Multi-protocol converged IoT heterogeneous device interconnection method and system

Abstract

This invention relates to the field of communication transmission technology, and discloses a method and system for interconnecting heterogeneous IoT devices using multi-protocol fusion. The method includes: normalizing the format of raw communication data from heterogeneous IoT devices to generate a standardized data stream; obtaining a temporary communication protocol stack through matching mapping based on real-time network status parameters and protocol tags; semantically abstracting the standardized data stream to form an intermediate semantic representation layer; performing real-time rule arrangement on the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack to generate a protocol conversion rule set; performing protocol conversion and encapsulation on the intermediate semantic representation layer according to the rule set to output a target protocol data packet; monitoring the data packet transmission status and target device feedback, and performing closed-loop adjustment of the matching mapping and rule arrangement parameters based on the monitoring results. This invention can improve the efficiency of interconnecting heterogeneous IoT devices using multi-protocol fusion.

Description

Technical Field

[0001] This invention relates to the field of communication transmission technology, and in particular to a method and system for interconnecting heterogeneous IoT devices using multi-protocol convergence. Background Technology

[0002] IoT heterogeneous devices encompass a variety of communication protocols. The protocol formats, data encoding, and transmission requirements of different devices vary significantly. Existing technologies mostly rely on fixed protocol adaptation schemes, failing to dynamically adjust adaptation strategies based on the real-time network status and data characteristics of the devices. This results in insufficient protocol compatibility and makes it difficult to meet the interconnection and interoperability needs of multiple types of devices in complex scenarios.

[0003] Existing technologies lack effective semantic abstraction and dynamic rule orchestration mechanisms in data processing and protocol conversion, making it impossible to achieve deep semantic alignment of data from different protocols. Furthermore, the lack of a closed-loop optimization link for transmission status and adaptation strategies results in large fluctuations in data transmission latency and a high packet loss rate. Consequently, the reliability and efficiency of data interaction between heterogeneous devices are low, making it difficult to support the large-scale deployment and efficient operation of IoT applications. Summary of the Invention

[0004] This invention provides a method and system for interconnecting heterogeneous IoT devices using multiple protocols, in order to solve the problems mentioned in the background.

[0005] To achieve the above objectives, the present invention provides a method for interconnecting heterogeneous IoT devices using a multi-protocol fusion architecture, comprising:

[0006] S1. Normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices;

[0007] S2. Based on the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream, perform matching and mapping in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices.

[0008] S3. Perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous devices;

[0009] S4. Based on the constraints of the temporary communication protocol stack, the content of the intermediate semantic representation layer is arranged in real time to obtain the protocol conversion rule set of the IoT heterogeneous device;

[0010] S5. Based on the protocol conversion rule set, perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer to obtain the data packet of the IoT heterogeneous device;

[0011] S6. Monitor the transmission status of the data packet and the feedback from the target device in real time, and adjust the execution parameters of the matching mapping process and the real-time rule orchestration process in a closed loop based on the monitoring results.

[0012] In a preferred embodiment, the step of format normalizing the raw communication data from heterogeneous IoT devices to obtain a standardized data stream from the heterogeneous IoT devices includes:

[0013] Receive raw communication data from heterogeneous IoT devices, identify and parse the protocol header of the raw communication data to obtain the protocol type and data encoding format of the heterogeneous IoT devices;

[0014] Based on the protocol type and the data encoding format, a corresponding standard format template is matched from a preset format mapping library;

[0015] Based on the standard format template, the original communication data is converted to obtain the unified intermediate data of the IoT heterogeneous devices;

[0016] The standardized intermediate data of the unified format is verified and recombined to obtain the standardized data stream of the heterogeneous IoT devices.

[0017] In a preferred embodiment, the step of matching and mapping based on the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream in a pre-set protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices includes:

[0018] The real-time network status parameters of the IoT heterogeneous devices are extracted to obtain the current network quality level and available bandwidth range of the IoT heterogeneous devices;

[0019] The standardized data stream is subjected to protocol identification to obtain the protocol tags of the heterogeneous IoT devices;

[0020] The current network quality level, the available bandwidth range, and the protocol label are used as composite query conditions to perform a joint query in a preset protocol stack mapping table to obtain the candidate protocol stack description of the IoT heterogeneous device.

[0021] Based on a preset protocol stack selection strategy, the candidate protocol stack descriptions are filtered to obtain the target protocol stack description of the IoT heterogeneous device.

[0022] The protocol layer structure and parameter configuration in the target protocol stack description are instantiated and transformed to obtain the temporary communication protocol stack of the IoT heterogeneous device.

[0023] In a preferred embodiment, the step of using the current network quality level, the available bandwidth range, and the protocol tag as composite query conditions to perform a joint query in a preset protocol stack mapping table to obtain candidate protocol stack descriptions for the IoT heterogeneous devices includes:

[0024] Based on the protocol tags, tag matching is performed in a preset protocol stack mapping table to obtain the basic protocol stack description set of the IoT heterogeneous device;

[0025] Based on the current network quality level, the basic protocol stack description set is filtered for network quality to obtain the quality adaptation subset of the IoT heterogeneous devices;

[0026] Based on the available bandwidth range, bandwidth adaptation selection is performed on the quality adaptation subset to obtain candidate protocol stack descriptions for the heterogeneous IoT devices.

[0027] In a preferred embodiment, the step of semantically abstracting the standardized data stream to obtain the intermediate semantic representation layer for the heterogeneous IoT devices includes:

[0028] Effective data separation is performed on the payload portion of the standardized data stream to obtain the original semantic element set of the heterogeneous IoT devices;

[0029] The header information of the standardized data stream is read to obtain the device type identifier and data generation timestamp of the heterogeneous IoT device;

[0030] Based on the device semantic definition rules corresponding to the device type identifier, the original semantic element set is semantically reconstructed to obtain a normalized semantic element set;

[0031] The standardized semantic element set, the device type identifier, and the data generation timestamp are associated and encapsulated to obtain the intermediate semantic representation layer of the heterogeneous IoT device.

[0032] In a preferred embodiment, the step of real-time rule orchestration of the content of the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack to obtain the protocol conversion rule set for the IoT heterogeneous device includes:

[0033] Extracting elements from the temporary communication protocol stack yields a list of protocol constraint elements for the heterogeneous IoT devices.

[0034] Based on the protocol constraint element list, field matching is performed on the content of the intermediate semantic representation layer to obtain the correspondence between the semantic fields and protocol fields of the IoT heterogeneous devices;

[0035] Based on the aforementioned correspondence, a logical mapping is constructed on the pre-set conversion operation library to obtain the field conversion operation sequence of the IoT heterogeneous device;

[0036] Based on the transmission requirements in the protocol constraint element list, the sequence constraints of the field conversion operation sequence are applied to obtain the protocol conversion rule set of the IoT heterogeneous device.

[0037] In a preferred embodiment, the step of applying sequence constraints to the field conversion operation sequence based on the transmission requirements in the protocol constraint element list to obtain the protocol conversion rule set for the IoT heterogeneous device includes:

[0038] Feature extraction is performed on the transmission requirements in the protocol constraint element list to obtain the timing attributes and reliability indicators of the IoT heterogeneous devices;

[0039] Based on the time sequence attribute, the field transformation operation sequence is rearranged in time sequence to obtain the time sequenced operation sequence of the IoT heterogeneous device;

[0040] Based on the reliability index, reliability logic is injected into the time-series operation sequence to obtain the controlled operation sequence of the IoT heterogeneous device.

[0041] The controlled operation sequence is encapsulated into a policy to obtain the protocol conversion rule set for the heterogeneous IoT devices.

