Multi-link collaborative real-time data transmission method based on ad hoc network

Abstract

The invention relates to a multilink collaborative real-time data transmission method based on an ad hoc network. The method comprises the following steps: constructing multiple links, carrying out preprocessing and custom protocol packaging on to-be-transmitted data, processing data conflicts through an escape mechanism, realizing priority scheduling based on data types, dynamically adjusting a transmission rate in combination with link states, and ensuring data integrity through buffer area caching and CRC (Cyclic Redundancy Check) verification. The method is adaptive to a scene without network infrastructure, solves the problems of packet loss and unstable rate of multi-link transmission, realizes real-time transmission of high-priority instructions, is suitable for multi-person voice communication and equipment interaction scenes such as emergency rescue and field operation, and has the advantages of high stability, wide compatibility and efficient scheduling.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a method for multi-link cooperative real-time data transmission based on ad hoc networks. Background Technology

[0002] With the development of mobile terminals and IoT technologies, the demand for real-time data transmission between multiple devices is increasing. However, in scenarios without public network coverage or with damaged network infrastructure, traditional transmission solutions relying on wired networks and WiFi are unsuitable. While existing technologies include RTP-based self-organizing network voice transmission and Bluetooth-plus-self-organizing network multi-terminal voice call solutions, these technologies require terminals to connect to the self-organizing network via wired or WiFi connections. This fails to cover scenarios where terminals only support wireless connections and lack wired / WiFi interfaces, and also cannot meet the needs of terminals requiring transmission via wired interfaces such as serial ports when there is no network infrastructure. Single-link or simple combination-link transmission via Bluetooth, serial ports, etc., is prone to data packet loss, transmission order disorder, and rate fluctuations, especially in weak signal environments where data transmission reliability drops significantly. Existing solutions lack differentiated processing mechanisms for various data types, cannot prioritize the transmission of high-priority commands, and have insufficient robustness in data protocol design, making them susceptible to command parsing errors. Summary of the Invention

[0003] Therefore, it is necessary to provide a multi-link collaborative real-time data transmission method based on ad hoc networks that can achieve stable and efficient data transmission in scenarios without network infrastructure, addressing the aforementioned technical problems.

[0004] A method for multi-link cooperative real-time data transmission based on ad hoc networks, the method comprising: The terminal device is connected to the corresponding wireless module of the relay device via a short-range wireless link, and the conversion module of the short-range wireless link is connected to the wired data interface of the relay device to form a multi-link transmission path. The multi-link transmission path enables the self-organizing network relay node to transmit the data received by the wired data interface to the corresponding self-organizing network relay node of other terminals in the network through the self-organizing network. The business data to be transmitted is collected and preprocessed. According to the custom transmission protocol, the preprocessed data is added with frame start marker, length field, data type identifier, packet sequence number, valid data segment, check field and frame end marker to form a complete data packet. The system checks whether there is a byte sequence in the valid data segment of the complete data packet that is the same as the start-of-frame marker or end-of-frame marker. If so, it processes the data through an escaping mechanism. At the same time, it parses the data type identifier of the data packet, allocates the data packet to the corresponding transmission queue according to the priority corresponding to the identifier, and configures different link transmission channels and preemption rules for data with different priorities. During data packet transmission, the transmission status parameters of each link in the multi-link are monitored in real time. Based on the status parameters, the transmission rate of the short-range wireless link, the transmission rate of the wired data interface, and the transmission speed of the self-organizing network relay node are adjusted respectively. If the short-range wireless link signal is detected to meet the weak signal condition, further rate degradation and data aggregation processing are performed. The scheduled data packets are sent to the ad hoc network using multiple links. The ad hoc network relay nodes forward the data packets according to their priority. After receiving the data packets, the ad hoc network relay node corresponding to the target terminal stores them in a preset buffer and parses them according to a custom transmission protocol. It verifies the data integrity through the verification field, submits the data packets that pass the verification to the upper layer application for processing, and discards the data packets that fail the verification or are incomplete.

