Communication device and communication method for multi-link secure retransmission

Abstract

A communication device and method for multi-link secure retransmission are provided. One exemplary embodiment provides a multi-link device (MLD) configured to operate with a first plurality of dependent STAs, comprising: circuitry for establishing a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs, wherein the circuitry is configured to cryptographically encapsulate a MAC protocol data unit (MPDU) to form additional authentication data (AAD) and a random number of the encapsulated MPDU, the AAD comprising an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, the random number comprising an address 2 (A2) field, wherein the SC field of the AAD is based on the SC field of the MPDU; and a transmitter for transmitting the encapsulated MPDU as an initial transmission to the second MLD on the first link, and, upon failure of the initial transmission, retransmitting the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

Description

Technical Field

[0001] The present embodiments generally relate to communication devices, and more particularly, to methods and devices for multi-link secure transmission. Background Art

[0002] In today's world, communication devices are expected to operate wirelessly with the same capabilities as wired computing devices. For example, users expect to be able to seamlessly watch a high-definition movie streamed to their wireless communication device. This presents challenges for both communication devices and the access points to which they connect wirelessly.

[0003] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 group recently established the Extremely High Throughput (EHT) research group to address these challenges. Multi-link operation in the 2.4 GHz, 5 GHz, and 6 GHz bands has been identified as a key candidate technology for such communications. Aggregating multiple channels across multiple links is a natural way to create exponential increases in communication data throughput.

[0004] In addition, security protocols including but not limited to the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or the Galois / Counter Mode Protocol (GCMP) are used in such IEEE 802.11 devices to provide data confidentiality, authentication, integrity, and replay protection for data frames, individually addressed robust management frames, and group addressed management frames. Summary of the Invention

[0005] One non-limiting and exemplary embodiment facilitates providing a first multi-link device (MLD) configured to operate with a first plurality of dependent stations, comprising: circuitry to establish a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs, wherein the circuitry is configured to cryptographically encapsulate a MAC protocol data unit (MPDU) to form additional authentication data (AAD) and a random number of the encapsulated MPDU, wherein the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, and the random number includes an A2 field, wherein the SC field of the AAD is based on the SC field of the MPDU; and a transmitter to transmit the encapsulated MPDU as an initial transmission to the second MLD on the first link and, upon failure of the initial transmission, retransmit the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0006] Another non-limiting and exemplary embodiment facilitates providing a method for retransmission of an MPDU in multi-link communication, comprising: establishing, at a first MLD, a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs; constructing additional authentication data (AAD) and a random number, wherein the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, and the random number includes an A2 field, wherein the SC field of the AAD is based on the SC field of the MPDU; cryptographically encapsulating the MPDU using the AAD and the random number to form an encapsulated MPDU; sending the encapsulated MPDU from the first MLD to the second MLD on the first link as an initial transmission, and upon failure of the initial transmission, resending the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0007] It should be noted that the general or specific embodiments may be implemented as systems, methods, integrated circuits, computer programs, storage media, or any selective combination thereof. Additional benefits and advantages of the disclosed embodiments will become apparent from the description and drawings. Benefits and / or advantages may be achieved individually through various embodiments and features of the description and drawings, and not all of these embodiments and features need to be provided in order to achieve one or more such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings are used to illustrate various embodiments and explain various principles and advantages according to the present embodiments. In the accompanying drawings, the same figure numbers refer to the same or functionally similar elements in separate views, and the accompanying drawings are incorporated into the specification together with the following detailed description and form a part of the specification.

[0009] Figure 1 Illustrated are steps for processing a Medium Access Control (MAC) Protocol Data Unit (MPDU) using CCMP according to various embodiments.

[0010] Figure 2A Depicted are diagrams of protected MPDUs in accordance with various embodiments.

[0011] Figure 2B Depicted is a diagram of a MAC header of a protected MPDU in accordance with various embodiments.

[0012] Figure 3 Depicted is a diagram of multi-link MPDU transmission using a separate pairwise transient key (PTK) for each link.

[0013] Figure 4Depicted is a diagram of multi-link MPDU transmission using a single PTK for all links in accordance with various embodiments.

[0014] Figure 5 Depicted is a diagram of a CCMP encapsulation process to form an encrypted MPDU in accordance with various embodiments.

[0015] Figure 6 A diagram depicting how an unprotected MPDU is resent on a different link according to a first embodiment.

[0016] Figure 7A Depicted is a diagram of an Additional Authentication Data (AAD) frame in accordance with a first embodiment.

[0017] Figure 7B A diagram of a random number frame according to a first embodiment is depicted.

[0018] Figure 8 Depicted is a diagram of a CCMP decapsulation process forming a plaintext MPDU according to a first embodiment.

[0019] Figure 9 A flow chart of the initial transmission of an MPDU according to the first embodiment is depicted.

[0020] Figure 10 A flowchart of retransmission of an MPDU according to a first embodiment is depicted.

[0021] Figure 11 A flow chart of reception of an MPDU according to the first embodiment is depicted.

[0022] Figure 12 Depicted is a diagram of a protected MPDU according to a second embodiment.

[0023] Figure 13 A flow chart of reception of an MPDU according to the second embodiment is depicted.

[0024] Figure 14 Depicted is a diagram of a protected MPDU according to a third embodiment.

[0025] Figure 15 A flow chart of reception of an MPDU according to a third embodiment is depicted.

[0026] Figure 16 Depicted is a diagram of a protected MPDU according to a fourth embodiment.

[0027] Figure 17 A flowchart of reception of an MPDU according to a fourth embodiment is depicted.

[0028] Figure 18ADepicted is a diagram of a Galois / Counter Mode Protocol (GCMP) encapsulation process to form an encrypted MPDU in accordance with a fifth embodiment.

[0029] Figure 18B Depicted is a diagram of a GCMP protected MPDU according to a fifth embodiment.

[0030] Figure 18C Depicted is a diagram of a GCMP decapsulation process forming a plaintext MPDU according to a fifth embodiment.

[0031] Figure 19 Depicted is a diagram of multi-link MPDU transmission using common packet number (PN) allocation for all links in accordance with various embodiments.

[0032] Figure 20 A schematic diagram of a transmitter MLD 2000 is depicted in accordance with various embodiments.

[0033] Figure 21 A schematic diagram of a receiver MLD 2100 is depicted in accordance with various embodiments.

[0034] Figure 22 shows a flowchart 2200 illustrating a method for multi-link secure retransmission according to various embodiments; and

[0035] Figure 23 A schematic partial cross-sectional view of one of the subordinate STAs of the multi-link device 2300 that can be implemented for multi-link security retransmission according to the first to fifth embodiments is shown.

[0036] Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. DETAILED DESCRIPTION

[0037] The following detailed description is merely exemplary in nature and is not intended to limit the embodiments or the application and uses of the embodiments. Furthermore, the present invention is not intended to be bound by any theory presented in the foregoing background technology or this detailed description. In addition, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and the background of the present disclosure.

[0038] refer to Figure 1, the diagram depicts the steps of processing an MPDU using CCMP according to various embodiments. In step 1, a MAC header is added to data such as a MAC service data unit (MSDU) or a management MPDU (MMDPU) to form an MPDU. In step 2, the MAC header is separated from the MPDU and a CCMP header is created. In step 3, a message integrity code (MIC) is calculated and appended to the end. The MIC is used for authentication and integrity checking. In step 4, the combination of the data and the MIC is encrypted to form a ciphertext. The CCMP header is then appended to the front of the ciphertext. In step 5, the MAC header is recovered by appending the MAC header to the front of the CCMP header. In step 6, a cyclic redundancy check (CRC) is calculated on the entire MPDU and appended to the end of the MPDU to form a protected or encrypted MPDU.

[0039] Figure 2A A diagram of a protected MPDU 200 according to various embodiments is depicted. The protected MPDU 200 includes a MAC header field 202, a CCMP header field, a data (PDU) field, a MIC field, and an FCS field. Figure 1 As described in

[15] , the Data (Payload) field and the MIC field are encrypted. The CCMP header field includes a PN0 field, a PN1 field, an Rsvd field, a Key ID octet field, a PN2 field, a PN3 field, a PN4 field, and a PN0 field. The Key ID octet field includes a Reserved (Rsvd) subfield, an Ext IV subfield, and a Key ID subfield.

[0040] MAC header field 202 is in Figure 2B The FC field is described in detail in FIG, and includes a Frame Control (FC) field, a Duration / ID field, an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, a Sequence Control (SC) field, an optional Quality of Service (QoS) control field, an optional Address 4 (A4) field, and an optional High Throughput (HT) field. The FC field also includes a Protocol Version subfield, a Type subfield, a To Distribution Service (DS) subfield, a From DS subfield, a More Fragments subfield, a Retry subfield, a Power Management subfield, a More Data subfield, a Protected Frame subfield, and a +HTC subfield.

[0041] Typically, the contents of the A1, A2, and A3 address fields of a data frame depend on the "To DS" and "From DS" subfields of the FC field of the MAC header, as shown in Table 1 below:

