KR20180090467A - Method and system for real-time multimedia transmission using parallel TCP acceleration - Google Patents

Abstract

According to an embodiment of the present invention, a data transmission method comprises the following steps: allowing a transmitter to receive a band width necessary for transmitting data from an application; allowing the transmitter to predict an available band width when a TCP channel for the application is added by using a network environmental value of the existing TCP channel assigned for the application; allowing the transmitter to compare the necessary band width with the available band width, and determining whether the TCP channel is added; allowing the transmitter to dynamically add the TCP channel for the application when the TCP channel is added; and allowing the transmitter to transmit the data with a parallel TCP method through the added TCP channel.

Description

TECHNICAL FIELD The present invention relates to a method and system for real-time multimedia transmission using parallel TCP acceleration,

The present invention relates to a method and system for transmitting real-time multimedia using parallel TCP acceleration. More particularly, the present invention relates to a method for generating a plurality of TCP channels and transmitting real-time multimedia using a plurality of TCP channels, and a system for performing the method.

Transmission Control Protocol (TCP) is a transport layer protocol that supports connection-oriented services. TCP provides reliable data transfer and flow control and congestion control. Therefore, TCP is often used for reliable transmission such as file transfer.

On the other hand, User Datagram Protocol (UDP) is a transport layer protocol supporting connectionless services. UDP does not go through the process of exchanging signals that the server and the client send or receive data when exchanging data. In UDP, there is no handshake process like TCP.

RTP (Real-time Transport Protocol), developed for real-time multimedia transmission, operates mainly on UDP rather than TCP to support real-time performance. It is because of low latency which is a characteristic of UDP, scalability that freely adjusts necessary data traffic, and adaptability that can recover quickly even if a loss occurs in the middle.

However, UDP does not have a concept of a session basically, which may cause security issues and cause difficulty in network management. As a result, corporate network administrators often restrict the use of UDP in policy. Therefore, UDP-based PC video conferencing and live streaming services are often blocked by corporate network firewalls.

For this reason, companies such as WebEx, which is famous for video conferencing solutions, often provide ineffective technology to operate the solution based on TCP rather than UDP. However, when real-time multimedia data is transmitted based on TCP designed to guarantee reliable transmission in the first place, many problems may arise.

For example, there may be a transmission speed limit in a section where a round-trip time (RTT) is large due to a restriction on a TCP buffer between a sender and a receiver. In addition, the transmission bandwidth is slowly increased in TCP due to the Additive Increase (AIMD) or the Slow Start and the TCP specific congestion control algorithm.

Due to the characteristics of the TCP, if a loss occurs during the transmission of real-time multimedia, the transmission rate may drop rapidly, and a time delay may occur until the transmission rate before the loss is recovered. This results in a sudden deterioration in the quality of audio and video in real-time multimedia. That is, the screen may be broken or the audio may be interrupted.

Therefore, it is necessary to transmit real-time multimedia using TCP, which is designed for reliable data transmission. On the other hand, there is a need for a transmission method capable of securing a stable bandwidth and preventing a sudden decrease in transmission speed when a loss occurs.

SUMMARY OF THE INVENTION The present invention provides a method and system for transmitting real-time multimedia using parallel TCP acceleration.

The technical problems of the present invention are not limited to the above-mentioned technical problems, and other technical problems which are not mentioned can be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, there is provided a data transmission method including: receiving a bandwidth required for transmitting data from an application; Predicting an available bandwidth when the transmitting apparatus adds a TCP channel for the application using a network environment value of a TCP channel that has been previously allocated for the application; Comparing the available bandwidth with the available bandwidth and determining whether to add a TCP channel; Dynamically adding a TCP channel for the application when the transmitting device determines to add a TCP channel; And the transmitting apparatus transmitting the data through the added TCP channel in a parallel TCP manner.

In one embodiment, the step of predicting the available bandwidth when adding a TCP channel for the application comprises: measuring in real time a network environment value of a TCP channel allocated for the application; Estimating a network environment value to be changed when a TCP channel is added using the measured network environment value; And estimating the available bandwidth using the predicted network environment value.

In another embodiment, the network environment value includes at least one of RTT, Loss, and Jitter.

In another embodiment, the step of predicting a network environment value to be changed when adding the TCP channel using the measured network environment value may include calculating a network environment value, an operating system of the transmitting apparatus, and a TCP characteristic And using the prediction model learned in advance based on the prediction model.

In yet another embodiment, the step of comparing the available bandwidth with the available bandwidth and determining whether to add a TCP channel may include adding a TCP channel if the number of TCP channels previously allocated for the application is greater than or equal to a threshold It may include a step of not judging.

