A GNSS network reference station system data scheduling method based on an MPTCP protocol

Abstract

The application discloses a GNSS network reference station system data scheduling method based on an MPTCP protocol, belongs to the technical field of data scheduling, and can make multiple same data packets be simultaneously transmitted on multiple paths by modifying a data transmission process of the MPTCP protocol, thereby solving the unstable connection problem caused by the single path transmission limitation of the Ntrip protocol; and a client buffer pool is designed to store different types of data, so that even if data packet loss occurs on one path, the client can still quickly select the data packet from the remaining paths, thereby reducing the risk of data packet loss; in addition, the method for dividing the buffer pool to store data also solves the buffer pool overflow problem of the MPTCP protocol multi-path data transmission, simultaneously divides the transmission data into two categories according to importance, and stores the data in different buffer pools, so as to reduce the data out-of-order phenomenon and improve the real-time performance of differential data transmission.

Description

Technical Field

[0001] This invention discloses a data scheduling method for a GNSS network reference station system based on the MPTCP protocol, belonging to the technical field of data scheduling. Background Technology

[0002] Global Navigation Satellite System (GNSS) technology is a technique for determining location on Earth using both ground-based and satellite equipment. GNSS technology is widely used in transportation, agriculture, construction, aerospace, and defense. However, GNSS positioning accuracy is affected by various factors, including weather, terrain changes, terrain obstruction, and errors in signal transmission. These factors increase positioning errors, failing to meet the accuracy requirements of some applications. To improve GNSS positioning accuracy, differential positioning technology has been introduced. Differential positioning technology calculates accurate location by comparing the location information of a reference station with the location information of a mobile device. Through differential positioning technology, the precise location information of the reference station can be transmitted to the mobile device, allowing the mobile device to calculate its location more accurately.

[0003] Networked Transport of RTCM via Internet Protocol (NTRIP) is a dedicated application-layer protocol used in high-precision GNSS systems to transmit differential information. (See attached image.) Figure 1 As shown, the Ntrip protocol involves three roles in communication: Ntrip Server, Ntrip Caster, and Ntrip Client. Its basic working principle is that the Ntrip Source generates an RTCM data stream and sends it to the Ntrip Server, which then sends it to the Ntrip Caster. The Ntrip Client uploads its own location's GGA and retrieves the RTCM data stream from the Caster to perform differential computation. However, the traditional Ntrip protocol is based on the TCP protocol (Transmission Control Protocol) for data transmission. The TCP protocol is designed based on a single network interface. When the underlying network environment is unstable or a network interface switch occurs, connection continuity cannot be guaranteed, which is particularly serious in mobile network environments.

[0004] The MPTCP protocol can transmit data simultaneously across multiple network paths, thereby improving the real-time performance and reliability of data transmission. (See attached image) Figure 2As shown, in the MPTCP implementation, a session can be transmitted through multiple TCP connections, and these connections can transmit simultaneously on different network paths. When one of the network paths fails, data transmission can automatically switch to another available path, thus ensuring the continuity and reliability of the connection, and consequently guaranteeing the accuracy and reliability of GNSS positioning.

[0005] Furthermore, due to the instability of the network environment, the MPTCP protocol still suffers from a certain packet loss rate. Packet loss rate refers to the percentage of data packets lost during data transmission. Losing too many data packets will significantly impact data accuracy, thus affecting the accuracy and reliability of data transmission.

[0006] Chinese patent document CN104994036A discloses a dynamic data scheduling method in a multi-path parallel transmission protocol (MPTCP), including: measuring the round-trip time (RTT) and the change in RTT (RTTVAR) of each path; determining the availability of a path based on the RTT and RTTVAR, discarding congested paths, and retaining available paths; estimating the data transmission capacity of each path; allocating data transmission quotas to each path based on the estimated data transmission capacity and the current sending window; and the scheduler distributing transmitted data according to the transmission quotas. This invention also provides a multi-transmit, selective-receive data transmission scheme, which uses multiple paths to transmit data simultaneously for data with relatively high real-time requirements during data transmission, thereby reducing the risk of data packet loss and having profound significance for improving the overall transmission capacity of the paths.

[0007] Chinese patent document CN101656653A relates to the field of mobile communications, and particularly to configuration technology for receive buffers used in multipath transmission. A method for configuring receive buffers for multipath transmission includes: measuring and obtaining the round-trip time (RTT) parameter of each individual path; determining the receive buffer requirement (abuf_size) of each individual path in the multipath; determining the receive buffer requirement (bufs_size) of the multipath based on the RTT and abuf_size of each individual path; and configuring the receive buffer used in multipath transmission according to the determined bufs_size. This invention also provides a method for configuring receive buffers in a multipath transmission protocol and a method for selecting transmission paths. This method stores different types of data in different read buffer pools on the client side. The client can quickly read important data from the corresponding read buffer pool in a timely manner. MPTCP can simultaneously receive data from different paths. This allows for concurrent data reception on multiple paths, improving data reception throughput and efficiency.

