ACCESS POINT VALIDATION ON NETWORK CHANGE

Abstract

Procedure (500) comprising the following: Detect (502) by a controller (120; 830) a trigger event (140) to validate a network containing a plurality of access points (APs) (130), wherein the trigger event is associated with at least one network configuration change, network firmware upgrade, or network topology change; Identify, by the controller, one AP (210) from the multitude of APs that is associated with the triggering event; Selecting (504), by the controller, a target AP (240) to validate the network from the plurality of APs, based on a neighbor table (220) of the AP associated with the detected trigger event, wherein the selection of the target AP is based either on a neighboring AP that is closest to the AP associated with the detected trigger event or on a neighboring AP that has the lowest workload; Determine (506) by the controller a validation case corresponding to the detected trigger event from a knowledge database (150), wherein the knowledge database stores a plurality of validation cases corresponding to a plurality of trigger events; Send (508), by the controller, the validation case (410) to the target AP; and in response to the execution of the validation case, the controller receives (510) a result (420) of the validation case from the target AP.

Description

background

[0001] With the development of hardware and software, information technology (IT) companies and network providers face new challenges in delivering a better user experience to customers and clients. To ensure a consistent level of performance, 24 / 7 monitoring solutions can proactively improve real-world user experiences. They continuously test network and connectivity performance in specific locations, such as offices, meeting rooms, and other public areas.

[0002] Adaptable test scripts and easy-to-set-up sensors are needed to ensure that every wireless and wired network can handle the influx of mobile and Internet of Things (IoT) devices while guaranteeing the responsiveness of applications required for unrestricted access. A validator that carries out these test scripts plays a crucial role in developing a smart and robust system. Every change must be validated to ensure nothing is broken.

[0003] US 2015 / 0139211A1 describes a method, device, and system for detecting an unauthorized wireless access point (AP) in the field of communication network technologies, which serves to mitigate the problem of information leakage to a certain extent. An authentication client determines the BSSID (Basic Service Set Identifier) ​​of a radio signal with which a connection is to be established and compares it against a valid BSSID list. If the BSSID of the radio signal with which the connection is to be established is not included in the valid BSSID list, the authentication client determines that the access point (AP) corresponding to the BSSID of the radio signal is a rogue AP and generates a corresponding message.

[0004] US 2020 / 0244517A1 describes systems and procedures for the automatic reconfiguration of one or more access points (APs) within a wireless local area network (WLAN). The described automatic reconfiguration can occur in response to the detection of a failure in the wired uplink connection of an access point. For example, the affected device can establish a wireless communication path to use as a mesh connection with a remote wireless access point. Depending on the network configuration type, a master in a master / slave configuration or a controller can instruct the remote wireless access point to become a mesh portal to support the newly established mesh connection. Consequently, network communication for the numerous remote wireless clients of the failed access point can be maintained by the failed access point.The reconfiguration can be performed without interrupting services for client devices or forcing client devices to establish a new network connection with a different access point.

[0005] US 10,462,015 B1 describes embodiments that use sensor APs (e.g., APs not connected to client devices) to detect changes in the physical topology that affect cell coverage areas and to determine cell boundaries for different client devices. In one embodiment of US 10,462,015 B1, a controller can generate baselines that characterize the signals received by the sensor APs from the sensor APs and received by normal APs connected to client devices. At regular intervals or in response to an unexpected action by a client device, one or more of the sensor APs can send another test signal.Since the test signal can be received at several normal APs, the controller can compare the test signal with the baseline values ​​to determine if the physical topology has changed and if this has an impact on the cellular coverage area for the client device.

[0006] US 2017 10 339 728 A1 describes a method for network configuration of a first wireless access point (AP) comprising scanning for a second wireless AP; determining whether the first wireless AP is a network provider or a network participant in a network connection with the second wireless AP according to a determination rule; establishing the network connection with the second wireless AP; and configuring a profile of the first wireless AP when the network connection is established; wherein the second wireless AP is configured to have a profile identical to the profile of the first wireless AP when the network connection is established.

[0007] US 2005 / 0124355A1 describes aspects of validating access point locations in a wireless network. These aspects include performing a scan at a validating access point for another access point in the wireless network. The location data of a detected access point is used at the validating access point to enable self-correction of the validating access point's current location data.

[0008] US 2021 / 0176143A1 describes a wireless access point system comprehensively as comprising a processor configured to intercept event data and process that event data using a variety of event filters. Each of the many event filters applies event criteria to detect one or more types of events. The wireless access point system includes memory configured to store the intercepted event data. The wireless access point system includes a communication interface configured to output a report on the detected event type. At least part of the report is used to analyze the performance of a wireless network.

[0009] US 2025 / 0047577A1 describes a wireless access point system comprising a processor configured to intercept event data and process that event data using a variety of event filters. Each of the many event filters applies event criteria to detect one or more types of events. The wireless access point system includes memory configured to store the intercepted event data. The wireless access point system includes a communication interface configured to output a report on the detected event type. At least part of the report is used to analyze the performance of a wireless network.

