A satellite communication method and system

Abstract

The application provides a satellite communication method and system, the satellite communication method comprises the following steps: obtaining a data object of a terminal; taking the data object as a specified micro-service instance in an application layer of a core network, and obtaining a data distribution service (DDS) topic corresponding to the specified micro-service instance; obtaining a quality of service (QoS) strategy corresponding to the data distribution service (DDS) topic; obtaining a subscriber micro-service instance subscribed to the data distribution service (DDS) topic according to the data distribution service (DDS) topic; and distributing the data object to the subscriber micro-service instance in parallel according to the quality of service (QoS) strategy. Through the method, the problem that the existing SBA architecture cannot meet the requirements of light weight, low delay, high reliability and autonomous operation and maintenance of a future on-board core network is solved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a satellite communication method and system. Background Technology

[0002] The current 3GPP 5G core network adopts a Service-Based Architecture (SBA), and its interface (SBI) is implemented based on the HTTP / 2 / JSON protocol. Although this architecture realizes the software-based functionalities and partial decoupling of network elements, it was originally designed for terrestrial fixed data center environments. When directly applied to spaceborne core networks such as 5G Non-Terrestrial Networks (5G-NTN) or as a core component of 6G integrated space-air-ground networks, its inherent defects are amplified dramatically under the extreme constraints of spaceborne environments: the spaceborne platform is limited by strict constraints on size, weight, and power consumption, and is continuously exposed to harsh space environments such as high-energy particle radiation, single event upsets (SEUs), and severe temperature fluctuations, while also having extremely stringent requirements for onboard processing latency (end-to-end service latency often needs to be ≤10-20ms).

[0003] Therefore, the existing SBA architecture is insufficient to meet the urgent needs of future spaceborne core networks for lightweight, low latency, high reliability, and autonomous operation and maintenance, and an innovative communication architecture paradigm is urgently needed. Summary of the Invention

[0004] In view of this, the technical problem to be solved by the present invention is to provide a satellite communication method, device, electronic device, computer-readable storage medium, and computer program product to solve the problem that the existing SBA architecture is unable to meet the requirements of future spaceborne core networks for lightweight, low latency, high reliability, and autonomous operation and maintenance.

[0005] To address the aforementioned technical problems, one aspect of the present invention provides a satellite communication method, the method comprising:

[0006] Obtain the terminal's data object; use the data object as a specified microservice instance in the core network application layer, and obtain the corresponding Data Distribution Service (DDS) topic based on the specified microservice instance;

[0007] Obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic;

[0008] Obtain the subscriber microservice instance that has subscribed to the Data Distribution Service (DDS) topic based on the DDS topic;

[0009] The data objects are distributed in parallel to the subscriber microservice instances according to the Quality of Service (QoS) policy.

[0010] Optionally, before obtaining the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic, a corresponding QoS policy is pre-configured for each Data Distribution Service (DDS) topic, including:

[0011] Configure RELIABLE mode for critical signaling; and / or,

[0012] Configure BEST_EFFORT mode for non-critical data; and / or,

[0013] Configure the state topic to TRANSIENT_LOCAL mode; and / or,

[0014] Set time limits for topics with high real-time requirements; if the time limit is exceeded, trigger an alarm or compensation mechanism.

[0015] Optionally, the method further includes:

[0016] The microservice instance of the subscriber listens to specific business status topics to obtain business status data; wherein, the business status data is obtained based on at least one of the following: the number of sessions of all terminals on the network, traffic load, satellite ephemeris and handover forecast;

[0017] The microservice instance is elastically scaled up or down based on the business status data.

[0018] In another aspect of the present invention, another satellite communication method is provided, the method comprising:

[0019] The satellite network accesses the onboard network via the air interface and sends a request message, which includes a data object. The onboard network uses the data object as a designated microservice instance in the core network application layer, obtains the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance, obtains the corresponding Quality of Service (QoS) policy based on the DDS topic, obtains subscriber microservice instances that have subscribed to the DDS topic, and distributes the data object to the subscriber microservice instances in parallel according to the QoS policy.

[0020] Receive response information for the request information from the subscriber microservice instance.

[0021] In another aspect, the present invention provides a satellite communication system, the system comprising:

[0022] The system comprises an application layer and a middleware layer. The application layer includes multiple microservice instances, each of which integrates a Data Distribution Service (DDS) client library. The DDS client library serves as the interface between the microservice instance and the middleware layer for data interaction, and is responsible for serializing the application's business data into DDS data samples and publishing or subscribing to them. The middleware layer provides a unified communication bus for the multiple microservice instances.

[0023] The middleware layer includes a control API; wherein the control API is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic; the Data Distribution Service (DDS) topic is obtained based on the specified microservice instance corresponding to the data object received from the terminal; the middleware layer obtains the subscriber microservice instances that have subscribed to the Data Distribution Service (DDS) topic based on the Data Distribution Service (DDS) topic, and distributes the data object to the subscriber microservice instances in parallel according to the Quality of Service (QoS) policy.

[0024] Optionally, the control API is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic, including:

[0025] Configure RELIABLE mode for critical signaling; and / or,

[0026] Configure BEST_EFFORT mode for non-critical data; and / or,

[0027] Configure the state topic to TRANSIENT_LOCAL mode; and / or,

[0028] Set time limits for topics with high real-time requirements; if the time limit is exceeded, trigger an alarm or compensation mechanism.

[0029] Optionally, multiple microservice instances may publish the same Data Distribution Service (DDS) topic and receive the same DDS topic; or, multiple microservice instances may publish the same DDS topic and receive multiple DDS topics; or, multiple microservice instances may publish multiple DDS topics and receive the same DDS topic; or, multiple microservice instances may publish multiple DDS topics and receive multiple DDS topics.

