Business demand analysis and resource automatic planning method and system for digital payload satellite communication system

Abstract

Disclosed are a method and system for service demand analysis and resource automatic planning for a digital payload satellite communication system, the method comprising: S1, receiving a user service application through terminal simulation software, a network management system or a service platform; S2, performing network access verification, location verification and service type verification according to an access authentication relationship table, terminal identity information and a beam coverage relationship; S3, identifying the service as a fixed point-to-point, fixed online, roaming point-to-point or roaming online scenario, and splitting a composite service into sub-demands that can be independently solved; S4, converting original service fields into a unified payload resource demand description; S5, converting the standardized demand into resource allocation algorithm input parameters according to a preset mapping rule; S6, automatically generating frequency allocation results, bandwidth allocation results, sub-band exchange relationships and sub-band gain allocation results; S7, returning the planning results; and S8, tracking the state of the service demand.

Description

Technical Field

[0001] This invention relates to the field of satellite communication technology, and in particular to a method for analyzing service requirements and automatically planning resources for digital payload satellite communication systems. Background Technology

[0002] Digital payload satellite communication systems utilize digital transparent processors (DTPs) to achieve subband-level switching, subband-level gain control, and flexible beam interconnection, supporting star, mesh, and hybrid topologies. Compared to traditional transparent transponder systems, digital payload systems require more precise and coordinated management of service requirements, beam coverage, frequency bandwidth, subband switching relationships, and power gain on the ground side.

[0003] Current practices typically involve the network management system receiving service requests from user terminals, then manually or semi-manually translating the original service requirements into resource configuration parameters, which are subsequently submitted to the resource allocation module and the payload control module. For different service scenarios such as fixed point-to-point, fixed internet access, roaming point-to-point, and roaming internet access, existing methods mostly employ a decentralized processing model, relying on operators to individually determine terminal identity, accessible beams, service timeliness, and link direction. For small- to medium-sized digital payload systems, this method can still complete basic configuration; however, with the rapid increase in the number of ports, subbands, and service types, relying solely on manual conversion and coarse-grained allocation is insufficient to support the highly complex, dynamic, and scenario-based scheduling of digital payload resources. For example, publication number CN116112059A discloses a system and method for digital transparent transponder control participating in satellite communication link management, which jointly manages DTP link resources through a ground control agent (GWFC) and a network management center (NNC), covering workflows such as service link establishment, resource reconfiguration, and rejection handling. However, this solution focuses on DTP link-level resource management and link establishment process control, without disclosing a standardized modeling mechanism for business requirements, and without realizing automatic scenario identification, requirement splitting, and joint planning output of frequency / bandwidth / subband switching / subband gain. It still relies on external systems to complete the conversion of business-side parameters to load-side parameters, and cannot complete access authentication, scenario identification, and multi-dimensional resource collaborative planning in the same process.

[0004] In other words, existing technologies have the following drawbacks:

[0005] 1. Lack of a unified standardized model for business requirements: Business requests initiated by the terminal are directly sent up with business-side fields. There is a lack of a stable, automatic, and scalable mapping mechanism between these fields and the load-oriented structured parameters required by the resource algorithm. This can easily lead to inconsistent field interpretations, missing parameters, or manual re-entry errors in different scenarios.

[0006] 2. Decoupling of business legitimacy determination, resource planning and load control: It is impossible to consider terminal type, beam coverage, service time period, communication topology, uplink and downlink subband relationship and subband gain requirements in the same process, resulting in low resource utilization, slow response speed and difficulty in meeting the rapid planning requirements of high bandwidth, multi-port and mixed topology scenarios.

[0007] 3. Lack of differentiated constraint handling mechanism between fixed and roaming services: The existing solution cannot simultaneously support the coverage beam constraints of fixed terminals and the allowed beam set switching constraints of roaming terminals within the same planning framework, resulting in the inability to automatically re-trigger resource planning when the terminal migrates in roaming scenarios.

[0008] 4. Lack of a unified processing framework for pre-allocation and on-demand allocation: The two allocation modes are handled by different modules or manual processes, making it impossible to generate the advance betting time for pre-allocation and the instant activation result for on-demand allocation within the same process. Summary of the Invention

