Data transmission method and device, nonvolatile storage medium and electronic equipment

Abstract

The application discloses a data transmission method and device, a nonvolatile storage medium and an electronic device. The method comprises the following steps: filling a device identifier into a device identifier field of an uplink data packet; determining a data source of to-be-sent uplink data, setting a source flag bit of a data type field in the uplink data packet according to the data source; filling a current count value into a packet sequence number field of the uplink data packet and updating a packet sequence number counter; calculating a whole packet length of the uplink data packet according to a sum of byte numbers of the device identifier field, the data type field, the packet sequence number field, a whole packet length field and a payload field of the uplink data packet, and filling the whole packet length into the whole packet length field; and sending the filled uplink data packet to an Internet of Things platform. The application solves the technical problems of low transmission efficiency, poor real-time performance and high operation and maintenance cost caused by large protocol overhead, high connection establishment delay and complex terminal adaptation in a satellite Internet of Things architecture.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and more specifically, to a data transmission method, apparatus, non-volatile storage medium, and electronic device. Background Technology

[0002] Against the backdrop of the convergence of satellite communication and the Internet of Things, traditional communication architectures face significant bottlenecks in Tiantong satellite scenarios, hindering their large-scale application:

[0003] Low transmission efficiency: Traditional solutions generally use the HTTP / 1.1 protocol, which has a request header overhead of about 140 bytes. With the limited bandwidth of Tiantong satellite (about 350 bytes / second), the protocol overhead accounts for as much as 40%, resulting in an effective payload transmission rate of only 210 bytes / second. This leads to extremely low bandwidth utilization and cannot meet the needs of high-frequency data transmission.

[0004] Severe transmission latency: Traditional protocol stacks based on TCP / IP and SSL / TLS involve complex handshake, certificate verification, and teardown processes. In an environment where the round-trip time (RTT) of the Tiantong satellite link is approximately 1700ms, the establishment and release of a single connection takes more than 6 seconds and involves multiple protocol negotiations, resulting in the inability to meet the real-time requirements of IoT services.

[0005] Terminal adaptation is difficult: Traditional architectures require third-party device data to be parsed and repackaged into HTTP protocol via the terminal, forming a lengthy "device → terminal → platform" link. This not only increases the development threshold (long adaptation cycle), but also leads to batch updates of terminal firmware when the protocol is upgraded, resulting in an exponential increase in operation and maintenance costs, and a low data interaction success rate.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides a data transmission method, apparatus, non-volatile storage medium, and electronic device to at least solve the technical problems of low transmission efficiency, poor real-time performance, and high operation and maintenance costs caused by the large protocol overhead, high connection establishment delay, and complex terminal adaptation in satellite Internet of Things architecture.

[0008] According to one aspect of this application, a data transmission method is provided, applied to a satellite terminal device, comprising: reading device registration information of the satellite terminal device, generating a device identifier based on the device registration information, and filling the device identifier into the device identifier field of an uplink data packet; determining the data source of the uplink data to be transmitted, setting a source flag bit in the data type field of the uplink data packet according to the data source, wherein the source flag bit takes a first flag value when the data source is a built-in sensor of the satellite terminal device, and takes a second flag value when the data source is an external device; obtaining the current count value of a packet sequence number counter, filling the current count value into the packet sequence number field of the uplink data packet, and updating the packet sequence number counter, wherein the packet sequence number counter increments by one step for each uplink data packet transmitted from its initial value, and resets to zero after reaching a preset upper limit value; calculating the total packet length of the uplink data packet based on the sum of the byte counts of the device identifier field, data type field, packet sequence number field, total packet length field of the uplink data packet, and payload field, and filling the total packet length into the total packet length field, wherein the payload field is used to carry the uplink data; and sending the filled uplink data packet to an Internet of Things platform.

[0009] Optionally, the device identifier field is 4 bytes, and the device identifier adopts ASCII encoding format or UUID format; the data type field is 1 byte and adopts bit field definition; the source flag bit is the 0th bit of the data type field, the first flag value is 0, and the second flag value is 1.

[0010] Optionally, after setting the source flag bit of the data type field in the uplink data packet according to the data source, the method further includes: setting the feedback flag bit of the data type field according to the response feedback status of the uplink data packet, wherein the feedback flag bit is the 7th bit of the data type field; the feedback flag bit takes the third flag value when the uplink data packet is used to carry response feedback information; the response feedback information includes acknowledgment response information or negative response information; and filling the reserved bits in the data type field other than the source flag bit and the feedback flag bit with 0, wherein the reserved bits are used to carry priority identifiers or data type classification identifiers.

[0011] Optionally, after sending the padded uplink data packet to the IoT platform, the method further includes: determining whether to retransmit the corresponding uplink data packet based on the response feedback information identified by the feedback flag; and before updating the packet sequence number counter, associating and storing the current count value of the packet sequence number counter with the uplink data packet so that, in the event of a packet loss indication from the IoT platform, the corresponding uplink data packet can be retransmitted based on the associated stored current count value.

[0012] Optionally, the packet sequence number field is 2 bytes; the packet sequence number counter has a value range of 0 to 65535, an initial value of 0, a step size of 1, and a preset upper limit value of 65535; the uplink data is data transmitted in packets, and the packet sequence number field is used to identify the order and control the reassembly of the data transmitted in packets on the IoT platform.

[0013] Optionally, the total packet length field is 2 bytes. The total packet length is the number of complete bytes of the uplink data packet, including the device identifier field, data type field, packet sequence number field, and total packet length field. The total packet length is stored in the total packet length field in big-endian byte order.

[0014] Optionally, the uplink data carried by the payload field is encoded in binary or JSON format; the number of bytes in the payload field does not exceed a preset payload threshold, wherein the preset payload threshold is determined based on the payload of a single satellite frame.

[0015] According to another aspect of this application, a data transmission method applied to an Internet of Things (IoT) platform is also provided, comprising: generating a downlink instruction according to business requirements; setting an object flag bit in the downlink data type field of the downlink data packet according to the instruction object of the downlink instruction, wherein the object flag bit takes a first object value when the instruction object is a satellite terminal device and a second object value when the instruction object is an external device; setting a type flag bit in the downlink data type field according to the instruction type of the downlink instruction, wherein the type flag bit is used to identify the pass-through type, configuration type, or upgrade type; filling the downlink packet sequence number into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number; filling the instruction parameters of the downlink instruction into the payload field of the downlink data packet; and sending the filled downlink data packet to a satellite so that the satellite can broadcast the downlink data packet to the satellite terminal device.

[0016] Optionally, the downlink data packet includes: a downlink data type field, a packet sequence number field, a downlink data packet length field, and a payload field arranged in sequence; the downlink data type field is 1 byte, the packet sequence number field is 2 bytes, and the packet length field is 2 bytes.

[0017] Optionally, the instruction parameters carried by the payload field are encoded in binary instruction code or JSON format, wherein the instruction parameters include device configuration parameters or upgrade firmware fragments; the total packet length field indicates the total packet length as the number of complete bytes of the downlink data packet, including the downlink data type field, packet sequence number field, total packet length field and payload field.

[0018] Optionally, the downlink data type field is defined using a bit field, with the object flag bit being the 0th bit of the downlink data type field, the first object value being 0, and the second object value being 1.

[0019] Optionally, the type flag is the 3rd to 5th bit of the downlink data type field. The type flag is 0 when identifying the pass-through type, 1 when identifying the configuration type, and 2 when identifying the upgrade type. The reserved bits in the downlink data type field, except for the object flag and the type flag, are 0. The reserved bits are used to carry the priority flag or the instruction subtype flag.

[0020] Optionally, the packet sequence number field has a value range of 0 to 65535. The downlink packet sequence number increments by one step for each downlink data packet sent from the initial value and returns to zero after reaching 65535 for cyclic counting. The downlink packet sequence number is used to instruct the satellite terminal equipment to execute downlink commands in sequence.

[0021] According to another aspect of this application, a data transmission apparatus is also provided, comprising: a first filling module, configured to read device registration information of a satellite terminal device, generate a device identifier based on the device registration information, and fill the device identifier into the device identifier field of an uplink data packet; a first setting module, configured to determine the data source of the uplink data to be transmitted, and set a source flag bit in the data type field of the uplink data packet according to the data source, wherein the source flag bit takes a first flag value when the data source is a built-in sensor of the satellite terminal device, and takes a second flag value when the data source is an external device; and an update module, configured to obtain the current packet sequence number counter. The counting module fills the current count value into the packet sequence number field of the uplink data packet and updates the packet sequence number counter. The packet sequence number counter increments by one step for each uplink data packet sent, starting from the initial value, and resets to zero after reaching a preset upper limit. The calculation module calculates the total packet length of the uplink data packet based on the sum of the byte counts of the device identification field, data type field, packet sequence number field, total packet length field of the uplink data packet, and payload field, and fills the total packet length into the total packet length field. The payload field is used to carry uplink data. The first sending module sends the filled uplink data packet to the IoT platform.