[0030] Optionally, the subscriber microservice instance listens to a specific business status topic to obtain business status data; wherein the business status data is obtained based on at least one of the following: the number of sessions of all terminals on the network, traffic load, satellite ephemeris and handover forecast; the business status data triggers the elastic scaling of the microservice instance.

[0031] Optionally, the middleware layer is implemented using DDS built into the ROS 2 framework.

[0032] Optionally, the middleware layer is linked to each microservice instance as a library; or, the middleware layer is deployed as a Sidecar container in the same Pod as the microservice instance container.

[0033] Optionally, the subscriber microservice instance can be an independent external service serving as a business state-aware scheduler; or the core awareness logic of the subscriber microservice instance can be implemented in the form of a Kubernetes Operator.

[0034] Optionally, the middleware layer includes a topic management module; wherein the topic management module is responsible for the lifecycle management and semantic parsing of all data topics.

[0035] Optionally, the middleware layer includes a global data space; wherein the global data space is the logical foundation for implementing decentralized many-to-many communication.

[0036] Optionally, the middleware layer includes QoS policy management; wherein the QoS policy management is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic.

[0037] Optionally, the middleware layer includes a dynamic discovery module.

[0038] Optionally, the application layer includes at least one of the following: access management microservice, session management microservice, forwarding management microservice, security management microservice, and intelligent microservice.

[0039] In another aspect, the present invention provides a satellite communication device applied to a microservice system of a spaceborne core network, the device comprising:

[0040] The first acquisition module is used to acquire the data object of the terminal; the second acquisition module is used to use the data object as a specified microservice instance in the core network application layer, and to acquire the corresponding data distribution service (DDS) topic according to the specified microservice instance.

[0041] The third acquisition module is used to acquire the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic.

[0042] The fourth acquisition module is used to acquire subscriber microservice instances that have subscribed to the Data Distribution Service (DDS) topic based on the DDS topic.

[0043] The distribution module is used to distribute the data objects in parallel to the subscriber microservice instances according to the Quality of Service (QoS) policy.

[0044] Optionally, the device further includes:

[0045] The configuration module is used to pre-configure a corresponding Quality of Service (QoS) policy for each Data Distribution Service (DDS) topic before obtaining the corresponding QoS policy based on the Data Distribution Service (DDS) topic, including:

[0046] Configure RELIABLE mode for critical signaling; and / or,

[0047] Configure BEST_EFFORT mode for non-critical data; and / or,

[0048] Configure the state topic to TRANSIENT_LOCAL mode; and / or,

[0049] Set time limits for topics with high real-time requirements; if the time limit is exceeded, trigger an alarm or compensation mechanism.

[0050] Optionally, the device further includes:

[0051] The listening module is used to listen to specific business status topics through subscriber microservice instances to obtain business status data; wherein, the business status data is obtained based on at least one of the following: the number of sessions of all terminals on the network, traffic load, satellite ephemeris and handover forecast;

[0052] The triggering module is used to trigger the elastic scaling of microservice instances based on the business status data.

[0053] In another aspect, the present invention provides a satellite communication device applied to a terminal, the device comprising:

[0054] A sending module is used to access the spaceborne network via the air interface and send request information; wherein, the request information includes a data object; the spaceborne network uses the data object as a designated microservice instance in the core network application layer, obtains the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance; obtains the corresponding Quality of Service (QoS) policy based on the DDS topic; obtains subscriber microservice instances that have subscribed to the DDS topic based on the DDS topic; and distributes the data object to the subscriber microservice instances in parallel according to the QoS policy.

[0055] The processing module is used to trigger corresponding business logic independently and in parallel through the subscriber microservice instances.

[0056] Optionally, the processing module is used for at least one of the following:

[0057] SMF instance processing user plane path pre-establishment for target onboard UPF;

[0058] Verification and updating of PCF instance handling switching policies;

[0059] UDM instances handle updates to user service satellite information.

[0060] In another aspect, the present invention provides an electronic device, comprising:

[0061] Processor; and

[0062] Stored program memory,

[0063] The program includes instructions that, when executed by the processor, cause the processor to perform the satellite communication method according to any of the preceding claims.

[0064] In another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute any of the satellite communication methods described above.

[0065] In another aspect of the present invention, a computer program product is provided, the computer program product including instructions that, when executed, cause a computer to perform any of the satellite communication methods described above.

[0066] The aforementioned satellite communication method includes: acquiring a data object from a terminal; using the data object as a designated microservice instance in the core network application layer, and obtaining the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance; obtaining the corresponding Quality of Service (QoS) policy based on the DDS topic; obtaining subscriber microservice instances that have subscribed to the DDS topic based on the DDS topic; and distributing the data object in parallel to the subscriber microservice instances according to the QoS policy. This method solves the problem that the existing SBA architecture cannot meet the future spaceborne core network's requirements for lightweight design, low latency, high reliability, and autonomous operation and maintenance.

[0067] It should be understood that the above general description and the following specific embodiments are merely exemplary and illustrative, and do not limit the scope of the invention. Attached Figure Description

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

[0069] Figure 1 A flowchart of a satellite communication method provided for a specific embodiment of the present invention.

[0070] Figure 2 A flowchart of another satellite communication method provided for a specific embodiment of the present invention.

[0071] Figure 3 This is a schematic diagram of the overall architecture of a satellite communication system provided for a specific embodiment of the present invention.

[0072] Figure 4 This is a schematic diagram of another satellite communication system architecture provided for a specific embodiment of the present invention.

