GB2614562A - Method for changing a value of an extended unique identifier of a non-AP station associated with an AP station - Google Patents

Abstract

A method for changing an Extended Unique Identifier (EUI), e.g. a media access control address (MAC address), of a non-access point (non-AP) station. The non-AP station is associated with an access point (AP) station, both having a shared function to generate the new EUI and a shared parameter having a value varying over time. The method comprises (at the non-AP station or AP station) obtaining a key shared with the other station, communicating a request for changing the EUI along with an indication of the time at which the EUI will be changed; calculating the new EUI using the shared key and a current value of the shared parameter (e.g. current time, current EUI) as inputs of the shared function and replacing the current EUI with the new EUI at the indicated time. The shared key may be generated pseudo-randomly and the shared function may be a pseudorandom function (PRF). The request for changing the EUI may be sent as a beacon frame by the AP station. Also provided are a wireless communication device and computer program product for carrying out the method.

Description

Intellectual Property Office Application No G132200177.0 RTM Date:9 June 2022 The following terms are registered trade marks and should be read as such wherever they occur in this document: - Wi-Fi

- IEEE

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

METHOD FOR CHANGING A VALUE OF AN EXTENDED UNIQUE IDENTIFIER OF A NON-AP STATION ASSOCIATED WITH AN AP STATION

FIELD OF THE INVENTION

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

BACKGROUND OF THE 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 o 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, is 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 of a user device 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.11aq 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 802cTm-2017.

More specifically, a new Management Information Base (MIB) variable controllable by an external management entity has been specified. This variable is called 'clod 1MACPrivacyActivated. When dot11MACPrivacyActivated is set to "true", the non-AP station can apply specific mechanisms for enhancing the privacy at MAC level, including RCM.

The MAC address, or EU1-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 "I/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 mulficast transmission). 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 I/G bit is set to 0, and the remaining 46 bits are randomly generated by using a pseudorandom function (PRF). When the RCM is operated, counters in all sequence number spaces used to identify data frame (MAC service data unit, MSDU, packet or Management MAC Protocol Data Unit, MMPDU, frame) has to be reset and the non-AP station also resets seeds used within the PHY DATA scrambler on the next physical layer protocol data unit, PPDU, to be transmitted.

However, according to the actual standards and the existing mechanism, a non-AP station cannot change its MAC address as soon as it is associated with an access point (AP). Therefore, when the non-AP station is associated with an AP, the security issues mentioned above arise: the privacy is not ensured as various behaviors or actions of the non-AP station within the Basic Service Set (BSS) of the AP can still be tracked and reconciled.

There is thus a need for a method for enabling a non-AP station to apply a Randomized and Changing MAC procedure when it is associated with an access point. Such method may be referred to as "Enhanced RCM" (ERCM) in the following.

SUMMARY OF THE INVENTION

It is provided a method for changing a value of an Extended Unique Identifier, EUI, of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both having a shared function to generate the new value of the EUI and a shared parameter having a value varying over time, the method comprising at the non-AP station or at the AP station: obtaining a key shared with the other station; communicating, with the other station, a request for changing the value of the EUI and an indication relative to a time at which the value of the EUI is to be changed; calculating the new value of the EUI by using the shared key and a current value of the shared parameter as inputs of the shared function; replacing a value of the EUI by the calculated new value of the EUI at the indicated time at which the value of the EUI is to be changed.

As known by the person skilled in the art, a EUI is a unique identifier assigned to the network interface controller of a device for use as a network address during wireless communications, for instance according to IEEE 802 networking technologies. Typically, a EUI may comprise 48 bits (EUI-48, also called MAC address) or 64 bits (EU1-64).

By "shared parameter having a value varying over time", it is meant a parameter whose value is known by both the non-AP station and the AP station, wherein the zo value of the parameter may be different at two different time. For instance, said parameter may be a time, a date, a counter, a EUI of the non-AP station (since, in the context of the present invention, the value of the EUI of the non-AP station can be changed, and therefore varies over time). By "current value of the shared parameter' it is meant the value of the parameter at the time at which the new value of the EUI is calculated.

The shared key is known by both the AP station and the non-AP station. Its value can be dedicated to the non-AP station (i.e. two non-AP stations have two distinct shared keys), or the same for a subgroup of non-AP stations associated with the AP station or to all the non-AP stations associated with the AP station.

According to the above method, the EUI of the non-AP station may be changed even when the non-AP station is associated with an AP station. User privacy is therefore increased. Both the AP station and the non-AP station can calculate a same value of the new EUI and use it from the same moment, which allows them to be able to communicate with each other without interruption (avoiding that the value EUI is changed on one side but not on the other). The user privacy is now ensured also when the non-AP STA is associated.

In one or several embodiments, the method may be performed at the non-AP station, and the obtaining of the key shared with the AP station may comprise, at the non-AP station: receiving, from the AP station, a request for obtaining the shared key; upon reception of the request for obtaining the shared key, generating the shared key; and sending the generated shared key to the AP station According to these embodiments, the shared key may be dedicated to the non-AP station which has to change the value of its EUI, and none of the other non-AP stations of the BSS has access to the key. Therefore, none of the other non-AP stations of the BSS can calculate the EUI of the non-AP station whose EUI value must be changed. The security is therefore increased.

It is noted that the sending of the shared key by the non-AP station to the AP station is performed after their association, and therefore in an encrypted manner.

Thus, a third party who would intercept the message containing the key could not use it.

In addition, the shared key may be generated pseudorandomly. The security is therefore increased, since its value cannot be inferred by a third party.

Symmetrically, when the method is performed at the AP station, and the obtaining of the key shared with the non-AP station may comprise, at the AP station: sending, to the non-AP station, a request for obtaining the shared key; and in response to the request for obtaining the shared key, receiving the shared key from the non-AP station.

