Counter mode with encrypted block link message authentication code protocol (CCMP) encapsulation and de-encapsulation including multi-link operation for enhanced privacy frames

Abstract

In a counter mode with encrypted block link message authentication code protocol (CCMP) encryption encapsulation, a station (STA) may incrementally increase a packet number (PN). The STA may construct additional authentication data (AAD) based on a plain text medium access control (MAC) protocol data unit (MPDU) header and an association with authentication medium access control (aaMAC) address. The STA may construct a random number based on the aaMAC address, the PN, and the priority value of the MPDU. The STA may form an encrypted message integrity code (MIC) based on the ADD and the random number. The STA may form an encrypted MPDU based on the MPDU header, the ciphertext, the MIC, and the CCMP header. The STA may then transmit the encrypted MDPU. The aaMAC address may be different from a multi-link device (MID) MAC address. The STA may be in non-multilink operation (MLO) communication with an access point (AP).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 439,742, filed January 18, 2023, and U.S. Provisional Application No. 63 / 451,407, filed March 10, 2023, the contents of which are incorporated herein by reference. Background Art

[0003] Users of wireless communication systems are increasingly interested in improved privacy protection. Over the past few years, there has been a trend within the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard to provide new privacy protection mechanisms for individuals using wireless local area network (WLAN) technology. One of the main areas of work in this area over the past few years has been protecting users from trackers. This means protecting the user's possible identity as they roam between different locations and different IEEE 802.11 networks.

[0004] IEEE 802.11aq introduces several modifications to the baseline specification that support current media access control (MAC) privacy features, which focus on protecting the privacy of users in the non-associated state. Summary of the Invention

[0005] Provided herein are methods and apparatus for counter mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) cryptographic encapsulation. In one example, a wireless transmit / receive unit (WTRU) may generate a medium access control (MAC) service data unit (MSDU). Additionally, in one example, frames of the MSDU may be anonymized. The frames may be anonymized by replacing the association and authentication medium access control (aaMAC) with an over-the-air medium access control (otaMAC) address.

[0006] In one example, a station (STA) may increment a packet number (PN). Furthermore, the STA may construct additional authentication data (AAD) based on a plaintext MAC protocol data unit (MPDU) header and an aaMAC address. Furthermore, the STA may construct a random number based on the aaMAC address, the PN, and the priority value of the MPDU. Furthermore, the STA may form an encrypted message integrity code (MIC) based on the ADD and the random number. Furthermore, the STA may form an encrypted MPDU based on the MPDU header, the ciphertext, the encrypted MIC, and the CCMP header. The STA may then transmit the encrypted MDPU. Furthermore, the STA may be in non-multi-link operation (MLO) communication with an access point (AP).

[0007] In another example, the aaMAC address may be different from the multi-link device (MLD) MAC address. Furthermore, in one example, the aaMAC may be a MAC address for secure exchange. In another example, the aaMAC may be a MAC address used for the association and authentication process between the AP and the STA. Furthermore, in one example, the aaMAC may be indexed in the Robust Security Network Association (RSNA). Furthermore, in one example, the aaMAC address may be used to set the RSNA. Furthermore, in one example, the aaMAC address may be different from the otaMAC address, and the otaMAC may be used in the association process. In another example, the aaMAC address may be used to route traffic to the STA on a distributed system (DS) network segment. In another example, the aaMAC address may be used for mobility-related operations. In another example, the aaMAC address may be used for a fast switching mechanism.

[0008] In another example, the CCMP header can be constructed based on the PN and the key identifier (KeyID) associated with the aaMAC address. In another example, the ciphertext can be formed based on the AAD, the random number, the plaintext MDPU data, and the temporary key (TK) associated with the aaMAC address. In addition, the encrypted MIC can also be formed based on the plaintext MDPU data and the TK associated with the aaMAC address. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be derived from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0010] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0011] Figure 1B It is shown that according to the embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0012] Figure 1C It is shown that according to the embodiment, Figure 1A A system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0013] Figure 1D It is shown that according to the embodiment, Figure 1A A system diagram of yet another exemplary RAN and yet another exemplary CN used within the illustrated communication system;

[0014] Figure 2is an architectural diagram illustrating an exemplary multi-link device (MLD) and tributary station (STA) communication system;

[0015] Figure 3 (including Figure 3A and Figure 3B ) is an architectural diagram illustrating an example of a medium access control (MAC) data plane architecture used when transparent fast session transport (FST) is not used;

[0016] Figure 4 (including Figure 4A 、 Figure 4B and Figure 4C ) is an architectural diagram illustrating an example of a MAC data plane architecture used when using a transparent FST;

[0017] Figure 5 is a block diagram illustrating an example of a counter mode with a Cipher Block Chaining Message Authentication Code Protocol (CCMP) encryption encapsulation process;

[0018] Figure 6 is a block diagram illustrating an example of a CCMP decapsulation process;

[0019] Figure 7 is a block diagram illustrating an example of another CCMP encryption encapsulation process;

[0020] Figure 8 is a format diagram showing an example of the construction of Additional Authentication Data (AAD) of a protocol version 0 (PV0) MAC protocol data unit (MPDU);

[0021] Figure 9 is a format diagram showing an example of a counter mode with a Cipher Block Chaining Message Authentication Code (CBC-MAC) (CCM) random number;

[0022] Figure 10 is a format diagram showing an example of a CCM random number flag field;

[0023] Figure 11 is a block diagram illustrating another example of another CCMP decapsulation process;

[0024] Figure 12 is a block diagram illustrating an example of another CCMP encryption encapsulation process;

[0025] Figure 13 is a flow chart of the CCMP encapsulation process; and

[0026] Figure 14 is a block diagram illustrating an example of another CCMP decapsulation process. DETAILED DESCRIPTION

[0027] Figure 1Ais a diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content via shared system resources, including wireless broadband. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tailing unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0028] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated process chains), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0029] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a master Node B, a master eNode B, a next generation Node B such as a gNode B (gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0030] Base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0031] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0032] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Air Access (UTRA) that may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro).

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use NR to establish the air interface 116.

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0036] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM Evolution (GERAN), etc.

[0037] Figure 1A The base station 114b in the example may be, for example, a wireless router, a master Node B, a master eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-aPro, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to the Internet 110. Thus, base station 114b may not be required to access the Internet 110 via CN 106.

[0038] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although Figure 1AAlthough not shown, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104, which may be utilizing NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0039] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) of the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0040] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0041] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0042] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0043] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0044] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0045] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., such as NR and IEEE 802.11).

[0046] The processor 118 of the WTRU 102 may be coupled to and receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0047] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0048] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0049] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0050] The WTRU 102 may include a full-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0051] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0052] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0053] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0054] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0055] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0056] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0057] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0058] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0059] Even though the WTRU Figures 1A to 1D Although depicted as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

[0060] In a representative embodiment, the other network 112 may be a WLAN.

[0061] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS or have an interface thereto. Traffic originating from outside the BSS destined for a STA may reach the AP and may be delivered to the STA. Traffic from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., sent directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0062] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit a beacon on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary signal is sensed / detected by a particular STA and / or is determined to be busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0063] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0064] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a fragment parser after channel coding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream separately. The stream can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0065] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0066] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports the 1 MHz operating mode) transmitting to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0067] In the United States, the available frequency bands for 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0068] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0069] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on an unlicensed spectrum, while the remaining component carriers may be located on a licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0070] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing a different number of OFDM symbols and / or lasting a different absolute time).

[0071] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as the eNode Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0072] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle air interface resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0073] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly Data Networks (DNs) 185a, 185b. While the aforementioned elements are depicted as being part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182 a, 182 b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as WiFi).

[0075] The SMFs 183a and 183b can connect to the AMFs 182a and 182b in the CN 106 via the N11 interface. The SMFs 183a and 183b can also connect to the UPFs 184a and 184b in the CN 106 via the N4 interface. The SMFs 183a and 183b can select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0076] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0077] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the local DN 185a, 185b.

[0078] Given that Figures 1A to 1D and Figures 1A to 1D

