WO2024188857A1

WO2024188857A1 - Dynamic setting of station association parameters to improve user privacy and communication reliability

Info

Publication number: WO2024188857A1
Application number: PCT/EP2024/056189
Authority: WO
Inventors: Stéphane Baron; Patrice Nezou; Julien Sevin
Original assignee: Canon Europe Ltd; Canon Inc
Current assignee: Canon Europe Ltd; Canon Inc
Priority date: 2023-03-10
Filing date: 2024-03-08
Publication date: 2024-09-19
Anticipated expiration: 2025-09-10
Also published as: KR20250141238A; GB202303588D0; GB2628008A; CN120770169A

Abstract

At least one embodiment of a method for changing a value of a public identifier of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising, at the AP station, obtaining a new value for the public identifier, identifying a need for changing the obtained new value, generating a request for changing a new value for the public identifier, obtained by the non-AP station, corresponding to the new value obtained by the AP station, and transmitting the generated request to the non-AP station.

Description

DYNAMIC SETTING OF STATION ASSOCIATION PARAMETERS TO IMPROVE USER PRIVACY AND COMMUNICATION RELIABILITY

FIELD OF THE DISCLOSURE

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

BACKGROUND OF THE DISCLOSURE

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 large 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, etc.) of a user without his/her consent, by means of their MAC addresses. This is because mobile phones are configured to discover surrounding access points to wireless networks. As a user moves, his/her mobile phone sends requests to determine if there are any access points nearby, these requests identifying the mobile phone which sends these requests and including in particular the MAC address of the mobile phone. Access points that hear these requests can respond. In the context of Wi-Fi networks as defined by IEEE 802.11 standards (Wi-Fi is a trademark), this procedure is called Probe Request/Response exchange.

So even when a mobile phone is not connected to a Wi-Fi network, surrounding access points may receive its MAC address. It is then possible to track a user by reconstructing his/her trajectory from access points to which his/her mobile phone has sent its MAC address. In addition, if the mobile 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 provided personal identification information (name, place of residence, etc.) 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 with a network (or, equivalently, with 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.

More specifically, a new Management Information Base (MIB) variable controllable by an external management entity has been specified. This variable is called ‘dotH MACPrivacyActivated’. When dotH MACPrivacyActivated 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 Elll-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 a software or a 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 first octet 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 first octet 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). 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). When the RCM is operated, counters in all sequence number spaces used to identify data frames (MAC service data units, MSDUs, packets or Management MAC Protocol Data Units, MMPDUs, frames) have 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. Some RCM implementations propose a mechanism for an AP and an associated non-AP station (denoted STA) to generate a new MAC address without exchanging it.

The inventors have observed that the MAC address is not the only identifier present in clear in frames exchanged between stations of a wireless LAN, and an eavesdropper may capture other elements that uniquely identify emitting stations.

In particular, one of these unique identifiers is the Association Identifier (AID). This identifier, that is assigned by an access point upon association with a station, is communicated in an Association Response frame sent by the access point in the last frame exchange of the association process. The AID is a 16 bit identifier that is locally unique. This means that two stations associated with two different Basic Service Sets (BSSs) of an AP station may have the same AID value, but two stations associated with the same BSS shall not share the same AID value. The AID has been originally introduced to reduce the signaling overhead when an AP wants to identify a station for delivery of buffered frames when power-saving is enabled. The AID is advantageously used in replacement of the MAC address (that is 48 bit long) when an AP indicates in Traffic Indication Messages that it has some traffic waiting for transmission to a station in power save state. But of course, the range of value for the AID selection is much shorter. In addition, in IEEE 802.11 series, the AID for a station is limited to a sub range [1 ; 2,007] of an 11 bit identifier (instead of the 2,045 possible values), the other values being reserved to identify some groups of stations, or specific signalling (unassigned resource, resources for random access, etc.).

Therefore, upon modification of the MAC address to maintain user privacy and avoiding tracking, it is advisable to also change the AID since it would be quite easy for an eavesdropper to correlate a newly changed MAC address and the old MAC address if the AID remains the same. In this scope, an IEEE 802.11 bi requirement document includes requirements mandating to define a mechanism for a station to change its AID address.

While recent solutions have been proposed to solve this issue, relying on the computing and assignment of a new AID by an AP and requiring systematic requests to exchange the newly generated AID, there is an ongoing need to improve user privacy and communication efficiency.

SUMMARY OF THE DISCLOSURE

The present disclosure has been devised to address one or more of the foregoing concerns.

In this context, there is provided a solution enabling dynamic setting of station association parameters to improve user privacy and communication reliability.

The present disclosure proposes a mechanism that allows a non-AP station (STA) to generate its new AID upon MAC address change and also propose a mechanism for the AP station to solve potential collision issues before such collisions effectively occur.

According to a first aspect of the disclosure, there is provided a method for changing a value of a public identifier of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the AP station: obtaining a new value for the public identifier; identifying a need for changing the obtained new value; generating a request for changing a new value for the public identifier, obtained by the non-AP station, corresponding to the new value obtained by the AP station; and transmitting the generated request to the non-AP station.

Accordingly, the method of the disclosure makes it possible to change efficiently one or more public identifier values to improve user privacy, communication reliability, and use of communication resources. More particularly, user privacy may be improved by allowing a station to change its AID upon MAC address change, while being associated, without breaking the ongoing connection. In most cases, the change of the AID is not easily detectable since there is no (or few) message exchange.

