An edge-computing-based remote monitoring system for internet of things devices

Abstract

This invention relates to the technical field, specifically to a remote monitoring system for IoT devices based on edge computing. The system includes: a baseline module that generates an edge session baseline table based on network handshake messages; a parsing module that parses device messages and chip reception records; a judgment module that generates a session status record page by combining sequence number, acquisition time, signal strength, retransmission count, operating status, and alarm identifier; a resident module that partitions and writes messages; and an update module that generates update messages and writes them to the corresponding record location on the server. In this invention, by verifying sessions based on network communication characteristics, associating communication, and performing partitioned resident and targeted updates based on operating and alarm status, the system distinguishes between network fluctuations and device anomalies, reduces misjudgments caused by out-of-order signals, weak signals, and retransmissions, maintains continuous tracking, reduces redundant server parsing and invalid transmissions, shortens alarm links, and improves the accuracy, real-time performance, and resource utilization efficiency of remote monitoring.

Description

Technical Field

[0001] This invention relates to the field of technology, and more particularly to a remote monitoring system for Internet of Things (IoT) devices based on edge computing. Background Technology

[0002] In existing IoT remote monitoring processes, edge gateways are only responsible for summarizing terminal messages, uploading them directly to the server, and updating records based on single status results. The edge side lacks verification of the correlation between network communication characteristics and the continuity of subsequent sessions. Network jitter, signal attenuation, or message retransmission can easily misjudge communication anomalies as operational anomalies. Out-of-order messages and data acquisition time offsets can also disrupt the continuity of status records. Normal data, abnormal session data, and alarm data are mixed in the same processing link, requiring the server to repeatedly parse and verify the original messages, resulting in delayed alarm responses, difficulty in status tracking, and increased bandwidth and computing resource consumption. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies (which, in addition to those mentioned in the background section, will be further elaborated in the specific implementation) and to propose a remote monitoring system for Internet of Things (IoT) devices based on edge computing.

[0004] To achieve the above objectives, one aspect of the present invention provides a remote monitoring system for Internet of Things (IoT) devices based on edge computing, for use at the edge, characterized by comprising the following modules:

[0005] The baseline module is used to receive multiple handshake confirmation messages during the IoT terminal network access phase, record device identification information, device communication address, message arrival interval set, received signal strength and message retransmission count, and generate an edge session baseline table.

[0006] The parsing module, connected to the benchmark module, is used to receive device data packets and communication chip reception records, parse the packet sequence number, acquisition time, operating status value, environmental parameter value and alarm identifier, and read the edge session benchmark table.

[0007] The edge preprocessing module, connected to the parsing module, is used to perform Kalman filtering, message reordering and retransmission deduplication on the parsed field records, and output the cleaned parsed field records.

[0008] The determination module, connected to the edge preprocessing module, is used to generate a session status record page based on the message sequence number, acquisition time, received signal strength, message retransmission count, running status value and alarm identifier.

[0009] The AI ​​inference module, connected to the judgment module, is used to deploy a lightweight machine learning model to perform real-time anomaly scoring, adaptive threshold adjustment, distinguish between communication anomalies and operational anomalies, and perform cross-device correlation analysis, and output an AI-enhanced status record page.

[0010] The dwell module, connected to the AI ​​inference module, is used to write device data packets into the normal state dwell area, session keep-alive dwell area, or alarm state dwell area according to the AI ​​enhanced status record page, and output the dwell area type.

[0011] The update module, connected to the resident module, is used to generate a monitoring update message according to the resident area type, and write the monitoring update message to the normal status record location, session status record location, or alarm status record location of the remote server.

[0012] As a further embodiment of the present invention, the reference module includes an acknowledgment receiving submodule, an interval statistics submodule, and a reference writing submodule;

[0013] The receiving confirmation submodule is configured to receive multiple handshake confirmation messages corresponding to the same device identification information from the network access monitoring interface of the edge gateway, match the device communication address written in the communication chip with the address field in the message header, and output the handshake reception record when the match is successful.

[0014] The interval statistics submodule is configured to calculate the arrival time difference of adjacent messages according to the receiving time order in the handshake receiving record, and obtain the message arrival interval set after removing the retransmitted messages corresponding to the duplicate handshake sequence number.

[0015] The baseline writing submodule is configured to associate the device identification information, the device communication address, the message arrival interval set, the received signal strength range, and the message retransmission count into the edge storage table to generate an edge session baseline table.

[0016] As a further embodiment of the present invention, the parsing module includes a record matching submodule, a field extraction submodule, and a benchmark reading submodule;

[0017] The record matching submodule is configured to acquire device data packets and communication chip reception records, and match the device data packets with the communication chip reception records according to the device communication address, physical layer reception timestamp and packet length to generate packet reception matching records.

[0018] The field extraction submodule is configured to read the header field, payload field and check field from the device data packet corresponding to the message receiving matching record, parse the message sequence number, collection time, running status value, environmental parameter value and alarm identifier, and generate a parsed field record.

[0019] The benchmark reading submodule is configured to read the edge session benchmark table based on the device identification information and device communication address in the parsed field records, and output the benchmark association record.

[0020] Compared with the prior art, the advantages and positive effects of the present invention include, but are not limited to:

[0021] In this invention, during the terminal network access phase, the device identifier, communication address, arrival interval, signal strength, and retransmission characteristics in the handshake confirmation message are aggregated to form a session verification benchmark. When receiving service messages, the message sequence number is combined with the collection time, operating values, alarm identifiers, and communication chip records to generate a session state. Based on the state differences, the data is stored in the normal state, session hold, or alarm state area, enabling hierarchical identification of communication fluctuations and actual operational anomalies, avoiding changes in remote state due to out-of-order, weak signals, and retransmission interference. Monitoring updates only carry the corresponding information and are written to the corresponding location on the server, thereby shortening the alarm link, maintaining the continuity of the state trajectory, reducing repeated parsing and invalid transmission, and improving the accuracy of remote monitoring and resource utilization efficiency. Attached Figure Description

[0022] Figure 1 This is the main flowchart for edge session monitoring and updating in this invention;

[0023] Figure 2 This is a schematic diagram illustrating the effect of generating an edge gateway session baseline according to the present invention;

[0024] Figure 3 This is a schematic diagram illustrating the effect of device data packet parsing and session state classification in this invention;

