COMMUNICATION APPARATUS AND METHOD FOR SECURE RETRANSMISSION OF MULTI-LINKS - Patent application

Abstract

The multi-link device (MLD) includes: a multi-link device (MLD) configured to operate with a first plurality of attached STAs; a second MLD configured to operate with a second plurality of attached STAs; circuitry for setting up a robust security network association (RSNA), wherein two or more links are established between STAs of the first plurality of attached STAs and corresponding STAs of the second plurality of attached STAs; circuitry for constructing additional authentication data (AAD) and a nonce used for cryptographic encapsulation of a MAC protocol data unit (MPDU) to form an encapsulated MPDU; and a transmitter for transmitting the encapsulated MPDU to the second MLD on the first link as an initial transmission and, if the initial transmission fails, retransmitting the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

Description

[Technical field]

[0001] The present embodiments relate generally to communication devices, and more particularly to a method and apparatus for multi-link secure transmission. [Background technology]

[0002] Today, communication devices are expected to perform the same functions wirelessly as wired computing devices. For example, users expect to be able to seamlessly watch high definition movies streamed to their wireless communication devices. This creates challenges for the communication devices and the access points to which they wirelessly connect.

[0003] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 Group recently formed the Extreme High Throughput (EHT) Study Group to address these challenges. Multi-link operation in the 2.4 GHz, 5 GHz, and 6 GHz frequency bands has been identified as an important candidate technology for such communications. Multi-channel aggregation across multiple links is a natural way to increase communication data throughput several-fold.

[0004] Additionally, such IEEE 802.11 devices use security protocols, including but not limited to Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or Galois / counter mode protocol (GCMP), 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 [Problem to be solved by the invention]

[0005] Non-limiting examples of the present disclosure are directed to providing devices and methods for secure retransmission of multi-links. [Means for solving the problem]

[0006] One non-limiting and exemplary embodiment includes a first Multi-Link Device (MLD) configured to operate with a first plurality of affiliated STAs (Stations), and a circuit for setting up a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of affiliated STAs, wherein two or more links are established between a STA of the first plurality of affiliated STAs and a corresponding STA of the second plurality of affiliated STAs, and a circuit for constructing additional authentication data (AAD) and a nonce used for cryptographical encapsulation of a MAC protocol data unit (MPDU) to form an encapsulated MPDU, wherein the AAD comprises an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, and a Sequence Control (SEQ) field. In one aspect, the present invention facilitates providing a first multi-link device (MLD) comprising: circuitry, wherein the circuitry includes a AAD (Anonymous Control) (SC) field, the nonce includes an A2 field, and the SC field of the AAD is based on the SC field of the MPDU; and a transmitter that, when operational, transmits an encapsulated MPDU on the first link to a second MLD as an initial transmission and, if the initial transmission fails, retransmits the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0007] Another non-limiting and exemplary embodiment is a method for retransmitting an MPDU in a multi-link communication, comprising the steps of: setting up a Robust Security Network Association (RSNA) in a first MLD configured to operate with a first plurality of attached STAs with a second MLD configured to operate with a second plurality of attached STAs, where two or more links are established between a STA of the first plurality of attached STAs and a corresponding STA of the second plurality of attached STAs; constructing an Additional Authentication Data (AAD) and a nonce, where the AAD includes an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, and a Sequence Control (SC) field, where the nonce includes an A2 field, where the SC field of the AAD is based on the SC field of the MPDU; and cryptographically encapsulating the MPDU using the AAD and the nonce. forming an encapsulated MPDU, transmitting the encapsulated MPDU from the first MLD over the first link as an initial transmission to the second MLD, and retransmitting the encapsulated MPDU over the second link without re-performing cryptographic encapsulation if the initial transmission fails.

[0008] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. Benefits and / or advantages may be obtained individually from various embodiments and features of the specification and drawings, and not all need be provided to obtain one or more of such benefits and / or advantages. [Brief description of the drawings]

[0009] The accompanying drawings, together with the following detailed description, are incorporated in and constitute a part of this specification, and serve to illustrate various embodiments and to explain various principles and advantages according to the present embodiments. Throughout the different drawings, like reference numbers indicate identical or functionally similar elements. [Figure 1] 1 illustrates steps for processing a Medium Access Control (MAC) Protocol Data Unit (MPDU) using CCMP, according to various embodiments. [Figure 2A] 1 illustrates an illustration of a protected MPDU according to various embodiments. [Figure 2B] 1 illustrates an illustration of a MAC header of a protected MPDU in accordance with various embodiments. [Diagram 3] 1 shows an illustration of a multi-link MPDU transmission using a separate Pairwise Temporal Key (PTK) on each link. [Figure 4] 1 illustrates an illustration of a multi-link MPDU transmission using a single PTK on all links according to various embodiments. [Diagram 5] 1 shows an illustration of a CCMP encapsulation process for forming an encrypted MPDU, according to various embodiments. [Figure 6] 2 shows an illustration of a method for retransmitting an unprotected MPDU on a different link according to a first embodiment; [Figure 7A] 1 shows an illustration of an additional authentication data (AAD) frame according to a first embodiment. [Figure 7B] 2 shows an illustration of a Nonce frame according to a first embodiment; [Figure 8] 2 shows an illustration of a CCMP decapsulation process to form a plaintext MPDU according to a first embodiment; [Figure 9] 4 shows a flowchart of the initial transmission of an MPDU according to the first embodiment. [Figure 10]2 shows a flowchart of retransmission of an MPDU according to a first embodiment. [Figure 11] 4 shows a flowchart of receiving an MPDU according to the first embodiment. [Figure 12] 1 shows an illustration of a protected MPDU according to a second embodiment; [Figure 13] 13 shows a flowchart of receiving an MPDU according to a second embodiment. [Figure 14] 13 shows an illustration of a protected MPDU according to a third embodiment; [Figure 15] 13 shows a flowchart of receiving an MPDU according to a third embodiment. [Figure 16] 13 shows an illustration of a protected MPDU according to a fourth embodiment; [Figure 17] 13 shows a flowchart of receiving an MPDU according to a fourth embodiment. [Figure 18A] 13 shows an illustration of a Galois / Counter Mode Protocol (GCMP) encapsulation process for forming an encrypted MPDU according to a fifth embodiment. [Figure 18B] 13 shows an illustration of a GCMP protected MPDU according to a fifth embodiment; [Figure 18C] 13 shows an illustration of a GCMP decapsulation process to form a plaintext MPDU according to a fifth embodiment. [Figure 19] 1 illustrates an illustration of a multi-link MPDU transmission using a common Packet Number (PN) assignment on all links, according to various embodiments. [Figure 20] 2 shows a schematic diagram of a sender MLD 2000 according to various embodiments. [Figure 21] 2 shows a schematic diagram of a receiver MLD 2100 according to various embodiments. [Figure 22] 2 shows a flowchart 2200 illustrating a method for secure retransmission of multilink, according to various embodiments. [Figure 23] 23 shows a schematic partial cross-sectional view of one of the attached STAs of a multi-link device 2300 operable for multi-link secure retransmission according to the first to fifth embodiments.

[0010] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] The following detailed description is merely illustrative and is not intended to limit the embodiments or the application and uses of the embodiments. Moreover, it is not intended to be bound by any theory presented in the preceding Background or Detailed Description sections. Moreover, 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 this disclosure.

[0012] Referring to FIG. 1, this figure shows the steps in 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 to create a CCMP header. 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 ciphertext. In step 5, the MAC header is restored by prepending the MAC header to 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.

