Big data-based mobile network device fault detection method and system, electronic device, and storage medium

Abstract

The application discloses a mobile network device fault detection method and system based on big data, an electronic device and a storage medium, and relates to the technical field of network fault detection. The method acquires the coordinates and acceleration of a mobile node and the CPU utilization and queue depth of a detected node in real time; based on the coordinates of multiple mobile nodes, a Long Short-Term Memory (LSTM) model is used to calculate predicted coordinates, the predicted coordinates are corrected according to the acceleration to obtain a transmission time delay prediction value; the sliding average is calculated based on multiple CPU utilizations, and the service time delay prediction value is obtained in combination with the queue depth; the CPU load variance is calculated, the weights of the transmission stage and the service stage are adjusted, and the timeout threshold is obtained in combination with the safety coefficient; the fault detection is performed according to the timeout threshold, the actual response time delay is recorded, the safety coefficient is adjusted according to the actual response time delay, and the network fault detection is completed. The transmission time delay prediction error is reduced, the timeout threshold is compressed, and the fault detection response speed is improved.

Description

Technical Field

[0001] This application relates to the field of network fault detection technology, specifically to a method and system for mobile network device fault detection based on big data, as well as electronic devices and storage media. Background Technology

[0002] Mobile network devices refer to devices equipped with Mobile Ad Hoc Networks (MANETs), such as drones, vehicles, and ships. Mainstream fault detection methods rely on specific message timeout mechanisms for fault determination. When the total delay from message transmission to reception exceeds a preset timeout threshold, a timeout is considered established, indicating a fault. However, for scenarios involving changes in the relative positions of mobile nodes within MANETs, ​​traditional fault detection methods divide the detection process into three stages: detection message transmission, service processing, and response message transmission. This fault detection process suffers from insufficient adaptability, large decision errors, and untimely responses.

[0003] The root cause lies in the mismatch between trajectory prediction and load perception models. The trajectory prediction algorithm relies on linear extrapolation of historical location data, but in reality, mobile nodes often exhibit non-linear movements such as sharp turns, acceleration, and deceleration, as seen in obstacle avoidance by vehicles and turning maneuvers. Linear models cannot fit sudden changes in motion states, leading to accumulated errors in transmission latency prediction during the packet transmission phase. Furthermore, latency prediction during the business processing phase uses only historical averages, ignoring real-time resource fluctuations such as CPU / memory peaks and queue depth delays. When the tested node experiences a sudden high load, the static prediction value deviates significantly from the actual processing latency, resulting in increased latency during the business processing phase. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for fault detection of mobile network devices based on big data, as well as electronic devices and storage media, to solve the problems mentioned in the background art.

[0005] In a first aspect, one embodiment of this application provides a method for mobile network device fault detection based on big data. The method includes: real-time acquisition of the coordinates and acceleration of a mobile node; real-time acquisition of the CPU utilization and queue depth of the node being detected; calculation of the predicted coordinates of the mobile node at the next moment using a Long Short-Term Memory (LSTM) model based on the coordinates of multiple mobile nodes; correction of the predicted coordinates based on the acceleration; obtaining a transmission delay prediction value based on the corrected predicted coordinates; calculating a moving average based on multiple CPU utilization values; obtaining a service delay prediction value based on the moving average and queue depth; real-time calculation of the CPU load variance; determining a weight allocation strategy for the transmission stage and the service stage based on the currently calculated CPU load variance; obtaining a timeout threshold based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value, and a safety factor; performing fault detection based on the timeout threshold; recording the actual response delay; adjusting the safety factor based on the actual response delay; and completing network fault detection.

[0006] In conjunction with the first aspect, in some implementations of the first aspect, based on the coordinates of multiple mobile nodes, the predicted coordinates of the mobile nodes at the next moment are calculated using a Long Short-Term Memory (LSTM) network model. The predicted coordinates are then corrected based on acceleration, including: constructing a historical trajectory coordinate sequence from the coordinates of multiple mobile nodes; if the coordinates of a mobile node are missing, they are filled using linear interpolation; using the historical trajectory coordinate sequence as an input vector, the predicted coordinates of the mobile nodes at the next moment are calculated using the LSTM model; based on acceleration, the gravitational acceleration component is removed and transformed to the UTM coordinate system direction to obtain a planar acceleration vector; based on the predicted coordinates and the planar acceleration vector, the predicted coordinates are dynamically corrected using a Kalman filter algorithm to obtain the corrected predicted coordinates.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, a moving average is calculated based on multiple CPU utilization rates. Based on the moving average and queue depth, a predicted service latency value is obtained. This includes: judging multiple CPU utilization rates; if a CPU utilization rate exceeds the range, it is considered an outlier and replaced with a valid value from the previous moment, forming a CPU utilization sequence; calculating the moving average based on the CPU utilization sequence; if the queue depth is less than 0, setting the queue depth to 0; calculating the CPU load factor based on the moving average; obtaining the basic service latency and average data packet processing time based on the service type identifier of the detected node; and calculating the predicted service latency value based on the CPU load factor, queue depth, basic service latency, and average data packet processing time.

[0008] In conjunction with the first aspect, in some implementations of the first aspect, a weight allocation strategy for the transmission stage and the service stage is determined based on the currently calculated CPU load variance. Based on the determined weight allocation strategy, and combined with the predicted transmission delay, predicted service delay, and a safety factor, a timeout threshold is obtained. This includes: comparing the CPU load variance with a preset variance threshold; selecting one from a predefined set of weight allocation strategies as the current weight allocation strategy based on the comparison result; performing a weighted summation of the predicted transmission delay and predicted service delay based on the respective weights of the transmission stage and the service stage to obtain a comprehensive predicted delay; and calculating the comprehensive predicted delay and the safety factor to obtain the timeout threshold.

