Data transmission control method, program therefor and data transmission unit using the same

[0001] The present invention relates to a data transmission control method suitable for use to avoid network load concentration, transmission delay fluctuations due to congestion and packet loss in a network which provides a best-effort service like the Internet. The invention also pertains to a program for implementing the method and a data transmission unit using the method.

[0002] Since the routing algorithm of the Internet usually chooses the shortest route between nodes, Internet communications are conventionally carried out using only the shortest route.

[0003] On the other hand, attempts have been made to adapt the Internet to multi-path routing. There is known in the art a router equipped with functions that, for example, in the case of using an OSPF (Open Shortest Path First) scheme as the routing algorithm, supports decentralization of equivalent traffic loads among multiple routes of equal metrics, and that, in the case of using an IGRP (Interior Gateway Routing Protocol) scheme, unequally distributes the network traffic to multiple routes of unequal metrics in proportion to their metrics.

[0004] In the Internet now in use that carries out communications over only one route, network fault and traffic congestion are unavoidable, and when data loss or sever delay are caused by such network fault and traffic congestion, congestion control suppresses the traffic load to the failed route, giving rise to a problem that the throughput cannot be obtained as desired.

[0005] A conventional data distribution system in which a router determines distribution ratios for multiple routes based on their metric values does not reflect the ever-changing route conditions in the metric values, and hence this system is not the best distribution system taking into account the condition of each route. This system causes a problem that the throughput on all routes decreases under the influence of some routes of deteriorated conditions.

[0006] EdgeStream, Inc. proposes a delivery system in which plural delivery servers capable of sending the same contents in synchronization with each other are provided on different routes of a network, and when the traffic load on the contents transmitting route from the one delivery server to a user exceeds a prescribed value, the contents are sent via the other delivery server, thereby providing a guarantee of moving picture quality at a predetermined transmission rate. This method calls for plural servers, and hence raises the cost accordingly. In addition, this method is not free from the possibility that route switching interrupts the image being played back.

[0007] In Japanese Patent Application Laid-Open Gazette No. 2000-216817 there is described a system in which each router on the network monitors the traffic state on the transmission line and, when traffic concentration exceeding the premeasured throughput of a route, switches the route to another as a detour. However, this method requires premeasuring the throughput of each route and generating a routing table of every router on the network on the basis of the premeasured throughputs; hence, this method is impractical.

[0008] It is therefore an object of the present invention to provide a data transmission control method suitable for use to avoid network load concentration, transmission delay fluctuations due to traffic congestion and packet loss in a network which provides a best-effort service like the Internet, and a program for implementing the method and a data transmission unit using the method.

[0009] The data transmission control method according to the present invention which is used at the source node on the network to send therefrom data to the destination node, the method comprising:

[0010] (a) obtaining from the destination node quality information on multiple routes between the source and the destination node; and

[0011] (b) adaptively changing data distribution ratios for the multiple routes based on the route quality information.

[0012] According to the present invention, the transmission unit, which sets up multiple communication routes from the source node to the destination node on the network and distributes and sends data, comprises: means for obtaining quality information on the multiple routes from the destination node; and distribution control means for adaptively changing data distribution ratios for the multiple routes on the basis of their quality information obtained by the quality information obtaining means.

[0038] A detailed description will be given, with reference to the accompanying drawings, of preferred embodiments of the present invention. To facilitate a better understanding, the present invention will be described as being applied to a real-time data transfer through utilization of an RTP/RTCP (Real-Time Transport Protocol/Real-Time Transport Control Protocol) scheme equipped with a function of monitoring the network quality, but the present invention I not limited specifically thereto. Other various data delivery schemes provided with network quality monitoring means also fall inside the scope of the present invention.

Basic Principle of the Invention

[0039] FIG. 1 is a block diagram illustrating a basic network configuration which embodies the data transmission control method according to the present invention. FIG. 2 is a diagram showing connections of a multimedia data delivery system using the RTP/RTCP scheme between source and destination nodes in the network architecture of FIG. 1. RTP is a protocol developed for supporting packet delivery of video and audio data, and possesses a function of framing in a real-time application.

