Communication apparatus and communication method for secure retransmission on multi-links

Abstract

To provide a device and a method for secure retransmission on multi-links.SOLUTION: A receiving-side MLD includes a receiving unit that receives an encapsulated MAC protocol data unit (encapsulated MPDU) from a transmitting-side MLD via a first link, and a circuit that constructs additional authentication data (AAD) and a nonce and decapsulates the encapsulated MPDU using the AAD and the nonce to obtain a plaintext MPDU, the AAD including an address 1 (A1) field where a MAC address of the receiving-side multi-link device (MLD) is set and an address 2 (A2) field where a MAC address of the transmitting-side MLD is set, and the nonce including the A2 field where the MAC address of the transmitting-side MLD is set.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] This embodiment generally relates to a communication device, and more particularly, to a method and apparatus for secure transmission of multi-link.

Background Art

[0002] Today, communication devices are expected to operate wirelessly with the same functions as wired computing devices. For example, users expect to be able to seamlessly watch high-resolution movies streamed to their wireless communication devices. This has led to problems related to communication devices and problems related to access points to which communication devices are wirelessly connected.

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

[0004] Furthermore, in such IEEE 802.11 devices, a security protocol including, but not limited to, the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or the Galois / Counter Mode Protocol (GCMP) is used 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

Problems to be Solved by the Invention

[0005] Non-limiting embodiments of the present disclosure contribute to providing devices and methods for secure retransmission of multi-links.

Means for Solving the Problems

[0006] A non-limiting and exemplary embodiment is a first multi-link device (MLD) configured to operate with a first plurality of affiliated STAs (Stations), which, during operation, includes a second MLD configured to operate with a second plurality of affiliated STAs, and a circuit for setting up a robust security network association (RSNA), wherein two or more links are established between the STAs of the first plurality of affiliated STAs and the corresponding STAs of the second plurality of affiliated STAs, and a circuit 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, 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, the nonce includes the A2 field, and the SC field of the AAD is based on the SC field of the MPDU, and a transmitter that, during operation, transmits the encapsulated MPDU as a first transmission to the second MLD over a first link and, when the first transmission fails, retransmits the encapsulated MPDU over a second link without re-executing the cryptographic encapsulation, to facilitate providing a first multi-link device (MLD).

[0007] Another non-limiting and exemplary embodiment is a method of retransmitting an MPDU in multi-link communication, including: in a first MLD configured to operate with a first plurality of attached STAs, a second MLD configured to operate with a second plurality of attached STAs; setting up a Robust Security Network Association (RSNA), wherein two or more links are established between the STAs of the first plurality of attached STAs and the corresponding STAs of the second plurality of attached STAs; constructing additional authentication data (AAD) and a nonce, wherein the AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, the nonce includes the A2 field, and the SC field of the AAD is based on the SC field of the MPDU; cryptographically encapsulating the MPDU using the AAD and the nonce to form an encapsulated MPDU; transmitting the encapsulated MPDU from the first MLD to the second MLD over a first link as a first transmission; and when the first transmission fails, retransmitting the encapsulated MPDU over a second link without re-executing the cryptographic encapsulation.

[0008] Note 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 optional combination thereof. Further benefits and advantages of the disclosed embodiments will become apparent from the present specification and the drawings. The benefits and / or advantages can be obtained individually by various embodiments and features of the present specification and the drawings, and it is not necessary that all be provided to obtain one or more of such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments and together with the detailed description serve to explain the various principles and advantages of the embodiments. Throughout the separate drawings, like reference numerals refer to the same or functionally similar elements.

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18A

Figure 18B

Figure 18C

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

[0010] Those skilled in the art will understand that the elements in the figure are shown for the purpose of simplicity and clarity and are not necessarily drawn to scale.

DETAILED DESCRIPTION OF THE INVENTION

[0011] The following detailed description is merely exemplary and is not intended to limit the embodiments or the application and use of the embodiments. Further, it is not intended to be bound by the theory presented in the previous background art or the section of the detailed description of the invention. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and the background of the present disclosure.

[0012] Referring to FIG. 1, this figure shows the steps when processing an MPDU using CCMP according to various embodiments. In step 1, an MAC header is added to data such as a MAC service data unit (MSDU) or a management MPDU (MMDPU) to form an MPDU. In step 2, the MAC header is separated from the MPDU and a CCMP header is created. In step 3, a message integrity code (MIC) is calculated and added 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. Next, the CCMP header is added in front of the ciphertext. In step 5, the MAC header is restored by adding the MAC header in front of the CCMP header. In step 6, a cyclic redundancy check (CRC) is calculated for the entire MPDU and added to the end of the MPDU to form a protected or encrypted MPDU.

[0013] Figure 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 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 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] Generally, the contents of the A1, A2, and A3 address fields of a data frame depend on the "To DS" subfield and the "From DS" subfield of the FC field of the MAC header. This is shown in Table 1 below.

Table 1

[0016] When the contents of both the "To DS" subfield and the "From DS" subfield are "0", the content of the A1 field is the recipient address (RA) (= destination address (DA)), the content of the A2 field is the sender address (TA) (= source address (SA)), the content of the A3 field is the basic service set identifier (BSSID), and address 4 does not exist. When the content of the "To DS" subfield is "0" and the content of the "From DS" subfield is "1", the content of the A1 field is RA, the content of the A2 field is the sender address (TA) (= BSSID), the content of the A3 field is SA, and address 4 does not exist. When the content of the "To DS" subfield is "1" and the content of the "From DS" subfield is "0", the content of the A1 field is RA (= BSSID), the content of the A2 field is TA, the content of the A3 field is DA, and address 4 does not exist. When the contents of both the "To DS" subfield and the "From DS" subfield are "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] In the case of a management frame, the contents of the A1, A2, and A3 address fields are generally the same as those of a data frame when "To DS" = 0 and "From DS" = 0. That is, the content of the A1 field is RA (= DA), and the content of the A2 field is TA (= SA). A3 depends on the frame type but is set to BSSID in most cases. When a STA sends a management frame to an access point (AP) with multiple BSSIDs configured, regardless of whether the STA is associated with that AP, the address 3 field is the BSSID of the AP's BSS (either the transmitting BSSID or the non-transmitting BSSID).

[0018] In the multi-link operation in next-generation wireless LANs such as 802.11be, it may be permitted to simultaneously transmit MPDUs with the same TID (Traffic ID) over different links. However, in such multi-link transmissions, when security encapsulation is applied to the MPDU, it may lead to unexpected operations as described below. When it is possible to simultaneously transmit MPDUs with the same TID over different links, in order for the receiving MLD to be able to correctly reorder the MPDUs received over different links, an SN (Sequence Number) can be assigned to the MSDU or MMPDU conveyed in the MPDU using the same sequence number space regardless of the link used for the actual transmission. At the first 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) can be negotiated between the AP MLD and the non-AP MLD and used as the master key for secure transmission between the two MLDs. The PTK (Pairwise Temporal Key) and GTK / IGTK ((Integrity) Group Temporal Key) used for secure encapsulation / decapsulation of the MPDU can be derived from the same PMK for different links. It is possible to generate separate PTKs and separate GTK / IGTKs for use on different links. Figure 3 shows an illustration 300 of multi-link MPDU transmission using separate PTKs for each link. In this example, the transmitting MLD transmits MPDUs to the receiving MLD over Link 1 and Link 2. PTK key 1 is used for Link 1 and a different PTK key 2 is used for Link 2. Also, a common sequence number (SN) is used for MPDU transmission on both links, but the packet number (PN) counters used on each link are different.For example, the PN counter of the MPDU transmitted on Link 1 starts from PN = 100, and the PN counter of the MPDU transmitted on Link 2 starts from PN = 51.

