Traffic shaping method, apparatus, video device, and computer program product

Abstract

This application discloses a traffic shaping method, a traffic shaping device, a video device, and a computer program product. The method includes: classifying traffic within the video device based on preset traffic characteristics; allocating corresponding token buckets to each type of traffic and setting shaping parameters for each token bucket based on a preset shaping strategy; determining a target parameter adjustment strategy from a preset first parameter adjustment strategy and a second parameter adjustment strategy based on the bandwidth status of the video device, wherein the first parameter adjustment strategy and the second parameter adjustment strategy impose different constraints on the shaping parameters; adjusting the shaping parameters of each token bucket according to the target parameter adjustment strategy; and shaping and transmitting the corresponding type of traffic based on the latest shaping parameters of each token bucket. This application's solution can improve the transmission performance of various types of traffic by video devices under dynamic bandwidth conditions.

Description

Technical Field

[0001] This application belongs to the field of wireless communication technology, and in particular relates to a traffic shaping method, a traffic shaping device, a video device, and a computer program product. Background Technology

[0002] In network transmission scenarios for video devices, various service traffic flows often occur concurrently. The requirements for latency, reliability, and bandwidth usage differ significantly among these different flows, making traffic management highly complex. Currently, related technologies typically employ fixed parameters or a single strategy to schedule overall traffic, such as uniform rate configuration, uniform queue rules, or a single token bucket scheme. However, wireless network bandwidth is easily affected by environmental factors, transmission distance, and signal interference, causing dynamic fluctuations. Furthermore, the bitrate of video streams fluctuates significantly depending on the complexity of the video image, making it difficult for existing traffic shaping and scheduling schemes to achieve ideal transmission results for various types of traffic. Summary of the Invention

[0003] This application provides a traffic shaping method, a traffic shaping device, a video device, and a computer program product, which can improve the transmission effect of various types of traffic under dynamic bandwidth conditions.

[0004] In a first aspect, this application provides a flow shaping method, including: Traffic within video devices is classified based on preset traffic characteristics; Allocate corresponding token buckets to various types of traffic, and set the shaping parameters of each token bucket based on the preset shaping strategy; Based on the bandwidth status of video devices, a target parameter adjustment strategy is determined from the preset first parameter adjustment strategy and second parameter adjustment strategy. The first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter. Adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy; Based on the latest shaping parameters of each token bucket, the corresponding types of traffic are shaped and sent.

[0005] Secondly, this application provides a flow shaping device, comprising: The classification module is used to classify traffic within video devices based on preset traffic characteristics; The configuration module is used to allocate corresponding token buckets to various types of traffic and set the shaping parameters of each token bucket based on the preset shaping strategy. The determination module is used to determine the target parameter adjustment strategy based on the bandwidth status of the video device, from the preset first parameter adjustment strategy and the second parameter adjustment strategy, wherein the first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter; The adjustment module is used to adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy. The transmission module is used to shape and send the corresponding types of traffic based on the latest shaping parameters of each token bucket.

[0006] Thirdly, this application provides a video device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in the first aspect.

[0007] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0008] Fifthly, this application provides a computer program product comprising a computer program that, when executed by one or more processors, implements the steps of the method described in the first aspect.

[0009] The beneficial effects of this application compared to existing technologies are as follows: This application classifies traffic within video devices and allocates corresponding token buckets to each type of traffic, achieving differentiated management of multiple traffic types. Furthermore, based on the device bandwidth status, this application determines a target parameter adjustment strategy among two strategies with different adjustment constraints and dynamically adjusts the shaping parameters of each type of traffic. This allows for the shaping and transmission of each type of traffic based on the adjusted shaping parameters, adapting to the dynamic changes in wireless network bandwidth. Based on this application, the adaptability of traffic scheduling can be effectively improved, transmission performance under dynamic bandwidth can be enhanced, and the stability of video service transmission can be guaranteed. It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram illustrating the implementation process of the flow shaping method provided in the embodiments of this application; Figure 2 This is an example diagram illustrating the configuration of the shaping strategy provided in this application for various types of traffic. Figure 3This is a structural block diagram of the flow shaping device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a video device provided in an embodiment of this application. Detailed Implementation

[0012] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0014] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly indicating the number, specific order, or primary and secondary relationship of the indicated technical features.

[0015] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0016] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0017] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), unless otherwise expressly and specifically defined.

[0018] Video devices typically need to transmit multiple types of data streams simultaneously via wireless networks or bandwidth-constrained links, such as preview streams, recording streams, cloud recording streams, and intercom streams. Different types of traffic differ in bandwidth consumption, real-time requirements, and service importance. For example, preview traffic is more sensitive to latency, while cloud recording traffic prioritizes data integrity and continuous transmission capability. When multiple types of traffic are transmitted concurrently, without an effective bandwidth management mechanism, the shared link bandwidth can easily lead to bandwidth contention, impacting the overall transmission performance of video devices. Furthermore, different service traffic types differ in their generation patterns; some traffic is continuously and stably output, while others exhibit bursty characteristics. When bursty traffic occurs, without differentiated management of different types of traffic, it can consume a large amount of bandwidth resources in a short period, affecting the normal transmission of other critical service traffic. Simultaneously, some traffic with lower real-time requirements but longer durations, if occupying bandwidth for an extended period, can also impact real-time services. For example, sudden surges in traffic such as resume downloads or event reporting may cause audio and video stream delays or even packet loss. Low-latency services such as continuous background recording and uploading will continuously consume bandwidth, affecting the transmission of high-latency traffic such as real-time preview.

[0019] Furthermore, video streams from video devices typically exhibit significant bitrate fluctuations. Since video encoding bitrate is related to image complexity, the bitrate can increase dramatically in a short period when there are more moving objects, changes in lighting, or scene transitions; conversely, it can decrease significantly when the image is relatively still. This bitrate fluctuation leads to dynamic changes in bandwidth demand. If fixed shaping parameters are used for transmission control, data backlog can easily occur during sudden bitrate increases, while bandwidth resources may be idled during bitrate decreases.

[0020] Furthermore, wireless network environments are typically highly uncertain. Factors such as channel interference, network congestion, or terminal mobility can all cause significant fluctuations in available bandwidth. When bandwidth decreases, if various types of traffic maintain their original transmission rates, it can easily lead to backlogs in the transmission queue and packet loss. Conversely, when bandwidth recovers, if the transmission rates of various types of traffic cannot be restored in a timely manner, it will affect bandwidth utilization efficiency.

[0021] Based on this, this application proposes a traffic shaping method that can effectively manage and control various types of traffic, and proposes different strategies for dynamically adjusting shaping parameters. This traffic shaping method can be applied to video devices, which are terminal devices equipped with video acquisition and transmission functions, including but not limited to network cameras, video surveillance terminals, or embedded devices with video encoding and network transmission capabilities. No specific device type is limited here. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 The implementation flow of the traffic shaping method applied to this type of video device is given, and the details are as follows: Step 101: Classify the traffic within video devices based on preset traffic characteristics.

[0022] During the operation of video devices, multiple types of service traffic are usually generated simultaneously, including but not limited to cloud event streams, preview streams, recording streams, resumeable streams, cloud recording streams, and intercom streams. Different service traffic types differ in terms of bandwidth usage, real-time requirements, and importance.

[0023] Video devices can be pre-configured to map traffic characteristics to traffic categories. When a data stream is detected, the video device's flow sensing center can classify it into the corresponding traffic category based on its traffic characteristics. These traffic characteristics characterize the service attributes or transmission features of the traffic and may include information such as service type, priority identifier, bitrate, port number, protocol type, and / or data source module. This allows video devices to accurately identify the type of each traffic stream, enabling subsequent classification and management of various traffic types within the video device.