[0073] Figure 5 This is a schematic diagram of a satellite communication device provided for a specific embodiment of the present invention.

[0074] Figure 6 This is a schematic diagram of another satellite communication device provided for a specific embodiment of the present invention.

[0075] Figure 7 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the spirit of the contents disclosed in the present invention will be clearly explained below with reference to the accompanying drawings and detailed description. After understanding the embodiments of the present invention, any person skilled in the art can make changes and modifications based on the technology taught in the present invention without departing from the spirit and scope of the present invention.

[0077] The illustrative embodiments and descriptions of the present invention are used to explain the invention, but are not intended to limit the invention. Furthermore, elements / components using the same or similar reference numerals in the drawings and embodiments are used to represent the same or similar parts.

[0078] The terms "first," "second," etc., used in this document are not intended to specifically refer to order or sequence, nor are they intended to limit the invention. They are merely used to distinguish elements or operations described using the same technical terms.

[0079] The directional terms used in this article, such as up, down, left, right, front, or back, are for reference only when referring to the accompanying drawings. Therefore, the use of directional terms is for illustrative purposes and not for limiting the scope of this work.

[0080] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0081] The term "and / or" as used herein includes any or all of the things mentioned.

[0082] The term "multiple" in this article includes "two" and "more than two"; the term "multiple groups" in this article includes "two groups" and "more than two groups".

[0083] The terms "approximately," "about," etc., used herein are intended to modify any quantity or error that may vary slightly, but these slight variations or errors do not change the essence of the quantity or error. Generally, the range of slight variations or errors modified by such terms may be 20% in some embodiments, 10% in others, 5% in still others, or other values. Those skilled in the art should understand that the aforementioned values ​​can be adjusted according to actual needs and are not limited thereto.

[0084] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0085] When expressions such as "at least one of A, B, and C" are used, they should generally be interpreted in accordance with the meaning commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). When expressions such as "at least one of A, B, or C" are used, they should generally be interpreted in accordance with the meaning commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). A person skilled in the art should also understand that any conjunction and / or phrase that substantially arbitrarily indicates two or more optional items, whether in the specification, claims, or drawings, should be understood to indicate the possibility of including one of these items, either of these items, or both items. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B”, or “A and B”.

[0086] When the Service-Oriented Architecture (SBA) of the 3GPP 5G core network is directly applied to the on-board core network (such as 5G-NTN) or used as a core component of the 6G integrated air-space-ground network, the traditional SBA architecture exposes the following core bottlenecks:

[0087] 1) Redundancy in protocol stack and poor adaptability to space: The HTTP / 2 protocol stack and its dependent TCP / TLS layers are numerous and have large header overhead, resulting in significant computation and memory consumption, which makes it difficult to meet the extreme energy efficiency requirements of space-based computing resource-constrained platforms.

[0088] 2) High latency and overhead in the request-response model: The SBI synchronous request-response paradigm and the cumbersome handshake, serialization / deserialization process introduce significant latency. Its service discovery heavily relies on centralized network elements such as the Network Repository Function (NRF), increasing signaling interaction paths and points of failure.

[0089] 3) Lack of reliability assurance mechanisms: HTTP / 2 lacks native, fine-grained Quality of Service (QoS) control capabilities (such as reliability, durability, and deadline monitoring), making it difficult to effectively cope with inter-satellite laser link interruptions, bit errors caused by single-event disturbances, packet loss, or service instance interruptions, resulting in insufficient system-level fault tolerance and self-healing capabilities.

[0090] 4) Logical coupling and limited elasticity: Service consumers must explicitly address producers through domain names (FQDN) or IP addresses, resulting in topological coupling between network elements, which limits the true independent deployment, seamless replacement and elastic scaling capabilities of microservices.

[0091] 5) High operational complexity: In scenarios with dynamic networking of low-Earth orbit constellations and continuous changes in network topology, the management of service dependencies based on IP and DNS becomes extremely complex. Ground maintenance personnel need to frequently configure manually or rely on complex automated scripts, which is prone to errors.

[0092] 6) Weak distributed collaboration capabilities: Its centralized service registration and discovery mechanism is unable to support low-latency, highly dynamic direct communication and collaboration between onboard edge nodes, and cannot effectively support advanced applications that require efficient state synchronization, such as onboard AI and distributed routing computation.

[0093] To address the aforementioned technical problems arising from the application of traditional SBA architecture in spaceborne core networks (such as 5G-NTN) or as a core component of 6G integrated space-air-ground networks, embodiments of this invention provide a satellite communication method, such as... Figure 1 As shown, the method includes the following steps:

[0094] Step S102: Obtain the terminal's data object. The data object conforms to the definition of 3GPP standard messages, such as registration requests (including initial registration, periodic registration, and mobility registration updates), session management messages (including establishment, modification, and release), and handover messages (such as N2 handover and Xn handover).

[0095] Step S104: Use the above data object as a designated microservice instance in the core network application layer, and obtain the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance.