[0042] In a preferred embodiment, the step of performing protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set to obtain the data packet of the IoT heterogeneous device includes:

[0043] The protocol conversion rule set is parsed to obtain the field mapping relationship of the IoT heterogeneous devices and the target protocol header format;

[0044] Based on the field mapping relationship, the data in the intermediate semantic representation layer is transformed to obtain the transformed data fields of the IoT heterogeneous device;

[0045] Based on the target protocol header format, a header is added to the converted data fields to obtain the preliminary data packet of the IoT heterogeneous device;

[0046] The integrity of the initial data packet is verified to obtain the data packet of the heterogeneous IoT device.

[0047] In a preferred embodiment, the step of real-time monitoring of the data packet transmission status and the feedback from the target device, and closed-loop adjustment of the execution parameters of the matching mapping process and the real-time rule orchestration process based on the monitoring results, includes:

[0048] The transmission status of the data packets is continuously monitored to obtain the average transmission latency and data packet loss rate of the heterogeneous IoT devices;

[0049] The feedback from the target device is dynamically processed to obtain the link quality score of the heterogeneous IoT devices;

[0050] The average transmission delay, the packet loss rate, and the link quality score are weighted and synthesized to obtain the system adaptive adjustment factor for the heterogeneous IoT devices. The calculation formula for the system adaptive adjustment factor is as follows:

[0051] ;

[0052] In the formula, This is the adaptive adjustment factor for the system. For the pre-configured system baseline coefficients, The preset target transmission delay, The average transmission delay is... The packet loss rate is... Score the link quality;

[0053] Based on the system adaptive adjustment factor, the network quality level weight benchmark value used in the protocol stack mapping table during the matching mapping process is adaptively updated.

[0054] Based on the system's adaptive adjustment factor, the sensitivity threshold used to trigger rule recombination during the real-time rule orchestration process is dynamically adjusted.

[0055] To address the aforementioned problems, this invention also provides a multi-protocol converged IoT heterogeneous device interconnection system, the system comprising:

[0056] The data preprocessing module is used to normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices.

[0057] The protocol dynamic adaptation module is used to match and map the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices.

[0058] The semantic abstraction module is used to perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous devices;

[0059] The dynamic rule generation module is used to perform real-time rule arrangement on the content of the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack, so as to obtain the protocol conversion rule set of the IoT heterogeneous device;

[0060] The protocol conversion execution module is used to perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set, so as to obtain the data packets of the IoT heterogeneous device;

[0061] The closed-loop optimization control module is used to monitor the transmission status of the data packet and the feedback from the target device in real time, and to adjust the execution parameters of the matching mapping process and the real-time rule orchestration process in a closed loop based on the monitoring results.

[0062] Compared with the prior art, the present invention has the following beneficial effects:

[0063] 1. This invention normalizes the format of raw communication data from heterogeneous IoT devices, and combines this with a standard template matching protocol type and data encoding format to achieve unified data format standardization. Simultaneously, it constructs an intermediate semantic representation layer through semantic abstraction, accurately extracting and associating device semantic elements and key identification information, significantly improving the consistency and interpretability of data semantics and laying a solid foundation for subsequent protocol conversion. Based on a dynamic matching mechanism of real-time network status parameters and protocol tags, it can accurately select suitable temporary communication protocol stacks, significantly enhancing the targeting and flexibility of protocol adaptation and ensuring smooth data interaction among various types of heterogeneous devices.

[0064] 2. This invention generates a highly adaptable protocol conversion rule set through real-time rule orchestration under the constraints of a temporary communication protocol stack. Combined with an integrity verification mechanism, it ensures the accuracy and reliability of protocol conversion and data encapsulation. Relying on transmission status monitoring and closed-loop optimization adjustment mechanisms, it dynamically updates key execution parameters through system adaptive adjustment factors, effectively reducing data transmission latency and packet loss rate, continuously optimizing interconnection performance, and significantly improving the stability and efficiency of data interaction between heterogeneous devices. This provides strong support for the large-scale deployment and efficient operation of IoT applications. Attached Figure Description

[0065] Figure 1 This is a flowchart illustrating a method for interconnecting heterogeneous IoT devices using a multi-protocol fusion approach, as provided in an embodiment of the present invention.

[0066] Figure 2 This is a functional block diagram of a multi-protocol converged IoT heterogeneous device interconnection system provided in an embodiment of the present invention;

[0067] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0068] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0069] This application provides a method for interconnecting heterogeneous IoT devices using a multi-protocol convergence approach. The executing entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the method can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0070] Reference Figure 1 The diagram shown is a flowchart illustrating a method for interconnecting heterogeneous IoT devices using a multi-protocol converged approach, according to an embodiment of the present invention. In this embodiment, the method includes:

[0071] S1. Normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices;

[0072] In this embodiment of the invention, the step of format normalizing the raw communication data from heterogeneous IoT devices to obtain a standardized data stream from the heterogeneous IoT devices includes:

[0073] Receive raw communication data from heterogeneous IoT devices, identify and parse the protocol header of the raw communication data to obtain the protocol type and data encoding format of the heterogeneous IoT devices;

[0074] Based on the protocol type and the data encoding format, a corresponding standard format template is matched from a preset format mapping library;

[0075] Based on the standard format template, the original communication data is converted to obtain the unified intermediate data of the IoT heterogeneous devices;

[0076] The standardized intermediate data of the unified format is verified and recombined to obtain the standardized data stream of the heterogeneous IoT devices.

[0077] The system listens to a designated data receiving port through the IoT communication link and continuously receives raw communication data sent by heterogeneous IoT devices. During the reception process, it records the data transmission start time and the total data length. Then, according to the general field structure definition of the protocol header, it reads the header area of ​​the raw communication data byte by byte. By identifying the fixed byte segment in the header used to identify the protocol type, it determines the specific protocol type by referring to a preset protocol type encoding lookup table. Then, it reads the encoding format identifier byte at a specified position in the header and determines the data encoding format by referring to the data encoding format mapping table. Finally, it obtains the protocol type and data encoding format of the heterogeneous IoT devices.

[0078] The pre-built format mapping library stores standard format templates that match various protocol types and their corresponding data encoding formats. Each template is associated with a unique retrieval identifier, which is formed by concatenating the protocol type name and the data encoding format name. The system concatenates the protocol type and data encoding format obtained in the previous step into a retrieval identifier, traverses all template retrieval identifiers in the format mapping library, and finds the template entry corresponding to the completely consistent retrieval identifier. The template associated with this entry is the standard format template corresponding to the current protocol type and data encoding format.

[0079] The standard format template clearly specifies the field arrangement order, the fixed length of each field, the type of separator between fields, and the data representation format. The system extracts the original data corresponding to each field from the original communication data in the order specified in the template. For fields whose length does not meet the template requirements, if the original data length is insufficient, the padding characters specified in the template are used to add padding characters to the end of the field to the specified length. If the original data length exceeds the template length, the data is truncated from the end to the specified length according to the truncation rules specified in the template. At the same time, the original separators in the original data are replaced with the separators specified in the template. All the processed fields are combined in the order required by the template to obtain the unified intermediate data of IoT heterogeneous devices.

[0080] The pre-defined validation rules include three dimensions: field quantity validation, field data type validation, and delimiter correctness validation. Field quantity validation requires confirming that the total number of fields in the formatted intermediate data matches the number of fields specified in the standard format template. Field data type validation requires checking that the data type of each field completely matches the type required by the template. Delimiter correctness validation requires verifying that the delimiters used between fields are the same as the delimiters specified in the template. If all validation items meet the requirements, the validation is considered successful. Afterward, the system re-integrates the fields of the formatted intermediate data that have passed the validation according to the complete data structure specified in the standard format template, ensuring that the data structure is complete and the format is standardized, ultimately forming a standardized data stream for heterogeneous IoT devices.

