Wireless AP configuration updating method and device, equipment and storage medium

By configuring a parameter classification and labeling system and an atomic update step sequence, the problems of low configuration update efficiency and poor stability in the OpenWRT system are solved, achieving efficient and reliable wireless AP configuration updates, ensuring business continuity and operational efficiency.

CN121665277APending Publication Date: 2026-03-13SHEN ZHOU SHU MA WANG LUO BEI JING YOU XIAN GONG SI +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-26
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

Existing wireless AP configuration update methods based on OpenWRT systems suffer from low efficiency, poor stability, and high risk of service interruption. In particular, in multi-VAP scenarios, the configuration takes a long time to take effect, service interruptions are frequent, and there is a lack of transactional guarantees.

Method used

A configuration parameter classification and labeling system is adopted to generate an atomic update step sequence, which is sorted by impact level and executed step by step. Each step is verified to ensure the reliability of the update process, and automatically rolls back to the original state in case of anomalies.

Benefits of technology

It enables on-demand updates and minimizes business impact, significantly improving the efficiency of configuration activation and the reliability of the system update process, and ensuring business continuity and operational experience in the network environment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121665277A_ABST
    Figure CN121665277A_ABST
Patent Text Reader

Abstract

The invention discloses a wireless AP configuration updating method and device, equipment and a storage medium, and relates to the technical field of communication, and the method comprises the steps: determining an updating influence level label corresponding to each configuration parameter in one or more to-be-updated wireless configuration parameters in a first modification request instruction; analyzing a dependency relationship among one or more to-be-updated wireless configuration parameters based on the update influence level tag, and generating a first atomization update step sequence; executing atomization updating steps according to the sequence of the first atomization updating step sequence; checking an execution result of the atomization updating step; if the verification is passed, executing the next atomization updating step in the first atomization updating step sequence; and when all atomization updating steps in the first atomization updating step sequence are executed and verification is passed, determining that updating of the wireless configuration parameters corresponding to the first modification request instruction is completed. According to the method, the configuration effective efficiency and the reliability of the system updating process are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, device and storage medium for updating the configuration of a wireless access point (AP). Background Technology

[0002] Currently, most wireless access point (AP) products on the market are developed based on the OpenWRT open-source system. This system is widely used in various network devices due to its lightweight design, high customizability, and broad hardware compatibility. In AP operation and maintenance, wireless configuration updates are common operations, such as modifying parameters like the Service Set Identifier (SSID), encryption method, channel, or transmit power. OpenWRT's native configuration update mechanism uses a full rebuild + forced restart mode: upon receiving a configuration change, the system deletes the original Virtual Access Point (VAP) and its associated wireless interface, then recreates the interface and loads the new configuration. The entire process forces a restart of the radio frequency module to ensure the configuration takes effect.

[0003] However, the aforementioned native update mechanism has certain shortcomings. First, the configuration takes a long time to take effect; a full rebuild and RF restart typically require 5 to 10 seconds, and this time is further increased in multi-VAP scenarios, leading to response delays. Second, there is a high risk of service interruption; RF restart forcibly disconnects all connected terminals, affecting the continuity of real-time services (such as video conferencing and online calls), especially for low-power IoT devices, which may cause problems with automatic reconnection. Furthermore, this mechanism is redundant and inefficient; even modifying only surface parameters such as the SSID will trigger an RF restart, causing unnecessary resource consumption and service interference. Finally, the system lacks transactional guarantees; if an anomaly occurs during the update process (such as driver failure or parameter errors), the configuration may be in a partially effective state, requiring manual intervention to recover, increasing operational complexity and failure risks.

[0004] In summary, existing AP configuration update methods based on OpenWRT systems suffer from low efficiency, poor stability, and high risk of service interruption. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for updating the configuration of a wireless access point (AP), which can effectively solve the problems of long service interruption time, low update efficiency, and lack of transactional guarantee in the configuration update process caused by full reconstruction and forced restart in the prior art.

[0006] To achieve the above objectives, this application adopts the following technical solution: In a first aspect, this application provides a method for updating the configuration of a wireless access point (AP), the method comprising: Obtain a first modification request instruction, the first modification request instruction carrying one or more wireless configuration parameters to be updated; Based on a predefined configuration parameter classification label system, determine the update impact level label corresponding to each configuration parameter among the one or more wireless configuration parameters to be updated; wherein, the update impact level label is used to indicate the minimum system operation range required to update the configuration parameter; Based on the update impact level label of each configuration parameter, the dependency relationship between the one or more wireless configuration parameters to be updated is analyzed to generate the first atomic update step sequence; Each atomic update step is executed sequentially according to the order of the first atomic update step sequence; The execution results of each atomic update step are verified; If the verification passes, continue to execute the next atomic update step in the first atomic update step sequence; When all atomic update steps in the first atomic update step sequence are executed and verified, it is determined that the wireless configuration parameter update corresponding to the first modification request instruction is complete.