[0010] US 2023 / 0053044A1 describes a sample system comprising access points (AP devices) configured to provide a wireless network at a location;and a network management system that stores network data received from the AP devices, network data collected from the AP devices or client devices connected to the wireless network, and one or more processors configured to: receive a time series of SLE metrics based on the network data, determine from the time series whether a network event has occurred, after determining that a network event has occurred, determine the cause of the network event, and after determining that the cause of the network event is related to an AP device, determine a classification of the AP device, and determine a network management action for the AP device based on the network event and the classification of the AP device.

[0011] US 2024 / 0223489A1 describes one or more methods for the automated scheduling and / or orchestration of synthetic tests for network sites. For example, a network management system includes a memory and one or more processors that communicate with the memory and are configured to: determine, based on data received from a variety of network devices on a network, a network state that requires testing, where the network state includes one or more time windows for performing the test or one or more of the network devices that are to perform the test; instruct the network devices to perform the test based on the network state; identify a network problem based on data received from the network devices being tested; and take action based on the identified problem.

[0012] EP 4 395 406 A1 describes one or more methods for the automated planning and / or orchestration of synthetic tests for network sites. For example, a network management system comprises a memory and one or more processors that communicate with the memory and are configured to: determine, based on data received from a variety of network devices in a network, a network state that requires testing, where the network state includes one or more time windows for performing the test or one or more of the network devices that are to perform the test; instruct the network devices to perform the test based on the network state; identify a network problem based on the data received from the network devices under test; and take action based on the identified problem. Brief description

[0013] A method according to claims 1 to 10, a device according to claims 11 to 19 and a non-transitory, computer-readable medium according to claim 20 are disclosed. Brief description of the drawings

[0014] The embodiments of this disclosure are evident from the following detailed description when read together with the accompanying figures. As is customary in the industry, the various features are not drawn to scale. Indeed, the dimensions of the various features may be arbitrarily increased or decreased for the clarity of the discussion. Some examples of this disclosure are described with reference to the following figures: Fig. shows a block diagram of a sample environment in which sample implementations of the present disclosure can be implemented; Fig. shows a block diagram of the selection of a target access point (AP) from a plurality of APs based on a neighbor table of an AP associated with the trigger event according to the implementations of this disclosure; Fig. shows a block diagram for determining the validation case(s) corresponding to the trigger event from the knowledge base according to the implementations of this disclosure; Fig. shows a block diagram of the determination of whether the network change becomes effective based on the result of a validation case run according to implementations of the present disclosure; Fig. shows a flowchart of an exemplary validation procedure according to the explanations of the present disclosure; Fig. shows a flowchart of an example procedure for validating various trigger events according to the implementations of the present disclosure; Fig. shows a block diagram of example scenarios in which example implementations of the present disclosure can be implemented; and Fig. shows an example of a device according to the descriptions in the present disclosure. Detailed description

[0015] Traditional access point (AP) monitoring solutions perform 24 / 7 active monitoring of APs on the network, requiring the deployment of numerous sensors. Cloud-based data processing and a web-based management dashboard can be accessed from anywhere to view monitoring results. However, traditional monitoring solutions cannot validate some Wi-Fi-specific features such as beacons or roaming, and the customer must configure testing to monitor these features.

[0016] As mentioned previously, while traditional monitoring solutions can actively monitor access points (APs) on the network around the clock, deployment is expensive for businesses. Furthermore, deploying these devices and sensors is time-consuming and therefore also costly. Personnel costs should also be considered, as traditional AP monitoring solutions require individually defining test cases for different APs in different scenarios. For these reasons, at least, traditional AP monitoring solutions can be too time-consuming to set up all the necessary test cases. If the network environment changes, the test cases must be reconfigured.

[0017] This highlights several problems with traditional AP monitoring solutions. First, they require additional effort. For example, sensors need to be mounted at the same height where user devices are positioned or held to perform accurate simulated tests over Wi-Fi or Ethernet connections. Installing these sensors in extremely remote locations can be challenging. Second, test cases must be configured in advance and individually for different APs in various scenarios. Tests can be set up for network access, authentication, captive portal response, cloud applications, and internal applications. For instance, in a message transmission scenario, test cases should be configured for each AP on the network.Thirdly, the new configuration might not be monitored due to the second problem mentioned above. For example, if a new IoT beacon is added to the network, the relevant test cases should be modified accordingly to monitor the newly added beacon.

[0018] Therefore, implementations of this disclosure propose a solution for AP validation during a network change. The proposed solution can be implemented by a cloud controller, which can be referred to as the AP validator. According to implementations of this disclosure, after a trigger event (e.g., a configuration change) is detected, the controller receives the relevant validation case(s) and sends the case(s) to a target AP for validation. It can also provide feedback on whether the network change is taking effect, e.g., whether the changed network is functioning as expected.

[0019] Implementations of this disclosure can leverage the existing access point (AP) in the network to validate the network change, eliminating the need for additional deployment. Implementations of this disclosure can be deployed without modifications to the production environment and are therefore cost-effective. Meanwhile, the AP sends back the results of the validation cases, providing information about the current state of the modified network. To better utilize the existing AP for validating the network change, this disclosure provides a knowledge base containing highly optimized test cases corresponding to various trigger events. Each trigger event is mapped to a case or set of cases based on expert experience.Since the cases in the knowledge base have been highly optimized by engineers, implementations of this disclosure can resolve the network problems with expert experience without user perception.

