Mechanism for A1 filtering, anonymization and de-anonymization in wireless networks

Abstract

During association with the AP, an association and authentication media access control (aaMAC) address is allocated to a station (STA). The STA initially communicates using an aaMAC address, and may then communicate using an over-the-air MAC (otaMAC) address to maintain anonymity. Filtering techniques may be used to associate frames having active aaMAC addresses with temporary otaMAC addresses, requesting and responding to the frames using an active MAC address set to exchange the temporary otaMAC addresses between nodes. The STA transmits a frame to a node (e.g., STA2) using an association associated with the STA and an aaMAC address, and transmits a first active MAC address set request to the node including an otaMAC address for wireless transmissions from the STA. The STA2 performs a reciprocal procedure and may randomly exchange subsequent communications between STAs using otaMAC addresses and / or aaMAC addresses to enhance privacy.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 489,599, filed on March 10, 2023, which is incorporated herein by reference in its entirety. Background Art

[0002] User privacy is threatened when users can be tracked in public places. In wireless local area networks (WLANs), the current use of fixed media access control (MAC) addresses for non-access point (AP) stations (STAs) associated in an extended service set (ESS) or basic service set (BSS) allows for easy tracking of individual non-AP STAs within the coverage area of ​​an ESS or BSS. If a user changes their MAC address to avoid being tracked, they must currently re-establish their association with the ESS or BSS, requiring them to re-identify themselves, establish a new security context (new security keys), and be assigned a new IP address. While this reduces the user's ability to be tracked while associated with the ESS or BSS, it does so at the considerable overhead (OH) cost of having to re-establish their association each time. Allowing non-AP STAs to frequently change their MAC addresses (and / or any other traceable header content) without incurring the OH cost of having to re-establish their ID and security context is highly desirable, as it would increase the privacy of the non-AP STA without causing network inefficiencies. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding can be obtained by the following detailed description given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are examples. Therefore, each figure ("FIG") and detailed description should not be considered limiting, and other equally effective examples are possible and intended. In addition, the same reference numerals ("ref") in the various figures indicate the same elements, and wherein: Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented; Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system is shown; Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used in the illustrated communication system; Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of yet another example RAN and yet another example CN used in the communication system shown; Figure 2 is an example active MAC address set request element format; Figure 3 is an example management request field format; Figure 4 is an example active MAC address set response element format; Figure 5 is an example management response field format; Figure 6 is a message sequence chart illustrating an example method for protecting active MAC addresses in request and response frames in a WLAN according to one example embodiment; Figure 7 is an example active MAC address set request element to modify the MAC addresses of dotllActiveMACAddressesSet associated with a transmitting aaMAC and stored in a receiving station; Figure 8 is an example management request field format for an element of Figure 7 Figure 9 is an example active MAC address set response element format for signaling the result of a management operation, including a transmitting aaMAC field and a status field; Figure 10 is an example status field format for an element of Figure 9 Figure 11 is a message sequence chart illustrating an example method for protecting active MAC addresses in request and response frames according to example embodiments; and Figure 12 is an example flow chart of a method according to embodiments. DETAILED DESCRIPTION

[0004] ​​In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the following description. Also, embodiments and examples not specifically described herein can be implemented in conjunction with the embodiments and other examples specifically described, implied, and / or inherently provided (collectively, “provided”) herein. Although various embodiments are described and / or claimed herein, it should be understood that any embodiment, including any currently described or potentially implemented embodiment, can be implemented with any device, system, apparatus, etc. and / or any element thereof configured to perform any operation, process, algorithm, function, etc. and / or any portion thereof.

[0005] Example communication system The methods, apparatus and systems provided herein are well suited to communications involving wired and wireless networks. Reference is made to Figures 1A-1D An overview of various types of wireless devices and infrastructure are provided, where various elements of the network can utilize, perform, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus and systems provided herein.

[0006] Figure 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can 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-tail unique-word discrete Fourier transform spread orthogonal frequency division multiplexing (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource block-filter OFDM, filter bank multicarrier (FBMC), and / or the like.

[0007] As Figure 1AAs shown, the communication system 100 can 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, though 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 can 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 can be referred to as a station (STA)), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, 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 (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0008] The communication system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can 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 the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode-B (eNB), a Home Node-B, a Home eNode-B, a next generation Node-B (gNode B or gNB), a new radio (NR) Node-B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0009] The base stations 114a can be part of a RAN 104 that can 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. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide service to a particular geographic area that can be a relative fixed geographic area or can change over time. Cells can also be divided into cell sectors depending on the coverage area covered by the base stations 114a and 114b. For example, a cell with three cell sectors can be associated with the base station 114a. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In another embodiment, the base station 114a can utilize MIMO technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0010] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

[0011] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

[0013] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0014] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0015] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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 EDGE (GERAN), and the like.

[0016] For example, Figure 1AThe base station 114b in the embodiment can be a wireless router, Home Node B, Home eNode-B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. Figure 1A

[0017] The RAN 104 can be in communication with the CN 106, which can 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. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing 5G, GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] ​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) from 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.

[0019] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-modal 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 WTRU 102c shown in FIG. 1 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.

[0020] Figure 1B is a system diagram illustrating an example 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.

[0021] The processor 118 can 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but can be integrated together in an electronic package or chip.

[0022] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the 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 an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF 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.

[0023] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to enable the WTRU 102 to transmit and receive wireless signals over the air interface 116.

[0024] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0025] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can 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).

[0026] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can 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, and the like.

[0027] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0028] The processor 118 can also be coupled to other peripherals 138 that can 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 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands -free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, an electronic game player module, an Internet browser, a virtual reality and / or an augmented reality (VR / A R) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors. The sensors can 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 posture sensor, a biometric sensor, a humidity sensor, and the like.

[0029] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals associated with a particular subframe, or transmission and reception, can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or eliminate self-interference and / or cross- interference due to concurrent or simultaneous transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals associated with a particular subframe are time divided.

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

[0031] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can 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 can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0032] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1C

[0033] Figure 1C The CN 106 shown in FIG. 10 can 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 can be owned and / or operated by an entity other than the CN operator.

[0034] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can 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 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0036] The SGW 164 can be connected to the PGW 166, which can 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.

[0037] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide

[0038] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such terminals can use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0039] In representative embodiments, the other network 112 can be a WLAN.

[0040] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. For example, traffic between STAs within a BSS can be sent through the AP, where a source STA can send traffic to the AP and the AP can deliver the traffic to a destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between (e.g., directly between) source and destination STAs with a direct link setup (DLS). In certain representative embodiments, DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode can not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as “ad-hoc” mode of communication.

[0041] When using an 802.11 ac infrastructure mode of operation or similar modes of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) 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 802.11 systems, with collision avoidance. For CSMA / CA, a STA, including the AP, (e.g., each STA) can sense the primary channel. If a particular STA senses / detects that the primary channel is busy, the particular STA can back off. Only one STA can transmit at any given time in a given BSS.

[0042] High Throughput (HT) STAs can use 40 MHz wide channels for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0043] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be parsed into two streams by a segment parser, which can divide the data into the two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described 80+80 configuration operations can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0044] 802.11af and 802.11ah support sub-1 GHz modes of operation. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in 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 representative embodiments, 802.11ah can support metering type control / Machine Type Communication (MTC), such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0045] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11η, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the largest 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 STAs that support (e.g., only support) 1 MHz mode, the primary channel can be 1 MHz wide, even if other STAs in the AP and 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 with transmissions to the AP due to a STA (supporting only 1 MHz operating mode), for example, all available frequency bands can be considered busy, even if most of the available frequency bands remain idle.

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

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

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

[0049] The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or lasting a variable length of absolute time).

[0050] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of the gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal s in the unlicensed frequency band to communicate with the gNBs 180a, 180b, 180c. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / wirelessly couple to the gNBs 180a, 180b, 180c, while also communicating / wirelessly coupling with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, the eNode-Bs 160a, 160b, 160c can serve as the WTRUs' 102a, 102b, 102c mobility anchor point, and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to the WTRUs 102a, 102b, 102c serving as a supplemental nodes.

[0051] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking with E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 180a, 180b, 180c over an Xn interface.

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

