Patent Description:
In today's world, communication devices are expected to wirelessly operate with the same capabilities as wired computing devices. For example, a user expects to be able to seamlessly watch a high definition movie streamed to the user's wireless communication device. This presents challenges for communication devices as well as the access points to which the communication devices wirelessly connect.

The Institute of Electrical and Electronics Engineers (IEEE) <NUM> group has recently formed the Extreme High Throughput (EHT) study group to address these challenges. Multi-link operation in the <NUM>, <NUM> and <NUM> frequency bands has been identified as a key candidate technology for such communication. Multi-channel aggregation over multiple links is a natural way to create multi-fold increase in communication data throughput.

Further, security protocols including but not limited to Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or Galois/counter mode protocol (GCMP) are used in such IEEE <NUM> devices to provide data confidentiality, authentication, integrity, and replay protection for data frames, individually addressed robust management frames and group addressed management frames. Patent Application <CIT> relates to wireless communication and in particular, to multi-link data transmission of MAC packet data units MPDUs, and discusses establishing multi-link sessions, transmission of data units between MLDs, and how to generate AADs and Nonce for cryptographic encapsulation of data units and their configuration. A wireless device establishes multiple links to affiliated STAs having lower Tx MAC addresses. Before transmission of the MPDU over the same or different links, the MPDUs are encrypted by applying codes. In case of failure of an initial transmission of the MPDUs over a first link, the MPDUs are retransmitted over the same or different links.

The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to illustrate various embodiments and to explain various principles and advantages in accordance with present embodiments.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been depicted to scale.

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, there is no intention to be bound by any theory presented in the preceding Background or this Detailed Description. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

Referring to <FIG>, an illustration depicts the steps in processing a MPDU using CCMP in accordance with various embodiments. At Step <NUM>, a MAC Header is added to Data such as a MAC Service Data Unit (MSDU) or Management MPDU (MMDPU) to form a MPDU. At Step <NUM>, the MAC Header is separated from the MPDU and a CCMP Header is created. At Step <NUM>, Message Integrity Code (MIC) is computed and appended at the end. The MIC is used for authentication and integrity check. At Step <NUM>, the combination of the Data and the MIC is encrypted to form a Ciphertext. The CCMP Header is then prepended to the Ciphertext. At Step <NUM>, the MAC Header is restored by prepending it to the CCMP Header. At Step <NUM>, Cyclic Redundancy Check (CRC) is computed over the entire MPDU and appended at the end of the MPDU to form a protected or encrypted MPDU.

<FIG> depicts an illustration of a protected MPDU <NUM> in accordance with various embodiments. The protected MPDU <NUM> comprises a MAC Header field <NUM>, a CCMP Header field, a Data (PDU) field, a MIC field and a FCS field. As explained in <FIG>, the data (payload) field and MIC field are encrypted. The CCMP Header field comprises a PN0 field, PN1 field, Rsvd field, Key ID octet field, PN2 field, PN3 field, PN4 field and a PN0 field. The Key ID octet field comprises a Reserved (Rsvd) subfield, Ext IV subfield and a Key ID subfield.

The MAC Header field <NUM> is depicted in detail in <FIG>, and comprises a Frame Control (FC) field, duration/ID field, Address <NUM> (A1) field, Address <NUM> (A2) field, Address <NUM> (A3) field, Sequence Control (SC) field, an optional Quality of Service (QoS) Control field, an optional Address <NUM> (A4) field and an optional High Throughput (HT) field. The FC field further comprises a Protocol Version subfield, Type subfield, To Distribution Service (DS) subfield, From DS subfield, More Fragments subfield, Retry subfield, Power Management subfield, More Data subfield, Protected Frame subfield and a +HTC subfield.

Typically, the contents of the A1, A2 and A3 Address fields of data frames depend on the"To DS"and "From DS"subfields of the FC field of the MAC Header. This is illustrated in Table <NUM> below:.

If the content of the "To DS" and "From DS" subfields are both "<NUM>", the content of the A1 field will be Receiver Address (RA) (= Destination Address (DA)), the content of the A2 field will be Transmitter Address (TA) (= Source Address (SA)), the content of the A3 field will be the basic service set identifier (BSSID) while Address <NUM> is not present. If the content of the "To DS" and "From DS" subfields are "<NUM>" and "<NUM>" respectively, the content of the A1 field will be the RA, the content of the A2 field will be Transmitter Address (TA) (=BSSID) , the content of the A3 field will be the SA while Address <NUM> is not present. If the content of the "To DS" and "From DS" subfields are "<NUM>" and "<NUM>" respectively, the content of the A1 field will be RA (= BSSID), the content of the A2 field will be the TA, the content of the A3 field will be the DA while Address <NUM> is not present. If the content of the "To DS" and "From DS" subfields are both "<NUM>", the content of the A1 field will be the RA, the content of the A2 field will be the TA, the content of the A3 field will be the DA while Address <NUM> is set to SA.

For management frames, the content of the A1, A2 and A3 Address fields are typically the same as that of data frames with "To DS"=<NUM> and "From DS"=<NUM>. That is, the content of the A1 field will be RA (=DA), and the content of the A2 field will be TA (=SA). A3 depends on the frame type but is set to BSSID for most cases. If the STA is transmitting the Management frame to an access point (AP) that is in a multiple BSSID set, the Address <NUM> field is the BSSID of the AP's BSS (which is either the transmitted BSSID or a nontransmitted BSSID), irrespective of whether the STA is associated with that AP.

Multi-link operations in next generation wireless LANs such as <NUM>. 11be may allow MPDUs of the same TID (Traffic ID) to be transmitted on different links at the same time. However, such multi-link transmissions may lead to some unexpected operations when security encapsulation is applied to the MPDUs as explained below. When MPDUs of the same TID (Traffic ID) are enabled to be transmitted on different links at the same time, in order to ensure that the recipient MLD is able to correctly reorder the MPDUs received over different links, the same Sequence Number (SN) space may be used to assign SNs to the MSDUs or MMPDUs carried in the MPDUs regardless of the link used for the actual transmission. During the initial setup of links between an AP MLD and a non-AP MLD (e.g. right after multi-link Association procedure), a single PMK (Pairwise Master Key) may be negotiated between an AP MLD and non-AP MLD to be used as the master key for secured transmissions between the two MLDs. PTK (Pairwise Temporal Key) and GTK/IGTK ((Integrity) Group Temporal Key) that are used for secure encapsulation/decapsulations of MPDUs may be derived from the same PMK for different links. It is possible that separate PTKs and separate GTK/IGTKs are generated for use in different links. <FIG> depicts an illustration <NUM> of a multi-link MPDU transmission using a separate PTK for each link. In this example, a transmitter MLD transmits MPDUs on a Link <NUM> and a Link <NUM> to a receiver MLD. Link <NUM> uses a PTK Key <NUM>, while Link <NUM> uses a different PTK Key <NUM>. The Packet Number (PN) counter used 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 <NUM> starts from PN=<NUM>, while the PN counter for MPDUs transmitted on Link <NUM> starts from PN=<NUM>.

In the present example, MPDU <NUM> on Link <NUM> fails to be transmitted, so it is scheduled to be retransmitted on a different link such as Link <NUM> instead of Link <NUM>. Since Link <NUM> uses a different PTK (i.e. Key <NUM>), the MPDU needs to be encapsulated with Key <NUM> and a new PN = <NUM> (since it is scheduled to be retransmitted after the transmission of MPDU <NUM> with PN=<NUM>) as MPDU <NUM>, even though it still shares the same SN=<NUM> as the MPDU <NUM>. At the receiving side, the receiver MLD then reorders the received MPDUs on Link <NUM> according to the SN of each received MPDU including MPDU <NUM>. When reordering up to SN=<NUM> i.e. up to received MPDU <NUM> with SN=<NUM> and PN=<NUM>, the receiver MLD updates a replay counter to PN=<NUM>. As a consequence, the rest of the MPDUs with SN greater than <NUM> and with PN less than <NUM> (i.e. received MPDU <NUM> with SN=<NUM>, PN=<NUM> and received MPDU <NUM> with SN=<NUM>, PN=<NUM>) are dropped, causing an unintended replay rejection issue.