[0015] As described above, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more simulation devices (not shown) with respect to one or more of the WTRUs 102a-102d, base stations 114a-114b, eNode-Bs 160a-160c, MME 162, SGW 164, PGW 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-185b, and / or any other devices described herein. A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0079] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions when being implemented and / or deployed in whole or in part as a part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions when being temporarily implemented / deployed as a part of a wired and / or wireless communication network. The simulation device can be directly connected to another device for testing purposes and / or perform testing using over-the-air wireless communications.

[0080] One or more simulation devices can perform one or more (including all) functions when not being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to achieve the test of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) to transmit and / or receive data.

[0081] The embodiments and examples provided herein include the current status of MAC privacy enhancements in baseline specifications such as IEEE 802.11-2020, as well as modification work begun in the IEEE 802.11bi and IEEE 802.11bh specifications.

[0082] Several features of IEEE 802.11 can be exploited for user tracking. Before associating with an AP, a STA defines the MAC address it will use for association. Before MAC privacy enhancements were added to the baseline specification, STAs used their hardwired MAC addresses for all associations. This behavior made it easy to track STAs simply by observing the MAC address in the pre-association message. Consequently, user privacy could be compromised.

[0083] In addition to MAC addresses, IEEE 802.11 has other mechanisms for tracking STAs. For example, each frame in a communication has a sequence number associated with it. This sequence number can be used to track STAs even after the MAC address changes, as consecutive frames will display consecutive sequence numbers. Other mechanisms are slightly more complex, such as the OFDM physical layer (PHY) data scrambler, which can also be tracked without reseeding.

[0084] The MAC privacy enhancements introduced in the standard enable a STA to modify all these parameters in the pre-association state in such a way that the user cannot be easily tracked when the STA roams before associating to an AP or when the STA changes network access.

[0085] As outlined in the standard, MAC privacy enhancements mitigate the impact of such traffic analysis. Therefore, STAs can support the ability to periodically and randomly change their MAC addresses and reset counters and seeds before associating. When discovering networks, STAs can avoid gratuitously transmitting probe request frames containing the service set identifier (SSID) of their preferred BSS network.

[0086] Several requirements are implemented to support MAC privacy enhancements. For example, the baseline specification defines a set of requirements for applying MAC address randomization, which may include the following. A STA may periodically change its MAC address to a random value when not associated to a BSS. A STA may construct a random MAC address from the locally administered address space defined in IEEE Std 802-2014 and IEEE Std 802c-2017. A non-AP STA does not change its MAC address during transaction exchanges, such as when transmitting public action frames during the pre-association discovery process or when establishing a state using pre-association capabilities on an AP (e.g., Robust Security Network (RSN) pre-authentication or Fast BSS Transition (FT) via DS). If a non-AP STA initiates any transaction that establishes a state bound to a MAC address and decides to establish an association or transaction state with a discovered BSS, it may change its MAC address to the MAC address used to establish this state. A state established with an AP using a previous MAC address (e.g., RSN pre-authentication state or FT state established via DS) is bound to the MAC address used when establishing that state. Each time a MAC address is changed to a new random value, the counters in all sequence number spaces used to identify each frame must be reset. A non-AP STA connected to an infrastructure BSS can retain a single MAC address for the duration of its connection across an Extended Service Set (ESS).

[0087] Although MAC privacy enhancement greatly improves user privacy, it has proven to be insufficient. Therefore, IEEE 802.11 created the Randomized and Varying MAC (RCM) address group to study how to enhance privacy and improve the operation of networks that use MAC address randomization.

[0088] The study group concluded operations in 2020 and has proposed two project authorizations (PARs), including IEEE 802.11bi: Enhanced Services with Data Privacy Protection and IEEE 802.11bh: Operation with Randomized and Varying MAC Addresses. IEEE 802.11bi specifies modifications to IEEE Std 802.11MAC to include new mechanisms to address and improve user privacy. The IEEE 802.11bh specification specifies modifications to the MAC mechanisms to preserve existing services that may be limited in environments where STAs in an ESS use randomized or varying MAC addresses, without compromising user privacy. IEEE 802.11bh will focus on developing mechanisms to achieve session continuity in the absence of any unique MAC address to STA mapping.

[0089] The embodiments and examples provided herein address the work of IEEE 802.11bi by providing mechanisms that broaden the operational scope of MAC privacy enhancements. In current 802.11 networks, STAs transmit over the air using a fixed and unique MAC address, identifying the AP to which they are associated. This allows others to track a STA by observing the MAC address in over-the-air messages, as is done in pre-association messages. The baseline 802.11 specification does not support the ability to dynamically modify a STA's MAC address while in the associated state.

[0090] To enhance privacy, embodiments and examples provided herein are directed to changes to the MAC data service architecture and counter mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) encapsulation / decapsulation to allow modification of the MAC address of the header of a MAC Protocol Data Unit (MPDU).

[0091] At least four exemplary embodiments are provided below. The first embodiment includes a modification to the MAC data service architecture to consider anonymization and de-anonymization of MAC frames by changing the address used to identify the STA. The second embodiment includes a mechanism to encapsulate frames using CCMP, considering only the relationship between the association and authentication media access control (aaMAC) address (further explained below) and the key used for encryption when encapsulating the frame. This means that the random number can be calculated using the air media access control (otaMAC) address. The third embodiment includes a mechanism to encapsulate frames using CCMP when considering the use of aaMAC to calculate the random number. The fourth embodiment includes a mechanism to perform CCMP encapsulation / decapsulation while considering multi-link operation (MLO). The mechanism works by using the multi-link device (MLD) MAC as the aaMAC in the case of MLO or using the aaMAC in the case of non-MLO to calculate the random number and additional authentication data (AAD).

[0092] In the embodiments and examples provided herein, otaMAC may be transmitted or sent via any medium, not just wireless or over the air. Additionally, in the embodiments and examples provided herein, aaMAC may be transmitted or sent via any medium, not just wireless or over the air.

[0093] The embodiments and examples provided herein include architectural modifications to the MAC Data Service architecture to account for the anonymization of frames. As used in the embodiments and examples provided herein, otaMAC can be a temporary MAC address for frames transmitted over the air. otaMAC can be otaMAC1, otaMAC2, etc. For individually addressed frames with the To DS bit set to 1 and the From DS bit set to 0, the otaMAC1 of the non-AP STA transmitting the frame is used as address 2, while the otaMAC2 of the AP receiving the frame can be used as address 1. For individually addressed frames with the To DS bit set to 0 and the From DS bit set to 1, the otaMAC1 of the receiving non-AP STA is transmitted as address 1, while the otaMAC2 of the AP sending the frame can be used as address 2. The purpose of otaMAC is to protect the privacy of the STA's aaMAC and can be changed on a per-packet basis.

[0094] As used in the embodiments and examples provided herein, aaMAC may correspond to a MAC address used for the association and authentication process between an AP and a STA. aaMAC may be a MAC address indexed in Robust Security Network Association (RSNA). Note that an AP may also use otaMAC to hide the identity of the AP. Additionally, a STA may also use otaMAC to hide the identity of the STA. This aaMAC address may be used to set up RSNA to route traffic to the STA on the DS network segment, and is also the MAC address used for mobility-related operations such as the fast handoff mechanism.

[0095] The anonymization of the frame depends on the aaMAC and otaMAC binding. The embodiments and examples provided herein may assume the use of a single RSNA between the transmit and receive aaMAC, and may use that RSNA to encrypt and decrypt the frame even if the frame uses different transmit otaMAC and receive otaMAC (which may also be associated with the aaMAC).

[0096] In the case of MLO, the transmit and receive MLD MAC addresses can play the same role as the aaMAC of each peer in the communication. This approach is illustrated in the following embodiments and examples.

[0097] Specifically, the embodiments and examples provided herein include a reference model for MLO. MLO can define a set of procedures that allow communication over multiple links between MLDs. MLDs can manage such communication over multiple links. Communication using links across different frequency bands or channels can occur simultaneously or non-simultaneously, depending on the capabilities of both the AP MLD and the non-AP MLD. Such communication can include both simultaneous transmit and receive (STR) and non-simultaneous transmit and receive (NSTR) operations.

