A method and device for alarming connection failure of cellular IoT nodes

Abstract

This application relates to the field of IoT fault management technology, and in particular to a method and apparatus for alarming connection faults of cellular IoT nodes. The method is applied to a cellular IoT node connection fault alarm apparatus, which is used to connect to multiple IoT nodes and an external alarm device respectively. The apparatus includes a first module, a second module, and a third module. The method includes: within a pre-divided equal-length time period, the second module obtains the online node ratio for the equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module; the second module determines whether a first fault condition occurs during the equal-length time period based on the online node ratio; if it occurs, the second module sends a first fault alarm information to the third module so that the third module can save the first fault alarm information, and upon confirmation of the first fault alarm information, sends a fault report to the external alarm device connected to the third module.

Description

Technical Field

[0001] This application relates to the field of IoT fault management technology, and in particular to a method and apparatus for alarming connection faults of cellular IoT nodes. Background Technology

[0002] In cellular IoT applications, IoT nodes are typically deployed on a large scale in industrial production, urban infrastructure, and other fields. In practical applications, a network topology is often used where multiple IoT nodes share a connection to the same remote server or the same type of business service. In this type of topology, the connection status between the node and the server directly affects the normal operation of the business system. If the connection fails, a large number of nodes may simultaneously be unable to complete data reporting or business interactions.

[0003] However, unlike traditional internet services, the connection status of IoT nodes is highly dynamic, with a large number of nodes and a wide distribution. The online and offline behavior of nodes exhibits significant fluctuations and phased characteristics over time. Existing alarm schemes for IoT node connection status typically focus on single-node status judgment or instantaneous event triggering, such as issuing alarms based on whether a node has successfully established a connection or experienced a disconnection. For example, patent application CN108521346A (classification H04L) provides a method for locating abnormal nodes in a telecommunications bearer network based on terminal data; patent application CN111107158A (classification H04L) provides an alarm method, device, equipment, and medium for IoT device clusters; and patent application CN116346656A (classification H04L) provides a method and system for detecting the link status of IoT devices. These existing solutions often assume that node connection status can be analyzed independently and that anomalies have obvious triggering conditions. However, in practical applications, connection failures often do not manifest as the complete offline status of a single node, but rather as an abnormal decrease or continuous fluctuation in the proportion of online nodes within a certain time range. This is a hidden and gradual form of anomaly, which is difficult to accurately identify through single-node or instantaneous judgment methods. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a cellular IoT node connection fault alarm method and device, which solves the technical problem that the prior art relies only on the connection status judgment of a single moment or a single node, which makes it impossible to accurately identify connection faults in which the proportion of online nodes deviates abnormally from the historical normal level, and thus makes it difficult to alarm the abnormal connection of the node group in a timely and reliable manner.

[0006] (II) Technical Solution

[0007] To achieve the above objectives, the main technical solutions adopted in this application include:

[0008] In a first aspect, embodiments of this application provide a cellular IoT node connection fault alarm method. The method is applied to a cellular IoT node connection fault alarm device, which is used to connect to multiple IoT nodes and an external alarm device. The device includes a first module, a second module, and a third module. The method includes: within a pre-divided equal-length time period, the second module obtains the online node ratio for the equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module; the second module determines whether a first fault condition occurs during the equal-length time period based on the online node ratio; if so, it sends a first fault alarm message to the third module so that the third module can save the first fault alarm message and, upon confirmation of the first fault alarm message, sends a fault report to the external alarm device connected to the third module; wherein, the first fault condition is when the deviation between the online node ratio during the equal-length time period and the average online node ratio during a specified historical time period exceeds a first preset threshold R1.

[0009] Preferably, in some embodiments of this application, the first module includes: a first computing unit, a first storage unit, a first data interface, a second data interface, and a third data interface; the first computing unit is used to, when the AAA data of the IoT node received by the second data interface contains message data of a node online identifier, add an AAA data record in a preset first database in the first storage unit according to the data corresponding to the node ID field, address field, and online field in the AAA data; when the AAA data contains message data of a node offline identifier, the unit retrieves matching AAA data records stored in the first database according to the data corresponding to the node ID field and offline field in the AAA data, where the offline field is empty. The system records the node's offline time and updates it to the node's offline time in the received AAA data. Based on the updated online and offline fields, it calculates the online duration of the nodes in the received AAA data and fills the calculation result into the duration field of the newly added AAA data record. Each AAA data record in the first database is a two-dimensional table structure, containing at least: a node ID field, an address field, an online field, an offline field, and a duration field. The online field records the node's online time; the offline field records the node's offline time; the duration field represents the node's online duration calculated based on the node's online time recorded in the online field and the node's offline time recorded in the offline field; the address field records the node's network address; and the node ID field records the node's ID.

[0010] Preferably, in some embodiments of this application, obtaining the online node ratio for the equal-length time period includes: within each equal-length time period, whenever a preset first timer T100 reaches its timing cycle, performing the following operations: querying a first database to obtain the number of node IDs of AAA data records as the total number of nodes and the number of AAA data records with an empty offline field as the total number of online nodes, and assigning the total number of nodes to a first counter N100 and the total number of online nodes to a second counter N101; calculating the current online node ratio based on the current values ​​of the first counter N100 and the second counter N101, and recording the calculation result as a temporary ratio value; for each equal-length time period, determining the last temporary ratio value obtained within that equal-length time period as the online node ratio corresponding to that equal-length time period; the number of equal-length time periods is n, wherein the equal-length time period is obtained by dividing 24 hours by a second preset threshold E1.

[0011] Preferably, in some embodiments of this application, the average online node ratio over a specified historical time period includes: an average value a1 calculated based on the online node ratio values ​​corresponding to the five consecutive equal-length time periods immediately preceding the current equal-length time period; and an average value a2 calculated based on the online node ratio values ​​corresponding to the corresponding equal-length time periods within the past three weeks that have the same weekday attribute as the current equal-length time period and are within the same time range of each day; wherein the same weekday attribute refers to the same weekday index value, which indicates the day of the week; and an average value a3 calculated based on the online node ratio values ​​corresponding to the three special dates of the same type as the current date and which are temporally adjacent, within the same time range of equal-length time periods when the date to which the current equal-length time period belongs is a preset special day; and an average value a3 calculated based on the online node ratio values ​​corresponding to the three special dates of the same type as the current date and which are temporally adjacent, within the same time range when the date to which the current equal-length time period belongs is a weekday; and an average value a3 calculated based on the online node ratio values ​​of the three special dates within the current week excluding the current date. The average value a4 is calculated from the proportion of online nodes corresponding to equal-length periods within the same time range for other weekdays; or, when the date of the current equal-length period is not a weekday, the average value a4 is calculated from the proportion of online nodes corresponding to equal-length periods within the same time range based on the most recent weekday attribute obtained by querying backward from the current date; wherein, the first fault alarm information includes: the sending time date1 of the first fault alarm information, the id1 of the first fault alarm information, the type identifier type1 of the first fault alarm information, and the data of the first fault alarm information; the data of the first fault alarm information includes: the first preset threshold R1, the second preset threshold E1, the E2 parameter, and the timing period of the first timer T100; the E2 parameter includes: the average value a1, the average value a2, the average value a3, and the average value a4.

[0012] Preferably, in some embodiments of this application, when the third module confirms the first fault alarm information, it also sends a first fault alarm information confirmation message to the second module; the first fault alarm information confirmation message includes: the sending time date2 of the first fault alarm information confirmation message, the first fault alarm information confirmation message id2, and the type identifier type2 of the first fault alarm information confirmation message; when the third module does not confirm the first fault alarm information, it also sends a first fault alarm information unconfirmed message to the second module; the first fault alarm information unconfirmed message includes: the sending time date3 of the first fault alarm information unconfirmed message, the first fault alarm information unconfirmed message id3, and the type identifier type3 of the first fault alarm information unconfirmed message; the first fault alarm information confirmation message id2 and the first fault alarm information unconfirmed message id3 are both the same as the first fault alarm information id1.

