Access point authentication against network changes

Abstract

In implementations of the present disclosure, a method for access point (AP) verification is provided. The method includes detecting a triggering event for verifying a network comprising a plurality of APs, and selecting a target AP from the plurality of APs based on a neighbor table of the AP associated with the detected triggering event. The method further includes determining a verification use case corresponding to the detected triggering event according to a knowledge base. The method further includes sending the verification use case to the target AP, and receiving an execution result of the verification use case from the target AP in response to the verification use case being executed. Implementations of the present disclosure can automatically verify whether a network change takes effect in the network, and can improve the verification efficiency of the network change.

Description

BACKGROUND

[0001] With the development of hardware and software, information technology (IT) businesses and network providers are facing new challenges to provide better user experiences to customers and clients. To provide consistent performance levels, 7 / 24 monitoring solutions can proactively improve real-world user experiences. It continuously tests network and connection performance in certain locations, such as office spaces, meeting areas, and other types of public spaces.

[0002] Customizable test scripts and easily deployable sensors are needed to help ensure that any wireless and wired networks can handle the influx of mobile and Internet of Things (IoT) devices while providing the application response capabilities required for free access. Such a validator carrying test scripts plays an important role in helping to build intelligent and robust systems. Each change needs to be validated to ensure that nothing is broken. BRIEF DESCRIPTION OF DRAWINGS

[0003] When read in conjunction with the accompanying Figure One Implementations of the disclosure can be understood from the following detailed description when read in conjunction with the accompanying drawings. The various features are not drawn to scale in accordance with standard practice in the industry. In fact, the dimensions of the various features can be arbitrarily increased or decreased for the sake of discussion. Some examples of the disclosure are described with respect to the following drawings:

[0004] Figure 1 A block diagram illustrating an example environment in which example implementations of the disclosure can be implemented is shown;

[0005] Figure 2 A block diagram illustrating selection of a target access point (AP) from a plurality of access points (APs) based on a neighbor table of the AP associated with a trigger event, in accordance with implementations of the disclosure is shown;

[0006] Figure 3 A block diagram illustrating determination of a validation case(s) corresponding to a trigger event from a knowledge base, in accordance with implementations of the disclosure is shown;

[0007] Figure 4 A block diagram illustrating determination of whether a network change takes effect based on an execution result of a validation case, in accordance with implementations of the disclosure is shown;

[0008] Figure 5 A flow diagram illustrating an example validation method, in accordance with implementations of the disclosure is shown;

[0009] Figure 6 A flow diagram illustrating an example method for validating different trigger events, in accordance with implementations of the disclosure is shown;

[0010] Figure 7 A block diagram illustrating an example scenario in which example implementations of the disclosure can be implemented is shown; and

[0011] Figure 8 An example device is shown in accordance with implementations of the present disclosure. DETAILED DESCRIPTION

[0012] Conventional AP monitoring solutions actively monitor APs in a network 7 / 24, and require a large number of sensors to be deployed for monitoring. Cloud-based data processing and web-based management dashboards are accessible from anywhere to view the monitoring results. Conventional monitoring solutions can not be able to verify certain Wi-Fi specific features, such as beacons or roaming, which require clients to set up tests to monitor these features.

[0013] As mentioned above, while conventional monitoring solutions can actively monitor APs in a network 7 / 24, it is too expensive for enterprises to deploy. In addition, it also takes time to deploy these devices and sensors, so it is also time-consuming. Human resource costs should also be considered, because when using conventional AP monitoring solutions, test cases for different APs in different scenarios are determined separately. For at least these reasons, conventional AP monitoring solutions can take too much time to set up all test cases. If any network environment changes, test cases need to be set up again.

[0014] As can be seen, conventional AP monitoring solutions have several problems. First, conventional AP monitoring solutions require additional deployment. For example, sensors should be placed at the same height as user devices are placed or fixed, in order to run accurate simulation tests through Wi-Fi or Ethernet connections. It can be difficult to install these sensors in very remote places. Second, test cases need to be set up in advance and are set up separately for different APs in different scenarios. Tests can be set up for network access, authentication, captive portal response, cloud applications, and internal applications. For example, in the scenario of broadcast messages, test cases should be set up for each AP in the network. Third, due to the second problem mentioned above, new configurations can not be monitored. For example, if a new IoT beacon is added to the network, the corresponding test cases should be modified accordingly to monitor the newly added beacon.

