Wireless Internet of Things cloud edge protocol conversion adaptation method, edge device and adaptation system

Abstract

The invention provides a wireless Internet of Things cloud edge protocol conversion adaptation method, an edge device and a system, and relates to the technical field of Internet of Things communication. The method comprises the following steps: acquiring network performance index vectors corresponding to various cloud side communication protocols, and reading an index weight vector determined based on a group decision from a local weight database in combination with a service quality level of a data packet; the method comprises the following steps: receiving a terminal data packet, analyzing a payload and a service quality level, calculating actual data volume and time consumption required by transmission of each protocol, generating a time consumption vector, and determining the payload amount transmitted in unit time; performing dimensionless processing on the network performance indexes to obtain a normalized matrix; and calculating the performance priority of each protocol by integrating the normalized index, the weight vector and the transmission efficiency, selecting the optimal protocol as a target protocol, and sending the data packet to the cloud through the protocol when the transmission time does not exceed the effective time of the data packet. The real-time performance, the reliability and the resource utilization rate of cloud side communication are improved, and the problems that a traditional fixed protocol is poor in selection adaptability and low in efficiency are solved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) communication technology, and in particular to a wireless IoT cloud-edge protocol conversion and adaptation method, edge device, and adaptation system. Background Technology

[0002] With the rapid development of IoT technology, a large number of smart terminals, sensors, and controllers have been deployed in wireless IoT. These devices come from different manufacturers and use different communication protocols, forming a complex heterogeneous network environment. In a typical IoT architecture, a three-layer structure of "cloud-edge-device" is usually adopted, in which edge computing nodes, as the key hub connecting the cloud and terminal devices, undertake important functions such as protocol conversion and data relay.

[0003] In terms of protocol conversion, existing technologies primarily employ edge gateways as protocol conversion nodes. These gateways achieve inter-protocol conversion by parsing the message formats of different protocols. The academic community has proposed various protocol conversion gateway architectures, such as middleware-based conversion schemes and semantic mapping-based methods, which have achieved good results in end-to-end or end-to-edge communication scenarios. However, existing research on the communication protocol adaptation problem between the cloud and edge nodes is relatively limited. In wireless IoT environments, network topology changes dynamically, and communication quality fluctuates significantly. Therefore, selecting the optimal cloud-edge communication protocol based on real-time network conditions directly impacts the communication efficiency and service quality of the entire system. Summary of the Invention

[0004] The purpose of this application is to provide a wireless IoT cloud-edge protocol conversion and adaptation method, edge device, and adaptation system to alleviate the aforementioned technical problems existing in the prior art.

[0005] In a first aspect, the present invention provides a wireless Internet of Things (IoT) cloud-edge protocol conversion and adaptation method, executed by an edge device, comprising: Obtain the network performance index vectors corresponding to various communication protocols that support communication with the cloud, and read the performance index weight vectors corresponding to the service quality level and determined based on group decision from the weight database stored locally, according to the service quality level of the current data packet to be transmitted. Receive data packets from terminal devices, parse out the payload and quality of service level of the data packets, combine the amount of redundant data required to encapsulate the payload according to each communication protocol, calculate the actual amount of data required to transmit the data packet under each communication protocol, and calculate the time required for each communication protocol to complete the transmission based on the network speed and the actual amount of data, and generate a time consumption vector. The effective payload transmitted per unit time for each communication protocol is determined based on the time consumption vector, and the various indicators in the network performance index vector are dimensionless to obtain the normalized network performance index matrix. Based on the normalized network performance index matrix, performance index weight vector, and effective payload transmitted per unit time, the performance priority of each communication protocol is calculated. The communication protocol with the highest performance priority is selected as the target protocol. When the time corresponding to the time consumption vector does not exceed the effective time of the data packet, the data packet is sent to the cloud through the target protocol.

[0006] In an optional implementation, network performance indicator vectors corresponding to various communication protocols supporting cloud communication are obtained. These vectors include at least network speed, latency, jitter, and packet loss rate. Based on the service quality level of the current data packet to be transmitted, a performance indicator weight vector corresponding to the service quality level and determined based on group decision-making is read from a locally stored weight database, including: Periodically test the communication link status between edge devices and the cloud under different communication protocols, collect the maximum data throughput during the data interaction process per unit time under each communication protocol as network speed, the average round-trip delay of the signal as latency, the difference in adjacent latency fluctuations as jitter, and the proportion of unsuccessfully received data packets as packet loss rate, and generate network performance index vectors corresponding to each communication protocol. Using the quality of service (QoS) level of the current data packet to be transmitted as an index parameter, a matching search is performed in the locally stored weight database to extract the performance indicator weight vector that is pre-associated with the QoS level and determined based on group decision-making.

[0007] In an optional implementation, data packets from a terminal device are received, the payload and quality of service (QoS) level of the data packets are parsed, the amount of redundant data required to encapsulate the payload according to each communication protocol is considered, the actual amount of data required to transmit the data packet under each communication protocol is calculated, and the time required for each communication protocol to complete the transmission is calculated based on the network speed and the actual amount of data, generating a time consumption vector, including: The system monitors the upload channel of the terminal device. When a data packet arrives, it reads the packet header information and extracts the data entity size as the payload and the service quality level corresponding to the service type identifier. Based on the pre-stored protocol overhead mapping table, the amount of redundant data is determined according to the amount of data occupied by the control fields, connection maintenance information and check codes required for each communication protocol to encapsulate the same payload. Based on the redundant data volume corresponding to the payload and each communication protocol, the total amount of data to be transmitted under each communication protocol is calculated as the actual data volume. Based on the actual data volume under each communication protocol and the network speed in the corresponding network performance index vector, calculate the time required for each communication protocol to complete this transmission and generate a time consumption vector.

[0008] In an optional implementation, the unit-time transmission payload of each communication protocol is determined based on the time consumption vector, and the various indicators in the network performance indicator vector are dimensionless to obtain a normalized network performance indicator matrix, including: Divide the payload corresponding to each communication protocol by the corresponding transmission time in the time consumption vector to obtain the effective data transmission amount that each communication protocol can complete per unit time, which is the effective payload transmitted per unit time. The network speed in the network performance metric vector is normalized according to the positive index, and the value is mapped to a uniform range. The latency, jitter, and packet loss rate are normalized according to the inverse indicators, and the values ​​are converted into a form in which higher values ​​indicate better performance. By recombining all the normalized index values, a network performance index matrix with uniform dimensions is obtained.

[0009] In an optional implementation, based on the normalized network performance index matrix, performance index weight vector, and effective payload transmitted per unit time, the performance priority of each communication protocol is calculated, the communication protocol with the highest performance priority is selected as the target protocol, and the data packet is sent to the cloud through the target protocol when the time corresponding to the time consumption vector does not exceed the data packet validity time, including: Each row of the normalized network performance index matrix corresponds to a normalized index value of a communication protocol. The values ​​are multiplied by the weights in the performance index weight vector at their corresponding positions and then summed to obtain the comprehensive network performance score of each communication protocol. The overall network performance score is weighted and fused with the corresponding effective payload transmitted per unit time to obtain the performance priority of each communication protocol; Compare the performance priorities of all communication protocols and determine the communication protocol with the highest value as the target protocol. Determine whether the transmission time corresponding to the target protocol in the time consumption vector is less than or equal to the valid time marked in the data packet. If yes, proceed to the next step; otherwise, abandon this forwarding operation.

[0010] In an optional implementation, the data packets are sent to the cloud via a target protocol, including: Modify the destination address of the data packet to the communication address of the cloud server, and update the protocol identifier field in the message header to the target protocol type; Initiate the communication connection mechanism corresponding to the target protocol, and after establishing a reliable transmission channel, send the encapsulated data packet to the cloud in segments or as a whole; Release the temporary resources occupied by the target protocol after the transmission is complete.