In another embodiment, the step of dynamically adding a TCP channel for the application includes: generating the TCP channel to be added in advance before the requested step and managing the TCP channel in a pool manner; Transmitting data to the pre-generated TCP channel, securing a bandwidth of the pre-generated TCP channel, and aging the pre-generated TCP channel.

In another embodiment, the transmitting apparatus may further include a step of returning unused TCP channels among TCP channels allocated for the application to a pool of TCP channels.

The effects according to the embodiment of the present invention are as follows.

According to the present invention, it is possible to use an acceleration technique through parallel TCP, which is widely used for reliable file transfer. This ensures sufficient bandwidth for multimedia that wants real-time transmission at a high quality level. Recently, due to the development of internet transmission speed, demand for large multimedia such as FHD and UHD is gradually increasing, and sufficient bandwidth for transmitting such large multimedia can be secured. In addition, when a loss occurs, it is possible to prevent a rapid decrease in transmission rate. Thus, it is possible to provide smooth and high quality video conferencing and live streaming service.

The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood to those of ordinary skill in the art from the following description.

FIG. 1 is an exemplary diagram for explaining bandwidth limitations according to conventional TCP characteristics.
2 is an exemplary diagram illustrating a congestion control algorithm according to conventional TCP characteristics.
3 is a diagram for explaining a case of transmitting real-time multimedia using a conventional TCP transmission.
4 to 5 are diagrams for explaining a real-time multimedia transmission method according to an embodiment of the present invention.
FIG. 6 is a block diagram illustrating a PTCP channel manager according to an embodiment of the present invention. Referring to FIG.
7A and 7B illustrate a process of managing a PTCP channel in a pool manner according to an embodiment of the present invention.
8 is a flowchart of a method of transmitting real-time multimedia using parallel TCP acceleration according to an embodiment of the present invention.
9 to 12 are views illustrating a Channel BW Estimator and a PTCP Channel Manager according to an embodiment of the present invention.
13 to 14 are exemplary diagrams illustrating a channel pool that can be utilized in an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention, and the manner of achieving them, will be apparent from and elucidated with reference to the embodiments described hereinafter in conjunction with the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Is provided to fully convey the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Unless defined otherwise, all terms (including technical and scientific terms) used herein may be used in a sense that is commonly understood by one of ordinary skill in the art to which this invention belongs. Also, commonly used predefined terms are not ideally or excessively interpreted unless explicitly defined otherwise. The terminology used herein is for the purpose of illustrating embodiments and is not intended to be limiting of the present invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification.

It is noted that the terms "comprises" and / or "comprising" used in the specification are intended to be inclusive in a manner similar to the components, steps, operations, and / Or additions.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

FIG. 1 is an exemplary diagram for explaining bandwidth limitations according to conventional TCP characteristics.

Referring to FIG. 1, the upper part of FIG. Referring to the terminology used in the equation of FIG. 1, the MSS refers to a maximum data size that can be sent by one TCP segment to a TCP through a channel in a maximum segment size (MSS). The larger the maximum segment size, the more data can be sent in one transmission, so the TCP bandwidth is proportional to the MSS.

The RTT is a round trip time (RTT), which is the time taken for the packet to travel from the network to the end-to-end. RTT is affected by network congestion, distance between end-to-end, and transmission rate. The larger the RTT, the more time it takes to send the data, so the TCP bandwidth is inversely proportional to the RTT.

And, Packet loss means packet loss. Since TCP guarantees reliable data transmission, it attempts retransmission if a packet is lost. The more packets are lost, the more bandwidth is lost because the data is sent again. So the TCP bandwidth is inversely proportional to the square root of the packet loss.

In summary, as shown in the equation of FIG. 1, the bandwidth of TCP is proportional to MSS, inversely proportional to RTT, and inversely proportional to the square root of Packet Loss. The relationship between the RTT, the packet loss and the bandwidth is shown in a three-dimensional graph as shown in the lower graph of FIG. Referring to the lower graph, the x-axis shows RTT, the y-axis shows Packet Loss, and the z-axis shows Throughput. As can be seen from the graph at the bottom of FIG. 1, the TCP bandwidth has a characteristic that the RTT and the packet loss are drastically lowered.

Referring to FIG. 1, in a situation where the RTT is 200ms and there is a loss of about 1%, a transmission rate of about 0.58 Mbit / sec can be secured for one TCP channel. In this transmission speed, it is not possible to make a smooth video conference because it is not enough to send video to the other party in real time through the video conference server.

2 is an exemplary diagram illustrating a congestion control algorithm according to conventional TCP characteristics.

TCP uses a congestion control algorithm such as AIMD (Multiplicative Decrease) or Slow Start (AIMD) implemented at the kernel level of the operating system.

