KR102352514B1 - Method and appratus for data transmission of multipath transport system - Google Patents

Abstract

A method for controlling multi-path transmission provided by an embodiment of the present disclosure includes: obtaining information on a data loss rate of data being communicated; determining whether the data loss rate is equal to or greater than a first reference value; and if the data loss rate is equal to or greater than the first reference value, determining the number of subflows of the MPTCP based on the data loss rate.
In addition, a data transmission method in a multi-path transmission system provided by an embodiment of the present disclosure includes the steps of determining whether a single subflow is used for a reference time; determining the number of data segments to which common data mapping information is to be applied based on link characteristic information of the subflow when a single subflow is used during the reference time; transmitting a multi-path header including the common data mapping information in a first data segment among the determined number of data segments; and transmitting the remaining data segments among the data segments without a multi-path header.

Description

Method and apparatus for data transmission in a multi-path transmission system

The present disclosure relates to a method and apparatus for controlling multipath in a multipath transmission system.

The present disclosure also relates to a method and apparatus for transmitting data in a multi-path transmission system.

As it is becoming more common for mobile devices using wireless networks to have various communication interfaces such as WiFi and LTE (Long-Term Evolution), multiple network paths are simultaneously used in one mobile device to increase transmission efficiency. The Multipath Transport Control Protocol (MPTCP) is being studied. MPTCP enables data transmission using multiple communication interfaces with different Internet Protocol (IP) addresses simultaneously.

MPTCP is a technology for using a plurality of network interfaces by extending the existing TCP protocol. While TCP basically consists of one communication path between a transmitting device and a receiving device, MPTCP has a difference in that a plurality of communication paths between the transmitting device and the receiving device are configured.

MPTCP can improve communication performance and fault tolerance by transmitting data in parallel (simultaneously) along multiple paths between a transmitting device and a receiving device at both ends. It also collects and manages available communication resources along a plurality of paths, each configured to support a single TCP connection.

Multipath supported by MPTCP means a plurality of connected connections, also called sub-flows. Individual subflows in MPTCP are similar to a single conventional TCP connection, but typically only transmit a subset of data.

Like a single TCP connection, MPTCP can access a session consisting of multiple subflows or related data segments regardless of application.

MPTCP solves many of the problems of a traditional single TCP connection by exchanging data over multiple interfaces using both end-to-end subflows in parallel. That is, MPTCP has superior performance in terms of throughput, has resilience against data loss and disconnection, and enables simultaneous data exchange through a plurality of subflows.

In addition, in MPTCP, in order to establish subflows on different interfaces as well as data exchange through each of the subflows, their own headers (MPTCP headers) are added as part of the TCP option.

The present disclosure provides a method and apparatus for adaptively setting the number of subflows constituting each path in a multi-path transmission system.

The present disclosure provides a method and apparatus for determining the number of subflows based on a data loss rate in a multipath transmission system.

The present disclosure provides a method and apparatus for obtaining a data loss rate in a multi-path transmission system.

The present disclosure provides a method and apparatus for determining the number of subflows in consideration of the amount of data to be processed in a multi-path transmission system.

The present disclosure provides a method and apparatus for obtaining an amount of data to be processed in a multi-path transmission system.

The present disclosure provides a method and apparatus for optimizing the amount of multipath headers when one subflow is continuously used for data exchange over a single interface.

The present disclosure provides a method and apparatus for preventing overhead by suppressing the number of multi-path headers generated during data exchange.

The present disclosure provides a method and apparatus capable of not only improving responsiveness to addition of a new interface but also balancing various link characteristics, such as data loss rate, transmission time, transmission time variation, and the like.

A method for controlling multi-path transmission provided by an embodiment of the present disclosure includes: obtaining information on a data loss rate of data being communicated; determining whether the data loss rate is equal to or greater than a first reference value; and if the data loss rate is equal to or greater than the first reference value, determining the number of subflows of the multipath based on the data loss rate.

An apparatus for controlling multi-path transmission provided by an embodiment of the present disclosure includes: a data loss rate monitoring unit for obtaining information on a data loss rate of data being communicated; and a subflow management unit to determine whether the data loss rate is equal to or greater than a first reference value, and to determine the number of subflows of the multipath based on the data loss rate if the data loss rate is equal to or greater than the first reference value .

A data transmission method in a multi-path transmission system provided by an embodiment of the present disclosure includes the steps of determining whether a single subflow is used for a reference time; determining the number of data segments to which common data mapping information is to be applied based on link characteristic information of the subflow when a single subflow is used during the reference time; transmitting a multi-path header including the common data mapping information in a first data segment among the determined number of data segments; and transmitting the remaining data segments among the data segments without a multi-path header.

A data transmission method in a multi-path transmission system provided by an embodiment of the present disclosure includes the steps of determining whether a single subflow is used in a multi-path mode for a reference time; determining to switch to a single-path mode when a single subflow is used during the reference time; generating and transmitting a multi-path header including data mapping information for the subflow when it is determined to switch to the single-path mode; switching from the multi-path mode to the single-path mode; and transmitting data segments using the data mapping information in the single path mode.

A data transmission apparatus in a multi-path transmission system provided by an embodiment of the present disclosure determines whether a single subflow is used during a reference time, and when a single subflow is used during the reference time, link characteristics of the subflow a control unit that determines the number of data segments to which common data mapping information is to be applied based on the information; and transmitting the multi-path header including the common data mapping information in a first data segment among the determined number of data segments under the control of the controller, and transmitting the remaining data segments among the data segments without a multi-path header It includes a transceiver.

A data transmission apparatus in a multipath transmission system provided by an embodiment of the present disclosure determines whether a single subflow is used in a multipath mode for a reference time, and when a single subflow is used for the reference time, a single path Determining switching to the single-path mode, generating and transmitting a multi-path header including data mapping information for the subflow when switching to the single-path mode is determined, and switching from the multi-path mode to the single-path mode control unit; and a transceiver for transmitting data segments including a multipath header in the multipath mode under the control of the controller and transmitting data segments using the data mapping information without a multipath header in the single path mode.

