Satellite internet deterministic routing data plane migration method based on prediction topology

Abstract

The invention discloses a predictive topology-based satellite internet deterministic routing data plane migration method, which mainly solves the problem of data packet and service interruption during satellite switching in the prior art. According to the implementation scheme, service flow terminal equipment firstly sends an access request to an entrance edge node; the entry edge node calculates a tunnel path and resource reservation according to the request, performs service identification, encapsulates various identifiers into deterministic specific segment identifiers, and encapsulates the original data packet into an SRv6 data packet based on the tunnel path and the specific segment identifiers; when the service flow is transmitted in the satellite network, if a satellite is switched, service flow tunnel migration is carried out, and when a queue data packet exists in the switched satellite, queue cache migration is carried out. According to the invention, the forwarding of the service flow in the satellite switching process is not influenced, the flow interruption or transmission error caused by lack of information pre-synchronization in the traditional satellite switching is avoided, the priority transmission of the high-priority data packet is ensured, and the method can be used for data transmission between a ground terminal and a deterministic satellite network.

Description

Technical Field

[0001] The present invention belongs to the field of mobile communication technology, and particularly designs a satellite Internet deterministic routing data plane migration method, which can be used for data transmission between a ground terminal and a deterministic satellite network. Background Art

[0002] Predictive topology is a mechanism that can calculate the future movement position of a satellite in advance based on parameters such as the satellite's period and orbit. Deterministic network Detnet refers to a service that provides deterministic streaming by the network, which provides a function of delivering data streams with extremely low packet loss rate and limited end-to-end transmission delay. In the deterministic satellite Internet network architecture, its network element architecture is mainly divided into four types of nodes: terminal systems, entry edge nodes, intermediate nodes, and exit edge nodes. However, existing deterministic satellite networks often use path transmission technology based on static routing or tunnels, which will lead to increased path reconstruction delay, packet loss and service interruption when satellite switching occurs, and cannot meet the application requirements in high reliability and low latency scenarios.

[0003] Patent publication number CN112291147A discloses a method for applying dynamic intelligent SR tunnels for 5G services. This method simplifies Multi-Protocol Label Switching (MPLS) technology by leveraging SR source routing technology. It also reuses MPLS's existing forwarding mechanisms to maintain compatibility with existing MPLS networks, supporting the smooth evolution of existing MPLS networks to software-defined networks (SDNs). This method primarily focuses on the construction and application of SR tunnels for 5G services, but does not consider the frequent switching of network element nodes in satellite networks, which can affect the continuity and stability of SR tunnels.

[0004] Patent publication number CN119135245A discloses a distributed mobility management method for satellite internet. This method uses VIP and subVIP management mechanisms to hide satellite mobility. The old satellite synchronizes the connection management information and satellite routing of online users to the new satellite in real time, allowing users to maintain the same IP address before and after a satellite handoff. This method primarily focuses on satellite internet mobility management and does not specifically consider the issues faced when switching between different network element nodes within the satellite internet, nor does it address issues related to node queue switching. This can increase data stream latency and packet loss, impacting the continuity and sequential nature of forwarding. Summary of the Invention

[0005] The purpose of the present invention is to address the deficiencies of the above-mentioned prior art and provide a satellite Internet deterministic routing data plane migration method based on predictive topology to avoid data packet loss and service interruption during satellite switching, ensure the continuity and stability of business flows, and improve data transmission performance.

[0006] The technical approach to achieving the objectives of the present invention is as follows: a unique flow identifier, Flow-ID, is assigned to each service flow through a resource reservation protocol, and a different deterministic flow identifier, DSID, is encapsulated for each service flow in combination with SRv6 technology and service flow requirements. When a satellite is about to switch, a predictive topology mechanism is used to know the satellite switching time in advance. Before the switch, the original satellite uses the deterministic flow identifier, DSID, to seamlessly migrate tunnel information and queue cache information to the new satellite, thereby achieving seamless migration and transmission of service flows from the original satellite to the new satellite.

[0007] Based on the above ideas, the satellite Internet deterministic routing data plane migration method based on predicted topology of the present invention includes the following steps:

[0008] (1) The service flow terminal device sends a request to the satellite entry edge node to access the satellite Internet deterministic network. The entry edge node determines whether it needs to calculate the transmission path required by the service flow based on the access request:

[0009] If calculation is required, execute step (2);

[0010] If no calculation is required, proceed to step (3);

[0011] (2) Calculate the tunnel path based on the topology and service flow requirements of the satellite Internet deterministic network, reserve resources based on the tunnel path to obtain the flow identifier Flow-ID, and select the location identifier LOC, function identifier FUNCT, queue identifier QID, and sequence identifier SEN for identification according to the different service flows;

