Sensor-based roaming problem identification in wireless networks

Abstract

Examples of sensor-based roaming problem identification in wireless networks are disclosed. In one example, a wireless roam of a sensor from a source AP to a target AP can be initiated. Management traffic between the sensor and one of the source AP or the target AP during the wireless roam can be monitored. Responsive to detecting an anomaly in the management traffic, the wireless roam of the sensor from the source AP to the target AP can be re-initiated. Management traffic capture on the sensor can be initiated during the re-initiated wireless roam. A roaming problem of the sensor can be identified based on analysis of the captured management traffic, and the same can be reported.

Description

BACKGROUND

[0001] Deploying multiple access points (APs) in a facility is important to provide network coverage to wireless client devices in the facility. As a wireless client moves around in the facility, it can connect to different APs in the facility. The wireless client can roam from one AP to another to achieve uninterrupted network access.

[0002] While moving, the wireless client can disassociate from one AP and re-associate with another AP to maintain network connectivity. To allow uninterrupted network access, the process of roaming from one AP to another is very important. In some scenarios, client and AP capabilities or other network conditions can not allow the client to transition smoothly from one AP to another, which can cause errors when the client attempts to roam from one AP to another. This can adversely affect network performance during roaming. BRIEF DESCRIPTION OF DRAWINGS

[0003] The embodiments described herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like references indicate similar elements. FIG. 1 illustrates a network environment in which various examples presented herein can be implemented.

[0004] Figure 1 FIG. 1 illustrates a network environment in which various examples presented herein can be implemented.

[0005] Figure 2A FIG. 2 illustrates a flow diagram of an example method for identifying roaming issues in a network. Figure 2B FIG. 2 illustrates a flow diagram of an example method for identifying roaming issues in a network.

[0006] Figure 3 FIG. 3 is an example graphical representation of management traffic captured during identifying roaming issues in a network.

[0007] Figure 4 FIG. 4 is a flow diagram of an example method for identifying roaming issues in a network.

[0008] Figure 5 FIG. 5 depicts a block diagram of an example computing system in which various examples described herein can be implemented. DETAILED DESCRIPTION

[0009] Some wireless local area networks (WLANs) include sensors that help monitor and analyze network performance in the WLAN. These sensors can exchange data with different devices in the WLAN to analyze network performance. Such sensors can be deployed at various locations within the WLAN (e.g., different floors of a building, different offices, etc.) and programmed to run various tests to assess network connectivity and services running in the WLAN. Wireless access points (APs) act as access points in the WLAN. These sensors can function as non-AP stations (STAs) associated with the APs in the WLAN and can run different applications and services to test network performance.

[0010] The sensors can be configured to operate and can be managed by a network insight system that can be cloud-based. The sensors can establish wireless connections to / from the network insight system. That is, the network insight system can be a “backend” system that provides a dashboard that can be a “frontend” system. The network insight system can communicate with sensors located remotely to send sensor configuration information or other data associated with or control sensor operation. The network insight system can also receive information or data collected by the sensors and analyze this information or data with respect to one or more aspects of the network in which the sensors have been installed due to the sensors monitoring or testing various aspects of the network, applications running on the network, etc. Network administrators can then view or obtain such information or data via the dashboard for use in debugging network issues. Operational parameters or information about sensor configuration can be set forth using the dashboard.

[0011] Wi-Fi clients can move at different locations of a wireless network. The wireless network can include an extended service set (ESS), which refers to a wireless network created by multiple APs that appears to a user as a single seamless network, such as a network covering a home or office. When a Wi-Fi client associated with one AP moves or transitions to another AP in the ESS, it can be said to be “roaming.” In some scenarios, a Wi-Fi client roaming from one AP to another AP in the ESS can experience a roaming issue. A roaming issue refers to a malfunction, error, or failure that can occur when a Wi-Fi client initiates roaming from one AP to another AP in the ESS, resulting in degraded network performance, such as high latency, dropped traffic, low data rates, etc. The roaming issue can arise due to a malfunction in one or more functions of the AP or the Wi-Fi client. When a roaming issue arises, network administrators need to debug and expend labor hours and resources to identify the roaming issue, as well as optimize network configuration to resolve the issue.

[0012] Frequent roaming issues can cause service disruption, resulting in poor Quality of Experience (QoE). Generally, packet capture devices such as sniffers can be deployed to collect air packets, which can be analyzed to identify roaming issues. However, to analyze network performance of a client roaming between any two APs in an ESS, a sniffer can be needed for each AP in the ESS, which is not feasible. In addition to this, enterprise WLAN deployments can have security settings (e.g., enterprise SSID-802. lx) enabled, which can prevent packet decryption and analysis using sniffers due to security reasons. Further, sensors operating as wireless clients can have the capability to save packet captures and analyze them to determine network performance. However, such sensors do not save packet captures during roaming, and thus identifying roaming issues based on analysis of such packet captures can be cumbersome and error-prone. Additionally, analyzing such packet captures to identify roaming issues is an indirect or passive approach, as real-time packets initiated during client roaming are not captured for such analysis. Thus, identification of roaming issues based on such packet captures can be inaccurate.