In one or several embodiments, the shared function may be a pseudorandom function, PRF. Therefore, the new value of the EUI is generated pseudorandomly, and it cannot be inferred by a third party, which increases security and privacy. In addition, a pseudorandom function already exists according to the standard. Therefore, no new function is needed to implement the method for changing the EUI of the non-AP station.

In one or several embodiment, the current value of the shared parameter may be a current value of the EUI. By "current value of the EUI", it is meant the value of the EUI at the time the new value is calculated, i.e. the value of the EUI before the changing.

Alternatively, the current value of the shared parameter may be a current time to value. By "current time", it is meant for example a time read from a clock at which the new value is generated. In these embodiments, the value of the current time may be rounded (e.g. to the nearest second, to the nearest tenth of a second, etc.) to ensure the value is the same at the AP station and at the non-AP station. Also, these embodiments require to define at which time the new value is calculated by both the AP station and the non-AP station (e.g., when the request for changing is sent/received, or when the change has to be applied, etc.).

In one or several embodiments, the non-AP station or AP station may store a registry comprising the value of the EUI of the non-AP station, and the replacing of the value of the EUI by the calculated new value of the EUI may comprise: replacing the value of the EUI of the non-AP station in the registry by the calculated new value.

In other words, at the time at which the change is to be applied, the registry of the AP station and the registry of the non-AP station may be updated with the new value. After this update, all data transmissions between the AP stations and the non-AP are done with the new value of the EUI.

In one or several embodiments, the EUI of the non-AP station may be a MAC address of the non-AP station, i.e. a EUI-48.

In one or several embodiments, the request for changing the value of the EUI may be sent by the AP station and received by the non-AP station. The request may be specific to one non-AP station (in this case, only the EUI of the concerned non-AP station is changed), or it may be sent to all the non-AP stations associated with the AP and supporting a EUI-changing procedure (in this case, all the EUls of the non-AP stations are changed at the same time).

For example, the request for changing the value of the EUI may be a beacon frame. In this case, the request is sent to all the non-AP stations associated with the AP and supporting a EUI-changing procedure.

In addition, the indication relative to the time at which the value of the EUI is to be changed may be a counter included in the beacon frame, said counter indicating a number of Target Beacon Transmission Times, TBTTs.

Furthermore, after the request for changing the value of the EUI, a plurality of subsequent beacon frames may be sent by the AP station and received by the non-AP station, each subsequent beacon frame including a respective value of the counter, the value of the counter being decremented by one for each subsequent beacon frame; and the time at which the value of the EUI is to be changed may be a time at which the beacon frame with a value of the counter equal to zero is sent from the AP station and received by the non-AP station.

Alternatively, the request for changing the value of the EUI may be sent by the non-AP station and received by the AP station.

In one or more embodiments, the indication relative to a time at which the value of the EUI is to be changed may be included in the request for changing the value of the EUI.

For example, the indication relative to the time at which the value of the EUI is to be changed may be a number k of Target Beacon Transmission Times, TBTTs, in which the value of the EUI is to be changed. In this case, the value of the EUI may be changed when a k-th beacon frame since the communicating of the request is sent from the AP station or received by the non-AP station.

Alternatively, the indication relative to a time at which the value of the EUI is to be changed may be a time value. In this case, the value of the EUI may be changed when a beacon frame corresponding to a first beacon frame after the time value is reached is sent from the AP station or received by the non-AP station.

In one or more embodiments, capabilities for implementing a procedure for changing the value of the EUI may have been exchanged during association between the non-AP station and the AP station. Therefore, each non-AP station declares if it supports the EUI-changing procedure (or ERCM procedure) and knows whether the AP station supports the EUI-changing procedure.

Another aspect of the invention relates to a wireless communication device comprising at least one microprocessor configured for carrying out the steps of the above method.

Yet another aspect of the invention relates to a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing the above method, when loaded into and executed by the programmable apparatus

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 2 is an example of a flow chart describing a method for changing a MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention; - Figures 3a and 3b illustrate steps performed at a non-AP station for changing its MAC address, according to one or several embodiments of the invention; - Figures 4a and 4b illustrate steps performed at an AP for changing the MAC address of a non-AP station with which it is associated, according to one or several embodiments of the invention; -Figure 5 illustrates an example of a frame format to advertise the capability of a station to support a MAC address change procedure, according to one or several embodiments of the invention; -Figure 6 illustrates an example of a sequence of steps for activating a procedure for changing the MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention; -Figures 7a and 7b illustrates examples of sequence of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention; -Figure 8 illustrates examples frame formats to activate and operate a MAC address change procedure, according to one or several embodiments of the invention; -Figure 9 illustrates an example of a frame format for operating a MAC address change procedure initiated by an AP, according to one or several embodiments of the invention; -Figure 10 illustrates an example of a communication device of a wireless network, configured to implement at least one embodiment of the present invention.

DESCRIPTION OF SOME EMBODIMENTS

According to embodiments, the invention proposes to change the MAC address of a non-AP station, when this non-AP station is associated with an AP (or "AP station"). In order for the AP and the non-AP station to be able to continue exchanging data, the new MAC address of the non-AP station must be known by both the AP and the non-AP station. For this, the invention provides 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 register with all the MAC addresses of the non-AP stations associated with it, updates the register with the new MAC address of the concerned non-AP station. Also, the AP and the non-AP station must 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. Therefore, the present invention proposes mechanisms to ensure that the updating of the MAC address is done in a synchronized manner at the AP and at the non-AP station.

In one or more embodiments, the invention therefore relates to a method to change the public MAC Address of an associated STA using a standard pseudo random generator based on shared private information. The change can be at the AP STA or non-AP STA initiative. This method makes correlation between a MAC address and a given STA very difficult for non registered STA.