[0012] (3) The ingress edge node uses the flow identifier Flow-ID, location identifier LOC, function identifier FUNCT, queue identifier QID, and sequence identifier SEN to assemble a deterministic specific segment identifier DSID, and encapsulates the original data packet of the service flow into an IPv6-based segment routing SRv6 data packet based on the tunnel path and the deterministic specific segment identifier DSID;

[0013] (4) The service flow is transmitted in the satellite Internet along the tunnel path encapsulated by the SRv6 data packet. When the satellite is about to switch during the transmission process, the service flow is migrated through the tunnel. If there are queues waiting to be forwarded on the switched satellite, these packets are queued and cached before being migrated.

[0014] (5) After the service flow transmission is completed, the ingress edge node clears the relevant data of the service flow.

[0015] Compared with the prior art, the present invention has the following advantages:

[0016] First, the present invention combines predictive topology with deterministic specific segment identifiers (DSIDs) to implement a traffic management mechanism for seamless traffic switching and continuous transmission. Compared with traditional satellite switching mechanisms, the present invention can ensure that the forwarding of service flows is not affected during the satellite switching process, avoid data loss and sequence disruption, and improve the reliability and stability of traffic transmission.

[0017] Secondly, the tunnel migration mechanism proposed in this invention synchronizes flow state information in advance, especially when switching between ingress edge nodes, intermediate nodes, and egress edge nodes. This ensures that service flows are promptly processed on the new satellite node, avoiding traffic interruptions and transmission errors caused by the lack of pre-synchronization in traditional satellite handovers. This mechanism improves the adaptability and reliability of satellite networks in dynamic topology environments.

[0018] Third, the proposed cache migration scheme for remaining packets in queues ensures that during satellite handovers, high-priority traffic flows are prioritized, while standard traffic flows are transmitted on a best-effort basis. This avoids the high-priority packet loss and performance degradation that can occur during traditional handovers. By employing different cache strategies during satellite handovers to preserve flow information and synchronize flow status information, a smooth traffic transition is ensured, improving protection for high-priority traffic flows. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is an implementation flow chart of the present invention;

[0020] Figure 2 This is a diagram of the satellite Internet network architecture used in the present invention;

[0021] Figure 3 It is a diagram of the encapsulation format of the deterministic specific segment identifier DSID in the present invention;

[0022] Figure 4 It is a schematic diagram of the encapsulation of the Detnet stream data packet in the present invention;

[0023] Figure 5 It is a schematic diagram of a satellite state diagram for migrating business flows in the present invention. DETAILED DESCRIPTION

[0024] The embodiments of the present invention are described in further detail below with reference to the accompanying drawings.

[0025] The implementation scenario of the present invention is a satellite Internet network, such as Figure 2As shown in the figure, it includes four types of network element nodes: end systems, ingress edge nodes, intermediate nodes, and egress edge nodes. The end system is the user's device and generally does not have Detnet capabilities. The ingress edge node is responsible for obtaining the service flow identification and resource allocation of the end system service, and provides tunnel path calculation for the service flow. If the service flow requires it, it also provides service protection for it in the satellite Internet, that is, providing packet replication, deletion, and sorting functions for the service flow. Finally, the egress edge node forwards the original data packet to the destination end system. Intermediate nodes need to have forwarding capabilities, and some intermediate nodes also need additional service protection functions based on service flow requirements. In addition, network element nodes must achieve high-precision time synchronization through protocols such as the Precision Time Protocol (PTP) to ensure a consistent time base across the entire network.

[0026] Example 1: Satellite Internet Deterministic Routing Data Plane Migration Method Based on Predicted Topology

[0027] Reference Figure 1 The implementation steps of this example include the following:

[0028] Step 1: Access request and path decision:

[0029] Each satellite node collects network node topology information through the OSPF-TE protocol and obtains the latency and jitter within the node and between upstream and downstream nodes in real time. When a terminal device needs to use satellite Internet, it sends a request to the entry edge node through the user-to-network interface UNI interface to apply for access to the satellite network;

[0030] The ingress edge node receives the service flow access request from the terminal device and extracts key requirements from it, including:

[0031] Deterministic requirements, such as latency limits, jitter tolerance, and packet loss rate thresholds;

[0032] Resource requirements, i.e. bandwidth, priority;

[0033] Reliability requirements, i.e. redundant paths;

[0034] Based on the satellite orbit prediction model and inter-satellite link quality obtained from the predicted topology, the ingress edge node obtains dynamic network topology information in real time through OSPF control signaling and queries the remaining bandwidth, forwarding delay, and other remaining resources of the current tunnel path.

[0035] The ingress edge node then compares the remaining resources with the key requirements extracted from the access request to determine whether to trigger tunnel path calculation:

[0036] If the remaining resources of the current tunnel path cannot meet the service flow requirements, the tunnel path calculation is triggered and step 2 is executed;

[0037] If the service flow requirements are met, tunnel path calculation is not triggered and step 3 is executed.

