Cloud-based voice call data analysis system

Abstract

This invention relates to the field of business signaling technology, specifically a cloud-based voice call data analysis system. The system includes: a signaling acquisition module, a stability assessment module, a dynamic compression module, an abnormal trajectory clustering module, and a cloud feature library module. In this invention, distributed nodes collect multi-dimensional parameters of the link and store them in time slices. Sliding difference calculations are used to calculate the rate difference of three consecutive hops, accurately identifying stable path segments. Mean compression filters the latency within segments to generate feature vectors and reduce redundancy. Cloud K-means integrates state duration, timeout rate, and retransmission counts to detect trajectory deviations and construct abnormal clustering labels. Time-series correlation storage and elastic architecture dynamically filter path segments to reduce invalid data processing. Mean compression reduces computational complexity, multi-dimensional clustering improves detection accuracy, time windows optimize the storage structure, sliding difference enhances fluctuation capture capabilities, and elastic storage improves the efficiency of massive data access, forming an end-to-end quality analysis closed loop.

Description

Technical Field

[0001] This invention relates to the field of service signaling technology, and in particular to a cloud-based voice call data analysis system. Background Technology

[0002] The field of service signaling technology encompasses various signaling technologies used to control communication processes in mobile communication networks. The core of this field involves establishing, maintaining, and releasing communication services such as voice, data, and SMS through network control channels, encompassing signaling interaction, call control, session management, and mobility management. Based on standardized communication protocols, this field ensures the normal operation and quality of service of the communication network by defining different message types and process mechanisms. In system architecture, service signaling coordinates the behavior between user equipment and the network, and is widely used in cellular networks, LTE, 5G, and other communication systems, working in conjunction with core network functions to achieve user state management, service access, and resource allocation.

[0003] The voice call data analysis system refers to a system for collecting and analyzing business signaling data related to voice calls in mobile communication networks. The technical aspects addressed by this patent include signaling flow extraction during call setup, analysis of call latency and call paths, and location of call failure causes. It extracts key call control data by classifying and processing call setup request signaling, call connection signaling, and release signaling generated in the network, combining timestamps and signaling parameters for ordered sorting and correlation mapping. Subsequently, the system classifies and statistically analyzes different types of call behaviors according to predefined analysis logic, and uses state transition rules to judge changes in call state, constructing call behavior sequences and link structures to achieve a structured expression of the call business process.

[0004] Traditional technologies rely on centralized signaling acquisition and static storage, which can easily lead to data loss and processing delays in high-concurrency scenarios. Path stability assessment uses fixed thresholds, which cannot distinguish between dynamic network fluctuations and persistent faults, resulting in a high false positive rate. Full signaling storage generates redundant data, interfering with the efficiency of feature extraction. Anomaly detection relies on single-dimensional statistics, failing to integrate the correlation of multiple indicators, and has weak capabilities for identifying complex fault modes. Static storage architectures cannot be elastically scaled, limiting the depth of historical data backtracking and trend analysis. For example, centralized acquisition leads to synchronization discrepancies between node hop count and latency data, full storage increases query latency, single-dimensional rule matching struggles to identify anomalies related to retransmissions and timeouts, and fixed storage capacity limits long-term data accumulation. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud computing-based voice call data analysis system.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a cloud computing-based voice call data analysis system includes:

[0007] The signaling acquisition module is used to obtain the number of node hops, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. After performing time window slicing, it stores the data in the cloud time series database, generates a cloud signaling time series dataset, and transmits it to the stability assessment module.

[0008] The stability assessment module is used to call the sliding window interpolation algorithm to calculate the difference of three consecutive hop transfer rates between the node hop count and the response delay in the cloud signaling time series dataset, mark the path segments that meet the threshold, generate path stability segment labels, and pass them to the dynamic compression module.

[0009] The dynamic compression module is used to filter path segments based on the path stability segmentation labels, perform distributed mean calculation on the response delay of all nodes in the segment, generate a cloud compression feature vector set, and transmit the cloud compression feature vector set and the cloud signaling time series dataset to the abnormal trajectory clustering module.

[0010] The abnormal trajectory clustering module is used to extract the state maintenance time, the timeout ratio, and the number of retransmissions. It performs trajectory offset detection using a distributed K-means algorithm based on a cloud platform, generates abnormal trajectory clustering labels, and transmits them to the cloud feature library module.

[0011] As a further embodiment of the present invention, the path stability segmentation label includes the difference in transfer rate of three consecutive hops, the segment that satisfies the rate difference threshold, and the path stability level identifier. The cloud compression feature vector set specifically refers to the filter path segment identifier, the distributed mean response delay, and the compression window delay distribution. The abnormal trajectory clustering label includes the offset trajectory cluster identifier, the state maintenance time offset, the timeout ratio cluster center, and the abnormal retransmission number threshold.

[0012] The distributed acquisition nodes deployed on the cloud platform work in conjunction with the sliding window interpolation algorithm to reduce network jitter interference and improve path selection accuracy.

[0013] The initial cluster centers of the cloud-based distributed K-means algorithm are 5 randomly selected sample points, and the convergence condition is that the center offset is less than 0.5%.

[0014] As a further aspect of the present invention, the signaling acquisition module includes:

[0015] The signaling acquisition submodule obtains the node hop count, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. It performs cross-regional clock synchronization calibration on the timestamps in the raw data, calculates the average of multiple indicators based on a sliding window and removes data points that deviate from the average by more than 3 times the standard deviation, calculates the correlation coefficient between node hop count and response latency, and generates a group of node performance indicators.

[0016] The data points that deviate from the mean by more than 3 times the standard deviation are determined based on statistical analysis of historical network jitter data.

[0017] The timing slicing submodule counts the number of node hops in segments according to the node performance index group and a fixed time window length. It uses the moving average method to eliminate instantaneous fluctuations in response latency and converts the timeout ratio and retransmission count into percentage values ​​based on the proportion of event triggers within the window to generate window timing parameters.

[0018] The moving average method uses a window length of 5 seconds and the weights are distributed with exponential decay.

[0019] The cloud storage submodule calls the window timing parameters to convert the node hop count into an integer sequence code, maps the response latency and state maintenance time to double-precision floating-point values, and writes the timeout ratio and retransmission count into the statistics field according to the preset label classification rules to generate a cloud signaling timing dataset.

[0020] As a further aspect of the present invention, the stability evaluation module includes:

[0021] The transfer rate calculation submodule calls the node hop count and the response delay field of the cloud signaling time series dataset, extracts the hop count difference and delay difference of three consecutive hops in time order, divides the hop count difference with the response delay difference, calculates the change in hop count per unit delay within each window, and generates a transfer rate difference sequence.

[0022] The delay difference values ​​are uniformly converted to milliseconds.

[0023] The path marking submodule sets the path stability threshold as the absolute fluctuation limit of the difference between two consecutive windows based on the transfer rate difference sequence. It iterates through all differences in the sequence, records the start and end timestamps of windows that continuously exceed the threshold, merges adjacent window intervals with timestamp intervals less than a preset value, and generates an abnormal path segment identifier.

[0024] The absolute fluctuation limit is determined by calculating the moving average of the differences in the first 10% window;

[0025] The path label generation submodule calls the abnormal path segment identifier, extracts the starting hop count, ending hop count, and average difference of each path segment, divides the stability level according to the preset interval where the average difference is located, and concatenates the level number with the path segment position code into a string to generate path stability segment labels.

[0026] As a further aspect of the present invention, the dynamic compression module includes:

[0027] The path filtering submodule calls the path stability segmentation label, traverses the stability level number corresponding to the path segment code in the label, compares the number with the preset path stability threshold item by item, filters the path segment code with the number greater than the threshold, and at the same time extracts the node hop count and delay field storage address of the corresponding path segment from the cloud signaling time series dataset according to the code to generate the filtered path segment identifier.

[0028] The mean calculation submodule divides the nodes within the path segment into continuous intervals according to the hop count from low to high based on the filtered path segment identifier. It accumulates the response delay value of the nodes in each interval and counts the number of nodes. The sum of the delays is divided by the number of nodes to obtain the mean of a single interval. At the same time, the mean is combined with the number of hops at the beginning and end of the interval to form a three-dimensional parameter set to generate the node delay mean.

