Managing roaming of client devices in wireless network

Abstract

Embodiments of the present disclosure relate to managing roaming of a client device in a wireless network. Example methods and network devices are presented that identify a correct roaming target set that includes one or more non-radio frequency (RF) neighbor access points (APs) to which roaming provisioning credentials may be provided prior to a client device roaming in its network coverage area. In some examples, a network device may use a machine learning model to identify a first roaming target set that includes one or more non-RF neighbor APs corresponding to a source AP of a client device in a network infrastructure. The network device may then determine a first roaming provisioning credential for the first set of roaming targets, and transmit the first roaming provisioning credential to the first set of roaming targets before the client device roams to any roaming target in the first set of roaming targets.

Description

BACKGROUND

[0001] Roaming in wireless fidelity (Wi-Fi) is a process by which a mobile client device seamlessly switches from one wireless networking device, such as an access point (AP), to another AP as its user moves from one location to another in a network infrastructure. When the device moves out of range of the currently associated AP, referred to as a source AP, it searches for the next available AP with the strongest signal and associates with that AP. The AP with which the client device newly associates is referred to as a target AP. The roaming process occurs automatically and is designed to provide uninterrupted connectivity to the user's online activities. More specifically, to prevent disruption of the user's online activities (e.g., web browsing, video / audio streaming, video / audio conferencing, etc.) as the mobile device roams from the source AP to the target AP, the client device needs to successfully associate with the target AP. To enable such fast association with the client device, roaming credentials are typically provisioned to candidate target APs.

[0002] In such roaming processes, identification of a correct set of target APs can be challenging, which can cause delays in re-association of the client device and disrupt wireless network connectivity of the client device. For example, lack of understanding of movement of the client device can impact identification of the correct set of target APs. Misidentification of the correct set of target wireless networking devices can render roaming credentials required to successfully authenticate the client device unavailable, resulting in delays in establishing wireless connectivity for the client device. This can in turn disrupt the user's online activities, causing an unpleasant user experience. BRIEF DESCRIPTION OF DRAWINGS

[0003] One or more examples in the present disclosure are described in detail below with reference to the following drawings. The drawings provided are for purposes of illustration only and merely depict example examples.

[0004] Figure 1 An example networking system in which various examples presented herein can be implemented is depicted.

[0005] Figure 2 An example interaction between components shown in the networking system of Figure 1 is depicted.

[0006] Figure 3 A block diagram of an example cloud computing system hosting network devices for managing roaming of client devices is depicted.

[0007] Figure 4 A flow diagram of an example method for managing roaming of client devices in a network infrastructure is depicted.

[0008] Figure 5 A flow diagram of another example method for managing roaming of client devices in a network infrastructure is depicted.

[0009] Figure 6 A block diagram depicting an example computing system is illustrated.

[0010] The accompanying drawings are not exhaustive and do not limit the present disclosure to the precise form disclosed. DETAILED DESCRIPTION

[0011] A target access point (AP) can use a roaming credential to enable faster roaming of a client device. The roaming credential can include cryptographic keys such as an R0 key and an R1 key. The R0 key is used for security during an initial mobility domain association for the client device. The R0 key can be derived from a pairwise master key (PMK) and used to protect authentication and association frames during the initial association of the client with an AP within a mobility domain. The R1 key is used for security during re-association of the client device within the same mobility domain. The R1 key can be derived from the PMK and used to protect re-association frames when the client roams from one access point to another within the same network.

[0012] In known fast roaming solutions, a cloud-hosted key management service pre-populates R1 keys to direct radio frequency (RF) neighbor APs of an AP from which a client device is assumed to roam. A direct RF neighbor AP for a host AP can refer to any AP that is within a predetermined radio frequency (RF) range. The RF range can be determined based on RF signal strength at the host AP. In known fast roaming solutions, after a client device is associated with a source AP, the source AP provides the R0 key of the client device to the key management service. The key management service then obtains a list of direct RF neighbor APs of the source AP and computes R1 keys (PMK-R1) for these direct RF neighbor APs. After computing the R1 keys, the key management service pre-assigns the R1 keys to all the direct RF neighbor APs. Thus, when the client device moves within range of one of the direct RF neighbor APs, such direct RF neighbor AP can successfully authenticate the client device as it already has the R1 for re-association of the client device.

[0013] This can work well and achieve seamless roaming with minimal disruption to applications like voice and video. However, challenges arise when the client device roams to an AP that is not a direct RF neighbor AP of its corresponding source AP. For example, a user can move between floors, such as to attend a meeting or move to an area like a cafeteria served by other APs that are not neighbor APs of the source AP. In other implementations such as a university deployment, a user can turn off their laptop and move to another classroom served by an AP that is not a neighbor of the source AP of the client device. As such, existing fast roaming solutions lack the ability to predict such roaming scenarios that impact roaming efficiency. Therefore, there is a need to enable a smoother transition in unpredictable mobility situations, thereby ensuring a consistently reliable and uninterrupted network experience for users.

[0014] To address the above challenges, in examples consistent with the teachings of the present disclosure, a method and network device are presented that identifies a correct set of roaming targets to which a client device can be provisioned with roaming provisioning credentials before it roams in its network coverage area. Specifically, the proposed network device leverages historical roaming patterns within a particular deployment to learn the roaming behavior of its client devices for a given AP by training a machine learning (ML) model, and uses such ML model to reason future roaming events. Moreover, in some examples, the proposed network device can also identify another set of roaming targets that includes direct RF neighbor APs of the source AP. As such, the proposed network device can be able to identify both direct RF neighbor APs as well as non-RF neighbor APs, if any, and provision them with useful roaming provisioning credentials to enable fast roaming of the client device. For example, by building the ML model based on past roaming behavior and patterns, Rl keys can be intelligently pre-populated on direct RF neighbor APs and non-RF neighbor APs that are candidates for future roaming events.

[0015] In some examples, the network device can access an ML model constructed based on a dataset characterizing past roaming of client devices among APs in a network infrastructure. The network device can then use the ML model to identify a first set of roam targets including one or more non-RF neighbor APs corresponding to a home of a client device in the network infrastructure. The network device can then determine, for each roam target in the first set of roam targets, a respective roam provisioning credential and transmit the roam provisioning credential to each roam target in the first set of roam targets before the client device roams to any roam target in the first set of roam targets. In some examples, the network device can also identify a second set of roam targets that can include direct RF neighbor APs of the source AP. The network device can also determine roam provisioning credentials for the second set of roam targets and transmit them to each roam target in the second set of roam targets before the client device roams to any roam target in the second set of roam targets.

