Method for modifying the value of one or more privacy parameters of a station in a basic service set - Patents.com

Abstract

The present invention relates to a method for changing the value of one or more privacy parameters, such as a MAC address, of a target station in a BSS, both in an AP station and in a non-AP station associated with the AP station. The two stations share a pseudorandom function that generates a new value of the privacy parameter from a shared key and a shared parameter whose value varies over time. Each station obtains the shared key and the parameter value, communicates with the other station a request to change the value of the privacy parameter at a target time, calculates the new value using the shared key and the current value of the shared parameter as inputs to the shared function, and replaces the current value of the privacy parameter of the target station with the calculated new value in a registry at the target time.

Description

[Technical field]

[0001] The present invention relates to wireless communications, and more particularly to user privacy during wireless communications. [Background technology]

[0002] The approaches described in this section could be achieved, but are not necessarily approaches that have been previously conceived or achieved. Thus, unless otherwise stated herein, the approaches described in this section are not prior art to the claims of this application, and no admission of prior art is made by inclusion in this section. Moreover, all embodiments are not necessarily intended to solve all or any of the problems raised in this section.

[0003] 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 many mechanisms for wireless communication between stations.

[0004] Today, the evolution of wireless systems, driven by user demands and the requirements of the General Data Protection Regulation (GDPR), has brought privacy concerns to the forefront. 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 profiling activities.

[0005] Personally Identifiable Information (PII) corresponds to any data that identifies an individual or from which an individual's identity or contact information can be derived. For example, in the context of 802.11, PII can be the use of a unique identifier (such as a MAC address or SSID) that can be directly linked to a single device or a small group of devices (and thus to the owners of such devices). In the following, PII are referred to as privacy parameters or PE (Privacy Enhancements) parameters.

[0006] The IEEE 802.11 Working Group proposed a procedure consisting of dynamically changing the MAC address of user devices to limit the risk of users being tracked. This mechanism, called the Randomized and Changing MAC (RCM) procedure, was introduced as a privacy extension in the 802.11aq Pre-Association Service Discovery Task Group and was eventually included in the IEEE Std 802.11-2020 standard. It involves periodically changing the MAC address of a non-AP station (a station that is not an access point) to a random value while that non-AP station (STA) is not associated with a network (or equivalently an access point).

[0007] Recent requirements from the IEEE 802.11bi working group now require privacy parameters other than MAC addresses to be protected.

[0008] However, according to the actual standards and existing mechanisms, non-AP stations cannot randomly change privacy parameters such as MAC addresses while they are associated with an AP station. Also, AP stations cannot randomly change their privacy parameters. Therefore, the above-mentioned security problem remains for these stations. The various actions and behaviors of non-AP stations in the basic service set (BSS) of an AP station can still be tracked and checked through the privacy parameters, so privacy is not guaranteed. Similarly, the AP station itself can still be tracked through the privacy parameters, which will harm privacy if such an AP station is, for example, a mobile AP station implemented in a personal mobile phone.

[0009] Therefore, there is a need for a method to facilitate the application of a procedure such as a Randomized and Changing MAC procedure for a station (non-AP or AP) to randomly change its privacy parameters without explicitly exchanging the changed privacy parameters. Summary of the Invention

[0010] In this context, the present invention provides a method for modifying a value of at least one privacy parameter of a target station between an AP station managing a Basic Service Set (BSS) and a non-AP station of said BSS, said non-AP station and said AP station having a shared function for generating a new value of the privacy parameter, said method being configured in said non-AP station or in said AP station, said method comprising: Obtaining a key and a parameter having a time-varying value that is shared between the non-AP station and the AP station with the other station; calculating a new value of at least one privacy parameter using the shared key and the current values ​​of the shared parameters as inputs to the sharing function; At the target time, the value of at least one privacy parameter is replaced with the calculated new value.

[0011] In some embodiments, the method further includes communicating, at the station, with the other station a request to change a value of the at least one privacy parameter at the target time, such that the target time is exchanged between the two stations.

[0012] In an alternative embodiment, the method further comprises determining, at a station, a value representing a (target) time at which the value of the privacy parameter will be changed by using the sharing function with an input set including the current value of the parameter to be shared, such that the target time is determined locally by both stations.

[0013] As known by those skilled in the art, privacy parameters in the context of a communication station include any information, parameter, or personally identifiable information (PII) that allows the communication station to be identified or tracked. As an example, the IEEE 802.11bi task group has defined a set of privacy (or privacy enhancement, PE) parameters known as the Client Privacy Enhancements (CPE) feature and the BSS Privacy Enhancements (BPE) feature. EUI (short for Extended Unique Identifier) ​​is one of them. It is a unique identifier that is assigned to the network interface controller of a communication station for use as a network address during wireless communication, for example according to IEEE 802 network technology. Typically, the EUI consists of 48 bits (EUI-48, also called MAC address) or 64 bits (EUI-64).

[0014] "Communicating with other stations" means communicating with other stations regardless of the communication direction. Thus, as described below, the communication of the request may be from a non-AP station to an AP station or vice versa. The method may also target one or more privacy parameters (and thus CPE parameters) of a non-AP station or one or more privacy parameters (and thus BPE parameters) of an AP station, in which case the communication of the request may be made to all non-AP stations of the BSS. Of course, multiple iterations of the method may change the privacy parameters of the AP station and each of multiple non-AP stations of the BSS over time.

[0015] By "shared parameter with a value that varies over time" is meant a parameter whose value is known by both non-AP and AP stations, and whose value is different at two different times when the procedure according to the invention is performed again for the same privacy parameter. For example, said shared parameter may be the time, a date, a counter, the EUI of the target station (in the context of the invention, the value of the EUI of the target station can change and therefore varies over time). By "current value of the shared parameter" is meant the value of the shared parameter at the time when the procedure is started, e.g. when a new value of the privacy parameter (such as EUI) is calculated.

[0016] The shared key is known by both the AP station and the non-AP station. Its value may be dedicated to the non-AP station (i.e., two non-AP stations have two different shared keys), it may be the same for a subgroup of non-AP stations that associate with the AP station, or for all non-AP stations that associate with the AP station. Also, if the privacy parameter (BPE parameter) is associated with the AP station (and thus the BSS), its value may be common to the BSS (i.e., all stations in the BSS).

[0017] The replacement of the privacy parameter value is performed locally at the non-AP station and / or the AP station.

[0018] According to the above method, the privacy parameter of a station in a BSS can be changed by an AP station or any non-AP station that is not yet associated with an AP station without exchanging (e.g., in a change request) a new randomized value of the privacy parameter. Thus, the user's privacy is improved. Both the AP station and the non-AP station can calculate the same new value of the privacy parameter and use it from the same moment because they have mirrored parameters. This allows them to communicate with each other without interruption (avoiding that the value of the privacy parameter is changed on one side and not changed on the other side). Thus, the user's privacy is improved.

[0019] Although optional features of the invention are defined below with reference to the method, they can be replaced by device features. The various embodiments below can be combined unless there are obvious incompatibilities.

[0020] In some embodiments, the at least one privacy parameter includes one or more of the following: One or more Extended Unique Identifiers (EUI) of the target station, One or more MAC addresses of the target stations, A sequence number used by the target station to uniquely identify each new MAC Service Data Unit (MSDU), Aggregated-MSDU (A-MSDU), or MAC Management Protocol Data Unit (MMPDU) being transmitted; A packet number used by a target station to uniquely identify each new frame being transmitted. This packet number is incremented for each frame transmission except for retransmissions, and is known to provide replay detection protection. the Association Identifier (AID) of the target station to uniquely identify the target station within the BSS; a scrambler seed used by the target station to initialize a local scrambler that scrambles transmitted data and / or a local scrambler that descrambles received data; A beacon interval that defines the time interval between two consecutive target beacon transmission times (TBTTs); The BSS colors are used as numeric identifiers for the BSS.

[0021] The more the privacy parameters are varied, the more the user's privacy is respected.

[0022] In some embodiments, the request to change the value of at least one privacy parameter is transmitted from the AP station to the non-AP station, reflecting a centrally directed decision to change the privacy parameter.

[0023] In some embodiments, the target station is an AP station. In this scenario, we target the modification of so-called BPE parameters related to the AP station. This is particularly beneficial for the privacy of mobile AP stations, such as those implemented in personal mobile phones, and therefore for the privacy of the entire BSS.

[0024] In a particular embodiment of this scenario, the shared key is the Groupwise Temporal Key (GTK) of the BSS or a derivative thereof. Advantageously, this key is already shared between all stations of the BSS. This therefore reduces the complexity of the method.

[0025] In some embodiments, the request notifies the AP station of multiple targeted non-AP stations (e.g., all non-AP stations) of the BSS that are declared as BSS Privacy Enhancement (BPE) clients, the BPE clients are configured to change the value of a privacy parameter using a shared function, and the request notifies each targeted BPE client to change: the value of at least one privacy parameter of the AP station; The value of at least one privacy parameter for the targeted BPE client.

[0026] The AP station changes the value of its own privacy parameter and the privacy parameter value of each of its target BPE clients. Note that this scenario guarantees global privacy within the BSS if it is applied to all non-AP stations in the BSS in addition to the AP station, which is the main target station.

[0027] In some embodiments, the request includes a policy field indicating whether the request notifies each of one or more targeted stations, different from the target station, to change the value of at least one privacy parameter of the targeted station. This is particularly useful for an AP station that may trigger a change in its own privacy parameters (so-called BPE AP parameters) as well as a change in the privacy parameters of one or more or all (targeted) non-AP stations of the BSS (so-called BPE client parameters).

[0028] In a particular embodiment, a non-AP station of a BSS that is configured to use the shared function to change the value of the privacy parameter declares itself to the AP station as a BSS Privacy Extension (BPE) client, and the policy field takes one of the following values ​​(e.g., the requesting station predetermines the policy to be applied and then signals it in the request): a first value indicating only a request to change the value of at least one privacy parameter of the AP station; a second value signaling a request to all BPE clients of the BSS requesting each targeted BPE client to change the value of at least one privacy parameter of the targeted BPE client; A third value signaling a request targeted to a subgroup of BPE clients of the BSS, requesting each targeted BPE client to change the value of at least one privacy parameter of the targeted BPE client.

[0029] According to a particular feature, if the policy field has a third value, the request further includes a BPE client group field indicating a subgroup of BPE clients. The third value and the BPE client group field may have multiple possible values ​​indicating multiple subgroups of BPE clients targeted in the policy field.

[0030] In these scenarios, the AP stations may dynamically manage and adjust privacy within the BSS.

[0031] In some embodiments, the method further comprises, at the AP station, if the request requests the targeted BPE client to change a value of at least one privacy parameter of the targeted BPE client: Obtain a second parameter having a second key and a time-varying value that is shared with the targeted BPE client; calculating a new value of at least one privacy parameter for the targeted BPE client by using the second shared key and the current value of the second shared parameter as inputs to a sharing function; Replace the value of at least one privacy parameter of the targeted BPE client with a new value of the at least one privacy parameter calculated at a second target time (which may be the target time if directly signaled in the request, or may be a different time determined locally, such as using a shared function as described below).

[0032] This scenario therefore provides a high level of privacy across the BSS.

[0033] In some embodiments, the method further comprises determining, at the non-AP station, from the request that the non-AP station belongs to the targeted BPE client, and in that affirmative: obtaining a second key and a second parameter having a time-varying value, the second key and second parameter being shared with the AP station; calculating a new value of at least one privacy parameter of a non-AP station by using the second shared key and the current value of the second shared parameter as inputs of a sharing function; The value of at least one privacy parameter of the non-AP station is replaced with a new value of the at least one privacy parameter calculated at a second target time (which may be the target time if directly notified in the request, or may be another time determined locally using a shared function, etc.).

[0034] This approach is preferably implemented in each BPE client targeted in the request, so that the AP station and any non-AP stations of the targeted BPE know that they can calculate the same new value of the privacy parameter and use it from the same moment on, since they have mirrored parameters, allowing them to communicate with each other uninterrupted.

[0035] In a particular embodiment, the second key shared is a Pairwise Transient Key (PTK) or a derivative thereof of the targeted non-AP station or BPE client. Advantageously, this key is already shared between the targeted non-AP station and the AP station when the former associates with the AP station. This therefore reduces the complexity of the method.

[0036] In some embodiments, calculating a new value for the at least one privacy parameter includes: Apply a shared function to the input to obtain multiple bits; determining a new value for a first privacy parameter of the target station from a first subset of the plurality of bits; A new value for a second distinct privacy parameter for the target station is determined from a second subset of bits of the plurality of bits.

[0037] Of course, this approach can be extended to any number (more than one) of privacy parameters of the target station. For example, four or five CPE parameters, or three or four BPE parameters can be considered. The chunks of bits in the resulting bits can correspond to (and thus are provided directly with) new randomized values ​​of the privacy parameters.

[0038] Therefore, to perform simultaneous random modifications of multiple privacy parameters, as recommended by 802.11bi for a given STA, a single call to a shared function is required. The proposed scenario significantly reduces the implementation complexity and cost.

[0039] In a particular embodiment, the first subset of bits and the second subset of bits have no bits in common, meaning that the subsets of bits for providing the new randomized value do not overlap, although in alternative embodiments, overlaps may be tolerated in order to reduce the length of the required binary result from the shared function.

[0040] In embodiments described below, one or more other (eg, separate) subsets of the resultant bits may be dedicated to providing one or more target times at which a change in the privacy parameter takes effect.

[0041] In some embodiments, the request includes a notification regarding a target time at which the value of at least one privacy parameter will be changed. Alternatively, the target time may be indicated in another frame, for example a beacon frame transmitted by the AP station. Thus, the target time is explicitly indicated by the requesting sending station (either a non-AP station or an AP station).

[0042] Alternatively, the method further includes determining, at the non-AP station or the AP station, a value representing a target time at which the value of the at least one privacy parameter is to be changed by using a shared function with inputs including a current value of the shared parameter, the same determination being made at both stations that need to simultaneously apply the mirrored privacy parameters, allowing one to efficiently communicate with the other.

[0043] Thanks to this method, the time when the change is performed is not exchanged between non-AP and AP stations, thus improving the user's privacy.

[0044] In certain embodiments, determining a value representative of a target time at which the value of the at least one privacy parameter will be changed and calculating a new value for the at least one privacy parameter includes: Apply a shared function to the input to obtain multiple bits; determining a new value of at least one privacy parameter from a first subset of the plurality of bits; Determine a value from a second subset of the plurality of bits that represents a target time at which the value of the at least one privacy parameter is to be changed. As discussed above, the new value of the privacy parameter and the target time value may thus be generated from multiple distinct subsets of bits that make up the binary result of one iteration / invocation of the shared function.

[0045] Using the same application of the same function advantageously reduces the number of calculations required to perform the modification method.

[0046] In a particular embodiment, the first subset of bits and the second subset of bits have no bits in common.

[0047] In a particular embodiment, determining the value representing the target time is performed in response to receiving a request. Alternative events that trigger the determining step may include changing the previous value of at least one privacy parameter to a current (randomized) value (the value to be changed now), receiving a message from the other station confirming the request, receiving a transmitted shared key as described below, or receiving a message from the other station confirming receipt of a transmitted shared key. Thus, the destination non-AP station can learn the target time determined by the AP station.

[0048] Exemplary embodiments of determining the value of the target time include one or more of the following: - the number of units of time by which the value of at least one privacy parameter is changed at the termination is a function of the determined value; - the unit of time is Target Beacon Transmission Times (TBTTs), - the determined value is an integer value k, Following the determination of the value representative of a target time at which the value of the at least one privacy parameter is to be changed, a number of subsequent beacon frames are transmitted by the AP station or received by the non-AP station; The target time at which the value of at least one privacy parameter is changed corresponds to a time at which the [k+1]th beacon frame among the subsequent multiple beacon frames is transmitted by the AP station or received by the non-AP station. - the determined value is an integer value k, the request to change the value of the at least one privacy parameter includes a field whose value represents an integer scaling factor s, and following the determination of the value representing a target time at which the value of the at least one privacy parameter is to be changed, a number of subsequent beacon frames are transmitted by the AP station or received by the non-AP station; The target time at which the value of at least one privacy parameter is changed corresponds to the time at which the [m+1]th beacon frame of a subsequent set of beacon frames is transmitted by an AP station or received by a non-AP station, where m is equal to k times s.

[0049] In one or more embodiments, the method may be performed at a non-AP station, and obtaining the key shared with the AP station may include, at the non-AP station: receiving a request from an AP station to obtain a shared key; upon receiving a request to obtain a shared key, generating a shared key; The generated shared key is transmitted to the AP station.

[0050] According to these embodiments, the shared key can be dedicated to the non-AP station that must change the value of a privacy parameter, such as an EUI, and none of the other non-AP stations in the BSS can access the key. Therefore, none of the other non-AP stations in the BSS can calculate the privacy parameter (such as an EUI) of the non-AP station that must change the value. Thus, security is improved.

[0051] Note that the transmission of the shared key from the non-AP station to the AP station is performed in an encrypted manner, since it is performed after their association, so that a third party who intercepts a message containing the key cannot use the key.

[0052] Furthermore, the shared key can be pseudo-generated, so its value cannot be guessed by a third party, improving security.

[0053] Symmetrically, when the method is performed at an AP station, obtaining the key shared with the non-AP station may include, at the AP station: Sending a request to a non-AP station to obtain a shared key; In response to a request to obtain the shared key, a shared key is received from the non-AP station.

[0054] In one or more embodiments, the shared function may be a pseudorandom function (PRF). Thus, new values ​​of privacy parameters (such as EUI) are pseudo-generated and cannot be inferred by a third party, improving security and privacy. Also, pseudorandom functions already exist according to standards. Therefore, no new functions are needed to implement the method of changing the privacy parameters of the target station.

[0055] In one or more embodiments, the current value of the shared parameter may be the current value of the EUI of the target station. "Current value of EUI" means the value of the EUI when the new value is calculated, e.g., the value of the EUI before it was changed. Alternatively, it may be the current value of any privacy parameter, or a mixed (e.g., concatenated) value of several parameters.

[0056] Alternatively, the current value of the shared parameter may be the value of the current time. "Current time" means, for example, the time read from the clock when the new value is generated. In these embodiments, the value of the current time may be rounded (e.g., to the nearest second, to the nearest tenth of a second, etc.) to ensure that it is the same value at the AP station and the non-AP station. Also, in these embodiments, it is necessary to define the time at which both the AP station and the non-AP station calculate the new value (e.g., when the change request is sent / received or when the change has to be applied, etc.).

[0057] In one or more embodiments, the non-AP station or the AP station may store a registry including the value of at least one privacy parameter of the target station, and replacing the value of the at least one privacy parameter with the calculated new value may include replacing the value of the at least one privacy parameter of the target station in the registry with the calculated new value. In other words, at the time the change is applied, the AP station's registry and the non-AP station's registry may be updated with the new value to have mirrored values. After this update, all data transmission between the AP station and the non-AP station is performed with the new value of, for example, the EUI.

[0058] In one or more embodiments, the EUI of the non-AP station may be the MAC address of the non-AP station, for example, EUI-48.

[0059] In one or more embodiments, a request to change the value of at least one privacy parameter may be sent by an AP station and received by a non-AP station, and the request may be specific to one non-AP station (in which case only the privacy parameter (e.g., EUI) of that non-AP station is changed) or may be sent to all non-AP stations associated with the AP and supporting the privacy parameter change procedure (in which case all privacy parameters (e.g., EUI) of the non-AP stations are changed simultaneously).

[0060] For example, the request to change the value of at least one privacy parameter may be a beacon frame, where the request is sent to all non-AP stations that are associated with the AP and that support the privacy parameter change procedure.

[0061] Furthermore, the indication regarding the target time at which the value of the at least one privacy parameter is to be changed may be a counter included in the beacon frame, the counter indicating a number of target beacon transmission times (TBTTs).