[0015] Therefore, implementations of the present disclosure propose a solution for AP verification for network changes. The proposed solution can be implemented by a controller of the cloud, and the controller can be referred to as an AP verifier. According to implementations of the present disclosure, after detecting a trigger event (e.g., a configuration change), the controller obtains the corresponding verification case(s) and sends the case(s) to the target AP for verification. It can also provide feedback indicating whether the network change is effective, for example, the changed network works as expected.

[0016] Implementations of the present disclosure can use existing AP(s) in the network to validate network changes, and thus do not require additional deployment. Implementations of the present disclosure can be applied to production environments without any changes, and thus it is cost-effective. At the same time, the APs will return the execution results of the validation use cases, thus knowing the update status of the changed network. To better utilize the existing APs to validate network changes, the present disclosure provides a knowledge base that stores highly optimized test cases corresponding to various trigger events. Based on expert experience, each trigger event is mapped to a use case or a suite of use cases. Since the use cases in the knowledge base are highly optimized by engineers, implementations of the present disclosure can solve network problems with expert experience without user perception.

[0017] Other advantages of implementations of the present disclosure will be described with reference to example implementations described below. The basic principles of the present disclosure and several example implementations are explained below with reference to Figures 1 to 8

[0018] Figure 1 A block diagram of an example environment 100 in which example implementations of the present disclosure can be implemented is shown. As Figure 1 shown, in the environment 100, there is a cloud 110 that can include a set of cloud servers. The cloud 110, which provides infrastructure as a service (IaaS) through an Internet or a private network connection, allows enterprises to access computing power on demand while no longer needing to worry about the underlying infrastructure. The cloud 110 enables enterprises to quickly scale out while reducing the cost of configuring computing power.

[0019] With continued reference to Figure 1 , a controller 120 is implemented in the cloud 110, and the controller 120 can be a computer program for AP validation. The role of the controller 120 is to receive data (e.g., trigger events 140) remotely from the network and determine the corresponding test strategy (such as validation use cases). Once the validation use cases are determined, the validation use cases will be sent to the target APs (also referred to as candidate APs) to execute the validation use cases. The controller 120 can receive the execution results of the validation use cases. According to the results, the controller 120 can determine whether the changes are effective in the network. If there are errors or exceptions, an alert can be automatically sent to the administrator by the controller 120.

[0020] The trigger events 140 can include various network changes. Example types of trigger events can include configuration changes, firmware upgrades, and topology changes. Example types of configuration changes can include service set identifier (SSID) changes and IoT beacon changes.

[0021] In the environment 100, there is an AP cluster 130 that includes multiple APs. Multiple APs in a network can be used to provide wireless network connectivity. As Figure 1 ​As shown, five APs (such as AP 130-1, AP 130-2, AP 130-3, AP 130-4, and AP 130-5) are grouped into AP cluster 130. It should be noted that AP cluster 130 is just an example, and there may be more APs or more AP clusters in environment 100.

[0022] like Figure 1 As shown, a knowledge base 150 exists within environment 100. Knowledge base 150 can communicatively connect to cloud 110 or controller 120. In some implementations, knowledge base 150 may be part of cloud 110, and knowledge base 150 may store different verification test cases. Verification test cases can be mapped to corresponding triggering events 140. Several related test cases can be combined into a verification test case suite, and this suite can be used to verify the same or relative network changes. In some implementations, verification test cases may be designed and optimized by expert engineers from the network equipment vendor.

[0023] Figure 2 A block diagram 200 is shown illustrating the selection of a target AP from multiple APs based on a neighbor table of APs associated with a triggering event, according to an implementation of this disclosure. Figure 2 As shown, after trigger event 140 occurs, controller 120 can receive the message for trigger event 140. In this example, trigger event 140 could be a change in the SSID of AP 130-2. Therefore, AP 130-2 can be identified as AP 210 associated with trigger event 140.

[0024] like Figure 2 As shown, controller 120 can obtain the neighbor table 220 of AP 130-2. Neighbor table 220 can include information indicating the location of the AP and its neighbor relationships, helping to locate the AP and plan the wireless network. The neighbor table helps each AP track its neighboring routers. When a new neighbor is learned, its address and interface are recorded in the neighbor table. After controller 120 obtains neighbor table 220, controller 120 can select the AP as the target AP for executing the verification use case.

[0025] One example neighbor table 220 is shown in dashed box 230. As shown in 230, AP 130-2 has two neighbor APs, namely 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 AP closest to AP 130-2, and AP 130-1 is selected as the target AP 240.