According to some embodiments, the determining a need for changing the obtained new value comprises determining that the obtained new value is assigned to another non-AP station.

Still according to some embodiments, the determining a need for changing the obtained new value comprises determining that the obtained new value is in violation of at least one value assignment rule of the AP station.

Still according to some embodiments, the method further comprises generating another new value for the public identifier.

Still according to some embodiments, the generated request comprises the generated another new value.

Still according to some embodiments, the generated request comprises at least one item of information enabling the non-AP station to generate another new value for the public identifier.

Still according to some embodiments, the at least one item of information comprises a range of values to which the another new value should belong, an offset for computing another new value from a new value, a number of iterations of a value generation process, or at least one initialization parameter of a pseudo-random number generator.

Still according to some embodiments, the method further comprises a forbidding of using the new value for the public identifier to transmit one or more messages to a non-AP station.

Still according to some embodiments, using the new value for the public identifier to transmit one or more messages to a non-AP station is forbidden until another new value for the public identifier is determined.

Still according to some embodiments, the generated request is a request for changing the value of a plurality of public identifiers.

Still according to some embodiments, the generated request is a protected action frame.

Still according to some embodiments, the generated request comprises an indication of a moment at which a new value for the public identifier is to be used.

Still according to some embodiments, the generated request comprises an item of information for identifying the public identifier.

According to a second aspect of the disclosure, there is provided a method for changing a value of a public identifier of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the non-AP station: obtaining a new value for the public identifier; receiving a request for changing the obtained new value; and determining another new value for the public identifier based on at least one item of information of the received request.

Accordingly, the method of the disclosure makes it possible to change efficiently one or more public identifier values to improve user privacy, communication reliability, and use of communication resources. More particularly, user privacy may be improved by allowing a station to change its AID upon MAC address change, while being associated, without breaking the ongoing connection. In most cases, the change of the AID is not easily detectable since there is no (or few) message exchange. According to some embodiments, the method further comprises determining whether the non-AP station is in a transition period and, if the non-AP station is not in a transition period, initiating a transition period.

Still according to some embodiments, the method further comprises generating and transmitting a response to the request for changing the new value for the public identifier, the response being indicative of the determination of the another new value.

Still according to some embodiments, the method further comprises determining the moment at which the another new value is to be used, based on at least one item of information of the received request.

Still according to some embodiments, the public identifier is an Association Identifier, AID.

According to a third aspect of the disclosure, there is provided a method for changing a value of a public identifier of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the AP station: obtaining a range of values for the value of the public identifier; generating an information element comprising a representation of the obtained range of values, the obtained range of values having to be used by the non-AP station each time a new value of the public identifier is to be determined; and transmitting the generated information element to the non-AP station.

According to a fourth aspect of the disclosure, there is provided a method for changing a value of a public identifier of a non-access point, non-AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the non-AP station: receiving, from the AP station, an information element comprising a representation of a range of values of the public identifier and storing the received range of values; and each time a value of the public identifier is needed, determining a value of the public identifier, the determined value belonging to the range of values stored.

According to some embodiments, the public identifier is an Association Identifier, AID.

The third and fourth aspects of the disclosure make it possible to improve use of communication resources, in particular to reduce the number of messages to be exchanged and the risk of conflicting public identifier values.

According to another aspect of the disclosure there is provided a device comprising a processing unit configured for carrying out each of the steps of the method described above.

This aspect of the disclosure has advantages similar to those mentioned above.

At least parts of the methods according to the disclosure may be computer implemented. Accordingly, the present disclosure 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 disclosure 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 solution of the present disclosure can be implemented in software, the solution of the present disclosure can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible 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 disclosure 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 some embodiments of the disclosure may be implemented;

Figure 2a illustrates a first example of a sequence of steps for operating a procedure for changing a public identifier of a non-AP station associated with an AP station, according to some embodiments of the disclosure; Figure 2b illustrates a particular case of the example illustrated in Figure 2a, illustrating an example of a sequence of steps wherein the public identity change is initiated by the AP, according to some embodiments of the disclosure;

Figure 3 illustrates a second example of a sequence of steps for operating a procedure for changing a public identifier of a non-AP station associated with an AP station, according to some embodiments of the disclosure;

Figure 4 illustrates an example of steps performed by an AP station for determining a new public identifier value to be used, according to some embodiments of the disclosure;

Figure 5 illustrates an example of steps carried out by a non-AP station upon reception of a frame requesting a change of one or more public identifier values;

Figure 6 illustrates examples of the format of change request frames;

Figure 7 illustrates an example of the format of a change response frame;

Figure 8 illustrates an example of frame formats of two Information Elements enabling a non-AP station to change its AID; and

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

DESCRIPTION OF SOME EMBODIMENTS

According to some embodiments of the disclosure, the value of one or more particular station association parameters may be changed after the values of a set of station association parameters, comprising the particular parameters, are set. The change may occur for example in case of conflicting values. Such particular parameters may be identifiers, in particular public identifiers also referred to as obfuscated identifiers, blind identifiers, concealed identifiers, or over the air (OTA) identifiers, that is to say parameters that value is transmitted in clear in different fields of frames exchanged between a station and its associated access point. For the sake of clarity, the following description is directed to public identifiers, that are typically part of the headers of the frames and may change over time to avoid an eavesdropper to track a station activity and movement, while private identifiers (also called device identifiers, or device IDs) may remain the same for a much longer period of time and remain secret.