[0020] Further advantages of implementations of the present disclosure are described with reference to the example implementation described below. The following refers to the Fig. until Fig. Reference is made to illustrate the basic principles and various example implementations of the present revelation.

[0021] Fig. shows a block diagram of a sample environment 100 in which sample implementations of this disclosure can be implemented. As in Fig. As depicted, environment 100 contains a Cloud 110, which can comprise a group of cloud servers. By providing Infrastructure-as-a-Service (IaaS) over the internet or a dedicated network connection, Cloud 110 enables businesses to access computing power on demand without having to worry about the underlying infrastructure. Cloud 110 allows businesses to scale quickly while reducing the costs of provisioning computing power.

[0022] As in Fig. As shown, Cloud 110 implements a Controller 120, which can be a computer program for AP validation. The role of Controller 120 is to receive data (such as the trigger event 140) from the network and determine the appropriate test strategy (such as validation cases). Once the validation cases are determined, they are sent to a target AP (also called a candidate AP) for execution. Controller 120 can then receive a result from the validation process. Depending on the result, Controller 120 can determine whether the change will take effect on the network. If something is incorrect or abnormal, Controller 120 can automatically send an alert to an administrator.

[0023] Trigger event 140 can encompass a variety of network changes. Examples of triggering events include configuration changes, firmware upgrades, and topology changes. Examples of configuration changes include changes to the Service Set Identifier (SSID) and IoT beacon changes.

[0024] In area 100, there is an AP cluster 130 with a large number of APs. The large number of APs in the network can be used to provide wireless network connectivity. As described in Fig. The diagram shows five APs (such as AP 130-1, AP 130-2, AP 130-3, AP 130-4, and AP 130-5) grouped together as AP Cluster 130. It should be noted that AP Cluster 130 is only an example, and that there may be 100 more APs or more AP Clusters in the environment.

[0025] As in Fig. As shown, a knowledge base 150 is located in environment 100. Knowledge base 150 can communicate with cloud 110 or controller 120. In some implementations, knowledge base 150 can be part of cloud 110 and can store various validation cases. A validation case can be mapped to a corresponding trigger event 140. Several related test cases can be grouped into a set of validation cases, and this set of validation cases can be used to validate the same or related network changes. In some implementations, the validation cases can be designed and optimized by specialist engineers from the network equipment manufacturer.

[0026] Fig. Figure 200 shows a block diagram illustrating the selection of a target AP from a plurality of APs based on a neighbor table of an AP associated with the triggering event, according to implementations of the present disclosure. As shown in Fig. As shown, after trigger event 140 occurs, controller 120 can receive a message about trigger event 140. In this example, trigger event 140 could be an SSID change of AP 130-2. Thus, AP 130-2 can be identified as AP 210, which is connected to trigger event 140.

[0027] As in Fig. As shown, Controller 120 can retrieve a neighbor table 220 from AP 130-2. Neighbor table 220 can contain information specifying the location of APs and their neighbor relationships, aiding in AP localization and wireless network planning. A neighbor table helps each AP keep track of neighboring routers. When a new neighbor is discovered, its address and interface are added to the neighbor table. After Controller 120 receives neighborhood table 220, it can select an AP as the target AP for validation.

[0028] An example neighborhood table 220 is shown in the dashed block 230. As shown in 230, AP 130-2 has two neighboring APs, AP 130-1 and AP 130-2. In some implementations, the selection of the target AP can be based on the nearest AP. For example, AP 130-1 is the nearest AP to AP 130-2, and AP 130-1 is selected as the target AP 240.

[0029] In some implementations, the selection of the target AP can be based on the neighboring AP with the lowest workload among a large number of neighboring APs. For example, Controller 120 might receive the workload of neighboring APs 130-1 and 130-3. If the workload of AP 130-3 is lower than that of AP 130-1, Controller 120 can select AP 130-3 as the target AP 240. Conversely, if the workload of AP 130-1 is lower than that of AP 130-3, Controller 120 can select AP 130-1 as the target AP 240. Because the APs in the network can have different operating conditions and workloads, two mechanisms for selecting the target AP offer flexibility and easy adaptation to the network and the APs.

[0030] Fig. Block diagram 300 shows the determination of the validation case(s) corresponding to the trigger event from the knowledge base, according to the implementations of this disclosure. As in Fig. As shown, controller 120 can receive trigger event 140 and send a query 310 of trigger event 140 to knowledge base 150. Based on query 310, knowledge base 150 can be accessed to retrieve the relevant validation cases. Knowledge base 150 can then send a response 320 back to controller 120. Controller 120 can then determine the validation case or set of validation cases based on response 320.

[0031] An example of the internal structure of knowledge database 150 is in Fig. The knowledge base 150 can contain multiple suites of validation cases, e.g., Suite 331 and Suite 332. Each suite can contain multiple validation cases, and the cases in a suite can correspond to a type of trigger event.

