Business-aware satellite communication method, device, equipment and storage medium

Abstract

This invention provides a service-aware satellite communication method, apparatus, device, and storage medium. The method includes: identifying and predicting the current communication services of a terminal device to obtain service attribute information, service requirement parameters, and predicted data volume; selecting a transmission strategy based on the service requirement parameters, predicted data volume, and channel state parameters of the current satellite link, wherein a target transmission path is determined based on the predicted data volume, and a target satellite frequency band is determined based on the service requirement parameters and channel state parameters; generating quality of service request parameters based on the service attribute information and predicted data volume, and establishing a satellite communication link based on the target transmission path, target satellite frequency band, and quality of service request parameters. This invention, by introducing a frequency band selection dimension, achieves joint selection of transmission path and satellite frequency band, improving the terminal's transmission adaptability under different channel conditions and service requirements.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a service-aware satellite communication method, apparatus, device, and storage medium. Background Technology

[0002] With the development of satellite communication technology, non-terrestrial networks (NTNs) have been widely used in scenarios such as emergency rescue, remote positioning, and data transmission. Existing satellite communication methods mainly optimize resource allocation through traffic prediction and differentiated transmission strategies, selecting different transmission paths based on the predicted data volume, such as cloud server-assisted transmission, ground station-assisted transmission, or combined transmission.

[0003] Existing technologies only consider path selection based on data volume when choosing transmission strategies, failing to fully utilize the frequency resources of multi-band satellite systems. In practical applications, different frequency bands exhibit significant differences in channel quality, coverage characteristics, and transmission capabilities. Current solutions delegate frequency band selection to the network side for unified scheduling, preventing terminals from flexibly selecting the optimal frequency band based on current service requirements and real-time channel conditions. This results in insufficient transmission efficiency and reliability in scenarios with poor channel conditions or specific service requirements. Summary of the Invention

[0004] The main objective of this invention is to solve the technical problem that existing satellite communication methods select transmission paths based solely on data volume, failing to combine channel conditions and service requirements for frequency band selection, resulting in insufficient adaptability of transmission strategies. This invention provides a service-aware satellite communication method, characterized in that the service-aware satellite communication method includes: Identify and predict the current communication services of terminal devices to obtain service attribute information, service requirement parameters, and prediction data volume; A transmission strategy is selected based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link. The selection of the transmission strategy includes determining the target transmission path based on the predicted data volume and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters. Service quality request parameters are generated based on the service attribute information and the predicted data volume, and a satellite communication link is established based on the target transmission path, the target satellite frequency band, and the service quality request parameters.

[0005] The present invention also provides a service-aware satellite communication device, characterized in that the service-aware satellite communication device comprises: The service identification module is used to identify and predict the current communication services of the terminal device, and obtain service attribute information, service requirement parameters and prediction data volume; The strategy selection module is used to select a transmission strategy based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link. The selection of the transmission strategy includes determining the target transmission path based on the predicted data volume and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters. The link establishment module is used to generate quality of service request parameters based on the service attribute information and the predicted data volume, and to establish a satellite communication link based on the target transmission path, the target satellite frequency band, and the quality of service request parameters.

[0006] The present invention also provides a service-aware satellite communication device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; the at least one processor invokes the instructions in the memory to cause the service-aware satellite communication device to perform the steps of the service-aware satellite communication method described above.

[0007] The present invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described service-aware satellite communication method.

[0008] The aforementioned service-aware satellite communication method, apparatus, equipment, and storage medium identify and predict the current communication services of the terminal device to obtain service attribute information, service requirement parameters, and predicted data volume. Based on the service requirement parameters, predicted data volume, and current satellite link channel state parameters, a transmission strategy is selected. Specifically, the target transmission path is determined based on the predicted data volume, and the target satellite frequency band is determined based on the service requirement parameters and channel state parameters. Service quality request parameters are generated based on the service attribute information and predicted data volume, and a satellite communication link is established based on the target transmission path, target satellite frequency band, and service quality request parameters. This invention, by introducing a frequency band selection dimension, achieves joint selection of the transmission path and satellite frequency band, improving the terminal's transmission adaptability under different channel conditions and service requirements.

[0009] Beneficial Effects: By expanding transmission strategy selection from a single path dimension to a two-dimensional joint selection of path and frequency band based on service identification and prediction, the terminal can simultaneously determine the transmission path based on the predicted data volume and the satellite frequency band based on service requirement parameters and channel state parameters. This two-dimensional strategy space allows communication tasks with different channel qualities and service requirements to select differentiated frequency band resources under the same data volume conditions. This prioritizes anti-attenuation frequency bands to ensure reliability under poor channel conditions and prioritizes high-bandwidth frequency bands to improve throughput under good channel conditions. This avoids the policy rigidity problem caused by unified network-side frequency band selection in existing technologies and enhances the terminal's transmission adaptability in diverse scenarios.

[0010] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0011] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the first embodiment of the service-aware satellite communication method in this invention. Figure 2 This is a schematic diagram of a second embodiment of the service-aware satellite communication method in this invention. Figure 3 This is a schematic diagram of one embodiment of the service-aware satellite communication device of the present invention; Figure 4 This is a schematic diagram of one embodiment of a service-aware satellite communication device according to the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0015] To facilitate understanding of this embodiment, a service-aware satellite communication method disclosed in this invention will first be described in detail. For example... Figure 1 As shown, this method includes the following steps: 101. Identify and predict the current communication services of the terminal equipment to obtain service attribute information, service requirement parameters, and prediction data volume; In this embodiment, the step of identifying and predicting the current communication services of the terminal device to obtain service attribute information, service requirement parameters, and predicted data volume includes: extracting features from the communication triggering events of the terminal device, matching the extracted features with a preset service type feature library to obtain service attribute information; querying a preset service requirement mapping relationship based on the service attribute information to obtain service requirement parameters; and inputting the historical traffic data and environmental feature data of the terminal device into a hybrid neural network model for time-series prediction to obtain predicted data volume.

