Dynamic configuration of station association parameters to improve user privacy and communication reliability

Abstract

[0010] At least one embodiment of a method for changing the value of a public identifier of a non-access point (non-AP) station associated with an access point (AP) station, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining, at the AP station, the new value of the public identifier; identifying a need to change the obtained new value; generating a request to change the new value of the public identifier obtained by the non-AP station, the new value corresponding to the new value obtained by the AP station; and transmitting the generated request to the non-AP station.

Description

[Technical Field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to wireless communications, and more particularly to user privacy during wireless communications. [Background technology]

[0002] The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims of this application, and are not admitted to be prior art by inclusion in this section.

[0003] Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems raised 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 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 numerous mechanisms for wireless communication between stations.

[0004] Today, the evolution of wireless systems has brought privacy concerns to the forefront, driven by user demands and requirements of the General Data Protection Regulation (GDPR). While the global wireless industry continues to improve wireless services and user experiences, it is faced with an increasing need to protect users' personally identifiable information from increasingly sophisticated user tracking and user profiling activities.

[0005] In particular, the medium access control (MAC) address of a user device constitutes part of the data that can be used to track this user. Indeed, a wireless network's access points (APs) can use the user's MAC address to monitor the location of the user's mobile device (tablet, laptop, mobile phone, etc.) without the user's consent. This is because the mobile phone is configured to discover surrounding access points to the wireless network. As the user moves, the mobile phone sends requests to determine whether there are any access points nearby, identifying the mobile phone sending these requests and including, in particular, the mobile phone's MAC address. Access points that hear these requests can respond. In the context of Wi-Fi networks (Wi-Fi is a trademark) defined by the IEEE 802.11 standard, this procedure is called a Probe Request / Response exchange.

[0006] Thus, even if 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 the user by reconstructing the user's trajectory from the access points to which the user's mobile phone transmitted its MAC address. Additionally, if the mobile phone is associated with one of the access points (i.e., the user is connected to the associated Wi-Fi network through that access point) and the user has previously provided personal identifying information (such as name or address), the access point may have recorded the phone's MAC address in its database in association with the identifying information. Thus, even if the user is not connected to a Wi-Fi network, this identifying information can be recovered by comparing the MAC address included in the Probe Request with the MAC addresses used for previous associations.

[0007] In the context of Wi-Fi networks, the IEEE 802.11 Working Group has proposed a solution to limit the risk of users being tracked. The solution is to dynamically change the MAC address of user devices. This mechanism is called the Randomize and Change MAC (RCM) procedure. It was first introduced as a privacy-enhancing feature in the 802.11aq Pre-Association Service Discovery Task Group and was eventually included in the standard IEEE Std 802.11-2020. It involves periodically changing the MAC address of non-AP stations (i.e., stations that are not access points) to a random value while they are not associated with the network (or, equivalently, with an access point). Non-AP stations may construct randomized MAC addresses from a locally administered address space, as defined in IEEE Std 802®-2014 and IEEE Std 802c™-2017.

[0008] More specifically, a new Management Information Base (MIB) variable that can be controlled by an external management entity is specified. This variable is called "dot11MACPrivacyActivated". When dot11MACPrivacyActivated is set to "true", non-AP stations can apply certain mechanisms to enforce privacy at the MAC level, including RCM.

[0009] A device's MAC address (EUI-48 address) is an Extended Unique Identifier (EUI) consisting of 48 bits. It can be universally or locally administered. Universally administered addresses are uniquely assigned to a device by its manufacturer. Conversely, locally administered addresses are assigned to a device by software or a network administrator, replacing a physically burned-in address. The penultimate bit of the first octet of a MAC address, i.e., the seventh bit of the first octet of the address, also known as the "U / L bit" (for "universal / local bit"), indicates whether it is universally administered (when set to 0) or locally administered (when set to 1). The least significant bit of the first octet of the MAC address, i.e., the eighth bit of the first octet of the address, is also called the "I / G bit" (for "Individual / Group bit") and indicates whether the frame is being sent to only one receiving device (when set to 0, it indicates unicast transmission) or to multiple devices (when set to 1, it indicates multicast transmission). When the RCM mechanism operates in a non-AP station, the MAC address of the non-AP station is changed randomly (e.g., periodically). 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 using a pseudorandom function (PRF). When RCM operates, counters in all sequence number spaces used to identify data frames (MAC Service Data Unit (MSDU) packets or Management MAC Protocol Data Unit (MMPDU) frames) must be reset, and the non-AP station also resets the seed used in the PHY DATA scrambler on the next physical layer protocol data unit (PPDU) to be transmitted. Some RCM implementations propose a mechanism for non-AP stations (called STAs) associated with an AP to generate new MAC addresses without exchanging them.

[0010] The inventors have realised that the MAC address is not the only identifier that is clearly present in frames exchanged between stations in a wireless LAN, and that an eavesdropper may capture other elements that uniquely identify the originating station.

[0011] In particular, one of these unique identifiers is the Association Identifier (AID). This identifier, assigned by the access point upon association with the station, is communicated in the Association Response frame sent by the access point in the final frame exchange of the association process. The AID is a locally unique 16-bit identifier. 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 do not share the same AID value.

[0012] The AID was initially introduced to reduce 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 place of the (48-bit) MAC address when the AP indicates in a traffic indication message that it has some traffic waiting to be transmitted to a station in a power saving state. However, the range of values ​​for the AID selection is, of course, much shorter. Furthermore, in the IEEE 802.11 series, the AID for a station is limited to a subrange [1;2007] of 11-bit identifiers (instead of 2045 possible values), with other values ​​reserved for identifying some groups of stations or for identifying specific signaling (unallocated resources, resources for random access, etc.).

[0013] Therefore, when changing the MAC address to maintain user privacy and avoid tracking, it is recommended to also change the AID, since if the AID remains the same, it is very easy for an eavesdropper to correlate the newly changed MAC address with the old MAC address. To this extent, the IEEE 802.11bi requirements document includes a requirement mandating that stations define a mechanism for changing their AID address.

[0014] While recent solutions have been proposed to solve this problem that rely on the calculation and allocation of new AIDs by the AP and require systematic requests to replace newly generated AIDs, there is a continuing need to improve user privacy and communication efficiency. Summary of the Invention

[0015] The present disclosure is designed to address one or more of the aforementioned concerns.

[0016] In this context, a solution is provided that allows dynamic configuration of the association parameters of stations in order to improve user privacy and reliability of communications.

[0017] This disclosure proposes a mechanism to allow a non-AP station (STA) to generate its new AID when its MAC address changes, and also proposes a mechanism for an AP station to resolve potential collision issues before such collisions actually occur.

[0018] According to a first aspect of the present 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining a new value for the public identifier; Identifying the need to change the obtained new value; generating a request to change a new value of 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.

[0019] Thus, the method of the present disclosure allows for efficient changing of the values ​​of one or more public identifiers to improve user privacy, communication reliability, and communication resource usage. More specifically, user privacy may be improved by allowing a station to change its AID when its MAC address changes without interrupting ongoing connections while associated. In most cases, there is no (or very little) message exchange, so AID changes cannot be easily detected.

[0020] According to some embodiments, determining the need to change the obtained new value includes determining that the obtained new value is assigned to another non-AP station.

[0021] Further, according to some embodiments, determining the need to change the obtained new value includes determining that the obtained new value violates at least one value assignment rule of the AP station.

[0022] According to some further embodiments, the method further comprises generating another new value for the public identifier.

[0023] Further, according to some embodiments, the generated request includes the generated different new value.

[0024] Further, according to some embodiments, the generated request includes at least one item of information that enables the non-AP station to generate another new value for the public identifier.

[0025] Furthermore, according to some embodiments, at least one item of information includes a range of values ​​to which the other new value should belong, an offset for calculating the other new value from the new value, a number of iterations of the value generation process, or at least one initialization parameter of a pseudo-random number generator.

[0026] Additionally, according to some embodiments, the method further includes prohibiting transmission of one or more messages to non-AP stations using the new value for the public identifier.

[0027] Further, according to some embodiments, use of the new value for the public identifier to transmit one or more messages to a non-AP station is prohibited until another new value for the public identifier is determined.

[0028] Further, according to some embodiments, the generated request is a request to change the values ​​of a number of public identifiers.

[0029] Furthermore, according to some embodiments, the generated request is a protected action frame.

[0030] Furthermore, according to some embodiments, the generated request includes an indication of the moment at which a new value for the public identifier should be used.

[0031] Furthermore, according to some embodiments, the generated request includes an item of information identifying the public identifier.

[0032] According to a second aspect of the present 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining a new value for the public identifier; receiving a request to change the obtained new value; and determining a different new value for the public identifier based on at least one item of information in the received request.

[0033] Thus, the method of the present disclosure allows for efficient changing of the values ​​of one or more public identifiers to improve user privacy, communication reliability, and communication resource usage. More specifically, user privacy may be improved by allowing a station to change its AID when its MAC address changes without interrupting ongoing connections while associated. In most cases, there is no (or very little) message exchange, so AID changes cannot be easily detected.

[0034] According to some embodiments, the method further includes 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.

[0035] According to some further embodiments, the method further comprises generating and transmitting a response to the request to change the new value for the public identifier, the response indicating the determination of the different new value.

[0036] According to further embodiments, the method further comprises determining, based on at least one item of information of the received request, the moment at which said further new value should be used.

[0037] Furthermore, according to some embodiments, the public identifier is an association identifier (AID).

[0038] According to a third aspect of the present 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: at the AP station, obtaining a value range for the value of the public identifier; generating an information element including a representation of the obtained value range, the value range 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.

[0039] According to a fourth aspect of the present disclosure, there is provided a method for changing a public identifier value of a non-access point (non-AP) station associated with an access point (AP) station, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: receiving, at the non-AP station, from the AP station, an information element including a representation of a range of values ​​of the public identifier, storing the received range of values; and determining, each time a value of the public identifier is needed, a value of the public identifier that belongs to the stored range of values.

[0040] According to some embodiments, the public identifier is an association identifier (AID).

[0041] The third and fourth aspects of the present disclosure allow for improved use of communication resources, in particular reducing the number of messages exchanged and the risk of conflicting public identifier values.

[0042] According to another aspect of the present disclosure, there is provided a device having a processing unit configured to perform each of the steps of the above-described method.

[0043] This aspect of the disclosure has similar advantages to those discussed above.

[0044] At least a portion of the methods according to the present 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, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally 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.

[0045] The solutions of the present disclosure can be implemented in software, and therefore can be embodied as computer-readable code for provision to a programmable apparatus on any suitable carrier medium. The tangible carrier medium can include a storage medium such as a floppy disk, CD-ROM, hard disk drive, magnetic tape device, or solid-state memory device. The transient carrier medium can include a signal such as an electric, electronic, optical, acoustic, magnetic, or electromagnetic signal, e.g., a microwave or RF signal. [Brief explanation of the drawings]

[0046] 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 symbols refer to similar elements and in which: [Figure 1] FIG. 1 illustrates an example of a network system in which some embodiments of the present disclosure may be implemented. [Figure 2a] 1 illustrates a first example sequence of steps for operating a procedure for changing the public identifier of a non-AP station associated with an AP station, according to some embodiments of the present disclosure. [Figure 2b] 2a, illustrating an example of a sequence of steps in which a change in a public identifier is initiated by an AP, according to some embodiments of the present disclosure. FIG. [Figure 3] FIG. 10 illustrates a second example sequence of steps for operating a procedure for changing the public identifier of a non-AP station associated with an AP station, according to some embodiments of the present disclosure. [Figure 4] 10A-10C illustrate example steps performed by an AP station to determine a new public identifier value to be used, in accordance with some embodiments of the present disclosure. [Figure 5] 10 illustrates example steps performed by a non-AP station upon receiving a frame requesting a change in the value of one or more public identifiers. [Figure 6] FIG. 10 is a diagram illustrating an example of the format of a change request frame. [Figure 7] FIG. 10 is a diagram illustrating an example of the format of a change response frame. [Figure 8] 10A and 10B are diagrams illustrating example frame formats for two information elements that allow a non-AP station to change its AID. [Figure 9] FIG. 1 illustrates an example of a communication device of a wireless network configured to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0047] According to some embodiments of the present disclosure, the values ​​of one or more specific station association parameters may be changed after the values ​​of a set of station association parameters that includes the specific parameter have been set. Such a change may occur, for example, if values ​​conflict. Such specific parameters may be identifiers, particularly public identifiers, also known as obfuscated, blind, hidden, or over-the-air (OTA) identifiers, i.e., parameters whose values ​​are explicitly transmitted in different fields of frames exchanged between a station and its associated access point. For clarity, the following description will focus on public identifiers, which are typically part of frame headers and may change over time to prevent eavesdroppers from tracking the station's activities and movements, while private identifiers (also known as device identifiers (device IDs)) may remain the same and secret for much longer periods of time.