[0009] In conjunction with the first aspect, in certain implementations of the first aspect, fault detection is performed based on a timeout threshold, the actual response delay is recorded, and the safety factor is adjusted based on the actual response delay. This includes: when a detection node sends a detection message to a detected node, the detection node records the sending time; the detection node listens to the network interface and checks whether a response message matching the identity of the detected node is received; if the detection node receives a response message, it records the receiving time and calculates the actual response delay based on the sending time; if the detection node does not receive a response message, it continues to check until the current time is greater than or equal to the sum of the sending time and the timeout threshold, and is then determined to be in a fault state; the relative error is calculated based on the actual response delay, the predicted transmission delay, and the predicted service delay; if the number of consecutive successful receptions of response messages reaches a preset number, the safety factor is adjusted based on the comparison between the relative error and the error threshold.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the coordinates and acceleration of the mobile node are obtained in real time, and the CPU utilization and queue depth of the detected node are obtained in real time, including: obtaining the latitude and longitude coordinates and acceleration of the mobile node in real time, and obtaining the CPU utilization and queue depth of the detected node in real time; converting the latitude and longitude coordinates into coordinates, which are Cartesian coordinates in the UTM coordinate system; if the acceleration is greater than the physical threshold, the average value of the predicted acceleration at the previous moment and the current moment is used for replacement; normalizing the CPU utilization to obtain the normalized CPU utilization, and normalizing the queue depth to obtain the normalized queue depth.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, based on the coordinates of multiple mobile nodes, the predicted coordinates of the mobile nodes at the next time step are calculated using a Long Short-Term Memory (LSTM) network model. This includes: using the historical trajectory coordinate sequence as an input vector, passing it through the forget gate of the LSTM model to obtain key historical information; updating the cell state based on the key historical information through the input gate of the LSTM model to obtain the current cell state; generating the current hidden state based on the current cell state through the output gate of the LSTM model, and mapping the current hidden state to two-dimensional plane coordinates through the fully connected layer of the LSTM model; and restricting the two-dimensional plane coordinates within a physically feasible range to obtain the predicted coordinates of the mobile nodes at the next time step.

[0012] Secondly, this application provides a mobile network device fault detection system based on big data, implemented using an LSTM model, comprising: a data acquisition module for real-time acquisition of the coordinates and acceleration of mobile nodes, and real-time acquisition of the CPU utilization and queue depth of the detected node; a transmission delay prediction module for calculating the predicted coordinates of the mobile node at the next moment based on the coordinates of multiple mobile nodes using a Long Short-Term Memory (LSTM) network model, correcting the predicted coordinates based on acceleration, and obtaining the transmission delay prediction value based on the corrected predicted coordinates; a service delay prediction module for calculating the moving average based on multiple CPU utilizations, and obtaining the service delay prediction value based on the moving average and queue depth; a decision fusion module for real-time calculation of CPU load variance, determining the weight allocation strategy for the transmission stage and the service stage based on the currently calculated CPU load variance, and obtaining a timeout threshold based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value, and a safety factor; and a fault determination module for performing fault detection based on the timeout threshold, recording the actual response delay, adjusting the safety factor based on the actual response delay, and completing network fault detection.

[0013] Thirdly, this application provides an electronic device, including: a processor; and a memory, in which computer program instructions are stored, which, when executed by the processor, implement the steps in the big data-based mobile network device fault detection method mentioned in the first aspect.

[0014] Fourthly, this application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, cause the processor to perform the steps in the big data-based mobile network device fault detection method mentioned in the first aspect.

[0015] The mobile network device fault detection method based on big data provided in this application solves the problem of large latency prediction errors caused by sudden changes in node movement and service fluctuations in mobile scenarios in traditional fault detection methods through a phased heterogeneous prediction model and dynamic load quantization mechanism. It reduces transmission latency prediction errors, realizes real-time dynamic quantization of service latency, compresses timeout thresholds, and improves fault detection response speed. Attached Figure Description

[0016] Figure 1 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in an exemplary embodiment of this application.

[0017] Figure 2 The diagram shown is a flowchart of a mobile network device fault detection method based on big data provided in another exemplary embodiment of this application.

[0018] Figure 3 The diagram shown is a flowchart of a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application.

[0019] Figure 4 The diagram shown is a flowchart of a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application.

[0020] Figure 5 The diagram shown is a flowchart of a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application.

[0021] Figure 6 The diagram shown is a flowchart of a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application.

[0022] Figure 7 The diagram shown is a flowchart of a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application.

[0023] Figure 8 The diagram shown is a structural schematic of a mobile network device fault detection system based on big data provided in an exemplary embodiment of this application.

[0024] Figure 9 The diagram shown is a structural schematic of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The following is combined with Figures 1 to 7 This application provides a detailed description of a mobile network device fault detection method based on big data.

[0027] Figure 1 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in an exemplary embodiment of this application. Figure 1 As shown in the figure, the mobile network device fault detection method based on big data provided in this application includes the following steps.

[0028] Step 100: Obtain the coordinates and acceleration of the moving node in real time, and obtain the CPU utilization and queue depth of the detected node in real time.

[0029] For example, a mobile node refers to a device equipped with a Mobile Ad Hoc Network (MANET). In this embodiment, two mobile nodes within each other's wireless communication range in the communication network are used as an example. The following description will use a simple scenario of two nodes to illustrate the method. The mobile nodes include a detection node and a detected node. Taking mobile node A and mobile node B as examples, they are respectively the detection node and the detected node.

[0030] For example, coordinates refer to plane rectangular coordinates in the Universal Transverse Mercator (UTM) coordinate system. The UTM coordinate system is a geographic projection system that converts latitude and longitude coordinates on the Earth's surface into plane rectangular coordinates. Transmission delay prediction depends on the position sequence of mobile nodes. The UTM coordinate system ensures that the coordinates of all mobile nodes are in the same plane rectangular reference system, and that two mobile nodes A and B are in the same UTM projection zone.

[0031] For example, queue depth refers to the number of network packets that are waiting to be processed within a mobile node for transmitting data information between mobile nodes.

[0032] Step 102: Based on the coordinates of multiple mobile nodes, calculate the predicted coordinates of the mobile nodes at the next time step using an LSTM model, and correct the predicted coordinates according to the acceleration.

[0033] For example, the LSTM model refers to a deep learning algorithm for trajectory prediction. It takes a sequence of historical trajectory coordinates as input and outputs predicted coordinates for future moments. Through the coordinated control of the forget gate, input gate, and output gate, it learns acceleration changes and turning trends.

[0034] Step 104: Based on the corrected prediction coordinates, obtain the predicted transmission delay value.

[0035] For example, predicted coordinates refer to the position coordinates obtained by using an LSTM model to filter and summarize patterns from the historical motion data of a mobile node, and then predicting the position of the mobile node at the next moment based on these summarized patterns.

[0036] For example, the transmission delay prediction value refers to the estimated time it takes for a detection message to propagate in a wireless channel, which is the one-way propagation time of the signal from the detection node to the detected node.

[0037] Step 106: Calculate the moving average based on multiple CPU utilization rates, and obtain the predicted service latency value based on the moving average and queue depth.

[0038] For example, the moving average is a statistic that smooths the short-term trend of CPU utilization, used to suppress transient fluctuations in CPU usage and provide a stable input for the CPU load factor.

