Service routing method for heterogeneous network

Abstract

The invention provides a service routing method for a heterogeneous network, and belongs to the technical field of multi-cloud service routing. The method comprises the following steps: mapping a core cloud, an edge cloud and terminal equipment in a heterogeneous network into logic nodes, and distributing a global unique identifier for each node; deploying a distributed database in a core cloud node and an edge cloud node, and electing a leader node based on a distributed consistency algorithm to maintain the consistency of global routing information; sensing and gathering local routing information in the edge cloud, and synchronizing the gathered local routing information to the distributed database; when cross-domain or cross-cluster transmission is needed, routing decision is made through a global information distribution mechanism. According to the method, the dynamic characteristics of the heterogeneous network can be effectively perceived and fused, intelligent and self-adaptive routing decisions meeting QoS constraints are realized, and efficient and reliable transmission of cloud services in a complex network environment is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of multi-cloud service routing technology, and in particular to a service routing method for heterogeneous networks. Background Technology

[0002] With the rapid development of cloud computing, the Internet of Things (IoT), and 5G technologies, the modern computing paradigm is evolving from centralized cloud processing to collaborative processing across cloud, edge, and endpoints. Against this backdrop, terminal access networks exhibit high heterogeneity, forming a complex environment where multiple access technologies coexist, including wired fiber optics, Wi-Fi, cellular networks (4G / 5G), satellite communications, and low-power wide-area networks (LPWAN). While this heterogeneity provides users with flexible access, it also presents significant challenges to the high-quality, efficient, and stable delivery of cloud services.

[0003] The core of cloud services lies in the fact that users can access computing and data resources on demand without needing to know the specific location of the service. However, the heterogeneity of the underlying network leads to significant and dynamic differences in key indicators such as bandwidth, latency, jitter, packet loss rate, and cost of network paths. Traditional routing protocols (such as OSPF and BGP) are mainly designed based on the shortest path principle and lack the ability to perceive the Quality of Service (QoS) requirements of upper-layer applications. They struggle to intelligently select the optimal transmission path for specific cloud services (such as low-latency applications like real-time video rendering, remote control, and VR / AR, or high-bandwidth applications like big data backup) under such complex network conditions.

[0004] Currently, the emergence of Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) technologies offers solutions to this problem. By separating control and forwarding, SDN controllers can obtain a global network view and perform centralized route calculations based on policies. However, existing SDN solutions still have limitations in multi-domain, large-scale heterogeneous network environments: First, the collection and updating of global state information incurs considerable control overhead and latency, making it difficult to respond in real time to rapidly changing network conditions; second, most solutions rely on a single routing decision factor and fail to deeply integrate multi-dimensional information such as real-time network state, link cost, user QoS requirements, and edge node computing load for joint optimization, resulting in low resource utilization efficiency and a degraded service experience. Summary of the Invention

[0005] In view of this, this invention proposes a service routing method for heterogeneous networks. This invention can effectively perceive and integrate the dynamic characteristics of heterogeneous networks, achieving intelligent, adaptive routing decisions that meet QoS constraints, thereby ensuring efficient and reliable transmission of cloud services in complex network environments.

[0006] The technical solution adopted in this invention is as follows:

[0007] A service routing method for heterogeneous networks includes the following steps:

[0008] Step 1: Map the core cloud, edge cloud, and terminal devices in the heterogeneous network as logical nodes, and assign a globally unique identifier to each node;

[0009] Step 2: Deploy a distributed database in the core cloud and edge cloud nodes, and elect a leader node based on a distributed consensus algorithm to maintain the consistency of global routing information;

[0010] Step 3: Perceive and aggregate local routing information within the edge cloud, and synchronize the aggregated local routing information to the distributed database;

[0011] Step 4: When cross-domain or cross-cluster transmission is required, routing decisions are made through a global information distribution mechanism.

[0012] Furthermore, the specific method of step 1 is as follows:

[0013] Step 101: Assign a globally unique node ID to each logical node in the heterogeneous network, and complete the mutual discovery of all nodes through a registration center or broadcast mechanism;

