A service experience perception elastic bandwidth arrangement method for high-latency satellite link

Abstract

The application discloses a service experience perception elastic bandwidth arrangement method for a high-latency satellite link. The method comprises the following steps: through a ship-level bandwidth quota mechanism, resource fair distribution in the ship dimension can be realized in a multi-ship concurrent access scene; through congestion scoring and grade determination based on multi-dimensional indexes, short-time jitter and continuous congestion can be accurately distinguished, and false adjustment can be avoided; through a differentiated re-arrangement mechanism, bandwidth recovery and elastic shrinkage actions of different intensities are executed according to the congestion grade; through an anti-jitter gradual recovery mechanism, secondary congestion caused by the concentrated release of low-priority services after link recovery is avoided. The application can improve the availability of key services, reduce the long-term occupation of link resources by low real-time services, and guarantee the normal service communication experience of a ship terminal in a satellite link environment with high latency, limited bandwidth and obvious link state fluctuations.

Description

Technical Field

[0001] This application relates to the fields of satellite communication technology and network resource orchestration technology, and in particular to a service experience-aware elastic bandwidth orchestration method for high-latency satellite links. Background Technology

[0002] Satellite links are a crucial communication method for internet access on ships at sea, characterized by high latency, limited bandwidth, significant link fluctuations, and high transmission costs. In ship internet access scenarios, different services have significantly different bandwidth and latency requirements. Voice communication, instant messaging, and remote maintenance are real-time interactive services, highly sensitive to latency and packet loss; web page access, business system access, and map queries are response-sensitive services; short videos, live streaming, and online video are throughput-sensitive services, consuming a large amount of bandwidth; file downloads, system updates, and background synchronization are deferred services with lower real-time requirements.

[0003] Traditional QoS mechanisms are mostly designed for terrestrial networks, typically employing static priorities, fixed rate limits, or simple queue scheduling. In high-latency satellite links, simply setting priorities or fixed rate limits based on service type can easily lead to problems such as insufficient protection of critical services, excessive consumption of link resources by low-real-time services, and secondary congestion caused by concentrated release of services after link recovery. Furthermore, shipboard internet services often involve concurrent access from multiple ships and terminals. If rate limiting is only applied to a single terminal or service, it cannot effectively address resource fairness among multiple ships and ensure a good service experience within the ship.

[0004] Therefore, there is an urgent need for a service experience-aware elastic bandwidth orchestration method for high-latency satellite links. This method uses the available bandwidth of the satellite link as an orchestratable resource and combines ship-level quotas, service experience levels, bandwidth pool division, congestion trend re-orchestration, and anti-jitter progressive recovery mechanisms to perform layered, pooled, and phased bandwidth resource orchestration for normal service traffic. Summary of the Invention

[0005] This application provides a service experience-aware elastic bandwidth orchestration method for high-latency satellite links, the technical solution of which is as follows:

[0006] Collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota;

[0007] The normal business traffic on the ship is divided into different business experience levels according to experience sensitivity, and the available bandwidth of the ship is divided into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool.

[0008] A congestion score is generated based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and the congestion level is determined based on the congestion score.

[0009] When congestion is detected, the three types of bandwidth pools are reorganized in a differentiated manner according to the congestion level. After the link enters the recovery observation state, the ratio of the elastic shared bandwidth pool and the reclaimable bandwidth pool is gradually restored according to the preset step size.

[0010] Record key data during each congestion assessment and reordering process, and periodically update the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

[0011] Secondly, a service experience-aware elastic bandwidth orchestration device for high-latency satellite links is provided, the device comprising:

[0012] The quota module is used to collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota.

[0013] The partitioning module is used to divide the normal business traffic on the ship into different business experience levels according to the experience sensitivity, and to divide the available bandwidth of the ship into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool.

[0014] The judgment module is used to generate a congestion score based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and to determine the congestion level based on the congestion score.

[0015] The recovery module is used to perform differentiated reordering of the three types of bandwidth pools according to the congestion level when a congestion state is detected, and to gradually restore the ratio of elastic shared bandwidth pool and reclaimable bandwidth pool according to a preset step size after the link enters the recovery observation state.

[0016] The update module records key data during each congestion assessment and reordering process, and periodically updates the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

[0017] Thirdly, an electronic device is provided, including a device processor and a memory;

[0018] The device processor is connected to the memory;

[0019] The memory is used to store executable program code;

[0020] The device processor runs a program corresponding to the executable program code stored in the memory to perform the steps of the method provided as in the first aspect or any possible implementation thereof.

[0021] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, the computer-readable storage medium storing instructions that, when executed on a computer or device processor, cause the computer or device processor to perform the method provided as in the first aspect or any possible implementation thereof.

