JP4838309B2 - データフローのための統合的リソース予約 - Google Patents

Description

本発明は、通信ネットワーク内のデータフローのためのリソース予約に関するものである。

今日のビジネス環境および個人環境における通信アプリケーションは、いつでもどこでも存在し、多種多様なサービス、例えば電子メールサービス、ウェブ閲覧、電話、テレビ会議などを提供する。多様な通信アプリケーションが存在すれば、リソース要件も多様になる。例えば、電子メールのアプリケーションは、送信者から受信者へのデータ送信を必要とするが、一般にデータ送信には厳密な時間の制約が課されない。しかし、音声通信または動画通信のアプリケーションは、一定の最小限のデータスループットを必要とし、そして、時間に敏感である、すなわち、情報の送信の際に遅延があれば、例えば、音声または動画の欠落が起こり、それに対応する不都合がもたらされる。

さらに、従来型の回線交換ネットワークは、一般に、例えば電話による会話やテレビ会議などの一定のアプリケーションについては専用の接続を提供するが、パケット交換ネットワークまたはコネクションレスネットワークは、そのような専用通信回線を提供するのではなく、例えば、発信元から着信先へのデータパケットのシーケンスを、場合によってはさまざまなパスを使って、ルーティングしてもよい。送信中にこれらのパケットが１個以上遅延すると、アプリケーションは、サービスを続ける前に遅延したデータパケットを待たなければならないため、着信先で問題が起きるであろう。

明らかに、ネットワークのそのような特徴は望ましくないため、そのようなネットワーク内では一定の最小限の通信品質を保証するメカニズムの需要が高まる。サービス品質（ＱｏＳ）とは、通信アプリケーションに必要な特徴を指す用語である。例えば、テレビ会議のサービス品質の特徴は、一定の最小限のデータスループットと、データ送信の一定の最大限の遅延であってもよいだろう。サービス品質の要件を満たすため、通信アプリケーションは、通信エンティティ間の通信リンクを確立する前に、対応する情報を信号で伝えてもよい。それに応じてネットワークは、可能なら、指定された要件を維持するような対応する通信リンクを確立する。

通信のリソースは、通信が開始されると同時に、またはアプリケーションに関連するデータフローが開始されると同時に、通信アプリケーションのために予約されてもよい。この予約は、通信アプリケーションによって提示されたサービス品質要件に対処するものであってもよい。必要なリソースを通信リンクまたはデータフローに割り当てる中央のオーソリティによって、リソースが一度に予約されてもよいし、あるいは、通信リンクまたはデータフローを送信または中継する通信ネットワークの各ネットワークノードにおいて、通信リソースが、分散ベースで通信に動的に割り当てられてもよい。十分な通信リソースが利用可能である場合のみ、新規のデータフローが認められてもよい。

従って、この場合、各ネットワークノードが、以前に割り当てられた通信リソースに関する情報を維持することが必要である。

しかし、多様なデータフローが恐らく多数あるため、各ノードは、各フローについての要件のデータをかなり多量に記憶しなければならない。

"RSVP and Integrated Services in the Internet: A Tutorial", XP 000657115は、インターネットにおいてＱｏＳ要求を伴うサービスを提供することに言及している。通信要求は、データフローのための所望のエンド・トゥ・エンドＱｏＳコミットメントを提供するためにルータにインストールしなければならない伝送スケジューリング動作と共に、予約しなければならないリソースのレベルを規定する。ルータにおいて十分なローカルリソースを利用可能な場合にのみ、要求は許可される。フローが承認されると、データフローは、エンド・トゥ・エンドＱｏＳコミットメントを受けることを期待できる。

ＥＰ １ ４６７ ５８８ Ａ２は、保証されたサービス品質のための承認制御およびリソース予約に言及している。Ａｂｉｓインタフェースのための承認制御が提供されるが、これは、Ａｂｉｓインタフェースの使用リソースを判断し、接続に関する所望のスループットのために必要なリソースを判断し、必要なＡｂｉｓリソースが利用可能なリソースと使用中のＡｂｉｓリソースとの差分よりも小さい場合にその接続を受け付けることにより、提供される。

本発明の目的は、複数の異なるサービス要件について演算上の必要性を低減させたかたちで、通信ネットワーク内のデータフローのためのリソース予約を提供することである。

本発明のこの目的は、独立クレームの主題によって解決される。従属クレームの中で、有利な実施形態が開示される。

一例によると、通信ネットワーク内のデータフローのためのリソースを予約する一方法は、新たなデータフローのための、要求されるリソースを指定する複数の記述子を含むリソース予約要求を検出するステップと、前記新たなデータフローの前記複数の記述子と、予約カウントと、に基づいて承認テストカウントを演算するステップであって、前記予約カウントは、承認されたデータフローのリソースを指定する複数の承認されたデータフローの複数の記述子の予約関数を表すステップと、前記承認テストカウントが前記複数の記述子のための最大承認カウントよりも小さい場合に前記新たなデータフローを承認するステップと、前記新たなデータフローが承認された場合に前記新たなデータフローの前記記述子に基づいて前記予約カウントを更新するステップと、を備える。

従って、予約カウントは、例えばサービス品質の要件のような複数の記述子に関する複数の承認されたデータフローのためのリソースを表すことから、ノードが、各フローの記述子を個別に記憶することなく、多数となりうるフローを処理することができる。フローが承認される場合、新規フローのためのリソースも反映するためには、予約カウントだけが更新されればよい。

一例によると、予約関数は、総和関数または乗算関数で構成されており、総和関数は、データフローの記述子を変数として有する関数の和で構成され、そして乗算関数は、データフローの記述子を変数として有する関数の積で構成される。従って、予約カウントは、既存の予約カウントと新規フローの記述子の関数の加算演算または乗算演算によって、新規フローの記述子に基づいて更新することができる。

別の例によると、承認テストカウントを更新することは、新規データフローの記述子の総和関数を予約カウントと加算すること、または、予約カウントを新規フローの記述子の乗算関数と乗算することを含む。次いで、それに対応する更新された予約カウントは、新規フローを含めてすべての承認されたデータフローを有利に反映する。

別の例によると、承認されたフローのうちの１つについての解放命令が受信された場合、対応する記述子に基づいて、各予約カウントが更新されてもよい。フローを解放することは、解放されるフローの記述子の総和関数を予約カウントから減算すること、または、解放されるデータフローの記述子の乗算関数で予約カウントを除算することを含んでもよい。従って、解放されたフローが、減算演算または除算演算によって予約カウントに反映されて、解放される可能性があるすべてのフローの記述子を維持する必要を回避することができる。