[0029] The vector generation submodule calls the node latency mean, converts the starting hop count into an integer index value, maps the latency mean to four decimal places as a floating-point value, adds the ending hop count to the index value to generate a composite index key, and integrates it with the latency mean according to field type to generate a cloud compressed feature vector.

[0030] As a further aspect of the present invention, the abnormal trajectory clustering module includes:

[0031] The feature extraction submodule calls the state maintenance time, timeout ratio, and retransmission count fields, normalizes the values ​​of multiple fields according to the path segment number, and concatenates the normalized field values ​​into a multi-dimensional vector according to the path segment order to generate trajectory feature parameters.

[0032] The normalization process uses the Min-Max formula to map the values ​​to the [0,1] interval;

[0033] Based on the trajectory feature parameters, the clustering calculation submodule uses a cloud-based distributed K-means algorithm to randomly select initial cluster centers, calculates the sum of squared Euclidean distances between all vectors and cluster centers, assigns vectors to the nearest cluster center, recalculates the mean of all vectors in each cluster as the new center, iterates until the change in center position is lower than the preset convergence condition, and generates trajectory cluster centers.

[0034] The clustering label generation submodule calls the trajectory clustering center, counts the proportion of path segments in each cluster, filters the cluster numbers whose proportion is lower than the preset abnormal threshold, maps the path segments under the corresponding cluster to an integer label sequence, and generates abnormal trajectory clustering labels.

[0035] As a further aspect of the present invention, the system further includes:

[0036] The cloud feature library module is used to associate the cloud compressed feature vector set with the abnormal trajectory clustering label in time series and store it in the elastic storage service, generate a cloud call behavior feature matrix, and provide query services to the outside world through the cloud API interface;

[0037] The cloud call behavior feature matrix specifically includes a time-series correlation feature vector, a clustering label index, an elastic storage service address identifier, and a cloud API interface access key.

[0038] As a further aspect of the present invention, the cloud feature library module includes:

[0039] The associated storage submodule calls the cloud compressed feature vector and the abnormal trajectory clustering label, extracts the timestamp field of both, sorts the timestamps in ascending order and matches the corresponding feature vector storage address and label storage address, binds the floating-point value of the feature vector and the integer code of the label in the order of timestamp and stores them in the elastic storage service to generate the associated feature dataset.

[0040] The matrix generation submodule extracts all floating-point values ​​in the order of timestamps to construct row vectors based on the associated feature dataset. Integer codes are appended to the end of the row vectors as independent columns. Fields with missing values ​​or data type conflicts in the row vectors are detected and deleted. The verified row vectors are arranged into a two-dimensional structure according to the time series to generate a cloud call behavior feature matrix.

[0041] The interface configuration submodule calls the cloud call behavior feature matrix, defines the matrix row index as the timestamp field, the column index as a combination of the feature number field and the tag code field, configures the parameter input format of the query interface as the starting value of the time range and the list of feature numbers, and generates the cloud feature query interface.

[0042] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0043] In this invention, multi-dimensional parameters of the call link are acquired through distributed acquisition nodes and stored in time-window slices. A sliding window interpolation algorithm is used to dynamically calculate the difference in transfer rates over three consecutive hops, accurately identifying path stability segments. Distributed mean calculation compresses response latency within the selected path segments, generating feature vectors to reduce data redundancy. A distributed K-means algorithm based on a cloud platform integrates state maintenance time, timeout ratio, and retransmission counts to perform trajectory offset detection and construct anomaly clustering labels. With the support of time-series correlated storage and an elastic architecture, dynamic path segment selection reduces invalid data processing, mean compression reduces computational complexity, and multi-dimensional clustering improves anomaly detection accuracy. Time-window slicing optimizes the time-series data storage structure, sliding interpolation enhances the ability to capture path fluctuations, and elastic storage improves the efficiency of accessing massive amounts of data, forming an end-to-end quality analysis closed loop. Attached Figure Description

[0044] Figure 1 This is a system flowchart of the present invention;

[0045] Figure 2 This is a flowchart of the signaling acquisition module of the present invention;

[0046] Figure 3 This is a flowchart of the stability assessment module of the present invention;

[0047] Figure 4 This is a flowchart of the dynamic compression module of the present invention;

[0048] Figure 5 This is a flowchart of the abnormal trajectory clustering module of the present invention;

[0049] Figure 6 This is a flowchart of the cloud feature library module of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0051] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0052] Example 1: Please refer to Figure 1 Cloud-based voice call data analysis systems include:

[0053] The signaling acquisition module is used to obtain the number of node hops, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. After performing time window slicing, it stores the data in the cloud time series database, generates a cloud signaling time series dataset, and transmits it to the stability assessment module.

[0054] The stability assessment module is used to call the sliding window interpolation algorithm to calculate the difference in the three consecutive hop transfer rate between the node hop count and response latency in the cloud signaling time series dataset, mark the path segments that meet the threshold, generate path stability segment labels, and pass them to the dynamic compression module.

[0055] The dynamic compression module is used to filter path segments based on path stability segment labels, perform distributed mean calculation on the response latency of all nodes within the segment, generate a cloud compression feature vector set, and pass the cloud compression feature vector set and cloud signaling time series dataset to the abnormal trajectory clustering module.

[0056] The abnormal trajectory clustering module is used to extract state maintenance time, timeout ratio, and retransmission count. It performs trajectory offset detection through a cloud-based distributed K-means algorithm, generates abnormal trajectory clustering labels, and transmits them to the cloud feature library module.

[0057] The cloud feature library module is used to associate cloud compressed feature vector sets and abnormal trajectory clustering labels with time series and store them in elastic storage services to generate cloud call behavior feature matrix, and provide query services to the outside world through cloud API interface.

[0058] The path stability segmentation labels include the difference in transfer rates over three consecutive hops, the segment that meets the rate difference threshold, and the path stability level identifier. The cloud compression feature vector set specifically refers to the filter path segment identifier, the distributed mean response latency, and the compression window latency distribution. The abnormal trajectory clustering labels include the offset trajectory cluster identifier, the state maintenance time offset, the timeout ratio cluster center, and the abnormal retransmission threshold. The cloud call behavior feature matrix specifically includes the time-series correlation feature vector, the clustering label index, the elastic storage service address identifier, and the cloud API interface access key.

[0059] Distributed data acquisition nodes deployed on a cloud platform work in conjunction with a sliding window interpolation algorithm to reduce network jitter interference and improve path selection accuracy;

[0060] The initial cluster centers of the cloud-based distributed K-means algorithm are 5 randomly selected sample points, and the convergence condition is that the center offset is less than 0.5%.

[0061] Please see Figure 2The signaling acquisition module includes:

[0062] The signaling acquisition submodule obtains the node hop count, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. It performs cross-regional clock synchronization calibration on the timestamps in the raw data, calculates the average of multiple indicators based on a sliding window and removes data points that deviate from the average by more than 3 times the standard deviation, calculates the correlation coefficient between node hop count and response latency, and generates a group of node performance indicators.

[0063] Data points that deviate from the mean by more than three standard deviations are determined based on statistical analysis of historical network jitter data.

[0064] The signaling acquisition submodule actively acquires key performance data for a specific call link, such as a VoIP call from user A in Beijing to user B in Shanghai, through distributed acquisition nodes deployed on the network path and on the cloud platform. Specific acquisition items include the number of node hops the data packet transmission passes through, the response latency between nodes, the duration of the connection state, the timeout ratio during communication, and the number of data packet retransmissions. The four acquisition nodes (Node1, Node2, Node3, and Node4) deployed in Beijing, Jinan, Nanjing, and Shanghai each record the key time points and performance indicators of the data packet's journey.

[0065] The timestamps in the collected raw data may be inaccurate due to the different geographical locations of the collection nodes (involving different time zones) or slight deviations in the clocks of each node. Cross-regional clock synchronization calibration is required. This step uses a unified reference clock source, selecting Global Positioning System (GPS) time as a high-precision reference. The deviation is calculated by comparing the difference between the local clock of each collection node and the GPS time. Specifically, if the local clock of Node1 is 2 milliseconds ahead of the GPS time and the local clock of Node4 is 1 millisecond behind the GPS time, then when processing the data, all timestamps recorded by Node1 are subtracted by 2 milliseconds, and all timestamps recorded by Node4 are added by 1 millisecond. This process is repeated to adjust the timestamps of all relevant nodes to ensure that subsequent analysis is based on a unified and accurate time reference.

