Multipath Receiver and 3GPP ATSSS Processing on the Multipath Receiver

Abstract

A multipath receiver includes: a reordering queue device configured to queue data packets received on multiple paths; a reordering queue controller configured to reorder the data packets in the reordering queue according to reordering criteria, wherein the reordering queue controller is configured to allow an ATSSS-based MA PDU session, wherein the reordering criteria are based on the sequence numbers of the data packets of the ATSSS-based MA PDU session, and wherein the reordering queue controller is configured to select to activate the reordering of the data packets. The present invention further relates to a method of processing data packets received by a multipath receiver.

Description

Technical Field

[0001] The present invention relates to a multipath receiver, which includes a reordering queue device configured to queue data packets received on multiple paths, and includes a reordering queue controller configured to reorder the data packets in the reordering queue according to reordering criteria. The present invention further relates to a method for processing data packets received by a multipath receiver. Background Art

[0002] This innovation is carried out in the context of a UE or RG receiving 3GPP and non-3GPP data packets distributed across multiple paths of a multipath channel. The architectural framework, terms, definitions, and references used in this application refer to the technical report TR-23.700-53, "Study on access traffic steering, switching and splitting support in the 5G system architecture", and other standards developed within the scope of 3GPP. This application adopts all the terms, definitions, and abbreviations used in these standards and technical specifications.

[0003] Since Release 16, ATSSS has been defined as part of the system architecture of the 5G system (5GS) specification TS23.501 for combining 3GPP and non-3GPP access between the UE / RG and the 5G core. The main ATSSS enhancements proposed within the scope of the Release 18 technical report TR-23.700-53 are new steering functionalities in addition to the existing ATSSS-LL and MPTCP steering functionalities defined in TS23.501, which can be used to support the steering, switching, and splitting of non-TCP traffic flows (e.g., UDP traffic flows and IP traffic flows).

[0004] Depending on the characteristics negotiated during the MA PDU session establishment and ATSSS rule exchange, it can be selected whether to apply the steering, switching or splitting, steering function (e.g., ATSSS-LL or MPTCP), steering mode (e.g., based on priority or load balancing), and this category. The latter uses ATSS-specific UE routing selection policies (URSPs) and ATSSS rules to apply ATSSS settings to any traffic or specific traffic based on, for example, AppID, IP address, etc.

[0005] Although these settings have determined the behavior of the sender in traffic handling so far, the situation on the receiver side has not been reflected. With the upcoming version discussion, the receiver side has become the focus. Currently, ATSSS-LL does not fully support traffic splitting for non-TCP traffic flows because this guiding functionality may introduce out-of-order delivery, which can seriously affect the transmission performance.

[0006] Compared with ATSSS-LL that does not support traffic splitting at all and MPTCP that inherits the TCP reordering principle, the requirements for non-TCP traffic splitting regarding reassembling the data stream on the receiver side are different. It is expected that in some cases, the receiver side needs to handle the split traffic to compensate for the different path propagations that result in out-of-order arrivals.

[0007] In the case where UDP traffic is distributed across multiple paths, it is likely that the strict in-order delivery known in MPTCP is not useful. When several paths are concurrently utilized to transfer user data between the sender and the receiver, the different characteristics of the paths in terms of bandwidth, latency, or error-proneness will affect the overall performance due to delayed packet arrivals and / or lost packets. Once a packet is lost, this will cause the receiver reordering process to immediately stall because UDP has no way to retransmit the lost packet. Packet loss detection becomes very important when applying multi-path protocols because multi-path protocols do not guarantee successful transmission by acknowledging successful reception like TCP. For example, MP-DCCP or MP-QUIC with the DATAGRAM extension is an unreliable protocol in this sense.

[0008] Therefore, it is recommended to provide a more relaxed reordering mode in addition to strict in-order delivery and make it part of the ATSSS framework.

[0009] As defined in Section 5.1 of TR-23.700-53, 3GPP is looking for a solution to split non-TCP traffic across multiple paths. Any solution discussed in the corresponding solution space will be affected by the different access characteristics provided by the combination of 3GPP access (e.g., cellular) and non-3GPP access (e.g., Wi-Fi). For example, the split data streams will experience different path delays, bandwidths, and packet loss rates, which cause out-of-order delivery at the multi-path receiver (e.g., UE, RG, AT3S UPF, or service endpoint). Services that are sensitive to this out-of-order delivery will potentially respond with degraded QoS, such as service interruption or data transmission being adjusted to a lower data rate. Summary of the Invention

