Multi-protocol edge compression data transmission method, device, equipment and medium

Abstract

This invention relates to the field of IoT communication and data transmission technology, and discloses a multi-protocol edge compression data transmission method, apparatus, device, and medium. The method includes: acquiring raw data from a multi-protocol device and generating protocol feature data; determining the protocol type based on the protocol feature data and parsing it into a unified data format; reading the tags of the unified data format data and performing layered compression to generate compressed data; monitoring network link quality to determine the target transmission link; sending the compressed data to the cloud through the target transmission link and receiving response information; and parsing the response information to update the parameter set to adapt to subsequent data transmission. This invention achieves adaptive adjustment of data parsing, compression, and transmission strategies through collaborative optimization of the edge processing layer and the cloud, improving the efficiency and stability of data transmission in a multi-protocol environment.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication and data transmission technology, and in particular to a multi-protocol edge compression data transmission method, apparatus, device, and storage medium. Background Technology

[0002] The widespread deployment of IoT devices has driven the development of multi-protocol data transmission technology. Although existing technologies have made some progress in the collaborative transmission between different communication protocols, there are still significant shortcomings in multi-protocol compatibility, edge data optimization, and link transmission collaboration.

[0003] Current mainstream solutions mostly employ a single communication protocol or cross-protocol gateway conversion to achieve data interconnection. Single-protocol methods typically rely on fixed communication standards such as WiFi, LoRa, or Bluetooth. While these can provide stable communication in specific scenarios, the significant differences in communication architecture between different protocols make direct interaction between different types of devices difficult. This necessitates the deployment of multiple dedicated gateways when multiple protocol devices coexist, increasing system hardware complexity and maintenance costs. Furthermore, the resource matching between bandwidth and power consumption is unbalanced across different protocols. For example, high-bandwidth protocols consume excessive power in low-power scenarios, while low-bandwidth protocols cannot handle large data transmission tasks, limiting the flexible deployment and operational efficiency of devices.

[0004] To alleviate protocol isolation issues, cross-protocol gateway technologies achieve data interoperability through protocol parsing and format conversion. However, these technologies often focus on data format adaptation without optimizing for data content characteristics. Large amounts of redundant or low-value data are directly transmitted without compression, causing the transmission link to remain under high load for extended periods, resulting in high bandwidth utilization and increased latency. Furthermore, existing protocol conversion strategies are typically statically configured, lacking the ability to adaptively adjust based on real-time network conditions. When link quality changes, the system cannot dynamically select the optimal transmission path or protocol type, leading to increased packet loss and communication instability.

[0005] On the other hand, while edge data compression optimization techniques can reduce transmission load, compression strategies are generally simplistic. Many systems use the same compression algorithm for all types of data, failing to dynamically select compression levels based on data characteristics or importance. This results in low compression efficiency for numerical data and severe distortion for image data. Furthermore, compression processing and transmission protocol selection are independent of each other, lacking a coordinated optimization mechanism between compression strategy, protocol type, and link conditions. Compressed data may still be transmitted via low-speed links, making it difficult to guarantee transmission performance. Summary of the Invention

[0006] The main objective of this invention is to provide a multi-protocol edge compression data transmission method, apparatus, device, and storage medium, aiming to solve the technical problems of existing technologies failing to achieve coordinated adaptive optimization of data parsing, compression strategies, and network link selection in a multi-protocol environment, resulting in low data transmission efficiency, poor network resource utilization, and insufficient system dynamic adaptability.

[0007] To achieve the above objectives, the present invention provides a multi-protocol edge compression data transmission method, comprising: Acquire raw data generated by multi-protocol devices and generate protocol feature data; Based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer, and the original data is parsed into a unified data format using the protocol type. Read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data; Monitor the link quality indicators of the network links, and determine the target transmission link based on the link quality indicators; The compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned by the cloud is received. The control command is parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control command to adapt to subsequent data transmission.

[0008] Furthermore, to achieve the above objectives, the present invention provides a multi-protocol edge compression data transmission apparatus, comprising: The device access module is used to acquire raw data generated by multi-protocol devices and generate protocol feature data. The protocol parsing module is used to determine the protocol type based on the protocol feature data through the protocol parsing module in the edge processing layer, and use the protocol type to parse the raw data into unified data format data. The layered compression module is used to read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data. The link selection module is used to monitor the link quality indicators of network links and determine the target transmission link based on the link quality indicators. The data transmission module is used to send the compressed unified data format data to the cloud interaction layer interface through the target transmission link, and to receive the response information returned by the cloud. The parameter adaptive module is used to parse control commands from the response information and update the compression level and protocol type selection parameters in the parameter set based on the control commands to adapt to subsequent data transmission.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a multi-protocol edge compression data transmission program stored in the memory and executable on the processor, wherein when the multi-protocol edge compression data transmission program is executed by the processor, it implements the steps of the multi-protocol edge compression data transmission method as described above.

[0010] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a multi-protocol edge compression data transmission program, wherein the multi-protocol edge compression data transmission program, when executed by a processor, implements the steps of the multi-protocol edge compression data transmission method as described above.

[0011] Beneficial Effects: This invention relates to the field of IoT communication and data transmission technology, and discloses a multi-protocol edge compression data transmission method, apparatus, device, and medium, comprising: acquiring raw data generated by multi-protocol devices and generating protocol feature data; determining the protocol type based on the protocol feature data through the protocol parsing module of the edge processing layer, and parsing the raw data into unified data format data; reading the data type tags in the unified data format data, performing layered compression processing, determining the compression level based on the data type tags, and generating compressed unified data format data; monitoring the link quality indicators of the network link, and determining the target transmission link based on the link quality indicators; sending the compressed unified data format data to the cloud interaction layer interface through the target transmission link, and receiving the response information returned by the cloud; parsing control commands from the response information, and updating the compression level and protocol type selection parameters in the parameter set based on the control commands to adapt to subsequent data transmission. This invention achieves coordinated control of data parsing, layered compression, and link selection at the edge processing layer, and combines it with the dynamic parameter feedback mechanism of the cloud interaction layer to form an integrated edge-cloud data transmission closed loop. It can adaptively adjust the compression level and protocol type according to network status and data characteristics, thereby improving data transmission efficiency in a multi-protocol environment, reducing bandwidth occupancy, and achieving stable and reliable cross-protocol data interaction. Attached Figure Description

[0012] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a multi-protocol edge compression data transmission method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the multi-protocol edge compression data transmission method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the multi-protocol edge compression data transmission device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

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

[0014] The multi-protocol edge compression data transmission method provided in this invention can be applied to applications such as... Figure 1 In this application environment, the client communicates with the server via a network. The server can obtain raw data generated by multi-protocol devices from the client and generate protocol feature data. Based on the protocol feature data, the protocol parsing module of the edge processing layer determines the protocol type and parses the raw data into a unified data format. The data type tags in the unified data format are read, layered compression processing is performed, and the compression level is determined based on the data type tags to generate compressed unified data format data. The link quality indicators of the network link are monitored, and the target transmission link is determined based on the link quality indicators. The compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned from the cloud is received. Control commands are parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control commands to adapt to subsequent data transmission. This invention achieves coordinated control of data parsing, layered compression, and link selection at the edge processing layer, combined with the dynamic parameter feedback mechanism of the cloud interaction layer, forming an integrated edge-cloud data transmission closed loop. It can adaptively adjust the compression level and protocol type according to network status and data characteristics, thereby improving data transmission efficiency in a multi-protocol environment, reducing bandwidth occupancy, and achieving stable and reliable cross-protocol data interaction. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0015] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the multi-protocol edge compression data transmission method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0016] like Figure 2 As shown, the multi-protocol edge compression data transmission method proposed in this invention includes the following steps: S10: Acquire raw data generated by multi-protocol devices and generate protocol feature data; In this embodiment, acquiring raw data generated by multi-protocol devices refers to continuously receiving and collecting data signals generated by the transport layer or application layer from different types of terminal nodes in a network environment where multiple communication protocols coexist. Raw data typically includes various types such as sensor data, device status information, image data, or log data. The transmission protocols corresponding to different devices may include WiFi, Bluetooth, LoRa, ZigBee, or cellular communication protocols. The acquisition process is achieved by establishing a stable communication session or broadcast listening. A unified data access interface is configured at the edge nodes, which can automatically identify the access protocol and adapt its physical layer and link layer parameters, thereby completing the raw data access in a multi-protocol environment. During the acquisition process, real-time buffering can be performed on the received data stream to avoid packet loss or timing misalignment caused by network jitter.

[0017] Generating protocol feature data involves extracting key information describing data transmission characteristics and protocol structure from the acquired raw data stream. Protocol features typically include protocol version number, packet header structure, field arrangement, verification mechanism, compression identifier, and encryption method. This information reflects the data organization pattern on the source device side and its encapsulation format at the network transport layer. The extraction process can be implemented using a protocol recognition engine, which identifies specific byte sequences of different protocols in data frames based on feature pattern matching and byte stream parsing strategies. To improve recognition accuracy, machine learning models can be introduced to perform feature clustering on unknown or custom protocols, and new protocol type templates can be determined by comparing the distribution patterns of training samples. The generated protocol feature data is stored in a structured format, supporting subsequent parsing and standardization operations.

