A method and device for efficient data acquisition in a ubiquitous Internet of Things network integrating air, space, and ground

Abstract

This application relates to a method and apparatus for efficient data acquisition in a ubiquitous Internet of Things (IoT) network integrating air, space, and ground. Addressing the characteristics of this network—narrow bandwidth, long communication distance, and high latency—it clarifies the need for frequent transmission of small-load packets. Furthermore, since most media applications use IP / UDP / RTP protocols, this method employs efficient data encoding and header compression algorithms to achieve efficient data acquisition. This significantly reduces the redundancy of the payload and header in protocol messages, thereby reducing data volume without losing necessary information, decreasing data transmission and storage requirements, improving transmission efficiency and real-time data processing, and enabling efficient processing and management of large-scale data acquisition, resulting in a significant improvement in data acquisition efficiency.

Description

Technical Field

[0001] This invention belongs to the field of computer communication technology and relates to a method and device for efficient data acquisition in a ubiquitous Internet of Things (IoT) network that integrates air, space, and ground. Background Technology

[0002] With the rapid development of technologies such as wireless communication, space-air computing, and multimodal networks, especially the widespread application of unmanned aerial vehicles (UAVs), satellite internet, satellite IoT, and terrestrial IoT devices, the concept of an integrated air-space-ground ubiquitous IoT network (hereinafter referred to as the ubiquitous IoT network) is gradually becoming a reality. This network aims to achieve seamless global information coverage and service provision by integrating communication resources in the air (such as UAVs and airplanes), space (such as satellites and spacecraft), and the ground (such as autonomous vehicles, unmanned ships, and sensor networks) through multimodal network communication. The integrated air-space-ground ubiquitous IoT network requires the deployment of a large number of sensor devices to achieve real-time collection and monitoring of information such as environmental parameters and device status. Data acquisition technology, as a fundamental function of the IoT, is responsible for collecting information from various sensor data sources for subsequent processing and analysis. However, integrated air-space-ground ubiquitous IoT network devices such as satellites, UAVs, and unmanned vehicles and ships typically face challenges such as bandwidth limitations and sensitivity to communication latency. Traditional data acquisition protocols, such as MQTT (Message Queuing Telemetry Transport Protocol) and SNMP (Simple Network Management Protocol), support the data acquisition needs of IoT devices to a certain extent, but they do not fully consider the special environment of integrated air-space-ground networks in their design. Therefore, in practical applications, there are technical problems of insufficient data acquisition efficiency. Summary of the Invention

[0003] To address the problems existing in the above-mentioned traditional methods, this invention proposes an efficient data acquisition device and a method for an integrated air-space-ground ubiquitous Internet of Things (IoT) network, which can effectively realize efficient processing and management of large-scale data acquisition.

[0004] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0005] On the one hand, a high-efficiency data acquisition device for a ubiquitous Internet of Things (IoT) network integrating air, space, and ground is provided, comprising multiple clients and at least one server. The server is equipped with a message broker program. The message broker program includes a connection management module A1, a session management module A2, a message header compression management module A3, and a message broker module. The message broker module includes a message header decompression module A4, a decompression and decoding module A5, a message MIB library A6, a compression encoding module A7, a message header compression module A8, a subscription management module A9, a message sending module A10, and a message receiving module A11.

[0006] The client has a client program installed, which includes a message MIB library B1, a connection management module B2, a session management module B3, a message header compression management module B4, and a message publishing module; the message publishing module includes a data acquisition module B5, a compression encoding module B6, a message header compression module B7, and a message sending module B8;

[0007] When the client and server establish a connection, after the connection request message sent by the connection management module B2 arrives at the message header compression management module B4, the message header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier, creates new content for the context identifier and sets the compression status to the initialization and reset status, and sends the context identifier along with the connection request message to the message header compression management module A3.

[0008] The header compression management module A3 is initially in a context-free state. After receiving a connection request message, it looks up the context identifier, creates new content for the context identifier, sets the decompression status to full-text status, and then sends the connection request message to the connection management module A1. The connection management module A1 verifies whether the connection request message is valid. If it is invalid, it closes the network connection with the client. If it is valid, it sends a connection confirmation message with a return code of "0" to the header compression management module A3. The header compression management module A3 adds the decompression status to the connection confirmation message and sends it to the header compression management module B4. After receiving the decompression status in the connection confirmation message, the header compression management module B4 sets the compression status to secondary compression status to complete the header compression initialization work and sends the connection confirmation message to the connection management module B2. After receiving the connection confirmation message, the connection module B2 successfully establishes a connection between the client and the server.

[0009] When the client enables the message publishing module as a data publisher, the data acquisition module B5 reads the message definition from the message MIB library B1, obtains the specific data collected by the sensor, device interface, and data bus according to the message definition, and then sends it to the compression encoding module B6. The compression encoding module B6 encodes the specific data and compresses the message header to construct a data publishing message, and then sends the data publishing message to the message header compression module B7. The message header of the data publishing message includes a sequence number, node identifier, message ID, incremental compression identifier, and incremental compression mask. The incremental compression identifier is used to identify the incremental compression method of some fields in the message payload of the data publishing message, and the incremental compression mask is used to perform incremental compression on some fields in the message payload.

[0010] After determining the context information type based on the context identifier of the data publishing message, the header compression module B7 obtains the context information of the corresponding context information type from the header compression management module B4. It then compresses the regularly changing dynamic header field in the header of the data publishing message using the context information, and sends the compressed header data publishing message to the message receiving module A11 via the message sending module B8 at a set frequency, thus completing the current data acquisition.

[0011] On the other hand, a method for efficient data acquisition in a ubiquitous IoT network integrating air, space, and ground is also provided, applied to the aforementioned efficient data acquisition device for a ubiquitous IoT network integrating air, space, and ground. The data acquisition method includes the following steps:

[0012] When the client and server establish a connection, after the connection request message sent by the connection management module B2 arrives at the message header compression management module B4, the message header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier, creates new content for the context identifier and sets the compression status to the initialization and reset status, and sends the context identifier along with the connection request message to the message header compression management module A3.

[0013] The header compression management module A3 is initially in a contextless state. After receiving the connection request message, it looks up the context identifier, creates new content for the context identifier, sets the decompression state to full-text state, and then sends the connection request message to the connection management module A1.

[0014] Connection management module A1 verifies whether the connection request message is valid. If it is invalid, it closes the network connection with the client. If it is valid, it sends a connection confirmation message with a return code of "0" to header compression management module A3. Header compression management module A3 adds the decompression status to the connection confirmation message and then sends it to header compression management module B4.

