JP2004186737A - Communication apparatus and communication system - Google Patents

Communication apparatus and communication system Download PDF

Info

Publication number
JP2004186737A
JP2004186737A JP2002347870A JP2002347870A JP2004186737A JP 2004186737 A JP2004186737 A JP 2004186737A JP 2002347870 A JP2002347870 A JP 2002347870A JP 2002347870 A JP2002347870 A JP 2002347870A JP 2004186737 A JP2004186737 A JP 2004186737A
Authority
JP
Japan
Prior art keywords
packet
rtp
retransmission
receiving
sequence number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002347870A
Other languages
Japanese (ja)
Inventor
Yasuhiko Numagami
泰彦 沼上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kyocera Corp
Original Assignee
Kyocera Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kyocera Corp filed Critical Kyocera Corp
Priority to JP2002347870A priority Critical patent/JP2004186737A/en
Publication of JP2004186737A publication Critical patent/JP2004186737A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

<P>PROBLEM TO BE SOLVED: To realize a communication apparatus capable of efficiently retransmitting packets without affecting a communication apparatus exchanging data having real time performance by packet communication using RTP. <P>SOLUTION: At a receiving terminal of an RTP packet, a retransmission control apparatus 20 detects the sequence number included in a received packet to be used for predetermined streaming, detects packet disposal on the basis of this sequence number, and requests retransmission of the packet based on the detection of the packet disposal. At a transmitting terminal of the RTP packet, a retransmission control apparatus 30 accumulates packets to be used for the predetermined streaming out of the transmission packets, and upon receiving the retransmission of the packets, the apparatus 30 transmits the accumulated corresponding packet to the retransmission request source. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【0001】
【発明の属する技術分野】
本発明は、パケットの再送を制御する通信装置及び通信システムに関する。
【0002】
【従来の技術】
UDP(User Datagram Protocol)及びIP(Internet Protocol)を用いたパケット通信方式では、IPパケットにUDPポート番号を付加するが、ほぼそのままIPパケットを使用してデータを伝送する。IP層レベルでは輻輳等によりパケットが廃棄されることがあるが、UDPではこの廃棄対策を行っていない。
【0003】
RTP(Realtime Transport Protocol)はUDP及びIP上で用いられるプロトコルであり、通信路で廃棄されたパケットを検出する機能を提供する。このRTPのパケット廃棄検出機能について説明する。図7は、RTPパケットのフォーマットを示す図である。図8は、図7に示すRTPヘッダの構成を示す図である。IPヘッダはIPアドレス等を含む、UDPヘッダはポート番号等を含む。
【0004】
RTPでは、図8のRTPヘッダ中のシーケンス番号をパケット毎に1づつ変化させる。そして、受信側において、そのシーケンス番号の不連続を検出することにより廃棄されたパケットを特定する。しかし、RTPではその廃棄されたパケットの取り扱いについては規定しておらず、上位プロトコルにより廃棄対策の処理を行っている。図8のタイプ(ペイロードタイプ)はパケットがどの上位プロトコルで処理されるかを示している(例えば、H.263の場合、タイプ「34」)。
【0005】
次に、TCP(Transmission Control Protocol)の再送機能について説明する。TCPは、IP上で用いられ、インターネットで広く使用されているプロトコルである。TCPではTCPヘッダにシーケンス番号と受信確認シーケンス番号のフィールドを設けている。送信側は各パケットにシーケンス番号をつけて送信し、受信側ではパケットの受信により確認したシーケンス番号(受信確認シーケンス番号)を受信確認シーケンス番号フィールドに入れて送信側へ送信する。この受信確認シーケンス番号により、送信側では、送信済みパケットの送達確認を行う。この送信済みのパケットの送達確認が、あるタイムアウト時間内になされなかった場合、送信側は、送達未確認のパケットを再送する。これにより、全てのパケットの送達が正常に行われ、通信データの信頼性が確保されている。
更にこのTCPでは、RTPと異なり、CRCによる受信データのチェックや輻輳回避のためのレート制御も行っているので、一般にUDP/IPを使用するよりも処理負荷が高く、リアルタイム性を要求されるアプリケーションには適用されない場合が多い。
【0006】
また、ARQ(Automatic Repeat Request)方式を用いて再送を制御する装置もある(例えば、特許文献1参照)。ARQ方式では、受信したパケットについては肯定応答(ACK)を返送し、一方、受信できなかったパケットについては否定応答(NAK)を返送することにより、再送の制御を行っている。
【0007】
【特許文献1】
特開平11−88466号公報
【0008】
【発明が解決しようとする課題】
しかし、上述したように、RTPではパケットの廃棄を検出する機能は提供されているが、廃棄されたパケットを再送するための機能については上位プロトコルに依存している。このため、通信データの信頼性が要求される場合には、RTPには再送プロトコルが含まれていないためTCPなど、再送機能を有する別のプロトコルを使用する必要がある。しかしながら、性能の低下、接続可能な通信装置が限定される、などの問題が生じている。
【0009】
また、ARQ方式では、肯定応答(ACK)を送信するので、帯域リソースの使用効率が低下するという問題がある。さらに、送受信する全てのパケットについて再送制御を行うため、不要なパケットの再送が起こり、通信効率が悪くなる。
【0010】
本発明は、このような事情を考慮してなされたもので、その目的は、RTPを用いたパケット通信によりリアルタイム性のあるデータを授受する通信装置に影響を与えることなく、パケットの再送を効率よく行うことができる通信装置及び通信システムを提供することにある。
【0011】
【課題を解決するための手段】
上記の課題を解決するために、請求項1に記載の通信装置は、パケットを受信する受信手段と、該受信手段が受信したパケットの種別を識別する識別手段と、該識別手段が所定のパケットを識別した時に該パケットに含まれるシーケンス番号を検出する検出手段と、該検出手段が検出したシーケンス番号に基づいてパケット廃棄を判定する判定手段と、該判定手段によりパケット廃棄と判定されると、当該パケットの再送を要求する再送要求手段とを備えたことを特徴とする。
【0012】
請求項2に記載の通信装置においては、前記パケットの伝送プロトコルはRTPであり、前記再送要求手段の再送要求はRTCPのAPPパケットに付加することを特徴とする。
【0013】
請求項3に記載の通信装置は、パケットに種別を付加して送信する送信手段と、該送信手段が送信したパケットを記憶する記憶手段と、パケットを受信する受信手段と、該受信手段により再送要求のパケットを受信した時に当該再送要求に応じたパケットを前記記憶手段より読み出して前記送信手段から送信するよう制御する制御手段とを備えたことを特徴とする。
【0014】
請求項4に記載の通信装置においては、前記パケットの伝送プロトコルはRTPであり、前記制御手段は前記受信手段がRTCPのBYEパケットを受信した時は前記記憶手段のデータを全て削除することを特徴とする。
【0015】
請求項5に記載の通信システムは、少なくともMPEG−4方式により圧縮された映像信号をRTPを用いて送信端末から受信端末へ伝送する通信システムにおいて、前記送信端末は、送信するRTPパケットのヘッダにエレメントストリームのタイプを付加して送信する送信手段を備え、前記受信端末は、前記送信端末から受信したRTPパケットのヘッダに付加されているエレメントストリームのタイプが再送を必要とするタイプか否かを識別する識別手段と、該識別手段が再送を必要するタイプであると識別した時に当該パケットに含まれるシーケンス番号を検出する検出手段と、該検出手段が検出したシーケンス番号に基づいてパケット廃棄を判定する判定手段と、該判定手段によりパケット廃棄と判定されると、当該パケットの再送を要求する再送要求手段とを備えたことを特徴とする。
【0016】
請求項6に記載の通信システムにおいては、前記再送要求手段の再送要求はRTCPのAPPパケットに付加することを特徴とする。
【0017】
【発明の実施の形態】
以下、図面を参照し、本発明の実施形態について説明する。
図1は、本発明の一実施形態による再送制御装置20,30(通信装置)を用いた通信システムの構成例を示すブロック図である。図1に示す通信システムは、RTP受信端末10と、RTPパケット受信端に位置するRTP再送制御装置20と、RTPパケット送信端に位置するRTP再送制御装置30と、RTP送信装置40を備えている。
RTP送信装置40は、RTPを用いたパケット通信により、RTP受信端末10へデータを提供する。RTP送信装置40及びRTP受信端末10は、RTPパケットを相互に送受信する。
【0018】
RTP再送制御装置20は、RTP受信装置10が接続されている信頼性の高いローカルネットワークと、インターネット50に接続されている。RTP再送制御装置20は、インターネット50から受信したRTPパケットをローカルネットワークへ転送する機能と、RTPパケットの再送機能を有する。受信端のRTP再送制御装置20は、インターネット50からRTPパケットを受信し、再送が必要なRTPパケットを検出して、送信端のRTP再送制御装置30に対して再送要求を送信する。
【0019】
RTP再送制御装置30は、RTP送信装置40が接続されている信頼性の高いローカルネットワークと、インターネット50に接続されている。RTP再送制御装置30は、ローカルネットワークを介してRTP送信装置40から受信したRTPパケットをインターネット50へ転送する機能と、RTPパケットの再送機能を有する。送信端のRTP再送制御装置30は、パケット列を監視し、信頼性が必要なRTPパケットを蓄積し、受信端のRTP再送制御装置20から再送要求があった場合に蓄積しているRTPパケットを再送する。
【0020】
図2は、図1に示す受信端のRTP再送制御装置20の構成を示すブロック図である。図2において、多重化復元部210は、送信端のRTP再送制御装置30から送信されたパケット列をインターネット50を介して受信し、該パケット列を分解してRTP解析部220に出力する。
RTP解析部220は、受信したRTPパケットが再送対象のストリームに含まれるRTPパケットであるか否かを判定し、再送対象のRTPパケットのみに対して廃棄検出処理を行う。再送対象のストリームに含まれるか否かの判定は、図8のRTPヘッダのタイプ(ペイロードタイプ)の値に基づいて行う。
【0021】
RTP解析部220は、廃棄検出処理において、再送対象のRTPパケットに含まれるシーケンス番号を確認し、次に受信すべきシーケンス番号と比較する。この比較の結果、シーケンス番号が異なっていた場合、パケット廃棄があったと判断し、廃棄されたRTPパケットのシーケンス番号を再送制御部240に通知して再送を指示する。さらに、パケット廃棄を検出した時点から、以降に到着する該当ストリームのRTPパケットを蓄積する。
【0022】
再送制御部240は、RTP解析部220から再送指示を受けると、通知されたシーケンス番号のRTPパケットを再送するためのAPP−RTCPパケットを生成して多重化部260へ出力する。APP−RTCPパケットはRTCPのアプリケーション定義パケットのことを指す。
多重化復元部250は、RTP受信端末10から送信されたパケット列をローカルネットワークを介して受信し、該パケット列を分解して多重化部260に出力する。
多重化部260は、再送制御部240から入力されたAPP−RTCPパケットを、多重化復元部250から入力されたパケットと多重化してインターネット50を介して送信端のRTP再送制御装置30へ送信する。
【0023】
RTP解析部220は、インターネット50を介してRTP再送制御装置30から再送パケットを受信すると、再送パケットと蓄積している該当ストリームのRTPパケットとをシーケンス番号順に多重化部230へ出力する。多重化部230は、入力されたパケットを多重化してローカルネットワークを介してRTP受信端末10へ送信する。これにより、RTP受信端末10には、シーケンス番号の順序でRTPパケットが届くことになる。
【0024】
なお、インターネット50から受信したRTPパケットを順次、RTP受信端末10側へ送信し、受信した再送パケットについてもそのままRTP受信端末10側へ送信するようにしてもよい。但し、この場合には、RTP受信端末10が受信パケットをシーケンス番号の順序に並べ替える。
【0025】
図3は、図1に示す送信端のRTP再送制御装置30の構成を示すブロック図である。図3において、多重化復元部310は、RTP送信装置40から送信されたパケット列をローカルネットワークを介して受信し、該パケット列を分解してRTP解析部320に出力する。
RTP解析部320は、受信したRTPパケットが再送対象のストリームに含まれるパケットであるか否かを判定し、再送対象のRTPパケットのみをデータ蓄積部350に蓄積する。また、RTP解析部320は、多重化復元部310から入力されたパケットを多重化部330へ出力する。
【0026】
多重化復元部370は、受信端のRTP再送制御装置20から送信されたパケット列をインターネット50を介して受信し、該パケット列を分解してRTP解析部380に出力する。
RTP解析部380は、受信端のRTP再送制御装置20によって生成されたAPP−RTCPパケットを検出した場合に、再送すべきシーケンス番号をAPP−RTCPパケットから抽出し、再送制御部360に再送を指示する。その他のパケットは全て多重化部390に出力する。
多重化部390は、入力されたパケットを多重化してローカルネットワークを介してRTP送信端末40へ送信する。
【0027】
再送制御部360は、RTP解析部380から指示されたシーケンス番号のRTPパケットを、データ蓄積部350から読み出して多重化部330へ出力する。
多重化部330は、再送制御部360から入力された再送パケットとRTP解析部320から入力されたパケットとを多重化して、インターネット50を介して受信端のRTP再送制御装置20へ送信する。
データ管理部340は、データ蓄積部350に蓄積されているRTPパケットのうち、不要となったパケットをデータ蓄積部350から削除する。
【0028】
次に、上述した本発明による再送制御装置20,30を用いた通信システムの実施例として、インターネットMPEG−4配信システムを説明する。図4は、インターネットMPEG−4配信システムの構成例を示すブロック図である。図5は、図4に示すインターネットMPEG−4配信システムのデータ伝送に係る基本構成を示すブロック図である。
インターネットMPEG−4配信システムは、MPEG−4再生端末15と、RTPパケット受信端に位置する上記図2のRTP再送制御装置20と、RTPパケット送信端に位置する上記図3のRTP再送制御装置30と、MPEG−4ビデオサーバ45を備える。
【0029】
MPEG−4ビデオサーバ45には、予めMPEG−4標準規格に従い符号化された、ビデオ映像データおよびシーン記述データが格納されている。MPEG−4ビデオサーバ45は、ビデオ映像データおよびシーン記述データを、RTP再送制御装置30へ送信する。RTP再送制御装置30は、受信したビデオ映像データおよびシーン記述データを、インターネット50を介してRTP再送制御装置20へ転送する。RTP再送制御装置20は、受信した受信したビデオ映像データおよびシーン記述データを、MPEG−4再生端末15へ送信する。シーン記述データおよびビデオ映像データの伝送形式には、独立したエレメントストリームを用いる。このエレメントストリームを区別するために、RTPヘッダのペイロードタイプを用いる。
【0030】
図4に示すインターネット50では、通信路が輻輳した場合、あるRTPパケットがビデオ映像データを含んでいるのか、あるいはシーン記述データを含んでいるのかを区別せずに、当該パケットの廃棄が行われる。MPEG−4のシーン記述データには、シーン中に文字や図形を表示するとともに、その中にビデオ映像をどのように表示するか等の情報が含まれている。このため、パケット廃棄によりシーン記述データが欠落すると、最悪ビデオ全体が表示されないなど、通信品質に与える悪影響が大きい。一方、ビデオ映像データのエレメンタリーストリームについては多くの情報が含まれており、一つのRTPパケットが廃棄されても1フレーム中の一部に画質劣化が生じるなど、非常に局所的な影響しか与えない。このため、シーン記述データのエレメンタリーストリームについては、ビデオ映像データのストリームよりも通信の信頼性が要求される。
【0031】
次に、図4のインターネットMPEG−4配信システムの再送制御に係る動作を説明する。以下、図2,図3に対応する部分には同一の符号を付している。
送信端のRTP再送制御装置30において、多重化復元部310は、MPEG−4ビデオサーバ45から受信した信号をIPパケットに分解してRTP解析部320に出力する。RTP解析部320は、受信したRTPパケットのみを抽出するが、パケットの廃棄、入れ替え、書換等は行わず、そのまま多重化部330に出力する。RTP解析部320は、受信したRTPパケットのうち、ペイロードタイプがシーン記述ストリームであるパケットを、データ蓄積部350に蓄積するとともに、データ管理部340の管理テーブルに情報を記録する。
【0032】
受信端のRTP再送制御装置20において、多重化復元部210は、送信端のRTP再送制御装置30から送信されたパケット列をインターネット50を介して受信し、該パケット列をIPパケットに分解してRTP解析部220に出力する。RTP解析部220は、受信したIPパケットのうち、RTPパケットであり且つペイロードタイプがシーン記述ストリームであるパケットのシーケンス番号を抽出する。このシーケンス番号と前回受信したシーン記述ストリームのRTPパケットのシーケンス番号との差が1でない場合、RTP解析部220は、それらシーケンス番号の間のパケットが廃棄されたと判断する。そして、その廃棄されたと判断したシーケンス番号を再送制御部240に通知する。
【0033】
再送制御部240は、そのシーケンス番号をRTP解析部220から受け取ると、送信端のRTP再送制御装置30へ送信するAPP−RTCPパケットを作成する。図6にAPP−RTCPパケットの構成を示す。
【0034】
図6に示すように、APP−RTCPパケットには、RTCPヘッダのタイプフィールドにAPPを表す「204」を使用し、送信者識別子には受信端末(MPEG−4再生端末15)の値を用いる。RTCPペイロードは、アプリケーション識別子の固有コードと、再送が必要なシーケンス番号の数、シーケンス番号列から成る。
【0035】
再送制御部240は、作成したAPP−RTCPパケットを多重化部260に出力する。多重化部260は、該APP−RTCPパケットと、MPEG−4再生端末15がMPEG−4ビデオサーバ45に返送しているRTCPパケットとを多重化してインターネット50を介して送信端のRTP再送制御装置30へ送信する。
【0036】
送信端のRTP再送制御装置30において、多重化復元部370は、インターネット50を介して受信したパケット列を、IPパケットに分解してRTP解析部380に出力する。RTP解析部380は、受信したAPP−RTCPパケットのうち、受信端のRTP再送制御装置20で生成されたものを抽出し、それ以外のパケットは、多重化部390によりMPEG−4ビデオサーバ45へ送信する。RTP解析部380は、抽出したAPP−RTCPパケットに含まれている再送要求対象のシーケンス番号を再送制御部360に通知する。
【0037】
再送制御部360は、そのシーケンス番号を受け取ると、データ蓄積部350から当該シーケンス番号を有するパケットを読み出して多重化部330に出力する。多重化部330は、その再送パケットと他のRTPパケットとを多重化してインターネット50を介して受信端のRTP再送制御装置20へ送信する。
【0038】
データ管理部340は、データ蓄積部350に蓄積されているRTPパケットのうち、不要となったパケットをデータ蓄積部350から削除する。データ管理部340は、RTP解析部320によりデータ蓄積部350に蓄積されるパケットのシーケンス番号が、既に蓄積されているパケットのシーケンス番号と同じである場合に、既に蓄積されているパケットをデータ蓄積部350から削除する。なお、シーケンス番号は、16ビットで構成されており、その値は巡回している。また、BYE−RTCPパケットが受信され、RTPセッションが終了したことをRTP解析部320が検出した場合、この検出によりデータ管理部340は、該RTPセッションのRTPパケットの全てを、データ蓄積部350から削除する。
【0039】
なお、本実施形態において、受信側の通信装置をRTP再送制御装置とローカルエリアネットワークで接続されたRTP受信端末(又はMPEG−4再生端末)で構成し、送信側の通信装置をRTP再送制御装置とローカルエリアネットワークで接続されたRTP送信端末(又はMPEG−4ビデオサーバ)で構成しているが、ローカルエリアネットワークで接続せずに通信端末に全て含むように構成してもよい。
【0040】
以上、本発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【0041】
【発明の効果】
以上説明したように、本発明によれば、所定のストリーミングに用いられる、例えばRTPパケットのみを再送対象として再送制御をおこなうので、RTPを用いたパケット通信によりデータを授受する通信装置に影響を与えることなく、パケットの再送を効率よく行うことができる。これにより、例えばRTP/UDP/IPを使用する通信において、送信サーバ及び受信端末を変更することなく、重要な通信ストリームの信頼性を確保することができる。
【0042】
また、再送用に蓄積している送信パケットのうち、不要となったパケットについては削除されるので、パケットの蓄積効率が向上する。
【図面の簡単な説明】
【図1】本発明の一実施形態による再送制御装置20,30を用いた通信システムの構成例を示すブロック図である。
【図2】RTPパケット受信端のRTP再送制御装置20の構成を示すブロック図である。
【図3】RTPパケット送信端のRTP再送制御装置30の構成を示すブロック図である。
【図4】本発明による再送制御装置20,30を用いたインターネットMPEG−4配信システムの構成例を示すブロック図である。
【図5】図4に示すインターネットMPEG−4配信システムのデータ伝送に係る基本構成を示すブロック図である。
【図6】APP−RTCPパケットの構成を示す図である。
【図7】RTPパケットのフォーマットを示す図である。
【図8】RTPヘッダの構成を示す図である。
【符号の説明】
10…RTP受信端末、15…MPEG−4再生端末、20,30…RTP再送制御装置、40…RTP送信装置、45…MPEG−4ビデオサーバ、50…インターネット、210,250,310,370…多重化復元部、220,320,380…RTP解析部、230,260,330,390…多重化部、240,360…再送制御部、340…データ管理部、350…データ蓄積部
[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a communication device and a communication system that control packet retransmission.
[0002]
[Prior art]
In a packet communication method using UDP (User Datagram Protocol) and IP (Internet Protocol), a UDP port number is added to an IP packet, but data is transmitted using the IP packet almost as it is. At the IP layer level, packets may be discarded due to congestion or the like, but UDP does not take this countermeasure.
[0003]
RTP (Realtime Transport Protocol) is a protocol used on UDP and IP, and provides a function of detecting a packet discarded on a communication path. The packet discard detection function of the RTP will be described. FIG. 7 is a diagram showing a format of the RTP packet. FIG. 8 is a diagram showing the configuration of the RTP header shown in FIG. The IP header includes an IP address and the like, and the UDP header includes a port number and the like.
[0004]
In RTP, the sequence number in the RTP header in FIG. 8 is changed one by one for each packet. Then, the receiving side identifies the discarded packet by detecting the discontinuity of the sequence number. However, the RTP does not specify the handling of the discarded packet, and performs a discard countermeasure process using a higher-level protocol. The type (payload type) in Fig. 8 indicates which upper layer protocol the packet is processed (for example, in the case of H.263, type "34").
[0005]
Next, a retransmission function of TCP (Transmission Control Protocol) will be described. TCP is a protocol used over IP and widely used in the Internet. In TCP, a TCP header has fields of a sequence number and a reception confirmation sequence number. The transmitting side attaches a sequence number to each packet and transmits the packet. The receiving side inserts the sequence number (reception confirmation sequence number) confirmed by the reception of the packet into the reception confirmation sequence number field and transmits the packet to the transmission side. The transmission side confirms the delivery of the transmitted packet based on the reception confirmation sequence number. If the acknowledgment of the transmission of the transmitted packet is not performed within a certain timeout period, the transmitting side retransmits the unacknowledged packet. As a result, all packets are normally delivered, and the reliability of communication data is ensured.
Further, unlike the RTP, the TCP checks received data by CRC and performs rate control for avoiding congestion. Therefore, the processing load is generally higher than that using UDP / IP, and applications requiring real-time properties are required. Often does not apply.
[0006]
There is also an apparatus that controls retransmission using an ARQ (Automatic Repeat Request) method (for example, see Patent Document 1). In the ARQ scheme, retransmission control is performed by returning an acknowledgment (ACK) for a received packet, and returning a negative acknowledgment (NAK) for a packet that could not be received.
[0007]
[Patent Document 1]
JP-A-11-88466
[Problems to be solved by the invention]
However, as described above, the function of detecting packet discard is provided in RTP, but the function of retransmitting the discarded packet depends on the upper layer protocol. Therefore, when reliability of communication data is required, since RTP does not include a retransmission protocol, it is necessary to use another protocol having a retransmission function such as TCP. However, there are problems such as a decrease in performance and a limitation of connectable communication devices.
[0009]
Further, in the ARQ method, since an acknowledgment (ACK) is transmitted, there is a problem that the use efficiency of the bandwidth resource is reduced. Further, since retransmission control is performed for all packets to be transmitted and received, unnecessary packets are retransmitted, and communication efficiency deteriorates.
[0010]
The present invention has been made in view of such circumstances, and an object of the present invention is to efficiently perform packet retransmission without affecting a communication device that transmits and receives real-time data by packet communication using RTP. It is an object of the present invention to provide a communication device and a communication system that can perform well.
[0011]
[Means for Solving the Problems]
In order to solve the above problem, a communication device according to claim 1 includes a receiving unit that receives a packet, an identifying unit that identifies a type of the packet received by the receiving unit, and a receiving unit that receives the packet. Detecting means for detecting a sequence number included in the packet when identifying the packet, determining means for determining packet discard based on the sequence number detected by the detecting means, when the packet is discarded by the determining means, Retransmission request means for requesting retransmission of the packet.
[0012]
The communication device according to claim 2, wherein a transmission protocol of the packet is RTP, and a retransmission request of the retransmission request unit is added to an RTCP APP packet.
[0013]
4. The communication apparatus according to claim 3, wherein the transmitting unit adds a type to the packet and transmits the packet, a storage unit that stores the packet transmitted by the transmitting unit, a receiving unit that receives the packet, and retransmits the packet by the receiving unit. When receiving the request packet, there is provided control means for reading out a packet corresponding to the retransmission request from the storage means and transmitting the packet from the transmission means.
[0014]
5. The communication device according to claim 4, wherein a transmission protocol of the packet is RTP, and the control unit deletes all data in the storage unit when the receiving unit receives an RTCP BYE packet. And
[0015]
The communication system according to claim 5, wherein the communication terminal transmits at least a video signal compressed according to the MPEG-4 system from a transmission terminal to a reception terminal using RTP, wherein the transmission terminal includes a header of an RTP packet to be transmitted. The transmitting terminal further includes a transmitting unit for transmitting by adding the type of the element stream, and the receiving terminal determines whether the type of the element stream added to the header of the RTP packet received from the transmitting terminal is a type requiring retransmission. Identification means for identification, detection means for detecting a sequence number included in the packet when the identification means identifies the type as requiring retransmission, and determination of packet discard based on the sequence number detected by the detection means Determining means for determining whether to discard a packet. Characterized in that a retransmission request means for requesting.
[0016]
The communication system according to claim 6, wherein the retransmission request of the retransmission request unit is added to an RTCP APP packet.
[0017]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram illustrating a configuration example of a communication system using retransmission control devices 20 and 30 (communication devices) according to an embodiment of the present invention. The communication system shown in FIG. 1 includes an RTP reception terminal 10, an RTP retransmission control device 20 located at an RTP packet reception end, an RTP retransmission control device 30 located at an RTP packet transmission end, and an RTP transmission device 40. .
The RTP transmitting device 40 provides data to the RTP receiving terminal 10 by packet communication using RTP. The RTP transmitting device 40 and the RTP receiving terminal 10 mutually transmit and receive RTP packets.
[0018]
The RTP retransmission control device 20 is connected to a highly reliable local network to which the RTP receiving device 10 is connected, and to the Internet 50. The RTP retransmission control device 20 has a function of transferring an RTP packet received from the Internet 50 to a local network and a function of retransmitting the RTP packet. The RTP retransmission control device 20 at the receiving end receives the RTP packet from the Internet 50, detects an RTP packet requiring retransmission, and transmits a retransmission request to the RTP retransmission control device 30 at the transmitting end.
[0019]
The RTP retransmission control device 30 is connected to a highly reliable local network to which the RTP transmission device 40 is connected, and to the Internet 50. The RTP retransmission control device 30 has a function of transferring an RTP packet received from the RTP transmission device 40 via the local network to the Internet 50, and a function of retransmitting the RTP packet. The RTP retransmission control device 30 at the transmission end monitors the packet sequence, accumulates RTP packets requiring reliability, and stores the accumulated RTP packets when there is a retransmission request from the RTP retransmission control device 20 at the reception end. resend.
[0020]
FIG. 2 is a block diagram showing the configuration of the RTP retransmission control device 20 at the receiving end shown in FIG. In FIG. 2, the multiplexing / restoring unit 210 receives the packet sequence transmitted from the RTP retransmission control device 30 at the transmitting end via the Internet 50, decomposes the packet sequence, and outputs the packet sequence to the RTP analysis unit 220.
The RTP analysis unit 220 determines whether the received RTP packet is an RTP packet included in the stream to be retransmitted, and performs a discard detection process on only the RTP packet to be retransmitted. The determination as to whether the stream is included in the retransmission target stream is made based on the value of the type (payload type) of the RTP header in FIG.
[0021]
In the discard detection process, the RTP analysis unit 220 checks the sequence number included in the RTP packet to be retransmitted, and compares the sequence number with the sequence number to be received next. As a result of the comparison, if the sequence numbers are different, it is determined that the packet has been discarded, and the sequence number of the discarded RTP packet is notified to the retransmission control unit 240 to instruct retransmission. Further, the RTP packets of the corresponding stream arriving after the time when the packet discard is detected are accumulated.
[0022]
Upon receiving a retransmission instruction from RTP analysis section 220, retransmission control section 240 generates an APP-RTCP packet for retransmitting the RTP packet of the notified sequence number, and outputs the APP-RTCP packet to multiplexing section 260. The APP-RTCP packet indicates an RTCP application-defined packet.
The multiplexing / restoring unit 250 receives the packet sequence transmitted from the RTP receiving terminal 10 via the local network, decomposes the packet sequence, and outputs the packet sequence to the multiplexing unit 260.
The multiplexing unit 260 multiplexes the APP-RTCP packet input from the retransmission control unit 240 with the packet input from the multiplexing decompression unit 250 and transmits the multiplexed packet to the RTP retransmission control device 30 at the transmission end via the Internet 50. .
[0023]
When receiving the retransmission packet from the RTP retransmission control device 30 via the Internet 50, the RTP analysis unit 220 outputs the retransmission packet and the stored RTP packet of the corresponding stream to the multiplexing unit 230 in sequence number order. The multiplexing unit 230 multiplexes the input packet and transmits the multiplexed packet to the RTP receiving terminal 10 via the local network. As a result, the RTP packets arrive at the RTP receiving terminal 10 in the order of the sequence numbers.
[0024]
Note that the RTP packets received from the Internet 50 may be sequentially transmitted to the RTP receiving terminal 10, and the received retransmission packets may be transmitted to the RTP receiving terminal 10 as they are. However, in this case, the RTP receiving terminal 10 rearranges the received packets in the order of the sequence numbers.
[0025]
FIG. 3 is a block diagram showing a configuration of the RTP retransmission control device 30 at the transmitting end shown in FIG. In FIG. 3, the multiplex restoration unit 310 receives a packet sequence transmitted from the RTP transmitting device 40 via a local network, decomposes the packet sequence, and outputs the packet sequence to the RTP analysis unit 320.
RTP analysis section 320 determines whether or not the received RTP packet is a packet included in the stream to be retransmitted, and stores only the RTP packet to be retransmitted in data storage section 350. Further, RTP analysis section 320 outputs the packet input from multiplexing / decompression section 310 to multiplexing section 330.
[0026]
The demultiplexing unit 370 receives the packet sequence transmitted from the RTP retransmission control device 20 at the receiving end via the Internet 50, decomposes the packet sequence, and outputs it to the RTP analysis unit 380.
When detecting the APP-RTCP packet generated by the RTP retransmission control device 20 at the receiving end, the RTP analysis unit 380 extracts a sequence number to be retransmitted from the APP-RTCP packet, and instructs the retransmission control unit 360 to perform retransmission. I do. All other packets are output to the multiplexer 390.
The multiplexing unit 390 multiplexes the input packet and transmits the multiplexed packet to the RTP transmitting terminal 40 via the local network.
[0027]
Retransmission control section 360 reads out the RTP packet of the sequence number specified by RTP analysis section 380 from data storage section 350 and outputs it to multiplexing section 330.
The multiplexing unit 330 multiplexes the retransmission packet input from the retransmission control unit 360 and the packet input from the RTP analysis unit 320, and transmits the multiplexed packet to the RTP retransmission control device 20 at the receiving end via the Internet 50.
The data management unit 340 deletes unnecessary packets from the data storage unit 350 among the RTP packets stored in the data storage unit 350.
[0028]
Next, an Internet MPEG-4 distribution system will be described as an embodiment of a communication system using the above-described retransmission control devices 20 and 30 according to the present invention. FIG. 4 is a block diagram showing a configuration example of the Internet MPEG-4 distribution system. FIG. 5 is a block diagram showing a basic configuration related to data transmission of the Internet MPEG-4 distribution system shown in FIG.
The Internet MPEG-4 distribution system includes an MPEG-4 playback terminal 15, the RTP retransmission control device 20 of FIG. 2 located at the RTP packet receiving end, and the RTP retransmission control device 30 of FIG. 3 located at the RTP packet transmitting end. And an MPEG-4 video server 45.
[0029]
The MPEG-4 video server 45 stores video image data and scene description data that have been encoded in advance according to the MPEG-4 standard. The MPEG-4 video server 45 transmits the video image data and the scene description data to the RTP retransmission control device 30. The RTP retransmission control device 30 transfers the received video image data and scene description data to the RTP retransmission control device 20 via the Internet 50. The RTP retransmission control device 20 transmits the received video image data and scene description data to the MPEG-4 playback terminal 15. An independent element stream is used for the transmission format of the scene description data and the video image data. To distinguish this element stream, the payload type of the RTP header is used.
[0030]
In the Internet 50 shown in FIG. 4, when the communication channel is congested, the packet is discarded without discriminating whether a certain RTP packet contains video image data or scene description data. . The MPEG-4 scene description data includes characters and graphics in a scene and information on how to display a video image in the scene. For this reason, if scene description data is lost due to packet discarding, the adverse effect on communication quality is large, such as the worst case of not displaying the entire video. On the other hand, the elementary stream of video image data contains a lot of information, and even if one RTP packet is discarded, the image quality deteriorates in a part of one frame. Absent. Therefore, the elementary stream of the scene description data requires higher communication reliability than the stream of the video image data.
[0031]
Next, an operation related to retransmission control of the Internet MPEG-4 distribution system of FIG. 4 will be described. Hereinafter, portions corresponding to FIGS. 2 and 3 are denoted by the same reference numerals.
In the RTP retransmission control device 30 at the transmitting end, the multiplexing / restoring unit 310 decomposes the signal received from the MPEG-4 video server 45 into IP packets and outputs the IP packets to the RTP analyzing unit 320. The RTP analysis unit 320 extracts only the received RTP packet, but does not discard, replace, or rewrite the packet, and outputs the packet to the multiplexing unit 330 as it is. The RTP analysis unit 320 accumulates a packet whose payload type is a scene description stream among the received RTP packets in the data accumulation unit 350, and records information in a management table of the data management unit 340.
[0032]
In the RTP retransmission control device 20 at the receiving end, the demultiplexing unit 210 receives the packet sequence transmitted from the RTP retransmission control device 30 at the transmission end via the Internet 50, and decomposes the packet sequence into IP packets. Output to the RTP analysis unit 220. The RTP analysis unit 220 extracts a sequence number of a packet, which is an RTP packet and has a payload type of a scene description stream, from among the received IP packets. If the difference between this sequence number and the sequence number of the previously received RTP packet of the scene description stream is not 1, the RTP analysis unit 220 determines that packets between those sequence numbers have been discarded. Then, it notifies the retransmission control unit 240 of the sequence number determined to have been discarded.
[0033]
Upon receiving the sequence number from RTP analysis section 220, retransmission control section 240 creates an APP-RTCP packet to be transmitted to RTP retransmission control apparatus 30 at the transmitting end. FIG. 6 shows the configuration of the APP-RTCP packet.
[0034]
As shown in FIG. 6, "204" representing APP is used in the type field of the RTCP header for the APP-RTCP packet, and the value of the receiving terminal (MPEG-4 playback terminal 15) is used for the sender identifier. The RTCP payload includes a unique code of an application identifier, the number of sequence numbers that need to be retransmitted, and a sequence number sequence.
[0035]
Retransmission control section 240 outputs the created APP-RTCP packet to multiplexing section 260. The multiplexing unit 260 multiplexes the APP-RTCP packet and the RTCP packet returned by the MPEG-4 playback terminal 15 to the MPEG-4 video server 45, and transmits the RTP retransmission control device at the transmission end via the Internet 50. Send to 30.
[0036]
In the RTP retransmission control device 30 at the transmission end, the multiplexing / restoring unit 370 decomposes a packet sequence received via the Internet 50 into IP packets and outputs the IP packets to the RTP analyzing unit 380. The RTP analysis unit 380 extracts, from the received APP-RTCP packets, those generated by the RTP retransmission control device 20 at the receiving end, and multiplexes the other packets to the MPEG-4 video server 45 by the multiplexing unit 390. Send. RTP analysis section 380 notifies retransmission control section 360 of the sequence number of the retransmission request target included in the extracted APP-RTCP packet.
[0037]
Upon receiving the sequence number, retransmission control section 360 reads a packet having the sequence number from data storage section 350 and outputs the packet to multiplexing section 330. The multiplexing unit 330 multiplexes the retransmission packet and another RTP packet, and transmits the multiplexed packet to the RTP retransmission control device 20 at the receiving end via the Internet 50.
[0038]
The data management unit 340 deletes unnecessary packets from the data storage unit 350 among the RTP packets stored in the data storage unit 350. If the sequence number of the packet stored in the data storage unit 350 by the RTP analysis unit 320 is the same as the sequence number of the already stored packet, the data management unit 340 stores the already stored packet in the data storage unit. It is deleted from the section 350. Note that the sequence number is composed of 16 bits, and the value is cyclic. When the BYE-RTCP packet is received and the RTP analysis unit 320 detects that the RTP session has been completed, the data management unit 340 stores all the RTP packets of the RTP session from the data storage unit 350 by this detection. delete.
[0039]
In this embodiment, the communication device on the receiving side is composed of an RTP retransmission control device and an RTP receiving terminal (or MPEG-4 playback terminal) connected by a local area network, and the communication device on the transmission side is an RTP retransmission control device. And an RTP transmission terminal (or MPEG-4 video server) connected by a local area network, but may be configured to include all of the communication terminals without being connected by the local area network.
[0040]
As described above, the embodiments of the present invention have been described in detail with reference to the drawings. However, the specific configuration is not limited to the embodiments, and includes a design change or the like without departing from the gist of the present invention.
[0041]
【The invention's effect】
As described above, according to the present invention, retransmission control is performed with only RTP packets used for predetermined streaming as retransmission targets, for example, which affects communication devices that exchange data by packet communication using RTP. Thus, the packet can be efficiently retransmitted. Thereby, in communication using, for example, RTP / UDP / IP, the reliability of important communication streams can be ensured without changing the transmission server and the receiving terminal.
[0042]
Further, among the transmission packets stored for retransmission, unnecessary packets are deleted, so that the packet storage efficiency is improved.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a communication system using retransmission control devices 20 and 30 according to an embodiment of the present invention.
FIG. 2 is a block diagram showing a configuration of an RTP retransmission control device 20 at an RTP packet receiving end.
FIG. 3 is a block diagram illustrating a configuration of an RTP retransmission control device 30 at an RTP packet transmitting end.
FIG. 4 is a block diagram showing a configuration example of an Internet MPEG-4 distribution system using the retransmission control devices 20 and 30 according to the present invention.
5 is a block diagram showing a basic configuration related to data transmission of the Internet MPEG-4 distribution system shown in FIG.
FIG. 6 is a diagram showing a configuration of an APP-RTCP packet.
FIG. 7 is a diagram showing a format of an RTP packet.
FIG. 8 is a diagram showing a configuration of an RTP header.
[Explanation of symbols]
10 RTP receiving terminal, 15 MPEG-4 playback terminal, 20, 30 RTP retransmission control device, 40 RTP transmission device, 45 MPEG-4 video server, 50 Internet, 210, 250, 310, 370 multiplexing RTP analysis unit, 230, 260, 330, 390 Multiplexing unit, 240, 360 Retransmission control unit, 340 Data management unit, 350 Data storage unit

Claims (6)

パケットを受信する受信手段と、
該受信手段が受信したパケットの種別を識別する識別手段と、
該識別手段が所定のパケットを識別した時に該パケットに含まれるシーケンス番号を検出する検出手段と、
該検出手段が検出したシーケンス番号に基づいてパケット廃棄を判定する判定手段と、
該判定手段によりパケット廃棄と判定されると、当該パケットの再送を要求する再送要求手段と、
を備えたことを特徴とする通信装置。
Receiving means for receiving the packet;
Identifying means for identifying the type of packet received by the receiving means;
Detecting means for detecting a sequence number included in the packet when the identification means has identified a predetermined packet;
Determining means for determining packet discard based on the sequence number detected by the detecting means;
Retransmission request means for requesting retransmission of the packet when the packet is determined to be discarded by the determination means;
A communication device comprising:
前記パケットの伝送プロトコルはRTPであり、前記再送要求手段の再送要求はRTCPのAPPパケットに付加することを特徴とする請求項1に記載の通信装置。2. The communication apparatus according to claim 1, wherein a transmission protocol of the packet is RTP, and a retransmission request of the retransmission request unit is added to an RTCP APP packet. パケットに種別を付加して送信する送信手段と、
該送信手段が送信したパケットを記憶する記憶手段と、
パケットを受信する受信手段と、
該受信手段により再送要求のパケットを受信した時に当該再送要求に応じたパケットを前記記憶手段より読み出して前記送信手段から送信するよう制御する制御手段と、
を備えたことを特徴とする通信装置。
Transmitting means for adding a type to the packet and transmitting the packet;
Storage means for storing the packet transmitted by the transmission means,
Receiving means for receiving the packet;
Control means for controlling when a packet of a retransmission request is received by the receiving means to read a packet corresponding to the retransmission request from the storage means and to transmit the packet from the transmission means;
A communication device comprising:
前記パケットの伝送プロトコルはRTPであり、前記制御手段は前記受信手段がRTCPのBYEパケットを受信した時は前記記憶手段のデータを全て削除することを特徴とする請求項3に記載の通信装置。4. The communication apparatus according to claim 3, wherein a transmission protocol of the packet is RTP, and the control unit deletes all data in the storage unit when the reception unit receives an RTCP BYE packet. 少なくともMPEG−4方式により圧縮された映像信号をRTPを用いて送信端末から受信端末へ伝送する通信システムにおいて、
前記送信端末は、
送信するRTPパケットのヘッダにエレメントストリームのタイプを付加して送信する送信手段を備え、
前記受信端末は、
前記送信端末から受信したRTPパケットのヘッダに付加されているエレメントストリームのタイプが再送を必要とするタイプか否かを識別する識別手段と、
該識別手段が再送を必要するタイプであると識別した時に当該パケットに含まれるシーケンス番号を検出する検出手段と、
該検出手段が検出したシーケンス番号に基づいてパケット廃棄を判定する判定手段と、
該判定手段によりパケット廃棄と判定されると、当該パケットの再送を要求する再送要求手段と、
を備えたことを特徴とする通信システム。
In a communication system for transmitting at least a video signal compressed by MPEG-4 from a transmitting terminal to a receiving terminal using RTP,
The transmitting terminal,
Transmission means for adding an element stream type to a header of an RTP packet to be transmitted and transmitting the element stream;
The receiving terminal,
Identification means for identifying whether or not the type of the element stream added to the header of the RTP packet received from the transmitting terminal is a type requiring retransmission;
Detecting means for detecting a sequence number included in the packet when the identification means identifies the type as requiring retransmission;
Determining means for determining packet discard based on the sequence number detected by the detecting means;
Retransmission request means for requesting retransmission of the packet when the packet is determined to be discarded by the determination means;
A communication system comprising:
前記再送要求手段の再送要求はRTCPのAPPパケットに付加することを特徴とする請求項5に記載の通信システム。The communication system according to claim 5, wherein the retransmission request of the retransmission request unit is added to an RTCP APP packet.
JP2002347870A 2002-11-29 2002-11-29 Communication apparatus and communication system Pending JP2004186737A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002347870A JP2004186737A (en) 2002-11-29 2002-11-29 Communication apparatus and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002347870A JP2004186737A (en) 2002-11-29 2002-11-29 Communication apparatus and communication system

Publications (1)

Publication Number Publication Date
JP2004186737A true JP2004186737A (en) 2004-07-02

Family

ID=32750932

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002347870A Pending JP2004186737A (en) 2002-11-29 2002-11-29 Communication apparatus and communication system

Country Status (1)

Country Link
JP (1) JP2004186737A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2911231A1 (en) * 2007-01-09 2008-07-11 Tdf Sa REAL-TIME PACKET DATA TRANSMIT / RECEIVE METHOD BETWEEN SERVER AND CUSTOMER TERMINAL, SERVER AND TERMINAL THEREOF

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2911231A1 (en) * 2007-01-09 2008-07-11 Tdf Sa REAL-TIME PACKET DATA TRANSMIT / RECEIVE METHOD BETWEEN SERVER AND CUSTOMER TERMINAL, SERVER AND TERMINAL THEREOF
WO2008087364A3 (en) * 2007-01-09 2008-09-12 Tdf Method of real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal
AU2007344308B2 (en) * 2007-01-09 2012-04-12 Tdf Method of real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal

Similar Documents

Publication Publication Date Title
US7315898B2 (en) Data communication system, data transmission apparatus, data reception apparatus, data communication method, and computer program
US7380014B2 (en) Reliable real-time transport protocol
EP2529528B1 (en) A method and apparatus for parsing a network abstraction-layer for reliable data communication
US8175036B2 (en) Multimedia wireless distribution systems and methods
EP1180870A2 (en) Packet retransmission using priority information
EP1301041A1 (en) Video data transmission method and apparatus
WO2003094449A1 (en) Method and apparatus for multicast delivery of information
JP2004007823A (en) Method and apparatus for data transmission
JP2005512400A (en) Data transmission
KR101438005B1 (en) Method for the real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal
US20060259845A1 (en) Method and apparatus for acknowledging a bitwise data chunk in wireline and wireless communication systems
US20050102416A1 (en) Modifications of tcp/ip
US20220123869A1 (en) Network equipment and method for delivering data packets
CN114051173B (en) RTP extension header-based video frame reliable transmission method, device and equipment
US8578040B2 (en) Method, system and article for client application control of network transmission loss tolerance
CN115883680A (en) UDP (user Datagram protocol) data transmission method, system and equipment based on ARQ (automatic repeat request)
JP2004186737A (en) Communication apparatus and communication system
EP1450535A1 (en) A relay for hierarchical retransmissions in multimedia streaming
WO2024022334A1 (en) Data transmission method, apparatus and system
WO2024022335A1 (en) Data transmission method, apparatus and system
EP1733527B1 (en) Technique for handling outdated information units
JP3594195B2 (en) Data transmission device and data transmission method
JP2004048408A (en) Re-transmission method
JP3594196B1 (en) Data transmission device and data transmission method
JP2002135302A (en) Data transmission device and data transmission method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050413

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20061117

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061128

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070126

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070403