[0005] The aforementioned multi-link collaborative real-time data transmission method based on ad hoc networks, as described in this application, constructs a multi-link architecture including short-range wireless links, conversion modules, wired data interfaces, and ad hoc networks. It employs Bluetooth-to-serial conversion and ad hoc network radios for multi-link collaborative transmission, utilizing various rate modulation techniques to achieve timely and stable data transmission, flexibly covering various complex application scenarios. Whether it's a terminal supporting only wireless connections without wired / WiFi interfaces, or a device requiring data transmission via dedicated wired interfaces such as serial ports, all can smoothly access the ad hoc network, perfectly adapting to network-free environments such as field operations and emergency rescue, significantly expanding the application boundaries of real-time data transmission technology. Furthermore, a custom high-robustness transmission protocol, coupled with frame boundary markers, CRC checks, and packet sequence number management, effectively reduces the data parsing error rate. A real-time dynamic rate adjustment mechanism precisely adapts the transmission rate based on link status parameters, and packet aggregation processing in weak signal environments reduces frame header overhead and retransmission counts, lowering the bit error rate in weak signal scenarios. This completely solves the common problems of packet loss, disordered sorting, and rate fluctuations in traditional multi-link transmission. Based on data type identifier priority division, combined with Bluetooth L2CAP layer differentiated channel configuration and self-organizing network IP_TOS priority forwarding mechanism, this application achieves instruction priority scheduling and forwarding on multiple transmission links, avoiding the blocking of critical instructions by low-priority data and meeting the core requirements of real-time interaction scenarios. Furthermore, this application possesses strong compatibility and flexibility; short-range wireless links, conversion modules, and wired data interfaces can be flexibly replaced according to actual needs, allowing for access without large-scale modifications to terminal equipment. This significantly lowers the technical application threshold and provides an efficient and feasible solution for real-time data transmission needs across different industries and device types. Attached Figure Description

[0006] Figure 1 This is a flowchart illustrating a multi-link collaborative real-time data transmission method based on an ad hoc network in one embodiment. Figure 2This is a schematic diagram of the framework of a multi-link collaborative real-time data transmission method based on an ad hoc network in one embodiment; Figure 3 This is a data transmission link diagram in one embodiment; Figure 4 This is a diagram of the sending end steps in another embodiment; Figure 5 This is a flowchart of the receiving end steps in one embodiment. Detailed Implementation

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

[0008] In one embodiment, such as Figure 1 As shown, a multi-link cooperative real-time data transmission method based on ad hoc networks is provided, including the following steps: Step 102: Connect the terminal device to the corresponding wireless module of the relay device via a short-range wireless link, and at the same time connect the conversion module of the short-range wireless link to the wired data interface of the relay device to form a multi-link transmission path. The multi-link transmission path enables the self-organizing network relay node to transmit the data received by the wired data interface to the corresponding self-organizing network relay node of other terminals in the network through the self-organizing network.

[0009] The terminal device connects to the corresponding wireless module of the relay device via a short-range wireless link, and simultaneously connects the conversion module of the short-range wireless link to the wired data interface of the relay device, forming a multi-link transmission path corresponding to the terminal device, the short-range wireless link, the conversion module, the wired data interface, and the self-organizing network relay node. The self-organizing network relay node can transmit the data received by the wired data interface to the corresponding self-organizing network relay node of other terminals within the network, realizing link interoperability between multiple terminals.

[0010] like Figure 2 As shown, in a specific implementation scenario, the preferred short-range wireless link is a Bluetooth link. The conversion module is a Bluetooth-to-serial module, the wired data interface is a serial port, the relay device is a radio, and the self-organizing network relay node is a radio node. Terminal devices connect to the radio's Bluetooth module via Bluetooth, and the Bluetooth-to-serial module physically connects to the radio's serial port. The radio, as a self-organizing network node, forwards serial data to other radio nodes via the self-organizing network protocol, ultimately achieving multi-link data transmission between terminal devices. The data transmission link is as follows: Figure 3 As shown.

