Method for modifying the value of one or more privacy parameters of a station in a basic service set - Patent Application 20070122997

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. Accordingly, unless expressly stated otherwise 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, not all embodiments are 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, and broadcast. 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 demand 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 faces a growing 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 therefore the owners of such devices). In the following, PII will be 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 the 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 actual standards and existing mechanisms, non-AP stations cannot randomly change privacy parameters such as MAC addresses while associated with an AP station. Furthermore, AP stations cannot randomly change their privacy parameters. Therefore, the security issues described above remain for these stations. Privacy cannot be guaranteed because various actions and behaviors of non-AP stations within the AP station's basic service set (BSS) can still be tracked and verified through the privacy parameters. Similarly, the AP station itself can also be tracked through the privacy parameters, which can harm privacy if, for example, the AP station is a mobile AP station implemented in a personal mobile phone.

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

[0010] In this context, the present invention provides a method for changing the 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 said AP station, and comprising: Obtaining a key and a parameter having a time-varying value that is shared between the non-AP station and the AP station; calculating a new value for 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 the 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 the 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, whereby 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, parameters, or personally identifiable information (PII) that allows for the identification or tracking of the communication station. As an example, the IEEE 802.11bi task group defined a set of privacy (or privacy enhancement, or PE) parameters known as the Client Privacy Enhancements (CPE) and BSS Privacy Enhancements (BPE) features. The EUI (short for Extended Unique Identifier) ​​is one such parameter. It is a unique identifier assigned to a communication station's network interface controller for use as a network address during wireless communication, e.g., according to IEEE 802 network technology. Typically, an EUI consists of 48 bits (EUI-48, also known as a MAC address) or 64 bits (EUI-64).

[0014] "Communicating with another station" refers to communicating with another station regardless of the direction of communication. Thus, as described below, the request communication 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 request communication may be directed to all non-AP stations in 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 in the BSS over time.

[0015] By "shared parameter having a value that varies over time" is meant a parameter whose value is known by both non-AP stations 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, the shared parameter may be the time, date, counter, EUI of the target station (in the context of the invention, the value of the EUI of the target station is changeable and therefore varies over time). By "current value of the shared parameter" is meant the value of the shared parameter at the time the procedure is started, e.g., when a new value of the privacy parameter (e.g., EUI) is calculated.

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

[0017] The substitution of privacy parameter values ​​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 the AP station or any non-AP station that is not yet associated with the AP station without exchanging a new randomized value of the privacy parameter (e.g., in a change request). Thus, user privacy is improved. Because both the AP station and the non-AP station have mirrored parameters, they can calculate the same new value of the privacy parameter and use it from the same moment. 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). Thus, user privacy is improved.

[0019] Optional features of the invention are defined below with reference to methods, but they can be substituted for 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 a new MAC Service Data Unit (MSDU), Aggregated-MSDU (A-MSDU), or MAC Management Protocol Data Unit (MMPDU) being transmitted; A packet number used by the 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 target station's association identifier (AID) 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 descrambles received data; a beacon interval that defines the time interval between two consecutive target beacon transmission times (TBTT); The BSS color used as the numeric identifier for the BSS.

[0021] The more 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 are targeting changes to 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 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 among 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 have declared themselves as BSS Privacy Enhancement (BPE) clients, the BPE clients 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 BPE client in question.

[0026] The AP station changes the privacy parameter value of its own device and the privacy parameter value of each target BPE client. Note that this scenario ensures global privacy within the BSS if it is applied to all non-AP stations in the BSS as well as the AP station, which is the primary 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) along with 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 change the value of the privacy parameter using the shared function declares itself to an 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 a request only for 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 for the targeted BPE client.

[0029] According to a particular feature, if the policy field takes 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 can 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 includes, at the AP station, if the request requests the targeted BPE client to change the value of at least one privacy parameter of the targeted BPE client: Obtain a second parameter with a second key and a time-varying value that is shared with the targeted BPE client; calculating a new value for at least one privacy parameter for the targeted BPE client by using the shared second key and the current value of the shared second 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 at least one privacy parameter calculated at a second target time (which may be the target time if directly signaled in the request, or a different time determined locally, such as using a shared function 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 the affirmative: obtaining a second key and a second parameter having a time-varying value, which are shared with the AP station; calculating a new value of at least one privacy parameter of the non-AP station by using the shared second key and the current value of the shared second 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 at each BPE client targeted in the request. The AP station and any non-AP stations of the targeted BPE know that, because they have mirrored parameters, they can calculate the same new value of the privacy parameter and use it from the same moment on. This allows them to communicate with each other without interruption.

[0035] In a particular embodiment, the second key shared is the Pairwise Transient Key (PTK) of the intended non-AP station or BPE client, or a derivative thereof. Advantageously, this key is already shared between the intended non-AP station and the AP station when the former associates with the AP station, thus reducing 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 for the target station from a first subset of bits 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 two) of privacy parameters for the target station. For example, four or five CPE parameters, or three or four BPE parameters, can be considered. The resulting chunks of bits can correspond to (and are therefore directly provided for) new randomized values ​​of the privacy parameters.

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

[0039] In certain embodiments, 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 resulting 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, such as a beacon frame transmitted by the AP station. Thus, the target time is explicitly indicated by the requesting 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 at least one privacy parameter will be changed by using a shared function with inputs including the current value of the shared parameter, such that the same determination is made at both stations that need to simultaneously apply the mirrored privacy parameters, allowing one to communicate efficiently with the other.

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

[0044] In certain embodiments, determining a value representing 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 for at least one privacy parameter from a first subset of bits of the plurality of bits; A value representing a target time at which the value of the at least one privacy parameter is to be changed is determined from a second subset of bits of the plurality of bits. As previously described, 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 certain embodiments, determining the value representing the target time occurs 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), receiving a message from another station confirming the request, receiving a transmitted shared key as described below, or receiving a message from another 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 end is a function of the determined value; - The time unit is Target Beacon Transmission Times (TBTTs), - the determined value is an integer value k, 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 plurality 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 when 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 determination of the value representing a target time at which the value of the at least one privacy parameter is to be changed, multiple 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 plurality 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, generate a shared key; The generated shared key is sent 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 have access to 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. Therefore, security is improved.

[0051] Note that the transmission of the shared key from the non-AP station to the AP station is performed after their association and is therefore performed in an encrypted manner, 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 (e.g., EUIs) are pseudo-generated and cannot be inferred by third parties, improving security and privacy. Also, pseudorandom functions already exist according to standards. Therefore, no new functions are required to implement the method for changing the privacy parameters of the target stations.

[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 EUI" refers to the value of the EUI when the new value is calculated, e.g., the value of the EUI before the change. 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, 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 a change request is sent / received or when a change must be applied, etc.).

[0057] In one or more embodiments, the non-AP station or the AP station can 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 can 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, when the change is applied, the AP station's registry and the non-AP station's registry can 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. 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., EUIs) 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 associated with the AP and that support the privacy parameter change procedure.