[0013] 2A shows an illustration of a protected MPDU 200 according to various embodiments. 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. As described in FIG. 1, the Data (Payload) field and the MIC field are encrypted. The CCMP Header field includes a PN0 field, a PN1 field, a Reserved (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.

[0014] The MAC Header field 202 is shown in detail in FIG. 2B 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 further 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.

[0015] In general, 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. [Table 1]

[0016] If the contents of the "To DS" subfield and the "From DS" subfield are both "0", the contents of the A1 field are the receiver address (RA) (= destination address (DA)), the contents of the A2 field are the sender address (TA) (= source address (SA)), the contents of the A3 field are the basic service set identifier (BSSID), and address 4 does not exist. If the contents of the "To DS" subfield are "0" and the contents of the "From DS" subfield are "1", the contents of the A1 field are RA, the contents of the A2 field are the sender address (TA) (= BSSID), the contents of the A3 field are SA, and address 4 does not exist. If the contents of the "To DS" subfield are "1" and the contents of the "From DS" subfield are "0", the contents of the A1 field are RA (= BSSID), the contents of the A2 field are TA, the contents of the A3 field are DA, and address 4 does not exist. If the contents of the "To DS" subfield and the "From DS" subfield are both "1", the content of the A1 field is RA, the content of the A2 field is TA, the content of the A3 field is DA, and address 4 is set to SA.

[0017] For management frames, the contents of the A1, A2, and A3 address fields are generally the same as for data frames with "To DS" = 0 and "From DS" = 0, i.e. the A1 field contains RA (= DA) and the A2 field contains TA (= SA). A3 depends on the frame type, but is almost always set to the BSSID. If a STA sends a management frame to an access point (AP) with multiple BSSIDs configured, the Address 3 field is the BSSID of the AP's BSS (either the transmitting or non-transmitting BSSID), regardless of whether the STA is associated with that AP or not.

[0018] Multi-link operation in next generation wireless LANs such as 802.11be may allow MPDUs with the same TID (traffic ID) to be transmitted simultaneously on different links. However, such multi-link transmission may lead to unexpected behavior when security encapsulation is applied to the MPDUs, as described below. When MPDUs with the same TID (traffic ID) can be transmitted simultaneously on different links, the same sequence number (SN) space may be used to assign SNs to MSDUs or MMPDUs carried in the MPDU, regardless of the link used for the actual transmission, so that the receiver MLD can correctly reorder the MPDUs received on different links. During the initial setup of the link between the AP MLD and the non-AP MLD (e.g., immediately after the multi-link association procedure), a single PMK (Pairwise Master Key) may be negotiated between the AP MLD and the non-AP MLD to be used as the master key for the secure transmission between the two MLDs. The PTKs (Pairwise Temporal Keys) and GTKs / IGTKs ((Integrity) Group Temporal Keys) used for secure encapsulation / decapsulation of MPDUs can be derived from the same PMK for different links. It is possible to generate separate PTKs and separate GTKs / IGTKs for use on different links. FIG. 3 shows an illustration 300 of a multi-link MPDU transmission using a separate PTK on each link. In this example, a sender MLD transmits an MPDU to a receiver MLD on link 1 and link 2. On link 1 it uses PTK key 1 and on link 2 it uses a different PTK key 2. Also, the MPDU transmission on both links uses a common sequence number (SN), but the packet number (PN) counters used on each link are different.For example, the PN counter of an MPDU transmitted on link 1 starts at PN=100, and the PN counter of an MPDU transmitted on link 2 starts at PN=51.

[0019] In this example, MPDU 302 on link 1 failed to transmit and is scheduled to be retransmitted on another link, say link 2, instead of link 1. Since a different PTK (i.e., key 2) is used on link 2, MPDU 302 needs to be encapsulated as MPDU 304 with key 2 and a new PN=54 (as it is scheduled for retransmission after the transmission of MPDU 308 with PN=53), but MPDU 304 still shares the same SN=4 as MPDU 302. On the receiving side, the receiver MLD reorders the MPDUs received on link 2 according to the SN of each received MPDU, including MPDU 304. When reordering up to SN=4, i.e., the received MPDU 304 with SN=4 and PN=54, the receiver MLD updates the replay counter to PN=54. As a result, the remaining MPDUs with SN greater than 4 and PN less than 54 (i.e., received MPDU 306 with SN=5, PN=52 and received MPDU 308 with SN=7, PN=53) are dropped, resulting in an unintended replay denial problem.

[0020] Also, even if a single PTK is used on all links, the replay rejection problem still occurs if the retransmitted MPDU is reencapsulated with a new PN. This can be seen in Figure 4, which shows an illustration 400 of a multi-link MPDU transmission using a single PTK on all links, according to various embodiments. Similar to Figure 3, the sender MLD transmits MPDUs to the receiver MLD on link 1 and link 2. The difference is that the same PTK key 1 is used on both link 1 and link 2. As a result, both links use a common SN assignment and a common PN assignment.

[0021] In this example, MPDU 402 with SN=4, PN=104 on link 1 has failed to transmit and is scheduled for retransmission on a different link, such as link 2, rather than link 1. Since link 2 has different A1, A2 fields compared to link 1, MPDU 402 needs to be reencapsulated as MPDU 404 with a new PN=108 (as it is scheduled for retransmission after the transmission of MPDU 408 with PN=107), but still shares the same SN=4 as MPDU 402. The receiver MLD reorders the MPDUs received on link 2 according to the SN of each received MPDU, including MPDU 404. When reordering up to SN=4, i.e. 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 (i.e., received MPDU 406 with SN=5, PN=105 and received MPDU 408 with SN=7, PN=107) will be dropped, resulting in a replay denial problem.

[0022] Furthermore, IEEE 802.11be may mandate the use of separate MAC addresses per link, but may allow the use of the same MAC address on different links. If separate MAC addresses are used for links, the problem (security flaw) of the same nonce value being reused to protect different data may be avoided when the TA of the two transmitting links is the same, but the RA of the two receiving links is different, and the frame is retransmitted on another link using the same A2 (i.e. =TA) and the same PN (i.e. the PN remains the same across retransmissions to avoid misordering of received PNs after SN reordering by the receiver MLD). However, the IEEE 802.11 specification states the following regarding the use of nonce and PN: "CCM requires a new temporal key for each session. CCM also requires a unique nonce value for each frame protected by a given temporal key; for this purpose CCMP uses a 48-bit packet number (PN). Reusing a PN with the same temporal key voids all security guarantees." That is, reusing the same PN in retransmissions on different links to avoid the replay denial problem solves the problem, but may cause security flaws. Note that, under the above assumption, the retransmitted MPDU needs to be re-encapsulated when retransmitted on a different link. This disclosure provides several options to avoid such security-related problems brought about by multi-link transmission.

[0023] 5 shows an illustration of a CCMP encapsulation process for forming an encrypted MPDU according to the IEEE 802.11 specification. In particular, to form an encrypted or protected MPDU, an Additional Authentication Data (AAD) 502 and a nonce 504 are constructed and used in the cryptographic encapsulation of the MPDU. The 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, and the nonce 504 includes a Nonce Flags field, an A2 field, and a PN field. The contents of the A1, A2, and A3 fields of the AAD 502 and the A2 field of the nonce 504 are taken from the A1, A2, and A3 fields of the MPDU being encapsulated (or decapsulated, in the case of a decapsulation process of an encrypted MPDU).

[0024] For a single-link 802.11 STA, the protected MPDU is retransmitted with the following minimal changes: - The Retry subfield (bit 11) of the FC field is set to 1. However, the Retry subfield and some other subfields of the FC field are generally masked to 0 during CCMP encapsulation. - The CRC is recalculated, but the FCS is not input to the CCMP encapsulation. - MPDUs are encapsulated only on the first transmission, not on retransmissions. However, in the case of MLD, the rules for retransmission of a protected MPDU may depend on the link over which the MPDU is retransmitted. If the same link is used for retransmission, the MPDU is encapsulated only on the first transmission, but not on the retransmission. If a different link is used for retransmission (assuming different MAC addresses of the attached STAs on both ends of the link), the MPDU needs to be reencapsulated before retransmission (it is possible to use the same PN to avoid replay denial problems). However, reusing a PN with the same security key may lead to security flaws.

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

[0026] FIG. 6 shows an illustration of a method for retransmitting unprotected MPDUs on different links according to the first embodiment. A sending MLD 602 ​​is configured to operate with a first plurality of attached STAs, such as STA 604 and STA 606. A MAC address MLD-TA identifies the sending MLD 602 ​​and can be used to represent the MLD for communication with a DS (Distribution Service), while the MAC addresses of STA 604 and STA 606 are TA1 and TA2, respectively. Similarly, a receiving MLD 612 is configured to operate with a second plurality of attached STAs, such as STA 614 and STA 616. A MAC address MLD-RA identifies the receiving MLD 612, while the MAC addresses of STA 614 and STA 616 are RA1 and RA2, respectively. In the case of an MLD, the MLD MAC address may be the same as one of its per-link MAC addresses or may be different. However, it is assumed that the per-link MAC addresses are different from each other (i.e., TA1 ≠ TA2, RA1 ≠ RA2). It will be understood that two or more STAs can form the first and second plurality of attached STAs, and two or more links can be formed between STAs of the first plurality of attached STAs and corresponding STAs of the second plurality of STAs, without necessarily each STA being connected by a link. For example, link 1 can be set up between STA 604 and STA 614, and link 2 can be set up between STA 606 and STA 616. The above-mentioned configuration is also applicable to retransmission of protected or unprotected MPDUs, which will be further described in various embodiments below. Furthermore, it is assumed that a Robust Security Network Association (RSNA) has been set up between the sending MLD and the receiving MLD, and all necessary secret keys (e.g., PTK, GTK / IGBT, etc.) have been generated / distributed, especially for retransmission of protected MPDUs.

[0027] As shown in diagram 600, a transmitting MLD 602 ​​transmits an unprotected MPDU 608 on link 1 to a receiving MLD 612, i.e., from STA 604 to STA 614. Thus, the A1, A2, and A3 fields of the MPDU 608 are set to the MAC address of the receiving STA 614 (i.e., RA1) and the MAC address of the transmitting STA 604 (i.e., TA1), respectively. For the first transmission, the Retry subfield of the FC field of the MPDU 608 is set to 0. In case of a failed transmission due to various reasons (e.g., a temporary failure of link 1), this MPDU can be retransmitted on link 2, i.e., from STA 606 to STA 616, as an unprotected MPDU 610. The unprotected MPDU can be retransmitted on another link simply by setting the Retry subfield of the Frame Control (FC) field of the MPDU to 1 and swapping the A1, A2, and A3 in the MAC header. Thus, the A1 field of the MPDU 610 is set to the MAC address of the receiving STA 616 (i.e., RA2), and the A2 field is set to the MAC address of the sending STA 606 (i.e., TA2). Additionally, the Reset subfield of the FC field of the MPDU 610 is set to 1. For MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (the BSSID of the link if different from MLD-TA) if the sender is an AP MLD, or MLD-RA (the BSSID of the link if different from MLD-RA) if the sender is a non-AP MLD. If the per-link MAC addresses are the same, the retransmission rules can be the same as for single-link STAs (i.e., no need to change A1, A2, A3 addresses).

[0028] In the first transmission of a protected MPDU according to the first embodiment, the MLD MAC address is used instead of the MAC address of the sender / receiver attached STA (i.e., the A1, A2 fields of the transmitted MPDU) to generate the AAD and nonce during CCMP encapsulation of the protected MPDU destined for the peer MLD. Figure 7A shows an illustration of an AAD 700 according to the first embodiment. Similar to the AAD 502, the A1 field 702 and A2 field 704 of the AAD 700 are set to the MAC address of the receiver MLD and the MAC address of the sender MLD (i.e., MLD-RA and MLD-TA), respectively, instead of the MAC address of the receiver / sender attached STA indicated in the A1, A2, A3 fields of the transmitted protected MPDU. For MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which is typically the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (BSSID of that link if different from MLD-TA) if the sender is an AP MLD, or MLD-RA (BSSID of that link if different from MLD-RA) if the sender is a non-AP MLD. Figure 7B shows an illustration of a nonce 706 according to the first embodiment. Similar to nonce 504, the A2 field 708 of nonce 706 is set to the MAC address of the sending MLD (i.e., MLD-TA) instead of the MAC address of the sending attached STA indicated in the A2 field of the transmitted protected MPDU. The protected MPDU can be stored in the memory of the sending MLD until an acknowledgement of successful reception of the MPDU is received from the recipient MLD or until the lifetime of the MSDU expires.

[0029] In case of failure of transmission of the protected MPDU according to the first embodiment, the protected MPDU is retrieved from memory (if it was saved during the first transmission), the Retry subfield of the FC field is set to 1, the A1, A2 fields of the MAC header are swapped, a new CRC is added, and then retransmitted. This is advantageous because there is no need to perform the CCMP encapsulation again, since the AAD and nonce remain the same regardless of the per-link MAC address used on the link. In fact, fields of the MAC header whose content may change during retransmission (e.g. Duration / ID field, HT control field) are not included in the AAD and therefore do not affect the encapsulation process. For the same reason, some subfields of the Frame Control field are masked to 0. i) The Subtype subfield (bits 4, 5, and 6) of the data frame is masked to zero. ii) The Retry subfield (bit 11) is masked to 0. iii) The Power Management subfield (bit 12) is masked to zero. iv) The More Data subfield (bit 13) is masked to 0 v) The Protected Frame subfield (bit 14) is always set to 1. vi) The +HTC subfield (bit 15) is: - The QoS Control field is masked to 0 in all data frames that contain it. - Otherwise it is not masked.