[0040] As shown in FIG. 1, the network architecture embodying the present invention has an existing network 30, and nodes 11 and 12 connected thereto via edge routers 21 and 22. According to the present invention, for example, a data packet from the source node 11 is distributed by the edge router 21 to one or more routes 31 and 32, for instance, over which it is sent to the destination node 12 via the edge router 22. While this example is shown to use only two routes 31 and 32, more than two routes may sometimes be used, and accordingly, the edge routers 21 and 22 (which need not always be edge routers) each have ports P0, P1 and P2 larger in number than the routes used.

[0041] According to the basic principle of the data transmission control method of the present invention, the source node 11 sends a packet to the destination node 12 over one route or more routes 31 and 32 to which the packet is distributed by use of a transport protocol. The destination node 12 obtains one or more of, for example, the packet loss ratio, the packet inter-arrival jitter, the one-way trip time and so on from the received packet, then writes them as information indicating the route quality (route quality information) in a receiver report, and sends the receiver report to the source. The source adaptively determines the distribution ratios for the multiple routes by changing the packet distribution ratios based on the route quality information in the received receiver report each time the source receives the report.

[0042] As shown in FIG. 2, in a data delivery system using RTP as a transport protocol, connections are established between the source and destination nodes 11 and 12 via a TCP (Transport Control Protocol) channel 101 of RTSP (Real-Time Streaming Protocol) and a UDP (User Datagram Protocol) channel 102 of RTP. A control channel 103 by RTCP is used to control RTP data transmission, and it possesses a function of offering information on the quality of data delivery to an application as mentioned above.

[0043] To measure the quality of each route, an RTP/RTCP session is provided on each route as described later on, then unified sequence numbers are assigned to all packets to be sent over multiple routes in a high-order application, and at the destination node the packets received from the same source over the multiple routes are rearranged in order of the sequence numbers.

[0044] FIGS. 3 and 4 show the format of an RTP header 6H of the IETF (Internet Engineering Task Force) spec and the format of a packet 70 of a receiver report using RTCP (which report will hereinafter be identified as RTCP-RR). As depicted in FIG. 3, the RT header 6H has version information V, padding P, extension bit X, number of sources concerned CC, marker bit M, payload type PT, sequence number SN, timestamp TS, synchronization source identifier SSRC and contributing source identifier SSRC, and is added with a payload 63. It is the sequence number (SN) 61 of the packet, the timestamp (TS) 62 indicating the packet-sending time, the synchronization source identifier SSRC and the payload (PL) 63 storing data that are related directly to the data transmission control method according to the present invention.

[0045] As shown in FIG. 4, the receiver report (RTCP-RR) 70 has version information V, padding P, receiver report count RRC, packet type PT, message length ML, synchronization source identifier of packet sender SSRC, synchronization source identifier of sender 1, packet loss ratio 71, cumulative number of packets lost (NPL), inter-arrival jitter (J) 72, last sender report timestamp LSR and delay since last sender report DLSR. Of them, the synchronization source identifier of packet sender SSRC, the packet loss ratio 71, the inter-arrival jitter 72, last sender report timestamp 73 and the delay since last sender report DLSR 74 are related directly to the data transmission control method according to the present invention.

[0046] At the destination node 12 it is possible to compute the packet loss ratio and jitter during one-way transmission from the source node 11 to the destination node 12 (which jitter will hereinafter be referred to simply as jitter J) on the basis of the sequence number 61 and the timestamp 62 in the received RTP packet 60. On the other hand, at the source node 11 it is possible to obtain the packet loss ratio 71 and the jitter 72 during one-way transmission from the receiver report RTCP-RR. Further, it is possible to compute the RTCP packet round-trip time RTT from the sending timestamp of an RTCP sender report (hereinafter identified as RTCP-SR) from the source node to the destination node, the receiver report RTCP-RR receiving timestamp and the last sender report timestamp LSR and the delay since the last sender report DLSR carried in RTCP-RR.

