Cloud collaborative docking station multi-link aggregation optimization method and system

Abstract

The invention discloses a cloud collaborative docking station multi-link aggregation optimization method and system, and relates to the related field of data communication networks, and the method comprises the steps: a docking station collects state parameters of available network links in real time, carries out the application-level task recognition of a data flow, and obtains task features; uploading the link state parameters and the task features to a cloud control platform for link scheduling strategy analysis, and generating a link scheduling strategy; the edge agent completes decomposition processing of the task data according to a strategy to generate a task data packet; and the execution hardware performs aggregation according to link selection, fragmentation and scheduling strategies, records task completion quality, link performance and user experience indexes through the docking station, and returns the task completion quality, the link performance and the user experience indexes to the cloud control platform for iterative optimization. The technical problems of insufficient utilization of link resources, low data transmission efficiency and poor user experience in existing docking station multi-link aggregation optimization are solved, and the technical effects of fully utilizing the link resources and improving the data transmission efficiency and the user experience are achieved.

Description

Technical Field

[0001] The present application relates to data communication network related fields, and in particular to a cloud-coordinated docking station multi-link aggregation optimization method and system. Background Art

[0002] In cloud collaboration scenarios, the docking station, as a hub device connecting multiple links, needs to handle complex requirements such as high-speed data transmission, multi-task scheduling, and dynamic link switching. Its multi-link aggregation performance directly affects data transmission efficiency, system stability, and user experience. The main methods currently used to solve the problem of multi-link aggregation optimization of the docking station in cloud collaboration are to use local devices to select links and allocate data according to preset rules, or to perform link scheduling through a simple centralized control platform. Due to the limited computing resources of local devices, the current methods are difficult to fully obtain all link status information in real time and make accurate link scheduling decisions. Although the centralized control platform can obtain more information, it lacks a deep understanding of application-level tasks and cannot perform flexible and optimized link scheduling according to the characteristics of different tasks, resulting in insufficient link resource utilization, low data transmission efficiency, and poor user experience.

[0003] In the current related technologies, the multi-link aggregation optimization of the expansion dock has technical problems such as insufficient link resource utilization, low data transmission efficiency and poor user experience. Summary of the Invention

[0004] The present application provides a cloud-collaborative expansion dock multi-link aggregation optimization method and system, which adopts the method that the expansion dock collects the status parameters of all available network links in real time, and performs application-level task identification on the input data stream to extract task features, uploads the link status and task features to the cloud control platform, uses the cloud learning module to analyze and generate the optimal link scheduling strategy, and sends it to the edge intelligent agent. The edge intelligent agent decomposes and processes the task data into data packets according to the strategy, and the execution hardware aggregates and transmits the data according to the strategy. The expansion dock records the task completion quality, link performance and user experience indicators in real time, and feeds back to the cloud platform for continuous optimization of scheduling strategies and other technical means, solves the technical problems of insufficient link resource utilization, low data transmission efficiency and poor user experience in the existing expansion dock multi-link aggregation optimization, and achieves the technical effect of fully utilizing link resources, improving data transmission efficiency and user experience.

[0005] The present application provides a cloud-collaborative expansion dock multi-link aggregation optimization method, comprising: collecting the status parameters of all available network links in real time through the expansion dock, performing application-level task identification on the data stream entering the expansion dock, and obtaining task characteristics; uploading the link status parameters and task characteristics to a cloud control platform, performing link scheduling strategy analysis using a learning module deployed in the cloud, generating a link scheduling strategy, and sending it to an edge intelligent agent; the edge intelligent agent completes the decomposition and processing of the task data according to the received link scheduling strategy, generates a task data packet and distributes it to the control execution hardware; the execution hardware aggregates according to the link selection, segmentation, and scheduling strategy in the task data packet, and records the task completion quality, link performance, and user experience indicators in real time through the expansion dock, and transmits them back to the cloud control platform for iterative optimization of the learning module.

[0006] In a possible implementation, the link scheduling strategy is generated and sent to the edge intelligent agent, and then the following processing is performed: a mapping relationship between the link scheduling strategy and the link state parameters and task characteristics is established to construct a strategy list; a strategy cache space is set on the expansion dock side, and the strategy list is stored in the strategy cache space. When the cloud control platform is disconnected or the response exceeds the threshold, link scheduling aggregation is performed based on the pre-stored strategies in the strategy cache space.

[0007] In a possible implementation, application-level task identification is performed on the data flow entering the expansion dock to obtain task characteristics, and the following processing is performed: a traffic identification model is deployed at the edge to identify the task type of the data flow entering the expansion dock; task levels are divided according to the identified task type, and data flow characteristics, task types and their task levels are used as the task characteristics.

[0008] In a possible implementation, the following processing is performed: the link state parameters include: link bandwidth, delay, packet loss rate, jitter value, and unit transmission cost.

[0009] In a possible implementation, the learning module deployed in the cloud is used to analyze the link scheduling strategy, generate the link scheduling strategy, and perform the following processing: combining the received link state parameters with the task characteristics to construct a feature vector; inputting the feature vector into a pre-trained scheduling model to analyze the link scheduling action and construct the link scheduling strategy, including the target link number, the task slice size, whether to start the redundancy mechanism, the bandwidth allocation ratio, and the delay tolerance parameter.

[0010] In a possible implementation, the edge agent completes the decomposition processing of the task data according to the received link scheduling strategy, generates a task data packet and distributes it to the control execution hardware, and performs the following processing: reads the link scheduling strategy, obtains the sharding parameters, target link list and scheduling strategy field; decomposes the original task data stream into multiple logical data segments according to the sharding parameters; encapsulates each logical data segment into a task data packet, and the task data packet includes a task number, shard number, link selection number, priority label and optional error correction control flag; sends the generated task data packet to the interface module of the control execution hardware for link distribution and data transmission.

[0011] In a possible implementation, the received link state parameters are combined with the task characteristics to construct a feature vector, and the following processing is performed: the link state parameters are normalized to form a link state feature vector; the task characteristics are structured encoded to form a task requirement vector; the link state feature vector and the task requirement vector are spliced ​​into a unified feature vector.

[0012] In a possible implementation, the following processing is also performed: based on the transmission response relationship between link state parameters and fragmentation granularity, the interests are balanced according to the link bandwidth, delay, packet loss rate, and jitter value in the link state parameters to determine the optimal fragmentation granularity; according to the task type and task level in the task characteristics, the transmission constraint parameters are determined; the optimal fragmentation granularity is adjusted and optimized using the transmission constraint parameters to obtain the fragmentation granularity constraint; the fragmentation granularity constraint is added as a constraint condition to the scheduling model to participate in the generation of link scheduling actions.

[0013] In a possible implementation, the link scheduling strategy supports multi-link heterogeneous aggregate transmission and performs the following processing: setting differentiated rate allocation ratios according to different link transmission credits, where the transmission credits are obtained by evaluating the actual performance of the links based on historical records; based on the current rate allocation ratio, determining the task data load sharing ratio corresponding to each link, which is used to control the distribution ratio of task data among multiple links; when the main link is abnormal, adjusting the task distribution strategy according to the load sharing ratio, automatically switching to the preset backup link and reallocating the rate ratio to ensure that the task is not interrupted in transmission; wherein, the multi-link heterogeneous aggregate transmission supports dynamic link online and offline, and when a new link is added or an existing link is disconnected, the rate allocation ratio and load sharing ratio are automatically updated without interrupting the current task transmission process.

