JP4433281B2 - 受信装置および方法、記録媒体、並びにプログラム - Google Patents

Description

本発明は、受信装置および方法、記録媒体、並びにプログラムに関し、特に、ストリーミング型のデータ通信において、損失パケットに対する再送要求通知パケットを送信側へ効果的に到達させるようにすることで、ストリーミング型のデータ通信の信頼性を向上させ、品質の高いデータ通信を行うことができるようにした受信装置および方法、記録媒体、並びにプログラムに関する。

昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の通信方式のサービスに加えて、ストリーム型の通信方式のサービスがより多く提供されるようになってきた。

ダウンロード型の通信方式のサービスにおいては、受信装置が、送信装置から送信された画像または音声のデータを格納したファイルを受信し、受信したファイルを自分の記録媒体に記録する。受信装置は、ファイルの記録が完了した後、記録したファイルを基に、画像または音声を再生する。ダウンロード型の通信方式のサービスにおいては、ファイルの記録が完了するまでは、画像または音声を再生することができないので、ダウンロード型の通信方式のサービスは、長時間の再生またはリアルタイムの再生には適さない。

一方、ストリーム型の通信方式のサービスにおいては、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の通信方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。

ストリーム型の通信方式において、送信装置から送信されてくるデータを、一般にストリーミングデータと称する。

より具体的な例として、ストリーム型の通信方式は、画像データにMPEG（Moving Picture Experts Group）符号化処理を適用することにより生成されるMPEGストリームを格納する、IP（Internet Protocol）パケットをインターネットを介して伝送するシステムで使用される。このシステムにおいて、受信装置である、例えば、PC（Personal Computer）、PDA（Personal Digital Assistance）、または携帯電話機は、IPパケットを受信し、画像を再生する。

ストリーム型の通信方式は、ビデオオンデマンド若しくはライブ映像のストリーミング配信、ビデオ会議、またはテレビ電話などのリアルタイム通信に適している。

このようなストリーム型の通信方式の技術の１つとして、IETF RFC（Internet Engineering Task Force Request For Comments）１８８９で規定されているプロトコルであるRTP（Real time Transport Protocol）がある。

RTPに基づくデータ通信においては、時刻を示すタイムスタンプがパケットに付加され、タイムスタンプの参照により送信側と受信側の時間的関係が把握されるので、受信側において、パケット通信の遅延ゆらぎ（ジッタ）などの影響が排除され、同期した再生が可能になる。

しかしながら、RTPにおいて、実時間のデータの伝送は保証されない。すなわち、パケット転送の優先度や設定、管理などは、RTPによって提供されるトランスポートサービスの範疇ではないため、他の方式のパケットと同様、ネットワーク上での遅延やパケットロスが生じる可能性がある。

遅延やパケットロスが生じても、受信側は、再生時刻までに受信されたパケットだけを利用してデータを再生することができる。すなわち、受信装置は、データに多少の損失や誤りが発生しても、品質を落として再生するか、またはデータの損失や誤りを訂正して再生する。

この場合、再生に間に合わず遅れて到着したパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、高品質なデータを送信しても、パケットロスやエラー、パケット到着の遅れ等が発生することから、受信側の再生の品質は保証されない。

特に、有線区間で10^-5、無線区間で10^-3以上のエラーがあると言われている中では、転送データの品質を維持することに関して、RTPをそのまま利用するのでは信頼性が低い。

このようなRTPに従ったデータ通信における問題を解決する案として、データ通信において信頼性のより高い通信プロトコルであるTCP（Transmission Control Protocol）に従ってパケットの再送要求およびパケットの再送を行う方法が考えられる。

しかしながら、TCPにおいて、パケットロスが生じた場合、パケットが再送されるので、エラーには強いが、スループットが低く、遅延が大きいため、受信側において、再送されたパケットの受信が再生時刻に間に合わない可能性があり、リアルタイム通信には不向きである。

したがって、送信と受信の遅延が少ないARQ（Automatic Repeat reQuest）などの技術が必要とされる。

これは、RTPパケットに設定されているシーケンス番号を用いて損失パケットを検出し、受信端末から送信端末へ、損失パケットの再送を要求する方式である。

例えば、再送処理タイミングとして、各フレームの最終パケット受信時、各フレームの先頭パケット受信時、最終処理期限、および一定間隔毎等の各種タイミングで損失パケットの検出処理を実行し、再送要求を行い、データ受信端末が再生処理時間、伝播遅延時間、を考慮し、再生処理に間に合わない場合には、再送要求処理を実行しないようにしているものがある。（特許文献１参照）

特開２００３−１６９０４０号公報

しかしながら、上述したARQについては、損失パケットの再送を要求するパケット自身がネットワーク上で損失し、そのパケットによって再送を要求しようとしていた損失パケットの再送処理が行われない可能性があるため、通信の信頼性において充分ではなかった。

本発明は、このような状況に鑑みてなされたものであり、損失パケットの再送を要求するパケットが高い確率で相手（送信装置）に到達するようにするものである。

本発明の受信装置は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差であって、パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定手段と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、送信装置に送信する場合における制御を要求レベルに従って行う再送要求通知送信制御手段とを備えることを特徴とする。

再送要求通知送信制御手段は、要求レベルに従って、再送要求通知パケットを送信する送信パケット数を決定し、決定した送信パケット数だけの再送要求通知パケットを送信するようにすることができる。

本発明の受信方法は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差であって、パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、送信装置に送信する場合における制御を要求レベルに従って行う再送要求通知送信制御ステップとを含むことを特徴とする。

本発明の記録媒体に記録されているプログラムは、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差であって、パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、送信装置に送信する場合における制御を要求レベルに従って行う再送要求通知送信制御ステップとを含むことを特徴とする。

本発明のプログラムは、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差であって、パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、送信装置に送信する場合における制御を要求レベルに従って行う再送要求通知送信制御ステップとをコンピュータに実行させる。

本発明の受信装置および方法、記録媒体、並びにプログラムにおいては、正常にパケットが受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルが、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差であって、パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定され、正常に受信できなかったパケットの再送を要求する再送要求通知パケットが送信装置に送信される場合における制御が要求レベルに従って行われる。

受信装置は、独立した装置であっても良いし、通信装置の受信処理を行うブロックであっても良い。

本発明によれば、損失パケットの受信の緊急性に応じて、再送を要求するパケットの送信を制御することができ、再生時刻までに、損失パケットを受信する確立を高めることができる。その結果、ストリーミングデータ通信において、信頼性の高いデータ通信および、高品位なメディア再生を実現することができる。

本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システムなどのリアルタイムにストリーミングデータを転送する通信システムに適用することができる。

図１は、本発明を適用した通信システムの一実施の形態の構成例を示すブロック図である。

図１において、通信システムは、送信側端末１２と受信側端末１４とが、IPネットワーク１３を介して接続されて構成されている。

ビデオカメラ１１は、動画を撮影し、送信側端末１２へ画像データと音声データを供給する。

画像データや音声データはストリーミングデータの一例であり、ストリーミングデータは、リアルタイム制御データなど、時間経過に対応して順次に送信または受信が要求されるデータであればよい。

送信側端末１２は、ビデオカメラ１１から供給されたデータをパケットに格納し、IPネットワーク１３を介して、受信側端末１４へ送信する。