[0039] For example, the business latency prediction value refers to the estimated amount of time it takes for the monitored node to process the detection message.

[0040] Step 108: Calculate the CPU load variance in real time. Based on the calculated CPU load variance, determine the weight allocation strategy for the transmission stage and the service stage. Based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value, and the safety factor, obtain the timeout threshold.

[0041] For example, the timeout threshold refers to the critical time threshold for fault determination, which integrates transmission delay and service delay prediction values, triggers weight switching through CPU load variance, and adds a safety margin.

[0042] It should be understood that the decision information for weights (CPU load variance) must be obtained and used before or simultaneously with the calculation of the predicted values ​​in order to transform the weight adjustment into a decision based on historical states.

[0043] Step 110: Perform fault detection based on the timeout threshold, record the actual response delay, adjust the safety factor based on the actual response delay, and complete the network fault detection.

[0044] For example, the actual response latency refers to the measured time taken for the detected node to return a response message from receiving the detection message. It serves as the direct basis for fault judgment and drives the adaptive adjustment of the safety factor.

[0045] The mobile network device fault detection method based on big data provided in this application solves the problem of large latency prediction errors caused by sudden changes in node movement and service fluctuations in mobile scenarios in traditional fault detection methods through a phased heterogeneous prediction model and dynamic load quantization mechanism. It reduces transmission latency prediction errors, realizes real-time dynamic quantization of service latency, compresses timeout thresholds, and improves fault detection response speed.

[0046] Figure 2 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 2 The illustrated embodiment will be described in detail below. Figure 2 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0047] like Figure 2 As shown in the embodiments of this application, the method for mobile network device fault detection based on big data calculates the predicted coordinates of the mobile nodes at the next moment using an LSTM model based on the coordinates of multiple mobile nodes, and corrects the predicted coordinates according to the acceleration, including the following steps.

[0048] Step 200: The coordinates of multiple moving nodes are used to form a historical trajectory coordinate sequence. If the coordinates of a moving node are missing, linear interpolation is used to fill them.

[0049] Specifically, the Cartesian coordinates of N mobile nodes A and B are obtained from the trajectory data to form the historical trajectory coordinate sequences NodeA_History and NodeB_History, where N is the number of sampling points and the value of N ranges from [5, 20]. If the coordinate value of a certain sampling point is missing, it is filled by linear interpolation.

[0050] The historical trajectory coordinate sequence of mobile node A, NodeA_History: {(x_A t-N y_A t-N ), (x_A t-N+1 y_A t -N+1 ), ..., (x_A t y_A t )}; The historical trajectory coordinate sequence of mobile node B, NodeB_History: {(x_B t-N y_B t-N ), (x_B t-N+1 y_B t -N+1), ..., (x_B t y_B t )}; Where t represents the sampling point at the current time.

[0051] For example, the number of sampling points N should not be too small or too large. If it is too small, the prediction accuracy will decrease, and if it is too large, the model's time consumption will increase.

[0052] For example, linear interpolation is used to handle scenarios where the sensor fails temporarily, improving the robustness of the model.

[0053] Step 202: Using the historical trajectory coordinate sequence as the input vector, the predicted coordinates of the moving node at the next moment are calculated using the LSTM model.

[0054] Specifically, the historical trajectory coordinate sequence NodeA_History of mobile node A is used as the input vector. A Long Short-Term Memory (LSTM) network model is used to parse the input vector step by step. The motion pattern is learned through a gating mechanism to calculate the predicted coordinates of the mobile node at the next moment.

[0055] Step 204: Based on the acceleration, remove the gravitational acceleration component and transform it to the UTM coordinate system direction to obtain the planar acceleration vector.

[0056] Specifically, the historical trajectory coordinate sequence NodeB_History of mobile node B is used as the input vector, and the predicted coordinates of mobile node B are calculated through the LSTM model. X pred _B, Y pred _B). Obtain the current triaxial acceleration (Acc_x) of moving nodes A and B from the trajectory data. A Acc_y A Acc_z A ) and (Acc_x B Acc_y B Acc_z B Remove the gravitational acceleration component in the Z-axis direction and transform it to the UTM coordinate system direction to obtain the planar acceleration vector IMU_Vector = {A: (acc_x_A, acc_y_A), B: (acc_x_B, acc_y_B)}.

[0057] For example, removing the gravitational acceleration component in the Z-axis direction is to avoid acceleration errors caused by driving on slopes and improve correction accuracy.

[0058] Step 206: Based on the predicted coordinates and the planar acceleration vector, the predicted coordinates are dynamically corrected using the Kalman filter algorithm to obtain the corrected predicted coordinates.

[0059] Specifically, based on the predicted coordinates of mobile node A ( X pred _A, Y pred The predicted coordinates are dynamically corrected using the Kalman filter algorithm, based on the plane acceleration vector (_A) and the planar acceleration vector (IMU_Vector), to obtain the corrected predicted coordinates. X corr _A, Y corr _A).

[0060] X corr _A = X pred _A + K x × (0.5 × acc_x_A × Δt 2 ); Y corr _A = Y pred _A + K y × (0.5 × acc_y_A × Δt 2 ); in, K x and K y This represents the Kalman gain coefficient; (0.5 × acc_x_A × Δt) 2 (0.5 × acc_y_A × Δt) represents the displacement increment of uniformly accelerated motion in the X-axis direction. 2 ) represents the displacement increment of uniformly accelerated motion in the Y-axis direction.

[0061] For example, the Kalman filter algorithm refers to the algorithm used when a mobile node undergoes nonlinear motion such as sharp turns, acceleration, or deceleration. The LSTM model may accumulate errors due to its reliance on historical trajectories. The algorithm uses the real-time acceleration of the Inertial Measurement Unit (IMU) as the observation value and dynamically adjusts the predicted coordinates output by the LSTM model through a two-stage prediction-update process to suppress the accumulated errors of the LSTM model and adapt to sudden acceleration and deceleration scenarios.

[0062] Based on the predicted coordinates of mobile node B ( X pred _B, Ypred Using the planar acceleration vector IMU_Vector, we obtain the corrected predicted coordinates of the moving node B. X corr _B, Y corr _B).

[0063] X corr _B = X pred _B + K x × (0.5 × acc_x_B × Δt 2 ); Y corr _B = Y pred _B + K y × (0.5 × acc_y_B × Δt 2 ); Based on the corrected predicted coordinates of mobile nodes A and B, calculate the predicted distance D at the next time step (prediction time). pred .