[0098] The MLO procedure allows a pair of MLDs to discover, synchronize, authenticate, deauthenticate, associate, reassociate, disassociate, and manage links and other resources on any common band or channel supported by both MLDs. Each MLD can have a single MAC Service Access Point (SAP). Each AP associated with an AP MLD has a MAC address that is different from any other AP associated with that AP MLD, and each non-AP STA associated with a non-AP MLD has a MAC address that is different from any other non-AP STA associated with the non-AP MLD.

[0099] Figure 2 FIG200 is an architectural diagram illustrating an exemplary MLD and STA communication system. Architectural diagram 200 illustrates an example of an AP MLD with two associated APs using link 1 and link 2, respectively. Figure 2 An AP MLD 220 with an MLD MAC address of M is shown, along with the MLD lower MAC sublayers of two associated APs, where AP1 has a MAC address of w 230 and AP2 has a MAC address of x 240. In addition, AP MLD 220 may be linked to DS 210 via MAC-SAP 225. Figure 2 As shown, AP MLD 220 is associated with a non-AP MLD 270 with MLD MAC address P and the MLD lower MAC sublayers of two associated STAs, STA1 with MAC address y 250 and STA2 with MAC address z 260. Link 1 is established between AP1 230 and STA1 260, and link 2 is established between AP2 240 and STA2 260. Furthermore, non-AP MLD 270 has a MAC-SAP 275. Typically, the MAC address of the MLD and the MAC addresses of the STAs associated with the MLD are different. For example, M, P, w, x, y, and z have different values.

[0100] However, the architecture supports implementations where M can be equal to w or x and P can be equal to y or z. Figure 2In the example shown, M and P can function as aaMAC addresses. Addresses w, x, y, and z can be considered otaMAC addresses and can change during operation of the MLO.

[0101] The embodiments and examples provided herein include modifications to the MAC data service architecture. In one example, when transparent FST is not used, a MAC data plane architecture can be used, as shown in Figure 3 below. When transparent FST is used, another MAC data plane architecture can be used, as further shown in Figure 4 below.

[0102] FIG3 is an architectural diagram illustrating an example of a MAC data plane architecture used when transparent Fast Session Transport (FST) is not used. In the example shown in architectural diagram 300, the processes in the MAC data plane architecture may involve the transmission of all or part of a MAC Service Data Unit (MSDU). Furthermore, the architecture shown in FIG3 may be referred to as a MAC data plane architecture in IEEE 802.11.

[0103] The MAC data plane architecture also includes a local higher layer entity 310 and an upper layer 802.1X Port Access Entity (PAE) 305. In addition, the architecture includes 802.1AC aggregation functions 315, 320 as 802.1 aggregation, bridging and related functions.

[0104] Figure 4 is an architectural diagram showing an example of a MAC data plane architecture used when using transparent FST. This architecture may be referred to as a MAC data plane architecture (transparent FST), such as in IEEE 802.11.

[0105] 3 , in the example shown in FIG4 , the MAC data plane architecture also includes a local higher layer entity 410 and an upper layer 802.1X PAE 405. In addition, the architecture includes 802.1AC aggregation functions 415, 420 as 802.1 aggregation, bridging, and related functions.

[0106] like Figure 3A As shown, the role-specific behavior box 325 can be replaced by one of a number of exemplary options depending on the role of the STA, as provided herein. Figure 4A , the role-specific behavior box 425 may be replaced by one of a number of exemplary options, as provided herein, depending on the role of the STA.

[0107] In one example, during transmission, the MSDU may undergo the process shown on the left side of Figures 3 and 4. In one example, the MSDU transmission process may begin with IEEE 802.1X control and non-control port filtering, such as Figure 3B Port filtering 330 or Figure 4BWhen transparent FST is used, the MSDU may first pass through an additional transparent FST entity 432 as shown in FIG4 , which contains a demultiplexing process that forwards the MSDU down to a selected transmit (Tx) MSDU rate limiting process 433 and then from there to the MAC data plane processing, as shown on the left side of FIG4 , and similar to the processing at the Rx / Tx MSDU rate limiting step 335 shown on the left side of FIG3 . Similarly, Rx MSDU rate limiting processing 437 may be performed as part of the MSDU flow for receive MSDUs.

[0108] 3 , A-MSDU aggregation Tx 340 may be performed after the Tx MSDU rate limiting process 335 in the MSDU stream for transmitting MSDUs. Accordingly, A-MSDU deaggregation Rx 340 may be performed before the Tx MSDU rate limiting process 335 in the MSDU stream for receiving MSDUs.

[0109] 4 , A-MSDU aggregation Tx 443 may be performed after the TxMSDU rate limiting process 433 in the MSDU flow for transmitting MSDUs. Accordingly, A-MSDU deaggregation Rx 447 may be performed before the TxMSDU rate limiting process 437 in the MSDU flow for receiving MSDUs.

[0110] 3 , after A-MSDU aggregation Tx 340 but before enhanced protection (EP) anonymization 360, a fragmentation Tx 350 may be performed in the MSDU stream to transmit the MSDU. Accordingly, before A-MSDU deaggregation Rx 340 but after EP deanonymization 365 and block acknowledgement (ACK) buffering and reordering 355, a defragmentation Rx 350 may be performed in the MSDU stream to receive the MSDU.

[0111] 4 , after A-MSDU aggregation Tx 443 but before MPDU encryption Tx 473, a fragmentation Tx 453 may be performed in the MSDU stream to transmit the MSDU. Accordingly, before A-MSDU deaggregation Rx 447 but after MPDU decryption Rx 474 and block ACK buffering and reordering 459, a defragmentation Rx 457 may be performed in the MSDU stream to receive the MSDU.

[0112] At filtering step 430, IEEE Std 802.1X-2010 can block the MSDU at the controlled port before the aforementioned processing occurs. Otherwise, at some point, a data frame containing all or part of the MSDU will be queued per access category (AC) / traffic stream (TS). In the case of an enhanced privacy MPDU, EP anonymization block 360 before encryption 370 or EP anonymization block 375 after encryption 370 can modify the MAC header's Address 1 (e.g., for transmissions from an AP to a non-AP STA) and / or Address 2 (e.g., for transmissions from a non-AP STA to an AP), replacing the aaMAC with the otaMAC currently being used by the EP MPDU's intended receiver (Address 1) and / or the EP MPDU's current transmitter (Address 2).

[0113] During reception, a received data frame may undergo the process shown on the right side of Figure 3 . One or more MSDUs may then be delivered to the MAC SAP or to a DS or IEEE 802.1Q bridge port via a distributed system access function (DSAF). When using transparent FST, as shown in Figure 4 , MSDUs originating from different PHY SAPs undergo the final step of the transparent FST entity 432 , which includes a multiplexing process, before the MSDUs are delivered. If the controlled port is not enabled and if the MSDU does not represent an IEEE 802.1X frame, the IEEE 802.1X controlled / uncontrolled port filtering 330 , 430 discards any received MSDUs. In the case of an EP MPDU, the EP de-anonymization block 365 may modify Address 1 (e.g., for transmissions from an AP to a non-AP STA) and / or Address 2 (e.g., for transmissions from a non-AP STA to an AP) of the MAC header by replacing otaMAC with aaMAC.

[0114] Many of the processes shown in Figure 3 can also be applied to the MAC Management Protocol Data Unit (MMPDU) flow for the MAC control plane architecture. In addition, the processes shown at the bottom of Figure 3 can also be applied to control and extended frames. For example, MPDU Header + CRC Create (Tx) / Verify (Rx) 390 and A-MPDU Aggregation (Tx) / Deaggregation (Rx) 395 can be applied to control and extended frames. Similarly, as shown in Figure 4, MPDU Header + CRC Create (Tx) / Verify (Rx) 493, 494 and A-MPDU Aggregation (Tx) / Deaggregation (Rx) 496, 497 can be applied to control and extended frames.

[0115] When using transparent FST, the MAC data plane uses the same security keys and packet number (PN) counters before and after the FST to encrypt the MPDU, and uses the same security keys and replay counters to check integrity and perform protection of the MPDU. When using non-transparent FST, independent RSNA, security keys, replay counters, and PN counters must be established for each MAC data plane to be used before and after the FST. When using transparent FST, a single MAC SAP is presented to the higher layers of the peer for all bands / channels identified by the same MAC address at that peer. When using non-transparent FST, different MAC SAPs are presented to higher layers because different MAC addresses are used before and after the FST.