[0096] Step S106: Obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic described above. Specifically, in an optional embodiment, configure RELIABLE mode for critical signaling (such as handover commands) to ensure delivery and improve the reliability of information transmission; configure BEST_EFFORT mode for non-critical data to reduce overhead; configure TRANSIENT_LOCAL mode for status topics to allow newly launched service instances to automatically obtain the latest status data and achieve rapid recovery; set time limits for topics with high real-time requirements, triggering alarms or compensation mechanisms if the timeout occurs. Liveliness: Automatically detect faulty nodes and remove them from the system. Specifically, critical signaling refers to those signaling processes absolutely necessary for establishing, maintaining, and releasing a PDU session (user's data connection). If these signaling processes fail, it will directly result in the user being unable to access the network, unable to obtain services, or the service being abnormally interrupted. They constitute the "skeleton" of session management. Non-critical signaling refers to those signaling processes used to optimize, enhance, or provide additional services. Their failures typically do not cause interruptions to core services (such as internet access), but may affect user experience, policy enforcement, or specific service functions. State topics are defined based on the needs of the core network, such as monitoring system load (including network element service metrics load, traffic load, etc.), e.g., / system / load, / NF / load. Liveness primarily refers to maintaining the subscriber and publisher relationships for topics (subscription and publish) managed by DDS. To more accurately and quickly perceive the status of subscribers or publishers (which can be understood as DDS periodically sending liveness status updates through a link check mechanism), DDS updates the subscription and publish relationships it maintains based on these statuses (this relationship is established through subscription registration during module initialization).

[0097] This step defines a series of DDS topics (e.g., / session_management / establish_request, / location_update) that correspond one-to-one with core network service events and signaling. Rich Quality of Service (QoS) policies are pre-configured for each topic.

[0098] Step S108: Obtain the subscriber microservice instances that have subscribed to the Data Distribution Service DDS topic based on the above-mentioned Data Distribution Service DDS topic;

[0099] Step S110: Distribute the data object in parallel to the subscriber microservice instance according to the above Quality of Service (QoS) policy.

[0100] Through the above steps, a differentiated communication mechanism based on topics and QoS policies is provided, offering robust reliability guarantees. This addresses the shortcomings of HTTP / 2, which lacks native, fine-grained Quality of Service (QoS) control capabilities, making it difficult to effectively handle inter-satellite laser link interruptions, bit errors caused by single-event disturbances, packet loss, or service instance interruptions, and resulting in insufficient system-level fault tolerance and self-healing capabilities. This optional embodiment incorporates a powerful, configurable reliable transmission and fault recovery mechanism, enhancing the system's robustness and survivability in the space environment. QoS policies provide differentiated transmission guarantees for different service data, effectively addressing onboard link interruptions and data errors. Simultaneously, rich QoS policies optimize the transmission process, helping to reduce latency and control overhead, meeting the millisecond-level real-time requirements of onboard processing. Topic-based communication allows operations and maintenance personnel to manage only topic policies, eliminating the need to configure IP addresses and ports, greatly simplifying operations and maintenance and significantly reducing the complexity of onboard core network operations and management, achieving automated and decentralized configuration.

[0101] In one optional embodiment, to enhance distributed collaboration capabilities, decentralized service discovery, native load balancing, and multiple communication modes are introduced to improve dynamic scheduling and edge collaboration capabilities. Specifically, subscriber microservice instances listen to specific business status topics to obtain business status data; this business status data is obtained based on at least one of the following: the number of sessions of all network terminals, traffic load, satellite ephemeris, and handover forecasts; elastic scaling of microservice instances is triggered based on this business status data. As a more specific implementation, a custom scheduler is designed. This scheduler itself acts as a subscriber, listening to specific business status topics (such as / system / load, / NF / load) to obtain business-level metrics such as the number of user sessions of all network terminals, traffic load, satellite ephemeris, and handover forecasts. The scheduler makes decisions based on this business status data (rather than traditional CPU / memory metrics) and triggers elastic scaling of microservices through the virtualization platform API. After a new microservice instance starts, it automatically joins the system and begins communication through the dynamic discovery mechanism built into DDS. This solves the problems of weak distributed collaboration capabilities in traditional SBA architectures, where the centralized service registration and discovery mechanism cannot support low-latency, highly dynamic direct communication and collaboration between onboard edge nodes, and cannot effectively support advanced applications that require efficient state synchronization, such as on-board AI and distributed routing computation. By sensing the business status, the scheduler can predictively adjust resources before satellite switching or business surges, solving the lag problem of traditional resource monitoring and scheduling, and realizing intelligent elastic scaling that is "business-aware and service-aware".

[0102] This invention also provides another satellite communication method, which is applied to a user terminal, such as... Figure 2 As shown, the method includes the following steps:

[0103] Step S202: Access the spaceborne network via the air interface and send a request message; wherein the request message includes a data object; wherein the data object includes at least a terminal identifier, a target satellite identifier ID, and an event timestamp; the spaceborne network uses the data object as a designated microservice instance in the core network application layer, obtains the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance; obtains the corresponding Quality of Service (QoS) policy based on the DDS topic; obtains the subscriber microservice instances that have subscribed to the DDS topic based on the DDS topic; and distributes the data object in parallel to the subscriber microservice instances according to the QoS policy.

[0104] Step S204: Receive the response information for the request information from the subscriber microservice instance.

[0105] This optional embodiment's onboard core network microservice system, connected to the user terminal, incorporates a robust, configurable, reliable transmission and fault recovery mechanism. This enhances the system's robustness and survivability in the space environment. Through QoS policies, it provides differentiated transmission guarantees for different service data, effectively addressing onboard link interruptions and data errors. Simultaneously, rich QoS policies optimize the transmission process, helping to reduce latency and control overhead, meeting the millisecond-level real-time requirements of onboard processing. Thematic communication allows operations and maintenance personnel to manage only thematic policies, eliminating the need to configure IP addresses and ports, greatly simplifying operations and maintenance and significantly reducing the complexity of onboard core network operations and management, achieving automated and decentralized configuration.

[0106] This invention also provides a satellite communication system, such as... Figure 3As shown, this satellite communication system comprises an application layer and a middleware layer. The application layer includes multiple lightweight microservice instances implementing 5G / 6G core network functions, such as the Access and Mobility Management Function (AMF) microservice and the Session Management Function (SMF) microservice. Each microservice instance integrates a Data Distribution Service (DDS) client library, which serves as the interface between the microservice instance and the middleware layer. This library is responsible for serializing application business data (such as SBI messages and PFCP session messages) into DDS data samples and publishing or subscribing to them, thus separating business logic from communication logic. Specifically, the business logic is "domain-specific": for AMF, it handles registration, connection, and mobility management; for SMF, it manages the lifecycle of PDU sessions; and for PCF, it formulates policies. They are not concerned with how data is transferred from one process to another in the network. Communication logic refers to how data is reliably, efficiently, and correctly transmitted in the distributed system. It focuses on "how to do it" and "how to transmit it". In a DDS-based microservice architecture, the communication logic is encapsulated by the DDS client library, which specifically includes: serialization and deserialization, publish-subscribe model management, underlying transmission, QoS policy enforcement, etc.

[0107] A decentralized unified communication middleware layer is introduced, conforming to the Data Distribution Service (DDS) standard. This middleware layer serves as a unified communication bus for multiple microservice instances, acting as the sole communication bus for all core network microservices (such as AMF, SMF, UPF, etc.). This middleware layer retrieves the subscriber microservice instances that have subscribed to a DDS topic and distributes the data object in parallel to these subscriber microservice instances according to the Quality of Service (QoS) policy. All inter-service interactions, including signaling, state updates, and user plane events, are conducted through this plane using a publish-subscribe and request-response model, completely eliminating calls based on IP addresses and HTTP / 2. This solution addresses the problem in existing technologies where service consumers must explicitly address producers via domain names (FQDNs) or IP addresses, leading to topological coupling between network elements and limiting the true independent deployment, seamless replacement, and elastic scaling capabilities of microservices. This optional embodiment eliminates the need for services to know each other's network locations; they only need to focus on data content, achieving complete decoupling and "anonymous communication" between microservices. It supports plug-and-play and seamless elastic scaling of services. Simultaneously, the lightweight nature of the DDS protocol reduces computational and power consumption overhead, resolving the issue of existing technologies where the HTTP / 2 protocol stack and its dependent TCP / TLS layers have multiple layers, large header overhead, and significant computational and memory consumption, making it difficult to meet the extreme energy efficiency requirements of spaceborne computing resource-constrained platforms.

[0108] like Figure 3 and Figure 4As shown, 100: Lightweight microservice system for the onboard core network; 101: Network Function (NF) microservice; 102: DDS Client Library; 103: Unified Communication Middleware Layer (DDS-based data plane), responsible for communication between all microservices; 104: Control API, used to obtain the corresponding Quality of Service (QoS) policy based on the DDS topic of the Data Distribution Service, and to perceive the service status and scheduling; the DDS topic of the Data Distribution Service is obtained based on the specified microservice instance corresponding to the data object received from the terminal; wherein, the data object includes at least the terminal identifier, the target satellite identifier ID, and the event timestamp; 105: Topic Management module (newly added), responsible for the lifecycle management and semantic parsing of all data topics; 106: Global Data Space, which is the logical foundation for realizing decentralized many-to-many communication; 107: QoS Policy Engine, the core of this optional embodiment, which realizes differentiated communication guarantee through configurable policy sets, and is used to obtain the corresponding Quality of Service (QoS) policy based on the DDS topic of the Data Distribution Service; 108: Dynamic Discovery module.

[0109] This optional embodiment of the satellite communication system constructs a unified communication middleware layer for real-time communication that is data-centric, topic-based, based on Quality of Service (QoS) policies, and decentralized, replacing the traditional HTTP / 2-based Service-Based Architecture (SBA). This middleware layer provides a unified communication abstraction for all core network microservices (such as lightweight AMF, SMF, UPF, etc.), directly addressing various challenges faced in the spaceborne environment through its rich built-in mechanisms.

[0110] In one optional embodiment, the control API is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic, including: configuring RELIABLE mode for critical signaling (such as handover commands) to ensure delivery and improve the reliability of information transmission; configuring BEST_EFFORT mode for non-critical data to reduce overhead; configuring TRANSIENT_LOCAL mode for status topics to allow newly launched service instances to automatically obtain the latest status data for rapid recovery; and setting time limits for topics with high real-time requirements, triggering alarms or compensation mechanisms upon timeout. Liveliness: Automatically detects faulty nodes and removes them from the system.

[0111] To achieve a new paradigm of high-concurrency many-to-many communication, in one optional embodiment, multiple microservice instances publish the same Data Distribution Service (DDS) topic, and multiple microservice instances receive the same DDS topic; in another optional embodiment, multiple microservice instances publish the same DDS topic, and multiple microservice instances receive multiple DDS topics; in yet another optional embodiment, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive the same DDS topic; in yet another optional embodiment, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive multiple DDS topics. The publish / subscribe model used in many-to-many communication is essentially many-to-many (M:N), where a topic can be published by any number of publishers and subscribed to by any number of subscribers. The DDS middleware is responsible for efficiently distributing data to all subscribers. The many-to-many communication pattern plays a crucial role:

[0112] First, it allows for parallel processing. For example, a "user location update" event can be received and processed in parallel by multiple network elements such as SMF, Policy Control Function (PCF), and Unified Data Management (UDM), which greatly improves system throughput and reduces latency. Second, it supports efficient event broadcasting and notification, providing natural support for the coordination and state synchronization between network functions and enhancing distributed capabilities.

[0113] In one optional embodiment, to enhance distributed collaboration capabilities, decentralized service discovery, native load balancing, and multiple communication modes are introduced to improve dynamic scheduling and edge collaboration capabilities. Specifically, subscriber microservice instances listen to specific business status topics to obtain business status data; this business status data is obtained based on at least one of the following: the number of sessions of all network terminals, traffic load, satellite ephemeris, and handover forecasts; elastic scaling of microservice instances is triggered based on this business status data. As a more specific implementation, a custom scheduler is designed, which itself acts as a subscriber, listening to specific business status topics (such as / system / load, / NF / load) to obtain business-level metrics such as the number of user sessions of all network terminals, traffic load, satellite ephemeris, and handover forecasts. The scheduler makes decisions based on this business status data (rather than traditional CPU / memory metrics) and triggers elastic scaling of microservices through the virtualization platform API. After a new microservice instance is launched, it automatically joins the system and begins communication through the dynamic discovery mechanism built into DDS. This solves the problem that the traditional SBA architecture has weak distributed collaboration capabilities, and its centralized service registration and discovery mechanism is unable to support low-latency, highly dynamic direct communication and collaboration between onboard edge nodes, thus failing to effectively support advanced applications that require efficient state synchronization, such as on-board AI and distributed routing computation. By sensing the business status, the scheduler can predictively adjust resources before satellite switching or business surges, solving the lag problem of traditional resource monitoring and scheduling, and realizing intelligent elastic scaling that is "business-aware and service-aware".

[0114] Regarding the implementation of the middleware layer, in one alternative embodiment, the middleware layer can be implemented using the DDS built into the ROS 2 framework (such as Fast DDS, Cyclone DDS), and in another alternative embodiment, it can be implemented using a commercial-grade DDS (such as RTI Connext DDS).

[0115] Optionally, the middleware layer can be linked to each microservice instance as a library to achieve extreme lightweight design, or it can be deployed as a Sidecar container in the same Pod as the microservice container to achieve multi-language support and isolation.

[0116] Optionally, the business state-aware scheduler (which itself is a subscriber microservice instance) can be a separate external service; or the core awareness logic of the business state-aware scheduler (which itself is a subscriber microservice instance) can be implemented in the form of a Kubernetes Operator and integrated more deeply into the infrastructure.

[0117] Optionally, the application layer includes at least one of the following: access management microservice, session management microservice, forwarding management microservice, security management microservice, and intelligent microservice.

[0118] In a specific alternative embodiment, such as Figure 3 and Figure 4 As shown:

[0119] 1) System Composition and Deployment: The entire system is deployed on an onboard computing platform, which runs a lightweight cloud-native cluster. Two main types of Pods run within the cluster: ① Core Network Function Pods: Each Pod contains a core network microservice (e.g., 101) and a DDS routing daemon container (Sidecar mode, not separately shown in the diagram). The microservice container integrates a DDS communication library (e.g., the Eclipse Cyclone DDS C++ library), which implements interaction with the 103-unified communication middleware layer. ② Management Function Pods: Contain management components such as the 104 business status-aware scheduler.

