A dynamic self-adaptive configuration method for mixed-service-oriented SDN network measurement

Abstract

The application discloses a kind of hybrid service-oriented SDN network measurement dynamic adaptive configuration method, comprising: receiving measurement intention generates six-tuple descriptor;Topology embedding vector is calculated using graph neural network, and the level of change is evaluated by vector distance to trigger differentiated configuration;Intention is decomposed into atomic task, and priority conflict is resolved in combination with resource capacity;According to the precision and load, adaptive switching is carried out between active measurement and in-band telemetry and incremental configuration is issued;Fusion double-channel measurement data constructs macroscopic and microscopic quality view;Closed-loop evaluation overhead and state and dynamically adjust strategy.The application solves the problem of differentiated expression of measurement demand in hybrid service scenario, roughness of topology change perception granularity and imbalance between resource overhead and precision, and realizes the paradigm upgrade from static topology driven to intention-aware dynamic adaptive configuration.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a dynamic adaptive configuration method for SDN network measurement oriented towards hybrid services. Background Technology

[0002] With the rapid development of emerging application scenarios such as the Industrial Internet, intelligent manufacturing, and the Internet of Vehicles, network service types are exhibiting highly diversified and dynamic characteristics. On the same physical network infrastructure, it is often necessary to simultaneously support multiple service flows with vastly different quality of service requirements. Taking an industrial manufacturing workshop as an example, the robot collaborative control command flow requires end-to-end latency of less than 1 millisecond and jitter control at the microsecond level, making it a typical deterministic latency-sensitive service; the production monitoring video feedback flow requires a stable, high-bandwidth transmission channel, but has a certain tolerance for occasional packet loss; while the equipment operation log reporting flow only needs a best-effort transmission service to meet its needs. This scenario of mixed service coexistence poses unprecedented challenges to the granularity and flexibility of network performance measurement.

[0003] Software-defined networking (SDN) technology, by decoupling the control plane from the data plane, empowers network administrators with a global view and programmability, providing an architectural foundation for implementing network-wide performance measurements. Currently, SDN-based automatic network measurement configuration methods typically employ a topology-driven approach: the SDN controller collects network topology information using protocols such as BGP-LS, identifies the physical links in the network, and then automatically generates a fixed set of active measurement protocol configurations for each link. For example, in existing solutions, the system determines the source and destination of a measurement session by comparing the IP addresses of the interfaces at both ends of a link, generates configuration templates for protocols such as TWAMP or TWAMP-Light, and distributes them to relevant router devices to perform link quality monitoring.

[0004] However, the existing solutions exhibit the following technical shortcomings when facing mixed service scenarios. First, existing methods employ a one-size-fits-all uniform measurement strategy, applying the same measurement frequency, metrics, and accuracy level to all links, failing to perceive and differentiate the varying measurement requirements of different services. This results in critical services potentially failing to achieve effective quality assurance due to insufficient measurement accuracy, while non-critical services consume the same measurement resources, leading to an unreasonable allocation of measurement overhead. Second, the existing methods have a relatively crude response mechanism to network topology changes. Whenever BGP-LS reports a topology change event, the system typically triggers a full network-wide configuration regeneration and redistribution, generating significant controller computational overhead and southbound communication load in large-scale networks, and failing to distinguish between local link jitter and structural network reconfiguration. Third, existing solutions lack intelligent control for dynamically balancing measurement overhead and accuracy. Whether using fixed-frequency active probing or full-band telemetry, neither can adaptively adjust the measurement strategy based on real-time network load and changes in service intent, ensuring measurement effectiveness while controlling measurement overhead.

[0005] Furthermore, while there is existing research in academia on intent-driven network measurement, it primarily focuses on translating intents into data plane P4 codes for traffic statistics and anomaly detection, with the goal of data flow measurement in programmable switch environments. Some studies have also explored hybrid methods of active and passive telemetry within in-band telemetry to improve INT coverage integrity. However, none of these studies address how to achieve automatic configuration of end-to-end network performance measurement—from intent parsing, resource scheduling, protocol selection to closed-loop adaptation—driven by the control plane to meet the differentiated needs of mixed services. Summary of the Invention

[0006] The purpose of this invention is to provide a dynamic adaptive configuration method for SDN network measurement oriented towards mixed services, in order to solve at least some of the problems existing in the prior art.

[0007] Technical solution: A dynamic adaptive configuration method for SDN network measurement oriented towards mixed services, comprising the following steps:

[0008] Receive measurement intent input data and perform formal translation and semantic verification to generate a six-tuple intent descriptor;

[0009] The six-tuple intent descriptor is decomposed into a requirement to generate an atomic measurement task set. The atomic measurement task set is compared with the link measurement resource capacity vector to detect the resource conflict task list. Conflict resolution is performed on the resource conflict task list, and a list of conflict-free atomic task execution is output.

[0010] The embedding vector of the current network topology is calculated based on the graph neural network to obtain the current topology embedding vector. The distance between the current topology embedding vector and the baseline topology embedding vector is measured, and the topology change level is determined based on the measurement result.

[0011] The configuration distribution range of the conflict-free atomic task execution list is determined based on the topology change level. Within the configuration distribution range, an adaptive selection is made between active measurement mode and in-band telemetry mode to generate protocol configuration payloads and distribute them to network devices in an incremental manner.

[0012] Collect the first data stream reported by active measurement and the second data stream reported by in-band telemetry, perform time alignment and spatial correlation on the first and second data streams, and generate a fused network quality view;

[0013] The measurement cost percentage parameter and health score parameter are calculated based on the fused network quality view. The measurement cost percentage parameter and health score parameter are compared with the preset threshold. Based on the comparison result, an adaptive adjustment action is triggered and the baseline status parameter is updated to complete the configuration.

[0014] Beneficial effects: This invention realizes a paradigm upgrade of SDN network measurement from static topology-driven to intent-aware dynamic adaptation, balancing the guarantee of differentiated measurement accuracy and efficient utilization of system resources in mixed service scenarios. Attached Figure Description

[0015] Figure 1 This is a flowchart of the overall solution of the present invention.

[0016] Figure 2 This is a flowchart of the process for generating a six-tuple intent descriptor according to the present invention.

[0017] Figure 3 This is a flowchart of the invention that outputs a conflict-free list of atomic task executions.

[0018] Figure 4 This is a flowchart of the present invention for determining the level of topological change.

[0019] Figure 5 This is a flowchart illustrating how the present invention generates protocol configuration payloads and sends them to network devices in an incremental manner.

[0020] Figure 6 This is a flowchart illustrating the generation of a fused network quality view according to the present invention.

[0021] Figure 7 This is a flowchart of the present invention that triggers adaptive adjustment actions and updates baseline state parameters. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] like Figure 1 As shown, this embodiment describes in detail the data processing flow of a dynamic adaptive configuration method for SDN network measurements oriented towards hybrid services, specifically including:

[0024] Step S1: Receive measurement intent input data and perform formal translation and semantic verification to generate a standardized six-tuple intent descriptor.

[0025] Specifically, the system first receives multimodal intent input data through the intent interface layer. This input data supports three forms: first, natural language strings, such as "monitor all links through which the industrial robot control flow passes, requiring latency measurement accuracy to reach ±50 microseconds and measurement bandwidth usage not exceeding 500Kbps"; second, declarative API calls, usually submitted in JSON format, containing fields such as the target flow quintuple, indicator type and accuracy requirements, resource constraint upper limit, and priority value; and third, policy template identifiers and their instantiation parameters, retrieving predefined measurement policy skeletons from the template library based on the template ID.

[0026] Furthermore, format standardization preprocessing is performed on the received raw input data. For natural language input, a lexical analyzer and a parser based on a pre-defined intent primitive set are invoked for parsing. This primitive set contains keywords such as MEASURE, MONITOR, WITH_PRIORITY, WITH_BUDGET, and UNTIL. The parser scans the standardized text, identifies primitive keywords, and triggers corresponding parsing rules to construct an abstract syntax tree describing the hierarchical structure of intents. For example, the root node of this abstract syntax tree is "MeasurementIntent," under which six core branch nodes are attached, corresponding to the measurement target, indicator set, constraints, priority, time range, and spatial range, respectively. Taking JSON input as an example, the target field is mapped to the target branch, the metrics array is mapped to the indicator set branch, the constraints object is mapped to the constraint branch, and so on.

[0027] According to one aspect of this application, after the abstract syntax tree (API) is constructed, the next processing step is not immediately initiated. Instead, a depth-first traversal is first performed on the API to conduct semantic verification. Semantic verification includes three dimensions of checks: First, a required field existence check, verifying that the measurement target and indicator set branches exist and are not empty; second, a constraint compatibility logic check, comparing the accuracy requirement of each indicator in the indicator set with the frequency or bandwidth upper limit in the constraints. If the required theoretical minimum bandwidth exceeds the set upper limit, it is determined to be a logical conflict; third, a spatial range validity check, checking whether the IP address prefix defined in the target field conforms to the naming convention and is reachable within the current autonomous system. If any check fails, a structured error response containing an error code and correction suggestions is generated and returned to the interface layer.

[0028] In a preferred embodiment, after semantic verification passes, the content of the spatial scope branch in the abstract syntax tree is extracted. If the spatial scope is specified as a logical service identifier, the traffic engineering database is queried using this identifier as the key to obtain the equivalent multipath routing information of the service flow in the current network state; if it is specified as an explicit path list, it is directly referenced. Further, the logical scope is parsed and mapped into a set of physical entities, where each element is either a node object (containing node ID and management IP address) or a link object (containing link ID, source port IP address, destination port IP address, source node ID, and destination node ID).

[0029] Furthermore, the information from each branch node of the abstract syntax tree and the parsed set of physical entities are extracted and recombined, compressed, and encapsulated into a standardized six-tuple intent descriptor. This descriptor has the form I = t{Target,Metrics,Constraints,Priority,TemporalScope,SpatialScope}. For example, the instantiation data of a complete six-tuple intent descriptor is as follows: the Target field value is the five-tuple corresponding to the business flow corresponding to flow_label="agv_control_flow"; the Metrics field value is a list containing {type: DELAY, precision: 50, unit: us}; the Constraints field value is {max_bw_kbps: 500}; the Priority field value is the integer 8; the TemporalScope field value is continuous; and the SpatialScope field value is the parsed set of physical entities. Then, a globally unique 128-bit UUID is assigned to this descriptor as an identifier, and it is associated with and written into the intent state database, completing the complete translation process from user intent to processable data.

[0030] Step S2: Decompose the standardized six-tuple intent descriptor into a requirement set to generate an atomic measurement task set. Compare the atomic measurement task set with the link measurement resource capacity vector, detect the resource conflict task list, perform conflict resolution on the resource conflict task list, and output a list of conflict-free atomic task executions.

[0031] In this embodiment, the generated standardized six-tuple intent descriptor is decomposed into atomic measurement tasks that can be directly mapped to a single physical link, and the resource contention problem between multiple intents is solved under resource-constrained conditions.

[0032] Specifically, the process first iterates through all six-tuple intent descriptors in the intent state database that are in a validated state. For each descriptor, it reads the set of physical entities in its SpatialScope field and the list of measurement metrics in its Metrics field. Further, a double-loop traversal process is executed: the outer loop iterates through each link in the physical entity set, and the inner loop iterates through each metric in the measurement metric list. For each (link, metric) combination, an atomic measurement task data structure is generated. For example, the data structure includes the following fields: task_id is a unique identifier generated by the system; link_id is a link identifier extracted from the link object; src_endpoint_ip and dst_endpoint_ip are the interface IP addresses at both ends of the link; metric_type is an enumerated value (such as DELAY, JITTER, LOSS); requested_precision is the precision value inherited from the metric set; requested_frequency is the initial request frequency calculated according to the precision requirement through the built-in policy mapping table, for example, a latency precision requirement of ±50 microseconds is mapped to a probe frequency of 100Hz; parent_intent_id is the UUID of the parent intent; parent_priority is the priority integer value inherited from the parent intent.

[0033] Furthermore, all generated atomic measurement task data structures are grouped according to the `link_id` field to obtain the task set corresponding to each physical link. For each link, a resource consumption accumulator is initialized, and each atomic task in its task set is traversed. Then, based on the `requested_frequency` field of each task and the known probe packet length (e.g., the typical size of a TWAMP-Light packet is 128 bytes, or 1024 bits), the estimated bandwidth consumption value is calculated using the formula: `est_bw = requested_frequency × packet_size`. Further, the estimated bandwidth consumption values ​​of each task are summed to obtain the total bandwidth consumption value, and the counts of each task are summed to obtain the total session consumption value.