[0064] D pred = sqrt(( X corr _A - X corr _B) 2 + ( Y corr _A - Y corr _B) 2 ); For example, in the embodiments of this application, the distance calculation between mobile nodes is based on planar geometry, and the elevation difference has been ignored.

[0065] Finally, based on the predicted distance D between mobile nodes A and B pred Calculate the predicted transmission delay value T 1.

[0066] T 1 = D pred / c); Where c represents the propagation speed of electromagnetic waves, and in this embodiment, c = 3 × 10⁻⁶. 8 m / s.

[0067] The mobile network device fault detection method based on big data provided in this application solves the problem of cumulative error in nonlinear motion scenarios such as sharp turns and acceleration / deceleration by using a fusion model of LSTM long-term trajectory prediction and Kalman filter real-time correction. This reduces the prediction error in scenarios of sudden motion changes and improves the accuracy of timeout threshold.

[0068] Figure 3 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 3 The illustrated embodiment will be described in detail below. Figure 3 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0069] like Figure 3 As shown in the embodiment of this application, the mobile network device fault detection method based on big data calculates the moving average based on multiple CPU utilization rates, and obtains the service latency prediction value based on the moving average and queue depth, including the following steps.

[0070] Step 300: Determine multiple CPU utilization values. If a CPU utilization value exceeds the range, it is considered an outlier and replaced with a valid value from the previous moment to form a CPU utilization sequence.

[0071] Specifically, N normalized CPU utilization values ​​CpuNorm_B are obtained from the load data. If the normalized CPU utilization value CpuNorm_B of mobile node B exceeds the range of [0, 1], it is considered an outlier and replaced with the valid value of the previous time step. The N verified normalized CPU utilization values ​​CpuNorm_B are used to form a CPU utilization sequence.

[0072] CPU utilization sequence: {CpuNorm_B[tN], CpuNorm_B[t-N+1], ..., CpuNorm_B[t]}; Where N is the number of sampling points, and the value of N ranges from [5, 20]; t represents the sampling point at the current time.

[0073] Step 302: Calculate the moving average based on the CPU utilization sequence. If the queue depth is less than 0, set the queue depth to 0.

[0074] Specifically, based on the CPU utilization sequence, calculate the moving average CpuAvg_B of the N normalized CPU utilization CpuNorm_B within the window.

[0075] CpuAvg_B = (CpuNorm_B[tN] + CpuNorm_B[t-N+1]+ ... + CpuNorm_B[t]) / N; For example, a sliding window is used to smooth out instantaneous CPU fluctuations, reflecting short-term trends in CPU load. The window size N is used to balance real-time performance and stability.

[0076] Obtain the normalized queue depth QueueNorm_B at the current moment from the load data. If the normalized queue depth QueueNorm_B of the moving node B is less than 0, then force QueueNorm_B = 0.

[0077] For example, data validation ensures the validity of input data and prevents outliers from causing prediction distortion. A negative queue depth may be caused by sensor errors or transmission errors.

[0078] Step 304: Calculate the CPU load factor based on the moving average, and obtain the basic service latency and average data packet processing time based on the service type identifier of the detected node.

[0079] Specifically, the CPU load factor CpuFactor_B is calculated based on the moving average CpuAvg_B.

[0080] CpuFactor_B = λ × CpuAvg_B; in, λ This represents the temperature decay coefficient, with a value range of [0, 1], used to suppress the excessive influence of CPU utilization fluctuations on prediction. λ The smaller the value, the lower the sensitivity to mutations. In the embodiments of this application, it is set as follows: λ = 0.8.

[0081] For example, the temperature attenuation coefficient is equivalent to a "low-pass filter" to prevent sudden high loads from causing drastic changes in the predicted service latency.

[0082] Based on the service type identifier of mobile node B, the basic latency mapping table for the service type is queried to obtain the service base latency τ_base, and the average processing time τ_pkt for a single data packet of mobile node B is obtained from the historical statistics database. The service types include video streaming services, file transfer services, and sensor data services.

[0083] For example, the basic latency mapping table refers to the basic latency of a computer processing various services when resources are sufficient and the network is stable. It is stored in a historical statistical database. The service type in the basic latency mapping table corresponds one-to-one with the basic latency. Among them, the basic latency of video streaming service is 0.02 seconds, the basic latency of file transfer service is 0.015 seconds, and the basic latency of sensor data service is 0.005 seconds.

[0084] For example, τ_base represents the inherent processing overhead of the business, while τ_pkt is determined by hardware performance; both are preset constants.

[0085] Step 306: Calculate the predicted service latency based on CPU load factor, queue depth, basic service latency, and average data packet processing time.

[0086] Specifically, the predicted service latency is calculated based on the CPU load factor CpuFactor_B, the normalized queue depth QueueNorm_B, the service base latency τ_base, and the average packet processing time τ_pkt. T 2.

[0087] T 2= ​​τ_base × (1 + CpuFactor_B) + QueueNorm_B × τ_pkt; For example, the CPU load factor is used as an "amplifier" of the base latency; the higher the CPU load, the higher the base latency. The processing time for queue backlogs is added as an additional factor, with each queued network packet adding a fixed processing time.

[0088] For example, CPU load is modeled by decoupling queue depth to quantify the nonlinear response characteristics of business latency.

[0089] The mobile network device fault detection method based on big data provided in this application solves the problem of lack of load fluctuation perception caused by the reliance on historical trajectory averages during the service phase through a dynamic load factor model (CPU moving average × attenuation coefficient + queue depth × packet processing). It completely abandons trajectory data and independently quantifies the nonlinear impact of CPU / queue on latency.

[0090] Figure 4 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 4 The illustrated embodiment will be described in detail below. Figure 4 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0091] like Figure 4 As shown in the embodiment of this application, the mobile network device fault detection method based on big data determines the weight allocation strategy for the transmission stage and the service stage based on the currently calculated CPU load variance. Based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value and the safety factor, a timeout threshold is obtained, including the following steps.

[0092] Step 400: Compare the CPU load variance with a preset variance threshold.

[0093] Specifically, the CPU utilization sequence and moving average are acquired in real time, and the CPU load variance CpuVar_B is calculated based on the CPU utilization sequence {CpuNorm_B[tN], CpuNorm_B[t-N+1], ..., CpuNorm_B[t]} and the moving average CpuAvg_B.

[0094] ; in, k Indicates the first k CPU utilization for each sample, k = 1, 2, 3, ..., N.

[0095] For example, CPU load variance is used to measure the degree of fluctuation in CPU utilization. The larger the variance, the more drastic the fluctuation in CPU load. In this case, the weight of latency prediction for the business phase should be reduced, because fluctuation will lead to a decrease in prediction reliability.