さらにまた、別の例によると、各予約カウントを演算することは、所定の期間を有するリフレッシュ・ウインドウの間に承認またはリフレッシュされたフローに基づく。フローは、フローに関連するリフレッシュ要求がリフレッシュ・ウインドウの間に受信されない場合、または、明示的解放命令が受信された場合には、解放されてもよい。従って、リフレッシュ・ウインドウを利用することによって、そして、リフレッシュ・ウインドウの範囲内でリフレッシュされなかったかまたは明示的に解放されたすべてのフローを解放することによって、予約カウントは、リフレッシュ・ウインドウの期間の間に承認されて解放されなかったすべてのフローを把握し続けることができる。

有利な一実施形態によると、各予約カウントは、複数のサブカウントを含んでもよく、各サブカウントは、リフレッシュ・ウインドウのうちで隣接するサブ・ポーションの間に承認されたかまたはリフレッシュされたフローに基づいており、サブ・ポーションは、リフレッシュ・ウインドウを進める単位時間に相当する。リフレッシュ・ウインドウを１単位時間だけ進めると、新規のサブカウントが生成され、最も古いサブカウントが削除されてもよい。従って、スライディング・ウインドウを１単位時間ずつ進める度に、最も古いサブカウントが削除され、すべての承認された新規フローとリフレッシュされたフローと解放されたフローとに基づいて、新規のサブカウントが演算されることになる。次いで、新規の予約サブカウントが、すべての新規フローとリフレッシュされたフローと解放されたフローとを反映し、従って、最も古い予約カウントは使われなくなる。従って、各サブ・ポーションすなわちリフレッシュ・ウインドウの単位時間について１つずつ、複数の予約サブカウントを維持することで十分であり、さらに演算の複雑度が減少する。

別の例によると、測定された帯域幅の合計と、新規フローのピークレートと、承認されたフローの中の新規フローのデグレードの合計とに基づいて、承認テストベクトルが演算される。

上記の演算を実行するように構成された命令を有するプログラムが提供されてもよいし、コンピュータで読み取り可能な媒体がそのプログラムを備えてもよい。コンピュータプログラム製品が、そのコンピュータで読み取り可能な媒体を備えてもよい。

別の例によると、通信ネットワークにおけるデータフローのためのリソース予約のためのネットワークノードが提供されてもよく、これは、新たなデータフローのための、要求されるリソースを指定する複数の記述子を含むリソース予約要求を検出し、前記新たなフローの複数の記述子と、予約カウントと、に基づいて承認テストカウントを演算するリソースマネージャであって、前記予約カウントは、承認されたデータフローに割り当てられたリソースを指定する複数の承認されたデータフローの複数の記述子の予約関数を表すリソースマネージャと、前記承認テストカウントが前記複数の記述子のための最大承認カウントよりも小さい場合に新たなデータフローを承認するフロー制御ユニットと、を備え、前記リソースマネージャは、前記新たなフローが承認された場合に前記新たなフローの前記記述子に基づいて前記承認テストカウントを更新するように構成される。

図１は、本発明の一実施形態による、データフローのためのリソース予約のための、通信ネットワークの要素を図解する図である。

図１は、通信エンティティ間でデータフローを中継または送信するための、ネットワークの通信ノードを図解する図である。ネットワークノードは、一般的に１００と表示するが、リソースマネージャ１１０とフロー制御ユニット１２０とを備えている。フロー制御ユニットは、データフローのための通信リソースを提供しており、新規データフローを承認してもよいし拒否してもよい。リソースマネージャは、データフローを中継または送信するためにネットワークノードで利用可能なリソースを把握し続ける。ネットワークノード１００は、通信リンク１５０を介して、１３０と記した隣接のネットワークノードに接続する。ネットワークノード１３０の各々は、ネットワークノード１００と同様の構造を持っていてもよく、すなわち、各ノードが、利用可能なリソースを把握し続けて、新規データフローを承認または拒否する権限を持っていてもよい。ネットワークノード１００および１３０は、多数のネットワークノードや通信エンティティで構成される、より大きいネットワークの一部を成してもよい。

ネットワークノード１００でのリソース予約メカニズムは、１５１に略示するようにリソース要求が受信された場合に、アクティブになる。リソース要求は、コンピュータ装置や電話機やテレビ会議装置などのような通信エンティティによって発行されてもよく、また、通信エンティティから直接受信されてもよいし、ネットワークノード１３０とネットワークノード１００とを接続する通信リンク１５０上でネットワークノード１３０を介して受信されてもよい。

リソースマネージャ１１０は、ネットワークノード１００で承認されることを求めている新規データフローのためのリソース予約を求めるリソース要求１５１を検出する準備ができている。リソース要求は、要求されたリソース、例えば最小帯域幅要件、平均帯域幅要件、データ送信の最大時間遅延、ピークレート、平均レート、その他のサービス品質要件などを指定する複数の記述子を少なくとも含む。また、それに加えて、リソース要求は、要求側エンティティやデータフローのＩＤ、一定のリソースを要求するための許可コード、セキュリティコードなどを含んでもよい。

リソース要求が検出された場合、リソースマネージャ１１０は、新規フローの複数の記述子と、例えば事前に演算されて記憶ユニットの中に維持された予約カウントの定数とに基づいて、承認テストカウントを演算する。予約カウントは、予約関数の演算の結果を表すものだが、予約関数は、変数として、複数の承認されたデータフローの複数の記述子を有し、承認されたデータフローのリソースを指定する。このようにして予約カウントは、個別のフローの記述子を統合されたかたちで、すなわち、個別のフローの記述子を明示的に示すことなく、反映する。記述子は、すべてのフローについて個別に記憶されてはいないため、変数すなわち予約カウントの数は、フローの数には依存しないことになり、システムは容易に拡張できるようになる。

より詳細には、リソース要求を検出すると、リソースマネージャは、承認されるように要求されたフローの記述子をリソース要求から抽出し、そして、すでに承認されたデータフローの対応する記述子の予約関数を表し且つ割り当てられたリソースを指定する予約カウントを、演算するか、または、例えば記憶ユニットから、取得する。

複数の予約関数が存在してもよく、それぞれが、予約カウントに関連付けられて、そして、記述子に関して、またはそれよりも、承認されたデータフローの記述子の値に関して実行される例えば和、積、平方根などのような数学的演算を指定してもよい。

また、それに加えて、予約関数は、新規データフローの記述子を変数として使って実行され、次いで、対応する承認テストカウントが、新規データフローの記述子の値と予約カウントとについての予約関数の演算の結果に基づいて得られる。承認テストカウントは、単一の値であってもよいし、ベクトルの中のさまざまな値の集合であってもよく、そして、新規フローが承認された場合には、全般的に必要なリソースを表す。

一例によると、予約カウントは、すべての承認されたフローに必要な帯域幅や、すべての承認されたフローについて推定されるピークレートや、データ送信のための最大保証時間遅延などを表してもよい。次いで、承認テストカウントは、新規データフローを含む全体帯域幅や、新規データフローを含む最大ピークレートや、新規データフローを含むデータ送信の最大保証時間遅延を反映するであろう。

