Methods, devices, and computer programs for managing a group key

Abstract

A communication network comprising an access point, AP, affiliated with an AP multi-link device AP MLD, and a non-AP station, STA, affiliated with a non-AP MLD. The AP MLD transmits a frame 400 includ

Description

FIELD OF THE DISCLOSURE The present disclosure relates to wireless communications and more specifically to managing group keys among multi-link devices, for example for user privacy during wireless communications. BACKGROUND OF DISCLOSURE The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section. Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multipleaccess 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 - RTM) provides a great number of mechanisms for wireless communications between stations. Today, the evolution of wireless systems has brought privacy concerns at the forefront, driven by user demand and requirements of the General Data Protection Regulation (GDPR). The global wireless industry is faced with the growing need to protect users’ personally identifiable information from increasingly sophisticated user tracking and user profiling activities, while continuing to improve wireless services and the user experience. The Personally Identifiable Information (PH) corresponds to any data that identifies an individual or from which identity or contact information of an individual can be derived. A device’s Media Access Control (MAC) address is an example of PH. A dedicated task group 802.11 bi has been initiated in 2019 to address those privacy concerns. Its objective is to specify Enhanced Data Privacy (EDP) features to be added in the current standard to increase privacy, an AP multi-link device (MLD) supporting such EDP features being referred to as an EDP AP MLD and a non-AP MLD supporting such EDP features being referred to as an EDP non-AP MLD. Some of the EDP features relate to the obfuscation of multiple identified PH, also referred to as EDP parameters or privacy parameters below, contained in the frames exchanged in clear by the stations (STAs) that would allowan eavesdropper to fingerprint a device. Among these EDP parameters, identifiers like the MAC address or the Association Identifier (AID) are of course the most important ones, but other parameters like the Sequence Number (SN) or the Packet Number (PN) present in the non-encrypted part of the data frames are also listed. The obfuscation consists in performing a simultaneous change of the transmitted EDP parameters (which are transmitted in clear in the frames) by the stations, to uncorrelated new values (with the previous ones) without any loss of connection. This change relies on the concept of group EDP epoch that corresponds to a limited period of time during which these uncorrelated values of the EDP parameters remain constant. A Group EDP epoch is a time window in which each EDP non-AP MLD of a group of EDP non-AP MLDs applies a set of EDP parameters that is valid for the duration of that Group EDP epoch. It is for instance initiated by an EDP AP MLD by advertising the EDP epoch parameters to a group of EDP non-AP MLDs. Each EDP non-AP MLD of the group of EDP non-AP MLDs applies the advertised EDP epoch parameters of the Group EDP epoch to determine the same one or more EDP epoch start times. A key challenge is that these EDP epoch start times need to be easily determined by both EDP AP MLD and the group of EDP non-AP MLDs (one, several, or all the non-AP stations associated with the AP station), while not being easily determined by an eavesdropper. For this, the generation of these EDP epoch start times is based on a shared function as a Pseudo-Random Function (PRF) which is executed in parallel by the EDP AP MLD and the group of EDP non-AP MLDs with the use of a shared private encryption key. The shared private encryption key should be common to all the EDP non-AP MLDs of the group. At the current stage of the standard 802.11 bi, the generation and the advertisement of such a shared private encryption key is not specified. While these mechanisms have proven their effectiveness, there is a constant need to improve them to make them more effective, safer and / or more efficient, particularly in terms of the resources used. SUMMARY OF THE DISCLOSURE It is a broad aspect of the present disclosure to provide methods, devices, and computer programs for managing group keys among multi-link devices (MLDs), for example for user privacy during wireless communications. According to some embodiments, a group key referred to as PGTK is generated by an EDP AP MLD and distributed to its associated non-AP MLDs with the other existing group keys, for example in the Key Delivery element included in the (Re)Association Response frame during the association procedure, and updated and distributed during Group Key Handshakes with the other existing group keys. The PGTK may be used to enhance privacy during wireless communication to change Enhances Data Privacy parameters. It is worthwhile to note that the PGTK operates at MLD level contrary to the other group keys operating at link level allowing to have an alignment of the group EDP epochs across the links. According to a first aspect, it is provided a method in a communication network, the method comprising transmitting, by an access point, AP, affiliated with an AP multilink device, MLD, to a non-AP station, STA, affiliated with a non-AP MLD, a frame including a group key, wherein the group key is for use in communications between the AP MLD and a group of non-AP MLDs. Accordingly, the method of the disclosure makes it possible to improve communication, in particular communication privacy, using simple and efficient mechanisms ensuring reliability, in particular by differentiating encryption and privacy aspects for data communication. According to particular embodiments, the group key is a master group key, the master group key being used to derive at least one group derivation key for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Accordingly, the master group key may be used to derive several independent group keys. According to particular embodiments, the at least one group derivation key is for use in communications between APs affiliated with the AP MLD and the non-AP STAs affiliated with the at least one non-AP MLD. Still according to particular embodiments, the method further comprises generating the master group key. Still according to particular embodiments, the at least one group derivation key is derived by an upper Media Access Control, MAC, sublayer of the AP MLD. The upper MAC sublayer may also be referred to as MLD upper MAC sublayer or MLD upper MAC entity. Still according to particular embodiments, the at least one group derivation key is used by the MLD upper MAC sublayer of the AP MLD to determine one or more start times at which at least one privacy parameter is to be modified, the one or more start times being transmitted to an MLD lower MAC entity of the AP MLD. This means that the start times are common to all or to a group of affiliated stations of the AP MLD. The AP MLD may comprise several affiliated APs, the one or more start times being transmitted to each of the affiliated APs of the AP MLD or to the group of affiliated stations. If only a group of affiliated stations of the AP MLD are concerned by the modification of a privacy parameter, the one or more start times may thus be transmitted to only the affiliated stations of the group. Still according to particular embodiments, the at least one group derivation key is transmitted to an MLD lower MAC entity of the AP MLD, the MLD lower MAC entity of the AP MLD determining one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the received group derivation key. The AP MLD may comprise several affiliated APs, the group derivation key being transmitted to each of the APs affiliated with the AP MLD or to a group of affiliated APs of the AP MLD. Each affiliated AP of the AP MLD or of the group of affiliated APs determining the one or more start times. Still according to particular embodiments, the master group key is transmitted to an MLD lower MAC entity of the AP MLD, the at least one group derivation key being derived by the MLD lower MAC entity of the AP M LD. The AP M LD may comprise several affiliated APs, the master group key being transmitted to each of the APs affiliated with the AP M LD or to a group of affiliated APs of the AP M LD, the group derivation key being derived by each of the affiliated APs of the AP MLD or of the group, each of these affiliated APs determining the one or more start times. Still according to particular embodiments, the MLD lower MAC entity of the AP MLD determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the group derivation key. Still according to particular embodiments, the master group key is updated and transmitted upon determining sleep mode exit of the non-AP MLD. Still according to particular embodiments, the method further comprises creating a privacy security association in a robust security network association, RSNA, between the AP MLD and the non-AP MLD, the master group key and / or the at least one group derivation key being stored in the AP MLD, in the privacy security association. Still according to particular embodiments, the privacy security association is created upon determining a successful group key handshake, reassociation response frame of a fast basic service set, BSS, transition protocol, or successful fast initial link setup, FILS, or authentication. Still according to particular embodiments, the master group key is a privacy group temporal key, PGTK, which value is a random number, and the at least one group derivation key is a privacy group derivation key, PGDK, which value is computed from PGTK using a key derivation function, KDF, based on a hash algorithm. Still according to particular embodiments, the at least one group derivation key is used for anonymizing group addressed frames transmitted by the AP MLD when the MLD AP operates BSS Privacy Enhancements anonymization. In one implementation, a same group derivation key is used for both anonymizing group addressed frames and for determining one or more start times at which at least one privacy parameter is to be modified. Still according to particular embodiments, the group key comprises a plurality of private group keys, the group key being used to obtain a private group key among the plurality for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Still according to particular embodiments, the group key is a privacy group temporal key, PGTK, for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Still according to particular embodiments, the method further comprises determining a start time at which at least one privacy parameter is to be modified, the start time being determined as a function of the PGTK. Still according to particular embodiments, the method further comprises anonymizing group addressed frames transmitted by the AP MLD when the MLD AP operates BSS Privacy Enhancements anonymization, the group addressed frames being anonymized using the PGTK. According to a second aspect, it is provided a method in a communication network, the method comprising receiving, by a non-access point, AP, station, STA, affiliated with a non-AP multi-link device, MLD, from an AP affiliated with an AP MLD, a frame including a group key, wherein the group key is for use in communications between the AP MLD and a group of non-AP MLDs. Accordingly, the method of the disclosure makes it possible to improve communication, in particular communication privacy, using simple and efficient mechanisms ensuring reliability, in particular by differentiating encryption and privacy aspects for data communication. According to particular embodiments, the group key is a master group key, the master group key being used to derive at least one group derivation key for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Accordingly, the master group key may be used to derive several independent group keys. Still according to particular embodiments, the method further comprises transmitting the received master group key to an MLD upper Media Access Control, MAC, sublayer of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD upper MAC sublayer of the non-AP MLD and is transmitted, by the non-AP MLD, to an MLD lower MAC entity of the non-AP MLD, meaning that the group derivation key is common to all affiliated stations, or to a group of affiliated stations, of the non-AP MLD. Still according to particular embodiments, an MLD lower MAC entity of the non-AP MLD(s) determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the received derived group key. Still according to particular embodiments, the method further comprises transmitting the received master group key to an MLD upper MAC sublayer of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD upper MAC sublayer of the non-AP MLD, the at least one group derivation key being used by the MLD upper MAC sublayer of the non-AP MLD to determine one or more start times at which at least one privacy parameter is to be modified, the one or more start times being transmitted to an MLD lower MAC entity of the non-AP MLD. This means that the group derivation key is common to all affiliated stations, or to a group of affiliated stations, of the non-AP MLD. Still according to particular embodiments, the method further comprises transmitting the received master group key to an MLD upper MAC sublayer of the non-AP MLD and transmitting, by the non-AP MLD, the master group key to an MLD lower MAC entity of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD lower MAC entity of the non-AP MLD. Still according to particular embodiments, the MLD lower MAC entity of the non-AP MLD determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the derived group key. Still according to particular embodiments, wherein the at least one privacy parameter is an Association Identifier (AID). Still according to particular embodiments, the mastergroup key is updated during a group key handshake. Still according to particular embodiments, the method further comprises creating a privacy security association in a robust security network association, RSNA, between the AP MLD and the non-AP MLD, the master group key and / or the at least one group derivation key being stored in the non-AP MLD, in the privacy security association. Still according to particular embodiments, the privacy security association is created upon determining a successful group key handshake, reassociation response frame of a fast basic service set, BSS, transition protocol, or encrypted reassociation response frame when operating an Enhanced Data Privacy Key Exchange, EDPKE, authentication or an IEEE 802.1X authentication, or successful fast initial link setup, FILS, authentication. Still according to particular embodiments, the at least one group derivation key is used for de-anonymizing group addressed frames received by the non-AP MLD when the AP MLD operates BSS Privacy Enhancements anonymization. Still according to particular embodiments, the group key comprises a plurality of private group keys, the group key being used to obtain a private group key among the plurality for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Still according to particular embodiments, the group key is a privacy group temporal key, PGTK, for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs. Still according to particular embodiments, the method further comprises determining a start time at which at least one privacy parameter is to be modified, the start time being determined as a function of the PGTK. Still according to particular embodiments, the method further comprises deanonymizing group addressed frames received by the non-AP MLD when the AP MLD operates BSS Privacy Enhancements anonymization, the group addressed frames being anonymized using the PGTK. At least parts of the methods according to the disclosure may be computer implemented. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present disclosure can be implemented in software, the present disclosure can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an example of a network system in which some embodiments of the disclosure may be implemented; Figure 2 illustrates an example of steps carried out by both an EDP AP MLD and an EDP non-AP MLD when the EDP non-AP station is added to an EDP Group, according to some embodiments of the disclosure; Figure 3a schematically illustrates an EDPKE authentication, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure; Figure 3b schematically illustrates an IEEE 802.1X authentication, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure; Figure 4 schematically illustrates a group key handshake, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure; Figure 5 illustrates an example of KDE selector to identify a PGTK KDE; Figure 6 illustrates an example of a PGTK KDE structure; Figure 7 illustrates an example of the format of the PGTK sub-element, containing the PGTK, when the EDP non-AP and EDP non-AP MLDs operate a Fast BSS Transition (FT) according to some embodiments of the disclosure Figure 8 illustrates an example of a specific value assigned to the PGTK subelement when the EDP non-AP and EDP non-AP MLDs operate a Fast BSS Transition (FT) according to some embodiments of the disclosure; Figure 9 illustrates an example of the status of the WNM Sleep Mode element; Figure 10 illustrates an example of a specific value assigned to the PGTK subelement; Figure 11 illustrates an example of the format of the PGTK sub-element, containing the PGTK; Figure 12 illustrates an example of the format of the key delivery sub-element, containing a KDE List; Figure 13a schematically illustrates an example of a communication device configured to implement at least some embodiments of the present disclosure; and Figure 13b schematically illustrates a MAC data plane architecture configured to implement at least some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE DISCLOSURE According to some embodiments of the disclosure, an EDP AP MLD generates a group key, for example a privacy group temporal key, PGTK, that is transmitted to a group of associated EDP non-AP MLDs. Accordingly, PGTK is shared between APs affiliated with the AP MLD and between affiliated non-AP STAs of each EDP non-AP MLD of the group of EDP non-AP MLDs. In this way, PGTK or a key derived from PGTK is used by the affiliated APs of the EDP AP MLDs and affiliated non-AP STAs of the group of associated EDP non-AP MLDs to determine the same start time at which one or more privacy parameters, such as an association identifier, AID, are to be modified. The group key may be transmitted by an affiliated AP to an affiliated non-AP STA in a frame. As the PGTK is a group key, like the existing keys denoted GTK (Group Transient Key), IGTK (Integrity Group Transient Key) and BIGTK (Beacon Integrity Group Transient Key), a framework similar to the one used for managing these keys may be used to manage the PGTK meaning, in particular, that the PGTK is generated by the EDP AP MLD and distributed to its associated EDP non-AP MLDs with the other existing group keys in the Key Delivery element included in the (Re)Association Response frame and may be updated and distributed later during a Group Key Handshake with the other existing group keys. If a group key, such as PGTK, is used to obtain, by derivation, extraction or other means, one or more other group keys, this group key may be referred to as a master group key. However, it is worthwhile to note that the PGTK operates at the MLD level (meaning that the same key is used by all the affiliated stations of the MLD) contrary to the other group keys (GTK, IGTK, and BIGTK) operating at link level (meaning that a key having the same function is different between different affiliated stations), allowing to have an alignment of the group EDP epochs across the links. According to some embodiments, the present disclosure specifies the generation and the distribution of the Privacy GTK (PGTK) corresponding to the cryptographic key assigned by an EDP AP MLD that is used to manage the group EDP epoch and distributed to the EDP non-AP MLDs associated with the EDP AP MLD. 802.11 network Figure 1 illustrates an example of a network system in which some embodiments of the disclosure may be implemented. For the sake of illustration, Figure 1 represents an 802.11 network (i.e., a Wi-Fi network, WiFi is a trademark) system 100 comprising four wireless devices: an access point station (AP) 105 and three non-AP stations (STAs) 110a, 110b, and 110c. The AP station and the non-AP stations are AP multi-link device (MLD) and non-AP MLDs, respectively, grouping APs referred to as affiliated APs and grouping non-APs referred to as affiliated non-AP STA (also referred to as affiliated stations), respectively. Of course, the number of non-AP MLDs 110a, 110b, and 110c may be different from three. Likewise, the number of affiliated APs per AP MLD and the number of affiliated non-AP STAs per non-AP MLD may vary. As illustrated with dotted lines, AP MLD 105 provides wireless connections between non-AP MLDs 110a, 110b, 110c and a wider network, such as the Internet (not represented). The association of one of non-AP MLDs 110a, 110b, and 110c with AP MLD 105 may be performed by a standardized process called MLO discovery and ML setup in order to establish communication links (referred to as enabled link) between an AP affiliated with the AP MLD and a non-AP STA affiliated with the non-AP MLD, a corresponding link corresponding to a given channel (e.g. 20 MHz, 40 MHz, and so on) in a given frequency band (e.g. 2.4 GHz, 5 GHz, 6 GHz). Once a non-AP MLD is associated with the AP MLD, the non-AP MLD can send data to the network and receive data from the network through the AP MLD. AP MLD 105 may comprise, be implemented as, or known as a Node B, Radio Network Controller (RNC), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (BSC), Base Transceiver Station (BTS), Base Station (BS), Transceiver Function (TF), Radio Router, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or some other terminology. It can be a standalone product or it may be integrated in a device, for instance in a broadband remote access server (BRAS). Non-AP MLDs 110a, 110b, and / or 110c may comprise, be implemented as, or known as a subscriber’s station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user’s device, a user equipment (UE), a user station (STA), or some other terminology. In some implementations, a non-AP MLD may be or may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or a smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, some of non-AP MLDs 110a, 110b, and 110c may be wireless nodes. Such a wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. AP MLD 105 manages a set of stations that together organize their accesses to the wireless medium for communication purposes. All the stations (AP MLD 105 and non-AP MLDs 110a, 110b, and 110c) form a service set, which may be referred to as basic service set, BSS (although other terminology can be used). It is noted that AP MLD 105 may manage more than one BSS: each BSS is thus uniquely identified by a specific basic service set identifier (BSSID) and managed by a separate virtual AP MLD implemented in physical AP MLD 105. In the context of the disclosure, AP MLD 105 supports Enhanced Data Privacy (EDP) features and is referred to as EDP AP MLD. Similarly non-AP MLDs 110a, 110b and 110c support EDP features and are referred to as EDP non-AP MLDs. Joining an EDP Group Figure 2 illustrates an example of steps carried out by both an EDP AP MLD and an EDP non-AP MLD when an EDP non-AP MLD is added to an EDP Group, according to the draft standard P802.11bi™ / D0.6. Figure 2a illustrates steps carried out in an EDP non-AP MLD and Figure 2b illustrates a corresponding step that is carried out in the EDP AP MLD. An EDP non-AP MLD advertises a Group EDP epoch support in (Re)Association Request frames by setting value 1 to the Group EDP Epoch Supported field of the Extended RSN (Robust Security Network) element. An EDP non-AP MLD may either join the default EDP group advertised by the EDP AP MLD during the association procedure or, after the association procedure, join an existing EDP group corresponding to an EDP epoch sequence advertised by the EDP AP MLD or request the EDP AP MLD to start a new EDP group by transmitting a unicast protected action frame before joining it. With each EDP group is associated an EDP Epoch sequence comprising one or more successive Group EDP epochs for which their start times are determined by using the same EDP epoch parameters. When an EDP non-AP MLD joins an EDP group, step 200, it retrieves the advertised / transmitted EDP epoch parameters of the EDP epoch sequence associated with the said EDP group. According to some embodiments, the EDP epoch parameters of the EDP epoch sequence include a value GT0 indicating the next reference start Time of the EDP epoch sequence, a value RandTR indicating the Time Range of the EDP epoch sequence, and a value GEI indicating the Interval of the EDP epoch Sequence. Next, at step 205, the EDP non-AP MLD determines the current epoch iteration n of the EDP epoch sequence, for example as follows: n = [(TSF-GTO) I GEI\ wherein TSF represents the Timing synchronization function or TSF time. Next, at step 210, the EDP non-AP MLD computes the start time denoted GETn+1 of the (n+1)th Group EDP epoch of the EDP epoch sequence, from a shared function which is executed in parallel by the EDP non-AP MLD and the EDP AP MLD with the use of a shared privacy group temporal key, EDP_Key. According to some embodiments, the shared function is the pseudorandom function (PRF) as specified in section 12.7.1.2 of the standard IEEE Std 802.11-2020. Alternatively, any other PRF or block cipher algorithm allowing to cipher a block, with similar input parameters (shared private encryption key and shared parameter having a value varying overtime) may be used. The description below mostly concentrates on the PRF for ease of explanation. However, similar considerations can be made with respect to any block cipher algorithm. According to some embodiments, at any point of time, for the current EDP epoch of iteration number n in the sequence, the start time GETn+1 of the next EDP epoch of the sequence, is computed according to the formula: GETn+1 = GTn+1 + A / T with MT = PRF-128\64(EDP_Key, ‘EDP’, GTn+1) mod (RandTR) n = [(TSF - GT0) / GE!J GTn+1 =GT0+ (n+1) x GEI where: n is the current iteration of the sequence computed at step 205; PRF-M / L corresponds to generating using PRF-Length a sequence of M random bits from which only the L leftmost bits are extracted; PRF-Length is the pseudorandom function defined in 12.7.1.2 of the standard IEEE Std 802.11-2020; TSF is the current value of the internal TSF counter of the receiving link of the non-AP STA; GTO is the value indicated in the Start Time field of the advertised EDP epoch Sequence parameters element retrieved at step 200; RandTR is the value indicated in the Time Range field of the advertised EDP epoch Sequence parameters element retrieved at step 200; GTn is the start time for the current iteration n of the sequence; GEI is the value indicated in the Interval field of the advertised EDP epoch Sequence parameters element retrieved at step 200; and EDP_Key is the shared private encryption key involved in the procedure used to generate the uncorrelated start time of a group EDP epoch. The start times GETk+1 of the next Group EDP epochs of the EDP epoch sequence (corresponding to the epoch iteration n+1, n+2, etc. of the Group EDP epoch sequence) are also computed from the shared private encryption key EDP_Key as follows: GETk+1 = GTk+1 + AIT with AIT = PRF-128\64(EDP_Key, “EDP”, GTk+1) mod (RandTR) GTk+1 = GTk + GEI In parallel, as illustrated in Figure 2b, the EDP AP MLD determines, at step 250, similar to step 210 in Figure 2a, the start time of the Group EDP epoch corresponding to the iteration k+1 as follows: GETk+1 = GTk+1 + AIT with AIT = PRF-128\64(EDP_Key, “EDP”, GTn+1) mod (RandTR) GTk+1 = GTk + GEI It is noted here that according to some embodiments, step 250 in Figure 2b is not carried out by the EDP AP MLD as it knows directly the current Group Epoch iteration. According to an embodiment, step 210 is performed by an MLD upper MAC sublayer of the EDP non-AP MLD. According to another embodiment, step 210 is performed by an MLD lower MAC entity of the EDP non-AP MLD. In this other embodiment, step 210 is performed by the MLD lower MAC entity of each STA affiliated with the EDP non-AP MLD or of a group of STAs affiliated with the EDP non-AP MLD. Similarly, according to an embodiment, step 250 is performed by the MLD upper MAC sublayer of the EDP AP MLD. According to another embodiment, step 250 is performed by a MLD lower MAC entity at each affiliated AP or at a group affiliated APs of the EDP APMLD. According to an embodiment, the EDP non-AP MLDs belonging to the same EDP group compute the same start times for each Group EDP epoch of the EDP epoch sequence (corresponding to the said EDP group). According to an embodiment, the start times of the Group EDP epochs of an EDP epoch sequence (computed by an EDP AP MLD and EDP non-AP MLDs belonging to the same EDP groups) are used on each enabled link established between the EDP AP MLD and these EDP non-AP MLDs. In an implementation, the start times of the Group EDP epochs are applied by all the affiliated APs or a group of affiliated APs of the EDP AP MLD and all the affiliated non-AP STAs or a group of affiliated non-AP STAs of the EDP non-AP MLDs belonging to the same EDP group, making it possible to have an alignment of the group EDP epochs across the links. According to some embodiments, EDP_Key is the PGTK group key generated and shared by the EDP AP MLD in the encrypted Reassociation Response frame after an EDPKE (Enhanced Data Privacy Key Exchange) authentication, as described in reference to Figure 3a, or after an IEEE 802.X authentication, as described in reference to Figure 3b, or after a result of a successful group key handshake as described in reference to Figure 4, or the Reassociation Response frame of the fast BSS transition protocol, or successful Fast Initial Link Setup (FILS) authentication. In such a case, PGTK is a random value, assigned by the access point (AP) MLD, that is used to manage group EDP epoch, that is the key used to compute the successive start times of the EDP Group Epochs and that is used as the shared secret in the computation formula for ensuring that these start times are easily determined by the AP and its stations while not being easily determinable by an eavesdropper. The start times GETk+1 of the next Group EDP epochs of the EDP epoch sequence (corresponding to the epoch iteration n+1, n+2, etc. of the Group EDP epoch sequence) are computed directly from the shared private encryption key PGTK as follows: GETk+1 = GTk+1 + AIT with AIT = PRF-128\64(PGTK, “EDP”, GTk+1) mod (RandTR) GTk+1 = GTk + GEI According to an embodiment and for each EDP non-AP MLD, the new or updated PGTK received from an AP affiliated with the EDP AP MLD, by the MLD lower MAC entity of one of the affiliated STA of the considered EDP non-AP MLD, is transmitted locally to the MLD upper MAC sublayer of the considered EDP non-AP MLD. Next, according to an embodiment, the new or updated PGTK is transmitted by the MLD upper MAC sublayer of the considered EDP non-AP MLD to a MLD lower MAC entity of each affiliated STA of the EDP non-AP MLD. Each of the MLD lower MAC entities is in charge of computing, from the new or updated PGTK, the start times of the next Group EDP epochs of the EDP epoch sequence. According to another embodiment, the MLD upper MAC sublayer of the considered EDP non-AP MLD computes the start times of the next Group EDP epochs of the EDP epoch sequence from the new or updated PGTK and transmits the computed start times to the MLD lower MAC entity of each affiliated STA of the considered EDP non-AP MLD. According to an embodiment and regarding the EDP AP MLD, the PGTK generated by the MLD upper MAC sublayer of the EDP AP MLD is transmitted to a MLD lower MAC entity of each affiliated AP of the EDP AP MLD. Each of the MLD lower MAC entities is in charge of computing, from the new or updated PGTK, the start times of the next Group EDP epochs of the EDP epoch sequence. According to another embodiment, the MLD upper MAC sublayer of the EDP AP MLD computes the start times of the next Group EDP epochs of the EDP epoch sequence, from the new or updated PGTK, and transmits the computed start times to the MLD lower MAC entity of each affiliated AP of the EDP AP MLD. According to some embodiments, PGTK may be used for other EDP operations, features, and / or purposes than only the management of the group EDP epoch and the computation of the successive start times of the EDP Group Epochs. For instance, PGTK may also be used for anonymizing or deanonymizing (i.e., remove anonymization) group addressed frames transmitted by an EDP AP MLD when an EDP MLD AP operates a BSS Privacy Enhancements anonymization. According to other embodiments, EDP_Key may be inherited or derived from the PGTK group key by using any Key Derivation Function (KDF). Still according to some embodiments, the PGTK group key is generated and shared by the EDP AP MLD in the encrypted Reassociation Response frame after an EDPKE authentication as described in reference to Figure 3a or after an IEEE 802.X authentication as described in reference to Figure 3b, or after a result of a successful group key handshake as described in reference to Figure 4, or the Reassociation Response frame of the fast BSS transition protocol, or successful FILS authentication. In such a case, the EDP_Key may be referred to as PGDK (for Privacy Group Derivation Key). In addition, other group keys operating at the MLD level, that are used for privacy purposes, may also be derived from PGTK. According to an embodiment, the inheritance or derivation of the PGDK from the PGTK is performed locally, at MLD level, by the EDP AP MLD and each EDP non-AP MLD belonging to the considered EDP group. In other words, for each new or updated PGTK (resulting from a successful group key handshake, a Reassociation Response frame of the fast BSS transition protocol, an encrypted Reassociation Response frame when operating an EDPKE authentication or an IEEE 802.1X authentication, or successful FILS authentication) a new PGDK is inherited or derived locally from this new or updated PGTK, by the EDP AP MLD and by each EDP non-AP MLD belonging to said the considered EDP group. According to an embodiment and for each EDP non-AP MLD, the new or updated PGTK received from an AP affiliated with the EDP AP MLD, by a MLD lower MAC entity of one of its affiliated STA, is transmitted locally to the MLD upper MAC sublayer of the considered EDP non-AP MLD. Next, the MLD upper MAC sublayer stores or updates the PGTK and performs a derivation from this PGTK to generate a new or updated PGDK. According to an embodiment, the new or updated PGDK is transmitted, by the MLD upper MAC sublayer of the considered EDP non-AP MLD, to a MLD lower MAC entity of each affiliated STA of the considered EDP non-AP MLD. Each of the MLD lower MAC entities is in charge of computing, from the new or updated PGDK, the start times of the next Group EDP epochs of the EDP epoch sequence. According to another embodiment, the MLD upper MAC sublayer of the considered EDP non-AP MLD computes the start times of the next Group EDP epochs of the EDP epoch sequence, from the new or updated PGDK, and transmits the computed start times to a MLD lower MAC entity of each affiliated STA of the EDP non-AP MLD. Still according to another embodiment, the new or updated PGTK received from an AP affiliated with the EDP AP MLD, by a MLD lower MAC entity of one affiliated STA of the considered EDP non-AP MLD is transmitted locally to a lower MAC entity of each affiliated STA of the considered EDP non-AP MLD. Each of the MLD lower MAC entities is in charge of deriving the PGDK from the received PGTK and computing the start times of the next Group EDP epochs of the EDP epoch sequence from the new or updated PGDK. According to an embodiment and regarding the EDP AP MLD, the MLD upper MAC sublayer generates the new or updated PGTK and performs the derivation from this PGTK to generate a new or updated PGDK. According to an embodiment, the new or updated PGDK is transmitted by the MLD upper MAC sublayer of the EDP AP MLD to a MLD lower MAC entity of each affiliated AP of the EDP AP MLD. Each of the MLD lower MAC entities is in charge of computing, from the new or updated PGDK, the start times of the next Group EDP epochs of the EDP epoch sequence. According to another embodiment, the MLD upper MAC sublayer of the EDP AP MLD computes, from the new or updated PGDK, the start times of the next Group EDP epochs of the EDP epoch sequence and transmits the computed start times to a MLD lower MAC entity of each affiliated AP of the EDP AP MLD. According to another embodiment, the MLD upper MAC sublayer generates the new or updated PGTK and transmits the new or updated PGTK to a MLD lower MAC entity of each affiliated AP of the EDP AP MLD. Each of the MLD lower MAC entities is in charge of deriving the PGDK from the received PGTK and computing, from the new or updated PGDK, the start times of the next Group EDP epochs of the EDP epoch sequence. According to these embodiments, the start times GETk+1 of the next Group EDP epochs of the EDP epoch sequence (corresponding to the epoch iteration n+1, n+2, etc. of the Group EDP epoch sequence) are computed from the shared private encryption key PGDK as follows: GETk+1 = GTk+1 + AIT with AIT = PRF-128\64(PGDK, “EDP”, GTk+1) mod (RandTR) GTk+1 = GTk + GEI According to some embodiments, KDF is the key derivation function as defined in section 12.7.1.6.2 (Key derivation function (KDF)) using the hash algorithm identified by the AKM suite selector (see Table 9-190 (AKM suite selectors)) of TGbi draft D0.6 and 802.11 REVme D5D7.0. Accordingly, PGDK is derived from PGTK as follows: PGDK = KDF-Hash-Length( PGTK, “EDP epoch Management Key”, AA) where: KDF-Hash-Length is the key derivation function as defined in 12.7.1.6.2 (Key derivation function (KDF)) using the hash algorithm identified by the AKM suite selector (see Table 9-190 (AKM suite selectors)), PGTK is the Privacy Group Temporal Key, and AA is the MAC address of the EDP AP MLD. According to some embodiments, several shared private group encryption keys may be inherited or derived from the PGTK by using any Key Derivation Function (KDF). For instance, a first one may be the shared private group encryption key PGDK[1] involved in the procedure used to generate the uncorrelated start times of a group EDP epochs and a second one PGDK[2] be a shared private group encryption key involved in the group addressed frames anonymization operated by an EDP MLD AP according to a BSS Privacy Enhancements anonymization. According to other embodiments, PGTK may comprise several shared private group keys operating at the MLD level for privacy purposes, including the shared private group key EDP_Key involved in the procedure used to generate the uncorrelated start times of a group EDP epochs. For example, the PGTK may comprise a concatenation at bit level of the several shared private group keys, and obtaining one group key would comprise extracting this group key from among the concatenation of group keys of the PGTK. In this embodiment, obtaining one group key from the PGTK, which may also be referred to as deriving the group key from the PGTK, is simpler than the derivation using a Key Derivation Function (KDF). In these other embodiments, PGTK may be a random value, assigned by the access point (AP) MLD, that is used to manage EDP features. According to some embodiments, the shared private group keys may be extracted from the PGTK by using the function denoted ExtractBits for which ExtractBits (S, F, N) providing bits F to F+N-1 of the bit string S starting from the left. For instance, the PGTK may contain a shared private group encryption key involved in the procedure used to generate the uncorrelated start time of PGDK[1] group EDP epochs and a second shared private group encryption key PGDK[2] involved in the group addressed frames anonymization operated by an EDP MLD AP according to a BSS Privacy Enhancements anonymization, the two keys PGDK[1] and PGDK[2] being extracted from PGTK as follows : EDP_Key = ExtractBits (PGTK.O, PGDK1_bits) PGDK = ExtractBits (PGTK, PGDK1_bits, PGDK2_bits) where ExtractBits(S, F, N) is a function providing bits F to F+N-1 of the bit string S starting from the left PGDK1_bits is the length of PGDK[1] and may be equal to 256 and PGDK2_bits is the length of PGDK[2] and may be equal to 256. According to some embodiments, the PGDK may be used for other EDP operations, features, and / or purposes than only the management of group EDP epochs and the computation of the successive start times of the EDP Group Epochs. For instance, the PGDK may be also used for anonymizing or de-anonymizing (i.e., remove anonymization) group addressed frames transmitted by an EDP AP MLD when an EDP MLD AP operates a BSS Privacy Enhancements anonymization. To handle the PGTK, a new type of security association may be specified, referred to as PGTKSA (PGTK security association) taking part of Robust Security Network Association (RSNA). It results of a successful group key handshake as illustrated in Figure 4, the Reassociation Response frame of the fast BSS transition protocol, the encrypted Reassociation Response frame when operating an EDPKE authentication as illustrated in Figure 3a or an IEEE 802.1X authentication as illustrated in Figure 3b, or successful FILS authentication. A PGTKSA may be created by an Authenticator’s Station Management Entity (SME) when dot1 IGroupEpochActivated is true. A PGTKSA has the lifetime of the AP MLD. A Supplicant’s SME creates a PGTKSA when dot1 IGroupEpochActivated is true, upon receiving a PGTK from its Authenticator. A PGTKA may consist of a PGTK and the Authenticator MAC address. PGTK is a hierarchy defined in RSNA consisting of a single key to provide anonymization for individually addressed frames, or more generally EDP features. The Authenticator (e.g., AP MLD) may select the PGTK as a random value each time it is generated. The Authenticator may update the PGTK for any reason, for example in case of a disassociation or deauthentication of a non-AP MLD or in the case of an event within the SME that triggers a group key handshake. The PGTK is configured via the MLME-SETKEYS.request primitive. The MLME-SETKEYS.request primitive is used to cause the keys identified in the parameters of the primitive to be set in the MAC and enabled for use. The SetKeyDescriptor of the MLME-SETKEYS.request consists of the following parameters: Name Type Valid range Description Key Bit string N / A The temporal key value Length Integer NA The number of bits in the Key to be used. Key ID Integer (> 3 shall be used with TKIP, CCMP, and GCMP; 4-5 with BIP for IGTK; 6-7 with BIP for BIGTK; 8-9 with BIP for WIGTK; and 10-4095 are reserved Key identifier Key Type Enumeration Group, Pairwise, PeerKey, IGTK, BIGTK, WIGTK.PGTK Defines whether this key is a GTK, TK. TPK-TK. IGTK, BIGTK, et-WIGTK or PGTK respectively. Address MAC address Any valid -individual address This parameter is valid only when the Key Type value is one of: — Pairwise, — Group and the STA or MLP is in an IBSS or PBSS (but not an MBSS), — PeerKey. Receive Sequence Counter 8 octets N / A Initialization value of the replay counter(s). This parameter is valid only when the Key Type is Group, IGTK, BIGTK. or WIGTK. The MLME-SETKEYS.request primitive may operate as follows: when the Key Type is Group, IGTK, BIGTK, WIGTK, or PGTK and the key matches the GTK, IGTK, BIGTK, WIGTK, or PGTK, if any, installed as a result of EAPOL-Key PDUs or exiting 10 WNM sleep mode receipt of this primitive shall have no effect except updating the RSC(s) when they are greater than those currently stored. Otherwise, irrespective of the Key Type parameter, when the Key parameter is the same as a key installed as a result of EAPOL-Key PDUs or exiting WNM sleep mode, receipt of this primitive shall have no effect. Otherwise, receipt of this primitive causes the MAC to apply the keys as follows: 15 - the MAC uses the key and key ID for the transmission of subsequent frames to which the key and key ID apply (as defined by the Key Type and Address parameters), - when the Key Type parameter is not PGTK, the MAC installs the key with the associated key ID such that received frames forthat cipher, of the appropriate type, and containing the matching key ID are processed using that key and its associated state information. When the Key Type parameter is PGTK, the MAC installs the key such that the successive start times of the EDP Group Epochs are processed using that key, and - when the Key Type parameter is Pairwise or PeerKey, and the Key, Key ID, and Address (where valid) parameters identify a new key to be set, the MAC shall initialize the transmitter TSC / PN counter and the receiver replay counter(s) to 0. When the Key Type parameter is not Pairwise, PeerKey, or BIGTK, or PGTK, and the Key, Key ID, and Address (where valid) parameters identify a new key to be set, the MAC shall initialize, depending on the direction of the traffic, the transmitter TSC / PN / IPN / WIPN counter to 0 or 1 or the receiver replay counter(s) to the value in the Receive Sequence Count parameter. An SME establishes an RSNA in one of several ways, among which: • If an RSNA uses authentication negotiated over IEEE Std 802.1Xor FILS authentication in a infrastructure BSS and if the Group EDP epoch is supported by both the AP MLD and the non-AP MLD, the SME programs the PGTK into the MAC for anonymization of individually addressed frames or more generally EDP features. • If an RSNA is based on a PSK or password in a infrastructure BSS and if the Group EDP epoch is supported by both the AP MLD and the non-AP MLD, the SME programs the PGTK into the MAC for anonymization of individually addressed frames or more generally EDP features. • If the Group EDP epoch is supported by both the AP MLD and the non-AP MLD and if an RSNA allows for confidentiality only (no authentication) in a infrastructure BSS, the SME programs the PGTK into the MAC for anonymization of individually addressed frames or more generally EDP features. The procedures used for IEEE 802.11 Association, reassociation, and disassociation should also handle the PGTK. More precisely, concerning the non-AP STA, non-AP MLD, and non-PCP STA association initiation procedures, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA, and TPKSA (including temporal keys) held for communication with the AP or PCP by using MLME-DELETEKEYS.request primitive before invoking MLME-ASSOCIATE.request primitive. The MLME-DELETEKEYS.request primitive is used to reinforce the security and may be used, in each involved STA, to delete the temporal key(s) established for the security association, so that they cannot be used to protect subsequent IEEE 802.11 traffic. An SME uses this primitive when it deletes a PTKSA, GTKSA, IGTKSA, BIGTKSA, PGTKSA, WIGTKSA or TPKSA. The MLME-DELETEKEYS.request primitive is generated by the SME at any time when keys for a security association are to be deleted in the MAC. More precisely, the MLME-DELETEKEYS.request primitive deletes the temporal key(s) established for the security association so that they cannot be used to protect subsequent IEEE 802.11 traffic. An SME uses this primitive when it deletes a PTKSA, GTKSA, IGTKSA, BIGTKSA, PGTKSA, WIGTKSA or TPKSA. The DeleteKeyDescriptor of the MLME-DELETEKEYS.request may consist in the following parameters: Name Type Valid range Description Key ID Integer 0-3 shall be used with TKIP, CCMP, and GCMP; 4-5 with BIP for IGTK; 6-7 with BIP for BIGTK; (llba)8-9 with BIP for WIGTK; and 10^4095 are reserved Key identifier. Key Type Enumeration Group, Pairwise, PeerKey, IGTK, BIGTK, WIGTK, PGTK Defines whether this key is a GTK, TK, TPK-TK, IGTK, BIGTK, WIGTK or PGTK respectively. Address MAC address Any valid individual address This parameter is valid only when the Key Type value is one of: — Pairwise, — Group and the STA or MLD is in an IBSS or PBSS (but not an MBSS), — PeerKey. Encapsulation Mode Enumeration Normal, BCE This parameter is valid only when the Key Type value is BIGTK Similarly, concerning the AP, AP MLD, or PCP association receipt procedures, upon receipt of an Association Request frame from a STA or by an AP MLD after an AP affiliated with the AP MLD receives an Association Request frame with Basic Multi-Link element from a non-AP STA affiliated with a non-AP MLD, and if the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the STA or non-AP MLD by using the MLME-DELETEKEYS.request primitive. Similarly, concerning the non-AP STA, non-AP MLD, and non-PCP STA reassociation initiation procedures, except when the association is part of a fast BSS transition, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA(11ba), WIGTKSA, WTKSA(Hbi), PGTKSA and TPKSA (including temporal keys) held for communication with the AP or PCP by using the MLME-DELETEKEYS.request primitive before invoking an MLME-REASSOCIATE.request primitive. Similarly, concerning the AP, AP MLD, or PCP reassociation receipt procedures, upon receipt of a Reassociation Request frame from a STA or by an AP affiliated with an AP MLD upon receipt of a Reassociation Request frame with Basic Multi-Link element from a non-AP STA affiliated with a non-AP MLD, and if management frame protection is not in use, or the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the reassociation is not part of a fast BSS transition, the SME of the AP or PCP should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the STA or the non-AP MLD by using the MLME-DELETEKEYS.request primitive. Similarly, concerning the non-AP STA, non-AP MLD, and non-PCP STA disassociation initiation procedures, upon receipt of an MLME-DISASSOCIATE.request primitive, a non-AP STA, non-AP MLD, and non-PCP STA’s MLME should disassociate from an AP, AP MLD, or PCP, respectively and upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the AP, AP MLD, or PCP by using the MLME DELETEKEYS.request primitive and by invoking an MLME-SETPROTECTION.request(None) primitive. In the case of an MM-SME coordinated STA, the MLME should perform this for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. Similarly, concerning the non-AP STA, non-AP MLD, and non-PCP STA disassociation receipt procedure, upon receipt of a Disassociation frame from an AP, AP MLD, or PCP for which the state is State 3 or State 4 (as defined in the IEEE P802.11REVme™ / D7.0 standard), if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection was negotiated when the PTKSA(s) were created and the frame is not discarded per management frame protection processing, a non-AP STA, non-AP MLD, and non-PCP STA, respectively, should disassociate from the AP, AP MLD, or PCP and upon receiving the MLME-DISASSOCIATE.indication primitive, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the AP, AP MLD, or PCP by using the MLME DELETEKEYS.request primitive and by invoking an MLME-SETPROTECTION.request(None) primitive. The MM-SME should perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. Similarly, concerning the AP, AP MLD, or PCP disassociation initiation procedure, upon receipt of an MLME-DISASSOCIATE.request primitive, an AP, AP MLD, or PCP should disassociate a STA (with respect to the AP or PCP) or a non-AP MLD (with respect to the AP MLD) and upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA(11ba), WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the STA by using the MLME DELETEKEYS.request primitive and by invoking an MLME-SETPROTECTION.request(None) primitive. The MM-SME should perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. Similarly, concerning the AP, AP MLD, or PCP disassociation receipt procedure, Upon receipt of a Disassociation frame from a STA or a non-AP MLD for which the state is State 3 or State 4, if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection was negotiated when the PTKSA(s) were created and the frame is not discarded per management frame protection processing, the AP or PCP(with respect to the STA) or AP MLD (with respect to the non-AP MLD) should disassociate the STA or the non-AP MLD, upon receiving an MLME-DISASSOCIATE.indication primitive the SME should delete any PTKSA, GTKSA, IGTKSA, BIGTKSA, WIGTKSA, WTKSA, PGTKSA and TPKSA (including temporal keys) held for communication with the STA by using the MLME DELETEKEYS.request primitive and by invoking an MLME-SETPROTECTION.request(None) primitive. The MM-SME should perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOC I ATE. request or MLME-REASSOCIATE.request primitive that established the association. During RSNA security association termination, when a non-AP STA’s SME receives a successful MLME-ASSOCIATE.confirm or MLME-REASSOCIATE.confirm primitive that is not part of a fast BSS transition or receives or invokes an MLME Disassociation or Deauthentication primitive, it may delete some security associations. Similarly, when an AP’s SME receives an MLME-ASSOCIATE.indication or MLME-REASSOCIATE.indication primitive from a STA that has not negotiated management frame protection, it deletes some security associations. Likewise, when an AP’s SME receives an MLME-ASSOCIATE.indication or MLM E-REASSOCIATE.indication primitive from a STA that has negotiated management frame protection that a) has resulted in an MLME (re)association response that is successful, and b) is not part of a fast BSS transition, or receives an MLME-DEAUTHENTICATE.indication or MLME-DISASSOCIATE.indication primitive or issues an MLME-DEAUTHENTICATE.request or MLME-DISASSOCIATE.request primitive, it deletes some security associations. In the case of an ESS (Extended Service Set), the non-AP STA’s SME may delete any PTKSA(s), GTKSA(s), IGTKSA(s), BIGTKSA(s)(11ba), WIGTKSA(s), WTKSA(s), and TPKSA(s), the non-AP MLD’s SME shall delete any PGTKSA(s), and the AP’s SME shall delete the PTKSA and the AP’s SME may delete the PTKSA. In the case of an IBSS, the SME may delete the PTKSA(s), the GTKSA(s), and any IGTKSA(s). Once the security associations have been deleted, the SME then invokes the MLME-DELETEKEYS.request primitive to delete all temporal keys associated with the deleted security associations. Authentication Figure 3a schematically illustrates an EDPKE authentication, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure. The EDPKE authentication allows for the protection of Management frames without association by establishing a PTKSA using authentication frames. The establishment of an EDPKE authentication between an EDP non-AP MLD and a EDP AP MLD is based on an Enhanced Data Privacy Key exchange including the messages 300, 301, 302 and 303, as specified in section 12.14.8 (Enhanced Data Privacy Key Exchange) of draft standard P802.11bi™ / D0.6. From a successful EDPKE authentication, a Pairwise Transient Key (PTK) is derived, as specified in section 12.14.8.3.4 (PTKSA derivation with EDPKE authentication) of draft standard P802.11bi™ / D0.6, including a temporal key (TK), both being used to encrypt the (Re)Association Request frame 310 and (Re)Association Response 311 during the association procedure. The EDP AP MLD includes a Key delivery element in the (Re)Association Response frame 311 and if a Key delivery element is included in the (Re)Association Response frame, the EDP AP MLD should construct the Key Delivery element with the RSC field set to 0, with the MLO GTK KDE (key data encapsulation) for each setup link, with the MLO IGTK KDE for each setup link if management frame protection is negotiated, with the MLO BIGTK KDE for each setup link if beacon protection is enabled, with the PGTK KDE if Group EDP epoch is supported by both AP MLD and non-AP MLD, as illustrated in Figure 12. More precisely, the PGTK KDE is identified with a specific KDE selector, for example a new KDE selector in Table 12-10—KDE selector of the IEEE P802.11 REVme™ / D7.0 standard. For instance, an Organizationally Unique Identifier set to 00-0F-AC and a Data type set to value 20 may be used to identify a PGTK KDE, as illustrated in Figure 5. As illustrated in Figure 6, a PGTK KDE may contain a PGTK Switch Time Indication field and a PGTK field. The PGTK Switch Time Indication field indicates the time at which the PGTK indicated in the Key field shall be applied to replace the PGTK in use by the EDP AP MLD and the EDP non-AP MLDs. The 8 octet PGTK Switch Time Indication is set to the time at which the PGTK contained in the PGTK field shall be applied by the EDP AP MLD and the EDP non-AP MLDs using, as a time-base, the value of the TSF corresponding to the BSS identified by the BSSID of the frame containing the PGTK KDE. The PGTK field contains the PGTK. The EDP non-AP MLD should decrypt the (Re)Association Response frame 311 received from the EDP AP MLD using the TK and the pairwise cipher indicated during the Enhanced Data Privacy Key exchange. If the decryption fails, then the association exchange fails. On successful (re)association, the EDP non-AP MLD installs the GTK and GTK RSC, and IGTK and IGTK RSC if management frame protection is enabled, and BIGTK and BIGTK RSC if present in the Key Delivery element and dot1 IBeaconProtectionEnabled is true, and PGTK if Group EDP epoch is supported by both AP MLD and non-AP MLD. Figure 3b schematically illustrates an IEEE 802.1X authentication, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure. The IEEE 802.1X authentication allows for the protection of Management frames without association by establishing a PTKSA using authentication frames. The establishment of an IEEE 802.1X authentication between an EDP non-AP MLD and an EDP AP MLD is based on an IEEE 802.1X authentication exchange including the messages 350, 351, 352 and 353 as specified in the section 12.14.8 (Enhanced Data Privacy Key Exchange) of draft standard P802.11bi™ / D0.6. From a successful IEEE 802.1X authentication, a Pairwise Transient Key (PTK) is derived, as specified in section 12.14.4 (IEEE 802.1X authentication utilizing Authentication frames) of draft standard P802.11bi™ / D0.6, including a temporal key (TK), both being used to encrypt the (Re)Association Request frame 360 and (Re)Association Response 361 during the association procedure. The EDP AP MLD includes a Key delivery element in the (Re)Association Response frame 361 and if a Key delivery element is included in the (Re)Association Response frame, the EDP AP MLD should construct the Key Delivery element with the RSC field set to 0, with the MLO GTK KDE for each setup link, with the MLO IGTK KDE for each setup link if management frame protection is negotiated, with the MLO BIGTK KDE for each setup link if beacon protection is enabled, with the PGTK KDE if Group EDP epoch is supported by both AP MLD and non-AP MLD, as illustrated in Figure 12. The EDP non-AP MLD should decrypt the (Re)Association Response frame 361 received from the EDP AP MLD using the TK and the pairwise cipher indicated during the IEEE 802.1X authentication exchange. If the decryption fails, then the association exchange fails. On successful (re)association, the EDP non-AP MLD installs the GTK and GTK RSC, and IGTK and IGTK RSC if management frame protection is enabled, and BIGTK and BIGTK RSC if present in the Key Delivery element and dot1 IBeaconProtectionEnabled is true, and PGTK if Group EDP epoch is supported by both AP MLD and non-AP MLD. Figure 4 schematically illustrates a group key handshake, enabling transmission of a privacy group temporal key according to some embodiments of the disclosure. When a non-AP and non-PCP STA operates an RSNA rekeying (PCP standing for PBSS control point and PBSS standing for personal basic service set), an Authenticator (e.g., EDP AP) may initiate a group key handshake for the purpose of GTK rekeying (with a GTKSA), IGTK keying (with an IGTKSA), BIGTK rekeying (with a BIGTKSA), PGTK rekeying (with a PGTKSA), or WIGTK rekeying (with a WIGTKSA). For M LO, if a PGTKSA update is triggered, the AP M LD updates PGTK through a group key handshake between the AP MLD and non-AP MLD. More precisely, when the Authenticator (e.g., the EDP AP MLD) is an AP MLD and the Supplicant is a non-AP MLD (e.g., the EDP non-AP MLD), the Authenticator may also use the Group key handshake to send new GTK(s) for any of the setup links and, if management frame protection is negotiated, new IGTK(s) for any of the setup links, and if beacon protection is enabled, new BIGTK(s) for any of the setup links to the Supplicant and if Group EDP epoch is supported by both AP MLD and non-AP MLD, a new PGTK. It is recalled that IEEE Std 802.11 uses EAPOL-Key PDUs (EAPOL standing for extensible authentication protocol over LANs, LAN standing for local area network, and PDU standing for protocol data unit), each carried in one or more EAPOL-Key frames, to exchange items of information between supplicants, for example an EDP non-AP, and authenticators, for example an EDP AP. These exchanges result in cryptographic keys and synchronization of security association state. EAPOL-Key PDUs make it possible to update the GTK and the PGTK (during a group key handshake). As illustrated in Figure 4, a first step of a group key handshake is directed to transmitting a first encrypted EAPOL-Key frame 400, from the EDP AP MLD to the EDP non-AP MLD. The encrypted EAPOL-Key frame 400 includes new GTK(s) for any of the setup links and, if a management frame protection is negotiated, new IGTK(s) for any of the setup links, and if a beacon protection is enabled, new BIGTK(s) for any of the setup links to the Supplicant, and if a Group EDP epoch is supported by both the AP MLD and the non-AP MLD, a new PGTK. To that end, the EAPOL-Key frame may include a PGTK KDE identified with a specific KDE selector, for example a new KDE selector in Table 12-10—KDE selector of the IEEE P802.11REVme™ / D7.0 standard. For instance, an Organizationally Unique Identifier set to 00-0F-AC and a Data type set to value 20 may be used to identify a PGTK KDE, as illustrated in Figure 5. As illustrated in Figure 6, a PGTK KDE may contain a PGTK Switch Time Indication field and a PGTK field. The PGTK Switch Time Indication field indicates the time at which the PGTK indicated in the Key field should be applied for replacing the PGTK in use by the EDP AP MLD and the EDP non-AP MLDs. The 8 octet PGTK Switch Time Indication may be set to the time at which the PGTK contained in the PGTK field should be applied by the EDP AP MLD and the EDP non-AP MLDs using, as a timebase, the value oftheTSF corresponding to the BSS identified by the BSSID of the frame containing the PGTK KDE. The PGTK field contains the PGTK. In that way, the encrypted EAPOL-Key frame 400 includes, for MLO, when present, PGTK and PGTK Switch Time Indication. The EAPOL-Key frame 400 may be expressed as follows: message 1 (Authenticator^Supplicant): EAPOL-Key(1, 1, 1, 0, G, 0, RSC, 0, MIC, {[GTK(N)] [, OCI} [, IGTK(M, IPN)] [, BIGTK(Q, BIPN)] [, WIGTK(R, WIPN)] [, MLO GTKn] [, MLO IGTKn] [, MLO BIGTKn] [, PGTK(ST)]) wherein PGTK, for MLO, when present, denotes the PGTK with its PGTK Switch Time (ST) as encapsulated using a PGTK KDE, as described with reference to Figure 6. Upon reception of message 400, at step 405, the supplicant (e.g., the EDP non-AP MLD) decrypts the message and sets new GTK(s) for any of the setup links and, if a management frame protection is negotiated, new IGTK(s) for any of the setup links, and if a beacon protection is enabled, new BIGTK(s) for any of the setup links to the Supplicant and if a Group EDP epoch is supported by both the AP MLD and the non-AP MLD, a new PGTK into the MAC at the time indicating by the PGTK Switch Time Indication advertised in companion to the PGTK. To that end, when the Supplicant is a non-AP MLD, it uses the MLME-SETKEYS.request primitive to configure the PGTK, when present, into the MAC at the time indicating by the PGTK Switch Time Indication. At the reception of message 400 and in addition to decrypting and updating the PTK, GTK, IGTK, and PGTK, the EDP non-AP MLD sends a second message 410 comprising an acknowledgment and the Message Integrity Code (MIC). Upon receiving message 410, at step 415, the AP MLD computes the MIC using the Key Confirmation Key (KCK). Next, it compares the received MIC to the computed MIC. If the received MIC is the same as the computed MIC, the non-AP MLD and the AP MLD have the same Pairwise Temporal Key (PTK). In such a case, the AP MLD sets new GTK(s) for any of the setup links and, if a management frame protection is negotiated, new IGTK(s) for any of the setup links, and if a beacon protection is enabled, new BIGTK(s) for any of the setup links to the Supplicant and if a Group EDP epoch is supported by both the AP MLD and the non-AP MLD, a new PGTK into the MAC at the time indicating by the PGTK Switch Time Indication advertised in companion to the PGTK. To that end, when the Authenticator is an AP MLD supporting a Group EDP epoch, it uses the MLME-SETKEYS.request primitive to configure the PGTK, when present, into the MAC at the time indicating by the PGTK Switch Time Indication. FILS Authentication When the EDP non-AP MLD (also referred to as FILSO) operates a FILS authentication with an EDP AP (also referred to as FILSR), FILSO and FILSR perform a key establishment using Authentication frames and perform a key confirmation using (Re)Association Request and (Re)Association Response frames. Upon receiving a (Re)Association Request for a FILS key confirmation, the FILSR constructs a (Re)Association Response frame for a FILS authentication. To that end, the FILSR constructs a Key Delivery element indicating the current GTK and GTK PN, the current IGTK and IPN if management frame protection is enabled, the current BIGTK and BIPN if beacon protection is enabled, the current WIGTK and WIPN if WUR frame protection is enabled, and the current PGTK if Group EDP epoch is supported by both AP MLD and non-AP MLD. For non-MLO, the GTK is carried in a GTK KDE. The IGTK and IPN are carried in an IGTK KDE, the BIGTK and BIPN are carried in a BIGTK KDE, and the WIGTK and WIPN are carried in a WIGTK KDE. For MLO, the PGTK is carried in a PGTK KDE, the GTKs, for all setup links, are carried in MLO GTK KDEs, the IGTKs are carried in MLO IGTK KDEs, and the BIGTKs are carried in MLO BIGTK KDEs. At the reception of the (Re)Association Response frame for FILS authentication, upon successful completion of the FILS authentication procedure, the FILSO should process the Key Delivery element in the (Re)Association Response frame. The FILSO installs the GTK and GTK RSC, the IGTK and IGTK RSC if management frame protection is enabled, the BIGTK and BIGTK RSC if present in the Key Delivery element and if dot1 IBeaconProtectionEnabled is true, the WIGTK and WIGTK RSC if present in the Key Delivery element and if dotHRSNAWURFrameProtectionActivated is true, and PGTK if present in the Key Delivery element and PGTK if present in the Key Delivery element and group EDP epoch is supported by both AP MLD and non-AP PMLD. For MLO, the FILSO installs the PGTK and installs GTKs, IGTKs, and BIGTKs for each setup link. Fast BSS Transition When the EDP non-AP MLD operates a Fast BSS Transition (FT), the security key holders (KHs) which implement the specific security functions such as keys generation and distribution should also handle the PGTK. In particular, if a Group EDP epoch is supported by both the AP MLD and the non-AP MLDs, the R1KH (R1 Key Holders physically located in each AP of the mobility domain) should derive and distribute the PGTK to all connected non-AP MLDs. When an EDP non-AP MLD operates the FT authentication sequence in order to roam from an EDP non-AP MLD to another EDP non-AP MLD, the fourth message of the sequence containing the group keys should now include the PGTK. To that end, the Fast BSS Transition element (FTE) should be set as follows: when this message of the authentication sequence appears in a Reassociation Response frame, the Optional Parameter(s) field in the FTE may include the GTK, IGTK, BIGTK, WIGTK subelements, or PGTK, MLO GTK, MLO IGTK, and MLO BIGTK subelements. If a GTK, IGTK, BIGTK, WIGTK, PGTK, MLO GTK, MLO IGTK, or MLO BIGTK are included, the Key field of the subelement should be wrapped using PTK-KEK or KEK2 and the appropriate key wrap algorithm, as specified in Table 12-11 (Integrity and key wrap algorithms) and 12.7.2 (EAPOL-Key frames) of the IEEE P802.11REVme™ / D7.0 standard. The padding consists of appending a single octet Oxdd followed by zero or more 0x00 octets. When processing a received message, the receiver should ignore this trailing padding. The padding does not change the value of the Key Length field. Note that the length of the encrypted Key field can be determined from the length of the GTK, IGTK, BIGTK, PGTK, WIGTK, MLO GTK, MLO IGTK, or MLO BIGTK subelement. The PGTK sub-element contains the PGTK, used for providing anonymization for individually addressed frames or more generally EDP features. More precisely, as illustrated in Figure 7, the PGTK sub-element may contain a Subelement ID field, a length field, a PGTK Switch Time Indication field, a Key Length field and a Wrapped Key field. The Sub-element ID field identifies the FTE sub-elements and is defined in Table 9-221—Sub-element IDs of the IEEE P802.11REVme™ / D7.0 standard. A specific value that was reserved until now may be assigned to PGTK sub-element, like the value 11, as illustrated in Figure 8. The PGTK Switch Time Indication field indicates the time at which the PGTK indicated in the Key field should be applied to replace the PGTK in use by the EDP AP MLD and EDP non-AP MLDs. The 8 octet PGTK Switch Time Indication is setto the time at which the PGTK contained in the PGTK field should be applied by the EDP AP MLD and the EDP non-AP MLDs using, as a time-base, the value of the TSF corresponding to the BSS identified by the BSSID of the frame containing the PGTK KDE. The Key Length field is the length of the PGTK in octets, not including any padding. The Wrapped Key field contains the wrapped PGTK being distributed. In a case according to which the FT resource request protocol is used, which involves an additional message exchange after the Authentication-Request / Response frame, or FT Request / Response frame, and prior to reassociation, the security key holders (KHs) should also handle the PGTK. In such a case, when the Over-the-air fast BSS transition with resource request is used, in an RSN, on successful completion of the FT authentication exchange of the FT resource request protocol, the PTKSA has been established and proven live. The key replay counter should be initialized to 0, and the subsequent EAPOL-Key PDUs (e.g., GTK, IGTK, BIGTK, PGTK and WIGTK updates) should use the key replay counter to detect and discard replays. The PTKSA should be deleted by the target FTR if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. Similarly, when Over-the-DS fast BSS transition with resource request is used, in an RSN, on successful completion of the FT Confirm / Acknowledgment frame exchange, the PTKSA has been established and proven live. The key replay counter should be initialized to 0, and the subsequent EAPOL-Key frames (e.g., GTK, IGTK, BIGTK, WIGTK and PGTK updates) should use the key replay counter to detect and discard replays. The PTKSA should be deleted by the target FTR if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. Resource request procedures are specified in 13.11 (Resource request procedures) of the IEEE P802.11REVme™ / D7.0 standard. In the case of a FT reassociation, the security key holders (KHs) should also deal with also the PGTK. To that end, if the FTO does not send a Reassociation Request frame to the target AP within the reassociation deadline interval received during the FT initial mobility domain association, the target AP may delete the PTKSA, and the FTO should abandon this transition attempt. The FTO should perform a reassociation directly with the target FTR, for example according to the following exchange: FTO^Target FTR: Reassociation Request(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, ROKH-ID], RIC-Request, RSNXE, Basic Multi-Link element) Target FTR^FTO: Reassociation Response(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, ROKH-ID, GTK[N], IGTK[M], BIGTK[Q], WIGTK[R], PGTK, MLO GTKn, MLO IGTKn, MLO BIGTKn], RIC-Response, RSNXE, Basic MultiLink element) wherein MLO GTK is the MLO GTK subelement for the AP affiliated with the AP MLD for the link specified by the value in the Link ID field, — MLO IGTK is the MLO IGTK subelement for the AP affiliated with the AP MLD for the link specified by the value in the Link ID field, — MLO BIGTKisthe MLO BIGTK subelement for the AP affiliated with the AP MLD for the link specified by the value in the Link ID field, the GTK[N], IGTK[M], BIGTK[Q] are present when the FTR is an AP, and the MLO GTKn, MLO IGTKn, MLO BIGTKn, PGTK and the Basic Multi-Link element are present when the FTR is an AP MLD. Wireless Network Management (WNM) sleep mode The Wireless Network Management (WNM) sleep mode should also handle the PGTK when the AP MLD is an EDP AP MLD and the non-AP MLDs are EDP non-AP MLDs. The extended power save mode for non-access point (non-AP) stations (STAs) and non-AP multi-link devices (non-AP MLDs) whereby a non-AP STA or non-AP STAs affiliated with a non-AP MLD need not listen for every delivery traffic indication map (DTIM) beacon and do not perform group temporal key / integrity group temporal key / beacon integrity group temporal key (GTK / IGTK / BIGTK) updates, the non-AP MLD needs not perform privacy group temporal key (PGTK) updates. In other words, WNM sleep mode enables an extended power save mode in which a non-AP STA needs not listen for every DTIM beacon, and does not need to perform GTK / IGTK / BIGTK updates. Further, the non-AP MLD does not need to perform PGTK updates. For MLO, WNM sleep mode enables a non-AP STA affiliated with the non-AP MLD to signal to an AP affiliated with the AP MLD that all the non-AP STAs affiliated with the non-AP MLD might transition to doze state for a specified length of time. This enables a non-AP STA or a non-AP MLD to reduce power consumption and remain associated while the non-AP STA or the non-AP MLD has no traffic to send to or receive from the APorAPMLD. The WNM sleep state is maintained by the MLD and the WNM sleep mode procedures are performed at the MLD level and apply to all the STAs affiliated with the MLD. The enter and the exit of a WNM sleep mode of a non-AP MLD is operated with an exchange of WNM Sleep Mode Request / Response frames between the non-AP MLD and the AP MLD through their respective affiliated STA and AP over a setup link. When a non-AP MLD (in WNM sleep mode) initiates an WNM sleep mode exit, it transmits a WNM Sleep Mode Request including a WNM Sleep Mode element for which the Action Type field is set to 1 indicating an Exit WNM sleep mode. When an AP MLD receives a WNM Sleep Mode Request frame from a non-AP MLD via one of its affiliated APs, the AP MLD should, in response, send a WNM Sleep Mode Response frame, via one of its affiliated APs operating on a link that is enabled for the non-AP MLD and subject to the power state of the non-AP STA affiliated with the non-AP MLD and operating on that link. An AP MLD may also send, via one of its affiliated APs that is operating on an enabled link for the non-AP MLD and subject to the power state of the non-AP STA affiliated with the non-AP MLD and operating on that link, the WNM Sleep Mode Response frame without solicitation upon the AP MLD’s deletion of all traffic filter sets established according to the traffic filtering agreement between the AP MLD and the non-AP MLD. The WNM Sleep Mode Response frame transmitted by the AP MLD includes a WNM Sleep Mode element for which the WNM Sleep Mode Response Status is set to 0 when the Exit WNM sleep mode is accepted and 1 when the Exit WNM sleep mode is accepted and requires also the GTK / IGTK / BIGTK / PGTK update, as illustrated in Figure 9. When the GTK / IGTK / BIGTK / PGTK update is required, the Key Data field of the WNM Sleep Mode Response frame contains zero or more sub-elements that provide the current GTK, IGTK, BIGTK to the STA (affiliated with the non-AP MLD) and the current PGTK to the non-AP MLD. More precisely, for MLO, with a RSN and a valid PTK configured for the non-AP MLD, if Group EDP epoch is supported by both the AP MLD and the non-AP MLD, the current PGTK should be included in the WNM Sleep Mode Response frame. If a PGTK update is in progress, the pending PGTK should be included in the WNM Sleep Mode Response frame. A sub-element is identified by an Optional sub-element ID, as specified in Table 9-540 of the Optional sub-element IDs for WNM Sleep Mode parameters of the IEEE P802.11REVme™ / D7.0 standard. A specific value that was reserved until now may be assigned to PGTK sub-element, like the value 6, as illustrated in Figure 10. Figure 11 illustrates an example of a WNM Sleep Mode PGTK sub-element format. The PGTK sub-element contains the PGTK of the EDP AP MLD. The Subelement ID field is set to the value of the Optional subelement ID assigned to a PGTK, for example the value 6. It may be specified in a table like Table 9-540 in the IEEE P802.11REVme™ / D7.0 standard, as illustrated in Figure 10. The Length field is defined in the section 9.4.3 (Subelements) of the IEEE P802.11REVme™ / D7.0 standard. The PGTK Switch Time Indication field indicates the time at which the PGTK indicated in the Key field should be applied to replace the PGTK in use by the EDP AP MLD and the EDP non-AP MLDs. The 8 octet PGTK Switch Time Indication is set to the time at which the PGTK contained in the PGTK field should be applied by the EDP AP MLD and the EDP non-AP MLDs using, as a time-base, the value of the TSF corresponding to the BSS identified by the BSSID of the frame containing the PGTK KDE. The Key field is the PGTK being distributed. Indeed, as a Group Key Handshake should be done separately for each station during a GTK rekeying (used here to deliver the PGTK), the EDP non-AP MLDs don’t receive the PGTK at the same time whereas all the EDP non-AP MLDs of an EDP group should use the same PGTK in order to compute the same start time of a group EDP epoch. To address this temporal issue, a PGTK Switch Time Indication is delivered in companion to the PGTK to indicate the time at which the delivered PGTK should be applied by the EDP AP MLD and the EDP non-AP MLDs. When the non-AP MLD receives the WNM Sleep Mode Response frame from the AP MLD via one of its affiliated non-AP STAs, all the affiliated non-AP STAs of the non-AP MLD should delete the GTKSA if the response indicates success. If a RSN is used with a management frame protection, the non-AP STA should delete the IGTKSA if the response indicates success. If a RSN is used with a beacon frame protection, the non-AP STA should delete the BIGTKSA if the response indicates success. If a Group EDP epoch is supported by both the AP MLD and the non-AP MLD, the non-AP MLD should delete the PGTKSA if the response indicates success. Hardware for carrying out the steps of some embodiments of the disclosure Figure 13a schematically illustrates an example of a communication device that may correspond any of the stations described by reference to Figure 1, of a wireless network, configured to implement at least some embodiments of the disclosure. The communication device, referenced 1300, may preferably be a device such as a microcomputer, a workstation, or a light portable device. Communication device 1300 may comprise a communication bus 1305 to which may be connected: - a central processing unit 1301, such as a processor, denoted CPU; - a memory 1303, denoted MEM, for storing an executable code of methods or steps of the methods according to embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing the methods; and - at least two communication interfaces 1302 and 1302’ 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 1304 and 1304’, respectively. Preferably, communication bus 1305 may provide communication and interoperability between the various elements included in the communication device 1300 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 1300 directly or by means of another element of the communication device 1300. 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 1302 or 1302’, in order to be stored in the memory 1303 of communication device 1300 before being executed. In some embodiments, communication device 1300 may be a programmable apparatus which uses software to implement embodiments of the disclosure. However, alternatively, some embodiments of the disclosure may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Figure 13b schematically illustrates a MAC data plane architecture configured to implement at least some embodiments of the present disclosure. The MAC layer of an MLD 1350 contains a MLD upper MAC sublayer 1360 (may also be referred to as entity) and multiple MLD lower MAC entities 1370-1, ..., 1370-n (may also be referred to as sublayers). The MLD upper MAC sublayer 1360 may include authentication, association, and reassociation between an AP MLD and a non-AP MLD, security association (e.g., PMKSA, PTKSA) and distribution of GTK / IGTK / BIGTK, SN / PN assignment for frames to be encrypted by PTK for individually addressed frames, SN assignment for group addressed MSDUs, power save buffering of individually addressed frames (only on AP MLD), encryption / decryption using PTK for individually addressed frames, selection of the MLD lower MAC entity for transmission, merging reception of MPDUs from two or more links, reordering of packets to ensure in-order delivery per each Block Ack session, block Ack scoreboarding for individually addressed frames (in collaboration with the MLD lower MAC entities). Optionally, the MLD upper MAC sublayer delivers successful status records of MPDUs and / or scoreboard context control information on Block Ack scoreboarding at one of the setup links to other setup links. In addition, the MLD upper MAC sublayer 1360 may include privacy operations as described in the present disclosure according to some embodiments. Each MLD lower MAC entity 1370-1, ..., 1370-n (or a part or group of) may include link specific control information exchange / indication (e.g., RTS / CTS, acknowledgements, NDP, etc.), power save state and mode, MAC address filtering for frame reception, Block Ack scoreboarding for individually addressed frames. In addition, each MLD lower MAC entity 1370-1, .... 1370-n may include privacy operations as described in the present disclosure according to some embodiments. Embodiment(s) of the disclosure can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a “non-transitory computer-readable storage medium”) to perform the functions of one or more of the above-described embodiment(s) and / or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the above-described embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiment(s) and / or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, 5 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. 10 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. 15 A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed may be combined without departing from the scope of the disclosure.