[0016] Specifically, after receiving a communication trigger event, the terminal device extracts features from the event. A communication trigger event can be understood as the initiation signal for satellite communication, and its source may be a user-initiated operation (such as pressing the SOS button), a data transmission request from an application, or a system-level scheduled task (such as periodic reporting of location information). Trigger events from different sources exhibit different characteristic patterns at the underlying level. These characteristics include the system privilege level of the trigger source, the device state at the time of triggering, and the characteristics of the data buffer associated with the trigger event. For example, trigger events for emergency rescue services typically contain high-priority identifiers and originate from the system's emergency service interface, while location reporting services are characterized by periodic triggering and a relatively fixed data volume.

[0017] The terminal device has a pre-built service type feature library, which stores typical feature patterns of various known services. The terminal device performs similarity matching between the extracted feature vectors and the service type templates in the feature library. Matching algorithms can use Euclidean distance, cosine similarity, etc. By calculating the similarity between the current feature vector and each template, the service type with the highest similarity is selected as the recognition result, thus obtaining service attribute information. This service attribute information includes a service type identifier, clearly indicating whether the current communication task belongs to the category of emergency rescue, location reporting, or data transmission.

[0018] After identifying the service type, the terminal needs to further determine the specific network transmission requirements of that service. Different service types have different requirements for network performance indicators such as latency and reliability; these requirements are quantitatively expressed as service requirement parameters. This embodiment establishes a correspondence between service types and requirement parameters through a preset service requirement mapping relationship. It should be noted that this mapping relationship is based on service characteristic analysis. For example, the essential characteristic of emergency rescue services lies in the life-or-death nature of information transmission; therefore, its reliability requirement should be set to a high level, requiring an extremely low transmission failure rate, while its latency requirement should also be set to a medium-low level. Data transmission services, especially large file transmissions, have core requirements for integrity and throughput, with a higher tolerance for latency; therefore, the latency requirement level can be set to high (i.e., allowing for longer transmission latency).

[0019] Based on the identified service attribute information, the terminal queries the corresponding requirement parameters in the mapping relationship. The query results include two dimensions: latency requirement level and reliability requirement level. The latency requirement level reflects the service's sensitivity to end-to-end transmission delay; the lower the level, the more stringent the latency requirement. The reliability requirement level reflects the service's tolerance for transmission failure; a high level means an extremely high transmission success rate is required.

[0020] In addition to qualitatively identifying the service type, the terminal also needs to quantitatively predict the data volume of this communication task. The size of the data volume directly affects the choice of transmission path. Small data volume tasks are suitable for fast forwarding via cloud servers, while large data volume tasks require high bandwidth support from ground stations or multi-path joint transmission. This embodiment uses a time-series prediction method based on historical traffic data to infer the data volume of the current communication task by analyzing the terminal device's past traffic usage patterns.

[0021] Specifically, the terminal device continuously records its historical traffic data, which is stored in time-series format, including uplink traffic, downlink traffic, and service type tags for each time window. In addition to the traffic data itself, the terminal also collects environmental characteristic data, such as the current time (weekday or weekend, day or night), geographic location type (city, suburbs, or wilderness), and network access status. These environmental characteristics have a significant impact on traffic patterns. For example, users in wilderness environments are more likely to report location information and transfer small files, while in urban environments, there may be a large demand for multimedia data transmission.

[0022] The terminal inputs historical traffic data and environmental feature data into a hybrid neural network model for prediction. The core of this model lies in integrating two temporal modeling structures: Long Short-Term Memory (LSTM) network layers and Gated Recurrent Unit (GRU) network layers. LSM networks excel at capturing long-term dependencies in data, such as users' weekly large file backups or periodic traffic peaks at the beginning of each month. GRU networks, on the other hand, are more sensitive to short-term fluctuations and can quickly respond to recent traffic spikes; for example, if a user has just started a video call, the subsequent data volume is likely to remain high.

[0023] The workflow of a hybrid neural network model is as follows: First, a Long Short-Term Memory (LSTM) network layer encodes the input historical traffic sequence, extracting long-term periodic features that reflect the macro trends in user traffic usage. Next, a Gated Recurrent Unit (GRU) network layer receives the tail segments of the historical sequence (typically data from the most recent time windows), extracting short-term fluctuation features to capture immediate changes in user behavior. The outputs of the two network layers are then weighted and combined by a feature fusion layer. The fused feature vector is then passed through a fully connected layer to output the predicted data volume, which is an estimate of the total amount of data required to be transmitted for the current communication task.

[0024] 102. Select a transmission strategy based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link, wherein the selection of the transmission strategy includes determining the target transmission path based on the predicted data volume, and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters; In this embodiment, the terminal device selects the transmission strategy using a preset strategy mapping table. Unlike methods based on real-time parameter comparison, this embodiment pre-constructs a strategy mapping relationship containing multiple scenario combinations, and the terminal searches for a matching strategy combination in the mapping table based on the current parameters.

[0025] Specifically, the terminal first acquires the channel state parameters of the current satellite link. These parameters are obtained by receiving physical layer signaling from the satellite network and reflect the current link quality status. The terminal then performs hierarchical processing on the acquired channel state parameters, mapping continuous channel state parameter values ​​to discrete quality levels, such as excellent, good, medium, and poor, according to a preset channel quality grading standard. This discretization simplifies the subsequent policy matching process.

[0026] The terminal device pre-stores a transmission strategy mapping table. This table uses service requirement parameters, predicted data volume range, and channel quality level as index dimensions, with each index combination corresponding to a preset optimal strategy. The mapping table is constructed based on extensive simulation tests and real-world scenario data analysis. By statistically analyzing the performance of each strategy under different parameter combinations, the optimal strategy is selected for each scenario. For example, when the service requirement parameters indicate high reliability requirements, the predicted data volume is within a small range, and the channel quality level is poor, the corresponding strategy in the mapping table is: select cloud server-assisted transmission for the target transmission path, and select the L-band for the target satellite frequency band.

[0027] It's important to note that the predicted data volume in the mapping table is not indexed by precise numerical values. Instead, it's pre-divided into several data volume ranges, such as small, medium, and large ranges. The terminal determines its corresponding range based on the current predicted data volume and uses that range as one of the query indexes in the mapping table. This range-based indexing method offers better robustness compared to precise numerical matching, tolerating estimation errors in the predicted data volume.

[0028] The terminal queries the policy mapping table based on current service requirements, the predicted data volume range, and the channel quality level. The query process is a multi-dimensional index retrieval; the terminal sequentially matches the index values ​​of each dimension to locate the corresponding policy entry in the mapping table. This entry explicitly records the recommended target transmission path and target satellite frequency band. The terminal directly adopts the policy configuration from this entry to complete the selection of the transmission policy.

