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

Abstract

【課題】 遅延のないネットワークの状況に応じたRTPパケットの配信をする。
【解決手段】 ロス率計算部３６は、パケットカウンタ３５のパケットカウントを読み出し、今現在のパケットカウントから直前N個のパケットカウントに対応するエントリ保持部３８ａに保持されているNACK受信回数を読み出し、ロス率を計算する。RTT計算部３９は、RTT計測パケットをクライアントPCに送信し、返信されてくるRTT返信計測パケットからRTTを計算する。送信レート計算部４１は、ロス率計算部３６により計算されたロス率とRTT計算部３９により計算されたRTTに基づいて、送信レートを計算し、送信レート保持部３７に保持させる。エンコーダ３１は、送信レート保持部３７に保持された送信レートでエンコードする。本発明は、ストリームデータ配信システムに適用することができる。
【選択図】 図２

Description

本発明は、送信装置および方法、記録媒体、並びにプログラムに関し、特に、送信する側でロス率とRTT（Round Trip Time：往復伝播遅延時間）を計算し、計算されたロス率とRTTに基づいて、送信レートを変化させることにより、ネットワークの状態に対応してストリームデータを送信できるようにした送信装置および方法、記録媒体、並びにプログラムに関する。

インターネットなどを介してサーバから動画像のストリームデータを配信する技術が一般に普及しつつある。

このようにインターネットなどの回線を使用して動画像のストリームデータを送信する際、パケット単位でデータが送受信されることになるが、このような通信においては、送信装置が送信したパケットが受信装置で正しく受信することができない、いわゆる、パケットロス（以下、単にロスとも称する）が生じることがある。

これは、ネットワークの輻輳によるもので、これを緩和する方法として、いろいろな方法が考えられている。

例えば、受信装置が定期的にRTCP（RTP（Real-time Transport Protocol） Control Protocol）の受信者レポートを送信装置に送信することで、送信装置はネットワークのロス率を知ることができる。そこで、この受信者レポートに基づき、例えば、パケットロスが生じたのであれば、送信装置が、送信レートを下げるなどして、ネットワークの輻輳状態を緩和させるようにすることが提案されている（例えば、特許文献１参照）。
特開２００１−３２０４４０号公報

しかしながら、上述の手法を用いると、受信装置から送信されてくるネットワークのロスに関するデータは、送信装置において一定間隔でしか取得することがないため、ネットワークの状況を送信装置が知るまでに遅延が生じ、送信レートの制御が遅れてしまう恐れがある。結果として、送信レートの制御が遅れると、現在のネットワークの状態に対応していない送信レートで、パケットデータが送信されてしまうことになるため、現在利用可能な帯域を十分に使えない状態となったり、或いは、利用可能帯域を越えてしまうため、輻輳状態を悪化させてしまう恐れがあった。

本発明はこのような状況に鑑みてなされたものであり、送信する側でロス率とRTT（Round Trip Time：往復伝播遅延時間）を計算し、計算されたロス率とRTTに基づいて、送信レートを変化させることにより、ネットワークの状態に対応してストリームデータを送信できるようにするものである。

本発明の送信装置は、ストリームデータを所定の送信レートで受信装置に送信する送信手段と、受信装置からの、ストリームデータの再送要求を受信する受信手段と、受信手段により受信された再送要求に基づいて、ロス率を計算するロス率計算手段と、ロス率計算手段により計算されたロス率に基づいて、送信レートを変更する変更手段とを備えることを特徴とする。

往復伝播遅延時間を計算する往復伝播遅延時間計算手段をさらに設けるようにさせることができ、ロス率計算手段には、再送要求と、往復伝播遅延時間に基づいて、ロス率を計算させるようにすることができる。

前記ロス率計算手段には、往復伝播遅延時間に基づいた間隔で、ロス率を計算させ、更新させるようにすることができる。

往復伝播遅延時間を計算する往復伝播遅延時間計算手段をさらに設けるようにさせることができ、前記変更手段には、ロス率計算手段により計算されたロス率と、往復伝播遅延時間計算手段により計算された往復伝播遅延時間に基づいて、送信レートを変更させるようにすることができる。

本発明の送信方法は、ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、受信装置からの、ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、ロス率計算ステップの処理で計算されたロス率に基づいて、送信レートを変更する変更ステップとを含むことを特徴とする。

本発明の記録媒体のプログラムは、ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、受信装置からの、ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、ロス率計算ステップの処理で計算されたロス率に基づいて、送信レートを変更する変更ステップとを含むことを特徴とする。

本発明のプログラムは、ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、受信装置からの、ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、ロス率計算ステップの処理で計算されたロス率に基づいて、送信レートを変更する変更ステップとをコンピュータに実行させることを特徴とする。

本発明の送信装置および方法、並びにプログラムにおいては、ストリームデータが所定の送信レートで受信装置に送信され、受信装置からの、ストリームデータの再送要求が受信され、受信された再送要求に基づいて、ロス率が計算され、計算されたロス率に基づいて、送信レートが変更される。

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

本発明によれば、遅延のないネットワークの状況に応じたRTPパケットの配信をすることが可能となる。

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

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