[0015] After receiving the decompression status in the connection confirmation message, the header compression management module B4 sets the compression status to the second-level compression status to complete the header compression initialization work, and sends the connection confirmation message to the connection management module B2. After receiving the connection confirmation message, the connection module B2 successfully establishes a connection between the client and the server.

[0016] When the client enables the message publishing module as a data publisher, the data acquisition module B5 reads the message definition from the message MIB library B1, obtains the specific data collected by the sensor, device interface and data bus according to the message definition, and then sends it to the compression encoding module B6.

[0017] The compression encoding module B6 encodes the specific data and compresses the message header to construct a data publishing message, and then sends the data publishing message to the message header compression module B7. The message header of the data publishing message includes a sequence number, node identifier, message ID, incremental compression identifier, and incremental compression mask. The incremental compression identifier is used to identify the incremental compression method of some fields in the message payload of the data publishing message, and the incremental compression mask is used to perform incremental compression on some fields in the message payload.

[0018] After determining the context information type based on the context identifier of the data publishing message, the header compression module B7 obtains the context information of the corresponding context information type from the header compression management module B4. It then compresses the regularly changing dynamic header field in the header of the data publishing message using the context information, and sends the compressed header data publishing message to the message receiving module A11 via the message sending module B8 at a set frequency, thus completing the current data acquisition.

[0019] One of the above technical solutions has the following advantages and beneficial effects:

[0020] The aforementioned efficient data acquisition method and device for an integrated air-space-ground ubiquitous Internet of Things (IoT) network addresses the characteristics of this network, such as narrow bandwidth resources, long communication distances, and high communication latency. It clarifies that the network requires frequent transmission of small-load packets, and that most media applications use IP (Internet Protocol) / UDP (User Datagram Protocol) / RTP (Real-Time Transport Protocol) protocols for transmission, requiring each data packet to carry 40 or 60 bytes of encapsulation overhead. This results in significant overhead in the protocol header, sometimes exceeding the proportion of the effective payload, which greatly reduces the bandwidth utilization of the communication system. Therefore, the proposed solution employs efficient data encoding algorithms and packet header compression algorithms to achieve efficient data acquisition. This significantly reduces the redundancy of the effective payload and packet header in the protocol packets, thereby reducing data volume without losing necessary information, reducing data transmission volume and storage requirements, improving transmission efficiency and real-time data processing, and enabling efficient processing and management of large-scale data acquisition, ultimately leading to a significant improvement in data acquisition efficiency. Attached Figure Description

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

[0022] Figure 1This is a schematic diagram of the module structure of a high-efficiency data acquisition device for a ubiquitous Internet of Things (IoT) network that integrates air, space, and ground in one embodiment.

[0023] Figure 2 This is a schematic diagram of a simulation environment built using a general open research simulation platform in one embodiment;

[0024] Figure 3 This is a schematic diagram comparing the resource consumption of the present invention and the traditional method in a simulation environment for data acquisition simulation in one embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0027] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various locations throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments.

[0028] Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items, and all possible combinations thereof.

[0029] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0030] Traditional data acquisition protocols often suffer from the following limitations in current practical applications: limited bandwidth resources. Ubiquitous IoT networks, integrating air, space, and ground, often require processing massive amounts of data, and available bandwidth is frequently limited in wireless communication environments. Traditional data acquisition methods consume significant storage space and transmission bandwidth during data acquisition, potentially leading to low data transmission efficiency under bandwidth constraints. High real-time requirements are also a concern. In certain application scenarios of ubiquitous IoT networks, such as disaster monitoring and emergency response, extremely high real-time data processing is demanded. Traditional data acquisition methods result in high transmission latency when processing large amounts of data, failing to meet real-time requirements. To address these issues, there is an urgent need to develop a low-bandwidth, high-efficiency data acquisition technology. This technology should possess characteristics such as low bandwidth consumption and high performance, enabling it to adapt to network bandwidth-constrained environments while maintaining efficient data processing capabilities.

[0031] In the process of developing this invention, it was discovered that in the low-bandwidth environment of ubiquitous IoT networks integrating air, space, and ground, traditional encoding methods, without effective data compression, may lead to increased bandwidth requirements for transmission, making it difficult to efficiently utilize limited bandwidth. Furthermore, the narrow bandwidth resources, long communication distances, and high latency of ubiquitous IoT networks often necessitate frequent transmission of small-load packets. Most media applications use IP / UDP / RTP protocols, requiring each data packet to carry 40 or 60 bytes of encapsulation overhead. This results in significant overhead for the protocol header, sometimes exceeding the proportion of the payload, greatly reducing the bandwidth utilization of the communication system. Moreover, the header fields of consecutive data packets within the same data stream exhibit redundancy, which can be compressed to reduce header size. Therefore, efficient data encoding algorithms and header compression algorithms are effective ways to achieve efficient data acquisition. They can significantly reduce the redundancy of payload and header in protocol messages, thereby reducing data volume without losing necessary information, reducing data transmission and storage requirements, improving transmission efficiency and real-time data processing, and enabling efficient processing and management of large-scale data acquisition.

[0032] The following are explanations of the technical terms used in this article:

[0033] Message MIB Library: The message MIB library stores messages in a tree structure, where each piece of information is a labeled node in the MIB tree.

[0034] Message definition: All leaf nodes under a branch in the MIB tree are used to store the message definition of a certain type of message. A message definition typically includes the following:

[0035] Message ID: The message ID is a unique numeric identifier that identifies a message definition. It can be represented as a set of integers separated by periods, consisting of the labels of all nodes on the path from the root node to itself. The message ID specifies the type and purpose of the message.

[0036] Message description: A description of the message, i.e., a comment.

[0037] Message Fields: Fields in a message used for message encoding. Every message must have at least one message field, which has the following attributes:

[0038] Field type: Similar to data types in C structs. It can be a signed or unsigned integer type of 8, 16, 32 or 64 bytes, a single-precision or double-precision floating-point type, or an array type.

[0039] Field name: The descriptive name of the field.

[0040] Context: Context is the state maintained by the compressor and decompressor to correctly compress or decompress the header of the data stream. Conceptually, Context can be divided into two distinct parts: a static part and a dynamic part, which respectively maintain the state information required for compressing and decompressing static and dynamic fields in the packet header. Each Context is identified using a Context Identifier (CID).

[0041] CID (Context Identifier): A context identifier used to identify the context of packet header compression.

[0042] Profile: Used to identify IP packets of different protocol types. Each profile type is assigned a fixed profile number (PID) indicating the type of compressed IP packet.

[0043] IR (initiation and refresh state): This state is used to initialize and update static and dynamic field information in the context. In this state, the compression unit continuously sends all IP header information and flow association identifiers (PID and CID).

