Communication method, apparatus, device, and storage medium

Abstract

The present application relates to the technical field of WiFi communications, and discloses a communication method, an apparatus, a device, and a storage medium. The method comprises: on the basis of a first frame, determining whether to use the same security association with a first access point device and a second access point device in a roaming or handover process, wherein the roaming or handover process is a process in which a non-access point device roams or is handed over from the first access point device to the second access point device. It is beneficial to clarify whether the non-access point device uses the same security association to communicate with the first access point device and the second access point device in the roaming or handover process.

Description

Communication methods, devices, equipment and storage media Technical Field

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

[0002] It is uncertain whether the same security association is used to communicate with the first and second access point devices during the roaming process initiated by a non-access point device. Summary of the Invention

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

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

[0005] Based on the first frame, it is determined whether the same security association is used with the first access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0006] On the other hand, embodiments of this application provide a communication method, which is executed by a first access point device, the method comprising:

[0007] Based on the first frame, it is determined whether the same security association is used with the non-access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0009] Based on the first frame, it is determined whether the same security association is used with the non-access point device and the first access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0011] The first determining module is used to determine, based on the first frame, whether the same security association is used with the first access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0013] The second determining module is used to determine, based on the first frame, whether the same security association is used with the non-access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0015] The third determining module is used to determine, based on the first frame, whether the same security association is used with the non-access point device and the first access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0017] processor;

[0018] A transceiver connected to the processor;

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

[0020] The processor is configured to load and execute executable instructions to implement the communication methods performed by the non-access point device described above.

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

[0022] processor;

[0023] A transceiver connected to the processor;

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

[0025] The processor is configured to load and execute executable instructions to implement the communication method performed by the first access point device described above.

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

[0027] processor;

[0028] A transceiver connected to the processor;

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

[0030] The processor is configured to load and execute executable instructions to implement the communication method performed by the second access point device described above.

[0031] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which is executed by a processor of a non-access point device to implement the communication method executed by the non-access point device described above.

[0032] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which is executed by a processor of a first access point device to implement the communication method executed by the first access point device.

[0033] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which is executed by a processor of a second access point device to implement the communication method executed by the second access point device.

[0034] On the other hand, embodiments of this application provide a chip, the chip including programmable logic circuits and / or program instructions, which, when the chip is running on a non-access point device, is used to implement the communication method executed by the non-access point device described above.

[0035] On the other hand, embodiments of this application provide a chip, the chip including programmable logic circuits and / or program instructions, which, when the chip is running on a first access point device, is used to implement the communication method executed by the non-access point device described above.

[0036] On the other hand, embodiments of this application provide a chip, the chip including programmable logic circuits and / or program instructions, which, when the chip is running on a second access point device, is used to implement the communication method executed by the non-access point device described above.

[0037] On the other hand, embodiments of this application provide a computer program product, which includes 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 above-described communication method.

[0038] On the other hand, embodiments of this application provide a computer program product, which includes 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, thereby enabling the first access point device to implement the above-described communication method.

[0039] On the other hand, embodiments of this application provide a computer program product, which includes 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, thereby enabling the second access point device to implement the above-described communication method.

[0040] On the other hand, embodiments of this application provide a computer program that, when executed by a processor of a non-access point device, implements the communication method executed by the non-access point device described above.

[0041] On the other hand, embodiments of this application provide a computer program that, when executed by the processor of a first access point device, implements the communication method executed by the first access point device described above.

[0042] On the other hand, embodiments of this application provide a computer program that, when executed by the processor of a second access point device, implements the communication method executed by the second access point device described above.

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

[0044] During the process of a non-access point device roaming from a first access point device or handing over to a second access point device, the non-access point device can determine, based on the first frame, whether to use the same security association to communicate with the first and second access point devices during the roaming or handover process. Attached Figure Description

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

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

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

[0048] Figure 4 shows a flowchart of a roaming process provided in an embodiment of this application;

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

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

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

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

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

[0054] Figure 10 shows a flowchart of a communication method provided in an embodiment of this application;

[0055] Figure 11 shows a flowchart of a communication method provided in an embodiment of this application;

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

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

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

[0059] Figure 15 shows a structural block diagram of a non-access point device provided in an embodiment of this application;

[0060] Figure 16 shows a structural block diagram of a first access point device provided in an embodiment of this application;

[0061] Figure 17 shows a structural block diagram of a second access point device provided in an embodiment of this application;

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

[0063] 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”.

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

[0065] Multi-link operation

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

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

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

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

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

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

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

[0073] The FT defines two FT protocols:

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

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

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

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

[0078] • 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.

[0079] Robust Secure Network Association (RSNA) security mechanism

[0080] The IEEE 802.11 standard uses the concept of security associations to describe secure operations. Secure communication can only be achieved within the context of a security association because this context provides the state (e.g., encryption key, counter, sequence space) required for the correct operation of IEEE 802.11 cipher suites.

[0081] A security association is a set of policies and keys used to protect information. Information within a security association is stored by each party, requires consistency between parties, and necessitates a single identity. The identity is a compact name for the keys and other security association information, adapted to a table index or Media Access Control Protocol Data Unit (MPDU). RSNA STA supports the following types of security associations:

[0082] • Pairwise Master Key Security Association (PMKSA): IEEE 802.1X exchange, Opportunistic Wireless Encryption (OWE) exchange, System Architecture Evolution (SAE) authentication, Fast Initial Link Setup (FILS) authentication, or pre-shared Pairwise Master Key (PMK) information; PMKSA can be cached.

[0083] • Pairwise Master Key R0 (first level) security association: the result of a successful initial FT mobile domain association.

[0084] • Pairwise Master Key R1 (second level) security association: the result of a successful FT initial mobile domain association or FT authentication sequence.

[0085] • Pairwise Transient Key Security Association (PTKSA): The result of a successful 4-way handshake, including FT 4-way handshake, FT authentication sequence, FILS authentication, (11az) or Primary Address Space Number (PASN) authentication.

[0086] • Group Temporal Key Security Association (GTKSA): The result of a successful group key handshake, including a 4-way handshake, FT 4-way handshake, FT protocol, FT resource request protocol, or FILS authentication.

[0087] • Integrity Group Temporal Key Security Association (IGTKSA): Successful group key handshake, successful 4-way handshake, successful FT 4-way handshake, re-association response frame of Fast BSS Transition Protocol, or successful FILS authentication.

[0088] 1. PMKSA

[0089] When Extensible Authentication Protocol (EAP) authentication, SAE authentication, FILS authentication, OWE exchange are successfully completed or a pre-shared key (PSK) is configured, a PMKSA is jointly created by the Simple Mobility Management Entity (SME) of the authenticating party and the SME of the requesting party.

[0090] When the negotiated Authentication and Key Management (AKM) uses the Pairwise Transient Key-Key Confirmation Key (PTK-KCK) as a parameter defined in the pairwise key hierarchy of the IEEE 802.11 standard to derive the Pairwise Master Key Identifier (PMKID), the PMKID derived from PTK-KCK during the initial four-way handshake will not change during the lifetime of the PMKSA.

[0091] The PMKSA association is bidirectional. In other words, both parties use the information in the security association to send and receive data. The PMKSA is used to create the PTKSA. The PMKSA has a certain validity period. The PMKSA includes the following:

[0092] • PMKID, as defined in the pair key hierarchy or PMK-R0. PMKID identifies security associations.

[0093] • The MAC address of the authenticating party or the peer. For multi-band RSNA, the MAC address is associated with the operating frequency band used when the PMKSA is established.

[0094] • Pairwise Master Key (PMK); or if PMKSA is established with the Authentication and Key Management Protocol (AKMP), where the authentication type column includes FT authentication.

[0095] ·life cycle.

[0096] ·AKMP.

[0097] • All authorization parameters specified in the AS or local configuration. This may include parameters such as the Service Set Identifier (SSID) of the STA.

[0098] • Cache identifier, if published by the AP in the FILS indicator element.

[0099] 2. PTKSA

[0100] A PTKSA is a PTKSA generated upon successful 4-way handshake, FT 4-way handshake, FT protocol, FT resource request protocol, FILS authentication, (11az) or PASN authentication. This security association is also bidirectional. A PTKSA has the same lifespan as a PMKSA or PMK-R1 security association (whichever comes first), except for PTKSAs established using PASN authentication. A PTKSA used for PASN authentication has the minimum lifespan and negotiated timeout (if any) of the PMKSA used during PASN authentication. Because a PTKSA is bound to a PMKSA or PMK-R1 security association, it only has additional information from the 4-way handshake, FT protocol authentication, FILS authentication (11az) or PASN authentication. Only one PTKSA per frequency band per key ID has the same requester and verifier MAC addresses.

[0101] During the 4-way handshake defined in message 4 of the 4-way handshake and the FT 4-way handshake defined in the FT Initial Mobility Domain Association in the RSN, a state is created between messages 1 and 3 of the handshake. The PTKSA is not created until message 3 is verified by the requester and message 4 is verified by the authenticator. In the FT authentication sequence, the PTKSA is verified when message 3 is verified by the PMK-R1 key holder (R1 Key Holder, R1KH) in the Authenticator and message 4 is verified by the PMK-R1 key holder (S1 Key Holder, S1KH) in the requester.

[0102] In the FILS authentication sequence, PTKSA is verified by using key confirmations in the (re)association request and (re)association response frames.

[0103] PTKSA includes the following:

[0104] • PTK, where the PTK includes the Key Derivation Key (KDK) when the Wake-Up Request (WUR) frame protection is negotiated;

[0105] • Paired cipher group selector: When negotiating WUR frame protection, the cipher group selector is used for individually addressed WUR wake-up frames;

[0106] • The requester's MAC address depends on the negotiated AKMP;

[0107] • The validator's MAC address depends on the negotiated AKMP;

[0108] • Key ID; if an FT key hierarchy is used, it includes at least one of R1KH-ID, S1KH-ID, and PTKName.

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

[0110] 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).

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

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

[0113] 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).

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

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

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

[0117] For a separately 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.

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

[0119] In this embodiment of the application, "security-associated scenario" can also be referred to as "security-associated context". That is, "context" can refer to either a scenario or a context.

[0120] 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 1 below.

[0121] Table 1

[0122] 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 security association scenario parameter control field is shown in Table 2 below:

[0123] Table 2

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

[0125] Table 3

[0126] The parameter set format for security-related scenarios is shown in Tables 4 and 5 below:

[0127] Table 4 (Parameter Set Format for Receiver Replay Scenario)

[0128] Table 5 (Parameter Set Format for Receiver Replay Scenario)

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

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

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

[0132] Table 6

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

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

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

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

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

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

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

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

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

[0142] 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 an AP or other STAs. For example, an STA is any user communication device that allows users to communicate with an AP and thus with a 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 Equipment, etc.

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

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

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

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

[0147] In some embodiments, the frequency bands supported by the wireless communication system 10 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).

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

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

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

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

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

[0153] In some embodiments, non-access point devices include non-access point single-site devices (non-AP STA) or non-access point multi-link devices (non-AP MLD).

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

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

[0156] 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 Roaming Domain (SMD), or the same Roaming AP MLD.

[0157] In this embodiment, the non-access point device is described as a non-access point multi-link device, the first access point device is the source access point multi-link device, and the second access point device is the target access point multi-link device. Referring to Figure 4, the process of a non-access point device roaming or switching from the first access point device to the second access point device is illustrated. In some embodiments, before the non-access point device decides to initiate roaming, it associates / connects with the first access point device. Uplink and downlink data transmission can occur between the non-access point device and the first access point device, and uplink and downlink data transmission can occur between the first access point device and the distribution system (DS).

[0158] In some embodiments, the non-access point device decides whether to initiate roaming or handover. When the non-access point device decides to initiate roaming or handover, step 1 is performed.

[0159] Further, the non-access point device performs step 2, sending a roaming notification frame to notify either the first or second access point device that the non-access point device is about to roam. The roaming notification frame carries one or more candidate AP MLDs. The second access point device is included among the one or more candidate AP MLDs.

[0160] Furthermore, after receiving the roaming notification frame sent by the non-access point device, the first access point device may optionally select a second access point device 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 second access point device.

[0161] Further, the first access point device or the second access point device executes step 4, sending a roaming notification frame to the non-access point device to notify the non-access point device of: the second access point device, the roaming or handover request timeout parameters, the BA protocol negotiation parameter migration status, etc.

[0162] Further, the non-access point device executes step 5, sending a roaming request frame to the first access point device or the second access point device to initiate a roaming request.

[0163] Further, after the non-access point device (NAP) completes its roaming, i.e., after migrating from the first access point device to the second access point device, the second access point device executes step 6, sending a roaming response frame to the NAP. Optionally, this roaming response frame is used to instruct the NAP to prepare to send a Class 3 frame to the second access point device. Upon receiving this roaming response frame, the NAP can send a Class 3 frame to the second access point device. Class 3 frames refer to three types of frames: data frames, management frames, and control frames. In some embodiments, during the period between the NAP sending the roaming request frame and receiving the roaming response frame, the migration of data communication context information (such as BA protocol negotiation parameters and / or BA protocol control and status parameters) may also be optionally performed.

[0164] In some embodiments, after the non-access point device (NAP) finishes roaming, it associates / connects with the second access point device. Uplink and downlink data transmission are possible between the NAP and the second access point device, and uplink and downlink data transmission are also possible between the second access point device and the DS.

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

[0166] In some embodiments, after sending a roaming notification frame or a roaming request frame, the non-access point device may also receive downlink data sent by the first access point device. For example, the downlink data includes separately addressed QoS data frames or QoS Null frames sent by the first access point device to the non-access point device.

[0167] In some embodiments, when a non-access point device receives a roaming response frame, it may be unable to receive downlink data sent by the first access point device, depending on the type of the roaming response frame; it may also be able to receive downlink data sent by the first access point device during a specific time period (e.g., before the roaming timeout expires).

[0168] In some embodiments, the roaming notification frame is a link reconfiguration notification frame, which carries a reconfiguration multilink element containing link information of the second access point device, SRDE, RSNE, and FTE. The roaming request frame is a link reconfiguration request frame, which carries a reconfiguration multilink element containing link information of the second access point device, an overload control information element, SRDE, RSNE, RSNXE, and FTE. The roaming response frame is a link reconfiguration response frame, which carries a basic multilink element containing link information of the second access point device, a reconfiguration status list, group key data, an overload control information element, SRDE, RSNE, RSNXE, and FTE.

[0169] In some embodiments, the roaming notification frame sent by the non-access point device to the first access point device may also be an FT request frame defined by the IEEE 802.11 standard, and the roaming notification frame sent by the first access point device to the non-access point device may also be an FT response frame defined by the IEEE 802.11 standard. Meanwhile, the roaming request frame may be a reassociation request frame sent by the non-access point device to the second access point device, and the roaming response frame may be a reassociation response frame sent by the first access point device / second access point device to the non-access point device.

[0170] In some embodiments, if the roaming response frame is a reassociation response frame, the non-access point device has already deassociated with the first access point device after receiving the reassociation response frame (indicating successful reassociation with the second access point device), and therefore the non-access point device cannot receive downlink data sent by the first access point device.