[0024] This step categorizes the traffic within video devices, enabling different types of service traffic to be processed separately. This lays the foundation for subsequent rate control and bandwidth allocation for different types of traffic, thereby avoiding disorderly competition for bandwidth resources among various types of traffic.

[0025] Step 102: Assign corresponding token buckets to various types of traffic, and set the shaping parameters of each token bucket based on the preset shaping strategy.

[0026] After traffic classification is completed, a corresponding token bucket can be assigned to each type of traffic. The token bucket is a traffic shaping mechanism used to control the data transmission rate. It generates tokens at a preset rate and allows data transmission only when there are sufficient tokens, thus limiting the output rate of traffic. Each token bucket can independently correspond to one type of traffic, and token generation and consumption are independent of each other between different token buckets.

[0027] Specifically, video devices use a shaping strategy engine to set and dynamically optimize the shaping parameters of each token bucket. This engine includes a shaping strategy, a first parameter adjustment strategy, and a second parameter adjustment strategy. The shaping strategy determines the initial shaping parameters of each token bucket and can be configured based on the importance of various traffic types, expected bitrate, and / or bandwidth allocation ratios. The shaping parameters describe the shaping capability of the token bucket, including but not limited to parameters such as committed rate, peak rate, or burst capacity.

[0028] In this embodiment, each token bucket can be configured with corresponding shaping parameters according to the shaping strategy, serving as the initial control basis for subsequent traffic shaping. Of course, when a certain type of traffic changes subsequently, video devices can also reset some or all of the shaping parameters of the token bucket according to the shaping strategy; this embodiment does not limit this.

[0029] This step achieves independent bandwidth control for different service traffic by allocating independent token buckets and setting shaping parameters for each type of traffic, enabling different traffic to be sent according to their respective rate constraints.

[0030] Step 103: Based on the bandwidth status of the video device, determine the target parameter adjustment strategy from the preset first parameter adjustment strategy and second parameter adjustment strategy.

[0031] During the operation of video devices, network bandwidth may change dynamically over time. Therefore, the shaping parameters of the token bucket corresponding to various types of traffic can be dynamically adjusted based on the bandwidth status. The bandwidth status is used to characterize the available bandwidth margin of the current video devices, and can be evaluated by statistically analyzing information such as send queue length, negotiation rate, channel occupancy, packet loss, and / or actual send rate.

[0032] In this embodiment, a first parameter adjustment strategy and a second parameter adjustment strategy can be preset. The first parameter adjustment strategy is used to coordinate and adjust the shaping parameters of different traffic flows when bandwidth is tight, so as to limit the transmission rate of some traffic flows. The second parameter adjustment strategy is used to adaptively adjust various types of traffic flows when bandwidth is relatively sufficient, so as to improve bandwidth utilization efficiency. Therefore, the first parameter adjustment strategy and the second parameter adjustment strategy impose different constraints on the shaping parameters; that is, the two adjustment strategies have different adjustment ranges or adjustment methods for the shaping parameters. For example, the first parameter adjustment strategy has a certain upper limit constraint on the adjustment of the shaping parameters, while the second parameter adjustment strategy has a certain lower limit constraint. Based on the current bandwidth status, video devices can select the more suitable target parameter adjustment strategy between the two strategies as the basis for subsequent shaping parameter adjustment.

[0033] This step involves selecting different parameter adjustment strategies based on bandwidth status, thereby prioritizing critical traffic when bandwidth is insufficient and improving bandwidth utilization when bandwidth is sufficient, thus achieving more flexible bandwidth management.

[0034] Step 104: Adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy.

[0035] After determining the target parameter adjustment strategy, the shaping parameters of each token bucket can be adjusted according to this strategy. For example, when the target parameter adjustment strategy is the first parameter adjustment strategy, the shaping parameters of some token buckets can be reduced due to insufficient bandwidth to decrease their bandwidth usage; when the target parameter adjustment strategy is the second parameter adjustment strategy, the shaping parameters of the corresponding token buckets can be increased or decreased according to the transmission status of various traffic types, thereby achieving adaptive adjustment. By dynamically adjusting the shaping parameters of each token bucket, the transmission rate of different traffic types can change with the bandwidth status.

[0036] This step adjusts the shaping parameters of each token bucket, enabling the traffic shaping mechanism to dynamically change the sending rate of various types of traffic, thereby adapting to bandwidth changes and optimizing bandwidth allocation.

[0037] Step 105: Based on the latest shaping parameters of each token bucket, shape the corresponding types of traffic and send them.

[0038] After the shaping parameters are adjusted, each token bucket generates tokens according to the updated shaping parameters, and uses these tokens to control the transmission of the corresponding traffic. When data of a certain type of traffic arrives in the transmission queue, data transmission is only allowed if there are enough tokens in the corresponding token bucket; otherwise, transmission waits for tokens to be replenished. In this way, various types of traffic are transmitted at a controlled rate according to their updated shaping parameters, thereby achieving shaping control of the overall output traffic of video devices.

[0039] Specifically, video devices can use a proportional shaper to shape various types of traffic. This proportional shaper is the executor of the shaping process, responsible for intercepting and classifying the traffic for shaping. In this embodiment, the requirement for the proportional shaper is to guarantee bandwidth for different types of traffic, and the mature Linux HTB model can be used. The core of the HTB model lies in its hierarchical class structure and bandwidth borrowing mechanism. In the HTB model, each class can have subclasses, forming a tree structure. The parent class can allocate bandwidth to its subclasses, and subclasses can borrow bandwidth based on priority. This design allows the proportional shaper based on the HTB model to both guarantee the bandwidth requirements of critical services and maximize the utilization of idle bandwidth.

[0040] This step reshapes and sends various types of traffic based on the latest reshaping parameters of each token bucket, enabling the bandwidth-based adjustment results to take effect in a timely manner, thereby achieving dynamic bandwidth control of multiple types of traffic from video devices.

[0041] As described above, video devices can be equipped with a stream-aware hub. It's understood that the traffic and parameters of video devices may change dynamically, with different traffic types requiring different shaping. Therefore, this stream-aware hub can dynamically detect these changes, including but not limited to: stream additions, stream deletions, and changes in stream parameters. Specifically, when a stream is added, a token bucket can be added according to the traffic characteristics to shape it; when a stream is deleted, the corresponding token bucket can be deleted; and when stream parameters change, the shaping parameters of the corresponding token bucket can be adjusted. Based on this, step 101 can be implemented in the following way: The flow perception hub can subscribe to socket actions from various service stakeholders, such as video clients, intercom services, and cloud event modules, during traffic classification, and configure the events emitted by each socket action to achieve perception of various types of traffic. Since the above operations subscribe to the source of the stream, traffic type differentiation is possible. However, video streams (whether preview or recording) originate from the same source, and their video transmission protocols lack corresponding markers; therefore, the distinction between recording and preview streams can be achieved based on device-specified or user-specified information. Thus, the flow perception hub can classify the traffic detected within video devices into different types, such as cloud event streams, recording streams, resumeable streams, cloud recording streams, intercom streams, and preview streams, achieving classification and identification based on traffic characteristics.