[0044] FO (first order): First-level compression state, in which the compression device only needs to transmit the complete dynamic header field information.

[0045] SO (second order): Second-level compression state, the highest level of compression state. At this time, the compressor transmits only the compression value of the dynamic domain according to the dynamic domain change law and sends the ROHC (a header compression method) compressed packet with the highest compression ratio.

[0046] NC (no context): No context state. The decompressor does not have static and dynamic field information of the IP header, and the compressor needs to send packets containing the complete header in IR state.

[0047] SC (static context): Static context state. The decompressor has obtained enough static field information, corresponding to the FO state of the compressor, and expects to receive compressed packets containing complete dynamic headers.

[0048] FC (full context): Full context state, the state in which the decompressor obtains sufficient static domain information and dynamic domain change pattern information, corresponding to the SO state of the compressor, and is able to receive compressed packets sent by the compressor in the SO state.

[0049] Please see Figure 1 In one embodiment, a high-efficiency data acquisition device 100 for a ubiquitous Internet of Things (IoT) network integrating air, space, and ground is provided, comprising multiple clients and at least one server. The server is equipped with a message broker program; the message broker program includes a connection management module A1, a session management module A2, a header compression management module A3, and a message broker module. The message broker module includes a header decompression module A4, a decompression and decoding module A5, a message MIB library A6, a compression encoding module A7, a header compression module A8, a subscription management module A9, a message sending module A10, and a message receiving module A11. The clients are equipped with a client program, which includes a message MIB library B1, a connection management module B2, a session management module B3, a header compression management module B4, and a message publishing module; the message publishing module includes a data acquisition module B5, a compression encoding module B6, a header compression module B7, and a message sending module B8.

[0050] When the client and server establish a connection, after the connection request message sent by the connection management module B2 arrives at the header compression management module B4, the header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier, creates new content for the context identifier and sets the compression status to initialization and reset, and sends the context identifier along with the connection request message to the header compression management module A3.

[0051] Initially, the header compression management module A3 is in a context-free state. Upon receiving a connection request message, it looks up the context identifier, creates new content for the context identifier, sets the decompression status to full-text state, and then sends the connection request message to the connection management module A1. The connection management module A1 verifies whether the connection request message is valid. If it is invalid, it closes the network connection with the client. If it is valid, it sends a connection confirmation message with a return code of "0" to the header compression management module A3. The header compression management module A3 adds the decompression status to the connection confirmation message and sends it to the header compression management module B4. After receiving the decompression status in the connection confirmation message, the header compression management module B4 sets the compression status to secondary compression status, completes the header compression initialization work, and sends the connection confirmation message to the connection management module B2. After receiving the connection confirmation message, the connection between the client and the server is successfully established.

[0052] When the client enables the message publishing module as a data publisher, the data acquisition module B5 reads the message definition from the message MIB library B1, obtains the specific data collected by sensors, device interfaces, and the data bus according to the message definition, and then sends it to the compression encoding module B6. The compression encoding module B6 encodes the specific data and compresses the message header to construct a data publishing message, which is then sent to the message header compression module B7. The message header of the data publishing message includes a sequence number, node identifier, message ID, incremental compression identifier, and incremental compression mask. The incremental compression identifier is used to identify the incremental compression method for some fields in the message payload of the data publishing message, and the incremental compression mask is used to perform incremental compression on some fields in the message payload.

[0053] After determining the context information type based on the context identifier of the data publishing message, the header compression module B7 obtains the context information of the corresponding context information type from the header compression management module B4. It then compresses the regularly changing dynamic header field in the header of the data publishing message using the context information, and sends the compressed header data publishing message to the message receiving module A11 via the message sending module B8 at a set frequency, thus completing the current data acquisition.

[0054] It's understandable that when a client establishes a connection with the server's message broker, authentication and message header compression initialization are required. Generally, the client initiates a network connection to the server's message broker, sending a connection request message carrying the client's existing identity information and initializing the message header compression context information, etc. The message broker receives the client's connection request message, initializes the message header compression context information, extracts the connection request information (such as the aforementioned identity information) from the connection request message for authentication, and returns a corresponding connection confirmation message and its compression feedback information to the client. The client receives and processes the connection confirmation message returned by the message broker and performs a compression state transition based on the compression feedback information within it. Specifically:

[0055] 2.1. The client's connection management module B2 sends a connection request message containing connection request information to the message broker's connection management module A1. The connection request message is first processed by the client's message header compression management module B4.

[0056] 2.2 After receiving the connection request message, the header compression management module B4 first determines whether the message can be compressed, i.e., it checks whether the message belongs to a protocol type supported by ROHC, such as IP, UDP, TCP, and RTP. If the message is not a protocol type that does not support compression, it cannot be compressed and no processing is performed; if it can be compressed, a compressor is created for the data stream of this message, and an unused CID is assigned to the data stream. A new content is created for the CID and the compression status is set to IR. Then, the CID is sent to the header compression management module A3 along with the connection request message.

[0057] 2.3 The message header compression management module A3 of the message broker is initially in NC state. After receiving the connection request message from the message header compression management module B4, it looks up the CID of the data stream, creates a new content for the CID and sets the decompression state to FC, and then sends the connection request message to the connection management module A1.

[0058] 2.4 The connection management module A1 of the message broker listens to the network and waits to receive connection request packets. If a connection request packet sent by a client is received, proceed to step 2.5; if no connection request packet is received from a client, proceed to step 2.4 to continue listening.

[0059] 2.5 When the connection management module A1 of the message broker receives a connection request message, it verifies the client's connection request. If the connection request message is invalid (e.g., incorrect message format, missing necessary fields, checksum failure), it directly closes the network connection with the client that sent the connection request message and proceeds to step 2.4. If the connection request message is valid, the connection management module A1 of the message broker sends a connection confirmation message with a return code of "0" to the message header compression management module A3 and sends the session information to the session management module A2. The session management module A2 updates the client access status information according to the client identifier and access time in the received session information, and then proceeds to step 2.4.

[0060] 2.6 After receiving the connection confirmation message from the connection management module A1, the header compression management module A3 adds the decompression status to the connection confirmation message and sends it to the header compression management module B4 on the client along with the connection confirmation message.

[0061] 2.7 After receiving the decompression status in the connection confirmation message, the header compression management module B4 sets the compression status to SO, the header compression initialization is completed, and then sends the connection confirmation message to the connection management module B2.

[0062] 2.8 The client's connection management module B2 waits to receive a connection confirmation message from the message broker's connection management module A1. After a successful connection, connection management module B2 generates corresponding session information and sends it to session management module B3. The session information includes the message broker's network address and access status. If the user uses this client as a message subscriber, the client will initiate the message subscription function; if the user uses this client as a data collection publisher, the client will initiate the data publishing function.

