DE102021134385A1 - PRIVACY ADDRESS OF A WI-FI DEVICE FOR FAST BASIC SERVICE SET (BSS) TRANSITION (FT) - Google Patents

Abstract

This disclosure relates to systems, methods, and devices related to the privacy address. An AP device configured to: communicate with a non-AP device based on a MAC address of the non-AP device; receive from the non-AP device a private identifier of the non-AP device that is encrypted and provided in a second message of an FT 4-way handshake; communicate with the non-AP device based on the private identifier, preferably wherein the private identifier is a private MAC address different from the MAC address of the non-AP device used for over-the-air - transmissions is used, and/or wherein preferably the AP device uses the private identifier as a source address (SA) to transmit data from the non-AP device to a distribution system (DS), and/or wherein preferably the AP Device using the private identifier to match a destination address (DA) of data transmitted from the DS and to transmit the data to the non-AP device.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to US provisional patent application Ser. No. U.S. 63/162,758 , filed March 18, 2021 (AD5276).

TECHNICAL AREA

This disclosure relates generally to systems and methods for wireless communications, and more particularly to a Wi-Fi device's privacy address for fast Basic Service Set (BSS) transition.

BACKGROUND

Wireless devices are proliferating and increasingly demanding access to wireless channels. The Institute of Electrical and Electronics Engineers (IEEE) is developing one or more standards that use Orthogonal Frequency-Division Multiple Access (OFDMA) in channel allocation.

character list

• 1 ist ein Netzwerkdiagramm, das eine beispielhafte Netzwerkumgebung für Privatsphären-Adressen gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung zeigt.
• 2 zeigt ein Flussdiagramm eines illustrativen Prozesses für ein illustratives Privatsphären-Adressen-System, gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung.
• 3 zeigt ein Funktionsdiagramm einer beispielhaften Kommunikationsstation, die zur Verwendung als eine Benutzervorrichtung geeignet sein kann, gemäß einer oder mehreren beispielhaften Ausgestaltungen der vorliegenden Offenbarung.
• 4 zeigt ein Blockdiagramm einer Beispielmaschine, auf der eine oder mehrere Techniken (z.B. Verfahren) gemäß einer oder mehreren Ausführungsbeispielen der vorliegenden Offenbarung durchgeführt werden können.
• 5 ist ein Blockdiagramm einer Funkarchitektur gemäß einigen Beispielen.
• 6 illustriert eine beispielhafte Front-End-Modul-Schaltung zur Verwendung in der Funkarchitektur von 5 gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung.
• 7 illustriert eine beispielhafte Funk-IC-Schaltung zur Verwendung in der Funkarchitektur von 5, gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung.
• 8 illustriert eine beispielhafte Verarbeitungsschaltung für das Basisband zur Verwendung in der Funkarchitektur von 5, gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung.
• 9A und 9B sind Netzwerkdiagramme, die detaillierte Beispiele einer Netzwerkumgebung für die Privatsphären-Adresse in einem Multi-Link-Rahmen für die Drahtlos-Kommunikation gemäß einer oder mehreren Ausführungsbeispielen der vorliegenden Offenbarung darstellen.
• 10 ist ein Nachrichtenflussdiagramm, das eine beispielhafte FT-Anfangs-Mobilitätsdomänen-Zuordnung in einem RSN einschließlich eines Vier-Wege-Handshakes zum Austausch verschlüsselter Informationen gemäß einigen beispielhaften Ausführungsformen der vorliegenden Offenbarung zeigt.
• 11 ist ein Blockdiagramm, das ein Beispielformat eines EAPOL-Schlüsselrahmens für einen FT-Vierwege-Handshake gemäß einigen Beispielausführungen der vorliegenden Offenbarung darstellt.
• 12 ist ein Blockdiagramm, das ein Beispielformat eines Schlüsselinformationsfeldes des EAPOL-Schlüsselrahmens für einen FT-Vier-Wege-Handshake gemäß einigen Beispielausführungen der vorliegenden Offenbarung veranschaulicht.
• 13 ist ein Blockdiagramm, das ein Beispielformat eines Schlüsseldaten-Einpack-(Key Data Encapsulation - KDE)-Selektors für einen FT-Vierwege-Handshake gemäß einigen Beispielen der vorliegenden Offenbarung veranschaulicht.
• 14 ist ein Blockdiagramm, das eine Beispieltabelle eines Schlüssel-Einpack-Algorithmus für einen FT-Vier-Wege-Handshake gemäß einigen Beispielausführungen der vorliegenden Offenbarung darstellt.
• 15A-15C sind Blockdiagramme, die Beispielformate eines Schneller-Übergangs-Elements (FTE) für einen FT-Vier-Wege-Handshake gemäß einigen Beispielausführungen der vorliegenden Offenbarung veranschaulichen.
• 16A-16B sind Blockdiagramme, die Beispiele für KDE-Formate eines Schneller-Übergangs-Elements (FTE) für einen FT-Vier-Wege-Handshake gemäß einigen beispielhaften Ausführungsformen der vorliegenden Offenbarung darstellen.
• 17A-17B sind Blockdiagramme, die Beispiele von Elementen zur Übertragung der privaten MAC-Adresse oder des privaten Identifikators eines Schneller-Übergangs-Elements (FTE) für einen FT-Vier-Wege-Handshake gemäß einigen Beispielen der vorliegenden Offenbarung veranschaulichen.

Various aspects of the present disclosure are explained below based on various embodiments with reference to the following drawings. The figures are not necessarily drawn to scale. In the figures, identical or similar components are provided with the same reference symbols.

• 1 1 is a network diagram depicting an example network environment for privacy addresses, in accordance with one or more example embodiments of the present disclosure.
• 2 10 shows a flow diagram of an illustrative process for an illustrative privacy address system, in accordance with one or more exemplary embodiments of the present disclosure.
• 3 12 shows a functional diagram of an example communication station that may be suitable for use as a user device, in accordance with one or more example embodiments of the present disclosure.
• 4 10 illustrates a block diagram of an example machine on which one or more techniques (eg, methods) may be performed according to one or more embodiments of the present disclosure.
• 5 12 is a block diagram of a radio architecture, according to some examples.
• 6 illustrates an example front-end module circuit for use in the radio architecture of FIG 5 according to one or more exemplary embodiments of the present disclosure.
• 7 illustrates an example radio IC circuit for use in the radio architecture of FIG 5 , according to one or more exemplary embodiments of the present disclosure.
• 8th 12 illustrates exemplary baseband processing circuitry for use in the radio architecture of FIG 5 , according to one or more exemplary embodiments of the present disclosure.
• 9A and 9B 12 are network diagrams illustrating detailed examples of a network environment for the privacy address in a multi-link wireless communication frame, according to one or more embodiments of the present disclosure.
• 10 13 is a message flow diagram showing an example FT-initial mobility domain mapping in an RSN including a four-way handshake for exchanging encrypted information, according to some example embodiments of the present disclosure.
• 11 13 is a block diagram illustrating an example format of an EAPOL key frame for an FT four-way handshake, according to some example implementations of the present disclosure.
• 12 12 is a block diagram illustrating an example format of a key information field of the EAPOL key frame for an FT four-way handshake, according to some example implementations of the present disclosure.
• 13 12 is a block diagram illustrating an example format of a key data encapsulation (KDE) selector for an FT four-way handshake, according to some examples of the present disclosure.
• 14 12 is a block diagram illustrating an example table of a key wrapping algorithm for an FT four-way handshake, according to some example implementations of the present disclosure.
• 15A-15C 12 are block diagrams illustrating example formats of a fast transition element (FTE) for an FT four-way handshake, according to some example implementations of the present disclosure.
• 16A-16B 10 are block diagrams illustrating example KDE formats of a Fast Transition Element (FTE) for an FT four-way handshake, according to some example embodiments of the present disclosure.
• 17A-17B 12 are block diagrams illustrating examples of elements for transmitting the private MAC address or identifier of a fast transition element (FTE) for an FT four-way handshake, according to some examples of the present disclosure.

DETAILED DESCRIPTION

The following description and drawings illustrate embodiments sufficiently specific to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, procedural, algorithmic, and other changes. Portions and features of some embodiments may be included in or substituted for other embodiments. The embodiments set forth in the claims include all available equivalents of those claims.

The IEEE 802.11 standard describes communication protocols that facilitate wireless communication between wireless communication stations. It specifies a set of medium access control (MAC) and physical layer (PHY) protocols for implementing WLAN communications (e.g. Wi-Fi) in various frequency ranges, including but not limited to the 2.4 GHz, 5 GHz frequency bands , 6GHz and 60GHz.

The proliferation of wireless devices such as phones, tablets and laptops has made access to information much easier and has made us almost inextricably linked to these wireless devices. Among these wireless devices, Wi-Fi is the common access mechanism that offers a low-cost, convenient-range network. However, it has been pointed out that the MAC address of the Wi-Fi device can be used for tracking the device, and since wireless devices are intrinsically linked to the person using the device, the MAC address of the Wi -Fi device can then be used to track a specific individual, violating the right to privacy.

To solve the privacy problem, a common practice is to randomize the MAC address used by the Wi-Fi device. In particular, a Wi-Fi device may randomize the MAC address during active scanning, e.g., when sending a probe request. Alternatively or additionally, a Wi-Fi device can randomize the MAC address while connecting to an AP, i.e. it can use a different MAC address if it connects to an AP at a different time.

The current IEEE 802.11 specification has no mechanism that allows a Wi-Fi device to randomize MAC addressing while connected to an AP, i.e. after authentication and association with the AP.

Currently, Fast Basic Service Set (BSS) transition is the most common mechanism used for roaming within a WLAN, and it is not clear how a private identifier or private MAC address mechanism under FT will work. It is also not clear how a private identifier or private MAC address would facilitate roaming with MLDs on a WLAN.

Exemplary embodiments of the present disclosure relate to systems, methods, and apparatus for providing home addresses to Wi-Fi devices for fast Basic Service Set (BSS) transition (FT).

Upon initial FT Mobility Domain Association in a Robust Security Network (RSN), a Wi-Fi device may have a private identifier or private MAC address that is provided to the attached AP or AP MLD in a secure manner.

In one or more embodiments, a private address scheme may allow the private identifier or private MAC address to be provided in message 2 of the FT 4-way handshake and encrypted with the EAPOL key (EAPOL = extensive authentication protocol over location area network ) is encrypted.

After the private identifier or private MAC address is provided, the AP or AP MLD changes the identifier/address to that of the established state machine for authentication, association, and 4-way hand shake corresponds, from non-AP STA or non-AP MLD MAC address to private identifier or private MAC address.

A Wi-Fi device can have different private identifiers or private MAC addresses for different SSIDs to avoid the problem of figuring out whether a particular network identified by a particular SSID can be trusted.

In FT re-association in an RSN, a Wi-Fi device may specify the private identifier or private MAC address in the re-association request frame.

The private identifier or private MAC address is encrypted using KEK or KEK2 and an appropriate key transcoding algorithm.

