Near space aerostat communication method, system, electronic device and storage medium

By introducing a publish/subscribe model of a proxy server and the MQTT protocol into the near-space airship, the system complexity and latency issues caused by serial communication of the onboard computer were resolved, achieving efficient data transmission and device expansion, and improving the system's reliability and ease of use.

CN122394631APending Publication Date: 2026-07-14AEROSPACE INFORMATION RES INST CAS

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
AEROSPACE INFORMATION RES INST CAS
Filing Date
2026-04-02
Publication Date
2026-07-14

AI Technical Summary

Technical Problem

Existing near-space airship onboard computers primarily use serial communication, which leads to system complexity, high latency, increased risk of failure, and hinders equipment scalability and lightweight data transmission.

Method used

A publish/subscribe model based on a proxy server is adopted. A two-way bridging channel is established between the onboard proxy server and the ground proxy server to decouple communication between onboard equipment and between the ground and the ground. The MQTT protocol is used for data transmission, and different service quality levels are used to process telemetry and remote control messages.

Benefits of technology

It reduces communication protocol overhead, improves the real-time performance and bandwidth utilization of data transmission, enhances the scalability and ease of use of the system, and reduces the complexity of system integration and maintenance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122394631A_ABST
    Figure CN122394631A_ABST
Patent Text Reader

Abstract

The application provides a near space airship communication method, system, electronic equipment and storage medium, wherein the method comprises the following steps: sending a bridge establishment request to a ground agent server on the ground; receiving a first message published by a first on-board client; the message carries a first message topic; determining a forwarding path of the message based on the first message topic; sending the first message to a second on-board client subscribing to the first message topic based on the local forwarding path; and sending the first message to the ground agent server through a bidirectional bridge channel based on the bridge forwarding path. The on-board agent server can flexibly distribute data within the on-board equipment based on the first message topic of the first message, and can selectively and efficiently transmit key data to the ground through the bridge channel, thereby effectively reducing the overhead of the communication protocol, improving the real-time performance of data transmission and reducing the bandwidth occupation in the bandwidth-limited satellite communication link, and greatly enhancing the scalability of the on-board system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of data communication technology, and in particular to a near-space airship communication method, system, electronic device and storage medium. Background Technology

[0002] Near-space airships are basically composed of a sphere and a pod. Flight test altitudes range from 20km to 100km, and communication with ground systems is achieved via a telemetry and control link. The airship's onboard / sphere-borne equipment typically includes a flight control computer, a shipboard computer, a safety control computer, onboard telemetry and control terminal equipment, and telemetry and control antennas. The telemetry and control antennas are deployed externally, while other equipment is deployed inside the pod. This equipment is used to collect airship information data and transmit it down the telemetry and control link to the ground command and control system, and to receive uplink commands from the ground command and control system via the onboard telemetry and control equipment. Currently, data exchange is mainly conducted using serial communication or UDP (User Datagram Protocol). Both protocols are lengthy, which is not conducive to lightweight data transmission and has drawbacks such as high bandwidth consumption and high latency. In terms of hardware support, since the flight control computer and the ship's computer currently mainly use serial communication, a serial-to-network conversion server is needed on the shipboard equipment to enable data exchange with satellite communication equipment. Serial communication between shipboard equipment is not conducive to the scalability of the equipment. Adding shipboard equipment requires corresponding hardware interfaces, which leads to relatively cumbersome software and hardware modifications.

[0003] Message Queuing Telemetry Transport (MQTT) is a network communication protocol primarily used in Internet of Things (IoT) communication. It boasts advantages such as being lightweight, open, simple, standardized, and easy to implement. It features small code footprint (facilitating implementation in embedded devices), low power consumption, low bandwidth, low latency, and support for publish / subscribe. It is typically used in scenarios with limited computing power and network bandwidth. MQTT operates on top of the TCP / IP (Transmission Control Protocol / Internet Protocol) protocol. The communication system includes three roles: publisher, subscriber, and broker. The communication process consists of three steps: (1) The client (subscriber) sends subscription information to the broker, which includes the subscription topic; (2) The client (publisher) sends data information to the broker, which includes the topic and content; (3) The broker checks its subscription table for users who have subscribed to the corresponding topic. If found, the data is sent to that user.

[0004] However, current onboard computers primarily rely on serial communication. This architecture, when faced with functional expansion needs, increases network complexity and the number of communication interfaces with the addition of new computers, reducing system scalability and ease of use. Furthermore, current data transmission primarily uses serial or UDP communication protocols, both of which have verbose data packet formats, resulting in low transmission efficiency, high bandwidth consumption, and high latency, hindering lightweight data transmission. At the hardware support level, the dominance of serial communication also necessitates that onboard equipment rely on serial servers for serial-to-network conversion to interact with satellite communication equipment, increasing the number of communication nodes in the system and raising overall complexity and potential failure risks. Summary of the Invention

[0005] This invention provides a near-space airship communication method, system, electronic device, and storage medium to address the shortcomings of the current shipboard computer architecture, which is mainly based on serial communication. These shortcomings include significant deficiencies in scalability, transmission efficiency, and hardware deployment, leading to system complexity, high latency, and increased risk of failure.

[0006] This invention provides a near-space airship communication method, applied to an onboard proxy server deployed on the airship's onboard end, comprising the following steps.

[0007] A bridging establishment request is sent to the ground-based proxy server; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground-based proxy server via a satellite communication link. Receive a first message published by the first onboard client; the first message carries a first message subject; Based on the first message topic, the forwarding path of the first message is determined; the forwarding path includes a local forwarding path for forwarding to the shipborne terminal equipment and a bridged forwarding path for forwarding to the ground terminal. Based on the local forwarding path, the first message is sent to the second submarine-borne client that has subscribed to the first message topic; Based on the bridging forwarding path, the first message is sent to the ground proxy server through the bidirectional bridging channel.