In the following, the procedure for changing the MAC address of a non-AP station already associated with an AP is referred to as "Enhanced RCM procedure", or 5 ERCM procedure.

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 (ails), such as EU1-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 not (so-called non-AP station or non-AP STA).

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 stations (non-AP STAs) 120a, 120b, 120c. Of course, the number of non-AP stations 120a, 120b, 120c may be different from three. The AP 110 provides wireless connections between the non-AP stations 120a, 120b, 120c and a wider network, such as the Internet. The connection of a non-AP station120a, 120b, 120c to the AP 110 is performed by a standardized process called association. Once a non-AP station 120a, 120b, 120c is associated with the AP 110, the non-AP station 120a, 120b, 120c can send data to the network and receive data from the network through the AP 110.

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 station 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 station 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 station 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 station 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 110.

Figure 2 is an example of a flow chart describing a method for changing a MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention. It represents an Enhanced RCM (ERCM) procedure allowing the dynamic change of the MAC address of a non-AP STA when it is associated with an AP. As detailed below, after association, encrypted information (ERCM key) is shared between AP and non-AP STA. Then, upon AP or non-AP STA request, both AP and non-AP STA compute a new transient MAC address for the changing STA, without sharing it, by using same pseudo random generator with same parameters. Then, at the request for changing the MAC address of the non-AP station initiated by the AP or the non-AP STA, both AP and non-AP STA apply the MAC address change for the changing STA.

In one or more embodiments, both the non-AP station and the AP may be configured with a dot11MACPrivacyActivated set to true, as it is the case for the non-AP station (only) in the standardized RCM mechanism.

At a first step 200, the non-AP station associates with the AP according to protocols defined in IEEE 802.11 standards. During the association (step 200), the non-AP station and the AP declare their capabilities, in particular their capabilities to implement a mechanism for changing the MAC address of the non-AP station, when it is associated with an AP ("ERCM capability"). For example, the ERCM capability may be signaled by using a frame format 500 as described with reference to Figure 5. It is noted that from the moment the non-AP station and the AP are associated, communications between them are secured.

Then, a key, referred to as "ERCM key", is obtained at both the non-AP station and the AP (step 210). The ERCM key is a key known by the non-AP station and the AP, which is used to calculate the new MAC address of the non-AP station.

In one or more embodiments, the ERCM key may be a key obtained during the authentication and association procedures between the non-AP station and the AP.

For example, after a successful authentication, the non-AP station and the AP have a shared key called Pairwise Master Key (PMK), which is common to all the non-AP stations of the BSS. After authentication, a 4-Way handshake is performed, during which a key specific to each non-AP station is derived from the PMK, called Pairwise Transient Key (PTK), which is the key to be used for ciphering communications between the non-AP station and the AP. In one or several embodiments, the PMK may be used as ERCM key.

In alternative embodiments, 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 the above 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 these embodiments, steps 200 and 210 can be carried out in either order.

In other embodiments, the ERCM key may be generated at the non-AP station and transmitted to the AP, as in steps 630,640 and 650 of Figure 6. Since the ERCM key is exchanged between the non-AP station and the AP, the communications between these entities must be secured. Therefore, in these embodiments, step 210 must be performed after step 200.

Of course, other embodiments are possible for step 210, as long as both the non-AP station and the AP obtain the same key.

In steps 200 and 210, it is assumed that the MAC address of the non-AP station has a first value, known (and stored) by both the non-AP station and the AP.

At step 220, a request for changing the MAC address of the non-AP station is exchanged between the non-AP station and the AP. As detailed below, this request may be sent by the non-AP to the AP, or by the AP to the non-AP station. To ensure that both the non-AP station and the AP start using the new MAC address at the same time (and thus avoid problems with frames sent, whose MAC address field does not correspond to the current MAC address of the non-AP station), this request may contain an indication relative to a time after which the new MAC address must be used. Examples of such indication are provided with reference to Figures 7a and 7b. In the following, the time at which the new MAC address must be used is referred to as "ERCM Date" or "ERCM Change Date".

Alternatively, the indication relative to a time after which the new MAC address must be used may not be included in the request, and may be obtained by other means. For example, it may be decided that the MAC address of the non-AP station is changed periodically and the next time at which the MAC address is to be changed corresponds to the next instant of the periodical time sequence.

The new MAC address is then calculated in parallel by both the non-AP station and the AP. From the moment the ERCM change Date is reached, the new calculated MAC address is used for communications between the non-AP station and the AP (step 230).

As mentioned above, there is a synchronous change of the MAC address. At the request for changing the MAC address of the non-AP station initiated by the AP or the non-AP STA, both AP and non-AP STA apply the MAC address change for the changing STA. In case of AP initiation, ERCM is intended to all the non-AP stations ERCM-capable. ERCM procedure may make use of a new ERCM IE to be included in the beacon frame including an ERCM Change counter corresponding to the number of TBTTs until the next transient MAC address is effective, as detailed below with reference to Figure 9. In case of non-AP initiation, ERCM procedure may make use of a new action frame including an ERCM Change date corresponding to the number of TBTTs until the next transient MAC address is effective, as detailed below with reference to Figure 8.

It is noted that the new MAC address may be calculated at any time between steps 220 and 230, or even at the same time as step 230, when the change is operated (i.e. when the new calculated MAC address becomes the address of the non-AP station).

To calculate the new MAC address of the non-AP station, a procedure similar to that currently used for the standardized RCM mechanism may be applied. More specifically, the U/L bit of the new MAC address is set to 1, the I/G bit is set to 0, and the remaining 46 bits are randomly generated. For instance, the remaining 46 bits can be generated by using the pseudorandom function (PRF) specified in the section zo 12.7.1.2 of the standard IEEE Std 802.11-2020 and defined as follows: PRF(K, A, B, Len) for i 0 to do R R II H-SHA-1(K, A, B, i) return L(R, 0, Len) where Len is the number of bits (128, 192, 256, ...).