[0022] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following:

[0023] In one or more embodiments of this application, a ship-level bandwidth quota mechanism enables fair resource allocation at the ship level in scenarios with concurrent access from multiple ships. Through service experience level identification and the division of three types of bandwidth pools, real-time interactive, response-sensitive, throughput-sensitive, and delay-sensitive services are differentiated and orchestrated, improving overall link utilization efficiency while ensuring the experience of critical services. Congestion scoring and level determination based on multi-dimensional indicators accurately distinguish between short-term jitter and continuous congestion, avoiding erroneous adjustments. A differentiated re-orchestration mechanism executes bandwidth reclamation and elastic contraction actions of varying intensities according to congestion levels. An anti-jitter progressive recovery mechanism prevents secondary congestion caused by the concentrated release of low-priority services after link recovery. This invention can improve the availability of critical services, reduce the long-term occupation of link resources by low-real-time services, and ensure normal communication experience on the ship side in satellite link environments with high latency, limited bandwidth, and significant link state fluctuations. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0025] Figure 1 A flowchart illustrating a service experience-aware elastic bandwidth orchestration method for high-latency satellite links provided in this application embodiment;

[0026] Figure 2 This application provides a schematic diagram of the structure of a service experience-aware elastic bandwidth orchestration device for high-latency satellite links.

[0027] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0029] The terms "first," "second," "third," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0030] The following description provides examples and does not limit the scope, applicability, or examples set forth in the claims. Changes may be made to the function and arrangement of the described elements without departing from the scope of this application. Various processes or components may be appropriately omitted, substituted, or added to the examples. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Furthermore, features described with respect to some examples may be combined into other examples.

[0031] Please see Figure 1 , Figure 1 The diagram shows an overall flowchart of a service experience-aware elastic bandwidth orchestration method for high-latency satellite links provided in an embodiment of this application.

[0032] like Figure 1 As shown, this service experience-aware elastic bandwidth orchestration method for high-latency satellite links may include at least the following steps:

[0033] Step 101: Collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the available ship-level bandwidth based on the corresponding link baseline parameters and ship-level quota.

[0034] In this embodiment, the core purpose of this step is to provide accurate basic data input and resource boundary constraints for subsequent service experience level classification, bandwidth pool construction, and congestion judgment. Satellite links differ from terrestrial links; the RTT baseline, jitter characteristics, and bandwidth fluctuation patterns of different types of satellite links (high-orbit, medium-orbit, low-orbit, and hybrid links) vary significantly. If a uniform congestion judgment threshold is used, it is easy to misjudge normal handover jitter of low-orbit links as congestion, or ignore the slow deterioration of high-orbit links. Furthermore, in scenarios with multiple ships accessing concurrently, it is necessary to first determine the available bandwidth boundary for each ship to avoid excessive resource consumption by a single ship. Therefore, after starting the orchestration service, the system first needs to complete three basic tasks: link status awareness, link type matching, and ship-level resource quota allocation.

[0035] In one implementation, satellite link status data can be collected through a link capacity monitoring module. This satellite link status data includes, but is not limited to, available satellite link bandwidth, link RTT, RTT change rate, packet loss rate, jitter, current bandwidth utilization, utilization of various bandwidth pools, and the response status of critical services. The system collects this data at a preset sampling period. When the link status is stable, a longer sampling period is maintained; when RTT continuously increases, packet loss rate increases, or high-priority service response deteriorates, the sampling period is shortened to improve orchestration response speed.

[0036] In one possible implementation, identifying the current satellite link type requires querying a satellite link type and baseline parameter database. The satellite link types include, but are not limited to, high-Earth orbit (HEO) satellite links, medium-Earth orbit (MEO) satellite links, low-Earth orbit (LEO) satellite links, multi-satellite hybrid links, and hybrid access links formed by combining satellite links with near-shore cellular links. The baseline parameter database stores historical average RTT, normal RTT fluctuation range, normal packet loss rate range, normal jitter range, available bandwidth baseline, bandwidth occupancy warning threshold, bandwidth occupancy congestion threshold, high-priority service response threshold, and recovery determination threshold for different link types. By matching the baseline parameters corresponding to the current link type, the system can use differentiated thresholds in subsequent congestion assessments, avoiding the application of a uniform standard to all link types.