TCP congestion control was introduced by Van Jacobson in the 1980s. At that time, congestion collapse was a big problem in Internet environment. Each host sent a maximum number of packets that it could send within a fixed time to send information quickly. However, in some routers, congestion has occurred and packets received within a certain time have not been processed. If the packet was not processed within a fixed time, the host retransmitted the packet, and the router received more packets, causing congestion to become exponentially more severe.

In order to solve the problem of congestion due to retransmission, a packet is sent one by one. When the packet arrives without problems, the window size, ie, the number of packets sent in unit time is increased by 1, Algorithm. Decreasing the Sum Increment Product The congestion control algorithm reduces the sending rate of packets by half if the packet transmission fails or exceeds a certain time.

This is a fair way. If several hosts using this method share a network, the later entry is disadvantageous at first but converges to equilibrium over time. Although the sum-multiply-decreasing scheme works efficiently around the capacity of the network, it has the disadvantage that it takes too long to initially increase the transmission rate.

The Slow Start method starts by sending packets one at a time, just like the sum / multiply decrement method. However, this method increases the window size by 1 for each ACK packet when the packet arrives without problems. That is, after one cycle, the window size is doubled.

Therefore, the transmission rate increases exponentially, unlike decreasing the sum-multiply product. Instead, when congestion occurs, the window size is dropped to 1 instead of half. At first, there is no information to predict the capacity of the network. However, once the congestion occurs, the capacity of the network can be predicted to some extent. Therefore, until half of the congestion window size is increased, After that, it is gradually increased by 1.

The previous TCP behavior begins by sending as many packets as possible at the beginning, and the slow start, unlike this, detects the capacity of the network by increasing the window size from 1 to an exponential function. This method is more efficient than the sum-multiply-decreasing method, but if there is a congested situation, there is a large amount of time blanking while waiting for a timeout.

The problem of the TCP-specific congestion control algorithm is that it takes a long time because it can not use the high bandwidth of the network in the early stage and it does not detect the congestion of the network in advance. In other words, congestion control algorithms such as decreasing sum-multiplying and slow-start are methods in which bandwidth is reduced only after the network becomes congested.

Referring to FIG. 2, the characteristics of such a TCP-specific congestion control algorithm are well illustrated. 2 shows a TCP bandwidth when a file is transferred from port 48476 of the internal network 10.0.0.2 to port 8080 of the host 10.0.1.1. In the case of TCP, if the initial connection or loss occurs in the middle, the congestion control algorithm will reduce the buffer size (Congestion Window Size) in the TCP itself. Therefore, it takes time to increase the transmission speed to a certain level.

Referring to FIG. 2, the process of repeating the process of dropping the transmission bandwidth very slowly and then repeating the process is repeated. This process leads to a bandwidth that can be reliably used only about 14 minutes after the file is transferred. However, if the transmission bandwidth is changed suddenly in this way, the quality degradation may occur seriously in a real time transmission application.

3 is a diagram for explaining a case of transmitting real-time multimedia using a conventional TCP transmission.

Referring to FIG. 3, the user can see the video displayed on the receiver's screen at the top and the bandwidth available in the application at the bottom. When TCP congestion occurs, we try to resolve congestion in a way that sharply reduces the bandwidth.

Referring to the lower part of FIG. 3, it can be seen that bandwidth is suddenly reduced to about half due to congestion while transmitting images at a bandwidth of 50 kbps stably until the first 200 seconds. Then, it is not until 400 seconds again that the original bandwidth of 50kbps is recovered.

If the network bandwidth changes suddenly, the quality of the video may suddenly deteriorate for the receiver. Referring to the upper part of FIG. 3, the image is broken between 200 seconds and 400 seconds. After the quality of the video suddenly deteriorates, it takes some time to recover.

1 through 3, since TCP is a protocol designed for reliable transmission from the beginning, there are some problems in transmitting multimedia in real time. One of them is that the bandwidth of TCP is sensitive to RTT or loss, so there is a bandwidth limitation that can be secured by one channel. The other is the TCP congestion control algorithm that can reduce the bandwidth drastically and it takes much time to recover the reduced bandwidth. Therefore, when real-time multimedia transmission is performed, .

4 to 5 are diagrams for explaining a real-time multimedia transmission method according to an embodiment of the present invention.

Referring to FIG. 4, the real-time multimedia transmission method proposed in the present invention uses parallel TCP transmission. That is, instead of transmitting real-time multimedia through one channel, real-time multimedia is transmitted through a plurality of channels. Such parallel TCP is a technology used for high-speed reliable file transfer in a place such as satellite communication where RTT is very long.