[0014] The present application also provides a cloud-collaborative expansion dock multi-link aggregation optimization system, including: an application-level task identification module, which is used to collect the status parameters of all available network links in real time through the expansion dock, perform application-level task identification on the data stream entering the expansion dock, and obtain task characteristics; a link scheduling strategy analysis module, which is used to upload the link status parameters and task characteristics to the cloud control platform, use the learning module deployed on the cloud to perform link scheduling strategy analysis, generate a link scheduling strategy, and send it to the edge intelligent agent; a decomposition processing module, which is used by the edge intelligent agent to complete the decomposition and processing of task data according to the received link scheduling strategy, generate task data packets and distribute them to the control execution hardware; an aggregation optimization module, which is used to execute hardware to aggregate according to the link selection, fragmentation, and scheduling strategies in the task data packets, and record the task completion quality, link performance and user experience indicators in real time through the expansion dock, and transmit them back to the cloud control platform for iterative optimization of the learning module.

[0015] The present application proposes a cloud-coordinated docking station multi-link aggregation optimization method and system. First, the docking station collects the status parameters of all available network links in real time, performs application-level task identification on the data stream entering the docking station, obtains task characteristics, and then uploads the link status parameters and task characteristics to the cloud control platform. The learning module deployed in the cloud is used to analyze the link scheduling strategy, generate a link scheduling strategy, and send it to the edge agent. The edge agent then completes the decomposition and processing of the task data according to the received link scheduling strategy, generates a task data packet and distributes it to the control execution hardware. Finally, the execution hardware aggregates according to the link selection, fragmentation, and scheduling strategy in the task data packet, and records the task completion quality, link performance, and user experience indicators in real time through the docking station, and transmits them back to the cloud control platform for iterative optimization of the learning module. The technical effect of fully utilizing link resources, improving data transmission efficiency and user experience is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention are briefly introduced below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in precise order. Instead, various steps may be processed in reverse order or simultaneously as needed. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0017] Figure 1 A flowchart of a cloud-collaborative docking station multi-link aggregation optimization method provided in an embodiment of the present application.

[0018] Figure 2A schematic structural diagram of a cloud-collaborative docking station multi-link aggregation optimization system provided in an embodiment of the present application.

[0019] Description of the accompanying drawings: application-level task identification module 10, link scheduling strategy analysis module 20, decomposition processing module 30, aggregation optimization module 40. DETAILED DESCRIPTION

[0020] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below.

[0021] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0022] In the following description, reference is made to “some embodiments” which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. The terms “including” and “having” and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application only.

[0023] The embodiment of the present application provides a cloud-coordinated docking station multi-link aggregation optimization method, such as Figure 1 As shown, the method includes: Step S100 : The state parameters of all available network links are collected in real time through the expansion dock, and application-level task recognition is performed on the data stream entering the expansion dock to obtain task features.

[0024] Specifically, a docking station is a connection device used to expand the interface functions of a computer or other electronic device. It includes multiple network interfaces (such as Ethernet, Wi-Fi, Bluetooth, etc.) and other peripheral interfaces (such as USB, HDMI, etc.). Link status parameters are used to describe the performance of network links, including signal strength, bandwidth, packet loss rate, latency, etc. Application-level task identification refers to analyzing the content, format, protocol, and other characteristics of the data stream to determine the application type (such as web browsing, video conferencing, file transfer, etc.) to which the data stream belongs.

[0025] Specifically, the dock's hardware interfaces begin to work, monitoring the status parameters of each network link (such as Wi-Fi signal strength and wired network bandwidth). The dock has multiple built-in network interfaces (such as Ethernet, Wi-Fi chips, and Bluetooth modules). Hardware sensors on these interfaces monitor each network link's signal strength, bandwidth, packet loss rate, latency, and other status parameters in real time. For example, the Wi-Fi chip measures signal strength using the RSSI (Received Signal Strength Indicator) value and calculates packet loss rate and latency by periodically sending test packets and counting the return data. For example, a test packet might be sent every second, recording which packets are lost and the round-trip time for each packet. For wired network interfaces, hardware sensors monitor bandwidth usage, packet loss rate, and latency. For example, by monitoring the network interface's traffic statistics, current bandwidth utilization can be calculated.

[0026] The network monitoring software obtains detailed information from the protocol stack in real time, further improving the recording of link status parameters. The docking station's operating system runs a dedicated network monitoring software driver that works closely with the network protocol stack to obtain detailed information about the network link status in real time. For example, in the TCP / IP protocol stack, by analyzing the TCP connection's acknowledgment (ACK) information, it can determine packet loss and network latency. These status parameters are recorded in real time, forming a set of parameters including signal strength, bandwidth, packet loss rate, and latency.

[0027] After data streams enter the dock, they are initially identified using Deep Packet Inspection (DPI) technology to determine their protocol type and port number. DPI can identify information such as the protocol type, port number, and data format of a data packet, thereby determining the application type to which the data stream belongs. For example, by detecting HTTP / HTTPS protocol characteristics, web browsing tasks can be identified; by analyzing the FTP protocol port and data transmission mode, file transfer tasks can be identified.

[0028] If DPI cannot determine the task type, it extracts the data stream's features and feeds them into a machine learning classification model for further classification. The model analyzes the data stream's characteristics, such as packet size distribution, traffic patterns, and protocol combinations. For example, for a data stream, the model extracts its characteristics (such as average packet size and traffic fluctuations). The model then calculates the characteristics of the data stream and determines which application task it belongs to (e.g., web browsing, file transfer, video conferencing, etc.). Ultimately, the dock obtains the characteristics of each task and packages them along with link status parameters for upload.

[0029] For example, suppose a user connects to both a wired and Wi-Fi network through a docking station and simultaneously opens video conferencing software and a web browser. The dock's Wi-Fi chip detects a Wi-Fi signal strength of -50dBm, a packet loss rate of 1%, and a latency of 30ms; the wired network interface detects a bandwidth of 100Mbps, a packet loss rate of 0.1%, and a latency of 1ms. After the data stream enters the dock, DPI technology identifies the video conferencing software's data stream as using the UDP protocol, port numbers 10000-10010, with uneven packet size distribution and real-time characteristics, initially determining it as a video conferencing task. A machine learning model further confirms this identification. DPI technology identifies the web browser's data stream as using the HTTP / HTTPS protocol, port numbers 80 and 443, with small packet sizes and frequent interactions, determining it as a web browsing task. The dock packages link status parameters (such as Wi-Fi signal strength and wired network bandwidth) with task characteristics (such as video conferencing or web browsing) for upload.