[0025] Figure 4 This is a schematic diagram illustrating the mapping effect of the dwell area classification and remote recording location in this invention;

[0026] Figure 5 This is a schematic diagram illustrating the effect of abnormal message retention and remote pending confirmation tracing in this invention. Detailed Implementation

[0027] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0028] IoT device monitoring technology involves data packet transmission based on network protocols, device status acquisition, communication session maintenance, and remote monitoring information exchange between IoT terminals, edge computing nodes, gateway devices, and remote servers. A traditional edge computing-based remote monitoring system for IoT devices is a network communication system consisting of IoT devices, edge gateways, communication networks, remote servers, and monitoring terminals. IoT devices collect operating status, environmental parameters, and alarm information through communication interfaces and encapsulate them into device data packets. The edge gateway receives the data packets and parses, caches, and forwards them according to application-layer communication protocols. The remote server writes the data to the monitoring database based on the device identifier, communication address, and timestamp. The monitoring terminal sends query requests to the server via network connection and receives the corresponding IoT device's operating status data.

[0029] Through long-term engineering practice, the inventors discovered that in existing IoT remote monitoring processes, the edge gateway is only responsible for summarizing terminal messages, directly uploading them to the server, and updating records according to a single state result. The edge side lacks the correlation verification between the characteristics of incoming network communication and the continuity of subsequent sessions. Network jitter, signal attenuation, or message retransmission can easily misjudge communication abnormalities as operational abnormalities. Out-of-order messages and data acquisition time offsets can also disrupt the continuity of state records. Normal data, abnormal session data, and alarm data are mixed in the same processing link, requiring the server to repeatedly parse and verify the original messages, resulting in delayed alarm response, difficulty in state tracking, and increased bandwidth and computing resource consumption.

[0030] This embodiment provides a remote monitoring system for IoT devices based on edge computing. The system is deployed in an edge gateway hardware device equipped with a processor, memory, and communication network interface. In practical applications, such as in a continuous communication environment where the edge gateway connects to IoT terminals and forwards terminal operation data to a remote server, the terminal network handshake, device data packet reception, link status determination, edge resident cache, and remote record update are connected on the same edge gateway side according to the session relationship. The system includes a base module, a parsing module, a determination module, a resident module, and an update module implemented by the processor executing computer program instructions in the memory.

[0031] Baseline module

[0032] The reference module is a network access reference generation structure set on the edge gateway side. It is used to receive handshake confirmation messages during the network access interaction of IoT terminals, and organize the device identification information, device communication address, message arrival interval set, received signal strength and message retransmission number corresponding to the handshake confirmation message into an edge session reference table.

[0033] Among them, the device identification information is a terminal identity field written in the message header or network access registration record, used to distinguish different IoT terminals within the edge gateway. The device communication address is an address field formed by the communication chip during link access, used to locate the session entry point of the same terminal when subsequent data packets arrive. The message arrival interval set is a set of time interval records formed by the handshake confirmation messages according to their reception order, used to describe the message arrival rhythm of the terminal during the network access phase. Received signal strength is a field in the communication chip's reception record reflecting the link reception status, and the message retransmission count is a retransmission field jointly confirmed during the handshake phase by the repeated handshake sequence number and the communication chip's retransmission record.

[0034] like Figure 1 As shown, the benchmark module may further include an acknowledgment receiving submodule, an interval statistics submodule, and a benchmark writing submodule during implementation.

[0035] The acknowledgment receiving submodule is configured to receive handshake acknowledgment messages corresponding to the same device identification information from the network access monitoring interface of the edge gateway. The network access monitoring interface is a message receiving interface exposed by the edge gateway to IoT terminals. Its input is the network access acknowledgment signal sent by the terminal communication chip, and its output is the handshake reception record to be verified. The acknowledgment receiving submodule reads the device communication address written by the communication chip and reads the address field in the message header of the handshake acknowledgment message, performing consistency matching between the two types of address fields according to the protocol registration relationship. When a match is found, the handshake acknowledgment message is written to the handshake reception record, which includes device identification information, device communication address, handshake sequence number, reception time, received signal strength, and retransmission indication fields, and is then passed to the interval statistics submodule. When a match is not found, the acknowledgment receiving submodule does not write the message to the edge session baseline table, but instead generates an address mismatch flag and writes the message header field, communication chip address field, and reception entry flag to the network access anomaly record area for gateway maintenance interface traceability.

[0036] The interval statistics submodule is configured to generate a record of the arrival time difference of adjacent packets according to the reception time order in the handshake reception record, and to obtain a set of packet arrival intervals after removing retransmitted packets corresponding to duplicate handshake sequence numbers. A duplicate handshake sequence number is a handshake sequence number field that appears again under the same device identification information and has the same session address. The interval statistics submodule marks it as a retransmission source, but does not treat it as an independent interval source for normal arrival rhythm; however, it retains the corresponding retransmission field for subsequent baseline writing. The set of packet arrival intervals is not used as an isolated value in subsequent processing, but is stored as a rhythm reference field in the edge session baseline table, along with the device identification information and device communication address. When a handshake reception record lacks a reception time or handshake sequence number, the interval statistics submodule generates an incomplete handshake record identifier, sends the record to the network access anomaly record area, and retains other handshake reception records that have passed address matching to continue forming baseline data. When a handshake record arrives out of order, the interval statistics submodule reorganizes the record according to the reception time order and writes the out-of-order status into an additional status field, enabling the subsequent judgment module to identify that the terminal has timing disturbances during the network access phase.

[0037] The baseline writing submodule is configured to associate device identification information, device communication address, message arrival interval set, received signal strength range, and message retransmission count into the edge storage table, generating an edge session baseline table. The received signal strength range is a baseline status field formed based on the received signal strength field in the handshake reception record during the network access phase. The field boundaries are derived from the communication chip's factory receiving capability, the edge gateway's deployment location, and the actual reception records during the network access phase. When the message retransmission count is written as a baseline field, the baseline writing submodule simultaneously records the duplicate sequence number identification result from the handshake phase and the communication chip's retransmission record.

[0038] Preferably, the edge storage table uses both device identification information and device communication address as the retrieval entry point to avoid misuse of the same device identification information due to address updates.

[0039] Preferably, when the edge storage table write fails, the baseline write submodule generates a baseline write failure flag and saves the handshake reception record in the temporary network entry buffer.

