JP4433281B2 - Receiving apparatus and method, recording medium, and program - Google Patents

Description

The present invention, receiving devices and methods, record medium, and a program, in a data communication streaming, a retransmission request notification packet to loss packets By so as to effectively reach the transmitting side, the streaming improve the reliability of data communication type, receiving apparatus and method capable of performing high data communication quality, record medium, and a program.

  In recent years, services that transmit and provide image data or audio data via various communication media such as the Internet are generally performed. In particular, in recent years, in addition to download-type communication system services, more stream-type communication system services have been provided.

  In a download-type communication method service, a receiving device receives a file storing image or audio data transmitted from a transmitting device, and records the received file on its own recording medium. After the recording of the file is completed, the receiving device reproduces an image or sound based on the recorded file. In the download type communication method service, the image or sound cannot be played until the file recording is completed. Therefore, the download type communication method service is suitable for long-time playback or real-time playback. Absent.

  On the other hand, in a stream-type communication system service, a receiving device receives data transmitted from a transmitting device, and in parallel, reproduces an image or sound based on the received data. The stream type communication method is used for Internet services such as Internet telephone, remote video conferencing, and video on demand.

  In a stream type communication system, data transmitted from a transmission device is generally referred to as streaming data.

  As a more specific example, the stream-type communication method uses an Internet protocol (IP) packet that stores an MPEG stream generated by applying MPEG (Moving Picture Experts Group) encoding processing to image data. Used in systems that transmit through. In this system, a receiving device such as a PC (Personal Computer), a PDA (Personal Digital Assistance), or a mobile phone receives an IP packet and reproduces an image.

  The stream-type communication method is suitable for real-time communication such as video-on-demand or live video streaming distribution, video conferencing, or videophone.

  As one of the technologies of such a stream type communication method, there is RTP (Real time Transport Protocol) which is a protocol defined by IETF RFC (Internet Engineering Task Force Request For Comments) 1889.

  In data communication based on RTP, a time stamp indicating the time is added to the packet, and the time relationship between the transmitting side and the receiving side is grasped by referring to the time stamp. ) And the like are eliminated, and synchronized playback becomes possible.

  However, RTP does not guarantee real-time data transmission. In other words, the priority, setting, and management of packet transfer are not within the scope of transport services provided by RTP, so there is a possibility that delay and packet loss may occur on the network as with other types of packets. .

  Even if a delay or packet loss occurs, the receiving side can reproduce data using only the packets received up to the reproduction time. In other words, even if some loss or error occurs in the data, the receiving apparatus reproduces the data with reduced quality or corrects the data loss or error and reproduces it.

  In this case, a packet that arrives late without being reproduced or a packet in which an error has occurred is discarded as it is on the receiving side. That is, even if high quality data is transmitted, packet loss, errors, packet arrival delays, and the like occur, so that the reproduction quality on the receiving side is not guaranteed.

In particular, when it is said that there are errors of 10 ⁻⁵ or more in the wired section and 10 ⁻³ or more in the wireless section, using the RTP as it is is not reliable for maintaining the quality of the transfer data.

  As a proposal for solving such problems in data communication according to RTP, a method of performing packet retransmission request and packet retransmission according to TCP (Transmission Control Protocol), which is a more reliable communication protocol in data communication, can be considered. .

  However, in TCP, when a packet loss occurs, the packet is retransmitted, so it is resistant to errors, but the throughput is low and the delay is large, so the receiving side cannot receive the retransmitted packet in time for the playback time. There is a possibility, it is not suitable for real-time communication.

  Therefore, a technique such as ARQ (Automatic Repeat reQuest) with a small delay between transmission and reception is required.

  In this method, a lost packet is detected using a sequence number set in an RTP packet, and a retransmission of the lost packet is requested from the receiving terminal to the transmitting terminal.

  For example, as the retransmission processing timing, the loss packet detection processing is executed at various timings such as the last packet reception of each frame, the reception of the first packet of each frame, the final processing deadline, and every predetermined interval, and a retransmission request is made. In some cases, the data receiving terminal considers the reproduction processing time and the propagation delay time, and does not execute the retransmission request processing when it is not in time for the reproduction processing. (See Patent Document 1)

JP 2003-169040 A

  However, with regard to the ARQ mentioned above, the packet itself requesting retransmission of the lost packet may be lost on the network, and the retransmission process of the lost packet that was requested to be retransmitted by the packet may not be performed. Reliability was not enough.

  The present invention has been made in view of such a situation, and a packet requesting retransmission of a lost packet reaches a partner (transmitting apparatus) with a high probability.

In the receiving apparatus of the present invention, when a packet cannot be normally received, the request level indicating the urgency of receiving the packet that has not been normally received is stored in the current time and the packet that has not been normally received. Request level judgment means for judging by dividing the reproduction grace time calculated from the packet time stamp information or sequence number by a predetermined value, which is a difference from the streaming data reproduction scheduled time, and cannot be received normally a retransmission request notification packet to request retransmission of the packet, characterized in that it comprises a retransmission request notification transmission control means for performing in accordance with the required level of control in the case of transmitting the transmit device.

  The retransmission request notification transmission control means can determine the number of transmission packets for transmitting the retransmission request notification packet according to the request level, and transmit the retransmission request notification packets for the determined number of transmission packets.

In the receiving method of the present invention, when a packet cannot be received normally, the request level indicating the urgency of receiving the packet that could not be received normally is stored in the current time and the packet that could not be received normally. A request level determination step that is a difference from the scheduled reproduction time of the streaming data and is determined by dividing the reproduction grace time calculated from the packet time stamp information or the sequence number by a predetermined value, and cannot be received normally a retransmission request notification packet to request retransmission of the packet, characterized in that it comprises a retransmission request notification transmission control step of performing according to the request level control in the case of transmitting the transmit device.

Program recorded in record medium of the present invention, can not be received if not received the packets normally, a request level representing the urgency of the reception not normally received packet, normally the current time Request level determination step for determining by dividing a reproduction grace time calculated from the time stamp information or sequence number of the packet by a predetermined value, which is a difference from the scheduled reproduction time of the streaming data stored in the packet when, characterized in that it comprises a retransmission request notification transmission control step of performing a retransmission request notification packet to request retransmission of the not normally received packet, according to the request level control in the case of transmitting the transmit device.

Program of the present invention is stored correctly if unable to receive the packet, the request level representing the urgency of the reception of the normally not received packets, in not received correctly and the current time the packet A request level determination step that is a difference from the scheduled reproduction time of the streaming data and is determined by dividing the reproduction grace time calculated from the packet time stamp information or the sequence number by a predetermined value, and cannot be received normally a retransmission request notification packet to request retransmission of packets, to perform the retransmission request notification transmission control step of performing according to the request level control in the case of transmitting the transmit device to the computer.

