Satellite communication method and system
By using the Data Distribution Service (DDS) topical communication mechanism and decentralized service discovery, the problems of lightweight, low latency, and high reliability of the SBA architecture in the spaceborne core network are solved, realizing efficient and reliable communication and intelligent operation and maintenance of the spaceborne core network.
Patent Information
- Application Number
- CN202511884918.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-15
- Publication Date
- 2026-01-13
- Estimated Expiration
- 2045-12-15
AI Technical Summary
The existing 3GPP 5G core network service architecture (SBA) is difficult to meet the requirements of lightweight, low latency, high reliability and autonomous operation and maintenance in spaceborne core networks and 6G integrated air-space-ground networks. It faces problems such as protocol stack redundancy, high latency, lack of reliability guarantee mechanism, logical coupling, high operation and maintenance complexity and weak distributed collaboration capability.
It adopts the Data Distribution Service (DDS) topical communication mechanism, obtains the Quality of Service (QoS) policy through DDS topics, realizes parallel data distribution, introduces decentralized service discovery and native load balancing, supports multiple communication modes, and enhances dynamic scheduling and edge collaboration capabilities.
It provides robust reliability assurance, reduces latency and operational complexity, supports efficient communication and intelligent elastic scaling in spaceborne environments, and meets the lightweight and low-latency requirements of spaceborne core networks.
Smart Images