[0034] According to one aspect of this application, a measurement resource capacity vector is predefined for each physical link. Exemplarily, this capacity vector contains four components: C_bw represents the upper limit of bandwidth available for active measurements, typically set to 2% of the total link bandwidth; C_cpu represents the percentage of CPU quota that the source device of the link can allocate to the measurement protocol daemon; C_session represents the maximum number of measurement sessions that can be established between the devices at both ends of the link; and C_flowtable represents the upper limit of data plane flow table entries that can be occupied when using in-band telemetry mode. Then, the total bandwidth consumption value and total session consumption value calculated in the previous step are compared with the corresponding components of this capacity vector. When the accumulated value of any component exceeds the capacity limit, a resource conflict is determined to exist on the link, and all atomic measurement tasks in the link's task set are recorded as a conflict task list.

[0035] In a preferred embodiment, a hierarchical conflict resolution process is executed for the conflict task list. First, all atomic measurement tasks in the conflict task list are sorted in descending order by the `parent_priority` field to obtain a sorted task list. An empty allowed execution list is initialized and the resource accumulator is reset. Then, each task is processed sequentially in descending order of priority. For the current task, it is checked whether adding it to the allowed execution list would exceed the limit of any component of the capacity vector; if it would not exceed the limit, it is added and the accumulator is updated; if it would exceed the limit, it is moved to a pending list. This process is called per-task admission control.

[0036] Furthermore, for a subset of tasks in the pending list that have the same `parent_priority` field value, a multi-objective optimization model is constructed to solve for the optimized execution frequency. This optimization model uses maximizing the total measured utility of all tasks with the same priority as the objective function, with the remaining available bandwidth of the link as the constraint. The utility function of each task can be defined as a function related to frequency and precision. A lightweight integer programming solver is invoked to solve the model, obtaining the optimized execution frequency for each task. For example, assuming three tasks with the same priority all request a frequency of 100Hz, but the remaining bandwidth only supports a total of 200Hz, the solution might result in two tasks maintaining 100Hz, one task dropping to 0Hz (i.e., temporarily suspended), or the three tasks being allocated 80Hz, 60Hz, and 60Hz respectively. Then, the `allocated_frequency` field of the task is updated based on the solution result, and it is moved from the pending list to the permitted execution list.

[0037] According to a further improvement of this embodiment, for tasks that remain in the pending list after optimization, an asynchronous feedback message containing a partially satisfied status and a fallback suggestion is generated by tracing back to the parent intent based on its parent_intent_id field, and this message is returned to the intent interface layer. Finally, the permitted execution list is output as a conflict-free list of atomic task executions, where each atomic task contains the finally determined allocated_frequency and execution_status fields.

[0038] Step S3: Calculate the embedding vector of the current network topology based on the graph neural network to obtain the current topology embedding vector. Measure the distance between the current topology embedding vector and the baseline topology embedding vector, and determine the topology change level based on the measurement result.

[0039] Specifically, peer sessions are established with route reflectors or border routers within the autonomous system via the BGP-LS protocol to subscribe to link-state network layer reachability information. Whenever the state of an Interior Gateway Protocol (INS) neighbor changes or link attributes are updated, the upstream router generates a BGP-LS update message. The system's topology-aware module receives this update message and calls the corresponding decoder to extract key information. For example, data extracted from a typical link NLRI update message includes: local router ID, remote router ID, local IPv4 interface address, remote IPv4 interface address, maximum link bandwidth, IGP metric, traffic engineering metric, management group attributes, etc. This data is used to dynamically maintain an in-memory network attribute graph G = ({V}, {E}, {X}_v, {X}_e). In this graph, each node is associated with a feature vector containing device type, AS number, and number of active interfaces; each directed edge is associated with a feature vector containing attributes such as normalized bandwidth, normalized metric, and link utilization.

[0040] Furthermore, upon detecting a change in the attribute graph, a delayed trigger timer is started to avoid frequent IGP oscillations. After the timer expires, the attribute graph G_t at the current sampling time is input into a pre-trained three-layer graph convolutional network model. The input data includes the graph's adjacency matrix, node feature matrix, and edge feature matrix. After the three-layer graph convolution operation, global average pooling is performed on the final layer feature vectors of each node, outputting a fixed-dimensional current topology embedding vector z_t. For example, this vector is a 128-dimensional floating-point array, such as [0.123, -0.456, 0.789,...], which acts as a unique digital fingerprint of the network topology at the current time.

[0041] In a preferred embodiment, the baseline topology embedding vector z_base corresponding to the most recent successful deployment of measurement configuration is read from the persistent storage of the configuration management library. The cosine distance between the current topology embedding vector and the baseline topology embedding vector is calculated. This distance value ranges from 0 to 2, where 0 indicates that the vectors are in the same direction and 2 indicates that the directions are completely opposite.

[0042] Specifically, the calculated cosine distance value is compared with preset low thresholds θ_low and high thresholds θ_high to determine the level of topology change. For example, after testing environment calibration, θ_low is set to 0.05 and θ_high is set to 0.25. The comparison rules are as follows:

[0043] When the cosine distance value is less than the low threshold (d < 0.05), the system determines the topology change level to be a stable state. This situation typically corresponds to a fine-tuning of the link IGP metric or a momentary interruption of a single edge access link. Based on this determination, a decision signal is generated that does not trigger configuration regeneration, and subsequent reconfiguration steps are skipped directly.

[0044] When the cosine distance value is between the low and high thresholds (0.05 ≤ d < 0.25), the topology change level is determined to be a locally significant change. This situation typically corresponds to a change in a member link of a port aggregation or a restart of an aggregation layer device. By comparing the structural differences in the attribute graphs at two different times, the changed set of node identifiers and link identifiers are accurately located, and these identifier sets are marked as the affected entity set.

[0045] When the cosine distance value is greater than or equal to the high threshold (d≥0.25), the topology change level is determined to be a structural abrupt change. This situation usually indicates a major event such as a core layer equipment failure or a fiber optic backbone outage. Based on this determination, the current network topology is marked as an area awaiting reconfiguration.

[0046] In one alternative implementation, before calculating the cosine distance value, the current topological embedding vector can be input into a topological prototype library built offline through historical embedding vector clustering to perform an approximate nearest neighbor search. If the retrieved Euclidean distance to a cluster center is less than a preset similarity threshold, the set of pre-validated measurement configuration templates associated with that prototype can be directly extracted, thereby skipping the requirement decomposition step and quickly proceeding to the configuration generation step.

[0047] Step S4: Determine the configuration distribution range of the conflict-free atomic task execution list based on the topology change level. Within the configuration distribution range, adaptively select between active measurement mode and in-band telemetry mode, generate protocol configuration payload, and distribute it to network devices incrementally.

[0048] Specifically, the configuration distribution scope is first determined based on the topology change level. If the determination result of step S3 is a stable state, no configuration distribution action is triggered, and the process returns directly to the previous step. If the determination result is a significant local change, tasks whose link identifiers belong to the affected entity set are selected from the atomic task execution list to form a local task subset, and the configuration distribution scope is limited to this local task subset. If the determination result is a structural mutation, the configuration distribution scope is set to all tasks in the atomic task execution list.

[0049] Furthermore, within the defined configuration range, each atomic task is traversed to select the most suitable measurement mode. The selection of the measurement mode is accomplished by the built-in strategy selector module, which follows a three-level decision rule. The first level rule reads the `metric_type` and `requested_precision` fields of the atomic task and compares them with a pre-stored measurement mode capability mapping table. For example, this mapping table defines the typical latency measurement accuracy of proactive measurement modes (such as TWAMP-Light) as approximately ±100 microseconds, while the accuracy of in-band telemetry modes can reach ±10 nanoseconds. If the requested accuracy exceeds the proactive measurement capability limit, or if the metric type requires hop-by-hop latency, the in-band telemetry mode is directly selected. The second level rule: If the first level rule is not met, a synchronous query is initiated to the closed-loop feedback control module to obtain the real-time load rate parameters of the link where the atomic task resides. If the load rate parameter is higher than the preset overhead protection threshold (e.g., 80%), and the parent_priority field value of the task is lower than the preset priority threshold, the active measurement mode is selected, and the execution_status field of the task is marked as degraded, indicating that it failed to run in the optimal mode due to high network load. Third-level rule: If neither of the first two levels of rules is met, the active measurement mode is selected by default as the baseline policy.

[0050] According to one aspect of this application, after the measurement mode is selected, the protocol configuration payload generation stage begins. If the active measurement mode is selected, the active measurement configuration generator is invoked. The generator first extracts the `src_endpoint_ip` and `dst_endpoint_ip` fields from the atomic task, compares the two IP addresses as unsigned integers, and determines the smaller one as the sender role and the larger one as the reflector role. This ensures that only one set of bidirectional measurement sessions is configured on a single physical link, avoiding duplicate configuration issues. Subsequently, the sender port number and reflector port number are queried from the device management database, and the active measurement configuration template corresponding to the device vendor and software version is read from the configuration template library. The sender IP, reflector IP, sender port, reflector port, the `allocated_frequency` field of the atomic task, and a globally unique `test-session` number are filled into the template to generate the sender configuration text and reflector configuration text.

[0051] In a preferred embodiment, if in-band telemetry mode is selected, the in-band telemetry configuration generator is invoked. The generator reads a predefined in-band telemetry template from the P4 program template library based on the switch node sequence of the path to which the atomic task belongs. In the ingress pipeline of the template, it dynamically generates an entry for each switch hop on the path. The matching key for this entry is the service flow 5-tuple, and the action is to call the `int_transit` action to push the switch ID, ingress / egress port, and timestamp into the INT packet header. Simultaneously, the INT sampling rate parameter is configured according to the allocated_frequency field of the atomic task. Finally, a P4 source code file and a runtime flow table configuration file are output.

[0052] Furthermore, the generated protocol configuration payload is compared line by line with the memory image of the device's current running configuration to calculate the difference increment. For ordinary single-device configuration changes, the increment is encapsulated in the NETCONF protocol. <edit-config>In RPC operations, the changes are directly issued. For cross-device configuration changes, a two-phase commit protocol is used: the first phase sends a command to all involved devices simultaneously, carrying the necessary information. <test-option> test-then-set< / test-option> The capability preparation request instructs the device to perform syntax and semantic verification and resource reservation without activating the configuration; after receiving successful confirmations from all devices within a preset timeout period, the second phase sends a request to all involved devices. <commit>The command is sent to activate the configuration. If any device returns an error or times out, a message is sent to all participating devices. <discard-changes>The command is used to abort this issuance to ensure the consistency of the distributed configuration state.

[0053] Step S5: Collect the first data stream reported by active measurement and the second data stream reported by in-band telemetry, perform time alignment and spatial correlation on the first and second data streams, and generate a fused network quality view.

[0054] In this embodiment, after the measurement configuration is successfully deployed and started, it continues to run, responsible for collecting two types of heterogeneous measurement data from the data plane and deeply fusing them to build a unified network quality view.

[0055] Specifically, the first step is to collect the initial data stream reported by active measurements. A high-performance telemetry data collection server based on the gRPC protocol is deployed in the northbound interface area of ​​the SDN controller. This server subscribes to the data paths of the TWAMP or TWAMP-Light YANG models on all router devices participating in active measurements. After the measurement session is established, the measurement clients and servers on the routers periodically push statistical information to this server via the Dial-Out mode of the Telemetry protocol. For example, a typical JSON-formatted report contains the following fields: node_id_str is the device identifier, test-session-id is the session number, sender-ip and reflector-ip are the endpoint addresses, the delay_stats substructure contains min_delay_us, max_delay_us, avg_delay_us, and std_dev_us, the jitter_stats substructure contains avg_jitter_us, and the loss_stats substructure contains loss_percent. The parser extracts the sender's IP field, the reflector's IP field, and the aforementioned performance metrics from the data stream. Using the (sender-ip, reflector-ip) tuple as the composite key, it performs a reverse lookup in the topology database to determine the unique physical link identifier corresponding to this measurement session. The parsed performance metrics, such as latency, jitter, and packet loss rate, are then associated with this physical link identifier and the reporting timestamp, and written as macro-quality metric records to the time-series database.