Receiving apparatus and method of the present invention, record medium, in the sequence in program, if not received the packets normally, the request level representing the urgency of the received that could not be normally received packet, and the current time This is the difference from the scheduled playback time of the streaming data stored in the packet that could not be received normally, and is determined by dividing the playback grace time calculated from the packet time stamp information or sequence number by the predetermined value Then, control in the case where a retransmission request notification packet requesting retransmission of a packet that could not be normally received is transmitted to the transmission apparatus is performed according to the request level .

  The reception device may be an independent device or a block that performs reception processing of the communication device.

  According to the present invention, transmission of a packet requesting retransmission can be controlled according to the urgency of receiving a lost packet, and the probability of receiving a lost packet by the reproduction time can be increased. As a result, highly reliable data communication and high-quality media reproduction can be realized in streaming data communication.

  The present invention can be applied to a communication system that transfers streaming data in real time, such as an Internet telephone, a remote video conference system, and a live video streaming distribution system.

  FIG. 1 is a block diagram showing a configuration example of an embodiment of a communication system to which the present invention is applied.

  In FIG. 1, the communication system is configured by connecting a transmission side terminal 12 and a reception side terminal 14 via an IP network 13.

  The video camera 11 captures a moving image and supplies image data and audio data to the transmission side terminal 12.

  Image data and audio data are examples of streaming data. The streaming data may be data that is sequentially requested to be transmitted or received in accordance with the passage of time, such as real-time control data.

  The transmission side terminal 12 stores the data supplied from the video camera 11 in a packet and transmits it to the reception side terminal 14 via the IP network 13.

  The receiving side terminal 14 receives the packet transmitted from the transmitting side terminal 12 via the IP network 13, extracts the data stored in the packet, and restores it to image data or audio data.

  The reception side terminal 14 requests retransmission to the transmission side terminal 12 when there is a packet that cannot be normally received in the packet in which the streaming data continuously transmitted from the transmission side terminal 12 is stored. The transmission side terminal 12 retransmits the packet corresponding to the request from the reception side terminal 14.

  The transmission side terminal 12 includes an encoder 21, a buffer 22, an RTP packet creation unit 23, an RTP output port 24, a communication unit 25, an RTCP input / output port 26, an RTCP packet analysis unit 27, an ARQ analysis unit 28, and an RTCP packet creation unit 29. Consists of

  The encoder 21 encodes data supplied from the video camera 11. The data encoded by the encoder 21 is supplied to the buffer 22 and stored.

  The RTP packet creation unit 23 periodically reads the data stored in the buffer 22, creates an RTP packet, and supplies it to the communication unit 25 via the RTP output port 24.

  In addition, when transmission of all data stored in the buffer 22 is completed, the RTP packet creation unit 23 instructs the RTCP packet creation unit 29 to create an EOS (End Of Stream) packet.

  The RTP output port 24 supplies the RTP packet supplied from the RTP packet creation unit 23 to the communication unit 25.

  The communication unit 25 creates an IP packet based on the RTP packet supplied from the RTP packet creation unit 23 via the RTP output port 24 and transmits the IP packet to the receiving terminal 14 via the IP network 13.

  In addition, the communication unit 25 receives an IP packet transmitted from the receiving terminal 14 via the IP network 13 and supplies the IP packet to the RTCP packet analysis unit 27 via the RTCP input / output port 26.

  The RTCP input / output port 26 supplies the RTCP packet supplied from the communication unit 25 to the RTCP packet analysis unit 27.

  The RTCP packet analysis unit 27 analyzes the header portion of the RTCP packet supplied via the RTCP input / output port 26, and determines whether the RTCP packet is a retransmission request notification packet for requesting retransmission of the packet. When the RTCP packet analysis unit 27 determines that the RTCP packet is a retransmission request notification packet, the RTCP packet analysis unit 27 supplies the data portion of the retransmission request notification packet to the ARQ analysis unit 28.

  The ARQ analysis unit 28 acquires information necessary for packet retransmission processing, such as a sequence number indicating a packet requested by the retransmission request notification packet, from the data portion of the retransmission request notification packet supplied from the RTCP packet analysis unit 27. The RTP packet creation unit 23 is instructed to retransmit the packet.

  The RTCP packet creation unit 29 creates an EOS packet in accordance with the EOS packet creation instruction from the RTP packet creation unit 23 and supplies the EOS packet to the communication unit 25 via the RTCP input / output port 26.

  The receiving terminal 14 includes a communication unit 31, an RTP input port 32, an RTP packet analysis unit 33, a buffer 34, an index list 35, a decoder 36, an ARQ processing unit 37, an RTCP packet creation unit 40, an RTCP input / output port 41, and an RTCP The packet analysis unit 42 is configured.

  Further, the ARQ processing unit 37 includes a packet loss detection unit 38 and a NACK packet transmission number determination unit 39.

  The communication unit 31 receives various packets transmitted from the transmission side terminal 12 via the IP network. When the received packet is an RTP packet, the RTP packet analysis unit 33 receives the RTP packet via the RTP input port 32. To supply. Further, when the received packet is an RTCP packet, the communication unit 31 supplies the RTCP packet to the RTCP packet analysis unit 42 via the RTCP input / output port 41.

  Further, the communication unit 31 creates an IP packet based on the RTCP packet that is a retransmission request notification packet supplied from the RTCP packet creation unit 40 via the RTCP input / output port 41, and transmits the IP packet via the IP network 13. Transmit to the terminal 12.

  The RTP input port 32 supplies the RTP packet supplied from the communication unit 31 to the RTP packet analysis unit 33.

  The RTP packet analysis unit 33 analyzes the RTP packet supplied from the communication unit 31 via the RTP input port 32 and determines whether or not the received RTP packet is normal. When the received RTP packet is abnormal (when it is not normal), the RTP packet analyzing unit 33 discards the RTP packet. Further, when the received RTP packet is normal, the RTP packet analyzing unit 33 divides the RTP packet into a header part and a data part, the data part to the buffer 34, and the header part to the index list 35 and This is supplied to the packet loss detection unit 38.

  The buffer 34 temporarily stores the data part of the RTP packet supplied from the RTP packet analysis part 33.

  The index list 35 temporarily stores the header part of the RTP packet supplied from the RTP packet analysis unit 33. At this time, the index list 35 stores the address in the buffer 34 of the data part corresponding to the header part in association with the header part.

  The decoder 36 reads the data of the necessary data part from the buffer 34 based on the header information of the header part periodically accumulated in the index list 35 and performs the decoding corresponding to the encoder 21 of the transmission side terminal 12. . Then, the decoder 36 outputs the data obtained by the decoding to the display 15 or the speaker 16.

  The packet loss detection unit 38 constituting the ARQ processing unit 37 determines the packet loss check timing based on the header information of the header part of the RTP packet supplied from the RTP packet analysis unit 33, and is stored in the index list 35. Analyzes the header information of the RTP packet that is received and determines whether there is any packet loss. When packet loss is detected (when it is determined that there is a packet loss), the packet loss detection unit 38 supplies information indicating the lost packet to the NACK packet transmission number determination unit 39.

  The NACK packet transmission number determination unit 39 constituting the ARQ processing unit 37 transmits the number of retransmission request notification packets for requesting retransmission of a lost packet based on the information indicating the lost packet supplied from the packet loss detection unit 38. The RTCP packet creation unit 40 is supplied with information indicating the number of retransmission request notification packets transmitted together with information indicating lost packets.

  The RTCP packet creation unit 40 creates a retransmission request notification packet (RTCP packet) based on the information supplied from the NACK packet transmission number determination unit 39, and only the transmission number determined by the NACK packet transmission number determination unit 39. , And supplied to the communication unit 31 via the RTCP input / output port 41. Hereinafter, the retransmission request notification packet is appropriately referred to as a NACK packet. Details of the NACK packet will be described later.

  The RTCP input / output port 41 supplies the RTCP packet (NACK packet) supplied from the RTCP packet creation unit 40 to the communication unit 31. The RTCP input / output port 41 supplies the RTCP packet (EOS packet) supplied from the communication unit 31 to the RTCP packet analysis unit 42.

  The RTCP packet analysis unit 42 analyzes the RTCP packet supplied from the communication unit 31 via the RTCP input / output port 41. When the RTCP packet is an EOS packet indicating the end of streaming data, the transmission side terminal 12 It recognizes that the transmission of the streaming data is completed.

  FIG. 2 is a diagram for explaining an RTP packet that is a packet in which streaming data is stored in the transmission side terminal 12 and transmitted to the reception side terminal 14.

  The header part of the RTP packet is composed of fields of version number, padding, extension bit, counter, marker_bit, payload type, sequence number, TIMESTAMP, synchronization source identifier, and contribution source identifier.

  The version number field is a 2-bit area, and the version number described therein represents the version of the RTP packet.

  The subsequent padding is a 1-bit area in which 0 is set, for example.

  The extension bit field is a 1-bit area, and the extension bits described therein indicate the presence or absence of an extension header.

  The counter field is a 4-bit area, and counter described therein represents the set number of contributing source identifiers.

  The marker_bit field is a 1-bit area, and the marker_bit described therein is defined by a profile.

  The payload type field is a 7-bit area, and the payload type described therein is information for defining the format of the RTP payload.

  The sequence number field is a 16-bit area, and the sequence number described therein represents the order of packets. The sequence number is information that increases by one each time an RTP packet is transmitted. The sequence number is used to detect packet loss and repair the order of received RTP packets.

  The TIMESTAMP field is a 32-bit area, and TIMESTAMP described therein is information indicating the time when the first octet of streaming data stored in the RTP packet is sampled.

  The synchronization source identifier field is a 32-bit area, and an identifier indicating a transmission source is set in the synchronization source identifier described therein.

  The contribution source identifier is a 32-bit area, and a maximum of 15 contribution source identifiers can be set as the contribution source identifier described therein. The set number of contribution source identifiers is set in the above counter. As the contribution source identifier, when there are a plurality of transmission sources, the above-mentioned synchronization source identifier set in each packet is set by the mixer through which the packet transmitted from each transmission source passes. At this time, an identifier indicating the mixer is set as the synchronization source identifier.

  In FIG. 2, “Payload” following the header portion including the above fields indicates streaming data.

  FIG. 3 is a diagram for explaining a NACK packet as a retransmission request notification packet transmitted from the receiving terminal 14 to the transmitting terminal 12.

  The NACK packet includes a version number, padding, FORMAT, PayloadType, packet length, transmission synchronization source identifier (RTCP), and TIMESTAMP information, as well as a retransmission specified sequence number that is a sequence number indicating the packet that is a retransmission request target, and a retransmission request. The number of times, an option (OPTION), and the number of times of duplication can be set.

  Since the version number and padding are the same as the version number and padding in the RTP header portion of FIG. 2, description thereof is omitted here.

  In this embodiment, regarding the distinction between control messages such as NACK packets and EOS packets, they are not distinguished only by PayloadType of the RTCP header, but are distinguished using PayloadType and FORMAT.

  A value indicating a NACK packet, an EOS packet, or the like is set in FORMAT, and a value indicating a control message is set in PayloadType.

  As shown in FIG. 3, in one NACK packet, it is possible to set one or more sequence numbers of packets to be retransmitted as retransmission designation sequence numbers (in FIG. “Specified sequence number” represents this).

  Further, the number of retransmission requests added to each sequence number of a packet to be retransmitted is a field indicating the number of retransmission requests for a packet corresponding to the sequence number, and the number of times of duplicate designation Is a field for designating the number of retransmissions of the same packet when the transmission side terminal 12 retransmits. OPTION is used as a field for storing other arbitrary information. In the OPTION, arbitrary information can be stored, and the transmission side terminal 12 can execute processing according to the set value.

  For example, when 3 is set as the number of times of duplication designation, it is possible to cause the transmitting side terminal 12 that has received a NACK packet to transmit a packet requested to be retransmitted by the NACK packet three times.

  In addition, by setting the number of retransmission requests as the number of retransmission requests, the transmitting terminal 12 can recognize that the NACK packet itself has been lost.

  FIG. 4 is a diagram for explaining an EOS packet transmitted from the transmission side terminal 12 to the reception side terminal 14.

  The EOS packet is composed of a version number, padding, FORMAT, payload type, packet length, transmission synchronization source identifier (RTCP), and TIMESTAMP. Each field constituting the EOS packet is the same as each field of the NACK packet shown in FIG.

  Next, packet transmission processing in the transmission side terminal 12 of FIG. 1 will be described with reference to the flowchart of FIG.

  In step S11, the encoder 21 encodes the data supplied from the video camera 11. For example, the encoder 21 encodes the supplied image data by a method such as MPEG (Moving Picture Experts Group) and stores the encoded image data in the buffer 22. The RTP packet creation unit 23 reads the encoded data stored in the buffer 22, creates an RTP packet in which the encoded data is arranged in Payload (FIG. 2), and supplies the RTP packet to the communication unit 25 via the RTP output port 24. To do. An RTP packet is an example of a packet used when transferring streaming data.

  Proceeding from step S11 to step S12, the communication unit 25 creates an IP packet based on the RTP packet supplied from the RTP packet creation unit 23 via the RTP output port 24, and then proceeds to step S13. In step S13, the communication unit 25 transmits the created IP packet to the receiving terminal 14 via the IP network 13, and proceeds to step S14.

  In step S <b> 14, the RTCP packet analysis unit 27 determines whether or not a NACK packet has been received from the receiving terminal 14. If it is determined in step S14 that a NACK packet has not been received, the process proceeds to step S15, where the RTP packet creation unit 23 determines whether transmission of all data to be transmitted has been completed.

  If it is determined in step S15 that transmission of all data to be transmitted has not been completed, the process returns to step S11, and RTP packet transmission processing is repeated until transmission of all data to be transmitted is completed.

  On the other hand, when it is determined in step S14 that the NACK packet has been received, that is, the NACK packet transmitted from the receiving terminal 14 is received by the communication unit 25 and is transmitted through the RTCP input / output port 26 to the RTCP packet analysis unit. When supplied to 27, the packet analysis unit 27 supplies the NACK packet to the ARQ analysis unit 28, and proceeds to step S16.

  In step S16, the ARQ analysis unit 28 analyzes the data part of the NACK packet supplied to the RTCP packet analysis unit 27, and is necessary for packet retransmission processing such as the sequence number of the packet requested to be retransmitted by the NACK packet. Such information is acquired and the RTP packet creation unit 23 is instructed to perform retransmission processing.

  In step S16, the ARQ analysis unit 28 sets a timer, and when a plurality of NACK packets including a sequence number indicating the same packet are received within a certain time, at the time when the first NACK packet is received. Then, the RTP packet creation unit 23 is instructed to retransmit the packet requested to be retransmitted, and then ignores the sequence number indicating the same packet included in the received NACK packet until the timer finishes counting for a certain period of time. Thus, it is also possible to control retransmission of a packet requested to be retransmitted.

  In this case, even if one or more NACK packets requesting retransmission of the same packet are received within a certain time, the packet is retransmitted only once, and an increase in useless traffic can be prevented. .

  Proceeding from step S16 to step S17, the RTP packet creation unit 23 sends data corresponding to the retransmission request (data requested to be retransmitted by the NACK packet) from the buffer 22 in accordance with the retransmission processing instruction input from the ARQ analysis unit 28. Extract and proceed to step S18.

  In step S18, the RTP packet creation unit 23 creates an RTP packet storing the data extracted from the buffer 22 in step S17, supplies the RTP packet to the communication unit 25 via the RTP output port 24, and proceeds to step S19.