[0047] FIG. 5 depicts the configuration of an RTCP sender report (RTCP-SR) 80. The illustrates report configuration differs from the receiver report RTCP-RR in that an NTP timestamp 81, an RTP timestamp 82 and the cumulative number of sender packets 83 are added as sender information.

[0048] FIG. 6 depicts the configuration of an IP header 4H. The IP header 4H contains, version information V, header length IHL (Internet Header Length), TOS (Type of Service) 41, IP packet length (LEN) 42, datagram identifier ID 43, fragment control field FRAGMENT 44, sender address SOURCE ADDRESS 45 and destination address DESTINATION ADDRESS 46.

[0049] FIG. 7 shows the configuration of a UDP (User Datagram Protocol) 50. UDP comprises a header 5H containing source port number 51, UDP destination port number 52 and LENGTH 53 representative of the number of bytes of all UDP datagrams, and data 54.

[0050] As depicted in FIG. 8A, the RTP packet is made up of IP header 4H, UDP header 5H, RTP header 6H and RTP data (payload) 63. The RTCP packet comprises, as shown in FIG. 8B, IP header, UDP header 5H and RTCP message 7M. The IP header 4H has a TOS field as shown in FIG. 6, whereas the UDP header has a destination port number field as shown in FIG. 7.

[0051] As the edge routers 21 and 22 on the network 30 shown in FIG. 1, there are generally available routers equipped with a policy routing function that presets a policy as to how to perform packet routing and carry it out accordingly. With such a router, the output port for an input packet, for example, from a port 0 connected to the node can be determined according to the value of TOS 41 (hereinafter referred to as a TOS value) of the IP header; and the output port for an input packet from the other ports can be determined according to the destination address 46 of the IP header. Accordingly, the TOS values of the IP headers 4H of respective packets can be sequentially determined by the application at the source node 11 so that packets are distributed among the plural ports P1 and P2 at desired distribution ratios.

[0052] Alternatively, it is possible to specify port numbers by the UDP destination port number 52 in FIG. 7 according to the application used so that the router 21 outputs packets to the specified ports according to the individual destination port numbers 52. In a conventional end-to-end connection, the application fixes the TOS value at a certain value and the router selects the packet output port corresponding to the destination address 46 in the IP header 4H from a routing table.

[0053] FIG. 9 shows an example of a packet transfer sequence between the source node 11 and the destination node 12. The source node 11 sends packet data over one or more routes by RTP, and sends the sender report RTCP-SR at fixed time intervals δT (for example, several seconds). The arrows shown between the source node 11 and the destination node 12 represent packets, and the symbol x represents packets lost on the routes. The destination arranges the packets received from the source over the respective routes in the order of the packet sequence number 61 (FIG. 3) in the RTP header, checks which numbers are missing, and calculates the packet loss ratio.

[0054] The destination node 12 sends RTCP-RR to the source node 11 at the same time intervals δT as is the case with the source node 11 (need not always be the same). AT this time, the destination node 12 writes, as route quality information, the packet loss ratio, the RTP packet inter-arrival jitter J, the timestamp 81 for the immediately previously received RTCP-SR (FIG. 5) and the delay DLSR (Delay since Last) since the last sender report RTC-SR in fields 71 to 74 of RTCP-RR (FIG. 4), thereafter sending the receiver report. DLSR is computed, as depicted in FIG. 9, by DLSR=Ti−Ci where Ci is the receiving time for the last sender report RTCP-ST and Ti is the time of generation of the receiver report RTCP-RR.

[0055] The RTP packet inter-arrival jitter J is defined, for example, by the following equations from receiving times R_n−1 and R_n for (n−1)-th and n-th RTP packets in the order of packet sequence.
D(n, n−1)=(R_n−TS_n)−(R_n−1−TS_n−1)  (1)
J=J+{|D(n, n−1)|−J}/16  (2)

[0056] The source node 11 extracts the route quality information from RTCP-RR received from the destination node 12 and, based on the packet inter-arrival jitter J, determines RTP packet distribution ratios for the respective routes. Alternatively, the source node 11 computes RTCP round-trip time RTT by the following equation from the receiving time T_R of the receiver report RTCP-RR responding to the sender report RTCP-SR
RTT=T_R−DLSR−LSR  (3)
and the source node may use the RTCP round-tip time RTT as route quality information.

