Multi-protocol adaptive Internet of Things equipment communication management method and system

Abstract

The invention discloses a multi-protocol adaptive Internet of Things device communication management method and system, and relates to the technical field of Internet of Things device communication management, and the method comprises the steps: capturing an original message sent by a source device through a communication management node disposed at an edge side when an Internet of Things device initiates a communication request, obtaining a source device identifier, a target address and a transport layer protocol type of the original message; identifying a used application layer protocol according to the structural features and the communication context of the original message, extracting an operation intention contained in the original message, and generating a standardized semantic feature vector; on the basis of the difference degree between the standardized semantic feature vector and semantic feature vectors of other protocols, initial compatibility scores among the protocols are determined, and a communication topological graph is constructed in combination with real-time delay and node resource states of network links; and continuously recording communication execution results of different protocol pairs on each node, and generating a dynamic memory factor according to the change trend of the execution results.

Description

Technical Field

[0001] This invention relates to the field of IoT device communication management technology, and in particular to a multi-protocol-adaptive IoT device communication management method and system. Background Technology

[0002] IoT device communication management technology refers to a technical system in IoT systems that unifies the scheduling, protocol adaptation, path selection, status monitoring, and resource coordination of data transmission between massive heterogeneous devices. Its core objective is to ensure that IoT devices of different brands, protocols, and network environments can efficiently, reliably, and securely complete data interaction. Therefore, how to utilize advanced technologies to improve the intelligence and security of IoT device communication management has become one of the most pressing issues to be addressed.

[0003] In the field of IoT device communication management, traditional communication gateways usually have a fixed protocol stack pre-installed. Adding a new protocol requires re-burning the firmware or restarting the device, which cannot meet the needs of the rapidly evolving IoT environment. Moreover, the existing path selection mechanism is usually based only on physical layer indicators such as network latency and bandwidth, or simply judges whether the protocol is supported, ignoring the protocol's contribution to the stability of cooperation in actual operation. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a multi-protocol-adaptive IoT device communication management method to solve the problems of traditional communication gateways that usually have a fixed protocol stack pre-installed. Adding a new protocol requires re-burning the firmware or restarting the device, which cannot meet the needs of the rapidly evolving IoT environment. Furthermore, existing path selection mechanisms are usually based only on physical layer indicators such as network latency and bandwidth, or simply determine whether the protocol is supported, ignoring the issue of protocol stability in actual operation.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a multi-protocol-adaptive IoT device communication management method, comprising:

[0008] When an IoT device initiates a communication request, the communication management node deployed at the edge captures the original message sent by the source device and obtains the source device identifier, destination address, and transport layer protocol type of the original message.

[0009] Based on the structural features and communication context of the original message, the application layer protocol used is identified, and the operation intent contained in the original message is extracted to generate a standardized semantic feature vector.

[0010] Based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, the initial compatibility score between the protocols is determined, and a communication topology is constructed by combining the real-time latency of the network link and the node resource status.

[0011] The system continuously records the communication execution results of different protocols on each node, generates dynamic memory factors based on the changing trends of the execution results, and uses the dynamic memory factors to correct the initial compatibility score to obtain the evaluation result.

[0012] The edge weights in the communication topology graph are updated based on the evaluation results, and the optimal transmission path from the source node to the target node is determined based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost.

[0013] At each hop transition node of the optimal transmission path, check whether it has a functional module for processing the next-hop protocol. If not, dynamically load the corresponding lightweight virtualized protocol container, parse the input message into a unified semantic representation, reconstruct the output message according to the format specification of the target protocol, and complete the cross-protocol data forwarding.

[0014] As a preferred embodiment of the multi-protocol adaptation IoT device communication management method of the present invention, the steps of identifying the application layer protocol used based on the structural characteristics and communication context of the original message, extracting the operation intent contained in the original message, and generating a standardized semantic feature vector are as follows:

[0015] Perform a byte sequence scan on the original message to obtain the field separator type, total message length, function code occurrence position, and parameter encoding method;

[0016] Monitor the periodicity, request-response pattern, and transport layer protocol behavior characteristics of the communication session to which the monitoring message belongs;

[0017] By combining the communication port number with the TLS handshake fingerprint information, it can be determined whether there is a behavioral pattern that matches a known protocol;

