A message path tracking method of a satellite network

Abstract

The application discloses a message path tracking method of a satellite network, which realizes the message path tracking function of a satellite dynamic network through a flow label in an IPv6 message header. The flow label of the message is mapped to give a unique flow identification to each flow, and is mapped to the flow label of the IPv6 message header to be written into the flow telemetry header. The flow label is used to identify the flow on each satellite node, metadata collection is carried out, then the telemetry data is sent to the flow telemetry collection module. The flow telemetry collection module analyzes and restores the forwarding path of all messages in the service flow according to the time stamp, message sequence number and node identification based on the received telemetry data, and then constructs the service flow path time-varying graph based on the time-varying graph theory. Finally, the constellation topology table based on ephemeris is introduced as the space-time reference for the satellite network link chain construction, the traffic scheduling strategy table and the sunrise time table are introduced as the reference, and the message path switching reason is inversely calculated in combination with the service flow path time-varying graph.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and in particular relates to a message path tracking method for satellite networks. Background Technology

[0002] In satellite networks, the highly dynamic satellite topology and frequent link switching cause network traffic paths to constantly change. Therefore, tracking the packet paths of service flows and determining the reasons for path switching are crucial for understanding the network's operational status. This invention utilizes a flow-based telemetry protocol to collect data from satellite network forwarding nodes by embedding metadata into service data packets. The flow-based telemetry acquisition module then tracks and reconstructs all packet paths of the service flow and determines the reasons for path switching.

[0003] The applicant, Nanjing University, disclosed a method for compressing flow detection data and identifying sampled messages in its patent application document "A Method for Flow Detection in Space Networks" (application date: April 7, 2025, application number: 202510424440.8, publication number: CN119945944B). It uses a sampling template to instruct each node to collect flow detection metadata. However, it does not solve the problem of analyzing the metadata collected in highly dynamic satellite networks and tracking and reconstructing the actual transmission path of the service flow, nor does it realize the determination of the reason for message path switching. This invention solves the problem of the difficulty in tracking message paths caused by the dynamism of space networks, and realizes message path tracking and reconstruction and the determination of the reason for message path switching in dynamic satellite networks. Summary of the Invention

[0004] Purpose of the invention: This invention discloses a packet path tracking method for satellite networks. It utilizes the Flow Label in the IPv6 packet header to identify the service flow of satellite nodes, enabling automated flow-based telemetry triggering and data acquisition. The telemetry data is analyzed to track and reconstruct the packet forwarding path. A constellation topology table based on ephemeris is introduced as a spatiotemporal reference for satellite network link establishment. A traffic scheduling strategy table and a diurnal outage time table are introduced as references to deduce the reasons for packet path switching.

[0005] The method includes the following steps:

[0006] S1: At the network entry node, each service flow is assigned a flow identifier by mapping the flow label of the packet to the Flow Label field of the IPv6 packet header and written into the flow telemetry header; metadata based on the flow label is collected on each dynamic satellite node along the path of each service flow and the telemetry data is sent to the flow telemetry collection module.

[0007] S2: The telemetry acquisition module analyzes the message forwarding path based on the received telemetry dataset according to the timestamp, message sequence number and node identifier, and constructs the forwarding path of all messages in the service flow;

[0008] S3: Based on the forwarding paths of all packets, construct a time-varying graph of the business flow path using time-varying graph theory;

[0009] S4: Introduce a constellation topology table based on ephemeris as the spatiotemporal reference for satellite network link establishment, introduce a traffic scheduling strategy table and a diurnal outage time table as references, and combine them with the time-varying diagram of service flow paths to deduce the reasons for message path switching.

[0010] Furthermore, the specific process of step S1 is as follows:

[0011] S1.1 When a service flow enters the network ingress node, it is assigned a unique flow identifier through flow label mapping and mapped to the Flow Label field in the IPv6 packet header;

[0012] S1.2 Map the flow identifier to the flow identifier field of the flow telemetry head, and assign a message sequence number starting from 1 to all messages and write it into the flow telemetry head;

[0013] S1.3 At each dynamic satellite node along each service flow path, the service flow is identified and metadata is collected through flow tags. The metadata includes, but is not limited to, the current satellite node identifier, timestamp, and message sequence number. The timestamp refers to the time when each message of the service flow enters the current satellite node, marked as the in timetamp of the message, and the time when the message leaves the current satellite node, marked as the out timetamp of the message.