[0096] Step 402: Based on the comparison results, select one of the predefined weight allocation strategies as the current weight allocation strategy.

[0097] If the CPU load variance is greater than the load variance threshold, then set the weights for the first transmission stage and the first service stage. If the CPU load variance is less than or equal to the load variance threshold, then set the weights for the second transmission stage and the second service stage.

[0098] Specifically, the weights of the transmission and service stages are adjusted based on the CPU load variance CpuVar_B. If the CPU load variance CpuVar_B is greater than the load variance threshold δ, the weight of the transmission stage is set to W1 = 0.7, and the weight of the service stage is set to W2 = 0.3. If the CPU load variance CpuVar_B is less than or equal to the load variance threshold δ, the weight of the transmission stage is set to W1 = 0.6, and the weight of the service stage is set to W2 = 0.4.

[0099] In this embodiment of the application, the load variance threshold δ = 5 is set.

[0100] For example, when the CPU load fluctuates greatly (CpuVar_B>5), the reliability of the service processing latency decreases, so its weight is reduced (from 0.4 to 0.3), while the weight of the transmission latency is increased (from 0.6 to 0.7), making the overall prediction more dependent on the transmission latency.

[0101] Step 404: Based on the respective weights of the transmission stage and the service stage, the predicted transmission delay and the predicted service delay are weighted and summed to obtain the comprehensive predicted delay.

[0102] Specifically, based on the transmission stage weight W1 and the service stage weight W2, the predicted delay values ​​for the two stages are weighted and summed to obtain the comprehensive predicted delay. T total .

[0103] T total = W1× T 1+ W2× T 2; For example, the stage delays of two independently predicted stages are merged into a single overall delay prediction value, which serves as the basis for the timeout threshold.

[0104] Step 406: Set a safety factor for the comprehensive predicted delay and perform calculations to obtain the timeout threshold.

[0105] Specifically, it will comprehensively predict latency. T total Set a safety factor α (Initial value 1.2), obtain the timeout threshold TimeOut.

[0106] TimeOut = T total × α ; For example, the safety factor α This is used to tolerate prediction errors and network jitter, avoiding misjudgments caused by predictions being slightly less than actual latency, i.e., classifying normal events as faults.

[0107] The mobile network device fault detection method based on big data provided in this application solves the problem of timeout threshold redundancy caused by the superposition of errors in transmission and service stages through dynamic weight allocation (CPU variance triggers weight switching) and adaptive adjustment of safety factor. The dynamic optimization of weight in high load fluctuation scenarios compresses the threshold error, and the safety factor is adjusted in a closed loop according to the prediction error, which tolerates sudden jitter while avoiding excessive conservatism.

[0108] Figure 5 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 5 The illustrated embodiment will be described in detail below. Figure 5 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0109] like Figure 5 As shown in the embodiment of this application, the method for mobile network device fault detection based on big data includes the following steps: performing fault detection according to a timeout threshold, recording the actual response delay, and adjusting the safety factor according to the actual response delay.

[0110] Step 500: When the detection node sends a detection message to the detected node, the detection node records the sending time.

[0111] Specifically, mobile node A sends a detection message to mobile node B, and mobile node A records the time of transmission. t start .

[0112] For example, a detection message refers to a specific control message sent between mobile nodes to detect the liveness status of a target node. The detection message is actively sent by the detection node (mobile node A in this application), and the node being tested (mobile node B in this application) needs to return a response message after receiving it.

[0113] For example, the precise recording of the sending time is used to calculate the starting point of the time window for waiting for a response, ensuring the accuracy of the timeout judgment benchmark.

[0114] Step 502: The detection node listens to the network interface and checks whether it receives a response message that matches the identity of the detected node.

[0115] It should be understood that mobile node A listens to the network interface and checks whether it receives a response message that matches the identity of mobile node B.

[0116] Step 504: If the detection node receives a response message, the detection node records the receiving time and calculates the actual response delay by combining it with the sending time.

[0117] Step 506: If the detection node does not receive a response message, it continues to check until the current time is greater than or equal to the sum of the sending time and the timeout threshold, and is then determined to be in a fault state.

[0118] Specifically, if a response message is received, mobile node A records the time of reception. t recv And calculate the actual response delay. t real = t recv - tstart If no response message is received, the check will continue until the current time. t now satisfy t now ≥ t start +TimeOut indicates a fault state.

[0119] Step 508: Calculate the relative error based on the actual response delay, the predicted transmission delay, and the predicted service delay.

[0120] Specifically, regarding the case where a response message is received, the actual response delay will be considered. t real The error calculation and safety factor adjustment are carried out, and the specific process includes the following.

[0121] (1) Based on the predicted transmission delay value T 1 and business latency prediction value T 2. Calculate the total predicted delay T pred .

[0122] T pred = T 1+ T 2; (2) Based on the actual response delay t real and predicted total delay T pred Calculate the absolute error θ.

[0123] θ = | t real - T pred |; (3) Based on the absolute error θ and the predicted total delay T pred Calculate the relative error θ rel .

[0124] θ rel = θ / T pred × 100%; Step 510: If the number of consecutive successful reception of response messages reaches the preset number, the security factor is adjusted based on the comparison result of the relative error and the error threshold.

[0125] If three consecutive response messages are received and the relative error is greater than the error threshold, the security factor is updated to the first security factor. If five consecutive response messages are received and the relative error is less than the error threshold, the security factor is updated to the second security factor. If a timeout occurs during continuous reception without receiving a response message, the counter for the number of successful receptions is reset to zero.

[0126] Specifically, if response messages are received three times consecutively and the relative error θ rel If the percentage is greater than 20%, then the update safety factor is: α new = α × 1.1, if five consecutive response messages are received and the relative error θ rel If the percentage is less than 20%, then the safety factor should be updated to: α new =max(1.0, α × 0.95), if it represents either of the above two situations, then the safety factor remains unchanged. α .

[0127] For example, the safety factor α It is a buffer factor that tolerates sudden fluctuations, and adaptive adjustment can balance prediction accuracy and robustness.

[0128] The mobile network device fault detection method based on big data provided in this application solves the problem that static thresholds cannot adapt to long-term network jitter through a timeout judgment and error feedback closed-loop mechanism, and improves the robustness of the system by real-time error-driven model self-optimization.

[0129] Figure 6 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 6 The illustrated embodiment will be described in detail below. Figure 6 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0130] like Figure 6 As shown in the embodiments of this application, the mobile network device fault detection method based on big data obtains the coordinates and acceleration of the mobile node in real time, and obtains the CPU utilization and queue depth of the detected node in real time, including the following steps.