1 is a diagram for explaining MPTCP.
2 is a view for explaining an example in which an MPTCP proxy supports MPTCP between a server and a client;
3 is a view for explaining a method of adjusting the number of subflows of MPTCP according to an embodiment of the present disclosure;
4 is a diagram illustrating data transmission of MPTCP.
5 is a diagram for explaining the configuration of an MPTCP header;
6 is a diagram for explaining an overhead due to an MPTCP header;
7A and 7B are diagrams for explaining a data transmission method in an MPTCP system according to an embodiment of the present disclosure;
Fig. 8 is a flowchart for explaining the data transmission method of Fig. 7B;
9A and 9B are diagrams for explaining a data transmission method in an MPTCP system according to an embodiment of the present disclosure;
10A and 10B are flowcharts for explaining the data transmission method of FIG. 9B;
11 is a view for explaining the configuration of an apparatus according to embodiments of the present disclosure;

In the following description of the present disclosure, if it is determined that a detailed description of a related well-known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted. Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

Although the embodiments of the present disclosure described below are separated for convenience of description, at least two or more embodiments may be combined and performed within a range that does not conflict with each other.

Terms to be described below are terms defined in consideration of functions in embodiments of the present disclosure, which may vary according to intentions or customs of users and operators. Therefore, the definition should be made based on the content throughout this specification.

The embodiment of the present disclosure may have various changes and may have various embodiments, and specific embodiments will be described in detail by exemplifying the drawings. However, this is not intended to limit the present disclosure to specific embodiments, and it should be understood to include all modifications, equivalents and substitutes included in the spirit and scope of the present disclosure.

Also, terms including an ordinal number such as 1st, 2nd, etc. may be used to describe various components, but the components are not limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

In addition, the terms used herein are used only to describe specific embodiments, and are not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present specification, terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It should be understood that this does not preclude the existence or addition of numbers, steps, operations, components, parts, or combinations thereof.

The apparatus and method proposed in the present disclosure include a Long-Term Evolution (LTE) mobile communication system, a Long-Term Evolution-Advanced (LTE-A) mobile communication system, and a high-speed downlink Packet access (high speed downlink packet access: HSDPA) mobile communication system, high speed uplink packet access (HSUPA) mobile communication system, 3rd generation project partnership 2 (3rd generation project partnership 2: 3GPP2) High rate packet data (HRPD) mobile communication system, 3GPP2 Wideband Code Division Multiple Access (WCDMA) mobile communication system, and 3GPP2 Code Division Multiple Access (Code Division Multiple Access: CDMA) Mobile Communication System, Institute of Electrical and Electronics Engineers (IEEE) 802.16m Communication System, Evolved Packet System (EPS), and Mobile Internet Protocol (Mobile Internet Protocol: Mobile) It is applicable to various communication systems, such as an IP) system.

Hereinafter, embodiments of the present disclosure will be described assuming a communication system supporting a multipath transport control protocol (MPTCP). These are only for explaining, not limiting, embodiments of the present disclosure, and the present disclosure is applicable to any communication system that exchanges data using a multi-path, that is, a multi-path transmission system.

MPTCP, data transmission of MPTCP, MPTCP header, and overhead generation will be described with reference to FIGS. 1 to 6 .

1 is a diagram for explaining MPTCP.

(a) shows a hierarchical structure including the TCP protocol in one network interface, and there is one TCP layer 103 and one IP layer 105 under the application layer 101 .

(b) shows a hierarchical structure including the MPTCP protocol in one network interface. There is one MPTCP layer 113 under the application layer 111, and a plurality of TCP subflows 114, 115, 116 in MPTCP. ) is included, and it can be seen that each IP layer 117 , 118 , 119 is below each of the TCP subflows 114 , 115 , 116 . The TCP subflows 114, 115, 116 are connected to different network interfaces. For example, TCP subflow 114 is for communicating with a client over an LTE network, TCP subflow 115 is for communicating with a client over a Wi-Fi network, and TCP subflow 116 is for communicating with a client over a WiMax network. it may be for

On the other hand, in order for MPTCP to operate normally, both the server and the client must support MPTCP. To solve this compatibility problem, an MPTCP proxy (hereinafter referred to as "proxy") was introduced, so that the proxy uses the multi-path of MPTCP between the server and the client. to support it.

2 is a diagram for explaining an example in which a proxy supports MPTCP between a server and a client.

Reference number 241 shows a traffic flow when the existing TCP protocol is used, and is shown for comparison with MPTCP.

Reference numerals 251 and 253 show examples of configuring two network interfaces using the MPTCP protocol. That is, the proxy 220 configures two network interfaces with the client 210 . For example, the network interface 251 between A-B may be a network interface for LTE, and the network interface 252 between A'-B may be a network interface for Wi-Fi. On the other hand, reference number 255 shows a network interface between the proxy 223 and the server 230. Since the proxy 223 and the server 230 are typically connected through a wired network, a plurality of network interfaces is not configured. it is common not to

In MPTCP, subflow management that configures one TCP flow into a plurality of TCP subflows is supported in order to configure a plurality of network interfaces. The configuration of one TCP flow into a plurality of TCP subflows has been previously described with reference to FIG. 1 .

Meanwhile, the total number of user devices that the proxy can support increases as the number of TCP flows for each user decreases. Therefore, the smaller the number of TCP flows for each user, the better in terms of proxy overhead or cost. However, in the existing MPTCP, the number of subflows is set to a fixed value. That is, when the number of subflows is set for the proxy, all users must use the same number of subflows.

If the number of subflows is used as a fixed value in this way, the following problems may occur.

For example, if the number of subflows is set excessively, the throughput may be higher than when the number of subflows is 1, but unnecessary overhead occurs in the proxy, and additional proxies may need to be configured. In this case, the cost for system configuration increases. On the other hand, if the number of subflows is set excessively small, the overhead of the proxy may be lowered, but the throughput will also be lowered.

The present disclosure provides a method and apparatus for adaptively setting the number of MPTCP subflows in a communication system supporting MPTCP.

Prior to the detailed description of the embodiments of the present disclosure, basic concepts of the present disclosure will be briefly described.

In the present disclosure, the proxy adaptively adjusts the number of MPTCP subflows for one network interface in consideration of the data loss rate for one network interface and the amount of data to be processed. If the data loss rate is equal to or greater than a predetermined value and the amount of data to be processed is equal to or greater than the reference value, the throughput may be increased by increasing the number of subflows. Conversely, in consideration of the data loss rate and the amount of data to be processed, the number of subflows may be reduced or maintained at an initial setting value.