In step S19, the communication unit 25 creates an IP packet based on the RTP packet supplied from the RTP packet creation unit 23 via the RTP output port 24, and proceeds to step S20. The packet is transmitted to the receiving terminal 14 via the IP network 13. Thereafter, the process returns to step S14, and the same processing is repeated thereafter.

  On the other hand, when it is determined in step S15 that transmission of all data to be transmitted is completed, the process proceeds to step S21, and the RTP packet creation unit 23 determines whether or not the EOS packet has been transmitted.

  If it is determined in step S21 that the EOS packet has not been transmitted, the process proceeds to step S22, and the RTP packet creation unit 23 instructs the RTCP packet creation unit 29 to transmit the EOS packet. The RTCP packet creation unit 29 creates an EOS packet according to the instruction from the RTP packet creation unit 23 and supplies the EOS packet to the communication unit 25 via the RTCP input / output port 26. The communication unit 25 creates an IP packet based on the EOS packet supplied from the RTCP packet creation unit 29 via the RTCP input / output port 26 and transmits the IP packet to the receiving terminal 14 via the IP network 13.

  Then, the process proceeds from step S22 to step S23, where the RTCP packet creation unit 29 starts measuring the transmission process end timer and returns to step S14. Here, since the NACK packet may be transmitted from the receiving terminal 14 even after the EOS packet is transmitted, the transmission process end timer is counted as the time for processing the NACK packet.

  On the other hand, if it is determined in step S21 that the EOS packet has been transmitted, the process proceeds to step S24, where the RTCP packet creation unit 29 determines whether or not the predetermined time measurement by the transmission process end timer has ended. To do.

  If it is determined in step S24 that the predetermined time has not been counted by the transmission process end timer, the process returns to step S14 and the above-described process is repeated.

  If it is determined in step S24 that the predetermined time has been counted by the transmission process end timer, the transmission process is terminated.

  With reference to the flowchart shown in FIG. 6, the packet reception processing by the receiving terminal 14 of FIG. 1 will be described.

  In step S31, initialization processing necessary for reception processing is performed. For example, the packet loss detection unit 38 starts measuring a predetermined time by a built-in packet loss check timer. The packet loss check timer is used to measure the time for performing a packet loss check at regular intervals.

  In step S <b> 32, the RTP packet analysis unit 33 determines whether or not an RTP packet from the transmission side terminal 12 has been received. When it is determined in step S32 that the RTP packet has been received, that is, when the RTP packet from the transmission side terminal 12 is received by the communication unit 31 and supplied to the RTP packet analysis unit 33 via the RTP input port 32 In step S33, the RTP packet analysis unit 33 supplies the data portion of the RTP packet supplied via the RTP input port 32 to the buffer 34, and supplies the header portion to the index list 35 and the packet loss detection unit 38. The process proceeds to step S34.

  Here, the buffer 34 stores the data of the data part of the RTP packet supplied from the RTP analyzer 33, and the index list 35 stores the header information of the header part of the RTP packet supplied from the RTP analyzer 33. Remember.

  In step S34, the packet loss detection unit 38, based on the header portion of the RTP packet supplied from the RTP analysis unit 33, the n frames of the data frame whose RTP packet (hereinafter, referred to as the packet of interest as appropriate) is a unit of reproduction. It is determined whether or not the packet is a terminal packet (n = 1, 2,...). If it is determined in step S34 that the packet of interest is not the end packet of the nth frame, the process proceeds to step S35, and the packet loss detection unit 38 determines whether or not the packet of interest is the first packet of the (n + 1) th frame. Make a decision.

  If it is determined in step S35 that the packet of interest is not the first packet of the (n + 1) th frame, the process proceeds to step S36, and the packet loss detection unit 38 determines whether or not the predetermined time measurement by the packet loss check timer has ended. Judgment is made.

  If it is determined in step S36 that the time measurement of the predetermined time by the packet loss check timer has not ended, the process proceeds to step S39, and the decoder 36 determines that the current time is the mth frame (m = 1, 2,...). It is determined whether or not it is the playback time of ().

  Here, the reproduction time of each frame can be calculated from the time stamp included in the RTP packet in which the data constituting the frame was stored.

  If it is determined in step S39 that the current time is not the playback time of the mth frame, step S40 is skipped, the process returns to step S32, and the above processing is repeated.

  If it is determined in step S39 that the current time is the playback time of the mth frame, the process proceeds to step S40, where the decoder 36 reads the data stored in the buffer 34 and performs the decoding process of the mth frame. . Then, it returns to step S32 and repeats the above-mentioned process.

  On the other hand, if it is determined in step S34 that the packet of interest is the end packet of the nth frame, or if it is determined in step S35 that the packet of interest is the first packet of the (n + 1) th frame, the process proceeds to step S38. move on.

  Also, when it is determined in step S36 that the time measurement of the predetermined time by the packet loss check timer has been completed, the packet loss detection unit 38 resumes the time measurement of the predetermined time by the packet loss check timer in step S37. Then, the process proceeds to step S38.

  In step S38, the packet loss detection unit 38 refers to the header information stored in the index list 35 to determine whether there is a loss of data constituting each frame, that is, whether there is a lost packet in each frame. . If it is determined in step S38 that there is no lost packet, the process proceeds to step S39, where the above-described processing is performed.

  If it is determined in step S38 that there is a lost packet, that is, if a lost packet is detected in the packet loss detection unit 38, the process proceeds to step S41, where the NACK packet transmission number determination unit 39 38 calculates a playback grace time which is the difference between the playback time of the frame including the data stored in the lost packet detected by the current time 38 and the current time, and further represents the urgency of receiving the lost packet from the playback grace time. Determine the request level.

  The reproduction grace time can be calculated from a time stamp included in the header information of the RTP packet, for example. That is, the reproduction grace time of the lost packet is, for example, the time stamp of the RTP packet in which the data constituting the frame currently being reproduced is stored and the time stamp of the RTP packet with the sequence number one before or after the lost packet. It can be obtained from the difference.

  In addition, as the reproduction grace time, for example, a difference value between the sequence number of the RTP packet in which the data constituting the frame currently being reproduced is stored and the sequence number of the lost packet may be used. In this case, the sequence number of the RTP packet in which the data making up the currently playing frame was stored is the sequence number of the RTP packet in which the first data of the currently playing frame was stored, or the currently playing frame The sequence number of the RTP packet in which the last data of the frame is stored, and the sequence number of any RTP packet in which the data between the beginning and the end are stored can be used.

  The required level can be determined by the following equation, for example.

  Request level = grace period / T

  T is a value indicating a certain time (time stamp) difference when the playback grace time is determined from the time stamp, and T is a value indicating a certain sequence number difference when the playback grace time is determined from the sequence number. This is the value shown. Further, it is assumed that the smaller the value of the request level, the higher the urgency of receiving a lost packet.

  After the determination of the request level in step S41, the process proceeds to step S42, where the NACK packet transmission number determination unit 39 determines the number of NACK packets to be transmitted according to the request level, and transmits information indicating the determined transmission number to the RTCP packet generation unit 40. To proceed to step S43.

  For example, the number of NACK packets transmitted can be determined as follows.

  If request level ≤ (K-1), number of NACK packets transmitted = K-request level

  If request level> (K-1), the number of NACK packets transmitted = 1

  In the above, K is a positive integer.

  According to the above contents, a small number of NACK packets (loss of NACK packets are sent) for lost packets with a large playback grace time (lost packets with a margin before playback time) and lost packets with a small playback grace time (playback time) A large number of NACK packets are transmitted (a number of NACK packets are transmitted).

  For example, assume that the scheduled playback time of the image frame F1 is 3000, the playback time of the image frame F2 is 6000, the scheduled playback time of the image frame F3 is 9000, T = 3000, K = 4, and the current time is 0. Suppose that a lost packet P1 for the image frame F1, a lost packet P2 for the image frame F2, and a lost packet P3 for the image frame F3 are detected. At this time, the transmission number C1 of NACK packets for the lost packet P1 is calculated by the following equation.

  C1 = 4- (3000/3000) = 3

  Similarly, the transmission number C2 of NACK packets for the lost packet P2 and the transmission number C3 of NACK packets for the lost packet P3 are calculated by the following equations.