[0026] In some implementations, the selection of the target AP can be based on the neighboring AP with the lowest workload among multiple neighboring APs. For example, controller 120 can obtain the workloads 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. Alternatively, 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. Since APs in the network may have different operating conditions and different workloads, both mechanisms for selecting the target AP provide flexibility and easy adaptation to the network and APs.

[0027] Figure 3 A block diagram is shown illustrating how, according to an implementation of this disclosure, multiple verification test cases corresponding to a triggering event are determined based on a knowledge base. For example... Figure 3 As shown, controller 120 can acquire trigger event 140 and send query 310 of trigger event 140 to knowledge base 150. Based on query 310, knowledge base 150 can be retrieved to obtain corresponding verification test cases. Knowledge base 150 can send response 320 back to controller 120. Controller 120 can determine verification test cases or sets of verification test cases based on response 320.

[0028] Figure 3 The diagram illustrates an example internal structure of knowledge base 150, which may have several suites of validation test cases, such as suite 331 and suite 332. Each suite may include several validation test cases, and a test case in a suite may correspond to a type of triggering event.

[0029] In some implementations, query 310 may include indexes. For example, index A indicates a configuration change, while index B indicates a firmware upgrade. In some implementations, query 310 may include some details about the triggering event. In some implementations, response 320 may include indexes about verification use cases, and controller 120 may determine the corresponding use case based on the corresponding index. In some implementations, response 320 may include a suite of verification use cases corresponding to triggering event 140, and then controller 120 may directly determine the verification use case.

[0030] Figure 4A block diagram illustrating determining whether a network change takes effect based on the execution results of the validation use case(s) according to implementations of the present disclosure is shown. Trigger event 140 can be directed to an AP. For example, the SSID of AP 130-1 is changed, which then directs trigger event 140 to AP 130-1. AP 130-2 is the closest neighbor AP to AP 130-1, and thus can be selected as the target AP.

[0031] Sequentially or in parallel, controller 120 can determine the validation use case(s) 410 (or validation use case suite) corresponding to trigger event 140 from knowledge base 150. Controller 120 can send the validation use case 410 to the target AP, which in this example is AP 130-2. AP 130-2 can execute the validation use case 210, and can send the execution results 420 of the validation use case back to controller 120.

[0032] In some implementations, the validation use case can be executed by the target AP to verify the functionality of the AP associated with the detected trigger event. Controller 120 can determine whether the detected trigger event takes effect in the network based on the execution results of the validation use case. As an example, the SSID of AP 130-2 has changed. Target AP 130-3 can receive the validation use case suite, and can execute the validation use case suite to verify whether the SSID of AP 130-2 has changed. In this way, the controller can discover problems by automatically executing the validation use case. The problem can be fixed by an engineer before the customer notices the network problem, thereby improving the satisfaction of the customer experience.

[0033] In some implementations, controller 120 can determine whether the detected trigger event takes effect in the network based on the execution results of the validation use case 410. In some implementations, results 420 can indicate the success of validation use case 410, which means that the changed network is working well and everything is as expected.

[0034] In some implementations, the determined use case suite can include several use cases, such as Figure 4 Use case 1, use case 2, and use case 3 are shown. These validation use cases are used to verify the changed part of the network or APs affected by trigger event 140. As an example, assume that the trigger event is that AP 130-1 broadcasts a message ‘123456’. Use case 1 can be sent to AP 130-2 (a neighbor AP of AP 130-1) to monitor whether the message broadcasted by AP 130-1 is 123456. Use case 2 can be to verify whether AP 130-3 can hear the message ‘123456’ broadcasted by AP 130-1.

[0035] In some implementations, the result 420 can indicate that the changed network does not work as expected. In this case, the controller 120 can send an alert associated with the triggering event 140 to the administrator device 430. The administrator who is using the administrator device 430 can take the next step to find out the problem. The verification use cases or use case suites are specific to the triggering event, and these verification use cases are mapped to the changed part of the network and are highly optimized. It can take less effort to execute the verification use cases, but better verification results and time efficiency can be achieved. On the other hand, unlike traditional monitoring solutions, these verification use cases are prepared by expert engineers, so they are more competitive, saving the user's time and effort.