即ち、本発明の送信装置は、ストリームデータを所定の送信レートで受信装置に送信する送信手段（例えば、図２の通信部３４）と、受信装置からの、ストリームデータの再送要求を受信する受信手段（例えば、図２の通信部３４）と、受信手段により受信された再送要求に基づいて、ロス率を計算するロス率計算手段（例えば、図２のロス率計算部３６）と、ロス率計算手段により計算されたロス率に基づいて、送信レートを変更する変更手段（例えば、図２の送信レート計算部３１）とを備えることを特徴とする。

また、本発明の送信方法は、ストリームデータを所定の送信レートで受信装置に送信する送信ステップ（例えば、図４のステップＳ６の処理）と、受信装置からの、ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップ（例えば、図１４のステップＳ１１９の処理）と、ロス率計算ステップの処理で計算されたロス率に基づいて、送信レートを変更する変更ステップ（例えば、図４のステップＳ９の処理）とを含むことを特徴とする。

図１は、本発明を適用したストリームデータ配信システムの一実施の形態の構成を示す図である。

カメラ１１は、CCD（Charge Coupled Devoce）などの撮像素子を用いた、いわゆるビデオカメラであり、撮像した画像データを配信サーバ１２に出力する。

配信サーバ１２は、カメラ１１より供給された画像データを所定の方式でエンコードし（圧縮し）、通信可能なパケット単位の情報に変換し、インターネット１３を介して、クライアントPC（Personal Computer）１４にストリームデータとして配信する。

クライアントPC１４は、インターネット１３を介して配信サーバ１２から配信されるストリームデータを受信し、所定の伸張処理を行ったのち、元の画像データを再生し、LCD（Liquid Crystal Display）やCRT（Cathode Ray Tube）などからなる表示部１５に出力して、表示させる。尚、図１の例においては、配信サーバ１２、および、クライアントPC１４が、インターネット１３を介して、それぞれ1台ずつ設けられている場合について示されているが、実際には、配信サーバ１２は、複数のクライアントPC１４に対してストリームデータを配信するので、実際には、クライアントPC１４は、インターネット１３を介して複数台数接続されている。また、同様にして、配信サーバ１２についても、複数の接続されていてもよい。

次に、図２を参照して、図１の配信サーバ１２の構成について説明する。

エンコーダ３１は、カメラ１１より供給される画像データを、送信レート保持部３７に保持されている送信レートで所定の形式（例えば、MPEG２（Moving Picture Experts Group）、MPEG４、または、Motion JPEG（Joint Photographic Experts Group）など）でエンコードし（圧縮し）、パケタイザ３２に出力する。

パケタイザ３２は、エンコーダ３１より供給されたエンコードされている画像データを、RTPパケットに変換し、バッファ３３、および、通信部３４に出力する。バッファ３３は、パケタイザ３２によりRTPパケットに変換された画像データを一時的に記憶し、NACK（Negative Acknowledge）処理部３８からの指示により、パケットロスが発生し、再送が指示されると、再送が指定されたRTPパケットを読み出し、通信部３４に出力する。

通信部３４は、いわゆる通信モデムのようなものであり、パケタイザ３２、または、バッファ３３より供給されたRTPパケットを、インターネット１３を介してクライアントPC１４に配信する。また、通信部３４は、１RTPパケットを送信するごとに、パケットカウンタ３５を１インクリメントさせ、パケットカウンタ３５に送信したRTPパケット数をカウントさせる。さらに、通信部３４は、クライアントPC１４より送信されてくるNACKを受信した場合、NACK処理部３８にNACKを供給する。また、通信部３４は、RTT計算部３９より作成されたRTT計測パケットをインターネット１３を介してクライアントPC１４に送信すると共に、このRTT計測パケットの応答である、RTT計測返信パケットがクライアントPC１４より送信されてくると、これを受信し、RTT計算部３９に供給する。

ロス率計算部３６は、パケットカウンタ３５に記憶されているパケットカウントと、NACK処理部３８のエントリ保持部３８ａに記憶されているエントリ情報（NACKの数：パケットロスの数）を読み出し、これらの情報に基づいてロス率を計算し、送信レート計算部４１に出力する。

NACK処理部３８は、通信部３４を介して、クライアントPC１４より、NACKが送信されているか否かを監視し、NACKが送信されてきた場合、その情報をエントリ保持部３８ａに記憶させると共に、NACKに含まれている再送要求に基づいて、バッファ３３に記憶されているRTPパケットのうち、再送が要求されているRTPパケットを読み出させ、通信部３４に出力させ、送信させる。このとき、NACK処理部３８は、再送するRTPパケットが通信部３４から送信できるように、パケタイザ３２を制御する。

RTT計算部３９は、RTT計測用フォーマットを作成し、作成時の時刻情報をRTC（Real Time Clock）４０より読み出して書き込み、通信部３４に転送して、クライアントPC１４に送信する。また、RTT計算部３９は、クライアントPC１４からのRTT計測用フォーマットの返信を取得し、その時刻に基づいて、RTT（往復伝播遅延時間）を計算し、計算結果を送信レート計算部４１に出力する。