[0007] In some possible implementations, the method further includes: If the verification fails, the reverse operation corresponding to the successfully executed atomic update step will be determined according to the preset rollback strategy. The reverse operations are performed sequentially in the reverse order of execution to roll back the system configuration state to the state before the first modification request instruction was executed.

[0008] In some possible implementations, the update impact level label includes at least: For the first type of label, the corresponding configuration parameters can be modified and taken effect directly through runtime commands without restarting the wireless interface and radio frequency module; The second type of label requires restarting the associated single wireless virtual interface for its configuration parameters, but does not affect other wireless virtual interfaces. For the third type of label, the corresponding configuration parameters require restarting the underlying RF hardware module.

[0009] In some possible implementations, the step of analyzing the dependencies between one or more wireless configuration parameters to be updated based on the update impact level label of each configuration parameter, and generating a first atomic update step sequence, includes: Identify configuration parameters belonging to the first type of tag among the one or more wireless configuration parameters to be updated, and generate corresponding first type of operation steps; the first type of operation steps include calling underlying runtime commands; Identify the configuration parameters belonging to the second type of tag among the one or more wireless configuration parameters to be updated, determine the wireless virtual interface associated with each configuration parameter, and generate corresponding second type of operation steps for each wireless virtual interface that needs to be restarted; Identify the configuration parameters belonging to the third type of tag among the one or more wireless configuration parameters to be updated. If the configuration parameters of the third type of tag exist, generate the corresponding third type of operation steps. Based on the dependency and conflict rules between configuration parameters, the first type of operation steps, the second type of operation steps, and the third type of operation steps are sorted and merged to form the first atomic update step sequence; wherein, in the first atomic update step sequence, the first type of operation steps are located before the second type of operation steps, and the second type of operation steps are located before the third type of operation steps.

[0010] In some possible implementations, the verification of the execution result of each atomic update step includes: Obtain the feedback status returned by the underlying driver or service after executing the atomic update step; Obtain the current operating parameters of the relevant wireless interface or radio frequency module; The current running parameters are verified against the configuration target expected to be achieved by the atomic update step.

[0011] In some possible implementations, the method further includes: If the feedback status returned by the underlying driver or service indicates successful execution, and the current running parameters match the configuration target expected to be achieved by the atomic update step, then the verification is deemed successful.

[0012] In some possible implementations, before executing each atomic update step sequentially according to the order of the first atomic update step sequence, the method further includes: An impact assessment report is generated based on the first atomic update step sequence. The impact assessment report is used to predict the scope of business impact and changes in terminal connection status caused by executing the first atomic update step sequence. Secondly, this application provides a wireless AP configuration update device, the device comprising: The acquisition module is used to acquire a first modification request instruction, which carries one or more wireless configuration parameters to be updated; and to determine the update impact level label corresponding to each of the one or more wireless configuration parameters to be updated according to a predefined configuration parameter classification label system; wherein the update impact level label is used to indicate the minimum system operation range required to update the configuration parameter. The analysis module is used to analyze the dependencies between the one or more wireless configuration parameters to be updated based on the update impact level label of each configuration parameter, and generate a first atomic update step sequence. An execution module is configured to execute each atomic update step sequentially according to the order of the first atomic update step sequence; The verification module is used to verify the execution result of each atomic update step; if the verification passes, the next atomic update step in the first atomic update step sequence is executed; when all atomic update steps in the first atomic update step sequence are executed and verified, it is determined that the wireless configuration parameter update corresponding to the first modification request instruction is completed.

[0013] Thirdly, this application provides a computing device, including a memory and a processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.

[0015] Fifthly, this application provides a computer program product comprising one or more computer instructions, wherein when the computer instructions are executed by a computer, the computer performs the method as described in any one of the first aspects.

[0016] As can be seen from the above technical solution, this application has at least the following beneficial effects: In this application, a first modification request instruction is obtained. Based on a predefined configuration parameter classification and labeling system, the update impact level label corresponding to each configuration parameter in one or more wireless configuration parameters to be updated within the first modification request instruction is determined. Based on the update impact level label of each configuration parameter, the dependencies between one or more wireless configuration parameters to be updated are analyzed, generating a first atomic update step sequence. Each atomic update step is executed sequentially according to the order of the first atomic update step sequence. The execution result of each atomic update step is verified. If the verification passes, the next atomic update step in the first atomic update step sequence is executed. When all atomic update steps in the first atomic update step sequence have been executed and verified, the wireless configuration parameter update corresponding to the first modification request instruction is determined to be complete. In existing technologies, all configuration updates require a forced restart of the radio frequency module, inevitably leading to service interruption, low efficiency, and no abnormal rollback mechanism. Therefore, this application, through intelligent configuration classification and differentiated atomic step execution, achieves on-demand updates and minimizes service impact, significantly improving configuration efficiency and the reliability of the system update process, effectively ensuring service continuity and operational experience in the network environment.

