Temporal key sharing for seamless roaming, devices and methods

Abstract

A STA initially associates with a seamless mobility domain SMD. A PTK or TK is defined with the first AP to which it associates, to protect communications with that AP. A by-default SR- PTK or SR-TK is also defined upon initially associating with the SMD, which SR-PTK / TK is shared amongst the APs of the SMD. A roaming from a current AP to a target AP is prepared during which a roaming-dedicated SR-PTK / TK is defined and shared with the current and target APs. The STA also defines a PTK / TK with the target AP. If a roaming-dedicated SR-PTK / TK is obtained, the STA uses it as SR-PTK / TK to protect communications with both the current and target APs during the process of roaming. Otherwise, the by-default SR-PTK / TK is used for communication protection. After the roaming process ends, the STA uses the PTK / TK defined with the target AP to protect communications with the target AP only.

Description

[0001] TEMPORAL KEY SHARING FOR SEAMLESS ROAMING, DEVICES AND METHODS

[0002] FIELD OF THE DISCLOSURE

[0003] The present disclosure generally relates to wireless communications and more specifically to roaming procedures for Multi-Link Devices (MLDs).

[0004] BACKGROUND OF THE DISCLOSURE

[0005] 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.

[0006] 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 multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.

[0007] The WLAN (Wireless Local Area Network) technology based on the IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 family standards provides a wireless communication between two or more devices.

[0008] Robust security network association (RSNA) in IEEE (RTM) Std 802.11-2020 allow stations (STA) (belonging or not to a non-AP Multi-Link Device - MLD - as defined in IEEE P802.11 be / D7.0, August 2024) to associate with an access point (AP - belonging or not to an AP MLD) managing a Basic Service Set (BSS) through an authentication or association procedure and possibly a 4-Way Handshake. During the procedure or the handshake, the STA and the AP exchange Nonces and establish a Pairwise Transient Key Security Association (PTKSA) that includes a PTK built from the Nonces. A Temporal Key extracted from the PTK is used to encrypt traffic exchanged between the devices (e.g. unicast frames), in particular to cryptographically encapsulate the exchanged Plaintext MPDUs (MAC Protocol Data Units) into encrypted MPDUs.

[0009] BSS transitioning is a change of association by a STA from one BSS (managed by a source AP) to another BSS (managed by a target AP). BSS transitioning contributes to device mobility.

[0010] To ease mobility, IEEE Std 802.11-2020 provides mobility domains (MD) and a so-called Fast BSS transition (FT) feature. The mobility domain is a set of BSSs, within the same extended service set (ESS), that support fast BSS transitions between themselves and that are identifiedby the set’s mobility domain identifier (MDID). The set of BSSs and integrated local area networks (LANs) can be interconnected, through a so-called distribution system (DS), to create an extended service set (ESS). The Fast BSS transition (FT) feature seeks to reduce the length of time that connectivity is lost between a STA and the DS during a BSS transition, by reducing the number of management frames that are exchanged. The FT protocols are part of the reassociation service and only apply to STA transitions between APs within the same mobility domain within the same ESS.

[0011] When a STA BSS-transitions to a target AP using the FT feature, the STA reassociates with the target AP with which it exchanges Nonces again to establish another PTKSA including another PTK (hence TK) for communication between them. Indeed, IEEE Std 802.11-2020 requires that a new PTK be used after each new association (including re-association, e.g., transitioning).

[0012] The IEEE 802.11 bn Task Group recently introduced a new 802.11 feature known as “Seamless Roaming” or “Seamless BSS transition”. Seamless BSS transition is a mechanism for a non-AP multi-link device (MLD) to transition from its current AP MLD to a target AP MLD that minimizes the time during which connectivity between the non-AP MLD and the DS is lost. By using this mechanism, the non-AP MLD remains in State 4 of association during the transition while preserving the context for data transmission for a seamless experience. The MD may be named as “seamless mobility domain” (SMD) or “UHR Seamless roaming domain” (USRD) or “Enhanced Mobility Domain” (EMD) or the like.

[0013] By remaining in State 4 (associated and capable to receive or transmit data) during seamless roaming, there is no additional (and costly) 4-Way Handshake or reauthentication (as with the FT request and response) to exchange Nonces and establish a new PTKSA to be used for communication with the target AP MLD.

[0014] To achieve secured “seamless” transitions, contributions to IEEE 802.11 bn propose to share the same PTKSA with the current AP MLD and the target AP MLD within the SMD to use its unique PTK (hence TK) to protect their communications with the non-AP MLD during the roaming process. In particular, for security in seamless roaming, when a non-AP MLD is in the process of roaming from the current AP MLD to a target AP MLD within the SMD, the same PTKSA, established with the SMD Management Entity (SMD-ME), is used to protect communications with the current AP MLD and the target AP MLD

[0015] SUMMARY OF THE DISCLOSURE

[0016] However, sharing the same PTKSA (hence PTK or TK) among all AP MLDs within the SMD has high security risks. Indeed, if the TK comes to be compromised, all of the data frames, individually addressed management frames exchanged between the non-AP MLD and the AP MLDs within the SMD become compromised.

[0017] Attention should be paid to how such sharing of the PTKSA and / or its keys should be made, in particular with respect to the duration of sharing during which the shared PTKSA or keysremains valid, as well as to the extent of the sharing in terms of the number of AP MLDs involved, and to the nature of the shared PTKSA or keys to reduce risks of compromising PTKs outside of the sharing.

[0018] The present disclosure seeks to overcome all or part of the deficiencies of the known techniques.

[0019] In this respect, embodiments regard a communication method in a mobility domain (MD) comprising a plurality of access points (APs), the method comprising, at a non-AP device:

[0020] roaming (or transitioning) from a current AP device to a target AP device within the MD, wherein a first temporal key (TK) derived from a first Pairwise Transient Key Security Association (PTKSA) is used during the process of roaming from the current AP device to the target AP device to protect communications with the current AP device and the target AP device, and a second TK different from the first TK is used before the roaming to protect communications with the current AP device or is used after the roaming to protect communications with the target AP device. Two different keys may be used before and after the roaming, that are different from the first key.

[0021] In this scheme, the non-AP device is initially associated with the current AP device and becomes associated with the target AP device as a result of the roaming. The roaming process or “roaming execution procedure” lasts a period during which the first TK, common to the current and target APs, can be used. Before or after that period, the second TK which is specifically established with the current or target AP (only) can be used, as in a conventional scheme. As a result, the TK sharing amongst multiple APs as recommended by the known techniques is time limited, thereby reducing risks of general key compromission.

[0022] A non-AP device may be a non-AP multi-link device (MLD) in the meaning of IEEE P802.11 be / D7.0, may be a non-AP station (STA) affiliated to a non-AP MLD, or may be a non-MLD non-AP STA (i.e., not belonging to an MLD). Symmetrically, an AP device may be an AP MLD, may be an AP station (AP) affiliated to an AP MLD, or may be a non-MLD AP STA (i.e., not belonging to an MLD). A MAC Address of a MLD is known as a MLD MAC Address.

[0023] The description below mainly focuses on MLDs for ease of explanation. However, the teachings below also apply to non-MLD devices.

[0024] Correspondingly, from AP side, the disclosure proposes a communication method in a mobility domain (MD) comprising a plurality of access points (APs), the method comprising, at a current or target AP device:

[0025] detecting a roaming (or transitioning) of a non-AP device from the current AP device to the target AP device within the MD,

[0026] wherein a first temporal key (TK) derived from a first Pairwise Transient Key Security Association (PTKSA) is used during the process of roaming of the non-AP device from the current AP device to the target AP device to protect communications with the non-AP device.

[0027] For the target AP device, a second TK different from the first TK is used after the roaming to protect communications with the non-AP device.For the current AP device, a second TK different from the first TK is used before the roaming to protect communications with the non-AP device.

[0028] Optional aspects of the disclosure are defined below with reference to methods, while they can be transposed into device features.

[0029] In some embodiments, the first TK is a TK shared between all the AP devices of the MD. This reduces the number of keys to be generated and shared.

[0030] In other embodiments, the first TK is a TK shared between the non-AP device, the current AP device and a set of candidate target AP devices forming a subset of the MD. This scenario provides a good tradeoff between a reduced number of keys to be generated and shared (thanks to the set of multiple AP devices) and security (thanks to the limited number of AP devices in the set compared to the entire SMD).

[0031] In other embodiments, the first TK is a TK shared only between the non-AP device, the current AP device and the target AP device. This provides high level of security with respect to impacts of a key compromission.

[0032] In yet other embodiments, the first TK is provided to the current AP device and the target AP device by a Management Entity of the MD. This provides centralized management of the shared TK.

[0033] In some embodiments where the second TK is used after the roaming to protect communications with the target AP device, the method further comprises, at the non-AP device, obtaining a third TK to protect communications with the current AP device before the roaming, wherein the first TK is different from the third TK. This provides high level of security with respect to impacts of a key compromission, since the target AP device will not be aware nor use the TK (or PTK) already used by the current AP device.

[0034] In alternative embodiments where the second TK is used after the roaming to protect communications with the target AP device, the method further comprises, at the non-AP device, obtaining a third TK to protect communications with the current AP device before the roaming, wherein the first TK is the third TK. This simplifies operations at the devices, in particular because no additional TK (and PTK) has to be generated and also because the non-AP device has to perform a key switch only once (from the first TK to the second TK).

[0035] In some embodiments where the second TK is used before the roaming to protect communications with the current AP device, the method further comprises, at the non-AP device, obtaining a third TK to protect communications with the target AP device after the roaming, wherein the first TK is different from the third TK.

[0036] In alternative embodiments where the second TK is used before the roaming to protect communications with the current AP device, the first TK is also used after the roaming to protect communications with the target AP device.

[0037] The third TK may be derived from the first PTKSA in case a single PTKSA is shared over the MD, whereas, in other embodiments where a new PTKSA is established at each roaming, the third TK may be derived from another PTKSA different from the first PTKSA.In some embodiments, the method further comprises, at the non-AP device, obtaining a fourth TK shared with a group, possibly all, of the AP devices of the MD, wherein:

[0038] if a fifth TK shared with the current AP device and the target AP device is obtained when preparing the roaming, the first TK is the fifth TK,

[0039] otherwise, the first TK is the fourth TK.

[0040] In other words, the fourth TK can be used as a default TK for communication protection during the process of any roaming within the MD, while the fifth TK specifically dedicated to the on-going roaming can take priority over the default TK for the on-going roaming when the fifth TK is declared. This hybrid scheme tends to increase security when possible because the fifth TK is less shared than the fourth TK and its validity can advantageously be restricted overtime.

[0041] The fourth (resp. fifth) TK may be derived from the first PTKSA in case a single PTKSA is shared over the MD, whereas, in other embodiments where a new PTKSA is established at each roaming, the fourth (resp. fifth) TK may be derived from another PTKSA different from the first PTKSA.

[0042] In some embodiments, the first TK is shared with the current AP device and the target AP device (and possibly other target AP candidates of the MD, or all the AP devices of the MD) upon the non-AP device initially associating with the MD. It is meant by “initially associating” the first association of the non-AP device with an AP MLD of the MD during a current MD session. An MD session usually ends when the non-AP device is no longer associated with an AP MLD of the MD (e.g., after mobility domain disassociation). This scenario advantageously reduces the number of key generation and of key sharing messages. It means that the devices may reuse the same first TK to protect their communications at each new roaming procedure during the current MD session.