[0010] The object of the present invention is to provide a concept for solving the above problems, that is, to define a reordering pattern for the ATSSS use case, a negotiation protocol for applying these reordering patterns, and the interaction with the boot mode (specifically for the identified key problems).

[0011] Therefore, the present invention defines a multipath receiver, a method for processing data packets received by the multipath receiver, and a non-transitory computer-readable medium storing computer instructions. Some further embodiments of the present invention are defined in the dependent claims.

[0012] The devices and methods proposed below can be of various types. Each element and feature can be implemented by hardware and / or software components. According to the present application, multipath includes at least two data packet transmission paths.

[0013] The core idea of the present invention is to provide a multipath receiver as described above, wherein the reordering queue controller is configured to allow an ATSSS-based MAPDU session, in other words, wherein the reordering queue controller is capable of operating on an ATSSS-based MAPDU session, and wherein the reordering criterion is based on the sequence number of the data packets of the ATSSS-based MAPDU session.

[0014] A common feature of all reordering patterns is the non-strict application of data ordering. The basic concept of reordering is to restore the data stream order to be close to the order generated on the sender side. The challenges to be overcome are the handling of packet loss during the reordering process and the decision on how long to wait for the lost data. Using the sequence number as the reordering criterion for the data packets received during an ATSSS-based MAPDU session is the main feature of the reordering of the present invention related to the ATSSS use case.

[0015] The method of the present invention includes receiving data packets of an ATSSS-based MAPDU session on multiple paths, wherein the reordering queue controller of the multipath receiver selects to activate the reordering of the received data packets, wherein in the case where the reordering is activated, the data packets are queued in the reordering queue, and the data packets are reordered in the reordering queue according to the reordering criterion, and wherein the reordering criterion is based on the sequence number of the data packets.

[0016] In a preferred embodiment, the multipath receiver, particularly the reordering queue controller, is configured to select to activate the reordering of data packets. Thus, the multipath receiver, particularly the reordering queue controller of the multipath receiver, can activate or deactivate reordering. This feature also includes selecting to deactivate reordering when reordering is currently active. In an enhanced embodiment of this configuration, the multipath receiver is configured to negotiate with the peer of the ATSSS-based MA PDU session (in other words, with the peer of the multipath receiver) to activate the reordering of data packets. This negotiation allows the multipath receiver to reach an agreement on whether reordering is suitable for the current use case. Preferably, this negotiation is carried out during the establishment of the MA PDU session as part of the ATSSS and N4 rule negotiation.

[0017] In another preferred embodiment, the reordering queue controller is configured to detect packet loss of data packets based on the comparison of at least two sequence numbers of the received data packets, and in the case where packet loss of data packets is detected, the reordering queue controller is configured to select a reordering mode for the received data packets, particularly to negotiate the reordering mode with the peer of the ATSSS-based MA PDU session (in other words, with the peer of the multipath receiver). This negotiation allows the multipath receiver to reach an agreement on the best reordering mode for the current use case. Preferably, this negotiation is also carried out during the establishment of the MA PDU session as part of the ATSSS and N4 rule negotiation.

[0018] In this application Figure 1 a segment extraction depicts the basic information of the MA PDU session establishment fully shown in the flowchart of Section 6.3.3 of TR-23.700-53. The above negotiation to activate reordering and / or the reordering mode is preferably embedded in points 5a, 5b, 6a, 6b or 6c of the flowchart.

[0019] Preferably, the reordering mode is based on the ATSSS guiding function (e.g., ATSSS-LL, MPTCP, MP-DCCP-LL or MP-QUIC), and / or the ATSSS guiding mode (e.g., active standby, minimum latency, load balancing or priority-based).

[0020] The reordering mode can be a strict sequence number-based reordering. This method encompasses all mechanisms that attempt to accurately regenerate the original order of data packets in the stream, regardless of the expected or caused delay due to the waiting time for all packets to arrive on all paths. In the case of a given unreliable transport protocol, this may lead to significant delays due to head-of-line blocking and actual packet loss in the remaining packet gaps (which causes irrecoverable stalls). For applications that require near real-time delivery of packets, this method should not be adopted.

[0021] Preferred reordering criteria for the reordering mode include a static expiration timer for packet loss detection or a dynamic expiration timer for packet loss detection, where the static or dynamic expiration time is preferably based on path-specific characteristics of multiple paths, especially latency.