[0016] It can be appreciated that the proposed network device can enable seamless roaming and enhance user experience as the ML model can be able to predict roam targets that are not direct RF neighbor APs to which a client device is connected. With the proposed techniques, roam credentials, e.g., Rl keys, can be pre-populated to such non-RF neighbor APs that can then use these keys for faster authentication. As a result of faster overall re-association, service interruption to the client device can be minimized, leading to an overall better user experience.

[0017] The following detailed description refers to the accompanying drawings. It should be clearly understood that the drawings are minimum for illustration and description only. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples. On the contrary, proper scope of the disclosed examples can be defined by the appended claims.

[0018] Before describing examples of the disclosed systems and methods in detail, it is useful to describe an example network installation in which these systems and methods can be implemented. Figure 1 An example networking system 100 in which various examples presented herein can be implemented is depicted. The networking system 100 can be implemented for any setting, e.g., in a home setting or in an organization such as a business, an educational institution, a government entity, a healthcare facility, or other organization. The networking system 100 can include a network infrastructure 102, or both the network infrastructure 102 and network devices 104. In Figure 1In particular implementations, although the network devices 104 are shown as being external to the network infrastructure 102, in some examples, the network devices 104 can be part of the network infrastructure 102. In certain examples, networking devices deployed in the network infrastructure 102 (e.g., access points, controllers, routers, etc.) can be configured to implement the functionality of the network devices 104.

[0019] The network infrastructure 102 can be a small-scale device network or a large-scale device network. For example, a small-scale device network can be a home network. For example, a large-scale device network can be an organization, a university, a public facility space (e.g., a mall, an airport, a train station, a bus station, a stadium, etc.), or an office network that houses a large number of network devices. The network infrastructure 102 can span more than one site, such as rooms, floors of a building, a building, or any other space that can house network devices. The network infrastructure 102 can be a private network, such as a network that can include security and access controls to limit access to authorized users of the private network.

[0020] The network infrastructure 102 can include several devices that communicate with each other and / or with any external devices or systems external to the network infrastructure 102. In Figure 1 In the depicted example implementation, the network infrastructure 102 is shown to include wireless networking devices, such as access points APs 108A, 108B, and 108C (hereinafter collectively referred to as APs 108A-C); and one or more client devices, such as client device 110. In addition, in some examples, the network infrastructure 102 can optionally include a controller 114 that communicates with the external network 106. It should be noted that the examples presented herein are not limited by the details of the devices depicted in the middle (e.g., types and counts). In some examples, the APs 108A-C, the client device 110, and the controller 114 can be configured to communicate with other devices using wireless communication techniques specified in one or more Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard specifications. Figure 1

[0021] The wireless networking devices, such as the APs 108A-C, can act as access points to a local network established in the network infrastructure 102 and / or the external network 106 for any client devices in the network infrastructure 102. For example, in Figure 1 ​In the depicted implementation, client device 110 is shown as connected to AP 108A via wireless communication link 112. Thus, client device 110 can communicate with any other device (either internal to network infrastructure 102 or external to network infrastructure 102) via AP 108A. Wireless communication link 112 can be established in accordance with any IEEE 802.11 standard. In the following description, the AP to which client device 110 is currently connected, i.e., AP 108A, can be referred to as the source AP for client device 110.

[0022] A wireless networking device (e.g., any of APs 108A-C) can be a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to client devices 110. The wireless networking device can communicate with client devices in accordance with one or more IEEE 802.11 standard specifications. In some examples, APs 108A-C can be implemented with one or more radios to help APs 108A-C communicate with respective client devices and other wireless-capable devices. Each radio device can operate over a respective range of radio frequencies, referred to as a Wi-Fi band, such as a 2.4 GHz Wi-Fi band, a 5 GHz Wi-Fi band, a 6 GHz Wi-Fi band, etc.

[0023] Network 106 can be a public or private network such as the Internet, or another communication network that allows for connectivity between network infrastructure 102 and network devices 104. Network 106 can include third-party telecommunication lines, such as telephone lines, broadcast coaxial cables, fiber optic cables, satellite communications, cellular communications, etc. In some examples, network 106 can include any number of intermediary network devices, such as switches, routers, gateways, servers, and / or controllers, that are not directly part of network infrastructure 102, but that facilitate communication between various parts of network infrastructure 102 and between network infrastructure 102 and any other network connection entities.

[0024] The APs 108A, 108B, and 108C can communicate with the controller 114 over respective connections, such as connections 116A, 116B, and 116C, which can include wired and / or wireless interfaces. The controller 114 can provide communication to the network infrastructure 102 with the network 106, although it can not be the only point of communication with the network 106 for the network infrastructure 102. In some examples, the controller 114 can communicate with the network 106 through a router (not shown). In other implementations, the controller 114 can provide router functionality to devices in the network infrastructure 102. In some examples, the controller 114 can be a wireless local area network (WLAN) controller. The controller 114 can be operable to configure and manage network devices, such as at the network infrastructure 102, and can also manage network devices at other remote sites within the network infrastructure 102, if any. The controller 114 can be operable to configure and / or manage switches, routers, access points, and / or client devices connected to the network. The controller 114 itself can be an AP or provide the functionality of an AP.