[0018] When the degree of matching between the detected structural features and the pre-stored protocol behavior template exceeds a set threshold, the original message is determined to be the corresponding application layer protocol.

[0019] Invoke semantic parsing rules that match the identified protocol type to extract the operation action, target, and parameter value from the message;

[0020] The extracted operation actions are mapped to verb tags in a unified semantic space, the objects of action are mapped to device category tags, and the parameter values ​​retain their dimensional attributes, forming a standardized semantic feature vector.

[0021] As a preferred embodiment of the multi-protocol adaptation IoT device communication management method of the present invention, the determination of the initial compatibility score between each protocol based on the degree of difference between the standardized semantic feature vector and the semantic feature vectors of other protocols specifically involves:

[0022] Obtain the standardized semantic feature vectors of all reachable target protocols in the network, denoted as... ,in Indicates the first One target agreement;

[0023] The standardized semantic feature vector of the source protocol is denoted as... Its components in the three dimensions of operation type, target object, and parameter format are respectively denoted as: ;

[0024] Target Protocol The three dimensional components are denoted as ;

[0025] Calculate the normalized difference between the source protocol and the target protocol across all dimensions. The expression is:

[0026] ;

[0027] For difference values We perform a weighted summation to obtain the overall difference. The expression is:

[0028] ;

[0029] in , , These are the weighting coefficients;

[0030] Convert the overall difference score into an initial compatibility score. The expression is:

[0031] ;

[0032] The initial compatibility score is a value between 0 and 1, with a larger value indicating that the semantics between the protocols are closer.

[0033] As a preferred embodiment of the multi-protocol adaptation IoT device communication management method of the present invention, wherein: the step of continuously recording the communication execution results of different protocol pairs on each node, and generating a dynamic memory factor based on the changing trend of the execution results, specifically includes:

[0034] Each time the protocol is completed To the agreement After the conversion operation, record the conversion success status of this communication. Deviation between actual delay and expected delay and resource consumption volatility ;

[0035] For the same protocol In recent The execution results of each communication are used to create a time series set;

[0036] Calculate the stability index of recent communication performance , , The expression is:

[0037] ;

[0038] right , , The three stability metrics are weighted and fused to obtain the base memory value. The expression is:

[0039] ;

[0040] in, , , These are the weighting coefficients;

[0041] By introducing a time decay factor and performing exponential smoothing on historical data, a dynamic memory factor is generated. The expression is:

[0042] ;

[0043] The dynamic memory factor This reflects the stability of the collaboration formed in actual operation by the agreement.

[0044] As a preferred embodiment of the multi-protocol adaptation IoT device communication management method of the present invention, wherein: the step of using a dynamic memory factor to correct the initial compatibility score to obtain the evaluation result specifically includes:

[0045] The dynamic memory factor Compared with the initial compatibility score Nonlinear coupling operations are performed to obtain empirically enhanced compatibility evaluation results. The expression is:

[0046] ;

[0047] in, To adjust the gain coefficient, The memory activation threshold;

[0048] when > When the evaluation results are positively reinforced, it indicates that the agreement has a good history of collaborative performance;

[0049] when ≤ At that time, the evaluation results remain unchanged or slightly decay, avoiding over-reliance on unstable paths.

[0050] As a preferred embodiment of the multi-protocol adaptation IoT device communication management method of the present invention, wherein: at each hop conversion node of the optimal transmission path, it is checked whether a functional module for processing the next-hop protocol is available; if not, the corresponding lightweight virtualized protocol container is dynamically loaded, specifically:

[0051] At each hop transition node, a local protocol container registry is maintained to record the currently loaded protocol types and their corresponding functional module instances.

[0052] When a request is received that needs to be forwarded to the target protocol When a message is received, the registry is queried to confirm whether a message related to the protocol exists. Matching registered modules;

[0053] If no match is found, a download request is sent to the distributed protocol container repository to obtain the protocol. The corresponding WebAssembly format container file;

[0054] Digital signature verification is performed on container files to confirm their legitimate origin, and integrity verification is performed to ensure that the files have not been tampered with or damaged.

[0055] The verified container file is injected into the lightweight runtime environment, and its internal protocol parsing and conversion logic is initialized.

