FIELD OF THE INVENTION

The present invention relates to wireless communications and more specifically to user privacy during wireless communications.

BACKGROUND OF INVENTION

The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section.

Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks. The 802.11 family of standards adopted by the Institute of Electrical and Electronics Engineers (IEEE) provides a great number of mechanisms for wireless communications between stations.

Today, the evolution of wireless systems has brought privacy concerns at the forefront, driven by user demand and requirements of the General Data Protection Regulation (GDPR). The global wireless industry is faced with the growing need to protect users’ personally identifiable information from increasingly sophisticated user tracking and user profiling activities, while continuing to improve wireless services and the user experience.

In particular, the Media Access Control (MAC) address, or EUI-48 address, of a user device is an Extended Unique Identifier (EUI) composed of 48 bits and constitutes a piece of data that can be used to track this user. Indeed, the access points (APs) of wireless networks can monitor the locations of mobile devices (tablets, laptops, mobile phones, ...) of a user without his consent, by means of their MAC addresses. This is because mobile phones are configured to discover surrounding access points to wireless networks. As the user moves, his mobile phone sends requests to determine if there are any access points nearby, these requests identifying the mobile phone which sends it and including in particular the MAC address of the mobile phone. Access points that hear this request can respond. In the context of Wi-Fi networks as defined by IEEE 802.11 standards, this procedure is called Probe Request/Response exchange. So even when the phone is not connected to a Wi-Fi network, surrounding access points receive its MAC address. It is then possible to track a user by reconstructing his trajectory from access points to which his phone has sent his MAC address. Also, if the phone has been associated with one of the access points (i.e. the user has connected to an associated Wi-Fi network through that access point) and the user has indicated personal identification information (name, place of residence, ...) in the past, the access point may have recorded in a database the MAC address of the phone in association with the identification information. Therefore, even if the user is not connected to the Wi-Fi network, this identity information could be recovered by comparing the MAC address contained in a Probe Request to the MAC address used for the past association.

In the context of Wi-Fi networks, a solution has been proposed by the IEEE 802.11 working group to limit the risk of a user being traced, and consists in dynamically modifying the MAC address of the user device. This mechanism is called Randomized and Changing MAC (RCM) procedure. It has been originally introduced as a privacy enhancing feature in the 802.11 aq Pre-Association Service Discovery Task Group and finally included in the standard IEEE Std 802.11-2020. It comprises periodical change of the MAC address of a non-AP station (i.e. a station which is not an access point) to a random value, while the non-AP station is not associated to a network (or, equivalently, to an access point). The non-AP station may construct the randomized MAC address from the locally administered address space as defined in IEEE Std 8020-2014 and IEEE Std 802c™-2017. The random generator algorithm used for generating the MAC address is implementation dependent and is not standardized.

New IEEE P802.11 bi task group considers the merits and challenges presented by randomized and changing MAC addresses within an 802.11-based network.

Improved mechanisms of the above RCM procedure have been designed to allow the MAC address of the non-AP station to be changed (using the RCM mechanisms) even while the non-AP station is associated to the AP.

Co-pending application GB 2202237.0 filed on February 18, 2022 and entitled “METHOD FOR CHANGING A VALUE OF AN EXTENDED UNIQUE IDENTIFIER OF A NON-AP STATION ASSOCIATED WITH AN AP STATION”, describes such an improved mechanism. An idea of this mechanism is to define a timer to trigger the non-AP station’s MAC address change at both AP and non-AP station, that is synchronized on beacon frame reception. For example, the AP and the registered, and thus associated, non-AP station count the same number of transmitted beacon frames from a starting time point, before simultaneously changing the MAC address of the non- AP station.

A key issue with the RCM procedure is that the AP must be able to recognize the associated RCM STA as it rotates its MAC. However, while RCM increases user privacy, it also leads to potential synchronization issues and possible disruption of the user experience.

Indeed, there may be situations where the non-AP station does not receive one or more beacon frames while it is conducting an RCM procedure and is still exchanging data frames. For example, the non-AP station may experience bad radio conditions, leading to a loss of frames. As another example, the non-AP station may enter in power save mode, hence missing some beacon frames.

This should result in a time shift (of one or more TBTT - Target Beacon Transmission Time) between the non-AP station’s MAC address change at the AP and the same MAC address change at the non-AP station. On one hand, in the meantime, the AP no longer knows the old MAC address of the non-AP station since it deletes it when a new MAC address is obtained through the RCM procedure. On the other hand, this old MAC address is still used by the non-AP station to send QoS data frames to the AP. As a consequence, although the QoS data frames are legitimate, the AP rejects them as failing to identify a known MAC address.

The known RCM techniques may therefore induce desynchronization of MAC addresses.

SUMMARY OF THE INVENTION

It is a broad objective of the present invention to overcome some of the foregoing concerns. In order to correct the desynchronization, the invention proposes to take advantage of the situation where a mere frame rejection would occur, to initiate a resynchronization process and provide signaling for an anticipated change of MAC address at the transmitting non-AP station. Indeed, as the non-AP station is currently performing the RCM procedure but with a time shift compared to the AP, desynchronization can be substantially reduced by triggering an anticipated change of the MAC address. To be noted that multiple anticipated changes may be successively triggered by the AP, should the time shift spanning over multiple RCM procedure instances launched at the AP for the same non-AP station.

In this respect, the invention provides a method of synchronizing an Extended Unique Identifier, EUI, identifying a first station, the method comprising at the first station: sending, to a second station, a first frame having a Transmitter Address field set to a current EUI value of the first station, in response to the first frame, receiving from the second station an EUI resynchronization frame addressed to the current EUI value to drive the first station to change its current EUI value into a new EUI value, in response to the EUI resynchronization frame, changing the current EUI value into a new EUI value.

The first station may be a non-access point, non-AP, station and the second station, an AP. In variants, the first station is the AP and the second station is a non-AP station. In other peer- to-peer-related variants, the first and second stations are non-AP stations.

Conversely, from AP perspective, the invention provides a method of synchronizing an Extended Unique Identifier, EUI, of a first station, the method comprising, at a second station having a registry of one or more known EUI values identifying respective registered stations: receiving, from the first station, a first frame having a Transmitter Address field set to an unknown EUI value, in response to the first frame, sending an EUI resynchronization frame addressed to the unknown EUI value (e.g. through its Receiver Address field) to cause (or drive) the first station to change a current EUI value of the first station into a new EUI value.

The first frame may be explicitly addressed to the second station by having a Receiver Address field set to an EUI address of the second station.

A specific frame from the second station, namely the EUI resynchronization frame, hence triggers the anticipated change of MAC address or EUI at the first station side. This results in reduced duration of the EUI desynchronization.

In particular, the second station may have previously performed an EUI change procedure with the first station at the end of which the second station has locally changed a current EUI value of the first station into a new EUI value, e.g. in local registry. This previous MAC address change at the second station is in this case the reason of the desynchronization with the first station.

As for the RCM procedure, the new EUI value may be calculated from the current EUI value using a pseudo-random function shared between the two stations. Such EUI generation leads to chained calculations of successive EUI values: the same previous EUI value results in the same next EUI value at both first and second station sides. This allows the desynchronization to be progressively reduced by successively calculating new EUI values, up to resynchronization. This particularly applies when the first station is drastically desynchronized by more than one late EUI change procedure.

Optional features of these embodiments of the invention are defined in the appended claims. Some of these features are explained here below with reference to a method, while they can be transposed into device features.

In some embodiments, in response to the EUI resynchronization frame, the first station: computes a new EUI value using an EUl-generating function shared with the second station, and sends to the second station an EUI resynchronization response frame having a Transmitter Address field set to the new EUI value.

The anticipated MAC address change is therefore signaled to the second station, e.g. AP, for instance for the latter to check the new MAC address, i.e. to check whether the two stations are resynchronized. From AP perspective, this requires that, in response to the EUI resynchronization frame, the second station: receives, from the first station, an EUI resynchronization response frame having a Transmitter Address field set to a new EUI value, and checks whether the new EUI value is a known EUI value.

The same identifiers within the various EUI resynchronization frames may help the second station to identify a received frame is a response from the first station previously addressed. In some embodiments, a payload of the EUI resynchronization response frame is encrypted using a Global Transient Key known by the second station and the registered stations. Registered stations may be those associated with a given AP.