[0029] This mapping table-based strategy selection method transforms the complex real-time decision-making process into a simple table query operation, significantly reducing the computational burden on the terminal. The mapping table can be obtained through offline optimization during the system design phase and updated periodically based on operational data after system deployment. When the network environment or business model changes, only the mapping table content needs to be updated, without modifying the terminal's decision-making logic, thus exhibiting good maintainability.

[0030] 103. Generate service quality request parameters based on the service attribute information and the predicted data volume, and establish a satellite communication link based on the target transmission path, the target satellite frequency band, and the service quality request parameters.

[0031] In this embodiment, generating service quality request parameters based on the service attribute information and the predicted data volume includes: querying a preset service QoS mapping table based on the service attribute information to obtain a QoS class identifier and a packet error rate requirement; determining a basic latency requirement value based on the service attribute information, and adjusting the basic latency requirement value based on the predicted data volume to obtain a packet latency budget, wherein when the predicted data volume is greater than a preset data volume threshold, the basic latency requirement value is multiplied by a preset relaxation coefficient to obtain the packet latency budget; when the predicted data volume is less than or equal to the preset data volume threshold, the basic latency requirement value is used as the packet latency budget; determining a priority based on the service attribute information and the predicted data volume, and combining the QoS class identifier, the priority, the packet latency budget, and the packet error rate requirement to obtain the service quality request parameters.

[0032] Specifically, after determining the transmission strategy, the terminal device needs to translate the service requirements into service quality parameters that can be recognized by the network side, and initiate a link establishment request accordingly. In traditional satellite communication systems, service quality parameters are usually directly specified by the application layer or use default configurations, which makes it difficult to reflect the actual needs of the underlying transmission tasks. This embodiment introduces a service-aware mechanism at the transport layer, enabling the terminal to intelligently generate service quality request parameters that match the current task based on service characteristics and data volume prediction results.

[0033] Specifically, the generation process of the Quality of Service (QoS) request parameters involves determining several components. First, the terminal queries a pre-defined service QoS mapping table based on the service attribute information. This mapping table establishes a correspondence between service types and QoS class identifiers defined by the 3GPP standard. QoS class identifiers are key parameters used by the network side to distinguish different QoS levels; different identifiers correspond to different resource scheduling priorities and transmission guarantee strategies. For example, the QoS class identifier for emergency rescue services is usually set to the highest priority category to ensure that it can still obtain resource guarantees during network congestion. The mapping table also records the packet error rate (PER) requirements for each service type. This parameter quantifies the service's requirements for transmission reliability; a lower PER requirement indicates a smaller tolerance for transmission errors.

[0034] After obtaining the QoS class identifier and packet error rate requirement, the terminal further determines the packet delay budget. The packet delay budget refers to the maximum allowable delay from packet transmission to successful reception, and this parameter directly affects the network-side scheduling decisions and resource allocation. In this embodiment, the determination of the packet delay budget needs to comprehensively consider the inherent delay requirements of the service and the data volume of the current task.

[0035] The terminal first determines the basic latency requirement value based on the service attribute information. Different service types have fundamentally different sensitivities to latency. Emergency distress calls need to deliver information as quickly as possible, so their basic latency requirement value is set relatively low. In contrast, large file transfer services have a higher tolerance for latency, so their basic latency requirement value can be set relatively leniently. This basic latency requirement value reflects the inherent characteristics of the service type and serves as the latency requirement benchmark without considering the specific scale of the transmission task.

[0036] It should be noted that for large-scale data transmission tasks, strictly adhering to the basic latency requirement often leads to low resource utilization efficiency. Large data transmissions inherently require significant time; forcing completion within a very short latency would necessitate allocating substantial bandwidth resources and high-priority scheduling authority on the network side, impacting the normal communication of other services. Therefore, this embodiment dynamically adjusts the basic latency requirement based on the predicted data volume.

[0037] The terminal determines whether the predicted data volume exceeds a preset data volume threshold. This threshold is set considering the typical data volume distribution of the service type. When the predicted data volume exceeds this threshold, it indicates that the data scale of the current task has significantly deviated from the normal level of the service, and in this case, appropriately relaxing the latency requirement is reasonable. The terminal multiplies the basic latency requirement value by a preset relaxation factor to obtain the adjusted packet latency budget. The relaxation factor is usually greater than 1, and its specific value is configured according to the service type and network capacity, providing greater flexibility for network scheduling while ensuring the basic latency requirements of the service.

[0038] When the predicted data volume does not exceed the threshold, the terminal directly uses the basic latency requirement value as the packet latency budget, maintaining strict latency requirements. This dynamic adjustment mechanism based on data volume allows the latency budget to better match the characteristics of the actual transmission task, avoiding resource waste or performance deficiencies caused by a "one-size-fits-all" fixed configuration.

[0039] In addition to the parameters mentioned above, the Quality of Service (QoS) request parameters also include a priority field. Determining the priority requires considering both business attribute information and the predicted data volume. The business type determines the basic priority level; emergency-related businesses have the highest base priority value, while ordinary data transmission businesses have a relatively lower base priority value. Based on the base value, the terminal fine-tunes the priority according to the predicted data volume. For tasks with smaller data volumes, which consume fewer resources and have shorter completion times, the priority can be appropriately increased to ensure rapid transmission. For tasks with larger data volumes, the priority should be appropriately decreased to prevent them from occupying high-priority resources for extended periods and affecting other urgent businesses.

[0040] The terminal combines the determined QoS class identifier, priority, packet delay budget, and packet error rate requirements to form a complete set of Quality of Service (QoS) request parameters. This parameter set comprehensively describes the network QoS expectations of the current communication task, providing a clear configuration basis for the subsequent link establishment process.

[0041] Furthermore, establishing a satellite communication link based on the target transmission path, the target satellite frequency band, and the quality of service request parameters includes: encapsulating the target transmission path identifier, the target satellite frequency band identifier, and the quality of service request parameters into a link establishment request message; sending the link establishment request message to the satellite network via radio resource control layer signaling; receiving a link configuration response message returned by the satellite network; parsing the allocated frequency band resources, transmission path configuration parameters, and MAC layer protocol parameters from the link configuration response message; configuring the physical layer and MAC layer of the terminal device according to the allocated frequency band resources, the transmission path configuration parameters, and the MAC layer protocol parameters; and establishing a communication link with the satellite network.