[0009] Existing technologies suffer from problems such as the lack of an automatic mapping mechanism between service-side fields and payload-side structured parameters, and the decoupling of service validity determination and resource planning, leading to the inability to coordinate multi-dimensional resource planning. Therefore, this invention aims to provide a method for service requirement analysis and automatic resource planning for digital payload satellite communication systems. This method achieves unified access, unified verification, unified modeling, and unified planning for multiple types of service requirements, automatically converting terminal service requests into inputs recognizable by resource allocation algorithms, and jointly outputting frequency allocation, bandwidth allocation, subband switching relationships, and subband gain allocation results within the same process, thereby improving the efficiency of digital payload resource scheduling and resource utilization.

[0010] More specifically, the present invention provides a method for service requirement analysis and automatic resource planning for digital payload satellite communication systems, comprising:

[0011] S1, Receive service requests: Receive user service requests through terminal emulation software, network management system or service platform. The service request includes at least terminal identifier, user type, service type, communication object, start and end time, bandwidth requirement, terminal location, allowed beam set, communication method and pre-allocated or on-demand allocated identifier.

[0012] S2, Perform legality verification: Based on the access authentication relationship table, terminal identity information and beam coverage relationship, perform network access verification, location verification and service type verification on the user terminal;

[0013] S3, Execution Scenario Identification and Requirement Decomposition: Based on user type and business direction, the business is automatically identified as a fixed point-to-point, fixed internet access, roaming point-to-point, or roaming internet access scenario; for composite businesses, it is decomposed into multiple sub-requirements that can be solved independently, and a unique identifier is generated for each sub-requirement;

[0014] S4, Execution Requirements Standardization: Convert the original business fields into a unified payload resource requirement description, which includes at least uplink beam, downlink beam, start and end time, required bandwidth, priority, service continuity strategy, communication mode, allowed switchable beam set and link quality constraints.

[0015] S5, Execute rule mapping: According to the preset mapping rules, the load resource requirement description is converted into resource allocation algorithm input parameters. The resource allocation algorithm input parameters include at least port identifier, sub-band granularity, frequency band range, directional relationship constraint, exchange relationship candidate set and gain requirement constraint.

[0016] S6, Automatic Resource Planning: Based on the current idle resources of the payload, service priorities and scenario constraints, automatically generate frequency allocation results, bandwidth allocation results, subband switching relationships and subband gain allocation results;

[0017] S7, Execution Result Feedback: Successful planning results are fed back to the requirement processing result interface and the instruction compilation module respectively; for requirements that fail to be planned, the reason for failure is output.

[0018] S8, Execution Result Maintenance: Tracks the status of business requirements to provide basic data for subsequent remote injection, telemetry consistency verification, and resource recycling.

[0019] Through the above steps, this invention completes the fully automated processing from the original business application to the load resource planning result within the same process. It gradually transforms the unstructured requests on the business side into structured inputs that can be directly called by the resource allocation algorithm, and jointly outputs four types of planning results: frequency, bandwidth, subband switching relationship, and subband gain. This avoids the problem of the separation between resource planning and load control results in traditional solutions.

[0020] Furthermore, in S2, for fixed-line services, services are only allowed to be initiated within the coverage beam corresponding to the application; for roaming services, switching applications are allowed within the pre-declared set of permitted beams. By implementing differentiated beam legitimacy constraints for fixed-line and roaming services, illegal requests can be intercepted during the access phase, avoiding subsequent waste of planning resources.

[0021] Furthermore, in S3, for roaming services, when a terminal migrates to another beam within the allowed beam set, the planning process is re-triggered without changing the service object. This mechanism ensures service continuity by eliminating the need for roaming terminals to re-initiate service requests when switching between beams.

[0022] Furthermore, in S6, for pre-allocated services, an advance betting time is generated simultaneously; for on-demand allocated services, an instant activation result is generated. Integrating pre-allocation and on-demand allocation into the same planning framework supports differentiated processing of services with different timeliness requirements, ensuring that pre-allocated services complete resource locking before starting, and on-demand allocated services immediately enter the activation process after being triggered.

[0023] Furthermore, in S7, the reasons for failure include at least illegal coverage, insufficient resources, time conflicts, port conflicts, and unmet constraints. This clear classification of failure reasons enables operators or upper-level systems to address specific problems, improving fault location efficiency.

[0024] Furthermore, in S8, the status tracking includes tracking and recording service requirements in the allocated, pending, in-use, and released states. This complete service lifecycle status record provides a unified data foundation for subsequent remote control uploading, telemetry consistency verification, and resource reclamation, supporting a complete closed loop for digital payload resource management.

[0025] Furthermore, in S5, the preset mapping rules are established according to the one-to-one correspondence between the business-side description and the load-side description, enabling the resource allocation algorithm to directly call the mapped structured input parameters, eliminating the manual conversion step and ensuring the consistency of parameter interpretation in different scenarios.