[0036] Figure 5 A flowchart illustrating an example verification method 500 according to implementations of the present disclosure is shown. At 502, the controller detects a triggering event for verifying a network comprising a plurality of access points, APs. For example, the controller 120 detects the triggering event 140, and the triggering event 140 is associated with at least one of a configuration change, a firmware upgrade, or a topology change of the network. For example, the triggering event 140 is associated with a SSID change that belongs to a network change.

[0037] At 504, the controller selects a target AP from the plurality of APs based on a neighbor table of the AP associated with the detected triggering event. For example, the triggering event 140 occurs in the AP 130-2, so the AP 130-2 is the AP associated with the detected triggering event 140. The controller 120 selects the AP 130-3 as the target AP based on the neighbor table of the AP 130-2.

[0038] At 506, the controller determines a verification use case corresponding to the detected triggering event from a knowledge base, wherein the knowledge base stores a plurality of verification use cases corresponding to a plurality of triggering events. For example, the controller 120 determines the verification use case suite 340 corresponding to the triggering event 140 from the knowledge base 150.

[0039] At 508, the controller sends the verification use case to the target AP. For example, the controller 120 sends the set of verification use cases 340 to the target AP 130-3, and the target AP 130-3 executes the verification use cases for verifying the network change.

[0040] At 510, after executing the verification use cases, the controller receives execution results of the verification use cases from the target AP. For example, the controller 120 receives the execution results of the verification use case suite 340 from the target AP 130-3, and the controller can verify whether the network change takes effect based on the execution results of the verification use case suite 340.

[0041] In this way, the method 500 can help build an intelligent and robust system as APs have more network coverage and APs have more powerful computing capabilities. At the same time, the method 500 provides feedback results about the performance of the validation use cases, so if the network changes do not take effect, the controller will know the situation of the network or AP(s).

[0042] Figure 6 A flowchart illustrating an example method 600 for validating different detected trigger events according to implementations of the present disclosure is shown. At 602, the controller 120 can detect a trigger event 140. At 604, the controller 120 can determine whether the trigger event 140 is related to a configuration change (CONFIG). If the trigger event 140 is a configuration change, the method 600 continues to 606, otherwise the method 600 continues to 622.

[0043] At 606, the controller 120 can determine whether the configuration change is a SSID change or an IoT beacon change (BC). If the configuration change is neither a SSID change nor an IoT beacon change, the method 600 continues to 608. If the configuration change is a SSID change or an IoT beacon change, the method 600 continues to 612.

[0044] At 608, if the trigger event is a configuration change, the controller 120 can determine one or more functionalities of the network that are affected by the configuration change. At 610, the controller 120 can obtain a validation use case for confirming the one or more functionalities of the network. As an example, the configuration change can be a configuration change of the AP 130-1 where a broadcast message changes from ‘123456’ to ‘456789’. The controller 120 can determine that there is only one changed part in the network, which is the message listened from the AP 130-1. The controller 120 can send a corresponding validation use case to the target AP to validate whether the broadcast message from the AP 130-1 changes from ‘123456’ to ‘456789’. In some implementations, the controller 120 can iteratively send the validation use case to other APs to help confirm that the changed message broadcast from the AP 130-1 is received as expected. Thus, the validity of the configuration change can be validated through the entire APs in the network.

[0045] In this way, the changed part due to the impact of the trigger event can be validated to check whether the changed network is normal and works as expected. In this way, validating the changed part can save computing overhead and time. Moreover, the implementations of the present disclosure are performed based on the triggered event. That is, if no event is triggered, there is no need to perform the validation use case, thereby saving the energy and life of the corresponding device.

[0046] At 612, the controller 120 can determine whether the configuration change is a SSID change or an IoT beacon change. If the configuration change is a SSID change, the method 600 continues to 614. If the configuration change is an IoT beacon change, the method 600 continues to 618.

[0047] At 614, the controller 120 can cause the target AP to establish a Wi-Fi station virtual AP (VAP) for connecting to a neighbor basic SSID (BSSID). At 616, the controller 120 can cause the target AP to generate traffic for verifying functionality of the neighbor BSSID. As an example, the controller 120 can fetch a suite of validation use cases according to the new SSID configuration. The controller 120 can send instructions to the target AP to execute the suite of validation use cases. Note that the instructions can be one or more scripts, such as Lua scripts, Python scripts, etc., that can be executed by the AP. The target AP can receive the instructions and establish the Wi-Fi station VAP to connect to the neighbor BSSID. During execution of the validation use cases, the target AP can act as a station and generate some traffic to verify functionality of the target BSSID. In some implementations, the controller 120 can schedule the process to iterate through the entire AP cluster or network. After validation, the controller 120 can tear down the Wi-Fi station VAP.