[0030] If the protected MPDU was not stored in memory during initial transmission, retrieve the original unprotected MPDU from memory (e.g., from the transmit buffer) and re-encapsulate it, but using the MAC address of the MLD in the A1, A2, A3 fields (and A3 field, if applicable) of the AAD and in the A2 field of the nonce.

[0031] During CCMP decapsulation, the AAD and nonce are generated using the MLD MAC address instead of the MAC address of the sender / receiver attached STA (i.e., the A1, A2 fields of the received MPDU), regardless of the link used to receive the protected MPDU (from the peer MLD). Figure 8 shows a diagram 800 of the CCMP decapsulation process used by the receiving MLD to form a cleartext MPDU according to the first embodiment. To decapsulate the protected or encrypted MPDU, an AAD 802 and nonce 810 are constructed. According to the first embodiment, the A1 field 804 and A2 field 806 of the AAD 802 are set to the MAC address of the receiving MLD (i.e., MLD-RA) and the MAC address of the sending MLD (i.e., MLD-TA), respectively. For MPDUs with A3 set to BSSID (e.g. data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which 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, or 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 of the nonce 810 is set to the MAC address of the sending MLD (i.e., MLD-TA). To verify the identity of the sending STA, the A2 field of the received MPDU is checked (i.e., the A2 field of the received MPDU should indicate the MAC address of the sending STA belonging to the other MLD). The A1 field of the received MPDU has already been checked during the received frame filtering.

[0032] For retransmission of protected MPDUs in the first embodiment, it is assumed that the MLD MAC addresses are known to both the sending and receiving MLDs (e.g., exchanged during the association / link activation procedure). It is further assumed that the same PTK is used on all links. If different PTKs are used on different links, the MPDU needs to be re-encapsulated before retransmission on the different links. If the per-link MAC addresses are the same and a single PTK is used on all links, the retransmission rules are the same as for single-link STAs.

[0033] As a variation, instead of using MLD-TA and MLD-RA, the AP may provide non-AP STAs (e.g., during the 4-way group key handshake or using some management frame exchange) with the MAC address to use for the A1, A2 (and A3, if applicable) fields when constructing the AAD and nonce. This may also be useful for single-link STAs that use dynamic MAC addresses (e.g., MAC randomization) whose addresses change between the initial transmission and the retransmission. The provided MAC address is used to construct the AAD and nonce instead of the various address fields in the protected MPDU. If the A1 and A2 (and A3, if applicable) fields used for the AAD and nonce are always fixed, CCMP decapsulation will succeed even if the MAC addresses (either or both A1, A2 (and A3, if applicable)) of the retransmitted frame change.

[0034] FIG. 9 shows a flow chart 900 of the first transmission of an MPDU according to the first embodiment. In step 902, the MPDU is prepared for the first transmission. In step 904, it is determined whether the MPDU needs to be protected. If it is determined that the MPDU does not need to be protected, the process proceeds to step 918, where the MPDU is sent to the next process (e.g., channel access) for transmission to the receiving MLD, and the process ends in step 920. If it is determined in step 904 that the MPDU needs to be protected, the process proceeds to step 906, where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD. In step 908, the A2 field of the AAD and the constructed nonce is set to the MAC address of the own MLD, i.e., the sending MLD. Although not shown, for MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which 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, or 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 of AAD and nonce 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 sent for further processing for transmission to the recipient MLD, and the process ends in step 916.

[0035] FIG. 10 shows a flow chart 1000 for retransmission of an MPDU according to the first embodiment. In step 1002, it is determined that an MPDU needs to be retransmitted after an initial transmission failure (e.g., upon receipt of a BlockAck frame indicating an initial transmission failure). In step 1004, the stored MPDU is retrieved from memory. In step 1006, a Retry subfield of the FC field of the MPDU is set to 1. In step 1008, it is determined whether the MPDU is a protected or unprotected MPDU. If it is an unprotected MPDU, the process proceeds to step 1018 to determine 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. If, instead, it is determined that the MPDU should be retransmitted on a different link, the process proceeds to step 1020 to determine whether the TA or RA is different on the new link used for retransmission. If it is determined that the TA or RA of the new link is the same as that of the link of the initial transmission, processing continues with step 1016. If not, processing 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 processing then continues with step 1016.

[0036] If it is determined in step 1008 that the MPDU is protected, the process proceeds to step 1010 to determine whether to retransmit the protected MPDU on the same link as the initial transmission. If it is determined that the same link is used for the retransmission, the process continues with step 1016. Otherwise, the process proceeds to step 1012 to determine whether the TA or RA is different on the new link used for the retransmission. If it is determined that the TA or RA is not different on the new link compared to the link used for the initial transmission, the process continues with step 1016. Otherwise, the process proceeds to step 1014 to set the A1 and / or A2 fields to the new RA and / or TA of the new link, and then the process continues with step 1016. Further, from step 1016 onwards, the MPDU is sent to the next process for retransmission, and the process ends with step 1028. It should be noted that the process for retransmission of protected and unprotected MPDUs (i.e., regardless of the outcome of step 1008) is exactly the same. Although not shown, in an MPDU where A3 is set to the BSSID (e.g., a data frame with To DS / From DS=0, or a management frame), if the BSSID of link 2 is different, A3 is set to the BSSID of link 2 (which is typically the same as the MAC address of the AP MLD for that link).

[0037] FIG. 11 shows a flow chart 1100 of receiving an MPDU according to the first embodiment. In step 1102, an MPDU is received. In step 1104, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1124, where the MPDU is sent to the next process for receiving, and then the process ends in step 1126. If it is determined in step 1104 that the MPDU is protected, the process proceeds to step 1106, where it is determined whether the A2 field of the received MPDU indicates a MAC address that identifies a peer MLD. In the case of a non-AP MLD, the peer MLD refers to the AP MLD with which the MLD is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD with which the MLD is associated. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, using conventional procedures for decapsulation, processing proceeds to step 1120, where the A2 field of the constructed AAD and nonce is set to the A2 field of the MPDU, processing proceeds to step 1122, where the A1 field of the constructed AAD is set to the A1 field of the MPDU (and A3, if applicable), and processing continues with step 1112. If in step 1106 it is determined that the A2 field is set to a MAC address identifying the peer MLD, processing proceeds to step 1108, where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD, processing proceeds to step 1110, where the A2 field of the constructed AAD and nonce is set to the MAC address of the sending MLD, and processing continues with step 1112. Although not shown, in an MPDU where A3 is set to the BSSID (e.g. a data frame with To DS / 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, and which 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 the link if different from MLD-TA) if the sender is an AP MLD, or to MLD-RA (or the BSSID of the link if different from MLD-RA) if the sender is a non-AP MLD.In step 1112, the remaining fields of the AAD and nonce are set as normal. In step 1114, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and nonce. In step 1116, the decrypted MPDU is sent for further processing for reception, and the process ends in step 1118. An advantageous effect of the above process is that it is possible to retransmit the encrypted MPDU on a different link without re-performing CCMP encapsulation, and the receiving MLD can still correctly decapsulate the MDPU.

[0038] According to the second embodiment, during the CCMP encapsulation of the protected MPDU in the first transmission, the AAD and nonce can be generated using the MLD MAC address, or the A1, A2 fields of the transmitted protected MPDU, or the per-link MAC address of any attached STA, and the same protected MPDU can be retransmitted on a different link (after setting the Retry subfield in the FC and modifying some other fields mentioned above) without CCMP encapsulation again. This is possible by modifying some fields of the MAC header of the protected MPDU, e.g., the CCMP header, to signal the address used to generate the AAD and nonce during CCMP encapsulation. The transmitting MLD can choose different addresses to generate the AAD and nonce during CCMP encapsulation based on the deployment scenario, e.g., it can use the MLD MAC address as described in the first embodiment when the same PTK is used on all links. Alternatively, the AAD and nonce can be generated using the per-link MAC of the link used for the original transmission of the MPDU, 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 sender MLD can signal to use the address field of the MPDU's MAC header to generate the AAD and nonce. However, if a different PTK is used on a different link, the MPDU needs to be encapsulated again on the retransmission on the different link using the PTK of that link. In this case, the CCMP encapsulation can follow the conventional method, 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 sender MLD can signal in the CCMP header that the address field of the MAC header of the (retransmitted) MPDU should be used to generate the AAD and nonce fields.Thus, signaling the MAC address in the CCMP header allows the receiving MLD to correctly decapsulate the received protected MPDU (either on initial transmission or retransmission) regardless of the method used by the sending MLD to encapsulate the MPDU. Figure 12 shows an illustration of a protected MPDU 1200 according to a second embodiment. In this embodiment, the CCMP header 1202 of the MPDU 1200 includes a new Options field 1204 that includes a reserved (Rsvd) subfield and an Address subfield 1206. The Address subfield 1206 indicates to the receiving MLD what values ​​to adopt for the A1, A2, A3 fields of the AAD and the A2 field of the nonce when decapsulating the protected MPDU 1200. Referring to table 1208, if the value of the Address subfield 1206 is set to 0, the AAD and nonce A1, A2, A3 fields are set to the A1, A2, A3 fields of the MAC header 1210, respectively. If the value of the Address subfield 1206 is set to 1, the AAD and nonce A1, A2, A3 fields are set to the MAC addresses of the receiving MLD and the sending MLD, respectively. If the value of the Address subfield 1206 is set to 2 to n, the AAD and nonce A1, A2, A3 fields are set to the per-link MAC addresses of the attached STAs associated with link 1 to link (n-1). Furthermore, the A1, A2, A3 fields of the MAC header 1210 are set to the MAC addresses of the sending links (i.e., TA1 / TA2, RA1 / RA2) as usual, and A3 is set to the BSSID of the links.

[0039] During CCMP decapsulation, the receiving MLD uses the Address subfield 1206 to determine the MAC address for generating the AAD and nonce. In this case, it is assumed that the per-link MAC addresses of all valid links are known to both the sending and receiving MLD (e.g. exchanged during the association / link activation procedure). According to the second embodiment, upon retransmission of a failed MPDU (after setting the Retry subfield of FC to 1, swapping the A1, A2, A3 fields of the MAC header (and A3 if the BSSIDs of the links are different) and adding a new CRC), no CCMP encapsulation is performed, which is advantageous.

[0040] The premise of the second embodiment is that the same PTK is used on all links. Although other fields in the MAC header 1210 may be used to indicate address information, it is natural to choose the CCMP header 1202 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 transmitted in the clear. Furthermore, link 1 to link (n-1) in table 1208 represent the first link to the (n-1)th link set up between the two MLDs, which do not necessarily have to be the same value as the link ID assigned to the link, but can be the same value. For example, link 1 represents link ID 2, link 2 represents link ID 4, and so on. However, if different PTKs are used on different links, then upon retransmission on the different links, the MPDU needs to be encapsulated again using the PTK of that link. In this case, the CCMP encapsulation can follow the conventional method, where the address field of the MAC header of the (retransmitted) MPDU is used to generate the AAD and nonce fields. However, even in this case, the sending MLD can still signal in the CCMP header that the address fields of the MAC header of the (retransmitted) MPDU should be used to generate the AAD and nonce fields, allowing the receiving MLD to correctly decapsulate the received protected MPDU.

[0041] FIG. 13 shows a flow chart 1300 of receiving an MPDU according to the second embodiment. In step 1302, an MPDU is received. In step 1304, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1324, where the MPDU is sent to the next process for receiving, and then the process ends in step 1326. If it is determined in step 1304 that the MPDU is protected, the process proceeds to step 1306, where it is determined whether the A2 field of the received MPDU indicates a MAC address that identifies a peer MLD. In the case of a non-AP MLD, the peer MLD refers to the AP MLD with which it is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD with which it is associated. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, using a conventional decapsulation scheme, processing proceeds to step 1320, where the A2 field of the constructed AAD and nonce is set to the A2 field of the MPDU, processing proceeds to step 1322, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and processing then continues with step 1312. If it is determined in step 1306 that the A2 field is set to a MAC address identifying the peer MLD, processing proceeds to step 1308, where the A2 field of the constructed AAD and nonce is set to the MAC address according to the Address subfield of the MPDU's CCMP header, processing proceeds to step 1310, where the A1 field of the constructed AAD is set to the MAC address according to the Address field of the MPDU's CCMP header, and processing then continues with step 1312.

[0042] In step 1312, the remaining fields of AAD and nonce are set as usual. Although not shown, for MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which 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, or MLD-RA (or the BSSID of that link if different from MLD-RA) if the sender is a non-AP MLD. In step 1314, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and nonce. In step 1316, the decoded MPDU is sent to further processing for reception, and the process ends in step 1318. In this second embodiment, the receiver MLD always checks the CCMP header of the MPDU to determine the settings of the A1, A2, A3 fields of the AAD to be constructed and the A2 field of the nonce, regardless of whether it is an initial transmission or a retransmission, which advantageously gives the sender MLD more flexibility in determining the address values ​​in the CCMP encapsulation.

[0043] According to the third embodiment, during CCMP encapsulation (in the first transmission of a protected MPDU), the AAD and nonce are generated using the A1, A2, A3 fields of the transmitted MPDU, i.e., the same as in the case of a conventional single-link STA. However, during retransmission of a failed protected MPDU (after setting the Retry subfield of FC to 1, swapping the A1, A2 (and A3, if applicable) fields of the MAC header, and adding a new CRC), the CCMP header indicates which A1, A2, A3 fields the receiver MLD should use to generate the AAD and nonce upon decapsulation. During retransmission, no CCMP encapsulation is performed.

[0044] 14 shows an illustration of a protected MPDU 1400 according to the third embodiment. In this embodiment, the CCMP header 1402 of the MPDU 1400 includes a new Options field 1404 including a spare (Rsvd) subfield and an Address subfield 1406. During CCMP decapsulation, if the Retry subfield of the FC field of 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 for generating the AAD and nonce. By referring to the table 1408, if the value of the Address subfield 1406 is set to 0, the A1, A2, A3 fields of the AAD and the A2 field of the nonce are set to the respective address fields of the MAC header field 1410. For example, if the A1 field of the MPDU 1400 indicates RA1 (or RA2), then the A1 field of the constructed AAD is set to RA1 (or RA2), and if the A2 field of the MPDU 1400 indicates TA1 (or TA2), then the A2 field of the AAD and nonce is set to TA1 (or TA2), and the A3 field is set to the A3 field of the MPDU. A value of 0 in the Address subfield 1406 also indicates that the retransmission of the MPDU 1400 is on the same link as the initial transmission (or that the per-link MAC address on a different link is the same as on the link used for the initial transmission), and the receiving MLD can decapsulate the protected MPDU using conventional methods. If the Address subfield 1406 is set to a value of 1 through n, then the A1, A2 fields of the AAD and the A2 field of the nonce are set to the per-link MAC addresses of the attached STAs associated with link 1 through link (n), and the A3 field of the AAD is set to the per-link MAC address of the attached STA in the AP MLD for that link. The Address subfield 1406 values ​​of 1 through n also indicate that the retransmission is on a different link than the initial transmission.On the other hand, if the value of the Retry subfield is 0 (i.e., indicating that the received MPDU is an initial transmission), the AAD and nonce are generated using the A1, A2, and A3 fields of the MAC header field 1410 (conventional operation).

[0045] The premise of this embodiment is that the same PTK is used on all links, and the CCMP header of the MPDU is transmitted in the clear (i.e. unencrypted), so that changing its value on retransmission advantageously does not require re-encapsulation. However, if different PTKs are used on different links, the MPDU needs to be encapsulated again on retransmission on the different link using the PTK of that link. In this case, the CCMP encapsulation can follow the conventional method, 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 sending MLD can still signal in the CCMP header that the address field of the MAC header of the (retransmitted) MPDU should be used to generate the AAD and nonce fields, allowing the receiving MLD to correctly decapsulate the received protected MPDU.

[0046] FIG. 15 shows a flow chart 1500 of receiving an MPDU according to the third embodiment. In step 1502, an MPDU is received. In step 1504, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1526, where the MPDU is sent to the next process for receiving, and then the process ends in step 1528. If it is determined in step 1504 that the MPDU is protected, the process proceeds to step 1506, where it is determined whether the A2 field of the received MPDU indicates a MAC address identifying a peer MLD. In the case of a non-AP MLD, the peer MLD refers to the AP MLD with which it is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD with which it is associated. If it is determined in step 1506 that the A2 field is set to a MAC address identifying a peer MLD, the process proceeds to step 1508, where it is determined whether the Retry subfield of the FC field of the MPDU is set to 1. If it is determined that the Retry subfield is set to 1, processing proceeds to step 1510, where the A2 field of the AAD and nonce to be constructed is set to the MAC address according to the Address subfield of the CCMP header of the MPDU (i.e. according to table 1408 of FIG. 14), processing proceeds to step 1512, where the A1 field of the AAD to be constructed is set to the MAC address according to the Address subfield of the CCMP header of the MPDU (i.e. according to table 1408 of FIG. 14), and then processing continues with step 1514. If in step 1506 it is determined that the A2 field of the received MPDU does not indicate the MAC address of the remote MLD, or if in step 1508 it is determined that the Retry subfield of the FC field of the MPDU is not 1, processing proceeds to step 1522, where the A2 fields of the constructed AAD and nonce are set to the A2 field of the MPDU, processing proceeds to step 1524, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then processing continues from step 1514.In step 1514, the remaining fields of AAD and nonce are set as usual. Although not shown, in MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which 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, or to MLD-RA (or the BSSID of that link if different from MLD-RA) if the sender is a non-AP MLD. In step 1516, CCMP decapsulation is performed on the MPDU with the constructed AAD and nonce. In step 1518, the decoded MPDU is sent to further processing for reception, and the process ends in step 1520. An advantageous effect of the above process is that the changes required to implement this embodiment can be minimized, since CCMP encapsulation and decapsulation differ from the conventional method only in the case of retransmission. Furthermore, the receiving MLD can determine whether a received MPDU is a retransmitted MPDU by checking the CCMP header of the MPDU, i.e., based on the value of the Address subfield of the CCMP header (in addition to the Retry subfield of the FC).

[0047] According to the fourth embodiment, data frames and management frames transmitted by or to the MLD may have a different MAC header format that carries information specific to multilink transmissions (i.e., information such as the MAC addresses of the sending and receiving MLDs). FIG. 16A shows an illustration of a protected MPDU 1600 with a modified MAC header 1602 according to the fourth embodiment. In the fourth embodiment, a Protocol Version (PV) field 1604 may 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. Additionally, the MAC header 1602 includes an ML Control field 1606 that may be used to carry control information related to the multilink transmission. The ML Control field 1606 includes a Control ID subfield 1608 that, when set to a particular value, the remainder of the ML Control field carries an ML Address 1 subfield 1610 and an ML Address 2 subfield 1612.

[0048] The Control ID subfield 1608 indicates the options of the ML Control field 1606. For example, if the value of the Control ID subfield 1608 is 1, the ML Control field 1606 conveys the MAC addresses of the receiving / sending MLD. These MAC addresses are indicated in the ML Address 1 subfield 1610 and the ML Address 2 subfield 1612. For example, the ML Address 1 subfield 1610 is set to the MAC address of the sender MLD, and the ML Address 2 subfield 1612 is set to the MAC address of the receiving MLD. In this case, the MLD address conveyed in the multilink frame is used in the construction of the AAD and nonce during CCMP encapsulation / decapsulation. For example, the A1 field of the constructed AAD is set to the MLD address of the receiving MLD indicated in the ML Address 1 subfield 1610, and the A2 field of the constructed AAD and nonce is set to the MLD address of the sending MLD indicated in the ML Address 2 subfield 1612, and the A3 field, if applicable, is set to the MLD address of the AP MLD as described above. Even if either or both of the 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 nonce can still use the full MAC address corresponding to the MLD ID (i.e., obtained from the (AP MLD) association record or from a record of MLD MAC address-MLD ID mapping stored, for example, during the multilink association procedure).

[0049] FIG. 17 shows a flow chart 1700 of receiving an MPDU according to the fourth embodiment. In step 1702, an MPDU is received. In step 1704, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1724, where the MPDU is sent to a next process for receiving, and then the process ends in step 1726. If it is determined in step 1704 that the MPDU is protected, the process proceeds to step 1706, where it is determined whether the MPDU uses a 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 it is determined that the PV field does not have a value of 2, the process proceeds to step 1720, where the A2 field of the constructed AAD and nonce is set to the A2 field of the MPDU, and the process proceeds to step 1722, where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then the process continues from step 1712. If, in step 1706, it is determined that the PV field has the value 2, processing 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 of the ML Control field of the received MPDU, processing proceeds to step 1710, where the A2 field of the constructed AAD and nonce is set to the MLD MAC address corresponding to the ML Address 2 subfield of the ML Control field of the received MPDU, and processing then continues with step 1712. In step 1712, the remaining fields of the AAD and nonce are set normally.Although not shown, for MPDUs where A3 is set to BSSID (e.g., data frames with To DS / From DS=0, or management frames), if the BSSID of link 2 is different, A3 (set to BSSID in such frames, which 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, or 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 with the constructed AAD and nonce. In step 1716, the decoded MPDU is sent to further processing for reception, and the process ends in step 1718. An advantageous effect of the above process is that the changes required to implement this embodiment can be minimized, since CCMP encapsulation / decapsulation is still performed based on MPDU fields.

[0050] The techniques described in the first to third embodiments can also work for Galois / Counter Mode Protocol (GCMP), which is currently used by DMG (Directional multi-gigabit) and EDMG (Enhanced DMG) 802.11 STAs, but may also be used by sub-7GHz 802.11 STAs in the future. FIG. 18A shows a diagram 1800 of the GCMP encapsulation process to form an encrypted MPDU according to the fifth embodiment. CCMP is based on a "chained" mode of operation that requires in-order processing of 16-byte chunks, since the chained cipher mode requires the output of one stage to be used as the input to the next stage. GCMP, on the other hand, uses the same AES cipher engine, but incorporates it into a more efficient framework. Compared to CCMP, GCMP requires half the number of cipher processes, and more importantly, since it is not chained, GCMP cipher acceleration can be applied in parallel to the entire transmitted frame. As can be seen in the diagram 1800, the GCMP encapsulation process is nearly identical to CCMP encapsulation. However, while the constructed AAD 1802 used in GCMP encapsulation is the same as the AAD constructed in CCMP encapsulation, the constructed nonce 1804 used in GCMP encapsulation differs from the nonce used in CCMP encapsulation in that it does not include a priority field.

[0051] FIG. 18B shows an illustration of a GCMP protected MPDU 1806 according to the fifth embodiment. Having been encrypted by GCMP, the MPDU 1806 includes a GCMP header 1808 instead of a CCMP header. The GCMP header 1808 includes an Options field, which conveys an Address field 1809 used to signal which address fields should be used to construct the AAD and nonce fields during GCMP decapsulation. FIG. 18C shows an illustration of a GCMP decapsulation process to form a plaintext MPDU according to the fifth embodiment. As with GCMP encapsulation, GCMP decapsulation is similar to CCMP decapsulation. However, while the constructed AAD 1812 used in GCMP decapsulation is the same as the constructed AAD in CCMP decapsulation, the constructed nonce 1814 used in GCMP decapsulation differs from the nonce used in CCMP decapsulation in that it does not include a Priority field. The receiving MLD can refer to the Address field 1809 to determine which address fields to use to construct the AAD and nonce fields during GCMP decapsulation.

[0052] FIG. 19 illustrates a diagram 1900 of a multilink MPDU transmission using a common packet number (PN) assignment on all links, according to various embodiments. Similar to the multilink MPDU transmission using separate PTKs as illustrated in diagram 300 of FIG. 3, a common PN assignment is used on both link 1 and link 2 for transmitting the MPDU. In this example, the transmission of MPDU 1902 on link 1 fails and is scheduled for retransmission on a different link, such as link 2, rather than 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 (since a common PN assignment is used on both link 1 and link 2). The receiver MLD sorts the MPDUs received on link 2 according to the SN of each received MPDU, including MPDU 1904. When the reordering is completed up to SN=4, i.e., the received MPDU 1904 with SN=4 and PN=104, the receiver MLD updates the replay counter to PN=104. Unlike the diagram 300 in Fig. 3, where the remaining MPDUs with SN greater than 4 (i.e., the received MPDU 306 with SN=5 and PN=52 and the received MPDU 308 with SN=7 and PN=53) are dropped and the replay denial problem occurs, the MPDUs 1906 and 1908 pass the replay check because the PNs are in the correct order after the reordering process. In this way, by using a common PN space to assign the PNs of the keys regardless of the number of PTKs and using the same PNs for retransmissions, the replay denial problem described above is solved.

[0053] 20 shows a schematic diagram of a sender MLD 2000 according to various embodiments. The sender MLD includes a MAC-SAP 2002 for performing a delivery service (DS), a transmit buffer 2004 (used to store unprotected and optionally protected MPDUs), a sequence number (SN) allocation module 2006, a packet number (PN) allocation module 2008, an MPDU encryption and integrity module 2010, and a retransmission module 2012 (determines the link to be used for retransmission and the MAC addresses to be used to construct the AAD and nonce during the cryptographic encapsulation process). The sender MLD 2000 further includes two attached STAs or stations, STA1 2014a and STA2 2014b. STA1 2014a includes an MPDU header and CRC creation module 2020a, a transmit (Tx) buffer and block acknowledgement (ACK) control module 2022a, and an aggregation control module 2024a in the MAC layer 2016a. Similarly, STA2 2014b includes an MPDU header and CRC creation module 2020b, a transmit (Tx) buffer and block acknowledgement (ACK) control module 2022b, and an aggregation control module 2024b in the MAC layer 2016b. Both STAs include a PHY layer with transmission over link 1 (for STA1 2014a) and link 2 (for STA2 2014b). It will be understood that the number of links and attached STAs or stations can be further expanded. The above architecture is appropriate when the same PTK (and / or GTK / IGTK) is used on all links, because even if different PTKs are used for the links, if the same PN space is used on all links, it may help to avoid the replay denial problem as explained in the context of Figure 19. However, in deployments that choose to use different PTKs (and / or GTK / IGTK), the MPDU encryption and integrity module 2010 may be moved to each attached STA.If separate PN spaces are used for the links (where the PN is typically tied to a respective secret key), then the packet number (PN) assignment module 2008 may also be moved to each attached STA.

[0054] FIG. 21 shows a schematic diagram of a receiver MLD 2100 according to various embodiments. The receiver MLD includes a MAC-SAP 2102 for performing a distribution service (DS), a replay detection module 2104, an MPDU decoding and integrity module 2106, a block ACK buffering and reordering module 2108, and a duplicate detection module 2110. The receiver MLD 2100 further includes two attached STAs or stations, STA1 2114a and STA2 2114b. STA1 2114a includes a block ACK scoreboard module 2120a, an address 1 filtering module 2122a, and a deaggregation control unit 2124a at the MAC layer 2116a. Similarly, STA2 2114b includes a block ACK scoreboard module 2120b, an address 1 filtering module 2122b, and a deaggregation control unit 2124b at the MAC layer 2116b. Both STAs have PHY layers (i.e., 2118a for STA1 2114a and 2118b for STA2 2114b) from which transmission takes place over link 1 (i.e., between STA1 2114a and STA1 2014a in the sender MLD 2000) and link 2 (i.e., between STA2 2114b and STA2 2014b in the sender MLD 2000). It will be appreciated that the number of links and attached STAs or stations can be further extended. Here, the MPDU decoding and integrity module 2106 is responsible for parsing the address fields in the CCMP / GCMP header during CCMP / GCMP decapsulation to determine which address fields are used to construct the AAD and nonce fields.

[0055] FIG. 22 shows a flow chart 2200 illustrating a method for multi-link secure retransmission of an MPDU according to various embodiments. In step 2202, a first MLD configured to operate with a first plurality of attached STAs sets up a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of attached STAs, where two or more links are established between STAs of the first plurality of attached STAs and corresponding STAs of the second plurality of attached STAs. In step 2204, construct additional authentication data (AAD) and a nonce, where the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, where the nonce includes the address 2 (A2) field, and the SC field of the AAD is based on the SC field of the MPDU. In step 2206, cryptographically encapsulate the MPDU using the AAD and the nonce to form an encapsulated MPDU. If applicable, the address fields in the CCMP / GCMP headers are set to signal the address fields used to generate the AAD and nonce fields. In step 2208, the encapsulated MPDU is transmitted from the first MLD on the first link to the second MLD as an initial transmission. In step 2210, upon failure of the initial transmission, the encapsulated MPDU is retransmitted on the second link without re-performing cryptographic encapsulation. If applicable, the address fields in the CCMP / GCMP headers of the retransmitted MPDU are set to signal the address fields used to generate the AAD and nonce fields during the encapsulation process.

[0056] 23 shows a schematic partial cross-sectional view of a multi-link device 2300 that can be implemented for secure retransmission of multi-link according to the first to fifth embodiments. The multi-link device 2300 can be implemented as an AP MLD or a non-AP MLD and includes one or more attached STAs or STAs according to various embodiments.

[0057] The various functions and operations of the multilink device 2300 are arranged in layers according to a hierarchical model, in which lower layers report to and receive instructions from higher layers, in accordance with the IEEE specification, and for the sake of brevity, the details of the hierarchical model will not be described in this disclosure.

[0058] As shown in Fig. 23, the multilink device 2300 may include a circuit 2314, at least one wireless transmitter 2302, at least one wireless receiver 2304, and multiple antennas 2312 (only one antenna is depicted in Fig. 23 for purposes of illustration for simplicity). The circuit may include at least one controller 2306, which is used when performing the tasks it is designed to perform with the aid of software and hardware, including controlling communications with one or more other multilink 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 one or more other multilink devices through the at least one wireless transmitter 2302, and at least one receive signal processor 2310 for processing MPDUs received from one or more other multilink devices through the at least one wireless receiver 2304. Further, the at least one controller 2306 can control at least one transmit signal generator 2308 and / or at least one receive signal processor 2310 to construct AAD and nonce frames and to perform CCMP or GCMP encapsulation or decapsulation on MPDUs using the constructed AAD and nonce frames. The at least one transmit signal generator 2308 and at least one receive signal processor 2310 can be standalone modules of the multi-link device 2300 that communicate with the at least one controller 2306 for the above-mentioned functions. Alternatively, the at least one transmit signal generator 2308 and at least one receive signal processor 2310 may be included in the at least one controller 2306. It will be understood by those skilled in the art that the arrangement of these functional modules is flexible and may vary according to practical needs and / or requirements. The data processing devices, storage devices, and other related control devices can be provided on a suitable circuit board and / or chipset.

[0059] In various embodiments, in operation, the at least one wireless transmitter 2302, the at least one wireless receiver 2304, and the at least one antenna 2312 may be controlled by at least one controller 2306. Additionally, while only one wireless transmitter 2302 is shown, it will be understood that there may be multiple such transmitters (i.e., one transmitter for each attached STA or per STA of the multilink device 2300).

[0060] In various embodiments, in operation, the at least one wireless receiver 2304 together with the at least one receive signal processor 2310 form a receiver for the multilink device 2300. In operation, the receiver for the multilink device 2300 provides the functionality necessary for multilink communications. Although only one wireless receiver 2304 is shown, it will be understood that there may be multiple such receivers (i.e., one receiver for each attached STA or per STA of the multilink device 2300).

[0061] In operation, the multi-link device 2300 provides functions necessary for secure retransmission of the multi-link. For example, the multi-link device 2300 can be a first multi-link device configured to operate with a first plurality of attached STAs. In operation, the circuit 2314 can set up a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of attached STAs, where two or more links are established between a STA of the first plurality of attached STAs and a corresponding STA of the second plurality of attached STAs, and the circuit constructs additional authentication data (AAD) and a nonce used for cryptographic encapsulation of a MAC protocol data unit (MPDU) to form an encapsulated MPDU, where the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, where the nonce includes the address 2 (A2) field, and the SC field of the AAD is based on the SC field of the MPDU. In operation, the transmitter 2302 can transmit an encapsulated MPDU to a second MLD on a first link as an initial transmission and, upon failure of the initial transmission, retransmit the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0062] The AAD and the A2 field of the nonce may be set to a Medium Access Control (MAC) address identifying the first MLD, and the A1 field of the AAD may be set to a MAC address identifying the second MLD. Either CCMP or GCMP may be used to cryptographically protect the MPDU. The MPDU may include identities of the first MLD and the second MLD, and the A2 field of the AAD and the nonce may be set to a MAC address identifying the first MLD indicated in the identities, and the A1 field of the AAD may be set to a MAC address identifying the second MLD indicated in the identities.

[0063] The circuit 2314 can specify a setting of the A1, A2, A3 fields in the MPDU, which indicates whether the A1, A2, A3 fields should be set to a MAC address identifying the second MLD, a MAC address identifying the first MLD, or a MAC address identifying the AP MLD, respectively, upon cryptographic decapsulation of the MPDU, or whether the A1, A2, A3 fields should be set to a MAC address of an attached STA of the second MLD, a MAC address of an attached STA of the first MLD, or a MAC address identifying the AP MLD, respectively, or whether the A1, A2, A3 fields should be set to the A1, A2, A3 fields of the MPDU, respectively, where the AP MLD is the first MLD or the second MLD. The setting of the A1, A2, A3 fields can be indicated in one of a CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) header field or a GCMP (Galois / Counter Mode Protocol) header field of the encapsulated MPDU.