The Wi-Fi device from a higher layer perspective is now identified by the private identifier or private MAC address, which is not revealed on the air interface. Private Identifier or Private MAC Address can now be set for a specific SSID without breaking MAC-based Parental Control, MAC-based Access Network and DHCP functions. That is, the same private identifier or MAC address can be specified each time a network with a particular SSID is encountered. FT operation now also works when roaming to an AP or AP-MLD that supports private identifier or private MAC address operation.

The above descriptions are provided for purposes of illustration and are not intended to be limiting. There are numerous other examples, configurations, processes, algorithms, etc., some of which are described in more detail below. Exemplary embodiments will now be described with reference to the attached figures.

1 12 is a network diagram illustrating an example network environment of the privacy address, in accordance with some example embodiments of the present disclosure. Wireless network 100 may include one or more devices 120 and one or more access points (AP) 102 capable of communicating according to IEEE 802.11 communication standards. User device(s) 120 may be mobile devices that are non-stationary (eg, do not have fixed locations) or may be stationary devices.

In some embodiments, user devices 120 and AP 102 may include one or more computing systems that conform to the functional diagram of FIG 3 and/or the example machine/system of 4 resemble

One or more illustrative user device(s) 120 and/or AP(s) 102 may be operable by one or more user(s) 110. Note that any addressable entity can be a Station (STA). A STA can have several different characteristics, each of which determines its function. For example, a single addressable entity can simultaneously be a portable STA, a Quality of Service (QoS) station, a slave STA, and a hidden STA. The illustrated device(s) 120 and AP(s) 102 may be STAs. The illustrated device(s) 120 and/or AP(s) 102 may operate as a Basic Personal Service Set (PBSS) Control Point/Access Point (PCP/AP). User device(s) 120 (eg, 124, 126, or 128) and/or AP(s) 102 may comprise any suitable processor controlled device, including but not limited to a mobile device or a non-mobile, eg, static device . User Equipment(s) 120 and/or AP(s) 102 may include, for example, a User Equipment (UE), Station (STA), Access Point (AP), Software Enabled AP (SoftAP), Personal Computer (PC), a wireless wearable device (e.g., bracelet, watch, glasses, ring, etc.), a desktop computer, a mobile computer, a laptop computer, an UltrabookTM computer, a notebook computer, a tablet Computer, server computer, handheld computer, handheld device, Internet of Things (IoT) device, sensor device, PDA device, PDA handheld device, on-board device, an off-board device, a hybrid device (e.g., combining the functionalities of a cellular phone with those of a PDA device), a consumer device, a vehicle device, a non-vehicle device, a mobile or portable device, a non- mobile or non-portable device, a cellular phone, a cellular phone, a PCS device, a PDA device, the ei a wireless communication device, a mobile or handheld GPS device, a DVB device, a relatively small computing device, a non-desktop computer, a Carry Small Live Large (CSLL) device, an ultra mobile device (UMD), an ultra-mobile PC (UMPC), a mobile Internet device (MID), an "origami" device or computing device, a device supporting dynamically composable computing (DCC), a context-sensitive device, a video device, an audio device, an A/V device, a set-top box (STB), a Blu-ray Disc (BD) player, a BD recorder, a digital video disc (DVD) player, a high -Definition (HD) DVD player, a DVD recorder, an HD DVD recorder, a Personal Video Recorder (PVR), an HD broadcast receiver, a video source, an audio source, a video sink, an audio sink , stereo tuner, broadcast receiver, flat panel display, personal media player (PMP), digital video camera (DVC), digital audio player, speaker, audio receiver, audio amplifier, gaming device, data source, data sink, digital still camera (DSC), a media player, a smartphone, a TV, a music player or similar. Other devices including smart devices such as lights, air conditioners, car components, household components, appliances, etc. can also be included in this list.

As used herein, the term "Internet of Things (IoT) device" refers to any object (e.g., a device, sensor, etc.) that has an addressable interface (e.g., an Internet Protocol (IP) address, a Bluetooth identifier (ID), a near field communication (NFC) ID, etc.) and information over a wired or wireless connection to one or more other devices. An IoT device may have a passive communication interface, such as a quick response (QR) code, radio frequency identification (RFID) tag, NFC tag, or the like, or an active communication interface, such as a modem , a transceiver, a transceiver or the like. An IoT device may exhibit a specific set of attributes (e.g., a device state or status, e.g., whether the IoT device is on or off, open or closed, idle or active, available to perform tasks or busy, etc ., a cooling or heating function, an environmental monitoring or recording function, a light emitting function, an acoustic emitting function, etc.) that can be embedded in and/or controlled/monitored by a central processing unit (CPU), microprocessor, ASIC or similar and set up to connect to an IoT network such as a local ad hoc network or the Internet. Examples of IoT devices may include refrigerators, toasters, ovens, microwaves, freezers, dishwashers, dishes, hand tools, washing machines, tumble dryers, ovens, air conditioners, thermostats, televisions, lighting fixtures, vacuum cleaners, sprinklers, electric meters, gas meters, etc., provided the Devices are equipped with an addressable communication interface for communication with the IoT network. IoT devices can also include cell phones, desktop computers, laptops, tablet computers, personal digital assistants (PDAs), and so on. Accordingly, the IoT network may include a combination of "legacy" internet-enabled devices (e.g., laptop or desktop computers, cell phones, etc.) in addition to devices that typically do not have internet connectivity (e.g., dishwashers, etc.).

User device(s) 120 and/or AP 102 may also comprise mesh stations, e.g., in a mesh network according to one or more IEEE 802.11 standards and/or 3GPP standards.

Each of user device(s) 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may be configured to communicate with one another via one or more communication networks 130 and/or 135, wirelessly or wired. User device(s) 120 may also communicate peer-to-peer or directly with or without AP(s) 102. Each of communication networks 130 and/or 135 may include any combination of different types of suitable communication networks, such as, but not limited to, broadcast networks, cable networks, public networks (e.g., the Internet), private networks, wireless networks, cellular networks, or other suitable private and/or public networks. Additionally, each of the communication networks 130 and/or 135 may have any suitable communication domain associated therewith, and may include, for example, global networks (e.g., the Internet), metropolitan area networks (MANs), wide area networks (WANs), local area networks ( LANs) or Personal Area Networks (PANs). In addition, each of the communication networks 130 and/or 135 may include any type of medium over which network traffic may be transmitted, including but not limited to coaxial cable, twisted pair wiring, optical fiber, a hybrid fiber coaxial medium (HFC), terrestrial microwave transceivers, Radio Frequency Communications Media, White Space Communications Media, Ultra High Frequency Communications Media, Satellite Communications Media, or any combination thereof.

Each of user device(s) 120 (eg, user devices 124, 126, 128) and AP(s) 102 may include one or more communication antennas. The one or more communication antennas can be any suitable type of antenna that supports the signals provided by user device(s) 120 (e.g., user devices 124, 126, and 128) and conform to the communication protocols used by the AP(s) 102. Some non-limiting examples of suitable communication antennas include Wi-Fi antennas, IEEE 802.11 family of standards-compliant antennas, directional antennas, omnidirectional antennas, dipole antennas, folded dipole antennas, patch antennas, multiple-input multiple-output (MIMO) antennas, omnidirectional antennas, quasi -Omnidirectional antennas or the like. The one or more communication antennas may be communicatively coupled to a radio component to transmit and/or receive signals, such as communication signals, to and/or from user devices 120 and/or AP(s) 102.

Each of user device(s) 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may be configured to perform directional transmission and/or reception in connection with wireless communication in a wireless network. Each of user device(s) 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may be configured to provide such directional transmission and/or reception using a set of multiple antenna arrays (e.g., DMG antenna arrays or the like) to perform. Each of the multiple antenna arrays can be used for transmission and/or reception in a particular direction or range of directions. Each of user device(s) 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may be configured to perform any directional transmission toward one or more defined transmit sectors. Each of user device(s) 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may be configured to perform any directional reception from one or more defined reception sectors.

MIMO beamforming in a wireless network can be performed with RF beamforming and/or digital beamforming. In some embodiments, user devices 120 and/or AP(s) 102, when performing a particular MIMO transmission, may be configured to use all or a subset of their one or more communication antennas to perform MIMO beamforming.

Each of user devices 120 (e.g., user devices 124, 126, 128) and AP(s) 102 may include any suitable radio device and/or transceiver for transmitting and/or receiving radio frequency signals in the bandwidth and/or channels consistent with the communication protocols that are used by each of user devices 120 and AP(s) 102 to communicate with each other. The radio components can contain hardware and/or software for modulating and/or demodulating communication signals according to predetermined transmission protocols. The radios may also have hardware and/or software instructions to communicate over one or more Wi-Fi and/or Wi-Fi Direct protocols as defined by the IEEE 802.11 (Institute of Electrical and Electronics Engineers ) are standardized. In certain exemplary embodiments, the radio component can work in cooperation with the communication antennas to communicate over 2.4 GHz channels (e.g. 802.11b, 802.11g, 802.11n, 802.11ax), 5 GHz channels (e.g. 802.11n, 802.11ac, 802.11 ax), 60 GHz channels (e.g. 802.11ad, 802.11ay) or 800 MHz channels (e.g. 802.11ah). The communication antennas can operate at 28 GHz and 40 GHz. It is understood that this list of communication channels according to certain 802.11 standards is only a partial list and that other 802.11 standards can also be used (e.g. next generation Wi-Fi or other standards). In some embodiments, non-Wi-Fi protocols can also be used for communication between devices, e.g., Bluetooth, Dedicated Short-Range Communication (DSRC), Ultra-High Frequency (UHF) (e.g., IEEE 802.11af, IEEE 802.22), White -Band frequencies (e.g. white spaces) or other packetized radio communications. The radio component can contain all known receivers and basebands that are suitable for communication via the communication protocols. The radio component may further include a low-noise amplifier (LNA), additional signal amplifiers, an analog-to-digital (A/D) converter, one or more buffers, and a digital baseband.

In one embodiment and with reference to FIG 1 AP 102 may facilitate privacy address 142 with one or more user devices 120 .

It is understood that the above descriptions are provided for purposes of illustration and are not to be construed as limiting.

In the never-ending quest for high throughput, IEEE 802.11 creates a framework that allows multiple links to connect while connected to a network, as in 9A and 9B shown.

9A and 9B are network diagrams showing detailed examples of a network environment for the privacy address in a multi-link wireless communication framework according to one or more embodiments of the present disclosure.

According to the present multi-link device framework, there are two logical multi-link entities (e.g., multi-link devices) on each side (e.g., uplink/downlink or transceiver) of a communication link, each of which comprises multiple stations (STAs ) that can establish one or more physical connections with each other to form the communication link. The detailed definition is shown below.

A multi-link device (MLD) is a logical entity that contains one or more STAs. The logical unit has a data services interface for medium access control (MAC) and logical link control (LLC) layer primitives, and a single address associated with the interface, which is used for communication over the Distributed system medium (DSM) can be used. The Distributed System (DS) is a system designed to connect a series of Basic Service Set (BSS) together to form an Enhanced Service Set (ESS).