Even if a single PTK is used for all links, if the retransmitted MPDU is encapsulated again with a new PN, the Replay rejection issue will still occur. This can be seen in <FIG> which depicts an illustration <NUM> of a multi-link MPDU transmission using a single PTK for all links in accordance with various embodiments. Similar to <FIG>, a transmitter MLD transmits MPDUs on a Link <NUM> and a Link <NUM> to a receiver MLD. The difference is that both Link <NUM> and Link <NUM> use the same PTK Key <NUM>. As a result, both links use a common SN assignment and a common PN assignment.

In the present example, MPDU <NUM> with SN=<NUM> and PN=<NUM> on Link <NUM> fails to be transmitted, so it is scheduled to be retransmitted on a different link such as Link <NUM> instead of Link <NUM>. Since Link <NUM> has a different A1, A2 fields compared to Link <NUM>, the MPDU needs to be encapsulated again as MPDU <NUM> and with a new PN = <NUM> (since it is scheduled to be retransmitted after the transmission of MPDU <NUM> with PN=<NUM>), even though it still shares the same SN=<NUM> as the MPDU <NUM>. The receiver MLD then reorders the received MPDUs on Link <NUM> according to the SN of each received MPDU including MPDU <NUM>. When reordering up to SN=<NUM> i.e. up to received MPDU <NUM> with SN=<NUM> and PN=<NUM>, the receiver MLD updates a replay counter to PN=<NUM>. As a consequence, the rest of the MPDUs with SN greater than <NUM> and with PN less than <NUM> (i.e. received MPDU <NUM> with SN=<NUM>, PN=<NUM> and received MPDU <NUM> with SN=<NUM>, PN=<NUM>) are dropped, causing a replay rejection issue.

Further, IEEE <NUM>. 11be may mandate separate MAC addresses to be used per link or it is also possible that different links are allowed to use the same MAC address. If separate MAC addresses are used for links the problem of a same Nonce value being reused to protect different data (a security flaw) when the TA for two transmit links are the same, but the RA for two receive links are different, and a frame is retransmitted on another link using the same A2 (i.e. =TA) and same PN (i.e. PN remains the same across retransmissions to avoid out-of-order PN received after SN re-ordering by a receiver MLD) may be averted. However, IEEE <NUM> specification makes the following statement regarding the usage of Nonce and PN:
"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 <NUM>-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees. "
This means that reuse of the same PN for retransmissions on a different link to avoid the replay rejection issue, although solves the issue, but may introduce a security flaw. The assumption for the above is that retransmitted MPDUs needs to be re-encapsulated when re-transmitted on a different link. The present disclosure provides several options to avoid such security related issues introduced by multi-link transmissions.

<FIG> depicts an illustration of a CCMP encapsulation process to form an encrypted MPDU as per the IEEE <NUM> specification. In particular, an Additional Authentication Data (AAD) <NUM> and a Nonce <NUM> are constructed and used for cryptographical encapsulation of the MPDU to form the encrypted or protected MPDU. The AAD <NUM> comprises a Frame Control (FC) field, an Address <NUM>(A1) field, Address <NUM> (A2) field, Address <NUM> (A3) field, Sequence Control (SC) field, an optional Address <NUM> (A4) field and an optional Quality Control (QC) field, while the Nonce <NUM> comprises a Nonce Flags field, an A2 field and a PN field. The contents of the A1, A2, A3 fields in the AAD <NUM> and the contents of the A2 field in the Nonce <NUM> are taken from the A1, A2, A3 fields of the MPDU that is to be encapsulated (or decapsulated, in the case of a decapsulation process of an encrypted MPDU).

In single link <NUM> STAs, protected MPDUs are retransmitted with minimal changes:.

Therefore, the present invention seeks to avoid CCMP encapsulation during re-transmissions of protected frames on a different link (even when the per-link MAC addresses are different).

<FIG> depicts an illustration of how an unprotected MPDU is retransmitted on a different link in accordance with a first embodiment. Transmitting MLD <NUM> is configured to operate with a first plurality of affiliated STAs such as STA <NUM> and STA <NUM>. A MAC address MLD-TA identifies the transmitting MLD <NUM> and may be used to represent the MLD for communication with the DS (Distribution Service), while the MAC addresses of STA <NUM> and STA <NUM> are TA1 and TA2 respectively. Similarly, receiving MLD <NUM> is configured to operate with a second plurality of affiliated STAs such as STA <NUM> and STA <NUM>. A MAC address MLD-RA identifies the receiving MLD <NUM>, while the MAC addresses of STA <NUM> and STA <NUM> are RA1 and RA2 respectively. For an MLD, the MLD MAC address may be the same as one of its per-link MAC addresses or 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 appreciated that two or more STAs may form the first and second plurality of affiliated STAs, and two or more links may be formed between STAs of the first plurality of affiliated STAs and corresponding STAs of the second plurality of STAs without necessarily requiring each STA to be connected by a link. For example, Link <NUM> may be setup between STA <NUM> and STA <NUM>, while Link <NUM> may be setup between STA <NUM> and STA <NUM>. The settings described above are also applicable for retransmission of protected or unprotected MPDUs that will be further discussed in various embodiments below. Further, it is assumed, particularly for retransmission of protected MPDUs, that a robust security network association (RSNA) has been set up between the transmitting MLD and the receiving MLD and all the necessary secret keys (e.g. PTK, GTK/IGTK etc.) have been generated/distributed.

As shown in illustration <NUM>, the transmitting MLD <NUM> transmits an unprotected MPDU <NUM> on a Link <NUM> to receiving MLD <NUM> i.e. from STA <NUM> to STA <NUM>. Therefore, the A1, A2, A3 fields of the MPDU <NUM> are set to the MAC addresses of receiving STA <NUM> (i.e. RA1) and transmitting STA <NUM> (i.e. TA1) respectively. As an initial transmission, the Retry subfield in the FC field of the MPDU <NUM> is set to <NUM>. In an event that the transmission fails, due to various reasons (e.g. temporary failure of Link <NUM>) the MPDU may be retransmitted as unprotected MPDU <NUM> on a Link <NUM> i.e. from STA <NUM> to STA <NUM>. Unprotected MPDUs may be retransmitted on another link by simply setting the Retry subfield in the Frame Control (FC) field of the MPDU to <NUM> and swapping A1, A2 and A3 in the MAC header. Therefore, the A1 field of the MPDU <NUM> is set to the MAC address of receiving STA <NUM> (i.e. RA2) and the A2 field is set to the MAC address of transmitting STA <NUM> (i.e. TA2). Further, the Reset subfield in the FC field of MPDU <NUM> is set to <NUM>. In MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if transmitter is non-AP MLD. If the per-link MAC addresses are the same, retransmission rules may be the same as single link STAs (i.e. even the A1, A2 and A3 addresses do not need to be changed).

For an initial transmission of a protected MPDU according to a first embodiment, during CCMP encapsulation of the protected MPDU addressed to a peer MLD, MLD MAC addresses are used to generate the AAD and Nonce instead of the MAC addresses of the transmitting/receiving affiliated STAs (i.e. A1, A2 fields of the MPDU to be transmitted). <FIG> depicts an illustration of an AAD <NUM> in accordance with the first embodiment. While similar to the AAD <NUM>, the A1 field <NUM> and A2 field <NUM> of AAD <NUM> are set to the MAC addresses of the receiving MLD and the transmitting MLD respectively (i.e. MLD-RA and MLD-TA) instead of the MAC addresses of the transmitting/receiving affiliated STAs which are indicated in the A1, A2, A3 fields of the protected MPDU to be transmitted. In MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if transmitter is non-AP MLD. <FIG> depicts an illustration of a Nonce <NUM> in accordance with the first embodiment. While similar to the Nonce <NUM>, the A2 field <NUM> of Nonce <NUM> is set to the MAC address of the transmitting MLD (i.e. MLD-TA) instead of the MAC address of the transmitting affiliated STA which is indicated in the A2 field of the protected MPDU to be transmitted. The Protected MPDU may be saved in memory of the transmitting MLD until successful acknowledgement of receiving the MPDU from the receiving MLD or upon expiry of MSDU lifetime.