Claims

1. A method in a communication network, the method comprising:transmitting, by an access point, AP, affiliated with an AP multi-link device, MLD, to a non-AP station, STA, affiliated with a non-AP MLD, a frame including a group key, wherein the group key is for use in communications between the AP MLD and a group of one or more non-AP MLDs.

2. The method of claim 1, wherein the group key is a master group key, the master group key being used to derive at least one group derivation key for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

3. The method of claim 2, further comprising generating the master group key.

4. The method of claim 2 or claim 3, wherein the at least one group derivation key is derived by an MLD upper Media Access Control, MAC, sublayer of the AP MLD.

5. The method of claim 4, wherein the at least one group derivation key is used by the MLD upper MAC sublayer of the AP MLD to determine one or more start times at which at least one privacy parameter is to be modified, the one or more start times being transmitted to an MLD lower MAC entity of the AP MLD.

6. The method of claim 4, wherein the at least one group derivation key is transmitted to an MLD lower MAC entity of the AP MLD, the MLD lower MAC entity of the AP MLD determining one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the received group derivation key.

7. The method of claim 2 or claim 3, wherein the master group key is transmitted to an MLD lower MAC entity of the AP MLD, the at least one group derivation key being derived by the MLD lower MAC entity of the AP MLD.

8. The method of claim 7, wherein the MLD lower MAC entity of the AP MLD determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the group derivation key.