[0008] According to a near-space airship communication method provided by the present invention, the method further includes: The second message, forwarded by the ground proxy server, is received via the bidirectional bridging channel; the second message carries a second message subject. Based on the second message topic, a third onboard client that subscribes to the second message topic is determined from the preset subscription relationships; The second message is sent to the third submarine-borne client.

[0009] According to a near-space airship communication method provided by the present invention, the step of sending the first message to a second onboard client subscribed to the first message topic based on the local forwarding path includes: Based on the local forwarding path and the first quality of service level, the first message is sent to the subscribed second submarine client; the first message is a telemetry message. The receiving of the second message forwarded by the ground proxy server based on the bidirectional bridging channel includes: Based on the bidirectional bridging channel and the second quality of service level, a second message forwarded by the ground proxy server is received; the second message is a remote control message. The first service quality level and the second service quality level are different.

[0010] According to a near-space airship communication method provided by the present invention, the second message is published by a ground client and received and forwarded by the ground proxy server.

[0011] According to a near-space airship communication method provided by the present invention, the step of sending the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path includes: If the first message topic matches any topic in the bridging topic list, the first message is sent to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0012] According to a near-space airship communication method provided by the present invention, the method further includes: Receive a connection request initiated by the first onboard client; the connection request includes identity credentials; The identity credential is verified by invoking a preset authentication strategy, and the verification result is obtained; If the verification result is successful, a communication connection is established with the first onboard client.

[0013] According to a near-space airship communication method provided by the present invention, the method further includes: The onboard proxy server is deployed at a static Internet Protocol address, and listening is initiated on the network port corresponding to the static Internet Protocol address. Receiving the connection request initiated by the first submarine-borne client includes: During the listening process, a connection request initiated by the first submarine client to the static Internet Protocol address is received.

[0014] The present invention also provides a near-space airship communication system, comprising the following modules: The module is used to send a bridging establishment request to the ground proxy server on the ground; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link; The receiving module is used to receive a first message published by a first onboard client; the first message carries a first message subject; The determination module is used to determine the forwarding path of the first message based on the first message topic; the forwarding path includes a local forwarding path for forwarding to the shipborne terminal equipment and a bridged forwarding path for forwarding to the ground terminal. The first sending module is used to send the first message to a second onboard client that has subscribed to the first message topic, based on the local forwarding path. The second sending module is used to send the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the near-space airship communication methods described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the near-space airship communication method as described above.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the near-space airship communication methods described above.

[0018] The near-space airship communication method, system, electronic equipment, and storage medium provided by this invention transform the communication architecture within the near-space airship and between space and ground from the traditional point-to-point serial port or user datagram protocol communication mode to a publish / subscribe mode based on a proxy server. The onboard proxy server, acting as the message hub of the onboard end, establishes a bidirectional bridging channel with the ground proxy server, thereby decoupling communication between onboard devices and between the onboard end and the ground end. On one hand, the onboard proxy server can flexibly distribute data within the onboard devices based on the first message topic of the first message; on the other hand, it can selectively and efficiently transmit critical data to the ground through the bridging channel. Compared with existing technologies, this approach effectively reduces the overhead of communication protocols, improves the real-time performance of data transmission and reduces bandwidth consumption in bandwidth-constrained satellite communication links; simultaneously, it greatly enhances the scalability of the onboard system. When adding or modifying onboard equipment, there is no need to change the hardware and software interfaces of other devices; only the connection and publish / subscribe relationship with the onboard proxy server need to be configured, significantly reducing the complexity and risk of system integration and maintenance. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the communication system provided by the present invention.

[0021] Figure 2 This is a flowchart illustrating the near-space airship communication method provided by the present invention.

[0022] Figure 3 This is a schematic diagram of the process for establishing a communication connection with the first submarine-borne client provided by the present invention.

[0023] Figure 4 This is a schematic diagram of the near-space airship communication method based on MQTT provided by the present invention.

[0024] Figure 5 This is a schematic diagram of the near-space airship communication system provided by the present invention.

[0025] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

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

[0027] The terms "first," "second," etc., used in this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and that the objects distinguished by "first," "second," etc., are generally of the same class.

[0028] This invention provides a near-space airship communication method, applied to an onboard proxy server deployed on the airship's onboard end. The onboard end of the airship can be understood as a collection of devices deployed within the pod of a near-space airship, such as a stratospheric airship, interconnected via an onboard local area network (LAN), such as Ethernet. The onboard proxy server is the core message processing unit in the onboard LAN, responsible for receiving, forwarding, and managing messages between onboard devices, as well as communicating with the ground terminal. In a specific implementation, the onboard proxy server can be a proxy server implementing a message queue telemetry transmission protocol.

[0029] Figure 1 This is a schematic diagram of the communication system provided by the present invention, as shown below. Figure 1 As shown, the communication system mainly consists of two parts: shipborne / global-borne equipment and ground equipment. On the shipborne / global-borne equipment side, the flight control computer, shipboard computer, and other shipborne / global-borne computers and equipment, acting as clients, are connected to a shipborne / global-borne network switch via a Local Area Network (LAN). This shipborne / global-borne network switch connects to the shipborne proxy server via the LAN and also to the shipborne / global-borne satellite terminal equipment via the LAN. On the ground equipment side, multiple ground monitoring computers, acting as clients, are connected to a ground network switch via a LAN. This ground network switch also connects to the ground-based proxy server (Broker) and ground satellite terminal equipment via the LAN. Wireless communication between the shipborne / global-borne satellite terminal equipment and the ground satellite terminal equipment is established via satellite, thus forming a satellite communication link connecting the shipborne and ground ends.

[0030] Figure 2 This is a flowchart illustrating the near-space airship communication method provided by the present invention, as shown below. Figure 2 As shown, the method includes the following: Step 110: Send a bridging establishment request to the ground proxy server on the ground; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link.

[0031] Specifically, firstly, a bridge establishment request can be sent to the ground-based proxy server. The ground-based system, which commands and controls the airship's operation, also deploys a ground proxy server to manage message communication with various ground monitoring devices and the airship's onboard terminals. This ground proxy server can also be an MQTT proxy server.