For example, a first multi-link logical unit 910 (see 9A ) a first STA 915a (eg, STA1.1), a second STA 915b (eg, STA1.2), and a third STA 915c (eg, STA1.3), and a second multi-link logical unit 920 comprises a first STA 925a ( eg STA2.1), a second STA 925b (eg STA2.2) and a third STA 925c (eg STA2.3). Each STA 915 of the first multi-link logical unit 910 and each corresponding STA 925 of the second multi-link logical unit 920 may form a respective connection 930a, 930b, 930c with each other. That is, one or more connections can be formed between the first logical multi-link unit and the second logical multi-link unit. For example, the first STA 915a of the first multi-link logical unit 910 and the first STA 925a of the second multi-link logical unit 920 may form a connection 930a with each other. The second STA 915b of the first multi-link logical unit 910 and the second STA 925a of the second multi-link logical unit 920 may form a second connection 930b with each other. The third STA 915a of the first multi-link logical unit 910 and the third STA 925a of the second multi-link logical unit 920 may form a third connection 930c with each other.

A multi-link device allows STAs within the multi-link logical unit to have the same MAC address. The name of the multi-link device can be changed.

For an infrastructure framework, there is a multi-link Access Point (AP) device that includes APs on one side and a multi-link non-AP device that includes non-APs on the other side. Detailed definitions are provided:

An AP-MLD is a multi-link device where each STA within the multi-link device is an EHT-AP.

A non-AP MLD is a multi-link device where each STA within the multi-link device is a non-AP EHT STA.

For example, a multi-link AP logical entity 940 (eg, AP-MLD) includes according to FIG 9B a first EHT AP-STA 945a (e.g. AP1 operating on 2.4 GHz), a second EHT AP-STA 945b (e.g. AP2 operating on 5 GHz) and a third EHT AP-STA 945c (e.g , AP3 operating at 6 GHz) and a multi-link non-AP logical entity 950 (eg non-AP MLD) comprises a first non-AP STA 955a (eg non-AP STA1), a second non -AP-STA 955b (e.g. non-AP-STA2) and a third non-AP-STA 955c (e.g. non-AP-STA3). Each AP-STA 945 of the multi-link AP logical entity 940 and each corresponding non-AP-STA 955 of the multi-link non-AP logical entity 950 may form a respective connection 960 with each other. That is, one or more connections may be formed between an AP MLD and a non-AP MLD. For example, the first AP-STA 945a of the multi-link AP logical entity 940 and the first non-AP-STA 955a of the multi-link non-AP logical entity 950 may form a connection 960a with each other. For example, the second AP-STA 945b of the multi-link AP logical entity 940 and the second non-AP-STA 955b of the multi-link non-AP logical entity 950 may form a second connection 960b with each other. For example, the third AP-STA 945c of the multi-link AP logical entity 940 and the third non-AP-STA 955c of the multi-link non-AP logical entity 950 may form a third connection 960c with each other.

This framework is a natural extension of the one-link operation between two STAs that are an AP and a non-AP STA in the framework of the infrastructure.

Each MLD has an MLD MAC address. Each STA of an MLD also has a STA MAC address.

Different STAs of an MLD have different MAC addresses. The MAC address of the MLD can be the same as or different from one of the MAC addresses of the STAs of the MLD.

A MAC address of an MLD is introduced to ensure that the traditional mapping of AP and STA from the higher layer perspective under multi-link is preserved, and the mapping is made independent of the MAC by AP-MLD and non-AP-MLD addresses used by the MLD's STAs.

In one or more embodiments, a Wi-Fi device may provide a private MAC address in a secure manner after computing a pairwise transit key (PTK). The private MAC address is provided in message 2 of an FT 4-way handshake.

After the private MAC address is provided, the AP or AP MLD changes the address corresponding to the established state machine for authentication, association, and FT-4-way handshake from the non-AP STA or non-AP -MLD MAC address to the private MAC address.

As a result, the private MAC address of the Wi-Fi device is used as the source address (SA) when the data delivered by the non-AP STA or non-AP MLD is delivered via the DS, and the destination address field ( DA) is checked when the data is transmitted from the DS to determine if the datum is for the non-AP STA or non-AP MLD.

In one or more embodiments, a privacy addressing system may describe the connection between a non-AP STA and an AP, and then the connection between a non-AP MLD and an AP MLD.

The connection between a non-AP STA and an AP using FT can be:

A non-AP-STA has a private MAC address that is different from the MAC address of the non-AP-STA.

A non-AP STA should use the same private MAC address within a network identified by the same SSID. That is, the non-AP STA should provide the same private MAC address to every AP that has the same SSID (i.e. the AP is part of the network).

The MAC address of the non-AP-STA is used for over-the-air transmission including authentication frame exchange, association frame exchange and FT 4-way handshake.

The MAC address of the non-AP-STA is used for the calculation of the pairwise master key (PMK) in the Simultaneous Authentication of Equals (SAE) secure key generation procedure.

The MAC address of the non-AP STA is used for S0KH-ID, S1 KH-ID and SPA.

The MAC address of the non-AP STA is used for the PTK calculation.

The private MAC address is provided in message 2 of the FT 4-way handshake. For example, Key Data Encapsulation (KDE) can be used to encapsulate the private MAC address. An existing KDE with data type 3 can be used to record the private MAC address. A new KDE containing the private MAC address can also be used. The KDE containing the private MAC address is included in the key data field of message 2. The key data field of message 2 is encrypted using KEK and an appropriate key-wrap algorithm. Also, the Encrypted Key Data field is set to 1.

Alternatively, instead of a KDE, an additional element containing the private MAC address to be included in the key data field of message 2 can also be used.

10 10 is a message flow diagram depicting an example FT initial mobility domain mapping 1000 in an RSN including a 4-way handshake 1010 for exchanging encrypted information, according to some example embodiments of the present disclosure.

The flow of the FT 4-way handshake 1010 is in 10 shown. In particular, the FT-4 message handshake exchange follows 802.1X Extensible Authentication Protocol (EAP) authentication 1009. At 1011, a first EAPOL key frame (ie, message 1) may be transmitted from an AP to a STA. At 1013, a second EAPOL key frame (ie, message 2) may be transmitted from the STA to the AP. At 1015, a third EAPOL key frame (ie, message 3) may be transmitted from the AP to the STA. At 1017, a fourth EAPOL key frame (ie, message 4) may be transmitted from the STA to the AP.

11 11 is a block diagram depicting an example format of an EAPOL key frame 1100 for an FT 4-way handshake, according to some example implementations of the present disclosure indicates. The format of an EAPOL key frame 1100 includes a descriptor type field 1101, a key information field 1103, a key length field 1105, a key repeat count field 1107, a key nonce field 1109, an EAPOL key IV field 1111, a key -RSC field 1113, a key MIC field 1117, a key data length field 1119, and a key data field 1121.

12 11 is a block diagram illustrating an example format of a key information field 1103 of the EAPOL key frame 1100 for an FT 4-way handshake, according to some example implementations of the present disclosure.

The format of the key information field 1103 contains various bits, including an encrypted key data bit 1219.

13 12 is a block diagram illustrating an example format of a key data wrapping selector (KDE) for an FT 4-way handshake, according to some example implementations of the present disclosure.

The key data encapsulation (KDE) selector format includes a different selectable data type for a different selectable KDE.

14 12 is a block diagram showing an example table of a key wrapping algorithm for an FT 4-way handshake, according to some example implementations of the present disclosure.

The key wrapping algorithm table contains various selectable key wrapping algorithms.

The private MAC address can also be provided in a Re-Association Request frame under FT Re-Association in an RSN. A new sub-element in Fast Transition Element (FTE) is used to transmit the private MAC address. The sub-element's private MAC address field is wrapped with KEK or KEK2 and the appropriate key-wrapping algorithm.

15A-15C 12 are block diagrams illustrating example formats of a Fast Transition Element (FTE) for an FT 4-way handshake, according to some embodiments of the present disclosure.

With reference to 15A The format of an FTE 1500 includes an item ID field 1501, a length field 1503, a MIC control field 1505, a MIC field 1507, an ANonce field 1509 and a SNonce field 1511, and an optional parameter field 1513.

In 15B shows the format of the optional parameter field 1513 with sub-element. The optional parameter field 1513 may contain a sub-item ID field 1521 , a length field 1523 , and a data field 1525 .

In 15C the format of the existing sub-item ID field 1521 is shown.

16A-16B 10 are block diagrams illustrating example KDE formats of a Fast Transition Element (FTE) for an FT 4-way handshake, according to some embodiments of the present disclosure.

Two examples of KDE formats are presented, one for a private MAC address and another for a private identifier. That is, alternatively, a private identifier of the STA can be provided in message 2 of an FT 4-way handshake. The private identifier can be a sequence of bits instead of a MAC address. The private identifier can be a MAC address.

Similar to the private MAC address embodiments, a non-AP STA should use the same private identifier for every AP within a network identified by the same SSID.

A KDE is used to hold the private identifier. A new KDE containing the private identifier can be used for this purpose. The KDE containing the private MAC identifier is included in the key data field of message 2.

Alternatively, an additional element can be used to hold the private MAC identifier. The element containing the private MAC identifier is included in the key data field of message 2.

In both cases, the key data field of message 2 is wrapped/encrypted using KEK with an appropriate key wrapping algorithm. Also, the Encrypted Key Data field is set to 1.

Similar to the private MAC address embodiments, the private identifier can also be provided in a re-association request frame under FT re-association in an RSN. A new sub-element in FTE is used to carry the private identifier. The private identifier field of the subele ments is wrapped with KEK or KEK2 and the appropriate key-wrapping algorithm.

The private MAC address or private identifier can be provided in the frame body of the protected management frame. An IEEE 802.11 protected management frame is also encrypted based on Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) or Galois Counter Mode Protocol (GCMP).

17A-17B 10 are block diagrams showing example elements for transmitting the private MAC address or the private identifier of a fast transition element (FTE) for an FT 4-way handshake according to some embodiments of the present disclosure. Two examples of an item carrying a private MAC address or a private identifier are provided.

The private MAC address is used in the SA field of the A-MSDU sent by the non-AP STA.

After an AP obtains the private MAC address of the non-AP STA from message 2 of the FT 4-way handshake under FT Initial Mobility Domain Association, the authentication/association/FT 4-way handshake state machine is the maintained for the MAC address of the non-AP STA, now the authentication/association/FT 4-way handshake state machine maintained for the private MAC address.

Similarly, after an AP receives the private MAC address of the non-AP STA indicated from the Re-Association Request frame under FT-Re-Association in an RSN, the state machine is Authentication/Association/FT-4 -Way handshake maintained for MAC address of non-AP STA, now authentication/association/FT 4-way handshake state machine maintained for private MAC address.

The AP uses the private MAC address as the SA to transmit the data transmitted by the non-AP STA through the DS.

The AP uses the private MAC address to match the DA field of the data transmitted by the DS and transmit the data to the non-AP STA.

Before an FT 4-way handshake, the devices can exchange capability information. The following skill gauge can be deployed:

The AP can indicate whether it supports the operation of receiving a private MAC address for FT. This specification is made in RSNXE.

The AP can indicate whether the process of providing a private MAC address is required for FT. The specification is made in RSNXE.

The non-AP STA can indicate whether it supports transmission of a private MAC address for FT. The specification is made in RSNXE.

The AP can indicate whether it supports receiving a private identifier for FT. The specification is made in RSNXE.

The AP can indicate whether the process of providing a private identifier for FT is required. The specification is made in RSNXE.