[0053] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as the control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the types of services utilized by the WTRUs 102a, 102b, 102c. For example, different network slices can 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, and the like. The AMF 182a, 182b can provide the control plane functionality to manage the WTRU 102a, 102b, 102c

[0054] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address

[0055] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can 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 UPF 184, 184b can 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.

[0056] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can 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. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface, and the UPF 184a, 184b can be connected to the DN 185a, 185b via an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0057] In view of Figures 1A-1D And Figures 1A-1D corresponding description, one or more or all of the functions described herein with regard to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate network and / or WTRU functionality.

[0058] The one or more emulation devices can perform one or more, or all, of the functions while implemented / deployed: (1) as part of a wired and and / or wireless communication network, (2) outside of a wired and and / or wireless communication network, and / or (3) during implementation and / or deployment of a wired and / or wireless communication network. For example, one or more emulation devices can perform one or more, or all, of the functions while being implemented / deployed as part of a test bench for a wired and / or wireless communication network. In another example, one or more emulation devices can perform one or more, or all, of the functions while being implemented / deployed in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to test components, devices, and / or networks not yet deployed in a wired and / or wireless communication network.

[0059] The one or more emulation devices can perform one or more, or all, of the functions while implemented / deployed: (1) as part of a wired and and / or wireless communication network, (2) outside of a wired and and / or wireless communication network, and / or (3) during implementation and / or deployment of a wired and / or wireless communication network. For example, one or more emulation devices can perform one or more, or all, of the functions while being implemented / deployed as part of a test bench for a wired and / or wireless communication network. In another example, one or more emulation devices can perform one or more, or all, of the functions while being implemented / deployed in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to test components, devices, and / or networks not yet deployed in a wired and / or wireless communication network.

[0060] Examples provided herein do not limit applicability of the subject matter to other wireless technologies, e.g., using the same or different principles that can apply.

[0061] As explained herein, a wireless transmit / receive unit (WTRU) can be an example of a user equipment (UE). Accordingly, the terms “UE” and “WTRU” can be used herein in the same range.

[0062] MAC privacy enhancements IEEE 802.11 has seen a trend in the past few years to use WLAN technology to provide new mechanisms to protect personal privacy. One major area of work in this area in the past few years has been to protect users from attacks by people tracking them. This means that when a user roams to different locations and IEEE 802.11 or similar networks, the user’s possible identification is to be protected.

[0063] Some modifications to the baseline specification were introduced in IEEE 802.11aq to support current MAC privacy features. These features focus on protecting the privacy of users in the unassociated state. In the following, the current status of MAC privacy enhancements in the baseline specification is described (note that the baseline specification is IEEE 802.11-2020), and new work is being done in IEEE 802.11bi and IEEE 802.11bh specifications.

[0064] As described herein, for the purposes of the discussion herein, the specifications IEEE 802.11-REVme / D2.0 and IEEE 802.11be / D2.3 are considered as the reference baseline. However, the reference to IEEE 802.11-REVme / D2.0 and IEEE 802.11be / D2.3 should not be considered as a limitation to the innovations described herein.

[0065] Several features of IEEE 802.11 can be used to track a user. Before associating to an AP, a STA defines the MAC address it will use for the association. Before the MAC privacy enhancements were added to the baseline specification, a STA will use a fixed MAC address (usually the one provided by the device manufacturer) for all associations. This behavior makes the tracking of a STA trivial, as observing the MAC address in the pre-association message allows to track and identify the STA. The addition of the MAC privacy enhancements to the baseline specification allows to change the fixed MAC address to a random MAC address, called Random and Changing MAC Address (RCM). This increases the user privacy by removing this simple technique to track a STA. However, when a STA associates with a network, it also requires the STA to keep its MAC address, allowing the associated STA to be tracked.

[0066] In addition to the MAC address, there are other mechanisms in IEEE 802.11 that can be used to track an associated STA. For example, each frame in a communication has an associated Sequence Number (SN). Even if the STA MAC address changes during the association, this sequence number can be used to track the STA, as consecutive frames will show consecutive sequence numbers. Some other mechanisms are more complex, such as the OFDM PHY data scrambler, which can also be tracked if not re-seeded.

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

[0068] As indicated in the standard, the MAC privacy enhancements “mitigate this traffic analysis, the ability of a STA to support periodic and random changes of its MAC address and the resetting of counters and seeds before association. When discovering a network, a STA can avoid gratuitously transmitting a Probe Request frame containing the preferred BSS network’s SSID”.

[0069] Requirements to support MAC privacy enhancements The baseline specification defines a set of requirements to apply the MAC address randomization, including: - A STA can periodically change its MAC address to a random value without being associated to a BSS; - A STA can construct a randomized MAC address according to the locally managed address space defined in IEEE Std 802-2014 and IEEE Std 802c-2017; - A non-AP STA can not change its MAC address during transaction exchanges (e.g., transmitting public action frames for pre-association discovery) or during the creation of a state on an AP using pre-association capabilities (e.g., RSN pre-authentication or FT on DS); - If a non-AP STA starts any transaction that establishes a state bound to a MAC address and decides to establish an association or a transaction state with a discovered BSS, it can change the MAC address to the one used to establish that state; - States created by an AP using a previous MAC address, such as Robust Security Network (RSN) pre-authentication state or Fast Transition (FT) state established on DS, are bound to the MAC address used when creating that state; and - In non-association states, all the counters in the sequence number space used to identify each frame must be reset each time the MAC address is changed to a new random value.

[0070] A non-AP STA connected to an infrastructure BSS can keep a single MAC address during its connection across an ESS, as the security association between the AP / ESS and the STA is linked to the MAC address. If the non-AP STA wishes to change its MAC address, it must re-establish the security association (identity, IP address, and security keys) each time it changes its MAC address.

[0071] While the currently specified MAC privacy enhancements greatly improve the privacy of users, it has proven to be insufficient to provide an acceptable level of user privacy (i.e., since the fixed MAC address of an associated user, they can be easily tracked as they move in public spaces). For this reason, IEEE 802.11 created the RCM Study Group to study enhancements to user privacy and how to improve the operation of networks using MAC address randomization.

[0072] The RCM Study Group concluded its work in 2020 and created and accepted two Project Authorization Requests (PARs), which in turn created two 802.11 Task Groups: (i) IEEE 802.11bi: Enhanced Services with Data Privacy Protection; and (ii) IEEE 802.11bh: Operation with Randomized and Changing MAC Addresses.

[0073] The focus of IEEE 802.11bi is to specify modifications to the IEEE Std 802.11 MAC to include new mechanisms to address and improve user privacy.

[0074] The focus of IEEE 802.11bh is to specify modifications to the MAC mechanism to preserve existing services (which otherwise can be limited in an environment where STAs use RCM) without reducing the user privacy gains provided by RCM. IEEE 802.11bh will work on mechanisms to achieve session continuity without any mapping of unique MAC addresses to STAs.

[0075] As previously mentioned, user privacy is compromised when users can be tracked in public places. The current use of fixed MAC addresses of associated non-AP STAs in an ESS or BSS allows easy tracking of individual non-AP STAs in the coverage area of the ESS or BSS. If a user changes their MAC address to avoid being tracked, the user currently has to re-establish their association with the ESS or BSS, which requires the user to re-identify themselves, establish a new security context (new security key) and be assigned a new IP address. While this will reduce the ability of the user to be tracked during their association with the ESS or BSS, it is done at the cost of a considerable overhead (OH) to re-establish their association each time. It is highly desirable to allow non-AP STAs to frequently change their MAC address (as well as any other trackable header content) without incurring the OH cost of having to re-establish their ID and security context, as this will increase the privacy of non-AP STAs without causing network inefficiencies.

[0076] Embodiments described herein relate to methods, devices, and message formats to implement Al address filtering when a communicating STA changes its MAC address. In addition and to improve privacy, embodiments can include hiding the sequence number of a frame, e.g., obfuscating the sequence number based on the set of addresses used in the frame.