[0048] According to some embodiments, new values ​​for one or more public identifiers are determined independently at the AP station and the non-AP station using the same mechanism to provide the same result, and the AP station checks whether the new value can be used reliably (e.g., whether it conflicts 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 other new value. The AP station may provide this other new value to the non-AP station, or it may provide the non-AP station with an item of information that enables the non-AP station to generate this value.

[0049] FIG. 1 illustrates an example of a network system in which some embodiments of the present disclosure may be implemented.

[0050] For illustrative purposes, FIG. 1 depicts an 802.11 network (i.e., Wi-Fi network) system 100 including 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. The AP station 105 provides wireless connectivity between the non-AP stations 110a, 110b, and 110c and a wider network, such as the Internet (not shown). The connection of one of the non-AP stations 110a, 110b, and 110c to the AP 105 may be performed by a standardized process called association. Once the non-AP station is associated with the AP station, the non-AP station can transmit data to the network and receive data from the network via the AP station.

[0051] The AP station 105 may include, be implemented as, or be 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), Wireless Router, Wireless Transceiver, Basic Service Set (BSS), Enhanced Service Set (ESS), Radio Base Station (RBS), or some other terminology. It may be a standalone product or may be integrated into a device, for example, in a Broadband Remote Access Server (BRAS).

[0052] Non-AP stations 110a, 110b, and / or 110c may be, have, be implemented as, or be known as a subscriber station, subscriber unit, mobile station (MS), remote station, remote terminal, user terminal (UT), user agent, user device, user equipment (UE), user station (STA), or some other terminology. In some implementations, a non-AP station may be or have a cellular telephone, a cordless telephone, a session initiation protocol (SIP) telephone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless connectivity capabilities, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a telephone (e.g., a cellular telephone or 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 configured to communicate via a wireless or wired medium. In some aspects, some of the non-AP stations 110a, 110b, and 110c may be wireless nodes. Such wireless nodes 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.

[0053] The AP station 105 manages a set of stations that simultaneously plan access to the wireless medium for communication. All stations (AP station 105 and non-AP stations 110a, 110b, and 110c) form a service set that may be called a basic service set (BSS) (although other terminology may be used). The AP station 105 may manage more than one BSS; therefore, each BSS is uniquely identified by a specific basic service set identifier (BSSID) and is managed by a separate virtual AP station implemented in the physical AP station 105.

[0054] Example Use Case FIG. 2a illustrates a first example sequence of steps for operating a procedure for changing the public identifier (e.g., AID or over-the-air (OTA) MAC address) of a non-AP station associated with an AP station, according to some embodiments of the present disclosure.

[0055] The public identifier change procedure essentially includes two phases: a first phase in which new public identifier values ​​for one or more non-AP stations are calculated and the AP station and one or more non-AP stations identify a valid change start time; and a second phase corresponding to the valid change of the public identifier values ​​of these non-AP stations. The valid change of the public identifier value begins at a time called the SERCPI change start time and ends at the latest at a time called the maximum SERCPI change end time, from which the newly calculated public identifier value is used for data exchange between the considered non-AP stations and their associated AP stations. Here, SERCPI stands for Seamless Enhanced Randomized and Changing Public Identifier. Thus, during the change procedure, each considered non-AP station changes its public identifier value from a current value (e.g., AID(n) or @MAC(n)) to a new value (AID(n+1) or @MAC(n+1)). During the transition period, both the current and new public identifier values ​​are valid.

[0056] The new public identifier value must be calculated by the non-AP stations and AP stations being considered.

[0057] At the SERCPI Change Start Time, the non-AP stations and AP stations initiate a valid change procedure, and at the Max SERCPI Change End Time (or earlier), they modify their respective registries by updating the value of the public identifier of each of the considered non-AP stations from the old value to the new value for each public identifier.

[0058] In other words, at the beginning of the transition period, both the AP and the non-AP STAs initiate changes to the public identifiers for the changing non-AP STAs.

[0059] How the AP station and non-AP station initially determine a new public identifier value to be used, e.g., a new MAC address or AID, is beyond the scope of this disclosure. The AP station and non-AP station may, for example, store a list of identifier values, and each time a change in the public identifier value must be performed, the next value in the list is selected as the identifier value. However, such an embodiment may lead to security issues if a third party gains access to the list. Alternatively, the same function may be used by the non-AP station and the AP station with which it is associated to determine, for example, the index of the next identifier value to use in a predetermined list of identifier values. This index may advantageously be determined randomly.

[0060] Other public identifier selection methods may be used, such as based on the use of a pseudorandom function (PRF) with the same input parameters. Thus, both the non-AP station and the AP station with which it is associated obtain the same values ​​for their public identifiers (e.g., AID(n+1) and / or @MAC(n+1)).

[0061] 2a and with reference to FIG. 1, there is shown a change procedure initiated by AP station 105 and directed to non-AP stations 110a and 110b of the BSS for which the initiation procedure is being performed. In other words, according to these embodiments, AP station 105 indicates to non-AP stations 110a and 110b for which the initiation procedure is being performed that they should change their respective public identifier values, and non-AP stations 110a and 110b simultaneously (at a SERCPI change start time) start changing their respective public identifier values.

[0062] For purposes 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 issues due to imperfect synchronization of the non-AP and AP station clocks).