[0081] The beneficial effects are: accurately acquiring key information from the raw communication data of heterogeneous IoT devices, clarifying the protocol type and data encoding format, standardizing the arrangement, length and delimiters of data fields by matching the corresponding standard format template, ensuring the integrity of the data structure and compliance of the format through multi-dimensional verification, and finally forming a unified and standardized data stream, providing a reliable data foundation for subsequent protocol adaptation and data interaction, and improving the consistency and adaptation efficiency of heterogeneous device data processing.

[0082] S2. Based on the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream, perform matching and mapping in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices.

[0083] In this embodiment of the invention, the step of matching and mapping based on the real-time network status parameters of the IoT heterogeneous device and the protocol tags in the standardized data stream in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous device includes:

[0084] The real-time network status parameters of the IoT heterogeneous devices are extracted to obtain the current network quality level and available bandwidth range of the IoT heterogeneous devices;

[0085] The standardized data stream is subjected to protocol identification to obtain the protocol tags of the heterogeneous IoT devices;

[0086] The current network quality level, the available bandwidth range, and the protocol label are used as composite query conditions to perform a joint query in a preset protocol stack mapping table to obtain the candidate protocol stack description of the IoT heterogeneous device.

[0087] Based on a preset protocol stack selection strategy, the candidate protocol stack descriptions are filtered to obtain the target protocol stack description of the IoT heterogeneous device.

[0088] The protocol layer structure and parameter configuration in the target protocol stack description are instantiated and transformed to obtain the temporary communication protocol stack of the IoT heterogeneous device.

[0089] The step of using the current network quality level, the available bandwidth range, and the protocol tag as composite query conditions to perform a joint query in a pre-set protocol stack mapping table to obtain candidate protocol stack descriptions for the heterogeneous IoT devices includes:

[0090] Based on the protocol tags, tag matching is performed in a preset protocol stack mapping table to obtain the basic protocol stack description set of the IoT heterogeneous device;

[0091] Based on the current network quality level, the basic protocol stack description set is filtered for network quality to obtain the quality adaptation subset of the IoT heterogeneous devices;

[0092] Based on the available bandwidth range, bandwidth adaptation selection is performed on the quality adaptation subset to obtain candidate protocol stack descriptions for the heterogeneous IoT devices.

[0093] The system continuously collects real-time network data from heterogeneous IoT devices through a network status monitoring component. The collection period is set to 1 second. The collected network data includes data transmission latency, packet loss count, and total data transmission volume per unit time. The data transmission latency is obtained by sending a fixed-size test data packet to the device and recording the total time from transmission to reception. The packet loss count is obtained by calculating the difference between the total number of sent data packets and the total number of received acknowledgment data packets. The total data transmission volume per unit time is obtained by summing the sizes of all successfully transmitted data packets within 1 second. Subsequently, the system references a preset network... The quality level classification standard is as follows: Level 1 is defined as latency ≤ 50ms and packet loss rate ≤ 1%; Level 2 is defined as latency 51-100ms and packet loss rate 1.1%-3%; Level 3 is defined as latency 101-200ms and packet loss rate 3.1%-5%; and Level 4 is defined as latency > 200ms or packet loss rate > 5%. To determine the current network quality level, the total data transmission volume per unit time is continuously collected 10 times per second. The minimum and maximum values ​​among the 10 collection results are taken to form the available bandwidth range. Finally, the current network quality level and available bandwidth range of IoT heterogeneous devices are obtained.

[0094] The system reads the preset protocol identifier field in the header of the standardized data stream. This field is fixed in the 7th-10th bytes of the header. The system reads the binary code of this field byte by byte and matches it with the preset protocol identifier and tag correspondence table. The protocol identifier and tag correspondence table stores a one-to-one correspondence between all supported binary codes and protocol tags. For example, the binary code "0001" corresponds to "MQTT protocol tag" and "0010" corresponds to "HTTP protocol tag". When the read binary code is completely consistent with a certain item in the correspondence table, the protocol tag name corresponding to that item is extracted to obtain the protocol tag of the IoT heterogeneous device.

[0095] The pre-configured protocol stack mapping table is a structured data table containing columns for protocol label, network quality level, available bandwidth range, and protocol stack description. The system first searches for all rows in the protocol label column that are exactly the same as the current protocol label, forming a preliminary filtering result set. Then, it extracts rows from the preliminary filtering result set whose network quality level matches the current network quality level, forming a secondary filtering result set. Next, it checks whether the available bandwidth range of each row in the secondary filtering result set includes the current available bandwidth range. The criteria for judging the available bandwidth range are that the minimum value of the current available bandwidth range is greater than or equal to the minimum value of the range, and the maximum value of the current available bandwidth range is less than or equal to the maximum value of the range. All the protocol stack description columns corresponding to all rows that meet this condition are extracted and combined to form candidate protocol stack descriptions for IoT heterogeneous devices.

[0096] The pre-defined protocol stack selection strategy is to "prioritize the protocol stack description with the fewest protocol stack layers and the highest number of supported concurrent connections". The system first counts the number of protocol layers explicitly recorded in each candidate protocol stack description. For example, if a candidate description contains 4 layers (physical layer, data link layer, network layer, and transport layer) and another candidate description contains 5 layers (physical layer, data link layer, network layer, transport layer, and application layer), then the candidate description with 5 protocol layers is first excluded. If multiple candidate protocol stack descriptions have the same number of protocol layers, the maximum number of supported concurrent connections recorded in each description is extracted, and the candidate protocol stack description with the largest value is selected. If only one candidate protocol stack description exists, it is directly used as the target protocol stack description, and finally the target protocol stack description for IoT heterogeneous devices is obtained.

[0097] The target protocol stack description details the names of each protocol layer, the functional definitions of each protocol layer, the interaction order between each protocol layer, and the names of the required configuration items for each layer. During the instantiation and conversion process, the system creates the functional modules of each protocol layer in sequence according to the protocol layer order in the description, assigns fixed attribute values ​​that conform to communication standards to each configuration item, such as assigning "100Mbps" to the physical layer configuration item "transmission rate", "CRC32 check" to the data link layer configuration item "frame check method", and "OSPF protocol" to the network layer configuration item "routing protocol". At the same time, it establishes data flow transmission channels between the functional modules of each protocol layer according to the interaction order specified in the description, ensuring that the output data of the upper layer module can be accurately transmitted to the lower layer module for processing, and finally constructs a temporary communication protocol stack that can be directly used for inter-device communication.

[0098] The pre-configured protocol stack mapping table is a structured data table containing a protocol tag column and a protocol stack description column. In each row, the protocol tag column stores the protocol tag in string form, and the protocol stack description column stores complete descriptive information such as the hierarchical structure and functional characteristics of the corresponding protocol stack. The system reads the protocol tags of the previously obtained heterogeneous IoT devices, traverses the protocol tag column of the protocol stack mapping table row by row, and compares the protocol tag string of each row with the current protocol tag character by character. When the character sequences of the two are completely consistent, the complete description content in the protocol stack description column of that row is extracted. All protocol stack description contents that are successfully matched through character-by-character comparison are collected and organized to form the basic protocol stack description set of heterogeneous IoT devices.

