Dynamic control method and system for spaceflight uplink data traffic

By introducing a combined structure of scheduler, multiple leaky buckets and one token bucket in the aerospace data transmission system, dynamically adjusting the bandwidth and output rates of each service, solving the multiple requirements for upstream data flow control in the space station, and achieving efficient and real-time data transmission.

CN119420703APending Publication Date: 2025-02-11BEIJING AEROSPACE CONTROL CENT
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310144529.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-02-07
Publication Date
2025-02-11

AI Technical Summary

Technical Problem

The prior art cannot meet the requirements of upstream data traffic control in space stations at the same time, including the problems of multiple service requests, different service priority, uneven bandwidth allocation and high data real-time requirements.

Method used

A dynamic control system for aerospace upstream data traffic is adopted, which includes a scheduler, multiple leaky buckets, a token bucket and a service queue cache. The scheduler adjusts the size of the leaked bucket and the token generation rate of the token bucket according to the task planning requirements and actual transmission conditions to control the bandwidth resources and output rates of each service.

Benefits of technology

Dynamic traffic control for multi-service requests is realized, real-time data transmission is improved, blocking and delay are reduced, and bandwidth is allocated reasonably.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119420703A_ABST
    Figure CN119420703A_ABST
Patent Text Reader

Abstract

The invention provides an aerospace uplink data flow dynamic control method and system, the system comprises a scheduler, a plurality of leaky buckets, a token bucket and a service queue cache, each leaky bucket is used for accessing a service request and sending uplink service data to the service queue cache, the token bucket is used for controlling the output rate of uplink service data in the service queue cache, and the scheduler is used for setting the initial size of the leaky bucket and the initial token generation rate of the token bucket according to task planning requirements; and the control module is used for adjusting the size of the leaky bucket according to the actual situation of task transmission to control the bandwidth resource occupied by each service when entering the service queue cache, and adjusting the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data. According to the invention, multiple service requests can be supported at the same time, flow control can be carried out according to the real-time transmission condition of the service data, the real-time performance of data transmission can be improved, and blocking and time delay are reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of aerospace data transmission, and in particular to a method and system for dynamically controlling aerospace uplink data flow. Background Art

[0002] With the construction and operation of the space station, the interactive services between the space station and the ground are becoming more and more abundant, including three categories and dozens of subcategories such as remote control data, IP data, image and voice data, etc., which is accompanied by an increase in the type of uplink data and an increase in the rate. However, the transmission rate, importance, producer and other characteristics of the uplink data are different, which conflicts with the relatively fixed uplink total bandwidth of the space-ground link. The data uplink of the space station must ensure the real-time reliability of important data and make full use of the space-ground channel for business development.

[0003] Currently, commonly used flow control algorithms include token bucket and leaky bucket, among which:

[0004] The token bucket algorithm is the most commonly used algorithm in network traffic shaping and rate limiting. It is used to control the amount of data sent to the network and allow burst data to be sent. A token bucket with a fixed size can generate tokens at a constant rate. If the token is not consumed, or the rate of consumption is lower than the rate of generation, the token will continue to increase until the bucket is full, and the tokens generated later will overflow from the bucket.

[0005] The main purpose of the leaky bucket algorithm is to control the rate at which data is injected into the network and smooth out burst traffic on the network. The leaky bucket algorithm provides a mechanism through which burst traffic can be shaped to provide a stable flow for the network. The process of the leaky bucket algorithm is that the request first enters the leaky bucket, and the leaky bucket drains water at a certain speed. When the water request is too large, it will overflow directly.

[0006] The token bucket adds tokens at a fixed rate. Whether a request is processed depends on whether there are enough tokens in the bucket. When the number of tokens is reduced to zero, new requests are rejected. The leaky bucket outflows requests at a constant fixed rate, and the incoming request rate is arbitrary. When the number of incoming requests accumulates to the leaky bucket capacity, new incoming requests are rejected. The token bucket allows a certain degree of burst, while the main purpose of the leaky bucket is to smooth the inflow rate.