[0040] Preferably, when the device re-initiates network access, the baseline writing submodule reads the records that have not yet been written in the temporary network access cache, and continues to form the edge session baseline table after the address matching and field integrity verification are successful.

[0041] By establishing an edge session baseline table, a baseline session reference data table is created in the local storage area of ​​the edge gateway. This table carries the correlation between device identification information, device communication address, message arrival interval set, received signal strength range, and message retransmission count, providing a data baseline for subsequent parsing and judgment modules.

[0042] Resolution module

[0043] The parsing module is connected to the benchmark module and is used to receive device data packets and communication chip reception records, parse the packet sequence number, acquisition time, operating status value, environmental parameter value and alarm flag, and read the edge session benchmark table.

[0044] Among them, device data packets are business packets sent by IoT terminals during operation, carrying header fields, payload fields, and checksum fields. Communication chip receive records are physical layer records generated by the edge gateway communication chip when receiving device data packets, carrying the device communication address, physical layer receive timestamp, packet length, received signal strength, and retransmission records. The parsing module does not directly determine the dwell zone type; its output consists of parsed field records and baseline association records, which are then passed to the determination module.

[0045] like Figure 2 As shown, the parsing module can be further implemented by including a record matching submodule, a field extraction submodule, and a baseline reading submodule.

[0046] The record matching submodule is configured to acquire device data packets and communication chip receive records. It matches the device data packets with the communication chip receive records based on the device communication address, physical layer receive timestamp, and packet length, generating a packet receive matching record. The device communication address is used to confirm the packet source terminal, the physical layer receive timestamp is used to confirm the sequential correspondence between the communication chip receive record and the gateway packet buffer record, and the packet length is used to confirm that the packet body matches the length field of the receive record. The packet receive matching record is an intermediate data object generated internally by the parsing module, carrying the correspondence between the device data packets and the communication chip receive records, and incorporating the received signal strength and packet retransmission count into subsequent judgment links. Device data packets that cannot be matched with a communication chip receive record are marked as missing and enter the verification buffer. When multiple receive records correspond to the same device data packet, the record matching submodule narrows the matching range according to a fixed order of consistent device communication address, similar receive timing, and consistent packet length, and writes the unused receive records into the receive conflict record area.

[0047] The field extraction submodule is configured to read the header field, payload field, and checksum field from the device data packet corresponding to the message reception matching record, parse the message sequence number, acquisition time, operating status value, environmental parameter value, and alarm identifier, and generate a parsed field record. The message sequence number is the order field set by the terminal for consecutive messages within the same session; the acquisition time is the time field written when the terminal acquires the operating status and environmental parameters; the operating status value is the status data converted from the terminal's operating status field; the environmental parameter value is the environmental data converted from the terminal's environmental parameter field; and the alarm identifier is the status marker formed by mapping and converting the alarm field in the payload according to protocol rules. The checksum field is used to confirm that the message header field and payload field have not suffered protocol layer corruption during transmission. When the checksum fails, the field extraction submodule does not generate a parsed field record that can enter the judgment module, but instead generates a parsing failure identifier and writes the message reception matching record to the parsing error record area. When parsing the payload field, the field extraction submodule retrieves the acquisition time field, running status field, environmental parameter field, and alarm field from the payload field. It then sequentially truncates the payload field according to preset field length boundaries and associates the truncated results with the packet sequence number in the packet header field to obtain a field segmentation record. The preset field length boundaries are derived from the terminal communication protocol configuration table, stored in the protocol parsing configuration area of ​​the edge gateway, and invoked by the parsing module after the terminal protocol version is registered. The field segmentation record stores the truncated results, field names, field sources, and association relationships with packet sequence numbers for each field within the same device data packet. When the acquisition time field in the field segmentation record is earlier than the edge gateway's reception time but does not exceed the allowable boundary corresponding to the acquisition delay threshold field, the field extraction submodule converts the running status field into a running status value, the environmental parameter field into an environmental parameter value, and the alarm field into an alarm identifier, generating a parsed field record. The acquisition delay threshold field is derived from the protocol configuration table and the gateway operation and maintenance configuration; its engineering meaning is the delay boundary between terminal acquisition and edge gateway reception that is allowed to be recognized as the same running session. When the acquisition time field is later than the edge gateway's reception time, or falls outside the delay boundary, the field extraction submodule generates an acquisition time anomaly flag and writes the flag into the anomaly appendix of the parsed field record, enabling the judgment module to include the timing anomaly in the session state record page.

[0048] The reference reading submodule is configured to read the edge session reference table based on the device identification information and device communication address in the parsed field records, and output the reference association record. The reference association record is the reference object passed from the parsing module to the decision module, carrying the reference received signal strength, the reference message retransmission count, the message arrival interval set, and the reference table version identifier related to the device identity. When the device identification information exists but the device communication address changes, the reference reading submodule first queries the address update record in the edge session reference table, and then confirms whether the current address belongs to a valid session address of the same terminal. When the edge session reference table is not read, the reference reading submodule generates a reference missing state and notifies the reference module to re-enter the network access reference generation process; in the reference missing state, the parsed field record will not directly enter the normal state resident link, but will enter the decision module with the reference missing identifier, and the decision module will form a record page according to the session persistence state.

[0049] By improving the traditional IoT terminal data collection and parsing process, the message matching status during the parsing process is recorded, and the running status values, environmental parameter values, and alarm flags of the data collection are collected. Based on these flags, the correct fields in the message are extracted. In the case of abnormal extraction, parsing field records are generated for processing by the edge preprocessing module and the judgment module. This ensures the accuracy of the data while maximizing the retention of abnormal data.

[0050] Edge pre-processing module

[0051] The edge preprocessing module, connected to the parsing module, performs Kalman filtering, message reordering and retransmission deduplication on the parsed field records, outputting cleaned parsed field records. Kalman filtering estimates the true system state and filters out measurement noise. Reordering and retransmission deduplication restore the order of out-of-sequence messages and remove duplicate messages, thus reducing the number of transmissions and ensuring the integrity of valid data.

[0052] When implementing the edge preprocessing module, it may further include a statistical Kalman filter submodule, an out-of-order reassembly submodule, and a retransmission deduplication submodule.