[0018] In practical implementation, the data acquisition process involves the collaboration of a communication interface management module, a cache scheduling module, and a protocol identification module. The communication interface management module is responsible for maintaining connection status with various devices and dynamically allocating bandwidth resources and port numbers. The cache scheduling module establishes a circular buffer at the receiving end, timestamping and managing the queue of arriving raw data. The protocol identification module reads the data stream from the buffer and performs protocol feature extraction to form unified protocol feature data. The entire process achieves high-throughput data access through asynchronous I / O mechanisms at edge nodes and ensures real-time response from different protocol channels through multi-threaded parallel processing.

[0019] In one implementation, edge nodes are deployed on a local data gateway, simultaneously accessing WiFi, Bluetooth, and LoRa modules via a unified driver. The system uses an asynchronous event listening mechanism to capture data packets from each module and classifies and caches them based on device identifiers. For high-speed transmission devices (such as WiFi cameras), a fragmented buffering strategy is used to aggregate data at the edge; for low-speed or intermittent transmission devices (such as LoRa environment monitoring nodes), a dynamic sampling window is set to ensure data timing integrity. After data acquisition, the parsing module scans the packet header and frame structure to extract protocol fields, combining the identified protocol features into a feature vector. This feature vector is then standardized and output as protocol feature data for subsequent parsing.

[0020] In another implementation, the system is deployed in a centralized control unit within an industrial environment, with pre-defined parsing templates for the communication protocols of different sensors. When a new device is detected, the system automatically identifies the protocol type through the feature packets during the handshake phase and updates the protocol identification library in real time. After the feature data is generated, it is stored in a memory-mapped table and associated with the device identifier, forming a dynamic feature index table for multi-protocol devices.

[0021] In distributed scenarios, data can also be uploaded via remote acquisition agents. Each agent performs preliminary protocol feature extraction locally and uploads only standardized protocol feature data to the central edge node, thereby reducing cross-node transmission load.

[0022] This embodiment acquires raw data from multi-protocol devices at the edge layer and generates protocol feature data, enabling a unified representation of protocol differences during device access and giving the system cross-protocol identification and parsing capabilities. This mechanism effectively reduces uncertainty in subsequent parsing processes, improves data access consistency and processing efficiency, provides standardized input for subsequent compression and transmission, and avoids data loss and incorrect parsing caused by format incompatibility between multi-protocol devices.

[0023] S20, based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer, and the original data is parsed into a unified data format using the protocol type; In this embodiment, the protocol type is determined by the protocol parsing module in the edge processing layer based on protocol feature data. This belongs to the data semantic recognition and unified structured processing process in a multi-protocol environment. Protocol feature data includes structural information extracted from data frames or data packets, protocol version number, field length, header verification rules, and transmission identifiers. The protocol parsing module in the edge processing layer is a multi-channel parsing engine used to perform protocol identification and data destructuring operations after receiving standardized protocol features. The module compares the input protocol features with a pre-stored protocol template library through a feature matching mechanism, determining the specific protocol type based on the feature vector matching result. When the feature matching degree is lower than a preset threshold, the module can invoke a self-learning mechanism to perform pattern clustering and structure inference on unknown protocols, and add newly identified protocol features to the protocol library for dynamic expansion.

[0024] After determining the protocol type, the parsing module loads the corresponding parsing rule set based on that protocol type. The parsing rule set defines the semantic mapping relationships of data fields, data delimiters, field encoding methods, and exception tolerance strategies. The module performs layer-by-layer deconstruction of the raw data according to the rule set, including header parsing, field extraction, byte stream escaping, unit conversion, and exception correction. After parsing, the module performs format correction and field rearrangement on the parsing results, mapping the data to a unified data structure model, forming unified data format data. This unified data format is an intermediate representation, using a key-value pair, timestamp, and source identifier structure, and is compatible with the input requirements of various upper-layer processing modules.

[0025] In its implementation, the protocol parsing module consists of a feature recognition unit, a rule management unit, and a data mapping unit. The feature recognition unit compares the input feature vector with the protocol template for similarity, using a hash index to accelerate the matching process. The rule management unit dynamically loads parsing rules corresponding to the protocol type and maintains version information to prevent rule conflicts. The data mapping unit reassembles the parsing results according to the field order defined in the rule table, generating data in a unified format. This module can run in a containerized edge node environment, achieving real-time parsing of multi-protocol data through a thread pool concurrency mechanism, and supports automatic scaling under different device access densities.

[0026] In one implementation, the edge processing layer deploys a protocol parsing module and pre-sets a template set of common communication protocols. When the input protocol feature data is detected to have the highest matching degree with the WiFi protocol template in the template set, the module automatically selects the WiFi parsing rule, extracts the signal strength, channel number, and data payload fields from the original data, and outputs the extraction results in a unified format.

[0027] In another implementation, the module can process data from various proprietary protocols in an industrial environment. For Modbus protocols of PLC devices and MQTT protocols of sensors, the module uses a dual-thread parallel parsing mechanism to load the corresponding parsing rules when receiving data with different protocol characteristics, thereby simultaneously deconstructing data frames from different sources. The unified data format output by the module is stored in a time-series structure and can be directly used by subsequent compression modules.

[0028] In distributed deployment scenarios, the parsing rule base can be dynamically updated by distributing protocol templates from the cloud. When an edge node receives protocol feature data from a new device, it can retrieve the corresponding parsing template from the cloud and update its local parsing module, thereby enabling rapid access and compatibility with new devices.

[0029] This embodiment achieves structured compatibility with multiple heterogeneous communication protocols by performing protocol type identification and unified data parsing based on protocol feature data at the edge processing layer, reducing the protocol adaptation complexity when devices access the network. This mechanism enables different protocol data to be uniformly converted into a standardized data format at the edge, thus providing consistent input for subsequent layered compression and link selection, and improving the processing stability and real-time response capability of cross-protocol data streams.

[0030] S30: Read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data; In this embodiment, reading data type tags from the unified data format refers to identifying identifier fields from the standardized data structure after the edge node completes protocol parsing. These fields distinguish different content categories, data uses, or priorities. Data type tags originate from metadata generated during the upstream data parsing phase and typically include the data category (e.g., image, log, sensor values), data sampling frequency, timestamp precision, redundancy flags, and processing priority. The tag reading module locates the corresponding fields in the unified data structure using index scanning and keyword matching mechanisms and loads them into a cache for use by the compression module. This tag information plays a guiding role in subsequent layered compression processes, determining the compression level and algorithm selection to ensure a balance between fidelity and transmission efficiency for different types of data after compression.

[0031] The edge processing layer performs hierarchical compression, employing differentiated compression strategies for different data categories after reading the data type tags. Hierarchical compression is achieved by building multi-level compression engines within the edge nodes. Each level of the compression engine corresponds to a different compression level and algorithm combination; for example, a basic compression layer is used for low-priority text and log data, while a higher-level compression layer is used for high-fidelity image or multimedia data. The compression engine calls the corresponding compression method from the algorithm library based on the tag mapping table, which may include lossless compression algorithms based on byte sequence analysis, lightweight predictive coding algorithms based on pattern aggregation, or hybrid compression methods combining block sampling. The system adjusts the compression layer selection based on the data's real-time requirements, target transmission bandwidth, and link status.

[0032] Determining the compression level based on data type tags involves mapping the priority parameters and data categories contained in the tags to a compression strategy rule table to calculate the appropriate compression level for the current data. This level can be represented as the result of a multi-dimensional weighted combination, including indicators such as data importance, update frequency, and bandwidth utilization threshold. The calculation module uses these indicators to determine the compression depth, compression ratio target, and whether to enable additional compression steps (such as differential compression or streaming compression).

[0033] Generating compressed data in a unified format refers to reorganizing the compressed result into a unified data format consistent with the original structure after the layered compression process, ensuring structural compatibility during subsequent transmission and cloud parsing. This process includes repackaging compressed data, updating index records, supplementing metadata, and appending a compression version identifier. The generated data structure retains the original data identifier and field order, while adding a compression identifier field to the metadata section for subsequent decompression modules to quickly identify the corresponding algorithm type.

[0034] In practical implementation, the edge processing layer comprises a tag parsing unit, a compression scheduling unit, and a compression execution unit. The tag parsing unit extracts and caches data type tags; the compression scheduling unit schedules compression tasks based on the tag parsing results and real-time link status, and assigns a compression level to each data block; the compression execution unit calls the algorithm library to complete the compression operation and outputs the results to the cache queue. All units communicate through a shared memory area, achieving millisecond-level response time for streaming layered compression processing.

[0035] In one implementation, the system is deployed at IoT edge nodes to process multi-source data collected by industrial equipment. When the unified data format includes periodic data from temperature sensors and video frames from the production line, the tag parsing unit reads the tag to identify the type fields of the two types of data. The compression scheduling unit assigns a low compression level to the temperature data according to a rule table, using a lightweight lossless compression algorithm; and assigns a high compression level to the video frame data, using a composite compression algorithm of block-level prediction and motion compensation, thereby reducing bandwidth consumption while maintaining image quality.

