Wireless network management system microservice architecture and containerized implementation method

Abstract

The application discloses a wireless network management system micro-service architecture and containerized implementation method, and belongs to the network management field, and comprises the following steps: step one, network function containerization deployment: network functions are split into multiple micro-services and are deployed in containers, and a containerized virtual switch and network controller are used to uniformly abstract and dynamically manage network resources; step two, dynamic clustering management and dynamic network access management: the micro-service cluster is dynamically managed in clusters, the network nodes are dynamically clustered, the service deployment topology and communication path are optimized according to node position, link quality and load information; and the network nodes and micro-service instances are dynamically managed to access or exit the network, so that the configuration, recovery and topology adaptive adjustment of network resources are realized. The application improves the elastic management, automatic deployment and dynamic expansion and contraction capacity of network functions in a cloud native environment.

Description

Technical Field

[0001] This invention relates to the field of network management, and more specifically, to a microservice architecture and containerization implementation method for a wireless network management system. Background Technology

[0002] With the rapid development of microservice architecture and container technology, container-based network function virtualization has become a key support for modern communication systems to achieve flexible resource scheduling and rapid service delivery. Microservice architecture significantly improves system maintainability and scalability by breaking down monolithic applications into a set of loosely coupled, independently deployable services. Containerization technology further enables resource isolation, environment consistency, and second-level deployment and elastic scaling capabilities, laying the foundation for dynamic management of network functions.

[0003] However, in highly dynamic network environments, the deployment and management of microservice-based network functions still face numerous challenges. The frequent creation and destruction of microservice instances lead to continuous changes in network topology; dynamic node joining and leaving require real-time responses; and service discovery and network resource configuration also need to be highly adaptive. Traditional static resource allocation and manual configuration methods are insufficient to meet the automation, real-time performance, and reliability requirements of microservice architectures. Especially in scenarios with increased node scale and complex service dependencies, how to achieve efficient communication between microservices, dynamic resource scheduling and lifecycle management, and ensure service continuity and stability in dynamic environments has become a core issue that urgently needs to be addressed.

[0004] In contrast, traditional network architectures typically rely on static resource allocation and pre-configured network topology, resulting in inefficient resource utilization and insufficient flexibility. Under this architecture, the network topology and nodes are tightly coupled; once network load or business requirements change, topology adjustments often require manual intervention, making automation and real-time adjustment difficult. Furthermore, the process of adding and removing nodes in traditional architectures is cumbersome, often requiring manual operation or complex configuration updates, severely limiting the system's adaptability to dynamic environments.

[0005] As network scale continues to expand and the number of nodes increases, the limitations of traditional architectures are becoming increasingly apparent. While containerized network function virtualization (NFV) technology has emerged to address this, supporting a degree of dynamic resource management, it still has significant shortcomings in areas such as efficient resource scheduling and handling frequent dynamic changes in nodes. Specifically, how to optimize network topology through automated clustering mechanisms, and how to achieve seamless integration and high availability when nodes join or leave, remain significant challenges in current network management.

[0006] Therefore, combining containerized network function virtualization technology with intelligent clustering algorithms to design an efficient dynamic management mechanism for node entry and exit has become a key direction for improving network resource scheduling capabilities, topology adaptation capabilities, and node management capabilities. Related breakthroughs will significantly enhance the adaptability and stability of networks in high-load and complex environments, providing solid technical support for the widespread application of containerization and virtualization technologies. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a microservice architecture and containerization implementation method for a wireless network management system, which improves the elastic management, automated deployment and dynamic scaling capabilities of network functions in a cloud-native environment.

[0008] The objective of this invention is achieved through the following solution:

[0009] A microservice architecture and containerized implementation method for a wireless network management system, comprising:

[0010] Step 1, Containerized Deployment of Network Functions: Decompose network functions into multiple microservices and deploy them in containers. Use containerized virtual switches and network controllers to uniformly abstract and dynamically manage network resources.

[0011] Step 2, Dynamic Clustering Management and Dynamic Network Entry / Exit Management: Dynamic clustering management is performed on the microservice cluster, and network nodes are dynamically clustered. Service deployment topology and communication paths are optimized based on node location, link quality, and load information. Dynamic network entry / exit management is performed on nodes and microservice instances, enabling adaptive adjustment of network resource configuration, reclamation, and topology.

[0012] Furthermore, the containerized virtual switch is specifically encapsulated using Open vSwitch; the network controller is specifically deployed using ONOS containerization; the two interact with each other and synchronize states in real time via the OpenFlow protocol.