[0171] In some embodiments, if the roaming response frame is a link reconfiguration frame, after receiving the link reconfiguration frame (indicating successful link establishment with the second access point device), the non-access point device may also receive downlink data sent by the first access point device for a specific period of time (e.g., before the roaming timeout expires) until the established link with the first access point device is deleted (or disabled) or the roaming timeout expires; alternatively, the established link with the first access point device may be directly deleted or disabled.

[0172] In some embodiments, a non-access point device (NAP) cannot receive downlink data sent by a second access point device until it receives a roaming response frame. Exemplarily, this downlink data includes separately addressed QoS data frames or QoS Null frames sent by a first access point device to the NAP. After successfully receiving a roaming response frame (indicating successful roaming or handover to the second access point device), the NAP can receive downlink data sent by the second access point device.

[0173] It should be noted that the roaming notification frame described in this embodiment can also be understood as a handover notification frame, the roaming request frame as a handover request frame, and the roaming response frame as a handover response frame. The difference between "roaming" and "handover" in this embodiment lies in their names; they convey the same meaning. For example, a non-access point device roaming from a first access point device to a second access point device can also be understood as the non-access point device handing over from the first access point device to the second access point device. Further details will not be elaborated upon hereafter.

[0174] In some embodiments, during roaming or handover of a non-access point device, the same security association can be used with both the first and second access point devices. For example, a first security association can be used with both the first and second access point devices. Alternatively, different security associations can be used with the first and second access point devices, respectively. For example, a first security association can be used with the first access point device, while a second security association can be used with the second access point device. The first and second security associations are different. That is, two security association methods can be used during roaming or handover of a non-access point device, including:

[0175] Method 1: Use the same security association with both the first and second access point devices;

[0176] Method 2: Use different security associations with the first access point device and the second access point device respectively.

[0177] However, it is uncertain which security association method a non-access point device (NAPD) will use during roaming or handover. Therefore, embodiments of this application propose a communication method that can clearly determine which security association method a NAPD will use during roaming or handover.

[0178] In this embodiment of the application, the roaming or handover process refers to the process by which a non-access point device roams from the first access point device or switches to the second access point device.

[0179] Optionally, the non-access point device in this application embodiment includes a non-access point single-site device or a non-access point multi-link device.

[0180] Optionally, the first access point device may include a single-site first access point device or a multi-link first access point device. Alternatively, the first access point device may be a source access point device, including a single-site source access point device or a multi-link source access point device. Alternatively, the first access point device may be a current access point device, including a single-site current access point device or a multi-link current access point device.

[0181] Optionally, the second access point device includes a single-site second access point device or a multi-link second access point device. Alternatively, the second access point device is a target access point device, including a single-site target access point device or a multi-link target access point device.

[0182] In some embodiments, the first access point device and the second access point device are attached to the same Seamless Roaming Domain (MLD). The attached AP of the first access point device or the attached AP of the second access point device may carry a Seamless Roaming Domain Element (SRDE) in its transmitted beacon or probe response frames.

[0183] In some embodiments, when a non-access point device (NAPD) establishes a multi-link with a first access point device or when an NAPD is associated with a first access point device, the NAPD establishes an initial seamless roaming domain (or seamless mobility domain) association with the seamless roaming domain or seamless roaming domain MLD to which the first access point device belongs. This serves as the first (re)association in the seamless roaming domain (or seamless mobility domain), allowing the NAPD's SME to use the seamless roaming (SR) process in the future.

[0184] Next, we will introduce the initial seamless roaming domain association:

[0185] The initial seamless roaming (SR) association is the first (re)association in the seamless roaming domain (or seamless movement domain). Non-AP MLD SMEs allow the use of the seamless roaming (SR) process in the future.

[0186] The initial seamless roaming domain (SR) association is typically the first association in the ESS. In addition to association request frames and association response frames, reassociation request frames and reassociation response frames are also supported in the initial seamless roaming domain (or seamless mobility domain) association, so that both SR access point devices and non-SR access point devices can appear in a single ESS.

[0187] For example, as shown in Figure 6, the non-AP MLD indicates its support for the Seamless Roaming (SR) process by including a Seamless Roaming Domain Element (SRDE) in the (re)association request frame, and indicates its support for security by including a Robust Security Network Element (RSNE). The AP responds by including both SRDE and RSNE in the (re)association response frame. After IEEE 802.1X authentication (if required) or SAE authentication, the STA and AP perform a 4-way handshake for Seamless Roaming (SR). At the end of the sequence, the IEEE 802.1X controlled port is opened, and the PTK of the PTKSA is established.

[0188] Non-AP MLD initiates SR initial seamless roaming domain (or seamless mobile domain) association by performing IEEE 802.11 authentication using the Open System authentication algorithm, including the following steps:

[0189] Step 11: The non-AP MLD sends an authentication request (Open System authentication algorithm, Basic Multi-Link Element) to the AP MLD.

[0190] Step 12: The AP MLD sends an authentication-response (Open System authentication algorithm, Basic Multi-Link Element) back to the non-AP MLD.

[0191] After successful IEEE 802.11 Open System or SAE certification, if the "Certification Type" in the suite type used is SR certification, the non-AP MLD will send a (re)association request frame to the AP MLD.

[0192] Step 13: The non-AP MLD sends a (Re)Association Request (SRDE, RSNE, RSNXE, Basic Multi-Link Element) frame to the AP MLD. The content of the SRDE is the value published by any AP to which the AP MLD is attached in its transmitted beacon frame or probe response frame. In addition, the non-AP MLD includes its security functions in the RSNE.

[0193] Step 14: The AP MLD sends a (Re)Association Response (SRDE, RSNE, RSNXE, Basic Multi-Link Element) back to the non-AP MLD.

[0194] For MLO, if the content of the SRDE received by the AP MLD does not match the content published in the beacon frame and probe response frame of the AP to which the AP MLD belongs, the AP MLD will reject the (re)association request frame with status code STATUS_INVALID_SRDE. If the SRDE appears in the (re)association request frame, and the content of the RSNE does not indicate a negotiated AKM with its authentication type listed as SR authentication, the AP MLD will reject the (re)association request frame with status code STATUS_INVALID_AKMP.

[0195] In some embodiments, taking the non-AP MLD as the supplicant and the AP MLD as the authenticator, the SR four-way handshake between the non-AP MLD and the AP MLD is as follows:

[0196] Step 21: The Authenticator sends an Extensible Authentication Protocol over LAN-Key (EAPOL-Key) frame to the Supplicant. Optionally, this frame carries at least the Authenticator's address. For example, the Authenticator sends an EAPOL-Key (0, 0, 1, 0, P, 0, 0, ANOnce, 0, {MAC Address}) to the Supplicant.

[0197] Step 22: The supplicant sends an EAPOL-Key frame to the authenticator. Optionally, this frame carries at least one of RSNE, MDE, FTE, OCI, and the supplicant's address. For example, the supplicant sends an EAPOL-Key (0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE(PMKR1Name), MDE, FTE, [RSNXE][, OCI], MAC Address, MLO Linkn}) to the authenticator.

[0198] Step 23: The Authenticator sends an EAPOL-Key frame to the Supplicant. Optionally, this frame carries at least one of the following: RSNE, group temporary key, MDE, FTE, OCI, and Authenticator address. For example, the Authenticator sends an EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANOnce, MIC, {MAC Address, MLO Linkm(RSNE(PMKR1Name)), MLO GTKn[, MLO IGTKn][, MLO BIGTKn], MDE, FTE, TIE(ReassociationDeadline), TIE(KeyLifetime)[, WIGTK(R, WIPN)]}).

[0199] Step 24: The supplicant sends an EAPOL-Key frame to the authenticator. Optionally, this frame carries at least the supplicant's address. For example, the supplicant sends an EAPOL-Key (1, 1, 0, 0, P, 0, 0, 0, MIC, {[MAC Address]}) to the authenticator.

[0200] For non-AP MLDs, MAC Address or MAC Address KDE is the MLD MAC address of the non-AP MLD to which the sending site is attached; for AP MLDs, MAC Address or MAC Address KDE is the MAC address of the seamless roaming domain to which the AP MLD to which the sending site is attached, or the MLD MAC address of the seamless roaming domain MLD.

