Terminal layer equipment communication management and control method, system, equipment and medium
By building a dynamic registration and authentication mechanism between terminal devices and device gateways, each device is ensured to have a unique identity and continuously updated security credentials. The device gateway service processes and converts data from multiple heterogeneous devices, solving the reliability and security issues in direct communication between terminal devices and the cloud, and realizing secure and efficient data collection and communication management across the entire chain.
Patent Information
- Application Number
- CN202511433520.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-09
- Publication Date
- 2026-01-02
AI Technical Summary
In existing technologies, direct communication between terminal devices and cloud platforms suffers from problems such as low data transmission reliability, high protocol adaptation pressure, high security risks, and low processing efficiency, making it difficult to meet the intelligent monitoring requirements of power grid operations.
By building a dynamic registration and authentication mechanism between devices and device gateways, each device is ensured to have a unique identity and continuously updated security credentials. The device gateway service performs protocol parsing, identity verification, data cleaning and protocol conversion on multi-source heterogeneous device data, and achieves secure isolation transmission with the cloud through a dedicated network.
It improves the reliability and efficiency of data transmission, reduces the processing pressure on the cloud, and achieves secure and efficient data acquisition and communication management across the entire chain.
Smart Images

Figure CN121261902A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication control technology for terminal layer devices, and in particular to a method, system, device, and medium for communication control of terminal layer devices. Background Technology
[0002] With the rapid development of IoT and smart grid technologies, a large number of sensor and visualization devices are deployed at power grid operation sites to collect environmental data and operational status in real time. To achieve efficient management and centralized monitoring of field equipment, most existing mainstream solutions adopt a model where terminal devices directly establish a communication connection with a cloud platform, transmitting the collected data to the cloud for processing via a public network. This direct-connection architecture is conceptually simple and straightforward, aiming to meet basic remote data acquisition needs.
[0003] However, direct-connection communication has significant drawbacks in practice. First, terminal devices are directly exposed to complex field network environments, making their communication links susceptible to interference. This results in low data transmission reliability, frequent interruptions, and an inability to meet the high real-time monitoring requirements of power grid operations. Second, the wide variety of terminal devices, their diverse communication protocols, and inconsistent data formats place a heavy burden on the cloud platform for protocol adaptation and data cleaning, leading to low processing efficiency. Third, the weak security mechanisms of terminal devices themselves pose security risks such as insufficient authentication strength and vulnerability to theft or tampering during data transmission when communicating directly with the cloud. These deficiencies in communication reliability, data processing efficiency, and system security severely restrict the improvement of intelligent operation and maintenance levels at power grid operation sites. Summary of the Invention
[0004] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a terminal layer device communication management and control method, including a terminal device initiating a registration request to a device gateway service, and after the device gateway service verifies the registration, assigning a unique device identifier to the terminal device and generating dynamic authentication information to complete identity authentication binding; The data collected by the registered terminal devices is sent to the device gateway service via the Internet of Things protocol; The device gateway service processes the received data to form standardized data packets, and then sends these standardized data packets to the cloud platform through a dedicated network channel. The cloud platform stores and analyzes the received standardized data packets.
[0005] In a preferred embodiment of the terminal layer device communication management method of the present invention, the terminal device initiates a registration request to the device gateway service, including: The terminal device sends a registration request containing the device hardware identifier and pre-set authentication information to the device gateway service; After the device gateway service verifies the pre-set authentication information, it generates a globally unique device identifier and dynamic authentication information for communication. The device gateway service sends device identifiers and dynamic authentication information to terminal devices and stores them in the backend database.
[0006] In a preferred embodiment of the terminal layer device communication management method of the present invention, the device gateway service processes the received data to form standardized data packets, including: Analyze the data to extract device identification and payload; Verify the identity and permissions of the terminal device sending data based on device identification and dynamic authentication information; The payload is verified and cleaned to filter out invalid data; The verified data is converted from the IoT protocol to an internal communication protocol supported by the cloud platform. The transformed data is standardized and enriched according to a predefined model to generate standardized data packets in a unified format.
[0007] As a preferred embodiment of the terminal layer device communication management method of the present invention, the cloud platform stores and analyzes the received standardized data packets, including: Standardized data packets are written in parallel to a real-time database and a batch data storage system; Real-time stream processing and analysis are performed on the data written to the real-time database. Real-time stream processing and analysis include window aggregation and anomaly detection. Batch calculations and mining are performed on the data written to the batch processing data storage system. Batch calculations and mining include trend analysis and model training.
[0008] As a preferred embodiment of the terminal layer device communication control method of the present invention, the dynamic authentication information includes an encryption key pair generated by an asymmetric encryption algorithm and an authentication token with a time limit. The encryption key pair is used for data encryption and digital signatures, while the authentication token is used to verify the device's identity during communication.
[0009] As a preferred embodiment of the terminal layer device communication control method of the present invention, the dedicated network channel is an APN dedicated network channel, which is used to directly transmit data to the virtual private network of the cloud platform and is isolated from the public Internet.
[0010] As a preferred embodiment of the terminal layer device communication management method of the present invention, the terminal device includes a sensor device and a visualization device; Internet of Things (IoT) protocols include MQTT or CoAP.
[0011] In a second aspect, the present invention provides a terminal layer device communication management and control system, comprising: a registration and binding module, used for a terminal device to initiate a registration request to a device gateway service, and after the device gateway service verifies the registration, assigning a unique device identifier to the terminal device and generating dynamic authentication information to complete identity authentication and binding; The data acquisition and transmission module is used to send the data collected by the registered terminal devices to the device gateway service via the Internet of Things protocol. The processing and sending module is used by the device gateway service to process the received data to form standardized data packets, and then send the standardized data packets to the cloud platform through a dedicated network channel; The storage and analysis module is used by the cloud platform to store and analyze the received standardized data packets.
[0012] Thirdly, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.
[0013] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described above.
[0014] Compared with existing technologies, the beneficial effects of this invention are as follows: By constructing a dynamic registration and authentication mechanism between terminal devices and device gateways, it ensures that each device has a unique identity and continuously updated security credentials, thereby establishing a reliable security foundation at the source of communication; the device gateway further performs protocol parsing, identity verification, data cleaning, protocol conversion, and standardized encapsulation on multi-source heterogeneous device data, effectively improving data quality and system compatibility, and achieving secure isolation transmission with the cloud through the APN dedicated network; the cloud platform adopts a real-time and batch dual-path parallel processing architecture, which supports real-time stream processing to achieve instant monitoring and anomaly alarms, and relies on batch computing to complete trend mining and model training, ultimately forming a secure, efficient, and scalable communication management and control system across the entire link from terminal access and data processing to intelligent analysis. Attached Figure Description
[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a flowchart illustrating the communication control method for terminal layer devices. Detailed Implementation
[0017] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.
[0018] Example 1, referring to Figure 1 This is the first embodiment of the present invention, which provides a terminal layer device communication management and control method, including: S100: The terminal device initiates a registration request to the device gateway service. After the device gateway service verifies the registration, it assigns a unique device identifier to the terminal device and generates dynamic authentication information to complete the identity authentication binding. S200: The data collected by the registered terminal devices is sent to the device gateway service via the Internet of Things protocol; S300: The device gateway service processes the received data to form standardized data packets, and sends the standardized data packets to the cloud platform through a dedicated network channel; S400: The cloud platform stores and analyzes the received standardized data packets.
[0019] It should be noted that in industrial IoT application scenarios such as power grid operation sites, a large number of heterogeneous terminal devices, such as various sensors and visualization devices, are typically deployed. These devices often use different communication protocols and data formats and connect directly to remote cloud platforms. Due to the complex network environment and large bandwidth fluctuations on-site, the communication link between the devices and the cloud is unstable, which can easily lead to data interruption or loss. At the same time, the terminal devices have limited resources and weak security mechanisms, and being directly exposed to open networks also brings security risks such as identity spoofing, data theft, and tampering. In addition, the cloud needs to directly adapt to multiple device protocols, resulting in high data processing pressure and low overall system scalability and operation and maintenance efficiency.
[0020] Therefore, to address the aforementioned issues regarding communication reliability, security, and processing efficiency, a device gateway service is constructed at the terminal layer as a unified communication and security management hub through steps S100 to S400. S100 implements mandatory device registration and dynamic authentication to ensure the legitimacy of access devices and communication security. Through S200 and S300, the device gateway service uniformly receives, converts protocols, and standardizes the encapsulation of data from multiple heterogeneous devices, masking device differences and improving data transmission quality and efficiency. A dedicated network channel ensures the reliability and isolation of the uplink. Finally, in S400, the standardized data is centrally stored and deeply analyzed in the cloud. Through this collaboration, secure, reliable, and efficient data acquisition and communication management are achieved across the entire link from the terminal to the cloud.
[0021] Example 2, refer to Figure 1 As an embodiment of the present invention, based on the above embodiment, a method for online health monitoring of high-temperature pipelines is provided.
[0022] In this embodiment of the application, in step S100, the terminal device initiates a registration request to the device gateway service. After the device gateway service verifies the registration, it assigns a unique device identifier to the terminal device and generates dynamic authentication information to complete the identity authentication binding. This includes the following steps A1-A2: It is understandable that terminal devices include sensor devices and visualization devices.
[0023] A1: The terminal device sends a registration request containing the device hardware identifier and pre-set authentication information to the device gateway service; To put it simply, device hardware identifiers include the MAC address, IMEI, and SN serial number. These are the device's identification numbers, globally unique, used to uniquely identify the physical device within the system. Pre-installed authentication information includes a pre-shared key (PSK) or digital certificate, which is the device's "factory password," burned into it during production. Its function is to complete an initial, one-time authentication, proving to the system that it is a legitimate device.
[0024] It should be noted that before the terminal device initiates a registration request to the device gateway service, a secure connection (channel) must first be established between the terminal device and the device gateway service.
[0025] A2: After the device gateway service verifies the pre-set authentication information, it generates a globally unique device identifier and dynamic authentication information for communication. It should be noted that dynamic authentication information includes an encryption key pair generated by an asymmetric encryption algorithm (such as RSA2048 / 3072 or ECCsecp256r1) and an authentication token with an expiration date; the encryption key pair is used for data encryption and digital signature, and the authentication token is used to verify the device identity during communication.
[0026] Understandably, upon receiving a request, the device gateway service does not immediately trust it. Instead, it performs device authentication, comparing the hardware identifier and PSK in the request with a pre-defined whitelist stored locally or retrieved from a backend database. If the authentication is successful, the system assigns a logically unique identifier to the physical device within its own business system. Furthermore, it generates a new set of dynamic authentication information bound to the device ID, replacing the initial pre-defined credentials.
[0027] Even better, the generated dynamic authentication information resolves the inherent security risks of pre-installed PSKs (such as the impact on all similar devices if leaked). By using short-term, device-specific credentials, the principle of least privilege and credential rotation are implemented, significantly improving the overall security of the system.
[0028] In an optional implementation, the globally unique device identifier generated in step A2 can also be generated based on UUID. That is, when the terminal device first accesses the system and sends a registration request, after the device gateway service receives and verifies the validity of the request, it triggers the UUID generation operation. Using the UUID generation function, a 128-bit UUID value is generated according to the UUID version standard (such as UUIDv4 which is generated based on random numbers). This value is then converted into a string to represent the device identifier. Finally, the generated UUID is stored in the backend database along with other registration information of the device (such as hardware identifier, device model, etc.) and a mapping relationship is established so that the device can be uniquely identified and managed in the system through the UUID in the future.
[0029] In another optional implementation, the globally unique device identifier generated in step A2 can also be generated based on the Snowflake algorithm. That is, after the terminal device is verified, the Snowflake algorithm service is triggered to generate a device ID. The Snowflake algorithm service then calculates a 64-bit device ID according to the rules of the Snowflake algorithm, based on the current timestamp (accurate to milliseconds), the preset data center ID and worker machine ID, and the serial number within the same millisecond. This ID is globally unique and can be generated in chronological order, facilitating sorting and management in subsequent data processing and queries. Finally, the generated device ID is stored in the backend database along with other registration information of the device (such as hardware identifiers, device model, etc.), and a mapping relationship is established. In this way, the system can quickly and accurately find and manage the corresponding device through the device ID, while also ensuring that the unique identifiers of various devices do not conflict in a distributed environment.
[0030] A3: The device gateway service sends device identification and dynamic authentication information to the terminal device and stores it in the backend database.
[0031] Understandably, the device gateway service persistently stores complete registration information (hardware identifier, device ID, public key portion of dynamic authentication information, token metadata, device model, etc.) in the backend database, essentially creating a "digital profile" for the device within the system. This means that each subsequent communication by the device allows the system to verify its identity and status (e.g., whether it is active or disabled) by querying this profile. Furthermore, the device gateway service's distribution of the generated device ID and dynamic authentication information (such as device private key and token) to the terminal device through the previously established secure channel signifies that the device is abandoning the old pre-installed PSK in subsequent communications and adopting a new authentication method.
[0032] Preferably, this step achieves a secure transition from a static, uniform factory identity to a dynamic, unique runtime identity. Through two-way authentication, unique identifier generation, dynamic key distribution, and credential expiration mechanisms, it lays a solid foundation for the secure and reliable operation of the entire IoT system.
[0033] In this embodiment of the application, step S200 involves sending the data collected by the registered terminal device to the device gateway service via the Internet of Things protocol, including the following steps A1-A2: Understandably, IoT protocols include MQTT or CoAP protocols. The reason for using IoT protocols such as MQTT and CoAP is because they have the characteristics of low latency, high efficiency and reliability.
[0034] It should be noted that only fully registered terminal devices are capable of executing subsequent processes. Specifically, when a registered terminal device sends data, it does not only send the raw collected data (such as temperature values). In the MQTT protocol, it carries its device ID and authentication token as identity credentials in the CONNECT and PUBLISH messages.
[0035] Ideally, this step makes each communication a lightweight identity verification process, preventing device spoofing. Even if the data stream is intercepted, attackers cannot inject malicious data without valid dynamic credentials.
[0036] In this embodiment of the application, in step S300, the device gateway service processes the received data to form standardized data packets, and sends the standardized data packets to the cloud platform through a dedicated network channel, including the following steps B1-B5: Understandably, the dedicated network channel is an APN dedicated network channel, used to transmit data directly to the cloud platform's virtual private network, isolated from the public internet.
[0037] B1: Parse the data to extract device identification and payload; Understandably, the device identifier for MQTT is extracted from the ClientID, Topic, or certificate information in the message, while the payload refers to the actual collected data (such as temperature readings, device status, etc.) carried in the message body.
[0038] In one optional implementation, the data parsing in step B1 to extract the device identifier can be based on a parsing method defined by the data packet structure, i.e., establishing a data packet format specification suitable for communication of terminal equipment at the power grid operation site. For example, the first 4 bytes of the data packet are specified as the length indicator field of the device identifier, followed by N bytes as the device identifier content (N is determined by the length indicator field). The device gateway service listens on the communication port and receives data packets sent from the sensor device. After receiving the data, it is temporarily stored in the receive buffer. According to the predefined data packet format, starting from the beginning position of the data packet in the buffer, the first 4 bytes of the length indicator field are read to determine the byte length N of the device identifier. Then, starting from the next byte, N bytes are read continuously to extract the device identifier.
[0039] In another optional implementation, the data parsing in step B1 to extract the device identifier and payload can be based on a protocol conversion and adaptation parsing method. That is, the device gateway service is pre-configured with support and conversion rules for various common sensor device communication protocols (such as Modbus, DNP3, etc.), and for each protocol, it defines how to extract the mapping relationship between the device identifier and payload, as well as the method to convert the protocol data into a unified intermediate format (such as a custom XML or JSON format). The device gateway service receives data of different protocol formats sent by the sensor device through the corresponding communication interface. According to the protocol type of the received data, it calls the pre-configured conversion rules to convert the original protocol data into a unified intermediate format. In this conversion process, the corresponding content of the device identifier and payload is extracted according to the mapping relationship and organized into the specified position of the intermediate format. A unified parsing operation is performed on the converted intermediate format data. Since the intermediate format is unified, a fixed parsing logic can be used to easily extract the device identifier and payload content from the intermediate format data.
[0040] B2: Verify the identity and permissions of the terminal device sending data based on device identification and dynamic authentication information; It should be noted that the device gateway service uses the device identifier extracted by B1 to query the device's registration file in the backend database to obtain its dynamic authentication information (such as token and public key). Specifically, for MQTT: the username / password (which can be device ID and token) is verified during the CONNECT phase; for CoAP: the OSCORE security context or DTLS certificate is verified to ensure that each data report comes from a registered and legitimate device in a normal state, preventing unauthorized device access and data injection, and realizing continuous security posture assessment.
[0041] B3: Verify and clean the payload to filter out invalid data; It should be noted that after verifying the identity, the device gateway service begins to check the data quality, specifically checking the integrity of the data packets (such as checksums) and whether the format conforms to predefined specifications (such as JSONSchema). At the same time, it filters out obviously invalid data, such as values that exceed the reasonable range (such as a temperature sensor reporting 1000℃) and messages with incorrect formats.
[0042] Ideally, this step ensures the validity and quality of the upstream data, reducing the processing pressure on the cloud platform and improving the accuracy of subsequent analysis by keeping "junk data" out of the system.
[0043] In one optional implementation, filtering invalid data in step B3 can be performed using a data feature model-based filtering method. This involves analyzing the valid characteristics of data from various sensor devices at the power grid operation site to construct a data feature model, including the data's normal range, frequency characteristics, and temporal correlation. After the device gateway service receives the data, it matches and compares the data with the feature model. Data exceeding the normal feature range is determined to be invalid and filtered out.
[0044] In another optional implementation, the filtering of invalid data in step B3 can be performed using a machine learning-based filtering method. This involves training the historical data of the power grid operation site sensor equipment using machine learning algorithms (such as support vector machines, random forests, neural networks, etc.) to learn the characteristic differences between valid and invalid data, generating a data classification model. When the device gateway service receives new data, it uses this classification model to predict and classify the data, filtering out samples predicted as invalid data.
[0045] B4: Convert the verified data from the IoT protocol to an internal communication protocol supported by the cloud platform; It is understandable that the device gateway service converts the efficient IoT protocols on the device side (such as MQTT and CoAP) into internal protocols (such as HTTPREST, gRPC, and Kafka messages) that the cloud backend service is better at handling.
[0046] For example, the Topic and Payload of an MQTT message are converted and encapsulated into a JSON object, and then sent to a specific data access endpoint in the cloud via an HTTP POST request.
[0047] Ideally, the protocol conversion in this step allows the cloud to focus on a unified, standardized internal API without needing to adapt to various complex IoT protocols, thus greatly improving the system's flexibility and scalability.
[0048] In one optional implementation, the conversion of the verified data from the IoT protocol to the internal communication protocol supported by the cloud platform in step B4 can be achieved using a protocol mapping conversion table. This involves pre-establishing a mapping table between the IoT protocol and the cloud platform's internal communication protocol, clearly defining the correspondence and conversion rules for each field in different protocol formats. After the device gateway service receives the verified IoT protocol data, it uses this mapping conversion table to map and convert each field of the data one by one into the format and content specified by the internal communication protocol.
[0049] In another optional implementation, step B4, which converts the verified data from the IoT protocol to the internal communication protocol supported by the cloud platform, can adopt a protocol plugin architecture. This means that a plugin-based architecture is used in the device gateway service, with corresponding protocol plugins developed for each common IoT protocol. Each plugin is responsible for parsing and converting data from a specific IoT protocol into the format specified by the cloud platform's internal communication protocol. When the device gateway service receives the verified IoT protocol data, it calls the appropriate plugin for conversion processing based on the data's protocol type.
[0050] B5: The converted data is standardized and enriched according to a predefined model to generate a standardized data package in a unified format. The predefined model refers to a set of data specifications and structural standards agreed upon and followed by the cloud platform and device gateway service during the system design phase. Specifically, the predefined model defines the data structure (which fields the data should contain), data type (the data format of each field), data standard (the representation specification of values. For example, all temperature units are unified as "°C"), and metadata rules (what contextual information should be included in addition to the original device data, which is added by the gateway).
[0051] Understandably, standardization includes unifying all temperature data to Celsius and converting all timestamps to ISO8601 format; enrichment includes adding contextual information, such as the gateway ID of the data source, the timestamp of the gateway receiving the data, and the geographical location information of the device.
[0052] Ideally, this step creates an efficient data processing pipeline that is completed on the gateway side.
[0053] In this embodiment of the application, step S400 involves the cloud platform storing and analyzing the received standardized data packets, including the following steps C1-C3: C1: Writes standardized data packets in parallel to the real-time database and batch data storage system; Understandably, real-time databases (such as time-series databases (InfluxDB, TimescaleDB)) are optimized for high-performance, low-latency queries to support real-time monitoring and fast retrieval of recent data; batch data storage systems such as object storage (Amazon S3) or data lakes are lower-cost and suitable for storing massive amounts of complete raw data for long-term archiving, offline batch analysis, and machine learning.
[0054] Ideally, this step preserves the original data, so even if there are errors in the real-time processing logic, the results can be corrected by rerunning the batch processing task.
[0055] C2: Performs real-time stream processing and analysis on data written to the real-time database. Real-time stream processing and analysis include window aggregation and anomaly detection. Understandably, the system uses stream processing engines (such as Apache Flink and Spark Streaming) to consume the data streams that have just been connected and written to the real-time database, performing instantaneous calculations. Specifically, window aggregation can calculate the average temperature per minute and the maximum pressure per second, transforming endless stream data into bounded, meaningful time-period metrics for easy monitoring and visualization. Anomaly detection utilizes predefined rules (such as thresholds exceeding XXX) or lightweight machine learning models to determine in real time whether each data point is abnormal, triggering alarms immediately upon detection. Furthermore, the processing results (such as aggregated metrics and triggered alarm events) can be pushed to downstream systems in real time, such as alarm notification services, real-time visualization dashboards, and online business systems.
[0056] C3: Performs batch calculations and mining on data written to the batch processing data storage system. Batch calculations and mining include trend analysis and model training.
[0057] It should be noted that the system periodically (e.g., late at night each day) starts batch processing jobs, using computing engines (such as Spark and Hive) to perform in-depth and complex analyses on the massive historical data stored in the data lake. Specifically, trend analysis refers to analyzing long-term (e.g., within a year) temperature change trends to identify patterns in equipment aging; model training involves using massive amounts of historical data to train and optimize more complex machine learning models, such as predictive maintenance models (predicting when equipment might fail) or energy consumption optimization models. Further trained models can be deployed back to the real-time pipeline to improve the accuracy of anomaly detection in C2.
[0058] Ideally, this step not only enables basic equipment monitoring, but also achieves an upgrade from passive response to proactive early warning and from experience-based management to data-driven decision-making through multi-level and multi-time-sensitive data analysis.
[0059] In summary, this method establishes a reliable security foundation at the communication source by constructing a dynamic registration and authentication mechanism between terminal devices and device gateways, ensuring that each device possesses a unique identity and continuously updated security credentials. The device gateway further performs protocol parsing, identity verification, data cleaning, protocol conversion, and standardized encapsulation on data from multi-source heterogeneous devices, effectively improving data quality and system compatibility. Secure isolation transmission with the cloud is achieved through a dedicated APN network. The cloud platform adopts a dual-path parallel processing architecture, supporting real-time stream processing for immediate monitoring and anomaly alerts, while also relying on batch computing for trend mining and model training. Ultimately, this forms a secure, efficient, and scalable communication management system across the entire chain, from terminal access and data processing to intelligent analysis.
[0060] Example 3 illustrates a schematic scheme for a terminal layer device communication control method. It should be noted that the technical solution of this terminal layer device communication control system belongs to the same concept as the technical solution of the aforementioned terminal layer device communication control method. Details not described in detail in this embodiment can be found in the description of the technical solution of the aforementioned terminal layer device communication control method.
[0061] This embodiment also provides a terminal layer device communication management and control system, including: The registration and binding module is used by the terminal device to initiate a registration request to the device gateway service. After the device gateway service verifies the registration, it assigns a unique device identifier to the terminal device and generates dynamic authentication information to complete the identity authentication and binding. The data acquisition and transmission module is used to send the data collected by the registered terminal devices to the device gateway service via the Internet of Things protocol. The processing and sending module is used by the device gateway service to process the received data to form standardized data packets, and then send the standardized data packets to the cloud platform through a dedicated network channel; The storage and analysis module is used by the cloud platform to store and analyze the received standardized data packets.
[0062] This embodiment also provides an electronic device suitable for terminal layer device communication control, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the terminal layer device communication control method proposed in the above embodiment.
[0063] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements the terminal layer device communication control method proposed in the above embodiments.
[0064] The storage medium proposed in this embodiment and the terminal layer device communication management method proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.
[0065] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.
[0066] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A method for communication control of terminal layer devices, characterized in that: include, The terminal device initiates a registration request to the device gateway service. After the device gateway service verifies the registration, it assigns a unique device identifier to the terminal device and generates dynamic authentication information to complete the identity authentication binding. The data collected by the registered terminal device is sent to the device gateway service via the Internet of Things protocol. The device gateway service processes the received data to form standardized data packets, and sends the standardized data packets to the cloud platform through a dedicated network channel; The cloud platform stores and analyzes the received standardized data packets.
2. The terminal layer device communication management and control method as described in claim 1, characterized in that: The terminal device initiates a registration request to the device gateway service, including: The terminal device sends a registration request containing a device hardware identifier and pre-set authentication information to the device gateway service. After the device gateway service verifies the preset authentication information, it generates a globally unique device identifier and dynamic authentication information for communication. The device gateway service sends the device identifier and the dynamic authentication information to the terminal device and stores them in the backend database.
3. The terminal layer device communication management and control method as described in claim 2, characterized in that: The device gateway service processes the received data to form standardized data packets, including: The data is parsed to extract the device identifier and payload; Based on the device identifier and the dynamic authentication information, verify the identity and permissions of the terminal device sending the data; The payload is verified and cleaned to filter out invalid data; The verified data is converted from the IoT protocol to an internal communication protocol supported by the cloud platform. The converted data is standardized and enriched according to a predefined model to generate the standardized data packet in a unified format.
4. The terminal layer device communication management and control method as described in claim 3, characterized in that: The cloud platform stores and analyzes the received standardized data packets, including: The standardized data packets are written in parallel to the real-time database and the batch data storage system. The data written to the real-time database is subjected to real-time stream processing and analysis, including window aggregation and anomaly detection. The data written to the batch processing data storage system is subjected to batch calculation and mining, which includes trend analysis and model training.
5. The terminal layer device communication management and control method as described in claim 4, characterized in that: The dynamic authentication information includes an encryption key pair generated by an asymmetric encryption algorithm and an authentication token with a time limit; The encryption key pair is used for data encryption and digital signature, and the authentication token is used to verify the device identity during communication.
6. The terminal layer device communication management and control method as described in claim 5, characterized in that: The dedicated network channel is an APN dedicated network channel, used to directly transmit data to the virtual private network of the cloud platform, which is isolated from the public Internet.
7. The terminal layer device communication management and control method as described in claim 6, characterized in that: The terminal device includes sensor devices and visualization devices; The IoT protocol includes MQTT or CoAP.
8. A terminal layer device communication management and control system, using the method described in any one of claims 1-7, characterized in that, include: The registration and binding module is used for terminal devices to initiate registration requests to the device gateway service. After the device gateway service verifies the registration, it assigns a unique device identifier to the terminal device and generates dynamic authentication information to complete the identity authentication and binding. The data acquisition and transmission module is used to transmit the data collected by the registered terminal device to the device gateway service via the Internet of Things protocol; The processing and sending module is used by the device gateway service to process the received data to form standardized data packets, and send the standardized data packets to the cloud platform through a dedicated network channel; The storage and analysis module is used by the cloud platform to store and analyze the received standardized data packets.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.