[0014] After the satellite node metadata collection is completed in S1.4, the telemetry headers and metadata collected for each message are combined into telemetry data packets for each message and sent to the telemetry acquisition module.

[0015] Furthermore, the specific process of step S2 is as follows:

[0016] After receiving the telemetry data packets sent by each satellite node, the S2.1 flow-following telemetry acquisition module distinguishes service flows by flow identifier and sorts all messages of each service flow by message sequence number;

[0017] S2.2 The telemetry acquisition module determines the time sequence of satellite nodes through which a message passes based on the ingress and egress timestamps in the metadata, and reconstructs the forwarding path of the message in the network;

[0018] S2.3 Tracks and analyzes the path information of all packets in the flow to construct the forwarding path of all packets in the service flow in the network.

[0019] Furthermore, the specific process of step S3 is as follows:

[0020] Based on the network entry timestamp and network exit timestamp of the service flow, the service flow The lifecycle is discretized by dividing the time axis into several time intervals. If within a time interval... If the path sequence of all messages remains consistent, it is defined as a path state. The network entry timestamp refers to the entry timestamp of the first packet in the service flow at the network entry node, and the network exit timestamp refers to the exit timestamp of the last packet in the service flow that arrives at the destination address at the end node.

[0021] All satellite network path states are sequentially linked and compared to identify the link connections between adjacent path states. Based on this, the service flow... Its lifecycle is mapped as an ordered sequence of path states. :

[0022] ,

[0023] in, Indicates business flow The total number of path states experienced during the lifecycle; Indicates the first The time window of a path, i.e., the duration of the path. Representing the path status respectively The start and end times; Indicates within the time window Internally, it carries the business flow. An ordered list of satellite nodes, in which This represents the number of hops in the path under this path state. Represents the first on the path One satellite node;

[0024] based on By setting the path set in all path states { }、{ }、 Perform a union operation to obtain the business flow. By combining the complete set of satellite nodes and network topology domains covered throughout the entire lifecycle with the timestamp information in the metadata, a time-varying graph of the business flow path within the business flow lifecycle is constructed.

[0025] Furthermore, the specific process of step S4 is as follows:

[0026] S4.1 The reasons for message path switching are divided into two categories: deterministic switching and non-deterministic switching. Deterministic switching refers to switching caused by predictable factors, including planned normal link switching, traffic scheduling strategies, and solar outages, during transmission. The reason for switching can be determined immediately through analysis. Non-deterministic switching refers to switching caused by various factors, including link interruptions, path performance degradation, instantaneous load fluctuations, short-term link quality jitter, and control plane decision delays, as well as other unknown factors, during transmission. The reason for switching cannot be determined immediately and requires further confirmation through subsequent statistical analysis and long-term observation. The determination of the reason for non-deterministic switching is not within the scope of this invention.

[0027] S4.2 Obtain the constellation topology table based on ephemeris, analyze the inter-satellite link connectivity before and after path switching, and establish a dynamic link establishment matrix between satellite nodes;

[0028] S4.3 Obtain the traffic scheduling policy table and daily delay schedule for reference to analyze whether the packet path switching is caused by the traffic scheduling policy or daily delay.

[0029] S4.4 Combine the time-varying diagram of the business flow path, the dynamic link establishment matrix, the traffic scheduling strategy table and the daily time table to analyze and determine the key nodes and reasons for path switching during message transmission;

[0030] Beneficial effects:

[0031] 1. This invention provides a packet path tracing method for satellite networks, which uses the flow label in the IPv6 packet header to complete automated flow-based telemetry judgment, is not constrained by dynamic topology, and achieves more efficient and loosely coupled node deployment and processing.

[0032] 2. This invention reconstructs the forwarding path of a message in a satellite network based on the timestamp, message sequence number, and node identifier fields, with low resource overhead and the ability to detect changes in the satellite network topology in real time.

[0033] 3. The path tracing method proposed in this invention realizes the restoration of the time-varying path graph within the lifecycle of the business flow, providing effective technical support for comprehensive monitoring of link connectivity.

[0034] 4. This invention introduces a constellation topology table based on ephemeris as a spatiotemporal reference for satellite network link establishment, and introduces a traffic scheduling strategy table and a solar outage time table as references. It proposes a method for judging the cause of service flow packet path switching in satellite networks. This method can explain about 60%–85% of path switching behavior, providing an important reference for subsequent research by relevant technical personnel. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating the overall process of satellite message path tracing.