When the proxy sends data to the client, the proxy can obtain a data loss rate based on the TCP ACK information sent by the client, and the amount of data to be processed depends on the amount of data stored in the Tx Queue in the MPTCP. The amount or information can be obtained based on the amount of unacknowledged data in TCP. When a proxy receives data from a client, in a similar manner, the proxy can adjust the number of subflows for its network interface by obtaining the rate of data loss and the amount of data to process.

3 is a diagram illustrating a method of adjusting the number of subflows of MPTCP according to an embodiment of the present disclosure.

The proxy determines whether the data loss rate is greater than or equal to a reference value (x) ( 301 ). If the data loss rate is greater than or equal to a predetermined value (x), it is determined whether the amount of data to be processed is greater than or equal to a reference value (y) ( 303 ). If the data loss rate is less than the predetermined value (x), the number of subflows is not adjusted and maintained at an initially set value ( 307 ). If the amount of data to be processed is greater than or equal to the reference value (y), the number of subflows is adjusted or determined based on the data loss rate (305), and if the amount of data to be processed is less than the reference value (y), the number of subflows is maintained at the initial set value without adjusting or determining (307).

As described above, the information on the data loss rate can be obtained based on the TCP ACK information transmitted by the client, and the amount of data to be processed is the amount of data stored in the transmission queue (Tx Que) in the MPTCP or TCP ACK. It can be obtained by the amount of data that is not available. However, the method of obtaining information on the data loss rate and information on the amount of data to be processed is not limited to the above-described method.

Meanwhile, step 303 may be performed before step 301 . That is, it is determined whether the amount of data to be processed is equal to or greater than the reference value (y), and when the amount of data to be processed is equal to or greater than the reference value (y), it is determined whether the data loss rate is equal to or greater than the reference value (x), and the data loss rate is the reference value (x). If it is greater than or equal to the value (x), the number of subflows may be adjusted by proceeding to step 305 . Also, step 303 is not necessarily performed. That is, since the data loss rate is greater than or equal to the reference value (x) in step 301, the number of subflows may be determined based on the data loss rate without performing step 303.

A method of adjusting the number of subflows in step 305 may be determined by a predetermined function determined in advance based on a data loss rate. For example, if the data loss rate is 0.1% to 0.5%, set the number of subflows to 4, if the data loss rate is 0.5 to 1.0%, set the number of subflows to 8, and if it is 1.0% or more, the number of subflows can be set to 10.

Meanwhile, in the present disclosure, a time point or an adjustment period for adjusting the number of subflows is not particularly limited. However, in some cases, the number of subflows may be adjusted according to a predetermined period, or the number of subflows may be adjusted when a predetermined event, for example, a specific type of data is transmitted/received.

4 is a diagram illustrating data transmission of MPTCP.

As shown, in MPTCP, subflow management of configuring one TCP flow into a plurality of TCP subflows is supported in order to configure a plurality of interfaces.

The configuration of one TCP flow into a plurality of subflows has been previously described with reference to FIG. 1 .

Meanwhile, in MPTCP, the MPTCP header is newly added as a part of TCP options.

In MPTCP, data packets have an MPTCP header called a Data Sequence Signal (DSS).

The MPTCP header is for segmentation and reassembly of data transmitted through different subflows, usually has a maximum length of 28 bytes, and is transmitted as a TCP option field. The use of the MPTCP header adds about 1.8% overhead for 1500 maximum transmission unit (MTU) paths.

5 is a diagram for explaining the configuration of an MPTCP header.

Referring to FIG. 5 , the MPTCP header includes a subflow sequence number field 1510 , a data sequence number field 1520 , a data level length field 1540 , and a data ACK field 1530 .

The MPTCP header holds the following two levels of sequence numbers in order to perform division and reassembly of data transmitted through different subflows.

The first is the subflow sequence number (SSN) of the subflow level (single TCP level) in the TCP layer.

Each subflow is assigned a unique subflow sequence number. The sequence numbers of a subflow work the same as the TCP sequence numbers allocated to sequentially transmit data allocated to that subflow in a single existing TCP connection.

The second is the data sequence number (DSN) of the data level (MPTCP connection level) in the MPTCP layer. According to the data sequence number, data from each of the subflows may be combined and sequentially transmitted to an application (eg, an application of a receiving device).

Data ACK is also a data level field belonging to the MPTCP layer.

The MPTCP header configured as described above collects traffic (ie, data segments) received through different subflows and maps the subflow sequence number to the data sequence number in order to assemble it into one data (data stream). Signal Mapping, hereinafter DSS mapping) is used.

DSS mapping can be defined as an operation of performing mapping between each subflow sequence number and data sequence number using the MPTCP header.

The MPTCP header is DSS mapping information and may include at least one of a subflow sequence number, a data sequence number, and a data level length.

The data level length is a value designating the length (ie, size) of data to which DSS mapping is to be applied, and is also referred to as a DSS mapping length. If only one interface is used and the data level length is set to a sufficiently large pre-allocated value, DSS mapping is possible by repeatedly using the previously received MPTCP header without receiving a new MPTCP header for a certain period.

If the DSS mapping length is given sufficiently long, the number of DSS mappings decreases and the number of MPTCP headers transmitted decreases, thereby reducing overhead due to header capacity.

However, if the DSS mapping length is too long, it may result in data wastage when a new interface appears. This is because many MPTCP headers must be transmitted for DSS mapping of the previous interface. DSS mapping information once transmitted (shared) in one subflow cannot be canceled. If the number of DSS mappings is too small, the data segments may be delivered within the subflow level (no mapping exists), but there may not be enough DSS mapping information to transmit them at the MPTCP connection level, which actually delivers them to applications. have. As a result, data segments remain at the subflow level. A data segment is a data transmission unit divided from one data (data stream), and may be the same as a data packet, a subset of a data packet, or a plurality of data packets.

On the other hand, if the length of the DSS mapping is too short, the number of DSS mappings increases, and the overhead increases because more MPTCP headers must be transmitted for the DSS mapping. Too frequent DSS mapping causes throughput degradation due to the overhead of header space.

