JP2006067410A - 送信装置および方法、プログラム、並びに送受信システム - Google Patents

Abstract

【課題】ネットワークへの負荷を少なくして、送信装置がRTTを計算することができるようにする。
【解決手段】 サーバ１２のRTP生成部７２は、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のRTPパケットを生成し、複数のRTPパケットのうちの１つのRTPパケットを、再生される順番と異なる順番にリオーダし、送信部８１に供給してクライアントに送信させる。RTT計算部７６は、クライアントから送信されてきたRTPパケットの再送要求を表すNACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されているリオーダされたRTPパケットのシーケンス番号と一致する場合に、現在時刻と、リオーダされたRTPパケットの送信時刻とから、RTT(Round Trip Time)を計算する。本発明は、例えば、送信レートを制御してデータを送受信するシステムに適用できる。
【選択図】図３

Description

本発明は、送信装置および方法、プログラム、並びに送受信システムに関し、特に、ネットワークへの負荷を少なくして、送信装置がRTTを計算することができる送信装置および方法、プログラム、並びに送受信システムに関する。

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

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

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

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

より具体的な例として、ストリーム型の伝送方式は、画像データに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によって提供されるトランスポートサービスの範疇ではないため、他の方式のパケットと同様、ネットワーク上での遅延やパケットロスが生じる可能性がある。

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

この場合、再生に間に合わず遅延して配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、高品質なデータ配信処理を行おうとしても、パケットロスやエラーが発生したときは、受信側の再生の品質は保証されない。

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

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

そこで、RTPに基づくデータ伝送に、ARQ（Automatic Repeat Request）などのエラー訂正の方式を採用することにより、リアルタイム性を満足しつつ、受信側の再生の品質を出来るだけ良くするようにした伝送方式が実現されている。ARQ方式は、受信したRTPパケットに含まれるシーケンス番号をチェックし、順番にインクリメントされるはずのシーケンス番号に抜けた番号があった場合、受信装置が、送信装置に対して、その抜けた番号のRTPパケットの再送要求を送信し、送信側に再度送信させることにより、パケットエラーを回復する方式である。

一方、パケットロスを発生させないようにするため（受信側の再生の品質を維持するため）に、送信側である送信装置では、ネットワークの輻輳（状態）を検知し、その輻輳に応じて、送信レートを制御することが考えられる。即ち、送信装置は、ネットワークが輻輳であるとみなされる場合には、送信レートを低くし、ネットワークが非輻輳であるとみなされる場合には、送信レートを上げてRTPパケットを受信装置に送信する。

ここで、ネットワークの輻輳を検知する方法としては、RTT(Round Trip Time；往復伝播遅延時間)を計測する方法がある（例えば、特許文献１および２参照）。

従って、例えば、送信装置が、RTTを定期的に計測し、計測されたRTTが増える傾向にあるのであれば、ネットワークが輻輳であるとみなし、計測されたRTTが減少する傾向にあるのであれば、ネットワークが非輻輳であるとみなすことにより、送信レートを制御するようにすればよい。

特開２００２−３７４３０２号公報 特開２００３−１７９５８０号公報

しかしながら、送信装置がRTTを計算するためには、従来の方法では、送信装置が、RTTを計算するためのRTPパケットであるRTT計測パケットを生成して、受信装置に送信し、その送信されたRTT計測パケットが受信装置から返信されてくるまでの往復時間を計算するなどしていた。

この方法によれば、ネットワーク上に、RTTを計算するためだけの無駄なパケットが流れることになり、ネットワークに負荷を与えることになっていた。また、送信装置および受信装置の両方にRTT計測パケットを処理する手段を設けなければならず、送信装置および受信装置ともに、その構成が複雑になるという問題があった。

本発明は、このような状況に鑑みてなされたものであり、ネットワークへの負荷を少なくして、送信装置がRTTを計算することができるようにするものである。

本発明の送信装置は、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のパケットを生成し、複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段と、パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む複数のパケットを他の装置に送信する送信手段と、リオーダパケットがリオーダされずに本来の再生される順番で他の装置に送信されたとした場合のリオーダパケットの送信時刻と、リオーダパケットのシーケンス番号とを記憶する記憶手段と、他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信手段と、再送要求パケットに格納されているシーケンス番号が、記憶手段に記憶されているリオーダパケットのシーケンス番号と一致するか否かを判定する判定手段と、再送要求パケットに格納されているシーケンス番号と、記憶手段に記憶されているリオーダパケットのシーケンス番号とが一致する場合に、現在時刻と送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段とを備えることを特徴とする。

パケット生成手段には、所定の時間ごとに、複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダさせるようにすることができる。

本発明の送信方法は、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のパケットを生成し、複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成ステップと、パケット生成ステップにおいてリオーダされたパケットであるリオーダパケットを含む複数のパケットを他の装置に送信する送信ステップと、リオーダパケットがリオーダされずに本来の再生される順番で他の装置に送信されたとした場合のリオーダパケットの送信時刻と、リオーダパケットのシーケンス番号とを記憶手段に記憶させる記憶ステップと、他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信ステップと、再送要求パケットに格納されているシーケンス番号が、記憶手段に記憶されているリオーダパケットのシーケンス番号と一致するか否かを判定する判定ステップと、再送要求パケットに格納されているシーケンス番号と、記憶手段に記憶されているリオーダパケットのシーケンス番号とが一致する場合に、現在時刻と送信時刻とから、RTT(Round Trip Time)を計算するRTT計算ステップとを含むことを特徴とする。

