Wireless communication method and apparatus for multiple links

Abstract

The present application provides a kind of multi-link wireless communication method and device.The method includes: performing fast initial link establishment (FILS) procedure to establish wireless communication between access point (AP) multi-link device (MLD) and non-AP STA MLD on multiple links;And after completing the FILS procedure, communication is carried out through one or more links in multiple links. Wherein, the FILS discovery frame sent in the FILS procedure indicates whether the service set identifier (SSID) of the AP MLD is different from the SSID of the AP in the multiple APs in the AP MLD which sends the FILS discovery frame.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more particularly, to extreme-high-throughput (EHT) fast initial link setup (FILS) support in multi-link operation in wireless communications. BACKGROUND

[0002] The methods described in this section are not prior art to the claims listed and are not admitted to be prior art by inclusion in this section.

[0003] In a wireless local area network (WLAN), a station (STA) needs to discover an access point (AP) first to establish communication (e.g., transmit and receive data) with the AP. Under the current Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification, an AP can broadcast a FILS discovery beacon to facilitate a STA to discover the AP within a communication range to establish a communication link with the AP. Link establishment generally includes a discovery procedure, an authentication procedure, and an association procedure. A FILS discovery frame is used in the known procedures. However, when the AP is an AP multi-link device (MLD) and / or the STA is a STA MLD, some modifications are needed to the FILS discovery frame as currently defined in order to support multi-link operation. For example, for an AP MLD, although the AP in the AP MLD has its own service set identifier (SSID), the AP MLD can have an MLD-level SSID that is different from the SSID of the AP. Therefore, the currently defined FILS discovery frame needs to be modified to indicate such information. In addition, some modifications are needed to the current IEEE specification to support EHT FILS in multi-link operation. SUMMARY

[0004] The following summary is illustrative only and is not intended to be in any way limiting. I.e., the following summary is presented to introduce some novel and non-obvious concepts, highlights, benefits, and advantages of the technology described herein. Selected implementations are described in further detail in the following detailed description. Thus, the following summary is intended to be indicative, but not limiting, of the nature of the claimed subject matter and is not intended to serve as an aid by itself in determining the scope of the claimed subject matter.

[0005] It is an object of the present application to provide solutions, concepts, designs, techniques, methods and apparatuses related to EHT FILS support in multi-link operation in wireless communications. The problems described herein can be solved under various proposed solutions according to the present application.

[0006] In one aspect, a method of multi-link wireless communication is provided, comprising: performing a fast initial link setup (FILS) procedure to establish wireless communication between an access point (AP) multi-link device (MLD) and a non-AP station (STA) MLD over multiple links; and communicating over one or more of the multiple links after completion of the FILS procedure. Wherein a FILS discovery frame transmitted in the FILS procedure indicates 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 that transmits the FILS discovery frame.

[0007] In another aspect, a multi-link wireless communication apparatus is provided, comprising a transceiver configured to perform wireless communication and a processor coupled to the transceiver. And the processor is configured to perform the following operations: performing a FILS procedure via the transceiver to establish wireless communication between an AP MLD and a non-AP STA MLD over multiple links; and communicating via the transceiver over one or more of the multiple links after completion of the FILS procedure. Wherein a FILS discovery frame transmitted in the FILS procedure indicates 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 that transmits the FILS discovery frame.

[0008] By the present application, extreme-high-throughput (EHT) fast initial link setup (FILS) support in multi-link operation in wireless communications can be achieved.

[0009] Notably, while the description provided herein can be in the context of certain radio access technologies, networks, and network topologies, such as Wi-Fi, for example, Long-Term Evolution (LTE), LTE-A, LTE-A Pro, 5G, New Radio (NR), Internet-of-Things (IoT), Narrow Band Internet of Things (NB-IoT), and Industrial Internet of Things (IIoT), the proposed concepts, schemes, and any variants / derivatives thereof can be implemented in, for, and by other types of radio access technologies, networks, and network topologies. Thus, the scope of the invention is not limited to the examples described herein. BRIEF DESCRIPTION OF DRAWINGS

[0010] The accompanying drawings are included to provide a further understanding of the present application, illustrate the principles of the application, and constitute a part of the detailed description of the application. The drawings illustrate embodiments of the present application and, together with the description, serve to explain the principles of the present application. It is understood that the drawings are not necessarily to scale, as some components can be shown exaggerated in scale or with exaggerated proportions in order to illustrate an aspect of the present application.

[0011] Figure 1 An example network environment is illustrated in which various solutions and schemes according to the present application can be implemented.

[0012] Figure 2 An example design of a FILS Discovery frame under the proposed schemes according to the present application is illustrated.

[0013] Figure 3 An example design of a FD Capability subfield under the proposed schemes according to the present application is illustrated.

[0014] Figure 4 An example design of a FILS Public Key element under the proposed schemes according to the present application is illustrated.

[0015] Figure 5 An example design of a Key Delivery element under the proposed schemes according to the present application is illustrated.

[0016] Figure 6 An example design of a Multi-Link GTK KDE element under the proposed schemes according to the present application is illustrated.

[0017] Figure 7 An example design of a Multi-Link IGTK KDE element under the proposed schemes according to the present application is illustrated.

[0018] Figure 8 An example design of the multi-link BIG TKDE element under the proposed scheme according to the present application is illustrated.

[0019] Figure 9 An example design of the Robust Security Network (RSN) Capabilities field under the proposed scheme according to the present application is illustrated.

[0020] Figure 10 An example scenario of RSNA rekeying under the proposed scheme is shown.

[0021] Figure 11 An example communication system according to an embodiment of the present application is shown.

[0022] Figure 12 An example process according to an implementation of the present application is shown. DETAILED DESCRIPTION

[0023] 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 for the purposes of exemplification and are not intended to limit the claimed subject matter in any manner. The present application can be embodied in various forms and should not be construed as limited to the examples set forth herein. These examples are provided so that this disclosure will be thorough and complete, and fully convey the scope of the application 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 present application.

[0024] SUMMARY

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

[0026] Figure 1 An example network environment 100 in which various solutions and schemes according to the present application can be implemented is illustrated. Figures 2 to 12 An example of an implementation of various proposed schemes in the network environment 100 according to the present application is illustrated. Reference is made to Figures 1 to 12 The following description of various proposed schemes is provided.

[0027] Referring to Figure 1 , the network environment 100 can include a STA 110 and a STA 120, which can wirelessly communicate over multiple links (e.g., Link 1, Link 2, and Link 3) according to one or more IEEE 802.11 standards, such as IEEE 802.11be and beyond. Each of the STA 110 and the STA 120 can function as an MLD. For example, the STA 110 can function as a non-AP MLD, which has multiple virtual STAs (e.g., STA 1, STA 2, and STA 3) operating within the STA 110. Correspondingly, the STA 120 can function as an AP MLD, which has multiple virtual APs (e.g., AP 1, AP 2, and AP 3) operating within the STA 120. Under various proposed schemes according to the present disclosure, the STA 110 and the STA 120 can be configured to perform EHT FILS support in multi-link operation in wireless communication according to various proposed schemes described herein.

[0028] Figure 2 An example design 200 of a FILS discovery frame under proposed schemes according to the present disclosure is illustrated. Referring to Figure 2 Part (A), the FILS discovery frame can include various information fields, in which the various information fields include a FILS discovery information (FILS Discovery Information) field. Referring to Figure 2 Part (B), among various information subfields of the FILS discovery information field, there is a FILS discovery capability (FILS Discovery (FD) Capability) subfield. The FD capability subfield can include several subfields, including a multiple links presence indicator subfield, which can indicate whether the AP (e.g., the STA 120) that transmits the FILS discovery frame supports multi-link operation as part of an AP MLD. For example, the multiple links presence indicator subfield can be set to 1 to indicate that there is a multiple links element in the beacon and probe response frames. On the other hand, the multiple links presence indicator subfield can be set to 0 to indicate that there is no multiple links element in the beacon and probe response frames.

[0029] Figure 3 An example design 300 of the FD capability subfield under proposed schemes according to the present disclosure is illustrated. Referring to Figure 3The FD capability subfield can include a plurality of subfields, including a multi-link 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 different AP MLD SSID from the SSID of the AP (e.g., AP1, AP2, or AP3 of STA 120) that transmitted the FILS discovery frame, the FILS discovery information field can further include a short MLD SSID subfield, as shown in part (B) of Figure 2 The short MLD SSID subfield can contain a 4-octet short SSID of the AP MLD (e.g., as defined in Section 9.4.2.170 (Reduced Neighbor Report element) of the IEEE specification).

[0030] Under the proposed scheme according to the present disclosure on higher-layer protocol (HLP) encapsulation, a FILS HLP Container element can be used to encapsulate HLP packets. Under the proposed scheme, in case of HLP encapsulation by a non-AP STA MLD (e.g., STA 110), the non-AP STA MLD can construct a FILS HLP Container element for each HLP packet. The non-AP STA MLD can then put multiple FILS HLP Container elements into an Association (or Reassociation) Request frame, as long as they fit within the size limit of a Medium Access Control (MAC) Management Protocol Data Unit (MMPDU). The HLP packets in the FILS HLP Container element can contain any MAC Service Data Unit (MSDU) format (e.g., as defined in Section 5.1.4 (MSDU format) of the IEEE specification). Under the proposed scheme, the encapsulation process can involve the non-AP STA MLD populating one or more FILS HLP Container elements with a destination MAC address, a source MAC address of the HLP packet, and the HLP packet in MSDU format. The source MAC address can be the MLD MAC address of the non-AP STA MLD. The encapsulation process can further involve the non-AP STA MLD including the FILS HLP Container element into the Association (or Reassociation) Request frame.