[0037] In one implementation, the available bandwidth at the ship level is determined based on ship-level quotas, which can be achieved through a ship-level bandwidth quota module. The system uses ships as the primary scheduling object and determines the available bandwidth at the ship level based on the ship's package level, the number of online terminals, historical bandwidth usage, and the status of critical services. Specifically, this includes a basic quota, a flexible quota, and a maximum available limit. The basic quota ensures the ship's basic communication capabilities, the flexible quota temporarily expands available bandwidth when the link is idle, and the maximum available limit restricts a single ship from occupying excessive resources for extended periods. Through the ship-level bandwidth quota mechanism, the system can establish clear resource boundaries in multi-ship concurrent scenarios, providing constraints for the independent bandwidth pool allocation for each ship in step 103.

[0038] Optionally, a two-tiered orchestration structure of "ship-level orchestration—in-ship service-level orchestration" can be adopted. The first tier determines the resource boundaries between multiple ships based on each ship's basic quota, flexible quota, and maximum available limit. The second tier then constructs a basic guaranteed bandwidth pool, a flexible shared bandwidth pool, and a reclaimable bandwidth pool within each ship's available bandwidth range, according to service experience levels. This avoids long-term occupation by a single ship due to scheduling based solely on network-wide service priorities, and also avoids failing to guarantee fairness among multiple ships by limiting speed only within a single ship.

[0039] Step 103: Divide the normal service traffic on the ship into different service experience levels according to experience sensitivity, and divide the available bandwidth of the ship into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool.

[0040] In this embodiment, this step follows the ship-grade available bandwidth determined in step 101, aiming to classify and pool the bandwidth resources of normal business traffic within the ship based on experience sensitivity. Given the scarcity of satellite link resources, different services have significantly different impacts on user experience. If all services are placed in the same queue to compete for bandwidth, real-time interactive services may be squeezed out by download services, leading to voice interruptions or remote maintenance disruptions. Therefore, this step stratifies services according to experience sensitivity and constructs three differentiated bandwidth pools within the ship-grade available bandwidth, providing a structural foundation for subsequent refined orchestration.

[0041] In one possible implementation, normal business traffic on the ship is categorized into different service experience levels based on experience sensitivity. Normal business traffic refers to traffic that has not been flagged as abnormal attack behavior by security detection systems, access control policies, or operational policies. This method does not involve the identification and handling of abnormal attack behavior. Specific categorization may include: classifying services into real-time interactive services, response-sensitive services, throughput-sensitive services, and delayable services. Real-time interactive services include voice communication, instant messaging, and remote maintenance; this type of service typically has low traffic but is sensitive to latency, packet loss, and jitter. Response-sensitive services include web page access, business system access, and map queries; this type of service requires fast response times. Throughput-sensitive services include short videos, live streaming, and online video; this type of service has high bandwidth requirements but can be managed through elastic allocation and experience degradation control. Delayable services include file downloads, system updates, and background synchronization; this type of service has lower real-time requirements and can be delayed or compressed due to link congestion.

[0042] In one possible implementation, the available ship-grade bandwidth is divided into three types of bandwidth pools, which may include: a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool. The basic guaranteed bandwidth pool is used to guarantee real-time interactive services and critical services; this bandwidth is prioritized for reservation during link congestion and does not participate in preemption for ordinary entertainment services. The elastic shared bandwidth pool is used to allocate response-sensitive and throughput-sensitive services; this bandwidth can be expanded when the link is idle and contracted when the link is congested. The reclaimable bandwidth pool is used to accommodate delayed services; this bandwidth can be fully utilized when the link is idle and is prioritized for reclamation when the link is congested or shows signs of congestion. Through the above service classification and bandwidth pool division, the system transforms limited satellite bandwidth resources into a three-layer structure that can be dynamically adjusted on demand, providing clear operational objects for the congestion judgment in step 105 and the rescheduling execution in step 107.

[0043] Optionally, minimum guaranteed bandwidth can be set separately for real-time interactive services and critical services. When links are congested, the system prioritizes reserving the minimum guaranteed bandwidth required for existing voice, instant messaging, remote maintenance, and critical service connections, and prioritizes reclaiming download, system update, and background synchronization resources from the reclaimable bandwidth pool; if this is still insufficient, the elastic shared bandwidth pool will be shrunk, without prioritizing the compression of existing connections for real-time interactive services. For throughput-sensitive services, maximum available bandwidth limits, single-terminal bandwidth limits, concurrency limits, and non-real-time loading delays can be implemented sequentially according to congestion level.

[0044] Step 105: Generate a congestion score based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and determine the congestion level based on the congestion score.