[0131] Step 600: Obtain the latitude and longitude coordinates and acceleration of the mobile node in real time, and obtain the CPU utilization and queue depth of the detected node in real time.

[0132] Specifically, the GPS sensors of mobile nodes A and B acquire their current latitude and longitude coordinates (Lat_A, Lon_A) and (Lat_B, Lon_B), and the IMU sensors of mobile nodes A and B acquire their triaxial acceleration (Acc_x). A Acc_y A Acc_z A ) and (Acc_x B Acc_y B Acc_z B The system monitor of mobile node B collects CPU utilization (CpuUsage_B), memory usage (MemUsage_B), and queue depth (QueueDepth_B) in real time.

[0133] Where Lat_A represents the current longitude of mobile node A; Lon_A represents the current latitude of mobile node A; Acc_x A This represents the X-axis acceleration of the moving node A; Acc_y A This represents the Y-axis acceleration of the moving node A; Acc_z A This represents the Z-axis acceleration of the moving node A.

[0134] For example, the coordinate system of the three-axis acceleration is such that the positive direction of the moving node is the positive direction of the X-axis, the positive direction of the moving node is the right direction of the moving node, and the positive direction of the moving node is the vertical downward direction of the moving node.

[0135] For example, the current latitude and longitude coordinates and triaxial acceleration are used for subsequent trajectory prediction, while CPU utilization, memory usage, and network packet queue depth are used to quantify the resource load status during the business processing phase.

[0136] Step 602: Convert latitude and longitude coordinates into coordinates, which are plane rectangular coordinates in the UTM coordinate system.

[0137] Specifically, the current latitude and longitude coordinates (Lat_A, Lon_A) and (Lat_B, Lon_B) of mobile nodes A and B are converted into Cartesian coordinates (x_A, y_A) and (x_B, y_B) in the UTM coordinate system.

[0138] The coordinate transformation formula is: x = f utm (Lat, Lon), y = g utm (Lat, Lon); where... f utm and g utm The projection function of the UTM coordinate system.

[0139] For example, the projection function of the UTM coordinate system is a conventional technique, and the specific mathematical expression of the transformation will not be elaborated in this embodiment.

[0140] For example, latitude and longitude coordinates are converted to Cartesian coordinates to eliminate the influence of the Earth's curvature and ensure that subsequent distance calculations are based on plane geometry (Euclidean distance) to avoid spherical distance errors.

[0141] Step 604: If the acceleration is greater than the physical threshold, then the average value of the predicted acceleration at the previous moment and the current moment is used for replacement.

[0142] Specifically, if the triaxial accelerations (Acc_x) of moving nodes A and B are... A Acc_y A Acc_z A ) and (Acc_x B Acc_y B Acc_z B If the acceleration exceeds the physical threshold, it is considered sensor noise and replaced by the average of the predicted acceleration from the previous moment and the current moment. The physical threshold refers to the theoretical maximum acceleration obtained from a theoretical simulation experiment in a laboratory setting. In this embodiment, the physical threshold for the X-axis acceleration is set to 12 m / s². 2 The physical threshold for Y-axis acceleration is 8.8 m / s². 2 The physical threshold for Z-axis acceleration is 9.81 m / s². 2 .

[0143] Step 606: Normalize the CPU utilization to obtain normalized CPU utilization, and normalize the queue depth to obtain normalized queue depth.

[0144] Specifically, the CPU utilization CpuUsage_B of mobile node B is scaled to the interval [0, 1] to obtain the normalized CPU utilization CpuNorm_B: CpuNorm_B = CpuUsage_B / 100. The queue depth QueueDepth_B of mobile node B is normalized to obtain the normalized queue depth QueueNorm_B: QueueNorm_B = QueueDepth_B / Max(QueueDepth).

[0145] Where Max(QueueDepth) represents the maximum queue capacity of network data packets in mobile node B, that is, the theoretical upper limit of the queue capacity.

[0146] For example, noise replacement improves the robustness of subsequent predictions, and normalization processing enables data of different dimensions to be calculated uniformly.

[0147] The trajectory data is constructed from multiple Cartesian coordinates and triaxial accelerations of mobile nodes A and B, and the load data is constructed from multiple normalized CPU utilization CpuNorm_B, memory usage MemUsage_B, and normalized queue depth QueueNorm_B.

[0148] The mobile network device fault detection method based on big data provided in this application solves the prediction interference problem caused by the coupling of motion data (GPS / IMU) and load data (CPU / queue) through multi-source heterogeneous data acquisition and preprocessing technology. It realizes the isolation of data sources between the transmission stage and the service stage, coordinate system transformation and normalization processing ensure data consistency, and eliminates spherical distance error and dimensional difference.

[0149] Figure 7 The diagram shown is a flowchart illustrating a mobile network device fault detection method based on big data, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 7 The illustrated embodiment will be described in detail below. Figure 7 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0150] like Figure 7 As shown in the embodiment of this application, the mobile network device fault detection method based on big data uses the historical trajectory coordinate sequence as the input vector and calculates the predicted coordinates of the mobile node at the next moment through the LSTM model, including the following steps.

[0151] Step 700: The historical trajectory coordinate sequence is used as the input vector, and the key historical information is obtained by passing it through the forget gate of the LSTM model.

[0152] Specifically, the forget gate in the LSTM model removes redundant information while retaining key historical information. f t .

[0153] ; in, W f Represents the forget gate weight matrix; h t-1 This indicates the hidden state in the previous moment; x t This represents the coordinate data input at the current moment; b f σ represents the forget gate bias vector; σ represents the Sigmoid activation function with an output range of [0, 1].

[0154] Step 702: Based on key historical information, update the cell state through the input gate of the LSTM model to obtain the cell state at the current moment.

[0155] Specifically, based on key historical information f t The cell state is updated through the input gate of the LSTM model.

[0156] ; ; ; in, I t The input gate output is used as the update ratio; W I This represents the input gate weight matrix; b I This represents the input gate bias vector; C t ′ indicates the candidate cell state, serving as a temporary memory; W C Represents the candidate cell state weight matrix; b C Represents the candidate cell state bias vector; C t Indicates the current state of the cell; This indicates element-wise multiplication.

[0157] Step 704: Based on the cell state at the current time, generate the hidden state at the current time through the output gate of the LSTM model. The fully connected layer of the LSTM model maps the hidden state at the current time to two-dimensional plane coordinates.