承認テストカウントを演算した後、リソースマネージャは、承認テストカウントが複数の記述子についての最大承認カウントを超えていない場合、新規データフローが承認されることになることを決定するが、ここで最大承認カウントは、例えば、最大予約カウントの承認関数を構成する。

例えば、最大承認カウントは、ネットワークノードによって提供される個別のリソース、例えば利用可能な最大帯域幅、可能な最大ピークレートなどの、閾値の限度に基づいて算出されてもよいだろう。

一例によると、最大承認カウントは、例えば各最大可能記述子に基づく加重計算のような、１個の値を表し、同様に、承認テストカウントは、例えば複数の予約カウントと新規フローの記述子とに基づく加重計算を反映する１個の値によって構成されてもよい。この場合、承認テストカウントの値が最大承認カウントを超えない場合、フローは承認されるであろう。

あるいは、最大承認カウントは、個別の最大リソース記述子に対応する複数の値を含み、そして、承認テストカウントの対応する要素との個別の比較が行われてもよい。承認テストカウントのどの要素も、対応する最大承認カウントの最大予約カウントを超えない場合、フローは承認されてもよいだろう。承認テストカウントと最大承認カウントとが、複数の値で構成される場合、例えば構成要素のうちの１つが対応する最大構成要素を超えることを許可するというような、一定の規則に従って新規フローの承認が行われてもよい。

新規データフローが承認された場合、新規データフローの記述子に基づいて予約カウントが更新されることにより、更新動作の後では予約カウントが、新規データフローを含むすべての承認されたデータフローのためのすべての予約されたリソースを反映するようになる。新規フローが承認されなかった場合、リソースマネージャは予約カウントを更新せず、その場合、予約カウントは、以前に承認されたデータフローを反映したままである。

フロー制御ユニット１２０は、承認チェックの後、対応するリソースを予約することと、承認されたデータフローに関するその後のデータ送信とを含めて、データフローを承認または拒否するステップを実行する。

ネットワークノード１００は、例えばワイヤレス通信ネットワークまたは有線固定もしくは混合通信ネットワークのような、通信ネットワークの複数のノードのうちの１つである。ネットワークノードは、例えば、インターネットを利用したネットワークの場合のようなネットワークのルータであってもよいし、基地局であってもよいし、隣接する通信ネットワークにインタフェースするいかなるネットワークノードであってもよい。ネットワーク内の通信リンクは、１５０で図示されており、専用通信リンク、コネクションレス通信リンク、ワイヤレスリンクのうちいずれであってもよい。一例によると、通信ネットワークは、少なくとも部分的にはパケット交換ネットワークで構成されるが、それは例えばＩＰを利用したネットワーク、例えばインターネットのようなものであり、承認されたり承認のためチェックされたりするデータフローをパケットのシーケンスが構成するものである。

動作中、各ネットワークノードは、自分自身のリソースを管理すること、すなわち、データフローを承認するかまたはデータフローを拒否することに責任を有してもよい。従って、パス沿いのすべてのネットワークノードがデータフローを承認する場合のみ、データフローは、発信元から着信先へルーティングされ得る。フローの承認手順は、例えば、通信アプリケーションが通信セッションを設定するためのステップを踏み、対応するデータフローのルーティングを要求する場合などに、動的に行われてもよい。

一例によると、リソースマネージャ１１０とフロー制御ユニット１２０とは、ネットワークノードの処理要素、例えば対応するハードウェアおよび／またはソフトウェア（ハードウェアとソフトウェアとのうちの少なくとも一方）で構成される。代わりに、またはそれに加えて、外付けの構成要素、例えば予約カウントを記憶するための外部メモリや承認テストカウントを演算するための外部処理要素等が利用されてもよい。リソースマネージャとフロー制御ユニットとは、内部バスなどを介して相互に通信する、別個の専用要素で構成されてもよい。あるいは、リソースマネージャとフロー制御ユニットとは、処理ユニットで実行された対応するソフトウェアルーチンによって少なくとも部分的には実現された、論理エンティティで構成されてもよい。

上記の実施形態によると、予約カウントの定数は、複数の承認されたデータフローのリソースを複数の記述子、例えばピーク帯域幅レート、平均レート、バーストサイズなどのサービス品質要件に関して統合することから、ノードは、各フローの記述子を個別に記憶することなく、多数となりうるフローを処理することができる。フローが承認された場合、新規フローのためのリソースも反映するためには、予約カウントだけが更新されればよい。従って、承認制御の数式は、予約カウントが承認されたリソースを統合するかたちで、削減された状態環境で維持されることができる。

下記において、本発明のさらなる実施形態を図２に関して記述しよう。図２は、通信ネットワーク内でのリソース予約の方法の動作を図解する図である。

第１の動作２０１において、新規データフローのためのリソース予約要求が検出されるが、リソース予約要求は、ネットワークノードで要求される通信リソースを指定する複数の記述子を含む。一例において、要求は、２つの通信エンティティ間のパスに沿った各ネットワークノードで受信される。リソース予約要求は、通信ネットワーク内でのメッセージ交換用の通信プロトコルに従って送信されてもよく、そして、例えば、通信の発信元から通信の着信先までの所望のまたは適切な通信パスに沿って１つのネットワークノードから次のネットワークノードへと転送されてもよい。リソース予約要求は、ネットワークノードでの新規データフローの承認を要求する。

データフローは、通信の発信元から通信の着信先まで送信されるいかなる形式のデータであってもよい。例えば、データフローは、通信データを搬送するものであれば、連続的なデータストリームでもデータパケットのシーケンスでもよい。

リソース予約要求は、一方向の、すなわち、通信の発信元から通信の着信先への新規データフローの承認を要求してもよいし、あるいは、双方向の、通信の発信元から通信の着信先への、そしてリターンパスで通信の着信先から通信の発信元への、データフローの承認を要求してもよい。

データフローにより送信されるアプリケーションデータまたはペイロード情報は、いかなる種類の通信から生じてもよい、すなわち、電子メールデータ、音声データ、テレビ会議のデータ、コンピュータ装置間の交換に関するデータなどを含んでもよい。

要求されたリソースを指定する記述子は、根底にあるアプリケーションの要件を満たすための最小限の必要リソースを指定することが好ましい。例えば、記述子は、必要な帯域幅や、中程度に必要な帯域幅や、ピークレートや、平均レートや、最大許容送信遅延などを指定してもよい。さらに、記述子は、リーキーバケットやトークンバケットを指定してもよい。

ネットワークノードの動作２０２において、リソース予約要求と共に受信された新規フローの複数の記述子と複数の予約カウントとに基づいて、承認テストカウントが演算される。予約カウントは、複数の承認されたデータフローの複数の記述子の予約関数を表し、そして、すべての承認されたデータフローの総リソースを指定する。予約関数は、例えば総和関数、乗算関数、または総和関数と乗算関数の集まりで構成されてもよい。存在している総和関数は、各データフローの記述子をそれぞれ変数として有する予約関数の合計によって構成され、存在している乗算関数は、データフローの記述子を変数として有する関数の積によって構成される。