[0045] In this embodiment, this step follows the bandwidth pool structure established in step 103, aiming to accurately determine whether the current link is congested and the severity of the congestion through the quantitative synthesis of multi-dimensional indicators. In high-latency satellite links, a single indicator (such as bandwidth utilization or absolute RTT value) cannot fully reflect the link status. For example, short-term RTT jitter may occur during low-Earth orbit satellite link switching, but the bandwidth pool is not full and services are not affected; or, for example, the reclaimable bandwidth pool is full of downloads but high-priority services respond normally, in which case a large-scale re-orchestration should not be triggered. Therefore, this step introduces a multi-dimensional congestion scoring mechanism, which comprehensively evaluates indicators from the link layer, bandwidth pool layer, and service experience layer.

[0046] In one implementation, a congestion score is generated based on link quality metrics, bandwidth pool pressure metrics, service experience metrics, and low real-time service occupancy metrics. Link quality metrics reflect changes in link RTT, packet loss rate, jitter, and available bandwidth; bandwidth pool pressure metrics reflect the occupancy rates of the three types of bandwidth pools; service experience metrics reflect the response time and connection stability of high-priority services; and low real-time service occupancy metrics reflect the bandwidth consumption of delayable services. The system can comprehensively calculate the congestion score as follows: the congestion score consists of the link quality score, bandwidth pool pressure score, service experience degradation score, and low real-time service occupancy score. Different weights can be assigned to each score based on different satellite link types. For example, in high-Earth orbit satellite link scenarios, the link quality score corresponding to service experience degradation and packet loss rate has higher weights; in low-Earth orbit satellite link scenarios, the link quality score corresponding to jitter and link switching status has higher weights; and in multi-ship concurrent scenarios, the single-ship bandwidth occupancy ratio and low real-time service occupancy score have higher weights.

[0047] In one possible implementation, determining the congestion level based on the congestion score may include: classifying the link status into normal state, congestion warning state, mild congestion state, moderate congestion state, severe congestion state, and recovery observation state. Normal state refers to a congestion score below a preset warning threshold, with all indicators within the normal range for the corresponding link type; congestion warning state refers to some indicators beginning to deteriorate but not yet affecting high-priority services; mild congestion state refers to a continuous increase in bandwidth utilization, with the reclaimable bandwidth pool fully occupied but high-priority services not yet significantly affected; moderate congestion state refers to RTT and packet loss rate deteriorating over multiple consecutive sampling periods, and response-sensitive or throughput-sensitive services experiencing slower access; severe congestion state refers to high-priority services already affected; and recovery observation state refers to all indicators falling back below the recovery threshold but not yet continuously meeting stable conditions. The system determines the corresponding congestion level based on the threshold range of the congestion score and the changing trend of the link status within consecutive sampling periods, providing a hierarchical decision basis for the differentiated reordering in step 107.

[0048] For different satellite link types, the system adopts different judgment priorities: for high-orbit satellite links, the main criteria are the increase in RTT relative to the historical baseline, packet loss rate, and service experience degradation status; for medium-orbit satellite links, the main criteria are the decrease in available bandwidth and bandwidth pool pressure; for low-orbit satellite links, the main criteria are the switching status, jitter duration, and continuous packet loss; for multi-link mixed scenarios, the congestion level of each link is calculated separately.

[0049] It should be noted that the congestion level is not determined solely by the linear summation of various scores. The system also considers continuous sampling trends and preset combined triggering conditions: when preset combined conditions such as deterioration of high-priority service response, increased pressure on the basic guarantee bandwidth pool, or rapid decline in available link bandwidth are met consecutively, the congestion level can be increased even if the total score has not yet reached the previous threshold; when a low-Earth orbit satellite handover causes momentary jitter but the service experience recovers within the observation period, even if the momentary score increases, a large-scale reordering will not be immediately executed.

[0050] Step 107: When a congestion state is detected, perform differentiated reordering of the three types of bandwidth pools according to the congestion level, and after the link enters the recovery observation state, gradually restore the ratio of elastic shared bandwidth pool and reclaimable bandwidth pool according to the preset step size.

[0051] In this embodiment, this step serves as the closed-loop execution link of the entire method. Following the congestion level determined in step 105, it transforms the evaluation results into specific bandwidth pool adjustment actions and introduces a gradual recovery and data-driven policy update mechanism. In satellite link scenarios, congestion handling needs to balance timeliness and stability. It must rapidly recover low-real-time service bandwidth to ensure critical services when congestion occurs, while preventing secondary congestion caused by the concentrated release of low-priority services after link recovery. Furthermore, different congestion levels require orchestration actions of varying intensities to avoid overreacting to mild congestion or underreacting to severe congestion.