送信レート計算部４１は、ロス率計算部３６より供給されるロス率の情報と、RTT計算部３９より供給されるRTTの情報に基づいて、送信レートを計算し、計算結果に基づいて、送信レート保持部３７に記憶されている送信レートを更新する。尚、送信レート保持部３７に保持されている送信レートは、デフォルトの値が設定されており、送信レート計算部４１により更新処理がなされなければ、そのデフォルトで設定された送信レートが読み出される。

次に、図３を参照して、クライアントPC１４の構成について説明する。

通信部５１は、図２を参照して説明した配信サーバ１２と同様のものであり、通信モデムなどから構成されており、インターネット１３を介して配信サーバ１２との間で、データの授受を行う。通信部５１は、RTPパケットがクライアントPC１２から送信されてくるとバッファ５２に出力する。通信部５１は、RTT計測フォーマットの情報が送信されてくると、RTT計測パケットの情報をRTT処理部５５に出力する。また、通信部５１は、RTT処理部５５よりRTT計測返信パケットの情報が入力されると、このRTT計測返信パケットの情報をインターネット１３を介して配信サーバ１２に送信する。

バッファ５２は、通信部５１より供給されたRTPパケットを一時的に記憶し、所定のデータ量になったとき、デコーダ５３に出力する。デコーダ５３は、バッファ５２より供給されたRTPパケットを所定の方式でデコードし（伸張処理し）、これをLCDやCRTからなる表示部１５に出力して、表示させる。

NACK処理部５４は、通信部５１で受信されるRTPパケットのシーケンス番号を確認し、連番でRTPパケットが受信されているか否かを確認し、シーケンス番号が連番ではなく、番号が抜けているような場合、パケットロスが発生したものと判定し、パケットロスが生じたRTPパケットの再送を要求するNACKを生成して、通信部５１を制御して、配信サーバ１２に送信する。

RTT処理部５５は、配信サーバ１２より送信されてくるRTT計測パケットを受信すると、受信したRTT計測パケットのタイムスタンプの情報に基づいて、返信用のRTT計測返信パケットを生成し、通信部５１を介して配信サーバ１２に返信する。

次に、図４のフローチャートを参照して、サーバ１２によるストリームデータの配信処理について説明する。

ステップＳ１において、エンコーダ３１は、エンコードする時刻となったか否かを判定する。ここでいうエンコードする時刻とは、例えば、30fps（Frame per Sec）でエンコードする場合、33ms毎の時刻のことである。すなわち、例えば、エンコーダ３１は、カメラ１１が撮像している画像をエンコードする時刻となったか否かを判定し、エンコードすべき時刻になっていると判定されるまで、同様の処理を繰り返す。例えば、エンコードすべき時刻であると判定された場合、その処理は、ステップＳ２に進む。

ステップＳ２において、エンコーダ３１は、カメラ１１より供給される画像データをキャプチャする。すなわち、エンコーダ３１は、カメラ１１より供給される画像データを取得して、蓄える。

ステップＳ３において、エンコーダ３１は、送信レート保持部３７に保持されている送信レートで、ステップＳ２の処理でキャプチャした画像データをエンコードし、パケタイザ３２に出力する。

ステップＳ４において、パケタイザ３２は、エンコーダ３１より供給されたエンコードされている画像データに基づいて、RTPパケットを作成する。

ステップＳ５において、パケタイザ３２は、作成したRTPパケットをバッファ３３に出力し、記憶させる。さらに、ステップＳ６において、パケタイザ３２は、作成したRTPパケットを通信部３４に出力して、ネットワーク１３を介してクライアントPC１４に向けて配信させる。

パケタイザ３２は、エンコーダ３１より供給されるエンコードされている画像データに基づいて、図５で示されるようなRTPパケットを作成する。

すなわち、パケタイザ３２は、エンコードされているデータ（ペイロードデータ）に対して、RTPヘッダを付加しパケット化する。RTPヘッダには、バージョン番号（ｖ）（２ビット）、パディング（Ｐ）（１ビット）、拡張ヘッダ（Ｘ）（１ビット）の有無、送信元数（Counter）（ＣＣ）（４ビット）、マーカ情報（marker bit）（Ｍ）（１ビット）、ペイロードタイプ（Payload Type）（７ビット）、シーケンス番号（１６ビット）、タイムスタンプ（３２ビット）、同期ソース（送信元）識別子（SS（Synchronization Source）RC）（３２ビット）、および、貢献ソース（送信元）識別子（CS（Contributing Source）RC）（３２ビット）の各フィールドが設けられている。

クライアントPC１４は、RTPヘッダに付与されたタイムスタンプによりRTPパケットの展開時に処理時間を制御し、リアルタイム画像、または音声を再生する。なお、例えば動画像データの符号化データを格納したRTPパケットにおいては、１つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがRTPヘッダに格納される。

ステップＳ７において、通信部３４は、RTPパケットを送信すると共に、パケットカウンタ３５を１インクリメントする。