[0011] In an optional implementation, it further includes: During the local initialization phase, we collected evaluation opinions from multiple managers regarding the importance of various network performance indicators under different service quality levels, resulting in multiple evaluation samples. Consistency tests were performed on multiple evaluation samples under the same service quality level, and outlier scores with significant deviations were removed. The retained evaluation results are aggregated to determine the relative importance distribution of each network performance indicator corresponding to the service quality level. Based on the relative importance distribution, the performance indicator weight vector is determined and written into the weight database for persistent storage.

[0012] In an optional implementation, it further includes: It periodically receives evaluation data updated by the system administrator and dynamically corrects the existing weight vector; When a new communication protocol is added, a complete network performance metric sampling process is executed to incorporate it into the set of supported communication protocols, and the dimensional range of the redundant data volume mapping table and the network performance metric vector is expanded.

[0013] Secondly, the present invention provides an edge device, including a processor and a memory, wherein the memory stores program instructions, and when the processor executes the instructions, it performs a wireless Internet of Things cloud-edge protocol conversion and adaptation method as described in any of the foregoing embodiments.

[0014] Thirdly, the present invention provides a wireless IoT cloud-edge protocol conversion and adaptation system, comprising a terminal device, an edge device, and a cloud; wherein... Terminal devices are used to generate data packets containing payload, quality of service level, and validity period, and send the data packets to edge devices; Edge devices receive data packets from terminal devices and obtain network performance indicator vectors corresponding to various communication protocols supporting communication with the cloud. These vectors include at least network speed, latency, jitter, and packet loss rate. Based on the quality of service (QoS) level of the data packets, they retrieve the corresponding performance indicator weight vectors from a locally stored weight database. Combining the amount of redundant data required to encapsulate the payload for each communication protocol, they calculate the actual data volume required for transmission under each protocol and calculate the time required for each protocol to complete transmission based on network speed and actual data volume, generating a time consumption vector. Based on the time consumption vector, they determine the payload transmitted per unit time and perform dimensionless processing on each indicator in the network performance indicator vector to obtain a normalized network performance indicator matrix. Based on the normalized network performance indicator matrix, the performance indicator weight vectors, and the payload transmitted per unit time, they calculate the performance priority of each communication protocol and select the communication protocol with the highest performance priority as the target protocol. When the time corresponding to the time consumption vector does not exceed the data packet's validity period, the target protocol is used to forward the data packet to the cloud. The cloud is used to receive data packets forwarded by edge devices and provide response services.

[0015] The wireless IoT cloud-edge protocol conversion and adaptation method, edge device, and adaptation system provided in this application achieve accurate perception of the dynamic network environment by acquiring network performance index vectors corresponding to various cloud-edge communication protocols and combining them with weight vectors determined based on group decision-making and matched with the data packet quality of service level. This improves the fit between protocol selection and actual communication needs. The actual transmitted data volume is calculated using redundant data, and the time consumption of each protocol is evaluated in conjunction with network speed, further deriving the effective payload transmitted per unit time and quantifying the transmission efficiency of different protocols in specific scenarios. By performing dimensionless processing on network performance indicators and integrating weights and transmission efficiency to calculate performance priorities, protocol selection gains multi-dimensional adaptive capabilities. Finally, by selecting the best protocol based on priority while considering effective time constraints, the real-time performance, reliability, and resource utilization of cloud-edge communication are effectively improved, solving the problems of low communication efficiency and poor adaptability caused by traditional fixed protocol selection. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a wireless IoT cloud-edge protocol conversion and adaptation method provided in this application embodiment; Figure 2 A specific protocol adaptation flowchart based on network performance characteristics is provided for an embodiment of this application; Figure 3 This is a structural diagram of a wireless IoT cloud-edge protocol conversion and adaptation system provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] This application provides a wireless IoT cloud-edge protocol conversion and adaptation method, executed by an edge device. See [link to relevant documentation]. Figure 1 As shown, the method mainly includes the following steps: S110: Obtain the network performance index vectors corresponding to various communication protocols that support communication with the cloud. The network performance index vectors include at least network speed, latency, jitter, and packet loss rate. Based on the service quality level of the data packet to be transmitted, read the performance index weight vector corresponding to the service quality level and determined based on group decision from the locally stored weight database.

[0022] Obtaining network performance metric vectors for various communication protocols supporting cloud communication refers to edge devices acquiring actual network performance data during communication for each available cloud-edge communication protocol (such as HTTP, MQTT, CoAP, WebSocket, etc.) in the current network environment through periodic probing or real-time monitoring. The network performance metric vector includes four key parameters: network speed, latency, jitter, and packet loss rate. Network speed characterizes the amount of data that can be transmitted per unit time; latency represents the time interval between data transmission and reception; jitter is the degree of variation in the time interval between consecutive data packets; and packet loss rate is the proportion of data packets lost during transmission. These metrics collectively characterize the overall performance level of different protocols under the current network conditions.

[0023] Based on the quality of service (QoS) level of the data packet to be transmitted, the system reads the corresponding performance metric weight vector from the locally stored weight database. In other words, before or simultaneously with the arrival of the data packet, the system identifies its QoS level (e.g., high, medium, and low) and, according to this QoS level, invokes the weight configuration pre-calculated and stored in the local SQL database using a group decision-making method. This weight vector represents the importance ranking of various network performance metrics under specific QoS requirements, avoiding biases caused by assigning weights based on single experience.

[0024] S120 receives data packets from the terminal device, parses the payload and quality of service level of the data packets, combines the amount of redundant data required to encapsulate the payload under each communication protocol, calculates the actual amount of data required to transmit the data packet under each communication protocol, and calculates the time required for each communication protocol to complete the transmission based on the network speed and the actual amount of data, generating a time consumption vector.

[0025] Receiving data packets from terminal devices and parsing out the payload and quality of service (QoS) level refers to the process by which edge devices, after receiving data units uploaded by terminals such as sensors and controllers, parse the structure of the data packets, extract the actual information content (payload) carried within, and the QoS level field used to identify the importance of the data.

[0026] Based on the redundant data required for each communication protocol, that is, according to the message format characteristics of different communication protocols, the amount of additional overhead data required for each protocol to transmit the same payload is pre-stored. For example, MQTT includes header information such as topics and identifiers, while HTTP has a larger text header. The payload size is added to the redundant data of the corresponding protocol to obtain the total amount of complete data required to complete the transmission under that protocol.

[0027] Calculating the time required for each protocol to complete transmission based on network speed and actual data volume means using the currently measured network speed and dividing it by the total amount of data required to be transmitted by each protocol to estimate the theoretical time required to completely send the data packet to the cloud using each protocol. The time of all protocols constitutes a time consumption vector.

[0028] S130: Determine the effective payload per unit time of each communication protocol based on the time consumption vector, and perform dimensionless processing on each index in the network performance index vector to obtain the normalized network performance index matrix.

[0029] The effective payload transmitted per unit time for each communication protocol is determined based on the time consumption vector. In specific implementation, the effective payload carried by each communication protocol is divided by the transmission time calculated in S120 to obtain the effective amount of information that can be successfully delivered to the cloud per unit time. This value reflects the actual transmission efficiency of different protocols in the current scenario.

[0030] To eliminate the incomparability caused by differences in dimensions and orders of magnitude among different indicators, the indicators in the network performance indicator vector are dimensionless. For network speed, a positive indicator, the range method can be used to map it to the [0,1] interval; for inverse indicators such as latency, jitter, and packet loss rate, reverse normalization can be performed so that a larger value represents better performance.