[0019] In this example, since the MPDU 302 on Link 1 fails to be transmitted, it is scheduled to be retransmitted on another link such as Link 2 instead of Link 1. Since a different PTK (i.e., Key 2) is used on Link 2, it is necessary to encapsulate the MPDU 302 as MPDU 304 using Key 2 and a new PN = 54 (because retransmission is scheduled after the transmission of MPDU 308 with PN = 53), where MPDU 304 still shares the same SN = 4 as MPDU 302. On the receiving side, the receiver MLD sorts the MPDUs received on Link 2 according to the SN of each received MPDU including MPDU 304. When sorting up to SN = 4, i.e., up to 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., the received MPDU 306 with SN = 5 and PN = 52 and the received MPDU 308 with SN = 7 and PN = 53) are dropped, causing an unintended replay rejection problem.

[0020] Also, even when a single PTK is used on all links, if the retransmitted MPDU is re-encapsulated with a new PN, a replay rejection problem will still occur. This can be seen in Figure 4, which shows an illustration 400 of 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, since the MPDU 402 with SN = 4 and PN = 104 at Link 1 fails to be transmitted, it is scheduled to be retransmitted on a different link such as Link 2 instead of Link 1. Since Link 2 has different A1 and A2 fields compared to Link 1, it is necessary to re-encapsulate the MPDU 402 as MPDU 404 using a new PN = 108 (because retransmission is scheduled after the transmission of MPDU 408 with PN = 107), where MPDU 404 still shares the same SN = 4 as MPDU 402. The receiver MLD sorts the MPDUs received on Link 2 according to the SN of each received MPDU including MPDU 404. When sorting up to SN = 4, that is, up to 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., the received MPDU 406 with SN = 5 and PN = 105 and the received MPDU 408 with SN = 7 and PN = 107) are dropped, causing a replay rejection problem.

[0022] Furthermore, in IEEE 802.11be, although it may be mandatory to use separate MAC addresses for each link in some cases, it may also be permitted to use the same MAC address for different links. When separate MAC addresses are used for links, even if the TAs of two transmitting links are the same, the RAs of two receiving links are different, and when a frame is retransmitted on a different link using the same A2 (i.e., = TA) and the same PN (i.e., the PN remains the same throughout retransmission to avoid the order of the PNs received after SN sorting by the receiver MLD from being shifted), the problem (security defect) of reusing the same nonce value to protect different data can be avoided. However, the IEEE 802.11 specification describes the use of nonces and PNs as follows. "In CCM, a new temporary key is required for each session. Also, in CCM, a unique nonce value is required for each frame protected by a given temporary key, and for this purpose CCMP uses a 48-bit packet number (PN). Reusing the PN with the same temporary key invalidates all security guarantees." That is, to avoid the replay rejection problem, reusing the same PN in retransmissions on different links solves the problem but may introduce security vulnerabilities. Note that as a prerequisite, the retransmitted MPDU needs to be re-encapsulated when retransmitted on different links. This disclosure provides several options for avoiding such security-related problems caused by multi-link transmission.

[0023] Figure 5 shows an illustration of the CCMP encapsulation process for forming an encrypted MPDU according to the IEEE 802.11 specification. In particular, to form an encrypted or protected MPDU, additional authentication data (AAD) 502 and nonce 504 are constructed and used in the cryptographic encapsulation of the MPDU. AAD 502 includes the Frame Control (FC) field, Address 1 (A1) field, Address 2 (A2) field, Address 3 (A3) field, Sequence Control (SC) field, optional Address 4 (A4) field, and optional Quality Control (QC) field, and nonce 504 includes the Nonce Flags field, A2 field, and PN field. The contents of the A1, A2, A3 fields of AAD 502 and the contents of the A2 field of nonce 504 are taken from the A1, A2, A3 fields of the MPDU to be encapsulated (decapsulated in the case of the decapsulation process of the encrypted MPDU).

[0024] In 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 of the FC field and some subfields are generally masked to 0 during CCMP encapsulation. - The CRC is recalculated, but the FCS is not an input to CCMP encapsulation. - The MPDU is encapsulated only during the first transmission and not during retransmission. However, in the case of MLD, the rule for retransmitting the protected MPDU may depend on the link on which the MPDU is retransmitted. If the same link is used for retransmission, the MPDU is encapsulated only during the first transmission and not during retransmission. If a different link is used for retransmission (assuming that the MAC addresses of the attached STAs at both ends of the link are different), it is necessary to re-encapsulate the MPDU before retransmission (it is also possible to use the same PN to avoid the replay rejection problem). However, reusing the PN using the same security key may lead to security defects.

[0025] Therefore, the present invention seeks a method to avoid CCMP encapsulation when retransmitting a protected frame over different links (even if the MAC addresses are different for each link).

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

[0027] As shown in the illustration 600, the transmitting - side MLD 602 transmits the unprotected MPDU 608 on link 1 to the receiving - side MLD 612, that is, from STA 604 to STA 614. Therefore, the A1, A2, and A3 fields of the MPDU 608 are set to the MAC address of the receiving - side STA 614 (i.e., RA1) and the MAC address of the transmitting - side STA 604 (i.e., TA1), respectively. As the first transmission, the Retry sub - field of the FC field of the MPDU 608 is set to 0. If the transmission fails for various reasons (e.g., a temporary failure of link 1), this MPDU can be re - transmitted on link 2, that is, from STA 606 to STA 616, as the unprotected MPDU 610. The unprotected MPDU can be re - transmitted on another link by simply setting the Retry sub - field of the Frame Control (FC) field of the MPDU to 1 and swapping the A1, A2, and A3 of the MAC header. Therefore, the A1 field of the MPDU 610 is set to the MAC address of the receiving - side STA 616 (i.e., RA2), and the A2 field is set to the MAC address of the transmitting - side STA 606 (i.e., TA2). Further, the Reset sub - field of the FC field of the MPDU 610 is set to 1. For an MPDU with A3 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 a frame, and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD - TA if the sender is the AP MLD (or the BSSID of that link if it is different from MLD - TA), and to MLD - RA if the sender is a non - AP MLD (or the BSSID of that link if it is different from MLD - RA). If the MAC address is the same for each link, the re - transmission rules can be the same as those for a single - link STA (i.e., there is no need to change the A1, A2, and A3 addresses).