6 is a diagram for explaining an overhead due to an MPTCP header.

MPTCP adds various values including the MPTCP header when multiple interfaces are available, and when one TCP connection needs to be split across multiple interfaces in relation to resilience, throughput, and the like.

Even when using one interface, MPTCP adds an MPTCP header for establishing DSS mapping during data exchange.

FIG. 6 shows a comparison of 10Mbps traffic on a single interface of 1 gigabit having 4 subflows in the case of MPTCP and 10Mbps traffic on the same single interface in the case of a single TCP.

The necessity of MPTCP can be seen by comparing the case where the loss rate is large (Loss=5%) and the case where the loss rate is small (Loss=0%). That is, when the data loss rate increases on one link (subflow), MPTCP can utilize the other link (subflow) to lower the loss rate, thereby maintaining data throughput.

However, it can be seen that MPTCP degradation compared to single TCP appears during the period up to the loss rate of 0 to 2%.

One of the main causes of such MPTCP performance degradation is the MPTCP header capacity required for DSS mapping accompanying the use of various subflows.

That is, when only one interface is available for a long duration, unnecessary overhead is caused due to the addition of MPTCP headers during data exchange. For example, in a 1500 MTU path, when an MPTCP header of 28 bytes, which is the maximum size, is added to data segments during data exchange, an overhead of about 1.8% is added, resulting in reduced efficiency.

An MPTCP connection supports multiple interfaces, but may only have a single interface. For example, in MPTCP in which both a network interface for LTE and a network interface for Wi-Fi can be used, there may be a case where only a network interface for LTE appears and there is no network interface for Wi-Fi.

In this case, there is no need to reassemble data in consideration of various subflows of various interfaces until traffic of a new interface occurs.

On the other hand, due to the characteristics of MPTCP in which a new interface can appear at any time, even when only one interface is continuously used, a quick response to the appearance (addition) of a new interface is required.

In the present disclosure, the main purpose of header optimization for efficient data exchange in MPTCP is to achieve a balance between overhead and responsiveness in a single interface, and for this, the following embodiments are proposed.

Hereinafter, embodiments of the present disclosure will be described with reference to FIGS. 7A to 11 .

A subject performing the embodiments of the present disclosure is mainly described as a transmitting device for convenience of description, but the present disclosure is not limited thereto, and a server or client capable of exchanging multi-path data according to an embodiment, a transmitting device or a receiving device, and a server It can be implemented in various forms, such as a proxy device that mediates a communication connection between a client and a client, or a selective combination or some combination thereof.

In MPTCP, an MPTCP header for DSS mapping will be included for every data segment, as long as the reassembly of data segmented across various subflows is covered by a known DSS mapping (that is, shared between the sending device and the receiving device). no need.

Accordingly, when the DSS mapping is known in advance (eg, when DSS mapping information for a sufficient data range has already been received by the receiving device), overhead can be reduced by utilizing this point. One such case is when there is only a single interface between the transmitting device and the receiving device, and the other is when segments of data are scheduled to be larger than packet size chunks.

An embodiment of the present disclosure performs DSS mapping suppression to reduce the number of MPTCP headers transmitted together with data segments to prevent overhead, but based on the link characteristics of subflows constituting the interface (currently in use) do this

Applicable link characteristic information includes loss rate (p), link stability, link robustness, round trip time (RTT), transmission time variance (RTT variance), transmittable data amount, and current congestion window (cwnd). ), a reception window (rcv_win), a link usage history, and at least one of a maximum segment size (MSS).

In embodiments of the present disclosure, after an initial MPTCP connection is set-up and a predetermined threshold time, MPTCP connections as many as the number of subflows constituting each interface are checked.

If the number of subflows exceeds one, DSS mapping suppression is not performed at all, and only link characteristics for each of the subflows are measured for monitoring.

When only one subflow is used for more than a certain duration (from the beginning or in the case of continuous from several subflows to one subflow), partial or complete suppression for DSS mapping is performed. Partial inhibition and complete inhibition of DSS mapping are described in more detail below.

The degree of suppression performed for each interface is determined by the link characteristics of the subflows constituting the interface, for example, the loss rate of the subflow currently in use, link stability, link robustness, transmission time, transmission time fluctuation amount, transmittable data amount, current It may be determined based on at least one of a congestion window (cwnd), a reception window (rcv_win), a link usage history, and a maximum segment size.

7A and 7B are diagrams for explaining a data transmission method in an MPTCP system according to an embodiment of the present disclosure.

This embodiment is a method of periodically suppressing the number of MPTCP headers for DSS mapping, hereinafter referred to as "partial suppression".

When the transmitting device recognizes that it is in a single subflow state only for a certain period of time, loss rate, link stability, link robustness, transmission time, transmission time variation (deviation), transmittable data amount, current congestion window and reception window, and link usage history And by covering a data range longer than the corresponding time based on link characteristics such as the maximum segment size, the number of DSS mappings is suppressed.

This method is applicable when only a single interface is configured, when a backup interface other than a single interface exists, or when a single interface with low enough traffic for the backup interface is active, etc.

Fig. 7a shows data transmission in a steady state without partial suppression, and is shown for comparison with the partial suppression shown in Fig. 7b.

In the normal state without partial suppression as shown in FIG. 7A, when M segments of 1500 bytes are transmitted for a certain period (hereinafter, assumed to be RTT), an MPTCP header is tagged for each segment. In addition, the data sequence number (DSN) for DSS mapping in the MPTCP headers added to each segment is sequentially updated.

When only one interface is used for a certain period (hereinafter referred to as RTT), a partial suppression operation may be performed as shown in FIG. 7B ( S1720 ).

In the partial suppression state, when M segments of 1500 bytes are transmitted during a certain period (RTT), only one segment among N segments transmitted per unit period (hereinafter, assumed to be RTT*(N/M)) , for example, only the first segment is tagged with the MPTCP header (S1725). During one unit period (RTT*(N/M)), the MPTCP header is not tagged in the remaining segments among the N segments ( S1730 ). Here, N is the number of segments transmitted during a unit period (RTT*(N/M)).

In each period (RTT), the transmitting apparatus calculates the optimal number N of segments to be tagged with only one MPTCP based on the link characteristics of subflows constituting the current interface. By the optimal number N, the interval of segments to contain the MPTCP header is selected. The MPTCP header includes common data mapping information to be applied to the calculated number of data segments.