[0099] Each protocol stack description in the basic protocol stack description set clearly indicates the network quality level it supports. The labeling format is completely consistent with the naming convention of the current network quality level. The system retrieves each protocol stack description in the basic protocol stack description set one by one, reads the supported network quality level it labels, and compares the name of the level with the name of the current network quality level. If the two names are exactly the same, the protocol stack description is retained; if the names are different, the description is directly removed. All the retained protocol stack descriptions are integrated together to obtain the quality adaptation subset for heterogeneous IoT devices.

[0100] Each protocol stack description in the quality adaptation subset has a predefined fixed supported bandwidth range, labeled as "XMbps-YMbps", where X is the minimum value and Y is the maximum value, both in Mbps. The system extracts each protocol stack description from the quality adaptation subset, splits its labeled supported bandwidth range string to obtain the minimum value X and the maximum value Y. Simultaneously, it extracts the minimum and maximum available bandwidth ranges of previously determined IoT heterogeneous devices. The minimum value of the current available bandwidth range is compared with the minimum value X, and the maximum value of the current available bandwidth range is compared with the maximum value Y. If the minimum value of the current available bandwidth range is greater than or equal to X, and the maximum value of the current available bandwidth range is less than or equal to Y, then the protocol stack description is retained. All protocol stack descriptions that meet this comparison condition together form the candidate protocol stack descriptions for IoT heterogeneous devices.

[0101] The beneficial effects are: accurately collecting network-related data from heterogeneous IoT devices, clarifying network quality levels and available bandwidth ranges, accurately identifying protocol tags, achieving precise matching of protocol stack descriptions through multi-round filtering of structured tables, determining the target protocol stack description for adaptation in combination with predetermined strategies, and constructing a temporary communication protocol stack that can be directly used for device communication through instantiation and transformation, thereby improving the targeting and reliability of protocol adaptation and providing strong support for smooth communication between heterogeneous devices.

[0102] S3. Perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous devices;

[0103] In this embodiment of the invention, the step of semantically abstracting the standardized data stream to obtain the intermediate semantic representation layer for the heterogeneous IoT devices includes:

[0104] Effective data separation is performed on the payload portion of the standardized data stream to obtain the original semantic element set of the heterogeneous IoT devices;

[0105] The header information of the standardized data stream is read to obtain the device type identifier and data generation timestamp of the heterogeneous IoT device;

[0106] Based on the device semantic definition rules corresponding to the device type identifier, the original semantic element set is semantically reconstructed to obtain a normalized semantic element set;

[0107] The standardized semantic element set, the device type identifier, and the data generation timestamp are associated and encapsulated to obtain the intermediate semantic representation layer of the heterogeneous IoT device.

[0108] The standardized data stream has a default header length of 20 bytes, with byte numbers ranging from 1 to 20. Bytes 21 and onwards are defined as the payload. The system reads byte 21 and all subsequent data sequentially according to their byte numbers to form a payload data segment. The system then traverses this payload data segment, identifying byte segments with consecutive all zeros or all ones and a length exceeding 5 bytes. These byte segments are determined as invalid data and directly removed. The remaining byte segments that are not removed are split according to the default field delimiters in the standardized data stream. Each split independent data fragment is treated as a raw semantic element. All raw semantic elements are aggregated to form the raw semantic element set for heterogeneous IoT devices.

[0109] The header information of the standardized data stream contains a fixed field area, where bytes 11-15 are the device type identifier field and bytes 16-20 are the data generation timestamp field. The system reads the binary data of bytes 11-15 byte by byte and converts it into the corresponding string according to the ASCII encoding conversion rules. This string is the device type identifier of the IoT heterogeneous device. At the same time, it reads the binary data of bytes 16-20 byte by byte and converts it into a time string in the format "YYYYMMDDHHMMSS" according to the decimal conversion rules. This time string is the data generation timestamp of the IoT heterogeneous device.

[0110] A pre-set one-to-one correspondence table between device type identifiers and device semantic definition rules is provided. Each rule in the table clearly specifies the semantic name, data format requirements, and element arrangement order of the original semantic elements under the corresponding device type. The system accurately matches the previously obtained device type identifiers with the entries in the corresponding table, extracts the device semantic definition rules corresponding to the successfully matched entries, extracts each original semantic element from the original semantic element set one by one, assigns the corresponding semantic name according to the rules, adjusts the element data format to the form required by the rules, and reorganizes all elements according to the arrangement order specified by the rules to form a standardized semantic element set for heterogeneous IoT devices.

[0111] The system adopts a hierarchical encapsulation structure of "device type identifier - data generation timestamp - standardized semantic elements". First, the device type identifier is used as the top-level identifier, and the data generation timestamp is used as the secondary association information. It establishes an association relationship with each element in the standardized semantic element set. Each standardized semantic element is accompanied by its corresponding semantic name and data generation timestamp. Then, all the associated information is integrated in a fixed format of "device type identifier | data generation timestamp | semantic name 1: element value 1 | semantic name 2: element value 2 | ...". The parts are separated by "|", and the semantic name and element value are associated with ":". Finally, a unified and semantically clear intermediate semantic representation layer for heterogeneous IoT devices is formed.

[0112] The beneficial effects are: accurately separating valid and invalid data in standardized data streams, extracting key information such as device type identifiers and data generation timestamps, standardizing the original semantic elements according to device semantic definition rules, clarifying semantic names, unifying data formats and standardizing the arrangement order, establishing the relationship between various elements through hierarchical encapsulation, and finally forming a unified and semantically clear intermediate semantic representation layer, providing accurate and standardized semantic data support for subsequent protocol conversion, and improving the semantic consistency and interpretability of data interaction.

[0113] S4. Based on the constraints of the temporary communication protocol stack, the content of the intermediate semantic representation layer is arranged in real time to obtain the protocol conversion rule set of the IoT heterogeneous device;

[0114] In this embodiment of the invention, the real-time rule arrangement of the content of the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack to obtain the protocol conversion rule set of the IoT heterogeneous device includes:

[0115] Extracting elements from the temporary communication protocol stack yields a list of protocol constraint elements for the heterogeneous IoT devices.

[0116] Based on the protocol constraint element list, field matching is performed on the content of the intermediate semantic representation layer to obtain the correspondence between the semantic fields and protocol fields of the IoT heterogeneous devices;

[0117] Based on the aforementioned correspondence, a logical mapping is constructed on the pre-set conversion operation library to obtain the field conversion operation sequence of the IoT heterogeneous device;

[0118] Based on the transmission requirements in the protocol constraint element list, the sequence constraints of the field conversion operation sequence are applied to obtain the protocol conversion rule set of the IoT heterogeneous device.

[0119] The step of applying sequence constraints to the field conversion operation sequence based on the transmission requirements in the protocol constraint element list yields the protocol conversion rule set for the IoT heterogeneous devices, including:

[0120] Feature extraction is performed on the transmission requirements in the protocol constraint element list to obtain the timing attributes and reliability indicators of the IoT heterogeneous devices;

[0121] Based on the time sequence attribute, the field transformation operation sequence is rearranged in time sequence to obtain the time sequenced operation sequence of the IoT heterogeneous device;

[0122] Based on the reliability index, reliability logic is injected into the time-series operation sequence to obtain the controlled operation sequence of the IoT heterogeneous device.

[0123] The controlled operation sequence is encapsulated into a policy to obtain the protocol conversion rule set for the heterogeneous IoT devices.

[0124] The temporary communication protocol stack contains a complete structure of physical layer, data link layer, network layer, transport layer, and application layer. Each layer clearly records core constraint information. The system parses each protocol layer one by one in the order from physical layer to application layer, extracting the key elements affecting data conversion in each layer, including the transmission rate limit of physical layer, the frame length limit and frame verification method of data link layer, the IP protocol version and routing identifier format of network layer, the port number range and data fragmentation threshold of transport layer, and the field naming convention and data format requirements of application layer. All extracted key elements are organized into a structured list according to the protocol layer order. Each element is labeled with its corresponding protocol layer and specific constraint content, resulting in a list of protocol constraint elements for heterogeneous IoT devices.