[0036] In another implementation, the system is applied to the edge nodes of a remote monitoring terminal. The tag parsing unit identifies the voice stream and control command data from the unified data format. The compression scheduling unit assigns a medium compression level to the voice stream, employing an algorithm combining framing and dynamic quantization; the control command data is assigned the lowest compression level to minimize response latency. The final output compressed unified data format retains the tag field and time index to support sequential decoding.

[0037] In multi-node collaborative scenarios, edge nodes can dynamically adjust the compression level based on link status. When network bandwidth decreases, the system increases the compression level and enables chunked compression; when bandwidth recovers, the compression level decreases to improve transmission fidelity, thus achieving a balance between real-time performance and data integrity.

[0038] This embodiment achieves intelligent compression management before data transmission by performing layered compression based on data type tags at the edge processing layer. This enables different types of data to adapt to varying compression depths and algorithm selections. This mechanism reduces invalid data, improves bandwidth utilization efficiency from the edge to the cloud, and ensures data structure consistency and traceability in multi-source heterogeneous data scenarios, thereby enhancing the system's real-time processing capabilities and overall transmission performance.

[0039] S40, Monitor the link quality indicators of the network link, and determine the target transmission link based on the link quality indicators; In this embodiment, monitoring network link quality metrics refers to the collection and quantitative evaluation of real-time performance parameters of each available transmission link in a multi-channel communication environment. Link quality metrics typically include bandwidth utilization, transmission latency, jitter, packet loss rate, signal-to-noise ratio, and connection stability. Edge nodes periodically send probe data packets to target nodes of each candidate link through their built-in link monitoring module, statistically analyzing return time and packet return rate to calculate latency and reliability; simultaneously, they combine this with rate and traffic information fed back from the network interface driver layer to determine real-time bandwidth. Link quality metric data is encapsulated into link status record units and dynamically updated using a sliding time window mechanism to reflect the stability trend of the link over different time periods.

[0040] Determining the target transmission link based on link quality metrics is a comprehensive decision-making process performed after obtaining quality data from multiple links. The system inputs the collected link quality metrics into the link selection model, which calculates the overall quality value of each link using weighted scoring or multi-objective optimization algorithms. The weight parameters can be automatically adjusted according to the application scenario; for example, latency metrics have a higher weight in high real-time scenarios, while bandwidth metrics have a higher weight in big data transmission scenarios. The system selects the link with the highest overall score from the candidate links as the target transmission link. To avoid jitter caused by frequent switching, the module maintains the current link when the score difference is below a threshold and uses a trend prediction mechanism to determine the link stability trend. When the link status deteriorates or is interrupted, the system immediately triggers the link switching process and completes route updates to ensure transmission continuity.

[0041] The link monitoring and selection process is implemented in the edge processing layer, consisting of a link detection unit, an indicator evaluation unit, and a link decision unit. The link detection unit periodically generates detection messages and measures response parameters; the indicator evaluation unit normalizes the monitoring results and corrects anomalies to eliminate short-term interference from network fluctuations; the link decision unit combines real-time scoring with historical trends to select the target link and feeds the results back to the transmission module.

[0042] In one implementation, the system is deployed at the edge node of the industrial control network. The link detection unit periodically collects round-trip latency and packet loss rate data for the primary and backup links using both ICMP echo requests and TCP handshake probes. The performance evaluation unit normalizes latency, bandwidth, and packet loss rate to calculate a comprehensive quality score. The link decision unit selects the primary link based on the score and automatically switches to the backup link when the primary link quality drops below a threshold.

[0043] In another implementation, the system is used in a remote monitoring environment, employing a multi-access communication architecture that simultaneously supports 4G, 5G, and WiFi transmission channels. The link detection unit calculates the real-time rate and signal strength of each channel based on the sampling rate per second; the performance evaluation unit calculates the signal-to-noise ratio and stability of each channel; and the link decision unit executes a multi-dimensional weighted algorithm to select the optimal link, adjusting the selection strategy according to task priority. For example, high-bandwidth links are prioritized for monitoring video transmission tasks, while low-latency links are prioritized for alarm information transmission tasks.

[0044] In vehicle-mounted edge computing scenarios, predictive mechanisms can be used to optimize link selection. The system analyzes historical data on vehicle movement paths and signal strength using machine learning models to predict link quality trends within the next time window, enabling early switching to stable links and reducing the risk of communication interruptions.

[0045] This embodiment enables dynamic management of multi-channel communication environments by monitoring network link quality indicators at edge nodes and determining target transmission links based on evaluation results. This mechanism improves the stability and real-time performance of data transmission, allowing the system to maintain reliable transmission even under bandwidth fluctuations or network congestion. Simultaneously, the link selection strategy based on scoring and trend prediction reduces switching frequency, improves overall network resource utilization, and provides a continuously available transmission channel for the efficient uploading of subsequent compressed data.

[0046] S50, the compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned by the cloud is received; In this embodiment, sending compressed unified data format to the cloud interaction layer interface via the target transmission link means that after link selection and data compression are completed, the edge node performs a data upload operation through the determined target transmission link. The target transmission link is dynamically determined by the link monitoring and selection module, and its corresponding communication path can be a public network, private network, cellular network, or VPN tunnel. During transmission, the system calls the transmission control module to encapsulate the compressed unified data format into a network transmission frame and configure transmission parameters according to the link type, such as the maximum transmission unit size, window sliding rate, and retransmission strategy. The cloud interaction layer interface is the data access endpoint between the edge node and the cloud system, typically a RESTful API, MQTT Topic, or a custom binary stream interface. When sending, the edge node attaches data packet header information, including data source identifier, compression algorithm type, and timestamp, so that the cloud can complete the parsing and decompression processing.

[0047] Receiving response information from the cloud refers to the process by which edge nodes receive feedback from the cloud after sending compressed data in a unified data format, through a maintained session connection or callback mechanism. The cloud interaction layer interface returns response information after completing data reception and parsing. This response may include data processing results, status codes, task identifiers, or further operation instructions. After parsing the response information, the edge node transmits it to the upper-layer application module for status updates, task confirmation, or data return control. When a response timeout or error is detected, the system automatically triggers a retransmission mechanism or switches to a backup link to ensure the integrity and reliability of the communication process.

[0048] In one implementation, the system is deployed in an Industrial Internet of Things (IIoT) environment. After compression processing, the edge nodes send the compressed, uniformly formatted data to the cloud interaction layer interface via the Ethernet main link. The cloud returns a response containing a data reception confirmation flag and task execution instructions. The edge nodes parse this information and trigger the next round of data acquisition.

[0049] In another implementation, the system is applied to a distributed video surveillance scenario. Edge nodes upload compressed, uniformly formatted data to the cloud interaction layer interface via cellular networks. The cloud parses the data and returns the recognition results and model update instructions. Upon receiving the response, the edge nodes update their local model parameters according to the instructions, achieving edge-cloud collaborative optimization.

[0050] This solution can also be deployed in remote medical monitoring environments. Edge nodes send compressed physiological monitoring data to the cloud interaction layer interface via WiFi links. The cloud returns response information containing analysis results, which the edge nodes then parse and display locally to present the real-time health status, achieving a closed loop of continuous monitoring and feedback.

[0051] This embodiment transmits compressed, uniformly formatted data to the cloud interaction layer interface via the target transmission link and receives response information from the cloud, thus realizing a closed-loop data interaction between edge nodes and the cloud. This mechanism ensures reliable data transmission while supporting rapid feedback of cloud processing results, thereby constructing a low-latency, highly reliable edge-cloud collaborative system. Through dynamic link management and structured data encapsulation, the system can maintain stable communication under different network conditions, effectively improving overall data interaction efficiency and the real-time performance of task execution.

[0052] S60, parse the control command from the response information, and update the compression level and protocol type selection parameters in the parameter set based on the control command to adapt to subsequent data transmission.

[0053] In this embodiment, parsing control commands from the response information refers to the edge node performing structured parsing on the response information received from the cloud interaction layer interface to extract the commands used to adjust system operating parameters. The response information is typically encapsulated in JSON or binary format and includes fields such as task status, policy update items, compression configuration, and protocol commands. The parsing module extracts control commands, including compression level adjustment parameters, protocol type switching commands, task execution cycles, and error correction strategies, through key field matching and data decoding. After parsing, the control commands are written to a temporary buffer for use by the parameter update module.

[0054] Updating compression level and protocol type selection parameters in the control command parameter set refers to the edge node dynamically adjusting its system operation configuration based on the parsed control commands to adapt to changes in network conditions and cloud policy requirements. Compression level updates reset the edge node's layered compression strategy, ensuring an optimal balance between compression ratio and data fidelity in subsequent data transmission. Protocol type selection parameter updates switch between various communication protocols (such as HTTP, MQTT, WebSocket, and CoAP) to adapt to different transmission link conditions or task characteristics. After modification, the parameter update module synchronizes the new configuration to the runtime parameter set and automatically takes effect in the next round of data transmission, achieving adaptive adjustment for edge-cloud collaboration.

[0055] In one implementation, the system is deployed in a multi-protocol edge communication environment. Edge nodes receive response information from the cloud, which includes control commands to set the compression level to high and switch the protocol type to MQTT. After recognizing the command fields, the parsing module calls the parameter update module to increase the compression level to high and switch the protocol to MQTT to adapt to the cloud's current receiving bandwidth and real-time processing requirements.