[0032] Here, the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link. It is important to understand that this bridging establishment request is not a single, instantaneous request message, but rather a connection process initiated according to a preset configuration, aimed at establishing a persistent logical channel. Specifically, the network address of the ground proxy server can be preset in the configuration file of the shipborne proxy server, along with bridging parameters such as the bridging name, connection direction (configured as bidirectional), and security authentication information (such as username and password). The network address can be an IP address and port number, the connection direction can be configured as bidirectional, and the security authentication information can include a username and password, etc., which are not specifically limited in this embodiment of the invention. When the shipborne proxy server starts up or the network becomes available, it will automatically initiate a connection to the ground proxy server according to this configuration, using an underlying network protocol such as TCP. This connection process constitutes the bridging establishment request.

[0033] Among them, the satellite communication link is the physical or logical communication link connecting the shipboard end and the ground end of the airship. It is usually composed of the shipboard satellite communication terminal, the communication satellite and the ground satellite communication terminal, providing a long-distance and wide-range channel for data transmission between the shipboard end and the ground end.

[0034] Here, the bidirectional bridging channel is a logical data channel formed after a successful connection is established between the onboard proxy server and the ground proxy server. It should be understood that the bidirectional bridging channel is bidirectional, meaning that messages can flow from the onboard proxy server to the ground proxy server (downlink) and from the ground proxy server to the onboard proxy server (uplink). Through the bidirectional bridging channel, the two originally independent proxy servers can achieve message sharing and interoperability, making the entire communication system logically appear as a unified distributed messaging system.

[0035] Step 120: Receive a first message published by the first onboard client; the first message carries a first message subject.

[0036] Specifically, after the bidirectional bridging channel is established, or during the establishment process, the onboard proxy server continuously runs its messaging service. During this step, the onboard proxy server receives messages published by other devices on the shipboard.

[0037] Furthermore, it can receive a first message published by the first onboard client, wherein the first message carries a first message subject.

[0038] Here, the first onboard client is any device deployed on the airship's onboard end, connected to the onboard local area network, and capable of publishing or subscribing to messages. For example, the first onboard client could be a flight control computer used to collect airship flight attitude, speed, and other status data; it could also be a shipboard computer used to collect the operating status of airship platform equipment (such as power supply and temperature control); or it could be other types of mission payloads or safety control computers. This embodiment of the invention does not specifically limit this. In the context of the MQTT protocol, this first onboard client plays the role of a publisher.

[0039] The first message is data generated by the first onboard client and needs to be distributed. For example, the first message could be a telemetry data frame collected and packaged by the flight control computer, which contains various status information of the aircraft.

[0040] The first message carries a first message topic. A first message topic is a string tag used to identify the message category, source, or content, typically in a hierarchical structure, such as "yctopic / FKTD1," reflecting the content attributes of the first message. For example, the topic "yctopic / FKTD1" could be defined as representing telemetry data released by the flight control computer. The publisher of the first message publishes it to a specific topic without needing to know who will receive it.

[0041] Step 130: Based on the first message topic, determine the forwarding path of the first message; the forwarding path includes a local forwarding path for forwarding to the onboard terminal equipment and a bridged forwarding path for forwarding to the ground terminal.

[0042] Specifically, based on the first message topic, the forwarding path of the first message is determined. This forwarding path includes a local forwarding path for forwarding to the shipboard terminal equipment and a bridged forwarding path for forwarding to the ground terminal.

[0043] The onboard proxy server can perform the following judgments: 1. Check its internal client subscription list to determine if any onboard client has subscribed to the First Message topic. If so, determine that the First Message has a local forwarding path that points to one or more onboard clients that have subscribed to the First Message topic.

[0044] 2. Check its bridging configuration to determine if the first message topic meets the preset bridging forwarding rules. For example, the bridging forwarding rule can be a list of topics to be bridged, or a topic pattern containing wildcards, such as "yctopic / #", indicating that all telemetry topics starting with "yctopic / " need to be bridged. If the match is successful, it is determined that the first message has a bridging forwarding path, which points to the ground proxy server via a bidirectional bridging channel.

[0045] Step 140: Based on the local forwarding path, send the first message to the second submarine client that subscribes to the first message topic.

[0046] Specifically, based on the local forwarding path, the first message is sent to the second onboard client subscribed to the first message topic. This step is the specific execution of the local forwarding path. If the onboard proxy server determines that a local forwarding path exists, it will forward the received first message to one or more second onboard clients without modification.

[0047] In this context, the second onboard client refers to any onboard device that registers a subscription to the first message topic with the onboard agent server. For example, the ship's maintenance computer, acting as the second onboard client, might need to subscribe to flight status messages published by the flight control computer, acting as the first onboard client, for collaborative control or status recording. In this scenario, the onboard agent server will send the flight status message to the ship's maintenance computer.

[0048] Step 150: Based on the bridging forwarding path, send the first message to the ground proxy server through the bidirectional bridging channel.

[0049] Specifically, based on the bridging forwarding path, the first message is sent to the ground proxy server through a bidirectional bridging channel. This step is the specific execution of the bridging forwarding path.

[0050] If the onboard proxy server determines that a bridging forwarding path exists, it will send the first received message to the ground proxy server via a bidirectional bridging channel and satellite communication link. Upon receiving the message, the ground proxy server can then distribute the first message to ground monitoring computers and other equipment based on the subscription status of ground clients, thus completing a downlink data transmission process from the airship to the ground.