[0056] Add a new entry to the local registry, tagging the protocol. The functional modules are available.

[0057] As a preferred embodiment of the multi-protocol-adaptive IoT device communication management method of the present invention, the step of parsing the input message into a unified semantic representation and reconstructing the output message according to the format specification of the target protocol specifically includes:

[0058] The parser corresponding to the source protocol is invoked to decode the input message into an internally unified semantic triple. ,in, Indicates the main equipment identification. Indicates an operation action. Indicates the target object;

[0059] Query the field mapping rule base of the target protocol to obtain actions. Corresponding function code in the target protocol Object The field address and parameter encoding format;

[0060] Construct the original byte sequence based on the message structure template of the target protocol;

[0061] function code Write the specified position in the message header, write the object address to the address field, and fill the data segment with the parameter values ​​after serializing them according to the encoding format;

[0062] Add the timestamp and transaction identifier of the original communication to form a complete output message;

[0063] The output message is sent to the next-hop node to complete cross-protocol data forwarding.

[0064] Secondly, the present invention provides a multi-protocol-adaptive IoT device communication management system, comprising:

[0065] The module includes a message capture module, a protocol identification module, a topology construction module, a memory evaluation module, a path planning module, and a conversion execution module.

[0066] The message capture module is used to capture the original message sent by the source device when the IoT device initiates a communication request. The communication management node deployed on the edge side listens to the network interface, captures the original message, and obtains the source device identifier, destination address and transport layer protocol type of the original message.

[0067] The protocol identification module is used to identify the application layer protocol used based on the structural features and communication context of the original message, extract the operation intent contained in the original message, and generate a standardized semantic feature vector.

[0068] The topology construction module is used to determine the initial compatibility score between protocols based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, and to construct a communication topology graph by combining the real-time latency of the network link and the node resource status.

[0069] The memory evaluation module is used to continuously record the communication execution results of different protocol pairs on each node, generate dynamic memory factors based on the changing trends of the execution results, and use the dynamic memory factors to correct the initial compatibility score to obtain an experience-enhanced compatibility evaluation result.

[0070] The path planning module is used to update the edge weights in the communication topology graph according to the evaluation results, and determine the optimal transmission path from the source node to the target node based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost.

[0071] The conversion execution module is used to check whether the next-hop protocol processing module is available at each conversion node of the optimal transmission path. If not, the corresponding lightweight virtualized protocol container is dynamically loaded, the input message is parsed into a unified semantic representation, and the output message is reconstructed according to the format specification of the target protocol to complete cross-protocol data forwarding.

[0072] Thirdly, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program is executed by the processor, it implements any step of the multi-protocol adapted Internet of Things device communication management method as described in the first aspect of the present invention.

[0073] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the multi-protocol-adaptive Internet of Things device communication management method as described in the first aspect of the present invention.

[0074] The beneficial effects of this invention are as follows: By constructing standardized semantic feature vectors, a unified representation of multi-protocol operation intentions is achieved. Combined with dynamic memory factors generated based on historical communication performance, the initial protocol compatibility score is enhanced empirically, effectively overcoming the technical defects of traditional methods that rely solely on static syntax matching, resulting in insufficient adaptability. By introducing a dynamically loadable lightweight virtualized protocol container mechanism, on-demand expansion of protocol functions is achieved at edge nodes, improving the system's flexible adaptability and resource utilization efficiency in heterogeneous IoT environments. The communication topology dynamic optimization method takes into account semantic consistency, network status, and historical operating trends, enabling path planning to have self-learning and adaptive characteristics, thereby improving the success rate and overall performance of cross-protocol communication. Attached Figure Description

[0075] 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.

[0076] Figure 1 This is a flowchart of the multi-protocol adaptation IoT device communication management method in Example 1.

[0077] Figure 2This is a schematic diagram of the multi-protocol-adaptive IoT device communication management system in Example 1. Detailed Implementation

[0078] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0079] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0080] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0081] Example, refer to Figure 1 and Figure 2 This embodiment of the invention provides a multi-protocol-adaptive IoT device communication management method, comprising the following steps:

[0082] S1. When an IoT device initiates a communication request, the communication management node deployed at the edge captures the original message sent by the source device and obtains the source device identifier, destination address, and transport layer protocol type of the original message.

[0083] Furthermore, the communication management node monitors the network interface of its local area network segment and uses a packet capture mechanism to mirror and capture the passing communication traffic, retaining only valid packets with clear device identification and that meet the preset minimum length threshold.

[0084] The source device identifier is extracted from the header fields of the message link layer or application layer. If multiple identifiers exist, the ID with unique authentication attributes will be selected first.

[0085] The target address includes at least one of an IP address or a MAC address, used for subsequent routing decisions; the transport layer protocol type is determined by parsing the transport layer header feature bits and is marked as a TCP, UDP, or TLS encrypted stream.

[0086] For encrypted transmission streams, protocol association records are made based on port numbers and traffic behavior patterns without decryption.

[0087] It should be noted that the communication management node is deployed on an edge computing device or gateway close to the data source, and its capture mechanism operates without affecting the original communication link, ensuring that it does not intrude on the normal communication behavior of IoT devices.

[0088] Setting a minimum length threshold can effectively filter noisy packets and probe packets, improving the accuracy of subsequent protocol identification.

[0089] For messages that do not carry a clear device identifier, the system temporarily stores them and triggers a device registration query process. Once the identity is confirmed, they are included in the management scope, thereby ensuring the integrity and security of communication management.

[0090] S2. Based on the structural features and communication context of the original message, identify the application layer protocol used, extract the operation intent contained in the original message, and generate a standardized semantic feature vector.

[0091] Furthermore, the original message is scanned by byte sequence to obtain the field separator type, total message length, function code occurrence position, and parameter encoding method;

[0092] Monitor the periodicity, request-response pattern, and transport layer protocol behavior characteristics of the communication session to which the monitoring message belongs;

[0093] By combining the communication port number with the TLS handshake fingerprint information, it can be determined whether there is a behavioral pattern that matches a known protocol;

[0094] When the degree of matching between the detected structural features and the pre-stored protocol behavior template exceeds a set threshold, the original message is determined to be the corresponding application layer protocol.

[0095] Invoke semantic parsing rules that match the identified protocol type to extract the operation action, target, and parameter value from the message;

[0096] The extracted operation actions are mapped to verb tags in a unified semantic space, the objects of action are mapped to device category tags, and the parameter values ​​retain their dimensional attributes, forming a standardized semantic feature vector;

[0097] It should be noted that the protocol behavior template library pre-stores the typical structural features and interaction modes of mainstream IoT protocols such as MQTT, CoAP, Modbus, HTTP, and BACnet, and supports incremental updates to adapt to new protocols.

[0098] The semantic parsing rules correspond one-to-one with the protocol types, and the pluggable design facilitates expansion.

[0099] The generation process of standardized semantic feature vectors does not depend on the complete message decoding and can infer key operational intentions based on confidence when some fields are missing or the format is abnormal.

[0100] S3. Based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, determine the initial compatibility score between the protocols, and construct a communication topology map by combining the real-time latency of the network link and the node resource status.

[0101] Furthermore, obtain the standardized semantic feature vectors of all reachable target protocols in the network, denoted as... ,in Indicates the first One target agreement;

[0102] The standardized semantic feature vector of the source protocol is denoted as... Its components in the three dimensions of operation type, target object, and parameter format are respectively denoted as: ;

[0103] Target Protocol The three dimensional components are denoted as ;

[0104] Calculate the normalized difference between the source protocol and the target protocol across all dimensions. The expression is:

[0105] ;

[0106] For difference values We perform a weighted summation to obtain the overall difference. The expression is:

[0107] ;

[0108] in , , These are the weighting coefficients;

[0109] Convert the overall difference score into an initial compatibility score. The expression is:

[0110] ;

[0111] The initial compatibility score is a value between 0 and 1, with a higher value indicating that the semantics between the protocols are more similar.

[0112] It should be noted that the quantization processing of the three dimensions of operation type, target object, and parameter format is completed based on a unified semantic dictionary to ensure that the feature values ​​of different protocols are comparable.

[0113] Weighting coefficient , , Configurations are configured according to the application scenario. For example, in control communication, the difference in operation type has a higher weight, while in data reporting scenarios, the consistency of parameter format is more critical.