[0053] The Kalman filter submodule is configured to perform Kalman filtering on the operating status values ​​and environmental parameter values ​​to estimate the true system state and filter out measurement noise, obtaining cleaned operating status values ​​and environmental parameter values. Before the filtering operation, in order to calculate the mean and standard deviation of the operating status values ​​and environmental parameter values ​​within the sliding window, data points that deviate from the mean by more than 3 times the standard deviation are marked as statistical outliers and removed from subsequent Kalman filtering.

[0054] The out-of-order reassembly submodule is configured to maintain a queue of expected message sequence numbers. It temporarily stores out-of-order messages in an out-of-order buffer, reassembling them in order upon arrival of messages with missing sequence numbers. If a timeout threshold is exceeded, the messages are released in the order of their reception time and marked as having a timing anomaly. Due to factors such as transmission path switching, the data reported by IoT terminals may sometimes be out of order. That is, a data message sent earlier may be received by the edge computing node later, while a later-sent data message may arrive at the edge computing node before the earlier one. This can lead to out-of-order data messages from the same device at the edge computing node. Discarding these out-of-order messages and requiring the IoT terminal to retransmit them would result in additional data transmission volume and delays in data collection or alarm processing.

[0055] The retransmission deduplication submodule is configured to identify retransmitted messages based on message sequence number and checksum field, retaining only the first received message, while retransmitted copies are either discarded or used for signal quality assessment. Traditional edge gateways directly forward collected data reported by IoT terminals. When receiving collected data, edge gateways may encounter message checksum errors due to link quality or network jitter, triggering message retransmission. In cases of poor channel quality, multiple retransmissions may occur. If these retransmitted messages are directly forwarded to the server, it will significantly increase the server's processing load.

[0056] Edge preprocessing further reduces the impact of measurement noise on the parsed field records, providing more accurate operating status and environmental parameter values ​​for subsequent decision-making modules. Furthermore, edge preprocessing filters out out-of-order and redundant retransmitted data, reducing the amount of data transmitted, saving network bandwidth, and lowering communication costs—crucial for large-scale AIoT deployments.

[0057] Decision module

[0058] The decision module connects to the edge preprocessing module and generates a session status record page based on the message sequence number, acquisition time, received signal strength, message retransmission count, operating status value, and alarm identifier. The session status record page is a temporary status page maintained by the edge gateway for the same device identification information, carrying sequence status items, link status items, operating status values, alarm identifiers, and the main page status. The main page status is a comprehensive status field in the session status record page, used to indicate to subsequent resident modules whether to write to the normal status resident area, the session persistence resident area, or the alarm status resident area. The decision module does not directly write to the remote server; its output session status record page serves as the status source jointly invoked by the resident module and the update module.

[0059] When implementing the determination module, it may further include a time-series comparison submodule, a link deviation submodule, and a record page generation submodule.

[0060] The sequence comparison submodule is configured to obtain the packet sequence number and the collection time, and jointly compare the increasing state of the packet sequence number relative to the most recently parsed packet sequence number with the sequential state of the collection time relative to the most recently parsed collection time to generate a sequence status item. The most recently parsed packet sequence number and the most recently parsed collection time originate from the previous valid parsed field record of the same device identification information in the edge gateway session cache. When a device has joined the network but has not yet formed a previous valid parsed field record, the sequence comparison submodule uses the initial session state after the network access confirmation as the initial reference and writes the current packet sequence number and the current collection time into the session cache. When both the increasing state of the packet sequence number and the sequential state of the collection time conform to the session order, the sequence status item is written as the normal order state; when there is packet sequence number rollback, collection time inversion, packet sequence number duplication, or collection time missing, the sequence status item is written as the sequence abnormal state, with an attached abnormal source field. Sequence anomalies do not directly cause packet loss; instead, they are passed to the resident module as components of the session state record page, allowing the packet to enter the session persistence resident area or alarm state resident area for retention and tracing. The link deviation submodule is configured to acquire the received signal strength, packet retransmission count, and the baseline received signal strength and baseline packet retransmission count from the edge session baseline table to determine the signal strength deviation state and retransmission deviation state, and generate link state entries. The received signal strength comes from the communication chip's receive record, and the baseline received signal strength comes from the edge session baseline table generated by the baseline module; both types of fields are written using the same communication chip's receive caliber. The packet retransmission count comes from the communication chip's receive record corresponding to the current data packet and the duplicate packet identification result; the baseline packet retransmission count comes from the handshake record during the network access phase.

[0061] The link deviation submodule first confirms that the current field and the reference field belong to the same device identification information and the same device communication address. Then, it reads the strength deviation threshold field and retransmission deviation threshold field from the link determination rule table. These fields are derived from communication protocol configuration, edge gateway network access calibration records, and operation and maintenance rule configurations, serving as lookup boundaries for judgment. For example, the strength deviation threshold is set to -85dBm, and the retransmission deviation threshold is 3 times. Although their specific values ​​are not saved in the session state record page, they can be directly compared by the determination program. When determining the signal strength deviation state and retransmission deviation state, the link deviation submodule obtains the strength difference state between the received signal strength and the reference received signal strength. It compares the strength difference state with the determination boundary corresponding to the strength deviation threshold field using text rules, and determines a signal attenuation flag when the difference state falls into the attenuation category. Similarly, the link deviation submodule obtains the retransmission difference state between the number of message retransmissions and the number of reference message retransmissions. It compares the retransmission difference state with the determination boundary corresponding to the retransmission deviation threshold field using text rules, and determines a retransmission anomaly flag when the difference state falls into the retransmission anomaly category. When the signal attenuation flag or the retransmission anomaly flag is set, the link status item is determined to be in an unstable session state; when neither the signal attenuation flag nor the retransmission anomaly flag is set, the link status item is determined to be in a stable session state. When the received signal strength field is missing, the reference received signal strength field is missing, or the message retransmission count field cannot be confirmed, the link deviation submodule does not write the link status item to the stable session state, but instead writes it to the link pending verification state, and writes the source of the missing information to the session status record page for identification by the resident module.