一般論として、総和関数は次式のような形式を有し、

乗算関数は次式のようであり、

ここで、Ｓ_ｎとＰ_ｍとは、予約カウントを構成し、

は、フローｉの記述子のベクトルを表し、
ｆ_ｊは、総和タイプの予約カウントｊの予約総和関数を表し、
ｇ_ｋは、乗算タイプの予約カウントｋの予約乗算関数を表す。

一例によると、承認テストベクトルは、測定された帯域幅の和と、新規データフローのピークレートと、新規データフローと承認されたフローとのピークレートの和とに基づいて演算される。

この例では、承認の決定を行うためにＨｏｅｆｆｄｉｎｇ−Ｂｏｕｎｄ（ＨＢ）が用いられる。ここでは、

の場合、
（ｎ＋１）番目のフローが承認される。
ここで、Ｍは、測定された帯域幅、Ｐ_ｉは、ｉ番目のフローの信号で伝えられたピークレート、イプシロンは、承認制御手順のリスクの度合いを制御するパラメータ、そしてＣは、リンクの容量である。数式は、削減された状態環境に適した形式に変換されてもよい。

この例示した承認制御の数式は、

を、統合された変数として維持することを必要とする。

予約カウントが、承認されたデータフローの記述子の総和関数または乗算関数によって表されるため、承認された各々のデータフロー自体の記述子に関する情報を維持することなく、承認されたリソースを把握し続けることができる。むしろ、すべての承認されたフローの記述子を総和関数または乗算関数で演算した統合的な結果が、予約カウントとして維持される。従って、予約カウントの各々は、すべての承認されたデータフローの記述子に対応するネットワークノードで使用されるリソースの量または程度に対応し得る。

承認テストカウントを演算することは、新規データフローの記述子を予約カウントに統合することを含む。予約カウントを演算する予約関数が、例えば総和関数である場合、新規フローの記述子の予約関数は、予約フローに加えられてもよいし、また、予約関数が乗算関数である場合、新規フローの記述子の乗算関数は、対応する予約カウントに乗じられてもよい。

すると、承認テストカウントは、新規データフローの記述子を含むすべての予約カウントの関数である。

一般に、承認テストカウントは、次式の形式をとる。

ここで、

は、フローｉの記述子のベクトルを表し、
ｆ_ｊは、総和タイプの予約カウントｊの予約総和関数を表し、
ｇ_ｋは、乗算タイプの予約カウントｋの予約乗算関数を表し、

は、新規データフローの記述子のベクトルを表し、

は、承認テストカウントの事前設定されたパラメータのベクトルを表し、そして、
Ｆは、任意の関数を表す。

承認テストカウントを演算した後、動作２０３で、承認テストカウントが最大承認カウントを超えないかどうかが判断される。最大承認カウントは、最大許容リソース予約を意味しており、承認されたデータフローと新規データフローとの記述子によって記述されたネットワークノードにおいて利用可能なリソースの最大値に基づいている。最大承認カウントは、最大予約カウントの承認関数に基づくことが好ましい。

一般論として、最大承認カウントは、次式で表される。

ここで、
Ｓ_ｊは、総和関数のための最大予約カウントを表し、
Ｐ_ｋは、総和関数の最大予約カウントを表し、そして、
Ｆ’は、承認関数を表す。

判断動作２０３は、２つの値の比較を含んでもよいし、承認カウントを表す複数の値と最大カウントを表す対応する値との比較を含んでもよい。比較動作は、承認カウントベクトルと最大カウントベクトルという２つのベクトルの比較と考えられてもよい。承認テストカウントのどの要素も、対応する最大承認カウントの値を超えないならば、承認カウントは最大承認カウントを超えないと考えられるであろう。あるいは、承認テストカウントベクトルの長さと、最大承認カウントベクトルの長さが、比較されてもよいだろう。

動作２０３において、決定が「ＮＯ」である場合、すなわち、承認テストカウントが最大承認カウントを超える場合、新規データフローは、動作２０６において拒否される。

動作２０３において、決定が「ＹＥＳ」である場合、すなわち承認カウントが最大承認カウントを超えない場合、新規データフローは、動作２０４において承認される。できれば、新規データフローを承認することは、リソース要求に従って、新規データフローをルーティングするのに必要なリソースを割り当てることを含むことが、好ましい。また、動作２０４は、要求側エンティティと通信パスに沿ったすべての通信ノードとに、データフローの承認を通知することを含んでもよい。

さらに、動作２０５において、予約カウントは、新規フローの記述子に基づいて更新される。この動作は、今新規データフローに割り当てられたリソースを予約カウントに反映するためである。予約カウントを更新することは、承認テストカウントの要素を、すなわち、新規フローの記述子を含む予約カウントを、新規予約カウントとして記憶することを含んでもよい。予約関数が総和関数である場合、対応する更新された予約カウントは、その結果、前の予約カウントと新規フローの記述子の予約総和関数との和である。予約関数が乗算関数である場合、更新された予約カウントは、前の予約カウントと新規フローの記述子の予約乗算関数との積に対応する。更新動作は、今後は更新された予約カウントを例えばさらなる新規データフローの承認動作に反映するため、以前の予約カウントを上書きすることを含んでもよい。

新規データフローが拒否された場合には、そのような更新動作は行われず、前に記憶または演算された予約カウントが、そのまま維持される。

以下に、承認制御の数式のさらなる例について、記述しよう。

この例は、例えば、Ｈ．Ｇ．Ｐｅｒｒｏｓ、Ｋ．Ｍ．Ｅｌｓａｙｅｄ著「呼承認制御スキーム：総論(Call admission control schemes: A review)」、ＩＥＥＥ通信マガジン、第３４巻、第１１冊、８２−９１頁、１９９６年１１月刊に記述されている大量トラヒックの近似（ＨＴＡ）理論を、削減された状態で実装したものを示す。

大量トラヒック近似理論によると、次式が成り立てば、新規フローが、ノードにおいて承認される。

ここで、

ここで、以下の事前設定されたパラメータ、すなわち、フロー自体ではなく、例えばノードのような環境に依存するパラメータは、
・γ：定数パラメータ
・Ｋ：ノードにおけるバッファ容量
・ε：目標呼損率
であり、以下のフロー毎に信号で送られる記述子、すなわち、フローに関連して送信される記述子は、
・Ｒ_ｉ：フローｉのピークレート
・ｒ_ｉ：フローｉの活動度（アクティビティ・ファクター）
・ｂ_ｉ：フローｉがアクティブである時間の平均存続時間
である。

上記の承認制御関数（８）は、下記の予約カウントが定義された場合、削減された状態環境へ変換することができる。

予約カウント（９）と（１０）とを、承認制御関数（８）に代入すると、削減された状態の承認制御関数になる。

今、新規フローが承認されることを希望する場合、以下の承認テストカウントが、予約カウント（９）および（１０）および新規フローの記述子のベクトル