[0008] The existing technology approaches the issue by changing protocols. However, other multipath protocols such as Multipath QUIC and CMT-SCTP cannot be used because these protocols have compatibility issues with existing network infrastructure and protocols.

[0009] To address this issue, existing technologies have proposed increasing the data buffer pool. However, increasing the size of the MPTCP buffer pool requires consideration of system resource constraints and performance requirements. Increasing the buffer pool size may consume more memory and could impact system latency and throughput. Summary of the Invention

[0010] To address the problems of existing technologies, this invention discloses a data scheduling method for a GNSS network reference station system based on the MPTCP protocol. Invention Overview:

[0012] This invention modifies the data transmission process of the MPTCP protocol, enabling multiple identical data packets to be transmitted simultaneously on multiple paths, thus solving the connection instability problem caused by the single-path transmission limitation of the Ntrip protocol. Furthermore, a client-side buffer pool is designed to store different types of data. This approach ensures that even if a data packet is lost on one path, the client can still quickly select the packet from the remaining paths, reducing the risk of data packet loss. Additionally, the method of dividing the data into buffer pools addresses the buffer pool overflow problem in the MPTCP protocol's multi-path data transmission. Transmitted data is divided into two categories based on importance and stored in different buffer pools to reduce data out-of-order issues and improve the real-time performance of differential data transmission. This strategy enhances the reliability and real-time performance of data transmission, thereby ensuring the accuracy and reliability of GNSS positioning.

[0013] The detailed technical solution of this invention is as follows:

[0014] A data scheduling method for a GNSS network reference station system based on the MPTCP protocol, characterized by including: designing a data transmission layer, data classification, and designing a client buffer pool;

[0015] The data transmission layer design replaces the underlying TCP protocol of Ntrip with the MPTCP protocol in the GNSS network reference station system.

[0016] The MPTCP protocol utilizes multiple network interfaces to transmit data and divides the data stream into multiple sub-streams to transmit data on different network paths, thereby improving the reliability and efficiency of the Ntrip protocol and reducing the possibility of data transmission interruption.

[0017] The MPTCP protocol is used to achieve bandwidth aggregation and seamless switching between multiple paths: when packet loss occurs, it promptly feeds back to the sender through multiple paths, thereby reducing transmission latency and improving network performance;

[0018] The Ntrip protocol is an internet-based RTCM network transmission protocol, typically using TCP as its underlying protocol. While TCP is a reliable, connection-oriented protocol that guarantees the reliability and stability of differential data transmission, GNSS base stations require real-time transmission of differential data streams to users, placing high demands on the real-time performance and stability of network transmission. However, TCP's data transmission rate is susceptible to network interface switching and packet loss, which can lead to data transmission failures or delays, thus reducing the accuracy and reliability of GNSS positioning. Furthermore, the widespread use of mobile devices with various interfaces, such as 3GPP, 4G, 5G, LTE, and Wi-Fi, means that users in GNSS network base station systems often have access to multiple network interfaces, including 4G and Wi-Fi ports. Since TCP relies on a single network interface and cannot utilize multiple network paths simultaneously, network interface switching can cause data transmission failures or delays, further reducing the accuracy and reliability of GNSS positioning.

[0019] In contrast, the TCP protocol may encounter bandwidth limitations when transmitting data over the Internet. When a large amount of real-time RTCM data with high real-time requirements is transmitted in Ntrip, the transmission speed of a single TCP network interface may decrease, thus affecting real-time performance; see attached. Figure 4 As shown, compared with the TCP protocol, the MPTCP protocol can promptly provide feedback to the sender through multiple paths when packets are lost, reducing transmission latency and improving network performance. At the same time, it also achieves multi-path bandwidth aggregation and seamless switching, improving the reliability and efficiency of the Ntrip protocol.

[0020] The data classification is as follows: GNSS reference station data transmitted via the MPTCP protocol is classified into primary data and secondary data; the primary data includes high real-time RTCM data and NMEA data; the secondary data includes control commands, status information, and RTCM data and NMEA data without high real-time performance.

[0021] The data classification includes the following steps:

[0022] S11: Determine the data type based on the differences in format and content of the message headers and message payloads of the RTCM data and NMEA data, and then classify them into primary data and secondary data according to the real-time requirements of the data:

[0023] In the input buffer of the MPTCP protocol sender, the data exists in the form of a structure sk_buff, which contains various information about the data packet;