本発明のプログラムは、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のパケットを生成し、複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成ステップと、パケット生成ステップにおいてリオーダされたパケットであるリオーダパケットを含む複数のパケットを他の装置に送信する送信ステップと、リオーダパケットがリオーダされずに本来の再生される順番で他の装置に送信されたとした場合のリオーダパケットの送信時刻と、リオーダパケットのシーケンス番号とを記憶手段に記憶させる記憶ステップと、他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信ステップと、再送要求パケットに格納されているシーケンス番号が、記憶手段に記憶されているリオーダパケットのシーケンス番号と一致するか否かを判定する判定ステップと、再送要求パケットに格納されているシーケンス番号と、記憶手段に記憶されているリオーダパケットのシーケンス番号とが一致する場合に、現在時刻と送信時刻とから、RTT(Round Trip Time)を計算するRTT計算ステップとを含む処理をコンピュータに実行させることを特徴とする。

本発明の送受信システムは、第１の装置は、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のパケットを生成し、複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段と、パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む複数のパケットを第２の装置に送信する第１の送信手段と、リオーダパケットがリオーダされずに本来の再生される順番で第２の装置に送信されたとした場合のリオーダパケットの送信時刻と、リオーダパケットのシーケンス番号とを記憶する記憶手段と、第２の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する第１の受信手段と、再送要求パケットに格納されているシーケンス番号が、記憶手段に記憶されているリオーダパケットのシーケンス番号と一致するか否かを判定する判定手段と、再送要求パケットに格納されているシーケンス番号と、記憶手段に記憶されているリオーダパケットのシーケンス番号とが一致する場合に、現在時刻と送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段とを備え、第２の装置は、第１の装置から送信されてくる複数のパケットを受信する第２の受信手段と、第２の受信手段により受信された複数のパケットのシーケンス番号が再生される順番と異なる順番である場合に、本来の再生される順番となるために必要なパケットの再送要求パケットを送信する第２の送信手段とを備えることを特徴とする。

本発明においては、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のパケットが生成され、複数のパケットのうちの１つのパケットが、再生される順番と異なる順番にリオーダされる。また、リオーダされたパケットであるリオーダパケットを含む複数のパケットが他の装置に送信され、リオーダパケットがリオーダされずに本来の再生される順番で他の装置に送信されたとした場合のリオーダパケットの送信時刻と、リオーダパケットのシーケンス番号とが記憶手段に記憶される。そして、他の装置から送信されてくる、パケットの再送を要求する再送要求パケットが受信され、その再送要求パケットに格納されているシーケンス番号と、記憶手段に記憶されているリオーダパケットのシーケンス番号とが一致する場合に、現在時刻と送信時刻とから、RTT(Round Trip Time)が計算される。

本発明によれば、ネットワークへの負荷を少なくして、送信装置がRTTを計算することができる。

以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。

さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。

請求項１に記載の送信装置は、
ストリーミングデータを格納した複数のパケットの送信処理を行う送信装置（例えば、図３のサーバ１２）において、
前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段（例えば、図３のRTP生成部７２）と、
前記パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを他の装置に送信する送信手段（例えば、図３の送信部８１）と、
前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記他の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶する記憶手段（例えば、図３のリオーダ履歴保持部７４）と、
前記他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信手段（例えば、図３の受信部８２）と、
前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定手段（例えば、図３のNACK処理部７５）と、
前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段（例えば、図３のRTT計算部７６）と
を備えることを特徴とする。

請求項３に記載の情報処理方法は、
ストリーミングデータを格納した複数のパケットの送信方法において、
前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成ステップ（例えば、図８のステップＳ９の処理）と、
前記パケット生成ステップにおいてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを他の装置に送信する送信ステップ（例えば、図８のステップＳ１１の処理）と、
前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記他の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶手段に記憶させる記憶ステップ（例えば、図８のステップＳ１２の処理）と、
前記他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信ステップ（例えば、図９のステップＳ３１の処理）と、
前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定ステップ（例えば、図９のステップＳ３２の処理）と、
前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算ステップ（例えば、図９のステップＳ５３の処理）と
を含むことを特徴とする。

請求項５に記載の送受信システムは、
ストリーミングデータを格納した複数のパケットを送受信する第１および第２の装置からなる送受信システムにおいて、
前記第１の装置（例えば、図３のサーバ１２）は、
前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段（例えば、図３のRTP生成部７２）と、
前記パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを前記第２の装置に送信する第１の送信手段（例えば、図３の送信部８１）と、
前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記第２の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶する記憶手段（例えば、図３のリオーダ履歴保持部７４）と、
前記第２の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する第１の受信手段（例えば、図３の受信部８２）と、
前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定手段（例えば、図３のNACK処理部７５）と、
前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段（例えば、図３のRTT計算部７６）と
を備え、
前記第２の装置（例えば、図４のクライアント１４）は、
前記第１の装置から送信されてくる前記複数のパケットを受信する第２の受信手段（例えば、図４の受信部１１１）と、
前記第２の受信手段により受信された前記複数のパケットの前記シーケンス番号が再生される順番と異なる順番である場合に、本来の前記再生される順番となるために必要なパケットの前記再送要求パケットを送信する第２の送信手段（例えば、図４の送信部１１２）と
を備える
ことを特徴とする。

以下、図を参照して、本発明の実施の形態について説明する。

図１は、本発明を適用したストリーミング配信システムの一実施の形態の構成例を示している。

図１のストリーミング配信システムにおいては、インターネットなどの通信網１３に、サーバ１２およびクライアント１４が接続されている。

ビデオカメラ１１は、画像を撮像して、撮像した画像に対応する画像データをサーバ１２に供給する。例えば、ビデオカメラ１１は、動画像を撮像して、動画像に対応する画像データをサーバ１２に供給する。

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

サーバ１２は、コンピュータなどにより構成され、クライアント１４からストリーミングデータの配信が要求された場合、ビデオカメラ１１から供給される画像データをパケットに格納して、その画像データが格納されたパケットを、通信網１３を介してクライアント１４に送信する。

通信網１３は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、サーバ１２から送信されたパケットをクライアント１４まで伝送する。また、通信網１３は、クライアント１４から送信された、所定のパケットの再送要求を表すパケットであるNACKパケット（再送要求パケット）をサーバ１２まで伝送する。