In addition, the transmitter generates an MPTCP header defining DSS mapping for N segments of a selected interval in each period (RTT). For N<1, only one segment tagged with the MPTCP header is transmitted for each period over multiple periods (RTT).

In this way, if the backup interface is additionally used while data is being transferred through the current interface while partial suppression is performed, the redundant data scheduler operates in response to the current interface and the already shared data for both subflows of the backup interface. An MPTCP header including DSS mapping information is transmitted. In this case, the partial suppression function of DSS mapping is disabled for a certain period of time. Even when a subflow is added by setting a new interface, the partial suppression function is disabled and becomes available again when a single subflow state occurs for a certain reference time.

In partial suppression, the optimal number N of segments in each period RTT may be determined according to at least one of the following.

- Loss rate on link: the higher the loss rate, the less suppression of DSS mappings. That is, since the number of DSS mappings should increase as the loss rate increases, the optimal number N using common mapping information decreases, and as the loss rate decreases, the number of DSS mappings decreases and the optimal number N using common mapping information increases. The number of DSS mappings is directly proportional to the square root of the loss factor P.

- Link Stability: Duration of a single subflow. The longer the duration in a single subflow state (no new subflows are added and one subflow continues), the fewer segments to send through the subflow in a unit period (RTT*(M/N), and therefore fewer A number of DSS mappings are required, that is, as the link stability value increases, the number of DSS mappings decreases and the optimal number N that uses common mapping information increases, and as the link stability value decreases, the number of DSS mappings increases and provides common mapping information. The optimal number N to be used decreases.

- RTT variance: When the amount of RTT variance is high, loss/rearrangement information of data segments is delayed and throughput may decrease. Therefore, the suppression degree of DSS mappings becomes smaller.

- Link robustness (based on the robustness of the current subflow, for example, signal strength in the case of a wireless subflow) or new interface establishment: These information are obtained by periodically monitoring the cross layer information of the lowest IP layer, the IP layer. can

- Amount of data that can be transmitted

- Current Congestion Window and Receive Window

In addition, the optimal number N of segments to which common mapping information included in one MPTCP header is applied may be determined as a value within the limit of segments satisfying 0 < N <= cwnd (congestion window).

For each unit period (RTT/(M/N)), the MPTCP header for DSS mapping is tagged only for one segment, for example, the first segment, and the remaining segments are transmitted without the MPTCP header.

As an example, the optimal number N of segments to which common mapping information is to be applied may be calculated by Equation (1).

[Equation 1]

N = (1/α)* min(min(congestion window, receive window), amount of data that can be sent to the application)

Here, α is a factor dependent on data loss rate, single link stability, and cross-layer information. The larger α, the fewer segments are tagged with the MPTCP header for DSS mapping, and vice versa.

When α=1, the partial suppression function is not applied and the MPTCP header is tagged for every segment.

The cross-layer information is information of the IP layer, which is the lowest layer, which notifies the appearance (when a new interface appears or is about to appear), and this cross-layer information can be actively used to increase or decrease α.

α increases when a new interface is established (a new interface appears or is about to appear), or when the data loss rate is high or the backup interface has been recently used. This is because the possibility that the subflow of the new interface will be added increases, the data loss rate increases due to the lack of DSS mapping information, or the backup interface is additionally used in addition to the current interface to derive redundant data. Accordingly, in this case, there is a need to more frequently transmit the MPTCP header for DSS mapping by reducing the value of N with an increase in α.

FIG. 8 is a diagram for explaining the data transmission method of FIG. 7B in more detail.

In each period (hereinafter, assumed to be RTT), the transmitting apparatus monitors whether subflows are used and link characteristic information of the subflows to obtain the corresponding information (S1810). Whether subflows are used and link characteristic information may be obtained from cross-layer information.

Then, it is determined whether only one subflow is being used for a reference time based on whether the subflows obtained in step S1810 are used (S1820).

As a result of the determination in step S1820, if only one subflow is used during the reference time, the MPTCP header is selectively added to a predetermined number of data segments based on the link characteristic information of the corresponding subflow obtained in step S1810. Header optimization to include is performed (S1850 to S1880).

In this case, it may be first determined whether the MPTCP header optimization for selectively including the MPTCP header is possible based on the link characteristic information of the used subflow ( S1840 ). If it is determined that MPTCP header optimization is possible based on the link characteristic information of this subflow, a header optimization (partial suppression) operation described later is performed.

The header optimization of the partial suppression method may be subdivided into steps S1850 to S1880.

In step S1850, the transmitting device calculates the optimal number N of segments to be tagged with one MPTCP header based on the link characteristic information of the subflow being used.

Then, an MPTCP header including common DSS mapping information (eg, at least one of a data sequence number, a subflow sequence number, and a data level length) required for reassembling the calculated number of N segments is generated (S1860) .

The MPTCP header generated in step S1860 may be transmitted while being included in one of the N segments, for example, the first transmitted segment (S1870).

A data transmission operation of sequentially transmitting N segments tagged with one MPTCP header is performed every unit period (hereinafter, assumed to be RTT*(M/N)) (S1870, S1880).

Here, one MPTCP header including common DSS mapping information for N segments transmitted during a unit period (RTT*(M/N)) is tagged. For example, only one segment (eg, the first segment) among N segments to be transmitted during the unit period (RTT*(M/N)) is tagged with the MPTCP header, and the remaining segments are transmitted without the MPTCP header.

That is, the transmitting device generates DSS mapping information for all segments transmitted on a subflow in use during a unit period (RTT*(M/N)) and transmits it together with one segment, while transmitting it along with one segment. M/N)) in the remaining segments, all MPTCP headers are not tagged, thereby reducing overhead.

When it is determined in step S1820 that a plurality of subflows are used, or when it is determined that header optimization is impossible as a result of determination in step S1840, for each of all segments divided from one data stream without header optimization Data is transmitted by including MPTCP headers (S1830).

In this way, the transmitting apparatus may calculate the optimal number of segments to use common DSS mapping information in each period (RTT), and may suppress the number of MPTCP headers for DSS mapping. At this time, if the DSS mapping interval is too short, the number of MPTCP headers increases and overhead is caused, and if the DSS mapping interval is too long, it shows low responsiveness to the appearance (addition) of a new interface, so there is a balance between overhead versus low responsiveness. should be maintained

