High-reliability multi-stream service scheduling method for railway safety services
By dynamically selecting redundant multi-stream and single-stream transmission modes under the multi-mode collaborative vehicle-mounted integrated wireless access architecture, the high reliability and low latency problems of railway mobile communication systems when transmitting railway security services are solved, and efficient resource utilization is achieved.
Patent Information
- Application Number
- CN202510215386.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-26
- Publication Date
- 2025-07-04
AI Technical Summary
When existing railway mobile communication systems transmit railway security services, it is difficult to meet the needs of high reliability and low latency at the same time, especially in a network environment where multiple communication modes coexist, resource utilization efficiency is low.
The multi-mode collaborative in-vehicle integrated wireless access architecture under the MPTCP mechanism is adopted, and the redundant multi-stream transmission mode and single-stream transmission mode are dynamically selected, and the transmission strategy is optimized according to the link status and service type, and 5G-R, GSM-R, railway 400MHz digital wireless column regulating system, public network 5G and satellite network resources are used to achieve high-reliability and low-latency transmission of railway security services.
While meeting the real-time data transmission needs of railway security services, the utilization of transmission resources is reduced, the reliability and efficiency of transmission is improved, and the utilization of network resources is optimized.
Smart Images

Figure HDA0005287197500000011 
Figure HDA0005287197500000021 
Figure HDA0005287197500000031
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of wireless communication, and particularly relates to a high-reliability multi-stream service scheduling method for railway safety-related services. Background Art
[0002] The new generation of railway mobile communication systems is evolving towards a dedicated railway wireless communication network (5G for Railway, 5G-R) that uses the Fifth Generation of Mobile Communication (5G). There will be a relatively long transition period during which multiple communication modes such as the Global System for Mobile Communication-Railway (GSM-R), 5G-R, and 400 MHz digital wireless train dispatching systems coexist. To further improve the transmission reliability mode of railway mobile communication systems, it is necessary to make full use of the available railway ground networks to build a multi-mode, multi-band collaborative vehicle-mounted integrated wireless access architecture based on 5G-R, GSM-R, railway 400 MHz digital wireless train dispatching systems, public network 5G, and satellites. By effectively integrating and optimizing various network resources, the transmission reliability and transmission capacity of railway mobile communication system safety-related services can be improved to meet the requirements of future intelligent railway development.
[0003] Railway safety-related services are an important part of railway train operation command and play an important role in maintaining train operation order and reducing safety risks. Such services require high-reliability and low-latency data transmission capabilities to support reliable real-time data interaction between trains and ground control systems. As mentioned above, the transmission reliability of railway safety-related services can be improved by integrating multiple available railway network resources. Summary of the Invention
[0004] In view of the above problems, the present invention provides a high-reliability multi-stream service scheduling method for railway safety-related services under a multi-mode collaborative vehicle-mounted integrated wireless access architecture of 5G-R, GSM-R, railway 400 MHz digital wireless train dispatching systems, public network 5G, and satellites that adopts the MPTCP mechanism.
[0005] Based on the railway multi-mode collaborative mobile communication network architecture of the MultiPath Transport Control Protocol (MPTCP), the present invention proposes a multi-stream service scheduling method for railway safety-related services. The method includes two transmission modes: redundant multi-stream mode and single-stream mode. The channel condition is judged according to the round-trip time (RTT) of sub-streams and the cumulative number of consecutive successful transmissions of data packets. When the channel condition is good, the single-stream transmission mode is adopted to ensure the transmission capacity. When the channel condition is poor, the redundant multi-stream transmission mode is adopted to ensure the transmission reliability.
[0006] A highly reliable multi-stream service scheduling method for railway safety-related services according to the present invention dynamically selects the redundant multi-stream transmission mode or the single-stream transmission mode according to the link state, including the sub-stream connection establishment stage and the transmission stage. The transmission stage can adopt two modes: redundant multi-stream transmission and single-stream transmission, and the transmission mode is dynamically selected according to the transmission threshold. Specifically as follows:
[0007] In the stage of establishing multiple sub-streams of MPTCP, the format of the MP_JOIN header option field in the header information of SYN data packets, SYN / ACK data packets, and ACK data packets is designed. The SYN data packet carries service type and scheduling method information, and is responsible for informing the receiving party of the service type to be transmitted and the supported multi-stream service scheduling method; the SYN / ACK data packet also carries service type and scheduling method information, and is responsible for informing the sending party whether to select the multi-stream service scheduling method; the ACK data packet carries single-stream transmission threshold and RTT threshold information. If the service to be transmitted is a railway safety-related service and the highly reliable multi-stream service scheduling method is adopted, the specific threshold information is informed to the receiving party. If the service to be transmitted is not a railway safety-related service, conventional information is sent.
[0008] In the redundant multi-stream transmission mode, at least two sub-streams are selected to redundantly send data packets according to the multi-stream scheduling method agreed upon by the sender and the receiver, and the cumulative number of consecutive successful transmissions of data packets is recorded. For example, the two sub-streams with the smallest RTT can be selected for redundant multi-stream transmission according to the historical RTT data of each sub-stream; if the data packet is successfully transmitted, the cumulative counter of consecutive successful transmissions of the data packet will be incremented by one; if the data packet transmission fails, retransmission is performed, the cumulative counter of consecutive successful transmissions of the data packet is set to 0, and redundant multi-stream transmission continues. When the cumulative number of consecutive successful transmissions reaches the preset single-stream transmission threshold, the single-stream transmission mode is entered, and the cumulative counter of consecutive successful transmissions of the data packet is reset to 0; otherwise, the redundant multi-stream transmission mode is continued, and at least two sub-streams are selected for transmission according to the above redundant multi-stream transmission process.
[0009] In the single - stream transmission mode, the cumulative number of successful consecutive transmissions of data packets is reset to 0. The sender will compare the RTT of each sub - stream in the previous time to determine whether the RTT of the sub - stream has decreased, and filter out the sub - streams with decreased RTT. Among these sub - streams, the sub - stream with the largest CWND value is selected for transmission; if the RTT of all sub - streams has not decreased, the sender will filter out the sub - streams with RTT lower than the RTT threshold, and among these sub - streams, the sub - stream with the largest CWND value is selected for transmission; if the RTT of all sub - streams is higher than the preset RTT threshold, the sender will select the sub - stream with the smallest RTT for transmission. If the data packet transmission is successful, the single - stream transmission mode will continue to be maintained, and the sub - stream will be selected for transmission according to the above - mentioned single - stream transmission process; if the data packet transmission fails, re - transmission will be performed, and after the re - transmission is completed, it will switch to the redundant multi - stream transmission mode.
[0010] Furthermore, the transmission mode and threshold are negotiated by the sender and receiver when establishing connections for multiple sub - streams during the MPTCP three - way handshake. During the first handshake, the sender needs to send a SYN data packet with an improved MP_JOIN option field, informing the receiver that the current transmitted service is a railway safety - related service, and the sender supports a high - reliability multi - stream service scheduling method for railway safety - related services; during the second handshake, the receiver needs to send a SYN / ACK data packet with an improved MP_JOIN option field for response, informing the sender whether to use the high - reliability multi - stream service scheduling method; during the third handshake, if the transmitted service is a railway safety - related service and both parties adopt the high - reliability multi - stream service scheduling method, the sender needs to send an ACK data packet with an improved MP_JOIN option field to the receiver, informing the specific single - stream transmission threshold and RTT threshold information.
[0011] The beneficial technical effects of the present invention are as follows:
[0012] The present invention relates to a multi - path scheme in the transport layer. The ground terminal system can obtain information such as the delay, packet loss, bandwidth, and congestion status of each path of MPTCP for service splitting decision - making; the multi - stream service scheduling method proposed by the present invention can dynamically select the redundant multi - stream transmission mode or the single - stream transmission mode according to the link state, select appropriate sub - streams for transmission, implement an optimal transmission strategy, and minimize the occupation of transmission resources on the premise of meeting the high - reliability and low - delay requirements of real - time data transmission for railway safety - related services. Description of the Drawings
[0013] Figure 1 is a schematic diagram of a multi - mode fusion radio access network architecture based on MPTCP provided by the embodiment.
[0014] Figure 2 is a schematic diagram of a data transmission protocol stack of a multi - mode fusion radio access network based on MPTCP provided by the embodiment.
[0015] Figure 3 It is a schematic flow diagram of signaling interaction in the MPTCP sub-flow connection establishment phase provided by the embodiment.
[0016] Figure 4 It is a schematic flow diagram of a highly reliable multi-flow service scheduling method for railway safety-related services according to the present invention.
[0017] Figure 5 It is a schematic format diagram of the MP_JOIN option field in a SYN packet provided by the embodiment of the present invention.
[0018] Figure 6 It is a schematic format diagram of the MP_JOIN option field in a SYN / ACK packet provided by the embodiment of the present invention.
[0019] Figure 7 It is a schematic format diagram of the MP_JOIN option field in an ACK packet provided by the embodiment of the present invention. Detailed implementation manners
[0020] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0021] Based on the railway multi-mode collaborative mobile communication network architecture of the MultiPath Transport Control Protocol (MPTCP), this invention proposes a multi-stream service scheduling method for railway safety-related services to achieve highly reliable transmission of railway safety-related service modes. The core of this method is to dynamically select redundant multi-stream transmission mode or single-stream transmission mode according to the link state, aiming to select appropriate sub-streams for transmission. The method includes two modes: redundant multi-stream mode and single-stream mode. When the channel condition is good, the single-stream transmission mode is adopted to ensure the transmission capacity, and when the channel condition is poor, the redundant multi-stream transmission mode is adopted to ensure the transmission reliability. Due to the performance differences such as delay and bandwidth in multiple transmission paths of MPTCP, the system defaults to the redundant multi-stream transmission mode. First, at least two sub-streams are selected to redundantly send data packets according to the multi-stream scheduling method agreed upon by the sender and receiver, and the cumulative number of successful consecutive transmissions of the data packets is recorded. Two sub-streams with the smallest Round-Trip Time (RTT) values can be selected for redundant multi-stream transmission according to the historical RTT values of each sub-stream. If the cumulative number of successful consecutive transmissions reaches the preset single-stream transmission threshold, single-stream transmission is performed and the cumulative number of successful consecutive transmissions of the data packets is reset to 0, otherwise, redundant multi-stream transmission continues. In the single-stream transmission mode, the cumulative number of successful consecutive transmissions of the data packets is set to 0, and the sender selects the optimal sub-stream for transmission according to the RTT threshold and the Congestion Window (CWND) value. If the transmission is successful, single-stream transmission continues to be selected. If the transmission fails, it means that the current path performance is poor, and after the retransmission ends, the redundant multi-stream transmission mode is switched for transmission. Through the above process, the redundant multi-stream transmission and single-stream transmission modes are continuously switched, and single-stream and multi-stream transmissions are dynamically selected according to the congestion conditions and channel quality of different networks, minimizing the occupation of transmission resources on the premise of ensuring the highly reliable and low-latency transmission requirements of railway safety-related services.
[0022] Embodiment:
[0023] First, the multi-mode fusion radio access network architecture applicable to the embodiment is described.
[0024] Figure 1 A schematic diagram of a railway multi-mode fusion radio access network architecture based on MPTCP provided for the embodiment. The fusion network includes 5G-R, GSM-R, railway 400MHz digital wireless train dispatching system, public network 5G, and satellite network.
[0025] Figure 2Schematic diagram of a multi-mode fusion radio access network data transmission protocol stack based on MPTCP provided for the embodiment. This data transmission protocol stack uses the MPTCP method to replace the Transmission Control Protocol (TCP) method, schedules and manages multiple subflows, and provides end-to-end reliable transmission.
[0026] Figure 3 Schematic diagram of the signaling interaction process in the MPTCP subflow connection establishment phase provided for the embodiment. Among them, MPTCP first exchanges the MP_CAPABLE option field to initialize the first subflow, and then exchanges the MP_JOIN option field to add the remaining subflows to the current connection.
[0027] Figure 4It is a schematic flowchart of a highly reliable multi - flow service scheduling method for railway safety - related services in the present invention. Among them, the redundant multi - flow transmission mode is default at the beginning of transmission. The sender selects the two sub - flows with the smallest RTT according to the historical RTT data of each sub - flow and sends the data packets redundantly. For railway safety - related services with small data volume and high latency requirements, sending the same data packets on different sub - flows can ensure the lowest transmission latency to the greatest extent in the existing network. In the redundant multi - flow transmission mode, if the data packet transmission is successful, the cumulative number of consecutive successful transmissions increases by one; if the data packet transmission fails, re - transmission is carried out, the cumulative number of consecutive successful transmissions is set to 0, and redundant multi - flow transmission continues. If the cumulative number of consecutive successful transmissions reaches the preset single - flow transmission threshold, the sender will enter the single - flow transmission mode, and the cumulative number of consecutive successful transmissions is reset to 0. In the single - flow transmission mode, the cumulative number of consecutive successful transmissions of the data packet is set to 0, and the sender filters out the sub - flows with decreasing RTT according to the previous RTT data of each sub - flow. It should be noted that due to the real - time nature of the vehicle - to - ground transmission link, the real - time status of each sub - flow cannot be obtained. Therefore, it is necessary to count the historical RTT information of the sub - flows associated with each ground base station as the decision - making basis. If there are sub - flows with decreasing RTT, the sub - flow with the largest CWND is selected for transmission among these sub - flows; if the RTT of each sub - flow increases or remains unchanged, the sub - flows below the preset RTT threshold are filtered out, and the sub - flow with the largest CWND is selected for transmission among these sub - flows. If the RTT of all sub - flows is higher than the preset RTT threshold, the sub - flow with the smallest RTT is selected for transmission. If the data packet transmission is successful, it is checked whether all the data to be transmitted has been transmitted. If all the data has been transmitted, the sub - flow scheduling ends; otherwise, the single - flow transmission mode continues to start the next round of transmission; if the data packet transmission fails, re - transmission is carried out, and after the re - transmission ends, it switches to the redundant multi - flow transmission mode. It should be noted that the change of RTT can characterize the stability of path data transmission. The smaller the change, the more stable the transmission; the larger the change, the more unstable the transmission. Each sub - flow in MPTCP maintains a congestion window, and the congestion window can reflect the congestion degree of each path in MPTCP.
[0028] In the sub - flow connection establishment phase, after the MPTCP connection completes the initialization of the first sub - flow, the sender and receiver execute a three - way handshake to add other sub - flows to the current connection based on the control information carried in the sub - fields of the MP_JOIN header option field of the MPTCP packet. In the first handshake, the ground device needs to send a SYN packet to inform the vehicle device that the current transmitted service is a railway safety - related service, and the ground device supports the high - reliable multi - flow service scheduling method; in the second handshake, the vehicle device needs to send a SYN / ACK packet for response to inform the ground device whether to use the high - reliable multi - flow service scheduling method; in the third handshake, if the ground device determines that the transmitted service is a railway safety - related service and both parties use the high - reliable multi - flow service scheduling method, the ground device needs to send an ACK packet to the vehicle device to inform the specific single - flow transmission threshold and RTT threshold information. It should be noted that the MP_JOIN header option field exists in the SYN, SYN / ACK, and ACK packets of the three - way handshake. This field is located between the header information and the data content of the MPTCP packet and carries control and management information. Therefore, it is necessary to specifically design the format of the MP_JOIN header option field of the packets used in the above process. (1) Format design of the MP_JOIN header option field of the SYN packet in the first handshake.
[0029] The format of the MP_JOIN option field in the SYN packet during the first handshake is as Figure 5 (b) shown, and the format of the MP_JOIN option field in the original SYN packet in the RFC6824 document is as Figure 5 (a) shown. Improve the MP_JOIN option field of the SYN packet in the RFC6824 document, mainly adding the ServiceType field and the SchedulingMethod field; it should be noted that the optional implementation schemes of the content of the MP_JOIN option field in the SYN packet include but are not limited to Figure 5 the schemes shown. The following elaborates on the function definitions of each field:
[0030] a) Kind field
[0031] This field is used to indicate the type of the option field. When the value of this field is 30, it means that this header option field is an MPTCP header option field.
[0032] b) Length field
[0033] This field is used to indicate the length of the header option field.
[0034] c) Subtype field
[0035] This field is used to indicate the subtype of the MPTCP option field. When this field is set to 0x1, it indicates that the subtype is the MP_JOIN option field for joining an MPTCP connection.
[0036] d) ServiceType field
[0037] This field is used to indicate the type of service. Compared with the MP_JOIN option field format in the SYN packet in RFC6824, the present invention adds a new ServiceType field, which is 1 bit. When this field is set to 1, it indicates that the service type is a railway safety service; when this field is set to 0, it indicates that the service type is other services.
[0038] e) SchedulingMethod field
[0039] This field is used to indicate whether the sender of this option field supports the high-reliability multi-stream service scheduling method. Compared with the MP_JOIN option field format in the SYN packet in RFC6824, the present invention adds a new SchedulingMetho field, which is 1 bit. When the value of the ServiceType field is 1, this field is set to 1, indicating that the sender of this option field supports the high-reliability multi-stream service scheduling method; when this field is set to 0, it means that the sender of this option field does not support the high-reliability multi-stream service scheduling method.
[0040] f) B field
[0041] This field is used to indicate whether the current subflow is used as an alternative path. When this field is set to 1, it means that the sender of this option field will use the current subflow as an alternative path when other paths fail; when this field is set to 0, it means that the sender of this option field will not use the current subflow as an alternative path when other paths fail.
[0042] g) Address ID field
[0043] This field is used to indicate the source address of the current packet.
[0044] h) Receiver’s Token field
[0045] This field is used to indicate the token value of the receiver.
[0046] i) Sender’s Random Number field
[0047] This field is used to indicate the random number sent by the sender.
[0048] (2) Design of the MP_JOIN header option field format for the SYN / ACK packet during the second handshake.
[0049] The format of the MP_JOIN option field in the SYN / ACK packet is as shown in Figure 6 (b), and the format of the MP_JOIN option field in the original SYN / ACK packet in RFC6824 is as shown in Figure 6 (a). The design is based on the MP_JOIN option field in the SYN / ACK packet of RFC6824; mainly, the ServiceType field and the SchedulingMethod field are newly added; the optional implementation schemes of the content of the MP_JOIN option field in the SYN / ACK packet include but are not limited to Figure 6 the schemes shown below, and the function definitions of each field are described as follows:
[0050] a) Kind field
[0051] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0052] b) Length field
[0053] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0054] c) Subtype field
[0055] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0056] d) ServiceType field
[0057] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0058] e) SchedulingMethod field
[0059] This field is used to indicate whether the sender of this option field uses the high-reliability multi-stream service scheduling method. Compared with the format of the MP_JOIN option field in the SYN packet in RFC6824, a new SchedulingMethod field is added in the present invention, which is 1 bit. When the value of the ServiceType field is 1, this field can be set to 1 or 0. When this field is set to 1, it indicates that the sender of this option field selects to use the high-reliability multi-stream service scheduling method to transmit railway safety-related services. When this field is set to 0, it means that the sender of this option field does not use the high-reliability multi-stream service scheduling method. When the value of the ServiceType field is 0, this sub-field is set to 0, indicating that the sender of this option field does not use the high-reliability multi-stream service scheduling method.
[0060] f) Field B
[0061] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0062] g) Address ID Field
[0063] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0064] h) Sender’s Truncated HMAC Field
[0065] This field is used to indicate the truncated HAMC value of the sender.
[0066] i) Sender’s Random Number Field
[0067] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0068] (3) Format design of the MP_JOIN header option field in the SYN / ACK packet during the third handshake.
[0069] The format of the MP_JOIN option field in the ACK packet during the third handshake is as Figure 7 (b) shown, and the format of the MP_JOIN option field in the original ACK packet in the RFC6824 document is as Figure 7 (a) shown. The design is based on the MP_JOIN option field in the ACK packet in the RFC6824 document; the main difference is the redefinition of the reserved field; the optional implementation schemes of the content of the MP_JOIN option field in the ACK packet include but are not limited to Figure 7 the schemes shown, and the function definitions of each field are described below:
[0070] a) Kind Field
[0071] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0072] b) Length Field
[0073] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0074] c) Subtype Field
[0075] The meaning of this field is the same as the description of the MP_JOIN option field in the SYN packet.
[0076] d) Mode Switch Threshold Scale Field
[0077] This field is used to indicate the scaling degree of the single - stream transmission threshold. Compared with the MP_JOIN option field format of the ACK packet in RFC6824, in the present invention, a Mode Switch Threshold Scale field is re - defined in the original reserved field, which is a 2 - bit unsigned integer. When the value of this field is 00B, it represents a scaling factor of 1; when the value of this field is 01B, it represents a scaling factor of 2; when the value of this field is 10B, it represents a scaling factor of 4; when the value of this field is 11B, it represents a scaling factor of 8.
[0078] e) Mode Switch Threshold Field
[0079] This field is used to indicate the single - stream transmission threshold information. The single - stream transmission threshold indicated by this field multiplied by the single - stream transmission threshold scaling factor is the transmission single - stream transmission threshold. Compared with the MP_JOIN option field format of the ACK packet in RFC6824, in the present invention, a Mode Switch Threshold field is re - defined in the original reserved field, which is a 3 - bit unsigned integer, and its value range is 0 - 7. When the value of the Mode Switch Threshold Scale field is 01B and the value of this field is 101B, it represents that the single - stream transmission threshold is set to 10 times.
[0080] f) Time Unit Type Field
[0081] This field is used to indicate the time unit type of the RTT threshold. Compared with the MP_JOIN option field format of the ACK packet in RFC6824, in the present invention, a Time Unit Type field is re - defined in the original reserved field, which is 1 bit. When the value of this field is 0, it represents that the time unit of the RTT threshold is microseconds; when the value of this field is 1, it represents that the time unit of the RTT threshold is milliseconds.
[0082] g) RTT Threshold Scale Field
[0083] This field is used to indicate the scaling degree of the RTT threshold. Compared with the MP_JOIN option field format of the ACK packet in RFC6824, in the present invention, a RTT Threshold Scale field is redefined in the original reserved field. It is an unsigned integer of 3 bits, and the value range is 0 to 7. When the value of this field is 000B, it represents a scaling factor of 1; when the value of this field is 001B, it represents a scaling factor of 2; when the value of this field is 010B, it represents a scaling factor of 4; when the value of this field is 011B, it represents a scaling factor of 8; when the value of this field is 100B, it represents a scaling factor of 16; when the value of this field is 101B, it represents a scaling factor of 32; when the value of this field is 110B, it represents a scaling factor of 64; when the value of this field is 111B, it represents a scaling factor of 128;
[0084] h) RTT Threshold field
[0085] This field is used to indicate the RTT threshold information. The RTT threshold information indicated by this field multiplied by the RTT threshold scaling factor is the transmitted RTT threshold. Compared with the MP_JOIN option field format of the ACK packet in the third handshake of RFC6824, in the present invention, a RTT Threshold field is redefined in the original reserved field. It is an unsigned integer of 3 bits. When the value of the Time Unit Type field is 1, the value of the RTT Threshold Scale field is 110B, and the value of this field is 011B, it represents that the RTT threshold is set to 192 milliseconds at this time.
[0086] i) Sender’s HMAC field
[0087] This field is used to indicate the HMAC value of the sender.
[0088] The above are only some embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.
Claims
1. A highly reliable multi-stream service scheduling method for railway safety-related services, characterized in that The Multi-Path Transmission Control Protocol (MPTCP) is adopted to replace the TCP method for scheduling and managing multiple sub-streams, and the redundant multi-stream transmission mode or the single-stream transmission mode is dynamically selected according to the link state to ensure end-to-end reliable transmission. In the redundant multi-stream transmission mode, at least two sub-streams are selected to redundantly send data packets according to the multi-stream scheduling method agreed upon by the sender and the receiver, and the cumulative number of successful consecutive transmissions of the data packets is recorded. When the cumulative number of successful consecutive transmissions reaches the preset single-stream transmission threshold, the single-stream transmission mode is entered, and the cumulative number of successful consecutive transmissions of the data packets is reset to 0. Otherwise, the redundant multi-stream transmission mode is continued, and at least two sub-streams are selected for transmission according to the above redundant multi-stream transmission process. In the single-stream transmission mode, the cumulative number of successful consecutive transmissions of the data packets is set to 0. The sender compares whether the round-trip time (RTT) of each sub-stream has decreased compared to the previous time, and filters out the sub-streams with decreased RTT. Among these sub-streams, the sub-stream with the largest congestion window (CWND) value is selected for transmission. If the RTT of all sub-streams has not decreased, the sender filters out the sub-streams with RTT lower than the RTT threshold, and among these sub-streams, the sub-stream with the largest CWND value is selected for transmission. If the RTT of all sub-streams is higher than the preset RTT threshold, the sender will select the sub-stream with the smallest RTT for transmission. If the data packet is successfully transmitted, the single-stream transmission mode is continued, and the sub-stream is selected for transmission according to the above single-stream transmission process. If the data packet transmission fails, retransmission is performed, and after the retransmission ends, the redundant multi-stream transmission mode is switched to.
2. The highly reliable multi-stream service scheduling method for railway safety-related services according to claim 1, wherein The transmission mode and threshold are negotiated by the sender and the receiver when establishing connections for multiple sub-streams during the MPTCP three-way handshake. During the first handshake, the sender needs to send a SYN data packet with an improved MP_JOIN option field, informing the receiver that the current transmitted service is a railway safety service, and the sender supports the high-reliability multi-stream service scheduling method for railway safety services. During the second handshake, the receiver needs to send a SYN / ACK data packet with an improved MP_JOIN option field for response, informing the sender whether to use the high-reliability multi-stream service scheduling method. During the third handshake, if the transmitted service is a railway safety service and both parties adopt the high-reliability multi-stream service scheduling method, the sender needs to send an ACK data packet with an improved MP_JOIN option field to the receiver, informing the specific single-stream transmission threshold and RTT threshold information.