[0038] Step 2: Path calculation and resource allocation.

[0039] 2.1) The ingress edge node converts the QoS requirements of different service flows into constraints that must be met when calculating the optimal path, including:

[0040] Delay constraint: end-to-end delay ≤ service flow delay upper limit;

[0041] Bandwidth constraint: The remaining bandwidth of all links in the path must be ≥ the bandwidth required by the service flow;

[0042] 2.2) The ingress edge node first selects an alternative path that meets the requirements based on the above constraints, and then calculates the path weight G of the alternative path according to the path weight calculation formula:

[0043]

[0044] Among them, α is the weight coefficient dynamically adjusted according to the service flow propagation delay t, d is the geometric distance between satellites, c is the speed of light, M is the tunnel path survival time estimated by the predicted topology mechanism, and β is the weight coefficient dynamically adjusted based on the tunnel path survival time M of the service flow. α and β satisfy the constraint condition α + β = 1 (α > 0, β > 0). After the calculation is completed, the entry edge node selects the tunnel path with the lowest weight value as the tunnel path for the service flow based on the path weight G.

[0045] 2.3) After the tunnel path calculation is completed, the ingress edge node and the egress edge node interact to complete resource reservation:

[0046] 2.3.1) Based on the path, the ingress edge node uses the Resource Reservation Protocol (RSVP-TE) to send a PATH request to the egress edge node to reserve the path resources for the flow and obtain the Flow-ID.

[0047] 2.3.2) After receiving the PATH request, the egress edge node assigns a unique Flow-ID in the deterministic network to the service flow and adds it to the Objects field of the reserved RESV packet. The Flow-ID is 16 bits long and returns the reserved RESV information to the ingress edge node.

[0048] 2.3.3) After receiving the RESV information, the ingress edge node completes resource reservation, retains the Flow-ID as the unique flow identifier of the service flow, and sets the location identifier LOC, function identifier FUNCT, queue identifier QID, and sequence identifier SEN according to different service flow requirements:

[0049] If the service flow requires service protection, the location identifier LOC and function identifier FUNCT are set, with lengths of 64 bits and 16 bits respectively;

[0050] If there are data packets waiting to be forwarded in the node, the queue identifier QID is set. Its length is variable. If there is no special identifier, the length is 10 bits.

[0051] If the service flow has a low tolerance for disorder, that is, real-time control service flows such as industrial control instructions and autonomous driving instructions, or timing-dependent service flows such as time-sensitive networks (TSN), a sequence identifier (SEN) is set, which is 16 bits long.

[0052] Step 3: Encapsulate the above identifier into a deterministic specific segment identifier DSID and perform SRv6 encapsulation.

[0053] 3.1) The ingress edge node assembles the various identifiers obtained in step 2 into a deterministic specific segment identifier DSID:

[0054] Reference Figure 3 , this step is implemented as follows:

[0055] The location identifier LOC is encapsulated in the header of the deterministic specific segment identifier DSID and is used to identify the intermediate node for duplication, elimination and sorting of service flows;

[0056] The function identifier FUNCT is encapsulated after the LOC identifier position and is used for business flow duplication, elimination and sorting. If this function is not enabled, all bits need to be set to 0;

[0057] The flow identifier Flow-ID is encapsulated after the FUNCT identifier and is used to identify each different flow in the Detnet network. That is, it is transmitted by the egress edge node of the DetNet service to its upstream ingress edge node in the network and encapsulated by the ingress edge node as part of the deterministic specific segment identifier DSID. It is then forwarded to the downstream intermediate node and egress edge node along with the SRv6 data packet. When the intermediate node and the egress edge node receive the SRv6 data packet, the receiver identifies the DetNet flow associated with the packet based on the Flow-ID;

[0058] The sequence identifier SEN is encapsulated after the Flow-ID and is used to identify the sequence position of the data packet in the service flow to ensure the integrity and sequence of the service flow. If this function is not enabled, all bits need to be set to 0;

[0059] The queue identifier QID is encapsulated at the end of the deterministic specific segment identifier DSID and is used to identify the queuing and forwarding priority of the service flow within the network node, ensuring that high-priority data flows are processed first and preventing low-priority traffic from blocking the forwarding of high-priority service flows.

[0060] If the bit length of the data packet is not a multiple of 16, the total length of the data packet is made a multiple of 16 by padding with 0 bits. After padding, the deterministic specific segment identifier DSID is obtained;

[0061] 3.2) Encapsulate the original data packet into an SRv6 data packet based on the tunnel path obtained in step 2 and the deterministic specific segment identifier DSID assembled in 3.1):

[0062] The ingress edge node adds a segment extension header (SRH) to the original data packet, preparing for the next step of encapsulating the deterministic specific segment identifier (DSID).

[0063] The ingress edge node encapsulates the deterministic specific segment identifier DSID at the end of the SRH to ensure the determinism, reliability and service quality of the service flow data, and does not participate in the forwarding of the intermediate nodes. The ingress edge node follows the tunnel path;