[0011] The multi-link transmission path construction technology, through a combined architecture of short-range wireless links, conversion modules, wired data interfaces, and self-organizing networks, completely breaks away from the dependence of traditional transmission solutions on public infrastructure such as wired networks and WiFi, while also solving the problem of terminal interface adaptation limitations. Whether it's a terminal that only supports wireless connections and lacks wired / WiFi interfaces, or a device that needs to transmit data through dedicated wired interfaces such as serial ports, it can smoothly access the self-organizing network, enabling multi-terminal interoperability in network-free scenarios. This significantly expands the application boundaries of real-time data transmission technology, making device interconnection possible in complex environments such as field operations and emergency rescue.

[0012] Step 104: Collect and preprocess the business data to be transmitted. Add frame start marker, length field, data type identifier, packet sequence number, valid data segment, check field and frame end marker to the preprocessed data according to the custom transmission protocol to form a complete data packet.

[0013] The system collects and preprocesses the service data to be transmitted. If it is voice data, the terminal device collects analog voice signals through a microphone, converts them into digital audio data streams through an audio codec, and compresses them using OPUS or LC3 low bit rate encoding algorithms to reduce the amount of data to adapt to multi-link transmission. If it is a service command or device configuration command, the corresponding digital command data is directly generated.

[0014] The preprocessed data is grouped according to a custom transmission protocol. For each group, a frame start marker, length field, data type identifier, packet sequence number, valid data segment, checksum field, and frame end marker are added sequentially to form a complete data packet. Among these: Start of frame marker: Use 0x7E 0x81 (choose a combination with low probability of occurrence), which can greatly reduce the probability of conflict with speech coding data.

[0015] Data length field: The 2 bytes of the data length field are used to indicate the actual number of bytes in the subsequent data segment (excluding the frame header, frame tail data length fields, and checksum field). By specifying the data length, the receiving end can accurately know how much data needs to be received to form a complete data packet.

[0016] Data type identifier: 1 byte is used to identify the data type, such as 0x01 for voice encoding data, 0x02 for control command data, etc., so that the receiving end can process the data according to different types. 0x03 identifies the configuration parameters and commands of radio, serial port, Bluetooth, etc.

[0017] Data segment: Used to store the actual encoded speech data; its length is determined by the data length field.

[0018] Check field: A 2-byte check code is generated using the CRC check algorithm to check all data from the frame header to the data segment in order to detect whether errors occur during data transmission.

[0019] End-of-frame identifier: Set a fixed 2-byte sequence as the frame tail, such as 0x81 0x7E, to indicate the end of the data packet.

[0020] The start and end markers of the frame clearly define the data boundaries, the length field ensures that the receiver accurately reads valid data, the packet sequence number enables the reordering of out-of-order data, and the check field can accurately identify data corruption during transmission. This raises the error recognition rate of data transmission to an extremely high level, effectively avoiding the parsing ambiguity and errors caused by the imperfect structure of traditional protocols, and significantly enhancing the accuracy and reliability of data transmission.

[0021] The transmission protocol design is shown in Table 1.

[0022] Table 1

[0023] Step 106: Detect whether there is a byte sequence in the valid data segment of the complete data packet that is the same as the start-of-frame marker or end-of-frame marker. If so, process it through the escaping mechanism. At the same time, parse the data type identifier of the data packet, allocate the data packet to the corresponding sending queue according to the priority corresponding to the identifier, and configure differentiated link transmission channels and preemption rules for data with different priorities.

[0024] For voice-coded data that may conflict with the frame header identifier, at the transmitting end, when the same byte sequence as the frame header and frame tail appears in the data segment, an escaping mechanism is used. That is, a specific escape byte, such as 0xCC, is inserted before the sequence. When the receiving end receives the data and detects the escape byte 0xCC, it restores the following 2-byte sequence to the original data, avoiding misinterpretation as a frame header.