[0052] In one possible implementation, differentiated rearrangement of the three types of bandwidth pools based on congestion levels may include: In a congestion warning state, limiting the continued expansion of the reclaimable bandwidth pool and increasing the sampling frequency, setting delayed start conditions for new downloads, system updates, and background synchronization tasks; In a mild congestion state, reducing the proportion of the reclaimable bandwidth pool, reclaiming some bandwidth for deferred services, and prioritizing the replenishment of the reclaimed bandwidth to the elastic shared bandwidth pool and the basic guarantee bandwidth pool; In a moderate congestion state, further reducing the proportion of the reclaimable bandwidth pool, shrinking the elastic shared bandwidth pool, setting single-terminal bandwidth limits, concurrency limits, or background loading limits for throughput-sensitive services such as short videos, live streaming, and online videos, while increasing the proportion of the basic guarantee bandwidth pool; In a severe congestion state, forcibly reclaiming the reclaimable bandwidth pool, suspending or delaying deferred services, limiting the concurrency of throughput-sensitive services, and prioritizing real-time interactive services and critical services in the basic guarantee bandwidth pool.

[0053] In one implementation, the ratio of the elastic shared bandwidth pool to the reclaimable bandwidth pool is gradually restored at preset steps, which can be performed after the link enters the recovery observation state. The system first restores the ratio of the elastic shared bandwidth pool, and then gradually restores the ratio of the reclaimable bandwidth pool at preset steps. If the link state deteriorates again during the recovery process, the recovery is paused and the congestion reordering process is re-entered. Through the anti-jitter gradual recovery mechanism, the system can avoid secondary congestion caused by the concentrated release of low-priority services in the early stage of link recovery, and achieve a smooth transition of network state.

[0054] Each re-orchestration follows a closed-loop process of "identification—judgment—issuance—verification—adjustment—recording." The system generates re-orchestration instructions corresponding to the congestion level and issues them to bandwidth management devices, traffic control devices, internet access behavior management devices, or multi-link scheduling devices. Within one or more sampling periods following execution, RTT, packet loss rate, bandwidth pool occupancy, and high-priority service response status are re-collected. If congestion is not alleviated, the congestion level is increased and a stronger re-orchestration action is executed; if high-priority services still do not recover, the proportion of the basic guaranteed bandwidth pool is further increased; if congestion is alleviated, the current strategy is maintained and recovery observation begins.

[0055] Optionally, when the system has at least two available links, the congestion level, stability, and available capacity of each link are determined separately. When the first link enters a state of moderate or severe congestion, while the second link is in a normal or lightly congested state, file downloads, system updates, background synchronization, or some video services are migrated to the second link, while voice, instant messaging, remote operation and maintenance, and critical services are retained on the link that meets the stability requirements. When link quality deteriorates or services are switched back, the system gradually recovers the migrated services according to a preset step size to avoid secondary congestion caused by a large number of services being switched back at once.

[0056] Step 109: Record key data for each congestion assessment and reordering process, and periodically update the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

[0057] In this embodiment, the system sets up a congestion re-arrangement data record table, which includes at least the following fields: ship identifier, link type, average RTT, RTT change rate, packet loss rate, jitter value, available bandwidth, total bandwidth utilization, utilization of the three types of bandwidth pools, response time of high-priority services, utilization ratio of low-real-time services, congestion score, congestion level, re-arrangement instructions issued, bandwidth pool ratio before re-arrangement, bandwidth pool ratio after re-arrangement, recovery step size, and whether secondary congestion has occurred. The policy update module periodically analyzes historical records. If it finds that a certain high-orbit satellite link frequently experiences moderate congestion due to peak video services during a specific time period, it lowers the elastic limit of throughput-sensitive services in advance. If it finds that a certain low-orbit satellite link frequently experiences short-term jitter during satellite handover but recovers quickly, it extends the congestion warning observation period. Through the above data-driven policy update closed loop, the system can continuously optimize the orchestration effect according to different satellite links, different ships, and different service scenarios.

[0058] Through the closed-loop processing of the above four steps, the embodiments of this application realize a closed-loop full-link bandwidth orchestration of "link awareness and quota allocation - service classification and bandwidth pooling - congestion quantification and level determination - differentiated re-orchestration and progressive recovery - data recording and policy update". It can improve the availability of critical services, reduce the long-term occupation of link resources by low real-time services, reduce the risk of secondary congestion during the link recovery phase, and ensure the normal service communication experience on the ship through satellite link environments with high latency, limited bandwidth and significant link status fluctuations.

[0059] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0060] Please refer to the following. Figure 2 , Figure 2 This illustration shows a schematic diagram of a service experience-aware elastic bandwidth orchestration device for high-latency satellite links, as provided in an embodiment of this application. It should be noted that... Figure 2 The service experience-aware flexible bandwidth orchestration apparatus for high-latency satellite links shown is used to perform the functions described in this application. Figure 1The methods shown in the embodiments are for illustrative purposes only, illustrating the parts relevant to the embodiments of this application. For specific technical details not disclosed, please refer to this application. Figure 1 The example shown.