[0064] The A2 field of the AAD and nonce may be set to the A2 field of the MPDU, and the A1 field of the AAD may be set to the A1 field of the MPDU, and when the initial transmission fails, the circuit 2314 may further specify a setting of the A1, A2, A3 fields in the retransmitted MPDU, which setting indicates whether, upon cryptographic decapsulation of the retransmitted MPDU, the A1, A2, A3 fields should be set to the MAC address of the attached STA of the second MLD, the MAC address of the attached STA of the first MLD, a MAC address identifying the AP MLD, respectively, or whether the A1, A2, A3 fields should be set to the A1, A2, A3 fields of the retransmitted MPDU, respectively.

[0065] For example, the multi-link device 2300 can be a first multi-link device configured to operate with a first plurality of attached STAs. The circuitry 2314, in operation, can set up a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of attached STAs, where two or more links are established between a STA of the first plurality of attached STAs and a corresponding STA of the second plurality of attached STAs. In operation, the receiver 2304 may receive a cryptographically encapsulated MAC protocol data unit (MPDU) from a second MLD, where the circuit 2314 constructs additional authentication data (AAD) and a nonce used for cryptographic decapsulation of the received MPDU, where 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 nonce includes an address 2 (A2) field, the A2 field of the AAD and the nonce may be set to either the A2 field of the MPDU, a medium access control (MAC) address identifying the second MLD, or a MAC address of one of the second plurality of attached STAs, the A1 field of the AAD may be set to either the A1 field of the MPDU, a MAC address identifying the first MLD, or a MAC address of one of the first plurality of attached STAs, and the Address 3 (A3) field of the AAD may be set to either the BSSID field of the link, the A3 field of the MPDU, or a MAC address of the AP. It can be set to the MAC address in the MLD and the SC field in the AAD is based on the SC field in the MPDU.