[0017] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0018] Figure 1 A schematic diagram illustrating an application scenario provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for updating the configuration of a wireless access point (AP) as provided in an embodiment of this application; Figure 3 A schematic diagram of a wireless AP configuration update device provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0019] The terms "first," "second," and "third," etc., used in this application specification and accompanying drawings are used to distinguish different objects, not to limit a specific order.

[0020] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0021] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the related technologies is given first: Currently, most wireless access point (AP) products on the market are developed based on the OpenWRT open-source system, which is widely used due to its lightweight nature, high customizability, and broad hardware compatibility. In the daily operation and maintenance of APs, wireless configuration updates are one of the core operations, involving modifications to various parameters such as Service Set Identifier (SSID), encryption method, transmit power, channel, and bandwidth. OpenWRT's native configuration update mechanism uses a "full rebuild + forced restart" mode. Upon receiving any configuration change request, the system first deletes the existing wireless virtual interface and its associated wireless interface, then recreates the interface and loads all the new configuration. This process forces a restart of the underlying radio frequency hardware module to ensure the configuration takes effect.

[0022] However, the aforementioned full update method has certain drawbacks. First, the configuration takes a long time to take effect, typically 5 to 10 seconds, and even longer in multi-VAP scenarios. Second, the forced restart of the RF module will cause all connected terminals to disconnect, posing a serious threat to the connection stability of real-time services such as video conferencing and online calls, as well as low-power IoT devices. Third, regardless of the nature of the modified parameters (such as only modifying the SSID), the same full update process is triggered, resulting in unnecessary operational redundancy and resource waste. Finally, this mechanism lacks transactional guarantees. If an anomaly occurs during the update process, the system may enter an abnormal state of partially effective configuration, requiring manual intervention to recover, increasing the complexity and risk of operation and maintenance.

[0023] In view of this, embodiments of this application provide a method for updating the configuration of a wireless AP. This method constructs an intelligent update engine between the system configuration management layer and the underlying wireless services, achieving refined and intelligent processing of configuration updates. Specifically, the method first pre-classifies and tags the wireless configuration parameters, defining the minimum system operation scope required for each parameter's update. Next, upon receiving a modification request containing one or more parameters to be updated, it automatically analyzes the dependencies between parameters based on the tag system and generates an atomic sequence of minimum operation steps ordered by impact level. Then, the system progressively executes each step according to this sequence, performing a status check immediately after each step. Finally, through a transactional guarantee mechanism, it ensures that the entire update process either succeeds completely or automatically rolls back to the stable state before the update in the event of an anomaly, thereby fundamentally solving the problems of service interruption, low efficiency, and insufficient reliability caused by traditional full-scale restart methods. To make the technical solution of this application clearer and easier to understand, the application scenarios of the technical solution of this application are described below with reference to the accompanying drawings. Figure 1 As shown in the figure, this figure is a schematic diagram of an application scenario provided by an embodiment of this application.

[0024] This application scenario describes the deployment architecture of the intelligent configuration update engine proposed in this application in a wireless access point (AP) based on an OpenWRT system. The architecture adopts a clear layered design, divided from top to bottom into an interaction layer 101, a core layer 102, and an execution layer 103. Each layer collaborates through a unified interaction interface 104.

[0025] Specifically, the Interaction Layer 101 is the user interface for interacting with the system, responsible for receiving wireless configuration operation requests from various channels. It supports multiple interaction methods, including: Web (web-based management interface), CLI (Command-Line Interface), AC (Wireless Access Controller), and a cloud management platform. The main function of the Interaction Layer is to standardize and encapsulate the user's original configuration parameters and operation types, and then send them to the core layer 102 for processing through a unified interaction interface 104, thereby shielding the differences in upper-layer interaction methods.

[0026] Core Layer 102 is the core innovation of this application, namely the intelligent configuration update engine. It consists of four major functional sub-modules: The configuration classification module is responsible for labeling received configuration parameters with update impact levels according to predefined rules; the dependency analysis module analyzes the technical dependencies and conflicts between parameters to be updated, and generates a minimal set of operations and an impact assessment report; the progressive commit module breaks down and sorts the minimal set of operations into a series of independently executable atomic update steps, and commits them sequentially; the status verification and rollback module verifies the execution results of each step in real time, and automatically triggers a rollback operation according to a preset strategy in case of failure, ensuring the consistency of the system state. The core layer is the brain of the entire architecture, realizing intelligent decision-making and transactional control for configuration updates.