[0032] In some implementations, query 310 may contain an index. For example, index A might refer to a configuration change, and index B to a firmware upgrade. In some implementations, query 310 may contain more detailed information about the triggering event. In some implementations, response 320 may contain indices relating to the validation cases, and controller 120 can determine the appropriate cases based on these indices. In some implementations, response 320 may contain the sequence of validation cases corresponding to the triggering event 140, and then controller 120 can directly determine the validation case.

[0033] Fig. Block diagram 400 shows the determination of whether the network change takes effect based on the result of performing the validation case(s) according to the implementations of this disclosure. The trigger event 140 can be directed to an access point (AP). For example, if the SSID of AP 130-1 is changed, the trigger event 140 is directed to AP 130-1. AP 130-2 is the nearest neighbor AP to AP 130-1, and therefore AP 130-2 can be selected as the target AP.

[0034] Sequentially or in parallel, Controller 120 can determine one or more validation cases 410 (or a series of validation cases) from Knowledge Base 150 according to the trigger event 140. Controller 120 can send the validation case 410 to the target AP (in this case, AP 130-2). AP 130-2 can execute the validation case 210 and send a result 420 of the validation case execution back to Controller 120.

[0035] In some implementations, the target AP can execute a validation case to validate an AP function associated with the detected trigger event. Based on the result of the validation case execution, Controller 120 can determine whether the detected trigger event takes effect on the network. For example, if the SSID of AP 130-2 has changed, Target AP 130-3 can receive and execute a series of validation cases to verify that the SSID of AP 130-2 has indeed changed. This allows the controller to identify problems by automatically executing the validation cases. Technicians can then resolve network issues before customers even notice them, thus increasing customer satisfaction.

[0036] In some implementations, controller 120 can determine whether the detected trigger event will take effect in the network based on the result of validation case 410. In some implementations, result 420 can indicate a success of validation case 410, meaning that the modified network is functioning correctly and everything is as expected.

[0037] In some implementations, the identified set of cases can include multiple cases, e.g., Case 1, Case 2, and Case 3, as in Fig. These validation cases are used to validate the changed part of the network or the access points (APs) affected by trigger event 140. Suppose the triggering event is that AP 130-1 sends a message "123456". Case 1 can be sent to AP 130-2 (neighbor AP of AP 130-1) to verify that the message sent by AP 130-1 is 123456. Case 2 can be used to verify that AP 130-3 can hear the message "123456" sent by AP 130-1.

[0038] In some implementations, result 420 may indicate that the modified network is not functioning as expected. In this case, the controller 120 can send an alert associated with the trigger event 140 to an administrator device 430. An administrator using the administrator device 430 can then take the necessary steps to resolve the issues. The validation cases, or series of cases, are dedicated to the trigger event and are mapped to the modified portion of the network and are highly optimized. The effort required to execute the validation cases may be reduced, yet better validation results and greater time efficiency are achieved. Furthermore, unlike traditional monitoring solutions, these validation cases are created by expert engineers, making them more competitive and saving the user time and effort.

[0039] Fig. Figure 502 shows a flowchart of an exemplary validation procedure 500 according to the implementations of the present disclosure. In Figure 502, a controller detects a trigger event for validating a network containing a plurality of access points (APs). For example, the controller 120 detects a trigger event 140, and the trigger event 140 is associated with at least one configuration change, firmware upgrade, or network topology change. For example, the trigger event 140 is associated with an SSID change that is part of a network change.

[0040] For response 504, the controller selects a target access point (AP) from the multitude of APs based on the neighbor table of an AP associated with the detected trigger event. For example, trigger event 140 occurred in AP 130-2, and therefore AP 130-2 is the AP associated with the detected trigger event 140. Controller 120 selects AP 130-3 as the target AP based on the neighbor table of AP 130-2.

[0041] In case 506, the controller determines a validation case corresponding to the detected trigger event from a knowledge base, where the knowledge base stores a multitude of validation cases corresponding to a multitude of trigger events. For example, controller 120 retrieves from knowledge base 150 a set of validation cases 340 that correspond to trigger event 140.

[0042] At 508, the controller sends the validation case to the target AP. For example, controller 120 sends the series of validation cases 340 to target AP 130-3, and target AP 130-3 executes the validation case to validate the network change.

[0043] At 510, after the validation case has been executed, the controller receives a result of the validation case execution from the target AP. For example, controller 120 receives the result of the execution of the series of validation cases 340 from target AP 130-3, and the controller can use the result of the execution of the series of validation cases 340 to verify whether the network change takes effect.

[0044] In this way, Method 500 can contribute to building a smart and robust system, as the access points (APs) have greater network coverage and more powerful computing capabilities. At the same time, Method 500 provides feedback on the performance of the validation cases, so the controller knows the status of the network or AP(s) if the network change fails to take effect.

[0045] Fig. Figure 600 shows a flowchart of an example procedure 600 for validating various detected trigger events according to implementations of the present disclosure. At step 602, the controller 120 can detect the trigger event 140. At step 604, the controller 120 can determine whether the trigger event 140 is associated with a configuration change (CONFIG). If the trigger event 140 is a configuration change, the procedure 600 continues with step 606; otherwise, the procedure 600 continues with step 622.

[0046] At procedure 606, the controller can determine whether the configuration change is an SSID change or an IoT beacon (BC) change. If the configuration change is neither an SSID nor an IoT beacon change, procedure 600 continues with 608. If the configuration change is either an SSID or an IoT beacon change, procedure 600 continues with 612.