[0125] The intermediate semantic representation layer contains a standardized semantic element set, device type identifier, and data generation timestamp. Each element in the standardized semantic element set has a clear semantic name and data type. The protocol constraint element list contains information such as the name, data type, and function definition of the protocol fields. The system retrieves each protocol field from the protocol constraint element list one by one, first comparing its data type with the data type of each semantic field in the intermediate semantic representation layer to see if they are completely consistent, and then comparing whether the function definition descriptions of the two are consistent. When the data type is consistent and the function definition is completely matched, a correspondence between the semantic field and the protocol field is established and recorded in the form of "semantic field name - protocol field name". All established correspondences are summarized to form the correspondence between semantic fields and protocol fields of IoT heterogeneous devices.

[0126] The pre-built conversion operation library stores various specific field conversion operations. Each operation clearly indicates the applicable source data type, target data type, and detailed execution steps. For example, the "decimal number to hexadecimal string" operation is applicable when the source data type is numeric and the target data type is string. The execution steps are: "convert the numeric number to a hexadecimal number by dividing by 16 and taking the remainder. If the number is less than two digits, add leading zeros. Finally, concatenate the numbers into a string." The system iterates through the correspondence between semantic fields and protocol fields. For each pair of correspondences, it searches for a unique matching conversion operation in the pre-built conversion operation library based on the data types of the semantic field and the protocol field. These conversion operations are arranged sequentially according to the order of the correspondences. Each operation is associated with its corresponding semantic field and protocol field, forming an ordered operation queue, resulting in a sequence of field conversion operations for heterogeneous IoT devices.

[0127] The transmission requirements in the protocol constraint element list include timing attributes and reliability indicators. The timing attributes clearly define the transmission order of protocol fields, and the reliability indicators clearly require the addition of data check bits and retransmission flags. The system first adjusts the execution order of each operation in the field conversion operation sequence according to the transmission order specified by the timing attributes to ensure that the converted protocol fields meet the transmission order requirements. Then, it adds the "CRC32 check bit generation" operation and the "retransmission flag addition" operation to the end of the adjusted operation sequence. Finally, the adjusted field conversion operation sequence is encapsulated in a fixed format of "operation order-operation name-operation object-execution steps". The execution steps of each operation are clear and specific, forming a structured rule set, which yields the protocol conversion rule set for IoT heterogeneous devices.

[0128] The transmission requirements in the protocol constraint element list are stored in structured text format. Each transmission requirement contains two fields: "Feature Type" and "Specific Content". The system reads all transmission requirement records line by line and classifies them by identifying the value of the "Feature Type" field. When the "Feature Type" is "Time Sequence", the system extracts the field sequence string separated by "→" in the corresponding "Specific Content" field and defines the string and the field sequence in it as the time sequence attribute of the IoT heterogeneous device. When the "Feature Type" is "Reliability", the system extracts the safeguards recorded in the corresponding "Specific Content" field and integrates the specific content of these safeguards into the reliability index of the IoT heterogeneous device.

[0129] The timing attribute explicitly defines the transmission order of each protocol field after protocol conversion. Each operation in the field conversion operation sequence is associated with a unique protocol field name. The system first decomposes the field order in the timing attribute into an independent list of field names, then traverses the field conversion operation sequence one by one, recording the protocol field name associated with each operation. According to the order of the field name list, the corresponding operations in the field conversion operation sequence are rearranged. Redundant operations that are not included in the field name list but exist in the operation sequence are directly removed to ensure that the rearranged operation sequence is completely consistent with the field order specified by the timing attribute, ultimately forming the timing-sequential operation sequence for IoT heterogeneous devices.

[0130] The reliability metrics include three specific requirements: check bit generation, retransmission control, and timeout handling. The system first adds a "CRC32 check bit generation operation" to the end of the time-series operation sequence. The execution steps are: "Read the output data of all operations in the time-series operation sequence, concatenate them into a complete data block in byte order, calculate the 4-byte checksum using the CRC32 checksum algorithm, and append the checksum as an independent field to the end of the data block." Next, a "retransmission flag setting operation" is added after this operation. The execution steps are: "Initialize a 1-byte retransmission flag field to 0; if a data transmission timeout is detected subsequently, change the flag to 1." Finally, a "timeout judgment operation" is added. The execution steps are: "Record the data transmission time, continuously monitor the target device's reception feedback; if no feedback is received within 500ms, trigger the retransmission flag setting operation and re-execute all operations in the time-series operation sequence; stop retransmission after the cumulative retransmission count reaches 1." By adding these three operations, a controlled operation sequence for IoT heterogeneous devices is obtained.

[0131] The system employs a three-layer encapsulation structure of "operation metadata + execution logic + constraints" to process the controlled operation sequence. Each operation is assigned a unique 10-digit operation ID, starting from 0000000001 and incrementing sequentially. The associated field names, execution step text, and dependent protocol constraints of each operation are extracted. Each operation is encapsulated in a fixed format of "operation ID|associated field|execution step constraint". All encapsulated operations are arranged in the order of the original controlled operation sequence, with start and end identifiers added to the beginning and end, respectively, forming a unified and directly callable text format set, thus obtaining the protocol conversion rule set for IoT heterogeneous devices.

[0132] The beneficial effects are as follows: accurately extracting the core constraint elements of each layer of the temporary communication protocol stack, establishing a precise correspondence between semantic fields and protocol fields, matching and adapting field conversion operations to form an ordered operation sequence, standardizing the operation execution order based on time-series attributes, supplementing the guarantee operation with reliability indicators, and forming a unified and directly callable protocol conversion rule set through a three-layer encapsulation structure, ensuring the standardization, adaptability and reliability of protocol conversion, providing a clear and explicit execution basis for the efficient conversion of heterogeneous device data, and improving the accuracy and smoothness of data conversion.

[0133] S5. Based on the protocol conversion rule set, perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer to obtain the data packet of the IoT heterogeneous device;

[0134] In this embodiment of the invention, the step of performing protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set to obtain the data packet of the IoT heterogeneous device includes:

[0135] The protocol conversion rule set is parsed to obtain the field mapping relationship and target protocol header format of the IoT heterogeneous devices;

[0136] Based on the field mapping relationship, the data in the intermediate semantic representation layer is transformed to obtain the transformed data fields of the IoT heterogeneous device;

[0137] Based on the target protocol header format, a header is added to the converted data fields to obtain the preliminary data packet of the IoT heterogeneous device;

[0138] The integrity of the initial data packet is verified to obtain the data packet of the heterogeneous IoT device.

[0139] The protocol conversion rule set is stored in a fixed format of "Operation ID|Associated Field|Execution Step|Constraints". It has clear start and end markers at the beginning and end. The system first identifies and removes these two markers, and then parses the "Associated Field" part of each rule line by line to extract the corresponding record of "Semantic Field Name - Protocol Field Name". All records are summarized to form the field mapping relationship of IoT heterogeneous devices. At the same time, the content of the header configuration in the "Constraints" part of the rule is parsed to extract the field composition of the protocol header, the fixed number of bytes of each field, the encoding method and the field arrangement order. This information is integrated to form the target protocol header format of IoT heterogeneous devices.