[0036] Figure 2 For the format of the flow-following telemetry head

[0037] Figure 3 Configure the flow label mapping rules and flow identifiers;

[0038] Figure 4 Metadata format;

[0039] Figure 5 For a segment in the business flow;

[0040] Figure 6 Examples of specific implementation scenarios for the flow tag-based message path tracing method

[0041] Figure 7 To reconstruct the forwarding path of a message based on information such as timestamp, message sequence number, and node identifier;

[0042] Figure 8 To reconstruct the time-varying graph of the business flow path; Detailed Implementation

[0043] The invention will be further described below with reference to the accompanying drawings and specific application scenarios.

[0044] This invention provides a message path tracing method for satellite networks, the overall process of which is shown in the attached figure. Figure 1 As shown, the method includes the following steps:

[0045] S1: At the network entry node, each service flow is assigned a flow identifier by mapping the flow label of the packet to the Flow Label field of the IPv6 packet header and written into the flow telemetry header; metadata based on the flow label is collected on each dynamic satellite node along the path of each service flow and the telemetry data is sent to the flow telemetry collection module.

[0046] S2: The telemetry acquisition module analyzes the message forwarding path based on the received telemetry dataset according to the timestamp, message sequence number and node identifier, and constructs the forwarding path of all messages in the service flow;

[0047] S3: Based on the forwarding paths of all packets, construct a time-varying graph of the business flow path using time-varying graph theory;

[0048] S4: Introduce a constellation topology table based on ephemeris as the spatiotemporal reference for satellite network link establishment, introduce a traffic scheduling strategy table and a diurnal outage time table as references, and combine them with the time-varying diagram of service flow paths to deduce the reasons for message path switching.

[0049] The specific process of step S1 is as follows:

[0050] S1.1 When a service flow enters the network ingress node, it is assigned a unique flow identifier through flow label mapping and mapped to the Flow Label field in the IPv6 packet header;

[0051] S1.2 Map the flow identifier to the flow identifier field of the flow-following telemetry header, and assign a message sequence number starting from 1 to all messages, writing it into the flow-following telemetry header; the format of the flow-following telemetry header is as follows. Figure 2 As shown;

[0052] S1.3 At each dynamic satellite node along each service flow path, the service flow is identified and metadata is collected using flow tags. The metadata includes, but is not limited to, the current satellite node identifier, timestamp, and message sequence number, in the format shown in the appendix. Figure 3 As shown; the timestamp refers to the time when each message in the service flow enters the current satellite node, marked as the message's entry timestamp, and the time when the message leaves the current satellite node, marked as the message's exit timestamp;

[0053] After the satellite node metadata collection is completed in S1.4, the telemetry headers and metadata collected for each message are combined into telemetry data packets for each message and sent to the telemetry acquisition module.

[0054] Furthermore, the specific process of step S2 is as follows:

[0055] After receiving the telemetry data packets sent by each satellite node, the S2.1 flow-following telemetry acquisition module distinguishes service flows by flow identifier and sorts all messages of each service flow by message sequence number;

[0056] S2.2 The telemetry acquisition module determines the time sequence of satellite nodes through which a message passes based on the ingress and egress timestamps in the metadata, and reconstructs the forwarding path of the message in the network;

[0057] S2.3 Tracks and analyzes the path information of all packets in the flow to construct the forwarding path of all packets in the service flow in the network.

[0058] Furthermore, the specific process of step S3 is as follows:

[0059] Based on the network entry timestamp and network exit timestamp of the service flow, the service flow The lifecycle is discretized by dividing the time axis into several time intervals. If within a time interval... If the path sequence of all messages remains consistent, it is defined as a path state. The network entry timestamp refers to the entry timestamp of the first packet in the service flow at the network entry node, and the network exit timestamp refers to the exit timestamp of the last packet in the service flow that arrives at the destination address at the end node.

[0060] All satellite network path states are sequentially linked and compared to identify the link connections between adjacent path states. Based on this, the service flow... Its lifecycle is mapped as an ordered sequence of path states. :

[0061] ,

[0062] in, Indicates business flow The total number of path states experienced during the lifecycle; Indicates the first The time window of a path, i.e., the duration of the path. Representing the path status respectively The start and end times; Indicates within the time window Internally, it carries the business flow. An ordered list of satellite nodes, in which This represents the number of hops in the path under this path state. Represents the first on the path One satellite node;