More specifically, the PRF-128 (i.e. PRF(K, A, B, 128)), which generates 128 pseudorandom bits, may be used. From the generated 128 bits, the leftmost 46 bits (i.e. the 46 most significant bits) may be selected. This function is referred to as PRF128/46.

The PRF function of the standard is based on 3 input parameters, denoted K, A and B. 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. To calculate the new MAC address, both the non-AP station and the AP apply the same PRF function to the same input parameters, to therefore obtain a same output result, which constitutes the new MAC address of the non-AP station. The input parameters used for this computation may be as follows: K is set to the ERCM key obtained at step 210 and A is set to "ERCM" to indicate that the PRF is used for calculating a new MAC address in the context of an ERCM mechanism. B may set to any value known by both the non-AP station and the AP, and changing over time. For example, B may be the current MAC address of the non-AP station, an actual current time On this case, the current time may be rounded, for example to the nearest tenth of second or to the nearest second, to avoid problems due to an imperfect synchronization between the clocks of the non-AP station and of the AP), etc. Examples and embodiments are detailed below.

It is noted that, according to different embodiments of the invention, the above method may be applied to only one non-AP station of a BSS, or to a subgroup of non-AP stations (each AP-(non-AP station) couple applying in parallel the changing method), or to all non-AP stations of the BSS.

Figures 3a and 3b illustrate steps performed at a non-AP station for changing its zo MAC address, according to one or several embodiments of the invention.

More specifically, Figure 3a illustrates steps performed at a non-AP station for changing its MAC address at its own request, and Figure 3b illustrates steps performed at a non-AP station for changing its MAC address at the request of the AP. It is noted that these embodiments are not mutually exclusive and can coexist in the same non-AP station. For example, the AP may be configured to indicate at certain times (for example periodically) to the non-AP station that the latter has to change its MAC address, while the non-AP station may be configured to indicate at other times corresponding to particular events (for example, when the non-AP station stays still for a predefined time or sends the same type of traffic for a predefined time) that it wants to change its MAC address.

It is noted that steps 300, 310, 320 (Figure 3a) or 325 (Figure 3b) and 330 are parts of steps 200, 210, 220 and 230 of Figure 2, respectively, performed by the non-AP station.

With reference to Figure 3a and Figure 3b, the non-AP station first associates with the AP (step 300). During the association (step 300), the non-AP station and the AP declare their capabilities, in particular their capabilities to implement a mechanism for changing the MAC address of the non-AP station, when it is associated with an AP ("ERCM capability"). For example, the ERCM capability may be declared by using a frame format 500 as described below with reference to Figure 5.

Then, the "ERCM key" may be obtained by the non-AP station (step 310) as detailed above with reference to Figure 2.

In embodiments represented in Figure 3a, a request for changing the MAC address of the non-AP station is received by the non-AP station (step 320), for example from the AP (as an alternative, the request may be sent from a third device of the network to both the non-AP station and the AP). In embodiments represented in Figure 3b, the request for changing the MAC address of the non-AP station is sent from the non-AP station (step 325), for example to the AP (as an alternative, the request may be sent to a third device of the network, which transmits it to the AP). In one or more embodiments, the request may comprise an indication relative to the ERCM change Date, i.e. the date at which the change must be applied by both the non-AP station and the AP. Alternatively, the ERCM change Date may be obtained at the non-AP station and at the AP by other means, for example from a third-party device, or according to a predefined list of times (periodic or not) at which the MAC address must be changed.

The new MAC address is then calculated by the non-AP station and the change is operated at the ERCM change Date (step 330), as explained above with reference to Figure 2. It is noted that the new MAC address may be calculated at the ERCM change Date (i.e. at step 330) or before (e.g. between steps 320/325 and 330, or even before 320/325). However, the effective change is performed when the ERCM date is reached.

Figures 4a and 4b illustrate steps performed at an AP for changing the MAC address of a non-AP station with which it is associated, according to one or several embodiments of the invention.

More specifically, Figure 4a illustrates steps performed at the AP for changing the MAC address of a non-AP station associated with the AP, at the request of the non-AP station (or, alternatively, of a third device of the network). Figure 4b illustrates steps performed at the AP for changing the MAC address of a non-AP station associated with the AP, at its own request. By "changing the MAC address of a non-AP station associated with the AP", it is meant that the AP calculates a new value and stores as new MAC address of the non-AP station the calculated value. As soon as the ERCM date is reached, this new MAC address becomes the one used in the exchanges of frames between the AP and the non-AP station.

Steps of Figures 4a and 4b respectively correspond to steps of Figures 3a and 3b, at the AP's side. It is noted that steps 400, 410, 420 (Figure 4a) or 425 (Figure 4b) and 430 are parts of steps 200, 210, 220 and 230 of Figure 2, respectively, performed by the AP.

With reference to Figure 4a and Figure 4b, the AP first associates with the non-AP station (step 400). During the association (step 400), the non-AP station and the AP exchange messages to signal to each other their capabilities, in particular their capabilities to implement a mechanism for changing the MAC address of the non-AP station, when it is associated with an AP ("ERCM capability"). For example, the ERCM capability may be declared by using a frame format 500 as described with reference to Figure 5.

Then, the "ERCM key" is obtained by the AP (step 410) as detailed above with reference to Figure 2.

In embodiments represented in Figure 4a, a request for changing the MAC address of the non-AP station is sent by the AP (step 420), for example to the non-AP station (as an alternative, the request may be sent to a third device of the network, which transmits it to the non-AP). In embodiments represented in Figure 4b, the request for changing the MAC address of the non-AP station is received at the AP (step 425), for example from the non-AP station. In alternatives, the request may be sent from a third device of the network to both the non-AP station and the AP, or it may be sent from the non-AP station to a third device which transmits it to the AP.