[0066] The circuitry 2314 can cryptographically decapsulate an MPDU received from a second MLD, where the A2 field of the AAD and nonce can be set to a MAC address identifying the second MLD and the A1 field of the AAD can be set to a MAC address identifying the first MLD. Either CCMP or GCMP can be used to cryptographically decapsulate the MPDU. The MPDU can carry identities of the first MLD and the second MLD, and the circuitry can cryptographically decapsulate the MPDU by setting the A2 field of the AAD and nonce to a MAC address identifying the second MLD indicated in the MPDU and setting the A1 field of the AAD to a MAC address identifying the first MLD indicated in the MPDU.

[0067] The circuit 2314 can cryptographically decapsulate the received MPDU based on a setting of the A1, A2, A3 fields indicated in the MPDU, the setting indicating whether the A1, A2, A3 fields should be set to a MAC address identifying the first MLD, a MAC address identifying the second MLD, or a MAC address identifying the AP MLD, respectively, upon cryptographic decapsulation, or whether the A1, A2, A3 fields should be set to a MAC address of an attached STA of the first MLD, a MAC address of an attached STA of the second MLD, or a MAC address identifying the AP MLD, respectively, or whether the A1, A2, A3 fields should be set to the A1, A2, A3 fields of the MPDU, respectively, where the AP MLD is the first MLD or the second MLD. The setting of the address fields can be indicated in one of the CCMP header or the GCMP header of the MPDU received from the second MLD.