[0042]

[0043] Table 1

[0044] If the contents of the "To DS" and "From DS" subfields are both "0," the contents of the A1 field will be the receiver address (RA) (=destination address (DA)), the contents of the A2 field will be the transmitter address (TA) (=source address (SA)), the contents of the A3 field will be the basic service set identifier (BSSID), and Address 4 will not exist. If the contents of the "To DS" and "From DS" subfields are "0" and "1," respectively, the contents of the A1 field will be RA, the contents of the A2 field will be the transmitter address (TA) (=BSSID), the contents of the A3 field will be SA, and Address 4 will not exist. If the contents of the "To DS" and "From DS" subfields are "1" and "0," respectively, the contents of the A1 field will be RA (=BSSID), the contents of the A2 field will be TA, the contents of the A3 field will be DA, and Address 4 will not exist. If the contents of the "To DS" and "From DS" subfields are both "1", the contents of the A1 field will be RA, the contents of the A2 field will be TA, the contents of the A3 field will be DA, and Address 4 is set to SA.

[0045] For management frames, the contents of the A1, A2, and A3 address fields are typically the same as those for data frames with "To DS" = 0 and "From DS" = 0. That is, the contents of the A1 field will be RA (= DA), and the contents of the A2 field will be TA (= SA). A3 depends on the frame type, but in most cases is set to the BSSID. If a STA is sending a management frame to an access point (AP) in a multi-BSSID set, the Address 3 field will be the BSSID of the AP's BSS (either a transmitting BSSID or a non-transmitting BSSID), regardless of whether the STA is associated with that AP.

[0046] Multilink operation in next-generation wireless LANs, such as 802.11be, allows MPDUs with the same TID (Traffic ID) to be sent simultaneously on different links. However, as explained below, such multilink transmission can lead to unexpected operation when security encapsulation is applied to the MPDUs. When MPDUs with the same TID (Traffic ID) can be sent simultaneously on different links, to ensure that the receiving MLD can correctly reorder MPDUs received on different links, the same sequence number (SN) space can be used to assign SNs to MSDUs or MMPDUs carried in the MPDUs, regardless of the link used for actual transmission. During the initial establishment of a link between an AP MLD and a non-AP MLD (e.g., immediately after the multilink association process), a single PMK (Pairwise Master Key) can be negotiated between the AP MLD and the non-AP MLD to serve as the master key for secure transmission between the two MLDs. The PTK (Pairwise Transient Key) and GTK / IGTK (Group (Integrity) Transient Key) used for secure encapsulation / decapsulation of the MPDUs can be derived from the same PMK across different links. It is possible to generate separate PTKs and separate GTKs / IGTKs for different links. Figure 3 A diagram 300 depicts multi-link MPDU transmission using a separate PTK for each link. In this example, a transmitter MLD transmits MPDUs to a receiver MLD on both Link 1 and Link 2. Link 1 uses PTK Key 1, while Link 2 uses a different PTK Key 2. The packet number (PN) counter for each link is also different, even though the MPDU transmissions on both links still use a common sequence number (SN). For example, the PN counter for MPDUs transmitted on Link 1 starts at PN=100, while the PN counter for MPDUs transmitted on Link 2 starts at PN=51.

[0047] In this example, MPDU 302 on Link 1 failed to be transmitted, so it is scheduled to be retransmitted on a different link (such as Link 2 instead of Link 1). Since Link 2 uses a different PTK (i.e., Key 2), the MPDU needs to be encapsulated with Key 2 and a new PN = 54 (since it is scheduled to be retransmitted after the transmission of MPDU 308 with PN = 53) as MPDU 304, even though it still shares the same SN = 4 with MPDU 302. On the receiving side, the receiver MLD then reorders the received MPDUs on Link 2 according to the SN of each received MPDU, including MPDU 304. When reordering reaches SN = 4, i.e., until the received MPDU 304 with SN = 4 and PN = 54, the receiver MLD updates the replay counter to PN = 54. Therefore, the remaining MPDUs with SN greater than 4 and PN less than 54 (ie, received MPDU 306 with SN=6, PN=52 and received MPDU 308 with SN=7, PN=53) are discarded, resulting in an unexpected replay rejection problem.

[0048] Even if a single PTK is used for all links, the replay rejection problem still occurs if the retransmitted MPDU is again encapsulated with a new PN. This can be seen in the diagram 400 depicting multi-link MPDU transmission using a single PTK for all links according to various embodiments. Figure 4 Seen in. Similar to Figure 3 , the transmitter MLD sends MPDUs to the receiver MLD on link 1 and link 2. The difference is that both link 1 and link 2 use the same PTK key 1. As a result, both links use a common SN allocation and a common PN allocation.

[0049] In this example, MPDU 402 with SN=4 and PN=104 on Link 1 failed to be transmitted, so it is scheduled to be retransmitted on a different link (such as Link 2 instead of Link 1). Since Link 2 has different A1 and A2 fields compared to Link 1, the MPDU needs to be encapsulated again as MPDU 404 with a new PN=108 (since it was scheduled to be retransmitted after the transmission of MPDU 408 with PN=107), even though it still shares the same SN=4 with MPDU 402. The receiver MLD then reorders the received MPDUs on Link 2 according to the SN of each received MPDU, including MPDU 404. When the reordering reaches SN=4, that is, until the received MPDU 404 with SN=4 and PN=108, the receiver MLD updates the replay counter to PN=108. As a result, the remaining MPDUs with SN greater than 4 and PN less than 108 (ie, received MPDU 406 with SN=6, PN=105 and received MPDU 408 with SN=7, PN=107) are discarded, resulting in a replay rejection problem.

[0050] Furthermore, IEEE 802.11be may specify the use of a separate MAC address for each link, or may also allow different links to use the same MAC address. If separate MAC addresses are used for links, then when the TAs of the two transmitting links are the same, but the RAs of the two receiving links are different, and the same A2 (i.e., =TA) and the same PN (i.e., the PN remains the same across retransmissions to avoid out-of-order PNs received by the receiver MLD after SN reordering) are used to retransmit the frame on the other link, the problem (security vulnerability) of reusing the same random number (Nonce) value to protect different data can be avoided. However, the IEEE 802.11 specification states the following regarding the use of random numbers and PNs:

[0051] "CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each frame protected by a given temporal key, and CCMP uses a 48-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees."

[0052] This means reusing the same PN for retransmissions on different links to avoid the replay rejection problem. While this solves the problem, it can introduce security vulnerabilities. The above assumption is that retransmitted MPDUs need to be re-encapsulated when retransmitted on different links. The present disclosure provides several options to avoid such security-related issues introduced by multi-link transmission.

[0053] Figure 5 A diagram depicts the CCMP encapsulation process for forming an encrypted MPDU in accordance with the IEEE 802.11 specification. Specifically, Additional Authentication Data (AAD) 502 and a random number 504 are constructed and used for cryptographic encapsulation of the MPDU to form an encrypted or protected MPDU. AAD 502 includes a Frame Control (FC) field, an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, a Sequence Control (SC) field, an optional Address 4 (A4) field, and an optional Quality Control (QC) field, while random number 504 includes a Random Number Flag field, an A2 field, and a PN field. The contents of the A1, A2, and A3 fields in AAD 502 and the contents of the A2 field in random number 504 are taken from the A1, A2, and A3 fields of the MPDU to be encapsulated (or decapsulated in the case of an encrypted MPDU decapsulation process).

[0054] In a single-link 802.11 STA, the protected MPDU is retransmitted with minimal changes:

[0055] - The Retry subfield (bit 11) of the FC field is set to 1. However, during CCMP encapsulation, the Retry subfield and several subfields of the FC field are usually masked to 0.

[0056] -CRC is recalculated, but FCS is not an input to CCMP encapsulation.

[0057] - MPDUs are encapsulated only during initial transmission and not for retransmission.

[0058] However, for MLD, the rules for retransmission of protected MPDUs may depend on the link over which the MPDU is retransmitted. If the same link is used for retransmission, the MPDU is encapsulated only during the initial transmission and not for retransmission. If a different link is used for retransmission (assuming different MAC addresses for the attached STAs at both ends of the link), the MPDU needs to be encapsulated again before retransmission (possibly with the same PN to avoid replay rejection issues). However, reusing a PN with the same security key can lead to security vulnerabilities.

[0059] Therefore, the present invention seeks to avoid CCMP encapsulation during retransmission of protected frames on different links (even when the per-link MAC addresses are different).

