JP2011135207A - ストリーム配信装置、方法及びプログラム - Google Patents

Abstract

【課題】受信端末からパケットロス率などのコンテンツ受信状態のフィードバックが得られない場合にも、ネットワークの輻輳状態を知る。
【解決手段】送信端末１０は、プローブパケットを定期的に受信端末２０へ送信するパケット送信部１５と、プローブパケットを受信したことを示す応答パケットを受信端末２０から受信するプローブパケット受信部１６と、制御部１７と、を備える。制御部１７は、パケット送信部１５がプローブパケットを送信してからプローブパケット受信部１６が応答パケットを受信するまでに要した往復遅延時間を計算し、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが前記可用帯域以下であると判定する。
【選択図】図１

Description

本発明は、ストリーム配信装置等に関し、特に品質非保証ネットワークで、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現するストリーム配信装置等に関する。

特許文献１に記載されているストリーム配信システムの送信端末は、コンテンツパケットとともに、ロスしたコンテンツパケットを再構成するための冗長パケットを、受信端末へ送信する。受信端末は、コンテンツパケットがロスした場合に、冗長パケットからコンテンツパケットを再構成して再生する。また、受信端末は、パケットロス率を送信端末へフィードバックする機能を持つ。送信端末は、受信端末からのフィードバック情報をもとに、ネットワークが輻輳状態であると判定したらビットレートを低減させる。また、送信する冗長パケット量を増加させることにより送信ビットレートを上昇させ、受信端末からのフィードバック情報をもとにネットワークが高いデータレートをサポートするか否かを判定する。

特許文献２には、受信した試験ストリームと同じ構成（パケットサイズ、ビットレート）の試験ストリームを送信ノード側に返送する受信ノードが、記載されている。

特許文献３には、伝送遅延時間差の増加傾向及び減少傾向から試験伝送率を求める技術が、記載されている。

特許文献４には、画像データのバッファ量の近似直線の傾きを演算し、送信レートを制御する技術が、記載されている。

特許文献５には、ストリームの送信時にビットレートを段階的に増加させる技術が、記載されている。

特開２００９−０２７７２０号公報 特開２００８−２７８２０７号公報（段落００４５〜００４７、図１） 特開２００６−０７４７７３号公報（段落００１９〜００２１、図１、図２） 特開２００５−００５８２３号公報（段落００５４〜００６０、図１０、図１２） 特開平１１−２４３３６０号公報（段落００８４、図１）

Jain and Dovrolis:a measurement tool for end-to-end available bandwidth、In Proceedings of Passive and Active Measurements Workshop、pp.14-25、2002.

しかしながら、特許文献１の技術を使用するには、受信端末から送信端末へ、パケットロス率などのコンテンツの受信状態をフィードバックする必要がある。そのため、送信端末がコンテンツ受信状態のフィードバックを得られない場合には、特許文献１の技術を使用できない。例えば、特許文献１には、ＲＴＣＰ ＲＲ（RTP(Realtime Transport Protocol) Control Protocol Receiver Report）によるパケットロス率のフィードバック方法が記載されている。しかし、ＲＴＣＰをサポートしないＳＴＢ（SetTop Box）や、ＲＴＣＰの不使用を明示したＩＰＴＶ（Internet Protocol TeleVision）プロトコルの環境では、特許文献１のフィードバック制御を実現できない。

また、特許文献２の技術では、ストリーム配信で受信ノードが「受信した試験ストリームと同じ構成（パケットサイズ、ビットレート）の試験ストリームを送信ノード側に返送する」ために、「受信したコンテンツパケットをそのまま送信ノードへ返送する」というコンテンツ受信状態のフィードバック機能が受信ノードに必要になる。そのため、そのような機能を有しない一般的な受信ノードに対しては、特許文献２の技術を使用できない。

このように、特許文献１、２の技術では、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合には、ネットワークの輻輳状態を知ることができず、その結果、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することができなかった。この課題を解決するための技術は、特許文献３〜５のどこにも開示も示唆もされていない。

そこで、本発明の目的は、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合にも、ネットワーク状態を知ることができ、その結果、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することにある。

本発明に係るストリーム配信装置は、
ネットワークを介して受信端末へストリームを送信するストリーム配信装置において、
プローブパケットを定期的に前記受信端末へ送信する送信部と、
前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する制御部と、
を備えたことを特徴とする。

本発明に係るストリーム配信方法は、
ネットワークを介して受信端末へストリームを送信するストリーム配信方法において、
プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部とを用意し、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する、
ことを特徴とする。

本発明に係るストリーム配信プログラムは、
ネットワークを介して受信端末へストリームを送信するストリーム配信装置に用いられるストリーム配信プログラムにおいて、
前記ストリーム配信装置が、プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、コンピュータとを備える場合に、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算する手段、及び、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する手段として、
前記コンピュータを機能させるためのものである。

本発明によれば、プローブパケットを送信してから応答パケットを受信するまでに要した往復遅延時間を計算し、往復遅延時間の増加傾向の有無に応じて送信レートが可用帯域を上回っているか否かを判定するようにしたので、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合でも、ネットワーク状態を知ることができる。

