Roaming test system based on a single physical access point

Abstract

The present disclosure relates to a single physical access point based roaming test system. Examples provide a new roaming test system for network deployments that can be implemented remotely using a single physical AP. Examples achieve this elegant system by using a VAP group provided on a single physical AP (VAP can refer to a logical or virtual AP instance on a physical AP). Each VAP of the VAP group can be configured to represent a physical AP of a physical network deployment (such a network deployment can be a prospective deployment or, an actual / installed deployment). Examples can emulate / simulate physical movement of a wireless client between the physical APs of a network deployment by changing the transmission power associated with each VAP as a function of time in a manner that reflects how the wireless client would perceive changes in transmission power for the physical APs (represented by the VAPs) of the network deployment as the wireless client moves geographically across the sites of the network deployment.

Description

Background Technology

[0001] A wireless access point (referred to as a "physical AP" in this document) is a network device that allows wireless client devices to connect to a wireless local area network (WLAN). Enterprise deployments (i.e., network deployments of one or more WLANs spanning a large geographical area, often associated with a single business / enterprise, such as large corporate offices, airports, hospitals, etc.) involve multiple physical APs strategically distributed throughout the enterprise. Enterprise deployments generally require multiple physical APs because the strength of the wireless signals transmitted and received by a physical AP decreases as the wireless signal propagates through space (a phenomenon sometimes referred to as path loss or transmission power loss). In other words, due to path loss, a given physical AP will have a limited range of usability. Therefore, enterprise deployments utilize multiple physical APs located in different physical locations to effectively cover / support a larger physical area of ​​the enterprise.

[0002] Roaming occurs when a wireless client device moves outside the range of a physical access point (AP) and connects to another physical AP. Attached Figure Description

[0003] This disclosure is described in detail with reference to the following figures, based on one or more various examples. The figures are provided for illustrative purposes only and describe only typical or exemplary cases.

[0004] Figure 1 The illustration shows an example network deployment.

[0005] Figure 2 yes Figure 1 The accompanying diagram illustrates a schematic representation of a physical AP in a multi-VAP configuration.

[0006] Figure 3 An example roaming test system is described, illustrating various examples of the technology according to this disclosure.

[0007] Figure 4 Example workflows that can be used in conjunction with the user interface of a roaming test system are described, based on various examples of the technology according to this disclosure.

[0008] Figure 5 An example diagram illustrating the automatic clockwise roaming of virtual access point (VAP) groups, illustrating various examples of the technology according to this disclosure.

[0009] Figure 6 yes Figure 5 The accompanying diagram illustrates an example graph of physical roaming within the illustrated network deployment.

[0010] Figure 7 Example computing systems that can be used to perform roaming scene tests using VAP groups are described, based on various examples of the technology disclosed herein.

[0011] Figure 8 A block diagram of an example computer system in which aspects of the examples described herein can be implemented is provided.

[0012] These figures are not exhaustive and do not limit this disclosure to the precise form disclosed. Detailed Implementation

[0013] With the rapid adoption of trends such as Bring Your Own Device (BYOD), a seamless roaming experience for wireless client devices is essential in enterprise deployments. Therefore, a reliable system is crucial for testing roaming scenarios within enterprise (and other WLAN) deployments.

[0014] Many traditional roaming test systems rely on the physical movement of humans or robots between physical APs deployed in a network to test / simulate roaming scenarios within the network deployment. While this manual process is generally effective, it is costly and time-consuming, especially for testing larger network deployments (e.g., enterprise deployments spanning large geographic sites). Furthermore, because these systems depend on physical resources (i.e., humans or robots) for the physical movement between deployed physical APs, they are difficult / impossible to implement remotely and generally lack scalability. This is also because: (a) the physical movement resource (i.e., humans or robots) must be present at the geographic site during testing; and (b) multiple physical APs in the network deployment must actually be installed / deployed at the geographic site.

[0015] Other existing roaming test systems (which do not require physical resource movement between physical APs) use expensive hardware / test equipment to test / simulate roaming scenarios to modify the transmission power of the physical APs deployed in the network. To implement these systems, expensive (and not easily portable) physical resources (e.g., attenuators, RF shielding boxes, power supplies, cabling, test benches and other test equipment, lab space, etc.) must be located at the geographic site of the network deployment during testing. Correspondingly, these systems rely on multiple physical APs actually installed / deployed at the geographic site. Therefore, like the other conventional systems mentioned above, these systems are difficult / impossible to implement remotely and generally lack scalability.

[0016] As mentioned above, traditional roaming testing systems typically: (a) have high installation and implementation costs; (b) are difficult / impossible to implement remotely; (c) are not easily scalable; and (d) require the actual installation / deployment of multiple physical APs to fully test roaming scenarios. Regarding point (d), traditional roaming testing systems are largely unable to test / troubleshoot the intended network deployment (i.e., the planned network deployment that has not yet been installed / deployed) without its actual installation / deployment prior to testing. This can lead to time delays and increased costs, especially when network administrators want to test multiple intended network deployments before selecting the deployment for final delivery.

[0017] Against this backdrop, the examples of the technology disclosed herein provide a novel roaming test system for network deployments that can be remotely implemented using a single physical AP. The examples simulate this elegant system by using a group of VAPs provided on a single physical AP to mimic a physical network deployment (as used herein, a VAP can refer to a logical or virtual AP instance on a physical AP). Each VAP in the VAP group can be configured to represent a physical AP in the physical network deployment (such a network deployment can be a planned deployment or an actual / installed deployment). The examples simulate / mock the physical movement of a wireless client between physical APs in a network deployment by varying the transmission power associated with each VAP as a function of time, in a manner that reflects how the wireless client will perceive changes in transmission power for each physical AP (represented by a VAP) in the network deployment as it moves across geographic sites within the network deployment.

[0018] Using VAPs and the technologies described above, the example provides a roaming testing system that allows a user / network administrator to: (1) configure a VAP group to simulate a physical AP deployed in a (physical) network; (2) configure roaming parameters for the VAP group (e.g., roaming type, security operation mode, roaming trigger, etc.); (3) perform a roaming scenario test using the VAP group based on the configured roaming parameters (as described above, this roaming scenario test can simulate a physical roaming scenario test deployed in the network); and (4) display the results of the roaming scenario test.

[0019] It should be understood here that using a VAP of a single physical AP to test / simulate physical roaming scenarios is an extremely unconventional application of VAPs. VAPs are conventionally used to broadcast multiple WLANs from a single physical AP (or from each of multiple physical APs). In other words, VAPs of the same physical AP are conventionally used to broadcast multiple WLANs from the same physical location (with the same / similar range of availability). Therefore, wireless clients will not physically roam between VAPs of the same physical AP. Instead, a transition from one VAP to another (of the same physical AP) will be a transition from one WLAN to another. Therefore, associating a transition from one VAP to another with physical / mobile-based roaming is unusual / unconventional. Therefore, in order to test / simulate physical roaming scenarios using a group of VAPs of the same physical AP, the technical examples of this disclosure (1) shift the traditional concept of physical / mobile-based roaming from the spatial domain to the temporal domain; and (2) change the conventional use / configuration of VAPs.