[0066] After calibration, a sliding window method was used to perform statistical analysis on multiple indicators. The sliding window size was set to 60 seconds, and the sliding step size was 10 seconds. Within each window, the collected indicator data was processed. Taking response delay as an example, the response delay data sequence collected within a specific time window W1 (e.g., 14:30:00 to 14:31:00) is as follows: Milliseconds, calculate the arithmetic mean of the delays within this window. Milliseconds, and simultaneously calculate the standard deviation of these data points. The calculation process involves first calculating the variance. Then the standard deviation Next, data points deviating from the mean by more than three standard deviations are removed. This removal rule (three standard deviations) is based on statistical analysis of historical network jitter data. The analysis results show that, under similar network environments, normal network latency fluctuations rarely exceed these limits. Data points outside this range are considered significantly abnormal and need to be removed. The upper limit of the removal threshold is calculated as follows: milliseconds, lower limit is Since latency cannot be negative, the actual lower limit is 0 milliseconds. The data point of 150 milliseconds is within the range of [0, 161.115] milliseconds, so it is not removed in this example. If there is a data point of 170 milliseconds in the window, it will be removed because it exceeds the upper limit of 161.115 milliseconds. After removing the outlier, the mean and standard deviation of the window need to be recalculated. The same sliding window statistics and outlier data removal process is also performed on other collected indicators such as node hop count and state maintenance time.

[0067] Finally, the correlation between node hop count and response latency was calculated, and the Pearson correlation coefficient was used to quantify the strength of the relationship. The node hop count sequence within the same sliding window was extracted after synchronous calibration and outlier removal. (Assuming no abnormal hops are removed, the mean is 4.375) and response delay sequence (Mean time 70.875 ms), calculate the covariance of the two sequences. and their respective standard deviations and ms, correlation coefficient , obtained through calculation The value range of this coefficient is [-1, 1]. 0.75 indicates that within this time window, the increase in node hop count and the increase in response latency show a strong positive correlation. The calculated statistical indicators, including the average node hop count of 4.375, the average response latency of 70.875ms, the average state maintenance time, the average timeout ratio, the average number of retransmissions, and the correlation coefficient of 0.75, are combined into a structured data record, namely the node performance indicator group, and the corresponding window timestamp is attached and output to the subsequent modules.

[0068] The timing slicing submodule counts node hops in segments based on node performance metrics and a fixed time window length. It uses a moving average method to eliminate instantaneous fluctuations in response latency and converts the timeout ratio and retransmission count into percentage values ​​based on the proportion of event triggers within the window to generate window timing parameters.

[0069] The moving average method uses a window length of 5 seconds and distributes weights exponentially decaying.

[0070] The time-series slicing submodule receives a sequence of node performance metrics generated by the previous module. This sequence contains statistical results of each sliding window arranged in chronological order, such as timestamps. The corresponding indicator group {average number of jumps} , average response delay ms, mean timeout rate Average number of retransmissions This module first counts the number of node jumps in segments according to a fixed time window length. The fixed window length is set to 1 minute. The number of times the mean number of node jumps in the input indicator group (rounded to the nearest integer or determined according to the distribution) is a specific value within the 1 minute from 14:30:00 to 14:31:00 is counted. The statistical results are {jumps 4: 3 times, jumps 5: 2 times, jumps 6: 1 time}.

[0071] Meanwhile, a moving average method is used to smooth the response delay to eliminate sudden and drastic fluctuations in the data and highlight trend changes. This moving average method specifies a window length of 5 seconds and uses exponential decay to distribute weights, with weight calculation based on a smoothing factor. Its settings are related to window length. (or equivalent points) related, based on The rule is that if a window length of 5 seconds corresponds to 5 data points (assuming a data frequency of 1Hz), then... Current time point Smooth latency Through formula The calculation shows that, among which It is the average raw response delay at the current time point. This is the smoothed delay value calculated at the previous time point. The specific calculation is as follows: If Average response delay at time step ms, and the smoothed delay of the previous time step. ms, then the current smoothing delay This smoothing calculation is continuously applied to every delay value in the time-series data stream.

[0072] Furthermore, the timeout ratio and retransmission count are converted into percentage values ​​based on the frequency of events occurring within a set 1-minute window. Specifically, this is done by counting the total number of data packets processed within the window, as well as the number of timeout events and retransmission events detected. For example, if 1000 data packets are processed within one minute, with 20 timeout events and 50 retransmission events, the timeout ratio is calculated as follows: The retransmission count conversion ratio is: The segmented hop count statistics obtained after the above processing {hop count 4: 3 times, hop count 5: 2 times, hop count 6: 1 time}, the delay value corresponding to the end point of the current 1-minute window in the calculated smooth response delay sequence (e.g., 62.10ms), and the converted timeout ratio are used. and retransmission ratio These parameters, along with the corresponding timestamps, are integrated to generate window timing parameters, which are then output to the next module.

[0073] The cloud storage submodule calls the window timing parameters, converts the node hop count into an integer sequence code, maps the response latency and state maintenance time to double-precision floating-point values, and writes the timeout ratio and retransmission count into the statistics field according to the preset label classification rules, generating a cloud signaling timing dataset.

[0074] The cloud storage submodule receives window timing parameters generated by the timing slicing submodule. A typical parameter set is {timestamp: "2025-04-24 14:31:00", hop count: {4:3, 5:2, 6:1}, smooth response latency: 62.10ms, average state duration: 120.5s, timeout rate: 2%, retransmission rate: 5%}. This module is responsible for converting these parameters into a format suitable for storage and subsequent analysis, and storing them in the cloud storage system to form a cloud signaling timing dataset.

[0075] First, the node hop count is converted into an integer sequence encoding. The selected encoding rule is to record the hop value that appears most frequently within the window. In {4:3,5:2,6:1}, the hop number 4 appears the most times (3 times), so it is encoded as the integer value 4. Then, the response delay and state maintenance time are mapped to double-precision floating-point values. The smooth response delay of 62.10ms is stored as the floating-point number 62.10, and the average state maintenance time of 120.5s is stored as the floating-point number 120.5.

[0076] Next, the timeout percentage and retransmission count are written into the statistics field according to the preset tag classification rules. The rule here is to store the percentage values ​​directly as floating-point numbers, with a 2% timeout percentage stored as 2.0 and a 5% retransmission percentage stored as 5.0. No interval division and tagging is performed to retain more refined raw information for subsequent analysis. All processed and transformed data items are integrated to form a structured storage record: {Timestamp:“2025-04-24 14:31:00”,HopCountCode:4,AvgSmoothedLatency:62.10,AvgStatusTime:120.5,TimeoutPercent:2.0,RetransmissionPercent:5.0}.

[0077] By continuously processing the parameters passed in for each time window, a series of such records are generated and stored in cloud storage services (such as distributed databases or time-series databases) in chronological order, thereby constructing a cloud signaling time-series dataset.

[0078] Table 1 Example of Cloud Signalling Timing Data

[0079] Timestamp hop count encoding Smooth response latency (ms) State duration (s) Overtime percentage (%) 2025-04-24 14:30:00 4 61.65 118.2 1.5 4.0 2025-04-24 14:31:00 4 62.10 120.5 2.0 5.0 2025-04-24 14:32:00 5 75.30 115.0 2.5 5.5 2025-04-24 14:33:00 5 78.00 110.8 3.2 7.0 2025-04-24 14:34:00 4 65.50 122.1 1.8 4.5 2025-04-24 14:35:00 4 64.00 125.3 1.6 4.2 2025-04-24 14:36:00 5 71.00 119.8 2.2 5.0

[0080] As shown in Table 1, this table lists a partial record sample of the cloud signaling time series dataset. Each row represents a snapshot of the call link status within a time window (1 minute interval), including the encoded main hop count, the smoothed response latency (unit: milliseconds), the average state maintenance time (unit: seconds), and the directly recorded timeout and retransmission ratio (unit: %).

[0081] Please see Figure 3 The stability assessment module includes:

[0082] The transfer rate calculation submodule calls the node hop count and response delay fields of the cloud signaling time series dataset, extracts the hop count difference and delay difference of three consecutive hops in time sequence, performs a division operation between the hop count difference and the corresponding delay difference, calculates the change in hop count per unit delay within each window, and generates a transfer rate difference sequence.