[0064] Based on the tunnel path obtained in step 2, the ingress edge node encapsulates the node addresses contained in the path segment identifier WSID. The path segment identifier WSID is then encapsulated before the deterministic specific segment identifier DSID. The path segment identifier WSID indicates the forwarding node that the data flow passes through and is used to ensure that the traffic is forwarded along the expected path.

[0065] The ingress edge node encapsulates the IPv6 packet header according to the first address of the path segment identifier WSID, and then fills the data link layer part and the physical layer part of the data packet to make it a complete data packet that can be transmitted on the physical link, such as Figure 4 shown.

[0066] The final encapsulated data packet includes an SRH data header and an IPv6 data header in addition to the original data packet.

[0067] Step 4: Tunnel path transmission.

[0068] 4.1) After data packet encapsulation is completed, different processing and transmission methods are performed according to the role of the satellite in the service flow transmission:

[0069] 4.1.1) Satellite as the processing and transmission of the entry edge node:

[0070] Set the Segment Left value in the Segment Extended Header (SRH) to the number of WSIDs, and use the first WSID as the destination address of the packet.

[0071] Determine whether the function identifier FUNCT and sequence identifier SEN fields are enabled:

[0072] If so, the business flow needs to be copied, eliminated, and sorted;

[0073] Otherwise, no business flow duplication, elimination, or sorting is performed;

[0074] After the judgment is completed, the data packet is forwarded to the next node according to the destination address;

[0075] 4.1.2) Processing and transmission with satellite as the intermediate node:

[0076] The Segment Left value is reduced by one, and the current path segment identifier WSID is used as the forwarding destination address. Then the path segment identifier WSID pointer is updated to point to the next path segment identifier WSID;

[0077] Determine whether the satellite is an intermediate node specified by the location identifier LOC:

[0078] If so, the business flow needs to be copied, eliminated and sorted according to the location identifier LOC requirements;

[0079] Otherwise, no business flow duplication, elimination, or sorting operations are performed;

[0080] After the judgment is completed, the data packet is forwarded to the next node according to the destination address;

[0081] 4.1.3) Satellite as the processing and transmission of the export edge node:

[0082] Determine whether the function identifier FUCNT and sequence identifier SEN fields are enabled:

[0083] If so, it is necessary to eliminate and sort the business flow data packets;

[0084] Otherwise, no elimination and sorting operations are performed on the service flow data packets;

[0085] After the judgment is completed, the SRH encapsulation of the data packet is removed, and it is restored to the original data packet, and finally forwarded to the terminal destination device according to the destination address of the original data packet.

[0086] 4.2) Determine whether there is a satellite switch during the transmission process:

[0087] If a satellite switch occurs during data transmission, execute step 5;

[0088] Otherwise, go to step 7;

[0089] Step 5: Switch satellites during data transmission to perform transmission migration.

[0090] Reference Figure 5 , the implementation of this step includes the following:

[0091] 5.1) Satellite switching preparation:

[0092] When a satellite S is about to switch, it uses the predicted topology technology to predict the network topology at the switching time by combining the satellite orbit data, and calculates the best new satellite N to switch to based on its own service flow constraints. It then sends a message to the new satellite N that it is ready to receive service flows, and then sends the current service flow information to the new satellite N, including the deterministic specific segment identifier DSID of the current service, the path segment identifier WSID, and the service flow requirements, such as Figure 5 As shown in a;

[0093] 5.2) Satellite switching phase:

[0094] The new satellite N receives the service flow information sent by the original satellite S and returns the received service flow information response to it. Then, it performs different operations according to the role of the original satellite S in the service flow transmission:

[0095] If the original satellite S is an entry edge node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then determines whether the current path meets the service flow requirements:

[0096] If yes, resend the PATH message to request resource reservation:

[0097] Otherwise, the ingress edge node needs to recalculate the tunnel path and apply for resource reservation;

[0098] If the original satellite S is an intermediate node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then sends an intermediate node handover message to the ingress edge node. After receiving the intermediate node handover message, the ingress edge node updates the resource reservation information based on the post-handover network topology and link information obtained from the predicted topology.

[0099] If the original satellite S is an egress edge node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then sends an egress edge node switching message to the ingress edge node. After receiving the egress edge node switching message, the ingress edge node updates the resource reservation information based on the post-switching network topology and link resources learned from the predicted topology to meet the service flow requirements, such as Figure 5 As shown in b;

[0100] 5.3) Satellite Migration and Transition:

[0101] After resource reservation is completed, the ingress edge node performs unified scheduling and bandwidth allocation of service flows based on the flow identifier Flow-ID in the deterministic specific segment identifier DSID, and adopts traffic shaping and priority scheduling mechanisms to ensure that the delay and packet loss of the service flow are controllable; then the function identifier FUNCT, location identifier LOC and sequence identifier SEN fields are set, the service flow is copied, and the service flows before and after the copy are forwarded to the original satellite S and the new satellite N respectively, so that the two can transmit the service flow at the same time, such as Figure 5 As shown in c;

[0102] 5.4) Satellite Tunnel Migration:

[0103] The new satellite N sends an ACK message to the original satellite S. After the original satellite S receives the ACK message, the transmission migration is completed. After waiting for 2-3 round-trip delays (RTT), the service flow is no longer forwarded to the original satellite S. The new satellite N is responsible for the service flow transmission. Figure 5 As shown in d.

[0104] 5.5) Determine if there is a queue on the handover satellite:

[0105] If there is a queue waiting to be forwarded on the switching satellite, go to step 6;

[0106] Otherwise, go to step 7.

[0107] Step 6: Switch the queue buffer migration of the data packets queued on the satellite.

[0108] When the real-time bandwidth utilization of satellite S is lower than the committed access rate (CAR), satellite S can achieve zero-queue forwarding. However, when burst traffic causes the bandwidth utilization to significantly exceed the CAR, satellite S will have packets queued for forwarding. In this case, after tunnel migration is completed, satellite S needs to perform queue cache migration. The implementation includes the following:

[0109] 6.1) The original satellite S determines whether the data packets waiting to be forwarded belong to multiple different service flows based on the flow identifier Flow-ID:

[0110] If so, the intelligent packet caching strategy is selected to cache the data packet. That is, the original satellite S uses a 10-bit queue identifier QID to identify the data packet according to the priority of the data packet waiting to be forwarded. Specifically, the first 4 bits are used to identify the queue forwarding priority, and the last 6 bits are used to identify the queue order of the data packet. Subsequently, the data packet is cached preferentially according to the queue identifier QID to reduce the waiting time and packet loss probability of high-priority service flows.

[0111] Otherwise, the ordinary packet caching strategy is selected to cache the data packets, that is, the original satellite S caches the data packets waiting to be forwarded in the queue order, and the priority bits of the queue identifier QID are uniformly set to 0 to indicate that the priority bits are not enabled.

[0112] 6.2) When using a caching strategy, the original satellite S sets a cache limit and a timer. When the cached packets reach the cache limit or the timer is reset, the original satellite S immediately sends the cached packets to the new satellite N. When all queued packets are cached, the packets cached by the original satellite S are sent to the new satellite N.

[0113] 6.3) After the new satellite N receives the data packet sent by the original satellite S, it establishes a two-dimensional queue processing mechanism based on the flow identifier Flow-ID and queue identifier QID fields carried in the data packet:

[0114] 6.3.1) Layer 1 divides each flow ID into independent virtual transmission channels to isolate different service flows;

[0115] 6.3.2) Layer 2 allocates queue resources within each independent virtual transmission channel defined by a Flow-ID based on the priority bits of the queue identifier (QID). This means that high-priority packets are placed in the VIP queue pool for priority processing, followed by low-priority packets in the best-effort (BE) queue pool.

[0116] 6.4) The new satellite N sends a Flow-ID synchronization confirmation frame to the original satellite S. The frame contains the last successfully received queue identifier QID sequence value. After the original satellite S receives the synchronization confirmation frame, the queue cache migration is successful and the cached data packets are cleared.

[0117] Step 7: Transmission completion and resource release.

[0118] After a service flow completes transmission according to the above steps, the ingress edge node, based on the transmission completion flag sent by the terminal device, clears the corresponding service flow information on the user network interface (UNI), including the tunnel path, service flow information, and deterministic specific segment identifier (DSID), and stops receiving user data for that flow. Furthermore, if a UNI interface remains unused for a set period of time, the node automatically disconnects the connection and clears data, ensuring timely recovery and utilization of network resources.

[0119] Example 2: Switching when a satellite serves multiple different service flows simultaneously

[0120] This example is for the original satellite S serving multiple different service flows simultaneously. Different service flows may be served by different types of transmission nodes. For example, the original satellite S is the ingress edge node of time-sensitive service flow A and also the intermediate node of normal service flow B. The switching operation is as follows:

[0121] The original satellite S detects that a handover is imminent through the predicted topology mechanism. It then uses the predicted topology technology, combined with satellite orbit data, to predict the network topology at the time of handover. It then calculates the optimal new satellite N to switch to based on its own traffic constraints. It then notifies the new satellite N and sends it a message indicating it is ready to receive traffic.

[0122] After receiving the response from the new satellite, the original satellite S sends the service flow information of streams A and B to the new satellite N, including the deterministic specific segment identifiers DSID and path segment identifiers WSID of streams A and B, as well as the service flow requirements;

[0123] The new satellite N receives and stores the traffic flow information, then returns a message indicating that the service flow has been received to the original satellite S and begins resource reservation:

[0124] As the ingress edge node of flow A, the new satellite N sends a RESV resource reservation message of flow A to the egress edge node of flow A and determines whether the current path meets the service flow requirements:

[0125] If yes, resend the PATH message to request resource reservation:

[0126] Otherwise, the ingress edge node needs to recalculate the tunnel path and apply for resource reservation;

[0127] As the intermediate node of flow B, the new satellite N sends an intermediate node switching message to the ingress edge node of flow B to request it to re-reserve resources for flow B;

[0128] After resource reservation is completed, the original satellite S finds that some data packets of flows A and B are waiting to be forwarded in the queue, and uses intelligent caching to cache the data packets of flows A and B, and then immediately sends them to the new satellite N;

[0129] After receiving the data, the new satellite N uses a two-dimensional queue processing mechanism to first divide flows A and B into different virtual transmission channels based on the flow identifier Flow-ID. Since flow A is a high-priority time-sensitive service flow, the high-priority data packets of flow A are placed in the VIP queue pool for priority processing based on the queue identifier QID. The low-priority data packets of flows A and B are then placed in the best-effort BE queue pool for processing. Finally, the BE queue pool reconstructs the original queue forwarding order based on the queue identifier QID sequence.

[0130] The above descriptions are merely two specific examples of the present invention and do not constitute any limitation to the present invention. Obviously, after understanding the content and principles of the present invention, professionals in this field may make various modifications and changes in form and details without departing from the principles and structure of the present invention. However, these modifications and changes based on the ideas of the present invention are still within the scope of protection of the claims of the present invention.

[0131] It should be noted that the step numbers in the specification and claims of the present invention are only for the purpose of clearly describing the embodiments of the present invention and facilitating understanding, and the order of the step numbers is not limited.

Claims

1. A satellite Internet deterministic routing data plane migration method based on predicted topology, characterized in that: include: (1) The service flow terminal device sends a request to the satellite entry edge node to access the satellite Internet deterministic network. The entry edge node determines whether it needs to calculate the transmission path required by the service flow based on the access request: If calculation is required, execute step (2); If no calculation is required, proceed to step (3); (2) Calculate the tunnel path based on the topology and service flow requirements of the satellite Internet deterministic network, reserve resources based on the tunnel path, obtain the flow identifier Flow-ID, and select its location identifier LOC, function identifier FUNCT, queue identifier QID, and sequence identifier SEN for identification according to different service flows; (3) The ingress edge node uses the flow identifier Flow-ID, location identifier LOC, function identifier FUNCT, queue identifier QID, and sequence identifier SEN to assemble a deterministic specific segment identifier DSID, and encapsulates the original data packet of the service flow into an IPv6-based segment routing SRv6 data packet based on the tunnel path and the deterministic specific segment identifier DSID; (4) The service flow is transmitted in the satellite Internet along the tunnel path encapsulated by the SRv6 data packet. When the satellite is about to switch during the transmission process, the service flow is migrated through the tunnel. If there are queues waiting to be forwarded on the switched satellite, these packets are queued and cached before being migrated. (5) After the service flow transmission is completed, the ingress edge node clears the relevant data of the service flow.

2. The method according to claim 1, characterized in that In step (1), the ingress edge node determines whether it is necessary to calculate the transmission path required by the service flow based on the access request, and its implementation includes: (1a) The ingress edge node receives the service flow access request from the terminal device and extracts key requirements from it, which include: Deterministic requirements, such as latency limits, jitter tolerance, and packet loss rate thresholds; Resource requirements, i.e. bandwidth, priority; Reliability requirements, i.e. redundant paths; (1b) Based on the satellite orbit prediction model and inter-satellite link quality obtained from the predicted topology, the network topology dynamic information is obtained in real time, and the remaining bandwidth, forwarding delay and other remaining resources of the current tunnel path are queried; (1c) Compare the remaining resources with the key requirements extracted in (1a) to determine whether to trigger tunnel path calculation: If the remaining resources of the current tunnel path cannot meet the service flow requirements, the tunnel path calculation is triggered; If the service flow requirements are met, tunnel path calculation is not triggered.

3. The method according to claim 1, characterized in that In step (2), the tunnel path is calculated based on the topology and service flow requirements of the satellite Internet deterministic network, and its implementation includes: (2a) The ingress edge node converts the QoS requirements of different service flows into constraints that must be met when calculating the optimal path, including: Delay constraint: end-to-end delay ≤ service flow delay upper limit; Bandwidth constraint: The remaining bandwidth of all links in the path must be ≥ the bandwidth required by the service flow; The entry edge node selects an alternative path that meets the requirements based on the constraints and waits for further selection. (2b) The entry edge node calculates the path weight G of the alternative path that meets the constraints in (3a) according to the path weight calculation formula: Among them, α is the weight coefficient dynamically adjusted according to the service flow propagation delay t, d is the geometric distance between satellites, c is the speed of light, M is the tunnel path survival time estimated by the prediction topology mechanism, β is the weight coefficient dynamically adjusted according to the tunnel path survival time M of the service flow, and α and β satisfy the constraint condition α + β = 1 (α>0, β>0); (2c) The ingress edge node selects the path with the lowest weight value as the tunnel path for the service flow based on the path weight G.