[0077] Definitions According to various embodiments, two media access control (MAC) definitions are provided, including an association and authentication MAC (aaMAC) address and an over-the-air MAC (otaMAC) address. The aaMAC address corresponds to the MAC address used for the association and authentication procedure between an AP and a STA, and is the address indexed in RSNA (robust security network association). This MAC address is used to establish the RSNA, to route traffic to the STA on the DS network segment, and it is also the address used for mobility related operations (e.g. fast transition mechanisms). The otaMAC address is a temporary MAC address used in frames transmitted over the air. The distribution system (DS) bit of the IEEE 802.11 frame indicates the direction of transmission. For individually addressed frames, where the To DS bit is set to 1 and the From DS bit is set to 0, the otaMAC is transmitted as address-2. For individually addressed frames, where the To DS bit is set to 0 and the From DS bit is set to 1, the otaMAC is transmitted as address-1. The purpose of using the otaMAC is to keep the aaMAC of the STA private, and the otaMAC can potentially be changed on a packet basis.

[0078] Using different MAC address sets for each peer STA and communication direction can include filtering anonymization and de-anonymization and / or messages to manage active MAC sets, as further described below.

[0079] Embodiment 1: Using different MAC address sets for each peer STA and communication direction A1 Filtering and anonymization / de-anonymization Modification of the MAC address used in communication during association requires a mechanism to maintain a list of MAC addresses that can be used by the receiving and transmitting STAs. Modifying the MAC address impacts A1 filtering, and requires modification of the MAC procedure. In one example innovative embodiment, the anonymization and de-anonymization blocks are included in the MAC processing. In this embodiment, it is assumed that each communicating STA pair can define a specific set of otaMAC addresses to be used as the RX (A1) and TX (A2) addresses for each communication direction. This does not preclude using the same address or different addresses for the two directions of communication (i.e. UL and DL communication).

[0080] Each enhanced privacy (EP) STA maintains a record of the aaMAC used during association (aaMAC STA), and each EP STA involved in communication maintains a set of Tx active MAC addresses and a set of Rx active MAC addresses for each STA to which it transmits or receives frames.

[0081] In an innovative embodiment, the Tx active MAC address set can include two lists. The first list contains the mapping between the aaMAC of the peer STA (aaMAC_pSTA) and the list of addresses selected by the peer STA and indicated to the STA from which the STA receives frames (A1) (e.g., otaMAC_pA1 address list). The second list contains the mapping between the aaMAC of the peer STA (aaMAC_pSTA) and the list of addresses that the STA can use to transmit frames to the peer STA (e.g., otaMAC_A2 address list). The Tx active MAC addresses are used to transmit frames to the peer STA.

[0082] In an innovative embodiment, the Rx active MAC address set can also include two lists. The first list contains the mapping between the aaMAC of the peer STA (aaMAC_pSTA) and the list of addresses that the STA can use to receive information from the peer STA (otaMAC_A1 address list). The second list contains the mapping between the aaMAC of the peer STA (aaMAC_pSTA) and the list of addresses that the peer STA can use as Tx addresses to transmit frames to the STA (otaMAC_pA2 address list).

[0083] In various related embodiments, the pool of addresses that the STA uses to receive frames from the peer STA (otaMAC_A1) and the pool of addresses that the STA uses to send frames to the peer STA (otaMAC_A2) can be the same or different. Moreover, after the signaling exchange, the Tx active MAC set of the transmitting STA and the Rx active MAC set of the receiving STA can be synchronized and store the same information. Thus, the Tx or Rx active MAC address set is dynamic and can change during the communication or association.

[0084] In an example method, given the Tx active MAC address set stored in the STA, the transmission process starts with the anonymization process of the frame, which starts with the STA processing the MAC protocol data unit (MPDU) to be transmitted. It first compares the Rx (A1) address on the MPDU with the aaMAC_pSTA stored in the different Tx active MAC address sets. Once found, the transmitting STA can choose among all otaMAC_pA1 addresses and all otaMAC_A2 addresses in the identified Tx active MAC address set. The MPDU is then modified, exchanging the A1 and A2 addresses with the newly selected otaMAC_pA1 and otaMAC_A2, and the processing continues.

[0085] In an example method, the reception procedure starts by a STA receiving a unicast frame and performing Al filtering. The receiving STA compares the Al address in the received frame with the list of otaMAC_A1 addresses stored in the set of all Rx active MAC addresses. If found, the process can continue, otherwise the frame should be discarded. After checking Al, an Enhanced Privacy (EP) or Enhanced Data Privacy (EDP) receiving STA can check the A2 address, comparing it with the otaMAC_pA2 addresses stored in the set of Rx active MAC addresses (note that the aaMAC_pSTA is already known by the receiving STA due to step 1). If found, the frame is modified, the aaMAC_pSTA of the transmitting STA (stored in the set of Rx active MAC addresses) swaps the Al address and the receiving aaMAC_STA (locally known) swaps the A2 address.

[0086] Messages to manage the active MAC set, different MAC address sets for each peer STA and communication direction Embodiments in this regard relate to information that can be carried by possible frames to indicate the addition or removal of MAC addresses to the active MAC address pool. The following specific frame / element / field formats are example implementations, and implementations that carry similar information in other types of frames, elements, or fields can also be used. The innovations here can be standardized for use by STAs in wireless networks. As such, the innovations described below can be included in a wireless specification such as IEEE 802.11bi or other wireless specification.

[0087] In one innovative embodiment, an action frame is defined, e.g., an Active MAC Address Set Management Request frame format. This frame enables the implementation of adding, deleting, or requesting the complete active MAC address set. One example of an action frame is a public action frame, which can include the fields / descriptions shown in Table 1 below: Common Action field value Description TBD Active MAC Address Set Management Request TBD Active MAC Address Set Management Response Table 1: Example of a public action frame for active MAC address set management request and response.

[0088] These frames help to protect the frames that exchange MAC sets. Such frames can be defined as protected public action frames, but different implementations can define them as another type of protected action frame. For example, a new category created for protected enhanced privacy action frames can be referred to as robust action frames (non-public).

[0089] Active MAC Address Set Management Request frame format: An Active MAC Address Set Management Request frame can be sent to a STA to manage the active MAC address set associated with the transmitting STA stored in the receiving STA. The Action field of the Active MAC Address Set Management Request frame can contain the information shown in Table 2 below. Command Information 0 Category 1 Common Action 2 Conversation Token 3 Active MAC Address Set Request Table 2: Action field information for the MAC Address Set Management Request frame.

[0090] The innovations herein include the Active MAC Address Set Request field described herein.

[0091] Active MAC Address Set Management Response frame format: The Active MAC Address Set Management Response frame is a reply to the requesting STA to indicate the status of the request to manage its Active MAC Address Set. In one embodiment, the Action field of the Active MAC Address Set Management Response frame can contain the information shown in Table 3 below. Command Information 0 Category 1 Common Action 2 Conversation Token 3 Active MAC Address Set Response Table 3: Action field information for the MAC Address Set Management Response frame.

[0092] The Active MAC Address Set Response is newly defined herein and serves the purposes described herein and includes the information described herein. The information carried in the Active MAC Address Set element can be implemented in different fields. Below are examples of implementations in the element fields.

[0093] Active MAC Address Set Request: The Active MAC Address Set Request element is used to signal the desire to include, remove, or list MAC addresses belonging to the dotllActiveMACAddressesSet associated with the transmitting aaMAC and stored in the receiving STA. An example format of the Active MAC Address Set Request element is shown in Figure 2 and can generally include: Element ID, Length and Element ID Extension field, Transmitting aaMAC field, Management Request field, and other fields as shown.

[0094] The Transmitting aaMAC field includes the transmitting aaMAC_pSTA associated with the transmitting STA. Note that the transmitting MAC address (A2) of the frame carrying this element can already be included in the Rx Active MAC Address Set (otaMAC_pA2) associated with the transmitting aaMAC (aaMAC_pSTA) on the receiving STA.

[0095] Referring to Figure 3 , an example format of the Management Request field of the MAC Address Set Request element of Figure 2 is shown. In certain embodiments, the format of the Management Request field can include one or more of the following indicators and / or purposes: - The List Set bit set to 1 indicates the request to list the addresses in the Active MAC Address Set. Otherwise it indicates that the transmitter does not request the receiver to list its Active MAC Address Set.

[0096] - Add Tx Address bit = 1 indicates that the Add Tx Address Count and Add Tx Address List fields are present in the Active MAC Address Set Request element.

