TWI794881B - Wireless communication method and apparatus for multi-link - Google Patents

Abstract

The present invention provides a wireless communication method and apparatus for multi-link. An access point (AP) multi-link device (MLD) and a non-AP station (STA) MLD perform a fast initial link setup (FILS) procedure to establish wireless communications over a plurality of links. The AP MLD and the non-AP STA MLD communicate over one or more links of the plurality of links upon completion of the FILS procedure with a FILS Discovery frame transmitted in the FILS procedure indicating whether a service set identifier (SSID) of the AP MLD is different from a SSID of an AP of a plurality of APs in the AP MLD transmitting the FILS Discovery frame.

Description

Multi-link wireless communication method and device

The present invention relates to wireless communication, and more particularly, to an extreme-high-throughput (EHT) fast initial link setup in multi-link operation (multi-link operation) in wireless communication , FILS) support.

Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims claimed and are not admitted to be prior art by inclusion in this section.

In a wireless local area network (wireless local area network, WLAN), a station (STA) needs to first discover an access point (access point, AP) to establish communication (eg, send and receive data) with the AP. Under the current Institute of Electrical and Electronics Engineers (Institute of Electrical and Electronics Engineers, IEEE) 802.11 specification, an AP can broadcast a FILS discovery beacon, so as to facilitate STAs to discover the AP within a communication range to establish a communication link with the AP. Link establishment usually includes discovery (discovery) process, authentication (authentication) process and association (association) process. The FILS discovery frame (discovery frame) is used in a known process. However, when the AP is an AP multi-link device (MLD) and/or the STA is a STA MLD, some modifications need to be made to the FILS discovery frame as currently defined in order to support multi-link operation. For example, for the AP MLD, although the AP in the AP MLD has its own service set identifier (service set identifier, SSID), the AP MLD may have an MLD-level (MLD-level) SSID different from the SSID of the AP. Therefore, the currently defined FILS discovery frames need to be modified to indicate such information. Additionally, some modifications to the current IEEE specification are required to support EHT FILS in multilink operation.

The following summary is exemplary only and is not intended to be limiting in any way. That is, the following summary is provided to introduce the concepts, highlights, benefits and advantages of the novel and non-obvious technologies described herein. Selected implementations are further described in the detailed description below. Accordingly, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

The object of the present invention is to provide solutions, concepts, designs, techniques, methods and devices related to EHT FILS support in multi-link operation in wireless communication. Under various proposals according to the invention, the problems described here can be solved.

In one aspect, a multi-link wireless communication method is provided, which includes: performing a Fast Initial Link Establishment (FILS) procedure to establish an access point (AP) multi-link device (MLD) and Establishing wireless communication between the non-AP stations STA MLD; and performing communication through one or more links in the plurality of links after completing the FILS process. Wherein, the FILS discovery frame sent in the FILS process indicates whether the SSID of the AP MLD is different from the SSID of the AP that sends the FILS discovery frame among multiple APs in the AP MLD.

In another aspect, a multi-link wireless communication apparatus is provided that includes a transceiver configured for wireless communication and a processor coupled to the transceiver. And the processor is configured to perform the following operations: execute a FILS procedure via the transceiver to establish wireless communication between the AP MLD and the non-AP STA MLD on multiple links; and after completing the FILS procedure, via the The transceiver communicates over one or more of the plurality of links. Wherein, the FILS discovery frame sent in the FILS process indicates whether the SSID of the AP MLD is different from the SSID of the AP sending the FILS discovery frame among the multiple APs of the AP MLD.

Through the present invention, support for fast initial link setup (FILS) in multi-link operation (extreme-high-throughput, EHT) in wireless communication can be realized.

It is worth noting that while the description provided here can be made in the context of certain radio access technologies, networks and network topologies (e.g. Wi-Fi), e.g. Long-Term Evolution (LTE), LTE-A , LTE-A Pro, 5G, New Radio (New Radio, NR), Internet-of-Things (IoT), Narrow Band Internet of Things (NB-IoT) and Industrial Internet of Things (Industrial Internet of Things, IIoT), the proposed concepts, solutions and any variants/derivatives thereof can be implemented in, for and through other types of radio access technologies, networks and network topologies. Accordingly, the scope of the present invention is not limited to the examples described herein.

Detailed embodiments and implementations of the claimed subject matter are disclosed herein. It should be understood, however, that the detailed embodiments and implementations disclosed are merely illustrative of the various forms in which the claimed subject matter can be embodied. This invention may, however, be embodied in many different forms and should not be construed as limited to only the illustrated embodiments and implementations. These exemplary embodiments and implementations are provided so that this description of the present invention will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art. In the following description, details of known features and techniques are omitted to avoid unnecessarily obscuring the embodiments and implementations of the invention. overview

Implementations of the present invention relate to various techniques, methods, schemes and/or solutions related to EHT FILS support in multi-link operation in wireless communications. According to the invention, many possible solutions can be realized individually or in combination. That is, although these possible solutions may be described separately below, two or more of these possible solutions may be implemented in one combination or another.

Figure 1 illustrates an example network environment 100 in which various solutions and schemes according to the present invention may be implemented. Figures 2 to 12 illustrate examples of implementations of various proposed solutions in a networked environment 100 according to the present invention. The following description of various proposed solutions is provided with reference to FIGS. 1-12 .

Referring to FIG. 1, network environment 100 may include STA 110 and STA 120. STA 110 and STA 120 may operate on multiple links (e.g., link communicate wirelessly on Link 1, Link 2, and Link 3). Each of STA 110 and STA 120 can function as an MLD. For example, STA 110 may function as a non-AP MLD with multiple virtual STAs operating within STA 110 (eg, STA 1, STA 2, and STA 3). Accordingly, STA 120 may function as an AP MLD with multiple virtual APs (eg, AP 1 , AP 2 and AP 3 ) operating within STA 120 . Under various proposed schemes according to the present invention, STA 110 and STA 120 may be configured to perform EHT FILS support in multi-link operation in wireless communication according to various proposed schemes described herein.

FIG. 2 illustrates an example design 200 of a FILS discovery frame under the proposed scheme according to the present invention. Referring to part (A) of FIG. 2 , the FILS discovery frame may include various information fields, wherein the various information fields include a FILS discovery information (FILS Discovery Information) field. Referring to part (B) of FIG. 2 , in each information subfield of the FILS discovery information field, there is a FILS discovery capability (FILS Discovery (FD) Capability) subfield. The FD Capability subfield may include several subfields, including a Multiple Links Presence Indicator (Multiple Links Presence Indicator) subfield, which may indicate whether the AP (e.g., STA 120) that sent the FILS discovery frame acts as an AP MLD. Some support multi-link operation. For example, the Multiple Links Presence Indicator subfield can be set to 1 to indicate the presence of a Multiple Links element in Beacon and Probe Response frames. On the other hand, the multilink presence indicator subfield can be set to 0 to indicate that there is no multilink element in the Beacon and Probe Response frames.

FIG. 3 illustrates an example design 300 of the FD capability subfield under the proposed scheme according to the present invention. Referring to FIG. 3, the FD capability subfield may include multiple subfields, including a multilink presence indicator subfield. Under the proposed scheme, when the multi-link presence indicator subfield in the FD capability subfield of the FILS discovery information field is set to 1 and the AP MLD has a connection with the AP (e.g., STA) that sent the FILS discovery frame If the SSID of AP1, AP2 or AP3) of 120 is different from the AP MLD SSID, the FILS discovery information field may further include a short MLD SSID subfield, as shown in part (B) of FIG. 2 . The Short MLD SSID subfield MAY contain the 4-octet Short SSID of the AP MLD (eg, as defined in Section 9.4.2.170 (Reduced Neighbor Report element) of the IEEE specification).

Under the proposed solution on higher-layer protocol (higher-layer protocol, HLP) encapsulation (HLP) encapsulation according to the present invention, the FILS HLP container (Container) element can be used to encapsulate the HLP package. Under the proposed scheme, where a non-AP STA MLD (eg, STA 110) uses HLP encapsulation, the non-AP STA MLD can construct a FILS HLP container element for each HLP packet. The non-AP STA MLD can then place multiple FILS HLP container elements into an Association (or Reassociation) Request frame as long as they are suitable for Medium Access Control (MAC) management The size limit of the protocol data unit (MAC Management Protocol Data Unit, MMPDU). An HLP packet within a FILS HLP container element MAY contain any MAC Service Data Unit (MSDU) format (eg, as defined in Section 5.1.4 (MSDU format) of the IEEE specification). Under the proposed scheme, the encapsulation process may involve the non-AP STA MLD filling one or more FILS HLP container elements with the destination MAC address, the source MAC address of the HLP packet, and the HLP packet in MSDU format. The source MAC address may be the MLD MAC address of the non-AP STA MLD. The encapsulation process may also involve the non-AP STA MLD including the FILS HLP container element into the association (or reassociation) request frame.

Under the proposed scheme, in case the AP MLD (e.g., STA 120) receives an association (or re-association) request frame including a FILS HLP container element, the AP MLD can decapsulate the HLP packet, but in The HLP packet will not be transmitted until key confirmation (eg, as defined in Section 12.12.2.6 (Key confirmation with FILS authentication) of the IEEE specification) has been successfully completed. After the key confirmation is successful, the AP MLD can forward the HLP packet to the upstream network (upstream network) or basic service set (basic service set, BSS) according to the destination MAC address of the HLP packet. The order in which the HLP packets are forwarded can be the same as the order of the FILS HLP container elements in the associate (or reassociate) request frame. If the confirmation of the key fails, the AP MLD can discard the HLP packet, and the AP MLD can also filter the HLP packet according to certain rules.

Under the proposed scheme, the packet decapsulation process for each FILS HLP container element may include the AP MLD extracting the destination MAC address, source MAC address, and HLP packet from a given FILS HLP container element. The process may then include the AP verifying that the extracted source MAC address is equal to the MLD MAC address of the non-AP STA MLD (eg, STA 110 ) associated with the source MAC address of the association (or re-association) request frame. If these addresses differ, the AP MAY discard the FILS HLP container element. Next, the process may include the AP using the extracted destination MAC address, the extracted source MAC address, and the HLP packet to frame the HLP packet in an appropriate format to transmit the HLP packet to the upstream network or BSS.