[0060] Figure 6A diagram depicts how an unprotected MPDU is retransmitted on a different link according to a first embodiment. A transmitting MLD 602 ​​operates with a first plurality of dependent STAs, such as STA 604 and STA 606. The MAC address MLD-TA identifies the transmitting MLD 602 ​​and can be used to indicate the MLD used for communication with the DS (Distribution Service), with the MAC addresses of STA 604 and STA 606 being TA1 and TA2, respectively. Similarly, a receiving MLD 612 operates with a second plurality of dependent STAs, such as STA 614 and STA 616. The MAC address MLD-RA identifies the receiving MLD 612, with the MAC addresses of STA 614 and STA 616 being RA1 and RA2, respectively. For an MLD, the MLD MAC address can be the same as or different from one of its per-link MAC addresses. However, it is assumed that the per-link MAC addresses are different from each other (i.e., TA1≠TA2; RA1≠RA2). It will be appreciated that two or more STAs may form a first plurality of dependent STAs and a second plurality of dependent STAs, and two or more links may be formed between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of STAs, without necessarily requiring each STA to be connected by a link. For example, Link 1 may be established between STA 604 and STA 614, while Link 2 may be established between STA 606 and STA 616. The above arrangement also applies to the retransmission of protected or unprotected MPDUs, which will be further discussed in various embodiments below. Furthermore, specifically for the retransmission of protected MPDUs, it is assumed that a Robust Security Network Association (RSNA) has been established between the transmitting MLD and the receiving MLD, and that all necessary secret keys (e.g., PTK, GTK / IGTK, etc.) have been generated / distributed.

[0061] As shown in diagram 600, transmitting MLD 602 ​​transmits an unprotected MPDU 608 on link 1 to receiving MLD 612 (i.e., from STA 604 to STA 614). Therefore, the A1, A2, and A3 fields of MPDU 608 are set to the MAC addresses of receiving STA 614 (i.e., RA1) and transmitting STA 604 (i.e., TA1), respectively. For the initial transmission, the retry subfield in the FC field of MPDU 608 is set to 0. In the event of a transmission failure due to various reasons (e.g., a temporary failure of link 1), the MPDU can be retransmitted as an unprotected MPDU 610 on link 2, i.e., from STA 606 to STA 616. The unprotected MPDU can be retransmitted on another link by simply setting the retry subfield in the MPDU's frame control (FC) field to 1 and swapping the A1, A2, and A3 fields in the MAC header. Therefore, the A1 field of MPDU 610 is set to the MAC address of receiving STA 616 (i.e., RA2), and the A2 field is set to the MAC address of transmitting STA 606 (i.e., TA2). In addition, the Reset subfield in the FC field of MPDU 610 is set to 1. In MPDUs where A3 is set to the BSSID (e.g., data frames to / from DS=0; or management frames), if the BSSID of link 2 is different, then if the transmitter is an AP MLD, A3 (which is set to the BSSID in such frames; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if it is different from MLD-TA), and if the transmitter is a non-AP MLD, A3 is also changed to MLD-RA (or the BSSID of that link, if it is different from MLD-RA). If the per-link MAC addresses are the same, the retransmission rules can be the same as for single-link STAs (i.e., even the A1, A2, and A3 addresses do not need to be changed).

[0062] For the initial transmission of a protected MPDU according to the first embodiment, during CCMP encapsulation of the protected MPDU addressed to the peer MLD, the MLD MAC address is used to generate the AAD and the random number instead of the MAC address of the transmitting / receiving dependent STA (i.e., the A1, A2 fields of the MPDU to be transmitted). Figure 7AA diagram of an AAD 700 according to a first embodiment is depicted. Although similar to AAD 502, AAD 700's A1 field 702 and A2 field 704 are set to the MAC addresses of the receiving and transmitting MLDs (i.e., MLD-RA and MLD-TA), respectively, rather than the MAC addresses of the transmitting / receiving subordinate STAs indicated in the A1, A2, and A3 fields of the protected MPDU to be transmitted. In an MPDU where A3 is set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, A3 (which is set to the BSSID in such frames; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if it is different from MLD-TA) if the transmitter is an AP MLD, and to MLD-RA (or the BSSID of that link, if it is different from MLD-RA) if the transmitter is a non-AP MLD. Figure 7B A diagram of a random number 706 according to a first embodiment is depicted. Although similar to random number 504, A2 field 708 of random number 706 is set to the MAC address of the transmitting MLD (i.e., MLD-TA) rather than the MAC address of the transmitting subordinate STA indicated in the A2 field of the protected MPDU to be transmitted. The protected MPDU can be stored in the memory of the transmitting MLD until receipt of the MPDU is successfully acknowledged from the receiving MLD, or when the MSDU lifetime expires.

[0063] When the transmission of the protected MPDU according to the first embodiment fails, after setting the Retry subfield of the FC field to 1, swapping the A1 and A2 fields of the MAC header, and adding a new CRC, the protected MPDU is retrieved from the memory (if it was saved during the initial transmission) and resent. Advantageously, since the AAD and the random number remain the same regardless of the per-link MAC address used in the link, CCMP encapsulation does not need to be performed again. In fact, the fields of the MAC header whose contents may change during retransmission (e.g., the Duration / ID field, the HT Control field) are not included in the AAD and therefore do not affect the encapsulation process. For similar reasons, several subfields in the Frame Control field are masked to 0:

[0064] i) The subtype subfield (bits 4, 5, and 6) in the data frame is masked to 0

[0065] ii) The Retry subfield (bit 11) is masked to 0

[0066] iii) Power Management subfield (bit 12) masked to 0

[0067] iv) More Data subfield (bit 13) masked to 0

[0068] v) Protected Frame subfield (bit 14) is always set to 1

[0069] vi) +HTC subfield (bit 15) is as follows:

[0070] - Mask to 0 in all data frames containing the QoS control field

[0071] - Otherwise, no mask

[0072] If the protected MPDU was not saved in memory during the initial transmission, the original unprotected MPDU is retrieved from memory (e.g., from the transmit buffer), but is re-encapsulated using the A1 field, A2 field, A3 field (and A3 field, if applicable) of the AAD and the MAC address of the MLD in the A2 field of the random number.

[0073] Regardless of the link used to receive protected MPDUs (from a peer MLD), during CCMP decapsulation, the MLD MAC address is used to generate the AAD and random number instead of the transmitting / receiving attached STA's MAC address (i.e., the A1, A2 fields of the received MPDU). Figure 8A diagram 800 illustrates the CCMP decapsulation process used by a receiving MLD to form a plaintext MPDU, according to a first embodiment. An AAD 802 and a random number 810 are constructed for decapsulating a protected or encrypted MPDU. According to the first embodiment, the A1 field 804 and the A2 field 806 in the AAD 802 are set to the MAC address of the receiving MLD (i.e., MLD-RA) and the MAC address of the transmitting MLD (i.e., MLD-TA), respectively. In MPDUs where A3 is set to the BSSID (e.g., data frames to / from DS=0; or management frames), if the BSSID of link 2 is different, A3 (set to the BSSID in such frames; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if different from MLD-TA) if the sender is an AP MLD, and to MLD-RA (or the BSSID of that link, if different from MLD-RA) if the sender is a non-AP MLD. Furthermore, the A2 field 808 in the random number 810 is set to the MAC address of the transmitting MLD (i.e., MLD-TA). The A2 field of the received MPDU is checked before switching to the MLD MAC address to verify the identity of the transmitting STA (i.e., the A2 field of the received MPDU should indicate the MAC address of the transmitting STA affiliated with the peer MLD). The A1 field of the received MPDU is already checked during receive frame filtering.

[0074] For retransmission of protected MPDUs according to the first embodiment, it is assumed that both the transmitter and receiver MLDs know the MLD MAC address (e.g., exchanged during the association / link activation process). Furthermore, it is assumed that the same PTK is used for all links. If different links use different PTKs, the MPDU needs to be re-encapsulated before retransmission on the different links. If the MAC address is the same per link and a single PTK is used for all links, the retransmission rules are the same as for single-link STAs.

[0075] As a variation, instead of using MLD-TA and MLD-RA, the AP can also provide the MAC address used for the A1, A2 fields (and A3, if applicable) during the construction of the AAD and random number to the non-AP STA, for example, during the 4-way group key handshake or using some kind of management frame exchange. This can also be useful for single-link STAs using dynamic MAC addresses (e.g., MAC randomization), where the address changes between initial transmissions and retransmissions. The provided MAC address is then used to construct the AAD and random number instead of the various address fields of the protected MPDU. If the A1 and A2 fields (and A3, if applicable) used in the AAD and random number are always fixed, CCMP decapsulation will still pass even after a change in the MAC address (A1, A2, or both (and A3, if applicable)) in the retransmitted frame.

[0076] Figure 9 Flowchart 900 illustrates the initial transmission of an MPDU according to a first embodiment. At step 902, an MPDU is prepared for initial transmission. At step 904, a determination is made as to whether the MPDU requires protection. If it is determined that the MPDU does not require protection, the process proceeds to step 918, where the MPDU is passed to the next process for transmission to a receiving MLD (e.g., for channel access), and the process ends at step 920. If it is determined at step 904 that the MPDU requires protection, the process proceeds to step 906, where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD. At step 908, the A2 field of the AAD and the constructed random number is set to the MAC address of the own MLD (i.e., the transmitting MLD). Although not shown in the figure, in an MPDU with A3 set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, A3 (set to the BSSID in such a frame; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if different from MLD-TA) if the sender is an AP MLD, and to MLD-RA (or the BSSID of that link, if different from MLD-RA) if the sender is a non-AP MLD. In step 910, the remaining fields in AAD and the random number are set as usual, i.e., according to the IEEE 802.11 standard. In step 912, CCMP encapsulation of the MPDU is performed to generate a protected or encrypted MPDU. In step 914, the protected MPDU is passed to the next process for transmission to the receiving MLD, and the process ends in step 916.