[0063] based on By setting the path set in all path states { }、{ }、 Perform a union operation to obtain the business flow. By combining the complete set of satellite nodes and network topology covered throughout the entire lifecycle with the timestamp information in the metadata, a time-varying graph of the business flow path within the business flow lifecycle is constructed.

[0064] Furthermore, the specific process of step S4 is as follows:

[0065] S4.1 The reasons for message path switching are divided into two categories: deterministic switching and non-deterministic switching. Deterministic switching refers to switching caused by predictable factors, including planned normal link switching, traffic scheduling strategies, and solar outages, during transmission. The reason for switching can be determined immediately through analysis. Non-deterministic switching refers to switching caused by various factors, including link interruptions, path performance degradation, instantaneous load fluctuations, short-term link quality jitter, and control plane decision delays, as well as other unknown factors, during transmission. The reason for switching cannot be determined immediately and requires further confirmation through subsequent statistical analysis and long-term observation. The determination of the reason for non-deterministic switching is not within the scope of this invention.

[0066] S4.2 Obtain the constellation topology table based on ephemeris, analyze the inter-satellite link connectivity before and after path switching, and establish a dynamic link establishment matrix between satellite nodes;

[0067] S4.3 Obtain the traffic scheduling policy table and daily delay schedule for reference to analyze whether the packet path switching is caused by the traffic scheduling policy or daily delay.

[0068] S4.4 Combine the time-varying diagram of the business flow path, the dynamic link establishment matrix, the traffic scheduling strategy table and the daily time table to analyze and determine the key nodes and reasons for path switching during message transmission;

[0069] Furthermore, at the network ingress node, each service flow is assigned a flow identifier through flow label mapping, which is mapped to the Flow Label field of the IPv6 packet header and written into the flow telemetry header; metadata based on flow labels is collected on each dynamic satellite node along the path of each service flow, and the telemetry data is sent to the flow telemetry collection module.

[0070] As attached Figure 4 As shown, when a service flow enters the network, at the network ingress node, a globally unique flow identifier is first assigned to it via flow label mapping, serving as the service flow identifier. Subsequently, the value of this flow identifier is mapped to the Flow Label field of the IPv6 packet header and written into the following telemetry header. Next, local metadata is collected for the key performance indicators of the current satellite node. After collection, the following telemetry header and metadata are combined into a telemetry data packet and sent to the following telemetry collection module for subsequent aggregation and analysis of the actual forwarding path of the packets. Additionally, packets in the service flow are assigned sequence numbers starting from 1, and these sequence numbers are stored in the following telemetry header and sent upwards.

[0071] Each satellite node in the network can identify service flows by judging the value of the flow label. When a packet arrives at a satellite node, the satellite node compares the flow label field in the packet's IPv6 header to determine whether the packet requires flow-based telemetry. If so, the satellite node will initiate a metadata collection process, which includes, but is not limited to, node identifiers and ingress / egress timestamps. After completing the metadata collection, the satellite node will encapsulate the flow-based telemetry header and metadata into telemetry data and send it to the flow-based telemetry collection module for subsequent correlation analysis and path tracing.

[0072] Furthermore, the telemetry acquisition module analyzes the message forwarding path based on the received telemetry dataset according to the timestamp, message sequence number and node identifier, and constructs the forwarding path of all messages in the service flow;

[0073] For a single service flow, its flow tag value is unique. The message sequence number field counts messages in the flow starting from 1, thus the message sequence number can be used to determine the message to which the metadata belongs and the order of the messages within the flow. The flow-following telemetry acquisition module first receives telemetry data packets from various satellite nodes. Due to multipath and latency jitter in satellite network transmission, the telemetry data packets arriving at the flow-following telemetry acquisition module are often out of order. Therefore, the system first isolates the data of different service flows based on the flow identifier in the flow-following telemetry header. For a specific service flow F, the metadata is first sorted using the message sequence number, and then a second sort is performed on a message based on the ingress timestamp in the metadata. Through this process, the system constructs a single message. Forwarding path sequence in the network ,in Represents the first on the path One satellite node.

[0074] A single service flow contains several consecutively transmitted messages, as shown in the attached diagram. Figure 5 As shown. By tracing and analyzing the path information of all packets in the flow at the packet level, the forwarding paths of all packets in the service flow can be constructed.