[0114] The constructed communication topology uses protocol type as nodes and compatibility score as edge attributes, combined with physical link status to form a multi-dimensional path evaluation basis, providing structural support for subsequent dynamic optimization.

[0115] S4. Continuously record the communication execution results of different protocols on each node, generate dynamic memory factors based on the changing trends of the execution results, and use the dynamic memory factors to correct the initial compatibility score to obtain the evaluation results.

[0116] Furthermore, upon completion of each agreement... To the agreement After the conversion operation, record the conversion success status of this communication. Deviation between actual delay and expected delay and resource consumption volatility ;

[0117] For the same protocol In recent The execution results of each communication are used to create a time series set;

[0118] Calculate the stability index of recent communication performance , , The expression is:

[0119] ;

[0120] right , , The three stability metrics are weighted and fused to obtain the base memory value. The expression is:

[0121] ;

[0122] in, , , These are the weighting coefficients;

[0123] By introducing a time decay factor and performing exponential smoothing on historical data, a dynamic memory factor is generated. The expression is:

[0124] ;

[0125] Dynamic memory factor It reflects the stability of the cooperation formed in actual operation by the agreement;

[0126] Dynamic memory factors Compared with the initial compatibility score Nonlinear coupling operations are performed to obtain empirically enhanced compatibility evaluation results. The expression is:

[0127] ;

[0128] in, To adjust the gain coefficient, The memory activation threshold;

[0129] when > When the evaluation results are positively reinforced, it indicates that the agreement has a good history of collaborative performance;

[0130] when ≤ At that time, the evaluation results remain unchanged or slightly decrease, avoiding over-reliance on unstable paths;

[0131] It should be noted that the introduction of dynamic memory factors enables the system to continuously learn from historical communication experience, avoiding misjudgments caused by relying solely on static semantic analysis.

[0132] Time decay factor Ensure that recent communication performance has a greater impact on the evaluation results, enabling the system to respond quickly to changes in the network environment or node status;

[0133] The nonlinear coupling mechanism achieves a balance between trust accumulation and risk aversion by setting a memory activation threshold η, preventing excessive trust in unstable paths due to accidental success, and improving the reliability and stability of path decision-making.

[0134] S5. Update the edge weights in the communication topology graph based on the evaluation results, and determine the optimal transmission path from the source node to the target node based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost.

[0135] Furthermore, the experience-enhanced compatibility assessment results are mapped to the semantic transformation cost in the path hopping process, and combined with the real-time measured link latency, bandwidth utilization, and CPU and memory usage of the next hop node to form dynamic edge weights.

[0136] A normalization module is introduced during the weight calculation process to eliminate the dimensional differences between indicators of different dimensions.

[0137] Based on the updated topology graph, an improved Dijkstra algorithm is used to search for the shortest path, where the priority queue is sorted based on the minimum cumulative comprehensive cost.

[0138] During the path generation process, if there are multiple equivalent paths, the historical communication success rates of each path are further compared and the optimal one is selected.

[0139] The output includes a complete sequence of hop nodes and a communication path scheme for each hop's corresponding protocol type.

[0140] It should be noted that the comprehensive communication cost covers multiple dimensions such as semantic conversion cost, transmission delay, and resource consumption. After normalization, each indicator is linearly weighted to form a side weight with a unified dimension, ensuring fair comparison in the path search process.

[0141] The improved Dijkstra algorithm supports path optimization under multiple constraints and adds path lifecycle and re-evaluation trigger conditions to the path output for dynamic adjustment in subsequent communication processes.

[0142] The path determination mechanism not only focuses on the current optimal state, but also has the ability to adapt to future state changes.

[0143] S6. At each hop conversion node of the optimal transmission path, check whether there is a functional module for processing the next hop protocol. If not, dynamically load the corresponding lightweight virtualization protocol container, parse the input message into a unified semantic representation, reconstruct the output message according to the format specification of the target protocol, and complete the cross-protocol data forwarding.

[0144] Furthermore, a local protocol container registry is maintained at each hop conversion node to record the currently loaded protocol types and their corresponding functional module instances;