[0024] Since the RTCM data and NMEA data have a fixed data format, the RTCM data contains a specific binary message header, as shown in Table 3 below. The RTCM data first has a 3-byte message header to identify the RTCM version and message type, then a 2-byte message length, followed by the message payload, the format of which varies depending on the message type, and finally a 3-byte CRC checksum. In addition, as shown in Table 1, the RTCM message is divided into Level 1 data and Level 2 data according to the message type.

[0025] The NMEA data is transmitted using an ASCII message header, as shown in Table 4 below. The format of the NMEA data message begins with the $ symbol and is followed by a series of fields used to identify the message type. In addition, as shown in Table 2 above, the NMEA can be divided into first-level data and second-level data according to the message type of the NMEA message.

[0026] Table 3: Message Headers of RTCM Data

[0027] Preface Reserved words Number of bytes occupied by information information CRC check 8 bits 6 bits 10 bits indefinite 24 bits

[0028] Table 4 NMEA Data Headers

[0029]

[0030] S12: Perform a copy operation on the first-level data. Since the first-level data requires high real-time performance, a copy operation is necessary to ensure that the first-level data is transmitted through all sub-streams, thereby improving the reliability of data transmission and ensuring that each sub-stream receives data in a timely manner. Assuming there are n sub-streams, the number of copied first-level data packets is n-1, resulting in n identical first-level data packets in the buffer pool after copying.

[0031] S13: Data allocation, as follows Figure 6 As shown, a multi-transmission and selective reception strategy is adopted for the primary data. After the primary data is copied in the data buffer pool, both the primary and secondary data enter the MPTCP protocol scheduler. The MPTCP protocol scheduler distributes all data and substreams: the primary data is evenly distributed among each substream for data transmission; the secondary data is allocated to available substreams through the MPTCP scheduler to ensure data transmission efficiency and reliability. When data is transmitted to the client via a substream, upon receiving the primary data, all copied data packets of that primary data can be discarded; upon receiving the secondary data, the secondary data is directly read into the corresponding buffer pool.

[0032] The client-side buffer pool design is as follows:

[0033] When GNSS network base station data is transmitted from the Ntrip broadcast server via the MPTCP multipath transmission protocol, the client does not immediately receive the data from the network. The data is first written into a read buffer, and then sent from the buffer to the client by the MPTCP protocol. The GNSS network base station transmits data to the client buffer pool simultaneously through multiple paths. A large amount of data accumulating in the buffer pool may cause the buffer pool to overflow. In order to solve this problem...

[0034] According to a preferred embodiment of the present invention, the specific method for designing the client buffer pool includes:

[0035] S21: Data processing: According to S11, determine whether the data is primary data or secondary data based on the data type in the data extension header; since the same number of primary data packets in the MPTCP protocol scheduler at the sending end are copied in the same substream, delete the redundant identical primary data packets.

[0036] S22: This is a check on the client's buffer pool.

[0037] Determine if there is remaining space in the corresponding read client buffer pool in the MPTCP multipath transport protocol:

[0038] When there is no remaining space in the client buffer pool, the corresponding data entering the client buffer pool will enter the waiting phase, that is, wait for the server to read the client buffer pool and there is free space before the data will enter the client buffer pool.

[0039] When there is remaining free space in the client buffer pool, the corresponding data is put into the read client buffer pool according to the remaining size of the read client buffer pool. The size of the data must not exceed the remaining size of the read buffer pool.

[0040] S23: Adjustment of the client buffer pool after receiving data:

[0041] The client buffer pool is equally divided into buffer pool A and buffer pool B;

[0042] After the data enters the corresponding read client buffer pool, the sizes of buffer pool A and buffer pool B are adjusted. After the adjustment, the remaining spaces of buffer pool A and buffer pool B are compared, and the value of the Ntrip read client buffer pool with the larger remaining space length is transmitted to the Ntrip broadcast server; the Ntrip broadcast server adjusts the size of the sending window in the sliding window according to the size of the received Ntrip client buffer, and then the Ntrip broadcast server continues to transmit data to the Ntrip client through the sub-flow of the MPTCP protocol.

[0043] Preferably according to the present invention, a dynamic adjustment method is added in step S23, including:

[0044] In the process of adjusting the buffer pool size, a dynamic adjustment mechanism can be considered. For example, in actual operation, the sizes of buffer pool A and buffer pool B can be dynamically adjusted according to the current network environment and load conditions to maximize the utilization of the buffer pool space and improve data transmission efficiency. This adjustment mechanism can be implemented based on some metrics, such as the current network bandwidth utilization rate, the full load degree of the buffer pool, etc. Through this dynamic adjustment mechanism, the utilization rate of the buffer pool can be higher and the data transmission efficiency can be improved;