C2 = 4- (6000/3000) = 2
C3 = 4- (9000/3000) = 1

  In step S43, the RTCP packet creation unit 40 creates a NACK packet for the lost packet, and communicates a number of NACK packets equal to the number of transmissions determined by the NACK packet transmission number determination unit 39 via the RTCP input / output port 41. Then, the process proceeds to step S44.

  In step S44, the communication unit 31 creates the number of IP packets based on the NACK packets supplied via the RTCP input / output port 41, and the process proceeds to step S45. In step S45, the communication unit 31 transmits the created IP packet to the transmission side terminal 12 via the IP network 13, returns to the process of step S32, and repeats the above process.

  As described above, it is possible to prevent an increase in useless traffic by adjusting the number of NACK packets transmitted according to the request level indicating the urgency of receiving lost packets.

  When a plurality of NACK packets are transmitted (when a plurality of NACK packets are transmitted), a plurality of NACK packets requesting retransmission of the same RTP packet (lost packet) by providing a timer in the RTCP packet creation unit 40 Can be transmitted to the transmitting terminal 12 at regular intervals.

  By transmitting NACK packets at regular intervals, when a plurality of NACK packets are transmitted at once, the risk of losing all transmitted NACK packets due to congestion of the IP network 13 may be reduced. it can.

  On the other hand, if it is determined in step S32 that the RTP packet from the transmission side terminal 12 has not been received, the process proceeds to step S46, where the RTCP packet analysis unit 42 has received the EOS packet from the transmission side terminal 12 or not. Judgment is made.

  If it is determined in step S46 that an EOS packet has been received, the process proceeds to step S47, where the RTCP packet analysis unit 42 starts counting a predetermined time by the reception process end timer, and returns to the process in step S32. The fixed time counted by this reception processing end timer is set based on the playback time of the last frame, and after the EOS packet is received, until the playback ends, the RTP packet requested to be retransmitted by the NACK packet. Used as time to enable reception.

  If it is determined in step S46 that no EOS packet has been received, the process proceeds to step S48, and the decoder 36 determines whether or not the current time is the reproduction time of the mth frame.

  If it is determined in step S48 that the current time is the reproduction time of the mth frame, the process proceeds to step S49, where the decoder 36 reads the data stored in the buffer 34 and performs the decoding process of the mth frame.

  In step S50, the RTCP packet analysis unit 42 determines whether an EOS packet has been received. If it is determined in step S50 that the EOS packet has been received, the process proceeds to step S51, and the RTCP packet analysis unit 42 determines whether or not the time measurement by the reception process end timer has ended.

  In step S51, if it is determined that the time measurement by the reception process end timer has ended, the reception-side terminal 14 ends the reception process.