[0031] S140: Based on the normalized network performance index matrix, performance index weight vector, and effective payload transmitted per unit time, calculate the performance priority of each communication protocol, select the communication protocol with the highest performance priority as the target protocol, and send the data packet to the cloud through the target protocol when the corresponding time in the time consumption vector does not exceed the data packet validity time.

[0032] Based on the normalized network performance index matrix, performance index weight vector, and effective payload transmitted per unit time, the performance priority of each communication protocol is calculated. In practice, the normalized network performance index values ​​are multiplied by their corresponding weights and summed to generate a score characterizing the protocol's network adaptability. This score, combined with the effective payload transmitted per unit time, is then used to calculate the overall performance priority value for each protocol according to predetermined fusion rules. The higher this value, the better the overall adaptability of the protocol under current network conditions and service requirements.

[0033] Selecting the communication protocol with the highest performance priority as the target protocol means choosing the one with the best overall score for this data forwarding. Furthermore, ensuring that the time in the time consumption vector does not exceed the data packet's valid lifespan is a constraint on transmission feasibility. If a protocol, although high priority, has an estimated transmission time exceeding the data packet's allowed valid lifespan, it will not be selected. This ensures that transmission only occurs while the data still has time-sensitive value, and ultimately, the data packet is sent to the cloud address through the target protocol that meets the conditions.

[0034] For ease of understanding, the above-mentioned methods provided in this application will be further described in detail below.

[0035] In one implementation, the above-mentioned acquisition of network performance indicator vectors corresponding to various communication protocols supporting cloud communication, wherein the network performance indicator vectors include at least network speed, latency, jitter, and packet loss rate, and based on the service quality level of the current data packet to be transmitted, reading the performance indicator weight vector corresponding to the service quality level and determined based on group decision from a locally stored weight database, may include the following steps 1.1 and 1.2 in a specific implementation: Step 1.1: Periodically test the communication link status between the edge device and the cloud under different communication protocols. Collect the maximum data throughput during the data interaction process per unit time under each communication protocol as network speed, the average round-trip delay as latency, the difference in adjacent latency fluctuations as jitter, and the proportion of unsuccessfully received data packets as packet loss rate, and generate network performance index vectors corresponding to each communication protocol.

[0036] In one implementation, the communication link between the edge device and the cloud can be continuously probed and measured according to a preset time interval or triggering condition. "Periodic testing" refers to monitoring changes in network status in real time to ensure that the obtained network performance indicators can reflect the current real communication environment.

[0037] Communication link status is the dynamic network behavior during data transmission between the cloud and the edge under a specific communication protocol. Maximum data throughput measures the maximum amount of data that can be successfully transmitted per unit time, used to quantify network speed and characterize the data carrying capacity of the communication channel; average round-trip delay, the average time interval between a data packet being sent from the edge to the cloud and receiving a response, is used to characterize latency; adjacent delay fluctuation difference represents the magnitude of change between two consecutive communication delays, used to calculate jitter; the ratio of unreceived data packets is the proportion of data packets lost during a certain transmission process to the total number of packets sent, used to measure the packet loss rate.

[0038] The aforementioned network speed, latency, jitter, and packet loss rate constitute a typical set of performance indicators for wireless IoT cloud-edge communication, used to characterize the actual communication quality of different protocols in the current network environment.

[0039] In this implementation, the edge device has a built-in link detection module. This module actively initiates connection probes to the cloud server at set intervals (e.g., every 30 seconds or every minute), establishing test sessions using supported cloud-edge communication protocols such as HTTP, MQTT, CoAP, and WebSocket. The same data interaction task (e.g., sending a fixed-size heartbeat message and waiting for acknowledgment) is performed on each protocol channel. The maximum data throughput during this process is recorded as the network speed value under that protocol; the arithmetic mean of multiple round-trip times is calculated as the latency value; the standard deviation or range of consecutive round-trip time differences is calculated as the jitter value; and the percentage of packets that fail to receive acknowledgment is calculated as the packet loss rate. These four indicators are organized into a four-dimensional vector to obtain the network performance indicator vector corresponding to this communication protocol.

[0040] Step 1.2: Using the quality of service level of the current data packet to be transmitted as an index parameter, perform a matching search in the locally stored weight database to extract the performance index weight vector that is pre-associated with the quality of service level and determined based on group decision-making.

[0041] Quality of Service (QoS) level refers to the classification level of communication assurance requirements for data packets during transmission. It can be set by the terminal application to characterize the importance and timeliness requirements of the data, such as different levels like normal, priority, and high priority.

[0042] The aforementioned group decision-making refers to the process where multiple domain experts (such as network engineers and system architects) independently score the importance of each performance indicator for different service quality levels, and then use mathematical methods (such as summation and normalization) to integrate multiple scores and finally determine a unified weight vector for each level. This avoids the bias caused by a single subjective judgment and improves the scientificity and rationality of the weight setting.

[0043] The performance metric weight vector is a four-dimensional numerical vector composed of the weights of four metrics: network speed, latency, jitter, and packet loss rate. It is used to characterize the relative influence of each metric in the protocol selection process under a specific service quality level.

[0044] When an edge device receives a data packet to be forwarded, it first parses the Quality of Service (QoS) field carried by the packet. Using this QoS value as the query key, it accesses a locally pre-configured weight database, performs an exact match retrieval operation, and obtains the performance metric weight vector associated with it. For example, if the data packet's QoS level is high real-time, it returns a vector with latency and jitter as the primary weights; if it is high throughput, it assigns a higher weight to network speed.

[0045] The above-mentioned approach involves periodically collecting real-world network performance metrics under various communication protocols to construct a dynamically updated performance metric vector set, ensuring the real-time nature and accuracy of protocol selection. Simultaneously, a weighted database mechanism based on group decision-making is introduced to intelligently invoke corresponding metric weight configurations according to the service quality level of different data packets, enabling the protocol adaptation process to balance universality and differentiated needs. Compared to static rule-based or experience-driven protocol selection methods, this solution can more accurately match the current network environment and business requirements, improving the stability, efficiency, and resource utilization of wireless IoT cloud-edge communication, and effectively supporting intelligent protocol switching and optimized transmission in complex and ever-changing application scenarios.

[0046] Furthermore, the process of receiving data packets from the terminal device, parsing the payload and quality of service (QoS) level of the data packets, calculating the actual data volume required to transmit the data packet under each communication protocol based on the amount of redundant data required to encapsulate the payload according to each communication protocol, and calculating the time required for each communication protocol to complete the transmission based on the network speed and the actual data volume, generates a time consumption vector. In specific implementation, this may include the following steps 2.1 to 2.4: Step 2.1: Monitor the upload channel of the terminal device. When a data packet is detected to arrive, read the header information of the data packet and extract the data entity size as the payload and the service quality level corresponding to the service type identifier.

[0047] The packet header contains control and metadata information, including key fields such as source address, destination address, data length, service type, and quality of service (QoS) level. The payload, or the data entity itself, is the amount of data it contains, measured in bytes, reflecting the scale of the core information to be transmitted. The QoS level is mapped from the service type identifier; for example, temperature monitoring might be marked as "normal," while emergency alarm signals would be "high priority." This level determines the focus of various network performance indicators during subsequent protocol selection.

[0048] In one implementation, the edge device continuously polls or responds to data arrival events from the terminal device via an interrupt mechanism. Once a new data packet is detected entering the buffer, a parsing process is immediately triggered to parse its header content, identify the carried service type identifier, and determine the corresponding quality of service level based on a preset mapping relationship. Simultaneously, the number of bytes read from the data body is used as the payload size.