[0013] The present technology allows a sensor to wirelessly roam from a source AP to a target AP. During the wireless roam, a computing system, such as a backend network insight system, monitors management traffic between the sensor and the source AP or the target AP. Upon detecting an anomaly in the management traffic, the wireless roam can be restarted, and traffic capture can be initiated at the sensor during the restarted wireless roam. The computing system can analyze the traffic captured during the restarted wireless roam to identify roaming issues and can report the roaming issues for troubleshooting. Thus, roaming issues can be identified by analyzing real-time management traffic captured during the sensor’s wireless roam to test the roaming performance of the network. Since real-time traffic capture is used for analysis, the identification of roaming issues can be more accurate. Further, in the present technology, traffic capture is conditionally initiated at the sensor upon an anomaly occurring in the management traffic exchange during the wireless roam. Thus, traffic capture devices (or sniffers) do not need to be performed all the time during the wireless roam. Upon detecting an anomaly, traffic capture can be initiated. This can allow optimal use of traffic capture on the sensor, which can help manage the storage and analysis of the captured traffic. Further, since the sensor can be tuned to capture air traffic in any operating channel of the APs associated with the wireless roam, traffic capture devices (or sniffers) per AP can not be needed, which can save implementation costs and manual effort.

[0014] The following detailed description references the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to same or like parts. While several embodiments of the application are described herein, modifications, adaptations and other implementations are possible. Accordingly, the following detailed description is not intended to limit the scope of the application as described herein. Instead, the proper scope of the application is defined by the appended claims.

[0015] Before describing examples of the disclosed systems and methods in detail, it can be useful to describe an example network installation in which these systems and methods can be implemented in various applications. Figure 1 A network environment 100 in which various examples presented herein can be implemented is illustrated. The network environment 100 can include a primary network 102, one or more secondary networks (not shown), and a computing system 104 that facilitates monitoring network performance in the primary network 102. The computing system 104 can be hosted on a network outside of the primary network 102, or on a network within the primary network 102. In some examples, the computing system 104 can be deployed on a cloud platform hosted on a public cloud, a private cloud, or a hybrid cloud outside of the primary network 102.

[0016] The primary network 102 can include a network of devices implemented for an organization such as a business, an educational institution, a government entity, a medical facility, or a home network. This diagram illustrates an example primary network implemented for an organization having multiple users and possibly one or more physical or geographic sites. The primary network 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. For example, authorized users can include employees of a company, residents of a housing, customers of a business, and the like.

[0017] In the illustrated example, the primary network 102 is shown to include a controller 105. Although a single controller 105 is illustrated, the primary network 102 can include multiple controllers. In some examples, the controller 105 can communicate with other networks through a router. In other implementations, the controller 105 can provide router functionality to devices in the primary network 102. The controller 105 can be operable to configure and / or manage switches, routers, APs, and / or client devices in the primary network 102. The controller 105 itself can be an AP or provide functionality of an AP.

[0018] In some examples, the controller 105 can be in communication with one or more switches and / or wireless APs 106A-106D. The APs 106A-106D can provide network connectivity to various client devices 108A-108E. One or more of the APs 106A-106C and one or more of the client devices 108A-108E can access network resources, including other devices on the main network 102. Examples of the client devices 108A-108E can include, but are not limited to: 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 televisions), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smart phones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, IoT devices, and the like.

[0019] The example includes the wireless APs 106A-106D as access points for the client devices 108A-108E to the main network 102. Each of the APs 106A-106D can be a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to the wireless client devices 108A-108E. In the illustrated example, the APs 106A-106D can be managed and configured by the controller 105. The APs 106A-106D can communicate with the controller 105 over connections 110, which can be wired or wireless interfaces.

[0020] Further, the main network 102 can host one or more sensors 118A-C. Each of the sensors 118A-C can be within range of one or more of the APs 106A-106D in the main network 102. The sensors can be associated with the APs in the main network 102 via wired or wireless connections. Thus, sensor 118A is associated with AP 106A, sensor 118B is associated with AP 106C, and sensor 118C is associated with AP 106D. The number of sensors deployed in the main network 102 can depend on the number of APs in the main network 102. For example, in one implementation such as an office setting, one sensor can be deployed for every five APs. In another example implementation such as a retail store, one sensor can be deployed in a site. In yet another example implementation such as a large public venue (e.g., a stadium or convention center), one sensor can be deployed for every ten APs.

[0021] The sensors 118A-C can be examples of client devices 108A-E. In one example, the sensors 118A-C can be client devices that work in conjunction with the computing system 104 to identify roaming issues in the main network 102 or a portion thereof. In another example, the sensors 118A-C can be user experience insight sensors configured to mimic end user behavior by simulating a user and the interactions it would perform with APs in the network. In yet another example, the sensors 118A-C can be low power devices, IoT devices, or any other software defined or hardware based device capable of collecting and transmitting data. As used herein, the term “low power device” refers to a device specifically designed for lower power consumption as compared to typical servers or network devices. As used herein, the term “IoT device” is a hardware device, actuator, gadget, appliance, or any other machine that is programmed for a specific application and can transmit data to the computing system 104 over the Internet or other network.

[0022] Each of the sensors 118A-C can maintain a persistent or non-persistent connection with the computing system 104. Examples of connections between the sensors 118A-C and the computing system 104 can include a direct connection, a VPN connection, a software defined wide area networking (SDWAN) connection, a wired connection, a wireless connection, or any other suitable connection. As used herein, a persistent connection refers to a network communication channel that is maintained open between the sensors 118A-C and the computing system 104. As used herein, a non-persistent connection refers to a network communication that can be interrupted, established on demand, or otherwise maintained in a non-persistent manner between the sensors 118A-C and the computing system 104.

[0023] Computing system 104 may be a computing system communicatively coupled to main network 102 via network 112. Computing system 104 may be a computer, controller, server, or storage system hosted on a public cloud, private cloud, or hybrid cloud. In some examples, computing system 104 may be any suitable device with hardware processor 114, such as one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 116. Processor 114 may fetch, decode, and execute instructions, such as instructions for identifying roaming issues in main network 102. In some examples, machine-readable storage medium 116 may be a non-transitory storage medium, where the term "non-transitory" excludes transient propagation signals. As described in detail below, machine-readable storage medium 116 may be encoded with executable instructions for identifying roaming issues. These instructions include instructions for wireless roaming initiator 120, traffic capture device 122, and traffic analyzer 124. In some examples, computing system 104 may be implemented as a service running in a “cloud computing” environment or as “Software as a Service” (SaaS).