[0063] According to the IEEE 802.11 standard, an AP station periodically (every TBTT) transmits a beacon frame, which is a management frame containing information about the network, to non-AP stations in the BSS. Therefore, the beacon frame may include a field for storing an item of information for indicating the SERCPI change date. For example, such an item of information may represent the value of a counter that is decremented in each successive beacon frame transmitted by the AP station to indicate that a change in the public identifier value is in progress and indicate the SERCPI change date. For example, each beacon frame transmitted by the AP station 105 to the non-AP stations 110a and 110b in the BSS may include an information element providing the SERCPI maximum transition period. The counter is initially set to a value corresponding to when the change must be made (e.g., an initial value k may be an integer indicating that the change must be made in (k+1) TBTTs), and may be decremented by one unit with each subsequent beacon frame transmission. When the counter reaches the value 0, the change must be made. Therefore, all transmissions of frames following a beacon frame associated with a counter equal to 0 must be performed with the new public identifier value. In another implementation, the counter is initialized to its maximum value and repeatedly decrements by one unit with each subsequent beacon transmission (returning to its maximum value upon reaching 0). When the counter reaches a predetermined value, which may be different for each non-AP station associated with the AP station, a change must be acted upon by the corresponding non-AP station.

[0064] 2a, non-AP stations 110a and 110b initially receive a beacon frame containing a counter, designated a SERCPI change counter, set to a value k (step 200). This indicates that non-AP stations 110a and 110b (for which initiation procedures have been performed) must change the value of their respective public identifiers at a time corresponding to k+1 TBTTs. The next beacon frame, with a SERCPI change counter having a value (k-1), is then transmitted from AP station 105 to non-AP stations 110a and 110b (step 205). After transmitting (k+1) beacon frames, AP station 105 transmits a beacon frame to non-AP stations 110a and 110b with a SERCPI change counter equal to 0, indicating that a change in the value of each public identifier of non-AP stations 110a and 110b must be initiated (step 210). The new public identifier values ​​for non-AP stations 110a and 110b should be determined at any time between steps 200 and 210, i.e., after requesting a public identifier change and before initiating the effective public identifier change.