[0049] Step 2.2: Based on the pre-stored protocol overhead mapping table, determine the amount of redundant data according to the amount of data required for each communication protocol to encapsulate the same payload, including the additional control fields, connection maintenance information, and checksums.

[0050] The protocol overhead mapping table is a locally stored data structure that records the fixed or typical amount of additional data generated when different communication protocols encapsulate data, i.e., the amount of redundant data. This redundant data mainly includes the protocol's own control fields (such as MQTT topic identifiers and CoAP message headers), session management information (such as WebSocket handshake frames), integrity check codes (such as CRC and TCP checksums), etc.

[0051] During system initialization, a protocol overhead mapping table has been established based on the standard specifications or measured statistical results of various cloud-edge communication protocols, and this table is stored in the non-volatile memory of the edge device. When making protocol adaptation decisions, this table is called to query the amount of redundant data corresponding to each protocol, such as HTTP, MQTT, CoAP, and WebSocket. For example, MQTT has less header overhead due to its lightweight publish / subscribe model, while HTTP has more redundant data because it needs to carry complete request header information.

[0052] Step 2.3: Based on the payload and the amount of redundant data corresponding to each communication protocol, calculate the total amount of data to be transmitted under each communication protocol as the actual amount of data.

[0053] Actual data volume refers to the total amount of data actually transmitted in the network to complete a single effective data transmission under a specific communication protocol. It is equal to the sum of the payload and the corresponding protocol's redundant data. This value is used to characterize the actual resource consumption level of different protocols when transmitting the same service data.

[0054] The payload and redundant data of each protocol obtained above are added together to obtain the actual data volume under each communication protocol, forming an actual data consumption vector corresponding to the set of supported protocols. For example, if the payload is 500 bytes and the redundancy of MQTT is 30 bytes, then its actual data volume is 530 bytes; if the redundancy of HTTP is 200 bytes, then its actual data volume is 700 bytes.

[0055] Step 2.4: Based on the actual data volume under each communication protocol and the network speed in the corresponding network performance index vector, calculate the time required for each communication protocol to complete this transmission and generate a time consumption vector.

[0056] The time consumption vector is a numerical vector composed of the theoretical time required for each communication protocol to complete the transmission of the current data packet, expressed in seconds or milliseconds. It is used to measure the transmission efficiency of different protocols under current network conditions. The network speed mentioned in this step comes from the maximum data throughput in the network performance index vector obtained from the periodic tests in step 1.1, representing the effective transmission rate under the current protocol channel, expressed in bytes per second (B / s).

[0057] In practical applications, for each communication protocol, the theoretical transmission time can be obtained by dividing the actual data volume corresponding to that protocol by the currently measured network speed. The transmission times of all protocols are summed to form a time consumption vector.

[0058] This approach constructs a time consumption vector, providing a quantitative basis for subsequent protocol prioritization and validity verification. This improves the accuracy and practicality of protocol selection, and is particularly suitable for wireless IoT environments with limited resources and frequent network fluctuations. It helps to achieve efficient, reliable, and on-demand adaptive switching of cloud-edge communication protocols.

[0059] Furthermore, the above-mentioned determination of the effective payload transmitted per unit time for each communication protocol based on the time consumption vector, and the dimensionless processing of each indicator in the network performance indicator vector to obtain the normalized network performance indicator matrix, may include the following steps 3.1 to 3.4 in specific implementation: Step 3.1: Divide the payload corresponding to each communication protocol by the corresponding transmission time in the time consumption vector to obtain the effective data transmission amount that each communication protocol can complete per unit time, which is the effective payload transmitted per unit time.

[0060] The payload transmitted per unit time characterizes the amount of valid business data that can be successfully delivered to the cloud per unit time under the current network conditions and protocol overhead. A higher payload transmitted per unit time indicates higher information utilization efficiency and greater communication benefits of the communication protocol in this transmission task.

[0061] In the specific calculation, the extracted payload (i.e., data entity size) and the transmission time of each protocol in the generated time consumption vector are calculated item by item. For each supported communication protocol, its corresponding payload is divided by the required transmission time to obtain its payload per unit time in the current scenario. For example, if a protocol takes 2 seconds to transmit 500 bytes of data, its payload per unit time is 250 bytes / second.

[0062] Step 3.2: Normalize the network speed in the network performance index vector according to the positive index, and map the values ​​to a unified range.

[0063] Positive metrics are performance parameters where a larger value indicates better network performance. Network speed is a positive metric; a higher value indicates stronger data throughput and higher communication efficiency. Since raw network performance metrics have different dimensions and orders of magnitude (e.g., B / s, ms, %), they cannot be directly used in weighted calculations. Therefore, they need to be dimensionless to eliminate unit differences and uniformly mapped to the same value range (e.g., [0,1]) for subsequent comprehensive evaluation.

[0064] Normalization is performed on the network speed values ​​in the network performance metric vectors corresponding to each communication protocol. Specifically, using the range method or the maximum value normalization method, the network speed of each protocol is converted into a standardized relative score by combining the maximum and minimum network speeds of all current protocols. For example, if the currently measured network speeds of each protocol are distributed between 100 B / s and 1000 B / s, then 1000 B / s is mapped to 1.0, 100 B / s is mapped to 0.1, and the rest are linearly transformed proportionally.

[0065] Step 3.3: Normalize latency, jitter, and packet loss rate according to the inverse index, and convert the values ​​into a form in which higher values ​​indicate better performance.

[0066] Inverse metrics are parameters where smaller values ​​generally indicate better performance. Latency, jitter, and packet loss rate all fall into this category: low latency indicates fast response, low jitter indicates stable latency, and low packet loss rate indicates reliable transmission. To align these metrics with other positive metrics in terms of optimization direction (i.e., "the larger the better"), they must undergo inverse normalization. This involves converting the original values ​​into equivalent performance scores, so that higher values ​​represent better network quality.

[0067] Inverse normalization is performed on latency, jitter, and packet loss rate in the network performance metric vectors of each protocol. The process involves first determining the maximum and minimum values ​​for each metric across all protocols, then employing a reverse mapping strategy to assign the highest score to the original minimum value and the lowest score to the original maximum value. For example, if a set of latency values ​​is 10ms, 50ms, and 100ms, after normalization, 10ms corresponds to a high score close to 1.0, while 100ms corresponds to a lower score. Jitter (the difference in latency between adjacent values) and packet loss rate (the proportion of packets that are not successfully received) are processed using the same method. After processing, all three metrics are converted into performance scores with uniform dimensions and consistent direction.

[0068] Step 3.4: Recombine all normalized index values ​​to obtain a network performance index matrix with uniform dimensions.

[0069] The network performance index matrix is ​​a two-dimensional data structure consisting of four-dimensional normalized index values ​​corresponding to multiple communication protocols. Each row represents a communication protocol, and each column represents a performance index after dimensionless processing (including normalized network speed, latency, jitter, and packet loss rate).

[0070] All normalized metric values ​​are then recombined, meaning the metric values ​​normalized in steps 3.2 and 3.3 are organized into a matrix according to the protocol. For example, for the MQTT protocol row, its normalized network speed score, latency score, jitter score, and packet loss rate score are entered; similarly, other protocol rows such as HTTP, CoAP, and WebSocket are filled in. The final result is a standard matrix with the number of rows equal to the number of supported protocols and the number of columns equal to the number of performance metrics—this is the normalized network performance metric matrix.