[0120] 2) Initial configuration example:

[0121] Topic Definition: Topic names should have clear semantics, such as / cn / {service type} / {message type}. Core network service topics and their default QoS policies are predefined in the DDS middleware via the control API. For example, create a QoS configuration that supports reliable transmission and persistent history, such as reliable transmission, retaining historical data for new subscribers, and a 50ms expiration policy.

[0122] Subject: / cn / session / sm_context_create

[0123] Data type: SMContextCreateRequest

[0124] Default QoS: RELIABLE, TRANSIENT_LOCAL, Deadline=50ms

[0125] DDS Implementation: You can choose from implementation libraries such as Eclipse CycloneDDS or RTI Connext DDS. CycloneDDS is an open-source, lightweight implementation that is well-suited for spaceborne environments.

[0126] 3) Communication process (taking user session establishment as an example):

[0127] Step 1: The user terminal accesses the satellite network via the air interface, and the AMF microservice processes the access request.

[0128] Step 2: AMF needs to create a session. Its business logic creates a request data object by calling the local DDS communication library.

[0129] Step 3: The DDS communication library publishes this data object as an instance to a predefined DDS topic, such as / cn-session / sm / establish_request. This topic has been configured with RELIABLE and Deadline QoS policies via the 104-control API during system initialization.