に基づいて演算される。

承認テストカウントは、先述のとおり、最大承認カウントと比較され、フローを承認することが決定された場合、予約カウント（９）および（１０）は、以下のように更新される。

Ｓ_１←Ｓ_１＋ｒ_ｎｅｗＲ_ｎｅｗ （１３）
Ｓ_２←Ｓ_２＋ｒ_ｎｅｗＲ_ｎｅｗ（１−ｒ_ｎｅｗ）^２ｂ_ｎｅｗ （１４）

フローが承認されない場合、すなわち、前述のように、予約テストカウントが最大承認カウントを超える場合、予約カウント（９）および（１０）は更新されない。

他方、フローが、対応する記述子の明示的な信号送信によって解放された場合には、予約カウント（９）および（１０）は以下のように更新される。

Ｓ_１←Ｓ_１−ｒ_ｎｅｗＲ_ｎｅｗ （１５）
Ｓ_２←Ｓ_２−ｒ_ｎｅｗＲ_ｎｅｗ（１−ｒ_ｎｅｗ）^２ｂ_ｎｅｗ （１６）

図２は、本発明の方法の利点を図解するが、この方法では、承認されたデータフローと新規データフローの各々の記述子を記憶するのではなく、その代わりに、すべてのフローの記述子の乗算関数をもう少し表す予約カウントの定数が維持され、新規フローが承認された場合には、適切に更新される。

以下に、図３に関して、本発明のさらなる実施形態について記述しよう。

図３は、リソースを予約する方法の動作を示し、特に、前に承認されたフローのリソースを解放することに関する動作を図解する。

動作は、例えば図２の動作２０５に続く、入口ポイントＡで開始される。

以前の実施形態に関して述べたように、予約カウントが維持されて、予約カウントは、すべての承認されたフローのリソースを統合されたかたちで反映する。すなわち、情報は、承認された各フローに関してではなく、すべてのフローを集合的に反映する統合的なかたちで記憶される。従って、データフローを終了させるためだけでなく、割り当てられたリソースを、より詳細には、これ以上維持されない特定のフローのために要求されたリソースの記述子を、予約カウントから除去するためにも、特別な準備（プロビジョン）が行われなければならない。

第１の動作３０１において、特定のフローに関連する解放命令が受信されたかどうか判断される。解放命令は、通信リンクおよび関連するデータフローはこれ以上必要ないという事実を各通信ノードに知らせるため、リソース要求と同様に、通信の発信元から承認されたデータフローのパスに沿って送信されてもよい。解放命令は、解放されることになるフローまたは通信リンクの指標を含むことが好ましく、また、さらに、そのデータフローのために承認されたリソースの記述子を含むことが好ましい。承認されたリソースの記述子、すなわち、データフローを承認することを求めるリソース要求を送信するときに以前に要求されたリソースは、以下にさらに概説するように、それに対応して予約カウントを調整するのに使われてもよい。

動作３０１において決定が「ＹＥＳ」である場合、解放命令が受信されたことを示し、動作３０３において、対応するデータフローが解放されて、対応する割当てられたリソースがさらなるデータフローのために利用可能になる。データフローを解放することには、例えば図１に示すフロー制御ユニット１２０によって、関連する通信リンクを終了することが含まれてもよい。

動作３０１において、決定が「ＮＯ」である場合、解放命令が受信されなかったことを示し、動作３０２において、リフレッシュ要求が一定の所定の時間内に受信されたかどうかが判断される。例えば、通信リンクまたはデータフローがまだ必要であることを各中継通信ノードに知らせるため、承認されたフローの維持を必要とする各通信エンティティがリフレッシュ要求を定期的に送信するように、通信ネットワークが設計される。例えば、通信アプリケーションのような通信エンティティは、アプリケーションの終了またはアプリケーションを実行するコンピュータ装置のシャットダウンのような終了イベントがあると、明示的解放命令を送信する立場にはなく、単純に終了されるかもしれない。明示的解放命令によってしかフローが解放されないのならば、そのような場合には、通信リンクまたはデータフローが無期限に維持される可能性がある。

従って、例えば対応する通信アプリケーションを終了させた場合に、データフローはこれ以上必要ないという情報も、定期的なリフレッシュ要求を送信する機会をとらえて伝達されてもよい。できれば、リフレッシュ要求は、解放命令と同様に、維持されるべきデータフローの指標を含むことが好ましく、また、例えばそのフローのために発行された以前のリソース要求の記述子のような、維持されるべきフローのリソースの記述子を含んでもよい。維持されるべきデータフローの記述子をリフレッシュ要求の中に含むことによって、以下にさらに概説するように、予約カウントを最新の状態に維持することが可能になる。

動作３０２において、決定が「ＮＯ」である場合、リフレッシュ要求が一定の所定の時間またはリフレッシュ時間内に受信されなかったことを示し、前述のように、動作３０３においてデータフローが解放される。

その後、動作３０４において、解放されたフローの記述子に基づいて予約カウントが更新される。明示的解放命令が受信された場合、データフローを解放することには、新規フローの記述子を予約カウントに含めることとは逆方向のプロセスが含まれ、すなわち、予約カウントから、解放されたデータフローの記述子のすべての総和関数を減算することと、すべての乗算関数の予約カウントを、解放されたデータフローの記述子の乗算関数によって除算することとが含まれる。従って、明示的解放命令があると、解放されたフローの記述子に基づいて、統合されたカウントから解放されたフローのリソースを削除することによって、予約カウントが更新され得る。

動作３０３において、必要とされる時間内にリフレッシュ要求が欠如することに応じてデータフローが解放された場合、通信ノードは、例えば、正式にデータフローの承認を要求するエンティティに質問することによって、フローの記述子に関して積極的に問い合わせてもよい。この質問に基づいて、ネットワークノードは、リフレッシュされていないフローの記述子を取得し、そして、それに対応して、明示的に解放されたフローに関してすでに概説したものと同様に、予約カウントから記述子を削除することができる。

従って、予約カウントは、常に最新の状態で維持され、継続的に使用中のすべてのフローを反映することができる。

通信ノードが、リフレッシュされていないフローの記述子を取得できない場合、時間に基づいたアルゴリズムが用いられてもよいが、それについては、図５に関してより詳細に概説しよう。簡単に言うと、このアルゴリズムは、リフレッシュされた各フローを、承認された新規フローとして扱うことを含み、すなわち、リフレッシュされた各フローの記述子が、予約カウントに含まれる。リフレッシュする度に予約カウントが増加することから、記述子を、従って、予約カウントにおけるリフレッシュされたフローのリソースを、過度に表すことを回避する目的で、予約カウントに時間タグが設けられ、予約カウントの期限切れ部分であるサブカウントを削除できるようにする。予約サブカウントの時間タグがリフレッシュ時間より古い場合、この時間内にリフレッシュ要求が発行されている必要があるわけだが、予約カウントのサブカウントが、例えば削除されてもよい。というのも、この場合、すべてのリフレッシュされたフローはカウントの中で新たに考慮され、リフレッシュされたフローをすでに反映している最も古いカウントはそのとき削除されるべきであるからである。リフレッシュされていないすべてのフローは、より新しい予約カウントの中に新たに表されることはないであろうし、最も古いカウントと共に削除されるであろう。