[0013] Preferably, in some embodiments of this application, the first computing unit is used to extract the values ​​of the node ID field, target address field, port field, address field, and protocol field from the node identity and access data of the IoT node received by the first data interface, and to perform line-by-line matching of the extracted five field values ​​with the corresponding fields of the node identity and access data records stored in the preset second database in the first storage unit. If a node identity and access data record that completely matches the values ​​of the five fields is found, the extracted node identity and access data is ignored; if no completely matching node identity and access data record is found, the extracted node identity and access data is considered invalid. The access data generates a unique sequence number, and this sequence number, along with the values ​​of the five extracted fields and the type field, is used as a new node identity and access data record and written into the second database. The type field is set to represent a value other than the preset address. The node identity and access data includes node identity data and node preset access address data. Each node identity and access data record in the second database is a two-dimensional table structure, containing at least: a sequence field, a node ID field, a target address field, a type field, a port field, an address field, and a protocol field. The sequence field records the sequence number; the target address field records the destination address of the node accessing the target address. The target network address is labeled; the type field records the source type of the target network address; the port field records the port of the target network address accessed by the node; the protocol field records the protocol used by the node to access the target address; the first computing unit is used to receive session data records of IoT nodes collected from the third data interface through the high-speed storage medium, and triggers the high-speed storage medium to perform cached data packaging operation when the packaging conditions are met; the packaging conditions are: reaching a preset fixed data packaging period, or the number of bytes of session data records cached by the high-speed storage medium reaches a preset upper limit value; in the packaging operation, each session data record is written into the corresponding field of the third database. The third database is described above; the session data records in the third database are in a two-dimensional table structure, including at least: an address field, a destination address field, a protocol field, a port field, a start field, an end field, a live field, a sent byte field, and a received byte field; the start field records the session start time; the end field records the session end time; the live field records the session live time calculated based on the session start time recorded in the start field and the session end time recorded in the end field; the sent byte field records the number of data bytes sent by the node to the destination address during the session; and the received byte field records the number of data bytes received by the node from the destination address during the session.When the second module receives the confirmation message of the first fault alarm information, it deletes the E2 parameter of the equal-length period corresponding to the first fault alarm information, restores it to the preset initial value, and marks all session data records in the third database starting from the sending time date1 of the first fault alarm information as alarmed.

[0014] Preferably, in some embodiments of the present application, the method further includes: when the first fault does not occur during the equal-length period, the second module determines whether a second fault condition occurs during the equal-length period. If it occurs, it sends a second fault alarm information to the third module, so that the third module saves the second fault alarm information, and when confirming the second fault alarm information, it sends a fault report to an external alarm device connected to the third module; wherein, the process of determining whether a second fault condition occurs during the equal-length period includes: when the timing period of the second timer T200 preset in the second module expires, it detects whether there is a new session data record in the third database of the first module. If it exists, it obtains the session survival time in the survival field of the new session data record. When |Tp - H1| / H1 > R2 and Tp < H1, it adds 1 to the value of the third counter N200. Then, when |P1 / P2 - H2| / H2 > R3 and P1 / P2 < H2, it adds 1 to the value of the fourth counter N201, and when the value of the third counter N200 is greater than or the value of the fourth counter N201 is greater than it determines that a second fault condition occurs during the equal-length period; Tp is the session survival time in the survival field of the new session data record; and is obtained in the following manner: reading session data records from the third database, and identifying all session data records with the same values in the target address field, protocol field, and port field as those in the new session data record as belonging to the same connection; respectively counting the number of session data records included in each connection as the number of sessions generated by the connection; multiplying the number of sessions of each connection by the third preset threshold G1 and the fourth preset threshold G2 respectively to obtain the corresponding and ; wherein, when the end field in the newly added session data record in the third database is not empty, the values in the sent byte field and received byte field of the newly added session data record are respectively divided by the value in the survival field to obtain the average value P1 of the uplink bytes and the average value P2 of the downlink bytes generated by the session corresponding to the newly added session data record during the connection duration; wherein, the second fault alarm information includes: the sending time date4 of the second fault alarm information, the second fault alarm information id4, the type identifier type4 of the second fault alarm information, and the second fault alarm information data;

[0015] The second fault alarm information data includes: the third preset threshold G1, the fourth preset threshold G2, the fifth preset threshold H1, the sixth preset threshold H2, the seventh preset threshold R2, the eighth preset threshold R3, the timing period of the second timer T200, the current value of the third counter N200, and the current value of the fourth counter N201.

[0016] Preferably, in some embodiments of this application, when the third module confirms the second fault alarm information, it also sends a second fault alarm information confirmation message to the second module; the second fault alarm information confirmation message includes: the sending time date5 of the second fault alarm information confirmation message, the second fault alarm information confirmation message id5, and the type identifier type5 of the second fault alarm information confirmation message; when the third module does not confirm the second fault alarm information, it also sends a second fault alarm information unconfirmed message to the second module; the second fault alarm information unconfirmed message includes: the sending time date6 of the second fault alarm information unconfirmed message, the second fault alarm information unconfirmed message id6, and the type identifier type6 of the second fault alarm information unconfirmed message; the second fault alarm information confirmation message id5 and the second fault alarm information unconfirmed message id6 are both the same as the second fault alarm information id4; when the second module receives the second fault alarm information confirmation message, it updates the current third database with the information from the sending time date5 of the second fault alarm information. All session data records in the third database starting from te4 are deleted; the process of the third module confirming the first fault alarm information includes: if the third module determines that the first fault alarm information contains the first fault alarm information type identifier type1, it determines whether the third module stores the same first fault alarm information id1 as the first fault alarm information in the first fault alarm information. If not, it sends the first fault feedback message to the second module. If the third module does not receive the first fault alarm information resent from the second module to the third module within the timing period of the updated first timer T100, the third module does not confirm the first fault alarm information and sends a first fault alarm information unconfirmation message to the second module; the first fault feedback message includes: the timing period of the updated first timer T100, the updated second preset threshold E1, and the first fault feedback message id7; wherein, the timing period of the updated first timer T100 is 0 times the timing period of the first timer T100 in the first fault alarm information data of the first fault alarm information.The value is 1 times the value of the updated second preset threshold E1, which is twice the value of the second preset threshold E1 in the first fault alarm information data; the first fault feedback message id7 is the same as the first fault alarm information id1; after receiving the first fault feedback message, the second module uses the updated timing period of the first timer T100 and the updated second preset threshold E1 to determine again whether the first fault situation occurs during the equal-length period based on the proportion of online nodes. If it occurs, the first fault alarm information is sent to the third module again; wherein, in the first fault alarm information sent by the second module to the third module again, the first fault feedback message id7 recorded in the first fault feedback message is used as the first fault alarm information id1; if it exists, the third module confirms the first fault alarm information, sends a first fault alarm information confirmation message to the second module, and obtains a fault report and sends the fault report to an external alarm device; the process of the third module confirming and judging the second fault alarm information includes:

[0017] If the third module determines that the second fault alarm information contains the type identifier type4 of the second fault alarm information, it determines whether the third module stores the same second fault alarm information id4 as the second fault alarm information in the second fault alarm information. If not, the third module sends the second fault feedback message to the second module. If the third module does not receive the second fault alarm information from the second module again within the timing period of the updated second timer T200, the third module does not acknowledge the second fault alarm information and sends a second fault alarm information unacknowledgement message to the second module. The second fault feedback message includes: the updated timing period of the second timer T200, the updated fifth preset threshold H1, the updated sixth preset threshold H2, the updated third preset threshold G1, the updated fourth preset threshold G2, and the second fault feedback message id8. The second fault feedback message id8 is the same as the second fault alarm information id4. Among them, the updated timing period of the second timer T200 is 0.1 times the timing period of the second timer T200 in the second fault alarm information data of the second fault alarm information, and the updated fifth preset threshold H1 is the second fault alarm information id4. The fifth preset threshold H1 in the alarm information data is 1.05 times, the updated sixth preset threshold H2 is 1.05 times the sixth preset threshold H2 in the second fault alarm information data, the updated third preset threshold G1 is 0.8 times the third preset threshold G1 in the second fault alarm information data, and the updated fourth preset threshold G2 is 0.8 times the fourth preset threshold G2 in the second fault alarm information data; after receiving the second fault feedback message, the second module adopts the updated second timer T200 timing period, the updated fifth preset threshold H1, and the updated sixth preset threshold H2. The system uses the value H2, the updated third preset threshold G1, and the updated fourth preset threshold G2 to determine again whether a second fault occurs during the same time period. If it does, it sends a second fault alarm message to the third module again. The second fault alarm message sent by the second module to the third module uses the second fault feedback message id8 as the second fault alarm message id4. If the fault exists, the third module confirms the second fault alarm message and sends a second fault alarm message confirmation message to the second module, as well as obtains a fault report and sends the fault report to an external alarm device.

[0018] Preferably, in some embodiments of this application, the process of obtaining a fault report includes:

[0019] The third module queries the session data records marked as alarmed in the second module via an interface. Based on the values ​​of the target address field, type field, and protocol field in the alarmed session data records, it performs a matching search in the second database. For sessions where no match is found, it extracts the corresponding field values ​​from the alarmed session data records that correspond to the two-dimensional table structure of node identity and access data records in the second database. It then adds a new node identity and access data record to the second database, setting the type field value to indicate a non-preset address. Finally, it performs a correlation search based on the address field in the alarmed session data records. The second database is queried to determine the corresponding node ID. A node ID is randomly selected from the determined node IDs and sampled in a specified manner to obtain the data packets of the corresponding sampling session. The specified sampling method includes: collecting data packets of all sessions of the selected node ID from the sending time date1 of the first fault alarm information for a complete online-to-offline time; or, collecting data packets of the selected node from the sending time date4 of the second fault alarm information for three consecutive complete session start-to-close times. The value of the type field is extracted from the node identity and access data record corresponding to the selected node ID in the second database and used as the sending field.