9. The method of any one of claims 2 to 8, wherein the master group key is updated and transmitted upon determining sleep mode exit of the non-AP MLD.

10. The method of any one of claims 2 to 9, further comprising creating a privacy security association in a robust security network association, RSNA, between the AP MLD and the non-AP MLD, the master group key and / or the at least one group derivation key being stored in the AP MLD, in the privacy security association.

11. The method of claim 10, wherein the privacy security association is created upon determining a successful group key handshake, reassociation response frame of a fast basic service set, BSS, transition protocol, or successful fast initial link setup, FILS, or authentication.

12. The method of any one of claims 2 to 11, wherein the master group key is a privacy group temporal key, PGTK, which value is a random number, and the at least one group derivation key is a privacy group derivation key, PGDK, which value is computed from PGTK using a key derivation function, KDF, based on a hash algorithm.

13. The method of claim 2, wherein the at least one group derivation key is used for anonymizing group addressed frames transmitted by the AP MLD when the MLD AP operates BSS Privacy Enhancements anonymization.

14. The method of claim 1, wherein the group key comprises a plurality of private group keys, the group key being used to obtain a private group key among the plurality for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

15. The method of claim 1, wherein the group key is a privacy group temporal key, PGTK, for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

16. The method of claim 15, further comprising determining a start time at which at least one privacy parameter is to be modified, the start time being determined as a function of the PGTK.

