ストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラム
【課題】ネットワークを介して受信端末へストリームを配信するストリーム配信装置において、配信するストリームのビットレートの上昇を判定する際に使用される往復遅延時間ＲＴＴの閾値を、容易かつ自動で設定する。
【解決手段】制御履歴記憶部は、過去のビットレート上昇試行時の上昇直前の往復遅延時間ＲＴＴを履歴情報として記憶する。閾値設定部は、制御履歴記憶部に記憶されたＲＴＴの履歴情報を基に、上昇後のビットレートで配信可能であった場合のＲＴＴと、上昇後のビットレートで配信不可能であった場合のＲＴＴとにより閾値ＲＴＴｔｈの閾値範囲を設定する。そして、時間経過とともに閾値ＲＴＴｔｈを、閾値範囲の下限値から上限値へ近づけて行く。配信レート決定部は、計測した往復遅延時間ＲＴＴ（ＲＴＴｍ）が閾値設定部で設定した閾値ＲＴＴｔｈを下回った場合に、ビットレートを上昇させる。
【解決手段】制御履歴記憶部は、過去のビットレート上昇試行時の上昇直前の往復遅延時間ＲＴＴを履歴情報として記憶する。閾値設定部は、制御履歴記憶部に記憶されたＲＴＴの履歴情報を基に、上昇後のビットレートで配信可能であった場合のＲＴＴと、上昇後のビットレートで配信不可能であった場合のＲＴＴとにより閾値ＲＴＴｔｈの閾値範囲を設定する。そして、時間経過とともに閾値ＲＴＴｔｈを、閾値範囲の下限値から上限値へ近づけて行く。配信レート決定部は、計測した往復遅延時間ＲＴＴ（ＲＴＴｍ）が閾値設定部で設定した閾値ＲＴＴｔｈを下回った場合に、ビットレートを上昇させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラムに関し、特に通信品質の保証されていないネットワークにおいてストリームをパケットに分割して配信するストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラムに関する。
【背景技術】
【０００２】
現在、ネットワークを介して動画像コンテンツ等のストリームデータ（単に、「ストリーム」とも呼ぶ）を配信するサービスが行われている。このストリームの配信を行うストリーム配信装置において、受信端末との間のネットワーク状態に応じてビットレートを制御する技術の一例が特許文献１に記載されている。特許文献１に記載のストリーム配信装置は、受信端末からパケットロスと往復遅延時間（ＲＴＴ：Round Trip Time）の報告を受けて動作するものであり、パケットロスが報告された場合にはネットワーク状態が悪化したと判断して配信するビットレートを低下させ、往復遅延時間ＲＴＴが設定した閾値を下回った場合に、ネットワーク状態が好転したと判断して配信するストリームのビットレートを上昇させるものである。
【０００３】
また、特許文献２に記載のネットワーク監視装置が開示されている。このネットワーク監視装置においては、応答時間計測部が遅延時間を測定し、該遅延時間の履歴を保存し、該遅延時間の平均値に基づいて閾値を算出／更新し、該閾値を超えている場合に経路中に障害が発生していると判定する（段落００３５から００４２を参照）。しかしながら、このネットワーク監視装置は、ＩＰ網における障害の有無を監視することを目的としており、ストリーム配信装置から配信するストリームのビットレートの上昇動作に関するものではない。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−０９９２６１号公報
【特許文献２】特開２００６−１６５６２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した特許文献１に記載のストリーム配信装置における問題点は、データ転送のビットレートを上昇させるための往復遅延時間ＲＴＴの閾値をあらかじめ設定しておく必要がある点である。ビットレートを上昇させる適切な閾値は、現在配信しているビットレート、上昇させるビットレートに依存する。すなわち、ビットレートを１Ｍｂｐｓから２Ｍｂｐｓへ上昇させる場合、２Ｍｂｐｓから４Ｍｂｐｓへ上昇させる場合、４Ｍｂｐｓから８Ｍｂｐｓへ上昇させる場合で適切な往復遅延時間ＲＴＴの閾値は多くの場合異なるはずである。
【０００６】
また、適切な閾値は受信端末ごとに異なる値となるはずである。すなわち、１Ｍｂｐｓから２Ｍｂｐｓへ上昇させるための閾値であっても、受信端末までの経路が異なれば適切な閾値は異なると考えるのが一般的である。そのため、すべての受信端末に対してすべてのビットレートの往復遅延時間ＲＴＴの閾値をあらかじめ設定しておくことは、膨大な時間を必要とし現実的ではない。
【０００７】
また、特許文献１に記載のストリーム配信装置においては、往復遅延時間ＲＴＴ等の閾値を動的（自ら積極的）に設定変更してビットレートの上昇試行を行う考え方は示されてない。
【０００８】
本発明の主たる課題は、ストリーム配信装置において、ビットレートを上昇させるための往復遅延時間ＲＴＴの閾値を、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を利用して、容易かつ自動で設定できるようにすることにあり、さらには、往復遅延時間ＲＴＴの閾値を動的に設定変更して、ビットレートの不用意な上昇と、低ビットレートでの停滞を防止することにある。
【課題を解決するための手段】
【０００９】
本発明のストリーム配信装置は、受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する、ことを特徴とする。
【発明の効果】
【００１０】
本発明のストリーム配信装置においては、受信端末およびビットレートごとに、過去のビットレートの上昇試行時の往復遅延時間ＲＴＴを履歴情報として記憶する。そして、例えば、上昇後のビットレートで配信可能であった場合の往復遅延時間ＲＴＴと、上昇後のビットレートで配信不可能であった場合の往復遅延時間ＲＴＴとを基に、閾値ＲＴＴｔｈを設定する。
これにより、受信端末とビットレートに応じた適切な閾値ＲＴＴｔｈを、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を基に、容易かつ自動で設定できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施の形態に係わるストリーム配信システムの構成を示すブロック図である。
【図２】制御履歴記憶部１５の構成例を示す図である。
【図３】第１の実施の形態の動作を示すフローチャートである。
【図４】往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの第１の設定方法を示すグラフである。
【図５】往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの第２の設定方法を示すグラフである。
【図６】本発明の第２の実施の形態に係わるストリーム配信システムの構成を示すブロック図である。
【図７】第２の実施の形態の動作を示すフローチャートである。
【図８】第２の実施の形態におけるネットワーク状態推定方法を示す第１のシーケンス図である。
【図９】第２の実施の形態におけるネットワーク状態推定方法を示す第２のシーケンス図である。
【図１０】実施例１におけるストリーム配信装置１の制御履歴記憶部１５の構成を示す図である。
【図１１】実施例１における往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの例を示す図である。
【図１２】実施例１における受信端末２からストリーム配信装置１へのレポートの例を示す図である。
【図１３】実施例１におけるストリーム配信装置１の制御履歴記憶部１５内の上昇可否記憶テーブルの例を示す図である。
【図１４】実施例１における往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの例を示す図である。
【図１５】実施例１におけるストリーム配信装置１の制御履歴記憶部１５内の上昇可否記憶テーブルの例を示す図である。
【図１６】実施例２におけるネットワーク状態推定方法を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、発明の実施の形態について図面を参照しながら説明する。
【００１３】
［第１の実施の形態］
図１は、本発明の第１の実施の形態に係わるストリーム配信システムの構成を示す図である。図１に示すように、本発明のストリーム配信システムは、ストリーム（動画像等のコンテンツ）をネットワークを通して配信するストリーム配信装置１と、ストリームを受信して再生する受信端末２から構成される。
【００１４】
ストリーム配信装置１と受信端末２は、インターネットなどの利用可能な帯域が保証されていないネットワークで接続されている。また、ストリーム配信装置１は複数の受信端末２と接続していてもよい。
【００１５】
ストリーム配信装置１は、受信端末２へ向けてストリームを送信するストリーム送信部１１、受信端末２へストリームとして配信するコンテンツを記憶するコンテンツ記憶部１２、受信端末２からのレポートを受信するレポート受信部１３、受信端末２へ配信するコンテンツのビットレートを判定（決定）する配信レート決定部１４、過去の制御履歴の情報を記憶する制御履歴記憶部１５、制御履歴の情報を基にビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを設定する閾値設定部１６、ストリームの配信開始や終了を管理する配信管理部１７から構成される。
【００１６】
まず、配信管理部１７は、受信端末２からの配信要求のメッセージの受信時に、コンテンツ記憶部１２から当該コンテンツの配信可能なビットレートのリストを取得し、配信レート決定部１４に対して配信コンテンツとビットレートのリストを通知し、配信開始を指示する。
【００１７】
本実施の形態では、以降、受信端末２を１台として説明する。受信端末２が複数存在する場合、符号１１から１７で示す各処理部の間の通信内容に受信端末の識別子が追加されるが、ここでは省略する。
【００１８】
ストリーム送信部１１は、配信レート決定部１４から指示されたビットレートのコンテンツをコンテンツ記憶部１２から取り出し受信端末２へ向けて送信する。ストリーム配信装置１から受信端末２へのコンテンツ送信は、トランスポートプロトコルとしてコネクションレス型プロトコルを使用し、トランスポートプロトコルでの輻輳制御、到達確認や再送は行われないこととする。また、ストリーム送信部１１は、コンテンツ配信中に配信レート決定部１４からビットレートの変更を指示された場合には、受信端末２での再生に途切れが発生しないように瞬時にビットレートを切り替える。
【００１９】
映像コンテンツの場合、ＭＰＥＧ−２やＭＰＥＧ−４などフレーム間予測を使用して圧縮されている場合がある。フレーム間予測を使用して圧縮されたコンテンツは、単独で復号可能なＩフレームと、前後のフレームの情報を使用して復号するＰフレーム、Ｂフレームからなる。このとき、ＰフレームまたはＢフレームの直前でビットレートを切り替えると、受信端末２は前のフレームが存在しないため正しく復号できない。そのため、フレーム間予測を使用して圧縮されているコンテンツの場合には、Ｉフレームの直前で切り替える。
【００２０】
コンテンツ記憶部１２は、ストリーム送信部１１から受信端末２へ送信するコンテンツデータ（ストリームデータ）を記憶する処理部であり、各コンテンツをあらかじめ複数のビットレートでエンコードして保持しておく。あるいは、ストリーム送信部１１からの要求されたビットレートにトランスコードしたコンテンツデータを一時的に記憶する記憶部でもよい。
【００２１】
レポート受信部１３は、受信端末２が送信した受信状態のレポート情報を受け、パケットロスの有無と往復遅延時間ＲＴＴとを配信レート決定部１４へ通知する。このとき、受信端末２からパケットロス率がレポートされる場合には、配信レート決定部１４へパケットロス率を通知してもよい。
【００２２】
配信レート決定部１４は、配信管理部１７からコンテンツの配信開始を指示されると、初期の配信レートを決定してストリーム送信部１１へ送信開始を指示する。初期の配信レートは、配信するコンテンツの中でビットレートが最低のものを選択する方法、受信端末２の種類や回線種別をストリーム配信装置１が把握している場合にはそれらの情報を使用して決定する方法、あるいは、配信開始前に利用可能帯域を推定し、その推定値をもとに決定する方法など、いかなる方法を使用してもよい。
【００２３】
また、配信レート決定部１４は、コンテンツ配信中にレポート受信部１３からパケットロスの有無と往復遅延時間ＲＴＴの通知を受け、パケットロスが発生している場合には配信するコンテンツのビットレートを１段階低下することを決定し、ストリーム送信部へ指示する。レポート受信部１３からパケットロス率が通知される場合には、パケットロス率が規定値を超えていたらビットレートを１段階低下させてもよい。パケットロスが発生していない場合には、閾値設定部１６からビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを受け取り、レポート受信部１３から通知された往復遅延時間ＲＴＴ（計測された最新の往復遅延時間ＲＴＴｍ）と比較する。
【００２４】
その結果、「ＲＴＴｍ≧ＲＴＴｔｈ」ならばビットレートを変更しないことを決定し、ストリーム送信部１１に対してはビットレート変更の指示は行わない。一方で、「ＲＴＴｍ＜ＲＴＴｔｈ」ならば配信するビットレートを１段階上昇することを決定し、ストリーム送信部１１へ指示する。
【００２５】
配信レート決定部１４は、ビットレートの上昇を決定した場合に、往復遅延時間ＲＴＴｍを記憶しておき、上昇させたビットレートでパケットロスなく配信できたか否かを判定して、制御履歴記憶部１５を更新し（更新方法は後述）、閾値設定部１６へ制御履歴記憶部１５における履歴情報の更新を通知する。
【００２６】
なお、上昇させたビットレートでパケットロスなく配信できたか否かは、ビットレートを上昇させた直後の受信端末２からのレポートでパケットロスの発生が通知されるか否かで決定する。また、ビットレートを上昇させた直後だけでなく、ビットレートを上昇させてから指定回数・指定時間のレポートでパケットロスの発生が通知されるか否かで決定してもよい。レポート受信部１３からパケットロスの有無だけでなくパケットロス率が通知される場合には、パケットロス率が規定値を超えているか否かを基に決定してもよい。
【００２７】
制御履歴記憶部１５は、配信レート決定部１４での制御履歴の情報を記憶する処理部である。図２は、制御履歴記憶部１５の構成例を示す図である。
【００２８】
図２に示すように、制御履歴記憶部１５は、受信端末（端末１，端末２，端末３，・・・）ごとの上昇可否記憶テーブル１５１（１５１−１、１５１−２、…）から構成され、それぞれの上昇可否記憶テーブル１５１は、上昇前ビットレート１５１１、上昇後ビットレート１５１２、上昇可能ＲＴＴ１５１３、上昇不可能ＲＴＴ１５１４の組で１レコードが構成される。
【００２９】
上昇可能ＲＴＴ１５１３と上昇不可能ＲＴＴ１５１４は、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇させる直前の往復遅延時間ＲＴＴを格納する領域である。上昇可能ＲＴＴ１５１３に格納されているのは、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇可能であった場合の往復遅延時間ＲＴＴ、上昇不可能ＲＴＴ１５１４に格納されているのは、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇不可能であった場合の往復遅延時間ＲＴＴである。
【００３０】
図２の端末１に対する上昇可否記憶テーブル１５１−１では、ビットレートＢＲ１［ｂｐｓ］での配信中に、往復遅延時間ＲＴＴが「Ｒｏｋ１＿１，Ｒｏｋ１＿２，・・・」の場合、ビットレートＢＲ２［ｂｐｓ］で配信でき、往復遅延時間ＲＴＴが「Ｒｎｇ１＿１，Ｒｎｇ１＿２，・・・」の場合、ビットレートＢＲ２［ｂｐｓ］では配信できなかったことを表している。
【００３１】
なお、初めて配信する端末などで、これまでにビットレート上昇の試行が行われていない場合には、初期値として上昇可能ＲＴＴ１５１３には十分小さな値を格納しておき、上昇不可能ＲＴＴ１５１４には十分大きな値を格納しておくものとする。
【００３２】
配信レート決定部１４は、上昇させたビットレートでの配信可否判定後に、制御履歴記憶部１５の上昇可否記憶テーブル１５１から上昇前ビットレートと上昇後ビットレートが一致するレコードを検索し、計測した往復遅延時間ＲＴＴｍを上昇可能ＲＴＴまたは上昇不可能ＲＴＴへ格納する。
【００３３】
閾値設定部１６は、制御履歴記憶部１５に記憶された履歴情報（上昇可否記憶テーブル１５１）に基づいてビットレートを上昇させる往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを計算し、配信レート決定部１４へ通知する。閾値設定部１６は、配信レート決定部１４から制御履歴記憶部１５の更新を通知されると、制御履歴記憶部１５から上昇可否記憶テーブル１５１の内容を取り出し、ビットレートを１段階上昇させるための閾値の上限値と下限値を求める。
【００３４】
閾値の下限ＲＴＴｌｂは、上昇可能ＲＴＴ１５１３に格納された往復遅延時間ＲＴＴの最大値、
ｍａｘ｛Ｒｏｋ１＿１，Ｒｏｋ１＿２，…，Ｒｏｋ１＿ｎ｝や、
平均値（Ｒｏｋ１＿１＋Ｒｏｋ１＿２＋…＋Ｒｏｋ１＿ｎ）／ｎ、などによって決定する。
【００３５】
また、閾値の上限ＲＴＴｕｂは上昇不可能ＲＴＴ１５１４に格納された往復遅延時間ＲＴＴの最小値、
ｍｉｎ｛Ｒｎｇ１＿１，Ｒｎｇ１＿２，…，Ｒｎｇ１＿ｍ｝や、
平均値（Ｒｎｇ１＿１＋Ｒｎｇ１＿２＋…＋Ｒｎｇ１＿ｍ）／ｍ、などによって決定する。
【００３６】
次に、［下限ＲＴＴｌｂ，上限ＲＴＴｕｂ］の範囲で閾値ＲＴＴｔｈを決定する。閾値ＲＴＴｔｈは、時間経過とともに下限ＲＴＴｌｂから上限ＲＴＴｕｂへ近づけていく方法を採る。これは、ビットレート上昇の試行回数を減らし、かつ、低ビットレートに停滞するのを防止するためである。
【００３７】
本来は上昇不可能であるにも関わらずビットレートを上昇させると、受信端末２での再生に途切れや乱れが生じるため、ビットレート上昇の試行はなるべく少なくすることが望ましい。一方で、試行を少なくするとビットレートを上昇可能にも関わらず上昇させずに低いビットレートのままで停滞してしまうことがある。閾値ＲＴＴｔｈを下限ＲＴＴｌｂから上限ＲＴＴｕｂへ近づけることで、初めは、往復遅延時間ＲＴＴが小さく、ネットワーク状態が非常によく、上昇させても配信できる可能性が高い場合のみビットレートを上昇させ、時間が経過するにつれてビットレート上昇を発生しやすくして低ビットレートでの停滞を防止することが可能となる。
【００３８】
具体的には、図４に示すように初期値を「ＲＴＴｔｈ＝ＲＴＴｌｂ」とし、閾値ＲＴＴｔｈを、下限ＲＴＴｌｂと上限ＲＴＴｕｂとの間で、
ＲＴＴｔｈ＝ＲＴＴｔｈ＋α（α：１回の処理での増加量）、
と変更していく方法がある。
【００３９】
または、図５に示すように
ＲＴＴｔｈ＝ＲＴＴｔｈ＋（β＾ｉ（ＲＴＴｕｂ−ＲＴＴｌｂ）） （β：０＜β＜１を満たす定数、ｉ：変更回数）、
と変更していく方法などある。
【００４０】
なお、閾値を変更する間隔、α、βはあらかじめ決定しておく。また、ここで述べた以外の方法で閾値を変更してもよい。
【００４１】
受信端末２は、ネットワークを通してストリーム配信装置１からストリームを受信するストリーム受信部２１と、受信状態をストリーム配信装置１へ通知するレポート送信部２２から構成される。
【００４２】
ストリーム受信部２１はレポート送信部２２と接続しており、ストリーム配信装置１からのストリームを受信するとともにパケットロスなどの受信状態を計測し、レポート送信部２２へ通知する。
【００４３】
レポート送信部２２は、ストリーム受信部２１から通知された受信状態の情報からなるレポートを定期的にストリーム配信装置１へフィードバックする。上述した例では、最新のレポートから求めた往復遅延時間ＲＴＴを閾値ＲＴＴｔｈと比較していた。しかし、クロストラフィックの発生などによって往復遅延時間ＲＴＴに揺らぎが発生する場合がある。この揺らぎによる影響を吸収するため、往復遅延時間ＲＴＴの移動平均を使用してもよい。
【００４４】
すなわち、受信端末２から受信したレポートのうち最新ｉ個の往復遅延時間ＲＴＴをＲ１，Ｒ２，Ｒ３，…，Ｒｉとしたとき、
ＲＴＴｍ＝（ａ１・Ｒ１＋ａ２・Ｒ２＋…＋ａｉ・Ｒｉ）／ｉ （ａ１，…，ａｉ：重み付けの係数）、とする方法である。
【００４５】
次に図３のフローチャートを参照して、本実施の形態の全体の動作について詳細に説明する。
まず、ストリームの配信開始時において、配信管理部１７は配信レート決定部１４へ配信開始を指示し、配信レート決定部１４は初期配信レート（初期のビットレート）を決定する（ステップＳ０１）。
【００４６】
次に現在配信中のビットレートから１段階上のビットレートに変更するための閾値を決定する。配信レート決定部１４は初期配信レートと１段階上のビットレートを閾値設定部１６へ通知し、閾値設定部１６は、制御履歴記憶部１５の上昇可否記憶テーブル１５１から該当するレコードを取り出す。
【００４７】
閾値設定部１６では、取り出したレコードをもとに、閾値の上限ＲＴＴｕｂと下限ＲＴＴｌｂを決定し（ステップＳ０２）、［ＲＴＴｌｂ，ＲＴＴｕｂ］の範囲から閾値ＲＴＴｔｈを決定して（ステップＳ０３）、配信レート決定部１４からの要求時に閾値ＲＴＴｔｈを通知する。
【００４８】
前述のとおり閾値ＲＴＴｔｈは、下限ＲＴＴｌｂから上限ＲＴＴｕｂへ時間経過とともに近づけていく（図４、図５を参照）。そこで、閾値設定部１６は、前回閾値ＲＴＴｔｈを変更してからの経過時間や、計測した往復遅延時間ＲＴＴｍとの比較回数をもとにして閾値ＲＴＴｔｈを必要に応じて変更する（ステップＳ０３）。
【００４９】
以下、現在配信しているコンテンツ（ストリーム）のビットレートをＢＲ１、ＢＲ１よりも１段階上のビットレートをＢＲ２、ＢＲ２よりも１段階上のビットレートをＢＲ３、ＢＲ１よりも１段階下のビットレートをＢＲ０と表す。
【００５０】
受信端末２から受信状態のレポートを受信すると、レポート受信部１３はパケットロスの有無と、往復遅延時間ＲＴＴとを配信レート決定部１４へ通知する（ステップＳ０４）。配信レート決定部１４は、まずパケットロスの有無を判定する（ステップＳ０５）。パケットロスが発生している場合には（ステップＳ０５：Ｙｅｓ）、配信レートをＢＲ１からＢＲ０へ１段階低下させ（ステップＳ０６）、ステップＳ０２へ戻る。
【００５１】
パケットロスが発生していない場合には（ステップＳ０５：Ｎｏ）、レポート受信部１３から通知された往復遅延時間ＲＴＴｍと閾値設定部１６から通知された閾値ＲＴＴｔｈを比較する（ステップＳ０７）。往復遅延時間ＲＴＴｍが閾値ＲＴＴｔｈを下回っていない場合（ステップＳ０７：Ｎｏ）にはビットレートの変更は行わずに、ステップＳ０３へ戻る。
【００５２】
往復遅延時間ＲＴＴｍが閾値ＲＴＴｔｈを下回った場合には（ステップＳ０７：Ｙｅｓ）、配信レート決定部１４は、配信レートをビットレートＢＲ１からＢＲ２へ１段階上昇することを決定し、ストリーム送信部１１は配信レートを１段階上昇させる（ステップＳ０８）。
【００５３】
配信レートを上昇後、配信レート決定部１４は上昇後のレート（ＢＲ２）で配信可能か否かを判定する（ステップＳ０９）。この判定は、前述の通り、配信レート変更後のレポートのパケットロス発生有無によって行う。
【００５４】
配信可能な場合には（ステップＳ０９：Ｙｅｓ）、上昇直前に計測した往復遅延時間ＲＴＴｍを、制御履歴記憶部１５の上昇可否記憶テーブル１５１における上昇前ビットレートがＢＲ１かつ上昇後ビットレートがＢＲ２のエントリの上昇可能ＲＴＴ１５１３に追加し（ステップＳ１２）、ステップＳ０２へ戻る。
【００５５】
一方でビットレートＢＲ２で配信できない場合には（ステップＳ０９：Ｎｏ）、上昇不可能ＲＴＴ１５１４へ往復遅延時間ＲＴＴｍを追加し（ステップＳ１０）、配信レートをＢＲ１へ戻し（ステップＳ１１）、ステップＳ０２へ戻る。
【００５６】
以上説明したように、本発明のストリーム配信装置においては、受信端末ごとに、過去のビットレート上昇試行時の往復遅延時間ＲＴＴを履歴情報として記憶し、上昇後のビットレートで配信可能であった場合の往復遅延時間ＲＴＴを使用して閾値の下限値を設定し、上昇後のビットレートで配信不可能であった場合の往復遅延時間ＲＴＴを使用して閾値の上限値を設定し、時間経過とともに閾値を下限値から上限値へ近づけてゆく。
【００５７】
これにより、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報から、受信端末とビットレートに応じた閾値を、容易かつ自動で設定できる。また、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。すなわち、閾値を大きく設定するとネットワーク状態があまり良くない場合にもビットレートを上昇させるため、上昇後のビットレートで配信できず映像に乱れや途切れの発生することが多くなる。一方、閾値を小さく設定するとビットレートを上昇可能でも上昇させず、受信端末に低品質のコンテンツを配信し続けることになる。本発明では、閾値を閾値設定範囲内において、下限値から上限値へ時間経過と共に近づけていくため、初めは上昇後のビットレートで配信できる可能性が高い場合のみビットレートを上昇させて、配信するストリーム（画像等）の乱れや途切れを防止し、時間経過とともにビットレートを上昇しやすくして停滞を防止できる。
【００５８】
なお、図１に示すストリーム配信装置１および受信端末２は、内部にＣＰＵを含むコンピュータシステムを有している。上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。また、ストリーム配信装置１はサーバ装置等で構成され、このストリーム配信装置１には、周辺機器として入力装置、表示装置等（いずれも表示せず）が接続されているものとする。ここで、入力装置としては、キーボード、マウス等の入力デバイスのことをいう。表示装置とは、ＣＲＴ（Cathode Ray Tube）や液晶表示装置等のことをいう。
【００５９】
以上、本発明の第１の実施の形態について説明したが、図１に示す本発明のストリーム配信装置は、受信端末２に配信するストリームのビットレートを上昇試行する際の受信端末２との間の往復遅延時間ＲＴＴを、受信端末２ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶部１５と、制御履歴記憶部１５に記憶された往復遅延時間ＲＴＴの履歴情報を基にしてビットレートを上昇させる際の往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを設定する閾値設定部１６と、受信端末２との間の往復遅延時間ＲＴＴが閾値ＲＴＴｔｈを下回った場合に、当該受信端末２に配信するストリームのビットレートを上昇させること判定する配信レート決定部１４と、を有して構成される。
これにより、ビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを、受信端末２およびビットレートごとに、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を基に、容易かつ自動で設定できる。
【００６０】
また、制御履歴記憶部１５は、ビットレートを上昇させる直前の受信端末２との間の往復遅延時間ＲＴＴを、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して、上昇可否記憶テーブル１５１（図２）に記憶する。
これにより、ビットレートを上昇させた際に、配信が可能であった場合の往復遅延時間ＲＴＴの情報と、配信が不可であった場合の往復遅延時間ＲＴＴを分類して記憶することができ、この履歴情報を基に、閾値ＲＴＴｔｈを容易に設定することができる。
【００６１】
また、閾値設定部１６は、制御履歴記憶部１５に記憶されたビットレート上昇後に配信可能であった往復遅延時間ＲＴＴと、ビットレート上昇後に配信不可能であった往復遅延時間ＲＴＴとを基に閾値設定範囲を決定し、該閾値設定範囲内から閾値ＲＴＴｔｈを設定する。
これにより、配信が可能であった場合の往復遅延時間ＲＴＴの履歴情報と、配信が不可であった場合の往復遅延時間ＲＴＴの履歴情報を基にして閾値設定範囲を決定し、該閾値設定範囲内から閾値ＲＴＴｔｈを設定することができる。
【００６２】
また、閾値設定部１６は、閾値設定範囲内で閾値ＲＴＴｔｈを変化させる、この場合に、閾値設定範囲内で、閾値ＲＴＴｔｈを時間経過とともに下限値から上限値へ近づくように設定変更する。
これにより、往復遅延時間ＲＴＴの閾値を動的に設定変更してビットレートの上昇試行を積極的に行うことができ、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞とを防止できる。
【００６３】
［第２の実施の形態］
次に、本発明の第２の実施の形態について図面を参照しながら説明する。
【００６４】
図６は、本発明の第２の実施の形態に係わるストリーム配信システムの構成を示す図である。図６に示すように、本発明の第２の実施の形態に係わるストリーム配信装置１Ａは、図１に示す第１の実施の形態のストリーム配信装置１と比較して、レポート受信部１３が削除され、受信端末２Ａとの間の管理セッションの情報からネットワーク状態を推定するネットワーク状態推定部１８が追加された点が異なる。他の構成は図１に示すストリーム配信装置１および受信端末１と同様である。このため、同一の構成部分には同一の符号を付している。
【００６５】
また、受信端末２Ａは、図１に示す第１の実施の形態の受信端末１と比較して、レポート送信部２２が削除され、ストリーム配信装置１Ａとの間でセッション情報をやりとりする管理情報通信部２３が追加された点が異なる。
【００６６】
この第２の実施の形態では、ストリーム配信装置１Ａの配信管理部１７と受信端末２Ａの管理情報通信部２３はコネクション型プロトコルを使用した管理セッションを接続している。コネクション型プロトコルは確認応答機能を備えており、送信側が送信したデータを受信側が受信すると、受信側から送信側へ確認応答が送信される。
【００６７】
また、受信側からデータの不着を意味する否定応答があった場合や、送信後所定時間が経過しても確認応答を受信できない場合にはデータを再送する。再送を既定回数行っても確認応答を受信できない場合には、上位レイヤに対して、送信が完了しなかったことを通知する。
【００６８】
この管理セッションでは、配信開始前に受信端末２Ａからストリーム配信装置１Ａへ配信要求を行い、配信中にはストリーム配信装置１Ａから受信端末２Ａへの死活監視に使用する。死活監視は、あらかじめ指定した間隔でストリーム配信装置１Ａから受信端末２Ａへ死活監視用データ（例えば、死活監視パケット）を送信することで行う。死活監視用データが受信端末２Ａへ到達すると、受信端末２Ａからストリーム配信装置１Ａへ確認応答が送信され、確認応答を受信したストリーム配信装置１Ａは受信端末２Ａとの間の接続が維持されていることを確認する。
【００６９】
所定回数連続して端末との接続維持が確認できなかった場合、ストリーム配信装置１Ａは受信端末２Ａが切断されたものと判定して、配信を停止する。
【００７０】
ストリーム配信装置１Ａのネットワーク状態推定部１８は、この死活監視の通信をモニタリングし、ネットワーク状態を推定する。ネットワーク状態推定部１８は、配信管理部１７から受信端末２Ａへ死活監視用データを送信した時刻を記憶しておき、確認応答を受信した時刻との差分を往復遅延時間ＲＴＴする。また、コネクション型プロトコルでの再送が発生した場合には、パケットロスが発生していると判断する。ネットワーク状態推定部１８は、この結果を配信レート決定部１４へ通知し、配信レート決定部１４では、第１の実施の形態と同様に動作する（例えば、パケットロスが発生している場合は、配信するストリームのビットレートを１段階低下させる）。
【００７１】
次に、図７のフローチャートを参照して第２の実施の形態の動作を説明する。この第２の実施の形態では、図３に示すフローチャートにおけるレポート受信部１３が受信端末２からレポートを受信するステップＳ０４が、ネットワーク状態推定部１８がネットワーク状態を推定するステップＳ１３に代わった点で第１の実施の形態と異なる。他のステップは図３に示すフローチャートと同様である。このため、同一の処理内容には同一の符号を付し、重複する説明は省略する。
【００７２】
ネットワーク状態推定部１８における往復遅延時間ＲＴＴとパケットロスの推定方法を、図８および図９のシーケンス図を使用して説明する。
【００７３】
図８は、パケットロスが発生しなかった場合のシーケンス図である。図８に示すシーケンス図を参照して、まず、ストリーム配信装置１Ａの配信管理部１７が死活監視用データを受信端末２Ａに送信する（ステップＳ１０１）。そして、ネットワーク状態推定部１８は送信時刻Ｔｓｅｎｄを記憶する（ステップＳ１０２）。
【００７４】
受信端末２Ａの管理情報通信部２３は、ストリーム配信装置１Ａから死活監視用データを受信すると（ステップＳ１０３）、ストリーム配信装置１Ａへ確認応答を送信する（ステップＳ１０４）。
【００７５】
ストリーム配信装置１Ａへ確認応答が到着した時刻をＴｒｃｖとすると、ネットワーク状態推定部１８は、「往復遅延時間ＲＴＴｍ＝Ｔｒｃｖ−Ｔｓｅｎｄ」を計算し、パケットロスが発生していないことと合わせて配信レート決定部１４へ通知する。
【００７６】
また、図９は、パケットロスが発生した場合のシーケンス図である。図９に示すシーケンス図を参照して、まず、ストリーム配信装置１Ａの配信管理部１７により、死活監視用データを受信端末２Ａへ送信する（ステップＳ２０１）。そして、ネットワーク状態推定部１８は送信時刻Ｔｓｅｎｄを記憶する（ステップＳ２０２）。
【００７７】
ストリーム配信装置１Ａの配信管理部１７は、死活監視用データ送信後、所定時間経過しても受信端末２Ａから確認応答を受信できない場合に、コネクション型プロトコルにより、死活監視用データの再送が行われる（ステップＳ２０３）。ネットワーク状態推定部１８は、再送が行われるとパケットロスが発生したことを記憶するとともに、送信時刻Ｔｓｅｎｄを再送データの送信時刻に変更する（ステップＳ２０４）。
【００７８】
受信端末２Ａの管理情報通信部２３は、ストリーム配信装置１Ａから死活監視用データを受信する（ステップＳ２０５）と、応答確認を送信する（ステップＳ２０６）。この応答確認を受信したストリーム配信装置１Ａのネットワーク状態推定部１８は、「往復遅延時間ＲＴＴｍ＝Ｔｒｃｖ−Ｔｓｅｎｄ」を計算し、パケットロスが発生したこととともに配信レート決定部１４へ通知する。
【００７９】
以上、説明したように、第２の実施の形態においては、ストリーム配信装置１Ａのネットワーク状態推定部１８により、ストリーム配信装置１Ａと受信端末２Ａとの間の死活監視通信から往復遅延時間ＲＴＴとパケットロスの有無を推定することによって、受信状態をレポートしない受信端末２Ａにおいても、過去のビットレート試行時の往復遅延時間ＲＴＴの制御履歴の情報から、受信端末とビットレートに応じた閾値を容易かつ自動で設定できる。また、第１の実施の形態と同様に、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。
【００８０】
なお、図６に示すストリーム配信装置１Ａおよび受信端末１Ａは、内部にＣＰＵを含むコンピュータシステムを有している。上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。また、ストリーム配信装置１Ａはサーバ装置等で構成され、このストリーム配信装置１Ａには、周辺機器として入力装置、表示装置等（いずれも表示せず）が接続されているものとする。ここで、入力装置としては、キーボード、マウス等の入力デバイスのことをいう。表示装置とは、ＣＲＴ（Cathode Ray Tube）や液晶表示装置等のことをいう。
【実施例１】
【００８１】
次に、具体的な実施例を用いて本発明のストリーム配信システムの動作について説明する。実施例１は、図１に示す第１の実施の形態のストリーム配信システムの具体的な例を示すものである。本実施例１においては、ストリーム配信装置１と受信端末２はインターネットを経由して接続されているものとする。
【００８２】
ストリーム配信装置１から受信端末２へのコンテンツ配信はＲＴＰ（Real-time Transport Protocol）によって行われ、受信端末２からストリーム配信装置１へのレポートの送信はＲＴＣＰ（RTP Control Protocol）によって行われる。ＲＴＰ、ＲＴＣＰともにトランスポートプロトコルには、ＵＤＰ（User Datagram Protocol）を使用する。
【００８３】
そして、ストリーム配信装置１はサーバ装置で構成される。ストリーム送信部１１は、サーバ装置のＣＰＵで実行されるプログラム（ストリーム送信部における一連処理の過程が記述されたプログラム）とネットワーク・インタフェース・カード（以下、ＮＩＣと略記）の組み合わせで実現される。このストリーム送信部１１は、コンテンツ記憶部１２から取り出したコンテンツデータを適当なサイズに分割し、分割した各データにＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダを付加したパケットを生成し、受信端末２へ向けて送信する。また、受信端末２に対して、定期的にメッセージ「ＲＴＣＰ ＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）」を送信する。本実施例１では、メッセージ「ＲＴＣＰ ＳＲ」の送信間隔を５秒とする。
【００８４】
コンテンツ記憶部１２は、サーバ装置に内蔵される磁気ディスク装置等の記憶装置であり、各映像コンテンツを複数のビットレートでエンコードして記憶しておく。本実施例１におけるコンテンツ記憶部１２は、３種類のコンテンツＡ，Ｂ，Ｃを記憶しているとする。コンテンツＡ，Ｂは、１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，８Ｍｂｐｓの各ビットレートを記憶しており、コンテンツＣは、１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，６Ｍｂｐｓ，８Ｍｂｐｓの各ビットレートを記憶している。コンテンツＡ，ＢとコンテンツＣは、コンテンツＣが６Ｍｂｐｓを記憶している点が異なっている。なお、コンテンツ記憶部１２が記憶するコンテンツは、画像でもよいし音声でもよい。
【００８５】
レポート受信部１３は、ストリーム送信部１１と同様にＣＰＵで実行されるプログラム（レポート受信部における一連の処理の過程が記述されたプログラム）とＮＩＣの組み合わせで実現され、端末からのメッセージ「ＲＴＣＰ ＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）」を受信し、パケットロス率と往復遅延時間ＲＴＴを計算して、配信レート決定部１４へ通知する。
【００８６】
パケットロス率はメッセージ「ＲＴＣＰ ＲＲ」の「ｆｒａｃｔｉｏｎ ｌｏｓｔ」フィールドまたは「ｃｕｍｕｌａｔｉｖｅ ｎｕｍｂｅｒ ｏｆ ｐａｃｋｅｔｓ ｌｏｓｔ」フィールドから求めることができる。また、往復遅延時間ＲＴＴはメッセージ「ＲＴＣＰ ＲＲ」の「ＬＳＲ」フィールドと「ＤＬＳＲ」フィールドから求めることができる。
【００８７】
配信レート決定部１４は、その一連の処理の過程が記述されたプログラムをＣＰＵが読み出して実行することにより、その機能が実現される。制御履歴記憶部１５は、サーバ装置のメインメモリの一部である。閾値設定部１６と配信管理部１７についても、その一連の処理の過程が記述されたプログラムをＣＰＵが読み出して実行することにより、その機能が実現される。
【００８８】
コンテンツ記憶部１２が上記のＡ，Ｂ，Ｃのコンテンツを記憶しているとき、制御履歴記憶部１５の上昇可否記憶テーブル１５１は、図１０に示すようになる。「上昇前ビットレートが１Ｍｂｐｓで上昇後ビットレートが２Ｍｂｐｓのエントリ」と、「上昇前ビットレートが２Ｍｂｐｓで上昇後ビットレートが４Ｍｂｐｓのエントリ」は、コンテンツＡ，Ｂ，Ｃのすべてで使用される。
【００８９】
「上昇前ビットレートが４Ｍｂｐｓで上昇後ビットレートが６Ｍｂｐｓのエントリ」と、「上昇前ビットレートが６Ｍｂｐｓで上昇後ビットレートが８Ｍｂｐｓのエントリ」は、コンテンツＣのみで使用され、「上昇前ビットレートが４Ｍｂｐｓで上昇後ビットレートが８Ｍｂｐｓのエントリ」は、コンテンツＡ，Ｂで使用される。これまでに一度も配信したことのない端末の場合、上昇可能ＲＴＴ１５１３と上昇不可能ＲＴＴ１５１４には初期値を記憶しておく。
【００９０】
本実施例１では、上昇可能ＲＴＴ１５１３の初期値を０［ｓ］、上昇不可能ＲＴＴ１５１４の初期値を１［ｓ］としている。受信端末２は、ＩＰＴＶ（Internet Protocol TeleVision）用のセット・トップ・ボックス（ＳＴＢ：Set Top Box)である。ストリーム受信部２１とレポート送信部２２は、ＣＰＵで実行されるプログラム（ストリーム送信部およびレポート送信部における一連の処理の過程が記述されたプログラム）とＮＩＣの組み合わせで実現される。
【００９１】
受信端末２内のストリーム受信部２１は、ストリーム配信装置１から配信されたパケットを受信し、ＲＴＰ、ＵＤＰ、ＩＰ、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダのデコードを行い、コンテンツのデコード部（図示せず）へ転送する。
【００９２】
ストリーム受信部２１でのＲＴＰデコード時には、メッセージ「ＲＴＣＰ ＲＲ」の送信に必要な各種データを収集し、レポート送信部２２へ通知する。また、ストリーム配信装置１から送信されるメッセージ「ＲＴＣＰ ＳＲ」を受信し、レポート送信部２２に転送する。
【００９３】
レポート送信部２２は、ストリーム受信部２１から得た情報をもとにメッセージ「ＲＴＣＰ ＲＲ」をストリーム配信装置１へ送信する。本実施例１では、メッセージ「ＲＴＣＰ ＲＲ」の送信間隔を１秒とする。なお、受信端末２は、セット・トップ・ボックス（ＳＴＢ）だけでなく、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、携帯電話端末などでもよい。
【００９４】
次に、実施例１において、ストリーム配信装置１が受信端末２からコンテンツＡの配信要求を受けた場合の動作を、図３のフローチャートを参照して、説明する。
【００９５】
配信管理部１７は、コンテンツ記憶部１２を参照し、コンテンツＡは１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，８Ｍｂｐｓで配信可能であることを配信レート決定部１４へ通知し、配信開始を指示する。配信レート決定部１４は、配信可能なビットレートの中から配信開始時のビットレート（配信レート）を決定する（ステップＳ０１）。ここでは、配信可能な最低のビットレートで配信開始する方法を採用し、１Ｍｂｐｓで配信を開始する。
【００９６】
次に配信レート決定部１４は、ビットレートを上昇させるための閾値を決定する。１Ｍｂｐｓの１段階上のビットレートは２Ｍｂｐｓなので、制御履歴記憶部１５の上昇可否記憶テーブル１５１から上昇前ビットレート１５１１が１Ｍｂｐｓ、上昇後ビットレート１５１２が２Ｍｂｐｓのエントリを抽出する。
【００９７】
次に抽出したエントリの上昇可能ＲＴＴ１５１３から閾値の下限ＲＴＴｌｂを、上昇不可能ＲＴＴ１５１４から閾値の上限ＲＴＴｕｂを決定する（ステップＳ０２）。本実施例１では、上昇可能ＲＴＴ１５１３の最大値を下限ＲＴＴｌｂ、上昇不可能ＲＴＴ１５１４の最小値を上限ＲＴＴｕｂとすると「ＲＴＴｌｂ＝０［ｓ］、ＲＴＴｕｂ＝１［ｓ］」となる。
【００９８】
次に、下限ＲＴＴｌｂと上限ＲＴＴｕｂからビットレートを上昇させるための閾値を決定する（ステップＳ０３）。本実施例１では、初期値を「ＲＴＴｔｈ＝ＲＴＴｌｂ」とし、閾値ＲＴＴｔｈが、下限ＲＴＴｌｂと上限ＲＴＴｕｂとの間で、
ＲＴＴｔｈ＝ＲＴＴｔｈ＋α（α：１回の処理での増加量）、
と変更していく方法（図４）を採用し、閾値ＲＴＴｔｈはレポートを２回受信するごとに更新し、「α＝（ＲＴＴｕｂ−ＲＴＴｌｂ）／１０」とする。このとき、閾値ＲＴＴｔｈは、図１１に示す変化をする。
【００９９】
一方、端末から図１２に示すレポートが送信されてきた場合、５回目で閾値ＲＴＴｔｈが０．２、往復遅延時間ＲＴＴｍが０．１８となり（ＲＴＴｍ＜ＲＴＴｔｈ）、ビットレートを１Ｍｂｐｓから２Ｍｂｐｓへ上昇させる（ステップＳ０８）。次に、上昇したビットレート２Ｍｂｐｓで配信可能かどうかを判定する（ステップＳ０９）。本実施例１では、ビットレートの上昇直後のレポートでパケットロスが報告された場合に配信不可と判定する。ここでは、上昇直後のレポートでパケットロスが報告されたとする（ステップＳ０９：Ｎｏ）。このとき、上昇可否記憶テーブル１５１（図１３）の上昇不可能ＲＴＴ１５１４に０．１８を追加し（ステップＳ１０）、ビットレートを１Ｍｂｐｓへ低下させ（ステップＳ１１）、ステップＳ０２へ戻る。
【０１００】
ステップＳ０２ではビットレートを再び２Ｍｂｐｓへ上昇させるための閾値の上限ＲＴＴｕｂと下限ＲＴＴｌｂを決定する。「ＲＴＴｌｂ＝０、ＲＴＴｕｂ＝０．１８」となり、閾値ＲＴＴｔｈは図１４のようになる。ビットレート１Ｍｂｐｓへ変更後、５回目の反復で往復遅延時間ＲＴＴｍが０．０３０［ｓ］となり、閾値ＲＴＴｔｈ（０．０３６［ｓ］）を下回ったとすると、再度２Ｍｂｐｓへビットレートを上昇させ、２Ｍｂｐｓで配信可能かどうかを判定する。２Ｍｂｐｓで配信開始後、最初のレポートでパケットロスが発生していないと報告された場合、２Ｍｂｐｓで配信可能と判定し、上昇可否記憶テーブル１５１の上昇可能ＲＴＴ１５１３に０．０３０［ｓ］を追加する（図１５）。
【０１０１】
その後、ステップＳ０２へ戻り、ビットレートを２Ｍｂｐｓから４Ｍｂｐｓへ上昇させるための閾値を設定する。閾値ＲＴＴｔｈは図１１と同様になる。ビットレート２Ｍｂｐｓでの配信中のレポートでパケットロスの発生が報告された場合には（ステップＳ０５：Ｙｅｓ）、ビットレートを１Ｍｂｐｓへ変更し（ステップＳ０６）、ステップＳ０２へ戻る。
【０１０２】
以上説明したように、実施例１においては、ストリーム配信装置１のレポート受信部１３は、インターネットを経由して、受信端末２が送信した受信状態のレポートを受信し、このレポートを基に、パケットロスの有無と往復遅延時間ＲＴＴを検出することによって、ビットレートの上昇試行時の往復遅延時間ＲＴＴの履歴情報を制御履歴記憶部１５に保存する。そして、過去のビットレートの上昇試行時の往復遅延時間ＲＴＴの制御履歴の情報を基に、受信端末とビットレートに応じた閾値を自動的に設定する。また、閾値ＲＴＴｔｈの設定を、閾値設定範囲の下限ＲＴＴｌｂから上限ＲＴＴｕｂに向けて動的（自ら積極的）に設定変更して行くことにより、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止する。
【実施例２】
【０１０３】
第２の実施例は、図６に示す第２の実施の形態のストリーム配信システムの具体的な例を示すものである。
前述の通り、図６に示す第２の実施の形態におけるストリーム配信装置１Ａは、図１に示す第１の実施の形態のストリーム配信装置１と比較してレポート受信部１３が削除され、受信端末２Ａとの間の管理セッションの情報からネットワーク状態を推定するネットワーク状態推定部１８が追加された点が異なる。また、受信端末２Ａは、レポート送信部２２が削除され、ストリーム配信装置１Ａとの間でセッション情報をやりとりする管理情報通信部２３が追加された点で第１の実施の形態と異なる。
【０１０４】
本実施例２における配信管理部１７とネットワーク状態推定部１８は、サーバ装置のＣＰＵで実行されるプログラム（配信管理部およびネットワーク状態推定部における一連処理の過程が記述されたプログラム）によりその機能が実現される。また、管理情報通信部２３は、セット・トップ・ボックスＳＴＢのＣＰＵで実行されるプログラムにより、その機能が実現される。また、ストリーム配信装置１Ａの配信管理部１７と受信端末２Ａの管理情報通信部２３は、ＲＴＳＰ（Real Time Streaming Protocol）によって通信し、プロトコルＲＴＳＰはトランスポートプロトコルにＴＣＰ（Transmission Control Protocol）を使用する。
【０１０５】
受信端末２Ａは、プロトコルＲＴＳＰを使用してストリーム配信装置１Ａへ配信要求を行う。ストリーム配信装置１Ａ内の配信管理部１７は、受信端末２Ａからの配信要求を受信すると、配信レート決定部１４に対して配信開始を指示する。また、配信開始後は、配信管理部１７から受信端末２ＡへＲＴＳＰセッションを使用して死活監視用パケットを送信する。受信端末２Ａの管理情報通信部２３は死活監視用パケットを受信すると、ストリーム配信装置１Ａへ応答確認を送信する。
【０１０６】
次に具体的な例を使用して、実施例２におけるネットワーク状態推定部１８の動作を説明する。図１６は、実施例２におけるネットワーク状態推定方法を示すシーケンス図であり、ストリーム配信装置１Ａと受信端末２Ａとの間の死活監視の処理の流れを示すものである。
【０１０７】
図１６を参照して、時刻０：００：００．１００（０時ちょうどの１００ミリ秒後）に受信端末２Ａへ死活監視パケットを送信したとき、ネットワーク状態推定部１８はこの時刻を記憶しておく。この死活監視パケットは時刻０：００：００．１１０に受信端末２Ａが受信し、時刻０：００：００．１１１に応答確認パケットを送信したとする。
【０１０８】
ストリーム配信装置１Ａは、応答確認パケットを時刻０：００：００．１２１に受信すると、ネットワーク状態推定部１８は、パケットロスが発生しておらず往復遅延時間ＲＴＴが２１ミリ秒（＝０：００：００．１２１−０：００：００．１００）であることを配信レート決定部１４へ通知する。
【０１０９】
その後、時刻０：００：０１．１００に次の死活監視パケットを送信したとする。この死活監視パケットが端末に到達する前にパケットロスした場合、受信端末２Ａからの確認応答が送られてこないため、一定時間経過後（図１６の例では５００ミリ秒としている）にＴＣＰによる再送が行われる。この再送が行われると、ネットワーク状態推定部１８はパケットロスが発生していると判定する。再送した死活監視パケットに対する確認応答を受信すると、ネットワーク状態推定部１８は、パケットロスが発生しており往復遅延時間ＲＴＴが６１ミリ秒（＝０：００：０１．６６１−０：００：０１．６００）であることを配信レート決定部１４へ通知する。
【０１１０】
以上説明したように、実施例２においては、ストリーム配信装置１Ａから受信端末２Ａに対し、インターネットにおけるＲＴＳＰセッションを使用して死活監視用パケットを送信することにより、ストリーム配信装置１Ａのネットワーク状態推定部１８でストリーム配信装置１Ａと受信端末２Ａとの間の往復遅延時間ＲＴＴとパケットロスの有無を推定する。これにより、受信状態をレポートしない受信端末２Ａにおいても、過去のビットレート試行時の往復遅延時間ＲＴＴの制御履歴の情報から、受信端末２Ａとビットレートに応じた閾値ＲＴＴｔｈを容易かつ自動で設定できる。また、第１の実施の形態と同様に、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。
【０１１１】
以上、本発明の実施の形態について説明したが、図１に示すストリーム配信装置１、および図６に示すストリーム配信装置１Ａは、前述のようにサーバ装置等で構成され、内部にコンピュータシステムを有している。そして、上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。
【０１１２】
すなわち、ストリーム配信装置１，１Ａにおける各処理は、ＣＰＵ等の中央演算処理装置がＲＯＭやＲＡＭ等の主記憶装置に上記プログラムを読み出して、情報の加工、演算処理を実行することにより、実現されるものである。
【０１１３】
ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【０１１４】
以上、本発明の実施の形態について説明したが、本発明のストリーム配信システム、およびストリーム配信装置は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【産業上の利用可能性】
【０１１５】
本発明は、インターネット上での映像配信サービスに使用するストリーム配信システムや、監視カメラで撮影した映像を監視センタへ転送する映像監視システムなどに適用できる。
【符号の説明】
【０１１６】
１，１Ａ・・・ストリーム配信装置、２，２Ａ・・・受信端末、１１・・・ストリーム送信部、１２・・・コンテンツ記憶部、１３・・・レポート受信部、１４・・・配信レート決定部、１５・・・制御履歴記憶部、１６・・・閾値設定部、１７・・・配信管理部、１８・・・ネットワーク状態推定部、２１・・・ストリーム受信部、２２・・・レポート送信部、２３・・・管理情報通信部、１５１・・・上昇可否記憶テーブル、１５１１・・・上昇前ビットレート、１５１２・・・上昇後ビットレート、１５１３・・・上昇可能ＲＴＴ、１５１４・・・上昇不可能ＲＴＴ
【技術分野】
【０００１】
本発明はストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラムに関し、特に通信品質の保証されていないネットワークにおいてストリームをパケットに分割して配信するストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラムに関する。
【背景技術】
【０００２】
現在、ネットワークを介して動画像コンテンツ等のストリームデータ（単に、「ストリーム」とも呼ぶ）を配信するサービスが行われている。このストリームの配信を行うストリーム配信装置において、受信端末との間のネットワーク状態に応じてビットレートを制御する技術の一例が特許文献１に記載されている。特許文献１に記載のストリーム配信装置は、受信端末からパケットロスと往復遅延時間（ＲＴＴ：Round Trip Time）の報告を受けて動作するものであり、パケットロスが報告された場合にはネットワーク状態が悪化したと判断して配信するビットレートを低下させ、往復遅延時間ＲＴＴが設定した閾値を下回った場合に、ネットワーク状態が好転したと判断して配信するストリームのビットレートを上昇させるものである。
【０００３】
また、特許文献２に記載のネットワーク監視装置が開示されている。このネットワーク監視装置においては、応答時間計測部が遅延時間を測定し、該遅延時間の履歴を保存し、該遅延時間の平均値に基づいて閾値を算出／更新し、該閾値を超えている場合に経路中に障害が発生していると判定する（段落００３５から００４２を参照）。しかしながら、このネットワーク監視装置は、ＩＰ網における障害の有無を監視することを目的としており、ストリーム配信装置から配信するストリームのビットレートの上昇動作に関するものではない。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−０９９２６１号公報
【特許文献２】特開２００６−１６５６２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した特許文献１に記載のストリーム配信装置における問題点は、データ転送のビットレートを上昇させるための往復遅延時間ＲＴＴの閾値をあらかじめ設定しておく必要がある点である。ビットレートを上昇させる適切な閾値は、現在配信しているビットレート、上昇させるビットレートに依存する。すなわち、ビットレートを１Ｍｂｐｓから２Ｍｂｐｓへ上昇させる場合、２Ｍｂｐｓから４Ｍｂｐｓへ上昇させる場合、４Ｍｂｐｓから８Ｍｂｐｓへ上昇させる場合で適切な往復遅延時間ＲＴＴの閾値は多くの場合異なるはずである。
【０００６】
また、適切な閾値は受信端末ごとに異なる値となるはずである。すなわち、１Ｍｂｐｓから２Ｍｂｐｓへ上昇させるための閾値であっても、受信端末までの経路が異なれば適切な閾値は異なると考えるのが一般的である。そのため、すべての受信端末に対してすべてのビットレートの往復遅延時間ＲＴＴの閾値をあらかじめ設定しておくことは、膨大な時間を必要とし現実的ではない。
【０００７】
また、特許文献１に記載のストリーム配信装置においては、往復遅延時間ＲＴＴ等の閾値を動的（自ら積極的）に設定変更してビットレートの上昇試行を行う考え方は示されてない。
【０００８】
本発明の主たる課題は、ストリーム配信装置において、ビットレートを上昇させるための往復遅延時間ＲＴＴの閾値を、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を利用して、容易かつ自動で設定できるようにすることにあり、さらには、往復遅延時間ＲＴＴの閾値を動的に設定変更して、ビットレートの不用意な上昇と、低ビットレートでの停滞を防止することにある。
【課題を解決するための手段】
【０００９】
本発明のストリーム配信装置は、受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する、ことを特徴とする。
【発明の効果】
【００１０】
本発明のストリーム配信装置においては、受信端末およびビットレートごとに、過去のビットレートの上昇試行時の往復遅延時間ＲＴＴを履歴情報として記憶する。そして、例えば、上昇後のビットレートで配信可能であった場合の往復遅延時間ＲＴＴと、上昇後のビットレートで配信不可能であった場合の往復遅延時間ＲＴＴとを基に、閾値ＲＴＴｔｈを設定する。
これにより、受信端末とビットレートに応じた適切な閾値ＲＴＴｔｈを、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を基に、容易かつ自動で設定できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施の形態に係わるストリーム配信システムの構成を示すブロック図である。
【図２】制御履歴記憶部１５の構成例を示す図である。
【図３】第１の実施の形態の動作を示すフローチャートである。
【図４】往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの第１の設定方法を示すグラフである。
【図５】往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの第２の設定方法を示すグラフである。
【図６】本発明の第２の実施の形態に係わるストリーム配信システムの構成を示すブロック図である。
【図７】第２の実施の形態の動作を示すフローチャートである。
【図８】第２の実施の形態におけるネットワーク状態推定方法を示す第１のシーケンス図である。
【図９】第２の実施の形態におけるネットワーク状態推定方法を示す第２のシーケンス図である。
【図１０】実施例１におけるストリーム配信装置１の制御履歴記憶部１５の構成を示す図である。
【図１１】実施例１における往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの例を示す図である。
【図１２】実施例１における受信端末２からストリーム配信装置１へのレポートの例を示す図である。
【図１３】実施例１におけるストリーム配信装置１の制御履歴記憶部１５内の上昇可否記憶テーブルの例を示す図である。
【図１４】実施例１における往復遅延時間ＲＴＴの閾値ＲＴＴｔｈの例を示す図である。
【図１５】実施例１におけるストリーム配信装置１の制御履歴記憶部１５内の上昇可否記憶テーブルの例を示す図である。
【図１６】実施例２におけるネットワーク状態推定方法を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、発明の実施の形態について図面を参照しながら説明する。
【００１３】
［第１の実施の形態］
図１は、本発明の第１の実施の形態に係わるストリーム配信システムの構成を示す図である。図１に示すように、本発明のストリーム配信システムは、ストリーム（動画像等のコンテンツ）をネットワークを通して配信するストリーム配信装置１と、ストリームを受信して再生する受信端末２から構成される。
【００１４】
ストリーム配信装置１と受信端末２は、インターネットなどの利用可能な帯域が保証されていないネットワークで接続されている。また、ストリーム配信装置１は複数の受信端末２と接続していてもよい。
【００１５】
ストリーム配信装置１は、受信端末２へ向けてストリームを送信するストリーム送信部１１、受信端末２へストリームとして配信するコンテンツを記憶するコンテンツ記憶部１２、受信端末２からのレポートを受信するレポート受信部１３、受信端末２へ配信するコンテンツのビットレートを判定（決定）する配信レート決定部１４、過去の制御履歴の情報を記憶する制御履歴記憶部１５、制御履歴の情報を基にビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを設定する閾値設定部１６、ストリームの配信開始や終了を管理する配信管理部１７から構成される。
【００１６】
まず、配信管理部１７は、受信端末２からの配信要求のメッセージの受信時に、コンテンツ記憶部１２から当該コンテンツの配信可能なビットレートのリストを取得し、配信レート決定部１４に対して配信コンテンツとビットレートのリストを通知し、配信開始を指示する。
【００１７】
本実施の形態では、以降、受信端末２を１台として説明する。受信端末２が複数存在する場合、符号１１から１７で示す各処理部の間の通信内容に受信端末の識別子が追加されるが、ここでは省略する。
【００１８】
ストリーム送信部１１は、配信レート決定部１４から指示されたビットレートのコンテンツをコンテンツ記憶部１２から取り出し受信端末２へ向けて送信する。ストリーム配信装置１から受信端末２へのコンテンツ送信は、トランスポートプロトコルとしてコネクションレス型プロトコルを使用し、トランスポートプロトコルでの輻輳制御、到達確認や再送は行われないこととする。また、ストリーム送信部１１は、コンテンツ配信中に配信レート決定部１４からビットレートの変更を指示された場合には、受信端末２での再生に途切れが発生しないように瞬時にビットレートを切り替える。
【００１９】
映像コンテンツの場合、ＭＰＥＧ−２やＭＰＥＧ−４などフレーム間予測を使用して圧縮されている場合がある。フレーム間予測を使用して圧縮されたコンテンツは、単独で復号可能なＩフレームと、前後のフレームの情報を使用して復号するＰフレーム、Ｂフレームからなる。このとき、ＰフレームまたはＢフレームの直前でビットレートを切り替えると、受信端末２は前のフレームが存在しないため正しく復号できない。そのため、フレーム間予測を使用して圧縮されているコンテンツの場合には、Ｉフレームの直前で切り替える。
【００２０】
コンテンツ記憶部１２は、ストリーム送信部１１から受信端末２へ送信するコンテンツデータ（ストリームデータ）を記憶する処理部であり、各コンテンツをあらかじめ複数のビットレートでエンコードして保持しておく。あるいは、ストリーム送信部１１からの要求されたビットレートにトランスコードしたコンテンツデータを一時的に記憶する記憶部でもよい。
【００２１】
レポート受信部１３は、受信端末２が送信した受信状態のレポート情報を受け、パケットロスの有無と往復遅延時間ＲＴＴとを配信レート決定部１４へ通知する。このとき、受信端末２からパケットロス率がレポートされる場合には、配信レート決定部１４へパケットロス率を通知してもよい。
【００２２】
配信レート決定部１４は、配信管理部１７からコンテンツの配信開始を指示されると、初期の配信レートを決定してストリーム送信部１１へ送信開始を指示する。初期の配信レートは、配信するコンテンツの中でビットレートが最低のものを選択する方法、受信端末２の種類や回線種別をストリーム配信装置１が把握している場合にはそれらの情報を使用して決定する方法、あるいは、配信開始前に利用可能帯域を推定し、その推定値をもとに決定する方法など、いかなる方法を使用してもよい。
【００２３】
また、配信レート決定部１４は、コンテンツ配信中にレポート受信部１３からパケットロスの有無と往復遅延時間ＲＴＴの通知を受け、パケットロスが発生している場合には配信するコンテンツのビットレートを１段階低下することを決定し、ストリーム送信部へ指示する。レポート受信部１３からパケットロス率が通知される場合には、パケットロス率が規定値を超えていたらビットレートを１段階低下させてもよい。パケットロスが発生していない場合には、閾値設定部１６からビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを受け取り、レポート受信部１３から通知された往復遅延時間ＲＴＴ（計測された最新の往復遅延時間ＲＴＴｍ）と比較する。
【００２４】
その結果、「ＲＴＴｍ≧ＲＴＴｔｈ」ならばビットレートを変更しないことを決定し、ストリーム送信部１１に対してはビットレート変更の指示は行わない。一方で、「ＲＴＴｍ＜ＲＴＴｔｈ」ならば配信するビットレートを１段階上昇することを決定し、ストリーム送信部１１へ指示する。
【００２５】
配信レート決定部１４は、ビットレートの上昇を決定した場合に、往復遅延時間ＲＴＴｍを記憶しておき、上昇させたビットレートでパケットロスなく配信できたか否かを判定して、制御履歴記憶部１５を更新し（更新方法は後述）、閾値設定部１６へ制御履歴記憶部１５における履歴情報の更新を通知する。
【００２６】
なお、上昇させたビットレートでパケットロスなく配信できたか否かは、ビットレートを上昇させた直後の受信端末２からのレポートでパケットロスの発生が通知されるか否かで決定する。また、ビットレートを上昇させた直後だけでなく、ビットレートを上昇させてから指定回数・指定時間のレポートでパケットロスの発生が通知されるか否かで決定してもよい。レポート受信部１３からパケットロスの有無だけでなくパケットロス率が通知される場合には、パケットロス率が規定値を超えているか否かを基に決定してもよい。
【００２７】
制御履歴記憶部１５は、配信レート決定部１４での制御履歴の情報を記憶する処理部である。図２は、制御履歴記憶部１５の構成例を示す図である。
【００２８】
図２に示すように、制御履歴記憶部１５は、受信端末（端末１，端末２，端末３，・・・）ごとの上昇可否記憶テーブル１５１（１５１−１、１５１−２、…）から構成され、それぞれの上昇可否記憶テーブル１５１は、上昇前ビットレート１５１１、上昇後ビットレート１５１２、上昇可能ＲＴＴ１５１３、上昇不可能ＲＴＴ１５１４の組で１レコードが構成される。
【００２９】
上昇可能ＲＴＴ１５１３と上昇不可能ＲＴＴ１５１４は、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇させる直前の往復遅延時間ＲＴＴを格納する領域である。上昇可能ＲＴＴ１５１３に格納されているのは、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇可能であった場合の往復遅延時間ＲＴＴ、上昇不可能ＲＴＴ１５１４に格納されているのは、上昇前ビットレート１５１１から上昇後ビットレート１５１２へ上昇不可能であった場合の往復遅延時間ＲＴＴである。
【００３０】
図２の端末１に対する上昇可否記憶テーブル１５１−１では、ビットレートＢＲ１［ｂｐｓ］での配信中に、往復遅延時間ＲＴＴが「Ｒｏｋ１＿１，Ｒｏｋ１＿２，・・・」の場合、ビットレートＢＲ２［ｂｐｓ］で配信でき、往復遅延時間ＲＴＴが「Ｒｎｇ１＿１，Ｒｎｇ１＿２，・・・」の場合、ビットレートＢＲ２［ｂｐｓ］では配信できなかったことを表している。
【００３１】
なお、初めて配信する端末などで、これまでにビットレート上昇の試行が行われていない場合には、初期値として上昇可能ＲＴＴ１５１３には十分小さな値を格納しておき、上昇不可能ＲＴＴ１５１４には十分大きな値を格納しておくものとする。
【００３２】
配信レート決定部１４は、上昇させたビットレートでの配信可否判定後に、制御履歴記憶部１５の上昇可否記憶テーブル１５１から上昇前ビットレートと上昇後ビットレートが一致するレコードを検索し、計測した往復遅延時間ＲＴＴｍを上昇可能ＲＴＴまたは上昇不可能ＲＴＴへ格納する。
【００３３】
閾値設定部１６は、制御履歴記憶部１５に記憶された履歴情報（上昇可否記憶テーブル１５１）に基づいてビットレートを上昇させる往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを計算し、配信レート決定部１４へ通知する。閾値設定部１６は、配信レート決定部１４から制御履歴記憶部１５の更新を通知されると、制御履歴記憶部１５から上昇可否記憶テーブル１５１の内容を取り出し、ビットレートを１段階上昇させるための閾値の上限値と下限値を求める。
【００３４】
閾値の下限ＲＴＴｌｂは、上昇可能ＲＴＴ１５１３に格納された往復遅延時間ＲＴＴの最大値、
ｍａｘ｛Ｒｏｋ１＿１，Ｒｏｋ１＿２，…，Ｒｏｋ１＿ｎ｝や、
平均値（Ｒｏｋ１＿１＋Ｒｏｋ１＿２＋…＋Ｒｏｋ１＿ｎ）／ｎ、などによって決定する。
【００３５】
また、閾値の上限ＲＴＴｕｂは上昇不可能ＲＴＴ１５１４に格納された往復遅延時間ＲＴＴの最小値、
ｍｉｎ｛Ｒｎｇ１＿１，Ｒｎｇ１＿２，…，Ｒｎｇ１＿ｍ｝や、
平均値（Ｒｎｇ１＿１＋Ｒｎｇ１＿２＋…＋Ｒｎｇ１＿ｍ）／ｍ、などによって決定する。
【００３６】
次に、［下限ＲＴＴｌｂ，上限ＲＴＴｕｂ］の範囲で閾値ＲＴＴｔｈを決定する。閾値ＲＴＴｔｈは、時間経過とともに下限ＲＴＴｌｂから上限ＲＴＴｕｂへ近づけていく方法を採る。これは、ビットレート上昇の試行回数を減らし、かつ、低ビットレートに停滞するのを防止するためである。
【００３７】
本来は上昇不可能であるにも関わらずビットレートを上昇させると、受信端末２での再生に途切れや乱れが生じるため、ビットレート上昇の試行はなるべく少なくすることが望ましい。一方で、試行を少なくするとビットレートを上昇可能にも関わらず上昇させずに低いビットレートのままで停滞してしまうことがある。閾値ＲＴＴｔｈを下限ＲＴＴｌｂから上限ＲＴＴｕｂへ近づけることで、初めは、往復遅延時間ＲＴＴが小さく、ネットワーク状態が非常によく、上昇させても配信できる可能性が高い場合のみビットレートを上昇させ、時間が経過するにつれてビットレート上昇を発生しやすくして低ビットレートでの停滞を防止することが可能となる。
【００３８】
具体的には、図４に示すように初期値を「ＲＴＴｔｈ＝ＲＴＴｌｂ」とし、閾値ＲＴＴｔｈを、下限ＲＴＴｌｂと上限ＲＴＴｕｂとの間で、
ＲＴＴｔｈ＝ＲＴＴｔｈ＋α（α：１回の処理での増加量）、
と変更していく方法がある。
【００３９】
または、図５に示すように
ＲＴＴｔｈ＝ＲＴＴｔｈ＋（β＾ｉ（ＲＴＴｕｂ−ＲＴＴｌｂ）） （β：０＜β＜１を満たす定数、ｉ：変更回数）、
と変更していく方法などある。
【００４０】
なお、閾値を変更する間隔、α、βはあらかじめ決定しておく。また、ここで述べた以外の方法で閾値を変更してもよい。
【００４１】
受信端末２は、ネットワークを通してストリーム配信装置１からストリームを受信するストリーム受信部２１と、受信状態をストリーム配信装置１へ通知するレポート送信部２２から構成される。
【００４２】
ストリーム受信部２１はレポート送信部２２と接続しており、ストリーム配信装置１からのストリームを受信するとともにパケットロスなどの受信状態を計測し、レポート送信部２２へ通知する。
【００４３】
レポート送信部２２は、ストリーム受信部２１から通知された受信状態の情報からなるレポートを定期的にストリーム配信装置１へフィードバックする。上述した例では、最新のレポートから求めた往復遅延時間ＲＴＴを閾値ＲＴＴｔｈと比較していた。しかし、クロストラフィックの発生などによって往復遅延時間ＲＴＴに揺らぎが発生する場合がある。この揺らぎによる影響を吸収するため、往復遅延時間ＲＴＴの移動平均を使用してもよい。
【００４４】
すなわち、受信端末２から受信したレポートのうち最新ｉ個の往復遅延時間ＲＴＴをＲ１，Ｒ２，Ｒ３，…，Ｒｉとしたとき、
ＲＴＴｍ＝（ａ１・Ｒ１＋ａ２・Ｒ２＋…＋ａｉ・Ｒｉ）／ｉ （ａ１，…，ａｉ：重み付けの係数）、とする方法である。
【００４５】
次に図３のフローチャートを参照して、本実施の形態の全体の動作について詳細に説明する。
まず、ストリームの配信開始時において、配信管理部１７は配信レート決定部１４へ配信開始を指示し、配信レート決定部１４は初期配信レート（初期のビットレート）を決定する（ステップＳ０１）。
【００４６】
次に現在配信中のビットレートから１段階上のビットレートに変更するための閾値を決定する。配信レート決定部１４は初期配信レートと１段階上のビットレートを閾値設定部１６へ通知し、閾値設定部１６は、制御履歴記憶部１５の上昇可否記憶テーブル１５１から該当するレコードを取り出す。
【００４７】
閾値設定部１６では、取り出したレコードをもとに、閾値の上限ＲＴＴｕｂと下限ＲＴＴｌｂを決定し（ステップＳ０２）、［ＲＴＴｌｂ，ＲＴＴｕｂ］の範囲から閾値ＲＴＴｔｈを決定して（ステップＳ０３）、配信レート決定部１４からの要求時に閾値ＲＴＴｔｈを通知する。
【００４８】
前述のとおり閾値ＲＴＴｔｈは、下限ＲＴＴｌｂから上限ＲＴＴｕｂへ時間経過とともに近づけていく（図４、図５を参照）。そこで、閾値設定部１６は、前回閾値ＲＴＴｔｈを変更してからの経過時間や、計測した往復遅延時間ＲＴＴｍとの比較回数をもとにして閾値ＲＴＴｔｈを必要に応じて変更する（ステップＳ０３）。
【００４９】
以下、現在配信しているコンテンツ（ストリーム）のビットレートをＢＲ１、ＢＲ１よりも１段階上のビットレートをＢＲ２、ＢＲ２よりも１段階上のビットレートをＢＲ３、ＢＲ１よりも１段階下のビットレートをＢＲ０と表す。
【００５０】
受信端末２から受信状態のレポートを受信すると、レポート受信部１３はパケットロスの有無と、往復遅延時間ＲＴＴとを配信レート決定部１４へ通知する（ステップＳ０４）。配信レート決定部１４は、まずパケットロスの有無を判定する（ステップＳ０５）。パケットロスが発生している場合には（ステップＳ０５：Ｙｅｓ）、配信レートをＢＲ１からＢＲ０へ１段階低下させ（ステップＳ０６）、ステップＳ０２へ戻る。
【００５１】
パケットロスが発生していない場合には（ステップＳ０５：Ｎｏ）、レポート受信部１３から通知された往復遅延時間ＲＴＴｍと閾値設定部１６から通知された閾値ＲＴＴｔｈを比較する（ステップＳ０７）。往復遅延時間ＲＴＴｍが閾値ＲＴＴｔｈを下回っていない場合（ステップＳ０７：Ｎｏ）にはビットレートの変更は行わずに、ステップＳ０３へ戻る。
【００５２】
往復遅延時間ＲＴＴｍが閾値ＲＴＴｔｈを下回った場合には（ステップＳ０７：Ｙｅｓ）、配信レート決定部１４は、配信レートをビットレートＢＲ１からＢＲ２へ１段階上昇することを決定し、ストリーム送信部１１は配信レートを１段階上昇させる（ステップＳ０８）。
【００５３】
配信レートを上昇後、配信レート決定部１４は上昇後のレート（ＢＲ２）で配信可能か否かを判定する（ステップＳ０９）。この判定は、前述の通り、配信レート変更後のレポートのパケットロス発生有無によって行う。
【００５４】
配信可能な場合には（ステップＳ０９：Ｙｅｓ）、上昇直前に計測した往復遅延時間ＲＴＴｍを、制御履歴記憶部１５の上昇可否記憶テーブル１５１における上昇前ビットレートがＢＲ１かつ上昇後ビットレートがＢＲ２のエントリの上昇可能ＲＴＴ１５１３に追加し（ステップＳ１２）、ステップＳ０２へ戻る。
【００５５】
一方でビットレートＢＲ２で配信できない場合には（ステップＳ０９：Ｎｏ）、上昇不可能ＲＴＴ１５１４へ往復遅延時間ＲＴＴｍを追加し（ステップＳ１０）、配信レートをＢＲ１へ戻し（ステップＳ１１）、ステップＳ０２へ戻る。
【００５６】
以上説明したように、本発明のストリーム配信装置においては、受信端末ごとに、過去のビットレート上昇試行時の往復遅延時間ＲＴＴを履歴情報として記憶し、上昇後のビットレートで配信可能であった場合の往復遅延時間ＲＴＴを使用して閾値の下限値を設定し、上昇後のビットレートで配信不可能であった場合の往復遅延時間ＲＴＴを使用して閾値の上限値を設定し、時間経過とともに閾値を下限値から上限値へ近づけてゆく。
【００５７】
これにより、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報から、受信端末とビットレートに応じた閾値を、容易かつ自動で設定できる。また、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。すなわち、閾値を大きく設定するとネットワーク状態があまり良くない場合にもビットレートを上昇させるため、上昇後のビットレートで配信できず映像に乱れや途切れの発生することが多くなる。一方、閾値を小さく設定するとビットレートを上昇可能でも上昇させず、受信端末に低品質のコンテンツを配信し続けることになる。本発明では、閾値を閾値設定範囲内において、下限値から上限値へ時間経過と共に近づけていくため、初めは上昇後のビットレートで配信できる可能性が高い場合のみビットレートを上昇させて、配信するストリーム（画像等）の乱れや途切れを防止し、時間経過とともにビットレートを上昇しやすくして停滞を防止できる。
【００５８】
なお、図１に示すストリーム配信装置１および受信端末２は、内部にＣＰＵを含むコンピュータシステムを有している。上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。また、ストリーム配信装置１はサーバ装置等で構成され、このストリーム配信装置１には、周辺機器として入力装置、表示装置等（いずれも表示せず）が接続されているものとする。ここで、入力装置としては、キーボード、マウス等の入力デバイスのことをいう。表示装置とは、ＣＲＴ（Cathode Ray Tube）や液晶表示装置等のことをいう。
【００５９】
以上、本発明の第１の実施の形態について説明したが、図１に示す本発明のストリーム配信装置は、受信端末２に配信するストリームのビットレートを上昇試行する際の受信端末２との間の往復遅延時間ＲＴＴを、受信端末２ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶部１５と、制御履歴記憶部１５に記憶された往復遅延時間ＲＴＴの履歴情報を基にしてビットレートを上昇させる際の往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを設定する閾値設定部１６と、受信端末２との間の往復遅延時間ＲＴＴが閾値ＲＴＴｔｈを下回った場合に、当該受信端末２に配信するストリームのビットレートを上昇させること判定する配信レート決定部１４と、を有して構成される。
これにより、ビットレートを上昇させるための往復遅延時間ＲＴＴの閾値ＲＴＴｔｈを、受信端末２およびビットレートごとに、過去のビットレートの上昇試行の際に計測した往復遅延時間ＲＴＴの履歴情報を基に、容易かつ自動で設定できる。
【００６０】
また、制御履歴記憶部１５は、ビットレートを上昇させる直前の受信端末２との間の往復遅延時間ＲＴＴを、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して、上昇可否記憶テーブル１５１（図２）に記憶する。
これにより、ビットレートを上昇させた際に、配信が可能であった場合の往復遅延時間ＲＴＴの情報と、配信が不可であった場合の往復遅延時間ＲＴＴを分類して記憶することができ、この履歴情報を基に、閾値ＲＴＴｔｈを容易に設定することができる。
【００６１】
また、閾値設定部１６は、制御履歴記憶部１５に記憶されたビットレート上昇後に配信可能であった往復遅延時間ＲＴＴと、ビットレート上昇後に配信不可能であった往復遅延時間ＲＴＴとを基に閾値設定範囲を決定し、該閾値設定範囲内から閾値ＲＴＴｔｈを設定する。
これにより、配信が可能であった場合の往復遅延時間ＲＴＴの履歴情報と、配信が不可であった場合の往復遅延時間ＲＴＴの履歴情報を基にして閾値設定範囲を決定し、該閾値設定範囲内から閾値ＲＴＴｔｈを設定することができる。
【００６２】
また、閾値設定部１６は、閾値設定範囲内で閾値ＲＴＴｔｈを変化させる、この場合に、閾値設定範囲内で、閾値ＲＴＴｔｈを時間経過とともに下限値から上限値へ近づくように設定変更する。
これにより、往復遅延時間ＲＴＴの閾値を動的に設定変更してビットレートの上昇試行を積極的に行うことができ、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞とを防止できる。
【００６３】
［第２の実施の形態］
次に、本発明の第２の実施の形態について図面を参照しながら説明する。
【００６４】
図６は、本発明の第２の実施の形態に係わるストリーム配信システムの構成を示す図である。図６に示すように、本発明の第２の実施の形態に係わるストリーム配信装置１Ａは、図１に示す第１の実施の形態のストリーム配信装置１と比較して、レポート受信部１３が削除され、受信端末２Ａとの間の管理セッションの情報からネットワーク状態を推定するネットワーク状態推定部１８が追加された点が異なる。他の構成は図１に示すストリーム配信装置１および受信端末１と同様である。このため、同一の構成部分には同一の符号を付している。
【００６５】
また、受信端末２Ａは、図１に示す第１の実施の形態の受信端末１と比較して、レポート送信部２２が削除され、ストリーム配信装置１Ａとの間でセッション情報をやりとりする管理情報通信部２３が追加された点が異なる。
【００６６】
この第２の実施の形態では、ストリーム配信装置１Ａの配信管理部１７と受信端末２Ａの管理情報通信部２３はコネクション型プロトコルを使用した管理セッションを接続している。コネクション型プロトコルは確認応答機能を備えており、送信側が送信したデータを受信側が受信すると、受信側から送信側へ確認応答が送信される。
【００６７】
また、受信側からデータの不着を意味する否定応答があった場合や、送信後所定時間が経過しても確認応答を受信できない場合にはデータを再送する。再送を既定回数行っても確認応答を受信できない場合には、上位レイヤに対して、送信が完了しなかったことを通知する。
【００６８】
この管理セッションでは、配信開始前に受信端末２Ａからストリーム配信装置１Ａへ配信要求を行い、配信中にはストリーム配信装置１Ａから受信端末２Ａへの死活監視に使用する。死活監視は、あらかじめ指定した間隔でストリーム配信装置１Ａから受信端末２Ａへ死活監視用データ（例えば、死活監視パケット）を送信することで行う。死活監視用データが受信端末２Ａへ到達すると、受信端末２Ａからストリーム配信装置１Ａへ確認応答が送信され、確認応答を受信したストリーム配信装置１Ａは受信端末２Ａとの間の接続が維持されていることを確認する。
【００６９】
所定回数連続して端末との接続維持が確認できなかった場合、ストリーム配信装置１Ａは受信端末２Ａが切断されたものと判定して、配信を停止する。
【００７０】
ストリーム配信装置１Ａのネットワーク状態推定部１８は、この死活監視の通信をモニタリングし、ネットワーク状態を推定する。ネットワーク状態推定部１８は、配信管理部１７から受信端末２Ａへ死活監視用データを送信した時刻を記憶しておき、確認応答を受信した時刻との差分を往復遅延時間ＲＴＴする。また、コネクション型プロトコルでの再送が発生した場合には、パケットロスが発生していると判断する。ネットワーク状態推定部１８は、この結果を配信レート決定部１４へ通知し、配信レート決定部１４では、第１の実施の形態と同様に動作する（例えば、パケットロスが発生している場合は、配信するストリームのビットレートを１段階低下させる）。
【００７１】
次に、図７のフローチャートを参照して第２の実施の形態の動作を説明する。この第２の実施の形態では、図３に示すフローチャートにおけるレポート受信部１３が受信端末２からレポートを受信するステップＳ０４が、ネットワーク状態推定部１８がネットワーク状態を推定するステップＳ１３に代わった点で第１の実施の形態と異なる。他のステップは図３に示すフローチャートと同様である。このため、同一の処理内容には同一の符号を付し、重複する説明は省略する。
【００７２】
ネットワーク状態推定部１８における往復遅延時間ＲＴＴとパケットロスの推定方法を、図８および図９のシーケンス図を使用して説明する。
【００７３】
図８は、パケットロスが発生しなかった場合のシーケンス図である。図８に示すシーケンス図を参照して、まず、ストリーム配信装置１Ａの配信管理部１７が死活監視用データを受信端末２Ａに送信する（ステップＳ１０１）。そして、ネットワーク状態推定部１８は送信時刻Ｔｓｅｎｄを記憶する（ステップＳ１０２）。
【００７４】
受信端末２Ａの管理情報通信部２３は、ストリーム配信装置１Ａから死活監視用データを受信すると（ステップＳ１０３）、ストリーム配信装置１Ａへ確認応答を送信する（ステップＳ１０４）。
【００７５】
ストリーム配信装置１Ａへ確認応答が到着した時刻をＴｒｃｖとすると、ネットワーク状態推定部１８は、「往復遅延時間ＲＴＴｍ＝Ｔｒｃｖ−Ｔｓｅｎｄ」を計算し、パケットロスが発生していないことと合わせて配信レート決定部１４へ通知する。
【００７６】
また、図９は、パケットロスが発生した場合のシーケンス図である。図９に示すシーケンス図を参照して、まず、ストリーム配信装置１Ａの配信管理部１７により、死活監視用データを受信端末２Ａへ送信する（ステップＳ２０１）。そして、ネットワーク状態推定部１８は送信時刻Ｔｓｅｎｄを記憶する（ステップＳ２０２）。
【００７７】
ストリーム配信装置１Ａの配信管理部１７は、死活監視用データ送信後、所定時間経過しても受信端末２Ａから確認応答を受信できない場合に、コネクション型プロトコルにより、死活監視用データの再送が行われる（ステップＳ２０３）。ネットワーク状態推定部１８は、再送が行われるとパケットロスが発生したことを記憶するとともに、送信時刻Ｔｓｅｎｄを再送データの送信時刻に変更する（ステップＳ２０４）。
【００７８】
受信端末２Ａの管理情報通信部２３は、ストリーム配信装置１Ａから死活監視用データを受信する（ステップＳ２０５）と、応答確認を送信する（ステップＳ２０６）。この応答確認を受信したストリーム配信装置１Ａのネットワーク状態推定部１８は、「往復遅延時間ＲＴＴｍ＝Ｔｒｃｖ−Ｔｓｅｎｄ」を計算し、パケットロスが発生したこととともに配信レート決定部１４へ通知する。
【００７９】
以上、説明したように、第２の実施の形態においては、ストリーム配信装置１Ａのネットワーク状態推定部１８により、ストリーム配信装置１Ａと受信端末２Ａとの間の死活監視通信から往復遅延時間ＲＴＴとパケットロスの有無を推定することによって、受信状態をレポートしない受信端末２Ａにおいても、過去のビットレート試行時の往復遅延時間ＲＴＴの制御履歴の情報から、受信端末とビットレートに応じた閾値を容易かつ自動で設定できる。また、第１の実施の形態と同様に、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。
【００８０】
なお、図６に示すストリーム配信装置１Ａおよび受信端末１Ａは、内部にＣＰＵを含むコンピュータシステムを有している。上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。また、ストリーム配信装置１Ａはサーバ装置等で構成され、このストリーム配信装置１Ａには、周辺機器として入力装置、表示装置等（いずれも表示せず）が接続されているものとする。ここで、入力装置としては、キーボード、マウス等の入力デバイスのことをいう。表示装置とは、ＣＲＴ（Cathode Ray Tube）や液晶表示装置等のことをいう。
【実施例１】
【００８１】
次に、具体的な実施例を用いて本発明のストリーム配信システムの動作について説明する。実施例１は、図１に示す第１の実施の形態のストリーム配信システムの具体的な例を示すものである。本実施例１においては、ストリーム配信装置１と受信端末２はインターネットを経由して接続されているものとする。
【００８２】
ストリーム配信装置１から受信端末２へのコンテンツ配信はＲＴＰ（Real-time Transport Protocol）によって行われ、受信端末２からストリーム配信装置１へのレポートの送信はＲＴＣＰ（RTP Control Protocol）によって行われる。ＲＴＰ、ＲＴＣＰともにトランスポートプロトコルには、ＵＤＰ（User Datagram Protocol）を使用する。
【００８３】
そして、ストリーム配信装置１はサーバ装置で構成される。ストリーム送信部１１は、サーバ装置のＣＰＵで実行されるプログラム（ストリーム送信部における一連処理の過程が記述されたプログラム）とネットワーク・インタフェース・カード（以下、ＮＩＣと略記）の組み合わせで実現される。このストリーム送信部１１は、コンテンツ記憶部１２から取り出したコンテンツデータを適当なサイズに分割し、分割した各データにＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダを付加したパケットを生成し、受信端末２へ向けて送信する。また、受信端末２に対して、定期的にメッセージ「ＲＴＣＰ ＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）」を送信する。本実施例１では、メッセージ「ＲＴＣＰ ＳＲ」の送信間隔を５秒とする。
【００８４】
コンテンツ記憶部１２は、サーバ装置に内蔵される磁気ディスク装置等の記憶装置であり、各映像コンテンツを複数のビットレートでエンコードして記憶しておく。本実施例１におけるコンテンツ記憶部１２は、３種類のコンテンツＡ，Ｂ，Ｃを記憶しているとする。コンテンツＡ，Ｂは、１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，８Ｍｂｐｓの各ビットレートを記憶しており、コンテンツＣは、１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，６Ｍｂｐｓ，８Ｍｂｐｓの各ビットレートを記憶している。コンテンツＡ，ＢとコンテンツＣは、コンテンツＣが６Ｍｂｐｓを記憶している点が異なっている。なお、コンテンツ記憶部１２が記憶するコンテンツは、画像でもよいし音声でもよい。
【００８５】
レポート受信部１３は、ストリーム送信部１１と同様にＣＰＵで実行されるプログラム（レポート受信部における一連の処理の過程が記述されたプログラム）とＮＩＣの組み合わせで実現され、端末からのメッセージ「ＲＴＣＰ ＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）」を受信し、パケットロス率と往復遅延時間ＲＴＴを計算して、配信レート決定部１４へ通知する。
【００８６】
パケットロス率はメッセージ「ＲＴＣＰ ＲＲ」の「ｆｒａｃｔｉｏｎ ｌｏｓｔ」フィールドまたは「ｃｕｍｕｌａｔｉｖｅ ｎｕｍｂｅｒ ｏｆ ｐａｃｋｅｔｓ ｌｏｓｔ」フィールドから求めることができる。また、往復遅延時間ＲＴＴはメッセージ「ＲＴＣＰ ＲＲ」の「ＬＳＲ」フィールドと「ＤＬＳＲ」フィールドから求めることができる。
【００８７】
配信レート決定部１４は、その一連の処理の過程が記述されたプログラムをＣＰＵが読み出して実行することにより、その機能が実現される。制御履歴記憶部１５は、サーバ装置のメインメモリの一部である。閾値設定部１６と配信管理部１７についても、その一連の処理の過程が記述されたプログラムをＣＰＵが読み出して実行することにより、その機能が実現される。
【００８８】
コンテンツ記憶部１２が上記のＡ，Ｂ，Ｃのコンテンツを記憶しているとき、制御履歴記憶部１５の上昇可否記憶テーブル１５１は、図１０に示すようになる。「上昇前ビットレートが１Ｍｂｐｓで上昇後ビットレートが２Ｍｂｐｓのエントリ」と、「上昇前ビットレートが２Ｍｂｐｓで上昇後ビットレートが４Ｍｂｐｓのエントリ」は、コンテンツＡ，Ｂ，Ｃのすべてで使用される。
【００８９】
「上昇前ビットレートが４Ｍｂｐｓで上昇後ビットレートが６Ｍｂｐｓのエントリ」と、「上昇前ビットレートが６Ｍｂｐｓで上昇後ビットレートが８Ｍｂｐｓのエントリ」は、コンテンツＣのみで使用され、「上昇前ビットレートが４Ｍｂｐｓで上昇後ビットレートが８Ｍｂｐｓのエントリ」は、コンテンツＡ，Ｂで使用される。これまでに一度も配信したことのない端末の場合、上昇可能ＲＴＴ１５１３と上昇不可能ＲＴＴ１５１４には初期値を記憶しておく。
【００９０】
本実施例１では、上昇可能ＲＴＴ１５１３の初期値を０［ｓ］、上昇不可能ＲＴＴ１５１４の初期値を１［ｓ］としている。受信端末２は、ＩＰＴＶ（Internet Protocol TeleVision）用のセット・トップ・ボックス（ＳＴＢ：Set Top Box)である。ストリーム受信部２１とレポート送信部２２は、ＣＰＵで実行されるプログラム（ストリーム送信部およびレポート送信部における一連の処理の過程が記述されたプログラム）とＮＩＣの組み合わせで実現される。
【００９１】
受信端末２内のストリーム受信部２１は、ストリーム配信装置１から配信されたパケットを受信し、ＲＴＰ、ＵＤＰ、ＩＰ、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダのデコードを行い、コンテンツのデコード部（図示せず）へ転送する。
【００９２】
ストリーム受信部２１でのＲＴＰデコード時には、メッセージ「ＲＴＣＰ ＲＲ」の送信に必要な各種データを収集し、レポート送信部２２へ通知する。また、ストリーム配信装置１から送信されるメッセージ「ＲＴＣＰ ＳＲ」を受信し、レポート送信部２２に転送する。
【００９３】
レポート送信部２２は、ストリーム受信部２１から得た情報をもとにメッセージ「ＲＴＣＰ ＲＲ」をストリーム配信装置１へ送信する。本実施例１では、メッセージ「ＲＴＣＰ ＲＲ」の送信間隔を１秒とする。なお、受信端末２は、セット・トップ・ボックス（ＳＴＢ）だけでなく、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、携帯電話端末などでもよい。
【００９４】
次に、実施例１において、ストリーム配信装置１が受信端末２からコンテンツＡの配信要求を受けた場合の動作を、図３のフローチャートを参照して、説明する。
【００９５】
配信管理部１７は、コンテンツ記憶部１２を参照し、コンテンツＡは１Ｍｂｐｓ，２Ｍｂｐｓ，４Ｍｂｐｓ，８Ｍｂｐｓで配信可能であることを配信レート決定部１４へ通知し、配信開始を指示する。配信レート決定部１４は、配信可能なビットレートの中から配信開始時のビットレート（配信レート）を決定する（ステップＳ０１）。ここでは、配信可能な最低のビットレートで配信開始する方法を採用し、１Ｍｂｐｓで配信を開始する。
【００９６】
次に配信レート決定部１４は、ビットレートを上昇させるための閾値を決定する。１Ｍｂｐｓの１段階上のビットレートは２Ｍｂｐｓなので、制御履歴記憶部１５の上昇可否記憶テーブル１５１から上昇前ビットレート１５１１が１Ｍｂｐｓ、上昇後ビットレート１５１２が２Ｍｂｐｓのエントリを抽出する。
【００９７】
次に抽出したエントリの上昇可能ＲＴＴ１５１３から閾値の下限ＲＴＴｌｂを、上昇不可能ＲＴＴ１５１４から閾値の上限ＲＴＴｕｂを決定する（ステップＳ０２）。本実施例１では、上昇可能ＲＴＴ１５１３の最大値を下限ＲＴＴｌｂ、上昇不可能ＲＴＴ１５１４の最小値を上限ＲＴＴｕｂとすると「ＲＴＴｌｂ＝０［ｓ］、ＲＴＴｕｂ＝１［ｓ］」となる。
【００９８】
次に、下限ＲＴＴｌｂと上限ＲＴＴｕｂからビットレートを上昇させるための閾値を決定する（ステップＳ０３）。本実施例１では、初期値を「ＲＴＴｔｈ＝ＲＴＴｌｂ」とし、閾値ＲＴＴｔｈが、下限ＲＴＴｌｂと上限ＲＴＴｕｂとの間で、
ＲＴＴｔｈ＝ＲＴＴｔｈ＋α（α：１回の処理での増加量）、
と変更していく方法（図４）を採用し、閾値ＲＴＴｔｈはレポートを２回受信するごとに更新し、「α＝（ＲＴＴｕｂ−ＲＴＴｌｂ）／１０」とする。このとき、閾値ＲＴＴｔｈは、図１１に示す変化をする。
【００９９】
一方、端末から図１２に示すレポートが送信されてきた場合、５回目で閾値ＲＴＴｔｈが０．２、往復遅延時間ＲＴＴｍが０．１８となり（ＲＴＴｍ＜ＲＴＴｔｈ）、ビットレートを１Ｍｂｐｓから２Ｍｂｐｓへ上昇させる（ステップＳ０８）。次に、上昇したビットレート２Ｍｂｐｓで配信可能かどうかを判定する（ステップＳ０９）。本実施例１では、ビットレートの上昇直後のレポートでパケットロスが報告された場合に配信不可と判定する。ここでは、上昇直後のレポートでパケットロスが報告されたとする（ステップＳ０９：Ｎｏ）。このとき、上昇可否記憶テーブル１５１（図１３）の上昇不可能ＲＴＴ１５１４に０．１８を追加し（ステップＳ１０）、ビットレートを１Ｍｂｐｓへ低下させ（ステップＳ１１）、ステップＳ０２へ戻る。
【０１００】
ステップＳ０２ではビットレートを再び２Ｍｂｐｓへ上昇させるための閾値の上限ＲＴＴｕｂと下限ＲＴＴｌｂを決定する。「ＲＴＴｌｂ＝０、ＲＴＴｕｂ＝０．１８」となり、閾値ＲＴＴｔｈは図１４のようになる。ビットレート１Ｍｂｐｓへ変更後、５回目の反復で往復遅延時間ＲＴＴｍが０．０３０［ｓ］となり、閾値ＲＴＴｔｈ（０．０３６［ｓ］）を下回ったとすると、再度２Ｍｂｐｓへビットレートを上昇させ、２Ｍｂｐｓで配信可能かどうかを判定する。２Ｍｂｐｓで配信開始後、最初のレポートでパケットロスが発生していないと報告された場合、２Ｍｂｐｓで配信可能と判定し、上昇可否記憶テーブル１５１の上昇可能ＲＴＴ１５１３に０．０３０［ｓ］を追加する（図１５）。
【０１０１】
その後、ステップＳ０２へ戻り、ビットレートを２Ｍｂｐｓから４Ｍｂｐｓへ上昇させるための閾値を設定する。閾値ＲＴＴｔｈは図１１と同様になる。ビットレート２Ｍｂｐｓでの配信中のレポートでパケットロスの発生が報告された場合には（ステップＳ０５：Ｙｅｓ）、ビットレートを１Ｍｂｐｓへ変更し（ステップＳ０６）、ステップＳ０２へ戻る。
【０１０２】
以上説明したように、実施例１においては、ストリーム配信装置１のレポート受信部１３は、インターネットを経由して、受信端末２が送信した受信状態のレポートを受信し、このレポートを基に、パケットロスの有無と往復遅延時間ＲＴＴを検出することによって、ビットレートの上昇試行時の往復遅延時間ＲＴＴの履歴情報を制御履歴記憶部１５に保存する。そして、過去のビットレートの上昇試行時の往復遅延時間ＲＴＴの制御履歴の情報を基に、受信端末とビットレートに応じた閾値を自動的に設定する。また、閾値ＲＴＴｔｈの設定を、閾値設定範囲の下限ＲＴＴｌｂから上限ＲＴＴｕｂに向けて動的（自ら積極的）に設定変更して行くことにより、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止する。
【実施例２】
【０１０３】
第２の実施例は、図６に示す第２の実施の形態のストリーム配信システムの具体的な例を示すものである。
前述の通り、図６に示す第２の実施の形態におけるストリーム配信装置１Ａは、図１に示す第１の実施の形態のストリーム配信装置１と比較してレポート受信部１３が削除され、受信端末２Ａとの間の管理セッションの情報からネットワーク状態を推定するネットワーク状態推定部１８が追加された点が異なる。また、受信端末２Ａは、レポート送信部２２が削除され、ストリーム配信装置１Ａとの間でセッション情報をやりとりする管理情報通信部２３が追加された点で第１の実施の形態と異なる。
【０１０４】
本実施例２における配信管理部１７とネットワーク状態推定部１８は、サーバ装置のＣＰＵで実行されるプログラム（配信管理部およびネットワーク状態推定部における一連処理の過程が記述されたプログラム）によりその機能が実現される。また、管理情報通信部２３は、セット・トップ・ボックスＳＴＢのＣＰＵで実行されるプログラムにより、その機能が実現される。また、ストリーム配信装置１Ａの配信管理部１７と受信端末２Ａの管理情報通信部２３は、ＲＴＳＰ（Real Time Streaming Protocol）によって通信し、プロトコルＲＴＳＰはトランスポートプロトコルにＴＣＰ（Transmission Control Protocol）を使用する。
【０１０５】
受信端末２Ａは、プロトコルＲＴＳＰを使用してストリーム配信装置１Ａへ配信要求を行う。ストリーム配信装置１Ａ内の配信管理部１７は、受信端末２Ａからの配信要求を受信すると、配信レート決定部１４に対して配信開始を指示する。また、配信開始後は、配信管理部１７から受信端末２ＡへＲＴＳＰセッションを使用して死活監視用パケットを送信する。受信端末２Ａの管理情報通信部２３は死活監視用パケットを受信すると、ストリーム配信装置１Ａへ応答確認を送信する。
【０１０６】
次に具体的な例を使用して、実施例２におけるネットワーク状態推定部１８の動作を説明する。図１６は、実施例２におけるネットワーク状態推定方法を示すシーケンス図であり、ストリーム配信装置１Ａと受信端末２Ａとの間の死活監視の処理の流れを示すものである。
【０１０７】
図１６を参照して、時刻０：００：００．１００（０時ちょうどの１００ミリ秒後）に受信端末２Ａへ死活監視パケットを送信したとき、ネットワーク状態推定部１８はこの時刻を記憶しておく。この死活監視パケットは時刻０：００：００．１１０に受信端末２Ａが受信し、時刻０：００：００．１１１に応答確認パケットを送信したとする。
【０１０８】
ストリーム配信装置１Ａは、応答確認パケットを時刻０：００：００．１２１に受信すると、ネットワーク状態推定部１８は、パケットロスが発生しておらず往復遅延時間ＲＴＴが２１ミリ秒（＝０：００：００．１２１−０：００：００．１００）であることを配信レート決定部１４へ通知する。
【０１０９】
その後、時刻０：００：０１．１００に次の死活監視パケットを送信したとする。この死活監視パケットが端末に到達する前にパケットロスした場合、受信端末２Ａからの確認応答が送られてこないため、一定時間経過後（図１６の例では５００ミリ秒としている）にＴＣＰによる再送が行われる。この再送が行われると、ネットワーク状態推定部１８はパケットロスが発生していると判定する。再送した死活監視パケットに対する確認応答を受信すると、ネットワーク状態推定部１８は、パケットロスが発生しており往復遅延時間ＲＴＴが６１ミリ秒（＝０：００：０１．６６１−０：００：０１．６００）であることを配信レート決定部１４へ通知する。
【０１１０】
以上説明したように、実施例２においては、ストリーム配信装置１Ａから受信端末２Ａに対し、インターネットにおけるＲＴＳＰセッションを使用して死活監視用パケットを送信することにより、ストリーム配信装置１Ａのネットワーク状態推定部１８でストリーム配信装置１Ａと受信端末２Ａとの間の往復遅延時間ＲＴＴとパケットロスの有無を推定する。これにより、受信状態をレポートしない受信端末２Ａにおいても、過去のビットレート試行時の往復遅延時間ＲＴＴの制御履歴の情報から、受信端末２Ａとビットレートに応じた閾値ＲＴＴｔｈを容易かつ自動で設定できる。また、第１の実施の形態と同様に、ビットレートの不用意な上昇と、ビットレートの上昇試行の停滞を防止できる。
【０１１１】
以上、本発明の実施の形態について説明したが、図１に示すストリーム配信装置１、および図６に示すストリーム配信装置１Ａは、前述のようにサーバ装置等で構成され、内部にコンピュータシステムを有している。そして、上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。
【０１１２】
すなわち、ストリーム配信装置１，１Ａにおける各処理は、ＣＰＵ等の中央演算処理装置がＲＯＭやＲＡＭ等の主記憶装置に上記プログラムを読み出して、情報の加工、演算処理を実行することにより、実現されるものである。
【０１１３】
ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【０１１４】
以上、本発明の実施の形態について説明したが、本発明のストリーム配信システム、およびストリーム配信装置は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【産業上の利用可能性】
【０１１５】
本発明は、インターネット上での映像配信サービスに使用するストリーム配信システムや、監視カメラで撮影した映像を監視センタへ転送する映像監視システムなどに適用できる。
【符号の説明】
【０１１６】
１，１Ａ・・・ストリーム配信装置、２，２Ａ・・・受信端末、１１・・・ストリーム送信部、１２・・・コンテンツ記憶部、１３・・・レポート受信部、１４・・・配信レート決定部、１５・・・制御履歴記憶部、１６・・・閾値設定部、１７・・・配信管理部、１８・・・ネットワーク状態推定部、２１・・・ストリーム受信部、２２・・・レポート送信部、２３・・・管理情報通信部、１５１・・・上昇可否記憶テーブル、１５１１・・・上昇前ビットレート、１５１２・・・上昇後ビットレート、１５１３・・・上昇可能ＲＴＴ、１５１４・・・上昇不可能ＲＴＴ
【特許請求の範囲】
【請求項１】
受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する、ことを特徴とするストリーム配信装置。
【請求項２】
受信端末に配信するストリームのビットレートを上昇試行する際の受信端末との間の往復遅延時間を、受信端末ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶部と、
前記制御履歴記憶部に記憶された往復遅延時間の履歴情報を基にして前記ビットレートを上昇させる際の往復遅延時間の閾値を設定する閾値設定部と、
前記受信端末との間の往復遅延時間が前記閾値を下回った場合に、当該受信端末に配信するストリームのビットレートを上昇させること判定する配信レート決定部と、
を有することを特徴とする請求項１に記載のストリーム配信装置。
【請求項３】
前記制御履歴記憶部は、ビットレートを上昇させる直前の前記受信端末との間の往復遅延時間を、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して記憶する、
ことを特徴とする請求項２に記載のストリーム配信装置。
【請求項４】
前記閾値設定部は、前記制御履歴記憶部に記憶された前記ビットレート上昇後に配信可能であった往復遅延時間と、前記ビットレート上昇後に配信不可能であった往復遅延時間とを基に閾値設定範囲を決定し、該閾値設定範囲内から前記閾値を設定する、
ことを特徴とする請求項３に記載のストリーム配信装置。
【請求項５】
前記閾値設定部は、前記配信可能であった往復遅延時間から閾値設定範囲の下限を設定し、前記配信不可能であった往復遅延時間から閾値設定範囲の上限を設定する
ことを特徴とする請求項４に記載のストリーム配信装置。
【請求項６】
前記閾値設定部は、前記閾値設定範囲内で前記閾値を変化させる、
ことを特徴とする請求項５に記載のストリーム配信装置。
【請求項７】
前記閾値設定部は、前記閾値設定範囲内で、前記閾値を時間経過とともに下限値から上限値へ近づくように設定変更する、
ことを特徴とする請求項６に記載のストリーム配信装置。
【請求項８】
前記受信端末から受信状態のレポート情報を受信するレポート受信部を有し、
前記レポート情報を基に、前記往復遅延時間とパケットロスの有無を判定する、
ことを特徴とする請求項１から７のいずれかに記載のストリーム配信装置。
【請求項９】
前記ストリーム配信装置は前記受信端末へ死活監視用データを送信すると共に、前記死活監視用データに対する確認応答を基に、往復遅延時間とパケットロスを推定するネットワーク状態推定部を有する、
ことを特徴とする請求項１から７のいずれかに記載のストリーム配信装置。
【請求項１０】
前記ストリーム配信装置が前記死活監視用データを受信端末に送信した後、当該受信端末からの確認応答を受信するまでの時間を前記往復遅延時間とし、
トランスポートプロトコルによる前記死活監視用データの再送発生を、前記パケットロス発生とする、
ことを特徴とする請求項９に記載のストリーム配信装置。
【請求項１１】
請求項１から１０のいずれかに記載のストリーム配信装置と、
複数の受信端末と、
で構成されることを特徴とするストリーム配信システム。
【請求項１２】
ネットワークを介して受信端末へストリームを配信するストリーム配信装置におけるストリーム配信方法であって、
前記ストリーム配信装置内のコンピュータにより、
受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する手順が、
行われること特徴とするストリーム配信方法。
【請求項１３】
ネットワークを介して受信端末へストリームを配信するストリーム配信装置におけるストリーム配信方法であって、
前記ストリーム配信装置内のコンピュータにより、
受信端末に配信するストリームのビットレートを上昇試行する際の受信端末との間の往復遅延時間を、受信端末ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶手順と、
前記制御履歴記憶手順により記憶された往復遅延時間の履歴情報を基にして前記ビットレートを上昇させる際の往復遅延時間の閾値を設定する閾値設定手順と、
前記受信端末との間の往復遅延時間が前記閾値を下回った場合に、当該受信端末に配信するストリームのビットレートを上昇させること判定する配信レート決定手順と、
が行われることを特徴とする請求項１２に記載のストリーム配信方法。
【請求項１４】
前記制御履歴記憶手順により、ビットレートを上昇させる直前の前記受信端末との間の往復遅延時間を、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して記憶する、
ことを特徴とする請求項１３に記載のストリーム配信方法。
【請求項１５】
前記閾値設定手順により、前記制御履歴記憶手順により記憶された前記ビットレート上昇後に配信可能であった往復遅延時間と、前記ビットレート上昇後に配信不可能であった往復遅延時間とを基に閾値設定範囲を決定し、該閾値設定範囲内から前記閾値を設定する、
ことを特徴とする請求項１４に記載のストリーム配信方法。
【請求項１６】
前記閾値設定手順により、前記配信可能であった往復遅延時間から閾値設定範囲の下限を設定し、前記配信不可能であった往復遅延時間から閾値設定範囲の上限を設定する
ことを特徴とする請求項１５に記載のストリーム配信方法。
【請求項１７】
前記閾値設定手手順により、前記閾値設定範囲内で前記閾値を変化させる、
ことを特徴とする請求項１６に記載のストリーム配信方法。
【請求項１８】
前記閾値設定手順により、前記閾値設定範囲内で、前記閾値を時間経過とともに下限値から上限値へ近づくように設定変更する、
ことを特徴とする請求項１７に記載のストリーム配信方法。
【請求項１９】
前記受信端末から受信状態のレポート情報を受信するレポート受信手順が行われ、
前記レポート情報を基に、前記往復遅延時間とパケットロスの有無を判定する、
ことを特徴とする請求項１２から１８のいずれかに記載のストリーム配信方法。
【請求項２０】
前記ストリーム配信装置は前記受信端末へ死活監視用データを送信すると共に、前記死活監視用データに対する確認応答を基に、往復遅延時間とパケットロスを推定するネットワーク状態推定手順が行われる、
ことを特徴とする請求項１２から１８のいずれかに記載のストリーム配信方法。
【請求項２１】
前記ストリーム配信装置が前記死活監視用データを受信端末に送信した後、当該受信端末からの確認応答を受信するまでの時間を前記往復遅延時間とし、
トランスポートプロトコルによる前記死活監視用データの再送発生を、前記パケットロス発生とする、
ことを特徴とする請求項２０に記載のストリーム配信方法。
【請求項２２】
請求項１２から請求項２１のいずれかに記載のストリーム配信方法における各処理の手順をストリーム配信装置内のコンピュータに実行させるためのストリーム配信プログラム。
【請求項１】
受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する、ことを特徴とするストリーム配信装置。
【請求項２】
受信端末に配信するストリームのビットレートを上昇試行する際の受信端末との間の往復遅延時間を、受信端末ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶部と、
前記制御履歴記憶部に記憶された往復遅延時間の履歴情報を基にして前記ビットレートを上昇させる際の往復遅延時間の閾値を設定する閾値設定部と、
前記受信端末との間の往復遅延時間が前記閾値を下回った場合に、当該受信端末に配信するストリームのビットレートを上昇させること判定する配信レート決定部と、
を有することを特徴とする請求項１に記載のストリーム配信装置。
【請求項３】
前記制御履歴記憶部は、ビットレートを上昇させる直前の前記受信端末との間の往復遅延時間を、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して記憶する、
ことを特徴とする請求項２に記載のストリーム配信装置。
【請求項４】
前記閾値設定部は、前記制御履歴記憶部に記憶された前記ビットレート上昇後に配信可能であった往復遅延時間と、前記ビットレート上昇後に配信不可能であった往復遅延時間とを基に閾値設定範囲を決定し、該閾値設定範囲内から前記閾値を設定する、
ことを特徴とする請求項３に記載のストリーム配信装置。
【請求項５】
前記閾値設定部は、前記配信可能であった往復遅延時間から閾値設定範囲の下限を設定し、前記配信不可能であった往復遅延時間から閾値設定範囲の上限を設定する
ことを特徴とする請求項４に記載のストリーム配信装置。
【請求項６】
前記閾値設定部は、前記閾値設定範囲内で前記閾値を変化させる、
ことを特徴とする請求項５に記載のストリーム配信装置。
【請求項７】
前記閾値設定部は、前記閾値設定範囲内で、前記閾値を時間経過とともに下限値から上限値へ近づくように設定変更する、
ことを特徴とする請求項６に記載のストリーム配信装置。
【請求項８】
前記受信端末から受信状態のレポート情報を受信するレポート受信部を有し、
前記レポート情報を基に、前記往復遅延時間とパケットロスの有無を判定する、
ことを特徴とする請求項１から７のいずれかに記載のストリーム配信装置。
【請求項９】
前記ストリーム配信装置は前記受信端末へ死活監視用データを送信すると共に、前記死活監視用データに対する確認応答を基に、往復遅延時間とパケットロスを推定するネットワーク状態推定部を有する、
ことを特徴とする請求項１から７のいずれかに記載のストリーム配信装置。
【請求項１０】
前記ストリーム配信装置が前記死活監視用データを受信端末に送信した後、当該受信端末からの確認応答を受信するまでの時間を前記往復遅延時間とし、
トランスポートプロトコルによる前記死活監視用データの再送発生を、前記パケットロス発生とする、
ことを特徴とする請求項９に記載のストリーム配信装置。
【請求項１１】
請求項１から１０のいずれかに記載のストリーム配信装置と、
複数の受信端末と、
で構成されることを特徴とするストリーム配信システム。
【請求項１２】
ネットワークを介して受信端末へストリームを配信するストリーム配信装置におけるストリーム配信方法であって、
前記ストリーム配信装置内のコンピュータにより、
受信端末に配信するストリームのビットレートを上昇させる際の受信端末との間の往復遅延時間を、受信端末およびビットレートごとに履歴情報として記憶し、この履歴情報を基にしてビットレートを上昇させる際の往復遅延時間の閾値を設定する手順が、
行われること特徴とするストリーム配信方法。
【請求項１３】
ネットワークを介して受信端末へストリームを配信するストリーム配信装置におけるストリーム配信方法であって、
前記ストリーム配信装置内のコンピュータにより、
受信端末に配信するストリームのビットレートを上昇試行する際の受信端末との間の往復遅延時間を、受信端末ごとに、かつ上昇前と上昇後のビットレートの組み合わせに関連付けて履歴情報として記憶する制御履歴記憶手順と、
前記制御履歴記憶手順により記憶された往復遅延時間の履歴情報を基にして前記ビットレートを上昇させる際の往復遅延時間の閾値を設定する閾値設定手順と、
前記受信端末との間の往復遅延時間が前記閾値を下回った場合に、当該受信端末に配信するストリームのビットレートを上昇させること判定する配信レート決定手順と、
が行われることを特徴とする請求項１２に記載のストリーム配信方法。
【請求項１４】
前記制御履歴記憶手順により、ビットレートを上昇させる直前の前記受信端末との間の往復遅延時間を、ビットレート上昇後に配信可能であった往復遅延時間と、ビットレート上昇後に配信不可能であった往復遅延時間とに分類して記憶する、
ことを特徴とする請求項１３に記載のストリーム配信方法。
【請求項１５】
前記閾値設定手順により、前記制御履歴記憶手順により記憶された前記ビットレート上昇後に配信可能であった往復遅延時間と、前記ビットレート上昇後に配信不可能であった往復遅延時間とを基に閾値設定範囲を決定し、該閾値設定範囲内から前記閾値を設定する、
ことを特徴とする請求項１４に記載のストリーム配信方法。
【請求項１６】
前記閾値設定手順により、前記配信可能であった往復遅延時間から閾値設定範囲の下限を設定し、前記配信不可能であった往復遅延時間から閾値設定範囲の上限を設定する
ことを特徴とする請求項１５に記載のストリーム配信方法。
【請求項１７】
前記閾値設定手手順により、前記閾値設定範囲内で前記閾値を変化させる、
ことを特徴とする請求項１６に記載のストリーム配信方法。
【請求項１８】
前記閾値設定手順により、前記閾値設定範囲内で、前記閾値を時間経過とともに下限値から上限値へ近づくように設定変更する、
ことを特徴とする請求項１７に記載のストリーム配信方法。
【請求項１９】
前記受信端末から受信状態のレポート情報を受信するレポート受信手順が行われ、
前記レポート情報を基に、前記往復遅延時間とパケットロスの有無を判定する、
ことを特徴とする請求項１２から１８のいずれかに記載のストリーム配信方法。
【請求項２０】
前記ストリーム配信装置は前記受信端末へ死活監視用データを送信すると共に、前記死活監視用データに対する確認応答を基に、往復遅延時間とパケットロスを推定するネットワーク状態推定手順が行われる、
ことを特徴とする請求項１２から１８のいずれかに記載のストリーム配信方法。
【請求項２１】
前記ストリーム配信装置が前記死活監視用データを受信端末に送信した後、当該受信端末からの確認応答を受信するまでの時間を前記往復遅延時間とし、
トランスポートプロトコルによる前記死活監視用データの再送発生を、前記パケットロス発生とする、
ことを特徴とする請求項２０に記載のストリーム配信方法。
【請求項２２】
請求項１２から請求項２１のいずれかに記載のストリーム配信方法における各処理の手順をストリーム配信装置内のコンピュータに実行させるためのストリーム配信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−３５７００（Ｐ２０１１−３５７００Ａ）
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願番号】特願２００９−１８０５２７（Ｐ２００９−１８０５２７）
【出願日】平成２１年８月３日（２００９．８．３）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願日】平成２１年８月３日（２００９．８．３）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]