実施形態１の送信端末を示すブロック図である。 図１の制御部の一例を示すブロック図である。 図３［１］は送信レートが可用帯域を上回っている場合のパケットの挙動を表すタイミングチャートであり、図３［２］は送信レートが可用帯域以下である場合のパケットの挙動を表すタイミングチャートである。 コンテンツレートと送信レートとの関係を示すグラフである。 実施形態１の送信端末における全体の動作を示すフローチャートである。 実施形態１におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施形態２におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施形態３におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施例１における送信時刻と送信パケット数との関係を示す図表であり、図９［１］は配信開始時であり、図９［２］は送信レート上昇時に１回に送信するパケット数を増やした場合であり、図９［３］はパケットの送信間隔を短くした場合である。 実施例２における送信レートの変化を示す図表である。 図１１［１］は実施例３における往復遅延時間と送信レートの増加率との関係を示す図表であり、図１１［２］は実施例３における近似直線の傾きと送信レートの低下率との関係を示す図表である。

次に、発明を実施するための形態について図面を参照して詳細に説明する。図１は、本発明の実施形態１の送信端末を示すブロック図である。図２は、図１の制御部の一例を示すブロック図である。以下、これらの図面に基づき説明する。

本実施形態１における送信端末１０、パケット送信部１５及びプローブパケット受信部１６は、それぞれ特許請求の範囲における「ストリーム配信装置」、「送信部」及び「受信部」に相当する。送信端末１０は、ネットワーク２１を介して受信端末２０へストリームを送信するストリーム配信装置であり、プローブパケットを定期的に受信端末２０へ送信するパケット送信部１５と、プローブパケットを受信したことを示す応答パケットを受信端末２０から受信するプローブパケット受信部１６と、制御部１７と、を備えたことを特徴とする。制御部１７は、パケット送信部１５がプローブパケットを送信してからプローブパケット受信部１６が応答パケットを受信するまでに要した往復遅延時間を計算し、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが前記可用帯域以下であると判定する。プローブパケットは、例えばエコー要求パケットである。

送信端末１０によれば、プローブパケットを送信してから応答パケットを受信するまでに要した往復遅延時間を定期的に計測し、往復遅延時間の増加傾向の有無に応じて送信レートが可用帯域を上回っているか否かを判定するようにしたので、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末２０から得られない場合でも、ネットワーク２１の状態を知ることができる。

また、送信端末１０は、次のように構成してもよい。

制御部１７は、送信レートが可用帯域を上回っていると判定した場合に送信レートを低下させ、送信レートが可用帯域以下であると判定した場合に送信レートを上昇させる。この場合は、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することができる。

ここで、本明細書における送信レートの定義を、図４を参照して説明しておく。図４は、コンテンツレートと送信レートとの関係を示すグラフである。図４において、横軸は送信開始からの時間を表し、縦軸は累積送信データ量を表す。

通常の送信方法では、図中の破線のように、累積送信データ量は経過時間に比例する。このとき、Ａ［ｂｐｓ］のコンテンツを配信開始からｔ秒経過したときの累積送信データ量は、Ａ×ｔ［ビット］になる。一方で、送信レートをＢ［ｂｐｓ］（Ｂ≧Ａ）とした場合、送信開始からの（Ａ／Ｂ）×ｔ秒間でＡ×ｔ［ビット］のコンテンツの送信を完了し、その後の（１−（Ａ／Ｂ））×ｔ秒間は送信しないという送り方も可能である（図中の実線）。本明細書では、このときのＢを送信レートと定義する。

また、制御部１７は、次のように構成してもよい。送信レートが可用帯域を上回っていると判定した場合に、（１）ストリームの対象となるコンテンツのレートであるコンテンツレートよりも送信レートが高ければ、コンテンツレートまで前記送信レートを低下させ、（２）コンテンツレートと送信レートとが同一であれば、コンテンツレートを低下させるとともに低下後のコンテンツレートまで送信レートを低下させる。送信レートが可用帯域以下であると判定した場合に、（３）コンテンツレートよりも送信レートが高ければ、コンテンツレートを上昇させるとともに上昇後のコンテンツレートに送信レートを合わせ、（４）コンテンツレートと送信レートとが同一であれば、送信レートを上昇させる。

本実施形態１のストリーム配信方法は、送信端末１０の動作を方法の発明として捉えたものである。すなわち、本実施形態１のストリーム配信方法は、ネットワーク２１を介して受信端末２０へストリームを送信するストリーム配信方法において、プローブパケットを定期的に受信端末２０へ送信するパケット送信部１５と、プローブパケットを受信したことを示す応答パケットを受信端末２０から受信するプローブパケット受信部１６とを用意し、パケット送信部１５がプローブパケットを送信してからプローブパケット受信部１６が応答パケットを受信するまでに要した往復遅延時間を計算し、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが可用帯域以下であると判定する、ことを特徴とする。

本実施形態１のストリーム配信プログラムは、制御部１７としてコンピュータ３０（図２）を機能させるためのものである。本実施形態１のストリーム配信プログラムは、ネットワーク２１を介して受信端末２０へストリームを送信する送信端末１０に用いられる。送信端末１０は、プローブパケットを定期的に受信端末２０へ送信するパケット送信部１５と、プローブパケットを受信したことを示す応答パケットを受信端末２０から受信するプローブパケット受信部１６と、コンピュータ３０とを備える。このとき、本実施形態１のストリーム配信プログラムは、パケット送信部１５が前記プローブパケットを送信してからプローブパケット受信部１６が応答パケットを受信するまでに要した往復遅延時間を計算する手段、及び、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが可用帯域以下であると判定する手段として（すなわち制御部１７として）、コンピュータ３０を機能させるためものである。

図２に示すように、コンピュータ３０は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、バス３４、入出力インタフェース３５等を有し、パケット送信部１５、プローブパケット受信部１６等に接続される。ＣＰＵ３１は、ＲＯＭ３２又はＲＡＭ３３に記憶された本実施形態１のストリーム配信プログラムを、読み込み、解釈し、実行する。なお、後述するコンテンツパケット生成部１３などの機能も、コンピュータ３０に実現するようなストリーム配信プログラムにしてもよい。