[0043] In other embodiments, the first TK is shared with the current AP device and the target AP device during a roaming preparation procedure. This allows a TK dedicated to a given roaming to be generated, hence increasing network security with respect to impacts of a key compromission.

[0044] In specific embodiments, the first TK is included in a context transferred by the current AP device to the target AP device during the roaming preparation procedure.

[0045] In some embodiments, parameters (e.g., Nonces, Ephemeral public keys) to generate the first TK (in particular the PTK from which the first TK is extracted or derived) are included in a context transferred by the current AP device to the target AP device during the roaming preparation procedure, so that the target AP generates the first TK by its own. The keys are therefore not directly exchanged, increasing network security.

[0046] In some embodiments, the second TK is derived from the first PTKSA. This means that the same PTKSA may be kept over time (e.g., as long as the MD session is active), from which multiple TKs can be derived as BSS transitions are performed. As mentioned above, the third, fourth and fifth TKs may also be derived from the first PTKSA.In particular embodiments, the first PTKSA includes a single PTK and the first and second TKs (possibly also the third, fourth and fifth TKs) are derived (e.g., subparts) from the PTK.

[0047] In other particular embodiments, the first PTKSA includes at least two PTKs and the first and second TKs (possibly also the third, fourth and fifth TKs) are derived (e.g., subparts) from respective PTKs.

[0048] In other embodiments, the second TK is derived from a second PTKSA different from the first PTKSA. A more conventional scheme is adopted here where a new PTKSA is negotiated with the target AP MLD at the new roaming.

[0049] In particular embodiments, the first PTKSA includes a single PTK and the first TK is derived (e.g., as a subpart thereof) from the PTK to protect communications with the current AP device and the target AP device.

[0050] In some embodiments, the process of roaming ends a timeout after a Roaming execution response frame sent by the target AP device. The devices (non-AP MLD and target AP MLD) switch from the shared (first) PTKSA (and corresponding key or keys) to the second PTKSA at that time, hence stopping the period where communications with both the current and target AP MLDs are possible. Other trigger events to signal the end of the roaming process can be contemplated, e.g., receiving the above Roaming execution response.

[0051] In specific embodiments, the timeout is indicated in the Roaming execution response frame.

[0052] In some embodiments, a frame exchanged by the non-AP device includes a field in a Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CCMP) or Galois / Counter Mode (GCM) protocol (GCMP) header, which field signals which key is used to protect the frame, from amongst the first TK and the second TK.

[0053] Correspondingly a frame exchanged by the current or target AP device with the non-AP device may include a field in a Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CCMP) or Galois / Counter Mode (GCM) protocol (GCMP) header, which field signals which key is used to protect the frame, from amongst the first TK and the second TK.

[0054] In some embodiments, the current AP device has a current packet number (PN) associated with the first PTKSA to perform replay detection of frames encrypted using the first TK and exchanged with the non-AP device, wherein the current AP device shares the current PN or the current PN increased by an incremental value to the target AP device for the latter to perform replay detection of frames encrypted using the first TK and exchanged with the non-AP device. This may apply to a DL (downlink) PN and to an UL (uplink) PN.

[0055] In some embodiments, the target AP device increases the received current PN by an incremental value to perform the replay detection of frames.

[0056] As apparent from the above, the incremental value may be predefined at the devices, in which case the target AP device may itself increment the received PN. Or the incremental valuemay be provided by the current AP device (e.g., dynamically chosen by the current AP device) either as a separate value to the current PN or already added to the current PN.

[0057] Another aspect of the disclosure regards a communication method in a communication device, comprising:

[0058] establishing a Pairwise Transient Key Security Association (PTKSA),

[0059] deriving a first key (e.g., a PTK or a TK) from the PTKSA to protect communications with a first device, and

[0060] deriving a second key (e.g., a PTK or a TK) from the PTKSA to protect communications with a second device.

[0061] As mentioned above, one and the same PTKSA can be used to derive multiple keys, which is advantageous to simplify processing. Such one-PTKSA-based multiple key derivations may take place within a Mobility Domain or independently thereto (i.e., in any wireless station). The first and second devices may be non-AP or AP MLDs. The PTKSA may include one or more PTKs from which one or more TKs can be obtained. The multiple key derivations may be based for example on an identifier of the MD, or on identifiers of the AP MLDs.

[0062] Correlatively, the disclosure also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above. The disclosure also provides a mobility domain system made of such devices.

[0063] Another aspect of the disclosure relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above.

[0064] 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.

[0065] 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.

[0066] BRIEF DESCRIPTION OF THE DRAWINGS

[0067] 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 exemplary network environment in which embodiments of the present disclosure can be implemented;

[0068] Figure 2A schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition after an initial SMD association (ISMDA) of a non-AP MLD with a first AP MLD, according to some embodiments;

[0069] Figure 2B schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition after an initial SMD association (ISMDA) of a non-AP MLD with a first AP MLD, according to other embodiments;

[0070] Figure 2C schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition after an initial SMD association (ISMDA) of a non-AP MLD with a first AP MLD, according to some hybrid embodiments;

[0071] Figure 2D schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition after an initial SMD association (ISMDA) of a non-AP MLD with a first AP MLD, according to some embodiments with a single PTKSA between the non-AP MLD and the SMD;

[0072] Figure 3 schematically illustrates, through a sequence of messages, three phases splitting a seamless roaming or BSS transition divided, according to some embodiments;

[0073] Figure 4A illustrates, using a flowchart, general steps at an MLD to manage TKs for its transmissions, according to some embodiments;

[0074] Figure 4B illustrates, using a flowchart, general steps at a transmitting MLD to conduct MPDU transmission, according to some embodiments;

[0075] Figure 4B illustrates, using a flowchart, general steps at a receiving MLD to conduct MPDU reception, according to some embodiments;

[0076] Figure 5A shows a schematic representation of a wireless communication device in accordance with embodiments of the present disclosure; and

[0077] Figure 5B illustrates schematically the architecture of the communication device of Figure 5A.

[0078] DETAILLED DESCRIPTION OF EMBODIMENTS A STA initially associates with a seamless mobility domain SMD. A PTK or TK is defined with the first AP to which it associates, to protect communications with that AP only. A by-default SR-PTK or SR-TK is also defined upon initially associating with the SMD, which by-default SR-PTK / TK is shared amongst the APs of the SMD. A roaming from a current AP to a target AP is prepared, during which a roaming-dedicated SR-PTK / TK can be defined and shared with the current and target APs. The STA also defines a PTK / TK with the target AP. If a roaming-dedicated SR-PTK / TK is obtained, the STA uses it as SR-PTK / TK to protect communications with both the current and target APs during the process of roaming. Otherwise, the by-default SR-PTK / TK is used for communication protection. After the roaming process ends, the STA uses the PTK / TK defined with the target AP to protect communications with the target AP only.The WLAN (Wireless Local Area Network) technology based on the IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 family standards provides a very simple distributed channel access mechanism. Distributed channel access means that a wireless device, in IEEE 802.11 terminology known as a station (STA), either access point (AP) or a non-access point (non-AP), tries to access an operating channel when it has data to send, usually using contention schemes on a so-called primary channel.

[0079] In such wireless networks, the AP that manages the set of wireless non-AP stations (registered to it or associated with it) that together organize their access to the wireless medium for communication purposes. The STAs (including the AP to which they register) form a service set, also referred to as basic service set, BSS (although other terminology can be used).

[0080] Often, the AP interfaces the non-AP stations to other networks, such as the Internet, e.g. through wired networks. For example, the AP operates as an IP router of IP traffic.

[0081] An AP 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.

[0082] A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a non-AP STA 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 smart phone), 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, the non-AP station may be a wireless node. Such 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.

[0083] IEEE P802.11 be / D7.0 introduces the Multi-Link Operation (MLO) when it comes to MAC layer operation. The MLO allows multi-link devices to establish or setup multiple links and operate them simultaneously. A Multi-Link Device (MLD) is a logical entity and has more than one affiliated STA (STA) and has a single MAC service access point (SAP) to logical link control (LLC), which includes one MAC data service. Multiple affiliated non-AP STAs of a non-AP MLD can then setup communication links with multiple affiliated APs of an AP MLD, hence forming a multi-link channel. A communication link or “link” thus corresponds to a given channel (e.g., 20 MHz, 40 MHz, andso on) in a given frequency band (e.g., 2.4 GHz, 5 GHz, 6 GHz) between an AP affiliated with the AP MLD and a non-AP STA affiliated with the non-AP MLD.

[0084] In this context, the term “non-AP STA” or “non-AP station” or “non-AP device” may also refer to one affiliated STA of a non-AP MLD (non-AP STAs of a non-AP MLD) or even to a non-AP MLD, and “AP” or “AP device” may also refer to one affiliated AP of an AP MLD or an AP MLD itself. An “MLD” may be a non-AP MLD or an AP MLD.

[0085] Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented.

[0086] The illustrated wireless network environment comprises a group of Basic Service Sets (BSS) that form a seamless mobility domain (SMD). A SMD is a set of AP MLDs implementing a seamless roaming mechanism allowing a non-AP STA to roam from an AP MLD to another AP MLD while remaining in State 4, which state corresponds to a state where the non-AP STA is associated and capable to receive or transmit data.

[0087] The seamless mobility domain SMD may be identical to an Extended Service Set or a Mobility Domain as specified in IEEE Std 802.11-2020 or may be different (i.e., the seamless mobility domain can consist in multiple ESSs / Mobility Domains or an ESS / Mobility Domain may include multiple seamless mobility domains). One AP MLD may belong to one or more SMDs. Each BSS typically operates on a different wireless channel from the other BSSs, to avoid interfering one each other. In variants, it can also operate on the same wireless channel as one or more other BSSs.

[0088] An SMD can be identified from amongst multiple SMDs, using an identifier (e.g., SMDID). It may be a number, a MAC address (e.g., SMD MAC Address) or any bitstring. The identifier is preferably unique.

[0089] The depicted SMD 100 consists of four BSSs. A first wireless network (or Basic Service Set) BSS1 comprises an AP MLD 111 also referred to as AP MLD1 and non-AP MLD 101 also referred to as STA1 associated with AP MLD1 (i.e., registered to it). Second, third and fourth wireless network BSS2, BSS3 and BSS4 comprise respectively AP MLD 112, AP MLD 113 and AP MLD 114, also referred to, respectively, AP MLD2, AP MLD3 and AP MLD4. More than one non-AP MLD can be provided in the SMD and can be registered to any AP MLD of the SMD. Also, STA1 may be a mere non-AP station not equipping an MLD.

[0090] Inside the SMD 100, it is assumed that the AP MLDs have inter-connections (the interconnect structure is known as Distribution System or DS) between them to exchange messages and e.g., cryptographic keys without exposure to any intermediate parties. In particular, the cryptographic strength of the secure channel of the DS between AP MLDs is greater than or equal to the cryptographic strength of the wireless channels (BSS channels) for which the keys are used. However, inter-connections over the air between AP MLDs may also be envisioned.

[0091] In a seamless roaming (SR) mechanism or seamless BSS transition mechanism, the non-AP MLD initiates an association procedure with one of the AP MLDs of the seamless mobility domain during an initial seamless mobility domain association (ISMDA) procedure. The AP MLDto which the initial seamless mobility domain association (ISMDA) is made can be referred to as “first AP MLD” or “initial AP MLD” because it is the first AP MLD of the SMD that the non-AP MLD is associated with. The first AP MLD can either be called as “current AP MLD” when the non-AP MLD is associated with the AP MLD. The initial association starts a “SMD session” or “SMD association” that lasts as long as the non-AP MLD remains associated with at least one of the AP MLD of the SMD.