[0083] The latency difference is uniformly converted to milliseconds.

[0084] The transfer rate calculation submodule calls the node hop count encoding and smooth response delay fields in the cloud signaling timing dataset, as shown in Table 1. Its purpose is to calculate the change in the number of node hops per unit delay, thereby quantifying the rate of change of the path structure.

[0085] The calculation process is performed chronologically, extracting records from three consecutive time points each time to calculate the transition rate between two adjacent time windows. Taking the records at 14:30:00, 14:31:00, and 14:32:00 in Table 1 as an example, the corresponding hop count encoding sequence is as follows: The corresponding smooth response delay sequence is ms, first calculate the hop count difference for the first time interval (14:30 to 14:31). (Unitless), delay difference ms, then calculate the hop count difference for the second time interval (14:31 to 14:32). Delay difference ms.

[0086] Next, the hop count difference is divided by the corresponding delay difference to calculate the transfer rate, which is the change in hop count per unit delay. The delay difference is directly expressed in milliseconds because this is a fine-grained time unit commonly used in communications and suitable for capturing rapid changes. The transfer rate for the first window (corresponding to 14:31:00, reflecting the changes in the previous minute) is calculated. ,because Calculated Jumps / milliseconds, calculate the transition rate for the second window (corresponding to the time point 14:32:00). Jumps / milliseconds.

[0087] Continuing with the time series processing, considering the data at 14:31:00, 14:32:00, and 14:33:00, the number of jumps... Delay ms, calculated , ms, transfer rate Jumps / milliseconds, then consider the data at 14:32:00, 14:33:00, and 14:34:00, jump count. Delay ms, calculated , ms, transfer rate Jumps / milliseconds, and this calculation is repeated to eventually generate a time-ordered sequence of transfer rate differences. This sequence reflects the dynamics of network path topology (measured by hop count) relative to changes in latency.

[0088] The path marking submodule is based on the transfer rate difference sequence. It sets the path stability threshold as the absolute fluctuation limit of the difference between two consecutive windows, traverses all differences in the sequence, records the start and end timestamps of windows that continuously exceed the threshold, merges adjacent window intervals with timestamp intervals less than the preset value, and generates abnormal path segment identifiers.

[0089] The upper limit of absolute fluctuation is determined by calculating the moving average of the differences in the first 10% window.

[0090] The path marking submodule receives the transfer rate difference sequence generated by the previous module. The task is to identify time periods in which network paths become significantly unstable based on this sequence.

[0091] First, a path stability threshold is set, defined as the upper limit of the absolute fluctuation of the difference between the transition rates of two consecutive windows. The specific value of the threshold is determined based on the analysis of the first 10% of the time windows of the transition rate sequence in historical data (e.g., the past month). The specific calculation process is as follows: Select the first 10% of the data points in sequence R, calculate the absolute value of the difference between each pair of adjacent points to obtain an absolute difference sequence, and then calculate the arithmetic mean of this absolute difference sequence. This average value is set as the stability threshold. Suppose sequence R has 100 data points, and we take the first 10 points. to Calculate 9 absolute differences for to The difference sequence is obtained. Calculate the average of these values. hops / milliseconds / window, therefore, set a path stability threshold. .

[0092] Next, traverse the entire transition rate difference sequence R and calculate the absolute value of the difference between all adjacent points. and compare this value with the threshold. Compare and record consecutive occurrences exceeding the threshold. The start and end timestamps of the time window, continue using the sequence. ,calculate , , , , , , , discovered from arrive The absolute values ​​of five consecutive differences all exceeded the threshold; this corresponds to the time period from the calculation... The change occurred in a window following that point in time (corresponding to the record at 14:31:00, with the change occurring between 14:30 and 14:31, marked as 14:31:00) (i.e., 14:32:00, corresponding to...). From the point in time when the impact occurs until the calculation The change occurred in a window following the time point (corresponding to the record at 14:35:00, with the change occurring between 14:34 and 14:35) (i.e., 14:36:00, corresponding to...). Once the point at which the impact occurs is reached, record the start and end timestamps. and end timestamp .

[0093] Finally, the identified consecutive abnormal window intervals are merged and checked. A time interval threshold, such as 2 minutes, is set to merge abnormal segments that are very close in time. If a new abnormal segment is found immediately after the above-mentioned abnormal segment (ending at 14:36:00), starting at 14:37:00 and continuing to 14:39:00, since the time interval between 14:37:00 and 14:36:00 is only 1 minute, which is less than the set 2-minute merging threshold, these two abnormal segments will be merged into a longer abnormal segment. Its start time is the start time of the original first segment, 14:32:00, and its end time is the end time of the original second segment, 14:39:00. The finally determined abnormal interval and its start and end timestamps are packaged to generate an abnormal path segment identifier, and the output is {ID:“PathSeg_001”,StartTime:“2025-04-2414:32:00”,EndTime:“2025-04-2414:39:00”}.

[0094] The path label generation submodule calls the abnormal path segment identifier, extracts the starting hop count, ending hop count, and average difference of each path segment, divides the stability level according to the preset interval where the average difference is located, and concatenates the level number with the path segment position code into a string to generate path stability segment labels.

[0095] The path label generation submodule receives an abnormal path segment identifier, such as {ID:“PathSeg_001”,StartTime:“2025-04-2414:32:00”,EndTime:“2025-04-2414:39:00”}, and its task is to generate a quantified stability level label for this identified abnormal path segment.

[0096] First, extract the node hop count codes for the start time (14:32:00) and end time (assuming a corresponding record exists at 14:39:00) of this path segment from the cloud signaling time series dataset (refer to Table 1 and subsequent data) to obtain the starting hop count. and the number of termination jumps Simultaneously, extract all calculated transfer rate values ​​within this path segment (covering time from 14:32:00 to 14:39:00). ,Right now (This is an addition) (Using the values ​​as examples), calculate the arithmetic mean of these transfer rate values. Jumps / milliseconds.

[0097] Then, based on the calculated average transfer rate Based on the preset stability level division rules, a level number is assigned to this path segment. The preset division rules are: Level 1 (stable) corresponds to... Level 2 (Slight Fluctuation) corresponds to Level 3 (moderate fluctuation) corresponds to Level 4 (violent fluctuations) corresponds to These intervals are set based on an analysis of the impact of different fluctuation amplitudes on call quality in historical data. The currently calculated mean is... Its absolute value Falling into the range Therefore, the stability level of this path segment is rated as level 3.

[0098] Finally, the obtained level number (3) is concatenated with the unique identifier of the path segment ("PathSeg_001") to form a structured string label, which is defined as "Level[Level Number]_[Path Segment ID]", i.e. "Level3_PathSeg_001". This process is repeated for all identified abnormal path segments to generate a list of path stability segment labels, such as ["Level3_PathSeg_001", "Level4_PathSeg_002", ...], which is then passed to subsequent modules.

[0099] Please see Figure 4 The dynamic compression module includes:

[0100] The path filtering submodule calls the path stability segment label, traverses the stability level number corresponding to the path segment code in the label, compares the number with the preset path stability threshold item by item, filters the path segment code with the number greater than the threshold, and at the same time extracts the node hop count and latency field storage address of the corresponding path segment from the cloud signaling time series dataset according to the code to generate the filtered path segment identifier.

[0101] The path filtering submodule receives a list of path stability segment labels, such as L=[“Level3_PathSeg_001”,“Level4_PathSeg_002”,“Level2_PathSeg_003”], with the goal of filtering out path segments that need further analysis based on preset conditions.

[0102] Iterate through each tag string in the tag list and extract the path segment stability level number contained within it. Extract level number 3 from "Level3_PathSeg_001", level number 4 from "Level4_PathSeg_002", and level number 2 from "Level2_PathSeg_003". Compare the extracted level numbers with the preset path stability filtering threshold. Perform numerical comparisons and set... This threshold is set based on operational needs, aiming to focus on path segments exhibiting moderate to severe instability for in-depth root cause analysis or optimization. The comparison process is as follows: Level 3 and... Compare, The result is true; Level 4 and Compare, The result is true; Level 2 and Compare, The result is false.