[0130] Step 4: The 103-Unified Communication Middleware Layer automatically discovers all subscribers (i.e. all 101-SMF microservice instances) that have subscribed to the / cn-session / sm / establish_request topic based on the dynamic discovery mechanism built into DDS, and reliably delivers the request data to one of the instances (selected by DDS's fine-grained load balancing mechanism (resources, load, specifications, etc.)).

[0131] Step 5: After receiving the request, the 101-SMF instance processes the session creation logic. Once completed, it publishes the session creation response to another topic (such as / cn-session / amf / establish_response), and 101-AMF, as a subscriber to this topic, will automatically receive the response.

[0132] Throughout the process, neither 101-AMF nor 101-SMF needs to know the other's IP address or the number of instances, thus achieving complete decoupling.

[0133] 4) Communication process (taking satellite handover event notification as an example):

[0134] Step 1: The 101-AMF microservice serving the onboard core network predicts a user terminal (UE) handover event, and its business logic generates a HandoverImminent data object containing information such as UE identifier, target satellite ID, and handover timestamp.

[0135] Step 2: 101-AMF publishes this data object as an instance to a predefined DDS topic, such as / cn / mobility / handover_imminent, through its local DDS client library. This topic has been configured with a BEST_EFFORT (best effort) and Deadline=20ms (deadline) QoS policy via the control API during system initialization to balance reliability and extreme latency requirements.