[0051] The method provided in this invention transforms the communication architecture within near-space airships and between space and ground from the traditional point-to-point serial port or User Datagram Protocol (UDP) communication mode to a publish / subscribe mode based on a proxy server. The onboard proxy server, acting as the message hub of the onboard end, establishes a bidirectional bridging channel with the ground proxy server, decoupling communication between onboard devices and between the onboard end and the ground end. On one hand, the onboard proxy server can flexibly distribute data within the onboard devices based on the first message topic of the first message; on the other hand, it can selectively and efficiently transmit critical data to the ground through the bridging channel. Compared to existing technologies, this approach effectively reduces communication protocol overhead, improves the real-time performance of data transmission and reduces bandwidth consumption in bandwidth-constrained satellite communication links; simultaneously, it greatly enhances the scalability of the onboard system. When adding or modifying onboard devices, there is no need to change the hardware and software interfaces of other devices; only the connection and publish / subscribe relationship with the onboard proxy server need to be configured, significantly reducing the complexity and risk of system integration and maintenance.

[0052] Based on the above embodiments, the method further includes: Step 210: Receive a second message forwarded by the ground proxy server based on the bidirectional bridging channel; the second message carries a second message subject. Step 220: Based on the second message topic, determine the third onboard client that subscribes to the second message topic from the preset subscription relationships; Step 230: Send the second message to the third onboard client.

[0053] Specifically, a second message forwarded by a ground proxy server can be received via a bidirectional bridging channel. Based on this bidirectional bridging channel, the shipborne proxy server can not only send messages to the ground but also receive messages from the ground proxy server.

[0054] The second message typically refers to instructions or data initiated from the ground and requiring execution by the shipboard equipment. For example, the second message could be a remote control command issued by ground control personnel. Similar to the first message, the second message carries a second message subject, which is used to identify the destination or content attributes of the second message. For example, the subject "yktopic / FKTC1" can be defined as representing a remote control command sent to the shipboard flight control computer.

[0055] Then, based on the second message topic, the third onboard client subscribing to the second message topic can be determined from the pre-defined subscription relationships.

[0056] The pre-defined subscription relationship refers to a subscription information table maintained internally by the onboard agent server. This table records all onboard clients currently connected to the server and their respective subscribed message topics. This relationship is pre-defined because each onboard client is configured during its initialization process to immediately subscribe to the topics required for its own functions upon connecting to the agent server. For example, the flight control computer automatically sends a subscription request to the onboard agent server upon startup, indicating that it is interested in all messages with the topic "yktopic / FKTC1".

[0057] Here, the third onboard client is the target device that the onboard terminal subscribes to the second message topic. For example, if the second message topic is "yktopic / FKTC1", then the third onboard client is the flight control computer that subscribes to the second message topic. The onboard agent server determines the third onboard client by querying its pre-set subscription relationship table to find the subscriber that matches the second message topic.

[0058] Finally, the second message can be sent to the third onboard client. Upon receiving the second message, the third onboard client will parse its content and execute corresponding operations. For example, after receiving the remote control command, the flight control computer will adjust the control surfaces or perform other flight control actions.

[0059] The method provided in this invention forwards a second message carrying a second message topic through a ground proxy server. Based on the second message topic, the shipborne proxy server determines a third shipborne client subscribed to the second message topic from a pre-defined subscription relationship, achieving efficient and accurate routing of ground commands to specific shipborne devices. This approach solves the problem of accurately delivering ground commands to target devices in a decoupled architecture, allowing ground stations to precisely control any device without needing to understand the complex internal network topology of the shipborne terminal, further enhancing the system's modularity and ease of use.

[0060] Based on the above embodiments, step 140 includes: Step 141: Based on the local forwarding path and the first quality of service level, send the first message to the subscribed second submarine client; the first message is a telemetry message; Step 210 includes: Step 211: Based on the bidirectional bridging channel and the second quality of service level, receive the second message forwarded by the ground proxy server; the second message is a remote control message. The first service quality level and the second service quality level are different.

[0061] Specifically, in this embodiment of the invention, the message type and service quality are further optimized and defined to adapt to the different reliability and real-time requirements of different services in near-space communication.

[0062] In a specific implementation, the first message can be a telemetry message. Telemetry messages are data reflecting the status of the airship platform or payload, and consist of various sensor data, equipment operating parameters, and status information collected by onboard clients (such as flight control computers and shipboard computers). Telemetry messages are typically characterized by high frequency and large data volume.

[0063] Accordingly, the second message can specifically be a remote control message. Remote control messages are instruction data used to control the behavior of the airship platform or payload, typically generated by the ground station based on mission requirements or to respond to unforeseen circumstances, such as flight control commands and equipment switching commands. Remote control messages are usually characterized by their suddenness, strong command nature, and extremely high reliability requirements.

[0064] To differentiate between these two types of messages, this embodiment introduces the concept of Quality of Service (QoS) level. When sending telemetry messages (the first message) via a local forwarding path or a bridged forwarding path, a first QoS level can be used. This first QoS level is a parameter used to define the message delivery reliability level. For high-frequency telemetry messages, a lower reliability level can be used, such as QoS0 ("At Most Once") in the MQTT protocol. This level delivers messages with a best-effort approach, without acknowledgment, minimizing overhead and enabling data transmission with maximum efficiency. It is suitable for telemetry scenarios where partial data loss is tolerable.

[0065] When the onboard agent server receives the remote control message (i.e., the second message) forwarded by the ground agent server, the message reception and forwarding process can be based on a second Quality of Service (QoS) level. The second QoS level is another parameter used to define the message delivery reliability level, and its level differs from the first QoS level. For critical remote control messages, a higher reliability level must be used, such as QoS1 ("at least once") in the MQTT protocol. This level ensures that the message will definitely be delivered to the target client; it requires the receiver to return an acknowledgment response, and if no response is received, the message will be retransmitted, thus guaranteeing the reliable execution of the command.