[0031] 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 will not transmit the HLP packet until a key confirmation is successfully completed (e.g., as defined in Section 12.12.2.6 (Key confirmation with FILS authentication) of the IEEE specification). After the key confirmation is successful, the AP MLD can forward the HLP packet to an upstream network or a basic service set (BSS) according to the destination MAC address of the HLP packet. The order of forwarding the HLP packet can be the same as the order of the FILS HLP container elements in the association (or re-association) request frame. If the key confirmation fails, the AP MLD can discard the HLP packet, and the AP MLD can also filter the HLP packet according to certain rules.

[0032] Under the proposed scheme, the packet decapsulating procedure of each FILS HLP container element can include the AP MLD extracting the destination MAC address, the source MAC address, and the HLP packet from a given FILS HLP container element. Then, the procedure can include the AP verifying that the extracted source MAC address is equal to the MLD MAC address of the non-AP STA MLD (e.g., STA 110) associated with the source MAC address of the association (or re-association) request frame. If these addresses are different, the AP can discard the FILS HLP container element. Next, the procedure can include the AP constructing a frame in an appropriate format using the extracted destination MAC address, the extracted source MAC address, and the HLP packet to transmit the HLP packet to an upstream network or a BSS.

[0033] Under the proposed scheme, after receiving an association (or re-association) request frame, the AP MLD can 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 an upstream network or BSS with the non-AP STA MLD’s MLD MAC address or group address as the destination address before sending the association (or re-association) response frame, the AP MLD can send each HLP packet in a different FILS HLP container element in the association (or re-association) response frame. The order of the FILS HLP container elements in the association (or re-association) response frame can be the same as the received order of the HLP packets. If the AP MLD receives an HLP packet for the non-AP STA MLD after sending the association (or re-association) response frame, the AP MLD can send the HLP packet as a data frame. If the AP does not receive any HLP packets with the non-AP STA MLD’s MLD MAC address or group address as the destination address from an upstream network or BSS before sending the association (or re-association) response frame, the AP MLD does not send any FILS HLP container element in the association (or re-association) response frame. Under the proposed scheme, the status code in the association (or re-association) response frame can not be affected by the presence or absence of a FILS HLP container element.

[0034] Under the proposed scheme regarding HLP encapsulation according to the present application, the packet encapsulation procedure of the AP MLD (e.g., STA 120) for each FILS HLP container element can include certain operations. First, the AP MLD can set the fields of the HLP container element by some means. For example, the AP MLD can set the Destination MAC Address field to the destination MAC address of the received HLP packet, which can be the MLD MAC address or group address of the non-AP STA MLD (e.g., STA 110). If the destination MAC address of the received HLP packet is not the same as the MLD MAC address of the non-AP STA MLD, but is equal to one of the wireless medium (WM) MAC addresses of the non-AP STA MLD, 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. Furthermore, the AP MLD can set the HLP Packet field to the MSDU-formatted HLP packet. Then, the AP MLD can include the FILS HLP container element in the association (or re-association) response frame. Next, the AP MLD can transmit the association (or re-association) response frame.

[0035] Under the proposed scheme regarding HLP encapsulation according to the present application, if the non-AP STA MLD (e.g., STA 110) receives the association (or re-association) response frame with one or more FILS HLP container elements, the non-AP STA MLD can first perform key confirmation. After the key confirmation is successful, the non-AP STA MLD can generate a MA-UNITDATA.indication primitive for each HLP packet. The order of generating the MA-UNITDATA.indication primitive for the HLP packet can be the same as the order of the FILS HLP container element in the association (or re-association) response frame. In the case of key confirmation failure, the non-AP STA MLD can discard the HLP packet.

[0036] Under the proposed scheme according to the present disclosure with respect to HLP encapsulation, the data packet decapsulation procedure by a non-AP STA MLD (e.g., STA 110) for each FILS HLP container element can include certain operations. First, the non-AP STA MLD can extract the destination MAC address, source MAC address, and HLP data packet. Then, the non-AP STA MLD can verify whether the extracted destination MAC address is equal to the MLD MAC address or group address of the non-AP STA MLD. If the destination MAC address is not for the non-AP STA MLD, then the non-AP STA MLD can discard the FILS HLP container element. Next, the non-AP STA MLD can generate a MA-UNITDATA.indication primitive with a plurality of parameters, including, for example, but not limited to: source address (extracted source MAC address), destination address (extracted destination MAC address), routing information (all), data (extracted HLP data packet), reception status (success), priority (contention), and service class (which can be Quality of Service Acknowledgement (QoSAck) when the destination address is a single address, or Quality of Service Negative Acknowledgement (QoSNoAck) when the destination address is not a single address).

[0037] Under the proposed scheme according to the present disclosure with respect to the FILS Public Key element, all APs in an AP MLD (e.g., AP1, AP2, and AP3 in STA 120) can use one public key in multiple links (e.g., Link 1, Link 2, and Link 3), and all non-AP STAs in a non-AP STA MLD (e.g., STA1, STA2, and STA3 in STA 110) can use one public key in multiple links. Under the proposed scheme, the Diffie-Hellman value in all APs in an AP MLD can be common in multiple links. Similarly, the Diffie-Hellman value in all non-AP STAs in a non-AP STA MLD can be common in multiple links.

[0038] Under the proposed scheme, the FILS Public Key element can be used to convey the (authenticated) public key of one device to be used with the FILS authentication exchange. Figure 4 An example design 400 of the FILS Public Key element under the proposed scheme is illustrated. Referring to Figure 4The FILS public key element can include an Element ID field, a Length field, and an Element ID Extension field (e.g., as defined in Section 9.4.2.1 (General) of the IEEE specification). The FILS public key element can 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 an X.509 v3 certificate encoded according to Internet Engineering Task Force (IETF) Request for Comments (RFC) 5280. The Key Type field can be set to 2 to indicate that the FILS public key field contains an unauthenticated public key encoded according to IETF RFC 5480. The Key Type field can be set to 3 to indicate that the FILS public key field contains an unauthenticated public key encoded according to IETF RFC 3279. Values 0 and 4-255 of the Key Type field can be reserved.

[0039] Under the proposed scheme according to the present application on key establishment through FILS Shared Key authentication, the non-AP STA MLD and the AP MLD can perform key establishment using an authentication frame and key confirmation using an association (or re-association) request frame and an association (or re-association) response frame. If the non-AP STA MLD chooses to initiate FILS Shared Key authentication, the non-AP STA MLD can first select a random 16-octet nonce, and then determine whether to attempt Pairwise Master Key Securing Association (PMKSA) caching. In the case of attempting PMKSA caching, the non-AP STA MLD can generate a list of PMKSA identifiers. If the non-AP STA MLD attempts to initiate an Extensible Authentication Protocol (EAP) registration procedure (RP) (EAP-RP), the non-AP STA MLD can construct an EAP-initiate / Re-auth packet according to IETF RFC 6696, and make some remarks. For example, regarding the EAP-RP flags, 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 a Trusted Third Party (TTP) sharing the rRK with the STA will provide the lifetime of the rRK and rMSK in an EAP-Finish / Re-auth packet. In addition, the EAP Identifier can be set to 0, and the Cryptosuite field can not be set to 1. Under the proposed scheme, in the case of requiring Perfect Forward Secrecy (PFS), the non-AP STA MLD can select the finite cyclic group frame dot11RSNAConfigDLCGroupTable.This can include identifying a number from a repository of "Group Description" attributes maintained by the Internet Assigned Numbers Authority (IANA) as IETF RFC 2409 (IKE). The STA MLD can then generate an ephemeral private key and perform a group's scalar-op (e.g., as per Section 12.4.4.1 of the IEEE specification (General)) using its random ephemeral private key and a generator from the selected finite cyclic group to compute an ephemeral public key.