[0048] At 618, the controller 120 can cause the target AP to inspect a listened-to IoT beacon. At 620, the controller 120 can cause the target AP to verify a payload of the listened-to IoT beacon. As an example, the controller 120 can fetch a suite of use cases corresponding to the IoT configuration. The controller 120 can send instructions to the target AP, and the target AP can inspect the listened-to beacon and verify the payload of the listened-to beacon. In some implementations, the controller 120 can schedule the process to iterate through the entire AP cluster or network. In some implementations, the beacon payload can be in JSON format. In some implementations, the beacon payload parameters can describe a gateway MAC address that received the beacon packet, an IoT AP IP, an IoT AP model, an IoT AP image version, an IoT AP serial number, etc.

[0049] Continuing with reference to Figure 6 At 622, the controller 120 can determine whether the trigger event is a firmware upgrade (FW) or a topology change (TOPO). If the configuration change is a firmware upgrade, the method 600 continues to 624. If the configuration change is a topology change, the method 600 continues to 628.

[0050] At 624, if the detected trigger event is a firmware upgrade, the controller 120 can obtain a patch list for the firmware upgrade. At 626, the controller 120 can determine, from the patch list, upgraded APs in the network and a validation use case for validating one or more functions of the upgraded APs.

[0051] In some implementations, the patch list can be used to create a custom patch report to gain patch intelligence, make intelligent patch decisions, report patch compliance, and communicate risk. The patch list can indicate patches associated with a particular task. For example, a patch can be one of the following types: security - a software change that addresses a vulnerability; service pack - a patch for installed software; a collection of updates, fixes, or enhancements of functionality provided in a single installable package; audit - a BigFix patch type for detecting conditions that can not be remediated and require administrator attention; enhancement - a change that provides new functionality; bug fix - a change that fixes one or more bugs; configuration - a change that addresses a configuration issue.

[0052] Thus, after the controller 120 obtains the patch list, the controller 120 can determine upgraded APs in the network, and the controller 120 can also determine, from the patch list, a validation use case to validate one or more functions of the upgraded APs. The controller 120 can then send instructions to target APs to execute the validation use case. In some implementations, the controller 120 can schedule the process to iterate through the entire AP cluster or network.

[0053] At 628, if the detected trigger event is a topology change, the controller 120 can determine one or more APs affected by the topology change. At 630, the controller 120 can validate a validation use case for validating one or more functions of the one or more APs.

[0054] As an example, after the controller 120 detects a network topology change, the controller 120 can select target APs from the neighbor table of the changed APs. The controller 120 can obtain a use case suite to validate the affected APs and send instructions to the target APs to execute the validation use case. In some implementations, the controller 120 can schedule the process to iterate through the entire AP cluster or network.

[0055] The validation method 600 is based on knowledge from expert engineers, and thus can automatically test validation use cases without any user input. With this mechanism, the validation is transparent to the user, and the controller also holds information about the updated network conditions.

[0056] Figure 7A block diagram of example scenarios in which an example implementation of this disclosure can be carried out is shown. As shown, for most scenarios 710, they are only applicable to using the controller 120 for AP authentication according to the method implemented according to this disclosure. For example, scenario 710 may include a wide range of test suites for Wi-Fi, LAN, DHCP, DNS, authentication, forced portal, IoT beacon addition, and roaming.

[0057] For other scenarios 720, a combination of AP verification using controller 120 and traditional 24 / 7 monitoring sensors 730 may be required. For example, scenario 720 includes dashboards with detailed diagnostics and insights, and integration with email, SMS, and slack alerts. These scenarios 720 represent a small fraction of all scenarios. Therefore, the AP verification controller can be used for most network monitoring situations. Furthermore, in other scenarios, the implementation of this disclosure can be combined with other solutions.

[0058] Figure 8 An example device 800 according to an implementation of this disclosure is shown. For example... Figure 8 As shown, device 800 includes at least one processor 810 and a memory 820 coupled to the processor 810. The memory 820 stores a controller 830, which includes instructions 832, 834, 836, 838, and 840 to cause the processor 810 to perform actions according to the implementation of this disclosure.