In one or more embodiments, the request may comprise an indication relative to the ERCM change Date, i.e. the date at which the change must be applied by both the non-AP station and the AP. Alternatively, the ERCM change Date may be obtained at the non-AP station and at the AP by other means, for example from a third-party device, or according to a predefined list of times (periodic or not) at which the MAC address must be changed.

The new MAC address is then calculated by the non-AP station and the change is operated at the ERCM date (step 430), as explained above with reference to Figure 2. It is noted that the new MAC address may be calculated at the ERCM date (i.e. at step 430) or before (e.g. between steps 420/425 and 430, or even before 420/425). However, the effective change is performed when the ERCM date is reached.

Figure 5 illustrates an example of a frame format to advertise the capability of a station to support a MAC address change procedure, according to one or several embodiments of the invention. An ERCM Capability field is used in the STA and AP to advertise their capability to support ERCM.

In one or more embodiments, the capability for a station (non-AP station and AP) to support ERCM procedure may be signalled during association in an Extended Capabilities Information Element (1E) 500 as defined in the section 9.4.2.26 of the standard IEEE Std 802.11-2020.

As represented in Figure 5, the Extended Capabilities IE 500 contains three fields: an Element ID field 510, a length field 520 and an Extended Capabilities field 530. The Element ID field 510 is set to value '127' corresponding to 'Extended Capabilities' extended. The length field 520 indicates the number of octets in the Extended Capabilities field 530 excluding the Element ID field 510 and the length field 520. For illustrative purpose, it may be set to n=16 octets. The Extended Capabilities field 530 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 standard may be assigned to the ERCM capability, to indicate that the station supports ERCM procedure. It may correspond to the k-th bit of the Extended Capabilities field 530, k being an integer between 88 and 8"n, n being the length of the Extended Capabilities field 530 expressed in number of bytes. When this bit is set to 1, it may indicate that the station supports ERCM procedure, and when this bit is set to 0, it may indicate that ERCM is not supported by the station.

A new row may be added to Table 9-153 -Extended Capabilities field, Clause 9.4.2.26 of the standard IEEE Std 802.11-2020 Insert new row in Table 9-153-Extended Capabilities field, Clause 9.4.2.26 Bit Information Notes k Enhanced RCM Capability The STA sets Enhanced RCM Capabilities bit to 1 to indicate support for Enhanced RCM and sets to 0 if Enhanced RCM is not supported.

As represented in Figure 6, in one or several embodiments, after association, encrypted information (ERCM key) is shared between AP and non-AP via specific action frames.

Figure 6 illustrates an example of a sequence of steps for activating a procedure for changing the MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention.

First, the non-AP station 120 may send a probe request (step 610) for initiating an association procedure with the AP 110. The probe request may contain an Extended Capabilities IE 500 as defined above with reference to Figure 5, for which the k-th bit of the Extended capabilities field 530, corresponding to the ERCM Capability, is set to 1 ("ERCM cap = 1" in Figure 6) Next, AP 110 may send a probe response (step 620) to non-AP station 120 in response to the probe request. The probe response may also contain an Extended Capabilities IE 500 for which the k-th bit of the Extended capabilities field 530, corresponding to the ERCM Capability, is set to 1.

As both AP 110 and non-AP station 120 support ERCM, an ERCM procedure may be initiated. The ERCM initiation is performed after the association procedure and the establishment of the security context, so as the payload of the transmitted frames is encrypted.

In one or more embodiments, the ERCM procedure may be initiated by the AP 110. In such embodiments, the AP 110 may transmit (step 630) 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" 810 as detailed below with reference to Figure 8.

At the reception of the ERCM Key delivery Request, the non-AP station 120 may generate a key, for instance on 256 bits, called ERCM key. This key is intended to be used for generating the next MAC address of the non-AP station 120 at both the non-AP station 120 and the AP 110, as described above, with reference to Figure 2. The ERCM key may be constant, or it may vary, for instance for each SSID, AP or ESS, or fully random.

Once the ERCM key is generated, the non-AP station 120 may send it to the AP 110 in a message (step 640). This message may be for example an "ERCM Key delivery Response" 820 as detailed below with reference to Figure 8.

At the reception of the message comprising the ERCM Key, the AP 110 may extract the key from the received message and store it. Also, in an optional step 650, the AP 110 may acknowledge the reception of the ERCM key to the non-AP station 120 by sending a confirmation message. For example, such message may be an "ERCM delivery Confirm" 830 as detailed below with reference to Figure 8.

According to other embodiments of the invention, the ERCM procedure may be initiated by a non-AP station 120. In such embodiments, the non-AP STA 120 may generate and transmit the ERCM Key to the AP 110 (step 640) without having received any ERCM Key delivery Request. In such embodiments, step 630 is omitted.

Alternatively, the non-AP station 120 may send a request for changing its MAC address to the AP (e.g. as in step 750 of Figure 7b). In response to this request, the AP may send a request for obtaining an ERCM key (step 630) to the non-AP station. In such embodiments, step 630 is implemented.

As an alternative, whether the ERCM procedure is initiated by the non-AP station or by the AP 110, the non-AP station 120 and the AP 110 may already have the ERCM key and steps 630, 640 and 650 may be omitted.

Figures 7a and 7b illustrates examples of sequence of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP, according to one or several embodiments of the invention. The changing procedure may be operated as soon as the initiation procedure (for example according to Figure 6) is completed.

The changing procedure basically comprises two steps: the computation of the new MAC address for each non-AP station 120, and the effective change of the MAC address at a date, called ERCM change Date, from which the new calculated MAC address is used for data exchanges between the AP 110 and the non-AP station 120. Therefore, during the changing procedure, each non-AP station 120 changes its MAC address from a current value @mac(n) to a new value @mac(n+1).

The new MAC address must be calculated by both the non-AP station(s) 120 and by the AP 110. At the ERCM change Date, both the non-AP station(s) 120 and the AP 110 may modify their respective registry by updating the MAC address of the non-AP station 120 from @mac(n) to @mac(n+1).