[0136] Step 3: The 103-Unified Communications Middleware Layer automatically discovers all subscribers (i.e., multiple microservice instances such as 101-SMF, PCF, UDM, etc.) that have subscribed to the / cn / mobility / handover_imminent topic based on the dynamic discovery mechanism built into DDS, and reliably distributes the event data to all these subscriber instances in parallel and almost simultaneously.

[0137] Step 4: After receiving the event data, the DDS client libraries of the multiple microservice instances mentioned above independently and in parallel trigger their respective business logic for processing:

[0138] 101-SMF instance processing target onboard UPF user plane path pre-establishment.

[0139] Verification and updating of the switching strategy for 101-PCF instances.

[0140] The 101-UDM instance handles updates to user service satellite information.

[0141] Step 5: Microservices that need to provide processing results (such as SMF and PCF) publish their results to the corresponding response topic (such as / cn / mobility / handover_preparation_result). 101-AMF, as a subscriber to this topic, will automatically receive and aggregate these results.

[0142] Throughout the process, 101-AMF, as the event publisher, does not need to know or care how many network elements need to be aware of this event, and subscribers do not need to be aware of each other's existence or state. The DDS middleware ensures efficient, parallel, and reliable distribution of information, achieving complete decoupling and efficient collaboration between network elements.

[0143] 5) Flexible scaling process:

[0144] Step 1: Each 101-SMF microservice periodically publishes the number of sessions it currently manages to a specific topic, such as / service / smf / load_status.

[0145] Step 2: 104 - The business status-aware scheduler subscribes to the / service / smf / load_status topic, so it can perceive the total load of all SMF instances in real time.

[0146] Step 3: When the scheduler finds that the total number of sessions exceeds the preset threshold, it creates a new SMF microservice Pod instance by calling the virtualization platform's API.

[0147] Step 4: After the new Pod starts, its internal DDS library automatically registers with the 103-Unified Communications Middleware Layer and declares the topics it subscribes to and publishes. Afterward, new session creation requests will automatically be partially offloaded to the new instance.

[0148] In summary, this technical solution systematically addresses six core challenges faced by traditional SBA architectures in 6G and spaceborne core network applications: lightweighting, latency, reliability, decoupling, operation and maintenance, and dynamic scheduling. It introduces a decentralized data plane built with DDS / ROS 2, supplemented by QoS policies and service-aware elastic scheduling. This provides a high-performance, highly reliable, and minimally invasive lightweight microservice system architecture. The resulting technical effects are: 1) Extremely lightweight and low power consumption: By adopting a lightweight DDS protocol stack and decentralized architecture, redundant components such as API gateways are eliminated, significantly reducing the computing power and power consumption of the spaceborne core network. 2) Low latency and high real-time performance: DDS's efficient communication mechanism and rich QoS policies (such as Deadline) ensure extremely low transmission latency for critical signaling, meeting the stringent requirement of ≤20ms. 3) High Reliability and Robustness: Through QoS policies such as RELIABLE and TRANSIENT_LOCAL, the system provides built-in, granular fault tolerance and recovery capabilities, effectively resisting interference from the space environment. 4) Complete Decoupling and Elastic Scaling: The topic-based communication mode achieves complete service anonymity, and microservices can be truly deployed independently and scaled on demand, greatly improving system flexibility. 5) Simplified and Automated Operation and Maintenance: No network address configuration is required between network elements; maintenance personnel only need to manage topics and QoS policies, significantly reducing the complexity of operation and maintenance management in dynamic satellite networks. 6) Intelligent and Refined Scheduling: Scheduling strategies based on service status rather than resource indicators enable the system to respond to network changes more intelligently and proactively, improving overall resource utilization and service stability. 7) System Benefits: It lays the core architectural foundation for building a truly autonomous "intelligent satellite network." The powerful distributed collaborative capabilities it provides strongly support the deployment of cutting-edge 6G applications such as on-board computing, on-orbit AI, and distributed beam management, enhancing the overall competitiveness of my country's integrated air-space-ground network.

[0149] This embodiment also provides a satellite communication device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0150] This embodiment provides a satellite communication device applied to a microservice system of a satellite-borne core network, such as... Figure 5As shown, the device includes:

[0151] The first acquisition module 52 is used to acquire the terminal's data object; wherein, the data object includes at least the terminal identifier, the target satellite identifier ID, and the event timestamp;

[0152] The second acquisition module 54 is used to use the data object as a specified microservice instance in the core network application layer, and to obtain the corresponding data distribution service DDS topic based on the specified microservice instance.

[0153] The third acquisition module 56 is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic.

[0154] The fourth acquisition module 58 is used to obtain the subscriber microservice instances that have subscribed to the DDS topic of the data distribution service based on the DDS topic of the data distribution service.

[0155] The distribution module 60 is used to distribute the data object in parallel to the subscriber microservice instance according to the Quality of Service (QoS) policy.

[0156] Optionally, the device further includes:

[0157] The configuration module is used to pre-configure the corresponding Quality of Service (QoS) policy for each Data Distribution Service (DDS) topic before obtaining the corresponding QoS policy based on the DDS topic, including:

[0158] Configure RELIABLE mode for critical signaling; and / or,

[0159] Configure BEST_EFFORT mode for non-critical data; and / or,

[0160] Configure the state topic to TRANSIENT_LOCAL mode; and / or,

[0161] Set time limits for topics with high real-time requirements; if the time limit is exceeded, trigger an alarm or compensation mechanism.

[0162] Optionally, the device also includes:

[0163] The listening module is used to listen to specific business status topics through subscriber microservice instances to obtain business status data; wherein, the business status data is obtained based on at least one of the following: the number of sessions of all terminals on the network, traffic load, satellite ephemeris and handover forecast;