[0022] According to another aspect of this application, a data transmission apparatus is also provided, comprising: a generation module for generating downlink instructions according to business requirements; a second setting module for setting an object flag bit in the downlink data type field of the downlink data packet according to the instruction object of the downlink instruction, wherein the object flag bit takes a first object value when the instruction object is a satellite terminal device and a second object value when the instruction object is an external device; a third setting module for setting a type flag bit in the downlink data type field according to the instruction type of the downlink instruction, wherein the type flag bit is used to identify a pass-through type, a configuration type, or an upgrade type; a second filling module for filling the downlink packet sequence number into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number; a third filling module for filling the instruction parameters of the downlink instruction into the payload field of the downlink data packet; and a second sending module for sending the filled downlink data packet to a satellite so that the satellite can broadcast the downlink data packet to the satellite terminal device.

[0023] According to another aspect of this application, a non-volatile storage medium is also provided, the storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above data transmission method.

[0024] According to another aspect of this application, an electronic device is also provided, comprising: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the above-described data transfer method during runtime.

[0025] According to another aspect of this application, a computer program is also provided, wherein the computer program, when executed by a processor, implements the above-described data transmission method.

[0026] According to another aspect of this application, a computer program product is also provided, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, which, when executed by a processor, implements the above-described data transmission method.

[0027] In this application, the following steps are employed: First, the device registration information of the satellite terminal device is read. A device identifier is generated based on the device registration information and filled into the device identifier field of the uplink data packet. Second, the data source of the uplink data to be sent is determined. A source flag bit in the data type field of the uplink data packet is set according to the data source. The source flag bit takes a first flag value when the data source is a built-in sensor of the satellite terminal device and a second flag value when the data source is an external device. Third, the current count value of the packet sequence number counter is obtained and filled into the packet sequence number field of the uplink data packet. The packet sequence number counter increments by one step for each uplink data packet sent from its initial value and resets to zero after reaching a preset upper limit. Finally, the data source flag bit is set according to the device identifier field, data type field, and packet sequence number field. The total length of the uplink data packet is calculated by summing the byte counts of the header field, the total length field, and the payload field. This total length is then filled into the total length field. The payload field carries the uplink data. The padded uplink data packet is then sent to the IoT platform. This method achieves the goal of building a lightweight custom application layer protocol and eliminating the redundant overhead of the traditional HTTP / TCP protocol. This results in significantly reducing protocol header overhead to improve link transmission efficiency, simplifying the connection establishment process to reduce transmission latency, and reducing the adaptation and maintenance costs of third-party devices through standardized interfaces. In turn, it solves the technical problems of low transmission efficiency, poor real-time performance, and high operation and maintenance costs caused by high protocol overhead, high connection establishment latency, and complex terminal adaptation in satellite IoT architecture. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0029] Figure 1 This is a flowchart of a data transmission method according to an embodiment of this application;

[0030] Figure 2 This is a flowchart of another data transmission method according to an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of a service transmission model according to an embodiment of this application;

[0032] Figure 4 This is a structural diagram of a data transmission device according to an embodiment of this application;

[0033] Figure 5 This is a structural diagram of another data transmission device according to an embodiment of this application;

[0034] Figure 6 This is a hardware structure block diagram of a computer terminal according to an embodiment of the present application of a data transmission method. Detailed Implementation

[0035] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] According to an embodiment of this application, a method embodiment for data transmission is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0038] Figure 1 This is a flowchart of a data transmission method according to an embodiment of this application, which is applied to a satellite terminal device, such as... Figure 1 As shown, the method includes the following steps:

[0039] Step S101: Read the device registration information of the satellite terminal device, generate a device identifier based on the device registration information, and fill the device identifier into the device identifier field of the uplink data packet.

[0040] In step S101, during initialization or startup, the satellite terminal device reads pre-configured device registration information from the local storage medium. This registration information contains the device's unique identification data. The terminal software generates a 4-byte device identifier (Device ID) according to a preset algorithm (such as directly extracting a hash value or mapping it to a specific encoding). This device identifier can be in ASCII encoding or UUID format to ensure global uniqueness. Subsequently, the terminal writes the device identifier into the first to fourth bytes (device identifier field) of the uplink data packet to be sent.

[0041] Step S102: Determine the data source of the uplink data to be sent, and set the source flag bit of the data type field in the uplink data packet according to the data source. The source flag bit takes the first flag value when the data source is the built-in sensor of the satellite terminal equipment, and takes the second flag value when the data source is an external device.

[0042] In step S102, after receiving data from a serial port (such as RS232 / RS485 / CAN) or an internal sensor module, the terminal determines the source of the data.

[0043] If the data originates from the built-in sensors (such as temperature and humidity sensors) of the satellite terminal equipment, the least significant bit (bit0, i.e., the source flag bit) of the data type field (ULDataType, 1 byte) in the uplink data packet is set to the first flag value (e.g., 0).

[0044] If the data originates from an external third-party device (such as a smart meter or GPS module) connected to the terminal's serial port, the source flag is set to the second flag value (e.g., 1). The remaining bits (bits 1-6) can be reserved for future expansion (such as priority), and bit 7 can be used for ACK feedback. With this bit field design, only one byte is needed to distinguish the data source, greatly saving protocol overhead.

[0045] Step S103: Obtain the current count value of the packet sequence number counter, fill the current count value into the packet sequence number field of the uplink data packet, and update the packet sequence number counter. The packet sequence number counter increments by one step for each uplink data packet sent from the initial value, and returns to zero after reaching the preset upper limit value.

[0046] In step S103, the terminal maintains a packet sequence number counter. Before sending each data packet, the current value of the counter is read and used as a 2-byte packet sequence number to fill the 5th and 6th bytes of the uplink data packet. Subsequently, the terminal increments the counter value by a step (e.g., 1). When the counter value reaches a preset upper limit (e.g., 65535, corresponding to the maximum value of a 16-bit unsigned integer), it is reset to zero before the next transmission, thus implementing cyclic counting. Step S103 can support sequence reassembly and packet loss detection during large data packet transmission.

[0047] Step S104: Calculate the total length of the uplink data packet based on the sum of the number of bytes in the device identifier field, data type field, packet sequence number field, total length of uplink data packet field, and payload field, and fill the total length field with the total length field. The payload field is used to carry uplink data.

[0048] In step S104, the terminal calculates the total length of the entire data packet. The calculation formula is:

[0049] Total packet length = Device identifier field length (4 bytes) + Data type field length (1 byte) + Packet serial number field length (2 bytes) + Total packet length field length (2 bytes) + Payload field length (N bytes).

[0050] The calculated total length value (2 bytes, big-endian) is filled into bytes 7 and 8 of the uplink data packet (total packet length field). The payload field (bytes 9 to 9+N) carries the actual raw binary data or lightweight JSON data.

[0051] Step S105: Send the padded uplink data packet to the IoT platform.

[0052] In step S105, the terminal sends the assembled complete data packet to the satellite link via the Tiantong satellite communication module. The data packet is routed through the satellite, gateway station, and core network to finally reach the IoT platform. After receiving the packet, the IoT platform parses the header fields according to the same protocol structure to extract the device ID, data type, packet number, and payload data, thereby achieving efficient and low-latency data uplink transmission.

[0053] Steps S101 to S106 together constitute a lightweight custom application layer protocol implementation scheme based on a structured data interface. This scheme, through simplified protocol header design and a flexible bit-field mechanism, can significantly optimize data transmission efficiency and system scalability under the Tiantong satellite link. Specific technical effects are as follows:

[0054] 1. Significantly Improved Protocol Header Lightweighting and Transmission Efficiency. This application abandons the lengthy text header (averaging approximately 140 bytes) of the traditional HTTP / 1.1 protocol, adopting a compact binary structured data interface. By compressing the header overhead of uplink and downlink data packets to less than 9 bytes (specifically including 4 bytes for device ID, 1 byte for data type, 2 bytes for packet number, and 2 bytes for total packet length), the protocol header overhead is reduced by 92.86%. This improvement increases the effective payload ratio of the Tiantong satellite narrowband link from approximately 60% to over 90%, and the actual transmission rate increases from 210 bytes / second to 315 bytes / second (theoretical bandwidth is 350 bytes / second). The significantly reduced protocol overhead significantly improves data transmission throughput under limited bandwidth resources, fully meeting the needs of high-frequency, small-data-packet transmission for IoT devices.

[0055] 2. Functional Decoupling and Reduced Terminal Adaptation Costs Based on Bit Field Structure: In the protocol design, both the uplink data type field (ULDataType) and the downlink data type field (DLDataType) are defined using a bit field structure, achieving fine-grained decoupling between data semantics and control logic. Bit 0 is used to distinguish between data sources (terminal built-in or external devices) and command targets (terminal control or device pass-through), enabling rapid identification of data routes. Specific bit segments (such as bits 3-5 of DLDataType) explicitly indicate the command type (such as pass-through, configuration, upgrade), supporting diverse remote control of terminals and external devices by the platform, thus decoupling control logic from data payload. Reserved bits (such as bit 7 of ULDataType) are used to support ACK / NACK feedback mechanisms, enhancing the reliability of the transmission process.