[0042] Specifically, the terminal first encapsulates the target transmission path identifier, target satellite frequency band identifier, and quality of service (QoS) request parameters into a link establishment request message. This encapsulation process follows the signaling message format specifications defined by 3GPP, with different parameter types occupying different information unit fields within the message. The target transmission path identifier informs the network side of the terminal's desired data forwarding path, such as whether it's via a cloud server or a ground station relay. The network side uses this identifier for route planning and resource reservation. The target satellite frequency band identifier clarifies the physical layer frequency resources requested by the terminal, allowing the network side to allocate frequency bands and coordinate interference. The QoS request parameters, as the core content of the message, include multiple fields such as QoS class identifier, priority, and packet delay budget. These fields are arranged in the message body according to the standard-defined order and format.

[0043] It's important to note that encapsulating the link establishment request message involves more than just listing parameters; consistency checks are also required. For example, when the target transmission path is a combined transmission, the message needs to include control information for multi-path parallel transmission, instructing the network side on how to perform data splitting and aggregation. When the target satellite frequency band is L-band, the bandwidth requirement in the quality of service request parameters should match the available bandwidth of the L-band to avoid requesting resources beyond the band's capabilities. The terminal performs these parameter validation checks during the encapsulation process to ensure the executability of the request message.

[0044] After encapsulation, the terminal sends a link establishment request message to the satellite network via Radio Resource Control (RRC) signaling. The RRC is a key protocol layer managing radio resource allocation and configuration; its signaling is carried on a reliable transmission channel to ensure accurate delivery of control messages. Simultaneously with sending the request message, the terminal starts a timer to wait for a response from the network. If no response is received within the timeout period, the terminal decides whether to retransmit the request based on its retransmission policy.

[0045] After receiving a link establishment request message, the satellite network performs a resource feasibility assessment and allocation decision. The network side first checks whether the requested frequency band resources are available and whether there is sufficient idle capacity to meet the quality of service (QoS) requirements. For transmission path configuration, the network side needs to coordinate with relevant satellite nodes, ground stations, or cloud servers to establish an end-to-end data forwarding path. At the MAC layer, the network side determines the HARQ retransmission mechanism parameter configuration based on the reliability and latency requirements in the QoS request parameters, such as the maximum number of retransmissions and the retransmission timeout.

[0046] After completing resource allocation and parameter configuration, the satellite network returns a link configuration response message to the terminal. This response message contains the resources and configuration parameters actually allocated by the network side, which may differ from the terminal's request. For example, if the requested frequency band resource is unavailable, the network side may allocate an alternative frequency band; if the requested quality of service level is too high and the current network load is heavy, the network side may appropriately reduce certain performance indicators. The response message explicitly records the allocated frequency band resources, transmission path configuration parameters, and MAC layer protocol parameters, which constitute the basis for the terminal's subsequent data transmission configuration.

[0047] After receiving the link configuration response message, the terminal parses the message. The parsing process extracts the values ​​of each parameter one by one, following the field order and data format defined in the protocol specification. From the frequency band resource field, the terminal learns the specific frequency, bandwidth, and transmit power limits allocated by the network. From the transmission path configuration parameters, the terminal understands the packet forwarding route and the address of the aggregation node. From the MAC layer protocol parameters, the terminal obtains key information such as HARQ configuration, scheduling request mechanism, and uplink grant mode.

[0048] After obtaining these parameters, the terminal needs to configure its physical layer and MAC layer accordingly. Physical layer configuration includes adjusting the operating frequency of the RF module to the allocated frequency band, setting the transmit power and modulation / coding scheme to match channel conditions and quality of service requirements. The terminal's baseband processing module also needs corresponding adjustments, such as configuring parameters like the channel coding rate and interleaving depth. MAC layer configuration involves setting the number of HARQ processes, configuring scheduling request trigger conditions, and establishing the mapping relationship between logical channels and transport channels.

[0049] It's important to note that the configuration of the physical layer and the MAC layer is not done in isolation; there is a tight parameter coupling between the two layers. For example, the HARQ retransmission strategy determined by the MAC layer requires corresponding feedback channel support from the physical layer, and the modulation and coding scheme configured by the physical layer affects the resource scheduling granularity of the MAC layer. During configuration, the terminal needs to ensure the consistency of cross-layer parameters to avoid protocol stack malfunctions due to improper configuration.

[0050] After configuration, the terminal sends a link establishment confirmation message to the satellite network, notifying the network side that the terminal has completed configuration and is ready. Upon receiving the confirmation, the satellite network marks the terminal's link status as "established," thus formally establishing the communication link between the terminal and the satellite network. The terminal can then begin transmitting data according to the configured transmission strategy and quality of service parameters, and the network side will provide service guarantees for this link according to the agreed resource allocation and priority.

[0051] In this embodiment, by identifying and predicting the current communication services of the terminal device, service attribute information, service requirement parameters, and predicted data volume are obtained. A transmission strategy is selected based on the service requirement parameters, predicted data volume, and current satellite link channel state parameters. Specifically, the target transmission path is determined based on the predicted data volume, and the target satellite frequency band is determined based on the service requirement parameters and channel state parameters. Service quality request parameters are generated based on the service attribute information and predicted data volume, and a satellite communication link is established based on the target transmission path, target satellite frequency band, and service quality request parameters. This invention, by introducing a frequency band selection dimension, achieves joint selection of the transmission path and satellite frequency band, improving the terminal's transmission adaptability under different channel conditions and service requirements.

[0052] Please see Figure 2 Another embodiment of the service-aware satellite communication method in this application includes: 201. Identify and predict the current communication services of the terminal equipment to obtain service attribute information, service requirement parameters and prediction data volume; In this embodiment, step 201 is similar to step 101 in the first embodiment, and will not be described again here.

[0053] 202. Extract the channel state parameters of the current satellite link from the physical layer signaling of the current satellite link; In this embodiment, extracting the channel state parameters of the current satellite link from the physical layer signaling of the current satellite link includes: receiving radio resource control layer signaling issued by the satellite network; parsing the channel quality indication field from the radio resource control layer signaling to obtain a channel quality indication value; performing numerical mapping on the channel quality indication value to map the channel quality indication value to a corresponding signal-to-noise ratio estimate or channel quality level to obtain the channel state parameters.