[0042] In addition to identifying and classifying traffic, the stream perception center can also acquire key stream metrics for various types of traffic. Specifically, for both video and audio streams, the stream perception center can use the encoder bitrate as the primary key stream metric, which can be read from the hardware encoder's registers or a designated interface, or calculated by statistically analyzing the amount of data output by the encoder within a fixed time window. Furthermore, for video streams, the key stream metrics acquired by the stream perception center can also include I-frame size and GOP length. The key stream metrics obtained above can be used for subsequent strategies. That is, for video streams, the key stream metrics obtained by the stream perception center are: encoder bitrate, I-frame size, and GOP length, where the encoder bitrate is the primary metric, and the I-frame size and GOP length are secondary metrics; for audio streams, the key stream metric obtained by the stream perception center is: encoder bitrate.

[0043] The shaping strategy can set the shaping parameters of its corresponding token bucket based on the encoder bitrate, such as the committed rate and peak rate. In this embodiment, the committed rate (equivalent to the initial value of the committed rate of the flow after the flow is added or changed) set by the shaping strategy based on the encoder bitrate of various types of traffic is recorded as the reference rate. That is, when the flow sensing center senses a new flow event of a certain type of traffic, it can obtain the key indicators of that type of traffic; then the shaping strategy engine can call the shaping strategy, based on the encoder bitrate in the key indicators of the flow, and use an initialization strategy corresponding to that type of traffic to determine the reference bitrate of that type of traffic. This initialization strategy can be set based on the calculation formula of the reference bitrate of that type of traffic, for example, the reference bitrate is a certain multiple of the encoder bitrate, or it can be extended to other possible calculation formulas; of course, other initialization strategies can also be used; thus, the shaping strategy engine can use this reference bitrate as the reference rate for that type of flow. The initial committed rate is also the baseline committed rate. Based on this, the shaping strategy engine can call the first parameter adjustment strategy or the second parameter adjustment strategy to dynamically adjust the committed rate of this type of traffic (during the adjustment process, it is constrained by the reference rate, i.e., the baseline committed rate). Subsequently, when the flow perception center senses a change in the flow parameters of this type of traffic, it can reacquire the key flow indicators of this type of traffic, and the shaping strategy engine will again call the shaping strategy first, and then call the first parameter adjustment strategy or the second parameter adjustment strategy to reset and dynamically adjust the committed rate of this type of traffic again. This will not be elaborated here.

[0044] Therefore, by using the flow sensing center to identify flow types and collect key flow indicators, a classification basis and data support are provided for subsequent token bucket allocation, shaping parameter configuration and dynamic adjustment.

[0045] In some embodiments, different traffic types have different requirements for video devices. Therefore, the shaping strategy for each token bucket can be configured with the following parameters for each identified possible traffic type: 1. Cloud Event Stream The goal of cloud event stream shaping is to ensure bandwidth to avoid packet loss and reduce latency. Its core principle is: Guarantee bandwidth: Allocate stable bandwidth to cloud event streams to prevent them from being consumed by other large data traffic, which could lead to packet loss due to starvation. Reduce latency: Adopt low-latency queuing rules to minimize queuing time and control latency.

[0046] Based on this, the shaping strategy for cloud event streams can be configured as follows: Qdisc employs CoDel, ensuring a fixed transmission bandwidth and leveraging CoDel's low-latency characteristics to optimize latency. It's understandable that CoDel can reduce latency (effective only for TCP), and stream-following shaping effectively eliminates spikes and limits maximum bandwidth.

[0047] 2. Video stream and resume stream The goal of video stream shaping and resumeable streaming is to ensure stable bandwidth, improve reliability, and avoid packet loss. Its core principle is: Guaranteed bandwidth: Allocate sufficient and stable minimum guaranteed bandwidth for video streams and resumed streams, which should generally not be lower than their average / peak bitrate requirements; Avoid excessive rate limiting: Be very careful when limiting its maximum bandwidth. The upper limit should be set much higher than its actual bit rate to prevent excessive compression during unexpected congestion, which could lead to recording interruption or damage. High priority: High-priority queues are used to ensure that video streams and resumeable streams are processed before audio streams such as walkie-talkies and preview streams when the network is congested.

[0048] Based on this, the shaping strategy can be configured as follows for video streams and resumed streams: Qdisc uses pfifo_fast to smooth out peak burst traffic and eliminate the impact of peak traffic bursts on low-latency traffic. It's understandable that pfifo_fast doesn't employ a low-latency strategy, making it suitable for environments with ample bandwidth. In addition, a relatively lenient rate limit is set to ensure normal transmission; for example, both the committed rate and peak rate are 1.2 times the encoder bitrate (i.e., the reference rate is 1.2 times the encoder bitrate).

[0049] 3. Cloud video streaming Cloud video streaming specifically refers to cloud video upload streams. Its shaping goal is to allow bursts of video but strictly limit peak times to prevent congestion. Its core principle is: Managing sudden surges: Sudden surges are allowed, but their peak rates must be limited to prevent the upstream bandwidth from being instantly filled, causing other high-priority traffic to be stuck or even disconnected. Prioritize reliability over real-time performance: Use guaranteed bandwidth or medium-priority queues to ensure they receive the bandwidth required for uploading, but do not pursue the lowest latency as with preview streams; allow queuing; and prioritize guaranteed bandwidth over preview streams when bandwidth is insufficient. Avoid starvation: In shaping strategies, it is essential to ensure that cloud video streams do not receive no bandwidth due to low priority when there are no events for extended periods.

[0050] Based on this, the shaping strategy for cloud video streams can be configured as follows: The reliability of cloud video streams is slightly lower than that of cloud event streams and video streams. Under extreme bandwidth conditions, bandwidth is guaranteed with secondary priority. Qdisc uses pfifo_fast. Since low latency is not considered, peak limits are also applied. For example, the committed rate and peak rate are both encoder bitrate × 1.2 (that is, the reference rate is encoder bitrate × 1.2).

[0051] 4. Intercom Stream The goal of stream shaping for intercom is ultra-low latency and minimal packet loss. Its core principle is: Low latency: When bandwidth is sufficient, intercom traffic should be forwarded first to minimize voice latency. When bandwidth is insufficient, a certain degree of compression of intercom traffic is allowed. Limiting jitter: The priority forwarding mechanism itself helps reduce jitter and ensures that the queues for processing voice packets are very short or dedicated.

[0052] Based on this, the shaping strategy for the intercom stream can be configured as follows: Qdisc uses CoDel, which guarantees bandwidth when there is sufficient bandwidth, for example, the committed rate and peak rate are both 1.2 times the encoder bitrate (i.e., the reference rate is 1.2 times the encoder bitrate), and allows bursts up to 1.5 times the encoder bitrate. When bandwidth is insufficient, rate limiting is implemented.

[0053] 5. Preview Stream The goal of shaping the preview stream is low latency, allowing for a small amount of jitter and packet loss. Its core principle is: Ensuring low latency: This is the most critical goal of the preview stream, requiring the use of a low-latency queue and ensuring it receives sufficient bandwidth; Limiting maximum bandwidth: A reasonable maximum bandwidth limit can be set for single or multiple preview streams to prevent a single user's high bitrate request from exhausting the bandwidth (especially on mobile networks), but the limit value should be lenient enough to avoid introducing additional latency; Handling bursts: Employ queuing mechanisms (e.g., large burst sizes) to tolerate normal bitrate fluctuations in the preview stream and avoid increased jitter or latency due to bursts being penalized by the shaper.

[0054] Based on this, the shaping strategy can be configured as follows for the preview stream: Qdisc uses CoDel to guarantee bandwidth when there is sufficient bandwidth, for example, promising a rate of 1.2 times the encoder bitrate (i.e., a reference rate of 1.2 times the encoder bitrate), and using I-frames to estimate the peak rate. When bandwidth is insufficient, rate limiting is implemented.