[0045] After the corresponding data enters the corresponding read buffer pool, the size of the read buffer pool is adjusted. It is assumed that the total size of the client read buffer pool in the MPTCP protocol is M, and M is the capacity size of the client buffer pool. The buffer pool is divided into two buffer pools A and B with different sizes, and the sizes of buffer pool A and buffer pool B can be changed, but the sizes of buffer pool A and buffer pool B are both within the range [min, max] (min + max = M, 0 <= min < max <= M);

[0046] After read buffer pool A reads the corresponding data, the remaining space length of read buffer pool A is lena. At this time, the length of read buffer pool A is increased by 1 / (1 - lena), and the space length of read buffer pool B is decreased by 1 / (1 - lena);

[0047] After read buffer pool B reads the corresponding data, the remaining space length of read buffer pool B is lenb. At this time, the length of read buffer pool B is increased by 1 / (1 - lenb), and the space length of read buffer pool A is decreased by 1 / (1 - lenb).

[0048] Preferably according to the present invention, the specific communication process of the MPTCP protocol is as follows:

[0049] S31: The Ntrip broadcast server and Ntrip client establish an MPTCP connection: The Ntrip client initiates a TCP connection request to the Ntrip broadcast server, and the Ntrip broadcast server returns a TCP SYN / ACK handshake signal to establish a TCP connection; after the TCP connection is established, the Ntrip broadcast server and Ntrip client transmit data through the TCP connection;

[0050] S32: MPTCP Substream Creation: After establishing a TCP connection between the Ntrip client and the Ntrip broadcast server, the Ntrip client sends MPTCP protocol option information to the Ntrip broadcast server. Upon receiving the option information, the Ntrip broadcast server creates an MPTCP protocol substream for each network path. Each substream has independent TCP parameters, including sequence number, acknowledgment number, and window size. These substreams can transmit data simultaneously, thereby improving transmission efficiency and reliability.

[0051] S33: Data transmission: The Ntrip client divides the data stream into multiple sub-streams and sends them to different network paths respectively; after receiving the sub-streams, the Ntrip broadcast server merges them into a complete data stream and sends the data stream back to the Ntrip client;

[0052] S34: Data Flow Control: The MPTCP protocol controls data flow according to different network conditions. For example, when network congestion occurs on a certain network path, MPTCP can switch the traffic to other network paths to avoid data transmission interruption.

[0053] S35: Connection Close: After the Ntrip client and Ntrip broadcast server complete data transmission, the Ntrip client sends a TCP FIN signal to the Ntrip broadcast server to close the TCP connection; upon receiving the TCP FIN signal, the Ntrip broadcast server returns a TCP ACK signal and closes the TCP connection.

[0054] Technical advantages of the present invention

[0055] 1. The data scheduling method for a GNSS network reference station system based on the MPTCP protocol described in this invention utilizes the multi-port nature of the GNSS network reference station system to replace the underlying TCP protocol of Ntrip with the MPTCP protocol, thereby solving the data congestion problem caused by the single-path transmission limitation of the Ntrip protocol and improving the efficiency and reliability of data transmission.

[0056] 2. This invention proposes a multi-path data caching strategy for GNSS reference station systems, which classifies data transmitted via MPTCP substreams into primary and secondary data. Simultaneously copying the primary data allows multiple identical data packets to be transmitted on multiple paths, reducing the risk of data packet loss. Even if a data packet is lost on one path, the client can still immediately select the packet from the remaining paths, improving data transmission reliability.

[0057] 3. This invention also optimizes the design of the receiver's buffer pool in the MPTCP layer, proposing a method for dividing the buffer pool to store data. This method stores different types of data in different read buffer pools on the client side. The client can quickly read important data information from the corresponding read buffer pool in a timely manner, thereby solving the problem of out-of-order data packets caused by the limitation of the shared receive buffer size in MPTCP, ensuring that data arrives in order as much as possible, and improving the reliability of data transmission. Attached Figure Description

[0058] Figure 1 This is a schematic diagram of the Ntrip protocol components in this invention;

[0059] exist Figure 1 In this context, NtripClient is the Ntrip client; NtripServer is the Ntrip server; NtripCaster is the Ntrip broadcast server; NtripSource is the Ntrip data source; HTTP Streams are HTTP data streams; administration is used to manage and monitor the activities of NTRIP servers, broadcasters, and clients; and http / telnet is used for communication via HTTP or Telnet protocols.

[0060] Figure 2 This is a schematic diagram of MPTCP multipath transmission according to the present invention;

[0061] Figure 3 This is a schematic diagram of Ntrip protocol data transmission in the GNSS network reference station of this invention.

[0062] exist Figure 3 In Chinese, GNSS Receiver means GNSS receiver; NtripClient means Ntrip client.