According to some embodiments, a new value of one or more public identifiers is determined independently in an AP station and in a non-AP station, using the same mechanism to provide same results, and it is checked in the AP station whether the new value may be used reliably (e.g., whether the new value is not conflicting with a value already in use). If there is a risk, the AP station generates another new value and requests the non-AP station to use this another new value. The AP station may provide this another new value to the non-AP station or may provide the non-AP station with items of information enabling the non-AP station to generate this value.

Figure 1 illustrates an example of a network system in which some embodiments of the disclosure may be implemented.

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

AP station 105 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 in a broadband remote access server (BRAS).

Non-AP stations 110a, 110b, and/or 110c 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 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, some of non-AP stations 110a, 110b, and 110c may be wireless nodes. Such a 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.

AP station 105 manages a set of stations that together organize their accesses to the wireless medium for communication purposes. All the stations (AP station 105 and non-AP stations 110a, 110b, and 110c) form a service set, which may be referred to as basic service set, BSS (although other terminology can be used). It is noted that AP station 105 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 station implemented in physical AP station 105.

Examples of use cases

Figure 2a illustrates a first example of a sequence of steps for operating a procedure for changing a public identifier (for example the AID or the Over The Air (OTA) MAC address) of a non-AP station associated with an AP station, according to some embodiments of the disclosure.

The public identifier changing procedure basically comprises two phases: a first phase during which new public identifier values for one or more non-AP stations are computed and during which the AP station and the one or more non-AP stations identify the effective change start time, and a second phase corresponding to an effective change of the public identifier values of these non-AP stations. The effective change of public identifier values starts at a time called SERCPI change start time and ends at the latest at a time called maximum SERCPI change end time, from which the new calculated public identifier values are used for data exchanges between the considered non-AP stations and the AP station with which they are associated, SERCPI standing for Seamless Enhanced Randomized and Changing Public Identifier. Therefore, during the changing procedure, each considered non- AP station changes its public identifier value from a current value (for instance AID(n) or @MAC(n)) to a new value (AID(n+1) or @MAC(n+1)). During the transition period, both current and new values for the public identifiers are valid.

The new public identifier values must be calculated by the considered non-AP station(s) and by the AP station.

At the SERCPI change start time, the non-AP station(s) and the AP station start the effective change procedure and, at the maximum SERCPI change end time (or earlier), they modify their respective registry by updating the public identifier values of each of the considered non-AP stations from old to new values for each public identifier.

In other words, at the starting of the transition period, both AP and non-AP STA initiate the public identifier change for the changing non-AP STA.

The way the AP station and the non-AP stations initially determine the new public identifier values to be used, for example the new MAC addresses or Al Ds, is out of scope of the disclosure. The AP station and the non-AP stations may, for instance, store a list of identifier values, and each time a change of public identifier values must be performed, the next value in the list is chosen as the identifier value. Such embodiments could, however, lead to security issues if a third party had access to the list. Alternatively, the same function may be used by a non-AP station and the AP station with which it is associated to determine, for example, an index of the next identifier values to use in a predetermined list of identifier values. This index may be advantageously determined randomly.

Another public identifier selection method can be used. For example, it may be based on the usage of a pseudorandom function (PRF) with the same input parameters. Therefore, both a non-AP station and the AP station with which it is associated obtain the same value for their public identifiers (AID(n+1) and/or @MAC(n+1) for instance).

Back to Figure 2a and by reference to Figure 1 , it is illustrated a changing procedure initiated by AP station 105 and intended to non-AP stations 110a and words, according to these embodiments, AP station 105 indicates to non-AP stations 110a and 110b for which the initiation procedure has been performed that they have to change their respective public identifier values, and non-AP stations 110a and 110b initiate the change of their respective public identifier values at the same time (the SERCPI change start time).

For the sake of illustration, the SERCPI change start time may be expressed in terms of a number of Target Beacon Transmission Times (TBTTs). Of course, the SERCPI change start time may be expressed differently, for example as an actual time (which may be rounded to avoid any problem due to an imperfect synchronization of the clocks of the non-AP and AP stations).

According to IEEE 802.11 standards, an AP station periodically (every TBTT) transmits beacon frames to the non-AP stations of the BSS, which are management frames containing information relative to the network. Therefore, beacon frames may include a field storing an item of information to indicate a SERCPI change date. For example, such an item of information may represent a value of a counter that is decremented within each successive beacon frame transmitted by the AP station so as to indicate that a change of a public identifier value is in progress and to indicate the SERCPI change date. For example, each beacon frame transmitted by AP station 105 to non-AP stations 110a and 110b of the BSS may contain an information element providing a SERCPI maximum transition period. 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 beacon 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 public identifier value(s). In another implementation, the counter is initialized to its maximum value and is constantly decreasing of one unit (going back to its maximum value when reaching 0) at each transmission of a next beacon. When the counter reaches a predetermined value, that can be different for each non-AP station associated with the AP station, the change must be operated by the corresponding non-AP stations.