[0075] Furthermore, based on the forwarding paths of all messages, a time-varying graph of the business flow path is constructed using time-varying graph theory;

[0076] Based on the network entry timestamp and network exit timestamp of the service flow, the service flow The lifecycle is discretized by dividing the time axis into several time intervals. If within a time interval... If the path sequence of all messages remains consistent, it is defined as a path state. The network entry timestamp refers to the entry timestamp of the first packet in the service flow at the network entry node, and the network exit timestamp refers to the exit timestamp of the last packet in the service flow that arrives at the destination address at the end node.

[0077] All satellite network path states are sequentially linked and compared to identify the link connections between adjacent path states. Based on this, the service flow... Its lifecycle is mapped as an ordered sequence of path states. :

[0078] ,

[0079] in, Indicates business flow The total number of path states experienced during the lifecycle; Indicates the first The time window of a path, i.e., the duration of the path. Representing the path status respectively The start and end times; Indicates within the time window Internally, it carries the business flow. An ordered list of satellite nodes, in which This represents the path hop count in this state. Represents the first on the path One satellite node;

[0080] based on By setting the path set in all path states { }、{ }、 Perform a union operation to obtain the business flow. By combining the complete set of satellite nodes and network topology domains covered throughout the entire lifecycle with the timestamp information in the metadata, a time-varying graph of the business flow path within the business flow lifecycle is constructed.

[0081] Furthermore, a constellation topology table based on ephemeris is introduced as a spatiotemporal reference for satellite network link establishment, and a traffic scheduling strategy table and a diurnal outage time table are introduced as references. Combined with the time-varying diagram of service flow paths, the reasons for message path switching are derived.

[0082] The system introduces a constellation topology table based on ephemeris as the spatiotemporal reference for establishing satellite network links, and constructs an adjacency matrix. Elements in the matrix The definition is as follows:

[0083] ,

[0084] Among them, matrix elements Indicates at time Satellite nodes With nodes Link status between them This indicates that the link between the two is available; This indicates that the link between the two is unavailable.

[0085] The matrix It describes the current state of whether the inter-satellite links of the satellite network are available, serving as a global physical constraint model for determining the cause of path switching.

[0086] For continuously transmitted messages, the system employs a sliding window algorithm to detect dynamic changes in the path and accurately locate key nodes where switching occurs. For the obtained time period... message The path is Time period message The path is The system takes the intersection of two sets to determine the last common node of the two paths from front to back. Original next-hop node and the new next hop node Based on this, the telemetry acquisition module, combined with the dynamic link establishment matrix, traffic scheduling strategy table, and daily outage schedule, further analyzes and determines the reasons for the switching of service flow packet transmission paths, as shown in the attached table. Figure 1 As shown, the specific analysis and judgment methods are as follows:

[0087] At any moment If a public node is found during the inspection With the original next hop node Link connection status between The current moment changes from available to unavailable, that is... If the value changes from 1 to 0, the path switch is determined to be a deterministic, planned, normal link switch.

[0088] At any moment If the inspection finds a public node With the original next hop node Connection status between It is still available, but the packet forwarding path has been switched to the new next-hop node. Then, the decision is made based on the traffic scheduling policy table. Whether the node is configured with a traffic scheduling policy: If a valid traffic scheduling policy exists, the path switch is determined to be caused by a deterministic policy; if no relevant traffic scheduling policy is configured, the time is further determined by combining the time schedule to see if a timeout has occurred at the current time. If the time matches the time interval recorded in the time schedule, the path switch is determined to be caused by a deterministic timeout event.

[0089] If the above reasons are not the cause, then it is determined to be caused by multiple factors, including link intermittent interruptions, path performance degradation, instantaneous load fluctuations, short-term link quality jitter, and control plane decision delays, as well as other unknown factors. Further judgment requires consideration of other information. Finally, the system performs switching on the path time-varying graph. The reasons for these behaviors are categorized and labeled to distinguish different types of online behavior.

[0090] To make the objectives, technical solutions, and advantages of this invention clearer, the embodiments of this invention are described in detail below with reference to the accompanying drawings. These embodiments are implemented based on the technical solutions of this invention, providing detailed implementation methods and specific operating procedures. The specific examples described herein are merely illustrative of this invention, but the scope of protection of this invention is not limited to the following embodiments.