[0061] Furthermore, the notification 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 (TBTT).

[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; Then, 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-directed decision to change its own privacy parameter.

[0064] In one or more embodiments, 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 of the target time at which the value of the at least one privacy parameter is to be changed may be the 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 the non-AP station since the communication of the request.

[0066] Alternatively, the notification regarding the target time at which the value of at least one privacy parameter will 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 the 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, such 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, wherein 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 part of the methods according to the present 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] Because 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 explanation 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 like 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 present 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 present invention. [Figure 4] 1 is an example flowchart illustrating a method for changing the MAC address of a non-AP station associated with an AP, according to 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] 1 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] 1 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 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 series 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. 10 illustrates an example 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 exemplary information elements for signaling a BPE AP initiated ERCM procedure (and therefore a BSS RCM procedure) according to an embodiment of the present invention. [Figure 14] 1 illustrates an exemplary protected action frame for operating a BSS RCM procedure, according to an embodiment of the present invention. [Figure 15A]1 shows a CPE list and a BPE list that list the privacy parameters of non-AP stations and the 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 the privacy parameters of non-AP stations and the 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] 1 is an example flowchart illustrating a method for changing the 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] 1 is an example flowchart illustrating a method for changing the 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] 1 is an example flowchart illustrating a method for changing the 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] 1 is an example flowchart illustrating a method for changing the 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]10 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 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 second embodiments of the present invention. [Figure 20] 10 illustrates 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 INVENTION