With reference to Figure 2a, non-AP stations 110a and 110b receive a beacon frame including a counter, denoted SERCPI Change counter, initially set to value k (step 200). It indicates that non-AP stations 110a and 110b (for which an initiation procedure has been done) must change their respective public identifier values at a time corresponding to (k+1) TBTTs. Then, a next beacon frame is sent from AP station 105 to non-AP stations 110a and 110b (step 205), comprising SERCPI Change counter with a value (k-1). After (k+1) beacon frame transmissions, AP station 105 sends a beacon frame with SERCPI Change counter equal to 0 to non- AP stations 110a and 110b (step 210), indicating that the change of the respective public identifier values of non-AP stations 110a and 110b must be initiated. The new public identifier values of non-AP stations 110a and 110b should be determined at any time between steps 200 and 210, that it to say after requesting the public identifier change and before starting the effective public identifier change.

All the transmissions between AP station 105 and non-AP stations 110a and 110b, occurring after max SERCPI change end time 615, should be performed with the new public identifiers of non-AP stations 110a and 110b.

The transition duration (referenced 220) between SERCPI change start time 210 and max SERCPI change end time 215 advantageously allows the AP station and the non-AP stations to transmit the frames addressed with the old public identifier values (e.g., AID(n) or @MAC(n)) that were buffered in their transmission buffer. This allows to change the public identifier values without breaking the on-going transmissions, making it possible that frequent public identifier changes do not have negative effects on the performances.

As illustrated in Figure 2a with reference 225, AP 105 may initiate a public identifier change by sending a public identifier change request to non-AP stations 110a and/or 110b that in turn confirm determination of another new public identifier in a public identifier change response (referenced 230). For the sake of illustration, such a request for another new public identifier value may be needed if it is determined that a new public identifier value to be used conflicts with another public identifier value, for example a public identifier used by another non-AP station. This may happen in particular when the considered public identifier is an AID since the number of AID possible values is rather small compared to the number of possible MAC address values.

Figure 2b illustrates a particular case of the example illustrated in Figure 2a, illustrating an example of a sequence of steps wherein the public identity change is initiated by the AP station contrary to the example of figure 3 where the public identifier changing procedure may be initiated by non-AP station 110a. For the sake of clarity, the same references as the ones used in Figure 2a are used in Figure 2b. According to the example illustrated in Figure 2b, AP station 105 detects a conflict only on AID of the non-AP station 110a (STA2) and selects another new public identifier value (another new AID value in this example) that is sent to the non-AP station to be used in place of the new public identifier value computed by the non- AP station. In this example,

• each non-AP station (STA1 and STA2) computes locally new public identity values (STA1 : @MACi and AIDi computing, STA2: @MAC2 and AID2 computing). The AP station performs the same operations and computes same values (STAs @MAC and AID computing);

• if the AP station detects a conflict (STA2 AID2 conflict detection), it generates a new public identifier value (New AID2’ selection for STA2) and sends it to the concerned non-AP station (STA2 in this example) that uses it to replace the locally computed new public identifier value (STA2 AID2’ setting); and

• at the end of the transition period, all the non-AP stations (STAs) and the AP station use new public identifier values.

This example describes a mechanism to generate a new AID for an associated STA upon its OTA MAC address modification. The described mechanism allows the generation of a new AID for an associated STA without any message exchange in most scenario. The resolution of potential AIDs conflict by the AP is also described.

Advantageously, whatever the cause of a potential conflict (detected prior to the effective use of a new AID, or even after its use), the AP can provide a new AID to the STA.

Figures 4 and 5 illustrates examples of steps for requesting and setting other new public identifier values, in particular in case of conflict or when a new public identifier value to be used does not meet required conditions.

It is noted that while the embodiments described by reference to Figure 2a and Figure 2b use beacon frames, other types of frames may be used similarly.

Figure 3 illustrates a second example of a sequence of steps for operating a procedure for changing a public identifier of a non-AP station associated with an AP station, according to some embodiments of the disclosure.

According to the alternative embodiments illustrated in Figure 3, the public identifier changing procedure may be initiated by non-AP station 110a. As illustrated, a request for changing the public identifier value of the considered non-AP station (i.e. non-AP station 110a in this example) is sent from non-AP station 110a to AP station 105 (step 300). This request may be an “SERCPI change Request”, for example “SERCPI change Request” 300. This request may contain an indication relative to the SERCPI change date and to the SERCPI max. transition period duration.

For the sake of illustration, it may comprise a field indicating, for example in terms of TBTTs, the date of the next public identifier 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 public identifier is to be applied immediately. Accordingly, all message transmissions subsequent to the transmission of the beacon frame associated with a counter equal to 0 should be performed by using the new public identifier.

The SERCPI change request frame may also contain a field indicating the maximum duration of the transition period. At the expiration of the transition period, both the AP station and the non-AP station should use the new public identifier value.

As illustrated, in response to the request for changing the public identifier, AP station 105 may acknowledge that it has received the request and that it agrees to change the public identifier value of non-AP station 110a (step 305), for example by sending to non-AP station 110a a “SERCPI change Response”.