[0056] By eliminating the three-level format conversion loss of "device → terminal → platform," third-party devices only need to output raw data via serial port to connect. This reduces the adaptation cycle from 2 weeks / model in the traditional solution to 1 week / model, lowers cross-vendor integration costs by 70%, and increases the data interaction success rate from 70% to over 95%.

[0057] 3. Large Data Packet Segmentation and Sequence Control Mechanism. The 2-byte packet number field (value range 0~65535) embedded in the uplink interface supports circular counting. Combined with the total packet length field, this enables the terminal to support the segmented transmission and reassembly of large data volumes. The receiving end can determine the integrity and order of data packets based on the packet number sequence, effectively solving the problem of packet loss or out-of-order delivery of long data in satellite links due to single-transmission limitations, and ensuring the orderliness of the data stream.

[0058] 4. High scalability and optimized operation and maintenance efficiency. The ULDataType and DLDataType fields reserve 2-4 unused bits (Reserved / Extension Bits) for future expansion of priority identifiers, encryption flags, or new instruction subtypes. This reserved design provides excellent forward compatibility: when business requirements change and new functions need to be added, only the parsing logic needs to be extended on the platform side, without modifying the underlying protocol structure of the terminal or performing large-scale batch upgrades of terminal firmware. This architecture allows protocol version upgrades to be performed without updating terminal firmware, reducing operation and maintenance costs by more than 90%; at the same time, the bit field reservation design supports the rapid addition of functions (such as priority scheduling and data encryption) when business requirements change, improving response speed by more than 50%.

[0059] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0060] According to some optional embodiments of this application, the device identifier field is 4 bytes, and the device identifier adopts ASCII encoding format or UUID format; the data type field is 1 byte and adopts bit field definition; the source flag bit is the 0th bit of the data type field, the first flag value is 0, and the second flag value is 1.

[0061] In this embodiment, the header fields of the uplink data packets are defined in a refined manner to minimize protocol overhead and improve parsing efficiency:

[0062] Device ID field: This field has a fixed length of 4 bytes. When generating the device ID, the terminal can use either ASCII encoding (e.g., selecting the first 4 characters of the device serial number) or UUID format (e.g., the first 32 bits of the UUID) for padding. This design ensures the uniqueness and readability of the device ID, while the fixed length of 4 bytes facilitates fast reading and processing by the hardware layer.

[0063] Data type field (ULDataType): This field has a fixed length of 1 byte and is defined at the software level using a bit field structure to support the reuse of multiple state flags.

[0064] Source flag (bit0): Located in the least significant bit of this byte. When the uplink data to be transmitted originates from a built-in sensor of the satellite terminal device (such as a temperature or barometric pressure sensor), this bit is set to the first flag value, i.e., binary 0. When the uplink data to be transmitted originates from an external third-party device connected to the terminal's serial port (such as an external smart meter or GPS module), this bit is set to the second flag value, i.e., binary 1.

[0065] Other bits (bit1-bit6): Reserved bits, currently filled with 0, for future protocol expansion (such as defining data priority, encryption flags, etc.). ACK / NACK bit (bit7): Reserved bit, currently filled with 0, for future implementation of uplink data acknowledgment mechanism.

[0066] With the above bit field definition, the terminal only needs to operate on 1 byte of memory space to distinguish the data source. Compared with the complex Content-Type or Header fields in the traditional HTTP protocol, it greatly reduces the computational complexity and memory consumption of protocol parsing, and is particularly suitable for resource-constrained satellite terminals.

[0067] According to some other optional embodiments of this application, after setting the source flag bit of the data type field in the uplink data packet according to the data source, the following steps can also be performed:

[0068] The feedback flag bit of the data type field is set according to the response feedback status of the uplink data packet. The feedback flag bit is the 7th bit of the data type field. The feedback flag bit takes the third flag value when the uplink data packet is used to carry response feedback information. The response feedback information includes acknowledgment response information or negative response information.

[0069] Fill the reserved bits in the data type field, except for the source flag and the feedback flag, with 0. The reserved bits are used to carry priority identifiers or data type classification identifiers.

[0070] In this embodiment, to enhance the reliability of the protocol and reserve expansion space, the data type field (ULDataType, 1 byte) in the uplink data packet is divided into more detailed bit fields:

[0071] Source flag (bit0): As mentioned above, it is used to identify the data source. When the data source is a built-in sensor, the first flag value (0) is used; when the data source is an external device, the second flag value (1) is used.

[0072] Feedback Flag (bit 7): Located in the most significant bit of the data type byte. When the uplink data packet carries the terminal's response feedback information to the platform command, this bit is set to the third flag value (e.g., 1). In this case, the payload field in the data packet will carry specific acknowledgment (ACK) or negative acknowledgment (NACK) information to inform the platform command of the reason for successful or failed reception. When the uplink data packet is ordinary data uplink, this bit is usually kept at 0 or set according to the specific implementation to distinguish it.

[0073] Reserved bits (bits 1-6): These are the 6 bits located between the source flag and the feedback flag. In this embodiment, the reserved bits are uniformly filled with 0. The reserved bits are specifically for future protocol version expansion. For example, bits 1-2 can be used to define data priorities (high / medium / low), and bits 3-6 can be used to define specific data type classification identifiers (such as telemetry data, alarm data, status data, etc.). By filling the reserved bits with 0, the simplicity and parsing efficiency of the current protocol version are ensured, while also providing hardware and software support for adding new service types (such as adding priority scheduling functionality) without modifying the underlying parsing logic.

[0074] In summary, by introducing a feedback flag (bit 7), this embodiment implements a simple acknowledgment mechanism (ACK / NACK) in the uplink, improving transmission reliability in weak network environments of Tiantong satellites and avoiding inconsistent device states due to command loss. Meanwhile, the reserved bit design ensures good backward compatibility and service scalability of the protocol, reducing subsequent maintenance and upgrade costs.

[0075] In some optional embodiments of this application, after sending the padded uplink data packet to the IoT platform, the following steps may also be performed:

[0076] Based on the response feedback information indicated by the feedback flag, determine whether to retransmit the corresponding uplink data packet;

[0077] Before updating the packet sequence number counter, the current count value of the packet sequence number counter is associated with and stored with the uplink data packet, so that if the IoT platform reports a packet loss, the corresponding uplink data packet can be retransmitted based on the associated stored current count value.

[0078] It should be noted that, to overcome potential signal instability or data packet loss issues in the Tiantong satellite communication link, in this embodiment, after the satellite terminal device sends the filled uplink data packet to the IoT platform via the satellite link, the terminal device does not immediately discard the data packet or blindly update the counter, but instead enters a waiting-for-response phase. The terminal device listens for downlink feedback signals from the IoT platform, which carry response feedback information identified by a feedback flag.

[0079] If the received response is an acknowledgment (ACK), it indicates that the target data has been successfully received by the platform and is complete and error-free. The terminal device then executes the normal protocol process, namely updating the packet sequence number counter (e.g., incrementing the count value) and clearing the temporary record related to the data packet in the local cache. Conversely, if the received response is a negative acknowledgment (NACK) or the platform actively provides a packet loss indication, it indicates that the currently sent data packet was lost or had a checksum error during transmission. The terminal device determines that the uplink data packet needs to be retransmitted.

[0080] To achieve efficient and accurate retransmission, this embodiment introduces a data packet association storage step before updating the packet sequence number counter. Specifically, when the satellite terminal device encapsulates the uplink data packet and prepares to send it, it obtains the current packet sequence number counter value (i.e., the unique sequence identifier of the data packet), establishes a mapping relationship between this sequence number and the specific content of the uplink data packet (e.g., the buffer address of the data packet in memory, a data copy, or key feature codes), and stores it in the terminal device's local cache. This ensures that even if a retransmission occurs subsequently, the terminal device can quickly locate the original data packet using the unique sequence number.

[0081] When the IoT platform reports a packet loss indication, the terminal device extracts the packet sequence number corresponding to the packet loss based on the indication and retrieves the associated uplink data packet from its local cache. Once the data packet is found, the terminal device does not need to reread data from the sensor or re-encapsulate complex protocols; it directly calls the original data packet copy in the cache, refills it into the uplink data packet transmission buffer, and retransmits it to the IoT platform via the satellite link.

[0082] The above process not only avoids additional time delays caused by data source reading or format conversion, but also ensures that the retransmitted data packets are completely consistent with the original data packets in terms of content, thereby effectively improving the reliability and real-time performance of data transmission in the Tiantong satellite IoT scenario.

[0083] As some optional embodiments of this application, the packet sequence number field is 2 bytes; the packet sequence number counter has a value range of 0 to 65535, an initial value of 0, a step size of 1, and a preset upper limit value of 65535; the uplink data is data transmitted in packets, and the packet sequence number field is used to perform sequential identification and reassembly control of the data transmitted in packets on the IoT platform.

[0084] In this embodiment, the packet sequence number field of the uplink data packet is designed to be 2 bytes (16 bits) to support larger data volume transmission and a cyclic counting mechanism. Specifically, the value range of the packet sequence number counter is set to 0 to 65535, with an initial value of 0. The counter value increments by 1 (i.e., a step size of 1) for each uplink data packet sent. When the packet sequence number counter reaches the preset upper limit of 65535, the counter automatically resets to zero and starts counting again from 0 when the next data packet is sent, thus implementing the cyclic counting function.