[0055] Please see Figure 2 , Figure 2 This document provides a possible configuration example of an integer shaping strategy for various traffic types. As can be seen, based on this shaping strategy, the Qdisc, bandwidth, and priority (corresponding to...) can be set for various traffic types. Figure 2 (prio in the text) etc.

[0056] In some embodiments, the most important shaping parameters of the token bucket are the committed rate and the peak rate. Considering the burstiness of the peak rate-limited flow, adjustments may cause the peak rate to exceed expectations, affecting other flows; therefore, this embodiment only adjusts the committed rate. As described above, the first parameter adjustment strategy and the second parameter adjustment strategy are adjustment strategies proposed for different bandwidth scenarios; therefore, step 103 may specifically include: Step 1031: Calculate the bandwidth evaluation index within video devices.

[0057] During the operation of video devices, the current network bandwidth usage can be assessed by statistically analyzing the transmission of various types of traffic. This application introduces a bandwidth assessment metric to characterize the current bandwidth margin of the video devices. This metric can be calculated based on the relationship between the target transmission rate and the actual transmission rate of various types of traffic in the video devices, or it can be calculated based on information such as the backlog in the transmission buffer, packet loss rate, or queuing latency, to reflect whether the current bandwidth is sufficient.

[0058] In some examples, this bandwidth evaluation metric can be calculated using the following formula: WBEI = Rate 总承诺速率 ÷ (α × Rate) 协商速率 ×(1-CU 信道利用率 (×PSR) Where WBEI represents the calculated bandwidth evaluation index; Rate 总承诺速率 The token bucket represents the sum of committed rates for various types of traffic; Rate 协商速率 This indicates the wireless negotiation rate, which can be determined based on the wireless environment, similar to the theoretical maximum rate; CU 信道利用率 The utilization rate of the wireless channel can be obtained by dividing the channel occupancy time by the statistical time, where the channel occupancy time is the time the channel is occupied within that statistical time. The PSR represents the packet success rate, which can be obtained by first calculating the packet error rate (PER) and then subtracting PER from the PER. α is a preset evaluation coefficient, typically with a value of 0.25. The derivation of this formula is briefly described below: When assessing available wireless bandwidth, channel utilization determines how many air interfaces are currently available, and the negotiation rate determines how much data can be transmitted over those air interfaces. Therefore, available bandwidth can be roughly estimated based on channel utilization and negotiation rate. However, this estimation ignores the collision problem, which needs to consider multiple terminals (STAs, stations) and interference in the environment. Theoretically, the collision probability should be assessed based on interference and the number of terminals, but in practice, PSR can also reflect the collision probability indirectly. Therefore, available bandwidth can be assessed based on channel utilization, negotiation rate, and PSR, resulting in the above formula. In the above formula, the product of negotiation rate, channel idle rate, and PSR is used to simplify the assessment of wireless bandwidth. It also assumes that channel utilization and PSR are independent, ignores protocol overhead and overhead at different rates, and assumes that the packet size is fixed or average. Finally, by comparing the total committed rate with the assessed value of wireless bandwidth, the bandwidth margin, i.e., the bandwidth assessment index, is obtained.

[0059] Step 1032: If the bandwidth evaluation index is higher than the preset index threshold, the first parameter adjustment strategy is determined as the target parameter adjustment strategy.

[0060] To enable flexible strategy switching, a threshold value can be preset to distinguish between bandwidth-constrained and normal bandwidth conditions. When the bandwidth assessment indicator exceeds this threshold, it indicates that the transmission demand of video devices exceeds the currently available bandwidth, and the link is in a bandwidth-insufficient state. In this case, the first parameter adjustment strategy is determined as the target parameter adjustment strategy.

[0061] The first parameter adjustment strategy can coordinate and adjust the shaping parameters of various traffic types when bandwidth is insufficient, thereby reducing the transmission rate of some traffic and freeing up bandwidth resources. For example, the token bucket commitment rate corresponding to low-priority traffic can be reduced first, thus reserving bandwidth for high-priority traffic. In this way, different traffic types can be coordinated and controlled when bandwidth is insufficient.

[0062] Step 1033: If the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate after adjustment based on the first parameter adjustment strategy has not recovered to the reference rate, the first parameter adjustment strategy is determined as the target parameter adjustment strategy.

[0063] When the bandwidth assessment metric drops below the metric threshold, it indicates that the bandwidth situation has improved. However, after bandwidth recovery, the committed rates of some traffic may still remain in the previously reduced state, thus requiring a gradual restoration of their committed rates. In this embodiment, a reference rate is introduced as the target for restoring the committed rates. This reference rate is the baseline committed rate configured by the shaping strategy for each token bucket, as described above, and will not be repeated here.

[0064] When the bandwidth assessment metric is below or equal to the threshold, but the current committed rate for a certain type of traffic has not yet recovered to the corresponding reference rate, the first parameter adjustment strategy continues to be used to gradually restore the committed rate, instead of immediately switching to the second parameter adjustment strategy. This avoids rate fluctuations caused by immediately switching to another strategy as bandwidth recovers, thus ensuring a smooth and stable rate adjustment process.

[0065] Step 1034: If the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has recovered to the reference rate, the second parameter adjustment strategy is determined as the target parameter adjustment strategy.

[0066] When the bandwidth assessment metrics remain within the threshold and the committed rates for all types of traffic have recovered to the reference rates, it indicates that the bandwidth is sufficient to meet the basic bandwidth requirements. At this point, the second parameter adjustment strategy can be determined as the target parameter adjustment strategy. This second parameter adjustment strategy can adaptively adjust the committed rates for various types of traffic when bandwidth is relatively sufficient. For example, it can appropriately increase or decrease the committed rates based on buffering conditions or changes in transmission rates to further improve bandwidth utilization efficiency.

[0067] Of course, video devices can also determine bandwidth status in other ways. For example, if the channel utilization is greater than a preset utilization threshold and / or the packet error rate is greater than a preset error rate threshold, the bandwidth is considered insufficient; conversely, if the channel utilization is less than or equal to the utilization threshold and the packet error rate is less than or equal to the error rate threshold, the bandwidth is considered sufficient.

[0068] In some embodiments, when the target parameter adjustment strategy is the first parameter adjustment strategy and the bandwidth evaluation index is higher than the index threshold, step 104 may specifically include: Step 1041: Calculate the rate penalty value for each token bucket based on the priority of various types of traffic, the preset penalty coefficient, and the current committed rate of each token bucket.

[0069] As described above, when the bandwidth assessment index exceeds the index threshold, it indicates that video devices are in a state of insufficient bandwidth. In this case, the first parameter adjustment strategy is used to limit the rate of various types of traffic. In this embodiment, the penalty mechanism in the first parameter adjustment strategy is used to calculate the rate penalty value to determine the reduction in the promised rate corresponding to each type of traffic.

[0070] Priority is used to indicate the importance of different types of traffic, and different priorities have different adjustment ranges when bandwidth is insufficient. It can be understood that the priority of various traffic types can be configured through shaping strategies, such as... Figure 2The `prio` parameter configured for each type of traffic represents the priority of that traffic type. Therefore, it can be concluded that: Figure 2 In the cloud streaming hierarchy, cloud event streams, video streams, and resumeable streams have the highest priority; cloud video streams and intercom streams have the second highest priority; intercom streams and preview streams have the next lowest priority; and other streams have the lowest priority. When bandwidth is insufficient, lower-priority traffic receives a larger penalty, while higher-priority traffic receives a smaller penalty.

[0071] The penalty coefficient controls the extent of the rate reduction and can be pre-configured according to system design requirements. In some examples, different penalty coefficients may correspond to different traffic priorities, or a uniform, base penalty coefficient may be used.

[0072] The current commitment rate of each token bucket is the commitment rate value that is currently in effect for each token bucket, which is used to represent the rate at which the current token bucket generates tokens.

[0073] In one example, the rate penalty value for each type of traffic can be determined based on the product of the current committed rate, penalty coefficient, and priority of each type of traffic in each token bucket. Taking any type of traffic as an example, the formula for calculating its rate penalty value can be as follows: Δ rate1 =β 惩罚 ×Rate 类速率 ×prio Where, Δ rate1 This represents the rate penalty value for this type of traffic; β 惩罚 Rate represents the penalty coefficient. 类速率 This indicates the current committed rate of the token bucket for this type of traffic; prio indicates the priority of this type of traffic.

[0074] Step 1042: Reduce the committed rate of each token bucket according to the rate penalty value of each token bucket.

[0075] After obtaining the rate penalty value for each token bucket, the current committed rate can be adjusted based on this penalty value to obtain the adjusted committed rate. For example, for a certain type of traffic, the current committed rate of its token bucket can be subtracted from the corresponding rate penalty value to obtain a new committed rate. Through this adjustment method, low-priority traffic reduces its bandwidth usage when bandwidth is insufficient, thereby freeing up bandwidth resources and ensuring the transmission needs of high-priority traffic.

[0076] Through the above steps, video devices can calculate the rate penalty value based on traffic priority and penalty coefficient when the bandwidth assessment index is higher than the index threshold, and reduce the promised rate accordingly. This enables coordinated control of various types of traffic in the event of insufficient bandwidth, thereby alleviating bandwidth congestion and ensuring the transmission performance of critical traffic.

[0077] In some embodiments, when the target parameter adjustment strategy is the first parameter adjustment strategy, the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, step 104 may specifically include: Step 1043: Calculate the rate recovery value for each token bucket based on the priority of various traffic types, the preset recovery coefficient, and the current committed rate of each token bucket.

[0078] When the bandwidth assessment metric is lower than or equal to the metric threshold, it indicates that the link bandwidth situation has improved, but the committed rate of some traffic may still be at the level after being reduced during the previous insufficient bandwidth phase (i.e., it has not recovered to the corresponding reference rate). In order to gradually restore various types of traffic to the normal bandwidth configuration, the recovery mechanism in the first parameter adjustment strategy is adopted in this embodiment of the application, which gradually increases the committed rate by calculating the rate recovery value.

[0079] The recovery coefficient controls the magnitude of the promised rate recovery and can be pre-configured according to system design requirements. In some examples, different recovery coefficients may correspond to different traffic priorities, or a uniform, base recovery coefficient may be used.

[0080] In one example, similar to the rate penalty value, the rate recovery value for each type of traffic can be determined based on the product of the current committed rate of each token bucket, the recovery factor, and the priority of each type of traffic. Taking any type of traffic as an example, the formula for calculating its rate recovery value can be as follows: Δ rate2 =β 恢复 ×Rate 类速率 ×prio Where, Δ rate2 This represents the rate recovery value for this type of traffic; β 恢复 Rate represents the coefficient of recovery. 类速率 This indicates the current committed rate of the token bucket for this type of traffic; prio indicates the priority of this type of traffic.

[0081] Step 1044: Increase the committed rate of each token bucket according to the rate recovery value and reference rate of each token bucket.

[0082] After obtaining the rate recovery values ​​for each token bucket, the current committed rate can be increased based on these values ​​to obtain an adjusted committed rate. To avoid over-increasing the committed rate during the recovery process, in this embodiment, a reference rate is used as an upper limit constraint when calculating the adjusted committed rate; that is, the reference rate is the target value for committed rate recovery.

[0083] For example, for a type of traffic, the current committed rate in its token bucket can be added to the corresponding rate recovery value to obtain a temporary committed rate. This temporary committed rate is then compared with the reference rate for that type of traffic: if the temporary committed rate is greater than the reference rate, the adjusted committed rate becomes the reference rate; conversely, if the temporary committed rate is less than or equal to the reference rate, the adjusted committed rate becomes the temporary committed rate. This adjustment method allows various types of traffic to smoothly recover to the baseline bandwidth configuration during the bandwidth recovery phase, thereby avoiding sudden rate changes and improving system stability.

[0084] By following the steps above, video devices can smoothly restore restricted traffic to the baseline rate when bandwidth assessment indicators decrease and the promised rate has not yet recovered to the reference rate, thereby achieving a stable transition during the bandwidth recovery phase.

[0085] In some embodiments, when the target parameter adjustment strategy is a second parameter adjustment strategy, step 104 may specifically include: Step 1045: For each type of traffic, check whether the amount of data in the data buffer corresponding to the traffic exceeds the preset buffer data amount threshold.

[0086] When the promised rates for various types of traffic have recovered to the reference rates and bandwidth remains sufficient, video devices can enable a second parameter adjustment strategy to adaptively adjust the rates for various types of traffic when bandwidth is sufficient. In this embodiment, the need to increase the promised rate is determined by detecting the amount of data in the data buffer corresponding to each type of traffic.

[0087] The data buffer is used to cache data packets to be sent. Different types of traffic can correspond to independent data buffers, or separate queues can be set up for different types of traffic in a shared buffer space. When traffic generates data but has not yet been sent, the data will be temporarily stored in the data buffer corresponding to that type of traffic. Based on this, the amount of data in the data buffer can be used to represent the scale of the currently backlogged data in the data buffer, which can be characterized by buffer queue length, number of data bytes, or number of data packets.

[0088] Video devices can pre-set buffer data volume thresholds to determine whether the current committed rate for a certain type of traffic is sufficient to meet its transmission requirements. When the amount of data in the data buffer exceeds this threshold, it indicates that the current committed rate is too low, resulting in insufficient transmission capacity and data backlog. By detecting whether the amount of data in the data buffer corresponding to various types of traffic exceeds this buffer data volume threshold, traffic that needs an increased committed rate can be identified.

[0089] It should be noted that video devices can set separate buffer data thresholds for each type of traffic; or, a uniform buffer data threshold can be set for each type of traffic. This application embodiment does not limit this.

[0090] Step 1046: If the data volume exceeds the buffer data volume threshold, increase the committed rate of the token bucket corresponding to the traffic.

[0091] When the amount of data in the data buffer corresponding to a certain type of traffic exceeds the buffer data size threshold, it indicates that the current committed rate of the token bucket corresponding to that type of traffic is insufficient to send the data in a timely manner. In this case, the committed rate of the token bucket is increased. After increasing the committed rate, the token bucket generates tokens at a higher rate, thereby allowing that type of traffic to send data at a higher rate and reducing data backlog.

[0092] In one example, the committed rate can be gradually increased for traffic that meets the above conditions within each preset detection period, so that the committed rate gradually increases with the degree of data backlog; when the data buffer backlog decreases, the committed rate can be maintained or adjusted by subsequent strategies, so that the committed rate can be dynamically increased according to the actual sending demand.

[0093] Through the above steps, under the second parameter adjustment strategy, the transmission rate of various types of traffic can be adaptively increased according to actual needs when bandwidth is sufficient, thereby improving bandwidth utilization and reducing data queuing delay.

[0094] In some embodiments, when the target parameter adjustment strategy is a second parameter adjustment strategy, step 104 may specifically include: Step 1047: For each type of traffic, calculate the cumulative duration during which the actual transmission rate of the traffic is lower than the preset low rate threshold within a preset period.

[0095] Under the second parameter adjustment strategy, if the promised rate of a certain type of traffic is increased, but the actual transmission rate of that traffic remains low for a period of time, it indicates that the traffic is not fully utilizing the currently allocated bandwidth resources. To avoid bandwidth resources being occupied for extended periods without being effectively utilized, this embodiment of the application determines whether the promised rate needs to be reduced by statistically analyzing the actual transmission rate.

[0096] The period duration is used to define the statistical time window, allowing video devices to monitor traffic transmission within each period. Based on this, the actual transmission rate is the true output rate of a traffic type within the statistical time window, calculated by counting the number of bytes sent and the time interval. Furthermore, video devices can preset a low-rate threshold; if the actual transmission rate of a certain traffic type falls below this threshold, it indicates that the promised rate for that traffic type is relatively too high.

[0097] It should be noted that video devices can set separate low-rate thresholds for each type of traffic; or, a uniform low-rate threshold can be set for each type of traffic. This application does not limit this.

[0098] During the statistical analysis within a given period, when the actual transmission rate of a certain type of traffic falls below its low-rate threshold, video devices can record the corresponding time slice length and accumulate this time slice length within that period to obtain the cumulative duration. This cumulative duration reflects the duration of low-rate transmission for that type of traffic within the given period.

[0099] Step 1048: If the cumulative duration exceeds the preset duration, reduce the committed rate of the token bucket corresponding to the traffic, and the reduced committed rate shall not be lower than the reference rate of the token bucket.

[0100] When the cumulative duration of a certain type of traffic, as calculated in step 1047, exceeds a preset duration, it indicates that this type of traffic has not fully utilized the allocated bandwidth for a considerable period within the cycle. Therefore, the committed rate of its corresponding token bucket is reduced. The preset duration can be calculated using the cycle duration and a duration coefficient. For example, multiplying the cycle duration by the duration coefficient yields the preset duration. The duration coefficient is a positive number not greater than 1. By setting the duration coefficient, the sensitivity of the second parameter adjustment strategy in triggering rate reduction can be flexibly adjusted.

[0101] To avoid reducing the committed rate to an excessively low level when lowering the committed rate, this embodiment of the application also sets a reference rate as a lower limit for the committed rate. As described above, the reference rate is the baseline committed rate configured for each token bucket based on a shaping strategy. It is typically a certain multiple (e.g., 1.2 times) of the encoder bitrate of the corresponding traffic, used to represent the basic bandwidth requirements of various types of traffic. When video devices reduce the committed rate of a token bucket through the second parameter adjustment strategy, the minimum rate will not fall below this reference rate.

[0102] Through the above steps, under the second parameter adjustment strategy, bandwidth resources can be released and redistributed from low-utilization traffic, thereby improving the overall bandwidth utilization efficiency of the system.

[0103] In some examples, different types of video traffic exhibit different bitrate variation characteristics, thus requiring different adjustment methods when adjusting the committed rate based on the second parameter adjustment strategy. Based on bitrate variation characteristics, variable bitrate (VBR) traffic and constant bitrate (CBR) traffic can be distinguished.

[0104] Variable bitrate traffic refers to traffic whose encoding bitrate fluctuates dynamically with changes in the scene. For example, video streams using dynamic encoding may experience a sudden increase in bitrate during complex or motion-based scenarios. Because variable bitrate traffic has sudden bandwidth demands, if the promised rate is increased only slightly when data buffer backlog is detected, the backlogged data may not be released in time.

[0105] Fixed bitrate traffic refers to traffic whose encoding bitrate remains relatively stable, such as video streams encoded with a fixed bitrate, where bandwidth requirements change little. For fixed bitrate traffic, even if buffer congestion occurs, it is usually not necessary to significantly increase the committed rate; therefore, a gradual increase in small increments is more reasonable.

[0106] Therefore, video devices employ slightly different methods when adjusting the committed rate based on the second parameter adjustment strategy for variable bitrate and fixed bitrate traffic. In some examples, the rate adjustment methods for variable bitrate and fixed bitrate traffic are shown in Table 1 below:

[0107] Table 1 Based on Table 1 above, when the bitrate type of the traffic is variable bitrate, that is, variable bitrate traffic: When increasing the committed rate based on the second parameter adjustment strategy, if the traffic currently meets the preset initial speed-up conditions, the committed rate of the corresponding token bucket is increased by a preset first increment. The initial speed-up conditions may include, but are not limited to: the current committed rate equals the reference rate, no speed-up operation based on the second parameter adjustment strategy has been performed, or no speed-up has occurred within a preset time window. When variable bitrate traffic meets these initial speed-up conditions, it indicates that the traffic has just entered the bandwidth adaptive adjustment phase. At this time, the committed rate of its corresponding token bucket can be increased by a larger first increment to quickly respond to burst bitrate demands. As shown in Table 1 above, the committed rate of the token bucket can be directly set to 2 × the reference bitrate.

[0108] When increasing the committed rate based on the second parameter adjustment strategy, if the traffic does not currently meet the preset initial speed-up conditions, it indicates that if there is still data backlog after the initial speed-up, the committed rate needs further adjustment. However, at this time, a large increase is no longer needed; instead, a small, gradual increase is adopted to avoid the committed rate growing too quickly and affecting the bandwidth allocation of other traffic. In this case, the committed rate of its corresponding token bucket can be increased based on a small second increase. As shown in Table 1 above, this second increase can be a × reference bitrate, where a is a preset increase coefficient, and its value range is (0,1).

[0109] When reducing the committed rate based on the second parameter adjustment strategy, video devices can first calculate the low rate average. This low rate average refers to the average of the actual transmission rates below a preset low rate threshold within a preset period, as mentioned in step 1047. For example, within the period from T0 to TN, if a type of traffic has an actual transmission rate below the low rate threshold within the period from T0 to T2, and also within the period from T3 to TN, and the sum of the periods from T0 to T2 and from T3 to TN (i.e., the cumulative duration) exceeds the preset duration mentioned above, then the video device can average the actual transmission rates of this type of traffic within the periods from T0 to T2 and T3 to TN. The result is the low rate average of this type of traffic within the period from T0 to TN. Based on this, the video device can use the calculated result of the low rate average + a × reference bitrate as a candidate committed rate and compare this candidate committed rate with the reference rate of this type of traffic. It is understandable that, since the reference bitrate is the second parameter adjustment strategy that lowers the lower limit of the committed rate, video devices can directly reduce the committed rate of this type of traffic to the larger value between the alternative committed rate and the reference rate; that is, when the alternative committed rate is lower than the reference rate, the committed rate is reduced to the reference rate; otherwise, the committed rate is reduced to the alternative committed rate.

[0110] Based on Table 1 above, when the bitrate type of the traffic is fixed bitrate, that is, when it is fixed bitrate traffic: When increasing the committed rate based on the second parameter adjustment strategy, since the bandwidth demand changes relatively little, a small, gradual increase can be adopted to avoid the committed rate growing too quickly and affecting the bandwidth allocation of other traffic. In this case, the committed rate of the corresponding token bucket can be increased based on a small second increase. As shown in Table 1 above, this second increase can be a × reference bitrate, where a is a preset increase coefficient, and its value ranges from (0,1).

[0111] When reducing the committed rate based on the second parameter adjustment strategy, the method used is the same as that used for variable bit rate traffic, as described above and in Table 1 above, and will not be repeated here.

[0112] As can be seen from the above, this application embodiment achieves differentiated management of multiple traffic types by classifying the traffic within video devices and allocating corresponding token buckets to each type of traffic. Furthermore, this application embodiment further determines a target adjustment strategy based on the device bandwidth status within two strategies with different adjustment constraints and dynamically adjusts the shaping parameters of each type of traffic. This allows for the shaping and transmission of each type of traffic based on the adjusted shaping parameters, adapting to the dynamic changes in wireless network bandwidth. Based on this application embodiment, the adaptability of traffic scheduling can be effectively improved, transmission performance under dynamic bandwidth can be enhanced, and the stability of video service transmission can be guaranteed.

[0113] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0114] Corresponding to the flow shaping method provided above, this application also provides a flow shaping apparatus. Please refer to... Figure 3 The flow shaping device 3 in this embodiment includes: The classification module 301 is used to classify the traffic within video devices based on preset traffic characteristics; The setting module 302 is used to allocate corresponding token buckets to various types of traffic and set the shaping parameters of each token bucket based on the preset shaping strategy. The determining module 303 is used to determine the target parameter adjustment strategy based on the bandwidth status of the video device, from the preset first parameter adjustment strategy and the second parameter adjustment strategy, wherein the first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter; The adjustment module 304 is used to adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy; The transmission module 305 is used to shape and send the corresponding types of traffic based on the latest shaping parameters of each token bucket.