[0059] like Figure 8 As shown, in some implementations, controller 830 may include a portion of scripts or code written in a specific computer language. Instructions 832, 834, 836, 838, and 840 may also be written in a specific computer language. Controller 830 (and the instructions included therein) may be implemented by a cloud or cloud server (such as cloud 110). In some other implementations (not shown), controller 830 may be a single electronic device deployed near the production environment, such as an AP controller.

[0060] Now refer to Figures 1 to 4 , Figure 6 and Figure 8 To describe the detailed implementation. For example... Figure 8 As shown, controller 830 includes instructions 832 for detecting a trigger event for verifying a network comprising multiple APs, and the trigger event is associated with at least one of a network configuration change, firmware upgrade, or topology change. For example, instructions 832 are executed by processor 810, and processor 810 causes controller 830 to detect trigger event 140.

[0061] In some implementations, trigger event 140 can be one or more of the following: a network configuration change, a firmware upgrade, or a topology change. In some implementations, a configuration change can include an SSID change or an IoT beacon change. In some implementations, trigger event 140 is detected by controller 830, while in others, trigger event 140 can be user input. For example, trigger event 140 could be a change in the SSID of AP 130-1 for each user input.

[0062] The controller 830 also includes instructions 834 for selecting a target AP from multiple APs based on a neighbor table of APs associated with the detected trigger event. As an 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 may be based on two conditions. One of the conditions is selecting the target AP based on the AP 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 AP closest to AP 130-2, then AP 130-3 is selected as the target AP 240.

[0063] The other of the two conditions is to select the target AP based on the neighboring AP with the lowest workload among multiple neighboring APs. For example, if AP 130-2 is the AP associated with trigger event 140, controller 830 can obtain the workloads 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. Alternatively, 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.

[0064] like Figure 8 As shown, controller 830 also includes instructions 836 for determining verification test cases corresponding to the detected triggering event based on a knowledge base, and the knowledge base stores multiple verification test cases corresponding to multiple triggering events. For example, instructions 836 are executed by processor 810, and processor 810 causes controller 830 to determine a suite 340 of verification test cases corresponding to the detected triggering event 140 from knowledge base 150. In some implementations, the verification test cases(s) can be determined by sending a query 310 to knowledge base 150 and receiving a response 320 to the query 310.

[0065] The controller 830 also includes instructions 838 for sending verification test cases to the target AP. As an example, instructions 838 are executed by the processor 810, which causes the controller 830 to send a set of verification test cases 340 to the target AP 130-3. When the target AP 130-3 receives the set of verification test cases 340, it can execute these test cases to verify the operation of the corresponding AP and the network.

[0066] like Figure 8 As shown, controller 830 also includes instruction 840 that receives the execution result of the verification test case from the target AP in response to the executed verification test case. For example, instruction 840 is executed by processor 810, and processor 810 causes controller 830 to receive the execution result of verification test case suite 340 from target AP 130-3, and controller 830 can verify whether network changes have taken effect based on the execution result of verification test case suite 340.

[0067] In some implementations, additional instructions can be executed to allow controller 830 to determine whether the detected triggering event is effective in the network based on the execution result of verification test case 410. In some implementations, result 420 can indicate the success of verification test case 410, meaning that the modified network is functioning well and everything is as expected.

[0068] In some implementations, result 420 may indicate that the changed network is not functioning as expected. In this case, controller 830 may send an alert associated with triggering event 140 to administrator device 430. In some implementations, the alert may first be sent to a mobile terminal, such as a mobile phone, for administrator use. Upon receiving the alert, the administrator can address the problem before it escalates and prevent users from becoming aware of it.

[0069] For some other implementations related to the process flow for each type of triggered event, please refer to [link / reference]. Figure 6 Furthermore, for simplicity, these implementations will not be discussed in this disclosure. It should be understood that device 800 can achieve one or more of the aforementioned advantages described with respect to method 500. For example, device 800 can automatically verify whether network changes are effective in the network and can improve the efficiency of network change verification. As another example, device 800 can save the cost of deploying dedicated sensors for verification.

[0070] Program code or instructions for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. These program codes or instructions can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing device to produce a machine, such that the program code or instructions, when executed by the processor or controller, create the means for implementing the functions / acts specified in the flowcharts and / or block diagrams. The program code or instructions can be loaded onto a machine, such as a computer, to cause the machine to perform processes, acts, or functions described in the flowcharts and / or block diagrams. The program code or instructions can also be stored in a machine-readable medium, such as a floppy disk, a CD-ROM, a RAM, a ROM, an erasable programmable read only memory (EPROM), a flash memory, or any other suitable memory device, or a combination thereof.