[0027] The Execution Layer 103 is the implementer of the specific operations. It is responsible for calling the native low-level services of the OpenWRT system (such as hostapd for managing wireless access points and netifd for network interface configuration) and wireless drivers from different chip manufacturers, accurately executing the optimized and differentiated instructions issued by the core layer 102 (such as hot reload commands, single VAP restart commands, etc.), and feeding back the execution status of each step to the core layer in real time for verification.

[0028] To address this, this solution introduces an intelligent core engine layer, constructing a central hub for configuration update processing that bridges the gap between upper and lower layers. It transforms diverse configuration requests from the upper layer into efficient and secure execution commands for the lower layer. Clearly, this solution not only solves the problems of the crude and inefficient update mechanism of the native OpenWRT system, but also improves the system's compatibility, scalability, and maintainability through a layered and decoupled design, enabling the intelligent update capability to flexibly adapt to different management interfaces, hardware platforms, and network scales.

[0029] To make the technical solution of this application clearer and easier to understand, the following describes a method for updating the configuration of a wireless AP provided by an embodiment of this application, in conjunction with the above application scenarios. Figure 2 As shown, this figure is a flowchart of a wireless AP configuration update method provided in an embodiment of this application.

[0030] This method is applied to a processing device, which may be a wireless access point (AP) itself that has deployed the aforementioned intelligent configuration update engine, or a wireless controller (AC), server, or cloud platform capable of managing the AP. The method includes: S201. Obtain a first modification request instruction, the first modification request instruction carrying one or more wireless configuration parameters to be updated.

[0031] The first modification request instruction is a standardized configuration change command that triggers the application process and serves as the starting point for all subsequent intelligent processing.

[0032] Wireless configuration parameters refer to the specific settings that can be configured on a wireless access point (AP) and affect the behavior of its wireless network.

[0033] The system receives a configuration update request from a user or management system through its configuration management interface (such as a web management page, command-line interface (CLI), wireless controller (AC), or cloud management platform). This request is standardized and encapsulated into a first modification request instruction. The core payload of this instruction is one or more wireless configuration parameters to be updated, i.e., the specific configuration items that the user wants to modify and their target values. These parameters may include, but are not limited to: Service Set Identifier (SSID, i.e., Wi-Fi network name), encryption method and key, wireless channel, transmit power, bandwidth, maximum number of user connections, etc. The instruction may also contain operational context, such as the identifier of the target AP and the effective time requirement.

[0034] This is the trigger point and input source for the entire update process. It collects and encapsulates users' scattered, unstructured configuration intentions into standardized data objects that the system can process, laying the foundation for subsequent automated analysis. Through a unified command interface, it shields the differences between various upper-layer interaction methods, ensuring consistency in subsequent core processing logic and enhancing system compatibility and maintainability.

[0035] S202. Based on the predefined configuration parameter classification label system, determine the update impact level label corresponding to each configuration parameter in one or more wireless configuration parameters to be updated.

[0036] The predefined configuration parameter classification tag system is a built-in, extensible rule base that establishes a mapping relationship from the technical attributes of configuration parameters to their update behavior characteristics (tags), serving as the knowledge foundation for intelligent updates.

[0037] The update impact level label is used to characterize the degree and scope of impact on the system's operational status (especially on connected terminal services) when updating a specific parameter, as well as the minimum system operations required. It is the core decision-making basis for achieving differentiated updates.

[0038] The update impact level label includes at least: The first type of label allows configuration parameters to be modified and applied directly via runtime commands without requiring a restart of the wireless interface and RF module. The second type of label requires a restart of the associated single wireless virtual interface for its configuration parameters, without affecting other wireless virtual interfaces. The third type of label requires a restart of the underlying RF hardware module for its configuration parameters.

[0039] Specifically, metadata tags are used to label all wireless configuration parameters in the OpenWRT system, defining four core tags and corresponding processing strategies to achieve fine-grained management of configuration parameters. The tag system and typical parameter adaptations are shown in Table 1: Table 1: Labeling System and Typical Parameter Adaptation Table

[0040] The update impact level label is used to indicate the minimum system operation range required to update the configuration parameters.

[0041] The system invokes the configuration classification module and, based on a predefined configuration parameter classification label system, identifies and labels each parameter to be updated received in S201. This label system is a metadata mapping library that defines the update impact level labels corresponding to parameters with different technical characteristics. The system queries this system to match one or more labels for each parameter. For example, the parameter SSID might be labeled as hot_reloadable, while the parameter radio channel might be labeled as require_radio_restart.

[0042] In some embodiments, metadata is stored by extending the tag field in the OpenWRT native configuration file " / etc / config / wireless" to achieve binding and storage of configuration and tags. An example code is shown below: config wifi-iface 'ath0' option ssid 'Office_WiFi'#SSID is Office_WiFi option encryption 'psk2' # Encryption method is WPA2-PSK option txpower '18'# transmit power is 18dBm option channel '6'#Channel 6 # Metadata tags extended in this application option meta_tag 'hot_reloadable' # Tag type is hot reloadable option meta_dep 'none' # Marks the dependency as zero option meta_impact 'low' # The business impact level is no impact.