[0077] Figure 10A flowchart 1000 illustrates retransmission of an MPDU according to a first embodiment. At step 1002, it is determined that the MPDU requires retransmission, i.e., after an initial transmission failure (e.g., upon receipt of a BlockAck frame indicating the initial transmission failure). At step 1004, a stored MPDU is retrieved from memory. At step 1006, the Retry subfield in the FC field of the MPDU is set to 1. At step 1008, it is determined whether the MPDU is a protected MPDU or an unprotected MPDU. If the MPDU is an unprotected MPDU, the process proceeds to step 1018, where it is determined whether the MPDU should be retransmitted on the same link as the initial transmission. If it is determined that the MPDU should be retransmitted on the same link as the initial transmission, the process continues from step 1016. Otherwise, if it is determined that the MPDU should be retransmitted on a different link, the process proceeds to step 1020, where it is determined whether the TA or RA is different on the new link to be used for the retransmission. If it is determined that the TA or RA in the new link is the same as those of the initial transmission link, the process continues from step 1016. Otherwise, the process proceeds to step 1022, where the A1 and / or A2 fields are set to the new RA and / or TA of the new link, and the process continues from step 1016.

[0078] If it is determined in step 1008 that the MPDU is protected, the process proceeds to step 1010, where a determination is made as to whether the protected MPDU is to be retransmitted on the same link as the initial transmission. If it is determined that the same link will be used for the retransmission, the process continues at step 1016. Otherwise, the process proceeds to step 1012, where a determination is made as to whether the TA or RA is different in the new link to be used for the retransmission. If it is determined that the TA or RA is different in the new link compared to the link used for the initial transmission, the process continues at step 1016. Otherwise, the process proceeds to step 1014, where the A1 and / or A2 fields are set to the new RA and / or TA for the new link, and the process continues at step 1016. Furthermore, starting at step 1016, the MPDU is passed to the next process for retransmission, and the process ends at step 1028. It is noteworthy that the processing for retransmissions of protected and unprotected MPDUs (i.e., regardless of the outcome from step 1008) is identical. Although not shown in the figure, in an MPDU in which A3 is set to the BSSID (e.g., a data frame to / from DS=0; or a management frame), if the BSSID of link 2 is different, A3 is set to the BSSID of link 2 (the BSSID is typically the same as the MAC address of the AP MLD on that link).

[0079] Figure 11A flowchart 1100 depicts the reception of an MPDU according to a first embodiment. At step 1102, an MPDU is received. At step 1104, a determination is made as to whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1124, where the MPDU is passed to the next process for reception, and the process then ends at step 1126. If, at step 1104, the MPDU is determined to be protected, the process proceeds to step 1106, where a determination is made as to whether the A2 field of the received MPDU indicates a MAC address identifying a peer MLD. For a non-AP MLD, the peer MLD refers to its associated AP MLD. For an AP MLD, the peer MLD refers to its associated non-AP MLD. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, then a conventional decapsulation process is used, and the process proceeds to step 1120, where the constructed AAD and the A2 field of the random number are set to the A2 field of the MPDU, proceeds to step 1122, where the A1 field of the constructed AAD is set to the A1 field (and A3, if applicable) of the MPDU, and then continues from step 1112. If it is determined in step 1106 that the A2 field is set to a MAC address identifying the peer MLD, then the process proceeds to step 1108, where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD, proceeds to step 1110, where the constructed AAD and the A2 field of the random number are set to the MAC address of the transmitting MLD, and then continues from step 1112. Although not shown in the figure, in an MPDU with A3 set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, A3 (set to the BSSID in such a frame; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if different from MLD-TA) if the sender is an AP MLD, and to MLD-RA (or the BSSID of that link, if different from MLD-RA) if the sender is a non-AP MLD. In step 1112, the remaining fields in the AAD and random number are set as usual. In step 1114, CCMP decapsulation is performed on the protected MPDU using the constructed AAD and random number. In step 1116, the decrypted MPDU is passed to the next process for reception, and the process ends in step 1118. The advantageous effect of the above process is that cross-link retransmission of the encrypted MPDU is possible without re-performing CCMP encapsulation, and the receiving MLD can still correctly decapsulate the MDPU.

[0080] According to a second embodiment, during initial transmission, the AAD and random number can be generated during CCMP encapsulation of the protected MPDU using the MLD MAC address, the A1 and A2 fields of the protected MPDU being transmitted, or the per-link MAC address of any attached STA. The same protected MPDU can then be retransmitted on a different link (after setting the Retry subfield in the FC and modifying some other fields as previously described) without undergoing CCMP encapsulation again. This can be achieved by modifying a field in the protected MPDU's MAC header (e.g., a CCMP header that signals the address used to generate the AAD and random number during CCMP encapsulation). The transmitting MLD can select different addresses for generating the AAD and random number during CCMP encapsulation based on the deployment scenario. For example, if the same PTK is used for all links, the MLD MAC address can be used as described in the first embodiment. Alternatively, the per-link MAC address of the link used for the original transmission of the MPDU can be used to generate the AAD and nonce, and if the MPDU is later retransmitted on a different link, a signal in the CCMP header can instruct the receiving MLD to use the per-link MAC address of the link used for the original transmission. Similarly, if the per-link MAC addresses of the two links are the same, the transmitter MLD can signal that the address field of the MPDU's MAC header is to be used to generate the AAD and nonce. However, if different links use different PTKs, the MPDU will need to be encapsulated again using the PTK of that link during retransmission on the different link. In this case, CCMP encapsulation can follow the conventional method of using the address field of the (retransmitted) MPDU's MAC header to generate the AAD and nonce fields. However, even in this case, the transmitting MLD can still signal in the CCMP header that the address field of the (retransmitted) MPDU's MAC header is to be used to generate the AAD and nonce fields. Thus, signaling the MAC address in the CCMP header enables the receiving MLD to correctly decapsulate the received protected MPDU (either during initial transmission or retransmission) regardless of the different methods used by the transmitting MLD to encapsulate the MPDU. Figure 12A diagram of a protected MPDU 1200 according to a second embodiment is depicted. The CCMP header 1202 of the MPDU 1200 now includes a new options field 1204, which includes an Rsvd subfield and an address subfield 1206. The address subfield 1206 indicates to the receiver MLD what values ​​the A1, A2, A3, and A2 fields in the AAD (Audio Addressing Device) should assume during decapsulation of the protected MPDU 1200. Referring to Table 1208, if the value of the address subfield 1206 is set to 0, the A1, A2, A3, and A2 fields in the AAD are set to the A1, A2, and A3 fields, respectively, of the MAC header 1210. If the value of the address subfield 1206 is set to 1, the A1, A2, A3, and A2 fields in the AAD are set to the MAC addresses of the receiving and transmitting MLDs, respectively. If the value of the address subfield 1206 is set to 2 to n, the A1 field, A2 field, A3 field, and random number in the AAD are set to the per-link MAC address of the affiliated STA associated with link 1 to link (n-1). In addition, the A1 field, A2 field, and A3 field in the MAC header 1210 are set to the MAC address of the link being transmitted (i.e., TA1 / TA2, RA1 / RA2), and A3 is set to the BSSID of the link as normal.

[0081] During CCMP decapsulation, the receiving MLD uses the Address subfield 1206 to determine the MAC address used to generate the AAD and random number. It is assumed that both the sender and receiver MLDs know the per-link MAC addresses of all enabled links (e.g., exchanged during the association / link activation process). Advantageously, during retransmission of a failed MPDU according to the second embodiment (after setting the Retry subfield of the FC to 1, swapping the A1, A2, and A3 fields of the MAC header (and A3 if the BSSIDs of the links are different), and adding a new CRC), CCMP encapsulation is not performed.

[0082] The second embodiment assumes that the same PTK is used for all links. Other fields in the MAC header 1210 could also be used to indicate address information, but the CCMP header 1202 would be the natural choice because this field is used to indicate security-related information and because the CCMP header 1202 is not included in the encapsulation process and is sent in plaintext. Furthermore, Link 1 through Link (n-1) in Table 1208 represent the first through (n-1)th links established between two MLDs and are not necessarily the same as the link IDs assigned to the links, although they may be the same value. For example, Link 1 could represent Link ID 2, Link 2 could represent Link ID 4, and so on. However, if different links use different PTKs, the MPDU would need to be encapsulated again using the PTK of that link during retransmissions on different links. In this case, CCMP encapsulation can follow the conventional method of using the address field of the MAC header of the (retransmitted) MPDU to generate the AAD and nonce fields. However, even in this case, the transmitting MLD can still signal in the CCMP header that the address field of the MAC header of the (retransmitted) MPDU is to be used to generate the AAD and random number fields, so that the receiving MLD can correctly decapsulate the received protected MPDU.