In order to maintain a balance between overhead versus low responsiveness, in step S1840 of determining whether header optimization is possible or step S1850 of determining the number of segments N, link characteristic information of a currently used subflow may be used as a reference.

The applicable link characteristic information may include at least one of loss rate, link stability, link robustness, transmission time, transmission time variation, transmittable data amount, current congestion window and reception window, link usage history, and maximum segment size. .

As an example, the link characteristic information may include a loss rate. In this case, as the loss rate increases, the number of segments decreases, and as the loss rate decreases, the number of segments increases.

As another example, the link characteristic information may include link stability. In this case, as the link stability value increases, the number of segments increases, and as the link stability value decreases, the number of segments decreases.

Alternatively, in step S1840, when the data loss rate is higher than the threshold value or link stability is lower than the threshold value, it is determined that header optimization is impossible, considering that data loss or communication failure may occur due to header optimization. can do.

In addition, although not shown, the transmitting device monitors the cross-layer information of the IP layer that notifies the addition or change of a subflow due to the setting of a new interface or activation of the backup interface, and when a new interface is set or the backup interface is activated In this case, by detecting this through cross-layer information, partial suppression for header optimization may not be executed or the partial suppression operation being executed may be terminated.

The receiving device determines whether the MPTCP header is included in the received segment, and if not, interprets the segment using the previously received MPTCP header.

9A and 9B are diagrams for explaining a data transmission method in an MPTCP system according to an embodiment of the present disclosure.

In this embodiment, when a single subflow state in which only one interface is activated lasts longer than a reference time, the mode itself supports one subflow in the MPTCP mode that supports a plurality of subflows until a new interface appears. A method of improving the performance gain by changing to the TCP mode (same as single TCP), hereinafter referred to as "complete suppression".

When the TCP mode is changed, only one interface can be supported, so if a backup interface exists in the MPTCP mode before the change to the TCP mode, this embodiment does not apply.

Complete suppression involves moving a single subflow (no backup subflow) from the MPTCP mode to the TCP mode using an infinite mapping MPTCP header, which will be described later. At this time, configuration information for all MPTCP connections of the subflow used in MPTCP mode can be saved, and when returning from TCP mode to MPTCP mode, based on the saved configuration information, MPTPC connections can be quickly and efficiently restored without degradation of throughput. have.

Since the infinite mapping MPTCP header defines the mapping of data sequence numbers and subflow sequences for a certain period (eg, multiple RTT durations) or more, if the infinite mapping MPTCP header is transmitted in advance before switching to the TCP mode, it is repeatedly applied. data segments can be reassembled by the solution, and no MPTCP header needs to be transmitted in TCP mode

In addition, monitoring for an event notifying the setting of a new interface is performed periodically. As an example, the transmitting device may detect the setting (addition) of a new interface by continuously monitoring the cross-layer information. When a corresponding event occurs, the conversion from the TCP mode to the MPTCP mode may be performed based on pre-stored MPTCP connection setting information.

Fig. 9a shows data transmission in the steady state without full suppression, and is shown for comparison with the partial suppression shown in Fig. 9b.

During a certain period (eg, RTT), when the first interface Iface1 is activated and transmits M segments of 1500 bytes, in a normal state without complete suppression as shown in FIG. 9A, an MPTCP header is tagged for each segment ( S1910). When the second interface Iface2 is set ( S1920 ), the MPTCP header is also tagged and transmitted to each segment of the second interface Iface2 . A data sequence number (DSN) for DSS mapping is sequentially updated in MPTCP headers added to each segment.

When multiple interfaces are activated, the transceiver exchanges data as configured in FIG. 9A for all subflows of the activated interfaces.

If only one interface exists during the reference time, for example, if the activated state of only one interface Iface1 continues for more than the minimum reference time, the subflow currently being used in the interface Iface1 as shown in FIG. 9B . An infinite mapping MPTCP header for ? is first transmitted (S1955) and then switched to the TCP mode (S1960).

Infinite mapping DSS mapping by the MPTCP header is stopped when an interface(s) other than the current interface being used is set (eg, when an event is generated by cross-layer information).

In the TCP mode, data exchange is performed on the current single interface Iface1 without using the MPTCP header for DSS mapping (S1960). Since MPTCP headers including DSS mapping information are not transmitted at all during the data exchange in step S1960, overhead is reduced.

Thereafter, when a new interface, that is, the second interface Iface2 is set, a second subflow is set on the first interface Iface1 using the MP_JOIN function for the first subflow of the first interface Iface1 being used, and (S1970), the first subflow in which the infinite mapping MPTCP header was exchanged is disconnected (S1975). This will bring continuity of data exchange in the first interface Iface1 as well as in the second interface Iface2. And, in order to allow MP_JOIN on the session in which the infinite mapping MPTCP header was previously received, the transceivers of both ends are enhanced (enhanced).

At this time, in order to reduce performance degradation due to slow startup, TCP-related parameters such as the congestion window cwnd of the stopped first subflow and the slow-start threshold value (Slow-Start Threshold, ssthresh) are added to the second subflow. It can be applied (S1970).

Then, using the MP_JOIN function, a third subflow is set on the second interface (Iface2) (S1980), returns to the MPTCP mode, and data is exchanged with DSS mapping information on both interfaces (Iface1, Iface2) ( S1985).

Thereafter, the transmitting device generates an MPTCP header defining current DSS mapping information based on the last successful transmission confirmed data in the first subflow in which the infinite mapping MPTCP header was exchanged. That is, the transmitting device generates new DSS mapping information based on the data for which successful transmission is confirmed, and uses the DSS mapping information to set new subflows on the first and second interfaces Iface1 and Iface2 (that is, data exchange through the second and third subflows) is started (S1985). Thereafter, data segments including DSS mapping information are continuously transmitted sequentially on both interfaces Iface1 and Iface2.

10A and 10B are diagrams for explaining the data transmission method of FIG. 9B in more detail.

In each period (eg, RTT), the transmitting apparatus basically operates in the MPTCP mode supporting a plurality of subflows to perform data exchange.