クライアント１４は、コンピュータなどにより構成され、サーバ１２から送信されてくるパケットを受信する。また、クライアント１４は、受信したパケットから画像データを抽出し、抽出した画像データに基づいて、画像を表示装置等（図示せず）に表示させる。

図２は、サーバ１２のハードウエアの構成例を示すブロック図である。

CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２、または記録部３８に記録されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）３３には、CPU３１が実行するプログラムやデータなどが適宜記憶される。これらのCPU３１，ROM３２、およびRAM３３は、バス３４により相互に接続されている。

CPU３１にはまた、バス３４を介して入出力インタフェース３５が接続されている。入出力インタフェース３５には、キーボード、マウス、スイッチなどよりなる入力部３６、ディスプレイ、スピーカ、ランプなどよりなる出力部３７が接続されている。CPU３１は、入力部３６から入力される指令に対応して各種の処理を実行する。

入出力インタフェース３５に接続されている記録部３８は、例えばハードディスクなどで構成され、CPU３１が実行するプログラムや各種のデータを記録する。通信部３９は、例えば、モデムやターミナルアダプタなどにより構成され、インターネット、その他のネットワークなどの通信網１３を介して、クライアント１４などの外部の装置と通信する。また、通信部３９は、通信網１３を介してプログラムを取得する。これにより取得されたプログラムは、CPU３１の制御に従い、記録部３８に記録される。

入出力インタフェース３５に接続されているドライブ４０は、磁気ディスク５１、光ディスク５２、光磁気ディスク５３、或いは半導体メモリ５４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部３８に転送され、記録される。

なお、図１のクライアント１４のハードウエアも、上述した図２のサーバ１２と同様に構成されるので、同図を適用する。

図３は、サーバ１２の機能的な構成例を示すブロック図である。

サーバ１２は、エンコーダ７１、RTP生成部７２、再送用バッファ７３、リオーダ履歴保持部７４、NACK処理部７５、RTT計算部７６、および通信部７７により構成される。また、通信部７７は、送信部８１および受信部８２により構成される。

図３において、エンコーダ７１、RTP生成部７２、NACK処理部７５、およびRTT計算部７６の機能は、例えば、図２のCPU３１に所定のプログラムを実行させることにより実現することができる。また、再送用バッファ７３、およびリオーダ履歴保持部７４の機能は、RAM３３または記録部３８により実現することができる。さらに、通信部７７の機能は、図２の通信部３９により実現することができる。

エンコーダ７１は、フレームレートを決定するタイマ（以下、FRタイマという）を内蔵している。そして、エンコーダ７１は、所定の時間に設定されたFRタイマのカウントが終了するまでの間にビデオカメラ１１から供給される画像データを、１フレームとしてキャプチャする。例えば、FRタイマの設定時間が、３３msecに設定されている場合、フレームレートは、３０fps(frame per second)となる。

また、エンコーダ７１は、ビデオカメラ１１から供給される画像データを所定の方式（例えば、MPEG１，２，４，７、もしくは２１，JPEG（Joint Photographic Experts Group）、JPEG２０００、またはモーションJPEGなど）によりエンコード（符号化）し、そのエンコードされた（１フレームごとの）画像データをRTP生成部７２に供給する。

RTP生成部７２は、１フレーム分の画像データを複数の画像データに分割し、その分割された画像データそれぞれを格納した複数のRTPパケットを生成する。なお、同一の１フレームを構成する複数の画像データそれぞれが格納されている複数のRTPパケットには、共通のタイムスタンプが設定される。また、RTPパケットそれぞれには、画像データが再生される順番にシーケンス番号が付与される（図６で後述）。

また、RTP生成部７２は、生成した１フレームあたり複数のRTPパケットを、通常は、シーケンス番号通りに（シーケンス番号に従って）通信部７７の送信部８１および再送用バッファ７３に供給する。

さらに、RTP生成部７２は、所定の設定時間経過ごとに、１フレームあたり複数のRTPパケットのうちの１つのRTPパケットを、シーケンス番号と異なる順番に故意にリオーダし（入れ替え）、通信部７７の送信部８１および再送用バッファ７３に供給する。RTP生成部７２は、シーケンス番号をリオーダさせる所定の設定時間をカウントするリオーダタイマを有している。ここで、リオーダタイマは、例えば、１secなどに設定される。以下では、シーケンス番号と異なる順番に故意にリオーダさせたRTPパケットをリオーダRTPパケットという。

また、RTP生成部７２は、リオーダRTPパケットが本来送信されるべき時刻と、リオーダRTPパケットのシーケンス番号とをリオーダ履歴保持部７４に供給する。ここで、リオーダRTPパケットが本来送信されるべき時刻とは、リオーダRTPパケットがリオーダされずに本来の再生される順番でクライアント１４に送信されたとした場合のリオーダRTPパケットの送信時刻を意味する。

なお、後述する送信部８１では、RTP生成部７２から供給されたRTPパケットを即座にクライアント１４に送信する。従って、RTP生成部７２がRTPパケットを送信部８１に供給したときの時刻は、サーバ１２がクライアント１４にRTPパケットを送信した送信時刻とみなすことができる。

リオーダ履歴保持部７４は、RTP生成部７２から供給される、リオーダRTPパケットが本来送信されるべき時刻（送信時刻）と、リオーダRTPパケットのシーケンス番号と（以下、リオーダRTPパケットの、送信時刻とシーケンス番号とのセットという）を記憶（保持）する。

再送用バッファ７３は、RTP生成部７２から供給されるRTPパケットを一時的に記憶する。そして、再送用バッファ７３は、NACK処理部７５からの要求に応じて、記憶しているRTPパケットをNACK処理部７５に供給する。