[0040] Under the proposed scheme, the non-AP STA MLD can construct an authentication frame in some manner. For example, depending on whether PFS is used or not, the non-AP STA MLD can set the authentication algorithm number to 4 (for FILS shared key authentication without PFS) or 5 (for FILS shared key authentication with PFS) (e.g., as defined in Section 9.4.1.1 of the IEEE specification (Authentication Algorithm Number field)). The non-AP STA MLD can also set the authentication transaction sequence number to 1. The random nonce can be encoded in the FILS Nonce element (e.g., as defined in Section 9.4.2.189 of the IEEE specification (FILS Nonce element (11ai))). If a list of PMKSA identifiers is generated, the non-AP STA MLD can use the list to construct the PMKID List field in the Robust Security Network element. The random FILS session can be encoded in the FILS Session element (e.g., 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 (e.g., as defined in Section 9.4.2.187 of the IEEE specification (FILS Wrapped Data element (11ai))). In the case where PFS is required, the selected finite cyclic group can be encoded in the Finite Cyclic Group field (e.g., as defined in Section 9.4.1.42 of the IEEE specification (Finite Cyclic Group field)), and the temporary public key can be encoded in the FFE field (e.g., as defined in Section 9.4.1.40 of the IEEE specification (FFE field)) according to the element to octet string conversion in Section 12.4.7.2.4 of the IEEE specification.Further, the wireless medium (WM) MAC address (including the STA MLD address) and the MLD MAC address of each link of the supported multiple links can be encoded in a Multiple Link Address element. After constructing the authentication frame, the non-AP STA MLD can send the authentication frame to the AP MLD.

[0041] Under the proposed scheme, in the case that PMKSA cache is not used and the AP MLD is not connected to or does not recognize an authentication server (identified by the realm in the key Name-NAI field of the EAP-Initiate / Re-auth packet used by the non-AP STA MLD), the AP MLD can send an authentication frame with the Status Code field set to 113 to indicate to the non-AP STA MLD that the authentication is rejected due to an unknown authentication server. Otherwise, the AP MLD can generate its own nonce and construct an authentication frame for the non-AP STA MLD. The AP MLD can copy the FILS Session element in the authentication frame sent by the non-AP STA MLD into the response authentication frame. If PMKSA cache is not used, this frame can 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 the AP MLD can contain the ephemeral public key of the AP MLD. In this frame, the AP MLD can set the authentication algorithm number to 4 or 5 depending on whether PFS is used, and the AP MLD can set the Authentication sequence number to 2. In the case that PMKSA cache is used, the AP can indicate the selected PMKID in the PMKID list. In the case that PFS is used for exchange, the AP MLD can perform the group’s scalar-op (e.g., as defined in Section 12.4.4.1 (General) of the IEEE specification) with the ephemeral public key of the STA MLD and its own ephemeral private key to generate the ephemeral Diffie-Hellman shared secret (DHss). Under the proposed scheme, the AP MLD can encode the WM MAC address of each link of the multiple links supported (including the AP MLD address) and the MLD MAC address of the AP MLD in a Multiple Link Address element, which the AP MLD can include in the authentication frame. In addition, the AP MLD can send the authentication frame to the non-AP STA MLD.After sending the FILS authentication frame, the AP can proceed with key establishment as per section 12.12.2.5 of the IEEE specification (Key establishment with FILS authentication).

[0042] Under the proposed scheme, a Pairwise Master Key (PMK) can be derived using two nonces and secret information from the FILS key establishment procedure. A PMK Identifier (PMKID) can be generated from the negotiated Authentication and Key Management (AKM) on input data specific to the FILS key establishment using a hash algorithm. Depending on the negotiated AKM, the PMK can be 256 bits or 384 bits in length, while the PMKID can be 128 bits in length. If FILS Shared Key authentication is used to generate the input keying material, the PMK and PMKID can be derived as follows:

[0043] PMK = HMAC-Hash (SNonce || ANonce, rMSK [|| DHss])

[0044] PMKID = Truncate-128 (Hash (EAP-Initiate / Reauth))

[0045] When FILS Public Key authentication is used to generate the input keying material, the PMK and PMKID can be derived as follows:

[0046] PMK = HMAC-Hash (SNonce || ANonce, DHss]) (MLD-level)

[0047] PMKID = Truncate-128 (Hash (gSTA || gAP)) (MLD-level)

[0048] Here, SNonce denotes an STA MLD nonce, ANonce denotes an AP MLD nonce. Further, rMSK denotes a shared secret from the EAP-RP exchange, DHss denotes a shared secret derived from the Diffie-Hellman exchange when it is performed, as only the x-coordinate from the Elliptic Curve Diffie-Hellman is included when using Elliptic Curve Cryptography (ECC). The square brackets denote that the shared secret is included when the Diffie-Hellman exchange is performed, otherwise it is not. EAP-Initiate / Reauth denotes an EAP-RP packet sent by the STA using the key establishment procedure with FILS shared key authentication. Further, gSTA denotes the Diffie-Hellman value of the STA MLD, gAP denotes the Diffie-Hellman value of the AP MLD. Hash denotes the hash algorithm specific to the negotiated AKM (see Table 9-151 of the IEEE specification (AKM suite selectors)).

[0049] For Pairwise Transient Key Security Association (PTKSA) key generation, the input to the pseudo-random function (PRF) can be the PMK of the PMKSA, a constant label, and a concatenation of the STA MLD MAC address, the AP MLD MAC address, the nonce of the STA MLD, and the nonce of the AP MLD. When the negotiated AKM is 00-0F-AC:14 or 00-0F-AC:16, the length of the Key Encryption Key (KEK) can be 256 bits, and the length of the Integrity Check Value Key (ICK) can be 256 bits. When the negotiated AKM is 00-0F-AC:15 or 00-0F-AC:17, the length of the KEK can be 512 bits, and the length of the ICK can be 384 bits. When the negotiated AKM is 00-0F-AC:16, the FILS-FT (fast transition) 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. Thus, the total number of bits extracted from the key derivation function (KDF) can be 512+TK bits, 896+TK bits, or 1280+TK bits, depending on the negotiated AKM, where TK bits are determined as follows:

[0050] FILS-Key-Data = PRF - X (PMK, "FILS PTK KDerivation", SPR || AA || SNonce || ANonce [|| DHss])

[0051] ICK = L (FILS-Key-Data, 0, ICK_bits)

[0052] KEK = L (FILS-Key-Data, ICK_bits, KEK_bits)

[0053] TK = L (FILS-Key-Data, ICK_bits + KEK_bits)

[0054] When FILS authentication is used to perform a fast transition (FT) initial mobility domain association, FILS-FT can be determined as follows:

[0055] FILS-FT = L(FILS-Key-Data, ICK_bits + KEK_bits + TK_bits, FILS-FT_bits)

[0056] 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 of FILS-FT in bits when FILS authentication is used to perform an FT initial mobility domain association. X can be 512+TK bits, 768+TK bits, 896+TK bits, or 1280+TK bits in IEEE specification Table 12-7 (Cipher suite key lengths) depending on the negotiated AKM. PMK represents the PMK from the PMKSA when PMKSA caching is used, which can be created from an initial FILS connection or from a cached PMKSA. When FILS authentication is used to perform an FT initial mobility domain association, it is equal to the Master PMK (MPMK) (e.g., as defined in Section 12.7.1.6.3 (PMKR0) of the IEEE specification). SPA represents the STA MLD MAC address, AA represents the AP MLD MAC address, ANonce represents the STA MLD’s nonce, ANonce represents the AP MLD’s nonce, and DHss represents the shared secret information derived from the Diffie-Hellman exchange when the Diffie-Hellman exchange is performed and PMKSA caching is used. Furthermore, the square brackets represent the inclusion of the shared secret information when the Diffie-Hellman exchange is performed while PMKSA caching is used, and otherwise represent the absence of the shared secret information. After generating FILS-Key-Data, the shared secret information DHss can be irreversibly deleted if the Diffie-Hellman exchange was performed.

[0057] Under the proposed scheme for association (or re-association) request with FILS key confirmation according to the present application, the key confirmation for FILS authentication can be an association (or re-association) request frame followed by an association (or re-association) response frame. The components of the association (or re-association) request frame and the association (or re-association) response frame can be protected using KEK. The STA MLD can construct the association (or re-association) request frame for FILS authentication (e.g., according to Section 9.3.3.5 (Association Request frame format) and Section 9.3.3.7 (Reassociation Request frame format) of IEEE specification). A hash algorithm can be used to generate the FILS Key Confirmation element, and the specific hash algorithm can depend on the negotiated AKM (e.g., according to Section 9.4.2.24.3 (AKM suites) of IEEE specification).

[0058] Under the proposed scheme, for FILS shared key authentication and FILS public key authentication when using PMKSA cache, the KeyAuth field of the FILS Key Confirmation element can be constructed by using a Hash-Based Message Authentication Code (HMAC) mode of the negotiated hash algorithm, with the negotiated hash algorithm utilizing the ICK key and the concatenation of the nonce of the STA MLD, the nonce of the AP MLD, the STA MLD MAC address, the AP MLD MAC address, and conditionally the public Diffie-Hellman value of the STA MLD and the public Diffie-Hellman value of the AP MLD, as follows:

[0059] Key-Auth = HMAC-Hash (ICK, SNonce || ANonce || STA-MLD-MAC || AP-MLD-MAC [|| gSTA || gAP])

[0060] Here, Hash denotes a hash algorithm specific to the negotiated AKM (see Table 9-151 of IEEE specification (AKM suite selectors)), SNonce denotes a nonce of the STA MLD, ANonce denotes a nonce of the AP MLD, STA-MLD-MAC denotes an MLD MAC address of the STA MLD, AP-MLD-MAC denotes an MLD MAC address of the AP MLD, gSTA denotes a public value of Diffie-Hellman of the STA MLD, gAP denotes a public value of Diffie-Hellman of the AP MLD, and the square brackets denote that the Diffie-Hellman public values are included when PFS is performed through FILS Shared Key authentication or PMKSA cache is performed through FILS Public Key authentication.

[0061] For FILS Public Key authentication when PMKSA cache is not used, the KeyAuth field of the FILS Key Confirmation element can be a digital signature of a private key of the STA MLD using a negotiated hash algorithm for a concatenation of the public Diffie-Hellman value of the STA MLD, the public Diffie-Hellman value of the AP MLD, the nonce of the STA MLD, the nonce of the AP MLD, the STA MLD MAC address, and the AP MLD MAC address in the following order:

[0062] Key-Auth = Sig-STA(gSTA || gAP || SNonce || ANonce || STA-MLD-MAC || AP-MLD-MAC)