[0092] The roaming or BSS transition means that after the non-AP MLD initially associates with the first AP MLD, it can transition from the first AP MLD to any other (called “target”) AP MLD of the SMD. Multiple transitions can be cascaded during the same SMD session. The “seamless” BSS transition means that the transitioning to the target AP MLD is made without performing again an association procedure, but using a specific switching procedure allowing data loss reduction or / and service interruption compared to a disassociation / association procedures. The seamless BSS transition seeks to reduce the length of time that connectivity is lost between a non-AP MLD and the DS during a BSS transition and also to avoid data lost during this transition. In other words, the seamless BSS transition aims to ensure service continuity.

[0093] In the scenario of Figure 1, AP MLD1 111 is the first AP MLD to which STA1 101 initially associates. After this initial association, STA1 101 discovers that one of the other AP MLDs (AP MLD2, AP MLD3 or AP MLD4) of the SMD 100 provides better connection. In such a case, STA1 decides to perform a seamless BSS transition procedure to switch its association from AP MLD1 to one other AP MLD of the SMD.

[0094] Inside the SMD, PMKSA (pairwise master key security association) and PTKSA (pairwise transient key security association) are shared. More precisely, when a non-AP MLD is in the process of roaming from the current AP MLD to a target AP MLD within the SMD, the same PMKSA / PTKSA, for example established with a SMD Management Entity (SMD-ME), is used to protect communications with the current AP MLD and the target AP MLD. The “current” AP MLD is the AP MLD that the non-AP MLD is associated with before the roaming and the “target” AP MLD is the AP MLD that the non-AP MLD is targeting as the roaming target. There may be one or more target AP MLDs.

[0095] The PTKSA is the context resulting from a successful 4-way handshake, FT 4-way handshake, FT authentication sequence, FILS authentication, PASN authentication, or EDPKE authentication between the non-AP MLD and an AP MLD.

[0096] In embodiments, the shared PTKSA includes the following:

[0097] - a pairwise transient key (PTK) which is a concatenation of session keys derived from the pairwise master key (PMK) or from the PMK R1 , including a temporal key (TK) that is used to protect information exchanged in individually addressed frames.

[0098] - Pairwise cipher suite selector

[0099] - Supplicant MAC address

[0100] - Authenticator MAC address- Key ID, identifying the PTK

[0101] - If FT key hierarchy is used, R1KH-ID, S1KH-ID and PTKName

[0102] The PTKSA therefore includes the cryptographic key TK to be used to encrypt unicast messages - i.e., Plaintext MPDUs - exchanged between the non-AP MLD and the AP MLD inside the SMD. A cryptographic encapsulation process is usually applied to the Plaintext MPDU to obtain the encrypted MPDU to transmit. The cryptographic encapsulation often includes constructing additional authentication data (AAD) from the fields in the MPDU header, constructing a nonce, and using the temporal key TK, the AAD, the nonce, and the MPDU data to form the cipher text and the encrypted MIC from the MPDU. The encrypted MPDU is formed by combining the original MPDU header, a so-called CCMP of GCMP header, the encrypted data and the encrypted MIC. CCMP / GCMP Header includes Key ID field which includes the Key ID value to indicate which temporal key TK is used to encrypt the MPDU.

[0103] For security in seamless roaming, when a non-AP MLD is in the process of roaming from the current AP MLD to a target AP MLD within the SMD, the same PTKSA, established with the SMD-ME, is used to protect communications with the current AP MLD and the target AP MLD. In these embodiments, the PTKSA includes a single PTK and a single TK is derived (as a subpart thereof) from the PTK to protect communications with the current AP device and the target AP device. The same PTK / TK is used by both AP MLDs to communicate with the same non-AP MLD during the process where the non-AP MLD roams between the two AP MLDs.

[0104] To mitigate the security risk, embodiments provide that such TK derived from the PTKSA shared with the two AP MLDs is used by the non-AP MLD (and the two AP MLDs) during the process of roaming from the current AP MLD to the target AP MLD to protect communications with both the current AP MLD and the target AP MLD, and that one or more other TKs different from the above shared TK are used before the roaming to protect communications with the current AP device and / or used after the roaming to protect communications with the target AP MLD. This other TK or TKs are preferably the TK or TKs of a conventional new PTKSA established between the non-AP MLD and the current and / or target AP MLD upon roaming.

[0105] The PTKSA shared with both AP MLDs is named SR-PTKSA (Seamless Roaming-PTKSA) or “roaming” PTKSA in this disclosure. Similarly, the PTK inside the SR-PTKSA can be named SR-PTK or “roaming” PTK, and the TK extracted from the SR-PTK can be named SR-TK or “roaming” TK.

[0106] In these embodiments, the use of the (shared) SR-TK is time limited, thereby reducing risks of general key compromission. Indeed, if the SR-TK is compromised, the compromised communication is limited to the communication that happens during the limited time of the roaming procedure.

[0107] In embodiments, the time limited sharing of the SR-TK may result from a time limited sharing of the corresponding SR-PTK, or even of a time limited sharing of the SR-PTKSA. In particular, the TK to protect communications between the non-AP MLD and the target AP MLD(only) can be derived from another PTKSA than the one used to derive the SR-TK used during the roaming period.

[0108] However, in some embodiments, the shared PTKSA (SR-PTKSA) can be extended to have multiple PTKs (which includes a single TK or from which multiple TKs can be derived). In that case where the SR-PTKSA includes at least two PTKs, the SR-TK can be derived from one PTK to protect communications with the current AP MLD and with the target AP MLD (during the roaming period), and any subsequent TK can be derived from the other PTK to protect communications with the target AP MLD (only) (after the roaming period). There is no longer a need to have a time limited sharing of the SR-PTKSA, because multiple TKs can be generated from the same PTKSA.

[0109] In other embodiments, multiple TKs can be derived from a single PTK. In such a case where the SR-PTKSA includes a single PTK, the SR-TK can be derived from the PTK to protect communications with the current AP MLD and with the target AP MLD, and another and different TK can be derived from the same PTK to protect communications with the target AP MLD (only).

[0110] In these embodiments, the TK to protect communications between the non-AP MLD and the target AP MLD (only) is derived from the same PTKSA as the SR-TK used during the roaming period. Conventional TKs used to protect communications between the non-AP MLD and the current AP MLD, between the non-AP MLD and the target AP MLD, and the TK shared between the non-AP MLD and both of the current AP MLD and the target AP MLD can be all included in (or be derived from) a single and same shared PTKSA. The TK derivation can be done in any way. Examples of TK derivations from the same PTK are described in the later part of this disclosure.

[0111] Figure 2A schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition after an initial SMD association (ISMDA) of a non-AP MLD with a first AP MLD.

[0112] Seamless Roaming (SR) firstly requires information to be exchanged during an initial association (or a later switching / roaming) between a non-AP MLD (also known as SR Originator (SRO)) and an AP MLD (also known as Responder (SRR)). The initial exchange is referred to as the Initial Seamless Mobility Domain Association (ISMDA) 210. Subsequent reassociations to AP MLDs within the same SMD may then make use of the SR protocols.

[0113] During ISMDA 210, the non-AP MLD such as STA1 101 firstly initiates an authentication / association procedure with one of the AP MLDs of the SMD referred to as first AP MLD or SRR 111.

[0114] Upon or after the successful association, the PTKSA [AP MLD1] is established between STA1 and AP MLD1 as shown in 220. PTKSA [AP MLD1] is a context resulting from the successful 4-way handshake between STA1 and AP MLD1 . It is specific to a single AP MLD, here AP MLD1. This PTKSA [AP MLD1] establishment 220 can be done by any means for example using the FT protocol (i.e. , the PTK for the PTKSA - namely PTK [AP MLD1] - is derived from PMK-R1 , which is derived from PMK-R0) or without the FT protocol (i.e., PTK [AP MLD1] isderived from PMK). PTK [AP MLD1] or TK [AP MLD1] included in the PTKSA [AP MLD1] is used to protect the communication between STA1 and AP MLD1 before any roaming procedure to transition from AP MLD1. They can be named “pre-roaming” PTK, “pre-roaming” TK, “preroaming” PTKSA.

[0115] In addition to the PTKSA [AP MLD1] establishment 220, another PTKSA can be established as illustrated through reference 222. This other PTKSA is named PTKSA [SMD] because it is a PTKSA shared between STA1 and multiple AP MLDs of the SMD. PTKSA [SMD] includes SR-TK (extracted from SR-PTK included in the PTKSA) that is to be shared with the AP MLDs to protect the communication between STA1 and AP MLD1 and target AP MLD2 (or another target AP MLD) during the roaming procedure, in particular to be shared between STA1 , current AP MLD (i.e. , AP MLD1) and one or more target AP MLDs (e.g., AP MLD2).

[0116] PTKSA [SMD] establishment A 222 can be accomplished by any means. For example, a PMK can be either generated by the SMD-ME (Management Entity) 201 or by the first AP MLD and shared within the SMD (i.e., to the other AP MLDs of the SMD). Once the PTKSA [SMD] has been shared with multiple AP MLDs, STA1 and the AP MLDs are ready for the roaming and STA1 may enter the Roaming execution procedure 240. PTKSA [AP MLD1] establishment 220 and PTKSA [SMD] establishment A 222 can be done in any order (PTKSA [SMD] establishment A 222 can be earlier than PTKSA [AP MLD1] establishment 220).

[0117] Roaming preparation procedure 230 may be optionally introduced to transfer context information related to STA1 between the current (source) AP MLD (AP MLD1) and the target AP MLD (AP MLD2), to set up the links between STA1 and AP MLD2 and so on. Roaming preparation procedure may be triggered by a frame sent from STA1 to the current AP MLD (AP MLD1) such as Roaming preparation request 232. Roaming preparation response 234 can be sent from AP MLD1 to respond to the request. Roaming preparation request / response frame can be any existing management frame with necessary extensions in the IEEE 802.11 specifications (e.g. Link Reconfiguration Request / Response frames) or a new management frame introduced in the IEEE802.11 bn amendment. Although the roaming preparation request / response frames are exchanged with AP MLD1 in the Figure, they may be exchanged with the target AP MLD (AP MLD2) in variants.

[0118] In the Roaming preparation request frame 232, STA1 may indicate which target AP MLD(s) to prepare the roaming with (e.g., AP MLD2 in the Figure). In the other embodiment, STA1 may not specify the target AP MLD, however the SMD side (including the SMD-ME and / or one or more AP MLDs) may specify one or more target AP MLDs as candidates. In this way, one or more target AP MLDs are specified to prepare the roaming with. With this, AP MLD1 can identify which AP MLDs to transfer the context and / or setup the link as done in 236. This information may be also used to select which target AP MLD(s) to perform PTKSA establishment. The context transfer and the link setup may be also triggered by the Roaming execution request frame 242 as shown in 238. Additional context can be transferred in 238 and additional links can be setup in 238. Thiscan be implemented when the Roaming execution procedure 240 is performed without the Roaming Preparation procedure 230.

[0119] In Figure 2A, PTKSA [AP MLD2] establishment 224 is performed with the Roaming Preparation procedure 230 and a PTKSA between STA1 and AP MLD2 is established. The context information may include information (e.g. the PTK itself, parameters to generate the PTK) used to establish the PTKSA for PTKSA establishment 224. The PTK or TK included in the PTKSA [AP MLD2], namely PTK [AP MLD2] or TK [AP MLD2], is used to protect the communication between STA1 and AP MLD2 after the roaming procedure to transition to AP MLD2. The PTKSA, PTK and TK can therefore be named “post-roaming” PTKSA, “post-roaming” PTK, “post-roaming” TK.

