Method and apparatus for operating in ESS mixing enhanced data privacy APs and non-EDP APs

Abstract

A non-AP station obtains capability information from an access point and associates with the AP using a first identifier (reference MAC address) or a second identifier (random MAC address or device ID

Description

TECHNICAL FIELD The present disclosure relates to wireless communications and more specifically to user and network operating with Enhanced Data Privacy features. BACKGROUND The approaches described in this background section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section. In wireless networks, an Extended Service Set (ESS) is a set of Basic Service Sets (BSSs) interconnected by a distribution system (DS), each BSS being managed by an access point (AP). An ESS advantageously provides a centralized management of the BSSs, enabling services to be provided at the ESS level, and mobility to the stations as they can roam between different BSSs of the ESS without losing connectivity. Mechanisms or services at the ESS level rely on user cached persistent information that allows the BSSs of the ESS to serve any station in the same way. The information specific to each station is stored in the ESS and shared between the BSSs, usually during the lifetime of the ESS or as long as the station regularly returns to the ESS. The information is therefore kept in memory within the ESS (in all BSSs or either BSS which shares the information upon the station reassociating with another BSS) even after a disassociation of the station from the ESS. The mechanisms or services relying on the user cached persistent information stored in the ESS can be provided to users over time thanks to the MAC address of their equipment (a non-AP station or STA). Indeed, as the user changes (roams) from one AP to the other within the ESS or as it disconnects and reconnects later on to the ESS (after a disassociation period), the MAC address of its STA is used as a permanent identifier to identify and recognize the user by the APs, and then to retrieve its user cached information associated with its MAC address, in order to serve the mechanisms or services. Exemplary mechanisms based on user cached persistent information include the Fast BSS Transition (FT) as defined in the IEEE 802.11r-2008 standard (RTM), now included in the IEEE Std 802.11-2020. In the FT, user encryption keys are stored and shared between the BSSs (forming a mobility domain), avoiding to renegotiate them when associating with the next AP. Other exemplary mechanisms include the pre-association client steering (that steers a station to a user cached persistent desired band when it reconnects to the network after being disconnected), the Control Access to Internet content and the Automation system. Today, the evolution of wireless systems has brought privacy concerns at the forefront, driven by user demand and requirements of the General Data Protection Regulation (GDPR).The global wireless industry is faced with the growing need to protect users’ Personally Identifiable Information (PH) from increasingly sophisticated user tracking and user profiling activities, while continuing to improve wireless services and the user experience. Pll corresponds to any data that identifies an individual or from which identity or contact information of an individual can be derived. For instance, in the context of IEEE 802.11 family of standards, Pll may be the use of unique identifiers (such as MAC addresses or SSIDs) that can be directly connected to a single device or small group of devices and therefore owners of such devices. Below, the Pll are referred to as privacy parameters or PE, Privacy Enhancements, parameters. The IEEE 802.11 working group has then proposed a first procedure to limit the risk for a user to be traced, which consists in dynamically modifying the MAC address of the user device. This mechanism, called Randomized and Changing MAC (RCM) procedure, has been originally introduced as a privacy enhancing feature in the 802.11aq Pre-Association Service Discovery Task Group and finally included in the standard IEEE Std 802.11-2020. It comprises periodical change of the MAC address of a non-AP station to a random value while it is not associated with a network or, equivalently, with an AP. Although the introduction of the RCM mechanism strongly enhances the privacy of the user, it has however an impact on the mechanisms based on user cached persistent information. In particular, as the MAC address changes over time, the APs within the ESS (or the mobility domain) can no longer ensure a continuous supplying of the services. To cope with this issue, the 802.11 bh task group has been launched to specify Enhanced Data Privacy (EDP) features allowing any AP of a given Extended Service Set (ESS) to recognize the non-AP STA when it reconnects to that ESS even if the non-AP STA has changed its MAC address in the meantime. Two EDP features have been then specified. The first one, referred to as Device ID, defines a permanent device ID (separate from the MAC address) provided by an AP of the ESS to the non-AP STA during a first association. The Device ID can then be used by the same STA when associating again with the ESS, via any AP of the ESS, to allow the APs to recognize the same STA. The second feature, referred to as IRM (standing for Identifiable Random MAC address), is based on a random MAC address provided by the non-AP STA (that is additional to and then different from the MAC address it is using) to the ESS during an association with an AP of the ESS. The IRM can then be used by the same STA when associating again with the ESS, via any AP of the ESS. In order to go further in terms of privacy, IEEE 802.11 WG has also initiated in parallel the 802.11 bi task group to address other privacy requirements and specify corresponding additional EDP features that a non-AP STA could implement in the next versions of the 802.11 standard. One of the specified EDP features is the ability for a non-AP STA to change randomly its MAC address while it is currently associated with an AP, without any loss of connection. The change of MAC address, either outside the association or during the association with an AP of the BSS, has an impact on the Fast BSS Transition mechanism introduced above. An enhanced (or EDP) Fast BSS Transition (FT) mechanism has been proposed in co-pending application GB2311697.3 filed on July 28, 2023 and entitled “ENHANCED FAST BSS TRANSITION FOR CPE STATIONS IMPLEMENTING CHANGING MAC ADDRESS”. Each one of these specified EDP features (including Device ID, IRM and EDP FT) is effective only if both the non-AP STA and the AP support EDP features and at ESS level, if all the APs of the ESS implement them. However, depending on its deployment and its design, an ESS may include APs from different generations implementing not necessary all the EDP features but only some of them or none. There is thus a risk that, even if the non-AP STA remains in the same ESS, the continuity of mechanisms or services based on its user cached persistent information be broken because an AP may not be able to retrieve the user cached persistent information associated to the non-AP STA. SUMMARY The present invention has been devised to address one or more of the foregoing concerns, to improve the continuity of services even if the non-AP STA associates an AP that does not support or partially support EDP features. For instance, the invention seeks to specify how an EDP non-AP STA has to suspend and resume efficiently its EDP features according to their support by the AP with which it intends to associate or transits (roams). In this context, the invention provides a method of communication in a wireless network comprising a set of Basic Station Sets, BSSs, (hence ESS or mobility domain) that are managed by respective APs, the method comprising at a non-AP station: obtaining capability information from one of the APs, and associating with the AP using an identifier identifying the non-AP station, wherein the identifier is a first identifier or a second identifier depending on the obtained capability information of the AP. Depending on the AP’s capabilities with respect to the EDP features, the non-AP station use different identifiers. For example, one of the EDP features can be used when the AP supports it, allowing the non-AP STA to have continuous services within the ESS despite dynamic changes of the STA’s MAC address. Hence, privacy is reinforced. On the other hand, a reference MAC address, previously set for the STA in the ESS, can be used each time the STA associates with an AP of the ESS that does not support the EDP features. As the reference MAC address is known by the ESS forthat STA, the services can be served continuously, although the privacy is reduced. Next the high level of privacy can be restored, while keeping continuous services, as soon as the STA associates again with an AP of the ESS that supports the EDP features. The use of two identifiers for association with APs, function of the capabilities of the APs, can therefore ensure continuous services in an ESS or mobility domain although some APs thereof may not support EDP features conventionally required for continuous services in case of changing MAC address of the STAs. Optional features are defined below with reference to methods, while they can be transposed into device features. In some embodiments, the capability information includes one or more from: a capability to operate or not Identifiable Random MAC address, IRM, for the set of BSSs. This may be signaled in an IRM Active field in an Extended RSN Capabilities field of a management frame received from the AP, a capability to operate or not Device ID indication for the set of BSSs. This may be signaled in a Device ID Active field in an Extended RSN Capabilities field of a management frame received from the AP, and a capability to operate or not Fast BSS Transition, FT, using a Randomized and Changing MAC, RCM, addresses within the set of BSSs. This may be signaled in a dedicated Enhanced Data Privacy, EDP, FT field in a Mobility Domain element of a management frame received from the AP. All these capabilities are examples of a support by the AP of a mechanism to recognize (i.e., identify) the non-AP station despite a change of MAC address of the non-AP station. In other embodiments, the identifier includes a MAC address of the non-AP station. In some embodiments, the first identifier includes a reference MAC address used by the non-AP station when first associating with the set of BSSs (i.e., with anyone of its APs). In a conventional approach of an ESS or mobility domain, this reference MAC address is spread over all the APs of the ESS or mobility domain. Hence, it can be used for instance by the APs that do not support the EDP features. In that case, the first identifier is used when the capability information represents no support by the AP of a mechanism to recognize (i.e., identify) a non-AP station within the set of BSSs despite a change of MAC address of the non-AP station. In other words, no support of EDP features, such as those defined above. In particular embodiments, the method further comprises locally storing a current MAC address of the non-AP station as reference MAC address, when first associating with the set of BSSs. This allows the station to easily access both identifiers, the reference MAC address and the second identifier. In some embodiments, the second identifier includes one from: an Identifiable Random MAC address, IRM, associated with the non-AP station, as provided by the non-AP station during a previous association with an AP of the set of BSSs (it may be the same AP or another one within the BSSs), a Device ID associated with the non-AP station, as received from an AP of the set of BSSs. Such ID is for example bound to the non-AP station’s current MAC address following the procedure set forth in IEEE 802.11bh, and a current Randomized and Changing MAC, RCM, address of the non-AP station. They correspond to the identifiers used for the EDP mechanisms mentioned above, respectively. In particular embodiments, the second identifier is used when the capability information represents support by the AP of a mechanism to recognize (i.e., identify) a non-AP station despite a change of MAC address of the non-AP station. In other words, actual support of EDP features, such as those defined above. In some embodiments, associating with the AP includes sending an Association or Reassociation Request frame, the MAC header of which includes a TA field set to the first or second identifier depending on the obtained capability information of the AP. This can be used for the conventional association with an AP not supporting EDP features or for IRM-based association or EDP FT or Device ID-based association using FILS authentication. In the particular case where no FILS authentication is used for a Device ID-based association, the second identifier is used in a non-AP STA Identity frame (Device ID KDE in message 2 of the 4 way handshake). In some embodiments, associating with the AP includes initiating a Fast BSS transition from a current AP to the AP. In particular embodiments, the method includes using a legacy Fast BSS transition as defined in the IEEE Std 802.11-2020 in case the first identifier is selected based on the obtained capability information and using an enhanced Fast BSS transition in case the second identifier is selected based on the obtained capability information, wherein the enhanced Fast BSS transition derives a Pairwise Master Key (PMK-R1 corresponding to the second level of the FT key hierarchy) for the non-AP station using a persistent station identifier different from a current MAC address of the non-AP station. The FT is therefore adapted depending on the capabilities of the target AP. In some embodiments, the method further comprises communicating with the AP using user cached persistent information associated with the non-AP station and shared between the BSSs. This may include exchanging encrypted data frames. In that case, the user cached persistent information includes a cryptographic key to generate a Pairwise Transient Key for cryptographic operations (e.g., encryption or decryption) on messages exchanged between the non-AP station and the AP. In some embodiments, the AP retrieves user cached persistent information using the first identifier or the second identifier used by the non-AP station when associating with the AP. For instance, the user cached persistent information may be retrieved locally from the AP or from another AP or a controller of the set of BSSs. Correlatively, the invention also provides a wireless communication station, a network controller and access points comprising at least one microprocessor configured for carrying respective methods as described above. Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present 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. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an exemplary network system in which embodiments of the disclosure may be used; Figure 2 illustrates, using a flowchart, general steps of a communication method ensuring continuous services for the non-AP station roaming between APs, according to embodiments of the present disclosure; Figure 3 illustrates, using a flowchart, steps done by a non-AP STA supporting EDP features specified in 802.11 bh in an ESS in which some APs do not support such EDP features according to embodiments of the disclosure; Figure 4 illustrates a scenario of switching between multiple APs of an ESS or mobility domain. Figures 5a, 5b and 5c illustrate, suing flowcharts, steps done by a non-AP STA supporting EDP features specified in 802.11 bi in an ESS or mobility domain in which some APs do not support such EDP features according to embodiments of the disclosure; Figure 6 illustrates a Mobility Domain element (MDE) used by an EDP AP for advertising a Mobility Domain in accordance with embodiments of the present disclosure; and Figure 7 schematically illustrates a communication device of a wireless network, configured to implement at least one embodiment of the present invention. Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e., wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to a different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The 802.11 family of standards adopted by the Institute of Electrical and Electronics Engineers (IEEE) is an example specification providing a great number of mechanisms for wireless communications between stations. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (AP) or non-AP station (STA). Figure 1 illustrates an example wireless communication network 100 in which embodiments of the disclosure may be implemented. The illustrated wireless communication network 100 includes a distribution system 110 interconnecting a set of basic service sets (BSSs) of an extended service set (ESS) 120. Each BSS is formed by a single access point (AP) together with wireless client devices (STAs), creating a wireless local area network (WLAN). Each STA may receive a signal from several APs within their range. Depending on its configuration, each STA can, manually or automatically, select the network (hence AP) with which to associate. The multiple APs may share a common service set identifier (SSID) as part of the ESS. Each BSS may be identified to users by the SSID, as well as to other devices by a basic service set identifier (BSSID). The BSSID of a BSS may be a medium access control (MAC) address of the AP of the BSS. Each AP periodically broadcasts beacon frames (“beacons”) including the corresponding BSSID to allow any STA within wireless range of the AP to associate or re-associate with the AP in order to establish or maintain a communication link with the AP. The WLANs can be networks implementing at least one of the IEEE 802.11 family of wireless communication protocol standards (such as that defined by the IEEE 802.11-2020 specification or amendments thereof). The distribution system 110 offers a secured channel between BSSs that can be used to exchange cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure channel in the distribution system is assumed to be greater than or equal to the cryptographic strength of the wireless channels used in the ESS. The secured channel may be a wireless or a wired backhaul network. In Figure 1, three WLANs of multiple (n) WLANs in ESS 120 are illustrated. A first WLAN comprises AP 131-1 and STAs 135-1 and 136-1 and covers area 130-1. A second WLAN comprises AP 131-2 and STA 135-2 and covers area 130-2. And a third WLAN comprises AP 131-n and STA 135-n and covers area 130-n. Coverage areas 130-1,130-2 and 130-n are shown for illustration only; they may have different coverages and shapes in a real environment. In operation mode, STAs (135-1, 136-1, 135-2, 135-n) are associated with their corresponding APs 131-1, 131-2, 131-n (referred to current AP) but may roam to associate with another AP (referred to as next or target AP) of another WLAN of the wireless communication network 100. In other words, when a STA, initially associated with a first AP, moves in an area covered by another AP, the STA may switch from the first (current) AP to the other (next) AP. The switching between APs is called “roaming” and sometimes “handover”. The Fast BSS Transitions (FT) has been defined to facilitate such switching between APs belonging to the same “mobility domain”. A mobility domain is a set of basic service sets (BSSs), within a same extended service set (ESS), that support Fast BSS Transitions (FTs) between them. For example, the mobility domain may correspond to the entire ESS 120. Alternatively, a subset of its BSSs may form a mobility domain. The mobility domain may be identified by a Mobility Domain IDentifier (MDID). In the present document, it is assumed that all the APs 131-1, 131-2 and 131-n belong to the same mobility domain within ESS 120. A description of the conventional FT is provided in co-pending application GB2311697.3, in particular with reference to its Figure 2, as well as in the IEEE Std 802.11-2020. STAs (135-1,136-1,135-2,135-n) may experience the Randomized and Changing MAC (RCM) procedure originally introduced in the 802.11aq Pre-Association Service Discovery Task Group and finally included in the IEEE Std 802.11-2020. The procedure introduces periodical change of the MAC address of a non-AP STA to a random value, while the non-AP STA is not associated with a network (or, equivalently, with an access point). STAs (135-1, 136-1, 135-2, 135-n) also experience an enhanced RCM procedure that allow them to have their MAC address be changed while they are currently associated with an AP. The same mechanisms allow the AP to also have its MAC address to be changed periodically. Publication GB2614584 describes an example of enhanced RCM procedure while the STA is associated with the AP. The RCM procedure (enhanced or not) intends to mitigate tracking and traffic analysis. The ROM procedure (enhanced or not) raises challenges in ESSs and mobility domains (as introduced below) because there is a need for the multiple APs to be able to recognize the same STA as its MAC address used for (re)association or Fast BSS transition changes. In particular, for some services, it may be desirable by the user that the non-AP STA is identified by the AP and network services. An AP may provide a device ID to a non-AP STA to allow any AP in the ESS to recognize the non-AP STA when it returns to that ESS even if the non-AP STA changes its MAC Address. The non-AP STA may provide that device ID to any AP in the same ESS upon a new association. Exchanges of the device ID are protected from third parties. The non-AP STA indicates activation of device ID for a particular ESS by setting a so-called Device ID Active field to 1 in the Extended RSN Capabilities field (defined in 9.4.2.241 -RSNExtension Element of the IEEE 802.11bh Draftl .0) in (Re)Association Request frames sent to any AP in the ESS. An AP indicates activation of Device ID by setting the Device ID Active field to 1 in the Extended RSN Capabilities field in Beacon, (Re)Association Response, and Probe Response frames. All APs in a given ESS set this field to the same value. A non-AP STA that is associating with any AP in an ESS with Device ID active for both the non-AP STA and the AP and the non-AP STA has a saved device ID for the ESS sends the most recently received device ID for that ESS in the non-AP STA Identity frame. The non-AP STA Identity frame is the (Re)Association Request frame when using FILS authentication in the Device ID element of this frame, or message 2 of the 4 way handshake when not using Fast Initial Link Setup (FILS) authentication in the Device ID KDE of this message. When the AP with Device ID active receives a non-AP STA Identity frame from the non-AP STA with Device ID active and the received device ID is recognized, the AP perform one of the following actions: - send a zero-length device ID (indicating the current device ID is maintained) and set Identifier Status to “Recognized” in the appropriate AP Identity frame (either (Re)Association Response frame or message 3 of the 4 way handshake), - assign a new device ID to the non-AP STA, send the device ID, and set Identifier Status to “Recognized” in the appropriate AP Identity frame. When the non-AP STA receives the AP Identity frame with Identifier Status equal to “Recognized” it can proceed with the assumption that the shared identity state with the AP or ESS is now bound to the non-AP STA’s current MAC address. In that way, the multiple APs of the BSS can recognize the same non-AP STA although its MAC address evolves overtime. The service can be served continuously to the non-AP STA. The Device ID is an Enhanced Data Privacy (EDP) feature that contributes to efficient functioning of the network (recognition of non-AP STA for continuous services) with high level of privacy (RCM address). Another existing EDP feature is the Identifiable Random MAC address (IRM) operation. When using IRM, a non-AP STA provides a random MAC address to the AP either when it associates or when it performs Pre-Association Security Negotiation (PASN) authentication. The non-AP STA may then use that IRM MAC address as its TA when it returns to that ESS or AP such that the non-AP STA may be identified pre-association. An IRM MAC address is a 48-bit address that is constructed from the locally administered address space. The non-AP STA indicates activation of IRM for a particular ESS by setting the IRM Active field to 1 in the Extended RSN Capabilities field (see 9.4.2.241 - RSNExtension Element) in (Re)Association Request frames sent to any AP in the ESS. The AP indicates activation of IRM by setting the IRM Active field to 1 in the Extended RSN Capabilities field in Beacon, (Re)Association Response, and Probe Response frames. All APs in each ESS set this field to the same value. Each time the non-AP STA associates with an AP / ESS, it provides a new IRM MAC address to the AP / ESS during the RSN association. The non-AP STA may allocate a new IRM MAC address to the AP by including an IRM KDE in message 4 of the 4-way handshake or, when using FILS authentication, including the IRM element in the Association Response frame. The non-AP STA stores the newly allocated IRM MAC address as an identifier for use with that AP / ESS and the AP / ESS stores that IRM MAC address as an identifier for that non-AP STA. The non-AP STA may then use that IRM MAC address as its TA the next time it requests association to that same AP / ESS. The non-AP STA may also use that IRM MAC address as its TA for any probes, directed or broadcast, public action frame, authentication and (re)association frame, that it may transmit when it intends to be identified. Device ID and IRM may be used together. Another EDP feature is the Enhanced Fast BSS Transition or “EDP FT” which supports mobility within a mobility domain for non-AP STAs that have their MAC address changing over time. An exemplary EDP FT is provided in co-pending application GB2311697.3, in particular with reference to its Figure 3. It is proposed to use a persistent identifier for the non-AP STA, at least for the time the station is in communication with APs of the mobility domain. This identifier is used for the generation of the set of keys used for fast BSS transition and for the identification of this set of keys during the next authentications with an AP of the mobility domain. The exemplary EDP FT provides, at the non-AP station, the following steps: associating with a first access point (AP) using a first media access control (MAC) address of the station; generating a first Pairwise Master Key (PMK), associated with the first AP, based on a station identifier; reassociating with a second AP using a second MAC address of the station; generating a second PMK, associated with the second AP, based on the station identifier; and generating a Pairwise Transient Key (PTK) based on the generated second PMK for encrypting messages exchanged between the station and the second AP. The use of a persistent identifier for the station during roaming allows the PMK to be generated once and used without having to regenerate it although the station has changed its MAC address. The session key (PTK) can thus be generated securely and without delay ensuring a fast BSS transition. Of course, other implementations allowing a FT when the MAC address of the station changes can be contemplated within the meaning of the EDP FT feature. Regardless of the particulars of the Device ID feature, the IRM feature and the EDP FT feature, any EDP feature can be used by a non-AP station only if the AP also supports the same EDP feature. There may be cases where the ESS or mobility domain mixes APs supporting such EDP feature while others do not. The continuity of services for a non-AP station roaming from one AP supporting the EDP feature implemented by the station to another AP not supporting it is a challenge because the other AP cannot recognize the station through its RCM address. Figure 2 illustrates, using a flowchart, general steps of a communication method ensuring continuous services for the non-AP station roaming between APs, according to embodiments of the present disclosure. At step 200, the non-AP STA obtains capability information from one of the APs, the one with which it intends to associate. The capability information reports a support of one specific or multiple EDP features by the AP or not. This helps the non-AP STA to adapt its signaling to the AP. As described below, the capability information is often retrieved from Management frames sent by the AP, such as Beacon frames, Probe Response frames or any Action frame. At step 210, the non-AP STA selects a STA identifier based on the obtained capability information. For instance, the non-AP STA may decide to use the Device ID or IRM or EDP FT identifier in case the target AP supports the EDP feature or features. On the other hand, the non-AP STA may use a reference identifier, persistent within the ESS or mobility domain, in case the target AP does not support the EDP feature or features, “persistent” means that the identifier is kept in memory of the ESS or mobility domain during their lifetime or during a certain period of time after the last disassociation of the non-AP STA from the ESS or mobility domain. In embodiments as further disclosed below, the identifier may be a reference MAC address used by the non-AP station when first associating with the ESS or mobility domain. Hence at step 210, the non-AP selects an identifier wherein the identifier is a first identifier or a second identifier depending on the obtained capability information of the AP. Next, at step 220, the non-AP STA associates with the AP using the selected identifier identifying the non-AP station. If the AP supports the EDP feature, the selected identifier (Device ID or IRM or EDP FT identifier) ensures a link is made to the non-AP STA: the AP actually recognizes the station and can serve the service in a continuous manner, based on the user cached persistent information associated with the non-AP station. Similarly, if the AP does not support the EDP feature, the reference MAC address of the like used as identifier also ensures a link is made to the non-AP STA: the AP also recognizes it and can then still serve the service based on the user cached persistent information associated with the non-AP station. The continuity of service is kept despite the different types of the APs (with respect of EDP support or not). Hence, whatever the case, at step 230, the non-AP STA operates the service. As reported previously, the non-AP STA and the AP may generate the same cryptographic keys based on the user cached persistent information associated with the non-AP station, and then use these keys to exchange encrypted messages. Figure 3 illustrates, using a flowchart, steps done by a non-AP STA supporting EDP features specified in 802.11 bh (e.g., Device ID and IRM features) in an ESS in which some APs do not support such EDP features according to embodiments of the disclosure. A non-AP STA supporting EDP features specified in 802.11 bh is referred to as EDP Client, whereas an AP supporting EDP features specified in 802.11bh is referred to as EDP AP. The EDP features allow the EDP AP to recognize an EDP Client when the EDP Client returns to an ESS even if the EDP Client changes its MAC address. An EDP Client may support and activate only the IRM or only the Device ID or both. As specified in the IEEE Std 802.11-2020, a non-AP STA may initiate an association procedure after a passive scanning or an active scanning. In a passive scanning, the non-AP STA listens to each channel as per the channel list and waits for Beacon frames from any AP. In an active scanning, the non-AP STA transmits Probe Request frames to each channel as per the channel list to obtain a Probe Response frame from an AP. This is step 310 at the end of which the EDP Client knows the target AP with which it wishes to associate. The Probe Response and Beacon frames transmitted by the AP contain a SSID field which constitutes an identifier of the ESS that it is checked at step 320 by the EDP Client to determine whether it has already been associated with that ESS or not (via this AP or another AP of the ESS). The non-AP STA thus checks whether it knows the SSID or not. In the affirmative, the next step is step 360. In the negative, the next step is step 330. At steps 330 and 360, the EDP Client checks whether the AP is an EDP AP or not (i.e., non-EDP AP). This corresponds to steps 200 and 210 above. In embodiments, the EDP Client checks a capability of the target AP to operate or not Identifiable Random MAC address, IRM, for the ESS. The EDP AP may signal its IRM activation by setting the IRM Active field to 1 in the Extended RSN Capabilities field of a transmitted management frame, e.g. each Beacon and Probe Response frames it transmits. In other embodiments, the EDP Client checks a capability of the target AP to operate or not Device ID indication for the ESS. The EDP AP may signal its Device ID activation by setting the Device ID Active field to 1 in the Extended RSN Capabilities field of a transmitted management frame, e.g. each (Re)Association Request frame it transmits. The EDP Client may check any of these two capabilities or both or any other additional EDP-related capability. In the present example, if the IRM Active field is set to 1 or / and the Device ID Active field is to 1 in the received Beacon or / and Probe Response frames, the target AP is determined as being an EDP AP. Otherwise, the AP is not an EDP AP, meaning it does not support the EDP features. In case the EDP Client has never associated with the ESS (test 330), if the AP is identified as an EDP AP, the next step is step 340; otherwise (non-EDP AP) it is step 350. At step 340, as it is the first association of the EDP Client with the ESS via an EDP AP of the ESS, the EDP Client may enable (or activate) the EDP features as specified in 802.11bh. It means that the EDP Client now uses the Device ID and / or IRM features for future associations within the ESS. As an example, the EDP Client generates an IRM address for the EDP AP, or the EDP AP provides the EDP Client with a Device ID. Still at this step, the EDP Client associates with the target EDP AP by exchanging appropriate management frames (typically Authentication Request / Response frames, Association Request / Response frames), wherein the TA field of the MAC header of the frames sent by the EDP Client is set to its current MAC address. This MAC address may be used as a persistent reference MAC address for the duration of the ESS. Hence, it is saved by the EDP Client as well as by the ESS (shared between the APs) as a reference identifier for that specific EDP Client. This means that reference identifier is stored in the ESS in association with the user cached persistent information associated with the EDP Client. Step 340 thus consists for the EDP Client to locally store the current MAC address as a reference MAC address, when first associating with the set of BSSs. As shown in the Figure, the reference MAC address is referred to as mac_fto_0. This MAC address is now used to recognize the EDP Client when it will return to the same ESS in addition to the Device ID and the IRM address. Specific to the invention (as explained below), reference MAC address mac_fto_0 will be used when returning to the ESS via an AP not supporting the EDP feature enabled at the non-AP STA (i.e., non-EDP AP), contrary to the Device ID and the IRM address that are used with an EDP AP of the ESS At step 350, as it is the first association of the EDP Client with the ESS via a non-EDP AP of the ESS, the EDP Client cannot be yet recognized by the AP and cannot activate the EDP features as specified in 802.11 bh. Hence, conventional association is performed using the current MAC address of the EDP Client. Furthermore, still at step 350, the current MAC address is also saved as reference MAC address mac_fto_0 for future associations. The operations are different when the EDP Client has already associated with the ESS (output ‘yes’ at step 320 followed by step 360 already described). At step 370, the EDP Client returns to the ESS via an EDP AP. In that case, the EDP Client can operate the EDP features as specified in 802.11 bh and enabled at step 340. The EDP Client can thus use its Device ID and / or IRM address in a conventional way to be recognized by the target EDP AP and to allow the corresponding user cached persistent information to be retrieved. For instance, when the Device ID feature is used with FILS authentication or when the IRM feature is used, an Association or Reassociation Request frame is sent, the MAC header of which includes a TA field set to the Device ID or IRM address respectively. When the Device ID feature is used without FILS authentication, the Device ID is used in Device ID KDE in message 2 of the 4 way handshake (authentication) before conventional association with the current MAC address (possible RCM address) of the EDP Client. Such identifiers (Device ID and / or IRM address or the like) are therefore used when the obtained capability information represents support by the AP of a mechanism to recognize (i.e., identify) a non-AP station despite a change of MAC address of the non-AP station. On the other hand, at step 380, the EDP Client returns to the ESS via a non-EDP AP. The EDP features are not available at the target AP to recognize the EDP Client. Hence, the present disclosure provides that the EDP Client performs the association procedure by using the reference MAC address mac_fto_0 previously stored at step 340 or 350. An Association or Reassociation Request frame is therefore sent, the MAC header of which includes a TA field set to mac_fto_0. Such reference identifier is therefore used when the obtained capability information represents no support by the AP of a mechanism to recognize (i.e., identify) a non-AP station within the set of BSSs despite a change of MAC address of the non-AP station. Figure 4 illustrates this situation. In this Figure, all the APs 1-7 (EDP APs and non-ADP APs) belong to the same ESS. The non-AP STA successively associates with all the shown APs. It first associates with the ESS via AP1 using MAC0 which is stored (see line referenced ‘802.11 bh’) as persistent reference MAC address mac_fto_0 forthe duration of the ESS (step 340 because the first AP is EDP). The non-AP STA then enables its EDP feature or features. The non-AP STA implements the RCM procedure, meaning that its MAC address evolves overtime when it is not associated. The next AP is EDP AP2. The non-AP STA can associate using Device ID or IRM address although its current MAC address is MAC1. Thanks to the EDP feature, the non-AP STA is recognized by the EDP AP. The same applies with the next EDP AP3 when the non-AP STA has MAC2 as current MAC address. When the non-AP STA intends to associate with AP4 which is not EDP, it uses reference MAC address mac_fto_0, despite its current MAC address is MAC3. mac_fto_0 allows the non-EDP AP to recognize the non-AP STA. The same applies with the next non-EDP AP5 when the non-AP STA has MAC4 as current MAC address. Next, the non-AP STA associates again with an EDP AP, AP6, and can use again the last Device ID or IRM address, ensuring appropriate recognition of the non-AP STA by the AP. And so on. Since the non-AP STA is always recognized, regardless of whether it used Device ID or IRM address identifiers (with an EDP AP) or mac_fto_0 (with a non-EDP AP), any service offered by the ESS can be continuously served. Figure 5a, 5b and 5c illustrate, using flowcharts, steps done by a non-AP STA supporting EDP features specified in 802.11 bi (e.g., EDP Fast BSS Transition) in an ESS or mobility domain in which some APs do not support such EDP features according to embodiments of the disclosure. An EDP feature, EDP RCM, allows the non-AP STA (or EDP Client) to change randomly its MAC address (or any other privacy parameter) while it is associated with an AP, without any loss of connection. The EDP RCM feature may be combined with the RCM feature allowing the non-AP STA to change randomly its MAC address (or any other privacy parameter) while not being associated with an AP. Another EDP feature, EDP FT, is provided that makes this change to be also effective when the EDP Client operates a BSS Transition mechanism between two APs belonging to the same ESS as the Fast BSS Transition (FT) mechanism specified in the 802.11 r amendment which allows to reduce strongly the handoff times. The EDP FT can apply when the EDP RCM is active. Figure 5a illustrates an initial association with a mobility domain. When the EDP Client initiates an association procedure with an AP of the mobility domain at step 500, first it checks at step 501 whether the AP is an EDP AP. In embodiments, the EDP Client checks a capability of the target AP to operate or not Fast BSS Transition, FT, using a Randomized and Changing MAC, RCM, addresses within the set of BSSs, i.e., to operate EDP FT. The EDP AP may signal its EDP FT capability by setting to 1 an appropriate EDP FT field in the Mobility Domain element (MDE) of a transmitted management frame, e.g. each Beacon and Probe Response frames it transmits. An exemplary EDP FT field is disclosed with reference to Figure 6 which illustrates a Mobility Domain element (MDE) used by an EDP AP for advertising a Mobility Domain (or Privacy Domain) in accordance with embodiments of the present disclosure. The proposed format of MDE 610 is based on the conventional format as described in section 9.4.2.46 of the IEEE Std 802.11-2020: it contains an Element ID field (set to value ‘54’ corresponding to a MDE), a Length field, a MDID (Mobility Domain Identifier) field and a FT Capability and Policy field 611. The FT Capability and Policy field 611 is 1-octet long. It contains a Fast BSS Transition over DS field 621, a Resource Request Protocol Capability 622 and the six remaining bits. In the IEEE Std 802.11-2020, the six remaining bits are reserved. In the present disclosure, one of these six bits within the FT Capability and Policy field 611 is a 1-bit EDP FT field 623 (or EDP FT Capability field) which indicates whether the EDP AP supports the EDP FT feature or not. Field 623 is set to 1 when the transmitting AP supports the EDP FT feature and is set to 0 when the transmitting AP does not support the EDP FT feature. The five remaining bits 624 are reserved. Given this format, step 501 checks whether the third bit 623 of the FT Capability and Policy field 611 of the MDE 610 is set to 1. If yes, it means that the AP is an EDP AP. If not, it means that the AP is not an EDP AP. If the target AP is an EDP AP, the next step is step 502. Otherwise, the next step is step 503. At step 502, the EDP Client stores its current MAC address as persistent reference MAC address mac_fto_0 as described above for step 340 for example. Next step is step 503 during which the EDP Client performs the FT initial mobility domain association as specified in the IEEE Std 802.11-2020. The association allows the target AP to obtain the current MAC address (from the TA field of the MAC header of the management frames transmitted by the EDP Client) to save it (in case of EDP AP) as reference MAC address forthat EDP Client, still in association with user cached persistent information associated with the EDP Client. Turning now to Figure 5b, the EDP Client may initiate, at step 510, a BSS transition between two APs of the same ESS referred to as current AP and next AP. At step 511, the EDP Client checks whether the next AP is an EDP AP or not. Step 511 is identical to step 501. For example, EDP FT field 623 is checked. If the next AP is an EDP AP, the next step is step 520. Otherwise, the next step is step 530. Steps 520 and 530 check whether the current AP is an EDP AP or not. This step is identical to step 501. This is to determine whether the BSS transition to perform is between two EDP APs in which case an EDP Fast BSS Transition can still be used, between two non-EDP APs in which case a conventional Fast BSS Transition can still be used, or between one EDP AP and one non-EDP AP in which case a change of BSS transition can be operated. If the current AP is identified as a non-EDP AP at step 530, meaning the current and next AP cannot operate EDP FT, the EDP Client continues to operate the legacy FT using the reference MAC address mac_fto_0 (and not any RCM address it may have) at step 532. Although privacy is not enhanced because no change is operated on the MAC address, continuity of services offered by the mobility domain is ensured. On the other hand, if the current AP is identified as an EDP AP at step 530, meaning the EDP Client is going to switch from an EDP AP operating EDP FT to a non-EDP AP, the EDP Client suspends at step 531 a the EDP features, including the EDP RCM and the EDP FT. It then uses the reference MAC address mac_fto_0 stored at step 502 for the association (FT) with the non-EDP AP through the legacy FT as described in the standard IEEE Std 802.11-2020. Indeed as it is the MAC address used during the FT initial mobility domain association, the next AP can recognize and identify the EDP Client via mac_fto_0. As a consequence of step 531a, the EDP client switches from the EDP FT to the legacy FT. By operating in such a way, it maintains a fast roaming (little handoff times) provided by the FT mechanism at the expense of maintaining its privacy as it stops changing its MAC address through stopping the EDP RCM feature. If the current AP is identified as an EDP AP at step 520, meaning the current and next AP operate EDP FT, the EDP Client continues to operate the EDP FT using its RCM MAC address and for instance a persistent station identifier described above with reference to co-pending application GB2311697.3. This is step 521, thus allowing the EDP Client to actually switch to the next AP without loss of connectivity. Privacy is still enhanced due to the operated RCM mechanism, while continuity of services offered by the mobility domain is maintained. On the other hand, if the current AP is identified as a non EDP AP at step 520, meaning the EDP Client is going to switch from a non-EDP AP to an EDP AP operating EDP FT, the EDP Client activates / enables / resumes at step 522 the EDP features, including the EDP RCM and the EDP FT. It means the conventional FT is suspended. Similar to Figure 3, whatever the case, the next AP is able to identify the EDP Client, hence to retrieve the user cached persistent information associated with the EDP Client. The services offered by the mobility domain can be continued. For example, the process continues with communication between the EDP Client and the next AP using the user cached persistent information. This may include exchanging encrypted data frames, wherein the encryption is based on a PTK (session keys) generated from the retrieved user cached persistent information. In that case, the user cached persistent information may include a cryptographic key to generate a Pairwise Transient Key for cryptographic operations (e.g., encryption or decryption) on messages exchanged between the non-AP station and the AP. The mechanism of Figure 5b shows that a legacy Fast BSS transition as defined in the IEEE Std 802.11-2020 can be used (step 531a or 532) in case the reference MAC address mac_fto_0 is selected based on the obtained next AP’s capability information and an enhanced Fast BSS transition can be used (step 521 or 522) in case the persistent station identifier for EDP FT is selected based on the obtained next AP’s capability information. In the example above, the enhanced Fast BSS transition derives a Pairwise Master Key (PMK-R1 corresponding to the second level of the FT key hierarchy) for the non-AP station using the persistent station identifier different from the current MAC address of the non-AP station. Figure 4 illustrates the mechanism of Figures 5a and 5b. The line referenced ‘802.11 bi’ shows the successive operations from the FT Initial Mobility Domain association storing mac_fto_0 to each EDP FT or FT to switch to EDP APs or non-EDP APs respectively. The multiple APs to which the non-AP STA successively connects (or associates through BSS transition) belong to the same mobility domain in the meaning of the 802.11 standard family, as exemplified by IEEE Std 802.11-2020. Figure 5c illustrates a variant to Figure 5b where if the current AP is identified as an EDP AP at step 530, meaning the EDP Client is going to switch from an EDP AP operating EDP FT to a non-EDP AP, the EDP Client does not suspend the EDP RCM feature to maintain a high level of privacy, stops the EDP FT and does not launch (or resume) the conventional FT as the transition cannot be completed with an RCM address (the EDP Client is now not recognized as it changes its randomly its MAC address and does not use the MAC address mac_fto_0 that it is required to operate with the legacy FT). This is step 531 b. The other steps of the Figure remain unchanged. In embodiments, the 802.11bh EDP features (corresponding to the mechanisms of Figure 3) can be combined with the 802.11 bi EDP features (corresponding to the mechanisms of Figures 5 and 6) at the non-AP STA side. An AP may be EDP AP according to 802.11bh or EDP AP according to 802.11 bi or EDP AP according to 802.11bh and 802.11 bi or non-EDP AP. The 802.11bh EDP features and Figure 3 drive the mechanisms when associating with a next AP, without BSS transition, while the 802.11 bi EDP features and Figures 5 and 6 drive the mechanisms when transiting to a next AP, using a Fast BSS transition. Figure 7 schematically illustrates a communication device 700, typically any of the stations of Figure 1, of a wireless network., configured to implement at least one embodiment of the present invention. The communication device 700 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 700 may comprise a communication bus 713 to which may be connected: - a central processing unit 701, such as a processor, denoted CPU; - a memory 703, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and - at least two communication interfaces 702 and 702’ connected to the wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 704 and 704’, respectively. Preferably the communication bus 713 may provide communication and interoperability between the various elements included in the communication device 700 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 700 directly or by means of another element of the communication device 700. The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 702 or 702’, in order to be stored in the memory 703 of the communication device 700 before being executed. In an embodiment, the device 700 may be a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Embodiment(s) of the present invention can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non-transitory computer-readable storage medium”) to perform the functions of one or more of the above-described embodiment(s) and / or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the abovedescribed embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiments) and / or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), etc.), a flash memory device, a memory card, and the like. Expressions such as “comprise”, “include”, “incorporate”, “contain”, “is” and “have” are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the invention. As an example, the embodiments described above consider one or more privacy parameters to be changed.

