Communication device and communication method for secure retransmission of multilink signals

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 given rise to issues related to communication devices and issues 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, such IEEE 802.11 devices employ security protocols, including but not limited to the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or the Galois / counter mode protocol (GCMP), to provide data confidentiality, authentication, integrity, and replay protection for data frames, individually addressed robust management frames, and group-addressed management frames. [Overview of the project] [Problems that the invention aims to solve]

[0005] Non-limiting embodiments of this disclosure contribute to providing devices and methods for secure retransmission of multilinks. [Means for solving the problem]

[0006] One non-limiting and exemplary embodiment is a first multilink device (MLD) configured to operate with a first plurality of affiliated STAs (Station), and a circuit that, when in operation, sets up a robust security network association (RSNA) with a second MLD configured to operate with a second plurality of affiliated STAs, wherein two or more links are established between the STAs of the first plurality of affiliated STAs and the corresponding STAs of the second plurality of affiliated STAs, and the circuit constructs Additional Authentication Data (AAD) and a nonce used for cryptographic encapsulation of a MAC protocol data unit (MPDU) to form an encapsulated MPDU, wherein the AAD comprises an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (Sequence To facilitate providing a first multilink device (MLD) comprising: a circuit including a Control)(SC) field, a nonce including an A2 field, and the SC field of the AAD being based on the SC field of the MPDU; and a transmitter that, when in operation, transmits the encapsulated MPDU to a second MLD on the first link as the first transmission, and if the first transmission fails, retransmits the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0007] Another non-limiting and exemplary embodiment is a method for retransmitting an MPDU in multilink communication, comprising the steps of: setting up a Robust Security Network Association (RSNA) with a first MLD configured to operate with a first plurality of attached STAs, and a second MLD configured to operate with a second plurality of attached STAs, 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 an A2 field, and the SC field of the AAD is based on the SC field of the MPDU; and cryptographically encapsulating the MPDU using the AAD and the nonce. To facilitate providing a method comprising the steps of: forming an encapsulated MPDU (encapsulating); transmitting the encapsulated MPDU from a first MLD to a second MLD on a first link as the first transmission; and, if the first transmission fails, retransmitting the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0008] It should be noted that general or specific embodiments may be implemented as systems, methods, integrated circuits, computer programs, storage media, or any selective combination thereof. Further benefits and advantages of the disclosed embodiments will become apparent from this specification and the drawings. Benefits and / or advantages may be obtained individually by the various embodiments and features of this specification and the drawings, and not all of them are required to obtain one or more such benefits and / or advantages. [Brief explanation of the drawing]

[0009] The attached figures, along with the following detailed description, are incorporated herein and constitute part of it, illustrating various embodiments and illustrating the various principles and advantages of these embodiments. Throughout the separate figures, similar reference figures refer to identical or functionally similar elements. [Figure 1] The following describes the steps for processing Media Access Control (MAC) protocol data units (MPDUs) using CCMP according to various embodiments. [Figure 2A] This shows illustrations of protected MPDUs in various embodiments. [Figure 2B] This shows illustrations of the MAC header of a protected MPDU in various embodiments. [Figure 3] This diagram illustrates multilink MPDU transmission using separate PTKs (Pairwise Temporal Keys) for each link. [Figure 4] This diagram illustrates multilink MPDU transmission using a single PTK across all links, according to various embodiments. [Figure 5] This diagram illustrates the CCMP encapsulation process for forming an encrypted MPDU using various embodiments. [Figure 6] This diagram illustrates how an unprotected MPDU is retransmitted over a different link according to the first embodiment. [Figure 7A] This diagram illustrates the Additional Authentication Data (AAD) frame according to the first embodiment. [Figure 7B] This diagram illustrates a nonce frame according to the first embodiment. [Figure 8] This diagram illustrates the CCMP decapsulation process for forming a plaintext MPDU according to the first embodiment. [Figure 9] This shows a flowchart of the initial transmission of the MPDU according to the first embodiment. [Figure 10]Shows the flowchart of the retransmission of MPDU according to the first embodiment. [Figure 11] Shows the flowchart of the reception of MPDU according to the first embodiment. [Figure 12] Shows the illustration of the protected MPDU according to the second embodiment. [Figure 13] Shows the flowchart of the reception of MPDU according to the second embodiment. [Figure 14] Shows the illustration of the protected MPDU according to the third embodiment. [Figure 15] Shows the flowchart of the reception of MPDU according to the third embodiment. [Figure 16] Shows the illustration of the protected MPDU according to the fourth embodiment. [Figure 17] Shows the flowchart of the reception of MPDU according to the fourth embodiment. [Figure 18A] Shows the illustration of the Galois / Counter Mode Protocol (GCMP) encapsulation process for forming an encrypted MPDU according to the fifth embodiment. [Figure 18B] Shows the illustration of the GCMP protected MPDU according to the fifth embodiment. [Figure 18C] Shows the illustration of the GCMP decapsulation process for forming a plaintext MPDU according to the fifth embodiment. [Figure 19] Shows the illustration of the multi-link MPDU transmission using the packet number (PN: Packet Number) assignment common to all links according to various embodiments. [Figure 20] Shows the schematic diagram of the sender MLD 2000 according to various embodiments. [Figure 21] Shows the schematic diagram of the receiver MLD 2100 according to various embodiments. [Figure 22] Shows the flowchart 2200 illustrating the method of secure retransmission of multi-link according to various embodiments. [Figure 23] FIG. 1 schematically shows a partial cross-sectional view of one of the attached STAs of the multi-link device 2300 that can be implemented for secure retransmission of multi-links according to the first to fifth embodiments.