[0097] - Add Rx Address bit = 1 indicates that the Add Rx Address Count and Add Rx Address List fields are present in the Active MAC Address Set Request element.

[0098] - Remove Tx Address bit = 1 indicates that the Remove Tx Address Count and Remove Tx Address List fields are present in the Active MAC Address Set Request element.

[0099] - Remove Rx Address bit = 1 indicates that the Remove Rx Address Count and Remove Add Rx Address List fields are present in the Active MAC Address Set Request element.

[0100] - Tx_Salt Value Present bit set to 1 indicates that the Tx_Salt Value field is included in the Active MAC Address Set Request element.

[0101] - Tx_MS Size Present bit set to 1 indicates that the Tx Active MAC Address Set Size field is included in the Active MAC Address Set Request element.

[0102] - Rx_MS Size Present bit set to 1 indicates that the Rx Active MAC Address Set Size field is included in the Active MAC Address Set Request element.

[0103] - Add Tx Address Count field specifies the number of MAC addresses in the Add Tx Address List field.

[0104] - Add Tx Address List field contains zero or more MAC addresses to be added to the receiving STA's Rx Active MAC Address Set.

[0105] - Add Rx Address Count field specifies the number of MAC addresses in the Add Rx Address List field.

[0106] - Add Rx Address List field contains zero or more MAC addresses to be added to the receiving STA's Tx Active MAC Address Set.

[0107] - Remove Tx Address Count field specifies the number of MAC addresses in the Remove Tx Address List field.

[0108] - Remove Tx Address List field contains zero or more MAC addresses to be removed from the receiving STA's Rx Active MAC Address Set.

[0109] - Remove Rx Address Count field specifies the number of MAC addresses in the Remove Rx Address List field.

[0110] - Remove Rx Address List field contains zero or more MAC addresses to be removed from the Tx Active MAC Address Set of the receiving STA.

[0111] The STA transmitting this element indicates the MAC address used by the transmitting STA. The MAC addresses included in the (Add / Remove) Tx Address List list correspond to the MAC addresses that the transmitting STA can use as Tx Address (A2) in the frames transmitted by the STA. Thus, the (Add / Remove) Tx Address List includes the addresses to be added or removed from the Rx Active MAC Address Set (otaMAC_pA2 list). In the same way, the MAC addresses included in the (Add / Remove) Rx Address List field correspond to the MAC addresses that the transmitting STA can use as Rx Address (Al) in the frames received by the STA. Thus, the (Add / Remove) Rx Address List includes the addresses to be added or removed from the Tx Active MAC Address Set (otaMAC_pAl list).

[0112] Tx_Salt Value subfield is a value that can be used to anonymize the sequence number of the frames transmitted by the frame transmitting STA to the receiving STA (or any other field in the frames transmitted in clear or constant, and allowing the matching of otaMAC with aaMAC). Tx Active MAC Address Set Size indicates the maximum number of MAC addresses that the Tx Active MAC Address Set of the transmitting STA can contain. Rx Active MAC Address Set Size indicates the maximum number of MAC addresses that the Rx Active MAC Address Set of the transmitting STA can contain.

[0113] In certain embodiments, an Active MAC Address Set Response can not be needed, e.g., the Active MAC Address Set Request is simply acknowledged using an ACK reply. In other embodiments, an Active MAC Address Set Response is utilized, as further described below.

[0114] Active MAC Address Set Response: The Active MAC Address Set Response element is used to signal the result of a management operation on the Active MAC Address Set of the transmitting STA, which is referred to as the aaMAC address of the requesting STA.

[0115] Reference Figure 4Figure 6 shows an example format of the Active MAC Address Set Response element, and can include fields for Element ID, Length, Element ID Extension, Transmit aaMAC, Management Response, Tx Address Count, Tx Address List, Rx Address Count, and Rx Address List. The Transmit aaMAC field includes the transmit aaMAC_pSTA associated with the transmitting STA. Note that the transmit MAC address (A2) of the frame carrying this element can already be included in the Rx Active MAC Address Set (otaMAC_pA2) associated with the transmit aaMAC on the receiving STA (aaMAC_pSTA).

[0116] Reference Figure 5 Figure 6 shows an example format of the Active MAC Address Set Response element, and can include fields for Element ID, Length, Element ID Extension, Transmit aaMAC, Management Response, Tx Address Count, Tx Address List, Rx Address Count, and Rx Address List. The Transmit aaMAC field includes the transmit aaMAC_pSTA associated with the transmitting STA. Note that the transmit MAC address (A2) of the frame carrying this element can already be included in the Rx Active MAC Address Set (otaMAC_pA2) associated with the transmit aaMAC on the receiving STA (aaMAC_pSTA). Figure 4 Figure 6 shows an example format of the Active MAC Address Set Response element, and can include fields for Element ID, Length, Element ID Extension, Transmit aaMAC, Management Response, Tx Address Count, Tx Address List, Rx Address Count, and Rx Address List. The Transmit aaMAC field includes the transmit aaMAC_pSTA associated with the transmitting STA. Note that the transmit MAC address (A2) of the frame carrying this element can already be included in the Rx Active MAC Address Set (otaMAC_pA2) associated with the transmit aaMAC on the receiving STA (aaMAC_pSTA). - The status bit is set to 0 if the operation requested in the Active MAC Address Set Request element has succeeded. The status bit is set to 1 if the operation requested in the Active MAC Address Set Request element has failed.

[0117] - The Tx Address bit indicates that the Tx Address Count and Tx Address List fields are present in the Active MAC Address Set Request element.

[0118] - The Rx Address bit indicates that the Rx Address Count and Rx Address List fields are present in the Active MAC Address Set Request element.

[0119] Figure 4 The Address Count field of the Response element specifies the number of Tx or Rx MAC addresses in the corresponding subsequent Address List field. The Address List field contains zero or more MAC addresses to indicate the set of MAC addresses to be added or removed from the Active MAC Address Set of the receiving STA.

[0120] Figure 4 The STA Transmit Response element can provide the contents of its Rx and / or Tx Active MAC Address Set upon request. In this case, the Tx and / or Rx Address List fields are included in the element using the Tx Address and Rx Address bits. The Tx Address field can provide a list of otaMAC_pA2 addresses associated with the requesting aaMAC_pSTA. The Rx Address field can provide a list of otaMAC_pAl addresses associated with the requesting aaMAC_pSTA.

[0121] As mentioned previously, it is important to protect the Active MAC Address Set Request and Response frames. The following embodiments describe example methods of protected dual frames using common action frames, but other protections such as self-protected action frames can also be alternative or additional protection mechanisms.

[0122] Protected dual frames for public action frames: The active MAC address set request and active MAC address set response action frames should be protected and thus should include the public action field values defined for protected dual frames for public action frames, as shown in Table 4 below. Common Action field value Description IEEE Standard Paragraph Reference TBD Active MAC Address Set Request <To be defined> TBD Active MAC Address Set Response <To be defined> Table 4: Public action field values for protected dual frames for public action frames.

[0123] Reference Figure 6 , shows a method for protecting MAC addresses according to certain embodiments, and the method can include the following steps as shown in the figure: 601 : STA_A and STA_B associate (one of the STAs A or B can be the AP). By associating, two aaMAC addresses are defined, e.g. aaMAC_A for STA_A and aaMAC_B for STA_B.

[0124] 602: At this point, the Rx and Tx active MAC address sets are formed by the aaMAC of each STA. The communication uses the aaMAC as the address in the frames following the standard mechanisms.

[0125] 603: STA_A adds two (can be any number) addresses, otaMAC_A1_1 and otaMAC_A2_1, to its Rx and Tx active MAC address sets. The former is used as the receive address and the latter as the transmit address. This is done by the transmission of an active MAC address set request frame, as described previously.

[0126] 604: STA_B acknowledges the operation and adds otaMAC_A1_1 to its Tx active MAC address set and otaMAC_A2_1 to its Rx active MAC address set. This is acknowledged by the transmission of an active MAC address set response frame.

[0127] 605: Frames sent by STA_A can now use aaMAC_A or otaMAC_A2_1 as the transmit address. The A1 filtering at STA_B is performed according to the standard, since A1 is aaMAC_B, de-anonymization can be performed by looking at the Rx active MAC address set associated with aaMAC_A.

