Data transmission method and system of multi-protocol Internet of Things central platform

Abstract

The invention relates to the field of data transmission, in particular to a data transmission method and system of a multi-protocol Internet of Things central platform. The method comprises the following steps: collecting communication data streams of various terminal devices, and carrying out transmission priority planning on the communication data streams to obtain various data priorities; performing data encapsulation on the communication data stream to obtain a data encapsulation packet; identifying a plurality of available transmission paths accessed by the Internet of Things central platform and performing transmission load evaluation to obtain a transmission evaluation value of each path; and carrying out data packet transmission adaptation and multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation values of the paths. According to the invention, data transmission with high reliability and high resource utilization rate is realized, and the data transmission success rate of the multi-protocol Internet of Things is improved.

Description

Technical Field

[0001] This invention relates to the field of data transmission, and more particularly to a data transmission method and system for a multi-protocol Internet of Things (IoT) hub platform. Background Technology

[0002] The communication data received by the IoT central platform are complex and diverse, with significant differences in real-time performance, reliability, and importance among data generated by different terminal devices. Control command data and alarm data typically have high requirements for transmission latency and reliability, while log recording or statistical analysis data have relatively lower real-time requirements. However, existing technologies often use a uniform transmission method to process all data, lacking effective differentiation and priority management for different data services. This can easily lead to delays or loss of critical business data under network congestion, affecting the overall operational efficiency and security of the system.

[0003] As the scale of IoT applications continues to expand, the network environment faced by central platforms is becoming increasingly complex. Existing IoT central platforms typically possess multiple network access methods, forming multiple usable transmission paths. However, in practical applications, most systems still use a single or fixed path for data transmission, failing to fully utilize multi-path network resources. Current technologies generally lack effective mechanisms for evaluating the real-time load status of each transmission path, leading to continued data transmission to a path even when bandwidth is insufficient, latency is increased, or link congestion occurs, further exacerbating transmission performance degradation. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a data transmission method and system for a multi-protocol Internet of Things (IoT) hub platform, thereby resolving at least one of the aforementioned technical issues.

[0005] To achieve the above objectives, the present invention provides a data transmission method for a multi-protocol Internet of Things (IoT) hub platform, comprising the following steps: Step S1: Collect communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types; Step S2: Encapsulate the communication data stream to obtain a data encapsulation packet; Step S3: Identify multiple available transmission paths accessed by the IoT central platform and perform transmission load assessment to obtain the transmission assessment value for each path; Step S4: Adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

[0006] This specification provides a data transmission system for a multi-protocol IoT hub platform, used to execute the data transmission method for a multi-protocol IoT hub platform as described above, including: The acquisition unit is used to acquire communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types. An encapsulation unit is used to encapsulate the communication data stream to obtain a data encapsulation packet; The evaluation unit identifies multiple available transmission paths accessed by the IoT central platform and performs transmission load evaluation to obtain transmission evaluation values ​​for each path. The adaptation unit is used to adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

[0007] The specific benefits of this invention are as follows: IoT hub platforms typically connect to multiple terminal devices supporting different communication protocols (such as MQTT, CoAP, HTTP, and proprietary protocols). By uniformly collecting communication data streams from various terminals, management fragmentation caused by protocol differences can be eliminated, laying the foundation for subsequent centralized scheduling. Clearly defining data priorities avoids low-value, high-volume data consuming excessive transmission resources, allowing network bandwidth and transmission capacity to more rationally serve high-value services, improving overall system throughput and service quality. Unified data encapsulation processing of data from different sources and using different protocols converts raw communication data into standardized data packages, freeing the hub platform from concern itself with specific protocol details at the transmission layer, thus enhancing multi-protocol integration capabilities. During data encapsulation, metadata such as priority identifiers, device identifiers, timestamps, and verification information can be attached, facilitating subsequent scheduling, verification, and anomaly handling, while also providing a carrier for security mechanisms such as encryption and authentication. IoT hub platforms often possess multiple transmission channels (such as wired networks, cellular networks, and private network links). By identifying multiple available transmission paths, over-reliance on a single path can be avoided, improving overall system availability. By evaluating the bandwidth, latency, packet loss rate, and load of each path, a path transmission evaluation value is obtained, enabling the platform to monitor the transmission capacity and health status of each path in real time. Through multi-path parallel transmission, data can be automatically diverted or switched to other paths when congestion or failure occurs on one path, significantly reducing the risk of data loss and transmission interruption. Multi-path parallel transmission overcomes the bandwidth limitations of single links, allowing the IoT hub platform to maintain high data processing capabilities and response speeds even in high-concurrency, large-scale terminal access scenarios. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating the steps of a data transmission method for a multi-protocol IoT hub platform according to the present invention. Figure 2 This is a detailed flowchart illustrating the implementation steps of step S1. Figure 3 This is a flowchart illustrating the detailed implementation steps of step S2. Detailed Implementation

[0009] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0010] This application provides a data transmission method and system for a multi-protocol IoT hub platform. The execution entities of the data transmission method and system for the multi-protocol IoT hub platform include, but are not limited to, mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc., which can be considered as general computing nodes in this application. The data processing platform includes, but is not limited to, at least one of an audio / image management system, an information management system, and a cloud-based data management system.

[0011] Please see Figures 1 to 3 This invention provides a data transmission method for a multi-protocol IoT hub platform, comprising the following steps: Step S1: Collect communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types; Step S2: Encapsulate the communication data stream to obtain a data encapsulation packet; Step S3: Identify multiple available transmission paths accessed by the IoT central platform and perform transmission load assessment to obtain the transmission assessment value for each path; Step S4: Adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