[0007] However, neither the token bucket algorithm nor the leaky bucket algorithm can simultaneously meet the following requirements for uplink data flow control of the space station: uplink data is carried out by business, not a single data request; the data of different businesses have different priorities, and high-priority requests must be processed first within the limited bandwidth; different businesses have different allocated bandwidths, and when multiple businesses share resources, the allocated bandwidth must be set in advance to enable rationality judgment when data flow with the same priority level exceeds the limit; the priority and preset bandwidth are adjusted according to the mission planning; the real-time requirements for uplink data are high, and time delays caused by queuing must be avoided as much as possible. Summary of the invention

[0008] In view of this, the present invention provides a method and system for dynamically controlling aerospace uplink data traffic to solve at least one of the above-mentioned problems.

[0009] In order to achieve the above object, the present invention adopts the following scheme:

[0010] According to a first aspect of the present invention, there is provided a dynamic control system for uplink data traffic in aerospace, the system comprising: a scheduler, a plurality of leaky buckets, a token bucket and a service queue cache, each of the leaky buckets being used to access a service request and send uplink service data to the service queue cache, the token bucket being used to control the output rate of uplink service data in the service queue cache, the scheduler being used to set the initial size of the leaky bucket and the initial token generation rate of the token bucket according to task planning requirements, and being used to adjust the leaky bucket size according to actual task transmission conditions to control the bandwidth resources occupied by each service when entering the service queue cache, and to adjust the token generation rate of the token bucket to control the output rate of each service, thereby ensuring normal transmission of service data.

[0011] Preferably, in this embodiment, the above-mentioned scheduler adjusts the leaky bucket size according to the actual situation of task transmission to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data, including: the scheduler receives the real-time measurement results of the input rate of each service, and obtains the services that need to be scheduled due to queue data congestion based on the real-time measurement results, and then adjusts the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

[0012] Preferably, in this embodiment, the scheduler obtains the service that needs to be scheduled due to queue data blocking according to the real-time measurement result, including: the scheduler determines the service that needs to be scheduled due to queue data blocking according to the real-time measurement result by the following formula:

[0013]

[0014]

[0015] In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i (k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

[0016] Preferably, in this embodiment, if the input rate ratio of multiple services is higher than the preset value, that is, If it is greater than a preset value, all services higher than the preset value will be regarded as services that need to be scheduled, and the real-time transmission of high-priority services will be guaranteed according to the priority.

[0017] Preferably, in this embodiment, the scheduler adjusts the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data, including: the scheduler increases the generation rate of service tokens that need to be scheduled in the token bucket, reduces the token generation rate of other idle services, and simultaneously reduces the leaky bucket size of the service that needs to be scheduled to control the service data entering the service queue cache, thereby preventing data loss due to the full service queue cache.

[0018] Preferably, in this embodiment, when the service to be scheduled is no longer blocked after scheduling, the scheduler gradually reduces the corresponding token generation rate until it returns to the initial token generation rate, and gradually increases the corresponding leaky bucket size until it returns to the initial size.

[0019] According to a second aspect of the present invention, a method for dynamically controlling aerospace uplink data traffic is provided, the method comprising: setting the initial sizes of multiple leaky buckets and the initial token generation rate of a token bucket according to mission planning requirements, each of the leaky buckets corresponding to a service request access; adjusting the leaky bucket size according to actual task transmission conditions to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusting the token generation rate of the token bucket to adjust the output rate of each service, thereby ensuring normal transmission of service data.

[0020] Preferably, in this embodiment, the leaky bucket size is adjusted according to the actual situation of task transmission to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to adjust the output rate of each service, thereby ensuring the normal transmission of service data, including: receiving real-time measurement results of the input rate of each service, and obtaining the services that need to be scheduled due to queue data congestion based on the real-time measurement results, and then adjusting the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusting the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

[0021] Preferably, in this embodiment, obtaining the service that needs to be scheduled due to queue data blocking according to the real-time measurement result includes: determining the service that needs to be scheduled due to queue data blocking according to the real-time measurement result by the following formula:

[0022]

[0023]

[0024] In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i (k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

[0025] Preferably, in this embodiment, if the input rate ratio of multiple services is higher than the preset value, that is, If it is greater than a preset value, all services higher than the preset value will be regarded as services that need to be scheduled, and the real-time transmission of high-priority services will be guaranteed according to the priority.

[0026] Preferably, in this embodiment, the leaky bucket size is adjusted to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to control the output rate of each service, thereby ensuring the normal transmission of service data, including: increasing the generation rate of service tokens that need to be scheduled in the token bucket, reducing the token generation rate of other idle services, and at the same time reducing the leaky bucket size of the service that needs to be scheduled to control the service data entering the service queue cache, thereby preventing data loss due to the full service queue cache.

[0027] Preferably, in this embodiment, when the service to be scheduled is no longer blocked after scheduling, the generation rate of the corresponding token is gradually reduced until it is restored to the initial token generation rate, and the corresponding leaky bucket size is gradually increased until it is restored to the initial size.

[0028] According to a third aspect of the present invention, there is provided an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0029] According to a fourth aspect of the present invention, there is provided a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0030] According to a fifth aspect of the present invention, there is provided a computer program product, comprising a computer program / instructions, which implement the steps of the above method when executed by a processor.