[0054] Specifically, terminal devices need to obtain real-time channel state information of the current satellite link to support subsequent frequency band selection decisions. The channel quality of satellite communication links is affected by various factors, including propagation distance, atmospheric attenuation, Doppler shift, and the relative motion between the satellite and the terminal. These factors cause channel quality to exhibit dynamic changes, making it impossible for the terminal to directly obtain an accurate channel state assessment through local measurements. In the satellite communication standards defined by 3GPP, the network side is responsible for measuring and assessing channel quality and sending the assessment results to the terminal via standard signaling.

[0055] Specifically, the terminal receives radio resource control (RRC) signaling from the satellite network. The RRC is the protocol layer responsible for radio resource management and configuration, and its signaling messages carry a large amount of information related to link status. In satellite communication scenarios, the network periodically sends signaling messages containing channel measurement results to the terminal. The transmission period of these messages is dynamically adjusted according to the channel change rate. When channel quality fluctuates significantly, the signaling transmission frequency is increased accordingly to ensure that the terminal can promptly grasp changes in channel status.

[0056] After receiving Radio Resource Control (RRC) signaling, the terminal needs to locate and extract channel quality-related information from the complex message structure. RRC signaling messages typically contain multiple information units, each carrying different types of control information, such as resource allocation instructions, power control commands, and handover indications. Channel quality information is stored in a dedicated Channel Quality Indicator (CQI) field, the location and format of which are clearly defined in the protocol standard. The terminal extracts the CQI field's content by parsing the message's structured fields to obtain the CQI value.

[0057] It should be noted that the Channel Quality Indicator (CQI) is a quantitative indicator calculated by the network side based on a comprehensive analysis of multiple physical layer measurements. The network side analyzes parameters such as channel measurement reports, received signal strength, and block error rate reported by terminals, combined with the link budget model and channel fading characteristics, to calculate the overall quality level of the current link. This calculation process considers multiple dimensions of channel characteristics, including not only signal-to-noise ratio (SNR) but also factors such as frequency-selective fading and time correlation. The final CQI is a discrete integer, and its range and meaning are defined by standards; different values ​​represent different channel quality levels.

[0058] After obtaining the channel quality indicator (CQI), the terminal needs to convert this discrete indicator into channel state parameters that are easy to use for policy decisions. The CQI itself is an abstract level identifier, and the terminal needs to understand the actual channel performance corresponding to this level identifier. This embodiment completes this conversion through numerical mapping.

[0059] The terminal pre-stores a mapping relationship between channel quality indicators (CMI) and signal-to-noise ratio (SNR) estimates or channel quality levels. This mapping relationship can take two forms: one maps the CMI to a specific SNR estimate, and the other maps it to a qualitative channel quality level. Mapping to an SNR estimate provides a quantitative basis for subsequent modulation and coding scheme selection, power control, etc., allowing the terminal to calculate link capacity and bit error rate based on the SNR estimate. Mapping to a channel quality level is more concise, discretizing the continuous channel quality space into a finite number of levels, such as excellent, good, average, and poor. This discretization simplifies the decision-making logic, enabling strategies such as frequency band selection to be based on clear level judgments.

[0060] The mapping process essentially involves querying a pre-defined mapping table or applying a mapping function based on the channel quality indicator (CQI) value to obtain the corresponding output value. The mapping table or function is established based on standards and measured data. Standards define the theoretical correspondence between the CQI and the signal-to-noise ratio (SNR), while measured data provides mapping calibration in actual systems. The terminal uses the currently acquired CQI value to find or calculate the corresponding SNR estimate or channel quality level from the mapping relationship, and then uses this as a channel state parameter.

[0061] This channel state parameter is then used for frequency band selection decisions. During frequency band selection, the terminal needs to determine whether the current channel quality is suitable for using a high-frequency or low-frequency band, and the channel state parameter provides a quantitative basis for this judgment. Through the above-described process of signaling reception, field parsing, and numerical mapping, the terminal transforms the abstract channel quality indication sent by the network side into channel state parameters that can be used for decision-making, thus completing the acquisition and processing of channel state information.

[0062] 203. Compare the predicted data volume with a first data volume threshold and a second data volume threshold, and determine the target transmission path based on the comparison result, wherein the target transmission path includes a cloud server-assisted transmission path, a ground station-assisted transmission path, and a combined transmission path; In this embodiment, the terminal device selects a suitable transmission path based on the predicted data volume. Satellite communication systems support multiple transmission path architectures, each with its own characteristics in terms of resource consumption, transmission latency, and processing capabilities. For communication tasks with significantly different data volumes, using a uniform transmission path can lead to low resource utilization efficiency or insufficient transmission performance; therefore, differentiated path selection based on data volume is necessary.

[0063] Specifically, the terminal compares the predicted data volume with two preset data volume thresholds. The first and second data volume thresholds divide the data volume space into three intervals, based on the carrying capacity and performance characteristics of each transmission path. The cloud server-assisted transmission path is suitable for handling small-scale data. In this path, data is transmitted via satellite to a cloud server, which performs rapid forwarding or lightweight processing. The entire transmission link has fewer hops and lower end-to-end latency. However, cloud servers have limited computing and storage resources, and their connection bandwidth to terrestrial networks is limited. When the data volume is too large, the cloud server can become a transmission bottleneck, leading to increased queuing delays or even congestion.

[0064] Ground station-assisted transmission paths are more suitable for medium-scale data transmission. As access nodes between satellite networks and the terrestrial internet, ground stations possess strong data processing capabilities and abundant network resources. After terminals transmit data to the ground station via satellite, the ground station can efficiently receive, buffer, and forward the data, with bandwidth capacity far exceeding that of cloud server paths. Ground stations are typically equipped with dedicated communication equipment and high-speed fiber optic links, capable of supporting large data transmission demands. However, the coverage of ground stations is limited; not all areas can directly access them, and their resources need to be shared among multiple terminals. When the number of connected terminals is large or the data volume of a single terminal is excessive, ground station resources may become strained.