In some embodiments, the EUI resynchronization response frame includes a hash value encrypting, using a Pairwise Transient Key shared with the second station, a reference value known by both the first and second stations. The PTK is a well-known cryptographic key that is obtained upon a non-AP station associating with an AP station, and that is not known by other non-AP stations. This hash-based configuration allows the second station, typically the AP, upon successfully decrypting the hash value, to be confirmed having correctly identified the first station (hence it is synchronized). As it transpires from the wording, the second station may obtain such confirmation by successively decrypting the hash value into the known value, using the PTK. In other words, from its perspective, checking whether the new EUI value is a known EUI value includes: determining whether the new EUI value matches an entry in the registry of known EUI values and, in case of matching, retrieving a Pairwise Transient Key associated with the matching entry, decrypting, using the Pairwise Transient Key, a hash value included in the EUI resynchronization response frame, and checking whether the decrypted hash value matches a reference value.

In specific embodiments, the reference value includes the new EUI value provided in the Transmitter Address field. In other words, the received frame plus the PTK associated with the new EUI value are self-sufficient for the second station to obtain such confirmation. In some embodiments, an identifier kept through the exchanged EUI resynchronization frames may also be included in the hash, to avoid that malicious stations easily retrieve such identifier specific to a resynchronization sequence.

In some embodiments, some functions of the first station may be restricted during the resynchronization sequence, that are released once resynchronized. For example, upon receiving the EUI resynchronization response frame, the first station is restricted to send to the second station only EUI resynchronization response frames, and in case an EUI resynchronization confirmation frame is received from the second station in response to the EUI resynchronization response frame, the restriction on the first station is released.

From the other station perspective, in case the new EUI value is known, the second station sends an EUI resynchronization confirmation frame with a Receiver Address field set to the known EUI value.

As soon as resynchronization is detected, the first station is made aware of this thanks to this frame, in such a way normal operations for sending any type of frames can resume.

In some embodiments where the second station has previously updated, in a local registry, a current EUI value associated with the first station into a new EUI value and initialized, with an initializing value, a counter counting the number of beacon frames determining a time for a next change of the new EUI value into another new EUI value, the second station, responsive to sending the EUI resynchronization confirmation frame, reinitializes again the counter with the initializing value. This is to ensure that not only the MAC addresses are resynchronized but also the timing of the EUI Change procedure are fully synchronized between the two stations.

In some embodiments, the EUI resynchronization confirmation frame includes a hash value encrypting, using a Pairwise Transient Key shared between the first and second stations, a reference value known by both stations. Again, this may be the new EUI value or another EUI value such as the MAC address of the second station (e.g. the AP).

This confirmation frame shows to the first station that the second station has correctly matched the new EUI value with the PTK of the first station.

Should the first station be desynchronized by more than one EUI new calculation, the triggered anticipated MAC address change is not enough to restore synchronization. Hence, in some embodiments, in case the new EUI value does not match an entry in the registry of known EUI values, the second station sends a new EUI resynchronization frame with a Receiver Address field set to the unknown new EUI value. This signals to the non-AP (first) station that it is not yet synchronized despite the new EUI value. From first station perspective, it means the method further comprises at the non-AP station: receiving a new EUI resynchronization frame from the second station in response to the EUI resynchronization response frame, and in response to the new EUI resynchronization frame, changing the current EUI value into another new EUI value and sending a new EUI resynchronization response frame having a Transmitter Address field set to the other new EUI value.

In other words, the first station is triggered to anticipate another MAC address change. This configuration gradually reduces the gap (in number of late EUls) in restoring synchronization between the two stations.

Multiple successive anticipated MAC address changes may be triggered by the second station. Therefore, at the second station, the method may further comprise: each time a new EUI resynchronization response frame is received from the first station with a Transmitter Address field set to a new EUI value that does not match an entry in the registry of known EUI values, sending a new EUI resynchronization frame with a Receiver Address field set to the unknown new EUI value, to cause the first station to change again its current EUI value into another new EUI value.

Corresponding, the method at the first station may further comprise: each time a new EUI resynchronization frame is received from the second station in response to a sent EUI resynchronization response frame, changing the current EUI value into another new EUI value and sending a new EUI resynchronization response frame having a Transmitter Address field set to the other new EUI value. Again, the same identifiers through the various exchanged EUI resynchronization frames may help the two stations to identify the frames belonging to the same resynchronization procedure instance (sequence).

To avoid an infinite exchange of frame when the two stations cannot be resynchronized, it is provided an exit procedure to the above loop of frame exchange, in which case the first station may intend to reassociate. From one perspective, the second station may no longer send a new EUI resynchronization frame to the first station upon failing to identify a new EUI value in the registry of known EUI values, after a predefined number of EUI resynchronization frames sent to the first station and EUI resynchronization response frames received from the first station. Similarly, from reverse perspective, the first station has previously associated with the second station, and the first stations triggers a reassociation procedure with the second station upon failing to receive a EUI resynchronization confirmation frame from the second station after a predefined number of EUI resynchronization frames received from the second station and EUI resynchronization response frames sent to the second station.

In practice, the predefined number may be low, less than 10, e.g. 3, 4, 5 or 6. This is to reduce overhead messages on the wireless medium.

The embodiments above lie on exchanges of various EUI resynchronization frames. Alternative embodiments may contemplate reducing the number of such frames to a single one when the second station clearly identifies the first station. In some embodiments at the second station, the method may further comprise: determining a Pairwise Transient Key associated with an entry of the registry of known EUI values that decrypts a frame body of the first frame, and providing the known EUI value of the entry within the EUI resynchronization frame.

In that way, the second station provides the correct EUI (as locally determined) to the first station, without additional frame exchanges. At the first station, this means changing the current EUI value includes retrieving the new EUI value from the EUI resynchronization frame.

For security reasons, providing the known EUI value may include encrypting the known EUI value using the Pairwise Transient Key into a hash value embedded in the EUI resynchronization frame. Therefore, at the first station, retrieving the new EUI value may include decrypting, using a Pairwise Transient Key shared with the second station, a hash value included in the EUI resynchronization frame.

A brute force approach may be adopted to determine the PTK, which is particularly suitable for a second station that has a registry with a reasonable number of entries. In that case, determining a Pairwise Transient Key includes: traversing entries of the registry of known EUI values, and for each entry traversed: retrieving a Pairwise Transient Key associated with the entry, decrypting, using the Pairwise Transient Key, the frame body of the first frame, and determining whether the decrypting frame body matches a reference frame format. For illustrative purposes, this may be the format of an A-MSDU (Aggregate MAC Service Data Unit) or TCP header. Succeeding in determining a known format ensures that decryption is successful, ensures that the PTK used corresponds to the non-AP station, hence ensured that the associated MAC address in the entry is the current one for the first station.

In some embodiments, the method at the first station may then further comprise: sending to the second station an EUI resynchronization response frame having a Transmitter Address field set to the retrieved new EUI value, and receiving from the second station an EUI resynchronization confirmation frame having a Receiver Address field set to the retrieved new EUI value.

Correspondingly, at the second station, the method may further comprises: receiving, from the first station, an EUI resynchronization response frame having a Transmitter Address field set to the known EUI value, and sending an EUI resynchronization confirmation frame with a Receiver Address field set to the known EUI value.

In that way, a confirmation exchanged is performed between the two stations to validate the exchanged EUI value as the correct one for the first station, hence ending the resynchonization.

Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out the steps of any of the above methods. The wireless communication device is thus either a non-AP station or an AP station.

Another aspect of the invention relates to an EUI resynchronization frame including signaling that causes an addressee station of the frame to change a current EUI value of the addressee station into a new EUI value. Indeed, this frame contributes to reduce or remove any desynchronization of changing EUI value (MAC address) between two stations.

This frame may include any limitation as described above. As an example, the frame causes the addressee station to calculate the new EUI value from the current EUI value using a pseudo-random function shared between the addressee station and another station transmitting the frame.

Yet another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as defined above.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid- state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

Figure 1 illustrates an example of a network system in which embodiments of the invention may be used;

Figure 1a illustrates an exemplary association sequence of management frames allowing a not-yet-associated non-AP station to discover and register with an AP in order to join the corresponding BSS;

Figure 1 b illustrates an example of a frame format to advertise the capability of a station to support the ERCM mechanism, according to one or several embodiments of the invention;