以下で、本発明のさらなる実施形態について、図４に関して記述しよう。図４は、リソース予約の方法の動作を図解し、特に、承認テストカウントを演算する動作と、フローが承認された場合に予約カウントを更新する動作とを図解する。

第１の動作４０１において、これまでの実施形態に関して概説したように、新規フローが承認されるべきかどうかが判断される。

動作４０２において、予約カウントがメモリから検索されるが、予約カウントは、予約関数に基づいて、複数の承認されたフローの各々について以前に演算されている。前に述べたように、予約総和関数の場合、予約カウントは、すでに承認されたフローの記述子のすべての総和関数を合計することによって得られる。

予約関数が乗算関数である場合、予約カウントは、すでに承認されたフローの記述子のすべての乗算関数の積で構成される。

続いて、動作４０３において、予約関数が、承認されることを要求する新規フローの記述子について演算される。

次いで、動作４０４において、動作４０２で得られた予約カウントと、動作４０３の結果とが、関数のタイプに応じて結合される。予約関数が総和関数である場合、動作４０３の結果が予約カウントに加算され、予約関数が乗算関数である場合、動作４０３の結果が動作４０２で得られた予約カウントに乗じられる。次いで、動作４０５において、さらなる予約関数が定義されるかどうか判断される。

なお、予約関数は、任意の総和関数または乗算関数でありうるものであり、事前に定められていてもよいし、必要に応じて例えばネットワークオペレータによって、動的に定められてもよい。従って、リソースを予約して統合的な予約状態を維持するための本発明の枠組みは、独自の予約関数の定義を可能にすることによって、個別の必要性に適応させることができる。

動作４０５において、さらなる予約関数が定義されていると判断された場合、動作４０２乃至４０４が反復される。

動作４０５において、さらなる予約が判断されないと判断された場合、動作４０６において、承認テストカウントが、このようにして得られた予約カウントに基づいて演算される。承認テストカウントを演算することには、例えば、予約カウントの加重総和、予約カウントの加重乗算、またはその他の何らかの演算のような、個別の予約カウントに関するいかなる数学的演算が含まれてもよい。

あるいは、別の例によると、動作４０４は省略され、動作４０６が、予約カウントと、動作４０３からの新規フローの記述子についての演算された予約関数とに基づく、承認テストカウントの演算を含む。

別の例によると、予約カウントは、承認テストカウントを構成するベクトルの中に維持される。

次いで、動作４０７において、こうして得られた承認テストカウントが、最大承認カウントと比較される。最大承認カウントは、例えば図２に関して概説したように、承認テストカウントの予約カウントに対応する事前設定された最大予約カウントの承認関数で構成されてもよい。

承認関数、すなわち、最大承認カウントが１個の値である場合、動作４０７は、承認テストカウントが最大承認カウントより小さいかどうかを判断するための単純な比較動作である。承認テストカウントと、対応する最大承認カウントとが、予約カウントのベクトルによって表される場合、ベクトルの個別要素、例えば個別の予約カウントと、対応する最大予約カウントとが、比較される。この場合、一例によると、承認テストカウントは、承認テストベクトルのすべての要素が、対応する最大承認カウントより小さい場合には、最大承認カウントより小さいと判断される。

動作４０７において、決定が「ＹＥＳ」である場合、承認テストカウントは最大承認カウントより小さいことを示し、動作４０８において、新規フローの記述子を含む予約カウントが、更新された予約カウントとして記憶される。従って、今記憶された予約カウントは、新規に承認されたデータフローも含めて、すべての承認されたデータフローを反映する。予約カウントを記憶することまたは更新することは、新規データフローのためのリソース要求を検出する前に記憶された、対応する記憶済みの予約カウントを上書きすることを含んでもよい。

動作４０７において決定が「ＮＯ」である場合、承認テストカウントは最大承認カウントより小さくないことを示し、動作４０９において、新規フローの記述子を含む演算された予約カウントは破棄され、以前に演算された予約カウント、すなわち、新規データフローのためのリソース要求を検出する前に利用可能な予約カウントが維持される。

従って、予約カウントは、現在承認されているデータフローを常に反映し、より正確には、現在承認されているフローに必要なリソースを常に反映する。

以下で、本発明のさらなる実施形態について、図５に関して記述しよう。図５は、リソース予約の方法の動作を図解し、特に、データフローを解放するステップを概説する。

図３に関して、データフローの解放とそれに対応する予約カウントの更新とに関係する実施形態を記述した。図３の動作３０４では、一定のリフレッシュ時間内にリフレッシュ要求を受信しない場合には、それに対応して予約カウントを更新するため、リフレッシュされなかったフローの記述子が取得されることが想定された。しかし、そのような情報が利用できない場合、すなわち、リフレッシュされなかったフローの記述子が得られない場合には、対応する更新動作が実行できない。前に述べたように、予約状態は、個別に維持されるのではないのであり、すなわち、ネットワークノードは、個別の承認されたフローの個別の記述子を記憶するのではなく、統合された予約カウントだけが維持される。

図５の実施形態は、スライディング・ウインドウの技法を用いることによって、リフレッシュされていないデータフローを予約カウントから削除するという上記の課題を扱う。

上記のように、これには、リフレッシュされた各フローを、承認された新規フローとして扱うこと、すなわち、リフレッシュされた各フローの記述子が予約カウントに再び含まれることが関与する。リフレッシュする度に予約カウントが増加することから、記述子を、従って、予約カウントにおけるリフレッシュされたフローのリソースを、過度に表すことを回避する目的で、予約カウントに時間タグが設けられ、スライディング・ウインドウが定義されて、予約カウントの期限切れ部分またはサブカウントを削除できるようにする。予約サブカウントの時間タグが、リフレッシュ時間より古い場合、この時間内にリフレッシュ要求が発行されている必要があるわけだが、予約カウントのサブカウントが、例えば削除されてもよい。というのも、この場合、すべてのリフレッシュされたフローはカウントの中で新たに考慮され、リフレッシュされたフローをすでに反映している最も古いサブカウントはそのとき、スライディング・ウインドウを用いて削除されるべきであるからである。リフレッシュされていないすべてのフローは、より新しい予約カウントの中に新たに表されることはないであろうし、最も古いカウントと共に削除されるであろう。

一般に、スライディング・ウインドウは、すべての新規に承認されたフローとリフレッシュされたフローとに基づいて、一定の時間内で各予約関数についての予約カウントを算出するために使用され、また、スライディング・ウインドウを進めるときに予約カウントを破棄するために使用される。従って、予約カウントは、一定の時間（タイムスパン）、すなわち前に概説したようにデータフローをリフレッシュするためのリフレッシュ期間の後、破棄されてもよい。というのも、この時間の後にはリフレッシュされない各フローは解放されてもよいことが知られているからである。