[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 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, a MAC header is added to data such as a MAC service data unit (MSDU) or a management MPDU (MMDPU) to form an MPDU. In step 2, the MAC header is separated from the MPDU and a CCMP header is created. In step 3, a message integrity code (MIC) is calculated and appended to the end. The MIC is used for authentication and integrity checking. In step 4, the combination of the data and the MIC is encrypted to form a ciphertext. Next, the CCMP header is added before the ciphertext. In step 5, the MAC header is restored by adding the MAC header before the CCMP header. In step 6, a cyclic redundancy check (CRC) is calculated for the entire MPDU and appended to the end of the MPDU to form a protected or encrypted MPDU.

[0013] Figure 2A illustrates the protected MPDU 200 in various embodiments. The protected MPDU 200 includes a MAC Header field 202, a CCMP Header field, a Data (PDU) field, an MIC field, and an FCS field. As described in Figure 1, the Data (Payload) field and the MIC field are encrypted. The CCMP Header field includes the PN0 field, PN1 field, Reserve (Rsvd) field, Key ID octet field, PN2 field, PN3 field, PN4 field, and PN0 field. The Key ID octet field includes the Reserve (Rsvd) subfield, the Ext IV subfield, and the Key ID subfield.

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

[0015] Generally, the contents of the A1, A2, and A3 address fields of a data frame depend on the "To DS" and "From DS" subfields of the FC field in the MAC header. This is shown in Table 1 below. [Table 1]

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

[0018] In multilink operation in next-generation wireless LANs such as 802.11be, it may be permitted to transmit MPDUs with the same TID (Traffic ID) on different links simultaneously. However, such multilink transmissions can lead to unexpected behavior, as described below, when security encapsulation is applied to the MPDU. When it is possible to transmit MPDUs with the same TID on different links simultaneously, in order to enable the receiving MLD to correctly sort MPDUs received on different links, the same Sequence Number (SN) space can be used, regardless of the link actually used for transmission, to assign an SN to the MSDU or MMPDU conveyed in the MPDU. During the initial setup of the link between the AP MLD and the non-AP MLD (e.g., immediately after the multilink 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 MPDUs can be derived from the same PMK for different links. It is possible to generate separate PTKs and separate GTKs / IGTKs for use on different links. Figure 3 illustrates a multilink MPDU transmission using separate PTKs for each link. In this example, the sender MLD sends MPDUs to the receiver MLD over link 1 and link 2. Link 1 uses PTK key 1, and link 2 uses a different PTK key 2. Also, while the MPDU transmissions on both links use a common sequence number (SN), the packet number (PN) counters used on each link are different.For example, the PN counter of an MPDU transmitted via link 1 starts at PN=100, while the PN counter of an MPDU transmitted via link 2 starts at PN=51.

[0019] In this example, MPDU 302 on link 1 failed to transmit and is scheduled to be retransmitted on another link, such as link 2, instead of link 1. Since link 2 uses a different PTK (i.e., key 2), MPDU 302 needs to be encapsulated as MPDU 304 using key 2 and a new PN=54 (because it is scheduled to be retransmitted after MPDU 308 with PN=53 has been transmitted), although 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 sorted down to SN=4, i.e., 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 an SN greater than 4 and a PN less than 54 (i.e., received MPDU 306 with SN=5, PN=52 and received MPDU 308 with SN=7, PN=53) are dropped, leading to an unintended replay rejection problem.

[0020] Furthermore, even if a single PTK is used across all links, the replay rejection problem still arises if the retransmitted MPDU is re-encapsulated with a new PN. This can be seen in Figure 4, which illustrates a multilink MPDU transmission using a single PTK across all links in various embodiments. Similar to Figure 3, the sender MLD transmits the MPDU to the receiver MLD over link 1 and link 2. The difference is that the same PTK key 1 is used on both link 1 and link 2. As a result, both links use a common SN assignment and a common PN assignment.

[0021] In this example, MPDU 402 with SN=4 and PN=104 failed to transmit on Link 1 and 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, MPDU 402 needs to be reencapsulated as MPDU 404 using a new PN=108 (because it is scheduled to be retransmitted after MPDU 408 with PN=107 has been transmitted), although 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 sorted down to SN=4, i.e., 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 an SN greater than 4 and a PN less than 108 (i.e., received MPDU 406 with SN=5 and PN=105, and received MPDU 408 with SN=7 and PN=107) are dropped, leading to the replay refusal problem.

[0022] Furthermore, while IEEE 802.11be may require the use of separate MAC addresses for each link, it may also permit the use of 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 another link using the same A2 (i.e., =TA) and the same PN (i.e., the PN remains the same across retransmissions to avoid the order of received PNs being shifted after SN sorting by the receiver MLD), the problem (security flaw) 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. Furthermore, CCM requires a unique nonce value for each frame protected by a given temporary key, and for this purpose, CCM uses a 48-bit packet number (PN). Reusing the PN with the same temporary key invalidates all security guarantees." In other words, reusing the same PN in retransmissions over different links to avoid the replay refusal problem solves the issue but can introduce security vulnerabilities. It should be noted that, as a prerequisite, the retransmitted MPDU must be re-encapsulated when retransmitted over a different link. This disclosure provides several options for avoiding such security-related problems arising from multilink transmission.

[0023] Figure 5 illustrates the CCMP encapsulation process for forming an encrypted MPDU according to the IEEE 802.11 specification. Specifically, 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, while Nonce 504 includes the Nonce Flags field, A2 field, and PN field. The contents of the A1, A2, and A3 fields of AAD 502 and the contents of the A2 field of Nonce 504 are extracted from the A1, A2, and A3 fields of the MPDU being encapsulated (or decapsulated in the case of decapsulation of an encrypted MPDU).

[0024] In single-link 802.11 STA, protected MPDUs are retransmitted with the following minimal modifications: - The Retry subfield (bit 11) of the FC field is set to 1. However, the Retry subfield of the FC field and some other subfields are generally masked to 0 during CCMP encapsulation. - CRC is recalculated, but FCS is not an input to CCMP encapsulation. - The MPDU is encapsulated only during the initial transmission and not during subsequent transmissions. However, in the case of MLDs, the rules for retransmitting protected MPDUs may depend on the link used to retransmit the MPDU. If the same link is used for retransmission, the MPDU is encapsulated only during the initial transmission and not during retransmission. If a different link is used for retransmission (assuming the MAC addresses of the attached STAs at both ends of the link are different), the MPDU must be re-encapsulated before retransmission (it is also possible to use the same PN to avoid replay rejection issues). However, reusing the PN with the same security key can lead to security vulnerabilities.

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

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

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

[0028] In the first embodiment, during the initial transmission of a protected MPDU, the MLD MAC address is used instead of the MAC address of the sender / receiver attached STA (i.e., the A1 and A2 fields of the transmitted MPDU) to generate the AAD and nonce when the protected MPDU is CCMP encapsulated to the recipient MLD. Figure 7A illustrates the AAD 700 according to the first embodiment. Similar to the AAD 502, the A1 field 702 and A2 field 704 of the AAD 700 are set to the MAC address of the receiving MLD and the MAC address of the sending MLD (i.e., MLD-RA and MLD-TA), respectively, instead of the MAC addresses of the receiver / sender attached STA shown in the A1, A2, and A3 fields of the transmitted protected MPDU. In MPDUs where A3 is set to the BSSID (e.g., data frames or management frames with To DS / From DS=0), if the BSSID of link 2 is different, A3 (which is set to the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA if the sender is an AP MLD (or the BSSID of the link if it is different from the MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of the link if it is different from the MLD-RA). Figure 7B illustrates nonce 706 according to the first embodiment. Similar to nonce 504, but the A2 field 708 of nonce 706 is set to the MAC address of the sending MLD (i.e., MLD-TA) instead of the MAC address of the sending attached STA shown in the A2 field of the protected MPDU being sent. The protected MPDU can be stored in the sending MLD's memory until it receives an acknowledgment of successful reception of the MPDU from the receiving MLD, or until the MSDU's lifetime ends.

[0029] If transmission of the protected MPDU according to the first embodiment fails, the protected MPDU is retrieved from memory (if saved during the initial transmission), the Retry subfield of the FC field is set to 1, the A1 and A2 fields of the MAC header are swapped, a new CRC is added, and then it is retransmitted. This is advantageous because the AAD and nonce remain the same regardless of the per-link MAC address used on the link, so there is no need to perform CCMP encapsulation again. In fact, MAC header fields whose content may change during retransmission (e.g., duration / ID field, HT control field) are not included in the AAD and therefore do not affect the encapsulation process. For similar reasons, some subfields of the Frame Control field are masked to 0. i) The subtype subfield (bits 4, 5, and 6) of the data frame is masked to 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: - All data frames containing the QoS Control field are masked to 0. - It will not be masked otherwise.

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

[0031] During CCMP decapsulation, regardless of the link used to receive the protected MPDU (from the other MLD), the MLD MAC address is used instead of the MAC addresses of the sender / receiver attached STAs (i.e., the A1 and A2 fields of the received MPDU) to generate the AAD and nonce. Figure 8 shows a diagram 800 of the CCMP decapsulation process used by the receiving MLD to form a plaintext MPDU according to the first embodiment. The AAD 802 and nonce 810 are constructed to decapsulate the protected or encrypted MPDU. According to the first embodiment, the A1 field 804 and A2 field 806 of the AAD 802 are set to the MAC address of the receiving MLD (i.e., MLD-RA) and the MAC address of the sender MLD (i.e., MLD-TA), respectively. In MPDUs where A3 is set as the BSSID (e.g., data frames or management frames with To DS / From DS=0), if the BSSID of Link 2 is different, A3 (which is set as the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA if the sender is an AP MLD (or the BSSID of that link if it is different from MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of that link if it is different from MLD-RA). Furthermore, the A2 field 808 of nonce 810 is set to the MAC address of the sending MLD (i.e., MLD-TA). To verify the identity of the sending STA, the A2 field of the received MPDU is checked before replacing it with the MLD's MAC address (i.e., the A2 field of the received MPDU should indicate the MAC address of the sending STA belonging to the other MLD). The A1 field of the received MPDU has already been checked during the received frame filtering.

[0032] In the retransmission of a protected MPDU according to the first embodiment, it is assumed that the MLD MAC address is known to both the transmitting and receiving MLDs (e.g., exchanged during the association / link activation procedure). Furthermore, it is assumed that the same PTK is used on all links. If different PTKs are used on different links, the MPDU must be re-encapsulated before retransmission on the different links. If the MAC address is the same per link and a single PTK is used on all links, the retransmission rules are the same as 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 address to be used in the A1, A2 fields (and A3 field, if applicable) when constructing the AAD and nonce (e.g., during a 4-way group key handshake or using some management frame exchange). This may also be useful for single-link STAs using dynamic MAC addresses (e.g., MAC randomization) where the address changes between the initial transmission and retransmission. Instead of various address fields in the protected MPDU, the provided MAC address is used to construct the AAD and nonce. If the A1 and A2 fields (and A3 field, if applicable) used for the AAD and nonce are always fixed, CCMP decapsulation will succeed even if the MAC address of the retransmitted frame (either A1, A2, or both (and A3, if applicable)) changes.

[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 for transmission to the receiving MLD (e.g., channel access), and the process ends in step 920. If it is determined in step 904 that the MPDU needs to be protected, the process proceeds to step 906, where the A1 field of the constructed AAD is set to the MAC address of the receiving MLD. In step 908, the A2 field of the AAD and the constructed nonce are set to the MAC address of the local MLD, i.e., the sending MLD. Although not shown in the diagram, in MPDUs where A3 is set as the BSSID (e.g., data frames or management frames with To DS / From DS=0), if the BSSID of Link 2 is different, A3 (which is set as the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA (or the BSSID of the link if it is different from MLD-TA) if the sender is an AP MLD, or to MLD-RA (or the BSSID of the link if it is different from MLD-RA) if the sender is not an AP MLD. In step 910, the remaining fields of AAD and nonce are set as usual, i.e., according to the IEEE 802.11 standard. In step 912, CCMP encapsulation of the MPDU is performed to generate a protected or encrypted MPDU. In step 914, the protected MPDU is sent to the next process for transmission to the receiver MLD, and the process ends in step 916.

[0035] Figure 10 shows a flowchart 1000 for retransmitting an MPDU according to the first embodiment. In step 1002, it is determined that the MPDU needs to be retransmitted after the initial transmission failure (for example, upon receiving a BlockAck frame indicating the initial transmission failure). In step 1004, the stored MPDU is retrieved from memory. In step 1006, the Retry subfield of the FC field of the MPDU is set to 1. In step 1008, it is determined whether the MPDU is a protected or unprotected MPDU. If it is an unprotected MPDU, the process proceeds to step 1018 to determine whether the MPDU should be retransmitted over the same link as the initial transmission. If it is determined that the MPDU should be retransmitted over the same link as the initial transmission, the process continues from step 1016. If, instead, it is determined that the MPDU should be retransmitted over a different link, the process proceeds to step 1020 to determine whether the TA or RA is different on the new link used for retransmission. If it is determined that the TA or RA of the new link is the same as that of the link in the initial transmission, processing continues from step 1016. Otherwise, processing proceeds to step 1022, where the A1 and / or A2 fields are set to the new RA and / or TA of the new link, and then processing continues from step 1016.

[0036] If, in step 1008, it is determined that the MPDU is protected, the process proceeds to step 1010 to determine whether to retransmit the protected MPDU over the same link as the initial transmission. If it is determined that the same link should be used for retransmission, the process continues from step 1016. Otherwise, the process proceeds to step 1012 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 is the same on the new link compared to the link used for the initial transmission, the process continues from step 1016. Otherwise, the process proceeds to step 1014, where the A1 and / or A2 fields are set to the new RA and / or TA on the new link, and then the process continues from step 1016. Furthermore, from step 1016 onward, the MPDU is sent to the next step for retransmission, and the process ends in step 1028. It is worth noting that the process for retransmitting protected and unprotected MPDUs is exactly the same (i.e., regardless of the result of step 1008). Although not shown in the diagram, in MPDUs where A3 is set as the BSSID (e.g., data frames or management frames with To DS / From DS=0), if the BSSID of link 2 is different, A3 will be set to the BSSID of link 2 (the BSSID is generally the same as the MAC address of the AP MLD on that link).

[0037] Figure 11 shows a flowchart 1100 of MPDU reception according to the first embodiment. In step 1102, the MPDU is received. In step 1104, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1124, where the MPDU is sent to the next process for receiving, and then the process ends in step 1126. If it is determined in step 1104 that the MPDU is protected, the process proceeds to step 1106, where it is determined whether the A2 field of the received MPDU indicates a MAC address that identifies the peer MLD. In the case of a non-AP MLD, the peer MLD refers to the AP MLD to which it is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD to which it is associated. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the remote MLD, the conventional decapsulation procedure is used, and the process proceeds to step 1120, setting the A2 fields of the constructed AAD and nonce to the A2 field of the MPDU, then proceeding to step 1122, setting the A1 field of the constructed AAD to the A1 field of the MPDU (and A3 if applicable), and then the process continues from step 1112. If it is determined in step 1106 that the A2 field is set to the MAC address that identifies the remote MLD, the process proceeds to step 1108, setting the A1 field of the constructed AAD to the MAC address of the receiving MLD, then proceeding to step 1110, setting the A2 fields of the constructed AAD and nonce to the MAC address of the sending MLD, and then the process continues from step 1112. Although not shown in the diagram, in MPDUs where A3 is set as the BSSID (e.g., data frames or management frames with To DS / From DS=0), if the BSSID of Link 2 is different, A3 (which is set as the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) will also be changed to MLD-TA if the sender is an AP MLD (or the BSSID of that link if it is different from the MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of that link if it is different from the MLD-RA).In step 1112, the remaining fields of the AAD and nonce are set as usual. In step 1114, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and nonce. In step 1116, the decrypted MPDU is sent to the next processing for reception, and the processing ends in step 1118. A favorable effect of the above processing is that the encrypted MPDU can be retransmitted over a different link without having to re-perform CCMP encapsulation, and the receiving MLD can still correctly decapsulate the MDPU.

[0038] According to the second embodiment, during the CCMP encapsulation of the protected MPDU in the initial transmission, the AAD and nonce are generated using the MLD MAC address, or the A1 and A2 fields of the transmitted protected MPDU, or the link-specific MAC address of any attached STA, and the same protected MPDU can be retransmitted on a different link without performing CCMP encapsulation again (after setting the Retry subfield in the FC and modifying some of the other fields mentioned above). This is made possible by modifying 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, depending on the deployment scenario; for example, if the same PTK is used on all links, the MLD MAC address can be used as described in the first embodiment. Alternatively, the AAD and nonce can be generated using the link-specific MAC address of the link used for the original transmission of the MPDU, and if the MPDU is later retransmitted over a different link, a signal in the CCMP header can instruct the receiving MLD to use the link-specific MAC address of the link used for the original transmission. Similarly, if the link-specific MAC addresses of the two links are the same, the sending MLD can signal that the address field of the MAC header of the MPDU should be used to generate the AAD and nonce. However, if different PTKs are used for different links, the MPDU must be re-encapsulated using the PTK of that link when retransmitted over a different link. In this case, CCMP encapsulation can follow the conventional method, generating the AAD and nonce fields using the address field of the MAC header of the (retransmitted) MPDU. However, even in this case, the sending MLD can signal in the CCMP header that the address field of the MAC header of the (retransmitted) MPDU should be used to generate the AAD and nonce fields.Thus, by signaling the MAC address in the CCMP header, the receiving MLD can correctly decapsulate the received protected MPDU (either during the initial transmission or retransmission), regardless of the method used by the sending MLD to encapsulate the MPDU. Figure 12 illustrates a protected MPDU 1200 according to a second embodiment. In this embodiment, the CCMP header 1202 of the MPDU 1200 includes a new Options field 1204, which contains a Reserve (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. Referencing Table 1208, if the value of the Address subfield 1206 is set to 0, the A1, A2, and A3 fields of the AAD and Nonce are set to the A1, A2, and A3 fields of the MAC header 1210, respectively. If the value of the Address subfield 1206 is set to 1, the A1, A2, and A3 fields of the AAD and Nonce are set to the MAC addresses of the receiving MLD and transmitting MLD, respectively. If the value of the Address subfield 1206 is set from 2 to n, the A1, A2, and A3 fields of the AAD and Nonce are set to the per-link MAC addresses of the attached STAs associated with links 1 to (n-1). Furthermore, the A1, A2, and A3 fields of the MAC header 1210 are set to the MAC addresses of the transmitting links (i.e., TA1 / TA2, RA1 / RA2) as usual, and A3 is set to the BSSID of the link.

[0039] During CCMP decapsulation, the receiving MLD uses the Address subfield 1206 to determine the MAC address for generating the AAD and nonce. In this case, it is assumed that the per-link MAC addresses for all valid links are known to both the sending and receiving MLDs (e.g., exchanged during the association / link enablement procedure). According to the second embodiment, when a failed MPDU is retransmitted (after setting the FC's Retry subfield to 1, swapping the A1, A2, and A3 fields of the MAC header (and A3 if the link's BSSID 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 for all links. Address information could be indicated using other fields in the MAC header 1210, but it is natural to choose the CCMP header 1202 because this field is used to indicate security-related information, and the CCMP header 1202 is not included in the encapsulation process and is sent in plain text. Furthermore, Link 1 to Link (n-1) in Table 1208 represents the (n-1)th link from the first link set up between the two MLDs, and does not necessarily have to be the same value as the link ID assigned to the link, but it can be the same value. For example, Link 1 represents Link ID 2, Link 2 represents Link ID 4, and so on. However, if different PTKs are used for different links, when retransmitting on a different link, the MPDU must be re-encapsulated using the PTK of that link. In this case, CCMP encapsulation can follow the conventional method, generating the AAD and nonce fields using the address field of the MAC header of the (retransmitted) MPDU. However, even in this case, the sending MLD can still signal in the CCMP header that it should use the address field of the MAC header of the (retransmitted) MPDU to generate the AAD and nonce fields, allowing the receiving MLD to correctly decapsulate the received protected MPDU.

[0041] Figure 13 shows a flowchart 1300 of MPDU reception according to the second embodiment. In step 1302, the MPDU is received. In step 1304, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1324, where the MPDU is sent to the next process for reception, and then the process ends in step 1326. If it is determined in step 1304 that the MPDU is protected, the process proceeds to step 1306, where it is determined whether the A2 field of the received MPDU indicates 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 it is associated. In the case of an AP MLD, the peer MLD refers to the non-AP MLD to which it is associated. If it is determined that the A2 field of the received MPDU does not indicate the MAC address of the remote MLD, the conventional decapsulation method is used, and the process proceeds to step 1320, where the A2 fields of the constructed AAD and nonce are set as the A2 field of the MPDU, then proceeds to step 1322, where the A1 field of the constructed AAD is set as the A1 field of the MPDU, and then the process continues from step 1312. If it is determined in step 1306 that the A2 field is set as the MAC address that identifies the remote MLD, the process proceeds to step 1308, where the A2 fields of the constructed AAD and nonce are set as the MAC address according to the Address subfield of the MPDU's CCMP header, then proceeds to step 1310, where the A1 field of the constructed AAD is set as the MAC address according to the Address field of the MPDU's CCMP header, and then the process continues from step 1312.

[0042] In step 1312, the remaining fields of the AAD and nonce are set as usual. Although not shown in the diagram, in MPDUs where A3 is set to the BSSID (e.g., a data frame or management frame with To DS / From DS=0), if the BSSID of link 2 is different, A3 (which is set to the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA if the sender is an AP MLD (or the BSSID of the link if it is different from the MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of the link if it is different from the MLD-RA). In step 1314, CCMP decapsulation is performed on the protected MPDU with the constructed AAD and nonce. In step 1316, the decrypted MPDU is sent to the next processing for reception, and the processing ends in step 1318. In this second embodiment, the receiver MLD always checks the MPDU's CCMP header to determine the settings of the A1, A2, and A3 fields of the constructed AAD and the A2 field of the nonce, regardless of whether it is the initial transmission or a retransmission. This allows the sending MLD to determine the address value more flexibly in CCMP encapsulation, which is advantageous.

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

[0044] Figure 14 illustrates a protected MPDU 1400 according to a third embodiment. In this embodiment, the CCMP header 1402 of the MPDU 1400 includes a new Options field 1404 containing a Reserve (Rsvd) subfield and an Address subfield 1406. During CCMP decapsulation, if the Retry subfield of the FC field in the MAC header field 1410 has a value of 1 (i.e., indicating that the received MPDU is a retransmission), the receiving MLD uses the Address field 1406 to determine the MAC address for generating the AAD and Nonce. 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 the respective Address fields in the MAC header field 1410. For example, if the A1 field of MPDU 1400 indicates RA1 (or RA2), the A1 field of the constructed AAD is set to RA1 (or RA2); if the A2 field of 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. Additionally, a value of 0 in the Address subfield 1406 indicates that the retransmission of MPDU 1400 is on the same link as the initial transmission (or that the per-link MAC address on a different link is the same as that on the link used for the initial transmission), allowing the receiving MLD to decapsulate the protected MPDU using conventional methods. If the value of the Address subfield 1406 is set to 1 through 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 link 1 through 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. Additionally, the value of the Address subfield 1406 from 1 through n also indicates that the retransmission is on a different link than the initial transmission.On the other hand, if the value of the Retry subfield is 0 (i.e., indicating that the received MPDU is the first transmission), the AAD and nonce are generated using the A1, A2, and A3 fields of MAC header field 1410 (conventional behavior).

[0045] This embodiment assumes that the same PTK is used on all links, and that the MPDU's CCMP header is transmitted in plaintext (i.e., unencrypted), thus having the advantage of not requiring re-encapsulation even if its value is changed during retransmission. However, if different PTKs are used on different links, the MPDU must be re-encapsulated using the PTK of that link during retransmission on a different link. In this case, CCMP encapsulation can follow conventional methods, generating the AAD and nonce fields using the address field of the MAC header of the (retransmitted) MPDU. However, even in this case, the sending MLD can still signal in the CCMP header that the AAD and nonce fields should be generated using the address field of the MAC header of the (retransmitted) MPDU, allowing the receiving MLD to correctly decapsulate the received protected MPDU.

[0046] Figure 15 shows a flowchart 1500 for receiving an MPDU according to the third embodiment. In step 1502, the MPDU is received. In step 1504, it is determined whether the MPDU is protected. If the MPDU is not protected, the process proceeds to step 1526, where the MPDU is sent to the next process for reception, and then the process ends in step 1528. If it is determined in step 1504 that the MPDU is protected, the process proceeds to step 1506, where it is determined whether the A2 field of the received MPDU indicates the MAC address that identifies the remote MLD. In the case of a non-AP MLD, the remote MLD refers to the AP MLD to which it is associated. In the case of an AP MLD, the remote MLD refers to the non-AP MLD to which it is associated. If it is determined in step 1506 that the A2 field is set to the MAC address that identifies the remote MLD, the process proceeds to step 1508, where it is determined whether the Retry subfield of the FC field of the MPDU is set to 1. If it is determined that the Retry subfield is set to 1, the process proceeds to step 1510, where the A2 field of the constructed AAD and nonce is set to the MAC address according to the Address subfield of the MPDU's CCMP header (i.e., according to Table 1408 in Figure 14), then proceeds to step 1512, where the A1 field of the constructed AAD is set to the MAC address according to the Address subfield of the MPDU's CCMP header (i.e., according to Table 1408 in Figure 14), and then the process continues from step 1514. If, in step 1506, it is determined that the A2 field of the received MPDU does not indicate the MAC address of the other MLD, or if, in step 1508, it is determined that the Retry subfield of the FC field of the MPDU is not 1, the process proceeds to step 1522, where the A2 fields of the constructed AAD and nonce are set as the A2 fields of the MPDU, and then proceeds to step 1524, where the A1 field of the constructed AAD is set as the A1 field of the MPDU, and the process then continues from step 1514.In step 1514, the remaining fields of the AAD and nonce are set as usual. Although not shown in the diagram, in MPDUs where A3 is set to the BSSID (e.g., a data frame or management frame with To DS / From DS=0), if the BSSID of link 2 is different, A3 (which is set to the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA if the sender is an AP MLD (or the BSSID of the link if it is different from MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of the 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 decoded MPDU is sent to the next processing for reception, and the processing ends in step 1520. A favorable effect of the above processing is that CCMP encapsulation and decapsulation differ from the conventional method only in the case of retransmission, so the changes required to implement this embodiment can be minimized. Furthermore, the receiving MLD can determine whether the received MPDU is a retransmitted MPDU by checking the MPDU's CCMP header, 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 to an MLD may have different MAC header formats that convey information specific to multilink transmissions (i.e., information such as the MAC addresses of the transmitting and receiving MLDs). Figure 16A illustrates a protected MPDU 1600 with a modified MAC header 1602 according to the fourth embodiment. In the fourth embodiment, a Protocol Version (PV) field 1604 can be used to distinguish multilink frames from legacy frames and PV1 (802.11ah) frames. For example, if the PV field 1604 is set to a value of 2, it indicates that the MPDU 1600 is a multilink frame. Alternatively, in 802.11be, one or more new frame types may be defined to indicate the new MAC header format. Furthermore, the MAC header 1602 includes an ML Control field 1606 that can be used to convey control information related to multilink transmissions. The ML Control field 1606 includes a Control ID subfield 1608, and when this subfield is set to a specific value, the remainder 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 for the ML Control field 1606. For example, if the value of the Control ID subfield 1608 is 1, the ML Control field 1606 conveys the MAC addresses of the receiving MLD / sending MLD. These MAC addresses are shown 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 sending MLD, and the ML Address 2 subfield 1612 is set to the MAC address of the receiving MLD. In this case, the MLD addresses conveyed in the multilink frame are used for AAD and nonce construction during CCMP encapsulation / decapsulation. For example, the A1 field of the constructed AAD is set to the MLD address of the receiving MLD indicated in the ML Address 1 subfield 1610, and the A2 field of the constructed AAD and nonce is set to the MLD address of the transmitting MLD indicated in the ML Address 2 subfield 1612. Also, where applicable, the A3 field is set to the MLD address of the AP MLD as described above. Even if one or both of the ML addresses in the ML Control field 1606 use a short ID format (i.e., a 12-bit MLD ID) instead of a full MAC address (48 bits), the AAD and nonce can still use the full MAC address corresponding to the MLD ID (i.e., obtained from the association record (of the AP MLD) or from the MLD MAC address-MLD ID mapping record stored, for example, during the multilink association procedure).

[0049] Figure 17 shows a flowchart 1700 of MPDU reception according to the fourth embodiment. In step 1702, the 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, sending the MPDU to the next process for reception, and then the process ends in step 1726. If it is determined in step 1704 that the MPDU is protected, the process proceeds to step 1706, where it is determined whether the MPDU is using a new frame format, for example, by checking whether the PV field in the MAC header of the received MPDU has a value of 2. If it is determined that the PV field does not have a value of 2, the process proceeds to step 1720, setting the A2 field of the constructed AAD and nonce to the A2 field of the MPDU, then proceeds to step 1722, setting the A1 field of the constructed AAD to the A1 field of the MPDU, and then the process continues from step 1712. If it is determined in step 1706 that the PV field has a value of 2, the process proceeds to step 1708, where the A1 field of the constructed AAD is set to the MLD MAC address corresponding to the ML Address 1 subfield of the ML Control field of the received MPDU. Then the process proceeds to step 1710, where the A2 fields of the constructed AAD and nonce are set to the MLD MAC address corresponding to the ML Address 2 subfield of the ML Control field of the received MPDU. The process then continues from step 1712. In step 1712, the remaining fields of the AAD and nonce are set as usual.Although not shown in the diagram, in MPDUs where A3 is set as the BSSID (e.g., a data frame or management frame with To DS / From DS=0), if the BSSID of Link 2 is different, A3 (which is set as the BSSID in such frames, and the BSSID is generally the same as the MAC address of the AP MLD on that link) is also changed to MLD-TA if the sender is an AP MLD (or the BSSID of the link if it is different from the MLD-TA), or to MLD-RA if the sender is not an AP MLD (or the BSSID of the link if it is different from the MLD-RA). In step 1714, CCMP decapsulation is performed on the MPDU with the constructed AAD and nonce. In step 1716, the decoded MPDU is sent to the next processing for reception, and the processing ends in step 1718. A favorable effect of the above processing is that CCMP encapsulation / decapsulation is still performed based on the MPDU fields, so the changes required to implement this embodiment can be minimized.

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

[0051] Figure 18B illustrates a GCMP-protected MPDU 1806 according to the fifth embodiment. Because 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, which tells the Address field 1809 to be used to signal the Address field to be used to construct the AAD and nonce fields during GCMP decapsulation. Figure 18C illustrates the GCMP decapsulation process for forming a plaintext MPDU according to the fifth embodiment. Like GCMP encapsulation, GCMP decapsulation is almost identical to CCMP decapsulation. The only difference is that 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 differs from the nonce used in CCMP decapsulation in that it does not include a Priority field. The receiving MLD can determine which address field to use to construct the AAD and nonce fields during GCMP decapsulation by referring to the Address field 1809.

[0052] Figure 19 illustrates a multilink MPDU transmission using a common packet number (PN) assignment across all links, according to various embodiments. Similar to the multilink MPDU transmission using separate PTKs as shown in Figure 3, diagram 300, but using a common PN assignment on both Link 1 and Link 2 for transmitting the MPDU. In this example, transmission of MPDU 1902 failed on Link 1 and is therefore intended 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 must be encapsulated using Key 2 as MPDU 1904, but still using the same SN=4 and PN=104 as MPDU 1902 (because a common PN assignment is used on both Link 1 and Link 2). The receiving MLD sorts the MPDUs received on Link 2 according to the SN of each received MPDU, including MPDU 1904. When the MPDUs are sorted up to SN=4, i.e., up to received MPDU 1904 with SN=4 and PN=104, the receiver MLD updates its replay counter to PN=104. Unlike Diagram 300 in Figure 3, where the remaining MPDUs with SN greater than 4 (i.e., received MPDU 306 with SN=5 and PN=52, and received MPDU 308 with SN=7 and PN=53) are dropped and a replay rejection problem occurs, MPDUs 1906 and 1908 pass the replay check because their PNs are in the correct order after the sorting process. Thus, regardless of the number of PTKs, assigning PNs to keys using a common PN space and using the same PNs for retransmission solves the aforementioned replay rejection problem.

[0053] Figure 20 shows schematic diagrams of the sender MLD 2000 in various embodiments. The sender MLD comprises a MAC-SAP 2002 for performing the delivery service (DS), a transmit 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 and integrity module 2010, and a retransmission module 2012 (which determines the link to use for retransmission and the MAC address to use for constructing the AAD and nonce during cryptographic encapsulation). Furthermore, the sender MLD 2000 includes two attached STAs or stations, STA1 2014a and STA2 2014b. STA1 2014a includes an MPDU header and CRC creation module 2020a, a transmit (Tx) buffer and block acknowledgment (ACK) control module 2022a, and an aggregation control unit 2024a in the MAC layer 2016a. Similarly, STA2 2014b includes an MPDU header and CRC creation module 2020b, a transmit (Tx) buffer and block acknowledgment (ACK) control module 2022b, and an aggregation control unit 2024b in the MAC layer 2016b. Both STAs have a PHY layer on which transmission takes place via Link 1 (for STA1 2014a) and Link 2 (for STA2 2014b). It will be understood that the number of links and associated STAs or stations can be further expanded. 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 links, it can help avoid the replay denial problem as explained in the context of Figure 19, provided that the same PN space is used for all links. However, in deployments that choose to use different PTKs (and / or GTK / IGTK), the MPDU Cryptography and Integrity Module 2010 may be moved to each accompanying STA.If separate PN spaces are used for the links (PNs are typically associated with their respective secret keys), the Packet Number (PN) assignment module 2008 may also be moved to each of the accompanying STAs.

[0054] Figure 21 shows schematic diagrams of the receiver MLD 2100 in various embodiments. The receiver MLD comprises a MAC-SAP 2102 for performing the distribution service (DS), a replay detection module 2104, an MPDU decoding and integrity module 2106, a block ACK buffering and sorting module 2108, and a duplicate detection module 2110. Furthermore, the receiver MLD 2100 comprises two auxiliary STAs or stations, STA1 2114a and STA2 2114b. STA1 2114a comprises 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 comprises 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 are equipped with a PHY layer (i.e., 2118a of STA1 2114a and 2118b of STA2 2114b), from which transmission takes place via Link 1 (i.e., between STA1 2114a and STA1 2014a in sender MLD 2000) and Link 2 (i.e., between STA2 2114b and STA2 2014b in sender MLD 2000). It will be understood that the number of links and associated STAs or stations can be further expanded. Here, the MPDU Decoding and Integrity Module 2106 is responsible for parsing the address fields in the CCMP / GCMP header during CCMP / GCMP decapsulation to determine which address fields to use to construct the AAD and nonce fields.

[0055] Figure 22 shows a flowchart 2200 illustrating a method for securely retransmitting a multilink MPDU according to various embodiments. In step 2202, a Robust Security Network Association (RSNA) is set up in a first MLD configured to work with a first plurality of attached STAs, and in a second MLD configured to work with a second plurality of attached STAs, in which 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. In step 2204, Additional Authentication Data (AAD) and a nonce are constructed, the AAD including an Address 1 (A1) field, an Address 2 (A2) field, an Address 3 (A3) field, and a Sequence Control (SC) field, the nonce including an Address 2 (A2) field, and the SC field of the AAD being based on the SC field of the MPDU. In step 2206, the MPDU is cryptographically encapsulated using the AAD and nonce to form an encapsulated MPDU. If applicable, the address field in the CCMP / GCMP header is configured to signal the address field used to generate the AAD and nonce fields. In step 2208, the encapsulated MPDU is sent from the first MLD to the second MLD on the first link as the initial transmission. In step 2210, if the initial transmission fails, the encapsulated MPDU is retransmitted on the second link without re-performing cryptographic encapsulation. If applicable, the address field in the CCMP / GCMP header of the retransmitted MPDU is configured to signal the address field used to generate the AAD and nonce fields during the encapsulation process.

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

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

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

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

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

[0061] The multilink device 2300 provides the functionality necessary for secure retransmission of multilinks during operation. For example, the multilink device 2300 may be a first multilink device configured to operate with a first plurality of attached STAs. The circuit 2314 may, during operation, set up a Robust Security Network Association (RSNA) with a second MLD configured to operate with a second plurality of attached STAs, in which 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, and 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 including an address 1 (A1) field, an address 2 (A2) field, an address 3 (A3) field, and a sequence control (SC) field, the nonce including an address 2 (A2) field, and the SC field of the AAD being based on the SC field of the MPDU. When operating, transmitter 2302 can transmit the encapsulated MPDU to the second MLD on the first link as the initial transmission, and if the initial transmission fails, it can retransmit the encapsulated MPDU on the second link without re-performing cryptographic encapsulation.

[0062] The A2 field of the AAD and nonce can be set to a media access control (MAC) address that identifies a first MLD, and the A1 field of the AAD can be set to a MAC address that identifies a second MLD. Either CCMP or GCMP can be used to encrypt the MPDU. The MPDU may contain identification information for the first and second MLDs, and the A2 field of the AAD and nonce can be set to a MAC address that identifies the first MLD as indicated in the identification information, and the A1 field of the AAD can be set to a MAC address that identifies the second MLD as indicated in the identification information.

[0063] Circuit 2314 can specify the settings of fields A1, A2, and A3 in the MPDU, which indicate whether, during cryptographic decapsulation of the MPDU, the A1, A2, and A3 fields should be set to the MAC address identifying the second MLD, the MAC address identifying the first MLD, and the MAC address identifying the AP MLD, respectively; or whether the A1, A2, and A3 fields should be set to the MAC address of the attached STA of the second MLD, the MAC address of the attached STA of the first MLD, 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, in which case the AP MLD is either the first MLD or the second MLD. The settings of fields A1, A2, and A3 can be shown in either the CCMP (Counter-Mode Cipher Block Chain Message Authentication Code Protocol) header field or the GCMP (Galois / Counter-Mode Protocol) header field of the encapsulated MPDU.

[0064] The AAD and the A2 field of the 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. If the initial transmission fails, circuit 2314 can further specify the settings of the A1, A2, and A3 fields in the retransmitted MPDU, which indicates whether, when the retransmitted MPDU is decapsulated, the A1, A2, and A3 fields should be set to the MAC address of the attached STA of the second MLD, the MAC address of the attached STA of the first MLD, and the MAC address that identifies 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 multilink device 2300 may be a first multilink device configured to operate with a first set of attached STAs. Circuit 2314 can, during operation, set up a Robust Security Network Association (RSNA) with a second MLD configured to operate with a second set of attached STAs, in which case two or more links are established between the STAs of the first set of attached STAs and the corresponding STAs of the second set of attached STAs. Receiver 2304, when operating, can receive a cryptographically encapsulated MAC protocol data unit (MPDU) from the second MLD. In this case, circuit 2314 constructs additional authentication data (AAD) and a nonce used to cryptographically decapsulate 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 nonce can be set to either the A2 field of the MPDU, a medium access control (MAC) address identifying the second MLD, or the MAC address of one of the second multiple attached STAs. The A1 field of the AAD can be set to either the A1 field of the MPDU, a MAC address identifying the first MLD, or the MAC address of one of the first multiple 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 AP. The MAC address of the MLD can be set, and 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 which case the A2 fields of the AAD and nonce can be set to the MAC address that identifies the second MLD, and the A1 field of the AAD can be set to the MAC address that identifies the first MLD. The MPDU can be cryptographically decapsulated using either CCMP or GCMP. The MPDU can convey identification information of the first and second MLDs, and the circuit can cryptographically decapsulate the MPDU by setting the A2 fields of the AAD and nonce to the MAC address that identifies the second MLD shown in the MPDU, and the A1 field of the AAD to the MAC address that identifies the first MLD shown in the MPDU.

[0067] Circuit 2314 can cryptographically decapsulate a received MPDU based on the settings of the A1, A2, and A3 fields shown in the MPDU. The settings indicate whether, during 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, in which case the AP MLD is either the first MLD or the second MLD. The address field settings can be shown 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 A2 fields of the AAD and the nonce to the A2 field of the first MPDU, and setting the A1 field of the AAD to the A1 field of the first MPDU, so that 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, so that during cryptographic decapsulation, 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 that identifies the AP MLD, respectively, or so that the A1, A2, and A3 fields should be set to the A1, A2, and A3 fields of the second MPDU, so that the second MPDU includes a Retry subfield set to 1.

[0069] This disclosure can be implemented by software, hardware, or software working in conjunction with hardware. Each functional block used in the description of each embodiment above 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 combination of LSIs. The LSI may be formed as individual chips, or it may form a single chip that includes some or all of the functional blocks. The LSI may include data input / output units coupled to it. The LSI referred to herein may be called an IC, system LSI, super LSI, or ultra LSI depending on the degree of integration. However, the technology for implementing the integrated circuit is not limited to LSIs and may be implemented using dedicated circuits, general-purpose processors, or special-purpose processors. Furthermore, a Field Programmable Gate Array (FPGA) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can change the connections and settings of circuit cells located inside the LSI may be used. This disclosure can be implemented as digital or analog processing. Advances in semiconductor technology and other derivative technologies mean that if future integrated circuit technology is replaced by LSIs, it will also be possible to integrate functional blocks using that future integrated circuit technology. Biotechnology can also be applied.

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

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

[0072] Some non-exclusive examples of such communication devices include telephones (e.g., cellular phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smartwatches, tracking devices), game consoles, e-readers, telemedicine / telemedicine devices, vehicles providing communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

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

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

[0075] The communication device may 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 may include a controller or sensor that generates control signals or data signals used by the communication device that performs the communication functions of the communication device.

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

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

[0078] A non-exclusive example of a station is a station that is part of a first group of stations belonging to a multilink station logical entity (i.e., an MLD), where the stations of the first group of stations share a common medium access control (MAC) data services interface to the upper layer, and the common MAC data services interface is associated with a common MAC address or traffic identifier (TID).

[0079] Therefore, embodiments of the present disclosure can be understood to provide communication devices and communication methods that operate on multiple links in order to fully realize the throughput gain of multilink communication, particularly in secure retransmission of multilinks.

[0080] While the detailed description of this embodiment so far has presented exemplary embodiments, it should be understood that a vast number of variations exist. Furthermore, it should be understood that the exemplary embodiments are examples and are not intended to limit in any way the scope, applicability, operation, or configuration of this disclosure. Rather, the detailed description so far provides a useful guide for carrying out the exemplary embodiments. It should be understood that the function and organization of the steps and methods of operation described in the exemplary embodiments, and the modules and structures of the devices described in the exemplary embodiments, can be modified in various ways without departing from the scope of the subject matter set forth in the appended claims.

Claims

1. A receiving multilink device (MLD), A receiving unit that receives an encapsulated MAC protocol data unit (encapsulated MPDU) from the transmitting MLD via a first link, The circuit constructs additional authentication data (AAD) and a nonce, decapsulates the encapsulated MPDU using the AAD and the nonce to obtain a plaintext MPDU, wherein the AAD includes an address 1 (A1) field with the MAC address of the receiving multilink device (MLD) set, and an address 2 (A2) field with the MAC address of the transmitting MLD set, and the nonce includes an A2 field with the MAC address of the transmitting MLD set. The receiving MLD is equipped with this.

2. If 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 for the initial transmission on the first link and for the retransmission on the second link. The receiving MLD according to claim 2.

4. It has a second plurality of affiliated stations (STAs) that can establish 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 fields A1 and A2 are indicated in either the CCMP (Counter-Mode Cipher Block Chain Message Authentication Code Protocol) header field or the 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. To cryptographically protect the MPDU before encapsulation, either CCMP (Counter-Mode Cipher Block Chain Message Authentication Code Protocol) or GCMP (Galois / Counter-Mode Protocol) is used. The receiving MLD according to claim 1.

8. A communication method for a receiving multilink device (MLD), The encapsulated MAC protocol data unit (encapsulated MPDU) is received from the transmitting MLD on the first link. Additional authentication data (AAD) and a nonce are constructed, and the encapsulated MPDU is decapsulated using the AAD and the nonce to obtain a plaintext MPDU, wherein the AAD includes an address 1 (A1) field in which the MAC address of the receiving multilink device (MLD) is set, and an address 2 (A2) field in which the MAC address of the transmitting MLD is set, and the nonce includes an A2 field in which the MAC address of the transmitting MLD is set. Communication method.

9. If reception of the encapsulated MPDU on the first link fails, the encapsulated MPDU is 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 communication method according to claim 8.

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

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

12. The settings of fields A1 and A2 are indicated in either the CCMP (Counter-Mode Cipher Block Chain Message Authentication Code Protocol) header field or the 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. To cryptographically protect the MPDU before encapsulation, either CCMP (Counter-Mode Cipher Block Chain Message Authentication Code Protocol) or GCMP (Galois / Counter-Mode Protocol) is used. The communication method according to claim 8.

15. An integrated circuit for a receiving multilink device (MLD), The steps include receiving an encapsulated MAC protocol data unit (encapsulated MPDU) from the transmitting MLD on a first link, Steps to construct additional authentication data (AAD) and nonce, The steps include: decapsulating the encapsulated MPDU using the AAD and the nonce to obtain a plaintext MPDU, wherein the AAD includes an address 1 (A1) field in which the MAC address of the receiving multilink device (MLD) is set, and an address 2 (A2) field in which the MAC address of the transmitting MLD is set, and the nonce includes an A2 field in which the MAC address of the transmitting MLD is set; An integrated circuit that controls something.

Images