[0071] This method quantifies the information transmission efficiency of different communication protocols in real transmission scenarios by calculating the effective payload transmitted per unit time, avoiding misjudgments based solely on theoretical bandwidth. At the same time, it classifies and normalizes key network performance indicators such as network speed, latency, jitter, and packet loss rate, solving the problems of inconsistent dimensions and opposite optimization directions among multiple indicators, and constructing a standardized network performance indicator matrix that can be used for comprehensive evaluation.

[0072] Furthermore, based on the normalized network performance index matrix, performance index weight vector, and effective payload transmitted per unit time, the performance priority of each communication protocol is calculated. The communication protocol with the highest performance priority is selected as the target protocol. When the time corresponding to the time consumption vector does not exceed the data packet validity time, the data packet is sent to the cloud via the target protocol. In specific implementation, this may include the following steps 4.1 to 4.4: Step 4.1: For each row of the normalized network performance index matrix, which corresponds to the normalized index values ​​of a communication protocol, multiply them by the weights in the performance index weight vector at their corresponding positions and sum them to obtain the comprehensive network performance score of each communication protocol.

[0073] The comprehensive network performance score measures the weighted performance of each communication protocol across network quality dimensions, reflecting the overall adaptability of the protocol to key performance indicators in the current network environment. By weighting and summing dimensionless metrics such as network speed, latency, jitter, and packet loss rate with a performance indicator weight vector extracted based on service quality levels, a fusion evaluation of multi-dimensional performance characteristics is achieved. This ensures that the scoring results reflect the quality of network adaptation under business demand.

[0074] For each row in the normalized network performance metric matrix (i.e., each supported communication protocol), its four corresponding normalized metric values ​​(standardized scores for network speed, latency, jitter, and packet loss rate, respectively) are extracted sequentially. These are then multiplied item by item with the corresponding weights in the performance metric weight vector obtained from the weight database, which matches the current data packet's quality of service level. The four products are then summed to obtain the overall network performance score for that communication protocol. For example, if a protocol has a high latency weight in high real-time scenarios, it may still achieve a high overall score even if its network speed is slightly lower, provided its latency performance is excellent.

[0075] Step 4.2: The overall network performance score is weighted and fused with the corresponding effective payload transmitted per unit time to obtain the performance priority of each communication protocol.

[0076] Performance priority is a comprehensive evaluation metric ultimately used for protocol selection. It includes both the weighted performance of network communication quality (i.e., the overall network performance score) and the performance of actual data transmission efficiency (i.e., the amount of payload transmitted per unit time), thus comprehensively reflecting the overall communication effectiveness of the protocol under the current task. The higher the priority value, the more suitable the protocol is for this data transmission.

[0077] After obtaining the comprehensive network performance score for each communication protocol, a weighted fusion process is performed, combining this score with the effective payload transmitted per unit time calculated in step 3.1. The fusion method can be based on a preset weight ratio according to the system design (e.g., network performance accounts for 60%, transmission efficiency accounts for 40%), or a dynamic adjustment mechanism can be used to adapt to different application scenarios. For example, in bandwidth-sensitive services, the weight of the effective payload transmitted per unit time can be increased; while in control command transmissions, the impact of network stability is emphasized. After fusion, a set of performance priority values ​​equal to the number of supported protocols is generated, forming a performance priority vector.

[0078] Step 4.3: Compare the performance priority of all communication protocols and determine the communication protocol with the highest value as the target protocol.

[0079] The target protocol refers to the communication protocol that is considered most suitable for the current data packet transmission needs after comprehensive evaluation. The selection is based on the principle of maximizing performance priority, that is, under the premise of meeting network conditions and resource constraints, the protocol that can bring the best communication benefits is selected first.

[0080] The performance priority vector output in step 4.2 is iterated and compared to identify the communication protocol corresponding to the highest-valued item, and this protocol is marked as the target protocol. For example, if the performance priority of MQTT is 0.92, which is higher than HTTP's 0.78, CoAP's 0.85, and WebSocket's 0.81, then MQTT is selected as the communication protocol used for this transmission. This decision-making process enables the automatic selection of the optimal path from a multi-protocol candidate set, improving the intelligence level of cloud-edge communication.

[0081] Step 4.4: Determine whether the transmission time corresponding to the target protocol in the time consumption vector is less than or equal to the valid time marked in the data packet. If yes, proceed to the next step; otherwise, abandon this forwarding operation.

[0082] In practice, the transmission time corresponding to the target protocol in the time consumption vector is obtained and compared with the valid time field carried in the data packet. If the transmission time does not exceed the valid time range (i.e., ≤ valid time), the subsequent encapsulation and forwarding process continues; otherwise, if the expected transmission time has expired, the data packet is determined to be invalid, the system actively discards the data packet and records it in the log, and does not initiate any network transmission action.

[0083] This approach constructs a comprehensive network performance score, enabling a quantitative comparison of various communication protocols at the network quality level. It then combines this with a weighted fusion of effective payload transmitted per unit time to form a performance priority system that balances communication stability and transmission efficiency, making protocol selection more closely aligned with actual business needs. Furthermore, by selecting the highest priority protocol as the target protocol and introducing a feasibility verification mechanism based on effective time, it effectively avoids data failure issues caused by transmission delays.

[0084] Furthermore, the aforementioned sending of data packets to the cloud via the target protocol may, in practice, include the following steps 5.1 to 5.3: Step 5.1: Modify the destination address of the data packet to the communication address of the cloud server, and update the protocol identifier field in the message header to the target protocol type.

[0085] The destination address is a crucial field used for routing and addressing data packets during network transmission. Originally, it might point to the edge device itself or intermediate nodes, but it needs to be changed to the actual cloud server's network address (such as IP address and port number) before forwarding to ensure data is correctly delivered to the target service endpoint. The protocol identifier field in the packet header is control information used to identify the type of communication protocol used, which the receiver uses to parse and process the data. Modifying this field allows the cloud to explicitly use the corresponding protocol stack for decoding and response.

[0086] After determining the target protocol and completing the validity verification, the edge device encapsulates and adjusts the original data packet. First, the destination address field in the header is replaced with a pre-configured or dynamically obtained cloud server communication address; second, according to the selected target protocol (such as MQTT, HTTP, etc.), the corresponding protocol type flag is written in the protocol identifier field (for example, setting "protocol_type = MQTT").

[0087] Step 5.2: Start the communication connection mechanism corresponding to the target protocol. After establishing a reliable transmission channel, send the encapsulated data packet to the cloud in segments or as a whole.

[0088] Communication connection mechanisms refer to the session establishment methods relied upon by various cloud-edge communication protocols. For example, HTTP is based on a short-connection request / response model, MQTT relies on a publish / subscribe architecture and maintains sessions through long connections, CoAP uses a lightweight interaction mechanism based on UDP, and WebSocket supports full-duplex persistent connections. Different protocols have different connection management logics. Establishing a reliable transmission channel means completing the handshake negotiation and having the ability to send and receive data, creating a secure communication path.

[0089] The edge device invokes the communication module of the target protocol to initiate a connection establishment operation according to its standard procedure. For the HTTP protocol, a POST request is constructed and submitted to the cloud interface along with authentication information; for the MQTT protocol, it checks whether a valid session already exists, and if not, executes a CONNECT message to connect to the proxy server and completes topic subscription registration; for the CoAP protocol, data interaction is achieved by sending CON or NON messages via UDP. After the connection is successfully established, the data packets with modified addresses and protocol identifiers are encoded according to the protocol format, and the transmission is determined as a whole or in fragments depending on the data size and protocol characteristics. For example, large data can be sent frame by frame in MQTT, while in HTTP it is submitted as a single request body. The entire process ensures that the data is accurately delivered to the cloud according to the requirements of the target protocol.

[0090] Step 5.3: Release the temporary resources occupied by the target protocol after the transmission is completed.