[0012] In the embodiments of the present invention, see Figure 1 This is a flowchart illustrating the steps of a data transmission method for a multi-protocol IoT hub platform according to the present invention. In this example, the steps of the data transmission method for the multi-protocol IoT hub platform include: Step S1: Collect communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types; In this embodiment, communication data streams generated by various connected terminal devices are collected in real time, including periodic sensor data, event-triggered control commands, and alarm data. The collected data streams are organized by session dimension and appended with high-precision timestamps for subsequent time-series analysis in priority planning. Next, transmission priority planning is performed on the data streams based on the real-time effective value of each type of data. Real-time effective value indicators include data generation frequency, service triggering dependencies, data timeliness decay rate, and historical usage feedback. Priority is typically divided into three levels: high, medium, and low. High priority corresponds to emergency alarms and control commands, medium priority corresponds to periodic status reporting, and low priority corresponds to long-term monitoring data or logs. During the planning process, a priority decay timestamp mechanism is considered; for example, high-priority data maintains the highest priority for 5 seconds after generation, while medium-priority data gradually decreases in priority over 10 seconds.

[0013] Step S2: Encapsulate the communication data stream to obtain a data encapsulation packet; In this embodiment, various communication data streams undergo data encapsulation processing. The encapsulation process first performs necessary fragmentation on the data stream, dividing the original data into data fragments suitable for transmission. The fragment size can be set between 1KB and 5KB to balance transmission efficiency and network load. For high-priority data, a small number of redundant fragments can be generated to improve reliability, while redundancy can be reduced for low-priority data to conserve network resources. Subsequently, necessary identification information is attached to each data fragment, including data stream identifier, fragment sequence number, total number of fragments, priority level, and verification information, enabling the data packet to be independently identified and reassembled at the receiving end. After data encapsulation, each data stream forms several data encapsulation packets, the size, number, and redundancy ratio of which are dynamically adjusted according to data priority and real-time validity value. Alarm data packets can generate two redundant fragments, while periodic status data can remain without redundancy or generate only one redundant fragment.

[0014] Step S3: Identify multiple available transmission paths accessed by the IoT central platform and perform transmission load assessment to obtain the transmission assessment value for each path; In this embodiment, multiple transmission paths available to the central platform are identified, including wired Ethernet links, wireless LTE / 5G links, and low-power wide area networks. Each path records its origin and destination nodes, link bandwidth, path length, and number of intermediate nodes to construct a path information table. Subsequently, network status detection is performed on each path, including link bandwidth utilization (e.g., 0%~100%), real-time network load (queue length, forwarding pressure), link reliability indicators (packet loss rate and outage probability), and terminal node energy consumption status (remaining energy percentage). Based on these status parameters, path performance characteristics, such as data throughput elasticity, latency stability, and failure recovery capability, are further calculated to obtain a comprehensive path transmission evaluation value. The evaluation value is represented in the range of 0~1, where paths with a value higher than 0.8 are high-performance paths capable of carrying high-priority data, medium-performance paths are 0.5~0.8, and low-performance paths are below 0.5.

[0015] Step S4: Adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

[0016] In this embodiment, the data packets to be transmitted are encapsulated and load-adapted, distributing the data packets to different paths according to their carrying capacity. The allocation principle is to allocate 50%~60% of the load to paths with high evaluation values, 25%~30% to paths with medium evaluation values, and 10%~15% to paths with low evaluation values, while ensuring that high-priority data is transmitted first. After adaptation, multi-path parallel transmission is initiated. Each path can send multiple data packets in parallel within a unit time window (e.g., 1 second), the number of which is limited by bandwidth and load. For example, a 10Mbps path can send 8~10 fragmented packets, and a 5Mbps path can send 3~4 fragmented packets. During transmission, the transmission time, path, transmission status, and acknowledgment status of each data packet are tracked and recorded to form real-time transmission monitoring data.

[0017] In this embodiment, see Figure 2 The diagram below illustrates the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: Collect communication data streams from various terminal devices, perform communication behavior analysis and feature clustering on the communication data streams, and construct a protocol behavior feature pool; Based on the protocol behavior feature pool, data value is deconstructed for each category to obtain the real-time effective value of each category of data. Define priority decay timestamps and perform transmission priority planning based on the real-time effective value to obtain the priorities of various data types.

[0018] In this embodiment, communication data streams generated by various terminal devices accessing the platform are continuously collected. The collected data includes periodically reported data, event-triggered data, and control interaction data. The collected communication data streams are organized according to session dimensions and arranged chronologically to form a complete sequence of communication behaviors. Based on this, communication behavior analysis is performed on the communication data streams, extracting behavioral features from multiple dimensions such as time characteristics, interaction patterns, and load changes. These features include message sending interval distribution, request-response ratio, continuous connection duration, and burst communication characteristics. Subsequently, the analyzed multi-dimensional behavioral features are normalized to eliminate differences in dimensions and scales between different protocols. Through similarity analysis of a large number of communication behavior features, data with similar communication patterns and behavioral regularities are grouped into the same category, completing feature clustering. The clustering results are used to characterize typical communication behavior patterns of different protocols in actual operation, forming a structured protocol behavior feature pool. Based on the sending rhythm and interaction frequency recorded in the protocol behavior feature pool, the activity level of data within a unit of time is assessed. Combining the triggering relationship between data and subsequent actions or business responses in communication behavior, the criticality of data in the business process is determined. A time factor is introduced to analyze the effective time span of data since its generation, distinguishing between short-term high-value data and long-term reference data. These value factors are integrated through weighted allocation, and the weights of different factors can be adjusted according to the application scenario; for example, increasing the timeliness weight for alarm data and the continuity weight for status data. An initial priority level is defined for each type of data, and a corresponding priority decay timestamp is set to describe the natural decline in data value over time. The priority decay timestamp reflects the characteristic that the urgency of data transmission gradually decreases after a specific time point. Different decay rates can be set for different types of data; for example, a shorter decay period is used for time-sensitive data, while a longer decay period is used for status monitoring data. During priority planning, the real-time effective value is combined with the current time point to dynamically adjust the initial priority, enabling the data priority to be automatically updated over time.