[0116] The mechanisms for maintaining otaMAC and aaMAC synchronization between the receiver and transmitter can vary and may include protected block acknowledgements (ACKs), protected management frames, pre-shared MAC address lists, or synchronization information that can be appended to the data traffic to support encryption.

[0117] The EP anonymization block 360 may precede the MPDU encryption block 370 (in transmission), thereby modifying the MPDU before CCMP encapsulation. Additionally or alternatively, the EP anonymization block 375 may follow the MPDU encryption block 370 in transmission, thereby modifying the frame after encapsulation is complete.

[0118] EP deanonymization block 365 may be located (in reception) after MPDU decryption and integrity block 370. Additionally or alternatively, in reception, EP deanonymization block 385 may be located (and perform its functions) after Address 1 address filtering in block 385. In the latter case, modification of the MPDU is done before the decryption process is performed.

[0119] Embodiments and examples herein may include CCMP encapsulation / decapsulation, without considering aaMAC for random number and AAD calculations. Embodiments and examples herein may consider an MPDU frame arriving at the MPDU encryption block 370, such as the example shown in Figure 3, where the frame undergoes CCMP encryption encapsulation. The examples provided herein may assume two example scenarios of CCMP encapsulation as follows. In the example scenario, the MPDU may have been modified before CCMP encryption encapsulation begins, and its address may have been modified so as not to transmit identifiable information. In this line of thought example, the frame may have been processed by the EP anonymization block 375. Additionally or alternatively, in another example scenario, the MPDU may not be anonymized prior to CCMP encryption encapsulation, and the MPDU may be anonymized after the process is complete.

[0120] The two exemplary scenarios described above are valid for the remaining examples related to this embodiment, as long as both EP anonymization and deanonymization are performed before or after encryption / decryption. The main advantage of this exemplary solution is that the standard CCMP mechanism can be used without modification by always using the keys associated with aaMAC instead of the keys associated with otaMAC.

[0121] Figure 5 This is a block diagram illustrating an example of the CCMP encryption and encapsulation process. As shown in the example of block diagram 500, for a Security Protocol Version 0 (PV0) MPDU, CCMP can use the following steps to encrypt the frame body field of the plaintext MPDU and encapsulate the resulting ciphertext. In the examples used herein, ciphertext may be referred to as encrypted data, and these terms are used interchangeably.

[0122] The process may increment the PN 540 to obtain a new non-zero PN for each MPDU so that the PN is not repeated for the same temporary key. In addition, the retransmitted MPDU may not be modified when retransmitted. In addition, the plaintext MPDU may be parsed 510 so that fields in the MPDU can be used for the CCMP encryption encapsulation process.

[0123] Another step may be to use fields in the MPDU header to construct an AAD for counter mode with Cipher Block Chaining Message Authentication Code (CBC-MAC) (CCM) 520. The CCM algorithm provides integrity protection for the fields contained in the AAD. MPDU header fields that may change during retransmission are masked out when calculating the AAD.

[0124] Another step may include constructing a CCM nonce block 530. Those skilled in the art will appreciate that the construction of the CCM nonce 530 may be the same or similar to the process defined in the standard, such as that defined in Section 12.5.2.3.4 (Constructing CCM Nonce). The CCM nonce 530 may be constructed from the PN, A2, and the priority value of the MPDU, where A2 is MPDU Address 2.

[0125] In the embodiments and examples provided herein, a random number can be considered a parameter or value that varies over time. For example, a random number can be a value used in cryptographic operations associated with a given cryptographic key that is not reused with that key, including across all reinitializations of the system.

[0126] If the Type field of the Frame Control field is 10 (Data Frame) and the QoS Control field is present in the MPDU header, the MPDU's priority value is equal to the value of the Traffic Identifier (TID) subfield of the QoS Control field (bits 0 to 3 of the QoS Control field). If the Type field of the Frame Control field is 00 (Management Frame) and the frame is a Quality of Service Management Frame (QMF), the MPDU's priority value is equal to the value in the Access Category Index (ACI) subfield of the Sequence Number field. Otherwise, the MPDU's priority value is a fixed value of 0.

[0127] Additional steps may include constructing a CCMP header 560. Those skilled in the art will appreciate that the construction of the CCMP header 560 may be the same or similar to the process defined in the standard, such as that defined in Section 12.5.2.3.5 (Constructing a CCMP Header for a PVO MPDU). For example, the CCMP header 560 may be constructed from the PN and the key identifier (KeyID).

[0128] If the MPDU is sent to an EP STA with bound aaMAC and otaMAC in place, an additional step may be to use the temporary key associated with the aaMAC, AAD, random number, and MPDU data to form the ciphertext and encrypted MIC. Otherwise, the process uses the temporary key, AAD, random number, and MPDU data to form the ciphertext and encrypted MIC. This step may be referred to as CCM originator processing. This processing may be performed as part of the CCM encryption block 550.

[0129] Another step may include forming an encrypted MPDU 570 by combining the original MPDU header, CCMP header, encrypted data, and encrypted MIC. It will be appreciated by those skilled in the art that forming the encrypted MPDU 570 may be the same or similar to the process described in the standard, such as described in Section 12.5.2.2 (CCMP MPDU Format). Then, the STA or WTRU (such as Figure 1A or Figure 1D The WTRU 102a) in may transmit an encrypted MPDU.

[0130] The CCM reference describes the processing of keys, random numbers, AADs, and data to generate encrypted outputs. For example, those skilled in the art will appreciate that in the standard, sections 12.5.2.3.2 (PN processing) through 12.5.2.3.7 (CCM originator processing) may be referred to or used for details on creating AADs and random numbers from MPDUs and associated MPDU-specific processing.

[0131] Figure 6600, CCMP may use the following steps to decrypt the Frame Body field of the ciphertext MPDU and decapsulate the plaintext MPDU. Figure 1A or Figure 1D The WTRU 102a) in may receive the encrypted MPDU.

[0132] The encrypted MPDU can then be parsed 610 to construct an AAD 620. As will be appreciated by those skilled in the art, parsing the encrypted MPDU 610 and constructing the AAD 620 can be the same or similar to the process described in the standard (such as in Section 12.5.2.3.3 (Constructing AAD)) and the random number (such as in Section 12.5.2.3.4 (Constructing CCM Random Number)). For example, the AAD 620 can be constructed from fields in the MAC header. In addition, the random number can be constructed (630) using the PN, A2, and priority from the parsed encrypted MPDU. In addition, as part of CCM decryption 650, a message integrity code (MIC) can be extracted for use in a CCM integrity check.

[0133] In the case of an MPDU received at an EP STA with aaMAC and otaMAC binding in place, the CCM receiver process can use the temporary key associated with the aaMAC, AAD, random number, encrypted MIC, and MPDU ciphertext data to recover the MPDU plaintext data and check the integrity of the AAD and MPDU plaintext data. This process can be performed as part of the CCM decryption block 650. Otherwise, the CCM receiver process (such as in the CCM decryption block 650) can use the temporary key, AAD, random number, encrypted MIC, and MPDU ciphertext data to recover the MPDU plaintext data and check the integrity of the AAD and MPDU plaintext data.

[0134] The received MPDU header and the MPDU plaintext data from the CCM receiver process can be concatenated to form a plaintext MPDU 670. At the replay check block 680, the decryption process can prevent the replay of the MPDU by verifying whether the PN in the MPDU is greater than the replay counter maintained for the session and the TID (for data frames) or ACI (for QMF). It will be appreciated by those skilled in the art that detailed information on examples of some of the processes used in the embodiments and examples herein can be found in the standard, such as in Sections 12.5.2.4.2 (CCM Receiver Processing) to Sections 12.5.2.4.4 (PN and Replay Detection).

[0135] When the received frame is an individually addressed robust management frame or a protocol version 1 (PV1) management frame protected by CCMP, the content of the MMPDU body after the protection is removed shall be delivered to the station management entity (SME) via the MAC layer management entity (MLME) primitive specified for the MMPDU or PV1 management frame (rather than via the MA-UNITDATA. indication primitive). It will be understood by those skilled in the art that Figure 6 The method provided in the illustrated example may be used in conjunction with the standard MLD CCMP encapsulation defined in IEEE 802.11be as a different mechanism for EP STAs that do not transmit in MLD.