[0091] Temporary resources include system resources such as memory buffers, socket handles, session state information, and timers allocated during the protocol connection process. Timely release of these resources can prevent resource leaks and ensure the long-term stability and multi-tasking concurrency capabilities of edge devices, which is especially important in resource-constrained environments.

[0092] Once all data packets have been successfully sent and a confirmation receipt has been received from the cloud (e.g., an HTTP 200 status code or an MQTT QoS1-level PUBACK message), the edge device triggers a resource reclamation process. This involves closing currently used communication sockets (e.g., TCP connections or UDP ports), clearing relevant cached data, unregistering temporary session contexts, and releasing the dynamically allocated memory space for this transmission. For target protocols using long-lived connections (e.g., MQTT), if the connection is still shared by other pending data transmissions, the connection remains active; otherwise, it is proactively disconnected upon timeout or during idle periods to conserve energy. This mechanism enables fine-grained management of resource usage, improving system efficiency and reliability.

[0093] Furthermore, the above method also includes steps 6.1 to 6.3: Step 6.1: During the local initialization phase, collect evaluation opinions from multiple administrators regarding the importance of various network performance indicators under different service quality levels, and obtain multiple evaluation samples.

[0094] The local initialization phase refers to the basic parameter preparation process performed by edge devices or protocol adaptation systems during initial deployment or configuration updates. This phase involves building key decision-making models to ensure subsequent operation is based on sound scientific principles. "Management personnel" refers to technical experts, network engineers, or business leaders involved in system design and maintenance, possessing professional judgment regarding IoT communication needs and network characteristics.

[0095] In the initial stage of system deployment, evaluation questionnaires were distributed to m managers with relevant domain experience. They were required to independently rate the importance of four network performance indicators under different service quality levels (e.g., "high throughput," "low latency," and "stable transmission") based on their experience in real-world application scenarios. For example, in high real-time scenarios such as emergency alarms, latency and jitter were more important; while in batch upload scenarios, network speed was more important. Each administrator submitted a complete rating vector for each service quality level, forming a set of evaluation samples.

[0096] Step 6.2: Perform a consistency check on multiple evaluation samples under the same service quality level and remove abnormal scores with significant deviations.

[0097] Consistency testing is a data cleaning technique used to ensure the rationality and reliability of group decision-making results. It is used to identify and eliminate abnormal evaluation values ​​that deviate significantly from the opinions of other experts, thus avoiding the impact of individual subjective biases on the objectivity of the overall weight.