[0019] In this embodiment, the specific steps for collecting communication data streams from various terminal devices, performing communication behavior analysis and feature clustering on the communication data streams, and constructing a protocol behavior feature pool are as follows: Real-time acquisition of communication data streams from various terminal devices based on an IoT central platform; The communication data stream is subjected to message protocol identification to obtain various communication protocols; Based on various communication protocols, communication behavior is analyzed, and the protocol frame sending rhythm, handshake interaction response delay, retransmission probability, data load burst characteristics, and link jitter spectrum are extracted to obtain a set of behavioral features. The behavioral feature set is clustered and statistically summarized to construct a protocol behavior feature pool.

[0020] In this embodiment, within the multi-protocol IoT hub platform, a communication data acquisition mechanism is deployed at the network access layer and edge aggregation locations to continuously acquire communication data streams from various terminal devices. The acquisition process is conducted via bypass monitoring or data mirroring, without participating in service forwarding; it only copies and records uplink and downlink communication between the terminal and the platform. The acquisition scope covers various terminal forms and communication links, including wired and wireless access methods, ensuring that communication behavior in different application scenarios can be fully perceived. The acquired communication data is organized according to the session dimension, distinguishing data streams by source address, destination address, port information, and transport layer protocol. A high-precision time stamp is added to each message to ensure the accuracy of subsequent timing analysis. To balance real-time processing and data integrity, the communication data stream is cached and organized according to fixed time windows, enabling continuous messages to form complete communication segments. Abnormal traffic characteristics occurring during communication, such as burst traffic and frequent connection establishment, are marked for targeted analysis in subsequent steps. After completing the communication data stream acquisition, the messages in the data stream are identified to determine the actual communication protocol type used. Because the IoT environment involves the mixed use of various standard and proprietary protocols, protocol identification does not rely on port numbers or manual configuration. Instead, it is based on a comprehensive judgment of message structure characteristics and communication interaction patterns. During the identification process, several consecutive messages are selected from the communication data stream, and information such as message length distribution, key field arrangement characteristics, first byte patterns, and request / response direction sequences are extracted. This information is then combined with behavioral characteristics such as the presence of a fixed handshake process and message exchange ratios during communication. For communication patterns with clearly defined characteristics, they can be directly matched with known protocol characteristics. For communication patterns with significant characteristic variations, their protocol category is determined through feature similarity. Communication data streams that cannot be classified are uniformly identified as unknown protocol types.

[0021] After determining the protocol type, the communication process is analyzed at the behavioral level, taking into account the interaction methods and communication patterns of different communication protocols. This step starts with the overall communication process, dividing the communication session into stages such as connection establishment, data transmission, maintenance interaction, and anomaly handling, and extracting key behavioral indicators reflecting communication characteristics within each stage. Specifically, these include protocol frame transmission rhythm, which describes the periodicity or irregularity of data reporting by statistically analyzing the time interval between adjacent messages; handshake interaction response latency, which characterizes interaction efficiency by calculating the time difference between the request and the corresponding response; retransmission probability, which reflects link reliability by identifying duplicate message characteristics; data load burst characteristics, which describes load fluctuations by analyzing changes in data volume per unit time; and link jitter spectrum, which characterizes communication stability by performing frequency domain analysis on the message time interval sequence. After obtaining the behavioral feature sets corresponding to various communication protocols, these features are further clustered and summarized to construct a protocol behavioral feature pool. This step performs similarity analysis on the behavioral features of a large number of communication sessions, grouping features with similar communication behavior patterns into the same category, thereby extracting the typical behavioral performance of different protocols under different operating conditions. During clustering, multiple dimensions such as transmission rhythm, delay distribution, retransmission characteristics, and jitter are comprehensively considered to ensure that the clustering results accurately reflect the overall characteristics of communication behavior. After clustering, statistical analysis is performed on each category of behavioral features to extract its representative feature range, mean level, and variation interval, forming a stable behavioral description model. These models are uniformly summarized and stored to form a protocol behavioral feature pool, used to describe and compare the behavioral characteristics of different communication protocols.

[0022] In this embodiment, the step of performing data value deconstruction based on the protocol behavior feature pool to obtain the real-time effective value of each data category specifically involves: The real-time effective value includes data generation frequency, data timeliness decay rate, business triggering dependencies, and historical usage feedback. The difference between high-frequency sensor data and low-frequency control commands is calculated based on the protocol behavior feature pool to obtain the data generation frequency. Based on the communication data stream, the influence weight of upstream data on downstream services is calculated to obtain the service triggering dependency relationship; Compare the protocol behavior feature pool with slow data decay and rapid alarm information expiration to generate data timeliness decay rate; The call frequency is calculated based on the communication data stream; Historical usage feedback is determined based on the frequency of the calls.