[0085] Furthermore, this embodiment introduces a packet-segmentation transmission mechanism for high-volume uplink transmission scenarios. When the length of the uplink data to be sent exceeds the single-frame data payload limit of the Tiantong satellite (e.g., 1024 bytes), the terminal device divides the original data into multiple smaller data packets for packet transmission. At this time, the packet sequence number field plays a crucial role in the data processing of the IoT platform, acting as a sequence identifier and controlling reassembly. After receiving the packet-segmented uplink data packets, the IoT platform first parses the packet sequence number field in the data packet to obtain the sequence identifier of the segment. The platform uses this sequence number to sort the received multiple data segments, ensuring that the data reassembly order is consistent with the sending end. Simultaneously, the platform combines the total packet length field and packet number information to determine whether all segments have been received. When all segments have been received and the sequence numbers are consecutive and without missing numbers, the platform reassembles the payload field data of each segment according to the packet sequence number order, restoring the complete original uplink data.

[0086] The above methods enable efficient and reliable transmission of large amounts of information over the bandwidth-constrained Tiantong satellite link, while ensuring the accuracy and integrity of data reconstruction.

[0087] In some optional embodiments of this application, the total packet length field is 2 bytes. The total packet length is the number of complete bytes of the uplink data packet, including the device identifier field, data type field, packet sequence number field, and total packet length field. The total packet length is stored in the total packet length field in big-endian byte order.

[0088] In this embodiment, the total packet length field of the uplink data packet is defined as 2 bytes (16 bits) to accurately identify the total number of bytes in the entire data packet. Specifically, the total packet length refers to the total number of bytes of all fields, including the device identifier field (4 bytes), the data type field (1 byte), the packet sequence number field (2 bytes), the total packet length field itself (2 bytes), and the payload field (N bytes). This definition allows the receiving end (i.e., the IoT platform) to quickly determine the actual boundaries of the data packet by parsing the total packet length field in the header, thereby accurately extracting the payload data and avoiding parsing errors caused by data packet merging or splitting.

[0089] To ensure data parsing consistency across platforms and devices, this embodiment specifies that the packet length field is stored in big-endian byte order. Big-endian byte order means that the most significant byte of data is stored at the lowest memory address, and the least significant byte is stored at the highest memory address, which is consistent with the byte order standard commonly used in network transmission. In actual storage, if the packet length is a numerical value L, then its high 8 bits are stored in the first byte of the packet length field, and its low 8 bits are stored in the second byte of the packet length field. For example, if the total length of an uplink data packet is 100 bytes (0x0064 in hexadecimal), then the packet length field is stored as 0x0064, that is, the first byte is 0x00, and the second byte is 0x64. By uniformly adopting big-endian byte order, the byte order differences between different hardware architectures (such as the little-endian architecture of the ARM Cortex-M series and the big-endian architecture of network devices) can be eliminated, reducing the complexity of parsing protocol headers on IoT platforms and improving the efficiency and accuracy of data processing.

[0090] As some alternative embodiments of this application, the uplink data carried by the payload field is encoded in binary or JSON format; the number of bytes in the payload field does not exceed a preset payload threshold, wherein the preset payload threshold is determined based on the satellite single-frame data payload.

[0091] In this embodiment, the payload field of the uplink data packet carries the actual business data, and its encoding format flexibly supports binary encoding or JSON encoding. When binary encoding is used, the data exists in the form of a compact binary stream, which has extremely high transmission efficiency and extremely low protocol overhead, making it suitable for sensor data reporting scenarios that are sensitive to bandwidth and have fixed data structures. When JSON encoding is used, the data is presented in the form of key-value pairs of text, which has the characteristics of strong readability and good cross-platform compatibility, making it easy for IoT platforms to perform dynamic parsing and business logic expansion, and suitable for business scenarios with more complex structures or those that require frequent adjustments to field types. The terminal device can dynamically select the most suitable encoding method to fill the payload field according to specific business needs, data types, and performance requirements.

[0092] Furthermore, to ensure that data packets can adapt to the physical layer limitations of the Tiantong satellite communication link, the number of bytes in the payload field is strictly constrained and must not exceed a preset payload threshold. This preset payload threshold is determined based on the maximum capacity of a single frame data payload of the Tiantong satellite, and typically does not exceed 1024 bytes. In practice, if the length of the uplink raw data to be transmitted exceeds the preset payload threshold, the terminal device needs to trigger a packet splitting mechanism to divide the raw data into multiple sub-data blocks smaller than or equal to the preset payload threshold. Each sub-data block is then encapsulated into an independent uplink data packet for transmission. This constraint mechanism based on the satellite single-frame payload limit can effectively avoid satellite link congestion, packet loss, or transmission timeouts caused by sending excessively large data packets, ensuring stable and efficient data transmission in the Tiantong satellite network.

[0093] Figure 2 This is a flowchart of another data transmission method according to an embodiment of this application, which is applied to an Internet of Things (IoT) platform, such as... Figure 2 As shown, the method includes the following steps:

[0094] Step S201: Generate downlink instructions based on business requirements.