On the other hand, if it is determined in step S48 that the current time is not the playback time of the m-th frame, if it is determined in step S50 that the EOS packet has not been received, or if it is determined in step S51 by the reception processing end timer. If it is determined that the time measurement has not ended, the process returns to step S32 to repeat the above-described process.

  As described above, by adjusting the number of NACK packets sent according to the request level indicating the urgency of receiving lost packets, NACK packets for lost packets that store data whose playback time is approaching are transmitted with high probability. It is possible to increase the probability that a retransmission packet storing data that is approaching the reproduction time can be received before the reproduction time on the reception side. As a result, highly reliable data communication and high-quality media playback are possible.

  Next, another embodiment will be described.

  FIG. 7 is a block diagram showing a configuration example of another embodiment of a communication system to which the present invention is applied. In FIG. 7, the same parts as those shown in FIG. 1 are denoted by the same reference numerals, and description thereof will be omitted as appropriate.

  In FIG. 7, an IP network 51 is an IP network compatible with Diffserv (Differentiated Services).

  The ARQ analysis unit 53 is necessary for retransmission processing of a packet such as a sequence number indicating an RTP packet requested to be retransmitted from the receiving side terminal 14 from the data portion of the NACK packet (RTCP packet) supplied from the RTCP packet analysis unit 27. Such information is acquired and the RTP packet creation unit 23 is instructed to perform retransmission processing. Further, the ARQ analysis unit 53 sets the DS (Differentiated Services) field of the IP header when the RTP packet is retransmitted from the designated priority of the data part of the NACK packet (RTCP packet) supplied from the RTCP packet analysis unit 27. The priority in the packet transfer process on the IP network 51 is determined, and information indicating the priority is notified to the communication unit 52 together with the information indicating the RTP packet requested to be retransmitted.

  The communication unit 52 performs the same processing as the communication unit 25 in FIG. However, when the communication unit 52 creates an IP packet from a retransmission packet (RTP packet) supplied from the RTP packet creation unit 23 via the RTP output port 26, the communication unit 52 is based on information supplied from the ARQ analysis unit 53. Then, a value corresponding to the priority set in the NACK packet is set in the DS field of the IP header, and the retransmission packet is transmitted to the receiving terminal 14 via the Diffserv compatible IP network 51.

  In FIG. 7, the ARQ processing unit 37 is configured by providing a NACK packet priority determining unit 55 instead of the NACK packet transmission number determining unit 39 of FIG.

  The NACK packet priority determination unit 55 determines the priority of the retransmission request notification packet for requesting retransmission of the lost packet based on the information indicating the lost packet supplied from the packet loss detection unit 38, and detects the packet loss. The information indicating the lost packet supplied from the unit 38 and the information indicating the priority of the retransmission request notification packet are supplied to the RTCP packet creating unit 40. At the same time, the NACK packet priority determination unit 55 supplies information indicating the priority of the retransmission request notification packet to the communication unit 54.

  The communication unit 54 performs the same processing as the communication unit 31 in FIG. However, when the communication unit 54 creates an IP packet based on the RTCP packet (NACK packet) supplied from the RTCP packet creation unit 40 via the RTCP input / output port 41, the communication unit 54 supplies it from the NACK packet priority determination unit 55. Based on the obtained information, a value indicating the priority in the packet transfer processing on the IP network 51 is set in the DS field of the IP header, and the packet is transmitted to the transmitting terminal 12 via the Diffserv-compatible IP network 51. To do.

  FIG. 8 is a diagram for explaining the configuration of an IP packet as a NACK packet transmitted from the receiving terminal 14 to the transmitting terminal 12.

  IP packet includes version information, header length, TOS (Type Of Service), packet length, identifier, flag, fragment offset, TTL (Time To Live), protocol, source IP address, destination IP address, options, and data It consists of each field.

  The version information field arranged at the head of the IP packet is a 4-bit area, and the version information represents the IP version.

  The header length to be arranged next represents the length of the IP header including version information to options.

  The 8-bit TOS field is replaced with a 6-bit DS (Differentiated Services) field and a 2-bit unused area when the IP packet is Diffserv-compatible, and a value indicating the priority of the IP packet is set in the DS field. The

  The packet length field is a 16-bit area, and the packet length described therein represents the total length of the IP packet, that is, the length including version information to data.

  The identifier field is a 16-bit area in which information for identifying a packet is set.

  The flag field is a 3-bit area, a 1-bit unused area at the beginning, a 1-bit area indicating whether fragmentation is prohibited, and finally, the end of a divided datagram. A 1-bit area is provided.

  The fragment offset field is a 13-bit area, and a value indicating the order in which the divided datagram is reconstructed is set therein.

  The TTL field is an 8-bit area, and the lifetime of the packet, that is, the number of routers through which the packet can pass is set. Each time the TTL value passes through the router, the TTL value is decremented by 1 by the router that has passed through, and is discarded by the router that has received the packet whose TTL value is 0.

  The protocol field is an 8-bit area, and a value indicating an upper protocol is set therein. In the present embodiment, RTP packets are used as an example for transferring streaming data. In this case, a value indicating UDP (User Datagram Protocol) is set as the protocol.

  The header checksum field is a 16-bit area, in which information used for error determination of the IP header portion is set.

  The source IP address field is a 32-bit area, and the source IP address is set in the source IP address field.

  The destination IP address field is a 32-bit area, and the destination IP address is set in the destination IP address field.

  A variable-length optional information list is arranged in the option field.

  The data field is a data portion of the IP packet, and an RTCP packet as a NACK packet in FIG.

  FIG. 9 is a diagram for explaining an RTCP packet as a NACK packet supplied from the RTCP packet creation unit 40 to the communication unit 54 via the RTCP input / output port 41.

  The version number, padding, FORMAT, transmission synchronization source identifier (RTCP), TIMESTAMP, number of retransmission requests, OPTION, and retransmission designation sequence are the same as those of the NACK packet shown in FIG.

  The designated priority shown in FIG. 9 represents the priority set in the DS field of the header part of the IP packet as the NACK packet.

  In addition, when a plurality of retransmission designation sequence numbers are set in the NACK packet and the designation priority corresponding to each retransmission designation sequence number is not the same, the DS field of the header part of the IP packet as the NACK packet includes a plurality of retransmission designation sequence numbers. Among the designated priorities corresponding to the respective retransmission designated sequence numbers, for example, the highest priority is set.

  FIG. 10 is a flowchart showing a transmission process of the transmission side terminal 12 of FIG.

  Steps S61 to S65, Step S67, or Steps S70 to S74 are the same as Steps S11 to S15, Step S17, or Steps S20 to S24 in FIG. To do.

  If it is determined in step S64 that a NACK packet has been received, that is, the NACK packet transmitted from the receiving side terminal 14 is received by the communication unit 52 and sent to the RTCP packet analysis unit 27 via the RTCP input / output port 26. If supplied, the RTCP packet analysis unit 27 supplies the NACK packet to the ARQ analysis unit 53 and proceeds to step S66. In step S66, the ARQ processing unit 53 analyzes the data part of the NACK packet supplied from the RTCP packet analyzing unit 27, and performs a packet retransmission process such as a sequence number indicating a packet requested to be retransmitted by the NACK packet. Necessary information is acquired, and a retransmission process is instructed to the RTP packet creation unit 23.

  Further, the ARQ analysis unit 53 sets the DS (Differentiated Services) field of the IP header at the time of packet retransmission from the designated priority (FIG. 9) of the data part of the NACK packet supplied from the RTCP packet analysis unit 27. The priority in the packet transfer process on the IP network 51 is determined, and the communication unit 52 is notified of the information indicating the priority together with the information indicating the RTP packet requested to be retransmitted.

  Proceeding from step S66 to step S67, the RTP packet creation unit 23 obtains data corresponding to the retransmission request (data requested to be retransmitted by the NACK packet) from the buffer 22 in accordance with the retransmission processing instruction from the ARQ analysis unit 28. The process proceeds to step S68.

  In step S68, the RTP packet creation unit 23 creates an RTP packet storing the data acquired from the buffer 22 in step S67, and supplies the RTP packet as a retransmission packet to the communication unit 52 via the RTP output port 24. Proceed to

  In step S <b> 69, the communication unit 52 creates an IP packet based on the retransmission packet supplied from the RTP packet creation unit 23 via the RTP output port 24. At this time, the communication unit 52 sets a value corresponding to the information indicating the priority supplied from the ARQ processing unit 53 in the DS field of the IP header. Then, the process proceeds to step S <b> 70, and the communication unit 52 transmits the created IP packet to the receiving terminal 14 via the IP network 51. Thereafter, the process returns to step S64, and the same processing is repeated thereafter.

  Therefore, in the communication system of FIG. 7, the designated priority set in the NACK packet from the transmitting terminal 12 to the receiving terminal 14, that is, the value set in the DS field of the IP packet as the NACK packet. For example, the same value is set in the DS field of the IP packet as the retransmission packet, and the IP packet as the retransmission packet is transmitted. In this case, the retransmission packet is transferred within the IP network 51 with the same priority as the NACK packet that requests retransmission of the retransmission packet.

  FIG. 11 is a flowchart showing a reception process of the reception side terminal 14 of FIG.

  The processes in steps S81 to S91 and steps S95 to S101 are the same as those in steps S31 to S41 and steps S45 to S51 in FIG.

  If it is determined in step S88 that there is a lost packet, that is, if a lost packet is detected in the packet loss detector 38, the process proceeds to step S91, where the NACK packet priority determiner 55 The request level of the frame including the data stored in the detected lost packet is determined in the same manner as the NACK packet transmission number determining unit 39 in FIG. 1 performs in step S41 in FIG. 6, and the process proceeds to step S92.

  In step S92, the NACK packet priority determination unit 55 determines the NACK packet priority indicating the priority in the packet transfer process on the IP network 51 according to the request level determined in step S91, and determines the lost packet. The NACK packet priority is supplied to the RTCP packet creation unit 40 together with the information (sequence number) indicated. At the same time, the NACK packet priority determination unit 55 supplies the NACK packet priority to the communication unit 54, and proceeds to step S93.

  When a plurality of lost packets are detected in step S88, the NACK packet priority determination unit 55 determines the NACK packet priority for each of the plurality of lost packets in step S92, and further, the NACK packet priority NACK packet priority indicating the highest priority is supplied to the communication unit 54.

  In step S93, the RTCP packet creation unit 40 creates an RTCP packet as a NACK packet requesting a lost packet. At this time, the RTCP packet creation unit 40 sets a sequence number as information indicating a lost packet from the packet loss detection unit 55 in the NACK packet as a retransmission designation sequence number in FIG. The priority of the NACK packet is set as the designated priority in FIG. 9 and supplied to the communication unit 54 via the RTCP input / output port 41, and the process proceeds to step S94.

  In step S 94, the communication unit 54 creates an IP packet based on the NACK packet supplied from the RTCP packet creation unit 40 via the RTCP input / output port 41. At this time, a value is set in the DS field of the IP header according to the NACK packet priority supplied from the NACK packet priority determination unit 55, and the process proceeds to step S95. In step S <b> 95, the communication unit 54 transmits the created IP packet to the transmission side terminal 12 via the IP network 51.

  Here, the NACK packet priority can represent a plurality of stages. Here, a two-stage NACK packet priority and a three-stage or higher NACK packet priority will be described.

  First, when the NACK packet priority is set to two levels, the NACK packet priority is obtained from the following equation, for example.