[0024] The computing system 104 can perform various functions to test wireless roaming performance in the main network 102. The computing system 104 can initiate wireless roaming for the sensor 118A, such as... Figure 1 As shown by the dashed arrow 126 in the diagram. When a Wi-Fi client associated with one AP moves or switches to another AP in the ESS, it can be said to be "roaming" between the two APs. During wireless roaming, the Wi-Fi client may unassociate from one AP in the ESS and reassociate with another AP. The AP with which the Wi-Fi client unassociated can be called the source AP, and the other AP with which it reassociated can be called the target AP. As previously described, sensors 118A-C can mimic the behavior of a Wi-Fi client. In one example, computing system 104 can automatically initiate wireless roaming for such a sensor at predefined time intervals or based on input from a network administrator.

[0025] refer to Figure 1, the processor 114 can execute the wireless roam initiator 120 stored in the machine-readable storage medium 116 to initiate a wireless roam of the sensor 118A. Consider that the sensor 118A is associated with the AP 106A and the computing system 104 initiates a wireless roam from the AP 106A to the AP 106B. Thus, the AP 106A is the source AP and the AP 106B is the target AP. In one example, the wireless roam initiator 120 can trigger the sensor 118A to lower its transmission power below a threshold. In response to the transmission power lowering, the source AP 106A can send a basic service set (BSS) transition management (BTM) request to the sensor 118A according to the Institute of Electrical and Electronics Engineers (IEEE) 802.1 lv. The IEEE 802.1 lv is a standard for wireless network management (WNM) according to which APs and wireless clients can exchange information with each other in order to improve their performance. The BTM request is a suggestion of available APs to which a Wi-Fi client can transition from a given AP. The Wi-Fi client can decide on its own whether to follow the suggestion. In another example, the wireless roam initiator 120 can trigger the sensor 118A to send a BTM query to the source AP 106A. The BTM query can refer to a message sent by a Wi-Fi client to the AP with which it is currently associated, requesting a BTM request message from the AP. In another example, the wireless roam initiator 120 can trigger the source AP 106A to send an unsolicited BTM request to the sensor 118A.

[0026] In one example, the BTM request can include a list of BSS transition candidates. In one example, the list of BSS transition candidates can contain one or more Neighbor Report elements that describe the preference of a target BSS candidate or a target AP. The BTM request can include a preference field value that establishes a relative order of preference of the target APs in a given list. Referring to Figure 1 , the target AP 106B can be included in the list of BSS transition candidates sent by the AP 106A in the BTM request. The processor 114 can execute the wireless roam initiator 120 to cause the sensor 118A to send a BTM response to the source AP 106A accepting the transition to the target AP 106B. The BTM response can include the result of the sensor 118A's BSS transition decision in a target BSSID field and a status code field in the BTM response. For example, the target BSSID field can include the BSSID of the target AP 106B and the status code field can be set to a value of 0 (i.e., accept) indicating that the sensor 118A will transition from the source AP 106A to the target AP 106B indicated in the target BSSID field. In response to the sensor 118A sending the BTM response, the transition of the sensor 118A from the source AP 106A to the target AP 106B can be initiated.

[0027] In another example, the processor 114 can execute the wireless roam initiator 120 to initiate a scan by the sensor 118A. The sensor 118A can scan for networks to identify a list of BSS transition candidates. In one example, the sensor 118A can identify the list of BSS transition candidates based on a neighbor report from the AP 106A according to IEEE 802.1 lk. IEEE 802.1 lk amendment, also known as radio resource measurement (RRM), allows stations to inform each other of their respective radio frequency (RF) environments. Using IEEE 802.1 lk, a Wi-Fi client can request an AP to send a neighbor report. Thus, the sensor 118A can also send a request for a neighbor report to the source AP 106A, which can respond with a neighbor report. The neighbor report can include the target AP 106B. The processor 114 can execute the wireless roam initiator 120 to cause the sensor 118A to send a BTM response to the source AP 106A to accept a transition to the target AP 106B, thereby initiating wireless roam.

[0028] During wireless roam, the processor 114 can execute the traffic capture 122 stored in the machine-readable storage medium 116 to monitor management traffic between the sensor 118A and the source AP 106A or the target AP 106B. Management traffic can refer to data exchanged between a Wi-Fi client and the source AP and / or target AP it roams between during roam. The management traffic can include neighbor device information, security information, and association / disassociation information. When the Wi-Fi client sends a BTM response to the target AP mentioned in the response, the Wi-Fi client and the target AP can exchange reauthentication messages and reassociation messages. In addition, depending on the security settings associated with the target AP, the Wi-Fi client can further exchange security related messages. For example, if the Wi-Fi client has IEEE 802. lx SSID enabled, the Wi-Fi client and the target AP can establish a master key to start 802. lx Extensible Authentication Protocol (EAP) authentication. Subsequently, in one example, the Wi-Fi client and the target AP can initiate a 4-way handshake. During the 4-way handshake, the Wi-Fi client and the target AP can derive their pairwise transient key (PTK), which is a unique encryption key for their association, from the master key. Reference Figure 1Management traffic exchanged between the sensor 118A and the source AP 106A and the target AP 106B can include the neighbor report received by the sensor 118A from the source AP 106A, the BTM response from the sensor 118A to the source AP 106A, reauthentication and reassociation messages exchanged between the sensor 118A and the target AP 106B, security related messages exchanged between the sensor 118A and the target AP 106B, and 4-way handshake messages. The processor 114 can execute the traffic analyzer 124 to monitor the power level, data rate, and timing of the management traffic exchanged between the sensor 118 and the source AP 106A or the target AP 106B.