[0057] Since the source node is able to know the traffic conditions (quality) of routes as described above, it can adaptively increase or decrease the packet data distribution ratios for the respective routes, taking into account their conditions. This embodiment features measuring the quality of routes for data delivery at whatever time and determining the packet distribution ratios for the respective routes based on the quality information.

[0058] FIG. 10 illustrates the procedures of the source node and the destination node based on the basic principle of the data transmission control method according to the present invention.

[0059] At the source node:

[0060] Step S11: Determine initial values of distribution ratios for multiple routes as desired.

[0061] Step S12: Transfer RTP packets over respective routes at the determined distribution ratios and send the sender report RTCP-SR at fixed time intervals.

[0062] Step S13: Make a check at fixed time intervals to see if any receiver report RTCP-RR has been received, and if not, return to step S121.

[0063] Step S14: If receiver report has been received, obtain or compute route quality information from the received receiver report RTCP-RR.

[0064] Step S15: Update the distribution ratios for the multiple routes in accordance with the obtained quality information, then returns to step S12, and transfer RTP packets over the multiple routes at the updated distribution ratios.

[0065] At the destination node:

[0066] Step S21: Receive RTP packets.

[0067] Step S22: Make a check to see if any sender report RTCP-SR has been received from the source node, and if not, returns to step S21.

[0068] Step S23: Compute or obtain route quality information from the received RTP packets and/or the sender report RTCP-SR.

[0069] Step S24: Write the route quality information in the receiver report RTCP-RR and send the report to the source node and return to step S21.

[0070] As the route quality information, it is possible to use any one or more of the packet loss rate on each route for data delivery, the round-trip time and jitter as mentioned previously, and the data distribution ratios for the multiple routes are changed based on the route quality information.

[0071] In this embodiment, the destination node obtains the quality information on respective routes from the RTP packets and RTCP-SR received via the respective routes and sends the quality information to the source node, which, in turn, changes the distribution ratios for the respective routes on the basis of the quality information on the routes. Since the route from which each received RTP packet was output can be detected from the TOS value of the IP header 4H (FIG. 6) or the destination port number 52 of the UDP header 5H (FIG. 7), it is possible to calculate the packet loss rate and the packet inter-arrival jitter for each route.

[0072] For example, in a route with a large packet loss ratio, there is the possibility of a persistent congestion occurring; hence, the data distribution ratio for this route is sharply decreased, but instead the distribution ratios for routes of low packet loss rate are increased.

[0073] In the case of adaptively changing the distribution ratios by the source node, for example, upon each reception of RTCP-RR, the source node repeats, in step S14 in FIG. 10, the operations of: comparing quality values of the respective routes, decreasing the distribution ratio for a route of the minimum quality value by a predetermined value, while at the same time increasing the distribution ratio for a route of the maximum quality value by a predetermined value.

[0074] FIG. 11 shows the procedure of the source node in the case of using jitter J as the route quality information.

[0075] Step S1: Set initial values of the distribution ratios for multiple routes as desired.

[0076] Step S2: Send packets over the multiple routes at the initialized distribution ratios.

[0077] Step S3: Obtain the jitter values J of the respective routes from received RTCP-RR.

[0078] Step S4: Compare the jitter values J of the respective routes.

[0079] Step S5: Increase the distribution ratios by a predetermined value for the routes of small jitter values J and decrease the distribution ratios by a predetermined value for the routes of large jitter values J, followed by a return to step S2.

[0080] While FIG. 11 shows the procedure to be followed in the case of using the jitter as the route quality information, it is also possible to use the packet loss rate which is obtained from the receiver report RTCP-RR, or the round-trip time RTT which is computed from LSR and DLSR available from RTCP-RR and the RTCP-RR receiving time T_R.