If request level ≤ θ, NACK packet priority = 2
If request level> θ, NACK packet priority = 1

  θ is a positive integer.

  Next, when the NACK packet priority is set to three or more levels, the NACK packet priority is obtained as follows, for example.

  If request level ≤ (K-1), NACK packet priority = K-request level

  If request level> (K-1), NACK packet priority = 1

  In the above, K is a positive integer. It is assumed that the larger the NACK packet priority is, the more preferential transfer is performed in the packet transfer process on the network 51.

  According to the above, NACK packets for lost packets with a sufficient playback grace time and therefore a high request level are transmitted at a low priority, and NACK packets for lost packets with a short playback grace time and therefore a low request level are It is transmitted with high priority (it is preferentially transferred in the IP network 51).

  For example, in the case where there are three levels of NACK packet priority and K = 3, the NACK packet priority is determined as follows according to the request level.

If request level ≥ 2, NACK packet priority = 1
If 1 ≤ request level <2, NACK packet priority = 2
If request level <1, NACK packet priority = 3

  Here, the value set in the DS field of the IP header will be described.

  When adopting two-stage NACK packet priority, for example, the Expedited Forwarding Class (EF Class) in Diffserv defined in IETF RFC2598 and the Best Effort Class (BE Class) defined in IETF RFC2597 are used.

  At this time, NACK packet priority = 2 corresponds to EF Class, and NACK packet priority = 1 corresponds to BE Class. Further, for example, 101110 is set in binary notation in the DS field of the EF Class packet, and 000000 is set in binary notation in the DS field of the BE Class packet.

  In the Diffserv network, the EF Class is the highest priority class, and is the highest priority Class that guarantees the delay and the maximum loss rate. On the other hand, BE Class is the lowest-priority class in the Diffserv network, and is processed in free time when EF Class packet processing is not performed in the Diffserv-compatible router.

  When adopting three levels of NACK packet priority, for example, Expedited Forwarding Class (EF Class) defined in IETF RFC2598, Assured Forwarding Class (AF Class) defined in IETF RFC2597, and Best Effort Class (BE Class).

  At this time, NACK packet priority = 3 corresponds to EF Class, NACK packet priority = 2 corresponds to AF Class, and NACK packet priority = 1 corresponds to BE Class. Also, for example, the DS field of the EF Class packet is 101110 in binary notation, the DS field of the AF Class packet is 00110 in binary notation, and the DS field of the BE Class packet is in binary notation. Set 000000.

  The NACK packet priority is EF Class, AF Class, and BE Class in descending order. In addition, since AF Class can set three levels of Class and four levels of packet loss rate in IETF RFC2597, it is possible to further classify priorities as a whole.

  In this embodiment, an example corresponding to Diffserv (Differentiated Services) defined in IETF RFC2474, IETF RFC2475, IETF RFC2597, and IETF RFC2598 has been described as a priority control method for controlling packet transmission according to priority. The priority control method may be adopted.

  In the present embodiment, a designated priority field is provided in the data portion of the RTCP packet as a NACK packet, and the NACK packet priority determined according to the request level is set in the designated priority field. The value corresponding to the NACK packet priority is set in the DS field of the IP packet in which the RTCP packet is stored, and the IP packet is transmitted from the receiving terminal 14 to the transmitting terminal 12. 14, it is possible to create a NACK packet without a designated priority field. In this case, the sending terminal 12 sets the same priority as the priority set in the DS field of the IP packet as the NACK packet received from the receiving terminal 14 in the DS field of the IP header part of the retransmission packet. Is done.

  As described above, the NACK for the lost packet storing the data whose reproduction time is near by adjusting the priority in the transfer process on the network of the NACK packet according to the request level indicating the urgency of receiving the lost packet. The packet can reach the transmission side with a high probability, and it is possible to increase the probability that the retransmission packet storing the data whose reproduction time is approaching can be received by the reception side by the reproduction time. As a result, highly reliable data communication and high-quality media playback are possible.

  By using the present invention, in RTP packet communication using the conventional automatic retransmission request method (ARQ), a packet requesting retransmission of a lost packet itself is lost on the network, and the loss that the packet tries to request retransmission In the problem that packet retransmission processing may not be performed, the robustness of RTP packet communication can be improved and highly reliable data communication can be realized.

  The series of processes described above can be executed by hardware or can be executed by software. In this case, the processing described above is executed by a personal computer 60 as shown in FIG.

  In FIG. 12, a CPU (Central Processing Unit) 61 performs various processes according to a program stored in a ROM (Read Only Memory) 62 or a program loaded from a storage unit 68 to a RAM (Random Access Memory) 63. Execute. The RAM 63 also appropriately stores data necessary for the CPU 61 to execute various processes.

  The CPU 61, ROM 62, and RAM 63 are connected to each other via an internal bus 64. An input / output interface 65 is also connected to the internal bus 64.

  The input / output interface 65 includes an input unit 66 including a keyboard and a mouse, a display including a CRT and LCD (Liquid Crystal Display), an output unit 67 including a speaker, a storage unit 68 including a hard disk, a modem, and the like. A communication unit 69 composed of a terminal adapter or the like is connected. The communication unit 69 performs communication processing via various networks including a telephone line and CATV.

  A drive 70 is also connected to the input / output interface 65 as necessary, and a magnetic disk 71 (including a flexible disk), an optical disk 72 (CD-ROM (Compact Disc-Read Only Memory), DVD (Digital Versatile Disc)) ), A magneto-optical disk 73 (including MD (Mini-Disc) (trademark)), or a removable medium composed of a semiconductor memory 74 or the like is appropriately mounted, and a computer program read therefrom is stored as necessary. 68 is installed.

  When a series of processing is executed by software, a program constituting the software executes various functions by installing a computer incorporated in dedicated hardware or various programs. For example, it is installed in a general-purpose personal computer from a network or a recording medium.

  As shown in FIG. 12, this recording medium is distributed to provide a program to the user separately from the computer, and the magnetic disk 71, optical disk 72, magneto-optical disk 73, or semiconductor memory on which the program is recorded is distributed. In addition to a package medium composed of 74 or the like, the medium is composed of a ROM 62 on which a program is recorded and a hard disk included in the storage unit 68 provided to the user in a state of being incorporated in a computer in advance.

  In the present specification, the processes described in the flowcharts are executed in parallel or individually even if they are not necessarily processed in time series, as well as processes performed in time series according to the order described as steps. It also includes processing.