[0056] Furthermore, a second data stream of in-band telemetry reports is simultaneously collected. In the data plane, switches supporting P4 programmability insert an INT header containing telemetry information during packet processing if the packet header matches an INT rule when forwarding service packets. The last-hop switch on the path acts as the INT sink, responsible for stripping all INT headers and encapsulating them into INT Report packets for the controller. The controller's in-band telemetry analysis engine listens for these Report packets on a designated UDP port. Based on the INT standardized format, the analysis engine parses and extracts the flow 5-tuple information and hop-by-hop telemetry data list layer by layer from the packet's stacked structure. For example, each element in the hop-by-hop list contains: switch_id (switch identifier), ingress_port and egress_port (inbound and outbound port numbers), hop_latency_ns (hop dwell time), and queue_depth (outbound queue depth). The topology database is queried based on the egress_port field of each hop to determine the physical link identifier corresponding to that outbound port. Subsequently, the hop-by-hop telemetry data list is associated with the flow quintuple information, the physical link identifier, and the reporting timestamp, and then written into the same time-series database as a micro-state data record.

[0057] According to one aspect of this application, when an upper-layer application initiates a path diagnostic query request for a specific service flow, the data fusion module is activated. This query request carries a target flow identifier and a query time range. First, within this time range, a hop-by-hop telemetry data list corresponding to the target flow identifier is retrieved from the time-series database. Hop points with abnormal dwell times (e.g., exceeding the average by three standard deviations) or abnormal queue depths (e.g., exceeding a preset threshold) are located, and the physical link identifier associated with these hop points is extracted. In a preferred embodiment, using the physical link identifier as an index, macroscopic quality indicator records within the same query time range are further retrieved from the time-series database to obtain macroscopic indicators such as average latency, jitter, and packet loss rate for the link. The macroscopic latency and packet loss rate indicators are correlated with microscopic dwell time anomaly hop points to generate a fused diagnostic record containing a phenomenological description (increased end-to-end latency) and a root cause localization (congestion in the outgoing port queue of a specific switch). This fused diagnostic record is output as a fused network quality view. This time-aligned and spatially correlated fusion mechanism enables the construction of a complete chain of evidence from macroscopic phenomena to microscopic root causes.

[0058] Step S6: Periodically calculate the measurement cost ratio parameter and health score parameter based on the fused network quality view, compare the measurement cost ratio parameter and health score parameter with the preset threshold, trigger adaptive adjustment action based on the comparison result, and update the system baseline status parameter after the adjustment action is completed to complete the configuration.

[0059] In this embodiment, the measurement strategy is dynamically optimized by taking the fused network quality view as input and continuously monitoring the resource consumption and effectiveness of the measurement process itself.

[0060] Specifically, the overhead calculation task is performed periodically at configurable evaluation intervals (e.g., every 30 seconds). First, the probe traffic rate information for each measurement session is extracted from the converged network quality view. For each active measurement session in an active state, the average probe traffic rate of the session is calculated based on its configured probe packet length and probe frequency parameters. The probe traffic rates of each session are summed according to the physical link identifier to obtain the total active probe traffic rate on each link. Subsequently, the physical bandwidth parameters of each link are read from the device management database, and the total probe traffic rate is divided by the physical bandwidth parameters to obtain the measurement bandwidth overhead percentage parameter for each link. For example, for a 1Gbps link, if 10 TWAMP sessions with a frequency of 100Hz and a packet size of 128 bytes are running on it, the total probe traffic rate is 10 × 100 × 1024 = 1,024,000 bps, and the measurement bandwidth overhead percentage is 1.024 Mbps / 1000 Mbps = 0.1024%.

[0061] Furthermore, health score parameters are calculated simultaneously. The CPU utilization parameters of the measurement protocol daemon on each network device are obtained through the device query interface. The system also scans the latest data point timestamp of each measurement session in the time-series database, comparing the difference between the current system time and the latest data point timestamp with a preset multiple (e.g., 3 times) of the session's configured reporting period. When the difference exceeds this preset multiple, the measurement session is determined to be in a failed state, and a corresponding session failure identifier is generated.

[0062] According to a further improvement of this embodiment, the calculated measured bandwidth overhead ratio parameter is compared with a preset bandwidth alarm threshold, and the CPU utilization parameter is compared with a preset CPU alarm threshold. When the measured bandwidth overhead ratio parameter exceeds the bandwidth alarm threshold or the CPU utilization parameter exceeds the CPU alarm threshold, an overhead exceeding the limit flag is generated, and a measured frequency degradation action is triggered. In a preferred embodiment, the specific process of the frequency degradation action is as follows: query all atomic tasks running on the link or device, and sort them in ascending order by the parent_priority field to obtain a sorted task list. Select the tasks with the lowest priority according to a preset ratio (e.g., 20%) from the list, and reduce the value of the allocated_frequency field of each selected task by a preset ratio (e.g., halve it) to generate a frequency value after frequency degradation. Then, the incremental configuration distribution process is invoked to update the frequency parameters after frequency degradation to the corresponding network device.

[0063] Specifically, when a session failure flag is detected, the handling method depends on the current topology change level. If the determination result of step S3 is a stable state, the failure is determined to be due to a momentary software malfunction or configuration inconsistency, and a session reset action is performed, sending a sequence of configuration instructions to the corresponding device for deletion followed by reconstruction. If the determination result of step S3 is a significant local change or a structural abrupt change, the session reset action is suppressed, because the network topology itself is converging at this time, and the measurement interruption is expected; after the topology awareness layer completes topology re-awareness and new configuration generation, the new configuration will naturally take over the measurement task.

[0064] In an optional implementation, when a newly submitted high-priority six-tuple intent descriptor is received, and the resource conflict detection in step S2 indicates that occupied resources need to be released to satisfy the new intent, a low-priority task resource preemption action is triggered. All existing atomic tasks that share a bottleneck link with the new intent and whose parent_priority field value is lower than that of the new intent are located. The execution_status field of these tasks is modified to a suspended state, and a command to delete the measurement session is issued to the corresponding device. After confirming that the resource release is complete, resources are allocated for the new intent and a configuration is generated.

[0065] Furthermore, after each successful adaptive adjustment action, a baseline state update operation is performed. The following information is atomically written to the controller's configuration and state database: new configuration version tags generated for all affected network devices; if the adjustment action is triggered by a topology change, the current topology embedding vector is updated to the new baseline topology embedding vector; the state fields and allocation frequency fields of all affected intentions and atomic tasks are updated; and the current occupancy registration table of the measurement resource capacity vector for each link is refreshed. This persistence step provides an accurate reference benchmark for the next round of evaluation, thus forming a complete closed-loop feedback control loop.

[0066] According to another aspect of this application, such as Figure 2 As shown, a six-tuple intent descriptor is generated, including:

[0067] S1.1: Receive multimodal intent input data and perform format standardization preprocessing to obtain standardized input text.

[0068] Specifically, the intent interface layer of the system simultaneously monitors three logical channels to receive multi-modal intent input data. The first channel is a natural language character string input channel, through which network operation and maintenance personnel can input statements such as "perform path quality monitoring on the service flow identified as 'robot_control_flow', require that the measurement accuracy of one-way delay reaches ±50 microseconds, and the link bandwidth occupied by the measurement process shall not exceed 500Kbps" via a command line interface or a graphical management terminal. After receiving the character string, character encoding unification processing is performed first, all inputs are uniformly converted to UTF-8 encoding format, then a rule-based tokenizer is called to perform word segmentation processing on the character string, and the continuous text is split into a token sequence separated by spaces and punctuation. At the same time, meaningless stop words such as "de", "le", "jinxing" are filtered out, and key information-carrying words such as "robot_control_flow", "delay", "±50 microseconds", "bandwidth", and "500Kbps" are retained. The second channel is a declarative API call channel, through which an upper-level service orchestrator or user script POSTs a structured payload in JSON format to the system via the RESTCONF interface. Illustratively, the field structure of the JSON payload is:

[0069] {"intent_type":"measurement","target":{"flow_label":"robot_control_flow"},"metrics":[{"type":"delay","precision":50,"unit":"us"}],"constraints":{"max_bw_kbps":500},"priority":8,"temporal_scope":"continuous"}. JSON Schema verification is performed on this payload to verify whether required fields exist, whether data types are correct, and whether numerical ranges are legal. The third channel is a policy template identifier input channel, where the user only needs to provide a predefined template ID and a small number of instantiation parameters, for example {"template_id":"TMPL_INDUSTRY_ROBOT","params":{"src_prefix":"192.168.1.0 / 24","dst_prefix":"192.168.2.0 / 24"}}. The corresponding template skeleton is retrieved from the policy template library according to the template ID, the passed instantiation parameters are filled into the placeholder positions of the template, and a complete intent description text is generated.

[0070] Furthermore, regardless of the source of the input, it is ultimately transformed into a unified, standardized input text format. For natural language input, the standardized text retains the key-value pairs of key information; for API calls, the JSON structure is flattened into key-value pair strings connected by specific delimiters; for template instantiation input, the output is a complete intent description string after padding. This standardized input text will serve as the direct input for the next sub-step, syntax parsing.

[0071] S1.2: Call the preset intent primitive set to perform lexical and syntactic analysis on the standardized input text, and construct an abstract syntax tree. The abstract syntax tree includes measurement target branch, indicator set branch, constraint condition branch, priority branch, time range branch and spatial range branch.

[0072] Specifically, a set of intent primitives specifically designed for this invention is built-in. This primitive set is defined in a form similar to a domain-specific language, and includes core primitive keywords such as: MEASURE for defining measurement actions, TARGET for specifying measurement objects, METRICS for declaring a set of measurement indicators, CONSTRAINTS for imposing resource constraints, PRIORITY for setting priority values, TEMPORAL for defining time ranges, and SPATIAL for defining spatial ranges. A lexical analyzer based on the ANTLR framework is invoked to scan the standardized input text from left to right. The lexical analyzer segments the input character stream into a series of lexical units according to predefined regular expression rules. For example, for the input fragment "requires a measurement accuracy of ±50 microseconds for one-way delay", the lexical analyzer segments it into: [KEYWORD: Requirement], [IDENTIFIER: One-way Delay], [KEYWORD: Accuracy], [VALUE: 50], [UNIT: Microseconds].

[0073] Furthermore, the parser receives the lexical unit stream output by the lexical analyzer, performs reduction and derivation based on predefined context-free grammar rules, and constructs an abstract syntax tree describing the hierarchical structure of intents. The root node of this abstract syntax tree is a MeasurementIntent type node. Six core branch nodes are attached to the root node, each corresponding to one dimension of a six-tuple intent descriptor. The first branch is TargetBranch, which has leaf nodes attached. The leaf nodes' attribute fields include flow_label, src_ip_prefix, dst_ip_prefix, protocol, and port_range. The second branch is MetricsBranch, which has one or more MetricNode child nodes attached. Each MetricNode contains a type attribute (enumerated values ​​are DELAY, JITTER, LOSS, and BANDWIDTH), a precision attribute (numeric), and a unit attribute (unit string). The third branch is ConstraintsBranch, which has ConstraintNode child nodes attached. It contains a type attribute (such as MAX_BANDWIDTH and MAX_FREQUENCY) and a value attribute. The fourth branch is PriorityBranch, whose leaf node values ​​are integers from 1 to 10. The fifth branch is TemporalBranch, which contains start_time, end_time, and recurrence attributes. The sixth branch is SpatialBranch, which contains a scope_type attribute (LOGICAL or EXPLICIT) and the corresponding specific range value. In a preferred embodiment, the parser performs a preliminary scope check while constructing the AST to ensure that the CONSTRAINTS primitive and the MEASURE primitive are in the same scope, thus avoiding incorrect constraint associations across intents.

[0074] S1.3: Perform a depth-first traversal on the abstract syntax tree to perform semantic verification. After the verification passes, extract the content of the spatial range branch and map and parse the content of the spatial range branch into a set of physical entities containing node objects and link objects.

[0075] In this embodiment, it is executed after the abstract syntax tree is constructed to verify the semantic correctness of the intent and to transform the logical space range described in the intent into a specific physical entity in the network.