[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. While changing only the MAC address is a first step to improving privacy, it is often not sufficient, and other elements, called personally identifiable information (PII) or privacy parameters, may also be dynamically changed to render 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, all counters in the sequence number (SN) space used to identify each transmitted frame (MSDU or MMPDU) are randomly reset, as are the seeds for 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 responsible for proposing new technical features (beyond RCM procedures) to enhance privacy in 802.11 networks. The current phase defines a set of privacy requirements that extends the consideration beyond a single MAC address to new privacy parameters for AP stations and / or non-AP stations, called Privacy Enhancements (PE) parameters, regardless of whether the non-AP station is currently associated with an AP station. Furthermore, these multiple PE parameters are preferably changed and randomized simultaneously.

[0075] Therefore, in the following we will refer interchangeably to "privacy parameters" and "PE parameters" (or CPE or BPE parameters as the 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 target stations in a BSS without interrupting service. To this end, the AP and non-AP stations involved in the BSS or Client RCM procedure locally generate the next random value of the considered privacy parameter in parallel using a shared function to obtain the same result, i.e., mirrored values ​​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 AP stations and / or non-AP stations to generate the same next randomized values ​​in 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 all current values ​​of privacy parameters of stations with which it exchanges data in a privacy parameter register and updates the register with new values ​​of the privacy parameters of the relevant target station. The stations also apply privacy parameter changes in a synchronized manner to prevent frames from being sent with old privacy parameter values, e.g., old MAC addresses that are no longer relevant to the target station, or privacy parameter values ​​that have been updated in one station but not in the other. Thus, embodiments of the present invention propose a mechanism to ensure that privacy parameter updates between relevant stations are performed in a synchronized manner, regardless of whether they are initiated by an AP or a non-AP station.

[0079] According to a particular embodiment, the present invention proposes changing 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 uniquely assigned to devices by their manufacturers. In contrast, locally administered addresses are assigned to devices by software or network administrators, replacing physical, burned-in addresses. 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 the address is universally administered (when set to 0) or locally administered (when 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 (when set to 0, it indicates a unicast transmission) or to multiple devices (when set to 1, it indicates 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, the terms "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 exchanging data or frames. Therefore, an embodiment provides for the AP station and the non-AP station to concurrently determine the next MAC address of the non-AP station, respectively, to achieve the same result. This next MAC address is used as the new MAC address identifying the non-AP station. The AP station stores all MAC addresses of non-AP stations associated with it in a register and updates the register with the new MAC address of the non-AP station. Furthermore, the AP station and the non-AP station apply the MAC change in a synchronized manner to prevent frames from being sent with an old MAC address that is no longer the station's current address, or with a MAC address that is updated by one entity but not the other. Therefore, the present invention proposes a mechanism to ensure that MAC address updates are performed in a synchronized manner by the AP station and the non-AP station.

[0083] Thus, in one or more specific embodiments, the present invention provides 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 specific embodiments propose that both the non-AP station and the AP station calculate the same counter, which defines the target time at which the MAC address change must be applied by both stations. This counter, consisting of a value representing the target time at which the MAC address value will be changed, is determined by using a shared function with a set of inputs consisting of the current values ​​of shared parameters. Thus, the MAC address update is performed in a synchronized manner at the AP station and the non-AP station, and information regarding the target random time at which the change must be applied is not exchanged between the non-AP station and the AP station.

[0085] Hereinafter, a procedure for changing a privacy parameter (e.g., the MAC address of a non-AP station already associated with an AP station) will be referred to as an "Enhanced RCM procedure (ERCM procedure)" or a "Seamless Enhanced RCM procedure (SERCM procedure)." Therefore, all occurrences of the abbreviation "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 privacy parameters, in which case the "Client RCM procedure" ("Client" refers to 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 target stations 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 spatial 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 divide the transmission signal into different time slots or resource units, and assign each time slot to a different user terminal, thereby allowing multiple user terminals to share the same frequency channel. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), a modulation technique that divides the overall system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers are sometimes called 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 Wi-Fi networks, the invention can be used in any type of wireless network, such as, for example, mobile phone cellular networks, which implement 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., a 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, and 120c. Of course, the number of non-AP stations 120a, 120b, and 120c may be different from three. The AP station 110 provides wireless connectivity between the non-AP stations 120a, 120b, and 120c and a wider network, such as the Internet. The connection of the non-AP stations 120a, 120b, and 120c to the AP station 110 is performed through a standardized process called association. Once the non-AP stations 120a, 120b, and 120c are associated with the AP station 110, they 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, radio network controller (RNC), evolved Node B (eNB), 5G next-generation base station (gNB), base station controller (BSC), base transceiver station (BTS), base station (BS), transceiver function (TF), wireless router, wireless transceiver, basic service set (BSS), enhanced service set (ESS), radio base station (RBS), or 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 subscriber stations, subscriber units, mobile stations (MS), remote stations, remote terminals, user terminals (UTs), user agents, user devices, user equipment (UEs), user stations (STAs), or other terms. 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. Accordingly, 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 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 connectivity to or from a network (e.g., a wide area network such as the Internet or a cellular network) via, for example, 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 may 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 non-AP STAs 120a, 120b, and 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 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 (or alternative variables may be defined) can be extended to mechanisms for enforcing privacy of other PE parameters or other privacy besides a station's single MAC address.

[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), and the second, called the BSS Privacy Enhancements (BPE) set of features, prevents identification and tracking of the BSS.

[0097] From these, 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 the CPE AP and the non-AP STAs 120a, 120b, and 120c are CPE clients (e.g., the scenarios of Figures 2A-2B, 4-11, 17A-17D, 19, and 20), or the AP STA 110 is the BPE AP and the non-AP STAs 120a, 120b, and 120c are BPE clients (e.g., the scenarios of Figures 3A-3B, 4-11, 12A-14, 17A-17D, 19, and 20). According to other embodiments, the AP STA 110 is both the CPE AP and the BPE AP, and the non-AP STAs 120a, 120b, and 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 a MAC address when exchanging data, another MAC address when exchanging measurements, a MAC address when transmitting, a 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 frame retransmissions. It is therefore used by the CPE client to uniquely identify each new MSDU (MAC Service Data Unit), A-MSDU (Aggregated-MSDU), or MMPDU (MAC Management Protocol Data Unit) that is being 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 for frame encryption and can uniquely identify frames being transmitted for replay detection purposes. The packet number is incremented for each transmitted frame and remains constant when a frame is retransmitted. Therefore, 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 its 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) include 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, as indicated in either the Transmit Address (TA) or Receive Address (RA) field of the IEEE 802.11 frame (corresponding to address 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 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 transmit data and descramble receive data, and to initialize the local scrambler of the BPE AP. This corresponds to a 7-bit parameter.

[0109] Beacon interval corresponds to the difference or time interval between two Target Beacon Transmission Times (TBTTs), which are the times when 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 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 also be considered. For example, another BPE AP parameter, the BSS color introduced by the IEEE 802.11ax task group, may be considered, which is used to identify the BSS. 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 frame. It is a 6-bit parameter.

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

[0112] (Client-led 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 or both a BPE AP or one or more BPE clients.

[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 CPE AP use a shared function, such as a pseudorandom function (PRF) as defined in Section 12.7.1.2 of the IEEE Std 802.11-2020 standard, identified herein by the term PRCM PRF. In other embodiments, the shared function is any block cipher algorithm that allows for encrypting blocks with similar input parameters (a shared key and a shared parameter with a time-varying value). For ease of explanation, the following description focuses primarily on PRCM PRFs. However, similar considerations apply to 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, the string "Client RCM" is set. Of course, any other string can 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, for example a predefined value, the current time, etc.

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

[0119] Within the scope of the Client RCM procedure, this may correspond to any key, called the 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 secret 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) generated in parallel by the CPE AP and the active CPE client during the four-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 can be used since it is already integrated into the station, in particular to generate Pairwise Master Keys (PMK) from Pre-Shared Keys (PSK) and Pairwise Transient Keys (PTK) from Pairwise Master Keys (PMK).

[0120] In alternative embodiments, the IPRCM key may correspond to any key shared between an active CPE client and a CPE AP. For example, this shared key may be stored in the memory of a device (such as an Internet connection box) that constitutes the CPE AP and read by a user on the housing of this device. The user may then manually enter this shared key into the user equipment that includes the active CPE client, for example using a touchscreen. Of course, other solutions are possible for the user equipment that includes 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 that constitutes the CPE AP (e.g., on a notification accompanying the device) or may be received directly on the user equipment that includes the CPE client from another device (e.g., via Short Message Service (SMS) or a 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, communications between these entities must be protected. Of course, other embodiments for obtaining and identifying the IPRCM key are possible, as 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 invokes the PRCM PRF with input parameters set as described above and generates an output corresponding to a sequence of pseudo-random bits from which only the L leftmost bits have been extracted (L is the number of bits required for the CPE privacy parameter being 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 that generates these 46 pseudo-random 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 for at least one privacy parameter by using the shared key and the current value of the shared parameter as inputs to a sharing function.

[0124] The PRCM PRF may be run repeatedly with a different shared parameter B and / or a different text string A to generate a new value for a different CPE privacy parameter. 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 in 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 to the CPE AP a request to change the value of at least one privacy parameter of the CPE client at a target time, in order to trigger the CPE AP to change the same privacy parameter with the same value in a synchronous manner (described below with reference to FIG. 2B).

[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 notification 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 embodiments are provided in several embodiments below, e.g., with reference to Figures 17A-20.

[0128] According to some embodiments, the Client RCM start request is a new protected action frame called a 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 numerals 1040, 1400, and 1840 in Figures 10, 14, and 18, described below.

[0129] Next, in step 230, the active CPE client performs a Client RCM procedure at the target time to update its registers with new randomized values ​​of the CPE parameters. In other words, the active CPE client replaces the value of at least one privacy parameter with the calculated new value of the at least one privacy parameter 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 that wish to change one or more CPE privacy parameters. Thus, the CPE AP has communicated with the active CPE client a request to change 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 with respect to the privacy parameters of the active CPE client. By "same Client RCM procedure" it is meant 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 obtains a key K and a parameter B having a time-varying value that are shared with the active CPE client, and calculates a new value of at least one privacy parameter by using the current values ​​of the shared key and shared parameters as inputs to the shared function.

[0132] This ensures that the active CPE client and the CPE AP have mirrored values ​​of said privacy parameters of the active CPE client (target station).

[0133] Next, in step 270, the CPE AP runs the Client RCM procedure at the target time (explicitly indicated in the request or locally determined) when it updates its registers with the 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 only cover 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 modification of at least one BPE AP parameter, the BPE AP and BPE client also use the shared function described above, such as the PRCM PRF. Within 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, the current value of the BPE AP parameter to be modified, or any BPE AP parameter, or even other shared value, such as the current time. The PCRM key K, referred to as 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 the private key) to identify the BPE AP and to be known by both the BPE AP and the BPE client. It may also 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 keys used to encrypt data transmitted from the AP station over the wireless medium. In another embodiment, the GPRCM may be derived from 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 may be used because it is already implemented and used in stations to generate, among other things, Pairwise Master Keys (PMKs) from Pre-Shared Keys (PSKs) and Pairwise Transient Keys (PTKs) from Pairwise Master Keys (PMKs).

[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 transmitted to the BPE clients via, for example, an encrypted information element in a protected action frame or a beacon frame. Because the GPRCM key is exchanged between the BPE AP and all associated BPE clients, communications between these entities are preferably secure. Of course, other embodiments are possible for deriving and determining the GPRCM key, so 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 initiates the BSS RCM procedure in step 310, it invokes the PRCM PRF with the input parameters set as described above, and generates an output corresponding to a sequence of pseudo-random bits from which only the leftmost L bits are extracted (L is 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 a new MAC address value. The function that generates these 46 pseudo-random 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 for at least one privacy parameter by using the current values ​​of the shared key and the shared parameter as inputs to a sharing function.

[0142] The PRCM PRF may be run repeatedly to generate another new value of the BPE privacy parameter using 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, multiple BPE clients, or all BPE clients in 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 a 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, it may be generated from the same iteration of the shared PRCM PRF function when calculating the new value of the privacy parameter. Details of such embodiments 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. To this end, 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 numerals 1040, 1400, and 1840 in Figures 10, 14, and 18, 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 its 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 AP 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 pseudorandom 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 obtains a key K shared with the BPE AP and a parameter B having a value that varies over time, and calculates a new value for at least one privacy parameter by using the shared key and the current value of the shared parameter as input to the shared function.

[0151] This ensures that the BPE AP and BPE client have mirrored values ​​of the 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 (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 through 11. As noted 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] 4 is an example flowchart 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 illustrates an Enhanced RCM (ERCM) procedure that allows for dynamic change of the MAC address of a non-AP STA when the non-AP STA associates with an AP. As described in more detail below, after association, encrypted information (an ERCM key) is shared between the AP and the non-AP STA. Then, upon request of the AP or the non-AP STA, both the AP and the non-AP STA calculate a new, temporary MAC address for the changing STA using, without sharing, the same pseudo-random generator with the same parameters. Thereafter, upon a request for a non-AP station MAC address change initiated by the AP or the non-AP STA, both the AP and the non-AP STA apply the MAC address change for the changing STA.

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

[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 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 frame format 700 as described with reference to FIG. 7. Note that from the moment the non-AP station and the AP associate, communications between them are 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 non-AP station's new MAC address.

[0158] In one or more embodiments, the ERCM key may be a key obtained during the authentication and association procedure 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, using a touchscreen. 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 from a location other than on the housing of the device including the AP (e.g., on a notification attached to the device) or may be received directly on the user equipment including the non-AP station from another device (e.g., via 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 can therefore also calculate the next MAC address of the non-AP station), thereby ensuring the security of the MAC address change procedure. In these embodiments, steps 400 and 410 may be performed in either order.

[0161] In other embodiments, the ERCM key may be generated at a non-AP station and sent to the AP, as in steps 830, 840, and 850 of Figure 8. Because the ERCM key is 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 non-AP station's MAC address is exchanged between the non-AP station and the AP. As described in more detail below, this 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 transmitted 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 referred to as the "target time"). Examples of such notifications are provided with reference to Figures 9A and 9B. In the following, the time after which the new MAC address should be used is referred to as the "ERCM Date" or "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 address of a non-AP station may be changed periodically, and the time at which the MAC address next changes 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 described above, there is a synchronous change of MAC address. For a request for a MAC address change of a non-AP station initiated by either the AP or a non-AP STA, both the AP and the non-AP STA apply the MAC address change of the changing STA. If initiated by the AP, the ERCM targets all ERCM-capable non-AP stations. The ERCM procedure may use a new ERCM IE included in a beacon frame that includes an ERCM Change counter corresponding to the number of TBTTs until the next temporary MAC address becomes 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 becomes valid, as described in more detail below with reference to FIG. 10.

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

[0169] To calculate the new MAC address of a non-AP station, a procedure similar to that currently used in 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 the pseudorandom function (PRF) specified in section 12.7.1.2 of the IEEE Std 802.11-2020 standard, which 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 generated 128 bits, 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 256-bit encoded secret key, 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, and construct a new MAC address for 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 an arbitrary value known to both the non-AP station and the AP and may change over time. For example, B may be the non-AP station's current MAC address, the actual current time (in this case, the current time may be rounded to the nearest tenth of a second or the nearest second to avoid problems due to imperfect synchronization between the non-AP station's clock and the AP's clock), etc. Examples and embodiments are described in detail 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, Figure 5A illustrates steps performed by a non-AP station to change its MAC address at its own request, and Figure 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 within the same non-AP station. For example, an AP may be configured to indicate to a non-AP station at specific 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 its desire to change its MAC address at other times corresponding to specific events (e.g., when the non-AP station is stationary for a predefined period of time or when it transmits the same type of traffic for a predefined period of time).

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

[0176] 5A and 5B, a non-AP station initially 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 for changing the MAC address of the non-AP station 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 an 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 at the non-AP station and the AP by other means, 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] A new MAC address is then calculated by the non-AP station, and the change is acted upon at the ERCM change date (step 530), as described above with reference to Figure 4. 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 non-AP station's new MAC address. As soon as the ERCM date is reached, this new MAC address becomes 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 initially associates with a non-AP station (step 600). During association (step 600), the non-AP station and the AP exchange messages to advertise each other's capabilities, particularly the ability 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 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, a request to change the MAC address of a 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, a request to change the MAC address of a non-AP station is received at the AP (step 625), e.g., from the non-AP station. 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 that 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 at the non-AP station and the AP by other means, e.g., from a third-party device or according to a list of predefined times (regular or not) when 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 that (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 ability 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 STAs and APs to advertise the ability 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 of "127" corresponding to the extended "Extended Capabilities." The length field 720 indicates the number of octets in 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 allocated to ERCM capability to indicate that a station supports the ERCM procedure. 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 Section 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. TIFF0007745761000001.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 series 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 can be initiated, which is performed after the 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 that 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. 10.

[0200] Upon receiving the ERCM Key delivery Request, the non-AP station 120 may generate a key, e.g., 256 bits, referred to as an ERCM key. This key is intended to be used to generate the next MAC address for the non-AP station 120 at both the non-AP station 120 and the AP 110, as described above with reference to FIG. 4. The ERCM key may be constant, or may vary per SSID, AP, or ESS, for example, 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. Also, 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. 10.

[0203] According to another embodiment of the present invention, the ERCM procedure may be initiated by non-AP station 120. In such an embodiment, non-AP station 120 may generate and send an ERCM key to 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 this 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 the non-AP station 120 or the AP 110, the non-AP station 120 and the 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 changing the MAC address of a non-AP station associated with an AP, according to one or more embodiments of the present invention. The change procedure can be operated as soon as the initiation procedure (e.g., according to FIG. 8) is completed.

[0207] The change procedure basically involves two steps: the calculation of a new MAC address for each non-AP station 120, and the effective change of the MAC address at a date and time, called the ERCM change Date, from which the newly calculated MAC address will be used in data exchanges 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 the current value @mac(n) to the 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 for 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 MAC address change needs to be performed, the next value on the list is selected as the new MAC address. However, such an embodiment may pose a security risk if a third party gains access to the list. It may also be envisioned that the same function is applied 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 MAC addresses in a random or pseudorandom manner makes it impossible for a third party to predict the next address, which poses a security issue. Furthermore, standards already have pseudorandom functions (e.g., as specified in section 12.7.1.2 of the IEEE Std 802.11-2020 standard), and this function may be advantageously reused within the framework of the present invention. Therefore, no additional functionality is required to implement the present invention.

[0212] Upon request of either the AP or the non-AP STA, both the AP and the non-AP STA compute a new, non-shared temporary MAC address for the changing STA 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 generated 128 bits, 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 non-AP station's ERCM key, 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 ensure that the parameter value is actually the same at the AP and non-AP stations. For example, if B represents the current time, its value may be rounded to avoid discrepancies between the values ​​at the non-AP and AP stations due to imperfect (even slight) synchronization of the non-AP and AP station clocks. Alternatively, new values ​​may be calculated simultaneously at the non-AP and AP stations (e.g., steps 913, 950 / 960, 970 in Figures 9A and 9B). This problem does not arise if B is the current MAC address.

[0217] 9A, the change procedure may be initiated by the AP 110 and may target all non-AP stations 120a, 120b in 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 of 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 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 beacon frames, which are management frames containing information related to the network, to the non-AP stations 120a, 120b in the BSS. According to the embodiment shown 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 MAC address change is in progress. For example, each beacon frame transmitted by the AP 110 to all non-AP stations 120a, 120b in 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 at which the change must be acted upon (e.g., 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 the value 0, the change must be acted upon. Therefore, all frame transmissions following a beacon frame with the counter equal to 0 must be performed with the new MAC address.

[0220] 9A, the non-AP stations 120a, 120b receive a beacon frame containing a counter called the 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 MAC addresses at the time corresponding to the (k+1) TBTT. The next beacon frame containing an ERCM Change counter with a value of (k-1) is then transmitted from the AP 110 to the non-AP stations 120a, 120b (step 712). After transmitting the (k+1) beacon frames, the AP 110 transmits a beacon frame with the 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 indicating an upcoming MAC address change (e.g., the one sent in step 911) 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 a 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. Alternatively, 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 change 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 performed in (k+1) TBTTs, while a value set to 0 may indicate that the next MAC address should be applied immediately. Thus, all message transmissions following the transmission of a beacon frame associated with a counter equal to 0 will be 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 by sending an “ERCM change Response” 1050 to the non-AP station 120, for example, as described with reference to FIG. 10 (step 960).

[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 terms of 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 MAC address change is applied. The new MAC address may be effective at the start of the next TBTT. That is, all transmissions following the transmission of the beacon frame corresponding to the ERCM change date (step 970) will be 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 occur 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] 9A and 9B uses beacon frames and expresses time in terms of TBTT, other embodiments are possible. In this embodiment, notification of the time when the change occurs is shared between the non-AP station and the AP, and it is only required that the non-AP station and the AP have a means of counting 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 predetermined times.

[0230] 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] Figure 10 shows example frame formats for activating and operating the MAC address change procedure. All frame formats represented in Figure 10 are identified by a "Category" field, which 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: TIFF0007745761000002.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: TIFF0007745761000003.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 take effect. 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 synchronize their clocks sufficiently (or have access to such clocks) to prevent a change from being made on one device but 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 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) specified in section 9.4.2 of the IEEE Std 802.11-2020 standard.

[0243] An IE dedicated to the ERCM procedure, called the ERCM IE 1100, may be specified. 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 in the IE 1000 excluding the Element ID field 1010 and the Length field 1020. Its 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 its 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 through 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 illustrated method (FIG. 12A), compared to FIG. 3A, includes a decision procedure in steps 1210 and 1220 for selecting an appropriate strategy also for BPE clients that change BPE client parameters, for example.

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

[0252] Each time a BSS RCM procedure is applied, the BPE AP may consider various trigger parameters or events (BSS RCM events) that, while improving privacy, are known to have potentially adverse effects in terms of QoS, e.g., causing a potential service interruption to legacy clients (due to the inability of the BPE AP or client to infer the new value of the parameter being changed) and / or incurring additional computational costs for the BPE client to calculate new values ​​for the OTA MAC address or other BPE parameters.

[0253] A first exemplary trigger parameter is the maximum interval between the initiation 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 according to a randomly generated privacy interval with a boundary value corresponding to the maximum interval between the initiation 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 and ratio of legacy clients, the number of BPE and / or legacy clients in doze or active mode, or 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 will not be triggered (or will be 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., exceeding a certain distance threshold will trigger the BSS RCM procedure).

[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 privacy interval if it considers the negative impact on service to be acceptable, expressed for example by legacy clients and / or BPE clients (whether in doze mode, transmitting UL data or not) being below a predetermined threshold.

[0257] When a BSS RCM procedure is triggered, the BPE AP may select a BSS RCM policy in step 1220 that determines, for example, whether the BSS RCM procedure will modify only its own BPE AP parameters (and therefore of the BSS) or whether it will also modify BPE client parameters of some 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 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 as 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 be based on the example policy above and differ 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 should also 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 to be 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 to be generated.

[0268] Therefore, 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 must be changed).

[0269] If BSS RCM Policy 0 is selected, the PRCM PRF is only invoked to generate the next / new value of the BPE AP parameter (e.g., OTA MAC address @AP_MAC(n+1) of the temporary BPE AP) with the parameters set as above (GPRCM key, OTA MAC address @AP_MAC(n) of the current BPE AP for parameter B). The next temporary BPE AP OTA MAC address @AP_MAC(n+1) corresponds to 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 U / L and I / G bits added.

[0270] If 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 was subject to the BSS RCM procedure (all BPE clients in the BSS in the case of BSS RCM Policy 1, and 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 that 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 the U / L bit set to 1 and the I / G bit set to 0. @CLIENT_MAC(n+1) = PRF-128 / 46(IPRCM key, "BSS RCM", @CLIENT_MAC(n)) with U / L and I / G bits added.

[0272] These policies 1 and 2 cause the BPE AP to obtain a second key (an 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 are shared with the BPE AP, and calculate a new value for at least one BPE client parameter for 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 start 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 exemplary information elements 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 correspond to information elements (IEs) 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 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 should notify 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, and 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 signals that the request is targeted to all 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; A third value signaling 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 to be applied selected by the BPE AP. 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 Figure 11. It is, of course, optional in that the target time at which a BPE parameter change must occur can be calculated locally by a station, as described in the embodiments below with reference to Figures 17a through 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 will take effect. This is expressed in target beacon transmission times (TBTT), and its integer value corresponds to the number of TBTTs until the next randomized value of the changing BPE privacy parameter takes effect. For example, a value set to k may indicate that the change must take effect 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 (Section 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 if not.

[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 a 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 previously described BPE Clients Group field 1360.

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

[0285] The current value of at least one BPE AP parameter (eg, 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 performed by each BPE client in 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 to 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 the 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 that 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 that 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 @Client_MAC(n) of parameter B).

[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] Furthermore, the same applies to its BPE client parameters that are changed if the BPE client is involved in a BSS RCM procedure with BSS RCM Policy 1 or 2. The BPE client replaces in the registry the current value of the BPE client parameter (e.g., OTA MAC address) with the corresponding calculated new parameter value.

[0294] (Randomized value generation procedure) The above-described embodiments focus on calculating 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 can be used to allow for the modification of multiple privacy parameters of a target station. A possible implementation includes multiple simultaneous iterations of the PRCM PRF, each using dedicated K, A, and B parameters to generate a new randomized value for 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 be unacceptable given 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 by 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 will 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 target time. In this regard, a station (whether AP or non-AP) that must compute such values ​​obtains multiple bits by applying a shared function to the input, and uses a first subset of bits of the multiple bits as the new value for a privacy parameter to be changed, and a second subset of bits of the multiple bits as the new value for another privacy parameter to be changed or a value representing the target time.

[0299] Therefore, these embodiments propose a global procedure for performing 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 implementation complexity and cost.

[0300] An exemplary 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 (which is itself a privacy parameter) without exchanging new randomized values ​​over the air.

[0301] First embodiments are described with reference to Figures 15A to 16B, focusing on generating multiple new values ​​for multiple BPE / CPE parameters of the same station. In these first embodiments, a CPE station (Figures 2A and 2B) or a BPE station (Figures 3A and 3B) obtains the multiple bits by applying a shared function to the input, determines a new value for a first privacy parameter of the target station from a first subset of the multiple bits, and determines a new value for a second, different privacy parameter of the target station from a second subset of the multiple bits. Of course, new values ​​for 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 generating 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 ​​for privacy parameters) Returning to the first embodiment, a list of privacy parameters, called a 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 for non-AP stations, and the BPE list may consist of privacy parameters for BPE APs. The PE list may consist of a CPE list and a BPE list. In the following, the PE list may refer to either of these lists.

[0305] The PE list is ordered. To do this, a rank is assigned to each privacy parameter, and the PE list is ordered according to this rank. These ranks are either predetermined or assigned during association between an AP station and a non-AP STA. Therefore, the same order is known by the stations.

[0306] Figure 15A shows a CPE list consisting of five privacy parameters for a non-AP station (CPE client, extendable to BPE client). This ordered list declares first the non-AP station's 46-bit OTA MAC address (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 for 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 pseudorandom 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 predetermined "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, for each privacy parameter in the PE list, the assigned chunk / subset in the PE output. 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 described 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, and PRF-704, which generate 128, 192, 256, 384, 512, or 704 randomized bits, respectively. Therefore, depending on the desired PE output length, an appropriate PRF function is selected.

[0314] As mentioned above, alternatively, the shared function can be any block cipher algorithm that allows 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 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. Therefore, PRF-192 may be selected, which generates 192 pseudo-random bits, with only the leftmost 129 bits (e.g., the most significant 129 bits) matching the privacy parameters of the CPE list.

[0316] FIG. 16A shows a CPE correspondence table indicating 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 divided 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, once the CPE output is generated, new random values ​​for each CPE parameter for a CPE client can be obtained directly by simply extracting from the allocated chunk. Thus, in a single iteration of PRF-192, each CPE client and CPE AP can obtain all of the new values ​​for the CPE parameters.

[0318] 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 to generate a number of pseudo-random bits greater than the length of the BPE AP list. As an example, the BPE AP list of FIG. 15B requires a length equal to 75 bits. Therefore, 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] Figure 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 divided 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 bit 46. The new random value for the Scrambler Seed corresponds to the chunk starting at bit 47 of the BPE output through bit 53. The new random value for the Beacon Interval corresponds to the chunk starting at bit 54 of the BPE output through bit 69. The new random value for the BSS Color corresponds to the chunk starting at bit 70 of the BPE output through bit 75.

[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] Additionally, 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 its 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., relevant bits 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 ​​for the BPE client parameters for that BPE client.

[0324] (Simultaneous generation of randomized values ​​for privacy parameters and target time) Returning to the second embodiment, where a PE (CPE or BPE) output is also used to provide a value representing the 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 flowcharts illustrating a method for changing the 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, both the AP and the non-AP station calculate the next value of the non-AP station's MAC address (step 421). Furthermore, they determine a value that represents a target time at which the non-AP station's MAC address must be changed. In one or more embodiments, the value that represents the time at which the non-AP station's MAC address must be changed may be an integer value used as the initial value of a counter called the "ERCM counter." Hereinafter, for simplicity, this determined value will be 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 time units at which the MAC address must be changed, and the ERCM date may correspond to the time that the determined number of time units 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 time units 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 ensure that both stations use the same MAC address of the non-AP station and avoid frame loss (in the 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 can cause privacy issues. In fact, if the ERCM date is exchanged between the non-AP station and the AP, this ERCM date can be recovered by a third party to detect the MAC address change. Another solution is to perform the address change periodically without exchanging information related to the ERCM date, but this can also 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, referred to as the ERCM counter value mentioned above, in step 422, which represents the time, referred to as the ERCM date, at which the MAC address of the non-AP station must be changed. For example, the ERCM counter value may be an integer value representing the number of Target Beacon Transmission Times (TBTT, 1 TBTT corresponds to 100 milliseconds in the 802.11 standard) or unit times (TU, 1 TU corresponds to 1024 milliseconds in the 802.11 standard) until the change of the MAC address of the non-AP station is applied in both the non-AP station and the AP. Privacy is further improved because no information related to the ERCM procedure is exchanged between the AP and the non-AP station.

[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 for both the non-AP station and the AP station.

[0332] After obtaining the value of the non-AP station's next MAC address and the value of the ERCM counter, both the non-AP station and the AP wait until the ERCM date defined by the ERCM counter value is reached to apply the MAC address change (step 430). In one or more embodiments, the non-AP station and the AP may each 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 elapses. 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 MAC address change 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 (e.g., each TBTT) after the ERCM procedure is triggered (step 420), the AP's counter 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 receiving 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 receiving 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 non-AP station of a request to change the MAC address of the non-AP station (described in more detail with reference to FIG. 20). The ERCM procedure may also be triggered by a change in the MAC address of the non-AP station (step 430). In other words, a new ERCM procedure is initiated as soon as the MAC address of the non-AP station is changed. It should be understood that these examples are not independent and mutually exclusive embodiments of the present invention. In the same embodiment of the present 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 non-AP station are both equal to zero, the MAC address change is applied in the AP and non-AP station (step 430). For example, the respective registers of the non-AP station and 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] Referring now 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 the exchange of requests to change the MAC addresses of non-AP stations. 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 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 each unit time.

[0337] In each station, the counter continues to be decremented every unit time unless the counter reaches the value 0 (step 425, arrow "N") or another predetermined value common to both stations. When the counter reaches the value 0 (step 425, arrow "Y"), 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 referred to as a "change request" or "ERCM change request").

[0339] Steps 400, 410, and 420 are similar to those in Figure 17A. As described above, during the ERCM procedure (step 420), the ERCM counter value may be calculated and determined, for example, by both the AP and non-AP stations by applying the same function to the same set of input parameters. Each station may activate a respective counter whose value is initially set to the ERCM counter value calculated in step 420 and decremented at each unit time. When the counter reaches a value of 0 in each station (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 initiated (step 420).

[0340] As long as the counter has not reached the value 0 (step 425, arrow "N"), a request to change the non-AP station's MAC address 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 for the same non-AP station. For example, the AP may be configured to indicate to the non-AP station at certain times that it needs to change its MAC address (e.g., to ensure that all non-AP stations in a BSS periodically change their 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 period of time or when it transmits the same type of traffic for a predefined period of 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 which are detailed in reference to Figures 18 and 20.

[0341] When 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., upon receipt or transmission of the first beacon frame immediately following 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 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 next value of the ERCM counter in step 430 may be performed upon reception or transmission of the beacon frame immediately following receipt of the change request in step 427, and the counter may be initialized upon reception or transmission of the next beacon frame. It is understood that the important point is that the AP and non-AP stations are configured to initialize and begin decrementing the counter and apply the MAC address change simultaneously.

[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 value of the counter continues to be decremented every unit time.

[0345] In one or more embodiments, the change request may include a field indicating that the MAC address change 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 predetermined 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 a non-AP station and an AP become out of sync. This situation 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. Therefore, the counter of the non-AP station may be decremented by the AP but not by the non-AP station. In this case, a MAC address change performed by the AP but not by the non-AP may result in a mismatch of the non-AP station's MAC address in frames exchanged between the non-AP station and the AP, resulting in the loss of the frames. This loss may be detected by the non-AP station and / or the AP, which may send a notification to the other station that a change must be made immediately. Prompting an immediate change of the non-AP station's MAC address may also be useful, for example, if the AP detects that the next value of the MAC address calculated in step 230 has already been assigned to another non-AP station (even though such a case is extremely rare). Furthermore, a change of the non-AP station's MAC address 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," which 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 because it allows adjusting the frequency of the change according to the context: for example, if the change is 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 those in FIG. 17A. In the embodiment of FIG. 17D, an ERCM procedure is not triggered unless a change request is exchanged between the AP and a non-AP station (step 415, arrow "N"). When a change request is received by the AP and / or non-AP station (step 415, arrow "Y"), an ERCM procedure is performed (step 420), during which the next value of the MAC address of the non-AP station and an ERCM counter value may be obtained. Then, each of the AP and non-AP stations may start a respective counter, which is initially set to the ERCM counter value calculated in step 420 and decremented every unit time. When each station's 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). Thereafter, when a subsequent change request is received by the AP and / or non-AP station, a new ERCM procedure is initiated.

[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 a 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 wishes to change its MAC address. In this case, the change pertains only to that non-AP station. If the procedure for changing a MAC address is initiated by the 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] 17A through 17D may be performed by both the non-AP station and the AP. If the change is initiated by the AP and involves multiple non-AP stations, the steps of FIG. 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 must obtain the same next value of the non-AP station's MAC address. Furthermore, 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 may advantageously be 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. Therefore, the results are the same for the non-AP station and the AP station. In one or more embodiments, this function may 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 and the ERCM counter value of a non-AP station advantageously limits the number of operations performed. The use of a PRF has the advantage of eliminating the need for a new function compared to the standard and generating values ​​in a pseudo-random manner, which adds complexity to tracking. Furthermore, using a pseudo-random function to calculate the ERCM counter value is particularly advantageous when multiple non-AP stations are involved in changing their MAC addresses, distributing the time at which different non-AP stations change their MAC addresses, thereby avoiding bottlenecks on the AP side. Of course, other implementations 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 MAC address and the ERCM counter values.

[0357] In the following, the current value of the MAC address of the non-AP station 120 is represented as @mac(n), the next value of the MAC address of the 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 the non-AP station 120 and the AP 110. At the ERCM date, both the non-AP station 120 and the AP 110 may modify their respective registries by updating the MAC address of the 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, such as resetting the counters for all sequence number spaces used to identify data frames for non-AP station 120, and non-AP station 120 may reset the seed used in the PHY DATA scrambler for 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). Standard pseudorandom functions (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. Therefore, no additional 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 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). 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) can 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 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 calculating @mac(n+1)) may be used to calculate the ERCM counter value CC(n+1). For example, to determine the value of the ERCM counter CC(n+1), the rightmost m bits (e.g., m least significant bits, where m is an integer from 1 to 82, preferably an integer from 3 to 10) may be selected. Therefore, 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 calculated 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 calculated 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 station and non-AP stations.

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

[0367] Note that in FIG. 17C, when a change request is received (step 427, arrow "Y"), a new ERCM procedure is initiated (step 420), during which a new value for the MAC address can be calculated. As mentioned above, this new value for the MAC address may advantageously differ from the value of the MAC address calculated in the previous ERCM procedure (which was interrupted by the reception of the change request). For this reason, the new value for the MAC address can be calculated as a function of a 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 the new ERCM procedure (e.g., the ERCM procedure initiated upon reception of the change request) and @mac1(n+1) denotes the value of the MAC address determined during the previous ERCM procedure (which was interrupted by the reception of the change 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 that conforms to 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., the date and time at which 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 FIGS. 17A-17D to obtain the 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 FIGS. 17A-17D is equal to k, then the MAC address change is applied at the ERCM change date corresponding 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 time units (TUs), then the MAC address change must be applied in (s×k) TUs.

[0373] The ERCM Scaling Factor field 1843 advantageously allows for adjusting the date and time of MAC address changes depending on the context. For example, too frequent MAC address changes can lead to packet loss (packets containing pre-prepared MAC addresses that are no longer valid). The ERCM Scaling Factor field 1843 allows for spreading out 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 lost packets per unit time exceeds this threshold, a Scaling Factor strictly greater than 1 is applied. For example, the ERCM Scaling Factor can be set to a predetermined value (e.g., 1) by default 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 predetermined 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 predetermined value (e.g., "FF") indicating that the ERCM Scaling Factor should remain the same.

[0374] The ERCM Reset field 1844 may indicate that the MAC address change should be directly applied upon reception 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 reception 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 predetermined value (e.g., "0") of the ERCM Scaling Factor field 1843 is used. In other words, in alternative embodiments, the predetermined value of the ERCM Scaling Factor field 1843 may indicate that the MAC address change should be directly applied upon reception of the next beacon frame (this 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 predetermined value, the value of the ERCM Scaling Factor remains the same for ERCM procedures following reception 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 resynchronizing 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, resulting in the non-AP station not applying 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 for the non-AP station. Additionally, the MAC address of a non-AP station can be changed immediately upon request by the AP or non-AP station, such as when the AP and non-AP station detect that they 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 may be either a unicast frame, 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 specific embodiment of the method illustrated in Figure 17B in which a request to change the value of the non-AP station's MAC address is not exchanged between the non-AP station 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 a new temporary MAC address for the changing STA.

[0379] First, an ERCM initiation procedure is performed (step 1910, corresponding to steps 400, 410 in FIGS. 17A-17D), e.g., 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 FIGS. 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 equal to CC(n+1) multiplied by a scaling factor.

[0380] For example, this counter may be initialized at the transmission / reception of the first beacon frame following the transmission / reception of an ERCM Key delivery Response (step 840 in FIG. 8), or at the 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), a 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 MAC address change 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 upon transmission / reception of the next beacon frame (new step 1921). All transmissions following the transmission of the beacon frame corresponding to the counter value equal to zero (step 1923) will be 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 specific 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). This request may be an "ERCM change Request" 1840, as described below with reference to FIG. 18. This request indicates to the AP 110 that the non-AP station 120 wants to change its MAC address. In response to the MAC address change request, the AP 110 may acknowledge receipt of the request by, for example, sending an "ERCM change Response" 1050 to the non-AP station 120, as described with reference to FIG. 10 (step 2020).

[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 at 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 at the transmission / reception of the first beacon frame following the transmission / reception of an ERCM Key delivery Response (step 840 in FIG. 8), or at the 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), a 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 MAC address change 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 beacon frame transmission / reception (new step 2031). All transmissions following the transmission of the beacon frame corresponding to the counter value equal to zero (step 2033) will be 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 Figures 19 and 20 are not mutually exclusive and both may be implemented in a BSS. Indeed, the automatic change procedure as in Figure 19 is performed by default (each 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 each time a change request is received as in Figure 20, a new ERCM procedure is initiated.

[0392] The second embodiment can be summarized through the following clauses, which for illustrative purposes are directed to EUI, but which can 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, wherein the non-AP station and the AP station share 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 change by using the shared function with an input set including the 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 the time at which the value of the EUI will change; and determining the new value of the EUI; applying the shared function to the input set to obtain a plurality 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 changes 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] Clause 6. Obtain a key to share with the other station; 10. 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; generating the shared key upon receiving the request to obtain 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 performed in the AP station, 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. further comprising: changing the previous value of the EUI of the non-AP station to the current value of the EUI; 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 will be changed is determined at the time of 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; 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 to be changed is determined upon receipt of the message indicating that the request to change the value of the EUI has been received by the other 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 representing 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 clause 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 representing 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; The method of any combination of clause 10 or clause 11 and clause 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, using the shared function having a second set of shared inputs, determine a second value representing a second time at which the value of the EUI will change; 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 will be changed and the time at which the value of the EUI will be changed, the second request including an indication that the EUI should be changed at a subsequent unit time; 20. 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] Figure 21 shows a schematic diagram of a communication device 2100 of a wireless network, typically one of the stations of Figure 1, 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 method steps 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, a communications bus 2113 may provide for communication and interoperability between various elements included in or connected to communications device 2100. The representation of a bus is not limiting, and in particular a central processing unit may be operable to communicate instructions to any element of communications device 2100 directly or by other elements of communications device 2100.

[0417] The executable code may be stored in a memory that is either read-only, a 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' so as 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 present invention. However, alternatively, embodiments of the present 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] Embodiments of the present invention may be implemented by a computer in a system or device that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium (which may more fully be referred to as a "non-transitory computer-readable storage medium") to perform one or more functions of the above-described embodiments, and / or includes one or more circuits (e.g., application-specific integrated circuits (ASICs)) for performing one or more functions of the above-described embodiments, and the instructions executed by the computer in the system or device 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 a storage medium. The storage medium may include, for example, one or more of a hard disk, random access memory (RAM), read-only memory (ROM), storage of a distributed computing system, an optical disk (such as a compact disk (CD), 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 associated 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 construed 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-described 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, wherein the non-AP station and the AP station have a shared function for generating a new value of the privacy parameter, the method comprising: 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 with time; calculating a new value of at least one privacy parameter by using current values ​​of the shared key and the shared parameters as inputs to the sharing function when calculating the new value of the at least one privacy parameter; replacing the value of at least one of the privacy parameters with the calculated new value at a target time; A method comprising:

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 to be 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 of 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 of claim 5.

7. The request notifies the AP station of a plurality of targeted non-AP stations of the BSS that have declared themselves as BSS Privacy Enhancement (BPE) clients, the BPE clients being configured to change values ​​of privacy parameters by using the shared function, and the request is sent to each targeted BPE client: a value of at least one of the privacy parameters of the AP station; and the value of at least one of the privacy parameters of the targeted BPE client; Notify me to change The method of 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 the value of at least one of the privacy parameters of the target station. The method of 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 contains: a first value indicating that the request is only a request to change the 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 the value of at least one of the privacy parameters of the targeted BPE client; and 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 the value of at least one of the privacy parameters of the targeted BPE client; and Take one value from The method of 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. In the AP station, when the request requests the BPE client targeted for the request to change the value of at least one of the privacy parameters of the targeted BPE client, 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 at the time of calculating the new value of the at least one privacy parameter as inputs to the sharing function; and replacing a value of the at least one privacy parameter of the targeted BPE client with the calculated new value of the at least one privacy parameter at a second target time. The method of claim 7.

12. determining, at 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, which are shared with the AP station; calculating a new value of the at least one privacy parameter of the non-AP station by using the shared second key and the current value of the shared second parameter at the time of calculating the new value of the at least one privacy parameter as inputs to 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 of claim 7.

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

14. Calculating a new value for at least one said privacy parameter comprises: applying the shared function to the input to obtain a plurality of bits; determining a new value for a first privacy parameter of the target station from a first subset of bits of the plurality of bits; determining a new value for a second distinct privacy parameter for the target station from a second subset of bits 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.

15. 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 of claim 3.

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

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

18. The method of claim 17.

19. The shared key is pseudo-randomly generated 20. The method of claim 18.

20. A method performed in the AP station, wherein obtaining the key to be 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.

18. The method of claim 17.

21. The shared function is a pseudorandom function (PRF). The method of claim 1.

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

23. The current value of the parameter to be shared is the current time value. The method of claim 1.

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.

18. The method of claim 17.

26. The notification relating 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 plurality 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.

18. 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.

18. The method of claim 17.

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

30. The method of claim 29.

31. The value of at least one of the privacy parameters is changed when the 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. The 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.

18. The method of claim 17.

35. and determining, at the non-AP station or 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 values ​​of the parameters to be shared. The method of claim 1.

36. determining a value representing 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 privacy parameter; applying the shared function to the input to obtain a plurality of bits; determining the new value of at least one of the privacy parameters from a first subset of bits of the plurality of bits; determining, from a second subset of bits of the plurality of bits, a value representing the target time at which the 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 common bits.

37. The method of claim 36.

38. 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. Determining a value representing the target time is performed in response to receiving the request.

36. The method of claim 35.

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

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

Images