[0030] In one possible implementation, application-level task identification is performed on data flows entering the docking station to obtain task features. Step S100 further includes step S110, where a traffic identification model is deployed at the edge to identify the task type of the data flows entering the docking station. Specifically, a pre-trained traffic identification model is deployed at the edge (i.e., the docking station or a device directly connected to the docking station). This model, built based on machine learning or deep learning algorithms, can analyze the characteristics of the data flow to identify the task type to which the data flow belongs. For example, the model can perform identification based on features such as the data flow's protocol type, port number, packet size distribution, and traffic pattern. Specifically, the data flow type is determined by inspecting the protocol header information (e.g., TCP, UDP, HTTP, HTTPS, etc.) of the data packet. Common applications typically use fixed port numbers, such as HTTP using port 80, HTTPS using port 443, and FTP using port 21. Different application types generate data packets of different sizes. For example, web browsing generates a large number of small data packets, while video streaming generates larger data packets. Time series features of the data flow are analyzed, such as the frequency and interval between data packet transmissions. Real-time applications (such as video conferencing) usually have a higher packet sending frequency, while file downloads pay more attention to the packet size.

[0031] When data streams enter the dock, the traffic identification model extracts features of the data stream in real time and feeds them into the model for analysis. Based on pre-trained rules or algorithms, the model determines which task type the data stream belongs to (such as web browsing, video conferencing, file downloading, etc.) and records the identified task type as part of the task signature. For example, if the model detects that the data stream uses the UDP protocol, port numbers 10000-10010, and has an uneven packet size distribution and a high transmission frequency, it can be identified as a video conferencing task.

[0032] Step S120, classify the tasks into different levels according to the identified task type, and use the data flow characteristics, task type and its task level as the task characteristics. Specifically, tasks are divided into different levels based on factors such as the importance of the task type, real-time requirements and resource requirements. For example: high-priority tasks (such as video conferencing, real-time games, etc.) have high requirements for real-time and bandwidth, and any delay or packet loss may seriously affect the user experience. Medium-priority tasks (such as web browsing, online video streaming, etc.) have certain requirements for real-time, but can tolerate a certain degree of delay. Low-priority tasks (such as file downloads, background updates, etc.) have lower requirements for real-time and can be performed when network resources are more abundant.

[0033] A task classification module is deployed at the edge (docking station or related equipment). This module classifies tasks based on task type identification and predefined rules. For example, if the identified task type is a video conference, it is classified as a high-priority task; if it is a file download, it is classified as a low-priority task. The task level is recorded along with the data flow characteristics and task type to form a complete task profile.

[0034] This approach deploys traffic identification models and task classification modules at the edge, enabling rapid and accurate task type identification and classification. This not only improves task scheduling accuracy but also optimizes resource allocation, reduces cloud computing pressure, and enhances system real-time performance and responsiveness.

[0035] In step S200, the link state parameters and task characteristics are uploaded to the cloud control platform, and the link scheduling strategy is analyzed using the learning module deployed in the cloud to generate a link scheduling strategy and send it to the edge agent.

[0036] Specifically, the cloud control platform is a server or server cluster deployed in the cloud. It receives and processes data from the docking station and runs a learning module to analyze link scheduling policies. The edge agent is a device or software entity located at the edge of the network. It receives the link scheduling policies sent by the cloud control platform and decomposes, processes, and distributes task data according to the policies.

[0037] Specifically, the dock encapsulates the collected link state parameters and mission characteristic data and converts it into JSON (a lightweight data exchange format). For example, the data is encapsulated into a JSON object containing fields such as signal strength, bandwidth, and mission type. The encapsulated data is encrypted using the SSL / TLS encryption protocol to ensure security and integrity during transmission. The dock then transmits the encrypted data to the cloud control platform via a network interface (such as Wi-Fi or a wired network). Upon receiving the data, the cloud control platform decrypts and parses it to extract the link state parameters and mission characteristics.

[0038] The cloud control platform's learning module uses reinforcement learning algorithms (such as Q-learning or DQN) to find the optimal link scheduling strategy based on link status and task characteristics. For example, the algorithm calculates the optimal link selection and task allocation based on the current link bandwidth and latency, as well as the real-time requirements of the task (e.g., low latency for video conferencing, higher latency for file downloads). The algorithm continuously tries different strategies and evaluates their effectiveness based on task completion quality and user experience metrics (such as video freeze rate and file download speed), thereby continuously optimizing the scheduling strategy. The cloud control platform stores a large amount of historical data, including past link status, task characteristics, scheduling strategies, and corresponding execution results. The learning module uses this historical data for training and further optimizes the scheduling strategy by analyzing past successes and failures.

[0039] The cloud control platform encapsulates the generated link scheduling policy into a message and sends it to a message queue (such as RabbitMQ or Kafka). The edge agent obtains the link scheduling policy from the message queue through a pre-registered API interface.

[0040] In a possible implementation, step S200 further includes: the link state parameters include: link bandwidth, delay, packet loss rate, jitter value, and unit transmission cost.

[0041] Specifically, link state parameters are crucial for the cloud control platform to analyze link scheduling strategies. To more comprehensively evaluate network link performance, link state parameters include not only traditional bandwidth, latency, and packet loss rate, but also jitter and unit transmission cost. The specific definitions and functions of these parameters are as follows: Link bandwidth refers to the maximum amount of data a network link can transmit per unit time, measured in bits per second (bps) or bytes per second (B / s). Bandwidth directly affects data transmission speed. High-bandwidth links are suitable for tasks with large data volumes, such as HD video streaming or large file downloads. Latency refers to the time required for data to travel from the sender to the receiver, measured in milliseconds (ms). Latency significantly impacts real-time-critical tasks, such as video conferencing and online gaming. Low-latency links provide a smoother user experience. Packet loss rate refers to the percentage of lost packets compared to the total number of packets sent during network transmission. Packet loss rate reflects network reliability. A high packet loss rate may lead to data retransmission, increasing transmission delay and impacting user experience. Jitter refers to the variability of network latency, or the range of latency fluctuation, reflecting the stability of network transmission, measured in milliseconds (ms). Jitter significantly impacts real-time tasks (such as voice calls and video conferencing). Links with lower jitter provide more stable transmission. Unit transmission cost refers to the cost of transmitting a unit of data (e.g., per megabyte), reflecting the cost differences between different links. In a multi-link environment, selecting a link with a lower unit transmission cost can reduce overall network costs, especially for tasks that require transmitting large amounts of data over long periods of time.

[0042] For example, the docking station detects a Wi-Fi link with a bandwidth of 50 Mbps, a latency of 30 ms, a packet loss rate of 1%, a jitter of 5 ms, and a unit transmission cost of 0.01 RMB / MB. The wired network link has a bandwidth of 100 Mbps, a latency of 1 ms, a packet loss rate of 0.1%, a jitter of 2 ms, and a unit transmission cost of 0.02 RMB / MB. The docking station uploads the collected link state parameters and task characteristics to the cloud control platform, which receives and analyzes them. Using reinforcement learning or optimization algorithms, a link scheduling policy is generated based on the task type and link state parameters. The algorithm comprehensively considers task priority, link performance, and cost control. Specifically, high-priority tasks (such as video conferencing) are prioritized for allocation to links with low latency, high bandwidth, and low jitter; links with high bandwidth, low latency, low packet loss rate, and low jitter are prioritized; and links with low unit transmission costs are prioritized, provided that task requirements are met. After generating the link scheduling policy, the cloud control platform sends it to the edge agent via a message queue or API. After receiving the strategy, the edge agent decomposes and distributes the task data according to the strategy requirements.