第１の動作５０１において、所定の長さを有するスライディング・ウインドウが定義され、スライディング・ウインドウを進めるための単位時間に相当する複数のサブ・ポーションに再分割される。言い換えると、スライディング・ウインドウは、対応する時間が経過するとサブ・ポーションすなわち単位時間だけ進められる。できれば、スライディング・ウインドウは、リフレッシュ時間に対応する所定の長さを有することが好ましく、データフローの解放を回避する目的で、リフレッシュ時間の間に、リフレッシュ要求がアプリケーションによって発行される必要がある。

動作５０２において、予約サブカウントが維持されるが、各サブカウントは、スライディング・ウインドウのサブ・ポーションの中で承認または解放されたデータフローに対応する。従って、各予約カウントは、多数の予約サブカウントで構成され、予約サブカウントの数は、スライディング・ウインドウのサブ・ポーションの数に対応する。

動作５０３において、スライディング・ウインドウを進ませるための各単位時間が経過することにより、スライディング・ウインドウが進むかどうかが判断される。動作５０３において、スライディング・ウインドウを進めると判断された場合、動作５０４において、ネットワークノードにおけるリソース予約状況のすべての動的な変化に基づいて、スライディング・ウインドウの新規サブ・ポーションのための新規サブカウントが、各予約カウントについて演算される。このように、新たな予約サブカウントは、すべての新規データフローの記述子の予約関数を演算することと、解放されたデータフローのリソースを予約カウントから削除することを含み、さらにまた、リフレッシュされたデータフローの記述子に関して演算された予約関数を含む。図３の動作３０２に関して述べたように、リフレッシュ要求は、さらに維持されることになる、対応するフローの記述子を含んでもよく、従って、新たな予約サブカウントは、リフレッシュされたデータフローのリソースをも表す。従って、上で概説したように、スライディング・ウインドウが進むにつれて、新たな予約サブカウントが演算され、以前の実施形態に関して記述した手順に従って承認された、すべての新規に承認されたデータフローと、リフレッシュされたデータフローと、そして、明示的に解放されたデータフローとについてのリソースを、統合されたかたちで反映する。

新たな単位時間についての新たな予約サブカウントを演算するのと並行して、リフレッシュされたデータフローのためのリソースを予約カウントの中に重複して表すのを回避する目的で、最も古い予約サブカウントが破棄される。最も古い予約サブカウント、すなわち、スライディング・ウインドウを１単位時間だけ進ませるともはやスライディング・ウインドウの一部を形成していない予約カウントは、２つ以上のリフレッシュ時間またはスライディング・ウインドウの存続時間が経過したフローのために予約された、すべてのリソースを表す。この時間内にリフレッシュされたあらゆるフローは、スライディング・ウインドウの予約サブカウントの１つの中に表されるであろうし、従って、最も古い予約サブカウントを削除することは、すべてのリフレッシュされていないデータフローに関する予約状態を予約カウントから削除することに効果的につながるであろう。

従って、各フローの記述子に関する明示的な情報がなくても予約状態が統合的なかたちで維持されるとしても、リフレッシュされていないフローを予約カウントから削除することができる。

上記の実施形態は、スライディング・ウインドウの技法の中で一般的な承認制御方式の枠組みを用いるシステムを導入する。上記の実施形態は、統合された変数で予約カウントを実装することによって、データフローについての効率的なリソースの活用を提供する。変数や予約カウントの数が、フローの数に依存しないので、導入された技法は任意に拡張できる。

別の例によると、ネットワークノードは、図１に関して概説したような、少なくともリソースマネージャとフロー制御ユニットとを含むＩＰ（インターネットプロトコル）ルータである。フロー制御ユニットは、上に概説した、記述子の複数の総和構成体および乗算構成体として表される承認制御方式を実装した承認制御ユニットを含んでもよい。着信するリソース要求は、リソースマネージャで処理されてもよいし、承認制御ユニットは、承認制御決定を行ってもよい。決定が肯定である場合、要求されたリソースが、リソースマネージャの中の対応する統合されたリソースに追加され、対応するフローがフロー制御ユニットによって承認される。上記のいくつかの例は、個別のフローの記述子を記憶することを回避するため、統合的なやり方で記述子と、それらの関数と、総和構成体および乗算の構成体とを維持する方法を開示する。

本発明は特に、前に概説したように、基礎をなすトランスポートネットワークに厳密な要件を課すストリーミングメディア・アプリケーションに適用できる。従って、新規フローの承認を決定するタスクは、以前に承認されたフローを妨害することを回避する必要がある。例えば、一元制御をせずに、インターネットの分散知識プリンシパルを考慮すると、承認決定は、上記で開示したように、各通信ノードにおいてホップバイホップで行われることが好ましい。また、新規フローについての要求は、いつでもどこでも通信ノードに着信する可能性があるので、決定は、発信元の要求に基づいて、オンデマンドで行われなければならない。

上述の実施形態は、ネットワーク要素がエッジノードとコアノードに分類されるような、サービスが細分化されたネットワークにとって特に有益である。エッジノードは、フロー毎の状態を用いること、すなわち、承認された各フローに関連する記述子を記憶することが許可され、他方、コアノードは、予約カウントを使って上で記述したように、統合された変数を記憶することだけが認められる。従って、上記の実施形態に関して記述したネットワークノードは、サービスが細分化されたネットワークにおけるコアノードを構成することができる。

ピークレート、平均レート、アクティビティ因子などのような、承認されることになるフローの記述子は、ネットワーク内で利用可能なリソース予約シグナリング・プロトコルを用いて信号で送られる。

予約状態は、統合されたソフト状態として扱われるため、一定のリフレッシュ時間内にリフレッシュされなかった予約は、図５に関して概説したように、一定の時間が経過した後、統合された予約状態から自動的に削除される。

本発明の一実施形態による、リソース予約のための通信システムの要素を図解する図である。 本発明の一実施形態による、通信ネットワーク内のデータフローのためにリソースを予約する方法の予約について図解する図である。 本発明の別の実施形態による、リソース予約の方法の動作を図解する図であり、特にデータフローを解放することを図解する図である。 本発明の別の実施形態による、リソース予約の方法の動作を図解する図であり、特に予約カウントを更新することを図解する図である。そして、 本発明の別の実施形態による、通信ネットワーク内でのリソース予約の方法の動作を図解する図であり、特にスライディング・ウインドウアルゴリズムに関して予約サブカウントを維持することを図解する図である。

Claims (21)