[0071] In the context of the present disclosure, a machine-readable medium can be any tangible medium that can contain or store program code for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an 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.

[0072] Further, although operations are described as being in a particular order, this should not be understood as requiring that particular order or indicating any order at all. One or more operations described can be performed in different orders or concurrently with one another. Certain features that are described in the context of separate implementations can also be implemented in combination with each other. Conversely, various features that are described in the context of a single implementation can also be implemented separately from that single implementation or in any appropriate sub-combination. Some of the features described in the detailed description can be used to implement one or more of the claimed implementations.

[0073] In the foregoing detailed description of implementations, references are made certain drawings that form a part hereof, and in which are shown by way of illustration example implementations of the disclosure. The examples are described in sufficient detail to enable those with ordinary skill in the art to practice the examples of the disclosure, and it is to be understood that other examples can be utilized and that process, electrical, and / or structural changes can be made without departing from the scope of the present disclosure.

Claims

1. A method for communication, comprising: The controller detects triggering events for verifying a network comprising multiple access points (APs), the triggering events being associated with at least one of the network's configuration change, firmware upgrade, or topology change; The controller identifies the AP associated with the triggering event among the plurality of APs; The controller selects a target AP from the plurality of APs for verifying the network based on the AP's neighbor table associated with the detected triggering event. The selection of the target AP is based on either the AP's nearest neighbor AP associated with the detected triggering event or the neighbor AP with the least workload. The controller determines the verification test case corresponding to the detected triggering event based on a knowledge base, wherein the knowledge base stores multiple verification test cases corresponding to multiple triggering events; The controller sends the verification test case to the target AP; as well as In response to the execution of the verification test case, the controller receives the execution result of the verification test case from the target AP.

2. The method of claim 1, wherein the verification test case is executed by the target AP to verify the functionality of the AP associated with the detected triggering event, and the method further comprises: The controller determines whether the detected triggering event is effective in the network based on the execution result of the verification use case.

3. The method according to claim 2, further comprising: In response to determining that the detected triggering event is not effective in the network, the controller sends an alarm associated with the detected triggering event to the administrator device.

4. The method of claim 1, wherein determining the verification use case corresponding to the detected triggering event based on the knowledge base comprises: The controller sends a query to the knowledge base regarding the detected triggering event; The controller receives a response to the query from the knowledge base, the response including a suite of verification test cases corresponding to the detected triggering event; as well as The controller determines the suite of validation use cases based on the response to the query.

5. The method of claim 1, wherein selecting the target AP from the plurality of APs based on the neighbor table of the AP associated with the detected triggering event comprises: The controller obtains the neighbor table of the AP associated with the detected triggering event; The controller selects one of the following as the target AP based on the neighbor table: The nearest AP to the AP associated with the detected triggering event, or The neighboring AP with the least workload among the multiple neighboring APs of the AP associated with the detected triggering event.

6. The method of claim 1, wherein determining the verification use case corresponding to the detected triggering event based on the knowledge base comprises: In response to the detected triggering event being the configuration change, the controller determines one or more functions of the network affected by the configuration change; as well as The controller obtains the verification test cases for verifying the one or more functions of the network.

7. The method of claim 6, wherein the configuration change is a Service Set Identifier (SSID) change, and sending the verification test case to the target AP comprises: Enable the target AP to establish a Wi-Fi station virtual AP (VAP) for connecting to the neighbor's basic SSID (BSSID); as well as The target AP generates a service for verifying the neighbor's BSSID.

8. The method of claim 6, wherein the configuration change is an Internet of Things (IoT) beacon change, and sending the verification use case to the target AP comprises: The target AP is instructed to inspect the IoT beacons it has heard. as well as The target AP verifies the payload of the received IoT beacon.

9. The method of claim 1, wherein determining the verification use case corresponding to the detected triggering event based on the knowledge base comprises: In response to the detected triggering event being the firmware upgrade, the controller obtains the patch list for the firmware upgrade; as well as The controller determines the upgraded APs and the verification use cases in the network based on the patch list, for use in verifying one or more functions of the upgraded APs.

10. The method of claim 1, wherein determining the verification use case corresponding to the detected triggering event based on the knowledge base comprises: In response to the detected triggering event being the topology change, the controller determines one or more APs affected by the topology change and the verification use case for verifying one or more functions of the one or more APs.