[0065] Joint transmission paths are high-throughput solutions designed for large-scale data transmission. In this approach, the terminal simultaneously utilizes multiple visible satellites, ground stations, or cloud nodes to divide data into blocks and transmit them concurrently through multiple parallel paths. Each path carries a portion of the data blocks, which are then reassembled at the receiving end. This parallel transmission method overcomes the bandwidth limitations of a single path, significantly improving overall throughput. Implementing joint transmission paths requires complex resource coordination and data scheduling. The terminal needs to maintain the status of multiple links, manage the distribution and reassembly of data blocks, and the network side also needs to cooperate in configuring multi-path routing and load balancing. The establishment and maintenance of this path incurs significant overhead; only when the data volume is sufficiently large can the throughput improvement offset the additional control overhead.

[0066] Based on the characteristics of the three paths mentioned above, the first data volume threshold is used to distinguish the boundary between small and medium data transmission, while the second data volume threshold divides the boundary between medium and large data transmission. The terminal first determines whether the predicted data volume is less than the first data volume threshold. If this condition is met, it indicates that the current task belongs to small-scale data transmission, and the terminal determines the target transmission path as the cloud server-assisted transmission path. This selection can fully utilize the low latency advantage of the cloud path to quickly complete data transmission.

[0067] If the predicted data volume is greater than or equal to the first data volume threshold, the terminal continues to determine whether it is less than the second data volume threshold. If the predicted data volume is between the two thresholds, the terminal determines the target transmission path as the ground station auxiliary transmission path. At this point, the data volume has exceeded the efficient processing range of the cloud path, but has not yet reached the level requiring the activation of joint transmission. The ground station path can achieve a good balance between performance and complexity.

[0068] If the predicted data volume is greater than or equal to the second data volume threshold, the terminal determines the target transmission path as a joint transmission path. In this case, a single path cannot meet the transmission requirements of large data volumes, and multi-path parallel transmission must be used to ensure transmission efficiency and completion time.

[0069] It should be noted that the data volume threshold is not fixed but needs to be dynamically adjusted based on the actual operating status of the system and the network environment. When the network load is light and available resources are sufficient, the first data volume threshold can be appropriately increased, allowing more tasks to use cloud paths and reducing the resource consumption of ground stations. When the network is congested and resources are scarce, the threshold needs to be lowered to enable high-capacity paths such as joint transmission as early as possible, avoiding overload of a single path. The terminal can adaptively adjust the threshold by receiving threshold update signaling from the network side or based on locally observed transmission performance feedback.

[0070] 204. Compare the channel state parameters with the preset channel threshold, and determine the target satellite frequency band based on the comparison results and the reliability requirement level and latency requirement level in the service requirement parameters; In this embodiment, determining the target satellite frequency band based on the comparison result and the reliability requirement level and latency requirement level in the service requirement parameters includes: judging the relationship between the channel state parameter and the preset channel threshold to obtain a channel quality judgment result; when the channel quality judgment result indicates that the channel state parameter is less than the preset channel threshold, extracting the reliability requirement level in the service requirement parameters for judgment; if the reliability requirement level is high, then the target satellite frequency band is determined to be the L-band; if the reliability requirement level is not high, then the target satellite frequency band is determined to be the L-band or S-band based on the size of the predicted data volume; when the channel quality judgment result indicates that the channel state parameter is greater than or equal to the preset channel threshold, extracting the latency requirement level in the service requirement parameters for judgment; if the latency requirement level is low, then the target satellite frequency band is determined to be the AWS frequency band; if the latency requirement level is high, then the target satellite frequency band is determined to be the S-band.

[0071] Specifically, terminal devices need to select the most suitable satellite frequency band for communication based on the current channel quality and service requirements. Multi-band satellite systems provide terminals with a variety of frequency resource options. Due to differences in their electromagnetic wave propagation characteristics, different frequency bands vary in coverage, anti-interference performance, and available bandwidth. Traditional frequency band selection methods often rely on unified scheduling by the network side, with the terminal passively accepting the allocation results. This approach struggles to balance the service characteristics of individual terminals with real-time channel conditions. This embodiment combines channel state assessment with service requirement awareness, enabling the terminal to proactively select the frequency band best suited to the current scenario.

[0072] Specifically, the terminal first determines the relationship between the channel state parameters and the preset channel threshold. The preset channel threshold is the dividing line between good and bad channel quality, and its setting comprehensively considers the performance of each frequency band under different channel conditions. When the channel quality is higher than this threshold, each frequency band can maintain good transmission performance, and the focus of frequency band selection shifts to optimizing performance indicators such as latency or bandwidth. When the channel quality is lower than this threshold, channel reliability becomes the primary consideration, and frequency bands with strong anti-attenuation capabilities need to be selected to ensure link stability.

[0073] The terminal compares channel state parameters with preset channel thresholds to obtain a channel quality assessment result. This assessment result categorizes the channel condition into two main types: poor channel quality and good channel quality. This binary classification provides a clear basis for subsequent decision-making logic.

[0074] When the channel quality assessment result indicates that the channel state parameters are less than the preset channel threshold, it indicates that the current link is in a poor channel environment. In this case, the main challenge for the terminal is how to complete data transmission under adverse channel conditions. Channel quality degradation in satellite communications is usually caused by a variety of factors, such as rain attenuation caused by heavy rainfall, absorption of electromagnetic waves by water vapor and oxygen in the atmosphere, and shadow fading caused by buildings or terrain obstruction. Different frequency bands have significantly different sensitivities to these attenuation factors. Higher frequency electromagnetic waves have shorter wavelengths and are more sensitive to particles such as water droplets and ice crystals in the atmosphere, resulting in more severe attenuation under adverse weather conditions such as rain.

[0075] The L-band operates in a lower frequency range, with longer wavelengths, strong diffraction capabilities, and relatively less susceptibility to atmospheric attenuation. In heavy rainfall conditions, L-band signal attenuation is typically only a few decibels, while attenuation at higher frequencies can reach tens or even hundreds of decibels. This resistance to attenuation makes the L-band a preferred frequency band under poor channel conditions. However, the available spectrum resources in the L-band are relatively limited, and its bandwidth is not as ample as higher frequency bands, potentially leading to rate limitations in high-data-volume transmission scenarios.