[0028] In the first transmission of the protected MPDU according to the first embodiment, when CCMP encapsulating the protected MPDU addressed to the peer MLD, the MLD MAC address is used instead of the MAC address of the attached STA on the transmitting / receiving side (i.e., the A1 and A2 fields of the transmitted MPDU) to generate the AAD and nonce. FIG. 7A shows an illustration of the AAD 700 according to the first embodiment. Although similar to the AAD 502, the A1 field 702 and the A2 field 704 of the AAD 700 are set to the MAC address of the receiving MLD and the MAC address of the transmitting MLD (i.e., MLD-RA and MLD-TA), respectively, instead of the MAC address of the attached STA on the receiving / transmitting side shown in the A1, A2, and A3 fields of the transmitted protected MPDU. For an MPDU with A3 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the sender is the AP MLD (or the BSSID of that link if different from MLD-TA), or MLD-RA if the sender is a non-AP MLD (or the BSSID of that link if different from MLD-RA). FIG. 7B shows an illustration of the nonce 706 according to the first embodiment. Although similar to the nonce 504, the A2 field 708 of the nonce 706 is set to the MAC address of the transmitting MLD (i.e., MLD-TA) instead of the MAC address of the attached STA on the transmitting side shown in the A2 field of the transmitted protected MPDU. The protected MPDU can be stored in the memory of the transmitting MLD until the transmitting MLD receives a confirmation response of successful reception of the MPDU from the receiving MLD, or until the lifetime of the MSDU ends.

[0029] When the transmission of the protected MPDU according to the first embodiment fails, if the protected MPDU is retrieved from the memory (when saved at the first transmission), the Retry subfield of the FC field is set to 1, the A1 and A2 fields of the MAC header are swapped, and after adding a new CRC, it is retransmitted. Regardless of the link MAC address used for the link, since the AAD and nonce remain the same, there is no need to re - execute the CCMP encapsulation, which is advantageous. In fact, the fields of the MAC header that can change in content during re - transmission (e.g., Duration / ID field, HT control field) are not included in the AAD and thus 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, 6) of the data frame is masked to 0. ii) The Retry subfield (bit 11) is masked to 0. iii) The Power Management subfield (bit 12) is masked to 0. 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 as follows. - Masked to 0 in all data frames including the QoS Control field. - Not masked otherwise.

[0030] If the protected MPDU was not saved in the memory at the first transmission, the original unprotected MPDU is retrieved from the memory (e.g., from the transmit buffer) and re - encapsulated, but the MLD MAC address is used for the A1, A2, A3 fields of the AAD (and the A3 field if applicable) and the A2 field of the nonce.

[0031] When CCMP decapsulation occurs, regardless of the link used for receiving the protected MPDU (from the peer MLD), the MLD MAC address is used instead of the MAC address of the associated STA on the transmitting / receiving side (i.e., the A1 and A2 fields of the received MPDU) to generate the AAD and nonce. FIG. 8 shows an illustration 800 of the CCMP decapsulation process used by the receiving-side MLD to form a plaintext MPDU according to the first embodiment. To decapsulate the protected or encrypted MPDU, the 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-side MLD (i.e., MLD-RA) and the MAC address of the transmitting-side MLD (i.e., MLD-TA), respectively. For 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the sender is the AP MLD (or the BSSID of that link if it is different from MLD-TA), and to MLD-RA if the sender is a non-AP MLD (or the BSSID of that link if it is different from MLD-RA). Further, the A2 field 808 of the nonce 810 is set to the MAC address of the transmitting-side MLD (i.e., MLD-TA). To verify the identity of the transmitting STA, the A2 field of the received MPDU is checked before swapping with the MLD's MAC address (i.e., the A2 field of the received MPDU should indicate the MAC address of the transmitting-side STA belonging to the peer MLD). The A1 field of the received MPDU has already been checked during received frame filtering.

[0032] In the retransmission of the protected MPDU according to the first embodiment, it is assumed that the MLD MAC address is recognized by both the transmitting - side MLD and the receiving - side MLD (e.g., exchanged during the association / link activation procedure). Further, it is assumed that the same PTK is used for all links. If different PTKs are used for different links, it is necessary to re - encapsulate the MPDU before re - transmitting on different links. When the link - by - link MAC addresses are the same and a single PTK is used for all links, the retransmission rules are the same as those for a single - link STA.

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

[0034] Figure 9 shows a flowchart 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 at step 920. In step 904, if it is determined that the MPDU needs to be protected, the process proceeds to step 906, where the A1 field of the AAD to be constructed is set to the MAC address of the receiving MLD. In step 908, the AAD and the A2 field of the constructed nonce are set to the MAC address of the local MLD, i.e., the transmitting MLD. Although not shown, for an MPDU in which 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the transmitter is the AP MLD (or the BSSID of that link if it is different from MLD-TA), or to MLD-RA if the transmitter is a non-AP MLD (or the BSSID of that link if it is different from MLD-RA). In step 910, the remaining fields of the AAD and the nonce are set as usual, i.e., in accordance with 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 to the next process for transmission to the receiving MLD, and the process ends at step 916.

[0035] Figure 10 shows flowchart 1000 for retransmission of an MPDU according to the first embodiment. At step 1002, it is determined that it is necessary to retransmit the MPDU after the failure of the first transmission (for example, when receiving a BlockAck frame indicating the failure of the first transmission). At step 1004, the saved MPDU is retrieved from the memory. At step 1006, the retry subfield of the FC field of the MPDU is set to 1. At step 1008, it is determined whether the MPDU is a protected MPDU or an unprotected MPDU. If 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 first transmission. If it is determined that the MPDU should be retransmitted on the same link as the first transmission, the process continues from step 1016. Otherwise, if it is determined that the MPDU should be retransmitted on a different link, the process proceeds to step 1020 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 first transmission link, the process continues from step 1016. Otherwise, the process proceeds to step 1022, where the A1 field and / or the A2 field are set to the new RA and / or TA of the new link, and then the process continues from step 1016.

[0036] In step 1008, if it is determined 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 first transmission. If it is determined to use the same link for retransmission, the process continues from step 1016. Otherwise, the process proceeds to step 1012 to determine whether the TA or RA is different in the new link used for retransmission. If it is determined that the TA or RA is not different in the new link compared to the link used for the first transmission, the process continues from step 1016. Otherwise, the process proceeds to step 1014 to set the A1 field and / or A2 field to the new RA and / or TA of the new link, and then the process continues from step 1016. Further, after step 1016, the MPDU is sent to the next process for retransmission, and the process ends at step 1028. It should be noted that the processes for retransmission of protected MPDUs and unprotected MPDUs are exactly the same (i.e., regardless of the result of step 1008). Although not shown, for an MPDU in which 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 (the BSSID is generally the same as the MAC address of the AP MLD in that link).