[0083] Figure 13Flowchart 1300 depicts the reception of an MPDU according to a second embodiment. At step 1302, an MPDU is received. At step 1304, a determination is made as to whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1324, where the MPDU is passed to the next process for reception, and the process then ends at step 1326. If, at step 1304, the MPDU is determined to be protected, the process proceeds to step 1306, where a determination is made as to whether the A2 field of the received MPDU indicates a MAC address identifying a peer MLD. For a non-AP MLD, the peer MLD refers to its associated AP MLD. For an AP MLD, the peer MLD refers to its associated non-AP MLD. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, then a conventional decapsulation method is used and the process proceeds to step 1320, where the constructed AAD and the A2 field of the random number are set to the A2 field of the MPDU, proceeds to step 1322, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step 1312. If it is determined in step 1306 that the A2 field is set to the MAC address identifying the peer MLD, then the process proceeds to step 1308, where the constructed AAD and the A2 field of the random number are set to the MAC address based on the address subfield in the CCMP header of the MPDU, proceeds to step 1310, where the A1 field of the constructed AAD is set to the MAC address based on the address field in the CCMP header of the MPDU, and then continues from step 1312.

[0084] In step 1312, the remaining fields in the AAD and random number are set as usual. Although not shown in the figure, in an MPDU where A3 is set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, A3 (which is set to the BSSID in such a frame; the BSSID is typically the same as the MAC address of the APMLD on that link) is also changed to MLD-TA (or the BSSID of that link, if it is different from MLD-TA) if the sender is an AP MLD, and to MLD-RA (or the BSSID of that link, if it is different from MLD-RA) if the sender is a non-AP MLD. In step 1314, CCMP decapsulation is performed on the protected MPDU using the constructed AAD and random number. In step 1316, the decrypted MPDU is passed to the next process for reception, and the process ends in step 1318. In the second embodiment, the receiver MLD always checks the CCMP header of the MPDU to determine the A1 field, A2 field, A3 field settings of the constructed AAD and the random number of the A2 field, regardless of whether it is an initial transmission or a retransmission. Advantageously, the sending MLD has greater flexibility in determining the address value used for CCMP encapsulation.

[0085] According to the third embodiment, during CCMP encapsulation (during the initial transmission of a protected MPDU), the A1, A2, and A3 fields of the transmitted MPDU are used to generate the AAD and random number, similar to a conventional single-link STA. However, during retransmission of a failed protected MPDU (after setting the FC's Retry subfield to 1, swapping the MAC header's A1, A2 (and A3, if applicable), and adding a new CRC), the CCMP header indicates which A1, A2, and A3 fields are to be used by the receiver MLD to generate the AAD and random number for decapsulation. CCMP encapsulation is not performed during retransmission.

[0086] Figure 14A diagram of a protected MPDU 1400 according to a third embodiment is depicted. The CCMP header 1402 of the MPDU 1400 now includes a new options field 1404, which includes an Rsvd subfield and an address subfield 1406. During CCMP decapsulation, if the retry subfield of the FC field in the MAC header field 1410 has a value of 1 (i.e., indicating that the received MPDU is a retransmission), the receiving MLD uses the address field 1406 to determine the MAC address to generate the AAD and the random number. Referring to Table 1408, if the value of the address subfield 1406 is set to 0, the A1 field, A2 field, and A3 field in the AAD, and the A2 field in the random number are set to the corresponding address fields of the MAC header 1410. For example, if the A1 field of MPDU 1400 indicates RA1 (or RA2), the A1 field of the constructed AAD will be set to RA1 (or RA2), and if the A2 field of MPDU 1400 indicates TA1 (or TA2) and the A3 field is set to the A3 field of the MPDU, the AAD and the A2 field of the random number will be set to TA1 (or TA2). A value of 0 in Address subfield 1406 also indicates that the retransmission of MPDU 1400 is on the same link as the initial transmission (or the per-link MAC address in a different link is the same as that in the link used for the initial transmission), and the receiving MLD can use conventional methods to decapsulate the protected MPDU. If the value of Address subfield 1406 is set to 1 to n, the A1 and A2 fields in the AAD and the A2 field in the random number are set to the per-link MAC address of the attached STA associated with Link 1 to Link (n), and the A3 field in the AAD is set to the per-link MAC address of the attached STA of the AP MLD for that link. A value of 1 to n in the Address subfield 1406 also indicates that the retransmission is on a different link than the initial transmission. On the other hand, if the Retry subfield has a value of 0 (i.e., indicating that the received MPDU is an initial transmission), the A1, A2, and A3 fields of the MAC header 1406 are used to generate the AAD and random number (normal behavior).

[0087] The assumption of this embodiment is that the same PTK is used for all links and that the CCMP header of the MPDU is sent in the clear (i.e., unencrypted), so changing its value during retransmission advantageously does not require re-encapsulation. However, if different links use different PTKs, then during retransmission in different links, the MPDU will need to be encapsulated again using the PTK of that link. In this case, CCMP encapsulation can follow the conventional method of using the address field of the MAC header of the (retransmitted) MPDU to generate the AAD and nonce fields. However, even in this case, the transmitting MLD can still signal in the CCMP header that the address field of the MAC header of the (retransmitted) MPDU is to be used to generate the AAD and nonce fields, so that the receiving MLD can correctly decapsulate the received protected MPDU.

[0088] Figure 15 A flowchart 1500 depicts reception of an MPDU according to a third embodiment. At step 1502, an MPDU is received. At step 1504, a determination is made as to whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1526, where the MPDU is passed to the next process for reception, and the process then ends at step 1528. If, at step 1504, the MPDU is determined to be protected, the process proceeds to step 1506, where a determination is made as to whether the A2 field of the received MPDU indicates a MAC address identifying a peer MLD. For a non-AP MLD, the peer MLD refers to its associated AP MLD. For an AP MLD, the peer MLD refers to its associated non-AP MLD. If, at step 1506, the A2 field is determined to be the MAC address identifying the peer MLD, the process proceeds to step 1508, where a determination is made as to whether the Retry subfield in the FC field of the MPDU is set to 1. If it is determined that the Retry subfield is set to 1, the process proceeds to step 1510, where the address subfield of the CCMP header of the MPDU (i.e., the address subfield of the CCMP header of the MPDU) is set to 1. Figure 14 Table 1408) sets the constructed AAD and the A2 field of the random number to the MAC address, and proceeds to step 1512, where the address subfield of the CCMP header of the MPDU (i.e., according to Figure 141408) sets the A1 field of the constructed AAD to the MAC address, and then continues from step 1514. If, at step 1506, it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, or if, at step 1508, it is determined that the Retry subfield in the FC field of the MPDU is not 1, the process proceeds to step 1522, where the A2 field of the constructed AAD and the nonce is set to the A2 field of the MPDU, proceeds to step 1524, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step 1514. At step 1514, the remaining fields in the AAD and the nonce are set as usual. Although not shown in the figure, in an MPDU where A3 is set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, then if the sender is an AP MLD, A3 (set to the BSSID in such a frame; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if it is different from MLD-TA), and if the sender is a non-AP MLD, A3 is also changed to MLD-RA (or the BSSID of that link, if it is different from MLD-RA). In step 1516, CCMP decapsulation is performed on the MPDU using the constructed AAD and random number. In step 1518, the decrypted MPDU is passed to the next process for reception, and the process ends in step 1520. The above process advantageously differs from conventional CCMP encapsulation and decapsulation only in retransmission, thus minimizing the modifications required to implement this embodiment. In addition, the receiving MLD may also check the CCMP header of the received MPDU to determine whether it is a retransmitted MPDU, ie, based on the value of the Address subfield in the CCMP header (in addition to the Retry subfield in the FC).

[0089] According to a fourth embodiment, data and management frames transmitted by or to the MLD may also have different MAC header formats, which carry information specific to multilink transmission, ie, information such as the MAC addresses of the transmitting and receiving MLDs. Figure 16A diagram depicts a protected MPDU 1600 with a modified MAC header 1602 according to a fourth embodiment. In the fourth embodiment, a protocol version (PV) field 1604 can be used to distinguish multilink frames from legacy and PV1 (802.11ah) frames. For example, if the PV field 1604 is set to a value of 2, it indicates that the MPDU 1600 is a multilink frame. Alternatively, one or more new frame types may be defined in 802.11be to indicate a new MAC header format. In addition, the MAC header 1602 includes an ML Control field 1606 that can be used to carry control information related to multilink transmission. The ML Control field 1606 includes a Control ID subfield 1608, which, when set to a certain value, carries an ML Address 1 subfield 1610 and an ML Address 2 subfield 1612.