[0066] In summary, each onboard computer and ground monitoring computer establishes a connection with the proxy server as clients; each client subscribes to and publishes messages through the TOPIC in the MQTT protocol. In the specific communication process, this embodiment employs different MQTT Quality of Service (QoS) levels based on the nature and real-time requirements of the messages. The MQTT protocol defines three QoS levels to determine the guarantee level of message delivery. Considering the limited data bandwidth in the flight tests and applications of airships in the near-air environment, different types of messages are processed differently. For telemetry messages composed of sensor data and equipment information collected by each onboard computer according to its respective function, due to their high publication frequency, QoS 0 (at most once) QoS level is used for communication. At this level, no acknowledgment is made after the message is sent, and no retransmission is performed, suitable for scenarios where reliability requirements are not high but transmission speed is required. For uplink remote control messages sent by the ground monitoring computer through human-machine interaction, such as related equipment and flight control commands, it is necessary to ensure that the message is received at least once. Therefore, QoS 1 (at least once) QoS level is used for communication. This level ensures the reliable delivery of critical commands through a mechanism where the sender waits for acknowledgment from the receiver. This embodiment does not use QoS2 (once only) level, although it is the most stable transmission level and can ensure the uniqueness of messages through a four-way handshake mechanism, but its communication overhead is large and it is not suitable for current application scenarios with limited data bandwidth.

[0067] The method provided in this invention introduces a differentiated service assurance mechanism by setting different quality of service (QoS) levels for different types of telemetry and remote control messages. By using a lower reliability level for high-frequency telemetry data to reduce transmission overhead, and a higher reliability level for critical remote control commands to ensure their reliable arrival, this scheme achieves a balance between system reliability and resource efficiency. This solves the technical challenge of balancing the transmission efficiency of massive amounts of telemetry data with the execution reliability of critical remote control commands on bandwidth-constrained satellite links, greatly optimizing the utilization efficiency of limited channel resources.

[0068] Based on the above embodiments, the second message is published by the ground client and received and forwarded by the ground proxy server.

[0069] Specifically, the second message is published by the ground client and received and forwarded by the ground proxy server. The ground client refers to an application or device deployed in the ground command and control system capable of generating and publishing messages. For example, the ground client could be monitoring software running on a ground monitoring computer used by ground operators. Operators input control commands through the monitoring software's human-machine interface. The monitoring software then encapsulates the input control commands into a second message carrying a specific subject and publishes the second message to the local ground proxy server. Upon receiving the second message, the ground proxy server, because the subject of the second message satisfies the bridging forwarding rules, forwards it to the shipborne proxy server through a bidirectional bridging channel.

[0070] The method provided in this invention involves the second message being published by the ground client and received and forwarded by the ground proxy server. This means the ground operator and their client software only need to interact with the local ground proxy server, without needing to know whether subsequent messages are transmitted via satellite link or other means, or the specific network structure of the spacecraft. This simplifies the design and operation of the ground control system, solves the complexity problem caused by the tight coupling between the ground and spacecraft in existing technologies, and improves the overall modularity and ease of use of the system.

[0071] Based on the above embodiments, step 150 includes: Step 151: If the first message topic matches any topic in the bridging topic list, the first message is sent to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0072] Specifically, if the first message topic matches any topic in the bridging topic list, the first message is sent to the ground proxy server through a bidirectional bridging channel based on the bridging forwarding path.

[0073] The bridging topic list is a pre-configured list or set of rules in the onboard agent server that defines which topics' messages need to be forwarded from the onboard end to the ground end. The bridging topic list can contain one or more explicit topic strings, such as "yctopic / FKTD1", or it can contain topic patterns with wildcards, such as "yctopic / #", representing all telemetry topics that begin with "yctopic / ".

[0074] When the onboard proxy server receives a first message, it extracts the message's topic and checks it against the bridging topic list. Only if a match is found will the onboard proxy server consider the first message to have a bridging forwarding path and send it to the ground via a bidirectional bridging channel. If a message's topic is not in the list, it will not be forwarded to the ground, even if it has local subscribers on the onboard side.

[0075] The method provided in this invention, by employing a bridging topic list as a filter, enables the system to precisely control which data can flow through bandwidth-constrained satellite communication links. This ensures that only critical data valuable to the ground end is transmitted, while a large number of local messages intended solely for internal interaction within the shipboard equipment are effectively confined to the shipboard local area network. This prevents valuable channel resources from being wasted on irrelevant data, thereby significantly improving the overall efficiency and economy of space-to-ground communication.

[0076] Based on the above embodiments, the method further includes: Step 310: Receive a connection request initiated by the first onboard client; the connection request includes identity credentials; Step 320: Invoke the preset authentication strategy to verify the identity credential and obtain the verification result; Step 330: If the verification result is successful, establish a communication connection with the first onboard client.

[0077] Specifically, Figure 3 This is a schematic diagram of the process for establishing a communication connection with the first submarine-borne client provided by the present invention, as shown below. Figure 3 As shown, firstly, a connection request initiated by the first onboard client can be received. Before any message communication occurs, a client, such as the first onboard client, must first establish a stable communication connection with the onboard proxy server. This step marks the beginning of the connection establishment process.

[0078] The connection request is the initial network data packet initiated by the first onboard client application to establish a network connection with the server. In TCP / IP-based communication, a connection request typically corresponds to the first request of the application layer protocol after the TCP three-way handshake. The connection request not only establishes a network path, but more importantly, it carries the client's identity information.

[0079] Here, the connection request includes identity credentials. Identity credentials are a set of information used to prove the legitimacy and identity of the client. Identity credentials can be a combination of various forms; for example, identity credentials may include a username and a password. In more stringent scenarios, identity credentials may also include a client ID, digital certificate, or other encrypted tokens; this embodiment of the invention does not specifically limit this. This information is included in a specific field of the connection request data packet and sent along with the request to the onboard proxy server.

[0080] Then, a preset authentication policy can be invoked to verify the identity credentials and obtain the verification result. When the onboard proxy server receives a connection request containing identity credentials, it does not immediately accept the connection but first initiates a security verification process. This invocation refers to the server internally triggering and executing a predefined security check logic. The preset authentication policy is one or more sets of rules configured by the administrator on the onboard proxy server to verify the client's identity. For example, the preset authentication policy could be an access control list containing all legitimate client username and password pairs. When a connection request is received, the server extracts the identity credentials, such as the username and password, from the request and compares them with the records stored in the access control list.