[0164] The trigger module is used to trigger the elastic scaling of microservice instances based on the business status data.

[0165] An optional embodiment of the present invention also provides another satellite communication device, applied to a terminal, such as... Figure 6 As shown, the device includes:

[0166] The sending module 62 is used to access the spaceborne network via the air interface and send request information; wherein, the request information includes a data object; wherein, the data object includes at least a terminal identifier, a target satellite identifier ID, and an event timestamp; the spaceborne network uses the data object as a designated microservice instance in the core network application layer, obtains the corresponding Data Distribution Service (DDS) topic based on the designated microservice instance; obtains the corresponding Quality of Service (QoS) policy based on the DDS topic; obtains the subscriber microservice instances that have subscribed to the DDS topic based on the DDS topic; and distributes the data object in parallel to the subscriber microservice instances according to the QoS policy.

[0167] The processing module 64 is used to trigger corresponding business logic independently and in parallel through the subscriber microservice instances.

[0168] The processing module 64 is used for at least one of the following:

[0169] SMF instance processing user plane path pre-establishment for target onboard UPF;

[0170] Verification and updating of PCF instance handling switching policies;

[0171] UDM instances handle updates to user service satellite information.

[0172] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0173] This optional embodiment proposes a 6G spaceborne core network microservice architecture based on Data Distribution Service (DDS) to build a decentralized unified data communication plane, replacing the traditional HTTP / 2-based SBA architecture. This fundamentally solves the problems of network element coupling, complex operation and maintenance, and high resource overhead. It proposes a mechanism to map and bind core network signaling with DDS topics and QoS policies (e.g., configuring RELIABLE and TRANSIENT_LOCAL policies for critical signaling). Through the built-in capabilities of the communication middleware, it provides differentiated and highly reliable transmission guarantees for the spaceborne core network, effectively coping with the special space environment. It also proposes a method for elastic scheduling based on subscribing to core network service status topics (such as load and handover events), breaking through the limitations of traditional scheduling based solely on CPU / memory metrics. This achieves service-aware, forward-looking, and refined resource management, adapting to the dynamic topology of satellite networks. A new core network service interaction model centered on data / events is established, with network elements communicating anonymously through topics, completely eliminating IP / FQDN-based addressing, greatly simplifying system configuration and operation and maintenance, and achieving complete decoupling of microservices.

[0174] An exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of the present invention.

[0175] An exemplary embodiment of the present invention also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0176] An exemplary embodiment of the present invention also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of the present invention.

[0177] refer to Figure 7The present invention will now describe a structural block diagram of an electronic device that can serve as a server or client of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0178] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0179] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0180] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the music data processing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured by any other suitable means (e.g., by means of firmware) to perform the methods according to embodiments of the present invention.

[0181] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0182] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0183] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0184] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0185] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0186] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0187] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A satellite communication system, characterized in that, The system includes: Application layer, middleware layer; The application layer includes multiple microservice instances, each of which integrates a Data Distribution Service (DDS) client library. The DDS client library is the interface for data interaction between the microservice instance and the middleware layer, responsible for serializing the application's business data into DDS data samples and publishing or subscribing to them. The middleware layer provides a unified communication bus for the multiple microservice instances. The middleware layer includes a control API; wherein the control API is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic; the Data Distribution Service (DDS) topic is obtained based on the specified microservice instance corresponding to the data object received from the terminal; the middleware layer obtains the subscriber microservice instances that have subscribed to the Data Distribution Service (DDS) topic based on the Data Distribution Service (DDS) topic, and distributes the data object to the subscriber microservice instances in parallel according to the QoS policy; The control API is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic, including: Configure RELIABLE mode for critical signaling; and / or, Configure BEST_EFFORT mode for non-critical data; and / or, Configure the state topic to TRANSIENT_LOCAL mode; and / or, Set time limits for topics with high real-time requirements; if the time limit is exceeded, trigger an alarm or compensation mechanism. Multiple microservice instances publish the same Data Distribution Service (DDS) topic, and multiple microservice instances receive the same DDS topic; or, multiple microservice instances publish the same DDS topic, and multiple microservice instances receive multiple DDS topics; or, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive the same DDS topic; or, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive multiple DDS topics. Subscriber microservice instances listen to specific business status topics to obtain business status data; wherein, the business status data is obtained based on at least one of the following: the number of sessions of all terminals on the network, traffic load, satellite ephemeris and handover forecast; the business status data triggers the elastic scaling of the microservice instance; The middleware layer is implemented using DDS built into the ROS 2 framework; The middleware layer includes a topic management module; wherein, the topic management module is responsible for the lifecycle management and semantic parsing of all data topics.

2. The satellite communication system according to claim 1, characterized in that, The middleware layer is linked to each microservice instance as a library; or, the middleware layer is deployed as a Sidecar container in the same Pod as the microservice instance container.

3. The satellite communication system according to claim 1, characterized in that, The subscriber microservice instance is treated as an independent external service, serving as a business state-aware scheduler; or the core awareness logic of the subscriber microservice instance is implemented as a Kubernetes Operator.

4. The satellite communication system according to claim 1, characterized in that, The middleware layer includes QoS policy management; wherein, the QoS policy management is used to obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic.

5. The satellite communication system according to claim 1, characterized in that, The middleware layer includes a dynamic discovery module.

6. The satellite communication system according to any one of claims 1 to 5, characterized in that, The application layer includes at least one of the following: access management microservice, session management microservice, forwarding management microservice, security management microservice, and intelligent microservice.

Images