[0090] Control ID subfield 1608 indicates the options of ML Control field 1606. For example, when Control ID subfield 1608 has a value of 1, ML Control field 1606 carries the MAC addresses of the receiving / transmitting MLDs. These MAC addresses are indicated in ML Address 1 subfield 1610 and ML Address 2 subfield 1612. For example, ML Address 1 subfield 1610 is set to the MAC address of the transmitter MLD, and ML Address 2 subfield 1612 is set to the MAC address of the receiving MLD. The AAD and nonce construction during CCMP encapsulation / decapsulation will then use the MLD addresses carried in the multilink frame. For example, as indicated in ML Address 1 subfield 1610, the A1 field of the constructed AAD will be set to the MLD address of the receiving MLD, while as indicated in ML Address 2 subfield 1612, the A2 field of the constructed AAD and nonce will be set to the MLD address of the transmitting MLD. As previously explained, the A3 field may also be set to the MLD address of the AP MLD, if applicable. Even if one or both ML addresses in the ML control field 1606 use a short ID format (i.e., a 12-bit MLD ID) instead of a full MAC address (48 bits), the AAD and random number may still use the full MAC address corresponding to the MLD ID (i.e., retrieved from the association record (of the AP MLD) or from a record of MLD MAC addresses mapped to MLD IDs, such as saved during the multi-link association process).

[0091] Figure 17Flowchart 1700 depicts reception of an MPDU according to a first embodiment. At step 1702, an MPDU is received. At step 1704, a determination is made as to whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1724, where the MPDU is passed to the next process for reception, and the process then ends at step 1726. If, at step 1704, the MPDU is determined to be protected, the process proceeds to step 1706, where a determination is made as to whether the MPDU uses the new frame format, for example, by checking whether the PV field in the MAC header of the received MPDU has a value of 2. If, at step 1704, the PV field is determined to not have a value of 2, the process proceeds to step 1720, where the constructed AAD and the A2 field of the random number are set to the A2 field of the MPDU, proceeds to step 1722, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step 1712. If it is determined in step 1706 that the PV field has a value of 2, the process proceeds to step 1708, where the A1 field of the constructed AAD is set to the MLD MAC address corresponding to the ML Address 1 subfield in the ML Control field of the received MPDU, proceeds to step 1710, where the A2 field of the constructed AAD and random number is set to the MLD MAC address corresponding to the ML Address 2 subfield in the ML Control field of the received MPDU, and then continues at step 1712. In step 1712, the remaining fields in the AAD and random number are set as usual. Although not shown in the figure, in an MPDU where A3 is set to the BSSID (e.g., a data frame to / from DS=0 or a management frame), if the BSSID of link 2 is different, A3 (set to the BSSID in such a frame; the BSSID is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of that link, if different from MLD-TA) if the sender is an AP MLD, and is also changed to MLD-RA (or the BSSID of that link, if different from MLD-RA) if the sender is a non-AP MLD. In step 1714, CCMP decapsulation is performed on the MPDU using the constructed AAD and random number. In step 1716, the decrypted MPDU is passed to the next process for reception, and the process ends in step 1718. The advantageous effect of the above process is that CCMP encapsulation / decapsulation is still based on MPDU fields, thus minimizing the modifications required to implement this embodiment.

[0092] The techniques described in the first to third embodiments may also be used for the Galois / Counter Mode Protocol (GCMP), which is currently used by Directed Multi-Gigabit (DMG) and Enhanced DMG (EDMG) 802.11 STAs, but may also be used by sub-7 GHz 802.11 STAs in the future. Figure 18A Diagram 1800 illustrates the GCMP encapsulation process for forming an encrypted MPDU according to a fifth embodiment. CCMP operates in a "chained" mode, requiring the orderly processing of 16-byte chunks, as the chained cipher mode requires the output of one stage to be used as the input for the next. GCMP, on the other hand, uses the same AES cipher engine but embeds it into a more efficient framework. Compared to CCMP, GCMP requires only half the number of encryption operations, and more importantly, GCMP is not chained, allowing GCMP cryptographic acceleration to be applied in parallel to the entire transmit frame. As can be seen from diagram 1800, the GCMP encapsulation process is virtually identical to CCMP encapsulation. However, while the AAD 1802 used in the GCMP encapsulation is identical to the AAD used in the CCMP encapsulation, the random number 1804 used in the GCMP encapsulation differs from the random number used in the CCMP encapsulation in that it does not include a priority field.

[0093] Figure 18B A diagram depicts a GCMP-protected MPDU 1806 according to a fifth embodiment. Having been encrypted by GCMP, the MPDU 1806 includes a GCMP header 1808, rather than a CCMP header. The GCMP header 1808 includes an options field, which in turn carries an address field 1809 for signaling the address field to be used to construct the AAD and nonce fields during GCMP decapsulation. Figure 18C A diagram illustrates the GCMP decapsulation process for forming a plaintext MPDU according to a fifth embodiment. Similar to GCMP encapsulation, the GCMP decapsulation process is nearly identical to CCMP decapsulation. However, while the constructed AAD 1812 used for GCMP decapsulation is identical to the constructed AAD used for CCMP decapsulation, the constructed random number 1814 used for GCMP decapsulation differs from the random number used for CCMP decapsulation in that random number 1814 does not include a priority field. The receiving MLD can reference address field 1809 to determine the address field to be used to construct the AAD and random number fields during GCMP decapsulation.

[0094] Figure 19 Diagram 1900 depicts multi-link MPDU transmission using common packet number (PN) assignment for all links according to various embodiments. Figure 3300 in Figure 300 shows a multi-link MPDU transmission using separate PTKs, but using a common PN allocation in link 1 and link 2 for sending the MPDUs. In this example, MPDU 1902 on link 1 fails to be sent, so it is scheduled to be retransmitted on a different link (such as link 2 instead of link 1). Since link 2 uses a different PTK (i.e., Key 2), the MPDU needs to be encapsulated with Key 2 as MPDU 1904, but still uses the same SN=4 and the same PN=104 as MPDU 1902 for this encapsulation (since the common PN allocation is used for link 1 and link 2). The receiver MLD then reorders the received MPDUs on link 2 according to the SN of each received MPDU, including MPDU 1904. When reordering up to SN=4, i.e., up to the received MPDU 304 with SN=4 and PN=104, the receiver MLD updates the replay counter to PN=104. Unlike Figure 3 300, where the remaining MPDUs with SN greater than 4 (i.e., received MPDU 306 with SN=6, PN=52 and received MPDU 308 with SN=7, PN=53) are discarded, resulting in a replay rejection problem. MPDUs 1906 and 1908 pass the replay check because the PNs are in order after the reordering process. Therefore, regardless of the number of PTKs, if a common PN space is used to assign PNs to the keys and the same PN is used for retransmissions, the previously described replay rejection problem is resolved.

[0095] Figure 20A schematic diagram of a transmitter MLD 2000 according to various embodiments is depicted. The transmitter MLD includes a MAC-SAP 2002 for performing a distribution service (DS), a transmit buffer 2004 for storing unprotected MPDUs and, optionally, protected MPDUs, a sequence number (SN) assignment module 2006, a packet number (PN) assignment module 2008, an MPDU encryption and integrity module 2010, and a retransmission module 2012, which determines the link to be used for retransmission and the MAC address to be used for AAD and random number construction during the cryptographic encapsulation process. The transmitter MLD 2000 also includes two dependent STAs or stations, STA1 2014a and STA2 2014b. STA1 2014a includes an MPDU header & CRC creation module 2020a, a transmit (Tx) buffer and block acknowledgement (ack) control module 2022a, and an aggregation control 2024a at the MAC layer 2016a. Similarly, STA2 2014b includes an MPDU header & CRC creation module 2020b, a Tx buffer and block ack control module 2022b, and an aggregation control 2024b at the MAC layer 2016b. Both STAs include a PHY layer from which transmissions via link 1 (for STA1 2014a) and link 2 (for STA2 2014b) emerge. It will be appreciated that the number of links and affiliated STAs or stations can be further extended. The above architecture is suitable when the same PTK (and / or GTK / IGTK) is used for all links, even if different PTKs are used for the links, if the same PN space is used for all links, this can help avoid replay rejection issues, such as Figure 19 However, in deployments that choose to use different PTKs (and / or GTKs / IGTKs), the MPDU encryption and integrity module 2010 can be moved down to the corresponding subordinate STA. If a separate PN space is used for the link (PNs are typically bound to their corresponding secret keys), the packet number (PN) allocation module 2008 can also be moved down to the corresponding subordinate STA.