[0025] The data packet data type identifier is parsed, classifying the data packets into three types: 0x01 represents voice commands, 0x02 represents service commands, and 0x03 represents radio configuration commands. The larger the value, the higher the priority. This application implements command priority scheduling through a multi-level system.

[0026] When the Bluetooth transmitter receives data from the upper layer, it first parses the priority bits and places the data packets into the corresponding priority transmission queue. The transmission thread prioritizes processing high-priority queues, while radio configuration and service commands are prioritized for transmission at the head of the queue. The Bluetooth L2CAP layer can create multiple logical channels, assigning different priorities to different types of data: a low-priority L2CAP channel is created for voice data (configured with QoS parameters: latency ≤ 100ms, jitter ≤ 20ms, reliability = high) to ensure controllable voice packet transmission latency; a high-priority L2CAP channel is created for control and configuration commands to avoid preempting voice data transmission resources; and a channel preemption function is enabled in the Bluetooth module—when there is data on the high-priority channel, the transmission of the low-priority channel can be interrupted, and high-priority commands can be sent first.

[0027] When data is read from the serial port and sent to various nodes in the multi-autonomous network through the network layer, IP_TOS is configured as a high priority, and other nodes will prioritize forwarding based on the value of IP_TOS.

[0028] By implementing a collaborative technology that combines data conflict escaping and priority scheduling, the system not only resolves potential data transmission conflicts but also enables differentiated and efficient transmission of various data types. The escaping mechanism inserts specific escape bytes before conflicting byte sequences to prevent the receiver from misjudging frame boundaries, minimizing the parsing error rate caused by data conflicts. Furthermore, priority allocation based on data type identifiers, differentiated channel configuration, and preemption rules ensure that high-priority instructions (such as device configuration and urgent business instructions) receive dedicated transmission resources, significantly improving transmission response speed and effectively preventing low-priority data from blocking critical instructions, thus meeting the core requirements of real-time interactive scenarios.

[0029] Step 108: During the data packet transmission process, the transmission status parameters of each link in the multi-link are detected in real time. Based on the status parameters, the transmission rate of the short-range wireless link, the transmission rate of the wired data interface, and the transmission speed of the self-organizing network relay node are adjusted respectively. If the short-range wireless link signal is detected to meet the weak signal condition, rate degradation and data aggregation processing are further performed.

[0030] This application employs a Bluetooth-to-serial converter and a self-organizing network radio for multi-link collaborative transmission. Since the data transmission rate is affected by various states and environmental factors, this application uses the following adaptive algorithm for transmission rate adjustment: Real-time detection of Bluetooth link error rate and Bluetooth signal strength, dynamically adjusting the Bluetooth transmission rate based on the data, with multiple transmission rate levels (2Mbps, 1Mbps, 128Kbps); Real-time detection of serial port buffer data, dynamically adjusting the serial port baud rate based on the buffer size to increase data transmission rate and stability, while also adjusting the terminal device's transmission speed; Real-time detection of parameters such as signal-to-noise ratio, distance, bandwidth, and latency between self-organizing network communication nodes, adjusting the terminal device's transmission speed accordingly.

[0031] When the Bluetooth signal is weak (RSSI < -70dBm), in order to reduce the bit error rate and improve the stability of data transmission, the Bluetooth rate is reduced to 128kbps to reduce bit errors. Multiple small voice packets (50 bytes) are aggregated into one large data packet (200 bytes) to reduce frame header overhead and retransmission times.

[0032] The design incorporates multi-link rate dynamic adjustment and weak signal optimization technologies to accurately match link status with transmission requirements, significantly improving transmission stability and efficiency. Short-range wireless links switch rate levels based on bit error rate and signal strength, while wired data interfaces adjust the baud rate according to buffer data volume. Self-organizing network nodes adjust transmission speed based on inter-node distance and bandwidth, achieving dynamic adaptation between rate and link status. Rate degradation and data aggregation in weak signal environments not only reduce frame header overhead but also decrease the number of packet retransmissions, significantly improving transmission quality in weak signal scenarios and effectively solving the packet loss and rate fluctuation problems caused by fixed rates in traditional solutions.