Under the proposed scheme, after receiving an association (or re-association) request frame, the AP MLD may wait to send an association (or re-association) response frame until a predefined duration such as dot11HLPWaitTime has elapsed. If the AP MLD receives one or more HLP packets from the upstream network or BSS before sending the Association (or Re-Association) Response frame, where the upstream network or BSS uses the MLD MAC address or group address of the AP STA MLD ( group address) as the destination address, the AP MLD can send each HLP packet in a different FILS HLP container element in the association (or reassociation) response frame. The order of the FILS HLP container elements in the associated (or reassociated) response frame can be the same as the order in which the HLP packets were received. If the AP MLD receives an HLP packet from a non-AP STA MLD after sending an association (or re-association) response frame, the AP MLD may send the HLP packet as a data frame. If the AP does not receive any HLP packet from the upstream network or BSS with the destination address of the MLD MAC address or group address of the non-AP STA MLD before sending the association (or re-association) response frame, the AP MLD is not in association ( or reassociate) response frame to send any FILS HLP container element. Under the proposed scheme, the status code in the association (or reassociation) response frame can be independent of the presence or absence of the FILS HLP container element.

Under the proposed scheme regarding HLP encapsulation according to the present invention, the encapsulation process of AP MLD (eg, STA 120 ) for each FILS HLP container element may include certain operations. First, AP MLD can somehow set the fields of the HLP container element. For example, the AP MLD may set the Destination MAC Address (Destination MAC Address) field to the destination MAC address of the received HLP packet, and the destination MAC address may be the MLD MAC address of a non-AP STA MLD (for example, STA 110) or group address. If the destination MAC address of the received HLP packet is different from the MLD MAC address of the non-AP STA MLD, but equal to one of the non-AP STA MLD's wireless medium (WM) MAC addresses, the destination MAC address field Can be set to the MLD MAC address of the non-AP STA MLD. In addition, the AP MLD can set the source MAC address field to the source MAC address of the received HLP packet. In addition, the AP MLD can set the HLP packet field (HLP Packet field) as an HLP packet in MSDU format. The AP MLD can then include the FILS HLP container element in the Association (or Reassociation) Response Frame. Next, the AP MLD can send an Associate (or Re-Associate) Response frame.

Under the proposed scheme regarding HLP encapsulation according to the present invention, if a non-AP STA MLD (eg, STA 110) receives an Association (or Re-Association) Response frame with one or more FILS HLP container elements, the non-AP STA MLD can perform key confirmation first. After the key confirmation is successful, the non-AP STA MLD can generate the MA-UNITDATA.indication primitive (primitive) for each HLP packet. The order of the MA-UNITDATA.indication primitives generating the HLP packet may be the same as the order of the FILS HLP container elements in the associated (or reassociated) response frame. In case of key validation failure, the non-AP STA MLD may discard the HLP packet.

Under the proposed scheme regarding HLP encapsulation according to the present invention, the encapsulation decapsulation process of the non-AP STA MLD (eg, STA 110 ) for each FILS HLP container element may include certain operations. First, the non-AP STA MLD can extract the destination MAC address, source MAC address and HLP packet. The non-AP STA MLD may then verify whether the extracted destination MAC address is equal to the non-AP STA MLD's MLD MAC address or group address. The non-AP STA MLD may discard the FILS HLP container element if the destination MAC address is not for the non-AP STA MLD. Next, the non-AP STA MLD may generate a MA-UNITDATA.indication primitive with multiple parameters including, for example but not limited to: source address (extracted source MAC address), destination address (extracted destination MAC address) address), routing information (all), data (extracted HLP packets), receive status (success), priority (competition) and service class (which can be a Quality of Service Acknowledgment (QoSAck) when the destination address is a single address) , or it can be a Quality of Service Negative Acknowledgment (QoSNoAck) when the target address is not a single address).

Under the proposed scheme on the FILS Public Key (Public Key) element according to the present invention, all APs in the AP MLD (for example, AP1, AP2 and AP3 in STA 120) can connect 1, 2 and 3) and all non-AP STAs in the non-AP STA MLD (for example, STA1, STA2 and STA3 in STA 110) can use it in multiple links a public key. Under the proposed scheme, the Diffie-Hellman values in all APs in the AP MLD can be common across multiple links. Similarly, Diffie-Hellman values in all non-AP STAs in the non-AP STA MLD may be common across multiple links.

Under the proposed scheme, the FILS Public Key element can be used to convey a device's (certified) public key for use with a FILS authentication exchange. Fig. 4 illustrates an example design 400 of a FILS public key element under the proposed scheme. Referring to Figure 4, the FILS public key element may include an element ID (Element ID) field, a length (Length) field and an element ID extension (Element ID Extension) field (for example, as in section 9.4.2.1 of the IEEE specification as defined in (General). The FILS Public Key element may also include a Key Type field with different values. For example, the key type field can be set to 1 to indicate that the FILS public key field contains X.509v3 encoded according to Internet Engineering Task Force (IETF) Request for Comments (RFC) 5280 Certificate. The KeyType field can be set to 2 to indicate that the FILS PublicKey field contains an uncertified public key encoded according to IETF RFC 5480. The KeyType field can be set to 3 to indicate that the FILS PublicKey field contains an uncertified public key encoded according to IETF RFC 3279. The values 0 and 4 ~ 255 of the key type field can be reserved.

Under the proposed scheme regarding key establishment through FILS Shared Key authentication according to the present invention, non-AP STA MLD and AP MLD can perform key establishment and usage association using authentication frames The (or reassociation) request frame and the association (or reassociation) response frame perform key validation. If the non-AP STA MLD chooses to initiate FILS shared key authentication, the non-AP STA MLD can first choose a random 16-octet random nonce (16-octet nonce), and then determine whether to try the pairwise master key Security Association (Pairwise Master Key Securing Association, PMKSA) cache. The non-AP STA MLD can generate a list of PMKSA Distinguished Words in case PMKSA caching is attempted. If the non-AP STA MLD attempts to initiate an Extensible Authentication Protocol (EAP) registration procedure (RP) (EAP-RP), the non-AP STA MLD MAY construct an EAP-initiation/reauthentication packet according to IETF RFC 6696 (EAP-initiate/Re-auth packet), and some instructions. For example, regarding the EAP-RP flag (flag), the B flag can be set to 0 to indicate that this is not an EAP-RP bootstrap message, and the L flag can be set to 1 to indicate that the trusted third party (Trusted Third) that shares the rRK with the STA Party, TTP) will provide the lifetime (lifetime) of rRK and rMSK in the EAP-Finish/Re-auth packet (EAP-Finish/Re-auth packet). In addition, the EAP identifier (Identifier) may be set to 0, and the Cryptosuite field may not be set to 1. Under the proposed scheme, when perfect forward secrecy (Perfect Forward Secrecy, PFS) is required, the non-AP STA MLD can choose a finite cyclic group frame (finite cyclic group frame) dot11RSNAConfigDLCGroupTable . This can include identifying a number from the repository maintained by the Internet Assigned Numbers Authority (IANA) as the IETF RFC 2409 (IKE) Group Description attribute. The STA MLD can then generate an ephemeral private key and perform group scalar operations using its random ephemeral private key and a generator from a selected finite cyclic group. -op) (eg, per Section 12.4.4.1 (General) of the IEEE specification) to compute an ephemeral public key.

Under the proposed scheme, the non-AP STA MLD can construct an authentication frame (Authentication frame) in a certain way. For example, a non-AP STA MLD could set the Authentication Algorithm Number to 4 (for FILS Shared Key Authentication without PFS) or 5 (for FILS Shared Key Authentication with PFS) depending on whether PFS is used (e.g., as described in IEEE Spec as defined in Section 9.4.1.1 (Authentication Algorithm Number field) of . The non-AP STA MLD can also set the authentication transaction sequence number (Authentication transaction sequence number) to 1. A random random nonce may be encoded in the FILS Nonce element (eg, as defined in Section 9.4.2.189 of the IEEE specification (FILS Nonce element (11ai))). If a PMKSA identifier list is generated, non-AP STA MLDs can use this list to construct the PMKID List (PMKID List) field in the Robust Security Network (Robust Security Network) element. A random FILS session (Session) may be encoded in a FILS session element (eg, as defined in Section 9.4.2.179 of the IEEE specification (FILS Session element (11ai))). If an EAP-Initiate/Re-authentication packet is generated, it can be copied into the FILS Wrapped Data field (for example, as described in Section 9.4.2.187 of the IEEE specification (FILS Wrapped Data) Data element (11ai))). In cases where PFS is required, the selected finite cyclic group can be encoded in the finite cyclic group field (Finite Cyclic Group field) (for example, as defined in Section 9.4.1.42 (Finite Cyclic Group field) of the IEEE specification ), and the temporary public key can be encoded in the FFE field according to the element to octet string conversion in Section 12.4.7.2.4 (Element to octet string conversion) of the IEEE specification (for example, as in Section 1 of the IEEE specification 9.4.1.40 (FFE field)). In addition, the wireless medium (WM) MAC address (including the STA MLD address) and the MLD MAC address of each of the supported multiple links may be encoded in the Multiple Link Address (Multiple Link Address) element . After constructing the authentication frame, the non-AP STA MLD can send the authentication frame to the AP MLD.