[0062] The record page generation submodule is configured to write the sequence status item, link status item, running status value, and alarm identifier into a temporary record page corresponding to the same device identification information, generating a session status record page. The temporary record page is a paged data object in the edge gateway's session cache, using device identification information and device communication address as index entries to store the session connection relationship between the current packet and the previous valid parsed field record. The main page state is formed by the alarm identifier, link status item, and sequence status item in a fixed priority order: when the alarm identifier hits the alarm trigger value field, the main page state is written with the alarm status; when the alarm identifier misses and the link status item is in an unstable session state or a link pending verification state, the main page state is written with the session hold state; when the alarm identifier misses and the link status item is in a stable session state and the sequence status item does not show any abnormality, the main page state is written with the normal state. The alarm trigger value field originates from the alarm field definition in the terminal protocol and the alarm rule configuration issued by the remote server, and is stored in the edge gateway's alarm rule area. After the session status record page is generated by the record page generation submodule, the page identifier, device identifier information, page main status and message sequence number are passed to the resident module. At the same time, the session status record page is saved in the session cache area for the AI ​​inference module to perform abnormal data inference and for the update module to build monitoring update messages.

[0063] By leveraging the edge layer's proximity to the data source, computation is performed near the data's origin, reducing the amount of data the server needs to process. Simultaneously, it maximizes the use of state data collected during transmission to aid in anomaly detection. Data deemed abnormal is not discarded directly; instead, its state information is recorded to create a session state log page for subsequent AI inference training.

[0064] AI inference module

[0065] The AI ​​inference module, connected to the judgment module, performs intelligent anomaly detection and classification inference of data packets, and outputs an AI-enhanced status record page, providing accurate classification basis for the three-level dwell partition of the subsequent dwell module.

[0066] When implementing AI inference, it may further include an anomaly screening pool module and an anomaly classification pool module.

[0067] The anomaly screening pool module is configured to perform initial binary separation on the input session state record page using a Gaussian mixture model, distinguishing between normal and abnormal data, and outputting normal and abnormal data pools. The session state record page from the judgment module contains the following features: operating status value (x1): standardized value of the device operating status; environmental parameter value (x2): standardized value of the environmental parameters; signal strength deviation (x3): the difference between the current signal strength and the reference signal strength; retransmission frequency (x4): the number of message retransmissions per unit time; message arrival interval variance (x5): the variance of the arrival time difference between adjacent messages; acquisition time deviation (x6): the deviation between the corrected acquisition time and the expected time; timing status flag (x7): normal sequence = 0, timing abnormal = 1; link status flag (x8): stable session = 0, unstable session = 1, link pending verification = 0.5. Therefore, the feature vector is: X = [x1, x2, x3, x4, x5, x6, x7, x8] ∈ R.

[0068] Assume that normal data is generated by a mixture of K Gaussian distributions:

[0069]

[0070] Where k is an empirical parameter, πk is the mixing coefficient, satisfying ∑πk = 1; μk is the mean vector of the k-th Gaussian distribution; Σk is the covariance matrix of the k-th Gaussian distribution; It is the probability density function of a multivariate Gaussian distribution.

[0071] Abnormal scores are calculated using the following formula:

[0072]

[0073] Judgment rule: If s_GMM(X) ≤ θ_GMM, it is judged as normal data and enters the normal data pool; if s_GMM(X) > θ_GMM, it is judged as abnormal data and enters the abnormal data pool. θ_GMM is an adaptive threshold, dynamically adjusted through sliding window statistics.

[0074] The specific model training is divided into two steps: (1) Initial training: collect normal traffic data during the edge session baseline table generation stage, and use the EM algorithm to estimate GMM parameters {πk, μk, Σk}; (2) Online update: maintain a sliding window, continuously monitor the abnormal score distribution of normal data, and trigger GMM parameter re-estimation when concept drift is detected.

[0075] The anomaly classification pool module is configured to use local anomaly coefficients for open set identification, distinguishing between known anomalies and novel unknown anomalies. It then uses random forests for binary classification to differentiate between communication layer anomalies and operational layer anomalies, finally outputting a normal pool, a communication anomaly pool, an operational anomaly pool, and an unknown anomaly pool. Specifically, identification is achieved through local anomaly coefficients. These coefficients identify novel unknown anomalies by comparing the local density of a data point with the local density of its neighbors. The local anomaly coefficients are obtained using the following formula:

[0076]

[0077] Where Nk(X) is the set of k nearest neighbors of X, and lrdk(X) is the local reachability density of X.

[0078] Outlier score: s_LOF(X) = LOFk(X)

[0079] Judgment rule: If s_LOF(X) > θ_LOF, it is judged as a new type of unknown anomaly and enters the unknown anomaly pool; if s_LOF(X) ≤ θ_LOF, further processing is performed.

[0080] The abnormal data features are divided into a communication layer feature subset and an operational layer feature subset: The communication layer feature subset Z_comm = [z3, z4, z5, z6, z7, z8], including signal strength change rate z3, retransmission frequency z4, message arrival interval variance z5, acquisition time deviation z6, timing status flag z7, and link status flag z8. The operational layer feature subset Z_op = [z1, z2, z9, z10, z11], including operational status deviation z1, environmental parameter mutation amplitude z2, operational status change rate z9, environmental parameter change rate z10, and alarm flag strength z11. RF consists of T decision trees, each trained on Bootstrap sampling and random feature subsets. If P(communication anomaly|Z) > P(operational anomaly|Z), it is determined to be a communication layer anomaly and enters the communication anomaly pool; if P(operational anomaly|Z) > P(communication anomaly|Z), it is determined to be an operational layer anomaly and enters the operational anomaly pool. Information on the normal pool, communication anomaly pool, operation anomaly pool, and unknown anomaly pool is written into the session state record page to form the AI-enhanced state record page.

[0081] The AI ​​inference module can perform intelligent anomaly detection and classification inference of data packets at the edge, and output an AI-enhanced status record page, providing accurate classification basis for the subsequent three-level dwell partitioning of the dwell module.

[0082] Residency module

[0083] The residency module connects to the decision module and is used to write device data packets into the normal state residency area, session persistence residency area, or alarm state residency area based on the AI-enhanced status record page, and output the residency area type. The normal state residency area is a cache area used by the edge gateway to store data packets with stable sessions and no alarms triggered. The session persistence residency area is a cache area used by the edge gateway to store packets with unstable links, timing anomalies, missing baselines, or pending verification. The alarm state residency area is a cache area used by the edge gateway to store data packets whose alarm identifiers match alarm rules and the corresponding AI-enhanced status record pages. The residency area type is a classification field output by the residency module to the update module. Its content comes from the target residency area identifier conversion result and is used to indicate the target record location where the monitoring update packet is written to the remote server.