ステップＳ８において、送信レート計算部４１は、送信レートの変更時刻になったか否かを判定する。送信レートの変更時刻は、後述するステップＳ１１の処理で決定された時刻であるが、最初の処理においては、エンコード開始時点から所定の時刻がデフォルトとして設定されている。ステップＳ８において、送信レートの変更時刻になったと判定された場合、その処理は、ステップＳ９に進む。

ステップＳ９において、送信レート計算部４１は、ロス率計算部３６で計算されたロス率と、RTT計算部３９で計算されたRTTに基づいて、送信レートを計算する。より詳細には、送信レート計算部４１は、以下の式（１）を演算することにより、送信レートを計算する。

・・・（１）

ここで、RTTは、往復伝播遅延時間を、ｐは、ロス率を、Tは、送信レートをそれぞれ示している。

尚、式（１）は、IETF（The Internet Engineering Task Force）のrfc（Request for Comments）3448におけるTCP Friendly Rate Control (TFRC): Protocol Specificationに記載に基づいたものである。TCP（Transmission Control Protocol）とUDP（User Datagram Protocol）がネットワーク上で同じリンクを使用すると、UDPがTCPに干渉する傾向がある。そこで、式（１）で示される計算式により、UDPの転送レートをTCPと同一にすることで、干渉を抑制し、ネットワーク資源を有効に利用できるようにしている。

また、ロス率とRTTの計算については、後述する。

ステップＳ１０において、送信レート計算部４１は、計算した送信レートを送信レート保持部３７に保持させる。

ステップＳ１１において、送信レート計算部４１は、RTT計算部３９が保持しているRTTを現在時刻に加算し、これを次の送信レートの変更時刻に決定する。尚、次の送信レートの変更時刻は、上述した方法以外で決定してもよく、例えば、現在時刻を次の送信レートの変更時刻として設定することで、パケットを送信する度に送信レートを変更させるようにしてもよい。

ステップＳ１２において、エンコーダ３１は、次のエンコード時刻を決定し、その処理は、ステップＳ１に戻る。より詳細には、エンコーダ３１は、上述したように、例えば、30fps（Frame per Sec）でエンコードする場合、次のエンコード時刻を、現在時刻の33ms後の時刻に決定する。

ステップＳ８において、送信レートの変更時刻ではないと判定された場合、ステップＳ９乃至Ｓ１１の処理がスキップされて、その処理は、ステップＳ１２に進む。すなわち、送信レートの変更時刻ではない場合、送信レートの変更処理がなされない。

以上の処理により、ストリームデータを送信する側である配信サーバ１２は、自らで計算したロス率に基づいて送信レートを変更させることが可能となるので、従来のように、ロス率が受信する側であるクライアントPCから送信されてくるの待つことで送信レートの変更に遅延が生じることなく、ロス率の変化をリアルタイムで反映させた送信レートの変更が可能となる。

次に、図６のフローチャートを参照して、クライアントPC１４による受信処理を説明する。

ステップＳ３１において、通信部５１は、インターネット１３を介して配信サーバ１２から送信されてきたRTPパケットを受信したか否かを判定し、RTPパケットが受信されるまでその処理を繰り返す。例えば、図４のフローチャートを参照して説明した処理により、配信サーバ１２がストリームデータを配信している場合、ステップＳ３１において、通信部５１は、配信サーバ１２から送信されてきたRTPパケットを受信するので、RTPパケットが受信されたと判定し、その処理は、ステップＳ３２に進む。

ステップＳ３２において、NACK処理部５４は、RTPパケットに含まれているシーケンス番号を読み出す。すなわち、NACK処理部５４は、図５を参照して説明したRTPパケットのフォーマットに含まれている１６ビットのシーケンス番号の情報を読み出す。

ステップＳ３３において、NACK処理部５４は、読み出したRTPパケットに、パケットロスがあるか否かを判定する。より詳細には、NACK処理部５４は、シーケンス番号が連番で受信できているか否かを監視し、連番ではなく、シーケンス番号が欠落しているとき、パケットロスが発生したと判定する。

ステップＳ３３において、パケットロスが発生していると判定された場合、ステップＳ３４において、NACK処理部５４は、ロスパケットについてのNACKを作成し、通信部５１に出力して、配信サーバ１２に送信させ、その処理は、ステップＳ３１に戻る。

より詳細には、上述したようにNACK処理部５４は、シーケンス番号が欠落しているRTPパケットについて、図７で示されるようなフォーマットのNACKを作成し、欠落したシーケンス番号のRTPパケットの再送を要求する。図７のNACKのフォーマットにおいては、バージョン番号（ｖ）（２ビット）、パディング（Ｐ）（１ビット）、サブタイプ（sub）（５ビット）、パケットタイプ（PT）（８ビット）、メッセージ長（Message Length）（１６ビット）、同期ソース（送信元）識別子（SS（Synchronization Source）RC）（３２ビット）、アプリケーションプログラムの名称（NAME）（３２ビット）、および、要求シーケンス番号（要求seq番号）の各フィールドが設けられている。

一方、ステップＳ３３において、パケットロスがないと判定された場合、ステップＳ３５に進み、通信部５１は、受信したRTPパケットをバッファ５２に適宜記憶させながら、デコーダ５３に出力し、これに応じて、デコーダ５３は、RTPパケットをデコードし、表示部１５に表示させる。