[0047] For event 608, if the trigger event is a configuration change, Controller 120 can determine one or more network functions affected by the configuration change. For event 610, Controller 120 can receive a validation case to validate the one or more network functions. For example, the configuration change could be a change to the AP 130-1's configuration, where the broadcast message is changed from "123456" to "456789". Controller 120 can determine that only one part of the network has changed, namely the message received from AP 130-1. Controller 120 can then send appropriate validation cases to the target AP to verify that the broadcast message from AP 130-1 has indeed been changed from "123456" to "456789".In some implementations, Controller 120 can iteratively send the validation cases to other APs to confirm that the modified broadcast message from AP 130-1 is being received as expected. This allows the effectiveness of the configuration change to be verified by all APs on the network.

[0048] The modified component, triggered by an event, can be validated to verify that the changed network functions correctly and as expected. This validation of the modified component saves computational effort and time. Furthermore, implementations of this disclosure are performed based on the triggered event. This means that if no event is triggered, there is no need to perform the validation checks, thus saving energy and extending the lifespan of the relevant equipment.

[0049] At step 612, the controller 120 can determine whether the configuration change is an SSID change or an IoT beacon change. If the configuration change is an SSID change, procedure 600 continues with step 614. If the configuration change is an IoT beacon change, procedure 600 continues with step 618.

[0050] At 614, Controller 120 can instruct the target AP to set up a virtual Wi-Fi station AP (VAP) to connect to a neighboring base SSID (BSSID). At 616, Controller 120 can instruct the target AP to generate traffic to validate a function of the neighboring BSSID. For example, Controller 120 can retrieve the set of validation cases according to the new SSID configuration. Controller 120 can send instructions to the target AP to perform the set of validation cases. It should be noted that the instructions can be a script or scripts that can be executed by APs, such as Lua scripts, Python scripts, etc. The target AP can receive the instructions and set up a Wi-Fi station VAP to connect to the neighboring BSSID.During the validation process, the target AP can behave like a station and generate some traffic to verify the functionality of the target BSSID. In some implementations, the Controller 120 can configure this process to repeat the entire group of APs or the network. After validation, the Controller 120 can decommission the Wi-Fi station VAP.

[0051] In case 618, Controller 120 can instruct the target AP to check a received IoT beacon. In case 620, Controller 120 can instruct the target AP to validate the payload of the received IoT beacon. For example, Controller 120 can retrieve the suite of cases corresponding to the IoT configuration. Controller 120 can send the instructions to the target AP, and the target AP can check out the received beacon and verify the payload. In some implementations, Controller 120 can configure this process to repeat across the entire group of APs or the network. In some implementations, the beacon payload can be in JSON format. In some implementations, the parameters of the beacon payload can describe the gateway MAC address that received the beacon packet, the IoT AP IP address, the IoT AP model, the IoT AP image version, the IoT AP serial number, etc.

[0052] As in Fig. As shown, controller 120 can determine at step 622 whether the trigger event is a firmware upgrade (FW) or a topology change (TOPO). If the configuration change is a firmware upgrade, procedure 600 continues with step 624. If the configuration change is a topology change, procedure 600 continues with step 628.

[0053] In case 624, if the detected trigger event is a firmware upgrade, the Controller 120 can receive a firmware upgrade patch list. In case 626, the Controller 120 can detect an updated AP on the network and determine the validation case according to the patch list in order to validate one or more functions of the updated AP.

[0054] In some implementations, the patch list can be used to create custom patch reports, gain patch intelligence, make informed patch decisions, report patch compliance, and communicate risks. The patch list can display patches associated with a specific task.A patch can belong to one of the following types, for example: Security – a software change to fix a vulnerability; Service Pack – a patch for installed software; a collection of updates, fixes, or enhancements delivered in a single installable package; Audit – a type of big fix patch used to identify conditions that may not be fixable and require administrator attention; Enhancement – ​​a change that provides new functionality; Bug Fix – a change that corrects one or more bugs; Configuration – a change that corrects a configuration problem.

[0055] After the Controller 120 receives the patch list, it can identify the upgraded AP on the network and determine the validation case according to the patch list to validate one or more features of the upgraded AP. The Controller 120 can then send instructions to the target AP to execute the validation cases. In some implementations, the Controller 120 may repeat this process across the entire cluster of APs or the network.

[0056] In case 628, if the detected trigger event is a topology change, the controller 120 can determine one or more access points (APs) affected by the topology change. In case 630, the controller 120 can execute the validation case to validate one or more functions of the one or more APs.

[0057] Once the network topology change is detected by Controller 120, it can, for example, select a target AP based on the neighbor table of the changed AP. Controller 120 can then retrieve the set of validation cases to validate the affected AP and send the instructions to the target AP to execute those validation cases. In some implementations, Controller 120 can iterate through the entire AP cluster or network to complete this process.

[0058] Validation method 600 is based on the expertise of specialist engineers, allowing validation cases to be tested automatically without user input. This mechanism makes the validation process imperceptible to the user, and the controller also has access to information about the updated network status.

