JP2001136195A - Method for compensating packet loss on user datagram protocol - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method for compensating a packet loss on a user datagram protocol that compensates the packet loss caused when transmitting data, in more detail, transmitting audio data and video data by a UDP. SOLUTION: The packet transmission method using an RTP header on the user datagram protocol includes a step (a) where a transmitter side adds a prescribed header to the RTP header and transmits the resulting header to a receiver side, a step b where the receiver side stores a packet arrival time on the header to calculate an average delay time between packets, a step c where the receiver side makes a request to the transmitter side for re- transmission of packets whose packet transmission time exceeds the average delay time, and a step d where the transmitter side executes the retransmission of the requested packet for the receiver side.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a data transmission method, and more particularly, to a user datagram communication protocol (User D).
The present invention relates to a method for compensating for a packet loss according to a user datagram communication protocol for compensating for a packet loss occurring at the time of transmitting audio data or video data by using an atagram protocol (hereinafter referred to as UDP).

[0002]

2. Description of the Related Art UDP is a layer of the Internet communication protocol, and is a transmission control protocol.
tocol (TCP) together with the International Standards Organization:
Open System Interconnection (Open Sys.) Defined by ISO
tems Interconnection (OSI) corresponds to the fourth lowest transport layer in the seven reference model layers. TC
P is a connection-oriented communication protocol for setting a communication path in advance for data transmission, while UDP is characterized as a communication protocol that does not use connection called datagram.

[0003] As described above, data transmission using UDP requires:
Since a datagram, which is a communication protocol that does not use connection, is used, there is a problem that smooth data communication is difficult without any compensation method for a packet loss in which data once transmitted does not arrive at a destination. In order to solve the problems of the conventional technology, real-time control communication protocol (Real
There is a method using Time Control Protocol (RTCP). However, this method provides information on packet loss, and since there is no compensation for lost packets, smooth data communication is still difficult. there were.

[0004]

The technical problem to be solved by the present invention is to predict the time of the next packet to be received by the average value of the packet reception time, and the packet must arrive within that time. For example, it is an object of the present invention to provide a method for compensating for a packet loss on a user datagram communication protocol that requires retransmission of the packet.

[0005]

SUMMARY OF THE INVENTION To solve the technical problem to be solved by the present invention, a method of compensating for packet loss on a user datagram communication protocol is described in RTP on a user datagram communication protocol. In the packet transmission method using the header, (a) the RTP is transmitted from the transmission side to the reception side.
Transmitting a header by adding a predetermined header to the header,
(B) storing a packet arrival time on the header at the receiving side and calculating an average delay time between packets;
(C) obtaining a retransmission of a packet whose packet transmission time has passed the average delay time from the receiving side to the transmitting side; and (d) determining a retransmission of the packet obtained from the transmitting side to the receiving side. And performing a retransmission.

[0006]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the attached drawings. FIG. 1 is a flowchart illustrating an operation of a method for compensating for a packet loss according to a user datagram communication protocol according to the present invention. In the flowchart shown in FIG. 1, the transmitting side transmits two additional headers to a Real Time Protocol (RTP) header from the transmitting side to the receiving side, and a packet arrives at the receiving side. Storing the calculated time and calculating and storing an average delay time between packets; determining whether the packet transmission time has exceeded the average delay time;
A step of waiting for packet transmission until the average delay time; a step of requesting the transmitting side to retransmit a packet having exceeded the average delay time; a step of retransmitting the packet obtained from the transmitting side to the receiving side; It comprises a step 16 of judging whether or not it is over.

FIG. 2 is a diagram showing a header format according to the real-time communication protocol according to the flowchart of FIG. Next, the present invention will be described in detail with reference to FIGS. FIG. RTP described in 225.0
This is a header format. The version is a 2-bit field indicating the RTP version. For example, the current version indicates 2 (V = 2). Padding is
This is a 1-bit field indicating an additional padding octet, and is mainly used for encryption. Extension is a 1-bit field indicating RTP head extension.

[0008] CSRC number (CC: Contributing source C
mount) is a 4-bit field that describes the number of CSRCs. If the CSRC number does not support the RTP mixer, 4 bits are set to 0. Generally, CC stands for Mixer Multi Conference
Indicates the number of fields used in the function of processing the sources received from various terminals and distributing the processed sources to the terminals. However, in the one-to-one data transmission, it becomes 0 and is not used. In the present invention, CCs and CSRC lists which are not generally used are used as fields for compensating for packet loss.

The marker M is a 1-bit field mainly indicating a boundary between video frames. H. When using H.261, there is no way to indicate the marker field since the data stream transmitted from the codec board to the system does not indicate the boundaries between frames. Therefore, it is defined by 1 bit. The mounting type is a 7-bit field indicating the mounting type of each audio / video data.

[0010] The sequence number is a 7-bit field that specifies the sequence number for the data packet to be transmitted.
The sequence number is incremented by one each time a data packet is sent. Therefore, the receiving side can confirm the sequence number and know the loss of the data packet. The time stamp is indicated by 16 bits in a time field required for synchronization on the receiving medium itself or between the media or for jitter calculation. Timestamps are supported in milliseconds, ms
ec with synchronization accuracy.

The SSRC identifier (Synchronization source)
identifier) is an identifier for identifying a synchronization source in the same session, and is the MD5 of RFC1321.
A 32-bit random number identifier is generated using a routine.
It also includes a mechanism that can resolve the occurrence of identifier collision.
In the present invention, an additional header for packet compensation is added as shown in FIG. On the transmitting side, two headers are added to the RTP header and transmitted.