[0014] Step 102: Based on the underlying physical network, establish virtual logical connections between the discovered nodes to form an overlay network that overlays the physical network. The overlay network abstracts the heterogeneous physical links at the underlying level and provides a unified communication view for the upper layer.

[0015] Step 103: In the Overlay network, the core cloud node serves as the global routing information center, the edge cloud node serves as the regional routing information aggregation point, and the end node serves as the producer and consumer of routing information.

[0016] Furthermore, in step 2, the specific method for electing a leader node based on the distributed consensus algorithm is as follows:

[0017] Step 201: When the system starts, the database service processes on all core cloud and edge cloud nodes initialize their state to follower.

[0018] Step 202: Each follower node maintains a random election timeout timer. If a follower does not receive a heartbeat message from the leader before the timer expires, it will change its state to that of a candidate.

[0019] Step 203: The node that becomes a candidate increments its current term number and then sends a message requesting a vote to all other core cloud and edge cloud nodes in the Overlay network based on the RPC protocol;

[0020] Step 204: Each node can only cast one vote during the same term. If a candidate node receives more than half of the votes from the nodes, it is elected as the new leader, and the nodes that cast the votes are the majority nodes.

[0021] Step 205: The leader node periodically sends heartbeat messages to the follower nodes based on the RPC protocol to maintain its authority and prevent new elections. At this point, the distributed database enters a stable state, and all data writes must be replicated to the majority of nodes through the leader node before they are confirmed and committed.

[0022] Furthermore, the specific method for step 3 is as follows:

[0023] Step 301: The edge cloud node and its managed terminal devices perceive and maintain their local routing information table through periodic beacon broadcasts, neighbor discovery protocols, or active probing methods; the local routing information table records the direct link status from end to edge and from edge to end;

[0024] Step 302: The terminal device periodically or through event triggering reports its local routing information to the edge cloud node it is connected to;

[0025] Step 303: The edge cloud node gathers local routing information from all terminal devices within its jurisdiction, integrates and aggregates it to form an edge local view of the edge region.

[0026] Step 304: The edge cloud node submits the aggregated edge local view as a transaction request to the leader node of the distributed database. The leader node then sends the information of the distributed database to the majority nodes via a heartbeat message.

[0027] Furthermore, step 4 is specifically implemented as follows:

[0028] Step 401: The leader node in the core cloud receives local view updates from various edge cloud nodes and integrates them into the global routing information table; the global routing information table contains the topology of the entire Overlay network and the aggregation status information of each logical link.

[0029] Step 402: The leader node sends the updated information of the global routing information table to all follower nodes via heartbeat messages;

[0030] Step 403: After receiving the update information of the global routing information table from the leader node, each edge cloud node updates its local global routing information cache.

[0031] Step 404: When a new service request arrives at an edge cloud, the edge cloud combines its global and local routing information to make a routing decision and achieve cross-domain service routing.

[0032] Compared with the prior art, the beneficial effects achieved by this invention are as follows:

[0033] 1. High Availability and Strong Consistency Guarantee: By integrating the Raft distributed consensus algorithm, this invention ensures strong consistency of global routing information across the core cloud and edge cloud node clusters. Even when some nodes experience network partitioning or downtime, this architecture can automatically complete Leader election and data synchronization, maintaining the continuity of routing services and avoiding single points of failure, thus providing reliable underlying routing support for critical cloud services.

[0034] 2. Hierarchical Awareness and Scalability: A two-tiered routing information maintenance mechanism, "local-global," is adopted. Local information distribution means that the access status information of massive terminal devices does not need to be directly sent to the core cloud. Instead, it is first aggregated and filtered by edge nodes, greatly reducing the load on the core network and control plane. This hierarchical design naturally fits the three-layer structure of heterogeneous networks, "cloud-edge-device," enabling the entire solution to easily cope with network expansion by horizontally adding edge nodes, exhibiting excellent scalability.