[0037] Figure 11 shows a flowchart 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, the MPDU is sent to the next process for reception, and then the process ends at step 1126. In step 1104, if it is determined that the MPDU is protected, the process proceeds to step 1106, and it is determined whether the A2 field of the received MPDU indicates the MAC address that identifies the peer MLD. In the case of a non-AP MLD, the peer MLD refers to the AP MLD to which itself is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD associated with itself. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, conventional procedures for decapsulation are used, the process proceeds to step 1120, the constructed AAD and the A2 field of the nonce are set to the A2 field of the MPDU, the process proceeds to step 1122, the A1 field of the constructed AAD is set to the A1 field of the MPDU (and A3 if applicable), and then the process continues from step 1112. In step 1106, if it is determined that the A2 field is set to the MAC address that identifies the peer MLD, the process proceeds to step 1108, the A1 field of the constructed AAD is set to the MAC address of the receiving MLD, the process proceeds to step 1110, the constructed AAD and the A2 field of the nonce are set to the MAC address of the transmitting MLD, and then the process continues from step 1112. Although not shown, for an MPDU in which 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA (or the BSSID of that link if it is different from MLD-TA) if the sender is an AP MLD, or MLD-RA (or the BSSID of that link if it is different from MLD-RA) if the sender is a non-AP MLD.In step 1112, set the remaining fields of AAD and nonce as usual. In step 1114, perform CCMP decapsulation on the protected MPDU with the constructed AAD and nonce. In step 1116, send the decrypted MPDU to the next process for reception, and the process ends in step 1118. As an advantageous effect of the above process, it is possible to retransmit the encrypted MPDU on a different link without re-executing CCMP encapsulation, and the receiving MLD can still correctly decapsulate the MDPU.

[0038] According to the second embodiment, at the time of CCMP encapsulation of the protected MPDU in the first transmission, the MLD MAC address, or the A1 and A2 fields of the protected MPDU to be transmitted, or the per-link MAC address of any attached STA, is used to generate the AAD and nonce, and the same protected MPDU can be retransmitted on a different link (after setting the Retry subfield in the FC and changing some of the other fields described above) without performing CCMP encapsulation again. This is made possible by changing some fields of the MAC header of the protected MPDU, for example, the CCMP header, to signal the address used to generate the AAD and nonce during CCMP encapsulation. The transmitting MLD can select different addresses to generate the AAD and nonce during CCMP encapsulation based on the deployment scenario. For example, when the same PTK is used on all links, the MLD MAC address can be used as described in the first embodiment. Alternatively, the per-link MAC of the link used for the original transmission of the MPDU can be used to generate the AAD and nonce, and when the MPDU is retransmitted on a different link later, the 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, when the per-link MAC addresses of two links are the same, the transmitting MLD can signal to use the address field of the MAC header of the MPDU to generate the AAD and nonce. However, when different PTKs are used on different links, when retransmitting on different links, it is necessary to re-encapsulate the MPDU using the PTK of that link. In this case, CCMP encapsulation can follow the conventional method, and the AAD and nonce fields are generated using the address field of the MAC header of the (retransmitted) MPDU. However, even in this case, the transmitting 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.In this way, by signaling the MAC address in the CCMP header, regardless of the method used by the transmitting MLD for encapsulating the MPDU, the receiving MLD can correctly decapsulate the received protected MPDU (at the first transmission or retransmission). FIG. 12 shows an illustration of a protected MPDU 1200 according to the 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, when the value of the Address subfield 1206 is set to 0, the A1, A2, A3 fields of the AAD and the nonce are set to the A1, A2, A3 fields of the MAC header 1210, respectively. When the value of the Address subfield 1206 is set to 1, the A1, A2, A3 fields of the AAD and the nonce are set to the MAC addresses of the receiving MLD and the transmitting MLD, respectively. When the value of the Address subfield 1206 is set from 2 to n, the A1, A2, A3 fields of the AAD and the nonce are set to the per-link MAC addresses of the attached STAs associated with links 1 to (n - 1). Further, the A1, A2, A3 fields of the MAC header 1210 are set to the MAC address of the transmitting link (i.e., TA1 / TA2, RA1 / RA2) as usual, and A3 is set to the BSSID of the link.

[0039] Upon CCMP decapsulation, the receiving MLD determines the MAC address for generating the AAD and nonce using the Address subfield 1206. In this case, it is assumed that the per-link MAC address of all valid links is recognized by both the transmitting MLD and the 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 the FC to 1, swapping the A1, A2, A3 fields of the MAC header (and A3 if the BSSID of the link is different), and adding a new CRC), CCMP encapsulation is not performed, which is advantageous.

[0040] As a premise of the second embodiment, the same PTK is used in all links. Although other fields of the MAC header 1210 may be used to indicate address information, it is natural to select the CCMP header 1202 because this field is used to indicate security-related information and the CCMP header 1202 is transmitted in plain text without being included in the encapsulation process. Further, the links 1 to (n - 1) in the table 1208 represent the first link to the (n - 1)th link set up between two MLDs, and 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, when different PTKs are used in different links, when retransmitting in different links, it is necessary to re-encapsulate the MPDU using the PTK of that link. In this case, CCMP encapsulation can follow the conventional method and generate the AAD and nonce fields using the address field of the MAC header of the (retransmitted) MPDU. However, even in this case, the transmitting MLD can still signal in the CCMP header that it should generate the AAD and nonce fields using the address field of the MAC header of the (retransmitted) MPDU, enabling the receiving MLD to correctly decapsulate the received protected MPDU.

[0041] Figure 13 shows a flowchart 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, the MPDU is sent to the next process for reception, and then the process ends at step 1326. In step 1304, if it is determined that the MPDU is protected, the process proceeds to step 1306 to determine whether the A2 field of the received MPDU indicates the MAC address that identifies the 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 associated with itself. 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, the process proceeds to step 1320, the constructed AAD and the A2 field of the nonce are set to the A2 field of the MPDU, the process proceeds to step 1322, the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then the process continues from step 1312. In step 1306, if it is determined that the A2 field is set to the MAC address that identifies the peer MLD, the process proceeds to step 1308, the constructed AAD and the A2 field of the nonce are set to the MAC address according to the Address subfield of the CCMP header of the MPDU, the process proceeds to step 1310, the A1 field of the constructed AAD is set to the MAC address according to the Address field of the CCMP header of the MPDU, and then the process continues from step 1312.

[0042] In step 1312, set the remaining fields of AAD and nonce as normal. Although not shown in the figure, in the 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the sender is the AP MLD (or the BSSID of that link if it is different from MLD-TA), and to MLD-RA if the sender is a non-AP MLD (or the BSSID of that link if it is different from MLD-RA). In step 1314, perform CCMP decapsulation on the protected MPDU with the constructed AAD and nonce. In step 1316, send the decrypted MPDU to the next process for reception, and the process ends at step 1318. In this second embodiment, the receiving MLD always checks the CCMP header of the MPDU to determine the settings of the A1, A2, A3 fields of the constructed AAD and the A2 field of the nonce, regardless of whether it is the first transmission or a retransmission. Thereby, the transmitting-side MLD can more flexibly determine the address value in CCMP encapsulation, which is advantageous.