[0063] NtripServer: Ntrip server; NtripCaster: Ntrip broadcast server;

[0064] Figure 4 This is a diagram illustrating packet loss;

[0065] Figure 5 This is a flowchart of the MPTCP protocol data packet processing of the present invention;

[0066] Figure 6 This is a schematic diagram of the multi-transmission selective reception strategy of the present invention;

[0067] Figure 7 This is a schematic diagram of the design process for reading the client buffer pool in this invention. Detailed Implementation

[0068] The present invention will now be described in detail with reference to the embodiments and accompanying drawings, but is not limited thereto.

[0069] Example 1

[0070] A data scheduling method for a GNSS network reference station system based on the MPTCP protocol includes: designing a data transmission layer, data classification, and designing a client buffer pool;

[0071] The data transmission layer design replaces the underlying TCP protocol of Ntrip with the MPTCP protocol in the GNSS network reference station system.

[0072] like Figure 5 As shown, the MPTCP protocol utilizes multiple network interfaces to transmit data and divides the data stream into multiple sub-streams to transmit data on different network paths, thereby improving the reliability and efficiency of the Ntrip protocol and reducing the possibility of data transmission interruption.

[0073] like Figure 4 As shown, the MPTCP protocol is used to achieve bandwidth aggregation and seamless switching between multiple paths: when packet loss occurs, it promptly feeds back to the sender through multiple paths, thereby reducing transmission latency and improving network performance;

[0074] The Ntrip protocol is an internet-based RTCM network transmission protocol, typically using TCP as its underlying protocol. While TCP is a reliable, connection-oriented protocol that guarantees the reliability and stability of differential data transmission, GNSS base stations require real-time transmission of differential data streams to users, placing high demands on the real-time performance and stability of network transmission. However, TCP's data transmission rate is susceptible to network interface switching and packet loss, which can lead to data transmission failures or delays, thus reducing the accuracy and reliability of GNSS positioning. Furthermore, the widespread use of mobile devices with various interfaces, such as 3GPP, 4G, 5G, LTE, and Wi-Fi, means that users in GNSS network base station systems often have access to multiple network interfaces, including 4G and Wi-Fi ports. Since TCP relies on a single network interface and cannot utilize multiple network paths simultaneously, network interface switching can cause data transmission failures or delays, further reducing the accuracy and reliability of GNSS positioning.

[0075] In contrast, the TCP protocol may encounter bandwidth limitations when transmitting data over the Internet. When a large amount of real-time RTCM data with high real-time requirements is transmitted in Ntrip, the transmission speed of a single TCP network interface may decrease, thus affecting real-time performance; see attached. Figure 4 As shown, compared with the TCP protocol, the MPTCP protocol can promptly provide feedback to the sender through multiple paths when packets are lost, reducing transmission latency and improving network performance. At the same time, it also achieves multi-path bandwidth aggregation and seamless switching, improving the reliability and efficiency of the Ntrip protocol.

[0076] The data classification is as follows: GNSS reference station data transmitted via the MPTCP protocol is classified into primary data and secondary data; the primary data includes high real-time RTCM data and NMEA data; the secondary data includes control commands, status information, and RTCM data and NMEA data without high real-time performance.

[0077] The data classification includes the following steps:

[0078] S11: Determine the data type based on the differences in format and content of the message headers and message payloads of the RTCM data and NMEA data, and then classify them into primary data and secondary data according to the real-time requirements of the data:

[0079] In the input buffer of the MPTCP protocol sender, the data exists in the form of a structure sk_buff, which contains various information about the data packet;

[0080] Since the RTCM data and NMEA data have a fixed data format, the RTCM data contains a specific binary message header, as shown in Table 3 below. The RTCM data first has a 3-byte message header to identify the RTCM version and message type, then a 2-byte message length, followed by the message payload, the format of which varies depending on the message type, and finally a 3-byte CRC checksum. In addition, as shown in Table 1 above, the RTCM message is divided into Level 1 data and Level 2 data according to the message type.

[0081] The NMEA data is transmitted using an ASCII message header, as shown in Table 4 below. The format of the NMEA data message begins with the $ symbol and is followed by a series of fields used to identify the message type. In addition, as shown in Table 2 above, the NMEA can be divided into first-level data and second-level data according to the message type of the NMEA message.

[0082] Table 3: Message Headers of RTCM Data

[0083] Preface Reserved words Number of bytes occupied by information information CRC check 8 bits 6 bits 10 bits indefinite 24 bits

[0084] Table 4 NMEA Data Headers

[0085]