[0035] 3. Accuracy and Intelligence of Routing Decisions: This invention overcomes the limitations of traditional routing protocols that only focus on hop count or cost, achieving intelligent routing decisions through multi-dimensional and multi-factor fusion. The routing calculation process not only relies on the global topology but also deeply integrates real-time link quality (latency, jitter, bandwidth), user-preset QoS policies (such as low latency and high throughput requirements), and the computational load of edge nodes. This enables the mechanism to dynamically select the truly "optimal path" for applications with different characteristics, such as VR / AR, industrial control, and real-time video streaming, achieving a leap from "network reachability" to "service quality reachability."

[0036] 4. Excellent real-time response capability: Local routing information is proactively and in real-time perceived at the edge using lightweight technologies (such as eBPF), ensuring rapid capture of dynamic changes in the terminal access network. Simultaneously, global information updates are completed through efficient consensus algorithms and push mechanisms (such as WebSocket), ensuring near real-time global visibility. This design enables this routing framework to quickly respond to network state fluctuations (such as sudden changes in wireless link quality) and rapidly converge and adjust routing paths, effectively guaranteeing service stability in dynamic network environments. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the routing architecture of a heterogeneous network in an embodiment of the present invention.

[0038] Figure 2 This is a flowchart illustrating the Raft election algorithm in an embodiment of the present invention. Detailed Implementation

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0040] A service routing method for heterogeneous networks is proposed. This method achieves cross-domain service routing in heterogeneous networks based on a global routing information maintenance mechanism, a local routing information maintenance mechanism, and a distributed consensus algorithm. The method deploys distributed databases in the core cloud and edge cloud, which are connected via high-bandwidth, low-latency communication. The global routing information maintenance mechanism enables the core cloud and edge cloud to periodically maintain global routing information, including link status, through the distributed database.

[0041] The global routing information table updates the network status through a distributed database between the central cloud and the edge cloud. The edge cloud updates the edge-to-end communication link information through technologies such as sensing and synchronizes the information to the distributed database to maintain the global network status information of the heterogeneous network.

[0042] The local routing information table is updated periodically through local / local interactions between edge nodes and endpoints, and stored on the endpoints. The endpoint information obtained by the edge nodes is synchronized to the distributed database to update the global routing information.

[0043] The method specifically includes the following steps:

[0044] Step 1, as follows Figure 1 As shown, an Overlay network is constructed, its nodes are determined, and all nodes of the cloud-edge-device network are mapped to the Overlay network. Specifically:

[0045] S101: Node Identification and Discovery. Assign a globally unique Node ID to each logical node in the heterogeneous network (including core cloud data centers, edge cloud nodes, and important gateways or end devices). Discovery between all nodes is achieved through a pre-defined registry center or broadcast mechanism.

[0046] S102: Logical Link Establishment. Based on the underlying physical network (such as an IP network), virtual and reliable logical connections are established between the discovered nodes, thus forming an overlay network that overlays the physical network. This overlay network abstracts the heterogeneous physical links at the underlying layer, providing a unified communication view for the upper layers.

[0047] S103: Node Role Mapping. In the Overlay network, the core cloud node is clearly defined as the global routing information center, the edge cloud node as the regional routing information aggregation point, and the end node as the producer and consumer of routing information.

[0048] Step 2: Determine the distributed database deployment nodes and control center node, and implement the consensus mechanism using the Raft election algorithm. The process is as follows: Figure 2 As shown. Specifically:

[0049] S201: Cluster Initialization. When the system starts, the database service processes on all core cloud and edge cloud nodes are initially in the Follower state.

[0050] S202: Timeout and State Transition. Each Follower node maintains a random election timeout timer (e.g., a random value between 150ms and 300ms). When a Follower does not receive a heartbeat message from the Leader before the timer expires, its state transitions to Candidate.

[0051] S203: Initiate an election. Nodes that become Candidates will:

[0052] (1) Increment its current term number.

[0053] (2) Send a request vote RPC to all other database nodes in the Overlay network (i.e., all core cloud and edge cloud nodes).

[0054] S204: Voting and Election. Other nodes can only cast one vote during the same term. If a Candidate node receives more than half of the votes from other nodes, it is elected as the new Leader.