[0043] According to the third embodiment, at the time of CCMP encapsulation (in the first transmission of the protected MPDU), the A1, A2, A3 fields of the transmitted MPDU are used to generate the AAD and nonce, that is, the same as in the case of a conventional single-link STA. However, at the time of retransmission of the failed protected MPDU (after setting the Retry subfield of the FC to 1, swapping the A1, A2 fields (and A3 if applicable) of the MAC header, and adding a new CRC), the CCMP header indicates which A1, A2, A3 fields should be used by the receiving MLD to generate the AAD and nonce in decapsulation. CCMP encapsulation is not performed at the time of retransmission.

[0044] Figure 14 illustrates 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 that includes a Reserved subfield and an Address subfield 1406. When decrypting the CCMP, if the Retry subfield of the FC field in the MAC header field 1410 has a value of 1 (i.e., indicating that the received MPDU is a retransmission), the receiving MLD determines the MAC address for generating the AAD and nonce using the Address field 1406. Referring to Table 1408, if the value of the Address subfield 1406 is set to 0, the A1, A2, and A3 fields of the AAD and the A2 field of the nonce are set to their respective address fields in the MAC header field 1410. For example, if the A1 field of the MPDU 1400 indicates RA1 (or RA2), 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), the A2 fields of the AAD and the nonce are set to TA1 (or TA2), and the A3 field is set to the A3 field of the MPDU. Also, the fact that the value of the Address subfield 1406 is 0 indicates that the retransmission of the MPDU 1400 is on the same link as the first transmission (or that the per-link MAC address for different links is the same as that on the link used for the first transmission), and the receiving MLD can decrypt the protected MPDU using the conventional method. When the value of the Address subfield 1406 is set from 1 to n, the A1 and A2 fields of the AAD and the A2 field of the nonce are set to the per-link MAC address of the attached STA associated with links 1 to link (n), and the A3 field of the AAD is set to the per-link MAC address of the attached STA of the AP MLD for that link. Also, the values from 1 to n of the Address subfield 1406 also indicate that the retransmission is on a different link from the first transmission.On the one hand, when the value of the Retry subfield is 0 (i.e., indicating that the received MPDU is the first transmission), the A1, A2, and A3 fields of the MAC header field 1410 are used to generate the AAD and nonce (conventional operation).

[0045] As a premise of this embodiment, the same PTK is used in all links, and the CCMP header of the MPDU is transmitted in plain text (i.e., not encrypted). Therefore, even if its value is changed during retransmission, there is no need for recapsulation, which is advantageous. However, when different PTKs are used in different links, it is necessary to re-encapsulate the MPDU using the PTK of that link during retransmission in different links. In this case, the CCMP encapsulation can follow the conventional method, and the address fields of the MAC header of the (retransmitted) MPDU are used to generate the AAD and nonce fields. However, even in this case, the transmitting MLD can still signal in the CCMP header that it should use the address fields of the MAC header of the (retransmitted) MPDU to generate the AAD and nonce fields, enabling the receiving MLD to correctly decrypt the received protected MPDU.

[0046] Figure 15 shows a flowchart 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, the MPDU is sent to the next process for reception, and then the process ends at step 1528. In step 1504, if it is determined that the MPDU is protected, the process proceeds to step 1506 to determine whether the A2 field of the received MPDU indicates the MAC address that identifies the 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 associated with itself. In step 1506, if it is determined that the A2 field is set to the MAC address that identifies the peer MLD, the process proceeds to step 1508 to determine 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, the process proceeds to step 1510, the constructed AAD and the A2 field of the nonce are set to the MAC address according to the Address subfield of the CCMP header of the MPDU (i.e., according to Table 1408 in FIG. 14), the process proceeds to step 1512, the A1 field of the constructed AAD is set to the MAC address according to the Address subfield of the CCMP header of the MPDU (i.e., according to Table 1408 in FIG. 14), and then the process continues from step 1514. In step 1506, if it is determined that the A2 field of the received MPDU does not indicate the MAC address of the peer MLD, or in step 1508, if it is determined that the Retry subfield of the FC field of the MPDU is not 1, the process proceeds to step 1522, the constructed AAD and the A2 field of the nonce are set to the A2 field of the MPDU, the process proceeds to step 1524, the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then the process continues from step 1514.In step 1514, the remaining fields of AAD and nonce are set as normal. Although not shown in the figure, in the 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 a frame, and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the sender is the AP MLD (or the BSSID of that link if it is different from MLD-TA), or to MLD-RA if the sender is a non-AP MLD (or the BSSID of that link if it is different from MLD-RA). In step 1516, CCMP decapsulation is performed on the MPDU with the constructed AAD and nonce. In step 1518, the decrypted MPDU is sent to the next process for reception, and the process ends at step 1520. As an advantageous effect of the above process, since CCMP encapsulation and decapsulation are different from the conventional method only in the case of retransmission, the changes required to implement this embodiment can be minimized. Further, the receiving MLD can determine whether the received MPDU is a retransmitted MPDU by checking the CCMP header of the MPDU, that is, 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 transmitted to the MLD can have different MAC header formats that convey information specific to multi-link transmission (i.e., information such as the MAC addresses of the transmitting MLD and the receiving MLD). FIG. 16A shows an illustration of a protected MPDU 1600 having a modified MAC header 1602 according to the fourth embodiment. In the fourth embodiment, the Protocol Version (PV) field 1604 can be used to distinguish multi-link frames from legacy frames and PV1 (802.11ah) frames. For example, if the PV field 1604 is set to the value 2, it indicates that the MPDU 1600 is a multi-link frame. Alternatively, in 802.11be, one or more new frame types may be defined to indicate the new MAC header format. Further, the MAC header 1602 includes an ML Control field 1606 that can be used to convey control information related to multi-link transmission. The ML Control field 1606 includes a Control ID subfield 1608, and when this subfield is set to a specific value, the remaining part of the ML Control field conveys the ML Address 1 subfield 1610 and the ML Address 2 subfield 1612.

[0048] The Control ID subfield 1608 indicates an option of the ML Control field 1606. For example, when the value of the Control ID subfield 1608 is 1, the ML Control field 1606 conveys the MAC addresses of the receiving - side MLD / sending - side 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 - side MLD. In this case, for the construction of AAD and nonce during CCMP encapsulation / decapsulation, the MLD addresses conveyed in the multi - link frame are used. For example, the A1 field of the constructed AAD is set to the MLD address of the receiving - side MLD indicated in the ML Address 1 subfield 1610, and the A2 fields of the constructed AAD and nonce are set to the MLD address of the sending - side MLD indicated in the ML Address 2 subfield 1612. Also, when applicable, the A3 field 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., 12 - bit MLD ID) instead of the 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 association record of (the AP MLD), or obtained from the record of the MLD MAC address - MLD ID mapping saved, for example, during the multi - link association procedure).