[0061] like Figure 2 As shown, the service experience-aware elastic bandwidth orchestration device for high-latency satellite links may include at least:

[0062] Quota module 201 is used to collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota;

[0063] The partitioning module 202 is used to divide the normal business traffic on the ship into different business experience levels according to the experience sensitivity, and to divide the available bandwidth of the ship into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool.

[0064] The determination module 203 is used to generate a congestion score based on link quality indicators, bandwidth pool pressure indicators, service experience indicators and low real-time service occupancy indicators, and determine the congestion level based on the congestion score.

[0065] The recovery module 204 is used to perform differentiated reordering of the three types of bandwidth pools according to the congestion level when a congestion state is detected, and to gradually restore the ratio of the elastic shared bandwidth pool and the reclaimable bandwidth pool according to a preset step size after the link enters the recovery observation state.

[0066] The update module 205 is used to record key data in each congestion judgment and reordering process, and periodically update the bandwidth pool ratio, congestion judgment threshold and reordering strategy accordingly.

[0067] In one possible implementation, the hierarchical and segmentation module 202 is specifically used for:

[0068] The normal business traffic on the ship is divided into real-time interactive services, response-sensitive services, throughput-sensitive services, and deferred services. Real-time interactive services include voice communication, instant messaging, and remote operation and maintenance; response-sensitive services include web page access, business system access, and map queries; throughput-sensitive services include short videos, live streaming, and online videos; and deferred services include file downloads, system updates, and background synchronization.

[0069] In one possible implementation, the hierarchical and division module 202 is further used for:

[0070] The available ship-grade bandwidth is divided into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool. The basic guaranteed bandwidth pool is used to guarantee real-time interactive services and critical services, the elastic shared bandwidth pool is used to allocate response-sensitive services and throughput-sensitive services, and the reclaimable bandwidth pool is used to accommodate delayed services.

[0071] In one possible implementation, the scoring and judgment module 203 is specifically used for:

[0072] A link quality score is generated based on link round-trip latency, packet loss rate, jitter, and changes in available bandwidth; a bandwidth pool stress score is generated based on the occupancy rates of the three types of bandwidth pools; a service experience degradation score is generated based on the response time and connection stability of high-priority services; a low real-time service occupancy score is generated based on the bandwidth occupancy of delayable services; and the congestion score is generated by combining the above scores.

[0073] In one possible implementation, the scoring and judgment module 203 is further used for:

[0074] The link status is divided into normal status, congestion warning status, mild congestion status, moderate congestion status, severe congestion status, and recovery observation status; the corresponding congestion level is determined based on the threshold range of the congestion score and the trend of link status changes within a continuous sampling period.

[0075] In one possible implementation, the orchestration and recovery module 204 is specifically used for:

[0076] Under congestion warning conditions, the expansion of the reclaimable bandwidth pool is restricted and the sampling frequency is increased. Under mild congestion conditions, the proportion of the reclaimable bandwidth pool is reduced, and some bandwidth for delayable services is reclaimed. Under moderate congestion conditions, the proportion of the reclaimable bandwidth pool is further reduced, the elastic shared bandwidth pool is shrunk, and elastic limits are set for throughput-sensitive services. Under severe congestion conditions, the reclaimable bandwidth pool is forcibly reclaimed, delayable services are suspended or postponed, and priority is given to real-time interactive services and critical services in the basic guarantee bandwidth pool.

[0077] In one possible implementation, the orchestration and recovery module 204 is further configured to:

[0078] After the link enters the recovery observation state, the proportion of the elastic shared bandwidth pool is restored first, and then the proportion of the reclaimable bandwidth pool is restored step by step according to the preset step size; if the link status deteriorates again during the recovery process, the recovery is paused and the congestion reordering process is re-entered.

[0079] Those skilled in the art will clearly understand that the technical solutions of the embodiments of this application can be implemented by means of software and / or hardware. In this application, "unit" and "module" refer to software and / or hardware that can independently complete or cooperate with other components to complete a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit (IC), etc.

[0080] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0081] Please refer to the following. Figure 3 , Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.

[0082] like Figure 3 As shown, the electronic device 300 may include: at least one device processor 301, at least one network interface 304, user interface 303, memory 305, and at least one communication bus 302.

[0083] The communication bus 302 can be used to realize the connection and communication of the above components.

[0084] The user interface 303 may include buttons, and the optional user interface may also include a standard wired interface or a wireless interface.

[0085] The network interface 304 may include, but is not limited to, Bluetooth modules, NFC modules, Wi-Fi modules, etc.