It is a block diagram which shows the structural example of one Embodiment of the communication system to which this invention is applied. It is a figure showing the structure of an RTP packet. It is a figure showing the structure of the RTCP packet as a NACK packet. It is a figure showing the structure of the RTCP packet as an EOS packet. It is a flowchart explaining a transmission process. It is a flowchart explaining a reception process. It is a block diagram which shows the structural example of other embodiment of the communication system to which this invention is applied. It is a figure which shows the structure of the IP packet as a NACK packet. It is a figure showing the structure of the RTCP packet as a NACK packet. It is a flowchart explaining a transmission process. It is a flowchart explaining a reception process. It is a figure which shows the structural example of a personal computer.

Explanation of symbols

  11 video camera, 12 transmitting terminal, 13 IP network, 14 receiving terminal, 15 display, 16 speaker, 21 encoder, 22 buffer, 23 RTP packet creation unit, 24 RTP output port, 25, 26 RTCP input / output port, 27 RTCP packet analysis unit, 28 ARQ processing unit, 29 RTCP packet creation unit, 31 communication unit, 32 RTP input port, 33 RTP packet analysis unit, 34 buffer, 35 index list, 36 decoder, 37 ARQ processing unit, 38 packet loss detection 39, NACK packet transmission number determination unit, 40 RTCP packet creation unit, 41 RTCP input / output port, 42 RTCP packet analysis unit, 51 IP network, 52 communication unit, 53 ARQ analysis unit, 54 communication unit, 55 NACK packet priority Decision part, 61 CPU, 62 ROM, 63 RAM, 64 internal bus, 65 input / output interface, 66 input section, 67 output section, 68 storage section, 71 magnetic disk, 72 optical disk, 73 magneto-optical disk, 74 semiconductor memory