[0049] Figure 17 shows a flowchart 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, the MPDU is sent to the next process for reception, and then the process ends at step 1726. In step 1704, if it is determined that the MPDU is protected, the process proceeds to step 1706, and it is determined whether the MPDU is using a new frame format by checking, for example, 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, the AAD and nonce A2 fields to be constructed are set to the A2 field of the MPDU, the process proceeds to step 1722, the A1 field of the constructed AAD is set to the A1 field of the MPDU, and then the process continues from step 1712. In step 1706, if it is determined that the PV field has a value of 2, the process proceeds to step 1708, 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, the process proceeds to step 1710, the AAD and nonce A2 fields to be constructed are set to the MLD MAC address corresponding to the ML Address 2 subfield of the ML Control field of the received MPDU, and then the process continues from step 1712. In step 1712, the remaining fields of the AAD and nonce are set as normal.Although not shown in the figure, in the case of an MPDU in which 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 a frame and the BSSID is generally the same as the MAC address of the AP MLD in that link) is also changed to MLD-TA if the sender is the AP MLD (or the BSSID of that link if it is different from MLD-TA), or MLD-RA if the sender is a non-AP MLD (or the BSSID of that link if it is different from MLD-RA). In step 1714, CCMP decapsulation is performed on the MPDU having the constructed AAD and nonce. In step 1716, the decrypted MPDU is sent to the next process for reception, and the process ends in step 1718. As an advantageous effect of the above process, since CCMP encapsulation / decapsulation is still performed based on the MPDU field, the changes required to implement this embodiment can be minimized.

[0050] The techniques described in the first through third embodiments can also function with respect to the Galois / Counter Mode Protocol (GCMP), which is currently used by DMG (Directional multi-gigabit) and EDMG (Enhanced DMG) 802.11 STAs and may be used in the future by sub-7 GHz 802.11 STAs. FIG. 18A shows an illustration 1800 of GCMP encapsulation processing for forming an encrypted MPDU according to the fifth embodiment. CCMP is based on a "chaining" mode of operation that requires in-order processing of 16-byte chunks because the output of one stage is required to be used as the input to the next stage in the chaining cipher mode. In contrast, GCMP uses the same AES cipher engine but incorporates it into a more efficient framework. Compared to CCMP, GCMP has half the number of required encryption 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 understood in FIG. 1800, the GCMP encapsulation processing is substantially the same as the CCMP encapsulation. However, the constructed AAD 1802 used in GCMP encapsulation is the same as the AAD constructed in CCMP encapsulation, but 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. Since it is encrypted by GCMP, the MPDU 1806 includes a GCMP header 1808 instead of a CCMP header. The GCMP header 1808 includes an Options field, and this field conveys an Address field 1809 that is used to signal an address field to be used for constructing the AAD and nonce fields during GCMP decapsulation. FIG. 18C shows an illustration of a GCMP decapsulation process for forming a plaintext MPDU according to the fifth embodiment. Similar to GCMP encapsulation, GCMP decapsulation is also substantially the same as CCMP decapsulation. However, the constructed AAD 1812 used in GCMP decapsulation is the same as the AAD constructed in CCMP decapsulation, but the constructed nonce 1814 used in GCMP decapsulation is different from the nonce used in CCMP decapsulation in that it does not include a Priority field. The receiving-side MLD can determine the address field to be used for constructing the AAD and nonce fields during GCMP decapsulation by referring to the Address field 1809.