[0115] In some embodiments, the shaping parameter to be adjusted includes the committed rate; the determining module 303 includes: The first calculation unit is used to calculate the bandwidth evaluation index within video devices. The bandwidth evaluation index is used to indicate the bandwidth margin of video devices. The first determining unit is used to determine the first parameter adjustment strategy as the target parameter adjustment strategy when the bandwidth evaluation index is higher than the preset index threshold. The second determining unit is used to determine the first parameter adjustment strategy as the target parameter adjustment strategy when the bandwidth evaluation index is lower than or equal to the index threshold and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate. The reference rate is the baseline committed rate configured by each token bucket through a shaping strategy. The third determining unit is used to determine the second parameter adjustment strategy as the target parameter adjustment strategy when the bandwidth evaluation index is lower than or equal to the index threshold and the committed rate adjusted based on the first parameter adjustment strategy has recovered to the reference rate.

[0116] In some embodiments, when the target parameter adjustment strategy is a first parameter adjustment strategy and the bandwidth evaluation index is higher than the index threshold, the adjustment module 304 includes: The second calculation unit is used to calculate the rate penalty value of each token bucket based on the priority of various types of traffic, the preset penalty coefficient, and the current committed rate of each token bucket. The first adjustment unit is used to reduce the committed rate of each token bucket according to the rate penalty value of each token bucket.