[0020] For example, the example can simulate the physical movement of a wireless client between physical APs deployed in a network by varying the transmission power per VAP as a function of time, in a way that reflects how the wireless client perceives the change in transmission power per physical AP (represented by VAP) as it moves within a geographic site deployed in the network. Therefore, the example utilizes the concept of "clockwise roaming" / clock movement to simulate "physical roaming" / spatial movement.

[0021] The example also alters the conventional use / configuration of VAPs. Specifically, the example configures VAPs in a public VAP group to broadcast the same WLAN / SSID (as will be described in more detail below, in some cases the example may configure multiple VAP groups, each configured to broadcast a unique / different WLAN / SSID). Conventionally, this configuration is illogical because VAPs are specifically designed to allow a single physical AP to broadcast multiple / different WLAN / SSIDs. However, since the examples of the technology disclosed herein utilize a single physical AP's VAP in an unconventional way—i.e., to simulate multiple physical APs broadcasting the same WLAN / SSID from different physical locations—it makes sense to configure VAPs in a public VAP group to broadcast the same WLAN / SSID.

[0022] As described above, the roaming testing system according to the present disclosure offers numerous technical advantages over conventional roaming testing systems. For example, the roaming testing system according to the present disclosure is generally cheaper and easier to implement than conventional roaming testing systems because (a) the roaming testing system according to the present disclosure does not require personnel or robots to physically move from the physical APs already deployed in the network to the physical APs; and (b) the roaming testing system according to the present disclosure does not require expensive (and not easily portable) testing equipment to be placed on-site during roaming testing. Relatedly, the roaming testing system according to the present disclosure can be implemented remotely because it does not require on-site physical resources (except for a single physical AP) during roaming testing. Moreover, because it does not rely on multiple physical APs installed / deployed before testing, the roaming testing system according to the present disclosure can test / troubleshoot potential network deployments without installing them. This can save significant time and costs, for example, when users / network administrators wish to test / troubleshoot multiple potential network deployments before selecting the final deployment to be provided. Due to the reduced reliance on human / physical resources, examples of the techniques disclosed also facilitate greater automation of roaming testing systems.

[0023] Before describing in detail the examples of the techniques disclosed herein, it is useful to describe how to use VAPs (and more generally APs) in a typical network deployment, and the examples of the techniques disclosed herein can be used for testing.

[0024] As mentioned above, a wireless access point (AP) generally refers to a networked device that allows wireless client devices to connect to a wireless network (e.g., a WLAN). According to the IEEE 802.11 WLAN standard (including Wi-Fi), a service set is a term used to refer to a group of wireless network devices that share a Service Set Identifier (SSID), typically a natural language label that users perceive as a network name. A service set forms a logical network of nodes that operate with shared link-layer networking parameters. One type of service set, a Basic Service Set (BSS), can refer to a subgroup of devices within the service set that share physical layer media access characteristics (e.g., radio frequency, modulation scheme, security settings), enabling wireless networking of devices. A BSS is defined by a BSS identifier (BSSID) shared by all devices within it.

[0025] An AP can advertise a WLAN to wireless client devices by sending beacon and probe responses containing the WLAN's SSID and, for example, the supported authentication and data rates. When a wireless client device associates with an AP, it sends traffic to the AP's BSSID, which is typically the AP's Media Access Control (MAC) address. In some networks, the AP uses a unique BSSID for each WLAN, allowing a single physical AP to support multiple WLANs in a network deployment. As described above, the WLAN configuration applied to the AP's BSSID can be called a Virtual AP (VAP). In other words, a VAP can be considered a logical or virtual AP instance on a physical AP. By convention, a VAP or VAP profile is configured to provide different network access or services to users on / across the same physical network deployment. For example, a first WLAN might be configured to provide access to guest users, and a second WLAN might be configured to provide access to employee users through the same(s) AP(s). Applying a first WLAN configuration to a second WLAN configuration with different BSSIDs will result in a first VAP and a second VAP. For example, the first VAP can be configured to provide open authentication and dedicated portal access with a basic rate not exceeding 1 Mbps, while the second VAP can be configured to require WPA authentication with a basic rate not exceeding 11 Mbps.

[0026] As described above, in order to test / simulate physical roaming scenarios using a group of VAPs with the same physical AP, Example (1) changes the traditional concept of physical / mobile-based roaming from the spatial domain to the temporal domain; and (2) changes the usual use / configuration of VAPs.

[0027] For example, the example can simulate the physical movement of a wireless client between physical APs deployed in a network by varying the transmission power for each VAP as a function of time, in a way that reflects how the wireless client perceives changes in transmission power for each physical AP (represented by the VAP) as it moves within the geographic sites of the network deployment. Therefore, the example utilizes the concept of "clockwise roaming" / clock movement to simulate "physical roaming" / spatial movement.

[0028] The example also alters the conventional use / configuration of VAPs. Specifically, the example configures VAPs in a public VAP group to broadcast the same WLAN / SSID. Conventionally, this configuration is illogical because VAPs are specifically designed to allow a single physical AP to broadcast multiple / different WLAN / SSIDs. However, since the examples of the technology disclosed herein utilize a single physical AP's VAP in an unconventional way—that is, to simulate multiple physical APs broadcasting the same WLAN / SSID from different physical locations—it makes sense to configure VAPs in a public VAP group to broadcast the same WLAN / SSID.

[0029] Similarly, before describing examples of the technologies disclosed in detail, it is useful to describe example network deployments that can be used for testing.

[0030] Figure 1 An example of a network deployment 100 is shown, which can be implemented for an enterprise / organization, such as a business, educational institution, government entity, healthcare institution, or other organization. The diagram illustrates an example configuration implemented by an organization with multiple users (or at least multiple client devices 110) at geographic site 102.

[0031] Geographic site 102 may include a primary network, which could be, for example, an office network, a home network, or another network installation. The geographic site 102 network may be a private network, and may include security and access controls to restrict access to authorized users. Authorized users may include, for example, company employees, residential residents, business customers, etc., at geographic site 102.

[0032] In the illustrated example, geographic site 102 includes a controller 104 that communicates with network 120. Controller 104 can provide communication between geographic site 102 and network 120, although it may not be the only communication point between geographic site 102 and network 120. Although geographic site 102 may include multiple controllers and / or multiple communication points with network 120, a single controller 104 is shown. In some examples, controller 104 communicates with network 120 via a router (not shown). In other examples, controller 104 provides router functionality to devices within geographic site 102.