[0063] The aforementioned high-efficiency data acquisition device 100 for ubiquitous IoT networks integrating air, space, and ground addresses the characteristics of such networks, including narrow bandwidth resources, long communication distances, and high communication latency. It clarifies that these networks require frequent transmission of small-load packets, and that most media applications use IP (Internet Protocol) / UDP (User Datagram Protocol) / RTP (Real-Time Transport Protocol) protocols for transmission, requiring each data packet to carry 40 or 60 bytes of encapsulation overhead. This results in significant overhead in the protocol header, sometimes exceeding the proportion of the effective payload, which greatly reduces the bandwidth utilization of the communication system. Therefore, the aforementioned solution employs efficient data encoding algorithms and message header compression algorithms to achieve efficient data acquisition. This significantly reduces the redundancy of the effective payload and message header in the protocol messages, thereby reducing data volume without losing necessary information, reducing data transmission volume and storage requirements, improving transmission efficiency and real-time data processing, and enabling efficient processing and management of large-scale data acquisition, thus significantly improving data acquisition efficiency.

[0064] When a client enables the message publishing module as a data publisher, it can collect data, compress and encode the messages, and then send them to the message broker for processing. During this process, the client, acting as the data publisher, will collect, compress, and publish data to the message broker according to step 4.1 below. The message broker will then receive the data publishing messages published by the client as the data publisher according to step 4.2 below, decompress the data publishing messages, and update its local message MIB database based on the data publishing messages.

[0065] 4.1 The client, acting as the data publisher, collects, compresses, encodes, and publishes data to the message broker, including the following specific implementation steps 4.1.1 to 4.1.4:

[0066] 4.1.1 The data acquisition module B5, acting as the data publisher, reads the corresponding message definition from the message MIB library according to the information to be published, and obtains specific data from sensors, device interfaces, and data buses on the publisher's hardware device based on the message definition. The data acquisition module B5 then sends this data to the compression encoding module B6, which is the data publisher.

[0067] 4.1.2 The compression encoding module B6 of the client, acting as the data publisher, encodes the received data and compresses the message header to construct a data publishing message. Specifically, this may include steps 4.1.2.1 to 4.1.2.5:

[0068] 4.1.2.1 Constructing the header of the data publishing message: First, create an empty string of length 8 bytes as the header of the data publishing message. Then, fill in the various fields of the header, including the sequence number, node identifier, message ID, incremental compression identifier, and incremental compression mask. The message length is not filled in for the time being.

[0069] 4.1.2.3 Add message payload after the header of the data publishing message: The message payload contains all fields defined in the message definition. The message fields are enumerated sequentially by traversing all leaf nodes in the message definition node, and the specific data is added after the header of the data publishing message according to the field type. Incremental compression is performed on some field types. The incremental compression method is identified by an incremental compression identifier. The incremental compression identifier has two values: 0 and 1. A value of 0 indicates no incremental compression; a value of 1 indicates incremental compression using an incremental compression mask. The specific method is as follows:

[0070] 4.1.2.3.1 Initialize variable x to 1, set the total number of fields in the message definition to X, and cache the most recently sent data publishing message in the client acting as the data publisher, defining it as msg0;

[0071] 4.1.2.3.2 If x > X, then the message payload encoding and compression are complete, proceed to step 4.1.2.4. If x ≤ X, determine the value of the incremental compression identifier. If the value is 0, proceed to step 4.1.2.3.2.1; if the value is 1, proceed to step 4.1.2.3.2.2.

[0072] 4.1.2.3.2.1 If the value of the incremental compression identifier is 0, then add the field to the header of the data publishing message using the type defined in the xth field of the message definition, and proceed to step 4.1.2.3.2.

[0073] 4.1.2.3.2.2 The value of the incremental compression identifier is 1. At this time, it is determined whether the value of the x-th field has changed compared to the corresponding field in the msg0 payload. If there is no change, the value of the corresponding bit of the incremental compression mask field is set to 0; if there is a change, the value of the corresponding bit of the incremental compression mask field is set to 1, and the field is added to the header of the data publication message using the type defined in the x-th field type definition in the message definition, and then proceeds to step 4.1.2.3.2.

[0074] 4.1.2.4 Fill the message length field in the data publishing message: The message length is the length of the currently constructed data publishing message plus the length of the 2-byte checksum. Update the message length field at the message length position of the data publishing message.

[0075] 4.1.2.5 Add a checksum to the data publishing message: Calculate the checksum of the data publishing message using the CRC checksum algorithm and add the checksum to the end of the data publishing message to ensure message integrity. The data publishing message includes message length (2 bytes), sequence number (2 bytes), node identifier (2 bytes), message ID (14 bits), subject, message payload, checksum (2 bytes), incremental compression identifier (1 bit), and incremental compression mask (x bytes, depending on the number of messages defined in the message definition). The data publishing message is sent to the header compression module B7 of the client acting as the data publisher.

[0076] 4.1.3 After receiving the data publishing message, the header compression module B7 performs header compression on the data publishing message. Specifically:

[0077] 4.1.3.1 The header compression module B7 determines the context type of this group based on the CID of the data transmission message, and then obtains the corresponding context from the header compression management module B4.

[0078] 4.1.3.2 The header compression module B7 uses the context of the data publishing message to compress the regularly changing dynamic header fields in the header using the LSB and W-LSB compression algorithms, and then replaces the header with the compressed header. The compressed data publishing message is then sent to the message sending module B8.

[0079] 4.1.4 The message sending module B8 publishes the generated compressed packets to the message broker at a set frequency f (usually 1Hz, i.e., one round of data publication per second).

[0080] In one embodiment, after receiving the data publishing message, the message receiving module A11 sends it to the message header decompression module A4. The message header decompression module A4 determines whether there is a corresponding decompressor based on the context identifier of the data publishing message. If there is, it obtains the context information of the corresponding context identifier from the message header compression management module A3 and uses the decompressor to decompress the message header of the data publishing message according to the context information. If there is no decompressor, it creates a new decompressor first.

[0081] The header decompression module A4 verifies the decompressed header. If the verification result matches the verification field, it sends the decompressed data publication message to the decompression and decoding module A5; otherwise, it notifies the sender of the data publication message to retransmit and adjust the decompression level to a backgroundless state. After completing the decompression and decoding of the data publication message payload, the decompression and decoding module A5 sends the correctly decompressed packets to the message MIB database A6, updating the message MIB database A6. Specifically:

[0082] 4.2 The message receiving module A11 of the message broker receives the data publishing message published by the data publisher and then sends it to the message header decompression module A4 for message header decompression. The specific implementation process is as follows:

[0083] 4.2.1 After receiving the data transmission message, the header decompression module A4 first obtains the CID of the packet, looks up the decompressor for this data stream, and if it does not exist, it creates a new decompressor based on the information carried by the packet and obtains the corresponding context from the header compression management module A3; otherwise, it directly obtains the corresponding context.

[0084] 4.2.2 The header decompression module A4 decompresses the data transmission message based on the context, verifies the decompressed header, and compares the verification result with the verification field: if they are different, it indicates a decompression error, and a corresponding NACK is sent to the sender to notify the sender to retransmit, indicating that the header decompression module A4 did not have sufficient context for data stream decompression, and the decompression level is adjusted to NC; if they are the same, it indicates that the decompression is correct, and the data transmission message is sent to the decompression decoding module A5.

[0085] 4.3 The decompression and decoding module A5 receives the data publishing message, extracts the message ID and message payload from the message, retrieves the message definition from the message MIB library according to the message ID, processes and restores the original data of each field according to the type and order of each field in the message definition, and decompresses the compressed fields. The specific implementation process is as follows:

[0086] 4.3.1 Initialize variable x to 1, set the total number of fields in the message definition to X, and cache the most recently received data publication message in the message broker, defining it as msg0;

[0087] 4.3.2 Check the variable x. If x > X, it means the message payload decoding is complete, and proceed to step 4.2.4. If x ≤ X, determine and process the value of the incremental compression identifier. If the value is 0, proceed to step 4.3.2.1; if the value is 1, proceed to step 4.3.2.2.

[0088] 4.3.2.1 The value of the incremental compression identifier is 0. At this time, the fields are directly extracted and restored from the message payload according to the type specified in the message definition, and then proceed to step 4.3.2 to continue decompressing the remaining fields.

[0089] 4.3.2.2 The value of the incremental compression identifier is 1. At this time, the value in the data publishing message payload is used to replace the value of the field in msg0 corresponding to the bit with a value of 1 in the incremental compression mask. The field is extracted and restored from the message payload of msg0 according to the type specified in the message definition. Proceed to step 4.3.2 to continue decompressing the remaining fields.

[0090] 4.2.4 After completing the message payload decompression and decoding, the decompression and decoding module A5 sends the correctly decompressed packets to the message MIB library A, updates the corresponding data in the message MIB library, and then proceeds to step 4.2 to continue receiving data transmission messages. In the above process, the redundancy of the payload and message header in the protocol messages is significantly reduced, thereby reducing the data volume, transmission volume, and storage requirements without losing necessary information.

[0091] In one embodiment, the client program further includes a message subscription module, which includes a subscription management module B9, a decompression and decoding module B10, a message header decompression module B11, and a message receiving module B12.

[0092] When the client enables the message publishing module as a message subscriber, the subscription management module B9 sends a subscription message to the subscription management module A9. After listening to the subscription message, the subscription management module A9 verifies that the subscription message is valid, extracts the subscription information from the subscription message, creates a new subscription, and adds it to the subscription list. The subscription management module A9 sends a subscription confirmation message to the subscription management module B9. After the subscription management module B9 receives the subscription confirmation message and verifies the subscription status, the subscription is successful.

[0093] The subscription management module A9 extracts all data corresponding to the message ID from the message MIB database A6 based on the message ID in the subscription message. Then, it constructs a data publishing message through the compression encoding module A7. At the same time, the subscription management module A9 searches for subscriber information that has subscribed to the message ID in the subscription list. It then passes the data publishing message and subscriber information to the message header compression module A8. The message header compression module A8 obtains the message header compression context information from the message header compression management module A3 and performs message header compression on the data publishing message. Finally, it sends the header-compressed data publishing message to the message receiving module B12 of the client corresponding to the subscriber information through the message sending module A10.

[0094] After receiving the data publishing message, the message receiving module B12 sends it to the message header decompression module B11 for message header decompression. The message header decompression module B11 then sends the data publishing message with the decompressed message header to the decompression and decoding module B10 for message payload decompression and decoding. After obtaining all the data corresponding to the message ID, it sends it to the upper-layer application of the client.

[0095] As can be understood, a client acting as a message subscriber can subscribe to messages of a specified type in a message broker: the client sends a subscription message to the message broker, the message broker waits to receive and verify the subscription message, performs the client subscription, and sends a subscription confirmation message, which the client then verifies. The specific implementation process is as follows:

[0096] 3.1 The subscription management module B9 of the message subscriber sends a subscription message containing subscription information to the subscription management module A9 of the message broker in order to request to subscribe to a specified type of message.

[0097] 3.2 The message broker's subscription management module A9 listens to the network and waits for the subscription message sent by the client's subscription management module B9. If the subscription message sent by the client is received, proceed to step 3.3; if the subscription message sent by the client is not received, proceed to step 3.2 to continue listening.

[0098] 3.3 The subscription management module A9 verifies the validity of the subscription message. If the subscription message is invalid (e.g., incorrect message format, missing necessary fields, checksum failure, etc.), proceed to step 3.2. If the subscription message is valid, extract the subscription information from the subscription message and create a new subscription. Add the new subscription to the subscription list and then proceed to step 3.4.

[0099] 3.4 Subscription management module A9 sends a subscription confirmation message to subscription management module B9. The subscription confirmation message contains all subscription information from the subscription message sent by the message subscriber's subscription management module B9.

[0100] 3.5 Subscription management module B9 waits for and receives the subscription confirmation message from subscription management module A9 in the message broker, verifies the subscription status, and if the verification passes, the subscription is successful. If the verification fails, the subscription fails, and the process proceeds to step 3.1 to re-initiate the subscription request.

[0101] The message broker retrieves the corresponding message from the message MIB database according to the message type subscribed to by the message subscriber, constructs a data publication message, compresses and encodes it, and then sends it to the message subscriber. The client, acting as a message subscriber, receives the data publication message distributed by the message broker and decompresses and decodes it. The specific implementation process is as follows:

[0102] 5.1 The message broker extracts all data under the specified message ID node from the message MIB database based on the message ID in the message subscription message, constructs a data publishing message according to the same process as step 4.1.2 above, and at the same time, the subscription management module A9 searches the subscription list to obtain the subscriber information of all message subscribers who have subscribed to the message type corresponding to the message ID, and passes the data publishing message and the obtained subscriber information to the message broker's message header compression module A8, and proceeds to step 5.2.