Under the proposed scheme, where the PMKSA cache is not used and the AP MLD is not connected to or does not recognize an Authentication Server (where the Authentication Server is initiated/reauthenticated by a non-AP STA MLD using EAP- packet (EAP-Initiate/Re-auth packet) key Name-NAI field (realm) in the field), then AP MLD can send the status code (Status Code) field is set to 113 authentication frame , to indicate "authentication denied due to unknown authentication server" to the non-AP STA MLD. Otherwise, the AP MLD can generate its own random nonce and construct an Authentication Frame for the non-AP STA MLD. The AP MLD can copy the FILS Session (FILS Session) element in the authentication frame sent by the non-AP STA MLD to the response authentication frame. If PMKSA caching is not used, this frame MAY contain FILS wrapped data that encapsulates the EAP-Finish/Re-auth packet received from the authentication server. In addition, if PFS is used, the FFE field of the authentication frame sent by AP MLD can contain AP MLD's ephemeral public key. In this frame, AP MLD can set the authentication algorithm number to 4 or 5 according to whether PFS is used, and AP MLD can set the authentication sequence number (Authentication sequence number) to 2. In case PMKSA caching is used, the AP can indicate the selected PMKID in the PMKID list. In the case where PFS is used for the exchange, the AP MLD can perform the group's scalar-op via the STA MLD's ephemeral public key and its own ephemeral private key (e.g., as described in clause 12.4.4.1 of the IEEE specification section (General)), generate temporary Diffie-Hellman shared secret information (Diffie-Hellman shared secret, DHss). Under the proposed scheme, AP MLD can encode the WM MAC address (including the AP MLD address) of each link of the supported multiple links and the MLD MAC address of the AP MLD in the multiple link address (Multiple Link Address) element, the AP MLD may include the multilink address element in the authentication frame. In addition, the AP MLD can send an authentication frame to the non-AP STA MLD. After sending the FILS authentication frame, the AP can establish the key according to Section 12.12.2.5 (Key establishment with FILS authentication) of the IEEE specification.

Under the proposed scheme, two random nonces (nonce) and secret information (secret) from the FILS key establishment process can be used to derive (derived) Pairwise Master Key (PMK). The PMK identifier (PMKID) used to identify the PMKSA can be generated from the negotiated Authentication and Key Management (AKM) on the input data specific to FILS key establishment using a hash algorithm (hash algorithm) . Depending on the negotiated AKM, the PMK can be 256-bit or 384-bit long, while the PKMID can be 128-bit long. If FILS Shared Key authentication is used to generate input keying material, PMK and PMKID can be derived as follows: PMK = HMAC - Hash(SNonce || ANonce, rMSK[||DHss]) PMKID = Truncate - 128 (Hash (EAP-Initiate/Reauth))

When FILS public key (Public Key) authentication is used to generate input key material, PMK and PMKID can be obtained as follows: PMK = HMAC - Hash (SNonce || ANonce, DHss]) (MLD-level) PMKID = Truncate - 128 (Hash (gSTA || gAP)) (MLD -level)

Here, SNonce means STA MLD random nonce (nonce), and ANonce means AP MLD random nonce. In addition, rMSK represents the shared secret information (secret) from EAP-RP exchange, and DHss represents the shared secret information (secret) exported from Diffie-Hellman exchange when performing Diffie-Hellman exchange, because when using Elliptic Curve Encryption (Elliptic Curve Cryptography, ECC), only the x-coordinates from Elliptic Curve Diffie-Hellman (Elliptic Curve Diffie-Hellman) are included. Square brackets indicate the inclusion of the shared secret when performing a Diffie-Hellman exchange, and the absence of the shared secret otherwise. EAP-Initiate/Reauth indicates the EAP-RP packet sent by the STA using the key establishment process with FILS shared key authentication. In addition, gSTA represents the Diffie-Hellman value of STA MLD, and gAP represents the Diffie-Hellman value of AP MLD. Hash represents the negotiation-specific AKM hash algorithm (see Table 9-151 (AKM suite selectors) of the IEEE specification).

For Pairwise Transient Key Security Association (PTKSA) key generation, the input of pseudo-random function (pseudo-random function, PRF) can be PMK of PMKSA, constant label (constant label) and STA MLD Concatenation of MAC address, AP MLD MAC address, STA MLD random number and AP MLD random number. When the negotiated AKM is 00-0F-AC:14 or 00-0F-AC:16, the length of the key encryption key (Key Encryption Key, KEK) can be 256 bits, and the integrity check value key ( Integrity Check Value Key (ICK) can be 256 bits in length. When the negotiated AKM is 00-0F-AC:15 or 00-0F-AC:17, the length of the KEK may be 512 bits, and the length of the ICK may be 384 bits. When the negotiated AKM is 00-0FAC:16, FILS-FT (fast transition, FT) can be 256 bits. When the negotiated AKM is 00-0F-AC:17, the FILS-FT can be 384 bits; otherwise, the FILS-FT cannot be derived. Therefore, depending on the negotiated AKM, the total number of bits extracted from the key derivation function (KDF) can be 512+TK bits, 896+TK bits, or 1280+TK bits, where the TK bits are as follows Determined by: FILS-Key-Data = PRF – X(PMK, "FILS PTK KDerivation", SPR || AA || SNonce || ANonce[ || DHss]) ICK = L (FILS-Key-Data, 0, ICK_bits) KEK = L (FILS-Key-Data, ICK_bits, KEK_bits) TK = L (FILS-Key-Data, ICK_bits + KEK_bits)

When using FILS authentication to perform a fast transition (FT) initial mobility domain association, FILS-FT can be determined as follows: FILS-FT = L (FILS-Key-Data, ICK_bits + KEK_bits + TK_bits, FILS-FT_bits)

Here, ICK_bits represents the length of ICK in bits, KEK_bits represents the length of KEK in bits, and FILS-FT_bits represents the length in bits when FILS authentication is used to perform FT initial mobility domain association (initial mobility domain association). The length of the FILS-FT in units. Depending on the negotiated AKM, X can be 512+TK bits, 768+TK bits, 896+TK bits, or 1280+TK bits in Table 12-7 (Cipher suite key lengths) of the IEEE specification. PMK Indicates the PMK from the PMKSA when using PMKSA caching, either created from the initial FILS connection or from a cached PMKSA. It is equal to the Master PMK (Maser PMK, MPMK) when performing FT Initial Mobility Domain Association using FILS authentication (e.g., as defined in Section 12.7.1.6.3 (PMKR0) of the IEEE specification). SPA means STA MLD MAC address, AA means AP MLD MAC address, ANonce means STA MLD random number, ANonce means AP MLD random number, DHss means Diffie-Hellman Exchange exported shared secret information. Additionally, square brackets indicate the inclusion of the shared secret when performing a Diffie-Hellman exchange concurrently with the PMKSA cache, and indicate no shared secret otherwise. After generating FILS-Key-Data, the shared secret information DHss can be irretrievably deleted if a Diffie-Hellman exchange is performed.

Under the proposed scheme regarding the association (or re-association) request for FILS key confirmation according to the present invention, the key confirmation for FILS authentication can be an association (or re-association) request frame followed by an association ( or reassociate) response box. Components of an association (or reassociation) request frame and an association (or reassociation) response frame can be protected using a KEK. The STA MLD may construct an association (or reassociation) request frame for FILS authentication (eg, according to Section 9.3.3.5 (Association Request frame format) and Section 9.3.3.7 (Reassociation Request frame format) of the IEEE specification). A hashing algorithm may be used to generate the FILS Key Confirmation element, and the specific hashing algorithm may depend on the negotiated AKM (e.g., according to section 9.4.2.24.3 of the IEEE specification (AKM suites)).

Under the proposed scheme, for both FILS public key authentication and FILS public key authentication when PMKSA cache is used, the KeyAuth field of the FILS key confirmation element can pass the hash based message authentication code using the negotiated hash algorithm (Hash-Based Message Authentication Code, HMAC) mode is constructed as follows, where the negotiated hash algorithm uses the ICK key and the random nonce of the STA MLD, the nonce of the AP MLD, the STA MLD MAC address, the AP Concatenation of MLD MAC address and conditionally (conditionally) STA MLD's public Diffie-Hellman value and AP MLD's public Diffie-Hellman value: Key-Auth = HMAC-Hash (ICK, SNonce || ANonce || STA-MLD-MAC || AP-MLD-MAC [ || gSTA || gAP])

Here, Hash represents the negotiation-specific AKM hash algorithm (see Table 9-151 (AKM suite selectors) of the IEEE specification), SNonce represents the random nonce of STA MLD, ANonce represents the random nonce of AP MLD, STA-MLD-MAC indicates the MLD MAC address of the STA MLD, AP-MLD-MAC indicates the MLD MAC address of the AP MLD, gSTA indicates the public value of Diffie-Hellman of the STA MLD, and gAP indicates the Diffie-Hellman of the AP MLD Public values, square brackets indicate that Diffie-Hellman public values are included when performing PFS via FILS Shared Key authentication or PMKSA caching via FILS Public Key authentication.

For FILS public key authentication when no PMKSA cache is used, the KeyAuth field of the FILS Key Confirmation element may be a digital signature of the private key of the STA MLD using a negotiated hash algorithm, the negotiated hash algorithm The algorithm is for STA MLD's public Diffie-Hellman value, AP MLD's public Diffie-Hellman value, STA MLD's nonce, AP MLD's nonce, STA MLD MAC address, and AP MLD's in the following order Concatenation of MAC addresses: Key-Auth = Sig-STA (gSTA || gAP || SNonce || ANonce || STA-MLD-MAC || AP-MLD-MAC)

Here, Sig-STA() means a digital signature using STA MLD's private key (similar to STA MLD's trusted public key). The form of the signature MAY depend on the type of public key used by the STA MLD (see the RSA section of IETF RFC 3447, the DSA section of FIPS 186-4, and the ECDSA section of ISO/IEC 14888-3). The material to be signed may first be hashed, and the hashing algorithm used with an appropriate digital signature algorithm may be specific to the negotiated AKM.