[0020] The first fault alarm message or the second fault alarm message, the data packet of the sampling session, and the sending field are packaged into a fault report; the second module is also used to delete the alarmed mark in the session data record of the third database when an alarm cancellation message is received from an external alarm device through the third module.

[0021] On the other hand, this application embodiment also provides a cellular IoT node connection failure alarm device, including: a first module, a second module, and a third module;

[0022] The second module obtains the online node ratio within a pre-divided equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module for that equal-length time period.

[0023] The second module determines whether the first fault occurs during the equal-length period based on the online node ratio. If it does, it sends the first fault alarm information to the third module so that the third module can save the first fault alarm information and send a fault report to the external alarm device connected to the third module after confirming the first fault alarm information.

[0024] The first fault condition is when the deviation between the proportion of online nodes in the same time period and the average proportion of online nodes in a specified historical time period exceeds a first preset threshold R1.

[0025] (III) Beneficial Effects

[0026] This application provides a method and apparatus for alarming connection faults in cellular IoT nodes. Within a pre-divided equal-length time period, it obtains the online node ratio based on the total number of IoT nodes and the total number of online nodes pre-collected in a first module, and compares this ratio with the average online node ratio over a specified historical time period to determine whether a first fault condition has occurred within that equal-length time period. When a first fault condition occurs, the method promptly sends a first fault alarm message to a third module and, upon confirmation, sends a fault report to an external alarm device. In this way, this application can accurately identify anomalies in the connection status of a node group, especially implicit or progressive connection faults, improving the accuracy and timeliness of connection fault alarms and effectively avoiding false alarms or missed alarms caused by fluctuations in the number of nodes or anomalies in a single node. Simultaneously, this application supports monitoring and alarming of the overall connection status of a large number of cellular IoT nodes, and through the collaboration of the first, second, and third modules, achieves closed-loop processing from anomaly judgment to fault reporting, improving the efficiency of cellular IoT node operation and maintenance management. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a cellular IoT node connection failure alarm method according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of a cellular IoT node connection failure alarm device according to an embodiment of this application. Detailed Implementation

[0029] To better explain and facilitate understanding of this application, a detailed description of its implementation is provided below with reference to the accompanying drawings. In the prior art, the following are the main solutions for connection failure alarms of cellular IoT nodes:

[0030] The first category is anomaly alerting solutions based on deep learning or model prediction. These solutions typically employ machine learning models or time series prediction models, training and predicting based on the historical online ratio or session data of nodes to determine whether a current node is experiencing a connection anomaly. While this approach can theoretically handle non-stationary or discontinuous data, it is highly dependent on large-scale, high-quality training data, and the model training is complex and computationally demanding, making it unsuitable for deployment on edge devices. Furthermore, for sudden or short-term intermittent connection failures, the model struggles to capture abnormal features, leading to delayed or missed alerts.

[0031] The second type is an alarm scheme based on interpolation or missing data compensation. This scheme generates virtual data through linear interpolation, spline interpolation, or other prediction methods during periods of missing node data or node offline to restore data continuity, and then applies traditional statistical or threshold judgment methods for anomaly alarms. While this scheme solves the data discontinuity problem to some extent, the generated virtual data deviates from the actual node online status, and this error is propagated to alarm judgment, reducing alarm accuracy. At the same time, the selection of different interpolation models and parameter tuning are difficult, resulting in poor universality and low sensitivity to real short-term node anomalies or group connectivity characteristics.

[0032] To address this, the cellular IoT node connection fault alarm method and apparatus provided in this application introduce multi-dimensional judgment and adaptive alarm methods in data acquisition, online ratio calculation, historical average comparison, and session data analysis. This allows for the independent acquisition of the online node ratio in each equal-length time period, and the determination of whether a first fault condition has occurred based on the average deviation over historical time periods. Simultaneously, through the storage, analysis, and confirmation feedback mechanism of session data, the detection and alarm of a second fault condition are achieved. Furthermore, the alarm confirmation, unconfirmed feedback, and fault report generation mechanisms form a closed-loop process, ensuring timely and accurate identification and alarming of connection faults in a large-scale, widely distributed cellular IoT node environment, significantly improving system operation and maintenance efficiency and alarm reliability.

[0033] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application can be understood more clearly and thoroughly, and that the scope of this application can be fully conveyed to those skilled in the art.

[0034] Figure 1 This is a flowchart illustrating an anomaly detection method for an intermittently operating device according to an embodiment of this application. Figure 1 As shown, this cellular IoT node connection failure alarm method is applied to a cellular IoT node connection failure alarm device. (See also...) Figure 2 The device is used to connect to multiple IoT nodes and external alarm devices respectively. The device includes a first module, a second module, and a third module. The method includes:

[0035] Within a pre-divided equal-length time period, the second module obtains the online node ratio for that equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module.

[0036] The first module includes: a first computing unit, a first storage unit, a first data interface, a second data interface, and a third data interface. The first computing unit, when receiving AAA data from an IoT node via the second data interface that contains a message data indicating a node's online status, adds a new AAA data record in a pre-set first database within the first storage unit, based on the data corresponding to the node ID field, address field, and online field in the AAA data. When receiving message data containing a node's offline status in the AAA data, the unit retrieves a matching AAA data record with an empty offline field from the AAA data records stored in the first database, based on the data corresponding to the node ID field and offline field in the AAA data. The offline field of the AAA data record is updated to the node offline time in the received AAA data; based on the updated online and offline fields, the online duration of the nodes in the received AAA data is calculated, and the calculation result is filled into the duration field of the newly added AAA data record; each AAA data record in the first database is a two-dimensional table structure, which includes at least: a node ID field, an address field, an online field, an offline field, and a duration field; wherein, the online field records the node online time; the offline field records the node offline time; the duration field represents the online duration of the node calculated based on the node online time recorded in the online field and the node offline time recorded in the offline field; the address field records the node's network address; and the node ID field records the node ID. The second module determines whether a first fault condition occurs during the equal-length period based on the online node ratio. If it does, it sends a first fault alarm message to the third module so that the third module can save the first fault alarm message. Upon confirmation of the first fault alarm message, the third module sends a fault report to an external alarm device connected to the third module. The first fault condition is when the deviation between the online node ratio during the equal-length period and the average online node ratio during a specified historical period exceeds a first preset threshold R1.

[0037] For example, in this embodiment of the application, it is assumed that 100 cellular IoT nodes are deployed in a smart industrial park for real-time monitoring of the status of various devices. The cellular IoT nodes are connected to a fault alarm device that is connected to these nodes and external alarm devices (such as alarm terminals in the operation and maintenance center). The device includes a first module, a second module, and a third module. The first module is used to receive AAA data uploaded by the nodes, which includes information such as node ID, network address, online / offline identifier, and time. The second module is used to calculate the proportion of online nodes within each equal-length time period and determine the fault. The third module is used for storing, confirming, and sending alarm information externally.

[0038] For example, a day is divided into 24 equal-length time periods, each lasting one hour. During a given time period, the first module receives AAA data uploaded by nodes, with some nodes sending online messages and others sending offline messages. The first module stores each AAA data record in a first database, containing the node ID, address, online time, offline time, and online duration. When a node's offline information is updated, the first module calculates the node's online duration based on the online and offline fields and updates the data record. Assuming that in the 5th time period, the first module counts a total of 100 nodes, with 92 online, the second module calculates the online node ratio for that time period to be 92%. The second module then compares this ratio with a specified historical time period. If the deviation exceeds a first preset threshold R1, it determines that a first fault has occurred during that time period and sends a first fault alarm message to the third module. Upon receiving the alarm message, the third module saves the information and, after confirming the first fault alarm message, sends a fault report to an external alarm device to notify maintenance personnel for timely handling.

[0039] The method in this application independently calculates the proportion of online nodes within each pre-divided equal-length time period. Even if some nodes are temporarily offline, anomalies can be detected in a timely manner, ensuring that alarm information can be transmitted to maintenance personnel in real time. Secondly, by comparing the deviation of the proportion of online nodes in the current equal-length time period with the average value of a specified historical time period, normal fluctuations and real faults are effectively distinguished, thereby reducing the false alarm rate. In addition, the first module continuously records the online and offline information of each node and calculates the online duration of the nodes, ensuring the integrity and reliability of node status data and providing a solid data foundation for alarm judgment. In terms of operation and maintenance management, combined with the alarm information confirmation and report sending mechanism of the third module, a closed-loop management system from node monitoring to alarm notification can be formed, enabling maintenance personnel to quickly obtain accurate fault information and take timely countermeasures, thereby reducing risks.