[0055] S205: Heartbeat and Steady State. The Leader node begins periodically sending heartbeats to the Follower nodes to maintain its authority and prevent new elections. At this point, the distributed database enters a steady state, where all data writes must be replicated to a majority of nodes through the Leader node before being confirmed and committed.

[0056] The above mechanism ensures that there is at most one valid Leader node during any given term, which is responsible for the final writing and synchronization of the global routing information table, thus fundamentally avoiding data conflicts.

[0057] Step 3, local information distribution, is suitable for scenarios where the destination node and the initiating node of information transmission are within the same cluster (such as under a cloud node). The specific method is as follows:

[0058] S301: Local Awareness. Edge cloud nodes and their managed terminal devices (such as IoT sensors and mobile phones) perceive and maintain their local routing information tables through periodic beacon broadcasts, neighbor discovery protocols (such as NDP), or active probing. This table records the state of direct links from end to edge and from edge to end, such as link quality (RSSI, bandwidth, latency), neighbor node IDs, etc.

[0059] S302: Information Reporting. Terminal devices periodically or when triggered by events (such as link quality changes exceeding a threshold) report their local routing information to the edge cloud nodes they are connected to.

[0060] S303: Edge Aggregation. Edge cloud nodes aggregate local routing information from all terminal devices within their jurisdiction, and integrate and aggregate it to form a local edge view of the edge region.

[0061] S304: Synchronize to the global database. The edge cloud node submits the aggregated edge local view as a transaction request to the Leader node of the distributed database. The Leader node replicates the distributed database information to the majority of nodes via a heartbeat mechanism. This operation synchronizes local routing information upwards to update the global routing information table.

[0062] Step 4, Global Information Distribution: When information transmission requires cross-domain / cross-cluster transmission, the global information distribution function is used for information transmission. The specific method is as follows:

[0063] S401: Global Situation Building. The Leader node in the core cloud receives local view updates from various edge cloud nodes and integrates them into the global routing information table. This table contains the topology of the entire Overlay network and the aggregated status information of each logical link (such as bandwidth utilization and latency between the core cloud and the edge cloud).

[0064] S402: Global Information Distribution. Any update to the global routing information table will be actively replicated by the Leader node to all Follower nodes (i.e., all core cloud and edge cloud nodes) via append entry RPC (either carried in the heartbeat or sent separately).

[0065] S403: Edge Cloud Updates Local Cache. Each edge cloud node updates its local global routing information cache upon receiving an update from the Leader. This ensures that each edge cloud node maintains a near real-time, globally consistent view of the network situation.

[0066] S404: Route Calculation and Service Scheduling. When a new service request arrives at an edge cloud, the edge cloud can combine its global routing information (such as the best path to other edge clouds or the core cloud) and local routing information (such as the best access point to a specific terminal) to make a comprehensive and optimal routing decision, thereby achieving efficient cross-domain service routing and traffic scheduling.

[0067] like Figure 1 As shown, in practical implementation, this method can construct a software architecture consisting of an Overlay network construction module, a distributed consistency module, a local information distribution module, and a global information distribution module. This architecture is deployed on a physical infrastructure comprised of a core cloud data center, multiple edge cloud nodes (such as MEC servers), and various terminal devices (such as IoT gateways, cameras, and mobile devices). Specifically:

[0068] 1. Specific implementation of the Overlay network construction module

[0069] This module is responsible for creating a unified, logical overlay network on top of heterogeneous physical networks.

[0070] Basic environment: Kubernetes is used as the basic cloud-native orchestration platform, which abstracts each core cloud node, edge cloud node and containerized gateway device into a Pod or Node in the Kubernetes cluster.

[0071] Node Identification and Discovery: Node registration and discovery are achieved using ETCD (as a standalone service discovery component). Each node automatically generates a globally unique node ID (e.g., a 64-bit ID generated based on the Snowflake algorithm or a standard UUID) upon startup and registers its network address (IP:Port) and role information (core cloud, edge cloud, gateway) in ETCD.