[0026] Furthermore, in S4, the requirement standardization transforms business requests with different formats under different business scenarios into a unified load resource requirement description with a consistent structure, eliminating the semantic differences between business-side fields and load-side parameters, and providing standardized intermediate data for subsequent rule mapping and resource planning.

[0027] This invention also provides a service requirement analysis and automatic resource planning system for digital payload satellite communication systems, including a requirement receiving module, a legality verification module, a scene identification module, a requirement standardization module, a rule mapping module, a resource planning module, a result feedback module, and a status maintenance module. The requirement receiving module receives user service applications through terminal simulation software, a network management system, or a service platform, and transmits the service applications to the legality verification module. The legality verification module is data-connected to the requirement receiving module and performs network access verification, location verification, and service type verification on the user terminal based on the access authentication relationship table, terminal identity information, and beam coverage relationship, and transmits the verified service applications to the scene identification module. The scene identification module is data-connected to the legality verification module and identifies services as fixed point-to-point, fixed internet access, roaming point-to-point, or roaming internet access scenarios according to user type and service direction, and decomposes composite services into requirement segments to generate structured sub-requirements. The requirement standardization module is data-connected to the scene identification module and converts the original service fields into a unified... The system comprises the following modules: a payload resource requirement description; a rule mapping module connected to the requirement standardization module, used to convert the payload resource requirement description into input parameters for a resource allocation algorithm according to preset mapping rules; a resource planning module connected to the rule mapping module, used to automatically generate frequency allocation results, bandwidth allocation results, subband switching relationships, and subband gain allocation results by combining current payload idle resources, service priorities, and scenario constraints; a result feedback module connected to the resource planning module, used to send back successful planning results to the requirement processing result interface and instruction compilation module, and output failure reasons for failed planning requirements; and a status maintenance module connected to the result feedback module, used to track the status of service requirements, providing basic data for subsequent remote control uploading, telemetry consistency verification, and resource reclamation. These modules collaborate sequentially to form a complete automated processing chain from the original service request to the payload resource planning result.

[0028] Furthermore, the legitimacy verification module only allows fixed services to be initiated within the coverage beam corresponding to the application, while for roaming services, it allows switching applications within a pre-declared set of allowed beams.

[0029] Furthermore, the resource planning module generates advance betting times for pre-allocated services and instant activation results for on-demand allocated services.

[0030] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method for analyzing service requirements and automatically planning resources for a digital payload satellite communication system.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] 1. By establishing a unified standardized business requirement model and a pre-defined rule mapping mechanism, the business requirement processing process, which originally relied on manual judgment and translation, is automated and standardized. This fundamentally eliminates the problems of inconsistent field interpretation, missing parameters, and manual secondary entry errors caused by the lack of stable mapping between business-side fields and load-side parameters, and significantly reduces the manual involvement between business acceptance and resource planning.

[0033] 2. By completing access authentication, beam coverage verification, scene identification, and demand decomposition within the same process, the originally decoupled business legality determination, resource planning, and load control are integrated into a unified processing link, avoiding the efficiency loss caused by manual determination across systems. This enables the system to simultaneously consider terminal type, beam coverage, service time period, communication topology, uplink and downlink subband relationship, and subband gain requirements, thereby improving the overall response speed and resource utilization.

[0034] 3. By jointly outputting frequency allocation results, bandwidth allocation results, subband switching relationships, and subband gain allocation results, the problem of the separation between resource planning and load control results in traditional schemes is avoided. At the same time, it supports unified planning for four typical scenarios: fixed point-to-point, fixed Internet access, roaming point-to-point, and roaming Internet access. It is compatible with star networks, mesh networks, and hybrid topologies, and has good scalability for high-bandwidth, multi-port digital load systems. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of the present invention, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0036] Figure 1 This is a flowchart illustrating a service requirement analysis and automatic resource planning method for a digital payload satellite communication system according to an embodiment of the present invention.

[0037] Figure 2 A schematic diagram illustrating the business requirement access and standardization process for business requirement analysis and automatic resource planning methods.

[0038] Figure 3 This is a schematic diagram illustrating the scene identification and classification of fixed-line and roaming services.

[0039] Figure 4 A schematic diagram illustrating the relationship between input parameters for the resource allocation algorithm.

[0040] Figure 5 Output a schematic diagram of the joint planning results.