[0103] Based on the comparison results, grades with a level number greater than or equal to the screening threshold were selected. The path segment identifiers are used to obtain a filtered list of path segment IDs [“PathSeg_001”, “PathSeg_002”]. Next, based on these filtered path segment IDs, the node hop count encoding sequence and the corresponding smooth response delay sequence for each path segment are extracted from the storage address index or direct data cache of the cloud signaling time series dataset (as shown in Table 1 and subsequent data). Specifically, the extracted content is the hop count sequence within the PathSeg_001 time period. and delay sequence (The complete sequence is provided here to avoid ellipses), and the data corresponding to PathSeg_002, the filtered path segment ID is combined with its extracted data (or the storage reference / address of the data) to generate the filtered path segment identifier, whose structure is [{ID:“PathSeg_001”,Data:{Hop:[5,5,4,4,4,5,5],Latency:[75.30,78.00,65.50,66.00,64.80,70.00,72.50]}},{ID:“PathSeg_002”,Data:{Hop:[…],Latency:[…]}}], which is then passed to the next module.

[0104] The mean calculation submodule divides the nodes within the path segment into continuous intervals based on the filtered path segment identifiers and the hop count from low to high. It accumulates the response delay values ​​of the nodes in each interval and counts the number of nodes. The sum of the delays is divided by the number of nodes to obtain the mean of a single interval. At the same time, the mean is combined with the number of hops at the beginning and end of the interval to form a three-dimensional parameter set to generate the node delay mean.

[0105] The mean calculation submodule receives the filtered path segment identifier and its associated data, such as processing the data of PathSeg_001 {ID:“PathSeg_001”,Data:{Hop:[5,5,4,4,4,5,5],Latency:[75.30,78.00,65.50,66.00,64.80,70.00,72.50]}}, with the aim of calculating the average response latency corresponding to each different hop value within the path segment.

[0106] First, analyze the hop count sequence [5,5,4,4,4,5,5] within the path segment to identify the different hop values. Here, there are hop numbers 4 and 5. Group the data according to the hop value. The latency data corresponding to hop number 4 is {65.50,66.00,64.80} ms, and the latency data corresponding to hop number 5 is {75.30,78.00,70.00,72.50} ms.

[0107] Then, for each hop count group, sum all response latency values ​​within the group and count the number of data points within that group (i.e., the number of times that hop count occurs). For a group with 4 hop counts, the total latency is... ms, number of data points For a group with 5 hops, the total delay is ms, number of data points .

[0108] Next, the sum of the delays for each group is divided by the corresponding number of data points to calculate the average response delay for that hop number. The average delay for hop number 4 is... ms, average latency of 5 hops ms.

[0109] Finally, the calculated average latency and its corresponding hop value (which serves as the representative value for the interval, with the starting and ending hop counts being the same in this case) are merged into a three-dimensional parameter set in the format [hop value, hop value, average latency]. The result generated for PathSeg_001 is two parameter sets: [4,4,65.43] and [5,5,73.95]. This calculation process is performed on all selected path segments to generate a set of node latency mean parameter sets, such as [[4,4,65.43],[5,5,73.95]] (from PathSeg_001) and [[6,6,88.20],[7,7,95.10]] (assuming it comes from PathSeg_002).

[0110] The vector generation submodule calls the node latency mean, converts the starting hop count into an integer index value, maps the latency mean to four decimal places as a floating-point value, adds the ending hop count to the index value to generate a composite index key, and integrates it with the latency mean according to field type to generate a cloud compressed feature vector.

[0111] The vector generation submodule receives a set of node delay mean parameter groups, such as [[4,4,65.43],[5,5,73.95]] (from PathSeg_001). The goal is to convert these calculation results into feature vectors in a fixed format for easy processing by subsequent machine learning models.

[0112] The vectorization method used is to create a feature vector for each path segment. The dimension (or index) of the vector corresponds to a possible node hop number, and the value of the vector in that dimension is the average response latency of the corresponding hop number. If a certain hop number does not appear in the path segment, the value in that dimension is a preset padding value (0 is used here). The hop number range covered by the vector is set to 1 to 10, that is, the vector length is 10.

[0113] Process the parameter sets [4,4,65.43] and [5,5,73.95] from PathSeg_001, keep the average latency value to four decimal places, and get 65.4300 and 73.9500. Take the hop number 4 as the index, and the corresponding value is 65.4300; take the hop number 5 as the index, and the corresponding value is 73.9500. For other dimensions in the vector (index 1,2,3,6,7,8,9,10), since these hop numbers do not appear in PathSeg_001, their values ​​are filled with 0. The final feature vector V1 generated by PathSeg_001 is: [0.0000,0.0000,0.0000,65.4300,73.9500,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000].

[0114] Perform the same transformation process on all input path segment parameter sets. For example, for the parameter set [[6,6,88.20],[7,7,95.10]] from PathSeg_002, the generated feature vector V2 is: [0.0000,0.0000,0.0000,0.0000,0.0000,88.2000,95.1000,0.0000,0.0000,0.0000]. Associate each generated vector with its corresponding path segment ID to form a cloud-compressed feature vector set: [{ID:“PathSeg_001”,Vector:V1},{ID:“PathSeg_002”,Vector:V2},…].

[0115] Please see Figure 5 The abnormal trajectory clustering module includes:

[0116] The feature extraction submodule calls the state maintenance time, timeout ratio, and retransmission count fields, normalizes the values ​​of multiple fields according to the path segment number, and concatenates the normalized field values ​​into a multi-dimensional vector according to the path segment order to generate trajectory feature parameters.

[0117] The normalization process uses the Min-Max formula to map the values ​​to the [0,1] interval;

[0118] The purpose of the feature extraction submodule is to extract features other than latency and hop count for each abnormal path segment (such as PathSeg_001, PathSeg_002, etc., which were previously selected) and integrate them.

[0119] The cloud signaling time series dataset is called, and the original data sequence of the corresponding state maintenance time, timeout ratio, and retransmission count fields within the time period corresponding to the abnormal path segment identifier (such as PathSeg_001 corresponding to the time period 14:32:00-14:39:00) is extracted. For PathSeg_001, the extracted sequence is: state maintenance time s (assuming this segment contains 5 record points), timeout percentage %, retransmission rate %.

[0120] Calculate the average value of each field within the path segment, and the average state duration of PathSeg_001. s, average timeout rate Average retransmission ratio Perform the same calculation on PathSeg_002, and obtain... .

[0121] The average values ​​calculated for all abnormal path segments are normalized using the Min-Max normalization method, as shown in the formula below. Before normalizing, the numerical values ​​are linearly mapped to the [0,1] interval. It is necessary to first determine the global minimum and maximum values ​​of each feature dimension (state duration, timeout ratio, retransmission ratio) across all the abnormal path segments to be processed. This is done by scanning the average data of all abnormal path segments to determine: State duration. s, s; timeout ratio , retransmission ratio , .

[0122] The three average values ​​of PathSeg_001 are normalized using the Min-Max formula: Normalized state duration. Normalized timeout ratio Normalized retransmission ratio .

[0123] The normalized field values ​​of each path segment are concatenated in the order of (state duration, timeout ratio, retransmission ratio) to form a multi-dimensional vector. For PathSeg_001, the generated trajectory feature vector is: The same process was performed on PathSeg_002 to obtain... Finally, a set of trajectory feature parameters is generated, containing feature vectors of all abnormal path segments. .

[0124] The clustering calculation submodule uses trajectory feature parameters and a cloud-based distributed K-means algorithm to randomly select initial cluster centers. It calculates the sum of squared Euclidean distances between all vectors and the cluster centers, assigns the vectors to the nearest cluster centers, recalculates the mean of all vectors in each cluster as the new center, and iterates until the change in the center position is lower than the preset convergence condition, thus generating trajectory cluster centers.

[0125] The clustering calculation submodule receives a set of trajectory feature parameters, i.e. ,in The goal is to group abnormal path segments with similar characteristics into the same group (cluster).

[0126] The K-means clustering algorithm is implemented in a cloud-distributed manner, with a set number of clusters. This value Typically determined based on business understanding (expected types of abnormal patterns) or through evaluation using techniques such as the elbow rule, the algorithm starts by randomly selecting... The initial cluster centers are selected using a strategy based on the input dataset. Random selection without replacement The vectors are used as the initial centers. Let the randomly selected initial center be... , , .