[0081] Here, the verification result is a flag output after the authentication policy is executed, indicating whether the authentication was successful or not. If the username and password provided by the client can be found in the access control list, the verification result is successful; otherwise, if no match is found, or the password is incorrect, the verification result is unsuccessful.

[0082] Finally, if the verification result is successful, a communication connection is established with the first onboard client. The onboard proxy server determines subsequent operations based on the verification result obtained in the previous step. Only when the verification result is successful will the server accept the connection request, allocate the necessary system resources to the client, and complete the connection establishment. Afterward, the first onboard client is allowed to publish or subscribe to messages to the proxy server. If the verification result is unsuccessful, the proxy server will reject the connection request and may return an authentication failure error code to the client, thereby preventing unauthorized or illegal devices from accessing the communication system.

[0083] The method provided in this invention adds a crucial security barrier to the shipborne communication system by introducing an identity credential verification process when the client establishes a connection with the proxy server. By executing a preset authentication policy to confirm the client's legitimacy, this scheme effectively prevents unauthorized devices from accessing the shipborne messaging network, thereby greatly improving the security and stability of the entire near-space airship communication system.

[0084] Based on the above embodiments, the method further includes: The onboard proxy server is deployed at a static Internet Protocol address, and listening is initiated on the network port corresponding to the static Internet Protocol address. Step 310 includes: Step 311: During the listening process, a connection request initiated by the first submarine client to the static Internet Protocol address is received.

[0085] Specifically, the onboard proxy server can be deployed with a static Internet Protocol (IP) address. A static IP address is a manually assigned, fixed IP address for a network device. Unlike dynamic addresses, static IP addresses ensure that the proxy server's network location within the onboard LAN is constant and predictable. For example, the onboard proxy server's address can be fixed at 192.168.1.100. Simultaneously, the proxy server will start listening on a specific network port corresponding to this static IP address, such as port 1883, the default port for the MQTT protocol.

[0086] Here, "listening" refers to binding the onboard proxy server program to the IP address and port, and entering a waiting state, ready to receive external connection requests from the IP address and port at any time.

[0087] Accordingly, during the listening process, a connection request initiated by the first onboard client to a static Internet Protocol address is received. This means that all onboard clients have this fixed IP address and port number of the onboard proxy server pre-configured in their programs. When a client needs to connect, it directly initiates a connection request to this known, fixed network endpoint without searching the network or relying on other service discovery mechanisms.

[0088] The method provided in this invention receives a connection request initiated by a first onboard client to a static Internet Protocol address during the listening process. This simplifies the client configuration logic, reduces latency during system startup and reconnection, and eliminates the risk of connection failures due to dynamic address changes. This ensures that the onboard communication system can quickly resume stable operation under various conditions such as device restarts and network fluctuations, further improving the system's robustness and reliability.

[0089] Based on any of the above embodiments Figure 4 This is a schematic diagram of the near-space airship communication method based on MQTT provided by the present invention, as shown below. Figure 4As shown, the entire communication system mainly includes the shipborne flight control computer, shipboard operations computer (and other possible shipborne computers), and shipborne proxy server, as well as the ground-based ground monitoring computer and ground proxy server. A stable two-way bridging channel is established between the shipborne proxy server and the ground proxy server via a satellite communication link.

[0090] During system initialization, the flight control computer and ship maintenance computer, acting as onboard clients, and the ground monitoring computer, acting as ground clients, each establish MQTT connections and connect to the proxy server. Specifically, they connect to the proxy server on their respective local area networks (onboard computers connect to the onboard proxy server, and ground computers connect to the ground proxy server). After successful connection, each client configures message subscription and publishing according to its functional requirements. Specifically, the flight control computer subscribes to / processes the yktopic / FKTC1 message, indicating its readiness to receive remote control commands; the ship maintenance computer subscribes to / processes the yktopic / TWTC1 message. Simultaneously, the ground monitoring computer subscribes to / processes either the yctopic / FKTD1 or yctopic / TWTD1 message to prepare for receiving telemetry data from the onboard terminal.

[0091] To clearly illustrate the data flow, the message topics in this embodiment are defined as follows: Data collected by the flight control computer and flight control status data can be integrated into MQTT protocol messages, and the telemetry message topic (topic) it publishes is "yctopic / FKTD1"; data collected by the ship's maintenance computer and computer status data can be integrated into MQTT protocol messages, and the telemetry message topic it publishes is "yctopic / TWTD1". The remote control message topic sent by the ground computer to the flight control computer is set to "yktopic / FKTC1", and the remote control message topic sent to the ship's maintenance computer is set to "yktopic / TWTC1". It should be noted that the messages published by each computer are not limited to one topic; multiple topics can be published according to actual needs. This embodiment only selects representative topics to illustrate the data flow process.

[0092] Under the above system configuration, the specific data interaction method can be divided into two processes: data downlink and data uplink. (1) Data Downlink Process: This process is mainly used to transmit telemetry data from the shipboard terminal to the ground. First, the flight control computer collects data through its sensors and periodically publishes yctopic / FKTD1 messages; similarly, the shipboard computer also collects data and periodically publishes yctopic / TWTD1 messages. These messages are sent to the shipboard proxy server. After receiving the messages, the shipboard proxy server performs a core routing judgment, that is, it determines whether the proxy server is a subscribed topic. Here, this judgment specifically checks whether the message topic matches the bridging forwarding rules. Since yctopic / FKTD1 and yctopic / TWTD1 are both configured as telemetry topics that need to be forwarded to the ground, the shipboard proxy server sends these telemetry messages through the shipboard switch and the shipboard satellite communication terminal, via the communication satellite to the ground satellite communication terminal, and finally to the ground proxy server. After receiving the messages, the ground proxy server also checks its subscription relationship. Since the ground monitoring computer has subscribed to these topics, the ground proxy server forwards the messages to the ground monitoring computer. After receiving the message in the subscription / processing process, the ground monitoring computer parses and displays it to visualize the telemetry data of the airship and complete the downlink data transmission.