[0201] The EAPOL-Key frame carries information that needs to be exchanged between the Supplicant (the requester) and the Authenticator (the authenticator). These exchanges result in the generation of the security association key and the synchronization of the security association state. (#1843) The EAPOL-Key is used to achieve the following functions:

[0202] • A 4-way handshake is used to confirm that the PMK between associated sites is the same and active, and to transmit GTK to the sites.

[0203] • Group key handshake, used to update GTK.

[0204] If no RSNA is established between a non-AP MLD and an AP MLD, each message of the SR 4-way handshake should be sent on the same link used in the most recent successful (re)association request / response frame exchange.

[0205] Once the PTKSA key lifecycle expires, as indicated by TIE [KeyLifetime], the STA or non-AP MLD should execute the SR Initial Seamless Roaming Domain Association Procedure to continue its association in the Seamless Roaming Domain. If the AP or AP MLD sends a Deauthentication or Disassociation frame to the STA or non-AP MLD with the reason code INVALID_AUTHENTICATION, then to continue its association in the Seamless Roaming Domain, the STA or non-AP MLD should execute the SR Initial Seamless Roaming Domain Association Procedure with any AP or any AP MLD in the Seamless Roaming Domain, respectively. If, after successful initial Seamless Roaming Domain Association, the requesting EAPOL state machine sends an EAPOL-start PDU (in one or more EAPOL-start frames), then the STA or non-AP MLD executes the SR Initial Seamless Roaming Domain Association Procedure.

[0206] In some embodiments, the first access point device and the second access point device belong to the same Seamless Roaming Domain (SRD) or the same Logical Access Point Multilink Device (Logical AP MLD). Alternatively, this can be understood as the first access point device and the second access point device belonging to the same Seamless Mobility Domain (SMD) or the same Roaming AP MLD, or the same Seamless Roaming Domain AP MLD, or the same Seamless Mobility Domain AP MLD. Further details will not be elaborated upon hereafter.

[0207] In some embodiments, seamless roaming can also be understood as seamless migration. Alternatively, roaming from a first access point device (AP) to a second AP can be understood as migrating from the first AP to the second AP. Seamless migration is the process by which a non-AP MLD transitions from the first AP (current AP) to the second AP (target AP), minimizing the time during which connectivity between the non-AP MLD and the DS is lost. Through this process, the non-AP MLD maintains its association state 4 during the transition, preserving the context for data transmission for a seamless experience.

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

[0209] Step 220: Based on the first frame, the non-access point device determines whether it uses the same security association with the first access point device and the second access point device during roaming or handover.

[0210] In some embodiments, the non-access point device determines, based on the first frame, that it will use the same security association with both the first and second access point devices during roaming or handover. For example, it may use the first security association with both the first and second access point devices. Optionally, this first security association may be dedicated to the roaming or handover process.

[0211] In some embodiments, the non-access point device determines, based on the first frame, that it will use different security associations with the first access point device and the second access point device during roaming or handover. For example, it may use a first security association with the first access point device and a second security association with the second access point device. The first security association and the second security association are different.

[0212] In some embodiments, the security association method used by a non-access point device during roaming or handover is determined based on the first frame. For example, FIG8 shows a flowchart of a communication method provided in an exemplary embodiment of this application. This method is performed by a non-access point device, a first access point device, or a second access point device. The method includes:

[0213] Step 320: Send and / or receive a first frame, which carries fields related to security association.

[0214] In some embodiments, the first frame is at least one of a roaming notification frame, a roaming request frame, a roaming response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a reassociation request frame, a reassociation response frame, a beacon frame, and a probe response frame.

[0215] In some embodiments, the classification is based on the type of the first frame:

[0216] The first frame is at least one of a roaming notification frame, a roaming request frame, and a roaming response frame; and / or,

[0217] The first frame is at least one of a link reconfiguration notification frame, a link reconfiguration request frame, and a link reconfiguration response frame; and / or,

[0218] The first frame is at least one of an association request frame, an association response frame, a reassociation request frame, and a reassociation response frame; and / or,

[0219] The first frame is either a beacon frame or a probe response frame.

[0220] In some embodiments, the classification is based on the sender of the first frame:

[0221] If the first frame is sent by a non-access point device, the first frame is at least one of the following: roaming notification frame, roaming request frame, link reconfiguration notification frame, link reconfiguration request frame, association request frame, and reassociation request frame;

[0222] If the first frame is sent by the first access point device, the first frame is at least one of the following: roaming notification frame, roaming response frame, link reconfiguration notification frame, link reconfiguration response frame, association response frame, reassociation response frame, beacon frame, and probe response frame;

[0223] If the first frame is sent by the second access point device, the first frame is at least one of the following: roaming notification frame, roaming response frame, link reconfiguration notification frame, link reconfiguration response frame, association response frame, reassociation response frame, beacon frame, and probe response frame.

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

[0225] • The first field indicates the Seamless Roaming Domain Element (SRDE);

[0226] • The second field indicates the Robust Security Network Element (RSNE);

[0227] • The third field indicates the Robust Security Network Extension Element (RSNXE);

[0228] • The fourth field indicates the Fast Transition Element (FTE);

[0229] • The fifth field indicates whether seamless roaming is enabled;

[0230] • The sixth field indicates seamless roaming support.

[0231] For example, let's take a first frame that is a link reconfiguration notification frame:

[0232] Link reconfiguration notification frame

[0233] In some embodiments, the link reconfiguration notification frame may be redefined based on the link reconfiguration notification frame defined in the IEEE 802.11be specification, and may adopt a protected action frame format.

[0234] The link reconfiguration notification frame is used by the AP MLD to recommend the addition and / or deletion of links based on multi-link establishment to its associated non-AP MLD. Optionally, it is used by the AP MLD to recommend a target AP MLD attached to the same seamless roaming domain or seamless roaming domain MLD to a non-AP MLD associated with it. Optionally, the AP MLD may also carry RSNA key update or update request information required for the non-AP MLD to roam to the target AP MLD in the link reconfiguration notification frame.

[0235] Simultaneously, the link reconfiguration notification frame can also provide the target AP MLD information for expected roaming through the non-AP MLD it is associated with. Optionally, the non-AP MLD needs to be associated with the Seamless Roaming Domain or Seamless Roaming Domain MLD to which the AP MLD belongs, and the provided target AP MLD for expected roaming also needs to belong to the same Seamless Roaming Domain or Seamless Roaming Domain MLD. Optionally, the non-AP MLD may also carry RSNA key update or update request information required for roaming to the expected target AP MLD in the link reconfiguration notification frame.

[0236] The link reconfiguration notification frame is a protected UHR class action frame. The information contained in the action field of the link reconfiguration notification frame is shown in Table 7 below (Link Reconfiguration Notification Frame Action Field Format):

[0237] Table 7

[0238] Optionally, the action field of the link reconfiguration notification frame described above may be based on the IEEE 802.11 standard definition.

[0239] For example, let's take a frame where the first frame is a link reconfiguration request frame:

[0240] • Link reconfiguration request frame

[0241] In some embodiments, the link reconfiguration request frame may be redefined based on the link reconfiguration request frame defined in the IEEE 802.11be specification, and may adopt a protected action frame format.

[0242] Link reconfiguration request frames are used by non-AP MLD requests to add and / or delete links based on their multi-link establishment.

[0243] Link reconfiguration request frames can also be used by a roaming non-AP MLD to request the addition of a link to the target AP MLD through its associated AP MLD. Optionally, the non-AP MLD needs to be associated with a seamless roaming domain or seamless roaming domain MLD to which the AP MLD belongs. Optionally, the non-AP MLD may also carry RSNA key updates or update information required for roaming to the target AP MLD in the link reconfiguration request frame.

[0244] The Link Reconfiguration Request frame is a protected UHR class action frame. The information contained in the action field of the Link Reconfiguration Request frame is shown in Table 8 below (Link Reconfiguration Request Frame Action Field Format):

[0245] Table 8

[0246] Optionally, the action field of the link reconfiguration request frame described above may be based on the IEEE 802.11 standard definition.

[0247] For example, let's take a scenario where the first frame is a link reconfiguration response frame:

[0248] Link reconfiguration response frame

[0249] In some embodiments, the link reconfiguration response frame may be redefined based on the link reconfiguration response frame defined in the IEEE 802.11be specification, and may adopt a protected action frame format.

[0250] The link reconfiguration response frame is sent by the AP MLD to respond to the link reconfiguration request frame received from the non-AP MLD, in order to accept or reject the request to the non-AP MLD to add and / or delete links based on the multi-link establishment.

[0251] Link reconfiguration response frames can also be sent by the AP MLD in response to a link reconfiguration request frame received from a roaming non-AP MLD, to accept or reject the non-AP MLD's request to add a link to the target AP MLD. Optionally, the non-AP MLD needs to be associated with a seamless roaming domain or seamless roaming domain MLD to which the AP MLD belongs. Optionally, the AP MLD may also carry RSNA key updates or update information required for the non-AP MLD to roam to the target AP MLD in the link reconfiguration response frame.

[0252] The link reconfiguration response frame is a protected UHR class action frame. The information contained in the action field of the link reconfiguration response frame is shown in Table 9 below (Link Reconfiguration Response Frame Action Field Format):

[0253] Table 9

[0254] Optionally, the action field of the above link reconfiguration response frame may be based on the IEEE 802.11 standard definition.

[0255] In some embodiments, the first field includes at least one of the following subfields:

[0256] • The first subfield is used to indicate the seamless roaming domain identifier;

[0257] • The second subfield is used to indicate the MAC address of the seamless roaming domain;

[0258] • The third subfield is used to indicate the first threshold, which is the PTKSA change duration threshold before seamless roaming;

[0259] • The fourth subfield is used to indicate the second threshold, which is the PTKSA change duration threshold after seamless roaming;

[0260] • The fifth subfield is used to indicate whether seamless roaming is allowed between two access point devices in the seamless roaming domain indicated by the first and / or second subfields for non-access point devices;

[0261] • The sixth subfield is used to indicate whether non-access point devices are allowed to communicate with the second access point device through the first access point device;

[0262] • The seventh subfield is used to indicate whether data communication context information for non-access point devices is allowed to be migrated from the first access point device to the second access point device;

[0263] • The eighth subfield is used to indicate whether data packets for non-access point devices are allowed to migrate from the first access point device to the second access point device;

[0264] • The ninth subfield is used to indicate whether an RSNA key update is required when a non-access point device roams from the first access point device or switches to the second access point device;

[0265] • The tenth subfield indicates whether the PTKSA needs to be updated before and after seamless roaming.

[0266] Next, let's introduce the Seamless Roaming Domain Element (SRDE):

[0267] In some embodiments, the Seamless Roaming Domain Element (SRDE) includes at least one of the following subfields: Seamless Roaming Domain Identifier (SRDID), Seamless Roaming Domain MAC Address, Seamless Roaming Capability and Policy, PTKSA Change Duration Threshold before Seamless Roaming, and PTKSA Change Duration Threshold after Seamless Roaming. An AP MLD can use the SRDE to announce that it is included in or attached to a Seamless Roaming Domain SRD, to announce its support for Seamless Roaming functionality, and to announce Seamless Roaming policy information, including whether it supports or allows fast transitions between two AP MLDs attached to the same Mobile Domain MLD.

[0268] For example, the format of a seamless roaming domain element is shown in Table 10 below:

[0269] Table 10

[0270] Furthermore, the aforementioned seamless roaming capability and policy subfields include at least one of the following: seamless roaming enable subfield, seamless roaming via DS subfield, data communication context migration subfield, packet migration subfield, whether RSNA key update is required subfield, whether PTKSA needs to be updated before and after seamless roaming subfield, and reserved subfield.

[0271] For example, the format of the seamless roaming capability and strategy subfields is shown in Table 11 below:

[0272] Table 11

[0273] The Seamless Roaming Enable subfield indicates whether seamless roaming is enabled or permitted for a non-AP MLD between two AP MLDs belonging to the Seamless Roaming Domain indicated by the Seamless Roaming Domain Identifier subfield and / or the Seamless Roaming Domain MAC Address subfield. Optionally, if the value of the Seamless Roaming Enable subfield is a first value, it indicates that seamless roaming is enabled or permitted between two AP MLDs belonging to the Seamless Roaming Domain indicated by the Seamless Roaming Domain Identifier subfield and / or the Seamless Roaming Domain MAC Address subfield; if the value of the Seamless Roaming Enable subfield is a second value, it indicates that seamless roaming is disabled or not permitted between two AP MLDs belonging to the Seamless Roaming Domain indicated by the Seamless Roaming Domain Identifier subfield and / or the Seamless Roaming Domain MAC Address subfield. For example, when the value of the Seamless Roaming Enable subfield is 1, it indicates that seamless roaming is enabled or permitted between two AP MLDs belonging to the Seamless Roaming Domain indicated by the Seamless Roaming Domain Identifier subfield and / or the Seamless Roaming Domain MAC Address subfield; otherwise, it indicates 0. For example, when the value of the Seamless Roaming Enable subfield is 0, it indicates that seamless roaming is enabled or allowed between two AP MLDs that are attached to the Seamless Roaming Domain Identifier subfield and / or the Seamless Roaming Domain MAC Address subfield; otherwise, it indicates 1.

[0274] The Seamless Roaming subfield of the DS indicates whether seamless roaming via the Over-the-DS protocol is enabled, meaning that a non-AP MLD can communicate with a target AP MLD through the current AP MLD. Communication between the non-AP MLD and the target AP MLD occurs within the seamless roaming action frame between the non-AP MLD and the current AP, while communication between the current AP MLD and the target AP MLD is via the DS protocol. Optionally, a first value for the Seamless Roaming subfield of the DS indicates that seamless roaming via the Over-the-DS protocol is enabled; a second value indicates that seamless roaming via the Over-the-DS protocol is disabled. For example, a value of 1 for the Seamless Roaming subfield of the DS indicates that seamless roaming via the Over-the-DS protocol is enabled; otherwise, a value of 0 indicates that seamless roaming via the Over-the-DS protocol is enabled. For example, when the value of the Seamless Roaming subfield via DS is 0, it indicates that seamless roaming via the Over-the-DS protocol is enabled; otherwise, it indicates 1.

[0275] The Data Communication Context Migration subfield indicates whether data communication context migration for a non-AP MLD is supported or permitted via a distributed system (Over-the-DS) from the current AP MLD to the target AP MLD. Optionally, a first value in the Data Communication Context Migration subfield indicates that data communication context migration is permitted; a second value indicates that data communication context migration is not permitted. For example, a value of 1 indicates that data communication context migration is permitted; otherwise, it indicates 0. Similarly, a value of 0 indicates that data communication context migration is permitted; otherwise, it indicates 1.

[0276] The Packet Migration subfield indicates whether packet migration for non-AP MLDs from the current AP MLD to the target AP MLD is supported or permitted via the Over-the-DS distributed system. Optionally, a first value in the Packet Migration subfield indicates support or permission for packet migration for non-AP MLDs via the Over-the-DS distributed system; a second value indicates no support or disallowance for packet migration for non-AP MLDs via the Over-the-DS distributed system. For example, a value of 1 indicates support or permission for packet migration for non-AP MLDs via the Over-the-DS distributed system; otherwise, a value of 0 indicates support or permission for packet migration for non-AP MLDs via the Over-the-DS distributed system; otherwise, a value of 1 indicates support or permission for packet migration for non-AP MLDs via the Over-the-DS distributed system.

[0277] The "RSNA Key Update Required" subfield indicates whether an RSNA key update (RSNA rekeying) is required when a non-AP MLD roams from its current AP MLD to a target AP MLD. Optionally, if the value of the "RSNA Key Update Required" subfield is the first value, it indicates that an RSNA key update is required when roaming from the current AP MLD to the target AP MLD; if the value of the "RSNA Key Update Required" subfield is the second value, it indicates that an RSNA key update is not required when roaming from the current AP MLD to the target AP MLD. For example, if the value of the "RSNA Key Update Required" subfield is 1, it indicates that an RSNA key update is required when roaming from the current AP MLD to the target AP MLD; otherwise, it indicates 0. Similarly, if the value of the "RSNA Key Update Required" subfield is 0, it indicates that an RSNA key update is required when roaming from the current AP MLD to the target AP MLD; otherwise, it indicates 1.

[0278] The "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield indicates whether an update of the PTKSA is required before and after seamless roaming. Optionally, if the value of the "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield is the first value, it indicates that an update of the PTKSA is required before and after seamless roaming; if the value of the "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield is the second value, it indicates that an update of the PTKSA is not required before and after seamless roaming. For example, if the value of the "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield is 1, it indicates that an update of the PTKSA is required before and after seamless roaming; otherwise, it indicates 0. Similarly, if the value of the "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield is 0, it indicates that an update of the PTKSA is required before and after seamless roaming; otherwise, it indicates 1.

[0279] In some embodiments, when the value of the "Whether PTKSA Needs to be Updated Before and After Seamless Roaming" subfield indicates that PTKSA needs to be updated before and after seamless roaming, then the seamless roaming domain element contains a "PTKSA Change Duration Threshold (TimeThreshold(BR))" subfield and / or a "PTKSA Change Duration Threshold (TimeThreshold(AR))" subfield. The "PTKSA Change Duration Threshold (TimeThreshold(BR))" subfield indicates the PTKSA change duration threshold before initiating seamless roaming, i.e., the PTKSA change duration threshold before initiating the roaming request frame; it is an unsigned integer in microseconds. The "PTKSA Change Duration Threshold (TimeThreshold(AR))" subfield indicates the PTKSA change duration threshold after seamless roaming, i.e., the PTKSA change duration threshold after the non-AP MLD receives the roaming response frame; it is an unsigned integer in microseconds.

[0280] In this embodiment of the application, the first field is taken as an example of a Seamless Roaming Domain Element (SRDE) field. For example, the SRDE format is shown in Table 10 above, and will not be described in detail here.

[0281] In this embodiment, the following examples illustrate the use of the following subfields: First subfield: Seamless Roaming Domain Identifier (SRDID) subfield in Table 10. Second subfield: Seamless Roaming Domain MAC Address subfield in Table 10. Third subfield: PTKSA Change Duration Threshold subfield before Seamless Roaming in Table 10. Fourth subfield: PTKSA Change Duration Threshold subfield after Seamless Roaming in Table 10. Fifth subfield: Seamless Roaming Enable subfield in Table 11. Sixth subfield: Seamless Roaming via DS subfield in Table 11. Seventh subfield: Data Communication Context Migration subfield in Table 11. Eighth subfield: Data Packet Migration subfield in Table 11. Ninth subfield: Whether RSNA Key Update is Required in Table 11. Tenth subfield: Whether PTKSA Update is Required Before and After Seamless Roaming in Table 11.

[0282] In some embodiments, at least two of the fifth, sixth, seventh, eighth, ninth, and tenth subfields are different subfields belonging to the same field. For example, as shown in Table 11 above, the seamless roaming enable subfield, the seamless roaming via DS subfield, the data communication context migration subfield, the packet migration subfield, whether RSNA key update is required subfield, and whether PTKSA needs to be updated before and after seamless roaming subfield all belong to the seamless roaming capability and policy subfields.

[0283] In some embodiments, if the tenth subfield indicates that the PTKSA needs to be updated before and after seamless roaming, the first field includes the third subfield and / or the fourth subfield; if the tenth subfield indicates that the PTKSA does not need to be updated before and after seamless roaming, the first field does not include the third subfield and / or the fourth subfield. For example, if the "Whether the PTKSA needs to be updated before and after seamless roaming" subfield indicates that the PTKSA needs to be updated before and after seamless roaming, the SRDE field includes the PTKSA change duration threshold subfield before seamless roaming and / or the PTKSA change duration threshold subfield after seamless roaming; if the "Whether the PTKSA needs to be updated before and after seamless roaming" subfield indicates that the PTKSA does not need to be updated before and after seamless roaming, the SRDE field does not include the PTKSA change duration threshold subfield before seamless roaming and / or the PTKSA change duration threshold subfield after seamless roaming.

[0284] In some embodiments, the fifth field may also be referred to as the Seamless Roaming Enable or Seamless Handover Enable field. The sixth field may also be referred to as the Seamless Roaming Support or Seamless Handover Support field. The Seamless Roaming Enable or Seamless Handover Enable field and / or the Seamless Roaming Support or Seamless Handover Support field may be placed directly in other elements, such as the UHR Operation element or the UHR Capabilities element. Optionally, the UHR Operation element or the UHR Capabilities element may be carried in one or more of the following frames: beacon frame; probe response frame; association request frame; association response frame; reassociation request frame; reassociation response frame.

[0285] It should be noted that steps 220 and 230 described above can be implemented as two separate embodiments, or they can be combined as a single embodiment. This application does not limit the implementation of these steps. When steps 220 and 320 are combined as a single embodiment, step 320 is executed before step 220.

[0286] In some embodiments, the security associations described in this application include at least one of the following described in the RSNA security mechanism section: PMKSA, PMK-R0 security association, PMK-R1 security association, PTKSA, GTKSA, and IGTKSA. Specifically, PTKSA is used as an example in this application embodiment.

[0287] Regarding Method 1: Using the same security association

[0288] In some embodiments, the non-access point device communicates with the first access point device and the second access point device based on the same PTKSA during roaming or handover. For example, during the non-AP MLD roaming from AP MLD1 to AP MLD2 (i.e., during the exchange of roaming request frames and roaming response frames), the same PTKSA is maintained.

[0289] In some embodiments, during the roaming or handover of a non-access point device from a first access point device to a second access point device, a security association dedicated to the roaming or handover process is used. Because this security association is dedicated to a seamless roaming or handover process, even if a security association leak occurs, it will only occur during the roaming or handover of the non-access point device from the first access point device to the second access point device, thereby helping to avoid or reduce the risk of security association leaks.

[0290] In this embodiment of the application, using the same security association with the first access point device and the second access point device during roaming or handover can also be understood as using the same security association with the first access point device and the second access point device for at least a period of time before roaming or handover and for at least a period of time after roaming or handover is completed.

[0291] In this embodiment, the example used is the use of the same PTKSA during the process of a non-access point device roaming from a first access point device or handing over to a second access point device. For example, the same PTKSA is the first PTKSA. The first PTKSA can be understood as a PTKSA dedicated to the seamless roaming or handover process.

[0292] Based on the embodiment shown in Figure 4 above, Figure 9 illustrates a flowchart of a communication method provided by an exemplary embodiment of this application. The method is jointly executed by a non-access point device, a first access point device, and a second access point device. The method includes:

[0293] Step a1: The non-access point device and the first access point device initiate an RSNA key update to generate the first PTKSA;

[0294] In some embodiments, before or after the non-access point device initiates roaming or handover, the non-access point device and the first access point device initiate an RSNA key update to generate a first PTKSA. The first PTKSA is different from the PTKSA used before initiating the RSNA key update.

[0295] In some embodiments, the first PTKSA is a PTKSA used during seamless roaming or handover of a non-access point device. Alternatively, the first PTKSA is understood as a PTKSA used by the non-access point device and / or the first and / or second access point devices during the process of the non-access point device roaming from a first access point device or handing over to a second access point device. Or, the first PTKSA is understood as a PTKSA dedicated to the seamless roaming process.

[0296] In some embodiments, to avoid or reduce the risk of data theft due to RSNA key leakage, non-access point devices may pre-initiate RSNA key updates (such as RSNA Rekeying, i.e. RSNA key regeneration) before or after initiating roaming or handover, generate a new RSNA key (including the first PTKSA), and cache the new RSNA key for seamless roaming.

[0297] In some embodiments, the first PTKSA is used for one or more roaming procedures. For example, a new RSNA key (e.g., the first PTKSA) is generated specifically for seamless roaming procedures through RSNA key updates between the non-access point device and the first access point device, and can be used for one or more roaming procedures to reduce the frequency of RSNA key updates.

[0298] It should be noted that before the non-access point device and the first access point device initiate the RSNA key update, the non-access point device and / or the first access point device and / or the second access point device are using a different PTKSA, such as a second PTKSA.

[0299] Step a2: Install the first PTKSA on the non-access point device and / or the first access point device;

[0300] In some embodiments, the non-access point device and / or the first access point device installs the first PTKSA before the non-access point device sends a roaming request frame. Figure 9 only shows the installation of the first PTKSA by the non-access point device as an example and does not show the process of the first access point device installing the first PTKSA, but this does not mean that the first access point device does not need to install the first PTKSA.

[0301] In some embodiments, when a first PTKSA is installed on the non-access point device and / or the first access point device, the non-access point device and / or the first access point device use the first PTKSA for seamless roaming or handover during the non-access point device's roaming from the first access point device or handover to the second access point device.

[0302] In some embodiments, the duration between the installation completion time of the first PTKSA and the first time is less than or equal to a first threshold. Optionally, the first threshold is a preset duration threshold. Optionally, the first threshold is determined based on the non-access point device itself, or determined through negotiation between the non-access point device and the first access point device, or pre-indicated by the first access point device. For example, the first access point device indicates the first threshold in a beacon frame or probe response frame. Optionally, the first access point device carries a Seamless Roaming Domain Element (SRDE) in the beacon frame or probe response frame, and the SRDE includes a PTKSA change duration threshold field to indicate the first threshold.

[0303] In some embodiments, the first time includes at least one of the following: roaming or handover initiation time, roaming or handover request time, roaming or handover preparation time, roaming request frame transmission time, and roaming request frame reception time. In this embodiment, the first time is described using the roaming request frame transmission time as an example.

[0304] For example, the installation of the first PTKSA can be done before or after roaming is initiated, as long as the time between the completion of the first PTKSA installation and the time the non-access point device sends a roaming request frame is less than or equal to a preset time threshold (TimeThreshold(BR)). Here, TimeThreshold(BR) is the PTKSA change time threshold before the non-access point device initiates roaming. Optionally, TimeThreshold(BR) is determined based on the non-access point device itself, negotiated between the non-access point device and the first access point device, or pre-indicated by the first access point device. Optionally, the first access point device carries a Seamless Roaming Domain Element (SRDE) in the beacon frame or probe response frame, and the SRDE includes a PTKSA change time threshold field to indicate TimeThreshold(BR).

[0305] In this embodiment, the RSNA key update requirement subfield value carried by the SRDE (e.g., a value of 0) indicates that the non-access point device (NPD) does not need to perform RSNA key update (RSNA rekeying) when roaming from the first NAD or switching to the second NAD. That is, the NAD continues to use the first PTKSA when roaming from the first NAD or switching to the second NAD. Alternatively, it can be understood that the NAD does not update the first PTKSA when roaming from the first NAD or switching to the second NAD.

[0306] In some embodiments, if the duration between the installation completion time of the first PTKSA and the first time is greater than a first threshold, the non-access point device may adopt the following scheme two. During the process of the non-access point device roaming from the first access point device or switching to the second access point device, the first PTKSA is updated to a fourth PTKSA, which is the PTKSA used by the non-access point device with the second access point device after the roaming ends.

[0307] In some embodiments, if the duration between the installation completion time of the first PTKSA and the first time is greater than a first threshold, the first access point device may employ at least one of the following methods:

[0308] 1) Reject seamless roaming requests from non-access point devices;