Figure 1c schematically illustrates a registry for the AP to store details on each registered non-AP station, including its current MAC address, its AID and its associated PTK, according to one or several embodiments of the invention;

Figure 2a illustrates a flowchart for operating an enhanced MAC address change procedure ERCM, according to embodiments of the invention;

Figure 2b illustrates exemplary frame formats to generate and exchange the ERCM Key, according to one or several embodiments of the invention;

Figure 2c which illustrates an exemplary sequence for operating an ERCM procedure instance changing the MAC address of a non-AP station in a synchronous way, according to embodiments of the invention;

Figure 2d schematically illustrates a MAC data frame;

Figure 3 schematically illustrates an exemplary sequence of desynchronization between the AP and a non-AP station;

Figure 4 illustrates, using a flowchart, exemplary resynchronization steps at the AP, according to some embodiments of the invention;

Figure 4a illustrates, using a flowchart, exemplary resynchronization steps at the AP, according to other embodiments of the invention; Figure 5 illustrates, using a flowchart, exemplary resynchronization steps the non-AP station, according to some embodiments of the invention;

Figure 5a illustrates, using a flowchart, exemplary resynchronization steps the non-AP station, according to other embodiments of the invention;

Figure 6 illustrates exemplary frame formats for operating a resynchronization procedure, according to one or several embodiments of the invention;

Figure 7 schematically illustrates an exemplary sequence of resynchronization the non- AP station with the AP using the second resynchronization mechanism according to one or several embodiments of the invention;

Figure 7a schematically illustrates an exemplary sequence of resynchronization the non- AP station with the AP using the first resynchronization mechanism according to one or several embodiments of the invention; and

Figure 8 illustrates an example of a communication device of a wireless network, configured to implement at least one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

According to embodiments, the invention proposes to synchronize an Extended Unique Identifier (EUI), such as a MAC address, identifying a first station when this station performs changing MAC address procedures over the time together with a second station.

In a first scenario, the first station is a non-access point, non-AP, station and the second station, an AP to which the non-AP station has previously associated. In that case, the resynchronization procedure of the invention intends to resynchronize the non-AP station.

In a second scenario, the first station is the AP and the second station is a non-AP station, in which case the resynchronization procedure of the invention intends to resynchronize the AP station.

In a third and peer-to-peer (P2P)-related scenario, the first and second stations are non- AP stations, one of which is late in changing its MAC address.

For ease of explanation, the description below concentrates on the first scenario. However, the teachings also apply to the other scenario by merely identifying the roles of the first and second stations. In particular, the establishment of P2P connections by a station with other stations may equate the association of non-AP stations to an AP in the building of a registry as exposed below.

The MAC address, or EUI-48 address, of a device is an Extended Unique Identifier (EUI) composed of 48 bits. It can be administered universally or locally. A universally administered address is uniquely assigned to the device by the manufacturer. On the contrary, a locally administered address is assigned to the device by software or network administrator, and replaces the physical burned-in address. The second-least-significant bit of the first octet of the MAC address, i.e. the seventh bit of the address, also referred to as “U/L bit” (for “Universal/Local bit”), indicates whether it is universally (when set to 0) or locally (when set to 1) administered. The least-significant bit of the first octet of the MAC address, i.e. the eighth bit of the address, also referred to as “l/G bit” (for “Individual/Group bit”), indicates whether the frame is sent to only one receiving device (when set to 0, indicating unicast transmission) or to a plurality of devices (when set to 1 , indicating multicast transmission).

A changing MAC address procedure is based on the fact that the AP and the non-AP station each determine in parallel the next MAC address of the non-AP station, so as to obtain the same result. This next MAC address is used as new MAC address by the non-AP station. The AP, which stores a registry or list with all the MAC addresses of the non-AP stations associated with it, updates the registry with the new MAC address of the concerned non-AP station when performing a changing MAC address procedure.

The AP and the non-AP station apply the MAC change in a synchronized manner, to prevent frames from being sent with an old MAC address which is no longer the current address of the station, or with a MAC address updated at one entity but not at the other. To ensure the synchronization, both the non-AP station and the AP base the MAC change time on the same counter without exchanging explicit indication on that MAC change time (for security reasons), e.g. based on a count of beacon frames sent by the AP station and thus received by the non-AP station.

Desynchronization may appear as soon as the non-AP station misses one or more beacon frames. The non-AP station is therefore late in changing its MAC address compared to the AP. Although lateness usually regards a single instance of changing MAC address procedure, it may also be spread over multiple changing MAC address procedure instances for example when the non-AP station is in a power save mode for a long time or when it experiences very poor radio conditions without transmitting for a while.

To correct the desynchronization in MAC address, the invention proposes that upon receiving a data frame having a Transmitter Address field set to an unknown MAC value (compared to the registry of known MAC addresses) and a Receiver address field set to an EUI address of the second station, the AP sends a MAC resynchronization frame addressed to the unknown MAC address value (e.g. through its Receiver Address field) to drive or cause the addressee non-AP station to change its current MAC address value into a new MAC address value. This forces the non-AP station to anticipate the changing of its MAC address, hence to execute one late changing MAC address procedure. In response to the MAC resynchronization frame, the non-AP station therefore changes the current MAC address value into a new MAC address value. Should the lateness was a single instance of changing MAC address procedure, the non-AP station is now resynchronized.

In embodiments where the lateness amounts of multiple changing MAC address procedure instances, multiple MAC resynchronization frames can be sent to try to gradually decrease the desynchronization up to resynchronization. When the new MAC address value is recognized as being the one in the registry, confirmation of resynchronization can be sent. Even if the following description is focused on the change of MAC address, the invention can be applied for other types of identifiers, for instance other Extended Unique Identifiers (EUls), such as EUI-64.

The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e. wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers.

The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so-called AP or AP station) or not (so-called non-AP STA or non-AP station).

While the examples and embodiment are described in the context of Wi-Fi networks, the invention may be used in any type of wireless networks, like, for example, mobile phone cellular networks that implement very similar mechanisms.

Figure 1 illustrates an example of a network system in which embodiments of the invention may be used.

Figure 1 represents an 802.11 network (i.e. a Wi-Fi network) system 100 comprising four wireless devices: an access point (AP) 110 and three non-AP ST As (non-AP STAs) 120a, 120b, 120c. Of course, the number of non-AP STAs 120a, 120b, 120c may be different from three. The AP 1 10 provides wireless connections between the non-AP STAs 120a, 120b, 120c and a wider network, such as the Internet. The connection of a non-AP STA 120a, 120b, 120c to the AP 110 is performed by a standardized process called association. Once a non-AP STA 120a, 120b, 120c is associated with the AP 1 10, the non-AP STA 120a, 120b, 120c can send data to the network and receive data from the network through the AP 1 10.

The AP 110 may comprise, be implemented as, or known as a Node B, Radio Network Controller (RNC), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (BSC), Base Transceiver Station (BTS), Base Station (BS), Transceiver Function (TF), Radio Router, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or some other terminology. It can be a standalone product or it may be integrated in a device, for instance a broadband remote access server (BRAS).

A non-AP STA 120a, 120b, 120c may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, a user equipment (UE), a user station (STA), or some other terminology. In some implementations, a non-AP STA 120a, 120b, 120c may be or may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or a smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP STA 120a, 120b, 120c may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

The AP 110 manages a set of stations that together organize their accesses to the wireless medium for communication purposes. All the stations (AP 110 and non-AP STA 120a, 120b, 120c) form a service set, which may be referred to as basic service set, BSS (although other terminology can be used). It is noted that the AP 110 may manage more than one BSS: each BSS is thus uniquely identified by a specific basic service set identifier (BSSID) and managed by a separate virtual AP implemented in the physical AP 1 10.

The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium, the current version being the standard IEEE Std 802.11- 2020. In particular, it includes the 802.11 aq Pre-Association Service Discovery Task Group in which the user privacy has been introduced. In order to ensure the user privacy, the non-AP STA 120a, 120b, 120c have been configured with a dot11 MACPrivacyActivated set to true.