The non-AP STA indicates whether it supports the FT private identifier transmission process. The specification is made in RSNXE.

For the connection between a non-AP MLD and an AP MLD using FT, a non-AP MLD has a private MAC address different from the MAC address of the connected non-AP STAs. The non-AP MLD should use the same private MAC address for a network identified by a specific SSID. That is, the non-AP MLD should give every AP with the same SSID the same private MAC address.

The MAC address of the non-AP MLD is used for wireless transmission including authentication frame exchange, association frame exchange, FT 4-way handshake, etc.

The MAC address of the non-AP MLD is used for the PMK calculation in the SAE procedure.

The MAC address of the non-AP MLD is used for S0KH-ID, S1KH-ID and SPA.

The MAC address of the non-AP MLD is used for the PTK calculation.

The private MAC address is transmitted in message 2 of the FT 4-way handshake. A KDE is used to record the private MAC address. An existing KDE with data type 3 can be used for this purpose. A new KDE containing the private MAC address can be used for this purpose.

The KDE containing the private MAC address is included in the key data field of message 2. The key data field of message 2 is encrypted using KEK with an appropriate key wrapping algorithm. Also, the Encrypted Key Data field is set to 1. The private MAC address is encrypted and provided securely.

The private MAC address can also be provided in a Re-Association Request frame under FT Re-Association in an RSN. A new sub-element in FTE is used to transmit the private MAC address. The private MAC address field of the sub-element shall be wrapped with KEK or KEK2 and the appropriate key-wrapping algorithm.

Alternatively, a private identifier of the non-AP MLD is conveyed in message 2 of the FT 4-way handshake. The private identifier cannot be a MAC address. The private identifier can be a MAC address. A non-AP MLD should use the same private identifier for a network identified by an SSID. That is, a non-AP MLD should provide the same private identifier to an AP MLD identified by the same SSID.

A KDE can be used to hold the private identifier. A new KDE containing the private identifier can be used for this purpose. The KDE containing the private MAC identifier is included in the key data field of message 2.

Alternatively, an additional element can be used to hold the private MAC identifier. The element containing the private MAC identifier is included in the key data field of message 2.

In both cases, the key data field of message 2 is wrapped/encrypted using KEK with an appropriate key wrapping algorithm. Also, the Encrypted Key Data field is set to 1.

The private identifier can also be provided in the Re-Association Request frame under FT Re-Association in an RSN. A new sub-element in FTE is used to carry the private identifier. The sub-element private identifier field is wrapped with KEK or KEK2 and the appropriate key-wrapping algorithm.

The private MAC address can be specified in the frame body of the protected management frame.

The private MAC address is used in the SA field of the A-MSDU sent by the connected STAs of the non-AP MLD.

After an AP MLD has received the private MAC address of the non-AP MLD specified in message 2 of the FT 4-way handshake as part of the initial FT mobility domain association, the state machine for the authentication/association/FT - 4-way handshake maintained for MAC address of non-AP MLD now state machine for authentication/association/FT 4-way handshake maintained for private MAC address.

After an AP MLD has received the private MAC address of the non-AP MLD from the Re-Association Request frame under FT-Re-Association in an RSN, the state machine maintained for the MAC address of the non-AP MLD is for authentication/ Association/FT 4-way handshake now the authentication/association/FT 4-way handshake state machine maintained for the private MAC address.

The AP MLD uses the private MAC address as SA to carry the data transmitted from the non-AP MLD over the DS.

The AP MLD uses the private MAC address to match the DA field of the data transmitted by the DS and transmit the data to the non-AP MLD.

Before an FT 4-way handshake, the MLDs can exchange capability information. The following capability statement may be provided:

An AP MLD indicates whether it supports receiving a private MAC address from a non-AP MLD during FT. The specification is made in RSNXE.

An AP MLD indicates whether the process of providing a private MAC address from a non-AP MLD during FT is required. The specification is made in an RSNXE of each connected AP. Each attached AP of an AP MLD reports the same value for ability to support the process of receiving a private MAC address. The indication can be made in another MLD element that indicates the MLD security capability.

A non-AP MLD indicates whether it supports the process of transmitting a private MAC address during FT. The specification is in RSNXE did. The indication can be made in another MLD element that indicates the MLD security capability.

The AP MLD indicates whether it supports the process of receiving private identifier from non-AP MLD during FT. The AP MLD indicates whether the process of providing a private identifier from a non-AP MLD during FT is required. The specification is made in RSNXE. The specification is made in the RSNXE of each connected AP. Each bonded AP of an MLD AP reports the same value for ability to support the process of receiving a private MAC address. The indication can be made in another MLD element that indicates the MLD security capability.

The non-AP MLD indicates whether it supports the process of transmitting the private identifier during FT. The specification is made in RSNXE. The indication may be included in another MLD element that indicates the MLD security capability.

2 10 shows a flow diagram of an illustrative process 200 for a privacy address system, in accordance with one or more example implementations of the present disclosure/invention.

At block 202, a device (e.g., user device(s) 120 and/or AP 102 of 1 ) to determine a private MAC (Medium Access Control) address.

In block 204, the device may determine a re-association request frame indicating the private MAC address.

In block 206, the device may cause the re-association request frame to be sent to a first station device of one or more station devices.

It is understood that the above descriptions are provided for purposes of illustration and are not to be taken as limiting.

3 FIG. 3 shows a functional diagram of an example communication station 300 according to one or more embodiments of the present disclosure/invention. In one embodiment 3 a functional block diagram of a communication station designed for use as an AP 102 ( 1 ) or as user device 120 ( 1 ) may be appropriate according to some embodiments. The communication station 300 can also be used as a handheld device, mobile device, cellular phone, smartphone, tablet, netbook, wireless terminal, laptop, portable computing device, femtocell, high data rate (HDR) subscriber station, access point, access terminal, or other PCS device ( personal communication system).

The communication station 300 may include communication circuitry 302 and a transceiver 310 for transmitting and receiving signals to and from other communication stations using one or more antennas 301 . The communications circuitry 302 may include circuitry that may operate physical layer (PHY) communications and/or medium access control (MAC) communications to control access to the wireless medium and/or any other communications layers to transmit and receive signals . The communication station 300 may also include processing circuitry 306 and memory 308 configured to perform the operations described herein. In some embodiments, the communication circuitry 302 and the processing circuitry 306 may be configured to perform the operations described in the figures, diagrams, and flows above.

According to some embodiments, the communication circuitry 302 may be configured to contend for a wireless medium and configure frames or packets to communicate over the wireless medium. Communication circuitry 302 may be configured to send and receive signals. Communications circuitry 302 may also include circuitry for modulation/demodulation, up/down conversion, filtering, amplification, and so on. In some embodiments, the processing circuitry 306 of the communication station 300 may include one or more processors. In other embodiments, two or more antennas 301 may be connected to communication circuitry 302, arranged to transmit and receive signals. Memory 308 may store information for setting up processing circuitry 306 to perform operations for configuring and transmitting message frames and performing the various operations described herein. Memory 308 may include any type of memory, including non-transitory memory, for storing information in a machine (e.g., computer) readable form. For example, memory 308 may include a computer-readable storage device, read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and other storage devices and media.

In some embodiments, the communication station 300 may be part of a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless phone, a smartphone, a wireless -Headsets, a pager, an instant messaging device, a digital camera, an access point, a television, a medical device (eg, a heart rate monitor, a blood pressure monitor, etc.), a portable computing device, or any other device that receives information wirelessly and/or or can send.

In some embodiments, the communication station 300 can include one or more antennas 301 . The antennas 301 may include one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas, or other types of antennas suitable for transmitting RF signals. In some embodiments, a single multi-aperture antenna may be used instead of two or more antennas. In these cases, each aperture can be viewed as a separate antenna. In some multiple input multiple output (MIMO) embodiments, the antennas can be effectively separated for spatial diversity and the different channel characteristics that may result between each of the antennas and the antennas of a transmitting station.

In some embodiments, the communication station 300 may include one or more of the following elements: a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other elements of the mobile device. The display can be an LCD screen with a touch screen.

Although the communication station 300 is illustrated as having several separate functional elements, two or more of the functional elements can be combined and implemented through combinations of software configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may include one or more microprocessors, DSPs, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio frequency integrated circuits (RFICs), and combinations of various hardware and logic circuits to perform at least the functions described herein. In some embodiments, the functional elements of the communication station 300 may refer to one or more processes running on one or more processing elements.

Certain embodiments may be implemented in one or a combination of hardware, firmware, and software. Other embodiments may also be implemented as instructions stored on a computer-readable device and readable and executable by at least one processor to perform the operations described herein. A computer-readable device may include any non-transitory storage mechanism for storing information in a form readable by a machine (e.g., a computer). A computer-readable storage device may include, for example, read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and other storage devices and media. In some embodiments, communication station 300 may include one or more processors and may be implemented with instructions stored on a computer-readable storage device.

4 4 shows a block diagram of an example of a machine 400 or system upon which one or more techniques (eg, methods) discussed herein may be implemented. In other embodiments, machine 400 may operate as a standalone device or may be connected (eg, networked) to other machines. In a networked deployment, machine 400 may operate in the capacity of a server, a client, or both in a server-client network environment. In one example, machine 400 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environments. Device 400 may be a personal computer (PC), tablet PC, set top box (STB), personal digital assistant (PDA), cellular phone, portable computing device, web appliance, a network router, switch, or bridge, or any device capable of executing instructions (sequential or otherwise) that specify actions to be performed by that device, such as a base station. Although only a single machine is depicted, the term "machine" is also intended to encompass any collection of machines that individually or collectively execute a set (or sets) of instructions to perform one or more of the methods discussed herein, such as Cloud Computing, Software as a Service (SaaS) or other computer cluster configurations.

The examples described herein may include or operate on logic or a number of components, modules, or mechanisms. Modules are tangible units (e.g. hardware) that are able to perform certain operations during operation. A module includes hardware. In one example, the hardware may be specifically configured (e.g., hardwired) to perform a particular operation. In another example, the hardware may include configurable execution units (e.g., transistors, circuitry, etc.) and a computer-readable medium bearing instructions, the instructions enabling the execution units to operate in a specified manner. The configuration can be established under the direction of the execution units or a loading mechanism. Accordingly, the execution units are communicatively coupled to the computer-readable medium when the device is in operation. In this example, the execution units may be part of more than one module. For example, the execution units may be operationally configured by a first set of instructions to implement a first module at one time and reconfigured by a second set of instructions to implement a second module at a second time.

Machine (e.g., computer system) 400 may include a hardware processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 404, and static storage 406, some or all of which may be can communicate with each other via an interconnect (e.g., a bus) 408 . Machine 400 may further include a power management device 432, a graphics display device 410, an alphanumeric input device 412 (e.g., a keyboard), and a user interface (UI) navigation device 414 (e.g., a mouse). In one example, the graphic display device 410, the alphanumeric input device 412, and the UI navigation device 414 may be a touchscreen display. The machine 400 may additionally include a storage device (i.e., a drive unit) 416, a signal generating device 418 (e.g., a speaker), a privacy addressing device 419, a network interface device/transceiver 420 coupled to antenna(s) 430, and one or more sensors 428, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. Device 400 may include an output controller 434, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with one or more peripheral communicate with or control devices (e.g., a printer, a card reader, etc.). The operations according to one or more embodiments of the present disclosure may be performed by a baseband processor. The baseband processor can be set up in such a way that it generates corresponding baseband signals. The baseband processor may further include physical layer (PHY) and medium access control (MAC) layer circuitry, and may further interface with the hardware processor 402 for generating and processing the baseband signals and for controlling the operations of the main memory 404, the storage device 416, and /or the privacy address device 419 form. The baseband processor can reside on a single radio card, chip, or integrated circuit (IC).