[0063] Here, Sig-STA() denotes a digital signature using a private key of the STA MLD (similar to a trusted public key of the STA MLD). The form of the signature can depend on the type of public key used by the STA MLD (see RSA section of IETF RFC 3447, DSA section of FIPS 186-4, and ECDSA section of ISO / IEC 14888-3). The data to be signed can be first hashed, and the hash algorithm used with the appropriate digital signature algorithm can be specific to the negotiated AKM.

[0064] Under the proposed scheme, the association (re-association) request frame can be encrypted using an Authenticated Encryption with Associated Data (AEAD) algorithm (e.g., as defined in Section 12.12.2.7 (AEAD cipher mode for FILS) of IEEE specification) with KEK as the key. The Additional Authentication Data (AAD) used with the AEAD algorithm for the association request frame can include the following data, which are passed as separate components in the following order: (i) the MAC address of the STA, (ii) the basic service set identifier (BSSID) of the AP, (iii) the nonce of the STA, (iv) the nonce of the AP, and (v) the contents of the from capabilities information field (contained in) to the FILS session element (contained in) of the association (re-association) request frame. In addition, the Additional Authentication Data (AAD) used with the AEAD algorithm for the association request frame can include (vi) the STA MLD MAC address and (vii) the AP MLD MAC address. The plaintext passed to the AEAD algorithm can be the data after the FILS session element in the unencrypted frame body. The output of the AEAD algorithm can become the data after the FILS session element in the encrypted and authenticated association (re-association) request frame. The output of the algorithm can be as specified in IETF RFC 5116. The resulting association (re-association) request frame can be transmitted 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 are different, the authentication exchange fails.

[0065] Under the proposed scheme, the AP MLD can decrypt and verify the received association (re-association) request frame using the KEK as a key with an AEAD algorithm (e.g., as defined in Section 12.12.2.7 of the IEEE specification (AEAD cipher mode for FILS)). 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. If the output of the AEAD decryption operation returns a failure indication, the authentication exchange fails. If the output does not return a failure indication, the output plaintext can replace the ciphertext as the portion of the frame body following the FILS session element, and the processing of the received frame can continue by checking the value of the FILS key confirmation element. The AP MLD can verify that the RSNE received in the association (re-association) 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 shared key authentication, the AP MLD can construct the verifier Key-Auth' in the same way as the STA MLD constructed its Key-Auth, as described above. The AP MLD can compare the Key-Auth' with the KeyAuth field in the FILS key confirmation element of the received frame. If they are different, the authentication fails.

[0066] For FILS public key authentication, the AP MLD can use the (authenticated) 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 formed by the STA MLD according to the used signature scheme by concatenating in order the following: the public Diffie-Hellman value of the STA (gSTA), the public Diffie-Hellman value of the AP (gAP), the nonce of the STA (SNonce), the nonce of the AP (ANonce), the MAC address of the STA (STA-MAC), and the BSSID of the AP (AP-BSSID). Furthermore, the AP MLD can cryptographically and from a security policy perspective check all the certificates in the certificate chain according to the procedure of checking certificates and certificate chains in IETF RFC 5280. If any of these verifications fails, the authentication fails.

[0067] Under the proposed scheme, if the authentication is deemed to fail, the ICK, KEK, TK, and PTKSA can be irreversibly deleted, and the AP MLD can return an authentication frame with a status code set to 112 to indicate "authentication denied due to FILS authentication failure". If no PMKSA cache is used in this failed authentication attempt, the PMKSA can also be deleted. If the PMKSA cache is used, the reason for the failure can be an impersonation attack. Therefore, when a FILS with PMKSA cache fails, the AP MLD can decide to keep the cached PMKSA.

[0068] Under the proposed scheme according to the present application regarding the Association (Reassociation) Response frame for FILS key confirmation, the AP MLD can construct an Association (Reassociation) Response frame for FILS authentication (e.g., as in Section 9.3.3.6 (Association Response frame format) and Section 9.3.3.8 (Reassociation Response frame format) of IEEE specification). As with the Association (Reassociation) Request frame, a hash algorithm can be used to generate the FILS Key Confirmation element, and the specific hash algorithm can depend on the negotiated AKM (see Section 9.4.2.24.3 (AKM suites)). In addition, the AP MLD can construct a Key Delivery element to indicate the current Group Temporal Key (GTK) and key receive sequence counter (RSC) for each link in the multiple links, the current Integrity Group Temporal Key (IGTK) and IGTK packet number (IPN) for each link in the multiple links (if management frame protection is enabled), the current Beacon Integrity Group Temporal Key (BIGTK) and BIGTK packet number (BIPN) for each link in the multiple links (if beacon protection is enabled). The AP MLD can put the Key Delivery element into the Association (Reassociation) Response frame.

[0069] Figure 5 An example design 500 of the Key Delivery element under the proposed scheme according to the present application is illustrated. Refer to Figure 5The key transfer element can 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 (KDE) list field. The key RSC field can contain a receive sequence counter (RSC) for a GTK that is being installed onto the link from which the key transfer element is sent. The KDE list field can contain one or more KDEs encapsulated using a predefined format. For example, the KDE list field can include a GTK KDE, an IGTK KDE, and a BIGTK KDE for the same link from which the key transfer element is sent. In addition, the KDE list field can include a multi-link GTK KDE, a multi-link IGTK KDE, and a multi-link BIGTK KDE for a different link from which the key transfer element is sent.