[0158] Specifically, based on the current cell state C t The hidden state at the current time step is generated through the output gate of the LSTM model: ; ; in, o t Indicates the output of the output gate; W o This represents the output gate weight matrix; b o This represents the output gate bias vector; h t This represents the hidden state at the current moment; the function tanh() represents the hyperbolic tangent function.

[0159] For example, the hidden state at the current moment is the unprocessed predicted coordinates. Through time step iteration, the LSTM model learns nonlinear motion features such as acceleration changes and turning trends from the historical trajectory coordinate sequence.

[0160] The hidden state at the current time step is obtained from the output gate of the LSTM model. h t The fully connected layers of the LSTM model hide the current state. h t Mapping to two-dimensional plane coordinates ( X pred , Y pred ).

[0161] ( X pred , Y pred ) = W out h t + b out ; in, W out This represents the output layer weight matrix; b out This represents the output layer bias vector.

[0162] For example, in the embodiments of this application, the two-dimensional planar coordinates calculated by the fully connected layer of the LSTM model are ( X pred , Y pred The unprocessed predicted coordinates are called the output coordinates; therefore, the fully connected layer is also called the output layer.

[0163] For example, the fully connected layer decodes high-dimensional motion features into physical coordinates, and in this embodiment, the prediction period Δt = 0.1 seconds is set.

[0164] Step 706: Restrict the two-dimensional plane coordinates to a physically feasible range to obtain the predicted coordinates of the moving node at the next moment.

[0165] Specifically, the two-dimensional plane coordinates ( X pred , Y pred (Limited to physical feasibility)

[0166] X pred = max ( X min , min ( X max , X pred )); Y pred = max ( Y min , min ( Y max , Y pred )); in,[ X min , X max [ represents the X-axis boundary of the UTM coordinate system;] Y min , Y max ] represents the Y-axis boundary of the UTM coordinate system.

[0167] If | X pred - x_A t |>V max 1 Δt indicates the predicted coordinates. X pred The velocity is discontinuous with the current moment; adjust the predicted coordinates. X pred .

[0168] X pred = x_A t + sign( X pred - x_A t ) V max 1 Δt; If | Y pred - y_A t |>V max 2 Δt indicates the predicted coordinates. Y pred The velocity is discontinuous with the current moment; adjust the predicted coordinates. Y pred .

[0169] Y pred = y_A t+ sign( Y pred - y_A t ) V max 2 Δt; Among them, V max 1 V represents the maximum moving speed of node A in the X-axis direction; max 2 This represents the maximum moving speed of node A in the Y-axis direction.

[0170] Two-dimensional plane coordinates ( X pred , Y pred After standardized operations such as restriction and adjustment, the predicted coordinates of the moving node A are obtained. X pred _A, Y pred _A).

[0171] It should be understood that limiting the prediction to a physically feasible range is to avoid the predicted value from exceeding the map boundary or violating the physical velocity constraints, and to ensure that the prediction results conform to the laws of real motion.

[0172] The mobile network device fault detection method based on big data provided in this application uses historical trajectory coordinate sequences as input vectors. The forget gate, input gate, output gate, and fully connected layer of the LSTM model parse the input vectors step by step to learn the learning motion pattern of the mobile node and impose physical constraints on the predicted coordinates. This solves the problem of accumulated error in AMA linear extrapolation in nonlinear motion scenarios such as sharp turns and acceleration / deceleration, and improves the model's prediction accuracy and precision.

[0173] Figure 8 The diagram shown is a structural schematic of a mobile network device fault detection system based on big data, provided in an exemplary embodiment of this application. Figure 8 As shown in the figure, the mobile network device fault detection system based on big data provided in this application embodiment includes: a data acquisition module 800, a transmission delay prediction module 802, a service delay prediction module 804, a decision fusion module 806, and a fault determination module 808.

[0174] The data acquisition module 800 is used to acquire the coordinates and acceleration of mobile nodes in real time, and to acquire the CPU utilization and queue depth of the detected nodes in real time. The transmission delay prediction module 802 is used to calculate the predicted coordinates of the mobile nodes at the next time step based on the coordinates of multiple mobile nodes using a Long Short-Term Memory (LSTM) network model, correct the predicted coordinates based on the acceleration, and obtain the transmission delay prediction value based on the corrected predicted coordinates. The service delay prediction module 804 is used to calculate the moving average based on multiple CPU utilizations, and obtain the service delay prediction value based on the moving average and queue depth. The decision fusion module 806 is used to calculate the CPU load variance in real time, determine the weight allocation strategy for the transmission stage and the service stage based on the currently calculated CPU load variance, and obtain the timeout threshold based on the determined weight allocation strategy, the transmission delay prediction value, the service delay prediction value, and the safety factor. The fault judgment module 808 is used to perform fault detection based on the timeout threshold, record the actual response delay, adjust the safety factor based on the actual response delay, and complete the network fault detection.

[0175] It should be understood that the operation and functions of the relevant modules mentioned in the big data-based mobile network device fault detection system can be referenced above. Figures 1 to 7 The method for detecting mobile network device faults based on big data is provided, and will not be described in detail here to avoid repetition.

[0176] Figure 9 The diagram shown is a structural schematic of an electronic device provided in an exemplary embodiment of this application. Figure 9 As shown, the electronic device 90 includes one or more processors 901 and memory 902.

[0177] The processor 901 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 90 to perform desired functions.

[0178] The memory 902 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 901 may execute the program instructions to implement the acceleration, CPU utilization, and / or other desired functions described in the various embodiments of this application above. Various content such as key historical information and cell states may also be stored in the computer-readable storage medium.

[0179] In one example, the electronic device 90 may also include an input device 903 and an output device 904, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0180] The input device 903 may include, for example, a keyboard, a mouse, etc.

[0181] The output device 904 can output various information to the outside, including network fault status, etc. The output device 904 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0182] Of course, for the sake of simplicity, Figure 9 Only some of the components of the electronic device 90 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 90 may include any other suitable components depending on the specific application.

[0183] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the big data-based mobile network device fault detection method according to various embodiments of this application described above.

[0184] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0185] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the big data-based mobile network device fault detection method according to various embodiments of this application described above.

[0186] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0187] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0188] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0189] It should also be noted that in the apparatus, equipment, and methods of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