Device 416 may include a machine-readable medium 422 storing one or more sets of data structures or instructions 424 (e.g., software) embodying or used by one or more techniques or functions described herein. Instructions 424 may also reside in whole or in part in main memory 404, static storage 406, or hardware processor 402 when executed by machine 400. In an example, one or any combination of hardware processor 402, main memory 404, static storage 406, or device 416 may represent a machine-readable medium.

Privacy addressing device 419 may execute or perform any of the operations and processes (e.g., process 200) described and shown above.

It should be understood that the above functions are only a subset of what privacy addressing device 419 may implement, and that other functions included in this disclosure are also performed by privacy addressing device 419 be able.

While the machine-readable medium 422 is depicted as a single medium, the term "machine-readable medium" may encompass a single medium or multiple media (eg, a centralized or distributed database and/or associated caches and servers) used for storage of the one or more instructions 424 are established.

Various embodiments may be implemented in full or in part in software and/or firmware. This software and/or firmware may take the form of instructions embodied in or on a non-transferable computer-readable storage medium. These instructions can then be read and executed by one or more processors to enable the operations described herein to be performed. The instructions may be in any suitable form, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Such a computer-readable medium may include any tangible, non-transitory medium for storing information in a form that can be read by one or more computers, such as read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media , a flash memory, etc., but not limited thereto

The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by machine 400 and that cause machine 400 to perform one or more of the techniques of the present disclosure. or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media can include solid-state memory, optical, and magnetic media. An example of a machine-readable mass medium is a machine-readable medium having a plurality of particles of mass at rest. Specific examples of machine-readable mass media may include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks.

Instructions 424 may also be transmitted over a communications network 426 using a transmission medium via network interface device/transceiver 420 using any transmission protocol (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.) are transmitted or received. Examples of communication networks can be a local area network (LAN), a wide area network (WAN), a packet data network (e.g. the Internet), mobile networks (e.g. cellular networks), standard telephone networks (POTS), wireless data networks (e.g. IEEE 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards and peer-to-peer (P2P) networks, among others. In one example, network interface device/transceiver 420 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas for connection to communications network 426 . In one example, the network interface device/transceiver 420 may include a plurality of antennas to communicate wirelessly using at least one of the techniques SIMO (single-input multiple-output), MIMO (multiple-input multiple-output), or MISO (multiple-input input single output) is used. The term "transmission medium" encompasses any intangible medium capable of storing, encoding, or transmitting instructions for execution by machine 400, and includes digital or analog communication signals or other intangible media to facilitate communication of such software .

The acts and processes described and shown above may be performed in any suitable order as desired in different implementations. Additionally, in certain implementations, at least a portion of the operations may be performed in parallel. Additionally, fewer or more acts than described may be performed in certain implementations.

5 10 is a block diagram of a radio architecture 105A, 105B, according to some embodiments, implemented in one of example APs 102 and/or example StAs 120 of FIG 1 can be implemented. The radio architecture 105A, 105B may include radio front end module (FEM) circuitry 504a-b, radio IC circuitry 506a-b, and baseband processing circuitry 508ab. The radio architecture 105A, 105B shown includes both wireless local area network (WLAN) and Bluetooth (BT) functionality, although the embodiments are not so limited. In this disclosure, “WLAN” and “Wi-Fi” are used interchangeably.

The FEM circuitry 504a-b may include WLAN or Wi-Fi FEM circuitry 504a and Bluetooth (BT) FEM circuitry 504b. The WiFi FEM circuitry 504a may include a receive signal path comprising circuitry configured to operate on WiFi RF signals received from one or more antennas 501 emp to amplify the received signals and provide the amplified versions of the received signals to the WLAN radio IC circuit 506a for further processing. The BT FEM circuitry 504b may include a receive signal path that may include circuitry configured to operate on BT RF signals received from one or more antennas 501 to amplify the received signals and amplify the amplified Provide versions of the received signals to the BT radio IC circuit 506b for further processing. The FEM circuitry 504a may also include a transmit signal path that may include circuitry configured to amplify WLAN signals provided by the radio IC circuitry 506a for wireless transmission through one or more of the antennas 501 . Additionally, the FEM circuitry 504b may also include a transmit signal path that may include circuitry configured to amplify BT signals provided by the radio IC circuitry 506b for wireless transmission through the one or more antennas . In the embodiment of 5 Although FEM 504a and FEM 504b are shown as separate, embodiments are not so limited and include within their scope the use of a FEM (not shown) having a transmit path and/or a receive path for both WLAN and BT signals, or the use of one or more FEM circuits, wherein at least some of the FEM circuits share transmit and/or receive signal paths for both WLAN and BT signals.

The radio IC circuit 506a-b shown may include a WLAN radio IC circuit 506a and a BT radio IC circuit 506b. WLAN radio IC circuitry 506a may include a receive signal path that may include circuitry for down-converting WLAN RF signals received from FEM circuitry 504a and providing baseband signals to WLAN baseband processing circuitry 508a. BT radio IC circuitry 506b may in turn include a receive signal path that may include circuitry for downconverting BT RF signals received from FEM circuitry 504b and providing baseband signals to BT baseband processing circuitry 508b. WLAN radio IC circuitry 506a may also include a transmit signal path that includes circuitry for upconverting WLAN baseband signals provided by WLAN baseband processing circuitry 508a and providing WLAN RF output signals to FEM circuitry 504a for subsequent wireless transmission through the one or more antennas 501 . BT radio IC circuitry 506b may also include a transmit signal path that includes circuitry for upconverting BT baseband signals provided by BT baseband processing circuitry 508b and providing BT RF output signals to FEM circuitry 504b for subsequent wireless transmission by the one or more antennas 501 . In the embodiment of 5 Although radio IC circuits 506a and 506b are shown as separate from one another, the embodiments are not so limited and include within their scope the use of a radio IC circuit (not shown) having a transmit signal path and/or a receive signal path for both WLAN and BT signals, or the use of one or more radio IC circuits in which at least some of the radio IC circuits have transmit and/or receive signal paths for both WLAN and BT signals share.

The baseband processing circuitry 508a-b may include a WLAN baseband processing circuitry 508a and a BT baseband processing circuitry 508b. WLAN baseband processing circuitry 508a may include memory, such as a set of RAM arrays in a Fast Fourier Transform or Inverse Fourier Transform block (not shown) of WLAN baseband processing circuitry 508a. Each of the WLAN baseband circuitry 508a and the BT baseband circuitry 508b may further include one or more processors and control logic to process the signals received from the corresponding WLAN or BT receive signal path of the radio IC circuitry 506a-b and also corresponding WLAN - or generate BT baseband signals for the transmit signal path of radio IC circuit 506a-b. Each of the baseband processing circuits 508a and 508b may further include physical layer (PHY) and medium access control (MAC) layer circuitry and may further interface to apparatus for generating and processing the baseband signals and controlling the operations of the radio IC circuitry 506ab.

According to the 5 In the illustrated embodiment, WLAN-BT coexistence circuitry 513 may include logic that provides an interface between WLAN baseband circuitry 508a and BT baseband circuitry 508b to enable use cases requiring WLAN and BT coexistence. In addition, a switch 503 may be provided between the WLAN FEM circuit 504a and the BT FEM circuit 504b to switch between the WLAN and BT radios according to application needs. Although antennas 501 are shown connected to WLAN FEM circuitry 504a and BT FEM circuitry 504b, respectively, embodiments include within their scope the sharing of one or more antennas between the WLAN and BT FEMs or the provision of more than one antenna connected to each of the FEMs 504a or 504b.

In some embodiments, front-end module circuitry 504a-b, radio IC circuitry 506a-b, and baseband processing circuitry 508a-b may be provided on a single radio card, such as wireless radio card 502. In some other embodiments, the one or more antennas 501, FEM circuitry 504a-b, and radio IC circuitry 506a-b may reside on a single radio card. In some other embodiments, radio IC circuitry 506a-b and baseband processing circuitry 508a-b may reside on a single chip or an integrated circuit (IC), such as IC 512.

In some embodiments, the wireless radio 502 may include a WLAN radio and may be configured for Wi-Fi communication, although the scope of the embodiments is not limited in this regard. In some of these embodiments, the radio architecture 105A, 105B may be configured to receive orthogonal frequency division multiplexed (OFDM) or orthogonal frequency division multiple access (OFDMA) communication signals over a multicarrier communication channel and to send. The OFDM or OFDMA signals can have a multiplicity of orthogonal subcarriers.

In some of these multi-carrier embodiments, the radio architecture 105A, 105B may be part of a Wi-Fi communication station (STA), such as a wireless communication point (AP), a base station, or a mobile device that includes a Wi-Fi device. In some of these embodiments, the radio architecture 105A, 105B may be configured to transmit and receive signals according to certain communication standards and/or protocols, such as any of the Institute of Electrical and Electronics Engineers (IEEE) standards, including 802.1 In-2009 , IEEE 802.11-2012, IEEE 802.11-2016, 802.11n-2009, 802.11ac, 802.11ah, 802.11ad, 802.11ay and/or 802.11ax, and/or proposed specifications for WLANs, although the scope of the embodiments in this respect is not is limited. The radio architecture 105A, 105B may also be capable of sending and/or receiving communications according to other techniques and standards.

In some embodiments, the radio architecture 105A, 105B can be set up for high-efficiency Wi-Fi communication (HEW) according to the IEEE 802.11ax standard. In these embodiments, the radio architecture 105A, 105B may be arranged to communicate according to an OFDMA technique, although the scope of the embodiments is not limited in this regard.

In some other embodiments, the radio architecture 105A, 105B may be configured to transmit and receive signals transmitted using one or more other modulation techniques, such as spread spectrum modulation (e.g. Direct Sequence Code Division Multiple Access - DS-CDMA) and/or Frequency Hopping Code Division Multiple Access (FH-CDMA)), Time Division Multiplexing (TDM) modulation and/or Frequency Division Multiplexing (FDM) modulation, the scope of the embodiments in this respect is not restricted.

In some embodiments, as in 6 Further shown, the BT baseband circuitry 508b may be compliant with a Bluetooth (BT) connectivity standard such as Bluetooth, Bluetooth 8.0, or Bluetooth 6.0, or another iteration of the Bluetooth standard.

In some embodiments, the radio architecture 105A, 105B may include other radios, such as a cellular radio configured for cellular (e.g., 5GPP such as LTE, LTE-Advanced, or 7G communications).