[0023] In this embodiment, the communication sessions corresponding to each protocol in the behavior feature pool are statistically analyzed to extract indicators such as the number of data reports per unit time, message interval distribution, and periodic stability. For sensor protocols, the data reporting pattern is usually fixed or quasi-periodic, and the data generation frequency can be measured by averaging the number of messages within a continuous time window. For control or command protocols, the event-driven characteristics are more prominent, and the data generation frequency is described by detecting the time point and trigger interval of sudden message occurrences. To ensure the stability of the calculation results, the frequency statistics adopt a multi-window overlay method, for example, simultaneously considering the generation frequency at 1-second, 5-second, and 30-second scales to eliminate the impact of short-term fluctuations. By comparing and analyzing the differences in frequency distribution, variation amplitude, and duration between high-frequency sensor data and low-frequency control commands, a data generation frequency index is formed. The flow relationship of data is identified from the communication data stream, distinguishing data generation nodes, data relay nodes, and business processing nodes, and constructing a time-sequence-based call association link. By analyzing the occurrence frequency, time sequence, and call order of different data streams before and after business triggering, the degree of influence of upstream data on downstream business behavior is determined. The specific approach involves calculating the probability of downstream business requests or control commands being triggered within a set time window after a certain type of data appears, and using this probability as an initial influencing factor. Combined with trigger latency characteristics, data that directly triggers business actions within a short timeframe is assigned higher weight, while data with longer latency or indirect correlation is assigned lower weight. By cumulatively analyzing multiple business links, a stable distribution of influence weights is formed.

[0024] Based on the communication behaviors recorded in the protocol behavior feature pool, the data is divided into different categories such as status data, trend data, and event data. Status and trend data typically have a longer validity period, with their value slowly decaying over time; while alarm and anomaly data have obvious immediacy characteristics, with their effective value rapidly decreasing in a short period. For different data categories, the proportion of data accessed, referenced, or triggering subsequent behaviors at different time points after generation is statistically analyzed, and a time-related decay curve is constructed accordingly. By comparing the slope of value change for different data types within the same time span, the corresponding data time-related decay rate parameter is obtained. Communication data streams are continuously monitored, recording the number of times data is requested, subscribed to, forwarded, or referenced, and cumulatively statistically analyzed in chronological order. Call frequency considers not only the number of single accesses but also the continuity and periodicity of accesses. Data frequently accessed within a fixed time window has a higher call frequency weight than data accessed only occasionally. Data from different protocols and different business types are statistically analyzed separately to avoid high-frequency protocols masking low-frequency but critical data call characteristics. By smoothing the call behavior, the impact of abnormal fluctuations in a short period of time is eliminated, so that the call frequency can stably reflect the actual usage of data.

[0025] The frequency of data calls over different time periods is accumulated to form a long-term usage curve, which is used to determine whether the data continues to be relied upon by the business. Data with consistently high call frequencies is given positive historical usage feedback, indicating its stable value in multi-protocol data transmission; data with gradually decreasing call frequencies or even long periods without access is given negative feedback, reflecting a weakening business relevance. A time decay factor is introduced to give more weight to recent call behavior in the feedback results, preventing early historical behavior from interfering with current judgments.

[0026] In this embodiment, see Figure 3 The diagram below illustrates the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: Perform content analysis on the communication data stream to extract content semantics; Data sharding requirements are analyzed based on content semantics to obtain sharding requirement characteristics; Based on the characteristics of fragmentation requirements, data streams are segmented one by one and then encapsulated to obtain multiple data packets; Multiple data packets are assigned the same data stream priority based on their respective data priorities, resulting in a data encapsulation packet with a priority label.

[0027] In this embodiment, the payload in the communication data stream is used as the analysis object. Without altering the original data structure, data fields, message type identifiers, and contextual information are parsed. For structured data, the focus is on identifying the meaning, data type, and value range of key fields. For semi-structured or unstructured data, semantic tags reflecting business meaning are extracted by analyzing field separation patterns, message template characteristics, and content frequency. In the specific implementation, content can be parsed hierarchically based on protocol characteristics, such as distinguishing between control semantics, status reporting semantics, alarm semantics, and configuration semantics. Time correlation analysis is introduced to compare the semantic changes of consecutive messages in the same data stream, avoiding semantic judgment bias caused by a single message. Through the above analysis of the communication data stream content, a stable and distinguishable semantic description of the data content is formed. This combines the business meaning of the data with transmission characteristics to determine the requirements for integrity, real-time performance, and reliability during data transmission. For data with strong semantic consistency and integrity requirements, such as control commands or configuration information, the fragmentation requirement is to minimize the number of splits and maintain the overall data transmission. However, for semantically separable and parallel-processable data, such as periodic status reports or large-volume monitoring data, fragmentation based on fixed lengths or semantic boundaries is permissible. In the specific analysis process, based on the logical unit boundaries of the semantically identified data, combined with data length distribution, field association strength, and transmission load, a suggested range for fragment size is formed. For example, the data size of a single fragment may be limited to no more than a certain byte threshold, while ensuring that semantic units are not corrupted.