[0190] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0191] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for fault detection of mobile network devices based on big data, characterized in that, include: Real-time acquisition of the coordinates and acceleration of moving nodes, and real-time acquisition of the CPU utilization and queue depth of the detected nodes; Based on the coordinates of multiple mobile nodes, the predicted coordinates of the mobile nodes at the next time step are calculated using a Long Short-Term Memory (LSTM) network model, and the predicted coordinates are corrected according to the acceleration. Based on the corrected predicted coordinates, the predicted transmission delay value is obtained; Based on multiple CPU utilization rates, a moving average is calculated, and based on the moving average and the queue depth, a predicted service latency value is obtained. The CPU load variance is calculated in real time. Based on the currently calculated CPU load variance, the weight allocation strategy for the transmission stage and the service stage is determined. Based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value, and the safety factor, the timeout threshold is obtained. Fault detection is performed based on the timeout threshold, the actual response delay is recorded, and the safety factor is adjusted based on the actual response delay to complete network fault detection.

2. The method for mobile network device fault detection based on big data according to claim 1, characterized in that, The method of calculating the predicted coordinates of the mobile nodes at the next time step based on the coordinates of multiple mobile nodes using a Long Short-Term Memory (LSTM) network model, and correcting the predicted coordinates according to the acceleration, includes: The coordinates of multiple mobile nodes are used to form a historical trajectory coordinate sequence. If the coordinates of a mobile node are missing, they are filled with linear interpolation. Using the historical trajectory coordinate sequence as an input vector, the predicted coordinates of the moving node at the next moment are calculated through the LSTM model; Based on the acceleration, the gravitational acceleration component is removed and the direction is transformed to the UTM coordinate system to obtain the planar acceleration vector; Based on the predicted coordinates and the planar acceleration vector, the predicted coordinates are dynamically corrected using a Kalman filter algorithm to obtain the corrected predicted coordinates.

3. The method for mobile network device fault detection based on big data according to claim 1, characterized in that, The process of calculating a moving average based on multiple CPU utilization rates, and obtaining a predicted service latency value based on the moving average and the queue depth, includes: The CPU utilization is determined. If the CPU utilization exceeds the range, it is considered an outlier and replaced with the valid value from the previous moment to form a CPU utilization sequence. Calculate the moving average based on the CPU utilization sequence; if the queue depth is less than 0, then set the queue depth to 0. The CPU load factor is calculated based on the moving average, and the basic service latency and average data packet processing time are obtained based on the service type identifier of the detected node. The predicted service latency is calculated based on the CPU load factor, the queue depth, the service base latency, and the average data packet processing time.

4. The method for mobile network device fault detection based on big data according to any one of claims 1-3, characterized in that, The step involves determining a weight allocation strategy for the transmission and service phases based on the currently calculated CPU load variance. Then, based on the determined weight allocation strategy, and combining the predicted transmission delay, the predicted service delay, and a safety factor, a timeout threshold is obtained, including: The CPU load variance is compared with a preset variance threshold. Based on the comparison results, one of the predefined weight allocation strategies is selected as the current weight allocation strategy. Based on the respective weights of the transmission stage and the service stage, a weighted sum is performed on the predicted transmission delay value and the predicted service delay value to obtain the comprehensive predicted delay. The timeout threshold is obtained by calculating the comprehensive predicted delay and the safety factor.

5. The method for mobile network device fault detection based on big data according to any one of claims 1-3, characterized in that, The step of performing fault detection based on the timeout threshold, recording the actual response delay, and adjusting the safety factor based on the actual response delay includes: When a detection node sends a detection message to the node being detected, the detection node records the time of transmission. The detection node listens to the network interface and checks whether it receives a response message that matches the identity of the detected node. If the detection node receives the response message, the detection node records the reception time and calculates the actual response delay by combining it with the transmission time. If the detection node does not receive the response message, it continues to check until the current time is greater than or equal to the sum of the sending time and the timeout threshold, and is then determined to be in a fault state. The relative error is calculated based on the actual response delay, the predicted transmission delay, and the predicted service delay. If the number of consecutive successful receptions of the response message reaches a preset number, the security factor is adjusted based on the comparison result between the relative error and the error threshold.

6. The method for mobile network device fault detection based on big data according to any one of claims 1-3, characterized in that, The real-time acquisition of the coordinates and acceleration of the moving node, and the real-time acquisition of the CPU utilization and queue depth of the detected node, include: The latitude and longitude coordinates and acceleration of the mobile node are obtained in real time, and the CPU utilization and queue depth of the detected node are obtained in real time. The latitude and longitude coordinates are converted into the coordinates, which are Cartesian coordinates in the UTM coordinate system; If the acceleration is greater than the physical threshold, the average of the predicted acceleration at the previous moment and the current moment is used for replacement; The CPU utilization rate is normalized to obtain a normalized CPU utilization rate, and the queue depth is normalized to obtain a normalized queue depth.

7. The method for mobile network device fault detection based on big data according to claim 2, characterized in that, The calculation of the predicted coordinates of the mobile nodes at the next time step based on the coordinates of multiple mobile nodes using a Long Short-Term Memory (LSTM) network model includes: The historical trajectory coordinate sequence is used as an input vector, and key historical information is obtained by passing it through the forget gate of the LSTM model. Based on the key historical information, the cell state is updated through the input gate of the LSTM model to obtain the cell state at the current moment; Based on the current cell state, the current hidden state is generated through the output gate of the LSTM model, and the fully connected layer of the LSTM model maps the current hidden state to two-dimensional plane coordinates. By restricting the two-dimensional plane coordinates to a physically feasible range, the predicted coordinates of the moving node at the next moment are obtained.

8. A mobile network device fault detection system based on big data, characterized in that, include: The data acquisition module is used to obtain the coordinates and acceleration of the moving node in real time, and to obtain the CPU utilization and queue depth of the detected node in real time. The transmission delay prediction module is used to calculate the predicted coordinates of the mobile nodes at the next moment based on the coordinates of multiple mobile nodes using a Long Short-Term Memory (LSTM) network model, correct the predicted coordinates according to the acceleration, and obtain the transmission delay prediction value based on the corrected predicted coordinates. The service latency prediction module is used to calculate the moving average based on multiple CPU utilization rates, and obtain the service latency prediction value based on the moving average and the queue depth. The decision fusion module is used to calculate the CPU load variance in real time, determine the weight allocation strategy for the transmission stage and the service stage based on the currently calculated CPU load variance, and obtain the timeout threshold based on the determined weight allocation strategy, combined with the transmission delay prediction value, the service delay prediction value and the safety factor. The fault determination module is used to perform fault detection based on the timeout threshold, record the actual response delay, adjust the safety factor based on the actual response delay, and complete the network fault detection.

9. An electronic device, characterized in that, include: Processor; and A memory that stores computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

Images