In some embodiments of IEEE 802.11, the radio architecture 105A, 105B may be configured to communicate over different channel bandwidths, including bandwidths with center frequencies of about 900 MHz, 2.4 GHz, 5 GHz, and bandwidths of about 2 MHz, 4 MHz, 5 MHz, 5 .5 MHz, 6 MHz, 8 MHz, 10 MHz, 20 MHz, 40 MHz, 80 MHz (with contiguous bandwidths) or 80+80 MHz (160MHz) (with non-contiguous bandwidths). In some embodiments, a channel bandwidth of 920MHz may be used. However, the scope of the embodiments is not limited with respect to the center frequencies mentioned above.

6 FIG. 5 shows WLAN FEM circuitry 504a according to some embodiments. Although the example of 6 described in connection with WLAN FEM circuitry 504a can do that example from 6 in conjunction with the example BT FEM circuit 504b ( 5 ) are described, although other circuit configurations may be appropriate.

In some embodiments, the FEM circuitry 504a may include a TX/RX switch 602 for switching between transmit and receive operations. The FEM circuit 504a may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 504a may include a low-noise amplifier (LNA) 606 to amplify the received RF signals 603 and provide the amplified received RF signals 607 as an output (eg, to the radio IC circuitry 506a-b ( 5 )). The transmit signal path of circuitry 504a may include a power amplifier (PA) for amplifying the input RF signals 609 (e.g., provided by radio IC circuitry 506a-b) and one or more filters 612, such as bandpass filters (BPFs), lowpass filters (LPFs ) or other types of filters, to generate RF signals 615 for subsequent transmission (e.g., by one or more of the antennas 501 ( 5 )) via an example duplexer 614 included.

In some dual mode variants for Wi-Fi communication, the FEM circuit 504a can be configured to operate in either the 2.4 GHz frequency spectrum or the 5 GHz frequency spectrum. In these embodiments, the receive signal path of FEM circuitry 504a may include a receive signal path duplexer 604 to separate the signals from each spectrum and provide a separate LNA 606 for each spectrum, as shown. In these embodiments, the transmit signal path of the FEM circuit 504a may further include a power amplifier 610 and a filter 612, such as a BPF, an LPF, or other type of filter for each frequency spectrum, and a transmit signal path duplexer 604 to split the signals of one of the different spectrums provide a single transmission path for subsequent transmission through the one or more of the antennas 501 ( 5 ). In some embodiments, the BT communication can utilize the 2.4 GHz signal paths and use the same FEM circuitry 504a as used for the WLAN communication.

7 FIG. 5 shows the radio IC circuit 506a according to some embodiments. The radio IC circuit 506a is an example of a circuit designed for use as a WLAN or BT radio IC circuit 506a/506b ( 5 ) may be implemented, although other circuit configurations may also be suitable. Alternatively, the example of 7 will be described in connection with the example of the BT radio IC circuit 506b.

In some embodiments, the radio IC circuit 506a may include a receive signal path and a transmit signal path. The received signal path of the radio IC circuit 506a may include at least one mixer circuit 702 such as a down-conversion mixer circuit, an amplifier circuit 706 and a filter circuit 708 . The transmit signal path of the radio IC circuit 506a may include at least one filter circuit 712 and a mixer circuit 714, such as an up-conversion mixer circuit. The radio IC circuit 506a may also include a synthesizer circuit 704 for synthesizing a frequency 705 for use by the mixer circuit 702 and the mixer circuit 714 . The mixer circuitry 702 and/or 714 may be configured to provide a direct conversion function in some embodiments. The latter type of circuit has a much simpler architecture compared to standard superheterodyne mixer circuits and any flicker noise caused by this can be mitigated by using OFDM modulation, for example. 7 Figure 12 shows only a simplified version of a radio integrated circuit and, although not shown, may include embodiments where each of the circuits shown may include more than one component. For example, mixer circuitry 714 may each include one or more mixers, and filter circuitry 708 and/or 712 may each include one or more filters, such as one or more BPFs and/or LPFs, depending on application needs. For example, if the mixer circuits are of the direct conversion type, they may each contain two or more mixers.

In some embodiments, mixer circuitry 702 may be configured to combine the FEM circuitry 504a-b ( 5 ) down-converts received RF signals 607 based on the synthesized frequency 705 provided by the synthesizer circuit 704 . Amplifier circuit 706 may be configured to amplify the down-converted signals and filter circuit 708 may include an LPF configured to remove unwanted signals from the down-converted signals to generate output baseband signals 707 . The output baseband signals 707 may be sent to processing circuitry 508a-b ( 5 ) for further processing. In some embodiments, the output baseband signals 707 may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, the circuitry of the mixer 702 may include passive mixers, although the scope of the embodiments is not limited in this regard.

In some embodiments, mixer circuit 714 may be configured to up-convert input baseband signals 711 based on synthesized frequency 705 provided by synthesizer circuit 704 to generate RF output signals 609 for FEM circuitry 504a-b. The baseband signals 711 may be provided by baseband processing circuitry 508a-b and filtered by filter circuitry 712. The filter circuit 712 may include an LPF or a BPF, although the scope of the embodiments is not limited in this regard.

In some embodiments, mixer circuit 702 and mixer circuit 714 may each include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion using synthesizer 704 . In some embodiments, mixer circuit 702 and mixer circuit 714 may each include two or more mixers, each configured for frame suppression (e.g., Hartley frame suppression). In some embodiments, mixer circuit 702 and mixer circuit 714 may be configured for direct down-conversion and/or direct up-conversion. In some embodiments, mixer circuit 702 and mixer circuit 714 may be configured for superheterodyne operation, although this is not required.

The mixer circuit 702 may include or be a passive quadrature mixer (eg, for the in-phase (I) and quadrature-phase (Q) paths) according to one embodiment. In such an embodiment, the RF input signal 607 may be off 7 down-converted to provide I and Q baseband output signals that are sent to the baseband processor.

Passive quadrature mixers can be driven by zero and ninety degree time varying LO switching signals provided by a quadrature circuit which can be configured to receive a LO frequency (fLO) from a local oscillator or a synthesizer such as the LO -Frequency 705 of the synthesizer 704 ( 7 ). In some embodiments, the LO frequency may be the carrier frequency, while in other embodiments the LO frequency may be a fraction of the carrier frequency (eg, half the carrier frequency, one-third the carrier frequency). In some embodiments, the time-varying zero and ninety degree switching signals may be generated by the synthesizer, but the scope of the embodiments is not limited in this regard.

In some embodiments, the LO signals may differ in duty cycle (the percentage of a period that the LO signal is high) and/or offset (the difference between the starting points of the period). In some embodiments, the LO signals may have an 85% duty cycle and an 80% offset. In some embodiments, each branch of the mixer's circuitry (e.g., the in-phase (I) and quadrature-phase (Q) paths) can operate with an 80% duty cycle, which can result in a significant reduction in power consumption.

The RF input signal 607 ( 6 ) may comprise a balanced signal, although the scope of the embodiments is not limited in this regard. The I and Q baseband output signals can be fed to a low-noise amplifier, such as the amplifier circuit 706 ( 7 ) or the filter circuit 708 ( 7 ) are supplied.

In some embodiments, the output baseband signals 707 and the input baseband signals 711 may be analog baseband signals, although the scope of the embodiments is not limited in this regard. In some alternative embodiments, the output baseband signals 707 and the input baseband signals 711 may be digital baseband signals. In these alternate embodiments, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

In some dual-mode embodiments, a separate radio IC circuit may be provided for processing signals for each spectrum or for other spectrums not mentioned here, although the scope of the embodiments is not limited in this regard.

In some embodiments, synthesizer circuitry 704 may be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this regard, as other types of frequency synthesizers may be suitable. For example, circuit 704 may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer exhibiting a phase-locked loop with a frequency divider. In some embodiments, synthesizer circuitry 704 may include digital synthesizer circuitry. An advantage of using a digital synthesizer circuit is that while it can still contain some analog components, its footprint is much smaller than the footprint of an analog synthesizer circuit. In some embodiments, the frequency can be a The output in the synthesizer circuit 704 can be provided by a voltage controlled oscillator (VCO), although this is not a requirement. A divider control input can also be provided by baseband processing circuitry 508a-b ( 5 ) can be provided depending on the desired output frequency 705. In some embodiments, a divider control input (eg, N) may be determined from a lookup table (eg, within a Wi-Fi card) based on a channel number and channel center frequency, as determined or indicated by example application processor 510 . The application processor 510 may include or be otherwise coupled to the example secure signal converter 101 or the example receive signal converter 103 (eg, depending on which device the example radio architecture is implemented in).

In some embodiments, the synthesizer circuitry 704 may be configured to generate a carrier frequency as the output frequency 705, while in other embodiments the output frequency 705 may be a fraction of the carrier frequency (e.g., half the carrier frequency, one-third the carrier frequency). In some embodiments, the output frequency 705 may be a LO frequency (fLO).

8th FIG. 5 shows a functional block diagram of baseband processing circuitry 508a according to some embodiments. Baseband processing circuitry 508a is an example of circuitry suitable for use as baseband processing circuitry 508a ( 5 ) can be implemented, although other circuit configurations may also be suitable. Alternatively, the example of 7 be used to illustrate the example BT baseband processing circuit 508b of FIG 5 to implement.

Baseband processing circuitry 508a may include a receive baseband processor (RX BBP) 802 for processing receive baseband signals 709 received from radio IC circuitry 506a-b ( 5 ) are provided, and a transmit baseband processor (TX BBP) 804 for generating transmit baseband signals 711 for the radio IC circuitry 506a-b. The baseband processing circuitry 508a may also include control logic 806 for coordinating the operations of the baseband processing circuitry 508a.

In some embodiments (e.g., when analog baseband signals are exchanged between processing circuitry 508a-b and radio IC circuitry 506a-b), processing circuitry 508a may include an ADC 810 to convert analog baseband signals 809 transmitted by radio IC circuitry 506a-b. Circuitry 506a-b to convert to digital baseband signals for processing by RX BBP 802. In these embodiments, the processing circuitry 508a may also include a DAC 812 to convert digital baseband signals from the TX BBP 804 to analog baseband signals 811 .

In some embodiments that transmit OFDM signals or OFDMA signals, e.g., via baseband processor 508a, transmit baseband processor 804 may be configured to generate OFDM or OFDMA signals suitable for transmission by using a inverse fast Fourier transform (IFFT). The receive baseband processor 802 may be configured to process received OFDM or OFDMA signals by performing an FFT. In some embodiments, the receive baseband processor 802 may be configured to detect the presence of an OFDM signal or OFDMA signal by performing auto-correlation to detect a preamble, e.g. a short preamble, and by performing cross-correlation to detect a long preamble to recognize. The preambles may be part of a predetermined frame structure for Wi-Fi communications.

Back to 5 : In some embodiments, the antennas 501 ( 5 ) each having one or more directional or omnidirectional antennas including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas, or other types of antennas suitable for the transmission of RF signals. In some multiple input multiple output (MIMO) embodiments, the antennas can be effectively separated to take advantage of the spatial diversity and different channel characteristics that can result. The antennas 501 may each include a set of phased array antennas, although embodiments are not so limited.