For this, a new Management Information Base (MIB) variable, referred to as dot11 MACPrivacyActivated, has been specified, controllable by an external management entity. When dot11 MACPrivacyActivated is set to true, a non-AP station applies specific mechanisms for enhancing the user privacy at MAC level. The main mechanism is the periodic change of the MAC address of the non-AP station to a random value while not associated to a BSS. The non- AP station constructs the randomized MAC address from the locally administered address space as defined in IEEE Std 802-2014 and IEEE Std 802c™-2017. This mechanism is referred to as Randomized and Changing MAC (RCM). Moreover, when a RCM is operated, counters in all sequence number spaces used to identify data frame (MSDU or MMPDU) are reset and the non- AP station also resets seeds used within the PHY DATA scrambler on the next PPDU to be transmitted.

When RCM mechanism is operated in the non-AP station, the MAC address of the non- AP station is randomly changed (for instance periodically). More specifically, the U/L bit is set to 1 , the l/G bit is set to 0, and the remaining 46 bits are randomly generated by using a pseudorandom function (PRF) specified in section 12.7.1.2 of the standard IEEE Std 802.11- 2020. The PRF is a function of four parameters K, A, B and Len. Len represents the length of the result of the function, i.e. the number (128, 192, 256, ...) of bits pseudorandomly generated, K is a secret key coded on 256 bits, A is a text string specific to the application for which the PRF is used, and B is a variable length string. In the RCM procedure of the standard IEEE Std 802.1 1- 2020, the PRF-128, i.e. PRF(K, A, B, 128), which generates 128 pseudorandom bits, is used. From the generated 128 bits, the leftmost 46 bits (i.e. the 46 most significant bits) are selected to generate the 46 bits of the new MAC address, to be concatenated with the U/L and l/G bits. This function is referred to as PRF-128/46.

RCM-based user privacy has been extended to yet-associated non-AP stations as described below. Such extended (or enhanced) procedure is referred to as Extended/Enhanced RCM or ERCM procedure.

Figure 1a illustrates an exemplary sequence of association management frames allowing a not-yet-associated non-AP STA 120 to discover and register with the AP 110 in order to join the corresponding BSS. It comprises three phases: WLAN or BSS discovery, authentication and association, at the end of which the station enters into an authenticated and associated state with the AP. Note that the non-AP station may be currently associated with a first AP (i.e. belonging to a first WLAN) and willing to join a second WLAN (with which it is not associated). The WLAN discovery phase may be performed simultaneously by the non-AP STA with multiple APs, for instance to choose the best BSS.

The WLAN discovery can be done through passive and/or active scanning operations on frequency channels in one or more of the frequency bands (typically 2.4 GHz, 5 GHz and 6 GHz bands). This is for the unassociated non-AP STA to gather network information about the APs.

The passive scanning consists for the unassociated non-AP STA in listening beacon frames 151 sent periodically by an AP on the medium. The beacon frames 151 provide details on the BSS: SSID (wireless network name), supported data rates, encryption types, and other 802.1 1 capabilities of the AP.

The active scanning consists in an exchange of management frames between the unassociated non-AP STA and the AP, for instance by sending out Probe Request frames 150 on the wireless channel. For example, the non-AP STA may send such a management frame to each AP it knows (e.g. to each AP with which it has already been associated in the past). In response to receiving such a Probe Request frame, the AP checks whether the unassociated non-AP STA has a common supported data rate or not. In the affirmative, the AP responds with a Probe Response frame 152 providing details on the BSS: SSID (wireless network name), supported data rates, encryption types, and other 802.11 capabilities of the AP.

A non-AP STA (possible already registered for a WLAN but seen as unassociated for other WLANs) may send Probe Request frames regularly onto other wireless channels to maintain an updated registry of available WLANs without any intend to associate with the other WLANs. However, it allows the non-AP STA to possible roam to another AP with a better signal strength (using the second and third phases of the association procedure) if needed.

In particular, the Beacon frames 151 and/or the Probe Response frames 152 may include a declaration from the AP of a support of the ERCM procedure according to the invention. Also, the Probe Request frame 150 may include a declaration from the non-AP STA of a support of the ERCM procedure according to the invention.

Once the unassociated non-AP STA has decided to join a WLAN (based on network information gathered from the various WLANs), it performs the second and authentication phase during which it sends a low-level 802.11 Authentication Request frame 160 to the selected AP. The AP may respond with an Authentication Response frame 162.

Next, the unassociated non-AP STA performs actual four-way handshake association with the AP to join the WLAN cell (or BSS). This stage finalizes the security and bit rate options and establishes the data link between the unassociated non-AP STA and the AP. The purpose of this final exchange is for the unassociated non-AP station to obtain its Association Identifier (AID) to be used to access the medium and send data within the joined BSS, as well as to generate a key specific to the non-AP station, called Pairwise Transient Key (PTK), that is the key to be used for ciphering communications with the AP. The PTK is usually derived from is derived from the PMK (Pairwise Master Key). To do the association, the unassociated non-AP STA sends an Association Request frame 170 to the AP of the BSS it wishes to join. The Association Request frame contains chosen encryption types if required and other compatible 802.11 capabilities.

In particular, the Association Request frame 170 may include a declaration from the non- AP STA of a support of the ERCM procedure according to the invention.

Figure 1 b illustrates an example of a frame format to advertise the capability of a station (AP or non-AP STA) to support the ERCM procedure, according to one or several embodiments of the invention. An ERCM Capability field is used in the non-AP STA and AP to advertise their capability to support the ERCM mechanism.

In one or more embodiments, the capability for the station to support ERCM procedure may be signaled during association using an Extended Capabilities Information Element (IE) 1000 contained in the exchanged management frames as defined in the section 9.4.2.26 of the standard IEEE Std 802.11-2020.

As represented in Figure 1 b, the Extended Capabilities IE 1000 contains three fields: an Element ID field 1010, a length field 1020 and an Extended Capabilities field 1030. The Element ID field 1010 is set to value ‘127’ corresponding to ‘Extended Capabilities’ extended. The length field 1020 indicates the number of octets in the Extended Capabilities field 1030 excluding the Element ID field 1010 and the length field 1020. For illustrative purpose, it may be set to n=16 octets. The Extended Capabilities field 1030 is a bit field indicating the extended capabilities being advertised by the station transmitting the IE. The Extended Capabilities field is shown in Table 9- 153 of the standard IEEE Std 802.11-2020.

A bit so far reserved in the standard may be assigned to the ERCM capability, to indicate whether the station supports ERCM procedure or not. It may correspond to the k-th bit of the Extended Capabilities field 1030, k being an integer between 88 and 8*n, n being the length of the Extended Capabilities field 1030 expressed in number of bytes. When this bit is set to 1 , it indicates that the station supports the ERCM procedure, and when this bit is set to 0, it indicates that the ERCM procedure is not supported by the station.

Backto Figure 1a, if the elements in the Association Request frame match the capabilities of the AP, the AP creates an Association ID (AID) for the unassociated non-AP STA and responds with an Association Response frame 172 including the AID and a success message granting network access to the non-AP STA. Now the non-AP STA is successfully associated with (registered to) the AP and data transfer (180) can begin in the chosen BSS using the AID.

The Beacon frame 151 , Probe Response frame 152, Authentication Request/Response frames 160 and 162, Association Request/Response frames 170 and 172 and Disassociation frame 190 are management frames emitted in an 802.11 legacy format, known as a single user (SU) format. Each of these management frames is acknowledged by an ACK frame 199.

At the end of the association procedure, the AP updates its registry 1100 listing all the registered non-AP stations. As exemplarily illustrated in Figure 1c, each entry 1110 in the registry is associated with a registered non-AP station may include the MAC address of the non-AP station together with its allocated AID and its associated PTK.

Figure 2a illustrates a flowchart for operating an enhanced MAC address change procedure ERCM, according to embodiments of the invention. It is assumed that the non-AP station is already registered to the AP as described above.

During the initiation of the procedure (210), the non-AP station and the AP obtain the same key, referred to as “ERCM key” (shared between the two stations), which is used to calculate the new MAC address of the non-AP station.

The obtaining the ERCM key may take place during the authentication and association procedures between the non-AP station and the AP. As an example, the PTK may be used as ERCM key. In a variant, it may be a key separate from the PTK key (e.g. in a further field of corresponding entry 1110 at AP side).

