An ACS server pre-management optimization method based on TR069 protocol
By introducing Redis middleware and multi-threaded management algorithms, the performance deficiencies and device compatibility issues of the ACS server when managing network devices in batches are resolved, and an efficient and stable configuration management process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANGZHOU V-SOLUTION TELECOMM TECH CO LTD
- Filing Date
- 2025-04-01
- Publication Date
- 2026-06-02
AI Technical Summary
When the ACS server configures and manages a large number of network devices, there are issues such as insufficient performance or incompatibility between device nodes, which can lead to configuration anomalies.
By introducing Redis middleware and multi-threaded management algorithms, and using cache migration listening threads and distribution listening threads, a fixed-size thread pool is used to handle the management and configuration tasks of the TR069 protocol, thereby achieving a high-concurrency and high-availability distribution management process.
It improves the management performance and stability of the ACS server, reduces the probability of configuration anomalies, and ensures data integrity and efficient data distribution management.
Smart Images
Figure CN120434116B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of IoT ONU and router device management technology, and more specifically, to an ACS server pre-management optimization method based on the TR069 protocol. Background Technology
[0002] With the continuous development of the communications industry, TR069, short for CPE WAN Management Protocol, provides a general framework and protocol for managing and configuring home network devices in next-generation networks. It is used to remotely and centrally manage devices such as gateways, routers, and optical modems in home networks from the network side.
[0003] The TR069 protocol enables real-time management of network devices, and because it is a universal protocol, it can manage network devices from different manufacturers. However, given the large number of user-end network devices that can be managed using the TR069 protocol, real-time management becomes insufficient for such a vast number of devices. Therefore, pre-configuring network devices through an ACS system and TR069 is particularly important and convenient.
[0004] In the communication between the ACS server and network devices, there are significant performance limitations in configuration distribution and network communication. When a single ACS server manages the configuration of a large number of network devices, insufficient performance or incompatibility of network device nodes may occur, causing the ACS server's configuration thread to malfunction, which in turn leads to multiple configuration errors. Summary of the Invention
[0005] This invention provides an ACS server pre-management optimization method based on the TR069 protocol, which solves the technical problem in the prior art where a single ACS server has insufficient performance or network device nodes are incompatible during the batch management of network devices.
[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:
[0007] This invention provides a pre-management optimization method for ACS servers based on the TR069 protocol, comprising the following steps:
[0008] When the ACS server starts, a cache migration listener thread and a distribution listener thread are created synchronously, and a fixed-length thread pool and Redis middleware are started.
[0009] The issued configuration information is saved to the database and also to the configuration information metadata cache of the Redis middleware.
[0010] After the cache migration listening thread detects that the configuration information meta-cache exists in the Redis middleware, the cache migration listening thread executes a task to migrate the configuration information meta-cache to the process meta-cache of the Redis middleware, and deletes the configuration information meta-cache after the task is completed.
[0011] After the delivery monitoring thread detects that the network device is online and that the network device is in the process meta cache, the delivery monitoring thread creates a delivery management task based on the TR069 protocol and submits it to a fixed-length thread pool for execution.
[0012] The fixed-length thread pool completes the distribution and management tasks.
[0013] Among the aforementioned technical methods, Redis middleware, multithreading, and thread management algorithms are used to handle a large number of potentially repetitive management and configuration tasks based on the TR069 protocol, ultimately achieving the goal of solving the high-concurrency and high-availability deployment management process. Specifically, the Redis middleware serves only as a storage medium for information related to the management and configuration tasks, enabling a highly efficient method for batch management of configuration tasks based on TR069.
[0014] Furthermore, the ACS server completes the pre-configuration management process, including:
[0015] Before network devices report information based on the TR069 protocol, the network configuration of the network devices is filled in in advance, and network devices of specific models or specific MAC addresses are bound to the network configuration to form several pre-configuration records;
[0016] When a network device reports information via the TR069 protocol, the ACS server detects that the identifier of the network device exists in the pre-configuration record. The ACS server will then send the network configuration information in the pre-configuration record to the network device in the form of a targeted network packet.
[0017] Furthermore, the issued configuration information is saved to the database and simultaneously to the Redis middleware's configuration information metadata cache, including:
[0018] The issued configuration information is saved to the database and simultaneously saved in JSON format to the configuration information metadata cache of the Redis middleware.
[0019] Furthermore, the configuration information is saved in JSON format to the Redis middleware's metadata cache, including:
[0020] The configuration information metadata cache is stored in key-value format, where the value stores configuration information, including WAN configuration, LAN configuration, and VoIP configuration, and the key is the identifier of the network device and the unique identifier of the specific configuration related to the identifier.
[0021] Furthermore, the Redis middleware's process meta-caching includes:
[0022] The process meta-cachate is stored in key-value format. The value stores configuration information, including WAN configuration, LAN configuration, and VoIP configuration. The key is the identifier of the network device, the unique identifier of the network device related to the specific configuration, and the distinguishing identifier used to differentiate between the process meta-cachate and the configuration information meta-cachate. At the same time, the number of process meta-cachates is kept below a preset number.
[0023] Furthermore, the task of migrating the configuration information meta-cached to the process meta-cached of the Redis middleware, executed by the cache migration listening thread, also includes:
[0024] If the cache migration monitoring thread checks whether the number of process meta-caches is below a preset number and there is no key in the process meta-caches that is consistent with the configuration information meta-caches, then the cache migration monitoring thread executes the task of migrating the configuration information meta-caches to the process meta-caches of the Redis middleware.
[0025] If a key exists in the process meta-cache that is consistent with the configuration information meta-cache, other records in the configuration information meta-cache will be migrated first until the process meta-cache for that key is cleared.
[0026] Furthermore, the fixed-length thread pool has a preset capacity and is equipped with a delivery monitoring thread. The delivery monitoring thread is used to monitor whether a key of the process meta cache type exists in the Redis middleware and whether a corresponding device exists. If it exists, a thread is created, and the corresponding delivery configuration module is called based on the information meta provided by the key, and then submitted to the fixed-length thread pool.
[0027] Furthermore, after the fixed-length thread pool completes the distribution of management tasks, it closes the threads.
[0028] Furthermore, after the fixed-length thread pool completes the distribution of the management task, it also includes deleting the process meta-cached record corresponding to the distribution of the management task in the Redis middleware.
[0029] Furthermore, after the fixed-length thread pool completes the distribution management task, the cache migration listening thread and the distribution listening thread continue to repeat the migration and listening process.
[0030] Compared with the prior art, the beneficial effects of the technical solution of the present invention are:
[0031] High availability: By utilizing multi-threading and Redis storage, the system can reduce the probability of users repeatedly issuing the same configuration due to erroneous operations, greatly reduce the probability of anomalies during the issuance process, and maintain the stable operation of the ACS server;
[0032] High performance: Through thread management and Redis storage, the system can maintain high performance after users submit pre-configuration information. Furthermore, during the pre-configuration distribution process on a large number of devices, the thread management algorithm greatly improves the distribution management performance based on the TR069 protocol.
[0033] Data integrity: Through thread management, the probability of dirty data being generated when users send a large number of operation data packets is greatly reduced. Attached Figure Description
[0034] Figure 1 A flowchart illustrating an ACS server pre-management optimization method based on the TR069 protocol provided in an embodiment of the present invention;
[0035] Figure 2 This is a schematic diagram illustrating a specific implementation of an ACS server pre-management optimization method based on the TR069 protocol provided in an embodiment of the present invention. Detailed Implementation
[0036] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent.
[0037] To better illustrate this embodiment, some parts in the accompanying drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions;
[0038] It will be understood by those skilled in the art that certain well-known structures and their descriptions may be omitted in the accompanying drawings.
[0039] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.
[0040] Example 1
[0041] This embodiment provides a pre-management optimization method for ACS servers based on the TR069 protocol, such as... Figure 1 As shown, it includes the following steps:
[0042] When the ACS server starts, a cache migration listener thread and a distribution listener thread are created synchronously, and a fixed-length thread pool and Redis middleware are started.
[0043] The issued configuration information is saved to the database and also to the configuration information metadata cache of the Redis middleware.
[0044] After the cache migration listening thread detects that the configuration information meta-cache exists in the Redis middleware, the cache migration listening thread executes a task to migrate the configuration information meta-cache to the process meta-cache of the Redis middleware, and deletes the configuration information meta-cache after the task is completed.
[0045] After the delivery monitoring thread detects that the network device is online and that the network device is in the process meta cache, the delivery monitoring thread creates a delivery management task based on the TR069 protocol and submits it to a fixed-length thread pool for execution.
[0046] The fixed-length thread pool completes the distribution and management tasks.
[0047] In this embodiment, to better implement the distribution process, the optimization method introduces Redis middleware as a cache. This cache is the core component of the entire optimization scheme, mainly responsible for receiving data records after the user's pre-configuration of the network on the page and the completion of regular database storage, and storing them in the cache. Based on the characteristics of this Redis middleware, when the same key is stored repeatedly, the value of the existing key will be overwritten. Therefore, when a user distributes the same configuration information multiple times, this method can prevent the occurrence of abnormal events or performance pressure caused by repeated distributions, thus solving the technical problem of insufficient performance of a single ACS server in the process of batch management of network devices in the prior art.
[0048] Example 2
[0049] This embodiment, based on Embodiment 1, further explains the pre-management optimization method for ACS servers based on the TR069 protocol:
[0050] The prerequisite for the ACS server pre-management optimization method based on the TR069 protocol is the existence of an ACS server, and the ACS server already provides a pre-configuration management method, which includes:
[0051] Before network devices report information based on the TR069 protocol, the network configuration of the network devices is filled in in advance, and network devices of specific models or specific MAC addresses are bound to the network configuration to form several pre-configuration records;
[0052] When a network device reports information via the TR069 protocol, the ACS server detects that the network device's identifier exists in the pre-configuration record. The ACS server then sends the network configuration information from the pre-configuration record to the network device via a targeted network packet to complete a device pre-configuration process.
[0053] In a further embodiment, the issued configuration information is saved to the database and simultaneously saved to the configuration information metadata cache of the Redis middleware, including:
[0054] The issued configuration information is saved to the database and simultaneously saved in JSON format to the configuration information metadata cache of the Redis middleware.
[0055] In a further embodiment, the configuration information metadata cache of the Redis middleware is saved in JSON format, including:
[0056] The configuration information metadata cache is stored in key-value format, where the value stores configuration information, including WAN configuration, LAN configuration, and VoIP configuration, and the key is the identifier of the network device and the unique identifier of the specific configuration related to the identifier.
[0057] In this embodiment, since Redis uses a key-value storage method, in addition to storing detailed configuration information in the value, the key setting must ensure the uniqueness of its configuration information elements. The uniqueness of configuration information elements means using the device identifier and the unique identifier of the specific configuration related to that identifier as the key of a configuration record. In this way, different configuration information can be separated and will not interfere with each other, thereby achieving the purpose of storing temporary configuration information.
[0058] In a further embodiment, the Redis middleware's process meta-cacher includes:
[0059] The process meta-cachate is stored in key-value format. The value stores configuration information, including WAN configuration, LAN configuration, and VoIP configuration. The key is the identifier of the network device, the unique identifier of the network device related to the specific configuration, and the distinguishing identifier used to differentiate between the process meta-cachate and the configuration information meta-cachate. At the same time, the number of process meta-cachates is kept below a preset number.
[0060] In this embodiment, in addition to the user-submitted configuration information metadata cache, the Redis middleware also stores a process metadata cache containing configuration information. The key-value values of the process metadata cache and the configuration information metadata cache are basically the same, but an identifier is added to distinguish the process metadata cache from the configuration metadata cache. Furthermore, the number of process metadata cache entries is always kept below n (n>0, and the specific number of n is determined according to the actual operating environment; in this embodiment, it can be set to 100). The function of the process metadata cache is as follows: the ACS server will start a separate thread to monitor whether the number of process metadata cache entries is less than n. If it is less than n, the key-value values are retrieved from the configuration information metadata cache and placed into the process metadata cache, and the configuration information metadata cache is deleted; if it is equal to n, no operation is performed.
[0061] In a further embodiment, the cache migration monitoring thread, which executes the task of migrating the configuration information metadata cache to the process metadata cache of the Redis middleware, further includes:
[0062] If the cache migration monitoring thread checks whether the number of process meta-caches is below a preset number and there is no key in the process meta-caches that is consistent with the configuration information meta-caches, then the cache migration monitoring thread executes the task of migrating the configuration information meta-caches to the process meta-caches of the Redis middleware.
[0063] If a key exists in the process meta-cache that is consistent with the configuration information meta-cache, other records in the configuration information meta-cache will be migrated first until the process meta-cache for that key is cleared.
[0064] In a further embodiment, the fixed-length thread pool has a preset capacity and is equipped with a delivery monitoring thread. The delivery monitoring thread is used to monitor whether a key of the process meta cache type exists in the Redis middleware and whether a corresponding device exists. If it exists, a thread is created, and the corresponding delivery configuration module is called based on the information meta provided by the key, and submitted to the fixed-length thread pool.
[0065] In a further embodiment, the fixed-length thread pool closes its threads after completing the management task.
[0066] In a further embodiment, after the fixed-length thread pool completes the distribution management task, it also includes deleting the process meta-cached record corresponding to the distribution management task in the Redis middleware.
[0067] In a further embodiment, after the fixed-length thread pool completes the distribution management task, the cache migration listening thread and the distribution listening thread continue to repeat the migration and listening process.
[0068] In this embodiment, besides the Redis middleware-related aspects, before the ACS server distributes the configuration, the ACS server synchronously starts a fixed-size thread pool with a capacity of n (n>0, and the specific number of n is determined according to the actual operating environment; here, we assume it to be 100) during deployment and startup. A separate listening thread continuously monitors whether a key of the process meta-cached type exists in the Redis middleware, and whether a corresponding device exists. If it exists, a thread is created, and based on the information provided by the key, it determines which configuration distribution module to call and submits it to the fixed-size thread pool. The thread executes the configuration distribution process in the thread pool until it is complete, and then closes the thread. After completing the task, the process meta-cached record corresponding to this task in the Redis cache is deleted, while the listening thread continues to monitor whether a key of the process meta-type exists in the Redis cache.
[0069] Example 3
[0070] This embodiment, based on Embodiments 1 and 2, takes an ACS server with integrated Redis middleware and a device environment supporting TR069 protocol management already deployed by an enterprise as an example. Figure 2 As shown, the specific implementation steps are as follows:
[0071] Step 1: When the user starts the ACS server, two listening threads are created and started simultaneously: a cache migration listening thread and a distribution listening thread. A fixed-size thread pool is also started for pre-configured distribution.
[0072] Step 2: Users create a configuration template, fill in the template information for any module (including WAN, LAN, etc.), bind the corresponding device, create a template record and save it to the database, and at the same time create a unique key-value pair and save it in the configuration information metadata cache. If a user performs multiple deployments for a certain module on a certain device, the original cache will be overwritten before the cache migration is triggered to ensure the uniqueness of the deployment information for that module on that device.
[0073] Step 3: If the cache migration monitoring thread detects the existence of the information element cache in the Redis middleware, and the capacity of the process element cache is less than the preset capacity value, and there is no key in the process element cache that is consistent with the information element cache, then the thread executes the task of migrating the information element cache to the process element cache. After the task is completed, the cached information in the information element cache is deleted. If there is a key in the process element cache that is consistent with the information element cache, other records in the information element cache will be migrated first, until the process element cache of that key is cleared.
[0074] Step 4: After the device comes online, the listener thread detects that the conditions of both the device being online and the device being in the process meta cache are met. Based on the module selected by the distribution configuration, a distribution management task based on the TR069 protocol is created and submitted to the fixed-length thread pool for execution. If the device does not come online or report within a certain period of time, the cache is placed back into the information meta cache and deleted from the process meta cache to wait for the next cache migration task.
[0075] Step 5: After the thread completes the task of issuing management, it deletes the cache related to this operation from the process meta cache and releases the thread resources. Then the cache migration listening thread and the issuing listening thread continue to repeat the process of steps 3 and 4.
[0076] The same or similar labels correspond to the same or similar parts;
[0077] The terms used to describe positional relationships in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent.
[0078] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.
Claims
1. A pre-management optimization method for ACS servers based on the TR069 protocol, characterized in that, Includes the following steps: When the ACS server starts, a cache migration listener thread and a distribution listener thread are created synchronously, and a fixed-length thread pool and Redis middleware are started. The issued configuration information is saved to the database and also to the configuration information metadata cache of the Redis middleware. After the cache migration listening thread detects that the configuration information meta-cache exists in the Redis middleware, the cache migration listening thread executes a task to migrate the configuration information meta-cache to the process meta-cache of the Redis middleware, and deletes the configuration information meta-cache after the task is completed. After the delivery monitoring thread detects that the network device is online and that the network device is in the process meta cache, the delivery monitoring thread creates a delivery management task based on the TR069 protocol and submits it to a fixed-length thread pool for execution. The fixed-length thread pool completes the distribution and management tasks.
2. The ACS server pre-management optimization method based on the TR069 protocol according to claim 1, characterized in that, The ACS server completes the pre-configuration management process, including: Before network devices report information based on the TR069 protocol, the network configuration of the network devices is filled in in advance, and network devices of specific models or specific MAC addresses are bound to the network configuration to form several pre-configuration records; When a network device reports information via the TR069 protocol, the ACS server detects that the identifier of the network device exists in the pre-configuration record. The ACS server will then send the network configuration information in the pre-configuration record to the network device in the form of a targeted network packet.
3. The ACS server pre-management optimization method based on the TR069 protocol according to claim 2, characterized in that, The issued configuration information is saved to the database and also to the Redis middleware's configuration information metadata cache, including: The issued configuration information is saved to the database and simultaneously saved in JSON format to the configuration information metadata cache of the Redis middleware.
4. The ACS server pre-management optimization method based on the TR069 protocol according to claim 3, characterized in that, The configuration information metadata is saved in JSON format to the Redis middleware's metadata cache, including: The configuration information metadata cache is stored in key-value format. The value stores the configuration information, including WAN configuration, LAN configuration, and VoIP configuration, while the key is the identifier of the network device and a unique identifier used to identify the specific configuration.
5. The ACS server pre-management optimization method based on the TR069 protocol according to claim 4, characterized in that, Redis middleware's process meta-cacher includes: The process meta cache is stored in key-value format. The value stores configuration information, including WAN configuration, LAN configuration, and VoIP configuration. The key is the identifier of the network device, a unique identifier for identifying specific related configurations, and a distinguishing identifier for differentiating between the process meta cache and the configuration information meta cache. At the same time, the number of process meta caches is kept below a preset number.
6. The ACS server pre-management optimization method based on the TR069 protocol according to claim 5, characterized in that, The cache migration listening thread executes a task to migrate the configuration information metadata cache to the Redis middleware's process metadata cache, which also includes: If the cache migration monitoring thread checks whether the number of process meta-caches is below a preset number and there is no key in the process meta-caches that is consistent with the configuration information meta-caches, then the cache migration monitoring thread executes the task of migrating the configuration information meta-caches to the process meta-caches of the Redis middleware. If a key exists in the process meta-cache that is consistent with the configuration information meta-cache, other records in the configuration information meta-cache will be migrated first until the process meta-cache for that key is cleared.
7. The ACS server pre-management optimization method based on the TR069 protocol according to claim 6, characterized in that, The fixed-length thread pool has a preset capacity and is equipped with a delivery monitoring thread. The delivery monitoring thread is used to monitor whether a key of the process meta cache type exists in the Redis middleware and whether a corresponding network device exists. If it exists, a thread is created, and the corresponding delivery configuration module is called based on the information meta provided by the key, and then submitted to the fixed-length thread pool.
8. The ACS server pre-management optimization method based on the TR069 protocol according to claim 7, characterized in that, After the fixed-size thread pool completes the distribution of management tasks, it closes the thread that created the thread.
9. The ACS server pre-management optimization method based on the TR069 protocol according to claim 8, characterized in that, After the fixed-length thread pool completes the distribution of management tasks, it also includes deleting the process meta-cached record corresponding to the distribution of management tasks in the Redis middleware.