17. The method of claim 15, further comprising anonymizing group addressed frames transmitted by the AP MLD when the MLD AP operates BSS Privacy Enhancements anonymization, the group addressed frames being anonymized using the PGTK.

18. A method in a communication network, the method comprising:receiving, by a non-access point, AP, station, STA, affiliated with a non-AP multilink device, MLD, from an AP affiliated with an AP MLD, a frame including a group key, wherein the group key is for use in communications between the AP MLD and a group of non-AP MLDs.

19. The method of claim 18, wherein the group key is a master group key, the master group key being used to derive at least one group derivation key for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

20. The method of claim 19, further comprising transmitting the received master group key to an MLD upper Media Access Control, MAC, sublayer of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD upper MAC sublayer of the non-AP MLD and is transmitted, by the non-AP MLD, to an MLD lower MAC entity of the non-AP MLD.

21. The method of claim 20, wherein the MLD lower MAC entity of the non-AP MLD determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the received derived group key.

22. The method of claim 19, further comprising transmitting the received master group key to an MLD upper MAC sublayer of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD upper MAC sublayer of the non-AP MLD, the at least one group derivation key being used by the MLD upper MAC sublayer of the non-AP MLD to determine one or more start times at which at least one privacy parameter is to be modified, the one or more start times being transmitted to an MLD lower MAC entity of the non-AP MLD.