[0127] The iterative process begins, and in each iteration, the assignment step is performed first: calculating the vectors in the dataset. To all current cluster centers The square of the Euclidean distance, the formula for the square of the Euclidean distance is: ,in It is the vector dimension (3 here), for vectors Calculate the squared distances between it and the three initial centers:

[0128] ;

[0129] ;

[0130] ;

[0131] Compare these three squared distance values. distance The closest (0.0856 minimum), therefore... Assigned to the first cluster, for all This assignment is performed on all vectors.

[0132] Then perform the update step: for each cluster Recalculate its cluster centers The new center is the arithmetic mean (centroid) of all vectors currently assigned to this cluster, i.e. ,in It is the first Assigned to clusters after round of iteration a set of vectors It is the number of vectors in the set.

[0133] Repeat the assignment and update steps until a preset convergence condition is met. The convergence condition is set as follows: the sum of the distances (Euclidean distances) that the positions of all cluster centers move in two consecutive iterations is less than a very small threshold. Or, it reaches the preset maximum number of iterations, this threshold Set according to the required precision, such as When the final iteration stops, the obtained cluster centers are... This is the final trajectory cluster center.

[0134] The clustering label generation submodule calls the trajectory clustering center, counts the proportion of path segments in each cluster, filters the cluster numbers whose proportion is lower than the preset abnormal threshold, maps the path segments under the corresponding cluster to an integer label sequence, and generates abnormal trajectory clustering labels.

[0135] The cluster label generation submodule receives the final trajectory cluster centers output by the cluster calculation submodule. And the cluster number to which each data point (abnormal path segment vector) ultimately belongs.

[0136] First, we calculate the proportion of path segments contained in each cluster to the total number of abnormal path segments. Let there be a total of... The abnormal path segments were clustered, and the clustering... Includes If there are several path segments, then clustering is performed. The proportion is Calculate all The proportion of each cluster .

[0137] Then, clusters representing abnormal behavior patterns are selected, and a preset threshold for the percentage of abnormal behavior is set. This threshold is set based on experience, assuming that clusters with an excessively low percentage may represent rare but crucial anomalous patterns. Filter out all that meet the requirements Cluster number These clusters, corresponding to these numbers, are considered as anomalous trajectory clusters that require special attention.

[0138] All path segments belonging to these selected anomalous clusters are mapped to a sequence of integer labels, where the label value is the anomalous cluster number to which the path segment belongs. For example, if the proportion of clusters 2 and 3 is less than 5%, then all path segments originally assigned to cluster 2 will have their cluster label set to 2, and all path segments originally assigned to cluster 3 will have their cluster label set to 3. Path segments assigned to other clusters (such as cluster 1, assuming their proportion...) will be... The path segment of the cluster is also set to its cluster number 1.

[0139] Finally, a unique clustering label is generated for each outlier path segment participating in clustering (such as "PathSeg_001", "PathSeg_002", etc.). This label directly corresponds to the cluster number it was assigned to during the clustering process. For example, if PathSeg_001 ultimately belongs to cluster 1, PathSeg_002 belongs to cluster 3 (and cluster 3 accounts for 4%, below the 5% threshold), PathSeg_003 belongs to cluster 1, PathSeg_004 belongs to cluster 2 (accounting for 36%), and PathSeg_005 belongs to cluster 3, then the output clustering label result can be represented as: {"PathSeg_001":1, "PathSeg_002":3, "PathSeg_003":1, "PathSeg_004":2, "PathSeg_005":3}. This result set identifies the feature pattern category to which different outlier path segments belong. In particular, by combining the clustering percentage information, it can highlight those belonging to low percentages (below the threshold). Clustered path segments that may represent more specific or critical anomalous behaviors.

[0140] Table 2 Examples of Clustering Labels for Abnormal Path Segments

[0141] Segment ID Trajectory feature vector (normalized: duration, timeout%, retransmission%) Cluster number Cluster percentage (%) Is it below the threshold (5%)? Final Tag PathSeg_001 [0.4767, 0.1800, 0.2489] 1 60 no 1 PathSeg_002 [0.8500, 0.7500, 0.8800] 3 4 yes 3 PathSeg_003 [0.5100, 0.2200, 0.2800] 1 60 no 1 PathSeg_004 [0.1500, 0.0800, 0.1200] 2 36 no 2 PathSeg_005 [0.7800, 0.8100, 0.9100] 3 4 yes 3

[0142] Refer to Table 2, which illustrates the label generation process for some abnormal path segments after clustering. The table lists the ID of each path segment, its corresponding normalized trajectory feature vector (dimensions are state maintenance time, timeout ratio, and retransmission ratio, in that order), the cluster number assigned by the K-means algorithm, the proportion of path segments included in that cluster to the total number of segments, whether this proportion is lower than the preset 5% abnormality threshold, and the final cluster label assigned to that path segment (i.e., its cluster number). This table shows that PathSeg_002 and PathSeg_005 are classified into cluster 3, which accounts for only 4% of the total, and are marked as abnormal pattern types requiring special attention.

[0143] Please see Figure 6 The cloud feature library module includes:

[0144] The associated storage submodule calls the cloud compressed feature vector and the abnormal trajectory clustering label, extracts the timestamp field of both, sorts the timestamps in ascending order and matches the corresponding feature vector storage address and label storage address, binds the floating-point value of the feature vector and the integer code of the label in the order of timestamp and stores them in the elastic storage service to generate the associated feature dataset.

[0145] The associated storage submodule receives a set of cloud-compressed feature vectors, such as {ID: "PathSeg_001", Vector: V1}, {ID: "PathSeg_002", Vector: V2}, ..., {ID: "PathSeg_005", Vector: V5}, and anomaly trajectory clustering label result set {"PathSeg_001": 1, "PathSeg_002": 3,"PathSeg_003": 1, "PathSeg_004": 2, "PathSeg_005": 3}. The core task of this module is to associate the vectors representing path segment delay features with their corresponding behavior pattern clustering labels using timestamps and store them for subsequent construction of a time-series feature matrix.

[0146] First, extract the timestamp information corresponding to each path segment identifier (e.g., "PathSeg_001"). This timestamp uses the time when the abnormal path segment ended in the original time series data as a unique identifier. Based on the context examples of sub-items 5 and 12, the end timestamps of each path segment are set as follows: PathSeg_001 corresponds to "2025-04-24 14:39:00", PathSeg_002 corresponds to "2025-04-24 14:55:00", PathSeg_003 corresponds to "2025-04-24 15:05:00", PathSeg_004 corresponds to "2025-04-24 15:12:00", and PathSeg_005 corresponds to "2025-04-24 15:20:00".

[0147] Next, the feature vector and cluster label for each path segment are stored in the specified storage location, and their storage addresses or references are retrieved. Feature vectors (floating-point arrays) are suitable for storage in object storage services (such as AWS S3, Google Cloud Storage) or dedicated vector databases for efficient storage and retrieval performance; cluster labels (integers) can be stored in key-value stores (such as Redis) or simple database tables. Assume the retrieved addresses after storage are as follows:

[0148] PathSeg_001: Vector address vec_loc_1 = " / feature_store / vectors / seg001.vec", Label address lbl_loc_1 = " / feature_store / labels / seg001.lbl"

[0149] PathSeg_002: Vector address vec_loc_2 = " / feature_store / vectors / seg002.vec", Label address lbl_loc_2 = " / feature_store / labels / seg002.lbl"

[0150] PathSeg_003: Vector address vec_loc_3 = " / feature_store / vectors / seg003.vec", Label address lbl_loc_3 = " / feature_store / labels / seg003.lbl"

[0151] PathSeg_004: Vector address vec_loc_4 = " / feature_store / vectors / seg004.vec", Label address lbl_loc_4 = " / feature_store / labels / seg004.lbl"

[0152] PathSeg_005: Vector address vec_loc_5 = " / feature_store / vectors / seg005.vec", Label address lbl_loc_5 = " / feature_store / labels / seg005.lbl"

[0153] Then, the timestamp of each path segment is bound to its corresponding feature vector storage address and label storage address to form an associated record. For example, the record corresponding to PathSeg_001 is: {"timestamp": "2025-04-24 14:39:00", "vector_loc": vec_loc_1, "label_loc": lbl_loc_1}.