[0029] Further, the processor 114 can execute the traffic analyzer 124 to detect anomalies in the management traffic. An anomaly in the management traffic can refer to a deviation from the expected or predefined management traffic exchange that is to occur between the sensor 118A and the source AP 106A or the target AP 106B during the roam. For example, if any BSS transition management query, request, or response messages exchanged between the sensor 118A and the source AP 106A are dropped or received after an unexpected time delay, reauthentication and reassociation messages exchanged between the sensor 118A and the target AP 106B are dropped, 4-way handshake messages are not exchanged, etc., the traffic analyzer 124 can detect an anomaly in the management traffic. In an example, the traffic analyzer 124 can also consider a response to a neighbor report request sent by the sensor 118A to the source AP 106A not to be received.

[0030] In another example, the traffic analyzer 124 can monitor traffic loss, latency, and roam time. Traffic loss can refer to the difference in the number of packets transmitted by a sender and the number of packets received by a receiver. Thus, traffic loss can refer to the number of packets lost or dropped during transmission. Latency refers to the time it takes for data to travel between its original source and destination. Roam time can refer to the total time taken from the start of the source AP to target AP transition to the completion of the transition by the Wi-Fi client. In an example, thresholds for traffic loss, latency, and roam time can be stored in the computing system 104.

[0031] Thresholds for traffic loss, latency, and roam time can depend on network conditions and AP capabilities. For example, the threshold for roam time can be different for different wireless security configurations. In one example, IEEE 802. lx authentication times can differ with or without IEEE 802.1 Ir fast roam. IEEE 802. lx is an IEEE standard for port-based network access control (PNAC) that provides a secured authentication for secure network access by using an authentication server, such as a remote authentication dial-in user service (RADIUS) server. IEEE 802.1 Ir is a standard that allows continuous connectivity for wireless devices in motion, with clients able to quickly and securely transition from one AP to another in an ESS. With fast roam, the threshold for roam time can be less than the roam time threshold without fast roam.

[0032] The traffic analyzer 124 can measure traffic loss, latency, and roam time during the transition of the sensor 118A from the source AP 106A to the target AP 106B and compare them to their thresholds. The traffic analyzer 124 can identify an anomaly if the measured values deviate from the thresholds. In response to detecting an anomaly in the management traffic, the processor 114 can execute the wireless roam initiator 120 stored in the machine-readable storage medium 116 to restart the wireless roam of the sensor 118A from the AP 106A to the AP 106B. The wireless roam can be restarted based on conditions similar to the conditions of the previous wireless roam of the sensor 118A from the source AP 106A to the target AP 106B. In one example, the wireless roam can be initiated using a similar method as described above.

[0033] During the restarted wireless roam, the processor 114 can execute the traffic capture 122 stored in the machine-readable storage medium 116 to initiate management traffic capture on the sensor 118A. In one example, the traffic capture 122 can cause the sensor 118A to intercept and record the management traffic exchanged between the sensor 118A and the source AP 106A or the target AP 106B. In one example, capturing management traffic refers to the process of intercepting and recording the time, power level, and data rate of different management frames. As the data stream flows through the network, the traffic capture 122 can cause the sensor 118A to capture each packet and, in some examples, decode the raw data of the packet, showing the values of individual fields in the packet.

[0034] Further, the processor 114 can execute the traffic analyzer 124 stored in the machine-readable storage medium 116 to identify a roaming problem for the sensor 118A based on the analysis of the captured management traffic. The roaming problem can refer to unexpected behavior of one or more APs or non-AP STAs in the Wi-Fi network, which can result in network performance degradation during roaming of the non-AP STA in the Wi-Fi network. In one example, the traffic analyzer 124 can identify a roaming problem regarding the sensor 118A roaming from a source AP 106A to a target AP 106B based on the analysis of the captured management traffic. In one example, a set of metrics indicative of roaming performance can be identified from the management traffic and compared to a network performance baseline to identify the roaming problem. The network performance baseline can include a set of metrics used in network performance monitoring to define normal working conditions of the enterprise network infrastructure during roaming.

[0035] Upon identifying the roaming problem, the computing system 104 can report the roaming problem via a dashboard (not shown) coupled thereto. The dashboard can be displayed on a website or application accessible to a network administrator of the main network 102. In one example, the dashboard represents a front-end interface of the computing system 104. In some examples, the computing system 104 can also send a notification to the network administrator when the roaming problem is discovered. Further, in some examples, the computing system 104 can recommend a corrective action to resolve the roaming problem via the notification. The corrective action can include one or more of: a firmware update, a software update, and / or a configuration change for the STA subject to the roaming problem. After the corrective action is implemented, the roaming problem can be considered resolved.

[0036] Figure 2A And Figure 2B A flowchart of a method 200 for roaming problem identification in a network according to embodiments of the present application is shown. The network can be a main network, such as the main network 102 of Figure 1 In one example, the steps of the method 200 can be performed by a computing system, such as the computing system 104 of Figure 1 In one example, the steps of the method 200 can be performed by a computing system, such as the computing system 104 of

[0037] At block 202, wireless roaming of the sensor from a source AP to a target AP can be initiated. The source AP can be the AP to which the sensor is currently associated, and the target AP refers to another AP in the ESS. In one example, the computing system can initiate the wireless roaming of such a sensor automatically at predefined time intervals or based on input from a network administrator. The initiation of the wireless roaming includes triggering the exchange of management traffic between the sensor and the source AP or the target AP. In one example, the management traffic can include a neighbor report received by the sensor from the source AP, a BTM response from the sensor to the source AP, reauthentication and reassociation messages exchanged between the sensor and the target AP, security related messages and 4-way handshake messages exchanged between the sensor and the target AP.