[0076] Specifically, a depth-first traversal is first performed on the abstract syntax tree, sequentially visiting each branch node and its subordinate child nodes. During this process, semantic validation is performed in three dimensions. The first dimension is the existence validation of required fields. It checks whether TargetBranch and MetricsBranch exist and whether their subordinate leaf nodes are not empty. For example, if an API call only specifies the priority field but lacks the target field, and the validation process is immediately interrupted when traversing to TargetBranch and finding that the branch is empty, a structured error response object is generated. This error response object contains the error_code field (value: E_MISSING_MANDATORY_FIELD), the error_message field (value: "Measurement target not specified"), and the suggestion field (value: "Please add the target field to the request to specify the measurement object"). The second dimension is constraint compatibility logic validation. The precision attribute value of each MetricNode under MetricsBranch is read and logically compared with the frequency or bandwidth constraints in ConstraintsBranch. An internal empirical mapping table is maintained, defining the theoretical minimum probe frequency and bandwidth required for different measurement accuracy levels. For example, a one-way latency accuracy of ±50 microseconds corresponds to a probe frequency of 100Hz and a probe bandwidth of approximately 500Kbps. The minimum resource overhead required for the current intent is calculated based on this mapping table. If the calculated result exceeds the upper limit declared in ConstraintsBranch, a logical conflict is identified, generating an error response with specific correction suggestions such as "suggesting increasing the accuracy to ±80 microseconds or increasing the bandwidth limit to 600Kbps." The third dimension is range validity verification. It checks whether the IP address prefix defined in SpatialBranch conforms to RFC standards and queries the controller's device management database to verify whether the prefix has a corresponding routing table entry in the current autonomous system. If the prefix is ​​unreachable, an E_UNREACHABLE_TARGET error code is returned.

[0077] In a preferred embodiment, after all the above three-dimensional verifications pass, the contents of SpatialBranch are extracted to perform topology binding operations. If the scope_type attribute is LOGICAL, its scope_value field stores a service flow logical identifier, such as "robot_control_flow". Using this identifier as the key, the traffic engineering database maintained in real time by the SDN controller via BGP-LS and PCEP protocols is queried. This database stores the mapping relationship between service flow forwarding equivalence classes and specific label-switched paths or hop-by-hop routes. The equivalent multi-path routing information of the service flow in the current network state is obtained. This routing information is returned in the form of an ordered sequence of nodes and links, for example: Path_1 = {Node_R1, Link_R1_R2, Node_R2, Link_R2_R4, Node_R4}. If scope_type is EXPLICIT, its scope_value field directly stores an explicit list of path hop counts, which is directly referenced. Finally, the logical scope is resolved and mapped to a set of specific physical entities, which exists in the form of a structured list. Each element in the list is either a node object (containing the node_id field and the mgmt_ip field) or a link object (containing the link_id field, src_ip field, dst_ip field, src_node_id field, and dst_node_id field).

[0078] S1.4: Extract and reorganize the information from each branch node of the abstract syntax tree and the physical entity set, compress and encapsulate it into a six-tuple intent descriptor, and write it into the intent state database after assigning a globally unique identifier to the six-tuple intent descriptor.

[0079] In this embodiment, the final data encapsulation and persistence of the intent processing flow are completed, integrating the information scattered in each node of the abstract syntax tree into a standardized data structure that can be uniformly called by all subsequent modules.

[0080] Specifically, the abstract syntax tree is traversed, and key information fields are extracted from each branch node. Values ​​extracted from `TargetBranch` include: the `target_type` field (identifying the type of measurement object, such as `FLOW` or `PATH`) and the `target_value` field (a specific target description, such as a quintuple or application label). A list structure is extracted from `MetricsBranch`, where each element is a substructure containing the `metric_type` field (enumerated values: `DELAY`, `JITTER`, `LOSS`, `BANDWIDTH`), the `precision` field (numerical), the `unit` field (unit string), and an optional `target_value` field (target threshold). Another list structure is extracted from `ConstraintsBranch`, where each element contains the `constraint_type` field (e.g., `MAX_BANDWIDTH`, `MAX_FREQUENCY`) and the `constraint_value` field. An integer value from 1 to 10 is extracted from `PriorityBranch`. A time range substructure containing `start_time`, `end_time`, and `recurrence` fields is extracted from `TemporalBranch`. The physical entity set is directly referenced from `SpatialBranch`.

[0081] Furthermore, all the information fields extracted above are recombined with the physical entity set and compressed and encapsulated into a standardized six-tuple intent descriptor.

[0082] According to one aspect of this application, a globally unique identifier is assigned to the six-tuple intent descriptor. Preferably, this identifier uses a 128-bit UUID format, such as "550e8400-e29b-41d4-a716-446655440000". An association mapping is established between this UUID and the six-tuple intent descriptor, and this key-value pair is written as a record to the controller's intent state database. This database is implemented using a key-value storage engine that supports transactional features to ensure the persistent reliability of intent data. After a successful write operation, an audit log is recorded, including a timestamp, operation type (CREATE), and intent UUID. At this point, the complete process from user intent input to translation into a standardized data structure is completed.

[0083] According to another aspect of this application, such as Figure 3 As shown, the output lists conflict-free atomic task executions, including:

[0084] S2.1: Traverse each six-tuple intent descriptor in the intent state database, read the physical entity set and indicator set of each six-tuple intent descriptor, perform a double loop traversal for each link in the physical entity set and each indicator in the indicator set, and generate an atomic measurement task data structure. The atomic measurement task data structure includes a link identifier field, a request accuracy field, a request frequency field, and a parent intent priority field.

[0085] Specifically, the requirement decomposer maintains a queue of pending intents. This queue reads all six-tuple intent descriptor records with a verified state from the intent state database in a first-in, first-out (FIFO) order. For each six-tuple intent descriptor retrieved from the queue, its SpatialScope field is accessed first. This field stores the set of physical entities obtained through topology binding resolution. For example, this set of physical entities is an ordered list containing node objects and link objects. A typical link object contains the following fields: link_id value "L12", src_endpoint_ip value "10.10.10.1", dst_endpoint_ip value "10.10.10.2", src_node_id value "R1", and dst_node_id value "R2". Simultaneously, the Metrics field of this six-tuple intent descriptor is read. This field is a list structure where each element describes a measurement metric requirement. For example, a list of metrics can contain two elements: the first element is {type: DELAY, precision: 50, unit: "us"}, and the second element is {type: JITTER, precision: 100, unit: "us"}.

[0086] Furthermore, a double loop traversal operation is performed on the physical entity set and the indicator set. The outer loop traverses each element in the physical entity set, and when an element of type link object is encountered, the inner loop is entered; the inner loop traverses each indicator element in the indicator set. For each pair of (link object, indicator element) combinations, the system generates an independent atomic measurement task data structure. In a preferred embodiment, the atomic measurement task data structure includes at least the following key fields: a task_id field, a globally unique identifier generated by the system call UUID generation algorithm, such as "TASK_a1b2c3d4e5f6"; a link_id field, directly extracted from the link object, such as "L12"; src_endpoint_ip and dst_endpoint_ip fields, copied from their respective fields in the link object; a metric_type field, extracted from the metric element, with a value of an enumeration type, such as DELAY; a requested_precision field, inherited from the metric element, such as the value 50; a requested_frequency field, calculated by querying the built-in policy mapping table based on the value of the requested_precision field, such as ±50 microseconds of latency accuracy mapped to a 100Hz detection frequency; a parent_intent_id field, recording the UUID of the parent intent that generated the task; and a parent_priority field, inherited from the Priority field of the parent intent, such as the integer value 8.

[0087] According to one aspect of this application, after generating the data structure for each atomic measurement task, it is temporarily stored in a memory-based temporary list named Global_Task_Pool. Simultaneously, an association mapping table is established and maintained. This mapping table has a key-value pair data structure, where the key is `parent_intent_id` and the values ​​are a list of `task_id` values ​​for all atomic tasks corresponding to the parent intent. The purpose of this mapping table is to quickly locate all atomic tasks decomposed from a specific intent during subsequent conflict resolution when priority adjudication or rollback processing of tasks for that intent is required.

[0088] S2.2: Group all atomic measurement task data structures by the link identifier field to obtain the task set corresponding to each link. For each link, traverse its task set, calculate the estimated bandwidth consumption value based on the request frequency field of each task and the known probe message length, and sum them up to obtain the total bandwidth consumption value and the total session consumption value.

[0089] In this embodiment, the task is executed after the atomic measurement task is generated. It is responsible for aggregating the tasks by physical link dimension and calculating the estimated cumulative resource consumption of all tasks to be executed on each link.

[0090] Specifically, a grouping operation is first performed on all atomic measurement task data structures in the generated Global_Task_Pool. This grouping operation uses the link_id field of each task as the grouping key, grouping tasks with the same link_id value into the same group. After the grouping operation is completed, a mapping structure is obtained, where the key is the link identifier string and the value is the atomic measurement task set T_l corresponding to that link. For example, for the group with the link identifier "L12", its task set may contain three tasks: task A has an indicator type of DELAY and a request frequency of 100Hz, task B has an indicator type of JITTER and a request frequency of 50Hz, and task C has an indicator type of LOSS and a request frequency of 10Hz.

[0091] Furthermore, for each link, resource consumption accumulation calculation is performed on the task set T_l for that link. First, two accumulator variables are initialized: total_bw_consumed for accumulating the estimated total bandwidth consumption (initial value: zero); and total_session_consumed for accumulating the total number of sessions (initial value: zero). Then, the data structure of each atomic measurement task in the task set is traversed. For each task, the value of its requested_frequency field is read, and the predicted probe packet length is obtained from the system configuration parameters. For example, for active measurements using the TWAMP-Light protocol, the typical size of its latency probe packet is 128 bytes, or 1024 bits. The estimated bandwidth consumption value for this task is calculated using the formula est_bw = requested_frequency × packet_size. For example, a task with a request frequency of 100Hz has an estimated bandwidth consumption of 100 × 1024 = 102,400 bps. This value is added to the total_bw_consumed variable, and the total_session_consumed variable is incremented by 1, indicating that the task will occupy one measurement session resource.

[0092] In a preferred embodiment, during the traversal process, the estimated bandwidth consumption and session consumption values ​​of each task are recorded in a newly added field in the task data structure for detailed querying in subsequent steps. After traversing the task set T_l, two cumulative values ​​for the link are obtained: total_bw_consumed represents the total probe bandwidth required if all tasks on the link run at their requested frequency; total_session_consumed represents the total number of measurement sessions that need to be established on the link. These two cumulative values ​​are stored in association with the link identifier as a snapshot of the link's resource requirements. This resource requirement snapshot will serve as the basis for comparison with the link capacity vector in the next step.

[0093] S2.3: Compare the total bandwidth consumption value and the total session consumption value with the corresponding components in the predefined link measurement resource capacity vector. When any component exceeds the limit, it is determined that there is a resource conflict on the link, and the task set of the link is recorded as a conflict task list.

[0094] In this embodiment, the process is executed after the cumulative calculation of resource consumption is completed. It is responsible for comparing the estimated resource demand of each link with its capacity limit to detect whether there is a conflict of exceeding the resource limit.

[0095] Specifically, a link measurement resource capacity vector C_l is predefined for each physical link. This capacity vector is a data structure containing multiple components, each representing the upper limit of measurement resources that the link can carry in a certain dimension. For example, the capacity vector contains the following four core components: the first component is C_bw, which is the upper limit of bandwidth that can be used for active measurement. Its value is usually set as a fixed proportion of the total physical bandwidth of the link. For example, for a 10Gbps link, if the proportion is set to 2%, then the value of C_bw is 200,000,000 bps; the second component is C_cpu, which is the CPU cycle quota that the link source device can allocate to the measurement protocol daemon, expressed as a percentage, such as 5%; the third component is C_session, which is the maximum number of concurrent measurement sessions that can be supported between the two devices of the link. This value is limited by the device's memory capacity and software license limitations, such as 100; the fourth component is C_flowtable, which is the upper limit of data plane flow table entries that can be occupied when using in-band telemetry mode, such as 500 entries. The specific values ​​of these capacity components are pre-configured by the network administrator based on device performance and operation and maintenance policies, and stored in the controller's device management database.

[0096] Further, the calculated total bandwidth consumption value (total_bw_consumed) and total session consumption value (total_session_consumed) for each link are read. The total_bw_consumed value for that link is compared with the C_bw component in the capacity vector, and the total_session_consumed value is compared with the C_session component. For example, suppose that on link "L12", the calculated total_session_consumed value is 200, while the C_session component for that link is 100. During the comparison operation, it is found that total_session_consumed (200) > C_session (100), that is, the total session consumption value exceeds the capacity limit. In this case, it is determined that there is a resource conflict on link "L12".

[0097] According to one aspect of this application, when a resource conflict is determined to exist in a certain link, all atomic measurement task data structures in the task set T_l corresponding to that link are recorded as a conflict task list. This conflict task list not only contains references to the task data structures but also includes detailed metadata about the conflict, including: the conflict link identifier, the name of the component exceeding the limit, the capacity limit, the actual demand value, and the over-limit ratio. A batch identifier is assigned to this conflict task list, and the entire list is passed to the conflict resolution module in the next sub-step for processing. For all links where no component exceeds the limit after comparison, the tasks in their corresponding task set are directly marked as conflict-free and can directly enter the permitted execution list without going through the subsequent conflict resolution process.