[0013] Furthermore, the dynamic clustering of network nodes is specifically based on the K-means clustering algorithm for dynamic cluster management. In K-means clustering, the primary cluster head node is selected from the nodes closest to the cluster center, and the backup cluster head node is selected from the nodes closest to the primary cluster head. The cluster structure is periodically updated to respond to dynamic changes in nodes.

[0014] Furthermore, the dynamic clustering management based on the K-means clustering algorithm involves selecting the node closest to the cluster center as the primary cluster head node and selecting the node closest to the primary cluster head as the backup cluster head node. The cluster structure is periodically updated to respond to dynamic changes in nodes, specifically including the following sub-steps:

[0015] Step A1: Given a set of data points The K-means algorithm was used to divide these points into K clusters. This minimizes the following objective function:

[0016] (1);

[0017] in, It is a cluster The center of is calculated using the following formula:

[0018] (2);

[0019] Step A2: Design the following cluster head selection rule:

[0020] For each cluster The rules for selecting the cluster head are as follows:

[0021] Cluster head selection: Select the cluster head closest to the cluster center. The nearest node is designated as the head of the primary cluster.

[0022] (3);

[0023] Alternate cluster head selection: Select the node closest to the primary cluster head from the remaining nodes as the alternate cluster head.

[0024] (4);

[0025] Step A3: Output Results: Generate detailed information for each cluster, including cluster center coordinates, primary cluster head node number, backup cluster head node number, and cluster member list. Record the information for each cluster according to the set format, and visually distinguish and display the ordinary cluster members, primary cluster head, and backup cluster head.

[0026] Furthermore, the dynamic entry and exit management of nodes and microservice instances, enabling adaptive adjustment of network resource configuration, reclamation, and topology, including node entry and service deployment, comprises the following sub-steps:

[0027] Step B1, Creating and Starting Containers: Use commands to start a new container node and allocate network to it; the microservice scheduler decides the deployment location of the new service instance based on the clustering results;

[0028] Step B2, Dynamic IP Allocation and Network Interface Configuration: In Docker, containers are allocated IP addresses through network bridging or overlay networks; the Docker Compose module is used to manage IP address allocation between containers and supports cross-host network connections; for each newly added node, the container is allocated an available IP address according to the configured network driver;

[0029] Step B3, Network Topology Update: The network topology is dynamically updated based on node additions to ensure that new nodes can integrate into the network. The Docker Swarm module is used to manage the container cluster and network topology. When a container joins, the scheduling system discovers the container's network interface and connects it to the designated network. The container's network topology is dynamically updated during scheduling to ensure that new nodes can access the network normally.

[0030] Furthermore, the dynamic entry and exit management of nodes and microservice instances, enabling adaptive adjustment of network resource configuration, reclamation, and topology, including node exit and service migration, includes the following sub-steps:

[0031] Step C1: Node Stopping and Destruction: When a node exits, it first completes the deregistration operation, notifies the network through the control layer, marks the node as offline, and clears its network status; when a container exits, it stops and deletes the container through a command, and network resources are reclaimed; and a periodic monitoring mechanism is used to track the offline status of nodes in real time, and removes the node from the network member list if it does not respond within a set time.

[0032] Step C2: Network Resource Reclamation: When a container is taken offline, Docker's network driver mechanism reclaims the container's IP address and updates the routing table and network configuration. Docker supports bridge and overlay network management of IP address pools to ensure the effective utilization of network resources.

[0033] Step C3: Topology Reorganization: When containers are taken out of the network, the network topology is reassessed and the routing configuration is adjusted. For cross-host communication, Docker adjusts the routing table of the Overlay network. The service discovery mechanism in the Docker Swarm module is used to ensure that the communication of the remaining containers is not affected when containers are taken out of the network.

[0034] Furthermore, the dynamic entry and exit management of nodes and microservice instances, enabling adaptive adjustment of network resource configuration, reclamation, and topology, including network isolation and communication between containers, includes the following sub-steps:

[0035] By using different network modes, containers can achieve effective communication while maintaining network isolation. These network modes include bridge network mode and overlay network mode. On the same host, containers communicate through the bridge network; when crossing hosts, containers communicate through the overlay network. Service discovery is performed using the Docker Swarm module to ensure interoperability between containers in dynamic environments.

[0036] The beneficial effects of this invention include:

[0037] This invention addresses the challenges of dynamic deployment of network functions, automatic resource scheduling, and elastic node management in microservice architectures, enhancing network resilience, scalability, and dynamic management capabilities, as well as improving system adaptability and fault tolerance in changing environments. Specifically, the method decomposes network functions into fine-grained microservices and implements containerized deployment, utilizing containerized Open vSwitch and the ONOS controller to achieve unified resource management and dynamic scaling. The K-means clustering algorithm is used to dynamically cluster network nodes, optimizing service deployment topology and communication paths. Intelligent selection of primary and backup cluster heads improves load balancing and access efficiency. A dynamic joining and leaving mechanism for nodes and microservice instances enables automatic configuration, reclamation, and adaptive topology adjustment of network resources, ensuring service continuity. In summary, this method improves network resource utilization, optimizes network performance, and is suitable for dynamically changing network environments. Simulation results demonstrate that this method significantly improves network resource utilization and effectively handles complex situations such as node failures and network topology changes, exhibiting strong application prospects and technological advantages. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a schematic diagram of the containerized network functional architecture based on microservices in the method of this embodiment of the invention;

[0040] Figure 2 This is a flowchart of the dynamic clustering management process in the method of this embodiment of the invention. Detailed Implementation

[0041] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0042] This invention relates to a containerized network function virtualization, dynamic resource scheduling, and node management technology solution based on a microservice architecture, aiming to improve the elastic management, automated deployment, and dynamic scaling capabilities of network functions in cloud-native environments. More specifically, this invention provides a microservice architecture and containerized implementation method for a wireless network management system, such as... Figure 1 and Figure 2 As shown, the specific steps include the following:

[0043] Step 1: Containerized Deployment of Network Functions Based on Microservices. Specifically, regarding microservice-based network function components, traditional network functions are broken down into independently deployable microservice units, such as routing services, load balancing services, and security policy services. Each service is encapsulated as a lightweight container with autonomous management and open interfaces. On the containerized network control plane and data plane, containerized technology is used to deploy the control plane component ONOS controller and the data plane unit OVS switch, supporting microservice-level scaling and fault recovery. OVS is encapsulated in a container, enabling automatic deployment, startup, shutdown, and hot restart on demand. It supports rapid integration and parallel operation of multiple instances, meeting flexible network topology construction needs. Containerized OVS instances seamlessly interact with the software-defined network controller ONOS through the standard OpenFlow protocol, receiving flow table rules to achieve centralized control of forwarding paths and packet processing behavior. The ONOS controller is encapsulated as a hot-migratable and elastically scalable container service, supporting cluster deployment and possessing fault recovery and horizontal scaling capabilities to achieve distributed network control and centralized policy distribution. Through the OpenFlow protocol, the controller and the OVS within the container exchange flow tables, status, and statistics in real time, ensuring automatic adjustment of routing and forwarding policies based on dynamic changes in business operations, enabling on-demand orchestration. The controller has real-time monitoring and modeling capabilities for network topology, link status, and task flow QoS requirements, and generates scheduling policies accordingly, supporting rapid response and optimization in complex scenarios. Regarding bridge virtualization, technologies such as Linux Bridge and OVS Bridge are used to construct virtual bridges, enabling Ethernet frame-level communication between processes within the container and across container nodes, meeting MAC address-level data forwarding requirements. VLAN tag configuration enables isolated communication between different task groups or tenants, ensuring resource security and business independence, suitable for dynamic task grouping and access control scenarios. The virtual bridge component can work in conjunction with container platform network plugins and OVS to achieve automatic identification and dynamic adjustment of network topology, improving the scalability and maintainability of the container network environment.

[0044] Step 2: Dynamic Clustering Management and Dynamic Network Entry / Exit Management of Nodes and Microservice Instances Based on K-means Clustering Algorithm. Specifically, in the dynamic clustering management scheme based on the K-means clustering algorithm, the clustering algorithm dynamically clusters network nodes. Based on this algorithm and considering the scenario of this embodiment, a dynamic clustering management mechanism is proposed. This algorithm divides nodes into several clusters according to their location, link quality, load, and other information, ensuring efficient collaboration and resource sharing within each cluster. The specific design steps are as follows:

[0045] Step A1: Given a set of data points The goal of the K-means algorithm is to divide these points into K clusters. This minimizes the following objective function:

[0046] (1);

[0047] in, It is a cluster The center (centroid) is calculated using the following formula:

[0048] (2);

[0049] Step A2: Design the following cluster head selection rule:

[0050] For each cluster The rules for selecting the cluster head are as follows:

[0051] Cluster head selection: Select the cluster head closest to the cluster center. The nearest node is the head of the primary cluster.

[0052] (3);

[0053] Alternate cluster head selection: Select the node closest to the primary cluster head from the remaining nodes as the alternate cluster head.

[0054] (4);

[0055] Step A3: Output Results: Generate detailed information for each cluster, including cluster center coordinates, primary cluster head node number, backup cluster head node number, and a list of cluster members. Record the information for each cluster in the format of "cluster sequence number - cluster head number - backup cluster head number - set of cluster member numbers". Visualize the clustering results, using different colors and shapes to identify ordinary cluster members, primary cluster head, and backup cluster head.

[0056] The dynamic network entry and exit management scheme for nodes and microservice instances specifically includes the processes of node entry and service deployment, node exit and service migration, and network isolation and communication between containers.

[0057] The node network access and service deployment process includes the following steps:

[0058] Step B1, Creating and Starting Containers: Use commands to start a new container node and assign it a suitable network. The microservice scheduler decides the deployment location of the new service instance based on the clustering results.

[0059] Step B2, Dynamic IP Allocation and Network Interface Configuration: In Docker, containers are assigned IP addresses through network bridging or overlay networks. Docker Compose can automatically manage IP address allocation between containers and support cross-host network connections. For each newly added node, the container will automatically be assigned an available IP address based on the configured network driver (such as bridge or overlay).

[0060] Step B3, Automatic Network Topology Update: The network topology is dynamically updated based on node additions, ensuring new nodes can quickly integrate into the network. Docker Swarm is used to manage container clusters and network topology. When a container joins, the scheduling system automatically discovers the container's network interface and connects it to the designated network. The container's network topology is dynamically updated during scheduling to ensure new nodes can access the network correctly.

[0061] The node decommissioning and service migration specifically includes the following steps:

[0062] Step C1: Node Stopping and Destruction: When a node exits, it first needs to complete a deregistration operation. The control layer notifies the network, marking the node as offline and clearing its network status. When a container exits, it is stopped and deleted via command. Network resources (such as IP addresses, routing information, etc.) are reclaimed. A periodic monitoring mechanism is used to track the offline status of nodes in real time; if a node remains unresponsive for an extended period, it is removed from the network member list.

[0063] Step C2: Network Resource Reclamation: When a container is taken offline, its IP address is reclaimed, and its routing table and network configuration are updated through Docker's network driver mechanism. Docker's supported bridge and overlay networks automatically manage IP address pools to ensure efficient use of network resources.

[0064] Step C3: Topology Reorganization: When a container leaves the network, the system reassesses the network topology and adjusts routing configurations to ensure network reliability and efficiency. For cross-host communication, Docker automatically adjusts the routing table of the Overlay network. The service discovery mechanism in Docker Swarm ensures that communication of remaining containers is not affected when a container leaves the network.

[0065] The network isolation and communication between containers specifically includes the following steps:

[0066] Each container has its own independent network namespace, providing an isolated network environment. By using different network modes (such as bridge or overlay), containers can communicate effectively while maintaining network isolation. On the same host, containers communicate via a bridge network; when crossing hosts, containers communicate via an overlay network. Docker Swarm is used for service discovery, ensuring interoperability between containers in dynamic environments.

[0067] In summary, the above-described embodiments of the present invention have the following characteristics: The design of a dynamic joining and leaving mechanism for nodes and microservice instances enables automatic configuration, reclamation, and adaptive topology adjustment of network resources, ensuring service continuity and high availability; the use of container network plugins to construct virtual bridges supports Ethernet frame-level communication between nodes, ensuring isolation and security between different tenants or task groups; and the combination of a distributed service discovery mechanism ensures that containerized nodes can automatically identify and connect in dynamically changing environments, enhancing the overall resilience and self-organization capabilities of the network.

[0068] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0069] According to one aspect of the present invention, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described above.

[0070] In another aspect, embodiments of the present invention also provide a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

Claims