[0140] The intermediate semantic representation layer contains a standardized set of semantic elements, device type identifiers, and data generation timestamps. Each semantic field has a clear name and data value. The system iterates through each record in the field mapping relationship, precisely comparing the semantic field names in the record with those in the intermediate semantic representation layer. After finding a completely matching semantic field, the system extracts the corresponding protocol field name and the conversion method described in the "execution steps" of the rule. The system processes the matched semantic field data according to the conversion method. For example, if the conversion method is "numeric type, retain two decimal places and convert to UTF-8 string", then the numerical value of the semantic field is first rounded to two decimal places according to the rounding rule, and then converted to the corresponding string according to the UTF-8 encoding rule. All protocol field names correspond one-to-one with the processed data, forming the converted data fields of IoT heterogeneous devices.

[0141] The target protocol header format clearly defines the composition, byte count, encoding method, and arrangement order of the header fields. The system processes each header field sequentially according to the format specifications. For the protocol type field, the corresponding protocol type string is converted into 2 bytes of binary data using UTF-8 encoding. For the version number field, the preset version number is converted into 1 byte of binary data. For the data length field, the total number of bytes in the converted data field is calculated and converted into 4 bytes of binary data. All processed header fields are concatenated in the specified order to form a complete target protocol header. This target protocol header is then directly appended to the beginning of the converted data fields, and the two are stored continuously without gaps, resulting in the initial data packets for heterogeneous IoT devices.

[0142] Integrity verification uses CRC32 checksum. The system reads all data in the initial data packet byte-by-byte order. Starting from the first byte, it performs a bitwise XOR operation between the current byte and the initial checksum value. Then, it shifts the result to the left by a specified number of bits. If the highest bit after the shift is 1, it performs a bitwise XOR operation with a preset CRC32 polynomial. This shifting and XOR process is repeated until all bytes have been processed. Finally, the result is bitwise NOTed to obtain a 4-byte CRC32 checksum. This checksum is directly appended to the end of the initial data packet, forming a continuous data block containing the target protocol header, the converted data fields, and the CRC32 checksum. This data block is the data packet for the IoT heterogeneous device.

[0143] The beneficial effects are as follows: it accurately analyzes the protocol conversion rule set, clarifies the field mapping relationship and the target protocol header format, processes the semantic field data of the intermediate semantic representation layer according to the standardized conversion method to form the converted data field, splices the target protocol header and the converted data field according to the predetermined format to obtain the preliminary data packet, and adds a check code through integrity verification to form the complete data packet, ensuring that the data packet structure is standardized, the data is accurate and the transmission is secure, providing a reliable carrier for data transmission between heterogeneous IoT devices, and improving the integrity and adaptability of data transmission.

[0144] S6. Monitor the transmission status of the data packet and the feedback from the target device in real time, and adjust the execution parameters of the matching mapping process and the real-time rule orchestration process in a closed loop based on the monitoring results.

[0145] In this embodiment of the invention, the step of real-time monitoring of the transmission status of the data packet and the feedback from the target device, and closed-loop adjustment of the execution parameters of the matching mapping process and the real-time rule orchestration process based on the monitoring results, includes:

[0146] The transmission status of the data packets is continuously monitored to obtain the average transmission latency and data packet loss rate of the heterogeneous IoT devices;

[0147] The feedback from the target device is dynamically processed to obtain the link quality score of the heterogeneous IoT devices;

[0148] The average transmission delay, the data packet loss rate, and the link quality score are weighted and synthesized to obtain the system adaptive adjustment factor for the heterogeneous IoT devices.

[0149] Based on the system adaptive adjustment factor, the network quality level weight benchmark value used in the protocol stack mapping table during the matching mapping process is adaptively updated.

[0150] Based on the system's adaptive adjustment factor, the sensitivity threshold used to trigger rule recombination during the real-time rule orchestration process is dynamically adjusted.

[0151] The formula for calculating the system's adaptive adjustment factor is as follows:

[0152] ;

[0153] In the formula, This is the adaptive adjustment factor for the system. For the pre-configured system baseline coefficients, The preset target transmission delay, The average transmission delay is... The packet loss rate is... The link quality is scored.

[0154] The system initiates a data packet transmission status monitoring process with a monitoring period of ten seconds. During each monitoring period, the transmission status of one hundred data packets is continuously counted. Each data packet is assigned a unique identifier and its sending time is accurately recorded. When a corresponding data packet reception confirmation is received from the target device, the confirmation reception time is recorded synchronously. The transmission delay of a single data packet is obtained by subtracting its sending time from the reception confirmation time. The transmission delays of all one hundred data packets are added together and then divided by one hundred to obtain the average transmission delay of the IoT heterogeneous devices. At the same time, the number of data packets that did not receive a reception confirmation from the target device within 500 milliseconds after being sent is counted. The number of unacknowledged data packets is divided by the total number of sent data packets to obtain the data packet loss rate of the IoT heterogeneous devices.

[0155] After the target device successfully receives the data packet, it automatically generates a feedback packet containing three core parameters: signal strength, bit error rate, and transmission stability, and sends it back immediately. Upon receiving this feedback packet, the system analyzes and scores each of the three parameters according to preset standards. The signal strength parameter is divided into three levels: greater than or equal to -60 dB, -61 dB to -80 dB, and less than -80 dB, corresponding to 30, 20, and 10 points respectively. The bit error rate parameter is divided into three levels: less than or equal to 0.1%, 0.11% to 0.5%, and greater than 0.5%, corresponding to 30, 20, and 10 points respectively. The transmission stability parameter is divided into three levels: no packet loss for five consecutive seconds, one packet loss for five consecutive seconds, and two or more packet losses for five consecutive seconds, corresponding to 40, 30, and 20 points respectively. The scores of the three parameters are directly added together to obtain the link quality score for the heterogeneous IoT device.

[0156] A fixed system baseline coefficient is pre-configured, and a specific target transmission delay is preset. First, the preset target transmission delay is divided by the monitored average transmission delay to obtain a ratio reflecting the degree of matching between the actual delay and the target delay. Then, the monitored data packet loss rate is subtracted to obtain the data packet transmission success rate. Next, the link quality score obtained in the second step is extracted. Then, the four values ​​of the pre-configured system baseline coefficient, the above-mentioned ratio, the data packet transmission success rate, and the link quality score are multiplied together. The result is the system adaptive adjustment factor for IoT heterogeneous devices. This calculation process integrates system baseline requirements, delay compliance, transmission success probability, and link quality level to ensure that the result can comprehensively reflect the communication status.

[0157] The initial network quality level weight baseline values ​​preset in the protocol stack mapping table are 50 for Level 1, 30 for Level 2, 15 for Level 3, and 5 for Level 4, with the total weight fixed at 100. The system makes targeted adjustments based on the score range of the system adaptive adjustment factor. When the adjustment factor is greater than or equal to 80, the weight of Level 1 is increased by 10 and the weight of Level 4 is decreased by 10, resulting in 60 for Level 1, 30 for Level 2, 15 for Level 3, and 5 for Level 4. When the adjustment factor is between 60 and 79, the weight of Level 1 is increased by 5 and the weight of Level 4 is decreased by 5, resulting in 55 for Level 1, 30 for Level 2, 15 for Level 3, and 10 for Level 4. When the adjustment factor is between 40 and 59, the weight of Level 3 is increased by 5 and the weight of Level 1 is decreased by 5, resulting in 45 for Level 1, 30 for Level 2, 20 for Level 3, and 5 for Level 4. When the adjustment factor is less than 40, the weight of Level 4 is increased by 10 and the weight of Level 1 is decreased by 10, resulting in 40 for Level 1, 30 for Level 2, 15 for Level 3, and 15 for Level 4. The total weight remains unchanged at 100 after the adjustment, completing the adaptive update.