Since data that needs to be transmitted is simultaneously transmitted through multiple TCP channels, a higher bandwidth can be secured than TCP transmission using one channel. 4, three channels for transmitting data from the client 100 to the server 200 are generated. Generally, the use of parallel TCP makes it possible to secure the aggregated transmission bandwidth compared to using one channel.

Referring to the bottom of FIG. 4, the formula of the bandwidth BWagg integrated at the bottom is shown. In the formula of FIG. 1 using a single channel, the equation is modified in such a manner that a portion related to a channel-specific packet loss is added. That is, assuming that 1 to n channels are used, a bandwidth of the sum of reciprocals of the square root of packet loss p1 to pn for each channel can be maximized.

In the case of generating a plurality of channels, the RTT or MSS between the client 100 and the server 200 have the same value irrespective of the channel, so they can be grouped together. Then, as shown in the lower part of FIG. 4, only the packet loss for each channel is left. Of course, since a plurality of channels are created in the same network, the loss rate for each channel is the same unless otherwise specified. Then, it is possible to secure a bandwidth equal to a maximum of n bandwidths for each channel. Here, it is necessary to note that in the equation of FIG. 4 there is "? &Quot; in the formula of BWagg.

That is, since the bandwidth of the entire network is not infinite, the bandwidth that can be used to increase the channel does not increase continuously, and there is a certain limitation. Referring to FIG. 5, it can be seen that the bandwidth increases proportionally to the number of channels up to 10, although it is the result of testing in the internal network.

However, referring to FIG. 5, since the number of channels exceeds 10, even if the number of channels is increased, the bandwidth does not increase proportionally and converges to about 200 Mbps. Even if the channel is continuously increased, the bandwidth that can be secured converges to a specific value.

This is due to the limitation of the bandwidth of the entire network, the load occurring in the transmitting apparatus for dividing the data into each channel, the load occurring in the receiving apparatus for receiving and merging the divided data for each channel, and the like. Also, network environment values such as available bandwidth, delay, and loss rate are affected as the number of channels increases. Therefore, these changes must be considered when adding channels.

As shown in FIGS. 4 to 5, when real-time multimedia is transmitted using a plurality of channels, a large bandwidth can be secured compared with the case of transmitting data using one channel. Therefore, I can solve the problem.

In addition, since the method of transmitting real-time multimedia using parallel TCP acceleration according to the present invention manages a plurality of channels in a pool form, it can secure a high bandwidth quickly, Can receive. This will be described in more detail with reference to FIGS. 7A to 7B.

FIG. 6 is a block diagram illustrating a PTCP channel manager according to an embodiment of the present invention. Referring to FIG.

PTCP stands for parallel TCP (parallel TCP). In order to transmit real-time multimedia data through a plurality of channels, the transmitting apparatus 100 divides the data into a plurality of packets and transmits the data through each channel. In addition, the receiver 200 must merge the received packets for each channel to restore real-time multimedia data.

To this end, the client 100 as a transmitting apparatus may include a BW broker 110, a PTCP channel manager 120, and a channel BW estimator 130 module. Similarly, the server 200, which is a receiving apparatus, may also include a BW Broker 210, a PTCP Channel Manager 220, and a Channel BW Estimator 230 module.

The BW Broker 110 of the client 100 or the BW Broker 210 of the server 200 plays a role of relaying the bandwidth in relation to the application. For example, when the BW Broker 110 of the client 100 requests the bandwidth (BW) required by the real-time video conferencing application to the BW Broker 110 of the client 100, the BW Broker 110 of the client 100 transmits the PTCP Channel To the manager (120).

The PTCP Channel Manager 120 receiving the required bandwidth from the application receives the information on the bandwidth per channel from the Channel BW Estimator 130 and compares the information. That is, it compares whether the bandwidth requested to the current application requires generation of an additional channel.

The channel BW estimator 130 measures RTT, loss, and jitter of the PTCP channel in real time in order to provide information on the bandwidth per channel. Based on this, we estimate the minimum bandwidth and average bandwidth per PTCP channel. Herein, the minimum bandwidth means a TCP bandwidth which is minimally transmitted by a slow start when a loss occurs.