[0041] Figure 6 This is a structural diagram of a service requirement analysis and automatic resource planning system for digital payload satellite communication systems according to an embodiment of the present invention;

[0042] Figure 7 This is a structural diagram of an electronic device provided according to an embodiment of the present invention. Detailed Implementation

[0043] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0044] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0045] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0046] This application relates to the automated parsing and resource planning of service requirements in a digital payload satellite communication system. Addressing the inefficiencies in existing technologies due to the lack of a stable mapping mechanism between service-side fields and payload-side parameters, and the decoupling of service validity determination and resource planning, this application establishes a unified requirement standardization model and rule mapping mechanism. This enables the entire process—from initial service application access, validity verification, scenario identification and requirement decomposition, requirement standardization, rule mapping to automatic resource planning—to be completed within the same workflow. It also jointly outputs frequency allocation results, bandwidth allocation results, subband switching relationships, and subband gain allocation results, providing a unified data foundation for subsequent remote control uploading and resource reclamation.

[0047] In this application, DTP refers to Digital Transparent Processor, which is the core processing unit of a digital payload satellite communication system, used to realize subband-level switching and subband-level gain control; pre-allocation refers to the allocation method in which resources are locked and remote control prepared in advance before the service starts, and the advance allocation time needs to be generated at the same time during planning; on-demand allocation refers to the allocation method in which resources are activated immediately when the service is triggered, and the activation process begins immediately after planning; beam coverage verification refers to the process of determining whether the service is legal based on the terminal location, access identifier, and accessible beam relationship.

[0048] I. System Overall Architecture

[0049] In one implementation, reference Figure 1 and Figure 6 The business requirement analysis and automatic resource planning system provided in this application consists of a requirement receiving module 101, a legality verification module 102, a scene recognition module 103, a requirement standardization module 104, a rule mapping module 105, a resource planning module 106, a result feedback module 107, and a status maintenance module 108 connected in sequence, forming a complete automated processing link from the original business application to the load resource planning result.

[0050] The demand receiving module is the entry point of the entire processing chain. It receives user service applications from terminal simulation software, network management systems, or service platforms. These applications include at least terminal identifier, user type, service type, communication object, start and end time, bandwidth requirements, terminal location, allowed beam set, communication method, and pre-allocated or on-demand allocated identifiers. This application data is then completely transmitted to the legitimacy verification module. Upon receiving the service application from the demand receiving module, the legitimacy verification module performs network access verification, location verification, and service type verification on the user terminal based on a pre-maintained access authentication relationship table, terminal identity information, and beam coverage relationship. Successful applications are transmitted to the scenario identification module, while failed applications receive a direct return of the failure reason. After receiving a legitimate service application, the scenario identification module identifies the service as one of four scenarios based on user type and service direction: fixed point-to-point, fixed internet access, roaming point-to-point, or roaming internet access. It then decomposes the composite service into requirements, generating a unique identifier for each sub-requirement, and subsequently transmits the structured sub-requirements to the demand standardization module. The demand standardization module converts the original service fields into a unified payload resource requirement description and outputs it to the rule mapping module. The rule mapping module converts standardized descriptions into input parameters for the resource allocation algorithm according to preset mapping rules and passes them to the resource planning module. The resource planning module completes the planning by combining the current idle resources of the load, business priorities, and scenario constraints. The output planning results are pushed to the requirement processing result interface and the instruction compilation module by the result feedback module, while the status maintenance module performs full lifecycle status tracking of business requirements.

[0051] The requirement receiving module is responsible for receiving user service applications through terminal simulation software, network management systems, or business platforms, and passing the application data to the legality verification module. After verification, the legality verification module passes the legitimate service to the scenario identification module. After identification and segmentation, the scenario identification module passes the structured sub-requirements to the requirement standardization module. The requirement standardization module outputs a standardized description, which is then converted into algorithm input parameters by the rule mapping module. The resource planning module completes the planning based on the algorithm input parameters, and the results are pushed to the interface and instruction compilation modules by the result feedback module, while the status is tracked by the status maintenance module.

[0052] II. Detailed Explanation of Each Step of the Method

[0053] Reference Figure 2 Step S1 involves receiving service requests. The request receiving module receives user service applications through terminal simulation software, a network management system, or a service platform. The service application includes at least the terminal identifier, user type, service type, communication target, start and end times, bandwidth requirements, terminal location, allowed beam set, communication method, and a pre-allocated or on-demand allocation identifier. The terminal identifier is used to uniquely identify the terminal device initiating the application during subsequent verification and planning stages; the user type distinguishes between fixed users and roaming users, directly determining the scene identification branch in step S3; and the pre-allocated or on-demand allocation identifier indicates the generation method of the resource allocation result in step S6. The request receiving module stores the above fields in a structured format and then passes them to the legality verification module.