Although the radio architecture 105A, 105B is illustrated as several separate functional elements, one or more of the functional elements can be combined and implemented through combinations of software configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may include one or more microprocessors, DSPs, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio frequency integrated circuits (RFICs), and combinations of various hardware and logic circuits to perform at least the functions described herein demonstrate. In some embodiments, the functional elements may refer to one or more processes running on one or more processing elements.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. As used herein, the terms “computing device,” “user device,” “communication station,” “station,” “handheld device,” “mobile device,” “wireless device,” and “user equipment” (UE) refer to a wireless communication device , such as a cellular phone, smartphone, tablet, netbook, wireless terminal, laptop, femtocell, HDR subscriber station, access point, printer, point of sale, access terminal, or other PCS (Personal communications system). The device can be either mobile or stationary.

As used in this document, the term “communicate” is intended to include sending or receiving, or both sending and receiving. This can be particularly useful in claims when describing the organization of data sent by one device and received by another, but only requiring the functionality of one of those devices for the claim to infringe. Similarly, the bi-directional exchange of data between two devices (both devices send and receive during the exchange) can be described as "communicating" when only the functionality of one of those devices is claimed. The term “communicate” as used herein with respect to a wireless communication signal includes sending the wireless communication signal and/or receiving the wireless communication signal. For example, a wireless communication unit capable of transmitting a wireless communication signal, a wireless transmitter for sending the wireless communication signal to at least one other wireless communication unit and/or a wireless communication receiver for receiving the wireless communication signal by at least one other wireless communication unit.

Unless otherwise noted, the use of the ordinal adjectives "first", "second", "third", etc. to describe a common object merely indicates that different instances of similar objects are being referred to and is not intended to imply that the so objects described must be in a specific order, whether temporal, spatial, ranked, or otherwise.

The term "access point" (AP) as used herein may mean a fixed station. An access point may also be referred to as an access node, base station, evolved node B (eNodeB), or other similar terms known in the art. An access terminal may also be referred to as a mobile station, user equipment (UE), wireless communication device, or other similar terminology known in the art. The embodiments disclosed herein generally relate to wireless networks. Some embodiments may relate to wireless networks operating according to any of the IEEE 802.11 standards.

Some embodiments may be used in connection with various devices and systems, e.g., a personal computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a PDA (Personal Digital Assistant) device, a PDA handheld device, an on-board device, an off-board device, a hybrid device, a vehicle device, a Non-vehicle device, mobile or portable device, consumer device, non-mobile or non-portable device, wireless communication station, wireless communication device, wireless access point (AP), wired or wireless router, wired or wireless modem , a video device, an audio device, an audio/video (A/V) device, a wired or a wireless network, a wireless network, a wireless video network (WVAN), a local area network (LAN), a wireless local area network (WLAN), a personal area network (PAN), a wireless PAN (WPAN) and the like.

Some embodiments may be used in connection with one-way and/or two-way radio communication systems, cellular radiotelephone communication systems, a cellular telephone, a cellular telephone, a cordless telephone, a Personal Communication System (PCS) device, a PDA device having a wireless communication device, a mobile or handheld Global Positioning System (GPS) device, a device containing a GPS receiver or transceiver or chip, a device containing an RFID element or chip, a MIMO -Transmitter/receiver or one MIMO device (Multiple Input Multiple Output), a SIMO transceiver or a SIMO device (Single Input Multiple Output), a MISO transceiver or a MISO device (Multiple Input Single Output), a device with a or multiple internal antennas and/or external antennas, DVB (Digital Video Broadcast) device or system, Multistandard radio device or system, Wired or wireless handheld device, e.g., smartphone, Wireless Application Protocol (WAP ) or the like can be used.

Some embodiments may be used in connection with one or more types of wireless communication signals and/or systems that follow one or more wireless communication protocols, e.g., radio frequency (RF), infrared (IR), frequency division multiplexing (FDM), orthogonal FDM ( OFDM), Time Division Multiplexing (TDM), Time Division Multiplexing (TDMA), Enhanced TDMA (E-TDMA), General Packet Radio Service (GPRS), Extended GPRS, Code-Division Multiple Access (CDMA), Wideband CDMA (WCDMA), CDMA 2000, Single-Carrier CDMA, Multi-Carrier CDMA, Multi-Carrier Modulation (MDM), Discrete Multi-Tone (DMT), Bluetooth, Global Positioning System (GPS), Wi-Fi, Wi-Max, ZigBee, Ultra Wideband (UWB) , Global System for Mobile Communications (GSM), 2G, 2. 5G, 3G, 3.5G, 4G, Fifth Generation Cellular Networks (5G), 3GPP, Long Term Evolution (LTE), LTE Advanced, Enhanced Data Rates for GSM Evolution ( EDGE) or similar. Other embodiments may be used in various other devices, systems, and/or networks.

The following examples relate to further embodiments.

Example 1 may include an apparatus comprising processing circuitry coupled to a memory, the processing circuitry configured to: determine a private medium access control (MAC) address; determine a re-association request frame containing the private MAC address; and causing the re-association request frame to be sent to a first one of one or more station devices.

Example 2 may include the device of Example 1 and/or any other example herein, where the private MAC address may be fixed for a specific Service Set Identifier (SSID).

Example 3 may include the device of Example 1 and/or another example herein, where the private MAC address may be different for different Service Set Identifiers (SSIDs).

Example 4 may include the device of Example 1 and/or another example herein, further comprising a transceiver configured to transmit and receive wireless signals.

Example 5 may include the device of Example 4 and/or another example herein, further comprising an antenna coupled to the transceiver to cause the transmission of the re-association request frame.

Example 6 may include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, result in the performance of operations comprising: obtaining a private medium access control (MAC) address; determining a re-association request frame that includes the private MAC address; and causing the re-association request frame to be sent to a first of one or more station devices.

Example 7 may include the non-transmittable computer-readable medium of Example 6 and/or any other example herein, where the private MAC address may be set to a specific Service Set Identifier (SSID).

Example 8 may include the non-transmittable computer-readable medium of example 6 and/or another example herein, where the private MAC address may be different for different Service Set Identifiers (SSIDs).

Example 9 may include a method, comprising: determining, by one or more processors, a private medium access control (MAC) address; determining a re-association request frame that includes the private MAC address; and causing the re-association request frame to be sent to a first device of one or more devices.

Example 10 may include the method of example 9 and/or another example herein, where the private MAC address may be set to a specific Service Set Identifier (SSID).

Example 11 may include the method of Example 9 and/or any other example herein, wherein the private MAC address for different Service Set Identifiers (SSIDs) can be different.

Example 12 may include a device comprising means for: determining a private medium access control (MAC) address; determining a re-association request frame containing the private MAC address; and causing the re-association request frame to be sent to a first device of one or more station devices.

Example 13 may include the device of example 12 and/or another example herein, where the private MAC address may be set to a specific Service Set Identifier (SSID).

Example 14 may include the device of example 12 and/or another example herein, where the private MAC address may be different for different Service Set Identifiers (SSIDs).

Example 15 may include one or more non-transitory computer-readable media depicting instructions for causing an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in any of Examples 1-14 described or refers to any of these examples, or any other method or process described herein.

Example 16 may include an apparatus demonstrating logic, modules, and/or circuitry for performing one or more elements of a method described in or related to any of Examples 1-14 or any other method or process described herein.

Example 17 may include a method, technique, or process as described in or associated with any of Examples 1-14, or portions thereof.

Example 18 may include an apparatus comprising: one or more processors; and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, technique or to perform the process as described in or associated with any of Examples 1-14, or portions thereof.

Example 19 may include a method of communicating in a wireless network as shown and described herein.

Example 20 may include a system for providing wireless communications as shown and described herein.

Example 21 may include an apparatus for providing wireless communications as shown and described herein.

Example 22 may include an access point (AP) device adapted to operate on an IEEE 802.11 network that supports Fast Basic Service Set (BSS) transition, wherein the AP Device includes processing circuitry coupled to memory configured to: communicate with a non-AP device based on a MAC address of the non-AP device; receive from the non-AP device a private identifier of the non-AP device, the private identifier provided in a second message of an FT 4-way handshake, the private identifier of the non-AP device being encrypted ; communicate with the non-AP device based on the private identifier of the non-AP device, preferably wherein the private identifier of the non-AP device is a private MAC address of the non-AP device, which is different from the MAC address of the non-AP, or preferably wherein the private identifier of the non-AP device is a sequence of bits different from the MAC address of the non-AP device, and/or preferably wherein the MAC address the non-AP device is used for over-the-air transmissions including authentication frame exchange, association frame exchange and FT 4-way handshake, and/or preferably wherein the AP device uses the private identifier of the non-AP device used as a source address (SA) to transfer data from the non-AP device to a distribution system (DS), and/or preferably wherein the AP device uses the private identifier of the non-AP device to e match a destination address (DA) of data transmitted from the DS and transmit the data to the non-AP device.

Example 23 may include the AP device of example 22, wherein the private identifier of the non-AP device is encrypted in a key data element (KDE) in the second FT 4-way handshake frame, preferably the private identifier of the non - AP device is encrypted using a key and a key-wrap algorithm, and further preferably wherein the private identifier of the non-AP device is wrapped using a key encryption key (KEK) according to a key-wrapping algorithm, or preferably wherein the private identifier of the non-AP device is encrypted in an additional element contained in a management frame, wherein, more preferably, the private identifier of the non-AP device is encrypted in a management frame using a key and a CCMP or GCMP algorithm, and wherein, more preferably, the key is PMK is derived.

Example 24 may include the AP device of examples 22 or 23, with the further steps including: maintaining a state machine for services and allowed frame exchanges for the non-AP device based on the MAC address of the non-AP device; and maintaining the state machine for services and allowed frame exchanges for the non-AP device based on the private identifier of the non-AP device when the second FT handshake frame is received.

Example 25 may include the AP device of any of Examples 22-24, wherein the processing circuitry is further configured: from the non-AP device, a re-association request frame containing the private identifier of the non-AP device; contains the private identifier of the non-AP device, preferably wherein the management frame contains an association request frame or a re-association request frame, preferably wherein the private identifier of the non-AP device is contained in an additional sub-element of an FT element in the Re - association request frame and the private identifier of the non-AP device is encrypted with a key according to a key-wrap algorithm, or preferably wherein the private identifier of the non-AP device is contained in a frame body of the management frame and the management frame is encrypted is.

Example 26 may include the AP device of any of Examples 22-25, wherein the AP device is an AP multi-link device (MLD) or an AP, and wherein if the AP device is an AP multi-link device Link Device (MLD), each associated AP of the AP-MLD indicates an equal value of the ability to support the process of receiving the private identifier of the non-AP device, preferably the indication in a robust security network extension element (RSNXE) wherein, preferably when the non-AP device is a non-AP MLD, the private identifier of the non-AP device is different from the non-AP device identifiers of each connected non-AP of the non-AP AP-MLD is different.

Example 27 is a non-AP device configured to operate on an IEEE 802.11 network that supports Fast Basic Service Set (BSS) transition (FT), wherein the non-AP device includes processing circuitry coupled to memory configured to: communicate with an access point (AP) device based on a MAC address of the non-AP device; transmit to the AP device a private identifier of the non-AP device, the private identifier of the non-AP device provided in a second message of an FT 4-way handshake, the private identifier of the non-AP -device is encrypted; and communicate with the AP device based on the private identifier of the non-AP device, preferably wherein the private identifier of the non-AP device is a private MAC address of the non-AP device, which is different from the MAC address of the non-AP device, or preferably wherein the private identifier of the non-AP device is a sequence of bits different from the MAC address of the non-AP device, and/or preferably wherein the MAC - address of the non-AP device is used for over-the-air transmissions, including authentication frame exchange, association frame exchange and FT 4-way handshake, and/or preferably wherein the non-AP device uses the private identifier of the non-AP device as a source address (SA) for an A-MSDU frame from the non-AP device to a distribution system (DS).