[0096] Figure 21A schematic diagram of a receiver MLD 2100 according to various embodiments is depicted. The receiver MLD includes a MAC-SAP 2102 for performing distribution services (DS), a replay detection module 2104, an MPDU decryption and integrity module 2106, a block Ack buffering and reordering module 2108, and a duplicate detection module 2110. The receiver MLD 2100 also includes two dependent STAs or stations, STA1 2114a and STA2 2114b. STA1 2114a includes a block Ack scoreboard module 2120a, an address 1 filter module 2122a, and a deaggregation control 2124a at the MAC layer 2116a. Similarly, STA2 2114b includes a block Ack scoreboard module 2120b, an address 1 filter module 2122b, and a deaggregation control 2124b at the MAC layer 2116b. Both STAs include a PHY layer (i.e., 2118a for STA1 2114a and 2118b for STA2 2114b), from which transmissions via Link 1 (i.e., between STA1 2114a and STA1 2014a at the transmitter MLD 2000) and Link 2 (i.e., between STA2 2114b and STA2 2014b at the transmitter MLD 2000) originate. It will be appreciated that the number of links and associated STAs or stations can be further expanded. The MPDU decryption and integrity module 2106 is responsible for parsing the address field in the CCMP / GCMP header to determine the address field used to construct the AAD and random number fields during CCMP / GCMP decapsulation.

[0097] Figure 22A flowchart 2200 is shown illustrating a method for multi-link secure retransmission of an MPDU according to various embodiments. In step 2202, at a first MLD configured to operate with a first plurality of dependent STAs, a Robust Security Network Association (RSNA) is established with a second MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs. In step 2204, Additional Authentication Data (AAD) and a nonce are constructed, the AAD comprising an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, and a Sequence Control (SC) field, and the nonce comprising an Address 2 (A2) field, the SC field of the AAD being based on the SC field of the MPDU. In step 2206, the MPDU is cryptographically encapsulated using the AAD and the nonce to form an encapsulated MPDU. If applicable, the address field in the CCMP / GCMP header is set to signal the address field used to generate the AAD and nonce fields. At step 2208, the encapsulated MPDU is sent from the first MLD to the second MLD on the first link as an initial transmission. At step 2210, if the initial transmission fails, the encapsulated MPDU is resent on the second link without re-performing cryptographic encapsulation. If applicable, the address field in the CCMP / GCMP header in the resent MPDU is set to signal the address field used to generate the AAD and random number fields during the encapsulation process.

[0098] Figure 23 Schematic partial cross-sectional views of a multi-link device 2300 that may be implemented for multi-link safety retransmission according to the first to fifth embodiments are shown. The multi-link device 2300 may be implemented as an AP MLD or a non-AP MLD and include one or more dependent stations or STAs according to various embodiments.

[0099] The various functions and operations of the multi-link device 2300 are arranged as layers according to a hierarchical model. In the model, lower layers report to and receive instructions from higher layers according to IEEE specifications. For simplicity, the details of the hierarchical model are not discussed in this disclosure.

[0100] like Figure 23 As shown, the multi-link device 2300 may include circuitry 2314, at least one radio transmitter 2302, at least one radio receiver 2304, and multiple antennas 2312 (for simplicity and for illustration purposes, the antennas 2312 are not shown in FIG). Figure 23(Only one antenna is depicted in the figure). The circuitry may include at least one controller 2306 for software and hardware assistance in performing the tasks it is designed to perform, including controlling communications with one or more other multi-link devices in a MIMO wireless network. The at least one controller 2306 may control at least one transmit signal generator 2308 for generating MPDUs to be transmitted to the one or more other multi-link devices via at least one radio transmitter 2302, and at least one receive signal processor 2310 for processing MPDUs received from the one or more other multi-link devices via at least one radio receiver 2304. The at least one controller 2306 may also control the at least one transmit signal generator 2308 and / or the at least one receive signal processor 2310 for constructing AAD and random number frames and performing CCMP or GCMP encapsulation or decapsulation on the MPDUs using the constructed AAD and random number frames. The at least one transmit signal generator 2308 and the at least one receive signal processor 2310 may be independent modules of the multi-link device 2300 that communicate with the at least one controller 2306 for the aforementioned functions. Alternatively, at least one transmit signal generator 2308 and at least one receive signal processor 2310 may be included in at least one controller 2306. Those skilled in the art will appreciate that the arrangement of these functional modules is flexible and may vary based on actual needs and / or requirements. Data processing, storage, and other related control devices may be provided on appropriate circuit boards and / or in chipsets.

[0101] In various embodiments, at least one radio transmitter 2302, at least one radio receiver 2304, and at least one antenna 2312 may be controlled by at least one controller 2306. Furthermore, while only one radio transmitter 2302 is shown, it will be understood that there may be more than one such transmitter, i.e., one transmitter for each secondary station or STA of the multi-link device 2300.

[0102] In various embodiments, at least one radio receiver 2304, together with at least one receive signal processor 2310, forms a receiver of the multi-link device 2300. The receiver of the multi-link device 2300 provides the functionality required for multi-link communication. Although only one radio receiver 2304 is shown, it will be understood that there may be more than one such receiver, i.e., one receiver for each attached station or STA of the multi-link device 2300.

[0103] Multi-link device 2300 provides functionality required for multi-link secure retransmission. For example, multi-link device 2300 may be a first multi-link device operating with a first plurality of dependent STAs. Circuitry 2314 may establish a robust security network association (RSNA) with a second multi-link device configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs. The circuitry is configured to cryptographically encapsulate a MAC protocol data unit (MPDU) to form additional authentication data (AAD) and a random number of the encapsulated MPDU, the AAD including an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, the random number including an address 2 (A2) field, and the SC field of the AAD based on the SC field of the MPDU. Transmitter 2302 may transmit the encapsulated MPDU as an initial transmission to the second multi-link device on the first link and, if the initial transmission fails, retransmit the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0104] The AAD and the A2 field of the random number may be set to identify the media access control (MAC) address of the first MLD, and the A1 field of the AAD may be set to identify the MAC address of the second MLD. One of CCMP or GCMP may be used to cryptographically protect the MPDU. The MPDU may include identification information of the first MLD and the second MLD, the AAD and the A2 field of the random number may be set to identify the MAC address of the first MLD indicated in the identification information, and the A1 field of the AAD may be set to identify the MAC address of the second MLD indicated in the identification information.

[0105] The circuit 2314 may specify a setting in the MPDU settings of the A1 field, the A2 field, and the A3 field, wherein the setting indicates whether, during cryptographic decapsulation of the MPDU, the A1 field, the A2 field, and the A3 field are to be set to the MAC address identifying the second MLD, the MAC address identifying the first MLD, and the MAC address identifying the AP MLD, respectively; or whether the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the MPDU, respectively, where the AP MLD is the first MLD or the second MLD. The settings of the A1 field, the A2 field, and the A3 field may be indicated in one of the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) header field or the Galois / Counter Mode Protocol (GCMP) header field of the encapsulated MPDU.

[0106] The AAD and the A2 field of the random number can be set to the A2 field of the MPDU, and the A1 field of the AAD can be set to the A1 field of the MPDU. When the initial transmission fails, the circuit 2314 can also specify a setting in the retransmitted MPDU setting of the A1 field, the A2 field, and the A3 field, where the setting indicates whether during the cryptographic decapsulation of the retransmitted MPDU, the A1 field, the A2 field, and the A3 field are to be set to the MAC address of the subordinate STA of the second MLD, the MAC address of the subordinate STA of the first MLD, and the MAC address identifying the AP MLD, respectively, or the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the retransmitted MPDU, respectively.

[0107] For example, the multi-link device 2300 may be a first multi-link device operating with a first plurality of dependent STAs. The circuit 2314 may establish a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between STAs in the first plurality of dependent STAs and corresponding STAs in the second plurality of dependent STAs. The receiver 2304 may receive a cryptographically encapsulated MAC protocol data unit (MPDU) from the second MLD, and the circuit 2314 may construct additional authentication data (AAD) and a random number for cryptographic decapsulation of the received MPDU, wherein the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, and the random number includes an address 2 (A2) field, the A2 field of the AAD and the random number may be set to the A2 field of the MPDU or a medium access control (MAC) address identifying the second MLD or a MAC address of one of the second plurality of dependent STAs, the A1 field of the AAD may be set to the A1 field of the MPDU or a MAC address identifying the first MLD or a MAC address of one of the first plurality of dependent STAs, the address 3 (A3) field of the AAD may be set to the BSSID field of the link, the A3 field of the MPDU, or the MAC address of the AP MLD, and the SC field of the AAD is based on the SC field of the MPDU.

[0108] Circuitry 2314 may cryptographically decapsulate an MPDU received from a second MLD. The A2 field of the AAD and the nonce may be set to the MAC address identifying the second MLD, and the A1 field of the AAD may be set to the MAC address identifying the first MLD. CCMP or GCMP may be used to cryptographically decapsulate the MPDU. The MPDU may carry identification information for the first MLD and the second MLD. The circuitry may cryptographically decapsulate the MPDU by setting the A2 field of the AAD and the nonce to the MAC address identifying the second MLD indicated in the MPDU and setting the A1 field of the AAD to the MAC address identifying the first MLD indicated in the MPDU.