[0054] Step S2 involves performing a legality check. The legality check module takes the service application passed in step S1 as input and, based on the access authentication relationship table, terminal identity information, and beam coverage relationship, sequentially performs network access verification, location verification, and service type verification on the user terminal. Network access verification determines whether the terminal identifier is registered in the access authentication relationship table; location verification determines the legality of the beam the terminal is in based on the terminal's location and beam coverage relationship; service type verification confirms that the requested service type matches the terminal's permissions. For fixed services, only services within the coverage beam corresponding to the application are allowed; applications outside the coverage beam are rejected, and the result feedback module outputs the reason "coverage invalid." For roaming services, switching applications are allowed within a pre-declared set of allowed beams; the legality check module confirms whether the terminal's current beam is within the allowed beam set based on the terminal's current location information. After all three checks pass, the legality check module passes the service application to the scene recognition module.

[0055] Reference Figure 3Step S3 involves scenario identification and requirement decomposition. The scenario identification module takes the service application from the legality verification module as input and automatically identifies the service into four scenarios based on user type and service direction: fixed point-to-point scenario (bidirectional communication between fixed users, with beam coverage remaining unchanged throughout the service lifecycle); fixed internet access scenario (one-way or two-way communication for fixed users accessing the internet via a gateway station); roaming point-to-point scenario (communication between roaming users and fixed users or other roaming users, allowing beam switching within the allowed beam set); and roaming internet access scenario (communication for roaming users accessing the internet via a gateway station). For composite services, the scenario identification module decomposes them into multiple independently solvable sub-requirements and generates a unique identifier for each sub-requirement, enabling independent planning and status tracking for subsequent steps. For roaming services, when a terminal migrates to another beam within the allowed beam set, the scenario identification module can re-trigger the planning process of steps S3 to S6 without changing the service object, updating the resource planning results of the corresponding beam to ensure service continuity.

[0056] Step S4 is to standardize the execution requirements. The requirement standardization module takes the structured sub-requirements output by the scenario recognition module as input and converts the original business fields into a unified payload resource requirement description. The payload resource requirement description includes at least uplink beams, downlink beams, start and end times, required bandwidth, priority, service continuity strategy, communication mode, allowed switchable beam set, and link quality constraints. Business requests with different formats under different business scenarios are uniformly converted into a consistent intermediate description after being processed by the requirement standardization module, eliminating the semantic differences between business-side fields and payload-side parameters, and providing standardized intermediate data for subsequent rule mapping and resource planning. The requirement standardization module then passes the above payload resource requirement description to the rule mapping module.

[0057] Reference Figure 4Step S5 involves executing rule mapping. The rule mapping module takes the load resource requirement description output by the requirement standardization module as input and further converts it into resource allocation algorithm input parameters according to preset mapping rules. These preset mapping rules are established based on a one-to-one correspondence between the service-side description and the load-side description, enabling the resource allocation algorithm to directly call the mapped structured input parameters, eliminating manual conversion and ensuring consistent parameter interpretation across different scenarios. The resource allocation algorithm input parameters include at least port identifiers, subband granularity, frequency band range, directional relationship constraints, candidate set of switching relationships, and gain requirement constraints. Specifically, the port identifier corresponds to the physical or logical port accessed by the terminal; the subband granularity refers to the smallest frequency unit for resource allocation; the frequency band range refers to the frequency interval available for allocation; the directional relationship constraint refers to the directional pairing requirements between uplink and downlink subbands; the candidate set of switching relationships refers to the set of optional subband switching paths that satisfy the topology constraints; and the gain requirement constraint refers to the target range requirement of the service link for subband gain. The rule mapping module then passes these input parameters to the resource planning module.

[0058] Reference Figure 5 Step S6 involves executing automatic resource planning. The resource planning module takes the algorithm input parameters output by the rule mapping module as input, and combines them with the current idle load resources, service priorities, and scenario constraints to automatically generate frequency allocation results, bandwidth allocation results, subband switching relationships, and subband gain allocation results. For pre-allocated services, after planning the above four types of results, the resource planning module simultaneously generates an advance betting time to ensure that resources are locked before the service begins, providing a time reference for subsequent remote betting. For on-demand allocated services, the resource planning module generates instant activation results, supporting immediate entry into the activation process after service triggering. The resource planning module simultaneously outputs four types of planning results: frequency, bandwidth, subband switching relationships, and subband gain, avoiding the problem of separation between resource planning and load control results in traditional solutions. The planning results are then passed to the result feedback module.