During data exchange in the MPTCP mode, the transmitting apparatus monitors whether subflows are used and link characteristic information of the subflows to obtain the corresponding information (S2100). As an example, whether subflows are used and link characteristic information may be obtained by periodically checking cross-layer information.

And, it is determined whether only a single subflow is used for a reference time based on the information on whether the subflows are used or not obtained in step S2100 ( S2110 ), and as a result of the determination, only a single subflow is used for the reference time In this case, it is determined to switch to the TCP mode supporting a single subflow (S2120).

In the MPTCP mode, MPTCP headers are included in some or all of the segments divided from one data stream and transmitted. On the other hand, in TCP mode, segments divided from data are transmitted without an MPTCP header (same as a normal TCP connection).

Currently, only one subflow is being used, and when this single subflow state continues for more than a reference time, the transition to the TCP mode for performing data exchange without an MPTCP header is determined.

When it is determined in step S2120 to switch to the TCP mode, the transmitting apparatus may generate and transmit a first MPTCP header for the first subflow currently being used in the interface in advance (S2140). The first MPTCP header includes DSS mapping information for reassembly of data segments to be transmitted through the first subflow currently being used in the TCP mode.

Specifically, the first MPTCP header may be an infinite mapping MPTCP header in which a data level length value among DSS mapping information is allocated to a preset sufficiently large value. If the value of the data level length is sufficiently large, infinite (repeated) mapping between subflow sequence numbers and data sequence numbers is possible only with DSS mapping information previously transmitted for a certain period of time (eg, multiple RTT durations).

Thereafter, the transmitter switches from the MPTCP mode supporting a plurality of subflows to the TCP mode supporting one subflow (S2150), and transmits data in the TCP mode (S2160). In the TCP mode, the transmitting apparatus may continuously perform mapping between subflow sequence numbers and data sequence numbers according to the previously transmitted DSS mapping information.

Meanwhile, the transmitter detects whether a new interface other than the interface of the current subflow is set in the TCP mode (S2200). In this case, the transmitting device continuously monitors the cross-layer information of the IP layer, and when a new interface other than the current subflow interface is set in the TCP mode, it can be detected through the cross-layer information.

When a new interface is set, that is, when a second interface appears or is about to appear, addition or change of a subflow is expected. Therefore, data exchange is performed by returning to the MPTCP mode that can support multiple subflows (S2210). to 2260).

The step of switching from the TCP mode to the MPTCP mode may be subdivided into S2210 to 2260.

As a result of the monitoring in step 2200, when the second interface is set in the TCP mode, the transmitter first sets the second subflow to the first interface currently being used, and then disconnects the first subflow in use ( S2210). At this time, in order to avoid starting performance degradation, link characteristic information of the first subflow to be disconnected, for example, TCP related parameters such as congestion window (cwnd) and slow start threshold (Slow-Start Threshold, ssthresh) are applied. You can set 2 subflows.

Then, a third subflow is newly set on the second interface ( S2220 ).

Then, for continuity of data exchange, the transmitting device generates a second MPTCP header for segmentation and reassembly of current data based on the last successful transmission confirmed data through the first subflow. That is, the second MPTCP header includes new DSS mapping information that is continuous with the point at which data is successfully exchanged on the first subflow that is stopped in use ( S2230 ).

Then, the transmitting device transmits the data segments including the second MPTCP header through both the second subflow of the first interface and the third subflow of the second interface, respectively (S2240). Thereafter, data segments including its own MPTCP header may be continuously transmitted on each subflow.

In addition, when it is determined to switch to the TCP mode in step S2120, the transmitting device may store configuration information for the MPTCP connection (S2130). If the configuration information for the MPTCP connection is maintained (S2130), when returning from the TCP mode to the MPTCP mode, the MPTCP connection (second and third subflows) can be efficiently and quickly restored based on the saved configuration information. There is (S2250, S2260). The transmitting device may store and use the setting information for the MPTCP connection by itself, or may transmit it to the communication-connected receiving device and induce it to be used when changing the mode.

11 is a view for explaining the configuration of an apparatus according to embodiments of the present disclosure.

The device according to the embodiments of the present disclosure may be provided in various forms, such as a server or client supporting MPTCP, a transmitting device or a receiving device, a proxy device mediating a communication connection between a server and a client, or a selective or partial combination thereof. can be implemented.

Referring to FIG. 11 , an apparatus according to embodiments of the present disclosure includes a monitoring unit 2300 , a control unit 2310 , and a transceiver 2320 .

When the device of the present disclosure is a proxy device that adjusts the number of subflows of MPTCP according to the embodiment of FIG. 3 , the monitoring unit 2300 monitors the data loss rate to acquire the data loss rate. As described above, the data loss rate can be obtained based on the TCP ACK information transmitted by the client.

Also, the monitoring unit 2300 monitors the amount of data to be processed by the proxy. As described above, the amount of data to be processed can be obtained from the amount of data stored in the transmission queue (Tx Que) in the MPTCP.

The controller 2310 adjusts the number of subflows of the MPTCP layer as described above in FIG. 3 based on the acquired data loss rate and the amount of data to be processed. That is, if the data loss rate is equal to or greater than the reference value (x) and the amount of data to be processed is equal to or greater than the reference value (y), the controller 2310 determines the number of subflows based on the data loss rate, otherwise, The number of subflows is maintained at an initially set value.

On the other hand, when the device of the present disclosure is a device for transmitting MPTCP data according to the embodiments of FIGS. 7B and 8 (partial suppression), the monitoring unit 2300 determines whether subflows are used and link characteristics of the subflows. monitor information. As described above, information on whether subflows are used and link characteristic information of subflows may be obtained from cross-layer information.

The controller 2310 determines whether only a single subflow is used for a reference time based on whether subflows are used, and when only a single subflow is used for a reference time, based on link characteristic information of the subflow being used determines the number of data segments to which common data mapping information is to be applied.

The transceiver 2320 performs data exchange under the control of the controller 2310 and transmits data segments selectively including an MPTCP header. Specifically, the transceiver 2320 includes a multi-path header including common data mapping information in one of the determined number of data segments, for example, a first data segment and transmits the multi-path header, and transmits the remaining data segments among the data segments. transmit without