[0052] FIG. 19 shows an illustration 1900 of multi-link MPDU transmission using a common packet number (PN) assignment in all links according to various embodiments. It is similar to the multi-link MPDU transmission using separate PTKs as shown in illustration 300 of FIG. 3, but a common PN assignment is used for both Link 1 and Link 2 for transmitting the MPDU. In this example, since the transmission of MPDU 1902 fails on Link 1, it is scheduled to be retransmitted on a different link such as Link 2 instead of Link 1. Since Link 2 uses a different PTK (i.e., Key 2), the MPDU needs to be encapsulated with Key 2 as MPDU 1904, but still uses the same SN = 4 and the same PN = 104 (because a common PN assignment is used for 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 sorting 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. Different from illustration 300 of FIG. 3 where the remaining MPDUs with SN greater than 4 (i.e., the received MPDU 306 with SN = 5, PN = 52 and the received MPDU 308 with SN = 7, PN = 53) are dropped and a replay rejection problem occurs, MPDU 1906 and MPDU 1908 pass the replay check because the PNs are in the correct order after the sorting process. Thus, regardless of the number of PTKs, if a common PN space is used to assign the PNs of the keys and the same PN is used in retransmission, the above-described replay rejection problem is solved.

[0053] Figure 20 shows a schematic diagram of a sender MLD 2000 according to various embodiments. The sender MLD includes a MAC-SAP 2002 for executing a delivery service (DS), a transmission buffer 2004 (used to store unprotected MPDUs and, optionally, protected MPDUs), a sequence number (SN) assignment module 2006, a packet number (PN) assignment module 2008, an MPDU encryption / integrity module 2010, and a retransmission module 2012 (determining the link to use for retransmission and the MAC address to use for constructing the AAD and nonce during the encrypted encapsulation process). Further, the sender MLD 2000 includes two attached STAs or stations, namely STA1 2014a and STA2 2014b. STA1 2014a includes, at the MAC layer 2016a, an MPDU header and CRC creation module 2020a, a transmission (Tx) buffer and block acknowledgment (ACK) control module 2022a, and an aggregation control unit 2024a. Similarly, STA2 2014b includes, at the MAC layer 2016b, an MPDU header and CRC creation module 2020b, a transmission (Tx) buffer and block acknowledgment (ACK) control module 2022b, and an aggregation control unit 2024b. Both STAs include a PHY layer through which transmission is performed via 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 extended. The above architecture is suitable when the same PTK (and / or GTK / IGTK) is used for all links, and even if different PTKs are used for the links, it can help avoid the replay rejection problem as described in the context of FIG. 19 if the same PN space is used for all links. However, in a deployment that selects the use of different PTKs (and / or GTK / IGTK), the MPDU encryption / integrity module 2010 may be moved to each attached STA.When separate PN spaces are used for the links (PN is typically associated with each secret key), the packet number (PN) assignment module 2008 may be further moved to each attached STA.

[0054] Figure 21 shows a schematic diagram of a receiver MLD 2100 according to various embodiments. The receiver MLD includes a MAC-SAP 2102 for executing a distribution service (DS), a replay detection module 2104, an MPDU decoding / integrity module 2106, a block ACK buffering and rearrangement module 2108, and a duplicate detection module 2110. Further, the receiver MLD 2100 includes two attached STAs or stations, namely 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 in 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 in the MAC layer 2116b. Both STAs include PHY layers (i.e., 2118a of STA1 2114a and 2118b of STA2 2114b), and transmissions are made via link 1 (i.e., between STA1 2114a and STA1 2014a in the transmitter MLD 2000) and link 2 (i.e., between STA2 2114b and STA2 2014b in the transmitter MLD 2000) from these PHY layers. It will be understood that the number of links and attached STAs or stations can be further extended. Here, the MPDU decoding / integrity module 2106 is responsible for analyzing the address field in the CCMP / GCMP header during CCMP / GCMP decapsulation to determine the address field used to construct the AAD and nonce fields.

[0055] Figure 22 shows a flowchart 2200 illustrating a method for secure retransmission of MPDU multi-links according to various embodiments. In step 2202, in a first MLD configured to operate with a first plurality of attached STAs, a second MLD configured to operate with a second plurality of attached STAs sets up a Robust Security Network Association (RSNA), where two or more links are established between the STAs of the first plurality of attached STAs and the corresponding STAs of the second plurality of attached STAs. In step 2204, additional authentication data (AAD) and a nonce are constructed, 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, the nonce includes an Address 2 (A2) field, and the SC field of the AAD is based on the SC field of the MPDU. In step 2206, the AAD and nonce are used to cryptographically encapsulate the MPDU to form an encapsulated MPDU. If applicable, the address fields in the CCMP / GCMP header are set to signal the address fields used to generate the fields of the AAD and nonce. In step 2208, the encapsulated MPDU is transmitted as a first transmission from the first MLD to the second MLD over the first link. In step 2210, upon failure of the first transmission, the encapsulated MPDU is retransmitted over the second link without re-executing the cryptographic encapsulation. If applicable, the address fields in the CCMP / GCMP header of the retransmitted MPDU are set to signal the address fields used to generate the fields of the AAD and nonce during the encapsulation process.

[0056] FIG. 23 shows a schematic partial cross-sectional view of a multi-link device 2300 that can be implemented for secure retransmission of multi-links 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 multi-link device 2300 are arranged in multiple layers according to a hierarchical model. In this model, according to the IEEE specification, the lower layer reports to the upper layer and receives instructions from the upper layer. For the sake of brevity, the details of the hierarchical model are not described in this disclosure.

[0058] As shown in FIG. 23, the multi-link device 2300 can include a circuit 2314, at least one wireless transmitter 2302, at least one wireless receiver 2304, and a plurality of antennas 2312 (only one antenna is depicted in FIG. 23 for illustrative purposes for simplicity). The circuit can include at least one controller 2306, and the controller 2306 is designed to execute tasks including controlling communication with one or more other multi-link devices in a MIMO wireless network, and is used when executing under the assistance of software and hardware. The at least one controller 2306 can control at least one transmit signal generator 2308 for generating MPDUs to be transmitted to one or more other multi-link devices through at least one wireless transmitter 2302, and at least one receive signal processor 2310 for processing MPDUs received from one or more other multi-link devices through 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 for constructing AAD and non-frames and for performing CCMP or GCMP encapsulation or decapsulation on MPDUs using the constructed AAD and non-frames. The at least one transmit signal generator 2308 and the at least one receive signal processor 2310 can be stand-alone modules of the multi-link device 2300 that communicate with at least one controller 2306 for the functions described above. Alternatively, the at least one transmit signal generator 2308 and the at least one receive signal processor 2310 may be included in the at least one controller 2306. Those skilled in the art will understand that the arrangement of these functional modules is flexible and can vary according to practical needs and / or requirements. The data processing device, storage device, and other related control devices can be provided on a suitable circuit board and / or chipset.

[0059] In various embodiments, during operation, at least one wireless transmitter 2302, at least one wireless receiver 2304, and at least one antenna 2312 can be controlled by at least one controller 2306. Further, although only one wireless transmitter 2302 is shown, it will be understood that multiple such transmitters (i.e., one transmitter per attached STA or per STA of the multi-link device 2300) may exist.

[0060] In various embodiments, during operation, at least one wireless receiver 2304, together with at least one receive signal processor 2310, forms the receiver of the multi-link device 2300. The receiver of the multi-link device 2300 provides the functions necessary for multi-link communication during operation. Although only one wireless receiver 2304 is shown, it will be understood that multiple such receivers (i.e., one receiver per attached STA or per STA of the multi-link device 2300) may exist.

[0061] The multi-link device 2300 provides the functions necessary for secure retransmission of multi-links during operation. 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 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 during operation. In this case, two or more links are established between the STAs of the first plurality of attached STAs and the corresponding STAs of the second plurality of attached STAs. The circuit constructs additional authentication data (AAD) and a nonce used for cryptographic encapsulation of the MAC protocol data unit (MPDU) to form the encapsulated MPDU. The AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field. The nonce includes an address 2 (A2) field. The SC field of the AAD is based on the SC field of the MPDU. The transmitter 2302 can transmit the encapsulated MPDU as a first transmission to the second MLD on the first link during operation. In case of failure of the first transmission, the encapsulated MPDU can be retransmitted on the second link without re-executing the cryptographic encapsulation.

[0062] The A2 fields of the AAD and the nonce can be set to the media access control (MAC) address identifying the first MLD, and the A1 field of the AAD can be set to the MAC address identifying the second MLD. To protect the MPDU by encryption, either CCMP or GCMP can be used. The MPDU can include identification information of the first MLD and the second MLD. The A2 fields of the AAD and the nonce can be set to the MAC address identifying the first MLD indicated by the identification information, and the A1 field of the AAD can be set to the MAC address identifying the second MLD indicated by the identification information.

[0063] Circuit 2314 can specify the settings of the A1, A2, and A3 fields in the MPDU. This setting indicates whether, upon decryption of the MPDU, the A1, A2, and A3 fields should be set to the MAC addresses identifying the second MLD, the MAC address identifying the first MLD, and the MAC address identifying the AP MLD, respectively, or whether the A1, A2, and A3 fields should be set to the MAC addresses of the associated STAs of the second MLD, the MAC addresses of the associated STAs of the first MLD, and the MAC address identifying the AP MLD, respectively, or whether the A1, A2, and A3 fields should be set to the A1, A2, and A3 fields of the MPDU, respectively, in which case the AP MLD is the first MLD or the second MLD. The setting of the A1, A2, and A3 fields can be indicated in either the CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) header field or the GCMP (Galois / Counter Mode Protocol) header field of the encapsulated MPDU.

[0064] The A2 field of the AAD and nonce can be set to the A2 field of the MPDU, and the A1 field of the AAD can be set to the A1 field of the MPDU. When the first transmission fails, circuit 2314 can further specify the settings of the A1, A2, and A3 fields in the retransmitted MPDU. This setting indicates whether, upon decryption of the retransmitted MPDU, the A1, A2, and A3 fields should be set to the MAC addresses of the associated STAs of the second MLD, the MAC addresses of the associated STAs of the first MLD, and the MAC address identifying the AP MLD, respectively, or whether the A1, A2, and A3 fields should be set to the A1, A2, and 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. Circuit 2314 can set up a Robust Security Network Association (RSNA) during operation with a second MLD configured to operate with a second plurality of attached STAs, where two or more links are established between the STAs of the first plurality of attached STAs and the corresponding STAs of the second plurality of attached STAs. Receiver 2304 can receive an encrypted MAC protocol data unit (MPDU) from the second MLD during operation, where circuit 2314 constructs additional authentication data (AAD) and a nonce used for decrypting the received MPDU. The AAD includes an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field. The nonce includes an address 2 (A2) field. The A2 fields of the AAD and the nonce can be set to any of the A2 field of the MPDU, the MAC address identifying the second MLD, or the MAC address of one of the second plurality of attached STAs. The A1 field of the AAD can be set to any of the A1 field of the MPDU, the MAC address identifying the first MLD, or the MAC address of one of the first plurality of attached STAs. The address 3 (A3) field of the AAD can be set to the BSSID field of the link, the A3 field of the MPDU, or the MAC address of the AP MLD. The SC field of the AAD is based on the SC field of the MPDU.