すなわち、NACK処理部５４は、パケットロスが発生した場合に、NACKを生成して、通信の途中で欠落したRTPパケットの再送を要求する。

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

ステップＳ５１において、配信サーバ１２のNACK処理部３８は、通信部３４に問い合わせてNACKが受信されたか否かを判定し、NACKが受信されたと判定されるまで、その処理を繰り返す。例えば、図６のフローチャートを参照して説明したクライアントPC１４の処理により、パケットロスが検出されて、NACKが送信されると、この処理により、ステップＳ５１において、NACKが受信されたと判定され、その処理は、ステップＳ５２に進む。

ステップＳ５２において、NACK処理部３８は、受信されたNACKを読み出し、再送要求されているシーケンス番号を確認して、対応するシーケンス番号のRTPパケットをバッファ３３より通信部３４に供給して、インターネット１２を介してクライアントPC１４に送信させる。尚、この際、NACK処理部３８は、パケタイザ３２を制御して、再送分のRTPパケットが送信される間、RTPパケットの処理を遅延させるなどして、タイミングを調整する。

ステップＳ５３において、NACK処理部３８は、パケットカウンタ３５に問い合わせて、現在のパケットカウントを読み出し、エントリ保持部３８ａに記憶させる。より詳細には、NACK処理部３８は、図９で示されるように、NACKの受信回数毎に付されるエントリに対応して、RTPパケットを再送したときのパケットカウントを記憶する。図９においては、エントリが１のときパケットカウントが８、エントリが２，３のときパケットカウントは何れも１４となっている。すなわち、図９で示されるエントリの情報では、エントリが１であるRTPパケットは、パケットカウントが８のときに再送され、エントリが２，３であるRTPパケットは、パケットカウントが１４のときに再送されていることが示されている。

ステップＳ５４において、NACK処理部３８は、パケットカウンタ３５を制御して、パケットカウントを１インクリメントし、その処理は、ステップＳ５１に戻り、それ以降の処理が繰り返される。

以上の処理により、クライアントPC１４から再送の要求があったシーケンス番号のRTPパケットが再送されることになるので、パケットロスによるRTPパケットの欠落を保証することが可能となる。

次に、図１０のフローチャートを参照して、配信サーバ１２によるRTTの計測処理について説明する。

ステップＳ７１において、RTT計算部３９は、RTT計測パケットを出力する時刻になったか否かを判定する。このRTT計測パケットを出力する時刻は、ステップＳ７６の処理で決定される時刻であるが、最初の処理では、処理の開始時刻から所定の時間が経過した時刻であるようにデフォルトの時刻が設定されている。

ステップＳ７１において、RTT計測パケットを出力する時刻ではないと判定された場合、その処理は、ステップＳ７７に進む。

一方、ステップＳ７１において、RTT計測パケットを出力する時刻になったと判定された場合、ステップＳ７２において、RTT計算部３９は、RTC４０に問い合わせて、現在時刻を取得する。

ステップＳ７３において、RTT計算部３９は、図１１で示されるようにRTT計測パケットを作成する。すなわち、図１１で示されるように、RTT計測パケットには、バージョン番号（ｖ）（２ビット）、パディング（Ｐ）（１ビット）、サブタイプ（sub）（５ビット）、パケットタイプ（PT）（８ビット）、メッセージ長（Message Length）（１６ビット）、同期ソース（送信元）識別子（SS（Synchronization Source）RC）（３２ビット）、アプリケーションプログラムの名称（NAME）（３２ビット）、および、送信時刻の各フィールドが設けられている。ここで、RTT計算部３９は、送信時刻のフィールドに、ステップＳ７２の処理で取得した現在時刻の情報を書き込む。

ステップＳ７４において、RTT計算部３９は、生成したRTT計算パケットを通信部３４に出力する。ステップＳ７５において、通信部３４は、インターネット１３を介してクライアントPC１４にRTT計測パケットを送信する。

ステップＳ７６において、RTT計算部３９は、次の出力時刻を決定し、その処理は、ステップＳ７１に戻る。すなわち、例えば、所定の間隔でRTTを計算するような場合、RTT計算部３９は、現在時刻に、所定の間隔となる時間を加算した時刻を次の出力時刻として決定する。この所定の時間は、例えば、後述する保持されているRTTなどでもよい。

ここで、図１２のフローチャートを参照して、クライアントPCによるRTT計測処理について説明する。

ステップＳ９１において、RTT処理部５５は、通信部５１に問い合わせて、RTT計測パケットが受信されたか否かを判定し、RTT計測パケットが受信されたと判定されるまでその処理を繰り返す。例えば、図１０のフローチャートのステップＳ７５の処理により、RTT計測パケットが送信されてくると、ステップＳ９１において、RTT計測パケットが受信されたと判定された場合、その処理は、ステップＳ９２に進む。

ステップＳ９２において、RTT処理部５５は、図１３で示されるようなRTT計測返信パケットを作成する。