Furthermore, the other privacy measures specified by the IEEE Std 802.11-2020 for RCM may also be applied. For example, counters in all sequence number spaces used to identify data frames relative to non-AP station 120 may be reset and the non-AP station 120 may reset seeds used within the PHY DATA scrambler on the next PPDUs to be transmitted.

According to one or more embodiments, the AP 110 and the non-AP station 120 both store a list of MAC addresses, and each time a change of MAC address must be performed, the next value on the list is chosen as the new MAC address. Such embodiments could however present security problems, if a third party had access to the list. Also, it can be envisaged to apply the same function on the AP side and on the non-AP station side to determine, for example, an index corresponding to the row of the next MAC address. This index may be advantageously determined randomly.

In alternative embodiments, the next MAC address of a non-AP station 120 may be calculated randomly. For example, the AP 110 and the non-AP station 120 may use the same pseudorandom function (PRF) with the same input parameters.

Therefore, both the AP 110 and the non-AP station 120 obtain the same output @mac(n+1). The PRF may be used for calculating the 46 leftmost bits, as described above. By generating MAC addresses in a random or pseudorandom manner, it is not possible for a third party to predict the next address, which would pose security problems. In addition, there is already a pseudorandom function in the standard (specified for instance in section 12.7.1.2 of the standard IEEE Std 802.11-2020), which can advantageously be reused within the framework of the present invention. Therefore, no supplementary function is needed to implement the present invention.

Upon AP or non-AP STA request, both AP and non-AP STA compute a new transient MAC address for the changing STA, without sharing it, by using the standardized PRF-128 (section 12.7.1.2 -IEEE Std 802.11-202) with same parameters.

For example, the next MAC address @mac(n+1) may be computed by using the PRF-128/46 with the following 3 parameters: K is set to the ERCM key of the non-AP station, A is set to the string "ERCM" and B is set to the current MAC address @mac(n) of the non-AP station. That is to say: @MAC (n+1) = PRF-128/46( ERCM Key, "ERCM", @MAC (n) , 128) where: -From the generated 128 bits, the leftmost 46 bits (i.e. the 46 most significant bits) are selected; -In addition to the 46 bits, the U/L bit of the new MAC address is set to 1, the I/G bit is set to 0; -@MAC (n) corresponds to the current address MAC of the non-AP STA.

Alternatively, the next MAC address @mac(n+1) may be computed by using the PRF-128/46 with the following 3 parameters: K is set to the ERCM key of the non-AP station, A is set to the string "ERCM" and B is the current time.

Alternatively, the next MAC address @mac(n+1) may be computed by using the PRF-128/46 with the following 3 parameters: K is set to the ERCM key of the non-AP station, A is set to the string "ERCM" and B corresponds to any parameter which changes over the time and which is known by the AP and non-AP station.

However, in the last two cases, it is necessary to make sur that the value of the parameter is indeed the same with the AP and the non-AP station. For example, when B represent the current time, its value may be rounded to avoid differences between the values at the non-AP station and at the AP due to imperfect synchronization (even slight) between the clocks of the non-AP station and of the AP. Also, the new value may be calculated at a same time at the non-AP station and at the AP station (e.g. at step 713, or 750/760, or 770 in Figures 7a, 7b). When B is the current MAC address, this problem does not arise.

According to embodiments represented in Figure 7a, the changing procedure may be initiated by the AP 110 and intended to all the non-AP stations 120a, 120b of the BSS for which the initiation procedure has been performed. In other words, according to these embodiments, the AP 110 indicates to all the non-AP stations 120a, 120b for which the initiation procedure has been performed that they have to change their respective MAC addresses, and all these non-AP stations 120a, 120b change their respective MAC addresses at the same time (the ERCM change Date).

In the embodiments described below, the ERCM change Date is expressed in terms of number of Target Beacon Transmission Times (TBTTs). Of course, the ERCM change Date may be expressed differently, for example as an actual time (which may be rounded to avoid problems due to an imperfect synchronization of the clocks of the non-AP and the AP) As specified in IEEE 802.11 standards, the AP 110 periodically (every TBTT) transmits beacon frames, which are management frames containing information relative to the network, to the non-AP stations 120a, 120b of the BSS. According to embodiments represented in Figure 7a, the beacon frames may include an indication relative to the ERCM change Date. For instance, each beacon frame may include a counter field to indicate that a change of MAC address is in progress. For example, each beacon frame transmitted by the AP 110 to all the non-AP stations 120a, 120b of the BSS may contain an information element as described below with reference to Figure 9. The counter may be initially set to a value corresponding to the time at which the change must be operated (for instance, an initial value of k may indicate that the change must be operated in (k+1) TBTTs, k being an integer), and decremented of one unit at each transmission of a next frame. When the counter reaches the value 0, the change must be operated. Therefore, all transmissions of frames subsequent to the beacon frame associated with a counter equal to 0 must be performed with the new MAC address.

With reference to Figure 7a, the non-AP stations 120a, 120b receives a beacon frame including a counter, called ERCM Change counter, set to a value k (step 711).

This indicates that all the non-AP stations 120a, 120b (for which an initiation procedure has been done) must change their respective MAC addresses at a time corresponding to (k+1) TBTTs. Then, a next beacon frame is sent from the AP 110 to the non-AP stations 120a, 120b (step 712), comprising a ERCM Change counter with a value (k-1). After (k+1) beacon frame transmissions, the AP 110 sends a beacon frame with an ERCM Change counter equal to 0 to the non-AP stations 120a, 120b (step 713), indicating that the respective MAC addresses of the non-AP stations 120a, 120b must be updated. All subsequent transmissions between the AP 110 and the non-AP stations 120a, 120b may be performed with the new MAC addresses of the non-AP stations 120a, 120b.