[0109] The circuit 2314 may cryptographically decapsulate the received MPDU based on the settings of the A1 field, the A2 field, and the A3 field indicated in the MPDU, indicating whether, during cryptographic decapsulation, the A1 field, the A2 field, and the A3 field are to be set to the MAC address identifying the first MLD, the MAC address identifying the second MLD, and the MAC address identifying the AP MLD, respectively; or whether the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the MPDU, respectively, where the AP MLD is the first MLD or the second MLD. The setting of the address field may be indicated in one of the CCMP header or the GCMP header of the MPDU received from the second MLD.

[0110] The circuit 2314 may cryptographically decapsulate the first MPDU received from the second MLD by setting the A2 field of the AAD and the random number to the A2 field of the first MPDU and setting the A1 field of the AAD to the A1 field of the first MPDU, the first MPDU including a retry subfield set to 0; the circuit 2314 may cryptographically decapsulate the second MPDU received from the second MLD based on the settings of the A1 field, the A2 field, and the A3 field indicated in the second MPDU, the settings indicating whether, during cryptographic decapsulation, the A1 field, the A2 field, and the A3 field are to be set to the MAC address of the subordinate STA of the first MLD, the MAC address of the subordinate STA of the second MLD, and the MAC address identifying the AP MLD, respectively, or the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the second MPDU, respectively, the second MPDU including a retry subfield set to 1.

[0111] The present disclosure can be implemented by software, hardware, or software in collaboration with hardware. Each functional block used in the description of each of the above embodiments can be partially or entirely implemented by an LSI such as an integrated circuit, and each process described in each embodiment can be partially or entirely controlled by the same LSI or a combination of LSIs. The LSI can be formed as a chip alone, or can be formed as a chip to include some or all functional blocks. The LSI can include data inputs and outputs coupled thereto. Depending on the degree of integration, the LSI here can be referred to as an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing the integrated circuit is not limited to the LSI and can be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. In addition, an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured or a reconfigurable processor in which the connections and settings of the circuit units arranged inside the LSI can be reconfigured can be used. The present disclosure can be implemented as digital processing or analog processing. If future integrated circuit technology replaces the LSI due to advances in semiconductor technology or other derivative technologies, the future integrated circuit technology can be used to integrate the functional blocks. Biotechnology can also be applied.

[0112] The present disclosure may be implemented by any kind of apparatus, device, or system having a communication function, which is referred to as a communication device.

[0113] A communication device may include a transceiver and processing / control circuitry. The transceiver may include and / or function as a receiver and a transmitter. As both a transmitter and a receiver, the transceiver may include an RF (radio frequency) module (including an amplifier, an RF modulator / demodulator, etc.), and one or more antennas.

[0114] Some non-limiting examples of such communication devices include phones (e.g., cellular (mobile) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (remote health and medical) devices, and vehicles providing communication capabilities (e.g., cars, airplanes, ships), and various combinations thereof.

[0115] Communication devices are not limited to being portable or movable and may also include any type of apparatus, device, or system that is not portable or stationary, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other “things” in an “Internet of Things” (IoT) network.

[0116] Communications may include exchanging data via, for example, cellular systems, wireless LAN systems, satellite systems, etc., and various combinations thereof.

[0117] A communication device may include a device, such as a controller or a sensor, coupled to a communication device that performs the communication functions described in the present disclosure. For example, a communication device may include a controller or a sensor that generates a control signal or a data signal that is used by the communication device that performs the communication functions of the communication device.

[0118] Communications equipment may also include infrastructure such as base stations, access points, and any other apparatus, device, or system that communicates with or controls devices such as the non-limiting examples above.

[0119] As a framework (e.g. Figure 20 and Figure 21 As a non-limiting example of the architecture shown in FIG, the MLD of the present disclosure may be logical and may be implemented by multiple separate communication devices sharing a common MAC data service interface to upper layers.

[0120] A non-limiting example of a station may be a station included in a first plurality of stations attached to a multi-link station logical entity (i.e., such as an MLD), wherein as part of the first plurality of stations attached to the multi-link station logical entity, the stations in the first plurality of stations share a common medium access control (MAC) data service interface to an upper layer, wherein the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0121] Therefore, it can be seen that the present embodiment provides a communication device and method for operating on multiple links to fully realize the throughput gain of multi-link communication, and is specifically used for multi-link secure retransmission.

[0122] Although exemplary embodiments have been presented in the foregoing detailed description of the present embodiment, it should be understood that there are a large number of variations. It should also be understood that the exemplary embodiments are examples and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. On the contrary, the foregoing detailed description will provide those skilled in the art with a convenient roadmap for implementing the exemplary embodiments, and it should be understood that various changes may be made to the steps and methods of the operations described in the exemplary embodiments and the functions and arrangements of the modules and structures of the devices described in the exemplary embodiments without departing from the scope of the subject matter set forth in the appended claims.

Claims

1. A transmitting multi-link device (MLD) configured to operate with a first plurality of affiliated STAs, comprising: circuitry for establishing a robust security network association (RSNA) with a receiving MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between a STA in the first plurality of dependent STAs and a corresponding STA in the second plurality of dependent STAs, wherein the circuitry is configured to cryptographically encapsulate additional authentication data (AAD) and a random number in a medium access control (MAC) protocol data unit (MPDU), and encapsulate a plaintext MAC protocol data unit (MPDU), the AAD (700), and the random number (706) to generate an encapsulated MPDU, wherein the AAD includes an address 1 (A1) field to which the MAC address of the receiving MLD is set, an address 2 (A2) field to which the MAC address of the transmitting MLD is set, an address 3 (A3) field, and a sequence control (SC) field, and the random number includes an address 2 (A2) field to which the MAC address of the transmitting MLD is set, wherein the SC field of the AAD is based on the SC field of the MPDU; and The transmitter sends the encapsulated MPDU as an initial transmission to the receiving MLD on a first link, and resends the encapsulated MPDU on a second link without changing a packet number PN used in the initial transmission when the initial transmission of the encapsulated MPDU fails.

2. The method of sending MLD according to claim 1, wherein: The A3 field of the AAD is set to identify the MAC address of an access point (AP) MLD, which is the transmitting MLD or the receiving MLD.

3. The method of claim 1, wherein: The circuit specifies settings in the MPDU settings of the A1 field, the A2 field, and the A3 field, the settings indicating that during cryptographic decapsulation of the retransmitted MPDU, the A1 field, the A2 field, and the A3 field are to be set to the MAC address identifying the receiving MLD, the MAC address identifying the transmitting MLD, and the MAC address identifying the transmitting MLD or the receiving MLD, respectively; or the A1 field, the A2 field, and the A3 field are to be set to the MAC address of the subordinate STA of the receiving MLD, the MAC address of the subordinate STA of the transmitting MLD, and the MAC address identifying the AP MLD, respectively; or the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the MPDU, respectively, where the AP MLD is the transmitting MLD or the receiving MLD.

4. The method of sending MLD according to claim 2, wherein: The settings of the A1 field, the A2 field, and the A3 field are indicated in one of the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) header field or the Galois / Counter Mode Protocol (GCMP) header field of the encapsulated MPDU.

5. The method of claim 1, wherein: The AAD and the A2 field of the random number are set to the A2 field of the MPDU, and the A1 field of the AAD is set to the A1 field of the MPDU, wherein when the initial transmission fails, the circuit further specifies a setting in the retransmitted MPDU setting of the A1 field, the A2 field, and the A3 field, and the setting indicates that during the cryptographic decapsulation of the retransmitted MPDU, the A1 field, the A2 field, and the A3 field are to be set to the MAC addresses of the subordinate STA of the receiving MLD and the subordinate STA of the transmitting MLD, respectively, or the A1 field, the A2 field, and the A3 field are to be set to the A1 field, the A2 field, and the A3 field of the retransmitted MPDU, respectively.

6. The method of claim 1, wherein: One of the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or the Galois Counter Mode Protocol (GCMP) is used to cryptographically protect the MPDU.

7. A method for a transmitting multi-link device (MLD) operating with a first plurality of dependent STAs, comprising: establishing a robust security network association (RSNA) with a receiving MLD configured to operate with a second plurality of dependent STAs, wherein two or more links have been established between a STA in the first plurality of dependent STAs and a corresponding STA in the second plurality of dependent STAs, constructing additional authentication data (AAD) and a random number for cryptographically encapsulating a medium access control (MAC) protocol data unit (MPDU), and encapsulating a plaintext MAC protocol data unit (MPDU), the AAD (700), and the random number (706) to generate an encapsulated MPDU, wherein the AAD includes an address 1 (A1) field to which the MAC address of the receiving MLD is set, an address 2 (A2) field to which the MAC address of the transmitting MLD is set, an address 3 (A3) field, and a sequence control (SC) field, and the random number includes an address 2 (A2) field to which the MAC address of the transmitting MLD is set, wherein the SC field of the AAD is based on the SC field of the MPDU; as well as The encapsulated MPDU is sent to the receiving MLD on a first link as an initial transmission, and when the initial transmission of the encapsulated MPDU fails, the encapsulated MPDU is resent on a second link without changing a packet number PN used in the initial transmission.

Images