[0136] Embodiments and examples herein may include CCMP encapsulation / decapsulation, taking into account aaMAC for the calculation of the nonce and AAD. Embodiments and examples herein may consider an MPDU frame arriving at the MPDU encryption block 370, such as the example shown in FIG3 , where the frame undergoes CCMP encryption encapsulation. The examples provided herein may consider a solution that uses aaMAC in place of Address 2, Address 1, or both when calculating the AAD and the nonce and the key associated with the aaMAC. The benefit of this exemplary solution is that it is independent of the location where the EP anonymization / de-anonymization is performed.

[0137] Figure 7 is a block diagram illustrating another example CCMP encryption and encapsulation process. As shown in the example of block diagram 700, for a secure PVO MPDU, CCMP can use the following steps to encrypt the frame body field of the plaintext MPDU and encapsulate the resulting ciphertext. This process can increment the PN 740 to obtain a new, non-zero PN for each MPDU, thereby preventing the PN from being repeated for the same temporary key. Furthermore, retransmitted MPDUs can be unmodified upon retransmission.

[0138] In addition, the plaintext MPDU may be parsed (710) so that fields in the MPDU may be used for the CCMP encryption encapsulation process. Another step may use fields in the MPDU header to construct the AAD (720) for the CCM. The CCM algorithm provides integrity protection for the fields contained in the AAD. It will be appreciated by those skilled in the art that MPDU header fields that may change upon retransmission are masked out when calculating the AAD 720 or are set to known values ​​when calculating the AAD 720, as described in the standard, such as described in Section 12.5.2.3.3 (Constructing the AAD). Figure 7 In the example shown, in addition to using fields in the MPDU header, the AAD may also be calculated 720 using the aaMAC (such as the transmit aaMAC).

[0139] Those skilled in the art will appreciate that, in the case of a secure PVO MPDU, which may be an individually addressed EP data frame, the process may include constructing a CCM nonce block 730 from the PN as defined in the standard, such as defined in 12.5.2.3.4 (Constructing CCM Nonce), transmitting the aaMAC and the MPDU's priority value. Otherwise, those skilled in the art will appreciate that the process may include constructing a CCM nonce block from the PN, A2, and the MPDU's priority value as defined in 12.5.2.3.4 (Constructing CCM Nonce), where A2 is MPDU Address 2. If the Type field of the Frame Control field is 10 (Data Frame) and the QoS Control field is present in the MPDU header, the MPDU's priority value is equal to the value of the TID subfield of the QoS Control field (bits 0 to 3 of the QoS Control field). If the Type field of the Frame Control field is 00 (Management Frame) and the frame is a QMF, the MPDU's priority value is equal to the value in the ACI subfield of the Sequence Number field. Otherwise, the MPDU's priority value is a fixed value of 0.

[0140] Those skilled in the art will appreciate that additional steps may include constructing a CCMP header 760 as defined in a standard, such as defined in Section 12.5.2.3.5 (Constructing a CCMP Header for a PV0 MPDU). For example, the CCMP header may be constructed (760) using the PN and KeyID associated with the aaMAC.

[0141] If the MPDU is sent to an EP STA with bound aaMAC and otaMAC in place, an additional step may be to use the temporary key associated with the aaMAC, AAD, random number, and MPDU data to form the ciphertext and encrypted MIC. Otherwise, the temporary key, AAD, random number, and MPDU data are used to form the ciphertext and encrypted MIC. This step may be referred to as CCM originator processing. This processing may be performed as part of CCM encryption block 750.

[0142] Another step may include forming an encrypted MPDU 770 by combining the original MPDU header, the CCMP header, the encrypted data, and the encrypted MIC. Those skilled in the art will appreciate that the process of forming the encrypted MPDU 770 may be the same or similar to the process described in the standard, such as described in Section 12.5.2.2 (CCMP MPDU Format).

[0143] The CCM reference describes the processing of keys, random numbers, AADs, and data to generate encrypted output. For example, in the standard, sections 12.5.2.3.2 (PN processing) to 12.5.2.3.7 (CCM originator processing) may be referred to or used for details on creating AADs and random numbers from MPDUs and associated MPDU-specific processing. The STA can then transmit the encrypted MPDU.

[0144] Figure 8 800 is a format diagram showing an example of the AAD structure of a PV0 MPDU. For a PV0 MPDU, the format of the AAD is as shown in the example of format diagram 800. The length of the AAD of PV0 can vary depending on the presence or absence of the QoS control (QC) and A4 fields, as shown in Table 1.

[0145]

[0146] Table 1

[0147] The AAD can be constructed from the MPDU header. The AAD does not contain the Duration / ID field and the HT Control field because the contents of these fields may change during normal operation. For example, the contents of one or both fields may change due to a rate change before a retransmission. The HT Control field can also be inserted or removed during normal operation. For example, during a retransmission of an A-MPDU, the field can be inserted or removed if the original A-MPDU contains a Modulation and Coding Scheme (MCS) Request (MRQ) for which a response has been generated. For similar reasons, several subfields in the Frame Control field are masked. For a PV0 MPDU, the AAD construction can be performed as follows.

[0148] The Frame Control (FC) field 820 may include: the three least significant bits (LSBs) of the Subtype subfield in data frames (bits 4, 5, and 6) masked (bit 7 may not be modified); the Retry subfield (bit 11) masked; the Power Management subfield (bit 12) masked; the More Data subfield (bit 13) masked; and the Protected Frame subfield (bit 14) unmodified (remains at 1), with the High Throughput Control (HTC) subfield (bit 15). The HTC subfield may include the following attributes: masked in all data frames containing the QoS Control field; otherwise, unmodified. Other subfields may not be modified.

[0149] If the To DS bit or From DS bit subfields in the MAC header of the MPDU are not equal to 0 or 1 at the same time, and the MPDU may be an EP MPDU, the A1 field 830 may be set to the aaMAC associated with the otaMAC indicated in the MPDU Address 1 field. Otherwise, the A1 field 830 is set to the MPDU Address 1 field.

[0150] If the To DS bit or From DS bit subfields in the MAC header of the MPDU are not equal to 0 or 1 at the same time, and the MPDU may be an EP MPDU, the A2 field 840 may be set to the aaMAC associated with the otaMAC indicated in the MPDU Address 2 field. Otherwise, the A2 field 840 is set to the MPDU Address 2 field.

[0151] The A3 field 850 may be the MPDU Address 3 field. Additionally, the Sequence Control (SC) field 860 may be the MPDU SC field with the Sequence Number subfield (bits 4 to 15 of the Sequence Control field) masked. The Fragment Number subfield may not be modified.

[0152] The A4 field 870 may be the MPDU address field, if present.

[0153] The QC field 880 may be an MDPU QoS control field that contains the MSDU priority (if present). The QC TID may be used to construct the AAD. Those skilled in the art will appreciate that in a non-directional multi-gigabit DMG BSS, if both the STA and its peer have their Signaling and Payload Protection Aggregation MSDU (SPPA-MSDU) Capability (M57) subfield (see the standard, such as Section 9.4.2.241 (RSNXE)) equal to 1, the A-MSDU Present field may also be used to construct the AAD. When in a DMG BSS, the A-MSDU Present field and the A-MSDU Type field may also be used to construct the AAD. The remaining QC fields may not be used and may be masked for AAD calculation (bits 4 to 6, bits 8 to 15 for non-DMG BSSs, and bit 7 when the STA or its peer has the SPP A-MSDU Capability field equal to 0; bits 4 to 6 and bits 9 to 15 for DMG BSSs). When in a DMG BSS, A-MSDU presence bit 7 and A-MSDU type bit 8 may be used to construct the AAD, and the remaining QC fields may be masked for AAD calculation (bits 4 to 6, bits 9 to 15).