[0031] It can be seen from the above technical solutions that the aerospace uplink data flow dynamic control method and system provided in this application can support multiple service requests at the same time, and can perform flow control based on the real-time transmission of service data, which can improve the real-time performance of data transmission and reduce congestion and delay. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0033] Figure 1 It is a structural schematic diagram of a dynamic control system for aerospace uplink data flow provided by an embodiment of the present application;

[0034] Figure 2 It is a flow chart of a method for dynamically controlling aerospace uplink data flow provided by an embodiment of the present application;

[0035] Figure 3 It is a schematic block diagram of the system structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] To make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0037] like Figure 1The figure shows a dynamic control system for aerospace uplink data traffic provided by an embodiment of the present application, the system comprising a scheduler 100, multiple leaky buckets 200, a token bucket 300 and a service queue cache 400. The system adopts a two-level scheduling structure of "multiple leaky buckets + token buckets", multiple leaky buckets are used to access multiple service requests, the token buckets are used to output the results, and the selection of services is scheduled by the scheduler.

[0038] Depend on Figure 1 It can be seen that each leaky bucket 200 is used to access a service request, for example, in the figure, leaky buckets A, B, and C are respectively connected to services A, B, and C, and the output end of the leaky bucket is connected to the service queue buffer 400, which is used to send the uplink service data to the service queue buffer 400. In this embodiment, multiple services share a token bucket 300, and the token bucket 300 controls the output rate of the uplink service data by controlling the rate of generating tokens corresponding to each service. The uplink service data in the service queue buffer 400 needs to obtain the token in the token bucket before it can be sent out.

[0039] The scheduler 100 is used to set the initial size of multiple leaky buckets 200 and the initial token generation rate of the token bucket 300 according to the task planning requirements, and to adjust the size of the leaky bucket 200 according to the actual task transmission situation to control the bandwidth resources occupied by each service when entering the service queue cache 400, and adjust the token generation rate of the token bucket 300 to control the output rate of each service, thereby ensuring the normal transmission of service data. It should be pointed out that the initial size of the leaky bucket 200 and the initial token generation rate of the token bucket 300 can be changed, and the scheduler 100 can change its settings according to different task planning requirements.

[0040] In this embodiment, the scheduler 100 can set the initial size of the leaky bucket 200 according to the required bandwidth of each service. For example, the bandwidth consumed by remote control instructions is relatively less than that of image data or network data transmission services. Therefore, when setting the initial size of the leaky bucket 200, the initial size of the leaky bucket corresponding to the instructions can be set to be smaller, while the initial size of the leaky bucket corresponding to the image data or network data transmission services can be set to be larger. Similarly, when setting the initial token generation rate of the token bucket 300, the scheduler 100 can set it according to the task planning requirements. For example, if the proportion of image data transmission in the task planning requirements is relatively high, the initial token generation rate of image data transmission can be set to be larger.

[0041] Preferably, the scheduler 100 can receive the real-time measurement results of the input rate of each service, that is, the input rate of the service data before the service data enters the leaky bucket 200, and then further determine the blocking degree of each service in the service queue cache 400 according to the real-time measurement results, and then determine the service to be scheduled according to the blocking degree, and then perform service scheduling through the scheduler 100. Specifically, the scheduler 100 adjusts the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

[0042] Preferably, in this embodiment, the services that need to be scheduled due to queue data congestion can be determined by the following formulas (1) and (2):

[0043]

[0044]