NACK処理部７５には、通信部７７の受信部８２から、所定のRTPパケットの再送要求を表すNACKパケット（再送要求パケット）が供給される。NACK処理部７５は、リオーダ履歴保持部７４を参照し、NACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されている、リオーダRTPパケットのシーケンス番号と一致するか否かを判定する。

NACKパケットに格納されているシーケンス番号がリオーダRTPパケットのシーケンス番号と一致しないと判定された場合、即ち、通信網１３上において、RTPパケットのパケットロスが実際に発生し、クライアント１４よりNACKパケットが送信されてきた場合、NACK処理部７５は、NACKパケットに格納されているシーケンス番号のRTPパケットを再送用バッファ７３から抽出（取得）し、送信部８１に供給する。

一方、NACKパケットに格納されているシーケンス番号がリオーダRTPパケットのシーケンス番号と一致すると判定された場合、即ち、NACKパケットにより再送が要求されているRTPパケットは、パケットロスが発生したのではなく、RTP生成部７２がリオーダしたことにより再送が要求されているRTPパケットである場合、NACK処理部７５は、NACKパケットに格納されているシーケンス番号をRTT計算部７６に供給する。従って、この場合、NACK処理部７５から送信部８１には、NACKパケットにより要求されているRTPパケットは供給されない。

RTT計算部７６には、NACK処理部７５から、シーケンス番号が供給される。RTT計算部７６は、計時機能を有し、NACK処理部７５からシーケンス番号が供給されたときの現在時刻を取得する。NACKパケットに格納されているシーケンス番号がリオーダRTPパケットのシーケンス番号と一致すると判定された場合、NACK処理部７５により、シーケンス番号が即座にRTT計算部７６に供給されるので、RTT計算部７６が取得した現在時刻は、受信部８２がNACKパケットを受信したときの受信時刻とみなすことができる。

また、RTT計算部７６は、NACK処理部７５から供給されるシーケンス番号と同一のシーケンス番号を有するリオーダRTPパケットの、シーケンス番号と送信時刻とのセットをリオーダ履歴保持部７４から取得する。

そして、RTT計算部７６は、NACK処理部７５からシーケンス番号が供給されたときの現在時刻（NACKパケットの受信時刻）と、リオーダ履歴保持部７４から取得した送信時刻とから、RTTを計算する。即ち、RTT計算部７６は、NACK処理部７５からシーケンス番号が供給されたときの現在時刻（NACKパケットの受信時刻）と、リオーダ履歴保持部７４から取得した送信時刻との差（RTT=現在時刻−送信時刻）としてRTTを求める。

送信部８１は、RTP生成部７２またはNACK処理部７５から供給されるRTPパケットを、通信網１３を介して（即座に）クライアント１４に送信する。受信部８２は、クライアント１４から送信されてくるNACKパケット（再送要求パケット）を受信し、受信したNACKパケットを（即座に）NACK処理部７５に供給する。

図４は、クライアント１４の機能的な構成例を示すブロック図である。

クライアント１４は、通信部１０１、RTP処理部１０２、デコーダ１０３、およびNACK処理部１０４により構成される。また、通信部１０１は、受信部１１１および送信部１１２により構成される。

図４において、通信部１０１の機能は、図２の通信部３９により実現することができる。また、RTP処理部１０２、デコーダ１０３、およびNACK処理部１０４の機能は、図２のCPU３１に所定のプログラムを実行させることにより実現することができる。

受信部１１１は、通信網１３を介して、サーバ１２から送信されてくるRTPパケットを受信し、受信したRTPパケットをRTP処理部１０２に供給する。送信部１１２は、NACK処理部１０４から供給されるNACKパケットを、通信網１３を介して、サーバ１２に送信する。

RTP処理部１０２には、RTPパケットが受信部１１１から供給される。RTP処理部１０２は、供給されたRTPパケットから画像データを抽出し、デコーダ１０３に供給する。また、RTP処理部１０２は、受信部１１１から供給されるRTPパケットからシーケンス番号を抽出し、抽出したシーケンス番号をNACK処理部１０４に供給する。

デコーダ１０３は、RTP処理部１０２から供給される画像データを、エンコーダ７１（図３）に対応する方式によりデコードし、デコードされた画像データを表示装置等（図示せず）に出力して表示させる。

NACK処理部１０４は、RTP処理部１０２から順に供給される（受信部１１１が受信した順番で供給される）、RTPパケットのシーケンス番号に基づいて、パケットロスが発生したか否かを判定する。そして、パケットロスが発生した場合、NACK処理部１０４は、そのRTPパケットのシーケンス番号を格納したNACKパケットを送信部１１２に供給する。これにより、送信部１１２より、NACKパケットがサーバ１２（の受信部８２）に送信される。

なお、NACK処理部１０４において、パケットロスが発生したと判定される場合は、通信網１３上において、RTPパケットのパケットロスが実際に発生した場合の他に、RTPパケットがリオーダされている場合も含まれる。

例えば、１，２，３，４，６，５・・・のように、RTPパケットのシーケンス番号が、RTP処理部１０２からNACK処理部１０４に供給された場合、NACK処理部１０４は、シーケンス番号６が供給された時点で、シーケンス番号５のRTPパケットを損失した（パケットロスが発生した）と判定し、NACKパケットの要求シーケンス番号の領域（後述）にシーケンス番号５を格納したNACKパケットを送信部１１２に供給する。

また、例えば、１，２，３，４，７・・・のように、RTPパケットのシーケンス番号が、RTP処理部１０２からNACK処理部１０４に供給された場合、NACK処理部１０４は、シーケンス番号７が供給された時点で、シーケンス番号５と６のRTPパケットを損失した（パケットロスが発生した）と判定し、NACKパケットの要求シーケンス番号の領域にシーケンス番号５または６を格納したNACKパケットそれぞれを、送信部１１２に供給する。

次に、図５を参照して、サーバ１２がRTTを計算する処理の概念を説明する。図５において、サーバ１２およびクライアント１４の横軸は、時間を表し、図中縦方向の同一直線上の時刻は、同一時刻を表す。