[0068] The circuit 2314 can cryptographically decapsulate a first MPDU received from the second MLD by setting the A2 field of the AAD and the nonce 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 can cryptographically decapsulate a second MPDU received from the second MLD based on a setting of the A1, A2, A3 fields indicated in the second MPDU, the setting indicating whether the A1, A2, A3 fields should be set to the MAC address of the attached STA of the first MLD, the MAC address of the attached STA of the second MLD, the MAC address identifying the AP MLD, respectively, upon cryptographic decapsulation, or whether the A1, A2, A3 fields should be set to the A1, A2, A3 fields of the second MPDU, respectively, and the second MPDU including a Retry subfield set to 1.

[0069] The present disclosure can be realized by software, hardware, or software cooperating with hardware. Each functional block used in the description of each embodiment above can be realized in part or in whole by an LSI such as an integrated circuit, and each process described in each embodiment can be controlled in part or in whole by the same LSI or a combination of LSIs. The LSI may be formed as an individual chip, or a single chip may be formed to include some or all of the functional blocks. The LSI may include a data input / output unit coupled to it. The LSI referred to here may be called an IC, a system LSI, a super LSI, or an ultra LSI depending on the degree of integration. However, the technology for implementing the integrated circuit is not limited to the LSI, and may be realized using a dedicated circuit, a general-purpose processor, or a special-purpose processor. Furthermore, a field programmable gate array (FPGA) that can be programmed after the manufacture of the LSI, or a reconfigurable processor that can change the connection and settings of the circuit cells arranged inside the LSI may be used. The present disclosure can be realized as digital processing or analog processing. If future integrated circuit technology replaces LSI due to advances in semiconductor technology and other derived technologies, it may be possible to integrate functional blocks using that future integrated circuit technology. Biotechnology can also be applied.