[0128] 606: Frames sent by STA_B can now use aaMAC_A or otaMAC_A1_1 as the receive address (A1). STA_A performs A1 filtering by looking at the Rx active MAC address set, following the procedure described above.

[0129] 607: STA_B adds two (can be any random number) addresses, otaMAC_B1_1 and otaMAC_B2_1, to its Rx and Tx active MAC address set. The former is used as the receive address and the latter is used as the transmit address. This is done by transmitting an active MAC address set request frame.

[0130] 608: STA_A acknowledges the operation and adds otaMAC_B1_1 to its Tx active MAC address set and otaMAC_B2_1 to its Rx active MAC address set. This is acknowledged by the transmission of an active MAC address set response frame.

[0131] 609: Frames sent by STA_B can now use aaMAC_B or otaMAC_B2_1 as the transmit address and aaMAC_A or otaMAC_A1_1 as the receive address. A1 filtering at STA_A is performed by looking at the Rx active MAC address set as per the above steps. De-anonymization can be performed by looking at the Rx active MAC address set associated with aaMAC_B.

[0132] 610: Frames sent by STA_A can now use aaMAC_B or otaMAC_B1_1 as the receive address (A1) and aaMAC_A or otaMAC_A2_1 as the transmit address. STA_B performs A1 filtering by looking at the Rx active MAC address set and performs de-anonymization by looking at the Rx active MAC address set.

[0133] Embodiment 2: Anonymization / de-anonymization using single MAC address set In another innovative embodiment, a single MAC address set for anonymization / de-anonymization can be used. Modification of MAC addresses used in communication during association requires a mechanism to maintain a list of MAC addresses that can be used for receiving and transmitting STAs. Modification of MAC addresses impacts A1 filtering and requires a new block in the MAC procedure, called anonymization and de-anonymization block.

[0134] Each EP (Enhanced Privacy) STA maintains a record of aaMACs used in association (aaMAC_STA). Each EP STA involved in communication maintains a Tx active MAC address set and a Rx active MAC address set. The Tx active MAC address set contains a mapping between aaMAC addresses of peer STAs (aaMAC_pSTA) and a list of otaMAC addresses (otaMAC_pA1 list) advertised by the peer STAs for receiving / transmitting frames. This address list is also used as a MAC address to use as Tx address (A2) in received frames (otaMAC_pA2 list).

[0135] The Rx Active MAC address set includes a list of addresses (otaMAC_A1 list) that the STA uses to receive frames from a peer STA. This address list is also used as a MAC address to use as the Tx address (A2) in transmitted frames (OTA MAC_A2 list). Thus, the Tx or Rx Active MAC address set is dynamic and can change during communication or association.

[0136] Given the Tx and Rx Active MAC address sets stored in a given STA, the anonymization process of a frame starts by the STA processing the MPDU to be transmitted. It first compares the Rx (A1) address on the MPDU with the aaMAC_pSTA stored in the Tx Active MAC address set. Once found, the transmitting STA can choose among all otaMAC_pA1 addresses in the Tx Active MAC address set and all otaMAC_A2 addresses in the Rx Active MAC address set. The MPDU is then modified, exchanging the A1 and A2 addresses with the newly chosen otaMAC_pA1 and otaMAC_A2, and processing continues.

[0137] The receiving process starts by the STA receiving a unicast frame and performing A1 filtering. The receiving STA compares the A1 address in the received frame with the list of otaMAC_A1 addresses stored in the Rx Active MAC address set. If found, processing can continue, otherwise the frame should be discarded. After checking the A1, the EP receiving STA can check the received A2 address, comparing it with the otaMAC_pA2 addresses stored in the Tx Active MAC address set. If found, the frame is modified, exchanging the A1 address with the aaMAC_pSTA of the transmitting STA (stored in the Rx Active MAC address set) and exchanging the A2 address with the receiving aaMAC_STA.

[0138] Messages to manage the Active MAC set, for single MAC address set for anonymization / de-anonymization Embodiments of the innovation discuss frame formats to indicate the addition or removal of MAC addresses to / from the Active MAC address pool. The following specific formats are examples of possible implementations, implementations carrying similar information in other types of frames or fields are also possible. The innovation here can be standardized for use by STAs in wireless networks. As such, the innovation described below can be included in a wireless specification such as IEEE 802.11bi or other wireless specification.

[0139] Initially, an Action frame is defined, referred to as Active MAC Address Set Management Request frame format. As with previous embodiments, this frame enables the implementation of adding, removing or requesting the complete Active MAC address set.

[0140] The new common Action frame is defined as shown in Table 5 below: Common Action field value Description TBD Active MAC Address Set Management Request TBD Active MAC Address Set Management Response Table 5: Public Action Frames for Active MAC Address Set Management Request and Response.

[0141] As described in previous embodiments above, these frames are defined as protected public action frames, which help to protect the frames of exchanging MAC set. Different implementations can define them as other types of protected action frames. For example, the newly created category of protected enhanced privacy action frames here can be called robust action frames (non-public).

[0142] Active MAC Address Set Management Request Frame Format. The Active MAC Address Set Management Request frame is sent to a STA to manage the Active MAC Address Set associated with the transmitting STA stored in the receiving STA. The Action field of the Active MAC Address Set Management Request frame can include the information shown in Table 6 below. Command Information 0 Category 1 Common Action 2 Conversation Token 3 Active MAC Address Set Request Table 6: Action field information of Active MAC Address Set Management Request frame.

[0143] The Active MAC Address Set Request field is newly defined for the embodiments described here.

[0144] Active MAC Address Set Management Response Frame Format: The Active MAC Address Set Management Response frame is replied to a STA to indicate the status of the request to manage its Active MAC Address Set. The Action field of the Active MAC Address Set Management Response frame can include the information shown in Table 7 below. Command Information 0 Category 1 Common Action 2 Conversation Token 3 Active MAC Address Set Response Table 7: Action field information of Active MAC Address Set Management Response frame.

[0145] The Active MAC Address Set Response field is newly defined for the embodiments described here. The information carried in the Active MAC Address Set element can be implemented in different fields.

[0146] Active MAC Address Set Request: The Active MAC Address Set Request element is used to signal the desire to include, remove or list the MAC addresses belonging to the dotllActiveMACAddressesSet associated with the transmitting aaMAC and stored in the receiving STA. Figure 7 An example format is shown, which can include the fields of Element ID, Length and Element ID Extension. The Active MAC Address Set Request can also include the transmitting aaMAC field, which includes the transmitting aaMAC_pSTA of the transmitting STA. Note that the transmitting MAC address (A2) of the frame carrying this element can already be included in the Tx Active MAC Address Set associated with the transmitting aaMAC (aaMAC_pSTA) on the receiving STA.

[0147] Reference Figure 8 ,Figure 7 The example format of the Management Request field of the Active MAC Address Set Request element is shown. The Management Request field may provide the following indications: - List Set bit, when set to 1, indicates a request to list the addresses in the active MAC address set. Otherwise, it indicates that the transmitter has not requested the receiver to list its active MAC address set.

[0148] – AddAddress bit = 1 indicates that the AddAddressCount and AddAddressList fields are present in the ActiveMACAddressSetRequest element.

[0149] - Remove Address Bit = 1 indicates that the Remove Address Count and Remove Address List fields are present in the Active MAC Address Set Request element.

[0150] - Tx_Salt Present bit, when set to 1, indicates that the Tx_Salt field is included in the Active MAC Address Set Request element.

[0151] - Tx_MS Size present bit, when set to 1, indicates that the Tx Active MAC Address Set Size field is included in the Active MAC Address Set Request element.

[0152] - The Rx_MS Size present bit, when set to 1, indicates that the Rx Active MAC Address Set Size field is included in the Active MAC Address Set Request element.

[0153] Figure 7 The Address Count field of the Active MAC Address Set Request element in the

