(57)【要約】【課題】  オペレータが、ユーザに対する課金を計算するために、個別の料金体系に適用できる必要なコスト情報を収集できるようにする。【解決手段】  マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するためにネットワークをプローブする方法は、ダウンストリームデバイスからアップストリームデバイスに向けてプローブクエリメッセージを送信するステップと、アップストリームデバイスがプローブクエリメッセージを受信し、アップストリームデバイスが既にセッションに関するトラフィックを受信しつつある場合にセッションのローカル情報をダウンストリームデバイスのアドレスで更新し、新たなセッションの初期単位コストを概算するステップと、プローブクエリメッセージの送信元に対してプローブアンサメッセージを返すステップとを含む。【選択図】図１
2010035203.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するためにネットワークをプローブする方法であって、
前記セッションの単位帯域幅当たりのコストとして前記単位コストを取得するために、ダウンストリームデバイスからセッション内のソースの方向に位置するアップストリームデバイスに向けて、前記新たなセッションに関する情報を含んだプローブクエリメッセージを送信するステップと、
前記アップストリームデバイスが前記プローブクエリメッセージを受信し、前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しつつある場合に、前記新たなセッションの単位コストを概算するステップと、
前記プローブクエリメッセージの送信元に対して前記セッションの初期単位コストに関する情報を返すために、前記プローブクエリメッセージの送信元に対してプローブアンサメッセージを返すステップと
を含む方法。
【請求項２】
前記アップストリームデバイスが前記セッションに関するトラフィックをまだ受信していない場合に、前記ダウンストリームデバイスのアドレスに関する情報に加えて新たなセッションのチャネルに関する情報を記憶するステップと、
前記プローブクエリメッセージを、配信するセッションのソースの方向へと更に転送するステップと
を更に含む請求項１に記載の方法。
【請求項３】
前記アップストリームデバイスにおける利用可能な全帯域幅に関する全コストと、前記利用可能な全帯域幅の割合としての単位レートとに基づいて、前記単位コストを概算するステップであって、前記単位コストは単位帯域幅当たりの送信コストである、ステップを更に含む請求項１または２に記載の方法。
【請求項４】
前記プローブアンサメッセージをダウンストリーム方向へと返すステップを更に含み、
前記新たなセッションの宛て先へと向かう途中で経由する各ダウンストリームデバイスにおいて、前記プローブアンサメッセージ内の前記単位コストは更新されるものである、
請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記単位コストを更新するステップは、
単位ダウンストリームコストの合計を取得するために、前記プローブアンサメッセージを介して受信したローカル単位アップストリームコストと、ローカル単位ダウンストリームコストとを加えるステップ
を含むものである、請求項４に記載の方法。
【請求項６】
前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しているかどうかのチェックと、前記単位コストの概算と、前記プローブアンサメッセージの生成とは、あるネットワーク内のエッジに位置するネットワークデバイスによってのみ行われるものである、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
あるネットワーク内のエッジに位置していない中間のネットワークデバイスは、前記プローブクエリメッセージと前記プローブアンサメッセージとを透過的に転送するものである、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
前記プローブクエリメッセージと前記プローブアンサメッセージと単位コスト情報とは、ペイロード送信のために確保されているフィールドとは異なる、既存のネットワークプロトコルの一つ以上の空きフィールドによって搬送されるものである、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
あるアップストリームデバイスから、セッションの単位コストに関する情報を含んだプローブアンサメッセージを受信するステップと、
前記プローブアンサメッセージを受信したデバイスにおいて、前記プローブアンサメッセージにより搬送された、セッションに関する単位コストを更新するステップと、
前記セッションの宛て先へと前記プローブアンサメッセージを転送するステップと
を更に含む請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
前記プローブクエリメッセージを受信する各アップストリームデバイスにおいて、前記新たなセッションとその宛て先とそのチャネルとに関する情報と、前記プローブクエリメッセージの送信元であるダウンストリームデバイスに関する情報とを記憶するために、セッション情報を更新するステップを更に含む請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
あるアップストリームデバイスが、あるプローブクエリメッセージによって特定される前記新たなセッションに関するトラフィックを受信していない一方で、該プローブクエリメッセージを受信すると、タイマーをセットするステップと、
前記新たなセッションに関して前記タイマーが終了した場合、該セッションに関するレートがまだゼロであるならば、該セッションに関して記憶されている情報を消去するステップと
を更に含む請求項１〜１０のいずれか一項に記載の方法。
【請求項１２】
あるセッションを特定する情報と、あるセッションのコストに関する情報とは、前記ネットワーク内のエッジデバイスにのみ記憶されるものである、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
あるネットワーク内のデバイスのうちのエッジデバイスのみが、前記プローブクエリメッセージと前記プローブアンサメッセージとを生成するものである、請求項１〜１２のいずれか一項に記載の方法。
【請求項１４】
マルチキャストネットワークを介して受信機へ配信される、複数のチャネルを含むセッションに関する受信データレートを受信機ベースで制御する方法であって、
単位コストと、各チャネルのレートと、送信コストに関するバジェットとに基づいて、バジェットにより許容されるチャネルの数を決定するステップと、
バジェットを考慮することに基づいて、セッションに対して許容可能な数だけチャネルを実行するステップと
を含む方法。
【請求項１５】
前記単位コストは請求項１〜１３のいずれか一項に記載の方法によって決定されるものである、請求項１４に記載の方法。
【請求項１６】
許容可能なチャネルは、前記バジェットと、個々のチャネルの優先度とに基づいて決定されるものである、請求項１４または１５に記載の方法。
【請求項１７】
宛て先においてセッションを開始するための開始信号に応じて、前記セッションの単位コストについてクエリするためにプローブクエリメッセージを生成し、該プローブクエリメッセージを前記セッションのソースに向けて転送するステップと、
前記セッションのソースの方向に位置し、前記単位コストに関する情報を有するアップストリームデバイスからプローブアンサメッセージを受信するステップと、
受信した情報に基づいて、最も高い優先度を有するチャネルから開始して前記セッションに対して決定されたバジェットにより許容可能な数のチャネルに加入するステップと
を更に含む請求項１４〜１６のいずれか一項に記載の方法。
【請求項１８】
前記セッションの宛て先において、前記セッションのコストに関する、更新された情報を含んだコスト調整メッセージを繰り返し受信するステップと、
更新されたコストが前記セッションに対するバジェットより低い場合に、前記バジェットにより許容可能な範囲でさらなるチャネルに加入するステップと、
前記更新されたコストがバジェットより高い場合に、最も低い優先度を有するチャネルから開始してバジェットを満たすまで、前記セッションからチャネルを加入取消しするステップと
を更に含む請求項１４〜１７のいずれか一項に記載の方法。
【請求項１９】
前記ネットワークは、サービスの異なるクラスと、あるクラスに属するセッションと、割当てられた全ての価値および対応する全帯域幅を有するクラスとを処理することができるものであり、
あるセッションに対し、単位コストは該セッションが属するクラスに応じて概算されるものである、
請求項１〜１８のいずれか一項に記載の方法。
【請求項２０】
マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するために、ネットワークをプローブする装置であって、
前記セッションの単位帯域幅当たりのコストとして単位コストを取得するために、ダウンストリームデバイスからセッション内のソースの方向に位置するアップストリームデバイスに向けて、前記新たなセッションに関する情報を含んだプローブクエリメッセージを送信する送信ユニットと、
前記アップストリームデバイスが前記プローブクエリメッセージを受信し、前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しつつある場合に、前記新たなセッションの単位コストを概算する受信ユニットと、
前記プローブクエリメッセージの送信元に対してセッションの初期単位コストに関する情報を返すために、前記プローブクエリメッセージの送信元へとプローブアンサメッセージを返す応答ユニットと
を備える装置。
【請求項２１】
前記アップストリームデバイスが前記セッションに関するトラフィックをまだ受信していない場合に、前記ダウンストリームデバイスのアドレスに関する情報に加えて新たなセッションのチャネルに関する情報を記憶し、前記プローブクエリメッセージを、配信するセッションのソースの方向へと更に転送する記憶ユニットを更に備える請求項２０に記載の装置。
【請求項２２】
前記アップストリームデバイスにおいて利用可能な全帯域幅に関する全コストと、前記利用可能な全帯域幅の割合としての単位レートとに基づいて、前記単位コストを概算する概算ユニットであって、前記単位コストは単位帯域幅当たりの送信コストである、概算ユニットを更に備える請求項２０または２１に記載の装置。
【請求項２３】
前記プローブアンサメッセージをダウンストリーム方向へと返す返却ユニットと、
前記プローブアンサメッセージが前記新たなセッションの宛て先へと向かう途中で通過する各ダウンストリームデバイスにおいて、前記単位コストを更新する更新ユニットと
を更に備える請求項２０〜２２のいずれか一項に記載の装置。
【請求項２４】
前記更新ユニットは、単位ダウンストリームコストの合計を得るために、プローブアンサメッセージを介して受信したローカル単位アップストリームコストと、ローカル単位ダウンストリームコストとを加えるものである、請求項２３に記載の装置。
【請求項２５】
前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しているかどうかの前記チェックと、前記単位コストの概算と、前記プローブアンサメッセージの生成とは、あるネットワーク内のエッジに位置するネットワークデバイスによってのみ実行されるものである、請求項２０〜２４のいずれか一項に記載の装置。
【請求項２６】
あるネットワーク内のエッジに位置していない中間のネットワークデバイスは、前記プローブクエリメッセージと前記プローブアンサメッセージとを透過的に転送するものである、請求項２０〜２５のいずれか一項に記載の装置。
【請求項２７】
前記プローブクエリメッセージと前記プローブアンサメッセージと前記単位コストに関する情報は、ペイロード送信のために確保されているフィールドとは異なる、既存のネットワークプロトコルの一つ以上の空きフィールドによって搬送されるものである、請求項２０〜２６のいずれか一項に記載の装置。
【請求項２８】
セッションの単位コストに関する情報を含んだプローブアンサメッセージをアップストリームデバイスから受信する受信ユニットと、
前記プローブアンサメッセージを受信したデバイスにおいて、前記プローブアンサメッセージにより搬送されたセッションの単位コストを更新する更新ユニットと、
前記セッションの宛て先に向けて前記プローブアンサメッセージを転送する転送ユニットと
を更に備える請求項２０〜２７のいずれか一項に記載の装置。
【請求項２９】
前記プローブクエリメッセージを受信した各アップストリームデバイスにおいて、前記新たなセッションとその宛て先とそのチャネルとに関する情報と、前記プローブクエリメッセージの送信元であるダウンストリームデバイスに関する情報とを記憶するために、セッション情報を更新するユニットを更に備える請求項２０〜２８のいずれか一項に記載の装置。
【請求項３０】
プローブクエリメッセージにより特定される前記新たなセッションに関するトラフィックを受信していない一方で、アップストリームデバイスが前記プローブクエリメッセージを受信した場合にタイマーをセットし、
前記新たなセッションに関して前記タイマーが終了した場合に、該セッションに関するレートがまだゼロであれば、該セッションに対して記憶されている情報を消去する
タイミングユニットを更に備える請求項２０〜２９のいずれか一項に記載の装置。
【請求項３１】
セッションを特定する情報とセッションのコストに関する情報とは、前記ネットワーク内のエッジデバイスにのみ記憶されるものである、請求項２０〜３０のいずれか一項に記載の装置。
【請求項３２】
あるネットワーク内のデバイスのうちの前記エッジデバイスのみが、前記プローブクエリメッセージと前記プローブアンサメッセージとを生成するものである、請求項２０〜３１のいずれか一項に記載の装置。
【請求項３３】
マルチキャストネットワークを介して受信機に配信される、複数のチャネルを含むセッションの受信データレートを受信機ベースで制御する装置であって、
単位コストと、各チャネルのレートと、送信コストに関するバジェットとに基づいて、バジェットにより許容されるチャネルの数を決定し、バジェットを考慮することに基づいてセッションに対し許容可能な数のチャネルを実行する決定ユニット
を備える装置。
【請求項３４】
前記単位コストは請求項２０〜３２のいずれか一項に記載の装置によって決定されるものである、請求項３３に記載の装置。
【請求項３５】
許容可能なチャネルは、前記バジェットと個々のチャネルの優先度とに基づいて決定されるものである、請求項３３または３４に記載の装置。
【請求項３６】
宛て先においてセッションを開始するための開始信号に応じて、セッションの単位コストについてクエリするためにプローブクエリメッセージを生成し、該プローブクエリメッセージを前記セッションのソースへと転送する生成ユニットと、
セッションのソースの方向に位置し、単位コストに関する情報を有するアップストリームデバイスからプローブアンサメッセージを受信する受信ユニットと、
受信した情報に基づいて、最も高い優先度を有するチャネルから開始して、前記セッションに対して決定されたバジェットにより許容可能な数のチャネルに加入する加入ユニットと
を更に備える請求項３３〜３５のいずれか一項に記載の装置。
【請求項３７】
セッションの宛て先において、前記セッションのコストに関する、更新された情報を含んだコスト調整メッセージを繰り返し受信する受信ユニットと、
更新されたコストが前記セッションに関するバジェットより低い場合に、前記バジェットにより許容可能な更なるチャネルに加入する加入ユニットと、
前記更新されたコストが前記バジェットより高い場合に、最も低い優先度を有するチャネルから開始してバジェットが満たされるまで、前記セッションからチャネルを加入取消しする加入取消しユニットと
を更に備える請求項３３〜３６のいずれか一項に記載の装置。
【請求項３８】
前記ネットワークは、サービスの異なるクラスと、あるクラスに属するセッションと、全ての価値および対応する全帯域幅を割り当てられているクラスとを処理することができるものであり、
前記単位コストは、あるセッションに関して該セッションが属するクラスに依存して概算されるものである、
請求項３３〜３７のいずれか一項に記載の装置。
【請求項３９】
コンピュータ上で、請求項１〜１９のいずれか一項に記載の方法を実行することを可能にするコンピュータ実行可能なコードを含むコンピュータプログラム。
【請求項４０】
請求項３９に記載のコンピュータプログラムを記憶または具現化するデータキャリア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスト送信、具体的にはマルチキャスト送信コストの管理に関する。
【背景技術】
【０００２】
マルチキャスト送信またはマルチキャストルーティングは、効率良くネットワークを使用するための方法である。マルチキャストルーティングにおいては、ソースといくつかの受信機とを接続するツリー型のパスが作られる。このツリーはノードを含んでおり、ソースから受信機の各々に向けて送信パスが存在するよう分岐している。このツリー構造によれば、パスが分岐しているツリー内の異なる受信機からあるノードまでの送信パスは、部分的に同一となる。ツリー内の各リンクを介してパケットのコピーを一つだけ送信することにより、ある一定のネットワーク効率を実現できる。各分岐点においてパケットは複製され、パケットのコピーは各ダウンストリームリンクを通して送信される。ここで、「ダウンストリーム」とは、ソースから受信機への方向を指し、「アップストリーム」とは、受信機からソースへの方向を指すものとする。
【０００３】
図１は、マルチキャスト送信に使われるネットワーク構成を模式的に示している。図１では、三つの異なる個別のネットワーク１００と１０５と１１０とが示されている。これらは例えば、ＩＰアドレス空間内の異なるドメインによって分離されているネットワークである。つまり、これらは三つの異なるタイプのネットワーク、例えばネットワーク１００はＬＡＮであり、ネットワーク１０５はモバイルネットワークであり、ネットワーク１１０は無線ＬＡＮネットワークである。
【０００４】
ネットワーク１００には、「ダウンストリーム」、つまり受信機に向けて情報を配信できる任意のサーバである、配信するセッションのソース１１５が配置されている。このソースは例えば、異なるチャネルを有するビデオストリーミングサーバ、（同様に異なるチャネルを有する）ニュースサーバ、または情報もしくはサービスのプロバイダである。
【０００５】
受信機１２０は、ダウンストリームに配信された情報を受信するＰＣ、ＰＤＡ、携帯電話といったデバイスである。マルチキャスト送信する際のダウンストリームにおいて、あるパケットは一度だけ、できるだけ長く配信される。例えば図１では、ソース１１５からネットワーク１０５内のエッジデバイス１２５に向けて必要な場合にのみパケットが配信される。例えばデバイス１２５においてパケットは複製され、中間ルータ１３０または他のエッジデバイス１３５に向けて別々に配信される。ルータ１３０において二つのダウンストリームリンクへの更なる分割が行われ、複製されたパケットはこのルータからエッジデバイス１４０および１４５に別々に送信される。つまり、パケットはツリー内の各リンクを通して一回送信される。
【０００６】
説明のため、以下マルチキャストルーティングとは、ＩＰマルチキャスト規格に限らず、ツリー内の各リンク上でパケットのコピーを一つだけ送信できる任意の方法を意味することに注意されたい。
【０００７】
前述したことから明らかなように、大量のデータを多数の受信機にマルチキャストすることは、ネットワーク内の各分岐点においてマルチキャストトラフィックが複製されるために、大きなコストが必要となる。ネットワークリソースは例えば帯域幅の点で常に限られている。したがってネットワーク使用の増加は、コストの増加とおそらくは信頼性の低下とをもたらす。マルチキャストルーティングによって生じるネットワークトラフィックは大きな関心事であり、何らかの対策をする必要がある。したがって、以下において「コスト」、「セッションのコスト」または「ネットワークコスト」という用語を使うときは、単に経済的な観点または概念を意味するばかりでなく、（それぞれの）ネットワークのリソースが限られているということと、蓄積されたリソースはある価値を反映するということとを意味している。ここで、この価値の一部は、それぞれの送信により使用されるものであって、これにより全体的なネットワークの「価値」の割合という意味で「コスト」に対応するものである。
【０００８】
ネットワークリソースの割合に対応するパラメータである「コスト」の概念は、「料金（ｃｈａｒｇｉｎｇ）」、つまり、あるユーザへの料金請求、または対応する金銭的価値に対する「コスト」の割当てという更に経済的な概念とは区別しなければならない。
【０００９】
したがって、料金とコストという概念を区別することは重要である。料金は、顧客から支払われる額を指す。料金体系または課金体系（ｃｈａｒｇｉｎｇ  ｓｃｈｅｍｅ）は、コストと、マーケット構造および価格安定性などの他の問題とに基づいている。これに対してコストは、オペレータによってネットワークリソースに与えられる価値を指している。本発明は、ネットワークトラフィックのマルチキャストセッションに関するコストを監視し、制御し、管理するための方法に関する。これに基づいてネットワークのプロバイダまたはオペレータは、独自の料金体系を適用できる。
【００１０】
一例として将来、基本的なサービスから高度なサービスまでのある範囲のネットワークサービスが生まれる可能性がある。基本的なサービスは、ユニバーサルな接続性を有するものの品質の保証はない現在のベストエフォートサービスに似ている。高度なサービスは、確実な品質レベルまたは保証された品質レベルを提供するものである。
【００１１】
ネットワークで使用される料金体系を決めるのは、各プロバイダである。例えば、ユーザには基本的および高度なネットワークサービスの区別が提供される。これは、ユーザが、基本的なサービスに対して均一料金を支払い、広帯域幅などの高度のサービスが要求に応じて得られる料金体系が存在することを意味する。均一料金は、ユーザが生成または消費するトラフィックとは別に、あるサービスに加入するためだけに支払う料金である。
【００１２】
生成または消費されたトラフィックに対してのみクライアントが支払う場合、利用ごとの料金が適用される。利用ごとの料金は、静的または動的に決定される。前者の方法は時間帯および宛て先などの要素に基づいているが、後者の方法はリソースの現在の要求と全体的なネットワーク負荷とに基づいている。
【００１３】
マルチキャストトラフィックに適したコスト割当てスキーム（ｃｏｓｔ  ａｌｌｏｃａｔｉｏｎ  ｓｃｈｅｍｅ）を表す幾つかのアプローチがある。非特許文献１には、受信機間でコストを配分する均等リンク配分ダウンストリーム（Ｅｑｕａｌ  Ｌｉｎｋ  Ｓｐｌｉｔ  Ｄｏｗｎｓｔｒｅａｍ）と呼ばれるスキームが提案されている。しかしながらこのスキームは、ネットワーク内の全てのルータの変更が必要になるなど幾つかの欠点を有しており、マルチキャストセッションのダイナミクスに対応する方法には触れていない。
【００１４】
非特許文献２には、単一レベルのサービスを有するネットワーク内のセッションの受信機間でコストの柔軟な配分を可能にするスキームが記載されている。各セッションのコストを計算して配分するために、各ドメインに配置されたサーバに基づくメカニズムが提案されている。しかしながらこれは、受信機間でコストを配分するために用いるメカニズムには触れていない。更にこのアプローチは、異なる品質レベルを有するサービスを提供できるネットワーク内での使用には適しておらず、各ドメインに配置されているサーバは単一障害点（ｓｉｎｇｌｅ  ｐｏｉｎｔ  ｏｆ  ｆａｉｌｕｒｅ）となる。
【００１５】
非特許文献３においては、ＡＴＭネットワーク内のマルチキャストトラフィックに課金するための階層化フレームワークが提案されている。料金情報は、受信機から送信機へのパスにおいてマージされるＲＳＶＰ（ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ：予約プロトコル）メッセージで送られる。コストは予約メッセージに含まれている情報に基づいて送信側に割り当てられるが、このフレームワークは受信機間でコストを配分する方法に触れていない。更にこのアプローチの場合も、全てのルータの変更が必要となる。
【００１６】
非特許文献４には、受信品質の適応化に関して、最初の受信機駆動型適応メカニズムであった受信機駆動型階層化マルチキャスト（Ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ  Ｌａｙｅｒｅｄ  Ｍｕｌｔｉｃａｓｔ：ＲＬＭ）が開示されている。あるセッションに含まれるチャネルの数は、パケットロスの数によって表されるサービスの品質が何らかの限界を示さない限り、パケットロスなどのパラメータに基づいて増加する。しかしながらＲＬＭは、品質の上限に関する閾値を決定する際にユーザの如何なる予算あるいはバジェット（ｂｕｄｇｅｔ）も考慮しておらず、更にはチャネル数を増加させる漸進的なアプローチであるために長い収束時間を有する。
【先行技術文献】
【非特許文献】
【００１７】
【非特許文献１】Ｈｅｒｚｏｇ  ｅｔ  ａｌ．，「Ｓｈａｒｉｎｇ  ｔｈｅ  『ｃｏｓｔ』  ｏｆ  ｍｕｌｔｉｃａｓｔ  ｔｒｅｅｓ：ａｎ  ａｘｉｏｍａｔｉｃ  ａｎａｌｙｓｉｓ」，  ＩＥＥＥ／ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｎｅｔｗｏｒｋｉｎｇ，５（６）：８４７−８６０，Ｄｅｃｅｍｂｅｒ  １９９７
【非特許文献２】Ｈｅｎｄｅｒｓｏｎ  ｅｔ  ａｌ．，「Ｐｒｏｔｏｃｏｌ−ｉｎｄｅｐｅｎｄｅｎｔ  ｍｕｌｔｉｃａｓｔ  ｐｒｉｃｉｎｇ」，  Ｐｒｏｃ．  ｏｆ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｎｅｔｗｏｒｋｉｎｇ  ａｎｄ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｓｕｐｐｏｒｔ  ｆｏｒ  Ｄｉｇｉｔａｌ  Ａｕｄｉｏ  ａｎｄ  Ｖｉｄｅｏ（ＮＯＳＳＤＡＶ），  Ｃｈａｐｅｌ  ＨＩＬＬ，  Ｎｏｒｔｈ  Ｃａｒｏｌｉｎａ，  ＵＳＡ，  Ｊａｎｕａｒｙ  ２０００
【非特許文献３】Ｃａｒｌｅ  ｅｔ  ａｌ． 「Ｃｈａｒｇｉｎｇ  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ  ｆｏｒ  ＱｏＳ−ｅｎｈａｎｃｅｄ  ＩＰ  ｍｕｌｔｉｃａｓｔ」，Ｐｒｏｃ．  Ｏｆ  ＩＦＩＰ  ６ＴＨ  ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ｈｉｇｈ−Ｓｐｅｅｄ  Ｎｅｔｗｏｒｋ」，  Ｓａｌｅｍ，  Ｍａｓｓａｃｈｕｓｅｔｔｓ，  ＵＳＡ，  Ａｕｇｕｓｔ  １９９９
【非特許文献４】ＭｃＣａｎｎｅ  ｅｔ  ａｌ．  「Ｒｅｃｅｉｖｅｒ  ｄｒｉｖｅｎ  Ｍｕｌｔｉｃａｓｔ」，Ｐｒｏｃ．  Ｏｆ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ（ＳＩＧＣＯＭＭ），  Ｐａｌｏ  Ａｌｔｏ，  ＵＳＡ，  Ａｕｇｕｓｔ  １９９６
【発明の概要】
【発明が解決しようとする課題】
【００１８】
料金体系を決めるためオペレータは、利用ごとの料金を計算するために送信コストに関する情報が必要である。更に均一的料金体系を定期的に更新するために正確な情報が有用である。したがって、本発明の目的は、オペレータが、ユーザに対する課金を計算するために、個別の料金体系に適用できる必要なコスト情報を収集できるようにすることである。
【００１９】
本発明の一実施形態に基づくマルチメディアアプリケーションによるレート適応システムは、ある程度の品質低下を許容するものである。しかしながら、許容の程度はマルチメディアセッションのコストに依存する。したがって、ユーザが進んで支払うのは幾らであるかを考慮しながらレート適応を制御すること、つまりユーザのバジェットを考慮することが重要である。更にネットワークにおける送信コストに関する情報を取得する必要性がある。
【課題を解決するための手段】
【００２０】
一実施形態によれば、マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するためにネットワークをプローブする方法であって、前記セッションに関する単位コストを取得するためにダウンストリームデバイスからセッションのソースの方向に配置されたアップストリームデバイスに向けて、前記新たなセッションに関する情報を含むプローブクエリメッセージを送信するステップと、前記アップストリームデバイスが前記セッションのためのトラフィックを既に受信しつつある場合に前記アップストリームデバイスが前記プローブクエリメッセージを受信し、ダウンストリームデバイスのアドレスでセッションのローカル情報を更新し、新たなセッションの単位コストを概算するステップと、プローブクエリメッセージの送信元に対してセッションの初期単位コストに関する情報を返すために、プローブクエリメッセージの送信元に対してプローブアンサメッセージを返すステップとを含む方法が提供される。
【００２１】
本実施形態により得られた単位コストは、チャネルに与えられたセッションのコストと、個々のチャネルの送信レートとを計算するために使用できる。
【００２２】
一実施形態によれば前記方法は、前記アップストリームデバイスが前記セッションのためのトラフィックをまだ受信していない場合にダウンストリームデバイスのアドレスに関する情報に加えて前記新たなセッションのチャネルに関する情報を記憶するステップと、セッションのソースの方向に更にプローブクエリメッセージを転送するステップとを含む。
【００２３】
これにより、セッションが既に張られているアップストリームデバイスを見出すことを可能にし、それによって新たなセッションのためのマルチキャスト送信が可能になる。
【００２４】
一実施形態によれば前記方法は、前記アップストリームデバイスにおける利用可能な全帯域幅に対する全コストと前記利用可能な全帯域幅の割合としての単位料金とに基づいて、単位帯域幅当たりの送信コストである前記単位コストを概算するステップを含む。
【００２５】
これは、ネットワーク内のあるデバイスにおける所与の経済的な境界条件下の単位コストの決定を可能にする。
【００２６】
一実施形態によれば前記方法は、ダウンストリーム方向へ前記プローブアンサメッセージを返すステップを含み、前記プローブアンサメッセージが前記新たなセッションの宛て先に向かう途中で通過する各ダウンストリームデバイスにおいて、前記単位コストは更新される。
【００２７】
プローブアンサメッセージの「トラベリング」と、各ネットワークデバイスにおけるその更新とは、セッションが既に宛て先に到着しているネットワークデバイスに基づいて単位コストの合計を概算する効率の良い正確な方法である。
【００２８】
一実施形態によれば前記方法は、単位ダウンストリームコストの合計を取得するために前記プローブアンサメッセージを介して受信したローカルな単位アップストリームコストと、ローカルな単位ダウンストリームコストとを加えるステップを含む。
【００２９】
一実施形態によれば前記方法は、前記アップストリームデバイスが前記セッションのためのトラフィックを既に受信しているかどうかをチェックするステップと、前記単位コストを概算するステップと、ネットワークのエッジに配置されたネットワークデバイスにおいてのみ前記プローブアンサメッセージを生成するステップとを含む。
【００３０】
これにより、中間ルータのような既存のネットワークインフラストラクチャの大部分にいかなる変更を加えることなく使用できるように、単位コストを概算するためのメカニズムをネットワーク内のエッジデバイスに実装することだけが必要となる。
【００３１】
一実施形態によれば前記方法は、ネットワーク内のエッジに位置していない中間ネットワークデバイスが、前記プローブクエリメッセージと前記プローブアンサメッセージとを透過的に（ｔｒａｎｓｐａｒｅｎｔｌｙ）転送するステップを含む。
【００３２】
透過的な送信（ｔｒａｎｓｐａｒｅｎｔ  ｔｒａｎｓｍｉｓｓｉｏｎ）は、中間ネットワークデバイスがコストの概算処理に関連するメッセージを単に転送するだけであり、内容を認識して処理しなければならないという意味においてこれらのメッセージを実際には「処理」しない。
【００３３】
一実施形態によれば前記方法は、前記プローブクエリメッセージと前記プローブアンサメッセージと前記単位コスト情報とが、ペイロード送信のために確保されたフィールドとは異なる、既存のネットワークプロトコルの一つ以上の空きフィールドによって送信されるステップを含む。
【００３４】
これは、既存のネットワークインフラストラクチャにおける中間ルータのようなデバイスを介して、コスト概算処理に関連したメッセージと情報とを転送するために、既存のネットワークプロトコルを使用する効率的な方法である。
【００３５】
一実施形態によれば前記方法は、セッションの単位コストに関する情報を含むプローブアンサメッセージをアップストリームデバイスから受信するステップと、前記プローブアンサメッセージを受信したデバイスにおいて、プローブアンサメッセージにより搬送されたセッションの単位コストを更新するステップと、前記プローブアンサメッセージを前記セッションの宛て先に転送するステップとを含む。
【００３６】
一実施形態によれば前記方法は、前記プローブクエリメッセージを受信した各アップストリームデバイスにおいて、前記新たなセッションとその宛て先とチャネルとに関する情報と、前記プローブクエリメッセージの送信元であるダウンストリームデバイスに関する情報とを記憶するためにセッション情報を更新するステップを含む。
【００３７】
動作中のセッションまたは新しく確立されるセッションに関する情報の更新は、複数のユーザに関するコスト配分を可能にするために有用である。更にこれは、ネットワークデバイスを、動作中のセッションと確立されるセッションとに関して通知できる状態に維持する。
【００３８】
一実施形態によれば前記方法は、アップストリームデバイスがプローブクエリメッセージによって特定される前記新たなセッションのためのトラフィックを受信せず、前記プローブクエリメッセージを受信した場合に、タイマーをセットするステップと、前記新たなセッションに関して前記タイマーが終了した場合に、このセッションに関するレートがまだゼロであれば、このセッションに関して記憶された情報を消去するステップとを含む。
【００３９】
これは、もはやアクティブではないセッション、または（例えばバジェットの問題により）それまでに全く存在したことのないセッションに関する情報でネットワークデバイスが溢れないことを保証するものである。
【００４０】
一実施形態によれば前記方法は、セッションを特定する情報とセッションのコストに関する情報とが、前記ネットワークのエッジデバイスだけに記憶されるステップを含む。
【００４１】
これは、本発明の一実施形態を実施する場合に既存のネットワークの修正の必要性を低く抑えるものである。
【００４２】
一実施形態によれば前記方法は、ネットワーク内のデバイスのうち、エッジデバイスだけがプローブクエリメッセージとプローブアンサメッセージとを生成するステップを含む。これもまた、本発明の一実施形態を実施する場合に既存のネットワークの修正の必要性を低く抑えるものである。
【００４３】
一実施形態によれば前記方法は、マルチキャストネットワークを介して受信機に配信される、複数のチャネルを含むセッションの受信データレートを受信機ベースで制御する方法であって、単位コストと各チャネルのレートと送信コストに対するバジェットとに基づいて、バジェットによって許容されるチャネルの数を決定するステップと、バジェットの考慮に基づいて、セッションに対し許容可能な数のチャネルを実行（ｒｕｎ）するステップとを含む方法を含む。
【００４４】
これは、コストの考慮に基づくチャネル選択の迅速な調整を可能にする。単位コストは、前述の実施形態による方法によって決定することができる。
【００４５】
一実施形態によれば前記方法は、許容されるチャネルが、前記バジェットまたは更に個々のチャネルの優先度に基づいて決定されるステップを含む。これは、ユーザによって行われる優先度の選択を考慮するものである。
【００４６】
一実施形態によれば前記方法は、宛て先でセッションを開始するための開始信号に応答し、セッションの単位コストについてクエリするために、プローブクエリメッセージを生成しセッションのソースに対して前記プローブクエリメッセージを転送するステップと、セッションのソースの方向に位置し、単位コストに関する情報を有するアップストリームデバイスからプローブアンサメッセージを受信するステップと、受信した情報に基づいて、最も高い優先度を有するチャネルから始めて前記セッションに対して決定されたバジェットによって許容可能な数のチャネルに加入（ｓｕｂｓｃｒｉｂｅ）するステップとを含む。
【００４７】
一実施形態によれば前記方法は、前記セッションの宛て先において、セッションのコストに関して更新された情報を含むコスト調整メッセージを繰り返し受信するステップと、前記更新されたコストが前記セッションに対するバジェットより低い場合に、前記バジェットにより許容可能な数の追加チャネルに加入するステップと、前記更新されたコストがバジェットより高い場合に、バジェットの基準が満たされるまで、最も低い優先度を有するセッションから始めて前記セッションからチャネルの加入を解除するステップとを含む。
【００４８】
これにより、チャネルの適切な選択についての連続的な更新が可能になる。
【００４９】
一実施形態によれば前記方法は、サービスの様々なクラスと、あるクラスに属するセッションと、全ての価値および対応する全帯域幅とを割り当てられたクラスとをネットワークが処理するステップと、あるセッションに対し、セッションが属するクラスに依存して単位コストを概算するステップとを含む。
【００５０】
これは、ネットワークが、単位帯域幅に異なる価値が割り当てられている異なるクラスに分割されることを考慮している。
【００５１】
一実施形態によれば、マルチキャストネットワーク内の送信コストをダウンストリームリンクの間で配分する方法であって、（１）前記デバイスがアップストリーム方向から受信するセッションのコストであるアップストリームコストに関する指示を含む、アップストリームデバイスからの情報を、前記ネットワーク内のデバイスが受信するステップと、（２）ある配分スキームに基づいて前記デバイスを起点とするダウンストリームリンク間で前記アップストリームコストを配分するステップと、（３）それぞれのセッションの全レートと前記ネットワークの全帯域幅および対応するコストとに基づく、各ダウンストリームリンクに対するローカルコストを決定するステップと、（４）各ダウンストリームリンクに対してステップ（２）で得られたコストとステップ（３）で得られたコストとを加えることにより、各ダウンストリームリンクの全コストを計算するステップとを含む方法が提供される。
【００５２】
一実施形態によれば前記方法は、前記ダウンストリームリンク間での前記送信コストの前記配分が、各ダウンストリームリンクにおいてセッションごとに別々に行われるステップを含む。
【００５３】
一実施形態によれば前記方法は、前記ダウンストリームリンクを介して前記それぞれのセッションを受信する、前記ネットワーク内のエッジデバイス間で、各ダウンストリームリンクにおける各セッションのコストを配分するステップを含む。
【００５４】
一実施形態によれば前記方法は、前記それぞれのダウンストリームリンクにおける送信コストに関する情報を含むコスト調整メッセージを、前記ネットワーク内の各ダウンストリームリンクにおけるダウンストリームデバイスに転送するステップと、前記ダウンストリームデバイスが受信した前記コスト調整メッセージに基づいてそのアップストリームコストを更新するステップとを含む。
【００５５】
一実施形態によれば前記方法は、前記コスト調整メッセージが前記ダウンストリームリンクの方向に位置する前記エッジデバイスに転送されるステップと、前記エッジデバイスが、前記ダウンストリームエッジデバイスに対してアップストリームコストに関する情報を提供する際に前記コスト調整メッセージを処理するステップとを含む。
【００５６】
一実施形態によれば前記方法は、前記コスト調整メッセージが前記ダウンストリームリンクにおける各セッションのためのコスト情報を個々に含むステップを含む。
【００５７】
一実施形態によれば前記方法は、アップストリームデバイスからのコスト調整メッセージと、チャネルまたはセッションのキャンセルについて通知する、ダウンストリームデバイスからのコストリーブメッセージ（ｃｏｓｔ  ｌｅａｖｅ  ｍｅｓｓａｇｅ）と、前記ネットワークデバイスにおけるコスト情報の反復的な更新を保証するために繰返しセットされるタイマーの終了とのうちの一つ以上によってトリガすることができる。
【００５８】
一実施形態によれば、マルチキャスト送信ネットワークにおいて、顧客の端末が前記ネットワーク内のエッジデバイスに接続された顧客間で送信コストを配分する方法であって、各顧客によって使用される受信レートに基づいて、配信するセッションに加入した顧客間に配信するセッションのコストを配分するステップを含む方法が提供される。
【００５９】
一実施形態によれば前記方法は、各チャネルのレートとセッションの全レートとの比率に基づいて、そのセッションのチャネル間でアクセスリンクにおけるセッションについて概算したコストを配分するステップと、チャネルを使用する各顧客の間で各チャネルのコストを均等に配分するステップとを含む。これは、各顧客が加入したチャネルに基づいて各顧客に配分されたチャネルコストの累積を可能にする。
【００６０】
一実施形態によれば前記方法は、各セッションに関して取得した全コストを、コスト調整メッセージを通して各顧客デバイスに搬送するステップと、別の実施形態による受信データレート制御方法への入力として前記全コスト情報を使用するステップとを含む。
【００６１】
一実施形態によれば、マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するためにネットワークをプローブするための装置であって、前記セッションに対して単位コストを取得するために、ダウンストリームデバイスからセッションのソースの方向に位置するアップストリームデバイスに向けて、前記新たなセッションに関する情報を含むプローブクエリメッセージを送信するための送信機と、前記アップストリームデバイスが前記プローブクエリメッセージを受信し、前記アップストリームデバイスが前記セッションのためのトラフィックを既に受信しつつある場合に、セッションのローカル情報を、ダウンストリームデバイスのアドレスで更新し、新たなセッションの初期単位コストを概算するための受信機と、前記プローブクエリメッセージの送信元に対して前記セッションの初期単位コストに関する情報を返すために、前記プローブクエリメッセージの送信元にプローブアンサメッセージを返すためのレスポンダとを備える装置が提供される。
【００６２】
更なる実施形態によれば、本発明の実施形態による方法を実施するための要素またはユニットを備える装置が提供される。
【図面の簡単な説明】
【００６３】
【図１】本発明の一実施形態によるネットワーク構成を示す図である。
【図２ａ】本発明の実施形態における信号伝達の様子を模式的に示す図である。
【図２ｂ】本発明の実施形態における信号伝達の様子を模式的に示す図である。
【図３】本発明の一実施形態を示すフローチャートである。
【図４】本発明の更なる実施形態を示すフローチャートである。
【図５】本発明の更なる実施形態を示すフローチャートである。
【図６】本発明の更なる実施形態を示すフローチャートである。
【発明を実施するための形態】
【００６４】
以下、本発明の実施形態について添付図面を参照しながら説明する。
【００６５】
本発明の実施形態は、ネットワーク内のマルチキャスト送信に関する。この実施形態は、互いに密接に関係する様々な要素に関する。これらの要素またはメカニズムは、バジェットベースのレート制御（ＢＲＣ）と、単位コストのプロービング（ｐｒｏｂｉｎｇ）（ＰＵＣ）と、送信コストの配分（ＳＴＣ）と、顧客当たりのコストの配分（ＤＣＣ）とである。これらのメカニズムは、以下更に詳細に説明するが、これらのメカニズムを示すために上記の略語を使用する。
【００６６】
一実施形態によれば、あるセッションに対してバジェットベースのレート制御を実行するためのメカニズムが提供される。セッションは、例えば、異なるテーマ内容を持つ幾つかのチャネルを含んだビデオセッションである。ユーザは、自身の端末上で実行されているマルチメディアアプリケーションを使用することにより、例えば配信して欲しいチャネルの特定と、これらのチャネルを含んだセッションを配信するソースの特定とを行うことによって自分の端末でこのようなセッションに加入することができる。ユーザは更に、ユーザが加入するセッションに対して選択された個々のチャネルに対する優先度の特定または割り当てを行うことができる。または、これらのチャネルのうちの一つ以上のチャネルの優先度を予め決定することができる。ユーザが既に実行中のセッションを有しているか、またはユーザが二つ以上のセッションを開きたいと思った場合、ユーザは一実施形態に基づいて、それぞれのセッションに対して優先度を割り当てることができる。ユーザによっていったんセッションが規定されユーザが加入すると、本発明の一実施形態による更なる手順は以下のようになる。
【００６７】
あるセッションにユーザがいったん加入すると、このセッションに関する単位コストが取得される。これは例えば、以下詳細に説明する単位コストをプローブするためのプロービングメカニズムによって行われる。このようなプローブに基づいてセッションに関するコストパラメータ、例えば「単位コスト」が取得される。これは、例えばこのセッションに対して１秒当たり１ビットの送信にかかるコストであり、このようにして取得された「単位コスト」に基づいて、ユーザにより規定されたセッションの全コストが計算される。この計算は、このセッションに属する個々のチャネルのレートに基づいて行われる。したがって、ユーザが加入したセッションの規定、すなわち選択されたチャネルとそれらのレートとに基づいて、ある単位ビットレート（例えば１ビット／秒）に対するコストを与える単位コストに基づいてこのセッションの全コストが計算される。
【００６８】
全コストの計算は、セッションの開始を要求したネットワークデバイス、つまりセッションの宛て先、またはソースデバイスを起点としたダウンストリームパスにおける最終的なダウンストリームデバイスにおいて実行される。いったん「宛て先デバイス」または「受信デバイス」がプローブクエリメッセージに応答してアップストリームデバイスから単位コストパラメータを受信すると、セッションの全コストの計算を開始する。
【００６９】
ユーザによって規定されたセッションの全コストがユーザの限度（「バジェット」）を超えると、「コストの制御」を目的としたレート適応が動作を開始する。つまり、セッションに関連するコストがバジェット内に収まることを保証する。このため、適応メカニズムによれば、バジェットを超えない範囲で配信可能な数のチャネルだけに加入する。最も高い優先度を有するチャネルから開始することによって行われることが好ましい。
【００７０】
このようなメカニズムにより、あるセッションの送信レートは、ユーザのバジェットを限度として瞬時に（いかなる遅延もなく）適応でき、それによってパラメータとしてのパケットロスにより駆動する受信機階層型マルチキャスト（ＲＬＭ）のようなメカニズムに関連する長い収束時間を回避することができる。更にこのＲＬＭは、バジェットの問題をまったく考慮していない。
【００７１】
一実施形態によれば、チャネルの数は、例えばセッションコストに関する更新された情報に基づいて調整できる。この更新された情報は、後述の「顧客当たりのコストの配分」などのメカニズムによって提供される。
【００７２】
図１は、本発明の一実施形態に基づくネットワーク構成を模式的に示している。この図には、どの要素がネットワークのどの部分にインプリメントされ、機能しているかが示されている。図１から理解できるように、ＢＲＣは受信機に実装されている。ＢＲＣは、アップストリームデバイスから送信される単位コストを入力として受信する。したがってネットワークが要求に応じてセッションに対する単位コストを提供できる限り、ＢＲＣはネットワークの他の部分へいかなる修正も加えることなく、受信機に実装するだけでよい。
【００７３】
図１はさらに、ＰＵＣまたはＳＴＣおよびＤＤＣなどの他のメカニズムに関して、これらがどのネットワーク要素内にインプリメントされる必要があるかを示している。
【００７４】
一実施形態によれば受信デバイスは、同時に二つ以上のセッションに加入してこれらを維持することができる。このような場合、各セッションのためのバジェットが個々に存在するか、または全てのセッションの全コストに対する全体的なバジェットが確立される。前者の場合、システムは、バジェットを超過しないように許容可能なチャネルをセッションごとに個別に決定することにより、前述のように動作する。後者の全体的なバジェットの場合には、これらのチャネルは、各チャネルの優先度に基づいて決定することができる。代替として例えば、セッションごとにセッションのランキングに基づいて（最も高い優先度を有するセッションから開始して）一つずつ、このセッションに関して最も高い優先度を有するチャネルが選択される。続いて、次のセッションに関しても最も高い優先度を有するチャネルが選択され、そして最も低い優先度を有するセッションに関して最も高い優先度を有するチャネルが選択されるまで以下同様に繰り返すといった、チャネルに関する他の選択方式を使用することもできる。バジェットを超過していなければ、この手順は、最も高い優先度のセッションに対して２番目に重要なチャネルを選択し、更なるチャネルを許容するとバジェットを超過してしまうという状態になるまで以下同様に続行する。
【００７５】
ネットワークが異なるクラスの（例えば異なる品質レベルの）サービスを提供し、さらにこの場合、あるセッションがあるクラスに属し、各クラスに対して別々にそれぞれの単位コストを決定できるということに注意しなければならない。通常、より高品質のサービスは、より多くのネットワークリソースを必要とし、したがって「より高いクラス」に属するサービスにおける単位コストは、より高くなる。
【００７６】
以下、一実施形態による単位コストをプローブするためのメカニズム（今後はＰＵＣとも呼ぶ）について簡潔に説明する。
【００７７】
ＰＵＣは、端末（新たなダウンストリームセッションの「ターゲット」である受信デバイス）の制御機能に対し、新たに配信するセッションについての近似的な単位コストに関する情報を提供する。このためＰＵＣは、セッションが存在する顧客と第１のネットワークデバイスとの間のネットワークのエッジにあるネットワークデバイスをプローブする。図２を参照すると、ＰＵＣが簡単に示されている。ソース２１５と受信機２４０との間には動作中のセッションＳ１が存在している。このセッションは、（エッジ）デバイス２２５と他の（エッジ）デバイス２３５とを介して受信機２４０に配信されている。ここでデバイス２２０のユーザは、新たなセッションを開始したいと考えており、所望のソース（デバイス２１５）と、チャネルと、おそらくは（所定のものがなければ）チャネルの優先度も決める。偶然ではあるが、この新たなセッションは、原則としてマルチキャストの使用を可能にする既存のセッションＳ１と同一ではない（またはＳ１のサブセットである）。続いて、ソースデバイスに向けて転送されるクエリメッセージＰＲＯＢＥ ＱＲＹが生成される。このクエリが到達する第１のエッジデバイス２３５には、要求されたものと（少なくとも部分的に）同じである動作中のセッションは存在しない。したがって、このクエリメッセージは、（少なくとも部分的に）同じセッションが既に動作しているネットワーク内のノードをサーチするために更にアップストリーム方向に転送される。このクエリメッセージは、中間ノード２３０も通過した後に同じセッションが既に動作している（エッジ）ノード２２５に到達する。これは、ノード２２５がマルチキャスト送信の分岐点として使用できるということと、このセッションに対する（ローカル）コストがこのノードにおいて決定できるということとを意味する。受信デバイスにこのセッションの単位コストを通知するために、この決定に基づいて得られた、このセッションに対する単位コストは、プローブアンサメッセージ（ＰＲＯＢＥ ＡＷＲ）を介して同じパスを通して返される。
【００７８】
同じセッションが、Ｐｒｏｂｅ Ｑｒｙメッセージを受信したネットワークデバイスにおいて既に動作しているかどうかのチェックは、例えばセッションを特定するセッション識別子に基づいて行うことができる。ここで、ソースによって提供されるセッションは、所定の一連のチャネルを含み、この一連のチャネルには、「セッション識別子」が割り当てられる。続いてこのセッション識別子は、新たなセッションを開始する受信デバイスによって使用され、新たに生成されるセッションに割り当てられる。ここで、新たに確立されるセッションが、ソースによって提供される「全セッション」に属するチャネルの全てを含んでいなくてはならないというわけではなく、新たに確立されるセッションを形成して規定するためのセッション識別子の下でソースによって提供されるこれらチャネルの一部をユーザが選択できるということに注目すべきである。しかしながら新たに確立されるセッションは、あるセッション識別子の下でソースによって提供される「全セッション」のうち、少なくとも「サブセット」を含んでいる必要がある。一例として、セッション識別子Ｓ１を有し、ソースＸによって提供されるセッションは、チャネル１、２、３、４、７、８および９を含み、このようなセッションが配信可能であるという情報が受信デバイスに伝えられる。続いてユーザは、自身の受信デバイスにおいて新たに開くセッションを選択することができ、セッションに含めたいチャネルとして例えばチャネル１、２および４を選択することができる。このセッションは、なおもセッション識別子Ｓ１によって特定される。このセッション識別子は、Ｐｒｏｂｅ Ｑｕｒｙメッセージの受信に応じて、このネットワークデバイスにおいてこのようなセッションが既に動作しているか（そして異なる宛て先に配信されているか）どうかをチェックする場合に、ネットワークデバイスにより使用することができる。もしそうであれば、ローカルな単位コストを含んだＰｒｏｂｅ  ＿ＡＷＲメッセージが生成されて返される。一実施形態によれば、例えばこのセッションの第１のチャネル、または慣例的にチャネル識別子として使用されるチャネルを使用することによって、セッションを特定するためにチャネル識別子を使用することも可能である。
【００７９】
受信したアンサメッセージとコスト情報とに基づいて、受信デバイスはセッションの（実際の）コストを決定し、ユーザのバジェットを超えずに許容可能な数のチャネルを使用することができる。
【００８０】
前述の例によれば、中間ノード２３０において要求されたセッションと同じセッションは動作しておらず、したがってクエリメッセージは更にアップストリーム方向に転送されている。しかしながら一実施形態によれば、たとえ中間デバイス２３０において同じセッションが動作していたとしても、クエリメッセージは中間デバイス２３０で応答を生成せずに更にアップストリームに転送される。この実施形態によれば、ネットワーク内でデバイス２２５および２３５などのエッジデバイスだけが、クエリメッセージ（およびアンサメッセージ）を生成する。これにより、本実施形態を実施するときに、ノード２３５のような中間ノードに対して、既存のネットワークの修正が必要ではなくなる。中間ノードは、クエリメッセージおよびアンサメッセージを（透過的に）転送する機能があればよく、例えば中間ノードによって評価されない既存のネットワークプロトコルにおける空きフィールドを使用することによって行うことができる。
【００８１】
クエリメッセージが宛て先と、ソースと、セッションに属するチャネルなどの新たに配信するセッションの特性について、ネットワークデバイスに通知するためにも使用できることに注目すべきである。
【００８２】
ＰＵＣは、配信するセッションの単位コストに関する情報を取得するためにネットワークをプローブし、顧客のバジェットを重視しつつ良好な受信品質レベルに達するために必要な収束時間を、バジェットベースの適応メカニズム（例えばＢＲＣ）が短縮することを可能にする。
【００８３】
顧客（ユーザまたはネットワーク）に送信される単位コストが、顧客とそのネットワークプロバイダとの間で合意した料金体系を反映できることに留意すべきである。これは、プロバイダと顧客との間で交換されたコスト情報が、プロバイダの課金体系によって修正できるということを意味する。また、プローブメッセージ（および対応するアンサメッセージ）があるネットワークまたはドメインの境界を越えて移動する場合、これは、例えば、異なるプロバイダのネットワークをまたがるセッションに対する料金体系を反映するために、アンサメッセージで送信される単位コストに影響を与える。
【００８４】
一実施形態によれば、プローブクエリメッセージは、対応するセッションが既に動作しているデバイスに到達するまでアップストリーム方向に転送される。ソースとユーザのいかなる端末との間に動作中のセッションが存在しなければ、プローブクエリはソースの最も近くに位置するネットワーク内のエッジデバイスに向けてアップストリーム方向に移動する。標準的なマルチキャスト環境においては、セッションを提供するマルチキャスト送信のソースは、少なくともデータを更にダウンストリーム方向に配信する、ネットワーク内のエッジデバイスによって前記セッションを確立するため、このエッジデバイスとソースとの間でセッションは既に動作している。ユーザまたは受信デバイスが提供されるセッションをまだ要求していなかったとすれば、ネットワーク内のエッジデバイスは、ソースから受信したセッションのパケットを破棄（ｄｒｏｐ）する。したがって、あるセッションに関して受信した最初のプローブクエリメッセージの場合、このネットワークエッジデバイスは、プローブアンサメッセージを生成して、このネットワークエッジデバイスにおける（全）ローカル単位コストと共にダウンストリーム方向に送信する。
【００８５】
更なる実施形態によれば、ダウンストリームリンクに対してマルチキャスト送信の送信コストを配分するためのメカニズム（以下、ＳＴＣとも呼ぶ）が提供される。一実施形態によればこれは、クラスベースのネットワークにおけるマルチキャストツリーのダイナミクスを考慮する。このようなネットワークにおいて、ネットワークのオペレータは、異なるネットワーククラスのトラフィックを区別する機能を提供する。ここで、この異なるネットワーククラスは、各々が例えば異なる品質レベルを提供し、異なるコストを有するものである。一実施形態によるＳＴＣは、クラスベースのネットワーク内のエッジデバイスだけにおいて、マルチキャストツリーのアップストリーム送信コストを、ダウンストリームリンク間で配分する。アップストリーム送信コストという用語は、ソースから現在のエッジデバイスまで送信されることによりセッションが有するコストを意味するということに留意すべきである。このため、各エッジデバイスにおいてＳＴＣは、アップストリームの近傍のデバイスによって提供されるセッションのコストに関する情報を収集し、セッションの全レート（各々のチャネルのレートの合計）と、このセッションによって使用されるネットワーククラスの帯域幅およびコストとを考慮してダウンストリームのエッジデバイス間でコストを配分する。つまり、このセッションによって使用されるネットワーククラスの帯域幅およびコストは、ネットワークオペレータによって（このセッションが属する）クラスが割り当てられた「全ての価値」に対応する。さらに、（測定デバイスから導かれる）セッションの全レートは、このセッションが属するクラスの帯域幅に応じてセッションの全レートを配分することに基づく、この全ての価値の割合に対応する。
【００８６】
近傍のデバイスが異なるネットワークのエッジに配置されている場合に、アップストリームの近傍のデバイスからダウンストリームの近傍のデバイスに伝達されるコストは、２つのネットワークプロバイダ間で合意した料金体系を反映することに注目すべきである。これは、プロバイダと顧客との間で交換されたコスト情報がプロバイダの課金メカニズムによって修正できることを意味する。各ネットワーククラスの帯域幅とコストとに関する価値の定義は、方針の問題であって、実際のコスト配分メカニズム（ＳＴＣ）には関係ないことに更に留意すべきである。単にアップストリームコストをダウンストリームデバイスに搬送する代わりに、ＳＴＣは、エッジデバイスのダウンストリームリンク間で配信するセッションのコストを配分し、それにより各外部インタフェースにおけるセッションコストを低減する。これは、顧客に対して品質とコストとの間の良好なトレードオフを与えることにより、ネットワークプロバイダが顧客を引き付けて維持することを可能にする。
【００８７】
更なる実施形態によれば、顧客当たりのコストの配分のためのメカニズム（以下ＤＣＣとも呼ぶ）が提供される。このメカニズムは、各顧客によって使用される受信レートに基づいて配信するセッションに加入した顧客の間でこの配信するセッションのコストを配分する。このため、ＤＣＣは、端末から各セッションに関する情報を収集し、各顧客が加入したチャネルの数と各チャネルのレートとを考慮することにより、（ＳＴＣなどによって与えられる）これらのセッションのコストを、これらのセッションを受信する全ての顧客の間で配分する。顧客に送信されたコストが、顧客とアクセスネットワークプロバイダとの間で合意した料金体系を反映していることに留意すべきである。これは、プロバイダと顧客との間で交換されたコスト情報が、プロバイダの課金メカニズムによって修正できることを意味する。
【００８８】
ここで図１を参照すると、前述のコンポーネントのどれがネットワークのどの部分にインストールされているかが更に表されている典型的なネットワーク構成が示されている。図１から理解できるように、端末にはＢＲＣだけがインストールされることになっているのに対し、ＰＵＣ、ＳＴＣおよびＤＣＣなどの他のメカニズムは、ネットワーク内に設置されている。更にＰＵＣ、ＳＴＣおよびＤＣＣが必要とする全ての機能は、内部のルータと干渉せずにエッジデバイス内に配置されている。ＰＵＣおよびＳＴＣは全てのエッジデバイスにおいてアクティブであるが、ＤＣＣは個々の顧客へのアクセスゲートウェイとして機能するネットワークエッジにおいてのみアクティブである。これは、本発明の実施形態が既存のネットワークにおいて全てのルータに修正を加えることなく実施でき、代わりに、端末（受信機）とエッジデバイスとにおいてだけ修正が必要であることを示している。
【００８９】
図２には、前述のメカニズムによって使用される信号伝達が示されている。図２ａは、ＢＲＣによってトリガされる信号伝達であって、新たな顧客がマルチキャストセッションに参加する際にこのマルチキャストセッションの単位コストに関する情報を収集するためにＰＵＣによって使用される信号伝達を示している。図２ｂは、コスト情報を伝達するためにＳＴＣおよびＤＣＣによって使用される信号伝達を示している。ＳＴＣは、各ダウンストリームリンクにおいてセッションのコストに関する情報を伝達するが、ＤＣＣは、各顧客に関連したコストに関する情報を伝達する。図２ｂに示されているように一実施形態によるＳＴＣおよびＤＣＣは、タイマーによってトリガされ、ＤＣＣは、セッションが存在する各ダウンストリームリンク間で各セッションのコストを配分するＳＴＣなどの別のメカニズムの出力を入力として使用する。本発明の実施形態に基づくこれらメカニズムの更に詳細な説明を以下で行う。
【００９０】
最初に、一実施形態によるＢＲＣについて、図２ａおよび図３を参照して詳細に説明する。ここで、「メカニズム」としてＢＲＣ、ＰＵＣ、ＳＴＣおよびＤＣＣを指す場合、このような「メカニズム」がネットワークデバイス内のマイクロプロセッサを適当にプログラムすることによってネットワークデバイス内に実現できることは、当業者には直ちに明らかであろうことに留意すべきである。したがってこのようなメカニズムは、マイクロプロセッサとおそらくは周辺デバイスとを、本明細書で説明するように動作する何らかのソフトウエアコード、または本明細書で説明するように動作するよう設計されたゲートアレイか、何らかの電子デバイスか、または集積回路などのある特定のハードウェアによって実現できる。前述したことを考慮すると、本明細書で使用する「メカニズム」という用語は、実行するときに本明細書で説明するようなネットワークデバイスの動作に対応する一連のステップを含んだ方法として理解すべきである。
【００９１】
ＢＲＣは、セッションの開始または終了を知らせるアプリケーション信号の受信と、ネットワークからのプローブアンサ（Ｐｒｏｂ Ａｗｒとも呼ばれる）メッセージと、コスト調整（Ｃｏｓｔ Ａｄｊとも呼ばれる）メッセージの受信という三つのトリガを有する。このような事象に応じて以下に説明する処理が実行される。
【００９２】
セッションを開始するアプリケーション信号を受信した場合。
セッションへの加入（例えばユーザの端末上で動作するマルチメディアアプリケーションを使用するユーザによって開始する）は、配信するセッションを共に定義する全てのチャネルに関する情報（例えばソース、チャネル識別子、各チャネルの優先度、レート）と、そのセッションに対する顧客のバジェットとを含んでいなくてはならない。これは、例えば図３のステップ３０５に対応する。これはＩＰマルチキャストが配信ツリー（ｄｉｓｔｒｉｂｕｔｉｏｎ  ｔｒｅｅ）を生成するために使用するときに生じるので、ソースとチャネル識別子はＩＰアドレスである。これらの情報は、一実施形態によればユーザの端末にインストールされて動作するソフトウェアコンポーネントとして実装されるＢＲＣによって受信され記憶される（図３のステップ３１０）。
【００９３】
セッションに関する情報を記憶した後、ＢＲＣは、セッションの近似的な単位コストについてクエリするために、プローブクエリ（以下、Ｐｒｏｂｅ Ｑｒｙとも呼ばれる図３のステップ３１５）メッセージをマルチキャストセッションのソースに対して送信する。これは例えば、デバイス２４０のユーザによって使用されている既存のセッションＳ１に対してデバイス２２０のユーザが新たに加入する場合の、デバイス２２０から生じるプローブクエリメッセージを示す図２ａにも示されている。アップストリーム方向に進むプローブクエリメッセージの目的は、単位コストに関する情報を含むメッセージ、いわゆるプローブアンサ（以下、Ｐｒｏｂｅ Ａｗｒとも呼ばれる）メッセージの返却をトリガすることである。
【００９４】
Ｐｒｏｂｅ Ａｗｒメッセージの受信（図３のステップ３２０）。
このメッセージは、セッションの近似的な単位コストに関する情報をもたらす。この情報をネットワーク内で実際に収集する方法は、ＰＵＣに関連して後で説明する。各チャネルに対するこの単位コストと各チャネルのレート（セッション開始信号に応じて既に記憶されている）とに基づいてＢＲＣは、各チャネルのコストを概算する（図３のステップ３２５）。この後、ＢＲＣは、最も高い優先度を有するチャネルから開始して顧客のバジェットにより許容可能な数のチャネルに加入する（図３のステップ３３０）。
【００９５】
コスト調整（Ｃｏｓｔ Ａｄｊ）メッセージの受信。
ＢＲＣは、セッションのコストに関して更新された情報を有するＣｏｓｔ Ａｄｊメッセージを定期的に受信する（図３のステップ３３５）。ネットワーク内でコスト情報を更新する方法は、ＳＴＣに関連して後で詳細に説明する。受信した更新コスト情報は、チャネルの数を調整するために使用される（図３のステップ３４０）。これは一実施形態にしたがって以下のように行われる。
【００９６】
（ａ）更新されたコストがそのセッションに関する顧客のバジェットよりも低い場合、ＢＲＣはバジェットによって許容される範囲で新たにチャネルに加入する（チャネルは最も重要なものから開始して加入する）。加入するチャネルの数は、セッションの単位コストと各チャネルのレートとに基づいて計算される。
【００９７】
（ｂ）更新されたコストが顧客のバジェットよりも高い場合、ＢＲＣは、コストがバジェットよりも高い限り、チャネルを取り消す（チャネルは、重要でないものから開始して取り消す）。バジェットがセッションの基本チャネルを維持するのに十分ではない場合、ユーザに対してバジェットの増加を依頼する信号がアプリケーションに送信される。バジェットが増えない場合、ＢＲＣは、以下に説明するようにセッションを抜ける（ｌｅａｖｅ）処理を実行する。そうでない場合は、上述のようなステップ（ａ）および（ｂ）を繰り返す。
【００９８】
セッションを終了するアプリケーション信号の受信。
ＢＲＣは、セッションの全てのチャネルを抜けて（ステップ３５０）、そのセッションに関する全ての情報を消去する（ステップ３５５）ために、（一実施形態によれば、システムがＩＰｖ４またはＩＰｖ６の場合、それぞれＩＧＭＰｖ３またはＭＬＤｖ２である）取消しメッセージを生成する（図３のステップ３４５）。アプリケーション信号において、セッションは、専用の識別子か、または実施形態によっては、例えば慣例によりあるセッションを特定するチャネル識別子である、セッション識別子によって特定することができる。
【００９９】
ＢＲＣがチャネルに加入するとき、チャネルの識別子と任意的にチャネルのレートとが（所定のものがない場合または不変でない場合に）含まれる。チャネルに関する情報は、（例えばチャネル識別子を使用することにより）セッションを特定する情報と共に、セッションの単位コストに関する情報を伝達する応答の返却をトリガするために、アップストリームに送信しなければならない。つまり、この情報の搬送を可能にするメカニズムが、好ましくは既存のネットワーキングメカニズムまたはプロトコルによって与えられなくてはならない。
【０１００】
本発明はマルチキャストに関連しており、本発明が実現されるネットワークにはマルチキャストツリーを構築するための何らかのメカニズムが既に存在している。一例として、Ｉｐｖ４およびＩｐｖ６それぞれに対するアクセスポイントにおいてＩＧＭＰｖ３またはＭＬＤｖ２を使用している。ＩＧＭＰｖ３は、Ｃａｉｎらによる「Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ，ｖｅｒｓｉｏｎ  ３，ＲＦＣ３３７６，ＩＥＴＦ，２００２年１０月」に記載されており、ＭＬＤｖ２は、「Ｖｉｄａ  ａｎｄ  Ｃｏｓｔａ，Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ  Ｖｅｒｓｉｏｎ  ２（ＭＬＤｖ２）ｆｏｒ  Ｉｐｖ６，ＲＦＣ３８１０，ＩＥＴＦ、２００４年６月」に記載されている。
【０１０１】
前述のようにデータを搬送するため、ＳＩＰ（Ｓｅｓｓｉｏｎ  ｉｎｖｉｔａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）のＩＮＶＩＴＥメッセージと同様に、ＩＧＭＰｖ３およびＭＬＤｖ２レポートの補助的なデータフィールドが使用できる。グループメッセージのための規格であるＩＧＭＰｖ３およびＭＬＤｖ２レポートは、以前のバージョンに存在していた「ホスト抑制」メカニズムが削除されたため、ルータが個々のユーザに関する情報を収集することを可能にする。どんな場合でも、チャネルに加入するために使用されるメッセージは、そのセッションの中で最も重要なチャネルの識別子も含んでいなくてはならない。チャネルへの加入を取り消すためにＢＲＣは、ＩＧＭＰｖ３およびＭＬＤｖ２レポートまたはＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｖｉｔａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）のＢＹＥメッセージ（加入取消しする（ｕｎｓｕｂｓｃｒｉｂｅｄ）チャネルの識別子を含む）を使用できる。代わりに、他のプロトコルまたは他のプロトコルのデータフィールドが使用できる。
【０１０２】
一実施形態におけるＢＲＣは、パケットロスの割合に基づいてチャネルの数を調整するＲＬＭなどのレートベースの適応メカニズムと組み合わせることができる。このシナリオにおいて一つの可能な組合せは、受信レートの増加を制御するＢＲＣと、（パケットロスが多くなり過ぎた場合に）このようなレートの減少を制御するＲＬＭのようなメカニズムとを有することであろう。
【０１０３】
ＢＲＣは、動作するためにセッションの単位コストに関する情報を必要とする。この情報は、図４を参照しながら以下更に詳細に説明するＰＵＣ（Ｐｒｏｂｉｎｇ  Ｕｎｉｔａｒｙ  Ｃｏｓｔｓ）メカニズムによって提供される。
【０１０４】
一実施形態によるＰＵＣは、Ｐｒｏｂ Ｑｒｙメッセージの受信と、Ｐｒｏｂ Ａｗｒメッセージの受信と、以下Ｚｅｒｏ Ｒａｔｅタイマーと呼ばれるタイマーの終了と、という三つのトリガを有する。これらの事象のうち一つの事象の後に、以下に説明するような処理が実行される。
【０１０５】
ダウンストリームデバイスからのＰｒｏｂｅ Ｑｒｙメッセージの取得。
あるセッション（例えばそのセッション識別子によって特定される）に関するＰｒｏｂｅ Ｑｒｙの受信（図４のステップ４００）に応じてＰＵＣは、ＰＵＣが動作していてＰｒｏｂｅ Ｑｒｙを取得したデバイスがこのようなセッションに関するトラフィックを既に受信しているかどうか（つまり、このデバイス上で動作しているこのようなローカルセッションが存在するかどうか）をチェックする（ステップ４０５）。そうであればＰＵＣはまず、受信したＰｒｏｂｅ Ｑｒｙの送信元であるダウンストリームデバイスのアドレスにより、セッションのローカル情報を更新する（ステップ４１０）。その後ＰＵＣは、セッションのローカル単位レート（例えば１ビット／秒）と、このセッションによって使用されるクラスに割り当てられる帯域幅と、このクラスのコストとに基づいて、Ｐｒｏｂｅ Ｑｒｙを受信したリンク内のセッションに関するローカル単位コストを概算する。一例であるが、セッションが属するクラスの（全）帯域幅が１Ｇビット／秒であると仮定し、更に対応する（全）コストが２０００ユーロであると仮定すると、このクラスにおける１セッションに対する１ビット／秒の単位コストは、２０００／１０９ユーロとなる。
【０１０６】
セッションの「全」単位コストを取得するために、Ｐｒｏｂｅ Ｑｕｒｙが取得されたリンク内のセッションに関する、それまでに得られた「ローカル」単位コストは、このセッションの「単位アップストリームコスト」に加えられる。この単位アップストリームコストは、アップストリーム方向からＰｒｏｂｅ Ｑｒｙメッセージを受信したデバイスへと移動するデータによって生じるコストである。この単位アップストリームコストは、アップストリームコストと、（アップストリームインタフェース内に配置されている、受信データレートを測定する計測器に基づいて決定できる）セッションのレートとに基づいて計算される。（既存のセッションによりデバイス内に既に記憶されている）アップストリームコストをデータレートで除算することにより、単位アップストリームコストを得ることができる。ローカル単位コスト（つまり、「単位ダウンストリームコスト」）に加えられるこれら単位アップストリームコストは、Ｐｒｏｂｅ Ｑｒｙメッセージを受信したデバイスにおけるセッションに対する全ローカル単位コストを与える。
【０１０７】
結果として得られた単位コストの合計は、Ｐｒｏｂｅ Ｑｒｙメッセージの送信元に返されるＰｒｏｂｅ Ａｗｒメッセージ内に含められる。一実施形態によれば全てのメッセージは、宛て先までのパス内に位置するＰＵＣによって取得されるために、ＩＰ警告オプションセットと共に送信される。
【０１０８】
ステップ４０５で、デバイスがセッションに対するトラフィックをまだ受信していないという結果が得られると、ＰＵＣは、ダウンストリームデバイスのアドレスに関する情報に加えてセッションのチャネルに関する情報を記憶する（ステップ４２５）。
【０１０９】
一実施形態によれば更に、受信インタフェースに関する情報を記憶することができる。続いてＰＵＣは、配信するセッションのソースの方向へとＰｒｏｂｅ Ｑｒｙメッセージを転送する。これらの処理が全て完了した後ＰＵＣは、Ｚｅｒｏ Ｒａｔｅタイマーをセットする。Ｐｒｏｂｅ Ｑｒｙメッセージがアップストリームの途中でアップストリームのエッジデバイスによって受信されると、このデバイスにおける手順は前述した方法と同じ方法で行われる。
【０１１０】
アップストリームデバイスからのＰｒｏｂｅ Ａｗｒメッセージの取得。
（最も重要なチャネルにより特定される）あるセッションに関するＰｒｏｂｅ Ａｗｒの受信（ステップ４３５）に応じてＰＵＣは、Ｐｒｏｂｅ Ａｗｒメッセージを通して送られたセッションの単位コストを更新し、このメッセージをその宛て先に転送する。このためＰＵＣは、Ｐｒｏｂｅ Ａｗｒメッセージを受信したデバイスから開始してダウンストリームリンクに関するローカル単位コストを概算する。これは、Ｐｒｏｂｅ Ｑｒｙメッセージの受信と関連して前のケースで説明したように、セッションが属するネットワーククラスに割り当てられている帯域幅と、この帯域幅に割り当てられている対応するコストまたは価値と、セッションの単位（ダウンストリーム）レートとに基づいて行われる。これにより、セッションのローカル単位コストが与えられ、さらに単位コストの合計を得るために単位アップストリームコストに加えなければならない。しかしながらこの単位アップストリームコストは、Ｐｒｏｂｅ Ａｗｒメッセージ内に含まれる情報として受信したものであり、アップストリーム方向に一段階上に位置するデバイスにおいて取得された単位コストの合計値と同じである。
【０１１１】
つまり、アップストリーム方向の途中で初めて、同じセッションが動作しているデバイスにおいてＰｒｏｂｅ Ｑｒｙメッセージを受信すると、このデバイスで新たに確立されるセッションに対する、このデバイスにおけるダウンストリーム方向の単位コストの合計が、ローカル単位アップストリームコストとダウンストリーム方向のローカル単位コストとを加えることにより概算される。ローカル単位アップストリームコストは、アップストリーム方向から到来する既に動作中の（計測器により計測可能な）セッションのレートを、既に動作中のセッションのアップストリームコストで除算することによって取得できる。動作中のセッションのコストの状態をデバイスが監視しているので、後者の情報はこのデバイスで利用可能である。また、ローカル単位アップストリームコストは、現在すでに動作中のセッションが開始したときにＰｒｏｂｅ Ａｗｒメッセージによりこのデバイスに一度配信されているために取得することができる。ローカル単位（ダウンストリーム）コストは、全帯域幅およびそれに割り当てられている全ての価値と、単位レート（例えば１ビット／秒）とに基づいて概算される。単位ダウンストリームコストの合計は、このデバイスにおけるローカル単位アップストリームコストとローカル単位ダウンストリームコストとを加えたものである。
【０１１２】
（ローカル単位コストをローカル単位アップストリームコストに加算することによって）いったん単位（ダウンストリーム）コストの合計がこのデバイスにおいて計算されると、これはダウンストリーム方向に搬送される。またダウンストリーム方向の各（エッジ）デバイスにおいて、単位コストの合計は、アップストリーム方向からＰｒｏｂｅ ＡＷＲメッセージを介して受信したローカル単位アップストリームコストの値にローカル単位ダウンストリームコストを加えることにより更新される。単位コストの合計に基づいてバジェットを守るためにセッションに適したチャネルを選択できる、セッションの開始を要求した端末により、Ｐｒｏｂｅ Ａｗｒメッセージ（および、ダウンストリーム方向の途中でこのメッセージによって搬送され、絶えず更新される単位コストの合計）を受信するまで、この手順はダウンストリーム方向へと続けられる。
【０１１３】
Ｚｅｒｏ Ｒａｔｅタイマーの終了。
特定のセッションに関してこのタイマーが終了する（ステップ４４５）と、ＰＵＣは、このセッションのレートがまだゼロであれば、このセッションに関して記憶されている情報を消去する（ステップ４５０）。これは、実際にはもはやアクティブでないセッション、または（例えばバジェット限度のために）アクティブにならなかったセッションに関する、デバイス内の記録を時々消去する。
【０１１４】
以下、ＳＴＣの動作について詳細に説明する図５を参照することによって、ダウンストリームリンク間での送信コストの配分について詳細に説明する。一実施形態におけるこのメカニズムは、Ｃｏｓｔ Ａｄｊメッセージの受信と、Ｃｏｓｔ Ｌｖｅメッセージの受信と、Ｓｐｌｉｔ Ｃｏｓｔｓタイマーの終了と、という３つのトリガを有する。このような事象の後に以下の処理が実行される。
【０１１５】
アップストリームデバイスからのＣｏｓｔ Ａｄｊメッセージの受信。
（セッション識別子によって特定される）一連のセッションに関するＣｏｓｔ Ａｄｊメッセージの受信（図５のステップ５００）の後、ＳＴＣはこれらのセッションがそのデバイスにおいてまだアクティブであるかどうかをチェックする（ステップ５０５）。既に不存在の全てのセッションに関しＳＴＣは、Ｃｏｓｔ Ａｄｊメッセージの送信元へとＣｏｓｔ  Ｌｅａｖｅを意味するＣｏｓｔ Ｌｖｅメッセージを送る（ステップ５１０）。まだローカルにアクティブである全てのセッションに関しＳＴＣは、これらのセッションのアップストリームコストに関するローカル情報を更新する（ステップ５１５）。
【０１１６】
Ｓｐｌｉｔ Ｃｏｓｔｓタイマーの終了（図５のステップ５２０）。
このタイマーが終了するとＳＴＣは、以下の処理を実行することによりデバイス内のセッションのコストの更新を実行する（ステップ５２５）。
【０１１７】
（ａ）各セッションに関して。セッションが存在するダウンストリームリンク間でこれらのアップストリームコストを配分する。計算の一例では、セッションのアップストリームレートと各ダウンストリームリンク内のセッションのレートとの比率を考慮する。アップストリームリンクのレート（すなわちセッションがアップストリーム方向からデバイスへと入るレート）が１００であるとし、ダウンストリームリンクＡが８０というレートを有するとし、ダウンストリームリンクＢが７０というレートを有するとし、ダウンストリームリンクＣが１００というレートを有するとすると、アップストリームコストは、Ａがアップストリームコストの８０／１００、Ｂが７０／１００、Ｃが１００／１００となるようにダウンストリームリンクＡとＢとＣとの間で配分される。ダウンストリームリンクにおけるセッションのレートは、そのチャネルのうちの各チャネルのレートとそのリンクに存在する計測器から収集される値とに基づいて概算される。セッションのアップストリームレートは、Ｃｏｓｔ Ａｄｊメッセージにおいて収集し、またはエッジデバイスのアップストリームインタフェースに設置されている計測器に基づいて収集することができる。
【０１１８】
代替として、前述の例においてＡが８０／２５０、Ｂが７０／２５０、Ｃが１００／２５０という割合になるようにコストを配分することも可能である。これは、ネットワークプロバイダがマルチキャストの使用により得られる利益を考慮するものであり、この利益を顧客に直接転送する。つまり、マルチキャストセッションに参加する人々が多いほど、（ユニキャスト送信によって同じ数の人々にサービスを提供する場合と比較して）必要なネットワークリソースは少なくなり、その結果、コストはより多くのユーザ間で配分することができる。
【０１１９】
もう一つの実施形態では、セッションのアップストリームコストと、このセッションが存在するダウンストリームリンクの数との比率に基づいてコストを配分できる。前述の例であれば、ダウンストリームリンクＡとＢとＣとに対して、それぞれアップストリームコストの１／３となる。
【０１２０】
（ｂ）各ダウンストリームリンクに関して。セッションのローカルレートと、このセッションによって使用されるネットワーククラスに割り当てられている帯域幅と、このクラスのコストとに基づいて、このリンクにおける各配信するセッションのローカルコストを概算する。各エッジデバイスの各リンクに関するクラスの帯域幅とコストとを設定するために使用するメカニズムは、方針の問題であって、本明細書で原則として説明した動作に影響を及ぼさないことに留意すべきである。単なる一例として、セッションによって使用されるネットワーククラスに割り当てられている帯域幅が２００であり、このクラスの値が１００であり、セッションが４というレートを使用すると仮定すると、このダウンストリームリンクに関する配信するセッションのローカルコストは、４／２００＊１００＝２となる。
【０１２１】
この決定の後、ダウンストリームリンクにおけるセッションの全コストは、このリンク内のセッションのローカルコストと、このセッションのアップストリームコストの割当て分（ステップａで計算された値）とを加えることによって計算される。
【０１２２】
（ｃ）各ダウンストリームリンクにおける各エッジデバイスに関して。
ＳＴＣは、前述のＰＵＣなどのプローブメカニズムを用いて各ダウンストリームエッジデバイスに関する情報（そのアドレスと、このようなダウンストリームデバイスに存在する各セッションのチャネルの数に関する情報）を収集することに留意すべきである。この情報は、ダウンストリームリンクのコストをより正確に配分するために使用できる。
【０１２３】
一実施形態によれば、ステップｂで計算された各ダウンストリームリンクにおける各セッションの送信コストは、このセッションを動作させる全てのダウンストリームエッジデバイス間で配分される。例として、図１におけるデバイス１２５からデバイス１３０へのダウンストリームリンクのコストの決定が結果的に１００という値になり、デバイス１２５からデバイス１３５へのダウンストリームリンクのコストが結果的に５０という値になったと仮定する。結果として得られる全ダウンストリームリンクコストは１５０となるが、デバイス１３５と１４０と１４５とが同じセッションを動作させていることをデバイス１２５は認識しているため、デバイス１２５は、例えばデバイス１３５と１４０と１４５とで動作しているセッションで使用されているチャネルの数を考慮することにより、１５０という全コストをこれら３つのデバイス間で配分することができる。
【０１２４】
プロバイダがこの配分を実行しないで、各ダウンストリームリンクに関して計算されたコスト（ステップｂ）を、このダウンストリームリンクを介して到達できる全てのダウンストリームエッジデバイスに単に送ることを決定できることに留意すべきである。これは、図１の例では、デバイス１４０および１４５がそれぞれ１００というセッションコストを負担しなくてはならないことを意味する。
【０１２５】
このセッションを受信する全てのエッジデバイス間でのコスト配分が行われると、ＳＴＣは、このデバイス内に存在する全てのセッションのコストに関する情報を持ったＣｏｓｔ Ａｄｊメッセージを各ダウンストリームエッジデバイスへと送る。
【０１２６】
ダウンストリームデバイスからのＣｏｓｔ  Ｌｅａｖｅ（Ｃｏｓｔ Ｌｖｅ）メッセージの受信。
このようなメッセージを受信した（ステップ５３５）後、ＳＴＣは、Ｃｏｓｔ Ｌｖｅメッセージに含まれている各セッションのエッジデバイスのリストから、Ｃｏｓｔ Ｌｖｅメッセージを送ったエッジデバイスのアドレスを削除する（ステップ５４０）。
【０１２７】
一実施形態によれば、エッジアクセスゲートウェイ（個々の顧客の端末がアクセスするゲートウェイ）において、このゲートウェイを介して到達する個々の顧客との通信が以下詳細に説明するＤＣＣによって行われるため、ＳＴＣメカニズムはＣｏｓｔ Ａｄｊメッセージを送らず、Ｃｏｓｔ Ｌｖｅメッセージを処理しない。
【０１２８】
図６は、ＤＣＣ（顧客当たりのコストの配分）メカニズムの動作についてより詳細な説明を行う。このメカニズムは、端末からの加入メッセージまたは加入取消しメッセージの取得と、Ｄｉｓｔ Ｃｏｓｔｓ Ｒｅｃｖタイマーと呼ばれるタイマーの終了と、という２つのトリガを有する。このような事象の後に以下の処理が実行される。
【０１２９】
顧客に関する情報を有する加入／加入取消しメッセージの取得。
各セッションのチャネルを知るために、ＢＲＣのようなメカニズムによって送られ、加入または加入取消しメッセージを伝達するために使用される、ＩＧＭＰｖ３およびＭＬＤｖ２レポート、またはＳＩＰのＩＮＶＩＴＥメッセージまたはＢＹＥメッセージで収集された情報を使用する（図６のステップ６００）。このようなメッセージの受信後、ＤＣＣは、メッセージがそれぞれチャネルに加入または加入取消しするものである場合に、新たなチャネルに関する情報を記憶すること、または既存のチャネルに関する情報を削除することにより各セッションのローカル情報を更新する（ステップ６０５）。続いて更新されたコストが決定されると、この更新された情報が使用される。このような更新は、例えば以下に説明するようにタイマーの終了によってトリガすることができる。
【０１３０】
Ｄｉｓｔ Ｃｏｓｔｓ Ｒｅｃｖタイマーの終了。
このタイマーが終了する（図６のステップ６１０）と、ＤＣＣは、各セッションに加入した顧客の間で、各セッションのコスト（アクセスリンクにおける各セッションのコストはＳＴＣのようなメカニズムによってそれまでに計算されている）を配分する（ステップ６１５）。コストの配分（またはその更新）は、例えば以下のステップにより行われる。
【０１３１】
（ａ）各チャネルのレートとセッションの全レートとの比率に基づいて、セッション内のチャネルの間のアクセスリンクにおけるセッションについて概算されたコストを配分する。各チャネルのレート、したがってセッションのレートは、（ＢＲＣによって提供されなければ）計測器に基づいてローカルに概算される。
【０１３２】
（ｂ）各チャネルに関して。ＤＣＣは、各チャネルを使用している顧客の間で各チャネルのコストを均等に配分する。
【０１３３】
（ｃ）各顧客に関して。ＤＣＣは、ステップｂで概算された、チャネル当たりのコストを加え、その後この概算された全コストは、Ｃｏｓｔ Ａｄｊメッセージで顧客の端末（例えばＢＲＣのようなメカニズム）へと送られる。
【０１３４】
前述のメカニズムにより、ソースからアクセスポイントへのセッションのコストは、ユーザの端末上でセッションを動作させている全てのエンドユーザ間で配分される。
【図１】
2010035203.tif 000003
【図２ａ】
2010035203.tif 000004
【図２ｂ】
2010035203.tif 000005
【図３】
2010035203.tif 000006
【図４】
2010035203.tif 000007
【図５】
2010035203.tif 000008
【図６】
2010035203.tif 000009
【手続補正書】
【提出日】平成21年11月6日(2009.11.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチキャストネットワークを介して受信機へ配信される、複数のチャネルを含むセッションに関する受信データレートを受信機ベースで制御する方法であって、
単位コストと、各チャネルのレートと、送信コストに関するバジェットとに基づいて、バジェットにより許容されるチャネルの数を決定するステップと、
バジェットを考慮することに基づいて、セッションに対して許容可能な数だけチャネルを実行するステップと
を含む方法。
【請求項２】
前記単位コストは、
前記マルチキャストネットワークにおいて新たなセッションの単位コストに関する情報を取得するためにネットワークをプローブする方法であって、
前記セッションの単位帯域幅当たりのコストとして前記単位コストを取得するために、ダウンストリームデバイスからセッション内のソースの方向に位置するアップストリームデバイスに向けて、前記新たなセッションに関する情報を含んだプローブクエリメッセージを送信するステップと、
前記アップストリームデバイスが前記プローブクエリメッセージを受信し、前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しつつある場合に、前記新たなセッションの単位コストを概算するステップと、
前記プローブクエリメッセージの送信元に対して前記セッションの初期単位コストに関する情報を返すために、前記プローブクエリメッセージの送信元に対してプローブアンサメッセージを返すステップと
を含む方法によって決定されるものである、請求項１に記載の方法。
【請求項３】
許容可能なチャネルは、前記バジェットと、個々のチャネルの優先度とに基づいて決定されるものである、請求項１または２に記載の方法。
【請求項４】
宛て先においてセッションを開始するための開始信号に応じて、前記セッションの単位コストについてクエリするためにプローブクエリメッセージを生成し、該プローブクエリメッセージを前記セッションのソースに向けて転送するステップと、
前記セッションのソースの方向に位置し、前記単位コストに関する情報を有するアップストリームデバイスからプローブアンサメッセージを受信するステップと、
受信した情報に基づいて、最も高い優先度を有するチャネルから開始して前記セッションに対して決定されたバジェットにより許容可能な数のチャネルに加入するステップと
を更に含む請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記セッションの宛て先において、前記セッションのコストに関する、更新された情報を含んだコスト調整メッセージを繰り返し受信するステップと、
更新されたコストが前記セッションに対するバジェットより低い場合に、前記バジェットにより許容可能な範囲でさらなるチャネルに加入するステップと、
前記更新されたコストがバジェットより高い場合に、最も低い優先度を有するチャネルから開始してバジェットを満たすまで、前記セッションからチャネルを加入取消しするステップと
を更に含む請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記ネットワークは、サービスの異なるクラスと、あるクラスに属するセッションと、割当てられた全ての価値および対応する全帯域幅を有するクラスとを処理することができるものであり、
あるセッションに対し、単位コストは該セッションが属するクラスに応じて概算されるものである、
請求項１〜５のいずれか一項に記載の方法。
【請求項７】
マルチキャストネットワークを介して受信機に配信される、複数のチャネルを含むセッションの受信データレートを受信機ベースで制御する装置であって、
単位コストと、各チャネルのレートと、送信コストに関するバジェットとに基づいて、バジェットにより許容されるチャネルの数を決定し、バジェットを考慮することに基づいてセッションに対し許容可能な数のチャネルを実行する決定ユニット
を備える装置。
【請求項８】
前記単位コストは、
前記セッションの単位帯域幅当たりのコストとして前記単位コストを取得するために、ダウンストリームデバイスからセッション内のソースの方向に位置するアップストリームデバイスに向けて、前記新たなセッションに関する情報を含んだプローブクエリメッセージを送信する送信ユニットと、
前記アップストリームデバイスが前記プローブクエリメッセージを受信するための受信ユニットと、
前記アップストリームデバイスが前記セッションに関するトラフィックを既に受信しつつある場合に、前記新たなセッションの単位コストを概算するユニットと、
前記プローブクエリメッセージの送信元に対して前記セッションの初期単位コストに関する情報を返すために、前記プローブクエリメッセージの送信元に対してプローブアンサメッセージを返す応答ユニットと
を備えた装置によって決定されるものである、請求項７に記載の装置。
【請求項９】
宛て先においてセッションを開始するための開始信号に応じて、セッションの単位コストについてクエリするためにプローブクエリメッセージを生成し、該プローブクエリメッセージを前記セッションのソースへと転送する生成ユニットと、
セッションのソースの方向に位置し、単位コストに関する情報を有するアップストリームデバイスからプローブアンサメッセージを受信する受信ユニットと、
受信した情報に基づいて、最も高い優先度を有するチャネルから開始して、前記セッションに対して決定されたバジェットにより許容可能な数のチャネルに加入する加入ユニットと
を更に備える請求項７または８に記載の装置。
【請求項１０】
セッションの宛て先において、前記セッションのコストに関する、更新された情報を含んだコスト調整メッセージを繰り返し受信する受信ユニットと、
更新されたコストが前記セッションに関するバジェットより低い場合に、前記バジェットにより許容可能な更なるチャネルに加入する加入ユニットと、
前記更新されたコストが前記バジェットより高い場合に、最も低い優先度を有するチャネルから開始してバジェットが満たされるまで、前記セッションからチャネルを加入取消しする加入取消しユニットと
を更に備える請求項７〜９のいずれか一項に記載の装置。
【請求項１１】
コンピュータ上で、請求項１〜６のいずれか一項に記載の方法を実行することを可能にするコンピュータ実行可能なコードを含むコンピュータプログラム。
【外国語明細書】
2010035203.tif 000010
2010035203.tif 000011
2010035203.tif 000012
2010035203.tif 000013
2010035203.tif 000014
2010035203.tif 000015
2010035203.tif 000016
2010035203.tif 000017
2010035203.tif 000018
2010035203.tif 000019
2010035203.tif 000020
2010035203.tif 000021
2010035203.tif 000022
2010035203.tif 000023
2010035203.tif 000024
2010035203.tif 000025
2010035203.tif 000026
2010035203.tif 000027
2010035203.tif 000028
2010035203.tif 000029
2010035203.tif 000030
2010035203.tif 000031
2010035203.tif 000032
2010035203.tif 000033
2010035203.tif 000034
2010035203.tif 000035
2010035203.tif 000036
2010035203.tif 000037
2010035203.tif 000038
2010035203.tif 000039
2010035203.tif 000040
2010035203.tif 000041
2010035203.tif 000042
2010035203.tif 000043
2010035203.tif 000044
2010035203.tif 000045
2010035203.tif 000046
2010035203.tif 000047
2010035203.tif 000048
2010035203.tif 000049
2010035203.tif 000050
2010035203.tif 000051
2010035203.tif 000052
2010035203.tif 000053
2010035203.tif 000054
2010035203.tif 000055
2010035203.tif 000056