Figure CN121334776A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of data processing, and in particular to a satellite communication method and system. BACKGROUND
[0002] The current 3GPP 5G core network adopts a service-based architecture (SBA), and the interface (SBI) is implemented based on the HTTP / 2 / JSON protocol. Although this architecture realizes the softwareization and partial decoupling of network element functions, its design is initially intended for a ground fixed data center environment. When directly applied to a satellite core network such as a 5G non-terrestrial network (5G-NTN) or as a core component of a 6G space-air-ground integrated network, its inherent defects are dramatically magnified under the extreme constraints of the satellite platform: the satellite platform is limited by strict size, weight, power consumption, and other constraints, and is continuously exposed to harsh space environments such as high-energy particle radiation, single event upset (SEU), and severe temperature fluctuations, while having extremely stringent requirements for processing latency on the satellite (the end-to-end service latency often needs to be ≤10-20 ms).
[0003] Therefore, the existing SBA architecture is difficult to meet the urgent needs of future satellite core networks for lightweight, low latency, high reliability, and autonomous operation and maintenance, and an innovative communication architecture paradigm is urgently needed. SUMMARY
[0004] Therefore, the present application aims to solve the technical problem of providing a satellite communication method, device, electronic equipment, computer readable storage medium, and computer program product to solve the problem that the existing SBA architecture is difficult to meet the urgent needs of future satellite core networks for lightweight, low latency, high reliability, and autonomous operation and maintenance.
[0005] To solve the above technical problems, one aspect of an embodiment of the present application provides a satellite communication method, the method comprising: obtaining a data object of a terminal; regarding the data object as a specified microservice instance in an application layer of a core network, obtaining a corresponding data distribution service (DDS) topic according to the specified microservice instance; obtaining a corresponding quality of service (QoS) policy according to the DDS topic; obtaining a subscriber microservice instance subscribed to the DDS topic according to the DDS topic; distributing the data object to the subscriber microservice instance in parallel according to the QoS policy.
[0006] Optionally, before acquiring the corresponding quality of service (QoS) policy according to the data distribution service (DDS) topic, a corresponding quality of service (QoS) policy is preconfigured for each data distribution service (DDS) topic, including: configuring the RELIABLE mode for critical signaling; and / or, configuring the BEST_EFFORT mode for non-critical data; and / or, configuring the TRANSIENT_LOCAL mode for state topics; and / or, setting a time limit for topics with high real-time requirements, and triggering an alarm or compensation mechanism when the time limit is exceeded.
[0007] Optionally, the method further includes: listening to a specific business state topic by a subscriber microservice instance to obtain business state data, wherein the business state data is obtained according to at least one of the following data: session number of all network terminals, traffic load, satellite ephemeris and switching preannouncement; triggering the elastic scaling of the microservice instance according to the business state data.
[0008] Another aspect of the embodiment of the application also provides another satellite communication method, which includes: accessing a spaceborne network through an air interface and sending request information; wherein the request information includes a data object; the spaceborne network takes the data object as a specified microservice instance in an application layer of a core network, acquires a corresponding data distribution service (DDS) topic according to the specified microservice instance, acquires a corresponding quality of service (QoS) policy according to the data distribution service (DDS) topic, acquires a subscriber microservice instance that subscribes to the data distribution service (DDS) topic according to the data distribution service (DDS) topic, and distributes the data object to the subscriber microservice instance in parallel according to the quality of service (QoS) policy; receiving response information of the request information from the subscriber microservice instance.
[0009] Still another aspect of the embodiment of the application also provides a satellite communication system, which includes: an application layer and a middleware layer; wherein the application layer includes a plurality of microservice instances, each of which is internally integrated with a data distribution service (DDS) client library, the DDS client library is an interface for data interaction between the microservice instance and the middleware layer, and is responsible for serializing business data of an application program into data distribution service (DDS) data samples and publishing or subscribing to receive; and the middleware layer provides a unified communication bus for the plurality of microservice instances; The middleware layer comprises a control API; wherein the control API is configured to obtain a corresponding quality of service (QoS) policy according to a data distribution service (DDS) topic; the DDS topic is obtained according to a specified microservice instance corresponding to a data object received from a terminal; the middleware layer obtains a subscriber microservice instance subscribed to the DDS topic according to the DDS topic, and distributes the data object to the subscriber microservice instance in parallel according to the QoS policy.
[0010] Optionally, the control API is configured to obtain a corresponding quality of service (QoS) policy according to a data distribution service (DDS) topic comprises: configuring a RELIABLE mode for critical signaling; and / or, configuring a BEST_EFFORT mode for non-critical data; and / or, configuring a TRANSIENT_LOCAL mode for state topics; and / or, setting a time limit for topics with high real-time requirements, and triggering an alarm or compensation mechanism if the time limit is exceeded.
[0011] Optionally, a plurality of microservice instances publish the same data distribution service (DDS) topic, and a plurality of microservice instances receive the same DDS topic; or a plurality of microservice instances publish the same DDS topic, and a plurality of microservice instances receive a plurality of DDS topics; or a plurality of microservice instances publish a plurality of DDS topics, and a plurality of microservice instances receive the same DDS topic; or a plurality of microservice instances publish a plurality of DDS topics, and a plurality of microservice instances receive a plurality of DDS topics.
[0012] Optionally, the subscriber microservice instance listens to a specific business state topic to obtain business state data; wherein the business state data is obtained according to at least one of the following data: session number, traffic load, satellite ephemeris, and switching pre-warning of all network terminals; and the business state data triggers the elastic scaling of the microservice instance.
[0013] Optionally, the middleware layer is implemented by a DDS built in a ROS 2 framework.
[0014] Optionally, the middleware layer is linked to each microservice instance in the form of a library; or the middleware layer is deployed in the same Pod as the microservice instance container as a Sidecar container.
[0015] Optionally, the subscriber microservice instance is an independent external service as a business state-aware scheduler; or the core awareness logic of the subscriber microservice instance is implemented in the form of a Kubernetes Operator.
[0016] Optionally, the middleware layer includes a topic management module; wherein the topic management module is responsible for the life cycle management and semantic analysis of all data topics.
[0017] Optionally, the middleware layer includes a global data space; wherein the global data space is the logical basis for realizing decentralized many-to-many communication.
[0018] Optionally, the middleware layer includes QoS policy management; wherein the QoS policy management is used to obtain a corresponding quality of service (QoS) policy according to a data distribution service (DDS) topic.
[0019] Optionally, the middleware layer includes a dynamic discovery module.
[0020] Optionally, the application layer includes at least one of the following: an access management microservice, a session management microservice, a forwarding management microservice, a security management microservice, and an intelligent microservice.
[0021] Still another aspect of the embodiment of the application further provides a satellite communication device applied to a microservice system of a satellite core network, the device comprising: a first obtaining module configured to obtain a data object of a terminal; a second obtaining module configured to obtain a corresponding data distribution service (DDS) topic according to a specified microservice instance in an application layer of a core network by taking the data object as the specified microservice instance; a third obtaining module configured to obtain a corresponding quality of service (QoS) policy according to the DDS topic; a fourth obtaining module configured to obtain a subscriber microservice instance that subscribes to the DDS topic according to the DDS topic; a distribution module configured to distribute the data object to the subscriber microservice instance in parallel according to the QoS policy.
[0022] Optionally, the device further comprises: a configuration module configured to pre-configure a corresponding QoS policy for each DDS topic before obtaining the corresponding QoS policy according to the DDS topic, including: configuring a RELIABLE mode for critical signaling; and / or, configuring a BEST_EFFORT mode for non-critical data; and / or, configuring the TRANSIENT_LOCAL mode for the state topic; and / or, setting a time limit for the topic with high real-time requirement, and triggering an alarm or compensation mechanism when the time limit is exceeded.
[0023] Optionally, the apparatus further comprises: a listening module configured to listen to a specific business state topic through a subscriber micro-service instance to obtain business state data, wherein the business state data is obtained according to at least one of the following data: session number of terminals in the whole network, traffic load, satellite ephemeris and switch pre-warning; a triggering module configured to trigger the micro-service instance to perform elastic scaling according to the business state data.
[0024] In still another aspect of the embodiments of the present application, a satellite communication apparatus is provided, which is applied to a terminal, and the apparatus comprises: a sending module configured to access a spaceborne network through an air interface and send request information, wherein the request information comprises a data object; the spaceborne network takes the data object as a specified micro-service instance in an application layer of a core network, obtains a data distribution service (DDS) topic corresponding to the specified micro-service instance, obtains a quality of service (QoS) policy corresponding to the DDS topic, obtains a subscriber micro-service instance subscribed to the DDS topic, and distributes the data object to the subscriber micro-service instance in parallel according to the QoS policy; a processing module configured to trigger corresponding business logic to perform processing independently and in parallel through the subscriber micro-service instances.
[0025] Optionally, the processing module is configured to perform at least one of the following: an SMF instance processes user plane path pre-establishment of a target spaceborne UPF; a PCF instance processes verification and update of a switching strategy; a UDM instance processes update of user service satellite information.
[0026] In still another aspect of the embodiments of the present application, an electronic device is provided, which comprises: a processor; and a memory storing a program, wherein the program comprises instructions which, when executed by the processor, cause the processor to perform the satellite communication method according to any one of the above.
[0027] In still another aspect of the embodiments of the present application, a non-transitory computer readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform the satellite communication method according to any one of the above.
[0028] Still another aspect of the embodiments of the present application provides a computer program product, which comprises instructions, when the instructions are executed, causing a computer to perform the satellite communication method according to any one of the above.
[0029] By the satellite communication method, the data object of the terminal is acquired, the data object is taken as a specified micro-service instance in an application layer of a core network, a corresponding data distribution service (DDS) topic is acquired according to the specified micro-service instance, a corresponding quality of service (QoS) policy is acquired according to the data distribution service (DDS) topic, a subscriber micro-service instance subscribed to the data distribution service (DDS) topic is acquired according to the data distribution service (DDS) topic, and the data object is distributed to the subscriber micro-service instance in parallel according to the quality of service (QoS) policy. The method solves the problem that the existing SBA architecture is difficult to meet the requirements of lightweight, low delay, high reliability and autonomous operation and maintenance of a future on-board core network.
[0030] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the scope of the application claimed. BRIEF DESCRIPTION OF DRAWINGS
[0031] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0032] Figure 1 The flowchart of the satellite communication method provided by the embodiments of the present application.
[0033] Figure 2 The flowchart of another satellite communication method provided by the embodiments of the present application.
[0034] Figure 3 The overall schematic diagram of the satellite communication system architecture provided by the embodiments of the present application.
[0035] Figure 4 The overall schematic diagram of another satellite communication system architecture provided by the embodiments of the present application.
[0036] Figure 5 The schematic diagram of the satellite communication device provided by the embodiments of the present application.
[0037] Figure 6 The schematic diagram of another satellite communication device provided by the embodiments of the present application.
[0038] 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 DESCRIPTION
[0039] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly explain the spirit of the present application with the aid of the drawings and detailed description. Any person skilled in the art can make changes and modifications to the technology taught by the present application without departing from the spirit and scope of the present application.
[0040] The schematic embodiments of the present application and the descriptions thereof are used to explain the present application but are not as limitations of the present application. In addition, the same or similar reference numerals are used to represent the same or similar parts in the drawings and embodiments.
[0041] As to the "first", "second", and the like used herein, they do not particularly mean the order or sequence, nor are used to limit the present application. They are merely used to distinguish elements or operations described by the same technical terms.
[0042] As to the directional terms used herein, such as "upper", "lower", "left", "right", "front", or "back", they are merely reference directions of the drawings. Therefore, the directional terms used are used to explain but not to limit the present creation.
[0043] As to the "comprise", "include", "have", "contain", and the like used herein, they are all open terms, that is, they mean comprising but not limited to.
[0044] As to the "and / or" used herein, it includes any or all combinations of the described things.
[0045] As to the "plurality" herein, it includes "two" and "more than two"; as to the "multiple groups" herein, it includes "two groups" and "more than two groups".
[0046] As to the phrases "substantially", "about", and the like used herein, they are used to modify any quantity or error that can be slightly changed, but the slight changes or errors do not change the nature. Generally, the slight changes or errors modified by such phrases can be 20% in some embodiments, 10% in some embodiments, 5% or other values in some embodiments. Those skilled in the art should understand that the aforementioned values can be adjusted according to actual needs and are not limited thereto.
[0047] All terms used herein, including technical and scientific terms, have the meanings as commonly understood by one of ordinary skill in the art unless otherwise defined. It should be further noted that the use of terms such as "first", "second" and the like can be used in this disclosure to describe various elements, but such elements should not be limited by these terms. Such terms can be used interchangeably with appropriate terminologies and are not intended to be signifi cantly limiting.
[0048] In the event a usage similar to "at least one of A, B, and C, etc." is used in the description, it will be understood that such phrasing is used merely for readability and that the term "comprising" will be understood to to encompass the presence of at least one of A, B, and C, etc., but not excluding likewise the presence of only A or an "and / or", that is, permitting a presence of only A or only B or only C. In the event such an "and / or" is used in the description, it will be understood that it is used only for readability, that it does not dictate how to interpret the term "comprising" - that it will be understood to encompass the presence of A or B or C or the presence of A and B or A and C or B and C or A and B and C or, vice versa, and so forth.
[0049] When the service-based architecture SBA of 3GPP 5G core network is directly applied to the spaceborne core network (such as 5G-NTN) or as a core component of 6G space-ground integration network, the traditional SBA architecture exposes the following core bottlenecks: 1) Protocol stack redundancy, poor spaceborne adaptability: The HTTP / 2 protocol stack and its dependent TCP / TLS layer are multi-layer, large header overhead, significant calculation and memory consumption, which is difficult to meet the extreme energy efficiency ratio requirements of spaceborne computing resource limited platform.
[0050] 2) Large latency and overhead in request-response mode: The SBI synchronous request-reply paradigm and cumbersome handshake, serialization / deserialization process introduce significant delay. Its service discovery relies heavily on centralized network elements such as Network Repository Function (NRF), increasing the signaling interaction path and failure points.
[0051] 3) Lack of reliability assurance mechanism: HTTP / 2 lacks native, fine-grained Quality of Service (QoS) control capabilities (such as reliability, persistence, deadline monitoring), making it difficult to effectively deal with the interruption of inter-satellite laser links, bit errors, packet loss or service instance instantaneous outage caused by single particle disturbance, and the system-level fault tolerance and self-healing capability is insufficient.
[0052] 4) Logical coupling, limited flexibility: Service consumers (Consumers) must explicitly address producers (Producers) through domain names (FQDNs) or IP addresses, resulting in topological coupling between network elements, limiting the true independent deployment, seamless replacement and elastic scaling capabilities of microservices.
[0053] 5) High operation complexity: In the scenario of low-orbit constellation dynamic networking and continuously changing network topology, service dependency management based on IP and DNS becomes extremely complex, and ground operation personnel need to frequently manually configure or rely on complex automation scripts, which is prone to errors.
[0054] 6) Weak distributed collaboration capability: The centralized service registration and discovery mechanism is difficult to support low-latency and high-dynamic direct communication and collaboration between on-board edge nodes, and cannot effectively support advanced applications such as on-board AI and distributed routing calculation that require efficient state synchronization.
[0055] In order to solve the above technical problems brought by the application of the traditional SBA architecture to the on-board core network (such as 5G-NTN) or as a core component of 6G space-ground integration network, the embodiments of the present application provide a satellite communication method, as shown in Figure 1 The method comprises the following steps: Step S102: Obtain the data object of the terminal. The data object conforms to the definition of the 3GPP standard message, for example, it can be a registration request (including initial registration, periodic registration and mobility registration update), a session management message (including establishment, modification and release) and a handover message (such as N2 handover and Xn handover) and the like.
[0056] Step S104: Take the above data object as a specified microservice instance in the core network application layer, and obtain the corresponding data distribution service (DDS) topic according to the specified microservice instance.
[0057] Step S106: Obtain the corresponding quality of service (QoS) policy according to the data distribution service (DDS) topic. Specifically, in an optional embodiment, the RELIABLE mode is configured for critical signaling (such as a handover command) to ensure that it is always delivered and improve the reliability of information transmission; the BEST_EFFORT mode is configured for non-critical data to reduce overhead; the TRANSIENT_LOCAL mode is configured for a state topic to allow a new online service instance to automatically obtain the latest state data and achieve rapid recovery; a time limit is set for a topic with high real-time requirements, and if the time limit is exceeded, an alarm or compensation mechanism is triggered. Liveliness: automatically detect faulty nodes and remove them from the system. Specifically, critical signaling: refers to signaling procedures that are absolutely necessary for establishing, maintaining, and releasing a PDU session (user data connection). If these signaling procedures fail, it will directly result in the user being unable to access the network, unable to obtain services, or services being interrupted abnormally. They constitute the "skeleton" of session management. Non-critical signaling: refers to signaling procedures used to optimize, enhance, or provide additional services. Their failure usually does not result in the interruption of core services (such as Internet access), but may affect user experience, policy implementation, or specific service functions. State topics are defined according to the needs of the core network, such as the need to monitor system load conditions (including network element service index load, traffic load, etc.), for example, / system / load, / NF / load. Liveliness mainly refers to the relationship between the DDS-managed topics (subscriptions and publications). To maintain the relationship between the subscribers and publishers, DDS needs to more accurately and quickly perceive the state of the subscribers or publishers (which can be understood as DDS checking the state through a link checking mechanism and sending a survival state at regular intervals), and update the subscription and publication relationship maintained by DDS according to the state (this relationship is completed through subscription registration in the module initialization stage).
[0058] Through this step, a series of DDS topics (Topic) corresponding to core network business events and signaling are defined (for example: / session_management / establish_request, / location_update). Each topic is pre-configured with rich quality of service (QoS) policies.
[0059] Step S108: Obtain the subscriber microservice instance subscribed to the data distribution service (DDS) topic according to the data distribution service (DDS) topic. Step S110: Distribute the data object to the subscriber microservice instance in parallel according to the quality of service (QoS) policy.
[0060] Through the above steps, the differentiated communication mechanism of the subject and the QoS policy is provided, strong reliability guarantee is provided, the problems that HTTP / 2 lacks native and fine-grained quality of service (QoS) control capability, and it is difficult to effectively cope with the bit error, message loss or service instance instantaneous interruption caused by the inter-satellite laser link interruption and single particle disturbance, and the system-level fault tolerance and self-healing capability are insufficient. The optional embodiment has a strong, configurable reliability transmission and fault recovery mechanism, which improves the robustness and survivability of the system in the space environment. Through the QoS policy, differentiated transmission guarantee is provided for different business data, effectively coping with the on-board link interruption and data error. At the same time, the rich QoS policy optimizes the transmission process, which helps to reduce the delay and control overhead, and meets the millisecond real-time requirement of on-board processing. The subject communication makes the operation and maintenance only need to manage the subject policy, without configuring IP address and port, greatly simplifying the operation and maintenance, greatly simplifying the operation and management complexity of the on-board core network, realizing the automation and decentralization of configuration.
[0061] In an optional embodiment, in order to enhance the distributed collaboration capability, decentralized service discovery, native load balancing and multiple communication modes are introduced to enhance the dynamic scheduling and edge collaboration capability. Specifically, the subscriber microservice instance listens to a specific business state subject to obtain business state data; wherein the business state data is obtained according to at least one of the following data: session number, traffic load, satellite ephemeris and switching forecast of the entire network terminal; the elastic expansion and contraction of the microservice instance is triggered according to the business state data. As a more specific implementation, a customized scheduler is designed, which itself acts as a subscriber to listen to specific business state subjects (such as / system / load, / NF / load) to obtain business-level indicators such as the number of sessions, traffic load, satellite ephemeris and switching forecast of the entire network. The scheduler makes decisions based on these business state data (rather than traditional CPU / memory indicators) and triggers the elastic expansion and contraction of the microservice through the virtualization platform API. After the new microservice instance starts, it automatically joins the system through the dynamic discovery mechanism built into DDS and starts communication. Thus, the problem that the distributed collaboration capability of the traditional SBA architecture is weak, and the centralized service registration and discovery mechanism is difficult to support low-latency and high-dynamic direct communication and collaboration between on-board edge nodes, and cannot effectively support advanced applications such as on-board AI and distributed routing calculation that require efficient state synchronization is solved. Through sensing the business state, the scheduler can predictively adjust the resources before satellite switching or business surge, solving the hysteresis problem of traditional resource monitoring and scheduling, and realizing the intelligent elastic expansion and contraction of “business unawareness and service unawareness”.
[0062] The embodiment of the application also provides another satellite communication method, which is applied to a user terminal, such asFigure 2 As shown, the method comprises the following steps: Step S202: Access the spaceborne network through the air interface and send request information; wherein the request information comprises a data object; wherein the data object at least comprises a terminal identifier, a target satellite identifier ID, and an event timestamp; the spaceborne network takes the data object as a specified microservice instance in a core network application layer, acquires a corresponding data distribution service DDS topic according to the specified microservice instance, acquires a corresponding quality of service QoS policy according to the data distribution service DDS topic, acquires a subscriber microservice instance that subscribes to the data distribution service DDS topic according to the data distribution service DDS topic, and distributes the data object to the subscriber microservice instance in parallel according to the quality of service QoS policy; Step S204: Receive response information to the request information from the subscriber microservice instance.
[0063] The optional embodiment has a powerful, configurable, reliable transmission and fault recovery mechanism built in the microservice system of the spaceborne core network connected with the user terminal, improves the robustness and survivability of the system in the space environment, provides differentiated transmission guarantee for different business data through the QoS policy, effectively deals with spaceborne link interruption and data errors. At the same time, the rich QoS policy optimizes the transmission process, helps to reduce the delay and control overhead, and meets the millisecond-level real-time requirement of on-board processing. The subject communication makes it only necessary to manage the subject policy for operation and maintenance, without the need to configure IP addresses and ports, greatly simplifies the operation and maintenance, greatly simplifies the operation and management complexity of the spaceborne core network, and realizes the automation and decentralization of configuration.
[0064] The embodiment of the application also provides a satellite communication system, which comprises the spaceborne network and the user terminal. Figure 3As shown, the satellite communication system includes an application layer and a middleware layer. The application layer includes a plurality of lightweight microservice instances implementing 5G / 6G core network functions, such as an Access and Mobility Management Function (AMF) microservice, a Session Management Function (SMF) microservice, and the like. Each microservice instance internally integrates a Data Distribution Service (DDS) client library, which is an interface for the microservice instance to interact with the middleware layer for data, responsible for serializing the business data (such as SBI messages, PFCP session messages) of the application into DDS data samples and publishing or subscribing to receive, realizing the separation of business logic and communication logic. Specifically, the business logic is "domain-specific": for AMF, the business logic is to handle registration, connection, and mobility management; for SMF, the business logic is to manage the life cycle of PDU sessions; for PCF, the business logic is to formulate policies. They do not care how data is passed from one process to another in the network. The communication logic refers to how data is reliably, efficiently, and correctly transmitted in a distributed system. It focuses on "how to do it" and "how to transmit it". In the DDS-based microservice architecture, the communication logic is encapsulated by the DDS client library, specifically including: serialization and deserialization, publish-subscribe model management, underlying transmission, QoS policy execution, and the like.
[0065] The decentralized unified communication middleware layer introduces a communication middleware layer conforming to the data distribution service (DDS) standard to provide a unified communication bus for multiple microservice instances, i.e., a unique communication bus for all core network microservices (such as AMF, SMF, UPF, etc.). The middleware layer acquires, according to a data distribution service DDS topic, a subscriber microservice instance subscribed to the data distribution service DDS topic, and distributes the data object to the subscriber microservice instance in parallel according to the quality of service QoS policy. All service interactions, including signaling, state updates, and user plane events, are performed through this plane in the publish / subscribe (Publish-Subscribe) and request / response (Request-Reply) modes, completely abandoning IP address and HTTP / 2-based calls. The existing technology solves the problem that the service consumer (Consumer) must explicitly address the producer (Producer) through the domain name (FQDN) or IP address, resulting in topology coupling between network elements, limiting the independent deployment, seamless replacement, and elastic scaling capabilities of microservices. Through the optional embodiment, the service does not need to know the network location of the other party, and only needs to focus on the data content, realizing the complete decoupling and "anonymous communication" between microservices, supporting the plug-and-play and seamless elastic scaling of services. At the same time, the lightweight characteristics of the DDS protocol reduce the computing power and power consumption overhead, solving the problem that the HTTP / 2 protocol stack and its dependent TCP / TLS layer are multi-layered, have large header overhead, and consume significant computing and memory, which is difficult to meet the extreme energy efficiency ratio requirements of the limited computing resources on the satellite platform.
[0066] As Figure 3 And Figure 4As shown, 100: spaceborne core network lightweight microservice system; 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, the control API is used to obtain the corresponding quality of service QoS policy according to the data distribution service DDS topic, and the service state sensing scheduling is perceived; the data distribution service DDS topic is obtained according to the specified microservice instance corresponding to the data object received from the terminal; wherein the data object at least includes terminal identifier, target satellite identifier ID, event timestamp; 105: topic management module (Topic Management, new), responsible for the life cycle management and semantic analysis of all data topics; 106: global data space, which is the logical basis for realizing decentralized many-to-many communication; 107: QoS policy management (QoS Policy Engine), which is the core of the present optional embodiment, realizes differentiated communication guarantee through a set of configurable policies, and the QoS policy management is used to obtain the corresponding quality of service QoS policy according to the data distribution service DDS topic; 108: dynamic discovery module.
[0067] Through the satellite communication system of the present optional embodiment, a unified communication middleware layer of data-centric, topic-based, quality of service (QoS) policy and decentralized real-time communication is constructed to replace the traditional service-based architecture (SBA) based on HTTP / 2. The middleware layer provides a unified communication abstraction for all core network microservices (such as lightweight AMF, SMF, UPF, etc.), and directly solves various challenges faced in the spaceborne environment through its built-in rich mechanisms.
[0068] In one optional embodiment, the control API is used to obtain the corresponding quality of service QoS policy according to the data distribution service DDS topic, including: configuring the RELIABLE mode for critical signaling (such as handover command), ensuring that it must be reached, and improving the reliability of information transmission; configuring the BEST_EFFORT mode for non-critical data to reduce overhead; configuring the TRANSIENT_LOCAL mode for state topics to allow new online service instances to automatically obtain the latest state data and realize quick recovery; setting a time limit for topics with high real-time requirements, and triggering an alarm or compensation mechanism if the time limit is exceeded. Liveliness: automatically detect faulty nodes and remove them from the system.
[0069] To realize the new paradigm of many-to-many high concurrency communication, in an 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 another optional embodiment, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive the same DDS topic; and in another optional embodiment, multiple microservice instances publish multiple DDS topics, and multiple microservice instances receive multiple DDS topics. The publish / subscribe model adopted by many-to-many communication is essentially many-to-many (M:N), and 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 mode plays a crucial role: First, it allows 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), Unified Data Management (UDM), etc., greatly improving system throughput and reducing latency; second, it supports efficient event broadcasting and notification, providing natural support for network function collaboration and state synchronization, enhancing distributed capabilities.
[0070] In an optional embodiment, to enhance the distributed collaboration capability, decentralized service discovery, native load balancing and multi-communication mode are introduced to enhance the dynamic scheduling and edge collaboration capability. Specifically, a subscriber microservice instance listens to a specific business state topic to obtain business state data; wherein the business state data is obtained according to data of at least one of the following: session number, traffic load, satellite ephemeris and switching forecast of all network terminals; the elastic scaling of the microservice instance is triggered according to the business state data. As a more specific implementation, a custom scheduler is designed, which itself acts as a subscriber to listen to specific business state topics (such as / system / load, / NF / load) to obtain business-level indicators such as all-network user session number, traffic load, satellite ephemeris and switching forecast. The scheduler makes decisions based on these business state data (rather than traditional CPU / memory indicators) and triggers the elastic scaling of microservices through virtualization platform API. After the new microservice instance is started, it automatically joins the system and starts communication through the built-in dynamic discovery mechanism of DDS, thereby solving the problem of weak distributed collaboration capability of traditional SBA architecture, the difficulty of centralized service registration and discovery mechanism to support low-latency and high-dynamic direct communication and collaboration between on-board edge nodes, and the inability to effectively support advanced applications such as on-board AI and distributed routing calculation that require efficient state synchronization; by sensing the business state, the scheduler can predictively adjust resources before satellite switching or business surge, solving the problem of hysteresis of traditional resource monitoring and scheduling, and realizing intelligent elastic scaling with "no business awareness and no service awareness".
[0071] Regarding the implementation of the middleware layer, in an optional embodiment, the middleware layer can be implemented through the built-in DDS (such as Fast DDS, Cyclone DDS) of the ROS 2 framework, and in another optional embodiment, through a commercial-grade DDS implementation (such as RTI Connext DDS).
[0072] Optionally, the middleware layer is linked to each microservice instance in the form of a library to pursue extreme lightweight, or it can be deployed in the same Pod as the microservice container as a Sidecar container to pursue multi-language support and isolation.
[0073] Optionally, the business state-aware scheduler (itself as a subscriber microservice instance) is an independent external service as a business state-aware scheduler; or the core perception logic of the business state-aware scheduler (itself as a subscriber microservice instance) is implemented in the form of a Kubernetes Operator, which is more deeply integrated into the infrastructure.
[0074] Optionally, the application layer includes at least one of the following: an access management microservice, a session management microservice, a forwarding management microservice, a security management microservice, and an intelligent microservice.
[0075] In one specific optional embodiment, as shown in Figure 3 and Figure 4 : 1) System composition and deployment: The entire system is deployed on a satellite-borne computing platform, which runs a lightweight cloud-native cluster. Two main types of Pods run in the cluster: ① Core network function Pod: Each Pod contains a core network microservice (e.g., 101) and a DDS routing daemon container (Sidecar mode, not separately marked in the figure). A DDS communication library (e.g., Eclipse Cyclone DDS C++ library) is integrated into the microservice container, which implements interaction with the 103-unified communication middleware layer. ② Management function Pod: Contains management components such as the business state-aware scheduler in 104.
[0076] 2) Initial configuration example: Topic definition: The topic name should have clear semantics, such as / cn / {service type} / {message type}. Core network business topics and their default QoS policies are defined in advance in the DDS middleware through control APIs. For example, create a QoS configuration that supports reliable transmission and persistent history, such as reliable transmission, reserve history data for new subscribers, and deadline policy 50ms: Topic: / cn / session / sm_context_create Data type: SMContextCreateRequest Default QoS: RELIABLE, TRANSIENT_LOCAL, Deadline = 50ms DDS implementation: Optional implementation libraries such as Eclipse CycloneDDS or RTI Connext DDS. CycloneDDS is an open-source, lightweight implementation that is very suitable for satellite-borne environments.
[0077] 3) Communication flow (take user session establishment as an example): Step one: The user terminal accesses the satellite-borne network through the air interface, and the AMF microservice processes the access request.
[0078] Step two: The AMF needs to create a session, and its business logic creates a session creation request data object by calling the local DDS communication library.
[0079] Step three: The DDS communication library publishes this data object as an instance to a pre-defined DDS topic, e.g. / cn-session / sm / establish_request. This topic has been configured with RELIABLE and Deadline QoS policies through 104- control API at system initialization.
[0080] Step four: The 103- Unified Communication Middleware layer automatically discovers all subscribers (i.e. all 101-SMF microservice instances) that subscribe to the / cn-session / sm / establish_request topic based on DDS built-in dynamic discovery mechanism, and delivers this request data reliably to one of them (selected by DDS sophisticated load balancing mechanism (resources, load, specification, etc.).
[0081] Step five: The 101-SMF instance receives the request and processes the session creation logic. After processing, it publishes the session creation response to another topic (e.g. / cn-session / amf / establish_response), and the 101-AMF as a subscriber of this topic will automatically receive the response.
[0082] Throughout the process, both 101-AMF and 101-SMF do not need to know each other's IP address or instance number, achieving complete decoupling.
[0083] 4) Communication flow (take satellite handover event notification as an example): Step one: The 101-AMF microservice serving the onboard core network predicts a handover event for a user terminal (UE), and its business logic generates a HandoverImminent data object containing UE identification, target satellite ID, handover timestamp, etc.
[0084] Step two: The 101-AMF publishes this data object as an instance to a pre-defined DDS topic, e.g. / cn / mobility / handover_imminent, through its local DDS client library. This topic has been configured with BEST_EFFORT and Deadline=20ms QoS policies through control API at system initialization to balance reliability and extreme latency requirements.
[0085] Step three: 103-UCM layer automatically discovers all subscribers (i.e. 101-SMF, PCF, UDM, etc. multiple microservice instances) subscribed to / cn / mobility / handover_imminent topic based on the dynamic discovery mechanism built-in DDS, and reliably distributes the event data to all these subscriber instances in parallel, almost simultaneously.
[0086] Step four: After the DDS client library of the above multiple microservice instances receives the event data, it triggers its business logic for processing independently, in parallel: 101-SMF instance processes the user plane path pre-establishment of target spaceborne UPF.
[0087] 101-PCF instance processes the verification and update of handover strategy.
[0088] 101-UDM instance processes the update of user service satellite information.
[0089] Step five: Microservices that need to feedback the processing results (such as SMF, PCF) publish the processing results to the corresponding response topic (such as / cn / mobility / handover_preparation_result). 101-AMF as a subscriber of the topic will automatically receive and aggregate these results.
[0090] Throughout the process, 101-AMF as an event publisher does not need to know or care how many network elements need to perceive this event, and the subscribers do not need to perceive the existence and state of each other. The DDS middleware ensures efficient, parallel, and reliable distribution of information, and achieves complete decoupling and efficient collaboration between network elements.
[0091] 5) Elastic scaling process: Step one: Each 101-SMF microservice will periodically publish the number of sessions it currently manages to a specific topic, such as / service / smf / load_status.
[0092] Step two: 104-service status perception scheduler subscribes to the / service / smf / load_status topic, so it can perceive the total load of all SMF instances in real time.
[0093] Step three: 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 API of the virtualization platform.
[0094] Step four: After the new pod starts, its internal DDS library automatically registers with the 103-unified communication middleware layer and declares the topics it subscribes and publishes. After that, new session creation requests are automatically partially loaded onto the new instance (this sentence is not smooth).
[0095] In summary, the technical solution solves the six core problems of lightweight, latency, reliability, decoupling, operation and maintenance, and dynamic scheduling that the traditional SBA architecture faces in the application of 6G and satellite core network by introducing the decentralized data plane constructed by DDS / ROS 2, supplemented by QoS strategy and business-aware elastic scheduling, and provides a lightweight micro-service system architecture with high performance, high reliability, and simple operation and maintenance. The following technical effects are achieved: 1) Extremely lightweight and low power consumption: by adopting a lightweight DDS protocol stack and a decentralized architecture, redundant components such as API gateways are eliminated, significantly reducing the computing power and power consumption overhead of the satellite core network. 2) Low latency and high real-time performance: the efficient communication mechanism and rich QoS strategies (such as Deadline) of DDS ensure extremely low transmission latency of critical signaling, meeting the stringent requirement of ≤20ms. 3) High reliability and strong robustness: through QoS strategies such as RELIABLE and TRANSIENT_LOCAL, the system provides built-in, granular fault tolerance and fault recovery capabilities, effectively resisting space environmental interference. 4) Complete decoupling and elastic scaling: the topic-based communication mode realizes complete anonymity of services, and microservices can be truly deployed independently and scaled on demand, greatly improving system flexibility. 5) Simplified and automated operation and maintenance: there is no need for network address configuration between network elements, and operation and maintenance personnel only need to manage topics and QoS strategies, greatly reducing the complexity of operation and maintenance in dynamic satellite networks. 6) Intelligent and fine-grained scheduling: scheduling strategies based on business status rather than resource indicators enable the system to more intelligently and proactively respond to network changes, improving overall resource utilization and service stability. 7) System benefits: laying the foundation for the core architecture of a truly self-operated "intelligent satellite network". The powerful distributed collaboration capability provides strong support for the deployment of 6G frontier applications such as on-board computing, on-orbit AI, and distributed beam management, enhancing the overall competitiveness of China's space-ground integrated network.
[0096] In the present embodiment, a satellite communication device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and contemplated.
[0097] The present embodiment provides a satellite communication device applied to a micro-service system of a satellite core network, such as Figure 5As shown, the device comprises: The first obtaining module 52 is configured to obtain a data object of a terminal, wherein the data object comprises at least a terminal identifier, a target satellite identifier ID, and an event timestamp; The second obtaining module 54 is configured to take the data object as a specified micro-service instance in an application layer of a core network, and obtain a data distribution service DDS topic corresponding to the specified micro-service instance; The third obtaining module 56 is configured to obtain a quality of service QoS policy corresponding to the data distribution service DDS topic; The fourth obtaining module 58 is configured to obtain a subscriber micro-service instance subscribed to the data distribution service DDS topic according to the data distribution service DDS topic; The distribution module 60 is configured to distribute the data object to the subscriber micro-service instance in parallel according to the quality of service QoS policy.
[0098] Optionally, the device further comprises: The configuration module is configured to pre-configure a corresponding quality of service QoS policy for each data distribution service DDS topic before obtaining the corresponding quality of service QoS policy according to the data distribution service DDS topic, comprising: configuring a RELIABLE mode for critical signaling; and / or, configuring a BEST_EFFORT mode for non-critical data; and / or, configuring a TRANSIENT_LOCAL mode for a state topic; and / or, setting a time limit for a topic with high real-time requirement, and triggering an alarm or a compensation mechanism if the time limit is exceeded.
[0099] Optionally, the device further comprises: The listening module is configured to listen to a specific business state topic through a subscriber micro-service instance to obtain business state data, wherein the business state data is obtained according to at least one of the following data: a session number of all network terminals, a traffic load, a satellite ephemeris, and a switching pre-warning; The triggering module is configured to trigger an elastic scaling of the micro-service instance according to the business state data.
[0100] The present application also provides another satellite communication device applied to a terminal, as shown in the following table: Figure 6 As shown, the device comprises: The sending module 62 is configured to access a spaceborne network through an air interface and send request information, wherein the request information comprises a data object, and the data object at least comprises a terminal identifier, a target satellite identifier ID, and an event timestamp; the spaceborne network takes the data object as a specified micro-service instance in an application layer of a core network, acquires a data distribution service DDS topic corresponding to the specified micro-service instance, acquires a quality of service QoS policy corresponding to the data distribution service DDS topic, acquires a subscriber micro-service instance subscribed to the data distribution service DDS topic according to the data distribution service DDS topic, and distributes the data object to the subscriber micro-service instance in parallel according to the quality of service QoS policy. The processing module 64 is configured to trigger corresponding business logic for processing independently and in parallel by the subscriber micro-service instances.
[0101] The processing module 64 is configured to perform at least one of the following: An SMF instance processes user plane path pre-establishment of a target spaceborne UPF. A PCF instance processes checking and updating of a handover policy. A UDM instance processes updating of user service satellite information.
[0102] Further function descriptions of the above modules are the same as those of the corresponding embodiments, and will not be described here.
[0103] The optional embodiment proposes a 6G spaceborne core network micro-service architecture based on a data distribution service (DDS) to construct a decentralized unified data communication plane, to replace a traditional SBA architecture based on HTTP / 2, and fundamentally solve the problems of network element coupling, complex operation and maintenance, and large resource overhead. A mechanism for mapping and binding core network signaling, DDS topics and QoS policies is proposed (for example, configuring RELIABLE and TRANSIENT_LOCAL policies for key signaling), and the built-in capabilities of a communication middleware provide differentiated and highly reliable transmission protection for the spaceborne core network, effectively coping with the special space environment. A method for elastic scheduling based on subscription to core network business state topics (such as load and handover events) is proposed, which breaks through the limitations of traditional scheduling based on CPU / memory indicators only, realizes business-aware and forward-looking fine-grained resource management, and adapts to the dynamic topology of the satellite network. A new mode of core network service interaction centered on data / events is established, and network elements communicate anonymously through topics, completely canceling IP / FQDN-based addressing, greatly simplifying system configuration and operation and maintenance, and realizing complete decoupling of micro-services.
[0104] The exemplary embodiments of this application further provide an electronic device, comprising: at least one processor; and a memory connected with the at least one processor in communication. The memory stores a computer program capable of being executed by the at least one processor, and the computer program, when executed by the at least one processor, is configured to cause the electronic device to perform the method according to the embodiments of this application.
[0105] The exemplary embodiments of this application further provide a non-transitory computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, is configured to cause the computer to perform the method according to the embodiments of this application.
[0106] The exemplary embodiments of this application further provide a computer program product comprising a computer program, wherein the computer program, when executed by a processor of a computer, is configured to cause the computer to perform the method according to the embodiments of this application.
[0107] Reference Figure 7 A block diagram of the structure of an electronic device that can be a server or a client of the present application will now be described, which is an example of a hardware device that can be applied to aspects of the present application. The electronic device is intended to represent a wide variety of digital electronic computer devices such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent a wide variety of mobile devices such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components, their connections, and their functions as shown in the figures, and their functions, are by way of example only, and are not meant to limit implementations of the present disclosure described and / or claimed in this document.
[0108] As Figure 7 shown, the electronic device 700 includes a computing unit 701 that can perform various appropriate actions and processes in accordance with 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. Various programs and data required for the operation of the electronic device 700 can also be stored in the RAM 703. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.
[0109] The various components in the electronic device 700 are connected to the I / O interface 705, including an input unit 706, an output unit 707, a storage unit 708, and a communication unit 709. The input unit 706 can be any type of device capable of inputting information to the electronic device 700, and can receive inputted digital or character information, as well as generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 707 can be any type of device capable of presenting information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 708 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 709 allows the electronic device 700 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a Bluetooth™ device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.
[0110] The computing unit 701 can be various general and / or special purpose processing components having 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 specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 701 performs 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 embodied in a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 700 via the ROM 702 and / or the communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the methods according to embodiments of the present application by any other appropriate means, such as by means of firmware.
[0111] Program code for carrying out methods of the present application can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions / operations specified in the flow charts and / or block diagrams to be implemented. The program code can be entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine or entirely on a remote machine or server.
[0112] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable storage medium can include, but are not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.
[0113] As used in the present application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus and / or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal that can be used to provide machine instructions and / or data to a programmable processor.
[0114] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; 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 acoustic, speech, or tactile input.
[0115] The systems and techniques described herein can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described herein, or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.
[0116] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
[0117] Obviously, the above-described embodiments are only illustrative and not restrictive. Based on the above description, other different forms of changes or variations can be made by those skilled in the art. Here, it is not necessary and impossible to enumerate all the embodiments. The obvious changes or variations derived therefrom are still within the protection scope of the present application.
Claims
1. A satellite communication method, characterized in that, The method includes: Get the terminal's data object; The data object is used as a designated microservice instance in the core network application layer, and the corresponding Data Distribution Service (DDS) topic is obtained according to the designated microservice instance. Obtain the corresponding Quality of Service (QoS) policy based on the Data Distribution Service (DDS) topic; Obtain the subscriber microservice instance that has subscribed to the Data Distribution Service (DDS) topic based on the DDS topic; The data objects are distributed in parallel to the subscriber microservice instances according to the Quality of Service (QoS) policy.
2. 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 Quality of Service (QoS) policy.
3. The satellite communication system according to claim 2, characterized in that, 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.
4. The satellite communication system according to claim 2, characterized in that, Multiple microservice instances publish the same Data Distribution Service (DDS) topic, and multiple microservice instances receive the same Data Distribution Service (DDS) topic. Alternatively, multiple microservice instances can publish the same Data Distribution Service (DDS) topic, and multiple microservice instances can receive data from the same multiple DDS topics. Alternatively, multiple microservice instances can publish multiple Data Distribution Service (DDS) topics, and multiple microservice instances can receive the same Data Distribution Service (DDS) topic. Alternatively, multiple microservice instances can publish multiple Data Distribution Service (DDS) topics, and multiple microservice instances can receive multiple Data Distribution Service (DDS) topics.
5. The satellite communication system according to claim 2, characterized in that, 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 microservice instances.
6. The satellite communication system according to claim 2, characterized in that, The middleware layer is implemented using DDS, which is built into the ROS 2 framework.
7. The satellite communication system according to claim 2, 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.
8. The satellite communication system according to claim 5, characterized in that, The subscriber microservice instance is an independent external service that acts as a business state-aware scheduler; or the core awareness logic of the subscriber microservice instance is implemented in the form of a Kubernetes Operator.
9. The satellite communication system according to claim 2, characterized in that, 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.
10. The satellite communication system according to claim 2, 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.
11. The satellite communication system according to claim 2, characterized in that, The middleware layer includes a dynamic discovery module.
12. The satellite communication system according to any one of claims 2 to 11, 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.
Citation Information
Patent Citations
Distributed and container virtualization-based elastic micro-service system and implementation method
CN114422371A
Data fusion system design method and system, electronic equipment and storage medium
CN115580648A
Optimized registration method and system based on micro-service architecture
CN120499260A
Micro-service application management method and device and computer equipment
CN120614396A
Synapse string and synapse string array for neural networks
KR102354286B1