[0033] Step 110: Use multiple links to send the scheduled data packets to the ad hoc network. The ad hoc network relay nodes forward the data packets according to their priority. After receiving the data packets, the ad hoc network relay node corresponding to the target terminal stores them in a preset buffer and parses them according to a custom transmission protocol. It verifies the data integrity through the verification field, submits the data packets that pass the verification to the upper layer application for processing, and discards the data packets that fail the verification or are incomplete.

[0034] The receiving end sets up a large buffer (e.g., 1024 bytes) to temporarily store all received data. This prevents data loss due to delayed data processing and handles out-of-order data arrival. Data is read sequentially from the buffer, starting with the frame header. Upon detecting a valid frame header, the corresponding length of data is read into the temporary storage area based on the data length field. Next, the checksum field and frame trailer are read. A CRC checksum is performed on the data in the temporary storage area (from the frame header to the data segment), and the result is compared with the received checksum field. If the checksum passes and the frame trailer is correct, the data packet is considered complete and correct, and is submitted to the upper-layer application for processing. If the checksum fails or the frame trailer is incorrect, the data packet is considered incomplete or incorrect, and the data in the temporary storage area is discarded. The next possible data packet is then read from the buffer. During processing, if the length of the read data is insufficient to form a complete data packet (such as reading only part of the frame header, incomplete data length field, etc.), then wait for new data to enter the buffer until a complete data packet can be formed or after a certain waiting time (such as 500 milliseconds). If it is still incomplete, then discard the read data and start detecting new data packets again.

[0035] Self-organizing network nodes prioritize forwarding high-priority data packets based on the IP_TOS value, shortening the end-to-end latency of critical instructions in multi-hop networks; the preset buffer at the receiving end can avoid missed or lost packets due to untimely data processing, and the timeout discard mechanism can promptly clean up invalid data. Combined with a custom protocol parsing and verification process, the integrity and validity of received data are ensured, forming a closed-loop guarantee for the entire data transmission link.

[0036] The aforementioned multi-link collaborative real-time data transmission method based on ad hoc networks, as described in this invention, constructs a multi-link architecture comprising short-range wireless links, conversion modules, wired data interfaces, and ad hoc networks. It employs Bluetooth-to-serial conversion and ad hoc network radios for multi-link collaborative transmission, utilizing various rate modulation techniques to achieve timely and stable data transmission, flexibly covering various complex application scenarios. Whether it's a terminal supporting only wireless connectivity without wired / WiFi interfaces, or a device requiring data transmission via dedicated wired interfaces such as serial ports, all can smoothly access the ad hoc network, perfectly adapting to network-free environments such as field operations and emergency rescue, significantly expanding the application boundaries of real-time data transmission technology. Furthermore, by setting a custom high-robustness transmission protocol combined with frame boundary markers, CRC checks, and packet sequence number management, the data parsing error rate is effectively reduced. A real-time dynamic rate adjustment mechanism precisely adapts the transmission rate based on link status parameters, and packet aggregation processing in weak signal environments reduces frame header overhead and retransmission counts, lowering the bit error rate in weak signal scenarios. This completely solves the common problems of packet loss, disordered sorting, and rate fluctuations in traditional multi-link transmission. Based on data type identifier priority division, combined with Bluetooth L2CAP layer differentiated channel configuration and self-organizing network IP_TOS priority forwarding mechanism, this application achieves instruction priority scheduling and forwarding on multiple transmission links, avoiding the blocking of critical instructions by low-priority data and meeting the core requirements of real-time interaction scenarios. Furthermore, this application possesses strong compatibility and flexibility; short-range wireless links, conversion modules, and wired data interfaces can be flexibly replaced according to actual needs, allowing for access without large-scale modifications to terminal equipment. This significantly lowers the technical application threshold and provides an efficient and feasible solution for real-time data transmission needs across different industries and device types.