Under the proposed scheme, an Authenticated Encryption with Associated Data (AEAD) algorithm (for example, as described in section 12.12.2.7 of the IEEE specification (AEAD cipher mode for FILS) can be used with KEK as a key. ), to encrypt the association (reassociation) request frame. Additional Authentication Data (AAD) used with the AEAD algorithm used to associate request frames may include the following data, delivered as separate elements in the following order: (i) the STA's MAC address, (ii) ) AP's basic service set identifier (BSSID), (iii) STA's random number, (iv) AP's random number, and (v) association (re-association) request frame slave capability Info field (inclusive) to the content of the FILS session element (inclusive). Additionally, the Additional Authentication Data (AAD) used with the AEAD algorithm for the association request frame may include (vi) STA MLD MAC address and (vii) AP MLD MAC address. The plaintext passed to the AEAD algorithm can be the data following the FILS session element in the unencrypted frame body. The output of the AEAD algorithm may become the data following the FILS session element in the encrypted and authenticated association (reassociation) request frame. The output of the algorithm may be as specified in IETF RFC 5116. The resulting association (re-association) request frame can be sent to the AP MLD. The AP MLD can compare the FILS session of the received association (re-association) request frame with the FILS session used to identify the FILS session in the authentication frame. If they differ, the authentication exchange fails.

Under the proposed scheme, the AP MLD can decrypt and authenticate the received Association (reassociation) request frame. The AAD can be reconstructed as defined above and can be passed to the AEAD decryption operation together with the ciphertext of the received frame. If the output of the AEAD decryption operation returns a failure indication, the authentication exchange has failed. If the output does not return a failure indication, the output plaintext may replace the ciphertext as part of the frame body following the FILS session element, and processing of the received frame may continue by checking the value of the FILS key confirmation element. The AP MLD can verify that the RSNE received in the Association (Reassociation) Request frame contains the same AKM suite and cipher suites and RSN capabilities as the RSNE in the Authentication frame from the STA MLD. If these fields are different, the authentication exchange fails. For FILS common key authentication, the AP MLD can construct the verifier Key-Auth' in the same way as the STA MLD above constructs its Key-Auth'. The AP MLD MAY compare the Key-Auth' to the KeyAuth field in the FILS KeyConfirmation element of the received frame. If they are different, authentication fails.

For FILS public key authentication, the AP MLD can use the (certified) public key of the STA MLD from the FILS public key element to verify that the signature contained in the KeyAuth field corresponds to the signature passed by the STA MLD according to the signature scheme used. The signature formed by concatenating the following contents in sequence: STA’s public Diffie-Hellman value (gSTA), AP’s public Diffie-Hellman value (gAP), STA’s random number (SNonce), AP’s random number (ANonce) , STA MAC address (STA-MAC) and AP BSSID (AP-BSSID). In addition, AP MLD can cryptographically and security-principally check all certificates in a credential chain according to the procedure for checking certificates and credential chains in IETF RFC 5280. If any of these verifications fail, the authentication fails.

Under the proposed scheme, if the authentication is deemed to have failed, the ICK, KEK, TK, and PTKSA can be irretrievably deleted, and the AP MLD can return an authentication frame with status code set to 112 to indicate "authentication failed due to FILS resulting in authentication being denied". The PMKSA can also be deleted if the PMKSA cache was not used in this failed authentication attempt. If a PMKSA cache is used, the failure could be due to an impersonation attack. So when FILS with PMKSA cache fails, AP MLD can decide to keep the cached PMKSA.

Under the proposed scheme of the association (re-association) response frame for FILS key confirmation according to the present invention, AP MLD can construct the association (re-association) response frame for FILS authentication (for example, as in IEEE specification Sections 9.3.3.6 (Association Response frame format) and 9.3.3.8 (Reassociation Response frame format)). As with the Association (Reassociation) Request frame, a hashing algorithm can be used to generate the FILS Key Confirmation element, the specific hashing algorithm MAY depend on the negotiated AKM (see Section 9.4.2.24.3 (AKM suites)). In addition, the AP MLD can construct a key delivery (Key Delivery) element to indicate the current group temporary key (Group Temporal Key, GTK) and key receiving sequence counter (receive sequence counter) of each link in multiple links , RSC), the current Integrity Group Temporal Key (IGTK) and IGTK packet number (IPN) for each of the multiple links (if management frame protection is enabled), The current Beacon Integrity Group Temporal Key (BIGTK) and BIGTK packet number (BIPN) for each of the multiple links (if beacon protection is enabled). The AP MLD MAY place a Key Transfer element in the Association (Reassociation) Response frame.

Fig. 5 illustrates an example design 500 of a Key Delivery element under the proposed scheme according to the present invention. Referring to FIG. 5, the key transmission element may include multiple fields, including, for example, an element ID field, a length field, an element ID extension field, a key RSC field, and a key data encapsulation (Key Data Encapsulation, KDE) list field. The Key RSC field may contain the Receive Sequence Counter (RSC) for the GTK installed on the link that sent the Key Transport element. The KDE list field can contain one or more KDEs packaged in a predefined format. For example, the KDE list field can include GTK KDE, IGTK KDE, and BIGTK KDE for the same link that sent the key transfer element. In addition, the KDE list field may include multi-link GTK KDE, multi-link IGTK KDE, and multi-link BITKK KDE for different links for sending key transfer elements.

Fig. 6 illustrates an example design 600 of a multi-link GTK KDE element under the proposed scheme according to the present invention. Referring to Figure 6, a multi-link GTK KDE element may include multiple fields including, for example, a Key ID field, a Transmit (Tx) field, a Reserved field, a Link ID field, a Key RSC field, and GTK field. The Key ID field can indicate the value of the GTK key identifier. The Send (Tx) field may indicate the link over which GTK is sent. If the value of the Tx field is 1, the IEEE 802.1X component can configure the temporal key exported from KDE into tis IEEE 802.11 MAC(#2507) for sending and receiving. If the value of the Tx field is 0, the IEEE 802.1X component can configure the ephemeral key exported from KDE into tis IEEE 802.11 MAC(#2507) for receive only. The link ID field may indicate the link (eg, class of operation and major channel number) of the GTK being installed. The Key RSC field may contain the Receive Sequence Counter (RSC) of the GTK installed on the link indicated by the Link ID field. Transmission of the RSC field value may enable the STA to identify the MAC protocol data unit (MPDU) being replayed on the link indicated by the link ID field. If the RSC field value is less than 8 octets in length, the remaining octets MAY be set to 0. The least significant octet of the transmit sequence counter (TSC) or packet number (PN) can be in the first octet of the RSC field.

Fig. 7 shows an example design 700 of a multi-link IGTK KDE element under the proposed scheme according to the present invention. Referring to FIG. 7, a multi-link IGTK KDE element may include multiple fields including, for example, a key ID field, an IPN field, a link ID field, and an IGTK field. The key ID field may indicate the value of the IGTK key identifier. The link ID field can indicate the link on which IGTK is being installed (for example, class of operation and primary channel number). The IPN field may correspond to the last packet number used by the broadcast/multicast sender on the link indicated by the link ID field, and it may be used by the receiver as the Broadcast Integrity Protocol (BIP) for IGTK ) the initial value of the replay counter.

Fig. 8 illustrates an example design 800 of a multi-link BIGTK KDE element under the proposed scheme according to the present invention. Referring to FIG. 8, a multi-link BIGTK KDE element may include multiple fields including, for example, a key ID field, a BIPN field, a link ID field, and a BIGTK field. The key ID field can indicate the value of the BIGTK key identifier. The Link ID field can indicate the link on which BIGTK is being installed (for example, class of operation and major channel number). The BIPN field may correspond to the Management Message Integrity Check (MIC) element (MIC element, MME) of the last protected Beacon frame (Beacon frame) on the link indicated by the Link ID field ), and it can be used by the receiver as the initial value of BIGTK's BIP replay counter.

Under the proposed scheme according to the present invention, for FILS shared key authentication and FILS public key authentication when using PMKSA cache, the HMAC mode of the negotiated hash algorithm can be used to construct the KeyAuth column of the FILS key confirmation element in the following manner bits, where the negotiated hash algorithm utilizes the ICK key and AP MLD's nonce, STA MLD's nonce, AP MLD MAC address, STA MLD MAC address, and conditionally AP MLD's Concatenation of the public Diffie-Hellman value and the public Diffie-Hellman value of the STA MLD: Key-Auth = HMAC-Hash (ICK, ANonce || SNonce || AP-MLD-MAC || STA-MLD-MAC [ || gAP || gSTA ])

Here, Hash represents the hash algorithm specific to the negotiated AKM, ANonce represents the random number of AP MLD, SNonce represents the random number of STA MLD, AP-MLD-MAC represents the MLD MAC address of AP MLD, STA-MLD-MAC Indicates the MLD MAC address of STA MLD, gAP indicates the Diffie-Hellman public value of AP MLD, gSTA indicates the Diffie-Hellman public value of STA MLD, and the square brackets indicate that when PFS is executed through FILS Shared Key authentication (FILS Shared Key authentication) includes Diffie-Hellman public value. Otherwise, no Diffie-Hellman public values are included.

Under the proposed scheme, for FILS public key authentication when no PMKSA cache is used, the KeyAuth field of the FILS key confirmation element can be the digital signature of the AP MLD private key output using the negotiated hash algorithm. The hash algorithm is based on AP MLD's public Diffie-Hellman value, STA MLD's public Diffie-Hellman value, AP MLD's nonce, STA MLD's nonce, AP MLD MAC address, and STA MLD MAC in the following order Concatenation of addresses. The specific construction of the digital signature can depend on the cryptographic system of the public key/private key pair, as follows: Key-Auth = Sig-AP (gAP || gSTA || ANonce || SNonce || AP-MLD-MAC || STA-MLD-MAC)

Here, Sig-AP() may represent a digital signature using the AP MLD's private key (similar to the AP MLD's trusted public key). The form of the signature MAY depend on the type of public key used by the AP MLD (see the RSA section of IETF RFC 3447, the DSA section of FIPS 186-4, and the ECDSA section of ISO/IEC 14883-3). The material to be signed may first be hashed, and the hashing algorithm used with an appropriate digital signature algorithm may be specific to the negotiated AKM.

