(57)【要約】【課題】不要になった再送パケットを消去し、再送用バッファの記憶領域をより少なくする。【解決手段】  パケタイザ８４は、相手に送信した送信パケットに対応する再送パケットを再送用バッファ８５に記憶させる。送信部１０１は、相手からの再送要求に対して記憶されている再送パケットを相手に送信する。受信部１０２は最終再送要求を受信する。最終再送要求が受信された場合、NACK処理部８６は、最終再送要求に含まれるシーケンス番号以下の再送パケットを再送用バッファ８５から消去する。本発明は、遠隔テレビ会議システムに適用できる。【選択図】図４
2005136545.tif 000002
【特許請求の範囲】
【請求項１】
伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置において、
相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御手段と、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御手段と、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御手段と、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御手段と
を備えることを特徴とする送信装置。
【請求項２】
前記受信制御手段は、前記相手から送信されてきた、前記ストリーミングデータの再生の終了を示す確認応答信号の受信をさらに制御し、
前記消去制御手段は前記確認応答信号が受信された場合、再生を終了した前記ストリーミングデータを格納する前記再送パケットの消去をさらに制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
再生される順番を示す再生順番情報を含む前記送信パケットを生成する生成手段をさらに備え、
前記記憶制御手段は、前記送信パケットに対応する、前記再生順番情報を含む前記再送パケットの記憶を制御し、
前記消去制御手段は、前記再生順番情報を基に前記再送パケットの消去を制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項４】
生成された時刻を示す時刻情報を含む前記送信パケットを生成する生成手段をさらに備え、
前記記憶制御手段は、前記送信パケットに対応する、前記時刻情報を含む前記再送パケットの記憶を制御し、
前記消去制御手段は、前記時刻情報を基に前記再送パケットの消去を制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項５】
伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置の送信方法において、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御ステップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御ステップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御ステップと
を含むことを特徴とする送信方法。
【請求項６】
伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理用のプログラムであって、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御テップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御テップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御テップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項７】
伝送に所定の遅延時間を要する通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理をコンピュータに行わせるプログラムにおいて、
前記相手に送信した前記送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、
前記相手からの再送要求に対応して記憶されている前記再送パケットの前記相手への送信を制御する送信制御テップと、
前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータの次に再生される前記ストリーミングデータを格納する前記再送パケットの前記再送要求である最終再送要求の受信を制御する受信制御テップと、
前記最終再送要求が受信された場合、前記相手が前記再送要求を送信してから前記再送パケットを受信するまでに必要とされる前記遅延時間より、現在時刻と再生される時刻との時間の間隔が小さい前記ストリーミングデータを格納する前記再送パケットの消去を制御する消去制御テップと
を含むことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は送信装置および方法、プログラム格納媒体、並びにプログラムに関し、特に、不要になったデータを消去することによって、再送用バッファの記憶領域をより少なくすることができるようにした送信装置および方法、プログラム格納媒体、並びにプログラムに関する。
【背景技術】
【０００２】
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の伝送方式のサービスに加えて、ストリーム型の伝送方式のサービスがより多く提供されるようになってきた。
【０００３】
ダウンロード型の伝送方式のサービスにおいては、受信装置が、送信装置から送信された画像または音声のデータを格納するファイルを受信し、受信したファイルを自分の記録媒体に記録する。受信装置は、ファイルの記録が完了した後、記録したファイルを基に、画像または音声を再生する。ダウンロード型の伝送方式のサービスにおいては、ファイルの記録が完了するまでは、再生することができないので、ダウンロード型の伝送方式のサービスは、長時間の再生またはリアルタイムの再生には適さない。
【０００４】
一方、ストリーム型の伝送方式のサービスにおいては、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
【０００５】
ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般にストリーミングデータと称する。
【０００６】
より具体的な例として、ストリーム型の伝送方式は、画像データにMPEG（Moving Picture Experts Group）符号化処理を適用することにより生成されるMPEGストリームを格納する、IP（Internet Protocol）パケットをインターネットを介して伝送するシステムで使用される。このシステムにおいて、受信装置である、PC（Personal Computer）、PDA（Personal Digital Assistance）、または携帯電話機は、IPパケットを受信し、画像を再生する。
【０００７】
ストリーム型の伝送方式は、ビデオオンデマンド若しくはライブ映像のストリーミング配信、ビデオ会議、またはテレビ電話などのリアルタイム通信に適している。
【０００８】
このようなストリーム型の伝送方式の技術の1つとして、IETF RFC（Internet Engineering Task Force Request For Comments）１８８９で規定されているプロトコルであるRTP（Real time Transport Protocol）がある。
【０００９】
RTPに基づくデータ転送においては、生成された時刻を示すタイムスタンプがパケットに付加され、タイムスタンプの参照により送信側と受信側の時間的関係が把握されるので、受信側において、パケット伝送の遅延ゆらぎ（ジッタ−）などの影響が排除され、同期した再生が可能になる。
【００１０】
しかし、RTPにおいて、実時間のデータの伝送は保証されない。すなわち、パケット配信の優先度や設定、管理などは、RTPによって提供されるトランスポートサービスの範疇ではないため、他の方式のパケットと同様、ネットワーク上での遅延やパケットロスが生じる可能性がある。
【００１１】
遅延やパケットロスが生じても、受信側は、再生時刻までに受信されたパケットだけを利用してデータを再生することができる。すなわち、受信装置は、データに多少の損失や誤りが発生しても、品質を落として再生するか、またはデータの損失や誤りを訂正して再生する。
【００１２】
この場合、再生に間に合わず遅延して配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、高品質なデータ配信処理を行おうとしても、パケットロスやエラーが発生したときは、受信側の再生の品質は保証されない。
【００１３】
このようなRTPに従ったデータ伝送における問題を解決する案として、データ転送の信頼性のより高い転送プロトコルであるTCP（Transmission Control Protocol）に従ってパケットの再送要求およびパケットの再送を行う方法が考えられる。
【００１４】
しかしながら、TCPにおいて、パケットロスが生じた場合、パケットが再送されるので、エラーには強いが、受信側において、再送されたパケットの受信が再生時刻に間に合わない可能性があり、リアルタイム通信には不向きである。
【００１５】
したがって、送信と受信の遅延が少ないARQ（Automatic Repeat Request）などの技術が必要とされる。
【００１６】
この問題の解決方法として、パケットロスが生じた場合、受信装置は、後述する往復遅延時間（RTT（Round Trip Time））を基に、再送されるパケットの受信が再生処理に間に合わないと判定されたときは、サーバに再送を要求しないという方法が提案されている。（例えば、特許文献１参照）。再送の要求はNACK（Negative Acknowledement）パケットの送信によって行われる。
【００１７】
従来のARQにおいて、図１で示されるように、サーバ（送信装置）がクライアント（受信装置）あてにストリーミングデータを送る。図１における横方向は、時間を示す。図１において、フレーム１−１を再生するための画像データであるストリーミングデータは送信パケット１１−１乃至送信パケット１１−３、フレーム１−２を再生するための画像データであるストリーミングデータは送信パケット１１−４乃至送信パケット１１−６、フレーム１−３を再生するための画像データであるストリーミングデータは送信パケット１１−７乃至送信パケット１１−９に格納されて送信される。図１において、時刻ｔ７０から時刻ｔ７１までのT１−１、時刻ｔ７１から時刻ｔ７２までのT１−２、および時刻ｔ７２から時刻ｔ７３までのT１−３は、それぞれフレーム１−１、フレーム１−２、およびフレーム１−３のそれぞれの再生時間である。
【００１８】
時刻ｔ０においてサーバはクライアントあてに送信パケット１１−１を送信するとともに、再送パケット１２−１を再送用バッファに格納する。クライアントは時刻ｔ４０にサーバから送信された送信パケット１１−１を受信する。同様に、時刻ｔ１および時刻ｔ２のそれぞれにおいて、サーバはクライアントあてに送信パケット１１−２および１１−３を送信するとともに再送パケット１２−２および１２−３を再送用バッファに格納する。      
【００１９】
さらにサーバは、クライアントあてに送信パケット１１−４乃至送信パケット１１−９を送信するとともに、再送パケット１２−４乃至再送パケット１２−９を再送用バッファに格納する。また、クライアントはサーバから送信された送信パケット１１−２乃至送信パケット１１−９を受信する。
【００２０】
ここで、再送パケット１２−１乃至再送パケット１２−９のそれぞれには、送信パケット１１―１乃至送信パケット１１−９のそれぞれに含まれるストリーミングデータが格納されている。換言すれば、再送パケット１２−１には、送信パケット１１−１に含まれるストリーミングデータが格納され、再送パケット１２−２には、送信パケット１１−２に含まれるストリーミングデータが格納され、同様に、再送パケット１２−３乃至再送パケット１２−９のそれぞれには順に対応する送信パケット１１−３乃至送信パケット１１−９のそれぞれに含まれるストリーミングデータが格納される。
【００２１】
以下、送信パケット１１−１乃至送信パケット１１−９を個々に区別する必要がないとき、単に送信パケット１１と称する。同様に、以下、再送パケット１２−１乃至再送パケット１２−９を個々に区別する必要がないとき、単に再送パケット１２と称する。
【００２２】
実際には、送信パケット１１と再送パケット１２は同じパケットであるため、特に区別する必要はないが、本明細書中では説明を分かり易くするため、再送用として再送用バッファに記憶されたパケットを特に再送パケットと称する。なお、送信パケットと再送パケットの区別をしない場合には単にパケットと称する。
【００２３】
時刻ｔ４１においてクライアントは、通信網における往復遅延時間を計測するため、RTT計測パケット２をサーバあてに送信する。時刻ｔ３にRTT計測パケット２を受信したサーバは、クライアントあてにRTT計測パケット２を返送する。時刻ｔ４２においてRTT計測パケット２を受信したクライアントは、RTT計測パケット２を受信した時刻ｔ４２から送信された時刻ｔ４１を引き算することにより往復遅延時間T２を算出する。クライアントは算出された往復遅延時間T２に基づき、ロスパケットの再送を要求するか否かを判定する。
【００２４】
時刻ｔ４３において、送信パケット１１−５のパケットロスを検知したクライアントは、時刻ｔ４３に再送を要求した場合、時刻ｔ４４における再送パケット１２−５の受信がフレーム１−２の再生開始時刻ｔ７１に間に合うと判定し、サーバあてに再送を要求する。
【００２５】
また、時刻ｔ４５において、送信パケット１１−９のパケットロスを検知したクライアントは、時刻ｔ４５に再送を要求しても、フレーム１−３の再生開始時刻ｔ７２までに再送パケット１２−９を受信することができないと判定し、再送を要求しない。
【００２６】
以上のようにして、再生処理に間に合わない再送パケットの送信を無くすことができる。
【００２７】
また、送信されるパケットのうち、優先度が高いパケットのみを再送しているものもある（例えば、特許文献２参照）。
【００２８】
【特許文献１】特開２００３−１６９０４０号公報
【００２９】
【特許文献２】特開２００２−８４３３８号公報
【発明の開示】
【発明が解決しようとする課題】
【００３０】
しかしながら、上述した特許文献１および特許文献２に開示されている技術においては、再送パケットの受信が再生時刻に間に合わない場合には、再送を要求しないため、リアルタイムの再生に適したデータの伝送を行うことはできるが、送信装置の再送用バッファとしてより大きな記憶領域が必要とされる。
【００３１】
また、送信から一定の時間が経過した、再送用バッファに格納されている再送パケットを自動的に消去するという方法も考えられるが、通信網におけるパケットの伝送には通信状態によって変化する遅延ゆらぎがあるため、いつ消去してよいかが明確ではなかった。
【課題を解決するための手段】
【００３２】
本発明の送信装置は、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御手段と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御手段と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御手段と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御手段とを備えることを特徴とする。
【００３３】
受信制御手段は、相手から送信されてきた、ストリーミングデータの再生の終了を示す確認応答信号の受信をさらに制御し、消去制御手段は、確認応答信号が受信された場合、再生を終了したストリーミングデータを格納する再送パケットの消去をさらに制御するようにすることができる。
【００３４】
送信装置は、再生される順番を示す再生順番情報を含む送信パケットを生成する生成手段をさらに設け、記憶制御手段は、送信パケットに対応する、再生順番情報を含む再送パケットの記憶を制御し、消去制御手段は、再生順番情報を基に再送パケットの消去を制御するようにすることができる。
【００３５】
送信装置は、生成された時刻を示す時刻情報を含む送信パケットを生成する生成手段をさらに設け、記憶制御手段は、送信パケットに対応する、時刻情報を含む再送パケットの記憶を制御し、消去制御手段は、時刻情報を基に再送パケットの消去を制御するようにすることができる。
【００３６】
本発明の送信方法は、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップとを含むことを特徴とする。
【００３７】
本発明の記録媒体のプログラムは、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御テップを含むことを特徴とする。
【００３８】
本発明のプログラムは、相手に送信した送信パケットに対応する再送パケットの記憶を制御する記憶制御ステップと、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップと、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップと、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御テップをコンピュータに実行させることを特徴とする。
【００３９】
送信装置は、独立した装置であってもよいし、通信装置の送信処理を行うブロックであってもよい。
【００４０】
本発明の送信装置および方法、記録媒体、並びにプログラムにおいては、相手に送信した送信パケットに対応する再送パケットが記憶され、相手からの再送要求に対応して記憶されている再送パケットが相手に送信される。そして、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求が受信される。さらに、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットが消去される。
【発明の効果】
【００４１】
本発明によれば、再送用バッファの記憶容量をより少なくすることが可能となる。
【発明を実施するための最良の形態】
【００４２】
以下に本発明の最良の形態を説明するが、本明細書に記載の発明と、発明と実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
【００４３】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現し、追加される発明の存在を否定するものではない。
【００４４】
本発明によれば、送信装置が提供される。この送信装置（例えば、図２のサーバ２２）は、相手に送信した送信パケット（例えば、図６の送信パケット１８１）に対応する再送パケット（例えば、図６の再送パケット１８２）の記憶を制御する記憶制御手段（例えば、図４の再送用バッファ８５）と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御手段（例えば、図４の送信部１０１）と、相手が再送要求（例えば、図１０で示されるNACKパケット）を送信してから再送パケットを受信するまでに必要とされる遅延時間（例えば、図６の往復遅延時間T１２）より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求（例えば、図１２で示されるNACKパケット）の受信を制御する受信制御手段（例えば、図４の受信部１０２）と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御手段（例えば、図４のNACK処理部８６）とを備える。
【００４５】
この送信装置は、受信制御手段（例えば、図４の受信部１０２）が、相手から送信されてきた、ストリーミングデータの再生の終了を示す確認応答信号（例えば、図１１で示されるACK（Acknowledgement）パケット）の受信をさらに制御し、消去制御手段（例えば、図４のNACK処理部８６）が、確認応答信号が受信された場合、再生を終了したストリーミングデータを格納する再送パケット（例えば、図６の再送パケット１８２）の消去をさらに制御するようにすることができる。
【００４６】
この送信装置は、再生される順番を示す再生順番情報（例えば、シーケンス番号）を含む送信パケットを生成する生成手段（例えば、図４のパケタイザ８４）をさらに備え、記憶制御手段（例えば、図４の再送用バッファ８５）が、送信パケットに対応する、再生順番情報を含む再送パケットの記憶を制御し、消去制御手段（例えば、図４のNACK処理部８６）が、再生順番情報を基に再送パケットの消去を制御するようにすることができる。
【００４７】
この送信装置は、生成された時刻を示す時刻情報（例えば、タイムスタンプ）を含む送信パケットを生成する生成手段（例えば、図４のパケタイザ８４）をさらに備え、記憶制御手段（例えば、図４の再送用バッファ８５）が、送信パケットに対応する、時刻情報を含む再送パケットの記憶を制御し、消去制御手段（例えば、図４のNACK処理部８６）が、時刻情報を基に再送パケットの消去を制御するようにすることができる。
【００４８】
また、本発明によれば、送信方法が提供される。この送信方法は、相手に送信した送信パケット（例えば、図６の送信パケット１８１）に対応する再送パケット（例えば、図６の再送パケット１８２）の記憶を制御する記憶制御ステップ（例えば、図７のステップＳ７の処理）と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップ（例えば、図１５のステップＳ９２の処理）と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間（例えば、図６の往復遅延時間T１２）より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求（例えば、図１２で示されるNACKパケット）の受信を制御する受信制御ステップ（例えば、図１５のステップＳ９３の処理）と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップ（例えば、図１５のステップＳ９４の処理）とを含む。
【００４９】
また、本発明によれば、プログラムが提供される。このプログラムは、相手に送信した送信パケット（例えば、図６の送信パケット１８１）に対応する再送パケット（例えば、図６の再送パケット１８２）の記憶を制御する記憶制御ステップ（例えば、図７のステップＳ７の処理）と、相手からの再送要求に対応して記憶されている再送パケットの相手への送信を制御する送信制御ステップ（例えば、図１５のステップＳ９２の処理）と、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間（例えば、図６の往復遅延時間T１２）より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータの次に再生されるストリーミングデータを格納する再送パケットの再送要求である最終再送要求の受信を制御する受信制御ステップ（例えば、図１５のステップＳ９３の処理）と、最終再送要求が受信された場合、相手が再送要求を送信してから再送パケットを受信するまでに必要とされる遅延時間より、現在時刻と再生される時刻との時間の間隔が小さいストリーミングデータを格納する再送パケットの消去を制御する消去制御ステップ（例えば、図１５のステップＳ９４の処理）とをコンピュータに実行させる。
【００５０】
このプログラムは記録媒体（例えば、図３の磁気ディスク６１）に記録することができる。
【００５１】
本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システム、またはテレビ電話などのリアルタイムにストリーミングデータを伝送する通信システムに適用できる。
【００５２】
図２は本発明を適用したストリーミング配信システムの一実施の形態を示す図である。このストリーミング配信システムにおいては、インターネットなどの通信網２３に、サーバ２２およびクライアント２４が接続されている。
【００５３】
カメラ２１は、画像を撮像して、撮像した画像に対応する画像データをサーバ２２に供給する。例えば、カメラ２１は、動画像を撮像して、動画像に対応する画像データをサーバ２２に供給する。
【００５４】
画像データは、ストリーミングデータの一例である。ストリーミングデータは、音声のデータ、またはリアルタイム制御データなど、時間の経過に対応して順次送信または受信が要求されるデータであればよい。
【００５５】
サーバ２２は、例えば、PCまたは専用サーバなどにより構成され、クライアント２４からストリーミングデータの配信が要求された場合、カメラ２１から供給された画像データをパケットに格納して、パケットを通信網２３を介して、クライアント２４に送信する。
【００５６】
通信網２３は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、所定の遅延時間で、サーバ２２から送信されてきたパケットをクライアント２４まで伝送する。
【００５７】
クライアント２４は、例えば、PC、PDA、あるいは携帯電話機などにより構成され、通信網２３を介してサーバ２２から送信されてきたパケットを受信する。クライアント２４は、受信したパケットから画像データを抽出し、出力装置２５に出力する。
【００５８】
クライアント２４は、ストリーミングデータが格納されているパケットを正常に受信できなかった場合、再送パケットの受信がストリーミングデータの再生時刻に間に合うと判定されたときには、サーバ２２に再送を要求する。サーバ２２はクライアント２４から再送が要求された場合、ストリーミングデータが格納されているパケットを再送する。
【００５９】
出力装置２５は、クライアント２４から供給された画像データを基に、画像を表示する。
【００６０】
なお、出力装置２５は、クライアント２４とは別の装置として設けるようにしてもよく、クライアント２４に内蔵するようにしてもよい。
【００６１】
図２で示されるストリーミング配信システムの例においては、サーバ２２およびクライアント２４が、それぞれ1台ずつ設けられているが、実際には、サーバ２２は複数のクライアント２４に対してストリーミングデータを配信するので、クライアント２４は、通信網２３を介して複数台接続されている。また、同様に、複数のサーバ２２を設けるようにしてもよい。
【００６２】
図３は、サーバ２２の構成の例を示すブロック図である。
【００６３】
サーバ２２のCPU（Central Processing Unit）４１は、ROM（Read Only Memory）４２、または記録部４８に記憶されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）４３には、CPU４１が実行するプログラムやデータなどが適宜記憶される。これらのCPU４１、ROM４２、およびRAM４３は、バス４４により相互に接続されている。
【００６４】
CPU４１にはまた、バス４４を介して入出力インタフェース４５が接続されている。入出力インタフェース４５には、キーボード、マウス、スイッチなどよりなる入力部４６、ディスプレイ、スピーカ、ランプなどによる出力部４７が接続されている。CPU４１は、入力部４６から入力される指令に対応して各種の処理を実行する。
【００６５】
入出力インタフェース４５に接続されている記録部４８は、例えばハードディスクなどで構成され、CPU４１が実行するプログラムや各種のデータを記録する。通信部４９は、インターネット、その他のネットワークなどの通信網２３を介して、クライアント２４などの外部装置と通信する。
【００６６】
また、通信部４９を介してプログラムを取得し、記録部４８に記録してもよい。
【００６７】
入出力インタフェース４５に接続されているドライブ５０は、磁気ディスク６１、光ディスク６２、光磁気ディスク６３、或いは半導体メモリ６４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部４８に転送され、記録される。
【００６８】
なお、クライアント２４は、サーバ２２と同様に構成されるので、その記載および説明は省略する。サーバ２２およびクライアント２４は、図３に示した内部構成に限らず、必要に応じ、機能を追加したり削除したりすることは可能であり、その機能に対応した構成をもつことが可能である。
【００６９】
図４は、サーバ２２の機能の構成を示すブロック図である。
【００７０】
サーバ２２は、通信部４９、制御部８１、エンコーダ８２、バッファ８３、パケタイザ８４、再送用バッファ８５、NACK処理部８６、およびタイマ８７を含む。
【００７１】
制御部８１は、サーバプログラムを実行するCPU４１によって実現され、サーバ２２全体を制御する。
【００７２】
エンコーダ８２は、カメラ２１から供給されたストリーミングデータの一例である画像データをエンコード（符号化）し、エンコードされた画像データをバッファ８３に供給する。
【００７３】
バッファ８３は、エンコーダ８２から供給された画像データを一時的に記憶する。
【００７４】
パケタイザ８４は、バッファ８３からエンコードされた画像データを取得する。また、パケタイザ８４は、取得した画像データを所定の方式のパケットに格納することにより、パケットを生成する。パケタイザ８４は、生成されたパケットを再送用バッファ８５および通信部４９へ供給する。
【００７５】
再送用バッファ８５は、パケタイザ８４から供給されたパケットを再送パケットとして一時的に記憶し、NACK処理部８６の制御に基づいて、記憶されている再送パケットを通信部４９に供給する。
【００７６】
通信部４９は各種のデータを送信する送信部１０１、および各種のデータを受信する受信部１０２を備えており、通信網２３を介してデータの送受信を行う。通信部４９の送信部１０１は、パケタイザ８４から供給されたパケットを送信パケットとして、通信網２３を介して、クライアント２４に送信する。通信部４９の送信部１０１は、再送用バッファ８５から供給された再送パケットを、通信網２３を介して、クライアント２４に送信する。
【００７７】
さらに、通信部４９の受信部１０２は、通信網２３を介して、クライアント２４から送信されてきた各種パケットを受信し、受信したパケットを制御部８１またはNACK処理部８６に供給する。
【００７８】
NACK処理部８６は、通信部４９が受信し、通信部４９から供給されたRTT計測パケット、確認応答信号、再送要求および最終再送要求の処理を行う。受信された各種パケットに対応する処理の詳細は後述する。
【００７９】
タイマ８７は、制御部８１の制御のもと、エンコーダ８２にエンコードする時間の間隔を管理するためのタイマ値を供給する。
【００８０】
図５は、クライアント２４の機能の構成を示すブロック図である。
【００８１】
クライアント２４は、制御部１２１、通信部１２２、RTP処理部１２３、バッファ１２４、デコーダ１２５、ACKモード設定部１２６、タイマ１２７、RTT計測部１２８、RTT保持部１２９、RTC（Real Time Clock）１３０、タイマ１３１、およびNACK処理部１３２を含む。
【００８２】
制御部１２１は、クライアントプログラムを実行するクライアント２４のCPU４１によって実現され、クライアント２４全体を制御する。
【００８３】
通信部１２２は、クライアント２４の通信部４９に対応し、データの受信を制御する受信部１５１および、データの送信を制御する送信部１５２を備えている。受信部１５１は、通信網２３を介して送信されてきた各種データを受信する。送信部１５２は、通信網２３を介して、各種のデータを送信する。通信部１２２は、受信したパケットをRTP処理部１２３またはRTT計測部１２８に供給する。
【００８４】
RTP処理部１２３は、通信部１２２が受信し、通信部１２２から供給された送信パケット１８１または再送パケット１８２であるRTPパケットを検査する。RTP処理部１２３は、正常なRTPパケットが受信された場合、RTPパケットをバッファ１２４に供給する。RTP処理部１２３は、正常なRTPパケットが受信されなかった場合、NACK処理部１３２に再送要求を指示する。例えば、RTP処理部１２３は、正常なRTPパケットが受信されなかった場合、RTPパケットのヘッダ情報をNACK処理部１３２に供給すると共に、NACK処理部１３２に再送要求を指示する。
【００８５】
バッファ１２４は、RTP処理部１２３から供給されたRTPパケットを一時的に記憶する。
【００８６】
デコーダ１２５は、バッファ１２４に記憶されているRTPパケットを順に取得して、取得したRTPパケットから画像データを抽出する。そして、デコーダ１２５は、エンコーダ８２に対応する復号方式で、抽出された画像データをデコード（復号）して、デコードされた画像データを出力装置２５に出力する。デコーダ１２５は、デコードされた画像データを格納していたRTPパケットのヘッダ情報をACKモード設定部１２６に供給する。
【００８７】
なお、RTP処理部１２３は、RTPパケットから画像データを抽出して、抽出した画像データをバッファ１２４に供給するようにしてもよい。この場合、RTP処理部１２３は、通信部１２２から供給されたRTPパケットのヘッダ情報を抽出して、抽出したヘッダ情報をバッファ１２４に供給する。バッファ１２４は、画像データおよびヘッダ情報を対応させて、それぞれに記憶する。デコーダ１２５は、画像データを復号する場合、バッファ１２４から対応するヘッダ情報を読み出して、読み出したACKモード設定部１２６に供給する。
【００８８】
ACKモード設定部１２６は、デコーダ１２５から供給されたヘッダ情報をNACK処理部１３２に供給する。
【００８９】
タイマ１２７は、制御部１２１の制御のもと、デコーダ１２５に、デコードする間隔を示すタイマ値を供給する。
【００９０】
RTT計測部１２８は、RTC１３０から現在時刻を取得し、RTT計測パケット１７２を生成する。RTT計測部１２８は、生成されたRTT計測パケット１７２を通信部１２２に供給する。通信部１２２は供給されたRTT計測パケット１７２を通信網２３を介してサーバ２２に送信する。
【００９１】
また、RTT計測部１２８は、通信部１２２が受信し、通信部１２２から供給されたRTT計測パケット１７２を取得する。RTT計測部１２８は、RTT計測パケット１７２を取得した場合、RTC１３０から現在時刻を取得し、往復遅延時間を算出する。RTT計測部１２８は、算出した往復遅延時間をRTT保持部１２９に供給する。往復遅延時間の詳細は後述する。
【００９２】
RTT保持部１２９は、RTT計測部１２８から供給された往復遅延時間をNACK処理部１３２に供給し、供給された往復遅延時間を一時的に記憶する。RTT保持部は、記憶している往復遅延時間をNACK処理部１３２に供給する。
【００９３】
RTC１３０は、現在時刻をRTT計測部１２８に供給する。
【００９４】
タイマ１３１は、制御部１２１の制御のもと、RTT計測部１２８にRTT計測パケット１７２を生成する間隔を示すタイマ値を供給する。
【００９５】
NACK処理部１３２は、RTP処理部１２３から供給された信号をもとに、正常にRTPパケットを受信できなかったか、すなわち、パケットロスが発生したか否かを判定する。パケットロスが発生したと判定された場合、NACK処理部１３２は、パケットロスが発生した送信パケット１８１の再送を要求する再送要求としてのNACKパケットを生成し、生成したNACKパケットを通信部１２２に供給する。
【００９６】
NACK処理部１３２は、RTT保持部１２９から供給された往復遅延時間、およびACKモード設定部１２６から供給されたヘッダ情報をもとに最終処理期限のフレームを計算する。最終処理期限のフレームの中にロスパケットがある場合には、NACK処理部１３２は、再送を要求するロスパケットの最終再送要求としてのNACKパケットを生成し、生成したNACKパケットを通信部１２２に供給する。
【００９７】
また、NACK処理部１３２は、ACKモード設定部１２６から供給されたヘッダ情報をもとに、ACKモードであるか否かを判定し、ACKモードであると判定された場合には、確認応答信号を生成し、通信部１２２に供給する。
【００９８】
ここで、ACKモードとは、クライアント２４がデコードし終わったフレームの最後のシーケンス番号をサーバ２２に通知するモードである。例えば、ACKモードは、使用者の操作に対応した入力部４６からの信号を基に、設定されるか解除される。
【００９９】
NACK処理部１３２によって実行される各種パケットの処理の詳細は後述する。
【０１００】
なお、図４または図５で示されるサーバ２２またはクライアント２４の機能は、ハードウェアにより実現するようにしてもよく、ソフトウェア（プログラム）により実現するようにしてもよい。
【０１０１】
次に、図６のタイムチャートを参照して、サーバ２２における再送要求および最終再送要求の処理を説明する。
【０１０２】
図６における横方向は、時間を示す。図６において、フレーム１７１−１を再生するための画像データであるストリーミングデータは、送信パケット１８１−１乃至送信パケット１８１−３に格納されて送信され、フレーム１７１−２を再生するための画像データであるストリーミングデータは、送信パケット１８１−４乃至送信パケット１８１−６に格納されて送信され、フレーム１７１−３を再生するための画像データであるストリーミングデータは、送信パケット１８１−７乃至送信パケット１８１−９に格納されて送信される。
【０１０３】
図６において、時刻ｔ１５０から時刻ｔ１５１までのT１１−１、および時刻ｔ１５１から時刻ｔ１５２までのT１１−２は、それぞれフレーム１７１−１、およびフレーム１７１−２のそれぞれの再生時間である。
【０１０４】
時刻ｔ８０において、サーバ２２は、通信網２３を介して、クライアント２４あてに送信パケット１８１−１を送信するとともに、再送パケット１８２−１を再送用バッファ８５に格納する。クライアント２４は、通信網２３を介して、サーバ２２から送信されてきた送信パケット１８１−１を時刻ｔ１２０に受信する。同様に、時刻ｔ８１および時刻ｔ８２のそれぞれにおいて、サーバ２２は、通信網２３を介して、クライアント２４あてに送信パケット１８１−２および１８１−３をそれぞれ送信するとともに、再送パケット１８２−２および１８２−３を再送用バッファ８５に格納する。
【０１０５】
さらに、サーバ２２は、通信網２３を介して、クライアント２４あてに送信パケット１８１−４乃至送信パケット１８１−９を送信するとともに、再送パケット１８２−４乃至再送パケット１８２−９を再送用バッファ８５に格納する。また、クライアント２４は、通信網２３を介して、サーバ２２から送信されてきた送信パケット１８１−２乃至送信パケット１８１−９を受信する。
【０１０６】
ここで、再送パケット１８２−１乃至再送パケット１８２−９のそれぞれには、送信パケット１８１―１乃至送信パケット１８１−９のそれぞれに含まれるストリーミングデータが格納されている。換言すれば、再送パケット１８２−１には、送信パケット１８１−１に含まれるストリーミングデータが格納され、再送パケット１８２−２には、送信パケット１８１−２に含まれるストリーミングデータが格納され、同様に、再送パケット１８２−３乃至再送パケット１８２−９のそれぞれには順に対応する送信パケット１８１−３乃至送信パケット１８１−９のそれぞれに含まれるストリーミングデータが格納される。
【０１０７】
以下、送信パケット１８１−１乃至送信パケット１８１−９を個々に区別する必要がないとき、単に送信パケット１８１と称する。同様に、以下、再送パケット１８２−１乃至再送パケット１８２−９を個々に区別する必要がないとき、単に再送パケット１８２と称する。
【０１０８】
時刻ｔ１２１において、クライアント２４は、通信網２３における往復遅延時間を計測するため、通信網２３を介して、RTT計測パケット１７２をサーバ２２あてに送信する。クライアント２４から送信されてきたRTT計測パケット１７２を、時刻ｔ８３において受信したサーバ２２は、通信網２３を介して、クライアント２４あてにRTT計測パケット１７２を返送する。サーバ２２から送信されてきたRTT計測パケット１７２を、時刻ｔ１２２において受信したクライアント２４は、RTT計測パケット１７２を受信した時刻ｔ１２２から送信された時刻ｔ１２１を引き算することにより往復遅延時間T１２を算出する。クライアント２４は、算出された往復遅延時間T１２に基づき、サーバ２２に、ロスパケットの再送を要求するか否かを判定する。
【０１０９】
時刻ｔ１２３において送信パケット１８１−５のパケットロスを検知したクライアント２４は、時刻ｔ１２３に再送を要求した場合、時刻ｔ１２３に往復遅延時間T１２を加算して求められる時刻ｔ１２５における再送パケット１８２−５の受信が、フレーム１７１−２の再生開始時刻ｔ１５１に間に合うと判定し、通信網２３を介して、サーバ２２あてに再送を要求する。
【０１１０】
同様にクライアント２４は、時刻ｔ１２４に検知した送信パケット１８１−６のロスパケットについても、時刻ｔ１２４において再送を要求した場合、時刻ｔ１２４に往復遅延時間T１２を加算して求められる時刻ｔ１２６における再送パケット１８２−６の受信が、フレーム１７１−２の再生開始時刻ｔ１５１に間に合うと判定し、通信網２３を介して、サーバ２２あてに再送を要求する。
【０１１１】
時刻ｔ１２６において、クライアント２４は、サーバ２２から再送されてきた再送パケット１８２−５のパケットロスを検知する。時刻ｔ１２７に再送パケット１８２−５が最終処理期限となったので、クライアント２４は、最終再送要求としてのNACKパケットを、通信網２３を介して、サーバ２２あてに送信する。最終処理期限については、後述する。再送パケット１８２−５の最終再送要求としてのNACKパケットを時刻ｔ８４において受信したサーバ２２は、通信網２３を介して、要求された再送パケット１８２−５をクライアント２４あてに再送するとともに、再送用バッファ８５に格納されている、以後の処理においてクライアント２４に送信されることのない再送パケット１８２−１乃至再送パケット１８２−５を消去する。
【０１１２】
以上のようにして、サーバ２２は再送要求および最終再送要求を示すNACKパケットの処理するとともに必要のなくなった再送用パケット１８２を再送用バッファ８５から消去する。
【０１１３】
図７のフローチャートを参照して、サーバプログラムを実行するサーバ２２によるストリーミングデータの送信処理を説明する。
【０１１４】
ステップＳ１において、制御部８１は、送信の処理に必要なデータを初期化する。例えば、ステップＳ１において、制御部８１は、パケタイザ８４に、シーケンス番号およびタイムスタンプを初期化させ、タイマ８７のタイマの値を0msにセットする。
【０１１５】
ステップＳ２において、制御部８１は、タイマ８７の値を基に、タイマ８７が終了したか否かを判定し、タイマ８７が終了していない場合、ステップＳ２に戻り、タイマ８７が終了したと判定されるまで、判定の処理を繰り返す。
【０１１６】
ステップＳ２において、タイマ８７が終了したと判定された場合、処理は、ステップＳ３に進む。
【０１１７】
例えば、画像データのフレームの数が１秒当たり３０である場合、タイマ８７が時間の経過に対応して値を増加させるとき、ステップＳ２において、制御部８１は、33msなどの所定の値とタイマ８７の値を比較することによりタイマ８７が終了したか否かを判定する。
【０１１８】
例えば、ステップＳ１において、タイマ８７の値を33msにセットし、タイマ８７の値が時間の経過に対応して減少するとき、制御部８１は、タイマ８７の値と、0msとを比較することによりタイマ８７が終了したか否かを判定する。
【０１１９】
この場合における、タイマ８７の値と比較される0msまたは33msは、フレームの数が１秒当たり３０である場合の例であり、本発明を限定するものではない。
【０１２０】
以下に説明するタイマに関する処理において、同様である。
【０１２１】
ステップＳ３において、制御部８１は、エンコーダ８２に、カメラ２１から供給された画像データを１フレーム分キャプチャさせる。例えば、ステップＳ３において、エンコーダ８２は、カメラ２１から供給された画像データを順次取得して、取得した画像データのうち、１フレーム分をキャプチャする。
【０１２２】
ステップＳ４において、制御部８１は、エンコーダ８２に、キャプチャされた画像データをエンコードさせる。例えば、ステップＳ４において、制御部８１は、エンコーダ８２に、キャプチャされた画像データをMPEG１，２，４，７、若しくは２１、JPEG（Joint Photographic Experts Group）、JPEG２０００、またはモーションJPEGなどの方式によりエンコードさせる。
【０１２３】
ステップＳ５において、エンコーダ８２は、エンコードされた画像データをバッファ８３に供給して、バッファ８３にエンコードされた画像データを格納（記憶）させる。
【０１２４】
ステップＳ６において、制御部８１は、パケタイザ８４にデコードされた画像データを格納するRTPパケットを生成させる。RTPパケットは、送信パケット１８１の一例である。
【０１２５】
図8はRTPパケットを説明する図である。RTPパケットの先頭には、図８において“V”で表される、２ビットのバージョン情報が配置される。バージョン情報は、RTPパケットのバージョンを示す。
【０１２６】
バージョン情報の次に図８中の“P”で表される１ビットのパディングが配置され、パディングに続いて、１ビットの拡張情報がRTPパケット１８１に配置される。拡張情報は図８において、“X”で表される。拡張情報は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。
【０１２７】
拡張情報に続いて、CSRC（Contributing Source）カウントがRTPパケットに配置される。CSRCカウントは、図８中において、“CC”で表される。CSRCカウントは、CSRC識別子の数を表す。
【０１２８】
CSRCカウントに続いて配置される、１ビットのメーカー情報は、プロファイルによって定義される。メーカー情報は、図８中において“m”で表される。
【０１２９】
メーカー情報に続いて配置される、７ビットのペイロードタイプは、RTPパケットのフォーマットを定義するための情報である。ペイロードタイプは、図８中において、“PT”で表される。RTPパケットにおいて、ペイロードタイプは、３３とされる。
【０１３０】
シーケンス番号は、ペイロードタイプの次に配置される、１６ビットの情報である。シーケンス番号は、RTPパケットの再生の順番を示す番号であり、送信の度に、１ずつ増える。シーケンス番号は、パケットロスを検出し、RTPパケットの順序を修復するために使用される。
【０１３１】
シーケンス番号の次に配置される、３２ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。
【０１３２】
SSRC（Synchronization Source）識別子は、タイムスタンプの次に配置される、３２ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。
【０１３３】
RTPパケットにおいて、SSRC識別子の次には、ストリーミングデータが格納される。図８において、“Original Data”は、ストリーミングデータを示す。
【０１３４】
図7に戻り、ステップＳ７において、制御部８１は、パケタイザ８４に、生成されたRTPパケットを再送用バッファ８５に供給させて、再送用バッファ８５にRTPパケットを格納させる。
【０１３５】
ステップＳ８において、制御部８１は、パケタイザ８４に、生成されたRTPパケットを通信部４９に供給させ、通信部４９に、通信網２３を介して、RTPパケットをクライアント２４あてに送信させる。
【０１３６】
ステップＳ９において、パケタイザ８４は、RTPパケットに付加するRTPタイムスタンプを更新する。
【０１３７】
ステップＳ１０において、制御部８１は、タイマ８７をセットし、ステップＳ２に戻り、上述した処理を繰り返す。例えば、ステップＳ１０において、制御部８１はタイマ８７の値を0msにセットする。
【０１３８】
以上の処理により、サーバ２２は、通信網２３を介して、例えば、画像であるストリーミングデータが格納されている送信パケット１８１をクライアント２４あてに送信する。
【０１３９】
次に、図９のフローチャートを参照して、クライアントプログラムを実行するクライアント２４による応答の処理について説明する。
【０１４０】
ステップＳ３１において、制御部１２１は、デコードの処理に必要なデータを初期化する。例えば、ステップＳ３１において、制御部１２１は、デコーダ１２５を500msの期間、待ち状態として待機させ、バッファ１２４が、所定の量の画像データを記憶するまで待たせる。制御部１２１は、デコーダ１２５を500msの期間、待機させることによってバッファ１２４に常時500ms分のストリーミングデータを格納させるようにする。
【０１４１】
また、例えば、画像データのフレームの数が1秒当たり３０である場合、ステップＳ３１において、制御部１２１は、タイマ１２７の値を0msにセットし、33msなどの所定の値と比較することによりタイマ１２７が終了したか否かを判定する。
【０１４２】
ステップＳ３２において、制御部１２１は、タイマ１２７の値を基に、タイマ１２７が終了したか否かを判定し、タイマ１２７が終了していないと判定された場合、処理はステップＳ３３に進む。
【０１４３】
ステップＳ３３において、制御部１２１は、RTP処理部１２３がRTPパケットを受信したか否かを判定し、RTPパケットを受信していないと判定された場合、処理はステップＳ３２に戻り、判定の処理を繰り返す。
【０１４４】
一方、ステップＳ３３において、RTPパケットを受信したと判定された場合、ステップＳ３４に進み、制御部１２１は、RTPパケットを正常に受信できなかったか否か、すなわち、パケットロスが発生したか否かを判定する。例えば、ステップＳ３３において、制御部１２１は、RTP処理部１２３に受信したRTPパケットを検査させ、RTP処理部１２３から供給される検査の結果を示す信号を基に、パケットロスが発生したか否かを判定する。
【０１４５】
ステップＳ３４において、パケットロスが発生したと判定された場合、処理はステップＳ３５に進み、制御部１２１は、NACK処理部１３２に、再送要求としてのNACKパケットを生成させ、生成させたNACKパケットを通信部１２２に供給させる。制御部１２１は、通信部１２２に、通信網２３を介して、NACKパケットをサーバ２２あてに送信させる。ステップＳ３５の処理が終了すると、処理はステップＳ３２に戻る。
【０１４６】
図１０は、再送要求としてのNACKパケットを説明する図である。バージョン情報、パディング、およびSSRC識別子は、図８で示されるRTPパケットの場合と同様であるので、その説明は省略する。
【０１４７】
NACKパケットにおいて、パディングに続いて５ビットのサブタイプが配置される。
【０１４８】
NACKパケットにおいて、ペイロードタイプは２０４とされる。ペイロードタイプの次に配置される、１６ビットのメッセージ長は、NACKパケットの長さ（サイズ）を示す情報である。
【０１４９】
３２ビットのSSRC識別子に続いて、３２ビットの名前が配置される。名前は、例えば、NACKパケットを取り扱うアプリケーションプログラムの名前である。
【０１５０】
名前に続いて配置される３２ビットの要求シーケンス番号は、パケットロスが発生したRTPパケット、すなわち、クライアント２４によって再送が要求されるパケットを特定するシーケンス番号を示す。
【０１５１】
一方、ステップＳ３４において、パケットロスが発生していないと判定された場合、NACKパケットを送信する必要がないので、ステップＳ３５の処理はスキップされ、手続きは、ステップＳ３２に戻る。
【０１５２】
ステップＳ３２において、タイマ１２７が終了したと判定された場合、ステップＳ３６に進み、制御部１２１は、デコーダ１２５にバッファ１２４からRTPパケットを１フレーム分取得させる。
【０１５３】
ステップＳ３７において、制御部１２１は、デコーダ１２５に、取得させたRTPパケットから画像データを抽出させ、抽出された画像データをデコードさせる。そして、制御部１２１は、デコーダ１２５に、デコードされた画像データを出力装置２５に供給させる。
【０１５４】
ステップＳ３８において、制御部１２１は、デコーダ１２５に、デコードされた画像データを格納するRTPパケットのヘッダ情報をACKモード設定部１２６に供給させる。ACKモード設定部１２６は、デコードされた画像データを格納するRTPパケットのヘッダ情報を格納する。ACKモード設定部１２６は、RTPヘッダ情報をNACK処理部１３２に供給する。
【０１５５】
なお、ACKモード設定部１２６は、使用者の操作に対応してクライアント２４の入力部４６から所定の信号が提供された場合、デコーダ１２５が復号する画像データが所定のビットレート以上である場合、またはサーバ２２から指示された場合、ACKモードに設定する。ACKモード設定部１２６は、NACK処理部１２３を介して、ACKモードであるか否かを示す信号を制御部１２１に供給する。
【０１５６】
スッテップＳ３９において、制御部１２１は、ACKモード設定部１２６から供給された信号を基に、ACKモードであるか否かを判定する。
【０１５７】
ステップＳ３９において、ACKモードでないと判定された場合、手続きは、ステップＳ４１に進み、ACKモードであると判定された場合、手続きは、ステップＳ４０に進む。
【０１５８】
ステップＳ４０において、制御部１２１は、NACK処理部１３２に、ACKモード設定部１２６から供給されたヘッダ情報を基に、サーバ２２に通知すべきシーケンス番号を含む確認応答信号を生成させ、通信部１２２に供給させる。制御部１２１は、通信部１２２に、通信網２３を介して、応答確認信号をサーバ２２あてに送信させる。
【０１５９】
確認応答信号は、例えば、ACKパケットとすることができる。
【０１６０】
図１１は、ACKパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図１０で示されるNACKパケットの場合と同様であるので、その説明は省略する。
【０１６１】
ACKパケットにおいて、ペイロードタイプは２０６とされる。
【０１６２】
ACKパケットにおいて、名前の次に配置されるシーケンス番号は、デコードが終了した画像データが格納されたRTPパケットに含まれるシーケンス番号である。
【０１６３】
次に、ステップＳ４１において、制御部１２１は、NACK処理部１３２に、最終処理期限のフレームを計算させる。最終処理期限のフレームとは、式（１）を満たすフレームのうち最も後に再生されるフレームの次に再生されるフレームを言う。
【０１６４】
往復遅延時間＞フレームの再生までの時間        ・・・（１）
【０１６５】
ここで、往復遅延時間の値は、現時刻における、クライアント２４が、サーバ２２にロスパケットの再送を要求してから、クライアント２４が再送されたパケットを受信するまでに必要とされる時間である。
【０１６６】
最終処理期限のフレームは、再送要求をして、再送が間に合うフレームのうち、最も先に再生されるフレームであるとも言える。
【０１６７】
往復遅延時間は、式（２）により算出される。
【０１６８】
往復遅延時間=
（RTT計測パケットの受信時刻）−（RTT計測パケットの送信時刻）
・・・（２）
【０１６９】
ここで、RTT計測パケット１７２の受信時刻は、RTT計測部１２８が通信部１２２からRTT計測パケット１７２を供給されたときに、RTT計測部１２８がRTC１３０から取得した時刻（例えば、図６の時刻ｔ１２２）である。また、RTT計測パケット１７２の送信時刻は、受信したRTT計測パケット１７２を相手に送信させるためのRTT計測パケット１７２を相手に宛てて送信した時刻（例えば、図６の時刻ｔ１２１）である。
【０１７０】
例えば、図６の時刻ｔ１２７においては、RTT保持部１２９に保持されている往復遅延時間は、T１２であり、式（１）を満たすフレームのうち最も後に再生されるフレームが、再生時間T１１−１において再生されるフレーム１７１−１なので、最終処理期限のフレームは、フレーム１７１−２である。
【０１７１】
図９のフローチャートの説明に戻り、ステップＳ４２において、制御部１２１は、NACK処理部１３２に、バッファ１２４に格納されているRTPパケットを検査させ、その結果を示す信号を基に、算出された最終処理期限のフレームの中にロスパケットがあるか否かを判定する。
【０１７２】
ステップＳ４２において、ロスパケットがあると判定された場合は、ステップＳ４３に進み、制御部１２１は、NACK処理部１３２に、最終処理期限にあるフレームのロスパケットの再送要求、すなわち最終再送要求としてのNACKパケットを生成させ、通信部１２２に供給させる。制御部１２１は、通信部１２２に、通信網２３を介して、NACKパケットをサーバ２２あてに送信させる。
【０１７３】
最終再送要求は、例えば、図１２で示されるNACKパケットである。
【０１７４】
図１２は、最終再送要求としてのNACKパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図１０で示されるNACKパケットの場合と同様であるので、その説明は省略する。
【０１７５】
最終再送要求を示すNACKパケットにおいて、ペイロードタイプは、２０７とされる。
【０１７６】
名前の次に配置される要求シーケンス番号は、最終処理期限のフレームのロスパケットすなわち、クライアント２４によって最終再送要求がなされるパケットを特定するシーケンス番号を示す。
【０１７７】
図９に戻り、ステップＳ４２において、最終処理期限のフレームの中にロスパケットがないと判定された場合、最終再送要求を行う必要がないので、ステップＳ４３の処理はスキップされ、処理はステップＳ４４に進む。ステップＳ４４において、制御部１２１はタイマ１２７を更新して、処理は、ステップＳ３２に戻り、上述した処理を繰り返す。
【０１７８】
例えば、ステップＳ４４において、制御部１２１は、タイマ１２７の値を0msにセットする。
【０１７９】
以上のように、クライアント２４は応答の処理として、サーバ２２に、最終再送要求を行うか、または応答確認信号を送信する。
【０１８０】
次に、図１３のフローチャートを参照して、クライアントプログラムを実行するクライアント２４によるRTT計測パケット１７２の送信処理について説明する。
【０１８１】
ステップＳ６１において、制御部１２１は、タイマ１３１の初期化を行う。例えば、ステップＳ６１において、制御部１２１は、タイマ１３１の値を0sにセットし、10sなどの所定の値と比較することによりタイマ１３１が終了したか否かを判定する。
【０１８２】
ステップＳ６２において、制御部１２１は、RTT計測部１２８に、タイマ１３１の値を基に、タイマが終了したか否かを判定させる。
【０１８３】
ステップＳ６２において、タイマ１３１が終了したと判定された場合、処理はステップＳ６３に進み、制御部１２１は、RTT計測部１２８に、RTC１３０から現在時刻を取得させる。
【０１８４】
次に、ステップＳ６４において、制御部１２１は、RTT計測部１２８に、RTT計測パケット１７２を生成させる。例えば、RTT計測部１２８は、図１４で示されるRTT計測パケット１７２を生成する。
【０１８５】
図１４は、RTT計測パケット１７２を説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図１０で示されるNACKパケットの場合と同様であるので、その説明は省略する。
【０１８６】
RTT計測パケット１７２において、ペイロードタイプは２０５とされる。
【０１８７】
RTT計測パケット１７２において、名前の次に配置される送信時刻は、サーバ２２がクライアント２４に、そのRTT計測パケット１７２を送信した時刻を示す。
【０１８８】
図１３のフローチャートに戻り、ステップＳ６５において、制御部１２１は、RTT計測部１２８に、生成されたRTT計測パケット１７２を通信部１２２に供給させ、通信部１２２に、通信網２３を介して、RTT計測パケット１７２をサーバ２２あてに送信させる。
【０１８９】
ステップＳ６６において、制御部１２１はタイマ１３１の値をセットして、処理はステップＳ６２に戻り、上述した処理を繰り返す。
【０１９０】
例えば、ステップＳ６６において、制御部１２１は、タイマ１３１の値を0sにセットする。
【０１９１】
一方、ステップＳ６２において、タイマ１３１が終了していないと判定された場合、ステップＳ６７に進む。
【０１９２】
ステップＳ６７において、制御部１２１は、通信部１２２に、サーバ２２から返送されてくるRTT計測パケット１７２を受信したか否かを判定させる。RTT計測パケット１７２を受信していないと判定された場合、処理はステップＳ６２に戻る。
【０１９３】
ステップＳ６７において、RTT計測パケット１７２を受信したと判定された場合は、ステップＳ６８に進み、制御部１２１は、通信部１２２に、受信されたRTT計測パケット１７２をRTT計測部１２８に供給させる。そして、制御部１２１は、RTT計測部１２８に、RTC１３０から現在時刻を取得させる。このときに取得された現在時刻が、RTT計測パケット１７２の受信時刻となる。
【０１９４】
ステップＳ６９において、制御部１２１は、RTT計測部１２８に、往復遅延時間を算出させる。例えば、ステップＳ６９において、RTT計測部１２８は、往復遅延時間を、式（２）を基に算出する。
【０１９５】
ステップＳ７０において、制御部１２１は、RTT計測部１２８に、算出させた往復遅延時間をRTT保持部１２９に供給させる。RTT保持部１２９は、往復遅延時間を保持（記憶）する。ステップＳ７０の処理の後、手続きは、ステップＳ６２に戻り、上述した処理を繰り返す。
【０１９６】
以上のようにして、クライアント２４は、往復遅延時間を算出して、記憶することが出来る。
【０１９７】
次に、図１５のフローチャートを参照して、サーバプログラムを実行するサーバ２２による再送パケット消去の処理について説明する。
【０１９８】
ステップＳ９１において、制御部８１は、NACK処理部８６から供給される信号を基に、NACKパケットを受信したか否かを判定する。例えば、ステップＳ９１において、通信部４９の受信部１０２は、NACKパケットを含む各種のパケットを受信し、受信したパケットをNACK処理部８６に供給する。NACK処理部８６は、受信部１０２から供給されたパケットのペイロードタイプの値に対応する信号を制御部８１に供給する。制御部８１は、受信されたパケットのペイロードタイプの値に対応する信号を基に、NACKパケットを受信したか否かを判定する。
【０１９９】
ステップＳ９１において、NACKパケットを受信したと判定された場合、処理はステップＳ９２に進み、制御部８１は、NACK処理部８６に、再送要求のあったシーケンス番号の再送パケットを再送させる。例えば、NACK処理部８６は、受信したNACKパケットから、要求シーケンス番号を抽出する。そして、NACK処理部８６は、再送用バッファ８５に、抽出されたシーケンス番号の値と同じ値のシーケンス番号を格納するRTPパケットを通信部４９に供給させる。制御部８１は、通信部４９に、通信網２３を介して、再送パケットであるRTPパケットをクライアント２４あてに送信させる。
【０２００】
ステップＳ９３において、制御部８１は、受信したNACKパケットが最終処理期限のフレームのロスパケットを示すNACKパケットであるか否かを判定する。例えば、制御部８１は、NACK処理部８６から供給されたパケットのペイロードタイプの値に対応する信号を基に、ペイロードタイプの値と、２０７とを比較することにより、NACKパケットであるか否かを判定する。
【０２０１】
ステップＳ９３において、受信されたNACKパケットが、最終処理期限のフレームのロスパケットを示すNACKパケット、つまり最終再送要求としてのNACKパケットであると判定された場合は、処理はステップＳ９４に進み、制御部８１は、NACK処理部８６に、再送を要求されたシーケンス番号以下のシーケンス番号を格納するRTPパケットを再送用バッファ８５から消去させ、ステップＳ９１に戻り、データ消去の処理を繰り返す。
【０２０２】
例えば、図６の時刻ｔ８４において、最終再送要求としてのNACKパケットを受信したサーバ２２は、時刻ｔ８４より後には、再送パケット１８２−１乃至再送パケット１８２−５の再送を要求されることはないので、サーバ２２は、再送パケット１８２−５をクライアント２４に送信するとともに、再送用バッファ８５に格納されている再送パケット１８２−１乃至再送パケット１８２−５を消去する。
【０２０３】
ステップＳ９３において、受信されたNACKパケットが最終処理期限のフレームのロスパケットを示すNACKパケットではない、すなわち最終再送要求としてのNACKパケットではないと判定された場合、再送パケットを消去することはできないので、ステップＳ９４の処理は、スキップされ、ステップＳ９１に戻り、データ消去の処理を繰り返す。
【０２０４】
次に、ステップＳ９１において、NACKパケットを受信していないと判定された場合、ステップＳ９５に進み、制御部８１は、RTT計測パケット１７２を受信したか否かを判定する。ステップＳ９６において、RTT計測パケット１７２を受信したと判定された場合、ステップＳ９６に進み、制御部８１は、NACK処理部８６に、受信されたRTT計測パケット１７２をクライアント２４に返送させ、処理はステップＳ９１に戻り、データ消去の処理を繰り返す。
【０２０５】
より詳細には、例えば、ステップＳ９６において、NACK処理部８６は、受信されたRTT計測パケット１７２のデータ部（ヘッダを除く部分）と同様のデータ部を有する新たなRTT計測パケット１７２を生成し、生成したRTT計測パケット１７２を通信部４９に供給する。通信部４９は、NACK処理部８６から供給されたRTT計測パケット１７２を通信網２３を介してクライアント２４に送信する。
【０２０６】
一方、ステップＳ９５において、RTT計測パケット１７２を受信していないと判定された場合、ステップＳ９７に進み、制御部８１は、確認応答信号を受信したか否かを判定する。例えば、制御部８１は、NACK処理部８６から供給されたパケットのペイロードタイプの値に対応する信号を基に、ペイロードタイプの値と、２０６とを比較することにより、NACKパケットであるか否かを判定する。
【０２０７】
ステップＳ９７において、確認応答信号を受信したと判定された場合、ステップＳ９８に進み、制御部８１は、NACK処理部８６に、受信された確認応答信号に含まれるシーケンス番号以下のシーケンス番号を格納するRTPパケット、すなわち、再生の終了したストリーミングデータが格納されたRTPパケットを再送用バッファ８５から消去させ、ステップＳ９１に戻り、上述した処理を繰り返す。
【０２０８】
ステップＳ９７において、応答確認信号を受信していないと判定された場合、RTPパケットを消去することはできないので、処理はステップＳ９１に戻り、上述した処理を繰り返す。
【０２０９】
以上のようにして、サーバ２２は再送用バッファ８５から不要になった再送パケットを消去する。
【０２１０】
このように、サーバがクライアントから送信されたNACKパケットおよびACKパケットを受信することによって、再生が終了して不要になった再送パケットを再送用バッファから消去する。このことにより、サーバは、再送用バッファの記憶領域をより少なくすることができる。
【０２１１】
なお、パケットに含まれるシーケンス番号をNACKパケットおよびACKパケットに格納し、シーケンス番号を基に、不要になった再送パケットを消去すると説明したが、シーケンス番号に限らず、再生の順番を示す再生順番情報や、タイムスタンプなどの時刻情報など他の情報を用いるようにしても良い。
【０２１２】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０２１３】
この記録媒体は、図３に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク６１（フレキシブルディスクを含む）、光ディスク６２（CD-ROM(Compact Disc-Read Only Memory)、DVD(Digital Versatile Disc)を含む）、光磁気ディスク６３（MD(Mini-Disc)（商標）を含む）、若しくは半導体メモリ６４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM４２や、記録部４８に含まれるハードディスクなどで構成される。
【０２１４】
なお、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインタフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
【０２１５】
また、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２１６】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【図面の簡単な説明】
【０２１７】
【図１】従来のストリーミングデータ配信システムを説明する図である。
【図２】本発明に係るストリーミングデータ配信システムの一実施の形態を示す図である。
【図３】サーバの構成の例を示すブロック図である。
【図４】サーバの機能の構成を示すブロック図である。
【図５】クライアントの機能の構成を示すブロック図である。
【図６】ストリーミングデータ配信システムを説明するタイムチャートである。
【図７】ストリーミングデータの送信の処理を説明するフローチャートである。
【図８】RTPパケットを説明する図である。
【図９】応答の処理を説明するフローチャートである。
【図１０】NACKパケットを説明する図である。
【図１１】ACKパケットを説明する図である。
【図１２】最終再送要求を示すNACKパケットを説明する図である。
【図１３】RTT計測パケットの送信の処理を説明するフローチャートである。
【図１４】RTT計測パケットを説明する図である。
【図１５】データ消去の処理を説明するフローチャートである。
【符号の説明】
【０２１８】
２２  サーバ，  ２３  通信網，  ２４  クライアント，  ４１  ＣＰＵ，  ４２  ROM，  ４３  RAM，  ４８  記録部，  ６１  磁気ディスク，  ６２  光ディスク，  ６３  光磁気ディスク，  ６４  半導体メモリ，  ８１  制御部，  ８２  エンコーダ，  ８４  パケタイザ，  ８５  再送用バッファ，  ８６  NACK処理部，  １０１  送信部，  １０２  受信部，  １２１  制御部，  １２２  通信部，  １２３  RTP処理部，  １２５  デコーダ，  １２６  ACKモード設定部，  １２８  RTT計測部，  １２９  RTT保持部，  １５１  受信部，  １５２  送信部
【図１】
2005136545.tif 000003
【図２】
2005136545.tif 000004
【図３】
2005136545.tif 000005
【図４】
2005136545.tif 000006
【図５】
2005136545.tif 000007
【図６】
2005136545.tif 000008
【図７】
2005136545.tif 000009
【図８】
2005136545.tif 000010
【図９】
2005136545.tif 000011
【図１０】
2005136545.tif 000012
【図１１】
2005136545.tif 000013
【図１２】
2005136545.tif 000014
【図１３】
2005136545.tif 000015
【図１４】
2005136545.tif 000016
【図１５】
2005136545.tif 000017