[0043] By precisely labeling data, the system can distinguish which modifications can take effect silently and which must cause business interruption. This fundamentally avoids the blind approach of traditional one-size-fits-all restarts. The output tag set serves as direct input for the next step of dependency analysis and generating a minimal set of operations. Without accurate classification, subsequent optimization and scheduling are impossible. Parameter qualitative analysis early in the process avoids repeatedly judging parameter types during subsequent execution, improving overall processing efficiency.

[0044] S203. Based on the update impact level label of each configuration parameter, analyze the dependency relationship between one or more wireless configuration parameters to be updated, and generate the first atomic update step sequence.

[0045] Dependency refers to the logical sequence and causal relationship between different configuration parameters or operation steps. For example, modifying a channel depends on the related VAP having stopped.

[0046] Conflict rules refer to restrictions that prevent certain operations from being executed simultaneously or out of order due to contention for the same resource (such as hardware radio frequency) or mutual exclusion of states.

[0047] The first atomic update step sequence refers to a detailed, safe, efficient, and step-by-step operation plan autonomously planned by the system to complete this configuration update.

[0048] Identify configuration parameters belonging to the first category of tags among one or more wireless configuration parameters to be updated, and generate corresponding first-type operation steps; the first-type operation steps include calling underlying runtime commands; identify configuration parameters belonging to the second category of tags among one or more wireless configuration parameters to be updated, determine the wireless virtual interface associated with each configuration parameter, and generate corresponding second-type operation steps for each wireless virtual interface that needs to be restarted; identify configuration parameters belonging to the third category of tags among one or more wireless configuration parameters to be updated, and if there are configuration parameters with the third category of tags, generate corresponding third-type operation steps.

[0049] Based on the dependency and conflict rules among the configuration parameters, the first type of operation steps, the second type of operation steps, and the third type of operation steps are sorted and merged to form the first atomic update step sequence; wherein, in the first atomic update step sequence, the first type of operation steps are placed before the second type of operation steps, and the second type of operation steps are placed before the third type of operation steps.

[0050] Specifically, this step is completed collaboratively by the dependency analysis module and the incremental commit module. First, based on the tags assigned to each parameter in S202, the system groups all parameters to be updated according to their tag types (e.g., Category 1, Category 2, Category 3). Then, the following sub-steps are executed: For parameters marked with the first category label (e.g., hot_reloadable), the system generates a first category of operation steps. These steps essentially call runtime configuration commands of the underlying operating system or driver (such as the iwconfig or hostapd_cli commands in Linux) to directly modify parameter values ​​in the kernel or driver without interrupting services.

[0051] For parameters tagged with Category 2 labels (e.g., require_vap_restart), the system needs to determine which wireless virtual interface each parameter specifically affects and generate a separate Category 2 operation step for each VAP that needs to be restarted. This step is typically a sequence of commands: "shut down the interface, apply the new configuration, and restart the interface."

[0052] For parameters marked with a third-category label (such as require_radio_restart), since radio frequency hardware is involved, the system generates a third-category operation step, which is to perform a complete restart process of the radio frequency module.

[0053] After generating the basic operation steps, the system does not execute them immediately. Instead, it calls the dependency rule base for in-depth analysis. It checks for technical dependencies (e.g., the underlying RF channel cannot be safely modified until the VAP is closed) or conflicts (e.g., two operations cannot be executed simultaneously) between all steps. Based on these rules, the system sorts and merges all steps: Following the principle of minimizing impact, the execution order is as follows: first, the first type (no interruption); then, the second type (local interruption); and finally, the third type (global interruption). Within each type, the order is determined based on specific dependencies.

[0054] Multiple steps targeting the same operation object (such as the same VAP) are merged to avoid duplicate operations.

[0055] Ultimately, the output is an ordered, conflict-free, and optimized sequence of first atomic update steps. Each atomic step is the smallest indivisible unit of operation with a definite execution result.

[0056] By analyzing and merging, all redundant operations were eliminated, ensuring that only the necessary instructions were executed.

[0057] By scientifically prioritizing operations, those that might disrupt business operations (Categories 2 and 3) are placed as late as possible, while allowing more time for non-disruptive operations (Category 1) to execute, thus compressing the overall time window during which business operations are affected. The output sequence forms the basis for the subsequent steps to be executed in a controlled manner.

[0058] S204. Execute each atomic update step sequentially according to the order of the first atomic update step sequence.

[0059] The execution module strictly follows the sequence of atomic update steps generated by S203, executing each atomic update step sequentially. Each step involves sending the corresponding command or instruction set (such as an `iwconfig` command or a VAP restart script) to the execution layer, which then calls OpenWRT underlying services or chip drivers to complete the actual operation. The system waits for the current step to complete and receives feedback before deciding whether to start the next step.