受信側端末１４は、IPネットワーク１３を介して送信側端末１２から送信されてきたパケットを受信し、そのパケットに格納されているデータを抽出して、画像データまたは音声データに復元する。

受信側端末１４は、送信側端末１２から連続して送信されてくるストリーミングデータが格納されたパケットの中に、正常に受信できないパケットがあった場合、送信側端末１２に対して再送を要求し、送信側端末１２は、受信側端末１４からの要求に対応したパケットを再送する。

送信側端末１２は、エンコーダ２１、バッファ２２、RTPパケット作成部２３、ＲＴＰ出力ポート２４、通信部２５、RTCP入出力ポート２６、RTCPパケット解析部２７、ARQ解析部２８、およびRTCPパケット作成部２９から構成される。

エンコーダ２１は、ビデオカメラ１１から供給されたデータの符号化を行う。エンコーダ２１で符号化されたデータはバッファ２２に供給され、蓄積される。

RTPパケット作成部２３は、バッファ２２に蓄積されたデータを定期的に読み込み、RTPパケットを作成し、RTP出力ポート２４を介して通信部２５に供給する。

また、RTPパケット作成部２３は、バッファ２２に蓄積された全データの送信が完了した場合、RTCPパケット作成部２９に対して、EOS（End Of Stream）パケット作成の指示を行う。

RTP出力ポート２４は、RTPパケット作成部２３から供給されたRTPパケットを通信部２５へ供給する。

通信部２５は、RTP出力ポート２４を介してRTPパケット作成部２３から供給されたRTPパケットをもとにIPパケットを作成し、IPネットワーク１３を介して、受信側端末１４へ送信する。

また、通信部２５は、IPネットワーク１３を介して受信側端末１４から送信されてきたIPパケットを受信し、RTCP入出力ポート２６を介してRTCPパケット解析部２７に供給する。

RTCP入出力ポート２６は、通信部２５から供給されたRTCPパケットをRTCPパケット解析部２７に供給する。

RTCPパケット解析部２７は、RTCP入出力ポート２６を介して供給されたRTCPパケットのヘッダ部を解析し、そのRTCPパケットが、パケットの再送を要求する再送要求通知パケットであるかどうかを判定する。RTCPパケット解析部２７は、RTCPパケットが再送要求通知パケットであると判定した場合、ARQ解析部２８に、その再送要求通知パケットのデータ部を供給する。

ARQ解析部２８は、RTCPパケット解析部２７から供給された再送要求通知パケットのデータ部から、その再送要求通知パケットによって要求されたパケットを示すシーケンス番号などのパケットの再送処理に必要な情報を取得し、RTPパケット作成部２３に対して、パケットの再送処理を指示する。

RTCPパケット作成部２９は、RTPパケット作成部２３からの、EOSパケット作成の指示に従い、EOSパケットを作成し、RTCP入出力ポート２６を介して通信部２５に供給する。

受信側端末１４は、通信部３１、RTP入力ポート３２、RTPパケット解析部３３、バッファ３４、インデックスリスト３５、デコーダ３６、ARQ処理部３７、RTCPパケット作成部４０、RTCP入出力ポート４１、およびRTCPパケット解析部４２により構成される。

さらに、ARQ処理部３７は、パケット損失検出部３８、NACKパケット送信数決定部３９から構成されている。

通信部３１は、IPネットワークを介して送信側端末１２から送信されてくる各種パケットを受信し、受信パケットがRTPパケットの場合、そのRTPパケットを、RTP入力ポート３２を介してRTPパケット解析部３３へ供給する。また、通信部３１は、受信パケットがRTCPパケットの場合、そのRTCPパケットを、RTCP入出力ポート４１を介してRTCPパケット解析部４２へ供給する。

また、通信部３１は、RTCP入出力ポート４１を介してRTCPパケット作成部４０から供給された再送要求通知パケットであるRTCPパケットをもとにIPパケットを作成し、IPネットワーク１３を介して送信側端末１２へ送信する。

RTP入力ポート３２は、通信部３１から供給されたRTPパケットを、RTPパケット解析部３３へ供給する。

RTPパケット解析部３３は、RTP入力ポート３２を介して通信部３１から供給されたRTPパケットを解析し、受信したRTPパケットが正常なものであるか否かを判定する。RTPパケット解析部３３は、受信したRTPパケットが異常なものである場合（正常なものではない場合）、そのRTPパケットを破棄する。また、RTPパケット解析部３３は、受信したRTPパケットが正常なものである場合、そのRTPパケットを、ヘッダ部とデータ部とに分割し、データ部をバッファ３４へ、ヘッダ部をインデックスリスト３５およびパケット損失検出部３８へ供給する。

バッファ３４は、RTPパケット解析部３３から供給されたRTPパケットのデータ部を一時的に記憶する。

インデックスリスト３５は、RTPパケット解析部３３から供給されたRTPパケットのヘッダ部を一時的に記憶する。このとき、インデックスリスト３５は、ヘッダ部に対応するデータ部のバッファ３４内のアドレスを、ヘッダ部と関連付けて記憶する。

デコーダ３６は、定期的にインデックスリスト３５に蓄積されたヘッダ部のヘッダ情報をもとにして、バッファ３４から必要なデータ部のデータを読み出し、送信側端末１２のエンコーダ２１に対応する復号を行う。そして、デコーダ３６は、復号によって得られたデータをディスプレイ１５、またはスピーカ１６に出力する。

ARQ処理部３７を構成するパケット損失検出部３８は、RTPパケット解析部３３から供給されるRTPパケットのヘッダ部のヘッダ情報を元に、パケット損失チェックのタイミングを判断し、インデックスリスト３５に蓄積されているRTPパケットのヘッダ情報を解析して、パケット損失の有無を判定する。パケット損失検出部３８は、パケット損失を検出した場合（パケット損失ありの判定をした場合）、損失したパケットを示す情報をNACKパケット送信数決定部３９に供給する。

ARQ処理部３７を構成するNACKパケット送信数決定部３９は、パケット損失検出部３８から供給された損失パケットを示す情報をもとに、損失したパケットの再送を要求する再送要求通知パケットの送信数を決定し、損失したパケットを示す情報とともに、再送要求通知パケットの送信数を示す情報をRTCPパケット作成部４０に供給する。

RTCPパケット作成部４０は、NACKパケット送信数決定部３９から供給された情報をもとに、再送要求通知パケット（RTCPパケット）を作成し、NACKパケット送信数決定部３９によって決定された送信数だけ、RTCP入出力ポート４１を介して通信部３１へ供給する。以下、再送要求通知パケットを、適宜NACKパケットという。NACKパケットの詳細については後述する。

RTCP入出力ポート４１は、RTCPパケット作成部４０から供給されたRTCPパケット（NACKパケット）を通信部３１へ供給する。また、RTCP入出力ポート４１は、通信部３１から供給されたRTCPパケット（ＥＯＳパケット）をRTCPパケット解析部４２へ供給する。

RTCPパケット解析部４２は、通信部３１からRTCP入出力ポート４１を介して供給されたRTCPパケットを解析し、そのRTCPパケットが、ストリーミングデータの終了を表すEOSパケットであった場合、送信側端末１２においてストリーミングデータの送信が完了したことを認識する。

図２は、送信側端末１２においてストリーミングデータが格納され、受信側端末１４に送信されてくるパケットであるRTPパケットを説明する図である。