Table 1 below shows the added header C and CM.
The item assigned to the D bit is described.

[0013]

[Table 1]

The length of the additional header is a field indicating the number of data packets to be retransmitted, and is meaningless when C = 0. However, when C = 1 and CMD = 1 of the additional header, it is possible to request retransmission of the number of data packets whose size is equal to the length from the sequence number (Sequence No.). C = 0 of additional header
In this case, the sequence number of the first field of the RTP header is the same as the sequence number of the additional header. When C = 1 and CMD = 1 of the additional header, the sequence number of the additional header is
This is the first value of the data packet sequence number for which retransmission is required.

The time of the additional header is the time at which the transmitted packet arrived at the receiving side, and is indicated in units of msec.
FIG. 1 together with the added header of FIG. 2 is as follows. The transmitting side adds two headers to the RTP header to the receiving side and transmits (10 steps). RT as shown in FIG.
Two headers are added to the P header and transmitted. 4 in FIG.
If CC indicating a bit is set at 2, the CSRC list will have two 32 bits added to the RTP header. The transmission side records C = 0, CMD = 0, and real-time information in the additional header transmitted to the reception side, and transmits it.

The receiving side stores the data packet arrival time and calculates and stores the average delay time between data packets (step 11). On the receiving side, msec of the added header
Check and store the data packet arrival time according to the time. The receiving side obtains the average delay time from the previously transmitted data packet, the currently transmitted data packet, and the arrival time of the data packet to be transmitted from now on, and calculates the average delay time every time each data packet arrives. Upgrade and maintain the average delay time.

It is determined whether the data packet transmission time has exceeded the average delay time (step 12). This is determined from the difference between the data packet transmission time and the average delay time.
If the data packet transmission time does not exceed the average delay time, wait for the data packet transmission until the average delay time (13).
Stage). If the data packet transmission time exceeds the average delay time, the transmitting side requests retransmission of the data packet having exceeded the average delay time, and the transmitting side retransmits the data packet obtained from the receiving side (steps 14 and 15). .

For example, the receiving side should receive P4. When receiving P5, the receiving side calculates P3 and calculates the delay time at the time of receiving P5. , But otherwise P
4 requires retransmission. At this time, the receiving side transmits information of C = 1, CMD = 1, Length = 1, Sequence No = 4 to the transmitting side. Upon receiving this, the transmitting side searches for P4 from its own transmission buffer (not shown) and finds C = 0, CMD =
A P4 packet is transmitted together with 1, Length = 1 and Sequence No = 4.

If some (eg two) packets P
4. If P5 is lost, the receiving side sends C =
1, CMD = 1, Length = 2, and Sequence No = 4 are transmitted. Upon receiving this, the transmitting side searches for P4 and P5 from its own transmission buffer (not shown) and finds C = 0, CM
A P4 packet is transmitted together with D = 1, Length = 1, Sequence No = 4, and again C = 0, CMD = 1, Length = 1,
A P5 packet is transmitted together with Sequence No = 5.

It is determined whether the packet retransmission has been completed (step 16). If the packet retransmission fails, the receiver asks the sender to transmit the unretransmitted packet. For example, if the retransmission of the packet P5 fails, the receiving side sends C = 0, CMD = 2, Length = 1, Sequence
If No = 5 is transmitted, the transmitting side searches for the P5 packet and retransmits it to the receiving side. The present invention is not limited to the embodiments described above, and can be modified by those skilled in the art within the spirit of the present invention.

[0021]

As described above, according to the present invention, UDP
By compensating for the packet loss generated above, there is an effect that the packet loss can be actually controlled to a minimum while the overhead on the network is minimized.

[Brief description of the drawings]

FIG. 1 is a flowchart illustrating an operation of a method for compensating for a packet loss according to a user datagram communication protocol according to the present invention.

FIG. 2 is a diagram illustrating a format of a header according to a real-time communication protocol according to the flowchart of FIG. 1;

Claims (4)

[Claims] 1. An RTP protocol based on a user datagram communication protocol.
A packet transmission method using a header, wherein: (a) transmitting a RTP header with a predetermined header added from a transmission side to a reception side; and (b) storing a packet arrival time on the header at the reception side. Calculating an average delay time between packets; (c) obtaining a retransmission of a packet having a packet transmission time exceeding the average delay time from the receiving side to the transmitting side; Performing a retransmission of the packet requested from the transmitting side to the receiving side, the method comprising compensating for a packet loss according to a user datagram communication protocol. 2. The user datagram communication according to claim 1, further comprising the step of: (e) requesting a packet which has not been retransmitted since the execution of the step (d) to transmit again. A method of compensating for packet loss according to the rules. 3. The method according to claim 1, wherein the header transmitted in the step (a) comprises the number of packets to be retransmitted, a sequence number of a packet to be retransmitted, a packet arrival time, and a control bit. 2. A method for compensating for packet loss according to the user datagram communication protocol described in 1. 4. The user datagram according to claim 1, wherein the average delay time calculated in the step (b) is upgraded to the latest average delay time every time a packet arrives. A method of compensating for packet loss according to the communication protocol.