[0093] (2) Data Uplink Process: This process is mainly used to transmit remote control commands from the ground to the onboard terminal. First, the airship flight controller performs manual operation on the ground monitoring computer, such as clicking a control button. This operation triggers the ground monitoring computer to issue a yktopic / FKTC1 or yktopic / TWTC1 message based on the operation. This remote control message is sent to the ground proxy server. According to the bridging configuration, the ground proxy server sends the remote control message to the onboard satellite communication terminal through the ground satellite communication terminal and the communication satellite, and finally to the onboard proxy server. After receiving the message, the onboard proxy server performs the judgment again to determine whether the proxy server has subscribed to the topic. Here, the judgment refers to checking whether there are any clients subscribed to the topic on the onboard local network. If the message topic is yktopic / FKTC1, the server determines the result as yes and forwards the message to the flight control computer that has subscribed to the topic; if the topic is yktopic / TWTC1, it is also determined as yes and forwarded to the ship's computer. The target computer receives the message in its respective subscription / processing flow, parses the control signals in it and executes the corresponding operations to achieve precise control of the onboard equipment of the near-space airship and complete the data uplink.

[0094] In summary, this invention describes an MQTT-based communication method for near-space airships. By applying IoT concepts to airship platform design, it enables near-space airship monitoring. Through the use of the MQTT protocol and configurable Quality of Service (QoS) levels, bandwidth occupancy is effectively reduced under conditions of limited network communication resources. Furthermore, it supports on-demand distributed expansion of onboard and ground-based monitoring computers, significantly reducing the complexity of equipment expansion.

[0095] The embodiments of the present invention effectively solve the problems existing in the prior art. Addressing the issue that existing shipboard computers primarily use serial communication, requiring extensive modifications to hardware and software interfaces for adding devices and hindering scalability, the present invention enables shipboard computers to support the MQTT interface communication protocol. When adding a shipboard computer as needed, only the added computer needs to be connected to the shipboard proxy server via software configuration and subscribe to or publish the required message topics. Computers that need to communicate with the newly added computer only need to subscribe to the corresponding message topics, eliminating the need for complex modifications to computer hardware interfaces and significantly improving system scalability.

[0096] In response to the problems of existing technologies that mainly use serial port or UDP communication protocols, such as lengthy protocols, large bandwidth consumption, and high latency, this invention adopts the MQTT protocol, which has a more lightweight and miniaturized data transmission type. Under the condition of limited bandwidth resources of near-space aerostats, it can effectively reduce the consumption of bandwidth resources, which is more conducive to data transmission under limited bandwidth and improves the real-time performance of data transmission.

[0097] To address the problem of system complexity and numerous failure points in existing technologies where onboard computers primarily use serial communication and require additional serial server conversion for serial-to-network conversion, this invention upgrades each computer to a core processor that supports the MQTT protocol and network communication. Communication between all client devices is achieved through a proxy server, eliminating the need for additional protocol conversion hardware. This effectively reduces the redundancy of hardware interfaces between devices and minimizes the risk of failure caused by multiple communication nodes.

[0098] The near-space airship communication system provided by the present invention is described below. The near-space airship communication system described below and the near-space airship communication method described above can be referred to in correspondence.

[0099] Based on any of the above embodiments, the present invention provides a near-space airship communication system. Figure 5 This is a schematic diagram of the near-space airship communication system provided by the present invention, as shown below. Figure 5 As shown, it includes: The module 510 is used to send a bridging establishment request to the ground proxy server on the ground; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link. The receiving module 520 is used to receive a first message published by the first onboard client; the first message carries a first message subject; The determination module 530 is used to determine the forwarding path of the first message based on the first message topic; the forwarding path includes a local forwarding path for forwarding to the shipborne terminal equipment and a bridged forwarding path for forwarding to the ground terminal. The first sending module 540 is used to send the first message to a second onboard client that subscribes to the first message topic based on the local forwarding path; The second sending module 550 is used to send the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0100] The system provided in this invention transforms the communication architecture within near-space airships and between space and ground from the traditional point-to-point serial port or User Datagram Protocol (UDP) communication mode to a publish / subscribe mode based on a proxy server. The onboard proxy server, acting as the message hub on the onboard end, establishes a bidirectional bridging channel with the ground proxy server, decoupling communication between onboard devices and between the onboard end and the ground end. On one hand, the onboard proxy server can flexibly distribute data within the onboard devices based on the first message topic of the first message; on the other hand, it can selectively and efficiently transmit critical data to the ground through the bridging channel. Compared to existing technologies, this approach effectively reduces communication protocol overhead, improves the real-time performance of data transmission and reduces bandwidth consumption in bandwidth-constrained satellite communication links; simultaneously, it greatly enhances the scalability of the onboard system. When adding or modifying onboard devices, there is no need to change the hardware or software interfaces of other devices; only their connection and publish / subscribe relationship with the onboard proxy server need to be configured, significantly reducing the complexity and risk of system integration and maintenance.

[0101] Based on any of the above embodiments, a third sending module is further included, wherein the third sending module specifically includes: The forwarding module is used to receive a second message forwarded by the ground proxy server based on the bidirectional bridging channel; the second message carries a second message subject; The subscription determination module is used to determine, based on the second message topic, a third onboard client that subscribes to the second message topic from a preset subscription relationship; The second message is sent to the third submarine-borne client.

[0102] Based on any of the above embodiments, the first sending module 540 is specifically used for: Based on the local forwarding path and the first quality of service level, the first message is sent to the subscribed second submarine client; the first message is a telemetry message. The forwarding module is specifically used for: Based on the bidirectional bridging channel and the second quality of service level, a second message forwarded by the ground proxy server is received; the second message is a remote control message. The first service quality level and the second service quality level are different.

[0103] Based on any of the above embodiments, the second message is published by the ground client and received and forwarded by the ground proxy server.