[0095] In step S201, the downlink commands may include control over the satellite terminal itself (such as querying the terminal status or modifying the terminal's operating mode), control over external third-party devices connected to the terminal's serial port (such as resetting the smart meter or adjusting the GPS sampling frequency), or sending firmware upgrade package fragments to the terminal. The platform's internal modules encapsulate the generated commands into standard command objects, which contain the target object identifier, command type, and specific command parameters.

[0096] Step S202: Set the object flag bit of the downlink data type field in the downlink data packet according to the instruction object of the downlink instruction. The object flag bit takes the first object value when the instruction object is a satellite terminal device and the second object value when the instruction object is an external device.

[0097] In step S202, during the encapsulation process, the downlink data type field (DLDataType, 1 byte) is processed. For the object flag bit (bit 0), the platform determines the target object of the instruction: if the instruction directly controls the satellite terminal equipment (e.g., modifying the terminal baud rate), the object flag bit is set to the first object value (e.g., 0); if the instruction indirectly controls an external device through the terminal (e.g., sending instructions to an external sensor via the terminal serial port), the object flag bit is set to the second object value (e.g., 1).

[0098] Step S203: Set the type flag of the downlink data type field according to the instruction type of the downlink instruction. The type flag is used to identify the pass-through type, configuration type or upgrade type.

[0099] In step S203, for the type flag bit, the platform sets the type flag bit according to the specific nature of the instruction: if it is a pass-through instruction (i.e., the terminal only acts as a channel and does not parse the content), it is set to the pass-through type value (e.g., 0); if it is a configuration instruction (such as updating local parameters), it is set to the configuration type value (e.g., 1); if it is an upgrade instruction (such as fragmented firmware distribution), it is set to the upgrade type value (e.g., 2). The remaining reserved bits are filled with 0.

[0100] Step S204: Fill the downlink packet sequence number into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number.

[0101] In step S204, the platform generates a downlink packet sequence number and fills it into the packet sequence number field of the downlink data packet. It should be noted that the downlink packet sequence number is maintained by the platform and has an independent counter and initial value. It does not interfere with the uplink packet sequence number reported by the terminal. This ensures that when the downlink command is received by the terminal in the broadcast channel, it can independently perform sequence control and deduplication processing, avoiding sequence number conflicts with the uplink data stream.

[0102] Step S205: Fill the instruction parameters of the downlink instruction into the payload field of the downlink data packet.

[0103] In step S205, the platform encodes the instruction parameters (e.g., a parameter set in JSON format, such as {"cmd":"set", "params":{"baud_rate":9600}}) and fills them into the payload field of the downlink data packet.

[0104] Step S206: The padded downlink data packet is sent to the satellite so that the satellite can broadcast the downlink data packet to the satellite terminal equipment.

[0105] In step S206, the padded downlink data packet is routed through the core network to the Tiantong satellite gateway station, and then transmitted by the satellite to the satellite terminal equipment in the target area via broadcast or unicast (depending on the specific link configuration). After receiving the data packet, the terminal equipment parses the DLDataType field to identify the command object and command type, and then performs the corresponding pass-through, configuration update, or upgrade operation.

[0106] Steps S201 to S206 above, by constructing an independently counted downlink packet sequence number mechanism and a refined instruction classification based on object and type flags, can achieve orderly distribution and precise routing of downlink control instructions, effectively avoid sequence number conflicts with uplink data, and support efficient decoupling processing of multiple types of instructions such as pass-through, configuration, and upgrade.

[0107] According to some optional embodiments of this application, the downlink data packet includes: a downlink data type field, a packet sequence number field, a downlink data packet length field, and a payload field arranged in sequence; the downlink data type field is 1 byte, the packet sequence number field is 2 bytes, and the packet length field is 2 bytes.

[0108] Furthermore, the instruction parameters carried by the payload field are encoded in binary instruction code or JSON format, where the instruction parameters include device configuration parameters or upgrade firmware fragments; the total packet length field indicates the total packet length as the number of complete bytes of the downlink data packet, including the downlink data type field, packet sequence number field, total packet length field, and payload field.

[0109] Furthermore, the downlink data type field adopts a bit field definition, with the object flag bit being the 0th bit of the downlink data type field, the first object value being 0, and the second object value being 1.

[0110] In this embodiment, the downlink data packet consists of four main parts arranged in sequence: a downlink data type field, a packet sequence number field, a total packet length field, and a payload field. The downlink data type field occupies 1 byte (8 bits) and carries key control information of the instruction; the packet sequence number field occupies 2 bytes (16 bits) and identifies the order of the data packets; the total packet length field occupies 2 bytes (16 bits) and indicates the total number of bytes in the data packet; the payload field occupies the remaining bytes and carries the actual instruction parameter data. This compact structural design eliminates the lengthy header information of the traditional HTTP protocol, making the header overhead of the entire downlink data packet only 5 bytes (1+2+2), significantly reducing transmission latency and bandwidth consumption in the Tiantong satellite narrowband link.

[0111] In the specific implementation process, the arrangement and storage method of each field follow a strict big-endian byte order rule to ensure consistency between the sending end (IoT platform) and the receiving end (satellite terminal equipment). The downlink data type field is located at the very beginning of the data packet. Its 0th bit (bit0) serves as an object flag, used to distinguish the target object of the instruction: when the instruction object is the satellite terminal equipment itself, this bit is set to the first object value (e.g., 0); when the instruction object is an external device connected to the terminal, this bit is set to the second object value (e.g., 1). Its 3rd to 5th bits (bit3-bit5) serve as type flags, corresponding to the three instruction types of transparent transmission, configuration, and upgrade, respectively. Next, the packet sequence number field occupies the next 2 bytes. This sequence number is generated and incremented by a counter maintained by the IoT platform that is completely separate from the uplink packet sequence number, thereby avoiding conflicts between the uplink data flow and the downlink control flow in the sequence number space and ensuring the orderliness of bidirectional communication.

[0112] The packet length field, also occupying 2 bytes, is stored in big-endian byte order. The value of this field equals the sum of the bytes in the downlink data type field (1 byte), the packet sequence number field (2 bytes), the packet length field itself (2 bytes), and the payload field (N bytes). Upon receiving a downlink data packet, the terminal device first reads the packet length field to determine the overall boundary of the data packet, and then accurately extracts the content of the payload field. Finally, the payload field directly carries the specific instruction parameters, which can be encoded in JSON or binary format, such as parameter key-value pairs in configuration instructions or firmware data fragments in upgrade instructions.

[0113] With the aforementioned clearly structured and fixed-length downlink data packet format, terminal devices can quickly identify instruction types and extract payloads without performing complex header parsing or dynamic memory allocation, greatly improving the terminal's processing speed and real-time response capabilities in resource-constrained environments.

[0114] In some optional embodiments of this application, the value range of the packet sequence number field is 0 to 65535. The downlink packet sequence number increments by one step for each downlink data packet sent from the initial value and returns to zero after reaching 65535 for cyclic counting. The downlink packet sequence number is used to instruct the satellite terminal equipment to execute downlink commands in sequence.

[0115] In this embodiment, the IoT platform maintains an independent packet sequence number counter for downlink communication. This counter is independent of the uplink packet sequence number and does not interfere with each other. When the platform needs to issue a downlink command, it first reads the current counter value as the packet sequence number of the current downlink packet and fills it into the packet sequence number field of the downlink packet. Then, the counter increments by a preset step size (e.g., 1). When the packet sequence number reaches the preset upper limit of 65535, the next increment operation will reset the counter to zero and start counting again from 0, thereby realizing a cyclic counting mechanism.

[0116] This circular counting design not only makes full use of the 2-byte field's storage space but also effectively avoids counter overflow issues caused by long-term operation. At the data receiving end, the satellite terminal equipment uses the received downlink packet sequence numbers to manage the order and track the status of downlink commands. Specifically, the terminal equipment compares the currently received downlink packet sequence number with the sequence number of the last successfully executed downlink packet to determine the arrival order and completeness of the commands. If the received sequence numbers conform to the expected increasing pattern, the terminal equipment parses and executes the corresponding downlink commands (such as pass-through, configuration, or upgrade) in sequence. If a sequence number jump or missing information is detected, the terminal equipment can identify packet loss and trigger a retransmission request or ignore out-of-order commands based on specific service requirements. In this way, the orderly execution and status consistency of downlink control commands can be ensured in the high-latency, packet-loss-prone link environment of the Tiantong satellite.

[0117] Figure 3 This is a schematic diagram of a service transmission model according to an embodiment of this application, such as... Figure 3 As shown, in the uplink data flow direction, third-party devices send raw service data to the Tiantong satellite terminal via physical interfaces (such as RS232, RS485, or CAN bus). The terminal's internal software module first preprocesses the received raw data, including format standardization and verification. Then, based on a custom application layer protocol format, the terminal encapsulates the device identifier, data type flag (ULDataType), packet sequence number, total packet length, and raw payload data into an uplink data packet. This data packet is transmitted to the IoT platform via the Tiantong satellite communication module, through the satellite link, gateway station, and core network. Upon receiving the data packet, the IoT platform parses the protocol header to identify the data source and target service module, extracts the payload data, and stores or performs subsequent service processing.

[0118] In the downlink control flow direction, the IoT platform generates control commands (such as device configuration, firmware upgrade, or transparent transmission commands) based on business needs. The platform encapsulates the command target object flag (DLDataType bit0), command type flag (DLDataType bits 3-5), downlink packet sequence number, total packet length, and command parameters into a downlink data packet according to a custom downlink application layer protocol format. This data packet is broadcast to the target satellite terminal via the core network, gateway station, and Tiantong satellite. The terminal receives and parses the downlink data packet, identifying the command type based on the DLDataType field: if it is a transparent transmission command, the terminal directly forwards the command parameters in the payload field to the external third-party device via serial port; if it is a configuration or upgrade command, the terminal performs the corresponding parameter update or firmware upgrade operation locally.

[0119] In some optional embodiments of this application, the data transmission method can also be implemented through the following steps.

[0120] Step 1: Define the uplink application data interface, the specific code is shown below.

[0121] Uplink data interface definition

[0122] typedef struct {

[0123] uint32_t deviceId; / / Device ID (4 bytes)

[0124] uint8_t ulDataType; / / ULDataType (1 byte)

[0125] uint16_t packetNumber; / / Packet number (2 bytes)

[0126] uint16_t totalLength; / / Total packet length (2 bytes)

[0127] uint8_t payload[0];} / / Payload (variable length)

[0128] ULData;

[0129] ULDataType bit field definition

[0130] typedef union {

[0131] uint8_t value;

[0132] struct {

[0133] uint8 t dataSource: 1; / / bite0: data source (0: terminal data; 1: external device data)

[0134] uint8_t prioritybit: 2; / / bite2-1: bit2-1: priority (first filled with 0)

[0135] uint8_t terminalType: 2; / / bite4-3: Terminal data type (filled with 0s initially)

[0136] uint8 t reserved: 2; / / bite6-5: reserved (filled with 0s first)

[0137] uint8_t terminalAck: 1; / / bite7: Terminal ACK (value 1 indicates ACK or NACK, initially padded with 0s)

[0138] bits;

[0139] ULDataType.

[0140] It should be noted that the uplink application data interface adopts a structured data frame format, enabling efficient data interaction between the Tiantong satellite terminal and the IoT platform. The protocol format of this uplink data packet consists of the following fields arranged in order: device identifier field, uplink data type field, packet sequence number field, total packet length field, and payload field. Specific definitions and parameter explanations are as follows:

[0141] 1. Device Identifier Field. This field is 4 bytes long and is used to uniquely identify the third-party device sending the data. The device identifier can be stored as an ASCII encoded string or in UUID (Universally Unique Identifier) ​​format to ensure that in scenarios with multiple devices accessing the network concurrently, the IoT platform can accurately trace the data source and establish a mapping relationship between devices and data.

[0142] 2. Uplink Data Type Field. This field is 1 byte long and uses a bit field design to carry control and status information. The specific bit definitions are as follows: bit0 (Data Source Identifier): Used to distinguish the data source type. When the value is 0, it indicates that the data comes from the terminal's built-in sensor; when the value is 1, it indicates that the data comes from a connected external third-party device. bit7 (Terminal ACK Feedback Identifier): Used to support reliability control of data transmission. When the value is 1, it indicates that the data packet carries ACK (acknowledgment) or NACK (negative acknowledgment) feedback information; when the value is 0, this bit is reserved. The remaining bits (bit1-bit6): As reserved extension bits, currently filled with 0, supporting future expansion of priority identifiers, data type classification, etc., and functional upgrades can be achieved without modifying the underlying protocol structure.

[0143] 3. Packet Sequence Number Field. This field is 2 bytes long and ranges from 0 to 65535. It uses a circular counting mechanism, automatically resetting to zero after the packet number increments to 65535. Its main function is to serve as an identifier for data packets in large data packet transmission scenarios, used by the receiving end for packet order verification, packet loss detection, and data reassembly control.

[0144] 4. Packet Length Field. This 2-byte field identifies the total number of bytes in the current uplink data packet. The total length includes the device identifier field (4 bytes), the uplink data type field (1 byte), the packet sequence number field (2 bytes), the packet length field itself (2 bytes), and the payload field (N bytes). This field is stored in big-endian byte order to ensure consistency in parsing across devices with different architectures.

[0145] 5. Payload Field. This field is N bytes long and carries the actual business data. The payload field supports binary encoding or JSON (JavaScript Object Notation) encoding to balance transmission efficiency and data readability. Considering the physical layer limitations of the Tiantong satellite communication link, the length of the payload bytes is constrained by the single-frame data payload threshold, typically not exceeding 1024 bytes. If the original data exceeds this threshold, the terminal needs to trigger a packet splitting mechanism for transmission.

[0146] The aforementioned uplink data interface is primarily applicable to uplink data transmission scenarios such as sensor data acquisition and device status reporting. Through the lightweight protocol design, the protocol header overhead is compressed to less than 9 bytes, significantly improving the payload transmission efficiency of the Tiantong satellite narrowband link. Simultaneously, the bit-domain-based data type field design enables rapid identification of data sources and flexible control over transmission reliability, meeting the high-frequency, low-latency data interaction needs of IoT devices.

[0147] Step 2: Define the downlink application data interface, the specific code is shown below.

[0148] Downlink data interface definition

[0149] typedef struct {

[0150] uint8_t dlDataType; / / DLDataType (1 byte)

[0151] uint16_t packetNumber; / / Packet number (2 bytes)

[0152] uint16_t totalLength; / / Total packet length (2 bytes)

[0153] uint8_t payload[0]; / / Payload (variable length)

[0154] DLData;

[0155] DLDataType bit field definition

[0156] typedef union {

[0157] uint8_t value;

[0158] struct {

[0159] uint8 t dataDestination: 1; / / bite0: data destination (0: terminal data; 1: external device data)

[0160] uint8_t priority: 2; / / bite2-1: bit2-1: priority (filled with 0 first)

[0161] uint8_t terminalCmdType: 4; / / bite6-3: Terminal data type (filled with 0s initially)

[0162] uint8 t reserved: 1; / / bite7: reserved (filled with 0s first)

[0163] bits;

[0164] DLDataType.

[0165] Understandably, the downlink application data interface also uses a structured data frame format to enable precise remote control of the Tiantong satellite terminal and external devices by the IoT platform. The protocol format of this downlink data packet consists of the following fields arranged in order: downlink data type field, packet sequence number field, total packet length field, and payload field. Specific definitions and parameter explanations are as follows:

[0166] 1. Downlink Data Type Field. This field is 1 byte long and uses a bit-field design to define the target object and execution type of the instruction. The specific bit definitions are as follows: bit0 (Data Target Identifier): Used to distinguish the target object of the instruction. When the value is 0, it indicates that the instruction acts on the satellite terminal device itself (e.g., modifying terminal parameters); when the value is 1, it indicates that the instruction acts on an external third-party device connected to the terminal (e.g., controlling sensors via the terminal serial port). bits3-5 (Instruction Type Identifier): Used to identify the specific type of instruction issued by the platform, supporting the following three modes: 0: Transparent transmission mode, instructing the terminal to forward the content in the payload field to the external device as is without parsing; 1: Configuration mode, instructing the terminal to parse the parameters in the payload field and update the local configuration (e.g., communication baud rate, working mode, etc.); 2: Upgrade mode, instructing the terminal to load the firmware data in the payload field to perform a software or firmware upgrade. The remaining bits (bit1-bit2, bit6-bit7): Reserved extension bits, currently filled with 0, supporting future expansion of priority identifiers, instruction subtypes, etc., ensuring good backward compatibility of the protocol.

[0167] 2. Packet Sequence Number Field. This field is 2 bytes long, and its counting logic is independent of the uplink packet sequence number. This field is maintained and incremented by the IoT platform to identify the order of data packets in the downlink. The receiving end (terminal) verifies this sequence number to ensure that instructions are received and executed in order, preventing out-of-order or duplicate execution problems caused by network fluctuations.

[0168] 3. Packet Length Field. This field is 2 bytes long, and its definition and calculation method are consistent with the uplink interface. This field identifies the total number of bytes in the complete data packet, including the downlink data type field (1 byte), the packet sequence number field (2 bytes), the packet length field itself (2 bytes), and the payload field (N bytes). Big-endian byte order is used for storage, which facilitates the terminal to quickly determine the data packet boundaries.

[0169] 4. Payload Field. This field is N bytes long and is used to carry the specific instruction parameters. The format of the payload field varies depending on the instruction type.

[0170] For pass-through commands, the payload field directly contains the raw data (binary or specific protocol format) to be forwarded to the external device; for configuration commands, the payload field typically contains a set of configuration parameters in JSON format (such as {"baud_rate":9600}) or binary configuration code; for upgrade commands, the payload field contains binary data of firmware fragments. This field supports flexible data encoding methods to adapt to the needs of different business scenarios regarding transmission efficiency and parsing complexity.

[0171] The aforementioned downlink data interface is primarily applicable to downlink control scenarios such as platform command issuance to terminals and external devices, remote configuration updates, and firmware upgrades. By introducing the DL DataType field, control logic decoupling can be achieved: the platform does not need to establish independent channels or protocols for each control type, but instead uses a unified interface structure to dynamically parse the payload content based on the type identifier. This design not only simplifies platform-side development and maintenance costs but also enhances the terminal's adaptability to diverse control commands, improving the flexibility and response speed of the Tiantong satellite IoT system.

[0172] Step 3: Data Uplink Process. The data uplink process mainly includes four key steps: data preprocessing, protocol encapsulation, satellite transmission, and platform parsing. The specific implementation process is as follows.

[0173] 1. Data Preprocessing. External third-party devices send raw service data to the Tiantong satellite terminal via physical serial port interfaces (such as RS232, RS485, or CAN bus). After receiving the raw data, the terminal's built-in software module first performs data verification (such as checking data integrity) and format standardization processing to ensure the legality and consistency of the input data, preparing for subsequent protocol encapsulation.

[0174] 2. Protocol Encapsulation. The terminal software performs structured encapsulation of the preprocessed data according to a custom uplink application layer protocol format. Specific steps include:

[0175] Fill in the device identifier: Read the device registration information stored inside the terminal and fill the unique device ID into the device identifier field (4 bytes) of the uplink data packet to ensure the traceability of the data source.

[0176] Set data type: Based on the actual source of the data, set bit 0 in the Uplink Data Type field (ULDataType). If the data comes from the terminal's built-in sensor, set bit 0 to 0; if the data comes from an external third-party device, set bit 0 to 1.

[0177] Update packet sequence number: Maintain an independent packet sequence number counter, starting from 0. The counter increments by 1 for each data packet encapsulated and sent; when the count reaches 65535, it automatically resets to zero and restarts counting, thus implementing cyclic counting to identify the sending order of data packets.

[0178] Calculate the total packet length: According to the protocol definition, calculate the total number of bytes in the current data packet. The total packet length is equal to the sum of the device identifier field (4 bytes), the uplink data type field (1 byte), the packet sequence number field (2 bytes), the total packet length field itself (2 bytes), and the payload field (N bytes). Fill this value into the total packet length field.

[0179] Generate checksum (optional): To improve transmission reliability, the terminal may optionally use an XOR check algorithm to calculate key fields, generate a checksum field, and append it to the data packet so that the receiving end can perform integrity verification.

[0180] The payload data is preprocessed and formatted raw data and used as the payload content to fill the payload field of the uplink data packet.

[0181] 3. Satellite Transmission. The terminal sends the encapsulated uplink data packets via the Tiantong satellite communication module. The data packets are transmitted to the ground gateway station via the Tiantong satellite link, and then routed to the IoT platform through the core network, completing the uplink data transmission from the terminal to the cloud.

[0182] 4. Platform Parsing. The IoT platform receives uplink data packets from the satellite link and parses them according to the preset uplink application layer protocol format. Specifically, this includes: parsing the device identifier field to obtain the device ID sending the data, and establishing or querying the data mapping relationship for that device in the platform database to ensure correct data attribution; identifying the data source by reading bit 0 of the uplink data type field to determine whether the data source is a built-in sensor in the terminal or an external device, thereby routing the data to the corresponding business processing module (such as a sensor data stream processing module or an external device data stream processing module); and using the packet sequence number field and the total packet length field to determine whether the data packet belongs to a packetized transmission scenario. If reassembly is required, the platform merges the packetized data according to the packet number order; after reassembly, it extracts the valid business data from the payload field and persistently stores it in the database for analysis or use by upper-layer applications.

[0183] Step 4: Data Downlink Process. The data downlink process mainly includes three key steps: command generation, satellite transmission, and terminal parsing and execution. The specific implementation process is as follows.

[0184] 1. Command Generation and Encapsulation. The IoT platform generates control commands based on business needs (such as device configuration adjustments, status queries, firmware upgrades, etc.) and encapsulates them according to a custom downlink application layer protocol format. Specific steps include:

[0185] Set data target identifier: Read bit 0 of the downlink data type field (DLDataType). If the instruction is applied to the satellite terminal device itself, bit 0 is set to 0; if the instruction is intended to control an external third-party device connected to the terminal, bit 0 is set to 1.

[0186] Set command type identifier: Set bits 3-5 in DLDataType according to the specific command type. If it is a pass-through command, this field is set to 0; if it is a configuration command, this field is set to 1; if it is an upgrade command, this field is set to 2.

[0187] Packet sequence number allocation: The platform maintains a packet sequence number counter independent of uplink data packets. Each time a downlink command data packet is sent, the counter increments by 1, and the current value is filled into the packet sequence number field of the downlink data packet. This independent counting mechanism ensures the sequential control capability of downlink commands in unicast or multicast scenarios, avoiding conflicts with uplink data sequence numbers.

[0188] Encode payload parameters: Encode specific command parameters into payload data. For example, for configuration commands, parameters can be serialized into JSON format strings (such as {"cmd":"set","params":{"baud_rate":9600}}) or binary command codes and populated into the payload field.

[0189] Calculate the total packet length: Calculate the total number of bytes including the DLDataType field (1 byte), the packet sequence number field (2 bytes), the total packet length field itself (2 bytes), and the payload field, and fill the total packet length field with the total packet length field.

[0190] 2. Satellite Transmission. The platform sends the encapsulated downlink data packets to the gateway station via the core network. The gateway station modulates the data and uploads it to the Tiantong satellite. After receiving the data, the satellite broadcasts the data packets to target satellite terminals within its coverage area.

[0191] 3. Terminal parsing and execution. After receiving downlink data packets, the satellite terminal performs the following processing steps:

[0192] The terminal reads the total packet length field to verify the packet boundaries. If the checksum mechanism is enabled, the terminal recalculates the checksum of the received data and compares it with the checksum in the packet. If they do not match, the packet is discarded or a retransmission is requested to ensure data integrity.

[0193] Parse the downlink data type field (DLDataType), identify the instruction target based on bit 0, identify the instruction type based on bits 3-5, and perform the corresponding operation:

[0194] If the instruction is identified as a pass-through instruction (bits 3-5 are 0), the terminal directly extracts the data from the payload field and forwards it to the external third-party device as is via a serial port (such as RS485 / CAN) without performing any protocol parsing.

[0195] If the command is identified as a configuration instruction (bits 3-5 are 1), the terminal parses the parameters in the payload field (such as JSON format or binary code), updates the local configuration parameters inside the terminal (such as modifying the communication baud rate, working mode, etc.), and may return a configuration success status.

[0196] If an upgrade command is identified (bits 3-5 are 2), the terminal triggers the firmware upgrade process. The terminal manages the receiving order of firmware segments based on the packet sequence number field, supports segmented reception and breakpoint resume mechanisms, and ensures the integrity and reliability of firmware upgrades in unstable satellite link environments.

[0197] Step 5: To further improve the reliability of data transmission via the Tiantong satellite link, an error detection mechanism based on Cyclic Redundancy Check (CRC-32) is introduced during the data encapsulation stage. The specific implementation process is as follows.

[0198] 1. Checksum Generation. When the terminal encapsulates uplink data or the platform encapsulates downlink commands, in addition to filling in the fields according to the protocol format, a 4-byte checksum field can optionally be generated. This checksum field is calculated using the CRC-32 algorithm. The CRC-32 algorithm applies to key data fields of the data packet, including but not limited to the device identifier field, uplink data type field (ULDataType) or downlink data type field (DLDataType), packet sequence number field, and payload field. The sending end performs a polynomial division operation on the data in the specified fields mentioned above to generate a 32-bit checksum value, and stores this value in the checksum field reserved in the data packet.

[0199] 2. Verification and Retransmission Mechanism. Upon receiving a data packet, the receiving end (an IoT platform for uplink data and a satellite terminal for downlink data) performs the following verification steps:

[0200] The key data fields extracted from the data packet by the receiving end (i.e., those fields used by the sending end for calculation) are recalculated, and the checksum is recalculated using the same CRC-32 algorithm.

[0201] The recalculated checksum is compared with the checksum field carried in the data packet. If they match, it indicates that no bit errors occurred in the data packet during transmission, and the receiving end continues to execute subsequent parsing logic. If they do not match, it indicates that the data packet may have been corrupted or lost during transmission. In this case, the receiving end will discard the erroneous data packet and trigger a retransmission mechanism according to the specific protocol configuration (e.g., the terminal sends a NACK signal to the uplink platform to request retransmission, or the platform requests the terminal to resend the instruction), thereby ensuring the integrity and consistency of the service data.

[0202] By introducing the CRC-32 check mechanism, data transmission errors caused by channel noise can be effectively identified and corrected in the high-latency, interference-prone Tiantong satellite communication environment, significantly reducing the data interaction failure rate and improving the overall stability of the system.

[0203] Figure 4 This is a structural diagram of a data transmission device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0204] The first filling module 41 is used to read the device registration information of the satellite terminal device, generate a device identifier based on the device registration information, and fill the device identifier into the device identifier field of the uplink data packet.

[0205] The first setting module 42 is used to determine the data source of the uplink data to be sent, and to set the source flag bit of the data type field in the uplink data packet according to the data source. The source flag bit takes a first flag value when the data source is the built-in sensor of the satellite terminal equipment, and takes a second flag value when the data source is an external device.

[0206] The update module 43 is used to obtain the current count value of the packet sequence number counter, fill the current count value into the packet sequence number field of the uplink data packet, and update the packet sequence number counter. The packet sequence number counter increments by one step for each uplink data packet sent from the initial value, and returns to zero after reaching the preset upper limit value.

[0207] The calculation module 44 is used to calculate the total length of the uplink data packet based on the sum of the number of bytes in the device identification field, data type field, packet sequence number field, total length field of uplink data packet, and payload field, and fill the total length field with the total length field. The payload field is used to carry uplink data.

[0208] The first sending module 45 is used to send the padded uplink data packet to the Internet of Things platform.

[0209] It should be noted that the above Figure 4The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0210] It should be noted that, Figure 4 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0211] Figure 5 This is a structural diagram of another data transmission device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0212] The generation module 51 is used to generate downlink instructions according to business requirements.

[0213] The second setting module 52 is used to set the object flag bit of the downlink data type field in the downlink data packet according to the instruction object of the downlink instruction. The object flag bit takes the first object value when the instruction object is a satellite terminal device and takes the second object value when the instruction object is an external device.

[0214] The third setting module 53 is used to set the type flag of the downlink data type field according to the instruction type of the downlink instruction. The type flag is used to identify the pass-through type, configuration type or upgrade type.

[0215] The second filling module 54 is used to fill the downlink packet sequence number into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number.

[0216] The third filling module 55 is used to fill the instruction parameters of the downlink instruction into the payload field of the downlink data packet.

[0217] The second transmitting module 56 is used to send the padded downlink data packets to the satellite, so that the satellite can broadcast the downlink data packets to the satellite terminal equipment.

[0218] It should be noted that the above Figure 5 The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0219] It should be noted that, Figure 5 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2The relevant descriptions of the embodiments shown will not be repeated here.

[0220] Figure 6 A hardware block diagram of a computer terminal for implementing a data transmission method is shown. Figure 6 As shown, the computer terminal 60 may include one or more processors 602 (shown as 602a, 602b, ..., 602n in the figure) 602 (processor 602 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 604 for storing data, and a transmission module 606 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 60 may also include... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0221] It should be noted that the aforementioned one or more processors 602 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 60. As described in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0222] The memory 604 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the data transmission method in the embodiments of this application. The processor 602 executes various functional applications and data processing by running the software programs and modules stored in the memory 604, thereby realizing the aforementioned data transmission method. The memory 604 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 604 may further include memory remotely located relative to the processor 602, and these remote memories can be connected to the computer terminal 60 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0223] The transmission module 606 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 60. In one example, the transmission module 606 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 606 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0224] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 60.