[0086] S12: Perform a copy operation on the first-level data. Since the first-level data requires high real-time performance, a copy operation is necessary to ensure that the first-level data is transmitted through all sub-streams, thereby improving the reliability of data transmission and ensuring that each sub-stream receives data in a timely manner. Assuming there are n sub-streams, the number of copied first-level data packets is n-1, resulting in n identical first-level data packets in the buffer pool after copying.

[0087] S13: Data allocation, as follows Figure 6 As shown, a multi-transmission and selective reception strategy is adopted for the primary data. After the primary data is copied in the data buffer pool, both the primary and secondary data enter the MPTCP protocol scheduler. The MPTCP protocol scheduler distributes all data and substreams: the primary data is evenly distributed among each substream for data transmission; the secondary data is allocated to available substreams through the MPTCP scheduler to ensure data transmission efficiency and reliability. When data is transmitted to the client via a substream, upon receiving the primary data, all copied data packets of that primary data can be discarded; upon receiving the secondary data, the secondary data is directly read into the corresponding buffer pool.

[0088] The client-side buffer pool design is as follows:

[0089] like Figure 2As shown, when GNSS network base station data is transmitted from the Ntrip broadcast server via the MPTCP multipath transmission protocol, the client does not immediately receive the data from the network. The data is first written into a read buffer, and then sent from the buffer to the client by the MPTCP protocol. The GNSS network base station transmits data to the client buffer pool simultaneously through multiple paths. A large amount of data accumulating in the buffer pool may cause the buffer pool to overflow. To solve this problem...

[0090] Example 2

[0091] like Figure 7 As shown in Example 1, a data scheduling method for a GNSS network reference station system based on the MPTCP protocol includes the following specific method for designing the client buffer pool:

[0092] S21: Data processing: According to S11, determine whether the data is primary data or secondary data based on the data type in the data extension header; since the same number of primary data packets in the MPTCP protocol scheduler at the sending end are copied in the same substream, delete the redundant identical primary data packets.

[0093] S22: This is a check on the client's buffer pool.

[0094] Determine if there is remaining space in the corresponding read client buffer pool in the MPTCP multipath transport protocol:

[0095] When there is no remaining space in the client buffer pool, the corresponding data entering the client buffer pool will enter the waiting phase, that is, wait for the server to read the client buffer pool and there is free space before the data will enter the client buffer pool.

[0096] When there is remaining free space in the client buffer pool, the corresponding data is put into the read client buffer pool according to the remaining size of the read client buffer pool. The size of the data must not exceed the remaining size of the read buffer pool.

[0097] S23: Adjustment of the client buffer pool after receiving data:

[0098] The client buffer pool is equally divided into buffer pool A and buffer pool B;

[0099] After the data enters the corresponding read client buffer pool, the sizes of buffer pool A and buffer pool B are adjusted. After the adjustment, the remaining spaces of buffer pool A and buffer pool B are compared, and the value of the read client buffer pool with the larger remaining space length is transmitted to the Ntrip broadcast server; the Ntrip broadcast server adjusts the size of the sending window in the sliding window according to the size of the received client buffer, and then the Ntrip broadcast server continues to transmit data to the Ntrip client through the sub - streams of the MPTCP protocol.

[0100] In step S23, a dynamic adjustment method is added, including:

[0101] During the adjustment process of the buffer pool size, a dynamic adjustment mechanism can be considered. For example, in actual operation, the sizes of buffer pool A and buffer pool B can be dynamically adjusted according to the current network environment and load conditions to maximize the utilization of the buffer pool space and improve data transmission efficiency. This adjustment mechanism can be implemented based on some metrics, such as the current network bandwidth utilization rate, the full - load degree of the buffer pool, etc. Through this dynamic adjustment mechanism, the utilization rate of the buffer pool can be higher and the data transmission efficiency can be improved;

[0102] After the corresponding data enters the corresponding read buffer pool, the size of the read buffer pool is adjusted. Suppose the total size of the client read buffer pool in the MPTCP protocol is M, where M is the capacity size of the client buffer pool. The buffer pool is divided into two buffer pools A and B with different sizes, and the sizes of buffer pool A and buffer pool B can be changed, but the sizes of both buffer pool A and buffer pool B are within the range [min, max] (min + max = M, 0 <= min < max <= M);

[0103] After the read buffer pool A reads the corresponding data, the remaining space length of the read buffer pool A is lena. At this time, the length of the read buffer pool A is increased by 1 / (1 - lena), and the space length of the read buffer pool B is decreased by 1 / (1 - lena);

[0104] After the read buffer pool B reads the corresponding data, the remaining space length of the read buffer pool B is lenb. At this time, the length of the read buffer pool B is increased by 1 / (1 - lenb), and the space length of the read buffer pool A is decreased by 1 / (1 - lenb).

[0105] Embodiment 3