According to some embodiments, non-AP station 110a may implement a counter reflecting the SERCPI change date (e.g. a counter equal to k or (k-1)) when it sends the request for changing its public identifier, the SERCPI change date being here expressed in a number of TBTTs. Each time a new beacon frame is received from AP station 105, the counter may be decremented by one unit. Upon reception by non-AP station 110a, from AP station 105, of the beacon frame corresponding to the SERCPI date, i.e. when the counter reaches the value zero (step 310), the change of the public identifier is initiated. At the end of the transition period (reference 320), the new public identifier of non-AP station 110a is effective (at the beginning of the next TBTT). This means that all transmissions subsequent to the transmission of the beacon frame corresponding to the maximum SERCPI change end time (step 315) are done with the new public identifier value.

It is noted that the new public identifier value of non-AP station 110a should be determined at any time between steps 300 and 310, that it to say after requesting the public identifier change and before starting the effective public identifier change.

Although the examples described with reference to Figures 2a, 2b, and 3 are based on the use of beacon frames and TBTTs, there exist other embodiments. Indeed, according to some embodiments, it may be needed to share, between the considered non-AP stations and the AP station with which they are associated, an indication relative to the time at which the change is to be made, and to provide the non-AP stations and the AP station with 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 station have access to the same clock or can synchronize their clocks. Changes of public identifier values may be performed periodically, at predetermined times, or on requests.

It is also noted that, based on the example illustrated in Figure 2a or 2b, an AP station may request that only one non-AP station changes its public identifier value. To that end, a SERCPI change request similar to the one described by reference to Figure 3 may be sent from the AP station to the considered non-AP station.

As illustrated in Figure 3 with reference 325, AP 105 may initiate a public identifier change by sending a public identifier change request to non-AP stations 110a that in turn confirm determination of another new public identifier value in a public identifier change response (referenced 330). As described above, such a request for another new public identifier value may be needed if it is determined that a new public identifier value to be used conflicts with another public identifier value, for example a public identifier value used by another non-AP station.

Figure 4 illustrates an example of steps performed by an AP station for determining a new public identifier value to be used, according to some embodiments of the disclosure. Such steps may be carried out between steps 225 and 230 in Figure 2a or 2b or steps 325 and 330 in Figure 3 to determine that another new public identifier value is needed.

After having determined association parameter values enabling exchange of data between an AP station and a non-AP station (step 400), the AP station determines that one or more of these parameter values, representing here public identifier values, need to be changed (step 405), for example for user privacy reasons. For the sake of illustration, this determination may be based on a previously negotiated frequency of change of these parameter values or, according to the examples illustrated in Figures 2a, 2b, and 3, upon transmission of a beacon indicating that a change is to be made.

According to a particular embodiment, the AP station and the non-AP station generate almost simultaneously the same value for one or more public identifiers, for example the AID (i.e., the AP station and the non-AP station generate the same value locally using the same shared function and parameters). This embodiment makes it possible to avoid exchange of additional messages between the AP station and the non-AP station thus increasing privacy and reducing overhead.

Since some public identifiers may have a reduced number of different possible values compared to the number of non-AP stations, the probability of randomly generating a value already assigned to another non-AP station may be significant. Therefore, a conflict avoidance mechanism should preferably be used. Accordingly, the AP station may determine whether the one or more newly generated public identifier values create a conflict with existing values of the same public identifier for another non-AP station associated with the AP station. Since the AP station knows the public identifier values assigned to each of its associated stations, it is able to determine whether the newly generated values have already been assigned to other stations.

Alternatively or additionally, the AP station may determine whether the newly generated public identifier values conform with an existing identifier value assignment plan: an AP may decide to assign public identifier values to public stations according to a predetermined plan. For instance, an AP station may divide the AID plan into several distinct ranges corresponding to different types or profiles of devices. This allows the AP station to group non-AP stations per types in a single request (like the NFRP trigger frame that polls non-AP stations using a range of AIDS).

If the AP station determines that there is no conflict between the new public identifier values and previously assigned public identifier values, the new public identifier values are used without any need for additional frame exchanges.

On the contrary, if the AP determines that a conflict occurred, another new public identifier value (or other new public identifier values) is selected or determined (step 415). For the sake of illustration, this step may comprise repeating the generation operation until the generated public identifier value is not conflicting any more with previous public identifier values assigned. In this embodiment, the pseudo random generation may be run using the previously conflicting value as changing parameters in the pseudo random generation process. The AP station counts the number of times it repeats the process in a dedicated retry counter that can be transmitted as a pseudo random generation parameter, as described with references 620-1 and 620-3 in Figure 6.

According to another embodiment, the AP station selects the next acceptable value for the public identifier (for instance by increasing the value of the generated public identifier value, modulo the acceptable range, for this non-AP station, until obtaining a non-conflicting value). In this embodiment, the increasing value (offset) can be sent in a parameter field like parameter field 620-1 or 620-3 in Figure 6. In this embodiment, the non-AP station apply the corresponding offset to its current generated value upon reception of the corresponding frame to obtain a new nonconflicting value.

In yet another embodiment, the AP station selects the new public identifier value by any other means and just provide the resulting value in a field value like field value 640-2 in Figure 6. In this embodiment, the non-AP station just replaces its current generated public identifier value by the new one received in the corresponding frame.

Since the AP station determines that the public identifier value generated by both the AP station and the non-AP station is conflicting with the public identifier value assigned to another non-AP station, the conflicting public identifier value is preferably set in a quarantine list of public identifiers that should not be used until the conflict is solved (step 420). This means that until the conflict is not solved, the AP station does not transmit frames containing the conflicting public identifier value (to the non-AP station that public identifier value is being changed, but also to the other non-AP station that already uses this public identifier value).