1. A microservice architecture and containerized implementation method for a wireless network management system, characterized in that, include: Step 1, Containerized Deployment of Network Functions: Decompose network functions into multiple microservices and deploy them in containers. Use containerized virtual switches and network controllers to uniformly abstract and dynamically manage network resources. Step 2, Dynamic Clustering Management and Dynamic Network Entry / Exit Management: Dynamic clustering management is performed on the microservice cluster, dynamically clustering network nodes and optimizing service deployment topology and communication paths based on node location, link quality, and load information. Specifically, this includes: using the K-means clustering algorithm to dynamically cluster network nodes to optimize service deployment topology and communication paths; in K-means clustering, the primary cluster head node is selected from the nodes closest to the cluster center, and the backup cluster head node is selected from the nodes closest to the primary cluster head, with periodic updates to the cluster structure to respond to dynamic changes in nodes; dynamic network entry / exit management is performed on nodes and microservice instances, enabling adaptive adjustments to network resource configuration, reclamation, and topology; the dynamic network entry / exit management includes node entry and service deployment, and node exit and service migration. The specific sub-steps for node network access and service deployment are as follows: Step B1, Creating and Starting Containers: Use commands to start a new container node and allocate network to it; the microservice scheduler decides the deployment location of the new service instance based on the clustering results; Step B2, Dynamic IP Allocation and Network Interface Configuration: In Docker, containers are allocated IP addresses through network bridging or overlay networks; the Docker Compose module is used to manage IP address allocation between containers and supports cross-host network connections; for each newly added node, the container is allocated an available IP address according to the configured network driver; Step B3, Network Topology Update: The network topology is dynamically updated based on node additions to ensure that new nodes can integrate into the network. The Docker Swarm module is used to manage the container cluster and network topology. When a container joins, the scheduling system discovers the container's network interface and connects it to the designated network. The container's network topology is dynamically updated during scheduling to ensure that new nodes can access the network normally. The specific sub-steps for node decommissioning and service migration are as follows: Step C1: Node Stopping and Destruction: When a node exits, it first completes the deregistration operation, notifies the network through the control layer, marks the node as offline, and clears its network status; when a container exits, it stops and deletes the container through a command, and network resources are reclaimed; and a periodic monitoring mechanism is used to track the offline status of nodes in real time, and removes the node from the network member list if it does not respond within a set time. Step C2: Network Resource Reclamation: When a container is taken offline, Docker's network driver mechanism reclaims the container's IP address and updates the routing table and network configuration. Docker supports bridge and overlay network management of IP address pools to ensure the effective utilization of network resources. Step C3: Topology Reorganization: When containers are taken out of the network, the network topology is reassessed and the routing configuration is adjusted. For cross-host communication, Docker adjusts the routing table of the Overlay network. The service discovery mechanism in the Docker Swarm module is used to ensure that the communication of the remaining containers is not affected when containers are taken out of the network.

2. The microservice architecture and containerized implementation method of the wireless network management system according to claim 1, characterized in that, The containerized virtual switch is specifically encapsulated using Open vSwitch; the network controller is specifically deployed using ONOS containerization; the two interact with each other and synchronize states in real time via the OpenFlow protocol.

3. The microservice architecture and containerized implementation method of the wireless network management system according to claim 1, characterized in that, The dynamic clustering management based on the K-means clustering algorithm involves selecting the node closest to the cluster center as the primary cluster head node and the node closest to the primary cluster head as the backup cluster head node. The cluster structure is periodically updated to respond to dynamic changes in nodes, specifically including the following sub-steps: Step A1: Given a set of data points The K-means algorithm was used to divide these points into K clusters. This minimizes the following objective function: (1)； in, It is a cluster The center of is calculated using the following formula: (2)； Step A2: Design the following cluster head selection rule: For each cluster The rules for selecting the cluster head are as follows: Cluster leader selection: Select the cluster leader based on its distance from the cluster center. The nearest node becomes the head of the primary cluster: (3)； Alternate cluster head selection: Select the node closest to the primary cluster head from the remaining nodes as the alternate cluster head. (4)； Step A3: Output Results: Generate detailed information for each cluster, including cluster center coordinates, primary cluster head node number, backup cluster head node number, and cluster member list. Record the information for each cluster according to the set format, and visually distinguish and display the ordinary cluster members, primary cluster head, and backup cluster head.

4. The microservice architecture and containerized implementation method of the wireless network management system according to claim 1, characterized in that, The dynamic entry and exit management of nodes and microservice instances enables adaptive adjustment of network resource configuration, reclamation, and topology, including network isolation and communication between containers. The specific sub-steps are as follows: by using different network modes, containers can achieve effective communication while maintaining network isolation. The network modes include bridge network mode or overlay network mode; on the same host, containers communicate through the bridge network. When traveling across hosts, containers communicate via an overlay network; the Docker Swarm module is used for service discovery to ensure interoperability between containers in dynamic environments.

Images