In addition, when the device of the present disclosure is a device for transmitting MPTCP data according to the embodiments of FIGS. 9B, 10A, and 10B (complete suppression), the operation of the monitoring unit 2300 is the same as in the above-described embodiment. same.

The controller 2310 determines whether a single subflow is used in the multi-path mode for a reference time based on the monitoring result, and when the single subflow is used for the reference time, determines to switch to the single-path mode. When it is determined to switch to the single-path mode, the controller 2310 generates and transmits a multi-path header including data mapping information for a subflow in use, and switches from the multi-path mode to the single-path mode.

The transceiver 2320 performs data exchange under the control of the controller 2310, but transmits data segments including the multi-path header in the multi-path mode, and uses data mapping information without the multi-path header in the single-path mode. send them

Certain aspects of the present disclosure described above may also be implemented as computer readable code in a computer readable recording medium. A computer readable recording medium is any data storage device capable of storing data that can be read by a computer system. Examples of the computer readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, and , floppy disks, optical data storage devices, and carrier waves (such as data transmission over the Internet). The computer readable recording medium may also be distributed through network-connected computer systems, so that the computer readable code is stored and executed in a distributed manner. In addition, functional programs, code, and code segments for accomplishing the present disclosure may be easily interpreted by programmers skilled in the art to which the present disclosure is applied.

In addition, it will be appreciated that the apparatus and method according to an embodiment of the present disclosure may be realized in the form of hardware, software, or a combination of hardware and software. Any such software, for example, whether erasable or rewritable, may be stored in a volatile or non-volatile storage device such as a ROM, or a memory such as, for example, RAM, a memory chip, device or integrated circuit. , or an optically or magnetically recordable storage medium such as a CD, DVD, magnetic disk, or magnetic tape, and at the same time may be stored in a machine (eg, computer) readable storage medium. The method according to an embodiment of the present disclosure may be implemented by a computer or portable terminal including a control unit and a memory, wherein the memory is suitable for storing a program or programs including instructions for implementing embodiments of the present disclosure You will see that it is an example of a machine-readable storage medium.

Accordingly, the present disclosure includes a program including code for implementing the apparatus or method described in any claim of the present specification, and a machine (computer, etc.) readable storage medium storing such a program. Also, such a program may be transmitted electronically through any medium such as a communication signal transmitted through a wired or wireless connection, and the present disclosure suitably includes the equivalent thereof.

Also, the device according to an embodiment of the present disclosure may receive and store the program from a program providing device connected by wire or wirelessly. The program providing device may include a program including instructions for causing the program processing device to perform a preset content protection method, a memory for storing information necessary for the content protection method, and wired or wireless communication with the graphic processing device. It may include a communication unit for performing, and a control unit for automatically transmitting a corresponding program to the transmission/reception device at the request of the graphic processing device or.

Claims (27)

delete delete delete delete delete delete delete delete delete delete delete delete delete delete A method for transmitting data in a multi-path transmission system, the method comprising:
determining whether a single subflow is used for a reference time;
determining the number of data segments to which common data mapping information is to be applied based on link characteristic information of the subflow when a single subflow is used during the reference time;
transmitting a multi-path header including the common data mapping information in a first data segment among the determined number of data segments; and
and transmitting the remaining data segments among the data segments without a multi-path header.
16. The method of claim 15,
and determining whether to apply the common data mapping information to the data segments based on link characteristic information of the subflow when a single subflow is used during the reference time.
16. The method of claim 15,
wherein the multi-path header is generated according to the determined number of data segments.
16. The method of claim 15,
The link characteristic information is
The method comprising at least one of a loss rate of the subflow, link stability, link robustness, transmission time, transmission time variation, transmittable data amount, current congestion window and reception window, link usage history, and a maximum segment size.
16. The method of claim 15,
The link characteristic information includes a loss rate of the subflow,
The larger the loss rate, the smaller the number, and the smaller the loss rate, the greater the number.
16. The method of claim 15,
The link characteristic information includes link stability of the subflow,
A method in which the number increases as the link stability value increases, and the number decreases as the link stability value decreases.
A method for transmitting data in a multi-path transmission system, the method comprising:
determining whether a single subflow is used in a multipath mode during a reference time;
determining to switch to a single-path mode when a single subflow is used during the reference time;
generating and transmitting a multi-path header including data mapping information for the subflow when it is determined to switch to the single-path mode;
switching from the multi-path mode to the single-path mode; and
and transmitting data segments using the data mapping information in the single path mode.
22. The method of claim 21,
detecting whether a new interface is established in the single path mode; and
The method further comprising the step of returning to the multi-path mode from the single-path mode when the new interface is set.
23. The method of claim 22,
storing configuration information for the multi-path connection when it is determined to switch from the multi-path mode to the single-path mode; and
When returning to the multi-path mode from the single-path mode, the method further comprising the step of restoring the multi-path connection based on the stored configuration information.
23. The method of claim 22,
when a new interface is set in the single-path mode, setting a second subflow on the new interface and disconnecting a first subflow on the current interface used in the single-path mode;
setting a third subflow on the new interface;
generating multi-path headers for the second and third subflows based on a data segment last transmitted through the first subflow; and
and transmitting the data segments including the multi-path header through the second and third subflows.
25. The method of claim 24,
The second subflow is set by applying link characteristic information of the first subflow.
An apparatus for transmitting data in a multi-path transmission system, comprising:
Determining whether a single subflow is used for a reference time, and when a single subflow is used for the reference time, determining the number of data segments to which common data mapping information is applied based on link characteristic information of the subflow control unit; and
Transmission and reception for transmitting a first data segment among the determined number of data segments by including a multi-path header including the common data mapping information under the control of the controller, and transmitting the remaining data segments among the data segments without a multi-path header A device containing wealth.
An apparatus for transmitting data in a multi-path transmission system, comprising:
It is determined whether a single subflow is used in the multi-path mode for a reference time, and when a single subflow is used for the reference time, a switch to the single-path mode is determined, and when the switch to the single-path mode is determined , a control unit that generates and transmits a multi-path header including data mapping information for the subflow and switches from the multi-path mode to the single-path mode; and
and a transceiver for transmitting data segments including a multi-path header in the multi-path mode and transmitting data segments using the data mapping information without a multi-path header in the single-path mode under the control of the controller.

Images