[0059] Fig. Figure 710 shows a block diagram of example scenarios in which example implementations of the present disclosure can be implemented. As shown, most scenarios apply only to the use of the Controller 120 for AP validation according to the method of the implementations of the present disclosure. Scenarios 710 can, for example, include extensive test suites for Wi-Fi, LAN, DHCP, DNS, authentication, unencrypted portals, IoT beacon addition, and roaming.

[0060] For other scenarios, a combination of using the 120 controller for AP validation and conventional 730 24 / 7 monitoring sensors may be required. These 720 scenarios include, for example, a dashboard with detailed diagnostics and insights, as well as alarm integration with email, SMS, and Slack. These 720 scenarios represent a small percentage of all scenarios. Therefore, the controller for AP validation can be used for most network monitoring situations. Furthermore, implementations of this disclosure can be combined with other solutions in other scenarios.

[0061] Fig. shows an example device 800 according to the implementations of the present disclosure. As in Fig. As shown, the device 800 comprises at least one processor 810 and a memory 820 connected to the processor 810. The memory 820 stores a controller 830 containing instructions 832, 834, 836, 838 and 840 to cause the processor 810 to perform actions according to the implementations of this disclosure.

[0062] As in Fig. As shown, in some embodiments, the Controller 830 can include a portion of scripts or code written in a specific computer language. Instructions 832, 834, 836, 838, and 840 can also be written in a specific computer language. The Controller 830 (and the instructions it contains) can be implemented by a cloud or cloud server (such as the Cloud 110). In some other implementations (not shown), the Controller 830 can be a single electronic device, such as an AP controller, deployed near a production environment.

[0063] The detailed implementations will now be described with reference to Fig. until Fig. , Fig. and Fig. described. As in Fig. As shown, the Controller 830 includes instructions 832 for detecting a trigger event for validating a network with a large number of APs, and the trigger event is associated with at least one configuration change, firmware upgrade, or network topology change. For example, instructions 832 are executed by the Processor 810, and the Processor 810 causes the Controller 830 to detect a trigger event 140.

[0064] In some implementations, trigger event 140 can be one or more configuration changes, a firmware upgrade, or a network topology change. In some implementations, the configuration change might include an SSID change or an IoT beacon change. In some implementations, trigger event 140 is detected by the Controller 830, while in others, trigger event 140 might be user input. For example, trigger event 140 could be a change to the SSID of the AP 130-1 initiated by user input.

[0065] Controller 830 further includes instructions 834 for selecting a target AP from the plurality of APs based on a neighbor table of an AP associated with the detected trigger event. For example, instructions 834 are executed by processor 810, and processor 810 causes controller 830 to select a target AP from AP 130-1, AP 130-2, AP 130-3, AP 130-4, and AP 130-5. This selection can be based on two conditions. One of the two conditions is to select the target AP according to the AP that is closest to the AP associated with trigger event 140. For example, if AP 130-2 is the AP associated with trigger event 140 and AP 130-3 is the nearest AP to AP 130-2, AP 130-3 is selected as target AP 240.

[0066] Another of the two conditions is to select the target AP according to a neighboring AP with the lowest workload among a multitude of neighboring APs. For example, if AP 130-2 is the AP associated with trigger event 140, Controller 830 can receive the workload of neighboring APs 130-1 and 130-3. If the workload of AP 130-3 is lower than that of AP 130-1, Controller 830 selects AP 130-3 as the target AP 240. If the workload of AP 130-1 is lower than that of AP 130-3, Controller 830 selects AP 130-1 as the target AP 240.

[0067] As in Fig. As shown, the controller 830 further includes instructions 836 for determining a validation case corresponding to the detected trigger event from a knowledge base, and the knowledge base stores a variety of validation cases corresponding to a variety of trigger events. For example, the instructions 836 are executed by the processor 810, and the processor 810 causes the controller 830 to determine a set of validation cases 340 corresponding to the detected trigger event 140 from a knowledge base 150. In some implementations, the validation cases can be determined by sending a query 310 to the knowledge base 150 and receiving a response 320 to the query 310.

[0068] The controller 830 also contains instructions 838 for sending the validation case to the target AP. For example, instructions 838 are executed by the processor 810, and the processor 810 causes the controller 830 to send the series of validation cases 340 to the target AP 130-3. When the target AP 130-3 receives the series of validation cases 340, it can execute these cases to validate the operating states of the corresponding AP and also the operating states of the network.

[0069] As in Fig. As shown, the controller 830 further includes instructions 840 that, in response to the executed validation case, receive a result of the execution of the validation case from the target AP. For example, the instructions 840 are executed by the processor 810, and the processor 810 causes the controller 830 to receive the result of the execution of the series of validation cases 340 from the target AP 130-3, and the controller 830 can verify, based on the result of the execution of the series of validation cases 340, whether the network change takes effect.

[0070] In some implementations, controller 830 can be instructed to execute additional instructions to determine whether the detected trigger event will take effect on the network based on the result of validation case 410. In some implementations, result 420 can indicate the success of validation case 410, meaning that the modified network is functioning correctly and everything is as expected.