23. The method of claim 19, further comprising transmitting the received master group key to an MLD upper MAC sublayer of the non-AP MLD and transmitting, by the non-AP MLD, the master group key to an MLD lower MAC entity of the non-AP MLD, wherein the at least one group derivation key is derived by the MLD lower MAC entity of the non-AP MLD.

24. The method of claim 23, wherein the MLD lower MAC entity of the non-AP MLD determines one or more start times at which at least one privacy parameter is to be modified, the one or more start times being determined as a function of the derived group key.

25. The method of any one of claims 5, 6, 8, 16, 21, 22 or 24, wherein the at least one privacy parameter is an Association Identifier (AID).

26. The method of claim 2 or 19, wherein the master group key is updated during a groupkey handshake.

27. The method of any one of claims 19 to 26, further comprising creating a privacy security association in a robust security network association, RSNA, between the AP MLD and the non-AP MLD, the mastergroup key and / or the at least one group derivation key being stored in the non-AP MLD, in the privacy security association.

28. The method of claim 27, wherein the privacy security association is created upon determining a successful group key handshake, reassociation response frame of a fast basic service set, BSS, transition protocol, or encrypted reassociation response frame when operating an Enhanced Data Privacy Key Exchange, EDPKE, authentication or an IEEE 802.1X authentication, or successful fast initial link setup, FILS, authentication.

29. The method of claim 19, wherein the at least one group derivation key is used for deanonymizing group addressed frames received by the non-AP MLD when the AP MLD operates BSS Privacy Enhancements anonymization.

30. The method of claim 18, wherein the group key comprises a plurality of private group keys, the group key being used to obtain a private group key among the plurality for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

31. The method of claim 18, wherein the group key is a privacy group temporal key, PGTK, for use in communications between the AP affiliated with the AP MLD and one or more non-AP STAs affiliated with a non-AP MLD of the group of non-AP MLDs.

32. The method of claim 31, further comprising determining a start time at which at least one privacy parameter is to be modified, the start time being determined as a function of the PGTK.

33. The method of claim 31, further comprising de-anonymizing group addressed frames received by the non-AP MLD when the AP MLD operates BSS Privacy Enhancements anonymization, the group addressed frames being anonymized using the PGTK.

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

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

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

Images