[0104] Based on any of the above embodiments, the second sending module 550 is specifically used for: If the first message topic matches any topic in the bridging topic list, the first message is sent to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0105] Based on any of the above embodiments, a verification module is further included, wherein the verification module is specifically used for: Receive a connection request initiated by the first onboard client; the connection request includes identity credentials; The identity credential is verified by invoking a preset authentication strategy, and the verification result is obtained; If the verification result is successful, a communication connection is established with the first onboard client.

[0106] Based on any of the above embodiments, a listening module is further included, wherein the listening module is specifically used for: The onboard proxy server is deployed at a static Internet Protocol address, and listening is initiated on the network port corresponding to the static Internet Protocol address. Receiving the connection request initiated by the first submarine-borne client includes: During the listening process, a connection request initiated by the first submarine client to the static Internet Protocol address is received.

[0107] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6As shown, the electronic device may include: a processor 610, a communications interface 620, a memory 630, and a communication bus 640, wherein the processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a near-space airship communication method, which includes: sending a bridging establishment request to a ground-based proxy server; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground-based proxy server via a satellite communication link; receiving a first message published by a first shipborne client; the first message carrying a first message topic; determining a forwarding path for the first message based on the first message topic; the forwarding path includes a local forwarding path for forwarding to the shipborne terminal device and a bridging forwarding path for forwarding to the ground terminal; sending the first message to a second shipborne client subscribing to the first message topic based on the local forwarding path; and sending the first message to the ground-based proxy server via the bidirectional bridging channel based on the bridging forwarding path.

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

[0109] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the near-space airship communication method provided by the above methods. The method includes: sending a bridging establishment request to a ground proxy server on the ground; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link; receiving a first message published by a first shipborne client; the first message carrying a first message topic; determining a forwarding path for the first message based on the first message topic; the forwarding path includes a local forwarding path for forwarding to a shipborne terminal device and a bridging forwarding path for forwarding to the ground terminal; sending the first message to a second shipborne client subscribing to the first message topic based on the local forwarding path; and sending the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

[0110] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the near-space airship communication method provided by the methods described above. The method includes: sending a bridging establishment request to a ground-based proxy server; the bridging establishment request being used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground-based proxy server via a satellite communication link; receiving a first message published by a first shipborne client; the first message carrying a first message subject; determining a forwarding path for the first message based on the first message subject; the forwarding path including a local forwarding path for forwarding to a shipborne terminal device and a bridging forwarding path for forwarding to a ground terminal; sending the first message to a second shipborne client subscribing to the first message subject based on the local forwarding path; and sending the first message to the ground-based proxy server via the bidirectional bridging channel based on the bridging forwarding path.

[0111] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A near-space airship communication method, characterized in that, The method, applied to an onboard agent server deployed on the onboard end of an airship, includes: A bridging establishment request is sent to the ground-based proxy server; the bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground-based proxy server via a satellite communication link. Receive a first message published by the first onboard client; the first message carries a first message subject; Based on the first message topic, the forwarding path of the first message is determined; the forwarding path includes a local forwarding path for forwarding to the shipborne terminal equipment and a bridged forwarding path for forwarding to the ground terminal. Based on the local forwarding path, the first message is sent to the second submarine-borne client that has subscribed to the first message topic; Based on the bridging forwarding path, the first message is sent to the ground proxy server through the bidirectional bridging channel.

2. The near-space airship communication method according to claim 1, characterized in that, The method further includes: The second message, forwarded by the ground proxy server, is received via the bidirectional bridging channel; the second message carries a second message subject. Based on the second message topic, a third onboard client that subscribes to the second message topic is determined from the preset subscription relationships; The second message is sent to the third submarine-borne client.

3. The near-space airship communication method according to claim 2, characterized in that, The step of sending the first message to a second onboard client that has subscribed to the first message topic based on the local forwarding path includes: Based on the local forwarding path and the first quality of service level, the first message is sent to the subscribed second submarine client; the first message is a telemetry message. The receiving of the second message forwarded by the ground proxy server based on the bidirectional bridging channel includes: Based on the bidirectional bridging channel and the second quality of service level, a second message forwarded by the ground proxy server is received; the second message is a remote control message. The first service quality level and the second service quality level are different.

4. The near-space airship communication method according to claim 2, characterized in that, The second message is published by the ground client and received and forwarded by the ground proxy server.

5. The near-space airship communication method according to any one of claims 1 to 4, characterized in that, The step of sending the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path includes: If the first message topic matches any topic in the bridging topic list, the first message is sent to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

6. The near-space airship communication method according to any one of claims 1 to 4, characterized in that, The method further includes: Receive a connection request initiated by the first onboard client; the connection request includes identity credentials; The identity credential is verified by invoking a preset authentication strategy, and the verification result is obtained; If the verification result is successful, a communication connection is established with the first onboard client.

7. The near-space airship communication method according to claim 6, characterized in that, The method further includes: The onboard proxy server is deployed at a static Internet Protocol address, and listening is initiated on the network port corresponding to the static Internet Protocol address. Receiving the connection request initiated by the first submarine-borne client includes: During the listening process, a connection request initiated by the first submarine client to the static Internet Protocol address is received.

8. A near-space airship communication system, characterized in that, include: The establishment module is used to send a bridge establishment request to the ground agent server on the ground. The bridging establishment request is used to request the establishment of a bidirectional bridging channel between the shipborne proxy server and the ground proxy server via a satellite communication link. The receiving module is used to receive the first message published by the first onboard client. The first message carries the first message subject; The determination module is used to determine the forwarding path of the first message based on the first message topic; The forwarding path includes a local forwarding path for forwarding to the shipboard terminal equipment and a bridged forwarding path for forwarding to the ground terminal. The first sending module is used to send the first message to a second onboard client that has subscribed to the first message topic, based on the local forwarding path. The second sending module is used to send the first message to the ground proxy server through the bidirectional bridging channel based on the bridging forwarding path.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the near-space airship communication method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the near-space airship communication method as described in any one of claims 1 to 7.