[00145] specifies the number of MAC addresses in the Address List field. The Address List field contains zero or more MAC addresses to indicate the MAC address set to be added or removed from the receiving STA's active MAC address set. The Tx_Salt subfield is a value that can be used to anonymize the sequence number of the frame transmitted by the frame transmitting STA to the receiving STA (or any other field in the frame transmitted in plain text or constant and allowing otaMAC to match aaMAC). The Tx Active MAC Address Set Size indicates the maximum number of MAC addresses that the transmitting STA's Tx Active MAC Address Set can contain, and the Rx Active MAC Address Set Size indicates the maximum number of MAC addresses that the transmitting STA's Rx Active MAC Address Set can contain.

[0154] In some embodiments, the Active MAC Address Set Response is not used because the request can simply be acknowledged by an ACK from the STA receiving the Request element. In other embodiments, the Active MAC Address Set Response element is used to signal the result of the management operation on the transmitting STA's active MAC address set, which is referred to as the requesting STA's aaMAC address.

[0155] Active MAC Address Set Response:Figure 9 The following figure shows an example format of an Active MAC Address Set Response element for one embodiment, which includes an element ID, a length and element ID extension field, a transmit aaMAC field, a status field, an address count field, and an address list field. The transmit aaMAC field includes the transmit aaMAC associated with the transmitting STA. Note that the transmit MAC address (A2) of the frame carrying this element may already be included in the Tx Active MAC Address Set associated with the transmit aaMAC (otaMAC_pA2) on the receiving STA.

[0156] The status field can have Figure 10 The example format is shown in Figure 1. If the requested operation in the Active MAC Address Set Request element has succeeded, the Status bit is set to 0; if the requested operation in the Active MAC Address Set Request element has failed, the Status bit is set to 1. The Status field may also include an Address List Included bit, which, when set to 1, indicates that the Address Count field and the Address List field are included in the Active MAC Address Set Response element. If the Address List Included bit is set to 0, these fields may not be included in the response element.

[0157] Figure 9 The Address Count field of the response element in the aaMAC_pResponse specifies the number of MAC addresses in the Address List field. The Address List field contains zero or more MAC addresses to indicate the MAC address set to be added or removed from the receiving STA's active MAC address set. A STA transmitting an Active MAC Address Set Response element can provide the contents of its Tx Active MAC Address Set for a given aaMAC_pSTA upon request.

[0158] As with the embodiment of protecting management request and response frames, protecting the active MAC address set request and response frames is important. An example method for protecting the active MAC address set request and response frames can use a protected double frame of a public action frame. Alternatively or additionally, other protection mechanisms can be utilized, such as self-protected action frames.

[0159] Protected Double Frame of Public Action Frame: In order to use the protected double frame of public action frame to protect the Active MAC Address Set Request and Active MAC Address Set Response action frames, the public action field value can be defined for the protected double frame of public action frame as shown in Table 8 below. Common Action field value Description IEEE Standard Paragraph Reference TBD Active MAC Address Set Request <To be defined> TBD Active MAC Address Set Response <To be defined> Table 8: Public Action field values ​​defined for the protected double frame of the Public Action frame.

[0160] refer to Figure 11 , a method for protecting active MAC address set request and response frames may include the steps shown in the figure: 1101 : STA_A and STA_B associate (one of them can be an AP). By associating, two aaMAC addresses are defined, aaMAC_A for STA_A and aaMAC_B for STA_B.

[0161] 1102 : At this point, the Rx and Tx active MAC address sets are formed by the aaMAC of each STA. Communication is done using the aaMAC as address in frames following the standard mechanisms.

[0162] 1103 : STA_A adds (can be random) an address, otaMAC_A1, to its Rx active MAC address set. This address can be used as receiving and transmitting address. This is done by transmitting an Active MAC Address Set Request frame.

[0163] 1104 : STA_B acknowledges the operation and adds otaMAC_A1 to its Tx active MAC address set. This is acknowledged by transmitting an Active MAC Address Set Response frame.

[0164] 1105 : Frames sent by STA_A can now use aaMAC_A or otaMAC_A1 as transmitting address. A1 filtering at STA_B is performed according to the standard, since A1 is aaMAC_B, de-anonymization can be performed by looking at the Rx and Tx active MAC address sets.

[0165] 1106 : Frames sent by STA_B can now use aaMAC_A or otaMAC_A1 as receiving address (A1 ). STA_A performs A1 filtering by looking at the Rx active MAC address set and de-anonymization by looking at the Rx and Tx active MAC address sets.

[0166] 1107 : STA_B adds (can be random) an address, otaMAC_B1, to its Rx and active MAC address sets. This address can be used as receiving and transmitting address. This is done by transmitting an Active MAC Address Set Request frame.

[0167] 1108 : STA_A acknowledges the operation and adds otaMAC_B1 to its Tx active MAC address set. This is acknowledged by transmitting an Active MAC Address Set Response frame.

[0168] 1109 : Frames sent by STA_B can now use aaMAC_B or otaMAC_B1 as transmitting address and aaMAC_A or otaMAC_A1 as receiving address. A1 filtering at STA_A is performed according to the steps described above by looking at the Rx active MAC address set. De-anonymization can be performed by looking at the Rx and Tx active MAC address sets associated with aaMAC_B.

[0169] 1110: The frame sent by STA A can now use aaMAC_B or otaMAC_B1 as the receive address (Al), and aaMAC_A or otaMAC_A1 as the transmit address. STA B performs Al filtering following the procedure described above by looking at the Rx active MAC address set, and de-anonymization by looking at the Rx and Tx active MAC address sets.

[0170] Figure 12 is an example method of using Figure 11 the features of the characteristic. At 1205, a wireless STA, such as a WTRU operating in a wireless network, obtains information establishing an association and authentication MAC (aaMAC) address associated with the STA. The aaMAC address corresponds to a MAC address used for association and authentication procedures between an AP and the STA, and is an address indexed in RSNA (Robust Security Network Association). The MAC address is used to set up RSNA, for routing traffic to the STA on the DS network segment, and it is also the address used for mobility related operations (such as fast transition mechanisms).

[0171] At 1210, the STA sends a MAC address set request frame to an access point (AP), the MAC address set request frame including two or more over-the-air MAC (otaMAC) addresses identifying a receive address of the STA. The otaMAC is used to maintain privacy of the aaMAC of the STA.

[0172] At 1215, the STA receives a MAC address set response frame acknowledging receipt of the otaMAC receive address of the STA. At this point, the STA can receive frames using the otaMAC address. At 1220, the AP can send a wireless communication message (information frame) to the STA, which the STA receives. At 1230, the STA processes the information frame received from the AP. The processing of the received frame is based on the frame from the AP having one of the two or more otaMAC addresses associated with the STA. Assuming the frame received from the AP uses one of the two or more otaMAC addresses, the STA accepts the frame as intended for the STA.

[0173] The STA processes the frame received from the AP by filtering the Al receive address of the STA to determine whether the address other than the aaMAC address of the STA is one of the two or more otaMAC addresses associated with the STA. In one aspect, the STA receives a frame from a second STA from the AP, the second STA communicating with the STA via the AP. In one embodiment, the STA, the second STA, and the AP have established respective different otaMAC addresses, and each performs Al address filtering on the received frame.

[0174] In another aspect, the STA can mask the frame sequence number of the MAC Address Set Request frame in order to further improve the privacy of the communication by obfuscating the frame sequence perceived by the tracking mechanism. In addition, the MAC Address Set Request frame and the MAC Address Response frame are protected dual frames of the public action frame.

[0175] Embodiment 3: Modification of Sequence Number In another innovative embodiment, modification of the sequence number (or any other field in the frame that is either publicly transmitted or constant and allows otaMAC to match aaMAC) can be performed. The innovation here can be standardized for use by STAs in wireless networks. As such, the innovation described below can be included in a wireless specification such as IEEE 802.11bi or other wireless specification.

[0176] To support enhanced privacy, in addition to the A1 and A2 anonymization, any parameter that is either transmitted in the clear or remains constant during the transmission should be anonymized. Parameters to consider for anonymization can include the sequence control, sequence number, QoS control, HT control, and CCMP header. In this embodiment, the sequence number is used, although this approach can be used for the remaining fields.

[0177] Generally, the sequence number (SN) is a 12-bit field that contains one of the 7 sets of sequence numbers defined in Table 10-5 of IEEE 802.11REVme / D2.0. According to the definition in IEEE 802.11aq, the sequence number is randomly selected at each MAC address change (pre-association MAC address modification).