11. A device for communication, comprising: At least one processor; as well as A memory coupled to the at least one processor, the memory storing a controller, the controller including instructions to cause the at least one processor to perform the following operations: Detection of triggering events used to verify a network comprising multiple access points (APs), the triggering events being associated with at least one of the network's configuration change, firmware upgrade, or topology change; Identify the AP associated with the triggering event among the plurality of APs; Based on the neighbor table of the AP associated with the detected triggering event, a target AP for verifying the network is selected from the plurality of APs, and the selection of the target AP is based on one of the nearest neighbor AP of the AP associated with the detected triggering event and the neighbor AP with the least workload. The knowledge base determines the verification test cases corresponding to the detected triggering events, and the knowledge base stores multiple verification test cases corresponding to multiple triggering events; Send the verification test case to the target AP; as well as In response to the execution of the verification test case, the execution result of the verification test case is received from the target AP.

12. The device of claim 11, wherein the verification use case is executed by the target AP to verify the AP's functionality associated with the detected triggering event, and the controller further includes instructions to cause the at least one processor to perform the following operations: The effectiveness of the detected triggering event in the network is determined based on the execution result of the verification test case.

13. The device of claim 12, wherein the controller further comprises instructions for causing the at least one processor to perform the following operations: In response to determining that the detected triggering event is not effective in the network, an alert associated with the detected triggering event is sent to the administrator device.

14. The device of claim 11, wherein the instructions for determining the verification use case corresponding to the detected triggering event based on the knowledge base include instructions for causing the at least one processor to perform the following operations: Send a query to the knowledge base regarding the detected triggering event; Receive the response to the query from the knowledge base, the response including a suite of verification test cases corresponding to the detected triggering event; and The suite of validation test cases is determined based on the response to the query.

15. The apparatus of claim 11, wherein the instructions for selecting the target AP from the plurality of APs based on the neighbor table of the APs associated with the detected triggering event include instructions for causing the at least one processor to perform the following operations: Obtain the neighbor table of the AP associated with the detected triggering event; Based on the neighbor table, select one of the following as the target AP: The nearest AP to the AP associated with the detected triggering event, or The neighboring AP with the least workload among the multiple neighboring APs of the AP associated with the detected triggering event.

16. The device of claim 11, wherein the instructions for determining a verification use case corresponding to the detected triggering event based on the knowledge base include instructions for causing the at least one processor to perform the following operations: In response to the detected triggering event being the configuration change, determine one or more functions of the network affected by the configuration change; and Obtain the verification test cases used to verify the one or more functions of the network.

17. The device of claim 16, wherein the configuration change is a Service Set Identifier (SSID) change, and the instruction for sending the verification use case to the target AP includes instructions causing the at least one processor to perform the following operations: The target AP establishes a virtual AP (VAP) for connecting to a neighboring basic SSID (BSSID); and The target AP generates a service for verifying the neighbor's BSSID.

18. The device of claim 16, wherein the configuration change is an Internet of Things (IoT) beacon change, and the instructions for sending the verification use case to the target AP include instructions causing the at least one processor to perform the following operations: The target AP is instructed to inspect the IoT beacons it has heard; and The target AP verifies the payload of the received IoT beacon.

19. The apparatus of claim 11, wherein the instructions for determining the verification use case corresponding to the detected triggering event based on the knowledge base include instructions for causing the at least one processor to perform the following operations: In response to the detected triggering event being the firmware upgrade, the controller obtains a list of patches for the firmware upgrade; and The upgraded APs and the verification use cases in the network are determined based on the patch list to verify one or more functions of the upgraded APs.

20. A non-transient computer-readable medium comprising instructions stored thereon, the instructions, when executed by a processor, causing the processor to: Detection of triggering events used to verify a network comprising multiple access points (APs), the triggering events being associated with at least one of the network's configuration change, firmware upgrade, or topology change; Identify the AP associated with the triggering event among the plurality of APs; Based on the neighbor table of the AP associated with the detected triggering event, a target AP for verifying the network is selected from the plurality of APs, and the selection of the target AP is based on one of the nearest neighbor AP of the AP associated with the detected triggering event and the neighbor AP with the least workload. The knowledge base determines the verification test cases corresponding to the detected triggering events, and the knowledge base stores multiple verification test cases corresponding to multiple triggering events; Send the verification test case to the target AP; as well as In response to the execution of the verification test case, the execution result of the verification test case is received from the target AP.

Images