Under the proposed scheme according to the present invention, the association (re-association ) in response to the frame. Additional Authentication Data (AAD) for use with the AEAD algorithm used to associate (re-associate) response frames may include the following data, delivered as separate elements in the following order: AP's BSSID, STA's MAC address, AP's nonce, STA's nonce, and the contents of the Association (Reassociation) Response frame from the Capability Info field (inclusive) to the FILS Session element (inclusive). In addition, the additional authentication data (Additional Authentication Data, AAD) used together with the AEAD algorithm for associating the response frame may include the STA MLD MAC address and the AP MLD MAC address. The plaintext passed to the AEAD algorithm can be the data following the FILS session element in the unencrypted frame body. The output of the AEAD algorithm may become data following the FILS session element in the encrypted and authenticated association (reassociation) response frame. The output of the algorithm may be as specified in IETF RFC 5116. The resulting association (re-association) response frame can be sent to the STA MLD.

Under the proposed scheme, STA MLD can decrypt and authenticate the received Associate (re-associate) response frame. The AAD can be reconstructed as defined above and can be passed to the AEAD decryption operation along with the ciphertext of the received frame. The STA MLD may compare the FILS session of the received frame with the FILS session of the STA MLD selected to identify the FILS. If they are different, authentication fails. If the output of the AEAD decryption operation returns a failure indication, the authentication exchange has failed. If the output does not return a failure indication, the output plaintext may replace the ciphertext as part of the frame body following the FILS session element, and processing of the received frame may continue by checking the value of the FILS key confirmation element. STA MLD can verify whether the RSNE received in the association (re-association) response frame contains the same AKM combination (AKM suite) and cipher suites (cipher suites) in the beacon, probe response and authentication frame from the AP MLD and RSN capability. If these fields are different, authentication fails.

Under the proposed scheme, for FILS shared key (Shared Key) authentication, STA MLD can construct the authenticator Key-Auth' in the same way as the above-mentioned AP constructs its key authentication (Key-Auth). The STA MLD may compare the Key-Auth' with the KeyAuth field in the FILS KeyValidation element of the received frame. If they are different, authentication fails. For FILS public key authentication, the STA MLD can use the AP MLD's (certified) public key from the FILS public key element to verify that the signature contained in the KeyAuth field corresponds to the A signature formed by concatenating the following contents: AP's public Diffie-Hellman value (gAP), STA's public Diffie-Hellman value (gSTA), AP's random number (ANonce), STA's random number (SNonce), AP The BSSID of the AP (AP-BSSID) and the MAC address of the STA (STA-MAC). In addition, AP MLD can cryptographically and security-principally check all certificates in a credential chain according to the procedure for checking certificates and credential chains in IETF RFC 5280. If any of these verifications fail, the authentication fails.

Under the proposed scheme, if the authentication is considered failed, the ICK, KEK, PMK and TK can be irretrievably deleted and the STA MLD should abandon the exchange. Otherwise, the authentication is successful and STA MLD and AP MLD can irretrievably delete the non-persistent secret keying material (nonpersistent secret keying material), which is passed FILS shared key authentication (Shared Key authentication ) key establishment (key establishment) process (for example, see Section 12.12.2.3 (Key establishment with FILS Shared Key authentication) of the IEEE specification) or key establishment through FILS public key authentication (Public Key authentication) ( key establishment) procedure (see, for example, Section 12.12.2.4 (Key establishment with FILS Public Key authentication) of the IEEE specification). The KEK and PMK can be used for subsequent key management (eg, as specified in section 12.6 (RSNA security association management) of the IEEE specification). When the lifetime (lifetime) of the rMSK is known, the STA MLD and the AP MLD can set the lifetime of the PMKSA to the lifetime of the rMSK. Otherwise, STA MLD and AP MLD may set the lifetime of PMKSA to the value dot11RSNAConfigPMKLifetime. After successful completion of the FILS authentication process, the STA MLD can process the Key Delivery element in the Association (Reassociation) Response frame. STA MLD can install GTK and key RSC, and if management frame protection (management frame protection) is enabled, install IGTK and IPN for each link in multiple links, and present in the key delivery element BIGTK and BIPN and dot11BeaconProtectionEnabled is true to install BIGTK and BIPN for each of the multiple links.

FIG. 9 illustrates an example design 900 of a Robust Security Network (RSN) capability field (Capabilities field) under the proposed scheme according to the present invention. As shown in FIG. 9, the RSN capability field may include multiple subfields, and the multiple subfields include the Extended Key ID (Extended Key ID for Individually Addressed Frames) subfield of individually addressed frames. When the cipher suite is Cipher Block Chaining Message Authentication Code Protocol (CCMP) or Galois/Counter Mode Protocol (Galois/Counter Mode Protocol, GCMP), the extended gold for individually addressable frames The Key ID subfield (located at bit 13 or B13 of the RSN Capability field) may be set to 1 to indicate that the STA supports Key ID values in the range 0~1 for PTKSA.

Under the proposed scheme for Robust Security Network Association (RSNA) key rekeying according to the present invention, when both ends of the link support extended key IDs for individually addressed frames , you can install a new PTKSA without losing data, provided that the new PTKSA uses a different key ID from the old PTKSA. It is worth noting that if the same key ID is used, data loss may occur, because at one end the new key is used for sending and at the other end it is used for receiving, which cannot be precisely coordinated (due to software processing delays ). If the new PTKSA uses a different key ID, fine reconciliation may not be required, assuming the new key is installed on the receiving side before the first use of the new key on the sending side. During transition, the key ID can be used to unambiguously identify received packets as belonging to the old or new PTKSA.

Under the proposed scheme, if the extended key ID subfield of the separate addressing frame of the RSN capability field is 1 for both the Authenticator and the Supplicant, the authenticator can be between 0 ~ 1 Assign a new key ID to PTKSA within the scope, this new key ID is different from the key ID assigned in the previous handshake, in addition, the authenticator can use the MLMESETKEYS.request primitive (primitive) to install the new key to receive the Individually addressed MPDUs protected by a PTK (associated with an assigned Key ID). Otherwise, key ID 0 may be used and installation of the key may be postponed until after message 4 is received. The authenticator can send message 3 to the supplicant. It is worth noting that the authenticator IEEE 802.11 MAC can continue to send protected, individually addressed MPDUs (if any) using the existing key while the existing PTK is still valid. By installing a new key for receiving, the authenticator can receive protected, individually addressed MPDUs using the old key (if present) or the new key.

Fig. 10 shows an example scenario 1000 of RSNA key rekeying under the proposed scheme. Referring to Figure 10, the RSNA key update process can use two keys. In scenario 1000, the key can persist in place (for receive processing) for two handshake periods. PTKSA life cycle can be two handshake cycles. A new key installation can replace an old key with the same key ID. Therefore, having two active keys allows for a smooth, time-lenient transition from one PTKSA to the next.

Under the proposed scheme on CCMP encapsulation according to the present invention, the PN value can sequentially number each MPDU. Each sender MAY maintain a single PN (eg, 48-bit counter) for each PTKSA and Group Temporal Key Security Association (GTKSA). PN can be implemented as a strictly increasing integer 48-bit value, and it is initialized to 1 when the corresponding ephemeral key is initialized or refreshed.

Under the proposed scheme about GCMP encapsulation according to the present invention, the PN value can sequentially number each MPDU. Each transmitter can maintain a single PN (for example, a 48-bit counter) for each PTKSA and GTKSA. PN can be implemented as a strictly increasing integer 48-bit value, and it is initialized to 1 when the corresponding ephemeral key is initialized or refreshed.

Under the proposed scheme for RSNA key update in multi-link operation according to the present invention, when a STA (e.g., STA 110) re-encrypts a frame for retransmission on the same link or a different link, the STA can use The value of the Key ID field in the CCMP or GCMP header is set to be the same as the value of the Key ID field in the first transmitted MPDU. Otherwise, replay detection may encounter difficulties due to different PN spaces for different key IDs. Exemplary Implementation

Figure 11 shows an example system 1100 having at least an example device 1110 and an example device 1120 in accordance with an embodiment of the invention. Each of the device 1110 and the device 1120 can perform various functions to realize the schemes, techniques, procedures and methods described herein related to EHT FILS support in multi-link operation in wireless communication, including referring to the above-mentioned various proposed designs, ideas , schemes, systems and methods, and various aspects of the processes described below. For example, means 1110 may be an example implementation of STA 110 and means 1120 may be an example implementation of STA 120.

Each of device 1110 and device 1120 may be part of an electronic device, which may be a STA or AP, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, each of apparatus 1110 and apparatus 1120 may be implemented in a smartphone, smart watch, personal digital assistant, digital camera, or computing device such as a tablet, laptop, or notebook computer. Each of device 1110 and device 1120 may also be part of a machine type device, which may be an IoT device such as a non-removable or fixed device, a home device, a wired communication device, or a computing device. For example, each of device 1110 and device 1120 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. When implemented in or as a network device, device 1110 and/or device 1120 may be implemented in a network node (eg, an AP in a WLAN).

In some implementations, each of device 1110 and device 1120 may be implemented in the form of one or more integrated-circuit (IC) chips, such as, but not limited to, one or more single-core processors, One or more multicore processors, one or more reduced-instruction-set-computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors device. In the foregoing various solutions, each of the apparatus 1110 and the apparatus 1120 may be implemented in or as an STA or an AP. Each of the apparatus 1110 and the apparatus 1120 may include at least some of those elements shown in FIG. 11 , such as a processor 1112 and a processor 1122 , respectively. Each of device 1110 and device 1120 may also include one or more other elements (e.g., an internal power supply, a display device, and/or a user interface device) that are not relevant to the proposed solution of the present invention, and thus, for the sake of simplicity and brevity, none of these elements of device 1110 and device 1120 are shown in FIG. 11 .