[0154] Finally, all these related records are sorted in ascending order by the timestamp field and stored in an elastic storage service optimized for time-series data, such as a time-series database (e.g., InfluxDB, TimescaleDB) or a NoSQL database configured with a time-sorted index. This type of storage service is chosen because it efficiently supports querying and aggregating data by time range, which is crucial for generating the feature matrix and providing a query interface. After storage, a related feature dataset is formed, logically structured as a time-sorted list, where each element contains a timestamp and a storage location pointing to the corresponding feature vector and cluster label at that time point.

[0155] The matrix generation submodule extracts all floating-point values ​​in the order of timestamps from the associated feature dataset to construct row vectors, appends integer codes as independent columns to the end of the row vectors, detects missing values ​​or fields with conflicting data types in the row vectors and performs deletion operations, and arranges the verified row vectors into a two-dimensional structure according to the time series to generate a cloud call behavior feature matrix.

[0156] The matrix generation submodule is based on the associated feature dataset created in the previous step. Its goal is to construct a structured two-dimensional matrix, namely the cloud call behavior feature matrix, which integrates the temporal feature information of all the selected abnormal path segments.

[0157] First, iterate through each record in the associated feature dataset in timestamp order. For each record, such as {"timestamp": "2025-04-24 14:39:00", "vector_loc": vec_loc_1, "label_loc": lbl_loc_1}, based on its included storage addresses vector_loc and label_loc, retrieve the actual feature vector (floating-point numerical array) and cluster label (integer encoding) from their corresponding storage locations (object storage, vector database, key-value storage, etc.). Based on the previous example data:

[0158] Timestamp 14:39:00: Vector V1 = [0.0, 0.0, 0.0, 65.43, 73.95, 0.0,0.0, 0.0, 0.0, 0.0], Label L1 = 1

[0159] Timestamp 14:55:00: Vector V2 = [0.0, 0.0, 0.0, 0.0, 0.0, 88.20,95.10, 0.0, 0.0, 0.0], Label L2 = 3

[0160] Timestamp 15:05:00: Vector V3 = [0.0, 0.0, 0.0, 68.10, 75.50, 0.0,0.0, 0.0, 0.0, 0.0], Label L3 = 1

[0161] Timestamp 15:12:00: Vector V4 = [0.0, 0.0, 55.00, 62.30, 0.0, 0.0,0.0, 0.0, 0.0, 0.0], Label L4 = 2

[0162] Timestamp 15:20:00: Vector V5 = [0.0, 0.0, 0.0, 0.0, 0.0, 90.10,98.50, 105.20, 0.0, 0.0], Label L5 = 3

[0163] Next, a row vector is constructed for each timestamp. This row vector consists of two parts: first, the value of the retrieved 10-dimensional floating-point feature vector, and then the retrieved integer clustering label encoding is appended to the end of the vector.

[0164] Row for 14:39:00: [0.0, 0.0, 0.0, 65.43, 73.95, 0.0, 0.0, 0.0, 0.0,0.0, 1]

[0165] Row for 14:55:00: [0.0, 0.0, 0.0, 0.0, 0.0, 88.20, 95.10, 0.0, 0.0,0.0, 3]

[0166] Row for 15:05:00: [0.0, 0.0, 0.0, 68.10, 75.50, 0.0, 0.0, 0.0, 0.0,0.0, 1]

[0167] Row for 15:12:00: [0.0, 0.0, 55.00, 62.30, 0.0, 0.0, 0.0, 0.0, 0.0,0.0, 2]

[0168] Row for 15:20:00: [0.0, 0.0, 0.0, 0.0, 0.0, 90.10, 98.50, 105.20,0.0, 0.0, 3]

[0169] After constructing the row vectors, data validation and cleaning steps are performed. Each row vector is checked for missing values ​​(e.g., incomplete vectors or labels were not retrieved due to storage or retrieval errors) or fields with conflicting data types (e.g., label values ​​are not integers). A processing rule is set: if any row vector is detected to contain any missing values ​​or type conflicts, the entire row is removed from the matrix to be constructed. This rule ensures the data integrity and consistency of the final generated matrix. In this example, it is assumed that all data was successfully retrieved and of the correct type, and no rows were deleted.

[0170] Finally, all the verified row vectors are arranged vertically according to their corresponding timestamps to form a two-dimensional structure. This two-dimensional structure is the cloud call behavior feature matrix.

[0171] Table 3 Example of Cloud Call Behavior Feature Matrix

[0172] Timestamp (RowIndex) F1 (Hop1Latency) F2(Hop2Latency) F3 (Hop3Latency) F4 (Hop4Latency) F5 (Hop5 Latency) F6 (Hop6Latency) F7 (Hop7 Latency) F8 (Hop8Latency) F9 (Hop9 Latency) F10 (Hop10 Latency) Label(ClusterID) 2025-04-24 14:39:00 0.00 0.00 0.00 65.43 73.95 0.00 0.00 0.00 0.00 0.00 1 2025-04-24 14:55:00 0.00 0.00 0.00 0.00 0.00 88.20 95.10 0.00 0.00 0.00 3 2025-04-24 15:05:00 0.00 0.00 0.00 68.10 75.50 0.00 0.00 0.00 0.00 0.00 1 2025-04-24 15:12:00 0.00 0.00 55.00 62.30 0.00 0.00 0.00 0.00 0.00 0.00 2 2025-04-24 15:20:00 0.00 0.00 0.00 0.00 0.00 90.10 98.50 105.20 0.00 0.00 3

[0173] Table 3 shows a portion of the generated cloud call behavior feature matrix. Each row represents the end time of an abnormal path segment, with the row index being the timestamp. Each column represents a feature dimension or label, with the column indices from left to right being the average latency features (F1 to F10, in ms) corresponding to the 10 hop counts, and the final clustering label encoding. This matrix integrates key temporal feature information for subsequent analysis and application.

[0174] The interface configuration submodule calls the cloud call behavior feature matrix, defines the matrix row index as the timestamp field, and the column index as a combination of the feature number field and the tag code field. It configures the parameter input format of the query interface as the starting value of the time range and the list of feature numbers, and generates the cloud feature query interface.

[0175] The interface configuration submodule utilizes the cloud call behavior feature matrix generated in the previous step (as shown in Table 3) to provide a standardized query interface that allows external systems or users to retrieve specific call behavior data based on time and feature dimensions.

[0176] First, define the data access structure for the matrix. Explicitly specify the row indices of the matrix as timestamp fields, with data type date and time. Define the column indices of the matrix as a composite structure: the first 10 columns (F1 to F10) correspond to feature numbers 1 to 10 (representing average latency under different hop counts), and the last column corresponds to the tag encoding field.

[0177] Next, configure the parameter input format for the query interface. This interface is designed to accept the following parameters:

[0178] startTime: The starting value for querying the time range, in the format of an ISO 8601 timestamp string (e.g., "2025-04-24T14:00:00Z").

[0179] endTime: The end value of the query time range, in the same format as above (e.g., "2025-04-24T15:00:00Z").

[0180] featureIDs: A list (array of integers) containing the desired feature IDs, for example, [4, 5] means you want to query feature 4 (Hop4 Latency) and feature 5 (Hop5 Latency).

[0181] The internal logic of the query interface executes operations based on the input parameters:

[0182] Based on startTime and endTime, filter out all rows in the cloud call behavior feature matrix whose row index (timestamp) falls within this time range.

[0183] For each selected row, extract the corresponding feature column data based on the featureIDs list. Simultaneously, extract the timestamp and label encoding columns at fixed intervals.

[0184] Organize the extracted data into a structured response format.

[0185] Set the response format to a JSON array, where each object represents a row of the original matrix (or a snapshot of data at a point in time) that meets the time range, containing the following key-value pairs:

[0186] timestamp: The timestamp string corresponding to this line.

[0187] features: An object whose key is the requested feature number (in string form, such as "4", "5") and the value is the corresponding feature value (floating-point number).

[0188] label: The cluster label code (integer) corresponding to this row.

[0189] Query Example: Suppose a user initiates a query request with the following parameters: startTime = "2025-04-24T14:30:00Z" endTime = "2025-04-24T15:10:00Z" featureIDs = [4, 6]

[0190] Interface execution logic:

[0191] Filter the rows in Table 3 with timestamps between 14:30:00Z and 15:10:00Z to get two rows corresponding to 14:39:00 and 15:05:00.

[0192] For row 14:39:00, extract features 4 (65.43) and 6 (0.00), as well as label (1).

[0193] For row 15:05:00, extract features 4 (68.10) and 6 (0.00), as well as label (1).

[0194] Organize it into a JSON response.

[0195] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A cloud-based voice call data analysis system, characterized in that, The system includes: The signaling acquisition module is used to obtain the number of node hops, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. After performing time window slicing, it stores the data in the cloud time series database, generates a cloud signaling time series dataset, and transmits it to the stability assessment module. The stability assessment module is used to call the sliding window interpolation algorithm to calculate the difference of three consecutive hop transfer rates between the node hop count and the response delay in the cloud signaling time series dataset, mark the path segments that meet the threshold, generate path stability segment labels, and pass them to the dynamic compression module. The dynamic compression module is used to filter path segments based on the path stability segmentation labels, perform distributed mean calculation on the response delay of all nodes in the segment, generate a cloud compression feature vector set, and transmit the cloud compression feature vector set and the cloud signaling time series dataset to the abnormal trajectory clustering module. The abnormal trajectory clustering module is used to extract the state maintenance time, the timeout ratio, and the number of retransmissions. It performs trajectory offset detection through a distributed K-means algorithm based on the cloud platform, generates abnormal trajectory clustering labels, and transmits them to the cloud feature library module. The signaling acquisition module includes: The signaling acquisition submodule obtains the node hop count, response latency, state maintenance time, timeout ratio, and retransmission count of the call link through distributed acquisition nodes deployed on the cloud platform. It performs cross-regional clock synchronization calibration on the timestamps in the raw data, calculates the average of multiple indicators based on a sliding window and removes data points that deviate from the average by more than 3 times the standard deviation, calculates the correlation coefficient between node hop count and response latency, and generates a group of node performance indicators. The data points that deviate from the mean by more than 3 times the standard deviation are determined based on statistical analysis of historical network jitter data. The timing slicing submodule counts the number of node hops in segments according to the node performance index group and a fixed time window length. It uses the moving average method to eliminate instantaneous fluctuations in response latency and converts the timeout ratio and retransmission count into percentage values ​​based on the proportion of event triggers within the window to generate window timing parameters. The moving average method uses a window length of 5 seconds and the weights are distributed with exponential decay. The cloud storage submodule calls the window timing parameters to convert the node hop count into an integer sequence code, maps the response latency and state maintenance time to double-precision floating-point values, and writes the timeout ratio and retransmission count into the statistics field according to the preset label classification rules to generate a cloud signaling timing dataset.

2. The cloud-based voice call data analysis system according to claim 1, characterized in that, The path stability segmentation label includes the difference in transfer rate for three consecutive hops, the segment that meets the rate difference threshold, and the path stability level identifier. The cloud compression feature vector set specifically refers to the filter path segment identifier, the distributed mean response latency, and the compression window latency distribution. The abnormal trajectory clustering label includes the offset trajectory cluster identifier, the state maintenance time offset, the timeout ratio cluster center, and the abnormal retransmission threshold. The distributed acquisition nodes deployed on the cloud platform work in conjunction with the sliding window interpolation algorithm to reduce network jitter interference and improve path selection accuracy. The initial cluster centers of the cloud-based distributed K-means algorithm are 5 randomly selected sample points, and the convergence condition is that the center offset is less than 0.5%.

3. The cloud-based voice call data analysis system according to claim 2, characterized in that, The stability assessment module includes: The transfer rate calculation submodule calls the node hop count and the response delay field of the cloud signaling time series dataset, extracts the hop count difference and delay difference of three consecutive hops in time order, divides the hop count difference with the response delay difference, calculates the change in hop count per unit delay within each window, and generates a transfer rate difference sequence. The delay difference values ​​are uniformly converted to milliseconds. The path marking submodule sets the path stability threshold as the absolute fluctuation limit of the difference between two consecutive windows based on the transfer rate difference sequence. It iterates through all differences in the sequence, records the start and end timestamps of windows that continuously exceed the threshold, merges adjacent window intervals with timestamp intervals less than a preset value, and generates an abnormal path segment identifier. The absolute fluctuation limit is determined by calculating the moving average of the differences in the first 10% window; The path label generation submodule calls the abnormal path segment identifier, extracts the starting hop count, ending hop count, and average difference of each path segment, divides the stability level according to the preset interval where the average difference is located, and concatenates the level number with the path segment position code into a string to generate path stability segment labels.

4. The cloud-based voice call data analysis system according to claim 3, characterized in that, The dynamic compression module includes: The path filtering submodule calls the path stability segmentation label, traverses the stability level number corresponding to the path segment code in the label, compares the number with the preset path stability threshold item by item, filters the path segment code with the number greater than the threshold, and at the same time extracts the node hop count and delay field storage address of the corresponding path segment from the cloud signaling time series dataset according to the code to generate the filtered path segment identifier. The mean calculation submodule divides the nodes within the path segment into continuous intervals according to the hop count from low to high based on the filtered path segment identifier. It accumulates the response delay value of the nodes in each interval and counts the number of nodes. The sum of the delays is divided by the number of nodes to obtain the mean of a single interval. At the same time, the mean is combined with the number of hops at the beginning and end of the interval to form a three-dimensional parameter set to generate the node delay mean. The vector generation submodule calls the node latency mean, converts the starting hop count into an integer index value, maps the latency mean to four decimal places as a floating-point value, adds the ending hop count to the index value to generate a composite index key, and integrates it with the latency mean according to field type to generate a cloud compressed feature vector.

5. The cloud-based voice call data analysis system according to claim 4, characterized in that, The abnormal trajectory clustering module includes: The feature extraction submodule calls the state maintenance time, timeout ratio, and retransmission count fields, normalizes the values ​​of multiple fields according to the path segment number, and concatenates the normalized field values ​​into a multi-dimensional vector according to the path segment order to generate trajectory feature parameters. The normalization process uses the Min-Max formula to map the values ​​to the [0,1] interval; Based on the trajectory feature parameters, the clustering calculation submodule uses a cloud-based distributed K-means algorithm to randomly select initial cluster centers, calculates the sum of squared Euclidean distances between all vectors and cluster centers, assigns vectors to the nearest cluster center, recalculates the mean of all vectors in each cluster as the new center, iterates until the change in center position is lower than the preset convergence condition, and generates trajectory cluster centers. The clustering label generation submodule calls the trajectory clustering center, counts the proportion of path segments in each cluster, filters the cluster numbers whose proportion is lower than the preset abnormal threshold, maps the path segments under the corresponding cluster to an integer label sequence, and generates abnormal trajectory clustering labels.

6. The cloud-based voice call data analysis system according to claim 5, characterized in that, The system also includes: The cloud feature library module is used to associate the cloud compressed feature vector set with the abnormal trajectory clustering label in time series and store it in the elastic storage service, generate a cloud call behavior feature matrix, and provide query services to the outside world through the cloud API interface; The cloud call behavior feature matrix specifically includes a time-series correlation feature vector, a clustering label index, an elastic storage service address identifier, and a cloud API interface access key.

7. The cloud-based voice call data analysis system according to claim 6, characterized in that, The cloud feature library module includes: The associated storage submodule calls the cloud compressed feature vector and the abnormal trajectory clustering label, extracts the timestamp field of both, sorts the timestamps in ascending order and matches the corresponding feature vector storage address and label storage address, binds the floating-point value of the feature vector and the integer code of the label in the order of timestamp and stores them in the elastic storage service to generate the associated feature dataset. The matrix generation submodule extracts all floating-point values ​​in the order of timestamps to construct row vectors based on the associated feature dataset. Integer codes are appended to the end of the row vectors as independent columns. Fields with missing values ​​or data type conflicts in the row vectors are detected and deleted. The verified row vectors are arranged into a two-dimensional structure according to the time series to generate a cloud call behavior feature matrix. The interface configuration submodule calls the cloud call behavior feature matrix, defines the matrix row index as the timestamp field, the column index as a combination of the feature number field and the tag code field, configures the parameter input format of the query interface as the starting value of the time range and the list of feature numbers, and generates the cloud feature query interface.

Images