[0225] It should be noted here that, in some optional embodiments, the above... Figure 6 The computer terminal shown may include hardware components (including circuitry), software components (including computer code stored on a computer-readable medium), or a combination of both hardware and software components. It should be noted that... Figure 6 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0226] It should be noted that, Figure 6 The computer terminal shown is used to execute Figure 1 The data transmission method shown above is also applicable to this electronic device, and will not be repeated here.

[0227] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program controls the device where the storage medium is located to execute the above data transmission method when it runs.

[0228] The non-volatile storage medium performs the following functions: reads the device registration information of the satellite terminal device, generates a device identifier based on the device registration information, and fills the device identifier into the device identifier field of the uplink data packet; determines the data source of the uplink data to be sent, sets the source flag bit of the data type field in the uplink data packet according to the data source, wherein the source flag bit takes a first flag value when the data source is the built-in sensor of the satellite terminal device, and takes a second flag value when the data source is an external device; obtains the current count value of the packet sequence number counter, fills the current count value into the packet sequence number field of the uplink data packet, and updates the packet sequence number counter, wherein the packet sequence number counter increments by one step for each uplink data packet sent from the initial value, and returns to zero after reaching a preset upper limit value; calculates the total packet length of the uplink data packet based on the sum of the byte counts of the device identifier field, data type field, packet sequence number field, total packet length field of the uplink data packet, and payload field, and fills the total packet length into the total packet length field, wherein the payload field is used to carry the uplink data; and sends the filled uplink data packet to the IoT platform.