[0098] S2.4: Sort the conflict task list in descending order by the parent intent priority field, perform task-by-task admission control to form an allowed execution list and a pending list, optimize the frequency of tasks with the same priority in the pending list with the goal of maximizing total utility, move the optimized tasks into the allowed execution list, and output the allowed execution list as a list of conflict-free atomic tasks to be executed.

[0099] In this embodiment, the task is executed after a resource conflict is detected. It is responsible for performing hierarchical resolution of tasks in the conflict task list and finally outputs an optimized and resource-conflict-free atomic task execution list.

[0100] Specifically, firstly, all atomic measurement task data structures in the conflict task list are sorted in descending order according to the value of their `parent_priority` field. This sorting operation places tasks with higher priority values ​​(e.g., priority 10) at the front of the list and tasks with lower priority values ​​(e.g., priority 1) at the back. After sorting, two empty lists are initialized: `Admitted_List` to store tasks that are allowed to be executed, and `Pending_List` to store tasks that cannot be accepted temporarily. Simultaneously, the resource accumulator variable for this link is reinitialized, setting all its values ​​to zero.

[0101] Further, a task-by-task admission control process is executed. Each task is retrieved from the conflict task list in the sorted order and processed sequentially. For the currently processed task, it is checked whether adding the task to the Admitted_List would cause the estimated bandwidth consumption and session consumption to exceed the limit of any component of the capacity vector. For example, assuming the remaining available capacity of C_bw is 50Mbps and the estimated bandwidth consumption of the current task is 1Mbps, adding it will not exceed the limit. If the check indicates that it will not exceed the upper limit of any component, the task is added to the Admitted_List, and the resource accumulator is updated, adding its estimated bandwidth consumption and session consumption to the accumulator. If the check indicates that adding it would cause any component to exceed the limit, the task is moved to the Pending_List and resources are temporarily withheld.

[0102] In a preferred embodiment, after the per-task admission control process is completed, the Pending_List may contain multiple tasks with different priorities. A subset of tasks with the same highest parent intent priority field value is selected from the Pending_List. For this subset, a multi-objective optimization model is constructed and solved, with the objective function of maximizing the total measurement utility of all tasks and the constraint of the remaining available bandwidth of the link. For example, assume the remaining bandwidth can only support a total probe frequency of 200Hz, and three tasks in the subset each request 100Hz. The solution assigns an optimized execution frequency to each task, and this frequency value is written to the allocated_frequency field of each task. After the solution is completed, these tasks are moved from the Pending_List to the Admitted_List.

[0103] Furthermore, the Admitted_List is output as the final conflict-free list of atomic task executions. Each atomic task in this list contains a finalized allocated_frequency field and execution_status field, which guide the specific protocol selection and configuration generation.

[0104] According to another aspect of this application, such as Figure 4 As shown, the topology change level is determined, including:

[0105] S3.1: Receive link state advertisement update messages via the BGP-LS protocol, extract node attributes and link attributes from the update messages, and construct a dynamic network attribute graph containing node feature vectors and edge feature vectors.

[0106] Specifically, the topology-aware module of the SDN controller operates as a client of a BGP-LS route reflector, establishing BGP peer sessions with border routers or route reflectors within the autonomous system. Upon session establishment, this module sends a subscription request for a BGP-LS address family to the peer, declaring its ability to receive link-state network layer reachability information. Whenever an interior gateway protocol neighbor state changes or link attributes are updated, the upstream router constructs a BGP-LS update message and pushes it to the controller through the established BGP session. For example, a typical link NLRI update message contains the following extractable information: the local_router_id field value is "192.0.2.1", the remote_router_id field value is "192.0.2.2", the local_ipv4 field value is "10.10.10.1", the remote_ipv4 field value is "10.10.10.2", the max_link_bw field value is "1000000000" (in bps), the igp_metric field value is "10", and the admin_group field value is "0x00000001".

[0107] Furthermore, the decoder corresponding to the BGP-LS address family is invoked to parse the received update message, extracting two types of information: node attributes and link attributes. Node attributes include router identifier, autonomous system number, area identifier, and the sRGB range supported by the device; link attributes include the IP addresses of the interfaces at both ends of the link, maximum link bandwidth, maximum reservable bandwidth, IGP metric value, traffic engineering metric value, and link color attribute. Using this extracted attribute data, a dynamic network attribute graph G in memory is dynamically maintained. Whenever a BGP-LS update message arrives, an incremental update operation is performed on this attribute graph, adding new nodes or edges, deleting invalid nodes or edges, or updating the feature vector values ​​of existing nodes and edges. The updated dynamic network attribute graph will serve as the direct input to the graph neural network model in the next sub-step.

[0108] S3.2: Input the dynamic network attribute graph at the current sampling time into the pre-trained graph convolutional network model, and output the current topology embedding vector after multi-layer graph convolution and global average pooling.

[0109] This embodiment is executed after the dynamic network attribute graph is updated. It is responsible for using a graph neural network model to compress the high-dimensional graph structure data into a low-dimensional topological embedding vector, so as to facilitate subsequent quantitative comparison of topological similarity.

[0110] Specifically, upon detecting a change in the dynamic network attribute graph, a delayed trigger timer is started to avoid unnecessary repetitive calculations due to frequent IGP oscillations. For example, the delay duration of this timer is set to 5 seconds. After the timer expires, the system uses the dynamic network attribute graph G_t at the current sampling time t as input data and feeds it into a pre-trained graph convolutional network model for forward inference calculation.

[0111] Furthermore, this graph convolutional network model employs a stacked structure of three graph convolutional layers. For example, the first two layers use the ReLU activation function, and the third layer uses a linear activation function. Input data first flows through the first graph convolutional layer, mapping the original node features from the input dimension (e.g., 16 dimensions) to the first hidden layer dimension (e.g., 64 dimensions); the second graph convolutional layer further maps the feature dimensions to the second hidden layer dimension (e.g., 128 dimensions); and the third graph convolutional layer outputs the final node embedding vector.

[0112] In a preferred embodiment, after completing the three-layer graph convolution operation to obtain the final layer embedding vectors of all nodes in the graph, a global average pooling operation is performed on the embedding vectors of all nodes. This operation calculates the arithmetic mean of all node values ​​in each feature dimension, thereby aggregating the graph structure of arbitrary size into a vector of fixed dimension. For example, if each node embedding vector output by the third layer is 128-dimensional, then after global average pooling, regardless of whether the graph contains 5 nodes or 500 nodes, a 128-dimensional vector z_t will be output. A specific numerical example of this vector is: [0.123, -0.456, 0.789, ..., 0.234]. This vector z_t is defined as the current topology embedding vector at the current sampling time. It captures the connection patterns, hierarchical structure, and link weight distribution characteristics of the network topology, which is equivalent to a compact digital fingerprint of the current network state.

[0113] S3.3: Read the baseline topology embedding vector corresponding to the most recent successful configuration distribution time from the configuration management library, and calculate the cosine distance between the current topology embedding vector and the baseline topology embedding vector.

[0114] This embodiment executes after obtaining the current topology embedding vector, and is responsible for comparing it with the historical baseline state to quantify the cumulative changes in the network topology since the last configuration was issued.

[0115] Specifically, the configuration management repository persistently stores a series of state snapshots associated with measurement configuration distribution operations. One key piece of data is the baseline topology embedding vector z_base, which records the network topology embedding vector at the moment of the most recent successful completion of a full-network or regional measurement configuration distribution. By querying the configuration management repository for records with the operation type of successful configuration distribution and the latest timestamp, the baseline topology embedding vector value stored in that record is retrieved. For example, the value of this baseline topology embedding vector is: [0.119, -0.461, 0.782, ..., 0.229].

[0116] Furthermore, the calculated current topology embedding vector z_t and the read baseline topology embedding vector z_base are used to perform distance metric calculation. In a preferred embodiment, cosine distance is used as the distance metric, and the theoretical range of the distance value is between 0 and 2: a value of 0 indicates that the two vectors have the same direction, that is, the structural features of the two topology snapshots are highly consistent; the closer the value is to 2, the greater the difference in the direction of the two vectors, that is, the more significant the change in the topology structure.

[0117] For example, assuming z_t is [0.123, -0.456, 0.789] and z_base is [0.119, -0.461, 0.782], the calculated cosine distance value d = 0.003. This value indicates that the network topology has changed only very slightly since the baseline time. The calculated cosine distance value is stored in memory as a scalar floating-point number, and this distance value will serve as the sole numerical basis for determining the level of topology change in the next step.

[0118] S3.4: Compare the cosine distance value with the preset low threshold and high threshold. If it is less than the low threshold, it is determined to be a stable state. If it is between the low threshold and the high threshold, it is determined to be a local change and the affected entity set is marked. If it is greater than or equal to the high threshold, it is determined to be a structural mutation and the entire network is reconfigured.

[0119] In this embodiment, the distance value is compared with a preset threshold to divide the degree of topology change into three discrete levels, and a corresponding configuration trigger decision is generated for each level.

[0120] Specifically, two threshold parameters are predefined in the configuration file: a low threshold θ_low and a high threshold θ_high. For example, after calibration in a test environment simulating various typical network fault scenarios, the low threshold is set to 0.05, and the high threshold is set to 0.25. The cosine distance value d obtained from the sub-calculation is then compared successively with these two thresholds.

[0121] Furthermore, the comparison process and corresponding judgment results are divided into the following three scenarios:

[0122] Scenario 1: When d < θ_low (i.e., d < 0.05), the topology change level is determined to be a stable state. This scenario typically corresponds to events such as minor adjustments to the link IGP metric, immediate recovery after a momentary interruption of a single edge access link, or a small change in link bandwidth attributes. Based on this stable state determination, a decision signal that does not require reconfiguration is generated. This decision signal will suppress the initiation of the configuration generation and distribution process in subsequent step S4, thereby avoiding unnecessary network-wide configuration oscillations triggered by minor, unstructured network fluctuations.

[0123] Scenario 2: When θ_low ≤ d < θ_high (i.e., 0.05 ≤ d < 0.2), the topology change level is determined to be a locally significant change. This scenario typically corresponds to events such as a partial failure of a member link in a port aggregation, a temporary offline state of an aggregation layer router due to a reboot, or the addition of a new access layer link. Under this determination, a change tracing submodule is activated. This module accurately identifies the changed node and edge objects by structurally comparing the current dynamic network attribute graph G_t with the attribute graph G_base at the baseline. These changed node and link identifiers are then aggregated into a set and marked as the affected entity set.

[0124] Scenario 3: When d ≥ θ_high (i.e., d ≥ 0.2), the topology change level is determined to be a structural abrupt change. This scenario typically indicates a major network event such as a core layer router failure, a fiber optic backbone link interruption leading to a large-scale network topology reconfiguration, or a change in the autonomous system boundary router. Based on this structural abrupt change determination, a command is generated to mark the entire network as reconfigurable. This command includes all nodes and links within the current network topology range into the reconfiguration area. The above three determination results and their corresponding decision signals will be passed as key input parameters to step S4 to determine the precise scope of subsequent configuration generation and distribution.

[0125] According to another aspect of this application, such as Figure 5 As shown, the generation of protocol configuration payloads and their incremental distribution to network devices includes:

[0126] S4.1: When the adaptive selection result is active measurement mode, extract the source endpoint IP field and destination endpoint IP field of the atomic task, compare the two IP addresses as unsigned integers, determine the smaller one as the sender role and the larger one as the reflector role, extract the corresponding port information to fill the active measurement configuration template, and generate the active measurement configuration payload.

[0127] Specifically, the first step is to examine the measurement mode decision result field generated by the policy selector for the current atomic task. When the value of this field is "TWAMP" or "TWAMP-Light", the active measurement configuration generator module is invoked for further processing. The generator extracts two key IP address fields from the atomic task data structure: the src_endpoint_ip field and the dst_endpoint_ip field. For example, the extracted values ​​are "10.10.10.1" and "10.10.10.2" respectively.

[0128] Further, in order to ensure that only one set of two-way measurement sessions is configured on one physical link and avoid repeated configuration caused by two directions of the link, a source-end and destination-end role determination algorithm is performed. The algorithm converts the two extracted IP address strings into 32-bit (for IPv4) or 128-bit (for IPv6) unsigned integer representations respectively. Illustratively, the IPv4 address "10.10.10.1" is converted to an integer of 168427521, and "10.10.10.2" is converted to an integer of 168427522. A numerical comparison is performed on these two integer values. The comparison rule is: the IP address with a smaller value is determined as the sender role, and the IP address with a larger value is determined as the reflector role. In the above example, since 168427521 <1684275>22, "10.10.10.1" is determined as the sender, and "10.10.10.2" is determined as the reflector.