[0120] Roaming execution request frame 242 initiates the Roaming execution procedure 240. Roaming execution is sent from STA1 to the current AP MLD (AP MLD1) or to the target AP MLD (AP MLD2). Roaming execution request frame 242 may include context information such as information relevant to the PTKSA establishment 224 (and / or PTKSA establishment 226 as introduced below). Roaming execution response frame 244 may be sent back to STAI . STA1 is allowed to send UL frames 214 to the target AP MLD (AP MLD2) after receiving the Roaming execution response frame 244. The current AP MLD is allowed to send DL frames 219 during a specific time period 260 after the Roaming execution response frame 244. The time period 260 may be a timeout specified in the Roaming execution response frame 244.

[0121] Roaming execution request / response frame can be any existing management frame with necessary extensions in the IEEE 802.11 specifications (e.g. Link Reconfiguration Request / Response frames) or a new management frame introduced in the IEEE802.11bn amendment. The roaming execution request / response frames are exchanged with AP MLD1 or with AP MLD2 as shown in the Figure.

[0122] Near around the roaming phase (e.g., during the Roaming execution procedure 240, after the Roaming execution request frame 242 after the Roaming execution response frame 244; or before the Roaming execution request frame 242), STA1 may exchange frames with either AP MLD1 or AP MLD2 including UL (uplink) frames (from STA1 to one or two of the AP MLDs) or DL (downlink) frames (from one or two of the AP MLDs to STA1) or both as shown in 212, 214, 216, 218 and 219.

[0123] The roaming SR-TK (or more generally SR-PTK) obtained during PTKSA [SMD] establishment A 222 is used to encrypt these exchanges near around the roaming phase. As an example, the SR-TK is used to protect the communications with the current and target AP devices from the Roaming execution request frame 242 to the end of the specific time period (timeout) 260. Beforehand, no communication is allowed with the target AP MLD, and only the pre-roaming TK [AP MLD1] can be used to protect communications with the current AP MLD. After the roaming, communications are no longer authorized with the current AP MLD, and only the postroaming TK [AP MLD2] (or more generally PTK) can be used to protect communications with the target AP MLD.The three phases (pre-roaming, roaming and post-roaming) are illustrated in Figure 3.

[0124] In the embodiments of Figure 2A, the SR-TK is shared with the current AP MLD and the target AP MLD (and possibly other target AP MLDs) upon the non-AP MLD initially associating with the SMD.

[0125] Different scopes of sharing the roaming SR-TK (or SR-PTK) inside the SMD can be contemplated, defining different “types” of SR-TK (or SR-PTK). Below it is mainly made reference to the shared TK SR-TK, although the same applies to the corresponding shared PTK SR-PTK.

[0126] In first embodiments, the SR-TK is shared between a large group of AP MLDs of the SMD, preferably between all the AP MLDs of the SMD. This is “Type 1” SR-TK.

[0127] Type 1 SR-TK is a unique key for the SMD (“per-SMD” key) so it is easy to share (i.e. , only one key is to be shared) even without knowing the candidates of target AP MLD. Indeed, all the AP MLDs can receive the Type 1 SR-TK after the initial association 210 and before any roaming preparation procedure 230, typically during the PTSKA [SMD] establishment A 222.

[0128] The Type 1 SR-TK can be obtained from SR-PTK derived from the shared PMK in each AP MLD of the SMD, or generated by the SMD-ME and then shared to the AP MLDs within the SMD, which means the Type 1 SR-TK may be provided to the current AP MLD and the target AP MLD by the Management Entity of the SMD. STA1 may generate the PMK, and the Type 1 SR-TK by itself.

[0129] For security reasons, the Type 1 SR-TK can be chosen different from the pre-roaming TK, i.e., TK [AP MLD1]. In other words, the non-AP MLD obtains a pre-roaming TK to protect communications with the current AP MLD before the roaming, and the Type 1 SR-TK is different from the pre-roaming TK.

[0130] For security reasons too, the Type 1 SR-TK can be chosen different from the postroaming TK, i.e., TK [AP MLD2]. In other words, the non-AP MLD obtains a post-roaming TK to protect communications with the target AP MLD after the roaming, and the Type 1 SR-TK is different from the post-roaming TK.

[0131] Type 2 SR-TK is a key dedicated to a pair of AP MLDs such as the current AP MLD and any target AP pair (“Per-AP pair” key). Compared to Type 1 SR-TK, Type 2 SR-TK increases security since the sharing scope of the SR-TK is limited to only two APs. In other words, each Type 2 SR-TK is shared only between the non-AP MLD and the corresponding current and target AP MLDs. Note that the role of the current and target AP MLDs may be symmetrical so that the same Type 2 SR-TK is used when two AP MLDs invert their roles (e.g., after multiple roaming of the non-AP MLD).

[0132] A Type 2 SR-TK is to be built and shared for each pair of AP MLDs. The Type 2 SR-TKs can be obtained from SR-PTK derived from the shared PMK in each AP MLD of the SMD, given the non-AP MLD and the other AP MLDs of the SMD, or generated by the SMD-ME and then shared to the AP MLDs within the SMD, which means the Type 2 SR-TK may be provided to the current AP MLD and the target AP MLD by the Management Entity of the SMD. STA1 may generate the PMK, and the Type 2 SR-TKs by itself.For security reasons, the Type 2 SR-TK can be chosen different from the pre-roaming TK, i.e., TK [AP MLD1]. In other words, the non-AP MLD obtains a pre-roaming TK to protect communications with the current AP MLD before the roaming, and the Type 2 SR-TK is different from the pre-roaming TK.

[0133] For security reasons too, the Type 2 SR-TK can be chosen different from the postroaming TK, i.e., TK [AP MLD2]. In other words, the non-AP MLD obtains a post-roaming TK to protect communications with the target AP MLD after the roaming, and the Type 2 SR-TK is different from the post-roaming TK.

[0134] Type 3 (Per-CAP or Per TAP) SR-TK is a key specific to one of the current and target AP MLD (“Per CAP” key or “Per TAP” key) and shared with one or more current or target AP MLDs. In particular, the Type 3 SR-TK is shared between the non-AP MLD, the current AP MLD and a set of candidate target AP MLDs forming a subset of the SMD.

[0135] Type 3 SR-TK can reuse the pre-roaming TK as SR-TK. In other words, the non-AP MLD obtains a pre-roaming TK (TK [AP MLD1]) to protect communications with the current AP MLD before the roaming, and the Type 3 SR-TK is the pre-roaming TK. This avoids generating an additional key and avoids the non-AP MLD to have to switch between keys upon roaming. The current AP MLD may share the (pre-roaming) TK with the target AP MLD (and other AP MLDs) during the PTSKA [SMD] establishment A 222.

[0136] Type 3 SR-TK can use the next post-roaming TK as SR-TK. In other words, the non-AP MLD also uses the Type 3 SR-TK after the roaming to protect communications with the target AP device, i.e., uses it as post-roaming TK (TK [AP MLD2]). This avoids generating an additional key and avoids the non-AP MLD to have to switch between keys upon roaming. The target AP MLD may share the (post-roaming) TK with the current AP MLD (and other AP MLDs) during the PTSKA [SMD] establishment A 222 or during the Roaming Preparation procedure (e.g. context transfer from the target AP MLD to the current AP MLD - not shown in the Figure).

[0137] As mentioned above, Type 2 and / or Type 3 SR-TK can be shared during the PTKSA [SMD] establishment A 222. However, given the increased number of Type 2 or Type 3 key exchanges as well as the number of SR-TKs to be locally stored at each device, it is more practical to share the Type 2 or Type 3 SR-TK (given a known current AP MLD and for one or more known specific target AP MLDs) in a later procedure, typically when the roaming preparation procedure is performed. Indeed, in that case, one can limit the number of Type 2 or Type 3 SR-TKs to be built and stored.

[0138] In other words, instead of sharing the SR-TK upon initially associating with the SMD, the SR-TK is shared with the current AP MLD and the target AP MLD during the roaming preparation procedure 230.

[0139] This is now described with reference to Figure 2B where the same references as in Figure 2A correspond to the same steps and descriptions.

[0140] PTKSA [SMD] establishment A 222 is omitted. Instead, PTKSA [SMD] establishment B 226 is performed during the roaming preparation procedure 230, together with PTKSA [AP MLD2]establishment 224. The PTKSA [SMD] is similar as the one described above with respect to PTKSA [SMD] establishment A 222.

[0141] Since the target AP MLDs have been specified in the Roaming preparation procedure 230, Type 2 SR-TK can be generated and shared for the specific target AP MLD or MLDs. Type 3 SR-TK can be shared for the specific target AP MLD as well. The TK included in the PTKSA [SMD] is the SR-TK and it is used to protect the communications between STA1 and AP MLD1 and AP MLD2 (or another target AP MLD) during the roaming procedure as described above.

[0142] PTKSA [SMD] establishment B 226 can be accomplished by any means. For example, a PMK can be either generated by the SMD-ME (Management Entity) 201 or by the AP MLD1 and shared within the SMD (i.e., to the other AP MLDs of the SMD). Context transfer 236 may include the generated SR-TK to share the SR-TK between AP MLD1 and AP MLD2. Or AP MLD1 may share the generated SR-TK to the SMD-ME 201 and the SMD-ME 201 may distribute the shared TK to one or more target AP MLDs (e.g., AP MLD2). STA1 may generate the PMK, SR-PTK and then SR-TK by itself.

[0143] PTKSA [AP MLD2] establishment 224 and PTKSA [SMD] establishment B 226 can be done in any order (PTKSA [SMD] establishment B 226 can be earlier than PTKSA [AP MLD1] establishment 224). If the Roaming preparation procedure 230 is skipped, PTKSA [AP MLD2] establishment 224 and PTKSA [SMD] establishment B 226 can be done as part of the Roaming execution procedure 240. In this case, information included in the Roaming execution request 242 may be used to specify the target AP MLD to establish the PTKSAs with.

[0144] In the scenarios of Figures 2A and 2B, a single one of the various types of SR-TK is used.

[0145] In other embodiments, two or more types of the SR-TK can be used in a hybrid manner. It can be beneficial to use Type 1 and Type 2 (or Type 3) SR-TKs in some scenarios. For example, Type 1 SR-TK can be used as a by-default key to be ready for the roaming without any roaming preparation procedure (i.e., ready for the roaming after the initial association). Once the roaming preparation procedure is done for a specific target AP MLD, Type 2 (or Type 3) SR-TK provided during this preparation procedure can be used. This is advantageous since the key sharing scope is limited to two AP MLDs for the Type 2 SR-TK or to the numbers of target AP MLDs for which roaming preparation procedure is performed for the Type 3 SR-TK, so that it mitigates the security risk.

[0146] This is illustrated in Figure 2C where the same references as in Figures 2A and 2B correspond to the same steps and descriptions. The non-AP MLD obtains a by-default Type 1 SR-TK shared with a group, possibly all, of the AP MLDs of the MD, and if a Type 2 or Type 3 SR-TK shared with the current AP MLD and the target AP MLD is obtained when preparing the roaming (e.g., during the Roaming preparation procedure 230), the SR-TK to be used is the Type 2 or Type 3 SR-TK; otherwise, the SR-TK to be used is the by-default Type 1 SR-TK.