[0229] This application also provides an electronic device, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described data transmission method during runtime.

[0230] The processor runs a program that performs the following functions: reads the device registration information of the satellite terminal device, generates a device identifier based on the device registration information, and fills the device identifier into the device identifier field of the uplink data packet; determines the data source of the uplink data to be sent, sets the source flag bit of the data type field in the uplink data packet according to the data source, wherein the source flag bit takes a first flag value when the data source is the built-in sensor of the satellite terminal device, and takes a second flag value when the data source is an external device; obtains the current count value of the packet sequence number counter, fills the current count value into the packet sequence number field of the uplink data packet, and updates the packet sequence number counter, wherein the packet sequence number counter increments by one step for each uplink data packet sent from the initial value, and resets to zero after reaching a preset upper limit value; calculates the total packet length of the uplink data packet based on the sum of the byte counts of the device identifier field, data type field, packet sequence number field, total packet length field of the uplink data packet, and payload field, and fills the total packet length into the total packet length field, wherein the payload field is used to carry the uplink data; and sends the filled uplink data packet to the IoT platform.

[0231] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0232] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0233] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0234] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0235] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0236] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0237] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or 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 this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0238] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data transmission method, characterized in that, Applied to satellite terminal equipment, including: Read the device registration information of the satellite terminal device, generate a device identifier based on the device registration information, and fill the device identifier into the device identifier field of the uplink data packet; Determine the data source of the uplink data to be sent, and set the source flag bit of the data type field in the uplink data packet according to the data source. The source flag bit takes a first flag value when the data source is the built-in sensor of the satellite terminal equipment, and takes a second flag value when the data source is an external device. Obtain the current count value of the packet sequence number counter, fill the current count value into the packet sequence number field of the uplink data packet, and update the packet sequence number counter. The packet sequence number counter increments by one step for each uplink data packet sent from its initial value, and returns to zero after reaching a preset upper limit value. The total length of the uplink data packet is calculated based on the sum of the number of bytes in the device identifier field, the data type field, the packet sequence number field, the total length of the uplink data packet field, and the payload field. The total length of the uplink data packet is then filled into the total length field. The payload field is used to carry the uplink data. The filled uplink data packet is sent to the IoT platform.