[0059] Step S7 involves sending back the execution results. The result feedback module takes the planning results output by the resource planning module as input and sends back successful planning results to both the requirement processing result interface and the instruction compilation module. This allows operators to view the planning details and the instruction compilation module to generate subsequent remote control upload instructions. For requirements that fail to plan, the result feedback module outputs the failure reason, which includes at least illegal coverage, insufficient resources, time conflicts, port conflicts, and unmet constraints. This enables operators or upper-level systems to address specific failure types, improving fault location efficiency. The result feedback module also notifies the status maintenance module of the planning result status.

[0060] Step S8 is for maintaining the execution results. The status maintenance module, triggered by notifications from the result feedback module, tracks the status of business requirements. This status tracking includes recording business requirements in the allocated, pending, in-use, and released states, forming a complete business lifecycle record. The allocated state indicates successful planning but not yet deployed; the pending deployment state indicates that the pre-allocated business has been planned and is waiting for remote deployment to be triggered at the pre-deployment time; the in-use state indicates that the business has been activated and is in the communication process; and the released state indicates that the business has ended or the resources have been reclaimed. The status tracking results provide basic data for subsequent remote deployment, telemetry consistency verification, and resource reclamation, supporting a complete closed loop for digital payload resource management.

[0061] The present invention will be further described below with reference to embodiments.

[0062] Example 1: Fixed Point-to-Point Pre-allocation Scenario

[0063] Terminal A and Terminal B are both fixed users, located within the coverage areas of uplink beam 1 (return) and downlink beam 3 (forward), respectively. They requested a 20MHz point-to-point service between 10:00 and 12:00 on the same day, using a pre-allocation method. The request receiving module receives the service request at 09:55 and stores the structured data including terminal identifier, user type (fixed), service type (point-to-point), start and end time (10:00 to 12:00), bandwidth requirement (20MHz), terminal location, and pre-allocation identifier before passing it to the legitimacy verification module. Based on the access authentication relationship table and beam coverage relationship, the legitimacy verification module confirms that Terminal A is within the coverage area of ​​beam 1 and Terminal B is within the coverage area of ​​beam 3. With all three verifications passed, the service request is passed to the scene identification module. The scene identification module identifies the service as a fixed point-to-point scenario based on the user type (fixed) and service direction (bidirectional point-to-point), and directly passes it to the request standardization module without needing to break down the sub-requirements. The demand standardization module converts the original fields into a payload resource demand description, generating a standardized description including uplink beam 1, downlink beam 3, start and end times from 10:00 to 12:00, and a required bandwidth of 20MHz, which is then passed to the rule mapping module. The rule mapping module, according to preset mapping rules, maps the 20MHz bandwidth demand into 8 sub-band demands with a sub-band granularity of 2.5MHz, generating corresponding port identifiers, candidate sets of switching relationships, and gain demand constraints, which are then passed to the resource planning module. The resource planning module, considering the current available payload resources, completes the planning, outputting the uplink and downlink sub-band switching relationships and gain allocation results for the 8 sub-bands, and simultaneously generating the advance betting time. The result feedback module pushes the planning results to the demand processing result interface and the instruction compilation module. The status maintenance module records the service as "pending betting".

[0064] Example 2: Roaming Point-to-Point On-Demand Allocation Scenarios

[0065] Mobile terminal E is allowed to roam within beams 5, 6, and 7, while fixed terminal B is located within beam 2. It initiates a 10MHz on-demand point-to-point service request. After receiving the service request, the demand receiving module passes fields such as user type (roaming), allowed beam sets (beams 5, 6, and 7), and the terminal's current location to the legitimacy verification module. The legitimacy verification module confirms that terminal E is within beam 6 of the allowed beam set based on its current location information. If the verification passes, the service request is passed to the scene recognition module. The scene recognition module identifies the service as a roaming point-to-point scenario based on the user type (roaming) and service direction, generates a unique service identifier, and passes the structured sub-requirements to the demand standardization module. The demand standardization module generates a standardized payload resource requirement description containing uplink beam 6, downlink beam 2, and a required bandwidth of 10MHz, and passes it to the rule mapping module. The rule mapping module generates four sub-band requirements and corresponding algorithm input parameters at a sub-band granularity of 2.5MHz and passes them to the resource planning module. The resource planning module automatically generates the switching relationships and gain planning results for the four sub-bands, generates immediate activation results, and immediately enters the activation process. The result feedback module pushes the planning results to the instruction compilation module. The status maintenance module records the service as "allocated". When terminal E migrates to beam 7, the scene recognition module re-triggers steps S3 to S6 without changing the service object. The demand standardization module updates the uplink beam to beam 7, the rule mapping module regenerates the algorithm input parameters, the resource planning module outputs the sub-band switching relationships and gain allocation corresponding to beam 7, and the result feedback module pushes the updated planning results to the instruction compilation module, achieving seamless service continuation after roaming handover.