[0037] In one embodiment, the frame start marker uses a fixed byte combination with low collision probability, the data type identifier distinguishes different service type data through preset bytes, and the length field identifies the actual number of bytes in the valid data segment.

[0038] In one embodiment, the short-range wireless link is a Bluetooth link, the conversion module is a Bluetooth to serial port module, the wired data interface is a serial port, the relay device is a radio, and the self-organizing network relay node is a radio node.

[0039] In one embodiment, the frame start marker of the custom transmission protocol is 0x7E 0x81, the frame end marker is 0x81 0x7E, the data type identifier is 1 byte, where 0x01 represents voice encoded data, 0x02 represents service instruction data, 0x03 represents configuration instruction data of multi-link related devices, the packet sequence number is 1 byte, the check field is a 2-byte CRC checksum, and the length field is 2 bytes.

[0040] In one embodiment, data preprocessing includes the terminal device acquiring analog voice signals through a microphone, converting them into digital audio data streams via an audio codec, and compressing the digital audio data streams using OPUS or LC3 low bit rate coding algorithms.

[0041] In one embodiment, the escaping mechanism involves inserting an escape byte 0xCC before the same byte sequence as the start-of-frame marker or end-of-frame marker; the differentiated link transmission channels are Bluetooth L2CAP layer logical channels, creating a low-priority L2CAP channel for voice data and a high-priority L2CAP channel for control and configuration commands; wherein, the low-priority L2CAP channel is configured with QoS parameters of latency≤100ms, jitter≤20ms, and reliability=high, and the preemption rule is that high-priority channel data can interrupt low-priority channel data transmission.

[0042] In one embodiment, the transmission status parameters include the bit error rate and signal strength of the short-range wireless link, the buffer data volume of the wired data interface, the signal-to-noise ratio, distance, bandwidth, and delay between relay nodes in the ad hoc network; the adjustment levels of the short-range wireless link transmission rate include 2Mbps, 1Mbps, and 128Kbps; the weak signal condition is that the RSSI of the short-range wireless link is <-70dBm; and the data aggregation processing is to aggregate multiple 50-byte small data packets into a 200-byte large data packet.

[0043] In one embodiment, the forwarding rule of the ad hoc network relay node is as follows: a high IP_TOS value is configured for high-priority data packets. After receiving a data packet, the relay node prioritizes forwarding data packets with high IP_TOS values. The preset buffer size is 1024 bytes. Data integrity verification includes CRC check and frame end mark verification. CRC check is performed on the data in the temporary storage area. The calculation result is compared with the received check field. If the check passes and the frame tail is correct, it is determined to be a complete and correct data packet and is submitted to the upper layer application for processing. If the check fails or the frame tail is incorrect, the data packet is determined to be incomplete or incorrect. The data of the data packet in the temporary storage area is directly discarded, and the next possible data packet is read from the buffer. If the length of the read data is insufficient to constitute a complete data packet, and it is still incomplete after waiting for a certain period of time, the read data is discarded, and the detection of new data packets is restarted.

[0044] In one embodiment, the packet sequence number is managed as follows: the packet sequence number starts from 0 and increments. When the packet sequence number reaches 255, the packet sequence number of the next data packet is reset to 0, thus achieving periodic looping. This makes it easier for the receiving end to determine the continuity of data transmission through the packet sequence number.

[0045] In one embodiment, the check field is generated by using a CRC check algorithm to calculate all data from the start of frame marker to the valid data segment, generating a 2-byte check code to detect errors in the data during transmission.