4. The method according to claim 1, wherein In step (2), the tunnel path reserves resources and obtains the flow identifier Flow-ID, which is implemented by: (2d) Based on the tunnel path of the service flow, the ingress edge node uses the resource reservation protocol RSVP-TE to send a path request to the egress edge node to reserve the path resources for the flow and obtain the Flow-ID; (2e) After receiving the PATH request, the egress edge node assigns a unique Flow-ID in the deterministic network to the service flow and adds it to the Objects field of the reserved RESV packet. It then returns the reserved RESV information to the ingress edge node. (2f) After receiving the RESV information, the ingress edge node completes resource reservation and retains the Flow-ID as the unique flow identifier of the service flow.

5. The method according to claim 1, wherein The deterministic specific segment identifier DSID assembled by the ingress edge node in step (3) contains the following types of identifier structures: The location identifier LOC is 64 bits long and is used to identify the intermediate node for duplication, elimination, and sorting of service flows, and is encapsulated in the header of the deterministic specific segment identifier DSID; The function identifier FUNCT is 16 bits long and is encapsulated after the LOC identifier position. It is used for business flow duplication, elimination and sorting. If this function is not enabled, all bits need to be set to 0; The flow identifier Flow-ID is 16 bits long and is encapsulated after the FUNCT identifier to identify each different flow in the Detnet network. That is, it is transmitted by the egress edge node of the DetNet service to its upstream ingress edge node in the network and encapsulated by the ingress edge node as part of the deterministic specific segment identifier DSID. It is then forwarded to the downstream intermediate node and egress edge node following the SRv6 data packet. When the intermediate node and egress edge node receive the SRv6 data packet, the receiver identifies the DetNet flow associated with the packet based on the Flow-ID. The sequence identifier SEN is 16 bits long and is encapsulated after the Flow-ID. It is used to identify the sequence position of the data packet in the service flow to ensure the integrity and sequence of the service flow. If this function is not enabled, all bits must be set to 0; The queue identifier QID has a variable length. If not specially identified, its length is 10 bits. It is encapsulated at the end of the deterministic specific segment identifier DSID and is used to identify the queuing and forwarding priority of business flows within the network node, ensuring that high-priority data flows are given priority processing and preventing low-priority traffic from blocking the forwarding of high-priority business flows.

6. The method according to claim 1, characterized in that In step (3), the ingress edge node encapsulates the original data packet of the service flow into an IPv6-based segment routing SRv6 data packet according to the tunnel path and the deterministic specific segment identifier DSID, and its implementation includes: (3a) The ingress edge node adds a segment extension header (SRH) to the original data packet, preparing for the next step of encapsulating the deterministic specific segment identifier (DSID); (3b) The deterministic specific segment identifier (DSID) is encapsulated at the end of the SRH to ensure the determinism, reliability, and service quality of the service flow data, and does not participate in the forwarding of intermediate nodes; (3c) The ingress edge node encapsulates the node address contained in the tunnel path into the path segment identifier WSID, and then encapsulates the path segment identifier WSID before the deterministic specific segment identifier DSID. The path segment identifier WSID indicates the forwarding node that the data flow passes through, and is used to ensure that the traffic is forwarded along the expected path; (3d) The ingress edge node encapsulates the IPv6 packet header according to the first address of the WSID, and then fills the data link layer part and the physical layer part of the data packet to make it a complete data packet that can be transmitted on the physical link.

7. The method according to claim 1, characterized in that In step (4), the service flow is transmitted in the satellite Internet according to the tunnel path encapsulated by the SRv6 data packet. Different transmissions are performed according to the role of the satellite in the service flow transmission: If the satellite is an ingress edge node, the Segment Left value in the SRH is set to the number of WSIDs. The first WSID is then used as the destination address of the packet. The FUNCT and SEN fields are then checked to see if they are enabled. If so, service flow replication, elimination, and sorting are performed. Otherwise, service flow replication, elimination, and sorting are not performed. Finally, the packet is forwarded to the intermediate node according to the destination address. If the satellite is an intermediate node, the Segment Left value is reduced by one, and the current path segment identifier WSID is used as the forwarding destination address. The WSID pointer is then updated to point to the next path segment identifier WSID. Then, it is determined whether the satellite is an intermediate node specified by the LOC. If so, the business flow replication, elimination, and sorting operations are performed according to the LOC requirements. Otherwise, the business flow replication, elimination, and sorting operations are not performed. Finally, the data packet is forwarded to the next node according to the destination address. If the satellite is an egress edge node, determine whether the FUCNT and SEN fields are enabled. If so, eliminate and sort the service flow packets. Otherwise, the service flow data packet is not eliminated and sorted; the SRH encapsulation of the data packet is then removed, and the data packet is restored to the original data packet, and finally forwarded to the terminal destination device according to the destination address of the original data packet.