すなわち、図１３で示されるように、RTT計測返信パケットには、バージョン番号（ｖ）（２ビット）、パディング（Ｐ）（１ビット）、サブタイプ（sub）（５ビット）、パケットタイプ（PT）（８ビット）、メッセージ長（Message Length）（１６ビット）、同期ソース（送信元）識別子（SS（Synchronization Source）RC）（３２ビット）、アプリケーションプログラムの名称（NAME）（３２ビット）、および、Dataの各フィールドが設けられている。ここで、RTT処理部５５は、Dataのフィールドに、ステップＳ９１の処理で受信した、RTT計測パケットに記録されている現在時刻の情報を書き込む。

ステップＳ９３において、RTT処理部５５は、作成したRTT計測返信パケットを通信部５１に出力する。ステップＳ９４において、通信部５１は、RTT計測返信パケットを、インターネット１３を介して配信サーバ１２に送信し、その処理は、ステップＳ９１に戻る。

すなわち、クライアントPC１４は、RTT計測パケットを受信すると、そこに記録されている現在時刻（配信サーバ１２がRTT計測パケットを送信した時刻）をRTT計測返信パケットに書き込み配信サーバ１２に送り返す。

ここで、図１０のフローチャートの説明に戻る。

ステップＳ７７において、RTT計算部３９は、通信部３４に問い合わせて、RTT計測返信パケットを受信したか否かを判定する。例えば、上述した図１２のフローチャートのステップＳ９４の処理により、クライアントPC１４からRTT計測返信パケットが送信されてくると、通信部３４は、このRTT計測返信パケットを受信することになるので、RTT計測返信パケットが受信されたと判定され、その処理は、ステップＳ７８に進む。

ステップＳ７８において、RTT計算部３９は、RTC４０に問い合わせて現在時刻を取得する。

ステップＳ７９において、RTT計算部３９は、受信したRTT計測返信パケットに記述されている現在時刻（ステップＳ７２の処理で、RTT計算部３９が、RTT計測パケットを送信した時刻）と、ステップＳ７９の処理で取得した現在時刻との差分を求め、これをRTTとして保持し、その処理は、ステップＳ７１に戻る。すなわち、例えば、RTT計測返信パケットに記載されていた時刻が、１２：００：００であり、現在時刻が１２：００：０１であった場合、この時刻差である１秒がRTTとして計算され、保持されることになる。

ステップＳ７７において、RTT計測返信パケットが受信されていないと判定された場合、その処理は、ステップＳ７１に戻り、それ以降の処理が繰り返される。

以上の処理により、配信サーバ１２は、クライアントPC１４とのRTT（往復伝播遅延時間）を繰り返し計測することができる。

次に、図１４のフローチャートを参照して、ロス率の計算処理について説明する。

ステップＳ１１１において、ロス率計算部３６は、パケットカウンタ３５のパケットカウントからRTPパケットの転送（RTPパケットのクライアントPC１４への送信）が行われているか否かを判定し、転送があったと判定されるまで、その処理を繰り返す。例えば、図４のフローチャートを参照して説明したように、RTPパケットが転送されていると判定された場合、その処理は、ステップＳ１１２に進む。

ステップＳ１１２において、ロス率計算部３６は、ロス率の更新時刻となったか否かを判定し、ロス率の更新時刻がくるまでその処理を繰り返す。尚、ロス率の更新時刻は、後述するステップＳ１２０の処理により、前回の処理で決定された更新時刻となるが、最初の処理においては、処理が開始されてから所定の時間経過後の時刻となるようにデフォルトの所定の時刻が設定されている。

ステップＳ１１２において、ロス率の更新時刻となったと判定された場合、ステップＳ１１３において、ロス率計算部３６は、パケットカウンタ３５で今現在記憶されている、今現在のパケットカウントを取得する。

ステップＳ１１４において、ロス率計算部３６は、NACK処理部３８のエントリ保持部３８ａに保持されている対象パケットカウントを取得する。すなわち、エントリ保持部３８ａに保持されているエントリに対応する対象パケットカウントは、例えば、図９の場合、エントリ１乃至３の８，１４，１４が、それぞれ対象パケットカウントとなるので、そのいずれかが取得される。

ステップＳ１１５において、ロス率計算部３６は、取得した対象パケットカウントが、今現在のパケットカウントＣと、今現在のパケットカウントからＮパケットを引いたパケットカウント（Ｃ−Ｎ）との間のパケットカウントであるか否かを判定する。

例えば、ステップＳ１１５において、取得した対象パケットカウントが、今現在のパケットカウントＣと、今現在のパケットカウントＣからＮパケットを引いたパケットカウント（Ｃ−Ｎ）との間のパケットカウントであると判定された場合、その処理は、ステップＳ１１６に進む。

ステップＳ１１６において、ロス率計算部３６は、図示せぬNACK受信数NAのカウンタを１インクリメントする。

ステップＳ１１７において、ロス率計算部３６は、エントリ保持部３８ａより取得した未処理の対象パケットカウントを検索する。例えば、図９の場合、最初の処理で、エントリ１のパケットカウント８が処理された場合、エントリ２のパケットカウント１４、または、エントリ３のパケットカウント１４は、未処理であるのでいずれかが検索されることになる。