RTPパケットのヘッダ部は、バージョン番号、パディング、拡張ビット、counter、marker_bit、payload type、シーケンス番号、TIMESTAMP、同期ソース識別子、貢献ソース識別子の各フィールドから構成されている。

バージョン番号フィールドは、２ビットの領域であり、そこに記述されるバージョン番号はRTPパケットのバージョンを表す。

続いて配置されるパディングは、例えば、０が設定される１ビットの領域である。

拡張ビットフィールドは、１ビットの領域であり、そこに記述される拡張ビットは、拡張ヘッダの有無を表す。

counterフィールドは、４ビットの領域であり、そこに記述されるcounterは、貢献ソース識別子の設定数を表す。

marker_bitフィールドは、１ビットの領域であり、そこに記述されるmarker_bitは、プロファイルによって定義される。

payload typeフィールドは、７ビットの領域であり、そこに記述されるpayload type は、RTPペイロードのフォーマットを定義するための情報である。

シーケンス番号フィールドは、１６ビットの領域であり、そこに記述されるシーケンス番号は、パケットの順序を表す。また、シーケンス番号は、RTPパケットの送信の度に１つずつ増える情報である。シーケンス番号は、パケット損失を検出したり、受信したRTPパケットの順序を修復するために使用される。

TIMESTAMPフィールドは、３２ビットの領域であり、そこに記述されるTIMESTAMPは、RTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。

同期ソース識別子フィールドは、３２ビットの領域であり、そこに記述される同期ソース識別子には、送信元を示す識別子が設定される。

貢献ソース識別子は、３２ビットの領域であり、そこに記述される貢献ソース識別子は、最大１５個の貢献ソース識別子が設定可能である。この貢献ソース識別子の設定数は、上記のcounterに設定されている。貢献ソース識別子は、送信元が複数の場合に、それぞれの送信元から送信されたパケットが経由するミキサによって、それぞれのパケットに設定されている上記の同期ソース識別子が設定される。その際、同期ソース識別子には、ミキサを示す識別子が設定される。

図２において、以上のような各フィールドからなるヘッダ部に続くPayloadは、ストリーミングデータを示す。

図３は、受信側端末１４が送信側端末１２に送信する再送要求通知パケットとしてのNACKパケットを説明する図である。

NACKパケットには、バージョン番号、パディング、FORMAT、PayloadType、パケット長、送信同期ソース識別子（RTCP）、TIMESTAMPの情報に加え、再送要求対象となるパケットを示すシーケンス番号である再送指定シーケンス番号、再送要求回数、オプション（OPTION）、重複指定回数が設定可能である。

バージョン番号、パディングは、図２のRTPヘッダ部のバージョン番号とパディングと同様であるため、ここでの説明は省略する。

本実施の形態においては、NACKパケットおよびEOSパケット等の制御メッセージの区別に関して、RTCPヘッダのPayloadTypeによってのみ区別するのではなく、PayloadTypeとFORMATを使用して区別することとする。

FORMATには、NACKパケットおよびEOSパケット等を示す値が設定され、PayloadTypeには、制御メッセージであることを示す値が設定される。

図３に示すように、１つのNACKパケットにおいて、１つ以上の、再送要求対象となるパケットのシーケンス番号を、再送指定シーケンス番号として設定することが可能である（図３において、複数の「再送指定シーケンス番号」はこのことを表す）。

また、再送要求対象となるパケットのシーケンス番号それぞれに対して付加される再送要求回数は、そのシーケンス番号に対応するパケットの再送要求が何回目のものであるかを示すフィールドであり、重複指定回数は、送信側端末１２が再送する際の、同一パケットの再送回数を指定するフィールドである。OPTIONは、その他の任意の情報を格納するフィールドとして使用される。OPTIONには、任意の情報を格納することが可能であり、設定値に従った処理を送信側端末１２に実行させることができる。

例えば、重複指定回数に３を設定した場合、NACKパケットを受信した送信側端末１２に、そのNACKパケットによって再送を要求したパケットを３回送信させることができる。

また、再送要求回数に何回目の要求であるのかを設定することで、NACKパケット自身が損失したことを送信側端末１２に認識させることができる。

図４は、送信側端末１２から受信側端末１４へ送信されるEOSパケットを説明する図である。

EOSパケットは、バージョン番号、パディング、FORMAT、payload type、パケット長、送信同期ソース識別子（RTCP）、TIMESTAMPから構成される。EOSパケットを構成するそれぞれのフィールドは、図３に示すNACKパケットのそれぞれのフィールドと同様であるので説明は省略する。

次に、図１の送信側端末１２におけるパケットの送信処理を図５のフローチャートを参照して説明する。

ステップＳ１１において、エンコーダ２１はビデオカメラ１１から供給されたデータを符号化する。例えば、エンコーダ２１は、供給された画像データをMPEG（Moving Picture Experts Group）などの方式により符号化し、バッファ２２に格納する。RTPパケット作成部２３は、バッファ２２に格納された符号化データを読み込み、その符号化データをPayload（図２）に配置したRTPパケットを作成し、RTP出力ポート２４を介して通信部２５に供給する。RTPパケットは、ストリーミングデータを転送する際に使用されるパケットの一例である。

ステップＳ１１からステップＳ１２に進み、通信部２５は、RTP出力ポート２４を介してRTPパケット作成部２３から供給されたRTPパケットをもとにIPパケットを作成し、ステップＳ１３へ進む。ステップＳ１３において、通信部２５は、作成したIPパケットを、IPネットワーク１３を介して受信側端末１４へ送信し、ステップＳ１４へ進む。

ステップＳ１４において、RTCPパケット解析部２７は、受信側端末１４からNACKパケットを受信したかどうかのNACKパケット受信判定を行う。ステップＳ１４において、NACKパケットが受信されてないと判定された場合、ステップＳ１５に進み、RTPパケット作成部２３は、送信すべき全データの送信が完了したか否かを判定する。

ステップＳ１５において、送信すべき全データの送信が完了していないと判定された場合、ステップＳ１１に戻り、送信すべき全データの送信が完了するまでRTPパケット送信処理が繰り返される。

一方、ステップＳ１４において、NACKパケットを受信したと判定された場合、即ち、受信側端末１４から送信されたNACKパケットが、通信部２５で受信され、RTCP入出力ポート２６を介してRTCPパケット解析部２７に供給された場合、パケット解析部２７は、そのNACKパケットをARQ解析部２８へ供給して、ステップＳ１６へ進む。

ARQ解析部２８は、ステップＳ１６において、RTCPパケット解析部２７に供給されたNACKパケットのデータ部を解析し、そのNACKパケットによって再送を要求されたパケットのシーケンス番号などの、パケットの再送処理に必要な情報を取得し、RTPパケット作成部２３に対して、再送処理を指示する。

なお、ステップＳ１６において、ARQ解析部２８は、タイマを設定することで、ある一定時間内に、同一パケットを示すシーケンス番号を含むNACKパケットを複数受信した場合、最初のNACKパケットを受信した時点において、RTPパケット作成部２３に再送を要求されたパケットの再送指示を行い、その後、タイマによる一定時間の計時が終了するまでの間に受信したNACKパケットに含まれる同一パケットを示すシーケンス番号を無視することで、再送要求されたパケットの再送を制御することも可能である。

この場合、一定時間内に同一パケットの再送を要求する１以上のNACKパケットを受信しても、そのパケットの再送が１回しか行われないこととなり、無駄なトラフィックの増加を防止することができる。