[0070] The present disclosure may be implemented by any type of apparatus, device, or system having communication capabilities, referred to as a communications device.

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

[0072] Some non-limiting examples of such communications devices include phones (e.g., cellular 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), gaming consoles, e-book readers, telemedicine equipment, vehicles providing communications capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

[0073] The communications devices are not limited to being portable or mobile, but may also include any type of apparatus, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "things" in the Internet of Things (IoT) network.

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

[0075] The communications device may include devices such as controllers and sensors coupled to the communications apparatus to perform the communications functions described in this disclosure. For example, the communications device may include a controller or sensor that generates control or data signals used by the communications apparatus to perform the communications functions of the communications device.

[0076] The communications device may further include infrastructure facilities, such as base stations, access points, and any other apparatus, devices, or systems that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

[0077] As a non-limiting example of an architecture (e.g., the architectures shown in Figures 20 and 21), the MLD of the present disclosure may be logically realized by multiple separated communication devices sharing a common MAC data service interface to upper layers.

[0078] A non-limiting example of a station may be a station included in a first plurality of stations belonging to a multi-link station logical entity (i.e., MLD, etc.), where as part of the first plurality of stations belonging to the multi-link station logical entity, the stations of the first plurality of stations share a common Medium Access Control (MAC) data service interface to higher layers, where the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0079] It can therefore be seen that embodiments of the present disclosure provide communication devices and methods operating on multiple links to fully realize the throughput gains of multi-link communication, particularly in multi-link secure retransmission.