[0076] After confirming poor channel quality, the terminal further extracts the reliability requirement level from the service demand parameters for assessment. The reliability requirement level reflects the current service's requirement for transmission success rate. For life-threatening services such as emergency rescue, the reliability requirement level is set to high. These services must ensure successful information delivery, and transmission failure cannot be tolerated even under extreme channel conditions. When the reliability requirement level is high, the terminal unhesitatingly selects the L-band as the target satellite frequency band, leveraging the high reliability of the L-band to guarantee the transmission of critical information.

[0077] If the reliability requirement level is not high, it indicates that the current service has a certain tolerance for transmission failures, and the terminal can weigh reliability against transmission efficiency. In this case, the terminal considers the predicted data volume as an auxiliary basis for judgment. For tasks with small data volumes, even with the limited bandwidth of the L-band, transmission can be completed within a reasonable time, so the L-band can still be selected to obtain a higher transmission success rate. For tasks with large data volumes, if the L-band is used forcibly, the limited bandwidth will lead to excessively long transmission times, and prolonged channel occupation will increase the risk of transmission interruption due to channel fluctuations. In this case, the terminal can choose the S-band. Although the performance of the S-band degrades significantly under poor channel conditions, its bandwidth advantage can shorten the transmission time, reducing the impact of channel fluctuations by completing the transmission quickly.

[0078] When the channel quality assessment result indicates that the channel state parameter is greater than or equal to the preset channel threshold, it means that the current link is in a relatively good channel environment, and the transmission reliability of each frequency band can be basically guaranteed. Under this condition, the terminal's frequency band selection strategy shifts from ensuring reliability to optimizing transmission performance, focusing on indicators such as latency and throughput.

[0079] The terminal extracts the latency requirement level from the service demand parameters for judgment. The latency requirement level reflects the service's sensitivity to end-to-end transmission delay. A low latency requirement level indicates that the service has strict requirements on latency and needs to minimize the delay of each link in the data transmission process. Satellite communication latency mainly consists of propagation delay and processing delay. Propagation delay depends on the satellite's orbital altitude and the electromagnetic wave propagation speed, while processing delay is related to data encoding / decoding, modulation / demodulation, and other processing procedures.

[0080] The AWS band offers a latency advantage in certain LEO (Low Earth Orbit) satellite systems. LEO satellites orbit at significantly lower altitudes than GEO (Geostationary Orbit) satellites, drastically reducing the propagation distance of electromagnetic waves and lowering round-trip latency from hundreds of milliseconds for GEO satellites to tens of milliseconds. As a spectrum resource specifically allocated for satellite communications, the AWS band is prioritized and optimized in LEO systems. When latency requirements are low, terminals select the AWS band, leveraging its low latency characteristics in LEO systems to meet the real-time requirements of their services.

[0081] If the latency requirement level is high, it indicates that the service has a high tolerance for latency, and the terminal can focus its optimization efforts on bandwidth and throughput. The S-band operates in a mid-frequency range, balancing coverage and spectrum resources, and its available bandwidth is relatively abundant, supporting high data transmission rates. Under good channel conditions, the S-band has high transmission efficiency, making it suitable for data transmission services with high throughput requirements. Terminals choosing the S-band as the target satellite frequency band can fully utilize its bandwidth resources to improve transmission efficiency.

[0082] 205. Generate service quality request parameters based on the service attribute information and the predicted data volume, and establish a satellite communication link based on the target transmission path, the target satellite frequency band, and the service quality request parameters.

[0083] In this embodiment, step 205 is similar to step 103 in the first embodiment, and will not be described again here.

[0084] In this embodiment, the current communication services of the terminal device are identified and predicted to obtain service attribute information, service requirement parameters, and predicted data volume. A transmission strategy is selected based on the service requirement parameters, predicted data volume, and current satellite link channel state parameters. Specifically, the target transmission path is determined based on the predicted data volume, and the target satellite frequency band is determined based on the service requirement parameters and channel state parameters. Quality of Service (QoS) request parameters are generated based on the service attribute information and predicted data volume, and a satellite communication link is established based on the target transmission path, target satellite frequency band, and QoS request parameters. This invention, by introducing a frequency band selection dimension, achieves joint selection of the transmission path and satellite frequency band, improving the terminal's transmission adaptability under different channel conditions and service requirements.

[0085] The above describes the service-aware satellite communication method in the embodiments of the present invention. The following describes the service-aware satellite communication device in the embodiments of the present invention. Please refer to [link to relevant documentation] for details. Figure 3 One embodiment of the service-aware satellite communication device in this invention includes: The service identification module 301 is used to identify and predict the current communication services of the terminal device, and obtain service attribute information, service requirement parameters and prediction data volume. The strategy selection module 302 is used to select a transmission strategy based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link. The selection of the transmission strategy includes determining the target transmission path based on the predicted data volume and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters. The link establishment module 303 is used to generate quality of service request parameters based on the service attribute information and the predicted data volume, and to establish a satellite communication link based on the target transmission path, the target satellite frequency band and the quality of service request parameters.

[0086] In this embodiment of the invention, the service-aware satellite communication device operates the aforementioned service-aware satellite communication method. The service-aware satellite communication device identifies and predicts the current communication services of the terminal device to obtain service attribute information, service requirement parameters, and predicted data volume. It then selects a transmission strategy based on the service requirement parameters, predicted data volume, and channel state parameters of the current satellite link. Specifically, it determines the target transmission path based on the predicted data volume and the target satellite frequency band based on the service requirement parameters and channel state parameters. Finally, it generates quality of service (QoS) request parameters based on the service attribute information and predicted data volume, and establishes a satellite communication link based on the target transmission path, target satellite frequency band, and QoS request parameters. This invention, by introducing a frequency band selection dimension, achieves joint selection of the transmission path and satellite frequency band, improving the terminal's transmission adaptability under different channel conditions and service requirements.

[0087] above Figure 3 The service-aware satellite communication device in this embodiment of the invention will be described in detail from the perspective of modular functional entities. The service-aware satellite communication equipment in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0088] Figure 4 This is a schematic diagram of a service-aware satellite communication device 400 provided in an embodiment of the present invention. The service-aware satellite communication device 400 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 410 (e.g., one or more processors) and a memory 420, and one or more storage media 430 (e.g., one or more mass storage devices) for storing application programs 433 or data 432. The memory 420 and storage media 430 can be temporary or persistent storage. The program stored in the storage media 430 may include one or more units (not shown in the diagram), each unit may include a series of instruction operations on the service-aware satellite communication device 400. Furthermore, the processor 410 may be configured to communicate with the storage media 430 and execute the series of instruction operations in the storage media 430 on the service-aware satellite communication device 400 to implement the steps of the aforementioned service-aware satellite communication method.