ステップＳ１１８において、ロス率計算部３６は、未処理の対象パケットカウントが存在するか否かを判定し、例えば、まだ、未処理の対象パケットカウントが存在すると判定した場合、その処理は、ステップＳ１１４に戻る。すなわち、全ての対象パケットカウントが、今現在のパケットカウントＣと、今現在のパケットカウントＣからＮパケットを引いたパケットカウント（Ｃ−Ｎ）との間のパケットカウントであるか否かの判定処理に掛けられるまで、ステップＳ１１４乃至Ｓ１１８の処理が繰り返される。

ステップＳ１１８において、未処理の対象パケットカウントが処理されたと判定された場合、ステップＳ１１９において、ロス率計算部３６は、以下の式（２）を計算し、計算結果をロス率として更新する。

p＝NA／N
・・・（２）

ここで、ｐは、ロス率、NAは、NACK受信数、Nは、所定のパケット数である。

ステップＳ１２０において、ロス率計算部３６は、今現在の時刻にRTT計算部３９に保持されているRTTを加算し、求められた時刻を次のロス率の更新時刻に決定し、その処理は、ステップＳ１１１に戻る。

尚、ステップＳ１１５において、取得した対象パケットカウントが、今現在のパケットカウントＣと、今現在のパケットカウントＣからＮパケットを引いたパケットカウント（Ｃ−Ｎ）との間のパケットカウントではないと判定された場合、ステップＳ１１６の処理が、スキップされ、NACK受信数を示すカウンタNAがインクリメントされない。

すなわち、例えば、図１５で示されるようなRTPパケットの配信があるような場合について、以下のように処理される。尚、図１５においては、最上段の数値はパケットカウントを、上から２段めのマス目で囲まれた値は、配信サーバ１２が送信したRTPパケットのシーケンス番号を、下段のマス目で囲まれた値は、クライアントPC１４が受信したRTPパケットのシーケンス番号をそれぞれ示している。

したがって、図１５の場合、矢印ＳのタイミングでRTPパケットの送信が開始され、シーケンス番号が１のRTPパケットが配信サーバ１２から送信されるとき、矢印M1で示されるタイミングで、RTT計測パケットも送信される。このRTT計測パケットにより、矢印Ｍ２で示されるように、シーケンス番号１のRTPパケットを受信したタイミングで、クライアントPC１４は、RTT計測返信パケットを送信する。

また、クライアントPC１４は、図中の左から５番目のRTPパケットを受信しそこなった（パケットロスが生じた）場合（図中では、バツ印が入っている）、そのタイミングで、矢印Ｒ１で示されるように、NACKを配信サーバ１２に送信する。

これを受けて、配信サーバ１２は、パケットカウンタ９のタイミングで、矢印Ｒ１で送信されてきたNACKに対応する、クライアントPC１４が受信し損ねたシーケンス番号５のRTPパケットを再送する。また、このとき矢印Ｍ３で示されるように、配信サーバ１２は、RTT計測パケットも送信する。このRTT計測パケットにより、矢印Ｍ４で示されるように、シーケンス番号１のRTPパケットを受信したタイミングで、クライアントPC１４は、RTT計測返信パケットを送信する。

さらに、クライアントPC１４は、左からシーケンス番号１０，１１のRTPパケットのパケットロスを検出し、矢印Ｒ２，Ｒ３で示されるように、それぞれのパケットロスについてNACKを送信する。

これを受けて、配信サーバ１２は、パケットカウンタ１５のタイミングで、矢印Ｒ２，Ｒ３で送信されてきたNACKに対応する、クライアントPC１４が受信し損ねたシーケンス番号１０，１１のRTPパケットを再送する。また、このとき矢印Ｍ５で示されるように、配信サーバ１２は、RTT計測パケットも送信する。このRTT計測パケットにより、矢印Ｍ６で示されるように、シーケンス番号１のRTPパケットを受信したタイミングで、クライアントPC１４は、RTT計測返信パケットを送信する。

このような状況で、例えば、パケットカウントが１７である場合、ステップＳ１１４において、エントリ保持部３８ａより対象パケットカウントは、矢印Ｒ１乃至Ｒ３で示されるNACKを受信したときのパケットカウントである８，１４，１４となる（図９と同様）。

例えば、N＝１０である場合、ステップＳ１１５においては、対象パケットカウントが７乃至１７の範囲に存在するか否かが判定されることになる。今の場合、８，１４，１４の全てが７乃至１７の範囲であるので、ステップＳ１１４乃至Ｓ１１８の処理は、３回繰り返されて、全てにおいてステップＳ１１６の処理がなされるため、NACK受信数NAは、３となる。

結果として、ステップＳ１１９においては、式（２）が計算されることになり、ロス率は、３／１０となる。

尚、以上においては、ロス率に基づいて送信レートを変化させる例について説明してきたが、ロス率が所定の値以上であると判定された場合、FEC（Forword Error Correction）の冗長度を上げるようにしてもよい。