In one aspect, each of processor 1112 and processor 1122 can be implemented as one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors form is realized. That is, even though the singular term "processor" is used herein to refer to processor 1112 and processor 1122, each of processor 1112 and processor 1122 may include multiple processors in some implementations and in other implementations. A single processor can be included in the mode. In another aspect, each of processor 1112 and processor 1122 may be implemented in the form of hardware (and optionally firmware) with electronic components including, for example but not limited to, one or more transistors , one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors configured and arranged to achieve a specific purpose, and/or or one or more varactor diodes. In other words, in at least some embodiments, each of processor 1112 and processor 1122 may be a special-purpose device that is specially designed, arranged, and configured to perform specific tasks, including specific tasks according to various embodiments of the present invention. EHT FILS supports various tasks related in multi-link operation in wireless communication.

In some implementations, the apparatus 1110 can also include a transceiver 1116 coupled to the processor 1112 . Transceiver 1116 may transmit and receive material wirelessly. In some implementations, the device 1120 can also include a transceiver 1126 coupled to the processor 1122 . Transceiver 1126 may include a transceiver capable of transmitting and receiving material wirelessly. The transceiver 1116 of the device 1110 and the transceiver 1126 of the device 1120 may communicate with each other through one or more links (such as a first link and a second link) among a plurality of links link 1 to link N, wherein N>1.

In some implementations, the device 1110 may further include a memory 1114 coupled to the processor 1112 and capable of being accessed by the processor 1112 therein. In some implementations, the device 1120 can also include a memory 1124 coupled to the processor 1122 and capable of being accessed by the processor 1122 . Each of memory 1114 and memory 1124 may include random-access memory (random-access memory, RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM) and/or Zero-capacitance RAM (Z-RAM). Alternatively or additionally, each of memory 1114 and memory 1124 may include read-only memory (ROM), such as mask ROM, programmable ROM (PROM), erasable Programmable ROM (EPROM) and/or Electrically Erasable Programmable ROM (EEPROM). Alternatively or additionally, each of memory 1114 and memory 1124 may include non-volatile random-access memory (non-volatile random-access memory, NVRAM), such as flash memory, solid-state memory, Ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and/or phase change memory.

Each of the device 1110 and the device 1120 may be a communication entity capable of communicating with each other using various proposed schemes according to the present invention. For illustrative purposes and not limitation, the following describes the capabilities of apparatus 1110 (apparatus 1110 as STA 110, which is a constrained non-AP MLD) and apparatus 1120 (apparatus 1120 as STA 120, which may be a constrained AP MLD) Ability. It is worth noting that while the example implementations described below are provided in the context of a WLAN, they can be implemented in other types of networks as well.

Under the proposed scheme concerning EHT FILS support in multi-link operation in wireless communication according to the present invention, in the processor 1112 of the device 1110 and the processor 1122 of the device 1120 respectively implemented in the non-AP STA MLD and the AP MLD Each, a FILS procedure may be performed to establish wireless communication between the AP MLD and the non-AP STA MLD over multiple links. Additionally, each of processor 1112 of device 1110 and processor 1122 of device 1120 may communicate over one or more of the plurality of links after the FILS process is complete.

In some implementations, the FILS discovery frame sent during the FILS process may indicate whether the SSID of the AP MLD is different from the SSID of the AP that sent the FILS discovery frame among the APs in the AP MLD.

In some implementations, the Multiple Links Presence Indicator (Multiple Links Presence Indicator) subfield in the FD Capability (Capability) subfield of the FILS Discovery Information (Discovery Information) field of the FILS discovery frame is set to 1, to indicate that the SSID of the AP MLD is different from the SSID of the AP sending the FILS discovery frame among multiple APs in the AP MLD. In some implementations, when the multi-link presence indicator subfield is set to 1, the FILS discovery information field may further include a short MLD SSID (Short MLD SSID) subfield, the short MLD SSID subfield The bits contain the 4-octet short SSID of the AP MLD.

In some implementations, when executing the FILS process, the processor 1112 implemented in the non-AP STA MLD can perform the association or re-association process through HLP encapsulation in the following manner: (a) construct the FILS HLP container (Container) element to form HLP packet; (b) Send the FILS HLP container element to the AP MLD in an Association or Reassociation Request frame. In some implementations, a FILS HLP container element may include a destination MAC address, a source MAC address, and an HLP packet in MSDU format. Additionally, the source MAC address may include or may be the MLD MAC address of the non-AP STA MLD.

In some implementations, when performing a FILS process, the processor 1122 implemented in the AP MLD can receive and decapsulate the HLP packet by: (a) extracting the destination MAC address, source MAC address, and HLP packet from the FILS HLP container element packet; (b) determine whether the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD associated with the source MAC address of the association or re-association request frame; (c) respond to determining the extracted source MAC address The MAC address matches the MLD MAC address of the non-AP STA MLD: (i) builds a frame containing the HLP packet; (ii) transmits the frame to the upstream network or BSS. Further, processor 1122 may discard the FILS HLP container element in response to determining that the extracted source MAC address does not match the MLD MAC address of the non-AP STA MLD.

In some implementations, when performing the FILS process, each of the processor 1112 of the device 1110 and the processor 1122 of the device 1120 respectively implemented in the non-AP STA MLD and the AP MLD may pass the AP Multiple APs in the MLD and non-AP STAs Multiple STAs in the MLD perform authentication procedures using one public key for multiple links. In some implementations, Diffie-Hellman values among multiple APs in an AP MLD may be common across multiple links. Similarly, Diffie-Hellman values among multiple STAs in the non-AP STA MLD may be common across multiple links.

In some implementations, in performing the FILS process, each of processor 1112 and processor 1122 implemented in the non-AP STA MLD and AP MLD, respectively, may use the PMK and PMKID to perform the authentication process. In some implementations, each of the PMK and PMKID may be generated using MLD-level information related to the AP MLD and the non-AP STA MLD.

In some implementations, during the execution of FILS, the processor 1112 implemented in the non-AP STA MLD may perform the authentication process by: (a) generating an authentication frame by: (i) for the non-AP STA The MLD MAC address of the MLD, which is the WM MAC address of each link of one or more supported links in the multiple links; (ii) in the multilink address element of the authentication frame Contains the encoded MAC address; (b) sends an authentication frame to the AP MLD.

In some implementations, in executing the FILS program, the processor 1122 implemented in the AP MLD may perform the authentication process by: (a) generating an authentication frame by: (i) encoding the MLD MAC address of the AP MLD , the MLD MAC address is the WM MAC address of each of one or more supported links in the plurality of links; (ii) includes the encoded MAC address in the multilink address element of the authentication frame; (b) Send an authentication frame to the non-AP STA MLD.

In some implementations, when performing the FILS process, the processor 1122 implemented in the AP MLD may perform the association or re-association process by: (a) generating an association or re-association response frame by constructing a key transfer element , where the key transfer element indicates: (i) the current GTK and key RSC associated with each of the multiple links, (ii) the the current IGTK and IPN associated with each link in the road, and (iii) the current BIGTK and BIPN associated with each of the multiple links if beacon protection is enabled; (b) Send an Association or Re-Association Response frame to the non-AP STA MLD. In some implementations, the key transfer element may contain a KDE list field that includes a multi-link GTK KDE, a multi-link IGTK KDE, and one or more A multilink BIGTK KDE associated with each of the multiple links.

In some implementations, the multi-link GTK KDE may include: (i) a Key ID field indicating the value of the GTK key identifier, (ii) a Transmit field indicating the link used to transmit the GTK ), (iii) a link ID field indicating the link on which GTK is to be installed, and (iv) a key RSC field containing the ID of the GTK installed on the link indicated by the link ID field RSC. In some implementations, for an AP MLD and a non-AP STA MLD that support the same key identifier, the GTK key identifier may be MLD-level.

In some implementations, a multi-link IGTK KDE may include: (i) a key ID field indicating the value of the IGTK key identifier, (ii) a link ID field indicating on which IGTK will be installed​​ TK's link, (iii) IPN field, which corresponds to the last packet number used by the sender on the link indicated by the link ID field, and this last packet number is used by the receiver as the BIP replay counter for IGTK (replay counter) initial value. In some implementations, the IGTK key identifier may be at MLD level for AP MLD and non-AP STA MLD that support the same key identifier.

In some implementations, a multi-link BIGTK KDE may include: (i) a key ID field indicating the value of the BIGTK key identifier, (ii) a link ID field indicating on which BIGTK will be installed​​ TK's link, (iii) BIPN field, which corresponds to the BIPN value carried in the MME of the last protected beacon frame on the link indicated by the link ID field, and this BIPN value is used by the receiver as The initial value of the BIP replay counter of BIGTK. In some implementations, the BIGTK key identifier may be at MLD level for AP MLD and non-AP STA MLD that support the same key identifier.

In some implementations, in communication, each of processor 1112 and processor 1122 sends or receives a retransmitted frame via transceiver 1116 or transceiver 1126, respectively, the CCMP or GCMP header of the retransmitted frame The Key ID field in is equal to the Key ID field of the MPDU transmitted for the first time. Exemplary process

Figure 12 shows an example process 1200 in accordance with an implementation of the invention. Process 1200 may represent one aspect of implementing the various designs, concepts, solutions, systems and methods presented above. More specifically, process 1200 may represent an aspect of various proposed concepts and schemes related to EHT FILS support in multi-link operation in wireless communications according to the present invention. Process 1200 may include one or more operations, actions, or functions as indicated by one or more of blocks 1210 and 1220 . Although shown as discrete blocks, the various blocks of process 1200 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Additionally, the blocks of process 1200 may be performed in the order shown in Figure 12, or may be performed in a different order. Additionally, one or one of the blocks/sub-blocks of process 1200 may be performed repeatedly or iteratively. Process 1200 may be implemented by or within apparatus 1110 and apparatus 1120 or any variation thereof. For illustrative purposes only and not limitation, below, device 1110 acts as STA 110 (eg, STA or AP) of a wireless network (eg, a WLAN conforming to one or more IEEE 802.11 standards) and device 1120 acts as STA 120 (eg, WLAN compliant with one or more IEEE 802.11 standards). , a peer STA or AP) the process 1200 is described in the context of. Process 1200 may begin at block 1210 .