[0043] This implementation introduces jitter values ​​and unit transmission costs, providing more comprehensive link status parameters and enabling more accurate evaluation of link performance and cost-effectiveness.

[0044] In one possible implementation, the link scheduling strategy analysis and generation process using a cloud-based learning module is further performed. Step S200 includes step S210, where the received link state parameters are combined with task characteristics to construct a feature vector. Specifically, the cloud-based control platform receives the link state parameters and task characteristics uploaded by the docking station and integrates these parameters and characteristics to form a unified feature vector. A feature vector is a multidimensional data structure, with each dimension representing a parameter or feature.

[0045] For example, a feature vector can be represented as an array, where each element corresponds to a parameter or feature. Assuming the link state parameters and task characteristics are as follows: link bandwidth: 100 Mbps, latency: 1 ms, packet loss rate: 0.1%, jitter: 2 ms, unit transmission cost: 0.02 yuan / MB, task type: video conferencing, task level: high priority, data flow characteristics: UDP protocol, port numbers 10000-10010, then the feature vector can be represented as: [100, 1, 0.1, 2, 0.02,"Video Conferencing","High Priority","UDP","10000-10010"].

[0046] In step S220, the feature vector is input into a pre-trained scheduling model to analyze the link scheduling actions and construct the link scheduling policy, including the target link number, task slice size, whether to enable the redundancy mechanism, bandwidth allocation ratio, and delay tolerance parameters. Specifically, the scheduling model is built based on a machine learning or deep learning algorithm and trained using historical data. Its goal is to generate an optimal link scheduling policy based on the input feature vector. The model output includes the target link number, task slice size, whether to enable the redundancy mechanism, bandwidth allocation ratio, and delay tolerance parameters. The target link number specifies the link to which the task should be assigned (e.g., Wi-Fi link or wired network link); the task slice size specifies the data slice size into which the task data should be divided; whether to enable the redundancy mechanism determines whether to enable redundant transmission mechanisms (e.g., multipath transmission) for the task data; the bandwidth allocation ratio specifies the bandwidth allocation ratio for different tasks on the link; and the delay tolerance parameter specifies the maximum delay that the task can tolerate.

[0047] The feature vector is input into the scheduling model, which analyzes it based on pre-trained rules or algorithms and generates a link scheduling policy. For example, based on the task type and link state parameters, the model outputs the following scheduling policy: For a video conferencing task, the target link is the wired network link (number 1), the task slice size is 10KB, redundancy is disabled, the bandwidth allocation ratio is 80%, and the delay tolerance parameter is 10ms. For a web browsing task, the target link is the Wi-Fi link (number 2), the task slice size is 5KB, redundancy is disabled, the bandwidth allocation ratio is 20%, and the delay tolerance parameter is 100ms.

[0048] This implementation combines link state parameters and task characteristics into a feature vector and inputs it into a pre-trained scheduling model to intelligently generate a link scheduling policy. This data-driven approach not only optimizes resource allocation and improves user experience, but also reduces system complexity and enhances robustness.

[0049] In one possible implementation, the received link state parameters are combined with task characteristics to construct a feature vector. Step S210 further includes step S211, where the link state parameters are normalized to form a link state feature vector. Specifically, link state parameters (such as bandwidth, latency, packet loss rate, jitter, and unit transmission cost) have different dimensions and numerical ranges. For example, bandwidth is measured in Mbps, latency is measured in milliseconds, and packet loss rate is expressed as a percentage. To ensure that these parameters participate in calculations fairly within the same model, they need to be normalized. Normalization can unify the numerical ranges of all parameters into a standard interval (e.g., [0, 1]), thereby eliminating differences in dimensions and numerical ranges.

[0050] The cloud control platform receives the link state parameters uploaded by the dock and selects an appropriate normalization method (such as min-max normalization or Z-score normalization) for each parameter. Each parameter is normalized to form a normalized link state feature vector. For example, the normalized link state feature vector might be: [0.44, 0.5, 0.2, 0.6, 0.3] (corresponding to bandwidth, latency, packet loss rate, jitter, and unit transmission cost, respectively).

[0051] Step S212: Structured encoding is performed on the task features to form a task requirement vector. Specifically, task features (such as task type, task level, and data flow characteristics) are discrete or non-numeric. To input these features into the scheduling model, they need to be converted into numeric vector representations. Specifically, the cloud control platform receives the task features uploaded by the docking station and performs one-hot encoding on the task type. One-hot encoding is suitable for discrete categorical features. Each category is represented by an independent dimension with a value of 1, and the values ​​of the remaining dimensions are 0. For example, there are three task types: web browsing, video conferencing, and file downloading. These can be encoded as follows: web browsing: [1, 0, 0], video conferencing: [0, 1, 0], file downloading: [0, 0, 1]. Task levels are numerically encoded, for example: low priority: 0; medium priority: 0.5; high priority: 1. Continuous task features (such as the average packet size of a data flow) can be used directly or normalized. The encoded task features are combined to form a task requirement vector. For example, the task requirement vector may be: [1, 0, 0, 0.5, 0.7] (corresponding to task type, task level, and data flow characteristics, respectively).

[0052] Step S213, concatenate the link state feature vector and the task requirement vector into a unified feature vector. Specifically, the normalized link state feature vector and the structured coded task requirement vector are concatenated to form a unified feature vector. The concatenated feature vector contains all the information about the link state and task requirement, and can be directly input into the scheduling model for analysis. For example, the link state feature vector is [0.44, 0.5, 0.2, 0.6, 0.3], and the task requirement vector is [1, 0, 0, 0.5, 0.7]. The concatenated unified feature vector is [0.44, 0.5, 0.2, 0.6, 0.3, 1, 0, 0, 0.5, 0.7].

[0053] This implementation normalizes link state parameters, structures task features, and concatenates them into a unified feature vector, enabling more efficient data input into the scheduling model. This approach not only improves model input consistency and generalization, but also enhances the accuracy of scheduling strategies and simplifies data preprocessing.

[0054] In one possible implementation, step S200 further includes step S230, which determines the optimal fragmentation granularity based on the transmission response relationship between the link state parameters and the fragmentation granularity, balancing the interests according to the link bandwidth, delay, packet loss rate, and jitter value in the link state parameters. Specifically, the relationship between the link state parameters (bandwidth, delay, packet loss rate, jitter value) and the fragmentation granularity is analyzed. Smaller fragmentation granularity can reduce the impact of delay and jitter, but will increase transmission overhead (such as more fragment header information); larger fragmentation granularity can reduce overhead, but may increase the impact of delay and packet loss. For example, for links with high bandwidth, low delay, and low packet loss rate, a larger fragmentation granularity can be used; while for links with low bandwidth, high delay, and high packet loss rate, a smaller fragmentation granularity is required.

[0055] Use mathematical models or algorithms to balance the relationship between fragmentation granularity and link state parameters. For example, you can define an objective function that comprehensively considers bandwidth utilization, latency, packet loss rate, and jitter, and determine the optimal fragmentation granularity by optimizing this function. For example, the objective function can be expressed as: Objective Function = α × Bandwidth Utilization − β × Latency − γ × Packet Loss Rate − δ × Jitter, where α, β, γ, and δ are weight coefficients used to adjust the importance of different parameters.