2. The method according to claim 1, characterized in that, The device identifier field is 4 bytes, and the device identifier adopts ASCII encoding format or UUID format; The data type field is 1 byte and is defined using a bit field. The source flag is the 0th bit of the data type field, the first flag value is 0, and the second flag value is 1.

3. The method according to claim 1, characterized in that, After setting the source flag of the data type field in the uplink data packet according to the data source, the method further includes: The feedback flag bit of the data type field is set according to the response feedback status of the uplink data packet, wherein the feedback flag bit is the 7th bit of the data type field; the feedback flag bit takes the third flag value when the uplink data packet is used to carry response feedback information; the response feedback information includes acknowledgment response information or negative response information; Fill the reserved bits in the data type field, except for the source flag bit and the feedback flag bit, with 0. The reserved bits are used to carry priority identifiers or data type classification identifiers.

4. The method according to claim 3, characterized in that, After sending the padded uplink data packet to the IoT platform, the method further includes: Based on the response feedback information identified by the feedback flag, determine whether to retransmit the corresponding uplink data packet; Before updating the packet sequence number counter, the current count value of the packet sequence number counter is associated with and stored with the uplink data packet, so that if the IoT platform provides a packet loss indication, the corresponding uplink data packet can be retransmitted according to the associated and stored current count value.

5. The method according to claim 1, characterized in that, The packet sequence number field is 2 bytes; the packet sequence number counter has a value range of 0 to 65535, the initial value is 0, the step size is 1, and the preset upper limit value is 65535; the uplink data is data transmitted in packets, and the packet sequence number field is used to perform sequential identification and reassembly control of the data transmitted in packets on the IoT platform.

6. The method according to claim 1, characterized in that, The total packet length field is 2 bytes. The total packet length is the number of complete bytes of the uplink data packet, including the device identifier field, the data type field, the packet sequence number field, and the total packet length field. The total packet length is stored in the total packet length field in big-endian byte order.

7. The method according to claim 1, characterized in that, The uplink data carried by the payload field is encoded in binary or JSON format; the number of bytes in the payload field does not exceed a preset payload threshold, wherein the preset payload threshold is determined based on the payload of a single satellite frame.

8. A data transmission method, characterized in that, Applications in IoT platforms, including: Generate downlink instructions based on business needs; The object flag bit of the downlink data type field in the downlink data packet is set according to the instruction object of the downlink instruction, wherein the object flag bit takes a first object value when the instruction object is a satellite terminal device and a second object value when the instruction object is an external device; The type flag of the downlink data type field is set according to the instruction type of the downlink instruction, wherein the type flag is used to identify the pass-through type, configuration type or upgrade type; The downlink packet sequence number is filled into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number; Fill the instruction parameters of the downlink instruction into the payload field of the downlink data packet; The padded downlink data packet is sent to the satellite, which then broadcasts the downlink data packet to the satellite terminal equipment.

9. The method according to claim 8, characterized in that, The downlink data packet includes: the downlink data type field, the packet sequence number field, the total packet length field, and the payload field arranged in sequence; the downlink data type field is 1 byte, the packet sequence number field is 2 bytes, and the total packet length field is 2 bytes.

10. The method according to claim 9, characterized in that, The instruction parameters carried by the payload field are encoded in binary instruction code or JSON format, wherein the instruction parameters include device configuration parameters or upgrade firmware fragments; the total packet length field indicates the total packet length, which is the number of complete bytes of the downlink data packet including the downlink data type field, the packet sequence number field, the total packet length field, and the payload field.

11. The method according to claim 8, characterized in that, The downlink data type field is defined using a bit field, the object flag bit is the 0th bit of the downlink data type field, the first object value is 0, and the second object value is 1.

12. The method according to claim 8, characterized in that, The type flag is the 3rd to 5th bit of the downlink data type field. The type flag is 0 when identifying the pass-through type, 1 when identifying the configuration type, and 2 when identifying the upgrade type. The reserved bits in the downlink data type field other than the object flag and the type flag are 0. The reserved bits are used to carry priority identifiers or instruction subtype identifiers.

13. The method according to claim 8, characterized in that, The value range of the packet sequence number field is 0 to 65535. The downlink packet sequence number increments by one step for each downlink data packet sent from the initial value and returns to zero after reaching 65535 for cyclic counting. The downlink packet sequence number is used to instruct the satellite terminal equipment to execute the downlink instructions in sequence.

14. A data transmission device, characterized in that, include: The first filling module is used to read the device registration information of the satellite terminal device, generate a device identifier based on the device registration information, and fill the device identifier into the device identifier field of the uplink data packet; The first setting module is used to determine the data source of the uplink data to be sent, and set the source flag bit of the data type field in the uplink data packet according to the data source. The source flag bit takes a first flag value when the data source is the built-in sensor of the satellite terminal equipment, and takes a second flag value when the data source is an external device. The update module is used to obtain the current count value of the packet sequence number counter, fill the current count value into the packet sequence number field of the uplink data packet, and update the packet sequence number counter. The packet sequence number counter increments by one step for each uplink data packet sent from the initial value, and returns to zero after reaching a preset upper limit value. The calculation module is used to calculate the total length of the uplink data packet based on the sum of the number of bytes of the device identifier field, the data type field, the packet sequence number field, the total length field of the uplink data packet, and the payload field, and to fill the total length field with the total length field, wherein the payload field is used to carry the uplink data; The first sending module is used to send the padded uplink data packet to the Internet of Things platform.

15. A data transmission device, characterized in that, include: The generation module is used to generate downlink instructions based on business requirements. The second setting module is used to set the object flag bit of the downlink data type field in the downlink data packet according to the instruction object of the downlink instruction, wherein the object flag bit takes a first object value when the instruction object is a satellite terminal device and takes a second object value when the instruction object is an external device; The third setting module is used to set the type flag bit of the downlink data type field according to the instruction type of the downlink instruction, wherein the type flag bit is used to identify the pass-through type, configuration type or upgrade type; The second filling module is used to fill the downlink packet sequence number into the packet sequence number field of the downlink data packet, wherein the downlink packet sequence number is counted independently of the uplink packet sequence number; The third filling module is used to fill the instruction parameters of the downlink instruction into the payload field of the downlink data packet; The second transmission module is used to send the padded downlink data packet to the satellite, so that the satellite can broadcast the downlink data packet to the satellite terminal equipment.

16. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to perform the data transmission method according to any one of claims 1 to 13.

17. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, performs the data transfer method according to any one of claims 1 to 13.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the data transmission method according to any one of claims 1 to 13.

Images