[0066] Example 3: Fixed Internet Access on-demand Allocation Scenario

[0067] Fixed user D is located within the uplink beam 4, targeting gateway station beam G1, and requests 30MHz internet access service using an on-demand allocation method. After receiving the service request, the demand receiving module transmits the user type (fixed), service type (internet access), terminal location (beam 4), communication target (gateway station G1), bandwidth requirement (30MHz), and on-demand allocation identifier to the legitimacy verification module. The legitimacy verification module confirms that terminal D is within the coverage area of ​​beam 4, passes the verification, and transmits the service request to the scenario identification module. The scenario identification module identifies the service as a fixed internet access scenario based on the user type (fixed) and service direction (user terminal to gateway station), and transmits it to the demand standardization module. The demand standardization module automatically establishes a one-way or two-way resource description from user terminal D to gateway station G1, generating a standardized payload resource requirement description including uplink beam 4, downlink beam G1, and the required bandwidth of 30MHz, and transmits it to the rule mapping module. The rule mapping module maps the 30MHz bandwidth requirement into 12 sub-band requirements with a sub-band granularity of 2.5MHz, generating port identifiers, candidate sets of switching relationships, and gain requirement constraints for both the gateway and user sides, and then passes these to the resource planning module. The resource planning module completes resource planning for the 12 sub-bands, outputting the sub-band switching relationships and gain allocation results, and generating immediate activation results. The result feedback module pushes the planning results to the requirement processing result interface and the instruction compilation module for subsequent activation. The status maintenance module records the service as "allocated."

[0068] This application also provides a computer-readable storage medium storing a computer program thereon. The computer-readable storage medium can be a non-volatile storage medium, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. When the computer program is executed by a processor, the processor calls the program code in the storage medium to sequentially implement steps S1 to S8 of the above method: In step S1, the processor receives service application data from terminal simulation software, a network management system, or a service platform through a corresponding interface and completes structured parsing; In step S2, the processor reads the access authentication relationship table and beam coverage relationship data, performs network access verification, location verification, and service type verification on the terminal, and performs differentiated beam legality judgment based on the type of fixed service or roaming service; In step S3, the processor completes scenario classification based on user type and service direction, performs requirement splitting on composite services, and generates a unique sub-requirement identifier; In step S4, the processor converts the original service fields into a structurally consistent load resource requirement description; In step S5, the processor... According to the preset mapping rules, the processor generates algorithm input parameters including port identifier, sub-band granularity, frequency band range, directional relationship constraints, candidate set of switching relationships, and gain requirement constraints. When executing step S6, the processor combines the current idle resources of the load and the service priority to complete automatic resource planning, output frequency allocation results, bandwidth allocation results, sub-band switching relationships, and sub-band gain allocation results, and generates advance betting time or immediate activation results according to the pre-allocation or on-demand allocation identifier. When executing step S7, the processor sends the planning results back to the demand processing result interface and instruction compilation module, and outputs the failure reason for the demand that failed to be planned. When executing step S8, the processor tracks and records the status of the service demand, maintains the status data of allocated, pending betting, in use, and released, and provides basic data for subsequent remote betting, telemetry consistency verification, and resource reclamation.

[0069] like Figure 7 As shown, the present invention also provides an electronic device, including a processor 301 and a memory 302 connected to the processor 301. The memory 302 stores a plurality of instructions, which can be loaded and executed by the processor to enable the processor to perform the method of the present invention.