[0103] 5.2 The header compression module A8 obtains the header compression context and other information from the header compression management module A3, compresses the header according to the process in step 4.1.3 above, and sends the compressed data publication message to the message sending module A10. The message sending module A10 sends the data publication message to the message receiving module B12 of the message subscriber's client, and then proceeds to step 5.1 to continue distributing the next data publication message.

[0104] 5.3 After receiving the data publishing message, the message receiving module B12, acting as the message subscriber, sends it to the message header decompression module B11 to decompress it according to the process in step 4.2 above, and then sends the decompressed complete data publishing message to the decompression decoding module B10.

[0105] 5.4 The decompression and decoding module B10 receives the data transmission message, decompresses and decodes the message payload according to the process described in step 4.3 above, and sends the data to the upper-layer application. At this point, the subscription process after data acquisition is complete, the overall service process ends, and both transmission efficiency and real-time data processing are significantly improved.

[0106] In some implementations, such as Figure 2 In the experimental example shown, a data acquisition scenario can be constructed. Specific operations include deploying a message broker on the virtual server Broker and deploying client programs on virtual nodes n1-n3 and p1-p3 respectively. In this scenario, nodes n1-n3 initiate data publishing, while nodes p1-p3 initiate message subscription. The experiment uses this system to collect system information such as CPU usage, system time, memory usage, and disk space of virtual nodes n1-n3, and obtains this system information by subscribing to it on nodes p1-p3. The message publishing frequency f is set to 1Hz, i.e., one round of data publishing per second, to verify the experimental effect.

[0107] To test the performance of the system provided by this invention in a large-scale and complex network environment, multiple client programs were run on each of the nodes n1 to n3, and the data publishing function was started to simulate a large-scale network environment.

[0108] like Figure 3 The diagram illustrates data acquisition in a simulated large-scale network environment. Using Wireshark (a free and open-source network packet analyzer capable of capturing and analyzing network packets) to capture packets at the acquisition nodes, the diagram shows the packet size statistics for different acquisition methods in a single round of data acquisition. It also demonstrates the use of a general-purpose open-source research simulation platform's traffic statistics function to calculate the total bandwidth usage for different acquisition methods under varying packet counts. Furthermore, it shows the total bandwidth resource usage of the system provided by this invention compared to traditional methods such as MQTT (Message Queuing Telemetry Transport), MQTT Headers Compressing, and MAVlink (Micro Air Vehicle Link, a drone communication protocol) under different packet counts. Figure 3 It can be seen that the system provided by this invention has significantly lower bandwidth usage than other traditional methods when completing the same data acquisition task. Experimental results show that the system provided by this invention significantly reduces bandwidth usage.

[0109] It is understood that each module in the aforementioned integrated air-space-ground ubiquitous Internet of Things (IoT) high-efficiency data acquisition device 100 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of devices with data processing capabilities, or stored in software within the memory of the aforementioned devices, so that the processor can call and execute the operations corresponding to each module. The aforementioned devices can be, but are not limited to, various types of communication devices already existing in the field.

[0110] In one embodiment, a method for efficient data acquisition in a ubiquitous IoT network integrating air, space, and ground is provided, applied to the aforementioned efficient data acquisition device for such a network. The data acquisition method includes the following steps:

[0111] When the client and server establish a connection, after the connection request message sent by the connection management module B2 arrives at the message header compression management module B4, the message header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier, creates new content for the context identifier and sets the compression status to the initialization and reset status, and sends the context identifier along with the connection request message to the message header compression management module A3.

[0112] The header compression management module A3 is initially in a contextless state. After receiving the connection request message, it looks up the context identifier, creates new content for the context identifier, sets the decompression state to full-text state, and then sends the connection request message to the connection management module A1.

[0113] Connection management module A1 verifies whether the connection request message is valid. If it is invalid, it closes the network connection with the client. If it is valid, it sends a connection confirmation message with a return code of "0" to header compression management module A3. Header compression management module A3 adds the decompression status to the connection confirmation message and then sends it to header compression management module B4.

[0114] After receiving the decompression status in the connection confirmation message, the header compression management module B4 sets the compression status to the second-level compression status to complete the header compression initialization work, and sends the connection confirmation message to the connection management module B2. After receiving the connection confirmation message, the connection module B2 successfully establishes a connection between the client and the server.

[0115] When the client enables the message publishing module as a data publisher, the data acquisition module B5 reads the message definition from the message MIB library B1, obtains the specific data collected by the sensor, device interface and data bus according to the message definition, and then sends it to the compression encoding module B6.

[0116] The compression encoding module B6 encodes the specific data and compresses the message header to construct a data publishing message, and then sends the data publishing message to the message header compression module B7. The message header of the data publishing message includes a sequence number, node identifier, message ID, incremental compression identifier, and incremental compression mask. The incremental compression identifier is used to identify the incremental compression method of some fields in the message payload of the data publishing message, and the incremental compression mask is used to perform incremental compression on some fields in the message payload.

[0117] After determining the context information type based on the context identifier of the data publishing message, the header compression module B7 obtains the context information of the corresponding context information type from the header compression management module B4. It then compresses the regularly changing dynamic header field in the header of the data publishing message using the context information, and sends the compressed header data publishing message to the message receiving module A11 via the message sending module B8 at a set frequency, thus completing the current data acquisition.

[0118] The aforementioned efficient data acquisition method for ubiquitous IoT networks integrating air, space, and ground addresses the characteristics of these networks, such as narrow bandwidth resources, long communication distances, and high communication latency. It clarifies that these networks require frequent transmission of small-load packets, and that most media applications use IP (Internet Protocol) / UDP (User Datagram Protocol) / RTP (Real-Time Transport Protocol) protocols for transmission, requiring each data packet to carry 40 or 60 bytes of encapsulation overhead. This results in significant overhead in the protocol header, sometimes exceeding the proportion of the effective payload, which greatly reduces the bandwidth utilization of the communication system. Therefore, the proposed solution employs efficient data encoding and header compression algorithms to achieve efficient data acquisition. This significantly reduces the redundancy of the payload and header in the protocol messages, thereby reducing data volume without losing necessary information, decreasing data transmission and storage requirements, improving transmission efficiency and real-time data processing, and enabling efficient processing and management of large-scale data acquisition, ultimately leading to a significant improvement in data acquisition efficiency.

[0119] In one embodiment, the efficient data acquisition method for an integrated air-space-ground ubiquitous Internet of Things network may further include the following steps:

[0120] After receiving the data transmission message, the message receiving module A11 sends it to the message header decompression module A4;

[0121] The header decompression module A4 determines whether there is a corresponding decompressor based on the context identifier of the data publishing message. If there is, it obtains the context information of the corresponding context identifier from the header compression management module A3 and uses the decompressor to decompress the header of the data publishing message based on the context information. If there is no decompressor, it creates a new decompressor first.