Next, the AP station creates an identifier change request frame (e.g., frame 600- 1 , 600-2, or 600-3 in Figure 6) to indicate to the non-AP station having generated a conflicting public identifier value that the latter should be changed according to the parameters transmitted by the AP station.

In the case where a public identifier value is generated by the AP station and the non-AP station, the AP station may indicate an identifier index corresponding to the public identifier, enabling the non-AP station to identify the public identifier. An example of identifier indexes can be found in the following table (of course, this list of identifiers and associated index values is not limitative, it is just provided as an example).

According to some embodiments, the AP station may indicate an acceptable range for public identifier values to be generated, for example by setting a minimum value field and a maximum value field (e.g., min value field 625-1 and max value field 630-1 in Figure 6), if the AP station determines that a public identifier value is conflicting its internal public identifier value plan.

After creating a public identifier change request frame, the AP station sends the frame to the non-AP station to change its corresponding public identifier value. Next, after reception of an acknowledgement of the request frame or reception of an optional public identifier change response (e.g. public identifier change response 700 in Figure 7), the AP station removes the conflicting identifier value from the quarantine list (so that it may be used again without any conflict) and the newly generated public identifier value is considered as valid.

According to some embodiments, steps 405 to 425 are carried out before the SERCPI change end time (e.g., before SERCPI change end time 215 in Figure 2a or 2b or before SERCPI change end time 315 in Figure 3) so that the non-AP station directly takes into account a potential new public identifier value, avoiding any conflict.

According to some embodiments, the AP station may indicate a new max SERCPI change end time if it determines that a conflict occurred. For the sake of illustration, it may indicate a new max SERCPI change end time 215 or 315 by indicating the new value in a switch count field like switch count field 635-1 , 635-2, or 635-3 in Figure 6, that indicates a number of beacons or TBTTs to wait before the effective use of the identifier value, of the identifier change request 225 or 325. This enables the AP station to provide more time to the non-AP station to change the public identifier value with the one that is to be used. This may be especially useful in the case of frequent identifier changes in a heavily loaded network (creating delay in medium access for transmission), or if the request sent by the AP station requires additional computation on the station side (new pseudo random generation for instance).

Still according to particular embodiments, the AP station can repeat steps 415 to 425 for each of the conflicting public identifier values, if it determines that more than one public identifier value are conflicting with values already assigned to non-AP stations. In such embodiments, an additional signaling providing a list of public identifiers that values are to be regenerated by a given non-AP station may be provided in a change request frame, for example in identifier index field 615-1 , 615- 2, or 615-3 of the change request frame 600-1 , 600-2, or 600-3, respectively, in Figure 6, allowing the AP station to send a single request instead of a request per identifier value to change. In these embodiments, the encoding of the identifier index field is different. It may be a bitmap wherein each bit corresponds to a public identifier (for example, a bit set to 1 in the bitmap indicates that the corresponding public identifier value should be regenerated according to the parameters provided in the frame). The bit value corresponding to the public identifier may be the identifier index indicated in the previous table.

Figure 5 illustrates an example of steps carried out by a non-AP station upon reception of a frame requesting a change of one or more public identifier values.

After having determined association parameter values enabling exchange of data between an AP station and a non-AP station (step 500), the non-AP station receives a public identifier change request (e.g., public identifier change request 600-1 , 600- 2, or 600-3 in Figure 6) from its associated AP station (step 505).

Next, a test is carried out to determine whether the non-AP station is in a transition period (step 410), that is to say a period of time between the SERCPI change start time and ERCPI change end time.

If the non-AP station is in a transition period, the non-AP station is in the process of changing the value of one or more of its public identifiers. Accordingly, upon reception of a request frame (e.g., request frame 600-1 , 600-2, or 600-3 in Figure 6), the non-AP station updates its internal transition parameters (i.e., the parameters used to generate public identifier values) according to the parameters received in the request frame (step 420), for example in field 620-1 or 620-3 in Figure 6. On the contrary, if the non-AP station is not in a transition period, the non-AP station initiates a new transition period (step 415) for generating all public identifier values before updating its internal transition parameters (step 420).

Next, the non-AP station generates the value of the one or more public identifiers to be changed, using the new transition parameters, for example according to the different embodiments described with reference to Figure 4. In some particular embodiments, the AP station provides the new public identifier value and the non- AP station simply replaces its newly generated public identifier value with the one provided by the AP station. According to some embodiments, the change request frames (e.g., request frame 225 in Figure 2a or 2b or 325 in Figure 3) and the change response frames (e.g., change response frame 230 in Figure 2a or 2b or 330 in Figure 3) are protected action frames therefore, the new value is protected (i.e., encrypted).

Examples of change request frames and change response frames

Figure 6 illustrates examples of the format of change request frames and Figure 7 illustrates an example of the format of a change request frame.

Frames 600-1 , 600-2, and 600-3 are examples of public identifier change request frames sent by an AP station to one of its associated non-AP stations to change the value of one or more of its current public identifiers according to the new parameters transmitted in their subfields. Frame 700 is an example of a public identifier change response frame that may be sent by the non-AP station to the AP station in response to a public identifier change request frame.