ステップＳ１６からステップＳ１７に進み、RTPパケット作成部２３は、ARQ解析部２８から入力される再送処理の指示に従い、再送要求に対応するデータ（NACKパケットによって再送が要求されたデータ）をバッファ２２から抽出し、ステップＳ１８へ進む。

ステップＳ１８において、RTPパケット作成部２３は、ステップＳ１７でバッファ２２から抽出したデータを格納したRTPパケットを作成し、RTP出力ポート２４を介して通信部２５に供給して、ステップＳ１９に進む。

ステップＳ１９において、通信部２５は、RTP出力ポート２４を介してRTPパケット作成部２３から供給されたRTPパケットをもとにIPパケットを作成し、ステップＳ２０に進み、通信部２５は、作成したIPパケットを、IPネットワーク１３を介して受信側端末１４へ送信する。その後、ステップＳ１４に戻り、以下同様の処理が繰り返される。

一方、ステップＳ１５において、送信すべき全データの送信が完了と判定された場合、ステップＳ２１へ進み、RTPパケット作成部２３は、EOSパケットを送信済みであるか否かの判定を行う。

ステップＳ２１においてEOSパケットが未送信であると判定された場合、ステップＳ２２に進み、RTPパケット作成部２３は、RTCPパケット作成部２９に対してEOSパケット送信の指示を行う。RTCPパケット作成部２９は、RTPパケット作成部２３からの指示に従い、EOSパケットを作成し、RTCP入出力ポート２６を介して通信部２５にEOSパケットを供給する。通信部２５は、RTCP入出力ポート２６を介してRTCPパケット作成部２９から供給されたEOSパケットをもとにIPパケットを作成し、IPネットワーク１３を介して受信側端末１４に送信する。

そして、ステップＳ２２からステップＳ２３に進み、RTCPパケット作成部２９は、送信処理終了タイマの計時を開始し、ステップＳ１４に戻る。ここで、送信処理終了タイマは、EOSパケット送信後にも受信側端末１４からNACKパケットが送信されてくる可能性があるために、そのNACKパケットの処理を行う時間として計時されるものである。

一方、ステップＳ２１において、EOSパケットが送信済みであると判定された場合は、ステップＳ２４へ進み、RTCPパケット作成部２９は、送信処理終了タイマによる所定の時間の計時が終了したか否かを判定する。

ステップＳ２４において、送信処理終了タイマによる所定の時間の計時が終了していないと判定された場合、ステップＳ１４に戻り、上述の処理が繰り返される。

また、ステップＳ２４において、送信処理終了タイマによる所定の時間の計時が終了したと判定された場合、送信処理が終了される。

図６に示すフローチャートを参照して、図１の受信側端末１４によるパケットの受信処理を説明する。

ステップＳ３１において、受信処理に必要な初期化処理が行い行われる。例えば、パケット損失検出部３８は、内蔵しているパケット損失チェックタイマによる所定の時間の計時を開始する。このパケット損失チェックタイマは、一定の時間毎にパケット損失のチェックを実行するために、その時間を計時するためのものである。

ステップＳ３２において、RTPパケット解析部３３は、送信側端末１２からのRTPパケットを受信したか否かの判定を行う。ステップＳ３２において、RTPパケットを受信したと判定された場合、即ち、送信側端末１２からのRTPパケットが通信部３１で受信され、RTP入力ポート３２を介してRTPパケット解析部３３へ供給された場合、ステップＳ３３へ進み、RTPパケット解析部３３は、RTP入力ポート３２を介して供給されたRTPパケットのデータ部をバッファ３４へ供給し、ヘッダ部をインデックスリスト３５およびパケット損失検出部３８へ供給し、ステップＳ３４へ進む。

ここで、バッファ３４は、RTP解析部３３から供給されたRTPパケットのデータ部のデータを記憶し、また、インデックスリスト３５は、RTP解析部３３から供給されたRTPパケットのヘッダ部のヘッダ情報を記憶する。

ステップＳ３４において、パケット損失検出部３８は、RTP解析部３３から供給されたRTPパケットのヘッダ部に基づき、そのRTPパケット（以下、適宜、注目パケットという）が再生の単位となるデータフレームのｎフレーム目（ｎ=１，２，．．．）の終端パケットであるか否かの判定を行う。ステップＳ３４において、注目パケットがｎフレーム目の終端パケットではないと判定された場合、ステップＳ３５に進み、パケット損失検出部３８は、注目パケットが（ｎ＋１）フレーム目の先頭パケットであるか否かの判定を行う。

ステップＳ３５において、注目パケットが（ｎ＋１）フレーム目の先頭パケットではないと判定された場合、ステップＳ３６へ進み、パケット損失検出部３８は、パケット損失チェックタイマによる所定の時間の計時が終了したか否かの判定を行う。

ステップＳ３６において、パケット損失チェックタイマによる所定の時間の計時が終了していないと判定された場合、ステップＳ３９へ進み、デコーダ３６は、現在時刻がｍフレーム目（ｍ=１，２，．．．）の再生時刻であるか否かの判定を行う。

ここで、各フレームの再生時刻は、そのフレームを構成するデータが格納されていたRTPパケットに含まれるタイムスタンプから算出することができる。

ステップＳ３９において、現在時刻がｍフレーム目の再生時刻ではないと判定された場合、ステップＳ４０をスキップして、ステップＳ３２に戻り、上述の処理を繰り返す。

また、ステップＳ３９において、現在時刻がｍフレーム目の再生時刻であると判定された場合、ステップＳ４０へ進み、デコーダ３６は、バッファ３４に記憶されたデータを読み出し、ｍフレーム目の復号処理を行う。その後、ステップＳ３２へ戻り、上述の処理を繰り返す。

一方、ステップＳ３４において、注目パケットがｎフレーム目の終端パケットであると判定された場合、またはステップＳ３５において、注目パケットが（ｎ＋１）フレーム目の先頭パケットであると判定された場合、ステップＳ３８へ進む。

また、ステップＳ３６において、パケット損失チェックタイマによる所定の時間の計時が終了したと判定された場合も、ステップＳ３７において、パケット損失検出部３８は、パケット損失チェックタイマによる所定の時間の計時を再開してから、ステップＳ３８へ進む。

ステップＳ３８において、パケット損失検出部３８は、インデックスリスト３５に記憶されているヘッダ情報を参照して、各フレームを構成するデータの損失の有無、即ち、各フレーム内の損失パケットの有無を判定する。ステップＳ３８において、損失パケットがないと判定された場合、ステップＳ３９に進み、以下、上述した処理が行われる。

また、ステップＳ３８において、損失パケットがあると判定された場合、即ち、パケット損失検出部３８において損失パケットが検出された場合、ステップＳ４１へ進み、NACKパケット送信数決定部３９は、パケット損失検出部３８により検出された損失パケットに格納されているデータを含むフレームの再生時刻と現在時刻の差である再生猶予時間を算出し、さらに、その再生猶予時間から、損失パケットの受信の緊急性を表す要求レベルを判定する。

なお、再生猶予時間は、例えば、RTPパケットのヘッダ情報に含まれるタイムスタンプから算出することができる。即ち、損失パケットの再生猶予時間は、例えば、現在再生中のフレームを構成するデータが格納されていたRTPパケットのタイムスタンプと損失パケットの、１つ前または後のシーケンス番号のRTPパケットのタイムスタンプの差から求めることができる。