[0089] The service-aware satellite communication equipment 400 may also include one or more power supplies 440, one or more wired or wireless network interfaces 450, one or more input / output interfaces 460, and / or one or more operating systems 431, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 4 The illustrated service-aware satellite communication equipment structure does not constitute a limitation on the service-aware satellite communication equipment provided by the present invention. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0090] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the service-aware satellite communication method.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0092] 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 medium. Based on this understanding, the technical solution of the present invention, 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 storage medium 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0093] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. 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 the present invention.

Claims

1. A service-aware satellite communication method, characterized in that, The service-aware satellite communication method includes: Identify and predict the current communication services of terminal devices to obtain service attribute information, service requirement parameters, and prediction data volume; A transmission strategy is selected based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link. The selection of the transmission strategy includes determining the target transmission path based on the predicted data volume and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters. Service quality request parameters are generated based on the service attribute information and the predicted data volume, and a satellite communication link is established based on the target transmission path, the target satellite frequency band, and the service quality request parameters.

2. The service-aware satellite communication method according to claim 1, characterized in that, The process of identifying and predicting the current communication services of the terminal device to obtain service attribute information, service requirement parameters, and prediction data volume includes: The communication trigger events of the terminal device are feature extracted, and the extracted features are matched with a preset service type feature library to obtain service attribute information; Based on the business attribute information, a preset business requirement mapping relationship is queried to obtain the business requirement parameters; The historical traffic data and environmental feature data of the terminal device are input into a hybrid neural network model for time-series prediction to obtain the predicted data volume.

3. The service-aware satellite communication method according to claim 1, characterized in that, The step of selecting a transmission strategy based on the service requirement parameters, the predicted data volume, and the current satellite link channel state parameters includes: Extract the channel state parameters of the current satellite link from the physical layer signaling of the current satellite link; The predicted data volume is compared with a first data volume threshold and a second data volume threshold, and the target transmission path is determined based on the comparison result. The target transmission path includes a cloud server-assisted transmission path, a ground station-assisted transmission path, and a combined transmission path. The channel state parameters are compared with a preset channel threshold, and the target satellite frequency band is determined based on the comparison results and the reliability requirement level and latency requirement level in the service requirement parameters.

4. The service-aware satellite communication method according to claim 3, characterized in that, The extraction of channel state parameters of the current satellite link from the physical layer signaling of the current satellite link includes: Receive radio resource control layer signaling sent by the satellite network, parse the channel quality indication field from the radio resource control layer signaling, and obtain the channel quality indication value; The channel quality indication value is numerically mapped to a corresponding signal-to-noise ratio estimate or channel quality level to obtain the channel state parameter.

5. The service-aware satellite communication method according to claim 3, characterized in that, The step of determining the target satellite frequency band based on the comparison results and in conjunction with the reliability requirement level and latency requirement level in the service requirement parameters includes: Determine the relationship between the channel state parameters and the preset channel threshold to obtain the channel quality judgment result; When the channel quality judgment result indicates that the channel state parameter is less than the preset channel threshold, the reliability requirement level in the service requirement parameter is extracted for judgment. If the reliability requirement level is high, the target satellite frequency band is determined to be L-band; if the reliability requirement level is not high, the target satellite frequency band is determined to be L-band or S-band based on the size of the predicted data volume. When the channel quality judgment result indicates that the channel state parameter is greater than or equal to the preset channel threshold, the latency requirement level in the service requirement parameter is extracted for judgment. If the latency requirement level is low, the target satellite frequency band is determined to be the AWS band; if the latency requirement level is high, the target satellite frequency band is determined to be the S-band.

6. The service-aware satellite communication method according to claim 1, characterized in that, The step of generating service quality request parameters based on the business attribute information and the predicted data volume includes: Based on the service attribute information, a preset service QoS mapping table is queried to obtain the QoS class identifier and packet error rate requirement; The basic latency requirement value is determined based on the business attribute information, and the basic latency requirement value is adjusted and calculated based on the predicted data volume to obtain the group latency budget. Specifically, when the predicted data volume is greater than a preset data volume threshold, the basic latency requirement value is multiplied by a preset relaxation coefficient to obtain the group latency budget; when the predicted data volume is less than or equal to the preset data volume threshold, the basic latency requirement value is used as the group latency budget. The priority is determined based on the service attribute information and the predicted data volume, and the QoS class identifier, the priority, the packet delay budget, and the packet error rate requirement are combined to obtain the quality of service request parameters.

7. The service-aware satellite communication method according to claim 1, characterized in that, The step of establishing a satellite communication link based on the target transmission path, the target satellite frequency band, and the quality of service request parameters includes: The target transmission path identifier, the target satellite frequency band identifier, and the quality of service request parameters are encapsulated into a link establishment request message; The link establishment request message is sent to the satellite network through radio resource control layer signaling, and the link configuration response message returned by the satellite network is received. The allocated frequency band resources, transmission path configuration parameters and MAC layer protocol parameters are parsed from the link configuration response message. The physical layer and MAC layer of the terminal device are configured according to the allocated frequency band resources, the transmission path configuration parameters, and the MAC layer protocol parameters to establish a communication link with the satellite network.

8. A service-aware satellite communication device, characterized in that, The service-aware satellite communication device includes: The service identification module is used to identify and predict the current communication services of the terminal device, and obtain service attribute information, service requirement parameters and prediction data volume; The strategy selection module is used to select a transmission strategy based on the service requirement parameters, the predicted data volume, and the channel state parameters of the current satellite link. The selection of the transmission strategy includes determining the target transmission path based on the predicted data volume and determining the target satellite frequency band based on the service requirement parameters and the channel state parameters. The link establishment module is used to generate quality of service request parameters based on the service attribute information and the predicted data volume, and to establish a satellite communication link based on the target transmission path, the target satellite frequency band, and the quality of service request parameters.

9. A service-aware satellite communication device, characterized in that, The service-aware satellite communication device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the service-aware satellite communication device to perform the steps of the service-aware satellite communication method as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions are executed by the processor, they implement the steps of the service-aware satellite communication method as described in any one of claims 1-7.

Images