[0071] In some implementations, result 420 may indicate that the modified network is not functioning as expected. In this case, the controller (830) can send an alert associated with trigger event 140 to an administrator device (430). In some implementations, the alert may first be sent to the administrator's mobile device, such as a mobile phone. Once the alert is received, the administrator can resolve such issues before a major crash occurs and also prevent the user from noticing the problem.

[0072] Some other implementations relating to handling the process flow against any type of triggering event can be found in Fig.These implementations will be shown, and for the sake of simplicity, the present disclosure will not discuss them here. It is understood that the device 800 can incorporate one or more of the aforementioned advantages as described in relation to method 500. For example, the device 800 can automatically verify whether the network change is taking effect in the network and can improve the validation efficiency of network changes. Another example: The device 800 can eliminate the cost of using special sensors for validation.

[0073] Program code or instructions for carrying out the procedures of this disclosure may be written in any combination of one or more programming languages. These program codes or instructions may be made available to a processor or controller of a general-purpose computer, a special-purpose computer, or any other programmable data processing device, such that when executed by the processor or controller, the program codes perform the functions / operations specified in the flowcharts and / or block diagrams. The program code or instructions may be executed entirely on one machine, partially on the machine, as a standalone software package, partially on the machine and partially on a remote computer, or entirely on the remote computer or server.

[0074] In the context of this disclosure, a machine-readable medium can be any tangible medium capable of containing or storing a program for use by or in conjunction with a command-executing system, apparatus, or device. The machine-readable medium can be a machine-readable signaling medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or a suitable combination thereof.More specific examples of a machine-readable storage medium would be an electrical connection with one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0075] Even though the processes are presented in a specific order, this does not mean that these processes must be executed in the presented order or sequentially, or that all presented processes must be executed to achieve the desired results. Multitasking and parallel processing can be advantageous under certain circumstances. Certain features described in connection with separate implementations can also be implemented in combination within a single implementation. Conversely, various features described in connection with a single implementation can also be implemented separately in multiple implementations or in any suitable subcombination.

[0076] The preceding detailed description of this disclosure refers to the accompanying drawings, which form part of this disclosure and illustrate how examples of the disclosure can be carried out. These examples are described in sufficient detail to enable those skilled in the art to put the examples of this disclosure into practice, and it is understood that other examples may be used and that process, electrical, and / or structural modifications may be made without departing from the scope of this disclosure.

Claims