The repetition of the counter (and therefore of the ERCM change Date) in beacon frames subsequent to the first beacon frame indicating a coming change of MAC address (i.e. the one sent at step 711) advantageously allows the non-AP stations 120a, 120b to be informed that their MAC addresses must be changed, even if they are in power safe or sleep mode. Indeed, even if one non-AP station misses one beacon frame, it can receive at least one counter before the next ERCM change Date by being awoken.

It is noted that the non-AP station may calculate the new MAC address anytime between steps 711 and 713. However, the effective change must be performed at step 713. Also, the AP may calculate the new MAC address before step 713, and perform the effective change at step 713.

Even if the embodiments of Figure 7a use beacon frames, it has to be understood that other types of frames may be used similarly.

According to alternative embodiments represented in Figure 7b, the changing procedure may be initiated by a non-AP station 120.

A request for changing MAC address is sent from the non-AP station 120 to the AP 110 (step 750). This request may be an "ERCM change Request" 840, as described below with reference to Figure 8. This request may contain an indication relative to the ERCM change Date. For instance, it may comprise a field (e.g. an ERCM Change Date field 843, as represented in Figure 8) indicating in terms of TBTTs the date of the next address change. For example, a value set to k may indicate that the change must be operated in (k+1) TBTTs, and a value set to 0 may indicate that the next MAC address is to be applied immediately. Therefore, all message transmissions subsequent to the transmission of the beacon frame associated with a counter equal to 0 are performed by using the new MAC address.

In response to the request for changing the MAC address, the AP 110 may acknowledge that it has received the request (step 760), for example by sending to the non-AP station 120 an "ERCM change Response" 850 as described with reference to Figure 8.

According to embodiments, when the non-AP station 120 sends the request for changing its MAC address, it may implement a counter reflecting the ERCM change date (e.g. a counter equal to k or (k-1), when the ERCM change date is expressed in number of TBTTs). Each time a new beacon frame is received from the AP 110, the counter may be decremented by one unit. At the reception, by the non-AP station 120 from the AP 110, of the beacon frame corresponding to the ERCM date, i.e. when the counter reaches the value zero (step 770), the change of MAC address is applied. The new MAC address may be effective at the start of the next TBTT. That means that all transmissions subsequent to the transmission of the beacon frame corresponding to the ERCM change date (step 770) are done with the new MAC address.

It is noted that the AP may calculate the new MAC address anytime between steps 750 and 770. However, the effective change must be performed at step 770. Also, the non-AP station may calculate the new MAC address before step 770, and perform the effective change at step 770.

Even if examples described with reference to Figures 7a and 7b use beacon frames and express time in TBTTs, other embodiments are possible. The invention only requires that an indication relative to the time at which the change is to be made is shared between the non-AP station and the AP, and that the non-AP station and the AP have means for counting the time. For example, it is possible to send an actual date, as long as the non-AP station and the AP have access to a same clock or to synchronized clocks. Changes may be performed periodically, or at predetermined times.

Also, it is noted that, alternatively to Figure 7a, the AP 110 may request that only one non-AP station 120 changes its MAC address. For this, an ERCM change Request (similar to that of Figure 7b) may be sent from the AP 110 to the concerned non-AP station 120.

Figure 8 illustrates examples frame formats to activate and operate a MAC address change procedure. All frame formats represented in Figure 8 are identified by a 'Category' field assigned to a specific value 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, the category value assigned for ERCM action frame may be set to 31. Another value may be used.

For example, the following may be added in the Table 9-51-Category values: Code Meaning Enhanced RCM where k is an integer between 31 and 125.

The frame formats represented in Figure 8 are identified by the single octet 'ERCM Action' field, which follows immediately the Category field. The values of the ERCM Action field may be defined in the following table, that may be inserted at the end of 9.6 Action frame format details of the standard IEEE Std 802.11-2020:

Action Field value Meaning

1 ERCM Key delivery Request 2 ERCM Key delivery Response 3 ERCM Key delivery Confirm 4 ERCM change Request ERCM change Response An ERCM Action field value set to 1 may correspond to an ERCM Key delivery Request. An ERCM Action field value set to 2 may correspond to an ERCM Key delivery Response. An ERCM Action field value set to 3 may correspond to an ERCM Key delivery Confirm. An ERCM Action field value set to 4 may correspond to an ERCM change Request. An ERCM Action field value set to 5 may correspond to an ERCM change Response.

For example, the ERCM Key delivery Request 810 may contain a Category field 811 set to value 31 and an ERCM Action field 812 set to value 1.

The ERCM Key delivery Response 820 may contain a Category field 821 set to value 31, an ERCM Action field 822 set to value 2 and an ERCM Key field 823 containing an ERCM key of 256 bits.

The ERCM Key delivery Confirm 830 may contain a Category field 831 set to value 31 and an ERCM Action field 832 set to value 3.

The ERCM change Request 840 may contain a Category field 841 set to value 31, an ERCM Action field 842 set to value 4 and an ERCM Change Date field 843.

The ERCM Change Date field 843 may indicate the date on which the change of MAC address is to be applied. In one or more embodiments, this date may be expressed in number of Target Beacon Transmission Times (TBTTs).

Other embodiments are possible. For example, the date on which the change of MAC address is to be applied may be an actual date. In such embodiments, the non-AP station and the AP must have sufficiently synchronized respective clocks (or have access to such clocks), to prevent the change from being made at one device but not the other.

The ERCM change Response 850 may contain a Category field 851 set to value

31 and an ERCM Action field 852 set to value 5.

Figure 9 illustrates an example of a frame format for operating a MAC address change procedure initiated by an AP, according to one or several embodiments of the invention.

It corresponds to an Information Element (1E) as specified in the section 9.4.2 in the standard IEEE Std 802.11-2020.