Example 28 may include the non-AP device of Example 27, wherein the private identifier of the non-AP device is encrypted in a key data element (KDE) in the second FT 4-way handshake frame, preferably wherein the private identifier of the non-AP device is encrypted using a key and a key wrapping algorithm, and more preferably wherein the private identifier of the non-AP device is encrypted using an encryption key (KEK) according to a key wrapping algorithm, or wherein, preferably, the private identifier of the non-AP device is encrypted in an additional element contained in the management frame, wherein, more preferably, the private identifier of the non-AP device is encrypted using a key and a CCMP or GCMP algorithm is encrypted, and where, more preferably, the key is derived from PMK.

Example 29 may include the non-AP device of examples 27 or 28, wherein the processing circuitry is further configured: a re-association request frame containing the private identifier of the non-AP device; or a management frame containing the private identifier of the non-AP device -AP device contains, to the AP device, preferably the management frame contains an association request frame or a re-association request frame, preferably, the private identifier of the non-AP device is contained in an additional sub-element of a FT element and the private identifier of the non-AP device is encrypted with a key according to a key-wrap algorithm, or, preferably, the private identifier of the non-AP device is contained in a frame body of the management frame and the management frame is encrypted.

Example 30 may include the non-AP device of any of Examples 27-29, wherein the non-AP device's transmitted private identifier is based on a service set identifier (SSID) advertised by the AP device. based, wherein preferably a different private identifier of the non-AP device is transmitted for each different SSID, and wherein preferably a same private identifier of the non-AP device is transmitted for each same SSID.

Example 31 may include the non-AP device of any of Examples 27-30, wherein the non-AP device is a non-AP multi-link device (MLD) and each attached non-AP device is the non- AP-MLD indicates an equal value of the ability to support the operation of receiving the private identifier of the non-AP device, the indication preferably being provided in a robust security network extension element (RSNXE).

Embodiments according to the disclosure are disclosed in particular in the appended claims relating to a method, a storage medium, an apparatus and a computer program product, wherein each feature recited in one claim category, e.g. method, is also claimed in another claim category, e.g. system can. The dependencies or dependencies in the appended claims are chosen for formal reasons only. However, any subject-matter resulting from intentional reference to previous claims (particularly to multiple dependencies) may also be claimed, such that any combination of claims and their features are disclosed and claimed independently of the dependencies chosen in the appended claims be able. The claimable subject-matter has not only the combinations of features set out in the appended claims, but also any other combination of features in the claims, and any feature recited in the claims may be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or illustrated herein may be claimed in a separate claim and/or in any combination with any embodiment or feature described or illustrated herein or with any of the features of the appended claims.

The foregoing description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the various embodiments.

Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, devices, and/or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flowcharts, and combinations of blocks in the block diagrams and flowcharts, respectively, can be implemented by computer-executable program instructions. Also, some blocks of the block diagrams and flowcharts do not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some implementations.

These computer-executable program instructions may be loaded onto a special purpose computer or other specified machine, processor or other programmable computing device to create a specified machine such that the instructions executed on the computer, processor or other programmable computing device provide means for implementing one or more functions specified in the flowchart block or blocks. These computer program instructions can also be stored in a computer-readable storage medium or memory capable of instructing a computer or other programmable data processing device to function in a particular manner such that the instructions stored on the computer-readable storage medium produce an article of manufacture that includes instruction means that implement one or more functions specified in the flow chart block or blocks. For example, certain implementations may provide a computer program product that is a computer-readable storage medium having computer-readable program code or program instructions implemented thereon, the computer-readable program code being adapted to be executed to implement one or more functions specified in the flowchart block or blocks . The computer program instructions may also be loaded onto a computer or other programmable computing device to cause a series of operational elements or steps to be performed on the computer or other programmable device to produce a computer-implemented process such that the instructions, executing on the computer or other programmable device, provide elements or steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, the blocks of the block diagrams and flowcharts support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions, and program instruction means for performing the specified functions. It is also understood that each block of the block diagrams and flowcharts, and combinations of blocks in the block diagrams and flowcharts, can be implemented by specific hardware-based computer systems that perform the specified functions, elements, or steps, or combinations of specific hardware and computer instructions.

Conditional expressions, such as "may", "could", "could", or "may", unless expressly stated otherwise or understood differently in the respective context, are generally intended to express that certain implementations have certain features, elements and /or may include operations that other implementations do not include. Therefore, such conditional language is generally not intended to imply that features, elements, and/or operations are in any way required of one or more implementations, or that one or more implementations necessarily contain logic to decide with or without user input or prompting whether those features, elements, and/or operations are included or intended to be performed in a particular implementation.

Many modifications and other implementations of the disclosure set forth herein will become apparent with the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is therefore to be understood that the disclosure is not limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a general and descriptive sense only and not for purposes of limitation.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• US63/162758 [0001]

Claims (10)

An access point (AP) device adapted to operate in an IEEE 802.11 network supporting Fast Basic Service Set (BSS) transition (FT), the AP device having processing circuitry coupled to a memory , wherein the processing circuit is set up: communicate with a non-AP device based on a MAC address of the non-AP device; receive from the non-AP device a private identifier of the non-AP device, the private identifier provided in a second message of an FT 4-way handshake, the private identifier of the non-AP device being encrypted ; communicate with the non-AP device based on the private identifier of the non-AP device, preferably wherein the private identifier of the non-AP device is a private MAC address of the non-AP device that is different from the MAC address of the non-AP device, or preferably wherein the private identifier of the non-AP device is a bit string different from the MAC address of the non-AP device, and/or preferably wherein the MAC address of the non-AP device is used for over-the-air transmissions including authentication frame exchange, association frame exchange and FT 4-way handshake, and/or preferably wherein the AP device uses the private identifier of the non-AP device as a source address (SA) to transmit data from the non-AP device to a distribution system (DS), and/or preferably wherein the AP device uses the private identifier of the non-AP device to match a destination address (DA) of the data transmitted from the DS and transmits the data to the non-AP device. AP device after claim 1 wherein the private identifier of the non-AP device is encrypted in a key data element (KDE) in the second FT 4-way handshake frame; preferably wherein the private identifier of the non-AP device is encrypted using a key and a key-wrap algorithm, and wherein, more preferably, the private identifier of the non-AP device is encrypted using a key (KEK) according to a key -Wrapping algorithm, or wherein, preferably, the private identifier of the non-AP device is encrypted in an additional element contained in a management frame, wherein, more preferably, the private identifier of the non-AP device is encrypted in a management framework is encrypted using a key and a CCMP or GCMP algorithm, and wherein, more preferably, the key is derived from PMK. AP device according to any one of Claims 1 until 3 further comprising: maintaining, for the non-AP device, a state machine for services and allowed frame exchanges based on the MAC address of the non-AP device; and maintaining, for the non-AP device, the state machine for services and allowed frame exchanges based on the private identifier of the non-AP device when the second FT handshake frame is received. The AP device according to any one of Claims 1 until 3 wherein the processing circuitry is further configured to: receive from the non-AP device a re-association request frame containing the private identifier of the non-AP device or a management frame containing the private identifier of the non-AP device ; preferably wherein the management frame includes an association request frame or a re-association request frame, preferably wherein the private identifier of the non-AP device is contained in an additional sub-element of an FT element in the re-association request frame and the private identifier of the non-AP device with a key according to a key-wrapping algorithm, or preferably wherein the private identifier of the non-AP device is contained in a frame body of the management frame and the management frame is encrypted. AP device according to any one of Claims 1 - 4 , wherein the AP device is an AP multi-link device (MLD) or an AP, and wherein if the AP device is an AP multi-link device (MLD), each connected AP of the AP MLD indicates an equal value of the ability to support the process of receiving the private identifier of the non-AP device, preferably providing the indication in a robust safety network extension element (RSNXE), preferably if the non-AP device has a Non-AP MLD is the private identifier of the non-AP device distinct from the non-AP devices directional identifiers of each attached non-AP device of the non-AP MLD. A non-AP device configured to operate in an IEEE 802.11 network supporting Fast Basic Service Set (BSS) transition (FT), the non-AP device including processing circuitry coupled to a memory , wherein the processing circuit is set up: communicate with an access point (AP) device based on a MAC address of the non-AP device; transmit a private identifier of the non-AP device to the AP device, wherein the private identifier of the non-AP device is provided in a second message of an FT 4-way handshake, wherein the private identifier of the non-AP device -device is encrypted; and communicate with the AP device based on the private identifier of the non-AP device; preferably wherein the private identifier of the non-AP device is a private MAC address of the non-AP device that is different from the MAC address of the non-AP device, or preferably wherein the private identifier of the non-AP device is a bit string different from the MAC address of the non-AP device, and/or preferably wherein the MAC address of the non-AP device is used for over-the-air transmissions including authentication frame exchange, association frame exchange and FT 4-way handshake, and/or preferably wherein the non-AP device uses the private identifier of the non-AP device as a source address (SA) for an A-MSDU frame from the non-AP device to a distribution system (DS). non-AP device after claim 6 wherein the private identifier of the non-AP device is encrypted in a key data element (KDE) in the second FT 4-way handshake frame; preferably wherein the private identifier of the non-AP device is encrypted using a key and a key wrapping algorithm, and wherein, more preferably, the private identifier of the non-AP device is encrypted using a key (KEK) according to a key -Wrapping algorithm, or wherein, preferably, the private identifier of the non-AP device is encrypted in an additional element contained in the management frame, wherein, more preferably, the private identifier of the non-AP device is encrypted under is encrypted using a key and a CCMP or GCMP algorithm and, more preferably, the key is derived from PMK. The non-AP device according to any one of Claims 6 until 7 , wherein the processing circuitry is further configured to transmit to the AP device a re-association request frame containing the private identifier of the non-AP device or a management frame containing the private identifier of the non-AP device, wherein preferably the management frame contains an association request frame or a re-association request frame, wherein preferably the private identifier of the non-AP device is contained in an additional sub-element of an FT element and the private identifier of the non-AP device is associated with a key according to a key- wrapping algorithm is encrypted, or preferably wherein the private identifier of the non-AP device is included in a frame body of the management frame and the management frame is encrypted. The non-AP device according to any one of Claims 6 until 8th , wherein the non-AP device private identifier transmitted by the non-AP device is based on a Service Set Identifier (SSID) advertised by the AP device, preferably for each different SSID a different non-AP device private identifier device is transmitted, and preferably for each same SSID a same private identifier of the non-AP device is transmitted. Non-AP device according to any of Claims 6 until 9 wherein the non-AP device is a non-AP multi-link device (MLD) and each connected non-AP indicates the non-AP MLD an equal value of capability, the process of receiving the private identifier of the non-AP AP device, preferably providing the indication in a Robust Safety Network Extension Element (RSNXE).

Images