[0081] Incidentally, there is a case where the distribution ratio for a certain route becomes extremely small as the adaptive changing of the distribution ratios for multiple routes is repeated in the first embodiment. In such a case, the routes provides packets at very long time intervals than the other routes. It was found by inventors' simulations, however, that as the packet interval δ increases, the packet inter-arrival jitter sharply increases irrespective of the actual traffic on the route as shown in FIG. 12. In order that the jitter value corresponding to the actual traffic may be measured at the destination, it is also possible to adjust at the source node in step S2 in FIG. 11 the timing or order of packet transmission in such a manner as to provide the packets to each route at equal time intervals.

[0082] To this end, two or more packets are provided in succession to each route at equal time intervals. That is, when two routes 31 and 32 are used as in the FIG. 1 example and the distribution ratio is 1:9, 10 packets are provided in succession to the route 31 at equal time intervals, and then 90 packets are provided in succession to the route 32 at equal time intervals. In this instance, the packet interval on the route 31 and the packet interval on the route 32 need not always be equal.

[0083] In this embodiment, at the destination node handles the packets received from multiple routes in step S21 in FIG. 10 without distinction of route, and computes the packet loss rate or packet inter-arrival jitter for all the received packets. That is, the destination node processes the received packets, regarding a set of multiple routes as a single virtual route. The route information thus obtained is inserted in RTCP-RR together with LSR and DLSR and sent to the source node in step S2.

[0084] The source node adaptively changes the distribution ratios for the multiple routes in step S14 on the basis of the route quality information obtained from the receiver report RTCP-RR in step S13. For example, the distribution ratio for an arbitrarily chosen route is increased by a predetermined value, and if the route quality information obtained from RTCP-RR received next indicates an improvement in the quality of the virtual route, the distribution ratio for that one route is further increased by a predetermined value, whereas if the route quality information indicates deterioration in quality, the distribution ratio for that route is lowered by a predetermined value and the distribution ratios for the other routes are each raised by a predetermined value. The distribution ratios for the respective routes can be adaptively changed by changing the distribution ratios and feeding back the resulting change in the quality information of the virtual route as described above. The quality information may be jitter, the packet return-trip time, or packet loss rate, for instance.

[0085] In the first and second embodiments the source node has been described to provide packets to the multiple routes in accordance with the distribution ratios at all times. In this embodiment, however, the source node: normally predetermines one of the multiple routes as a default route; sends packets over the default route alone (that is, sets the distribution ratios for the other routes to 0%); when the quality of the default route goes down below a predetermined value, raises the distribution ratios for other routes; and when the quality of the default route goes up above the predetermined value, sets the distribution ratio for the default route again to 100%.

[0086] FIG. 13 shows the procedure of the source node in this embodiment.

[0087] Step S1: Predetermine the default route and set the distribution ratio therefor to 100%.

[0088] Step S2: Provide packets to the default route at the distribution ratio 100%.

[0089] Step S3: Obtain quality information on the default route from the receiver report RTCP-RR, or compute the packet round-trip time as the quality information from the RTCP-RR receiving time TR, LSR and DLSR.

[0090] Step S4: Compare the quality of the default route with a prescribed value.

[0091] Step S5: If the route quality is lower than the prescribed value, obtain quality information on the other routes from RTCP-RR.

[0092] Step S6: If the route quality of the other routes is higher than the prescribed value, lower the distribution ratio for the default route by a predetermined value, raise the distribution ratios for the other routes according to the route quality, and return to step S2. But when the distribution ratio for the default route is 100%, quality information on the other routes is not available, so that the distribution ratios for the other routes are equally raised.

[0093] Step S7: If the route quality is found higher than the prescribed value in step S2, raise the distribution ratio for the default route by a predetermined value, then lower the distribution ratios for the other routes by a predetermined value, and return to step S2. When the distribution ratio for the default route is already 100%, it is kept unchanged.

[0094] The third embodiment has been described to determine one default route as a route that is normally used, but in this embodiment an arbitrary one of multiple routes is selected for normal use, and when the quality of the selected route goes down below a permitted level, distribution ratios are assigned to other routes.

[0095] FIG. 14 depicts the procedure of the source node in this embodiment.