[0145] When a request is received that needs to be forwarded to the target protocol When receiving a message, check the registry to confirm if a message related to the protocol exists. Matching registered modules;

[0146] If no match is found, a download request is sent to the distributed protocol container repository to obtain the protocol. The corresponding WebAssembly format container file;

[0147] Digital signature verification is performed on container files to confirm their legitimate origin, and integrity verification is performed to ensure that the files have not been tampered with or damaged.

[0148] The verified container file is injected into the lightweight runtime environment, and its internal protocol parsing and conversion logic is initialized.

[0149] Add a new entry to the local registry, tagging the protocol. The functional modules are in an available state;

[0150] The parser corresponding to the source protocol is invoked to decode the input message into an internally unified semantic triple. ,in, Indicates the main equipment identification. Indicates an operation action. Indicates the target object;

[0151] Query the field mapping rule base of the target protocol to obtain actions. Corresponding function code in the target protocol Object The field address and parameter encoding format;

[0152] Construct the original byte sequence based on the message structure template of the target protocol;

[0153] function code Write the specified position in the message header, write the object address to the address field, and fill the data segment with the parameter values ​​after serializing them according to the encoding format;

[0154] Add the timestamp and transaction identifier of the original communication to form a complete output message;

[0155] The output message is sent to the next-hop node, completing cross-protocol data forwarding;

[0156] It should be noted that the lightweight virtualization protocol container is implemented using WebAssembly technology, which has cross-platform operation capabilities and strong isolation, and the loading process does not require restarting the node service;

[0157] The protocol parsing and field mapping rule base supports dynamic updates to adapt to protocol version evolution;

[0158] When reconstructing output messages, the original timestamp and transaction identifier are preserved to ensure the traceability and context consistency of end-to-end communication;

[0159] The entire conversion process ensures security while achieving high-efficiency, low-latency cross-protocol data transfer.

[0160] This embodiment also provides a multi-protocol-adaptive IoT device communication management system, including:

[0161] The module includes a message capture module, a protocol identification module, a topology construction module, a memory evaluation module, a path planning module, and a conversion execution module.

[0162] The message capture module is used to capture the original message sent by the source device when the IoT device initiates a communication request. The communication management node deployed on the edge listens to the network interface, captures the original message, and obtains the source device identifier, destination address and transport layer protocol type of the original message.

[0163] The protocol identification module is used to identify the application layer protocol used based on the structural characteristics and communication context of the original message, extract the operation intent contained in the original message, and generate a standardized semantic feature vector.

[0164] The topology construction module is used to determine the initial compatibility score between protocols based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, and to construct a communication topology graph by combining the real-time latency of network links and the status of node resources.

[0165] The memory evaluation module is used to continuously record the communication execution results of different protocol pairs on each node, generate dynamic memory factors based on the changing trends of the execution results, and use the dynamic memory factors to correct the initial compatibility score to obtain the experience-enhanced compatibility evaluation result.

[0166] The path planning module is used to update the edge weights in the communication topology graph based on the evaluation results, and determine the optimal transmission path from the source node to the target node based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost.

[0167] The conversion execution module is used to check whether the next-hop protocol processing module is available at each conversion node of the optimal transmission path. If not, the corresponding lightweight virtualized protocol container is dynamically loaded, the input message is parsed into a unified semantic representation, and the output message is reconstructed according to the format specification of the target protocol to complete cross-protocol data forwarding.

[0168] This embodiment also provides a computer device applicable to the communication management method for IoT devices with multi-protocol adaptation, 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 communication management method for IoT devices with multi-protocol adaptation as proposed in the above embodiment.

[0169] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0170] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the IoT device communication management method for multi-protocol adaptation as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0171] In summary, this invention achieves a unified representation of multi-protocol operational intentions by constructing standardized semantic feature vectors. It also enhances the initial protocol compatibility score by combining dynamic memory factors generated based on historical communication performance. This effectively overcomes the technical shortcomings of traditional methods that rely solely on static syntax matching, which leads to insufficient adaptability. Furthermore, by introducing a dynamically loadable lightweight virtualized protocol container mechanism, it enables on-demand expansion of protocol functions at edge nodes, improving the system's flexibility and resource utilization efficiency in heterogeneous IoT environments. The dynamic optimization method for communication topology takes into account semantic consistency, network status, and historical operating trends, giving path planning self-learning and adaptive characteristics, thereby improving the success rate and overall performance of cross-protocol communication.