[0070] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; 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 or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for service requirement analysis and automatic resource planning for digital payload satellite communication systems, characterized in that, include: S1, Receive service requests: Receive user service requests through terminal emulation software, network management system or service platform. The service request includes at least terminal identifier, user type, service type, communication object, start and end time, bandwidth requirement, terminal location, allowed beam set, communication method and pre-allocated or on-demand allocated identifier. S2, Perform legality verification: Based on the access authentication relationship table, terminal identity information and beam coverage relationship, perform network access verification, location verification and service type verification on the user terminal; S3, Execution Scenario Identification and Requirement Decomposition: Based on user type and business direction, the business is automatically identified as a fixed point-to-point, fixed internet access, roaming point-to-point, or roaming internet access scenario; for composite businesses, it is decomposed into multiple sub-requirements that can be solved independently, and a unique identifier is generated for each sub-requirement; S4, Execution Requirements Standardization: Convert the original business fields into a unified payload resource requirement description, which includes at least uplink beam, downlink beam, start and end time, required bandwidth, priority, service continuity strategy, communication mode, allowed switchable beam set and link quality constraints. S5, Execute rule mapping: According to the preset mapping rules, the load resource requirement description is converted into resource allocation algorithm input parameters. The resource allocation algorithm input parameters include at least port identifier, sub-band granularity, frequency band range, directional relationship constraint, exchange relationship candidate set and gain requirement constraint. S6, Automatic Resource Planning: Based on the current idle resources of the payload, service priorities and scenario constraints, automatically generate frequency allocation results, bandwidth allocation results, subband switching relationships and subband gain allocation results; S7, Execution Result Feedback: The successful planning results are fed back to the requirement processing result interface and the instruction compilation module respectively; For requests where planning fails, output the reasons for the failure; as well as S8, Execution Result Maintenance: Tracks the status of business requirements to provide basic data for subsequent remote injection, telemetry consistency verification, and resource recycling.

2. The method according to claim 1, characterized in that, In S2, for fixed services, services can only be initiated within the coverage beam corresponding to the application; for roaming services, applications can be switched within the pre-declared set of allowed beams.

3. The method according to claim 1, characterized in that, In S3, for roaming services, when a terminal migrates to another beam within the allowed beam set, the planning process is retried without changing the service object.

4. The method according to claim 1, characterized in that, In S6, for pre-allocated services, an advance betting time is generated simultaneously; for on-demand allocated services, an instant activation result is generated.

5. The method according to claim 1, characterized in that, In S7, the reasons for failure include at least illegal coverage, insufficient resources, time conflict, port conflict, and constraint failure.

6. The method according to claim 1, characterized in that, In S8, the status tracking includes tracking and recording business requirements in the states of allocated, pending, in use, and released.

7. The method according to claim 1, characterized in that, In S5, the preset mapping rules are established according to the one-to-one correspondence between the service-side description and the load-side description, so that the resource allocation algorithm can directly call the mapped structured input parameters.

8. The method according to claim 1, characterized in that, In S4, the requirement standardization transforms business requests with different formats under different business scenarios into a unified load resource requirement description with a consistent structure, eliminating the semantic differences between business-side fields and load-side parameters.

9. A service requirement analysis and automatic resource planning system for digital payload satellite communication systems, characterized in that, include: The demand receiving module is used to receive user service requests through terminal emulation software, network management system or service platform, and pass the service requests to the legality verification module. The legality verification module is connected to the request receiving module and is used to perform network access verification, location verification and service type verification on the user terminal based on the access authentication relationship table, terminal identity information and beam coverage relationship, and to pass the verified service application to the scene recognition module. The scene recognition module is connected to the legality verification module and is used to identify the service as a fixed point-to-point, fixed Internet access, roaming point-to-point or roaming Internet access scenario according to the user type and business direction, and to decompose the composite service into requirements to generate structured sub-requirements. The requirement standardization module is connected to the scene recognition module and is used to convert the original business fields into a unified load resource requirement description. The rule mapping module is data-connected to the demand standardization module and is used to convert the load resource demand description into resource allocation algorithm input parameters according to preset mapping rules. The resource planning module is data-connected to the rule mapping module and is used to automatically generate frequency allocation results, bandwidth allocation results, subband switching relationships, and subband gain allocation results by combining the current idle resources of the payload, service priorities, and scenario constraints. The result feedback module is connected to the resource planning module and is used to send the successful planning results back to the requirement processing result interface and the instruction compilation module, and to output the failure reason for the failed planning requirements. The status maintenance module is connected to the result feedback module and is used to track the status of business requirements, providing basic data for subsequent remote injection, telemetry consistency verification and resource recycling.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the service requirement analysis and automatic resource planning method for a digital payload satellite communication system as described in any one of claims 1 to 8.

Images