The present invention relates to a multicast node apparatus, a method of backing up a lost packet that is used for it, and a program thereof, and more particularly to an apparatus, a method, and a program that allow a wait time at the time of backing up the lost packet to be optimized in performing redundant delivery of the packet employing a multipath.
With a diffusion of broadband networks, the high-quality video delivery service, which was difficult in a conventional narrowband network, is being realized. Further, employing a multicast technology for delivering a video packet makes it possible to delivery the video packet to a large number of users while saving a server or a band of the network. The multicast transfer technology in an IP (Internet Protocol) layer, however, has the following problems.
The first problem lies in a point that employing an IP multicast transfer requires that all routers existing in a delivery path be correspondent to an IP multicast (see
The router apparatus, which is widely being used at present, is not correspondent to the IP multicast in many cases due to issues such as architecture and software.
The second problem lies in a point that there is a possibility of exerting a baneful influence upon other communication in a case where a loop occurs because the reproduction of the packet is repeated in the IP multicast network that has not been correctly set, thereby wasting the network band or resource of the router.
In consideration of such an operational reason, also in the network employing the router that corresponds to the multicast, the setting is made so that its function (multicast) is not used in may cases. For this, in launching the use of the IP multicast over the existing network,
The application-level multicast technique has been proposed so as to avoid theses problems (see
This technique can be used also in the conventional IP multicast non-correspondence network because an IP-layer unicast packet is used for communication between the application-level multicast node apparatuses.
The real time video delivery employing the IP network has the problems such as
As a rule, a streaming server, which delivers the video, sends out the packet according to the reproduction interval of the video. Assuming that a transmission delay in the network is constant, it is enough that a receiving terminal reproduces the received packet as it stands. However, the transmission delay in the network is not constant, and dispersion occurs. So as to absorb this dispersion (fluctuation) in the delay, the receiving terminal performs the buffering for the received packet for a constant time, thereby to absorb an influence caused by the dispersion. At this moment, the video is not reproduced immediately after receiving the packet, but the value obtained by adding the wait time having a transmission delay taken into consideration on the basis of a timestamp that the streaming server has affixed packet by packet at the time of the delivery is used as a timing at which the video is reproduced. This enables the reproduction of the video in the reception side to be performed at a timing identical to the timing at which the streaming server sends out the packet without being influenced by the dispersion in the transmission delay in the network.
In the IP network, a loss of the packet occurs due to various factors such as a burden of the router and a congestion of the network. A loss of the packet leads to deterioration in a reproduction quality of the video caused by omission of a frame.
The technique of Forward Error Correction employing a corrective encoding technology has been proposed for coping with this problem. This technique is a technique of redundantly pre-transmitting the packets and backing up the lost packets.
However, employing this technique arouses the following problems.
In this technique, the band of the network is excessively used because the redundant packets have to be sent out, which could raise a loss rate of the packet all the more. It is possible to restore the packets, which are lost isolatedly, at a high provability; however, the packet cannot be restored in many cases in a situation where the packets are continuously lost.
Such a situation occurs due to disconnection of a link, a failure of a relaying apparatus, or the like in the IP layer or the lower layer, and thus, it becomes impossible to cope with the packet loss only by means of the technology of the FEC under such a situation.
It is thinkable that exclusive paths that do not share the link or the node are prepared in plural for the continuous loss of the packets, and an identical packet is sent out redundantly to respective paths.
However, as a rule, a manger cannot explicitly decide the delivery path in the IP layer. Assuming that the packets are sent out redundantly, it follows that the packets pass through the identical path, so it is difficult to prevent the continuous loss. For this, this technique cannot be employed in the general IP multicast.
On the other hand, the path in communication between the nodes cannot be explicitly decided in an application-level multicast similarly to the IP multicast; however the manger can decide the node through which the packet passes.
For this, appropriately arranging the application-level multicast nodes in the network, and successively selecting the node through which the packet passes so that the link or the node through which the packet passes is not shared makes it possible to constitute an exclusive path.
An example of the multipath in the application-level multicast is shown in
Additionally, in a Patent document 1 are disclosed the method, the system, and the terminal apparatus for allowing delivery video to be simultaneously reproduced by forwarding a multicast packet including media data and information indicative of a delivery time from a video delivery server to each terminal apparatus, receiving the multicast packet in each terminal apparatus, collecting information of the delivery time and the reception time in a certain terminal, computing, for example, a maximum delivery delay time, and subtracting the delay time in each terminal apparatus from this maximum delivery delay time, thereby to obtain a wait time, which ranges from reception up to reproduction of the media data, in its own terminal apparatus.
Patent document 1: JP-P2003-235027A
As mentioned above, the conventional multicast system has the points at issue described below.
The first point at issue is that it is difficult to decide an appropriate wait time in a case of utilizing the technology of backing up the packet by the multipath.
Herein, the so-called wait time is equivalent to a value obtained by subtracting the clock time at which the packet is sent out from the transmission source from the clock time at which the packet is sent out from the node apparatus (see, for example, 66 of
Further, that the buffering time in the node apparatus is long signifies that a delay as well in the arrival of the packet is enlarged. For this reason, the wait time is desirably shortened as much as possible.
Regrettably, dispersion in the delays in respective paths could not be absorbed in a case where the wait time is short.
The transmission delay of the packet is not constant, and the dispersion occurs in the IP network. For this, with the multipath, when the packet lost in the path of which a delay is smaller has to be backed up by using the other path, there is the possibility that the packet does not arrive during the wait time due to an increase in the delay of the latter path. Hereinafter, explanation thereof will be made, based upon an investigation result by this inventor.
A timing diagram of
A packet 21 having arrived at the node apparatus via the path 1 is sent out with the value obtained by adding a wait time 66 to the timestamp, which is included in the packet, assumed to be a sending-out time (packet 41). Herein, a so-called buffering time 65 of the packet 21 in the path 1 is a value obtained by subtracting a transmission delay of the packet 21 (this time, it is a mean delay 62) from the wait time 66.
A packet 31 having arrived via the path 2 is sent out as the packet 41 instead of the packet 21 in a case where the packet 21, which is to arrive via the path 1, has been lost in the path, and has not arrived.
In an example of
Now think about the case that the packet 13 having the sequence number 619 sent out from the transmission source has been lost in the path 1. In this case, the packet is backed up by sending out the packet 33 having the sequence number 619, which is to arrive via the path 2, instead of the packet 23. However, as shown in
Shortening the wait time in such a manner raises the possibility that the packet cannot be backed up.
Thus, an object of the present invention is to provide an apparatus, a method, and a program that enable a minimum wait time to be obtained while a target packet backup rate is satisfied, and yet are preferredly employed for a node apparatus for backing up the packet using a multipath.
As a means to solve the foregoing problems, a node apparatus relating to a first aspect of the present invention includes:
a network interface that makes a connection to an network existing outside the apparatus;
a packet receiver for receiving a packet including a sequence number and a timestamp via the network interface;
a packet synchronizer for making a reference to the sequence number of the received packet, and filing only the packet having a not-filed sequence number into a transmitting buffer;
a statistics processing unit for collecting statistic information relating to a delay reception path by reception path from the received packet; and
a wait time calculator for deciding a wait time of the packet based upon the statistic information collected by the statistics processing unit.
In the present invention, the statistics processing unit obtains a mean of the delays of the packets. The statistics processing unit obtains a variance of the delays of the packets.
A backup rate of the packet is governed by two elements, i.e. a loss rate of the packet for each path in the network and a rate at which the packet arrives within the wait time. The wait time calculator prepares an arrival rate table indicative of a relation between the wait time and the arrival rate based upon a probability distribution function that is obtained from a mean and a variance of the transmission delays for each path obtained in the statistics processing unit of the present invention, and a pre-given loss rate for each path. In accordance with the present invention, a minimum wait time that satisfies a target packet backup rate (arrival rate) is obtained by employing, for example, the arrival rate table.
The node apparatus relating to another aspect of the present invention includes an arrival rate measure, thereby enabling the arrival rate (and the loss rate) of the packet to be obtained path by path in the actual network. Also in a situation where the arrival rate of the packet fluctuates, this makes it possible to obtain an appropriate wait time responding to its situation during operation of this apparatus.
The method relating to another aspect of the present invention, which is a multicast packet transfer method of receiving a packet including a sequence number and a timestamp, making a reference to the sequence number of the received packet, and sending out the packet having a not-sent sequence number at a sending-out time, includes the steps of:
collecting statistic information relating to a delay value reception path by reception path from the received packet; and
computing a wait time of the packet based upon the collected statistic information.
In the method relating to the present invention, a mean of the delays of the packets is obtained in the step of collecting the statistic information.
In the method relating to the present invention, a variance of the delays of the packets is obtained in the step of collecting the statistic information.
In the method relating to the present invention, the step of computing the wait time is a step of deciding the wait time for each reception path of the packet by employing a probability distribution function.
In the method relating to the present invention, the step of computing the wait time is a step of deciding the wait time by employing a frequency distribution relating to the delay of the packet.
In the method relating to the present invention, which further includes a step of measuring an arrival rate of the packet, the step of computing the wait time is a step of deciding the wait time by employing the measured arrival rate.
The computer program relating to another aspect of the present invention is comprised of programs for causing a computer to execute the processes of:
receiving a packet including a sequence number and a timestamp in performing a multicast transfer;
making a reference to the sequence number of the received packet, and sending out the packet having a not-sent sequence number at a sending-out time;
collecting statistic information relating to a delay value reception path by reception path from the received packet; and
computing a wait time of the packet based upon the collected statistic information.
In the computer program relating to the present invention, the process of collecting the statistic information includes a process of obtaining a mean of the delays of the packets.
In the computer program relating to the present invention, the process of collecting the statistic information includes a process of obtaining a variance of the delays of the packets.
In the computer program relating to the present invention, the process of computing the wait time includes a process of deciding the wait time by employing a probability distribution function for each reception path of the packet.
In the computer program relating to the present invention, the process of computing the wait time includes a process of deciding the wait time by employing a frequency distribution relating to the delay of the packet.
The computer program relating to the present invention is comprised of programs for causing the computer to execute the processes of:
measuring an arrival rate of the packet; and
deciding the wait time by employing the measured arrival rate.
The first effect of the present invention lies in a point that a memory quantity that is used in the buffering of the node apparatus can be minimized while a target packet backup rate is satisfied. Lessening the memory quantity necessary for the buffering makes it possible to suppress a cost of the node apparatus because the quantity of the memory that is installed into the node apparatus can be lessened. Further, employing the technique of the present invention makes it possible to treat much more stream delivery even though the quantity of the memory that is installed is identical.
The second effect of the present invention lies in a point that an accumulated delay in the packet transmission can be minimized while a target packet backup rate is satisfied. The buffering for backing up the packet is necessitated in the node apparatus that exists in a junction of the multipath, and inevitably, delay equivalent to its buffering time occurs. Further, a delay occurs to a certain extent until transmission of the received packet is finished completely in the application-level multicast node apparatus other than the node apparatus that exists in a junction of the multipath. Employing the technique of the present invention makes it possible to suppress a delay in a junction of the multipath at a minimum level.
Next, embodiments of the present invention will be explained in details by making a reference to the accompanied drawings.
In
Each of the network interfaces 151 to 15m makes a connection to a network existing outside the node apparatus.
The packet receiver 141 receives the packet via the network interfaces 151 to 15m, makes a reference to an upstream pier management table 1411, and determines a pier of the packet.
The packet of which the pier has been specified is sent to any receiving buffer, which corresponds to the upstream pier, out of the receiving buffers 121 to 12n.
The packet receiver 141 in the present invention treats the packet such as an RTP packet, in which the timestamp and the sequence number affixed at the time of sending-out the packet are included.
The so-called pier is a connection at a transport-layer protocol between the application-level multicast nodes.
The packet receiver 141 can determine that the packet is a packet received from a pier 1 by making a reference to this upstream pier management table 1411 in the case that the transmission source address, the transmission source port number, the destination address, and the destination port number of the received packet are A10, P10, A11, and P11, respectively,
For example, in a case where the destination address is signified with a wild card “*” like a pier 2 of
Herein, by employing the values that was included in an IP header and a UDP header, the upstream pier was specified; however any of the techniques, which enable the upstream pier to be specified from the received packet, may be employed. For example, it is also acceptable that a field into which a value for uniquely identifying the packet pier by pier is inserted is pre-arranged in any portion of the packet, and the upstream pier is specified with the value filed in the above field.
Upon making a reference to
The wait time calculator 131 computes the wait time of the packet based upon information such as the delay and the packet loss rate collected in the statistics processing unit 111 to 11n, and sets the computed value to the packet synchronizer 132.
The packet synchronizer 132 merges the packet streams received from a plurality of the upstream paths. At this time, the packet synchronizer 132 makes a reference to a path table 1321, specifies a downstream pier, and sends the packet to any of the corresponding transmitting buffers 161 to 16p.
In
For example, it follows
Upon making a reference to
The packet transmitter 142 makes a reference to a downstream pier management table 1421, and retrieves the transmission source address, the transmission source port number, the destination address, and the destination port number that are used in the downstream pier.
In
Upon making a reference to
The setting of the path information to the path managing unit 143 may be made manually, or the setting may be made by the network managing terminal via the network.
The real time clock 144 supplies information of the current time responding to a request by each unit of the statistics processing units 111 to 11n, the packet synchronizer 132, and the packet transmitter 142.
At first, each of counters ci, di, and si is pre-set equal to 0 (zero) (step S1).
The statistics processing unit waits for reception of the packet from a path i, makes a reference to the timestamp that is included in the received packet, and assumes its value to be ts (step S2).
A current time tn is acquired from the real time clock 144 (step S3).
A difference between the current time tn and a packet transmission time ts is computed and di is added to the obtained value. This di signifies a sum of values of the delays of respective packets. Further, the square of the difference is computed and si is added to the obtained value. This si signifies a sum of the values of the square of the delays of respective packets. Further, 1 (one) is added to ci (step S4).
Next, it is investigated whether or not the value of ci exceeds an initial-measurement packet number (step S5). The initial-measurement packet number is manually pre-given. In a case where the value of ci does not exceed the initial-measurement packet number, the operation returns to the step S2.
In a case where the value of ci has exceeded the initial-measurement packet number, the following computation is performed.
At first, a value mi that is obtained by dividing di by ci is found. This mi signifies a mean of the transmission delays of respective packets.
Further, a square root vi (=(si/ci−mi2)1/2) of the value obtained by subtracting the square of mi from the value obtained by dividing si by ci is extracted. This vi signifies a variance of the transmission delays of respective packets.
Herein, in the step 5, a loop process from the step S2 to the step S5 has been finished in a case where the number of the received packets has exceeded a predetermined value; however it may be judged that the loop process has been finished after a constant time has elapsed since starting a series of the processes.
At first, a value of 1 (one) is set to each Li (step S11). This i is an index indicative of a row of an arrival rate table of each pier.
The arrival rate table will be explained by employing
Herein, a maximum value out of the row numbers of the arrival rate table of each pier is assumed to be n. At this point, the maximum value is unknown, so it is enough to arrange a sufficiently large value, which is assumed to be n.
Li is indicative of an accumulated loss rate in an i-th row of the arrival rate table for each path.
Upon making a reference to
Next, the wait time calculator prepares an arrival rate table of the pier a from a probability distribution function by employing a mean ma and a variance va of the delays of the upstream pier a (step S13).
Herein, the probability distribution function having a normal distribution is employed; however the probability distribution function having a different distribution may be employed according to characteristics of the network.
Additionally, the arrival rate in the arrival rate table of
In a step S14 of
Herein, it is assumed that a value of the i-th row of the arrival rate table is xi, and an estimated packet arrival rate of the pier a is la, respectively, and (1−xi)×(1−la) is obtained and the obtained value is assumed to be yi.
yi is computed over all rows of the arrival rate table.
The estimated packet arrival rate la is a probability of the packet arriving without being lost in the path. For example, the estimated packet arrival rate of the path in which 5% of the packets are expected to be lost becomes 0.95.
With this estimated packet arrival rate,
yi, which is a product of a probability at which, with the path a, the packet does not arrive within the wait time, and a probability at which the packet does not arrive at the node because the packet is lost in the path a, is indicative of a loss rate in the wait time of the i-th row of the path a.
Assuming that the wait time of the i-th row of the arrival rate table of the path a is 55 ms, yi is indicative of a probability at which, with the path a, the packet does not arrive within 55 ms.
Next, Li is multiplied by a value of yi over each row i of the arrival rate table of the path a (step S15).
This Li, which is an accumulated loss rate, is indicative of a probability at which the packet does not arrive within 55 ms through any of the paths processed up to this point if it is assumed that the wait time of the i-th row of the arrival rate table is 55 ms.
Next, it is assumed that the upstream pier a has already been processed (step S16), and it is investigated whether or not the other not-processed upstream pier still remains (step S17). In a case where the other not-processed upstream pier still remains, the operation returns to the step S12.
In a case where the process has been finished for all upstream piers, an entire arrival rate table is prepared by employing Li obtained in the computation performed up to this point.
At this time, it is assumed that 1−Li is an arrival rate in the i-th row of the entire arrival rate table (step S18).
Next, a minimum value dt, out of the delay values exceeding a target arrival rate lt, is obtained from the entire arrival rate table (step S19).
The obtained dt is set to the packet synchronizer (step S20).
The packet synchronizer waits for reception of the packet (step S21).
Upon receipt of the packet, the packet synchronizer acquires a sequence number q and a timestamp ts that are included in its packet (step S22).
The packet synchronizer scans the transmitting buffer, and confirms whether or not the packet having an identical sequence number exists (step S23).
In a case where the packet having an identical sequence number exists in the transmitting buffer, the above packet is canceled (step S24), and the operation returns to the step S21.
In a case where the packet having an identical sequence number does not exist in the transmitting buffer, ts+ds is calculated, and the obtained value is assumed to a transmission schedule time to (step S25)
Next, the current time tn is acquired from the real time clock 144 (step S26).
It is investigated whether or not the current time tn is behind the transmission schedule time to (step S27), and in a case where it is behind, the operation returns to the step S24.
In a case where the current time tn is not behind the transmission schedule time to, the packet synchronizer sends the packet to the transmitting buffer (step S28), and sets the transmission schedule time of the sent packet to the transmitting buffer (step S29).
Next, a second embodiment of the present invention will be explained.
In the foregoing first embodiment shown in
On the other hand, in the second embodiment of the present invention, each of the arrival rate measures 181 to 18n measures the actual packet loss rate path by path, thereby enabling more appropriate wait time responding to a fluctuation in a situation of the network to be obtained.
Next, a third embodiment of the present invention will be explained.
A frequency distribution table is prepared by collecting the packet number for each class width of the transmission delay sectioned for each constant space. An example of the frequency distribution table and an example of the accumulated frequency distribution table are shown in
Next, a procedure of preparing the arrival rate table from the frequency distribution table in this embodiment will be explained by making a reference to a flowchart of
At first, 0 (zero) is set to c, and 1 (one) to i, respectively (step S31). Herein, i is a variance indicative of a row in the frequency distribution table.
Next, a value of fi is added to c. fi is indicative of the packet number of the i-th row of the frequency distribution table. Next, 1 (one) is added to i (step S32)
c is registered to an entry of the accumulated packet number of the i-th row of the accumulated frequency distribution table (step S33). The accumulated frequency distribution table shown in
Next, it is investigated whether the computation for all rows of the frequency distribution table has been finished, and if it has not finished yet, the operation returns to the step S32 (step S34).
In a case where the computation for all rows has been finished, the operation proceeds to a step S35. At this time point, a value of c is indicative of a sum of the packet numbers collected in the frequency distribution table.
Next, 0 (zero) is substituted into r, and 1 (one) into i, respectively (step S35).
Next, a value obtained by dividing fi by c is substituted into r. Further, 1 (one) is added to i (step S36).
r is registered to an entry of the arrival rate of i-th row of the arrival rate table (step S37).
It is investigated whether the computation for all rows of the accumulated frequency distribution table (
In a case where the computation for all rows has been finished, the operation comes to an end.
The procedure of computing the wait time from the arrival rate table obtained herein is similar to that of the first embodiment of the present invention.
In the first embodiment explained by making a reference to
In this embodiment, the sole actual operation is division alone in the step S36 of
The present invention is preferredly employed for a live video delivery employing in IP network.
Above, while the present invention was explained according to the above-mentioned examples thereof, the present invention is not limited to the configurations of the above-mentioned examples, and needless to say, the scope of the present invention includes various alterations to, and variations of these examples that those skilled in the art may readily carry out.
Number | Date | Country | Kind |
---|---|---|---|
2005-248263 | Aug 2005 | JP | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/JP2006/316674 | 8/25/2006 | WO | 00 | 2/26/2008 |