[0046] In a specific embodiment, the sending end steps during the sending and receiving process are as follows: Figure 4 As shown, the data preparation involves grouping the voice-encoded data to be sent according to certain rules. Each group of data is prepared with a protocol header, data length field, data type identifier, checksum field, and frame trailer added to form a complete data packet. Frame header generation: A fixed-format 2-byte frame header is generated. Data length calculation and padding: The number of bytes in the grouped voice-encoded data (data segment) is calculated, and this value is converted to 2 bytes of binary form and padded to the data length field. Data type identifier setting: A 1-byte data type identifier is set according to the actual data type. If it is voice-encoded data, it is set to 0x01. Checksum field calculation: A CRC check is performed on all data from the frame header to the data segment, and the generated 2-byte checksum is padded to the checksum field. Frame trailer addition: A fixed 2-byte frame trailer sequence is added to the end of the data packet. Data transmission: The constructed complete data packet is transmitted via Bluetooth or serial port. If a 4-byte sequence identical to the frame header is detected in the data segment, an escape byte 0xCC is inserted before it before transmission.

[0047] The receiving end steps are as follows Figure 5 As shown, (1) Initialization: Initialize the buffer and set the buffer size to 1024 bytes. Initialize the data processing state and prepare to start receiving data.

[0048] (2) Data reception: Data is received via Bluetooth or serial port, and each received byte is stored sequentially in the buffer. (3) Data packet parsing: Data is read sequentially from the buffer, and frame header detection begins. During the reading process, if two consecutive bytes match a possible frame header sequence generated by the preset frame header generation algorithm, the next two bytes of the data length field are read. Based on the value of the data length field, data of the corresponding length is read from the buffer into a temporary storage area, followed by reading a two-byte checksum field and a two-byte frame trailer. (4) Verification and processing: Perform CRC check calculation on the data from the frame header to the data segment in the temporary storage area, and compare the calculation result with the received check field. If the two are consistent and the frame tail is correct, the data packet is determined to be complete and correct, and the voice encoded data in the data segment is submitted to the upper layer application for processing; if the check fails or the frame tail is incorrect, the data packet in the temporary storage area is directly discarded.

[0049] (5) Continuous processing: If, during the reading process, it is found that the data length is insufficient to form a complete data packet (e.g., only part of the frame header is read, or the data length field is incomplete), then continue to wait for new data to enter the buffer. If a complete data packet cannot be formed within 500 milliseconds, then discard the part of the data already read into the temporary storage area and start detecting new data packets again from the buffer.

[0050] (6) Loop processing: Repeat steps 2-5 continuously to receive and process data, ensuring stable and accurate transmission and parsing of data.

[0051] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

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

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

Claims

1. A method for multi-link collaborative real-time data transmission based on ad hoc networks, characterized in that, The method includes: The terminal device is connected to the corresponding wireless module of the relay device via a short-range wireless link, and the conversion module of the short-range wireless link is connected to the wired data interface of the relay device to form a multi-link transmission path. The multi-link transmission path enables the self-organizing network relay node to transmit the data received by the wired data interface to the corresponding self-organizing network relay node of other terminals in the network through the self-organizing network. The business data to be transmitted is collected and preprocessed. According to the custom transmission protocol, the preprocessed data is added with frame start marker, length field, data type identifier, packet sequence number, valid data segment, check field and frame end marker to form a complete data packet. The system checks whether the valid data segment of the complete data packet has the same byte sequence as the start-of-frame marker or end-of-frame marker. If it does, it processes the data packet through an escaping mechanism. At the same time, it parses the data type identifier of the data packet, allocates the data packet to the corresponding transmission queue according to the priority corresponding to the identifier, and configures different link transmission channels and preemption rules for data with different priorities. During data packet transmission, the transmission status parameters of each link in the multi-link are monitored in real time. Based on the status parameters, the transmission rate of the short-range wireless link, the transmission rate of the wired data interface, and the transmission speed of the self-organizing network relay node are adjusted respectively. If the short-range wireless link signal is detected to meet the weak signal condition, further rate degradation and data aggregation processing are performed. The scheduled data packets are sent to the ad hoc network using multiple links. The ad hoc network relay nodes forward the data packets according to their priority. After receiving the data packets, the ad hoc network relay node corresponding to the target terminal stores them in a preset buffer and parses them according to a custom transmission protocol. It verifies the data integrity through the verification field, submits the data packets that pass the verification to the upper layer application for processing, and discards the data packets that fail the verification or are incomplete.