[0070] Figure 6 An example design 600 of a multi-link GTK KDE element under the proposed scheme according to the present application is illustrated. Referring to Figure 6 The multi-link GTK KDE element can 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 a GTK field. The key ID field can indicate a value of a GTK key identifier. The transmit (Tx) field can indicate a link over which the GTK is being transmitted. If the value of the Tx field is 1, then the IEEE 802. IX component can configure a temporal key derived from the KDE into the IEEE 802.11 MAC (#2507) for both transmission and reception. If the value of the Tx field is 0, then the IEEE 802. IX component can configure a temporal key derived from the KDE into the IEEE 802.11 MAC (#2507) for reception only. The link ID field can indicate a link (e.g., an operating class and a primary channel number) for which the GTK is being installed. The key RSC field can contain a receive sequence counter (RSC) for the GTK that is being installed on the link indicated by the link ID field. The transmission of the RSC field value can enable the STA to recognize a MAC protocol data unit (MPDU) that is replayed on the link indicated by the link ID field. If the RSC field value is less than 8 octets in length, then the remaining octets can be set to 0. The least significant octet of a transmit sequence counter (TSC) or a packet number (PN) can be in the first octet of the RSC field.

[0071] Figure 7FIG. 7 shows an example design 700 of a multi-link IGTK KDE element according to the proposed scheme of the present invention. Figure 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 may indicate the link on which the IGTK is being installed (e.g., the operating category 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 an initial value for a Broadcast Integrity Protocol (BIP) replay counter for the IGTK.

[0072] Figure 8 An example design 800 of a multi-link BIGTK KDE element according to the proposed scheme of the present invention is illustrated. Figure 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 may indicate the value of the BIGTK key identifier. The link ID field may indicate the link on which the BIGTK is being installed (e.g., the operating category and primary channel number). The BIPN field may correspond to the BIPN value carried in the Management Message Integrity Check (MIC) element (MME) of the last protected Beacon frame on the link indicated by the link ID field, and it may be used by the receiver as the initial value of the BIP replay counter of the BIGTK.

[0073] Under the proposed solution of the present invention, for FILS shared key authentication and FILS public key authentication when using PMKSA caching, the KeyAuth field of the FILS key confirmation element can be constructed as follows using the HMAC mode of the negotiated hash algorithm, where the negotiated hash algorithm utilizes the ICK key and the concatenation of the AP MLD's nonce, the STA MLD's nonce, the AP MLD's MAC address, the STA MLD's MAC address, and conditionally the AP MLD's public Diffie-Hellman value and the STA MLD's public Diffie-Hellman value:

[0074] Key-Auth = HMAC-Hash (ICK, ANonce || SNonce || AP-MLD-MAC || STA-MLD-MAC [|| gAP || gSTA])

[0075] Here, Hash denotes the hash algorithm specific to the negotiated AKM, ANonce denotes the nonce of the AP MLD, SNonce denotes the nonce of the STA MLD, AP-MLD-MAC denotes the MLD MAC address of the AP MLD, STA-MLD-MAC denotes the MLD MAC address of the STA MLD, gAP denotes the Diffie-Hellman public value of the AP MLD, gSTA denotes the Diffie-Hellman public value of the STA MLD, and the square brackets denote that the Diffie-Hellman public values are included when Perfect Forward Secrecy (PFS) is performed by FILS Shared Key authentication. Otherwise, it denotes that the Diffie-Hellman public values are not included.

[0076] Under the proposed scheme, for FILS public key authentication when the PMKSA cache is not used, the Key-Auth field of the FILS Key Confirmation element can be a digital signature of the AP MLD private key using the output of the negotiated hash algorithm based on concatenation of the public Diffie-Hellman value of the AP MLD, the public Diffie-Hellman value of the STA MLD, the nonce of the AP MLD, the nonce of the STA MLD, the AP MLD MAC address, and the STA MLD MAC address in the following order. The specific construction of the digital signature can depend on the cryptographic system of the public / private key pair, as follows:

[0077] Key-Auth = Sig-AP (gAP || gSTA || ANonce || SNonce || AP-MLD-MAC || STA-MLD-MAC)

[0078] Here, Sig-AP() can denote a digital signature using the private key of the AP MLD (similar to the trusted public key of the AP MLD). The form of the signature can depend on the type of public key used by the AP MLD (see RSA section of IETF RFC 3447, DSA section of FIPS 186-4, and ECDSA section of ISO / IEC 14883-3). The data to be signed can be first hashed, and the hash algorithm used with the appropriate digital signature algorithm can be specific to the negotiated AKM.

[0079] Under the proposed solution according to the present application, an AEAD algorithm (e.g., as defined in Section 12.12.2.7 of IEEE specification (AEAD cipher mode for FILS)) can be used with KEK as the key to encrypt the association (re-association) response frame. The Additional Authentication Data (AAD) used with the AEAD algorithm for the association (re-association) response frame can include the following data, which are passed as separate components in the following order: BSSID of the AP, MAC address of the STA, nonce of the AP, nonce of the STA, and contents of the From Capabilities Information field (contained in) to the FILS Session Element (contained in) of the association (re-association) response frame. In addition, the Additional Authentication Data (AAD) used with the AEAD algorithm for the association response frame can include the STA MLD MAC address and the AP MLD MAC address. The plaintext passed to the AEAD algorithm can be the data after the FILS Session Element in the unencrypted frame body. The output of the AEAD algorithm can become the data after the FILS Session Element in the encrypted and authenticated association (re-association) response frame. The output of the algorithm can be as specified in IETF RFC 5116. The resulting association (re-association) response frame can be transmitted to the STA MLD.

[0080] Under the proposed scheme, the STA MLD can decrypt and verify the received association (re-association) response frame using an AEAD algorithm (e.g., as defined in Section 12.12.2.5 of the IEEE specification (Key establishment with FILS authentication)) with KEK as the key. 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 can compare the FILS session of the received frame with the FILS session selected to identify the STA MLD of the FILS. If they are different, the authentication fails. If the output of the AEAD decryption operation returns a failure indication, the authentication exchange fails. If the output does not return a failure indication, the output plaintext can replace the ciphertext as the part of the frame body following the FILS session element, and the processing of the received frame can continue by checking the value of the FILS key confirmation element. The STA MLD can verify that the RSNE received in the association (re-association) response frame contains the same AKM suite and cipher suites and RSN capabilities as in the beacon, probe response, and authentication frames from the AP MLD. If these fields are different, the authentication fails.

[0081] Under the proposed scheme, for FILS shared key authentication, the STA MLD can construct the verifier Key-Auth' in the same way as the AP constructs its Key-Auth described above. The STA MLD can compare Key-Auth' with the KeyAuth field in the FILS key confirmation element of the received frame. If they are different, the authentication fails. For FILS public key authentication, the STA MLD can use the AP MLD (authenticated) public key from the FILS public key element to verify that the signature contained in the KeyAuth field corresponds to the signature formed by the AP according to the used signature scheme by concatenating in order the following: the public Diffie-Hellman value of the AP (gAP), the public Diffie-Hellman value of the STA (gSTA), the nonce of the AP (ANonce), the nonce of the STA (SNonce), the BSSID of the AP (AP-BSSID), and the MAC address of the STA (STA-MAC). Furthermore, the AP MLD can check all the certificates in the certificate chain cryptographically and from a security policy perspective according to the procedure of checking certificates and certificate chains in IETF RFC 5280. If any of these verifications fails, the authentication fails.

[0082] Under the proposed solution, if the authentication is deemed to fail, the ICK, KEK, PMK and TK can be irreversibly deleted and the STA MLD shall abort the exchange. Otherwise, the authentication is successful and the STA MLD and the AP MLD can irreversibly delete the nonpersistent secret keying material created through the key establishment procedure of FILS Shared Key authentication (see, e.g., Section 12.12.2.3 of the IEEE specification (Key establishment with FILS Shared Key authentication)) or created through the key establishment procedure of FILS Public Key authentication (see, e.g., Section 12.12.2.4 of the IEEE specification (Key establishment with FILS Public Key authentication)). The KEK and PMK can be used for subsequent key management (e.g., as specified in Section 12.6 of the IEEE specification (RSNA security association management)). In case the 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, the STA MLD and the AP MLD can set the lifetime of the PMKSA to the value dotllRSNAConfigPMKLifetime. After successfully completing the FILS authentication procedure, the STA MLD can process the Key Delivery element in the Association (Re-association) Response frame. The STA MLD can install the GTK and the key RSC, and install the IGTK and IPN for each of the multiple links in case management frame protection is enabled, and install the BIGTK and BIPN for each of the multiple links in case BIGTK and BIPN are present in the Key Delivery element and dotllBeaconProtectionEnabled is true.

[0083] Figure 9An example design 900 of a Robust Security Network (RSN) Capabilities field is illustrated under the proposed scheme according to the present application. As shown Figure 9 The RSN Capabilities field can contain a number of subfields, including an Extended Key ID for Individually Addressed Frames subfield, as shown. When the cipher suite is either the Cipher Block Chaining Message Authentication Code Protocol (CCMP) or the Galois / Counter Mode Protocol (GCMP), the Extended Key ID for Individually Addressed Frames subfield (at bit 13 or B13 of the RSN Capabilities field) can be set to 1 to indicate that the STA supports a key ID value in the range 0-1 for the PTKSA.

[0084] Under the proposed scheme according to the present application regarding Robust Security Network Association (RSNA) rekeying, when both ends of the link support the Extended Key ID for Individually Addressed Frames, a new PTKSA can be installed without loss of data, provided that the new PTKSA uses a different key ID than the old PTKSA. Notably, if the same key ID is used, data loss can occur because precise coordination is not possible (due to software processing delays) when the new key is used for transmission at one end and it is used for reception at the other end. If the new PTKSA uses a different key ID, precise coordination can not be needed, assuming that the new key is installed at the receiving side before it is first used at the transmitting side. During the transition, the key ID can be used to explicitly identify received data packets as belonging to the old or new PTKSA.

[0085] Under the proposed scheme, if the RSN Capabilities field of the individual addressing frame's Extended Key ID subfield is 1 for both the Authenticator and the Supplicant, the Authenticator can assign a new Key ID in the range 0-1 for the PTKSA, which is different from the Key ID assigned in the previous handshake, and in addition, the Authenticator can use the MLME SET KEYS.request primitive to install the new key to receive individually addressed MPDUs protected by the PTK (associated with the assigned Key ID). Otherwise, Key ID 0 can be used and the installation of the key can be deferred until after the reception of message 4. The Authenticator can send message 3 to the Supplicant. It is noted that the Authenticator IEEE 802.11 MAC can continue to send protected, individually addressed MPDUs (if any) using the existing key, if the existing PTK is still valid. By installing the new key for reception, the Authenticator is able to receive protected, individually addressed MPDUs using the old key (if present) or the new key.

[0086] Figure 10 An example scenario 1000 of RSN A key rekeying under the proposed scheme is shown. Referring to Figure 10 , the RSN A key rekeying procedure can use two keys. In the scenario 1000, the keys can be in place (for reception processing) for two handshake periods. The PTKSA lifetime can be two handshake periods. The new key installation can replace the old key with the same Key ID. Thus, having two active keys can allow a smooth, time- relaxed transition from one PTKSA to the next PTKSA.

[0087] Under the proposed scheme according to the present application with respect to CCMP encapsulation, the PN value can number each MPDU sequentially. Each transmitter can maintain a single PN (e.g., 48-bit counter) per PTKSA and Group Temporal Key Security Association (GTKSA). The PN can be implemented as a 48-bit value of strictly increasing integers and is initialized to 1 when the corresponding temporal key is initialized or refreshed.

[0088] Under the proposed scheme according to the present disclosure regarding GCMP encapsulation, the PN value can sequentially number each MPDU. Each transmitter can maintain a single PN (e.g., 48-bit counter) for each PTKSA and GTKSA. The PN can be implemented as a 48-bit value of strictly increasing integer and initialized to 1 when the corresponding temporal key is initialized or refreshed.

[0089] Under the proposed scheme according to the present disclosure regarding RSNA key update in multi-link operation, when a STA (e.g., STA 110) re-encrypts a frame for retransmission on the same link or different links, the STA can set the value of the key ID field in the CCMP or GCMP header to be the same as the value of the key ID field of the MPDU of the first transmission. Otherwise, replay detection can have difficulty due to different PN spaces for different key IDs.

[0090] Exemplary Implementations

[0091] Figure 11 An example system 1100 is shown that has at least an example apparatus 1110 and an example apparatus 1120 according to embodiments of the present disclosure. Each of the apparatus 1110 and the apparatus 1120 can perform various functions to implement the schemes, techniques, processes, and methods described herein related to EHT FILS support in multi-link operation in wireless communications, including various schemes with reference to the various proposed designs, ideas, schemes, systems, and methods described above and the processes described below. For example, the apparatus 1110 can be an example implementation of the STA 110 and the apparatus 1120 can be an example implementation of the STA 120.

[0092] Each of the apparatus 1110 and the apparatus 1120 can be part of an electronic device, which can be a STA or an AP, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, each of the apparatus 1110 and the apparatus 1120 can be implemented in a smart phone, a smart watch, a personal digital assistant, a digital camera, or a computing device such as a tablet computer, a laptop computer, or a notebook computer. Each of the apparatus 1110 and the apparatus 1120 can also be part of a machine type device, which can be an IoT device, a home device, a wired communication device, or a computing device such as an immovable or fixed device. For example, each of the apparatus 1110 and the apparatus 1120 can 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, the apparatus 1110 and / or the apparatus 1120 can be implemented in a network node such as an AP in a WLAN.

[0093] In some implementations, each of the apparatus 1110 and the apparatus 1120 can 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 multi-core processors, one or more reduced-instruction-set computing (RISC) processors, or one or more complex-instruction-set computing (CISC) processors. In various scenarios described above, each of the apparatus 1110 and the apparatus 1120 can be implemented in or as a STA or an AP. Each of the apparatus 1110 and the apparatus 1120 can include at least a portion of the components shown in FIG. 11, such as the processor 1112 and the processor 1122, respectively. Figure 11 Each of the apparatus 1110 and the apparatus 1120 can also include one or more other components that are not relevant to the proposed solutions of the present application (e.g., an internal power supply, a display device, and / or a user interface device), and thus, for simplicity and brevity, none of these components of the apparatus 1110 and the apparatus 1120 are shown in FIG. 11. Figure 11

[0094] In an aspect, each of the processor 1112 and the processor 1122 can be implemented in the form of one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors. That is, even though the singular term “processor” is used herein to refer to the processor 1112 and the processor 1122, each of the processor 1112 and the processor 1122 can include multiple processors in some implementations, and a single processor in other implementations. In another aspect, each of the processor 1112 and the processor 1122 can be implemented in the form of hardware (and, optionally, firmware), having electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactors, configured and arranged to perform certain tasks as described above.

[0095] ​In some implementations, the apparatus 1110 can also include a transceiver 1116 coupled to the processor 1112. The transceiver 1116 can transmit and receive data wirelessly. In some implementations, the apparatus 1120 can also include a transceiver 1126 coupled to the processor 1122. The transceiver 1126 can include a transceiver capable of wirelessly transmitting and receiving data. The transceiver 1116 of the apparatus 1110 and the transceiver 1126 of the apparatus 1120 can communicate with each other over one or more of a plurality of links Link 1 - Link N (e.g., a first link and a second link), where N > 1.

[0096] In some implementations, the apparatus 1110 can further include a memory 1114 coupled to the processor 1112 and accessible to the processor 1112 for storing data. In some implementations, the apparatus 1120 can also include a memory 1124 coupled to the processor 1122 and accessible to the processor 1122 for storing data. Each of the memory 1114 and the memory 1124 can include a random-access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero capacitor RAM (Z-RAM). Alternatively or additionally, each of the memory 1114 and the memory 1124 can include a read-only memory (ROM), such as a mask ROM (MASK ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively or additionally, each of the memory 1114 and the memory 1124 can include a non-volatile random-access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase change memory.

[0097] Each of the apparatus 1110 and the apparatus 1120 can be a communication entity capable of communicating with each other using various proposed solutions according to the present application. For illustrative purposes and not limitation, the capabilities of the apparatus 1110 (the apparatus 1110 as a STA 110, which is a constrained non-AP MLD) and the capabilities of the apparatus 1120 (the apparatus 1120 as a STA 120, which can be a constrained AP MLD) are described below. Notably, while the example implementations described below are provided in the context of a WLAN, the same can be implemented in other types of networks as well.

[0098] In the proposed solution for EHT FILS support in multi-link operation in wireless communications according to the present disclosure, each of the processor 1112 of the apparatus 1110 and the processor 1122 of the apparatus 1120 implemented in the non-AP STA MLD and the AP MLD, respectively, can perform a FILS procedure to establish wireless communications between the AP MLD and the non-AP STA MLD over multiple links. Further, after the FILS procedure is completed, each of the processor 1112 of the apparatus 1110 and the processor 1122 of the apparatus 1120 can communicate over one or more of the multiple links.

[0099] In some implementations, the FILS discovery frame transmitted in the FILS procedure can indicate whether the SSID of the AP MLD is different from the SSID of the AP in the plurality of APs in the AP MLD that transmits the FILS discovery frame.

[0100] In some implementations, a Multiple Links Presence Indicator subfield in a FD Capability subfield in a 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 in the plurality of APs in the AP MLD that transmits the FILS discovery frame. In some implementations, the FILS Discovery Information field can further include a Short MLD SSID subfield containing a 4-octet short SSID of the AP MLD, in the case that the Multiple Links Presence Indicator subfield is set to 1.

[0101] In some implementations, in performing the FILS procedure, the processor 1112 implemented in the non-AP STA MLD can perform an association or re-association procedure through HLP encapsulation by: (a) constructing a FILS HLP Container element to form an HLP data packet; and (b) transmitting the FILS HLP Container element to the AP MLD in an association or re-association request frame. In some implementations, the FILS HLP Container element can include a destination MAC address, a source MAC address, and an MSDU formatted HLP data packet. Further, the source MAC address can include or be the MLD MAC address of the non-AP STA MLD.

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

[0103] In some implementations, while performing the FILS procedure, each of the processor 1112 of the apparatus 1110 and the processor 1122 of the apparatus 1120 implemented in the non-AP STA MLD and the AP MLD, respectively, can perform an authentication procedure using one public key of a plurality of links over a plurality of APs in the AP MLD and a plurality of STAs in the non-AP STA MLD on the plurality of links. In some implementations, a Diffie-Hellman value in the plurality of APs in the AP MLD can be common across the plurality of links. Similarly, a Diffie-Hellman value in the plurality of STAs in the non-AP STA MLD can be common across the plurality of links.

[0104] In some implementations, while performing the FILS procedure, each of the processor 1112 and the processor 1122 implemented in the non-AP STA MLD and the AP MLD, respectively, can perform an authentication procedure using a PMK and a PMKID. In some implementations, each of the PMK and the PMKID can be generated using MLD level information related to the AP MLD and the non-AP STA MLD.

[0105] In some implementations, while performing the FILS procedure, the processor 1112 implemented in the non-AP STA MLD can perform an authentication procedure by: (a) generating an authentication frame by: (i) encoding a MLD MAC address of the non-AP STA MLD that is a WMMAC address of each link of one or more supported links in the plurality of links; (ii) including the encoded MAC address in a multi-link address element of the authentication frame; (b) sending the authentication frame to the AP MLD.

[0106] In some implementations, in performing a FILS procedure, the processor 1122 implemented in an AP MLD can perform an authentication procedure by: (a) generating an authentication frame by: (i) encoding an MLD MAC address of the AP MLD, which is a WM MAC address of each link of one or more supported links in the plurality of links; (ii) including the encoded MAC address in a multi-link address element of the authentication frame; (b) transmitting the authentication frame to a non-AP STA MLD.

[0107] In some implementations, in performing a FILS procedure, the processor 1122 implemented in an AP MLD can perform an association or re-association procedure by: (a) generating an association or re-association response frame by constructing a key delivery element, wherein the key delivery element indicates: (i) a current GTK and a key RSC associated with each link in the plurality of links, (ii) a current IGTK and IPN associated with each link in the plurality of links in case management frame protection is enabled, and (iii) a current BIGTK and BIPN associated with each link in the plurality of links in case beacon protection is enabled; (b) transmitting the association or re-association response frame to a non-AP STA MLD. In some implementations, the key delivery element can contain a KDE list field that includes a multi-link GTK KDE, a multi-link IGTK KDE, and a multi-link BIGTK KDE associated with each link of one or more links in the plurality of links for which the key delivery element is transmitted.

[0108] In some implementations, the multi-link GTK KDE can include: (i) a key ID field indicating a value of a GTK key identifier, (ii) a transmit field indicating a link for which the GTK is transmitted, (iii) a link ID field indicating a link for which the GTK is to be installed, and (iv) a key RSC field containing a RSC of the GTK installed on the link indicated by the link ID field. In some implementations, the GTK key identifier can be MLD-level for an AP MLD and a non-AP STA MLD supporting the same key identifier.

[0109] In some implementations, the multi-link IGTK KDE can include: (i) a Key ID field indicating a value of an IGTK key identifier, (ii) a Link ID field indicating a link on which the IGTK is to be installed, (iii) an IPN field corresponding to a last packet number used by a transmitter on the link indicated by the Link ID field, and the last packet number is used by a receiver as an initial value of a BIP replay counter for the IGTK. In some implementations, the IGTK key identifier can be MLD- wide for AP MLDs and non-AP STA MLDs supporting the same key identifier.

[0110] In some implementations, the multi-link BIGTK KDE can include: (i) a Key ID field indicating a value of a BIGTK key identifier, (ii) a Link ID field indicating a link on which the BIGTK is to be installed, (iii) a BIPN field corresponding to a BIPN value carried in an MME of a last protected beacon frame on the link indicated by the Link ID field, and the BIPN value is used by a receiver as an initial value of a BIP replay counter for the BIGTK. In some implementations, the BIGTK key identifier can be MLD-wide for AP MLDs and non-AP STA MLDs supporting the same key identifier.

[0111] In some implementations, in a communication, each of the processors 1112 and 1122 transmits or receives, via the transceiver 1116 or the transceiver 1126, respectively, a retransmitted frame having a Key ID field in a CCMP or GCMP header of the retransmitted frame equal to a Key ID field of a first transmitted MPDU.

[0112] Exemplary Processes

[0113] Figure 12 An example process 1200 in accordance with implementations of the present application is shown. The process 1200 can be representative of one aspect of implementing the various designs, concepts, schemes, systems, and methods presented above. More specifically, the process 1200 can be representative of one aspect of the presented concepts and schemes in relation to EHT FILS support in multi-link operations in wireless communications in accordance with the present application. The process 1200 can include one or more operations, actions, or functions as shown in one or more of blocks 1210 and 1220. Although shown as discrete blocks, each block of the process 1200 can be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Also, the blocks of the process 1200 can be performed in an order different from that shown, and / or various blocks of the process 1200 can be performed concurrently, depending on the desired implementation. Figure 12The order in which the operations are executed in process 1200 can be different than illustrated in FIG. 12, or the operations can be executed in different orders. Also, one or more of the blocks / sub-blocks of process 1200 can be executed repeatedly or iteratively. Process 1200 can be implemented by or realized in apparatuses 1110 and 1120, or any variants thereof. For illustrative purposes only and not limitation, process 1200 is described below in the context of apparatus 1110 as a STA 110 (e.g., a STA or an AP) of a wireless network (e.g., a WLAN compliant with one or more IEEE 802.11 standards) and apparatus 1120 as a STA 120 (e.g., a peer STA or an AP). Process 1200 can start at block 1210.

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

[0115] At 1220, process 1200 can involve each of apparatuses 1110 and 1120 communicating over one or more of the multiple links after completion of the FILS procedure.

[0116] In some implementations, a FILS discovery frame sent in the FILS procedure can indicate whether a SSID of the AP MLD is different from a SSID of an AP of the multiple APs in the AP MLD that sends the FILS discovery frame.

[0117] In some implementations, a Multiple Links Presence Indicator subfield in a FD Capacity subfield in a 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 of the multiple APs in the AP MLD that sends the FILS discovery frame. In some implementations, the FILS Discovery Information field can further include a Short MLD SSID subfield containing a 4-octet short SSID of the AP MLD, in a case that the Multiple Links Presence Indicator subfield is set to 1.

[0118] In some implementations, in performing the FILS procedure, the process 1200 can involve that the non-AP STA MLD can perform an association or re-association procedure by encapsulating, by the HLP, in the following manner: (a) constructing a FILS HLP Container element to form an HLP data packet; (b) sending the FILS HLP Container element in an association or re-association request frame to the AP MLD. In some implementations, the FILS HLP Container element can include a destination MAC address, a source MAC address, and the HLP data packet in MSDU format. Further, the source MAC address can include or be the MLD MAC address of the non-AP STA MLD.

[0119] In some implementations, in performing the FILS procedure, the process 1200 can further involve that the AP MLD can receive and decapsulate the HLP data packet in the following manner: (a) extracting the destination MAC address, the source MAC address, and the HLP data packet from the FILS HLP Container element; (b) 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; (c) in response to determining that the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD: (i) constructing a frame containing the HLP data packet; (ii) transmitting the frame to an upstream network or BSS. Further, the process 1200 can 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.

[0120] In some implementations, in performing the FILS procedure, the process 1200 can involve that each of the apparatus 1110 and the apparatus 1120 can perform an authentication procedure using one common public key of the plurality of links by a plurality of APs in the AP MLD and a plurality of STAs in the non-AP STA MLD over the plurality of links. In some implementations, the Diffie-Hellman value in the plurality of APs in the AP MLD can be common over the plurality of links. Similarly, the Diffie-Hellman value in the plurality of STAs in the non-AP STA MLD can be common over the plurality of links.

[0121] In some implementations, in performing the FILS procedure, the process 1200 can involve that each of the apparatus 1110 and the apparatus 1120 can perform an authentication procedure using a PMK and a PMKID. In some implementations, each of the PMK and the PMKID can be generated using MLD-level information related to the AP MLD and the non-AP STA MLD.

[0122] In some implementations, in performing a FILS procedure, the process 1200 can involve the apparatus 1110 implemented in a non-AP STA MLD can perform an authentication procedure by: (a) generating an authentication frame by: (i) encoding a MLD MAC address of the non-AP STA MLD that is a WM MAC address of each link of one or more supported links of the plurality of links; (ii) including the encoded MAC address in a multi-link address element of the authentication frame; (b) transmitting the authentication frame to the AP MLD.

[0123] In some implementations, in performing a FILS procedure, the process 1200 can involve the apparatus 1120 implemented in an AP MLD can perform an authentication procedure by: (a) generating an authentication frame by: (i) encoding a MLD MAC address of the AP MLD that is a WM MAC address of each link of one or more supported links of the plurality of links; (ii) including the encoded MAC address in a multi-link address element of the authentication frame; (b) transmitting the authentication frame to the non-AP STA MLD.

[0124] In some implementations, in performing a FILS procedure, the process 1200 can involve the apparatus 1120 implemented in an AP MLD can perform an association or re-association procedure by: (a) generating an association or re-association response frame by constructing a key delivery element that indicates: (i) a current GTK and key RSC associated with each link of the plurality of links, (ii) a current IGTK and IPN associated with each link of the plurality of links in case management frame protection is enabled, and (iii) a current BIGTK and BIPN associated with each link of the plurality of links in case beacon protection is enabled; (b) transmitting the association or re-association response frame to the non-AP STA MLD. In some implementations, the key delivery element can contain a KDE list field that includes a multi-link GTK KDE, a multi-link IGTK KDE, and a multi-link BIGTK KDE associated with each link of one or more links of the plurality of links for which the key delivery element is transmitted.

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

[0126] In some implementations, the multi-link IGTK KDE can include: (i) a Key ID field indicating a value of an IGTK key identifier, (ii) a Link ID field indicating a link on which the IGTK is to be installed, (iii) an IPN field corresponding to a last packet number used by a transmitter on the link indicated by the Link ID field and used by a receiver as an initial value of a BIP replay counter for the IGTK. In some implementations, the IGTK key identifier can be MLD-level for an AP MLD and a non-AP STA MLD supporting the same key identifier.

[0127] In some implementations, the multi-link BIGTK KDE can include: (i) a Key ID field indicating a value of a BIGTK key identifier, (ii) a Link ID field indicating a link on which the BIGTK is to be installed, (iii) a BIPN field corresponding to a BIPN value carried in an MME of a last protected beacon frame on the link indicated by the Link ID field and used by a receiver as an initial value of a BIP replay counter for the BIGTK. In some implementations, the BIGTK key identifier can be MLD-level for an AP MLD and a non-AP STA MLD supporting the same key identifier.

[0128] In some implementations, in a communication, the process 1200 can involve each of the apparatus 1110 and the apparatus 1120 transmitting or receiving a retransmitted frame having a Key ID field in a CCMP or GCMP header of the retransmitted frame equal to a Key ID field of a first transmitted MPDU.

[0129] Supplemental Explanation

[0130] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, 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, irrespective of architectures or intermediate 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 couplable", to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0131] Further, with respect to the numerous uses of the term "comprising" herein, such term is used in the sense of "including" and / or the sense of "consisting" so as to cover the respective scenarios "substantially consisting of", "consisting essentially of", and "consisting of". It is further noted that the claims can be drafted to exclude any elements or limit the use of "comprising". As such, these claims can be proper drawn to be exclusively "consisting of" or "consisting essentially of" the listed components.

[0132] In addition, those skilled in the art will appreciate that, in general, the terms used herein, and especially in the appended claims (e.g., in the body of the appended claims), are generally intended as "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that, unless otherwise indicated herein, the singular forms of terms used herein are intended to include the plural forms of those terms. Those skilled in the art will appreciate that, when certain claims are introduced that recite a specific number of an introduced claim recitation, that such an intent is expressly recited in the claim and that no such intent exists when such a recitation is not present. For example, as an aid in understanding, the appended claims can contain the use of the introductory phrases "at least one" and "one or more" of an introduced claim recitation. However, the use of such phrases should not be interpreted as implying that any specific claim limitation that follows the introductory phrase is limited to only one such claim limitation of the introduced claim recitation, 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 an" should be interpreted to mean "at least one" or "one or more"), the same applies to the use of the definite article to introduce a claim recitation. In addition, even when a specific number of an introduced claim recitation is expressly recited, those skilled in the art will recognize that such a recitation is to be interpreted to mean at least the recited number (e.g., an unqualified recitation of "two of the introduced claim recitations" means at least two of the introduced claim recitations or two or more of the introduced claim recitations) absent further modification. Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general, such a construction is intended to be interpreted in the same manner as "at least one of A, B, and C" even when the conjunctive phrase does not expressly appear. By way of example, the phrase "at least one of A, B, or C" should be construed to mean at least one of A, at least one of B, at least one of C, at least one of A and B, at least one of A and C, at least one of B and C, and at least one of A, B, and C. An exception to this is the use of two "at a time" or "two at a time" in the claims to indicate that an element must be present in at least one but only one of the claim limitations. In those instances, the phrase "two at a time" or "two at a time" is to be interpreted to mean that the element is to be present in at least one, but only one, of the claim limitations; e.g., the phrase "two at a time" preceding the introductory clause of a claim limitation is to be interpreted to mean that the element is to be present in at least one, but only one, of the claim limitations. Those skilled in the art will further understand that any disjunctive word or phrase, such as "among

[0133] In light of the above, it will be appreciated that the various implementations described herein have been described for the purpose of illustration only and that various modifications are possible without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, the true scope and spirit being indicated by the following claims.

Claims

1. A method of wireless communication of multi-link, comprising: performing a fast initial link setup (FILS) procedure to establish wireless communication between an access point (AP) multi-link device (MLD) and a non-AP station (STA) MLD on multiple links; and communicating over one or more of the multiple links after completion of the FILS procedure, wherein the performing of the FILS procedure comprises the AP MLD performing an association or re-association procedure by: generating an association or re-association response frame by constructing a key transfer element, wherein the key transfer element indicates: a current group temporal key (GTK) and a key receive sequence counter (RSC) associated with each of the multiple links, a current integrity group temporal key (IGTK) and an IGTK packet number (IPN) associated with each of the multiple links in case management frame protection is enabled, and a current beacon integrity group temporal key (BIGTK) and a BIGTK packet number (BIPN) associated with each of the multiple links in case beacon protection is enabled; sending the association or re-association response frame to the non-AP STA MLD.

2. The method of claim 1, wherein, a multi-link presence indicator subfield in a FILS discovery capabilities subfield in a FILS discovery information field of a FILS discovery frame sent in the FILS procedure is set to 1 to indicate that a service set identifier (SSID) of the AP MLD is different from a SSID of an AP of the multiple APs in the AP MLD that sends the FILS discovery frame.

3. The method of claim 2, wherein, in case the multi-link presence indicator subfield is set to 1, the FILS discovery information field further includes a short MLD SSID subfield that contains a 4 octet short SSID of the AP MLD.

4. The method of claim 1, wherein, the performing of the FILS procedure comprises performing an authentication procedure over the multiple links by the multiple APs in the AP MLD and multiple STAs in the non-AP STA MLD using one public key of the multiple links.

5. The method of claim 4, wherein Diffie-Hellman values in the multiple APs in the AP MLD are common across the multiple links, and Diffie-Hellman values in the multiple STAs in the non-AP STA MLD are common across the multiple links.

6. The method of claim 1, wherein the performing of the FILS procedure comprises performing an authentication procedure using a pairwise master key (PMK) and a pairwise master key identifier (PMKID), and wherein each of the PMK and the PMKID is generated by using MLD level information related to the AP MLD and the non-AP STA MLD.

7. The method of claim 1, wherein, the performing of the FILS procedure comprises the non-AP STA MLD performing an authentication procedure by: generating an authentication frame by: encoding a MLD MAC address of the non-AP STA MLD, the MLD MAC address being a wireless medium, WM, MAC address of each of one or more supported links of the plurality of links; and including the encoded MAC address in a multi-link address element of the authentication frame; and transmitting the authentication frame to the AP MLD.

8. The method of claim 1, wherein the performing of the FILS procedure comprises the AP MLD performing an authentication procedure by: generating an authentication frame by: encoding a MLD MAC address of the AP MLD, the MLD MAC address being a WM MAC address of each of one or more supported links of the plurality of links; including the encoded MAC address in a multi-link address element of the authentication frame; and transmitting the authentication frame to the non-AP STA MLD.

9. The method of claim 1, wherein, The key transfer element includes a key data encapsulation, KDE, list field, the KDE list field including a multi-link GTK KDE, a multi-link IGTK KDE, and a multi-link BIGTK KDE associated with each of one or more links of the plurality of links on which the key transfer element is transmitted.

10. The method of claim 9, wherein the multi-link GTK KDE includes: a key identifier, ID, field indicating a value of a GTK key identifier, a transmit field indicating a link on which the GTK is to be transmitted, a link ID field indicating a link on which the GTK is to be installed, and a key RSC field, the key RSC field including an RSC of the GTK installed on the link indicated by the link ID field, wherein the GTK key identifier is MLD level for the AP MLD and the non-AP STA MLD supporting the same key identifier.

11. The method of claim 9, wherein the multi-link IGTK KDE includes: a key ID field indicating a value of an IGTK key identifier, a link ID field indicating a link on which the IGTK is to be installed, an IPN field corresponding to a last packet number used by a transmitter on the link indicated by the link ID field, and the last packet number is used by a receiver as an initial value of a broadcast integrity protocol, BIP, replay counter for the IGTK, wherein the IGTK key identifier is MLD level for the AP MLD and the non-AP STA MLD supporting the same key identifier.

12. The method of claim 9, wherein the multi-link BIGTK KDE includes: a key ID field indicating a value of a BIGTK key identifier, a link ID field indicating a link on which the BIGTK is to be installed, wherein the BIGTK key identifier is MLD level for the AP MLD and the non-AP STA MLD supporting the same key identifier. a BIPN field, corresponding to a BIPN value carried in a management message integrity check element, MME, of a last protected beacon frame on a link indicated by the link ID field, and the BIPN value is used by a receiver as an initial value for a BIP replay counter of the BIGTK, wherein, for the AP MLD and the non-AP STA MLD supporting the same key identifier, the BIGTK key identifier is MLD level.

13. The method of claim 1, wherein, The communication includes transmitting or receiving a retransmitted frame, a key ID field in a cipher block chain message authentication code protocol, CCMP, or Galois / Counter Mode protocol, GCMP, header of the retransmitted frame is equal to a key ID field of a first transmitted MAC protocol data unit, MPDU.

14. A method of multi-link wireless communication, comprising: performing a fast initial link setup, FILS, procedure to establish wireless communication between an access point, AP, multi-link device, MLD, and a non-AP station, STA, MLD over multiple links; and communicating over one or more of the multiple links after completion of the FILS procedure, wherein the performing of the FILS procedure includes the non-AP STA MLD performing an association or re-association procedure via a high layer protocol, HLP, encapsulation by: constructing a FILS HLP container element to form an 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 an HLP packet in a media access control service data unit, MSDU, format, wherein the source MAC address includes an MLD MAC address of the non-AP STA MLD.

15. The method of claim 14, wherein the performing of the FILS procedure further includes the AP MLD receiving and decapsulating the HLP packet by: extracting the destination MAC address, the source MAC address, and the HLP packet from the FILS HLP container element; determining whether 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 match; 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 a basic service set, wherein, in response to 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.

16. An apparatus of multi-link wireless communication, comprising: a transceiver configured to communicate wirelessly; and a processor coupled to the transceiver and configured to: perform a FILS procedure via the transceiver to establish wireless communication between an AP MLD and a non-AP STA MLD over multiple links; and communicate via the transceiver over one or more of the multiple links after completion of the FILS procedure, wherein, when implemented in the AP MLD, the processor performs an association or re-association procedure when performing the FILS procedure by: generating an association or re-association response frame by constructing a key delivery element, wherein the key delivery element indicates: a GTK and a key RSC associated with each of the plurality of links, an IGTK and an IPN associated with each of the plurality of links in case management frame protection is enabled, and a current BIGTK and a BIPN associated with each of the plurality of links in case beacon protection is enabled; and sending the association or re-association response frame to the non-AP STA MLD.

17. The apparatus of claim 16, wherein, a multi-link presence indicator subfield in a FILS discovery capabilities subfield in a FILS discovery information field of a FILS discovery frame sent in the FILS procedure is set to 1 to indicate that the SSID of the AP MLD is different from the SSID of an AP in the plurality of APs in the AP MLD that sends the FILS discovery frame, and wherein, in case the multi-link presence indicator subfield is set to 1, the FILS discovery information field further includes a short MLD SSID subfield containing a 4 octet short SSID of the AP MLD.

18. The apparatus of claim 16, wherein, In performing the FILS procedure, the processor performs an authentication procedure over the plurality of links using one public key of the plurality of links by the plurality of APs in the AP MLD and a plurality of STAs in the non-AP STA MLD, wherein a Diffie-Hellman value in the plurality of APs in the AP MLD is common over the plurality of links and a Diffie-Hellman value in the plurality of STAs in the non-AP STA MLD is common in the plurality of links.

19. The apparatus of claim 16, wherein, the key delivery element contains 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 one or more links in the plurality of links that sent the key delivery element.

20. A wireless communication apparatus for multi-link comprising: a transceiver configured to communicate wirelessly; and a processor coupled to the transceiver and configured to perform the following operations: performing a FILS procedure via the transceiver to establish wireless communication between an AP MLD and a non-AP STA MLD over a plurality of links; and communicating via the transceiver over one or more of the plurality of links after the completion of the FILS procedure, wherein the processor is implemented in the AP MLD or the non-AP STA MLD, wherein: when implemented in the non-AP STA MLD, the processor performs an association or re-association procedure by HLP encapsulation when performing the FILS procedure by: constructing a FILS HLP container element to form a HLP data packet, the FILS HLP container element including a destination MAC address, a source MAC address, and a HLP data packet in MSDU format, the source MAC address including an MLD MAC address of the non-AP STA MLD; and sending the FILS HLP container element to the AP MLD in an association or re-association request frame, and when implemented in the AP MLD, receiving and decapsulating the HLP data packet by the processor when performing the FILS procedure by: extracting the destination MAC address, the source MAC address, and the HLP data packet from the FILS HLP container element; 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 that the extracted source MAC address matches the MLD MAC address of the non-AP STA MLD: constructing a frame containing the HLP data packet; and communicating the frame to an upstream network or basic service set, or in response to determining that the extracted source MAC address does not match the MLD MAC address of the non-AP STA MLD, discarding the FILS HLP container element.

Images