[0106] For a GNSS network reference station system data scheduling method based on the MPTCP protocol as described in Embodiments 1 and 2, the specific communication process of the MPTCP protocol is as follows:

[0107] S31: The Ntrip broadcast server and Ntrip client establish an MPTCP connection: The Ntrip client initiates a TCP connection request to the Ntrip broadcast server, and the Ntrip broadcast server returns a TCP SYN / ACK handshake signal to establish a TCP connection; after the TCP connection is established, the Ntrip broadcast server and Ntrip client transmit data through the TCP connection;

[0108] S32: MPTCP Substream Creation: After establishing a TCP connection between the Ntrip client and the Ntrip broadcast server, the Ntrip client sends MPTCP protocol option information to the Ntrip broadcast server. Upon receiving the option information, the Ntrip broadcast server creates an MPTCP protocol substream for each network path. Each substream has independent TCP parameters, including sequence number, acknowledgment number, and window size. These substreams can transmit data simultaneously, thereby improving transmission efficiency and reliability.

[0109] S33: Data transmission: The Ntrip client divides the data stream into multiple sub-streams and sends them to different network paths respectively; after receiving the sub-streams, the Ntrip broadcast server merges them into a complete data stream and sends the data stream back to the Ntrip client;

[0110] S34: Data Flow Control: The MPTCP protocol controls data flow according to different network conditions. For example, when network congestion occurs on a certain network path, MPTCP can switch the traffic to other network paths to avoid data transmission interruption.

[0111] S35: Connection Close: After the Ntrip client and Ntrip broadcast server complete data transmission, the Ntrip client sends a TCP FIN signal to the Ntrip broadcast server to close the TCP connection; upon receiving the TCP FIN signal, the Ntrip broadcast server returns a TCP ACK signal and closes the TCP connection.

[0112] like Figure 1 As shown, the Ntrip protocol transmits various data types, including RTCM messages, NMEA messages, status information, and control commands. RTCM messages contain positioning information, accuracy information, and timing information from the satellite positioning system, while NMEA messages contain device information, location information, and time information. Furthermore, status information includes connection status, receiver status, and Ntrip server status, while control commands are used to establish, maintain, and close connections, as well as control the frequency of data transmission.

[0113] In GNSS network reference stations, RTCM messages typically contain positioning information, accuracy information, and timing information from the satellite positioning system. Some of this information needs to be transmitted promptly and maintain real-time performance. A multi-transmitter / selective receiver approach is required to ensure the timely transmission of RTCM and NMEA data requiring strong real-time performance. In a GNSS network reference station system, an RTCM data frame consists of five parts: a preamble, reserved words, the number of bytes occupied by the message, the message itself, and a CRC. The number of bytes occupied by the preamble, reserved words, message, and CRC is fixed, while the size of the message portion depends on the specific message type, generally ranging from 0 to 1023 bytes. Timing information mainly includes the satellite navigation system's time stamp, observation time stamp, and clock correction parameters. This information is crucial for satellite navigation data processing and accuracy calculation, improving positioning accuracy and reliability. Table 1 below shows the information body type table for RTCM as defined in this invention.

[0114] Table 1. Types of Information Bodies Defined by RTCM

[0115]

[0116]

[0117]

[0118]

[0119]

[0120] NMEA messages are a standard serial data format used to transmit GPS positioning information and other sensor data on ships and aircraft. The NMEA message format begins with a $ symbol and ends with a carriage return and a line feed, containing a series of fields separated by commas. In GNSS network base stations, NMEA messages contain device information, location information, and time information, and need to be transmitted promptly to ensure data real-time performance. Table 2 below classifies the information body format defined in this invention for NMEA.

[0121] Table 2: Classification of Information Body Formats Defined by NMEA

[0122]

[0123]

[0124]

Claims