[0040] Preferably, in some embodiments of this application, obtaining the online node ratio for the equal-length time period includes: within each equal-length time period, whenever a preset first timer T100 reaches its timing cycle, performing the following operations: querying a first database to obtain the number of node IDs of AAA data records as the total number of nodes and the number of AAA data records with an empty offline field as the total number of online nodes, and assigning the total number of nodes to a first counter N100 and the total number of online nodes to a second counter N101; calculating the current online node ratio based on the current values ​​of the first counter N100 and the second counter N101, and recording the calculation result as a temporary ratio value; for each equal-length time period, determining the last temporary ratio value obtained within that equal-length time period as the online node ratio corresponding to that equal-length time period; the number of equal-length time periods is n, wherein the equal-length time period is obtained by dividing 24 hours by a second preset threshold E1.

[0041] For example, suppose a cellular IoT system contains 1000 nodes, and the 24 hours are divided into equal-length time periods, with a second preset threshold E1 of 24 and a corresponding number of equal-length time periods n of 24. Within each equal-length time period, the first timer T100 is triggered periodically, for example, every 10 minutes. Each time it is triggered, the second module queries the AAA data record in the first database of the first module: assuming there are currently 1000 node records, 950 of which have an empty offline field, indicating that the current number of online nodes is 950. At this time, the first counter N100 records the total number of nodes as 1000, the second counter N101 records the total number of online nodes as 950, and calculates the current online node ratio as 95%. This ratio is recorded as a temporary ratio value. Within this equal-length time period, the second module calculates the temporary ratio value multiple times, and finally selects the last calculated temporary ratio value (e.g., 95%) as the online node ratio corresponding to this equal-length time period. The embodiments of this application achieve dynamic monitoring of node online status by calculating the proportion of online nodes multiple times within each equal-length time period and using the last calculation result of that equal-length time period as the indicator for that time period. This effectively smooths out fluctuations caused by short-term node online / offline cycles, thereby avoiding misjudgments that may be caused by single sampling and significantly improving the accuracy of online status judgment. Simultaneously, by dividing the 24 hours into equal-length time periods and combining this with the periodic triggering of the first timer T100, the monitoring process is standardized and quantifiable, facilitating systematic analysis and statistics of node online status throughout the day. Each timer trigger obtains the latest node online information, ensuring real-time updates of node status; furthermore, each node record includes online time, offline time, and online duration, providing a complete data foundation for subsequent analysis and fault tracing. In addition, the accurate proportion of online nodes provides a reliable basis for the second module to judge the first fault condition.

[0042] Specifically, the average online node ratio over a specified historical time period includes: the average value a1 calculated based on the online node ratio values ​​of the five consecutive equal-length time periods immediately preceding the current equal-length time period; and the average value a2 calculated based on the online node ratio values ​​of corresponding equal-length time periods within the past three weeks that have the same weekday attribute as the current equal-length time period and fall within the same time range of each day; wherein the same weekday attribute refers to the same weekday index value, which indicates the day of the week; and when the date of the current equal-length time period is a preset special day, the average value calculated based on the online node ratio values ​​of three special dates of the same type as the current date and which are temporally adjacent, within the same time range of equal-length time periods. a3; and, when the date of the current equal-length period is a weekday, the average value a4 is calculated based on the online node ratio values ​​corresponding to the other weekdays (excluding the current date) within the same time range of equal-length periods; or, when the date of the current equal-length period is a non-weekday legal working day, the average value a4 is calculated based on the online node ratio values ​​corresponding to the same weekday attribute obtained by querying backward from the current date; wherein, the first fault alarm information includes: the sending time date1 of the first fault alarm information, the first fault alarm information id1, the type identifier type1 of the first fault alarm information, and the first fault alarm information data;

[0043] The first fault alarm information data includes: a first preset threshold R1, a second preset threshold E1, E2 parameters and the timing period of the first timer T100; the E2 parameter includes: average value a1, average value a2, average value a3 and average value a4.

[0044] For example, based on the online node ratios of the five consecutive equal-length periods preceding the current equal-length period, an average value 'a1' is calculated to reflect recent fluctuations in node online status. For instance, if the currently monitored equal-length period is from 8:00 AM to 10:00 AM, and the online node ratios of the previous five consecutive equal-length periods were 95%, 97%, 96%, 98%, and 94%, then 'a1' is 96%. Furthermore, based on equal-length periods within the past three weeks that share the same weekday attribute as the current equal-length period, the corresponding online node ratios are obtained, and an average value 'a2' is calculated to reflect the periodic patterns in node online status. For example, for a period currently on Monday, the online ratios for the same period on Mondays in the past three weeks were 93%, 95%, and 94%, respectively, so 'a2' is approximately 94%. When the date of the current equal-length period is a preset special day (such as a holiday), an average value 'a3' is further calculated based on the online node ratios of three special dates of the same type and time proximity to the current date, within the same time range of equal-length periods. For example, if the current date is New Year's Day, the online percentages for the same time period during the past three New Year's Days are 90%, 92%, and 91%, respectively, so a3 is approximately 91%. Simultaneously, if the current equal-length period falls within a weekday, the average a4 is calculated based on the online percentages for the same time period during other weekdays excluding the current date. If the current date is not a weekday, the system will look back to the most recent equal-length period with the same weekday attribute that is also a weekday, and calculate the corresponding average a4. For example, if the current time period is Tuesday 8:00 AM – 10:00 AM, the online percentages for the same time period from Tuesday to Thursday are 97%, 96%, and 95%, respectively, so a4 is approximately 96%. After obtaining the above averages, the second module compares the online node percentage for the current equal-length period with a1, a2, a3, and a4. If the deviation in the online node percentage exceeds a first preset threshold R1, a first fault condition is determined to have occurred in the current equal-length period, and a first fault alarm message is sent to the third module. The first fault alarm information includes the sending time, alarm information ID, type identifier, and alarm information data. The alarm information data records the first preset threshold R1, the second preset threshold E1, E2 parameters, and the timing period of the first timer T100. Specifically, the E2 parameter includes average values ​​a1, a2, a3, and a4, providing maintenance personnel with multi-dimensional historical references to facilitate the determination of the cause and severity of node anomalies. Through the above implementation method, the introduction of multi-dimensional historical average values ​​can effectively distinguish between short-term fluctuations and actual faults in nodes, significantly reducing the false alarm rate and improving the accuracy of fault diagnosis. The first alarm information includes the sending time, ID, type, and detailed historical parameters, ensuring information completeness and traceability, which helps maintenance personnel quickly analyze and handle faults.

[0045] In practical applications, in this embodiment, when the third module confirms the first fault alarm information, it also sends a first fault alarm information confirmation message to the second module; the first fault alarm information confirmation message includes: the sending time date2 of the first fault alarm information confirmation message, the first fault alarm information confirmation message id2, and the type identifier type2 of the first fault alarm information confirmation message; when the third module does not confirm the first fault alarm information, it also sends a first fault alarm information unconfirmed message to the second module; the first fault alarm information unconfirmed message includes: the sending time date3 of the first fault alarm information unconfirmed message, the first fault alarm information unconfirmed message id3, and the type identifier type3 of the first fault alarm information unconfirmed message; the first fault alarm information confirmation message id2 and the first fault alarm information unconfirmed message id3 are both the same as the first fault alarm information id1.

[0046] For example, when the second module determines that a first fault has occurred based on the proportion of online nodes over an equal time period and sends a first fault alarm message to the third module, the third module will save the first fault alarm message and enter the alarm confirmation process. Specifically, if the third module determines that the first fault alarm message meets the preset confirmation conditions, it will generate and send a first fault alarm message confirmation message to the second module. This confirmation message includes the sending time date2, the alarm message confirmation message id2, and the type identifier type2 used to distinguish message attributes. The alarm message confirmation message id2 is consistent with the original first fault alarm message id1, used to establish a one-to-one mapping relationship between the confirmation message and the corresponding alarm event. For example, when a large number of IoT nodes go offline simultaneously within a certain time period, and it is confirmed that this is a real network anomaly, the third module can send a confirmation message to notify the second module that the fault alarm has been officially confirmed.

[0047] Accordingly, if the third module determines that the first fault alarm information does not meet the confirmation conditions, the third module will generate and send an unconfirmed message for the first fault alarm information to the second module. The unconfirmed message also includes the sending time (date3), the unconfirmed message ID3, and the unconfirmed type identifier (type3), where the unconfirmed message ID3 is consistent with the original first fault alarm information ID1. Through the above implementation, the technical solution of this application introduces a two-way feedback mechanism of "confirmation / unconfirmation" after alarm generation, making alarm processing no longer a one-way trigger, but forming a closed-loop interaction between the second and third modules. This effectively avoids the problem that alarms are automatically considered as real faults once triggered, reducing the risk of false alarms from a mechanism perspective. Secondly, both the confirmation and unconfirmed messages are associated with an identifier consistent with the original alarm information ID1, ensuring that the alarm event has a clear and unique identity throughout its entire lifecycle, improving the traceability and consistency of alarm processing.