[1] Method (500) comprising the following: Detect (502) by a controller (120; 830) a trigger event (140) to validate a network containing a plurality of access points (APs) (130), wherein the trigger event is associated with at least one network configuration change, network firmware upgrade, or network topology change; Identify, by the controller, one AP (210) from the multitude of APs that is associated with the triggering event; Selecting (504), by the controller, a target AP (240) for validating the network from the plurality of APs, based on a neighbor table (220) of the AP associated with the detected trigger event, wherein the selection of the target AP is based either on a neighboring AP that is closest to the AP associated with the detected trigger event or on a neighboring AP that has the lowest workload; Determine (506) by the controller a validation case corresponding to the detected trigger event from a knowledge database (150), wherein the knowledge database stores a plurality of validation cases corresponding to a plurality of trigger events; Send (508), by the controller, the validation case (410) to the target AP; and in response to the execution of the validation case, the controller receives (510) a result (420) of the validation case from the target AP. [2] Method according to claim 1, wherein the validation case is performed by the target AP to validate a function of the AP that is associated with the detected trigger event, and the method further comprises: Determine, via the controller, whether the detected trigger event will take effect in the network, based on the result of the validation case execution. [3] The method of claim 2, further comprising: In response to a determination that the detected trigger event will not take effect on the network, the controller sends a warning associated with the detected trigger event to an administrator device. [4] The method of claim 1, wherein determining the validation case corresponding to the detected trigger event from the knowledge database comprises the following: Sending, through the controller to the knowledge base, a query (310) about the detected trigger event; Received by the controller from the knowledge base a response (320) to the query, the response containing a set of validation cases (340) corresponding to the detected trigger event; and Determine, by the controller, the series of validation cases based on the response to the query. [5] Method according to claim 1, wherein selecting the target AP from the plurality of APs based on the neighbor table of an AP associated with the detected trigger event comprises: Retrieved by the controller from the neighboring table of the AP associated with the detected trigger event; and Select, by the controller and based on the neighboring table, one of the following as the target AP: an AP that is closest to the AP associated with the detected triggering event, or a neighboring AP with the lowest workload among a multitude of neighboring APs of the AP that is associated with the detected trigger event. [6] The method of claim 1, wherein determining the validation case corresponding to the detected trigger event from the knowledge database comprises the following: In response to the detected trigger event, which is the configuration change, the controller determines one or more network functions that are affected by the configuration change; and Received by the controller, the validation case for validating one or more functions of the network. [7] Method according to claim 6, wherein the configuration change is a Service Set Identifiers (SSID) change and sending the validation case to the target AP comprises: Causing the target AP to set up a virtual Wi-Fi station AP (VAP) to connect to a neighbor's base SSID (BSSID); and To cause the target AP to generate traffic to validate a function of the neighboring BSSID. [8] Method according to claim 6, wherein the configuration change is an Internet of Things (IoT) beacon change and sending the validation case to the target AP comprises: Causing the target AP to check for an heard IoT beacon; and Cause the target AP to validate a payload from the heard IoT beacon. [9] The method of claim 1, wherein determining the validation case corresponding to the detected trigger event from the knowledge database comprises: In response to the detected trigger event, which is the firmware upgrade, the controller receives a patch list for the firmware upgrade; Determine, by the controller, an updated AP in the network and the validation case according to the patch list to validate one or more functions of the updated AP. [10] The method of claim 1, wherein determining the validation case corresponding to the detected trigger event from the knowledge database comprises the following: In response to the detected trigger event, which is the topology change, the controller determines one or more APs affected by the topology change and the validation case to validate one or more functions of the one or more APs. [11] Device (800), comprising: at least one processor (810); and a memory (820) coupled to the at least one processor, wherein the memory stores a controller (120; 830) which includes instructions to cause the at least one processor to: to detect a trigger event (140) to validate a network containing a plurality of access points (APs) (130) (832), wherein the trigger event is associated with at least one network configuration change, network firmware upgrade, or network topology change; to identify one AP (210) from the multitude of APs that is associated with the triggering event; to select a target AP (240) for validating the network from the multitude of APs based on a neighbor table (220) of the AP associated with the detected trigger event (834), wherein the selection of the target AP is based either on a neighboring AP that is closest to the AP associated with the detected trigger event or on a neighboring AP that has the lowest workload; to determine a validation case corresponding to the detected trigger event from a knowledge database (150), wherein the knowledge database stores a plurality of validation cases corresponding to a plurality of trigger events; Send the validation case (410) to the target AP (838); and in response to the execution of the validation case from the target AP to receive a result (420) of the execution of the validation case (840). [12] Device according to claim 11, wherein the validation case is performed by the target AP to validate a function of the AP associated with the detected trigger event, and the controller further comprises instructions to cause the at least one processor to: to determine, based on the result of the validation case, whether the detected trigger event will take effect in the network. [13] Device according to claim 12, wherein the controller further comprises instructions to cause the at least one processor to: In response to a determination that the detected trigger event will not take effect on the network, send an alert associated with the detected trigger event to an administrator device. [14] Device according to claim 11, wherein the instructions for determining the validation case corresponding to the detected trigger event from the knowledge database include instructions to cause the at least one processor to: to send a query (310) to the knowledge base regarding the detected trigger event; to receive a response (320) to the query from the knowledge base, wherein the response contains a series of validation cases (340) corresponding to the detected trigger event; and to determine the series of validation cases based on the response to the query. [15] Device according to claim 11, wherein the instructions for selecting the target AP from the plurality of APs based on the neighbor table of an AP associated with the detected trigger event include instructions to cause the at least one processor to: to obtain the neighboring table of the AP that is assigned to the detected trigger event; and Based on the neighboring table, select one of the following APs as the target AP: an AP that is closest to the AP associated with the detected triggering event, or a neighboring AP with the lowest workload among a multitude of neighboring APs of the AP that is associated with the detected trigger event. [16] Device according to claim 11, wherein the instructions for determining the validation case corresponding to the detected trigger event from the knowledge database include instructions to cause the at least one processor to: in response to the detected trigger event, which is the configuration change, to determine one or more network functions that are affected by the configuration change; and to obtain the validation case for validating one or more functions of the network. [17] Device according to claim 16, wherein the configuration change is a Service Set Identifier (SSID) change, wherein the instructions for sending the validation case to the target AP include instructions to cause the at least one processor to: to cause the target AP to establish a virtual Wi-Fi station AP (VAP) for connection to a neighbor base SSID (BSSID); and to cause the target AP to generate traffic to validate a function of the neighboring BSSID. [18] Device according to claim 16, wherein the configuration change is an Internet of Things (IoT) beacon change and the instructions for sending the validation case to the target AP include instructions to cause the at least one processor to: to instruct the target AP to check for an heard IoT beacon; and to induce the target AP to validate a payload of the heard IoT beacon. [19] Device according to claim 11, wherein the instructions for determining the validation case corresponding to the detected trigger event from the knowledge database include instructions to cause the at least one processor to: In response to the detected trigger event, which is the firmware upgrade, to obtain a patch list for the firmware upgrade; to determine an updated AP in the network and the validation case according to the patch list to validate one or more functions of the updated AP. [20] Non-transitory, computer-readable medium comprising instructions stored on it which, when executed by a processor, cause the processor to: to detect a trigger event (140) for validating a network with a plurality of access points (APs) (130), wherein the trigger event is associated with at least one network configuration change, network firmware upgrade, or network topology change; to identify one AP (210) from the multitude of APs that is associated with the triggering event; to select a target AP (240) from the plurality of APs based on a neighbor table (220) of an AP that is associated with the detected trigger event, wherein the selection of the target AP is based either on a neighboring AP that is closest to the AP that is associated with the detected trigger event or on a neighboring AP that has the lowest workload; to determine a validation case corresponding to the detected trigger event from a knowledge database, wherein the knowledge database (150) stores a plurality of validation cases corresponding to a plurality of trigger events; to send the validation case (410) to the target AP; and in response to the execution of the validation case from the target AP to receive a result (420) of the execution of the validation case.

Images