[0072] Logical link establishment: Virtual links are established between nodes using the VXLAN tunneling protocol. Through the Linux vxlan kernel module or the user-space WireGuard tool, the underlying heterogeneous physical networks (such as 5G wireless access networks, enterprise internal Wi-Fi, and Internet leased lines) are encapsulated into a unified, IP-based overlay network, providing a consistent network communication interface for upper-layer applications.

[0073] 2. Specific Implementation of the Distributed Consistency Module

[0074] This module is the core component for ensuring the consistency and high availability of global routing information.

[0075] Algorithm Implementation: The etcd / raft library, written in Go, is selected as the foundation for the Raft consensus algorithm. This library has been thoroughly validated in production environments and is stable and efficient.

[0076] Cluster deployment: The service process implementing the Raft state machine is deployed on all core cloud nodes and key edge cloud nodes with certain computing resources, forming a distributed database cluster.

[0077] Parameter tuning: In a typical WAN environment, to balance availability and performance, the election timeout can be set to a random value between 1 and 2 seconds, and the heartbeat interval can be set to 200-500 milliseconds. gRPC is used as the RPC framework for communication such as voting requests and log replication between nodes to ensure high throughput and low latency.

[0078] Data persistence and commit: The Leader node is responsible for receiving data write requests (such as local view updates) from the edge cloud. The Leader only confirms the commit and updates the global routing information table after the request has been replicated to a majority of nodes in the cluster and persisted. This mechanism ensures strong data consistency.

[0079] 3. Specific Implementation of the Local Information Distribution Module

[0080] This module is responsible for refined network status awareness and reporting within the edge domain.

[0081] Local awareness technology: On edge cloud nodes, probes are implanted at the kernel level using eBPF technology to achieve real-time monitoring of virtual network interface cards (veth pairs) or physical network interface cards, and to collect key indicators such as round-trip latency, bandwidth utilization, and packet loss rate of TCP / UDP connections without loss.

[0082] Terminal information reporting: Resource-constrained terminal devices (such as sensors) use the lightweight MQTT protocol to report their status to the edge cloud nodes connected to them in a "publish-subscribe" mode. The reporting strategy is configurable, for example: periodic reporting every 5 seconds, or triggering event-based reporting when the link RSSI changes by more than 5dBm or the latency changes by more than 15%.

[0083] Edge aggregation and buffering: Edge cloud nodes run a data aggregation service (which can use Python Pandas or Go for real-time stream processing) to clean and aggregate the raw data reported by massive amounts of terminals (e.g., calculating average latency and maximum bandwidth) to form a structured edge local view. To prevent the distributed database from being overwhelmed during peak data periods, an Apache Kafka message queue can be introduced between the edge cloud and the core database as a buffer to achieve asynchronous and decoupled data synchronization.

[0084] 4. Specific Implementation of the Global Information Distribution and Routing Calculation Module

[0085] This module is responsible for constructing the macro-level network situation and making intelligent routing decisions.

[0086] Global Situation Building: The Leader node of the core cloud integrates all edge local views to build and maintain a global routing information table. This table is typically stored in memory as a graph data structure, where nodes represent logical nodes and edge weights are dynamically calculated comprehensive metric values.

[0087] Efficient information delivery: Updates to the global table are proactively and rapidly pushed to all Follower nodes via heartbeat messages or dedicated gRPC streams from the Leader node. Upon receiving an update, the edge cloud node immediately refreshes its local cache, thus maintaining a global network view that is nearly identical to that of the central node.

[0088] Intelligent routing computation: When a service request arrives (e.g., a low-latency video stream being transmitted from edge A to edge B), the routing engine of the edge cloud node combines a global view (finding all possible paths from A to B) and a local view (the best access quality from A and B to their respective endpoints) to run a routing algorithm that considers multiple constraints. Specifically, the A* algorithm can be used, where the cost function f(n) = g(n) + h(n) defines g(n) as the cumulative latency of the path and h(n) as the estimated minimum latency to the target, thus quickly finding an optimal path that meets the low-latency constraint.