[0048] In this embodiment, the first computing unit is used to extract the values ​​of the node ID field, target address field, port field, address field, and protocol field from the node identity and access data of the IoT node received by the first data interface. The extracted values ​​of the five fields are then matched line by line with the corresponding fields of the node identity and access data records stored in a preset second database in the first storage unit. If a node identity and access data record with completely identical values ​​of the five fields is found, the extracted node identity and access data is ignored. If no completely identical node identity and access data record is found, a unique sequence number is generated for the extracted node identity and access data. This sequence number, along with the values ​​of the five extracted fields and the type field, is used as a new node identity and access data record and written into the second database. The type field is set to represent a value that is not a preset address.

[0049] The node identity and access data includes: node identity data and node preset access address data; each node identity and access data record in the second database is a two-dimensional table structure, containing at least: a sequence field, a node ID field, a target address field, a type field, a port field, an address field, and a protocol field; wherein, the sequence field records the sequence number; the target address field records the target network address accessed by the node; the type field records the source type of the target network address; the port field records the port of the target network address accessed by the node; and the protocol field records the protocol used by the node to access the target address;

[0050] For example, when an IoT node attempts to access external network resources during communication, the first data interface can obtain node identity and access data containing the node ID, target address, port, source address, and the communication protocol used. The first computing unit parses this node identity and access data, extracting five key fields: node ID, target address, port, address, and protocol. The values ​​of these five fields are then compared line-by-line with existing node identity and access data records in a pre-set second database stored in the first storage unit. During the comparison, if a record in the second database already exists that perfectly matches the extracted data in all five fields, the node's access behavior is considered a known access behavior, and the first computing unit ignores the extracted data and does not write it back to the database, thus avoiding redundant data. Conversely, if no record matching the extracted data is found in the second database, the first computing unit generates a unique sequence number for the extracted node identity and access data, and combines this sequence number with the values ​​of the five extracted fields and the type field to form a new node identity and access data record, which is then written to the second database. The type field is set to a value that represents a non-preset address, used to identify that the access target is not a pre-authorized or predefined access address of the node.

[0051] The first computing unit is used to receive session data records from IoT nodes collected by a third data interface through a high-speed storage medium, and trigger the high-speed storage medium to perform cached data packaging operation when the packaging conditions are met. The packaging conditions are: reaching a preset fixed data packaging period, or the number of bytes of session data records cached by the high-speed storage medium reaches a preset upper limit. In the packaging operation, each session data record is written into the third database according to the corresponding fields of the third database. The session data records in the third database are in a two-dimensional table structure, which includes at least: address field, target address field, protocol field, port field, start field, end field, live field, sent byte field, and received byte field. The start field records the session start time; the end field records the session end time; the live field records the session live time calculated based on the session start time recorded in the start field and the session end time recorded in the end field; the sent byte field records the number of data bytes sent by the node to the target address during the session; and the received byte field records the number of data bytes received by the node from the target address during the session.

[0052] When the second module receives the confirmation message of the first fault alarm information, it deletes the E2 parameters of the equal-length period corresponding to the first fault alarm information, restores them to the preset initial values, and marks all session data records in the third database starting from the sending time date1 of the first fault alarm information as alarmed.

[0053] In the embodiment of the present application, by performing field-level precise matching on the node identity and access data, only the unappeared access behaviors are recorded, effectively reducing the redundant data in the database, improving the storage and retrieval efficiency, and enabling the abnormal access behaviors to be quickly identified and located. Secondly, by performing structured storage and associated management on the node access behaviors and subsequent session data records, the faults can be analyzed from multiple dimensions of "node access - session behavior - alarm event", providing sufficient data support for subsequent alarm confirmation and fault tracing. Thirdly, after the first fault alarm is confirmed, by resetting the E2 parameters and marking the session data as alarmed, the continuous interference of abnormal data on the subsequent statistical model is avoided, significantly improving the stability and accuracy of the online node ratio judgment and fault identification. Finally, this embodiment realizes the effective coordination among the node access behavior management, session data collection, and fault alarm processing, constructs a complete and traceable alarm closed-loop mechanism, and significantly improves the reliability of the cellular Internet of Things node connection fault alarm device in a complex network environment.

[0054] In the embodiment of the present application, the method further includes: when the first fault does not occur in the equal-length period, the second module determines whether a second fault situation occurs in the equal-length period. If so, it sends the second fault alarm information to the third module for the third module to save the second fault alarm information and, when the second fault alarm information is confirmed, send a fault report to an external alarm device connected to the third module; where the process of determining whether a second fault situation occurs in the equal-length period includes: when the timing period of the second timer T200 preset in the second module expires, detecting whether there is a new session data record in the third database of the first module. If it exists, obtaining the session survival time in the survival field of the new session data record, and when |Tp - H1| / H1 > R2 and Tp < H1 (indicating that the actual survival time of this session is significantly lower than the normal expected range, indicating that the connection may be abnormally interrupted or frequently rebuilt), adding 1 to the value of the third counter N200, and then when |P1 / P2 - H2| / H2 > R3 and P1 / P2 < H2 (indicating that there is an obvious asymmetry in the uplink and downlink traffic or a decrease in the overall throughput capacity of this session, which may correspond to abnormal access, communication restriction, or abnormal speed limit behavior), adding 1 to the value of the fourth counter N201, and when the value of the third counter N200 is greater than or the value of the fourth counter N201 is greater than When a second failure occurs during this extended period, it is determined that Tp represents the session survival time in the survival field of the newly added session data record.

[0055] and The following method is used to obtain the session data records: Session data records are read from the third database; all session data records that are identical to the values ​​of the target address field, protocol field, and port field in the newly added session data records are identified as belonging to the same connection; the number of session data records contained in each connection is counted, which is taken as the number of sessions generated by that connection; the number of sessions for each connection is multiplied by a third preset threshold G1 and a fourth preset threshold G2, respectively, to obtain the corresponding connection's session count. and In the case that the end field of the newly added session data record in the third database is not empty, the values ​​of the sent byte field and received byte field in the newly added session data record are divided by the value of the live field to obtain the average uplink byte count P1 and the average downlink byte count P2 generated by the session corresponding to the newly added session data record during the connection duration; the second fault alarm information includes: the sending time date4 of the second fault alarm information, the id4 of the second fault alarm information, the type identifier type4 of the second fault alarm information, and the data of the second fault alarm information; the data of the second fault alarm information includes: the third preset threshold G1, the fourth preset threshold G2, the fifth preset threshold H1, the sixth preset threshold H2, the seventh preset threshold R2, the eighth preset threshold R3, the timing period of the second timer T200, the current value of the third counter N200, and the current value of the fourth counter N201.

[0056] In cases where no first fault occurs within a given time period, this application allows the second module to further determine whether a second fault has occurred. This is achieved by periodically triggering a second timer T200 to detect newly added session data records in the third database. This continuous monitoring of session-level anomalies avoids missed detections caused by relying solely on online node status, thus improving the comprehensiveness of fault detection. Secondly, the second module obtains the session lifetime Tp from the newly added session data records and compares it with the fifth preset threshold H1 and the seventh preset threshold R2. When the corresponding conditions are met, the third counter N200 is incremented, providing a clear quantitative basis for determining abnormal session lifetimes. This effectively reflects the abnormal characteristic of short session lifetimes, thereby improving the accuracy of second fault detection. Furthermore, when the end field of a newly added session data record is not empty, the second module calculates the average uplink byte count P1 and the average downlink byte count P2 using the sent byte field, received byte field, and liveness field. Based on the sixth preset threshold H2 and the eighth preset threshold R3, it makes a judgment. When the conditions are met, the fourth counter N201 is incremented, enabling effective identification of uplink and downlink data transmission anomalies and enhancing the reliability of the second fault judgment. Simultaneously, by identifying session data records with identical target address, protocol, and port fields as the same connection, and counting the number of session data records contained in each connection, this is combined with the third preset threshold G1 and the fourth preset threshold G2 respectively. This allows the second fault judgment process to be constrained by session characteristics at the connection level, avoiding unreasonable influence of single session data on the judgment result and improving the stability of the judgment result. Furthermore, when the value of the third counter N200 is greater than or the value of the fourth counter N201 is greater than a certain value, the second module determines that a second fault condition has occurred during this equal-length period and sends a second fault alarm message containing relevant threshold parameters, timing period, and the current value of the counter to the third module. This ensures that the second fault alarm message has complete judgment criteria and status information, facilitating storage and subsequent processing by the third module. Finally, upon confirmation of the second fault alarm message, the third module sends a fault report to the external alarm device connected to the third module, achieving timely reporting of the second fault alarm message.

[0057] In this embodiment of the application, when the third module confirms the second fault alarm information, it also sends a second fault alarm information confirmation message to the second module; the second fault alarm information confirmation message includes: the sending time date5 of the second fault alarm information confirmation message, the id5 of the second fault alarm information confirmation message, and the type identifier type5 of the second fault alarm information confirmation message;