Since the operation may be slightly different depending on how the TCP is implemented at the kernel level of the operating system, the Channel BW Estimator 130 determines RTT and Loss according to the end-to-end combination of the client 100 and the server 200. [ And the prediction accuracy can be improved by generating a model by a preliminary experiment.

Returning to the PTCP Channel Manager 120, when a bandwidth required for real-time transmission is requested in consideration of the size of the screen (= resolution) and the number of participants in the real-time multimedia application, the bandwidth is received through the BW Broker 110.

And compares the channel-by-channel bandwidth calculated in real time with the Channel BW Estimator 130. The PTCP Channel Manager 120 transmits a control message for creating a new PTCP channel to the PTCP Channel Manager 220 if the additional channel is required to secure the required bandwidth B. [

The corresponding control message is transmitted through the PTCP dedicated header. That is, the PTCP channel is transmitted through the control message code, not the real-time multimedia data, and the PTCP channel manager 220 generates a necessary PTCP channel based on the control message received during the session.

In addition, the PTCP Channel Manager 120 not only manages the addition and deletion of channels, but also plays a role of dividing and merging data. The PTCP Channel Manager 120 basically divides real-time multimedia data transmitted through a plurality of TCP sockets according to the MSS and adds a PTCP dedicated header.

The PTCP Channel Manager 220 of the server 200 receiving the divided multimedia data from the PTCP Channel Manager 120 of the client 100 refers to the information added to the dedicated header and reassembles the packet again, And transmits the generated multimedia data to the application of the server 200.

Although not shown in FIG. 6, the real-time application of the server 200 is responsible for retransmitting the real-time multimedia data transmitted by the client 100 to another client. Thus, it is possible to provide real-time video conferencing services to a plurality of clients.

In addition, the PTCP Channel Manager 120 manages an extra PTCP channel generated in advance in order to quickly converge to the requested bandwidth in real time. That is, the PTCP channel can be managed in a pool manner. Due to the nature of TCP, additional connection setup time is required to transmit data even if the channel is additionally created.

A 3-Way Handshake is the process of exchanging a packet three times in order to establish a reliable connection. In order to make a connection from the client to the server for the first time, a SYN packet is transmitted first. The server then receives it and sends the SYN ACK packet back to the client. The client finally sends an ACK packet back to the server.

This 3-way handshake process ensures that both the client and the server are ready to transmit data. Of course, there are 3-Way Handshakes as well as 4-Way Handshakes. The first time a TCP channel is created, it takes at least 3 RTTs to transmit data.

Also, even if a channel is created, it is not possible to transmit data at a high bandwidth. As we have seen, the TCP-specific congestion control algorithm results in a gradual increase in the available bandwidth of the generated channel. Therefore, it takes a long time, including the time taken to create the channel, and the time taken to secure the necessary bandwidth.

For example, assuming that the required full window size per channel is 100 units, if the bandwidth available on the corresponding channel increases by 1 RTT + (1 + 2 + 4 + 8 + 16 + 32 + 64) The maximum bandwidth of 100 units is exceeded. Therefore, in the interval of RTT of 200 ms, at least 1.6 seconds is required before the required bandwidth can be secured in the corresponding channel.

To solve this problem, in the present invention, not only the real time multimedia data is transmitted using the parallel TCP, but also the PTCP channel is managed in a full form and the bandwidth is pre-secured do.

7A and 7B illustrate a process of managing a PTCP channel in a pool manner according to an embodiment of the present invention.

7A is a diagram for explaining a change in Window Size when the PTCP Channel Manager 120 receives a necessary BW request from the BW Broker 110 and generates a channel. First, when data is transmitted through one channel until time t1, and another bandwidth is requested from the BW broker 110 and a channel is further generated, time is required until time t2 in order to maximize the bandwidth of the second channel . This is due to the TCP-specific congestion control algorithm.

That is, even if the BW broker 110 requests a bandwidth extension, it takes a time of a = t2 - t1 to provide a smooth bandwidth in the PTCP Channel Manager 120 as a service. In order to solve such a problem, the present invention proposes a method of generating a plurality of channels in advance and reserving a bandwidth.

That is, the PTCP Channel Manager 120 previously generates a plurality of channels in advance and transmits a PTCP channel message or dummy data through the corresponding channel, thereby securing the Congestion Window size of the corresponding channel to a high level, 110) requests bandwidth extension, the service can be provided so that the bandwidth can be used immediately.

Referring to FIG. 7B, two channels are generated in advance at time t1, and the bandwidth of the corresponding channel is secured by transmitting dummy data or the like from that time. Next, when the BW Broker 110 requests bandwidth extension at time t2, it can transmit real-time multimedia data through two channels from a time t3 to a requested window size through a channel that is generated in advance and has an extended bandwidth.

In the case of FIG. 7B, it is possible to provide the service of the requested bandwidth immediately only by the time of a '= t3 - t2. In other words, the previously generated channel can be aged in advance to quickly digest the requested bandwidth. This also solves the second problem due to the existing TCP-specific congestion control algorithm.

Of course, there has been a conventional high speed transmission method of large capacity data using parallel TCP. However, the conventional parallel TCP is determined by how many parallel TCPs are used before the data is transmitted. On the other hand, the parallel TCP proposed in the present invention considers the end-to-end network environment in real time, To manage them dynamically.

This is different from the existing PTCP which transmits a fixed size file in that the real-time property is important for real-time multimedia data and the required bandwidth can be changed depending on the resolution or image quality of the screen. For example, if a user changes the resolution of a video conference from 360p to 720p, the amount of bandwidth needed per hour will vary.

In this case, it is necessary to calculate the bandwidth required for video conferencing at 720p resolution, and to recalculate the number of parallel channels required to provide service at that bandwidth. This is a difference between the conventional PTCP for transmitting a file as soon as possible over a predetermined number of channels and the PTCP of the present invention for transmitting real-time multimedia.

In order to calculate the number of parallel channels dynamically required, the channel BW estimator 130 of the present invention measures RTT, transmission / reception buffer size, and loss, which are environment values of the network, in real time, The congestion control algorithm, and the like, it is possible to calculate the number of sessions of the TCP corresponding to the desired bandwidth in the multimedia application.

Since the implementation method of the TCP kernel of the operating system used by the client 100 and the server 200, for example, the congestion control method, the buffer size, and the error processing method are different, the bandwidth of the TCP is predicted by the pre- The model is mounted on the Channel BW Estimator (130). Pre-modeling is a simulation of the extent to which the transmission / reception operating system and network environment (RTT, loss, and jitter) change.

6 and 7A to 7B, a real-time multimedia transmission method using the parallel TCP according to the present invention has been described. Referring back to FIG. 6, the BW broker (110) 210 of the present invention receives a bandwidth reservation request stably from a real-time application and transmits it to the PTCP channel managers 120 and 220. Although only one application is shown in FIG. 6, various applications requiring real-time multimedia transmission may be connected to the BW brokers 110 and 210. FIG.

Next, the PTCP Channel Managers 120 and 220 play a fundamental role of stripping and re-merging a multimedia data stream (RTP) simultaneously transmitted in parallel to generate a source multimedia stream. In addition, it plays a role of interworking with the BW brokers (110, 210) and the channel BW estimators (130, 230) to exchange necessary channel control messages in real time and create a new channel. In addition, when a channel having a much larger bandwidth than the requested bandwidth is opened for a long time, the generated channel can be returned dynamically. It is responsible for managing the channel in a pool manner.

Finally, the channel BW estimators 130 and 230 are responsible for managing the characteristics of communication channels between end-to-end in real time through control messages (RTCP) according to the network environment such as RTT, jitter, and loss. In addition, RTT, Jitter, and Loss are input, and it is responsible for estimating the bandwidth per channel according to operating system-specific TCP characteristics. It also provides information to determine whether to create a new channel to provide the required bandwidth service.

8 is a flowchart of a method of transmitting real-time multimedia using parallel TCP acceleration according to an embodiment of the present invention.

Referring to FIG. 8, in the real-time multimedia application, a required bandwidth due to a specific event is changed (S1100). For example, if an attendee is added to a video conference, or a screen resolution is changed from 480p to 720p, the bandwidth can be more than that to provide a real-time multimedia service. In this case, it is compared whether the current bandwidth can be accommodated through the current channel. If the bandwidth can be afforded, the service is provided with the requested bandwidth. If the bandwidth can not be provided, the maximum bandwidth is provided.

In contrast, according to the present invention, the bandwidth B requested by the BW Broker 110 is requested (S1200), and the bandwidth extension request is transmitted from the BW Broker 110 to the PTCP Channel Manager 120 (S1300). The PTCP Channel Manager 120 then checks the maximum bandwidth C that can be provided through the currently used channel (S1400).

Next, the PTCP channel manager 120 compares the bandwidth B requested by the BW broker 110 with the maximum bandwidth C that can be provided through the current channel (S1500) If the bandwidth C is larger than the requested bandwidth B, that is, if the requested bandwidth B can be accommodated without further generating a channel, the requested bandwidth B is returned (S1550).

If the maximum bandwidth (C) that can be provided through the current channel is smaller than the requested bandwidth (B), that is, if the requested bandwidth (B) can not be met without further generating additional channels, And receives from Channel BW Estimator 130 the maximum bandwidth (C) that can be provided when using up to a further generated channel.

Next, the PTCP channel manager 120 compares the bandwidth B requested by the BW broker 110 with the maximum bandwidth C 'that can be provided through the added channel (S1700) (B) if the maximum bandwidth (C ') that can be received is greater than the requested bandwidth (B), that is, the requested bandwidth (B) over the further generated channel S1750).