[0147] As shown in Figure 2C, the PTKSA [SMD] establishment A 222 to share the by-default Type 1 SR-TK with multiple AP MLDs of the SMD and the PTKSA [SMD] establishment B 226 toshare the Type 2 or Type 3 SR-TK with a reduced number of AP MLDs (typically the current and (candidate) target AP MLDs only) are performed within the same scenario. The PTKSA [SMD] establishment A 222 is performed once, upon initial association 210, whereas the PTKSA [SMD] establishment B 226 is performed each time a new roaming is prepared.

[0148] Figures 2A to 2C have been described above where a new PTKSA is established at each new roaming. It means that the SR-TK is derived from the SR-PTKSA whereas the TK for use to protect communications with the target AP MLD after the roaming ends is derived from another PTKSA different from the SR-PTKSA.

[0149] To ease management, it may be contemplated having the TK for use to protect communications with the target AP MLD after the roaming ends be derived from the same SR-PTKSA as the SR-TK. This is possible as long as multiple TKs can be derived from the same PTKSA.

[0150] In preferred embodiments, a single PTKSA is established when the non-AP MLD initially associates with the SMD, which single PTKSA (hence shared with all the AP MLDs of the SMD) serves as a basis for multiple TK generations. For example, the above pre-roaming TK (TK [AP MLD1]), roaming TK, post-roaming TK (TK [AP MLD2]) can be derived from the same shared PTKSA. Additional PTKSA establishments are avoided.

[0151] In embodiments, one (single) PTK can be included in the single shared PTKSA and the multiple TKs can be derived from the unique PTK. Alternatively, multiple PTKs can be included in the single shared PTKSA and each TK may derive from a respective one of the multiple PTKs. More alternatively, when multiple PTKs populate the single shared PTKSA, each PTK may be used to derive multiple TKs.

[0152] When multiple PTKs are included in the single shared PTKSA, the PTKs can be derived from the same PMK (which is shared among the SMD) using the AA (Authenticator Address), SPA (Supplicant Address), ANonce / SNonce and / or DHss (Diffie-Hellman shared secret) parameters (i.e., ephemeral public key) exchanged between the Supplicant and the Authenticator. Those parameters are input to the PRF (Pseudo Random Function) or the KDF (Key Derivation Function) defined in the IEEE 802.11 specification. PTK is obtained as an output. One or more TKs can be included in (or further derived from) the PTK. The PTK derivation formula may be one of the followings:

[0153] With FILS authentication:

[0154] - PTK = PRF-X(PMK, “FILS PTK Derivation”, SPA || AA || SNonce || ANonce [ || DHss ])

[0155] where x || y is the concatenation of x and y, and “[ || DHss ]” means an alternative to “|| SNonce || ANonce”

[0156] X is 512+TK_bits, 768+TK_bits, 896+TK_bits, 1280+TK_bits depending on the negotiated AKM. TK_bits is the bits of TK depending on the used Cipher suite. Without FILS authentication:PTK = PRF-Length(PMK, “Pairwise key expansion”, Min(AA, SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce || DHss)) if key derivation with Authentication frame exchange for IEEE 802.1X is used. Otherwise,

[0157] PTK = PRF-Length(PMK, “Pairwise key expansion”, Min(AA, SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)).

[0158] where Length = KCK_bits + KEK_bits + TK_bits + KDK_bits. The values of KCK_bits and KEK_bits are AKMP dependent and the value of TK_bits is cipher suite dependent and is defined. If a KDK is derived, the value of KDK_bits is equal to the value of PMK_bits; otherwise the value of KDK_bits shall be 0.

[0159] With FT protocol

[0160] - PTK = KDF-Hash-Length(PMK-R1 , “FT-PTK”, SNonce || ANonce || BSSID || STA- ADDR || DHss) if key derivation with Authentication frame exchange for FT is used. Otherwise,

[0161] - PTK = KDF-Hash-Length(PMK-R1 , "FT-PTK", SNonce || ANonce || BSSID || STA- ADDR)

[0162] where Length is the total number of bits to derive, i.e., number of bits of the PTK. The length is dependent on the negotiated cipher suites and AKMP.

[0163] With PASN authentication

[0164] - PTK = KDF-HASH-NNN (PMK, “PASN PTK Derivation”, SPA || BSSID || DHss) where NNN is the Bits required for KCK, TK, and KDK depending on the pairwise cipher and whether a KDK is derived.

[0165] The values in AA / BSSID, SPA / STA-ADDR and the scope of sharing ANonce / SNonce and / or DHss parameters (ephemeral public keys) depend on which type of PTK it is desired.

[0166] In some embodiments, one PTK includes one TK, in which case a pre-roaming PTK can be generated from which the pre-roaming TK is obtained, one or more roaming Type 1 / Type 2 / Type 3 PTKs can be generated from which the Type 1 / Type 2 / Type 3 TKs are obtained, and a post-roaming PTK can be generated from which the post-roaming TK is obtained. One TK can be extracted from each derived PTK (derived using one of the PTK derivation formulas shown above).

[0167] As the Type 1 SR-PTK is common to the AP MLDs of the SMD, the SMD identifier (e.g., SMD MAC address) can be used as AA and / or BSSID. The SMD identifier or the MLD MAC address of the non-AP MLD can be used for SPA and / or STA-ADDR. In embodiments, the Type 1 SR-PTK is derived using the PTK derivation formula according to the authentication type used for the authentication.

[0168] As the Type 2 SR-PTK is common to a specific AP-MLD pair, the MLD MAC addresses of both APs can be used as AA / BSSID. The point is to differentiate the PTK when the combination of the current AP MLD and the target AP MLD changes. For example, assuming “CAD” is the MLD MAC address of the current AP MLD and “TAD” is the MLD MAC address of the target AP MLD, AA (and / or BSSID) may be defined as XOR (Min(CAD, TAD), Max(CAD, TAD)). Inembodiments, the Type 2 SR-PTK is derived using the PTK derivation formula with PASN authentication (PTK = KDF-HASH-NNN (PMK, “PASN PTK Derivation”, SPA || BSSID || DHss) ), where the ephemeral public keys to compute the DHss can be exchanged using the Roaming Preparation Request 232 / Response 234.

[0169] As the Type 3 SR-PTK preferably reuses the pre-roaming PTK used for the communication between the non-AP MLD and the current AP MLD, AA / BSSID can be set to the MLD MAC Address of the current AP MLD. The resulting Type 3 SR-PTK can be transferred from the current AP MLD to the target AP MLD during context transfer 236 or transferred via SMD-ME.

[0170] For the pre-roaming PTK used to protect communications between the non-AP MLD and the current AP MLD prior to the roaming, AA / BSSID can be set to the MLD MAC Address of the current AP MLD.

[0171] For the post-roaming TK used to protect communications between the non-AP MLD and the target AP MLD, AA / BSSID can be set to the MLD MAC Address of the target AP MLD.

[0172] The ANonce / SNonce and / or DHss parameters are the parameters shared between at least the two entities identified by AA (or BSSID) and SPA (or STA-ADDR). If the entity identified by AA (or BSSID) is the SMD and the entity identified by SPA (or STA-ADDR) is the non-AP MLD, the parameters can be shared between all AP MLDs of the SMD, the SMD-ME and the non-AP MLD. DHss is calculated by using the ephemeral private keys and the ephemeral public keys. The ephemeral private keys are locally stored in the entity identified by SPA (or STA-ADDR) and the entity identified by AA (or BSSID). The ephemeral public keys are shared between those entities preferably using context transfer 236 during the Roaming Preparation procedure 230.

[0173] In some embodiments, one PTK may include or be used to derive multiple TKs. One PTK may be included in the PTKSA. Alternatively, multiple PTKs may be included in the PTKSA, which PTKs can be generated as described above.

[0174] One PTK may be used to derive all or part of the pre-roaming TK, SR-TK, Type 1 SR-TK, Type 2 SR-TK, Type 3 SR-TK, the post-roaming TK. Another PTK (if multiple) may be used to derive those TK needed not yet derived from the first PTK. As an example, a PTK may be used to derive the pre-roaming and post-roaming TKs, while another PTK may be used to derive one or more SR-TKs.

[0175] When one PTK is used to derive multiple TKs, the TKs can be derived from a Master TK. In embodiments, the Master TK is identical to the “Original TK” which is included in the PTK as specified in the IEEE 802.11-2020 specification (hence derived using one of the PTK derivation formulas shown above). In other embodiments, the Master TK is a new TK which is different from the Original TK. For example, the Master TK can be added into the PTK in addition to the Original TK. In this case, the length of the PTK can be increased to accommodate the new Master TK.

[0176] The TKs needed can be derived from the Master TK using a TK derivation formula, which may be for example as one of the followings:

[0177] TK = PRF-Length(Master TK, “Temporal key Derivation”, Min(AA, SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce || DHss))TK = PRF-Length(Master TK, “Temporal key Derivation”, Min(AA, SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)).

[0178] TK = KDF-Hash-Length(Master TK, “Temporal key Derivation”, SNonce || ANonce || BSSID || STA-ADDR || DHss)

[0179] TK = KDF-Hash-Length(Master TK, “Temporal key Derivation”, SNonce || ANonce || BSSID || STA-ADDR)

[0180] - TK = KDF-HASH-NNN (Master TK, “Temporal key Derivation”, SPA || BSSID || DHss) where Length is the total number of bits to derive, i.e., number of bits of the TK. where NNN is the Bits required for the TK.

[0181] Similar to the PTKs above, the values in AA / BSSID, SPA / STA-ADDR and the scope of sharing ANonce / SNonce and / or DHss parameters (ephemeral public keys) depend on which type of TK it is desired.

[0182] As the Type 1 SR-TK is common to the AP MLDs of the SMD, the SMD identifier (e.g., SMD MAC address) can be used as AA and / or BSSID. The SMD identifier or the MLD MAC address of the non-AP MLD can be used for SPA and / or STA-ADDR. In embodiments, the Type 1 SR-TK is derived using the TK derivation formula according to the authentication type used for the authentication.

[0183] As the Type 2 SR-TK is common to a specific AP-MLD pair, the MLD MAC addresses of both APs can be used as AA / BSSID. The point is to differentiate the TK when the combination of the current AP MLD and the target AP MLD changes. For example, assuming “CAD” is the MLD MAC address of the current AP MLD and “TAD” is the MLD MAC address of the target AP MLD, AA (and / or BSSID) may be defined as XOR (Min(CAD, TAD), Max(CAD, TAD)). In embodiments, the Type 2 SR-TK is derived using the following PTK derivation formula: TK = KDF-HASH-NNN (Master TK, “Temporal key Derivation”, SPA || BSSID || DHss), where the ephemeral public keys to compute the DHss can be exchanged using the Roaming Preparation Request 232 / Response 234.

[0184] As the Type 3 SR-TK preferably reuses the pre-roaming PTK used for the communication between the non-AP MLD and the current AP MLD, AA / BSSID can be set to the MLD MAC Address of the current AP MLD. The resulting Type 3 SR-TK - which is also the pre-roaming TK - can be transferred from the current AP MLD to the target AP MLD during context transfer 236 or transferred via SMD-ME.

[0185] For the pre-roaming TK used to protect communications between the non-AP MLD and the current AP MLD, AA / BSSID can be set to the MLD MAC Address of the current AP MLD.

[0186] For the post-roaming TK used to protect communications between the non-AP MLD and the target AP MLD, AA / BSSID can be set to the MLD MAC Address of the target AP MLD.