[0172] 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, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for managing communication of IoT devices with multi-protocol adaptation, characterized in that: include: When an IoT device initiates a communication request, the communication management node deployed at the edge captures the original message sent by the source device and obtains the source device identifier, destination address, and transport layer protocol type of the original message. Based on the structural features and communication context of the original message, the application layer protocol used is identified, and the operation intent contained in the original message is extracted to generate a standardized semantic feature vector. Based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, the initial compatibility score between the protocols is determined, and a communication topology is constructed by combining the real-time latency of the network link and the node resource status. The system continuously records the communication execution results of different protocols on each node, generates dynamic memory factors based on the changing trends of the execution results, and uses the dynamic memory factors to correct the initial compatibility score to obtain the evaluation result. The edge weights in the communication topology graph are updated based on the evaluation results, and the optimal transmission path from the source node to the target node is determined based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost. At each hop transition node of the optimal transmission path, check whether it has a functional module for processing the next-hop protocol. If not, dynamically load the corresponding lightweight virtualized protocol container, parse the input message into a unified semantic representation, reconstruct the output message according to the format specification of the target protocol, and complete the cross-protocol data forwarding.

2. The multi-protocol adapted IoT device communication management method as described in claim 1, characterized in that: The steps for identifying the application layer protocol used based on the structural characteristics and communication context of the original message, extracting the operational intent contained in the original message, and generating a standardized semantic feature vector are as follows: Perform a byte sequence scan on the original message to obtain the field separator type, total message length, function code occurrence position, and parameter encoding method; Monitor the periodicity, request-response pattern, and transport layer protocol behavior characteristics of the communication session to which the monitoring message belongs; By combining the communication port number with the TLS handshake fingerprint information, it can be determined whether there is a behavioral pattern that matches a known protocol; When the degree of matching between the detected structural features and the pre-stored protocol behavior template exceeds a set threshold, the original message is determined to be the corresponding application layer protocol. Invoke semantic parsing rules that match the identified protocol type to extract the operation action, target, and parameter value from the message; The extracted operation actions are mapped to verb tags in a unified semantic space, the objects of action are mapped to device category tags, and the parameter values ​​retain their dimensional attributes, forming a standardized semantic feature vector.

3. The multi-protocol adapted IoT device communication management method as described in claim 2, characterized in that: The initial compatibility score among protocols is determined based on the degree of difference between the standardized semantic feature vector and the semantic feature vectors of other protocols. Specifically: Obtain the standardized semantic feature vectors of all reachable target protocols in the network, denoted as... ,in Indicates the first One target agreement; The standardized semantic feature vector of the source protocol is denoted as... Its components in the three dimensions of operation type, target object, and parameter format are respectively denoted as: ; Target Protocol The three dimensional components are denoted as ; Calculate the normalized difference between the source protocol and the target protocol across all dimensions. The expression is: ； For difference values We perform a weighted summation to obtain the overall difference. The expression is: ； in , , These are the weighting coefficients; Convert the overall difference score into an initial compatibility score. The expression is: ; The initial compatibility score is a value between 0 and 1, with a larger value indicating that the semantics between the protocols are closer.

4. The multi-protocol-adaptive IoT device communication management method as described in claim 3, characterized in that: The process of continuously recording the communication execution results of different protocols on each node and generating a dynamic memory factor based on the changing trend of the execution results is as follows: Each time the protocol is completed To the agreement After the conversion operation, record the conversion success status of this communication. Deviation between actual delay and expected delay and resource consumption volatility ; For the same protocol In recent The execution results of each communication are used to create a time series set; Calculate the stability index of recent communication performance , , The expression is: ; right , , The three stability metrics are weighted and fused to obtain the base memory value. The expression is: ； in, , , These are the weighting coefficients; By introducing a time decay factor and performing exponential smoothing on historical data, a dynamic memory factor is generated. The expression is: ; The dynamic memory factor This reflects the stability of the collaboration formed in actual operation by the agreement.

