(57)【特許請求の範囲】
【請求項１】
パケット交換網における輻輳回避のためのフロー制御システムであって、
送信ノードは、
輻輳の状態に応じて新たな送信パケットレートを決定する制御手段と、
前記新たな送信パケットレートに合わせて送信すべきデータを生成するデータ生成手段と、
前記データ生成手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、
を含んで構成され、
前記パケット交換網において輻輳が検知された場合に、前記制御手段は、
前記新たな送信パケットレートを算出した後、前記データ生成手段に通知し、
前記データ生成手段からの変更承認を待ち、
承認後に前記新たな送信パケットレートを前記送信手段に指示する、
ことを特徴とするフロー制御システム。
【請求項２】
パケット交換網における輻輳回避のためのフロー制御システムであって、
送信ノードは、
前記パケット交換網における輻輳を検知する輻輳検知手段と、
前記輻輳検知手段によって検知される輻輳の状態に応じて、送信パケットレートについて減速を行うことを決定し、新たな送信パケットレートを算出する制御手段と、
前記制御手段によって算出された新たな送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成手段と、
前記データ生成手段の出力を蓄えるバッファ手段と、
前記バッファ手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、
前記送信手段から供給される前記パケットデータを、前記パケット交換網経由で受信ノード宛に送信し、前記受信ノードから前記パケット交換網経由で送信されるパケットを、前記輻輳検知手段に供給するパケット処理手段を含んで構成され、
前記制御手段は、
減速を行う場合には、減速された新たな送信パケットレートを算出して前記データ生成手段に通知し、
前記データ生成手段は、
前記減速された新たな送信パケットレートを通知された際に、前記バッファ手段に蓄積されたデータ量と現在の送信パケットレートとから待ち時間を算出して前記制御手段に指示し、
前記制御手段は、
前記待ち時間が経過した後に、前記減速された新たな送信パケットレートを前記送信手段に指示することを特徴とするフロー制御システム。
【請求項３】
パケット交換網における輻輳回避のためのフロー制御システムであって、
送信ノードは、
前記パケット交換網における輻輳を検知する輻輳検知手段と、
前記輻輳検知手段によって検知される輻輳の状態に応じて、送信パケットレートについて減速を行うことを決定し、新たな送信パケットレートを算出する制御手段と、
前記制御手段によって算出された新たな送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成手段と、
前記データ生成手段の出力を蓄えるバッファ手段と、
前記バッファ手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、
前記送信手段から供給される前記パケットデータを、前記パケット交換網経由で受信ノード宛に送信し、前記受信ノードから前記パケット交換網経由で送信されるパケットを、前記輻輳検知手段に供給するパケット処理手段を含んで構成され、
前記制御手段は、
減速を行う場合には、減速された新たな送信パケットレートを算出して前記データ生成手段に通知し、
前記データ生成手段は、
前記減速された新たな送信パケットレートの通知を受けた際、減速可能になるまで待ってから、減速承認を前記制御手段に通知し、
前記制御手段は、
前記減速承認の通知を受けるまで待ってから、前記減速された新たな送信パケットレートを前記送信手段に指示することを特徴とするフロー制御システム。
【請求項４】
前記データ生成手段は、
前記減速された新たな送信パケットレートを通知された際に、前記バッファ手段に蓄積されているデータ量を測定し、通知以降にそのデータ量以上のデータが前記バッファ手段から出力されるまで待った後に、前記減速承認を前記制御手段に通知することを特徴とする請求項３記載のフロー制御システム。
【請求項５】
前記データ生成手段は、読み出し手段と複数の記憶手段とを含んで構成され、
前記複数の記憶手段は、各々異なるビットレートで符号化され、かつ所定の時間間隔毎に切替点を有するデータを記憶し、
前記読み出し手段は、
前記複数の記憶手段の中の１つの記憶手段からデータをそのデータが符号化されたビットレートで読み出して、前記バッファ手段に蓄積していくものであり、
読み出しているデータが切替点に達する毎に、前記新しい送信パケットレートが通知されたかどうかを確認し、
通知されている場合には、前記複数の記憶手段の中から、前記新しい送信パケットレートに合う記憶手段を選択すると共に、前記新しい送信パケットレートが前記減速された新たな送信パケットレートだった場合には、前記バッファ手段に蓄積されたデータ量を測定し、
通知以降にそのデータ量以上のデータが前記バッファ手段から出力されるまで待った後に、前記減速承認を前記制御手段に通知する、
ことを特徴とする請求項３記載のフロー制御システム。
【請求項６】
前記送信手段は、
送信するべき各パケットに一連のシーケンス番号を付与し、
前記受信ノードは、
前記一連のシーケンス番号が付与された受信パケットの総数と、前記一連のシーケンス番号が付与された受信パケットの中で最後の受信パケットのシーケンス番号の情報を含めて応答パケットを生成すると共に、前記応答パケットを前記送信ノードに転送し、
前記輻輳検知手段は、
前記受信パケットの総数と前記最後の受信パケットのシーケンス番号の差分の変化から輻輳を検知することを特徴とする請求項２から５のいずれか１つに記載のフロー制御システム。
【請求項７】
送信するべき各パケットが、前記パケット交換網を構成する中継ノードにおいて輻輳状態である場合に、輻輳状態であることをセット可能な輻輳表示情報を持ち、
前記送信手段は、
前記輻輳表示情報をクリアして各パケットを送信し、
前記受信ノードは、
前記輻輳表示情報がセットされたパケットの総数の情報を含めて応答パケットを生成すると共に、前記応答パケットを前記送信ノードへ転送し、
前記輻輳検知手段は、
前記総数の変化から輻輳を検知することを特徴とする請求項２から５のいずれか１つに記載のフロー制御システム。
【請求項８】
前記送信手段は、
前記バッファ手段が空の場合には、空のパケットを前記パケット処理手段に供給することを特徴とする請求項２から７のいずれか１つに記載のフロー制御システム。
【請求項９】
パケット交換網における輻輳回避のためのフロー制御方法であって、
前記パケット交換網における輻輳を検知する輻輳検知ステップと、
前記輻輳検知ステップによって検知される輻輳の状態に応じて、送信パケットレートについて減速を行うことを決定し、新たな送信パケットレートを算出する制御ステップと、
指定された送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成ステップと、
前記生成され出力されたデータをバッファに蓄えるステップと、
前記バッファからデータを引き出し、指定されたパケットレートでパケット化し、パケットデータを前記パケット交換網経由で受信ノード宛に送信する送信ステップと、
を含み、
前記制御ステップで減速した場合には、前記新たな送信パケットレートを前記データ生成ステップにおけるパケットレートに指定し、
前記バッファに蓄積されたデータ量と現在の送信パケットレートとから待ち時間を算出し、
前記待ち時間が経過した後に、前記新たな送信パケットレートを前記送信ステップにおけるパケットレートに指定する、
ことを特徴とするフロー制御方法。
【請求項１０】
パケット交換網における輻輳回避のためのフロー制御方法であって、
前記パケット交換網における輻輳を検知する輻輳検知ステップと、
前記輻輳検知ステップによって検知される輻輳の状態に応じて、送信パケットレートについて減速を行うことを決定し、新たな送信パケットレートを算出する制御ステップと、
指定された送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成ステップと、
前記生成され出力されたデータをバッファに蓄えるステップと、
前記バッファからデータを引き出し、指定されたパケットレートでパケット化し、パケットデータを前記パケット交換網経由で受信ノード宛に送信する送信ステップと、
を含み、
前記制御ステップで減速した場合には、前記データ生成ステップにおけるパケットレートに前記新たな送信パケットレートを指定し、前記データ生成ステップは減速可能になるまで待ってから減速承認を行い、
前記制御ステップは前記減速承認を受けるまで待ってから、前記送信ステップにおけるパケットレートを前記新たな送信パケットレートに指定する、
ことを特徴とするフロー制御方法。
【請求項１１】
パケット交換網における輻輳回避のためのフロー制御システムであって、
送信ノードは、
前記パケット交換網における輻輳を検知する輻輳検知手段と、
前記輻輳検知手段によって検知される輻輳の状態に応じて、新たな送信パケットレートを算出する制御手段と、
指定されたパケットレートに合わせて送信すべきデータを生成して出力するデータ生成手段と、
前記データ生成手段の出力を蓄えるバッファ手段と、
前記バッファ手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、
前記送信手段から供給される前記パケットデータを、前記パケット交換網経由で受信ノード宛に送信し、前記受信ノードから前記パケット交換網経由で送信されるパケットを、 前記輻輳検知手段に供給するパケット処理手段を含んで構成され、
前記制御手段は、
前記新たな送信パケットレートを算出した場合、まず前記データ生成手段に指示し、
前記バッファ手段に蓄積されたデータ量と現在の送信パケットレートとから待ち時間を算出し、
前記待ち時間が経過した後に、前記新たな送信パケットレートを前記送信手段に指示する、
ことを特徴とするフロー制御システム。
【請求項１２】
パケット交換網における輻輳回避のためのフロー制御システムであって、
送信ノードは、
前記パケット交換網における輻輳を検知する輻輳検知手段と、
前記輻輳検知手段によって検知される輻輳の状態に応じて、新たな送信パケットレートを算出する制御手段と、
指定されたパケットレートに合わせて送信すべきデータを生成して出力するデータ生成手段と、
前記データ生成手段の出力を蓄えるバッファ手段と、
前記バッファ手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、
前記送信手段から供給される前記パケットデータを、前記パケット交換網経由で受信ノード宛に送信し、前記受信ノードから前記パケット交換網経由で送信されるパケットを、前記輻輳検知手段に供給するパケット処理手段を含んで構成され、
前記制御手段は、
前記新たな送信パケットレートを算出した場合、まず前記データ生成手段に指示し、
前記データ生成手段からの変更承認を待ち、
承認後に前記新たな送信パケットレートを前記送信手段に指示する
ことを特徴とするフロー制御システム。
【請求項１３】
パケット交換網における輻輳回避のためのフロー制御方法であって、
前記パケット交換網における輻輳を検知する輻輳検知ステップと、
前記輻輳検知ステップによって検知される輻輳の状態に応じて、新たな送信パケットレートを算出する制御ステップと、
指定されたパケットレートに合わせて送信すべきデータを生成して出力するデータ生成ステップと、
前記生成され出力されたデータをバッファに蓄えるステップと、
前記バッファからデータを引き出し、指定されたパケットレートでパケット化し、パケットデータを前記パケット交換網経由で受信ノード宛に送信する送信ステップと、
を含み、
前記制御ステップは、前記新たな送信パケットレートを算出した場合、
まず前記データ生成ステップにおけるパケットレートに指定し、
前記バッファに蓄積されたデータ量と現在の送信パケットレートとから待ち時間を算出し、
前記待ち時間が経過した後に、前記新たな送信パケットレートを前記送信ステップにおけるパケットレートに指定する、
ことを特徴とするフロー制御方法。
【請求項１４】
パケット交換網における輻輳回避のためのフロー制御方法であって、
前記パケット交換網における輻輳を検知する輻輳検知ステップと、
前記輻輳検知ステップによって検知される輻輳の状態に応じて、新たな送信パケットレートを算出する制御ステップと、
前記新たな送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成ステップと、
前記生成され出力されたデータをバッファに蓄えるステップと、
前記バッファからデータを引き出し、指定されたパケットレートでパケット化し、パケットデータを前記パケット交換網経由で受信ノード宛に送信する送信ステップと、
を含み、
前記制御ステップは、前記新たな送信パケットレートを算出した場合、
まず前記データ生成ステップにおけるパケットレートに指定し、
前記データ生成ステップからの変更承認を待ち、
承認後に前記新たな送信パケットレートを前記送信ステップにおけるパケットレートに指定する、
ことを特徴とするフロー制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パケット交換網に接続された通信プロトコル処理を実行するノードに対する輻輳回避のためのフロー制御システムに関する。
【０００２】
【従来の技術】
現在、インターネットプロトコル（ＩＰ）を用いたパケット交換網（ＩＰ網）が広く用いられている。ＩＰ網では、送信ノードと受信ノードのエンドツーエンドで輻輳回避を行っている。すなわち、ＯＳＩ参照モデルのトランスポートレイヤであるプロトコルレイヤ４において、ＴＣＰのフロー制御によって輻輳回避を実現している。ＴＣＰとは、バーチャルサーキット（ＶＣ）に基づいてデータを転送するコネクション指向型の転送プロトコルである。ＴＣＰのフロー制御では、ウインドウ制御方式を用いている。そこでは、送信ノードが網内でのパケットロスを検出すると、その原因を輻輳であると判断し、送信データ量（輻輳ウインドウ）を半分に削減する。輻輳ウインドウとは、ネットワークの転送能力を推定した値である。
【０００３】
より効率的な輻輳制御のため、輻輳の兆候を明示的に通知するＥＣＮ（Ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎ）が提案されている。ＥＣＮは各パケットに輻輳表示情報を持たせており、網内の中継ノードが輻輳の兆候を捉えて（中継ノードの送信バッファ占有量が大きくなったら）、この情報をセットする。受信ノードは、このような輻輳情報がセットされたパケットを送信ノードに送り返す。これによって、送信ノードはパケットロスの場合と同様に輻輳ウインドウを半分に削減する。ＴＣＰの動作については特許第３００３０９５号公報においても解説されている。参考文献には、Ｗ.Ｒ.Ｓｔｅｖｅｎｓ著のＴＣＰ  Ｉｌｌｕｓｔｒａｔｅｄ  Ｖｏｌ.1（Ａｄｄｉｓｏｎ  Ｗｅｓｌｅｙ、１９９４）の２１章や、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）のＲｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）の２００１や２４８１などがある。尚、上記特許第３００３０９５号公報においては、パケット紛失／廃棄の原因が輻輳でなく回線誤りによるものである場合に、不要な輻輳ウインドウ削減を回避する方法が開示されている。また、特開２０００−１１５２３９号公報においては、輻輳状態を監視しつつ、パケット毎に管理される優先度が低い通信のパケット再送を制御する手段が開示されている。
【０００４】
ＩＰ網は元々データ伝送用のネットワークであるが、近年、音声や画像などのストリームデータのリアルタイム伝送（ストリーミング）が行われるようになってきた。最も簡単なストリーミングは固定ビットレートで符号化したストリームデータの伝送である。ストリーミングに適した伝送プロトコルとしてＲＴＰ（ＩＥＴＦ  ＲＦＣ  １８８９）が知られているが、ＲＴＰは輻輳回避の機能を持たない。そのため、網の容量以上に伝送しようとすると輻輳が発生し、パケットロスが多発する。輻輳が継続している期間には、音声が途切れ画像が崩れるだけでなく、ＴＣＰによるデータ転送もできなくなる。ＴＣＰは輻輳を検出すると輻輳ウインドウを半分にするが、ＲＴＰにより輻輳が継続するとＴＣＰの送信できるデータが指数的に減少し（半減を繰り返し）、ほとんど零となってしまうからである。
【０００５】
一方、伝送プロトコルにＴＣＰを用いる場合、網の状態に合わせて送信ビットレートが変化するため、伝送完了までにかかる時間が不定となる。ファイル転送であれば単に転送完了までの待ち時間が長くなるだけで、品質には影響を及ぼさない（最終的に受信側に内容の全てが受け渡されれば品質に問題は生じない）。しかし、ストリーミングでは時々再生が途中で停止し、品質が大きく損なわれるという問題が生じる（時間的な要素が重要となる）。すなわち、ストリーミングの場合は、輻輳を回避するだけでなく、予定された時間的な連続性を維持して送信が行われる必要がある（そうしなければ、再生途中で停止され、品質に悪影響を及ぼす）。
【０００６】
ストリーミングで輻輳回避を行いつつ、再生途中の停止をなるべく避ける方法が提案されている。符号化ビットレートの異なる複数のストリームデータを用意しておき、網の状態に合わせて切り替えて送信するという方式である。以後、これをストリーム切替方式と呼ぶ。一般にストリームデータは単純に途中で切り替えることが出来ないため、ストリーム切替方式では、同期した所定の時間間隔（例えば１秒間隔）にストリームデータを切り替えられる点（切替点）をストリームデータ毎に用意している。例えば、特開２０００−８３０２９号公報においては、ストリーム切替方式の一種であってＡＴＭ網を用いたＶＯＤシステムの構成例が開示されている。ここでは、ＡＴＭ網の機能を用いてリソースの確保と輻輳情報の取得を行い、切替点で送信するストリームデータを切り替えると共に、送信パケットレートを更新している。しかし、ＩＰ網では網自体にこのような機能は無く、エンドツーエンドで輻輳回避を行っているために、特開２０００−８３０２９号公報に開示された技術をＩＰ網でそのまま適用することは出来ない。
【０００７】
ＩＰ網上でストリーム切替方式を実現する場合、ＴＣＰの送信ビットレートを推定し、それに合わせてストリームデータを選択して送信する。しかし、ウインドウ制御方式では輻輳ウインドウを制御しているために送信ビットレートが直接定まらない。また、パケット毎に異なる網内での遅延時間がそのまま送信ビットレートの変動につながっている。そのため、アプリケーションは、実際に送信できたデータ量を測定し、ある時間で平均化した平均送信ビットレートを算出し、それを今後の送信ビットレートの推定値として用いている。ここで、切替点が所定の時間間隔毎にしか存在しないため、必ずしも連続再生は保証されないという問題がある。例えば、ＴＣＰの平均送信ビットレートが１Ｍｂｐｓで、これに合わせて１Ｍｂｐｓ（１０００Ｋｂｐｓ）のストリームデータを送信していたとする。この時突然、平均送信ビットレート１００Ｋｂｐｓに変化したとする。次の切替点まで０．５秒分のストリームデータ（５００Ｋビット）が残っていたとすると、５００Ｋビットを１００Ｋｂｐｓで送ることになり（送信に５秒要することになり）、４．５秒の遅延が余計に発生する。つまり再生が４．５秒間停止してしまう。
【０００８】
この再生途中の停止という問題は、アプリケーションとしてリアルタイムで符号化できる符号化手段を用いた場合にも存在する。一般に符号化手段は出力ビットレートを平滑化するために内部に（例えば最大０．５秒分の）バッファを持っている。そのため、すでにバッファ内に存在する生成済みの符号列は符号化時点のビットレートで出力される必要がある。例えば、ＴＣＰの送信ビットレートが２００Ｋｂｐｓで、バッファに符号化された１００Ｋビットの符号列が存在していた場合、バッファの内容は０．５秒で出力される必要がある。しかし、ＴＣＰの送信ビットレートが突然１００Ｋｂｐｓに変化すると、出力に要する時間が１秒に変化する。受信ノードから見ると、遅延が突然０．５秒増えるため、再生が０．５秒間停止してしまう。
【０００９】
この問題への対策として、受信ノードで長時間（例えば１０秒以上）の再生遅延バッファを持つという方法がある。送信ビットレートの変動による遅延がこの範囲内であれば、再生途中の停止を回避することができ、連続再生できる確率を高くできる。そのため、ＴＣＰを伝送プロトコルに用いたストリーミングでは一般に大きな遅延バッファが用いられている。ただし、連続再生できる確率は高くできるものの、再生途中の停止がなくなるわけではなく、テレビ電話のような会話型のアプリケーションを実行するのは困難である。
【００１０】
【発明が解決しようとする課題】
上述したように、これまでの技術では輻輳回避を行うと再生が途中で停止するという問題があった。また連続再生できる確率を高くするためには、受信側において、大きな再生遅延バッファを挿入する必要があった。そのため、高品質なストリーミングをあきらめるか、そもそもストリーミング用の帯域をネットワーク設計の時点で予め確保しておく必要があった（輻輳が発生しないような設計を行う必要があった）。
【００１１】
【課題を解決するための手段】
上記課題を解決するために、請求項１に記載されたフロー制御システムの送信ノードは、輻輳の状態に応じて新たな送信パケットレートを決定する制御手段と、前記新たな送信パケットレートに合わせて送信すべきデータを生成するデータ生成手段と、前記データ生成手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、を含んで構成され、パケット交換網において輻輳が検知された場合に、前記制御手段は、前記新たな送信パケットレートを算出した後、前記データ生成手段に通知し、前記データ生成手段からの変更承認を待ち、承認後に前記新たな送信パケットレートを前記送信手段に指示する、ことを特徴とする。フロー制御システムの送信ノードは、前記パケット交換網における輻輳を検知する輻輳検知手段と、前記輻輳検知手段によって検知される輻輳の状態に応じて、送信パケットレートについて減速を行うことを決定し、新たな送信パケットレートを算出する制御手段と、前記制御手段によって算出された新たな送信パケットレートに合わせて送信すべきデータを生成して出力するデータ生成手段と、前記データ生成手段の出力を蓄えるバッファ手段と、前記バッファ手段からデータを引き出し、指定されたパケットレートでパケット化する送信手段と、前記送信手段から供給される前記パケットデータを、前記パケット交換網経由で受信ノード宛に送信し、前記受信ノードから前記パケット交換網経由で送信されるパケットを、前記輻輳検知手段に供給するパケット処理手段を含んで構成される。
【００１２】
本発明の第１の側面によれば、制御手段は、減速を行う場合には、減速された新たな送信パケットレートを算出して前記データ生成手段に通知し、データ生成手段は、減速された新たな送信パケットレートを通知された際に、バッファ手段に蓄積されたデータ量と現在の送信パケットレートとから待ち時間を算出して前記制御手段に指示し、前記制御手段は、前記所定の待ち時間が経過した後に、前記減速された新たな送信パケットレートを前記送信手段に指示する。
【００１３】
本発明の第２の側面によれば、制御手段は、減速を行う場合には、減速された新たな送信パケットレートを算出して前記データ生成手段に通知し、前記データ生成手段は、前記減速された新たな送信パケットレートの通知を受けた際、減速可能になるまで待ってから、減速承認を前記制御手段に通知し、前記制御手段は、前記減速承認の通知を受けるまで待ってから、前記減速された新たな送信パケットレートを前記送信手段に指示する。
【００１４】
本発明は、輻輳回避と同時に連続再生を目的とするものであって、特にＩＰ網での利用が有効であるが、その他のパケット交換網でも適用可能である。また、画像や音声のストリームデータのリアルタイム伝送（ストリーミング）における画像停止等の問題に対して特に有効であるが、その他のデータについても適用可能である。
【００１５】
【発明の実施の形態】
本発明の第１の実施形態について説明する。図１は本発明のフロー制御システムが適用されるストリームデータ伝送システムのブロック図である（後述の第２の実施形態でも同じ構成である）。図１において、送信ノード１と受信ノード２は複数の中継ノード３，４からなる通信網５を介して接続されており、送信ノード１から受信ノード２へストリームデータが伝送される。
【００１６】
送信ノード１は送信すべきストリームデータを生成するアプリケーション１１と、アプリケーション１１で生成されたストリームデータを制御手段１４から指定された送信パケットレートでパケット化してデータパケットとする送信手段１２と、送信ノードと受信ノードとを接続する通信網５で発生した輻輳を検知する輻輳検知手段１３と、輻輳検知手段１３の結果に応じて送信手段１２の送信パケットレートを制御する制御手段１４と、網との入出力処理を行うパケット処理手段１５を備える。一方の受信ノード２は、パケット処理手段１５と、パケット処理手段１５から受信パケットを受け取る受信手段２２と、受信したストリームを利用するアプリケーション２１とを備える。
【００１７】
アプリケーション１１は、送信手段１２から送信タイミングを受け取り、それに応じてデータ列を送信手段１２に供給する。また、制御手段１４から減速した新しい送信パケットレートの通知を受けた際には、遷移に必要な待ち時間を制御手段１４に指示する。送信手段１２は、制御手段１４から指示された送信パケットレートで送信タイミングを生成し、これをアプリケーション１１に通知するとともに、アプリケーション１１から供給されるデータ列に、一連のシーケンス番号を付けてパケット化し、パケット処理手段１５に供給する。送信タイミングにアプリケーション１１からデータ列が供給されない場合、空のパケットを生成して、パケット処理手段１５に供給する。上記の遷移に必要な待ち時間とは、送信パケットレートの変更のためにアプリケーション１１が必要とする時間を意味する。アプリケーションの内部構成および遷移に必要な待ち時間の算出の仕組については後述する。
【００１８】
アプリケーション２１は、受信手段２２から供給されるストリームデータを消費（利用）する。受信手段２２は、パケット処理手段１５からパケットを受け取り、データ列を復元してアプリケーション２１に供給する。また、受信手段２２は、送信ノード１に受信状況を通知するため、一連のシーケンス番号が付与された受信パケットの総数と、一連のシーケンス番号が付与された受信パケットの中で最後に受信したパケットのシーケンス番号についての情報を含めたＡｃｋパケット（応答パケット）を生成し、パケット処理手段１５に供給する。
【００１９】
パケット処理手段１５は、送信手段１２や受信手段２２から受け取ったパケットを網に送出し、網から受信したパケットを輻輳検知手段１３や受信手段２２に供給する。前述したＡｃｋパケットは、パケット処理手段１５を介して受信ノード２から送信ノード１へ転送される。輻輳検知手段１３は、Ａｃｋパケットに記載された内容に基づいて、輻輳を検知して制御手段１４に通知する。通信網５のどこかで輻輳つまりパケットロスが発生すると、最終シーケンス番号と総受信パケット数の関係がパケットロスした分だけずれることになる。輻輳検知手段１３は、Ａｃｋパケットに記載されている最終シーケンス番号と総受信パケット数の差分を監視し、この変化から輻輳を検知する。
【００２０】
制御手段１４は、輻輳検知手段１３で輻輳が検知されない場合、送信パケットレートを所定の加速度で増加させ、新しい送信パケットレートとして送信手段１２に指示するとともに、アプリケーション１１に通知する。逆に、輻輳検知手段１３で輻輳が検知されると、送信パケットレートに所定の１未満の係数を乗じて、減速された新しい送信パケットレートを求める。そして、まずアプリケーション１１に新しい送信パケットレートを通知する。そして、通知後、アプリケーション１１に指示された所定の待ち時間が経過した時点で、送信手段１２に新しい送信パケットレートを指示する。
【００２１】
アプリケーション１１から制御手段１４への待ち時間の指示は、アプリケーション１１が必要とする遷移時間の最大値を予めアプリケーション起動時に待ち時間として指示する構成とすることができる。また、新しい送信パケットレートが通知されるたびに、その時点で必要となる遷移時間を待ち時間として指示する構成とすることもできる。また、待ち時間は時間そのもので表すだけでなく、送信パケットレートの減速前に送信すべきデータ量で表すことも可能である。その場合、制御手段１４はデータ量を時間に換算して待ち時間とする。
【００２２】
このように、本発明の第１の実施形態によれば、アプリケーションに必要な待ち時間（アプリケーションの遷移に必要な時間）が経過した後に、送信パケットレートが下方に変更される。このような構成によって、突然のビットレートの変更による遅延の発生、すなわち再生の停止という事態の発生を回避することが可能となる。従って、本実施形態によれば、輻輳回避と品質維持（受信者側から見た突然の遅延の発生の防止）を同時に達成することが可能となる。
【００２３】
本発明の第２の実施形態を説明する。ここでは、アプリケーション１１から制御手段１４に待ち時間を指示する代わりに、送信パケットレートの減速の承認を指示する。すなわち、アプリケーション１１において、送信パケットレートの減速を行えるようになった時点で、制御手段１４に指示を与える。そのため、アプリケーション１１と制御手段１４の動作が異なる。
【００２４】
アプリケーション１１は、送信手段１２から送信タイミングを受け取り、それに応じてデータ列を送信手段１２に供給する。また、制御手段１４から減速した新しい送信パケットレートの通知を受けた場合、送信パケットレートの減速前に送信すべきデータの送信が完了してから、減速の承認を制御手段１４に指示する（アプリケーション１１の準備が完了してから制御手段１４に承認を与える）。
【００２５】
制御手段１４は、輻輳検知手段１３で輻輳が検知されない場合、送信パケットレートを所定の加速度で増加させ、新しい送信パケットレートとして送信手段１２に指示するとともにアプリケーション１１に通知する。逆に、輻輳検知手段１３で輻輳が検知されると、送信パケットレートに所定の１未満の係数を乗じて、減速された新しい送信パケットレートを求める。そして、まずアプリケーション１１に新しい送信パケットレートを通知し、アプリケーション１１から承認を受け取るまで待ち、その後に送信手段１２に新しい送信パケットレートを指示する。尚、本実施形態においても、アプリケーション１１と制御手段１４の動作が異なるのみであって、第１の実施形態と同様の効果を得ることができる。
【００２６】
輻輳検知のために、明示的な輻輳情報を用いることができる。すなわち、各パケットがＥＣＮのような輻輳表示情報（輻輳状態であることをセット可能）を持ち、送信手段１２が輻輳表示情報をクリアして送信する。通信網５を構成する中継ノード３や４が出方路の輻輳状態に応じて輻輳表示情報をセットする。そして、受信手段２２が、受信パケットの中で輻輳表示情報がセットされているパケットをカウントして総セット数を求める。輻輳状態は、総セット数についての情報を含んだＡｃｋパケットによって送信ノード１に通知される。送信ノード１において、輻輳検知手段１４が、総セット数の変化から輻輳を検知する。
【００２７】
図２はアプリケーション１１の構成の一例を示すブロック図である。アプリケーション１１は符号化手段１１１と、バッファ手段１１２と、アプリケーション制御手段１１３から構成される。符号化手段１１１は、制御手段１１３に指示された量子化ステップサイズで入力信号を符号化する。そして、符号化によって生成されたストリームデータをバッファ手段１１２に供給する。
【００２８】
バッファ手段１１２は、符号化手段１１１で生成されたストリームデータをバッファする（蓄積する）。そして、送信手段１２から指示された送信タイミングで、所定の長さのデータ列をバッファから抜き出して、送信手段１２に供給する。アプリケーション制御手段１１３は、バッファ手段１１２の占有量（蓄積されたデータ量）を監視する。そして、制御手段１４から通知された送信パケットレートに合うように、量子化ステップサイズを制御して符号化手段１１１に指示する。また、制御手段１４から減速された新しい送信パケットレートを通知された場合、バッファ手段１１２の占有量を現在の送信パケットレートで除して必要となる遷移時間を算出する。そして、その値を待ち時間として制御手段１４に指示する。
【００２９】
図３はアプリケーション１１の他の構成の一例を示すブロック図である。アプリケーション１１は、記憶手段１１４と、記憶手段１１５と、読み出し手段１１６と、バッファ手段１１７と、アプリケーション制御手段１１８から構成される。
【００３０】
記憶手段１１４は、低ビットレートで符号化したストリームデータをファイルとして記憶している。そこから、読み出し手段１１６によってファイルが読み出され、バッファ手段１１７に供給される。記憶手段１１５は、高ビットレートで符号化したストリームデータをファイルとして記憶している。そして、上記同様にそこから、読み出し手段１１６によってファイルが読み出され、バッファ手段１１７に供給される。これらの符号化されたストリームデータは例えば１秒ごとに切り替え点を持つ（所定の固定された時間間隔であればよい）。尚、上記の記憶手段は、高低２種類のビットレートで符号化したストリームデータをファイルとして記憶しているものとしたが、２種類のみである必要はなくそれ以上の種類を有する構成も可能である。
【００３１】
読み出し手段１１６は、アプリケーション制御手段１１８に指示（選択）された記憶手段から、符号化されたストリームデータのビットレートに従った速度でストリームデータを読み出し、バッファ手段１１７に供給する。また、次の切替点までの待ち時間（すなわちアプリケーションの遷移に必要な時間）をアプリケーション制御手段１１８に供給する。バッファ手段１１７は、読み出し手段１１６から供給されるストリームデータをバッファする。そして、送信手段１２から指示された送信タイミングで、所定の長さのデータ列をバッファから抜き出して、送信手段１２に供給する。
【００３２】
アプリケーション制御手段１１８は、制御手段１４から通知された送信パケットレートに合うビットレートで符号化されたストリームデータを記憶している記憶手段を選択する。そして、選択された記憶手段を、その記憶手段に記憶されたストリームデータの符号化ビットレートに従った速度で読み出すように読み出し手段１１６に指示する。また、制御手段１４から新しい送信パケットレートを通知された場合、読み出し手段１１６から得られる次の切替点までの時間を待ち時間として制御手段１４に指示する。選択されるストリームデータの符号化ビットレートが送信パケットレートから定まるビットレート以下となり、送信手段１２が指示した送信タイミングではバッファ手段１１７にデータ列が存在しない場合がある。このような場合に、送信手段１２はパケット処理手段１５に空のパケットを供給する。
【００３３】
【発明の効果】
以上説明したように、本発明のフロー制御システムによれば、網の輻輳回避のためだけに送信パケットレートを制御するのではなく、送信パケットレートを減速する際にアプリケーションが必要とする遷移時間をいつも考慮する。これによって、ユーザから見える遅延が突然増大するといった問題が起きないように動作することができる。結果として、輻輳回避を行いつつ連続再生を実現するフロー制御システムが提供できる。
【図面の簡単な説明】
【図１】本発明のフロー制御方式によるストリームデータ伝送システムのブロック図である。
【図２】符号化手段１１の内部構成の一例を示すブロック図である。
【図３】符号化手段１１の内部構成の他の一例を示すブロック図である。
【符号の説明】
１  送信ノード
２  受信ノード
３  中継ノード
４  中継ノード
５  通信網
１１  アプリケーション
１２  送信手段
１３  輻輳検知手段
１４  制御手段
１５  パケット処理手段
２１  アプリケーション
２２  受信手段
１１１  符号化手段
１１２  バッファ手段
１１３  アプリケーション制御手段
１１４  記憶手段
１１５  記憶手段
１１６  読み出し手段
１１７  バッファ手段
１１８  アプリケーション制御手段
【図１】
0003882187.tif 000002
【図２】
0003882187.tif 000003
【図３】
0003882187.tif 000004