[0066] Circuit 2314 can cryptographically decapsulate the MPDU received from the second MLD. In this case, the AAD and nonce A2 fields can be set to the MAC address identifying the second MLD, and the A1 field of the AAD can be set to the MAC address identifying the first MLD. The MPDU can be cryptographically decapsulated using either CCMP or GCMP. The MPDU can convey the identification information of the first MLD and the second MLD, and the circuit can cryptographically decapsulate the MPDU by setting the AAD and nonce A2 fields to the MAC address identifying the second MLD indicated in the MPDU, and setting the A1 field of the AAD to the MAC address identifying the first MLD indicated in the MPDU.

[0067] Circuit 2314 can cryptographically decapsulate the received MPDU based on the settings of the A1, A2, and A3 fields indicated in the MPDU. The settings indicate whether, at the time of cryptographic decapsulation, the A1, A2, and A3 fields should be set to the MAC address identifying the first MLD, the MAC address identifying the second MLD, and the MAC address identifying the AP MLD, respectively, or whether the A1, A2, and 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, and the MAC address identifying the AP MLD, respectively, or whether the A1, A2, and A3 fields should be set to the A1, A2, and 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 either the CCMP header or the GCMP header of the MPDU received from the second MLD.

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

[0069] The present disclosure can be implemented by software, hardware, or software that collaborates with hardware. Each functional block used in the description of each of the above-described embodiments can be implemented 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 individual chips, or one chip may be formed to include part or all of the functional blocks. The LSI can include a data input / output section coupled to itself. Here, the LSI may be referred to as 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 it may be implemented using an application-specific circuit, a general-purpose processor, or a special-purpose processor. Further, a programmable FPGA (Field Programmable Gate Array) after the manufacture of the LSI, or a reconfigurable processor capable of changing the connection and setting of circuit cells arranged inside the LSI may be used. The present disclosure can be implemented as digital processing or analog processing. With the progress of semiconductor technology and other derivative technologies, when future integrated circuit technology replaces the LSI, it is also possible to integrate functional blocks using that future integrated circuit technology. Biotechnology can also be applied.

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

[0071] The communication device can include a transceiver and a processing / control circuit. The transceiver can include a receiver and a transmitter, and / or can function as a receiver and a transmitter. The transceiver as a transmitter and a receiver can 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 communication devices include telephones (e.g., cellular (mobile) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smartwatches, tracking devices), gaming consoles, e-book readers, telemedicine / telehealth (remote medical / pharmaceutical) devices, vehicles that provide communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

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

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

[0075] The communication device can include devices such as controllers and sensors coupled to a communication device that performs the communication functions described in this disclosure. For example, the communication device can include a controller or sensor that generates a control signal or data signal used by a communication device that performs the communication function of the communication device.

[0076] The communication device can further include infrastructure facilities, such as base stations, access points, and any other device, apparatus, or system that communicates with or controls devices such as those in the non-limiting examples above.

[0077] As a non-limiting example of an architecture (e.g., the architecture shown in FIGS. 20 and 21), the MLD of the present disclosure can be logically implemented by a plurality of separate communication devices that share a common MAC data service interface to an upper layer.

[0078] Non-limiting examples of stations can include stations included in a first plurality of stations belonging to a multi-link station logical entity (i.e., such as an MLD), and 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 an upper layer, and the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0079] Therefore, it can be understood that embodiments of the present disclosure provide a communication device and a communication method operating on a plurality of links in order to fully realize the throughput gain of multi-link communication, particularly in secure retransmission of multi-links.

[0080] In the detailed description so far of this embodiment, exemplary embodiments have been presented, but it should be understood that there are a vast number of variations. Furthermore, it should be understood that the exemplary embodiments are examples and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the detailed description so far provides a convenient guide for those skilled in the art to implement the exemplary embodiments. It should be understood that various changes can be made to the steps of the operations, the functions and arrangements of the methods, and the modules and structures of the devices described in the exemplary embodiments without departing from the scope of the subject matter described in the appended claims.

Claims

1. A receiving multi-link device (MLD), a receiver for receiving an encapsulated MAC protocol data unit (encapsulated MPDU) from a transmitting MLD via a first link; a circuit for constructing additional authentication data (AAD) and a nonce, and decapsulating the encapsulated MPDU using the AAD and the nonce to obtain a plaintext 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, and the nonce including an A2 field set to the MAC address of the sending MLD; The receiving MLD comprises:

2. When reception of the encapsulated MPDU on the first link fails, the receiving unit receives the encapsulated MPDU retransmitted on a second link different from the first link, and the retransmitted encapsulated MPDU is not encapsulated with a new packet number (PN); The receiving MLD according to claim 1.

3. A common packet number (PN) is used in the initial transmission on the first link and the retransmission on the second link. The receiving MLD according to claim 2.

4. a second plurality of affiliated stations (STAs) capable of establishing one or more links with a first plurality of affiliated stations (STAs) associated with the transmitting MLD; The receiving 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 receiving MLD according to claim 1.

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

7. Either CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) or GCMP (Galois / Counter Mode Protocol) is used to cryptographically protect the MPDU before it is encapsulated. The receiving MLD according to claim 1.

8. A communication method for a receiving multi-link device (MLD), comprising: receiving an encapsulated MAC protocol data unit (encapsulated MPDU) on a first link from a transmitting MLD; constructing additional authentication data (AAD) and a nonce, and using the AAD and the nonce to decapsulate the encapsulated MPDU to obtain a plaintext 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, and the nonce including an A2 field set to a MAC address of the sending MLD; Communication methods.

9. if reception of the encapsulated MPDU on the first link fails, receiving a retransmitted encapsulated MPDU on a second link different from the first link, the retransmitted encapsulated MPDU not being encapsulated with a new packet number (PN); The communication method according to claim 8.

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

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

12. 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 8.

13. A common packet number (PN) is used for initial transmission and retransmission across multiple links; The communication method according to claim 8.

14. Either CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) or GCMP (Galois / Counter Mode Protocol) is used to cryptographically protect the MPDU before it is encapsulated. The communication method according to claim 8.

15. 1. An integrated circuit for a receiving multi-link device (MLD), comprising: receiving an encapsulated MAC protocol data unit (encapsulated MPDU) on a first link from a transmitting MLD; constructing additional authentication data (AAD) and a nonce; decapsulating the encapsulated MPDU using the AAD and the nonce to obtain a plaintext 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, and the nonce including an A2 field set to a MAC address of the sending MLD; An integrated circuit that controls

Images