Claims

1. A method of communication in a wireless network comprising a set of Basic Station Sets, BSSs, that are managed by respective APs, the method comprising at a non-AP station:obtaining capability information from one of the APs, andassociating with the AP using an identifier identifying the non-AP station, wherein the identifier is a first identifier or a second identifier depending on the obtained capability information of the AP.

2. The method of Claim 1, wherein the capability information includes one or more from: a capability to operate or not Identifiable Random MAC address, IRM, for the set of BSSs, a capability to operate or not Device ID indication for the set of BSSs, anda capability to operate or not Fast BSS Transition, FT, using a Randomized and Changing MAC, RCM, addresses within the set of BSSs.

3. The method of Claim 1, wherein the identifier includes a MAC address of the non-AP station.

4. The method of Claim 1, wherein the first identifier includes a reference MAC address used by the non-AP station when first associating with the set of BSSs5. The method of Claim 4, wherein the first identifier is used when the capability information represents no support by the AP of a mechanism to recognize a non-AP station within the set of BSSs despite a change of MAC address of the non-AP station.

6. The method of Claim 4, further comprising locally storing a current MAC address of the non-AP station as reference MAC address, when first associating with the set of BSSs.

7. The method of Claim 1, wherein the second identifier includes one from:an Identifiable Random MAC address, IRM, associated with the non-AP station, as provided by the non-AP station during a previous association with an AP of the set of BSSs,a Device ID associated with the non-AP station, as received from an AP of the set of BSSs, anda current Randomized and Changing MAC, RCM, address of the non-AP station.