[0091] As attached Figure 6 The image shows a satellite constellation application scenario for this embodiment. Service Flow The message ordering in the stream uses message sequence numbers starting with 1. During different stages of its lifecycle, messages are distributed across three paths: Path 1, Path 2, and Path 3. Satellite nodes are distinguished by node identifiers 1-9. Messages with sequence number 1 are transmitted via Path 1, passing through nodes 1-2-3-4-5-9 in sequence. Each satellite node's transmitted message contains the ingress timestamp, egress timestamp, and node identifier, with a one-to-one correspondence between timestamps and node identifiers. The specific configuration and message path tracking process are as follows:

[0092] As described in step S1, flow label mapping rules are first configured on the network ingress node ground station U1 to match the service flows that require flow-based telemetry. Service Flow Upon arrival at ground station U1, the rules are matched and the flow telemetry process begins, which is part of the business flow. The packets in the IPv6 header are assigned a sequence number starting from 1 and a globally unique flow identifier, let's say 1. The value of this flow identifier is then mapped to the Flow Label field in the IPv6 header and written into the flow telemetry header.

[0093] The flow can be identified by the flow label at each satellite node through which the message passes. After the service flow is identified, telemetry is used to collect metadata, which includes, but is not limited to, key information such as node identifier and ingress timestamp. After the satellite node metadata collection is completed, the following telemetry head and metadata are sent to the following telemetry acquisition module.

[0094] As described in step S2, after the flow-fed telemetry acquisition module receives the data transmitted from each satellite node, as shown in the attached... Figure 7 As shown, for message data with flow identifier 1, analysis is performed based on information such as timestamp, message sequence number, and node identifier to reconstruct its actual forwarding path in the satellite network. For example, for the metadata sent by the message with message sequence number 1, sorting by the incoming timestamp reveals that the satellite nodes the message passed through were nodes 1-2-3-4-5-9, and its forwarding path is path 1. Furthermore, the forwarding paths of all messages in the service flow are reconstructed.

[0095] As described in step S3, by performing time sorting and aggregation analysis on the forwarding paths of all packets, a complete time-varying path diagram of the service flow can be obtained, as shown in the attached figure. Figure 8 The three paths shown represent the business flow. The lifecycle of a packet is determined by the timestamp of its first packet entering the network entry node and the timestamp of its last packet leaving the satellite network. The system uses this time interval as a benchmark to analyze service flows. The lifecycle is discretized.

[0096] In this scenario, the business flow The messages are transmitted sequentially along path 1, path 2, and path 3 during their lifecycle, and therefore can be mapped to an ordered sequence of path states:

[0097] ,

[0098] in, and These represent the sequence of satellite nodes that the service flow passes through in different time windows.

[0099] This path state sequence fully characterizes the business flow. The path evolution process in satellite networks provides a foundation for subsequent path switching analysis. Furthermore, performing a union operation on all paths yields the service flow. The entire set of satellite nodes covered throughout the entire lifecycle is used to construct the service flow. A path time-varying graph is used to describe the evolution of a path over time.

[0100] As described in step S4, when the telemetry acquisition module detects a change in the forwarding path of an adjacent message, the system compares the paths of the adjacent messages to locate the location where the path switching occurred.

[0101] Set time period Message The forwarding path is Time period Message The forwarding path is The system takes the intersection of two sets and selects the last common node from beginning to end as the path switching node. In this scenario, the business flow occurs at any given time. If a path switches from path 1 to path 2, and the two paths remain consistent at nodes 1 and 2, but branch off after node 2, then node 2 is identified as the path switching node. .

[0102] After locating path switching node 2, the system further uses a constellation topology table based on ephemeris, a traffic scheduling strategy table, and a solar outage time table to determine the reason for the switching. Within the time window where the switching occurs, if the original next-hop node before the switching is detected... (Node 3) and Connection status between (node ​​2) If a path changes from available to unavailable at the current moment, it is determined to be a deterministic, planned, normal link switchover; if the link is still detected to be available, i.e. However, the message forwarding path is switched to the new next-hop node. (Node 6) will then undergo further checks based on the traffic scheduling policy table. Whether the node is configured with a traffic scheduling policy: If there is a valid relevant policy, the path switch is determined to be caused by a deterministic policy; if no relevant traffic scheduling policy is configured, the timetable is further combined to determine whether a daytime outage has occurred at the current time. If the time matches the time interval recorded in the daytime outage timetable, the path switch is determined to be caused by a deterministic daytime outage event.