[0056] In another implementation, the system is applied to video surveillance terminals. The cloud generates control commands based on real-time network bandwidth changes, requiring edge nodes to reduce compression levels and switch to the HTTP protocol to improve stability. After parsing the command, the edge nodes update their parameter sets, and subsequent uploaded video streams automatically adopt the new compression ratio and transmission protocol, achieving seamless adaptive transmission.

[0057] It can also be deployed in industrial IoT scenarios. The cloud returns control commands based on link latency monitoring results, instructing edge nodes to enable the fast handshake protocol and improve the compression level. After receiving and parsing the commands, the edge nodes update the parameter set in real time, enabling the system to maintain high-efficiency data transmission performance even in complex network environments.

[0058] This embodiment achieves adaptive closed-loop control between the edge and cloud by parsing control commands from response information and updating compression level and protocol type selection parameters accordingly. This mechanism enables the system to automatically adjust transmission strategies based on real-time link status and cloud policies, avoiding delays and resource waste caused by human intervention, thereby improving data transmission efficiency, link stability, and overall system response speed.

[0059] In one embodiment, step S10 includes: S101, scans multi-protocol devices in the network environment, detects device connection status, records device identifiers and identifies device types; S102, Based on the device identifier and device type, establish a secure communication channel with the multi-protocol device and perform two-way authentication; S103, receive raw data sent by the multi-protocol device in real time on the secure communication channel, and perform real-time buffering and preprocessing on the received data; S104, parse the protocol header information and data packet structure of the original data, and extract protocol feature elements including protocol version, data format and transmission characteristics; S105, normalize the protocol feature elements to generate standardized protocol feature data; S106, verify the integrity and validity of the protocol feature data, and determine the quality score of the feature data; S107, based on the verification results of integrity and validity and the quality score, dynamically adjust the data acquisition parameters and protocol processing strategy.

[0060] In this embodiment, a discovery process combining bounded scanning and passive listening is first performed in the network environment to establish a device list and a link candidate list for multi-protocol devices. The scanning action sets the detection period and dwell time based on frequency band, channel, access medium, and carrier characteristics, and collects beacon frames, service announcements, or connection broadcasts in the listening channel. The discovery results are deduplicated and merged to form a set of "multi-protocol devices," followed by connection reachability testing and heartbeat detection, outputting the connection status. For each entry, stable and temporary identifiers are recorded. The device identifier source is inferred by combining manufacturer markings, hardware fingerprints, broadcast fields, service UUIDs, MAC prefixes, or vendor-assigned numbers. In case of conflicts, priority strategies and consistency checks are introduced to ensure the stable and uniqueness of device identifiers. Device type identification is based on a comprehensive judgment of service message characteristics, product category markings, port and service enumeration, physical interface descriptions, and historical interaction trajectories, distinguishing between sensor terminals, execution terminals, imaging terminals, edge sub-bridges, etc., providing a basis for subsequent communication capability assessment and channel governance.

[0061] After identification, a secure communication channel is established for the target multi-protocol device. Security configuration starts with root trusted materials, combining certificates, pre-shared keys, and key materials in a hardware security element or trusted execution environment to achieve two-way authentication. During the handshake phase, session key derivation, replay protection parameter negotiation, and compression negotiation whitelist synchronization are completed. Link survival employs a parallel strategy of soft and hard timeouts to reduce false positives. After the channel is established, a flow control tag combining sequence numbers and timestamps is enabled to provide anchor points for subsequent out-of-order reordering and packet loss detection. Failure paths for two-way authentication define fallback strategies, including temporary isolation, retry rhythm, and blacklist cooldown time, to avoid frequent invalid connections consuming the scanning and handshake window.

[0062] Continuous reception of raw data is performed within a secure communication channel. The receiving end introduces a circular buffer and sliding window, with two-level queues distinguishing between fast writing and ordered dequeueing. A high-precision clock is used to stamp the reception timestamp at the access boundary, and the source device identifier and channel identifier are attached to the data segment metadata. The preprocessing stage completes packet fragmentation, fragment reassembly, duplicate fragment removal, and missing fragment marking; abnormal lengths, illegal control bits, and unauthorized fields are isolated, outputting a consistent set of raw data frames. To improve subsequent extraction efficiency, the control domain and payload domain are separated and indexed without changing the service load, ensuring rapid location of protocol header information.

[0063] For the raw data frame, the protocol header information and data packet structure are parsed. This parsing does not involve semantic processing of the application load, but focuses on extracting the elements that constitute the differences in communication behavior. The protocol header information includes version markers, flag combinations, sequence fields, length fields, check fields, and option fields. The data packet structure focuses on frame boundaries, fragmentation and reassembly semantics, optional extension headers, encapsulation layers, and multiplexing identifiers. The parser walks through the message byte by byte using a state machine driven by a field table description. When encountering variable-length fields, it uses a length prefix or terminator strategy to determine the boundaries, and when encountering extension headers, it uses chained traversal. During the extraction process, "protocol feature elements" are formed. These elements are used for subsequent unified expression and include discrete markers of the protocol version, the structural paradigm of the data format (such as key-value sequences, TLV, binary frames), and quantifiable indicators of transmission characteristics (such as whether congestion announcement is supported, whether retransmission is available, window mechanism form, keep-alive mechanism form). For abnormal or incomplete messages, only a verifiable subset is output and labeled with confidence level, provided that field consistency is guaranteed, to avoid misleading subsequent judgments.

[0064] The extracted protocol feature elements enter the unified expression stage, generating standardized protocol feature data. The unified expression is driven by a pattern mapping table, mapping heterogeneous elements from multiple sources to a fixed field structure and dictionary space, eliminating naming and enumeration value differences. Unit conversion and dimensional alignment are performed on numerical values, and Boolean and enumeration values ​​are mapped to a controlled vocabulary. For composite structures, flattening and path encoding are used to ensure monotonically comparable results within the key space. To improve downstream matching stability, observation masks and default strategies are applied to missing fields, and the field source and transformation trajectory are provided to support traceability. The standardized results are output as compact binary or structured text, maintaining field order and alignment to facilitate high-speed matching.

[0065] After standardization, completeness and validity verification are performed, and a quality score is generated. Completeness focuses on field completeness, key domain consistency, and verification domain matching; validity focuses on temporal compatibility, field combination constraints, and mutual verification relationships with device types. The verification pipeline aggregates field-level results into a multi-dimensional score vector, covering four dimensions: structural completeness, syntactic consistency, temporal stability, and source reliability, and calculates the overall quality score. Score generation considers recent fluctuations and anomaly proportions within the sliding window, employing gentle updates for sudden anomalies to avoid misleading results from short-term fluctuations. The score, dimension vector, and anomaly summary are written into metadata to provide a basis for subsequent data collection governance.

[0066] Based on the verification results of completeness and validity, and the quality score, data acquisition parameters and protocol processing strategies are dynamically adjusted. Data acquisition parameters include sampling interval, batch size, buffer size, retry rhythm, heartbeat cycle, and timeout threshold. When the quality score continues to decline, sampling and batch strategies are tightened, and retry and heartbeat frequencies are increased to prioritize observability. When the score steadily improves, batch size and sampling are relaxed to increase throughput. Protocol processing strategies include parsing depth, extended header traversal strategy, anomaly tolerance range, field backfilling and inference strategy, and version migration compatibility strategy. For specific device types and known protocol versions, parsing depth and extended header traversal order are adjusted to reduce average latency, and tolerance ranges for jittery fields are relaxed and adjudication times are delayed. Parameter and strategy adjustments adopt a "preset ladder + fine-grained offset" structure to avoid frequent oscillations while retaining the ability to quickly converge to sudden anomalies. All adjustments are recorded in the control plane as rollback records, associated with device identifiers, time windows, and channel identifiers for evidence storage, facilitating problem localization and auditing.

[0067] This embodiment establishes a unified data acquisition and feature generation link for multi-protocol environments. Raw data entering the system can be stably identified, reliably communicated, continuously acquired, structurally extracted, standardized, and its quality measured at the same access surface. Precise device identifier and device type location reduces reliance on upper-layer identification; secure communication channels and two-way authentication reduce the risk of fake sources and tampering; circular buffers and sliding windows maintain reception continuity; extraction of protocol header information and packet structure elements provides a comparable feature set; unified representation resolves heterogeneous semantic discrepancies; and integrity and validity verification provide quantifiable quality scores and drive adaptive adjustments to acquisition parameters and protocol processing strategies.

[0068] In one embodiment, step S20 above includes: S201, the protocol identifier, including the protocol version and data packet structure characteristics, in the protocol feature data is parsed by the protocol parsing module in the edge processing layer; S202, Match the protocol identifier with the protocol templates in the protocol library to determine the protocol type; S203, Based on the protocol type, load the corresponding data parsing rules and parsing algorithm; S204, using the data parsing rules and algorithms, parse the original data into data in a unified data format; S205, verify the integrity and consistency of the unified data format data, and record the parsing log for error tracking.