[0065] All transmissions between the AP station 105 and the non-AP stations 110a and 110b that occur after the maximum SERCPI change end time 615 should be performed using the new public identifiers of the non-AP stations 110a and 110b.

[0066] The transition duration (referenced at 220) between the SERCPI change start time 210 and the maximum SERCPI change end time 215 advantageously allows AP stations and non-AP stations to transmit frames addressed with the old public identifier value (e.g., AID(n) or @MAC(n)) buffered in their transmit buffers. This allows public identifier values ​​to change without interrupting ongoing transmissions, allowing frequent public identifier changes to not negatively impact performance.

[0067] 2a at reference numeral 225, the AP 105 may initiate a public identifier change by sending a public identifier change request to the non-AP station 110a and / or 110b, and then confirm the decision of another new public identifier in a public identifier change response (referenced at 230). By way of illustration, such a request for another new public identifier value may be required if it is determined that the new public identifier value to be used conflicts with another public identifier value, e.g., a public identifier used by another non-AP station. This may particularly occur when the public identifier under consideration is an AID, since the number of possible values ​​of the AID is significantly smaller compared to the number of possible MAC address values.

[0068]

[0033] Figure 2b illustrates a specific case of the example shown in Figure 2a, illustrating an example sequence of steps in which a public identifier change is initiated by an AP station, as opposed to the example of Figure 3 in which the public identifier change procedure may be initiated by a non-AP station 110a. For clarity, the same reference numerals are used in Figure 2b as are used in Figure 2a.