[0062] Further, after the request to change the value of the at least one privacy parameter, multiple subsequent beacon frames may be transmitted by the AP station and received by the non-AP station, each subsequent beacon frame including a respective value of the counter, the value of the counter being decremented by one for each subsequent beacon frame; And the target time at which the value of the at least one privacy parameter is changed may be the time at which a beacon frame with the counter value equal to 0 is transmitted from the AP station and received by the non-AP station.

[0063] Alternatively, the request to change the value of at least one privacy parameter may be sent by a non-AP station and received by an AP station, reflecting a station-oriented decision to change the privacy parameter of its own device.

[0064] In one or more embodiments, a notification regarding the target time at which the value of the at least one privacy parameter will be changed may be included in the request to change the value of the at least one privacy parameter.

[0065] For example, the notification for a target time at which the value of the at least one privacy parameter is to be changed may be a number k of target beacon transmission times (TBTTs) at which the value of the at least one privacy parameter is to be changed, where the value of the privacy parameter may be changed when the kth beacon frame is transmitted from the AP station or received by a non-AP station since the communication of the request.

[0066] Alternatively, the notification regarding the target time at which the value of the at least one privacy parameter is to be changed may be a time value, in which case the value of the privacy parameter may be changed when a beacon frame corresponding to the first beacon frame after the time value is reached is transmitted from an AP station or received by a non-AP station.

[0067] In one or more embodiments, the capability to perform the procedure for changing the value of at least one privacy parameter may be exchanged during association between the non-AP station and the AP station, so that each non-AP station declares whether it supports the privacy parameter change procedure and knows whether the AP station supports the privacy parameter change procedure.

[0068] Relatedly, the present invention also provides a wireless communication device including at least one microprocessor configured to perform the steps of any of the above methods. The wireless communication device is a non-AP MLD.

[0069] Another aspect of the present invention relates to a non-transitory computer readable medium storing a program which, when loaded and executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any of the methods defined above.

[0070] At least some of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, 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 invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0071] Since the present invention can be implemented in software, the present invention can be implemented as computer readable code for provision to a programmable device on any suitable carrier medium. Tangible non-transitory carrier media can include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid-state memory devices. Transitory carrier media can include signals such as electrical, electronic, optical, acoustic, magnetic, or electromagnetic signals, e.g., microwave or RF signals. [Brief description of the drawings]

[0072] Some embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which: [Figure 1]1 illustrates an example of a network system in which embodiments of the present invention may be used; [Figure 2A] 1 illustrates a client-initiated (CPE) procedure for randomizing one or more privacy parameters of a CPE client, according to an embodiment of the present invention. [Figure 2B] 1 illustrates a client-initiated (CPE) procedure for randomizing one or more privacy parameters of a CPE client, according to an embodiment of the present invention. [Figure 3A] 1 illustrates an AP-initiated (BPE) procedure for randomizing one or more privacy parameters of either a BPE AP and / or one or more BPE clients, according to an embodiment of the invention. [Figure 3B] 1 illustrates an AP-initiated (BPE) procedure for randomizing one or more privacy parameters of either a BPE AP and / or one or more BPE clients, according to an embodiment of the invention. [Figure 4] 4 is an example flowchart illustrating a method for changing a MAC address of a non-AP station associated with an AP in accordance with one or more embodiments of the present invention. [Figure 5A] 4 illustrates steps performed in a non-AP station to change its MAC address in accordance with one or more embodiments of the present invention. [Figure 5B] 4 illustrates steps performed in a non-AP station to change its MAC address in accordance with one or more embodiments of the present invention. [Figure 6A] 4 illustrates steps performed at an AP to change the MAC addresses of non-AP stations that associate with the AP, in accordance with one or more embodiments of the present invention. [Figure 6B] 4 illustrates steps performed at an AP to change the MAC addresses of non-AP stations that associate with the AP, in accordance with one or more embodiments of the present invention. [Figure 7]1 illustrates an example of a frame format for advertising a station's ability to support a MAC address change procedure in accordance with one or more embodiments of the present invention. [Figure 8] 1 illustrates an example sequence of steps for initiating a procedure to change the MAC address of a non-AP station associated with an AP, in accordance with one or more embodiments of the present invention. [Figure 9A] 1 illustrates an example series of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP, in accordance with one or more embodiments of the present invention. [Figure 9B] 1 illustrates an example series of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP, in accordance with one or more embodiments of the present invention. [Figure 10] FIG. 2 illustrates an example of a frame format for activating and operating a MAC address change procedure in accordance with one or more embodiments of the present invention. [Figure 11] 1 illustrates an example of a frame format for operating an AP-initiated MAC address change procedure in accordance with one or more embodiments of the present invention. [Figure 12A] 1 illustrates steps performed at a BPE AP and a BPE client, respectively, to operate a BSS RCM procedure in accordance with one or more embodiments of the present invention. [Figure 12B] 1 illustrates steps performed at a BPE AP and a BPE client, respectively, to operate a BSS RCM procedure in accordance with one or more embodiments of the present invention. [Figure 13] 1 illustrates an exemplary information element for signaling an ERCM procedure (and therefore a BSS RCM procedure) initiated by a BPE AP according to an embodiment of the present invention. [Figure 14] 1 illustrates an exemplary protected action frame for operating a BSS RCM procedure, in accordance with an embodiment of the present invention. [Figure 15A]1 shows a CPE list and a BPE list that list privacy parameters of non-AP stations and privacy parameters of AP stations that must be modified according to an embodiment of the present invention, hereinafter referred to as "first embodiment." [Figure 15B] 1 shows a CPE list and a BPE list that list privacy parameters of non-AP stations and privacy parameters of AP stations that must be modified according to an embodiment of the present invention, hereinafter referred to as "first embodiment." [Figure 16A] We show the corresponding CPE and BPE lookup tables that match each privacy parameter in the list to a binary subset of the output of the sharing function. [Figure 16B] We show the corresponding CPE and BPE lookup tables that match each privacy parameter in the list to a binary subset of the output of the sharing function. [Figure 17A] 4 is an example flowchart illustrating a method for changing a MAC address of a non-AP station associated with an AP according to multiple embodiments of the present invention, hereinafter referred to as the "second embodiment." [Figure 17B] 4 is an example flowchart illustrating a method for changing a MAC address of a non-AP station associated with an AP according to multiple embodiments of the present invention, hereinafter referred to as the "second embodiment." [Figure 17C] 4 is an example flowchart illustrating a method for changing a MAC address of a non-AP station associated with an AP according to multiple embodiments of the present invention, hereinafter referred to as the "second embodiment." [Figure 17D] 4 is an example flowchart illustrating a method for changing a MAC address of a non-AP station associated with an AP according to multiple embodiments of the present invention, hereinafter referred to as the "second embodiment." [Figure 18]13 illustrates an exemplary frame format of an ERCM Change Request adapted to a second embodiment for initiating a MAC address change procedure in accordance with one or more embodiments of the present invention. [Figure 19] 1 illustrates an example sequence of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP in accordance with one or more second embodiments of the present invention. [Figure 20] 10 shows an example sequence of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP according to another second embodiment of the present invention. [Figure 21] 1 illustrates an example of a communication device of a wireless network configured to implement at least one embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0073] The IEEE 802.11 Working Group proposed a procedure that consists of dynamically changing the MAC address of a user device to limit the risk of users being tracked. This mechanism is called the Randomized and Changing MAC (RCM) procedure, and Changing only the MAC address is a first step to improve privacy, but it is often not enough, and other elements, called personally identifiable information (PII) or privacy parameters, may also be dynamically changed to make them unidentifiable and / or untraceable. For example, in the RCM procedure specified in the IEEE Std 802.11-2020 standard, every time the MAC address of a non-AP STA is changed to a new random value, the counters of all sequence number (SN) spaces used to identify each transmitted frame (MSDU or MMPDU) are randomly reset, as are the seeds of the scramblers used at the PHY level to shuffle the frame data payload before transmission or to deshuffle it upon reception.

[0074] Since 2019, the IEEE 802.11bi task group has been in charge of proposing new technical features (beyond the RCM procedure) to enhance privacy in 802.11 networks. In its current phase, it defines a set of privacy requirements that extends the consideration beyond a single MAC address to new privacy parameters for AP and / or non-AP stations, called Privacy Enhancements (PE) parameters, regardless of whether the non-AP stations are currently associated with an AP station or not. Moreover, these multiple PE parameters are preferably modified and randomized simultaneously.

[0075] Therefore, in the following we refer interchangeably to "privacy parameters" and "PE parameters" (or CPE or BPE parameters as a specific implementation), with a MAC address or EUI (short for Extended Unique Identifier) ​​being just an example of a privacy parameter.

[0076] An embodiment of the present invention proposes a BSS or Client RCM procedure for modifying one or more privacy or PE parameters of one or more interested stations of a BSS without interrupting the service. For this purpose, the AP and non-AP stations involved in the BSS or Client RCM procedure locally generate in parallel the next random value of the considered privacy parameter using a shared function to obtain the same result, i.e. a mirrored value of the privacy parameter. These mirrored values ​​are used for subsequent communication between the stations.

[0077] In an embodiment, the procedure performs simultaneous random modification of multiple privacy parameters. It relies on a shared function executed locally in parallel by the AP and / or non-AP stations to generate the same next randomized values ​​of the list of privacy parameters all at once, again without exchanging these new values ​​over the air. These next values ​​are used as new values ​​by the stations.

[0078] A station stores in a privacy parameter register all current values ​​of privacy parameters of stations with which it exchanges data, and updates the register with new values ​​of privacy parameters of the concerned target stations. The stations also apply the changes of privacy parameters in a synchronized manner, and avoid sending frames with old privacy parameter values, e.g. old MAC addresses that are no longer relevant for the target stations, or privacy parameter values ​​that have been updated in one station but not in the other. Thus, an embodiment of the present invention proposes a mechanism to ensure that privacy parameter updates are performed in a synchronized manner between concerned stations, regardless of whether they are initiated by an AP or a non-AP station.

[0079] According to a particular embodiment, the invention proposes to change the MAC address of a non-AP station while this non-AP station is associated with the AP (or "AP station"). Again, the MAC address is used here as an example, but any privacy parameter may be involved instead.

[0080] A device's MAC address, or EUI-48 address, is an Extended Unique Identifier (EUI) consisting of 48 bits. It can be universally or locally administered. Universally administered addresses are assigned to a device uniquely by the manufacturer. In contrast, locally administered addresses are assigned to a device by software or a network administrator, replacing a physical burned-in address. The penultimate bit of the first octet of a MAC address, e.g. the seventh bit of the address, is also called the "U / L bit" (for "universal / local bit") and indicates whether it is universally administered (if set to 0) or locally administered (if set to 1). The least significant bit of the first octet of a MAC address, e.g. the eighth bit of the address, is also called the "I / G bit" (for "Individual / Group bit") and indicates whether the frame is sent to only one receiving device (if set to 0, indicating a unicast transmission) or to multiple devices (if set to 1, indicating a multicast transmission).

[0081] In a BSS, the MAC address used by a station for over-the-air (OTA) communication is called the OTA MAC address, and is indicated in either the Transmit Address (TA) field or the Receive Address (RA) field (corresponding to addresses 2 or 3) of the IEEE 802.11 frame. Therefore, in the following, "MAC address" and "OTA MAC address" are used interchangeably.

[0082] The new MAC address of the non-AP station must be known by both the AP station and the non-AP station so that they can continue to exchange data or frames. For this reason, the embodiment provides for the AP station and the non-AP station to determine the next MAC address of the non-AP station in parallel, respectively, to achieve the same result. This next MAC address is used as the new MAC address to identify the non-AP station. The AP station stores all MAC addresses of the non-AP stations associated with it in a register and updates the register with the new MAC address of the non-AP station. The AP station and the non-AP station also apply the MAC change in a synchronized manner to avoid sending frames with an old MAC address that is no longer the current address of the station, or with a MAC address that is updated in one entity but not the other. Therefore, the present invention proposes a mechanism to ensure that the MAC address update is done in a synchronized manner in the AP station and the non-AP station.

[0083] Thus, in one or more specific embodiments, the present invention relates to a method for changing the public MAC address of an associated station using a standard pseudo-random generator based on shared private information. The change can be initiated by an AP station or a non-AP station. This method makes it very difficult for non-registered stations to correlate the MAC address with a given station. Thus, the privacy of the given station is improved.

[0084] One or more particular embodiments propose that both the non-AP station and the AP station calculate the same counter, which defines the target time at which the change in the MAC address must be applied by both stations. This counter, consisting of a value representing the target time at which the value of the MAC address is to be changed, is determined by using a shared function with a set of inputs consisting of the current values ​​of the shared parameters. Thus, the MAC address update is performed in a synchronized manner at the AP station and the non-AP station, and no information regarding the target random time at which the change must be applied is exchanged between the non-AP station and the AP station.

[0085] Hereinafter, a procedure for changing a privacy parameter (e.g., a MAC address of a non-AP station already associated with an AP station) is referred to as an "Enhanced RCM procedure (ERCM procedure)" or a "Seamless Enhanced RCM procedure (SERCM procedure)". Therefore, all abbreviations of "ERCM" used in this specification can be replaced with "SERCM". ERCM or SERCM may be implemented at the initiative of a non-AP station in order for the non-AP station to change one of its own device's privacy parameters, in which case the "Client RCM procedure" ("Client" indicates a non-AP station) is referred to. On the other hand, when an AP changes a privacy parameter of its own device at the initiative of an AP station, the "BSS RCM procedure" is referred to.

[0086] Therefore, the present invention seeks to fill a gap in the known art by providing a procedure that allows randomization of privacy parameters of a target station during the lifetime of a BSS.

[0087] The techniques described herein may be used for various broadband wireless communication systems, including communication systems based on orthogonal multiplexing. Examples of such communication systems include space division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single carrier frequency division multiple access (SC-FDMA) systems. SDMA systems may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, e.g., wireless devices or stations. TDMA systems allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units and assigning each time slot to a different user terminal. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), which is a modulation technique that divides the overall system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers may also be referred to as tones, bins, etc. In OFDM, each subcarrier is independently modulated with data. An SC-FDMA system may utilize Interleaved FDMA (IFDMA), which transmits on subcarriers distributed across the system bandwidth, Localized FDMA (LFDMA), which transmits on blocks of adjacent subcarriers, or Enhanced FDMA (EFDMA), which transmits on multiple blocks of adjacent subcarriers.

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

[0089] Although the examples and embodiments are described in the context of a Wi-Fi network, the invention may be used in any type of wireless network, such as, for example, a mobile phone cellular network, which implements very similar mechanisms.

[0090] FIG. 1 illustrates an example of a network system in which embodiments of the present invention may be used.

[0091] FIG. 1 illustrates an 802.11 network (e.g., Wi-Fi network) system 100 consisting of four wireless devices: an access point (AP) station 110 and three non-AP stations (non-AP STAs) 120a, 120b, 120c. Of course, the number of non-AP stations 120a, 120b, 120c may be different from three. The AP station 110 provides wireless connectivity between the non-AP stations 120a, 120b, 120c and a broader network, such as the Internet. The connection of the non-AP stations 120a, 120b, 120c to the AP station 110 is performed by a standardized process called association. Once the non-AP stations 120a, 120b, 120c are associated with the AP station 110, the non-AP stations 120a, 120b, 120c can transmit data to and receive data from the network via the AP station 110.

[0092] The AP station 110 may be configured, implemented, or known as a Node B, a radio network controller (RNC), an evolved Node B (eNB), a 5G next-generation base station (gNB), a base station controller (BSC), a base transceiver station (BTS), a base station (BS), a transceiver function (TF), a wireless router, a wireless transceiver, a basic service set (BSS), an enhanced service set (ESS), a radio base station (RBS), or other terminology. It may be a standalone product or may be integrated into equipment such as a broadband remote access server (BRAS).