[0103] For dynamic adjacency matrices :

[0104] ,

[0105] current In other words, after the handover occurs, the inter-satellite link between Node 2 and Node 3 becomes unavailable, indicating that the path handover is a planned normal link handover caused by the natural failure of the link due to satellite orbital motion. In this case, the service flow automatically selects an alternative path {1,2,6,7,8,9} that still meets the physical connectivity constraints at the current moment to continue transmission, thereby ensuring service continuity.

[0106] If the link interruption cannot be explained by normal orbital motion, the system will classify the path switch as an unplanned abnormal link switch and proceed to the anomaly cause analysis process.

[0107] Specifically, this type of abnormal switching may be caused by one or a combination of the following factors:

[0108] 1. Intermittent link disconnection or unstable link

[0109] Due to factors such as inter-satellite channel quality fluctuations, antenna pointing errors, or short-term obstruction, the link may fail prematurely or be intermittently interrupted within the visibility window.

[0110] 2. Equipment or load abnormality

[0111] Issues such as faulty onboard communication equipment, abnormal interfaces, or limited power can render the link unusable at the physical level.

[0112] The above situation requires further analysis and determination based on more information.

[0113] For dynamic adjacency matrices :

[0114] ,

[0115] in, The link between Node 2 and Node 3 is available, and the system proceeds to the traffic scheduling policy determination branch. First, the system checks whether there is a configured or recently updated traffic scheduling policy on the switching node within the current time window. If a policy adjustment event matching the service flow is detected, and the effective time of the policy is consistent with or highly overlaps with the time of the path switch, the path switch is determined to be policy-induced, including but not limited to proactive control behaviors such as load balancing scheduling, path optimization, or network reconstruction.

[0116] If no clear strategy adjustment record is detected, the system further combines the solar outage timetable to determine whether a solar outage has occurred at the current time. Taking the solar outage situation in early March 10, 2025 as an example, the solar outage timetable is shown in the table below. If the current time matches the time interval recorded in the solar outage timetable, it is determined that the path switch was caused by a deterministic solar outage event.

[0117] Table 1. Solar Transmission Timeline:

[0118]

[0119] If the issue is not caused by traffic scheduling strategies or daytime outages, it may be caused by factors such as path performance degradation, instantaneous load fluctuations, short-term link quality jitter, or control plane decision delays. Further confirmation can be obtained through subsequent statistical analysis or long-term observation.

[0120] Finally, the system marks the path switching event and its cause that occurred at node 2 in the business flow path time-varying graph.

Claims

1. A message path tracing method for a satellite network, characterized in that, The method includes the following steps: S1: At the network entry node, each service flow is assigned a flow identifier by mapping the flow label of the packet to the Flow Label field of the IPv6 packet header and written into the flow telemetry header; metadata based on the flow label is collected on each dynamic satellite node along the path of each service flow and the telemetry data is sent to the flow telemetry collection module. S2: The telemetry acquisition module analyzes the message forwarding path based on the received telemetry dataset according to the timestamp, message sequence number and node identifier, and constructs the forwarding path of all messages in the service flow; S3: Based on the forwarding paths of all packets, construct a time-varying graph of the business flow path using time-varying graph theory; S4: Introduce a constellation topology table based on ephemeris as the spatiotemporal reference for satellite network link establishment, introduce a traffic scheduling strategy table and a solar outage time table as reference, and combine the time-varying diagram of service flow path to deduce the reasons for message path switching. S4.1 The reasons for message path switching are divided into two categories: deterministic switching and non-deterministic switching. Deterministic switching refers to message switching caused by known factors during transmission. Non-deterministic switching refers to message switching caused by unknown factors during transmission. S4.2 Obtain the constellation topology table based on ephemeris, analyze the inter-satellite link connectivity before and after path switching, and establish a dynamic link establishment matrix between satellite nodes; S4.3 Obtain the traffic scheduling policy table and daily delay schedule for reference to analyze whether the packet path switching is caused by the traffic scheduling policy or daily delay. S4.4 Combine the time-varying diagram of the business flow path, the dynamic link establishment matrix, the traffic scheduling strategy table and the daily time table to analyze and determine the key nodes and reasons for path switching during message transmission; Step S4.4, which involves determining the key nodes and reasons for path switching during message transmission, is implemented as follows: For the obtained time period message The path is Time period message The path is The system takes the intersection of two sets to determine the last common node of the two paths from front to back. Original next-hop node and the new next hop node Based on this, the telemetry acquisition module, combined with the dynamic link establishment matrix, traffic scheduling strategy table, and daily outage schedule, further analyzes and determines the reasons for the switching of service flow packet transmission paths. The specific analysis and determination methods are as follows: At any moment If a public node is found during the inspection With the original next hop node Link connection status between The current moment changes from available to unavailable, that is... If the value changes from 1 to 0, the path switch is determined to be a deterministic, planned, normal link switch. At any moment If a public node is found during the inspection With the original next hop node Connection status between It is still available, but the packet forwarding path has been switched to the new next-hop node. Then, the decision is made based on the traffic scheduling policy table. Whether the node is configured with a traffic scheduling policy: If a valid traffic scheduling policy exists, the path switch is determined to be caused by a deterministic policy; if no relevant traffic scheduling policy is configured, the time is further determined by combining the time schedule to see if a timeout has occurred at the current time. If the time matches the time interval recorded in the time schedule, the path switch is determined to be caused by a deterministic timeout event. If the above reasons are not the cause, it is determined to be caused by a variety of factors, including link intermittent interruption, path performance degradation, instantaneous load fluctuation, short-term link quality jitter and control plane decision delay, as well as other unknown factors. Further judgment is required by combining other information. Finally, the system performs switching on the path time-varying graph. The reasons for these behaviors are categorized and labeled to distinguish different types of online behavior.