サーバ１２は、１フレーム分の画像データから複数のRTPパケットを生成する。図５では、１フレーム分の画像データが７個のRTPパケットP1乃至P7となっている。そして、時刻ｔ_１１において、サーバ１２は、７個のRTPパケットP1乃至P7のクライアント１４への送信を開始する。ここで、サーバ１２のRTP生成部７２は、RTPパケットP5をリオーダRTPパケットとし、RTPパケットP5とP6の順番をリオーダさせ（入れ替え）て、送信部８１に供給する。これにより、図５に示すように、サーバ１２からは、RTPパケットが、P1，P2，P3，P4，P6，P5，P7の順番でクライアント１４に送信される。なお、RTPパケットP1，P2，P3，P4，P6，P5，P7に格納されているシーケンス番号は、それぞれ、1,2,3,4,6,5,7であるとする。

また、RTP生成部７２は、リオーダRTPパケットP5が本来送信されるべき時刻ｔ_１２と、RTPパケットP5のシーケンス番号５とをリオーダ履歴保持部７４に供給し、そこに記憶させる。

時刻ｔ_１１から所定の時間経過後の時刻ｔ_２１において、クライアント１４は、サーバ１２から送信されてきたRTPパケットP1，P2，P3，P4，P6，P5，P7を順に受信する。そして、クライアント１４の受信部１１１は、RTPパケットをP1，P2，P3，P4，P6，P5，P7の順にRTP処理部１０２に供給し、RTP処理部１０２は、シーケンス番号1,2,3,4,6,5,7を、順にNACK処理部１０４に供給する。

ここで、NACK処理部１０４は、シーケンス番号６が供給された時点（時刻ｔ_２２）において、シーケンス番号５のRTPパケットを損失した（パケットロスが発生した）と判定し、要求シーケンス番号５を格納したNACKパケットを送信部１１２に供給する。これによりクライアント１４（の送信部１１２）から、シーケンス番号５の再送を要求するNACKパケットがサーバ１２に送信される。

時刻ｔ_２２から所定の時間経過後の時刻ｔ_１３において、クライアント１４から送信されてきたNACKパケットがサーバ１２（の受信部８２）で受信される。そして、サーバ１２のNACK処理部７５は、NACKパケットに格納されているシーケンス番号５がリオーダ履歴保持部７４に記憶されている、リオーダRTPパケットのシーケンス番号と一致するか否かを判定する。この例では、上述したように、リオーダ履歴保持部７４には、リオーダRTPパケットP5の時刻ｔ_１２とシーケンス番号５とのセットが記憶されているので、NACK処理部７５は、NACKパケットに格納されているシーケンス番号５をRTT計算部７６に供給する。

RTT計算部７６は、リオーダ履歴保持部７４に記憶されている、時刻ｔ_１２とシーケンス番号５とのセットから取得される時刻ｔ_１２（送信時刻）と、NACK処理部７５からシーケンス番号５が供給されたときの時刻ｔ_１３（受信時刻）とから、図中、T_１で示されているRTTを計算する。

以上のようにして、サーバ１２は、RTT計測用のRTT計測パケットをネットワーク（通信網１３）上に送信することなく、RTTを計算することができる。即ち、ネットワークへの負担を少なくして、サーバ１２がRTTを計算することができる。

なお、複数のRTPパケットのうちの、リオーダさせるRTPパケットは、どの位置（シーケンス番号の）RTPパケットであってもよい。

図６は、画像データが格納されるRTPパケットのフォーマットを示している。

図６に示すように、RTPパケットの先頭には、２ビットのバージョン情報（Ｖ）が配置される。バージョン情報（Ｖ）は、RTPパケットのバージョンを示す。バージョン情報（Ｖ）の次には、１ビットのパディング（Ｐ）が配置され、パディング（Ｐ）に続いて、１ビットの拡張情報（Ｘ）が配置される。拡張情報（Ｘ）は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。

拡張情報（Ｘ）に続いて、CSRC（Contributing Source）カウント（ＣＣ）がRTPパケットに配置される。CSRCカウント（ＣＣ）は、CSRC識別子の数を表す。

CSRCカウント（ＣＣ）に続いて配置されている１ビットのマーカ情報（ｍ）は、プロファイルによって定義される。マーカ情報（ｍ）に続いて配置される、７ビットのペイロードタイプ（ＰＴ）は、RTPパケットのフォーマットを定義するための情報である。画像データが格納されるRTPパケットのペイロードタイプ（ＰＴ）は、３３（ＰＴ＝３３）とされる。

ペイロードタイプ（ＰＴ）の次に、１６ビットのシーケンス番号が配置される。シーケンス番号は、上述したように、RTPパケットの再生の順番を表す番号である。

シーケンス番号の次に配置される、３２ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。また、タイムスタンプにより、受信側においてRTPパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御を行うことが可能となる。タイムスタンプは、１つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定される。

SSRC（Synchronization Source）識別子は、タイムスタンプの次に配置される３２ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。

そして、SSRC識別子の次のオリジナルデータ（Original Data）には、画像データが格納される。

図７は、クライアント１４がサーバ１２に送信するNACKパケットのフォーマットを示している。

バージョン情報（Ｖ）、パディング（Ｐ）、およびSSRC識別子については、図６で説明したRTPパケットと同様であるので、その説明を省略する。

図７のNACKパケットでは、パディング（Ｐ）に続いて６ビットのサブタイプが配置される。また、NACKパケットのペイロードタイプ（ＰＴ）は２０４（ＰＴ＝２０４）とされる。ペイロードタイプ（ＰＴ）の次に配置される、１６ビットのメッセージ長（Message Length）には、NACKパケットの長さ（サイズ）を示す情報が入力される。