[0056] The cloud control platform calculates the optimal fragmentation size for each link based on link state parameters (bandwidth, latency, packet loss rate, and jitter). It uses optimization algorithms (such as linear programming and genetic algorithms) to solve the objective function and determine the optimal fragmentation size. For example, for one link, the calculated optimal fragmentation size is 10KB.

[0057] Step S240 determines the transmission constraint parameters based on the task type and task level in the task characteristics. Specifically, the transmission constraint parameters are determined based on the task type and task level. These parameters include delay tolerance, bandwidth requirement, packet loss rate tolerance, etc. A mapping table from task characteristics to constraint parameters is predefined, and the corresponding constraint parameters are searched from the mapping table based on the task type and task level. For example, the mapping table is as follows: Video conferencing (high priority): delay tolerance value 10ms, bandwidth requirement 50Mbps, packet loss rate tolerance value 0.1%; web browsing (medium priority): delay tolerance value 50ms, bandwidth requirement 10Mbps, packet loss rate tolerance value 0.5%; file downloading (low priority): delay tolerance value 100ms, bandwidth requirement 5Mbps, packet loss rate tolerance value 1%. The cloud control platform searches the mapping table based on the task characteristics (task type and task level) to determine the transmission constraint parameters.

[0058] Step S250, using the transmission constraint parameters to adjust and optimize the optimal sharding granularity to obtain a sharding granularity constraint. Specifically, the optimal sharding granularity is adjusted and optimized according to the transmission constraint parameters (such as delay tolerance, bandwidth requirement, and packet loss rate tolerance). For example, if the delay tolerance of the task is low, the sharding granularity needs to be reduced to reduce the delay; if the bandwidth requirement of the task is high, the sharding granularity can be appropriately increased to improve the transmission efficiency. By adjusting the optimized sharding granularity, a sharding granularity constraint is generated. The sharding granularity constraint is a range value, which represents the minimum and maximum values ​​of the sharding granularity. For example, for a video conferencing task, the adjusted sharding granularity constraint may be: a minimum sharding granularity of 5KB and a maximum sharding granularity of 15KB.

[0059] In step S260, the slice granularity constraint is added as a constraint to the scheduling model to participate in the generation of link scheduling actions. Specifically, the slice granularity constraint is used as one of the input constraints of the scheduling model. The scheduling model needs to consider the slice granularity constraint when generating the link scheduling strategy. For example, when generating the task slice size, the scheduling model must ensure that the slice size is within the slice granularity constraint range (such as the minimum slice granularity of 5KB and the maximum slice granularity of 15KB). The scheduling model generates the final link scheduling strategy based on the link state parameters, task characteristics, and slice granularity constraints.

[0060] This implementation method determines the optimal sharding granularity by balancing interests based on the transmission response relationship between link state parameters and sharding granularity, and adjusts the sharding granularity according to task characteristics. It can optimize the sharding granularity, meet task requirements, improve the adaptability of the scheduling strategy, and thus enhance the user experience.

[0061] In one possible implementation, the link scheduling policy supports multi-link heterogeneous aggregate transmission. Step S200 further includes step S270, which sets differentiated rate allocation ratios based on the transmission credits of different links. Transmission credits are obtained by evaluating the actual performance of the links based on historical records. Specifically, transmission credits are indicators obtained based on the actual performance of the links, reflecting the stability and reliability of the links. They include parameters such as bandwidth utilization, latency, packet loss rate, and jitter. For example, if a link has an average latency of 10ms and a packet loss rate of 0.1% over a period of time, the transmission credit of the link is high. Based on the transmission credits of the links, different rate allocation ratios are set for each link. Links with higher credits are allocated higher rates, while links with lower credits are allocated lower rates. For example, if the transmission credit of a wired network link is 90 (out of 100) and the transmission credit of a Wi-Fi link is 70, the rate allocation ratio can be set to 60% for the wired network link and 40% for the Wi-Fi link. The rate allocation ratios are incorporated into the link scheduling policy.

[0062] Step S280, based on the current rate distribution ratio, determines the task data load sharing ratio corresponding to each link, which is used to control the distribution ratio of task data among multiple links. Specifically, according to the rate distribution ratio, the task data load sharing ratio of each link is determined. The load sharing ratio determines the proportion of the task data volume that each link needs to bear. For example, if the rate distribution ratio is 60% for the wired network link and 40% for the Wi-Fi link, the task data load sharing ratio is also 60% and 40%. The load sharing ratio can be calculated by proportion. For example, the total task data volume is 100MB, the wired network link bears 60MB, and the Wi-Fi link bears 40MB. Add the load sharing ratio to the link scheduling strategy, and send the link scheduling strategy to the edge agent.

[0063] In step S290, when the primary link experiences an anomaly, the task distribution strategy is adjusted based on the load sharing ratio, automatically switching to the preset backup link and redistributing the rate ratio to ensure uninterrupted task transmission. The multi-link heterogeneous aggregate transmission supports dynamic link online and offline. When a new link is added or an existing link is disconnected, the rate distribution ratio and load sharing ratio are automatically updated without interrupting the current task transmission process. Specifically, the edge agent monitors link status in real time. When an anomaly in the primary link is detected (such as a sudden increase in packet loss rate, excessive latency, or a link disconnection), the task distribution strategy is adjusted. Based on the load sharing ratio, task data originally assigned to the primary link is automatically switched to the preset backup link. The rate sharing ratio is recalculated to ensure that the distribution ratio of task data across multiple links is consistent with the current link status. For example, if the primary link is a wired network link and the backup link is a Wi-Fi link, when the wired network link experiences an anomaly, the task data is switched to the Wi-Fi link and the rate ratio is redistributed. When a new link is added or an existing link is disconnected, the rate distribution ratio and load sharing ratio are automatically updated without interrupting the current task transmission process. For example, if a new Wi-Fi link is added, the system recalculates the transmission credits and rate allocation ratios for all links, dynamically adjusting the distribution of task data. The updated link scheduling policy is sent to the control execution hardware to continue the transmission of task data.

[0064] This implementation method improves transmission reliability and stability, optimizes resource utilization, enhances user experience, and strengthens system robustness by supporting multi-link heterogeneous aggregate transmission, setting differentiated rate allocation ratios, determining task data load sharing ratios, and automatically switching to backup links when the main link is abnormal.

[0065] In one possible implementation, the link scheduling strategy is generated and sent to the edge intelligent agent. After that, the method further includes: establishing a mapping relationship between the link scheduling strategy and the link status parameters and task characteristics, and constructing a strategy list; setting a policy cache space on the expansion dock side, storing the strategy list in the strategy cache space, and when the cloud control platform is disconnected or the response exceeds a threshold, performing link scheduling aggregation based on the pre-stored strategies in the strategy cache space.