[0122] The header decompression module A4 verifies the decompressed header. If the verification result is the same as the verification field, the data publishing message after header decompression is sent to the decompression decoding module A5. Otherwise, the sender of the data publishing message is notified to retransmit and the decompression level is adjusted to the no-texture state.

[0123] After decompressing and decoding the payload of the data publication message, the decompression and decoding module A5 sends the correctly decompressed packets to the message MIB library A6 and updates the message MIB library A6.

[0124] In one embodiment, the client program further includes a message subscription module, which comprises a subscription management module B9, a decompression and decoding module B10, a message header decompression module B11, and a message receiving module B12. The above data acquisition method may also include the following steps:

[0125] When the client enables the message publishing module as a message subscriber, the subscription management module B9 sends a subscription message to the subscription management module A9.

[0126] After the subscription management module A9 listens to the subscription message and verifies its validity, it extracts the subscription information from the message, creates a new subscription, and adds it to the subscription list. The subscription management module A9 then sends a subscription confirmation message to the subscription management module B9. Once the subscription management module B9 receives the confirmation message and verifies the subscription status, the subscription is successful.

[0127] After the subscription management module A9 extracts all data corresponding to the message ID from the message MIB library A6 based on the message ID in the subscription message, it constructs a data publishing message through the compression encoding module A7. At the same time, the subscription management module A9 searches for subscriber information that has subscribed to the message ID in the subscription list and passes the data publishing message and subscriber information to the message header compression module A8.

[0128] After obtaining the context information of the header compression from the header compression management module A3, the header compression module A8 compresses the header of the data publishing message and sends the header-compressed data publishing message to the message receiving module B12 of the client corresponding to the subscriber information through the message sending module A10.

[0129] After receiving the data publishing message, the message receiving module B12 sends it to the message header decompression module B11 for message header decompression. The message header decompression module B11 then sends the data publishing message with the decompressed message header to the decompression and decoding module B10 for message payload decompression and decoding. After obtaining all the data corresponding to the message ID, it sends it to the upper-layer application of the client.

[0130] For specific limitations on the efficient data acquisition method for the integrated air-space-ground ubiquitous Internet of Things network, please refer to the corresponding limitations of the integrated air-space-ground ubiquitous Internet of Things network efficient data acquisition device 100 mentioned above, which will not be repeated here.

[0131] In one embodiment, a data transmission device is also provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described efficient data acquisition method for an integrated air-space-ground ubiquitous Internet of Things network.

[0132] It is understood that, in addition to the memory and processor mentioned above, the data transmission device may also include other hardware and software components not listed in this specification. The specific components may be determined according to the specific communication data transmission model in different application scenarios, and will not be listed and described in detail in this specification.

[0133] In one embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described efficient data acquisition method for an integrated air-space-ground ubiquitous Internet of Things network.

[0134] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0136] The above embodiments merely illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, all of which fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A space-air-ground integrated ubiquitous Internet of Things network efficient data acquisition device, characterized in that, The system comprises a plurality of clients and at least one server, wherein the server is installed with a message broker program; the message broker program comprises a connection management module A1, a session management module A2, a message header compression management module A3 and a message broker module; the message broker module comprises a message header decompression module A4, a decompression decoding module A5, a message MIB library A6, a compression encoding module A7, a message header compression module A8, a subscription management module A9, a message sending module A10 and a message receiving module A11; The client is installed with a client program, which comprises a message MIB library B1, a connection management module B2, a session management module B3, a message header compression management module B4 and a message publishing module; the message publishing module comprises a data acquisition module B5, a compression encoding module B6, a message header compression module B7 and a message sending module B8; When the client establishes a connection with the server, the connection request message sent by the connection management module B2 reaches the message header compression management module B4, the message header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier, creates a new content for the context identifier and sets the compression state to the initialization and reset state, and sends the context identifier to the message header compression management module A3 together with the connection request message; The message header compression management module A3 is initially in the no context state, and after receiving the connection request message, it searches for the context identifier, creates a new content for the context identifier and sets the decompression state to the full context state, and then sends the connection request message to the connection management module A1; the connection management module A1 verifies whether the connection request message is legal, and if not, closes the network connection with the client, and if so, sends a connection confirmation message with a return code of "0" to the message header compression management module A3; the message header compression management module A3 adds the decompression state to the connection confirmation message and sends it to the message header compression management module B4; after receiving the decompression state in the connection confirmation message, the message header compression management module B4 sets the compression state to the secondary compression state to complete the message header compression initialization, and sends the connection confirmation message to the connection management module B2; after receiving the connection confirmation message, the client establishes a successful connection with the server. When the client enables the message publishing module as a data publisher, the data collection module B5 reads a message definition from the message MIB library B1, acquires specific data collected by sensors, device interfaces and data buses according to the message definition, and sends the specific data to the compression and encoding module B6; the compression and encoding module B6 encodes the specific data and packet header compression to construct a data publishing packet, and sends the data publishing packet to the packet header compression module B7; the packet header of the data publishing packet includes a sequence number, a node identifier, a message ID, an incremental compression identifier and an incremental compression mask; the incremental compression identifier is used to identify the incremental compression method of part of the fields in the message load of the data publishing packet, and the incremental compression mask is used to perform incremental compression on part of the fields in the message load; The packet header compression module B7 determines the context information type according to the context identifier of the data publishing packet, acquires the context information corresponding to the context information type from the packet header compression management module B4, compresses the dynamic header field that changes regularly in the packet header of the data publishing packet through the context information, and obtains the data publishing packet after packet header compression, which is sent to the packet receiving module A11 at a set frequency through the packet sending module B8, to complete the current data collection.