2. The method according to claim 1, characterized in that, The frame start marker uses a fixed byte combination with low collision probability, the data type identifier distinguishes different service type data through preset bytes, and the length field indicates the actual number of bytes in the valid data segment.

3. The method according to claim 1, characterized in that, The short-range wireless link is a Bluetooth link, the conversion module is a Bluetooth to serial port module, the wired data interface is a serial port, the relay device is a radio, and the self-organizing network relay node is a radio node.

4. The method according to claim 1, characterized in that, The custom transmission protocol has a frame start marker of 0x7E0x81 and a frame end marker of 0x810x7E. The data type identifier is 1 byte, where 0x01 represents voice encoded data, 0x02 represents service instruction data, 0x03 represents configuration instruction data for multi-link related devices, the packet sequence number is 1 byte, the check field is a 2-byte CRC checksum, and the length field is 2 bytes.

5. The method according to claim 1, characterized in that, The data preprocessing includes the terminal device acquiring analog voice signals through a microphone, converting them into digital audio data streams via an audio codec, and compressing the digital audio data streams using OPUS or LC3 low bit rate encoding algorithms.

6. The method according to claim 1, characterized in that, The escaping mechanism involves inserting an escape byte 0xCC before the same byte sequence as the start-of-frame marker or end-of-frame marker; the differentiated link transmission channel is a Bluetooth L2CAP layer logical channel, creating a low-priority L2CAP channel for voice data and a high-priority L2CAP channel for control and configuration commands; wherein, the low-priority L2CAP channel is configured with QoS parameters of latency≤100ms, jitter≤20ms, and reliability=high, and the preemption rule is that high-priority channel data can interrupt low-priority channel data transmission.

7. The method according to claim 1, characterized in that, The transmission status parameters include the bit error rate and signal strength of the short-range wireless link, the buffer data volume of the wired data interface, the signal-to-noise ratio, distance, bandwidth, and delay between relay nodes in the ad hoc network; the adjustment levels of the short-range wireless link transmission rate include 2Mbps, 1Mbps, and 128Kbps; the weak signal condition is that the RSSI of the short-range wireless link is <-70dBm; and the data aggregation processing is to aggregate multiple 50-byte small data packets into a 200-byte large data packet.

8. The method according to claim 1, characterized in that, The forwarding rules of the self-organizing network relay node are as follows: high IP_TOS values ​​are configured for high-priority data packets. After receiving a data packet, the relay node prioritizes forwarding data packets with high IP_TOS values. The size of the preset buffer is 1024 bytes. The data integrity verification includes CRC check and frame end mark verification. CRC check is performed on the data in the temporary storage area, and the calculation result is compared with the received check field. If the check passes and the frame tail is correct, it is determined to be a complete and correct data packet, which is then submitted to the upper-layer application for processing. If the check fails or the frame tail is incorrect, the data packet is determined to be incomplete or incorrect. The data in the temporary storage area of ​​the data packet is directly discarded, and the next possible data packet is read from the buffer. If the length of the read data is insufficient to constitute a complete data packet, and it is still incomplete after a certain period of time, the read data is discarded, and the detection of new data packets begins again.

9. The method according to claim 1, characterized in that, The packet sequence number is managed as follows: the packet sequence number starts from 0 and increments. When the packet sequence number reaches 255, the packet sequence number of the next data packet is reset to 0, realizing periodic looping, which makes it easier for the receiving end to judge the continuity of data transmission by the packet sequence number.

10. The method according to claim 1, characterized in that, The verification field is generated by using the CRC check algorithm to calculate all data from the start of frame marker to the valid data segment, generating a 2-byte check code to detect errors in the data during transmission.

Images