[0028] Taking a single data stream as the processing object, the segmentation method is determined based on the segmentation requirements, including whether to enable segmentation, the start and end positions of segmentation, and the content range carried by each segment. During segmentation, the semantic boundaries of the content are strictly followed to avoid splitting data with strong semantic relationships into different segments. For data streams requiring segmentation, they are segmented sequentially according to a preset data volume upper limit or semantic unit size, and each segment is assigned a sequence number to ensure consistency during subsequent reassembly. After segmentation, each data segment undergoes unified data encapsulation, attaching necessary descriptive information such as the original data stream identifier, segment sequence number, total number of segments, and semantic category identifier, enabling each data packet to have independent transmission and identification capabilities. Based on the semantics of the data content, its real-time effective value, and business dependencies, a priority level is assigned to the entire data stream, and this level is synchronously marked on all data packets corresponding to that data stream. Priority division typically uses a multi-level approach, such as high, medium, and low levels, to distinguish between alarm data, control data, and routine monitoring data. In the specific calibration process, the basic priority of the data stream is first determined based on the data semantics, and then adjusted in conjunction with factors such as data generation frequency and time decay characteristics to ensure that the priority can truly reflect the urgency of data transmission. After calibration, the priority label is written into each data packet as part of the encapsulation information, so that it can be directly identified and used in subsequent transmission, scheduling, and queue management processes.

[0029] In this embodiment, the specific steps for performing data stream segmentation based on fragmentation requirements and encapsulating the data to obtain multiple data packets are as follows: The fragmentation requirements include redundancy features and fault tolerance requirements. Based on the data compressibility analysis, the compressibility of each data stream is obtained; Calculate the maximum acceptable packet loss rate based on the aforementioned fault tolerance requirement level; The encoding parameters of each data stream are dynamically adjusted based on the maximum acceptable packet loss rate and the compressibility. The communication data stream is divided into K data fragments and M redundant fragments based on the encoding parameters; Data is encapsulated from K data fragments and M redundant fragments to obtain multiple data packets.

[0030] In this embodiment, redundancy features and fault tolerance requirement levels reflect the reliability requirements of data during transmission. Redundancy features primarily describe whether data transmission success rates can be improved through additional redundant fragmentation. Their values ​​are determined comprehensively based on the semantic importance of the data, business continuity requirements, and the impact of historical data loss. Fault tolerance requirement levels quantify the tolerance of data for packet loss, out-of-order delivery, or delays during transmission. A multi-level classification is typically used, such as dividing fault tolerance requirements into high, medium, and low levels. A high level indicates extremely high requirements for data integrity, while a low level allows for a certain percentage of missing data. After clarifying the fragmentation requirement characteristics, data compressibility analysis is performed on the communication data stream to assess the space for data compression without affecting business meaning. This step quantifies the compressibility of different data streams by analyzing the redundancy of data content, the magnitude of field changes, and information entropy characteristics within the communication data stream. For periodically reported sensor data, the field structure is stable and the numerical variation range is limited, generally exhibiting high compressibility. However, for event-driven data such as control commands and alarm information, the compressibility is relatively low due to the greater content differences. During the analysis, compressibility assessment results are formed by statistically analyzing the similarity ratio between adjacent data segments, the frequency of field repetition, and the trend of data length changes. These results are expressed in the form of proportions or levels, such as dividing compressibility into intervals such as above 50%, between 20% and 50%, or below 20%.

[0031] After obtaining the fault tolerance requirement level of the data stream, it is further transformed into a quantifiable maximum acceptable packet loss rate to guide the formulation of redundant fragmentation ratios and encoding strategies. This step concretizes the abstract fault tolerance requirements into numerical constraints by establishing a mapping relationship between fault tolerance requirement levels and packet loss rates. For data with higher fault tolerance requirement levels, the maximum acceptable packet loss rate is limited to a lower range to ensure the integrity of data transmission; while for data with lower fault tolerance requirement levels, a higher proportion of data loss is allowed in exchange for higher transmission efficiency. During the calculation process, the criticality of the data in the business link, retransmission costs, and data timeliness requirements are comprehensively considered to set corresponding upper limits for packet loss rates for different levels. After clarifying the maximum acceptable packet loss rate and data compressibility, the encoding parameters of each data stream are dynamically adjusted to achieve a balance between reliability and transmission efficiency. The encoding parameters mainly include the fragmentation ratio, redundant fragmentation ratio, and data compression intensity. For data streams with high compressibility and low fault tolerance requirements, a higher compression ratio and a lower redundancy ratio can be used to reduce the overall transmission load. For data streams with low compressibility but high fault tolerance requirements, the compression level should be appropriately reduced and the proportion of redundant fragments increased to improve packet loss resistance. During the adjustment process, the maximum acceptable packet loss rate is used as a constraint to ensure that even if some fragments are lost, data recovery can still be completed through redundant fragments.

[0032] After determining the encoding parameters, the communication data stream is actually segmented according to these parameters. This step divides the original communication data stream into K data fragments sequentially based on the fragmentation ratio defined in the encoding parameters. Each data fragment carries a portion of the original data while maintaining semantic continuity. M redundant fragments are generated based on the redundancy ratio. These redundant fragments do not directly carry the original data content but are obtained through encoding calculations on the K data fragments, and are used for recovery in case of partial data fragment loss. During the segmentation process, fragment size constraints and sequential numbering rules are strictly followed to ensure that each data fragment and redundant fragment has a clear location identifier and association. After the data fragments and redundant fragments are generated, all fragments undergo unified data encapsulation to form independently transmittable data packets. During encapsulation, necessary descriptive information is appended to each data packet, including the original data stream identifier, fragment type identifier, fragment sequence number, total number of fragments, and encoding parameter summary, ensuring that each data packet has complete identification and reassembly information during transmission.

[0033] In this embodiment, step S3 includes the following steps: Identify multiple available transmission paths accessed by the IoT central platform; Network status detection is performed on the multiple available transmission paths to obtain status parameters for the multiple paths; the status parameters include link bandwidth utilization, real-time network load, link reliability index, and terminal node energy consumption status; Calculate the data throughput elasticity, latency stability, and failure recovery capability of the multiple available transmission paths to obtain the path performance characteristics; Based on the path performance characteristics and the aforementioned state parameters, the transmission load is evaluated to obtain the transmission evaluation value for each path.