[0033] Controller 104 can be operated to configure and manage network devices, such as at geographic site 102. Controller 104 can be operated to configure and / or manage switches, routers, access points, and / or client devices connected to the network. Controller 104 itself can be an access point, or can provide access point functionality.

[0034] Controller 104 can communicate with one or more switches 108 and / or wireless access points (APs) 106a-c. Switches 108 and wireless APs 106a-c provide network connectivity to various client devices 110a-j. Using the connection to switch 108 or AP 106a-c, client devices 110a-j can access network resources, including other devices on (geographic site 102) and network 120.

[0035] Examples of client devices may include: desktop computers, laptops, servers, web servers, authentication servers, Authentication, Authorization and 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, tablets, e-readers, netbooks, televisions and similar displays (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smartphones, smart terminals, simple terminals, virtual terminals, video game consoles, virtual assistants, Internet of Things (IoT) devices, etc.

[0036] Within geographic site 102, switch 108 is included as an example of a point for wired client devices 110i-j to access the network established within geographic site 102. Client devices 110i-j can connect to switch 108, and through switch 108, can access other devices within network deployment 100. Client devices 110i-j are also able to access network 120 through switch 108. Client devices 110i-j can communicate with switch 108 via a wired connection 112. In the example shown, switch 108 communicates with controller 104 via a wired connection 112, although this connection could also be wireless.

[0037] Wireless AP 106a-c is included as another example of a point for client devices 110a-h to access a network AP established in geographic site 102. Each of AP 106a-c can be a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to wireless client devices 110a-h. In the example shown, AP 106a-c can be managed and configured by controller 104. AP 106a-c communicates with controller 104 and the network via connection 112, which can be a wired or wireless interface.

[0038] Network 120 may be a public or private network, such as the Internet, or other communication networks that allow connection to geographic site 102 and access to servers 160a-b. Network 120 may include third-party telecommunications lines, such as telephone lines, coaxial cables, fiber optic cables, satellite communications, cellular communications, etc. Network 120 may include any number of intermediate network devices, such as switches, routers, gateways, servers, and / or controllers, which are not directly part of network deployment 100 but facilitate communication between the various parts of network deployment 100 and between network deployment 100 and other network-connected entities.

[0039] An Access Point (AP) generally refers to a networked device that allows wireless client devices to connect to a wireless network. An AP may include a processor, memory, and I / O interfaces, including wired network interfaces (such as an IEEE 802.3 Ethernet interface) and wireless network interfaces (such as an IEEE 802.11 Wi-Fi interface), but the examples in this disclosure are not limited to such interfaces. An AP may include memory, including tiers of read-write memory (i.e., volatile memory) and persistent memory (i.e., non-volatile memory), such as ROM, EPROM, and flash memory. Furthermore, as used herein, an AP may refer to a receiving point of any known or later-to-be-known convenient wireless access technology. In particular, the term AP is not intended to be limited to IEEE 802.11-based APs.

[0040] As described above, an AP (such as AP 106a-c) can implement VAP, which means supporting one or more different SSID values ​​over a single AP radio, each SSID (i.e., BSSID) having a unique Media Access Control (MAC) address. The SSID can be a field between 0 and 32 octets and may be included as an Information Element (IE) in a management frame. In the context of the 802.11 standard, management frames supporting SSID IEs include beacon, probe request / response, and association / reassociation request frames. An AP can support VAP using multiple BSSIDs. Typically, a beacon or probe response can contain a single SSID IE. The AP sends beacons for each supported VAP at beacon intervals (e.g., 100ms), each VAP using a unique BSSID. The AP responds to probe requests for supported SSIDs (including requests for broadcast SSIDs) with probe responses (including capabilities corresponding to each BSSID). Typically, an AP can advertise a maximum given number (e.g., 16) of beacons, each with a different BSSID to provide VAP support. Each VAP can have a unique MAC address, and each beacon can have a network name.

[0041] Figure 2 yes Figure 1 The accompanying diagram illustrates a schematic of an AP configured with multiple VAPs. Figure 1 and Figure 2 The components marked with common numerical labels in the figures may be the same or similar components, and for the sake of brevity, they will not be described further.

[0042] AP 106a can be configured to support multiple VAPs 106a-1 and 106a-2. Each of VAPs 106a-1 and 106a-2 can emulate the operation of the physical AP 106a at the MAC layer. Specifically, each of VAPs 106a-1 and 106a-2 can emulate the MAC layer behavior of the physical AP 106a by using different BSSIDs (A, B) and optional different capability publications (e.g., rates 1, 2, 5.5, 11 for BSSID A, and rates 1, 2, 5.5 for BSSID B) and default key sets (RSN for BSSID A and WEP for BSSID B). Each of VAPs 106a-1 and 106a-2 can also exhibit different application behaviors (at the application layer) and can be accessed via different domain names (at the IP layer). To provide this support, it is assumed that (1) client devices 110G and 110H can discover SSIDs, (2) each of VAPs 106a-1 and 106a-2 can advertise its own set of capabilities, and (3) each of VAPs 106a-1 and 106a-2 can be assigned to a unique WLAN. It should be understood that the number of VAPs may vary, and Figure 2 The examples provided are not intended to be restrictive.

[0043] As described above, in order to test / simulate physical roaming scenarios using a group of VAPs with the same physical AP, Example (1) changes the traditional concept of physical / mobile-based roaming from the spatial domain to the temporal domain; and (2) significantly alters the usual use / configuration of VAPs.

[0044] For example, the example can simulate the physical movement of a wireless client between physical APs deployed in a network by varying the transmission power for a VAP as a function of time, in a way that reflects how the wireless client will perceive changes in the transmission power of each physical AP (represented by a VAP) as it moves within the geographic sites of the network deployment. Therefore, the example utilizes the concept of "clockwise roaming" / clock movement to simulate "physical roaming" / spatial movement.

[0045] The example also alters the conventional use / configuration of VAPs. Specifically, the example configures VAPs in a public VAP group to broadcast the same WLAN / SSID. Conventionally, this configuration is illogical because VAPs are specifically designed to allow a single physical AP to broadcast multiple / different WLAN / SSIDs. However, since the examples of the technology disclosed herein utilize a single physical AP's VAP in an unconventional way—that is, to simulate multiple physical APs broadcasting the same WLAN / SSID from different physical locations—it makes sense to configure VAPs in a public VAP group to broadcast the same WLAN / SSID.

[0046] Figure 3 Various examples of the technology according to this disclosure are described, which can be used for testing. Figure 1-2 The example roaming test system 300 is deployed in network 100. Figures 1 to 3 Components labeled with common numerical reference numerals in the accompanying drawings may be the same or similar components; for the sake of brevity, they will not be described further. Figure 1 and Figure 2 China uses common numbers.

[0047] As described, the roaming test system 300 can be implemented using a single physical AP (i.e., AP 106a). The roaming test system 300 can simulate this elegant system by using a group of VAPs provided on AP 106a to simulate network deployment 100. Each VAP in the VAP group can be configured to represent a physical AP (i.e., AP 106a-c) of network deployment 100. The roaming test system 300 can simulate a wireless client device (e.g., wireless client device 110h) physically moving within geographic site 102 (and, by extension, roaming between physical APs of network deployment 100) by varying the transmission power associated with each VAP in the VAP group as a function of time, in a manner that reflects how the wireless client device will perceive changes in the transmission power of each physical AP (represented by a VAP) as it moves within geographic site 102.

[0048] As described, the roaming test system 300 includes an AP 106a and a roaming test controller 320 (e.g., an Aruba mobile controller or a similar controller used in conjunction with a wireless device). The roaming test controller 320 can be connected to the AP 106a via a wired or wireless connection. In some examples, the roaming test system 300 may also include a user interface (not shown) associated with one or both of the AP 106a and the roaming test controller 320. As described below, the user can select via the user interface: (1) multiple VAP groups to be configured and multiple VAPs in each group (again, these VAPs and VAP groups can represent / simulate physical APs of network deployment 100); and (2) various roaming parameters (e.g., roaming type, security operation mode, roaming trigger type, etc.) for the configured VAP groups (which simulate network deployment 100). Here, the user can select multiple VAP groups to be configured so that the user can test multiple roaming scenarios simultaneously. In particular, each VAP group can be configured with unique / individual roaming parameters (e.g., the first set of roaming parameters for the first VAP group, the second set of roaming parameters for the second VAP group, the third set of roaming parameters for the third VAP group, etc.), which allows users to test different roaming scenarios for different VAP groups simultaneously (based on unique / individual roaming parameters).

[0049] As described above, multiple VAPs can be provided on AP 106a (up to 16 VAPs can be provided on AP 106a in various examples). As described above, the example (in some cases in response to user input) can configure VAPs such that a given VAP is configured to represent a physical AP of network deployment 100. For example, a first VAP (e.g., VAP 106a-1) can be configured to represent AP 106a, a second VAP (e.g., VAP 106a-2) can be configured to represent AP 106b, a third VAP (e.g., VAP 106a-3) can be configured to represent AP 106c, and so on. As described above, by strategically changing the transmission power of these VAPs (as a function of time), the example can simulate a wireless client device (e.g., wireless client device 110h) moving within geographic site 102 and roaming between (physical) APs 106a-c.

[0050] In various examples, the roaming test controller 320 can configure VAP / VAP groups and / or roaming parameters for VAP / VAP groups provided on AP 106a. In some examples, the roaming test controller 320 can be a logical block residing in AP 106a. In some examples, either or both of AP 106a and the roaming test controller 320 can be associated with a user interface / dashboard via a wired or wireless connection. As described above, the user interface can allow the user to select: (1) multiple VAP groups and multiple VAPs to be configured (again, these VAPs and VAP groups can represent / simulate the physical APs of network deployment 100); and (2) various roaming parameters for (multiple) VAP groups (e.g., roaming type, security operation mode, roaming trigger type, etc.). In these examples, the user interface can be located remotely from geographic site 102. Therefore, the user has the ability to perform roaming scenario testing of network deployment 100 entirely remotely and / or automatically (e.g., the system can be remotely provided from a cloud or local connection, and the test suite can automatically execute multiple test cases in any order). As described above, this feature of the roaming test system 300 offers an advantage over conventional roaming test systems, which typically require a physical presence at a geographic site where the network is deployed to perform roaming tests. Therefore, using a single physical AP, the technical examples of this disclosure enable roaming testing without requiring the user to be present at a geographic site where the network is deployed.

[0051] The roaming test system 300 can be used with APs (e.g., AP 106a) from a variety of different vendors (including Aruba). In various examples, the roaming test system 300 can be used with APs that support: (1) 16 VAPs per AP / each radio, each VAP having its own unique tunnel ID (in the case of a campus AP tunnel-based solution) and a unique Layer 2 MAC address (note that from a roaming perspective, Layer 3 data paths treat each tunnel ID equally, whether they are established from a single physical AP or multiple physical APs); and (2) mapping unique VAP profiles one-to-one to unique SSID profiles.

[0052] As described above, in order to effectively replace physical APs with VAPs for roaming scenario testing, the roaming test system 300 can implement professional configurations of AP 106a and the VAPs provided on AP 106a.

[0053] For example, the roaming test system 300 can make certain WLAN driver / firmware changes to the AP 106a based on command line. For instance, the roaming test system 300 can differentiate the transmission power for all AP downlink (DL) packets for each VAP provided on the wireless AP 106a. As another example, the roaming test system 300 is able to suspend the beacon queue for each VAP and create a beacon loss for a user-configurable period. This can reduce the transmission power on DL packets when the wireless client decides to transmit on the uplink (UL). Reducing the transmission power helps reduce the Received Signal Strength Indication (RSSI) on the wireless client, which has a roaming algorithm (to initiate roaming to a new AP) that can be based on RSSI thresholds, beacon loss, etc. In some cases, examples of the techniques disclosed herein can even help in understanding the roaming algorithm of a wireless client.

[0054] The roaming test system 300 can also make configuration changes to its profile, allowing a single SSID profile to be applied to all VAPs in a public VAP group provided on AP 106a. As mentioned above, this unconventional configuration allows the VAP group to simulate a physical network where multiple physical APs broadcast the same SSID / WLAN from different physical locations. Therefore, each VAP in the VAP group provided on AP 106a can have a unique / different BSSID (also known as a Layer 2 MAC address) but the same SSID (sometimes called an ESSID).

[0055] As described above, the test equipment required for the roaming test system 300 may include a physical access point (AP) (i.e., AP 106a) and a controller (i.e., roaming test controller 320). In some examples, wireless client devices (e.g., wireless client devices 110h and 110g) may also be used in roaming scenario tests performed by the roaming test system 300. The wireless client devices may be used for verification purposes or to gain a better understanding of the wireless client roaming algorithm.

[0056] In some examples, the roaming test system 300 may rely on certain assumptions when performing roaming scenario tests. These assumptions may include: (1) AP 106a supports 2.4 GHz, 5 GHz, and 6 GHz bands, and each band supports up to 16 VAPs / BSSIDs (this assumption helps to achieve a comprehensive multi-band system where each radio / band may have 16 VAPs, for a total of 48 VAPs; here, the more VAPs, the more comprehensive the roaming test); (2) VAPs have the same SSID (as mentioned above, in order to simulate physical roaming from one physical AP to another, the VAPs of the techniques disclosed herein broadcast the same SSID); (3) VAPs have the same mobile domain (as required by a specific specification, such as 802.11r-based roaming); (4) VAPs under the same Layer 2 network use the same DHCP server and subnet (this helps to simulate different APs in the same subnet).

[0057] As described above, via a user interface associated with either or both of AP 106 and roaming test controller 320, the user can select: (1) multiple VAP groups and multiple VAPs to be configured (again, these VAPs and VAP groups can represent / simulate the physical APs of network deployment 100); and (2) various roaming parameters for the configured (multiple) VAP groups (e.g., roaming type, security operation mode, roaming trigger type, etc.). The following will combine... Figure 4 Describe an example workflow that can be used with this user interface.

[0058] Figure 4 Example workflow 400, which describes various examples of the technology according to this disclosure, can be used in conjunction with a user interface of a roaming test system. Workflow 400 and the user interface associated with workflow 400 can be used in conjunction with a roaming test system 300.

[0059] As described, in operation 402, the user selects multiple VAP groups and multiple VAPs in each group to simulate a (physical) network deployment. As mentioned above, each VAP in a VAP group can be configured as a physical AP representing a network deployment (e.g., network deployment 100).

[0060] Here, users can group VAPs into "VAP groups" to improve testing efficiency. This is because users can select / apply different roaming parameters for each VAP group (i.e., users can select / apply: a first set of roaming parameters for the first VAP group, a second set of roaming parameters for the second VAP group, etc.). Therefore, users can simultaneously execute different roaming test scenarios using different VAP groups (and their associated roaming parameters). For example, a user can simultaneously execute (1) a first roaming scenario test using the first VAP group (with the first set of roaming parameters); (2) a second roaming scenario test using the second VAP group (with the second set of roaming parameters); (3) a third roaming scenario test using the third VAP group (with the third set of roaming parameters); and so on. Here, each VAP group may have its own unique mobility domain depending on the requirements of a specific specification (e.g., roaming based on 802.11r).

[0061] In Operation 404, the user selects the roaming type, security operation mode, and roaming trigger for each selected VAP group.

[0062] Examples of selectable roaming types include: (a) traditional roaming; (b) opportunistic key cache (OKC); (c) PMKID cache; (d) fast roaming (sometimes referred to as FT roaming or 802.11r roaming); (e) point (a) to point (d) with managed frame protection (MFP); and so on.

[0063] Examples of selectable safe operating modes include: (a) wpa2-psk-aes; (2) wpa3-sae-aes; (3) wpa2-psk-aes; etc.

[0064] Examples of selectable roaming triggers include: (a) triggering based on AP transmission power (this could include 802.11v-based roaming triggering, where the client device has a switching selection based on decreasing transmission power); and (2) triggering based on beacon loss. In some examples, roaming triggering could include instructing the client device to switch from one VAP to another based on, for example, 802.11v-based roaming triggering.

[0065] Here, users can select a specific roaming test scenario (i.e., a specific combination of roaming type, security operation mode, and roaming trigger) or the entire roaming test suite with various combinations of roaming and security operation modes. For example, users can select / apply: (1) a first combination of roaming parameters for the first VAP group (e.g., wpa2-psk-aes+FT and roaming trigger based on AP transmission power); (2) a second combination of roaming parameters for the second VAP group (e.g., wpa3-sae-aes+MBO+PMKID cache and trigger based on beacon loss); (3) a third combination of roaming parameters for the third VAP group (e.g., wpa2-psk-aes+OKC+MFP and trigger based on 802.11v); and (4) a fourth combination of roaming parameters for the fourth VAP group (e.g., wpa2-psk-aes+FT and trigger based on AP transmission power).

[0066] In operation 406, the user selects "Yes" or "No" for automatic clockwise roaming. In various examples, the user can make this selection via the VAP group.

[0067] As mentioned above, and will be combined Figure 5 To describe in more detail, automatic clockwise roaming involves changing the transmission power (or, in some cases, the beacon loss value) associated with each configured VAP as a function of time, in a way that reflects how the wireless client will perceive changes in the transmission power (or, in some cases, the beacon loss) of the physical AP (represented by the VAP) as it moves within the geographic location of the network deployment.

[0068] Here, if a user only wants to perform spot checks on specific roaming scenarios, they can select "No" for automatic clockwise roaming. In other words, selecting "No" for automatic clockwise roaming is similar to a traditional roaming test system, which changes the transmission power or beacon loss used for multiple physical APs to spot check roaming scenarios, rather than physically moving people or robots between physical APs to test roaming scenarios.

[0069] Figure 5 Example graph 500 illustrating automatic clockwise roaming of VAP group 510 describes various examples of the technology according to this disclosure. Figure 6 yes Figure 5 The accompanying diagram illustrates an example graph 600 of physical roaming within the illustrated network deployment 610. Here, VAP group 510 can simulate network deployment 610.

[0070] As described, Figure 500 shows the transmission (Tx) power of (downlink) DL packets for the four VAPs (i.e., VAP1, VAP2, VAP3, and VAP4) in VAP group 510 as a function of time. As depicted, each of VAPs 1-4 is associated with a unique BSSID (i.e., BSSID 1 for VAP1, BSSID 2 for VAP2, etc.).

[0071] Figure 6 Figure 600 looks very similar to Figure 500, but there are some key differences. Specifically, Figure 600 shows the transmission (Tx) power of DL packets for the four physical APs (i.e., AP1, AP2, AP3, and AP4) of network deployment 610 as a function of distance. As depicted, each (physical) AP is associated with a unique BSSID (i.e., BSSID 1a for AP1, BSSID 2a for AP2, etc.). Here, VAP 1 of VAP group 510 can be configured to represent AP 1 of network deployment 610, VAP 2 of VAP group 510 can be configured to represent AP 2 of network deployment 610, VAP 3 of VAP group 510 can be configured to represent AP 3 of network deployment 610, and so on.

[0072] As described, using, for example, an automatic clockwise roaming algorithm, examples of the technology disclosed herein can simulate a physical roaming scenario within network deployment 610 (i.e., physical movement / roaming between physical APs in network deployment 610) by changing the time-varying transmission power (for DL ​​packets) of the VAPs in VAP group 510. As mentioned above, in a physical roaming scenario, the wireless client device will perceive changes in the transmission power of DL packets transmitted by each physical AP in network deployment 610 as a function of distance / physical movement. In the automatic clockwise roaming scenario introduced by examples of the technology disclosed herein, the wireless client device will perceive changes in the transmission power of DL packets transmitted by each VAP in VAP group 510 as a function of time / clock movement. Here, the example may adjust based on the geographical location of the physical APs within network deployment 610. Figure 5 The example demonstrates an automatic clockwise roaming scenario. For instance, depending on the relative positions of AP 1 and AP 2, the example could adjust how the transmission power of DL packets sent by VAP 1 changes over time relative to the transmission power of DL packets sent by VAP 2.

[0073] In combination Figure 5In the simplified example described, at the beginning (i.e., time = 0), the maximum allowed transmission power (e.g., 18 dBm) is set on VAP 1, and very low transmission power (e.g., 0 dBm) is set on VAP 2-4. Through an automated script, over time, the transmission power on VAP 1 gradually decreases to 0 dBm, while the transmission power on VAP 2 increases from 0 dBm to the maximum allowed transmission power, and so on. As described above, each of VAP 1-4 can be configured to have a different transmission power, allowing VAP group 510 to effectively simulate network deployment 610. Figure 5 As shown, as time continues, the transmission power of VAPs 1-4 eventually reaches 0dBm. This can simulate the handover from Wi-Fi to cellular in network deployment 610 (i.e., it can simulate the scenario where wireless client devices physically leave the usable range of network deployment 610). The example can also simulate a Wi-Fi to cellular handover by reducing the transmission power of all VAPs in VAP group 510 to 0dBm.

[0074] In various scenarios, instead of adjusting / changing the transmission power over time for VAPs 1-4, examples could be used to adjust / change the beacon loss value over time for VAPs 1-4 to simulate roaming scenarios within a network deployment 610, for example, based on beacon loss rather than transmission power loss. Beacon loss is likely introduced by causing a given VAP to transmit a smaller number of beacons per unit time, close to 0 (i.e., no SSID seen). Generally, wireless clients have a threshold for beacon reading per unit time. Therefore, when the beacon rate drops below the wireless client's threshold rate, the client will have to switch / roam from one BSS to another.

[0075] Figure 7 Example computing system 700, which describes various examples of the technology according to this disclosure, can be used to perform roaming scenario tests using a group of VAPs (or typically multiple VAPs) configured to simulate network deployment.

[0076] Now for reference Figure 7 The computing component 710 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 7 In the example implementation, computing component 710 includes hardware processor 712 and machine-readable storage medium 714.

[0077] The hardware processor 712 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in the machine-readable storage medium 714. The hardware processor 712 may fetch, decode, and execute instructions, such as instructions 716-722, to control a burst preloading process or operation for estimating available bandwidth. As an alternative to or supplement to retrieving and executing instructions, the hardware processor 712 may include one or more electronic circuits comprising electronic components for the function of executing one or more instructions, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits.

[0078] A machine-readable storage medium, such as machine-readable storage medium 714, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Therefore, machine-readable storage medium 714 can be, for example, random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, machine-readable storage medium 714 can be a non-transitory storage medium, wherein the term "non-transitory" excludes transient propagation indicators. As described in detail below, machine-readable storage medium 714 can be encoded with executable instructions, such as instructions 716-722.

[0079] As described above, according to various examples of the technology disclosed herein, the computing system 700 can be used to perform roaming scene testing using a group of VAPs (or generally multiple VAPs).

[0080] Therefore, the hardware processor 712 executes instruction 716 to configure the VAP group to simulate a (physical) network deployment.

[0081] As described above, a VAP group can simulate a network deployment that includes multiple physical APs located at geographic sites. Therefore, a given VAP can be configured to represent a given physical AP within the network deployment (including its geographic location). For example, the first VAP in the VAP group can be configured to represent the first physical AP of the network deployment, the second VAP in the VAP group can be configured to represent the second physical AP of the network deployment, and so on. As mentioned above, a VAP group can also be a logical AP provided on a single physical AP in the network deployment.

[0082] In various examples, a group of VAPs can simulate a anticipated network deployment (i.e., a network deployment that has not yet been deployed / installed, or has not been fully deployed / installed). Therefore, a given VAP can represent a potential physical AP deployed at a desired location in a geographic site. As mentioned above, because roaming testing systems implemented according to the techniques of this disclosure do not rely on installing / deploying multiple physical APs before testing, they can test / troubleshoot potential deployments without installing them. This can save significant time and cost, for example, when users / network administrators wish to test / troubleshoot multiple potential network deployments before ultimately providing them. The examples also provide a better understanding of wireless client roaming algorithms and roaming thresholds.

[0083] As described above, the hardware processor 712 can configure a VAP group to broadcast the same Service Set Identifier (SSID) – sometimes also called an Extended SSID (ESSID). This corresponds to each VAP broadcasting the same WLAN. As mentioned above, this type of configuration is the opposite of the convention where VAPs provided on the same physical AP are configured to broadcast different SSIDs / WLANs. Here, the hardware processor 712 can configure the VAPs in the VAP group to broadcast the same SSID / WLAN to simulate multiple physical APs in a (simulated) network deployment broadcasting the same SSID / WLAN from different geographical locations. The hardware processor 712 can also configure the VAPs in the VAP group to have unique / different underlying Service Set Identifiers (BSSIDs) (i.e., the first BSSID of the first VAP, the second BSSID of the second VAP, etc.). Therefore, wireless client devices may treat each VAP in the VAP group as a separate physical AP, which generally also has a unique BSSID. In some examples, the hardware processor 712 can also configure each VAP to have its own unique tunnel ID (e.g., in the case of a campus AP tunnel-based solution).

[0084] In various examples, the hardware processor 712 can be configured with multiple VAP groups to simulate network deployments (e.g., a first VAP group, a second VAP group, etc.). As mentioned above, the hardware processor 712 can configure multiple VAP groups for better test efficiency / multi-user testing. This is because the hardware processor 712 can apply different roaming parameters to each VAP group and then simultaneously execute different roaming test scenario tests on each VAP group with different roaming parameters applied thereto. For example, the hardware processor 712 can simultaneously execute (1) a first roaming scenario test using the first VAP group (with a first set of roaming parameters); (2) a second roaming scenario test using the second VAP group (with a second set of roaming parameters); (3) a third roaming scenario test using the third VAP group (with a third set of roaming parameters); and so on.

[0085] In some examples, the hardware processor 712 can configure VAP groups in response to user input. For example, as described above, a user can select multiple VAP groups and multiple VAPs within each VAP group. The hardware processor 712 can then configure the selected multiple VAP groups / VAPs to simulate a network deployment.

[0086] Hardware processor 712 executes instruction 718 to configure roaming parameters for the VAP group. In some examples, hardware processor 712 may perform this configuration in response to user input.

[0087] The hardware processor 712 can be configured with various types of roaming parameters for VAP groups. For example, the hardware processor 712 can configure (1) roaming type; (2) secure operation mode; and (3) roaming trigger.

[0088] Examples of configurable roaming types include: (a) traditional roaming; (b) opportunistic key cache (OKC); (c) PMKID cache; (d) fast roaming (sometimes referred to as FT roaming or 802.11r roaming); (e) point (a) to point (d) with managed frame protection (MFP); and so on.

[0089] Examples of configurable security operating modes include: (a) wpa2-psk-aes; (2) wpa3-sae-aes; (3) wpa2-psk-aes; etc.

[0090] Examples of configurable roaming triggers include: (a) triggering based on AP transmission power (this could include 802.11v-based roaming triggering, where the client device has a switching selection based on decreasing transmission power); and (2) triggering based on beacon loss. In some examples, roaming triggering could include: instructing the client device to switch from one VAP to another based on, for example, 802.11v-based roaming triggering.

[0091] As described above, in some examples, the hardware processor 712 can configure different sets of roaming parameters for different VAP groups. For example, the hardware processor can configure: (1) a first set of roaming parameters for a first VAP group; (2) a second set of roaming parameters for a second VAP group; (3) a third set of roaming parameters for a third VAP group; and so on. The hardware processor 712 can then execute different roaming scenario tests using the VAP groups simultaneously based on the (different) sets of roaming parameters applied to the VAP groups. This can improve testing efficiency by executing multiple roaming scenario tests within the approximate time required to execute a single roaming scenario test.

[0092] Based on the roaming parameter configuration described in instruction 718, hardware processor 712 executes instruction 720 to perform a roaming scene test using a VAP group.

[0093] As described above, in examples where different sets of roaming parameters are applied to different VAP groups, the hardware processor 712 can execute multiple roaming scenario tests simultaneously. For example, the hardware processor 712 can simultaneously execute (1) a first roaming scenario test using a first VAP group (with a first roaming parameter set); (2) a second roaming scenario test using a second VAP group (with a second roaming parameter set); (3) a third roaming scenario test using a third VAP group (with a third roaming parameter set); and so on. As described above, executing multiple roaming scenario tests simultaneously can improve testing efficiency because multiple roaming scenarios can be tested within the approximate time required to execute a single roaming scenario test.

[0094] As mentioned above, in some examples, performing roaming scenario tests using a VAP group may include: varying the transmission power of at least one VAP in the VAP group over time to simulate the movement of client devices relative to the location of physical APs deployed in the network (in some examples, the transmission power may vary over time for each VAP in the VAP group). Combined Figure 5 and Figure 6 This "automatic clockwise roaming" is described in detail.

[0095] In various scenarios, the hardware processor 712 can vary beacon loss over time to simulate the movement of client devices relative to the physical APs deployed in the network, rather than changing the transmission power of at least one VAP in the VAP group over time. Beacon loss may be introduced by causing a given VAP to transmit a smaller number of beacons per unit time, close to 0 (i.e., no SSID seen). Generally, wireless clients have a threshold for reading beacons per unit time. Therefore, when the beacon rate drops below the wireless client's threshold rate, the client will have to switch / roam from one BSS to another.

[0096] Hardware processor 712 executes instruction 722 to display the results of the roaming scene test(s). Alternatively, in some examples, hardware processor 712 may provide the results of the roaming scene test(s) to a user interface / graphical user interface that can display the test results to a user.

[0097] Figure 8A block diagram illustrating an example computer system 800 in which various embodiments described herein may be implemented is provided. The computer system 800 includes a bus 802 or other communication mechanism for transmitting information, and one or more hardware processors 804 coupled to the bus 802 for processing information. The hardware processors 804 may be, for example, one or more general-purpose microprocessors.

[0098] Computer system 800 also includes main memory 806, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 can also be used to store temporary variables or other intermediate information during the execution of instructions by processor 804. When these instructions are stored in storage media accessible to processor 804, computer system 800 presents itself as a special-purpose machine customized to perform the operations specified in the instructions.

[0099] The computer system 800 also includes a read-only memory (ROM) 808 or other static storage device coupled to the bus 802 for storing static information and instructions of the processor 804. Storage devices 810, such as disks, optical disks, or USB flash drives, are provided and coupled to the bus 802 for storing information and instructions.

[0100] Computer system 800 may be coupled to display 812, such as a liquid crystal display (LCD) (or touchscreen), via bus 802 for displaying information to the computer user. Input device 814 (including alphanumeric and other keys) is coupled to bus 802 for transmitting information and command selections to processor 804. Another type of user input device is cursor control 816 (e.g., mouse, trackball, or arrow keys) for transmitting directional information and command selections to processor 804 and for controlling cursor movement on display 812. In some embodiments, the same directional information and command selections as cursor control may be implemented via receiving touch on a touchscreen without a cursor.

[0101] The computing system 800 may include a user interface module to implement a GUI that can be stored as executable software code on a mass storage device, which is executed by the computing device(s). For example, this module and other modules may include: components (e.g., software components, object-oriented software components, class components, and task components), processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuit systems, data, databases, data structures, tables, arrays, and variables.

[0102] Generally, the terms "component," "engine," "system," "database," and "data storage" used in this document can refer to logic contained in hardware or firmware, or to a collection of software instructions that may have entry and exit points, written in a programming language such as Java, C, or C++. Software components can be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It should be understood that software components can be invoked from other components or from themselves, and / or can be invoked in response to detected events or interrupts. Software components configured to execute on a computing device may be provided on computer-readable media, such as optical discs, digital video discs, flash drives, disks, or any other tangible media, or as digital downloads (and initially stored in a compressed or installable format that requires installation, decompression, or decryption before execution). The software code may be stored, in part or in whole, on a storage device executing the computing device for execution by the computing device. Software instructions may be embedded in firmware, such as EPROM. It should also be understood that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0103] Computer system 800 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic. Such logic, combined with the computer system, enables or programs the computer system 800 to become a dedicated machine. According to one embodiment, the techniques described herein are executed by computer system 800 in response to processor(s) 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium (e.g., storage device 810). Execution of the instruction sequence contained in main memory 806 causes processor(s) 804 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0104] As used herein, the term "non-transitory media" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-transitory media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 810. Volatile media include dynamic memory, such as main memory 806. Common forms of non-transitory media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, any other memory chips or memory cartridges, and their network versions.