[0309] 2) Adopt the following scheme two. During the process of the non-access point device roaming from the first access point device or switching to the second access point device, update the first PTKSA to the fourth PTKSA. The fourth PTKSA is the PTKSA used by the non-access point device and the second access point device after the roaming ends.

[0310] In some embodiments, after the first access point device accepts a seamless roaming request from a non-access point device, the first access point device sends a first PTKSA to the second access point device. Alternatively, this can be understood as, if the first access point device accepts a roaming request from a non-access point device, the first access point device sends the first PTKSA to the second access point device via a secure channel. Or, if the first access point device accepts a roaming request from a non-access point device, the first access point device migrates the PTKSA information (including PTK, PTKSA context, and associated key authorization) currently associated with the non-access point device in the seamless roaming domain to the second access point device via a secure channel.

[0311] In some embodiments, after the second access point device receives the first PTKSA sent by the first access point device through a secure channel, the second access point device installs the first PTKSA. Optionally, after completing the installation of the first PTKSA and other roaming operations, the second access point device sends feedback to the first access point device, which can then send a roaming response frame to the non-access point device, indicating that the non-access point device has successfully roamed from the first access point device or switched to the second access point device. In some embodiments, when the second access point device has installed the first PTKSA, the second access point device uses the first PTKSA for seamless roaming or handover during the non-access point device's roaming or handover process from the first access point device to the second access point device.

[0312] It should be noted that the "secure channel" mentioned in the embodiments of this application refers to the secure channel of DS. Other parts will not be elaborated upon.

[0313] It should also be noted that, in the embodiments of this application, after any access point device installs PTKSA, it can use the corresponding PTK to encrypt and / or decrypt subsequent data frames, which will not be elaborated here.

[0314] Step a3: Install the second PTKSA on the non-access point device / second access point device.

[0315] In some embodiments, after a non-access point device receives a roaming response frame, the non-access point device successfully roams or hands over from the first access point device to the second access point device. At this time, the non-access point device and / or the second access point device can negotiate to use another PTKSA, such as a second PTKSA.

[0316] In some embodiments, the non-access point device and / or the second access point device install a second PTKSA after the non-access point device receives a roaming response frame. The second PTKSA is another PTKSA different from the first PTKSA. Figure 9 only shows the installation of the second PTKSA by the non-access point device as an example, and does not show the process of the second access point device installing the second PTKSA, but this does not mean that the second access point device does not need to install the second PTKSA.

[0317] In some embodiments, the second PTKSA is a newly negotiated PTKSA between the non-access point device and the second access point device. Alternatively, the second PTKSA is a PTKSA used prior to the installation of the first PTKSA. For example, the second PTKSA is a PTKSA used by the non-access point device and the first access point device before the installation of the first PTKSA.

[0318] In some embodiments, the duration between the installation completion time of the second PTKSA and the second time is less than or equal to a second threshold. Optionally, the second threshold is a preset duration threshold. Optionally, the second threshold is determined based on the non-access point device itself, or determined through negotiation between the non-access point device and the second access point device, or pre-indicated by the second access point device. For example, the second access point device indicates the second threshold in a beacon frame or probe response frame. Optionally, the second access point device carries an SRDE in the beacon frame or probe response frame, the SRDE including a PTKSA change duration threshold field to indicate the second threshold.

[0319] In some embodiments, the second time includes at least one of the following: roaming or handover completion time, next roaming or handover preparation time, next roaming or handover request time, roaming response frame reception time, roaming response frame transmission time, and link establishment time with the second access point device. It should be noted that "next roaming or handover" here is implemented in the event of a failure in the current roaming process or a failure in the current handover process. In this embodiment, the second time is described using the roaming response frame reception time as an example.

[0320] For example, after receiving a roaming response frame, a non-access point device (NAP) may install a second PTKSA for a duration less than or equal to a preset timethreshold (AR) period. Optionally, the second PTKSA is a new PTKSA or an RSNA key previously used due to the roaming procedure (i.e., installing a replacement PTKSA). Here, TimeThreshold (AR) is the PTKSA change duration threshold after receiving the roaming response frame. Optionally, TimeThreshold (AR) is determined based on the NAP itself, negotiated between the NAP and the second access point device, or pre-indicated by the second access point device. Optionally, the second access point device carries an SRDE in the beacon frame or probe response frame, the SRDE including a PTKSA change duration threshold field to indicate TimeThreshold (AR).

[0321] In some embodiments, if the duration between the completion time of the second PTKSA installation and the second time exceeds a second threshold, the non-access point device and / or the second access point device may initiate an RSNA key update to generate a third PTKSA and continue installing the third PTKSA.

[0322] It should be noted that the terms "first PTKSA", "second PTKSA" and "third PTKSA" used in the embodiments of this application only refer to PTKSAs used at different times, but it is not excluded that the PTKSAs used at the above different times may be the same PTKSA.

[0323] In summary, the method provided in this embodiment uses the same PTKSA during the roaming or handover process of a non-access point device from a first access point device to a second access point device. On one hand, since this PTKSA is pre-negotiated between the non-access point device and the first access point device, and is sent by the first access point device to the second access point device via a secure channel, it helps avoid the security risks caused by sharing the PTKSA between different access point devices. On the other hand, since the PTKSA is pre-negotiated between the non-access point device and the first access point device, it helps avoid the problem of long roaming times due to complex negotiation during roaming or handover.

[0324] It should be noted that this application embodiment only uses PTKSA as the same security association for illustration. In some possible embodiments, the same security association is PMKSA. For example, the non-access point device uses the same PMKSA with the first access point device and the second access point device during roaming or handover. This PMKSA can be understood as a PMKSA dedicated to the roaming or handover process. Optionally, the non-access point device, the first access point device, and the second access point device may derive the same PTKSA or different PTKSA based on this PMKSA, which is not limited here.

[0325] For Method 2: Use different security associations

[0326] In some embodiments, during roaming or handover, the non-access point device communicates with the first access point device and the second access point device respectively based on different PTKSAs. During the non-AP MLD's roaming from AP MLD1 to AP MLD2 (i.e., during the exchange of roaming request frames and roaming response frames), the PTKSA is updated.

[0327] In some embodiments, the security association may be updated or may change during the roaming or handover of a non-access point device from a first access point device to a second access point device. For example, the PTKSA may be updated during the roaming or handover of a non-access point device from a first access point device to a second access point device. Or, it can be understood that the PTKSA may change during the roaming or handover of a non-access point device.

[0328] In some embodiments, to avoid or reduce security risks caused by sharing PTKSA between different access point devices during roaming or handover, non-access point devices and / or first access point devices and / or second access point devices switch to using a security association specific to the second access point device. In this embodiment, the example of a non-access point device and / or first access point device and / or second access point device switching to using a fourth PTKSA specific to the second access point device is used for illustration.

[0329] In some embodiments, the auxiliary AP of the first access point device or the auxiliary AP of the second access point device carries a Seamless Roaming Domain Element (SRDE) in its transmitted beacon or probe response frame. The SRDE carries a subfield value indicating whether an RSNA key update is required (e.g., a value of 1), which indicates that an RSNA key update (RSNA rekeying) is required when the non-access point device roams from the first access point device or switches to the second access point device.

[0330] In this embodiment of the application, using different PTKSAs with the first access point device and the second access point device during roaming or handover can also be understood as using different PTKSAs with the first access point device and the second access point device for at least a period of time before roaming or handover and for at least a period of time after roaming or handover.

[0331] In this embodiment, the example illustrating the use of different PTKSAs during the roaming or handover process of a non-access point device from a first access point device to a second access point device is used. For instance, the different PTKSAs include a fifth PTKSA for the first access point device and a fourth PTKSA for the second access point device. During roaming or handover, the non-access point device switches from using the fifth PTKSA for the first access point device to using the fourth PTKSA for the second access point device; the fourth PTKSA is different from the fifth PTKSA. Optionally, the fourth PTKSA and the fifth PTKSA are derived from the same PMKSA. For example, both the fourth and fifth PTKSAs are derived from PMKSA-1. Optionally, the fourth PTKSA and the fifth PTKSA are derived from different PMKSAs. For example, the fourth PTKSA is derived from PMKSA-1, while the fifth PTKSA is derived from PMKSA-2; PMKSA-1 and PMKSA-2 are different.

[0332] In some embodiments, the method for deriving a PTKSA key from a PMKSA key may employ one of the following methods:

[0333] 1) Based on the 4-way handshake defined in the current IEEE 802.11 standard.

[0334] 2) The PTKSA key generation method (i.e., FT 4-way handshake) used in the FT protocol defined by the current IEEE 802.11 standard.

[0335] In some embodiments, switching to the use of a fourth PTKSA for the second access point device includes at least one of the following:

[0336] Method 1: During the process of a non-access point device roaming from the first access point device or switching to the second access point device, the first access point device sends the fourth PTKSA to the second access point device through a secure channel;

[0337] In some embodiments, the fourth PTKSA is a PTKSA used prior to the seamless roaming or handover process; and / or, the fourth PTKSA is a newly negotiated PTKSA for the seamless roaming or handover process.

[0338] Option 1: The fourth PTKSA is a PTKSA that the non-access point device continuously uses before roaming from the first access point device or switching to the second access point device. For example, based on the embodiment shown in FIG4 above, FIG10 shows a flowchart of a communication method provided in an exemplary embodiment of this application. The method is jointly performed by the non-access point device, the first access point device, and the second access point device. The method includes:

[0339] Step b1: Install the fourth PTKSA on the second access point device.

[0340] It should be noted that the non-access point device and / or the first access point device install the fourth PTKSA before step b1. Figure 10 only uses the installation of the fourth PTKSA by the second access point device as an example and does not show the process of installing the fourth PTKSA by the non-access point device and / or the first access point device, but this does not mean that the non-access point device and / or the first access point device do not need to install the fourth PTKSA.

[0341] In some embodiments, the fourth PTKSA is the PTKSA for the second access point device. Alternatively, it can be understood as the fourth PTKSA used by the non-access point device and the second access point device after the non-access point device has successfully roamed or switched from the first access point device to the second access point device.