[0096] Step S1: Set a distribution ratio 100% as an initial value in an arbitrarily chosen route.

[0097] Step S2: Transfer packets over the chosen route according to the preset distribution ratio.

[0098] Step S3: Obtain or compute route quality information from the receiver report RTCP-RR.

[0099] Step S4: Decide whether there are routes with their quality higher than a prescribed value.

[0100] Step S5: When there are routes with their quality higher than the prescribed value, raise the distribution ratios for such routes by a predetermined value and return to step S2.

[0101] Step S6: If there are no routes with their quality higher than the prescribed value, control the distribution ratios for the routes according to their quality and return to step S2.

[0102] In the FIG. 14 embodiment, when it is decided in step S4 that the route quality has deteriorated below the prescribed value, part of traffic is distributed to other routes, then the quality of each route is compared with the quality of the other routes, and the distribution ratios for routes of better quality are gradually raised. When it can be decided that the quality of only either one of the routes satisfies the prescribed value, control can be effected to perform communications over the route alone.

[0103] By adaptively changing the distribution ratios for multiple routes at the source node as described above, the situation sometimes arises where a 100% distribution ratio is set in only in one route but 0% in the other routes. In such an instance, since packets are sent solely over that one route, the source node does not obtain quality information about other routes from the receiver report, and consequently, the quality information available in this case differs from that in the case of using multiple routes. By changing the distribution ratios for multiple routes in the manner described above, there could arise the state of single-route communication and the state of multi-route communication. This embodiment adopts a different distribution ratio control method for each of the single-route communication and the multi-route communication.

[0104] FIG. 15 shows the procedure of the source node in this embodiment.

[0105] Step S1: Set initial values of distribution ratios arbitrarily determined for multiple routes.

[0106] Step S2: Send PFT packets over the respective routes at the set distribution ratios.

[0107] Step S3: Obtain or compute quality information on each route from the receiver report RTC-RR.

[0108] Step S4: Decide whether the current state of communication is the single-route communication.

[0109] Step S5: In the case of single-route communication, the distribution ratios for the multiple routes are determined by a method predetermined for the single-route communication and return to step S2.

[0110] Step S6: In the case of multiple-route communication, the distribution ratios for the multiple routes are determined by a method predetermined for the multi-route communication and return to step S2.

[0111] During the single-route communication, it is impossible to obtain route quality information for each route in step S3. It was found by the inventors' simulations that the packet round-trip time sharply increases immediately before congestion starts to occur in a certain route. FIGS. 16A, 16B and 16C shows the results of simulations about variations in jitter, packet round-trip time and packet loss when the traffic load ρ monotonously increases in one route with the lapse of time. As shown in FIG. 16C, an increase in the traffic load causes a sharp increase in the packet loss at and after a certain point in time, resulting in the occurrence of congestion. FIG. 16A shows that jitter gently varies in such a manner as to reach its peak at the time when congestion begins. In contrast thereto, FIG. 16B shows that the packet round-trip time sharply increases immediately prior to the start of congestion but thereafter it does not markedly varies.

[0112] For example, when the packet loss increases in the route currently used for communication, there is the possibility of persistent congestion occurring, in which case the source node effects control in step S5 to sharply lower the packet distribution ratio for this route but sharply raise the distribution ratios for other routes. Alternatively, even if the packet loss is smaller than a preset level, when the packet round-trip time RPP increases, for example, in the route currently used for communication, there is the possibility of the occurrence of congestion; hence, the packet distribution ratio for this route is lowered by a predetermined value and the distribution ratios for other routes are raised by a predetermined value.

[0113] During multiple-route communication the packet loss for each route can be obtained from RTCP-RR. Since there is the possibility of persistent congestion occurring, for example, in a route with a large packet loss, the source node effects control in step S6 to sharply decrease the packet distribution ratio for this route but sharply increase the distribution ratio for a route with a smaller packet loss on the basis of the packet loss rates of other routes. Similarly, during communication simultaneously using multiple routes jitter information for each route can be obtained from the RTP packet sent over each route. Since there is the possibility of temporary congestion occurring in a route with large jitter, the source node effects control in step S6 to lower the packet distribution ratio for that route to some extent but raise the distribution ratio for routes with small jitter on the basis of jitter in those routes.