If the maximum bandwidth (C ') that can be provided through the added channel is smaller than the requested bandwidth (B), that is, if the user can not afford the requested bandwidth (B) even if an additional channel is generated, (C ') that can be provided through the RNC.

The real-time multimedia transmission method proposed in the present invention differs from the conventional single-channel multimedia transmission method in that additional bandwidth is secured through channel addition. As shown in FIG. 5, although the total network bandwidth exists as a maximum limit, since the available bandwidth increases proportionally with the addition of the channel to some extent, it is necessary to transmit the real time multimedia through the parallel TCP transmission Gt; of the < / RTI >

9 to 12 are views illustrating a Channel BW Estimator and a PTCP Channel Manager according to an embodiment of the present invention.

Referring to FIG. 9, the channel BW estimator 130 measures RTT, loss, and jitter of an RTP channel periodically transmitted through an RTCP (Real-time Control Protocol) (S2100). Here, RTP is a protocol for transmitting video and audio as described above, and RTCP is a protocol for monitoring the transmission state of RTP data.

RTCP is a protocol for transmitting session related information and can measure the network environment value of the RTP channel using RTCP. The current RTCP statistic value is calculated through the measured value (S2150). The calculated RTCP statistic value is used to select a PTCP throughput model in the future.

In addition, the throughput statistic value according to the number of I / O bytes actually transmitted per second is set as the input value (S2200, S2300) through the PTCP Channel characteristic, and the combination of the transmission apparatuses and the receiving apparatuses Based on the PTCP throughput model according to the current channel (S2300).