Alternatively, the ERCM key may correspond to any key shared between the non-AP station with the AP. For example, this shared key may be stored in the memory of the device comprising the AP (e.g. an internet connection box), and may also be read by a user on the housing of this device. The user may then enter this shared key manually, for example by means of a touch screen, into the user equipment comprising the non-AP station. Of course, other solutions for the user equipment comprising the non-AP station to recover the ERCM key are possible. For example, the ERCM key may be read elsewhere than on the housing of the device comprising the AP (e.g. on a notice supplied with the device), or can be received directly on the user equipment comprising the non-AP station from another equipment (e.g. by Short Message Service, SMS, or via a Bluetooth® connection). It is noted that in these embodiments, the ERCM key is common to all the non-AP stations. In these alternative embodiments, the ERCM key is not exchanged between the non-AP station and the AP. Therefore, the ERCM key cannot be recovered by a third party which would listen to the communications between the two entities (and could thus also calculate the next MAC address of the non-AP station), which ensures the security of the MAC address change procedure.

In other embodiments, the ERCM key may be generated at the non-AP station and transmitted to the AP after association, to benefit from the PTK-based encryption of all communications between the non-AP station and the AP. For example, the AP 110 may transmit a request to the non-AP station 120 to obtain an ERCM key. Alternatively, the request may be sent to a third device which transmits it to the non-AP station 120. For example, this request may be an “ERCM Key delivery Request” frame 250 of Figure 2b. At the reception of the ERCM Key delivery Request 250, the non-AP station 120 may generate the ERCM key, for instance on 256 bits, whatever the generation algorithm, be it based on PMK, PTK or not. The generated ERCM key is fed back to the AP 1 10 using an “ERCM Key delivery Response” frame 260. The AP 1 10 may acknowledge receipt of the ERCM key using an “ERCM Key delivery Confirm” frame 270.

Figure 2b illustrates exemplary frame formats to generate and exchange the ERCM Key, according to one or several embodiments of the invention. Those frames are action frames in the meaning of IEEE Std 802.11-2020.

All frame formats represented in Figure 2b are identified by a ‘Category’ field 251 , 261 , 271 assigned to a specific value k in the range [31 ,125] as specified in the table 9-51 of the IEEE Std 802.11-2020, so far reserved. For the purpose of illustration, a new category value is defined that is assigned for ERCM action frames. For example, new category value is set to 31 . Of course, any other value in the above range may be used.

The frame formats represented in Figure 2b are identified by the single octet ‘ERCM Action’ field 252, 262, 272, which follows immediately the Category field. The values of the ERCM Action field may be defined as follows: Action field value is set to 1 to signal an ERCM Key delivery Request Action frame 250, set to 2 to signal an ERCM Key delivery Response Action frame 260, and set to 3 to signal an ERCM Key delivery Confirm Action frame 270.

Back to Figure 2a, next, at step 220, an ERCM procedure, i.e. an EUI change procedure, is triggered, at the end of which the non-AP station and the AP change the current value MAC address of the non-AP station into a new MAC address value. The end of the ERCM procedure defines the time at which the change of MAC address is actually done.

In some embodiments, the end of the procedure is determined by counting a number of beacon frames sent by the AP station from the start of the procedure. Hence a beacon counter is implemented at both the AP and the non-AP station. The beacon counter value corresponds to the time (in number of Target Beacon Transmission Times (TBTTs)) when the new MAC address will be applied on the both sides. In variants, another criterion than the number of beacon frames can be used to determine the end of the procedure, such as a mere counting of time from a predetermined time point or a reference event defining the beginning of the procedure. Note that the reference event may be missed by either one of the non-AP station or the AP station leading to a loss of MAC address synchronization.

In some embodiments, the new MAC address and the beacon counter value may be calculated randomly. For example, the new MAC address and the beacon counter value may be obtained from the result of the same pseudorandom function (PRF) applied to the same input parameters by the AP 110 and the non-AP station 120. Therefore, both the AP 110 and the non- AP station 120 obtain the same outputs. The pseudorandom function of the standard (specified for instance in section 12.7.1.2 of the standard IEEE Std 802.11-2020) may advantageously be reused within the framework of the present invention. It is referred below to the “ERCM PRF”.

The ERCM PRF is based on the four input parameters: K, A, B and Len. Parameter Len is described above. Parameter K is the ERCM key, i.e. a secret information known by the non-AP STA and the AP. Parameter A is set to string, e.g. “ERCM”, to indicate that the PRF is used for calculating a new MAC address and a new beacon counter in the context of the ERCM mechanism. Parameter B corresponds to any value known by both the non-AP STA and the AP, which value changes over time.

In some embodiments, this shared value is the current MAC address of the non-AP STA, i.e. @MAC _n . This allows having the successive MAC addresses of the non-AP station to be chained by successive executions of the same ERCM PRF to the result (@MAC) of the previous ERCM PRF execution. As an example, @MAC _n +i is built from PRF-128/46( ERCM Key, “ERCM”, @MAC _n ) with the addition of two fixed bits (U/L bit set to 1 and l/G bit set to 0).

In some embodiments, more than the leftmost 46 bits are retrieved from the PRF, e.g. 50 bits so to include the calculation of the beacon counter initial value, denoted CC _n +i. Hence, @MAC _n +i is obtained as above with the leftmost 46 bits of the 50-bit PRF result, while CCn+i equals the remaining four bits of the 50-bit PRF result.

In variants, CC _n +i may be computerfrom CC _n (previous beacon counter initial value) using the leftmost 4 bits of the PRF. For example, CC _n+i = PRF-128/4( ERCM Key, “ERCM”, CC _n ).

Of course, other embodiments may contemplate using another shared value, e.g. predefined values, a current time, and so on.

In some embodiments, an initial instance of the ERCM procedure is triggered at the end of the association procedure (Figure 1a) and a new instance is triggered each time the MAC address of the non-AP station is changed, meaning the new MAC address and beacon counter value are determined as soon as the previous MAC address is changed.

After having obtained the value of the next MAC address of the non-AP station and the initial value of the beacon counter, the non-AP station and the AP both wait for the end of the timer defined by the beacon counter value to be reached to apply the change of the MAC address. This is done by counting the beacon frames broadcast by the AP as illustrated through Figure 2c which illustrates an exemplary sequence for operating an ERCM procedure instance changing the MAC address of a non-AP station in a synchronous way, according to embodiments of the invention.

In this sequence, the non-AP station and the AP have initially computed the new MAC address @MAC _n that becomes the current MAC address of the non-AP station (hence the AP has updated the corresponding entry 1110 of its registry) as well as the initial value CC _n for the beacon counter dedicated to the next ERCM procedure instance.

The ERCM Change counter at each side (AP and non-AP) is initialized with the calculate value CC _n , e.g. when receiving the first beacon frame 223 following the @MAC _n and CC _n calculation.

Next, each time a new beacon frame 224, 225 is sent I received, the ERCM Change counters are decremented by one unit at both the AP 110 and the non-AP station 120.

When its own ERCM Change counter reaches the value zero (at step 225), the change of the MAC address may be performed by the concerned station (AP or non-AP although they should be synchronized): the next value @MAC _n +i for the non-AP station 120 and the next value of the ERCM Change counter CC _n +i are calculated, and @MAC _n +i is stored in the local registry 1100 in replacement of the old @MAC _n . On the other hand, CC _n +i is used to reinitialize the ERCM Change counter for the next ERCM procedure instance as described above.

All transmissions subsequent to the transmission of beacon frame 225 are done with the new MAC address, @MAC _n +i. This means that the non-AP station sends frames, in which Transmitter Address field in the MAC header is set to @MAC _n +i, while the AP sends frames to the non-AP station, in which the Receiver Address field in the MAC header is set to @MAC _n +i.

As shown in Figure 2d, a MAC data frame 2000 comprises a MAC header 2100, a frame body 2200 and a FCS field 2300. The frame body includes the data that are encrypted using a cryptographic key, PTK for frames specific to a non-AP station and GTK (Global Transient Key) for broadcast frames addressed to the non-AP stations of the BSS managed by the AP.

The MAC header 2100 includes, amongst other fields, Address 1 field 2110, Address 2 field 21 120, Address 3 field 2130 and Address 4 field 2140. Usually, Address 1 field 2110 is the Receiver Address specifying the MAC address of the addressee station, while Address 2 field 2120 is the Transmitter Address specifying the MAC address of the transmitting station.

Back to Figure 2a, step 230 updates (increments or decrements) at each sent/received beacon frame and then transits to step 240 upon reaching a predetermined number, here zero.

At step 231 , the AP orthe non-AP station (usually both) where the ERCM Change counter has reached zero applies the new MAC address @MAC _n +i.