[0080] In the above detailed description of the present embodiment, an exemplary embodiment has been presented, but it should be understood that a vast number of variations exist. Furthermore, it should be understood that the exemplary embodiment is an example, and is not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the above detailed description provides those skilled in the art with a convenient guide for implementing the exemplary embodiment. It should be understood that various changes can be made in the function and organization of the steps and methods of operation described in the exemplary embodiment, and in the modules and structures of the devices described in the exemplary embodiment, without departing from the scope of the subject matter described in the appended claims.

Claims

1. A transmitting multi-link device (MLD), a circuit for constructing an additional authentication data (AAD) and a nonce, and encapsulating a plaintext MAC protocol data unit (MPDU) with the AAD and the nonce to form an encapsulated MPDU, the AAD including an address 1 (A1) field set to a MAC address of a receiving multi-link device (MLD) and an address 2 (A2) field set to a MAC address of the sending MLD, and the nonce including an A2 field set to the MAC address of the sending MLD; a transmitter for transmitting the encapsulated MPDU to the receiving MLD via a first link; The sending MLD comprises:

2. If the transmission of the encapsulated MPDU fails, the transmitter retransmits the MPDU on another link without encapsulating the MPDU with a new packet number (PN). The sending MLD according to claim 1 .

3. A common packet number (PN) is used for the initial transmission on the first link and the retransmission on the other link. The sending MLD according to claim 1 .

4. The receiving MLD has a first plurality of affiliated STAs (Station) that can establish one or more links with a second plurality of affiliated STAs associated with the receiving MLD. The sending MLD according to claim 1 .

5. the settings of the A1 and A2 fields are indicated in one of a CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) header field or a GCMP (Galois / Counter Mode Protocol) header field of the encapsulated MPDU; The second sending MLD according to claim 3.

6. A common packet number (PN) is used in the transmission and retransmission for multiple links; The sending MLD according to claim 1 .

7. To cryptographically protect the MPDU, one of CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) or GCMP (Galois / Counter Mode Protocol) is used; The sending MLD according to claim 1 .

8. the circuit uses one packet number (PN) space for multiple links; The sending MLD according to claim 1 .

9. A communication method for a transmitting multi-link device (MLD), comprising: constructing additional authentication data (AAD) and a nonce, and encapsulating a plaintext MAC protocol data unit (MPDU) with the AAD and the nonce to form an encapsulated MPDU, the AAD including an Address 1 (A1) field set to a MAC address of a receiving multilink device (MLD) and an Address 2 (A2) field set to a MAC address of the sending MLD, the nonce including an A2 field set to the MAC address of the sending MLD; transmitting the encapsulated MPDU to the receiving MLD over a first link; Communication methods.

10. if the transmission of the encapsulated MPDU fails, retransmitting the MPDU on another link without encapsulating the MPDU with a new packet number (PN); The communication method according to claim 9.

11. A common packet number (PN) is used for the initial transmission on the first link and the retransmission on the other link. The communication method according to claim 9.

12. The sending MLD has a first plurality of affiliated STAs (Station) that can establish one or more links with a second plurality of affiliated STAs associated with the receiving MLD. The communication method according to claim 9.

13. the settings of the A1 and A2 fields are indicated in one of a CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) header field or a GCMP (Galois / Counter Mode Protocol) header field of the encapsulated MPDU; The communication method according to claim 11.

14. A common packet number (PN) is used in the transmission and retransmission for multiple links; The communication method according to claim 9.

15. To cryptographically protect the MPDU, one of CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) or GCMP (Galois / Counter Mode Protocol) is used; The communication method according to claim 9.

16. Use of one packet number (PN) space for multiple links; The communication method according to claim 9.

17. 1. An integrated circuit for a transmitting multi-link device (MLD), comprising: constructing an additional authentication data (AAD) and a nonce, and encapsulating a plaintext MAC protocol data unit (MPDU) with the AAD and the nonce to form an encapsulated MPDU, the AAD including an Address 1 (A1) field set to a MAC address of a receiving multi-link device (MLD) and an Address 2 (A2) field set to a MAC address of the sending MLD, and the nonce including an A2 field set to a MAC address of the sending MLD; transmitting the encapsulated MPDU to the receiving MLD over a first link; An integrated circuit that controls

Images