8. The method according to claim 1, characterized in that The migration of the service flow through the tunnel described in step (4) includes the following: (4a) When a satellite S is about to be switched, it uses the predicted topology technology to predict the network topology at the switching time by combining the satellite orbit data, and calculates the best new satellite N to switch to based on its own traffic flow constraints. It then sends a message to the new satellite N to prepare it to receive traffic flow information. (4b) The original satellite S sends the current service flow information to the new satellite N, including the deterministic specific segment identifier DSID of the current service, the path segment identifier WSID, and the service flow requirements; (4c) The new satellite N receives the service flow information sent by the original satellite S and returns a response to the received service flow information. Then, it performs different operations based on the role of the original satellite S in the service flow transmission: If the original satellite S is an ingress edge node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then determines whether the current path meets the service flow requirements. If so, it resends the PATH message to request resource reservation. Otherwise, the ingress edge node needs to recalculate the tunnel path and request resource reservation. If the original satellite S is an intermediate node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then sends an intermediate node handover message to the ingress edge node. After receiving the intermediate node handover message, the ingress edge node updates the resource reservation information based on the post-handover network topology and link information obtained from the predicted topology. If the original satellite S is an egress edge node, the new satellite N first stores the deterministic specific segment identifier DSID, path segment identifier WSID, and service flow requirements, and then sends an egress edge node switching message to the ingress edge node. After receiving the egress edge node switching message, the ingress edge node updates the resource reservation information based on the post-switching network topology and link resources learned from the predicted topology to meet the service flow requirements. (4d) After resource reservation is completed, the ingress edge node performs unified scheduling and bandwidth allocation of service flows based on the flow identifier Flow-ID in the deterministic specific segment identifier DSID. It then adopts traffic shaping and priority scheduling mechanisms to ensure that the latency and packet loss of the service flows are controllable. Finally, the ingress edge node sets the FUNCT and SEN fields, copies the service flow, and forwards the service flows before and after the copy to the original satellite S and the new satellite N respectively, so that both satellites can transmit the service flows simultaneously. (4e) The new satellite N sends an ACK message to the original satellite S. After the original satellite S receives the ACK message, the node switch is completed. After waiting for 2-3 round-trip delays (RTT), the service flow is no longer forwarded to the original satellite S. Only the new satellite N is responsible for the service flow transmission.

9. The method according to claim 1, characterized in that In step (4), there are queues on the switched satellite waiting to be forwarded, and these data packets are cached in the queue before being migrated, including the following: (4f) The original satellite S determines whether the data packets waiting to be forwarded belong to multiple different service flows based on the flow identifier Flow-ID: If yes, select the intelligent group caching strategy to cache the data packets: Otherwise, select the normal packet caching strategy to cache the data packet: (4g) After the queue buffering is completed, the data packets buffered in the original satellite S are sent to the new satellite N; (4h) After the new satellite N receives the data packet sent by the original satellite S, it establishes a two-dimensional queue processing mechanism based on the flow identifier Flow-ID and queue identifier QID fields carried in the data packet: (4i) The new satellite N sends a Flow-ID synchronization confirmation frame to the original satellite S. The frame contains the last successfully received QID sequence value. After the original satellite S receives the synchronization confirmation frame, the queue cache migration is successful and the cached data packets are cleared. The intelligent packet caching strategy is selected to cache data packets. The original satellite S uses a 10-bit queue identifier QID to identify the data packet according to the priority of the data packet waiting to be forwarded. That is, the first 4 bits identify the queue forwarding priority, and the last 6 bits identify the data packet queue forwarding order. Subsequently, the data packet is cached preferentially according to the QID to reduce the waiting time and packet loss probability of high-priority service flows. The ordinary packet caching strategy is selected to cache the data packets, and the original satellite S caches the data packets waiting to be forwarded in the queue order, and the priority bits of the QID are uniformly set to 0 to indicate that the priority bits are not enabled.

10. The method according to claim 9, characterized in that In step (4h), a two-dimensional queue processing mechanism is established, which is implemented as follows (4h1) The first layer divides each Flow-ID into independent virtual transmission channels to isolate different service flows; (4h2) The second layer allocates queue resources within each independent virtual transmission channel divided by Flow-ID based on the priority bits of the queue identifier QID: Put high-priority data packets into the VIP queue pool for priority processing; Then put the low priority data packets into the best effort BE queue pool for processing; Finally, the original queue forwarding order is reconstructed according to the queue ID QID sequence.

Images