[0342] In some embodiments, the fourth PTKSA is a PTKSA that the non-access point device continues to use before initiating roaming or handover, or after initiating roaming or handover. Alternatively, it can be understood that the fourth PTKSA is a PTKSA used by the non-access point device before roaming.

[0343] In some embodiments, the non-access point device requests the first access point device to send the fourth PTKSA to the second access point device via a secure channel before, during, or after sending a roaming request frame. Optionally, the first access point device accepts the request from the non-access point device or rejects it. In this embodiment, the first access point device accepts the request from the non-access point device, and then sends the fourth PTKSA to the second access point device via a secure channel.

[0344] After receiving the fourth PTKSA from the first access point device via a secure channel, the second access point device installs the fourth PTKSA. Optionally, after completing the fourth PTKSA installation and other roaming operations, the second access point device sends feedback to the first access point device, which can then send a roaming response frame to the non-access point device, indicating that the non-access point device has successfully roamed from the first access point device or switched to the second access point device. In some embodiments, when the second access point device has installed the fourth PTKSA, it uses the fourth PTKSA after the non-access point device roams from the first access point device or switches to the second access point device.

[0345] In this embodiment, on the one hand, the first access point device sends the fourth PTKSA to the second access point device through a secure channel, which helps to avoid the security risks caused by sharing the PTKSA between different access point devices. On the other hand, since PTKSA negotiation is not required during roaming or handover of non-access point devices, it helps to solve the problem of long roaming times caused by complex negotiation.

[0346] Option 2: The fourth PTKSA is a newly negotiated PTKSA during the process of a non-access point device roaming from the first access point device or switching to the second access point device. For example, based on the embodiment shown in FIG4 above, FIG11 shows a flowchart of a communication method provided in an exemplary embodiment of this application. This method is jointly performed by the non-access point device, the first access point device, and the second access point device. The method includes:

[0347] Step b2: Install the fourth PTKSA on the second access point device.

[0348] It should be noted that the non-access point device and / or the first access point device install the fourth PTKSA before step b2. Figure 11 only uses the installation of the fourth PTKSA by the second access point device as an example and does not show the process of installing the fourth PTKSA by the non-access point device and / or the first access point device, but this does not mean that the non-access point device and / or the first access point device do not need to install the fourth PTKSA.

[0349] In some embodiments, the fourth PTKSA is the PTKSA for the second access point device. Alternatively, it can be understood as the fourth PTKSA used by the non-access point device and the second access point device after the non-access point device has successfully roamed or switched from the first access point device to the second access point device.

[0350] In some embodiments, the non-access point device requests the first access point device to initiate an RSNA key update to generate a fourth PTKSA before, via, or after sending a roaming request frame. It also requests the first access point device to send the fourth PTKSA to the second access point device via a secure channel. Optionally, the first access point device accepts or rejects the request from the non-access point device. In this embodiment, the first access point device accepts the request from the non-access point device, and then sends the fourth PTKSA to the second access point device via a secure channel.

[0351] After receiving the fourth PTKSA from the first access point device via a secure channel, the second access point device installs the fourth PTKSA. Optionally, after completing the fourth PTKSA installation and other roaming operations, the second access point device sends feedback to the first access point device, which can then send a roaming response frame to the non-access point device, indicating that the non-access point device has successfully roamed from the first access point device or switched to the second access point device. In some embodiments, when the second access point device has installed the fourth PTKSA, it uses the fourth PTKSA after the non-access point device roams from the first access point device or switches to the second access point device.

[0352] In this embodiment, on the one hand, the first access point device sends the fourth PTKSA to the second access point device through a secure channel, which helps to avoid the security risks caused by sharing the PTKSA between different access point devices. On the other hand, since the fourth PTKSA is pre-negotiated, it helps to solve the problem of long roaming times caused by complex negotiation.

[0353] Method 2: During the process of a non-access point device roaming from the first access point device or switching to the second access point device, the first access point device sends a PMKSA to the second access point device through a secure channel. This PMKSA is used to derive the fourth PTKSA.

[0354] Based on the embodiment shown in Figure 4 above, Figure 12 illustrates a flowchart of a communication method provided by an exemplary embodiment of this application. The method is jointly executed by a non-access point device, a first access point device, and a second access point device. The method includes:

[0355] Step b3: Install the fourth PTKSA on the second access point device.

[0356] It should be noted that the non-access point device and / or the first access point device install the fourth PTKSA after step b3. Figure 12 only uses the installation of the fourth PTKSA by the second access point device as an example and does not show the process of installing the fourth PTKSA by the non-access point device and / or the first access point device, but this does not mean that the non-access point device and / or the first access point device does not need to install the fourth PTKSA.

[0357] In some embodiments, the fourth PTKSA is the PTKSA for the second access point device. Alternatively, it can be understood as the fourth PTKSA used by the non-access point device and the second access point device after the non-access point device has successfully roamed or switched from the first access point device to the second access point device.

[0358] In some embodiments, the fourth PTKSA is derived from the first PMKSA; or, the fourth PTKSA is derived from the second PMKSA. The first PMKSA differs from the second PMKSA; the first PMKSA is generated by the non-access point device before initiating roaming or handover, while the second PMKSA is generated by the non-access point device after initiating roaming or handover and before sending a roaming request frame.

[0359] To reduce the time spent negotiating new keys during roaming or handover, non-access point devices can initially associate with a seamless roaming domain or SRD / SMD MLD through a first access point device before roaming, thus associating the non-access point device with the seamless roaming domain or SRD / SMD MLD and forming a first PMKSA with the seamless roaming domain or SRD / SMD MLD.

[0360] In some embodiments, the non-access point device maintains the first PMKSA unchanged during roaming from the first access point device or switching to the second access point device.

[0361] In some embodiments, before initiating roaming, the non-access point device (NAPD) establishes one or more second PMKSAs with the seamless roaming domain or SRD / SMD MLD through the first APD and caches them. The cached second PMKSA is used to establish a PTKSA between the NAPD and the second APD, i.e., a fourth PTKSA between the NAPD and the second APD is derived from the cached PMKSA key.

[0362] In some embodiments, the non-access point device requests the first access point device to migrate the first PMKSA and / or the second PMKSA to the second access point device before sending a roaming request frame, or via a roaming request frame, or after sending a roaming request frame. Optionally, the first access point device accepts the request from the non-access point device or rejects the request. In this embodiment, the first access point device accepts the request from the non-access point device as an example; the first access point device then sends the first PMKSA and / or the second PMKSA to the second access point device via a secure channel.

[0363] After the second access point device receives the first PMKSA and / or the second PMKSA sent by the first access point device through a secure channel, the second access point device derives a fourth PTKSA based on the first PMKSA and / or the second PMKSA. Optionally, the fourth PTKSA is derived by the non-access point device and the second access point device based on a four-way handshake process in the Seamless Roaming Domain; or, the fourth PTKSA is derived by the non-access point device and the second access point device based on a Fast Transition (FT) four-way handshake process.

[0364] In some embodiments, the method for deriving a PTKSA key from a PMKSA key may employ one of the following methods:

[0365] 1) Optimize the four-way handshake as defined in the current IEEE 802.11 standard. This means that the non-access point device and the second access point device directly perform a four-way handshake based on the seamless roaming domain or seamless roaming domain MLD on the existing or cached PMKSA. The existing or cached PMK and PMK context can be migrated from the first access point device to the second access point device.

[0366] 2) The method for generating the new PTKSA key for the second access point device based on the FT protocol defined in the current IEEE 802.11 standard (i.e., FT 4-way handshake) involves a four-way FT handshake between the non-access point device and the second access point device. The PMK-R1 and PMK-R1 context derived from the original PMK can be migrated from the first access point device to the second access point device.

[0367] Optionally, after the second access point device completes the installation of the fourth PTKSA and other roaming operations, it sends feedback to the first access point device. The first access point device can then send a roaming response frame to the non-access point device, indicating that the non-access point device has successfully roamed from the first access point device or switched to the second access point device. In some embodiments, if the second access point device has installed the fourth PTKSA, it uses the fourth PTKSA after the non-access point device roams from the first access point device or switches to the second access point device.

[0368] In this embodiment, on the one hand, the first access point device sends the first PMKSA and / or the second PMKSA to the second access point device through a secure channel, which helps to avoid the security risks caused by sharing the PTKSA between different access point devices. On the other hand, since the first PMKSA and / or the second PMKSA are predetermined, it helps to solve the problem of long roaming times caused by complex negotiation.

[0369] It should be noted that the embodiments in this application only illustrate different security associations as different PTKSAs. In some possible embodiments, different security associations are different PMKSAs. For example, the first PMKSA and the second PMKSA mentioned above. The embodiments in this application do not limit this.

[0370] Figure 13 illustrates a flowchart of a communication method provided in an exemplary embodiment of this application. The method is performed by a first access point device. The method includes:

[0371] Step 420: Based on the first frame, the first access point device determines whether it uses the same security association with the non-access point device and the second access point device during roaming or handover.

[0372] In some embodiments, the first access point device determines, based on the first frame, that it will use the same security association with the non-access point device and the second access point device during roaming or handover. See the Embodiments section of Method 1 above for details.

[0373] In some embodiments, the first access point device determines, based on the first frame, to use different security associations with the non-access point device and the second access point device, respectively, during roaming or handover. See the embodiments section of Method Two above for details.

[0374] In some embodiments, the security association method used by the first access point device during roaming or handover is determined based on the first frame. See step 320 above for a specific embodiment.

[0375] Figure 14 illustrates a flowchart of a communication method provided in an exemplary embodiment of this application. The method is performed by a second access point device. The method includes:

[0376] Step 520: The second access point device determines, based on the first frame, whether it uses the same security association with the non-access point device and the first access point device during roaming or handover.

[0377] In some embodiments, the second access point device determines, based on the first frame, that it will use the same security association with both the non-access point device and the first access point device during roaming or handover. See the embodiments section of Method 1 above for details.

[0378] In some embodiments, the second access point device determines, based on the first frame, that it will use different security associations with the non-access point device and the first access point device, respectively, during roaming or handover. See the embodiments section of Method Two above for details.

[0379] In some embodiments, the security association method used by the second access point device during roaming or handover is determined based on the first frame. See step 320 above for a specific embodiment.

[0380] In related technologies, during roaming initiated by a non-access point device, the PTK can be shared or not. For roaming schemes with shared PTK, there are certain security risks because the PTK may be shared between access point devices in different locations (e.g., between the first and second access point devices). For roaming schemes without shared PTK (such as roaming schemes based on existing FT mechanisms), there is also the problem of long roaming times due to the complexity of PTK negotiation.

[0381] This application provides a secure association and key establishment mechanism for a non-access point device initially associated with a Seamless Mobility Domain (SMD) or Roaming (or Logical) AP MLD when the first access point device and the second access point device are in the same Seamless Mobility Domain (SMD) or Roaming (or Logical) AP MLD. The mechanism includes one or more of the following:

[0382] a. Requirements and rules for sharing or distributing keys between the first access point device and the second access point device;

[0383] b. Establish or derive keys (such as PMK or different levels of PMK, PTK or different levels of PTK) containing SMD identifier or identity information, first access point device or second access point device identifier or identity information, and authenticated when the key is installed on the target device;

[0384] c. A mechanism for establishing backup keys (such as PMK or different levels of PMK keys, PTK or different levels of PTK keys).

[0385] In some embodiments, this application also proposes a security association and key establishment mechanism between a non-access point device and a second access point device when the non-access point device roams from a first access point device or switches to a second access point device, including a key rekeying processing method and signaling mechanism before and / or after roaming.

[0386] The communication method provided by the embodiments of this application achieves continuous data transmission while minimizing or reducing security risks caused by sharing security-related information between access point devices in different locations.

[0387] It should be noted that the steps performed by the non-access point device described above can be implemented as a single embodiment. Alternatively, the steps performed by the first access point device described above can be implemented as a single embodiment. Alternatively, the steps performed by the second access point device described above can be implemented as a single embodiment. Alternatively, the steps performed by the non-access point device and the first access point device described above can be combined to implement a single embodiment. Alternatively, the steps performed by the non-access point device and the second access point device described above can be combined to implement a single embodiment. Alternatively, the steps performed by the first access point device and the second access point device described above can be combined to implement a single embodiment. Alternatively, the steps performed by the non-access point device, the first access point device, and the second access point device described above can be combined to implement a single embodiment.

[0388] Figure 15 shows a structural block diagram of a non-access point device provided in an exemplary embodiment of this application. The device includes:

[0389] The first determining module 610 is used to determine, based on the first frame, whether the same security association is used with the first access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which a non-access point device roams or hands over from the first access point device to the second access point device.

[0390] The first determining module 610 is further configured to determine, based on the first frame, that the same security association is used with the first access point device and the second access point device during roaming or handover.

[0391] The first determining module 610 is further configured to determine, based on the first frame, that different security associations are used with the first access point device and the second access point device respectively during roaming or handover.

[0392] In some embodiments, the security association includes at least one of PMKSA, PMK-R0 security association, PMK-R1 security association, PTKSA, GTKSA, and IGTKSA.

[0393] In some embodiments, during roaming or handover from a first access point device to a second access point device, a security association dedicated to the seamless roaming or handover process is used. The first and second access point devices belong to the same seamless roaming domain or the same logical access point multi-link device.

[0394] In some embodiments, during roaming from a first access point device or handover to a second access point device, a first pairwise temporary key security association (PTKSA) for seamless roaming or handover is used.

[0395] The first determining module 610 is further configured to determine, based on the first frame, that the same PTKSA is used with the first access point device and the second access point device during roaming or handover. The same PTKSA includes the first PTKSA.

[0396] The first determining module 610 is further configured to initiate a robust security network association RSNA key update before or after initiating roaming or handover, to generate a first PTKSA. The first PTKSA is different from the PTKSA used before initiating the RSNA key update.

[0397] In some embodiments, the first PTKSA is used for one or more roaming processes.

[0398] The first determining module 610 is further configured to install a first PTKSA before sending a roaming request frame; and / or, install a second PTKSA after receiving a roaming response frame. The second PTKSA is a different PTKSA from the first PTKSA.

[0399] In some embodiments, the second PTKSA is a PTKSA used before the first PTKSA is installed.

[0400] In some embodiments, the duration between the installation completion time of the first PTKSA and the first time is less than or equal to a first threshold; and / or, the duration between the installation completion time of the second PTKSA and the second time is less than or equal to a second threshold.

[0401] The first determining module 610 is further configured to, if the duration between the completion time of the installation of the second PTKSA and the second time is greater than a second threshold, initiate an RSNA key update to generate a third PTKSA; and install the third PTKSA.

[0402] The first determining module 610 is further configured to update the first PTKSA to a fourth PTKSA during the process of roaming from the first access point device or switching to the second access point device when the duration between the installation completion time of the first PTKSA and the first time is greater than a first threshold. The fourth PTKSA is the PTKSA used by the second access point device after the non-access point device finishes roaming.

[0403] In some embodiments, the device further includes:

[0404] The first transceiver module 620 is also used to send and / or receive a first frame, the first frame carrying fields related to security associations in seamless roaming.

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

[0406] The first field is used to indicate SRDE;

[0407] The second field is used to indicate RSNE;