[0187] The ANonce / SNonce and / or DHss parameters are the parameters shared between at least the two entities identified by AA (or BSSID) and SPA (or STA-ADDR). If the entity identified by AA (or BSSID) is the SMD and the entity identified by SPA (or STA-ADDR) is the non-AP MLD, the parameters can be shared between all AP MLDs of the SMD, the SMD-ME and the non-APMLD. DHss is calculated by using the ephemeral private keys and the ephemeral public keys. The ephemeral private keys are locally stored in the entity identified by SPA (or STA-ADDR) and the entity identified by AA (or BSSID). The ephemeral public keys are shared between those entities preferably using context transfer 236 during the Roaming Preparation procedure 230.

[0188] Figure 2D illustrates a scenario where a single PTKSA [SMD] establishment A 222 is done for the non-AP MLD to establish a single shared PTKSA for the roaming. After the Initial SMD Association 210, the PTKSA [SMD] establishment A 222 is performed to have the shared PTKSA (and the one or more PTKs) and be ready to derive TKs.

[0189] A first TK derivation A 250 is performed right after the PTKSA [SMD] establishment A 222 to derive the pre-roaming TK (TK [AP MLD1]) to protect communications between the non-AP MLD and the current (first) AP MLD1 . As a result, STA1 and AP MLD1 have the same pre-roaming TK.

[0190] In addition, a second TK derivation SMD 252 is performed to derive the SR-TK, typically the Type 1 SR-TK. As a result, STA1 and all the AP MLDs have the same roaming TK.

[0191] Of course, the first TK derivation A 250 and the second TK derivation SMD 252 can be done in any order (second TK derivation SMD 252 can be earlier than first TK derivation A 250).

[0192] When a new roaming comes, a third TK derivation B 254 is performed, e.g., as part of the Roaming preparation procedure 230 or of the Roaming execution procedure 240. The third TK derivation B 254 derives the post-roaming TK to protect communications between the non-AP MLD and the target AP MLD2. As a result, STA1 and AP MLD2 have the same post-roaming TK.

[0193] If a single SR-TK is derived and used (e.g., during the second TK derivation SMD 252), the scenario looks like the one of Figure 2A with however a single PTKSA over time.

[0194] This can be extended to the scenario of Figure 2C, where an additional TK derivation SMD 256 (in dotted line) to derive another SR-TK - Type 2 SRTK or Type 3 SR-TK - is performed at each new roaming. The TK derivation can be done in each AP MLDs from the shared PTKSA and / or some additional parameters shared among AP MLDs. Or the TK derivation can be done in the SMD Management Entity 201 and the TKs can be delivered to each AP MLD. STA1 may derive the TKs by itself.

[0195] Of course, the third TK derivation B 254 and the additional TK derivation SMD 256 can be done in any order (additional TK derivation SMD 256 can be earlier than third TK derivation B 254).

[0196] The single shared PTKSA can also be used in the scenario of Figure 2B, in which case the second TK derivation SMD 252 is omitted and the TK derivation SMD 256 is performed.

[0197] Hybrid scenarios may include renegotiating the single shared PTKSA after a lifetime duration (e.g., the lifetime of the PMKSA including the PMK(s) from which the PTKSA is derived, timeout negotiated during PASN authentication) or a predefined number of roaming / transitions by the same non-AP MLD or due to exhausting the PN space.

[0198] An AP MLD or an SMD may advertise which type of SR-TK it is supporting, for example inside a Beacon frame sent by one of the AP MLDs inside the SMD. In a Beacon frame, the APMLD may include an SMD element which includes any information relevant to SMD. Inside the SMD element, there may be a capability field to declare the supported SR-TK type. For example, it can be a SR-TK support bitmap field which indicates support of each one of Type 1 to Type 3 (or more) using at least three bits. A non-AP MLD receiving the Beacon can identify which type or types of SR-TK the AP MLD or the SMD supports. Similarly, the non-AP MLD may declare which type or types of SR-TK it is supporting, for example inside an Association Request frame sent to an AP MLD or an SMD during the initial association to the SMD. It can be indicated with a SR-TK support bitmap field (as above) as well.

[0199] By exchanging the supported SR-TK type or types to each other, the AP MLD and the non-AP MLD may initiate PTKSA establishment or TK Derivation to exchange the TK they want to use. The initiation can be triggered by any means, for example the AP MLD may start 4 (or 3) way handshake, or the non-AP MLD or the AP MLD may send a dedicated Action frame, or the non-AP MLD may send the Roaming preparation request frame typically for the Type 2 or Type 3 SR-TK.

[0200] Figure 3 schematically illustrates, through a sequence of messages, an exemplary frame exchanges along the seamless roaming or BSS transition divided into three phases, according to embodiments. During each phase, a corresponding TK is used to encrypt the transmitting MPDU. MPDUs encrypted by the specific TK is buffered in the transmission buffer and sent to the destination with some queuing delay. As a result, MPDUs encrypted in the Phasel 310 with a Key A are sent in 330 depicted with solid lines, MPDUs encrypted in the Phase2 312 with a Key B are sent in 332 depicted with dotted lines, and MPDUs encrypted in the Phase3314 with a Key C are sent in 334 depicted with dash-dotted lines.

[0201] MPDUs may fail to reach the destination and be retransmitted. In this case, some packets can be sent again interleaved with MPDUs of another phase, as shown for example in 336 depicted with solid line (i.e., the MPDU 336 encrypted with Key A is transmitted amongst the MPDUs encrypted with Key B). When a receiver STA (including both non-AP MLDs and AP MLDs) receives an encrypted MPDU, it decrypts the MPDU with the corresponding keys. The corresponding keys can be identified by the information included in the frame for example using the Key ID field of the CCMP / GCMP header value. The MPDU is typically a Data frame but it may also include an individually addressed robust Management frame.

[0202] In embodiments, Phasel is a pre-roaming phase where a pre-roaming TK (Key A) (e.g., derived from the PTKSA established in PTKSA [AP MLD1] establishment 220) is used to protect communications between the non-AP MLD and the current AP MLD. Frame exchanges in Phasel only take place between STA1 and AP MLD1. Phase 2 is a roaming phase where the roaming TK, SR-TK, (Key B) is used to protect communications with the current and target AP MLDs. SR-TK can be any one of the three types explained above. If SR-TK is a Type 3 SR-TK, the same TK as Key A can be continuously used in Phase2 (i.e., no key switching between Phase 1 310 and Phase 2 312 is needed). Frame exchanges in Phase2 can take place between STA1 and AP MLD1 and also between STA1 and AP MLD2. Phase3 is a post-roaming phase where a post-roaming TK (Key C) (e.g., derived from the PTKSA established in PTKSA [AP MLD2] establishment 224) is used to protect communications between the non-AP MLD and the (new) target AP MLD. Frame exchanges in Phase3 only take place between STA1 and AP MLD2.

[0203] Figure 3 clearly shows that SR-TK usage is limited to Phase2312, thereby mitigating the security risk of using a shared TK (shared between multiple AP MLDs).

[0204] In one embodiment, the three phases can be separated by specific frame exchanges. For example, Roaming preparation request / response frames 232 / 234, or Roaming execution request / response frames 242 / 244 can be used to separate the phases. STA1 and AP MLD1 starts from Phase 1 310 as a default after association. STA1 may switch to Phase 2 312 when the Roaming preparation request 232 is sent or the Roaming preparation response 234 is received. Or, STA1 may switch to Phase 2 312 when the Roaming execution request 242 is sent or the Roaming response 244 is received. AP MLD1 may switch to Phase 2 312 when the Roaming preparation request 232 is received or the Roaming preparation response 234 is sent. Or, AP MLD1 may switch to Phase 2 312 when the Roaming execution request 242 is received or the Roaming response 244 is sent. AP MLD2 starts Phase 2 312 when the Roaming execution request 242 is received (either directly from STA1 or the information is forwarded via AP MLD1). STA1 and AP MLD2 may switch to Phase 3 314 when the specific time period or timeout (shown in 260) is elapsing after the Roaming execution response 244. In other words, the process of roaming (where the SR-PTK can be used) ends a predetermined duration after the Roaming execution response frame sent by the target AP device. In some embodiments, the predetermined duration or timeout 260 may be indicated from one of the AP MLDs inside the Roaming execution response 244.

[0205] In other embodiments, the three phases can be separated by other means that indicates the possibility of roaming execution. For example, RSSI of the peer device (i.e., STA1 for AP MLD1 / AP MLD2, AP MLD1 / AP MLD2 for STA1) or the location information ofthe peer device (AP MLDs’ location for STA1 , STA1 location for AP MLDs) can be used to identify the possibility of roaming execution.

[0206] In a scenario using RSSI, if the RSSI ofthe current associated peer device goes under a predetermined threshold, the devices (including both non-AP MLDs and AP MLDs) may switch the phase from Phase 1 310 to Phase 2312. Or if the RSSI ofthe target AP MLD gets better than the RSSI ofthe current AP MLD, STA1 may switch the phase from Phase 1 310 to Phase 2 312. Also, if the RSSI of STA1 from the target AP MLD gets better than the RSSI of STA1 from the current AP MLD, AP MLD1 may switch the phase from Phase 1 310 to Phase 2 312. Once the RSSI ofthe target AP MLD gets better than the predetermined threshold, the devices may switch the phase from Phase 2 312 to Phase 3314.

[0207] In a scenario using location information ofthe peer devices, the devices may use Timing Measurement or Fine Timing Measurement scheme to obtain the distance ofthe peer device, or share the location information obtained by GPS. If the peer device is reaching into or getting out of a predetermined area, the devices may decide to switch the phase.As another example, the number of the transmission failures or of the retransmission failures can be used to identify the possibility of roaming execution. Once the number of the transmission failures or of the retransmission failures with the current peer device surpasses a predetermined threshold, the devices may switch the phase from Phase 1 310 to Phase 2312.

[0208] In other embodiments, the three phases can be separated by a combination of both conditions of specific frame exchanges and the possibility of roaming execution as described above.

[0209] As one can note, the third phase with respect to a first roaming becomes a first phase with respect to a subsequent roaming. The MLD (either non-AP or AP MLD) switches between two types of TKs depending on whether a roaming phase is on-going or not.

[0210] In that respect, Figure 4A illustrates, using a flowchart, general steps at an MLD to manage the TKs for its transmissions, according to some embodiments. The MLD can be either a non-AP MLD or an AP MLD.

[0211] The shared SR-TK (Type 1 , Type 2 or Type 3) is derived, shared and stored locally as described above. The TK dedicated to a single AP MLD (target AP MLD) is derived and stored locally as described above.

[0212] The MLD if acting as a non-AP MLD may be transmitting to a current AP MLD using TK [current AP MLD]. The MLD if acting as an AP MLD may be transmitting to the non-AP MLD using TK [current AP MLD]. The MLD if acting as a target AP MLD may not transmit yet to the non-AP MLD.

[0213] At step 400, the MLD determines whether a roaming phase is entered, based e.g. on a Roaming preparation request 232 (or any variant as described above).

[0214] In the negative, nothing happens at the MLD, which loops to same step 400.

[0215] In the affirmative, the MLD switches to applicable SR-TK as described above. All three non-AP MLD, current AP MLD and target AP MLD switch. The switching may include retrieving the SR-TK from local memory. Note that in some embodiments described above, SR-TK = TK [current AP MLD] in which case the non-AP MLD and the current AP MLD keep going with TK [current AP MLD] as SR-TK, while the target AP MLD activates such SR-TK for its transmissions to the non-AP MLD.