[0069] In this embodiment, the protocol feature data is first decoded and normalized at the parsing entry point, mapping elements such as protocol version and data packet structure features from byte sequences to internal tag sets. To avoid ambiguity caused by heterogeneous sources, the entry decoding explicitly defines the byte order and alignment. Fixed-length fields are read using direct offset, while variable-length fields are determined based on length prefixes and boundary markers. When an extended header linked list exists, it is traversed by pointer stepping, accumulating an extended capability list and recording the enabled status with a bitmap. This stage outputs a protocol identifier, including version discrete markers, frame structure outlines, fragment reassembly semantics, verification mechanism indicators, and congestion control indicators, forming a feature vector that can be consumed by the matching engine.

[0070] The matching process uses a protocol library as a reference for template alignment. The protocol library employs a template-plus-constraint organizational structure. Each template specifies the order of field appearance, conditions for optional fields, a set of values, and conflict resolution rules. When multiple templates overlap, a score is calculated based on the confidence level of the feature vectors and the constraint satisfaction level. Version priority and historical consistency weights are introduced for sorting, ultimately determining the protocol type. To handle vendor-specific extensions or version evolution, templates allow incremental differential expression. New fields are appended via optional fields without disrupting existing paths. When strong constraints are not met, the matching engine reverts to a compatible template and marks unrecognized fields as reserved fields for subsequent auditing.

[0071] Once the protocol type is determined, the rule and algorithm loading process begins. The parsing module retrieves the parsing rule set and algorithm implementation based on the protocol type. The rule set defines the field extraction order, variable-length field parsing strategy, cross-layer encapsulation and unpacking order, and verification calculation path. The algorithm implementation provides operators for verification calculation, fragmentation and reassembly, option field parsing, timestamp restoration, and sequence replay detection. The loading process considers resource constraints and the number of concurrent sessions, instantiating state machines and buffer pools as needed, and reusing immutable lookup tables to reduce memory usage. For verification and copy operations with hardware offloading capabilities, zero-copy or vectorized interfaces are enabled to reduce CPU usage. The rule version, algorithm version, and protocol type are all embedded into the session context to ensure that subsequent data frames are processed on the same parsing track.

[0072] Data parsing execution is driven by a streaming state machine, transforming raw data into a unified data format. The state machine is built around the message start, header, optional fields, payload, checksum, and end boundaries. Upon entering the header state, fixed fields are extracted according to a rule set, triggering variable-length field decoding. During the payload phase, the encapsulation layers are unpacked layer by layer from the outside in, recording the protocol markers and offset indices for each layer. In fragmented scenarios, the complete payload is reassembled based on fragment markers and offsets, introducing missing fragment markers and timeout decisions to avoid prolonged blocking. Replay detection is based on a comprehensive judgment of sequence and time window, preventing duplicate fragments from entering the formatting pipeline. During field formatting, unit conversion, encoding set unification, time base alignment, and path encoding flattening are performed, mapping heterogeneous key names and semantics to a unified dictionary space, maintaining key order and alignment relationships for high-speed consumption. Missing but inferable fields are backfilled according to an inference strategy and accompanied by source identifiers, while confidence markers for uncertain fields are retained to avoid misuse. After processing, unified data format data is generated, along with metadata such as frame index, source device identifier, protocol type marker, and parsing timestamp.

[0073] Integrity and consistency verification performs structure and relationship checks on the parsed output. Structure checks confirm the completeness of required fields, matching of check fields, consistent lengths, and hierarchical encapsulation closure. Relationship checks verify cross-field constraints and time constraints, such as sequence monotonicity, time rollback detection, fragment coverage integrity, non-overlapping load boundaries, and version and optional field compatibility. Verification failures trigger tiered handling: minor anomalies are flagged with warnings and proceed to subsequent stages while maintaining availability; severe anomalies are isolated and queued for retry or manual intervention. Parsing logs record key operation nodes and anomaly summaries throughout the entire process, including matching decisions, template identifiers, rule versions, operator paths, rollback reasons, snapshots of unidentified fields, and performance sampling. Log writing employs an asynchronous batch strategy and is aligned with the data frame index to ensure traceability and reproducibility.

[0074] To ensure stable operation within the edge processing layer, the parsing module maintains observable metrics and throttling thresholds during execution. When the waiting queue grows or CPU usage exceeds the threshold, it dynamically reduces the extension header depth or delays optional field parsing, prioritizing resources for header parsing and integrity checks to maintain minimum correctness. When the number of sessions increases and causes frequent context switching, it reduces cache jitter through session grouping and affinity scheduling. All adjustments are made without altering the externally unified data format and semantics, avoiding inconsistencies introduced into upper layers.

[0075] This embodiment establishes a standardized, loadable, and verifiable entry point at the edge by using protocol feature data-driven type determination and templated parsing, reducing ambiguity and repeated attempts in scenarios with multiple protocols coexisting. Template matching and differential compatibility lower the reconstruction costs associated with version evolution; rule and algorithm decoupling ensures precise loading and execution down to the protocol instance level; streaming state machines and zero-copy paths reduce latency and processing overhead; and unit conversion and dictionary unification ensure consistent comparability of fields from different sources within a unified data format. Composite structure and relation verification, along with hierarchical processing, enhance output reliability, and parsed logs provide traceability and auditability.

[0076] In one embodiment, step 30 above includes: S301, parse the data type tags in the unified data format data to identify the data content type and data priority; S302, Select the corresponding compression algorithm from the compression algorithm library according to the data content type and data priority; S303, Based on the data type label and the selected compression algorithm, determine the compression level and compression parameters; S304, using the compression algorithm and compression parameters through the edge processing layer, perform layered compression processing on the unified data format data to generate compressed unified data format data.

[0077] In this embodiment, firstly, read-only parsing is performed on the uniform data format data at the edge to locate the offset position and encoding form of the data type tag in the header or metadata area. The tag key name, value field, and version mark are decomposed into internally comparable structures. When the tag has an extended field or a supplier-defined key, a tag mapping table is introduced for standardization. Unmapped entries are submitted to a reserved set and annotated with a source identifier to avoid mismatch. After parsing, two decision factors are obtained: data content type and data priority. These two factors serve as upstream signals for subsequent decisions throughout the entire processing chain.

[0078] The compression algorithm library employs a parallel maintenance approach combining cataloging and feature-based methods. For each compression algorithm, it records applicable data content types, tolerance for missing fields, constraints on out-of-order and fragmentation, and capability tags such as whether it supports streaming processing and parallel slicing. The selector in the edge processing layer searches a candidate set based on a combination of data content type and data priority. If multiple paths with overlapping capabilities exist in the candidate set, the compression algorithm is determined by sorting according to capability matching degree, single-frame overhead, cross-batch throughput, and expected hot cache hit rate of existing sessions. When the tag information is incomplete or ambiguous, the selector reverts to a compatible algorithm and writes the uncertainty into the bypass metadata, ensuring that subsequent stages can perform differentiated processing accordingly. To reduce latency caused by repeated loading, the algorithm library resides on edge nodes as read-only instances and reusable state machine caches; the loading process only involves lightweight references and parameter injection.

[0079] The determination of compression level and compression parameters follows a strategy of tag-driven and resource-constrained collaboration. The strategy engine reads the priority given by the data type tag, real-time link occupancy, computational load of the edge processing layer, and memory level, and combines them to form a candidate range for the compression level. The algorithm side exposes adjustable knobs, including window size, block splitting strategy, dictionary update threshold, transform depth, quantization granularity, and entropy coding context granularity. Within the candidate range, the strategy engine selects specific values ​​for these knobs to form the compression parameters. If the edge node is under high load, the strategy engine favors parameter combinations that are less congested in the streaming state; if link congestion worsens, the compression level is increased and more aggressive block splitting is adopted to increase throughput. The compression level and compression parameters are fixed in the session context along with the frame index of the unified data format data to ensure consistency of processing within the same time window.

[0080] Layered compression processing follows an organizational approach of "structure first, semantic follow-up, and cross-frame collaboration." The structure layer performs field-level deduplication and structural rewriting on fixed headers, indexes, and directory areas in data with a unified data format, preserving the minimum skeleton required for alignment and fast location. The record layer blocks homogeneous record batches, applying deduplication, run-length merging, and dictionary generation, extracting high-frequency keys and common values ​​to a shared table and adding backreference indexes. The payload layer uses corresponding compression algorithms based on data content type, employing matching encoding paths for image, audio, time-series numerical, discrete event, and log text types. The cross-frame collaboration layer establishes historical context within a time window, reusing the dictionary or prediction state of previous blocks, while setting drift detection and context rollback to prevent error propagation. All layers execute in a streaming manner, maintaining unidirectional zero-copy or minimal-copy within the execution thread of the edge processing layer. Block splitting and parallel queues are allocated according to session affinity to reduce cache jitter. After processing, compressed data in a unified format is generated. Necessary metadata is attached to the output side, including data type tag snapshot, compression algorithm identifier, compression level, compression parameter summary, block directory and checksum. The metadata is placed in a fixed location for quick downstream reading.