[0069] 2b, AP station 105 detects a conflict only in the AID of non-AP station 110a (STA2) and selects a different new public identifier value (in this example, a different new AID value) to be sent to the non-AP station to be used instead of the new public identifier value calculated by the non-AP station. Each non-AP station (STA1 and STA2) locally calculates a new public identifier value (STA1: calculates @MAC1 and AID1, STA2: calculates @MAC2 and AID2). The AP station performs the same operation and calculates the same values ​​(STA's @MAC and AID calculation); · If the AP station detects a conflict (Detection of conflict in AID2 of STA2), it generates a new public identifier value (Selection of new AID2' for STA2) and sends it to the involved non-AP station (STA2 in this example), which uses it to replace the locally calculated new public identifier value (Setting of AID2' of STA2); At the end of the transition period, all non-AP stations (STAs) and AP stations use the new public identifier value.

[0070] This example describes a mechanism for generating a new AID for an associated STA upon modification of its OTA MAC address. The described mechanism allows for the generation of a new AID for an associated STA without message exchange in most scenarios. Resolution of potential AID conflicts by the AP is also described.

[0071] Advantageously, the AP can provide the STA with a new AID regardless of the source of the potential conflict (detected before or even after the valid use of the new AID).

[0072] 4 and 5 show example steps for requesting and setting other new public identifier values, particularly in the case of a conflict or if the new public identifier value to be used does not meet the required conditions.

[0073] It should be noted that although the embodiment described with reference to Figures 2a and 2b uses beacon frames, other types of frames may be used as well.

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

[0075] According to an alternative embodiment shown in FIG. 3, the public identifier change procedure may be initiated by the non-AP station 110a.

[0076] As shown, a request to change the value of the public identifier 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 a "SERCPI change request," e.g., "SERCPI change request" 300. This request may include an indication of the SERCPI change date and the duration of the SERCPI maximum transition period.

[0077] For illustrative purposes, it may include a field indicating the date of the next public identifier change, e.g., in terms of TBTT. For example, a value set to k may indicate that the change must be performed in (k+1) TBTTs, while a value set to 0 may indicate that the next public identifier should be applied immediately. Thus, all message transmissions following the transmission of a beacon frame associated with a counter equal to 0 should be performed by using the new public identifier.

[0078] The SERCPI Change Request frame may include a field indicating the maximum duration of the transition period, at the expiration of which both AP and non-AP stations should use the new public identifier value.

[0079] As shown, in response to the request to change the public identifier, the AP station 105 may acknowledge receipt of the request and agree to change the value of the public identifier of the non-AP station 110a, for example, by sending a "SERCPI change response" to the non-AP station 110a (step 305).

[0080] According to some embodiments, the non-AP station 110a may execute a counter (e.g., a counter equal to k or (k-1)) reflecting the SERCPI change time, here expressed as a number of TBTTs, when transmitting a request to change its public identifier. Each time a new beacon frame is received from the AP station 105, the counter may be decremented by one unit. The public identifier change is initiated when the non-AP station 110a receives a beacon frame from the AP station 105 corresponding to the SERCPI time, i.e., when the counter reaches the value zero (step 310). At the end of the transition period (reference numeral 320), the new public identifier of the non-AP station 110a is valid (at the start of the next TBTT). This means that all transmissions after the transmission of the beacon frame corresponding to the maximum SERCPI change end time (step 315) will be performed using the new public identifier value.

[0081] Note that the new public identifier value for non-AP station 110a should be determined any time between steps 300 and 310, i.e., after requesting a public identifier change and before initiating the effective public identifier change.

[0082] Although the examples described with reference to Figures 2a, 2b, and 3 are based on the use of beacon frames and TBTT, other embodiments exist. Indeed, according to some embodiments, it may be necessary to provide the non-AP station and the AP station with which they are associated with a method for sharing an indication of when a change should be made and for counting the timing. For example, as long as the non-AP station and the AP station have access to the same clock or can synchronize their clocks, they can transmit the actual date and time. The change in the value of the public identifier may be performed periodically, at a predetermined time, or on demand.

[0083] 2a or 2b, an AP station may request that only one non-AP station change the value of its public identifier, and to that end, a SERCPI change request similar to that described with reference to FIG. 3 may be sent from the AP station to the considered non-AP station.

[0084] 3 at reference numeral 325, the AP 105 may initiate a public identifier change by sending a public identifier change request to the non-AP station 110a, which then confirms the determination of another new public identifier value in a public identifier change response (referenced at 330). As mentioned above, such a request for another new public identifier value may be necessary if it is determined that the new public identifier value to be used conflicts with another public identifier value, e.g., a public identifier value used by another non-AP station.

[0085] Example of generating and processing a change request 4 shows example steps performed by an AP station to determine a new public identifier value to be used, according to some embodiments of the present disclosure. Such steps may be performed between steps 225 and 230 of FIG. 2a or 2b, or between steps 325 and 330 of FIG. 3, to determine that another new public identifier value is needed.

[0086] After determining association parameter values ​​that enable the exchange of data between the AP station and the non-AP station (step 400), the AP station determines that one or more of these parameter values, here representing public identifier values, need to be changed, e.g., for user privacy reasons (step 405). Illustratively, this determination may be based on a previously negotiated frequency of change of these parameter values, or, according to the examples shown in Figures 2a, 2b, and 3, in response to transmitting a beacon indicating that a change will be made.

[0087] According to a particular embodiment, the AP station and the non-AP station generate the same value for one or more public identifiers, e.g., AIDs, at approximately the same time (i.e., the AP station and the non-AP station generate the same value locally using the same shared functions and parameters). This embodiment allows for avoiding the exchange of additional messages between the AP station and the non-AP station, thus increasing privacy and reducing overhead.

[0088] Because the number of different possible values ​​for some public identifiers may be reduced compared to the number of non-AP stations, the probability of randomly generating a value that has already been assigned to another non-AP station may be significant. Therefore, a conflict avoidance mechanism should preferably be used. Thus, the AP station may determine whether one or more newly generated public identifier values ​​cause a conflict with an existing value of the same public identifier for another non-AP station associated with the AP station. Because the AP station knows the public identifier values ​​assigned to each of its associated stations, it can determine whether a newly generated value has already been assigned to another station.

[0089] Alternatively or additionally, the AP station may determine whether the newly generated public identifier value complies with an existing identifier value allocation plan, and the AP may decide to assign public identifier values ​​to public stations according to the predetermined plan. For example, the AP station may divide the AID plan into several separate ranges corresponding to different types or profiles of devices. This allows the AP station to group non-AP stations by type in one request (such as an NFRP trigger frame that polls non-AP stations using a range of AIDs).

[0090] If the AP station determines that there is no conflict between the new public identifier value and the previously assigned public identifier value, the new public identifier value is used without requiring an additional frame exchange.

[0091] Conversely, if the AP determines that a conflict has occurred, another new public identifier value (or multiple other new public identifier values) is selected or determined (step 415). Illustratively, this step may include repeating the generation operation until the generated public identifier value no longer conflicts with a previously assigned public identifier value. In this embodiment, pseudo-random generation may be performed using the previously conflicting value as a varying parameter in the pseudo-random generation process. The AP station counts the number of times to repeat the process in a dedicated retry counter, which may be transmitted as a pseudo-random generation parameter, as described with reference numerals 620-1 and 620-3 in FIG. 6 .

[0092] According to another embodiment, the AP station selects the next allowed value for the public identifier (e.g., by increasing the value of the generated public identifier value modulo the allowed range for this non-AP station until a non-conflicting value is obtained). In this embodiment, the increase value (offset) can be transmitted in a parameter field such as parameter field 620-1 or 620-3 in FIG. 6. In this embodiment, the non-AP station applies the corresponding offset to its current generated value upon reception of the corresponding frame to obtain a new non-conflicting value.

[0093] In yet another embodiment, the AP station selects the new public identifier value by any other method and simply provides the resulting value in a field value such as field value 640-2 in Figure 6. In this embodiment, the non-AP station simply replaces its current generated public identifier value with the new public identifier value received in the corresponding frame.

[0094] Because the AP station determines that a public identifier value generated by both the AP station and the non-AP station conflicts with a public identifier value assigned to another non-AP station, the conflicting public identifier value is preferably placed in a quarantine list of public identifiers that should not be used until the conflict is resolved (step 420). This means that the AP station will not transmit frames containing the conflicting public identifier value (not only to the non-AP station whose public identifier value is being changed, but also to other non-AP stations already using this public identifier value) until the conflict is no longer resolved.

[0095] The AP station then creates an identifier change request frame (e.g., frame 600-1, 600-2, or 600-3 in FIG. 6) to indicate to the non-AP station that generated the conflicting public identifier value that it should change the latter according to the parameters transmitted by the AP station.

[0096] When public identifier values ​​are generated by the AP station and the non-AP station, the AP station may indicate an identifier index corresponding to the public identifier, allowing the non-AP station to identify the public identifier. Examples of identifier indexes can be seen in the table below (of course, this list of identifiers and associated index values ​​is provided merely as an example, not a limitation): TIFF2026506834000002.tif108130

[0097] According to some embodiments, if the AP station determines that the public identifier value conflicts with its internal public identifier value plan, the AP station may indicate an acceptable range for the generated public identifier value, for example, by setting minimum and maximum value fields (e.g., min value field 625-1 and max value field 630-1 in FIG. 6).

[0098] After creating a public identifier change request frame, the AP station transmits the frame to the non-AP station to change its corresponding public identifier value. Then, after receiving an acknowledgment of the request frame or an optional public identifier change response (e.g., public identifier change response 700 of FIG. 7), the AP station removes the conflicting identifier value from the quarantine list (so that it may be used again without conflict), and the newly generated public identifier value is considered valid.

[0099] According to some embodiments, steps 405-425 are performed before the SERCPI change end time (e.g., before the SERCPI change end time 215 in FIG. 2a or FIG. 2b, or before the SERCPI change end time 315 in FIG. 3) so that non-AP stations directly consider potential new public identifier values ​​and avoid collisions.

[0100] According to some embodiments, an AP station may indicate a new maximum SERCPI change end time if it determines that a conflict has occurred. Illustratively, it may indicate a new maximum SERCPI change end time 215 or 315 by indicating a new value in a switch count field, such as switch count field 635-1, 635-2, or 635-3 in FIG. 6, which indicates the number of beacons or TBTTs to wait before validly using the identifier value of the identifier change request 225 or 325. This allows the AP station to provide more time for non-AP stations to change their public identifier value to the public identifier value to be used. This may be particularly useful in cases of frequent identifier changes in a heavily loaded network (causing delays in medium access for transmissions) or when the request sent by the AP station requires additional calculations (e.g., new pseudo-random generation) on the station side.

[0101] According to more specific embodiments, if the AP station determines that multiple public identifier values ​​conflict with values ​​already assigned to non-AP stations, it can repeat steps 415-425 for each of the conflicting public identifier values. In such embodiments, additional signaling providing a list of public identifiers whose values ​​should be regenerated by a given non-AP station may be provided in the modification request frame, e.g., in identifier index field 615-1, 615-2, or 615-3 of modification request frame 600-1, 600-2, or 600-3 of FIG. 6, respectively, allowing the AP station to send a single request instead of a request for each identifier value. In these embodiments, the encoding of the identifier index field differs. It may be a bitmap in which each bit corresponds to a public identifier (e.g., 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 values ​​corresponding to the public identifiers may be the identifier indexes shown in the previous table.

[0102] FIG. 5 illustrates example steps performed by a non-AP station in response to receiving a frame requesting a change in the value of one or more public identifiers.

[0103] After determining association parameter values ​​that enable the exchange of data between the AP station and the 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 FIG. 6) from the AP station with which it is associated (step 505).

[0104] A test is then performed to determine if the non-AP station is in a transition period, ie, the period between the SERCPI change start time and the SERCPI change end time (step 410).

[0105] If the non-AP station is in a transition period, the non-AP station is in the process of changing the values ​​of one or more of its public identifiers. Thus, in response to receiving a request frame (e.g., request frame 600-1, 600-2, or 600-3 of FIG. 6), the non-AP station updates its internal transition parameters (i.e., parameters used to generate values ​​of public identifiers) according to the parameters received in the request frame, e.g., in fields 620-1 or 620-3 of FIG. 6 (step 420). Conversely, if the non-AP station is not in a transition period, the non-AP station begins a new transition period (step 415) for generating values ​​of all public identifiers before updating its internal transition parameters (step 420).

[0106] The non-AP station then generates one or more public identifier values ​​to be changed using the new transition parameters, for example, according to various embodiments described with reference to FIG. 4. In some particular embodiments, the AP station provides the new public identifier values, and the non-AP station simply replaces its newly generated public identifier values ​​with those provided by the AP station. According to some embodiments, the modification request frame (e.g., request frame 225 of FIG. 2a or 2b or request frame 325 of FIG. 3) and the modification response frame (e.g., modification response frame 230 of FIG. 2a or 2b or modification response frame 330 of FIG. 3) are protected action frames, and thus the new values ​​are protected (i.e., encrypted).

[0107] Example of a change request and change response frame FIG. 6 shows an example of the format of a change request frame, and FIG. 7 shows an example of the format of a change request frame.

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

[0109] As shown, each of the frames referenced 600-1, 600-2, 600-3, and 700 includes a category field referenced 605-1, 605-2, 605-3, and 705, respectively, which indicates that the purpose of the frame is to change the value of the public identifier. Table 9-51 of the IEEE 802.11-2020 standard may be modified to configure specific categories, for example, by adding the following category values: TIFF2026506834000003.tif29130

[0110] Additionally, 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, which may be a single-bit field and may immediately follow the category field. The values ​​of the Change ID Action field may be defined according to the following table, which may be inserted at the end of paragraph "9.6 Action frame format details" of the IEEE 802.11-2020 standard: TIFF2026506834000004.tif39139

[0111] To further illustrate, a value of the identifier action field set to 6 may correspond to a public identifier change request, and a value of the identifier action field set to 7 may correspond to a public identifier change response.

[0112] As shown, each of the frames referenced 600-1, 600-2, and 600-3 includes an identifier index field referenced 615-1, 615-2, and 615-3, respectively, to indicate the public identifier whose value should be changed.

[0113] Additionally, each of frames 600-1, 600-2, and 600-3 includes a field for providing information to non-AP stations to enable them to obtain the value of the public identifier to be used.

[0114] For illustrative purposes, frame 600-1 includes 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, the parameter field 620-1 is used to transmit the 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, the parameter field 620-1 is used to transmit an increment value (offset) used to obtain the public identifier value to be used from a previously generated public identifier value. According to still some embodiments, the min value field 625-1 and the max value field 630-1 are used to provide an allowable range of values ​​from which the public identifier value to be used should be selected. Such a range of values ​​may be obtained from the AP station's internal identifier value plan. The items of information provided in fields 620-1 through 630-1 enable a non-AP station to generate new values ​​for one or more public identifiers referenced in the identifier index field 615-1. Finally, the switch count field 635-1 may indicate the number of beacons or TBTTs to wait before validly using the new public identifier value.

[0115] Frame 600-2 has a switch count field 635-2 and a value field 640-2. Similar to switch count field 635-1, switch count field 635-2 may indicate the number of beacons or TBTTs to wait before valid use of the new public identifier value provided in value field 640-2 (generated by the AP station).

[0116] To further illustrate, frame 600-3 includes a parameter field 620-3 and a switch count field 635-3. The parameter field 620-3 is similar to the parameter field 620-1. According to some embodiments, the parameter field 620-3 is used to transmit the 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, the parameter field 620-3 is used to transmit an increment value (offset) used to obtain the public identifier value to be used from a previously generated public identifier value. Similar to the switch count field 635-1, the switch count field 635-3 may indicate the number of beacons or TBTTs to wait before valid use of the new public identifier value.

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

[0118] The following table provides an example of the encoding of the protected action field for these new EDP Protected Action frames when regenerating the public identifier value: TIFF2026506834000005.tif48139

[0119] Furthermore, according to some particular embodiments, the protected action frame is adapted per identifier. For simplicity, the following table shows the encoding of the corresponding protected action field for such a protected action frame for a change of AID in the range of EDP: TIFF2026506834000006.tif48139

[0120] In the case of a protected action frame where a protected AID Switch is intended, the simplest example of information elements to be carried may be based on the information elements shown in Figure 9, where field 915 carries the new value of the AID and field 925 carries the number of beacons (TBTT) to wait before effectively changing the value of the public identifier.

[0121] Alternate formats for information elements based on the format of frames 600-1, 600-2, and 600-3 (fields collectively designated 615-640) are also capable of carrying more information.

[0122] Figure 8 shows example frame formats for two new information elements that allow a non-AP station to change its AID, which may correspond to the information elements (IEs) specified in Section 9.4.2 of the IEEE 802.11-2020 standard.

[0123] A first dedicated IE may be designated for the AID value change procedure, called an AID IE, e.g., AID IE 800. As shown, the IE may be identified by an Element ID, e.g., Element ID 805. The AID IE 800 further has a length field, referenced 810, indicating the number of octets in the IE 900, excluding the Element ID field 805 and the length field 810.

[0124] The AID IE 800 further includes an AID field 815 that indicates the type of public identifier to be changed, and an AID switch counter field 820 .

[0125] The AID switch counter field indicates the number of beacons (TBTT) to wait before a valid change of AID. Other implementations are possible.

[0126] An optional second dedicated new AID Range IE 850 may be specified to transmit information regarding the allowable range of values ​​for a given public identifier (AID in the illustrated example). This information element may be used by an AP station before generating a public identifier value to inform non-AP stations about the allowable range of values ​​for the given public identifier according to its internal identifier value plan. This reduces the probability that a non-AP station will generate conflicting public identifier values. This information element may be transmitted in an association response frame during the association / re-association procedure in addition to the initial AID value provided by the AP station during the association procedure.

[0127] As shown, the AID IE 850 may be identified by an Element ID 855, an Element ID Extension, e.g., an Element ID Extension 865 assigned to a specific value within the range [99,255] specified in Table 9-92 of the IEEE 802.11-2020 standard.

[0128] Additionally, the AID IE 850 has a length field referenced at 860 that indicates the number of octets in the AID IE 850 excluding the Element ID field 855 and the length field 860. The AID IE 850 also has a min value field 870 and a max value field 875 that are used to provide an allowable range of values ​​from which the AID value to be used is selected. These minimum and maximum values ​​are stored by the non-AP station for use by the non-AP station each time an AID value is to be generated.

[0129] Of course, other formats exist. Furthermore, the IE may carry several ranges of values, for example for different types of non-AP stations.

[0130] Examples of hardware for performing steps of the method of the presently disclosed embodiments 9 illustrates a schematic example of a communications device that may correspond to any of the stations described with reference to FIG. 1 of a wireless network configured to implement at least some embodiments of the present disclosure. The communications device referenced 900 may preferably be a device such as a microcomputer, a workstation, or a lightweight portable device. The communications device 900 may include: a central processing unit 901, such as a processor called a CPU; a memory 903, denoted MEM, for storing the executable code of the methods or steps of the methods according to the embodiments of the present disclosure, as well as registers adapted to record variables and parameters necessary for carrying out the methods; and at least two communication interfaces 902 and 902′ connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via respective transmitting and receiving antennas 904 and 904′, may have a communication bus 913 to which

[0131] Preferably, the communications bus 913 may provide communication and interoperability between various elements included in or connected to the communications device 900. The representation of a bus is not limiting, and in particular a central processing unit is operable to communicate instructions to any element of the communications device 900, either directly or with another element of the communications device 900.

[0132] The executable code may be stored in a memory which may be either read-only, a hard disk or a removable digital medium such as a disk. According to an optional variant, the executable code of the program may be received by means of a communications network via interface 902 or 902', in order to be stored in memory 903 of communications device 900 before execution.

[0133] In some embodiments, communications device 900 may be a programmable device that uses software to implement embodiments of the present disclosure. Alternatively, however, some embodiments of the present disclosure may be implemented in whole or in part in hardware (e.g., in the form of an application-specific integrated circuit (ASIC)).

[0134] Embodiments of the present disclosure may be realized by a computer of a system or apparatus that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium (which may more fully be referred to as a “non-transitory computer-readable storage medium”) to perform one or more functions of the above-described embodiments and / or includes one or more circuits (e.g., application-specific integrated circuits (ASICs)) for performing one or more functions of the above-described embodiments, as well as by a method executed by the computer of the system or apparatus, e.g., by reading and executing the computer-executable instructions for performing one or more functions of the above-described embodiments from a storage medium and / or controlling the one or more circuits for performing one or more functions of the above-described embodiments. The computer may have one or more processors (e.g., central processing unit (CPU), microprocessing unit (MPU)) and may include a separate computer or a network of separate processors for reading and executing the computer-executable instructions. The computer-executable instructions may be provided to the computer, for example, from a network or a 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 device of a distributed computing system, an optical disk (such as a compact disc (CD), a digital versatile disc (DVD), etc.), a flash memory device, a memory card, etc.

[0135] When interpreting the description and its associated claims, expressions such as "comprise," "include," "incorporate," "contain," "is," and "have" should be construed in a non-exclusive manner, i.e., to allow for the presence of other items and elements not expressly defined. References to the singular should also be construed as references to the plural, and vice versa.

[0136] Those skilled in the art will readily appreciate that the various parameters disclosed in the description may be changed and that the various disclosed embodiments may be combined without departing from the scope of the present disclosure.

Claims

1. 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining a new value for the public identifier; Identifying the need to change the obtained new value; generating a request to change a new value of 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. 2. The method of claim 1, wherein determining the need to change the obtained new value comprises determining that the obtained new value is assigned to another non-AP station.

3. 3. The method of claim 1, wherein determining the need to change the obtained new value includes determining that the obtained new value violates at least one value assignment rule of the AP station.

4. The method of claim 1 , further comprising generating another new value for the public identifier.

5. The method of claim 4 , wherein the generated request includes the generated different new value.

6. 5. A method according to claim 1, wherein the generated request includes at least one item of information that enables the non-AP station to generate another new value for the public identifier.

7. 7. The method of claim 6, wherein the at least one item of information includes a range of values ​​to which the other new value must belong, an offset for calculating another new value from the new value, a number of iterations of a value generation process, or at least one initialization parameter of a pseudorandom number generator.

8. 8. The method of claim 2 or any one of claims 3 to 7 dependent on claim 2, further comprising prohibiting transmission of one or more messages to non-AP stations using the new value for the public identifier.

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

10. The method of claim 1 , wherein the generated request is a request to change the values ​​of a plurality of public identifiers.

11. The method of claim 1 , wherein the generated request is a protected action frame.

12. 12. The method of claim 1, wherein the generated request includes an indication of the moment at which a new value for the public identifier should be used.

13. A method according to any preceding claim, wherein the generated request includes an item of information identifying the public identifier.

14. 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining a new value for the public identifier; receiving a request to change the obtained new value; and determining a different new value for the public identifier based on at least one item of information in the received request.

15. 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. 16. The method of claim 14 or 15, further comprising generating and sending a response to the request to change the new value for the public identifier, the response indicating the determination of the different new value.

17. 18. The method of claim 14, further comprising determining the moment at which the further new value should 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. 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: obtaining a range of values ​​for the value of the public identifier; generating an information element containing a representation of the obtained range of values ​​that should be used by the non-AP station each time a new value for the public identifier is to be determined; and transmitting the generated information element to the non-AP station.

20. 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, wherein both the non-AP station and the AP station use the same mechanism for determining a new value of the public identifier, the method comprising: receiving from the AP station an information element including a representation of a range of values ​​of the public identifier and storing the received range of values; determining a value of said public identifier each time a value of said public identifier is needed, said value of said public identifier being within said stored range of values.

21. 21. The method of claim 19 or 20, wherein the public identifier is an association identifier (AID).

22. 22. A computer program product for a programmable device, comprising a series of instructions for performing each of the steps of the method of any one of claims 1 to 21 when loaded into and executed by said programmable device.

23. A non-transitory computer-readable storage medium having stored thereon computer program instructions for performing each of the steps of the method of any one of claims 1 to 21.

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

Images