[0086] The device processor 301 may include one or more processing cores. The device processor 301 connects to various parts within the electronic device 300 using various interfaces and lines. It executes various functions and processes data of the electronic device 300 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 305, and by calling data stored in the memory 305. Optionally, the device processor 301 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The device processor 301 may integrate one or more of the following: CPU, GPU, and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the device processor 301 and may be implemented as a separate chip.

[0087] The memory 305 may include RAM or ROM. Optionally, the memory 305 may include a non-transitory computer-readable medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned device processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and program instructions.

[0088] Specifically, the device processor 301 can be used to call the service experience-aware elastic bandwidth orchestration application for high-latency satellite links stored in the memory 305, and specifically perform the following operations:

[0089] Collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota;

[0090] The normal business traffic on the ship is divided into different business experience levels according to experience sensitivity, and the available bandwidth of the ship is divided into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool.

[0091] A congestion score is generated based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and the congestion level is determined based on the congestion score.

[0092] When congestion is detected, the three types of bandwidth pools are reorganized in a differentiated manner according to the congestion level. After the link enters the recovery observation state, the ratio of the elastic shared bandwidth pool and the reclaimable bandwidth pool is gradually restored according to the preset step size.

[0093] Record key data during each congestion assessment and reordering process, and periodically update the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

[0094] As an optional embodiment of this application, the step of classifying the normal shipboard service traffic into different service experience levels according to experience sensitivity includes: classifying the normal shipboard service traffic into real-time interactive services, response-sensitive services, throughput-sensitive services, and deferred services; wherein, real-time interactive services include voice communication, instant messaging, and remote operation and maintenance; response-sensitive services include web page access, business system access, and map query; throughput-sensitive services include short videos, live streaming, and online videos; and deferred services include file downloads, system updates, and background synchronization.

[0095] As an optional embodiment of this application, the step of dividing the available ship-grade bandwidth into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool includes: dividing the available ship-grade bandwidth into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool; wherein, the basic guaranteed bandwidth pool is used to guarantee real-time interactive services and critical services, the elastic shared bandwidth pool is used to allocate response-sensitive services and throughput-sensitive services, and the reclaimable bandwidth pool is used to accommodate delayable services.

[0096] As an optional embodiment of this application, the step of generating a congestion score based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators includes: generating a link quality score based on link round-trip time, packet loss rate, jitter, and changes in available bandwidth; generating a bandwidth pool pressure score based on the occupancy rates of the three types of bandwidth pools; generating a service experience degradation score based on the response time and connection stability of high-priority services; generating a low real-time service occupancy score based on the bandwidth occupancy of delayable services; and generating the congestion score by combining the above scores.

[0097] As an optional embodiment of this application, determining the congestion level based on the congestion score includes: dividing the link state into normal state, congestion warning state, mild congestion state, moderate congestion state, severe congestion state, and recovery observation state; and determining the corresponding congestion level based on the threshold range of the congestion score and the changing trend of the link state within a continuous sampling period.

[0098] As an optional embodiment of this application, the differentiated rearrangement of the three types of bandwidth pools according to the congestion level includes: under congestion warning state, limiting the continued expansion of the reclaimable bandwidth pool and increasing the sampling frequency; under mild congestion state, reducing the proportion of the reclaimable bandwidth pool and reclaiming some bandwidth for delayable services; under moderate congestion state, further reducing the proportion of the reclaimable bandwidth pool, shrinking the elastic shared bandwidth pool and setting an elastic upper limit for throughput-sensitive services; under severe congestion state, forcibly reclaiming the reclaimable bandwidth pool, suspending or postponing delayable services, and prioritizing real-time interactive services and critical services in the basic guarantee bandwidth pool.

[0099] As an optional embodiment of this application, the step of gradually restoring the ratio of the elastic shared bandwidth pool and the reclaimable bandwidth pool by a preset step size includes: after the link enters the recovery observation state, first restore the ratio of the elastic shared bandwidth pool, and then gradually restore the ratio of the reclaimable bandwidth pool by a preset step size; if the link state deteriorates again during the recovery process, the recovery is paused and the congestion reordering process is re-entered.

[0100] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0101] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0103] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units 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 through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0104] The units described 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.

[0105] Furthermore, the functional units in the various embodiments of this application 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.

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

