(57)【要約】【課題】正常に受信できなかったパケットに対する再送を要求するパケットを、送信側へ高い確率で到達できるようにする。【解決手段】NACKパケット送信数決定部３９は、正常に受信できなったRTPパケットの受信の緊急性を表す要求レベルを判定し、その要求レベルに従い、正常に受信できなったRTPパケットの再送を要求する再送要求通知パケットの送信数を決定する。通信部３１は、決定した送信数の再送要求通知パケットを送信側端末１２へ送信する。本発明は、例えば、ストリーミングデータを送信する送信側端末と、そのストリーミングデータを受信する受信側端末とからなる通信システムに適用することができる。【選択図】図１
2005197988.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して、ストリーミングデータが格納されているパケットを受信する受信装置および前記ネットワークを介して前記パケットを送信する送信装置からなる通信システムにおいて、
前記受信装置は、
正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段と、
正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記要求レベルに従って前記送信装置に送信する制御を行う再送要求通知送信制御手段と
を備え、
前記送信装置は、
前記受信装置から送信されてくる前記再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、
前記再送要求通知パケットよって要求されたパケットの再送を制御する再送制御手段と
を備える
ことを特徴とする通信システム。
【請求項２】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信装置において、
正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段と、
正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記要求レベルに従って前記送信装置に送信する制御を行う再送要求通知送信制御手段と
を備えることを特徴とする受信装置。
【請求項３】
前記要求レベル判定手段は、現在時刻と正常に受信できなかった前記パケットに格納されているストリーミングデータの再生予定時刻との差である再生猶予時間をもとに、前記要求レベルを判定する
ことを特徴とする請求項２に記載の受信装置。
【請求項４】
前記要求レベル判定手段は、前記パケットのタイムスタンプ情報またはシーケンス番号から、前記再生猶予時間を算出する
ことを特徴とする請求項３に記載の受信装置。
【請求項５】
前記再送要求通知送信制御手段は、前記要求レベルに従って、前記再送要求通知パケットを送信する送信パケット数を決定し、決定した送信パケット数だけの前記再送要求通知パケットを送信する
ことを特徴とする請求項２に記載の受信装置。
【請求項６】
前記再送要求通知送信制御手段は、複数である前記送信パケット数の前記再送要求通知パケットの送信を、一定の時間おきに行わせる
ことを特徴とする請求項５に記載の受信装置。
【請求項７】
前記再送要求通知送信制御手段は、前記要求レベルに従って、前記再送要求通知パケットの、前記ネットワーク上でのパケットの転送処理における優先度を決定し、決定した優先度を示す値を前記再送要求通知パケットに設定して送信する
ことを特徴とする請求項２に記載の受信装置。
【請求項８】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信方法において、
正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、
正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記要求レベルに従って前記送信装置に送信する制御を行う再送要求通知送信制御ステップと
を含むことを特徴とする受信方法。
【請求項９】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信処理用のプログラムであって、
正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、
正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記要求レベルに従って前記送信装置に送信する制御を行う再送要求通知送信制御ステップと
を含むことを特徴とする、コンピュータが読み取り可能なプログラムが記載されている記録媒体。
【請求項１０】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置から送信されてくる前記パケットを受信する受信処理において、
正常に前記パケットを受信できなかった場合、正常に受信できなかった前記パケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、
正常に受信できなかった前記パケットの再送を要求する再送要求通知パケットを、前記要求レベルに従って前記送信装置に送信する制御を行う再送要求通知送信制御ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
【請求項１１】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、
一定時間内に同一の前記パケットに対する1以上の前記再送要求通知パケットを受信した場合、前記再送要求通知パケットの個数に関係なく１回だけ、前記再送要求通知パケットよって要求された前記パケットの再送を行うように再送を制御する再送制御手段と
を備えることを特徴とする送信装置。
【請求項１２】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信方法において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
一定時間内に同一の前記パケットに対する1以上の前記再送要求通知パケットを受信した場合、前記再送要求通知パケットの個数に関係なく１回だけ、前記再送要求通知パケットよって要求された前記パケットの再送を行うように再送を制御する再送制御ステップと
を含むことを特徴とする送信方法。
【請求項１３】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信処理用のプログラムであって、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
一定時間内に同一の前記パケットに対する1以上の前記再送要求通知パケットを受信した場合、前記再送要求通知パケットの個数に関係なく１回だけ、前記再送要求通知パケットよって要求された前記パケットの再送を行うように再送を制御する再送制御ステップと
を含むことを特徴とする、コンピュータが読み取り可能なプログラムが記載されている記録媒体。
【請求項１４】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信処理において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
一定時間内に同一の前記パケットに対する1以上の前記再送要求通知パケットを受信した場合、前記再送要求通知パケットの個数に関係なく１回だけ、前記再送要求通知パケットよって要求された前記パケットの再送を行うように再送を制御する再送制御ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
【請求項１５】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信装置において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットであって、前記ネットワーク上でのパケットの転送処理における優先度が設定されている前記再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、
前記再送要求通知パケットに設定されている優先度に対応した優先度を、前記再送要求通知パケットによって要求された前記パケットに設定し、その前記パケットの再送を制御する再送制御手段と
を備えることを特徴とする送信装置。
【請求項１６】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信方法において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットであって、前記ネットワーク上でのパケットの転送処理における優先度が設定されている前記再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
前記再送要求通知パケットに設定されている優先度に対応した優先度を、前記再送要求通知パケットによって要求された前記パケットに設定し、その前記パケットの再送を制御する再送制御ステップと
を含むことを特徴とする送信方法。
【請求項１７】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信処理用のプログラムであって、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットであって、前記ネットワーク上でのパケットの転送処理における優先度が設定されている前記再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
前記再送要求通知パケットに設定されている優先度に対応した優先度を、前記再送要求通知パケットによって要求された前記パケットに設定し、その前記パケットの再送を制御する再送制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１８】
ネットワークを介して、ストリーミングデータが格納されているパケットを送信する送信処理において、
前記パケットを受信する受信装置から送信されてくる、前記パケットの再送を要求する再送要求通知パケットであって、前記ネットワーク上でのパケットの転送処理における優先度が設定されている前記再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、
前記再送要求通知パケットに設定されている優先度に対応した優先度を、前記再送要求通知パケットによって要求された前記パケットに設定し、その前記パケットの再送を制御する再送制御ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラムに関し、特に、ストリーミング型のデータ通信において、損失パケットに対する再送要求通知パケットを送信側へ効果的に到達させるようにすることで、ストリーミング型のデータ通信の信頼性を向上させ、品質の高いデータ通信を行うことができるようにした通信システム、受信装置および方法、送信装置および方法、記録媒体、並びにプログラムに関する。
【背景技術】
【０００２】
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の通信方式のサービスに加えて、ストリーム型の通信方式のサービスがより多く提供されるようになってきた。
【０００３】
ダウンロード型の通信方式のサービスにおいては、受信装置が、送信装置から送信された画像または音声のデータを格納したファイルを受信し、受信したファイルを自分の記録媒体に記録する。受信装置は、ファイルの記録が完了した後、記録したファイルを基に、画像または音声を再生する。ダウンロード型の通信方式のサービスにおいては、ファイルの記録が完了するまでは、画像または音声を再生することができないので、ダウンロード型の通信方式のサービスは、長時間の再生またはリアルタイムの再生には適さない。
【０００４】
一方、ストリーム型の通信方式のサービスにおいては、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の通信方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
【０００５】
ストリーム型の通信方式において、送信装置から送信されてくるデータを、一般にストリーミングデータと称する。
【０００６】
より具体的な例として、ストリーム型の通信方式は、画像データに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については、損失パケットの再送を要求するパケット自身がネットワーク上で損失し、そのパケットによって再送を要求しようとしていた損失パケットの再送処理が行われない可能性があるため、通信の信頼性において充分ではなかった。
【００２１】
本発明は、このような状況に鑑みてなされたものであり、損失パケットの再送を要求するパケットが高い確率で相手（送信装置）に到達するようにするものである。
【課題を解決するための手段】
【００２２】
本発明の通信システムは、受信装置が、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御手段とを備え、送信装置が、受信装置から送信されてくる再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、再送要求通知パケットよって要求されたパケットの再送を制御する再送制御手段とを備えることを特徴とする。
【００２３】
本発明の受信装置は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御手段とを備えることを特徴とする。
【００２４】
要求レベル判定手段は、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差である再生猶予時間をもとに、要求レベルを判定するようにすることができる。
【００２５】
要求レベル判定手段は、パケットのタイムスタンプまたはシーケンス番号から、再生猶予時間を算出するようにすることができる。
【００２６】
再送要求通知送信制御手段は、要求レベルに従って、再送要求通知パケットを送信する送信パケット数を決定し、決定した送信パケット数だけの再送要求通知パケットを送信するようにすることができる。
【００２７】
再送要求通知送信制御手段は、複数である送信パケット数の再送要求通知パケットの送信を、一定の時間おきに行わせるようにすることができる。
【００２８】
再送要求通知送信制御手段は、要求レベルに従って、再送要求通知パケットの、ネットワーク上でのパケットの転送処理における優先度を決定し、決定した優先度を示す値を再送要求通知パケットに設定して送信するようにすることができる。
【００２９】
本発明の受信方法は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御ステップとを含むことを特徴とする。
【００３０】
本発明の第１の記録媒体に記録されているプログラムは、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御ステップとを含むことを特徴とする。
【００３１】
本発明の第１のプログラムは、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップと、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御ステップとをコンピュータに実行させる。
【００３２】
本発明の第１の送信装置は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御手段とを備えることを特徴とする。
【００３３】
本発明の第１の送信方法は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御ステップとを含むことを特徴とする。
【００３４】
本発明の第２の記録媒体に記録されているプログラムは、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御ステップとを含むことを特徴とする。
【００３５】
本発明の第２のプログラムは、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御ステップとをコンピュータに実行させる。
【００３６】
本発明の第２の送信装置は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットであって、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットの受信を制御する再送要求通知受信制御手段と、再送要求通知パケットに設定されている優先度に対応した優先度を、再送要求通知パケットによって要求されたパケットに設定し、そのパケットの再送を制御する再送制御手段とを備えることを特徴とする。
【００３７】
本発明の第２の送信方法は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットであって、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、再送要求通知パケットに設定されている優先度に対応した優先度を、再送要求通知パケットによって要求されたパケットに設定し、そのパケットの再送を制御する再送制御ステップとを含むことを特徴とする。
【００３８】
本発明の第３の記録媒体に記録されているプログラムは、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットであって、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、再送要求通知パケットに設定されている優先度に対応した優先度を、再送要求通知パケットによって要求されたパケットに設定し、そのパケットの再送を制御する再送制御ステップとを含むことを特徴とする。
【００３９】
本発明の第３のプログラムは、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットであって、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットの受信を制御する再送要求通知受信制御ステップと、再送要求通知パケットに設定されている優先度に対応した優先度を、再送要求通知パケットによって要求されたパケットに設定し、そのパケットの再送を制御する再送制御ステップとをコンピュータに実行させる。
【００４０】
本発明の通信システムにおいては、受信装置にて、正常にパケットが受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルが判定され、要求レベルに従って、正常に受信できなかったパケットの再送を要求する再送要求通知パケットの送信が行われる。そして、送信装置により、受信装置から送信されてくる再送要求通知パケットが受信され、その再送要求通知パケットによって要求されたパケットの再送が行われる。
【００４１】
本発明の受信装置および方法、第１の記録媒体、並びに第１のプログラムにおいては、正常にパケットが受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルが判定され、要求レベルに従って、正常に受信できなかったパケットの再送を要求する再送要求通知パケットの送信が行われる。
【００４２】
本発明の第１の送信装置および方法、並びに第２の記録媒体および第２のプログラムにおいては、一定時間内に、パケットを受信する受信装置から送信されてくる、同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送が行われる。
【００４３】
本発明の第２の送信装置および方法、並びに第３の記録媒体および第３のプログラムにおいては、パケットを受信する受信装置から送信されてくる、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットを受信した場合、その再送要求通知パケットに設定されている優先度に対応した優先度を設定して、再送要求通知パケットよって要求されたパケットの再送が行われる。
【００４４】
受信装置は、独立した装置であっても良いし、通信装置の受信処理を行うブロックであっても良い。
【００４５】
同様に、送信装置は、独立した装置であっても良いし、通信装置の送信処理を行うブロックであっても良い。
【００４６】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【発明の効果】
【００４７】
本発明によれば、損失パケットの受信の緊急性に応じて、再送を要求するパケットの送信を制御することができ、再生時刻までに、損失パケットを受信する確立を高めることができる。その結果、ストリーミングデータ通信において、信頼性の高いデータ通信および、高品位なメディア再生を実現することができる。
【発明を実施するための最良の形態】
【００４８】
以下に本発明の実施の形態を説明するが、本明細書に記載の発明と、発明の実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
【００４９】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現、追加される発明の存在を否定するものではない。
【００５０】
請求項１に記載の通信システムは、受信装置（例えば、図１の受信側端末１４）が、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段（例えば、図６のステップＳ４１の処理を実行する図１のNACKパケット送信数決定部３９）と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御手段（例えば、図６のステップＳ４２の処理を実行する図１のNACKパケット送信数決定部３９）とを備え、送信装置（例えば、図１の送信側端末１２）が、受信装置から送信されてくる再送要求通知パケットの受信を制御する再送要求通知受信制御手段（例えば、図１のRTCPパケット解析部２７）と、再送要求通知パケットよって要求されたパケットの再送を制御する再送制御手段（例えば、図１のARQ解析部２８）とを備えることを特徴とする。
【００５１】
請求項２に記載の受信装置は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定手段（例えば、図６のステップＳ４１の処理を実行する図１のNACKパケット送信数決定部３９）と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御手段（例えば、図６のステップＳ４２の処理を実行する図１のNACKパケット送信数決定部３９）とを備えることを特徴とする。
【００５２】
請求項３に記載の受信装置は、要求レベル判定手段（例えば、図６のステップＳ４１の処理を実行する図１のNACKパケット送信数決定部３９）が、現在時刻と正常に受信できなかったパケットに格納されているストリーミングデータの再生予定時刻との差である再生猶予時間をもとに、要求レベルを判定することを特徴とする。
【００５３】
請求項４に記載の受信装置は、要求レベル判定手段（例えば、図６のステップＳ４１の処理を実行する図１のNACKパケット送信数決定部３９）が、パケットのタイムスタンプまたはシーケンス番号から、再生猶予時間を算出することを特徴とする。
【００５４】
請求項５に記載の受信装置は、再送要求通知送信制御手段（例えば、図６のステップＳ４２の処理を実行する図１のNACKパケット送信数決定部３９）が、要求レベルに従って、再送要求通知パケットを送信する送信パケット数を決定し、決定した送信パケット数だけの再送要求通知パケットを送信することを特徴とする。
【００５５】
請求項６に記載の受信装置は、再送要求通知送信制御手段（例えば、図６のステップＳ４２の処理を実行する図１のNACKパケット送信数決定部３９）が、複数である送信パケット数の再送要求通知パケットの送信を、一定の時間おきに行わせることを特徴とする。
【００５６】
請求項７に記載の受信装置は、再送要求通知送信制御手段（例えば、図７のNACKパケット優先度決定部５５）が、要求レベルに従って、再送要求通知パケットの、ネットワーク上でのパケットの転送処理における優先度を決定し、決定した優先度を示す値を再送要求通知パケットに設定して送信をすることを特徴とする。
【００５７】
請求項８に記載の受信方法は、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップ（例えば、図６のステップＳ４１の処理）と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御ステップ（例えば、図６のステップＳ４２の処理）とを含むことを特徴とする。
【００５８】
請求項１０に記載のプログラムは、正常にパケットを受信できなかった場合、正常に受信できなかったパケットの受信の緊急性を表す要求レベルを判定する要求レベル判定ステップ（例えば、図６のステップＳ４１の処理）と、正常に受信できなかったパケットの再送を要求する再送要求通知パケットを、要求レベルに従って送信装置に送信する制御を行う再送要求通知送信制御ステップ（例えば、図６のステップＳ４２の処理）とをコンピュータに実行させることを特徴とする。
【００５９】
このプログラムは、記録媒体（例えば、図１２の磁気ディスク７１）に記録することができる。
【００６０】
請求項１１に記載の送信装置は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御手段（例えば、図１のRTCPパケット解析部２７）と、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御手段（例えば、図１のARQ解析部２８）とを備えることを特徴とする。
【００６１】
請求項１２に記載の送信方法は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップ（例えば、図５のステップＳ１４の処理）と、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御ステップ（例えば、図５のステップＳ１６の処理）とことを特徴とする。
【００６２】
請求項１４に記載のプログラムは、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットの受信を制御する再送要求通知受信制御ステップ（例えば、図５のステップＳ１４の処理）と、一定時間内に同一のパケットに対する１以上の再送要求通知パケットを受信した場合、再送要求通知パケットの個数に関係なく１回だけ、再送要求通知パケットよって要求されたパケットの再送を行うように再送を制御する再送制御ステップ（例えば、図５のステップＳ１６の処理）とことを特徴とする。
【００６３】
このプログラムは、記録媒体（例えば、図１２の磁気ディスク７１）に記録することができる。
【００６４】
請求項１５に記載の送信装置は、パケットを受信する受信装置から送信されてくる、パケットの再送を要求する再送要求通知パケットであって、ネットワーク上でのパケットの転送処理における優先度が設定されている再送要求通知パケットの受信を制御する再送要求通知受信制御手段（例えば、図７のRTCPパケット解析部２７）と、再送要求通知パケットに設定されている優先度に対応した優先度を、再送要求通知パケットによって要求されたパケットに設定し、そのパケットの再送を制御する再送制御手段（例えば、図７の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パケット優先度決定部，  ６１  ＣＰＵ，  ６２  ＲＯＭ，  ６３  ＲＡＭ，  ６４  内部バス，  ６５  入出力インターフェース，  ６６  入力部，  ６７  出力部，  ６８  記憶部，  ７１  磁気ディスク，  ７２  光ディスク，  ７３  光磁気ディスク，  ７４  半導体メモリ
【図１】
2005197988.tif 000003
【図２】
2005197988.tif 000004
【図３】
2005197988.tif 000005
【図４】
2005197988.tif 000006
【図５】
2005197988.tif 000007
【図６】
2005197988.tif 000008
【図７】
2005197988.tif 000009
【図８】
2005197988.tif 000010
【図９】
2005197988.tif 000011
【図１０】
2005197988.tif 000012
【図１１】
2005197988.tif 000013
【図１２】
2005197988.tif 000014