As mentioned above, since the operation may be slightly different depending on how the TCP is implemented at the kernel level of the operating system, the PTCP bandwidth is variously modeled according to the combination of the operating system of the transmitting apparatus and the receiving apparatus. Then, by using the RTCP statistics and the I / O rate (bit rate), it is possible to predict the change in the network environment value when the channel is added by selecting a necessary model in the PTCP bandwidth model, and to predict how much bandwidth can be secured .

The calculated value of the available bandwidth for each current channel is provided to the PTCP Channel Manager 120 and used to determine whether to further generate a channel to cover the bandwidth requested by the user. The PTCP bandwidth model will be described in more detail with reference to FIG.

10, in the channel BW estimator 130, a RTT, a loss, a jitter, and a jitter of a RTT periodically measured in consideration of a current RTCP and a PTCP throughput (Bitrate) It is judged by experimental / statistical results whether the current traffic is stable enough to allow "Increase" or "Decrease" according to the amount of data actually flowing. (Threshold) is calculated and pre-modeled.

For example, the current RTT, Loss, and Jitter values of the RTP channel are measured and monitored through the RTCP protocol. In the PTCP bandwidth model, RTT, loss, and jitter according to the channel number according to the combination of the operating system of the transmitting apparatus and the receiving apparatus are built in advance as models.

In other words, if another channel is added in the current state, the RTT, loss and jitter values can be predicted through the PTCP bandwidth model and the change of RTT, loss, and jitter is examined. As a result, Stable, Medium, or Unstable.

If the change of the network environment value (RTT, Loss, Jitter) is stable even if a channel is added, the channel can be increased (Increase). On the other hand, when the change of the network environment value is normal, it is preferable to leave the number of channels as it is. On the other hand, when the change of the network environment value is unstable, it is desirable to reduce the channel (Decrease).

This decision can also be done using PTCP rate statistics to finally determine whether to add or reduce the channel. The PTCP channel manager finally determines whether to add a channel using the RTCP statistic value and the PTCP rate statistic value.

Referring to FIG. 11, the channel BW estimator 130 performs a change prediction on a currently available BW value when a channel is increased. When one channel is added according to the PTCP throughput model, (RTT, Loss, and Jitter), it predicts throughput, RTT, jitter, and loss, which are expected to increase when one channel is added per operating system.

That is, when a parallel TCP is used, a channel is added, thereby changing the network environment such as RTT, loss, and jitter due to the added channel. The change of the network environment value affects the existing channel as well as the newly added channel. In particular, the value of the network environment varies depending on the operating system used by the transmitting apparatus and the receiving apparatus. We model it through various experiments beforehand. It predicts the effect of channel addition and predicts the bandwidth that can be transmitted due to parallel TCP including the added channel.

Referring to FIG. 12, the PTCP Channel Manager 120 directly processes the request of the BW Broker 110 (S3100). When an extension request is received from the BW Broker 110 to the bandwidth B, the channel BW estimator 130 attempts to expand the channel considering the expected bandwidth when the channel is added (S3200).