[0089] Service scheduling and execution: The final calculated routing strategy is issued and executed through the integrated Istio service mesh traffic management APIs (such as VirtualService and DestinationRule), enabling fine-grained control over service traffic, such as weighted traffic distribution and failover, thereby achieving efficient cross-domain service routing and scheduling. The entire routing decision and execution process forms a closed loop, ensuring service quality.

Claims

1. A service routing method for heterogeneous networks, characterized in that, Includes the following steps: Step 1: Map the core cloud, edge cloud, and terminal devices in the heterogeneous network as logical nodes, and assign a globally unique identifier to each node; Step 2: Deploy a distributed database in the core cloud and edge cloud nodes, and elect a leader node based on a distributed consensus algorithm to maintain the consistency of global routing information; Step 3: Perceive and aggregate local routing information within the edge cloud, and synchronize the aggregated local routing information to the distributed database; Step 4: When cross-domain or cross-cluster transmission is required, routing decisions are made through a global information distribution mechanism.

2. The service routing method for heterogeneous networks as described in claim 1, characterized in that, The specific method for step 1 is as follows: Step 101: Assign a globally unique node ID to each logical node in the heterogeneous network, and complete the mutual discovery of all nodes through a registration center or broadcast mechanism; Step 102: Based on the underlying physical network, establish virtual logical connections between the discovered nodes to form an overlay network that overlays the physical network. The overlay network abstracts the heterogeneous physical links at the underlying level and provides a unified communication view for the upper layer. Step 103: In the Overlay network, the core cloud node serves as the global routing information center, the edge cloud node serves as the regional routing information aggregation point, and the end node serves as the producer and consumer of routing information.

3. The service routing method for heterogeneous networks as described in claim 1, characterized in that, In step 2, the specific method for electing a leader node based on the distributed consensus algorithm is as follows: Step 201: When the system starts, the database service processes on all core cloud and edge cloud nodes initialize their state to follower. Step 202: Each follower node maintains a random election timeout timer. If a follower does not receive a heartbeat message from the leader before the timer expires, it will change its state to that of a candidate. Step 203: The node that becomes a candidate increments its current term number and then sends a message requesting a vote to all other core cloud and edge cloud nodes in the Overlay network based on the RPC protocol; Step 204: Each node can only cast one vote during the same term. If a candidate node receives more than half of the votes from the nodes, it is elected as the new leader, and the nodes that cast the votes are the majority nodes. Step 205: The leader node periodically sends heartbeat messages to the follower nodes based on the RPC protocol in order to maintain its authority and prevent new elections. At this point, the distributed database has entered a stable state, and all data writes must be replicated to the majority of nodes through the leader node before they are confirmed and committed.

4. The service routing method for heterogeneous networks as described in claim 1, characterized in that, The specific method for step 3 is as follows: Step 301: The edge cloud node and its managed terminal devices perceive and maintain their local routing information table through periodic beacon broadcasts, neighbor discovery protocols, or active probing methods; the local routing information table records the direct link status from end to edge and from edge to end; Step 302: The terminal device periodically or through event triggering reports its local routing information to the edge cloud node it is connected to; Step 303: The edge cloud node gathers local routing information from all terminal devices within its jurisdiction, integrates and aggregates it to form an edge local view of the edge region. Step 304: The edge cloud node submits the aggregated edge local view as a transaction request to the leader node of the distributed database. The leader node then sends the information of the distributed database to the majority nodes via a heartbeat message.

5. A service routing method for heterogeneous networks as described in claim 1, characterized in that, The specific method for step 4 is as follows: Step 401: The leader node in the core cloud receives local view updates from various edge cloud nodes and integrates them into the global routing information table; the global routing information table contains the topology of the entire Overlay network and the aggregation status information of each logical link. Step 402: The leader node sends the updated information of the global routing information table to all follower nodes via heartbeat messages; Step 403: After receiving the update information of the global routing information table from the leader node, each edge cloud node updates its local global routing information cache. Step 404: When a new service request arrives at an edge cloud, the edge cloud combines its global and local routing information to make a routing decision and achieve cross-domain service routing.

Images