[0216] The switching may include determining whether to use a Type 1 SR-TK or a Type 2 (or Type 3) SR-TK according to criterions, such as the exchange of the Type 2 (or Type 3) SR-TK during the Roaming preparation procedure as described with reference to Figure 2C (reference 226) or Figure 2D (reference 256).

[0217] The SR-TK enabled at step 405 is used to protect communications with the peer MLD. Next to step 405, the MLD determines, at step 410, whether the roaming phase has ended, based e.g. on the elapsing of the specific time period 260 following the Roaming execution response frame 244 (or any variant as described above).

[0218] In the negative, nothing happens at the MLD, which loops to same step 410.In the affirmative, the MLD switches, at step 415, to TK [target AP MLD] which is specific to the relationship between the non-AP MLD and the target AP MLD. Of course, this happens for these two MLDs, meaning that the current AP MLD only deactivates any TK for communication with the non-AP MLD. The switching may include retrieving TK [target AP MLD] from local memory, as stored after PTKSA [target AP MLD] establishment 224 or TK derivation B 254.

[0219] Next to step 405, the MLD loops back to step 400.

[0220] Figure 4B illustrates, using a flowchart, general steps at a transmitting MLD to conduct MPDU transmission, according to some embodiments. A transmitting MLD can be either a non-AP MLD or an AP MLD. The MLD can be either a non-AP MLD or an AP MLD. This process is implemented at the MLD gaining access to the medium and having an MPDU to transmit (UL MPDU for a non-AP MLD, DL MPDU for an AP MLD).

[0221] At step 420, the transmitting MLD encrypts the MPDU using the currently active TK. The currently active TK is the one currently enabled given the process of Figure 4A.

[0222] Information about the used TK is included in the encrypted MPDU for example using the Key ID field of the CCMP / GCMP header value.

[0223] Next, at step 425, the encrypted MPDU is sent to a destination MLD.

[0224] Figure 4C illustrates, using a flowchart, general steps at a receiving MLD to conduct MPDU reception, according to some embodiments. A receiving MLD can be either a non-AP device or an AP MLD.

[0225] At step 430, the receiving MLD receives an encrypted MPDU destined to itself (UL MPDU for an AP MLD, DL MPDU for a non-AP MLD).

[0226] At step 435, the receiving MLD identifies the TK to be used by parsing the information (Key ID field) included in the received frame. This information may merely distinguish between a SR-TK and a TK [AP MLD] specific to a single AP MLD. In other embodiments as described below, this information may help distinguish between a higher number of TKs.

[0227] Next, at step 440, the receiving MLD decrypts (deciphers) the received MPDU using the identified TK.

[0228] In some scenarios described above, the receiving MLD has to keep multiple TKs available in local memory. This is for example the case in the scenario of Figure 2C, wherein STA1 as a receiving device keep three TKs available: those included in PTKSA [AP MLD1] established in 220 or PTKSA [AP MLD2] established in 224, in (by-default) PTKSA [SMD] established in PTKSA[SMD] establishment A 222 and in PTKSA [SMD] established in PTKSA[SMD] establishment B 226.

[0229] Furthermore, if the RSNA rekeying scheme of each temporal key is considered, each of these TKs is regenerated after its lifetime expires (either in absolute time or due to exhausting the PN space). As a result, there may be up to six TKs locally stored at the MLD, at the same time.

[0230] In embodiments relying on three TKs, the Key ID field (2bits) of the CCMP / GCMP header can be used to identify the used TK. Each value 00, 01 , 10 can be assigned to each Key respectively. For example, 00 signals TK [AP MLD1] or TK [AP MLD2] depending on the AP MLDinvolved in the communication, 01 signals Type 1 SR-TK of PTKSA [SMD] established in PTKSA [SMD] establishment A 222, and 10 signals Type 2 (or Type 3) SR-TK of PTKSA [SMD] established in PTKSA [SMD] establishment B 226. Value 11 is reserved in this case. RA and TA fields in the MPDU header can be used to identify the receiving and transmitting MLDs respectively. As one of these fields identifies the AP MLD involved (AP MLD1 or AP MLD2), the key ID value 00 uniquely identifies whether it is TK [AP MLD1] established with AP MLD1 or TK [AP MLD2] established with AP MLD2.

[0231] In embodiments relying on more TKs (such as in case of RSNA rekeying), one additional bit of the Reserved bits may be assigned to indicate which TK (i.e., the old one or the new one given the rekeying) is to be used for each TK. In these embodiments, three bits are used in total to indicate which TK of the eight TK candidates is used. The support of this new bit can be indicated for example, by the Reserved bits of the RSN Capabilities element or by the Reserved bits of Extended RSN Capabilities field in the RSN extension element or by any other Reserved bits or by any other new field.

[0232] In IEEE802.11-2020 specification, the Key ID field is used to identify one of the two TKs (old one or new one given the RSNA rekeying) during the transition which happens during the RSNA rekeying scheme if the Extended Key ID for Individually Addressed Frames field of the RSN Capabilities element sent from the MLD is set to 1. To use the Key Id field for another purpose as proposed in this disclosure, the Extended Key ID for Individually Addressed Frames field of the RSN Capabilities element sent from the MLD can be set to 0 and the other field may be used to indicate the alternate usage of the Key ID field. For example, the Reserved bits of the RSN Capabilities element or the Reserved bits of Extended RSN Capabilities field in the RSN extension element or any other Reserved bits or new field can be used for this purpose.

[0233] In alternative embodiments that keep the current usage of the Key ID field, values 00 and 01 are kept for the existing purpose as specified in IEEE 802.11-2020 specification (i.e., signaling the old or new TK given the rekeying), values 10 and / or 11 (currently reserved) may be used for the new purpose of the present disclosure. For example, value 10 signals which TK from amongst the ones of PTKSA [current AP MLD] and of PTKSA [target AP MLD] is used. In addition, one more Reserved bit in the CCMP / GCMP header can be assigned to identify two more TKs (e.g., the TKs of PTKSA [SMD] established in PTKSA [SMD] establishment A 222 and B 226 respectively). Alternatively, values 10 and / or 11 can be used to signal the TK of PTKSA [SMD]. The Reserved bit in the CCMP / GCMP header can be used to signal the TK of PTKSA [current AP MLD] or of PTKSA [target AP MLD],

[0234] In other embodiments, Reserved bits in the CCMP / GCMP Header of IEEE 802.11-2020 specification can be assigned as a new field for the key indication purpose proposed in this disclosure. In this case, the existing Key ID field is used for the existing purpose as specified in IEEE 802.11-2020 specification, and only the Reserved bits are used to signal which TK from amongst the multiple PTKSA [current AP MLD], PTKSA [target AP MLD], PTKSA [SMD] is used. The support of this new field can be indicated for example, by the Reserved bits of the RSNCapabilities element or by the Reserved bits of Extended RSN Capabilities field in the RSN extension element or by any other Reserved bits or by any other new field.

[0235] In embodiments where only one type of SR-TK is used (e.g., as in Figures 2A and 2B or 2D in some embodiments), only two key ID values may be enough to identify all TKs. For example, value 10 may signal the TK of PTKSA [AP MLD1] or TK of PTKSA [AP MLD2] (based on the RA or TA field), while value 11 may signal the TK of PTKSA [SMD]. The existing Key ID field in the CCMP / GCMP field is advantageously used without assigning additional bits.

[0236] All of these embodiments apply as well for the embodiments shown in Figure 2D where multiple TKs are derived from one single PTKSA [SMD]. Each TK can be identified by the key IDs.

[0237] In the above various embodiments, a frame exchanged by an MLD includes a field in the CCMP or GCMP header, which field signals which key is used to protect the frame from amongst the pre-roaming / post-roaming TK (TK [AP MLD1] or TK [AP MLD2]) and the SR-TK (whatever its Type 1 or 2 or 3).

[0238] PN (Packet Number) is included in the CCMP / GCMP header to perform replay detection. When a receiving MLD receives an MPDU, it extracts the PN from the CCMP / GCMP header. The receiving MLD maintains a separate set of replay counters for each PTKSA. The receiving MLD initializes these replay counters to 0 when it resets the TK for a peer. The replay counter is set to the PN value of accepted CCMP / GCMP MPDUs. For each PTKSA, the receiving MLD maintains a separate replay counter for each TID, subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field. If management frame protection is negotiated, the receiving MLD maintains a single replay counter for received individually addressed robust Management frames except Protected Fine Timing frames that are received with the To DS subfield equal to 0, and a single replay counter for received individually addressed robust PV1 Management frames except PV1 Protected Fine Timing frames. The receiving MLD discards any Data frame that is received with its PN less than or equal to the value of the replay counter that is associated with the TA, RA (individual or group address; not if TDLS) and priority value of the received MPDU. The receiving MLD discards fragmented MSDUs, A-MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. If management frame protection is negotiated, the receiving MLD discards any individually addressed robust Management frame that is received with its PN less than or equal to the value of the replay counter associated with the TA. In this way, replay detection is performed.

[0239] The PN mechanism may be adjusted to take into account the multiple MLDs involved with the shared SR-TK.

[0240] In case of using SR-TKs, the frames encrypted by one of the SR-TKs (i.e ., Type 1 , Type 2 or Type 3 ST-TK) may be protected by the replay detection using a single replay counter for each SR-TK. To achieve this, the PN expected for the next frame exchange using a given SR-TK can be synchronized between the transmitting MLD and the receiving MLD. This synchronization can be done through context transfers triggered by STA1 (e.g., triggered by Roaming preparationrequest 232 or Roaming execution request 242 in Figures 2A to 2D or any other Action frame not shown in the Figure) or through information sharing triggered by the SMD-ME or one of the AP MLDs (not shown in the Figure).

[0241] In one embodiment, the expected PN value is shared as context information from the current AP MLD to the target AP MLD (e.g., during context transfer 236). The latest PNs used for the UL / DL frame exchanges using the SR-TK can be identified respectively by the current AP MLD. For example, here we assume value N is the last one for UL and value M is the last one for DL. The expected PN values used for the UL / DL frame exchanges between STA1 and the target AP MLD using the SR-TK are shared as context information from the current AP MLD (AP MLD1) to target AP MLD (AP MLD2) in the context transfer 236 triggered by the Roaming preparation request 232 or by the Roaming execution request 242. The expected PN values have to be larger than N for UL and M for DL to clear the replay detection. Since there may be additional frame exchanges between STA1 and the current AP MLD (AP MLD1) after the Roaming preparation request 232 or the Roaming execution request 242, some PN gaps X / Y (e.g. 100 for X, 50 for Y) may be added to accommodate those frame exchanges. With this, the expected PN values are N+X for UL and M+Y for DL. X and Y may be set depending on the UL / DL traffic pattern and / or the estimated duration until the roaming. X and Y can be an identical value. STA1 and the target AP MLD (AP MLD2) both manage the values N+X and M+Y and use these PNs when they start exchanging frames to each other during the roaming.

[0242] The PN is maintained per PTKSA: The new TK negotiated with the target AP MLD shares the same PN space with the TK of the current AP MLD (PN is monotonically increasing).