[0178] To implement enhanced privacy, a specific sequence number can be calculated for each transmitting and receiving MAC address tuple (A1, A2) used in the previous embodiments. This SN can be modified at any time desired by the communicating STAs, such as periodically or according to a randomization pattern.

[0179] The mechanism is based on a salt value parameter that each STA in the communication can exchange, as described below. As defined in the previous embodiments, each STA stores a set of Tx and Rx active MAC addresses. In this embodiment, the content of the Tx / Rx active MAC address set can be extended to include a salt value parameter (Tx_Salt is stored in the Tx active MAC address set and Rx_Salt is stored in the Rx active MAC address set) that is exchanged and used by the STAs. The transmitting STA sends the Tx_Salt to the receiving STA through an active MAC address request frame. The receiving STA stores the received Tx_Salt in its Rx active MAC address set as Rx_Salt. Thus, for the two given STAs of the communication, the Tx_Salt can be used to anonymize the SN at transmission and used as Rx_Salt for de-anonymizing the SN at reception.

[0180] For the transmitting STA, the SN used in the frame can be computed as follows: first, a hash function of the otaMAC addresses in the frame and the Tx_Salt parameter stored in the Tx active MAC address set is generated: SN_Salt = Hash (otaMAC_A1, otaMAC_A2, Tx_Salt); second, the new SN to be added to the frame is computed by performing an XOR operation of the original SN and the SN_Salt: SN_new = SN XOR SN_Salt.

[0181] At reception, the STA first computes the SN_Salt by using the Rx_Salt in the Rx active MAC address set: SN_Salt = Hash (OTA MAC_A1, otaMAC_A2, Rx_Salt), and then is able to obtain the original SN by performing an XOR operation: SN_original = SN_new XOR SN_Salt.

[0182] The Tx_Salt and Rx_Salt used in the communication between the transmitting STA (STA1) and the receiving STA (STA2) can be different from the Tx_Salt and Rx_Salt used in the communication between the transmitting STA (STA2) and the receiving STA (STA1). In addition to the aforementioned mechanism, a simpler mechanism can also be applied in this case. One example includes using a random offset associated with each otaMAC and adding it to the sequence number. A random mask is associated with each otaMAC and XORed with the sequence number. Other potential functions can be used to mask the SN based on the otaMAC and elements exchange discussed here.

[0183] Aspects of the disclosure provide mechanisms, devices, and message formats that enable implementing Al filtering when a communicating STA changes its MAC address. Further and in order to improve privacy, aspects of the disclosure enable hiding the sequence number (SN) of a frame, e.g., obfuscating the SN based on the set of addresses used in the frame.

[0184] Aspects of the above embodiments relate to an association and authentication MAC (aaMAC) address, which corresponds to the MAC address used for the association and authentication procedure between an AP and a STA. In one aspect, the aaMAC address is the address indexed in the Robust Security Network Association (RSNA) procedure. This MAC address is used to set up the RSNA, to route traffic to the STA on the Distribution System (DS) network segment, and also for mobility related operations, such as the fast transition procedure.

[0185] Additional aspects of the above discussed embodiments relate to an over-the-air MAC (otaMAC) address used in frames transmitted over-the-air. For individually addressed frames involving the Distribution System (DS), where the To DS bit is set to 1 and the From DS bit is set to 0, the otaMAC is transmitted as address-2. For individually addressed frames, where the To DS bit is set to 0 and the From DS bit is set to 1, the otaMAC is transmitted as address-1. The advantage of using the otaMAC is that the aaMAC of the STA is kept private and can potentially be changed on a packet basis.

[0186] In summary, the above disclosure provides mechanisms and message formats to enable A1 filtering when communicating STAs change their MAC addresses. In addition and to improve privacy, the description also proposes a mechanism to hide the frame sequence number, obfuscating it based on the set of addresses used in the frame.

[0187] CONCLUSION Although the above provides features and elements in a particular combination, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in combination with others dependent upon the particular application. The disclosure is not limited to the specific embodiments described in this application, which are intended for purposes of illustration only. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the spirit and scope of the present application. Nothing in the description of the state of the art in this application should be interpreted as a disavowal of claimable Priorty. No element, act, or instruction used in the description of this application should be construed as an abandonment of such subject matter applied for by priority. Based on the foregoing description, a person skilled in the art can clearly understand that the methods and devices within the scope of the present disclosure can be implemented other than the methods and devices recited in the claims. Such modifications and variations are intended to fall within the scope of the appended claims. The disclosure is limited only as defined in the claims and the full range of equivalents to which such claims are entitled. It is understood that the disclosure is not limited to particular methods or systems.

[0188] For simplicity, the foregoing embodiments are discussed in terms of terminology and structure of devices having infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves, such as sound waves.

[0189] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can refer to any one of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its acronym "UE," the term "remote," and / or the term "head-mounted display" and its acronym "HMD" can mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a device having wireless capability and / or wired capability (e.g., tetherable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless capability and / or wired capability that is configured with less than all of the structure and functionality of a WTRU; or (iv) the like. Reference is made to Figures 1A-1D Details of an example WTRU that can be representative of any WTRU described herein are provided. As another example, the various embodiments disclosed above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than a head-mounted display can be utilized, and some or all of the present disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices can include a drone or other device configured to stream information to provide an adaptive reality experience.

[0190] Furthermore, the methods provided herein can be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (optical, electrical or the like) transmittable over a wire or wirelessly and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, removable floppy disks, RAM disks, solid state RAM, magnetic tape, hard disk drives, optical storage, and the like. The processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0191] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the application. In view of the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, the embodiments provided herein include hand-held devices, which can include or be used with any suitable voltage source, such as a battery or the like, that provides any suitable voltage.

[0192] Further, in the embodiments provided above, reference is made to processing platforms, computing systems, controllers, and other devices that include processors. These devices can include at least one central processing unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions can be performed by the various CPUs and memories. Such acts and operations or instructions can be referred to as being "executed," "computer executed" or "CPU executed."

[0193] Those skilled in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system representations, such as a bit, can cause a resulting transformation or reduction of the electrical signals or other processing of signals. The memory locations where data bits are maintained are an example of physical locations that can have particular electrical, magnetic, optical, or organic properties representing data bits.

[0194] Data bits can also be maintained on computer-readable media including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read Only Memory (ROM)) mass storage system readable by the CPU. The computer-readable medium can include cooperating or interconnected computer-readable media, which exist exclusively on the processing system, or are distributed among multiple interconnected processing systems that can be local or remote to the processing system. It is understood that the embodiments are not limited to the above-mentioned memory or CPU, and other platforms and memories can support the provided methods.

[0195] In the illustrative embodiments, any of the operations, processes, etc. described herein can be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0196] There is little distinction between the implementation of various aspects of the system in terms of hardware and software in that either can be used to implement the functionality associated with the various aspects. The choice of whether to implement various aspects using hardware or software depends on the design choices made by the implementer. For example, if the implementer determines that speed and accuracy are paramount, the implementer can opt for mainly hardware and / or firmware implementations. In another implementation, if flexibility is the most important, the implementer can opt for mainly software implementations. Alternatively, the implementer can choose to use a combination of hardware, software and / or firmware.

[0197] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize the embodiments disclosed herein, in whole or in part, can be equivalently implemented by other means, e.g., as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that the disclosed embodiments (again, in whole or in part) could run a wide range of operating systems / platforms. In view of this, the examples disclosed herein include a general purpose computing article of manufacture comprising a computer-readable storage medium, which can be read by a machine, tangibly embody the program of claims. The general purpose computing article of manufacture can include, but is not limited to, one or more of the following: a floppy disk, a flexible disk, a hard disk, a magnetic tape, a cassette tape, a punch tape, a paper tape, a compact disk, a CD-ROM, a digital tape, a computer memory, a RAM, a ROM, a PROM, an EPROM, a FLASH-EPROM, optical disks, a optical fiber, and a solid state drive. The general purpose computing article of manufacture can also include hardware for use with an example, such as: a suitable central processing unit, a suitable input device or devices, e.g., a keyboard, a mouse, and a joystick, and a suitable output device or devices, e.g., a monitor or a printer. The general purpose computing article of manufacture can also include a computer-readable storage medium for use with an example, such as: a floppy disk, a flexible disk, a hard disk, a magnetic tape, a cassette tape, a punch tape, a paper tape, a compact disk, a CD-ROM, a digital tape, a computer memory, a RAM, a ROM, a PROM, an EPROM, a FLASH-EPROM, optical disks, a optical fiber, and a solid state drive. The general purpose computing article of manufacture can also include a computer-readable storage medium encoded with a set of instructions for performing a method, as described above, and including a computer-readable storage medium that is in communication (e.g., via hardwired or wireless communication) with such software that causes a machine to