また、再生猶予時間としては、その他、例えば、現在再生中のフレームを構成するデータが格納されていたRTPパケットのシーケンス番号と損失パケットのシーケンス番号の差分値を用いるようにしても良い。この場合、現在再生中のフレームを構成するデータが格納されていたRTPパケットのシーケンス番号としては、現在再生中のフレームの、先頭のデータが格納されていたRTPパケットのシーケンス番号、または現在再生中のフレームの最後のデータが格納されていたRTPパケットのシーケンス番号、さらにその先頭と最後の間のデータが格納されていた任意のRTPパケットのシーケンス番号を用いることができる。

要求レベルは、例えば次の式により判定することができる。

要求レベル = 再生猶予時間／T

Tは、再生猶予時間をタイムスタンプから求める場合には、ある一定の時間（タイムスタンプ）差を示す値であり、再生猶予時間をシーケンス番号から求める場合には、ある一定のシーケンス番号の差を示す値である。また、要求レベルは、値が小さい程、損失パケットの受信の緊急性が高いことを表すものとする。

ステップＳ４１での要求レベルの判定後、ステップＳ４２に進み、NACKパケット送信数決定部３９は、要求レベルに従い、NACKパケットの送信数を決定し、決定した送信数を示す情報をRTCPパケット作成部４０に供給して、ステップＳ４３に進む。

NACKパケットの送信数は、例えば、次のように決定することができる。

要求レベル ≦（Ｋ−１）の場合は、NACKパケットの送信数 = Ｋ−要求レベル

要求レベル ＞（Ｋ−１）の場合は、NACKパケットの送信数 = １

上記において、Ｋは正の整数である。

上記内容に従うと、再生猶予時間が大きい損失パケット（再生時刻までに余裕がある損失パケット）に対するNACKパケットは少数送信され（少数のNACKパケットが送信され）、再生猶予時間の小さい損失パケット（再生時刻までに余裕がない損失パケット）に対するNACKパケットは多数送信される（多数のNACKパケットが送信される）。

例えば、画像フレームＦ１の再生予定時刻が3000、画像フレームＦ２の再生時刻が6000、画像フレームＦ３の再生予定時刻が9000であるとし、上記Ｔ = 3000、Ｋ = ４、さらに現在時刻が0であるとしたとき、画像フレームＦ１に対する損失パケットＰ１、画像フレームＦ２に対する損失パケットＰ２、画像フレームＦ３に対する損失パケットＰ３を検出したとする。このとき、損失パケットＰ１に対するNACKパケットの送信数Ｃ１は、下記の式により算出される。

Ｃ１ = ４−（3000／3000）= ３

同様に、損失パケットＰ２に対するNACKパケットの送信数Ｃ２、損失パケットＰ３に対するNACKパケットの送信数Ｃ３は下記の式より算出される。

Ｃ２ = ４−（6000／3000）= ２
Ｃ３ = ４−（9000／3000）= １

ステップＳ４３において、RTCPパケット作成部４０は、損失パケットに対するNACKパケットを作成し、NACKパケット送信数決定部３９により決定された送信数に等しい数のNACKパケットを、RTCP入出力ポート４１を介して通信部３１に供給し、ステップＳ４４に進む。

ステップＳ４４において、通信部３１は、RTCP入出力ポート４１を介して供給されたNACKパケットをもとに、その個数分のIPパケットを作成し、ステップＳ４５に進む。ステップＳ４５において、通信部３１は、作成したIPパケットを、IPネットワーク１３を介して送信側端末１２へ送信し、ステップＳ３２の処理へ戻り、上述の処理を繰り返す。

上記のように、損失パケットの受信の緊急性を表す要求レベルに応じて、NACKパケットの送信数を調整することで、無駄なトラフィックの増加を防止することができる。

なお、NACKパケットを複数送信する場合（複数個のNACKパケットを送信する場合）、RTCPパケット作成部４０においてタイマを設けることで、同一のRTPパケット（損失パケット）の再送を要求する複数のNACKパケットを一定の時間おきに送信側端末１２へ送信することが可能である。

NACKパケットを一定の時間おきに送信することで、複数のNACKパケットを一度にまとめて送信した場合に、IPネットワーク１３の輻輳により、送信した全てのNACKパケットが損失する危険性を低下させることができる。

一方、ステップＳ３２において、送信側端末１２からのRTPパケットを受信していないと判定された場合、ステップＳ４６へ進み、RTCPパケット解析部４２は、送信側端末１２からのEOSパケットを受信したか否かの判定を行う。

ステップＳ４６において、EOSパケットを受信したと判定された場合、ステップＳ４７へ進み、RTCPパケット解析部４２は、受信処理終了タイマによる一定時間の計時を開始し、ステップＳ３２の処理へ戻る。この受信処理終了タイマにより計時される一定時間は、最終フレームの再生時刻をもとに設定され、EOSパケット受信後も、再生が終了するまでの間は、NACKパケットにより再送を要求したRTPパケットの受信を可能にするための時間として使用される。

また、ステップＳ４６において、EOSパケットを受信していないと判定された場合、ステップＳ４８へ進み、デコーダ３６は、現在時刻がｍフレーム目の再生時刻であるか否かの判定を行う。

ステップＳ４８において、現在時刻がｍフレーム目の再生時刻であると判定された場合、ステップＳ４９へ進み、デコーダ３６は、バッファ３４に記憶されたデータを読み出し、ｍフレーム目の復号処理を行う。

そして、ステップＳ５０に進み、RTCPパケット解析部４２は、EOSパケットを受信済みであるか否かの判定を行う。ステップＳ５０において、EOSパケットを受信済みであると判定された場合、ステップＳ５１へ進み、RTCPパケット解析部４２は、受信処理終了タイマによる一定時間の計時が終了したか否かの判定を行う。

ステップＳ５１において、受信処理終了タイマによる一定時間の計時が終了したと判定された場合、受信側端末１４は、受信処理を終了する。

一方、ステップＳ４８において、現在時刻がｍフレーム目の再生時刻でないと判定された場合、ステップＳ５０において、EOSパケットが受信済みでないと判定された場合、または、ステップＳ５１において、受信処理終了タイマによる一定時間の計時が終了していないと判定された場合は、ステップＳ３２の処理へ戻り、上述した処理を繰り返す。

以上のように、損失パケットの受信の緊急性を表す要求レベルに応じて、NACKパケットの送信数を調整することにより、再生時刻の迫ったデータを格納する損失パケットに対するNACKパケットを高い確率で送信側へ到達させることが可能となり、再生時刻の迫ったデータを格納した再送パケットを、受信側にて再生時刻までに受信できる確立を高めることができる。その結果として、信頼性の高いデータ通信、および高品位なメディアの再生が可能となる。

次に、他の実施の形態について説明する。

図７は、本発明を適用した通信システムの他の実施の形態の構成例を示すブロック図である。図７において、図１に示す場合と同様の部分には同一の番号を付してあり、その説明は適宜省略する。

図７において、IPネットワーク５１は、Diffserv（Differentiated Services）対応のIPネットワークである。