[0117] In some embodiments, when the target parameter adjustment strategy is a first parameter adjustment strategy, and the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, the adjustment module 304 includes: The third calculation unit is used to calculate the rate recovery value of each token bucket based on the priority of various types of traffic, the preset recovery coefficient, and the current committed rate of each token bucket. The second adjustment unit is used to increase the committed rate of each token bucket according to the rate recovery value and reference rate of each token bucket.

[0118] In some embodiments, when the target parameter adjustment strategy is a second parameter adjustment strategy, the adjustment module 304 includes: The detection unit is used to detect whether the amount of data in the data buffer corresponding to each type of traffic exceeds a preset buffer data amount threshold. The third adjustment unit is used to increase the committed rate of the token bucket corresponding to the traffic when the data volume exceeds the buffer data volume threshold.

[0119] In some embodiments, the third adjustment unit includes: The first speed-up subunit is used to increase the promised rate of the corresponding token bucket based on a preset first magnitude if the traffic is variable bitrate traffic and the traffic currently meets the preset first speed-up conditions. The second speed-up subunit is used to increase the promised rate of the corresponding token bucket based on a preset second magnitude when the traffic is fixed bit rate traffic or variable bit rate traffic and the current conditions for the first speed-up are not met. The first magnitude is greater than the second magnitude.