[0243] In this respect, the current AP MLD has a current packet number PN (or multiple when considering UL and DL) associated with the SR-PTKSA (hence SR-PTK) to perform replay detection of frames encrypted using the SR-TK and exchanged with the non-AP MLD, and the current AP MLD shares the current PN or the current PN increased by an incremental value to the target AP MLD for the latter to perform replay detection of frames encrypted using the SR-TK and exchanged with the non-AP MLD. The incremental value to be added may be signaled from the current AP MLD to the target AP MLD in the Context transfer 236 or Context transfer 238, or it may be predefined at each MLD, or it may be already added to the current PN when transmitted by the current AP MLD. As well, if the pre-roaming TK, SR-TK and the post-roaming TK are all derived from one single PTKSA, the same PN space is used for all TKs. So, the PN has to monotonically increase even when the TK is switched from one to another, as long as the TKs are tied to the same PTKSA. Since the switch from the pre-roaming TK to SR-TK (which happens between STA1 and AP-MLD1), and from SR-TK to the post-roaming TK (which happens between STA1 and AP-MLD2) happens between the same non-AP MLD and AP MLD, it is simple to maintain the PN space incrementally (without the increase of predefined value).

[0244] If TKs are used that are tied to different PTKSAs, different PNs (hence different PN spaces) are preferably used, one for each PTKSA (and its keys).In case the start of Phase2 312 is independent from the Roaming preparation request 232 and the Roaming execution request 242, another frame may trigger context transfer to convey the expected PN values. This can be any existing Action frame with an extended purpose or a new Action frame defined in the future amendment of IEEE 802.11.

[0245] Depending on the roaming to exchange the PN value means that STA1 (the non-AP MLD) initiates the PN sharing.

[0246] In other embodiments, the PN values can be synchronized among the SMD without any specific request from STA1 . In this case, the current AP MLD1 and target AP MLD2 synchronize the PN values in the background whenever they need to. Synchronization can be done each time the PN is updated or can be done at a specific interval or whenever specific events happen. The SMD-ME can manage the synchronization in a centralized manner or each AP MLD can communicate with each other to manage the synchronization in a distributed manner.

[0247] In some embodiments, the PN(s) can be saved locally from one roaming procedure to the next roaming procedure. For example, after one roaming execution, the PN(s) associated with a Type 1 SR-TK are maintained for the next frame exchanges which will happen during the next roaming execution. This is because the Type 1 SR-TK is maintained over time in the SMD and can be used as a default SR-TK (as in the scenario of Figure 2C). This may also be the case for a Type 2 or Type 3 SR-TK at the AP MLDs, in case of roaming back of STA1 to the same AP MLD. This is because the Type 2 or Type 3 SR-TK may be maintained over time with some criteria (e.g., within a specific time duration or until surpassing specific RSSI threshold of the new current AP MLD which indicates stable connection), in which case, the corresponding PN for the SR-TK is maintained overtime.

[0248] In some embodiments, the PN(s) can be discarded from one roaming procedure to the other. For example, after one roaming execution, the PN(s) associated with a Type 2 or Type 3 SR-TK are discarded. This is because a new Type 2 or Type 3 SR-TK will be used at STA1 for the next roaming execution.

[0249] Figure 5A schematically illustrates a communication device 500 configured to implement at least one embodiment of the present disclosure, for instance any of the (AP and non-AP) MLDs shown in Figure 1.

[0250] The communication device 500 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 500 comprises a communication bus 513 to which there are preferably connected:

[0251] a central processing unit 501 , such as a processor, denoted CPU;

[0252] a memory 503 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

[0253] at least one communication interface 502 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 504.Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 500 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 500 directly or by means of another element of the communication device 500.

[0254] 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 502, in order to be stored in the memory of the communication device 500 before being executed.

[0255] In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the disclosure. However, alternatively, embodiments of the present disclosure may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

[0256] Figure 5B is a block diagram schematically illustrating the architecture of the communication device 500, adapted to carry out, at least partially, the disclosure. As illustrated, device 500 comprises a physical (PHY) layer block 523, a MAC layer block 522, and an application layer block 521.

[0257] The PHY layer block 523 (here an 802.11 standardized PHY layer) has the task of formatting, modulating on or demodulating from any 20MHz channel or the common communication channel, and thus sending or receiving frames over the wireless radio medium used, such as 802.11 frames, for instance MAC data and management frames based on a 20MHz width.

[0258] The MAC layer block or controller 522 preferably comprises a MAC 802.11 layer 524 implementing conventional 802.11 be MAC operations, and additional block 525 for carrying out, at least partially, the disclosure. The MAC layer block 522 may optionally be implemented in software, which software is loaded into RAM 503 and executed by CPU 501.

[0259] Preferably, the additional block 525, referred to as Seamless roaming managing module which has different operations to implement parts of the disclosure, depending on the role played by the communication device 500, as described above.

[0260] MAC 802.11 layer 524 and Seamless roaming Managing module 525 interact one with each other in orderto process accurately the seamless roaming procedure, e.g., to perform frame exchanges when appropriate according to embodiments.

[0261] On top of the Figure, application layer block 521 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 521 represents all the stack layers above MAC layer according to ISO standardization.

[0262] Although the present disclosure has been described hereinabove with reference to specific embodiments, the present disclosure is not limited to the specific embodiments, andmodificationswill be apparent to a skilled person in the art which lie within the scope of the present disclosure.

[0263] Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the disclosure, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

[0264] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

34CLAIMS1. A communication method in a mobility domain (MD) comprising a plurality of access points (APs), the method comprising, at a non-AP device:roaming from a current AP device to a target AP device within the MD,wherein a first temporal key (TK) derived from a first Pairwise Transient Key Security Association (PTKSA) is used during the process of roaming from the current AP device to the target AP device to protect communications with the current AP device and the target AP device, and a second TK different from the first TK is used before the roaming to protect communications with the current AP device or is used after the roaming to protect communications with the target AP device.

2. The method of Claim 1 , further comprising, at the non-AP device, obtaining a third TK to protect communications with the current AP device before the roaming, wherein the first TK is different from the third TK and the second TK is used after the roaming to protect communications with the target AP device.

3. The method of Claim 1 , further comprising, at the non-AP device, obtaining a third TK to protect communications with the current AP device before the roaming, wherein the first TK is the third TK and the second TK is used after the roaming to protect communications with the target AP device.

4. The method of Claim 1 , further comprising, at the non-AP device, obtaining a third TK to protect communications with the target AP device after the roaming, wherein the first TK is different from the third TK and the second TK is used before the roaming to protect communications with the current AP device.

5. The method of any of Claims 2 to 4, wherein the third TK is derived from the first PTKSA.

6. The method of any of Claims 2 to 4, wherein the third TK is derived from another PTKSA different from the first PTKSA.

7. The method of Claim 1 , wherein the second TK is used before the roaming to protect communications with the current AP device, and the first TK is also used after the roaming to protect communications with the target AP device.

8. The method of Claim 1 , further comprising, at the non-AP device, obtaining a fourth TK shared with a group, possibly all, of the AP devices of the MD, wherein:if a fifth TK shared with the current AP device and the target AP device is obtained when preparing the roaming, the first TK is the fifth TK,otherwise, the first TK is the fourth TK.

9. The method of Claim 8, wherein the fourth and fifth TKs are derived from the first35PTKSA.

10. The method of Claim 8, wherein the fourth and fifth TKs are derived from respective PTKSAs different from the first PTKSA.

11. The method of Claim 1 , wherein a frame exchanged by the non-AP device includes a field in a Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CCMP) or Galois / Counter Mode (GCM) protocol (GCMP) header, which field signals which key is used to protect the frame from amongst the first TK and the second TK.

12. A communication method in a mobility domain (MD) comprising a plurality of access points (APs), the method comprising, at a target AP device:detecting a roaming of a non-AP device from a current AP device to the target AP device within the MD,wherein a first temporal key (TK) derived from a first Pairwise Transient Key Security Association (PTKSA) is used during the process of roaming of the non-AP device from the current AP device to the target AP device to protect communications with the non-AP device,and a second TK different from the first TK is used after the roaming to protect communications with the non-AP device.

13. The method of Claim 12, wherein a frame exchanged by the target AP device with the non-AP device includes a field in a Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CCMP) or Galois / Counter Mode (GCM) protocol (GCMP) header, which field signals which key is used to protect the frame from amongst the first TK and the second TK.

14. A communication method in a mobility domain (MD) comprising a plurality of access points (APs), the method comprising, at a current AP device:detecting a roaming of a non-AP device from the current AP device to a target AP device within the MD,wherein a first temporal key (TK) derived from a first Pairwise Transient Key Security Association (PTKSA) is used during the process of roaming of the non-AP device from the current AP device to the target AP device to protect communications with the non-AP device,and a second TK different from the first TK is used before the roaming to protect communications with the non-AP device.

15. The method of Claim 14, wherein a frame exchanged by the current AP device with the non-AP device includes a field in a Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CCMP) or Galois / Counter Mode (GCM) protocol (GCMP) header, which field signals which key is used to protect the frame from amongst the first TK and the second TK.

16. The method of Claim 1 or 12 or 14, wherein the first TK is a TK shared between allthe AP devices of the MD.

17. The method of Claim 1 or 12 or 14, wherein the first TK is a TK shared between the non-AP device, the current AP device and a set of candidate target AP devices forming a subset of the MD.

18. The method of Claim 1 or 12 or 14, wherein the first TK is a TK shared only between the non-AP device, the current AP device and the target AP device.

19. The method of Claim 1 or 12 or 14, wherein the first TK is provided to the current AP device and the target AP device by a Management Entity of the MD.

20. The method of Claim 1 or 12 or 14, wherein the first TK is shared with the current AP device and the target AP device upon the non-AP device initially associating with the MD.

21. The method of Claim 1 or 12 or 14, wherein the first TK is shared with the current AP device and the target AP device during a roaming preparation procedure.

22. The method of Claim 21 , wherein the first TK is included in a context transferred by the current AP device to the target AP device during the roaming preparation procedure.

23. The method of Claim 1 or 12 or 14, wherein parameters to generate the first TK are included in a context transferred by the current AP device to the target AP device during the roaming preparation procedure, so that the target AP generates the first TK by its own.

24. The method of Claim 1 or 12 or 14, wherein the second TK is derived from the first PTKSA.

25. The method of Claim 24, wherein the first PTKSA includes a single PTK and the first and second TKs are derived from the PTK.

26. The method of Claim 24, wherein the first PTKSA includes at least two PTKs and the first and second TKs are derived from respective PTKs.

27. The method of Claim 1 or 12 or 14, wherein the second TK is derived from a second PTKSA different from the first PTKSA.

28. The method of Claim 27, wherein the first PTKSA includes a single PTK and the first TK is derived from the PTK to protect communications with the current AP device and the target AP device.

29. The method of Claim 1 or 12 or 14, wherein the process of roaming ends a timeout after a Roaming execution response frame sent by the target AP device.

30. The method of Claim 29, wherein the timeout is indicated in the Roaming execution response frame.

31. The method of Claim 1 or 12 or 14, wherein the current AP device has a current packet number (PN) associated with the first PTKSA to perform replay detection of framesencrypted using the first TK and exchanged with the non-AP device, wherein the current AP device shares the current PN or the current PN increased by an incremental value to the target AP device for the latter to perform replay detection of frames encrypted using the first TK and exchanged with the non-AP device.

32. The method of Claim 31 , wherein the target AP device increases the received current PN by an incremental value to perform the replay detection of frames.

33. A communication method in a communication device, comprising: establishing a Pairwise Transient Key Security Association (PTKSA),deriving a first key from the PTKSA to protect communications with a first device, and deriving a second key from the PTKSA to protect communications with a second device.

34. A wireless communication device comprising at least one microprocessor configured for carrying out the method of Claim 1 or 12 or 14 or 33.

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

Images