３２ビットのSSRC識別子に続いて、３２ビットの名前（NAME）が配置される。名前（NAME）は、例えば、NACKパケットを取り扱うアプリケーションプログラムの名前が入力される。

名前（NAME）に続いて配置される３２ビットの要求シーケンス番号には、パケットロスが発生したとみなされるRTPパケットの、換言すれば、再送を要求するRTPパケットのシーケンス番号が入力される。従って、上述した図５のRTTを計算する処理では、時刻ｔ_２２において、クライアント１４がサーバ１２に送信するNACKパケットには、ここの要求シーケンス番号に５が入力されることになる。

次に、図８のフローチャートを参照して、サーバ１２のRTPパケットを送信する送信処理について説明する。

初めに、ステップＳ１において、サーバ１２は、RTPパケットの送信処理に必要なデータを初期化して、ステップＳ２に進む。例えば、ステップＳ１において、エンコーダ７１のFRタイマやRTP生成部７２のリオーダタイマの値が０にセットされた後、それぞれのタイマのカウントが開始される。

ステップＳ２において、エンコーダ７１は、FRタイマのカウントが終了したか否か、即ち、例えば、フレームレートを３０fpsとした場合、FRタイマの設定時間である３３msecが経過したか否かを判定する。ステップＳ２では、FRタイマのカウントが終了したと判定されるまで、同様の処理が繰り返される。

ステップＳ２において、FRタイマのカウントが終了したと判定された場合、即ち、FRタイマが０にセット（リセット）されてから、３３msecの時間が経過した場合、ステップＳ３に進み、エンコーダ７１は、ビデオカメラ１１から供給された画像データを１フレーム分としてキャプチャする。

ステップＳ３の後、ステップＳ４に進み、エンコーダ７１は、キャプチャした画像データをエンコードし、RTP生成部７２に供給する。例えば、ステップＳ４において、エンコーダ７１は、キャプチャした画像データをMPEG１、２、４、７、もしくは２１、JPEG（Joint Photographic Experts Group）、JPEG２０００、またはモーションJPEGなどの所定の方式によりエンコードし、RTP生成部７２に供給して、ステップＳ５に進む。

ステップＳ５において、RTP生成部７２は、リオーダタイマのカウントが終了したか否か、即ち、例えば、リオーダタイマが１secに設定されている場合、リオーダタイマが０にセット（リセット）されてから、１secの時間が経過したか否かを判定する。

ステップＳ５で、リオーダタイマのカウントが終了していないと判定された場合、即ち、リオーダタイマが０にセット（リセット）されてから、１secの時間が経過していない場合、ステップＳ６に進み、RTP生成部７２は、エンコーダ７１から供給された１フレーム分の画像データから、複数のRTPパケットを生成し、ステップＳ７に進む。従って、ステップＳ６で、RTP生成部７２において生成された複数のRTPパケットは、リオーダされない。即ち、シーケンス番号通りに整列している。

ステップＳ７において、RTP生成部７２は、ステップＳ６で生成した、シーケンス番号通りに整列されている複数のRTPパケットを、送信部８１および再送用バッファ７３に供給する。また、ステップＳ７において、再送用バッファ７３は、RTP生成部７２から供給された複数のRTPパケットを記憶して、ステップＳ８に進む。

ステップＳ８において、送信部８１は、RTP生成部７２から供給された複数のRTPパケットを、通信網１３を介して、クライアント１４に送信し、ステップＳ１４に進む。

一方、ステップＳ５において、リオーダタイマのカウントが終了したと判定された場合、即ち、リオーダタイマが０にセット（リセット）されてから、１secの時間が経過した場合、ステップＳ９に進み、RTP生成部７２は、エンコーダ７１から供給された１フレーム分の画像データから、複数のRTPパケットを生成し、その複数のRTPパケットのうちの１つのRTPパケットを、リオーダRTPパケットとしてシーケンス番号と異なる順番にリオーダさせる。

ステップＳ９の後、ステップＳ１０に進み、RTP生成部７２は、ステップＳ９で生成した、１つのRTPパケットがリオーダされている複数のRTPパケットを、送信部８１および再送用バッファ７３に供給する。また、ステップＳ１０において、再送用バッファ７３は、RTP生成部７２から供給された複数のRTPパケットを記憶して、ステップＳ１１に進む。

ステップＳ１１において、送信部８１は、RTP生成部７２から供給された、１つのRTPパケットがリオーダされている複数のRTPパケットを、通信網１３を介して、クライアント１４に送信して、ステップＳ１２に進む。

ステップＳ１２において、RTP生成部７２は、ステップＳ９でリオーダさせた１つのRTPパケットの（リオーダRTPパケットの）、送信時刻とシーケンス番号とのセットをリオーダ履歴保持部７４に供給し、記憶させる。また、ステップＳ１２において、リオーダ履歴保持部７４は、RTP生成部７２から供給された送信時刻とシーケンス番号とのセットを記憶して、ステップＳ１３に進む。なお、ステップＳ１１とＳ１２の処理は、並行に実行することができる。

ステップＳ１３において、RTP生成部７２は、リオーダタイマをリセット（０にセット）して、ステップＳ１４に進む。

ステップＳ１４において、RTP生成部７２は、RTPパケットに格納するタイムスタンプを更新して、ステップＳ１５に進む。

ステップＳ１５において、エンコーダ７１は、FRタイマをリセット（０にセット）して、ステップＳ２に戻り、以下、同様の処理が繰り返される。

以上のように、図８の送信処理によれば、ビデオカメラ１１から供給される画像データが３０fpsのフレームレートでキャプチャされ、１フレームの画像データが、同一のタイムスタンプが格納された複数のRTPパケットとして、サーバ１２からクライアント１４に送信される。

また、図８の送信処理によれば、リオーダタイマのカウントが終了するごとに（１secごとに）、１つのRTPパケットがシーケンス番号と異なる順番にリオーダされた複数のRTPパケットが、サーバ１２からクライアント１４に送信される。なお、リオーダタイマの設定時間を所望の値に変更することにより、サーバ１２が所望のタイミングでRTTを計算することもできる。