[0045] In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i (k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

[0046] From the above, it can be seen that the embodiment of the present application determines whether a data transmission surge has occurred in the business by obtaining the input rate ratio of each business, and then determines whether the business in the business queue cache 400 is blocked. According to the task planning, the initially set leaky bucket size and the token generation rate of the token bucket can meet the normal data transmission of the task, but it cannot be ruled out that some task data will surge in certain periods. Therefore, the scheduler 100 is required to monitor and implement corresponding task scheduling to ensure that normal transmission can be carried out even in the case of a surge in certain task data, so as to avoid data loss or excessive queuing delays for some tasks.

[0047] by Figure 1 For example, the three services A, B, and C in the k-th time slot are v. A (k), v B (k) and v C (k), according to formula (2), the average input rate in △T time slots before time slot k is and When the input rate of service A is is 1.5, the input rate of service B is is 2, the input rate of service C is When it is 0.8, according to formula (1), the value of j is B, that is, service B is the service that needs to be scheduled currently.

[0048] Preferably, in this embodiment, a threshold value may be set for the input rate ratio. When the input rate ratio of multiple services is higher than the preset threshold value, that is, When it is greater than the preset value, all services higher than the preset value can be regarded as services that need to be scheduled, and the real-time transmission of high-priority services can be guaranteed according to the priority. For example, the priority of spacecraft remote control commands is greater than the priority of image transmission. When the scheduler 100 detects intensive remote control commands and a large amount of image data transmission, if the rate ratio of the two services is greater than the preset value 4, the remote control command service and the image transmission service are both regarded as services that need to be scheduled. Since the priority of remote control commands is higher than that of image data transmission, the leaky bucket of image data services can be reduced, and the generation rate of remote control command tokens in the token bucket can be increased, and the generation rate of image data tokens can be reduced to ensure that the waiting delay of remote control service data is reduced, and the real-time performance of high-priority services is guaranteed to the greatest extent. It should be pointed out that the priority relationship of the service can also be changed through the scheduler 100, and can be changed and set according to different task planning requirements.

[0049] Preferably, the scheduler 100 adjusts the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data. Specifically, it may include: the scheduler 100 increases the generation rate of service tokens that need to be scheduled in the token bucket, reduces the token generation rate of other idle services, and simultaneously reduces the leaky bucket size of the service that needs to be scheduled to control the service data entering the service queue cache, thereby preventing data loss due to the full service queue cache.

[0050] When the service to be scheduled is no longer blocked after scheduling, the scheduler 100 can gradually reduce the generation rate of the corresponding token until it returns to the initial token generation rate, and gradually increase the corresponding leaky bucket size until it returns to the initial size.

[0051] In addition, preferably, the scheduler 100 in this embodiment can also control the generation rate of tokens in the token bucket to ensure that the total access rate of all services is not greater than the output rate, thereby ensuring that the aircraft uplink data will not be lost.

[0052] As described above, it can be seen from the above technical solutions that the aerospace uplink data flow dynamic control system provided by the present application can support multiple service requests at the same time, and can perform flow control according to the real-time transmission of service data, which can improve the real-time performance of data transmission and reduce congestion and delay. In addition, different initial bandwidths can be allocated to different services, and the bandwidth utilization rate is more reasonable. Finally, the real-time performance of high-priority service data transmission can be guaranteed.

[0053] like Figure 2 The figure is a flow chart of a method for dynamic control of aerospace uplink data flow provided by an embodiment of the present application. The method is a description of the present application from the scheduler side. The method includes the following steps:

[0054] Step S201: setting the initial sizes of multiple leaky buckets and the initial token generation rate of a token bucket according to task planning requirements, each of the leaky buckets corresponding to a service request access.

[0055] Step S202: adjusting the leaky bucket size according to the actual task transmission situation to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusting the token generation rate of the token bucket to adjust the output rate of each service, thereby ensuring the normal transmission of service data.

[0056] Preferably, in the above step S202, the leaky bucket size is adjusted according to the actual situation of task transmission to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to adjust the output rate of each service, thereby ensuring the normal transmission of service data, including:

[0057] Receive the real-time measurement results of the input rate of each service, and obtain the services that need to be scheduled due to queue data congestion based on the real-time measurement results, then adjust the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjust the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

[0058] Preferably, the acquiring the service that needs to be scheduled due to queue data blocking according to the real-time measurement result includes: determining the service that needs to be scheduled due to queue data blocking according to the real-time measurement result by the following formula:

[0059]

[0060]

[0061] In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i(k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

[0062] Preferably, in the method of this embodiment, if the input rate ratio of multiple services is higher than the preset value, that is, If it is greater than a preset value, all services higher than the preset value will be regarded as services that need to be scheduled, and the real-time transmission of high-priority services will be guaranteed according to the priority.

[0063] Preferably, in step S202 of this embodiment, the leaky bucket size is adjusted to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to control the output rate of each service, so as to ensure the normal transmission of service data. Specifically, it can include: increasing the generation rate of service tokens that need to be scheduled in the token bucket, reducing the token generation rate of other idle services, and reducing the leaky bucket size of the service that needs to be scheduled to control the service data entering the service queue cache to prevent data loss due to the full service queue cache.

[0064] Preferably, in the method of this embodiment, when the service to be scheduled is no longer blocked after scheduling, the generation rate of the corresponding token is gradually reduced until it is restored to the initial token generation rate, and the corresponding leaky bucket size is gradually increased until it is restored to the initial size.

[0065] As described above, it can be seen from the above technical solutions that the aerospace uplink data flow dynamic control method provided by the present application can support multiple service requests at the same time, and can perform flow control according to the real-time transmission of service data, which can improve the real-time performance of data transmission and reduce congestion and delay. In addition, different initial bandwidths can be allocated to different services, and the bandwidth utilization rate is more reasonable. Finally, the real-time performance of high-priority service data transmission can be guaranteed.

[0066] An embodiment of the present invention further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the above method is implemented when the processor executes the program.

[0067] An embodiment of the present invention further provides a computer program product, including a computer program / instruction, which implements the steps of the above method when the computer program / instruction is executed by a processor.

[0068] An embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program for executing the above method.

[0069] like Figure 3As shown, the electronic device 600 may further include: a communication module 110, an input unit 120, an audio processor 130, a display 160, and a power supply 170. It is worth noting that the electronic device 600 does not necessarily have to include Figure 3 In addition, the electronic device 600 may also include Figure 3 For components not shown, reference may be made to the prior art.

[0070] like Figure 3 As shown, the central processor 100 is sometimes also referred to as a controller or an operation control, and may include a microprocessor or other processor devices and / or logic devices. The central processor 100 receives inputs and controls the operations of various components of the electronic device 600.

[0071] The memory 140 may be, for example, one or more of a cache, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory or other suitable devices. The above-mentioned information related to the failure may be stored, and a program for executing the relevant information may also be stored. The CPU 100 may execute the program stored in the memory 140 to implement information storage or processing.

[0072] The input unit 120 provides input to the CPU 100. The input unit 120 is, for example, a key or a touch input device. The power supply 170 is used to provide power to the electronic device 600. The display 160 is used to display display objects such as images and text. The display may be, for example, an LCD display, but is not limited thereto.

[0073] The memory 140 may be a solid-state memory, such as a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It may also be a memory that saves information even when the power is off, can be selectively erased, and is provided with more data, examples of which are sometimes referred to as EPROMs, etc. The memory 140 may also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application / function storage unit 142, which is used to store application programs and function programs or processes for executing the operation of the electronic device 600 through the central processor 100.

[0074] The memory 140 may also include a data storage unit 143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 144 of the memory 140 may include various drivers for communication functions of the electronic device and / or for executing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0075] The communication module 110 is a transmitter / receiver 110 that transmits and receives signals via an antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processor 100 to provide input signals and receive output signals, which may be the same as the case of a conventional mobile communication terminal.

[0076] Based on different communication technologies, multiple communication modules 110 may be provided in the same electronic device, such as a cellular network module, a Bluetooth module and / or a wireless LAN module. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide an audio output via the speaker 131 and receive an audio input from the microphone 132, thereby realizing a common telecommunication function. The audio processor 130 may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor 130 is also coupled to the central processor 100, so that recording can be performed on the local machine through the microphone 132, and the sound stored on the local machine can be played through the speaker 131.

[0077] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0079] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0080] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0081] The present invention uses specific embodiments to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A dynamic control system for aerospace uplink data flow, characterized in that: The system includes: a scheduler, multiple leaky buckets, a token bucket and a service queue cache, each leaky bucket is used to access a service request and send uplink service data to the service queue cache, the token bucket is used to control the output rate of the uplink service data in the service queue cache, the scheduler is used to set the initial size of the leaky bucket and the initial token generation rate of the token bucket according to task planning requirements, and is used to adjust the leaky bucket size according to the actual task transmission situation to control the bandwidth resources occupied by each service when entering the service queue cache, and adjust the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