本実施形態１のストリーム配信方法及びプログラムは、送信端末１０と同様の作用及び効果を奏するとともに、送信端末１０の構成に準じて多様な構成を採り得る。

以下、送信端末１０について、更に詳しく説明する。

図１を参照すると、本実施形態１のストリーム配信システムは、コンテンツを配信する送信端末１０と、コンテンツを受信して再生する受信端末２０とから構成される。送信端末１０と受信端末２０とは、ネットワーク２１を介して接続されている。受信端末２０は複数存在してもよい。本実施形態１の送信端末１０には、前述したパケット送信部１５、プローブパケット受信部１６及び制御部１７の他に、コンテンツ記憶部１２、コンテンツパケット生成部１３等を備える。制御部１７は、配信制御部１１及びプローブパケット生成部１４を有する。

送信端末１０は、配信制御部１１、コンテンツ記憶部１２、コンテンツパケット生成部１３、プローブパケット生成部１４、パケット送信部１５、プローブパケット受信部１６等からなる。配信制御部１１は、プローブパケット受信部１６から各プローブパケットに対する応答パケットの受信時刻を受け取り、配信するコンテンツレート及び送信レートを決定してコンテンツパケット生成部１３及びプローブパケット生成部１４へコンテンツパケット及びプローブパケットの生成を指示する。コンテンツ記憶部１２は、複数のビットレートで配信可能な形態で、コンテンツを記憶している。コンテンツパケット生成部１３は、コンテンツ記憶部１２からコンテンツデータを取り出してコンテンツパケットを生成し、生成したコンテンツパケットをパケット送信部１５へ転送する。プローブパケット生成部１４は、プローブパケットであるエコー要求パケットを生成し、これをパケット送信部１５へ転送する。パケット送信部１５は、コンテンツパケット生成部１３及びプローブパケット生成部１４で生成した各パケットをネットワーク２１へ送出する、プローブパケット受信部１６は、送信したプローブパケットに対する応答パケットを受信し、受信時刻を配信制御部１１へ通知する

ここで、本実施形態１のストリーム配信システムの動作原理を説明する。

ＩＰネットワークには、次の性質がある。送信端末１０からの送信レートが送信端末１０と受信端末２０との間の可用帯域を上回っていると、後に送信するパケットほど遅延時間が増加する。逆に、送信レートが可用帯域以下であるならば、後に送信するパケットでも遅延時間は増加しない。

図３［１］は送信レートが可用帯域を上回っている場合のパケットの挙動を表すタイミングチャートであり、図３［２］は送信レートが可用帯域以下である場合のパケットの挙動を表すタイミングチャートである。言い換えると、図３［１］は可用帯域よりも高いビットレートでパケットを送信したときのパケットの遅延を示し、図３［２］は可用帯域以下のビットレートでパケットを送信したときのパケットの遅延を示す。以下、これらの図面に基づき説明する。

図３において、縦方向が時間経過を表し、矢印はパケットを表し、矢印の密度が高いほどレートが高いことを意味する。可用帯域を上回るレートで送信したパケットは、可用帯域最小のリンク直前のルータに到着後、送信可能になるまでこのルータのキューに保存され、送信可能になると出力される。

図３［１］に示すように、送信レートが可用帯域を上回っていると、後方のパケットになるほど、キューに保存される時間が増加するため、遅延時間（送信端末１０で送信してから受信端末２０に到着するまでの時間）が大きくなる。

一方、図３［２］に示すように、送信レートが可用帯域以下である場合、送信端末１０から送信したパケットは、可用帯域最小リンク直前のルータのキューに保存されることなく、即座に送信される。そのため、送信順によらず、各パケットの遅延時間は一定になる。

すなわち、あるレートで送信したときの遅延時間に、増加傾向があれば送信レートが可用帯域を超えており、増加傾向がなければ送信レートが可用帯域以下である、と判定できる。この原理はＩＰネットワークだけでなく、パケット交換ネットワーク全般で利用できるため、本発明の対象はＩＰネットワークに限らない。本実施形態１の送信端末１０は、受信端末２０へ送信したプローブパケットの往復遅延時間に増加傾向があるか否かによって、送信レートと可用帯域との大小関係を判定し、その判定結果に基づいてコンテンツレート及び送信レートを制御する。

送信レートをコンテンツレートと異なる値にすることで、現在配信しているコンテンツレートよりも高いレートと可用帯域との大小を比較できるため、コンテンツレートを上昇させられるか否かの判定が可能になる。

次に、図５のフローチャートを参照して、本実施形態１の送信端末１０における全体の動作について詳細に説明する。以下、図１及び図５に基づき説明する。

配信開始時、配信制御部１１は、初期コンテンツレート及び送信レート並びにプローブパケットの送信間隔をそれぞれ決定し（ステップＳ１１）、コンテンツパケットの生成をコンテンツパケット生成部１３へ、プローブパケットの生成をプローブパケット生成部１４へそれぞれ指示する。初期コンテンツレート及び送信レートは、あらかじめ設定しておいた値にする方法、過去の情報をもとに決定する方法、配信可能な最低のビットレートのコンテンツを配信する方法など、いかなる方法で決定してもよい。

続いて、コンテンツパケット生成部１３は、配信制御部１１から指示されたレートのコンテンツデータをコンテンツ記憶部１２から取り出してコンテンツパケットを生成し、そのコンテンツパケットを指定された送信レートでパケット送信部１５へ転送する（ステップＳ１２）。同時に、プローブパケット生成部１４は、配信制御部１１から指示された間隔でプローブパケットを生成し、これをパケット送信部１５へ転送する（ステップＳ１２）。