[0154] Figure 9 is a field diagram showing an example of a CCM random number. Examples herein may include a process for constructing a CCM random number, such as Figure 5 Block 530, Figure 6 Block 630, Figure 7 Block 730, Figure 11 Block 1130, Figure 12 Block 1230, Figure 13 Step 1340 or Figure 14 As shown in block 1430 in .

[0155] Figure 10 1000 is a field diagram illustrating an example of a CCM nonce flag field. In one example, the CCM nonce flag field of field diagram 1000 may be used in CCM nonce flag field 930 in field diagram 900.

[0156] In another example, those skilled in the art will appreciate that Figure 10 The priority subfield 1020 in the MPDU may be set to the priority value of the MPDU (such as in the standard, such as in Section 12.5.2.3.1 (General). In addition, if the MPDU is a management frame and management frame protection has been negotiated, the management subfield 1030 may be set to 1; otherwise, it may be set to 0.

[0157] For a PV1 frame, the PV1 subfield 1040 may be set to 1; otherwise, the PV1 subfield 1040 may be set to 0. The Zero 1050 subfield shall be set to 0.

[0158] Figure 9 The STA MAC address identified by the A2 subfield 940 in the MAC header of the MPDU may include the following. If the To DS bit or From DS bit subfield in the MAC header of the MPDU may not be equal to 0 or 1 at the same time, and the MPDU may be an EP MPDU, the STA MAC address identified by the A2 subfield 940 may be set to the aaMAC associated with the otaMAC indicated in the Address 2 field of the MPDU. Otherwise, as will be appreciated by those skilled in the art, the STA MAC address identified by the A2 subfield 940 may be set to the Address 2 field from the MAC header of the PV0 MPDU and the MAC address identified by the A2 field in the MAC header of the PV1 MPDU (such as in the standard, such as in Section 9.8.3.2 (Address Field)).

[0159] The PN subfield 950 may contain the packet number, with PN0 being located in the last octet of the subfield.

[0160] A transmitter may not use MSDU or A-MSDU priorities if this would result in the total number of priorities used during the lifetime of a source address (SA) exceeding the number of replay counters for that SA supported by the receiver (for a pairwise SA) or all receivers (for a group SA). A transmitter shall not reorder CCMP-protected frames transmitted to the same receiver address (RA) within the replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is MSDU or A-MSDU priorities.

[0161] The transmitter may preserve the order of protected robust management frames transmitted to the same destination address (DA) and not using the QMF service. When using the QMF service, the transmitter shall not reorder robust individually addressed QMF (IQMF) frames within an AC when the frames are transmitted to the same RA.

[0162] Individually addressed robust management frames protected by CCMP shall be protected with the same Temporal Key (TK) as data frames.

[0163] Figure 11 1100 is a block diagram illustrating another example of a CCMP decapsulation process. As shown in the example of block diagram 1100, for a secure PVO MPDU, CCMP can use the following steps to decrypt the Frame Body field of the ciphertext MPDU and decapsulate the plaintext MPDU. In one example, a STA can receive an encrypted MPDU.

[0164] Those skilled in the art will appreciate that the encrypted MPDU can be parsed 1110 to construct the AAD 1120, which can be done the same or similarly to the process in the standard (such as, Section 12.5.2.3.3 (Constructing AAD)) and the random number value (such as, Section 12.5.2.3.4 (Constructing CCM Random Number)). In addition, those skilled in the art will appreciate that if the To DS and From DS bits of the MAC header may not be set to 1 or 0 at the same time, and the MPDU may be a separately addressed EP MPDU, then the aaMAC associated with the otaMAC (which may be included in A1 or A2) can be passed to construct the AAD 1120 (see 12.5.2.3.3 (Constructing AAD)) and the random number value 1130 (see 12.5.2.3.4 (Constructing CCM Random Number)). Therefore, the AAD can be constructed (1120) from the parsed MPDU header and the aaMAC. Additionally, a random number may be constructed from the A2 field, the priority field, the PN field, and the aaMAC ( 1130 ). The MIC may be extracted for use in a CCM integrity check, such as in a CCM decryption process 1150 .

[0165] As part of the CCM decryption process 1150, if an MPDU is received at an EP STA with an aaMAC and otaMAC binding in place, the CCM receiver process may use the temporary key associated with the aaMAC, AAD, random number, encrypted MIC, and MPDU ciphertext data to recover the MPDU plaintext data and check the integrity of the AAD and MPDU plaintext data. Otherwise, the CCM receiver process 1150 uses the temporary key, AAD, random number, encrypted MIC, and MPDU ciphertext data to recover the MPDU plaintext data and check the integrity of the AAD and MPDU plaintext data.

[0166] The received MPDU header and the MPDU plaintext data from the CCM receiver process are concatenated to form a plaintext MPDU 1170. At replay check block 1180, the decryption process prevents replay of the MPDU by verifying that the PN in the MPDU is greater than the replay counter maintained for the session and the TID (for data frames) or ACI (for QMF). It will be appreciated by those skilled in the art that detailed information on examples of some of the processes used in the embodiments and examples herein can be found in the standard, such as in Sections 12.5.2.4.2 (CCM Receiver Processing) to 12.5.2.4.4 (PN and Replay Detection).

[0167] In an exemplary solution, when the received frame is a CCMP protected individually addressed robust management frame or a PV1 management frame, the contents of the MMPDU body after removing protection shall be delivered to the SME via the MLME primitive specified for that MMPDU or PV1 management frame (instead of via the MA-UNITDATA.indication primitive).

[0168] Embodiments and examples herein may include CCMP encapsulation / decapsulation for both MLO and non-MLO operations, considering aaMAC for random number and AAD calculations. Embodiments and examples herein may consider an MPDU frame arriving at the MPDU encryption block 370, such as shown in FIG3 , where the frame undergoes CCMP encryption encapsulation. The proposed mechanism integrates a single CCMP encapsulation operation for both MLO and non-MLO.

[0169] In the embodiments and examples herein, the AP MLD MAC address and the non-AP MLD MAC address can be considered the aaMAC on the AP side and the non-AP side of the communication. Furthermore, the embodiments and examples herein include a solution that uses aaMAC in place of Address 2, Address 1, or both when calculating the AAD and the random number and key associated with the aaMAC. Benefits of this solution include being independent of the location where EP anonymization / de-anonymization is performed.

[0170] The embodiments and examples herein relate to frame exchanges between STAs operating under the MAC masquerading protocol and / or using IEEE 802.11bi / bh enhancements as Enhanced Protection (EP) frames. In one example, STAs operating under the MAC masquerading protocol may be able to change their over-the-air MAC addresses upon association. Furthermore, those skilled in the art will appreciate that the embodiments and examples herein include IEEE 802.11be / D2.3 as a baseline specification.

[0171] Figure 121200 is a block diagram illustrating another example CCMP encryption encapsulation process. As shown in the example of block diagram 1200, for a secure PVO MPDU, the CCMP encryption encapsulation process can use the following steps to encrypt the frame body field of a plaintext MPDU 1210 and encapsulate the resulting ciphertext. This process can increment the PN 1240 to obtain a new PN for each MPDU, thereby preventing the PN from being repeated for the same temporary key. Furthermore, retransmitted MPDUs can be unmodified upon retransmission. For MLO, MPDUs can be unencapsulated with a new PN when retransmitted on another link.

[0172] Additionally, the process can use fields in the MPDU header to construct the AAD 1220 for the CCM. The CCM algorithm provides integrity protection for the fields contained in the AAD. MPDU header fields that may change upon retransmission are masked to zero or set to a known value when calculating the AAD 1220. In one example, the process can construct the AAD 1220 from fields in the MPDU header and from the MLD MAC address. Additionally or alternatively, the process can construct the AAD 1220 from fields in the MPDU header and from the aaMAC address.

[0173] In the case of a secure PVO MPDU (i.e., an individually addressed data frame to be encrypted via MLD), the process can construct a CCM nonce block 1230 from the PN, the transmitting MLD MAC address (if the transmitting STA uses EP, the transmitting MLD MAC address corresponds to the transmitting STA's aaMAC), and the MPDU's priority value. In the case of a secure PVO MPDU, which can be an individually addressed EP data frame, the process can construct a CCM nonce block 1230 from the PN, the transmitting aaMAC, and the MPDU's priority value. Otherwise, the process can construct a CCM nonce block 1230 from the PN, A2, and the MPDU's priority value, where A2 is MPDU address 2. If the Type field of the Frame Control field is 10 (data frame) and the QoS Control field is present in the MPDU header, the MPDU's priority value is equal to the value of the TID subfield of the QoS Control field (bits 0 to 3 of the QoS Control field). If the Type field of the Frame Control field is 00 (management frame) and the frame is a QMF, the MPDU's priority value is equal to the value in the ACI subfield of the Sequence Number field. Otherwise, the priority value of the MPDU is equal to the fixed value 0.

[0174] For the construction of the MLO, AAD, and CCM random numbers for management frames, the process can follow procedures known to those skilled in the art and can use the MPDU header fields to be transmitted over the associated STA link. In addition, the process can use the PN and KeyID to construct the CCMP header 1260. The KeyID can be associated with the MLD MAC address, the aaMAC address, or both.

[0175] In addition, the process may use one or more of the temporary key, AAD, random number, and MPDU data to form a ciphertext and an encrypted MIC. This step may be referred to as CCM originator processing and may be performed at CCM encryption block 1250.

[0176] For EP frames, the SME can maintain an RSN association between the aaMAC addresses of the AP and non-AP STAs. Therefore, the temporary key is associated with the aaMAC address pair used in the communication. Furthermore, the process can form an encrypted MPDU 1270 by combining the original MPDU header, CCMP header, encrypted data, and encrypted MIC. In one example, the process can form an encrypted MPDU 1270 by combining the original MPDU header, CCMP header, ciphertext, and encrypted MIC.

[0177] For PV0 MPDU, the format of AAD is as follows Figure 8 The length of the AAD of PV0 may vary depending on the presence or absence of the QC and A4 fields, and is shown in Table 1 (AAD length of PV0 MPDU).

[0178] The AAD may be constructed from the MPDU header. The AAD may not contain the Duration / ID field and the HT Control field, as the contents of these fields may change during normal operation. For example, these fields may change during normal operation due to a rate change before a retransmission. The HT Control field may also be inserted or removed during normal operation. In one example, during retransmission of an A-MPDU, the HT Control field may also be inserted or removed in the event that the original A-MPDU contains an MRQ for which a response has been generated. For similar reasons, several subfields in the Frame Control field may be masked to 0. For a PV0 MPDU, the AAD construction may be performed as follows.

[0179] The FC field (such as FC field 820) can be an MPDU FC field and can include: the Subtype subfield (bits 4, 5, and 6) in data frames masked to 0; the Retry subfield (bit 11) masked to 0; the Power Management subfield (bit 12) masked to 0; the More Data subfield (bit 13) masked to 0; the Protected Frame subfield (bit 14) always set to 1; and the +HTC subfield (bit 15). The +HTC subfield can be set as follows: masked to 0 in all data frames containing the QoS Control field, and unmasked otherwise. The other subfields of the FC field may not be modified.

[0180] Field A1 (such as field A1 830) can be set as follows. If the To DS or From DS subfields in the MPDU's MAC header are not both equal to 0, and the MPDU is an individually addressed data frame between the AP MLD and a non-AP MLD (EP or non-EP) associated with the AP MLD, then A1 is set to the MLD MAC address of the target receiver. If the To DS or From DS subfields in the MPDU's MAC header are not both equal to 0 or 1, and the MPDU is an individually addressed EP data frame, then A1 can be set to the aaMAC of the target receiver. Otherwise, A1 can be set to the MPDU Address 1 field.

[0181] Field A2 (such as field A2 840) can be set as follows. If the To DS or From DS subfields in the MPDU's MAC header are not both equal to 0, and the MPDU is an individually addressed data frame between the AP MLD and a non-AP MLD (EP or non-EP) associated with the AP MLD, then A2 is set to the MLD MAC address of the transmitting MLD. If the To DS or From DS subfields in the MPDU's MAC header are not both equal to 0 or 1, and the MPDU is an individually addressed EP data frame, then A2 can be set to the aaMAC of the target transmitter. Otherwise, A2 can be set to the MPDU Address 2 field.

[0182] If dot11MultiLinkActivated is true, the MPDU Address 3 field (such as field A3850) is the BSS identifier (BSSID), and the MPDU is a separately addressed data frame between the AP MLD and the non-AP MLD associated with the AP MLD. Therefore, A3 can be set to the AP MLD's MLD MAC address. Otherwise, A3 can be set to the MPDU Address 3 field.

[0183] An SC field, such as SC field 860, may be an MPDU SC field with the sequence number subfield (bits 4 to 15 of the sequence control field) masked to 0. The fragment number subfield may not be modified.

[0184] The A4 field (if present) (such as A4 field 870) can be set as follows: If dot11MultiLinkActivated is true, the MPDU Address 4 field is the BSSID, and the MPDU is an individually addressed data frame between the AP MLD and a non-AP MLD associated with the AP MLD. Therefore, A4 is set to the MLD MAC address of the AP MLD. Otherwise, A4 (if present) is set to the MPDU Address 4 field.

[0185] The QC field (such as QC field 880) may include the MSDU priority (if present). The QC TID may be used to construct the AAD. When in a non-DMG BSS and both the STA and its peer have their SPP A-MSDU capability fields equal to 1, bit 7 (A-MSDU present field) may be used to construct the AAD. The remaining QC fields may be masked to 0 for AAD calculation (bits 4 to 6, bits 8 to 15, and bit 7 when the STA or its peer has SPP A-MSDU capability field equal to 0). When in a DMG BSS, A-MSDU present bit 7 and A-MSDU type bit 8 may be used to construct the AAD, and the remaining QC fields may be masked to 0 for AAD calculation (bits 4 to 6, bits 9 to 15).

[0186] exist Figure 9 and Figure 10 In the example shown, the priority subfield 1020 of the CCM random number flag field 930 of the CCM random number can be set to the priority value of the MPDU. If the MPDU is a management frame and management frame protection has been negotiated, the management subfield 1030 can be set to 1; otherwise, it can be set to 0.

[0187] For PV1 frames, the PV1 subfield 1040 may be set to 1; otherwise, it may be set to 0. The Zero subfield 1050 may be set to 0. If the To DS or From DS subfields in the MAC header of the MPDU are not both equal to 0, and the MPDU is a separately addressed data frame between the AP MLD and a non-AP MLD (EP or non-EP) associated with the AP MLD, the STA MAC address identified by the A2 subfield may include the MLD MAC address of the transmitting MLD.

[0188] If the To DS or From DS subfields in the MAC header of the MPDU are not both equal to 0 or 1, and the MPDU may be an EP MPDU, the STA MAC address identified by the A2 subfield 940 may be set to the aaMAC of the transmitting STA. Otherwise, the STA MAC address identified by the A2 subfield 940 may contain the Address 2 field from the MAC header of the PV0 MPDU and the MAC address identified by the A2 field in the MAC header of the PV1 MPDU. The PN subfield 950 may contain the packet number, with PN0 located in the last octet of the subfield.

[0189] A transmitter may not use MSDU or A-MSDU priorities if this would result in the total number of priorities used during the lifetime of an SA exceeding the number of replay counters supported by the receiver (for a pairwise SA) or all receivers (for a group SA) for that SA. A transmitter may not reorder CCMP-protected frames transmitted to the same RA within the replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is MSDU or A-MSDU priorities.

[0190] The transmitter shall preserve the order of protected robust management frames transmitted to the same DA and not using the QMF service. When using the QMF service, the transmitter shall not reorder the robust IQMF within an AC when the frames are transmitted to the same RA. Individually addressed robust management frames protected by CCMP may be protected using the same TK as data frames.

[0191] Figure 13 13 is a flowchart of the CCMP encapsulation process. As shown in the example of flowchart 1300, the STA may increment the PN 1320. In addition, the STA may construct an AAD based on the plaintext MPDU header and the aaMAC address 1330. In addition, the STA may construct a random number based on the aaMAC address, the PN, and the priority value of the MPDU 1340. In addition, the STA may form an encrypted MIC based on the ADD and the random number 1350. In addition, the STA may form an encrypted MPDU based on the MPDU header, the ciphertext, the encrypted MIC, and the CCMP header 1360. The STA may then transmit the encrypted MDPU 1370. In addition, the STA may be in non-MLO communication with the AP. In one example, the STA may transmit the encrypted MDPU to the AP.

[0192] In another example, the aaMAC address may be different from the MLD MAC address. In another example, the aaMAC address may be a MAC address for security exchange. In another example, the aaMAC address may be a MAC address used for the association and authentication process between the AP and the STA. Furthermore, in one example, the aaMAC address may be indexed in the RSNA, and the aaMAC address may be used to set the RSNA. Furthermore, in one example, the aaMAC address may be different from the otaMAC address, and the otaMAC may be used in the association process. In another example, the aaMAC address may be used to route traffic to the STA on the DS network segment. In another example, the aaMAC address may be used for mobility-related operations. In another example, the aaMAC address may be used for a fast switching mechanism.

[0193] In another example, the CCMP header can be constructed based on the PN and the key identifier KeyID associated with the aaMAC address. In another example, the ciphertext can be formed based on the AAD, the random number, the plaintext MDPU data, and the TK associated with the aaMAC address. In addition, the encrypted MIC can also be formed based on the plaintext MDPU data and the TK associated with the aaMAC address.

[0194] Figure 14 1400 is a block diagram illustrating another example of a CCMP decapsulation process. As shown in the example of block diagram 1400, for a secure PVO MPDU, CCMP can use the following steps to decrypt the Frame Body field of the ciphertext MPDU and decapsulate the plaintext MPDU. In one example, a STA can receive an encrypted MPDU.

[0195] The encrypted MPDU may be parsed 1410 to construct an AAD 1420 and a random value 1430. In the event that the To DS or From DS subfields in the MPDU's MAC header are not simultaneously equal to 0 and the MPDU is an individually addressed data frame transmitted by a STA associated with the MLD, then the transmitter and receiver MLD MAC addresses may be transmitted to construct the AAD 1420 and the random value 1430. In the event that the To DS and From DS bits of the MAC header may not be simultaneously set to 1 or 0 and the MPDU may be an individually addressed EP MPDU, then the transmit and receive aaMACs may be transmitted to construct the AAD 1420 and the random value 1430.

[0196] In one example, the ADD 1420 can be constructed from fields in the MAC header and the MLD MAC address. Additionally or alternatively, the ADD 1420 can be constructed from fields in the MAC header and the aaMAC address.

[0197] Furthermore, a random number may be constructed 1430 from A2, priority, PN, and MLD MAC address. Additionally or alternatively, a random number may be constructed 1430 from A2, priority, PN, and aaMAC address.

[0198] The MIC can be extracted for CCM integrity checking. The CCM receiver process can use the temporary key, AAD, random number, encrypted MIC, and MPDU ciphertext data to recover the MPDU plaintext data and check the integrity of the AAD and MPDU plaintext data. This process can be performed as part of the CCM decryption block 1450.

[0199] For EP frames, the SME can maintain RSNA associations between the aaMAC addresses of the AP and non-AP STAs. Thus, a temporary key can be associated with the aaMAC address pair used in the communication.

[0200] At CCM decryption block 1450, the received MPDU header and the MPDU plaintext data from the CCM receiver process may be concatenated to form a plaintext MPDU 1470. At replay check 1480, the decryption process may prevent replay of the MPDU by verifying that the PN in the MPDU is greater than the replay counter maintained for the session and the TID (for data frames) or ACI (for QMF).

[0201] In an exemplary solution, when the received frame is a CCMP protected individually addressed robust management frame or a PV1 management frame, the contents of the MMPDU body after removing protection may be delivered to the SME via the MLME primitive specified for the MMPDU or PV1 management frame (instead of via the MA-UNITDATA indication primitive).

[0202] Although features and elements are described above in specific combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, it should be understood by those skilled in the art that the features and elements described above include means for implementing the methods described herein. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital versatile disks (DVDs). A processor in association with software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MLD, STA, AP, relay node, mesh node, customer premises equipment (CPE), fixed wireless access (FWA) device, industrial device, or any host.

Claims

1. A method for a station (STA) communicating with an access point (AP) in non-multi-link operation (MLO), the method comprising: Increment the packet number (PN); Constructing Additional Authentication Data (AAD) based on the plain text Media Access Control (MAC) Protocol Data Unit (MPDU) header and the Association and Authentication MAC (aaMAC) address; constructing a random number based on the aaMAC address, the PN, and the priority value of the MPDU; forming an encrypted MPDU based on the MPDU header, ciphertext, a cryptographic message integrity code (MIC), and a counter mode with a Cipher Block Chaining Message Authentication Code Protocol (CCMP) header, wherein the cryptographic MIC is formed based on the ADD and the random number; as well as The encrypted MPDU is transmitted.

2. The method according to claim 1, wherein The aaMAC address is different from a multi-link device (MLD) MAC address.

3. The method according to claim 1, wherein The aaMAC address is a securely exchanged MAC address.

4. The method according to claim 1, wherein The aaMAC address is a MAC address used in the association and authentication process between the AP and the STA.

5. The method according to claim 1, wherein The aaMAC address is indexed in a Robust Security Network Association (RSNA), and wherein the aaMAC address is used to set the RSNA.

6. The method according to claim 1, wherein The aaMAC address is different from the over-the-air MAC (otaMAC) address, which is used during the association process.

7. The method according to claim 1, wherein The aaMAC address is used to route traffic to the STA on a distributed system (DS) network segment.

8. The method according to claim 1, wherein The aaMAC address is used for mobility-related operations.

9. The method according to claim 8, wherein The aaMAC address is used for a fast switching mechanism.

10. The method according to claim 1, wherein The CCMP header is constructed based on the PN and a key identification (KeyID) associated with the aaMAC address.

11. The method according to claim 1, wherein The ciphertext is formed based on the AAD, the random number, the data of the plaintext MDPU and the temporary key (TK) associated with the aaMAC address; and wherein the encrypted MIC is further formed based on the data of the plaintext MDPU and the TK associated with the aaMAC address.

12. A station (STA) communicating with an access point (AP) in non-multi-link operation (MLO), the STA comprising: transceiver; as well as a processor operatively coupled to the transceiver; wherein: The processor is configured to increment a packet number (PN); The processor is configured to construct additional authentication data (AAD) based on a plain text medium access control (MAC) protocol data unit (MPDU) header and an association and authentication MAC (aaMAC) address; The processor is configured to construct a random number based on the aaMAC address, the PN, and a priority value of the MPDU; The processor is configured to form an encrypted MPDU based on the MPDU header, ciphertext, an encrypted message integrity code (MIC), and a counter mode with a Cipher Block Chaining Message Authentication Code Protocol (CCMP) header, wherein the encrypted MIC is formed based on the AAD and the random number; and The transceiver and the processor are configured to transmit the encrypted MPDU.

13. The STA according to claim 12, wherein: The aaMAC address is different from a multi-link device (MLD) MAC address.

14. The STA according to claim 12, wherein: The aaMAC address is a securely exchanged MAC address.

15. The STA according to claim 12, wherein: The aaMAC address is a MAC address used in the association and authentication process between the AP and the STA.

16. The STA according to claim 12, wherein: The aaMAC address is indexed in a Robust Security Network Association (RSNA), and wherein the aaMAC address is used to set the RSNA.

17. The STA according to claim 12, wherein: The aaMAC address is different from the over-the-air MAC (otaMAC) address, which is used during the association process.

18. The STA according to claim 12, wherein: The aaMAC address is used to route traffic to the STA on a distributed system (DS) network segment.

19. The STA according to claim 12, wherein: The aaMAC address is used for mobility-related operations.

20. The STA according to claim 19, wherein: The aaMAC address is used for a fast switching mechanism.

21. The STA according to claim 12, wherein: The CCMP header is constructed based on the PN and a key identification (KeyID) associated with the aaMAC address.

22. The STA according to claim 12, wherein: The ciphertext is formed based on the AAD, the random number, the data of the plaintext MDPU and the temporary key (TK) associated with the aaMAC address; and wherein the encrypted MIC is further formed based on the data of the plaintext MDPU and the TK associated with the aaMAC address.

Images