[0025] Examples of client devices 110 can include desktop computers, laptop computers, servers, web servers, authentication servers, authentication-authorization-accounting (AAA) servers, domain name system (DNS) servers, dynamic host configuration protocol (DHCP) servers, Internet protocol (IP) servers, virtual private network (VPN) servers, network policy servers, mainframes, tablet computers, e-readers, netbook computers, televisions and similar monitors (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smart phones, virtual terminals, video game consoles, virtual assistants, Internet of Things (IoT) devices, and the like.

[0026] Some client devices can be portable and can move from one location to another within the network infrastructure 102. As will be appreciated, each of the APs 108A-C can provide wireless connectivity within a respective limited range, also referred to as a network coverage area. Within the network coverage area of a given AP, the signal strength from the given AP can be above a predetermined value. Thus, within its network coverage area, the given AP can provide good wireless connectivity to any client device. However, when a client device moves outside the network coverage area or reaches near the boundary of the network coverage area of its source AP, the signal strength from the source AP can decrease and the client device can start looking for other APs that can provide better wireless connectivity and initiate roaming. Roaming in Wi-Fi is the process of a mobile client device seamlessly switching from one wirelessly networked device (e.g., its source AP) to another (e.g., a roaming target) as its user moves from one location to another within a wireless network.

[0027] In accordance with Wi-Fi standards, the APs 108A-C can use R0 or R1 keys to implement secure association of client devices. In particular, the R0 key can be used for security during initial association of a client device in a given mobility domain. A mobility domain can be a set of APs that form a contiguous RF space. In Figure 1 In an example implementation, the APs (such as the APs 108A, 108B, and 108C) deployed in the network infrastructure 102 can define a contiguous RF space and thus form a mobility domain. In one example, the APs in the network infrastructure 102 can be arranged such that the network infrastructure 102 can be a single mobility domain. Thus, when the client device 110 first connects with the AP 108A, for example, in the mobility domain, the AP 108A can use the R0 key to protect authentication and association frames during initial association of the client device 110 within the mobility domain. Other APs (e.g., the APs 108B and 108C) can use the R1 key for security during re-association of the client device 110.

[0028] To enable faster roaming, generally, the APs in the RF neighborhood (hereinafter referred to as direct RF neighbors) of the source AP can pre-receive the R1 key corresponding to a client device connected to the source AP. In particular, for a given AP, the direct RF neighbors are the APs from which the received signal strength from the given AP is greater than a predetermined threshold. For example, in Figure 1In the implementation of FIG. 1 , AP 108B is a direct RF neighbor of source AP 108A because it is within the RF neighborhood 111 of source AP 108A. On the other hand, AP 108C is a non-RF neighbor for source AP 108A. For illustrative purposes, RF neighborhood 111 is marked with a dashed outline representing an RF boundary where the received signal strength from a given AP 108A may be greater than a predetermined threshold.

[0029] In some cases, the movement of a client device within a given mobility domain can be sudden and / or random. For example, a client device may roam to an AP that is not a direct RF neighbor of its source AP. For example, a user may move between floors, such as by taking an elevator to attend a meeting, or move to an area like a cafeteria that is served by another AP that is not a direct RF neighbor of the source AP. In other implementations, such as university deployments, a user may shut down their laptop and move to another classroom served by an AP that is not a neighbor of the client device's source AP. Conventional solutions may not pre-populate useful roaming provisioning credentials to such non-RF neighbors.

[0030] To this end, the network device 104 can assist certain APs that are potential roaming targets with the necessary roaming provisioning credentials to enable fast roaming, even when the AP to which the client device has roamed is not a direct RF neighbor of its source AP. The network device 104 can be deployed in a public, private, or hybrid cloud outside the network infrastructure 102. In some examples, the network device 104 can be implemented as one or more computing systems, such as computers, controllers, servers, or storage systems. In some examples, the network device 104 can be an electronic device with hardware processing resources, such as one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions (e.g., roaming management instructions 120). In some other examples, the network device 104 can be implemented as a software resource, such as a software application, a virtual machine (VM), a container, a containerized application, or a container group (pod). In some examples, the network device 104 can be implemented as a service running on a "cloud computing" environment or as "software as a service" (SaaS). The network device 104 and / or the functionality implemented via the network device 104 may be provided as a standalone product / service or a packaged solution that may be used on a one-time complete product / solution purchase or on a pay-per-use basis. Figure 1In certain other examples not shown, the network device 104 can be deployed within the network infrastructure 102. In such implementations, the network device 104 can be connected to the controller 114 or the APs 108A-C. In some other examples, the controller 114 itself can be configured to implement the functionality of the network device 104.

[0031] According to examples presented herein, the network device 104 can host a roaming management system 118 by processing resources of the network device 104 executing roaming management instructions 120 stored in a machine-readable medium of the network device 104. For illustrative purposes, the roaming management system 118 and the roaming management instructions 120 are represented by dashed outlines, as they represent digital entities that can be in the form of data and / or instructions executable by physical processing resources (e.g., processors). By executing the roaming management instructions 120, the roaming management system 118 can identify a correct set of roaming targets to which a client device can be provided with roaming credentials before it roams to any such roaming target. Specifically, the proposed network device 104 leverages a machine learning (ML) model built based on historical roaming patterns within the network infrastructure 102 to reason about future roaming events in the network infrastructure 102. Specifically, the roaming management system 118 can identify a set of roaming targets including non-RF neighbors (if any) to which a client device can roam, and pre-provision such non-RF neighbors with useful roaming provisioning credentials to enable fast roaming of the client device. For example, by building the ML model based on past roaming behavior and patterns, Rl keys can be intelligently pre-populated to non-RF neighbors, such as the AP 108C. In conjunction with the Figure 3 Additional details about the example network device and the example roaming management system are described in conjunction with a block diagram of

[0032] An example roaming scenario in the networking system 100 is described in conjunction with a message flow diagram of Figure 2 The depicted message flow diagram 200 illustrates an example sequence of events and communications between various components in the networking system 100. Figure 2

[0033] ​During sequence 202, the client device 110 initiates association with the AP 108A by sending a connection request to the AP 108A. The association at sequence 202 can be the first association of the client device in the mobile domain of the network infrastructure 102. Upon successful authentication of the AP 108A, the client device 110 is associated with the AP 108A. To authenticate the client device 110, the AP 108A derives an R0 key associated with the client using a pairwise master key (PMK). After successful authentication of the client device 110, the AP 108A can encrypt the R0 key at sequence 204. Further, at sequence 206, the AP 108A can send a key update message to the network device 104. In some examples, the key update message can specify the encrypted R0 key and radius attributes, such as a virtual local area network (VLAN) identifier of the client device 110.

[0034] Further, at sequence 208, the network device 104 can update a key store (e.g., a key cache) by storing the R0 key reported by the AP 108A. In some examples, the network device 104 can also update other attributes, such as the VLAN identifier in a respective data store in the network device 104. Further, at sequence 210, the network device 104 can identify roaming targets for the client device 110. In one example, the network device 104 can determine roaming targets that can include direct RF neighbor APs or non-RF neighbor APs. In one example, the network device can store a list of RF neighbor APs for each of the APs 108A-C in RF neighbor data and retrieve the data when needed. For each of the APs 108A-C, the network device 104 can determine respective RF neighbor APs based on wireless signal strength. Further, the network device 104 can identify non-RF neighbor APs based on historical roaming behavior of client devices in the network infrastructure 102. Specifically, the network device 104 can use one or more ML models developed based on learning from past roaming events to infer non-RF neighbor APs. Additional details on how the network device 104 can identify roaming targets are described in connection with the methods described in Figure 4 and Figure 5 Additional details on how the network device 104 can identify roaming targets are described in connection with the methods described in

[0035] Further, at sequence 212, the network device 104 can determine roaming provisioning credentials (e.g., R1 keys) for each of the roaming targets identified at sequence 210. Additional details on how the network device 104 can determine roaming provisioning credentials are described in connection with the methods described in Figure 4 and Figure 5The methods described in the middle can be used to describe additional details on how the network device 104 can identify the determined roaming target for the roaming provisioning credential. After determining the roaming provisioning credential, at sequence 214, the network device 104 can transmit the roaming provisioning credential to the respective roaming targets. For example, the roaming provisioning credential can be sent to each of the RF neighbor AP(s) (e.g., AP 108B) and non-RF neighbor AP(s) (e.g., AP 108C) that are identified as roaming targets. Thus, not only direct RF neighbor APs but also non-RF neighbor APs that are identified as roaming targets will receive the roaming provisioning credential needed for the client device re-association.

[0036] At sequence 216, the client device 110 can move into the network coverage area of AP 108C and initiate a roaming procedure by sending a re-association request. Sequence 216 can represent the client device 110 physically moving into the network coverage area of AP 108C. As Figure 1 As depicted, AP 108C is not a direct RF neighbor of AP 108A. However, since the network device 104 has identified AP 108C as a potential roaming target due to the machine learning of past roaming events, the roaming provisioning credential (e.g., Rl key) corresponding to the client device 110 has been provisioned to AP 108C. Thus, at sequence 218, AP 108C can also quickly authenticate the client device 110 and negotiate a roaming session using the respective Rl key. Specifically, during this re-association procedure, AP 108C can establish a roaming session with AP 108A (e.g., the source AP for the client device 110) via an intermediary networking device such as a network switch (not shown) or controller 114. For example, AP 108C can send a session request to the intermediary networking device, which in turn passes the session request to AP 108A. AP 108A can then send a session response to AP 108C. Upon receiving the session response from AP 108A, AP 108C can complete the re-association of the client device 110. At sequence 220, AP 108C can notify the network device 104 of the successful authentication and association of the client device 110 with AP 108C.

[0037] As will be appreciated, the network device 104 can also identify roaming targets corresponding to the new source AP (i.e., AP 108C) and pre-populate Rl keys on them to enable future fast roaming of client devices associated with AP 108C.

[0038] Reference is now made to Figure 3 a block diagram of an example network device 300 is presented. Figure 3 The network device 300 of Figure 1of the network devices 104. In certain examples, the network device 300 can be implemented as a controller, such as Figure 1 of the network infrastructure 102. Specifically, the network device 300 is configured to manage roaming of client devices within a network infrastructure (e.g., Figure 1 of the network infrastructure 102). More specifically, the network device 300 is configured to pre-populate roaming provisioning credentials on the correct set of roaming targets prior to a client device roaming onto it to enable fast roaming. In some examples, to enable this distribution of roaming provisioning credentials, the network device 300 implements a roaming management system 306. For illustrative purposes, the roaming management system 306 and items within the roaming management system 306 are represented by dashed outlines as they represent digital entities that can be in the form of data and / or instructions executable by a physical processing resource (e.g., the processing resource 302).

[0039] The network device 300 can include a processing resource 302 and / or a machine-readable storage medium 304 for the network device 300 to perform a number of operations that will be described in greater detail below.

[0040] The processing resource 302 can be a physical device, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), other hardware devices capable of retrieving and executing instructions stored in the machine-readable storage medium 304, or a combination thereof. In one example, the processing resource 302 can fetch, decode, and execute instructions stored in the machine-readable storage medium 304 to manage roaming of client devices. As an alternative or in addition to executing instructions, the processing resource 302 can include at least one integrated circuit (IC), control logic, electronic circuits, or a combination thereof that includes a number of electronic components for performing functions intended to be performed by the network device 300.