[0081] Integrity and consistency are verified both before and after compression. Before compression, structural and boundary checks are performed on data in a uniform format to ensure directory closure, length matching, and the presence of critical fields. After compression, verification summaries are generated at both the block and overall levels, and sampled blocks undergo reverse fast decapsulation and field comparison to prevent hidden damage caused by parameter drift. If the compressed metadata is inconsistent with the session context, a lightweight rollback is immediately triggered, reducing the compression level or changing the compression algorithm, and performing layered compression processing again. Details of abnormal paths are written to the compression log and associated with frame indexes, selector decisions, and resource level snapshots to support post-event tracking and online parameter tuning. Resource control is implemented throughout the entire process. When queue backlog or increased latency is detected, layered compression processing automatically reduces the context depth and dictionary refresh frequency of the cross-frame collaborative layer, prioritizing deterministic output from the structure and record layers. When the link is idle and the edge processing layer is lightly loaded, the window and context are appropriately increased to improve the overall compression ratio.

[0082] This embodiment uses data type tags as a unified entry point to transform data content type and data priority into executable decisions. It selects a matching compression algorithm and automatically adapts the compression level and parameters. Layered compression processing operates collaboratively at multiple levels—structure, record, payload, and cross-frame coordination—significantly reducing the size of the compressed, unified data format while maintaining semantic integrity and structural indexability. Tag-driven and resource-constrained collaboration avoids mismatches caused by a one-size-fits-all approach. Load reuse and streaming execution reduce edge latency and computational overhead. Dual-end verification and anomaly fallback improve output reliability. Output metadata enables downstream devices to unpack and quickly locate data as needed, thus stably supporting subsequent link selection and cloud interaction in complex scenarios.

[0083] In one embodiment, step S40 above includes: S401 collects link quality metrics in real time, including bandwidth, latency, packet loss rate, and stability parameters of network links. S402, perform data filtering and normalization on the link quality indicators to generate a standardized link quality dataset; S403, Based on the standardized link quality dataset, calculate the comprehensive quality score for each link; S404, Based on the comprehensive quality score and real-time network conditions, select the optimal transmission link as the target transmission link; S405, perform the switching operation of the target transmission link and verify the connectivity and transmission performance of the target transmission link.

[0084] In this embodiment, a closed-loop monitoring, evaluation, and optimization channel is established around link quality indicators. The monitoring unit is permanently stationed at the edge processing layer, synchronously collecting bandwidth, latency, packet loss rate, and stability parameters for multiple candidate links. Bandwidth is measured using two types of sampling paths: one is based on the transmission byte count and timestamps at the sending and receiving sides to form a throughput trajectory; the other is obtained through small-granular probe packets to obtain instantaneous availability during low-occupancy periods. Latency is measured by generating a latency sequence in parallel through timestamp round-trip probing and uplink unidirectional sampling. The time reference is corrected by comparing the local high-precision clock with the cloud clock to eliminate deviations caused by clock drift. The packet loss rate is generated based on the sequence number and the missing data within the sliding window, and lost data is recorded across windows to avoid duplicate statistics. Stability parameters are composed of latency jitter, bandwidth fluctuation, queue backlog depth changes, and retransmission ratio, used to characterize the link's fluctuation characteristics at short and medium time scales. To reduce observational disturbances, the monitoring unit adaptively controls the detection frequency and message size, shortening the observation window and reducing detection traffic during high load periods, and increasing sampling density to improve resolution during idle periods. All raw observations carry a unified timestamp, link identifier, and sampling source tag before entering the subsequent processing pipeline.

[0085] Data filtering and normalization are performed in a separate cleaning pipeline. First, bandwidth, latency, packet loss rate, and stability parameters are assembled into a time-ordered index vector along the link dimension. A combined mechanism of in-window outlier suppression and trend smoothing is used to remove short-pulse interference and sampling jitter. Anomaly detection uses a dual-threshold approach, employing both cross-quantile difference and adjacent difference thresholds to avoid misjudgments caused by a single threshold. Subsequently, a unified scale is applied, mapping indicators of different dimensions to a common interval between zero and one. Bandwidth uses a piecewise linear mapping bounded by peak value and availability; latency and packet loss rate use an inverse mapping to reflect the preference for lower values; and stability parameters use a combined mapping of volatility and jitter to reflect stability. The resulting standardized link quality dataset is written in batches to a circular buffer, retaining historical slices from the most recent windows to provide temporal context for optimization and switching.

[0086] The overall quality score is generated in the optimizer. The optimizer reads the indicator vectors of the latest and historical windows from the standardized link quality dataset, weights them according to preset weights and hysteresis criteria, and aggregates them to form the overall quality score. Simultaneously, it calculates the rate of change and fluctuation radius of the score to identify short-term peaks and pseudo-optimal links. Weights can be dynamically adjusted according to service profiles; for example, weights are increased for latency and jitter in low-latency services, and for bandwidth and stability in high-throughput services. To reduce optimization jitter, a hysteresis window and a minimum hold duration are introduced. When the overall quality score of a candidate link does not exceed the threshold difference of the current link, the status quo is maintained; when it exceeds the threshold and the duration meets the threshold, the candidate is promoted to the optimal transmission link. Real-time network conditions influence the weights and thresholds through two types of inputs: one from upstream load and queue level, and the other from service-level preferences issued by cloud policies. The optimizer processes these two types of inputs and the score in parallel to avoid bias caused by single-source information dominance.

[0087] The generation and switching of the target transmission link are completed within the transmission manager. The transmission manager receives the optimal transmission link identifier, establishes a pre-connection session in the background, completes handshake, key negotiation, path probing, and maximum transmission unit negotiation, and performs rapid connectivity probing on the end-to-end path. Subsequently, a dual-path parallel phase is implemented, maintaining both the old and new links simultaneously. Within a limited time window, a small number of service units are mirrored, and arrival order and error rate are compared. Once the mirroring result meets a threshold, the new link is switched to as the target transmission link. To reduce out-of-order delivery and retransmissions caused by switching, the transmission manager freezes and rearranges the sending queue at the switching boundary to ensure complete delivery of the sequence before the boundary. For service units requiring real-time performance, a pre-priority queue is used to shorten the switching window. Connectivity is maintained through heartbeats and persistent probing. Heartbeat loss or continuous probing failures trigger a backoff rollback to the previous stable link. Transmission performance enters a verification phase after switching. Throughput, latency, and packet loss are sampled at fixed time slots to form a cold start curve after switching. This curve is compared with the baseline curve before switching. If the deviation exceeds a threshold, the optimizer re-evaluates and initiates a secondary adjustment. All events are logged, including the overall quality score, threshold, weight, mirroring results, and rollback reasons, for future optimization.

[0088] This embodiment uses a weighted aggregation process after unified measurement and cleaning of link quality indicators. The selection of the optimal transmission link and the generation of the target transmission link are driven by a combination of comprehensive quality scores and real-time network conditions. The handover operation suppresses jitter through pre-connection, mirror verification, and hysteresis control. Connectivity and transmission performance are measured and compared before and after the handover. This brings three benefits: First, a multi-dimensional consistent measurement based on bandwidth, latency, packet loss rate, and stability parameters avoids single-indicator bias and ensures optimal selection better matches the business profile. Second, hysteresis and dual-path mirroring reduce frequent and erroneous handovers, minimizing out-of-order transmissions and retransmissions, maintaining stable throughput and latency. Third, post-handover verification and rollback channels shorten abnormal dwell time, ensuring continuity and predictable performance of transmission management in complex network environments, providing a stable entry point for subsequent data transmission and cloud interaction.

[0089] In one embodiment, step S50 above includes: S501, the compressed unified data format data is encapsulated and encrypted to generate a transmission data packet; S502, the data packet is sent to the cloud interaction layer interface through the target transmission link, and the data transmission status is monitored; S503 receives the response information returned from the cloud and buffers and performs preliminary verification on the response information.

[0090] In this embodiment, the compressed, unified data format is first encapsulated and encrypted. The encapsulation consists of three layers: a service header carrying the data source identifier, data type identifier, sequence number, timestamp, and fragmentation information; a transmission header recording the target transmission link identifier, priority label, congestion sensitivity label, and retransmission policy label; and an integrity check segment carrying the integrity check digest and key derivation tag. The encapsulation process fragments and generates a reassembly index according to the maximum transmission unit constraint, assigning each fragment a consecutive sequence number and timestamp to facilitate subsequent out-of-order correction and retransmission selection. Encryption occurs after encapsulation, with the input being the complete data payload and service header, and the output being the ciphertext payload and authentication tag. The key is sourced from the session key pool and selected according to the target transmission link identifier. Key rotation is triggered at fragment boundaries or time thresholds to reduce the risk of long-term key residency. After encryption, a transmission data packet is formed, carrying a short, quickly verifiable check segment for detecting and discarding forged messages en route.