[0066] Specifically, after each link scheduling policy is generated, the cloud control platform associates the policy with its corresponding link state parameters (such as bandwidth, latency, packet loss rate, jitter, and unit transmission cost) and task characteristics (such as task type, task level, and data flow characteristics) to form a policy mapping entry. For example, if the link state parameters are "100Mbps bandwidth, 1ms latency, 0.1% packet loss rate, 2ms jitter, and a cost of 0.02 yuan / MB" and the task characteristics are "video conferencing, high priority, UDP protocol," the corresponding policy is "target link number 1, 10KB fragmentation, redundancy mechanism disabled, bandwidth allocation ratio 80%, and latency tolerance parameter 10ms." All policy mapping entries are sorted by timestamp and priority, forming a dynamically updated policy list.

[0067] The dock's local storage allocates a non-volatile cache area (such as Flash or EEPROM) for storing policy lists. The policy list is written to the cache via incremental updates. Each time a new policy is delivered from the cloud, the dock verifies its integrity (e.g., through a CRC check) and overwrites or appends it to the cache. The cache uses a circular buffer design. When capacity is insufficient, the oldest or lowest-priority policy entries are automatically eliminated, ensuring that frequently used policies remain cached.

[0068] The dock monitors the connection status with the cloud in real time (such as heartbeat packet timeouts or SSL handshake failures) and sets a response threshold (such as 500ms). If a disconnection or response timeout is detected, the edge agent immediately switches to local decision-making mode. Specifically, it extracts current link state parameters and task characteristics and uses a fuzzy matching algorithm (such as cosine similarity or Euclidean distance) to search for the closest historical policy in the policy list. For example, if the current link latency is 1.2ms (close to 1ms) and the task characteristic is "video conferencing," the historical policy "target link number 1, shard size 10KB" is matched. If the parameters of the matching policy deviate from the current state (such as the packet loss rate increases from 0.1% to 0.5%), the edge agent fine-tunes the policy according to pre-set rules (such as reducing the shard size to 8KB to reduce retransmission overhead). Data sharding, link selection, and load balancing are performed according to the adjusted policy, while continuously monitoring link status. If the cloud connection is restored, the agent seamlessly switches back to cloud-optimized mode and feeds the locally adjusted parameters back to the cloud to update the model.

[0069] This implementation method ensures efficient, low-latency link scheduling during network fluctuations or cloud failures through local policy caching and intelligent matching mechanisms, significantly improving the system's robustness and user experience continuity.

[0070] In step S300, the edge agent completes the decomposition processing of the task data according to the received link scheduling strategy, generates task data packets and distributes them to the control execution hardware.

[0071] Specifically, a task data packet is a unit of task data that has been decomposed and processed by an edge agent. It contains a portion of the task data as well as information related to link selection, fragmentation, and scheduling strategies. Control execution hardware is the hardware device used to execute the link selection, fragmentation, and scheduling strategies in the task data packet, such as network interface cards, routers, and switches.

[0072] Specifically, the edge agent decomposes task data based on the fragmentation requirements of the link scheduling policy. For example, for a large file transfer task, the policy requires the file to be fragmented into multiple data fragments of equal or unequal size. If the policy requires dynamic fragmentation, the edge agent dynamically adjusts the fragment size based on the link bandwidth. For example, if the link bandwidth is high, the data fragments can be larger; if the bandwidth is low, the fragments can be smaller. The edge agent schedules and prioritizes the decomposed task data based on the task priority and scheduling order specified in the link scheduling policy. For example, video conferencing task data with high real-time requirements is given higher priority and allocated to links with better performance, while non-real-time file download task data is allocated to links with lower bandwidth. The edge agent encapsulates the decomposed task data according to the requirements of different link protocols to generate task data packets. For example, data transmitted over a Wi-Fi link is encapsulated according to the standard format of the Wi-Fi protocol, while data transmitted over an Ethernet link is encapsulated according to the Ethernet protocol. The edge agent sends the task data packets to the control execution hardware through the hardware interface driver. The driver is responsible for communicating with the hardware interface and controlling the sending and receiving of data. For example, for an Ethernet interface, the driver will encapsulate the task data packet into an Ethernet frame and send it through the physical link.

[0073] In one possible implementation, the edge agent completes the decomposition processing of the task data according to the received link scheduling policy, generates a task data packet and distributes it to the control execution hardware. Step S300 further includes step S310, reading the link scheduling policy, obtaining the sharding parameters, the target link list and the scheduling policy field. Specifically, the edge agent receives the link scheduling policy issued by the cloud control platform. The link scheduling policy is a data structure containing multiple fields, represented in JSON format. The edge agent parses this data structure and extracts key information. Among them, the sharding parameters include information such as the task shard size and the number of shards. For example, the shard size is 10KB and the total number of shards is 100. The target link list includes the link number to which each shard should be assigned. For example, the first 50 shards are assigned to the wired network link, and the last 50 shards are assigned to the Wi-Fi link. The scheduling policy field includes information such as the task number, priority tag, and whether the redundancy mechanism is activated. For example, the task number is 12345, the priority is high, and the redundancy mechanism is not activated.

[0074] Step S320, decompose the original task data stream into multiple logical data segments according to the sharding parameters. Specifically, according to the sharding parameters (such as the sharding size), decompose the original task data stream into multiple logical data segments. For example, if the sharding size is 10KB and the original task data stream size is 1MB (1024KB), it needs to be decomposed into 103 logical data segments (each segment is 10KB, and the last segment is 4KB). The generation of logical data segments can be completed through slicing operations to ensure that the size of each segment meets the requirements of the sharding parameters. Each logical data segment is an independent data unit that contains a part of the task data. A unique sharding number is assigned to each logical data segment for subsequent reorganization and management.

[0075] Step S330, encapsulates each logical data segment into a task data packet, which includes a task number, a fragment number, a link selection number, a priority tag, and an optional error correction control flag. Specifically, the edge agent creates a task data packet for each logical data segment, and fills in the various fields of the task data packet, including the task number (a number that uniquely identifies the task, such as 12345), the fragment number (identifies the fragment number of the data packet in the task, such as 1, 2, 3...), the link selection number (specifies which link the data packet should be transmitted through, such as the wired network link number is 1, the Wi-Fi link number is 2), the priority tag (identifies the priority of the data packet, such as high, medium, low), and the optional error correction control flag (identifies whether the error correction control mechanism is enabled, such as enabled or not). The content of the logical data segment is encapsulated as the payload of the task data packet.

[0076] Step S340 sends the generated task data packet to the interface module of the control execution hardware for link distribution and data transmission. Specifically, the edge agent sends the generated task data packet to the interface module of the control execution hardware. The interface module receives the task data packet and assigns it to the corresponding link based on the link selection number. The control execution hardware sends the task data packet via the designated link, completing the data transmission.

[0077] This implementation accurately decomposes, processes, and distributes task data by reading the link scheduling policy, decomposing the task data stream, encapsulating the task data packets, and sending them to the control execution hardware. This processing method not only improves the accuracy and reliability of data transmission, but also optimizes link selection and scheduling, enhancing overall system performance and user experience.

[0078] In step S400, the execution hardware aggregates according to the link selection, fragmentation, and scheduling strategies in the task data packet, and records the task completion quality, link performance, and user experience indicators in real time through the expansion dock, and transmits them back to the cloud control platform for iterative optimization of the learning module.