[0129] In a preferred embodiment, after the roles are determined, a query request is initiated to the device management database to obtain port information corresponding to the above roles. The query request carries the sender IP address and the reflector IP address as query conditions. The device management database returns the corresponding interface configuration information, from which the sender port number and the reflector port number are extracted. Illustratively, the query result shows that the sender port number is "2001" and the reflector port number is "2010".

[0130] Further, an active measurement configuration template corresponding to the target device vendor and software version is read from the configuration template library. For example, a configuration template fragment for the TWAMP-Light protocol is: "test-session: {{SESSION_ID}}; sender-ip: {{SENDER_IP}}; reflector-ip: {{REFLECTOR_IP}}; sender-port: {{SENDER_PORT}}; reflector-port: {{REFLECTOR_PORT}}; frequency: {{FREQUENCY}}". Parameter population is performed: {{SESSION_ID}} is replaced with a globally unique session ID on the sender node; {{SENDER_IP}} and {{REFLECTOR_IP}} are replaced with the IP addresses of the sender and reflector, respectively; {{SENDER_PORT}} and {{REFLECTOR_PORT}} are replaced with the corresponding port numbers; and {{FREQUENCY}} is replaced with the allocated_frequency field value of the atomic task. After the data is populated, a complete sender configuration text is generated. Simultaneously, using the reflector as the configuration target, a corresponding responder configuration text is generated from the reflector template. The sender and reflector configuration texts are then merged and encapsulated into an active measurement configuration payload data structure.

[0131] S4.2: When the adaptive selection result is in-band telemetry mode, according to the switch node sequence of the path to which the atomic task belongs, generate matching action entries for each hop switch in the in-band telemetry template, configure the sampling rate parameter, and generate in-band telemetry configuration payload.

[0132] In this embodiment, the system is responsible for generating the corresponding in-band telemetry protocol configuration payload when the decision result is in-band telemetry mode.

[0133] Specifically, the measurement mode decision result field generated by the policy selector for the current atomic task is checked. When the value of this field is "INT", the in-band telemetry configuration generator module is called for subsequent processing. The generator first queries the set of physical entities stored in the SpatialScope field of the parent intent associated with the atomic task, based on the parent_intent_id. The complete sequence of switch nodes traversed by the service flow is extracted from this set. For example, the extracted node sequence is: [Node_S1, Node_S2, Node_S3], with the corresponding switch identifiers "S1", "S2", and "S3" respectively.

[0134] Furthermore, a predefined in-band telemetry template is read from the P4 program template library. This template is a P4 source code file containing INT header definitions and a Match-Action pipeline skeleton. Placeholders for dynamically generated pipeline entries are reserved in the template. Each hop switch in the switch node sequence is traversed, and a matching action entry is dynamically generated for each hop switch.

[0135] For example, for the first-hop switch S1 (INT Source) on the path, an entry is generated with the matching key being the five-tuple information of the service flow. The action is to call the `int_source` action, which generates a new INT header and inserts it into the data packet, while also writing the switch ID, ingress port number, and timestamp of this hop into the header. For the intermediate-hop switch S2 (INT Transit), an entry is generated with the matching key also being the service flow five-tuple. The action is to call the `int_transit` action, which appends the switch ID, ingress port, egress port, and timestamp information of this hop to the existing INT header stack. For the last-hop switch S3 (INT Sink), an entry is generated with the action of calling the `int_sink` action, which strips the complete INT header from the data packet and encapsulates it into an INT Report message, which is then sent to the specified address of the controller.

[0136] In a preferred embodiment, the sampling rate parameter for INT is also configured based on the allocated_frequency field of the atomic task. For example, if the allocated frequency is 100Hz and the packet arrival rate of the traffic flow is approximately 10000pps, the sampling rate can be configured to perform an INT insertion operation once every 100 packets processed. This sampling rate parameter is implemented by adjusting the counter threshold in the Match-Action entry. Finally, the generated P4 source code file and runtime flow table configuration file are merged and encapsulated into an in-band telemetry configuration payload data structure.

[0137] S4.3: Calculate the difference between the configuration payload and the current running configuration of the device to obtain the incremental configuration. For cross-device associated configurations, a two-phase commit method is used to send the incremental configuration to the network device.

[0138] In this embodiment, the newly generated configuration is efficiently and reliably distributed to the target network device while minimizing the impact on the device's operating status.

[0139] Specifically, after receiving the generated protocol configuration payload, the southbound configuration agent module first determines the target device list for the configuration payload. For active measurement configuration payloads, the target devices typically include both the sending and reflecting devices; for in-band telemetry configuration payloads, the target devices are all switch nodes along the path.

[0140] Furthermore, a difference calculation operation is performed for each target device. A memory image copy of the current running configuration for each managed device is maintained. The newly generated configuration payload text is compared line by line with the device's current running configuration text. For example, if for device R1, the new configuration only changes the frequency parameter of test-session 5 from 50 to 25, the calculated difference increment is only the text block containing these two lines of change, rather than redistributing the entire TWAMP configuration block. The calculated difference increment is encapsulated in a NETCONF-compliant container. <edit-config>In the remote procedure call message.

[0141] According to one aspect of this application, for ordinary single-device configuration changes, the change can be made directly through an established NETCONF session. <edit-config>The message is sent to the target device, which then performs the configuration change and returns a response.

[0142] In a preferred embodiment, a two-phase commit protocol is used for cross-device associated configuration changes to ensure the consistency of the distributed configuration state. The first phase is the preparation phase: simultaneously sending a command carrying the configuration changes to all devices involved in the configuration change. <test-option> test-then-set< / test-option> Ability <edit-config>The request instructs the device to perform syntax and semantic validation of the configuration locally and reserve necessary resources, but does not activate the configuration to make it effective. A preset timeout timer is set, and responses are awaited from all participating devices. The second phase is the commit phase: The device commits if and only if responses indicating successful validation are received from all participating devices within the timeout period. <ok / > "Only after the response is received will a second RPC call be sent to all participating devices." <commit>Upon receiving this instruction, the device officially activates the configuration reserved during the preparation phase, and the measurement session begins. If any device returns an error response (e.g., port already in use) or times out during the preparation phase, an error message will be immediately sent to all devices participating in the preparation phase. <discard-changes>The instruction notifies them to discard the prepared configuration changes, thereby suspending the current distribution operation and ensuring that there is no inconsistency where some devices have configurations that have taken effect while others have not.

[0143] According to another aspect of this application, such as Figure 6 As shown, a fused network quality view is generated, including:

[0144] S5.1: Receive active measurement and reporting data, parse the sender IP field, reflector IP field, and performance indicators from the active measurement and reporting data, look up the first link identifier in the topology database using the sender IP and reflector IP as composite keys, and write the performance indicators, the first link identifier, and the reporting timestamp together into the time series database.

[0145] Specifically, a high-performance telemetry data collection server based on the gRPC / HTTP2 protocol stack is deployed in the northbound interface area of ​​the SDN controller. This server listens on a designated port and has subscribed to the data paths under its TWAMP or TWAMP-Light YANG model from all router devices participating in active measurements. During session execution, the measurement clients and servers on the router devices periodically push statistical information to this collection server via the Telemetry protocol's Dial-Out mode according to the configured reporting cycle.

[0146] Furthermore, after receiving the pushed data packet, the server first calls the corresponding decoder based on the data packet's encoding type. For example, if the data uses GPB encoding, the corresponding protobuf decoder is called; if it uses JSON encoding, the JSON parser is called. The decoder extracts the following key fields from the raw data stream: the `node_id_str` field, whose value is the device identifier that sent the reported data; the `subscription_id_str` field, whose value is the subscription identifier; the `sensor_path` field, whose value is the YANG path of the data source; the `msg_timestamp` field, whose value is the timestamp of the message's generation; and the `content` substructure, which contains specific measurement statistics. Further extraction from the `content` substructure includes: the `test-session-id` field, the `sender-ip` field, the `reflector-ip` field, the `sender-port` field, the `reflector-port` field, the `delay_stats` substructure, the `jitter_stats` substructure, and the `loss_stats` substructure.

[0147] In a preferred embodiment, the extracted sender-ip field value and reflector-ip field value are combined into a composite key. For example, the string representation of this composite key is "10.10.10.1-10.10.10.2". Using this composite key as the query condition, a reverse lookup operation is performed in the topology database in the controller's memory. The topology database maintains a mapping index from interface IP address pairs to physical link identifiers. The query operation returns the first link identifier uniquely corresponding to the IP address pair. For example, the returned link identifier is "L12".

[0148] Furthermore, the parsed performance metrics data—including the minimum, maximum, and average latency values ​​and standard deviation from `delay_stats`, the average jitter value from `jitter_stats`, and the packet loss percentage from `loss_stats`—are correlated with the first link identifier obtained from the query and the `msg_timestamp` timestamp from the reported message. This correlated data is then written as a time-series record to the controller's time-series database. This time-series database can use storage engines specifically optimized for time-series data, such as InfluxDB or Prometheus. After writing, this record can be used by upper-layer applications to query the macroscopic link quality change trend of a specified link within a specific time range.

[0149] S5.2: Receive in-band telemetry reporting data, parse the hop-by-hop information list and outgoing port field from the in-band telemetry reporting data, find the second link identifier in the topology database based on the outgoing port field, associate the hop-by-hop information list with the second link identifier and the reporting timestamp, and write it into the time series database.

[0150] Specifically, the controller's in-band telemetry analysis engine listens on a pre-agreed UDP port, waiting for INT Report packets sent by the data plane switch. Upon receiving a packet containing an INT header, the last-hop switch on the path strips all INT headers, encapsulates it into an INT Report packet, sets its destination address to the controller's IP address and the listening port, and forwards it to the controller via the data plane network.

[0151] Furthermore, after receiving the INT Report message, the analysis engine, according to... P4.org The defined INT v2.1 standardized format specification parses the packet. The parsing process extracts the following from the packet payload sequentially: flow identification information, including source IP address, destination IP address, source port number, destination port number, and protocol number; these fields together constitute the five-tuple identifier of the service flow; and a hop-by-hop information list. For example, for a packet that has passed through three switches, its hop-by-hop information list contains three elements. The first element corresponds to the first-hop switch and contains the fields: switch_id = "S1", ingress_port = 1, egress_port = 2, hop_latency_ns = 1200, and queue_depth = 5. The second element corresponds to the second-hop switch and contains the fields: switch_id = "S2", ingress_port = 1, egress_port = 3, hop_latency_ns = 3500, and queue_depth = 24. The third element corresponds to the third-hop switch and contains the following fields: switch_id is "S3", ingress_port is 2, egress_port is 4, hop_latency_ns is 800, and queue_depth is 2.

[0152] According to one aspect of this application, the `egress_port` field value of each hop element in the hop-by-hop information list is extracted. For each `egress_port`, a query is initiated to the topology database in conjunction with the `switch_id` field of that hop. The topology database stores the mapping relationship between switch ports and physical link identifiers. The query condition is a tuple of `(switch_id, egress_port)`, and the query returns the identifier of the second link connected to that outgoing port. For example, for outgoing port 3 of switch S2, the link identifier returned by the query is "L23". The parsed complete telemetry information of that hop (including `hop_latency_ns` and `queue_depth`, etc.) is associated with the queried second link identifier, the service flow 5-tuple, and the received timestamp of the Report message. This set of associated microstate data is written as a record to the time-series database.

[0153] S5.3: In response to a diagnostic query request, extract the target flow identifier and the query time range, retrieve the macro indicators of the first link identifier and the micro data of the second link identifier corresponding to the target flow identifier within the query time range, associate the macro indicators with the micro data, and generate a fusion diagnostic record.

[0154] In this embodiment, after accumulating two types of data, active measurement and in-band telemetry, in the time series database, it is responsible for responding to the diagnostic query request from the upper layer, associating and fusing macroscopic indicators with microscopic data, and generating diagnostic records with root cause analysis capabilities.

[0155] Specifically, the data fusion and root cause analysis module provides a query interface. This interface receives diagnostic query requests from the WEBUI or northbound applications. For example, a typical query request includes the following parameters: target_flow_label is the target business flow identifier, such as "agv_control_flow"; time_range is the query time range, such as the start and end timestamps.