[0105] Non-transient media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transient media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the wires that constitute bus 802. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0106] Computer system 800 also includes a communication interface 818 coupled to bus 802. Network interface 818 provides bidirectional data communication coupled to one or more network links connected to one or more local networks. For example, communication interface 818 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, network interface 818 may be a Local Area Network (LAN) card to provide data communication connectivity with a compatible LAN (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, network interface 818 sends and receives electrical, electromagnetic, or optical indicators carrying streams of digital data representing various types of information.

[0107] Network links typically provide data communication to other data devices over one or more networks. For example, a network link can provide connectivity to a host or to data devices operated by an Internet Service Provider (ISP) via a local network. ISPs, in turn, provide data communication services through a global packet data communication network now commonly referred to as the "Internet." Both local networks and the Internet use electrical, electromagnetic, or optical indicators carrying digital data streams. Indicators across various networks and on network links, as well as indicators via communication interface 818, are example forms of transmission media, where communication interface 818 transmits digital data to and from computer system 800.

[0108] Computer system 800 can send messages and receive data, including program code, through multiple networks, network links, and communication interface 818. In the Internet example, the server can transmit application request code through the Internet, ISP, local network, and communication interface 818.

[0109] The received code can be executed by processor 804 upon receipt and / or stored in storage device 810 or other non-volatile storage device for subsequent execution.

[0110] Each process, method, and algorithm described in the preceding sections may be embodied in a code component executed by one or more computer systems or computer processors including computer hardware, and fully or partially automated by that code component. One or more computer systems or computer processors may also run in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the performance of the associated operations. Processes and algorithms may be implemented partially or entirely in a dedicated circuit system. The various features and processes described above may be used independently of each other, or in combination in various ways. Different combinations and sub-combinations are within the scope of this disclosure, and certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and associated blocks or states may be executed in other suitable orders, or in parallel, or otherwise. Blocks or states may be added or removed in the disclosed example embodiments. The performance of certain operations or processes may be distributed among computer systems or computer processors, not only residing in a single machine but also deployed across multiple machines.

[0111] As used herein, the circuit can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be used to compose the circuit. In implementations, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be partially or wholly shared between one or more circuits. Even if various features or elements of a function can be described separately or claimed as separate circuits, these features and functions can be shared between one or more common circuits, and such descriptions should not require or imply that implementing such features or functions requires separate circuits. When the circuit is implemented entirely or partially using software, such software can be implemented to operate with a computing or processing system (e.g., computer system 800) capable of performing the described functions.

[0112] As used herein, the term “or” may be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular form should not be construed as excluding the plural form. Conditional language, such as “can,” “could,” “might,” or “may,” unless explicitly stated otherwise or otherwise understood in the context of use, is generally intended to convey that certain embodiments include, but other embodiments do not include, certain features, elements, and / or steps.

[0113] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations thereof, should be interpreted as open-ended, not restrictive. Adjectives such as “routine,” “traditional,” “normal,” “standard,” “known,” and terms with similar meanings should not be interpreted as limiting the described items to those available at a given timeframe or up to a given time, but should be understood to include routine, traditional, normal, or standard techniques that are available or known now or in the future. In some cases, the appearance of broad words and phrases such as “one or more,” “at least,” “but not limited to,” or other similar phrases should not be interpreted as intending or requiring a narrower definition where such a broad phrase might not exist.

Claims

1. A method comprising: configuring a plurality of virtual access points (VAPs) provided on a first physical access point (AP) to emulate a network deployment, a given VAP of the plurality of VAPs configured to represent a physical AP of the network deployment; configuring roaming parameters for the plurality of VAPs; based on the roaming parameter configuration, performing a roaming scenario test using the plurality of VAPs to emulate a moving position of a client device relative to a position of a physical AP of the network deployment by changing at least one of beacon loss and transmission power of at least one VAP of the plurality of VAPs over time; and providing results of the roaming scenario test to a user interface.

2. The method of claim 1, wherein the first physical AP is one of the physical APs of the network deployment.

3. The method of claim 2, wherein the plurality of VAPs are time multiplexed logical APs provided on the first physical AP of the network deployment.

4. The method of claim 2, wherein the plurality of VAPs broadcast a same service set identifier (SSID). configuring a roaming type, a security mode of operation, and a roaming trigger for the plurality of VAPs.

5. The method of claim 2, wherein configuring roaming parameters for the plurality of VAPs comprises:

6. The method of claim 5, wherein the configured roaming trigger for the plurality of VAPs comprises at least one of: an AP transmission power change based trigger, and a beacon loss based trigger.

7. The method of claim 2, wherein the configuration for the plurality of VAPs is made in response to user input.

8. A system comprising: one or more processing resources; and a non-transitory computer readable medium coupled to the one or more processing resources having instructions stored therein that, when executed by the one or more processing resources, cause the system to: configure a first set of VAPs to emulate a network deployment, a given VAP of the first set of VAPs configured to represent a physical AP of the network deployment; configure a second set of VAPs to emulate the network deployment, a given VAP of the second set of VAPs configured to represent a physical AP of the network deployment; configure a first set of roaming parameters for the first set of VAPs and a second set of roaming parameters for the second set of VAPs; based on the roaming parameter configurations: perform a first roaming scenario test using the first set of VAPs to emulate a moving position of a client device relative to a position of a physical AP of the network deployment by changing at least one of beacon loss and transmission power of at least one VAP of the first set of VAPs over time, and perform a second roaming scenario test using the second set of VAPs to emulate the moving position of the client device relative to the position of the physical AP of the network deployment by changing at least one of beacon loss or transmission power of at least one VAP of the second set of VAPs over time; and provide results of the first roaming scenario test and the second roaming scenario test to a user interface. ​ ​ 9. The system of claim 8, wherein the first set of VAPs and the second set of VAPs are provided on a single physical AP.

10. The system of claim 9, wherein the VAPs in the first set of VAPs and the second set of VAPs are time multiplexed logical APs provided on the single physical AP.

11. The system of claim 8, wherein: configuring the first set of roaming parameters for the first set of VAPs comprises configuring a first roaming type, a first security operation mode, and a first roaming trigger for the first set of VAPs; and configuring the second set of roaming parameters for the second set of VAPs comprises configuring a second roaming type, a second security operation mode, and a second roaming trigger for the second set of VAPs.

12. The system of claim 11, wherein the first roaming type comprises at least one of: legacy roaming, opportunistic key caching, PMKID caching, and 802.11r roaming.

13. The system of claim 11, wherein the first roaming trigger comprises at least one of: a trigger based on AP transmission power change, and a trigger based on beacon loss.

14. A non-transitory computer-readable medium storing instructions that, when executed by one or more processing resources, cause the one or more processing resources to: configure a plurality of VAPs to emulate a network deployment, a given VAP of the plurality of VAPs configured to represent a physical AP of the network deployment; configure roaming parameters for the plurality of VAPs; based on the roaming parameters configuration, perform a roaming scenario test using the plurality of VAPs by changing a transmission power of at least one VAP of the plurality of VAPs over time to emulate a moving position of a client device relative to a position of the physical AP of the network deployment; and display results of the roaming scenario test. change the transmission power of each VAP of the plurality of VAPs over time.

15. The non-transitory computer-readable medium storing instructions of claim 14, wherein performing the roaming scenario test using the multiple VAPs by varying a transmission power of at least one of the multiple VAPs over time comprises:

16. The non-transitory computer-readable medium storing instructions of claim 14, wherein the plurality of VAPs are provided on a single physical AP of the network deployment.

17. The non-transitory computer-readable medium storing instructions of claim 16, wherein the VAP groups are time multiplexed logical APs provided on the single physical AP of the network deployment. configure a roaming type, a security operation mode, and a roaming trigger for the plurality of VAPs.

18. The non-transitory computer-readable medium storing instructions of claim 14, wherein configuring roaming parameters for the plurality of VAPs comprises:

19. The non-transitory computer-readable medium storing instructions of claim 18, wherein the roaming type configured comprises at least one of: legacy roaming, opportunistic key caching, PMKID caching, and 802.11r roaming.

20. The non-transitory computer-readable medium storing instructions of claim 14, wherein the plurality of VAPs broadcast an SSID. ​

Images