As illustrated, each of the frames referenced 600-1 , 600-2, 600-3, and 700 comprises a category field referenced 605-1 , 605-2, 605-3, and 705, respectively, that indicates that the aim of the frame is directed to changing a public identifier value. Table 9-51 of the IEEE 802.11-2020 standard may be modified to comprise a specific category, for example by adding the following category value:

In addition, frames 600-1 , 600-2, 600-3, and 700 are further identified by a field denoted ‘Change ID Action’, referenced 610-1 , 610-2, 610-3, and 710, respectively, that may be a single bit field and that may immediately follow the category field. The values of the Change ID Action field may be defined according to the following table, that may be inserted at the end of the “9.6 Action frame format details” paragraph of the IEEE 802.11-2020 standard:

Still for the sake illustration, an identifier action field value set to 6 may correspond to a public identifier change request and an identifier action field value set to 7 may correspond to a public identifier change response.

As illustrated, each of the frames referenced 600-1 , 600-2, and 600-3 comprises an identifier index field referenced 615-1 , 615-2, and 615-3, respectively, to indicate the public identifier(s) that value is to be changed.

In addition, each of the frames 600-1 , 600-2, and 600-3 comprises fields to provide information to a non-AP station to enable it to obtain public identifier values to be used.

For the sake of illustration, frame 600-1 comprises a parameter field 620-1 , a min value field 625-1 , a max value field 630-1 , and a switch count field 635-1 . According to some embodiments, parameter field 620-1 is used to transmit a number of times the process of generating a public identifier value should be repeated to obtain the public identifier value to be used. According to some other embodiments, parameter field 620-1 is used to transmit an increasing value (offset) that is to be used to obtain the public identifier value to be used from the public identifier value previously generated. Still according to some embodiments, min value field 625-1 and max value field 630-1 are used to provide an acceptable range of values in which the public identifier value to be used is to be chosen. Such range of values may be obtained from an internal identifier value plan of the AP station. The items of information provided in fields 620-1 to 630-1 enable the non-AP station to generate a new value for one or more public identifiers referenced in identifier index field 615- 1 . Finally, switch count field 635-1 may indicate a number of beacons or TBTTs to wait before the effective use of the new public identifier value.

Frame 600-2 comprises a switch count field 635-2 and a value field 640-2. Like switch count field 635-1 , switch count field 635-2 may indicate a number of beacons or TBTTs to wait before the effective use of the new public identifier value provided in value field 640-2 (that has been generated by the AP station).

Still for the sake of illustration, frame 600-3 comprises a parameter field 620-3 and a switch count field 635-3. Parameter field 620-3 is similar to parameter field 620-1. According to some embodiments, parameter field 620-3 is used to transmit a number of times the process of generating a public identifier value should be repeated to obtain the public identifier value to be used. According to some other embodiments, parameter field 620-3 is used to transmit an increasing value (offset) that is to be used to obtain the public identifier value to be used from the public identifier value previously generated. Like switch count field 635-1 , switch count field 635-3 may indicate a number of beacons or TBTTs to wait before the effective use of the new public identifier value.

According to particular embodiments, the change request frame 600-1 , 600-2, or 600-3 and the response frame 700 are two new protected action frames part of the Enhanced Data Privacy (EDP) action frames as defined in the IEEE 802.11 standard.

The table below provides an example of encoding of the protected action fields for these new EDP protected action frames in the case of regenerating public identifier values:

Still according to some particular embodiments, the protected action frames are specialized per identifier. For the sake of simplicity, the following table indicates an encoding scheme of the corresponding protected action fields for such protected action frames for the change of AID in the scope of the EDP.

In the case of protected action frames directed to a protected AID Switch, an example of the simplest information elements carried may be based on the information elements illustrated in Figure 9 wherein field 915 carries the new value of the AID and field 925 carries the number of beacons (TBTTs) to wait before the effective change of the public identifier value.

Alternative formats of the information elements based on the format of frames 600-1 , 600-2, and 600-3 (fields generically referenced 615 to 640) are also possible to carry more information.

Figure 8 illustrates an example of frame formats of two new Information Elements enabling a non-AP station to change its AID. They may correspond to Information Elements (IE) as specified in section 9.4.2 in the IEEE 802.11-2020 standard.

A first dedicated IE may be specified for the AID value change procedure, referred to as AID IE, for example AID IE 800. As illustrated, the IE may be identified by an Element ID, for example Element ID 805. AID IE 800 further comprises a length field referenced 810 that indicates the number of octets in the IE 900, excluding Element ID field 805 and length field 810.

AID IE 800 further comprises an AID field 815 indicating the type of public identifiers that are to be changed and an AID switch counter field 820.

The AID switch counter field indicates the number of beacons (TBTTs) to wait before the effective change of the AIDS. Other embodiments are possible.

A second dedicated new AID Range IE 850, that is optional, may be specified to transmit information regarding an acceptable range of values for a given public identifier (the AID in the illustrated example). This information element can be used by the AP station prior to generating public identifier values to inform the non-AP stations about the allowable ranges of values for a given public identifier according to its internal identifier value plan. This reduces the probability for a non-AP station to generate conflicting public identifier values. This information element can be transmitted during an association I re-association procedure in the association response frame in addition to the initial AID value provided by the AP station during this association procedure.