ARQ解析部５３は、RTCPパケット解析部２７から供給されたNACKパケット（RTCPパケット）のデータ部から、受信側端末１４から再送を要求されたRTPパケットを示すシーケンス番号などのパケットの再送処理に必要な情報を取得し、RTPパケット作成部２３に対して、再送処理を指示する。また、ARQ解析部５３は、RTCPパケット解析部２７から供給されたNACKパケット（RTCPパケット）のデータ部の指定優先度から、RTPパケットの再送の際にIPヘッダのDS（Differentiated Services）フィールドに設定する、IPネットワーク５１上でのパケットの転送処理における優先度を判定し、再送を要求されたRTPパケットを示す情報とともに、通信部５２へ優先度を示す情報を通知する。

通信部５２は、図１の通信部２５と同様の処理を行う。ただし、通信部５２は、RTP出力ポート２６を介してRTPパケット作成部２３から供給された再送パケット（RTPパケット）からIPパケットを作成する際、ARQ解析部５３から供給された情報をもとにして、IPヘッダのDSフィールドに、NACKパケットに設定された優先度に対応する値を設定し、Diffserv対応のIPネットワーク５１を介して、受信側端末１４へ再送パケットを送信する。

図７において、ARQ処理部３７は、図１のNACKパケット送信数決定部３９に代えて、NACKパケット優先度決定部５５が設けられて構成されている。

NACKパケット優先度決定部５５は、パケット損失検出部３８から供給された損失パケットを示す情報をもとに、その損失パケットの再送を要求する再送要求通知パケットの優先度を決定し、パケット損失検出部３８から供給された損失パケットを示す情報とともに、再送要求通知パケットの優先度を示す情報をRTCPパケット作成部４０に供給する。同時に、NACKパケット優先度決定部５５は、再送要求通知パケットの優先度を示す情報を通信部５４へ供給する。

通信部５４は、図１の通信部３１と同様の処理を行う。ただし、通信部５４は、RTCP入出力ポート４１を介してRTCPパケット作成部４０から供給されたRTCPパケット（NACKパケット）をもとにIPパケットを作成する際、NACKパケット優先度決定部５５から供給された情報をもとに、IPヘッダのDSフィールドに、IPネットワーク５１上でのパケットの転送処理における優先度を示す値を設定し、Diffserv対応のIPネットワーク５１を介して送信側端末１２へ送信する。

図８は、受信側端末１４が送信側端末１２へ送信するNACKパケットとしてのIPパケットの構成を説明する図である。

IPパケットは、バージョン情報、ヘッダ長、TOS（Type Of Service）、パケット長、識別子、フラグ、断片オフセット、TTL（Time To Live）、プロトコル、送信元IPアドレス、宛て先IPアドレス、オプション、およびデータの各フィールドから構成されている。

IPパケットの先頭に配置されるバージョン情報フィールドは、４ビットの領域であり、バージョン情報は、IPのバージョンを表す。

次に配置されるヘッダ長は、バージョン情報からオプションまでを含む、IPヘッダの長さを表す。

８ビット領域のTOSフィールドは、IPパケットがDiffserv対応の場合、６ビットのDS（Differentiated Services）フィールドと２ビットの未使用領域に置き換えられ、DSフィールドにIPパケットの優先度を示す値が設定される。

パケット長フィールドは、１６ビットの領域であり、そこに記述されるパケット長は、IPパケットの全長、つまり、バージョン情報からデータまでを含んだ長さを表す。

識別子フィールドは、１６ビットの領域であり、そこには、パケットを識別するための情報が設定される。

フラグフィールドは、３ビットの領域であり、先頭に１ビットの未使用領域、次に、フラグメント禁止か否かを示す１ビットの領域、最後に、分割されたデータグラムの最後であるか否かを示す１ビットの領域が設けられている。

断片オフセットフィールドは、１３ビットの領域であり、そこには、分割されたデータグラムが再構成される際の順番を示す値が設定される。

TTLフィールドは、８ビットの領域であり、そこには、パケットの生存時間、つまりパケットが通過できるルータの数が設定される。また、TTLの値は、ルータを通過する度に、その通過したルータによって１づつ減らされ、TTLの値が０になったパケットを受け取ったルータによって破棄される。

プロトコルフィールドは、８ビットの領域であり、そこには、上位のプロトコルを示す値が設定される。本実施の形態においてはストリーミングデータの転送に、例としてRTPパケットを使用しており、この場合、プロトコルにはUDP（User Datagram Protocol）を示す値が設定される。

ヘッダチェックサムフィールドは、１６ビットの領域であり、そこには、IPヘッダ部のエラー判定に使用される情報が設定される。

送信元IPアドレスフィールドは、３２ビットの領域であり、送信元IPアドレスフィールドには、送信元のIPアドレスが設定される。

宛て先IPアドレスフィールドは、３２ビットの領域であり、宛て先IPアドレスフィールドには、宛て先のIPアドレスが設定される。

オプションフィールドには、可変長のオプショナル情報リストが配置される。

データフィールドは、IPパケットのデータ部であり、後述する図９のNACKパケットとしてのRTCPパケットが配置される。

図９は、RTCPパケット作成部４０からRTCP入出力ポート４１を介して通信部５４に供給されるNACKパケットとしてのRTCPパケットを説明する図である。

バージョン番号、パディング、FORMAT、送信同期ソース識別子（RTCP）、TIMESTAMP、再送要求回数、OPTION、および再送指定シーケンスは、図３で示されるNACKパケットと同様であるため、その説明は省略する。

図９に示される指定優先度は、NACKパケットとしてのIPパケットのヘッダ部のDSフィールドに設定される優先度を表す。

なお、NACKパケットに複数の再送指定シーケンス番号が設定されており、それぞれの再送指定シーケンス番号に対応する指定優先度が同一でない場合、NACKパケットとしてのIPパケットのヘッダ部のDSフィールドには、複数の再送指定シーケンス番号それぞれに対応する指定優先度の中で、例えば、最も高い優先度が設定される。

図１０は、図７の送信側端末１２の送信処理を示したフローチャートである。

ステップＳ６１乃至ステップＳ６５、ステップＳ６７、またはステップＳ７０乃至ステップＳ７４の処理は、図５のステップＳ１１乃至ステップＳ１５、ステップＳ１７、またはステップＳ２０乃至ステップＳ２４の処理のそれぞれと同様なので、その説明は適宜省略する。

ステップＳ６４において、NACKパケットを受信したと判定された場合、即ち、受信側端末１４から送信されたNACKパケットが、通信部５２で受信され、RTCP入出力ポート２６を介してRTCPパケット解析部２７に供給された場合、RTCPパケット解析部２７は、そのNACKパケットをARQ解析部５３へ供給して、ステップＳ６６へ進む。ステップＳ６６では、ARQ処理部５３は、RTCPパケット解析部２７から供給されたNACKパケットのデータ部を解析し、そのNACKパケットによって再送を要求されたパケットを示すシーケンス番号などの、パケットの再送処理に必要な情報を取得し、RTPパケット作成部２３に対して、再送処理を指示する。

また、ARQ解析部５３は、RTCPパケット解析部２７から供給されたNACKパケットのデータ部の指定優先度（図９）から、パケットの再送の際にIPヘッダのDS（Differentiated Services）フィールドに設定する、IPネットワーク５１上でのパケットの転送処理における優先度を判定し、通信部５２に再送が要求されたRTPパケットを示す情報とともに優先度を示す情報を通知する。