[0038] At block 204, it can be checked whether the sensor receives a BTM request. In one example, if the BTM request is in response to a BTM query initiated by the computing system from the sensor, the computing system can check whether the BTM request is received within a predefined time. Further, if the BTM request from the source AP is in response to the transmit power of the AP being reduced by the computing system, the computing system can check the reception of the BTM request within a predetermined time from the reduction of the transmit power.

[0039] If the BTM request is not received within the predefined time (the "No" branch from block 204), the computing system can detect an anomaly in the management traffic at block 210. The anomaly in the management traffic can refer to a deviation from the expected or predefined exchange of management traffic that would occur between the sensor and the source AP or the target AP during the wireless roaming. The anomaly can include a failure to receive a management frame or an unexpected time delay in receiving a management frame.

[0040] In response to receiving the BTM request (the "Yes" branch from block 204), it can be verified whether the BSS transition candidate in the BTM request is based on a neighbor report at block 206. In one example, the computing system can monitor the IEEE 802.1 Ik neighbor report and the BTM request from the source AP to the sensor. If a basic service set identifier (BSSID) present in the neighbor report is also included in the BTM request (the "Yes" branch from block 206), the computing system can determine that the BSS transition candidate is based on the neighbor report and can allow the sensor to roam to the target AP at block 208. Since no anomaly in the management traffic is detected, which indicates that the likelihood of a roaming issue can be small, the sensor is allowed to roam to the target AP. In one example, the sensor can roam to one of the APs mentioned in the BSS transition candidate. After a predetermined interval of completing the roaming, the method 200 can be reinitiated for the sensor.

[0041] Differences between candidate APs in the BSS switching candidate and neighbor APs in the neighbor report can indicate the likelihood of roaming issues. Therefore, in response to a mismatch between the BSSID in the BSS switching candidate included in the BTM request and the BSSID in the neighbor report (from the "No" branch of box 206), an anomaly in the management service is detected in box 210. Although in method 200, differences between the BSS switching candidate and the neighbor report are detected as anomalies, in some other examples, other deviations in the management services exchanged between the sensor and the source / target AP can also be detected as anomalies.

[0042] In response to the detection of an anomaly, in box 212, the sensor's wireless roaming from the source to the target AP can be restarted. Restarting wireless roaming refers to initiating roaming of the sensor from the same source to the same target AP, as performed in box 202. Restarting sensor roaming allows the re-creation of similar management service exchanges between sensors, and thus the re-creation of the network conditions during the period when the anomaly was detected in box 210.

[0043] Box 214, Initiating Management Traffic Capture on the Sensor. In one example, the computing system can enable the sensor to intercept and record management traffic exchanged between the sensor and the source / target AP. In one example, capturing management traffic refers to the process of intercepting management frames and recording their time, power level, and data rate. The sensor can intercept management traffic in its own operating channel.

[0044] Further, in one example, the management traffic capture can be initiated on a set of neighboring sensors of the roving sensor. The set of neighboring sensors can include sensors within a predefined geographical area from the roving sensor and those belonging to the same ESS. At block 216, a first sensor from the set of neighboring sensors can be configured to capture management traffic on a first WLAN channel on which the source AP is operating. A WLAN channel refers to a sub-division of a frequency band in the radio frequency (RF) spectrum of the wireless medium used for wireless communication. An AP or a non-AP STA can be tuned to operate in a particular WLAN channel at a time. Once the first sensor is tuned to operate on the first WLAN channel, it can communicate with the AP operating on the same channel. Thus, the first sensor can intercept and record the management traffic exchanged between the source AP operating in the first WLAN channel and the sensor for which the roaming is initiated. Since additional sensors other than the sensor that is roaming are used for capturing the management traffic in the first WLAN channel, the management traffic to / from the source AP can be captured in a comprehensive manner even after the sensor roams away from the source AP during the re-initiated roaming. This allows a clearer picture of the management traffic originating from the source AP, facilitating a complete analysis of the management traffic for roaming problem identification. The packet captures from different neighboring sensors can be merged, collated, processed, and analyzed to obtain a comprehensive view of the management traffic exchanged during the wireless roaming.

[0045] Likewise, at block 218, a second sensor from the set of neighboring sensors can be configured to capture management traffic on a second WLAN channel on which the target AP is operating. Once the second sensor is tuned to operate on the second WLAN channel, it can communicate with the AP operating on the same channel. Thus, the second sensor can intercept and record the management traffic exchanged between the target AP operating in the second WLAN channel and the sensor for which the roaming is initiated. Since additional sensors other than the sensor that is roaming are used for management traffic capture in the second WLAN channel, the management traffic to / from the target AP can be captured in a comprehensive manner even before the sensor switches or re-associates with the target AP. This allows a clearer picture of the management traffic originating from the target AP, facilitating a complete analysis of the management traffic for roaming problem identification.

[0046] Further, it can be noted that the management traffic capture in the set of neighboring sensors (i.e., the first and second sensors in the first and second WLAN channels) is not initiated unless an anomaly in the management traffic is detected at block 210. That is, the management traffic is not captured throughout the wireless roam. This conditional capture of management traffic in the neighboring sensors can allow selective execution of the traffic capture apparatus at the neighboring sensors, thereby optimally utilizing processing and memory resources to analyze and store the captured management traffic.

[0047] At block 220, a set of key performance indicators (KPIs) of network performance can be determined from the management traffic exchanged within the time interval from restarting the roam to the sensor successfully transitioning to the target AP. The KPIs can refer to a set of metrics that indicate the network performance of the sensor during the roam from the source to the target AP. The KPIs can include client roam time, roam type (i.e., 802.11r - fast BSS transition), and network management statistics (such as 802.11k radio resource management / 802.11v - BSS transition management (BTM) information), among others.