[0060] S205. Verify the execution results of each atomic update step.

[0061] Obtain the feedback status returned by the underlying driver or service after the atomic update step is executed; obtain the current operating parameters of the relevant wireless interface or radio frequency module; and verify the current operating parameters against the configuration target expected to be achieved by the atomic update step.

[0062] This is the core guarantee mechanism to ensure the reliability and accuracy of the update process. It is equivalent to setting a quality checkpoint after each step to prevent errors from accumulating or the system from entering an inconsistent state.

[0063] S206. If the verification passes, continue to execute the next atomic update step in the first atomic update step sequence.

[0064] If the feedback status returned by the underlying driver or service indicates that the execution was successful, and the current running parameters match the configuration target expected to be achieved by the atomic update step, then the verification is considered successful.

[0065] If the verification fails, the reverse operation corresponding to the successfully executed atomic update step is determined according to the preset rollback strategy; the reverse operation is executed in the reverse order of execution so that the system configuration state is rolled back to the state before the first modification request instruction was executed.

[0066] The preset rollback strategy is a set of predefined, searchable rule mapping tables. It establishes a one-to-one correspondence from forward atomic operations to reverse atomic operations that can invalidate their effects, and is the technical guarantee for achieving transaction atomicity and consistency.

[0067] A reverse operation is a specific sequence of instructions or commands used to undo or cancel the effect of a successful forward atomic operation.

[0068] Rollback refers to the operation of restoring the system state to the state before the transaction started (in this example, before the execution of the first modification request instruction) when a transaction fails midway.

[0069] Through rigorous success criteria, only correct steps are accumulated, laying a solid foundation for a successful update. A mechanism that commits upon complete success and rolls back completely upon any failure ensures the update operation is an indivisible whole. Users will see either all new configurations taking effect or everything remaining the same; there is no intermediate state.

[0070] Automatic rollback ensures that the system can always transition from one consistent configuration state (the original state) to another consistent configuration state (either the new state or the original state after rollback), and will not remain in a corrupt or inconsistent state.

[0071] Automated rollback replaces manual troubleshooting and recovery, enabling instant business recovery in the event of anomalies, minimizing the failure window and impact caused by configuration updates, and improving system reliability and operational efficiency.

[0072] S207. When all atomic update steps in the first atomic update step sequence have been executed and verified, it is determined that the wireless configuration parameters corresponding to the first modification request instruction have been updated.

[0073] This step is the final check of the process status and the termination of the transaction. When the system, based on the decision logic of S206, has completed the closed-loop process of "instruction execution, status verification, result confirmation, and subsequent step iteration," and the last atomic step in the first atomic update step sequence has also been successfully executed and passed verification, the iteration loop terminates. Based on this, the system makes a final status determination: all wireless configuration parameter update operations associated with the first modification request instruction have been completed and are effective. The system then returns a transaction success response to the upper-layer interaction interface, and may optionally perform auxiliary operations such as update log recording and persistent configuration storage.

[0074] It identifies the successful completion boundary of a transaction, outputs a deterministic conclusion, and constitutes the endpoint of a complete transaction loop from instruction parsing to final effectiveness. It outputs a clear and unambiguous success status to the management plane, eliminating uncertainty in results under asynchronous or long-running operations. As an event signal for transaction completion, it can drive downstream consistency maintenance operations such as log auditing, configuration synchronization, and status reporting. It verifies the effectiveness of the entire technical chain from intelligent hierarchical management and planning scheduling to atomic execution and verification, achieving a reliable closed loop for configuration update transactions.

[0075] In some embodiments, before executing each atomic update step in the order of the first atomic update step sequence, an impact assessment report is generated based on the first atomic update step sequence. The impact assessment report is used to predict the scope of business impact and changes in terminal connection status caused by executing the first atomic update step sequence.

[0076] Based on the above, the wireless AP configuration update method provided in this application fundamentally innovates the traditional full-reboot update paradigm by constructing a closed-loop management system encompassing configuration parameter classification, dependency analysis, atomic step generation and execution, and real-time verification and rollback. This method deconstructs the originally simple and coarse reboot operation into an intelligent update process that can be finely scheduled, atomically verified, and has transactional guarantees.

[0077] It is evident that this solution not only addresses the efficiency bottlenecks and service interruptions inherent in native OpenWRT systems during configuration updates from a technical perspective, but also provides a highly compatible and scalable general framework at the engineering level. By introducing a layered architecture and a rule engine, this intelligent update capability can flexibly adapt to different hardware drivers, management interfaces, and business scenarios, providing a reliable technical foundation for achieving seamless dynamic operation and maintenance and smooth evolution of modern enterprise-level wireless networks.