[0093] The non-AP stations 120a, 120b, 120c may be configured, implemented, or 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 other terminology. In some embodiments, the non-AP stations 120a, 120b, 120c may be or consist of 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. Thus, one or more aspects taught herein may be incorporated into a telephone (e.g., a mobile phone 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, the non-AP stations 120a, 120b, 120c may be wireless nodes. Such wireless nodes may provide, for example, connectivity to or from a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

[0094] The AP station 110 manages a set of stations that together organize access to the wireless medium for communication purposes. All stations (AP station 110 and non-AP stations 120a, 120b, 120c) form a service set called a basic service set (BSS) (although other terminology can be used). Note that the AP station 110 may manage more than one BSS. 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 110.

[0095] To ensure user privacy, the AP station 110 and the non-AP STAs 120a, 120b, 120c are configured with dot11MACPrivacyActivated set to true. This is a Management Information Base (MIB) variable controllable by an external management entity that defines whether the non-AP STAs can apply (variable set to true) or cannot apply (variable set to false) certain mechanisms for enforcing privacy at the MAC level, including RCM procedures. The use of this variable (other variables may be defined instead) can be extended to mechanisms for enforcing privacy of other than the station's single MAC address or PE parameters.

[0096] The IEEE 802.11bi task group specified two sets of privacy features or mechanisms. The first, called the Client Privacy Enhancements (CPE) set of features, prevents identification and tracking of clients (non-AP STAs). The second, called the BSS Privacy Enhancements (BPE) set of features, prevents identification and tracking of the BSS.

[0097] From this, a CPE-enabled AP is referred to as a CPE AP, and a CPE-enabled non-AP STA is referred to as a CPE non-AP STA or CPE client. Similarly, a BPE-enabled AP is referred to as a BPE AP, and a BPE-enabled non-AP STA is referred to as a BPE non-AP STA or BPE client. Similarly, with respect to BPE and / or CPE functionality, a non-BPE-enabled and / or non-CPE-enabled non-AP STA is referred to as a legacy non-AP STA or legacy client.

[0098] Typically, CPE functions are initiated by a CPE client (called the initiating CPE client) and BPE functions are initiated by a BPE AP. CPE functions involve simultaneous and random modification of multiple PE parameters, called CPE parameters. Similarly, BPE functions involve simultaneous and random modification of multiple PE parameters, called BPE parameters. A station's PE parameters are unique parameters that identify the station and are used to communicate efficiently with other stations.

[0099] In what follows, we use "PE" as a generalization of "BPE" and "CPE".

[0100] Depending on the scenario, the AP STA 110 is a CPE AP and the non-AP STAs 120a, 120b, 120c are CPE clients (e.g., the scenarios of Figures 2A-2B, 4-11, 17A-17D, 19, 20), or the AP STA 110 is a BPE AP and the non-AP STAs 120a, 120b, 120c are BPE clients (e.g., the scenarios of Figures 3A-3B, 4-11, 12A-14, 17A-17D, 19, 20). According to other embodiments, the AP STA 110 is both a CPE AP and a BPE AP and the non-AP STAs 120a, 120b, 120c are both CPE clients and BPE clients.

[0101] Exemplary CPE parameters include the following, which are intended for CPE clients only (CPE parameters are therefore PE client parameters): The MAC address of a CPE client (e.g., a non-AP station) for over-the-air (OTA) communication, called the OTA MAC address, is indicated in either the Transmit Address (TA) field or the Receive Address (RA) field of the IEEE 802.11 frame (corresponding to addresses 2 or 3). Optionally, a CPE client may have multiple OTA MAC addresses, each used for a given purpose, such as one MAC address when exchanging data, another MAC address when exchanging measurements, one MAC address when transmitting, one MAC address when receiving, etc.

[0102] The Sequence Number (SN) contained in the Sequence Number field of the Sequence Control field of the MAC header of an 802.11 frame (MSDU, A-MSDU, MMPDU). It is a 12-bit field. The Sequence Number is incremented for each transmitted frame and remains constant for retransmissions of a frame. It is therefore used by the CPE client to uniquely identify each new MAC Service Data Unit (MSDU), Aggregated-MSDU (A-MSDU) or MAC Management Protocol Data Unit (MMPDU) that is to be transmitted.

[0103] The Packet Number (PN) contained in the Packet Number field of the CCMP header in the plaintext MAC payload of a frame. It is a 48-bit packet number. It is used to encrypt the frame and can uniquely identify the frame being transmitted for replay detection purposes. The packet number is incremented for each transmitted frame and remains constant when the frame is retransmitted. Thus, the CPE client uses this number to uniquely identify each new frame being transmitted.

[0104] AID (Association Identifier) ​​is a unique identifier that an AP station assigns to a non-AP station upon association. It is a 16-bit field that is included in many frames for different purposes, such as power saving and resource allocation for MU OFDMA.

[0105] Scrambler seed corresponds to the seed used by the PLCP / OFDM PHY DATA scrambler to initialize the initial state (clause 17.3.5.5), e.g. to initialize the local scrambler that scrambles the transmitted data and / or descrambles the received data. This corresponds to a 7-bit parameter.

[0106] The BPE parameters for a BPE client (also called BPE client parameters) contain the same as the CPE parameters for a BPE client.

[0107] Exemplary BPE parameters for the BPE AP, also referred to as BPE AP parameters, include the following: The OTA MAC address of the BPE AP, indicated in either the Transmit Address (TA) or Receive Address (RA) field of the IEEE 802.11 frame (corresponding to addresses 2 or 3). Optionally, the BPE AP may have multiple OTA MAC addresses, each used for a given purpose as described above for the CPE client.

[0108] Scrambler seed, which corresponds to the seed used to initialize the initial state of the PLCP / OFDM PHY DATA scrambler (clause 17.3.5.5), e.g. to scramble transmitted data and descramble received data, and to initialize the local scrambler of the BPE AP. This corresponds to a 7-bit parameter.

[0109] Beacon interval, which corresponds to the difference or time interval between two of the Target Beacon Transmission Times (TBTTs), which are the times that an AP station is configured to transmit a beacon frame. The beacon interval is given in Time Units (TU), where a TU is equal to 1024 microseconds. It is a 16-bit field that is set to the number of TUs between beacon transmissions and is included in the Beacon Interval field of the beacon frame.

[0110] The list of these CPE / BPE parameters is not exhaustive and other CPE / BPE parameters may be considered. For example, another BPE AP parameter, the BSS Color introduced by the IEEE 802.11ax task group, used to identify the BSS, may be considered. It is included in the BSS Color field of the BSS Color Information of the HE Operation element included in the Beacon, Probe Response, and (Re)Association frames. It is a 6-bit parameter.

[0111] 2A, 2B, 3A and 3B illustrate, by way of a flow chart, the general steps of a method for modifying at least one value of a privacy parameter of a target station in a basic service set (BSS) according to an embodiment of the present invention.

[0112] (Client-directed procedure) 2A and 2B show a client-initiated (CPE) procedure for randomizing one or more privacy parameters of a CPE client, and FIGS. 3A and 3B show an AP-initiated (BPE) procedure for randomizing one or more privacy parameters of either a BPE AP or one or more BPE clients, or both.

[0113] The Client RCM procedure of Figures 2A and 2B is initiated by a CPE client, referred to as the active CPE client or active station, and consists of assigning new randomized values ​​to each of one or more CPE privacy parameters, meaning that the active CPE client is the target station whose privacy parameters must be changed.

[0114] For this modification, the active CPE client and the CPE AP use a shared function, such as the pseudorandom function (PRF) defined in section 12.7.1.2 of the IEEE Std 802.11-2020 standard, which is identified herein by the term PRCM PRF. According to other embodiments, the shared function is any block cipher algorithm that allows encrypting blocks with similar input parameters (a shared key and a shared parameter whose value varies over time). In the following description, for ease of explanation, the focus is mainly on the PRCM PRF. However, similar considerations are possible for any block cipher algorithm.

[0115] The PRCM PRF is based on three primary input parameters, denoted K, A, and B, and an auxiliary parameter Len, which specifies the number of pseudorandom bits (128, 192, 256, ...) generated by the PRCM PRF. In most of the following embodiments, Len is set to 128.

[0116] Parameter A is a string specific to the application in which the PRCM PRF is used. Within the scope of the Client RCM procedure, it is set to the string "Client RCM". Of course, any other string may be used.

[0117] Parameter B is a variable length string that must be known by all STAs affected by the Client RCM procedure of the active STA. It is a shared parameter for the calculation. According to one embodiment, this shared value is the current OTA MAC address of the active STA or the current value of the privacy parameter to be changed. According to another embodiment, the shared value corresponds to any CPE parameter of the active STA. According to another embodiment, it may be contemplated to use another shared value, e.g. a predefined value, the current time, etc.

[0118] The parameter K is a secret key unique to the active STA.

[0119] In the scope of the Client RCM procedure, it may correspond to any key, called IPRCM key, shared between the active CPE client and the CPE AP. Such a key is shared in a secret manner between the two stations so as to identify the stations and be known by both stations (hence it is a private key). It may also be a private encryption key shared between the CPE client and the CPE AP. In one or more embodiments, the IPRCM key is a Pairwise Transient Key (PTK) that the CPE AP and the active CPE client generated in parallel during the 4-way handshake mechanism upon association. In another embodiment, the IPRCM key may be inherited or derived from the PTK by using any block cipher that encrypts fixed-size (e.g. 128-bit) blocks of data. For example, the key derivation function PBKDF2 specified in IETF RFC 2898 may be used since it is already integrated into the station, in particular to generate Pairwise Master Keys (PMK) from Pre-Shared Keys (PSK) and to generate Pairwise Transient Keys (PTK) from the PMK.

[0120] In alternative embodiments, the IPRCM key may correspond to any key shared between an active CPE client and the CPE AP. For example, this shared key may be stored in a memory of a device constituting the CPE AP (such as an Internet connection box) and read by a user on the housing of this device. The user may then manually enter this shared key into the user equipment including the active CPE client, for example using a touch screen. Of course, other solutions are possible for the user equipment including the active CPE client to recover the IPRCM key. For example, the IPRCM key may be read elsewhere than on the housing of the device constituting the CPE AP (for example on a notification letter accompanying the equipment) and may be received directly on the user equipment including the CPE client from another equipment (for example via Short Message Service (SMS) or Bluetooth connection).

[0121] In yet another embodiment, the IPRCM key may be generated at the CPE AP and sent to the active CPE client, for example, via a protected action frame. Because the IPRCM key is exchanged between the active CPE client and the CPE AP, the communication between these entities must be protected. Of course, other embodiments for obtaining and identifying the PRCM key are possible, so long as both the active CPE client and the CPE AP obtain the same key. An exemplary exchange of keys between a non-AP station and an AP station is described below with reference to Figures 6 and 10.

[0122] On the operational CPE client side (FIG. 2A), when the latter initiates the Client RCM procedure in step 210, it launches the PRCM PRF with input parameters set as described above and generates an output corresponding to a sequence of pseudorandom bits from which only the L leftmost bits have been extracted (L being the number of bits required for the CPE privacy parameter to be changed). As an example, the leftmost 46 bits (e.g. the most significant 46 bits) are selected to generate a new MAC address value. The function generating these 46 pseudorandom bits is called PRF-128 / 46.

[0123] Thus, an operating CPE client obtains a key K and a parameter B having a time-varying value that are shared with the CPE AP station, and calculates a new value of at least one privacy parameter by using the shared key and the current values ​​of the shared parameters as inputs to a sharing function.

[0124] The PRCM PRF may be run repeatedly with different shared parameters B and / or different text strings A to generate new values ​​for different CPE privacy parameters. As shown below with reference to Figures 15A through 16B, in some advantageous scenarios, multiple randomized values ​​for multiple privacy parameters may be generated at once from a single iteration / invocation of the PRCM PRF.

[0125] Next, step 220 consists of sending a Client RCM Initiation Request to the CPE AP, indicating that a Client RCM procedure has been initiated by the active CPE client, so that the latter communicates with the CPE AP a request to modify the value of at least one privacy parameter of the CPE client at the target time, in order to trigger the CPE AP to modify the same privacy parameter with the same value in a synchronous manner (described with reference to FIG. 2B below).

[0126] In some embodiments, the request includes a notification (e.g., a Change Date field) related to a target time at which the value of the privacy parameter will be changed by both the active CPE client and the CPE AP. Details of such notifications are provided below in some embodiments, for example with reference to Figures 2A-6B and 9A-14.

[0127] Alternatively, a value representing a target time at which the value of the privacy parameter is to be changed may be determined (locally at both stations) by using a shared function with inputs including the current value of the shared parameter. Preferably, the new value of the privacy parameter may be generated from the same iteration of the shared PRCM PRF function when calculating the new value. Details of such an embodiment are provided in several embodiments below, for example with reference to Figures 17A-20.

[0128] According to some embodiments, the Client RCM start request is a new protected action frame called the Client RCM Action frame. For this purpose, a previously reserved specific value in the range [31,125] is assigned to the new Category field as specified in Table 9-51 of IEEE Std 802.11-2020. For illustrative purposes, the Category value assigned to the Client RCM procedure action frame is 31. Of course, other values ​​within the above range may be used. Exemplary Client RCM start requests are shown under reference numbers 1040, 1400 and 1840 in Figures 10, 14 and 18 described below.

[0129] Next, in step 230, the active CPE client executes a Client RCM procedure at the target time and updates the register with the new randomized values ​​of the CPE parameters. In other words, the active CPE client replaces the value of the at least one privacy parameter with the new value of the at least one privacy parameter calculated at the target time.

[0130] On the CPE AP side (FIG. 2B), the CPE AP receives a Client RCM Initiation Request from an active CPE client in step 250. In practice, the CPE AP may receive multiple requests from various "active" CPE clients wishing to modify one or more CPE privacy parameters. Thus, the CPE AP has communicated with the active CPE client a request to modify the value of at least one privacy parameter at a target time.

[0131] In step 260, in response to the request, the CPE AP initiates the same Client RCM procedure for the privacy parameters of the active CPE client. By "same Client RCM procedure" we mean that the same shared function is used with the same input parameters as in step 210 to generate the same output. In an embodiment, the output corresponds to the same sequence of pseudo-random bits from which the leftmost L bits are taken as the new value of the privacy parameter to be changed. In other words, the CPE AP takes a key K shared with the active CPE client and a parameter B having a value that changes over time, and calculates a new value of at least one privacy parameter by using the shared key and the current values ​​of the shared parameters as inputs to the shared function.

[0132] This ensures that the active CPE client and the CPE AP have a mirrored value of said privacy parameter of the active CPE client (target station).

[0133] Next, in step 270, the CPE AP runs a Client RCM procedure at a target time (explicitly indicated in the request or locally determined) when it updates its registers with new randomized values ​​of the CPE parameters of the active CPE client.

[0134] (AP-led procedure) The BSS RCM procedure of Figures 3A and 3B is initiated by the BPE AP and consists of assigning new randomized values ​​to each of one or more privacy parameters (BPE AP parameters) and, optionally, assigning new randomized values ​​to the privacy parameters of one or more or all BPE clients (BPE Client parameters).

[0135] In these embodiments, the BPE AP is the target station for which BPE AP parameters must be changed, and other stations (targeted BPE clients) may also be affected by the change in BPE client parameters.

[0136] With reference to FIG. 12A, exemplary decision criteria for applying one strategy or the other are provided below.

[0137] For simplicity, the BSS RCM procedures in the following description are directed only to changing at least one BPE AP parameter. The dedicated shared key and shared parameters may be used to generate new values ​​for the BPE client parameters using a shared function.

[0138] For the modification of at least one BPE AP parameter, the BPE AP and the BPE client also use the shared function mentioned above, such as the PRCM PRF. In the scope of the BSS RCM procedure, parameter A may be set to the string "BSS RCM", although other text strings may be used. Shared parameter B may be set to a predefined value, such as the current OTA MAC address of the BPE AP, or the current value of the BPE AP parameter to be modified, or any BPE AP parameter, or even other shared values, such as the current time. The PCRM key K, called the GPRCM key, is a key shared by the BPE AP and all associated BPE clients. Such a key is shared in a secret manner (hence it is a private key) to identify the BPE AP and to be known by both with the BPE client. It may be a secret encryption key shared between the BPE AP and the BPE client. In one or more embodiments, the GPRCM key is a Groupwise Temporal Key (GTK) that the AP station provides in EAP-Key message 3 during the 4-Way handshake mechanism with the non-AP station with which it wishes to associate. This GTK is conventionally used to generate the encryption key used to encrypt data transmitted from the AP station over the wireless medium. In another embodiment, the GPRCM can be inherited or derived from the GTK by using any block cipher that encrypts fixed-size blocks of data. For example, the key derivation function PBKDF2 specified in IETF RFC 2898 can be used since it is already built into the station and used to generate Pairwise Master Keys (PMKs) from Pre-Shared Keys (PSKs) and Pairwise Transient Keys (PTKs) from the PMKs, among others.

[0139] As with the IPRCM key, in alternative embodiments the GPRCM key may correspond to any key shared between the BPE AP and all associated BPE clients as described above and / or may be generated by the BPE AP and sent to the BPE clients via an encrypted information element, for example in a protected action frame or a beacon frame. Since the GPRCM key is exchanged between the BPE AP and all associated BPE clients, communication between these entities is preferably secure. Of course, other embodiments are possible for obtaining and determining the GPRCM key, as long as both the BPE AP and the BPE clients obtain the same shared key.

[0140] On the operational BPE AP side (FIG. 3A), when the latter starts the BSS RCM procedure in step 310, it starts the PRCM PRF with input parameters set as described above and generates an output corresponding to a sequence of pseudorandom bits from which only the leftmost L bits have been extracted (L being the number of bits required for the BPE AP parameters to be changed). As an example, the leftmost 46 bits (e.g. the most significant 46 bits) are selected to generate the new MAC address value. The function generating these 46 pseudorandom bits is called PRF-128 / 46.

[0141] Thus, the BPE AP obtains a key K shared with the BPE client and a parameter B having a value that varies over time, and calculates a new value of at least one privacy parameter by using the current values ​​of the shared key and the shared parameters as inputs to a sharing function.

[0142] The PRCM PRF may be run repeatedly to generate another new value of the BPE privacy parameter with a different shared parameter B and / or a different text string A. In some advantageous scenarios, such as those illustrated below with reference to Figures 15A-16B, multiple randomized values ​​for multiple BPE AP parameters may be generated at once from a single iteration / invocation of the PRCM PRF.

[0143] Next, step 320 consists of the BRE AP sending a BSS RCM start request to the BPE client, indicating that the BSS RCM procedure has been initiated by the BPE AP. In practice, the BPE AP may send the request to a single BPE client, to multiple BPE clients, or to all BPE clients of the BSS. An exemplary implementation is shown below with reference to Figures 12A to 14.

[0144] Thus, the BPE AP communicates with the BPE client a request to change the value of at least one BPE AP parameter at the target time, in order to trigger the BPE client to change the same BPE AP parameter with the same value in a synchronous manner (described with reference to Figure 3B below).

[0145] In some embodiments, the request includes an indication, e.g., a Change Date field, related to the target time at which the value of the privacy parameter will be changed by both the BPE AP and the BPE client. Details of such notifications are provided below in some embodiments, e.g., with reference to Figures 2A-6B and 9A-14.

[0146] Alternatively, a value representing a target time at which the value of the privacy parameter is to be changed may be determined (locally at both stations) by using a shared function with inputs including the current value of the shared parameter. Preferably, the new value of the privacy parameter may be generated from the same iteration of the shared PRCM PRF function when calculating the new value. Details of such an embodiment are provided in several embodiments below, for example with reference to Figures 17A to 20.

[0147] According to some embodiments, the BSS RCM start request is a new protected action frame called a BSS RCM action frame. For this purpose, a new Category field is assigned to a specific previously reserved value in the range [31,125], as specified in Table 9-51 of the IEEE Std 802.11-2020 standard. For illustrative purposes, the Category value assigned to the BSS RCM procedure action frame is 32. Of course, other values ​​within the above range may be used. Exemplary Client RCM start requests are shown under reference numbers 1040, 1400 and 1840 in Figures 10, 14 and 18, which will be described below.

[0148] Next, in step 330, the BPE AP runs a BSS RCM procedure at the target time and updates the registers with the new randomized values ​​of the BPE AP parameters. In other words, the BPE AP replaces the value of its at least one BPE AP parameter with the calculated new value of the at least one BPE AP parameter at the target time.

[0149] On the BPE client side (FIG. 3B), each BPE client receives a BSS RCM start request from the BPE AP in step 350. The BPE client thus communicates with the acting CPE client a request to change the value of at least one BPE AP parameter to a target time.

[0150] In step 360, in response to the request, the BPE client initiates the same BSS RCM procedure with respect to the BPE AP parameters. By "same BSS RCM procedure" we mean that the same shared function is used with the same input parameters as in step 310 to generate the same output. In an embodiment, the output corresponds to the same sequence of pseudo-random bits from which the leftmost L bits are taken as a new value for modifying the BPE privacy parameter. In other words, the BPE client AP takes a key K shared with the BPE AP and a parameter B having a value that varies over time, and calculates a new value of at least one privacy parameter by using the shared key and the current value of the shared parameter as inputs to the shared function.

[0151] This ensures that the BPE AP and the BPE client have mirrored values ​​of said BPE AP parameters of the BPE AP (target station).

[0152] Next, in step 370, the BPE client runs the BSS RCM procedure at the target time (either explicitly indicated in the request or locally determined) and updates the registers with the new randomized values ​​of the BPE AP parameters.

[0153] (Example Procedure for Changing the EUI of a Non-AP Station) Exemplary methods for changing the value of the EUI of a non-AP station associated with an AP station will now be described with reference to Figures 4 to 11. As mentioned above, these exemplary methods may be extended to privacy parameters of any CPE or BPE of a non-AP station. These exemplary methods implement either the Client RCM procedure (Figures 2A and 2B) or the BSS RCM procedure (Figures 3A and 3B) described above, depending on the station initiating the procedure.

[0154] FIG. 4 is an example of a flow chart illustrating a method for associating with an AP and changing the MAC address of an associated non-AP station according to one or more embodiments of the present invention. This represents an Enhanced RCM (ERCM) procedure that allows dynamic change of the MAC address of a non-AP STA when the non-AP STA associates with an AP. As described in detail below, after association, encrypted information (ERCM key) is shared between the AP and the non-AP STA. Then, upon request of the AP or non-AP STA, both the AP and the non-AP STA calculate the new temporary MAC address of the changing STA using the same pseudo-random generator with the same parameters, without sharing. Then, upon request of change of the MAC address of the non-AP station initiated by the AP or non-AP STA, both the AP and the non-AP STA apply the change of the MAC address of the changing STA.

[0155] In one or more embodiments, as in the case of non-AP stations (only) in the standardized RCM mechanism, both the non-AP stations and the AP may be configured with dot11MACPrivacyActivated set to true.

[0156] In a first step 400, a non-AP station associates with an AP according to the protocol defined in the IEEE 802.11 standard. During the association (step 400), the non-AP station and the AP declare their capabilities, in particular the ability to implement a mechanism to change the MAC address of the non-AP station when it associates with the AP ("ERCM capability"). For example, the ERCM capability can be signaled by using a frame format 700 as described with reference to FIG. 7. It should be noted that from the moment the non-AP station and the AP are associated, the communication between them is protected.

[0157] Next, both the non-AP station and the AP obtain a key called the "ERCM key" (step 410). The ERCM key is a key known by the non-AP station and the AP and is used to calculate the new MAC address of the non-AP station.

[0158] In one or more embodiments, the ERCM key may be a key obtained during authentication and association procedures between the non-AP station and the AP. For example, after successful authentication, the non-AP station and the AP have a shared key called a Pairwise Master Key (PMK) that is common to all non-AP stations in the BSS. After authentication, a 4-Way handshake is performed during which a key unique to each non-AP station is derived from the PMK, called a Pairwise Transient Key (PTK), which is the key used to encrypt communications between the non-AP station and the AP. In one or more embodiments, the PTK may be used as the ERCM key.

[0159] In alternative embodiments, the ERCM key may correspond to any key shared between a non-AP station and an AP. For example, this shared key may be stored in the memory of a device constituting the AP (e.g., an Internet connection box) and may be read by a user on the housing of this device. The user may then manually enter this shared key into the user equipment including the non-AP station, for example by using a touch screen. Of course, other solutions are possible for the user equipment including the non-AP station to recover the ERCM key. For example, the ERCM key may be read at a location other than on the housing of the device including the AP (e.g., on a notification attached to the device) and may be received directly on the user equipment including the non-AP station from another device (e.g., via a Short Message Service (SMS) or Bluetooth connection). Note that in these embodiments, the ERCM key is common to all non-AP stations.

[0160] In the above embodiments, the ERCM key is not exchanged between the non-AP station and the AP. Therefore, the ERCM key cannot be recovered by a third party who eavesdrops on the communication between the two entities (and thus can also calculate the next MAC address of the non-AP station), which ensures the security of the MAC address change procedure. In these embodiments, steps 400 and 410 can be performed in any order.

[0161] In other embodiments, the ERCM keys may be generated at the non-AP station and sent to the AP, as in steps 830, 840, and 850 of Figure 8. Because the ERCM keys are exchanged between the non-AP station and the AP, communications between these entities must be protected. Therefore, in these embodiments, step 410 must be performed after step 400.

[0162] Of course, other embodiments of step 410 are possible, so long as both the non-AP station and the AP station obtain the same key.

[0163] In steps 400 and 410, it is assumed that the MAC address of the non-AP station has a first value that is known (stored) by both the non-AP station and the AP.

[0164] In step 420, a request to change the MAC address of the non-AP station is exchanged between the non-AP station and the AP. As described in more detail below, the request is sent from the non-AP to the AP or from the AP to the non-AP station. To ensure that both the non-AP station and the AP start using the new MAC address at the same time (thus avoiding the problem of frames being sent whose MAC address fields do not correspond to the non-AP station's current MAC address), the request may include a notification of the time after which the new MAC address should be used (also called the "target time"). An example of such a notification is provided with reference to Figures 9A and 9B. In the following, the time after which the new MAC address should be used is called the "ERCM Date" or the "ERCM Change Date".

[0165] Alternatively, notification of the time after which the new MAC address must be used may not be included in the request and may be obtained by other means, for example, the MAC addresses of non-AP stations may be changed periodically and the time at which the MAC address will next be changed may be determined to correspond to the next instant in the periodic time sequence.

[0166] The new MAC address is calculated in parallel by both the non-AP station and the AP. From the moment the ERCM change Date is reached, the new calculated MAC address is used for communication between the non-AP station and the AP (step 430).

[0167] As mentioned above, there is a synchronous change of MAC address. For a request for a non-AP station MAC address change initiated by either the AP or a non-AP STA, both the AP and the non-AP STA apply the MAC address change for the changing STA. If AP initiated, the ERCM targets all non-AP stations that are ERCM capable. The ERCM procedure may use a new ERCM IE included in the beacon frame that includes an ERCM Change counter corresponding to the number of TBTTs until the next temporary MAC address is valid, as described in more detail below with reference to FIG. 11. In the non-AP initiated case, the ERCM procedure may use a new action frame that includes an ERCM Change date corresponding to the number of TBTTs until the next temporary MAC address is valid, as described in more detail below with reference to FIG. 10.

[0168] Note that the new MAC address may be calculated any time between steps 420 and 430, or simultaneously with step 430, when a change is acted upon (e.g., when the new calculated MAC address becomes that of a non-AP station).

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

[0170] More specifically, a PRF-128 (e.g., PRF(K,A,B,128)) may be used that generates 128 pseudorandom bits. From the 128 bits generated, the leftmost 46 bits (e.g., the most significant 46 bits) may be selected. This function is called PRF-128 / 46.

[0171] The standard PRF function is based on three input parameters, denoted K, A, and B. K is a secret key encoded on 256 bits, A is a text string specific to the application in which the PRF is used, and B is a variable-length string. To calculate a new MAC address, the non-AP station and the AP apply the same PRF function to the same input parameters, obtain the same output result, and construct the new MAC address of the non-AP station. The input parameters used for this calculation may be as follows: K is set to the ERCM key obtained in step 410, and A is set to "ERCM" indicating that the PRF is used to calculate a new MAC address in the context of the ERCM mechanism. B is set to any value known to both the non-AP station and the AP, and may change over time. For example, B may be the current MAC address of the non-AP station, the actual current time (in this case, the current time may be rounded to the nearest tenth of a second or to the nearest second, for example, to avoid problems due to imperfect synchronization between the clocks of the non-AP station and the AP), etc. Examples and embodiments are detailed below.

[0172] It should be noted that, according to different embodiments of the present invention, the above method may be applied to only one non-AP station in a BSS, to a subgroup of non-AP stations (each AP-non-AP station pair to which the modification method is applied in parallel), or to all non-AP stations in a BSS.

[0173] 5A and 5B illustrate steps performed in a non-AP station to change its MAC address in accordance with one or more embodiments of the present invention.

[0174] More specifically, FIG. 5A illustrates steps performed by a non-AP station to change its MAC address at its own request, and FIG. 5B illustrates steps performed by a non-AP station to change its MAC address at the request of an AP. Note that these embodiments are not mutually exclusive and may coexist in the same non-AP station. For example, an AP may be configured to indicate to a non-AP station at certain times (e.g., periodically) that the non-AP station needs to change its MAC address, while the non-AP station may be configured to indicate that it wants to change its MAC address at other times corresponding to certain events (e.g., when the non-AP station is stationary for a predefined time or when it transmits the same type of traffic for a predefined time).

[0175] Note that steps 500, 510, 520 (FIG. 5A) or 525 (FIG. 5B) and 530 are part of steps 400, 410, 420 and 430, respectively, in FIG. 4 and may be performed by a non-AP station.

[0176] 5A and 5B, a non-AP station first associates with an AP (step 500). During association (step 500), the non-AP station and the AP declare their capabilities, in particular, the ability to implement a mechanism to change the non-AP station's MAC address when the non-AP station is associated with the AP ("ERCM capability"). For example, the ERCM capability may be declared by using a frame format 700 as described below with reference to FIG. 7.

[0177] An "ERCM key" may then be obtained by the non-AP station (step 510), as detailed above with reference to FIG.

[0178] In the embodiment depicted in FIG. 5A, a request to change the MAC address of the non-AP station is received by the non-AP station (step 520), e.g., from the AP (alternatively, the request may be sent from a third device in the network to both the non-AP station and the AP). In the embodiment depicted in FIG. 5B, a request to change the MAC address of the non-AP station is sent from the non-AP station (step 525), e.g., to the AP (alternatively, the request may be sent to a third device in the network and then to the AP). In one or more embodiments, the request may include an ERCM change Date, e.g., a notification regarding the date and time when the change must be applied by both the non-AP station and the AP. Alternatively, the ERCM change Date may be obtained by other means at the non-AP station and the AP, e.g., from a third party device or according to a list of predefined times (regular or not) at which the MAC address must be changed.

[0179] Then, as described above with reference to Figure 4, a new MAC address is calculated by the non-AP station and the change is acted upon at the ERCM change Date (step 530). Note that the new MAC address may be calculated at the ERCM change Date (e.g., step 530) or before (e.g., between steps 520 / 525 and 530, or even before 520 / 525). However, the effective change is performed when the ERCM date is reached.

[0180] 6A and 6B illustrate steps performed at an AP to change the MAC address of a non-AP station associated with the AP in accordance with one or more embodiments of the present invention.

[0181] More specifically, Figure 6A shows steps performed by an AP to change the MAC address of a non-AP station associated with the AP at the request of the non-AP station (or alternatively, a third device in the network). Figure 6B shows steps performed by an AP to change the MAC address of a non-AP station associated with the AP at its own request. "Changing the MAC address of a non-AP station associated with the AP" means that the AP calculates a new value and stores the calculated value as the new MAC address of the non-AP station. As soon as the ERCM date is reached, this new MAC address will be the one used in frame exchanges between the AP and the non-AP station.

[0182] The steps in Figures 6A and 6B correspond to the steps in Figures 5A and 5B on the AP side, respectively, and it should be noted that steps 600, 610, 620 (Figure 6A) or 625 (Figure 6B) and 630 are parts of steps 400, 410, 420 and 430 in Figure 4, respectively, which are performed by the AP.

[0183] 6A and 6B, an AP first associates with a non-AP station (step 600). During association (step 600), the non-AP station and the AP exchange messages to inform each other of their capabilities, in particular the capability to implement a mechanism for changing the non-AP station's MAC address when the non-AP station is associated with the AP ("ERCM capability"). For example, the ERCM capability may be declared using a frame format 700 as described with reference to FIG. 7.

[0184] An "ERCM key" is then obtained by the AP (step 610), as detailed above with reference to FIG.

[0185] In the embodiment depicted in Figure 6A, the request to change the MAC address of the non-AP station is sent by the AP (step 620), e.g., to the non-AP station (alternatively, the request may be sent to a third device in the network, which sends it to the non-AP). In the embodiment depicted in Figure 6B, the request to change the MAC address of the non-AP station is received at the AP, e.g., from the non-AP station (step 625). Alternatively, the request may be sent from a third device in the network to both the non-AP station and the AP, or from the non-AP station to a third device which sends it to the AP.

[0186] In one or more embodiments, the request may include a notification related to the ERCM change Date, e.g., the date and time when the change must be applied by both the non-AP station and the AP. Alternatively, the ERCM change Date may be obtained by other means at the non-AP station and the AP, e.g., from a third party device or according to a list of predefined times (regular or not) at which the MAC address must be changed.

[0187] Thereafter, a new MAC address is calculated by the non-AP station and the change is acted upon at the ERCM date (step 630), as described above with reference to Figure 4. Note that the new MAC address may be calculated at the ERCM date (e.g., at step 630) or before (e.g., between steps 620 / 625 and 630, or before 620 / 625). However, the effective change is performed when the ERCM date is reached.

[0188] 7 illustrates an example of a frame format for advertising a station's capability to support a MAC address change procedure in accordance with one or more embodiments of the present invention. The ERCM Capability field is used in the STA and the AP to advertise the capability to support ERCM.

[0189] In one or more embodiments, the ability of stations (non-AP stations and APs) to support the ERCM procedure may be signaled during association in an Extended Capabilities Information Element (IE) 700, as defined in Section 9.4.2.26 of the IEEE Std 802.11-2020 standard.

[0190] As shown in FIG. 7, the Extended Capabilities IE 700 includes three fields: an Element ID field 710, a length field 720, and an Extended Capabilities field 730. The Element ID field 710 is set to a value "127" corresponding to the extended "Extended Capabilities". The length field 720 indicates the number of octets of the Extended Capabilities field 730 excluding the Element ID field 710 and the length field 720. For illustrative purposes, it may be set to n=16 octets. The Extended Capabilities field 730 is a bit field indicating the extended capabilities advertised by the station transmitting the IE. The Extended Capabilities field is shown in Table 9-153 of the IEEE Std 802.11-2020 standard.

[0191] A previously reserved bit in the standard may be assigned to ERCM capability to indicate that a station supports ERCM procedures. This may correspond to the kth bit of the Extended Capabilities field 730, where k is an integer between 88 and 8*n, and n is the length of the Extended Capabilities field 730 in bytes. When this bit is set to 1, it may indicate that the station supports the ERCM procedure, and when this bit is set to 0, it may indicate that ERCM is not supported by the station.

[0192] A new row may be added to Table 9-153 - Extended Capabilities field in clause 9.4.2.26 of the IEEE Std 802.11-2020 standard.

[0193] Insert a new row in the Table 9-153- Extended Capabilities field in Section 9.4.2.26. TIFF2025501048000002.tif44152

[0194] As depicted in FIG. 8, in one or more embodiments, after association, encrypted information (ERCM key) is shared between the AP and the non-AP via a specific action frame.

[0195] FIG. 8 illustrates an example sequence of steps for initiating a procedure to change the MAC address of a non-AP station associated with an AP, in accordance with one or more embodiments of the present invention.

[0196] Initially, the non-AP station 120 may send a probe request (step 810) to initiate an association procedure with the AP 110. The probe request may include the Extended Capabilities IE 700 defined above with reference to FIG. 7, with the k-th bit of the Extended Capability field 730 corresponding to the ERCM Capability set to 1 ("ERCM cap=1" in FIG. 8).

[0197] The AP 110 may then send a probe response to the non-AP station 120 in response to the probe request (step 820). The probe response may also include an Extended Capabilities IE 700 with the k-th bit of the Extended capabilities field 730 corresponding to the ERCM Capability set to 1.

[0198] When both the AP 110 and the non-AP station 120 support ERCM, an ERCM procedure may be initiated, which is performed after an association procedure and the establishment of a security context so that the payload of a transmitted frame is encrypted.

[0199] In one or more embodiments, the ERCM procedure may be initiated by the AP 110. In such an embodiment, the AP 110 may send a request to the non-AP station 120 to obtain an ERCM key (step 830). Alternatively, the request may be sent to a third device, which sends it to the non-AP station 120. For example, the request may be an "ERCM Key delivery Request" 1010, as described in more detail below with reference to FIG.

[0200] Upon receiving the ERCM Key delivery Request, the non-AP station 120 may generate a key, e.g., 256-bit, called the ERCM key, which is intended to be used to generate the next MAC address of the non-AP station 120 at both the non-AP station 120 and the AP 110, as described above with reference to Figure 4. The ERCM key may be constant or may vary, e.g., per SSID, AP or ESS, or may be completely random.

[0201] Once the ERCM key is generated, the non-AP station 120 may send it in a message to the AP 110 (step 840). This message may be, for example, an “ERCM Key delivery Response” 1020, as described in more detail below with reference to FIG.

[0202] Upon receiving the message containing the ERCM key, the AP 110 may extract and store the key from the received message, and in optional step 850, the AP 110 may confirm receipt of the ERCM key to the non-AP station 120 by sending a confirmation message. For example, such a message may be an "ERCM delivery Confirm" 1030, as described in more detail below with reference to FIG.

[0203] According to another embodiment of the present invention, the ERCM procedure may be initiated by the non-AP station 120. In such an embodiment, the non-AP station 120 may generate and send an ERCM key to the AP 110 (step 840) without receiving an ERCM Key Delivery Request. In such an embodiment, step 830 is omitted.

[0204] Alternatively, the non-AP station 120 may send a request to the AP to change its MAC address (e.g., as in step 950 of FIG. 9B). In response to the request, the AP may send a request to the non-AP station to obtain an ERCM key (step 830). In such an embodiment, step 830 is performed.

[0205] Alternatively, regardless of whether the ERCM procedure is initiated by non-AP station 120 or AP 110, non-AP station 120 and AP 110 may already have the ERCM key and steps 830, 840 and 850 may be omitted.

[0206] 9A and 9B show an example of a sequence of steps for operating a procedure for modifying the MAC address of a non-AP station associated with an AP, according to one or more embodiments of the present invention. The modification procedure can be operated as soon as the initiation procedure (e.g., according to FIG. 8) is completed.

[0207] The change procedure basically includes two steps: calculation of a new MAC address for each non-AP station 120, and an effective change of the MAC address at a date and time, called the ERCM change Date, from which the new calculated MAC address is used for data exchange between the AP 110 and the non-AP station 120. Thus, during the change procedure, each non-AP station 120 changes its MAC address from a current value @mac(n) to a new value @mac(n+1).

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

[0209] Additionally, other privacy measures specified by IEEE Std 802.11-2020 for RCM may also be applied, for example, counters for all sequence number spaces used to identify data frames for non-AP station 120 may be reset, and non-AP station 120 may reset the seed used in the PHY DATA scrambler of the next transmitted PPDU.

[0210] According to one or more embodiments, both the AP 110 and the non-AP station 120 store a list of MAC addresses, and each time a change in the MAC address has to be performed, the next value on the list is selected as the new MAC address. However, such an embodiment may cause security problems if a third party has access to the list. It may also be envisaged to apply the same function on the AP side and the non-AP station side to determine, for example, the index corresponding to the next row of MAC addresses. This index may advantageously be determined randomly.

[0211] In an alternative embodiment, the next MAC address of the non-AP station 120 may be calculated randomly. For example, the AP 110 and the non-AP station 120 may use the same pseudorandom function (PRF) with the same input parameters. Thus, both the AP 110 and the non-AP station 120 obtain the same output @mac(n+1). The PRF may be used to calculate the leftmost 46 bits as described above. Generating the MAC address in a random or pseudorandom manner makes it impossible for a third party to predict the next address, which creates security concerns. Furthermore, there are already pseudorandom functions in standards (e.g., as specified in section 12.7.1.2 of the IEEE Std 802.11-2020 standard), and advantageously, this function may be reused within the framework of the present invention. Thus, no supplementary functionality is required to implement the present invention.

[0212] Upon request of either the AP or a non-AP STA, both the AP and the non-AP STA calculate, without sharing, a new temporary MAC address for the changing STA by using the standardized PRF-128 (Section 12.7.1.2 of IEEE Std 802.11-202) with the same parameters.

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

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

[0215] Alternatively, the next MAC address @mac(n+1) may be calculated using PRF-128 / 46 with the following three parameters: K is set to the ERCM key of the non-AP station, A is set to the string "ERCM", and B varies over time and corresponds to an arbitrary parameter known by the AP station and the non-AP station.

[0216] However, in the last two cases, it is necessary to make sure that the value of the parameter is actually the same in the AP and non-AP stations. For example, if B represents the current time, its value may be rounded to avoid differences in the values ​​in the non-AP and AP stations due to imperfect (even slight) synchronization of the clocks of the non-AP and AP stations. Also, new values ​​may be calculated simultaneously in the non-AP and AP stations (e.g., steps 913, 950 / 960, 970 in Fig. 9A, 9B). If B is the current MAC address, this problem does not arise.

[0217] 9A, the change procedure may be initiated by the AP 110 and may target all non-AP stations 120a, 120b of the BSS for which the initiation procedure was performed. In other words, according to these embodiments, the AP 110 indicates to all non-AP stations 120a, 120b for which the initiation procedure was performed that they must change their MAC addresses, and all these non-AP stations 120a, 120b change their MAC addresses simultaneously (ERCM change Date).

[0218] In the embodiment described below, the ERCM change date is expressed as a number of target beacon transmission times (TBTT). Of course, the ERCM change date can be expressed in other ways, such as the actual time (which may be rounded to avoid problems due to imperfect synchronization of non-AP and AP clocks).

[0219] As specified in the IEEE 802.11 standard, the AP 110 periodically (every TBTT) transmits a beacon frame, which is a management frame that contains information related to the network, to the non-AP stations 120a, 120b of the BSS. According to the embodiment depicted in FIG. 9A, the beacon frame may include a notification related to the ERCM change Date. For example, each beacon frame may include a counter field to indicate that a change of MAC address is in progress. For example, each beacon frame transmitted by the AP 110 to all non-AP stations 120a, 120b of the BSS may include an information element as described below with reference to FIG. 11. The counter may be initialized to a value corresponding to the time when the change must be acted upon (for example, an initial value of k may indicate that the change must be acted upon in (k+1) TBTTs, where k is an integer), and is decremented by one unit with each subsequent frame transmission. When the counter reaches a value of 0, the change must be acted upon. Thus, all subsequent frame transmissions following the beacon frame with the counter equal to 0 must be performed with the new MAC address.

[0220] Referring to FIG. 9A, the non-AP stations 120a, 120b receive a beacon frame containing a counter called ERCM Change counter set to a value k (step 911). This indicates that all non-AP stations 120a, 120b (for which the initiation procedure has been performed) must change their respective MAC addresses at the time corresponding to the (k+1) TBTT. Then, the next beacon frame containing an ERCM Change counter with a value of (k-1) is transmitted from the AP 110 to the non-AP stations 120a, 120b (step 712). After the (k+1) beacon frame transmission, the AP 110 transmits a beacon frame with an ERCM Change counter equal to 0 to the non-AP stations 120a, 120b (step 913), indicating that the respective MAC addresses of the non-AP stations 120a, 120b must be updated. All subsequent transmissions between the AP 110 and the non-AP stations 120a, 120b may be performed with the new MAC addresses of the non-AP stations 120a, 120b.

[0221] The repetition of the counter (and thus the ERCM change Date) in beacon frames following the first beacon frame (e.g., the one sent in step 911) indicating an upcoming MAC address change advantageously allows non-AP stations 120a, 120b to be notified that their MAC addresses must change even if they are in power safe or sleep mode. Indeed, even if one non-AP station misses one beacon frame, it may be woken up to receive at least one counter before the next ERCM change Date.

[0222] Note that a non-AP station may calculate a new MAC address at any time between steps 911 and 913, but the effective change must be made in step 913. Also, an AP may calculate a new MAC address before step 913 and make the effective change in step 913.

[0223] Although the embodiment of FIG. 9A uses beacon frames, it should be understood that other types of frames may be used as well.

[0224] According to an alternative embodiment shown in FIG. 9B, the modification procedure may be initiated by the non-AP station 120 .

[0225] A MAC address change request is sent from the non-AP station 120 to the AP 110 (step 950). This request may be an "ERCM change Request" 1040, as described below with reference to FIG. 10. This request may include a notification related to an ERCM change Date. For example, it may include a field indicating the date and time of the next address change in TBTTs (e.g., ERCM Change Date field 1043 as depicted in FIG. 10). For example, a value set to k may indicate that the change should be acted on in (k+1) TBTTs, and a value set to 0 may indicate that the next MAC address is applied immediately. Thus, all message transmissions following the transmission of a beacon frame associated with a counter equal to 0 are performed using the new MAC address.

[0226] In response to the request to change the MAC address, the AP 110 may acknowledge receipt of the request (step 960), for example, by sending an “ERCM change Response” 1050 to the non-AP station 120, as described with reference to FIG. 10.

[0227] According to an embodiment, when the non-AP station 120 sends a request to change its MAC address, it may implement a counter reflecting the ERCM change date (e.g., a counter equal to k or (k-1) if the ERCM change date is expressed in TBTT numbers). Each time a new beacon frame is received from the AP 110, the counter may be decremented by one unit. When the non-AP station 120 receives a beacon frame from the AP 110 corresponding to the ERCM date, e.g., when the counter reaches a value of zero (step 970), the change in MAC address is applied. The new MAC address may be valid at the beginning of the next TBTT. That is, all transmissions following the transmission of the beacon frame corresponding to the ERCM change date (step 970) are made with the new MAC address.

[0228] Note that an AP may calculate a new MAC address at any time between steps 950 and 970, but the effective change must be made in step 970. Also, a non-AP station may calculate a new MAC address before step 970 and make the effective change in step 970.

[0229] Although the example described with reference to Figures 9A and 9B uses beacon frames and expresses time in TBTT, other embodiments are possible. In this embodiment, it is only required that the notification regarding the time when the change is made is shared between the non-AP station and the AP, and that the non-AP station and the AP have a means to count the time. For example, as long as the non-AP station and the AP have access to the same or synchronized clocks, they can transmit the actual date and time. The change can be performed periodically or at a predetermined time.

[0230] Also, note that instead of Fig. 9A, the AP 110 may request that only one non-AP station 120 change its MAC address. To this end, an ERCM change Request (similar to Fig. 9B) may be sent from the AP 110 to the non-AP station 120.

[0231] FIG. 10 shows examples of frame formats for activating and operating the MAC address change procedure. All frame formats represented in FIG. 10 are identified by a "Category" field that is assigned to a specific previously reserved value in the range [31,125], as specified in Table 9-51 of IEEE Std 802.11-2020. For illustrative purposes, the category value assigned to an ERCM action frame may be set to 31 (or 31 for a Client RCM action frame or 32 for a BSS RCM action frame, depending on the station initiating the RCM procedure). Other values ​​may be used.

[0232] For example, the following could be added to Table 9-51- Category values: TIFF2025501048000003.tif24154, where k is an integer between 31 and 125.

[0233] The frame format represented in Figure 10 is identified by a one-octet "ERCM Action" field immediately following the Category field. The values ​​of the ERCM Action field may be defined in the following table inserted at the end of section 9.6 Action frame format details of the IEEE Std 802.11-2020 standard: TIFF2025501048000004.tif56151

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

[0235] For example, the ERCM Key Delivery Request 1010 may include a Category field 1011 set to a value of 31 and an ERCM Action field 1012 set to a value of 1.

[0236] The ERCM Key delivery Response 1020 may include a Category field 1021 set to a value of 31, an ERCM Action field 1022 set to a value of 2, and an ERCM Key field 1023 containing a 256-bit ERCM key.

[0237] The ERCM Key Delivery Confirm 1030 may include a Category field 1031 set to a value of 31 and an ERCM Action field 1032 set to a value of 3.

[0238] The ERCM change request 1040 may include a Category field 1041 set to a value of 31, an ERCM Action field 1042 set to a value of 4, and an ERCM Change Date field 1043. The ERCM Change Date field 1043 may indicate the date and time when the MAC address change will be applied. In one or more embodiments, this date and time may be expressed in number of target beacon transmit times (TBTT).

[0239] Other embodiments are possible. For example, the date and time at which the MAC address change is applied can be the actual date and time. In such an embodiment, the non-AP station and the AP must have their respective clocks sufficiently synchronized (or have access to such clocks) to prevent a change being made on one device and not the other.

[0240] The ERCM change response 1050 may include a Category field 1051 set to a value of 31 and an ERCM Action field 1052 set to a value of 5.

[0241] FIG. 11 is a diagram illustrating an example of a frame format for operating an AP-initiated MAC address change procedure in accordance with one or more embodiments of the present invention.

[0242] This corresponds to the information element (IE) defined in section 9.4.2 of the IEEE Std 802.11-2020 standard.

[0243] An IE dedicated to the ERCM procedure may be specified, called the ERCM IE 1100. The IE is identified by an Element ID 1110 and an Element ID Extension 1130 that are assigned specific values, previously reserved, in the range [99,255] specified in Table 9-92 of the IEEE Std 802.11-2020 standard. For illustrative purposes, the Element ID Extension to identify the ERCM IE may be set to 99.

[0244] The ERCM IE 1000 may include an Element ID field 1010 set to 255, a Length field 1020, an Element ID Extension field 1030 set to 99, and an ERCM Change counter field 1040.

[0245] The Length field 1020 indicates the number of octets of the IE 1000 excluding the Element ID field 1010 and the Length field 1020. The value is 2.

[0246] The ERCM Change counter field 1040 indicates the ERCM date corresponding to the date and time when the next MAC address must be applied. This may be expressed in target beacon transmit times (TBTT), and the integer value may correspond to the number of TBTTs until the next MAC address becomes valid. Other implementations are possible.

[0247] (Example of procedure for changing BPE AP parameters) Exemplary methods for changing the EUI or value of any BPE AP parameter of a BPE AP associated with a BPE non-AP station will now be described with reference to Figures 12A to 14. These exemplary methods implement the BSS RCM procedure (Figures 3A and 3B) described above.

[0248] Thus, a request to change the value of at least one BPE AP parameter is sent by the BPE AP to a BPE client, and although the target station for which the privacy parameter is to be changed is the BPE AP, the request may also notify the targeted BPE clients and notify each such targeted BPE client to also change the value of at least one BPE client parameter.

[0249] 12A and 12B illustrate steps performed at a BPE AP and a BPE client, respectively, to operate a BSS RCM procedure in accordance with one or more embodiments of the present invention. Preferably, each targeted BPE client performs the method of FIG. 12B.

[0250] On the BPE AP side, the method shown (FIG. 12A), in comparison with FIG. 3A, includes a decision procedure in steps 1210 and 1220 for selecting an appropriate strategy also for the BPE client modifying e.g. BPE client parameters.

[0251] Step 1210 relates to initiation of a BSS RCM procedure at the BPE AP, which may be based on various trigger criteria.

[0252] The BPE AP may take into account various triggering parameters or events (BSS RCM events) that, while improving privacy, are known to cause potential negative impacts in terms of QoS, e.g., causing a potential service interruption for legacy clients (due to the inability of the BPE AP or client to infer the new value of the parameter to be changed) and / or incurring additional computational costs for the BPE client to calculate new values ​​for the OTA MAC address or other BPE parameters, each time a BSS RCM procedure is applied.

[0253] A first exemplary trigger parameter is the maximum interval between the start of two BSS RCM procedures. For example, a BPE AP may periodically trigger a BSS RCM procedure to change at least one of its BPE AP parameters, possibly following a randomly generated privacy interval with a boundary value corresponding to the maximum interval between the start of two BSS RCM procedures.

[0254] A second exemplary trigger parameter is representative of the current state of the BSS. For example, this may be the number of associated BPE clients, the number of legacy clients, their ratio, the number of BPE and / or legacy clients in doze or active mode, measurements of current uplink and downlink traffic from and / or to the BPE and / or legacy clients. For example, an increase in activity (traffic, number of stations, number of BPE clients) may cause the BPE AP to trigger a BSS RCM procedure to change at least one of the BPE AP parameters.

[0255] A third exemplary trigger parameter is representative of the motion state of the BPE AP. For example, as long as the BPE AP is stationary, the BSS RCM procedure is not triggered (or is triggered periodically), whereas if the BPE AP is moving, the BSS RCM procedure may be triggered more frequently or based on the distance traveled by the BPE AP (e.g., the BSS RCM procedure is triggered when a certain distance threshold is exceeded).

[0256] These exemplary trigger parameters may be combined and other trigger parameters may be involved. For example, the BPE AP may proceed with initiating a BSS RCM procedure during the above mentioned privacy interval if it considers the adverse impact on service to be acceptable, expressed for example by legacy clients or / and BPE clients (whether in doze mode, transmitting UL data or not) being below a predefined threshold.

[0257] When a BSS RCM procedure is triggered, the BPE AP may select in step 1220 a BSS RCM policy that determines, for example, whether the BSS RCM procedure will modify only its BPE AP parameters (and therefore of the BSS) or whether it will also modify BPE client parameters of some of the BPE clients.

[0258] The BSS RCM policy may be selected from predefined policies based on a BSS RCM event or any of the parameters / events mentioned above. The selection of the BSS RCM policy is implementation dependent and outside the scope of the present invention.

[0259] By way of example only, three BSS RCM policies are defined as follows:

[0260] The first BSS RCM policy consists of modifying only BPE AP parameters (such as the OTA MAC address). The first policy is identified by BSS RCM Policy 0.

[0261] The second BSS RCM policy consists of modifying the BPE AP parameters and the BPE client parameters for all BPE clients in the BSS. The second policy is identified by BSS RCM Policy 1.

[0262] The third BSS RCM policy is for modifying BPE AP parameters and BPE client parameters for a subset of BPE clients in the BSS. The third policy is identified in BSS RCM Policy 2.

[0263] Of course, other policies may be defined that differ with respect to the number of BPE clients involved and / or with respect to the number of BPE client or AP parameters that are modified. As an example, two policies may differ based on the example policy above only by the number of BPE client or AP parameters that are modified.

[0264] In the following steps, the selected BSS RCM policy identifies the BPE clients (none of them, a subset of them, or all of them) involved in the BSS RCM procedure, in addition to the BPE APs whose BPE AP parameters also need to be modified.

[0265] The next step is step 310 already described and consists of generating a next / new value for at least one BPE AP parameter, which may include generating new values ​​for multiple BPE AP parameters.

[0266] If the BSS RM policy includes changes to BPE client parameters (Policy1 or Policy2), new values ​​for these BPE client parameters may also be calculated / generated for each of the participating BPE clients.

[0267] The generation relies on the use of a shared function (e.g. PRCM PRF). As an example to generate new values ​​for the OTA MAC addresses of the BPE AP and BPE client, the PRF-128 / 46 function is used, parameter A is set to the string "BSS RCM", parameter B is the current OTA MAC address of the station (BPE AP or one BPE client) for which the new value is generated, and key K is either the GPRCM key when generating the new OTA MAC address of the BPE AP or the IPRCM key corresponding to the BPE client for which the new OTA MAC address is generated.

[0268] Thus, the PRCM PRF is initiated by the BPE AP for each BPE station (AP or client) involved in the BSS RCM procedure (eg, BPE parameters such as OTA MAC address have to be changed).

[0269] If BSS RCM Policy 0 is selected, the PRCM PRF is only launched to generate the next / new value of the BPE AP parameter (e.g. OTA MAC address of the temporary BPE AP @AP_MAC(n+1)) with the parameters set as above (GPRCM key, OTA MAC address of the current BPE AP @AP_MAC(n) for parameter B). The next temporary BPE AP OTA MAC address @AP_MAC(n+1) corresponds to the 46 output random bits with U / L bit set to 1 and I / G bit set to 0. @AP_MAC(n+1) = PRF-128 / 46(GPRCM key, "BSS RCM", @AP_MAC(n)) with the U / L and I / G bits appended.

[0270] When BSS RCM Policy 1 or 2 is selected, the PRCM PRF is invoked to generate BPE client parameters (in addition to the BPE AP parameters) for each BPE client that is the subject of the BSS RCM procedure (all BPE clients in the BSS in the case of BSS RCM Policy 1, only some BPE clients in the BSS in the case of BSS RCM Policy 2).

[0271] For each targeted BPE client, the PRCM PRF is invoked to generate the next / new value of its BPE AP parameter, e.g. temporary BPE client OTA MAC address @CLIENT_MAC(n+1), with the parameters set as above (IPRCM key, current BPE client OTA MAC address @CLIENT_MAC(n), or parameter B AP OTA MAC address @CLIENT_MAC(n)). The next temporary client OTA MAC address @CLIENT_MAC(n+1) corresponds to the 46 output random bits with U / L bit set to 1 and I / G bit set to 0. @CLIENT_MAC(n+1) = PRF-128 / 46(IPRCM key, "BSS RCM", @CLIENT_MAC(n)) with the U / L and I / G bits appended.

[0272] With these policies 1 and 2, the BPE AP obtains a second key (IPRCM for each BPE client) and a second parameter having a value that changes over time (such as, but not limited to, an OTA MAC address for each BPE client) that is shared with the BPE AP, and calculates a new value of at least one BPE client parameter of the BPE client by using the current values ​​of the shared second key and the shared second parameter as inputs to a sharing function.

[0273] The next step is step 320 already described and consists of sending a BSS RCM start request indicating that a BSS RCM procedure has been initiated by the BPE AP.

[0274] The BSS RCM initiation request may correspond to an encrypted information element 1300 in a beacon frame as shown in FIG. 13, or a protected action frame 1400 as shown in FIG.

[0275] 13 is a diagram illustrating an example information element for signaling an ERCM procedure (and therefore a BSS RCM procedure) initiated by a BPE AP according to an embodiment of the present invention, which corresponds to an information element (IE) defined in chapter 9.4.2 of the IEEE Std 802.11-2020 standard.

[0276] This IE specified in the BSS RCM procedure is called the BSS RCM IE, which is an extension of the IE shown in Figure 11.

[0277] The BSS RCM IE is identified by an Element ID of 255 and an Element ID Extension that is assigned a previously reserved specific value in the range [99,255] specified in Table 9-92 of IEEE Std 802.11-2020. For illustrative purposes, the Element ID Extension for identifying the BSS RCM IE is 100. Thus, the request includes a policy field 1350 indicating whether the request notifies each of one or more targeted BPE clients (targeted stations different from the target station) to change the value of at least one of its BPE client parameters, where the policy field takes the following values: a first value signaling that the request is only a request to change the value of at least one privacy parameter of the BPE AP; a second value that informs the BSS that the request is targeted to all BPE clients and requests each targeted BPE client to change the value of at least one privacy parameter of the targeted BPE client; A third value that signals that the request is targeted to a subgroup of BPE clients of the BSS and requests each targeted BPE client to change the value of at least one privacy parameter of the targeted BPE client.

[0278] The BSS RCM IE 1300 includes an Element ID field 1110 set to 255, a Length field 1120 indicating the number of octets in the element excluding the Element ID 1110 and the Length field 1120, an Element ID Extension field 1130 set to 100, a BSS RCM Policy field 1350, a BSS RCM Change counter field 1140, and a BPE Clients Group field 1360.

[0279] The BSS RCM Policy field 1350 is a 2-bit value that indicates the BSS RCM Policy selected by the BPE AP to be applied. It is set to 0 (1, 2) if BSS RCM Policy 0 (1, 2) is selected.

[0280] The BSS RCM Change counter field 1140 is similar to the ERCM Change counter 1140 of Fig. 11. It is of course optional in that the target time at which the BPE parameter change must be made can be calculated locally by the station, as described in the embodiments below with reference to Figs. 17a to 20. The BSS RCM Change counter field 1140 indicates a BSS RCM Change date (target time) corresponding to the date and time at which the next randomized value change of the BPE privacy parameter should be applied. This is expressed in target beacon transmission times (TBTTs), and its integer value corresponds to the number of TBTTs until the next randomized value of the changing BPE privacy parameter becomes effective. For example, a value set to k may indicate that the change must be made in (k+1) TBTTs.

[0281] The BPE Clients Group field 1360 is an optional field present when the BSS RCM Policy is 2. The BPE Clients Group field 1360 is used to indicate the BPE client STAs involved in the BSS RCM procedures. As an example, this field is a bitmap similar to the Partial Virtual Bitmap field of the TIM element (clause 9.2.4.5 of IEEE Std 802.11-2020), where each BPE client has a specific bit in the Partial Virtual Bitmap based on the AID given by the BPE AP during the association phase. In the bitmap, a bit is set to 1 if the corresponding BPE client is involved in the BSS RCM procedures, and 0 otherwise.

[0282] 14 shows an exemplary protected action frame for operating a BSS RCM procedure, called a BSS RCM action frame, which is a variation of the action frame 1040 shown in FIG.

[0283] The new Category field 1410 is assigned a previously reserved specific value in the range [31,125], as specified in Table 9-51 of IEEE Std 802.11-2020. For illustrative purposes, the category value assigned to the BSS RCM action frame may be 31. Of course, other values ​​within the above range may be used. The Protected action frame also includes a BSS RCM Policy field 1350, an optional BSS RCM Change counter field 1140, and the BPE Clients Group field 1360 already described.

[0284] After sending the request, step 330 configures the BPE AP to run a BSS RCM procedure at the target time (eg, BSS RCM change Date).

[0285] The current value of at least one parameter of the BPE AP (eg, the OTA MAC address) is replaced in the registry by the calculated new value of that parameter.

[0286] The same applies to targeted BPE clients if BSS RCM Policy 1 or 2 is selected: the BPE AP replaces in the registry the current value of at least one BPE client parameter (e.g. OTA MAC address) for each targeted BPE client with the new value of the corresponding calculated parameter.

[0287] As shown in Figure 12B, the BPE client side process is very similar to that of Figure 3B. However, because of the notification of the BSS RCM Policy, step 350 is slightly adapted in accordance with one or more embodiments of the present invention. Thus, the illustrated process is executed by each BPE client of the BSS.

[0288] In step 350, the BPE client receives a BSS RCM Initiation request. According to the BSS RCM Policy field 1350 and, if present, the BPE Clients Group field 1360, the receiving BPE client decides whether it will participate in the BSS RCM procedure (and therefore whether one or more of the BPE client parameters, such as its OTA MAC address, must be changed). In other words, the BPE client determines from the request whether it belongs to the targeted BPE client specified in fields 1350 and 1360.

[0289] The next step is step 360, where the BPE client generates the next / new value of at least one BPE AP parameter, e.g. the OTA MAC address @AP_MAC(n+1) of a new temporary BPE AP, by invoking the PRCM PRF with the same input parameters as in step 310 (GPRCM key, OTA MAC address @AP_MAC(n) of the current BPE AP in parameter B).

[0290] Furthermore, if the determination in step 350 is positive (meaning the BPE client has been targeted by the BSS RCM procedure), the next / new value of the parameter of that BPE client to be changed, e.g. the OTA MAC address @Client_MAC(n+1) of the new / next temporary BPE client, is also generated by invoking the PRCM PRF again with the same input parameters as in step 310 (IPRCM key, current OTA MAC address of parameter B @Client_MAC(n)).

[0291] This causes the BPE AP and the BPE Client to calculate the same new values ​​for the same BPE parameters.

[0292] Finally, step 370 consists of the BPE client running a BSS RCM procedure at the target time (e.g., the time specified in the BSS RCM change Date field 1140). The current value of at least one BPE AP parameter (e.g., the OTA MAC address) is replaced in the registry by the calculated new value of that parameter.

[0293] Moreover, the same applies to its BPE client parameters that are changed if the BPE client is involved in BSS RCM procedures with BSS RCM Policy 1 or 2. The BPE client replaces in the registry the current values ​​of the BPE client parameters (e.g. OTA MAC address) with the corresponding calculated new parameter values.

[0294] (Randomized simultaneous value generation procedure) The embodiments described above focus on computing a single new value of a BPE or CPE parameter from an iteration or invocation of the PRCM PRF, which new value replaces the current value of that parameter at a target time explicitly specified in the request.

[0295] It is contemplated that embodiments of the present invention may be used to allow multiple privacy parameters of a target station to be modified. A possible implementation includes multiple simultaneous iterations of the PRCM PRF, each using dedicated K, A, B parameters to generate a new randomized value of one privacy parameter (e.g., A may be a string unique to each privacy parameter and / or B may be the current value of the target privacy parameter). However, the complexity and cost of implementing such a solution may not be acceptable considering the number of privacy parameters that must be considered both at the AP station side and at each non-AP station side.

[0296] Also, in the above embodiment, the target time is not explicitly signaled in the request, but is calculated on the side of each station. To ensure that each station has the same target time, a possible embodiment includes using another iteration of the PRCM PRF to obtain the target time. In other words, the station may determine a value representing the target time at which the value of at least one privacy parameter is to be changed by using a shared function with inputs including the current value of the shared parameter (e.g., parameter B).

[0297] Again, this is not entirely satisfactory due to the complexity and cost of performing multiple iterations of the PRCM PRF.

[0298] Thus, embodiments of the present invention provide for using a single iteration of (i.e., a single call to) the PRCM PRF to generate multiple values ​​at once that can be used as new values ​​for a privacy parameter and / or a target time. In this regard, a station (AP or non-AP) that must compute such values ​​obtains a plurality of bits by applying a shared function to the input, and uses a first subset of the multiple bits as the new value for a privacy parameter to be modified, and a second subset of the multiple bits as the new value for another privacy parameter to be modified or a value representing the target time.

[0299] Thus, these embodiments propose a global procedure to perform simultaneous random modification of multiple privacy parameters and target times without exchanging them over the network (avoiding third-party eavesdropping). The generation of new randomized values ​​for a set of privacy parameters is performed at once, reducing the complexity and cost of implementation.

[0300] An example application of these embodiments is to allow a station (BPE or CPE, AP or non-AP STA) to simultaneously randomly change the values ​​of a set of privacy parameters when it changes its MAC address (itself a privacy parameter) without exchanging new randomized values ​​over the air.

[0301] A first embodiment is described with reference to Figures 15A to 16B, focusing on the generation of multiple new values ​​for multiple BPE / CPE parameters of the same station. In these first embodiments, the CPE station (Figures 2A and 2B) or the BPE station (Figures 3A and 3B) obtains said multiple bits by applying a shared function to the input, determines a new value of a first privacy parameter of the target station from a first subset of the multiple bits, and determines a new value of a second, different privacy parameter of the target station from a second subset of the multiple bits. Of course, new values ​​of more privacy parameters can be generated using one and the same iteration of the shared function.

[0302] Second embodiments are described with reference to Figures 17A to 20, focusing on the generation of a target time using the same iteration of the PRCM PRF that generates new values ​​for the BPE / CPE parameters. In these second embodiments, the CPE station (Figures 2A and 2B) or the BPE station (Figures 3A and 3B) obtains a plurality of bits by applying a shared function to an input, determines a new value for at least one privacy parameter from a first bit subset of the plurality of bits, and determines a value representing a target time at which the value of the at least one privacy parameter is to be changed from a second bit subset of the plurality of bits.

[0303] Of course, the first and second embodiments may be combined together, for example the obtained bits may consist of a first binary portion divided into subsets of bits corresponding to new values ​​of privacy parameters of the same target station, and a second binary portion providing one or more target time values.

[0304] (Simultaneous generation of randomized values ​​of privacy parameters) Returning to the first embodiment, a list of privacy parameters, called Privacy Enhancement (PE) list, may be assigned by the AP or negotiated between the AP and non-AP STAs during association. The CPE list may consist of privacy parameters of non-AP stations, and the BPE list may consist of privacy parameters of BPE APs. The PE list may consist of the CPE list and the BPE list. In the following, the PE list may refer to either of these lists.

[0305] The PE list is ordered. For this purpose, a rank is assigned to each privacy parameter and the PE list is ordered according to this rank. These ranks are either pre-determined or assigned during association between the AP station and the non-AP STA. Thus, the same order is known by the stations.

[0306] Figure 15A shows a CPE list of five privacy parameters for non-AP stations (CPE clients, extendable to BPE clients). This ordered list declares first the 46-bit OTA MAC address of the non-AP station (46 bits because the U / L and I / G bits are fixed), then a 12-bit Sequence Number, then a 48-bit Packet number, then a 16-bit AID, and finally a 7-bit Scrambler Seed. Any other ordering is possible. Similarly, any other set of CPE privacy parameters is possible.

[0307] Figure 15B shows a BPE AP list consisting of four privacy parameters of a BPE AP station. This ordered list declares first the 46-bit OTA MAC address of the BPE AP, then the 7-bit Scrambler Seed, then the 16-bit Beacon Interval, and finally the 6-bit BSS Color. Any other ordering is possible. Similarly, any other set of BPE AP parameters is possible.

[0308] The generation of new values ​​for the privacy parameters of the PE list occurs in steps 210 and 260 (FIGS. 2A and 2B) or steps 310 and 360 (FIGS. 3A and 3B).

[0309] A shared function is a function that generates a pseudo-random bit string of a given length from a set of input parameters. In the following description, the output binary string is called the PE output and is divided into predefined "chunks" or subsets of bits. Each chunk or subset is assigned to one of the privacy parameters in the PE list, providing a new random value.

[0310] A PE correspondence or lookup table may be used that indicates the assigned chunk / subset in the PE output for each privacy parameter in the PE list. The same table may be generated locally by the AP and non-AP STAs based on the ranking / order declared or negotiated during association.

[0311] A chunk or subset is characterized by its first bit (start position) and last bit (end position) in the PE output, and its length corresponds to the length of the assigned privacy parameter.

[0312] Preferably, the chunks or subsets are disjoint, meaning that they do not overlap in the PE output. As a result, the generated PE output must have a length at least equal to the length of the PE list (which corresponds to the sum of the lengths of its elements).

[0313] According to one embodiment, the shared function is the PRCM PRF mentioned above. Section 12.7.1.2 of the IEEE Std 802.11-2020 standard specifies six PRF functions: PRF-128, PRF-192, PRF-256, PRF-384, PRF-512 or PRF-704, which generate 128, 192, 256, 384, 512 or 704 randomized bits, respectively. Thus, depending on the desired PE output length, the appropriate PRF function is selected.

[0314] As mentioned above, alternatively, the shared function can be any block cipher algorithm that makes it possible to encrypt blocks.

[0315] Taking the Client RCM procedure initiated by the CPE client (FIGS. 2A and 2B) as an example, the CPE client (at step 210) or the CPE AP (at step 260) uses a shared function corresponding to a PRF selected according to the CPE list to generate a number of pseudo-random bits, more specifically, a number greater than the length of the CPE list. As an example, the CPE list of FIG. 15A requires a length equal to 129 bits. Thus, PRF-192 may be selected, which generates 192 pseudo-random bits, where only the leftmost 129 bits (e.g., the most significant 129 bits) match the privacy parameter of the CPE list.

[0316] FIG. 16A illustrates a CPE correspondence table showing the matching between each chunk or subset of the Shared Function Output (CPE Output) and one of the CPE Privacy Parameters. In this example, the CPE Output is split into five chunks corresponding to the five CPE Parameters of FIG. 15A. The new random value for the OTA MAC Address corresponds to the chunk starting at the first bit of the CPE Output through the 46th bit. The new random value for the SN corresponds to the chunk starting at the 47th bit of the CPE Output through the 58th bit. The new random value for the PN corresponds to the chunk starting at the 59th bit of the CPE Output through the 106th bit. The new random value for the AID corresponds to the chunk starting at the 107th bit of the CPE Output through the 122nd bit. The new random value for the Scrambler Seed corresponds to the chunk starting at the 123rd bit of the CPE Output through the 129th bit.

[0317] In effect, when a CPE output is generated, new random values ​​for each CPE parameter of a CPE client can be obtained directly by simply extracting from the allocated chunk. Thus, in one iteration of PRF-192, each CPE client and the CPE AP can obtain all of the new values ​​of the CPE parameters.

[0318] Now, taking the BSS RCM procedure initiated by the BPE AP (FIGS. 3A and 3B) as an example, the BPE AP (at step 310) or the BPE client (at step 360) uses a shared function corresponding to a PRF selected according to the BPE AP list, more specifically to generate a number of pseudo-random bits greater than the length of the BPE AP list. As an example, the BPE AP list in FIG. 15B requires a length equal to 75 bits. Thus, a PRF-128 may be selected, which generates 128 pseudo-random bits, from which only the leftmost 75 bits (e.g., the 75 most significant bits) match the privacy parameter of the BPE AP list.

[0319] FIG. 16B shows a BPE correspondence table that shows the matching of each chunk or subset of the Shared Function Output (BPE Output) with one of the BPE AP parameters. In this example, the BPE output is split into four chunks. The new random value for the OTA MAC Address corresponds to the chunk starting at the first bit of the BPE output through the 46th bit. The new random value for the Scrambler Seed corresponds to the chunk starting at the 47th bit of the BPE output through the 53rd bit. The new random value for the Beacon Interval corresponds to the chunk starting at the 54th bit of the BPE output through the 69th bit. The new random value for the BSS Color corresponds to the chunk starting at the 70th bit of the BPE output through the 75th bit.

[0320] In fact, once the BPE output is generated, new random values ​​for each BPE AP parameter can be obtained directly by simply extracting from the allocated chunk. Thus, in one iteration of PRF-128, the BPE AP and each BPE client can obtain all of the new values ​​for the BPE AP parameters.

[0321] Furthermore, according to the BSS RCM Policy applied to the BSS RCM procedure by the BPE AP, the procedure may also include changing the values ​​of BPE client parameters of some or all BPE clients. As an example, the CPE list mentioned above may be used as the list of BPE client parameters to be changed.

[0322] In such a policy, as described above, the BPE AP must generate new values ​​for those BPE client parameters for each targeted BPE client (step 310), while the BPE client must generate new values ​​for its own BPE client parameters if targeted (e.g., the relevant bits are enabled in bitmap 1360 for BSS RCM Policy 1 or BSS RCM Policy 2) (step 360).

[0323] Each of these generations may be performed along the lines described above with reference to Figures 15A and 16A for the CPE list. Each generation requires one iteration of the PRF-192 function. Once the corresponding output has been generated, new random values ​​for each BPE client parameter may be obtained directly by simply extracting from the allocated chunk. Thus, in one iteration of PRF-192, the BPE AP and the BPE client can obtain all new values ​​of the BPE client parameters for that BPE client.

[0324] (Simultaneous generation of randomized values ​​for privacy parameters and target times) Returning to the second embodiment, where a PE (CPE or BPE) output is also used to provide a value representing a target time at which that CPE / BPE parameter or value is to be changed, it is clear that, for example, the unused portion of the CPE output (bits 130 to 192 in FIG. 16A) or the unused portion of the BPE output (bits 76 to 128 in FIG. 16B) can be used to define the target time.

[0325] 17A-17D are example flow charts illustrating a method for changing a MAC address of a non-AP station associated with an AP according to some embodiments of the present invention.

[0326] For ease of explanation, refer to Figure 4, where steps 400 and 410 are part of a process called the "initiation procedure", in which stations (APs and non-APs) declare their capabilities and may exchange ERCM keys (GPRCM and / or IPRCM depending on the scenario). A detailed example of the initiation procedure is provided above with reference to Figure 8.

[0327] In step 420, when the ERCM procedure is triggered, the next value of the non-AP station's MAC address is calculated by both the AP and the non-AP station (step 421). Furthermore, they determine a value representative of the target time at which the non-AP station's MAC address must be changed. In one or more embodiments, the value representative of the time at which the non-AP station's MAC address must be changed may be an integer value used as an initial value of a counter called an "ERCM counter". For simplicity, this determined value is hereinafter referred to as the "ERCM counter value". The time at which the non-AP station's MAC address must be changed, called the "ERCM date" or "ERCM change date", is defined by the ERCM counter value. For example, the ERCM counter value may represent the number of unit times at which the MAC address must be changed, and the ERCM date may correspond to the time that the determined number of unit times has elapsed since the triggering of the ERCM procedure 420. In another embodiment, described further below, the ERCM counter value determined in step 422 may be multiplied by an integer value called an "ERCM scaling factor" to obtain the number of unit times at which the MAC address must be changed.

[0328] In step 421, the next value of the non-AP station's MAC address is obtained in parallel by both the non-AP station and the AP, as described above with reference to FIG.

[0329] Once the next value of the non-AP station's MAC address is obtained, the change (from the current MAC address to the next MAC address) must be performed at the same target time, called the "ERCM date", to guarantee that both stations use the same MAC address of the non-AP station and to avoid frame loss (in case of frames sent with a MAC address field that does not correspond to the non-AP station's current MAC address). A possible solution is for one station to send a notification related to the ERCM date to the other station. However, this may cause problems in terms of privacy. Indeed, if the ERCM date is exchanged between the non-AP station and the AP, this ERCM date can be restored by a third party to detect the change of the MAC address. Another solution is to perform the address change periodically without exchanging information related to the ERCM date, but this too can be tracked by a third party identifying these periodic requests.

[0330] To overcome this privacy issue, the second embodiment of the present invention proposes that both the non-AP station and the AP determine the same value, called the ERCM counter value mentioned above, which represents the time, called the ERCM date, at which the MAC address of the non-AP station must be changed in step 422. For example, the ERCM counter value can be an integer value representing the number of Target Beacon Transmission Times (TBTT, 1TBTT corresponds to 100 milliseconds in the 802.11 standard) or unit time (TU, 1TU corresponds to 1024 milliseconds in the 802.11 standard) until applying the change of the MAC address of the non-AP station in both the non-AP station and the AP. Since no information related to the ERCM procedure is exchanged between the AP and the non-AP station, privacy is further improved.

[0331] In one or more embodiments, both the AP station and the non-AP station may calculate the ERCM counter value in step 422 by using the same function with the same set of input parameters, thus ensuring that the results are the same at both the non-AP station and the AP station.

[0332] After obtaining the value of the next MAC address of the non-AP station and the value of the ERCM counter, both the non-AP station and the AP wait for the ERCM date defined by the ERCM counter value to be reached in order to apply the change of the MAC address (step 430). In one or more embodiments, each of the non-AP station and the AP may have a respective counter initialized to the ERCM counter value determined in step 422, and each counter may be decremented by one unit for each unit of time that has elapsed. For example, if the ERCM date is expressed in terms of the number of TBTTs, the ERCM counter value k determined in step 422 may be an integer value representing the number of TBTTs until the change of the MAC address is applied (e.g., replacing the current value of the MAC address with the new value obtained in step 421). The AP may store the counter with an initial value set to k, and each time the AP broadcasts a beacon frame after the trigger of the ERCM procedure (step 420) (e.g., each TBTT), the counter of the AP is decremented by one unit. When the counter reaches the value zero, the change is applied. A non-AP station may implement a similar counter, where upon receiving the first beacon frame following the triggering of the ERCM procedure (step 420), the counter is initialized to a value k and the counter is decremented by 1. When the counter reaches the value zero, the change is applied.

[0333] According to an embodiment, this change may be applied by the AP and non-AP stations immediately after the reception of the (k+1)th beacon frame following the triggering of the ERCM procedure (step 220), which means that all frames following the transmission / reception of this (k+1)th beacon frame are transmitted with the new value of the MAC address of the non-AP station. Of course, other embodiments are possible. For example, the change may be applied by the AP and non-AP stations immediately after the reception of the kth beacon frame following the triggering of the ERCM procedure (step 420).

[0334] As will be described in further detail below, several events may trigger the ERCM procedure (step 420). For example, the ERCM procedure may be triggered as soon as the initiation procedure is performed, in particular upon receipt of an ERCM key by the AP (step 840 in FIG. 8) or upon receipt by a non-AP station of a confirmation message that the AP has received the ERCM key (step 850 in FIG. 8). The ERCM procedure may also be triggered by receipt by the AP or the non-AP station of a request for a change of the non-AP station's MAC address (described in more detail with reference to FIG. 20). The ERCM procedure may also be triggered by a change of the non-AP station's MAC address (step 430). In other words, as soon as a change of the non-AP station's MAC address is performed, a new ERCM procedure is initiated. It should be understood that these examples are not independent and mutually exclusive embodiments of the invention. In the same embodiment of the invention, several different types of events may trigger the ERCM procedure.

[0335] 2A, when the ERCM date defined in the ERCM counter is reached, e.g., when the values ​​of the respective counters of the AP and the non-AP station are both equal to zero, the change in the MAC address is applied in the AP and the non-AP station (step 430). For example, the respective registers of the non-AP station and the AP may be updated with the new value of the MAC address of the non-AP station obtained in step 421. As soon as step 430 is executed, this new value is used for communication between the non-AP station and the AP. As described above, a new ERCM procedure 420 may be initiated immediately after the change.

[0336] Now referring to FIG. 17B, a first specific embodiment of the method of FIG. 17A is shown, in which the ERCM procedure is triggered completely automatically, without exchange of requests to change the MAC address of the non-AP station. Steps 400, 410 and 420 are similar to FIG. 17A. As described above, during the ERCM procedure (step 420), an ERCM counter value may be determined, e.g., calculated by both the AP station and the non-AP station by applying the same function to the same set of input parameters. Each station may start a respective counter whose value is initially set to the ERCM counter value calculated in step 420 and decremented at each unit time.

[0337] In each station, the counter continues to be decremented every unit of time, unless the counter reaches the value 0 (step 425, arrow "N") or another predefined value common to both stations, in which case the new value of the MAC address obtained in step 420 is applied (step 230) and a new ERCM procedure is initiated (step 420).

[0338] FIG. 17C illustrates another embodiment, in which the ERCM procedure can be triggered automatically and also upon receipt of a request for a change of the MAC address of a non-AP station (also called a “change request” or “ERCM change request”).

[0339] Steps 400, 410 and 420 are similar to FIG. 17A. As described above, during the ERCM procedure (step 420), the ERCM counter value may be calculated and determined, for example, by both AP and non-AP stations by applying the same function to the same set of input parameters. Each station may start a respective counter whose value is initially set to the ERCM counter value calculated in step 420 and decremented at each unit time. In each station, when the counter reaches a value of 0 (step 425, arrow "Y"), the new value of the MAC address obtained in step 420 is applied (step 430) and a new ERCM procedure is started (step 420).

[0340] As long as the counter has not reached the value 0 (step 425, arrow "N"), a request to change the MAC address of the non-AP station may be exchanged between the non-AP station and the AP (step 427, arrow "Y"). This request may be sent from the non-AP to the AP (alternatively, the request may be sent to a third device in the network, which in turn sends it to the AP) or from the AP to the non-AP station (alternatively, the request may be sent to a third device in the network, which in turn sends it to the non-AP station). Note that these embodiments are not mutually exclusive and may coexist in the same non-AP station. For example, the AP may be configured to indicate to the non-AP station at certain times that the non-AP station needs to change its MAC address (e.g., to ensure that all non-AP stations in the BSS periodically change their respective MAC addresses), while the non-AP station may be configured to indicate that it wants to change its MAC address at other times corresponding to certain events (e.g., when the non-AP station is stationary for a predefined time or when it transmits the same type of traffic for a predefined time). Alternatively, the request may be sent from a third device in the network to both the non-AP station and the AP, examples of such requests are detailed with reference to Figures 18 and 20.

[0341] Once a change request is received by at least one of the AP and non-AP stations (step 427, arrow "Y"), a new ERCM procedure may be initiated (step 420). The previously obtained next MAC address value and ERCM counter value are replaced with the next MAC address value and ERCM value obtained during the new ERCM procedure 420. The initial value of the station's counter may be set to the ERCM value determined during the new ERCM procedure, and the process may continue as detailed above with the values ​​obtained in the new ERCM procedure 420.

[0342] For the counters to be synchronized between the AP and non-AP stations, they must be initialized and decremented at the same time, e.g., at the receipt or transmission of the first beacon frame immediately following the receipt or transmission of the change request in step 427. It will be appreciated that in such an embodiment, a new ERCM procedure 420 must be performed after the receipt of the change request by one of the stations (step 420) and before the AP transmits the next beacon frame.

[0343] Other embodiments are possible. For example, the calculation of the MAC address and the next value of the ERCM counter in step 430 may be performed at the time of reception or transmission of the beacon frame immediately following the reception of the change request in step 427, and the counter may be initialized at the time of reception or transmission of the next beacon frame. It is understood that the important point is that the AP and the non-AP station are configured to initialize and start decrementing the counter and apply the MAC address change at the same time.

[0344] As long as a change request is not received from at least one of the AP and non-AP stations (step 427, arrow "N"), the counter value continues to be decremented every unit time.

[0345] In one or more embodiments, the change request may include a field indicating that the change of the MAC address should be applied "immediately", e.g., immediately after transmission or reception of a beacon frame following receipt of the change request. For example, the change request may be an "ERCM Change Request" 1840 (described below with reference to FIG. 18 ) that includes an "ERCM Reset" field 1844 or an "ERCM Scaling factor" field 1843 set to a predefined value. In these embodiments, the ERCM counter value is not determined during an ERCM procedure 420 subsequent to receipt of the change request 427, but is set to a value of zero. Also, the next value of the MAC address obtained in step 420 may advantageously differ from the value of the MAC address obtained in the previous ERCM procedure 420.

[0346] Such an embodiment may be useful, for example, when the counters of the non-AP station and the AP become out of sync. This may occur, for example, because the non-AP station is in a power-safe or sleep mode and misses one or more beacon frames transmitted by the AP. Thus, the counters of the non-AP station may be decremented at the AP but not at the non-AP station. In this case, a change in MAC address is made by the AP but not at the non-AP, causing a mismatch in the MAC address of the non-AP station in frames exchanged between the non-AP station and the AP, which may result in the frame being lost. This loss may be detected by the non-AP station and / or the AP, which may send a notification to the other station that the change needs to be applied immediately. Prompting an immediate change in the MAC address of the non-AP station may also be useful, for example, when the AP detects that the next value of the MAC address calculated in step 230 is already assigned to another non-AP station (even though such a case is very rare). Also, a change in the MAC address of the non-AP station may be required depending on the application of the non-AP station.

[0347] Additionally or alternatively, the change request may include a field indicating an integer value called a "scaling factor" or "ERCM Scaling Factor" that may be used to increase or decrease the time between changes in the value of the MAC address of non-AP stations. If this field is present in the change request, the ERCM counter value determined in step 420 may be multiplied by the integer value to obtain the number of units by which the next change must be performed. For example, the change request may be an "ERCM Change Request" 1840 (described below with reference to FIG. 18) that includes an "ERCM Scaling factor" field 1843 set to a predetermined value.

[0348] Such an embodiment is advantageous since it allows to adjust the frequency of the changes according to the context: for example, if the changes are made too frequently, data frames may be lost (e.g. data frames prepared before the change and containing the old value of the MAC address) and it may be useful to increase the time between two changes.

[0349] FIG. 17D illustrates yet another embodiment in which the ERCM procedure is triggered only upon receipt of a change request.

[0350] Steps 400, 410 and 420 are similar to FIG. 17A. In the embodiment of FIG. 17D, the ERCM procedure is not triggered unless a change request is exchanged between the AP and the non-AP station (step 415, arrow "N"). When a change request is received by the AP and / or the non-AP station (step 415, arrow "Y"), the ERCM procedure is executed (step 420), during which the next value of the MAC address of the non-AP station and the ERCM counter value can be obtained. Then, each station, the AP and the non-AP station, can start a respective counter, which is initially set to the ERCM counter value calculated in step 420 and is decremented every unit time. When the counter reaches the value 0 in each station (step 425, arrow "Y"), the new value of the MAC address obtained in step 420 is applied (step 430). Then, when a subsequent change request is received by the AP and / or the non-AP station, a new ERCM procedure is started.

[0351] It should be noted that, according to different embodiments, the above method related to the second embodiment may be applied to only one non-AP station in the BSS, to a subgroup of non-AP stations (each AP-non-AP station pair to which the modification method is applied in parallel), or to all non-AP stations in the BSS.

[0352] For example, if the procedure for changing the MAC address is initiated by a non-AP station, the non-AP station may send a request to the AP indicating that the non-AP station wants to change its MAC address. In this case, the change only concerns that non-AP station. If the procedure for changing the MAC address is initiated by an AP, the AP station may send a unicast request to a specific non-AP station indicating that it must change its MAC address. Alternatively, it may send a multicast request to a group of non-AP stations, and all non-AP stations in this group must change their MAC addresses. As yet another alternative, the AP may send a broadcast request (e.g., via a beacon frame) to all non-AP stations in the BSS, and all non-AP stations in the BSS must change their MAC addresses.

[0353] It should be noted that the steps of Figures 17A through 17D may be performed by both the non-AP station and the AP, and if a change is initiated by an AP and involves multiple non-AP stations, the steps of Figures 17A through 17D, when performed by the AP, are performed independently for each non-AP station of the multiple non-AP stations.

[0354] As described above, in the process of Figures 17A to 17D, both the AP and the non-AP station need to obtain the same next value of the non-AP station's MAC address. Also, the change of the MAC address must be performed simultaneously by the non-AP station and the AP. In one or more embodiments, the new value of the MAC address and the value of the ERCM counter can be advantageously determined by applying the same function to a set of input parameters that are the same for the non-AP station and the AP station. Thus, the result is the same for the non-AP station and the AP station. In one or more embodiments, the function can be a pseudo-random function, as defined above (Figure 4).

[0355] The value of the ERCM counter (step 430) may be advantageously calculated from the set of remaining bits generated by the PRF that are not used to determine the new MAC address.

[0356] Using the same result of a unique function to calculate both the new MAC address of the non-AP station and the ERCM counter value advantageously limits the number of operations to be performed. The use of a PRF has the advantage that no new function is required compared to the standard and the tracking is more complicated since the values ​​are generated in a pseudo-random manner. Furthermore, using a pseudo-random function to calculate the ERCM counter value is particularly advantageous when multiple non-AP stations are involved in the MAC address change, and distributes the time when different non-AP stations change their MAC addresses, thus avoiding a bottleneck on the AP side. Of course, other embodiments are possible. For example, a function other than the PRF may be used and / or two different functions may be used to calculate the new value of the MAC address and the value of the ERCM counter.

[0357] In the following, the current value of the MAC address of non-AP station 120 is represented as @mac(n), the next value of the MAC address of non-AP station 120 (applied to the ERCM date) is represented as @mac(n+1), and the ERCM counter that defines the ERCM date is represented as CC(n+1).

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

[0359] Additionally, other privacy measures specified by IEEE Std 802.11-2020 for RCM may also be applied, for example, counters for all sequence number spaces used to identify data frames for non-AP station 120 may be reset, and non-AP station 120 may reset the seed used in the PHY DATA scrambler of the next transmitted PPDU.

[0360] In one or more embodiments, the next MAC address @mac(n+1) and the ERCM counter CC(n+1) of the non-AP station 120 may be calculated randomly. For example, @mac(n+1) and CC(n+1) may be obtained from the result of the same pseudorandom function (PRF) applied to the same input parameters by the AP 110 and the non-AP station 120. Thus, both the AP 110 and the non-AP station 120 obtain the same output @mac(n+1) and CC(n+1). The standard pseudorandom function (e.g., as defined in section 12.7.1.2 of the IEEE Std 802.11-2020 standard) may be advantageously reused within the framework of the present invention. Thus, no supplementary functionality is required to implement the present invention.

[0361] For example, the next MAC address @mac(n+1) and ERCM counter value CC(n+1) may be calculated using the PRF with three parameters: K is set to the non-AP station's ERCM key, A is set to the string "ERCM", and B is set to the non-AP station's current MAC address @mac(n). That is, PRF-128(ERCM key, "ERCM", @mac(n), 128).

[0362] From the 128 bits thus generated, the leftmost 46 bits (e.g., the most significant 46 bits) may be used to define the next value of the MAC address @mac(n+1), where the 48 bits @mac(n+1) correspond to the 46 randomized bits resulting from the PRF-128 / 46 plus two fixed bits, the U / L bit of the new MAC address set to 1, and the I / G bit set to 0.

[0363] Furthermore, from the generated 128 bits, one or more of the 128-46=82 remaining bits (e.g., bits not used in the calculation of @mac(n+1)) may be used to calculate the ERCM counter value CC(n+1). For example, the rightmost m bits (e.g., m least significant bits, m being an integer from 1 to 82, preferably an integer from 3 to 10) may be selected to determine the value of the ERCM counter CC(n+1). Thus, no additional calculation is required to determine the ERCM counter value CC(n+1). According to an embodiment, an integer value obtained from the selected m bits may be multiplied by a factor called a "scaling factor" which will be described in detail below with reference to FIG. 18, and the result may correspond to the ERCM counter value.

[0364] Alternatively, @mac(n+1) and CC(n+1) may be computed using PRF-128 with the following three parameters: K is set to the non-AP station's ERCM key, A is set to the string "ERCM", and B is the current time.

[0365] Alternatively, @mac(n+1) and CC(n+1) may be computed using PRF-128 with the following three parameters: K is set to the non-AP station's ERCM key, A is set to the string "ERCM", and B corresponds to an arbitrary parameter that varies over time and is known to the AP and non-AP stations.

[0366] However, in the last two cases, we need to make sure that the value of the parameter is actually the same in the AP and non-AP stations. For example, if B represents the current time, we can round its value to avoid it being different in the non-AP station and the AP due to imperfect (even slight) clock synchronization between the non-AP station and the AP. If B is the current MAC address, this problem does not occur.

[0367] It should be noted that in the case of FIG. 17C, when a modification request is received (step 427, arrow "Y"), a new ERCM procedure is initiated (step 420), during which a new value of the MAC address can be calculated. As mentioned above, this new value of the MAC address can advantageously differ from the value of the MAC address calculated in the previous ERCM procedure (interrupted by the reception of the modification request). For this reason, the new value of the MAC address can be calculated as a function of the previously determined (but not applied) value of the MAC address instead of the current value of the MAC address. For example, if @mac2(n+1) denotes the value of the MAC address determined during a new ERCM procedure (for example the ERCM procedure initiated upon reception of the modification request) and @mac1(n+1) denotes the value of the MAC address determined during the previous ERCM procedure (interrupted by the reception of the modification request), then @mac2(n+1) can be determined by applying the following function: PRF-128(ERCM key, "ERCM", @mac1(n+1),128) Of these, the leftmost 46 bits are retained.

[0368] The sequence of steps for activating the procedure as shown in FIG. 8 also applies to these second embodiments.

[0369] Figure 18 shows an exemplary frame format of an ERCM Change Request consistent with the second embodiment. The other frame formats of Figure 10 apply to other types of frames exchanged in the second embodiment (e.g., during the procedure of Figure 8).

[0370] The ERCM change request 1840 may include a Category field 1841 and an ERCM Action field 1842. The Category field 1841 may be set to a value of 31, and the ERCM Action field 1842 may be set to a value of 4.

[0371] Optionally, the ERCM change request 1840 may also include an ERCM Scaling Factor field 1843 and / or an ERCM Reset field 1844.

[0372] The ERCM Scaling Factor field 1843 may represent an integer used to calculate an ERCM change date, e.g., a date and time when a MAC address change must be applied. In some embodiments, the value of the ERCM Scaling Factor field 1843 may be an integer that is multiplied by the value CC(n+1) calculated in step 430 of FIG. 17A-17D to obtain an ERCM change date. In other words, if the ERCM Scaling Factor field 1843 is set to a value s, where s is an integer, and the value of CC(n+1) calculated in step 420 of FIG. 17A-17D is equal to k, then the MAC address change is applied at an ERCM change date that corresponds to the product of s and k (s×k). For example, if the ERCM change date is expressed in number of target beacon transmission times (TBTTs), then the MAC address change must be applied in (s×k) TBTTs. If the ERCM change date is expressed in units of time (TUs), then the MAC address change must be applied in (s×k) TUs.

[0373] The ERCM Scaling Factor field 1843 advantageously allows adjusting the date and time of the MAC address change depending on the context. For example, too frequent MAC address changes can lead to packet loss (packets with pre-prepared MAC addresses that are no longer valid). Thanks to the ERCM Scaling Factor field 1843, it is possible to distribute the changes (by setting this field to an integer value strictly greater than 1), thus reducing packet loss. Thus, according to some embodiments, a threshold can be predefined, and if the number of packets lost per unit time exceeds this threshold, a Scaling Factor strictly greater than 1 is applied. For example, the ERCM Scaling Factor can be set by default to a predefined value (e.g. 1) for all non-AP stations and APs. When an AP (non-AP station) receives the ERCM change Request frame 1840, it can apply the value of the ERCM Scaling Factor field 1843 to calculate the ERCM change date. A value of the ERCM Scaling Factor field 1843 equal to a predefined value (e.g., "FF") may indicate that no change is requested to the current value of the scaling factor, e.g., the ERCM scaling factor is to remain the same. If no change is requested by the ERCM Change request Action frame, the ERCM Scaling Factor field is set to a predefined value (e.g., "FF") indicating that the ERCM Scaling Factor should remain the same.

[0374] The ERCM Reset field 1844 may indicate that the change in the MAC address should be directly applied upon receipt of the next beacon frame. For example, the value of the ERCM Reset field 1844 may be set to 1 when an ERCM procedure is performed and directly applied upon receipt of the next beacon frame. In another embodiment, this ERCM Reset field 1844 is not present in the ERCM change Request 1840, and instead another predefined value (such as "0") of the ERCM Scaling Factor field 1843 is used. In other words, in alternative embodiments, the predefined value of the ERCM Scaling Factor field 1843 may indicate that the change in the MAC address should be directly applied upon receipt of the next beacon frame (which replaces the use of an additional dedicated field). In these alternative embodiments, if the value of the ERCM Scaling Factor field 1843 is equal to this predefined value, the value of the ERCM Scaling Factor remains the same for ERCM procedures following receipt of the ERCM change Request 1840.

[0375] Indicating that the MAC address change should be applied immediately upon receipt of the next beacon frame is useful for resynchronization of the AP and non-AP stations. In fact, a non-AP station may miss one or more beacon frames. In such a case, the non-AP station miscounts the number of frames received before applying the MAC address change, and therefore does not apply the change when it should. This can result in multiple data packets being lost because the non-AP and AP stations do not register the same MAC address with the non-AP station. It also allows the MAC address of a non-AP station to be changed immediately upon request of the AP or non-AP station, for example, when it is detected that the AP and non-AP stations are out of sync (e.g., they are not using the same value for the non-AP station's MAC address).

[0376] It should be noted that the ERCM change Request frame 1840 and / or the ERCM change Response frame 1050 can be either a unicast frame or a multicast frame or a broadcast frame to initiate an ERCM procedure for a group of non-AP stations or for all non-AP stations.

[0377] FIG. 19 shows an example of a series of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP according to another second embodiment.

[0378] Figure 19 illustrates a particular embodiment of the method illustrated in Figure 17B in which requests to change the values ​​of the non-AP stations' MAC addresses are not exchanged between the non-AP stations 120 and the AP 110. In other words, Figure 17 illustrates a method for synchronous MAC address generation in which no ERCM Change Request exchange is required to calculate new temporary MAC addresses for the changing STAs.

[0379] First, an ERCM initiation procedure is performed (step 1910, corresponding to steps 400, 410 in FIG. 17A-17D), for example according to the procedure described above with reference to FIG. 8. During this ERCM activation procedure, an ERCM key may be exchanged between the AP 110 and the non-AP station 120. Upon completion of the ERCM activation procedure, the AP 110 and the non-AP station 120 may obtain the next value of the non-AP station's MAC address @mac(n+1) and the ERCM counter value CC(n+1) (step 420 in FIG. 17A-17D). In one or more embodiments, upon transmission / reception of the first beacon frame following the end of the ERCM activation procedure (step 1921), a counter may be initialized in both the AP 110 and the non-AP station 120, as described above. In one or more embodiments, this counter is initialized to a value equal to CC(n+1). Alternatively, this counter may be initialized to a value of CC(n+1) multiplied by a scaling factor.

[0380] For example, this counter may be initialized upon transmission / reception of the first beacon frame following transmission / reception of an ERCM Key delivery Response (step 840 in FIG. 8), or upon transmission / reception of an ERCM Key delivery Confirm (step 850 in FIG. 8) if an ERCM Key delivery Confirm is exchanged.

[0381] Then, each time a new beacon frame is transmitted or received (steps 1922, 1923), the counter is decremented by one unit in both the AP 110 and the non-AP station 120. When the counter reaches a value of zero (step 1923 in FIG. 19), a change in MAC address may be performed, the next value of the MAC address of the non-AP station 120 @mac(n+2) and the next value of the ERCM counter CC(n+2) may be calculated, and a new counter may be initialized in the AP 110 and the non-AP station 120 at the time of the next beacon frame transmission / reception (new step 1921). All transmissions following the transmission of the beacon frame corresponding to the counter value equal to zero (step 1923) will be made with the new MAC address.

[0382] According to an embodiment, the method of FIG. 19 may therefore include: - Calculate the ERCM counter value (CC) (4 bits) using standardized PRF-128 (IEEE Std 802.11-202 section 12.7.1.2) with the same parameters as for calculating the new temporary MAC address (new set of bits): CC(n+1)=PRF-128 / 4(ERCM key, "ERCM", CC(n),128) From the resulting 128 bits, a new set of 4 bits (different from the leftmost 46 bits used for the new temporary MAC address) is selected. The ERCM counter value defines the number of TBTTs before applying a new temporary MAC address. - Synchronous management of ERCM counter values: No exchange of ERCM Change counter value in beacon frame A synchronous decrement of the ERCM Change counter value starting after the first beacon following the ERCM initiation procedure or after the last temporary MAC address validation.

[0383] FIG. 20 shows an example of a series of steps for operating a procedure for changing the MAC address of a non-AP station associated with an AP according to another second embodiment.

[0384] FIG. 20 illustrates another particular embodiment of the method illustrated in FIGS. 17C-17D in which receipt of a change request by a non-AP station 120 and / or an AP 110 may trigger an ERCM procedure.

[0385] A request to change the MAC address of the non-AP station 120 is sent from the non-AP station 120 to the AP 110 (step 2010). The request may be an "ERCM change Request" 1840, as described below with reference to FIG. 18. The request indicates to the AP 110 that the non-AP station 120 would like to change its MAC address. In response to the MAC address change request, the AP 110 may acknowledge receipt of the request (step 2020), for example, by sending an "ERCM change Response" 1050 to the non-AP station 120, as described with reference to FIG. 10.

[0386] Upon receiving the ERCM change Response (in the case of a non-AP station 120) or immediately after sending the ERCM change Response (in the case of an AP 110), both the AP 110 and the non-AP station 120 may obtain the next value of the non-AP station's MAC address @mac(n+1) and the ERCM counter value CC(n+1) (step 420 in Figures 17A to 17D).

[0387] In one or more embodiments, upon transmission / reception of the first beacon frame following the ERCM change response (step 2020), a counter may be initialized in both the AP 110 and the non-AP station 120, as described above. In one or more embodiments, this counter is initialized to a value equal to CC(n+1). Alternatively, this counter may be initialized to a value equal to CC(n+1) multiplied by a scaling factor.

[0388] For example, this counter may be initialized upon transmission / reception of the first beacon frame following transmission / reception of an ERCM Key delivery Response (step 840 in FIG. 8), or upon transmission / reception of an ERCM Key delivery Confirm (step 850 in FIG. 8) if an ERCM Key delivery Confirm is exchanged.

[0389] Then, each time a new beacon frame is transmitted or received (steps 2032, 2033), the counter is decremented by one unit in both the AP 110 and the non-AP station 120. When the counter reaches a value of zero (step 2033 in FIG. 20), a change in MAC address may be performed, the next value of the MAC address of the non-AP station 120 @mac(n+2) and the next value of the ERCM counter CC(n+2) may be calculated, and new counters may be initialized in the AP 110 and the non-AP station 120 at the next transmission / reception of the beacon frame (new step 2031). All transmissions following the transmission of the beacon frame corresponding to the counter value equal to zero (step 2033) are made with the new MAC address.

[0390] In the embodiment depicted in Figure 20, the change procedure is initiated by non-AP station 120. Alternatively, the change procedure may be initiated by AP 110, which may send an ERCM change Request to one or more non-AP stations in the BSS (in which case the arrows for steps 2010 and 2020 in Figure 20 would be reversed), or may send a beacon frame including a field indicating that the MAC address of the non-AP station should be changed to all non-AP stations in the BSS.

[0391] It should be understood that the embodiments of Figure 19 and Figure 20 are not mutually exclusive and both can be implemented in a BSS. Indeed, an automatic change procedure as in Figure 19 is performed by default (every time a change is performed, new values ​​for the MAC address and ERCM counter are calculated and the next change is performed at the time defined by the new ERCM counter value), and a new ERCM procedure is triggered every time a change request is received as in Figure 20.

[0392] The second embodiment can be summarized through the following clauses, which for illustrative purposes are directed to EUI, but which may be applied to any of the privacy parameters already mentioned.

[0393] Clause 1. A method for changing an Extended Unique Identifier (EUI) value of a non-access point (non-AP) station associated with an access point (AP) station, the non-AP station and the AP station sharing a function and a parameter whose value changes over time, the method comprising: determining a value representing a time at which the value of the EUI will be changed by using the shared function with an input set including current values ​​of the shared parameters; At the time represented by the determined value, changing the current value of the EUI of the non-AP station to a new value of the EUI.

[0394] Clause 2. The method of clause 1, further comprising determining a new value for the EUI using the shared function with the input set.

[0395] Clause 3. Determining the value representing a time at which the value of the EUI is to be changed and determining the new value of the EUI applying the shared function to the input set to obtain a number of bits; determining the new value of the EUI from a first set of bits of the plurality of bits; 3. The method of claim 2, further comprising determining the value representing the time at which the value of the EUI is changed from a second set of bits of the plurality of bits.

[0396] Clause 4. The method of clause 3, wherein the first set of bits and the second set of bits have no bits in common.

[0397] Clause 5. The method of any one of the preceding clauses, wherein the shared function is a pseudorandom function (PRF).

[0398] Article 6. Obtain a key to be shared with the other station; 13. The method of any one of the preceding clauses, wherein the input set further includes the shared key.

[0399] Clause 7. Obtaining the key shared with the AP station includes: receiving a request from the AP station to obtain the shared key; upon receiving the request to obtain the shared key, generating the shared key; Transmitting the generated shared key to the AP station; receiving a message indicating that the AP station has received the shared key; 7. The method of claim 6, performed in the non-AP station, wherein the value representing the time at which the EUI value is changed is determined upon receipt of the message indicating that the AP station has received the shared key.

[0400] Clause 8. Obtaining the key shared with the non-AP station includes: sending a request to the non-AP station to obtain the shared key; receiving the shared key from the non-AP station in response to the request to obtain the shared key; 7. The method of claim 6, wherein the value representing the time at which the value of the EUI is changed is determined upon receipt of the shared key.

[0401] Clause 9. The method further includes changing a previous value of the EUI of the non-AP station to the current value of the EUI; A method according to any one of clauses 1 to 6, wherein the value representing the time at which the value of the EUI is changed to the new EUI value is determined when the previous value of the EUI of the non-AP station is changed to the current value of the EUI.

[0402] Clause 10. Receiving a request to change the value of the EUI; 7. The method of any one of clauses 1 to 6, wherein the value representing the time at which the value of the EUI is changed is determined upon receipt of the request to change the value of the EUI.

[0403] Clause 11. Sending a request to the other station to change the value of the EUI; receiving a message indicating that the request to change the value of the EUI was received by the other station; A method according to any one of clauses 1 to 6, wherein the value representing the time at which the value of the EUI is changed is determined upon receipt of the message indicating that the request to change the value of the EUI has been received by the opposing station.

[0404] Clause 12. The method of any one of clauses 10 and 11, wherein the request to change the value of the EUI is sent from the AP station to the non-AP station.

[0405] Clause 13. The method of any one of clauses 10 and 11, wherein the request to change the value of the EUI is sent from the non-AP station to the AP station.

[0406] Clause 14. The method of any one of the preceding clauses, wherein the number of units of time at the end over which the value of the EUI is changed is a function of the determined value.

[0407] Clause 15. The method of clause 14, wherein the unit times are target beacon transmission times (TBTTs).

[0408] Clause 16. The determined value is an integer value k; Following the determination of the value representative of the time at which the value of the EUI is changed, a number of subsequent beacon frames are transmitted by the AP station or received by the non-AP station; The method of claim 15, wherein the time at which the value of the EUI is changed corresponds to the time at which the [k+1]th beacon frame of the plurality of subsequent beacon frames is transmitted by the AP station or received by the non-AP station.

[0409] Clause 17. The determined value is an integer value k; the request to change the value of the EUI includes a field whose value represents an integer scaling factor s; Following the determination of the value representative of the time at which the value of the EUI is changed, a number of subsequent beacon frames are transmitted by the AP station or received by a non-AP station; A method according to any one of clauses 10 or 11 and 15, wherein the time at which the value of the EUI is changed corresponds to the time at which the [m+1]th beacon frame of the plurality of subsequent beacon frames is transmitted by the AP station or received by the non-AP station, where m is equal to k times s.

[0410] Clause 18. The method of any one of the preceding clauses, wherein the EUI of the non-AP station is a MAC address of the non-AP station.

[0411] Clause 19. The method of any one of the preceding clauses, wherein the current value of the shared parameter is the current value of the EUI.

[0412] Clause 20. Receiving a request (referred to as a second request) to change the value of the EUI of the non-AP station, the second request being received between determining a value representing the time at which the value of the EUI will be changed and the time at which the value of the EUI will be changed; upon receiving the second request, determining, using the shared function having a second set of shared inputs, a second value representative of a second time at which the value of the EUI is to be changed; The method of any one of the preceding clauses, further comprising: changing the current value of the EUI of the non-AP station to a new value of the EUI at the second time represented by the determined second value.

[0413] Clause 21. The method of clause 20, further comprising, upon receipt of the second request, determining the new value of the EUI by using the shared function with the second set of shared inputs.

[0414] Clause 22. Receiving a request (referred to as a second request) to change the value of the EUI of the non-AP station, the second request being received between the determination of the value representing the time at which the value of the EUI is to be changed and the time at which the value of the EUI is to be changed, the second request including an indication that the EUI should be changed at a subsequent unit of time; The method of any one of clauses 1 to 19, further comprising: changing the current value of the EUI of the non-AP station to a new value of the EUI is performed upon reception of a beacon frame by the non-AP station or transmission of a beacon frame by the AP station immediately after receiving the second request, and the new value of the EUI is determined by using the shared function with a second set of shared inputs.

[0415] Fig. 21 shows a schematic diagram of a communication device 2100, typically one of the stations of Fig. 1, of a wireless network configured to implement at least one embodiment of the present invention. The communication device 2100 may preferably be a device such as a microcomputer, a workstation or a lightweight handheld device. The communication apparatus 700 may include a communication bus 2113 that may be connected to: - a central processing unit 2101, such as a processor (denoted CPU); a memory 2103 (denoted MEM) for storing the executable code of the method or steps of the method according to an embodiment of the invention and registers adapted to record variables and parameters necessary for the implementation of the method; and at least two communication interfaces 2102 and 2102' connected via transmitting and receiving antennas 2104 and 2104', respectively, to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards.

[0416] Preferably, the communications bus 2113 may provide communication and interoperability between various elements included in or connected to the communications device 2100. The representation of a bus is not limiting, in particular a central processing unit may be operable to communicate instructions to any element of the communications device 2100 directly or by other elements of the communications device 2100.

[0417] The executable code may be stored in a memory, either read-only, hard disk or a removable digital medium such as a disk. According to any variant, the executable code of the program may be received by the communications network via the interface 2102 or 2102', to be stored in the memory 2103 of the communications device 2100 before being executed.

[0418] In one embodiment, device 2100 may be a programmable device that uses software to implement embodiments of the invention. Alternatively, however, embodiments of the invention may be implemented in whole or in part in hardware (e.g., in the form of an Application Specific Integrated Circuit or ASIC).

[0419] The embodiments of the present invention may be implemented 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 be more fully 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, and by instructions executed by the computer of the system or apparatus by reading and executing the computer-executable instructions from the storage medium and / or controlling the one or more circuits for performing one or more functions of the above-described embodiments. The computer may be comprised of one or more processors (e.g., central processing unit (CPU), microprocessor unit (MPU)) or 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 from 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), storage of a distributed computing system, an optical disk (such as a compact disk (CD), a digital versatile disk (DVD)), a flash memory device, a memory card, and the like.

[0420] The words "comprise," "include," "incorporate," "contain," "is," "have," and the like, when interpreting this specification and the related claims, are to be interpreted in a non-exclusive manner, i.e., to allow for the presence of other items or components not expressly defined. Reference to the singular is to be interpreted as a reference to the plural and vice versa.

[0421] Those skilled in the art will readily appreciate that the various parameters disclosed herein can be changed and the various disclosed embodiments can be combined without departing from the scope of the present invention.

[0422] As an example, the above embodiment considers one or more privacy parameters to be modified, which may be predefined and known by the stations, for example as listed in Figures 15A and 15B.

Claims

1. A method for changing a value of at least one privacy parameter of a target station between an AP station managing a basic service set (BSS) and a non-AP station of the BSS, the non-AP station and the AP station having a shared function for generating a new value of the privacy parameter, the method comprising the steps of: Obtaining a key shared with the other station between the non-AP station and the AP station and a parameter having a value that varies over time; calculating a new value of at least one of the privacy parameters by using the shared key and the current values ​​of the shared parameters as inputs to the sharing function; replacing at a target time the value of at least one of the privacy parameters with the calculated new value; The method includes:

2. At least one of the privacy parameters is: one or more Extended Unique Identifiers (EUIs) of the target station; and one or more MAC addresses of the target stations; a sequence number used by the target station to uniquely identify a new MSDU, A-MSDU, or MMPDU being transmitted; a packet number used by the target station to uniquely identify a new frame being transmitted; and an association identifier (AID) of the target station for uniquely identifying the target station within the BSS; a scrambler seed used by the target station to initialize a local scrambler that scrambles transmitted data and / or descrambles received data; a beacon interval defining the time interval between two consecutive target beacon transmission times (TBTTs); a BSS color, which is used as a numeric identifier for the BSS; The method of claim 1.

3. and communicating, at the station, with the other station, a request to change the value of at least one of the privacy parameters at the target time. The method of claim 1.

4. The request to change the value of at least one of the privacy parameters is transmitted from the AP station to the non-AP station. The method according to claim 3.

5. The target station is the AP station. The method of claim 1.

6. The key shared is the Groupwise Temporal Key (GTK) of the BSS or a derivative of the GTK. The method according to claim 5.

7. The request notifies the AP station of a plurality of targeted non-AP stations of the BSS that have been declared as BSS Privacy Enhancement (BPE) clients, the BPE clients being configured to change values ​​of privacy parameters by using the shared function, the request being sent to each targeted BPE client: a value of at least one of the privacy parameters of the AP station; and a value of at least one of the privacy parameters of the targeted BPE client; Notify me to change The method according to claim 3.

8. The request includes a policy field indicating whether the request also notifies each of one or more targeted stations different from the target station to change a value of at least one of the privacy parameters of the target station. The method according to claim 3.

9. A non-AP station of the BSS configured to change a value of a privacy parameter using the shared function declares the non-AP station to the AP station as a BSS Privacy Enhancement (BPE) client, and the policy field includes: a first value indicating that the request is only a request to change a value of at least one of the privacy parameters of the AP station; a second value indicating that the request is targeted to all BPE clients of the BSS and requests each of the targeted BPE clients to change a value of at least one of the privacy parameters of the targeted BPE client; a third value indicating that the request is targeted to a subgroup of the BPE clients of the BSS and requests each of the targeted BPE clients to change a value of at least one of the privacy parameters of the targeted BPE clients; Take one value from The method according to claim 8.

10. If the policy field has the third value, the request further includes a BPE Clients group field that notifies the subgroup of BPE clients.

10. The method of claim 9.

11. When the request is made at the AP station to a BPE client addressed to the request, the request requests a change to a value of at least one of the privacy parameters of the BPE client addressed to the request. Obtaining a second key and a second parameter having a time-varying value shared with the targeted BPE client; Calculating a new value of at least one of the privacy parameters for the targeted BPE client by using the shared second key and the current value of the shared second parameter as inputs to the sharing function; and replacing a value of at least one of the privacy parameters of the targeted BPE client with the calculated new value of at least one of the privacy parameters at a second target time. The method according to claim 8.

12. determining in the non-AP station from the request that the non-AP station belongs to the targeted BPE client; and if so, Obtaining a second key and a second parameter having a time-varying value shared with the AP station; calculating a new value of at least one of the privacy parameters of the non-AP station by using the second shared key and the current value of the second shared parameter as inputs of the sharing function; and replacing a value of the at least one privacy parameter of the non-AP station with the calculated new value of the at least one privacy parameter at a second target time. The method according to claim 8.

13. The second key shared is the targeted BPE client's Pairwise Transient Key (PTK) or a derivative of the PTK.

13. The method according to claim 11 or 12.

14. Calculating a new value for at least one said privacy parameter comprises: obtaining a plurality of bits by applying the shared function to the input; determining a new value of a first privacy parameter for the target station from a first subset of the plurality of bits; determining a new value of a second distinct privacy parameter for the target station from a second subset of the plurality of bits. The method of claim 1.

15. The first subset of bits and the second subset of bits have no common bits. The method of claim 14.

16. The request to change the value of at least one of the privacy parameters is transmitted from the non-AP station to the AP station. The method according to claim 3.

17. The request includes a notification regarding the target time at which a value of at least one of the privacy parameters will be changed. The method according to claim 3.

18. A method performed in the non-AP station, wherein obtaining the key shared with the AP station comprises: receiving a request for obtaining the shared key from the AP station; generating the shared key in response to receiving the request to obtain the shared key; transmitting the generated shared key to the AP station.

20. The method of claim 17.

19. The shared key is pseudorandomly generated 20. The method of claim 18.

20. A method performed in the AP station, wherein obtaining the key shared with the non-AP station comprises: sending a request to the non-AP station to obtain the shared key; receiving the shared key from the non-AP station in response to the request to obtain the shared key.

20. The method of claim 17.

21. The shared function is a pseudorandom function (PRF).

21. The method according to any one of claims 1 to 20.

22. The current value of the parameter being shared is the current value of the target station's Extended Unique Identifier (EUI).

22. The method of any one of claims 1 to 21.

23. The current value of the parameter being shared is the current time value.

22. The method of any one of claims 1 to 21.

24. The non-AP station or the AP station maintains a registry containing a value of at least one of the privacy parameters of the non-AP station; Replacing the value of at least one of the privacy parameters with the calculated new value of at least one of the privacy parameters includes replacing the value of at least one of the privacy parameters of the non-AP stations in the registry with the calculated new value.

17. The method of claim 16.

25. The request to change the value of at least one of the privacy parameters is a beacon frame. The method according to claim 4.

26. The notification related to the time at which the value of at least one of the privacy parameters is changed is a counter included in the beacon frame, the counter indicating a number of target beacon transmission times (TBTTs).

26. The method of claim 25.

27. after the request to change the value of at least one of the privacy parameters, a number of subsequent beacon frames are transmitted by the AP station and received by the non-AP station, each subsequent beacon frame including a respective value of the counter, the value of the counter being decremented by one with each subsequent beacon frame; The time at which the value of at least one of the privacy parameters is changed is the time at which the beacon frame with the counter value of 0 is transmitted from the AP station and received by the non-AP station.

27. The method of claim 26.

28. The request to change the value of at least one of the privacy parameters is transmitted by the non-AP station and received by the AP station.

20. The method of claim 17.

29. The notification regarding the time at which the value of at least one of the privacy parameters will be changed is included in the request to change the value of at least one of the privacy parameters.

20. The method of claim 17.

30. The notification regarding the time at which the value of at least one of the privacy parameters is changed is a number k of target beacon transmission times (TBTTs) at which the value of at least one of the privacy parameters is changed.

30. The method of claim 29.

31. The value of at least one of the privacy parameters is changed when a kth beacon frame is transmitted from the AP station or received by the non-AP station after the communication of the request.

31. The method of claim 30.

32. The notification regarding the time at which the value of at least one of the privacy parameters will be changed is a time value.

30. The method of claim 29.

33. A value of at least one of the privacy parameters is changed when a beacon frame corresponding to a first beacon frame after the time value is reached is transmitted from the AP station or received by the non-AP station.

33. The method of claim 32.

34. A capability for performing a procedure for changing the value of at least one of the privacy parameters is exchanged during association between the non-AP station and the AP station.

20. The method of claim 17.

35. determining, at the non-AP station or at the AP station, a value representing the target time at which a value of at least one of the privacy parameters is to be changed by using the sharing function with inputs including the current value of the parameter to be shared. The method of claim 1.

36. determining a value representative of the target time at which a value of at least one of the privacy parameters will be changed and calculating the new value of the at least one of the privacy parameters; applying the shared function to the input to obtain a number of bits; determining the new value of at least one of the privacy parameters from a first subset of the plurality of bits; determining a value from a second subset of the plurality of bits representative of the target time at which a value of at least one of the privacy parameters is to be changed.

36. The method of claim 35.

37. The first subset of bits and the second subset of bits have no bits in common.

37. The method of claim 36.

38. Determining a value representative of the target time is performed in response to receiving the request.

35. The method of claim 3.

39. 39. A wireless communication device comprising at least one microprocessor configured to carry out the steps of the method according to any one of claims 1 to 38.

40. A non-transitory computer readable medium storing a program which, when loaded and executed by a microprocessor or computer system in a wireless device, causes said wireless device to perform the method of any one of claims 1 to 38.

Images