The synchronization of the MAC Address change must be highly synchronized to ensure that both stations use the same MAC address of the non-AP station and thus avoid frame losses due to unknown MAC address in a received frame. Desynchronization of MAC address between the AP and the non-AP station may indeed occur as illustrated in Figure 3. Figure 3 schematically illustrates an exemplary sequence of desynchronization between the AP and the non-AP station.

When an ERCM procedure instance is launched (300) while the current MAC address of the non-AP station is @MAC _n , the new MAC address @MAC _n +i is applied after a predetermined number CC _n of TBTTs (i.e. beacon frames). As explained above (Figure 2c), when the beacon frame sent by the AP is well received by the non-AP station (310), the ERCM Change counter on both sides decreases its value by 1 (initially from CC _n in the Figure). During the procedure, any data frame (thick arrow) sent by the non-AP to the AP has the TA (Transmitter Address) field of the MAC header set to MAC _n which is recognized by the AP. The frame can therefore be processed by the AP.

Different reasons may lead to a non-AP station having its MAC address unsynchronized with the AP. For example, the starting time of the ERCM procedure can be missed by the non-AP station. Also, some beacon frames can be missed or not correctly received by the non-AP station during the transition period. A beacon frame may be lost for the non-AP station due to the bad transmission conditions or if the non-AP station is in power save mode and is not able to receive frames (320). In that case, the ERCM Change counter of the non-AP station does not decrease its value, whereas the ERCM Change counter at the AP does. In the example of the Figure, the non-AP station misses three beacon frames, resulting in having an ERCM Change counter shifted by two compared to the AP.

Finally, the AP applies the new MAC address for the non-AP station when its ERCM Change counter goes to 0. At the same time, the ERCM Change counter is not 0 (but 3 in the example). Therefore, the non-AP station continues decreasing its ERCM Change counter each time a new beacon frame is received. However, before its ERCM Change counter reaches zero (i.e. in a number of TBTTs corresponding to the number of lost beacon frames), the non-AP station still uses its current MAC address MAC _n in all its transmissions, in particular in the TA field of the MAC header of its data frames sent to the AP. Any data frame (thick arrow, 330) sent by the non-AP to the AP during this period of desynchronization has the TA (Transmitter Address) field of the MAC header set to MACn which is not recognized by the AP. The frame is therefore discarded by the AP.

A resynchronization procedure according to the invention may therefore be driven upon detecting such a frame 330, i.e. a frame using an unknown MAC address.

A resynchronization procedure according to embodiments of the invention includes for the AP to send an ERCM resynchronization frame in response to the data frame having an unknown TA MAC address, which ERCM resynchronization frame is addressed to the unknown MAC address, i.e. the non-AP station having sent frame 330. This is to drive the addressee non-AP station to change its current MAC Address MACn into the new MAC Address MAC _n +i in an anticipated manner (compared to the possible time shift of desynchronization). That means the non-AP station receives such ERCM resynchronization frame and responsively changes its current MAC Address into the new MAC Address. Figures 4 and 5 illustrate, using flowcharts, exemplary resynchronization steps at the AP and the non-AP station respectively, according to embodiments of the invention.

One or more ERCM procedure instances have been performed at the AP station and the non-AP station. However, a time shift has appeared between the MAC address change at the non-AP station and the corresponding MAC address change at the AP. The lateness may be few TBTTs or more, such as one or more entire ERCM procedure instances. In this context, the AP has already updated the entry 11 10 of its registry 1100 associated with the non-AP station, with MACn+i, while the non-AP station has not yet changed its current MAC address (which may be MACn, MACn-i or even a previous MAC address) into MAC _n +i, due to loss of beacon frames. Unless the non-AP stations performs such change towards MAC _n +i before the AP changes again the non-AP station’s MAC address into the next value MAC _n +2, the non-AP station is permanently desynchronized with the AP regarding its MAC address.

During this desynchronized period, the non-AP station sends a MAC frame to the AP (such as frame 330) which is received by the AP. This is step 410 starting the resynchronization process. At step 410, the AP checks whether the MAC address in the TA field of the received frame is a known MAC address. This may be done by merely checking whether the MAC address is present in the registry 1100. In the affirmative, conventional processing is performed. In the negative, desynchronization may exist with the transmitting non-AP station.

Several scenarios can occur. The transmitting station may be an associated non-AP station that does not use the appropriate MAC address that is expected by the AP. However, there may be a rogue station that is illegitimate and try to spam each discovered AP to increase the computing load of an AP. The resynchronization process of the present invention seeks to resynchronize the sole legitimate (i.e. associated) non-AP station that is desynchronized, and not the rogue station.

Hence, instead of merely discarding the frame, in embodiments, the AP sends (420) a challenge frame to the transmitting non-AP station, by merely using the unknown MAC address specified in the TA field of the received frame. The challenge frame may be an ERCM Resynchronization Request Action frame 660 as illustrated in Figure 6.

Figure 6 illustrates exemplary frame formats for operating a resynchronization procedure, according to one or several embodiments of the invention. Those frames are action frames in the meaning of IEEE Std 802.11-2020, hence populate the frame body 2200 of a MAC frame 2000.

All frame formats represented in Figure 6 are identified by a ‘Category’ field 651 , 661 , 671 assigned to a specific value k in the range [33,125] as specified in the table 9-51 of the IEEE Std 802.11-2020, so far reserved. For the purpose of illustration, a new category value is defined that is assigned for ERCM action frames. For example, new Category value is set to 33. Of course, any other value in the above range may be used. The value is preferably different from the value used for the action frames of Figure 2b.

The frame formats represented in Figure 6 are identified by the single octet ‘ERCM Action’ field 652, 662, 672, which follows immediately the Category field. The values of the ERCM Action field may be defined as follows: Action field value is set to 1 to signal an ERCM Resynchronization Request Action frame 650, set to 2 to signal an ERCM Resynchronization Response Action frame 660, and set to 3 to signal an ERCM Resynchronization Confirm Action frame 670. In a variant where the same Category value as in Figure 2b is used, the Action field values used for these three ERCM Resynchronization Action frames can be different from values 1 to 3 already used in Figure 2b, hence for example values 4 to 6 respectively.

Each ERCM Resynchronization Action frame further includes an ID field 653, 663, 673 carrying a unique identifier assigned by the AP for a given ERCM resynchronization procedure (i.e. an instance of the process of Figure 4). Hence, the ID value may be assigned by the AP at step 410 when detecting a data frame with a TA field set to an unknown MAC address. The ID value may be incremented by one at each new step 410.

ERCM Resynchronization Response Action frame 660 and ERCM Resynchronization Confirm Action frame 670 further include a HASH Code field 664, 674 as described below.

The Resynchronization ERCM Request action frame 650 may not be encrypted. For the three action frames 650, 660 and 670 the ID field is used to track the resynchronization sequence. The resynchronization ERCM Response 660 and Confirm 670 action frames may have a hash code of the MAC address of the TA field (used to prevent rogue STAs). The HASH code allows the non-AP STA and the AP to match the MAC address with the used PTK. The resynchronization ERCM Response 660 action frame is sent with a new/updated MAC address (TA field).

Back to Figures 4 and 5, the payload 2200 of ERCM Resynchronization Request Action frame 660 may be encrypted using the GTK key. This is a way for the AP to be sure that the receiving non-AP station is a station that was already associated in the past to this AP and thus to avoid spamming rogue stations with bad intentions to be able to identify that specific frame.

The ERCM Resynchronization Request Action frame 660 is received at step 510 by the transmitting non-AP station. It is retrieved from payload 2200 only if the station has the GTK (hence is already associated with the AP).

This ERCM Resynchronization Request Action frame 660 thus indicates to the non-AP STA that its currently-used MAC address is unknown by the AP. The non-AP station therefore sets a local ERCM status to “unsynchronized” (520). The non-AP station may be forbidden to send new frames (except the ERCM Resynchronization Response Action frame 660 described below) to the AP as long as its local ERCM status is not set back to “synchronized”. The non-AP station is therefore restricted to send to the AP only such frames 660.

In response to the received ERCM Request Action frame 660, the non-AP station computes the next MAC address MAC _n +i that is expected using the PRF function. This is step 530. Also, the next value CC _n +2 is calculated.