[0022] The method includes a static expiration timer for detecting and determining packet loss, which assumes a certain fixed time threshold for the gap between data packets in the sequence after recombining two paths. Before this threshold is exceeded, a possible retransmission may not be requested (either within the multipath system or based on the underlying protocol / service). Therefore, there will be additional delays in the overall latency budget, so this simple method is only recommended for non-time-critical applications. Each packet loss or simultaneous transmission of data on short-latency and long-latency paths will cause a peak in the service-perceived latency.

[0023] In the method including a dynamic expiration timer, the packet gap is assumed to be a packet loss after exceeding a flexibly determinable time threshold, which can be dynamically derived from the latency difference exhibited by the two paths. Since the latency may vary due to propagation conditions or routing paths, the latency difference must be monitored and statistically evaluated (smoothed), which introduces additional work. A possible solution to this is to determine the one-way latency or send the available RTT information from the sender, based on which the multipath receiver can calculate the latency difference.

[0024] In another preferred embodiment, the sequence number of the data packet is a path-specific number, and the reordering criterion is based on the path-specific number of the data packet, and / or the sequence number of the data packet is an overall sequence number across multiple paths, and the reordering criterion is based on the overall sequence number of the data packet across multiple paths. This embodiment relates to the features disclosed in the document EP 3531 637B1 "Techniques for efficient reordering of data packets in multipath scenarios". All the definitions, explanations, devices, and methods disclosed in this document and the advantages cited therein become part of this application and fall within the scope of the disclosure of this application.

[0025] Preferably, the multipath receiver, especially its reordering queue controller, is configured to trigger a retransmission, especially a partial retransmission, of the specific data packet mentioned above after detecting a packet loss of the specific data packet.

[0026] In another preferred alternative for retransmission, the multipath receiver is configured to recover a specific data packet after detecting packet loss of the specific data packet. The recovery of the data packet, especially the lost or presumed lost data packet on the receiver side, avoids retransmission and potentially alleviates the reordering process associated with detecting data packet loss. Shorter latency is expected.

[0027] In a preferred embodiment, the multipath receiver includes an FEC device, which is preferably applied to one or more of the multiple paths. The method is based on introducing redundancy into the user data to detect errors and then reconstructing the data in the case of a limited number of bit or byte errors. In this way, data packets with corrupted data can be recovered to a certain extent, but in the case of an excessive bit error rate, the data packets will be completely lost. However, combined with scrambling, that is, distributing the sequence of the original data stream into multiple packets and then recompiling, the data in the lost data packets can also be recovered. Since this method introduces additional delay and overhead, it is mainly applied to the case of a long retransmission delay (such as a typical case for satellite transmission). FEC can be applied to each path separately. For example, if these paths exhibit different performance characteristics, it will not degrade the performance of the "better path", or it can be applied in an overall FEC manner before splitting and recombining, which will support scrambling and help recover completely lost packets on the "worse path". The unsuccessful application of FEC can achieve rapid detection of irrecoverable errors in the packet, thus triggering a retransmission from the sender before timeout.

[0028] In another preferred embodiment, the reordering queue device is configured to receive data packets transmitted with LNC. In linear network coding (LNC), network nodes (or interfaces of devices) do not simply relay the packets of the information they receive, but combine several packets together for transmission. After receiving the combined and separated packets, the maximum possible information flow in the network can be detected, and throughput, efficiency, scalability, and the ability to recover from attacks and eavesdropping can be improved. Generally, when the number of paths exceeds two, this method will be improved. The disadvantages of LNC are high decoding computational complexity, large transmission overhead, and linear dependence between coefficient vectors during encoding and decoding. Triangular network coding (TNC) solves the problem of high encoding and decoding computational complexity without degrading the throughput performance, and its coding rate is comparable to that of LNC. Therefore, it is beneficial to implement TNC on small devices with limited processing power and power supply (such as mobile phones and wireless sensors).

[0029] Preferably, the reordering criterion is exclusive to a specific ATSSS guiding function and / or an ATSSS-specific guiding mode. This means that when a certain guiding function or mode is selected, no reordering mode and / or functional feature is available, and vice versa. The advantage of this is that if the reordering mode does not bring benefits or is disadvantageous for reordering, the computational overhead will be reduced.

[0030] The scenario where reordering results in computational overhead is when ATSSS is used in the guiding or handover mode (effectively single-path use). If the application can effectively resist out-of-order delivery or has its own optimized reordering logic, it may have a worse effect. Therefore, it is recommended to specify the shutdown of reordering when selecting guiding or handover.