Claims (5)

In the receiving device that receives the packet transmitted from the transmitting device that transmits the packet storing the streaming data via the network,
If the packet cannot be received normally, the request level indicating the urgency of receiving the packet that could not be received normally is reproduced as the current time and the streaming data stored in the packet that could not be received normally A request level determination unit that determines a difference from a scheduled time by dividing the reproduction grace time calculated from the time stamp information or the sequence number of the packet by a predetermined value ;
Receiving, characterized in that it comprises a retransmission request notification transmission control means for performing control in case of transmitting a retransmission request notification packet to request retransmission of the packet is not received correctly, before Symbol transmitting apparatus according to the required level apparatus. The retransmission request notification transmission control unit determines the number of transmission packets for transmitting the retransmission request notification packet according to the request level, and transmits the retransmission request notification packets for the determined number of transmission packets. Item 4. The receiving device according to Item 1 . In a receiving method for receiving the packet transmitted from a transmitting device that transmits a packet storing streaming data via a network,
If the packet cannot be received normally, the request level indicating the urgency of receiving the packet that could not be received normally is reproduced as the current time and the streaming data stored in the packet that could not be received normally A request level determination step for determining by dividing a reproduction grace time calculated from a time stamp information or a sequence number of the packet by a predetermined value, which is a difference from a scheduled time ;
Receiving, characterized in that it comprises a retransmission request notification transmission control step of performing control in case of transmitting a retransmission request notification packet to request retransmission of the packet is not received correctly, before Symbol transmitting apparatus according to the required level Method. A program for reception processing that receives the packet transmitted from a transmission device that transmits a packet storing streaming data via a network,
If the packet cannot be received normally, the request level indicating the urgency of receiving the packet that could not be received normally is reproduced as the current time and the streaming data stored in the packet that could not be received normally A request level determination step for determining by dividing a reproduction grace time calculated from a time stamp information or a sequence number of the packet by a predetermined value, which is a difference from a scheduled time ;
A retransmission request notification packet to request retransmission of the packet is not received correctly, characterized in that it comprises a retransmission request notification transmission control step of the control in case of transmitting before Symbol transmitting device carried out according to the required level, A recording medium on which a computer-readable program is written. In the reception process of receiving the packet transmitted from the transmission device that transmits the packet storing the streaming data via the network,
If the packet cannot be received normally, the request level indicating the urgency of receiving the packet that could not be received normally is reproduced as the current time and the streaming data stored in the packet that could not be received normally A request level determination step for determining by dividing a reproduction grace time calculated from a time stamp information or a sequence number of the packet by a predetermined value, which is a difference from a scheduled time ;
A retransmission request notification packet to request retransmission of the packet is not received correctly, to perform the control in the case of transmitting before Symbol sending device processing including retransmission request notification transmission control step carried out in accordance with the required level in the computer A program characterized by that.

Images