[0034] In this embodiment, from the perspective of network topology and access methods, the possible communication paths between the platform and each terminal node are identified and confirmed. The identification process comprehensively considers various link types, including wired and wireless links, and independent transmission channels formed through different access gateways, different operating networks, or different physical links. For each available transmission path, its origin and destination nodes, path length, number of intermediate nodes, and network type are recorded to form a complete path description. Through continuous detection of path reachability, currently unavailable or unstable paths are eliminated to ensure that all paths included in subsequent evaluations have basic communication capabilities. The process revolves around link resource utilization and node operating status, periodically detecting key nodes and links in the path. The detection content includes link bandwidth utilization, which reflects resource usage by statistically analyzing the ratio of current data traffic to the link's rated bandwidth; real-time network load, which characterizes link congestion through comprehensive analysis of queuing length, forwarding pressure, and other indicators; link reliability indicators, which form a stability assessment by statistically analyzing historical packet loss and connection interruptions; and terminal node energy consumption status, which reflects the node's continuous operating capability by monitoring the proportion of remaining energy or the trend of power consumption changes. The aforementioned state parameters are organized in a unified dimension or normalized form to make different paths comparable.

[0035] After obtaining the state parameters of each transmission path, the overall performance of the paths is further analyzed to extract path performance characteristics reflecting their transmission capacity and stability. Data throughput elasticity describes the degree to which a path maintains data transmission capacity under load changes, measured by analyzing the relationship between bandwidth occupancy changes and actual throughput changes. Delay stability characterizes the fluctuation of path transmission delay, reflecting the path's stability by statistically analyzing the magnitude of delay changes within different time windows. Failure recovery capability assesses the path's ability to recover communication after anomalies or interruptions, described by analyzing the reconnection time and success probability after path interruption. All these performance characteristics are expressed quantitatively and corrected in conjunction with path state parameters to accurately reflect the path's performance in actual operation. By fusing path performance characteristics with state parameters, the transmission capacity of different paths is quantitatively scored. During the evaluation process, paths with low bandwidth occupancy, high throughput elasticity, and good delay stability are assigned higher evaluation values; paths with high network load, low reliability, or node energy consumption close to the threshold are appropriately downgraded in evaluation value. The various indicators are combined using a weighted approach, and the weights of different indicators can be adjusted according to the application scenario to highlight transmission requirements that are sensitive to real-time performance, reliability, or energy consumption.

[0036] In this embodiment, step S4 includes the following steps: Calculate the transmission load of the data encapsulation packet; Based on the transmission evaluation value of each path, the transmission load is adapted to the data packet transmission to obtain the data packet to be transmitted for each path. Based on the priority of various data types, the data packets to be transmitted are prioritized to obtain the transmission order of each path; Multi-path parallel transmission is performed based on the transmission order, and the transmission process is tracked and recorded to extract transmission monitoring data. Based on real-time assessment of transmission monitoring data, transmission path switching is performed.

[0037] In this embodiment, the network resource consumption of each data packet during transmission needs to be clearly quantified for subsequent path allocation and load scheduling. Load calculation primarily uses data packet size, number of fragments, redundant fragment ratio, and expected transmission frequency as parameters. For a raw data stream divided into 5 data fragments and generating 2 redundant fragments, the total byte size needs to be calculated, taking into account the potential increase in load due to network retransmission or acknowledgment mechanisms. The unit time window can be set to 1 second or 5 seconds to statistically analyze the total load of each data stream within that time range, thereby reflecting the instantaneous transmission pressure. For high-frequency data streams, such as periodic sensor data reporting, 10 to 50 data packets may be generated per second, while low-frequency control commands only require 1 to 2 data packets per minute. Matching the load of the data packet with the path carrying capacity achieves reasonable load allocation. For the three available paths, their transmission evaluation values ​​are 0.8, 0.6, and 0.4 (normalized), respectively. The total load to be transmitted can be proportionally distributed across each path, with the path with the highest evaluation value carrying approximately 50%–60% of the load, the medium-value path carrying approximately 25%–30%, and the low-value path carrying approximately 15%–20%. The instantaneous bandwidth limit of a single path needs to be considered. For example, a path with a link bandwidth of 10 Mbps can transmit a maximum of approximately 1.2 MB of data packets within a 1-second window. Data exceeding this limit needs to be allocated to other paths or wait for the next time window. For multiple fragments or redundant fragments of the same data stream, one can choose to concentrate transmission on a single path or distribute transmission across multiple paths to balance ordering and load balancing.