図８の送信処理において、FRタイマのリセット（ステップＳ１５の処理）は、ステップＳ３乃至Ｓ１４の処理が終了した後に実行するようにしたが、ステップＳ２のFRタイマのカウント終了後、直ちに実行するようにしてもよい。同様に、リオーダタイマのリセット（ステップＳ１３の処理）は、ステップＳ９乃至Ｓ１２の処理が終了した後に実行するようにしたが、ステップＳ５のリオーダタイマのカウント終了後、直ちに実行するようにしてもよい。

次に、図９のフローチャートを参照して、サーバ１２のNACK処理部７５のNACK処理について説明する。

初めに、ステップＳ３１において、NACK処理部７５は、受信部８２で受信されたNACKパケットが供給されたか否かを判定し、NACKパケットが供給されたと判定されるまで、同様の処理が繰り返される。

一方、ステップＳ３１で、NACKパケットが供給されたと判定された場合、ステップＳ３２に進み、NACK処理部７５は、NACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されているシーケンス番号と一致するか否かを判定する。

ステップＳ３２において、NACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されているシーケンス番号と一致すると判定された場合、即ち、NACKパケットにより、クライアント１４から再送要求が出されたRTPパケットは、サーバ１２が故意にリオーダさせたRTPパケットである場合、ステップＳ３３に進み、NACK処理部７５は、NACKパケットに格納されているシーケンス番号をRTT計算部７６に供給して、ステップＳ３１に戻り、以下、同様の処理が繰り返される。

一方、ステップＳ３２において、NACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されているシーケンス番号と一致しないと判定された場合、即ち、クライアント１４から再送要求が出されたRTPパケットが、実際に発生したパケットロスによるものである場合、ステップＳ３４に進み、NACK処理部７５は、NACKパケットに格納されているシーケンス番号と同一のシーケンス番号を有するRTPパケット（再送RTPパケット）を、再送用バッファ７３から抽出（取得）して、ステップＳ３５に進む。

ステップＳ３５において、NACK処理部７５は、ステップＳ３４で再送用バッファ７３から抽出した再送RTPパケットを送信部８１に供給して、ステップＳ３１に戻り、以下、同様の処理が繰り返される。なお、ステップＳ３５において送信部８１に供給された再送RTPパケットは、送信部８１により、通信網１３を介して、クライアント１４に送信される。

次に、図１０のフローチャートを参照して、RTT計算処理部７６のRTT計算処理について説明する。

初めに、ステップＳ５１において、RTT計算処理部７６は、NACK処理部７５からシーケンス番号が供給されたか否かを判定する。ステップＳ５１でNACK処理部７５から供給されるシーケンス番号は、上述した図９のステップＳ３３においてNACK処理部７５がRTT計算処理部７６に供給するシーケンス番号であり、サーバ１２が故意にリオーダさせたRTPパケットのシーケンス番号である。

ステップＳ５１では、NACK処理部７５からシーケンス番号が供給されるまで、同様の処理が繰り返され、NACK処理部７５からシーケンス番号が供給されたと判定された場合、ステップＳ５２に進み、RTT計算部７６は、NACK処理部７５からシーケンス番号が供給されたときの現在時刻（NACKパケットの受信時刻）を取得する。また、ステップＳ５２において、RTT計算部７６は、NACK処理部７５から供給されるシーケンス番号と同一のシーケンス番号を有するリオーダRTPパケットの、シーケンス番号と送信時刻とのセットをリオーダ履歴保持部７４から取得して、ステップＳ５３に進む。

ステップＳ５３において、RTT計算部７６は、NACK処理部７５からシーケンス番号が供給されたときの現在時刻（NACKパケットの受信時刻）と、リオーダ履歴保持部７４から取得した送信時刻とから、RTT（=現在時刻−送信時刻）を計算して、ステップＳ５１に戻り、以下、同様の処理が繰り返される。

次に、図１１のフローチャートを参照して、クライアント１４のNACK処理部１０４のNACK処理について説明する。

初めに、ステップＳ７１において、NACK処理部１０４は、RTP処理部１０２から供給されるRTPパケットのシーケンス番号に基づいて、パケットロスが発生したか否かを判定し、パケットロスが発生したと判定されるまで、同様の処理が繰り返される。

一方、ステップＳ７１において、パケットロスが発生したと判定された場合、ステップＳ７２に進み、NACK処理部１０４は、パケットロスが発生したRTPパケットのシーケンス番号を格納したNACKパケットを送信部１１２に供給して、ステップＳ７１に戻り、以下、同様の処理が繰り返される。ステップＳ７２において、NACK処理部１０４から送信部１１２に供給されたNACKパケットは、送信部１１２からサーバ１２（の受信部８２）に送信される。

以上のように、図１のストリーミング配信システムによれば、サーバ１２のRTP生成部７２は、ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された複数のRTPパケットを生成する。また、RTP生成部７２は、所定の時間（上述のリオーダタイマの設定時間）ごとに、生成した複数のRTPパケットのうちの１つのRTPパケットを、再生される順番と異なる順番にリオーダする。送信部８１は、RTP生成部７２から供給された、リオーダされたRTPパケット（リオーダRTPパケット）を含む複数のRTPパケットをクライアント１４に送信する。

また、サーバ１２のリオーダ履歴保持部７４は、リオーダRTPパケットがリオーダされずに本来の再生される順番でクライアント１４に送信されたとした場合のリオーダRTPパケットの送信時刻と、そのリオーダRTPパケットのシーケンス番号とを記憶する。