[0078] The above text combined Figures 1 to 2 The method for updating the configuration of a wireless AP provided in the embodiments of this application has been described in detail. The apparatus and device provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0079] This application also provides a wireless AP configuration update device, such as... Figure 3 As shown in the figure, this is a schematic diagram of a wireless AP configuration update device provided in an embodiment of this application. The device includes: The acquisition module 301 is used to acquire a first modification request instruction, the first modification request instruction carrying one or more wireless configuration parameters to be updated; and to determine the update impact level label corresponding to each of the one or more wireless configuration parameters to be updated according to a predefined configuration parameter classification label system; wherein, the update impact level label is used to indicate the minimum system operation range required to update the configuration parameter; Analysis module 302 is used to analyze the dependency relationship between the one or more wireless configuration parameters to be updated based on the update impact level label of each configuration parameter, and generate a first atomic update step sequence; The execution module 303 is used to execute each atomic update step sequentially according to the order of the first atomic update step sequence; The verification module 304 is used to verify the execution result of each atomic update step; if the verification passes, the next atomic update step in the first atomic update step sequence is executed; when all atomic update steps in the first atomic update step sequence are executed and verified, it is determined that the wireless configuration parameter update corresponding to the first modification request instruction is completed.

[0080] In some possible implementations, the verification module 304 is further configured to, if the verification fails, determine the reverse operation corresponding to the successfully executed atomic update step according to a preset rollback strategy; and execute the reverse operation in the reverse order of execution so that the system configuration state is rolled back to the state before the execution of the first modification request instruction.

[0081] In some possible implementations, the update impact level label includes at least: The first type of label allows configuration parameters to be modified and applied directly via runtime commands without requiring a restart of the wireless interface and RF module. The second type of label requires a restart of the associated single wireless virtual interface for its configuration parameters, without affecting other wireless virtual interfaces. The third type of label requires a restart of the underlying RF hardware module for its configuration parameters.

[0082] In some possible implementations, the analysis module 302 is specifically used to identify configuration parameters belonging to the first type of tag among the one or more wireless configuration parameters to be updated, and generate corresponding first type of operation steps; the first type of operation steps include calling underlying runtime commands; identifying configuration parameters belonging to the second type of tag among the one or more wireless configuration parameters to be updated, determining the wireless virtual interface associated with each configuration parameter, and generating corresponding second type of operation steps for each wireless virtual interface that needs to be restarted; identifying configuration parameters belonging to the third type of tag among the one or more wireless configuration parameters to be updated, and generating corresponding third type of operation steps if configuration parameters of the third type of tag exist; sorting and merging the first type of operation steps, the second type of operation steps, and the third type of operation steps according to the dependency rules and conflict rules between configuration parameters to form the first atomic update step sequence; wherein, in the first atomic update step sequence, the first type of operation steps are located before the second type of operation steps, and the second type of operation steps are located before the third type of operation steps.

[0083] In some possible implementations, the verification module 304 is specifically used to obtain the feedback status returned by the underlying driver or service after executing the atomic update step; obtain the current operating parameters of the relevant wireless interface or radio frequency module; and verify the current operating parameters with the configuration target expected to be achieved by the atomic update step.

[0084] In some possible implementations, the verification module 304 is further configured to determine that the verification is successful if the feedback status returned by the underlying driver or service indicates that the execution was successful and the current running parameters match the configuration target expected to be achieved by the atomic update step.

[0085] In some possible implementations, the device further includes: The generation module is used to generate an impact assessment report based on the first atomic update step sequence. The impact assessment report is used to predict the scope of business impact and changes in terminal connection status caused by executing the first atomic update step sequence. The wireless AP configuration update apparatus according to the embodiments of this application can correspond to the execution of the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the wireless AP configuration update apparatus are respectively for implementing Figure 1 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0086] This application also provides a computing device. For example... Figure 4 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 400 includes a bus 401, a processor 402, a communication interface 403, and a memory 404. The processor 402, the memory 404, and the communication interface 403 communicate with each other via the bus 401.

[0087] Bus 401 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0088] Processor 402 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0089] The communication interface 403 is used for communication with external devices. For example, if the computing device is a first switch, the communication interface 403 can be used for communication between the first switch and a first user terminal, or for communication between the first switch and a second switch.

[0090] Memory 404 may include volatile memory, such as random access memory (RAM). Memory 404 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0091] The memory 404 stores executable code, which the processor 402 executes to perform the aforementioned wireless AP configuration update method.

[0092] Specifically, in achieving Figure 3 In the case of the illustrated embodiment, and Figure 3 When the modules or units of the wireless AP configuration update device described in the embodiment are implemented in software, the execution... Figure 3 The software or program code required for the functions of each module / unit can be partially or wholly stored in memory 404. Processor 402 executes the program code corresponding to each unit stored in memory 404 to execute the aforementioned wireless AP configuration update method.

[0093] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the aforementioned wireless AP configuration update method.