2. The aerospace uplink data flow dynamic control system according to claim 1, characterized in that: The scheduler adjusts the leaky bucket size according to the actual task transmission situation to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data, including: The scheduler receives the real-time measurement results of the input rate of each service, and obtains the services that need to be scheduled due to queue data congestion based on the real-time measurement results, and then adjusts the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

3. The aerospace uplink data flow dynamic control system as claimed in claim 2, characterized in that: The scheduler obtains the services that need to be scheduled due to queue data blocking according to the real-time measurement result, including: The scheduler determines the service that needs to be scheduled due to queue data congestion according to the real-time measurement result by the following formula: In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i (k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

4. The aerospace uplink data flow dynamic control system as claimed in claim 3, characterized in that: If the input rate ratio of multiple services is higher than the preset value, that is, If it is greater than a preset value, all services higher than the preset value will be regarded as services that need to be scheduled, and the real-time transmission of high-priority services will be guaranteed according to the priority.

5. The aerospace uplink data flow dynamic control system according to claim 3 or 4, characterized in that: The scheduler adjusts the size of the leaky bucket to control the bandwidth resources occupied by each service when entering the service queue cache, and adjusts the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data, including: The scheduler increases the generation rate of service tokens that need to be scheduled in the token bucket, reduces the token generation rate of other idle services, and reduces the leaky bucket size of the services that need to be scheduled to control the service data entering the service queue cache to prevent data loss due to the full service queue cache.

6. The aerospace uplink data flow dynamic control system as claimed in claim 5, characterized in that: When the service to be scheduled is no longer blocked after scheduling, the scheduler gradually reduces the generation rate of the corresponding tokens until it returns to the initial token generation rate, and gradually increases the corresponding leaky bucket size until it returns to the initial size.

7. A method for dynamically controlling aerospace uplink data flow, characterized in that: The method comprises: Set the initial sizes of multiple leaky buckets and the initial token generation rate of a token bucket according to task planning requirements. Each leaky bucket corresponds to a service request access. The size of the leaky bucket is adjusted according to the actual task transmission situation to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to adjust the output rate of each service, thereby ensuring the normal transmission of service data.

8. The method for dynamically controlling aerospace uplink data flow as claimed in claim 7, characterized in that: According to the actual situation of task transmission, the size of the leaky bucket is adjusted to control the bandwidth resources occupied by each service when entering the service queue cache, and the token generation rate of the token bucket is adjusted to adjust the output rate of each service, thereby ensuring the normal transmission of service data, including: Receive the real-time measurement results of the input rate of each service, and obtain the services that need to be scheduled due to queue data congestion based on the real-time measurement results, then adjust the leaky bucket size to control the bandwidth resources occupied by each service when entering the service queue cache, and adjust the token generation rate of the token bucket to control the output rate of each service, thereby ensuring the normal transmission of service data.

9. The method for dynamically controlling aerospace uplink data flow as claimed in claim 8, characterized in that: Acquiring services that need to be scheduled due to queue data blocking according to the real-time measurement results includes: The services that need to be scheduled due to queue data congestion are determined according to the real-time measurement results by the following formula: In the above formula: j indicates that the business with the most blocked queue data in the current time window is selected for scheduling; i indicates the task number; v i (k) represents the input rate of the i-th task data at the current k-th time slot; represents the average input rate of the ΔT time slots before the i-th task to the k-th time slot; ΔT represents the time window size.

10. The method for dynamically controlling aerospace uplink data flow as claimed in claim 9, characterized in that: If the input rate ratio of multiple services is higher than the preset value, that is, If it is greater than a preset value, all services higher than the preset value will be regarded as services that need to be scheduled, and the real-time transmission of high-priority services will be guaranteed according to the priority.