[0114] In the case of sending packets over multiple routes, the reliability of measured values of jitter can be increased by adjusting the timing or order of sending the packet so that the packet intervals on the multiple routes are nearly equal.

[0115] FIG. 17 shows an example of the procedure in step S5 in FIG. 15.

[0116] During single-route communication the source node monitors packet loss and packet round-trip time as route quality information, and when the packet loss increases in excess of a preset level, the source node greatly lowers the distribution ratio for the route but equally raises the distribution ratios for other routes. When the packet round-trip time exceeds a preset level, the source node estimates that traffic concentration on the route causes congestion as mentioned previously with reference to FIGS. 16A, 16B and 16C, and lowers the distribution ratio for that route by a predetermined value from 100% and divides the lowered value of distribution ratio among other routes, for example, equally. An example of the procedure in step S5 in FIG. 15 will be described with reference to FIG. 17.

[0117] Step S51: Compare the packet loss rate in a single currently-used route with a preset level PL_S and decide whether the loss rate is higher than PL_S.

[0118] Step S52: If the packet loss rate is above PL_S, increase the distribution ratios as predetermined for the routes with their packet loss rate lower than PL_S.

[0119] Step S53: Make a check to see if the packet round-trip time RTT is above a preset level RTT_S, and if so, return to step S5 in FIG. 15.

[0120] Step S54: If the packet round-trip time RTT is not above RTT_S, lower the level RTT_S by a predetermined value δRTT_S and return to step S2.

[0121] Step S55: If the packet loss rate is not above the preset level PL_S in step S51, decide whether the packet return-trip time RTT is above the preset level RTT_S, and if not return to step S2.

[0122] Step S56: If the packet return-trip time RTT is above RTT_S, since the occurrence of congestion is predicted in that route as referred to previously, lower the distribution ratio for the current route by a predetermined value and increase the distribution ratios by a predetermined value for the other routes and return to step S2.

[0123] As described above, according to the fifth embodiment, it is possible to determine the distribution ratios on the basis of a different piece of route quality information for each of the multi-route packet transmission and the single-route packet transmission.

[0124] In the procedure of FIG. 16, jitter may be used in place of the packet loss rate. Since there is the possibility of temporary congestion occurring in a route with a large jitter value, the source node lower the data distribution ratio for that route by a predetermined value and raise the distribution ratios for routes with low jitter by a predetermined value.

[0125] While in the above it has been described that the packet round-trip time RTT can be used as one piece of the route quality information, the round-trip time RTT is affected by the condition of the route from the source to the destination node, and hence it is not apt as a measure of the receiving condition of the destination node. The packet one-way tip time is rather effective as a more accurate indication of the route quality information.

[0126] This embodiment utilizes the one-way trip time as the route quality information. For accurate measurement of the one-way trip time, however, it is necessary that clocks of the source node and the destination node be synchronized with each other. This embodiment utilizes GPS (Geographical Positioning System) to establish synchronization between the clocks of the both nodes in the measurement of the one-way trip time.

[0127] FIG. 18 illustrates the network configuration according to this embodiment, the parts corresponding to those in FIG. 1 being identified by the same reference numerals. The illustrated network configuration features GPS receivers 81 and 82 placed in the nodes 11 and 12, which receive a GPS signal from a satellite 90 to synchronize clocks of the nodes (clocks in computers) with the time indicated by the same GPS signal.

[0128] The one-way trip time TT for sue in this embodiment is computed by TT=Rn−TS from the timestamp (TS) 62 written by the source node in the RTP header (FIG. 3) of the RTP packet to be sent over each route and the time Rn at which the destination node received the RTP packet from each route. The destination node sends the one-way trip time TT thus obtained to the source node after writing it in an appropriate filed of RTCP-RR. The source node uses, as the quality information in each of the afore-described embodiments, the one-way-trip time TT over each route obtained from the receiver report RTCP-RR. For example, ratio of reciprocals of the one-way trip times TT for the multiple routes can be set as distribution ratio in each route.