[0120] In some embodiments, when the target parameter adjustment strategy is a second parameter adjustment strategy, the adjustment module 304 includes: The statistics unit is used to count the cumulative duration during which the actual transmission rate of each type of traffic is lower than a preset low rate threshold within a preset period. The fourth adjustment unit is used to reduce the committed rate of the token bucket corresponding to the traffic when the cumulative duration exceeds the preset duration, and the reduced committed rate is not lower than the reference rate of the token bucket. The preset duration is determined based on the period duration and the preset duration coefficient.

[0121] As can be seen from the above, this application embodiment achieves differentiated management of multiple traffic types by classifying the traffic within video devices and allocating corresponding token buckets to each type of traffic. Furthermore, this application embodiment further determines a target adjustment strategy based on the device bandwidth status within two strategies with different adjustment constraints and dynamically adjusts the shaping parameters of each type of traffic. This allows for the shaping and transmission of each type of traffic based on the adjusted shaping parameters, adapting to the dynamic changes in wireless network bandwidth. Based on this application embodiment, the adaptability of traffic scheduling can be effectively improved, transmission performance under dynamic bandwidth can be enhanced, and the stability of video service transmission can be guaranteed.

[0122] Corresponding to the traffic shaping method provided above, this application also provides a video device. Please refer to... Figure 4 The video device 4 in this embodiment includes: a memory 401, and one or more processors 402. Figure 4 (Only one is shown in the image) and a computer program stored in memory 401 and executable on the processor. Specifically, the processor 402 performs the following steps by running the aforementioned computer program stored in memory 401: Traffic within video devices is classified based on preset traffic characteristics; Allocate corresponding token buckets to various types of traffic, and set the shaping parameters of each token bucket based on the preset shaping strategy; Based on the bandwidth status of video devices, a target parameter adjustment strategy is determined from the preset first parameter adjustment strategy and second parameter adjustment strategy. The first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter. Adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy; Based on the latest shaping parameters of each token bucket, the corresponding types of traffic are shaped and sent.

[0123] Assuming the above is the first possible implementation, in the second possible implementation based on the first possible implementation, the shaping parameter to be adjusted includes the committed rate; based on the bandwidth status of the video device, a target parameter adjustment strategy is determined from the preset first parameter adjustment strategy and second parameter adjustment strategy, including: Calculate the bandwidth assessment metrics within video devices. These metrics are used to indicate the bandwidth margin of video devices. If the bandwidth evaluation index is higher than the preset index threshold, the first parameter adjustment strategy will be determined as the target parameter adjustment strategy. If the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, the first parameter adjustment strategy will be determined as the target parameter adjustment strategy, where the reference rate is the baseline committed rate configured by each token bucket through a shaping strategy. If the bandwidth assessment index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has recovered to the reference rate, the second parameter adjustment strategy will be determined as the target parameter adjustment strategy.

[0124] In a third possible implementation based on the second possible implementation described above, when the target parameter adjustment strategy is the first parameter adjustment strategy and the bandwidth evaluation index is higher than the index threshold, the shaping parameters of each token bucket are adjusted according to the target parameter adjustment strategy, including: Based on the priority of various types of traffic, the preset penalty coefficient, and the current committed rate of each token bucket, the rate penalty value of each token bucket is calculated respectively. Based on the rate penalty value of each token bucket, the commitment rate of each token bucket is reduced respectively.

[0125] In the fourth possible implementation provided based on the second possible implementation described above, when the target parameter adjustment strategy is the first parameter adjustment strategy, and the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, the shaping parameters of each token bucket are adjusted according to the target parameter adjustment strategy, including: Based on the priority of various traffic types, the preset recovery coefficient, and the current committed rate of each token bucket, the rate recovery value of each token bucket is calculated respectively. Based on the rate recovery value and reference rate of each token bucket, the committed rate of each token bucket is increased respectively.

[0126] In the fifth possible implementation provided based on the second possible implementation described above, when the target parameter adjustment strategy is the second parameter adjustment strategy, the shaping parameters of each token bucket are adjusted according to the target parameter adjustment strategy, including: For each type of traffic, check whether the amount of data in the corresponding data buffer exceeds the preset buffer data amount threshold; If the amount of data exceeds the buffer data volume threshold, increase the committed rate of the token bucket corresponding to the traffic.