Next, it sends (540) an ERCM Resynchronization Response Action frame 660 having a Transmitter Address field set to the new MAC address MAC _n +i. The ID field 663 of ERCM Resynchronization Response Action frame 660 is set with the same value as the ID field 653 of the received ERCM Resynchronization Request Action frame 650. In embodiments, the ERCM Resynchronization Response Action frame 660 includes a hash value in HASH Code field 664, that encrypts, using the PTK of the non-AP station, a reference value known by both the AP station and non-AP stations, such as the MAC address in the TA field and/or the value of the ID field 663. HASH Code field 664 allows the AP to verify that the non-AP station is indeed associated with the AP and further confirms, should the AP is able to successfully decrypt the hash value, that the non-AP station has been identified (hence it is synchronized).

Upon receiving (430) the ERCM Resynchronization Response Action frame 660, the AP identifies the ongoing resynchronization sequence thanks to the ID field 663. Note that if no frame 660 is received for the current ID value (e.g. within a predefined time limit), the resynchronization process ends, without successful resynchronization. This may be the case when rogue stations try to overload the AP.

After step 430, the AP can then check (440) whetherthe new MAC address in the received frame is a known EUI value, in which case resynchronization would have been achieved. This may be done by determining whether the new MAC address MAC _n +i in the TA field of the received frame matches an entry 11 10 of the registry 1100 of known MAC address. Furthermore, in case of matching, the AP may retrieve the PTK 1113 associated with the matching entry 1110, then decrypt, using the PTK, the hash value 664 included in the frame, and check whether the decrypted hash value matches the reference value, such as MAC _n +i.

In case the new MAC address is known (output yes at step 440), it means that the non- AP station used the expected MAC address to send to the ERCM Resynchronization Response Action frame 660, hence it is resynchronized. In that case, the AP station sends (450) an ERCM Resynchronization Confirm Action frame 670 with the Receiver Address (RA) field set to the known (recognized) MAC address MAC _n +i.

The ID field 673 of ERCM Resynchronization Confirm Action frame 670 is set with the same value as the ID field 653/663 of the preceding exchanges frames.

Also, the Resynchronization Confirm Action frame 670 may include a hash value encrypting, using the PTK of the non-AP station, a reference value known by both the AP and non-AP stations, e.g. again MAC _n +i or in variant the MAC address of the AP. This confirmation frame thus shows to the non-AP station that the AP has correctly matched MAC _n +i with its PTK.

This ends the resynchronization process at the AP side.

On the other hand, in case the new MAC address does not match an entry 1110 in the registry 11100 of the known MAC addresses (output no at step 440), it means that the non-AP station has not yet resynchronized, possibly because it has more than one ERCM procedure instance late. Therefore, another opportunity to advance one ERCM procedure may be offered to the non-AP station. To do so, the AP station sends a new ERCM Resynchronization Request Action frame 650 with a Receiver Address field set to the unknown new MAC address MAC _n +i, by looping back to step 420. At the non-AP side, the non-AP station either receives an ERCM Resynchronization Confirm Action frame 670 or a new ERCM Resynchronization Request Action frame 650 (test 550).

In case an ERCM Resynchronization Confirm Action frame is received from the AP station in response to the ERCM Resynchronization Response Action frame (output yes at step 550), the non-AP station may abort (i.e. ends) any ongoing ERCM Changing procedure without changing again the value of its MAC address. For example, at step 560, the non-AP station sets its local ERCM status to “synchronized”, meaning the restriction set at step 520 to the non-AP station is released: the non-AP station may thus start again sending any frames to the AP station using the new (and synchronized) MAC address.

In embodiment, initial value CC _n +i calculated for the next ERCM procedure instance is used to initialize the ERCM Change counter of the non-AP station upon reception of the ERCM Resynchronization Confirm Action frame 670. To guarantee that not only the MAC addresses are resynchronized but also the timing of the ERCM Change procedure are fully synchronized between the AP and the non-AP station, the AP has to do the same, although it may have already started decrementing its ERCM Change counter previously initialized with initial value CC _n +i. It is therefore provided in embodiments that the AP station, responsive to sending the ERCM Resynchronization Confirm Action frame, reinitializes again its ERCM Change counter with the same initializing value CC _n +i.

This ends the process at the non-AP side.

On the other hand (output no at step 550), a new ERCM Resynchronization Request Action frame 650 is received from the AP station in response to the ERCM Resynchronization Response Action frame 660 (identifiable thanks to the same values in the ID fields 653 and 663). In response, the non-AP station changes again its current MAC Address MAC _n +i into another new MAC address MAC _n +2 and sends a new ERCM Resynchronization Response Action frame 660 having a Transmitter Address field set to the other new EUI value MAC _n +2, as described above (through looping back to steps 510, 520, 530 and 540).

Note that the loops back to step 420 (at AP side) and to steps 510, 520, 530 and 540 (at non-AP side) allow multiple anticipated generations of next MAC address by the non-AP station with a view of resynchronizing from multiple late ERCM change procedure instances. Indeed, as mentioned above, the non-AP station may be desynchronized by more than a single ERCM Change procedure, e.g. if it misses a lot of beacon frames. Hence, each time a new ERCM Resynchronization Response Action frame 660 is received by the AP from the non-AP station with a Transmitter Address field set to a new MAC address that does not match an entry in the registry, the AP sends a new ERCM Resynchronization Request Action frame with a Receiver Address field set to the unknown new MAC address, to cause the non-AP station to change again its current MAC address into the next MAC address according to the shared chained calculation of MAC addresses. Corresponding, each time a new ERCM Resynchronization Request Action frame 650 is received by the non-AP station from the AP station in response to a sent ERCM Resynchronization Response Action frame, the non-AP station changes its current MAC address into the next MAC address according to the shared chained calculation and sends a new ERCM Resynchronization Response Action frame having a Transmitter Address field set to said next MAC address.

There may be a need to avoid infinite iterations of the above loops which may for instance occur with spamming stations. It may thus be worth having both AP and non-AP stations driving an internal counter associated with the ID of the resynchronization sequence to set a maximum limit to the number of trials an ERCM Resynchronizatoin Request Action frame can be sent to the same non-AP STA.

This may be done at the AP with step 460 following output “no” at test 440, to check whether this maximum limit of the counter (initialized to 1 at step 410) has been reached.

In the affirmative, the process ends. Hence the AP station no longer sends a new ERCM Resynchronization Request Action 650 frame to the non-AP station upon failing to identify a new MAC address in the registry, after a predefined number of such frames sent to the non-AP station and corresponding ERCM Resynchronization Response Action frames received from the non-AP station.

In the negative, the internal counter is incremented at step 470 before looping back to step 420.

At the non-AP station, this may be done with step 570 following output “no” at test 550, to check whether this maximum limit of the counter (initialized to 1 upon receiving the first frame 650 with a new ID) has been reached.

In the affirmative, the process ends; it is considered the non-AP station cannot be resynchronized. In embodiments, the non-AP stations triggers a reassociation procedure (580) with the AP station in this case. A reassociation procedure is well known from the 802.11 standards and is therefore not described with more details.

In the negative, the internal counter is incremented at step 590 before looping back to step 510.

The embodiments described above mainly lie on exchanges of various ERCM Resynchronization Action frames 650, 660, 670. In alternative embodiments of the invention, a single ERCM Resynchronizatoin Action frame may be exchanged to reduce overhead. This is illustrated by Figures 4a and 5a which illustrate, using flowcharts, exemplary resynchronization steps at the AP and the non-AP station respectively, according to other embodiments of the invention.

In these embodiments, the AP can try to resynchronize the non-AP station with an unknown MAC address by searching the correct MAC address that should be used by the non- AP station. Determination of which non-AP station is concerned may be made using the payload 2200 of the frames that is encrypted using the PTK of the non-AP station. Hence, successively decrypting the payload may allow the AP to retrieve the MAC address of the non-AP station using its registry. The process starts at step 410’ similar to step 410. The MAC address of the TA field is unknown.

However, at step 420’, the AP applies a brute force search of the correct PTK form amongst all the entries 1110 of its registry 1100. For instance, the AP may traverse the entries of the registry of known MAC addresses, and for each entry traversed: retrieve the PTK 1113 associated with the entry 11 10, decrypt, using the PTK, the frame body 2200 of the received data frame, and determine whether the decrypting frame body matches a reference frame format. For example, the AP may search for known formats such as an A-MSDU (Aggregate MAC Service Data Unit) format or a TCP header format.