[0041] The machine-readable storage medium 304 can be non-transitory and is alternatively referred to as non-transitory machine-readable storage medium that does not encompass a transitory propagating signal. The machine-readable storage medium 304 can be any electronic, magnetic, optical, or other type of storage device capable of storing data and / or executable instructions. Examples of the machine-readable storage medium 304 can include RAM, NVRAM, EEPROM, storage drives (e.g., SSD or HDD), flash memory, etc. The machine-readable storage medium 304 can be encoded with a roaming management system 306 that helps manage roaming of client devices from one AP to another AP in a network infrastructure. The roaming management system 306 includes program data 308 and program instructions 310 to manage roaming of client devices.

[0042] Program data 308 may store various data that may be received, used, and / or generated by processing resource 302 when processing resource 302 executes program instructions 310. By way of example, program data 308 includes information regarding roaming events, roaming datasets, ML models, roaming provisioning credentials, information regarding roaming targets, including RF neighbor APs and non-RF neighbor APs, and / or training datasets. Each of these different types of data may be stored in a common data store within program data 308 or in corresponding separate data stores. In some other examples, one or more types of data may be combined and stored in the combined data store. In one example, processing resource 302 may store roaming events received from APs (e.g., APs 108A through 108C) in program data 308. Furthermore, processing resource 302 may store roaming datasets generated based on roaming events in program data 308. Furthermore, processing resource 302 may store one or more ML models within program data 308 that processing resource 302 may train and use to infer various roaming targets. Furthermore, processing resource 302 may store roaming provisioning credentials, such as an R1 key, in program data 308. Furthermore, processing resource 302 may store information about RF neighbor APs for each of the APs deployed in the network infrastructure in program data 308. Additionally, processing resource 302 may store a list of roaming targets (e.g., non-RF neighbor APs identified as roaming targets) for the APs in the network infrastructure in program data 308. Furthermore, processing resource 302 may store a training dataset including a plurality of training roaming events in program data 308.

[0043] According to an example consistent with the present disclosure, the network device 300 may execute a roaming management system 306 by a processing resource 302 executing program instructions 310 to manage roaming of a client device from one AP to another AP in the network infrastructure. Specifically, in some examples, the processing resource 302 may execute one or more program instructions 310 to perform a roaming management system 306 in conjunction with Figure 4 and Figure 5The described method steps. For example, the program instructions 310 can include instructions 312, 314, 316, and 318. Specifically, the instructions 312, when executed by the processing resource 302, can cause the processing resource 302 to access, from the program data 308, a ML model constructed based on a dataset characterizing past roaming of client devices among APs in a network infrastructure. Further, the instructions 314, when executed by the processing resource 302, can cause the processing resource 302 to identify, using the ML model, a first set of roaming targets including one or more non-RF neighbor APs corresponding to a source AP. Further, the instructions 316, when executed by the processing resource 302, can cause the processing resource 302 to determine first roaming provisioning credentials for the first set of roaming targets. Further, the instructions 318, when executed by the processing resource 302, can cause the processing resource 302 to transmit the first roaming provisioning credentials to the first set of roaming targets prior to the client device roaming to any roaming target in the first set of roaming targets. Although not shown, in some examples, the machine-readable storage medium 304 can be encoded with certain additional executable instructions to perform any other operations performed by the network device 300 without limiting the scope of the present disclosure.