[0058] If the third module fails to acknowledge the second fault alarm information, it also sends a second fault alarm information unacknowledged message to the second module. The second fault alarm information unacknowledged message includes: the sending time date6 of the second fault alarm information unacknowledged message, the second fault alarm information unacknowledged message id6, and the type identifier type6 of the second fault alarm information unacknowledged message. The second fault alarm information acknowledgment message id5 and the second fault alarm information unacknowledged message id6 are both the same as the second fault alarm information id4. Upon receiving the second fault alarm information acknowledgment message, the second module deletes all session data records in the third database starting from the sending time date4 of the second fault alarm information.

[0059] The process of the third module confirming the first fault alarm information includes: when the third module determines that the first fault alarm information contains the first fault alarm information type identifier type1, it determines whether the third module stores the same first fault alarm information id1 as the first fault alarm information in the first fault alarm information. If it does not exist, it sends the first fault feedback message to the second module. If the third module does not receive the first fault alarm information sent by the second module to the third module again within the timing period of the updated first timer T100, the third module does not confirm the first fault alarm information and sends a first fault alarm information unconfirmation message to the second module.

[0060] The first fault feedback message includes: an updated timing period of the first timer T100, an updated second preset threshold E1, and a first fault feedback message id7; wherein, the updated timing period of the first timer T100 is 0.1 times the timing period of the first timer T100 in the first fault alarm information data of the first fault alarm information, and the updated second preset threshold E1 is twice the value of the second preset threshold E1 in the first fault alarm information data; the first fault feedback message id7 is the same as the first fault alarm information id1;

[0061] After receiving the first fault feedback message, the second module uses the updated timing period of the first timer T100 and the updated second preset threshold E1 to determine again whether the first fault situation occurs during the equal-length period based on the proportion of online nodes. If it occurs, the second module sends the first fault alarm information to the third module again. In the first fault alarm information sent by the second module to the third module again, the first fault feedback message id7 recorded in the first fault feedback message is used as the first fault alarm information id1. If it exists, the third module confirms the first fault alarm information, sends the first fault alarm information confirmation message to the second module, and obtains the fault report and sends the fault report to the external alarm device.

[0062] The process by which the third module confirms and judges the second fault alarm information includes:

[0063] If the third module determines that the second fault alarm information contains the type identifier type4 of the second fault alarm information, then the third module determines whether the third module stores the same second fault alarm information id4 as the second fault alarm information in the second fault alarm information.

[0064] If not, the second fault feedback message is sent to the second module. If the second module does not send the second fault alarm information to the third module again within the updated second timer T200's timing period, the third module does not acknowledge the second fault alarm information and sends a second fault alarm information unacknowledged message to the second module. The second fault feedback message includes: the updated second timer T200 timing period, the updated fifth preset threshold H1, the updated sixth preset threshold H2, the updated third preset threshold G1, the updated fourth preset threshold G2, and the second fault feedback message id8. The second fault feedback message id8 is the same as the second fault alarm information id4. The updated second timer T200 timing period is 0.1 times the second timer T200 timing period in the second fault alarm information data, and the updated fifth preset threshold H1 is... The updated sixth preset threshold H2 is 1.05 times the fifth preset threshold H1, the updated third preset threshold G1 is 0.8 times the third preset threshold G1 in the second fault alarm information data, and the updated fourth preset threshold G2 is 0.8 times the fourth preset threshold G2 in the second fault alarm information data. After receiving the second fault feedback message, the second module uses the updated second timer T200 timing period, the updated fifth preset threshold H1, the updated sixth preset threshold H2, the updated third preset threshold G1, and the updated fourth preset threshold G2 to determine again whether the second fault situation occurs during the equal-length period. If it occurs, the second fault alarm information is sent to the third module again. The second fault alarm information sent by the second module to the third module again uses the second fault feedback message id8 as the second fault alarm information id4.

[0065] If present, the third module confirms the second fault alarm information, sends a second fault alarm information confirmation message to the second module, obtains the fault report, and sends the fault report to the external alarm device.

[0066] Specifically, the third module sends a confirmation message to the second fault alarm message when it confirms the second fault alarm message, and sends a non-confirmation message when it does not confirm. Both the confirmation message ID5 and the non-confirmation message ID6 are identical to the second fault alarm message ID4, enabling the second module to accurately associate the corresponding second fault alarm message. This allows for targeted processing of session data records in the third database starting from the second fault alarm message sending time date4, preventing historical data from affecting subsequent judgments. Simultaneously, by checking in the third module whether an alarm message identical to the first fault alarm message ID1 or the second fault alarm message ID4 is already stored, duplicate alarms are identified and distinguished. This allows alarm messages within the same time period to be managed based on a unique ID, improving the standardization of alarm processing. If the first or second fault alarm information is not confirmed, the third module sends a first or second fault feedback message to the second module. It also updates the timing periods of the first timer T100 and the second timer T200, as well as the corresponding preset threshold parameters. This allows the second module to re-evaluate whether the first or second fault condition occurs within the same time interval under shorter timing periods and adjusted threshold conditions, thereby improving the sensitivity and specificity of alarm judgment. Furthermore, when the second module re-sends the first or second fault alarm information, it uses the first fault feedback message id7 or the second fault feedback message id8 as the corresponding alarm information ID, respectively. This ensures that the re-triggered alarm information establishes a clear association with the initial alarm information, facilitating continuous judgment and confirmation processing by the third module.

[0067] When the third module confirms the first or second fault alarm information, it not only sends a corresponding alarm information confirmation message to the second module, but also obtains a fault report and sends the fault report to an external alarm device. This achieves closed-loop processing of alarm information, ensuring that alarm confirmation results can be output in a timely manner. In summary, through the above-mentioned alarm confirmation, unconfirmation, and feedback mechanisms, this application can achieve repeated verification of alarm information, adaptive parameter adjustment, and closed-loop management of alarm processing without changing the alarm type identifier and alarm information ID. This is beneficial to improving the accuracy and reliability of fault alarm judgment.

[0068] Specifically, the process of obtaining fault reports includes: the third module queries the session data records marked as alarmed in the second module through an interface; based on the values ​​of the target address field, type field, and protocol field in the alarmed session data records, it performs a matching search in the second database; for sessions that fail to match, it extracts the corresponding field values ​​from the alarmed session data records and adds a new node identity and access data record to the second database, setting the value of the type field of this record to indicate a non-preset address; based on the address field in the alarmed session data records, it queries the second database to determine the corresponding node ID; and randomly selects a node ID from the determined node IDs for sampling in a specified manner to obtain the data packets of the corresponding sampled session.

[0069] The specified sampling method includes: collecting data packets of all sessions of the selected node ID from the sending time date1 of the first fault alarm information within a complete online to offline time; or, collecting data packets of the selected node from the sending time date4 of the second fault alarm information within three consecutive complete session start to shutdown time.

[0070] Extract the value of the type field from the node identity and access data record corresponding to the selected node ID from the second database and use it as the sending field;

[0071] The first fault alarm message or the second fault alarm message, the data packet of the sampling session, and the sending field are packaged together as a fault report;

[0072] The second module is also used to delete the alarmed flag in the session data record of the third database when receiving an alarm cancellation message sent by an external alarm device through the third module.

[0073] Through the fault report acquisition process described in the above embodiments, the third module can perform a matching search in the second database based on the session data records marked as alarms in the second module, according to the target address field, type field, and protocol field. This enables the correlation analysis of node identity and access data, which is beneficial for accurately identifying the node identity information corresponding to abnormal access behavior after a fault occurs. If no matching node identity and access data record is found, the module extracts the field values ​​corresponding to the two-dimensional table structure of node identity and access data records in the second database from the alarmed session data records, adds a new node identity and access data record in the second database, and sets the value of the type field to represent a non-preset address. This allows for supplementary recording of access behavior at non-preset addresses, improving the coverage of node identity and access data and avoiding incomplete fault analysis due to database gaps.

[0074] See Figure 2 This embodiment also provides a cellular IoT node connection fault alarm device, including: a first module, a second module, and a third module; the second module obtains the online node ratio for a pre-divided equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module for the equal-length time period; the second module determines whether a first fault condition occurs during the equal-length time period based on the online node ratio; if it occurs, it sends a first fault alarm message to the third module so that the third module can save the first fault alarm message, and upon confirmation of the first fault alarm message, sends a fault report to an external alarm device connected to the third module; the first fault condition is when the deviation between the online node ratio during the equal-length time period and the average online node ratio during a specified historical time period exceeds a first preset threshold R1.