As illustrated, AID IE 850 may be identified by Element ID 855, and an Element ID Extension, for example Element ID Extension 865 assigned to a specific value in the range [99,255] as specified in Table 9-92 of the IEEE 802.11-2020 standard.

In addition, AID IE 850 comprises a length field referenced 860 that indicates the number of octets in the AID IE 850, excluding Element ID field 855 and length field 860. AID IE 850 further comprises min value field 870 and max value field 875 that are used to provide an acceptable range of values in which the AID value to be used is to be chosen. These min and max values are stored by the non-AP station, to be used by the non-AP station each time an AID value is to be generated.

Naturally, other formats exist. In addition, an IE may transmit several ranges of values, for example for different types of non-AP stations.

Example of a hardware to carry out steps of the method of embodiments of the present disclosure

Figure 9 schematically illustrates an example of a communication device, that may correspond to any of the stations described by reference to Figure 1 , of a wireless network, configured to implement at least some embodiments of the present disclosure. The communication device, referenced 900, may preferably be a device such as a micro-computer, a workstation, or a light portable device. Communication device 900 may comprise a communication bus 913 to which may be connected:

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

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

- at least two communication interfaces 902 and 902’ 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 904 and 904’, respectively.

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

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 902 or 902’, in order to be stored in the memory 903 of communication device 900 before being executed.

In some embodiments, communication device 900 may be a programmable apparatus which uses software to implement embodiments of the disclosure. However, alternatively, some embodiments of the present disclosure 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 disclosure 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 disclosure.

Claims

1. A method for changing a value of a public identifier of a non-access point, non- AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the AP station: obtaining a new value for the public identifier; identifying a need for changing the obtained new value; generating a request for changing a new value for the public identifier, obtained by the non-AP station, corresponding to the new value obtained by the AP station; and transmitting the generated request to the non-AP station.

2. The method of claim 1 , wherein the determining a need for changing the obtained new value comprises determining that the obtained new value is assigned to another non-AP station.

3. The method of claim 1 or claim 2, wherein the determining a need for changing the obtained new value comprises determining that the obtained new value is in violation of at least one value assignment rule of the AP station.

4. The method of any one of claims 1 to 3, further comprising generating another new value for the public identifier.

5. The method of claim 4, wherein the generated request comprises the generated another new value.

6. The method of any one of claims 1 to 4, wherein the generated request comprises at least one item of information enabling the non-AP station to generate another new value for the public identifier.

7. The method of claim 6, wherein the at least one item of information comprises a range of values to which the another new value should belong, an offset for computing another new value from a new value, a number of iterations of a value generation process, or at least one initialization parameter of a pseudo-random number generator.

8. The method of claim 2 or of any one of claims 3 to 7 depending on claim 2, further comprising a forbidding of using the new value for the public identifier to transmit one or more messages to a non-AP station.

9. The method of claim 8, wherein using the new value for the public identifier to transmit one or more messages to a non-AP station is forbidden until another new value for the public identifier is determined.

10. The method of any one of claims 1 to 9, wherein the generated request is a request for changing the value of a plurality of public identifiers.

11. The method of any one of claims 1 to 10, wherein the generated request is a protected action frame.

12. The method of any one of claims 1 to 11 , wherein the generated request comprises an indication of a moment at which a new value for the public identifier is to be used.

13. The method of any one of claims 1 to 12, wherein the generated request comprises an item of information for identifying the public identifier.

14. A method for changing a value of a public identifier of a non-access point, non- AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the non-AP station: obtaining a new value for the public identifier; receiving a request for changing the obtained new value; and determining another new value for the public identifier based on at least one item of information of the received request.

15. The method of claim 14, further comprising determining whether the non-AP station is in a transition period and, if the non-AP station is not in a transition period, initiating a transition period.

16. The method of claim 14 or claim 15, further comprising generating and transmitting a response to the request for changing the new value for the public identifier, the response being indicative of the determination of the another new value.

17. The method of any one of claims 14 to 17, further comprising determining the moment at which the another new value is to be used, based on at least one item of information of the received request.

18. The method of any one of claims 1 to 17, wherein the public identifier is an Association Identifier, AID.

19. A method for changing a value of a public identifier of a non-access point, non- AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the AP station: obtaining a range of values for the value of the public identifier; generating an information element comprising a representation of the obtained range of values, the obtained range of values having to be used by the non-AP station each time a new value of the public identifier is to be determined; and transmitting the generated information element to the non-AP station.

20. A method for changing a value of a public identifier of a non-access point, non- AP, station associated with an access point, AP, station, the non-AP station and the AP station both using a same mechanism for determining a new value of the public identifier, the method comprising at the non-AP station: receiving, from the AP station, an information element comprising a representation of a range of values of the public identifier and storing the received range of values; and each time a value of the public identifier is needed, determining a value of the public identifier, the determined value belonging to the range of values stored.

21. The method of claim 19 or claim 20, wherein the public identifier is an Association Identifier, AID.

22. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing each of the steps of the method according to any one of claims 1 to 21 when loaded into and executed by the programmable apparatus.

23. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing each of the steps of the method according to any one of claims 1 to 21.

24. A communication device comprising a processing unit configured for carrying out each of the steps of the method according to any one of claims 1 to 21.