ステップＳ６６からステップＳ６７へ進み、RTPパケット作成部２３は、ARQ解析部２８からの再送処理の指示に従い、再送要求に対応するデータ（NACKパケットによって再送が要求されたデータ）をバッファ２２から取得し、ステップＳ６８に進む。

ステップＳ６８において、RTPパケット作成部２３は、ステップＳ６７でバッファ２２から取得したデータを格納したRTPパケットを作成し、再送パケットとして、RTP出力ポート２４を介して通信部５２に供給して、ステップＳ６９に進む。

ステップＳ６９において、通信部５２は、RTP出力ポート２４を介してRTPパケット作成部２３から供給された再送パケットをもとにIPパケットを作成する。この際、通信部５２は、ARQ処理部５３から供給された優先度を示す情報に対応する値を、IPヘッダのDSフィールドに設定する。そして、ステップＳ７０へ進み、通信部５２は、作成したIPパケットを、IPネットワーク５１を介して受信側端末１４へ送信する。その後、ステップＳ６４へ戻り、以下、同様の処理が繰り返される。

従って、図７の通信システムでは、送信側端末１２から受信側端末１４に対して、NACKパケットに設定されている指定優先度、即ち、NACKパケットとしてのIPパケットのDSフィールドに設定されている値と、例えば、同一の値が、再送パケットとしてのIPパケットのDSフィールドに設定され、その再送パケットとしてのIPパケットが送信される。この場合、再送パケットは、その再送パケットの再送を要求するNACKパケットと同一の優先度で、IPネットワーク５１内で転送されることになる。

図１１は、図７の受信側端末１４の受信処理を示したフローチャートである。

ステップＳ８１乃至ステップＳ９１、ステップＳ９５乃至ステップＳ１０１の処理は、図６のステップＳ３１乃至ステップＳ４１、ステップＳ４５乃至ステップＳ５１の処理のそれぞれと同様なので、その説明は適宜省略する。

ステップＳ８８において、損失パケットがあると判定された場合、即ち、パケット損失検出部３８において損失パケットが検出された場合、ステップＳ９１へ進み、NACKパケット優先度決定部５５は、パケット損失検出部３８により検出された損失パケットに格納されているデータを含むフレームの要求レベルを、図１のNACKパケット送信数決定部３９が図６のステップＳ４１で行うのと同様にして判定し、ステップＳ９２に進む。

ステップＳ９２において、NACKパケット優先度決定部５５は、ステップＳ９１にて判定された要求レベルに従い、IPネットワーク５１上でのパケットの転送処理における優先度を表すNACKパケット優先度を決定し、損失パケットを示す情報（シーケンス番号）とともにNACKパケット優先度をRTCPパケット作成部４０へ供給する。同時に、NACKパケット優先度決定部５５は、NACKパケット優先度を通信部５４へ供給し、ステップＳ９３に進む。

なお、ステップＳ８８において、複数の損失パケットが検出された場合、ステップＳ９２においてNACKパケット優先度決定部５５は、その複数の損失パケットそれぞれに対するNACKパケット優先度を決定し、さらに、そのNACKパケット優先度のうちの、最も高い優先度を示すNACKパケット優先度を通信部５４に供給する。

ステップＳ９３において、RTCPパケット作成部４０は、損失パケットを要求するNACKパケットとしてのRTCPパケットを作成する。このとき、RTCPパケット作成部４０は、NACKパケットに、パケット損失検出部５５からの損失パケットを示す情報としてのシーケンス番号を、図９の再送指定シーケンス番号として設定するとともに、パケット損失検出部５５からのNACKパケットの優先度を、図９の指定優先度として設定し、RTCP入出力ポート４１を介して通信部５４に供給して、ステップＳ９４に進む。

ステップＳ９４において、通信部５４は、RTCP入出力ポート４１を介してRTCPパケット作成部４０から供給されたNACKパケットをもとにIPパケットを作成する。その際、NACKパケット優先度決定部５５から供給された、NACKパケット優先度に従って、IPヘッダのDSフィールドに値を設定し、ステップＳ９５に進む。ステップＳ９５において、通信部５４は、作成したIPパケットを、IPネットワーク５１を介して送信側端末１２へ送信する。

ここで、NACKパケット優先度は、複数の段階を表すことが可能である。ここでは、２段階のNACKパケット優先度と、３段階以上のNACKパケット優先度とについて説明する。

まず、NACKパケット優先度を２段階とする場合、NACKパケット優先度は、例えば、次の式から求められる。

要求レベル ≦ θ の場合、 NACKパケット優先度 = ２
要求レベル ＞ θ の場合、 NACKパケット優先度 = １

θは正の整数である。

次に、NACKパケット優先度を３段階以上とする場合、NACKパケット優先度は、例えば、次のように求められる。

要求レベル ≦（Ｋ−１）の場合は、NACKパケット優先度 = Ｋ− 要求レベル

要求レベル ＞（Ｋ−１）の場合は、NACKパケット優先度 = １

上記において、Ｋは正の整数である。NACKパケット優先度は値が大きい程、ネットワーク５１上でのパケットの転送処理において、より優先的に転送が行われることを表すものとする。

上述の内容に従うと、再生猶予時間が充分にあり、従って要求レベルが大きい損失パケットに対するNACKパケットは低い優先度にて送信され、再生猶予時間が短く、従って要求レベルが小さい損失パケットに対するNACKパケットは高い優先度にて送信される（IPネットワーク５１内を優先的に転送される）。

例えば、３段階のNACKパケット優先度を持つ場合において、Ｋ = ３とすると、NACKパケット優先度は、要求レベルに応じて、下記のように決定される。

要求レベル ≧ ２ の場合、 NACKパケット優先度 = １
１ ≦ 要求レベル ＜ ２ の場合、 NACKパケット優先度 = ２
要求レベル ＜ １ の場合、 NACKパケット優先度 = ３

ここで、IPヘッダのDSフィールドに設定される値について説明する。

２段階のNACKパケット優先度を採用する場合、例えば、IETF RFC2598に規定されているDiffservにおけるExpedited Forwarding Class（EF Class）とIETF RFC2597に規定されているBest Effort Class（BE Class）を用いる。

このとき、NACKパケット優先度 = ２をEF Class 、NACKパケット優先度 = １をBE Classに対応させる。また、例えば、EF ClassのパケットのDSフィールドには、２進数表記で101110、BE ClassのパケットのDSフィールドには、２進数表記で000000を設定する。

なお、Diffservネットワークにおいて、EF Classは、最も高い優先度のクラスで、遅延と最大損失率が保証される最優先Classである。一方、BE Classは、Diffservネットワークにおいて、最も低い優先度のクラスで、Diffserv対応ルータにてEF Classのパケット処理が行われていない空き時間に処理される。

３段階のNACKパケット優先度を採用する場合、例えば、IETF RFC2598に規定されているExpedited Forwarding Class（EF Class）、IETF RFC2597に規定されているAssured Forwarding Class（AF Class）および、Best Effort Class（BE Class）を用いる。

このとき、NACKパケット優先度 = ３をEF Class 、NACKパケット優先度 = ２をAF Class 、NACKパケット優先度 = １をBE Classに対応させる。また、例えば、EF ClassのパケットのDSフィールドには、２進数表記で101110、AF ClassのパケットのDSフィールドには、２進数表記で001010、BE ClassのパケットのDSフィールドには、２進数表記で000000を設定する。