[0075] The cellular IoT node connection failure alarm device in this embodiment can realize the aforementioned cellular IoT node connection failure alarm method. By acquiring the proportion of online nodes within a pre-divided equal-length time period and comparing this proportion with the average proportion of online nodes over a specified historical time period, it can identify abnormal deviations at the overall node scale level, avoiding misjudgments caused by short-term fluctuations in a single node, thereby improving the stability and accuracy of the first fault condition judgment. Secondly, by combining AAA data to record node online / offline status and online duration, and periodically statistically analyzing node status through a first timer and counter, the calculation of the online node proportion has a clear data source and traceability. By constructing a fault report that includes alarm information, sampled session data packets, and node identity and access data, and supporting alarm cancellation and data tag recovery, a complete closed loop of alarm processing is formed, significantly improving fault location efficiency and the reliability of operation and maintenance management.

[0076] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for alarming connection failures of cellular IoT nodes, characterized in that, The method is applied to a cellular IoT node connection fault alarm device, the device being used to connect to multiple IoT nodes and external alarm devices respectively, the device comprising a first module, a second module, and a third module, and the method comprising: Within a pre-divided equal-length time period, the second module obtains the online node ratio for that equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module. The second module determines whether the first fault occurs during the equal-length period based on the online node ratio. If it does, it sends the first fault alarm information to the third module so that the third module can save the first fault alarm information and send a fault report to the external alarm device connected to the third module after confirming the first fault alarm information. The first fault condition is when the deviation between the proportion of online nodes in the same long period and the average proportion of online nodes in a specified historical period exceeds a first preset threshold R1. The first module includes: a first computing unit, a first storage unit, a first data interface, a second data interface, and a third data interface; The first calculation unit is used to add a new AAA data record in a preset first database in the first storage unit when the AAA data of the IoT node received by the second data interface contains message data with a node online identifier, based on the data corresponding to the node ID field, address field, and online field in the AAA data; when the AAA data contains message data with a node offline identifier, the first calculation unit is used to retrieve a matching AAA data record with an empty offline field in the AAA data records stored in the first database based on the data corresponding to the node ID field and offline field in the AAA data, and update the offline field of the AAA data record to the node offline time in the received AAA data; based on the updated online field and offline field, the online duration of the node in the received AAA data is calculated, and the calculation result is filled into the duration field in the newly added AAA data record; Obtain the proportion of online nodes for this long time period, including: Within each of the equal-length time periods, whenever the preset first timer T100 reaches its timing cycle, the following operations are performed: Query the first database to obtain the number of node IDs of AAA data records as the total number of nodes and the number of AAA data records with empty offline fields as the total number of online nodes. Assign the total number of nodes to the first counter N100 and the total number of online nodes to the second counter N101. Based on the current values ​​of the first counter N100 and the second counter N101, calculate the current online node ratio and record the calculation result as a temporary ratio value; For each equal-length time period, the last temporary ratio value obtained within that equal-length time period is determined as the online node ratio corresponding to that equal-length time period.

2. The cellular IoT node connection failure alarm method according to claim 1, characterized in that, Each AAA data record in the first database is a two-dimensional table structure, which includes at least: a node ID field, an address field, an online field, an offline field, and a duration field; The online field records the node's online time; the offline field records the node's offline time; the duration field represents the node's online duration calculated based on the node's online time recorded in the online field and the node's offline time recorded in the offline field; the address field records the node's network address; and the node ID field records the node's ID.

3. The cellular IoT node connection failure alarm method according to claim 2, characterized in that, The number of equal-length time periods is n, wherein the equal-length time periods are obtained by dividing 24 hours by a second preset threshold E1.

4. The cellular IoT node connection failure alarm method according to claim 3, characterized in that, The average proportion of online nodes over a specified historical period, including: The average value a1 is calculated based on the online node ratio values ​​corresponding to the five consecutive equal-length periods preceding the current equal-length period; and, The average value a2 is calculated based on the proportion of online nodes for corresponding time periods of the same length within the past three weeks that have the same weekday attribute and fall within the same daily time range as the current time period; where the same weekday attribute refers to the same weekday index value, which indicates the day of the week; and, When the date of the current equal-length period is a preset special day, the average value a3 is calculated based on the online node ratio values ​​corresponding to three special dates of the same type and close in time within the same time range for equal-length periods; and, When the current equal-length period falls on a weekday, the average value a4 is calculated based on the online node ratios corresponding to the equal-length periods within the same time range, excluding the current date, for other weekdays within the current week; or, when the current equal-length period falls on a non-weekday legal working day, the average value a4 is calculated based on the online node ratios corresponding to the same weekday attribute obtained by querying backward from the current date, for the same time range. The first fault alarm information includes: the sending time date1 of the first fault alarm information, the id1 of the first fault alarm information, the type identifier type1 of the first fault alarm information, and the data of the first fault alarm information; The first fault alarm information data includes: a first preset threshold R1, a second preset threshold E1, E2 parameters and the timing period of the first timer T100; the E2 parameter includes: average value a1, average value a2, average value a3 and average value a4.

5. The cellular IoT node connection failure alarm method according to claim 4, characterized in that, Upon confirming the first fault alarm information, the third module also sends a first fault alarm information confirmation message to the second module. The first fault alarm information confirmation message includes: the sending time of the first fault alarm information confirmation message date2, the first fault alarm information confirmation message id2, and the type identifier of the first fault alarm information confirmation message type2; If the third module does not acknowledge the first fault alarm information, it also sends a message to the second module that the first fault alarm information has not been acknowledged. The first unacknowledged fault alarm message includes: the sending time date3 of the first unacknowledged fault alarm message, the id3 of the first unacknowledged fault alarm message, and the type identifier type3 of the first unacknowledged fault alarm message; The first fault alarm confirmation message ID2 and the first fault alarm unconfirmation message ID3 are both the same as the first fault alarm message ID1.

6. The cellular IoT node connection failure alarm method according to claim 5, characterized in that, The first calculation unit is used to extract the values ​​of the node ID field, target address field, port field, address field, and protocol field from the node identity and access data of the IoT node received by the first data interface. The extracted values ​​of these five fields are then matched line by line with the corresponding fields of node identity and access data records stored in a preset second database in the first storage unit. If a node identity and access data record with completely identical values ​​of the five fields is found, the extracted node identity and access data is ignored. If no completely identical node identity and access data record is found, a unique sequence number is generated for the extracted node identity and access data. This sequence number, along with the values ​​of the five extracted fields and the type field, is used as a new node identity and access data record and written into the second database. The type field is set to represent a value that is not a preset address. The node identity and access data includes: node identity data and node preset access address data; Each node identity and access data record in the second database is a two-dimensional table structure, which includes at least: sequence field, node ID field, target address field, type field, port field, address field, and protocol field; The sequence field records the sequence number; the target address field records the target network address accessed by the node; the type field records the source type of the target network address; the port field records the port of the target network address accessed by the node; and the protocol field records the protocol used by the node to access the target address. The first computing unit is used to receive session data records of IoT nodes collected from the third data interface through the high-speed storage medium, and trigger the high-speed storage medium to perform cache data packaging operation when the packaging conditions are met. The packaging conditions are: reaching a preset fixed data packaging cycle, or the number of bytes of session data records cached by the high-speed storage medium reaching a preset upper limit value; During the packaging operation, each session data record is written into the third database according to the corresponding fields of the third database; the session data record in the third database is a two-dimensional table structure, which includes at least: address field, destination address field, protocol field, port field, start field, end field, live field, sent byte field, and received byte field; The start field records the time when the session started; the end field records the time when the session ended; the live field records the session live time calculated based on the session start time recorded in the start field and the session end time recorded in the end field; the sent bytes field records the number of data bytes sent by the node to the target address during the session; and the received bytes field records the number of data bytes received by the node from the target address during the session. Upon receiving the confirmation message for the first fault alarm, the second module deletes the E2 parameter corresponding to the first fault alarm for an equal period of time and restores it to the preset initial value. It also marks all session data records in the third database as alarmed starting from the sending time date1 of the first fault alarm.