Upon transmission failure of the protected MPDU according to the first embodiment, the protected MPDU is retrieved from memory (if saved during initial transmission) and retransmitted after setting Retry subfield of FC field to <NUM>, swapping A1, A2 fields of MAC Header and adding a new CRC. Advantageously, since the AAD and Nonce remain the same regardless of the Per-link MAC Addresses used in the links, there is no need to perform CCMP encapsulation again. Indeed, fields of the MAC Header whose contents may change during retransmissions (e.g. Duration/ID field, HT Control field) are not included in the AAD and hence do not affect the encapsulation process. For similar reasons, several sub-fields in the Frame Control field are masked to <NUM>:.

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) and encapsulated again but using the MAC Addresses of the MLDs for A1, A2, A3 fields (and A3 field if applicable) of AAD and A2 field of the Nonce.

Regardless of the link used for reception of protected MPDUs (from a peer MLD), during CCMP decapsulation, MLD MAC addresses are used to generate the AAD and Nonce instead of the MAC addresses of the transmitting/receiving affiliated STAs (i.e. A1, A2 fields of the received MPDU). <FIG> depicts an illustration <NUM> of a CCMP decapsulation process used by a receiving MLD to form a plaintext MPDU in accordance with the first embodiment. An AAD <NUM> and a Nonce <NUM> are constructed for decapsulation of the protected or encrypted MPDU. In accordance with the first embodiment, A1 field <NUM> and A2 field <NUM> in AAD <NUM> are set to the MAC address of the receiving MLD (i.e. MLD-RA) and MAC address of the transmitting MLD (i.e. MLD-TA) respectively. In MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. Further, A2 field <NUM> in the Nonce <NUM> 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 MLD MAC address to verify the identity of the transmitting STA (i.e. 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 would already have been checked during receive frame filtering.

For retransmission of protected MPDUs according to the first embodiment, it is assumed that the MLD MAC addresses are known to both transmitter and receiver MLD (e.g. exchanged during Association/link enablement procedure). Further, it is assumed that the same PTK is used for all the links. If different links use different PTK, MPDUs need to be encapsulated again prior to retransmission on a different link. If the per-link MAC addresses are the same and a single PTK is used for all links, retransmission rules are the same as single link STAs.

As a variation, instead of using MLD-TA and MLD-RA, AP may also provide the MAC addresses to use for the A1, A2 fields (and A3 field if applicable) during the construction of AAD and Nonce to non-AP STA e.g. during <NUM>-way, group key handshake or using some management frame exchange. This may also be useful for single link STAs that use dynamic MAC addresses (e.g. MAC randomization) wherein the addresses change between an initial transmission and a retransmission. The provided MAC addresses are then used to construct the AAD and Nonce instead of the various address fields of the protected MPDU. If the Aland A2 fields (and A3 field if applicable) used in AAD and Nonce are always fixed, even after change of MAC addresses in the retransmitted frames (either A1, A2 or both (and A3 if applicable)), CCMP decapsulation will still pass.

<FIG> depicts a flowchart <NUM> for an initial transmission of a MPDU in accordance with the first embodiment. At step <NUM>, an MPDU is prepared for initial transmission. At step <NUM>, 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 goes to step <NUM> where the MPDU is sent to a next process for transmission to a receiving MLD (e.g. for channel access), and the process ends at step <NUM>. If it is determined at step <NUM> that the MPDU needs to be protected, the process goes to step <NUM> where the A1 field of a constructed AAD is set to the MAC address of the receiving MLD. At step <NUM>, the A2 field of the AAD and a constructed Nonce are set to the MAC address of own MLD i.e. transmitting MLD. Although not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. At step <NUM>, the rest of the fields in the AAD and Nonce are set as usual i.e. in accordance with IEEE <NUM> standards. At step <NUM>, CCMP encapsulation of the MPDU is performed to generate a protected or encrypted MPDU. At step <NUM>, the protected MPDU is sent to a next process for transmission to the receiving MLD, and the process ends at step <NUM>.

<FIG> depicts a flowchart <NUM> for a retransmission of a MPDU in accordance with the first embodiment. At step <NUM>, it is determined that an MPDU needs retransmission i.e. after failure of an initial transmission (e.g. upon reception of a BlockAck frame indicating failure of the initial transmission). At step <NUM>, the saved MPDU is retrieved from memory. At step <NUM>, the Retry subfield in FC field of the MPDU is set to <NUM>. At step <NUM>, it is determined whether the MPDU is a protected or unprotected MPDU. If it is an unprotected MPDU, the process goes to step <NUM> 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 <NUM>. Otherwise, if it is determined that the MPDU should be retransmitted on a different link, the process goes to step <NUM> where it is determined whether the TA or RA is different in the new link that is to be used for retransmission. If it is determined that the TA or RA in the new link is the same as those for the initial transmission link, the process continues from step <NUM>. Otherwise, the process goes to step <NUM> where the A1 and/or A2 fields are set to the new RA and/or TA of the new link, and then the process continues from step <NUM>.

If it is determined at step <NUM> that the MPDU is protected, the process goes to step <NUM> where it is determined 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 retransmission, the process continues from step <NUM>. Otherwise, the process goes to step <NUM> where it is determined whether the TA or RA is different in the new link that is to be used for retransmission. If the TA or RA is determined to be different in the new link compared to the link used for the initial transmission, the process continues from step <NUM>. Otherwise, the process goes to step <NUM> where the A1 and/or A2 fields are set to the new RA and/or TA of the new link, and then the process continues from step <NUM>. Further, from step <NUM>, the MPDU is sent a next process for retransmission and the process ends at step <NUM>. Notably, processing for retransmissions of protected and unprotected MPDUs (i.e. regardless of outcome from step <NUM>) are exactly the same. Although not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 is set to the BSSID of Link2 (the BSSID typically being the same as the AP MLD's MAC address on that link).

<FIG> depicts a flowchart <NUM> for reception of a MPDU in accordance with the first embodiment. At step <NUM>, a MPDU is received. At step <NUM>, it is determined whether the MPDU is protected. If the MPDU is not protected, the process goes to step <NUM> where the MPDU is sent to a next process for reception and the process then ends at step <NUM>. If it is determined at step <NUM> that the MPDU is protected, the process goes to step <NUM> where it is determined if the A2 field of the received MPDU indicates the MAC address that identifies a peer MLD. For a non-AP MLD, peer MLD refers to an AP MLD with which it is associated. For an AP MLD, peer MLD refers to a non-AP MLD that is associated with it. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, the convention procedure for decapsulation is used and the process goes to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the A2 field of the MPDU, proceeds to step <NUM> where the A1 field of the constructed AAD is set to the A1 field of the MPDU (and A3 as well if applicable), and then continues from step <NUM>. If it is determined at step <NUM> that the A2 field is set to the MAC address that identifies a peer MLD, the process goes to step <NUM> where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD, proceeds to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the MAC address of the transmitting MLD, and then continues from step <NUM>. Although not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. At step <NUM>, the rest of the fields in the AAD and Nonce are set as usual. At step <NUM>, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and Nonce. At step <NUM>, the decrypted MPDU is sent to a next process for reception and the process ends at step <NUM>. An advantageous effect of the above process is that cross-link re-transmissions of encrypted MPDUs are possible without re-performing CCMP encapsulations and the receiving MLD can still correctly decapsulate the MDPUs.

According to a second embodiment, it is possible to use either MLD MAC addresses or A1, A2 fields of a protected MPDU to be transmitted, or the Per-link MAC addresses of any of the affiliated STAs to generate the AAD and Nonce during CCMP encapsulation of a Protected MPDU during an initial transmission, and the same Protected MPDU is re-transmitted (after setting the Retry subfield in the FC and changing some other fields as explained earlier) on a different link without going through the CCMP encapsulation again. This is made possible by modifying some field in the MAC Header of a Protected MPDU, for example the CCMP Header to signal the addresses used to generate the AAD and Nonce during CCMP encapsulation. A transmitting MLD may choose different addresses to generate the AAD and Nonce during CCMP encapsulation based on deployment scenarios, for example if the same PTK if used for all the links, the MLD MAC addresses may be used as explained in the first embodiment. Alternatively, the Per-link MAC of the link used for the original transmission of an MPDU may be used for the generation of AAD and Nonce, and if the MPDU is later retransmitted in a different link, the signal in the CCMP Header can instruct the receiving MLD to use the Per-link MAC addresses 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 may signal that the Address fields of the MAC Header of the MPDU are to be used to generate the AAD and the Nonce. However, if different links use different PTKs, during retransmissions in a different link, the MPDU will need to be encapsulated again using the PTK for that link. In this case, the CCMP encapsulation may follow the conventional method of using the Address fields of the MAC Header of the (re-transmitted) MPDU to generate the AAD and the Nonce fields. However, even in this case the transmitting MLD can still signal in the CCMP Header that the Address fields of the MAC Header of the (re-transmitted) MPDU are to be used to generate the AAD and the Nonce fields. Thus, the signaling of the MAC Addresses in the CCMP Header enables the receiving MLD to correctly decapsulate a received Protected MPDU (either during an initial transmission or retransmissions) regardless of the different methods used by the transmitting MLD to encapsulate the MPDU. <FIG> depicts an illustration of a protected MPDU <NUM> in accordance with the second embodiment. The CCMP Header <NUM> of the MPDU <NUM> now includes a new Options field <NUM> that comprises a Rsvd subfield and an Address subfield <NUM>. The Address subfield <NUM> indicates to the receiver MLD what values to adopt for the A1, A2, A3 fields in the AAD and the A2 fields in the Nonce during the decapsulation of the protected MPDU <NUM>. Referring to table <NUM>, if the value of the Address subfield <NUM> is set to <NUM>, the A1, A2, A3 fields in the AAD and Nonce are to be set to the A1, A2, A3 fields of the MAC Header <NUM> respectively. If the value of the Address subfield <NUM> is set to <NUM>, the A1, A2, A3 fields in the AAD and Nonce are to be set to the MAC addresses of the receiving MLD and the transmitting MLD respectively. If the value of the Address subfield <NUM> is set from <NUM> up to n, the A1, A2, A3 fields in the AAD and Nonce are to be set to the per-link MAC addresses of the affiliated STAs associated with link <NUM> to link (n-<NUM>). Further, the A1, A2, A3 fields in the MAC Header <NUM> are set to MAC addresses of the transmitted link (i.e. TA1/TA2, RA1/RA2) and A3 set to the BSSID of the link as per normal.

During CCMP decapsulation, the receiving MLD uses the Address subfield <NUM> to decide the MAC addresses for generating the AAD and Nonce. It is assumed that the per-link MAC addresses of all enabled links are known to both transmitter and receiver MLD (e.g. exchanged during Association/link enablement procedure). Advantageously, during retransmission of failed MPDUs according to the second embodiment (after setting Retry subfield of FC to <NUM>, swapping A1, A2, A3 fields (and A3 as well if the BSSID of the link is different) of MAC Header and adding a new CRC), CCMP encapsulation is not performed.

An assumption for the second embodiment is that the same PTK is used for all the links. Other fields in the MAC Header <NUM> may also be used to indicate Address information, but CCMP Header <NUM> would be a natural choice since the field is used to indicate security related information and also because the CCMP Header <NUM> is not included in the encapsulation process and is transmitted in the plain text. Further, link <NUM> to link (n-<NUM>) in the table <NUM> represents the first link to the (n-<NUM>)th link that has been setup between the two MLDs and need not necessarily be the same as the Link IDs assigned to the links, although it is possible that they are the same value. For example, link <NUM> may represent Link ID <NUM>, link <NUM> may represent Link ID <NUM>, etc. However, if different links use different PTKs, during retransmissions in a different link, the MPDU will need to be encapsulated again using the PTK for that link. In this case, the CCMP encapsulation may follow the conventional method of using the Address fields of the MAC Header of the (re-transmitted) MPDU to generate the AAD and the Nonce fields. However, even in this case the transmitting MLD can still signal in the CCMP Header that the Address fields of the MAC Header of the (re-transmitted) MPDU are to be used to generate the AAD and the Nonce fields, enabling the receiving MLD to correctly decapsulate a received Protected MPDU.

<FIG> depicts a flowchart <NUM> for reception of a MPDU in accordance with the second embodiment. At step <NUM>, a MPDU is received. At step <NUM>, it is determined whether the MPDU is protected. If the MPDU is not protected, the process goes to step <NUM> where the MPDU is sent to a next process for reception and the process then ends at step <NUM>. If it is determined at step <NUM> that the MPDU is protected, the process goes to step <NUM> where it is determined if the A2 field of the received MPDU indicates the MAC address that identifies a peer MLD. For a non-AP MLD, peer MLD refers to an AP MLD with which it is associated. For an AP MLD, peer MLD refers to a non-AP MLD that is associated with it. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, the conventional decapsulation method is used and the process goes to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the A2 field of the MPDU, proceeds to step <NUM> where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step <NUM>. If it is determined at step <NUM> that the A2 field is set to the MAC address that identifies a peer MLD, the process goes to step <NUM> where the A2 field of the constructed AAD and Nonce is set to the MAC address according to the Address subfield in the CCMP Header of the MPDU, proceeds to step <NUM> where the A1 field of the constructed AAD is set to the MAC address according to the Address field in the CCMP header of the MPDU, and then continues from step <NUM>.

At step <NUM>, the rest of the fields in the AAD and Nonce are set as usual. Although, not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. At step <NUM>, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and Nonce. At step <NUM>, the decrypted MPDU is sent to a next process for reception and the process ends at step <NUM>. In the second embodiment, the receiver MLD always checks the CCMP Header of the MPDU to decide the A1, A2, A3 field settings of the constructed AAD and the A2 field of the Nonce, regardless of initial transmission or retransmission. Advantageously, there is more flexibility to the transmitting MLD in deciding Address values for CCMP encapsulation.

According to a third embodiment, during CCMP encapsulation (during initial transmission of a protected MPDU), the A1, A2, A3 fields of the MPDU to be transmitted are used to generate the AAD and Nonce i.e. same as legacy single link STAs. However, during retransmission of failed protected MPDUs (after setting Retry subfield of FC to <NUM>, swapping A1, A2 fields (and A3 if applicable) of MAC Header and adding a new CRC), the CCMP Header indicates which A1, A2, A3 fields are to be used by the receiver MLD to generate the AAD and Nonce for decapsulation. CCMP encapsulation is not performed during retransmissions.

<FIG> depicts an illustration of a protected MPDU <NUM> in accordance with the third embodiment. The CCMP Header <NUM> of the MPDU <NUM> now includes a new Options field <NUM> that comprises a Rsvd subfield and an Address subfield <NUM>. During CCMP decapsulation, if the Retry subfield of the FC field in MAC Header field <NUM> has a value of <NUM> (i.e. indicating that the received MPDU is a retransmission), the receiving MLD uses the Address field <NUM> to decide the MAC addresses to generate the AAD and Nonce. Referring to table <NUM>, if the value of the Address subfield <NUM> is set to <NUM>, the A1, A2, A3 fields in the AAD and the A2 field in the Nonce are to be set to the respective address fields of the MAC Header <NUM>. For example, the A1 field of the constructed AAD will be set to RA1 (or RA2) if the A1 field of the MPDU <NUM> indicates RA1 (or RA2), and the A2 field of the AAD and Nonce is set to TA1 (or TA2) if the A2 field of the MPDU <NUM> indicates TA1 (or TA2) and the A3 field is set to the A3 field of the MPDU. A value of <NUM> in the Address subfield <NUM> also indicates that retransmission of the MPDU <NUM> is on the same link as the initial transmission (or the Per-link MAC addresses in a different link is the same as those 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 the Address subfield <NUM> is set to <NUM> up to n, the A1 and A2 fields in the AAD and the A2 field in the Nonce are to be set to the per-link MAC addresses of the affiliated STAs associated with link <NUM> to link (n), while A3 field in AAD is set to the Per-link MAC address of the affiliated STA of the AP MLD for that link. A value of <NUM> up to n in the Address subfield <NUM> also indicates that the retransmission is on a link that is different from the initial transmission. On the other hand, if the Retry subfield has a value of <NUM> (i.e. indicating that the received MPDU is an initial transmission), the A1, A2, A3 fields of MAC Header <NUM> are used to generate the AAD and Nonce (conventional behavior).

Assumptions for this embodiment are that the same PTK is used for all the links, and that the CCMP Header of the MPDU is transmitted in the clear (i.e. unencrypted), so changing its value during retransmissions advantageously does not require re-encapsulation. However, if different links use different PTKs, during retransmissions in a different link, the MPDU will need to be encapsulated again using the PTK for that link. In this case, the CCMP encapsulation may follow the conventional method of using the Address fields of the MAC Header of the (re-transmitted) MPDU to generate the AAD and the Nonce fields. However, even in this case the transmitting MLD can still signal in the CCMP Header that the Address fields of the MAC Header of the (re-transmitted) MPDU are to be used to generate the AAD and the Nonce fields, enabling the receiving MLD to correctly decapsulate a received Protected MPDU.

<FIG> depicts a flowchart <NUM> for reception of a MPDU in accordance with the third embodiment. At step <NUM>, a MPDU is received. At step <NUM>, it is determined whether the MPDU is protected. If the MPDU is not protected, the process goes to step <NUM> where the MPDU is sent to a next process for reception and the process then ends at step <NUM>. If it is determined at step <NUM> that the MPDU is protected, the process goes to step <NUM> where it is determined if the A2 field of the received MPDU indicates the MAC address that identifies a peer MLD. For a non-AP MLD, peer MLD refers to an AP MLD with which it is associated. For an AP MLD, peer MLD refers to a non-AP MLD that is associated with it. If it is determined at step <NUM> that the A2 field is set to the MAC address that identifies a peer MLD, the process goes to step <NUM> where it is determined if the Retry subfield in the FC field of the MPDU is set to <NUM>. If it is determined that the Retry subfield is set to <NUM>, the process goes to step <NUM> where the A2 fields of the constructed AAD and Nonce are set to a MAC address according to the Address subfield of the CCMP Header of the MPDU (i.e. in accordance with the table <NUM> of <FIG>), proceeds to step <NUM> where the A1 field of the constructed AAD is set to a MAC address according to the Address subfield of the CCMP Header of the MPDU (i.e. in accordance with the table <NUM> of <FIG>), and then continues from step <NUM>. If it is determined at step <NUM> that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, or if it is determined at step <NUM> that the Retry subfield in the FC field of the MPDU is not <NUM>, the process goes to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the A2 field of the MPDU, proceeds to step <NUM> where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step <NUM>. At step <NUM>, the rest of the fields in the AAD and Nonce are set as usual. Although, not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. At step <NUM>, CCMP decapsulation is performed on the MPDU with the constructed AAD and Nonce. At step <NUM>, the decrypted MPDU is sent to a next process for reception and the process ends at step <NUM>. An advantageous effect of the above process is that CCMP encapsulation and decapsulation differs from legacy only for retransmissions, thus minimizing the modifications required for implementing the present embodiment. Further, the receiving MLD can also check the CCMP Header of the received MPDU to determine if it is a retransmitted MPDU i.e. based on the value of the Address subfield in the CCMP Header (in addition to the Retry subfield in the FC).

According to a fourth embodiment, it is also possible that data and management frames transmitted by or transmitted to MLDs may have a different MAC header format that carry information specific to Multi-link transmissions i.e. information such as MAC addresses of transmitting and receiving MLDs. 16A depicts an illustration of a protected MPDU <NUM> having a modified MAC Header <NUM> in accordance with a fourth embodiment. In the fourth embodiment, the Protocol Version (PV) field <NUM> may be used to differentiate multi-link frames from legacy and PV1 (<NUM>. 11ah) frames. For example, if the PV field <NUM> is set to value of <NUM>, it indicates that the MPDU <NUM> is a multi-link frame. Alternatively, one or more new frame types may be defined in <NUM>. 11be to indicate the new MAC Header format. Further, the MAC Header <NUM> includes a ML Control field <NUM> that may be used to carry control information related to Multi-link transmissions. The ML Control field <NUM> comprises a Control ID subfield <NUM> which, when set to a certain value, the rest of the ML Control field carries a ML Address <NUM> subfield <NUM> and a ML Address <NUM> subfield <NUM>.

The Control ID subfield <NUM> indicates options for ML Control field <NUM>. For example, when the Control ID subfield <NUM> has a value of <NUM>, the ML Control field <NUM> carries the MAC Addresses of receiving/transmitting MLDs. These MAC addresses are indicated in the ML Address <NUM> subfield <NUM> and ML Address <NUM> subfield <NUM>. For example, the ML Address <NUM> subfield <NUM> is set to the MAC Address of the transmitter MLD and the ML Address <NUM> subfield <NUM> is set to the MAC Address of the receiving MLD. AAD and Nonce construction during CCMP encapsulation/decapsulation will then use the MLD addresses carried in the Multi-link frames. For example, the A1 field of the constructed AAD will be set to the MLD Address of the receiving MLD as indicated in the ML Address <NUM> subfield <NUM>, while the A2 fields of the constructed AAD and Nonce are set to the MLD Address of the transmitting MLD as indicated in the ML Address <NUM> subfield <NUM>. If applicable, the A3 field may also be set to the MLD Address of the AP MLD as explained earlier. Even if either or both ML Addresses in the ML Control field <NUM> use a short ID format (i.e. <NUM>-bits MLD ID) instead of full MAC address (<NUM>-bits), AAD and Nonce can still use the full MAC addresses corresponding to the MLD IDs (i.e. retrieved from Association record (for AP MLD) or from a record of the MLD MAC Address to MLD ID mapping, for example saved during the multi-link association procedure).

<FIG> depicts a flowchart <NUM> for reception of a MPDU in accordance with the first embodiment. At step <NUM>, a MPDU is received. At step <NUM>, it is determined whether the MPDU is protected. If the MPDU is not protected, the process goes to step <NUM> where the MPDU is sent to a next process for reception and the process then ends at step <NUM>. If it is determined at step <NUM> that the MPDU is protected, the process goes to step <NUM> where it is determined if the MPDU uses a new frame format, for example by checking if the PV field in the MAC Header of the received MPDU has a value of <NUM>. If it is determined that the PV field does not have a value of <NUM>, the process goes to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the A2 field of the MPDU, proceeds to step <NUM> where the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then continues from step <NUM>. If it is determined at step <NUM> that the PV field has a value of <NUM>, the process goes to step <NUM> where the A1 field of the constructed AAD is set to the MLD MAC address corresponding to the ML Address <NUM> subfield in the ML Control field of the received MPDU, proceeds to step <NUM> where the A2 field of the constructed AAD and Nonce are set to the MLD MAC address corresponding to the ML Address <NUM> subfield in the ML Control field of the received MPDU, and then continues from step <NUM>. At step <NUM>, the rest of the fields in the AAD and Nonce are set as usual. Although, not shown in the figure, in MPDUs in which A3 is set to BSSID (e.g. Data frames with To/From DS = <NUM>; or management frames), if the BSSID of Link <NUM> is different, A3 (which is set to the BSSID in such frames; the BSSID typically being the same as the AP MLD's MAC address on that link) is also changed to MLD-TA (or the BSSID for that link if it is different from MLD-TA) if the transmitter is AP MLD and MLD-RA (or the BSSID for that link if it is different from MLD-RA) if the transmitter is non-AP MLD. At step <NUM>, CCMP decapsulation is performed on the MPDU with the constructed AAD and Nonce. At step <NUM>, the decrypted MPDU is sent to a next process for reception and the process ends at step <NUM>. An advantageous effect of the above process is that CCMP encapsulation/decapsulation is still based on the MPDU fields, thus minimizing the modifications required for implementing the present embodiment.

The techniques that are described in the first to third embodiments can also work for Galois/counter mode protocol (GCMP), which is currently used by Directional multi-gigabit (DMG) and Enhanced DMG (EDMG) <NUM> STAs but may also be used by sub <NUM> <NUM> STAs in the future. <FIG> depicts an illustration <NUM> of a GCMP encapsulation process to form an encrypted MPDU in accordance with a fifth embodiment. CCMP is based on a "chained" mode of operation that requires in-order processing of the <NUM>-byte chunks because chained cryptographic modes require the output of one stage to be used as the input to the next. GCMP, on the other hand, uses the same AES cryptographic engine, but embeds it into a more efficient framework. Compared with CCMP, GCMP requires only half the number of encryption operations, and, more importantly, is not chained so that GCMP cryptographic acceleration can be applied to an entire transmitted frame in parallel. As can be seen in illustration <NUM>, GCMP encapsulation process is almost the same as CCMP encapsulation. However, while constructed AAD <NUM> for use in GCMP encapsulation is the same as a constructed AAD for CCMP encapsulation, constructed Nonce <NUM> for use in GCMP encapsulation differs from a Nonce used in CCMP encapsulation in that Nonce <NUM> does not include a Priority field.

<FIG> depicts an illustration of a GCMP protected MPDU <NUM> in accordance with the fifth embodiment. Having been encrypted by GCMP, the MPDU <NUM> includes a GCMP Header <NUM> instead of a CCMP Header. The GCMP Header <NUM> includes an Options field, which in turn carries an Address field <NUM> that is used to signal the Address fields to be used for the construction of the AAD and the Nonce fields during the GCMP decapsulation. <FIG> depicts an illustration of a GCMP decapsulation process to form a plaintext MPDU in accordance with the fifth embodiment. Similar to GCMP encapsulation, GCMP decapsulation process is almost the same as CCMP decapsulation. However, while constructed AAD <NUM> for use in GCMP decapsulation is the same as a constructed AAD for CCMP decapsulation, constructed Nonce <NUM> for use in GCMP decapsulation differs from a Nonce used in CCMP decapsulation in that Nonce <NUM> does not include a Priority field. The receiving MLD can refer to the Address field <NUM> to determine the Address fields to be used for the construction of the AAD and the Nonce fields during the GCMP decapsulation.

<FIG> depicts an illustration <NUM> of a multi-link MPDU transmission using a common Packet Number (PN) assignment for all links in accordance with various embodiments. While similar to the multi-link MPDU transmission using separate PTKs as shown in illustration <NUM> in <FIG>, a common PN assignment is used in both Link <NUM> and Link <NUM> for transmitting MPDUs. In the present example, MPDU <NUM> on Link <NUM> fails to be transmitted, so it is scheduled to be retransmitted on a different link such as Link <NUM> instead of Link <NUM>. Since Link <NUM> uses a different PTK (i.e. Key <NUM>), the MPDU needs to be encapsulated with Key <NUM> as MPDU <NUM> but still using the same SN=<NUM> and the same PN = <NUM> (since a common PN assignment is used for both Link <NUM> and Link <NUM>) as the MPDU <NUM>. The receiver MLD then reorders the received MPDUs on Link <NUM> according to the SN of each received MPDU including MPDU <NUM>. When reordering up to SN=<NUM> i.e. up to received MPDU <NUM> with SN=<NUM> and PN=<NUM>, the receiver MLD updates a replay counter to PN=<NUM>. Unlike illustration <NUM> of <FIG> where the rest of the MPDUs with SN greater than <NUM> (i.e. received MPDU <NUM> with SN=<NUM>, PN=<NUM> and received MPDU <NUM> with SN=<NUM>, PN=<NUM>) are dropped causing a replay rejection issue, MPDUs <NUM> and <NUM> pass the replay check since the PN are in order after the reordering process. Thus, regardless of the number of PTKs, if a common PN space is used to assign PN for the keys, and the same PN is used for retransmissions, the replay rejection issue described earlier is resolved.

<FIG> depicts a schematic of a transmitter MLD <NUM> in accordance with various embodiments. The transmitter MLD comprises a MAC-SAP <NUM> for performing distribution service (DS), a transmit buffer <NUM> (used to store the unprotected MPDUs, and optionally the protected MPDUs), a Sequence Number (SN) Assignment module <NUM>, a Packet Number (PN) Assignment module <NUM>, a MPDU Encryption and Integrity module <NUM> and a Re-transmission module <NUM> (that decides the link to be used for the retransmission, as well the MAC addresses to be used for the AAD and the Nonce construction during the cryptographic encapsulation process). The transmitter MLD <NUM> also comprises two affiliated STAs or stations, STA1 2014a and STA2 2014b. STA1 2014a comprises at MAC layer 2016a a MPDU Header & CRC Creation module 2020a, a Transmit (Tx) Buffer and Block acknowledgement (ack) Control module 2022a and an Aggregation Control 2024a. Likewise, STA2 2014b comprises at MAC layer 2016b a MPDU Header & CRC Creation module 2020b, a Tx Buffer and Block ack Control module 2022b and an Aggregation Control 2024b. Both STAs comprise a PHY layer from which transmission via Link <NUM> (for STA1 2014a) and Link <NUM> (for STA2 2014b) occurs. It will be appreciated that the number of links and affiliated STAs or stations may be further expanded. The above architecture is appropriate when the same PTK (and or GTK/IGTK) is used for all the links, for even if different PTKs are used for the links, if a same PN space is used for all links, which may help to avoid the replay rejection issue as explained in the context of <FIG>. However, in deployments that chooses to use different PTKs (and/or GTK/IGTK), the MPDU Encryption and Integrity module <NUM> may be moved down to the respective affiliated STAs. If separate PN space are used for the links (PNs are usually tied to their respective secret Keys), the Packet Number (PN) Assignment module <NUM> may also be moved down to the respective affiliated STAs.

<FIG> depicts a schematic of a receiver MLD <NUM> in accordance with various embodiments. The receiver MLD comprises a MAC-SAP <NUM> for performing distribution service (DS), a Replay Detection module <NUM>, a MPDU Decryption and Integrity module <NUM>, a Block Ack Buffering and Reordering module <NUM> and a Duplicate Detection module <NUM>. The receiver MLD <NUM> also comprises two affiliated STAs or stations, STA1 2114a and STA2 2114b. STA1 2114a comprises at MAC layer 2116a a Block Ack Scoreboarding module 2120a, an Address <NUM> filtering module 2122a and a De-aggregation Control 2124a. Likewise, STA2 2114b comprises at MAC layer 2116b a Block Ack Scoreboarding module 2120b, an Address <NUM> filtering module 2122b and a De-aggregation Control 2124b. Both STAs comprise a PHY layer (i.e. 2118a for STA1 2114a and 2118b for STA2 2114b) from which transmission via Link <NUM> (i.e. between STA1 2114a and STA1 2014a at the transmitter MLD <NUM>) and Link <NUM> (i.e. between STA2 2114b and STA2 2014b at the transmitter MLD <NUM>) occurs. It will be appreciated that the number of links and affiliated STAs or stations may be further expanded. Here, the MPDU Decryption and Integrity module <NUM> is responsible for parsing the Address field in the CCMP/GCMP Header to decide the Address fields used to construct the AAD and the Nonce field during the CCMP/GCMP decapsulation.

<FIG> shows a flow diagram <NUM> illustrating a method for multi-link secured retransmission of a MPDU according to various embodiments. At step <NUM>, a robust security network association (RSNA) is set up, at a first MLD configured to operate with a first plurality of affiliated STAs, with a second MLD that is configured to operate with a second plurality of affiliated STAs, wherein two or more links have been established between STAs of the first plurality of affiliated STAs and corresponding STAs of the second plurality of affiliated STAs. At step <NUM>, an Additional Authentication Data (AAD) and a Nonce are constructed, wherein the AAD includes an Address <NUM> (A1) field, an Address <NUM> (A2) field, an Address <NUM> (A3) field and a Sequence Control (SC) field, and the Nonce includes an Address <NUM> (A2) field, wherein the SC field of the AAD is based on a SC field of the MPDU. At step <NUM>, the MPDU is cryptographically encapsulated using the AAD and Nonce to form an encapsulated MPDU. If applicable, the Address field in the CCMP/GCMP Header is set to signal the Address fields used to generate the AAD and the Nonce field. At step <NUM>, the encapsulated MPDU is transmitted from the first MLD to the second MLD on a first link as an initial transmission. At step <NUM>, the encapsulated MPDU is retransmitted on a second link without reperforming the cryptographical encapsulation upon failure of the initial transmission. If applicable, the Address field in the CCMP/GCMP Header in the retransmitted MPDU is set to signal the Address fields used to generate the AAD and the Nonce field during the encapsulation process.

<FIG> shows a schematic, partially sectioned view of a multi-link device <NUM> that can be implemented for multilink secured retransmissions in accordance with the first to fifth embodiments. The multi-link device <NUM> may be implemented as an AP MLD or non-AP MLD, and comprising one or more affiliated stations or STAs according to various embodiments.

Various functions and operations of the multi-link device <NUM> are arranged into layers in accordance with a hierarchical model. In the model, lower layers report to higher layers and receive instructions therefrom in accordance with IEEE specifications. For the sake of simplicity, details of the hierarchical model are not discussed in the present disclosure.

As shown in <FIG>, the multi-link device <NUM> may include circuitry <NUM>, at least one radio transmitter <NUM>, at least one radio receiver <NUM> and multiple antennas <NUM> (for the sake of simplicity, only one antenna is depicted in <FIG> for illustration purposes). The circuitry may include at least one controller <NUM> for use in software and hardware aided execution of tasks it is designed to perform, including control of communications with one or more other multi-link devices in a MIMO wireless network. The at least one controller <NUM> may control at least one transmission signal generator <NUM> for generating MPDU to be sent through the at least one radio transmitter <NUM> to one or more other multi-link devices and at least one receive signal processor <NUM> for processing MPDU received through the at least one radio receiver <NUM> from the one or more other multi-link devices. The at least one controller <NUM> may also control the at least one transmission signal generator <NUM> and/or the least one receive signal processor <NUM> for constructing AAD and Nonce frames, as well as performing CCMP or GCMP encapsulation or decapsulation on MPDUs using the constructed AAD and Nonce frames. The at least one transmission signal generator <NUM> and the at least one receive signal processor <NUM> may be stand-alone modules of the multi-link device <NUM> that communicate with the at least one controller <NUM> for the above-mentioned functions. Alternatively, the at least one transmission signal generator <NUM> and the at least one receive signal processor <NUM> may be included in the at least one controller <NUM>. It is appreciable to those skilled in the art that the arrangement of these functional modules is flexible and may vary depending on the practical needs and/or requirements. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets.

In various embodiments, when in operation, the at least one radio transmitter <NUM>, at least one radio receiver <NUM>, and at least one antenna <NUM> may be controlled by the at least one controller <NUM>. Furthermore, while only one radio transmitter <NUM> is shown, it will be appreciated that there can be more than one of such transmitters i.e. one transmitter for each affiliated station or STA of the multi-link device <NUM>.

In various embodiments, when in operation, the at least one radio receiver <NUM>, together with the at least one receive signal processor <NUM>, forms a receiver of the multi-link device <NUM>. The receiver of the multi-link device <NUM>, when in operation, provides functions required for multi-link communication. While only one radio receiver <NUM> is shown, it will be appreciated that there can be more than one of such receivers i.e. one receiver for each affiliated station or STA of the multi-link device <NUM>.

The multi-link device <NUM>, when in operation, provides functions required for multi-link secured retransmissions. For example, the multi-link device <NUM> may be a first multi-link device configured to operate with a first plurality of affiliated STAs. The circuitry <NUM> may, in operation, set up a robust security network association (RSNA) with a second MLD that is configured to operate with a second plurality of affiliated STAs, wherein two or more links have been established between STAs of the first plurality of affiliated STAs and corresponding STAs of the second plurality of affiliated STAs, wherein the circuitry constructs an Additional Authentication Data (AAD) and a Nonce that are used for cryptographical encapsulation of a MAC protocol data unit (MPDU) to form an encapsulated MPDU, wherein the AAD includes an Address <NUM> (A1) field, an Address <NUM> (A2) field, an Address <NUM> (A3) field, and a Sequence Control (SC) field, and the Nonce includes an Address <NUM> (A2) field, and wherein the SC field of the AAD is based on a SC field of the MPDU. The transmitter <NUM> may, in operation, transmit the encapsulated MPDU to the second MLD on a first link as an initial transmission, and upon failure of the initial transmission, retransmit the encapsulated MPDU on a second link without reperforming the cryptographical encapsulation.

The A2 field of the AAD and the Nonce may be set to a medium access control (MAC) address that identifies the first MLD, and the A1 field of the AAD may be set to a MAC address that identifies the second MLD. One of a CCMP or a GCMP may be used to cryptographically protect the MPDU. The MPDU may comprise identification information of the first and second MLDs, wherein the A2 field of the AAD and the Nonce may be set to a MAC address that identifies the first MLD indicated in the identification information, and the A1 field of the AAD may be set to a MAC address that identifies the second MLD indicated in the identification information.

The circuitry <NUM> may specify in the MPDU settings of the A1, A2, A3 fields, the settings indicating whether, during cryptographical decapsulation of the MPDU, the A1, A2, A3 fields are to be set to a MAC address that identifies the second MLD, a MAC address that identifies the first MLD and a MAC address that identifies an AP MLD respectively, or the A1, A2, A3 fields are to be set to a MAC address of an affiliated STA of the second MLD, a MAC address of an affiliated STA of the first MLD and the MAC address that identifies the AP MLD respectively, or the A1, A2, A3 fields are to be set to A1, A2, A3 fields of the MPDU respectively, wherein the AP MLD is the first or second MLD. The settings of the A1, A2, A3 fields may be indicated in one of a Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) Header field or a Galois/Counter Mode Protocol (GCMP) Header field of the encapsulated MPDU.

The A2 field of the AAD and the Nonce may be set to an A2 field of the MPDU, and the A1 field of the AAD may be set to an A1 field of the MPDU, wherein upon failure of the initial transmission, the circuitry <NUM> further may specify in the retransmitted MPDU settings of the A1, A2, A3 fields, the settings indicating whether, during cryptographical decapsulation of the retransmitted MPDU, the A1, A2, A3 fields are to be set to a MAC address of an affiliated STA of the second MLD, a MAC address of an affiliated STA of the first MLD and the MAC address that identifies the AP MLD respectively, or the A1, A2, A3 fields are to be set to the A1, A2, A3 fields of the retransmitted MPDU respectively.

For example, the multi-link device <NUM> may be a first multi-link device configured to operate with a first plurality of affiliated STAs. The circuitry <NUM> may, in operation, set up a robust security network association (RSNA) with a second MLD that is configured to operate with a second plurality of affiliated STAs, wherein two or more links have been established between STAs of the first plurality of affiliated STAs and corresponding STAs of the second plurality of affiliated STAs. The receiver <NUM> may, in operation, receive a cryptographically encapsulated MAC protocol data unit (MPDU) from the second MLD, wherein the circuitry <NUM> constructs an Additional Authentication Data (AAD) and a Nonce that are used for cryptographical decapsulation of the received MPDU, wherein the AAD includes an Address <NUM> (A1) field, an Address <NUM> (A2) field, an Address <NUM> (A3) field, and a Sequence Control (SC) field, and the Nonce includes an Address <NUM> (A2) field, wherein the A2 field of the AAD and the Nonce may be set to either an A2 field of the MPDU or a medium access control (MAC) address that identifies the second MLD or a MAC address of one of the second plurality of affiliated STAs, the A1 field of the AAD may be set to either an A1 field of the MPDU or a MAC address that identifies the first MLD or a MAC address of one of the first plurality of affiliated STAs, the Address <NUM> (A3) field of the AAD may be set to the BSSID field of a link, or the A3 field of the MPDU, or the MAC Address of the AP MLD and the SC field of the AAD is based on a SC field of the MPDU.

The circuitry <NUM> may cryptographically decapsulate the MPDU received from the second MLD, wherein the A2 field of the AAD and the Nonce may be set to the MAC address that identifies the second MLD, and the A1 field of the AAD may be set to the MAC address that identifies the first MLD. One of a CCMP or a GCMP may be used to cryptographically decapsulate the MPDU. The MPDU may carry identification information of the first and second MLDs, wherein the circuitry may cryptographically decapsulate the MPDU by setting the A2 field of the AAD and the Nonce to the MAC address that identifies the second MLD indicated in the MPDU, and the A1 field of the AAD to the MAC address that identifies the first MLD indicated in the MPDU.

The circuitry <NUM> may cryptographically decapsulate the received MPDU based on settings of the A1, A2, A3 fields indicated in the MPDU, the settings indicating whether, during the cryptographical decapsulation, the A1, A2, A3 fields are to be set to the MAC address that identifies the first MLD, the MAC address that identifies the second MLD and the MAC address that identifies an AP MLD respectively, or the A1, A2, A3 fields are to be set to the MAC address of an affiliated STA of the first MLD, the MAC address of an affiliated STA of the second MLD and the MAC address that identifies the AP MLD respectively, or the A1, A2, A3 fields are to be set to the A1, A2, A3 fields of the MPDU respectively, wherein the AP MLD is the first or second MLD. The settings of the Address fields may be indicated in one of a CCMP Header or a GCMP Header of the MPDU received from the second MLD.

The circuitry <NUM> may 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 the A1 field of the AAD to the A1 field of the first MPDU, wherein the first MPDU includes a Retry subfield that is set to <NUM>; The circuitry <NUM> may cryptographically decapsulate a second MPDU received from the second MLD based on the settings of the A1, A2, A3 fields indicated in the second MPDU, the settings indicating whether, during the cryptographical decapsulation, the A1, A2, A3 fields are to be set to the MAC address of an affiliated STA of the first MLD, the MAC address of an affiliated STA of the second MLD and the MAC address that identifies the AP MLD respectively, or the A1, A2, A3 fields are to be set to A1, A2, A3 fields of the second MPDU respectively, wherein the second MPDU includes a Retry subfield that is set to <NUM>.

The present disclosure can be realized by software, hardware, or software in cooperation with hardware. Each functional block used in the description of each embodiment described above can be partly or entirely realized by an LSI such as an integrated circuit, and each process described in the each embodiment may be controlled partly or entirely by the same LSI or a combination of LSIs. The LSI may be individually formed as chips, or one chip may be formed so as to include a part or all of the functional blocks. The LSI may include a data input and output coupled thereto. The LSI here may be referred to as an IC, a system LSI, a super LSI, or an ultra LSI depending on a difference in the degree of integration. However, the technique of implementing an integrated circuit is not limited to the LSI and may be realized by using a dedicated circuit, a general-purpose processor, or a special-purpose processor. In addition, a FPGA (Field Programmable Gate Array) that can be programmed after the manufacture of the LSI or a reconfigurable processor in which the connections and the settings of circuit cells disposed inside the LSI can be reconfigured may be used. The present disclosure can be realized as digital processing or analogue processing. If future integrated circuit technology replaces LSIs as a result of the advancement of semiconductor technology or other derivative technology, the functional blocks could be integrated using the future integrated circuit technology. Biotechnology can also be applied.

The present disclosure can be realized by any kind of apparatus, device or system having a function of communication, which is referred as a communication device.

The communication device may comprise a transceiver and processing/control circuitry. The transceiver may comprise and/or function as a receiver and a transmitter. The transceiver, as the transmitter and receiver, may include an RF (radio frequency) module including amplifiers, RF modulators/demodulators and the like, and one or more antennas.

Some non-limiting examples of such communication device include a phone (e.g., cellular (cell) phone, smart phone), a tablet, a personal computer (PC) (e.g., laptop, desktop, netbook), a camera (e.g., digital still/video camera), a digital player (digital audio/video player), a wearable device (e.g., wearable camera, smart watch, tracking device), a game console, a digital book reader, a telehealth/telemedicine (remote health and medicine) device, and a vehicle providing communication functionality (e.g., automotive, airplane, ship), and various combinations thereof.

The communication device is not limited to be portable or movable, and may also include any kind of apparatus, device or system being non-portable or stationary, such as a smart home device (e.g., an appliance, lighting, smart meter, control panel), a vending machine, and any other "things" in a network of an "Internet of Things (IoT)".

The communication device may comprise an apparatus such as a controller or a sensor which is coupled to a communication apparatus performing a function of communication described in the present disclosure. For example, the communication device may comprise a controller or a sensor that generates control signals or data signals which are used by a communication apparatus performing a communication function of the communication device.

The communication device also may include an infrastructure facility, such as a base station, an access point, and any other apparatus, device or system that communicates with or controls apparatuses such as those in the above non-limiting examples.

As a non-limiting example of an architecture (for example, the architectures as illustrated in <FIG> and <FIG>), the MLD of the present disclosure can be logical and realized by a plurality of separated communication apparatuses sharing a common MAC data service interface to an upper layer.

A non-limiting example of a station may be one included in a first plurality of stations affiliated with a multi-link station logical entity (i.e. such as an MLD), wherein as a part of the first plurality of stations affiliated with the multi-link station logical entity, stations of 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 a Traffic Identifier (TID).

Thus, it can be seen that the present embodiments provide communication devices and methods for operation over multiple links in order to fully realize the throughput gains of multi-link communication, in particular for multi-link secured retransmissions.

Claim 1:
A transmitting multi-link device, MLD (<NUM>), configured to operate with a first plurality of affiliated STAs (<NUM>, <NUM>), the transmitting MLD comprising:
circuitry (<NUM>) configured to set up a robust security network association, RSNA, with a receiving MLD (<NUM>) that is configured to operate with a second plurality of affiliated STAs (<NUM>, <NUM>), wherein two or more links have been established between STAs of the first plurality of affiliated STAs (<NUM>, <NUM>) and corresponding STAs of the second plurality of affiliated STAs (<NUM>, <NUM>),
wherein the circuitry (<NUM>) is configured to construct an Additional Authentication Data, AAD (<NUM>), and a Nonce (<NUM>) that are used for cryptographical encapsulation of a MAC protocol data unit, MPDU, and encapsulates a plaintext MAC protocol data unit, MPDU, the AAD (<NUM>) and the Nonce (<NUM>) to generate an encapsulated MPDU, and
a transmitter (<NUM>, <NUM>) configured to transmit the encapsulated MPDU (<NUM>) to the receiving MLD on a first link as an initial transmission,
wherein
the AAD (<NUM>) includes an Address <NUM>, A1, field to which a receiving MLD's medium access control, MAC, address (<NUM>) is set, an Address <NUM>, A2, field to which the transmitting MLD's MAC address (<NUM>) is set, an Address <NUM>, A3, field and a Sequence Control, SC, field;
the Nonce (<NUM>) includes an Address <NUM>, A2, field to which the transmitting MLD's MAC address (<NUM>) is set, wherein the SC field of the AAD (<NUM>) is based on a SC field of the MPDU; and
the transmitter, upon failure of the initial transmission of the encapsulated MPDU (<NUM>), retransmits the encapsulated MPDU (<NUM>) on a second link without changing a packet number, PN, that is used in the initial transmission.