A dedicated IE may be specified for ERCM procedure, referred to as ERCM IE 900. An IE may be identified by an Element ID 910 and an Element ID Extension 930 assigned to a specific value in the range [99,255] as specified in table 9-92 of the IEEE Std 802.11-2020, so far reserved. For the purpose of illustration, the Element ID Extension for identifying an ERCM IE may be set to 99.

An ERCM IE 900 may contain an Element ID field 910 set to 255, a Length field 920, an Element ID Extension field 930 set to 99 and an ERCM Change counter field 940.

The Length field 920 indicates the number of octets in the IE 900 excluding the Element ID field 910 and the Length field 920. Its value is 2.

The ERCM Change counter field 940 indicates the ERCM date, which corresponds to the date when the next MAC address has to be applied. It may be expressed in Target Beacon Transmission Time (TBTT) and its integer value may correspond to the number of TBTTs until the next MAC address is effective. Other embodiments are possible.

Figure 10 schematically illustrates a communication device 1000, 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 1000 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 700 may comprise a communication bus 1013 to which may be connected: -a central processing unit 1001, such as a processor, denoted CPU; -a memory 1003, 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 1002 and 1002' 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 1004 and 1004', respectively.

Preferably the communication bus 1013 may provide communication and interoperability between the various elements included in the communication device 1000 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 1000 directly or by means of another element of the communication device 1000.

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 1002 or 1002', in order to be stored in the memory 1003 of the communication device 1000 before being executed.

In an embodiment, the device 1000 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 embodiment(s) 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 above-described 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.

Claims (22)

1. CLAIMS1. A method for changing a value of an Extended Unique Identifier, EUI, of a non-access point, non AP, station (120) associated with an access point, AP, station (110), the non-AP station (120) and the AP station (110) both having a shared function to generate the new value of the EUI and a shared parameter having a value varying over time, the method comprising at the non-AP station (120) or at the AP station (110): obtaining (210, 310, 410) a key shared with the other station; communicating (220, 320, 325, 420, 425), with the other station, a request for changing the value of the EUI and an indication relative to a time at which the value of the EUI is to be changed; calculating the new value of the EUI by using the shared key and a current value of the shared parameter as inputs of the shared function; replacing (230, 330, 430) a value of the EUI by the calculated new value of the EUI at the indicated time at which the value of the EUI is to be changed.
2. 2. The method of claim 1 performed at the non-AP station, wherein the obtaining (310) of the key shared with the AP station comprises, at the non-AP station: receiving (630), from the AP station, a request for obtaining the shared key; upon reception of the request for obtaining the shared key, generating the shared key; and sending (640) the generated shared key to the AP station.
3. 3. The method of claim 2, wherein the shared key is generated pseudorandomly.
4. 4. The method of claim 1 performed at the AP station, wherein the obtaining (410) of the key shared with the non-AP station comprises, at the AP station: sending (630), to the non-AP station, a request for obtaining the shared key; and in response to the request for obtaining the shared key, receiving (640) the shared key from the non-AP station.
5. 5. The method of any one of the preceding claims, wherein the shared function is a pseudorandom function, PRF.
6. 6. The method of any one of the preceding claims, wherein the current value of the shared parameter is a current value of the EUI.
7. 7. The method of any one of claims 1 to 5, wherein the current value of the shared parameter is a current time value.
8. 8. The method of any one of the preceding claims, wherein the non-AP station or AP station stores a registry comprising the value of the EUI of the non-AP station, wherein the replacing (230, 330, 430) of the value of the EUI by the calculated new value of the EUI comprises: replacing the value of the EUI of the non-AP station in the registry by the calculated new value.
9. 9. The method of any one of the preceding claims, wherein the EUI of the non-AP station is a MAC address of the non-AP station.
10. 10. The method of any one of the preceding claims, wherein the request for changing the value of the EUI is sent (420) by the AP station and received (320) by the non-AP station.
11. 11. The method of claim 10, wherein the request for changing the value of the EUI is a beacon frame (711).
12. 12. The method of claim 11, wherein the indication relative to the time at which the value of the EUI is to be changed is a counter (940) included in the beacon frame, said counter (940) indicating a number of Target Beacon Transmission Times, TBTTs.
13. 13. The method of claim 12, wherein, after the request for changing the value of the EUI, a plurality of subsequent beacon frames (712, 713) are sent by the AP station and received by the non-AP station, each subsequent beacon frame including a respective value of the counter, the value of the counter being decremented by one for each subsequent beacon frame; wherein the time at which the value of the EUI is to be changed is a time at which the beacon frame with a value of the counter equal to zero is sent from the AP station and received by the non-AP station (713).
14. 14. The method of any one of claims 1 to 9, wherein the request for changing the value of the EUI is sent (325) by the non-AP station and received (425) by the AP station.
15. 15. The method of any one of the preceding claims, wherein the indication relative to a time at which the value of the EUI is to be changed is included in the request for changing the value of the EUI.
16. 16. The method of claim 15, wherein the indication relative to the time at which the value of the EUI is to be changed is a number k of Target Beacon Transmission Times, TBTTs, in which the value of the EUI is to be changed.
17. 17. The method of claim 16, wherein the value of the EUI is changed when a k-th beacon frame since the communicating of the request is sent from the AP station or received by the non-AP station.
18. 18. The method of claim 15, wherein the indication relative to a time at which the value of the EUI is to be changed is a time value.
19. 19. The method of claim 18, wherein the value of the EUI is changed when a beacon frame corresponding to a first beacon frame after the time value is reached is sent from the AP station or received by the non-AP station.
20. 20. The method of any one of the preceding claims, wherein capabilities (530) for implementing a procedure for changing the value of the EUI has been exchanged during association between the non-AP station and the AP station.
21. 21. A wireless communication device comprising at least one microprocessor configured for carrying out the steps of the method of any one of claims 1 to 20.
22. 22. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 20, when loaded into and executed by the programmable apparatus.