[0091] When data packets are sent to the cloud interaction layer interface via the target transmission link, the transmission subsystem maintains a priority queue and rate limiting valve in front of the sending queue, scheduling data packets from different services according to priority tags and congestion sensitivity tags. The sending path continuously monitors the transmission status, covering round-trip delay trajectory, instantaneous throughput, queuing depth, packet loss alarms, and retransmission ratio. When queuing increases or round-trip delays are abnormal, the sending pace is slowed down, the fragment size is reduced, and priority tags are temporarily reordered. The target transmission link maintains an active session table and keep-alive signal. When the keep-alive signal is lost, it immediately switches to a backup session or fallback link. When the cloud interaction layer interface is unreachable or authentication fails, the transmission subsystem suspends the sending queue, places the data packets to be sent into the retry buffer, and initiates an exponential backoff retry plan. To reduce the impact of switching on upper-layer continuity, the sending path performs mirrored sending of critical data packets within the switching window, delivering them simultaneously through the old and new channels. The cloud interaction layer interface receives them according to a first-come, first-served strategy and deduplicates them using sequence numbers. After the mirrored window ends, only the target transmission link is retained.

[0092] The response information returned from the cloud enters a buffer on the receiving side. The buffer is organized by session and sequence number, and first performs fast integrity verification and authentication tag verification. Only after passing these checks does it proceed to the decryption process. The decrypted response information is first checked for timeliness against the timestamp, and then its correspondence with the active session table is confirmed to exclude replay and cross-session injection. The preliminary verification includes three parts: first, structural validity check, confirming that the response information contains the minimum necessary fields and valid enumeration values; second, session consistency check, confirming that the response information and the target transmission link are consistent in session identifier and key rotation generation; and third, sequence consistency check, using sequence number and timestamp to determine whether it is out of order or lost. If it is out of order, it is rearranged; otherwise, a retransmission request or status query is triggered. Response information that passes the preliminary verification is written to the interactive shared area for subsequent parsing and parameter update processes to read. Response information that fails verification is recorded in the error log with context, including the receiving time, session identifier, verification failure type, and the most recent key rotation information, to help locate the problem.

[0093] To improve overall observability, key events in the encapsulation, transmission, and reception stages all output telemetry logs in a unified format: the encapsulation stage outputs fragment counts, encryption time, and integrity checksums; the transmission stage outputs the target transmission link identifier, queue dwell time distribution, packet loss and retransmission counts, and mirrored window results; and the reception stage outputs the response information arrival delay distribution, decryption time, and verification pass rate. Telemetry logs are reported to the cloud interaction layer interface at low frequency to facilitate joint optimization by remote strategies and local scheduling. All state transitions use atomic updates to avoid misjudgments caused by concurrent race conditions. Logs and buffers use a circular storage mode to maintain high-precision records for the recent period and prioritize the retention of failure contexts when space is limited.

[0094] This embodiment establishes a service header, a transmission header, and an integrity verification segment during the encapsulation stage. The compressed, unified data format acquires an identifiable, fragmentable, and verifiable structure before entering the target transmission link. Through encryption and key rotation, end-to-end confidentiality and tamper resistance are guaranteed. Through priority scheduling, queue rate limiting, and mirroring, the target transmission link maintains a stable arrival order and available throughput during congestion changes and link switching. Through rapid integrity verification, authentication verification, timeliness checks, and sequence consistency checks, response information undergoes basic trustworthiness and integrity screening before entering subsequent processing, and abnormal branches are traceable.

[0095] In one embodiment, step S60 above includes: S601, Perform integrity verification and source verification on the response information; S602, extract control command data from the response information that has passed integrity verification and source verification, and parse the command type and parameter adjustment requirements; S603, Update the compression level parameters in the parameter set according to the parameter adjustment requirements; S604, based on the protocol selection strategy in the control command, update the protocol type selection parameters in the parameter set; S605, verify the compatibility and validity of the updated parameter set; S606 applies the verified parameter set to the subsequent data transmission process to complete parameter adaptation.

[0096] In this embodiment, the access process first performs integrity and source verification on the response information. Integrity verification uses a dual-channel comparison of message authentication tags and digests. Source verification is based on session binding and timestamp verification, combined with a one-time random variable to resist replay. Session binding relies on the established session identifier and key generation, the timestamp is compared with the local time base using a window comparison, and the random variable is verified by pairing the previously issued challenge value with the currently returned response value. After successful verification, the response information is written to a read-only buffer, along with the receiving time and session identifier for subsequent traceability.

[0097] The extraction phase extracts control command data from the response information. For ease of parsing and expansion, the control command data uses a key-value structure, with keys using a fixed namespace and values ​​represented without units. During parsing, field mappings are first selected based on version markers, and then values ​​are retrieved item by item along the field path, including command type, target object, target value, applicable boundaries, and fallback strategy. To avoid command ambiguity, if multiple version markers exist, only the entry with the highest version number is retained, and audit information is recorded.

[0098] The judgment process identifies the command type and parameter adjustment requirements. Command types cover two categories: the first affects compression level parameters, and the second affects protocol type selection parameters. Commands for compression level parameters include three forms: increasing the level, decreasing the level, and setting to a specified level, with upper and lower limits that can be attached to restrict the scope of effect. Commands for protocol type selection parameters include three types of information: preferred protocol set, disabled protocol set, and switching threshold. If conflicting requests occur within the same response message, the command priority field and the effective timing field are used for adjudication; if the priority field is missing, the priority order in the local policy table is used, and the adjudicated item is marked as delayed for manual confirmation.

[0099] The update process atomically replaces the compression level parameters and protocol type selection parameters in the parameter set. Updates to the compression level parameters undergo boundary checks and cross-module consistency checks. Boundary checks compare the new level to locally allowed ranges, while cross-module consistency checks compare the new level to the current data type label and link capability records. If a significant mismatch exists between the new level and the link capability, a downgrade write and delayed reassessment are triggered. Updates to the protocol type selection parameters use a parallel whitelist and blacklist. The whitelist defines the order of candidate protocols, and the blacklist defines the disabled set; the two are combined to generate an effective selection order. To avoid affecting the currently processed data stream, the parameter set uses a versioned structure. New versions are written to the shadow area, and the main pointer is switched only after the reference count reaches zero. This switching action is completed in one step to eliminate race conditions.

[0100] The verification phase performs compatibility and validity checks on the updated parameter set. Compatibility checks focus on two aspects: first, whether there are conflicts with the current session's encryption suite and handshake process; and second, whether there are conflicts with the target transmission link's capability specifications. Validity checks are completed through a rapid trial run. The compression level parameter undergoes a compression and decapsulation process on a small batch of samples to observe whether the time and size changes fall within the expected range; the protocol type selection parameter undergoes a handshake and heartbeat on a sandbox channel to observe connectivity. If any check fails, a rollback to the previous available version is performed, and a difference summary is recorded to increase the rejection weight in the next ruling.

[0101] In the application phase, the validated parameter set is used for subsequent data transmission. Compression level parameters are subscribed to by the compression module of the edge processing layer. The subscription interface is based on a single-write, multi-read queue, and a new version is received and switched in the next batch. Protocol type selection parameters are subscribed to by the link scheduler. After subscription, the candidate queue is refreshed immediately and takes effect in the next link evaluation cycle. To maintain historical traceability, all successfully applied parameter set versions, along with triggered control command data, adjudication results, and verification results, are written to audit storage and retained within a fixed window. In concurrent scenarios, only one parameter set version is allowed to be in a switching state within the same session. New update requests enter a waiting queue, which is dequeued alternately according to time and priority order to avoid frequent jitter.

[0102] This embodiment ensures the reliability of data entering the parsing link by prioritizing the integrity and source verification of response information; through key-value control command data and versioned adjudication processes, adjustment requirements from the cloud can be verifiably mapped to changes in compression level parameters and protocol type selection parameters; through atomic replacement and shadow zone switching, the impact of parameter set updates on the data stream in transit is reduced, avoiding inconsistencies caused by partial reads; through boundary checks, cross-module consistency checks, and small-sample trial runs, incorrect and mismatched configurations are intercepted before taking effect, and the fallback path is clear; through subscription push and effective cycle control, the edge processing layer and link scheduler obtain a controllable update rhythm, and subsequent data transmission achieves targeted optimization in compression efficiency and protocol selection order, while maintaining stable scheduling behavior when link capabilities and data type labels change.

[0103] In one embodiment, a multi-protocol edge compression data transmission device is provided, which corresponds one-to-one with the multi-protocol edge compression data transmission method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the multi-protocol edge compression data transmission device of the present invention. The modules include a device access module 10, a protocol parsing module 20, a layered compression module 30, a link selection module 40, a data transmission module 50, and a parameter adaptive module 60. Detailed descriptions of each functional module are as follows: Device access module 10 is used to acquire raw data generated by multi-protocol devices and generate protocol feature data; Protocol parsing module 20 is used to determine the protocol type based on the protocol feature data through the protocol parsing module in the edge processing layer, and use the protocol type to parse the original data into unified data format data; The layered compression module 30 is used to read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data. The link selection module 40 is used to monitor the link quality indicators of the network link and determine the target transmission link based on the link quality indicators. The data transmission module 50 is used to send the compressed unified data format data to the cloud interaction layer interface through the target transmission link, and to receive the response information returned by the cloud. The parameter adaptive module 60 is used to parse control instructions from the response information and update the compression level and protocol type selection parameters in the parameter set based on the control instructions to adapt to subsequent data transmission.