[0408] The third field is used to indicate RSNXE;

[0409] The fourth field is used to indicate the FTE;

[0410] The fifth field indicates whether seamless roaming is enabled;

[0411] The sixth field indicates seamless roaming support.

[0412] In some embodiments, the first field includes at least one of the following subfields:

[0413] The first subfield is used to indicate the seamless roaming domain identifier;

[0414] The second subfield is used to indicate the MAC address of the seamless roaming domain;

[0415] The third subfield is used to indicate the first threshold, which is the PTKSA change duration threshold before seamless roaming.

[0416] The fourth subfield is used to indicate the second threshold, which is the PTKSA change duration threshold after seamless roaming;

[0417] The fifth subfield is used to indicate whether seamless roaming between two access point devices in the seamless roaming domain indicated by the first and / or second subfields is enabled or permitted for the non-access point device;

[0418] The sixth subfield is used to indicate whether non-access point devices are allowed to communicate with the second access point device through the first access point device;

[0419] The seventh subfield is used to indicate whether data communication context information for non-access point devices is allowed to migrate from the first access point device to the second access point device;

[0420] The eighth subfield is used to indicate whether data packets for non-access point devices are allowed to migrate from the first access point device to the second access point device;

[0421] The ninth subfield is used to indicate whether an RSNA key update is required when a non-access point device roams from the first access point device or switches to the second access point device;

[0422] The tenth subfield indicates whether the PTKSA needs to be updated before and after seamless roaming.

[0423] In some embodiments, at least two of the fifth, sixth, seventh, eighth, ninth, and tenth subfields are different subfields belonging to the same field.

[0424] In some embodiments, if the tenth subfield indicates that the PTKSA needs to be updated before and after seamless roaming, the first field includes the third subfield and / or the fourth subfield; if the tenth subfield indicates that the PTKSA does not need to be updated before and after seamless roaming, the first field does not include the third subfield and / or the fourth subfield.

[0425] In some embodiments, the first frame is at least one of a roaming notification frame, a roaming request frame, a roaming response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a reassociation request frame, a reassociation response frame, a beacon frame, and a probe response frame.

[0426] The first determining module 610 is further configured to establish an initial seamless roaming domain association between the non-access point device and the first access point device when the non-access point device establishes a multi-link with the first access point device, or when the non-access point device is associated with the first access point device.

[0427] The first determining module 610 is further configured to switch the security association for the second access point device during roaming from or switching to the second access point device. The first access point device and the second access point device belong to the same seamless roaming domain or the same logical access point multi-link device.

[0428] The first determining module 610 is further configured to, based on the first frame, determine that a different PTKSA is used between the first access point device and the second access point device during roaming or handover. The different PTKSAs include a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, wherein the fourth PTKSA and the fifth PTKSA are different. Optionally, the fourth PTKSA and the fifth PTKSA are derived from the same PMKSA; or, the fourth PTKSA and the fifth PTKSA are derived from different PMKSAs.

[0429] The first determining module 610 is also configured to switch to a fourth PTKSA for the second access point device during roaming from the first access point device or switching to the second access point device.

[0430] In some embodiments, the fourth PTKSA is a PTKSA used prior to the seamless roaming or handover process; and / or, the fourth PTKSA is a newly negotiated PTKSA for the seamless roaming or handover process.

[0431] The first determining module 610 is further configured to, in the case that the fourth PTKSA is a PTKSA used before the seamless roaming or handover process, request the first access point device to send the fourth PTKSA to the second access point device through a secure channel before, through, or after sending a roaming request frame.

[0432] The first determining module 610 is further configured to, in the case that the fourth PTKSA is a newly negotiated PTKSA for seamless roaming or a handover process, request the first access point device to initiate an RSNA key update to generate the fourth PTKSA before, through, or after sending a roaming request frame; and request the first access point device to send the fourth PTKSA to the second access point device via a secure channel.

[0433] In some embodiments, the fourth PTKSA is derived from the first PMKSA; or, the fourth PTKSA is derived from the second PMKSA. The first PMKSA differs from the second PMKSA; the first PMKSA is generated by the non-access point device before initiating roaming or handover, while the second PMKSA is generated by the non-access point device after initiating roaming or handover and before sending a roaming request frame.

[0434] The first determining module 610 is further configured to request the first access point device to migrate the first PMKSA and / or the second PMKSA to the second access point device during the process of roaming from the first access point device or switching to the second access point device.

[0435] In some embodiments, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the seamless roaming domain; or, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the fast transition (FT) four-way handshake process.

[0436] It should be noted that when the apparatus provided in the above embodiments implements its functions, the steps performed by the non-access point device in the above method embodiments are referred to.

[0437] Figure 16 shows a structural block diagram of a first access point device provided in an exemplary embodiment of this application. The device includes:

[0438] The second determining module 810 is used to determine, based on the first frame, whether the same security association is used with the non-access point device and the second access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0439] The second determining module 810 is also used to determine, based on the first frame, that the same security association is used with the non-access point device and the second access point device during roaming or handover.

[0440] The second determining module 810 is further configured to determine, based on the first frame, that different security associations are used with the non-access point device and the second access point device, respectively, during roaming or handover.

[0441] In some embodiments, the security association includes at least one of PMKSA, PMK-R0 security association, PMK-R1 security association, PTKSA, GTKSA, and IGTKSA.

[0442] In some embodiments, during the roaming or handover of a non-access point device from a first access point device to a second access point device, a security association dedicated to the seamless roaming or handover process is used. The first and second access point devices belong to the same seamless roaming domain or the same logical access point multi-link device.

[0443] The second determining module 810 is further configured to use a first PTKSA for seamless roaming or handover during the process of a non-access point device roaming from a first access point device or handing over to a second access point device.

[0444] The second determining module 810 is further configured to, based on the first frame, determine that the same PTKSA is used with the non-access point device and the second access point device during roaming or handover. The same PTKSA includes the first PTKSA.

[0445] The second determining module 810 is further configured to initiate an RSNA key update before or after a non-access point device initiates roaming or handover, to generate a first PTKSA. The first PTKSA is different from the PTKSA used before initiating the RSNA key update.

[0446] In some embodiments, the first PTKSA is used for one or more roaming processes of a non-access point device.

[0447] The second determining module 810 is also used to install the first PTKSA before receiving the roaming request frame.

[0448] In some embodiments, the duration between the installation completion time of the first PTKSA and the first time is less than or equal to a first threshold.

[0449] The second determining module 810 is further configured to reject the roaming request of the non-access point device if the duration between the installation completion time of the first PTKSA and the first time is greater than a first threshold; and / or, during the process of the non-access point device roaming from the first access point device or switching to the second access point device, update the first PTKSA to a fourth PTKSA, the fourth PTKSA being the PTKSA used by the non-access point device with the second access point device after the roaming ends.

[0450] The second determining module 810 is further configured to send the first PTKSA to the second access point device via a secure channel when the first access point device receives a roaming request from a non-access point device.

[0451] In some embodiments, the device further includes:

[0452] The second transceiver module 820 is used to send and / or receive a first frame, which carries fields related to security associations in seamless roaming.

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

[0454] The first field is used to indicate SRDE;

[0455] The second field is used to indicate RSNE;

[0456] The third field is used to indicate RSNXE;

[0457] The fourth field is used to indicate the FTE;

[0458] The fifth field indicates whether seamless roaming is enabled;

[0459] The sixth field indicates seamless roaming support.

[0460] In some embodiments, the first field includes at least one of the following subfields:

[0461] The first subfield is used to indicate the seamless roaming domain identifier;

[0462] The second subfield is used to indicate the MAC address of the seamless roaming domain;

[0463] The third subfield is used to indicate the first threshold, which is the PTKSA change duration threshold before seamless roaming.

[0464] The fourth subfield is used to indicate the second threshold, which is the PTKSA change duration threshold after seamless roaming;

[0465] The fifth subfield is used to indicate whether seamless roaming between two access point devices in the seamless roaming domain indicated by the first and / or second subfields is enabled or permitted for the non-access point device;

[0466] The sixth subfield is used to indicate whether the non-access point device can communicate with the second access point device through the first access point device;

[0467] The seventh subfield is used to indicate whether data communication context information for non-access point devices is allowed to migrate from the first access point device to the second access point device;

[0468] The eighth subfield is used to indicate whether data packets for non-access point devices are allowed to migrate from the first access point device to the second access point device;

[0469] The ninth subfield is used to indicate whether an RSNA key update is required when a non-access point device roams from the first access point device or switches to the second access point device;

[0470] The tenth subfield indicates whether the PTKSA needs to be updated before and after seamless roaming.

[0471] In some embodiments, at least two of the fifth, sixth, seventh, eighth, ninth, and tenth subfields are different subfields belonging to the same field.

[0472] In some embodiments, if the tenth subfield indicates that the PTKSA needs to be updated before and after seamless roaming, the first field includes the third subfield and / or the fourth subfield; if the tenth subfield indicates that the PTKSA does not need to be updated before and after seamless roaming, the first field does not include the third subfield and / or the fourth subfield.

[0473] In some embodiments, the first frame is at least one of a roaming notification frame, a roaming request frame, a roaming response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a reassociation request frame, a reassociation response frame, a beacon frame, and a probe response frame.

[0474] The second determining module 810 is further configured to switch the security association for the second access point device during the process of a non-access point device roaming from the first access point device or switching to the second access point device. The first access point device and the second access point device belong to the same seamless roaming domain or the same logical access point multi-link device.

[0475] The second determining module 810 is further configured to, based on the first frame, determine that a different PTKSA is used between the non-access point device and the second access point device during roaming or handover. The different PTKSAs include a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, wherein the fourth PTKSA and the fifth PTKSA are different. Optionally, the fourth PTKSA and the fifth PTKSA are derived from the same PMKSA; or, the fourth PTKSA and the fifth PTKSA are derived from different PMKSAs.

[0476] The second determining module 810 is used to switch to the fourth PTKSA for the second access point device during the process of a non-access point device roaming from the first access point device or switching to the second access point device.

[0477] In some embodiments, the fourth PTKSA is a PTKSA used prior to the seamless roaming or handover process; and / or, the fourth PTKSA is a newly negotiated PTKSA for the seamless roaming or handover process.

[0478] The second determining module 810 is further configured to send the fourth PTKSA to the second access point device via a secure channel if the fourth PTKSA is a PTKSA used before the seamless roaming or handover process.

[0479] The second determining module 810 is further configured to, in the case that the fourth PTKSA is a newly negotiated PTKSA for seamless roaming or handover procedures, initiate an RSNA key update to generate the fourth PTKSA; and send the fourth PTKSA to the second access point device via a secure channel.

[0480] In some embodiments, the fourth PTKSA is derived from the first PMKSA; or, the fourth PTKSA is derived from the second PMKSA. The first PMKSA differs from the second PMKSA; the first PMKSA is generated by the non-access point device before initiating roaming or handover, while the second PMKSA is generated by the non-access point device after initiating roaming or handover and before sending a roaming request frame.

[0481] The second determining module 810 is further configured to migrate the first PMKSA and / or the second PMKSA to the second access point device during the process of the non-access point device roaming from the first access point device or switching to the second access point device.

[0482] In some embodiments, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the seamless roaming domain; or, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the fast transition (FT) four-way handshake process.

[0483] It should be noted that when the device provided in the above embodiments implements its function, the steps performed by the first access point device in the above method embodiments are referred to.

[0484] Figure 17 shows a structural block diagram of a second access point device provided in an exemplary embodiment of this application. The device includes:

[0485] The third determining module 1010 is used to determine, based on the first frame, whether the same security association is used with the non-access point device and the first access point device during roaming or handover, wherein the roaming or handover process is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0486] The third determining module 1010 is also used to determine, based on the first frame, that the same security association is used with the non-access point device and the first access point device during roaming or handover.

[0487] The third determining module 1010 is also used to determine, based on the first frame, that different security associations are used with the non-access point device and the first access point device respectively during roaming or handover.

[0488] In some embodiments, the security association includes at least one of PMKSA, PMK-R0 security association, PMK-R1 security association, PTKSA, GTKSA, and IGTKSA.

[0489] The third determination module 1010 is used to employ a security association specifically designed for seamless roaming or handover processes during the roaming or handover of a non-access point device from a first access point device to a second access point device. The first and second access point devices belong to the same seamless roaming domain or are multi-link devices with the same logical access point.

[0490] The third determining module 1010 is also used to use a first PTKSA for seamless roaming or handover during the process of a non-access point device roaming from a first access point device or handing over to a second access point device.

[0491] The third determining module 1010 is further configured to determine, based on the first frame, that the same PTKSA is used with both the non-access point device and the first access point device during roaming or handover. The same PTKSA includes the first PTKSA.

[0492] In some embodiments, the first PTKSA is generated by the non-access point device and / or the first access point device when initiating an RSNA key update, either before or after initiating roaming or handover. The first PTKSA is different from the PTKSA used before initiating the RSNA key update.

[0493] In some embodiments, the first PTKSA is used for one or more roaming processes of a non-access point device.

[0494] The third determining module 1010 is further configured to receive the first PTKSA from the secure channel and install the first PTKSA when the first access point device receives a roaming request from a non-access point device.

[0495] The third determining module 1010 is also used to install a second PTKSA, which is another PTKSA different from the first PTKSA.

[0496] In some embodiments, the second PTKSA is a PTKSA used before the first PTKSA is installed.

[0497] In some embodiments, the duration between the installation completion time of the second PTKSA and the second time is less than or equal to the second threshold.

[0498] The third determining module 1010 is further configured to initiate RSNA key update to generate a third PTKSA and install the third PTKSA if the duration between the installation completion time of the second PTKSA and the second time is greater than a second threshold.

[0499] In some embodiments, the device further includes:

[0500] The third transceiver module 1020 is used to send and / or receive a first frame, which carries fields related to security associations in seamless roaming.

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

[0502] The first field is used to indicate SRDE;

[0503] The second field is used to indicate RSNE;

[0504] The third field is used to indicate RSNXE;

[0505] The fourth field is used to indicate the FTE;

[0506] The fifth field indicates whether seamless roaming is enabled;

[0507] The sixth field indicates seamless roaming support.

[0508] In some embodiments, the first field includes at least one of the following subfields:

[0509] The first subfield is used to indicate the seamless roaming domain identifier;

[0510] The second subfield is used to indicate the MAC address of the seamless roaming domain;

[0511] The third subfield is used to indicate the first threshold, which is the PTKSA change duration threshold before seamless roaming.

[0512] The fourth subfield is used to indicate the second threshold, which is the PTKSA change duration threshold after seamless roaming;

[0513] The fifth subfield is used to indicate whether seamless roaming between two access point devices in the seamless roaming domain indicated by the first and / or second subfields is enabled or permitted for the non-access point device;

[0514] The sixth subfield is used to indicate whether the non-access point device can communicate with the second access point device through the first access point device;

[0515] The seventh subfield is used to indicate whether data communication context information for non-access point devices is allowed to migrate from the first access point device to the second access point device;

[0516] The eighth subfield is used to indicate whether data packets for non-access point devices are allowed to migrate from the first access point device to the second access point device;

[0517] The ninth subfield is used to indicate whether an RSNA key update is required when a non-access point device roams from the first access point device or switches to the second access point device;