なお、NACKパケット優先度は、高い順に、EF Class、AF Class、BE Classとなる。また、AF Classは、IETF RFC2597にて３段階のClassと４段階のパケット棄却率を設定できるため、全体として、さらに細かい優先度分けを行うことが可能である。

本実施の形態では、優先度によりパケットの送信を制御する優先制御方式として、IETF RFC2474、IETF RFC2475、IETF RFC2597、IETF RFC2598に規定されるDiffserv（Differentiated Services）に対応した例について説明したが、その他の優先制御方式を採用してもよい。

また、本実施の形態では、NACKパケットとしてのRTCPパケットのデータ部に指定優先度フィールドを設け、その指定優先度フィールドに、要求レベルに応じて決定されたNACKパケット優先度を設定するとともに、そのNACKパケット優先度に対応する値を、そのRTCPパケットが格納されるIPパケットのDSフィールドに設定し、そのIPパケットを受信側端末１４から送信側端末１２に送信するようにしたが、受信側端末１４では、指定優先度フィールドがないNACKパケットを作成することが可能である。この場合、送信側端末１２では、受信側端末１４から受信したNACKパケットとしてのIPパケットのDSフィールドに設定されている優先度と同一の優先度が、再送パケットのIPヘッダ部のDSフィールドに設定される。

以上のように、損失パケットの受信の緊急性を表す要求レベルに応じて、NACKパケットのネットワーク上で転送処理における優先度を調整することにより、再生時刻の迫ったデータを格納する損失パケットに対するNACKパケットを高い確率で送信側へ到達させることが可能となり、再生時刻の迫ったデータを格納した再送パケットを、受信側にて再生時刻までに受信できる確立を高めることができる。その結果として、信頼性の高いデータ通信、および高品位なメディアの再生が可能となる。

本発明を用いることにより、従来の自動再送要求方式（ARQ）を用いたRTPパケット通信における、損失パケットの再送を要求するパケット自身がネットワーク上で損失し、そのパケットによって再送を要求しようとしていた損失パケットの再送処理が行われない可能性があるという問題点において、RTPパケット通信の頑健性を向上させ、信頼性の高いデータ通信を実現することができる。

上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、上述した処理は、図１２に示されるようなパーソナルコンピュータ６０により実行される。

図１２において、CPU（Central Processing Unit）６１は、ROM(Read Only Memory)６２に記憶されているプログラム、または、記憶部６８からRAM(Random Access Memory)６３にロードされたプログラムに従って各種の処理を実行する。RAM６３にはまた、CPU６１が各種の処理を実行する上において必要なデータなどが適宜記憶される。

CPU６１、ROM６２、およびRAM６３は、内部バス６４を介して相互に接続されている。この内部バス６４にはまた、入出力インターフェース６５も接続されている。

入出力インターフェース６５には、キーボード、マウスなどよりなる入力部６６、CRT，LCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部６７、ハードディスクなどより構成される記憶部６８、モデム、ターミナルアダプタなどより構成される通信部６９が接続されている。通信部６９は、電話回線やCATVを含む各種のネットワークを介しての通信処理を行う。

入出力インターフェース６５にはまた、必要に応じてドライブ７０が接続され、磁気ディスク７１（フレキシブルディスクを含む）、光ディスク７２（CD-ROM(Compact Disc-Read Only Memory) 、ＤＶＤ(Digital Versatile Disc)を含む）、光磁気ディスク７３（ＭＤ(Mini-Disc)（商標）を含む）、あるいは半導体メモリ７４などによりなるリムーバブルメディアが適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部６８にインストールされる。

一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。

この記録媒体は、図１２に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク７１、光ディスク７２、光磁気ディスク７３、若しくは半導体メモリ７４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM６２や、記憶部６８に含まれるハードディスクなどで構成される。

なお、本明細書において、フローチャートに記載された処理は、ステップとして記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

本発明を適用した通信システムの一実施の形態の構成例を示すブロック図である。 RTPパケットの構成を表す図である。 NACKパケットとしてのRTCPパケットの構成を表す図である。 EOSパケットとしてのRTCPパケットの構成を表す図である。 送信処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 本発明を適用した通信システムの他の一実施の形態の構成例を示すブロック図である。 NACKパケットとしてのIPパケットの構成を示す図である。 NACKパケットとしてのRTCPパケットの構成を表す図である。 送信処理を説明するフローチャートである。 受信処理を説明するフローチャートである。 パーソナルコンピュータの構成例を示す図である。

符号の説明

１１ ビデオカメラ， １２ 送信側端末， １３ IPネットワーク， １４ 受信側端末， １５ ディスプレイ， １６ スピーカ， ２１ エンコーダ， ２２ バッファ， ２３ RTPパケット作成部， ２４ RTP出力ポート， ２５， ２６ RTCP入出力ポート， ２７ RTCPパケット解析部， ２８ ARQ処理部， ２９ RTCPパケット作成部， ３１ 通信部， ３２ RTP入力ポート， ３３ RTPパケット解析部， ３４ バッファ， ３５ インデックスリスト， ３６ デコーダ， ３７ ARQ処理部， ３８ パケット損失検出部， ３９ NACKパケット送信数決定部， ４０ RTCPパケット作成部， ４１ RTCP入出力ポート， ４２ RTCPパケット解析部， ５１ IPネットワーク， ５２ 通信部， ５３ ARQ解析部， ５４通信部， ５５ NACKパケット優先度決定部， ６１ ＣＰＵ， ６２ ＲＯＭ， ６３ ＲＡＭ， ６４ 内部バス， ６５ 入出力インターフェース， ６６ 入力部， ６７ 出力部， ６８ 記憶部， ７１ 磁気ディスク， ７２ 光ディスク， ７３ 光磁気ディスク， ７４ 半導体メモリ

Claims (5)

1. ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信装置において、
   正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかった前記パケットに格納されているストリーミングデータの再生予定時刻との差であって、前記パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定手段と、
   正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記送信装置に送信する場合における制御を前記要求レベルに従って行う再送要求通知送信制御手段と
   を備えることを特徴とする受信装置。
2. 前記再送要求通知送信制御手段は、前記要求レベルに従って、前記再送要求通知パケットを送信する送信パケット数を決定し、決定した送信パケット数だけの前記再送要求通知パケットを送信する
   ことを特徴とする請求項１に記載の受信装置。
3. ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信方法において、
   正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかった前記パケットに格納されているストリーミングデータの再生予定時刻との差であって、前記パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、
   正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記送信装置に送信する場合における制御を前記要求レベルに従って行う再送要求通知送信制御ステップと
   を含むことを特徴とする受信方法。
4. ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信処理用のプログラムであって、
   正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかった前記パケットに格納されているストリーミングデータの再生予定時刻との差であって、前記パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、
   正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記送信装置に送信する場合における制御を前記要求レベルに従って行う再送要求通知送信制御ステップと
   を含むことを特徴とする、コンピュータが読み取り可能なプログラムが記載されている記録媒体。
5. ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信処理において、
   正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを、現在時刻と正常に受信できなかった前記パケットに格納されているストリーミングデータの再生予定時刻との差であって、前記パケットのタイムスタンプ情報またはシーケンス番号から算出される再生猶予時間を所定の値で除算することにより判定する要求レベル判定ステップと、
   正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記送信装置に送信する場合における制御を前記要求レベルに従って行う再送要求通知送信制御ステップと
   を含む処理をコンピュータに実行させることを特徴とするプログラム。

Images