2. The message path tracking method for a satellite network according to claim 1, characterized in that, The specific process of step S1 is as follows: S1.1 When a service flow enters the network ingress node, it is assigned a unique flow identifier through flow label mapping and mapped to the Flow Label field in the IPv6 packet header; S1.2 Map the flow identifier to the flow identifier field of the flow telemetry head, and assign a message sequence number starting from 1 to all messages and write it into the flow telemetry head; S1.3 At each dynamic satellite node along each service flow path, the service flow is identified and metadata is collected through flow tags. The metadata includes, but is not limited to, the current satellite node identifier, timestamp, and message sequence number. The timestamp refers to the time when each message of the service flow enters the current satellite node, marked as the in timetamp of the message, and the time when the message leaves the current satellite node, marked as the out timetamp of the message. After the satellite node metadata collection is completed in S1.4, the telemetry headers and metadata collected for each message are combined into telemetry data packets for each message and sent to the telemetry acquisition module.

3. The message path tracking method for a satellite network according to claim 1, characterized in that, The specific process of step S2 is as follows: After receiving the telemetry data packets sent by each satellite node, the S2.1 flow-following telemetry acquisition module distinguishes service flows by flow identifier and sorts all messages of each service flow by message sequence number; S2.2 The telemetry acquisition module determines the time sequence of satellite nodes through which a message passes based on the ingress and egress timestamps in the metadata, and reconstructs the forwarding path of the message in the network; S2.3 Tracks and analyzes the path information of all packets in the flow to construct the forwarding path of all packets in the service flow in the network.

4. The message path tracking method for a satellite network according to claim 1, characterized in that, The specific process of step S3 is as follows: Based on the network entry timestamp and network exit timestamp of the service flow, the service flow The lifecycle is discretized by dividing the time axis into several time intervals. If within a time interval... If the path sequence of all messages remains consistent, it is defined as a path state. The network entry timestamp refers to the entry timestamp of the first packet in the service flow at the network entry node, and the network exit timestamp refers to the exit timestamp of the last packet in the service flow that arrives at the destination address at the end node. All satellite network path states are sequentially linked and compared to identify the link connections between adjacent path states. Based on this, the service flow... Its lifecycle is mapped as an ordered sequence of path states. : ， in, Indicates business flow The total number of path states experienced during the lifecycle; Indicates the first The time window of a path, i.e., the duration of the path. Representing the path status respectively The start and end times; Indicates within the time window Internally, it carries the business flow. An ordered list of satellite nodes, in which This represents the number of hops in the path under this path state. Represents the first on the path One satellite node; based on By setting the path set in all path states { }、{ }、 Perform a union operation to obtain the business flow. By combining the complete set of satellite nodes and network topology domains covered throughout the entire lifecycle with the timestamp information in the metadata, a time-varying graph of the business flow path within the business flow lifecycle is constructed.

Images