[0094] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0095] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0096] When the computer program product is executed by a computer, the computer performs any of the aforementioned methods for updating the wireless AP configuration. The computer program product can be a software installation package; when any of the aforementioned methods for updating the wireless AP configuration is required, the computer program product can be downloaded and executed on the computer.

[0097] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A method for updating the configuration of a wireless access point (AP), characterized in that, The method includes: Obtain a first modification request instruction, the first modification request instruction carrying one or more wireless configuration parameters to be updated; Based on a predefined configuration parameter classification label system, determine the update impact level label corresponding to each configuration parameter among the one or more wireless configuration parameters to be updated; wherein, the update impact level label is used to indicate the minimum system operation range required to update the configuration parameter; Based on the update impact level label of each configuration parameter, the dependency relationship between the one or more wireless configuration parameters to be updated is analyzed to generate the first atomic update step sequence; Each atomic update step is executed sequentially according to the order of the first atomic update step sequence; The execution results of each atomic update step are verified; If the verification passes, continue to execute the next atomic update step in the first atomic update step sequence; When all atomic update steps in the first atomic update step sequence are executed and verified, it is determined that the wireless configuration parameter update corresponding to the first modification request instruction is complete.

2. The method according to claim 1, characterized in that, The method further includes: If the verification fails, the reverse operation corresponding to the successfully executed atomic update step will be determined according to the preset rollback strategy. The reverse operations are performed sequentially in the reverse order of execution to roll back the system configuration state to the state before the first modification request instruction was executed.

3. The method according to claim 1, characterized in that, The update impact level label includes at least: For the first type of label, the corresponding configuration parameters can be modified and taken effect directly through runtime commands without restarting the wireless interface and radio frequency module; The second type of label requires restarting the associated single wireless virtual interface for its configuration parameters, but does not affect other wireless virtual interfaces. For the third type of label, the corresponding configuration parameters require restarting the underlying RF hardware module.

4. The method according to claim 3, characterized in that, The method analyzes the dependencies between one or more wireless configuration parameters to be updated based on the update impact level label of each configuration parameter, and generates a first atomic update step sequence, including: Identify configuration parameters belonging to the first type of tag among the one or more wireless configuration parameters to be updated, and generate corresponding first type of operation steps; the first type of operation steps include calling underlying runtime commands; Identify the configuration parameters belonging to the second type of tag among the one or more wireless configuration parameters to be updated, determine the wireless virtual interface associated with each configuration parameter, and generate corresponding second type of operation steps for each wireless virtual interface that needs to be restarted; Identify the configuration parameters belonging to the third type of tag among the one or more wireless configuration parameters to be updated. If the configuration parameters of the third type of tag exist, generate the corresponding third type of operation steps. Based on the dependency and conflict rules between configuration parameters, the first type of operation steps, the second type of operation steps, and the third type of operation steps are sorted and merged to form the first atomic update step sequence; wherein, in the first atomic update step sequence, the first type of operation steps are located before the second type of operation steps, and the second type of operation steps are located before the third type of operation steps.

5. The method according to claim 1, characterized in that, The verification of the execution result of each atomic update step includes: Obtain the feedback status returned by the underlying driver or service after executing the atomic update step; Obtain the current operating parameters of the relevant wireless interface or radio frequency module; The current running parameters are verified against the configuration target expected to be achieved by the atomic update step.

6. The method according to claim 5, characterized in that, The method further includes: If the feedback status returned by the underlying driver or service indicates successful execution, and the current running parameters match the configuration target expected to be achieved by the atomic update step, then the verification is deemed successful.

7. The method according to claim 1, characterized in that, Before executing each atomic update step sequentially according to the order of the first atomic update step sequence, the method further includes: An impact assessment report is generated based on the first atomic update step sequence. The impact assessment report is used to predict the scope of business impact and changes in terminal connection status caused by executing the first atomic update step sequence.

8. A device for updating the configuration of a wireless access point (AP), characterized in that, The device includes: The acquisition module is used to acquire a first modification request instruction, which carries one or more wireless configuration parameters to be updated; and to determine the update impact level label corresponding to each of the one or more wireless configuration parameters to be updated according to a predefined configuration parameter classification label system; wherein the update impact level label is used to indicate the minimum system operation range required to update the configuration parameter. The analysis module is used to analyze the dependencies between the one or more wireless configuration parameters to be updated based on the update impact level label of each configuration parameter, and generate a first atomic update step sequence. An execution module is configured to execute each atomic update step sequentially according to the order of the first atomic update step sequence; The verification module is used to verify the execution result of each atomic update step; if the verification passes, the next atomic update step in the first atomic update step sequence is executed; when all atomic update steps in the first atomic update step sequence are executed and verified, it is determined that the wireless configuration parameter update corresponding to the first modification request instruction is completed.

9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.