[0048] At block 222, the computing system can identify a roam issue based on the set of KPIs and a network performance baseline. In one example, the network performance baseline can include a set of metrics used in the network performance monitoring to define the normal working conditions of the enterprise network infrastructure during the roam. In one example, the set of KPIs can be illustrated using a scatter plot that can be compared to the network performance baseline. In some examples, the network administrator can use different analysis and plotting techniques to obtain a graphical representation of the KPIs with respect to the network performance baseline. A deviation between the set of KPIs and the network performance baseline can indicate that a roam issue has occurred.

[0049] Once the roam issue is identified, at block 224, the computing system can report the roam issue via a dashboard. In one example, the dashboard can represent a front-end interface of the computing system. In some examples, the computing system can also send a notification to the network administrator in the event that a roam issue is identified. Further, in some examples, the computing system can recommend a corrective action to resolve the roam issue via the notification.

[0050] Figure 3 FIG. 13 illustrates a graphical representation 300 of the captured management traffic, according to one example. In one example, the dashboard (front-end of the computing system) can include a roam tab that a user can invoke to display the graphical representation 300. In one example, the graphical representation 300 can be obtained by merging and plotting the management traffic captured when performing the method 200.

[0051] As Figure 3The captured management traffic can be plotted in a scatter plot, as shown in graphical representation 300. Upon restarting the sensor's roam in response to detecting an anomaly in the management traffic, the computing system can initiate management traffic capture at the set of neighboring sensors as the sensor roams from one AP to another. The captured management traffic can be plotted and displayed in a dashboard. In one example, the captured management traffic can include neighbor request / report pairs exchanged between the sensor and the source AP, BTM responses from the sensor to the source AP, reauthentication and reassociation messages exchanged between the sensor and the target AP, security related messages and 4-way handshake messages exchanged between the sensor and the target AP. One or more types of management traffic can be displayed in graphical representation 300 based on user selection.

[0052] In an example, the primary vertical axis (SNR) and the secondary vertical axis (data rate) are always visible on the graph, and the display of groupings along the corresponding axes depends on user selection. The horizontal axis represents time in milliseconds. In one example, graphical representation 300 can display management frames associated with the IEEE 802.11v wireless network management (WNM) standard, the 802.11k radio resource measurement (RRM) standard, or the IEEE 802.1x network access control standard that are exchanged during the sensor's reinitiated roam. One or more of the above management frame exchanges can be selected by a user to display in the graphical representation.

[0053] Graphical representation 300 shows authentication / reauthentication request 302, association / reassociation request 304, authentication / reauthentication response 306, association / reassociation response 308, and 802.11k neighbor report request 310. The SNR, data rate, and timing of these messages can be derived from graphical representation 300. As can be seen from graphical representation 300, the source AP does not respond when the sensor sends the 802.11k neighbor report request to the source AP. The lack of response to the management frames can indicate that there is a roam problem. In one example, the computing system can send a notification indicating that the source AP has a roam problem related to the IEEE 802.11k protocol. Similarly, any management frame retries can also indicate a roam problem.

[0054] Figure 4 is a flowchart of a method 400 for identifying a roam problem, according to one example. In one example, the steps of method 400 can be performed by a computing system, such as computing system 100, described above. Figure 1the computing system 104. At block 402, wireless roaming of the sensor from the source AP to the target AP can be initiated. The source AP and the target AP belong to the same ESS. Initiating the wireless roaming can include triggering an exchange of management traffic between the sensor, the source AP, and the target AP for the sensor's transition from the source AP to the target AP. In one example, initiating the roaming can include triggering the sensor to reduce its transmit power below a predetermined threshold. In response to the sensor receiving a basic service set (BSS) transition management (BTM) request from the source AP, the sensor can be caused to send a BTM response to the source AP accepting the transition to the target AP. The BTM request can include a BSS transition candidate list including the target AP.

[0055] At block 404, management traffic between the sensor and one of the source AP or the target AP is monitored during the wireless roaming. The management traffic can refer to data exchanged between the Wi-Fi client and the source AP and / or the target AP it roams between during the roaming. The management traffic can include neighbor device information, security information, and association / disassociation information. In one example, monitoring the management traffic includes monitoring at least one of the following during the wireless roaming: traffic loss, latency, roaming time, and AP capabilities.

[0056] At block 406, in response to detecting an anomaly in the management traffic, the wireless roaming of the sensor from the source AP to the target AP is reinitiated. Reinitiating the wireless roaming includes resuming the exchange of management traffic for the roaming. Reinitiating the wireless roaming recreates the network conditions under which the sensor roamed during which the anomaly was detected. In one example, the anomaly in the management traffic includes a failure to receive a response to a neighbor report request sent by the sensor to the source AP.

[0057] At block 408, during the reinitiation of the wireless roaming, management traffic capture can be initiated on the sensor. The management traffic exchanged between the sensor and the source or target AP can be captured by the sensor. In another example, initiating the management traffic capture includes configuring a first sensor from a set of neighboring sensors to capture management traffic on a first WLAN channel on which the source AP is operating. In another example, initiating the management traffic capture includes configuring a second sensor from the set to capture management traffic on a second WLAN channel on which the target AP is operating.

[0058] At block 410, a roaming issue of the sensor can be identified based on the analysis of the captured management traffic. In one example, a set of KPIs of network performance can be determined from the management traffic exchanged within a time interval from restarting the wireless roaming simulation to the sensor successfully transitioning to the target AP. The roaming issue can be identified based on the set of KPIs and a network performance baseline. Further, the roaming issue can be reported by displaying a notification on a dashboard indicating the roaming issue.