[0198] Those skilled in the art will recognize that the description of apparatus and / or process set forth herein is exemplary and explanatory only and is not intended to be limiting, as one of ordinary skill in the art will readily appreciate that the described apparatus and / or processes can be implemented in other ways to accomplish the same results. Those skilled in the art will further appreciate that the described apparatus and / or processes can be implemented or combined in any combination of hardware and / or software to achieve the same results. One of ordinary skill in the art will further appreciate that the described apparatus and / or processes can be implemented or combined with a data processing system to achieve the same results. Those skilled in the art will appreciate that the described apparatus and / or processes can be implemented or combined with a data processing system to achieve the same results.

[0199] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable", to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0200] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate the plural terms to the singular and / or singular to the plural as is appropriate to the disclosure. For the sake of clarity, the singular and / or plural terms are sometimes specifically mentioned in this disclosure. It is intended that the disclosure encompass both the singular and the plural forms of the terms.

[0201] Those skilled in the art will appreciate that, in general, terminology used herein, and especially in the appended claims (e.g., in the body of the appended claims), is intended to be interpreted in an "open" and "inclusive" manner (e.g., the term "comprising" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including, but not limited to," and the like). Those skilled in the art will further appreciate that if it is intended that a particular number of a claim recitation be included, such intent is expressly recited in the claim, and if not, no such intent is present. For example, where only one item is intended, the term "single" or similar language can be used. To aid in understanding, the claims and / or description herein below can include the use of introductory phrases such as "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed in a way that would limit any specific claim recitation to including only a single such recitation. For example, when a claim recitation uses phrases such as "at least one of," "one or more of," or "one or more aspects," those phrases are understood to mean that a feature flagged by that phrase can be included alone or in multiple conjunction with another feature (e.g., "comprising at least one of A and B" would mean that A or B can be included, solely A can be included, solely B can be included, or both A and B can be included). This is simply stated as a means to explain the phrases, and it is to be appreciated that a single "feature" can be claimed even when the phrases are used and that feature can be claimed even when the phrase is used in conjunction with other claims except where it is explicitly expressed that it is to be different.Also, as used herein, the term "any of' followed by a listing of a plurality of items and / or categories of items, is intended to mean "any of the individual items and / or categories of items", "any of the combinations of the individual items and / or categories of items", "any of the multiple individual items and / or categories of items", and / or "any of the multiple combinations of the individual items and / or categories of items". Additionally, as used herein, the term "set" is intended to mean any number of items, including zero. Furthermore, as used herein, the term "number" is intended to mean any number, including zero. And as used herein, the term "plurality" is intended to mean "multiple".

[0202] Further, where a feature or aspect of the disclosure is described in terms of Markush groups, a person of ordinary skill in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0203] As those skilled in the art will appreciate, all ranges disclosed herein are also intended to encompass any and all possible sub-ranges and combinations of sub-ranges thereof, for any and all purposes. Any listed range can be easily reduced to, and / or combined to form, a smaller range. As a non-limiting example, a range of "1 to 10" can be easily reduced to, and / or combined, to form a range of "2 to 5." Any listed range can be easily reduced to, and / or combined, to form a smaller range that is next-to-smallest, next-to-larger, "exact", or possibly useful in other ways. All ranges disclosed and taught herein can be easily "reversed," "mirrored," or "flipped," to ensure the understanding that the broader range is intended. It will also be clear that all individual values of any of the ranges disclosed and taught herein can be explicitly enumerated, even though only a few are listed. Any reference to any element in a claim that was not present in the initial disclosure is expressly identified as being taken from another claim. Also, as used herein, "means" or "step-plus-function" clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents but also equivalent structures. Furthermore, to the extent that any clause recites "means" or "step-plus-function", it is intended that alternative disclosure be made of any structure also falling under 35 U.S.C. § 112, paragraph 6.

[0204] Also, the claims are not to be limited to the specific order or elements described if that is possible under the prior art except where a particular order is inherently required (e.g., a process). Additionally, the claims are not to be limited to the specific embodiments, examples, or methods described, unless that is specifically indicated. or means-plus-function claim format, and that no claim in this specification is intended to be interpreted under 35 U.S.C. § 112, paragraph 6.

Claims

1. A method for using an over-the-air MAC (otaMAC) address performed by a wireless station (STA), the method comprising: Obtain the association and authentication media access control (aaMAC) address associated with the STA; Sending a MAC address set request frame to an access point (AP), the MAC address set request frame including two or more otaMAC addresses identifying receiving addresses of the STA; Receive a MAC address set response frame, wherein the MAC address set response frame confirms receipt of the STA's otaMAC receiving address; Receive frames from AP; The frame from the AP is processed based on the frame from the AP having one of two or more otaMAC addresses associated with the STA.

2. The method of claim 1 , wherein before processing the frame from the AP, filtering the A1 received address of the STA to determine whether an address other than the aaMAC address of the STA is one of two or more otaMAC addresses associated with the STA. 3 . The method of claim 1 , wherein receiving the frame from the AP comprises receiving a frame having an address different from an aaMAC address of the STA from the AP. 4 . The method of claim 3 , wherein receiving the frame having an address different from the aaMAC address of the STA from the AP comprises receiving the frame from a second STA communicating via the AP.

5. The method of claim 4, wherein the STA, the second STA, and the AP have established different respective otaMAC addresses, and each performs A1 address filtering on received frames.

6. The method according to claim 1, further comprising: Masks the frame sequence number of the MAC address set request frame.

7. The method of claim 1, wherein the MAC address set request and MAC address response frames are protected dual frames of a public action frame.

8. The method of claim 1, obtaining an association and authentication media access control (aaMAC) address associated with the STA comprises obtaining the aaMAC address from any one of an aaMAC provision via an AP or a provision via STA configuration.

9. A wireless station (STA) comprising circuitry, the circuitry comprising a transmitter, a receiver, a processor, and a memory, the STA being configured to: Obtain the association and authentication media access control (aaMAC) address associated with the STA; Sending a MAC address set request frame to an access point (AP), the MAC address set request frame including two or more over-the-air MAC (otaMAC) addresses identifying receiving addresses of the STA; Receive a MAC address set response frame, wherein the MAC address set response frame confirms receipt of the STA's otaMAC receiving address; Receive frames from AP; The frame from the AP is processed based on the frame from the AP having one of two or more otaMAC addresses associated with the STA.

10. The wireless STA of claim 9, wherein the STA processes a frame from the AP by filtering the STA's A1 received address to determine whether an address other than the STA's aaMAC address is one of two or more otaMAC addresses associated with the STA.

11. The wireless STA of claim 9, wherein the STA receives a frame having an address different from an aaMAC address of the STA from the AP. 12 . The wireless STA of claim 11 , wherein the STA receives the frame from the AP from a second STA communicating via the AP.

13. The wireless STA according to claim 12, wherein the STA, the second STA, and the AP have established different respective otaMAC addresses, and each performs A1 address filtering on received frames.

14. The wireless STA according to claim 9, wherein the wireless STA is further configured to: Masks the frame sequence number of the MAC address set request frame.

15. The wireless STA of claim 9, wherein the MAC address set request frame and the MAC address response frame are protected double frames of a public action frame.

16. The wireless STA of claim 9, wherein the wireless STA is a wireless transmit / receive unit (WTRU). 17 . The wireless STA of claim 9 , wherein the STA obtains the aaMAC address from any one of aaMAC provision via an AP or provision via STA configuration.

18. A non-transitory computer-readable storage medium embodying instructions that, when executed by a computer, cause the computer to perform a method of using an over-the-air MAC (otaMAC) address, the method comprising any one of claims 1-8.

Images