[0107] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0108] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A service experience-aware elastic bandwidth orchestration method for high-latency satellite links, characterized in that, The method includes: Collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota; The normal business traffic on the ship is divided into different business experience levels according to experience sensitivity, and the available bandwidth of the ship is divided into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool. A congestion score is generated based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and the congestion level is determined based on the congestion score. When congestion is detected, the three types of bandwidth pools are reorganized in a differentiated manner according to the congestion level. After the link enters the recovery observation state, the ratio of the elastic shared bandwidth pool and the reclaimable bandwidth pool is gradually restored according to the preset step size. Record key data during each congestion assessment and reordering process, and periodically update the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

2. The method according to claim 1, characterized in that, The method of classifying the normal service traffic on the ship into different service experience levels based on experience sensitivity includes: The normal business traffic on the ship is divided into real-time interactive business, response-sensitive business, throughput-sensitive business, and delayable business. Among them, real-time interactive services include voice communication, instant messaging, and remote operation and maintenance; response-sensitive services include web page access, business system and map query; throughput-sensitive services include short videos, live streaming and online videos; and delayable services include file download, system update and background synchronization.

3. The method according to claim 1, characterized in that, The division of the available ship-grade bandwidth into a basic guaranteed bandwidth pool, a flexible shared bandwidth pool, and a reclaimable bandwidth pool includes: The available ship-class bandwidth is divided into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool; The basic guaranteed bandwidth pool is used to guarantee real-time interactive services and critical services, the elastic shared bandwidth pool is used to allocate response-sensitive services and throughput-sensitive services, and the reclaimable bandwidth pool is used to accommodate delayed services.

4. The method according to claim 1, characterized in that, The process of generating a congestion score based on link quality metrics, bandwidth pool pressure metrics, service experience metrics, and low real-time service occupancy metrics includes: A link quality score is generated based on link round-trip time, packet loss rate, jitter, and changes in available bandwidth. A bandwidth pool stress score is generated based on the occupancy rate of the three types of bandwidth pools; A service experience degradation score is generated based on the response time and connection stability of high-priority services; A low real-time service usage score is generated based on the bandwidth usage of delayable services. The congestion score is generated by combining the above scores.

5. The method according to claim 1, characterized in that, The step of determining the congestion level based on the congestion score includes: The link status is divided into normal status, congestion warning status, mild congestion status, moderate congestion status, severe congestion status, and recovery observation status. The corresponding congestion level is determined based on the threshold range in which the congestion score falls and the trend of link status changes within a continuous sampling period.

6. The method according to claim 1, characterized in that, The differential reordering of the three bandwidth pools based on the congestion level includes: Under congestion warning conditions, limit the continued expansion of the reclaimable bandwidth pool and increase the sampling frequency; In a state of mild congestion, reduce the proportion of reclaimable bandwidth pool and reclaim some bandwidth for delayable services; Under moderate congestion conditions, further reduce the proportion of reclaimable bandwidth pool, shrink the elastic shared bandwidth pool, and set elastic limits for throughput-sensitive services. In the event of severe congestion, the reclaimable bandwidth pool will be forcibly reclaimed, and deferred services will be suspended or postponed, prioritizing real-time interactive services and critical services in the basic guarantee bandwidth pool.

7. The method according to claim 1, characterized in that, The gradual restoration of the ratio between the elastic shared bandwidth pool and the reclaimable bandwidth pool according to a preset step size includes: After the link enters the recovery observation state, first restore the proportion of the elastic shared bandwidth pool, and then gradually restore the proportion of the reclaimable bandwidth pool according to the preset step size. If the link status deteriorates again during the recovery process, the recovery will be paused and the congestion rescheduling process will be restarted.

8. A service experience-aware elastic bandwidth orchestration device for high-latency satellite links, characterized in that, The device includes: The quota module is used to collect satellite link status data and ship-side normal service traffic data, identify the current satellite link type, and determine the ship-level available bandwidth based on the corresponding link baseline parameters and ship-level quota. The partitioning module is used to divide the normal business traffic on the ship into different business experience levels according to the experience sensitivity, and to divide the available bandwidth of the ship into a basic guaranteed bandwidth pool, an elastic shared bandwidth pool, and a reclaimable bandwidth pool. The judgment module is used to generate a congestion score based on link quality indicators, bandwidth pool pressure indicators, service experience indicators, and low real-time service occupancy indicators, and to determine the congestion level based on the congestion score. The recovery module is used to perform differentiated reordering of the three types of bandwidth pools according to the congestion level when a congestion state is detected, and to gradually restore the ratio of elastic shared bandwidth pool and reclaimable bandwidth pool according to a preset step size after the link enters the recovery observation state. The update module records key data during each congestion assessment and reordering process, and periodically updates the bandwidth pool ratio, congestion assessment threshold, and reordering strategy accordingly.

9. An electronic 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 steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer or processor, cause the computer or processor to perform the steps of the method as described in any one of claims 1-7.

Images