[0031] The method of the present invention can be stored as instruction code on a non-transitory computer-readable medium such that when the code is executed by a computer, the computer executes the method.

Claims

1. A multipath receiver, comprising: a reordering queue configured to queue data packets received on multiple paths, a reordering queue controller configured to reorder the data packets in the reordering queue according to reordering criteria, the reordering queue controller being configured to allow multi-access protocol data unit (MAPDU) sessions based on access traffic steering, handover, and split ATSSS, wherein, the reordering queue controller is configured to select to activate the reordering of the data packets, wherein, the reordering queue controller is configured to negotiate with the peer of the MAPDU session based on the ATSSS use case to activate the reordering of the data packets, and in the case where the reordering is activated, the data packets are queued in the reordering queue, wherein the reordering criteria are based on the sequence numbers of the data packets of the MAPDU session based on the ATSSS use case.

2. The multipath receiver according to claim 1, wherein, the reordering queue controller is configured to detect packet loss of the data packets based on a comparison of at least two sequence numbers of the received data packets, and in the case where packet loss is detected, the reordering queue controller is configured to select a reordering mode for the received data packets, whereby each reordering mode is based on a non-strict application of data sorting.

3. The multipath receiver according to claim 1, wherein, the reordering queue controller is configured to detect packet loss of the data packets based on a comparison of at least two sequence numbers of the received data packets, and in the case where packet loss is detected, the reordering queue controller is configured to negotiate with the peer of the MAPDU session based on the ATSSS use case for a reordering mode for the received data packets.

4. The multipath receiver according to claim 2, wherein, the reordering mode is based on the ATSSS steering function and / or the ATSSS steering mode.

5. The multipath receiver according to any one of claims 1 to 4, wherein, the reordering criteria include a static expiration timer for packet loss detection or a dynamic expiration timer for packet loss detection, wherein the static expiration time or the dynamic expiration time is based on path-specific characteristics of the multiple paths.

6. The multipath receiver according to claim 5, wherein, the path-specific characteristics include latency.

7. The multipath receiver according to any one of claims 1 to 4, wherein, the sequence number of the data packet is a path-specific number, and the reordering criteria are based on the path-specific number of the data packet, and / or the sequence number of the data packet is an overall sequence number across the multiple paths, and the reordering criteria are based on the overall sequence number of the data packet across the multiple paths.

8. The multipath receiver according to claim 1, wherein, the multipath receiver is configured to trigger retransmission of the specific data packet after detecting packet loss of the specific data packet.

9. The multipath receiver according to claim 1, Wherein, the multipath receiver is configured to recover a specific data packet after detecting a packet loss of the specific data packet, and / or the multipath receiver includes a FEC device that is applied to one or more of the multiple paths.

10. The multipath receiver according to claim 1, wherein the reordering queue is configured to receive data packets transmitted using LNC "linear line coding".

11. The multipath receiver according to claim 1, wherein the reordering criterion is exclusive for a specific ATSSS pilot function and / or an ATSSS-specific pilot mode.

12. A method for a multipath receiver to process data packets received by the multipath receiver, the method comprising: receiving, on multiple paths, data packets of a multi-access protocol data unit MAPDU session based on access traffic steering, handover, and split ATSSS, wherein a reordering queue controller of the multipath receiver selects to activate reordering of the received data packets, and wherein, in a case where reordering is activated, the data packets are queued in the reordering queue and the data packets are reordered in the reordering queue according to a reordering criterion based on an ATSSS use case, wherein the reordering criterion is based on the sequence numbers of the data packets, and wherein, the reordering queue controller further negotiates with a peer of the MAPDU session based on the ATSSS use case to activate reordering of the data packets.

13. The method according to claim 12, wherein, the reordering queue controller detects a loss of the data packet based on a comparison of at least two sequence numbers of the received data packets, and in a case where a packet loss is detected, the reordering queue controller selects a reordering mode for the received data packets, whereby each reordering mode is based on a non-strict application of data sorting.

14. The method according to claim 12, wherein, the reordering queue controller detects a loss of the data packet based on a comparison of at least two sequence numbers of the received data packets, and in a case where a packet loss is detected, the reordering queue controller negotiates with a peer of the MAPDU session based on the ATSSS use case for the reordering mode of the data packets, whereby each reordering mode is based on a non-strict application of data sorting.

15. The method according to claim 14, wherein, the negotiation occurs during the establishment of the MAPDU session.

16. A non-transitory computer-readable medium storing computer instructions that, when executed by a computer, cause the computer to execute the method according to any one of claims 12 to 15.

Images