[0104] In one embodiment, the device access module 10 is specifically used for: Scan multi-protocol devices in the network environment, detect device connection status, record device identifiers, and identify device types; Based on the device identifier and device type, a secure communication channel is established with the multi-protocol device, and two-way authentication is performed; The system receives raw data sent by the multi-protocol device in real time on the secure communication channel and performs real-time buffering and preprocessing on the received data. The protocol header information and data packet structure of the raw data are parsed to extract protocol feature elements, including protocol version, data format, and transmission characteristics; The protocol feature elements are normalized to generate standardized protocol feature data. Verify the completeness and validity of the protocol feature data, and determine the quality score of the feature data; Based on the verification results of completeness and validity and the quality score, dynamically adjust the data acquisition parameters and protocol processing strategies.

[0105] In one embodiment, the protocol parsing module 20 is specifically used for: The protocol parsing module in the edge processing layer parses the protocol identifier, which includes the protocol version and data packet structure characteristics, from the protocol feature data. The protocol identifier is matched with the protocol templates in the protocol library to determine the protocol type; Based on the protocol type, load the corresponding data parsing rules and parsing algorithms; Using the data parsing rules and algorithms, the original data is parsed into data in a unified data format; Verify the integrity and consistency of the unified data format data, and record parsing logs for error tracking.

[0106] In one embodiment, the layered compression module 30 is specifically used for: Parse the data type tags in the unified data format to identify the data content type and data priority; Based on the data content type and data priority, select the corresponding compression algorithm from the compression algorithm library; Based on the data type label and the selected compression algorithm, the compression level and compression parameters are determined; The compression algorithm and compression parameters are used in the edge processing layer to perform layered compression processing on the unified data format data, generating compressed unified data format data.

[0107] In one embodiment, the link selection module 40 is specifically used for: Real-time collection of link quality metrics, including bandwidth, latency, packet loss rate, and stability parameters of network links; The link quality indicators are subjected to data filtering and normalization to generate a standardized link quality dataset. Based on the standardized link quality dataset, calculate the overall quality score for each link; Based on the comprehensive quality score and real-time network conditions, the optimal transmission link is selected as the target transmission link; Perform the switching operation of the target transmission link and verify the connectivity and transmission performance of the target transmission link.

[0108] In one embodiment, the data transmission module 50 is specifically used for: The compressed unified data format data is encapsulated and encrypted to generate a transmission data packet; The data packets are sent to the cloud interaction layer interface via the target transmission link, and the data transmission status is monitored. Receive the response information returned from the cloud, and buffer and perform preliminary verification on the response information.

[0109] In one embodiment, the parameter adaptation module 60 is specifically used for: The response information is subjected to integrity verification and source verification. Extract control command data from the response information that has passed integrity verification and source verification, and parse the command type and parameter adjustment requirements; Update the compression level parameters in the parameter set according to the parameter adjustment requirements; Based on the protocol selection strategy in the control command, update the protocol type selection parameters in the parameter set; Verify the compatibility and validity of the updated parameter set; The validated parameter set is then applied to subsequent data transmission processes to complete parameter adaptation.

[0110] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a multi-protocol edge compressed data transmission method on the server side.

[0111] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a multi-protocol edge compression data transmission method. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Acquire raw data generated by multi-protocol devices and generate protocol feature data; Based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer, and the original data is parsed into a unified data format using the protocol type. Read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data; Monitor the link quality indicators of the network links, and determine the target transmission link based on the link quality indicators; The compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned by the cloud is received. The control command is parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control command to adapt to subsequent data transmission.

[0112] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Acquire raw data generated by multi-protocol devices and generate protocol feature data; Based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer, and the original data is parsed into a unified data format using the protocol type. Read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data; Monitor the link quality indicators of the network links, and determine the target transmission link based on the link quality indicators; The compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned by the cloud is received. The control command is parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control command to adapt to subsequent data transmission.

[0113] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0114] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0116] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method of multi-protocol edge compression data transmission, characterized by, Includes the following steps: Acquire raw data generated by multi-protocol devices and generate protocol feature data; Based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer, and the original data is parsed into a unified data format using the protocol type. Read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data; Monitor the link quality indicators of the network links, and determine the target transmission link based on the link quality indicators; The compressed unified data format data is sent to the cloud interaction layer interface through the target transmission link, and the response information returned by the cloud is received. The control command is parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control command to adapt to subsequent data transmission.

2. The multi-protocol edge compression data transmission method of claim 1, wherein, Acquire raw data generated by multi-protocol devices and generate protocol characteristic data, including: Scan multi-protocol devices in the network environment, detect device connection status, record device identifiers, and identify device types; Based on the device identifier and device type, a secure communication channel is established with the multi-protocol device, and two-way authentication is performed; The system receives raw data sent by the multi-protocol device in real time on the secure communication channel and performs real-time buffering and preprocessing on the received data. The protocol header information and data packet structure of the raw data are parsed to extract protocol feature elements, including protocol version, data format, and transmission characteristics; The protocol feature elements are normalized to generate standardized protocol feature data. Verify the completeness and validity of the protocol feature data, and determine the quality score of the feature data; Based on the verification results of completeness and validity and the quality score, dynamically adjust the data acquisition parameters and protocol processing strategies.

3. The multi-protocol edge compression data transmission method of claim 1, wherein, Based on the protocol feature data, the protocol type is determined by the protocol parsing module in the edge processing layer. The original data is then parsed into a unified data format using the protocol type, including: The protocol parsing module in the edge processing layer parses the protocol identifier, which includes the protocol version and data packet structure characteristics, from the protocol feature data. The protocol identifier is matched with the protocol templates in the protocol library to determine the protocol type; Based on the protocol type, load the corresponding data parsing rules and parsing algorithms; Using the data parsing rules and algorithms, the original data is parsed into data in a unified data format; Verify the integrity and consistency of the unified data format data, and record parsing logs for error tracking.

4. The multi-protocol edge compression data transmission method as described in claim 1, characterized in that, Read the data type tags from the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level based on the data type tags, and generate compressed unified data format data, including: Parse the data type tags in the unified data format to identify the data content type and data priority; Based on the data content type and data priority, select the corresponding compression algorithm from the compression algorithm library; Based on the data type label and the selected compression algorithm, the compression level and compression parameters are determined; The compression algorithm and compression parameters are used in the edge processing layer to perform layered compression processing on the unified data format data, generating compressed unified data format data.

5. The multi-protocol edge compression data transmission method as described in claim 1, characterized in that, Monitoring network link quality metrics and determining target transmission links based on these metrics includes: Real-time collection of link quality metrics, including bandwidth, latency, packet loss rate, and stability parameters of network links; The link quality indicators are subjected to data filtering and normalization to generate a standardized link quality dataset. Based on the standardized link quality dataset, calculate the overall quality score for each link; Based on the comprehensive quality score and real-time network conditions, the optimal transmission link is selected as the target transmission link; Perform the switching operation of the target transmission link and verify the connectivity and transmission performance of the target transmission link.

6. The multi-protocol edge compression data transmission method as described in claim 1, characterized in that, The compressed, unified data format is sent to the cloud interaction layer interface via the target transmission link, and the response information returned by the cloud is received, including: The compressed unified data format data is encapsulated and encrypted to generate a transmission data packet; The data packets are sent to the cloud interaction layer interface via the target transmission link, and the data transmission status is monitored. Receive the response information returned from the cloud, and buffer and perform preliminary verification on the response information.

7. The multi-protocol edge compression data transmission method as described in claim 1, characterized in that, The control command is parsed from the response information, and the compression level and protocol type selection parameters in the parameter set are updated based on the control command to adapt to subsequent data transmission, including: The response information is subjected to integrity verification and source verification. Extract control command data from the response information that has passed integrity verification and source verification, and parse the command type and parameter adjustment requirements; Update the compression level parameters in the parameter set according to the parameter adjustment requirements; Based on the protocol selection strategy in the control command, update the protocol type selection parameters in the parameter set; Verify the compatibility and validity of the updated parameter set; The validated parameter set is then applied to subsequent data transmission processes to complete parameter adaptation.

8. A multi-protocol edge compression data transmission device, characterized in that, The multi-protocol edge compression data transmission device includes: The device access module is used to acquire raw data generated by multi-protocol devices and generate protocol feature data. The protocol parsing module is used to determine the protocol type based on the protocol feature data through the protocol parsing module in the edge processing layer, and use the protocol type to parse the raw data into unified data format data. The layered compression module is used to read the data type tags in the unified data format data, perform layered compression processing through the edge processing layer, determine the compression level according to the data type tags, and generate compressed unified data format data. The link selection module is used to monitor the link quality indicators of network links and determine the target transmission link based on the link quality indicators. The data transmission module is used to send the compressed unified data format data to the cloud interaction layer interface through the target transmission link, and to receive the response information returned by the cloud. The parameter adaptive module is used to parse control commands from the response information and update the compression level and protocol type selection parameters in the parameter set based on the control commands to adapt to subsequent data transmission.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a multi-protocol edge compression data transmission program stored in the memory and executable on the processor, wherein the multi-protocol edge compression data transmission program, when executed by the processor, implements the steps of the multi-protocol edge compression data transmission method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a multi-protocol edge compression data transmission program, which, when executed by a processor, implements the steps of the multi-protocol edge compression data transmission method as described in any one of claims 1-7.

Images