[0084] like Figure 3 As shown, the resident module may be further included in its implementation as a record page reading submodule, a resident allocation submodule, and a type output submodule.

[0085] The record page reading submodule is configured to acquire the main page status, link status items, timing status items, and alarm identifiers from the AI-enhanced status record page, establish a page message association relationship between the main page status and the device identifier information of the device data packet, and output a dwell determination record. The page message association relationship is an internal association object within the dwell module, used to confirm that the device data packet corresponding to the current AI-enhanced status record page has not been replaced, has not been repeatedly written, and has not been referenced across devices. The record page reading submodule first reads the page identifier from the AI-enhanced status record page, then reads the device identifier information and message sequence number from the device data packet, and verifies whether the two types of information are consistent with the association information output by the determination module. When the association is consistent, the record page reading submodule generates a dwell determination record, which carries the main page status, link status items, timing status items, alarm identifiers, device identifier information, and message sequence number. When the association is inconsistent, the record page reading submodule generates a page message mismatch identifier, writes the AI-enhanced status record page and the device data packet into the dwell anomaly record area, and prevents the packet from entering the normal state dwell area.

[0086] The dwell allocation submodule is configured to determine the target dwell area based on the page master state in the dwell determination record, between the normal state dwell area, the session persistence dwell area, and the alarm state dwell area, and write the device data packet to the target dwell area, generating a dwell write record. When determining the target dwell area, the dwell allocation submodule obtains the page master state, link status item, and alarm identifier, compares the alarm identifier with the alarm trigger value field, and if the comparison matches or the AI ​​inference module infers "runtime layer anomaly," the target dwell area is determined as the alarm state dwell area. When writing to the alarm state dwell area, the dwell allocation submodule simultaneously saves the device data packet, the AI-enhanced status record page, and the trigger source field, enabling the remote server to read the packet content and edge determination source at the alarm record location. When the alarm flag does not match the alarm trigger value field and the link status item is in an unstable session state, or the AI ​​inference module infers "communication layer anomaly" or "unknown anomaly", the target dwell area is determined to be a session-persistent dwell area. When the alarm flag does not match the alarm trigger value field and the link status item is in a stable session state, or the AI ​​inference module infers that no anomaly was found, the target dwell area is determined to be a normal state dwell area. When the link status item is in a pending verification state or the timing status item has an anomaly, the dwell allocation submodule determines the target dwell area to be a session-persistent dwell area and retains the pending verification source in the dwell write record. When the dwell area write fails, the dwell allocation submodule generates a dwell failure flag, saves the device data packet and the AI ​​enhanced status record page to the rewrite buffer, and feeds back the dwell failure status to the type output submodule.

[0087] The type output submodule is configured to read the target residency area identifier from the residency write record, convert the target residency area identifier into a residency area type, and output the residency area type. The target residency area identifier is a storage identifier in the edge gateway's internal cache area, and the residency area type is a service classification field for the update module. The type output submodule converts normal state residency area identifiers into normal state types, session persistence residency area identifiers into session persistence types, and alarm state residency area identifiers into alarm state types according to the residency area mapping configuration. When the residency write record contains a residency failure identifier, the type output submodule outputs the session persistence type along with the residency failure source, causing the update module to write the packet to the session state record location on the remote server, instead of writing unacknowledged residency packets to the normal state record location. After outputting the residency area type, the type output submodule transmits the device identification information, packet sequence number, residency area type, and page identifier to the update module.

[0088] Update module

[0089] The update module connects to the resident module and generates monitoring update messages based on the resident area type. These messages are then written to the normal status record location, session status record location, or alarm status record location on the remote server. The normal status record location on the remote server receives monitoring update messages corresponding to normal status types, the session status record location receives monitoring update messages corresponding to session persistence types, and the alarm status record location receives monitoring update messages corresponding to alarm status types. The monitoring update message is an update object sent or written by the edge gateway to the remote server, carrying update index fields, timing verification fields, status payload fields, and target record location fields. The update module does not re-determine alarms or link states; its writing is based on the resident area type output from the resident module and the session status record page generated by the determination module.

[0090] like Figure 4 As shown, the update module may further include a type mapping submodule, a message construction submodule, and a location writing submodule during implementation.

[0091] The type mapping submodule is configured to obtain the dwell area type and device identification information, match the dwell area type with the record location mapping table, determine the target record location among the normal state record location, session state record location, or alarm state record location, and output the location matching result. The record location mapping table is a pre-registered write location configuration object between the edge gateway and the remote server, carrying the correspondence between dwell area types and remote server record locations, and is updated through the remote server's configuration distribution interface or the edge gateway's operation and maintenance configuration interface. The location matching result includes device identification information, dwell area type, target record location, and mapping source fields. When the dwell area type fails to match the target record location in the record location mapping table, the type mapping submodule generates a location matching failure flag and designates the target record location as the pending verification entry point corresponding to the session state record location, ensuring that the message can still be received and traced by the remote server in a pending verification state.

[0092] The message construction submodule is configured to generate monitoring update messages based on location matching results, session status record pages, and device data packets. When generating monitoring update messages, the message construction submodule obtains the device identification information, message sequence number, and acquisition time from the device data packets, and obtains the page main status, link status item, and alarm identifier from the session status record page. The device identification information serves as an update index field, used by the remote server to locate terminal records. The message sequence number and acquisition time serve as timing verification fields, used by the remote server to confirm the correspondence between the update message and the terminal acquisition order. The page main status, link status item, and alarm identifier serve as status payload fields, used by the remote server to distinguish the record content in normal, session, and alarm states. The target record location in the location matching results serves as a write pointer field, establishing an update field association relationship with the update index field, timing verification field, and status payload field. The updated field associations are field combination rules generated internally by the message construction submodule, which define the source, meaning, and writing location of each field. While this embodiment does not include specific numerical examples or rely on formulaic processing, those skilled in the art can certainly write programs to implement this based on the aforementioned field sources and corresponding writing locations. When a device data message lacks device identification information, message sequence number, or acquisition time, the message construction submodule does not generate a normal status monitoring update message. Instead, it generates an incomplete field update message and writes the status payload field to the session persistence state, enabling the remote server to receive the source of the anomaly at the session state record location.