[0156] Further, the query request is first parsed to extract the target flow identifier and the query time range. Using the target flow identifier as a filter, all in-band telemetry reporting records corresponding to the service flow are retrieved from the time-series database within the query time range. The retrieved telemetry data for each hop are sorted by time, and the statistical characteristics of the hop_latency_ns and queue_depth metrics for each hop are analyzed. For example, the average and standard deviation of the latency for each hop are calculated, and abnormal hops are identified where hop_latency_ns exceeds the average by three standard deviations or queue_depth exceeds a preset threshold. Suppose the analysis results show that the hop_latency_ns value of switch S2 is significantly higher than other hops, and its queue_depth value reaches 24 (far higher than the normal value of less than 5), then switch S2 is identified as an abnormal hop, and the associated second link identifier, such as "L23", is extracted from its corresponding telemetry record.

[0157] In a preferred embodiment, the extracted second link identifier "L23" is used as the new search key. Within the same query time range, the active measurement macro-indicator records corresponding to this link identifier are retrieved from the time-series database. The retrieval returns time-series data such as average latency, jitter, and packet loss rate for this link within the query time window. The macro-level phenomena of increased latency and packet loss rate provided by active measurement are correlated and combined with the micro-level root causes of queue depth accumulation at the S2 outgoing port provided by in-band telemetry to generate a structured converged diagnostic record. This record includes: a phenomenon description field ("The end-to-end latency of the service flow agv_control_flow increased from an average of 1.2ms to 5.5ms"), a root cause location field ("The bottleneck is link L23 between switch S2 and switch S3, caused by queue congestion at the S2 outgoing port, with a queue depth of 24"), and supporting data fields (attached with time-series chart data references for macro and micro indicators). This converged diagnostic record, as the final output of the converged network quality view, provides network operators with a complete analysis chain from phenomenon to root cause.

[0158] According to another aspect of this application, such as Figure 7 As shown, the adaptive adjustment action is triggered and the baseline state parameters are updated, including:

[0159] S6.1: Extract the probe traffic rate of each measurement session from the converged network quality view at preset evaluation cycles, accumulate it according to the link identifier, divide it by the corresponding link physical bandwidth, and obtain the measurement bandwidth overhead ratio parameter.

[0160] Specifically, the overhead controller module runs continuously as a background daemon, and its activation frequency is controlled by a configurable preset evaluation period parameter. For example, the default value for this evaluation period is set to 30 seconds. Whenever the timer reaches the preset period, the controller triggers an overhead evaluation task. The controller first accesses the converged network quality view, whose data is actually stored in the time-series database. The controller initiates an aggregation query request to the time-series database, the goal of which is to obtain the probe traffic rate information for all active measurement sessions currently in an "active" state.

[0161] Furthermore, the time-series database stores the configuration parameters and real-time statistics corresponding to each active measurement session. For each active session, its configuration parameters include a `packet_size` field and a `frequency` field. The `packet_size` field records the length of the probe packets used in this session; for example, a standard TWAMP-Light latency probe packet is 128 bytes (i.e., 1024 bits). The `frequency` field records the current probe packet transmission frequency of this session; for example, this value is 100Hz. The average probe traffic rate of this session is calculated using the formula `session_bw = packet_size × frequency`. For example, the rate corresponding to 128 bytes and 100Hz is 128 × 8 × 100 = 102,400 bps. The calculated probe traffic rate value for each session is extracted, along with the `link_id` field associated with that session.

[0162] In a preferred embodiment, the extracted data is grouped and aggregated by the `link_id` field. Using `link_id` as the grouping key, the probe traffic rate values ​​of all sessions belonging to the same physical link are summed to obtain the total active probe traffic rate on each link. For example, for a link identified as "L12" running three TWAMP sessions with rates of 102,400 bps, 51,200 bps, and 25,600 bps respectively, the summed total probe traffic rate is 179,200 bps. Subsequently, the physical bandwidth parameter of the link is read from the device management database. This parameter, pre-configured by the network administrator, reflects the link's maximum transmission capacity. For example, the physical bandwidth of link L12 is 1 Gbps, or 1,000,000,000 bps. The total probe traffic rate is divided by the physical bandwidth parameter to obtain the measured bandwidth overhead percentage parameter for that link. For example, 179,200 / 1,000,000,000 = 0.0001792, which is 0.01792% as a percentage. This cost percentage parameter is associated with the link identifier and stored in memory as input data for threshold comparison in the next step.

[0163] S6.2: Compare the measured bandwidth overhead ratio parameter with the preset bandwidth alarm threshold. When the preset bandwidth alarm threshold is exceeded, query all atomic tasks running on the link, sort them in ascending order of priority, filter the task with the lowest priority according to the preset ratio, reduce the allocation frequency of the filtered task according to the preset ratio, and generate and distribute the frequency reduction configuration.

[0164] In this embodiment, the parameter is compared with a preset threshold, and a refined measurement frequency degradation operation is automatically triggered when the overhead exceeds the limit.

[0165] Specifically, a preset bandwidth alarm threshold parameter is predefined in the configuration file. For example, this threshold is set to 2.0%, meaning that when the measured traffic on a certain link exceeds two percent of the total bandwidth of that link, the measured overhead is considered to have entered a range that needs to be controlled. The calculated measured bandwidth overhead percentage parameter for each link is then compared with this preset bandwidth alarm threshold.

[0166] Furthermore, when the measured bandwidth overhead ratio parameter of a certain link exceeds the preset bandwidth alarm threshold, an overhead overrun flag is generated, and a measurement frequency degradation process for that link is initiated. First, a query request is sent to the intent parsing and scheduling layer module, carrying the link_id of the overrunning link as the query condition. The intent parsing and scheduling layer module retrieves all atomic task records currently running on that link from its maintained task status database and returns a list of these tasks. For example, the returned task list contains 5 atomic tasks with parent_priority field values ​​of 10, 8, 8, 5, and 3, respectively.

[0167] In a preferred embodiment, the returned task list is sorted in ascending order by the value of the `parent_priority` field. Ascending order means that tasks with lower priority values ​​(i.e., low-priority tasks) are placed at the front of the list, and tasks with higher priority values ​​(i.e., high-priority tasks) are placed at the back. In the example above, the sorted order is: priority 3, priority 5, priority 8, priority 8, priority 10. Based on a preset percentage parameter, a subset of tasks from the front of the sorted list is selected as tasks to be de-emphasized. For example, this preset percentage is set to 20%. For a list containing 5 tasks, a 20% percentage means that 1 task (5 × 0.2 = 1), i.e., the task with priority 3, is selected.

[0168] Furthermore, for each selected task to be downgraded, its current allocated_frequency field value is read. Based on a preset reduction ratio parameter, the new frequency value after downgrading is calculated. For example, the preset reduction ratio is set to 50% (i.e., halved). If the original allocated frequency is 100Hz, the new frequency value after downgrading is 50Hz. The task's allocated_frequency field is updated to the new frequency value after downgrading, and the configuration generation and incremental distribution process in step S4 is invoked to update the downgraded frequency parameter to the corresponding router device. Because downgrading is only performed on low-priority tasks, the measurement accuracy and frequency of high-priority services are fully preserved, thereby controlling overall measurement overhead while ensuring priority protection for critical services.

[0169] S6.3: When a measurement session failure is detected from the converged network quality view and the current topology change level is in a stable state, perform a session reset; when the topology change level is a local change or a structural abrupt change, suppress the session reset and wait for the topology re-sensing to complete.

[0170] In this embodiment, the system is responsible for monitoring the health status of the measurement session and, when a session failure is detected, adopting a differentiated recovery strategy based on the current topology change level.

[0171] Specifically, the generated fused network quality view includes not only performance metric data but also metadata information for each measurement session, with a key piece of information being the timestamp of the latest data point for each session. The health monitoring module periodically scans the time-series database for all measurement session records that should be active. For each session, it reads the timestamp field of its latest data point and calculates the difference between it and the current system time. For example, the session reporting cycle is configured to be 10 seconds, and the system's failure judgment multiplier is set to 3. The difference between the current time and the timestamp of the latest data point is calculated. If the difference is greater than 30 seconds (10 seconds × 3), the measurement session is determined to be in a failed state, and a session failure identifier is generated.

[0172] Furthermore, upon detecting a session failure flag, the session reset operation is not executed immediately. Instead, the latest determined current topology change level is queried first. Based on the different topology change levels, a branch decision is executed.

[0173] Branch 1: If the current topology change level is stable. In this case, it is determined that the session failure was not caused by the underlying network topology change, but more likely by local causes such as transient software failures, configuration inconsistencies, or abnormal exits of the measurement protocol daemon. Therefore, a session reset command is generated. This command triggers a system call to the southbound configuration interface, sending two NETCONF operations sequentially to the corresponding router device: the first is... <delete-config>Or with the operation="delete" attribute <edit-config>The first line is used to delete the currently invalid measurement session configuration; the second line is for re-issuing. <edit-config>The content contains the complete original configuration of the session. This sequence of deletion and reconstruction attempts to restore the normal operation of the measurement session.

[0174] Branch 2: If the current topology change level is a localized significant change or a structural abrupt change, the session failure is likely due to an expected interruption caused by the underlying network topology undergoing a convergence process. If a session reset is prematurely executed at this point, it may fail not only due to the target device being unreachable or the path being blocked, but may also interfere with the normal execution of the topology re-awareness and reconfiguration process. Therefore, a reset suppression flag is generated. This flag will prevent the sending of session reset commands. The failed session is marked as awaiting topology convergence, and the execution status of steps S2 and S3 is continuously monitored. When step S3 completes new topology awareness and updates the topology change level, and step S2 completes the requirement decomposition and conflict resolution for the new topology, step S4 will generate a completely new measurement configuration based on the new topology state. The new configuration will naturally overwrite the old failed session, thus achieving a smooth recovery of the measurement task.

[0175] S6.4: After the adaptation action is executed, the current configuration version tag, the current topology embedding vector, and the updated resource occupancy registration table are written to the configuration and status database.

[0176] In this embodiment, the system is responsible for persistently updating the system baseline state after each successful adaptive adjustment action, thereby providing an accurate reference benchmark for the next round of evaluation and forming a complete control closed loop.

[0177] Specifically, regardless of whether it's a triggered measurement frequency degradation action, a triggered session reset action, or a resource preemption action triggered by a new intent, a unified baseline state update operation will be performed after each adaptation action is successfully executed and a confirmation response is received from the network device. First, a new configuration version tag is generated for all network devices affected by the adaptation action. For example, this tag uses the format "device identifier + timestamp + incrementing sequence number," such as "R1_20240421_153022_03," to uniquely identify the device's configuration snapshot after this change. This configuration version tag is then associated with the corresponding complete configuration payload and stored in the configuration management library for subsequent configuration auditing, rollback, or comparison operations.

[0178] Further, it is checked whether this adaptation action was triggered by a topology change event. If the cause of the adaptation action is a significant local change or a structural abrupt change, the current topology embedding vector z_t calculated at the current moment is read. The value of this vector is overwritten into the baseline topology embedding vector field stored in the configuration management library, making it the new baseline value. This update operation ensures that step S3 can use the latest stable topology as a comparison benchmark in the next round of topology change evaluation, thereby accurately quantifying the degree of subsequent cumulative changes.

[0179] In a preferred embodiment, the resource occupancy register is also updated. During the adaptation process, the atomic task allocation frequency on each link may change, and some tasks may be suspended or resumed, resulting in a change in the current occupancy of the measured resource capacity vector for each link. The total bandwidth consumption and total session consumption of each link are recalculated, and the updated values ​​are written to the resource occupancy register in the configuration and status database. This register will serve as the capacity baseline data when performing the next round of resource conflict detection in step S2. Through the baseline status updates in the above three dimensions—configuration version, topology embedding vector, and resource occupancy register—a complete state memory mechanism is built for the entire adaptive measurement configuration process, ensuring that each adaptation decision is based on the latest system state, forming a closed-loop feedback control loop of "measurement-evaluation-adaptation-update".

[0180] This invention introduces an intent-aware mechanism to achieve differentiated expression and precise configuration of measurement requirements in mixed service scenarios, significantly improving the service adaptability of network measurement systems. Existing technologies employ a "topology-driven, one-size-fits-all" configuration model, applying the same measurement strategy to all links in the network, failing to identify and differentiate the varying measurement requirements of different types of services. This invention innovatively proposes a six-tuple formal representation model of measurement intent, abstracting the network measurement needs of users or upper-layer applications into a structured description of six dimensions: objectives, indicators, constraints, priorities, and spatiotemporal range. An intent compiler translates declarative intent primitives into atomic measurement tasks that the system can understand, enabling the deterministic latency measurement requirements of an industrial robot control flow and the bandwidth measurement requirements of a video surveillance stream to be expressed and processed separately within the same system. Furthermore, this invention designs a conflict resolution mechanism based on a combination of priority and multi-objective optimization. When multiple service intents compete for measurement resources on the same physical link, the system can make hierarchical decisions based on service priorities and achieve fair allocation of measurement frequencies among tasks of the same priority through utility function optimization, ensuring that high-value services receive priority while maximizing overall measurement utility. This paradigm shift from "link-centric" to "intent-centric" enables network measurement systems to truly possess service-aware capabilities oriented towards business, greatly reducing the complexity of manually planning measurement strategies and improving the level of automation in network operations and maintenance.