[0518] The tenth subfield indicates whether the PTKSA needs to be updated before and after seamless roaming.

[0519] In some embodiments, at least two of the fifth, sixth, seventh, eighth, ninth, and tenth subfields are different subfields belonging to the same field.

[0520] In some embodiments, if the tenth subfield indicates that the PTKSA needs to be updated before and after seamless roaming, the first field includes the third subfield and / or the fourth subfield; if the tenth subfield indicates that the PTKSA does not need to be updated before and after seamless roaming, the first field does not include the third subfield and / or the fourth subfield.

[0521] In some embodiments, the first frame is at least one of a roaming notification frame, a roaming request frame, a roaming response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a reassociation request frame, a reassociation response frame, a beacon frame, and a probe response frame.

[0522] The third determining module 1010 is used to switch the security association for the second access point device during the process of a non-access point device roaming from the first access point device or switching to the second access point device. The first access point device and the second access point device belong to the same seamless roaming domain or the same logical access point multi-link device.

[0523] The third determining module 1010 is further configured, based on the first frame, to determine that a different PTKSA is used between the non-access point device and the first access point device during roaming or handover. The different PTKSAs include a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, wherein the fourth and fifth PTKSAs are different. Optionally, the fourth and fifth PTKSAs are derived from the same PMKSA; or, the fourth and fifth PTKSAs are derived from different PMKSAs.

[0524] The third determining module 1010 is also used to switch to the fourth PTKSA for the second access point device during the process of the non-access point device roaming from the first access point device or switching to the second access point device.

[0525] In some embodiments, the fourth PTKSA is a PTKSA used prior to the seamless roaming or handover process; and / or, the fourth PTKSA is a newly negotiated PTKSA for the seamless roaming or handover process.

[0526] The third determining module 1010 is also used to receive the fourth PTKSA through a secure channel and to install the fourth PTKSA.

[0527] In some embodiments, the fourth PTKSA is derived from the first PMKSA; or, the fourth PTKSA is derived from the second PMKSA. The first PMKSA differs from the second PMKSA; the first PMKSA is generated by the non-access point device before initiating roaming or handover, while the second PMKSA is generated by the non-access point device after initiating roaming or handover and before sending a roaming request frame.

[0528] The third determining module 1010 is further configured to receive the first PMKSA and / or the second PMKSA during the process of the non-access point device roaming from the first access point device or switching to the second access point device.

[0529] In some embodiments, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the seamless roaming domain; or, the fourth PTKSA is derived from the four-way handshake process between the non-access point device and the second access point device based on the fast transition (FT) four-way handshake process.

[0530] It should be noted that when the device provided in the above embodiments implements its function, the steps performed by the second access point device in the above method embodiments are referred to.

[0531] It should also 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.

[0532] Figure 18 shows a schematic diagram of the structure of a communication device (non-access point device, first access point device, or second access point 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.

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

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

[0535] In some embodiments, when the communication device is implemented as a non-access point device, transceiver 2106 is used to send and / or receive a first frame, the first frame carrying fields related to security association.

[0536] In some embodiments, when the communication device is implemented as a first access point device, transceiver 2106 is used to send and / or receive a first frame, the first frame carrying fields related to security association.

[0537] In some embodiments, when the communication device is implemented as a second access point device, transceiver 2106 is used to send and / or receive a first frame, the first frame carrying fields related to security association.

[0538] The memory 2104 is connected to the processor 2101 via the bus 2105.

[0539] In some embodiments, when the communication device is implemented as a non-access point device, the memory 2104 can be used to store a computer program, and the processor 2101 is used to execute the computer program to implement the various steps performed by the non-access point device in the above method embodiments. For example, the processor 2101 is used to determine, based on a first frame, whether the same security association is used with the first access point device and the second access point device during roaming or handover, where roaming or handover is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0540] In some embodiments, when the communication device is implemented as a first access point device, the memory 2104 can be used to store a computer program, and the processor 2101 is used to execute the computer program to implement the various steps performed by the first access point device in the above method embodiments. For example, the processor 2101 is used to determine, based on a first frame, whether the same security association is used with the non-access point device and the second access point device during roaming or handover, where roaming or handover is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0541] In some embodiments, where the communication device is implemented as a second access point device, the memory 2104 can be used to store a computer program, and the processor 2101 is used to execute the computer program to implement the various steps performed by the second access point device in the above method embodiments. For example, the processor 2101 is used to determine, based on a first frame, whether the same security association is used with both the non-access point device and the first access point device during roaming or handover, where roaming or handover is the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

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

[0543] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor of a non-access point device, a first access point device, or a second access point device to implement the various steps in the above-described communication method.

[0544] 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).

[0545] This application also provides a chip, which includes programmable logic circuits and / or program instructions, and is used to implement the various steps in the above-described communication method when the chip is running on a non-access point device.

[0546] In some embodiments, the chip is used to determine, based on a first frame, whether the same security association is used with the first access point device and the second access point device during roaming or handover, the roaming or handover process being the process by which a non-access point device roams or hands over from the first access point device to the second access point device.

[0547] This application also provides a chip, which includes programmable logic circuits and / or program instructions. When the chip is running on a first access point device, it is used to implement the various steps in the above-described communication method.

[0548] In some embodiments, the chip is used to determine, based on a first frame, whether the same security association is used with the non-access point device and the second access point device during roaming or handover, the roaming or handover process being the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0549] This application also provides a chip, which includes programmable logic circuits and / or program instructions. When the chip is running on a second access point device, it is used to implement the various steps in the above-described communication method.

[0550] In some embodiments, the chip is used to determine, based on a first frame, whether the same security association is used with the non-access point device and the second access point device during roaming or handover, the roaming or handover process being the process by which the non-access point device roams or hands over from the first access point device to the second access point device.

[0551] 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 non-access point device, the first access point device, or the second access point device reads and executes the computer instructions from the computer-readable storage medium to implement the various steps in the above-described communication method.

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

[0553] 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 communication method characterized by comprising: The method is performed by a non-access point device, and the method comprises: determining, based on the first frame, whether to use a same security association with a first access point device and a second access point device in a roaming or switching process, the roaming or switching process being a process in which the non-access point device roams or switches from the first access point device to the second access point device.

2. The method of claim 1, wherein, The determining, based on the first frame, whether to use a same security association with a first access point device and a second access point device in a roaming or switching process comprises: determining, based on the first frame, to use a same security association with the first access point device and the second access point device in the roaming or switching process.

3. The method of claim 2, wherein the security association comprises at least one of a pairwise master key security association (PMKSA), a pairwise master key first level (PMK-R0) security association, a pairwise master key second level (PMK-R1) security association, a pairwise transient key security association (PTKSA), a group transient key security association (GTKSA), and an integrity group transient key security association (IGTKSA).

4. The method according to claim 2 or 3, characterized in that, The determining, based on the first frame, to use a same security association with the first access point device and the second access point device in the roaming or switching process comprises: determining, based on the first frame, to use a same PTKSA with the first access point device and the second access point device in the roaming or switching process.

5. The method of claim 4, wherein, The same PTKSA comprises a first PTKSA, and the method further comprises: starting a robust security network association (RSNA) key update to generate the first PTKSA before or after starting the roaming, the first PTKSA being different from a PTKSA used before starting the RSNA key update.

6. The method of claim 5, wherein, The first PTKSA is used for one or more roaming procedures.

7. The method according to claim 5 or 6, characterized in that, The method further comprises: installing the first PTKSA before sending a roaming request frame; and / or, installing a second PTKSA after receiving a roaming response frame; wherein the second PTKSA is another PTKSA different from the first PTKSA.

8. The method of claim 7, wherein, The second PTKSA is a PTKSA used before installing the first PTKSA, or the second PTKSA is a newly generated PTKSA.

9. The method of claim 7, wherein a time duration between a time of completion of installation of the first PTKSA and a first time is less than or equal to a first threshold; and / or a time duration between a time of completion of installation of the second PTKSA and a second time is less than or equal to a second threshold.

10. The method of claim 9, wherein, In a case where the time duration between the time of completion of installation of the second PTKSA and the second time is greater than the second threshold, the method further comprises: starting a RSNA key update to generate a third PTKSA; and installing the third PTKSA.

11. The method of claim 9, wherein, In a case where the time duration between the time of completion of installation of the first PTKSA and the first time is greater than the first threshold, the method further comprises: updating the first PTKSA to a fourth PTKSA, the fourth PTKSA being a PTKSA for the second access point device.

12. The method of claim 1, wherein, determining, based on the first frame, whether to use a same security association with the first access point device and the second access point device during the roaming or switching process, comprises: determining, based on the first frame, to use different security associations with the first access point device and the second access point device respectively during the roaming or switching process.

13. The method of claim 12, wherein: the security associations comprise at least one of a PMKSA, a PMK-R0 security association, a PMK-R1 security association, a PTKSA, a GTKSA, and an IGTKSA.

14. The method according to claim 12 or 13, characterized in that, determining, based on the first frame, to use different security associations with the first access point device and the second access point device respectively during the roaming or switching process, comprises: determining, based on the first frame, to use different PTKSAs with the first access point device and the second access point device respectively during the roaming or switching process.

15. The method of claim 14, wherein, the different PTKSAs comprise a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, the fourth PTKSA and the fifth PTKSA being different, the method further comprising: switching to use the fourth PTKSA for the second access point device during the roaming or switching process.

16. The method of claim 15, wherein: the fourth PTKSA and the fifth PTKSA are derived from a same PMKSA; or, the fourth PTKSA and the fifth PTKSA are derived from different PMKsAs.

17. The method of claim 15 or 16, wherein: the fourth PTKSA is a newly negotiated PTKSA during the roaming or switching process.

18. The method of claim 17, wherein, the method further comprises: requesting, before sending the roaming request frame or through the roaming request frame or after sending the roaming request frame, the first access point device to initiate a RSNA key update to generate the fourth PTKSA, and requesting the first access point device to send the fourth PTKSA to the second access point device through a secure channel.

19. The method of claim 15 or 16, wherein: the fourth PTKSA is derived from a first PMKSA; or, the fourth PTKSA is derived from a second PMKSA; wherein the first PMKSA and the second PMKSA are different, the first PMKSA being generated by the non-access point device before initiating the roaming, and the second PMKSA being generated by the non-access point device after initiating the roaming and before sending the roaming request frame.

20. The method of claim 19, wherein, the method further comprises: requesting, during the roaming or switching process, the first access point device to migrate the first PMKSA and / or the second PMKSA to the second access point device.

21. The method of claim 19 or 20, wherein: The fourth PTKSA is derived by the non-access point device and the second access point device based on a 4-way handshake procedure of a seamless roaming domain; or The fourth PTKSA is derived by the non-access point device and the second access point device based on a fast transition (FT) 4-way handshake procedure.

22. The method of any one of claims 1 to 21, wherein, The method further comprises: sending and / or receiving the first frame, the first frame carrying a field related to the security association.

23. The method of claim 22, wherein, The first frame comprises at least one of the following fields: a first field for indicating a seamless roaming domain element (SRDE); a second field for indicating a robust security network element (RSNE); a third field for indicating a robust security network extension element (RSNXE); a fourth field for indicating a fast transition element (FTE); a fifth field for indicating seamless roaming enablement; a sixth field for indicating seamless roaming support.

24. The method of claim 23, wherein, The first field comprises at least one of the following subfields: a first subfield for indicating a seamless roaming domain identification; a second subfield for indicating a seamless roaming domain medium access control (MAC) address; a third subfield for indicating a first threshold, the first threshold being a PTKSA change duration threshold before seamless roaming; a fourth subfield for indicating a second threshold, the second threshold being a PTKSA change duration threshold after seamless roaming; a fifth subfield for indicating whether seamless roaming between two access point devices in the seamless roaming domain indicated by the first subfield and / or the second subfield is allowed for the non-access point device; a sixth subfield for indicating whether communication between the first access point device and the second access point device is allowed for the non-access point device; a seventh subfield for indicating whether data communication context information for the non-access point device is allowed to be migrated from the first access point device to the second access point device; an eighth subfield for indicating whether data packets for the non-access point device are allowed to be migrated from the first access point device to the second access point device; a ninth subfield for indicating whether RSNA key update is needed when the non-access point device roams or hands over from the first access point device to the second access point device; a tenth subfield for indicating whether PTKSA before and after seamless roaming needs to be updated.

25. The method of claim 24, wherein, At least two of the fifth subfield, the sixth subfield, the seventh subfield, the eighth subfield, the ninth subfield, and the tenth subfield are different subfields of the same field.

26. The method of claim 24 or 25, wherein in a case where the tenth subfield indicates that PTKSA before and after seamless roaming needs to be updated, the first field comprises the third subfield and / or the fourth subfield; in a case where the tenth subfield indicates that PTKSA before and after seamless roaming does not need to be updated, the first field does not comprise the third subfield and / or the fourth subfield.

27. The method of any of claims 22 to 26, wherein The first frame is at least one of a roam notification frame, a roam request frame, a roam response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a re-association request frame, a re-association response frame, a beacon frame, and a probe response frame.

28. The method of any one of claims 1 to 27, wherein, The first access point device and the second access point device belong to a same seamless roaming domain or a same logical access point multi-link device.

29. A method of communication, comprising: The method is performed by a first access point device, and the method comprises: determining, based on a first frame, whether to use a same security association with a non-access point device and a second access point device in a roaming or switching process, the roaming or switching process being a process in which the non-access point device roams or switches from the first access point device to the second access point device.

30. The method of claim 29, wherein, The determining, based on the first frame, whether to use the same security association with the non-access point device and the second access point device in the roaming or switching process comprises: determining, based on the first frame, to use the same security association with the non-access point device and the second access point device in the roaming or switching process.

31. The method of claim 30, wherein: The security association comprises at least one of a PMKSA, a PMK-R0 security association, a PMK-R1 security association, a PTKSA, a GTKSA, and an IGTKSA.

32. The method of claim 30 or 31, wherein, The determining, based on the first frame, to use the same security association with the non-access point device and the second access point device in the roaming or switching process comprises: determining, based on the first frame, to use a same PTKSA with the non-access point device and the second access point device in the roaming or switching process.

33. The method of claim 32, wherein, The same PTKSA comprises a first PTKSA, and the method further comprises: starting an RSNA key update to generate the first PTKSA before or after the non-access point device starts roaming, the first PTKSA being different from a PTKSA used before the RSNA key update is started.

34. The method of claim 33, wherein, The first PTKSA is used for one or more roaming procedures of the non-access point device.

35. The method of claim 33 or 34, wherein, The method further comprises: installing the first PTKSA before receiving the roam request frame.

36. The method of claim 35, wherein: a time duration between a time when the installation of the first PTKSA is completed and a first time is less than or equal to a first threshold.

37. The method of claim 36, wherein, In a case where the time duration between the time when the installation of the first PTKSA is completed and the first time is greater than the first threshold, the method further comprises: rejecting a roam request of the non-access point device; and / or, updating the first PTKSA to a fourth PTKSA, the fourth PTKSA being a PTKSA for the second access point device.