[0038] Data packets to be transmitted on each path are sorted according to data priority to form a clear transmission order. Priority can be set to three levels: high (urgent alarms or control commands), medium (periodic status reporting), and low (long-term monitoring or log data). High-priority packets are placed at the front of the queue to ensure priority transmission; medium-priority packets are sorted secondary based on their generation time, and low-priority packets are placed at the rear of the queue. To prevent low-priority data from waiting for extended periods, a time decay mechanism can be introduced; for example, low-priority data that has not been sent for more than 5 seconds can automatically have its priority increased by one level. Queue sorting also considers the continuity of the same data stream to ensure consistent fragmentation order. Following the sorted transmission queue, multi-path parallel transmission is initiated. Each path can send multiple data packets simultaneously within a 1-second time window, the number limited by path bandwidth and load assessment values. A path with a high assessment value and a bandwidth of 10Mbps can transmit 8 to 10 data packets in parallel within 1 second, while a path with a low assessment value and a bandwidth of 5Mbps can transmit 3 to 4 data packets. During transmission, the sending time, selected path, reception acknowledgment status, and retransmission count of each data packet are recorded in real time, forming a complete tracking log. Transmission monitoring data includes metrics such as actual path throughput, latency changes, packet loss rate, and retransmission status, and is summarized by path and data priority. After acquiring the transmission monitoring data, a real-time evaluation is performed to determine whether path switching is necessary. When the actual throughput of a path falls below 50% of the evaluated value, the average latency exceeds the threshold of 50 milliseconds, or the packet loss rate exceeds 5%, the path switching mechanism is triggered. During the switching process, data packets that have not yet been sent or are currently being transmitted are reallocated to other available paths, and the transmission order is readjusted to ensure that high-priority data is transmitted first. The switching process may also consider path load balancing, ensuring that high-evaluation paths bear 50%–60% of the load after the switch, medium-evaluation paths 25%–30%, and low-evaluation paths 15%–20%.

[0039] In this embodiment, the specific steps for real-time evaluation based on transmission monitoring data and transmission path switching are as follows: Based on transmission monitoring data, the transmission success rate, segment loss rate, reassembly delay, and protocol backoff frequency are calculated to obtain the actual path status indicators. Set the path transmission status threshold; The actual status index of the path is evaluated in real time based on the path transmission status threshold. When the actual status index of the path is lower than the path transmission status threshold, the transmission path switching process is triggered. The data encapsulation packet undergoes path rematching and emergency transmission processing.

[0040] In this embodiment, four key metrics are calculated for each path: transmission success rate, fragment loss rate, reassembly delay, and protocol backoff frequency. Transmission success rate is measured by the ratio of the number of successfully arriving complete data packets to the total number of sent data packets within a statistical unit time window, which can use a 1-second or 5-second rolling time window. Fragment loss rate is calculated by statistically analyzing the number of lost fragments or redundant fragments, reflecting the path's reliability as a percentage. Reassembly delay describes the time interval from data fragment transmission to reassembly completion; average and maximum values ​​can be recorded to assess path latency stability. Protocol backoff frequency reflects the number of times the path triggers protocol backoff or retransmission mechanisms under abnormal conditions, used to quantify path anomaly recovery behavior. Corresponding state thresholds are set for each metric to define whether the path is in an available or healthy state. Threshold settings are typically combined with business requirements and network performance requirements; for example, a transmission success rate of over 90%, a fragment loss rate of less than 5%, an average reassembly delay of no more than 50 milliseconds, and a protocol backoff frequency of no more than once per second are typically set. Different application scenarios can adjust the thresholds according to the requirements of real-time performance or reliability. For example, higher-priority alarm data transmission can use stricter thresholds, while lower-priority log data transmission can tolerate a certain degree of packet loss or delay. The thresholds can be further subdivided according to path type, link bandwidth, and terminal node capabilities to reflect the performance tolerance under different network conditions.

[0041] The actual status indicators of the transmission path are compared and analyzed with the set status thresholds using real-time collected monitoring data. When the transmission success rate of a path falls below 90%, the segment loss rate exceeds 5%, the average reassembly latency exceeds 50 milliseconds, or the protocol backoff frequency exceeds 1 time / second, the path performance is deemed to have degraded, triggering a transmission path switching mechanism. The evaluation uses a continuous sliding time window, such as updating indicators every 1 second or every 5 seconds, to ensure rapid response to network fluctuations. Path switching triggers not only consider single indicator anomalies but also make judgments based on the comprehensive evaluation results of multiple indicators, ensuring more stable and reliable switching decisions. After triggering a path switch, data packets that have not yet been sent or are currently being transmitted are encapsulated and re-matched to the path and processed for emergency transmission. First, based on the latest transmission evaluation value and status indicators of available paths, data packets are reassigned to the optimal path, prioritizing paths with high evaluation values, high success rates, and sufficient bandwidth. During the re-matching process, the priority order and fragmentation continuity of data packets are maintained simultaneously to ensure that high-priority data is transmitted first, reducing the risk of low-priority data being delayed or blocked. For high-priority or time-sensitive data, multi-path redundancy transmission can be enabled, where the same data packet is sent in parallel on two or more paths to improve the transmission success rate. After the data packet is re-matched, emergency transmission processing is initiated, including real-time monitoring of retransmission status, recording the effect of path selection, and adjusting the fragmentation scheduling strategy.

[0042] In this embodiment, a data transmission system for a multi-protocol IoT hub platform is provided, used to execute the data transmission method for a multi-protocol IoT hub platform as described above, including: The acquisition unit is used to acquire communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types. An encapsulation unit is used to encapsulate the communication data stream to obtain a data encapsulation packet; The evaluation unit identifies multiple available transmission paths accessed by the IoT central platform and performs transmission load evaluation to obtain transmission evaluation values ​​for each path. The adaptation unit is used to adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

[0043] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0044] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein are implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A data transmission method for a multi-protocol Internet of Things (IoT) hub platform, characterized in that, Includes the following steps: Step S1: Collect communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types; Step S2: Encapsulate the communication data stream to obtain a data encapsulation packet; Step S3: Identify multiple available transmission paths accessed by the IoT central platform and perform transmission load assessment to obtain the transmission assessment value for each path; Step S4: Adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