[0059] Figure 5 A block diagram of an example computer system 500 is depicted wherein various embodiments described herein can be implemented. The computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a one or more hardware processors 504 coupled with bus 502 for processing information. Hardware processor(s) 504 can be, for example, one or more general purpose microprocessors.

[0060] Computer system 500 also includes a main memory 506, such as a random access memory (RAM), cache and / or other dynamic storage devices, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 also can be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504. Such instructions, when stored in storage media accessible to processor 504, render computer system 500 into a special-purpose machine that operates to perform the operations specified in the instructions.

[0061] Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504. A storage device 510, such as a magnetic disk, optical disk, USB thumb drive (flash drive), etc., is provided and coupled to bus 502 for storing information and instructions.

[0062] Computer system 500 can be coupled via bus 502 to a display 512, such as a liquid crystal display (LCD) (or touch screen), for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to bus 502 for communicating information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for

[0063] The computing system 500 can include a user interface module to implement a GUI that can be stored in mass storage device as executable software code that is executed by the computing device(s). As examples, this and other modules can include components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

[0064] Generally, as used herein, the words "component," "system," "database," and the like can refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, C or C++. A software component can be compiled and linked into an executable program, installed in a dynamic link library, or can be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software components can be callable from other components or from themselves, and / or can be invoked in response to detected events or interrupts. Software components configured for execution on computing devices can be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and can be originally stored in an encoded or compressed format that requires installation, decompression, or decryption prior to execution). Such software code can be stored, partially or entirely, on a storage device locally accessible to the computing device, such as, for example, on a hard disk or other memory resource. Software instructions can be embedded in firmware, such as an EPROM. It will also be appreciated that hardware components can be comprised of connected logic units, such as gates and flip-flops, and / or can be comprised of programmable units, such as programmable gate arrays or processors.

[0065] The computer system 500 can implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and / or program logic which in combination with the computer system causes or programs computer system 500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to the

[0066] As used herein, the term “non-transitory medium” and similar terms, refer to any medium that stores the data and / or instructions that cause a machine to operate in a specific manner. Such non-transitory medium can include non-volatile media and / or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as the storage device 510. Volatile media includes dynamic memory, such as the main memory 506. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, a hard disk, a solid state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

[0067] Non-transitory media differ from transmission media although the latter can be included in non-transitory media. Transmission media participate in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire, and fiber optic cables, including wires that comprise bus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency and infrared data communications.

[0068] Computer system 500 also includes a network interface 518 coupled to bus 502. Network interface 518 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 518 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 518 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicate with a WAN). Wireless links can also be implemented. In any such implementation, network interface 518 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0069] Network links typically provide data communication through one or more networks to other data devices. For example, a network link can provide a connection through a local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet.” Local networks and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on network link and through network interface 518 are examples of transmission media.

[0070] Computer system 500 can send messages and receive data, including program code, through the network(s), network link(s), and communication interface(s) 518. In the Internet example, a server might transmit a requested code for an application program through the Internet, ISP, local network and communication interface 518. The received code can be executed by processor 504 as it is received, and / or stored in storage device 510, or other non-volatile storage for later execution.

[0071] Each of the processes, methods, and algorithms described in the preceding sections can be embodied in, and fully or partially automated by, code components of one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors also can be programmed to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). The various processes and functions can be described in the general context of the computer system or computer processor, including aspects of the code components described herein. Software and hardware components can include modules, units or code that execute on a computer system or computer processor, and / or include the components that execute on a computer system or computer processor. Processes and algorithms can be realized partially or wholly in application-specific circuitry. The various components and processes described herein can be used independently of, and in two or more combinations of, one another in various embodiments. Different combinations and sub-combinations of the various embodiments and features are intended to fall within the scope of the disclosure, and some implementations can omit certain methods or process steps. The methods and processes described herein are also not limited to any particular order or sequence, and the steps or states involved in those methods and processes can be performed in other orders or sequences, in parallel, or in other suitable manners. Steps or states can be added to or removed from the disclosed example embodiments. The execution of a method or process can be distributed over a computer system or computer processor, residing in more than one location, and being executed on more than one machine.

[0072] As used herein, a circuit can be implemented using any form of hardware, software, or combinations thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a circuit. In implementation, the various circuits described herein can be implemented as discrete circuits or the functions and features described can be shared in part or in total among one or more circuits. Even though individual features or elements of a function can be described or claimed as part of, for example, a single circuit, these features and functions can be shared among one or more circuits, and such description or claim should not be understood as requiring that individual features or elements be part of a single circuit. In instances in which software is used to implement all or part of a circuit, such software can be implemented in any of a variety of ways, including by way of a computer system that includes a processor and a memory.

[0073] As used herein, the term “or” can be construed to mean either a inclusive or exclusive OR. Moreover, the description of resources, operations, or structures as singular or multiple should not be read to exclude the other. Conditional language, such as “can,” “could,” “might,” or “may,” among others, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and / or steps.

[0074] Unless otherwise expressly stated, terms and phrases used in this document and variations thereof, unless otherwise indicated or unless the context clearly dictates otherwise, are to be construed as open ended as opposed to limiting. As examples of the foregoing, the term “including” is to be construed as “including but not limited to” or “including but not limited to, etc. The term “examples” is used to provide examples of what is included, but is not exclusive or limiting. The term “based on” is to be construed as “based at least on” or “based at least primarily on,” etc. The term “one” or “a” is to be construed as “at least one” or “one or more than one,” etc. In some instances, the presence of certain

[0075] Although implementations of the present application have been described in language specific to structural features and / or methods, it is to be understood that the present application is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed and explained in the context of some implementations of the present application.