38. The method of any one of claims 33 to 37, wherein, The method further comprises: in a case where the first access point device accepts the roam request of the non-access point device, sending the first PTKSA to the second access point device through a secure channel.

39. The method of claim 29, wherein, The determining, based on the first frame, whether to use the same security association with the non-access point device and the second access point device in the roaming or switching process comprises: determine, based on the first frame, to use different security associations with the non-access point device and the second access point device respectively during the roaming or switching process.

40. The method of claim 39, wherein, the security associations comprise at least one of a PMKSA, a PMK-R0 security association, a PMK-R1 security association, a PTKSA, a GTKSA, and an IGTKSA.

41. The method of claim 39 or 40, wherein, the determining, based on the first frame, to use different security associations with the non-access point device and the second access point device respectively during the roaming or switching process comprises: determining, based on the first frame, to use different PTKSAs with the non-access point device and the second access point device respectively during the roaming or switching process.

42. The method of claim 41, wherein, the different PTKSAs comprise a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, the fourth PTKSA and the fifth PTKSA being different, the method further comprising: switching, during the roaming or switching process, to use the fourth PTKSA for the second access point device.

43. The method of claim 42, wherein, the fourth PTKSA and the fifth PTKSA are derived from a same PMKSA; or, the fourth PTKSA and the fifth PTKSA are derived from different PMKsAs.

44. The method of claim 42 or 43, wherein, the fourth PTKSA is a newly negotiated PTKSA during the roaming or switching process.

45. The method of claim 44, wherein, the method further comprises: initiating a RSNA key update to generate the fourth PTKSA; and sending the fourth PTKSA to the second access point device over a secure channel.

46. The method of claim 42 or 43, wherein, the fourth PTKSA is derived from a first PMKSA; or, the fourth PTKSA is derived from a second PMKSA; wherein the first PMKSA and the second PMKSA are different, the first PMKSA is generated by the non-access point device before initiating the roaming, and the second PMKSA is generated by the non-access point device after initiating the roaming and before sending the roaming request frame.

47. The method of claim 46, wherein, the method further comprises: migrating the first PMKSA and / or the second PMKSA to the second access point device during the roaming or switching process.

48. The method of claim 46 or 47, wherein, the fourth PTKSA is derived by the non-access point device and the second access point device based on a 4-way handshake procedure of a seamless roaming domain; or, the fourth PTKSA is derived by the non-access point device and the second access point device based on a 4-way handshake procedure of a fast transition (FT).

49. The method of any one of claims 29 to 48, wherein, the method further comprises: sending and / or receiving the first frame, the first frame carrying a field related to the security associations.

50. The method of claim 49, wherein, the first frame comprises at least one of the following fields: a first field for indicating an SRDE; a second field for indicating an RSNE; a third field for indicating an RSNXE; a fourth field for indicating an FTE; a fifth field for indicating seamless roaming enablement; a sixth field for indicating seamless roaming support.

51. The method of claim 50, wherein, The first field comprises at least one of the following subfields: a first subfield for indicating a seamless roaming domain identity; a second subfield for indicating a seamless roaming domain MAC address; a third subfield for indicating a first threshold, the first threshold being a PTKSA change duration threshold before seamless roaming; a fourth subfield for indicating a second threshold, the second threshold being a PTKSA change duration threshold after seamless roaming; a fifth subfield for indicating whether the non-access point device is allowed to seamlessly roam between two access point devices in the seamless roaming domain indicated by the first subfield and / or the second subfield; a sixth subfield for indicating whether the non-access point device is allowed to communicate with the second access point device through the first access point device; a seventh subfield for indicating whether data communication context information for the non-access point device is allowed to be migrated from the first access point device to the second access point device; an eighth subfield for indicating whether data packets for the non-access point device are allowed to be migrated from the first access point device to the second access point device; a ninth subfield for indicating whether RSNA key update is required when the non-access point device roams or switches from the first access point device to the second access point device; a tenth subfield for indicating whether PTKSA before and after seamless roaming needs to be updated.

52. The method of claim 51, wherein, At least two of the fifth subfield, the sixth subfield, the seventh subfield, the eighth subfield, the ninth subfield, and the tenth subfield are different subfields of the same field.

53. The method of claim 51 or 52, wherein, in a case where the tenth subfield indicates that PTKSA before and after seamless roaming needs to be updated, the first field comprises the third subfield and / or the fourth subfield; in a case where the tenth subfield indicates that PTKSA before and after seamless roaming does not need to be updated, the first field does not comprise the third subfield and / or the fourth subfield.

54. The method of any of claims 49 to 53, wherein, the first frame is at least one of a roam notification frame, a roam request frame, a roam response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a re-association request frame, a re-association response frame, a beacon frame, and a probe response frame.

55. The method of any one of claims 29 to 54, wherein, The first access point device and the second access point device belong to the same seamless roaming domain or the same logical access point multi-link device.

56. A method of communication, comprising: The method is performed by a second access point device, and the method comprises: determine, based on the first frame, whether a same security association is used with the non-access point device and the first access point device during a roaming or switching procedure, the roaming or switching procedure being a procedure in which the non-access point device roams or switches from the first access point device to the second access point device.

57. The method of claim 56, wherein, The determining, based on the first frame, whether a same security association is used with the non-access point device and the first access point device during a roaming or switching procedure includes: determining, based on the first frame, that a same security association is used with the non-access point device and the first access point device during the roaming or switching procedure.

58. The method of claim 57, wherein The security association includes at least one of a PMKSA, a PMK-R0 security association, a PMK-R1 security association, a PTKSA, a GTKSA, and an IGTKSA.

59. The method of claim 57 or 58, wherein, The determining, based on the first frame, that a same security association is used with the non-access point device and the first access point device during the roaming or switching procedure includes: determining, based on the first frame, that a same PTKSA is used with the non-access point device and the first access point device during the roaming or switching procedure.

60. The method of claim 59, wherein, The same PTKSA includes a first PTKSA, the first PTKSA being generated by the non-access point device and / or the first access point device prior to or after the non-access point device initiates roaming, the first PTKSA being different from a PTKSA used prior to the initiation of the RSNA key update.

61. The method of claim 60, wherein, The first PTKSA is used for one or more roaming procedures of the non-access point device.

62. The method of claim 60 or 61, wherein, The method further includes: receiving the first PTKSA from a secure channel in a case where the first access point device accepts a roaming request of the non-access point device; installing the first PTKSA.

63. The method of any one of claims 60 to 62, wherein, The method further includes: installing a second PTKSA after the roaming of the non-access point device ends, the second PTKSA being another PTKSA different from the first PTKSA.

64. The method of claim 63, wherein, The second PTKSA is a PTKSA used prior to the installation of the first PTKSA, or the second PTKSA is a newly generated PTKSA.

65. The method of claim 64, wherein a time duration between a time of completion of the installation of the second PTKSA and the second time is less than or equal to a second threshold.

66. The method of claim 65, wherein, In a case where the time duration between the time of completion of the installation of the second PTKSA and the second time is greater than the second threshold, the method further includes: initiating a RSNA key update to generate a third PTKSA; installing the third PTKSA.

67. The method of claim 56, wherein, The determining, based on the first frame, whether a same security association is used with the non-access point device and the first access point device during a roaming or switching procedure includes: determining, based on the first frame, that different security associations are used with the non-access point device and the first access point device, respectively, during the roaming or switching procedure.

68. The method of claim 67, wherein The security association comprises at least one of a PMKSA, a PMK-R0 security association, a PMK-R1 security association, a PTKSA, a GTKSA, and an IGTKSA.

69. The method of claim 67 or 68, wherein, The determining, based on the first frame, that different security associations are used in the roaming or switching process with the non-access point device and the first access point device respectively comprises: The determining, based on the first frame, that different PTKSAs are used in the roaming or switching process with the non-access point device and the first access point device respectively comprises:

70. The method of claim 69, wherein, The different PTKSAs comprise a fourth PTKSA for the second access point device and a fifth PTKSA for the first access point device, the fourth PTKSA and the fifth PTKSA being different, and the method further comprises: Switching, in the roaming or switching process, to use the fourth PTKSA for the second access point device.

71. The method of claim 70, wherein: The fourth PTKSA and the fifth PTKSA are derived from a same PMKSA; or The fourth PTKSA and the fifth PTKSA are derived from different PMKsAs.

72. The method of claim 70 or 71, wherein: The fourth PTKSA is a newly negotiated PTKSA in the roaming or switching process.

73. The method of claim 72, wherein, The method further comprises: receiving the fourth PTKSA over a secure channel; and installing the fourth PTKSA.

74. The method of claim 70 or 71, wherein: The fourth PTKSA is derived from a first PMKSA; or The fourth PTKSA is derived from a second PMKSA; wherein the first PMKSA and the second PMKSA are different, the first PMKSA is generated by the non-access point device before initiating roaming, and the second PMKSA is generated by the non-access point device after initiating roaming and before sending the roaming request frame.

75. The method of claim 74, wherein, The method further comprises: receiving the first PMKSA and / or the second PMKSA during the roaming of the non-access point device from the first access point device to the second access point device.

76. The method of claim 74 or 75, wherein: The fourth PTKSA is derived by the non-access point device and the second access point device based on a 4-way handshake procedure of a seamless roaming domain; or The fourth PTKSA is derived by the non-access point device and the second access point device based on a 4-way handshake procedure of a fast transition (FT).

77. The method of any one of claims 56 to 76, wherein, The method further comprises: sending and / or receiving the first frame, the first frame carrying a field related to the security association.

78. The method of claim 77, wherein, The first frame comprises at least one of: a first field indicating an SRDE; a second field indicating an RSNE; a third field indicating an RSNXE; a fourth field indicating an FTE; a fifth field indicating seamless roaming enablement; and a sixth field indicating seamless roaming support.

79. The method of claim 78, wherein, The first field comprises at least one of the following subfields: a first subfield for indicating a seamless roaming domain identity; a second subfield for indicating a seamless roaming domain MAC address; a third subfield for indicating a first threshold, the first threshold being a PTKSA change duration threshold before seamless roaming; a fourth subfield for indicating a second threshold, the second threshold being a PTKSA change duration threshold after seamless roaming; a fifth subfield for indicating whether seamless roaming between two access point devices in the seamless roaming domain indicated by the first subfield and / or the second subfield is allowed for the non-access point device; a sixth subfield for indicating whether communication between the first access point device and the second access point device is allowed for the non-access point device; a seventh subfield for indicating whether data communication context information for the non-access point device is allowed to be migrated from the first access point device to the second access point device; an eighth subfield for indicating whether data packets for the non-access point device are allowed to be migrated from the first access point device to the second access point device; a ninth subfield for indicating whether RSNA key update is required when the non-access point device roams or switches from the first access point device to the second access point device; a tenth subfield for indicating whether PTKSA before and after seamless roaming needs to be updated.

80. The method of claim 79, wherein, At least two of the fifth subfield, the sixth subfield, the seventh subfield, the eighth subfield, the ninth subfield, and the tenth subfield are different subfields of the same field.

81. The method of claim 79 or 80, wherein, in a case where the tenth subfield indicates that PTKSA before and after seamless roaming needs to be updated, the first field comprises the third subfield and / or the fourth subfield; in a case where the tenth subfield indicates that PTKSA before and after seamless roaming does not need to be updated, the first field does not comprise the third subfield and / or the fourth subfield.

82. The method of any of claims 77 to 81, wherein, the first frame is at least one of a roam notification frame, a roam request frame, a roam response frame, a link reconfiguration notification frame, a link reconfiguration request frame, a link reconfiguration response frame, an association request frame, an association response frame, a re-association request frame, a re-association response frame, a beacon frame, and a probe response frame.

83. The method of any one of claims 56 to 82, wherein, the first access point device and the second access point device belong to a same seamless roaming domain or a same logical access point multi-link device.

84. A non-access point apparatus, comprising: The apparatus comprises: a first determining module configured to determine, based on a first frame, whether a same security association is used with a first access point device and a second access point device during a roaming or switching process, the roaming or switching process being a process in which a non-access point device roams or switches from the first access point device to the second access point.

85. A first access point apparatus, comprising: The apparatus comprises: The second determining module is configured to determine, based on the first frame, whether a same security association is used with the non-access point device and the second access point device during a roaming or switching process, the roaming or switching process being a process in which the non-access point device roams or switches from the first access point device to the second access point device.

86. An apparatus for a second access point, the apparatus comprising: The apparatus comprises: The third determining module is configured to determine, based on the first frame, whether a same security association is used with the non-access point device and the first access point device during a roaming or switching process, the roaming or switching process being a process in which the non-access point device roams or switches from the first access point device to the second access point device.

87. A non-access point device, comprising: The non-access point device comprises: a processor; a transceiver connected to the processor; a memory for storing executable instructions of the processor; wherein the processor is configured to load and execute the executable instructions to implement the communication method according to any one of claims 1 to 28.

88. A first access point device, comprising: The first access point device comprises: a processor; a transceiver connected to the processor; a memory for storing executable instructions of the processor; wherein the processor is configured to load and execute the executable instructions to implement the communication method according to any one of claims 29 to 55.

89. A second access point device, comprising: The second access point device comprises: a processor; a transceiver connected to the processor; a memory for storing executable instructions of the processor; wherein the processor is configured to load and execute the executable instructions to implement the communication method according to any one of claims 56 to 83.

90. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which is configured to be executed by a processor of a non-access point device to implement the communication method according to any one of claims 1 to 28.

91. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which is configured to be executed by a processor of a first access point device to implement the communication method according to any one of claims 29 to 55.

92. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which is configured to be executed by a processor of a second access point device to implement the communication method according to any one of claims 56 to 83.

93. A chip, characterized by The chip comprises programmable logic circuit and / or program instructions, which are configured to implement the above-mentioned communication method according to any one of claims 1 to 28 when the chip is running on a non-access point device.

94. A chip, comprising: The chip comprises programmable logic circuit and / or program instructions, which are configured to implement the above-mentioned communication method according to any one of claims 29 to 55 when the chip is running on a first access point device.

95. A chip, comprising: The chip comprises programmable logic circuit and / or program instructions, which are configured to implement the above-mentioned communication method according to any one of claims 56 to 83 when the chip is running on a second access point device.

96. A computer program product, characterized in that, The computer program product comprises computer instructions stored in a computer readable storage medium, which are read by a processor of the non-access point device and executed, causing the non-access point device to implement the communication method as claimed in any of claims 1-28.

97. A computer program product, characterized in that, The computer program product comprises computer instructions stored in a computer readable storage medium, which are read by a processor of the first access point device and executed, causing the first access point device to implement the communication method as claimed in any of claims 29-55.

98. A computer program product, characterized in that, The computer program product comprises computer instructions stored in a computer readable storage medium, which are read by a processor of the second access point device and executed, causing the second access point device to implement the communication method as claimed in any of claims 56-83.

99. A computer program, characterized in that, The computer program, when executed by a processor of the non-access point device, is for implementing the communication method as claimed in any of claims 1-28.

100. A computer program, characterized in that, The computer program, when executed by a processor of the first access point device, is for implementing the communication method as claimed in any of claims 29-55.

101. A computer program, characterized in that, The computer program, when executed by a processor of the second access point device, is for implementing the communication method as claimed in any of claims 56-83.

Images