[0093] The location writing submodule is configured to write monitoring update messages to the target record location, generating a remote write record. The remote write record is a write trace object stored by the edge gateway, carrying device identification information, target record location, residency type, write status, and the reception acknowledgment status returned by the remote server. Before writing, the location writing submodule reads the remote server's connection status and access permission status. The connection status comes from the edge gateway's communication interface, and the access permission status comes from the server's authorization configuration. When the connection status meets the write conditions and the access permission status is valid, the location writing submodule writes the monitoring update message to the target record location and writes the reception acknowledgment status returned by the remote server to the remote write record. When the connection status does not meet the write conditions, the access permission fails, or the remote server returns an exception, the location writing submodule generates a remote write pending acknowledgment flag, saves the monitoring update message in the edge gateway's pending send queue, and maintains its residency type and target record location unchanged. When the pending send queue triggers writing again, the location writing submodule reads the remote write pending acknowledgment flag and continues writing according to the original target record location, preventing the same message from being written to different record locations due to retries.

[0094] To further illustrate the working process of each module of the present invention, the following describes some possible data flow processes during the operation of the entire system.

[0095] like Figure 5 As shown, during system operation, the edge session baseline table output by the baseline module is first used as the baseline reading object of the parsing module, and then as the reference source for the decision module to generate link status items.

[0096] After the parsed field records and baseline association records output by the parsing module enter the judgment module, the judgment module will uniformly write the message sequence number, acquisition time, received signal strength, message retransmission count, running status value and alarm flag into the session status record page.

[0097] The residency module reads the session status record page and writes the device data packets into the target residency area. The update module constructs a monitoring update packet based on the residency area type and the session status record page, and writes it to the corresponding record location on the remote server.

[0098] The handshake reception record, parsed field record, session state record page, resident write record, and remote write record generated locally by the edge gateway all carry device identification information, forming a continuous traceability link from network access benchmark, packet parsing, status determination, resident cache to remote update.

[0099] When a terminal performs a cold start or re-enters the network, the baseline module first generates a new edge session baseline table based on the handshake confirmation message received by the network access monitoring interface.

[0100] When the edge session baseline table has not yet been written, the parsing module generates a baseline missing status for the arrived device data packets, the determination module forms a session status record page for session persistence status based on this, and the resident module writes the corresponding packets into the session persistence resident area.

[0101] After the edge session baseline table is generated, subsequent device data packets enter the parsing and judgment link according to the new baseline. When a device communication address is updated, the baseline module writes an address update association record into the edge session baseline table, and the parsing module reads the baseline association record based on the device identification information and the current device communication address, thus preventing the old address baseline from directly affecting the new address packets.

[0102] When a device data packet arrives repeatedly, the record matching submodule identifies the source of the duplication based on the packet sequence number, device communication address, and communication chip reception record. The field extraction submodule retains the parsed field records that have passed the verification. The determination module writes the duplication status into the sequence status item, and the resident module writes it into the session persistence resident area according to the session persistence rules.

[0103] When a device data packet payload field is corrupted, the field length boundaries are inconsistent, or the validation field fails, the parsing module generates a parsing failure flag. The determination module generates a session state record page for session persistence based on this flag. The resident module retains the original device data packet and the source of the error. The update module writes the incomplete field update packet to the session state record location on the remote server.

[0104] When a remote server write fails, the update module retains the monitoring update message, the target record location, and the remote write confirmation flag. The edge gateway continues to retain the corresponding data in the resident area until the remote write record reaches the received confirmation status.

[0105] In summary, through the aforementioned module connections and data flow, the baseline module establishes a device-level session reference during the network access phase, the parsing module maps device data packets and communication chip received records to the same parsing field, the determination module aggregates timing status, link status, operating status, and alarm identifiers into a session status record page, the dwell module writes packets to the corresponding dwell area based on the session status record page, and the update module writes monitoring update packets to the corresponding record location on the remote server according to the dwell area type. In this way, packets first undergo local baseline verification and session status classification at the edge gateway before entering the remote record location. The data received by the remote server simultaneously carries the terminal identity, timing verification field, and status payload field, forming a correspondence between remote monitoring records and edge session determination. This significantly reduces the number of server-parsed verification packets, improves the orderliness of status data, accelerates alarm response, and solves the problems of difficult alarm status tracking and increased bandwidth and computing resource consumption.

[0106] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A remote monitoring system for IoT devices based on edge computing, used at the edge, characterized in that... Includes the following modules: The baseline module is used to receive multiple handshake confirmation messages during the IoT terminal network access phase, record device identification information, device communication address, message arrival interval set, received signal strength and message retransmission count, and generate an edge session baseline table. The parsing module, connected to the benchmark module, is used to receive device data packets and communication chip reception records, parse the packet sequence number, acquisition time, operating status value, environmental parameter value and alarm identifier, and read the edge session benchmark table. The edge preprocessing module, connected to the parsing module, is used to perform Kalman filtering, message reordering and retransmission deduplication on the parsed field records, and output the cleaned parsed field records. The determination module, connected to the edge preprocessing module, is used to generate a session status record page based on the message sequence number, acquisition time, received signal strength, message retransmission count, running status value and alarm identifier. The AI ​​reasoning module is connected to the judgment module to complete intelligent anomaly detection and classification reasoning of data packets, and outputs an AI-enhanced status record page to provide accurate classification basis for the three-level dwell partition of the subsequent dwell module. The dwell module, connected to the AI ​​inference module, is used to write device data packets into the normal state dwell area, session keep-alive dwell area, or alarm state dwell area according to the AI ​​enhanced status record page, and output the dwell area type. The update module, connected to the resident module, is used to generate a monitoring update message according to the resident area type, and write the monitoring update message to the normal status record location, session status record location, or alarm status record location of the remote server.

2. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that... The reference module includes: The receiving confirmation submodule is configured to receive multiple handshake confirmation messages corresponding to the same device identification information from the network access monitoring interface of the edge gateway, match the device communication address written in the communication chip with the address field in the message header, and output the handshake reception record when the match is successful. The interval statistics submodule is configured to calculate the arrival time difference of adjacent messages according to the receiving time order in the handshake receiving record, and obtain the message arrival interval set after removing the retransmitted messages corresponding to the duplicate handshake sequence number. It is configured to associate the device identification information, the device communication address, the message arrival interval set, the received signal strength range, and the message retransmission count into an edge storage table to generate an edge session baseline table.

3. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that... The parsing module includes: The record matching submodule is configured to acquire device data packets and communication chip reception records, and match the device data packets with the communication chip reception records according to the device communication address, physical layer reception timestamp and packet length to generate packet reception matching records. The field extraction submodule is configured to read the header field, payload field and check field from the device data packet corresponding to the message receiving matching record, parse the message sequence number, collection time, running status value, environmental parameter value and alarm identifier, and generate a parsed field record. The benchmark reading submodule is configured to read the edge session benchmark table based on the device identification information and device communication address in the parsed field records, and output the benchmark association record.

4. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that, The edge preprocessing module includes: The Kalman filter submodule is configured to perform Kalman filtering on the operating status values ​​and environmental parameter values ​​to estimate the true system state and filter out measurement noise, thereby obtaining the cleaned operating status values ​​and environmental parameter values. The out-of-order reassembly submodule is configured to maintain a queue of expected message sequence numbers, temporarily store out-of-order messages in an out-of-order buffer, and reassemble them in order after missing sequence number messages arrive. If the timeout threshold is exceeded, the messages are released in the order of reception time and marked as having a timing error. The retransmission deduplication submodule is configured to identify retransmitted messages based on message sequence number and check field, retain only the first received message, and discard the retransmitted copy directly or use it for signal quality assessment.

5. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that, The determination module includes: The sequence comparison submodule is configured to obtain the message sequence number and the collection time, and jointly compare the increasing state of the message sequence number relative to the most recently parsed message sequence number with the sequential state of the collection time relative to the most recently parsed collection time to generate a sequence status item. The link deviation submodule is configured to acquire the received signal strength, the number of message retransmissions, and the reference received signal strength and the number of reference message retransmissions in the edge session reference table, determine the signal strength deviation status and retransmission deviation status, and generate link status entries. The record page generation submodule is configured to write the sequence status item, the link status item, the running status value, and the alarm identifier into a temporary record page corresponding to the same device identification information, thereby generating a session status record page.

6. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that, The AI ​​inference module includes: The anomaly screening pool module is configured to use a Gaussian mixture model to perform initial binary separation on the input session state record page, distinguish between normal data and abnormal data, and output normal data pool and abnormal data pool. The anomaly classification pool module is configured to use local anomaly coefficients for open set identification, distinguishing between known anomalies and novel unknown anomalies. It uses random forest for binary classification to distinguish between communication layer anomalies and runtime anomalies, and finally outputs a normal pool, a communication anomaly pool, a runtime anomaly pool, and an unknown anomaly pool.

7. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that, The resident module includes: The record page reading submodule is configured to obtain the main page status, link status items, timing status items and alarm identifiers in the AI-enhanced status record page, establish a page message association relationship between the main page status and the device identifier information of the device data message, and output the dwell determination record. The dwell allocation submodule is configured to determine the target dwell area among the normal state dwell area, session persistence dwell area and alarm state dwell area based on the main page state in the dwell determination record, and write device data packets into the target dwell area to generate a dwell write record. The type output submodule is configured to read the target residency area identifier from the residency write record, convert the target residency area identifier into a residency area type, and output the residency area type.

8. The remote monitoring system for IoT devices based on edge computing according to claim 1, characterized in that, The update module includes: The type mapping submodule is configured to obtain the dwell area type and device identification information, match the dwell area type with the record location mapping table, determine the target record location among the normal state record location, session state record location, or alarm state record location, and output the location matching result. The message construction submodule is configured to generate monitoring update messages based on the location matching results, session status record pages, and device data messages. The location writing submodule is configured to write the monitoring update message to the target record location, thereby generating a remote write record.

9. The remote monitoring system for IoT devices based on edge computing according to claim 3, characterized in that, The parsing of message sequence number, acquisition time, running status value, environmental parameter value, and alarm identifier, and the generation of parsing field records are specifically as follows: The acquisition time field, running status field, environmental parameter field and alarm field in the payload field are obtained. The payload field is truncated sequentially according to the preset field length boundary. The truncated result is associated with the message sequence number in the message header field to obtain the field segmentation record. When the acquisition time field in the field segment record is earlier than the edge gateway reception time and does not exceed the acquisition delay threshold, the running status field is converted into a running status value, the environmental parameter field is converted into an environmental parameter value, and the alarm field is converted into an alarm identifier, thereby generating the parsed field record.

10. The remote monitoring system for IoT devices based on edge computing according to claim 5, characterized in that, The determination of signal strength deviation state and retransmission deviation state specifically refers to: The strength difference between the received signal strength and the reference received signal strength is obtained, the strength difference is compared with the strength deviation threshold, and a signal attenuation mark is determined when the strength difference exceeds the strength deviation threshold. The difference between the number of retransmissions of the message and the number of retransmissions of the baseline message is obtained. The difference is compared with the retransmission deviation threshold. When the difference exceeds the retransmission deviation threshold, a retransmission anomaly is identified. When the signal attenuation flag or the retransmission anomaly flag is true, the link status item is determined to be in an unstable session state; when neither the signal attenuation flag nor the retransmission anomaly flag is true, the link status item is determined to be in a stable session state.

11. The remote monitoring system for IoT devices based on edge computing according to claim 7, characterized in that, The specific steps for determining the target dwell area among the normal state dwell area, the session hold dwell area, and the alarm state dwell area are as follows: Obtain the main page state, the link state item, and the alarm identifier; compare the alarm identifier with the alarm trigger value; and determine the target dwell area as the alarm state dwell area when the comparison is successful. When the alarm flag does not hit the alarm trigger value and the link status item is in an unstable session state, the target dwell area is determined as a session-keeping dwell area. When the alarm flag does not hit the alarm trigger value and the link status item is in a stable session state, the target dwell area is determined as a normal state dwell area, and the dwell write record is generated.

12. The remote monitoring system for IoT devices based on edge computing according to claim 8, characterized in that, The specific steps for generating a monitoring update message based on the location matching result, session status record page, and device data message are as follows: Obtain the device identification information, message sequence number and collection time from the device data message, and obtain the page main status, link status item and alarm identifier from the session status record page. Use the device identification information as the update index field, the message sequence number and collection time as the timing verification field, and the page main status, link status item and alarm identifier as the status payload field to establish the update field association relationship. The monitoring update message is generated based on the relationship between the updated fields and the location matching result.

Images