[0181] This invention, by introducing graph neural network technology, achieves quantitative perception and differentiated configuration triggering of network topology changes, effectively reducing configuration update overhead and response latency in large-scale networks. Existing solutions employ a crude "full reconfiguration" approach to handling topology changes. Whether it's a brief interruption of an access link or a core node failure and reconfiguration, it triggers a network-wide regeneration and redistribution of measurement configurations, leading to wasted controller computing resources and congestion of southbound communication channels. This invention abstracts the network topology as a dynamic graph containing node and edge attributes. It embeds the high-dimensional topology structure into low-dimensional feature vectors using a graph convolutional network, and precisely quantifies the magnitude and nature of topology changes using the cosine distance between vectors. Based on this, the system subdivides topology changes into three levels: stationary state, local change, and structural mutation. For stationary changes such as fine-tuning of link metrics, the system does not trigger any reconfiguration action; for local changes such as restarting aggregation layer devices, the system only performs incremental updates on affected nodes and links; and large-scale configuration recalculation is only initiated when a core network reconfiguration occurs. Furthermore, this invention also constructs a topology prototype library based on historical embedding vector clustering. When a new topology is highly similar to a verified prototype, existing configuration templates can be quickly reused, further shortening the configuration generation time. This GNN-based intelligent sensing mechanism upgrades the measurement system's response to network dynamics from passive "post-event full processing" to proactive "pre-event quantitative prediction," significantly reducing the system's own operating overhead while ensuring measurement continuity.

[0182] This invention achieves a dynamic adaptive balance between measurement accuracy and resource consumption by constructing a complete feedback loop that includes hybrid measurement strategy selection, dual-channel data fusion, and closed-loop overhead control. In existing solutions, measurement strategies are fixed once configured and cannot be dynamically optimized according to changes in network load or service requirements, often resulting in a dilemma of "high accuracy accompanied by high overhead" or "low overhead sacrificing accuracy." This invention supports both active measurement and in-band telemetry in the data plane and designs a hybrid strategy selector that combines accuracy-driven and overhead-aware approaches. When services require nanosecond-level hop-by-hop latency, the system automatically enables in-band telemetry mode to leverage its high accuracy advantage; when network load climbs to the warning threshold, the system smoothly switches non-critical service measurement tasks from high-overhead in-band telemetry to lightweight active measurement mode, achieving adaptive degradation of measurement overhead. At the data acquisition end, this invention uses time alignment and spatial correlation techniques to deeply fuse the macroscopic link quality indicators provided by active measurement with the hop-by-hop microscopic state data provided by in-band telemetry, providing a complete chain of evidence from symptoms to root causes for network fault delimitation. More importantly, this invention designs a closed-loop feedback controller that periodically evaluates the measurement bandwidth ratio, device CPU utilization, and session validity. When excessive overhead is detected, it automatically selects a frequency reduction strategy that halves the execution frequency of low-priority tasks. When session failure is detected, it intelligently decides whether to reset the session or wait for topology convergence based on the topology status. This "measurement-evaluation-adjustment-remeasurement" closed-loop mechanism enables the system to continuously learn and optimize during operation, achieving a dynamic optimal match between measurement resource investment and business value return.

[0183] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention. < / commit> < / commit>

Claims

1. A dynamic adaptive configuration method for SDN network measurement oriented towards mixed services, characterized in that, include: Receive measurement intent input data and perform formal translation and semantic verification to generate a six-tuple intent descriptor; The six-tuple intent descriptor is decomposed into a requirement to generate an atomic measurement task set. The atomic measurement task set is compared with the link measurement resource capacity vector to detect the resource conflict task list. Conflict resolution is performed on the resource conflict task list, and a list of conflict-free atomic task execution is output. The embedding vector of the current network topology is calculated based on the graph neural network to obtain the current topology embedding vector. The distance between the current topology embedding vector and the baseline topology embedding vector is measured, and the topology change level is determined based on the measurement result. The configuration distribution range of the conflict-free atomic task execution list is determined based on the topology change level. Within the configuration distribution range, an adaptive selection is made between active measurement mode and in-band telemetry mode to generate protocol configuration payloads and distribute them to network devices in an incremental manner. Collect the first data stream reported by active measurement and the second data stream reported by in-band telemetry, perform time alignment and spatial correlation on the first and second data streams, and generate a fused network quality view; The measurement cost percentage parameter and health score parameter are calculated based on the fused network quality view. The measurement cost percentage parameter and health score parameter are compared with the preset threshold. Based on the comparison result, an adaptive adjustment action is triggered and the baseline status parameter is updated to complete the configuration.

2. The method according to claim 1, characterized in that, Generate a six-tuple intent descriptor, including: Receive multimodal intent input data and perform format standardization preprocessing to obtain standardized input text; The pre-defined intent primitive set is invoked to perform lexical and syntactic analysis on the standardized input text, and an abstract syntax tree is constructed. The abstract syntax tree includes a measurement target branch, an indicator set branch, a constraint condition branch, a priority branch, a time range branch, and a spatial range branch. Perform a depth-first traversal on the abstract syntax tree to perform semantic verification. After the verification passes, extract the content of the spatial range branch and parse it into a set of physical entities containing node objects and link objects. The information in each branch node of the abstract syntax tree and the physical entity set are extracted and recombined, compressed and encapsulated into a six-tuple intent descriptor, and then written into the intent state database after being assigned a globally unique identifier.

3. The method according to claim 2, characterized in that, Output a list of conflict-free atomic tasks to be executed, including: Traverse each six-tuple intent descriptor in the intent state database, read the physical entity set and indicator set of each six-tuple intent descriptor, perform a double loop traversal on each link in the physical entity set and each indicator in the indicator set, and generate an atomic measurement task data structure. The atomic measurement task data structure includes a link identifier field, a request precision field, a request frequency field, and a parent intent priority field. Group all atomic measurement task data structures by link identifier field to obtain the task set corresponding to each link. For each link, traverse its task set, calculate the estimated bandwidth consumption value based on the request frequency field of each task and the known probe message length, and sum them up to obtain the total bandwidth consumption value and the total session consumption value. The total bandwidth consumption value and the total session consumption value are compared with the corresponding components in the predefined link measurement resource capacity vector. When any component exceeds the limit, it is determined that there is a resource conflict on the link, and the task set of the link is recorded as a conflict task list. Sort the conflict task list in descending order by the parent intent priority field, perform task-by-task admission control to form an allowed execution list and a pending list, optimize the frequency of tasks with the same priority in the pending list with the goal of maximizing total utility, move the optimized tasks into the allowed execution list, and output the allowed execution list as a list of conflict-free atomic tasks to be executed.

4. The method according to claim 3, characterized in that, Determine the level of topological change, including: The link state advertisement update message is received through the BGP-LS protocol, and node attributes and link attributes are extracted from the update message to construct a dynamic network attribute graph containing node feature vectors and edge feature vectors. The dynamic network attribute graph at the current sampling time is input into the pre-trained graph convolutional network model, and the current topology embedding vector is output after multi-layer graph convolution and global average pooling. Read the baseline topology embedding vector corresponding to the most recent successful configuration distribution time from the configuration management library, and calculate the cosine distance between the current topology embedding vector and the baseline topology embedding vector; The cosine distance value is compared with a preset low threshold and a high threshold. If it is less than the low threshold, it is determined to be a stable state. If it is between the low threshold and the high threshold, it is determined to be a local change and the affected entity set is marked. If it is greater than or equal to the high threshold, it is determined to be a structural mutation and the entire network is reconfigured.

5. The method according to claim 4, characterized in that, Generate protocol configuration payloads and distribute them to network devices incrementally, including: When the adaptive selection result is active measurement mode, the source endpoint IP field and destination endpoint IP field of the atomic task are extracted, the two IP addresses are compared as unsigned integers, the smaller one is determined as the sender role, and the larger one is determined as the reflector role. The corresponding port information is extracted to fill the active measurement configuration template and generate the active measurement configuration payload. When the adaptive selection result is in-band telemetry mode, according to the switch node sequence of the path to which the atomic task belongs, a matching action table entry is generated for each hop switch in the in-band telemetry template, and the sampling rate parameter is configured to generate the in-band telemetry configuration payload. The incremental configuration is obtained by calculating the difference between the configuration payload and the current running configuration of the device. For cross-device related configurations, a two-phase commit method is used to send the incremental configuration to the network device.

6. The method according to claim 5, characterized in that, Adaptive selection between active measurement mode and in-band telemetry mode includes: Read the requested precision field of the atomic task, compare the requested precision field with the pre-stored measurement mode capability mapping table, and select the in-band telemetry mode when the active measurement capability limit is exceeded or hop-by-hop latency is required. When the active measurement capability limit is not exceeded, the link real-time load rate parameter is obtained. If the real-time load rate parameter is higher than the overhead protection threshold and the task priority is lower than the preset value, the active measurement mode is selected and marked as a degraded state. Otherwise, the active measurement mode will be selected by default.

7. The method according to claim 1, characterized in that, Generate a fused network quality view, including: Receive active measurement and reporting data, parse the sender IP field, reflector IP field, and performance indicators from the active measurement and reporting data, use the sender IP field and reflector IP field as composite keys to find the first link identifier in the topology database, associate the performance indicators with the first link identifier and the reporting timestamp, and write them into the time series database. Receive in-band telemetry reporting data, parse the hop-by-hop information list and outgoing port field from the in-band telemetry reporting data, find the second link identifier in the topology database based on the outgoing port field, and write the hop-by-hop information list, the second link identifier and the reporting timestamp into the time series database. In response to a diagnostic query request, the target flow identifier and query time range are extracted. Within the query time range, macroscopic indicators of the first link identifier and microscopic data of the second link identifier corresponding to the target flow identifier are retrieved. The macroscopic indicators and microscopic data are correlated to generate a fusion diagnostic record.

8. The method according to claim 7, characterized in that, Trigger adaptive adaptation actions and update baseline state parameters, including: The probe traffic rate of each measurement session is extracted from the converged network quality view at preset evaluation cycles, accumulated by link identifier and divided by the corresponding link physical bandwidth to obtain the measurement bandwidth overhead ratio parameter. The measured bandwidth overhead ratio parameter is compared with the preset bandwidth alarm threshold. When the preset bandwidth alarm threshold is exceeded, all atomic tasks running on the link are queried, sorted in ascending order of priority, and the task with the lowest priority of the preset ratio is selected. The allocation frequency of the selected task is reduced by the preset ratio, and the frequency reduction configuration is generated and distributed. When a measurement session failure is detected from the converged network quality view and the current topology change level is in a stable state, a session reset is performed; when the topology change level is a local change or a structural abrupt change, the session reset is suppressed and the process waits for topology re-awareness to complete. After the adaptation action is executed, the current configuration version tag, the current topology embedding vector, and the updated resource usage registration table are written to the configuration and status database.

9. The method according to claim 4, characterized in that, Before calculating the cosine distance between the current topology embedding vector and the baseline topology embedding vector, the following steps are also included: Input the current topology embedding vector into the vector index of the topology prototype library to perform nearest neighbor search, calculate the Euclidean distance with each cluster center, and determine the nearest cluster center; If the Euclidean distance is less than the preset similarity threshold, then the set of pre-validated measurement configuration templates associated with the cluster center is extracted, and the requirement decomposition step is skipped to directly enter the configuration generation step.

10. The method according to claim 3, characterized in that, The optimization frequency for tasks of the same priority in the processing list is calculated with the goal of maximizing total utility, including: For a subset of tasks in the pending list that have the same parent intent priority field value, construct an optimization model with the objective function of maximizing the total measurement utility of all tasks and the constraint of remaining available bandwidth. The optimal execution frequency for each task is obtained by solving the optimization model. After updating the allocation frequency field of each task to the optimal execution frequency, the task is moved to the allowed execution list. For tasks that cannot be moved to the permitted execution list after being solved, an asynchronous feedback message containing a partially satisfied status and a rollback suggestion is generated based on its parent intent identifier.

Images