7. The cellular IoT node connection failure alarm method according to claim 6, characterized in that, The method further includes: If no first fault occurs during the equal-length period, the second module determines whether a second fault occurs during the equal-length period. If it does, it sends a second fault alarm message to the third module so that the third module can save the second fault alarm message. Upon confirmation of the second fault alarm message, the third module sends a fault report to the external alarm device connected to the third module. The process of determining whether a second fault occurs during this extended period includes: When the timing period of the second timer T200 preset in the second module expires, it is detected whether there is new session data record in the third database in the first module. If it exists, the time of session survival in the session survival field of the new session data record is obtained. When |Tp - H1| / H1 > R2 and Tp < H1, the value of the third counter N200 is incremented by 1. Then, when |P1 / P2 - H2| / H2 > R3 and P1 / P2 < H2, the value of the fourth counter N201 is incremented by 1, and when the value of the third counter N200 is greater than or the value of the fourth counter N201 is greater than it is determined that a second failure situation occurs in the equal-length time period; Tp represents the session lifetime in the liveness field of the newly added session data record; and It is obtained in the following way: Read session data records from the third database and identify all session data records that are exactly the same as the values ​​of the target address field, protocol field, and port field in the newly added session data record as belonging to the same connection; The number of session data records contained in each connection is counted, and this number is taken as the number of sessions generated by that connection. Multiply the number of sessions for each connection by the third preset threshold G1 and the fourth preset threshold G2 respectively to obtain the corresponding connection. and ; In the case that the end field of the newly added session data record in the third database is not empty, the values ​​of the sent byte field and the received byte field in the newly added session data record are divided by the value of the live field to obtain the average number of uplink bytes P1 and the average number of downlink bytes P2 generated by the session corresponding to the newly added session data record during the connection duration. The second fault alarm information includes: the sending time of the second fault alarm information (date4), the ID of the second fault alarm information (id4), the type identifier of the second fault alarm information (type4), and the data of the second fault alarm information. The second fault alarm information data includes: the third preset threshold G1, the fourth preset threshold G2, the fifth preset threshold H1, the sixth preset threshold H2, the seventh preset threshold R2, the eighth preset threshold R3, the timing period of the second timer T200, the current value of the third counter N200, and the current value of the fourth counter N201.

8. The cellular IoT node connection failure alarm method according to claim 7, characterized in that, Upon confirming the second fault alarm information, the third module also sends a second fault alarm information confirmation message to the second module. The second fault alarm confirmation message includes: the sending time of the second fault alarm confirmation message (date5), the ID of the second fault alarm confirmation message (id5), and the type identifier of the second fault alarm confirmation message (type5); If the third module does not acknowledge the second fault alarm information, it also sends a message to the second module that the second fault alarm information has not been acknowledged. The second fault alarm message unacknowledged includes: the sending time date6 of the second fault alarm message unacknowledged, the id6 of the second fault alarm message unacknowledged, and the type identifier type6 of the second fault alarm message unacknowledged; The second fault alarm message confirmation message id5 and the second fault alarm message unconfirmation message id6 are both the same as the second fault alarm message id4. Upon receiving the confirmation message for the second fault alarm, the second module deletes all session data records in the third database starting from the sending time of the second fault alarm, date4. The process by which the third module confirms and judges the first fault alarm information includes: If the third module determines that the first fault alarm information contains the type identifier type1 of the first fault alarm information, then the third module determines whether it stores a first fault alarm information with the same first fault alarm information id1 as the first fault alarm information in the first fault alarm information. If it does not exist, the first fault feedback message is sent to the second module. If the second module does not send the first fault alarm message to the third module again within the timing period of the updated first timer T100, the third module does not acknowledge the first fault alarm message and sends a first fault alarm message unacknowledged to the second module. The first fault feedback message includes: the updated timing period of the first timer T100, the updated second preset threshold E1, and the first fault feedback message id7; wherein, the updated timing period of the first timer T100 is 0.1 times the timing period of the first timer T100 in the first fault alarm information data of the first fault alarm information, and the updated second preset threshold E1 is twice the value of the second preset threshold E1 in the first fault alarm information data; The first fault feedback message ID7 is the same as the first fault alarm message ID1; After receiving the first fault feedback message, the second module uses the updated timing period of the first timer T100 and the updated second preset threshold E1 to determine again whether the first fault occurs during the same period based on the proportion of online nodes. If it occurs, the second module sends the first fault alarm information to the third module again. In the first fault alarm information sent again by the second module to the third module, the first fault feedback message id7 recorded in the first fault feedback message is used as the first fault alarm information id1. If present, the third module confirms the first fault alarm information, sends a first fault alarm information confirmation message to the second module, obtains a fault report, and sends the fault report to an external alarm device. The process by which the third module confirms and judges the second fault alarm information includes: If the third module determines that the second fault alarm information contains the type identifier type4 of the second fault alarm information, then the third module determines whether the third module stores the same second fault alarm information id4 as the second fault alarm information in the second fault alarm information. If it does not exist, the second fault feedback message will be sent to the second module. If the second module does not send the second fault alarm information to the third module again within the timing period of the updated second timer T200, the third module will not acknowledge the second fault alarm information and will send a second fault alarm information acknowledgment message to the second module. The second fault feedback message includes: the updated timing period of the second timer T200, the updated fifth preset threshold H1, the updated sixth preset threshold H2, the updated third preset threshold G1, the updated fourth preset threshold G2, and the second fault feedback message id8; The second fault feedback message ID8 is the same as the second fault alarm message ID4; Among them, the updated second timer T200 timing period is 0.1 times the second timer T200 timing period in the second fault alarm information data; the updated fifth preset threshold H1 is 1.05 times the fifth preset threshold H1 in the second fault alarm information data; the updated sixth preset threshold H2 is 1.05 times the sixth preset threshold H2 in the second fault alarm information data; the updated third preset threshold G1 is 0.8 times the third preset threshold G1 in the second fault alarm information data; and the updated fourth preset threshold G2 is 0.8 times the fourth preset threshold G2 in the second fault alarm information data. After receiving the second fault feedback message, the second module uses the updated second timer T200 timing period, the updated fifth preset threshold H1, the updated sixth preset threshold H2, the updated third preset threshold G1, and the updated fourth preset threshold G2 to determine again whether the second fault situation occurs during the same long period. If it occurs, the second fault alarm information is sent to the third module again. In the second fault alarm information sent again by the second module to the third module, the second fault feedback message id8 is used as the second fault alarm information id4; If present, the third module confirms the second fault alarm information, sends a second fault alarm information confirmation message to the second module, obtains the fault report, and sends the fault report to the external alarm device.

9. The cellular IoT node connection failure alarm method according to claim 8, characterized in that, The process of obtaining a fault report includes: The third module queries the session data records marked as alarms in the second module through the interface, and performs a matching search in the second database based on the values ​​of the target address field, type field, and protocol field in the alarmed session data records. For sessions where no matching record is found, extract the corresponding field values ​​from the alarmed session data records and the two-dimensional table structure of the node identity and access data records in the second database. Add a new node identity and access data record in the second database and set the value of the type field of the node identity and access data record to a value that indicates a non-preset address. Based on the address field in the alarmed session data record, a second database is queried to determine the corresponding node ID. From the determined node IDs, a node ID is randomly selected for sampling in a specified manner to obtain the data packets of the corresponding sampling session. The specified sampling method includes: collecting data packets of all sessions of the selected node ID from the sending time date1 of the first fault alarm information within a complete online to offline time; or, collecting data packets of the selected node from the sending time date4 of the second fault alarm information within three consecutive complete session start to shutdown time. Extract the value of the type field from the node identity and access data record corresponding to the selected node ID from the second database and use it as the sending field; The first fault alarm message or the second fault alarm message, the data packet of the sampling session, and the sending field are packaged together as a fault report; The second module is also used to delete the alarmed flag in the session data record of the third database when receiving an alarm cancellation message sent by an external alarm device through the third module.

10. A cellular Internet of Things (IoT) node connection failure alarm device, characterized in that, include: Module 1, Module 2, Module 3; The second module obtains the online node ratio within a pre-divided equal-length time period based on the total number of IoT nodes and the total number of online nodes pre-collected in the first module for that time period. The second module determines whether the first fault occurs during the equal-length period based on the online node ratio. If it does, it sends the first fault alarm information to the third module so that the third module can save the first fault alarm information and send a fault report to the external alarm device connected to the third module after confirming the first fault alarm information. The first fault condition is when the deviation between the proportion of online nodes in the same long period and the average proportion of online nodes in a specified historical period exceeds a first preset threshold R1. The first module includes: a first computing unit, a first storage unit, a first data interface, a second data interface, and a third data interface; The first calculation unit is used to add a new AAA data record in a preset first database in the first storage unit when the AAA data of the IoT node received by the second data interface contains message data with a node online identifier, based on the data corresponding to the node ID field, address field, and online field in the AAA data; when the AAA data contains message data with a node offline identifier, the first calculation unit is used to retrieve a matching AAA data record with an empty offline field in the AAA data records stored in the first database based on the data corresponding to the node ID field and offline field in the AAA data, and update the offline field of the AAA data record to the node offline time in the received AAA data; based on the updated online field and offline field, the online duration of the node in the received AAA data is calculated, and the calculation result is filled into the duration field in the newly added AAA data record; Obtain the proportion of online nodes for this long time period, including: Within each of the equal-length time periods, whenever the preset first timer T100 reaches its timing cycle, the following operations are performed: Query the first database to obtain the number of node IDs of AAA data records as the total number of nodes and the number of AAA data records with empty offline fields as the total number of online nodes. Assign the total number of nodes to the first counter N100 and the total number of online nodes to the second counter N101. Based on the current values ​​of the first counter N100 and the second counter N101, calculate the current online node ratio and record the calculation result as a temporary ratio value; For each equal-length time period, the last temporary ratio value obtained within that equal-length time period is determined as the online node ratio corresponding to that equal-length time period.

Images