5. The multi-protocol-adaptive IoT device communication management method as described in claim 4, characterized in that: The initial compatibility score is corrected using a dynamic memory factor to obtain the evaluation result, specifically as follows: The dynamic memory factor Compared with the initial compatibility score Nonlinear coupling operations are performed to obtain empirically enhanced compatibility evaluation results. The expression is: ; in, To adjust the gain coefficient, The memory activation threshold; when > When the evaluation results are positively reinforced, it indicates that the agreement has a good history of collaborative performance; when ≤ At that time, the evaluation results remain unchanged or slightly decay, avoiding over-reliance on unstable paths.

6. The multi-protocol adapted IoT device communication management method as described in claim 5, characterized in that: At each hop transition node of the optimal transmission path, it is checked whether a functional module for processing the next-hop protocol is available. If not, the corresponding lightweight virtualized protocol container is dynamically loaded. Specifically: At each hop transition node, a local protocol container registry is maintained to record the currently loaded protocol types and their corresponding functional module instances. When a request is received that needs to be forwarded to the target protocol When a message is received, the registry is queried to confirm whether a message related to the protocol exists. Matching registered modules; If no match is found, a download request is sent to the distributed protocol container repository to obtain the protocol. The corresponding WebAssembly format container file; Digital signature verification is performed on container files to confirm their legitimate origin, and integrity verification is performed to ensure that the files have not been tampered with or damaged. The verified container file is injected into the lightweight runtime environment, and its internal protocol parsing and conversion logic is initialized. Add a new entry to the local registry, tagging the protocol. The functional modules are available.

7. The multi-protocol-adaptive IoT device communication management method as described in claim 6, characterized in that: The step of parsing the input message into a unified semantic representation and reconstructing the output message according to the format specification of the target protocol specifically includes: The parser corresponding to the source protocol is invoked to decode the input message into an internally unified semantic triple. ,in, Indicates the main equipment identification. Indicates an operation action. Indicates the target object; Query the field mapping rule base of the target protocol to obtain actions. Corresponding function code in the target protocol Object The field address and parameter encoding format; Construct the original byte sequence based on the message structure template of the target protocol; function code Write the specified position in the message header, write the object address to the address field, and fill the data segment with the parameter values ​​after serializing them according to the encoding format; Add the timestamp and transaction identifier of the original communication to form a complete output message; The output message is sent to the next-hop node to complete cross-protocol data forwarding.

8. A multi-protocol-adaptive IoT device communication management system, based on the multi-protocol-adaptive IoT device communication management method according to any one of claims 1 to 7, characterized in that: include: The module includes a message capture module, a protocol identification module, a topology construction module, a memory evaluation module, a path planning module, and a conversion execution module. The message capture module is used to capture the original message sent by the source device when the IoT device initiates a communication request. The communication management node deployed on the edge side listens to the network interface, captures the original message, and obtains the source device identifier, destination address and transport layer protocol type of the original message. The protocol identification module is used to identify the application layer protocol used based on the structural features and communication context of the original message, extract the operation intent contained in the original message, and generate a standardized semantic feature vector. The topology construction module is used to determine the initial compatibility score between protocols based on the degree of difference between the standardized semantic feature vector and the semantic feature vector of other protocols, and to construct a communication topology graph by combining the real-time latency of the network link and the node resource status. The memory evaluation module is used to continuously record the communication execution results of different protocol pairs on each node, generate dynamic memory factors based on the changing trends of the execution results, and use the dynamic memory factors to correct the initial compatibility score to obtain an experience-enhanced compatibility evaluation result. The path planning module is used to update the edge weights in the communication topology graph according to the evaluation results, and determine the optimal transmission path from the source node to the target node based on the updated topology graph. The optimal transmission path is the path sequence with the lowest overall communication cost. The conversion execution module is used to check whether the next-hop protocol processing module is available at each conversion node of the optimal transmission path. If not, the corresponding lightweight virtualized protocol container is dynamically loaded, the input message is parsed into a unified semantic representation, and the output message is reconstructed according to the format specification of the target protocol to complete cross-protocol data forwarding.

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 multi-protocol adapted IoT device communication management 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 the processor, it implements the steps of the multi-protocol adapted IoT device communication management method according to any one of claims 1 to 7.

Images