2. The space-air-ground integrated WIO network efficient data collection device according to claim 1, wherein, After receiving the data publishing packet, the packet receiving module A11 sends the data publishing packet to the packet header decompression module A4; the packet header decompression module A4 determines whether there is a corresponding decompressor according to the context identifier of the data publishing packet, and if there is, acquires the context information corresponding to the context identifier from the packet header compression management module A3, and performs packet header decompression on the data publishing packet according to the context information using the decompressor; if there is not, a new decompressor is created first; The packet header decompression module A4 checks the decompressed packet header, and if the checking result is the same as the checking field, sends the data publishing packet after packet header decompression to the decompression and decoding module A5, otherwise, notifies the sender of the data publishing packet to perform retransmission processing and adjusts the decompression level to no context state; After completing the decompression and decoding of the packet load of the data publishing packet, the decompression and decoding module A5 sends the packet with correct decompression to the message MIB library A6, and updates the message MIB library A6. 3.The space-air-ground integrated ubiquitous network high-efficiency data acquisition device according to claim 1 or 2, characterized in that, The client program further includes a message subscription module, and the message subscription module includes a subscription management module B9, a decompression and decoding module B10, a packet header decompression module B11 and a packet receiving module B12; When the client enables the message publishing module as a message subscriber, the subscription management module B9 sends a subscription message to the subscription management module A9. After the subscription management module A9 listens to the subscription message and verifies that the subscription message is legal, the subscription management module A9 extracts subscription information from the subscription message and creates a new subscription and adds it to a subscription list. The subscription management module A9 sends a subscription confirmation message to the subscription management module B9. After the subscription management module B9 receives the subscription confirmation message and verifies the subscription state, the subscription is successful. After the subscription management module A9 extracts all data corresponding to the message ID from the message MIB library A6 according to the message ID in the subscription message, the subscription management module A9 constructs a data publishing message through the compression encoding module A7. Meanwhile, the subscription management module A9 finds the subscriber information of the message ID in the subscription list and delivers the data publishing message and the subscriber information to the message header compression module A8. After the message header compression module A8 obtains context information of message header compression from the message header compression management module A3, the message header compression module A8 performs message header compression on the data publishing message. The data publishing message after message header compression is sent to the message receiving module B12 of the client corresponding to the subscriber information through the message sending module A10. After the message receiving module B12 receives the data publishing message, the message receiving module B12 sends the data publishing message to the message header decompression module B11 for message header decompression. The message header decompression module B11 sends the data publishing message after message header decompression to the decompression decoding module B10 for message payload decompression and decoding. After obtaining all data corresponding to the message ID, the data is sent to the upper application of the client.

4. A space-air-ground integrated ubiquitous Internet of Things network efficient data collection method, characterized in that, The data acquisition method is applied to the space-ground-integrated ubiquitous Internet of Things network efficient data acquisition device of any one of claims 1 to 3. The data acquisition method comprises the following steps: When the client and the server establish a connection, the connection request message sent by the connection management module B2 reaches the message header compression management module B4. The message header compression management module B4 creates a compressor for the compressible connection request message and allocates an unused context identifier. The message header compression management module B4 creates a new content for the context identifier and sets the compression state to initialization and reset state. The message header compression management module B4 sends the context identifier with the connection request message to the message header compression management module A3. The message header compression management module A3 is initially in a no context state. After receiving the connection request message, the message header compression management module A3 finds the context identifier, creates a new content for the context identifier, sets the decompression state to full context state, and sends the connection request message to the connection management module A1. The connection management module A1 verifies whether the connection request message is legal, and if not, closes the network connection with the client, and if so, sends a connection confirmation message with a return code of "0" to the message header compression management module A3, and the message header compression management module A3 adds a decompression state to the connection confirmation message and sends it to the message header compression management module B4; After receiving the decompression state in the connection confirmation message, the message header compression management module B4 sets the compression state to a two-level compression state to complete the message header compression initialization, and sends the connection confirmation message to the connection management module B2, and after receiving the connection confirmation message, the client and the server establish a successful connection; When the client enables the message publishing module as a data publisher, the data collection module B5 reads the message definition from the message MIB library B1, acquires specific data collected by sensors, device interfaces and data buses according to the message definition, and sends the specific data to the compression encoding module B6; The compression encoding module B6 encodes and compresses the specific data to construct a data publishing message, and sends the data publishing message to the message header compression module B7; the message header of the data publishing message includes a sequence number, a node identifier, a message ID, an incremental compression identifier and an incremental compression mask; the incremental compression identifier is used to identify the incremental compression method of part of the fields in the message payload of the data publishing message, and the incremental compression mask is used to perform incremental compression on part of the fields in the message payload; The message header compression module B7 determines the context information type according to the context identifier of the data publishing message, acquires context information corresponding to the context information type from the message header compression management module B4, and compresses the dynamic header field that changes regularly in the message header of the data publishing message through the context information, to obtain the data publishing message after message header compression, which is sent to the message receiving module A11 at a set frequency through the message sending module B8, to complete the current data collection.

5. The space-air-ground integrated WIO network efficient data collection method according to claim 4, characterized in that, Further comprising the steps of: The message receiving module A11 receives the data publishing message and sends it to the message header decompression module A4; The message header decompression module A4 determines whether there is a corresponding decompressor according to the context identifier of the data publishing message, and if so, acquires context information corresponding to the context identifier from the message header compression management module A3, and performs message header decompression on the data publishing message according to the context information using the decompressor, and if not, a new decompressor is created first; The message header decompression module A4 checks the decompressed message header, and if the result of the check is the same as the check field, the data publishing message after message header decompression is sent to the decompression decoding module A5, otherwise the sender of the data publishing message is notified to perform retransmission processing and adjust the decompression level to no context state. The decompression and decoding module A5 sends the decompression-corrected packet to the message MIB library A6 after completing the packet payload decompression and decoding of the data publishing packet, and updates the message MIB library A6.

6. The efficient data collection method for space-air-ground integrated ubiquitous network according to claim 4 or 5, characterized in that, The client program of the client further comprises a message subscription module, and the message subscription module comprises a subscription management module B9, a decompression and decoding module B10, a packet header decompression module B11 and a packet receiving module B12. The data collection method further comprises the steps of: When the client enables the message publishing module as a message subscriber, the subscription management module B9 sends a subscription packet to the subscription management module A9; After the subscription management module A9 verifies that the subscription packet is legal, the subscription management module A9 extracts subscription information from the subscription packet and creates a new subscription to add to a subscription list, sends a subscription confirmation packet to the subscription management module B9, and after the subscription management module B9 receives the subscription confirmation packet and verifies the subscription state, the subscription is successful; The subscription management module A9 extracts all data corresponding to the message ID from the message MIB library A6 according to the message ID in the subscription packet, constructs a data publishing packet through the compression and encoding module A7, and simultaneously finds the subscriber information of the message ID in the subscription list, and delivers the data publishing packet and the subscriber information to the packet header compression module A8; The packet header compression module A8 obtains context information of packet header compression from the packet header compression management module A3, and performs packet header compression on the data publishing packet, and sends the data publishing packet after packet header compression to the packet receiving module B12 of the client corresponding to the subscriber information through the packet sending module A10; The packet receiving module B12 receives the data publishing packet and sends it to the packet header decompression module B11 for packet header decompression, and the packet header decompression module B11 sends the data publishing packet after packet header decompression to the decompression and decoding module B10 for packet payload decompression and decoding, and obtains all data corresponding to the message ID and sends it to the upper layer application of the client.

Images