Should such a format being successfully identified (meaning the payload 2200 has been successfully decrypted), the AP retrieves the corresponding MAC address MAC _n +i (associated with the PTK used in the same entry 1110) and provides the MAC address MAC _n +i within an ERCM resynchronization frame sent to the non-AP station. This is step 430’.

An ERCM Resynchronization Confirm Action frame 670 is preferably used to this end. ID field 673 is set to a new ID value. HASH code field 674 is used to convey the MAC address MACn+i preferably in an encrypted form (using the PTK).

Optionally, the associated initial value CC _n +i for the ERCM Change counter is also included in frame 670, e.g. together with MAC _n +i in the hash value or in a separate field.

The Transmitter Address (TA field of the MAC header) of frame 470 is set to the MAC address of the AP and the Receiver Address (RA field of the MAC header) is set to the unknown MAC address of the data frame received at step 410’.

Upon receiving (510’) this ERCM Resynchronization Confirm Action frame 670, the non- AP station decrypts (520’), using its own PTK, the hash value contained in HASH Code field 674 to obtain MAC _n +i and possibly CC _n +i. The non-AP station next modifies (530’) its currently used MAC address with this new MAC address MAC _n +i decrypted from the HASH Code field.

In some embodiments, the process ends here. As forthe embodiments above, initial value CCn+i obtained from the decrypting of the HASH Code field 674 is used by the non-AP station to initialize its ERCM Change counter upon reception of the ERCM Resynchronization Confirm Action frame 670. To guarantee that not only the MAC addresses are resynchronized but also the timing of the ERCM Change procedure are fully synchronized between the AP and the non-AP station, the AP has to do the same, although it may have already started decrementing its ERCM Change counter previously initialized with initial value CC _n +i. It is therefore provided in embodiments that the AP station, responsive to sending the ERCM Resynchronization Confirm Action frame 670, reinitializes again its ERCM Change counter with the same initializing value CCn+1.

In other embodiments that continue the process, step 530’ may then optionally commute to step 540 where the non-AP station sends an ERCM Resynchronization Response Action frame 660 based on the received MAC _n +i. The next steps of Figure 5 are then performed. This ensures a confirmation with MAC _n +i (as TA field) is exchanged. Correspondingly, step 430’ optionally commutes to step 430 of Figure 4 for the AP to perform the corresponding steps.

Although the embodiments of Figures 4 and 5 on one hand and of Figures 4a and 5a on the other hand describe separate processing of the initial data frame, they can be combined together.

For example, the AP may first search for a known format in the decrypted payload 2200 (step 420’).

If a known format is found, step 430’ is performed as well as steps 510’-530’ at the non- AP station (hence the second resynchronization mechanism is implemented).

If no known format can be found, the AP may switch to the first resynchronization mechanism, meaning that it sends an ERCM Resynchronization Request Action frame 650 at step 420. Steps 430-470 at the AP and steps 510-590 at the non-AP station are then performed.

Figure 7 schematically illustrates an exemplary sequence of resynchronization the non- AP station with the AP using the second resynchronization mechanism.

When a data frame 330 sent by the non-AP station to the AP is not recognized by the AP due to an unknown MAC address MAC _n , the AP retrieves the MAC address MAC _n +i corresponding to the PTK used to encrypt its payload 2200. Next, the AP sends ERCM Resynchronization Confirm Action frame 670 with RA field set to the unknown MAC address, the ID field 673 set to a new ID value and the HASH Code field 674 filled in with an encrypted version of the retrieved MAC address MAC _n +i and optionally the associated initial value CC _n +i for the ERCM Change counter.

Upon reception of this frame, the non-AP station decrypts the hash value and retrieves MACn+i and CC _n +i. It then modifies its current MAC address with MAC _n +i.

Optionally, to confirm the change, the non-AP station sends an ERCM Resynchronization Response Action frame 660 with TA field set to current MAC address MAC _n +i, the ID field 663 set to the ID value of frame 670 and the HASH Code field 664 filled in with an encrypted version (using the PTK) of MAC _n +i.

The AP may then respond with another ERCM Resynchronization Confirm Action frame 670 with RA field set to MAC _n +i, the ID field 673 set to the same ID value and the HASH Code field 674 filled in with an encrypted version of MAC _n +i and optionally the associated initial value CCn+i for the ERCM Change counter.

Figure 7a schematically illustrates an exemplary sequence of resynchronization the non- AP station with the AP using the first resynchronization mechanism.

When a data frame 330 sent by the non-AP station to the AP is not recognized by the AP due to an unknown MAC address MAC _n , the AP sends a “challenge” to the non-AP station, in particular ERCM Resynchronization Request Action frame 650 with RA field set to the unknown MAC address, the ID field 673 set to a new ID value. This triggers at the receiving non-AP station the generation of the next MAC address, namely MAC _n +i, which is used to modify the current MAC address MAC _n into this new value MACn+1.

The non-AP station informs the AP of such new MAC address through the sending of ERCM Resynchronization Response Action frame 660 with TA field set to the new MAC address MACn+i, with the ID field 663 set to the received ID and with the HASH Code field 664 filled in with an encrypted version (using the PTK) of MAC _n +i.

The AP confirms the new MAC address by sending ERCM Resynchronization Confirm Action frame 670 with RA field set to MAC _n +i, the ID field 673 set to the same ID value and the HASH Code field 674 filled in with an encrypted version of MAC _n +i or of the AP’s MAC address.

As described above, embodiments of the invention describe a method to resynchronize the OTA MAC address of an associated STA while the OTA MAC address is changed using a standard pseudo random generator based on shared private information. This method ensures privacy during the resynchronization process.

The principles of a resynchronization procedure of the OTA MAC address for a non-AP STA as described above include the following operations:

- Detection that a non-AP STA is potentially unsynchronized when the AP receives a frame with unknown TA MAC Address and RA MAC Address set to the one of the AP;

- The AP sends a “challenge” frame to the unknown non-AP STA requesting to modify its MAC address (resynchronization Request Action frame). The resynchronization Request Action frame may be built considering the following: request the STA to use the next MAC Address (for instance: +1 run with the PRF-128/46). The frame has TA set to the MAC Address of the AP and RA set to the unknown MAC Address. It further adds an ID request field.

- In response, the unknown non-AP STA updates its MAC address and sends a resynchronization response Action frame by using the new MAC address. For example, the STA sends a resynchronized Response Action frame (only if the STA is ERCM capable) considering the following: the STA updates its outdated MAC Address with the next MAC Address (+1 run with the PRF-128/46). The frame has TA set to the next MAC Address of the STA and RA set to the MAC Address of the AP. It further adds a HASH code based on the PTK previously agreed with the AP and add the ID request field.

- If the AP recognizes the new MAC address of the non-AP STA, the AP sends a resynchronization Confirm Action frame to acknowledge the resynchronization of the non-AP STA The AP may send a resynchronized Confirm Action frame with a hash code (PTK) to validate the re-synchronization of the non-AP STA. However, if the MAC Address is not the MAC address expected by the AP, the AP can restart the process by sending another “challenge” frame. After several trials (tracked with the ID field), the AP can stop sending challenges.

Among the benefits of the described method, the following may be listed:

- resynchronizing non-AP STAs implementing ERCM mechanisms;

- the user privacy is ensured during the resynchronization procedure; - protected mechanism against MAC address spammer attacks from rogue non-AP ST As and rogue APs;

- allows a non-AP STA not to relaunch an association process.

Figure 8 schematically illustrates a communication device 800, typically any of the stations of Figure 1 , of a wireless network, configured to implement at least one embodiment of the present invention. The communication device 800 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 800 may comprise a communication bus 805 to which may be connected:

- a central processing unit 801 , such as a processor, denoted CPU;

- a memory 803, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and

- at least two communication interfaces 802 and 802’ connected to the wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 804 and 804’, respectively.

Preferably the communication bus 805 may provide communication and interoperability between the various elements included in the communication device 800 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 800 directly or by means of another element of the communication device 800.

The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 802 or 802’, in order to be stored in the memory 803 of the communication device 800 before being executed.

In an embodiment, the device 800 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Embodiment(s) of the present invention can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non- transitory computer-readable storage medium”) to perform the functions of one or more of the above-described embodiments) and/or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the abovedescribed embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiment(s) and/or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), etc.), a flash memory device, a memory card, and the like. Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the invention.