Claims

1. A method comprising: The computing system initiates wireless roaming from the source AP to the target AP for the sensor in the following manner: The sensor is triggered to reduce its transmission power below a threshold. as well as In response to the sensor receiving a Basic Service Set (BSS) Transition Management (BTM) request from the source AP, wherein the BTM request includes a BSS transition candidate list and the BSS transition candidate list includes the target AP, the sensor sends a BTM response indicating that it has received a transition from the target AP to the source AP. During the wireless roaming, the computing system monitors the management transactions between the sensor and either the source AP or the target AP. In response to the detection of an anomaly in the management service, the computing system restarts the wireless roaming from the source AP to the target AP for the sensor; During the restarted wireless roaming, the computing system initiates management service capture on the sensor; as well as The computing system identifies roaming issues for the sensors based on analysis of the captured management data; and The roaming problem is reported by the computing system.

2. The method according to claim 1, wherein detecting the anomaly in the management operation comprises: Monitor a set of neighbor reports sent by the sensor to the source AP; as well as In response to the sensor receiving the BTM request during the wireless roaming, it verifies whether the BSS conversion candidate list in the BTM request was obtained based on the set of neighbor reports.

3. The method according to claim 1, wherein the anomaly in the management operation includes: No response was received to the neighbor report request sent by the sensor to the source AP.

4. The method according to claim 3, further comprising: In response to the detection of the anomaly, a management service capture is initiated at a set of adjacent sensors, wherein initiating the management service capture at the set of adjacent sensors includes: The first sensor from the set is configured to capture management traffic on a first WLAN channel, where the source AP is operating on the first WLAN channel; and A second sensor from the set is configured to capture management traffic on a second WLAN channel, on which the target AP is operating.

5. The method according to claim 1, wherein the monitoring and management operations include: During the wireless roaming, at least one of the following should be monitored: service loss, latency, roaming time, and AP capabilities.

6. The method of claim 1, wherein identifying the roaming problem comprises: A set of key performance indicators (KPIs) for network performance are determined from the captured management traffic. as well as The roaming problem is identified based on the aforementioned set of KPIs and network performance baselines.

7. The method of claim 1, wherein the source AP, the target AP, the sensor, and the set of adjacent sensors are included in a single extended service set (ESS).

8. The method of claim 1, wherein reporting the roaming problem comprises: A notification indicating the roaming problem is displayed on a dashboard coupled to the computing system.

9. A computing system, comprising: processor; as well as A memory coupled to the processor, the memory storing instructions executable by the processor to: To initiate wireless roaming from the source AP to the target AP for a sensor, follow these steps: The sensor is triggered to reduce its transmission power below a threshold. as well as In response to the sensor receiving a Basic Service Set (BSS) Transition Management (BTM) request from the source AP, wherein the BTM request includes a BSS transition candidate list and the BSS transition candidate list includes the target AP, the sensor sends a BTM response indicating that it has received a transition from the target AP to the source AP. During the wireless roaming, the management services between the sensor and either the source AP or the target AP are monitored. In response to the detection of an anomaly in the management service, the wireless roaming from the source AP to the target AP for the sensor is restarted; During the restarted wireless roaming, management service capture is initiated on the sensor; Based on the analysis of the captured management data, roaming issues for the sensors are identified; and The roaming issue described in the report.

10. The computing system of claim 9, wherein, in order to detect the anomaly in the management service, the processor is configured to: Monitor a set of neighbor reports sent by the sensor to the source AP; and In response to the sensor receiving the BTM request during the wireless roaming, it verifies whether the BSS conversion candidate list in the BTM request was obtained based on the set of neighbor reports.

11. The computing system of claim 9, wherein the anomaly in the management operation includes: No response was received to the neighbor report request sent by the sensor to the source AP.

12. The computing system of claim 9, wherein the processor is further configured to initiate management service capture at a set of adjacent sensors in response to detecting the anomaly, wherein in order to initiate the management service capture at the set of adjacent sensors, the processor is configured to: The first sensor from the set is configured to capture management traffic on a first WLAN channel, where the source AP is operating on the first WLAN channel; and A second sensor from the set is configured to capture management traffic on a second WLAN channel, on which the target AP is operating.

13. The computing system of claim 9, wherein, in order to monitor and manage services, the processor is configured to monitor at least one of the following during the wireless roaming: service loss, latency, roaming time, and AP capability.

14. The computing system of claim 9, wherein, in order to identify the roaming problem, the processor is configured to: A set of key performance indicators (KPIs) for network performance are determined from the captured management traffic; and The roaming problem is identified based on the aforementioned set of KPIs and network performance baselines.

15. The computing system of claim 9, wherein the source AP, the target AP, the sensor, and the set of adjacent sensors are included in a single extended service set (ESS).

16. The computing system of claim 9, wherein, in order to report the roaming problem, the processor is configured to display a notification indicating the roaming problem on a dashboard coupled to the computing system.

17. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause a computing system to: To initiate wireless roaming from the source AP to the target AP for a sensor, follow these steps: The sensor is triggered to reduce its transmission power below a threshold. as well as In response to the sensor receiving a Basic Service Set (BSS) Transition Management (BTM) request from the source AP, wherein the BTM request includes a BSS transition candidate list and the BSS transition candidate list includes the target AP, the sensor sends a BTM response indicating that it has received a transition from the target AP to the source AP. During the wireless roaming, the management services between the sensor and either the source AP or the target AP are monitored. In response to the detection of an anomaly in the management service, the wireless roaming from the source AP to the target AP for the sensor is restarted; During the restarted wireless roaming, management service capture is initiated on the sensor; Based on the analysis of the captured management data, roaming issues for the sensors are identified; and The roaming issue described in the report.

Images