[0044] Now turning to Figure 4 and Figure 5 a flowchart of an example method for managing roaming of client devices is presented. Figure 4 and Figure 5 The steps shown in Figure 1 the network device 104 or the controller 114 of Figure 3 or the network device 300 of In some examples, an appropriate device can include a processing resource adapted to retrieve and execute instructions stored in a machine-readable storage medium. The processing resource and the machine-readable storage medium can be example representatives of the processing resource 302 and the machine-readable storage medium 304 of the network device 300. As an alternative or in addition to retrieving and executing instructions, the processing resource can include one or more electronic circuits including electronic components, such as FPGAs, ASICs, or other electronic circuits, to perform the functionality of one or more instructions.

[0045] Figure 4 An example method 400 for managing roaming of client devices (e.g., the client device 110 of Figure 1 in a network infrastructure (e.g., the network infrastructure 102 of Figure 1 is depicted.

[0046] At step 402, a network device (e.g., the network device 104 of Figure 1 or the controller 114 of Figure 3network device 300) can access a machine learning (ML) model. The machine learning model is constructed based on historical roaming patterns of client devices in the network infrastructure. More specifically, the ML model is developed based on a dataset (hereinafter referred to as a roaming dataset) that characterizes past roaming of client devices among APs (e.g., APs 108A-C) in the network infrastructure. For example, each AP can report roaming events to the network device. For a given client device, a roaming event can specify information associated with its source AP, target AP, timestamp of roaming, and the like. For example, a roaming event can specify one or more of: an identifier of the respective source AP, an identifier of the target AP, a timestamp of the roaming event, a media access control (MAC) address of the given client device, or a device type of the given client device. The identifiers of the source and target APs can be one or more of: respective device names, Internet Protocol (IP) addresses, or MAC addresses of the source and target APs. In one example, the device type of the client device can represent an operating system (e.g., “Android” or “iOS”) that is executed on the client device. Syntax 1 presented below describes an example roaming event that specifies one or more of the above-listed information.

[0047] {

[0048] "Client MAC":"11:22:33:44:55:66",

[0049] "Device Type":"iOS",

[0050] "Source AP":"AP1",

[0051] "Target AP":"AP2",

[0052] "Time of Day":"11AM"

[0053] }

[0054] Syntax 1 - Example Roaming Event

[0055] The roaming event described in Syntax 1 represents a roaming scenario in which a client device with MAC address 11:22:33:44:55:66 and device type - “iOS” roamed from a source AP (with device name AP1) to a target AP (with device name AP2) at 11 AM. Likewise, the network device can receive many such roaming events from APs deployed in the network infrastructure, periodically or on a real-time basis. The roaming dataset can be a collection of all such roaming events reported by APs deployed in the network infrastructure. In conjunction with Figure 5 The method of describes additional details regarding the ML model.

[0056] Further, at step 404, the network device can use the ML model to identify the first set of roaming targets. Specifically, the network device can use the ML model to infer the first set of roaming targets for the client device associated with the source AP. For example, for a given time of day, the network device can predict one or more non-RF neighbor APs corresponding to the source AP as the first set of roaming targets. For example, based on the learning from the set of roaming data, the ML model can infer that a given client device currently associated with AP 1 can move to AP 3, which is not a direct RF neighbor of AP 1. Accordingly, AP 3 can be included in the first set of roaming targets.

[0057] Further, at step 406, the network device can determine the first set of roaming provisioning credentials for the first set of roaming targets. Specifically, the roaming provisioning credentials for a given roaming target in the first set of roaming targets can include a target encryption key, such as an Rl key conforming to the IEEE 802.1 Ir specification. The network device can compute the Rl key for the given roaming target in the first set of roaming targets based on a client encryption key corresponding to the client device and a respective basic service set identifier (BSSID) of the given roaming target. The client encryption key can be an R0 key used during the first association of the client device in the mobility domain.

[0058] Once the first set of roaming provisioning credentials is determined, at step 408, the network device can transmit the first set of roaming provisioning credentials to the first set of roaming targets prior to the client device roaming to any roaming target in the first set of roaming targets. This prior transmission of the Rl key to the non-RF neighbor APs can allow the non-RF neighbor APs to quickly authenticate the client device, thereby providing seamless network connectivity and improving user experience.

[0059] Reference is now made to Figure 5 , a flowchart of another example method 500 for managing roaming of a client device (e.g., client device 110 of Figure 1 ) in a network infrastructure (e.g., network infrastructure 102 of Figure 1 ) is presented. In contrast to Figure 4 , method 500 of Figure 5 may include certain additional steps and / or information. Further, for brevity, certain details of steps already described in Figure 4 are not repeated here.

[0060] At step 502, the network device can receive roaming events from APs deployed in the network infrastructure. Each of the APs deployed in the network infrastructure can report roaming events to the network device. In some examples, the APs can report roaming events to the network device on a real-time basis (i.e., immediately upon detecting that a client device has left its association with an AP and has connected to another AP). In some other examples, the APs can accumulate roaming events over a predetermined duration of time and send a collection of such roaming events to the network device. In certain examples, the APs can periodically send roaming events to the network device, either according to the network device’s requirements, or after a certain number of roaming events have been detected. A roaming event for a given client device (e.g., see Syntax 1) can specify information associated with its source AP, target AP, timestamp of the roam, etc. In some examples, the network device can store the roaming events received from the APs in program data such as program data 308 shown in Figure 3 FIG. 3.

[0061] Further, at step 504, the network device can generate a roaming dataset by combining and processing the roaming events reported by the APs. In some examples, the network device can access the roaming event data store and process the roaming data by filtering out irrelevant fields and retaining useful fields that help build the ML model. In certain examples, the network device can request the roaming dataset from an external source. In this case, the APs can report roaming events to such external source, and the external source can be responsible for generating the roaming dataset from the reported roaming events. In some examples, the network device can store the roaming dataset in program data such as program data 308 shown in Figure 3 FIG. 3.

[0062] Once the roaming dataset is generated or obtained, at step 506, the network device can extract model features from the roaming dataset. The selection of the model features can depend on what information the ML model is designed to reason and what parameters can help reason such information. In the present example, the ML model can be used to reason potential roaming targets for a given AP, specifically, non-RF neighbor APs to which a client device from the given AP can roam. Thus, in one example, model features such as a first device identifier of the source AP (hereinafter referred to as "source AP identifier"), a second device identifier of the target AP ("target AP identifier"), a roaming event time, a third device identifier of the client device (hereinafter referred to as "client identifier"), and a client device type (hereinafter referred to as "client device type") can be extracted. Since these model features include details about the client device (e.g., the third device identifier of the client device and the client device type), the resulting ML model can be trained to reason future roaming events for each client device. In particular, such model features can help the network device fine-tune the resulting ML model for a given device type (e.g., iOS, Android, etc.).

[0063] In some other examples, when selecting the model features, information specific to the client device can be omitted to build a client device-agnostic ML model. In such implementations, the model features can include the source AP identifier, the target AP identifier, and the roaming event time. Since these model features do not include details about the client device, the resulting ML model can be trained to reason future roaming events for the AP. Thus, such a ML model can be used to reason potential roaming targets for a given AP, which would find all APs to which a client device associated with the given AP can roam.

[0064] After extracting the model features, at step 508, the network device can build the ML model. To build the ML model, the network device can be configured to select a candidate ML model from various models such as supervised learning models, unsupervised learning models, reinforcement learning models, neural networks, decision trees, support vector machines, long short-term memory (LSTM), etc. It can be noted that the examples presented herein do not limit the type of the ML model. The use of any appropriate type of ML model is contemplated within the scope of the present disclosure. The network device can store the selected ML model in program data such as program data 308 shown in FIG. 3. Figure 3

[0065] ​After selecting the ML model, at step 510, the network device can train the selected ML model during a learning phase. The learning phase can be a period of time after the ML model has been selected and before the ML model is deployed for real-time applications. In this learning phase, the model features can be adjusted using a training dataset to generate inferences. In some examples, the network device can receive a new training dataset and / or update a sample training dataset that has been stored during the learning phase from, for example, the program data 308 shown in FIG. 3. Figure 3 In one example, the training dataset store can be pre-configured with a sample training dataset. In another example, the network device can receive a new training dataset and / or update a sample training dataset that has been stored during the learning phase.

[0066] The training dataset can include training roam events. In examples where the ML model to be built is client-agnostic, the training roam events can not include client device specific details. For example, Syntax-2 presented below represents a first example training roam event without client device specific details.

[0067] {

[0068] "Source AP":"AP1",

[0069] "Target AP":"AP2", / / dependent or target variable

[0070] "Time of Day":"Time"

[0071] }

[0072] Syntax 2 - First example training roam event

[0073] In another example where the ML model is specific to a client device, the training roam events are designed to include client device specific details. For example, Syntax-2 presented below represents one such example training roam event without client device specific details.

[0074] {

[0075] "Client MAC":"11:22:33:44:55:66",

[0076] "Device Type":"iOS", / / or Android

[0077] "Source AP":"AP1",

[0078] "Target AP":"AP2", / / dependent or target variable

[0079] "Time of Day":"Time"

[0080] }

[0081] Syntax 3 - First example training roam event

[0082] In the learning phase, the model features are adjusted based on tens or hundreds of such training roam events to learn the patterns of roam behavior. This adjustment of the model features during the learning phase is referred to as a first fine-tuning of the model features.

[0083] Once the model parameters are adjusted, at step 512, the network device can evaluate the model performance. For example, the network device can test the performance of the model against metrics such as accuracy, precision, recall, F1 score, etc. In some examples, if any improvement in the model performance is needed, the network device can perform model training again (see step 510). In some examples, if the model performance is not satisfactory, the network device can go back to the model building step (see step 508) and select a new model, which can be trained (at step 510) to achieve the desired performance.

[0084] Once the ML model is trained, the learning phase ends, and the inference phase begins, where the network device can start using the ML model for real-time applications. For example, at step 514, the network device can infer a first set of roam targets including one or more non-RF neighbor APs based on the time of day and using the ML model. Specifically, the network device can use the ML model to identify a first set of roam targets including potential non-RF neighbor APs of a given source AP. For example, for a given time of day, the network device can predict one or more non-RF neighbor APs corresponding to the source AP as the first set of roam targets. In one example, for a given time of day, the network device can predict AP 108C as a non-RF neighbor AP of source AP 108A and include it in the first set of roam targets. Figure 1 Using the ML model and based on past roamings of the client device in the network infrastructure, the network device can identify AP 108C as a non-RF neighbor AP of source AP 108A and include it in the first set of roam targets. The network device can store information about the first set of roam targets (e.g., MAC address, AP name, IP address, etc.) in the program data 308 shown in FIG. 3. Figure 3

[0085] ​Further, at step 516, the network device can determine first roaming provisioning credentials for the first set of roaming targets. Specifically, the roaming provisioning credentials for a given roaming target in the first set of roaming targets can include a target encryption key, such as an Rl key conforming to the IEEE 802.1 Ir specification. The network device can compute the Rl key for the given roaming target in the first set of roaming targets based on a client encryption key corresponding to the client device and a corresponding basic service set identifier (BSSID) of the given roaming target. The client encryption key can be an R0 key used during the first association of the client device in the mobility domain. In some examples, the network device can store the first roaming provisioning credentials, such as the Rl keys for the first set of roaming targets, in program data of program data 308, such as Figure 3

[0086] Once the first roaming provisioning credentials are determined, at step 518, the network device can transmit the first roaming provisioning credentials to the first set of roaming targets prior to the client device roaming to any roaming target in the first set of roaming targets. This prior transmission of the Rl keys to the non-RF neighbor APs can allow the non-RF neighbor APs to quickly authenticate the client device, providing seamless network connectivity and improving user experience.

[0087] Further, in some examples, at step 520, the network device can fine-tune the model features again based on the reported roaming events during the inference phase. This fine-tuning of the model features during the inference phase is also referred to as a second fine-tuning of the model features, and can be performed using similar techniques described in connection with step 510.

[0088] Additionally, at step 522, in some examples, the network device can identify a second set of roaming targets including one or more RF neighbor APs of the source AP. In one example, the APs in the network infrastructure can report a list of their RF neighbors to the network device. In another example, the network device can obtain a list of RF neighbors for any given AP from an external entity. The external entity can be a service or device that can be used to identify and maintain a list of RF neighbor APs for APs deployed in the network infrastructure. In yet another example, the network device itself can identify RF neighbor APs for the APs deployed in the network infrastructure based on received signal strengths. For example, the network device can select one or more APs having a received signal strength indicator (RSSI) value greater than a threshold value at the source AP as RF neighbor APs of the source AP, and identify such RF neighbor APs as the second set of roaming targets. In one example, the network device stores the second set of roaming targets, such as the list of RF neighbor APs of the source AP, in program data of program data 308, such as Figure 3 ​The program data 308 shown in FIG maintains information (eg, MAC address, AP name, IP address, etc.) of a list of all RF neighbor APs (reported by the APs, obtained from an external entity, or self-identified).

[0089] Furthermore, at step 524, the network device may determine second roaming provisioning credentials for the second roaming target set. Specifically, the second roaming provisioning credentials may include an R1 key for each roaming target in the second roaming target set, the R1 key being determined based on a client encryption key corresponding to the client device and a corresponding basic service set identifier (BSSID) of the second roaming target set. In some examples, the network device may store the second roaming provisioning credentials, such as the R1 key for the second roaming target set, in a storage medium such as a server. Figure 3 In the program data of program data 308 shown in .

[0090] Once the second roaming provisioning credentials are determined, the network device may transmit the second roaming provisioning credentials to the second set of roaming targets before the client device roams to any roaming target in the second set of roaming targets at step 526. This prior transmission of the R1 key to the RF neighbor AP may allow the RF neighbor AP to quickly authenticate the client device, thereby providing seamless network connectivity and improving the user experience.

[0091] Figure 6 A block diagram of an example computing system 600 is depicted in which various examples described herein may be implemented. In one example, the computing system 600 may be configured as a Figure 1 The computing system 600 may be operated as a network device of the network device 104 and may perform various operations described in one or more of the previous figures. In another example, the computing system 600 may be any system in a possible infrastructure and capable of hosting the roaming management system described previously. Examples of devices and / or systems that may be implemented as the computing system 600 may include desktop computers, laptop computers, servers, web servers, authentication servers, AAA servers, DNS servers, DHCP servers, IP servers, VPN servers, network policy servers, mainframes, tablet computers, e-readers, netbook computers, televisions and similar monitors (e.g., smart TVs), content receivers, set-top boxes, PDAs, mobile phones, smart phones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, IoT devices, and the like.

[0092] The computing system 600 can include a bus 602 or other communication mechanism for communicating information, a hardware processor 604, also referred to as a processing resource, coupled with the bus 602 for processing information, and a machine-readable storage medium 605 coupled to the bus 602 for storing information and instructions to be executed by the processing resource 604. In some examples, the processing resource 604 can include one or more CPUs, semiconductor-based microprocessors, and / or other hardware devices suitable for retrieval and execution of instructions stored in the machine-readable storage medium 605. The processing resource 604 can fetch, decode, and execute instructions to configure an MLO for an SSID. As an alternative or in addition to retrieving and executing instructions, the processing resource 604 can include one or more electronic circuits that include electronic components for performing the functionality of one or more instructions, such as an FPGA, ASIC, or other electronic circuit.

[0093] In some examples, the machine-readable storage medium 605 can include a main memory 606, such as a RAM, cache, and / or other dynamic storage devices, coupled with the bus 602 for storing information and instructions to be executed by the processing resource 604. The main memory 606 can also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processing resource 604. Such instructions can be stored in a storage medium accessible to the processing resource 604, which makes the computing system 600 a special-purpose machine that is customized to perform the operations specified in the instructions. The machine-readable storage medium 605 can also include a read-only memory (ROM) 608 or other static storage device coupled with the bus 602 for storing static information and instructions for the processing resource 604. Furthermore, a storage device 610, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), among others, can be provided and coupled to the bus 602 for storing information and instructions.

[0094] In some examples, the bus 602 of the computing system 600 can be coupled with a display 612, such as a liquid crystal display (LCD) (or touch-sensitive screen), for displaying information to a computer user. In some examples, an input device 614, including alphanumeric and other keys (physical or software generated and displayed on a touch-sensitive screen), can be coupled to the bus 602 for communicating information and command selections to the processing resource 604. Furthermore, in some examples, another type of user input device 616, such as a cursor control 616, can be connected to the bus 602. The cursor control 616 can be a mouse, trackball, or cursor direction keys. The cursor control 616 can communicate direction information and command selections to the processing resource 604 for implementing movement of a cursor on the display 612. In some other examples, the same direction information and command selections as the cursor control can be implemented via receiving touches on a touch screen without a cursor.

[0095] In some examples, the computing system 600 can include a user interface module implementing a GUI that can be stored in mass storage device as executable software code executed by the computing device(s). This and other modules can include components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, steps, subroutines, program code segments, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

[0096] The computing system 600 also includes a network interface 618 coupled to bus 602. Network interface 618 provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, network interface 618 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface 618 can be a local area network (LAN) card or wireless communication unit (e.g., Wi-Fi chip / module).

[0097] In some examples, the machine-readable storage medium 605 (e.g., one or more of main memory 606, ROM 608, or storage 610) stores instructions 607 (labeled with a dashed outline) that, when executed by the processing resource 604, can cause the processing resource 604 to perform one or more of the methods / operations described above. The instructions 607 can be stored on any memory within main memory 606, ROM 608, or storage 610. In some examples, the instructions 607 can be distributed across one or more of main memory 606, ROM 608, or storage 610. In some examples, the instructions 607, when executed by the processing resource 604, can cause the processing resource 604 to perform one or more of the methods described in any of Figure 4 and Figure 5 In some examples, the machine-readable storage medium 605 (e.g., one or more of main memory 606, ROM 608, or storage 610) stores instructions 607 (labeled with a dashed outline) that, when executed by the processing resource 604, can cause the processing resource 604 to perform one or more of the methods / operations described above. The instructions 607 can be stored on any memory within main memory 606, ROM 608, or storage 610. In some examples, the instructions 607 can be distributed across one or more of main memory 606, ROM 608, or storage 610. In some examples, the instructions 607, when executed by the processing resource 604, can cause the processing resource 604 to perform one or more of the methods described in any of

[0098] Unless otherwise explicitly stated, the terms and phrases used herein, and variations thereof, should be interpreted as open ended as opposed to limiting. As used herein, the term "include" and / t or "comprise" and variations thereof are intended to be equivalent to the term "comprising" and are therefore to be open-ended, not limiting. The terms "example" and "exemplary" are used to provide example instances of the item in discussion, not an exhaustive or limiting list thereof. The terms "a" or "an" are understood to mean "one or more" unless explicitly stated otherwise. In some cases, the presence of a widening word or phrase, such as "one or more," "at least,” “but not limited to,” or other similar phrase, should not be construed as implying that a narrower case is intended or required where such widening phrase can not be present. In addition, the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated items. It will be understood that, although the terms first, second, third, etc. can be used herein to describe various elements, these elements should not be limited by these terms since such terms are only used to distinguish one element from another unless otherwise stated or indicated by context.

Claims

1. A method comprising: accessing, by a network device, a machine learning (ML) model constructed based on a dataset characterizing past roaming of client devices among access points (APs) in a network infrastructure; identifying, by the network device, a first set of roaming targets using the ML model, the first set of roaming targets comprising one or more non-radio frequency (RF) neighbor access points (APs corresponding to a source AP of a client device in the network infrastructure; determining, by the network device, first roaming provisioning credentials for the first set of roaming targets; and transmitting, by the network device, the first roaming provisioning credentials to the first set of roaming targets before the client device roams to any roaming target in the first set of roaming targets.

2. The method of claim 1, wherein the dataset comprises information corresponding to a plurality of roaming events, wherein for a given one of the client devices, a roaming event specifies one or more of: an identifier of a respective source AP, an identifier of a target AP, a timestamp of the roaming event, a media access control (MAC) address of the given client device, or a device type of the given client device.

3. The method of claim 1, further comprising: extracting model features based on the dataset, wherein the model features comprise one or more of: a first device identifier of a source AP, a second device identifier of a target AP, a roaming event time, a third device identifier of the client device, or a client device type; and training the ML model using the dataset during a learning phase. first-tuning the model features during the learning phase. inference, during an inference phase, of the one or more non-RF neighbor APs based on a time of day and using the ML model.

4. The method of claim 3, wherein the training the ML model comprises: second-tuning, by the network device, the model features based on reported roaming events during the inference phase.

5. The method of claim 4, wherein identifying the first set of roaming targets comprises: computing the target encryption key for each roaming target in the first set of roaming targets based on a client encryption key corresponding to the client device and a respective basic service set identifier (BSSID) of the first set of roaming targets.

6. The method of claim 5, further comprising:

8. The method of claim 7, wherein the client encryption key is an R0 key and the target encryption key is an Rl key, the R0 key and the Rl key being specified in the Institute of Electrical and Electronics Engineers (IEEE) 802.11r specification.

7. The method of claim 1, wherein the first roaming provisioning credential corresponding to the client device comprises a target encryption key, and wherein determining the first roaming provisioning credential corresponding to the client device comprises:

9. The method of claim 1, further comprising: identifying, by the network device, a second set of roaming targets comprising one or more RF neighbor APs of the source AP; determining, by the network device, second roaming provisioning credentials for the second set of roaming targets; and transmitting, by the network device, the second roaming provisioning credentials to the second set of roaming targets before the client device roams to any roaming target in the first set of roaming targets. selecting, as the second set of roaming targets, one or more APs having a received signal strength indicator (RSSI) value at the source AP that is greater than a threshold value.

11. A network device comprising: ​ 10. The method of claim 9, wherein identifying the second set of roaming targets comprises: ​ ​ a machine-readable storage medium storing executable instructions; and a processing resource coupled to the machine-readable storage medium and configured to execute one or more of the instructions to: access a machine learning, ML, model constructed based on a dataset characterizing past roaming of client devices between access points, APs, in a network infrastructure; use the ML model to identify a first set of roaming targets including one or more non-radio frequency, RF, neighbor access points, APs, corresponding to a source AP of a client device in the network infrastructure; determine first roaming provisioning credentials for the first set of roaming targets; and transmit the first roaming provisioning credentials to the first set of roaming targets prior to the client device roaming to any roaming target in the first set of roaming targets.

12. The network device of claim 11, wherein the dataset includes information corresponding to a plurality of roaming events, wherein for a given one of the client devices, a roaming event specifies one or more of: an identifier of a respective source AP, an identifier of a respective target AP, a timestamp of the roaming event, a media access control, MAC, address of the given client device, or a device type of the given client device.

13. The network device of claim 12, wherein the processing resource is configured to execute one or more of the instructions to train the ML model using the dataset during a learning phase. To train the ML model, the processing resource is configured to execute one or more of the instructions to first fine-tune model features derived based on the plurality of roaming events, wherein the model features include one or more of: a first device identifier of the source AP, a second device identifier of a target AP, an event time, a third device identifier of the client device, or a client device type.

14. The network device of claim 13, wherein, 15. The network device of claim 14, wherein the processing resource is configured to execute one or more of the instructions to: infer, during an inference phase, the one or more non-RF neighbor APs based on a time of day and using the ML model; and second fine-tune the model features based on reported roaming events during the inference phase.

16. The network device of claim 11, wherein the processing resource is configured to execute one or more of the instructions to: identify a second set of roaming targets including one or more RF neighbor APs of the source AP; determine second roaming provisioning credentials for the second set of roaming targets; and transmit the second roaming provisioning credentials to the second set of roaming targets prior to the client device roaming to any roaming target in the first set of roaming targets. ​ 17. The network device of claim 16, wherein the processing resource is configured to execute one or more of the instructions to select one or more APs having a received signal strength indicator (RSSI) value at the source AP greater than a threshold value as the second set of roam targets.

18. A networking system comprising: a plurality of access points (APs) including a source AP that facilitates wireless connectivity of a client device to a network infrastructure; and a network device communicatively coupled to the plurality of APs, wherein the network device is configured to: access a machine learning (ML) model constructed based on a dataset characterizing past roamings of the client device among the plurality of APs in the network infrastructure; use the ML model to identify a first set of roam targets including one or more non-radio frequency (RF) neighbor APs corresponding to the source AP; determine first roam provisioning credentials for the first set of roam targets; and transmit the first roam provisioning credentials to the first set of roam targets prior to the client device roaming to any of the first set of roam targets, wherein a roam target in the first set of roam targets uses a respective one of the first roam provisioning credentials to authenticate the client device when the client device associates with the roam target.

19. The networking system of claim 18, wherein the network device is configured to: identify a second set of roam targets including one or more RF neighbor APs of the source AP; determine second roam provisioning credentials for the second set of roam targets; and transmit the second roam provisioning credentials to the second set of roam targets prior to the client device roaming to any of the first set of roam targets.

20. The networking system of claim 18, wherein the network device is further configured to: first fine-tune model features derived based on the dataset; infer, during an inference phase, the one or more non-RF neighbor APs based on the time of day and using the ML model; and second fine-tune the model features based on reported roam events during the inference phase.

Images