8. The method of Claim 7, wherein the second identifier is used when the capability information represents support by the AP of a mechanism to recognize a non-AP station despite a change of MAC address of the non-AP station.

9. The method of Claim 1, wherein associating with the AP includes sending an Association or Reassociation Request frame, the MAC header of which includes a TA field set to the first or second identifier depending on the obtained capability information of the AP.

10. The method of Claim 1, wherein associating with the AP includes initiating a Fast BSS transition from a current AP to the AP.

11. The method of Claim 1, comprising using a legacy Fast BSS transition as defined in the IEEE Std 802.11-2020 in case the first identifier is selected based on the obtained capability information and using an enhanced Fast BSS transition in case the second identifier is selected based on the obtained capability information, wherein the enhanced Fast BSS transition derives a Pairwise Master Key for the non-AP station using a persistent station identifier different from a current MAC address of the non-AP station.

12. The method of Claim 1, further comprising communicating with the AP using user cached persistent information associated with the non-AP station and shared between the BSSs.

13. The method of Claim 12, wherein the user cached persistent information includes a cryptographic key to generate a Pairwise Transient Key for cryptographic operations on messages exchanged between the non-AP station and the AP.

14. The method of Claim 1, further comprising, at the AP, retrieving user cached persistent information using the first identifier or the second identifier used by the non-AP station when associating with the AP.

15. The method of Claim 14, wherein the user cached persistent information is retrieved locally from the AP or from another AP or a controller of the set of BSSs.

16. The method of any one of Claims 1 to 15, wherein the set of BSSs is an Extended Service Set, ESS.

17. A wireless communication station, a network controller and access points comprising at least one microprocessor configured for carrying the method of Claim 1.

18. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method of Claim 1.