[0127] In the sixth possible implementation provided based on the fifth possible implementation described above, when the target parameter adjustment strategy is the second parameter adjustment strategy, the shaping parameters of each token bucket are adjusted according to the target parameter adjustment strategy, including: increasing the committed rate of the token bucket corresponding to the traffic, including: In the case of variable bitrate traffic, if the traffic currently meets the preset first speed-up conditions, the promised rate of the corresponding token bucket will be increased based on the preset first magnitude. If the traffic is fixed bitrate traffic, or if the traffic is variable bitrate traffic and the conditions for the first speed-up are not met, the promised rate of the corresponding token bucket will be increased based on a preset second magnitude, wherein the first magnitude is greater than the second magnitude.

[0128] In the seventh possible implementation provided based on the second possible implementation described above, when the target parameter adjustment strategy is the second parameter adjustment strategy, the shaping parameters of each token bucket are adjusted according to the target parameter adjustment strategy, including: For each type of traffic, the cumulative duration during which the actual transmission rate of the traffic is lower than a preset low rate threshold is counted within a preset period. If the cumulative duration exceeds the preset duration, the committed rate of the token bucket corresponding to the traffic is reduced, and the reduced committed rate is not lower than the reference rate of the token bucket. The preset duration is determined based on the period duration and the preset duration coefficient.

[0129] It should be understood that, in the embodiments of this application, the processor 402 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0130] Memory 401 may include read-only memory and random access memory, and provides instructions and data to processor 402. Some or all of memory 401 may also include non-volatile random access memory. For example, memory 401 may also store device type information.

[0131] As can be seen from the above, this application embodiment achieves differentiated management of multiple traffic types by classifying the traffic within video devices and allocating corresponding token buckets to each type of traffic. Furthermore, this application embodiment further determines a target adjustment strategy based on the device bandwidth status within two strategies with different adjustment constraints and dynamically adjusts the shaping parameters of each type of traffic. This allows for the shaping and transmission of each type of traffic based on the adjusted shaping parameters, adapting to the dynamic changes in wireless network bandwidth. Based on this application embodiment, the adaptability of traffic scheduling can be effectively improved, transmission performance under dynamic bandwidth can be enhanced, and the stability of video service transmission can be guaranteed.

[0132] This application also provides a computer program product that, when run on a video device, enables the video device to implement the steps described in the various method embodiments above.

[0133] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0134] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of external device software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0136] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0137] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing associated hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer-readable storage device, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc. It should be noted that the contents of the aforementioned computer-readable storage media may be appropriately added to or subtracted from the contents according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable storage media may not include electrical carrier signals and telecommunication signals.

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

Claims

1. A flow shaping method, characterized in that, Applied to video devices, including: The traffic within the video devices is classified based on preset traffic characteristics; Allocate corresponding token buckets to each type of traffic, and set the shaping parameters of each token bucket based on a preset shaping strategy; Based on the bandwidth status of the video device, a target parameter adjustment strategy is determined from the preset first parameter adjustment strategy and second parameter adjustment strategy, wherein the first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter; Adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy; Based on the latest shaping parameters of each token bucket, the corresponding types of traffic are shaped and sent.

2. The flow shaping method as described in claim 1, characterized in that, The shaping parameters to be adjusted include the committed rate; determining the target parameter adjustment strategy based on the bandwidth status of the video device, among preset first parameter adjustment strategies and second parameter adjustment strategies, includes: Calculate the bandwidth evaluation index within the video device, the bandwidth evaluation index being used to indicate the bandwidth margin of the video device; If the bandwidth evaluation index is higher than the preset index threshold, the first parameter adjustment strategy is determined as the target parameter adjustment strategy. If the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, the first parameter adjustment strategy is determined as the target parameter adjustment strategy, wherein the reference rate is the baseline committed rate configured for each token bucket by the shaping strategy. If the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has recovered to the reference rate, the second parameter adjustment strategy will be determined as the target parameter adjustment strategy.

3. The flow shaping method as described in claim 2, characterized in that, When the target parameter adjustment strategy is the first parameter adjustment strategy, and the bandwidth evaluation index is higher than the index threshold, adjusting the shaping parameters of each token bucket according to the target parameter adjustment strategy includes: Based on the priority of each type of traffic, the preset penalty coefficient, and the current committed rate of each token bucket, the rate penalty value of each token bucket is calculated respectively. The committed rate of each token bucket is reduced according to the rate penalty value of each token bucket.

4. The flow shaping method as described in claim 2, characterized in that, When the target parameter adjustment strategy is the first parameter adjustment strategy, and the bandwidth evaluation index is lower than or equal to the index threshold, and the committed rate adjusted based on the first parameter adjustment strategy has not recovered to the reference rate, adjusting the shaping parameters of each token bucket according to the target parameter adjustment strategy includes: Based on the priority of each type of traffic, the preset recovery coefficient, and the current committed rate of each token bucket, the rate recovery value of each token bucket is calculated respectively. Based on the rate recovery value of each token bucket and the reference rate, the committed rate of each token bucket is increased respectively.

5. The flow shaping method as described in claim 2, characterized in that, When the target parameter adjustment strategy is the second parameter adjustment strategy, adjusting the shaping parameters of each token bucket according to the target parameter adjustment strategy includes: For each type of traffic, detect whether the amount of data in the data buffer corresponding to the traffic exceeds a preset buffer data amount threshold; If the amount of data exceeds the buffer data threshold, increase the committed rate of the token bucket corresponding to the traffic.

6. The flow shaping method as described in claim 5, characterized in that, The increase in the committed rate of the token bucket corresponding to the traffic includes: In the case of variable bitrate traffic, if the traffic currently meets the preset first speed-up conditions, the promised rate of the corresponding token bucket is increased based on the preset first magnitude. If the traffic is a fixed bitrate traffic, or if the traffic is a variable bitrate traffic and the initial speed-up condition is not currently met, then the promised rate of the corresponding token bucket is increased based on a preset second magnitude, wherein the first magnitude is greater than the second magnitude.

7. The flow shaping method as described in claim 2, characterized in that, When the target parameter adjustment strategy is the second parameter adjustment strategy, adjusting the shaping parameters of each token bucket according to the target parameter adjustment strategy includes: For each type of traffic, the cumulative duration during which the actual transmission rate of the traffic is lower than a preset low rate threshold is counted within a preset period. If the cumulative duration exceeds a preset duration, the committed rate of the token bucket corresponding to the traffic is reduced, and the reduced committed rate is not lower than the reference rate of the token bucket, wherein the preset duration is determined based on the period duration and a preset duration coefficient.

8. A flow shaping device, characterized in that, Applied to video devices, including: The classification module is used to classify the traffic within the video devices based on preset traffic characteristics; The setting module is used to allocate corresponding token buckets for various types of traffic and set the shaping parameters of each token bucket based on a preset shaping strategy. The determining module is used to determine a target parameter adjustment strategy based on the bandwidth status of the video device, among a preset first parameter adjustment strategy and a second parameter adjustment strategy, wherein the first parameter adjustment strategy and the second parameter adjustment strategy have different adjustment constraints on the shaping parameter; An adjustment module is used to adjust the shaping parameters of each token bucket according to the target parameter adjustment strategy; The transmission module is used to shape and send the corresponding types of traffic based on the latest shaping parameters of each token bucket.

9. A video device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by one or more processors, implements the method as described in any one of claims 1 to 7.

Images