At 1210, process 1200 may involve each of means 1110 and 1120 implemented in the non-AP STA MLD and AP MLD, respectively, performing a FILS process to establish wireless between the AP MLD and the non-AP STA MLD over multiple links. communication. Process 1200 may proceed from block 1210 to block 1220 .

At 1220, process 1200 may involve each of device 1110 and device 1120 communicating over one or more of a plurality of links after completing the FILS process.

In some implementations, the FILS discovery frame sent during the FILS process may indicate whether the SSID of the AP MLD is different from the SSID of the AP that sent the FILS discovery frame among the APs in the AP MLD.

In some implementations, the Multiple Links Presence Indicator (Multiple Links Presence Indicator) subfield in the FD Capability (Capacity) subfield in the FILS Discovery Information (Discovery Information) field of the FILS discovery frame is set to 1, to indicate that the SSID of the AP MLD is different from the SSID of the AP sending the FILS discovery frame among multiple APs in the AP MLD. In some implementations, when the multi-link presence indicator subfield is set to 1, the FILS discovery information field may further include a short MLD SSID (Short MLD SSID) subfield, the short MLD SSID subfield The bits contain the 4-octet short SSID of the AP MLD.

In some implementations, when performing the FILS process, the process 1200 may involve that the non-AP STA MLD may perform the association or re-association process through HLP encapsulation in the following manner: (a) constructing a FILS HLP container (Container) element to form an HLP encapsulation; (b) Send the FILS HLP container element to the AP MLD in an Association or Reassociation Request frame. In some implementations, a FILS HLP container element may include a destination MAC address, a source MAC address, and an HLP packet in MSDU format. Additionally, the source MAC address may include or may be the MLD MAC address of the non-AP STA MLD.

In some implementations, when performing the FILS process, the process 1200 can also involve that the AP MLD can receive and decapsulate the HLP packet by: (a) extracting the destination MAC address, source MAC address, and HLP packet from the FILS HLP container element; (b) determine whether the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD associated with the source MAC address of the association or re-association request frame; (c) respond to determining that the extracted source MAC address Matches the MLD MAC address of the non-AP STA MLD: (i) builds a frame containing the HLP packet; (ii) transmits the frame to the upstream network or BSS. Additionally, process 1200 may also involve discarding the FILS HLP container element in response to determining that the extracted source MAC address does not match the MLD MAC address of the non-AP STA MLD.

In some implementations, when performing the FILS process, process 1200 may involve each of apparatus 1110 and apparatus 1120 passing multiple APs in the AP MLD and multiple STAs in the non-AP STA MLD over multiple links, The authentication process is performed using one public key for multiple links. In some implementations, Diffie-Hellman values among multiple APs in an AP MLD may be common across multiple links. Similarly, Diffie-Hellman values among multiple STAs in the non-AP STA MLD may be common across multiple links.

In some implementations, in performing a FILS process, process 1200 may involve each of device 1110 and device 1120 using the PMK and PMKID to perform an authentication process. In some implementations, each of the PMK and PMKID may be generated using MLD-level information related to the AP MLD and the non-AP STA MLD.

In some implementations, in performing the FILS process, the process 1200 may involve the means 1110 implemented in the non-AP STA MLD to perform the authentication process by: (a) generating an authentication frame by: (i) for The MLD MAC address of the non-AP STA MLD is encoded, and the MLD MAC address is the WM MAC address of each link of one or more supported links in the multiple links; (ii) in the multi-link authentication frame The address element contains the encoded MAC address; (b) sends an authentication frame to the AP MLD.

In some implementations, in executing a FILS program, process 1200 may involve means 1120 implemented in AP MLD performing an authentication process by: (a) generating an authentication frame by: (i) encoding the AP MLD's The MLD MAC address, which is the WM MAC address of each of one or more supported links among multiple links; (ii) contained in the multilink address element of the authentication frame MAC address; (b) Send authentication frame to non-AP STA MLD.

In some implementations, when performing a FILS process, process 1200 may involve means 1120 implemented in AP MLD may perform an association or re-association process by: (a) generating an association or re-association by constructing a key transfer element response frame, where the key transfer element indicates: (i) the current GTK and key RSC associated with each of the multiple links, (ii) with the the current IGTK and IPN associated with each of the plurality of links, and (iii) the current BIGTK and BIPN associated with each of the plurality of links if beacon protection is enabled; (b) Send an Association or Reassociation Response frame to the non-AP STA MLD. In some implementations, the key transfer element may contain a KDE list field that includes a multi-link GTK KDE, a multi-link IGTK KDE, and one or more A multilink BIGTK KDE associated with each of the links.

In some implementations, the multi-link GTK KDE may include: (i) a key ID field indicating the value of the GTK key identifier, (ii) a Transmit field indicating on which to transmit GTK's link, (iii) link ID field to indicate the link on which GTK is to be installed, and (iv) key RSC field contained in the link ID field RSC for GTK installed on the indicated link. In some implementations, for an AP MLD and a non-AP STA MLD that support the same key identifier, the GTK key identifier may be MLD-level.

In some implementations, a multi-link IGTK KDE may include: (i) a key ID field indicating the value of the IGTK key identifier, (ii) a link ID field indicating on which IGTK will be installed​​ TK's link, (iii) IPN field, which corresponds to the last packet number used by the sender on the link indicated by the link ID field, and this last packet number is used by the receiver as the BIP replay counter for IGTK (replay counter) initial value. In some implementations, the IGTK key identifier may be at MLD level for AP MLD and non-AP STA MLD that support the same key identifier.

In some implementations, a multi-link BIGTK KDE may include: (i) a key ID field indicating the value of the BIGTK key identifier, (ii) a link ID field indicating on which BIGTK will be installed​​ TK's link, (iii) BIPN field, which corresponds to the BIPN value carried in the MME of the last protected beacon frame on the link indicated by the link ID field, and this BIPN value is used by the receiver as The initial value of the BIP replay counter of BIGTK. In some implementations, the BIGTK key identifier may be at MLD level for AP MLD and non-AP STA MLD that support the same key identifier.

In some implementations, in communication, process 1200 may involve each of device 1110 and device 1120 sending or receiving a retransmitted frame with the key ID field in the CCMP or GCMP header of the retransmitted frame Equal to the Key ID field of the first transmitted MPDU. Supplementary Note

The herein described subject matter sometimes illustrates different components contained within, or connected with, various other components. It is to be understood that these depicted architectures are examples only, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, independent of architectures or intermediary components. Likewise, any two components so associated can also be viewed as being "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably coupled" to each other. "Operationally coupleable" to achieve the desired functionality. Specific examples of operatively coupleable components include, but are not limited to, physically matable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactive components.

Furthermore, with regard to the substantial use of any plural and/or singular terms herein, one skilled in the art may convert from plural to singular and/or from singular to plural as appropriate to the context and/or application. For the sake of clarity, various singular/plural reciprocities may be explicitly set forth herein.

Additionally, those skilled in the art will understand that terms used herein, and especially in the appended claims (eg, the subject of the appended claims), generally mean "open" terms For example, the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", and so on. Those skilled in the art will also understand that if a specific number of an incorporated claim recitation is intended, such intent will be expressly recited in the claim, and no such recitation is present in the absence of such recitation. intention. For example, as an aid to understanding, the appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce the claims' recitations. However, use of such phrases should not be construed to imply that the introduction of a claim list by the indefinite article "a" or "an" limits any particular claim containing such an introduced claim list to only includes one such enumerated implementation even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a and /or a" shall be construed to mean "at least one" or "one or more"), the same applies to the use of the definite article used to introduce a claim enumeration. In addition, even if a specific number of an incorporated claim recitation is expressly recited, those skilled in the art will recognize that such a recitation should be construed to mean at least that recited number (e.g., in the absence of other modifiers In the case of , an unambiguous listing of "two listings" means at least two listings or two or more listings). Furthermore, where a convention similar to "at least one of A, B, and C, etc." is used, such an interpretation is generally intended in the sense that one skilled in the art would understand this convention (e.g., "has A , B, and C" would include, but not limited to, A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C, etc. system). In those cases where a convention similar to "at least one of A, B, or C, etc." is used, such an interpretation is generally intended in the sense that those skilled in the art will understand the convention (e.g., "has A, B, etc. or C" will include, but not limited to, A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A together, systems of B and C, etc.). Those skilled in the art will also understand that any transitional word and/or phrase that actually presents two or more alternative items, whether in the specification, claims, or drawings, should be construed as contemplating the inclusion of those items. one, either, or both of these items. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B."

From the foregoing it will be appreciated that various implementations of the invention have been described herein for purposes of illustration and that various modifications may be made without departing from the scope and spirit of the invention. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the appended claims.

100: Network environment 110, 120: STA 200: FILS discovery frame 300: FD capability subfield 400: FILS Public Key Element 500: Key Delivery element 600: Multilink GTK KDE Elements 700: Multilink IGTK KDE Elements 800: Multilink BIGTK KDE Elements 900: RSN capability field 1000: scenes 1100: Example system 1110, 1120: device 1112,1122: Processor 1116, 1126: Transceiver 1114, 1124: memory 1200: Sample procedure 1210, 1220: box

The invention is shown by way of example and not limitation in the figures of the drawings, in which like reference numerals indicate like elements. When a particular feature, structure or characteristic is described in conjunction with an embodiment, it should be considered that it is within the knowledge of those skilled in the art to implement such feature, structure or characteristic in combination with other embodiments, whether or not explicitly stated otherwise. Figure 1 illustrates an example network environment in which various solutions and schemes according to the present invention can be implemented. Fig. 2 illustrates an example design of a FILS discovery frame under the proposed scheme according to the present invention. Fig. 3 illustrates an example design of the FD capability subfield under the proposed scheme according to the present invention. Fig. 4 illustrates an example design of a FILS public key element under the proposed scheme. Fig. 5 illustrates an example design of a Key Delivery element under the proposed scheme according to the present invention. Fig. 6 illustrates an example design of a multi-link GTK KDE element under the proposed scheme according to the present invention. Fig. 7 shows an example design of a multi-link IGTK KDE element under the proposed scheme according to the present invention. Fig. 8 illustrates an example design of a multi-link BIGTK KDE element under the proposed scheme according to the present invention. FIG. 9 illustrates an example design of a Robust Security Network (RSN) capability field (Capabilities field) under the proposed scheme according to the present invention. Figure 10 shows an example scenario of RSNA key rekeying under the proposed scheme. Figure 11 shows an example communication system according to an embodiment of the present invention. Figure 12 illustrates an example process in accordance with an implementation of the invention.