そして、サーバ１２の受信部８２が、クライアント１４から送信されてくる、RTPパケットの再送を要求するNACKパケット（再送要求パケット）を受信し、NACK処理部７５に供給する。NACK処理部７５は、受信部８２から供給されたNACKパケットに格納されているシーケンス番号が、リオーダ履歴保持部７４に記憶されているリオーダRTPパケットのシーケンス番号と一致するか否かを判定し、NACKパケットが表すシーケンス番号と、リオーダ履歴保持部７４に記憶されているリオーダRTPパケットのシーケンス番号とが一致する場合に、RTT計算部７６にシーケンス番号を供給する。RTT計算部７６は、現在時刻と、リオーダRTPパケットの送信時刻とから、RTT(Round Trip Time)を計算する。

また、図１のストリーミング配信システムによれば、クライアント１４の受信部１１１は、サーバ１２の送信部８１から送信されてくる複数のRTPパケットを受信し、RTP処理部１０２に供給する。RTP処理部１０２は、受信部１１１から供給された複数のRTPパケットのシーケンス番号をNACK処理部１０４に供給する。NACK処理部１０４は、シーケンス番号がリオーダされている（再生される順番と異なる順番である）場合に、そのリオーダされているRTPパケット（本来の再生される順番となるために必要なRTPパケット）のNACKパケットを送信部１１２に供給する。送信部１１２は、NACK処理部１０４から供給されたNACKパケットをサーバ１２に送信する。

これにより、サーバ１２は、RTTを計算するための特別のRTT計算用RTPパケットをクライアント１４に送信せずに、RTTを計算することが可能となる。即ち、通信網１３（ネットワーク）への負担を少なくして、RTTを計算することができる。また、サーバ１４がRTT計算用RTPパケットを送信してこないので、クライアント１４にRTT計算用の特別の処理部を設ける必要がなく、クライアント１４を単純な構成とすることができるとともに、プログラム等の変更も必要としない。

さらに、サーバ１２は、リオーダタイマの設定時間を任意の値に変更することにより、所望のタイミングでRTTを計算することができる。

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

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

本発明を適用したストリーミング配信システムの一実施の形態の構成例を示すブロック図である。 図１のサーバ１２のハードウエアの構成例を示すブロック図である。 図１のサーバ１２の機能的な構成例を示すブロック図である。 図１のクライアント１４の機能的な構成例を示すブロック図である。 サーバ１２がRTTを計算する処理の概念を説明する図である。 RTPパケットのフォーマットを説明する図である。 NACKパケットのフォーマットを説明する図である。 サーバ１２の送信処理を説明するフローチャートである。 NACK処理部７５のNACK処理を説明するフローチャートである。 RTT計算処理部７６のRTT計算処理を説明するフローチャートである。 クライアント１４のNACK処理部１０４のNACK処理を説明するフローチャートである。

符号の説明

１２ サーバ， １４ クライアント， ７２ RTP生成部， ７４ リオーダ履歴保持部， ７５ NACK処理部， ７６ RTT計算部， ７７ 通信部， ８１ 送信部， ８２ 受信部， １０１ 通信部， １１１ 受信部， １１２ 送信部

Claims (5)

1. ストリーミングデータを格納した複数のパケットの送信処理を行う送信装置において、
   前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段と、
   前記パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを他の装置に送信する送信手段と、
   前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記他の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶する記憶手段と、
   前記他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信手段と、
   前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定手段と、
   前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段と
   を備えることを特徴とする送信装置。
2. 前記パケット生成手段は、所定の時間ごとに、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダする
   ことを特徴とする請求項１に記載の送信装置。
3. ストリーミングデータを格納した複数のパケットの送信方法において、
   前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成ステップと、
   前記パケット生成ステップにおいてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを他の装置に送信する送信ステップと、
   前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記他の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶手段に記憶させる記憶ステップと、
   前記他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信ステップと、
   前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定ステップと、
   前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算ステップと
   を含むことを特徴とする送信方法。
4. ストリーミングデータを格納した複数のパケットの送信処理を、コンピュータに実行させるプログラムにおいて、
   前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成ステップと、
   前記パケット生成ステップにおいてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを他の装置に送信する送信ステップと、
   前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記他の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶手段に記憶させる記憶ステップと、
   前記他の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する受信ステップと、
   前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定ステップと、
   前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算ステップと
   を含むことを特徴とするプログラム。
5. ストリーミングデータを格納した複数のパケットを送受信する第１および第２の装置からなる送受信システムにおいて、
   前記第１の装置は、
   前記ストリーミングデータとして再生される順番を表すシーケンス番号がそれぞれに格納された前記複数のパケットを生成し、前記複数のパケットのうちの１つのパケットを、再生される順番と異なる順番にリオーダするパケット生成手段と、
   前記パケット生成手段においてリオーダされたパケットであるリオーダパケットを含む前記複数のパケットを前記第２の装置に送信する第１の送信手段と、
   前記リオーダパケットがリオーダされずに本来の前記再生される順番で前記第２の装置に送信されたとした場合の前記リオーダパケットの送信時刻と、前記リオーダパケットの前記シーケンス番号とを記憶する記憶手段と、
   前記第２の装置から送信されてくる、パケットの再送を要求する再送要求パケットを受信する第１の受信手段と、
   前記再送要求パケットに格納されているシーケンス番号が、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号と一致するか否かを判定する判定手段と、
   前記再送要求パケットに格納されているシーケンス番号と、前記記憶手段に記憶されている前記リオーダパケットの前記シーケンス番号とが一致する場合に、現在時刻と前記送信時刻とから、RTT(Round Trip Time)を計算するRTT計算手段と
   を備え、
   前記第２の装置は、
   前記第１の装置から送信されてくる前記複数のパケットを受信する第２の受信手段と、
   前記第２の受信手段により受信された前記複数のパケットの前記シーケンス番号が再生される順番と異なる順番である場合に、本来の前記再生される順番となるために必要なパケットの前記再送要求パケットを送信する第２の送信手段と
   を備える
   ことを特徴とする送受信システム。

Images