[0079] Specifically, the execution hardware uses a multi-link aggregation protocol (such as IEEE 802.3ad or a custom protocol) to aggregate task data slices transmitted across different links. Multi-link aggregation is a protocol that combines multiple network links to form a single logical high-speed link, improving data transmission efficiency and reliability. The protocol specifies rules for sorting, checking, and reassembling data slices. For example, by adding sequence numbers and checksums to data slices, the execution hardware can reassemble the data slices according to the sequence number order and verify data integrity using the checksums.

[0080] The execution hardware utilizes multi-core processors or specialized acceleration chips (such as FPGAs or ASICs) to parallelize multi-link aggregation operations, improving aggregation efficiency. For example, multiple data slices can be sorted and reassembled simultaneously on different processor cores, reducing aggregation latency.

[0081] The dock has a built-in real-time monitoring module that, through a combination of software and hardware, records task completion quality (metrics that measure task execution effectiveness, such as task completion time, data transmission success rate, task execution accuracy and completeness, etc.), link performance (reflecting the performance of the network link during task execution, such as link utilization, latency changes, packet loss rate changes, etc.), and user experience indicators (metrics that measure task execution effectiveness from the user's perspective, such as video playback freeze rate, web page loading speed, file download speed, etc.). For example, by setting monitoring points along the data transmission path, the module collects data packet transmission timestamps and packet loss in real time, and calculates task completion time and data transmission success rate.

[0082] The docking station transmits the collected metric data back to the cloud control platform via SSL / TLS encryption and stores it in a cloud database (such as the Hadoop Distributed File System or Cassandra). The cloud control platform uses this data to iteratively optimize the learning module and further improve the performance of the scheduling strategy.

[0083] The embodiment of the present application adopts a method in which the expansion dock collects the status parameters of all available network links in real time, performs application-level task identification on the input data stream to extract task features, uploads the link status and task features to the cloud control platform, uses the cloud learning module to analyze and generate the optimal link scheduling strategy, and sends it to the edge intelligent agent. The edge intelligent agent decomposes and processes the task data into data packets according to the strategy, and the execution hardware aggregates and transmits the data according to the strategy. The expansion dock records the task completion quality, link performance and user experience indicators in real time, and feeds back to the cloud platform for continuous optimization of scheduling strategies and other technical means, which solves the technical problems of insufficient link resource utilization, low data transmission efficiency and poor user experience in the existing expansion dock multi-link aggregation optimization, and achieves the technical effect of fully utilizing link resources, improving data transmission efficiency and user experience.

[0084] In the above, refer to Figure 1 A method for optimizing multi-link aggregation of a docking station based on cloud collaboration according to an embodiment of the present invention is described in detail. Figure 2 A cloud-coordinated docking station multi-link aggregation optimization system according to an embodiment of the present invention is described.

[0085] According to an embodiment of the present invention, a cloud-coordinated docking station multi-link aggregation optimization system is designed to address the technical issues of insufficient link resource utilization, low data transmission efficiency, and poor user experience in existing docking station multi-link aggregation optimization, thereby achieving the technical effect of fully utilizing link resources, improving data transmission efficiency, and user experience. The cloud-coordinated docking station multi-link aggregation optimization system includes: an application-level task identification module 10, a link scheduling strategy analysis module 20, a decomposition processing module 30, and an aggregation optimization module 40.

[0086] The application-level task identification module 10 is used to collect the status parameters of all available network links in real time through the expansion dock, perform application-level task identification on the data stream entering the expansion dock, and obtain task characteristics; the link scheduling strategy analysis module 20 is used to upload the link status parameters and task characteristics to the cloud control platform, use the learning module deployed on the cloud to perform link scheduling strategy analysis, generate a link scheduling strategy, and send it to the edge intelligent agent; the decomposition processing module 30 is used for the edge intelligent agent to complete the decomposition processing of the task data according to the received link scheduling strategy, generate a task data packet and distribute it to the control execution hardware; the aggregation optimization module 40 is used to execute the hardware to aggregate according to the link selection, segmentation, and scheduling strategy in the task data packet, and record the task completion quality, link performance and user experience indicators in real time through the expansion dock, and transmit them back to the cloud control platform for iterative optimization of the learning module.

[0087] Among them, the link scheduling strategy is generated and sent to the edge intelligent agent. After that, the system can further include: a strategy list construction module for establishing a mapping relationship between the link scheduling strategy and the link state parameters and task characteristics, and constructing a strategy list; a pre-stored strategy scheduling module is used to set a policy cache space on the expansion dock side, and store the strategy list in the strategy cache space. When the cloud control platform is disconnected or the response exceeds the threshold, link scheduling aggregation is performed based on the pre-stored strategies in the strategy cache space.

[0088] The specific configuration of the application-level task identification module 10 will be described in detail below. As described above, application-level task identification is performed on the data stream entering the docking station to obtain task characteristics. The application-level task identification module 10 may further include: a task type identification unit for deploying a traffic identification model at the edge to identify the task type of the data stream entering the docking station; and a task level classification unit for classifying tasks based on the identified task type, using the data stream characteristics, task type, and task level as the task characteristics.

[0089] The following describes in detail the specific configuration of the link scheduling strategy analysis module 20. As described above, the link scheduling strategy analysis module 20 may further include: the link status parameters include: link bandwidth, delay, packet loss rate, jitter value, unit transmission cost.

[0090] Among them, the link scheduling strategy analysis is performed using the learning module deployed in the cloud to generate a link scheduling strategy. The link scheduling strategy analysis module 20 may further include: a feature vector construction unit for combining the received link state parameters with the task features to construct a feature vector; a link scheduling action analysis unit for inputting the feature vector into a pre-trained scheduling model to perform link scheduling action analysis and construct the link scheduling strategy, including the target link number, task segment size, whether to start the redundancy mechanism, bandwidth allocation ratio and delay tolerance parameters.

[0091] The specific configuration of the decomposition processing module 30 will be described in detail below. As described above, the edge agent completes the decomposition processing of the task data according to the received link scheduling strategy, generates a task data packet and distributes it to the control execution hardware. The decomposition processing module 30 may further include: a link scheduling strategy reading unit for reading the link scheduling strategy, obtaining the fragmentation parameters, the target link list and the scheduling strategy field; a fragmentation unit for decomposing the original task data stream into multiple logical data segments according to the fragmentation parameters; a task data packet encapsulation unit for encapsulating each logical data segment into a task data packet, wherein the task data packet includes a task number, a fragmentation number, a link selection number, a priority tag and an optional error correction control flag; and a task data packet sending unit for sending the generated task data packet to the interface module of the control execution hardware for link distribution and data transmission.

[0092] Among them, the received link state parameters are combined with the task characteristics to construct a feature vector, and the feature vector construction unit may further include: a normalization processing subunit for normalizing the link state parameters to form a link state feature vector; a structured coding subunit for structured coding the task characteristics to form a task requirement vector; and a splicing subunit for splicing the link state feature vector and the task requirement vector into a unified feature vector.

[0093] Among them, the link scheduling strategy analysis module 20 can further include: a benefit balancing unit for balancing benefits based on the transmission response relationship between link state parameters and fragmentation granularity, according to the link bandwidth, delay, packet loss rate, and jitter value in the link state parameters, to determine the optimal fragmentation granularity; a transmission constraint parameter determination unit for determining the transmission constraint parameters according to the task type and task level in the task characteristics; a fragmentation granularity adjustment and optimization unit for adjusting and optimizing the optimal fragmentation granularity using the transmission constraint parameters to obtain fragmentation granularity constraints; a constraint condition adding unit for adding the fragmentation granularity constraint as a constraint condition to the scheduling model to participate in the generation of link scheduling actions.

[0094] Among them, the link scheduling strategy supports multi-link heterogeneous aggregation transmission, and the link scheduling strategy analysis module 20 can further include: a differentiated rate allocation ratio setting unit for setting differentiated rate allocation ratios according to different link transmission credits, wherein the transmission credit is obtained by evaluating the actual performance of the link based on historical records; a task data load sharing ratio determination unit for determining the task data load sharing ratio corresponding to each link based on the current rate allocation ratio, and for controlling the distribution ratio of task data among multiple links; a rate ratio reallocation unit for adjusting the task distribution strategy according to the load sharing ratio when the main link is abnormal, automatically switching to the preset backup link and reallocating the rate ratio to ensure that the task is not interrupted in transmission; wherein, the multi-link heterogeneous aggregation transmission supports dynamic link online and offline, and when a new link is added or an existing link is disconnected, the rate allocation ratio and load sharing ratio are automatically updated without interrupting the current task transmission process.

[0095] A cloud-collaborative expansion dock multi-link aggregation optimization system provided by an embodiment of the present invention can execute a cloud-collaborative expansion dock multi-link aggregation optimization method provided by any embodiment of the present invention, and has functional modules and beneficial effects corresponding to the execution method.

[0096] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, any number of different modules may be used and run on the user terminal and / or server, and the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other and are not used to limit the scope of protection of the present invention.

[0097] The above specific embodiments do not constitute a limitation to the scope of protection of this application. It should be understood by those skilled in the art that various modifications, combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of this application should be included in the scope of protection of this application. In some cases, the actions or steps recorded in this application can be performed in an order different from that in the embodiments and can still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A cloud-coordinated docking station multi-link aggregation optimization method, characterized in that: include: The docking station collects the status parameters of all available network links in real time, performs application-level task identification on the data stream entering the docking station, and obtains task features; Upload link state parameters and task characteristics to the cloud control platform, use the cloud-deployed learning module to analyze the link scheduling strategy, generate the link scheduling strategy, and send it to the edge agent; The edge agent completes the decomposition and processing of the task data according to the received link scheduling strategy, generates task data packets and distributes them to the control execution hardware; The execution hardware aggregates according to the link selection, fragmentation, and scheduling strategies in the task data packet, and records the task completion quality, link performance, and user experience indicators in real time through the expansion dock, and transmits them back to the cloud control platform for iterative optimization of the learning module.

2. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 1, characterized in that: The link scheduling strategy is generated and sent to the edge agent, and then includes: Establishing a mapping relationship between the link scheduling strategy and link state parameters and task characteristics, and constructing a strategy list; A policy cache space is set on the expansion dock side, and the policy list is stored in the policy cache space. When the cloud control platform is disconnected or the response exceeds a threshold, link scheduling aggregation is performed based on the pre-stored policies in the policy cache space.

3. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 1, characterized in that: Perform application-level task identification on the data stream entering the docking station to obtain task features, including: Deploy a traffic identification model at the edge to identify the task type of the data flow entering the docking station; The task levels are divided according to the identified task types, and the data flow characteristics, task types and task levels are used as the task characteristics.

4. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 3, characterized in that: The link status parameters include: link bandwidth, delay, packet loss rate, jitter value, and unit transmission cost.

5. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 4, characterized in that: The link scheduling strategy analysis and generation of the link scheduling strategy using the learning module deployed in the cloud include: Combine the received link state parameters with the task characteristics to construct a feature vector; The feature vector is input into a pre-trained scheduling model to perform link scheduling action analysis and construct the link scheduling strategy, including the target link number, task slice size, whether to start the redundancy mechanism, bandwidth allocation ratio and delay tolerance parameters.

6. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 5, characterized in that: The edge agent completes the decomposition and processing of the task data according to the received link scheduling strategy, generates task data packets and distributes them to the control execution hardware, including: Read the link scheduling policy to obtain fragmentation parameters, target link list, and scheduling policy fields; Decomposing the original task data stream into a plurality of logical data segments according to the slicing parameters; Encapsulating each logical data segment into a task data packet, wherein the task data packet includes a task number, a slice number, a link selection number, a priority tag, and an optional error correction control flag; The generated task data packets are sent to the interface module that controls the execution hardware for link distribution and data transmission.

7. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 5, characterized in that: Combine the received link state parameters with the task characteristics to construct a feature vector, including: Normalizing the link state parameters to form a link state feature vector; Structurally encoding the task features to form a task requirement vector; The link state feature vector and the task requirement vector are concatenated into a unified feature vector.

8. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 5, characterized in that: Also includes: Based on the transmission response relationship between link state parameters and fragmentation granularity, the optimal fragmentation granularity is determined by balancing the interests of link bandwidth, delay, packet loss rate, and jitter value in the link state parameters; Determining transmission constraint parameters according to the task type and task level in the task characteristics; Using the transmission constraint parameters to adjust and optimize the optimal sharding granularity to obtain a sharding granularity constraint; The shard granularity constraint is added as a constraint condition to the scheduling model to participate in the generation of link scheduling actions.

9. The cloud-coordinated docking station multi-link aggregation optimization method according to claim 1, characterized in that: The link scheduling strategy supports multi-link heterogeneous aggregation transmission, including: Differentiated rate allocation ratios are set based on the transmission credits of different links, where the transmission credits are obtained by evaluating the actual performance of the links based on historical records; Based on the current rate allocation ratio, the task data load sharing ratio corresponding to each link is determined to control the distribution ratio of task data among multiple links; When the main link is abnormal, the task distribution strategy is adjusted according to the load sharing ratio, automatically switching to the preset backup link and redistributing the rate ratio to ensure that the task is not interrupted. Among them, the multi-link heterogeneous aggregation transmission supports dynamic link online and offline. When a new link is added or an existing link is disconnected, the rate allocation ratio and load sharing ratio are automatically updated without interrupting the current task transmission process.

10. A cloud-coordinated docking station multi-link aggregation optimization system, characterized in that: The system is used to implement the cloud-coordinated docking station multi-link aggregation optimization method according to any one of claims 1 to 9, and the system includes: The application-level task identification module is used to collect the status parameters of all available network links in real time through the docking station, perform application-level task identification on the data stream entering the docking station, and obtain task characteristics; The link scheduling strategy analysis module is used to upload link state parameters and task characteristics to the cloud control platform, use the learning module deployed in the cloud to analyze the link scheduling strategy, generate the link scheduling strategy, and send it to the edge agent; A decomposition processing module is used for the edge agent to complete the decomposition processing of task data according to the received link scheduling strategy, generate task data packets and distribute them to the control execution hardware; The aggregation optimization module is used to execute hardware aggregation according to the link selection, fragmentation, and scheduling strategies in the task data packet, and record the task completion quality, link performance and user experience indicators in real time through the expansion dock, and transmit them back to the cloud control platform for iterative optimization of the learning module.

Images