1200: Sample procedure 1210, 1220: box

Claims (20)

A multi-link wireless communication method, comprising: performing a fast initial link setup (FILS) procedure to communicate between an access point (AP) multi-link device (MLD) and a non-AP station (STA) MLD on multiple links and after completing the FILS process, communicate through one or more links in the plurality of links, wherein the FILS discovery frame sent during the FILS process includes the AP Short SSID of 4 octets for MLD. The multi-link wireless communication method as in claim 1, wherein the multi-link existence indicator subfield in the FILS discovery capability subfield in the FILS discovery information field of the FILS discovery frame is set to 1, To indicate that the SSID of the AP MLD is different from the SSID of the AP sending the FILS discovery frame among the multiple APs in the AP MLD. The multi-link wireless communication method of claim 2, wherein the FILS discovery information field further includes a short MLD SSID subfield, and the short SSID of 4 octets is included in the short MLD SSID subfield in place. The multi-link wireless communication method as claimed in claim 1, wherein the execution of the FILS process includes that the non-AP STA MLD performs an association or re-association process through high-level protocol (HLP) encapsulation in the following manner: constructing a FILS HLP container element to form HLP packet; sending the FILS HLP container element to the AP MLD in an association or re-association request frame, wherein the FILS HLP container element includes a destination media access control (MAC) address, a source MAC address, and a media An HLP packet in an access control service data unit (MSDU) format, wherein the source MAC address includes the MLD MAC address of the non-AP STA MLD. The multi-link wireless communication method as claimed in claim 4, wherein the execution of the FILS process further includes the AP MLD receiving and decapsulating the HLP packet by extracting the destination MAC address from the FILS HLP container element , the source MAC address and the HLP packet; determine the extracted source MAC address and the MLD MAC address of the non-AP STA MLD associated with the source MAC address of the association or re-association request frame matches; and in response to determining that the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD: constructing a frame containing the HLP packet; and transmitting the frame to an upstream network or basic service set, wherein the FILS HLP container element is discarded in response to determining that the extracted source MAC address does not match the MLD MAC address of the non-AP STA MLD. The multi-link wireless communication method according to claim 1, wherein the execution of the FILS process includes passing the multiple APs in the AP MLD and the multiple APs in the non-AP STA MLD on the multiple links STAs perform an authentication process using one public key of the plurality of links. The multi-link wireless communication method as claimed in claim 6, wherein the Diffie-Hellman values in the multiple APs in the AP MLD are common on the multiple links, and the non-AP STA MLDs The Diffie-Hellman values in the multiple STAs are common among the multiple links. The multi-link wireless communication method as claimed in claim 1, wherein the execution of the FILS process includes performing an authentication process using a paired master key (PMK) and a paired master key identifier (PMKID), and wherein the PMK and each of the PMKIDs are generated using MLD-level information related to the AP MLD and the non-AP STA MLD. The multi-link wireless communication method as claimed in claim 1, wherein the FILS process Executing includes the non-AP STA MLD performing an authentication process by: generating an authentication frame by: encoding the MLD MAC address of the non-AP STA MLD, the MLD MAC address being one of the plurality of links a wireless medium WM MAC address for each of the one or more supported links; and including the encoded MAC address in the multilink address element of the authentication frame; and sending the authentication to the AP MLD frame. The multi-link wireless communication method as claimed in claim 1, wherein the execution of the FILS process includes the AP MLD performing an authentication process by: generating an authentication frame by: encoding the MLD MAC address of the AP MLD, the The MLD MAC address is the WM MAC address of each of the one or more supported links in the plurality of links; the encoded MAC address is included in the multilink address element of the authentication frame ; and sending the authentication frame to the non-AP STA MLD. The multi-link wireless communication method according to claim 1, wherein the execution of the FILS process includes the AP MLD performing the association or re-association process in the following manner: generating an association or re-association response message by constructing a key transmission element box, wherein the Key Transfer element indicates: the current Group Temporary Key GTK and the Key Received Sequence Counter RSC associated with each of the plurality of links, where Management Frame Protection is enabled the current integrity group temporary key IGTK and the IGTK packet number IPN associated with each of the plurality of links, and, if beacon protection is enabled, the The current beacon integrity group temporary key BIGTK and BIGTK packet number BIPN associated with each link; Send the association or re-association response frame to the non-AP STA MLD, wherein the key transmission element may include a key data package KDE list field, and the KDE list field includes multi-link GTK KDE, A multi-link IGTK KDE and a multi-link BIGTK KDE associated with each of the one or more links of the plurality of links that sent the key transfer element. The multi-link wireless communication method of claim item 11, wherein the multi-link GTK KDE includes: a key identification word ID field, used to indicate the value of the GTK key identification word, and a sending field, indicating the value used to send the The link of the GTK, the link ID field, indicating the link on which the GTK will be installed, and the key RSC field, the key RSC field includes the link to be installed on the link indicated by the link ID field The RSC of the GTK, wherein, for the AP MLD and the non-AP STA MLD supporting the same key identifier, the GTK key identifier is at the MLD level. The multi-link wireless communication method as in claim item 11, wherein the multi-link IGTK KDE includes: a key ID field indicating the value of the IGTK key identification word, and a link ID field indicating that all links will be installed on it The link of the IGTK, the IPN field, corresponds to the last packet number used by the sender on the link indicated by the link ID field, and the last packet number is used by the receiver as the broadcast integrity of the IGTK The initial value of the BIP replay counter for the protocol BIP, where the IGTK key identifier is at the MLD level for the AP MLD and the non-AP STA MLD supporting the same key identifier. The multi-link wireless communication method according to claim 11, wherein the multi-link BITKK KDE includes: Key ID field, indicating the value of the BIGTK key identifier, Link ID field, indicating the link on which said BIGTK will be installed, and BIPN field, corresponding to the last link on the link indicated by said Link ID field The BIPN value carried in the Management Message Integrity Check Element MME of a protected beacon frame and used by the receiver as the initial value of the BIP replay counter of the BIGTK, where, for the same key supported The AP MLD and the non-AP STA MLD of the identification word, the BIGTK key identification word is MLD level. The multi-link wireless communication method according to claim 1, wherein the communication includes sending or receiving a retransmitted frame, and the cipher block chain message authentication code protocol CCMP or Galois/counter mode protocol GCMP of the retransmitted frame The key ID field in the header is equal to the key ID field of the MAC protocol data unit MPDU transmitted for the first time. A multi-link wireless communication apparatus, comprising: a transceiver configured to communicate wirelessly; and a processor coupled to the transceiver and configured to perform the following operations: execute a FILS process via the transceiver to establishing wireless communication between the AP MLD and the non-AP STA MLD on a plurality of links; and communicating via the transceiver on one or more of the plurality of links after completion of the FILS procedure, Wherein, the FILS discovery frame sent in the FILS process includes the 4-octet short SSID of the AP MLD. The multi-link wireless communication device as in claim 16, wherein the multi-link presence indicator subfield in the FILS discovery capability subfield in the FILS discovery information field of the FILS discovery frame is set to 1, To indicate that the SSID of the AP MLD is different from the SSID of the AP that sends the FILS discovery frame among the plurality of APs in the AP MLD, and wherein, the FILS The discovery information field also includes a short MLD SSID subfield in which the short SSID of 4 octets is included. The multi-link wireless communication device according to claim 16, wherein the processor is implemented in the AP MLD or the non-AP STA MLD, wherein: when implemented in the non-AP STA MLD, when executing the When describing the FILS process, the processor executes the association or re-association program through HLP encapsulation by constructing a FILS HLP container element to form an HLP packet, the FILS HLP container element including destination MAC address, source MAC address, and MSDU format HLP packet, the source MAC address includes the MLD MAC address of the non-AP STA MLD; and the FILS HLP container element is sent to the AP MLD in an association or re-association request frame, and when in the AP When implemented in MLD, when executing the FILS process, the processor receives and decapsulates the HLP packet by extracting the destination MAC address, the source MAC address, and the determining whether the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD associated with the source MAC address of the association or re-association request frame; and in response to determining matching the extracted source MAC address with the MLD MAC address of the non-AP STA MLD: constructing a frame containing the HLP packet; and transmitting the frame to an upstream network or BSS, or responding Upon determining that the extracted source MAC address does not match the MLD MAC address of the non-AP STA MLD, the FILS HLP container element is discarded. The multi-link wireless communication device as claimed in claim 16, wherein, after executing the FILS During the process, the processor uses the multiple APs in the AP MLD and the multiple STAs in the non-AP STA MLD on the multiple links to use one public gold of the multiple links key to perform an authentication process, wherein the Diffie-Hellman values in the plurality of APs in the AP MLD are common on the plurality of links, and the non-AP STAs in the plurality of STAs in the MLD Diffie-Hellman values are common among the plurality of links. The multi-link wireless communication device according to claim 16, wherein, when implemented in the AP MLD, when executing the FILS process, the processor performs the association or re-association process in the following manner: by constructing a key transmitting an element to generate an association or reassociation response frame, wherein the key transmission element indicates: the GTK and key RSC associated with each link in the plurality of links, when management frame protection is enabled The IGTK and IPN associated with each of the plurality of links if beacon protection is enabled, and the current BIGTK and BIPN; and sending the association or re-association response frame to the non-AP STA MLD, wherein the key transfer element may include a KDE list field including a multi-link GTK KDE , a multi-link IGTK KDE, and a multi-link BIGTK KDE associated with each of the one or more links of the plurality of links that send the key transfer element.

Images