続いて、パケット送信部１５は、コンテンツパケット生成部１３で生成したコンテンツパケットと、プローブパケット生成部１４で生成したプローブパケットとを、ネットワーク２１へ送出する（ステップＳ１３）。

最後に、配信制御部１１は、コンテンツレートと送信レートを決定する（ステップＳ１４）。その後、送信端末１０の動作はステップＳ１２へ戻る。

ここで、ステップ１４におけるコンテンツレート及び送信レートの決定方法を、図６のフローチャートを参照して、詳細に説明する。以下、図１及び図６に基づき説明する。

配信制御部１１は、プローブパケット受信部１６から各プローブパケットの受信時刻を受け取り（ステップＳ１４０１）、配信制御部１１が記憶している送信時刻に基づき往復遅延時間を計算する（ステップＳ１４０２）。この送信時刻は、例えば、パケット送信部１５がプローブパケットをネットワーク２１へ送出した時刻、すなわち配信制御部１１がプローブパケット生成部１４へプローブパケットの生成を指示した送信時刻である。したがって、往復遅延時間は、（往復遅延時間）＝（受信時刻）−（送信時刻）の式で得られる。

続いて、配信制御部１１は、規定数のプローブパケットを受信したら、往復遅延時間の増加傾向の有無を判定する（ステップＳ１４０３）。往復遅延時間の増加傾向の有無を判定する方法の一例として、横軸をプローブパケットの送信時刻とし、縦軸を往復遅延時間としたグラフにおいて、各送信時刻における往復遅延時間をプロットし、これらの点の近似直線を最小二乗法で求め、その傾きが規定値以上ならば増加傾向あり、規定値未満ならば増加傾向なし、と判定する方法がある。また、可用帯域推定法であるＰａｔｈｌｏａｄ（非特許文献１参照）の判定方法を使用してもよい。Ｐａｔｈｌｏａｄでは、既定数のプローブパケットの遅延時間から、ＰＣＴ（Pairwise Comparison Test)とＰＤＴ(Pairwise Difference Test）という値を計算し、これらの値をもとに増加傾向の有無を判定している。また、受信端末２０へエコー要求を送信してから規定時間が経ってもエコー応答が返ってこない場合にパケットロスと判定し、プローブパケットのパケットロス率が規定値以上ならば、送信レートが可用帯域を上回っていると判定してもよい。

これ以降の処理は、送信レートとコンテンツレートとが同一か否か（ステップＳ１４０４）と、往復遅延時間に増加傾向があるか否か（ステップＳ１４０５，Ｓ１４０６）との、次の四通りの組み合わせによって異なる。

（１）．送信レートとコンテンツレートとが同一であり、往復遅延時間に増加傾向がない場合（ステップＳ１４０４がＹｅｓ、ステップＳ１４０５がＮｏ）。この場合は、コンテンツレートの上昇可否を判定するため、コンテンツレートは変更せずに送信レートを現在のコンテンツレートよりも１段階上のコンテンツレートと同一にする（ステップＳ１４０７）。

（２）．送信レートとコンテンツレートとが同一であり、往復遅延時間に増加傾向がある場合（ステップＳ１４０４がＹｅｓ、ステップＳ１４０５がＹｅｓ）。この場合は、現在のコンテンツレートが可用帯域を上回っていると判定して、コンテンツレートを１段階下げ、送信レートを低下後のコンテンツレートと同一にする（ステップＳ１４０８）。

（３）．送信レートとコンテンツレートとが異なり（すなわち送信レートを１段階上のコンテンツレートとしている）、往復遅延時間に増加傾向がある場合（ステップＳ１４０４がＮｏ、ステップＳ１４０６がＹｅｓ）。この場合は、１段階上のコンテンツレートでは配信不可と判定して、送信レートを現在配信中のコンテンツレートと同一する（ステップＳ１４０９）。

（４）．送信レートとコンテンツレートとが異なり（すなわち送信レートを１段階上のコンテンツレートとしている）、往復遅延時間に増加傾向がない場合（ステップＳ１４０４がＮｏ、ステップＳ１４０６がＮｏ）。この場合は、１段階上のコンテンツレートで配信可能と判定して、コンテンツレートを１段階上昇させる（ステップＳ１４１０）。図６では、送信レートとコンテンツレートとが同一か否か（ステップＳ１４０４）の判定を先に、往復遅延時間に増加傾向があるか否か（ステップＳ１４０５，Ｓ１４０６）の判定を後にしているが、前述の四通りの組み合わせが得られればよいので、これらの順従は逆でもよい。

ステップＳ１４０７とステップＳ１４１０とにおいて、往復遅延時間に増加傾向がない場合にすぐに上昇させるのではなく、何回か連続して増加傾向がない場合に上昇させるようにしてもよい。また、ステップＳ１４０７において、送信レートを１段階上のコンテンツレートよりも高くして、１段階上のコンテンツレートよりも高いレートと可用帯域を比較してもよい。

これらの処理を行うことで、可用帯域に余裕がある場合にのみコンテンツレートを上昇させることができ、コンテンツレート上昇後に可用帯域不足による受信端末での再生の停止や乱れを防止できる。

次に、本実施形態１の効果を説明する。本実施形態１によれば、受信端末がコンテンツ受信機能の他にエコー要求に対して応答する機能を備えていれば、受信端末がコンテンツ受信状態のフィードバック機能を持たなくても、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現できる。インターネットで使用されているＩＰ（Internet Protocol）をサポートするほぼすべての受信端末はICMP(Internet Control Message Protocol) Echo機能を実装しているため、インターネットでのストリーム配信では、ほとんどすべての場合に本発明を利用できる。

図７は、実施形態２におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。本実施形態２は、配信制御部１１におけるコンテンツレート及び送信レートの決定方法（図５のステップＳ１４）が実施形態１と異なる。以下、本実施形態２における図５のステップＳ１４の詳細な動作を、図１及び図７を参照して詳細に説明する。

図５のステップＳ１４０１からステップＳ１４０３までの動作は、実施形態１と同一である。これ以降の処理は、往復遅延時間の増加傾向の有無によって異なる（ステップＳ１４１１）。

往復遅延時間に増加傾向がある場合（ステップＳ１４１１がＹｅｓ）には、送信レートとコンテンツレートとが同一か否かを判定する（ステップＳ１４１２）。送信レートがコンテンツレートと異なる（ステップＳ１４１２がＮｏ）場合（すなわち送信レートがコンテンツレートよりも大きい場合）には、現在の送信レートが可用帯域を超えていると判定して送信レートをコンテンツレートと同一に変更する（ステップＳ１４１４）。送信レートとコンテンツレートとが等しい（ステップＳ１４１２がＹｅｓ）場合には、現在のコンテンツレートは可用帯域を上回っていると判定して、コンテンツレートを１段階低下させ、送信レートを低下後のコンテンツレートと同一にする（ステップＳ１４１５）。

一方、往復遅延時間に増加傾向がない（ステップＳ１４１１がＮｏ）場合には、送信レートを上昇させる（ステップＳ１４１３）。ステップＳ１４１３における送信レートの上昇量は、例えば１０％上昇させるなどあらかじめ決めておく。送信レートの上昇量は、現在の送信レートからの一定割合とする以外に、５００ｋｂｐｓなどの絶対量にしてもよい。また、送信レートが１Ｍｂｐｓ以上ならば５００ｋｂｐｓ、１Ｍｂｐｓ未満ならば１００ｋｂｐｓなどと、送信レートに応じて変動させてもよい。

続いて、上昇後の送信レートと１段階上のコンテンツレートとを比較し（ステップＳ１４１６）、送信レートが１段階上のコンテンツレートを上回っていたら、１段階上のコンテンツレートで配信可能と判断して、コンテンツレートを１段階上昇させる（ステップＳ１４１７）。このとき、送信レートが１段階上のコンテンツレートを上回ったらすぐにコンテンツレートを上昇させるのではなく、送信レートが１段階上のコンテンツレートを一定割合（例えば１０％）上回ったらコンテンツレートを上昇させるとしてもよい。

これらの処理を行うことで、実施形態１と同様に可用帯域に余裕がある場合にのみコンテンツレートを上昇させることができ、コンテンツレート上昇後に可用帯域不足による受信端末での再生の停止や乱れを防止できる。

次に、本実施形態２の効果を説明する。本実施形態２では、送信レートを徐々に上昇させていくため、パケットロスが発生しにくくなる。送信レートが可用帯域を大幅に超えると、ネットワーク機器のキューを溢れさせてコンテンツパケットのロスとなるので、受信端末２０での再生に途切れや乱れが生じる可能性がある。そこで、送信レートを徐々に増加させることにより、送信レートが可用帯域を大幅に超える可能性が低くなるので、パケットロスが発生しにくくなる。

本実施形態２のその他の構成、作用及び効果は、実施形態１と同様である。

図８は、実施形態３におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。本実施形態３も、配信制御部１１におけるコンテンツレート及び送信レートの決定方法（図５のステップＳ１４）が実施形態１、２と異なる。以下、本実施形態３における図５のステップＳ１４の詳細な動作を、図１及び図８を参照して詳細に説明する。

ステップＳ１４０１からステップＳ１４１１までの動作は、実施形態２と同一である。本実施形態３では、往復遅延時間に増加傾向がないと判定した（ステップＳ１４１１がＮｏ）場合、往復遅延時間の挙動から送信レートの上昇量を決定する（ステップＳ１４２３）。

送信レートが可用帯域以下の場合でも、送信レートが可用帯域よりも大幅に小さいときと、送信レートが可用帯域に近いときとでは、往復遅延時間のばらつき傾向が異なる。例えば、送信レートが可用帯域よりも大幅に小さいときには往復遅延時間の分散が小さくなり、送信レートが可用帯域に近いといには往復遅延時間の分散が大きくなる。本実施形態３では、プローブパケットの往復遅延時間の分散が小さい場合には送信レートの上昇量を大きくし、その分散が大きい場合には送信レートの上昇量を小さくする。

また、往復遅延時間に増加傾向がある（ステップＳ１４１１がＹｅｓ）場合には、増加傾向から送信レートの低下量を決定する（ステップＳ１４２２）。

送信レートが可用帯域を大幅に上回っている場合には、実施形態１で述べた近似直線の傾きが大きくなり、プローブパケットのロスも発生しやすくなる。一方、送信レートが可用帯域を超える量が少なければ、近似直線の傾きが小さくなり、プローブパケットのロスも発生しにくくなる。本実施形態３では、プローブパケットの往復遅延時間を直線に近似した場合の傾きの大きさや、プローブパケットのロス率に応じて、送信レートの低下量を決定する。

最後に、ステップＳ１４２２及びステップＳ１４２３で決定した送信レートをもとに、ステップＳ１４２４でコンテンツレートを決定する。コンテンツレートは、配信可能なコンテンツレートの中で、送信レート以下かつ最大のものを選択することで、決定できる。

換言すると、本実施形態３における制御部１７は、送信レートを上昇させる際に、往復遅延時間のばらつき具合の大小に応じて送信レートの上昇率を変化させ、送信レートを低下させる際に、送信レートが可用帯域を上回っている量に応じて送信レートの低下率を変化させる。

次に、本実施形態３の効果を説明する。本実施形態３では、送信レートと可用帯域との大小関係だけでなく、送信レートと可用帯域とにどれだけ差があるかという情報をもとに送信レートの変動量を決定するため、可用帯域変動への追従性が向上する。

本実施形態３のその他の構成、作用及び効果は、実施形態１、２と同様である。

次に、実施形態１〜３をそれぞれ更に具体化した実施例１〜３について説明する。図９は、実施例１における送信時刻と送信パケット数との関係を示す図表であり、図９［１］は配信開始時であり、図９［２］は１回に送信するパケット数を増やした場合であり、図９［３］はパケットの送信間隔を短くした場合である。以下、図１及び図９に基づき説明する。

実施例１は、実施形態１を更に具体化した一例である。本実施例１において、送信端末１０と受信端末２０とは、ネットワーク２１としてのインターネットを経由して接続されている。送信端末１０から受信端末２０へのコンテンツ配信はＲＴＰ（Realtime Transport Protocol）によって行われ、トランスポートプロトコルにはＵＤＰ（User Datagram Protocol）を使用する。また、プローブパケットにはICMP Echoを使用する。送信端末１０から受信端末２０へはICMP Echo Requestを送信し、受信端末２０はICMP Echoを受信すると送信端末１０へはICMP Echo Replyを返答する。ICMP Echo機能は、ＩＰをサポートするほとんどすべての端末に実装されているため、本発明はほとんどすべての受信端末で使用できる。ICMP Echo以外にも、UDP Echoなどを使用してもよい。

送信端末１０はサーバ装置である。配信制御部１１、コンテンツパケット生成部１３及びプローブパケット生成部１４は、サーバ装置のＣＰＵ３１（図２）で実行するプログラムによって実現されている。コンテンツ記憶部１２は、サーバ装置に内蔵される磁気ディスク装置であり、各映像コンテンツを複数のビットレートでエンコードして記憶しておく。コンテンツは、映像以外に音声などでもよい。本実施例１では、各映像コンテンツを２Ｍｂｐｓ、４Ｍｂｐｓ、６Ｍｂｐｓでエンコードしたものを記憶しているとする。パケット送信部１５及びプローブパケット受信部１６は、サーバ装置のネットワーク・インタフェース・カードである。受信端末２０は、ＩＰＴＶ用のセット・トップ・ボックス、携帯電話端末、ＰＤＡ（Personal Digital Assistant）、ＰＣ（Personal Computer）などの、映像や音声などのメディアを受信して再生する端末であり、ICMP Echo機能を実装している。

配信開始時、送信端末１０は、初期のコンテンツレート及び配信レートを決定する。ここでは、コンテンツ記憶部１２で記憶しているものうち、最低品質のものを選択するとし、コンテンツレート及び送信レートともに２Ｍｂｐｓとする。１ＲＴＰパケットあたりのデータサイズを１０００バイトとしたとき、１秒間に送信するＲＴＰパケット数は、２５０個（＝２００００００［ｂｐｓ］／８［ｂ／Ｂ］／１０００［Ｂ／パケット］）となる。パケットの送信間隔を１０ミリ秒とすると、１回に送信するＲＴＰパケット数は２．５個（２個と３個を交互に送信）となる（図９［１］）。

このとき、コンテンツパケットの直前・直後・中間にICMP Echo Requestを送信する。
ICMP Echo Requestは、なるべくネットワーク２１の負荷にならないように、可能な限り小さいサイズにすることが望ましい。また、ICMP EchoヘッダのＩＤフィールド及びシーケンス番号フィールドを送信パケット毎に変更することにより、受信端末２０からのエコー応答受信時には、どのエコー要求に対する応答パケットであるかを識別可能にする。

ここでは、コンテンツレート及び送信レートともに２Ｍｂｐｓとした場合、往復遅延時間に増加傾向がなかったとする。送信レートとコンテンツレートとが等しく、往復遅延時間に増加傾向がない場合、１段階上のコンテンツレートで配信できるか否かを判定するため、コンテンツレートを変更せずに、送信レートを１段階上のコンテンツレートに変更する（図６のステップＳ１４０７）。本実施例１では、送信レートを４Ｍｂｐｓへ上昇させる。

送信レートを上昇させる方法として、パケットの送信間隔を変更せずに１回の送信パケット数を増加させる方法と、１回の送信パケット数を変更せずにパケットの送信間隔を変更する方法との二通りが考えられる。

前者の送信パケット数を増加させる方法について、０．１秒分（２Ｍｂｐｓコンテンツの場合には２５個）のパケットの送信レートを変更する例で考える。１回の送信パケット数を増加させる方法では、図９［２］に示すように、１０ミリ秒間隔で５個（＝２．５×（４Ｍｂｐｓ／２Ｍｂｐｓ））ずつのコンテンツパケットを送信する。そして、コンテンツパケットとともに送信したプローブパケットの増加傾向の有無に基づき、可用帯域が４Ｍｂｐｓ以上あるか否かを判定する。その結果に基づき、コンテンツレートを４Ｍｂｐｓへ上昇させるか否かを判定する。

一方、後者のパケットの送信間隔を変更する方法では、図９［３］に示すように、５ミリ秒間隔で２．５個（実際には２個と３個を交互に）のコンテンツパケットを送信する。そして、プローブパケットの往復遅延時間の増加傾向の有無に基づき、可用帯域が４Ｍｂｐｓ以上あるか否かを判定する。判定の結果、増加傾向がなければコンテンツレートを４Ｍｂｐｓへ上昇させ、増加傾向があれば送信レートを２Ｍｂｐｓへ低下させる。

一般的なストリーム配信では、コンテンツのビットレートが上昇した場合、コンテンツの送信間隔は変更せずに１回に送信するパケット数を変化させる。そのため、前者の方法を用いると、コンテンツレート上昇後と同じ送信パターンで、送信レートと可用帯域との比較が可能になる。一方、後者の方法の場合、１回の送信あたりに１個のプローブパケットを送信した場合に、より多くのプローブパケットを送信するため、多くのサンプルから送信レートと可用帯域とを比較することが可能である。

図１０は、実施例２における送信レートの変化を示す図表である。以下、図１０に基づき説明する。

実施例２は、実施形態２を更に具体化した一例である。コンテンツレート及び送信レートがともに２Ｍｂｐｓのときに往復遅延時間に増加傾向がない場合、実施例１では送信レートを４Ｍｂｐｓに増加させるのに対し、本実施例２では送信レートを徐々に増加させていく。送信レートを１０％ずつ増加させた場合の一例を図１０に示す。往復遅延時間に増加傾向がない場合には、送信レートを２．２Ｍｂｐｓ、２．４２Ｍｂｐｓ、・・・と増加させていき、この処理を９回実行すると送信レートが４Ｍｂｐｓを超えるため、コンテンツレートを４Ｍｂｐｓに変更する。

実施例２における他の構成、作用及び効果は、実施例１と同様である。

図１１［１］は実施例３における往復遅延時間と送信レートの増加率との関係を示す図表であり、図１１［２］は実施例３における近似直線の傾きと送信レートの低下率との関係を示す図表である。以下、図８及び図１１に基づき説明する。

実施例３は、実施形態３を更に具体化した一例である。実施形態３では、往復遅延時間に増加傾向がない場合の送信レートの増加率を往復遅延時間の分散に応じて決定し、往復遅延時間に増加傾向がある場合の送信レートの低下率を近似直線の傾きに応じて決定する。

送信レートの増加率は、図１１［１］に示したように決定する。図１１［１］は、往復遅延時間の分散があるしきい値ａ以下ならば送信レートを２０％増加させ、ａより大きくｂ以下ならば１０％増加させ、ｂ以上ならば５％増加させることを表す。図１１［２］は、往復遅延時間に増加傾向があるか否かを判定する際に求めた近似直線の傾きに応じて
送信レートの低下率を変化させている。

配信開始時、コンテンツレート及び送信レートがともに２Ｍｂｐｓであるとする。このとき図８のステップＳ１４１１で往復遅延時間に増加傾向がないと判定すると、送信レートの上昇量の決定ステップ（図８のステップＳ１４２３）に移る。ステップＳ１４２３では、往復遅延時間の分散をもとに送信レートの上昇量を決定する。往復遅延時間の分散ｖがａ未満の場合、送信レートを２０％上昇させた２．４Ｍｂｐｓとする。次に得られた往復遅延時間の分散ｖがｂ≧ｖ＞ａの場合には、送信レートを更に１０％上昇させた２．６４Ｍｂｐｓとする。

続いて、送信レートが２．６４Ｍｂｐｓの場合に、プローブパケットの往復遅延時間に増加傾向が表れたとする。往復遅延時間に増加傾向が表れると、近似直線の傾きｗをもとに送信レートの変動量を決定する（図８のステップＳ１４２２）。このとき、ｗ≦ｄであれば、送信レートを１０％低下させて２．３８Ｍｂｐｓとする。

実施例３における他の構成、作用及び効果は、実施例１、２と同様である。

以上、上記各実施形態及び各実施例を参照して本発明を説明したが、本発明は上記各実施形態及び各実施例に限定されるものではない。本発明の構成や詳細については、当業者が理解し得るさまざまな変更を加えることができる。また、本発明には、上記各実施形態及び各実施例の構成の一部又は全部を相互に適宜組み合わせたものも含まれる。

本発明は、例えば、インターネット上での映像配信サービスに使用する配信サーバや、テレビ会議システムなどに適用できる。

最後に、本発明の構成として特許請求の範囲に記載し得る例を、以下に付記として記載する。

（付記１）ネットワークを介して受信端末へストリームを送信するストリーム配信装置であって、
前記ストリーム配信装置の配信制御部は、
定期的に送信したプローブパケットの往復遅延時間の増加傾向の有無を判定し、
前記増加傾向がある場合には前記ストリームの送信レートが可用帯域を上回っていると判定し、前記増加傾向がない場合には前記送信レートが可用帯域以下であると判定する、
ことを特徴とするストリーム配信装置。

（付記２）付記１に記載のストリーム配信装置であって、
前記送信レートをコンテンツレートよりも高く設定し、
前記プローブパケットの往復遅延時間の増加傾向の有無を判定することにより、前記コンテンツレートよりも高いレートと可用帯域との比較を行う、
ことを特徴とするストリーム配信装置。

（付記３）付記２に記載のストリーム配信装置であって、
コンテンツパケットの各送信時刻における送信パケット数を増加させることにより、前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。

（付記４）付記２に記載のストリーム配信装置であって、
コンテンツパケットの送信間隔を短縮することにより、前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。

（付記５）付記３又は４に記載のストリーム配信装置であって、
前記コンテンツパケットの送信時にプローブパケットを送信する、
ことを特徴とするストリーム配信装置。

（付記６）付記１乃至５のいずれか一つに記載のストリーム配信装置であって、
前記プローブパケットがエコー要求パケットである、
ことを特徴とするストリーム配信装置。

（付記７）付記１乃至６のいずれか一つに記載のストリーム配信装置であって、
前記送信レートが可用帯域を上回っていると判定した場合に前記送信レートを低下させる、
ことを特徴とするストリーム配信装置。

（付記８）付記１乃至７に記載のストリーム配信装置であって、
前記送信レートが可用帯域以下と判定した場合に前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。

（付記９）付記７に記載のストリーム配信装置であって、
前記送信レートが可用帯域を上回っていると判定した場合に、
前記送信レートがコンテンツレートよりも高ければ、前記送信レートを前記コンテンツレートと同一のレートへ低下させ、
前記送信レートと前記コンテンツレートとが同一であるならば、前記コンテンツレートを現在配信しているものから１段階低下させ、前記送信レートを低下後の前記コンテンツレートと同一にする、
ことを特徴とするストリーム配信装置。

（付記１０）付記７に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域を上回っていると判定した場合に、前記送信レートが前記可用帯域を上回っている量に応じて前記送信レートの低下率を変化させる、
ことを特徴とするストリーム配信装置。

（付記１１）付記８に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、
前記送信レートとコンテンツレートが同一であるならば、前記送信レートを現在配信しているものから１段階上の前記コンテンツレートと同一にし、
前記送信レートが現在配信しているものから１段階上の前記コンテンツレートと同一であるならば、前記コンテンツレートを１段階上昇させる、
ことを特徴とするストリーム配信装置。

（付記１２）付記８に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、前記送信レートを既定量上昇させる、
ことを特徴とするストリーム配信装置。

（付記１３）付記８に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、前記プローブパケットの前記往復遅延時間のばらつき具合の大小に応じて前記送信レートの上昇率を変化させる、
ことを特徴とするストリーム配信装置。

（付記１４）付記１乃至１３のいずれか一つに記載のストリーム配信装置を有する、
ことを特徴とするストリーム配信システム。

１０ 送信端末（ストリーム配信装置）
１１ 配信制御部
１２ コンテンツ記憶部
１３ コンテンツパケット生成部
１４ プローブパケット生成部
１５ パケット送信部（送信部）
１６ プローブパケット受信部（受信部）
１７ 制御部
２０ 受信端末
２１ ネットワーク（インターネット）
３０ コンピュータ
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ バス
３５ 入出力インタフェース

Claims (10)

1. ネットワークを介して受信端末へストリームを送信するストリーム配信装置において、
   プローブパケットを定期的に前記受信端末へ送信する送信部と、
   前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、
   前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する制御部と、
   を備えたことを特徴とするストリーム配信装置。
2. 請求項１記載のストリーム配信装置において、
   前記制御部は、前記送信レートが前記可用帯域を上回っていると判定した場合に前記送信レートを低下させる
   ことを特徴とするストリーム配信装置。
3. 請求項２記載のストリーム配信装置において、
   前記制御部は、前記送信レートを低下させる際に、前記送信レートが前記可用帯域を上回っている量に応じて前記送信レートの低下率を変化させる、
   ことを特徴とするストリーム配信装置。
4. 請求項２又は３記載のストリーム配信装置において、
   前記制御部は、
   前記送信レートが前記可用帯域を上回っていると判定した場合に、
   前記ストリームの対象となるコンテンツのレートであるコンテンツレートよりも前記送信レートが高ければ、前記コンテンツレートまで前記送信レートを低下させ、
   前記コンテンツレートと前記送信レートとが同一であれば、前記コンテンツレートを低下させるとともに低下後の前記コンテンツレートまで前記送信レートを低下させる、
   ことを特徴とするストリーム配信装置。
5. 請求項１乃至４のいずれか一項記載のストリーム配信装置において、
   前記制御部は、前記送信レートが前記可用帯域以下であると判定した場合に前記送信レートを上昇させる、
   ことを特徴とするストリーム配信装置。
6. 請求項５記載のストリーム配信装置において、
   前記制御部は、前記送信レートを上昇させる際に、前記往復遅延時間のばらつき具合の大小に応じて前記送信レートの上昇率を変化させる、
   ことを特徴とするストリーム配信装置。
7. 請求項５又は６記載のストリーム配信装置において、
   前記制御部は、
   前記送信レートが前記可用帯域以下であると判定した場合に、
   前記コンテンツレートよりも前記送信レートが高ければ、前記コンテンツレートを上昇させるとともに上昇後の前記コンテンツレートに前記送信レートを合わせ、
   前記コンテンツレートと前記送信レートとが同一であれば、前記送信レートを上昇させる、
   ことを特徴とするストリーム配信装置。
8. 請求項１乃至７のいずれか一項記載のストリーム配信装置において、
   前記プローブパケットがエコー要求パケットである、
   ことを特徴とするストリーム配信装置。
9. ネットワークを介して受信端末へストリームを送信するストリーム配信方法において、
   プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部とを用意し、
   前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する、
   ことを特徴とするストリーム配信方法。
10. ネットワークを介して受信端末へストリームを送信するストリーム配信装置に用いられるストリーム配信プログラムにおいて、
    前記ストリーム配信装置が、プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、コンピュータとを備える場合に、
    前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算する手段、及び、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する手段として、
    前記コンピュータを機能させるためのストリーム配信プログラム。

Images