[0158] During real-time rule orchestration, the initial threshold for triggering rule reorganization sensitivity is set to five. This threshold represents the value at which a change in transmission status parameters triggers rule reorganization. The parameter change range is calculated as the absolute value of the difference between the current monitored value and the previous monitored value. The system dynamically adjusts this threshold based on the score range of the system adaptive adjustment factor. When the adjustment factor is greater than or equal to 80, the threshold is adjusted to three, meaning that reorganization is triggered when the parameter change range reaches three. When the adjustment factor is between 60 and 79, the threshold is adjusted to four. When the adjustment factor is between 40 and 59, the threshold remains unchanged at five. When the adjustment factor is less than 40, the threshold is adjusted to six, meaning that a parameter change range of six is ​​required to trigger reorganization, ensuring that the triggering timing of rule reorganization is accurately matched with the current link status.

[0159] The system initiates a data packet transmission status monitoring process with a monitoring period of 10 seconds. During each monitoring period, the transmission status of 100 data packets is continuously counted. Each data packet is assigned a unique identifier and its sending time is recorded. When a corresponding data packet reception confirmation is received from the target device, the confirmation reception time is recorded. The transmission delay of a single data packet is obtained by subtracting the sending time from the reception confirmation time of each data packet. The transmission delays of the 100 data packets are summed and divided by 100 to obtain the average transmission delay of the IoT heterogeneous devices. At the same time, the number of data packets that did not receive a reception confirmation is counted. The number of unacknowledged packets is divided by the total number of packets sent to obtain the data packet loss rate of the IoT heterogeneous devices. The criterion for unacknowledged packets is that no corresponding confirmation is received within 500ms after sending.

[0160] After receiving the data packet, the target device generates and sends back a feedback packet containing three core parameters: signal strength, bit error rate, and transmission stability. The system receives the feedback packet and parses these three parameters. The signal strength parameter is divided into three levels: "≥-60dBm", "-61dBm to -80dBm", and "<-80dBm", corresponding to 30, 20, and 10 points respectively. The bit error rate parameter is divided into three levels: "≤0.1%", "0.11% to 0.5%", and ">0.5%", corresponding to 30, 20, and 10 points respectively. The transmission stability parameter is divided into three levels: "no packet loss for 5 consecutive seconds", "one packet loss for 5 consecutive seconds", and "two or more packet losses for 5 consecutive seconds", corresponding to 40, 30, and 20 points respectively. The scores for the three parameters are added together to obtain the link quality score for the heterogeneous IoT device.

[0161] The system pre-sets the weighting weights for average transmission latency, packet loss rate, and link quality score to be 30%, 30%, and 40%, respectively. First, it converts the average transmission latency into corresponding scores of 100, 80, 60, and 40 points for each of the following categories: ≤50ms, 51ms to 100ms, 101ms to 200ms, and >200ms. It also converts the packet loss rate into corresponding scores of 100, 80, 60, and 40 points for each of the following categories: ≤1%, 1.1% to 3%, 3.1% to 5%, and >5%. The link quality score directly uses the previously obtained scores. Then, it multiplies the scores of the three indicators by their respective weighting weights, and sums the three products. The resulting total is the system adaptive adjustment factor for heterogeneous IoT devices, with a score range of 0 to 100 points.

[0162] The initial network quality level weight baseline values ​​preset in the protocol stack mapping table are: Level 1 50, Level 2 30, Level 3 15, and Level 4 5. The system adjusts these weights according to the score range of the system adaptive adjustment factor: When the adjustment factor is ≥80, the Level 1 weight is increased by 10 and the Level 4 weight is decreased by 10, resulting in Level 1 60, Level 2 30, Level 3 15, and Level 4 5; when the adjustment factor is between 60 and 79, the Level 1 weight is increased by 5 and the Level 4 weight is decreased by 5, resulting in Level 1 55, Level 2 30, Level 3 15, and Level 4 10; when the adjustment factor is between 40 and 59, the Level 3 weight is increased by 5 and the Level 1 weight is decreased by 5, resulting in Level 1 45, Level 2 30, Level 3 20, and Level 4 5; when the adjustment factor is <40, the Level 4 weight is increased by 10 and the Level 1 weight is decreased by 10, resulting in Level 1 40, Level 2 30, Level 3 15, and Level 4 15. The total weight remains unchanged at 100 after adjustment, completing the adaptive update.

[0163] During real-time rule orchestration, the initial threshold for triggering rule reorganization sensitivity is set to 5. This threshold indicates that reorganization is triggered when the transmission status parameter changes by 5 units. The system adjusts the threshold based on the system adaptive adjustment factor: when the adjustment factor is ≥80, the threshold is adjusted to 3, meaning that rule reorganization is triggered when the parameter change reaches 3 units; when the adjustment factor is between 60 and 79, the threshold is adjusted to 4; when the adjustment factor is between 40 and 59, the threshold remains unchanged at 5; when the adjustment factor is <40, the threshold is adjusted to 6, meaning that reorganization is triggered only when the parameter change reaches 6 units. The parameter change range is calculated as the absolute value of the difference between the current value and the previous monitored value, ensuring that the triggering timing of rule reorganization after dynamic parameter adjustment is adapted to the current link status.

[0164] The beneficial effects are: accurately monitoring the data packet transmission status and target device feedback, obtaining key transmission indicators and synthesizing system adaptive adjustment factors, dynamically updating the network quality level weight benchmark value of the protocol stack mapping table based on the factor, flexibly adjusting the sensitivity threshold of real-time rule orchestration, making protocol adaptation and rule reorganization more in line with the current link status, continuously optimizing the adaptability and responsiveness of heterogeneous device interconnection, and effectively improving the stability of data transmission and the overall system operating performance.

[0165] like Figure 2 The diagram shown is a functional block diagram of a multi-protocol converged IoT heterogeneous device interconnection system provided in an embodiment of the present invention.

[0166] The multi-protocol converged IoT heterogeneous device interconnection system 100 of this invention can be installed in electronic devices. Depending on the functions implemented, the multi-protocol converged IoT heterogeneous device interconnection system 100 may include a data preprocessing module 101, a protocol dynamic adaptation module 102, a semantic abstraction module 103, a dynamic rule generation module 104, a protocol conversion execution module 105, and a closed-loop optimization control module 106. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, stored in the memory of the electronic device.

[0167] In this embodiment, the functions of each module / unit are as follows:

[0168] The data preprocessing module 101 is used to normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices.

[0169] The protocol dynamic adaptation module 102 is used to perform matching and mapping in a preset protocol stack mapping table based on the real-time network status parameters of the IoT heterogeneous device and the protocol tags in the standardized data stream to obtain the temporary communication protocol stack of the IoT heterogeneous device.

[0170] The semantic abstraction module 103 is used to perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous device.

[0171] The dynamic rule generation module 104 is used to perform real-time rule arrangement on the content of the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack, so as to obtain the protocol conversion rule set of the IoT heterogeneous device.

[0172] The protocol conversion execution module 105 is used to perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set to obtain the data packet of the IoT heterogeneous device.

[0173] The closed-loop optimization control module 106 is used to monitor the transmission status of the data packet and the feedback from the target device in real time, and to make closed-loop adjustments to the execution parameters of the matching mapping process and the real-time rule arrangement process based on the monitoring results.

[0174] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0175] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0177] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0178] This application embodiment can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended 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.

Claims

1. A method for interconnecting heterogeneous IoT devices using multi-protocol convergence, characterized in that, The method includes: S1. Normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices; S2. Based on the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream, perform matching and mapping in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices. S3. Perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous devices; S4. Based on the constraints of the temporary communication protocol stack, the content of the intermediate semantic representation layer is arranged in real time to obtain the protocol conversion rule set of the IoT heterogeneous device; S5. Based on the protocol conversion rule set, perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer to obtain the data packet of the IoT heterogeneous device; S6. Monitor the transmission status of the data packet and the feedback from the target device in real time, and adjust the execution parameters of the matching mapping process and the real-time rule orchestration process in a closed loop based on the monitoring results.

2. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, The process of format normalizing the raw communication data from heterogeneous IoT devices to obtain a standardized data stream from the heterogeneous IoT devices includes: Receive raw communication data from heterogeneous IoT devices, identify and parse the protocol header of the raw communication data to obtain the protocol type and data encoding format of the heterogeneous IoT devices; Based on the protocol type and the data encoding format, a corresponding standard format template is matched from a preset format mapping library; Based on the standard format template, the original communication data is converted to obtain the unified intermediate data of the IoT heterogeneous devices; The standardized intermediate data of the unified format is verified and recombined to obtain the standardized data stream of the heterogeneous IoT devices.

3. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, The temporary communication protocol stack of the IoT heterogeneous devices is obtained by matching and mapping the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream in a pre-set protocol stack mapping table, including: The real-time network status parameters of the IoT heterogeneous devices are extracted to obtain the current network quality level and available bandwidth range of the IoT heterogeneous devices; The standardized data stream is subjected to protocol identification to obtain the protocol tags of the heterogeneous IoT devices; The current network quality level, the available bandwidth range, and the protocol label are used as composite query conditions to perform a joint query in a preset protocol stack mapping table to obtain the candidate protocol stack description of the IoT heterogeneous device. Based on a preset protocol stack selection strategy, the candidate protocol stack descriptions are filtered to obtain the target protocol stack description of the IoT heterogeneous device. The protocol layer structure and parameter configuration in the target protocol stack description are instantiated and transformed to obtain the temporary communication protocol stack of the IoT heterogeneous device.

4. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 3, characterized in that, The step of using the current network quality level, the available bandwidth range, and the protocol tag as composite query conditions to perform a joint query in a pre-set protocol stack mapping table to obtain candidate protocol stack descriptions for the heterogeneous IoT devices includes: Based on the protocol tags, tag matching is performed in a preset protocol stack mapping table to obtain the basic protocol stack description set of the IoT heterogeneous device; Based on the current network quality level, the basic protocol stack description set is filtered for network quality to obtain the quality adaptation subset of the IoT heterogeneous devices; Based on the available bandwidth range, bandwidth adaptation selection is performed on the quality adaptation subset to obtain candidate protocol stack descriptions for the heterogeneous IoT devices.

5. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, The step of semantically abstracting the standardized data stream to obtain the intermediate semantic representation layer for the heterogeneous IoT devices includes: Effective data separation is performed on the payload portion of the standardized data stream to obtain the original semantic element set of the heterogeneous IoT devices; The header information of the standardized data stream is read to obtain the device type identifier and data generation timestamp of the heterogeneous IoT device; Based on the device semantic definition rules corresponding to the device type identifier, the original semantic element set is semantically reconstructed to obtain a normalized semantic element set; The standardized semantic element set, the device type identifier, and the data generation timestamp are associated and encapsulated to obtain the intermediate semantic representation layer of the heterogeneous IoT device.

6. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, Based on the constraints of the temporary communication protocol stack, the content of the intermediate semantic representation layer is subjected to real-time rule orchestration to obtain the protocol conversion rule set for the heterogeneous IoT devices, including: Extracting elements from the temporary communication protocol stack yields a list of protocol constraint elements for the heterogeneous IoT devices. Based on the protocol constraint element list, field matching is performed on the content of the intermediate semantic representation layer to obtain the correspondence between the semantic fields and protocol fields of the IoT heterogeneous devices; Based on the aforementioned correspondence, a logical mapping is constructed on the pre-set conversion operation library to obtain the field conversion operation sequence of the IoT heterogeneous device; Based on the transmission requirements in the protocol constraint element list, the sequence constraints of the field conversion operation sequence are applied to obtain the protocol conversion rule set of the IoT heterogeneous device.

7. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 6, characterized in that, The step of applying sequence constraints to the field conversion operation sequence based on the transmission requirements in the protocol constraint element list yields the protocol conversion rule set for the IoT heterogeneous devices, including: Feature extraction is performed on the transmission requirements in the protocol constraint element list to obtain the timing attributes and reliability indicators of the IoT heterogeneous devices; Based on the time sequence attribute, the field transformation operation sequence is rearranged in time sequence to obtain the time sequenced operation sequence of the IoT heterogeneous device; Based on the reliability index, reliability logic is injected into the time-series operation sequence to obtain the controlled operation sequence of the IoT heterogeneous device. The controlled operation sequence is encapsulated into a policy to obtain the protocol conversion rule set for the heterogeneous IoT devices.

8. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, The process of performing protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set to obtain the data packets of the IoT heterogeneous devices includes: The protocol conversion rule set is parsed to obtain the field mapping relationship of the IoT heterogeneous devices and the target protocol header format; Based on the field mapping relationship, the data in the intermediate semantic representation layer is transformed to obtain the transformed data fields of the IoT heterogeneous device; Based on the target protocol header format, a header is added to the converted data fields to obtain the preliminary data packet of the IoT heterogeneous device; The integrity of the initial data packet is verified to obtain the data packet of the heterogeneous IoT device.

9. The method for interconnecting heterogeneous IoT devices with multi-protocol fusion as described in claim 1, characterized in that, The real-time monitoring of the data packet transmission status and the feedback from the target device, and the closed-loop adjustment of the execution parameters of the matching mapping process and the real-time rule orchestration process based on the monitoring results, includes: The transmission status of the data packets is continuously monitored to obtain the average transmission latency and data packet loss rate of the heterogeneous IoT devices; The feedback from the target device is dynamically processed to obtain the link quality score of the heterogeneous IoT devices; The average transmission delay, the data packet loss rate, and the link quality score are weighted and synthesized to obtain the system adaptive adjustment factor for the heterogeneous IoT devices. Based on the system adaptive adjustment factor, the network quality level weight benchmark value used in the protocol stack mapping table during the matching mapping process is adaptively updated. Based on the system's adaptive adjustment factor, the sensitivity threshold used to trigger rule recombination during the real-time rule orchestration process is dynamically adjusted.

10. A multi-protocol converged IoT heterogeneous device interconnection system, characterized in that, The system for implementing the multi-protocol converged IoT heterogeneous device interconnection method as described in claim 1 includes: The data preprocessing module is used to normalize the format of the raw communication data from the heterogeneous IoT devices to obtain the standardized data stream of the heterogeneous IoT devices. The protocol dynamic adaptation module is used to match and map the real-time network status parameters of the IoT heterogeneous devices and the protocol tags in the standardized data stream in a preset protocol stack mapping table to obtain the temporary communication protocol stack of the IoT heterogeneous devices. The semantic abstraction module is used to perform semantic abstraction on the standardized data stream to obtain the intermediate semantic representation layer of the IoT heterogeneous devices; The dynamic rule generation module is used to perform real-time rule arrangement on the content of the intermediate semantic representation layer based on the constraints of the temporary communication protocol stack, so as to obtain the protocol conversion rule set of the IoT heterogeneous device; The protocol conversion execution module is used to perform protocol conversion and encapsulation on the data in the intermediate semantic representation layer based on the protocol conversion rule set, so as to obtain the data packets of the IoT heterogeneous device; The closed-loop optimization control module is used to monitor the transmission status of the data packet and the feedback from the target device in real time, and to adjust the execution parameters of the matching mapping process and the real-time rule orchestration process in a closed loop based on the monitoring results.

Images