1. A data scheduling method for a GNSS network reference station system based on the MPTCP protocol, characterized in that, include: Design the data transmission layer, data classification, and client-side buffer pool; The data transmission layer design replaces the underlying TCP protocol of Ntrip with the MPTCP protocol in the GNSS network reference station system. The MPTCP protocol uses multiple network interfaces to transmit data and divides the data stream into multiple sub-streams to transmit data on different network paths. The MPTCP protocol is used to achieve bandwidth aggregation and seamless switching between multiple paths: when packet loss occurs, feedback is promptly sent to the sender through multiple paths; The data classification is as follows: GNSS reference station data transmitted via the MPTCP protocol is classified into primary data and secondary data; the primary data includes high real-time RTCM data and NMEA data; the secondary data includes control commands, status information, and RTCM data and NMEA data without high real-time performance. The data classification includes the following steps: S11: Based on the differences in the format and content of the message headers and message payloads of the RTCM data and NMEA data, determine the type of GNSS reference station data transmitted via the MPTCP protocol, and then classify it into primary data and secondary data according to the real-time requirements of the GNSS reference station data transmitted via the MPTCP protocol: The RTCM data includes a specific binary message header; the RTCM data first has a 3-byte message header to identify the RTCM version and message type, then a 2-byte message length, followed by a message payload, the format of which varies depending on the message type, and finally a 3-byte CRC checksum. RTCM messages are divided into Level 1 data and Level 2 data according to their message type; the RTCM data includes a message header, message length, message payload, and CRC checksum. The NMEA data is transmitted using an ASCII message header. The format of the NMEA data message begins with a $ symbol and is followed by a series of fields used to identify the message type. Based on the message type of the NMEA message, the NMEA is divided into first-level data and second-level data. Table 3: Message Headers of RTCM Data Table 4 Examples of Main Message Types in NMEA Data S12: Perform a copy operation on the first-level data. If the number of sub-streams is n, then the number of first-level data packets copied is n-1. After copying, there are n identical first-level data packets in the data buffer pool, where n≥2. S13: Data allocation. A multi-transmission and selective reception strategy is adopted for the primary data. After copying the primary data in the data buffer pool, both the primary and secondary data enter the MPTCP protocol scheduler. The MPTCP scheduler allocates all data among substreams: n identical primary data packets in the data buffer pool are evenly distributed to each substream for data transmission; the secondary data is allocated to available substreams through the MPTCP scheduler. When data is transmitted to the client via a substream, upon receiving any primary data packet, all other data packets are discarded; upon receiving secondary data, the secondary data is directly read into the corresponding client buffer pool. The client-side buffer pool design is as follows: Data is first written to a read buffer, and then sent from the read buffer to the client buffer pool via the MPTCP protocol; the GNSS network base station transmits data to the client buffer pool simultaneously through multiple paths.

2. The data scheduling method for a GNSS network reference station system based on the MPTCP protocol according to claim 1, characterized in that, The specific methods for designing the client buffer pool include: S21: Data Processing: According to S11, determine whether the data is primary data or secondary data based on the data type in the data extension header; since the same number of primary data packets in the MPTCP protocol scheduler at the sending end have been copied in the same substream, delete the redundant identical primary data packets. S22: Check the client buffer pool: Determine if there is remaining space in the corresponding read client buffer pool in the MPTCP multipath transport protocol: When there is no remaining space in the client buffer pool, the corresponding data that enters the client buffer pool will enter the waiting phase. That is, the corresponding data that enters the waiting phase will only enter the client buffer pool when the server reads that there is free space in the client buffer pool. When there is remaining free space in the client buffer pool, the corresponding data is put into the client buffer pool according to the remaining size of the client buffer pool. S23: Adjustment of the client buffer pool after receiving data: The client buffer pool is equally divided into buffer pool A and buffer pool B; After data enters the corresponding client buffer pool, the sizes of buffer pool A and buffer pool B are adjusted. After adjustment, the remaining space of buffer pool A and buffer pool B are compared, and the value of the client buffer pool with the larger remaining space is transmitted to the Ntrip broadcast server. The Ntrip broadcast server adjusts the size of the sending window in the sliding window according to the received size of the client buffer pool, and then the Ntrip broadcast server continues to transmit data to the Ntrip client through the sub-stream of the MPTCP protocol.

3. The data scheduling method for a GNSS network reference station system based on the MPTCP protocol according to claim 1, characterized in that, The specific communication process of the MPTCP protocol is as follows: S31: Ntrip broadcast server and Ntrip client establish MPTCP connection: Ntrip client initiates TCP connection request to Ntrip broadcast server, Ntrip broadcast server returns TCP SYN / ACK handshake signal, and TCP connection is established; S32: Creation of MPTCP Protocol Substreams: After establishing a TCP connection between the Ntrip client and the Ntrip broadcast server, the Ntrip client sends MPTCP protocol option information to the Ntrip broadcast server; upon receiving the option information, the Ntrip broadcast server creates an MPTCP protocol substream for each network path. Each substream has independent TCP parameters, including: sequence number, acknowledgment number, and window size. S33: Data transmission: The Ntrip client divides the data stream into multiple sub-streams and sends them to different network paths respectively; after receiving the sub-streams, the Ntrip broadcast server merges them into a complete data stream and sends the data stream back to the Ntrip client; S34: Data Flow Control: The MPTCP protocol controls data flow based on different network conditions; S35: Connection Close: After the Ntrip client and Ntrip broadcast server complete data transmission, the Ntrip client sends a TCP FIN signal to the Ntrip broadcast server to close the TCP connection; upon receiving the TCP FIN signal, the Ntrip broadcast server returns a TCP ACK signal and closes the TCP connection.

Images