以上のような処理により、配信サーバ１２は、自らでクライアントPC１４のロス率を計算することができるので、クライアントPC１４からのロス率の報告を受けることなく、送信レートを最適な値に変化させながら、RTPパケットを送信させるようにすることができ、結果として、クライアントPC１４からのロス率の報告を待つことにより生じていた遅延がなくなり、ネットワークの状況に応じたRTPパケットの配信をすることが可能となる。

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

図１６は、図２の配信サーバ１２の電気的な内部構成をソフトウェアにより実現する場合のパーソナルコンピュータの一実施の形態の構成を示している。パーソナルコンピュータのCPU１０１は、パーソナルコンピュータの全体の動作を制御する。また、CPU１０１は、バス１０４および入出力インタフェース１０５を介してユーザからキーボードやマウスなどからなる入力部１０６から指令が入力されると、それに対応してROM(Read Only Memory) １０２に格納されているプログラムを実行する。あるいはまた、CPU１０１は、ドライブ１１０に接続された磁気ディスク１２１、光ディスク１２２、光磁気ディスク１２３、または半導体メモリ１２４から読み出され、記憶部１０８にインストールされたプログラムを、RAM(Random Access Memory) １０３にロードして実行する。これにより、上述した図２の配信サーバ１２の機能が、ソフトウェアにより実現されている。さらに、CPU１０１は、通信部１０９を制御して、外部と通信し、データの授受を実行する。

プログラムが記録されている記録媒体は、図１６に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１２１（フレキシブルディスクを含む）、光ディスク１２２（CD-ROM(Compact Disc-Read Only Memory)，DVD（Digital Versatile Disk）を含む）、光磁気ディスク１２３（MD（Mini-Disc）を含む）、もしくは半導体メモリ１２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM１０２や、記憶部１０８に含まれるハードディスクなどで構成される。

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

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

本発明を適用したストリームデータ配信システムの構成を示す図である。 図１の配信サーバの構成を示すブロック図である。 図１のクライアントPCの構成を示すブロック図である。 配信処理を説明するフローチャートである。 RTPパケットを説明する図である。 受信処理を説明するフローチャートである。 NACKを説明する図である。 再送処理を説明するフローチャートである。 図２のエントリ保持部に保持される情報を説明する図である。 図１の配信サーバによるRTTの計測処理を説明するフローチャートである。 RTT計測パケットを説明する図である。 図１のクライアントPCによるRTTの計測処理を説明するフローチャートである。 RTT計測返信パケットを説明する図である。 ロス率の計算処理を説明するフローチャートである。 ロス率の計算を説明する図である。 記録媒体を説明する図である。

符号の説明

１１ カメラ， １２ 配信サーバ， １３ インターネット， １４ クライアントPC， ３１ エンコーダ， ３２ パケタイザ， ３３ バッファ， ３４ 通信部， ３５ パケットカウンタ， ３６ ロス率計算部， ３７ 送信レート保持部， ３８ NACK処理部， ３８ａ NACK保持部， ３９ RTT計算部， ４０ RTC， ５１ 通信部， ５２ バッファ， ５３ デコーダ， ５４ NACK処理部， ５５ RTT処理部

Claims (7)

1. ストリームデータを所定の送信レートで受信装置に送信する送信手段と、
   前記受信装置からの、前記ストリームデータの再送要求を受信する受信手段と、
   前記受信手段により受信された再送要求に基づいて、ロス率を計算するロス率計算手段と、
   前記ロス率計算手段により計算されたロス率に基づいて、前記送信レートを変更する変更手段と
   を備えることを特徴とする送信装置。
2. 往復伝播遅延時間を計算する往復伝播遅延時間計算手段をさらに備え、
   前記ロス率計算手段は、前記再送要求と、前記往復伝播遅延時間に基づいて、ロス率を計算する
   ことを特徴とする請求項１に記載の画像処理装置。
3. 前記ロス率計算手段は、前記往復伝播遅延時間に基づいた間隔で、ロス率を計算し、更新する
   ことを特徴とする請求項２に記載の画像処理装置。
4. 往復伝播遅延時間を計算する往復伝播遅延時間計算手段をさらに備え、
   前記変更手段は、前記ロス率計算手段により計算されたロス率と、前記往復伝播遅延時間計算手段により計算された往復伝播遅延時間に基づいて、前記送信レートを変更する
   ことを特徴とする請求項１に記載の画像処理装置。
5. ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、
   前記受信装置からの、前記ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、
   前記ロス率計算ステップの処理で計算されたロス率に基づいて、前記送信レートを変更する変更ステップと
   を含むことを特徴とする送信方法。
6. ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、
   前記受信装置からの、前記ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、
   前記ロス率計算ステップの処理で計算されたロス率に基づいて、前記送信レートを変更する変更ステップと
   を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
7. ストリームデータを所定の送信レートで受信装置に送信する送信ステップと、
   前記受信装置からの、前記ストリームデータの再送要求に基づいて、ロス率を計算するロス率計算ステップと、
   前記ロス率計算ステップの処理で計算されたロス率に基づいて、前記送信レートを変更する変更ステップと
   をコンピュータに実行させることを特徴とするプログラム。

Images