2. The data transmission method of the multi-protocol IoT hub platform according to claim 1, characterized in that, The specific steps of step S1 are as follows: Collect communication data streams from various terminal devices, perform communication behavior analysis and feature clustering on the communication data streams, and construct a protocol behavior feature pool; Based on the protocol behavior feature pool, data value is deconstructed for each category to obtain the real-time effective value of each category of data. Define priority decay timestamps and perform transmission priority planning based on the real-time effective value to obtain the priorities of various data types.

3. The data transmission method of the multi-protocol IoT hub platform according to claim 2, characterized in that, The specific steps for collecting communication data streams from various terminal devices, performing communication behavior analysis and feature clustering on the communication data streams, and constructing a protocol behavior feature pool are as follows: Real-time acquisition of communication data streams from various terminal devices based on an IoT central platform; The communication data stream is subjected to message protocol identification to obtain various communication protocols; Based on various communication protocols, communication behavior is analyzed, and the protocol frame sending rhythm, handshake interaction response delay, retransmission probability, data load burst characteristics, and link jitter spectrum are extracted to obtain a set of behavioral features. The behavioral feature set is clustered and statistically summarized to construct a protocol behavior feature pool.

4. The data transmission method of the multi-protocol IoT hub platform according to claim 2, characterized in that, The specific steps for deconstructing data value based on the protocol behavior feature pool to obtain the real-time effective value of each data category are as follows: The real-time effective value includes data generation frequency, data timeliness decay rate, business triggering dependencies, and historical usage feedback. The difference between high-frequency sensor data and low-frequency control commands is calculated based on the protocol behavior feature pool to obtain the data generation frequency. Based on the communication data stream, the influence weight of upstream data on downstream services is calculated to obtain the service triggering dependency relationship; Compare the protocol behavior feature pool with slow data decay and rapid alarm information expiration to generate data timeliness decay rate; The call frequency is calculated based on the communication data stream; Historical usage feedback is determined based on the frequency of the calls.

5. The data transmission method of the multi-protocol IoT hub platform according to claim 1, characterized in that, The specific steps of step S2 are as follows: Perform content analysis on the communication data stream to extract content semantics; Data sharding requirements are analyzed based on content semantics to obtain sharding requirement characteristics; Based on the characteristics of fragmentation requirements, data streams are segmented one by one and then encapsulated to obtain multiple data packets; Multiple data packets are assigned the same data stream priority based on various data priorities, resulting in a data encapsulation packet with a priority label.

6. The data transmission method of the multi-protocol IoT hub platform according to claim 5, characterized in that, The specific steps for segmenting data streams based on fragmentation requirements and encapsulating the data to obtain multiple data packets are as follows: The fragmentation requirements include redundancy features and fault tolerance requirements. Based on the data compressibility analysis, the compressibility of each data stream is obtained; Calculate the maximum acceptable packet loss rate based on the aforementioned fault tolerance requirement level; The encoding parameters of each data stream are dynamically adjusted based on the maximum acceptable packet loss rate and the compressibility. The communication data stream is divided into K data fragments and M redundant fragments based on the encoding parameters; Data is encapsulated from K data fragments and M redundant fragments to obtain multiple data packets.

7. The data transmission method of the multi-protocol IoT hub platform according to claim 1, characterized in that, The specific steps of step S3 are as follows: Identify multiple available transmission paths accessed by the IoT central platform; Network status detection is performed on the multiple available transmission paths to obtain status parameters for the multiple paths; the status parameters include link bandwidth utilization, real-time network load, link reliability index, and terminal node energy consumption status; Calculate the data throughput elasticity, latency stability, and failure recovery capability of the multiple available transmission paths to obtain the path performance characteristics; Based on the path performance characteristics and the aforementioned state parameters, the transmission load is evaluated to obtain the transmission evaluation value for each path.

8. The data transmission method of the multi-protocol IoT hub platform according to claim 1, characterized in that, The specific steps of step S4 are as follows: Calculate the transmission load of the data encapsulation packet; Based on the transmission evaluation value of each path, the transmission load is adapted to the data packet transmission to obtain the data packet to be transmitted for each path. Based on the priority of various data types, the data packets to be transmitted are prioritized to obtain the transmission order of each path; Multi-path parallel transmission is performed based on the transmission order, and the transmission process is tracked and recorded to extract transmission monitoring data. Based on real-time assessment of transmission monitoring data, transmission path switching is performed.

9. The data transmission method of the multi-protocol IoT hub platform according to claim 1, characterized in that, The specific steps for real-time evaluation based on transmission monitoring data and transmission path switching are as follows: Based on transmission monitoring data, the transmission success rate, segment loss rate, reassembly delay, and protocol backoff frequency are calculated to obtain the actual path status indicators. Set the path transmission status threshold; The actual status index of the path is evaluated in real time based on the path transmission status threshold. When the actual status index of the path is lower than the path transmission status threshold, the transmission path switching process is triggered. The data encapsulation packet undergoes path rematching and emergency transmission processing.

10. A data transmission system for a multi-protocol Internet of Things (IoT) hub platform, characterized in that, A data transmission method for executing a multi-protocol IoT hub platform as described in claim 1 includes: The acquisition unit is used to acquire communication data streams from various terminal devices, perform transmission priority planning on the communication data streams, and obtain the priorities of various data types. An encapsulation unit is used to encapsulate the communication data stream to obtain a data encapsulation packet; The evaluation unit identifies multiple available transmission paths accessed by the IoT central platform and performs transmission load evaluation to obtain transmission evaluation values ​​for each path. The adaptation unit is used to adapt the data packet transmission and perform multi-path parallel transmission on the data encapsulation packet according to the transmission evaluation value of each path.

Images