At this time, as shown in FIG. 5, even if a channel is further added, the estimated bandwidth may not be further increased. That is, the current bandwidth is compared with a preset threshold value (S3300). If there is no effect of adding a channel, the current bandwidth (Cur-BW) is returned (S3350).

If the current bandwidth is less than the threshold, additional bandwidth can be obtained by adding channels. In this case, a channel is added to compute an additional available bandwidth (Estimated BW) with the bandwidth B requested to be extended (S3400). In this case, when the bandwidth B requested for extension is smaller than the estimated bandwidth BW, it is possible to add the channel to the requested bandwidth B, (S3450).

If the bandwidth B requested for extension is larger than the estimated bandwidth BW, the bandwidth B can not be accommodated even if one channel is added. In this case, you need to add more than one channel. Therefore, one channel is added and the network environment value due to the added channel is updated (S3500).

If another channel is added next, the flow returns to step S3200 to request the expected bandwidth. Through this process, it is possible to estimate the total number of channels to be added in order to cover the bandwidth (B) requested to be extended. That is, if it is not sufficient to add one channel in order to cover the requested bandwidth B, it is possible to determine whether the bandwidth B requested for expansion can be accommodated by repeatedly adding a channel.

13 to 14 are exemplary diagrams illustrating a channel pool that can be utilized in an embodiment of the present invention.

Referring to FIG. 13, the PTCP Channel Manager 120 does not add a TCP channel to a channel at the request time of the BW Broker 110, but creates an extra PTCP channel in advance to minimize data flow. At this time, the pre-populated channel is called a pre-populated PTCP channel and the media data used by the real-time application is not sent to the corresponding channel in advance.

This allows you to reduce the time required for the connection to be established after the channel control message is delivered (Connection Setup Time) and the amount of time it takes to wait for the Windows Size to grow so that a certain amount of bandwidth can be obtained. In the case of UDP, this connection is very short, which is advantageous for real-time transmission. By contrast, TCP channels are generated and aged in advance to obtain similar effects to those based on UDP.

Referring to FIG. 14, the PTCP Channel Manager 120 generates a plurality of PTCP channels in advance (S4100). Then, the pre-generated PTCP channel is aged (S4200). The Aging Packets used here may be the Control Channel Message of the PTCP channel, the RTCP feedback, or a meaningless dummy packet. In other words, if there is nothing to send to the Sender Queue, a dummy packet can be created and sent as a PTCP Control Message.

(S4500) until the aging of the PTCP channel that has been generated is completed (S4300), and then a part of the packets stored in the queue of the transmitting apparatus is transmitted. However, after the Aging Packets are sufficiently aged up to the window size defined in the operating system, Aging may be stopped and the Aging Packets may wait in a pool until a request for the corresponding channel is received (S4400).

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, You will understand. It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive.

Claims (7)

Receiving a bandwidth required for a transmitting apparatus to transmit data from an application;
Predicting an available bandwidth when the transmitting apparatus adds a TCP channel for the application using a network environment value of a TCP channel that has been previously allocated for the application;
Comparing the available bandwidth with the available bandwidth and determining whether to add a TCP channel;
Dynamically adding a TCP channel for the application when the transmitting device determines to add a TCP channel; And
Wherein the transmitting apparatus transmits the data through the added TCP channel in a parallel TCP manner.
Data transmission method. The method according to claim 1,
The step of predicting an available bandwidth when adding a TCP channel for the application comprises:
Measuring a network environment value of an existing TCP channel for the application in real time;
Estimating a network environment value to be changed when a TCP channel is added using the measured network environment value; And
And estimating the available bandwidth using the predicted network environment value.
Data transmission method. 3. The method of claim 2,
Wherein the network environment value includes
RTT, Loss, and Jitter.
Data transmission method. 3. The method of claim 2,
The step of estimating a network environment value to be changed when the TCP channel is added using the measured network environment value,
Using the predictive model learned in advance based on the network environment value, the operating system of the transmitting apparatus, and the TCP characteristic implemented by the operating system of the receiving apparatus,
Data transmission method. The method according to claim 1,
Comparing the available bandwidth with the available bandwidth, and determining whether to add a TCP channel,
Determining that the TCP channel should not be added if the number of TCP channels allocated for the application is greater than or equal to a threshold;
Data transmission method. The method according to claim 1,
Dynamically adding a TCP channel for the application comprises:
Generating the TCP channel to be added in advance in the requested step and managing it in a pool manner;
And transmitting data to the pre-generated TCP channel, securing a bandwidth of the pre-generated TCP channel, and aging the pre-generated TCP channel.
Data transmission method. The method according to claim 1,
Wherein the transmitting apparatus further comprises returning unused TCP channels among TCP channels allocated for the application to a pool of TCP channels.
Data transmission method.

Images