[0098] For each preset Quality of Service (QoS) level (e.g., "QoS=High Priority"), all corresponding evaluation samples submitted by administrators are processed centrally. Consistency analysis methods (such as Kendall's coefficient of consistency test or outlier detection based on standard deviation) are used to examine the score distribution for each network performance metric (e.g., latency). If an administrator's score for a particular metric significantly deviates from the group mean (e.g., exceeding twice the standard deviation), and after review, it is confirmed that there is no reasonable technical basis, then this is considered an outlier and removed. Valid evaluation results that meet consistency requirements are retained and proceed to the next stage of aggregation calculation, thereby improving the representativeness and authority of the final weight.

[0099] Step 6.3: Perform aggregation calculations on the retained evaluation results to determine the relative importance distribution of each network performance indicator corresponding to the service quality level. Based on the relative importance distribution, determine the performance indicator weight vector and write it into the weight database for persistent storage.

[0100] Aggregation operations mathematically fuse the selected valid scores, commonly using methods such as arithmetic averaging, weighted averaging, or entropy weighting to generate a comprehensive weight representing group consensus. The relative importance distribution represents the ranking and proportional relationship of the influence of each indicator at a specific service quality level, reflecting the priority differences between different indicators. The performance indicator weight vector is a four-dimensional vector composed of normalized weight values, corresponding to the four indicators of network speed, latency, jitter, and packet loss rate, used for weighted evaluation in subsequent protocol priority calculations.

[0101] In practical applications, for valid evaluation samples that pass the consistency check, the scores of each network performance indicator are horizontally aggregated using the arithmetic mean method to obtain the average score of each indicator under that service quality level. Then, the resulting score vector is normalized so that its sum equals 1, forming a standardized performance indicator weight vector. For example, if the average scores of latency and jitter are significantly higher than the other two items under the "high real-time" level, their corresponding weights will also be higher. Finally, this weight vector is bound to the corresponding service quality level label and stored in a local weight database. Weight vectors for all levels are pre-generated and stored according to this process for dynamic access by edge devices during operation.

[0102] This implementation method enhances the scientific rigor and practicality of the protocol adaptation strategy by introducing professional evaluations from multiple managers during the system initialization phase and constructing a group decision-making-based indicator weight generation mechanism. By performing consistency checks on the evaluation samples, interference from extreme subjective biases is effectively eliminated, improving the robustness and reliability of the weight results. By generating performance indicator weight vectors for each service quality level through aggregation operations and implementing local persistent storage, the protocol selection can dynamically adjust the evaluation focus according to different business needs.

[0103] Furthermore, the above method also includes the following steps 7.1 and 7.2: Step 7.1: Periodically receive evaluation data updated by the system administrator and dynamically correct the existing weight vector.

[0104] A system administrator is a technical operations and maintenance personnel responsible for maintaining the communication policies and protocol adaptation logic of edge devices. They have the authority to adjust the mapping relationship between service quality levels and the importance of performance indicators. Evaluation data refers to the scoring results submitted by administrators based on actual operational feedback or changes in business needs, regarding the relative importance of various network performance indicators under different service quality levels.

[0105] In practice, a periodic triggering mechanism (e.g., monthly) or an event-driven mechanism (e.g., upon detection of a major business change) can be set to proactively prompt system administrators to review and update the importance assessments of existing service quality levels. Administrators upload new scoring samples through the management interface, and the system uses the same methods as the initial construction (such as consistency checks, outlier removal, and aggregation operations) to fuse the new assessment data with historical data, generating a revised performance indicator weight vector.

[0106] Step 7.2: When a new communication protocol is added, a complete network performance metric sampling process is executed to include it in the set of supported communication protocols, and the dimensional range of the redundant data volume mapping table and the network performance metric vector is expanded.

[0107] Adding a new communication protocol refers to introducing a cloud-edge communication method (such as LwM2M, HTTP / 3, etc.) that was not originally supported, to adapt to new network environments or meet specific application requirements. To enable this protocol to participate in subsequent protocol adaptation decisions, a complete performance parameter profile must be established for it. The network performance indicator sampling process has been defined in the preceding content, including the periodic testing of link status, collection of network speed, latency, jitter, and packet loss rate, and will not be repeated here. The redundancy data mapping table records the total amount of additional control information required for each protocol to encapsulate its payload.

[0108] Upon detecting the addition of a new cloud-edge communication protocol to the system configuration, the edge device automatically initiates an initialization probe task. It establishes a connection with the cloud via this protocol, performs standardized data interaction tests, and collects data such as the maximum data throughput under current network conditions as network speed, the average round-trip latency as latency, the difference in latency fluctuations between adjacent signals as jitter, and the proportion of unreceived data packets as packet loss rate, forming a network performance metric vector specific to this protocol. Simultaneously, based on the protocol's standard message structure or actual test results, it determines the amount of additional data required to encapsulate the same payload and writes it into a redundancy data mapping table. Subsequently, in all operations involving the protocol set (such as performance matrix construction and priority calculation), this new protocol will participate as an independent option in the entire process. The system synchronously updates the dimensions of the supported protocol set vector and related data structures to ensure that the algorithm logic covers all available protocols.

[0109] This implementation method enables continuous optimization of protocol adaptation strategies by supporting the periodic receipt of evaluation data updated by system administrators and dynamically correcting existing weight vectors. This allows the system to respond to rule evolution needs arising from shifts in business priorities, network architecture adjustments, or the accumulation of operational experience, enhancing the flexibility and long-term applicability of the solution. Furthermore, a complete parameter modeling process is proposed for new communication protocols, ensuring equal treatment in network performance awareness, transmission overhead calculation, and comprehensive priority evaluation, achieving seamless integration of protocol extensions.

[0110] Figure 2 A specific protocol adaptation flowchart based on network performance characteristics is shown, including the following steps: Step 1: Obtain the set vector of the four cloud-edge communication protocols supported by the edge device. Four typical network communication performance index vectors are selected. .

[0111] Step 2: m experts (admin) evaluate the importance of communication metrics under different QoS levels. Among them, , This indicates that there are no special requirements for latency. This indicates the lowest latency requirement. This indicates the highest latency requirement. It is set at the service quality level. In the case of the i-th administrator The importance score for the j-th communication indicator is: .in, . The larger the value, the more important the communication indicator. An evaluation matrix is ​​formed by the evaluation results of m experts on the four communication indicators. .

[0112] Step 3, Set the service quality level The evaluation matrix under the following conditions is Let the total score of the j-th indicator be... Then the weight of the j-th communication indicator The weights of all indicators constitute the service quality level. The weight vector below Store the weight vectors for all QoS levels in the weight database (SQL).

[0113] Step 4: The edge device obtains network performance metric vectors when communicating with the cloud using different protocols. , Among them, network speed is measured in bytes per second (B / s), latency in milliseconds (ms), jitter in milliseconds (ms), and packet loss in percentage. All performance metric vectors form a performance metric matrix. .

[0114] Step 5: The edge device receives a packet from the terminal device. The packet contains the Quality of Service (QoS) level, the data entity message, and the validity period. The data size of the data entity msg is the payload, measured in bytes.

[0115] Step 6: Obtain the service quality level from the weighted database SQL. Time-based performance index weight vector .

[0116] Step 7: Obtain the amount of extra data required by each protocol to transmit the current data entity msg. This is called redundant data. The redundant data of each protocol forms a redundant data vector. .

[0117] Step 8: Calculate the actual amount of data required to transmit the current data entity msg using each protocol, and form a vector of actual data consumption. .in, .

[0118] Step 9: Calculate the time taken to transmit the current data entity `msg` using each protocol. The time consumed by all protocols in transmitting data forms a time consumption vector. .in, , .

[0119] Step 10: Calculate the amount of data transmitted per unit time. .

[0120] Step 11, if The current data packet will be discarded.

[0121] Step 12, for each performance index in the performance index matrix P, let

[0122]

[0123] For network speed (a positive indicator), use the formula:

[0124] For delay, jitter (joggle), and packet loss (inverse metrics), use the formula:

[0125] The dimensionless performance index matrix is ​​denoted as .

[0126] Step 13: Calculate the performance priority of the i-th communication protocol using the following formula:

[0127] Step 14: Select the final communication protocol according to the following rules. : and

[0128] Step 15: The edge device modifies the destination address (target_destination) in the packet to the cloud address (cloud_addr) and modifies the expiration time in the packet. Using communication protocols Forward data packets to the cloud.

[0129] Compared to current mainstream wireless IoT protocol adaptation methods, the above method considers typical performance indicators of wireless IoT communication, improving the compatibility between communication protocols and network performance; it uses a group decision-making method to calculate the optimal indicator weights under different service quality levels; and it combines the terminal data packet service quality level with data transmission cost to select the protocol that maximizes efficiency for data transmission.

[0130] This application provides an edge device for implementing the aforementioned wireless IoT cloud-edge protocol conversion and adaptation method. The edge device includes a processor and a memory, wherein the memory stores computer program instructions, and when the processor executes the program instructions, it is configured to perform the following operations: Obtain the set of cloud-edge communication protocols supported in the current communication environment; Collect network performance metrics when using different protocols for cloud-edge communication, including network speed, latency, jitter, and packet loss rate, and construct a performance metric matrix. Extract the Quality of Service (QoS), data entity size, and validity period from the received data packets; Based on the index weight vectors corresponding to each QoS level calculated using the group decision-making method and pre-stored in the database, obtain the weight configuration under the current QoS. Obtain the amount of redundant data required for data transmission by each communication protocol, and calculate the total amount of data that actually needs to be transmitted; Based on the actual data volume and network speed, calculate the time required for each protocol to transmit the data packet, and further calculate the amount of data transmitted per unit time (i.e., transmission efficiency). The performance index matrix is ​​made dimensionless, and the overall performance priority of each protocol is calculated by combining the weight vector and transmission efficiency. The communication protocol with the highest priority and a transmission time that does not exceed the validity period of the data packet is selected as the target protocol; Modify the destination address of the data packet to the cloud address, and forward the data packet to the cloud using the selected protocol.

[0131] This edge device, through hardware and software collaboration, enables dynamic and intelligent adaptive selection of cloud-edge communication protocols, improving the communication efficiency and reliability of IoT systems in complex network environments.

[0132] This application provides a wireless IoT cloud-edge protocol conversion and adaptation system. (See also...) Figure 3 As shown, the system includes terminal devices, edge devices, and the cloud, which work together through a wireless network to achieve intelligent adaptation and efficient transmission of communication protocols.

[0133] Specifically, the terminal device is responsible for generating a data packet containing a payload, Quality of Service (QoS) level, and validity period, and sending it to the adjacent edge device. This data packet carries service priority and timeliness information to guide subsequent protocol selection decisions.

[0134] As the core processing node, the edge device receives data packets from the terminal device and performs the following operations: First, it obtains the network performance indicator vectors corresponding to the various currently supported cloud-edge communication protocols (such as HTTP, MQTT, CoAP, WebSocket, etc.), including network speed, latency, jitter, and packet loss rate. Then, based on the quality of service level carried in the data packet, it reads the corresponding performance indicator weight vector, which has been pre-calculated using a group decision-making method, from the locally stored weight database. Next, it calculates the total amount of data that actually needs to be transmitted under each protocol, combining the amount of redundant data required to encapsulate the payload for each protocol. Based on the actual data volume and the measured network speed, it calculates the time required for each protocol to complete the transmission, forming a time consumption vector, and further derives the effective payload transmitted per unit time to measure transmission efficiency. At the same time, it performs dimensionless processing on the original network performance indicators to eliminate dimensional differences and obtain a normalized network performance indicator matrix. Finally, it integrates the normalized indicator matrix, weight vector, and transmission efficiency to calculate the performance priority of each communication protocol and selects the protocol with the highest priority as the target communication protocol—provided that its transmission time does not exceed the effective time of the data packet; otherwise, it is discarded.

[0135] After selecting a protocol, the edge device modifies the destination address of the data packet to the cloud address and uses the target protocol to securely and reliably forward the data packet to the cloud.

[0136] The cloud, as the system backend, receives data packets forwarded by edge devices, parses and processes the payloads within them, and provides corresponding services such as remote monitoring, data analysis, or control response.

[0137] This system implements a dynamic protocol adaptation mechanism oriented towards quality of service and timeliness constraints, which significantly improves the adaptability, efficiency and reliability of cloud-edge communication in complex wireless IoT environments.

[0138] This application also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned wireless IoT cloud-edge protocol conversion and adaptation method. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0139] The computer program product of the wireless IoT cloud-edge protocol conversion and adaptation method, edge device and adaptation system provided in the embodiments of this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0140] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0141] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A wireless IoT cloud-edge protocol conversion and adaptation method, executed by an edge device, characterized in that, include: Obtain the network performance index vectors corresponding to various communication protocols that support communication with the cloud, and read the performance index weight vectors corresponding to the service quality level and determined based on group decision from the weight database stored locally, according to the service quality level of the current data packet to be transmitted. Receive data packets from terminal devices, parse out the payload and quality of service level of the data packets, combine the amount of redundant data required to encapsulate the payload with the amount of communication protocols, calculate the actual amount of data required to transmit the data packets under each communication protocol, and calculate the time required for each communication protocol to complete the transmission based on the network speed and the actual amount of data, and generate a time consumption vector. The effective payload per unit time of each communication protocol is determined based on the time consumption vector, and the indicators in the network performance index vector are dimensionless to obtain the normalized network performance index matrix. Based on the normalized network performance index matrix, the performance index weight vector, and the effective payload transmitted per unit time, the performance priority of each communication protocol is calculated, the communication protocol with the highest performance priority is selected as the target protocol, and when the time corresponding to the time consumption vector does not exceed the effective time of the data packet, the data packet is sent to the cloud through the target protocol.

2. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 1, characterized in that, Obtain network performance indicator vectors corresponding to various communication protocols supporting cloud communication. These vectors include at least network speed, latency, jitter, and packet loss rate. Based on the service quality level of the current data packet to be transmitted, read the performance indicator weight vectors corresponding to the service quality level and determined based on group decision-making from a locally stored weight database, including: Periodically test the communication link status between edge devices and the cloud under different communication protocols, collect the maximum data throughput during the data interaction process per unit time under each communication protocol as network speed, the average round-trip delay of the signal as latency, the difference in adjacent latency fluctuations as jitter, and the proportion of unsuccessfully received data packets as packet loss rate, and generate network performance index vectors corresponding to each communication protocol. Using the quality of service (QoS) level of the current data packet to be transmitted as an index parameter, a matching search is performed in the locally stored weight database to extract the performance index weight vector that is pre-associated with the QoS level and determined based on group decision-making.

3. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 2, characterized in that, The system receives data packets from terminal devices, parses out the payload and quality of service (QoS) level of the data packets, combines the amount of redundant data required to encapsulate the payload according to each communication protocol, calculates the actual amount of data required to transmit the data packet under each communication protocol, and calculates the time required for each communication protocol to complete the transmission based on the network speed and the actual amount of data, generating a time consumption vector, including: The system monitors the upload channel of the terminal device. When a data packet is detected to arrive, it reads the header information of the data packet and extracts the data entity size as the payload and the service quality level corresponding to the service type identifier. Based on the pre-stored protocol overhead mapping table, the amount of redundant data is determined according to the amount of data occupied by the control fields, connection maintenance information and check codes required for each communication protocol to encapsulate the same payload. Based on the redundant data volume corresponding to the payload and each communication protocol, the total amount of data to be transmitted under each communication protocol is calculated as the actual data volume. Based on the actual data volume under each communication protocol and the network speed in the corresponding network performance index vector, calculate the time required for each communication protocol to complete this transmission and generate a time consumption vector.

4. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 3, characterized in that, The unit-time transmission payload of each communication protocol is determined based on the time consumption vector, and the various indicators in the network performance indicator vector are dimensionless to obtain a normalized network performance indicator matrix, including: Divide the payload corresponding to each communication protocol by the corresponding transmission time in the time consumption vector to obtain the effective data transmission amount that each communication protocol can complete per unit time, which is the effective payload transmitted per unit time. The network speed in the network performance metric vector is normalized according to the positive index, and the value is mapped to a uniform range. The latency, jitter, and packet loss rate are normalized according to the inverse indicators, and the values ​​are converted into a form in which higher values ​​indicate better performance. By recombining all the normalized index values, a network performance index matrix with uniform dimensions is obtained.

5. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 4, characterized in that, Based on the normalized network performance index matrix, the performance index weight vector, and the effective payload transmitted per unit time, the performance priority of each communication protocol is calculated, the communication protocol with the highest performance priority is selected as the target protocol, and the data packet is sent to the cloud through the target protocol when the time corresponding to the time consumption vector does not exceed the effective time of the data packet, including: Each row of the normalized network performance index matrix corresponds to a normalized index value of a communication protocol. The values ​​are multiplied by the weights in the performance index weight vector at their corresponding positions and then summed to obtain the comprehensive network performance score of each communication protocol. The overall network performance score is weighted and fused with the corresponding effective payload transmitted per unit time to obtain the performance priority of each communication protocol. Compare the performance priorities of all communication protocols and determine the communication protocol with the highest value as the target protocol. Determine whether the transmission time corresponding to the target protocol in the time consumption vector is less than or equal to the valid time marked in the data packet. If yes, proceed to the next step; otherwise, abandon the forwarding operation.

6. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 5, characterized in that, Sending the data packet to the cloud via the target protocol includes: Modify the destination address of the data packet to the communication address of the cloud server, and update the protocol identifier field in the message header to the target protocol type; Initiate the communication connection mechanism corresponding to the target protocol, and after establishing a reliable transmission channel, send the encapsulated data packet to the cloud in segments or as a whole; Release the temporary resources occupied by the target protocol after the transmission is completed.

7. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 1, characterized in that, Also includes: During the local initialization phase, we collected evaluation opinions from multiple managers regarding the importance of various network performance indicators under different service quality levels, resulting in multiple evaluation samples. Consistency tests were performed on multiple evaluation samples under the same service quality level, and outlier scores with significant deviations were removed. The retained evaluation results are aggregated to determine the relative importance distribution of each network performance indicator corresponding to the service quality level. Based on the relative importance distribution, the performance indicator weight vector is determined and written into the weight database for persistent storage.

8. The wireless IoT cloud-edge protocol conversion and adaptation method according to claim 7, characterized in that, Also includes: It periodically receives evaluation data updated by the system administrator and dynamically corrects the existing weight vector; When a new communication protocol is added, a complete network performance metric sampling process is executed to incorporate it into the set of supported communication protocols, and the dimensional range of the redundant data volume mapping table and the network performance metric vector is expanded.

9. An edge device, characterized in that, It includes a processor and a memory, the memory storing program instructions, which, when executed by the processor, perform the wireless IoT cloud-edge protocol conversion and adaptation method as described in any one of claims 1 to 8.

10. A wireless IoT cloud-edge protocol conversion and adaptation system, characterized in that, This includes terminal devices, edge devices, and the cloud; among them, The terminal device is used to generate a data packet containing a payload, a quality of service level, and a validity period, and send the data packet to the edge device; The edge device is used to receive data packets from terminal devices, obtain network performance index vectors corresponding to various communication protocols supporting communication with the cloud, and the network performance index vectors include at least network speed, latency, jitter, and packet loss rate; according to the service quality level of the data packets, it reads the corresponding performance index weight vector from a locally stored weight database; combined with the amount of redundant data required to encapsulate the payload for each communication protocol, it calculates the actual amount of data required for transmission under each communication protocol, and calculates the time required for each communication protocol to complete transmission based on network speed and actual data amount, generating a time consumption vector; based on the time consumption vector, it determines the effective payload transmitted per unit time, and performs dimensionless processing on each index in the network performance index vector to obtain a normalized network performance index matrix; based on the normalized network performance index matrix, the performance index weight vector, and the effective payload transmitted per unit time, it calculates the performance priority of each communication protocol, selects the communication protocol with the highest performance priority as the target protocol; when the time corresponding to the time consumption vector does not exceed the effective time of the data packet, the target protocol is used to forward the data packet to the cloud. The cloud is used to receive data packets forwarded by edge devices and provide response services.

Images