JP2004186737A - Communication apparatus and communication system - Google Patents
Communication apparatus and communication system Download PDFInfo
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
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
[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
The
[0018]
The RTP
[0019]
The RTP
[0020]
FIG. 2 is a block diagram showing the configuration of the RTP
The
[0021]
In the discard detection process, the
[0022]
Upon receiving a retransmission instruction from
The multiplexing / restoring
The
[0023]
When receiving the retransmission packet from the RTP
[0024]
Note that the RTP packets received from the
[0025]
FIG. 3 is a block diagram showing a configuration of the RTP
[0026]
The
When detecting the APP-RTCP packet generated by the RTP
The
[0027]
The
The
[0028]
Next, an Internet MPEG-4 distribution system will be described as an embodiment of a communication system using the above-described
The Internet MPEG-4 distribution system includes an MPEG-4
[0029]
The MPEG-4
[0030]
In the
[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
[0032]
In the RTP
[0033]
Upon receiving the sequence number from
[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]
[0036]
In the RTP
[0037]
Upon receiving the sequence number,
[0038]
The
[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
FIG. 2 is a block diagram showing a configuration of an RTP
FIG. 3 is a block diagram illustrating a configuration of an RTP
FIG. 4 is a block diagram showing a configuration example of an Internet MPEG-4 distribution system using the
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:
該送信手段が送信したパケットを記憶する記憶手段と、
パケットを受信する受信手段と、
該受信手段により再送要求のパケットを受信した時に当該再送要求に応じたパケットを前記記憶手段より読み出して前記送信手段から送信するよう制御する制御手段と、
を備えたことを特徴とする通信装置。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パケットのヘッダにエレメントストリームのタイプを付加して送信する送信手段を備え、
前記受信端末は、
前記送信端末から受信した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:
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)
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 |
-
2002
- 2002-11-29 JP JP2002347870A patent/JP2004186737A/en active Pending
Cited By (3)
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 |