[0129] Not only the one-way trip time but also jitter or packet loss rate can be used as the route quality information. By setting the distribution ratios for respective routes in correspondence to the route quality information as described above, it is possible to maximize the transmission rate from the source node to the destination node.

[0130] In the measurement of the one-way trip time at the destination node, the time, Ci, of reception of RTCP-SR over each route can be used. In such an instance, the one-way trip time TT can be computed from the RTCP-SR receiving time Ci and the timestamp in RTCP-SR.

Procedure of the Destination Node

[0131] FIGS. 19A, 19B and 19C show procedures which the destination node follows in each of the above-described embodiments.

[0132] FIG. 19A depicts the procedure for obtaining quality information on each route.

[0133] Step S11: Receive RTP packets from respective routes.

[0134] Step S12: Obtain each RTP packet receiving time Rn.

[0135] Step S13: Obtain from the received RTP packets the timestamps TS (FIG. 3) indicating the time of their transmission.

[0136] Step S14 Calculate the packet inter-arrival jitter J by Eqs. (1) and (2) for each route.

[0137] Step S15: Detect packet losses based on the sequence numbers SN of the received RTP packets and compute the packet loss rate for each route.

[0138] Step S16: Store the received RTP packets in a receiving buffer.

[0139] The data in the payload part is extracted by the application from the received RTP packets and used.

[0140] FIG. 19B depicts the sender report RTCP-SR receiving procedure.

[0141] Step S21: Receive the sender report RTCP-SR (FIG. 5).

[0142] Step S22: Store the RTCP-SR receiving time Ci.

[0143] Step S23: Obtain the NTP timestamp from RTCP-SR and record it.

[0144] FIG. 19C depicts the receiver report generating procedure.

[0145] Step S31: Start a timer which provides timing at time intervals δT.

[0146] Step S32: Generate a packet for the receiver report RTCP-RR.

[0147] Step S33: compute the elapsed time DLSR=Ti−Ci from the time the last sender report RTCP-SR was received (steps S22 and S23 in FIG. 19B) and the current time Ti.

[0148] Step S35: Insert in RTCP-RR the jitter J and packet loss rate obtained in steps S14 and S15 in FIG. 19A, the elapsed time DLSR and the NTP time stamp in RTCP-SR.

[0149] Step S36: Send the receiver report RTCP-RR.

[0150] The data transmission control method according to each of the above-described embodiments may preferably be implemented under computer control. As referred to previously, a program for implementing the data transmission control method under computer control also falls inside the scope of the present invention.

[0151] As will be seen from the description given of each embodiment, a data transmission unit serving as the source node which implements the data transmission control method of the invention is provided with quality information obtaining means for obtaining route quality information from the destination node, and distribution control means for adaptively changing the data distribution ratios for multiple routes on the basis of the quality information. FIG. 20 illustrates an example of the construction of the data transmission unit, which is basically similar to common computers. The data transmission unit comprises CPU (Central Processing Unit) 11A, a RAM (Random Access Memory) 11B, a hard disk 11C as a large-capacity storage, a display 11E, and a network interface card 11D connected to the edge router 21. The program having described therein the afore-mentioned data transmission control procedure of the present invention, which the source node executes, is stored in the hard disk 11D, for instance. At the time of communication the program is read out of the hard disk 11D and into the RAM 11B for execution by the CPU 11A, Accordingly, the quality information obtaining means and distribution control means in the transmission unit of the present invention are implemented by the execution of the program.

[0152] The above-described embodiments are merely illustrative of the present invention and are not intended to be limiting the invention. Needless to say, appropriate modifications and variations may be effected without departing from the scope of the spirits of the present invention.

[0153] As described above in detail, according to the present invention, multiple routes are set up between two points of data transmission and reception in a best-effort-service-type internet, and by quickly changing data distribution ratios for the multiple routes in response to ever-lasting route conditions, it is possible to avoid data loss or delay due to network faults or traffic congestion and hence provide increased throughput.