1. 通信ネットワークにおけるデータフローのためのリソース予約の方法であって、
   新たなデータフローのための、要求されるリソースを数値で指定する複数の記述子を含むリソース予約要求（１５１）を検出するステップと、
   前記新たなデータフローの前記複数の記述子と、すべての承認されたデータフローに関する統合的なリソースを指定する予約カウントと、に基づいて承認テストカウントを演算するステップであって、各予約カウントは総和関数または乗算関数を表し、前記総和関数は前記承認されたデータフローの複数の記述子を変数として有する関数の総和で構成され、前記乗算関数は前記承認されたデータフローの複数の記述子を変数として有する関数の積で構成されるステップと、
   前記承認テストカウントが前記複数の記述子のための最大承認カウントよりも小さい場合に前記新たなデータフローを承認するステップと、
   前記新たなデータフローが承認された場合に前記新たなデータフローの前記複数の記述子に基づいて前記予約カウントを更新するステップと、
   を備えることを特徴とする方法。
2. 前記予約カウントを更新する前記ステップは、
   前記新たなデータフローの前記記述子の総和関数を前記予約カウントに加えるステップ、または、
   前記予約カウントに前記新たなデータフローの前記記述子の乗算関数を乗じるステップ
   を含むことを特徴とする請求項１に記載の方法。
3. 前記承認されたデータフローのうちの１つに対する解放命令が受信された場合に、対応する記述子に基づいて各予約カウントを更新するステップを含むことを特徴とする請求項１または２に記載の方法。
4. データフローを解放することが、
   前記解放されるデータフローの記述子の総和関数を前記予約カウントから減算すること、または、
   前記解放されるデータフローの記述子の乗算関数で前記予約カウントを除算すること
   を含むことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 所定の期間を有するリフレッシュ・ウインドウの間に承認またはリフレッシュされたデータフローに基づいて各予約カウントを演算するステップを含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記リフレッシュ・ウインドウの間にデータフローに関するリフレッシュ要求（１５１）が受信されない場合、または明示的な解放命令が受信された場合に、前記データフローを解放するステップを含むことを特徴とする請求項５に記載の方法。
7. 各予約カウントが複数のサブカウントを含み、各サブカウントは前記リフレッシュ・ウインドウの隣接するサブ・ポーションの間に承認またはリフレッシュされたデータフローに基づいており、サブ・ポーションは前記リフレッシュ・ウインドウを進める単位時間に対応することを特徴とする請求項５または６に記載の方法。
8. 前記リフレッシュ・ウインドウを１単位時間だけ進めると新たなサブカウントが生成されて最も古いサブカウントが削除されることを特徴とする請求項５乃至７のいずれか１項に記載の方法。
9. 測定された帯域幅の合計、前記新たなデータフローのピークレート、および前記新たなデータフローのピークレートと前記承認されたデータフローのピークレートとの合計に基づいて、承認テストベクトルを演算するステップを含むことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 請求項１乃至９のいずれか１項に記載の方法を実行するように適合された命令を有するプログラム。
11. 中央サーバおよび少なくとも１つのコンテンツサーバを含むコンピュータシステムに請求項１乃至９のいずれか１項に記載の方法を実行させるプログラムを収録したコンピュータ読み取り可能な媒体。
12. 請求項１１に記載のコンピュータ読み取り可能な媒体を有するコンピュータプログラム製品。
13. 通信ネットワークにおけるデータフローのためのリソース予約のためのネットワークノードであって、
    新たなデータフローのための、要求されるリソースを数値で指定する複数の記述子を含むリソース予約要求（１５１）を検出し、前記新たなデータフローの前記複数の記述子と、すべての承認されたデータフローに関する統合的なリソースを指定する予約カウントと、に基づいて承認テストカウントを演算するリソースマネージャ（１１０）であって、各予約カウントは総和関数または乗算関数を表し、前記総和関数は前記承認されたデータフローの複数の記述子を変数として有する関数の総和で構成され、前記乗算関数は前記承認されたデータフローの複数の記述子を変数として有する関数の積で構成されるリソースマネージャ（１１０）と、
    前記承認テストカウントが前記複数の記述子のための最大承認カウントよりも小さい場合に前記新たなデータフローを承認するデータフロー制御ユニット（１０２）であって、前記最大承認カウントは最大予約カウントの承認関数を構成するデータフロー制御ユニット（１０２）と、
    を備え、
    前記リソースマネージャ（１１０）は、前記新たなデータフローが承認された場合に前記新たなデータフローの前記複数の記述子に基づいて前記承認テストカウントを更新するように構成される
    ことを特徴とするネットワークノード。
14. 前記リソースマネージャ（１１０）は、
    前記新たなデータフローの前記記述子の総和関数を前記予約カウントに加えるか、または、
    前記予約カウントに前記新たなデータフローの前記記述子の乗算関数を乗じる
    ことによって、前記予約カウントを更新するように構成される
    ことを特徴とする請求項１３に記載のネットワークノード。
15. 前記リソースマネージャ（１１０）は、前記承認されたデータフローのうちの１つに対する解放命令が受信された場合に、対応する記述子に基づいて各予約カウントを更新するように構成されることを特徴とする請求項１３または１４に記載のネットワークノード。
16. 前記データフロー制御ユニット（１０２）は、
    解放されるデータフローの記述子の総和関数を前記予約カウントから減算するか、または、
    前記解放されるデータフローの記述子の乗算関数で前記予約カウントを除算する
    ことによって、データフローを解放するように構成される
    ことを特徴とする請求項１３乃至１５のいずれか１項に記載のネットワークノード。
17. 前記リソースマネージャ（１１０）は、所定の期間を有するリフレッシュ・ウインドウの間に承認またはリフレッシュされたデータフローに基づいて各予約カウントを演算するように構成されることを特徴とする請求項１３乃至１６のいずれか１項に記載のネットワークノード。
18. 各予約カウントが複数のサブカウントを含み、各サブカウントは前記リフレッシュ・ウインドウの隣接するサブ・ポーションの間に承認またはリフレッシュされたデータフローに基づいており、サブ・ポーションは前記リフレッシュ・ウインドウを進める単位時間に対応することを特徴とする請求項１７に記載のネットワークノード。
19. 前記リソースマネージャ（１１０）は、前記リフレッシュ・ウインドウの間にデータフローに関するリフレッシュ要求（１５１）が受信されない場合、または明示的な解放命令が受信された場合に、前記データフローを解放するように構成されることを特徴とする請求項１７または１８に記載のネットワークノード。
20. 前記リソースマネージャ（１１０）は、前記リフレッシュ・ウインドウを１単位時間だけ進めると新たなサブカウントを生成して最も古いサブカウントを破棄するように構成されることを特徴とする請求項１７乃至１９のいずれか１項に記載のネットワークノード。
21. 前記リソースマネージャ（１１０）は、測定された帯域幅の合計、前記新たなデータフローのピークレート、および前記新たなデータフローのピークレートと前記承認されたデータフローのピークレートとの合計に基づいて、承認テストベクトルを演算するように構成されることを特徴とする請求項１３乃至２０いずれか１項に記載のネットワークノード。

Images