(57)【要約】  ネットワーク内において稼動する複数の装置に対してブロードキャストモードにおいてデータを伝送するシステム、装置、及び方法である。本発明は、ブロードキャストされたデータを利用する装置上において稼動しているアプリケーションの所望のサービス品質レベルを提供しつつ、帯域幅の効率的な利用を実現している。本発明は、ネットワーク資源に関する競合状態が存在する際に影響を受けるアプリケーションにとって重要であるサービス品質メトリックに対する影響を極小化する方式による複数のアプリケーション間における帯域幅の割り当て及び再割り当てのために経験則及び規則の組との組み合わせにおいて帯域幅の制約の組を利用している。本発明は、特定の優先度及び保証が維持された状態において、それぞれのアプリケーションに提供されるサービス品質を滑らかに低下させるプロセスを実装している。また、本発明は、アプリケーション用のイベントセグメント化及び再アセンブリ機能をも提供しており、かつ、長期間にわたって能動的に受信していなかったクライアント装置に対してデータを提供する能力を向上させる信頼性メカニズムをも含んでいる。【選択図】図１
2009525641.tif 000002
【特許請求の範囲】
【請求項１】
通信システムを使用してデータを転送する複数のアプリケーション間で前記通信システムの帯域幅を割り当てる方法において、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
前記帯域幅限度は、
前記複数のアプリケーションのすべてのＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップであって、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を含む方法。
【請求項２】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、前記アプリケーションのそれぞれのものに帯域幅を割り当てるステップは、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しておらず、
前記複数のアプリケーションのそれぞれには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられており、
前記ＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられず、かつ、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項１に記載の方法。
【請求項３】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップは、前記それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む請求項１に記載の方法。
【請求項４】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、前記帯域幅調節は、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、その帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられており、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを具備しており、かつ、前記１以上のアプリケーションには、結果的に前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、ステップと、
を更に含む、請求項１に記載の方法。
【請求項５】
アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項１に記載の方法。
【請求項６】
通信ネットワーク上においてデータを複数のクライアント装置に供給する装置において、
アプリケーションを登録すべく構成された登録要素であって、前記アプリケーションは、前記クライアント装置に供給されるデータを提供している、登録要素と、
前記通信ネットワークの帯域幅を前記アプリケーションに割り当てるべく構成された帯域幅割り当て要素と、
前記通信ネットワーク上における搬送のために前記提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、
前記通信ネットワーク上における搬送のために前記フォーマッティングされたデータを前記通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、
を備える装置。
【請求項７】
前記登録要素は、複数のアプリケーションを登録しており、かつ、更には、この場合に、前記帯域幅割り当て要素は、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されている請求項６に記載の装置。
【請求項８】
前記帯域幅割り当て要素は、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されており、
前記帯域幅割り当てプロセスは、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、この場合に、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、この場合に、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
この場合に、前記帯域幅限度は、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップであって、この場合に、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を有する、請求項７に記載の装置。
【請求項９】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップは、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しておらず、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられており、
そのＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられず、かつ、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項８に記載の方法。
【請求項１０】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップは、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項８に記載の方法。
【請求項１１】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、この場合に、前記帯域幅調節は、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、その帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられており、この場合に、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを具備しており、かつ、前記１以上のアプリケーションには、結果的に前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、ステップと、
を更に含む、請求項７に記載の方法。
【請求項１２】
前記アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項６に記載の方法。
【請求項１３】
前記フォーマッティングされたデータは、前記通信ネットワーク上においてブロードキャストされる請求項６に記載の装置。
【請求項１４】
通信ネットワーク上において搬送されたデータを受信する装置において、前記データが前記装置上で稼動しているアプリケーションに提供されるものである装置であって、
前記アプリケーションを登録すべく構成された登録要素と、
前記通信ネットワークから受信したデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットからイベントを生成するデータアセンブリ要素と、
前記受信したデータを保存すべく構成されたキャッシュと、
前記イベントを前記アプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、
を備える装置。
【請求項１５】
前記受信したデータは、前記通信ネットワーク上においてブロードキャストされたものである請求項１４に記載の装置。
【請求項１６】
前記スケジューリング要素は、前記イベントに必要なすべてのデータが受信され、かつ、所望の順序に配置されていると決定された後に、前記イベントを前記アプリケーションに提供すべく構成されている請求項１４に記載の装置。
【請求項１７】
通信ネットワーク上においてクライアント装置にデータを供給するためのシステムにおいて、
サーバーアプリケーションを登録すべく構成された登録要素であって、前記サーバーアプリケーションは、前記クライアントアプリケーションに供給されるデータを提供している、登録要素と、
前記通信ネットワークの帯域幅を前記サーバーアプリケーションに割り当てるべく構成された帯域幅割り当て要素と、
前記通信ネットワーク上における搬送のために前記提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、
前記通信ネットワーク上における搬送のために前記フォーマッティングされたデータを前記通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、
を有するサーバー装置と；
前記クライアントアプリケーションを登録すべく構成された登録要素と、
前記通信ネットワークから受信したデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットを生成するデータアセンブリ要素と、
前記受信したデータを保存すべく構成されたキャッシュと、
前記イベントを前記クライアントアプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、
を有するクライアント装置と；
を備えるシステム。
【請求項１８】
前記サーバー装置及びクライアント装置の間においてデータを搬送すべく構成された通信ネットワークを更に含む、請求項１７に記載のシステム。
【請求項１９】
前記データは、前記通信ネットワーク上においてブロードキャストされている請求項１７に記載のシステム。
【請求項２０】
前記通信ネットワークは、無線ネットワークである請求項１７に記載のシステム。
【請求項２１】
前記サーバー装置の登録要素は、複数のアプリケーションを登録しており、かつ、更には、この場合に、前記帯域幅割り当て要素は、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されている請求項１７に記載のシステム。
【請求項２２】
前記帯域幅割り当て要素は、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されており、
前記帯域幅割り当てプロセスは、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、この場合に、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、この場合に、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
この場合に、前記帯域幅限度は、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれに割り当てるステップであって、この場合に、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を有する、請求項２１に記載の装置。
【請求項２３】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップは、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しておらず、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられており、
そのＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回っていないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられず、かつ、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項２２に記載の方法。
【請求項２４】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップは、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項２２に記載の方法。
【請求項２５】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、この場合に、前記帯域幅調節は、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、その帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられており、この場合に、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを具備しており、かつ、前記１以上のアプリケーションには、結果的に前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、ステップと、
を更に含む、請求項２１に記載の方法。
【請求項２６】
前記サーバーアプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記サーバーアプリケーションに提供するステップと、
を更に含む、請求項１７に記載の方法。
【請求項２７】
通信ネットワーク上においてデータを複数のクライアント装置に配布する方法において、
前記クライアント装置にデータを提供すべくアプリケーションを登録するステップと、
前記アプリケーションに前記通信ネットワークの帯域幅を割り当てるステップと、
前記通信ネットワーク上における搬送のために前記アプリケーションによって提供されたデータを処理するステップと、
前記処理されたデータを前記通信ネットワーク上において搬送するステップと、
を有しており、
この場合に、それぞれのクライアント装置について、前記方法は、
前記クライアント装置にクライアントアプリケーションを登録するステップと、
前記通信ネットワーク上における搬送の後に前記データを受信するステップと、
前記データをストレージ媒体内にキャッシングするステップと、
前記データの供給をスケジューリングするステップと、
前記データを前記クライアントアプリケーションに提供するステップと、
を含む方法。
【請求項２８】
前記処理されたデータを前記通信ネットワーク上において搬送するステップは、前記データを前記通信ネットワーク上においてブロードキャストするステップを更に含む、請求項２７に記載の方法。
【請求項２９】
前記通信ネットワークは、無線ネットワークである請求項２７に記載の方法。
【請求項３０】
データを前記クライアント装置に提供すべくアプリケーションを登録するステップは、複数のアプリケーションを登録するステップを更に有しており、かつ、更には、この場合に、前記通信ネットワークの帯域幅を前記アプリケーションに割り当てるステップは、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を複数のアプリケーションに割り当てるステップを更に有しており、
前記帯域幅割り当てプロセスは、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、この場合に、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、この場合に、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
この場合に、前記帯域幅限度は、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれに割り当てるステップであって、この場合に、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を有する請求項２７に記載の方法。
【請求項３１】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップは、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しておらず、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられており、
そのＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられず、かつ、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項３０記載の方法。
【請求項３２】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップは、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項３０に記載の方法。
【請求項３３】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、この場合に、前記帯域幅調節は、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、その帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられており、この場合に、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを具備しており、かつ、前記１以上のアプリケーションには、結果的に前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、ステップと、
を更に含む、請求項３０に記載の方法。
【請求項３４】
前記アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項２７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願に対する相互参照及び優先権の主張）
本出願は、（１）２００６年１月３１日付けで出願された「Ｒｅｌｉａｂｌｅ  Ｅｖｅｎｔ  Ｓｔｒｅａｍ  Ｄｉｓｔｒｉｂｕｔｏｒ」という名称の米国仮特許出願第６０／７６３，３８５号、（２）２００６年６月２６日付けで出願された「Ｒｅｌｉａｂｌｅ  Ｅｖｅｎｔ  Ｂｒｏａｄｃａｓｔｅｒ」という名称の米国仮特許出願第６０／８１６，３２２号、及び２００６年１２月６日付けで出願された「Ｒｅｌｉａｂｌｅ  Ｅｖｅｎｔ  Ｂｒｏａｄｃａｓｔｅｒ  Ｗｉｔｈ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ａｎｄ  Ｂｒａｎｄｗｉｄｔｈ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎｓ」という名称の米国仮特許出願第６０／８６８，８６８号、及び２００７年１月２４日付で出願された「Ｒｅｌｉａｂｌｅ  Ｅｖｅｎｔ  Ｂｒｏａｄｃａｓｔｅｒ  Ｗｉｔｈ  Ｍｕｌｉｐｌｅｘｉｎｇ  Ａｎｄ  Ｂａｎｄｗｉｄｔｈ  Ｃｏｎｔｔｒｏｌ  Ｆｕｎｃｔｉｏｎｓ」という名称の米国特許出願第１１／６２６，７０７号に関係すると共に、これらの利益を主張するものであって、これらの内容は、本引用により、本明細書にそのすべてが包含される。
本発明は、ネットワーク内において動作する複数の装置に対するニュース、イベント、通知、ファイル、メディアクリップ、及びその他のアプリケーションデータなどのデータの配布と、更に詳しくは、このようなデータのブロードキャストデータ転送モードを使用したクライアント装置に対する配布を効率的に提供及び管理するシステム及び関連する装置並びに方法に関するものである。本発明は、特に、それぞれの装置の個別のアドレス指定がネットワーク資源の使用法の観点において非効率であるかまたはネットワークの帯域幅限度に起因して技術的に実現可能ではない無線ネットワークにおいて動作するモバイル装置に対するデータのブロードキャストに適用可能であるが、これらの説明対象のシステム、装置、及び方法は、その他の装置に適用することも同様に可能であり、かつ、有線または無線ネットワーク上におけるデータ伝送を伴う方式において実装可能であることを理解されたい。
【０００２】
以下の説明の各部分においては、無線ネットワーク内において動作するモバイル無線装置を参照することにより、本発明について説明しているが、本発明のシステム、装置、及び方法は、一般的に、その他のタイプの装置、並びに、（例えば、インターネットに基づいた通信ネットワークなどの固定高速双方向ネットワークまたは一方向における通信が他方向におけるものよりも高速である固定または無線双方向ネットワークなどの）無線ネットワーク以外のネットワークにも適用可能であることを理解されたい。適用可能である装置は、例えば、ＡＴＭ装置、情報キオスク、自動販売機、及びナビゲーションシステムを含んでいる。本発明を適用可能である状況の一例は、ユーザー装置がデータの供給源と通信するための能力を有していないまたは限られた能力しか有していない自動車ナビゲーションシステムであろう。別の例は、アップストリーム通信能力が制限される可能性がある情報キオスクである。一般に、本発明は、一方向（ネットワークから多数の装置に向かう方向）におけるブロードキャストメカニズムまたはその他の効率的なデータ配布メカニズムを有してはいるが、それぞれの装置についてカスタマイズされたデータを取得するための効率的な／費用効率の優れたまたは利用可能な双方向メカニズムを有してはいないクライアント装置に対して最も適用可能性が高い。本発明は、前述のように、このようなネットワークに対して大きな利益を提供しているが、一般に、対称型または非対称型の通信能力を有する高速の固定型または無線双方向ネットワークの環境において使用可能である。
【背景技術】
【０００３】
ユーザーによるデータサービスの利用が増大した結果、これに関連し、利用可能なこのようなサービスのタイプと、それらのユーザーが関心を有する様々なデータ及びアプリケーションが増大している。モバイル無線装置のユーザーは、例えば、スポーツ情報、ニュース、株価情報、自身の装置上において稼動している特定のアプリケーションに固有のリアルタイムデータ、並びに、緊急事態の通知及び場所に固有のデータを受信する能力を、現在持っているか、もうすぐ持つことになるであろう。
【０００４】
しかしながら、携帯電話機、ＰＤＡ、及び無線接続されたラップトップコンピュータなどのモバイル無線装置を使用する際には、これらの装置上において稼動しているアプリケーションにデータを供給すべく設計されたシステムに、特定の考慮事項が発生し、この場合に、これらの考慮事項の中のいくつかのものは、（インターネットに基づいた通信システムなどの）固定型の高速双方向通信システムの場合には、重要でないかまたは関係しないものであろう。例えば、モバイル装置が無線ネットワーク上において中央データストアまたはサーバーと通信しなければならない状況においては、クライアント装置のユーザーにデータ及びコンテンツを転送すべく設計されたシステムに、帯域幅の制約、レイテンシーに関する懸念、断続的な接続性の問題、及び法外なコストという考慮事項が発生することになる。更には、高速有線ネットワークと比べて利用可能な帯域幅が小さいことに起因し、効率的に供給可能なデータまたはコンテンツのタイプまたは複雑性に対して制約が課されることになる。また、モバイルネットワークは、通常、その他のネットワークトラフィックに対する大きな悪影響を伴うことなしには、多数の同時クライアント起動ユニキャスト（即ち、個別にアドレス指定されたサーバーからクライアントへの通信）トランザクションを処理することはできない。同様に、レイテンシー及び間欠的に切断する接続性の懸念も、データまたはコンテンツの供給源と通信してコンテンツの供給を確認するクライアント装置の能力に影響を与えることになろう。更には、モバイル及びその他の専用の装置は、通常、高速の双方向ネットワークに接続されたデスクトップコンピュータまたはその他の装置を使用している際には存在しないデータの保存及び処理に対して制約を課すような特性を持っている。これらの制約は、ディスプレイのサイズ及び分解能、データ処理速度、及びデータストレージ容量を含み得る。
【０００５】
この結果、データが装置に対してどれだけ良好に供給されるかを判断する際の閾値の問題は、名宛人である受信者とネットワークインフラストラクチャの間の通信に使用されるデータ転送モードの問題である。多くのタイプのネットワークにおいては、ネットワークインフラストラクチャと個々のユーザーの間の通信は、ポイントツーポイント通信または受信者のグループに対するデータのブロードキャストによって実現可能である。それぞれのデータ転送方法は、最適なネットワークインフラストラクチャの使用法との関連において、かつ、転送されるデータタイプの有効な使用法の実現との関連において、特定の利点及び関連する欠点を持っている。
【０００６】
例えば、ポイントツーポイント通信は、受信者装置のアドレス指定、専用帯域幅の割り当て、並びに、装置からの要求の管理及びこれらの要求に対する応答の関連する処理の観点において、大きなインフラストラクチャを必要とし得ることから、相対的に小さな受信者のグループの場合に、最も効率的である。ポイントツーポイント通信の別の欠点は、ネットワーク資源及びオーバーヘッドの観点におけるコストが、伝送を受信するクライアント装置の数に比例しており、この結果、一般的に、コストが、受信者の数によって直接的に増減するという点にある。
【０００７】
これとは対照的に、受信者の相対的に大きなグループに対するデータのブロードキャストは、特定の状況においてや、特定タイプのデータとの関連においては、ネットワークインフラストラクチャの資源を割り当てるための相対的に費用効率の優れた良好な方法であろう。ブロードキャスト法は、効率性及びスケーラビリティの観点において利益を提供しており、データをブロードキャストする費用は、受信者の数に直接的に比例してはいない。ブロードキャスト法によれば、クライアント側の要求をサーバーに伝達することを要することなしに、データを受信者の大きなグループに対して効率的に供給可能であり、かつ、特定タイプのアプリケーションにおける資源使用法の観点において、相対的に効率的であろう。ブロードキャスト法は、相対的に低い転送データビット当たりのコストを提供する能力を有しており、かつ、特定のアプリケーションにおいては、関心を有するユーザーに対してデータを提供するための相対的に実際的かつ効率的な手段であろう。
【０００８】
また、データまたはそのデータの宛先であるアプリケーションのタイプも、望ましいデータ転送モードを決定する際に考慮すべき要因をもたらすことになろう。特定タイプのアプリケーションは、クライアントの大きな組に対するデータの非同期同時配布を必要としている。これらのアプリケーションは、限定を伴うことなしに、安全警報、緊急事態の通知、交通及び極端な天気の更新、スポーツイベントの更新、ニュースの更新、株価情報の更新、並びに、ユーザーの大きなグループが潜在的な関心を有していると共に時間の影響を受けやすいまたはその価値が迅速に失われるその他のデータを含んでいる。このようなアプリケーションの場合には、データを具体的に要求したユーザーに対してのみ応答することよりも、関連データをネットワークのカバレージ内の領域または区画に対して提供することのほうが重要であろう。更には、間欠的なまたは信頼性の低いカバレージの状況においては、要求−応答のやり取りを処理するのに必要な時間及びネットワーク資源が、必要時に利用可能ではない場合もあろう。
【０００９】
これらの並びにその他の理由から、かつ、特に、多くのモバイルデータネットワークなどの帯域幅が制限されたデータ配布ネットワークの場合には、イベントまたはデータの配布にブロードキャストモードを利用するほうが、しばしば有利である。本明細書に使用されている「イベント」または「データ」という用語は、データを受信するアプリケーションにとって有意であるかまたはこれに関係している任意のサイズ及びタイプのデータを意味していることに留意する。この例には、受信アプリケーションのユーザーに対して表示されるべく宛先が設定されたメッセージ、アプリケーション内において提示される（例えば、ニュース、天気、スポーツ情報または更新などの）データ、ユーザーに対して再生されるビデオクリップ、またはアプリケーション用のデータ更新が含まれる。消失データパケットが存在している状況に対して大きな柔軟性を有するように設計されたストリーミングデメディアなどのアプリケーションとは対照的に、いくつかのアプリケーションは、データ及び／またはイベントが確実にかつ順番に受信及び処理されることに依存する可能性がある。更には、しばしば、データ及び／またはイベントは、時間的に十分に離隔しており、アプリケーションは、バッファリングしたデータストリームを処理するのではなく、データ及びイベントの到着に伴って個々の通知を待ち受けている。
【００１０】
無線ネットワークに接続されたモバイル装置用の、または、更に一般的には、高速双方向ネットワーク以外のネットワークに接続された装置用のデータ供給システムの設計における重要な考慮事項は、ネットワーク事業者にとって効率的でありつつ、エンドユーザーの意図する使用法にとって効率的である方法により、データを提供するということである。この意味におけるネットワーク事業者の「効率性」は、一般的に、限られたまたは制約されたネットワーク資源の最適な使用法における考慮事項を伴っている。これらの資源は、帯域幅（並びに、関連するデータ転送資源）と、（クライアント装置との要求−応答のやり取りを処理すべく使用可能である）データ処理資源を含んでいる。更には、「エンドユーザーの意図する使用法にとって効率的である」とは、データがタイムリーであり、ユーザーの利用に望ましいように提示されることを意味している。
【００１１】
前述のように、ポイントツーポイントまたはブロードキャストデータ転送モードのいずれを使用する場合にも、重要な考慮事項は、ネットワーク資源、主には、帯域幅及びデータ処理資源の効率的な使用法である。クライアントからサーバーに対して要求を転送すべく、またはその要求に対する（例えば、テキスト、オーディオ、ビデオ、マルチメディア、通知などの形態のデータなどの）応答をクライアント装置に転送すべくポイントツーポイントモードにおいて使用される場合も、帯域幅は、限られたかつ価値ある資源である。同様に、ブロードキャストモードの場合にも、データが多数のサービス元のアプリケーションから多数のクライアント装置に転送されており、これらのクライアント装置の中には、データをブロードキャストしている特定のアプリケーションのデータに関心を有しているものも、有していないものもあり得るが、帯域幅は、やはり重要な資源である。更には、多数のクライアント装置が要求またはデータを相対的に小さなタイムフレーム内において中央サーバーに送信している場合には、クライアント要求の受信及び処理に必要なものなどのデータ処理資源が、ネットワークにとって大きな負担となる可能性がある。
【００１２】
帯域幅は、限られた資源であるため、複数のユーザー間において、その帯域幅を利用してデータサービスをユーザーに提供している複数のアプリケーション間において、効率的に割り当てる必要がある。複数のアプリケーションにおける帯域幅の使用法には、通常、専用と共有という２つの基本モードが存在している。専用とは、固定量の帯域幅をそれぞれのアプリケーションに提供する方法を意味しており、このようなそれぞれのアプリケーションは、その帯域幅を必要に応じて利用可能である。共有とは、複数のアプリケーションが一定量の帯域幅を共有する方法を意味しており、特定の規則または経験則を適用することにより、それらのアプリケーションの潜在的に矛盾する帯域幅需要の間においてネゴシエートしている。
【００１３】
様々なアプリケーション及びそれらのアプリケーションのユーザー間における帯域幅の割り当ては、様々な方法に基づいたものであってよいが、使用する方法の決定においては、通常、データ及びアプリケーションのタイプとそのデータを良好に供給及び提示する程度、平均的な及び需要が増大した期間の両方におけるデータの帯域幅要件、並びに、そのアプリケーションの所望のまたは必要なサービス品質（ＱｏＳ）を損なうことなしに帯域幅の初期割り当てを最も良く変更できるか、といった要因を考慮することになる。
【００１４】
例えば、非ストリーミングのデータアプリケーション（即ち、例えば、ストリーミングオーディオまたはビデオ以外のもの）に帯域幅を専用とすることは、資源を割り当てる効率的な方法ではない。この理由は、このようなアプリケーションは、割り当てられた帯域幅を長期間にわたって完全には利用しないためである。これらは、しばしば、アイドル状態にあり、かつ、帯域幅を必要とする際には、データをバースト送信する必要があろう。従って、ブロードキャストチャネルをこのようなアプリケーションに専用とする従来の方法は、ネットワーク内において利用可能である限られた帯域幅を完全に利用するという観点においては、非効率的である。
【００１５】
前述のように、利用可能な帯域幅の一部をそれぞれのアプリケーションに専用とする代わりに、別の可能な方法は、複数のアプリケーションによる一定量の帯域幅の共有を許容するという方法である。しかしながら、共有帯域幅モデルの実装は、大きな課題をもたらすことになる。この理由は、帯域幅を共有しているアプリケーションは、帯域幅資源を適切に共有すべく協働する必要があるためである。更には、ネットワーク事業者は、複数のアプリケーションの帯域幅需要の間に発生する矛盾を解決すべく、規則または経験則の組を必要とすることになろう。例えば、複数のアプリケーションが同時にデータを伝送することが必要となる可能性があり、あるいは、それらに割り当てられた帯域幅限度に制約することができない場合もあろう。アプリケーションは、その他のアプリケーションが同一のネットワーク資源を使用している方法について認識しておらず、これを認識している場合にも、ブロードキャストセッションにおけるその他のアプリケーションの使用パターンについて合理的に認識することはできないため（この場合には、使用パターンにより、割り当てられた量を超過する帯域幅に対する需要が発生し得る）、この結果、システムにとって物理的に利用可能であるものを上回るネットワーク帯域幅資源を使用しようと試みることがあり得る。
【００１６】
ベースライン帯域幅共有モデルを変更するための可能な方法は、複数のアプリケーションが帯域幅を共有できるようにすると共に、ネットワーク上において最高優先度のイベントを次にブロードキャストさせるポリシーとの関連において、伝送対象のデータに優先度付け方式を導入するというものである。これは、優先度インジケータをデータパケットに「タグ付け」することによってキューから最初に送信するべきパケットを識別し、この後に、相対的に低い優先権を有するものが続くようにすることにより、実現可能である。この方法は、アイドル状態のアプリケーションが、さもなければ利用可能である帯域幅を浪費することがないため、ベースライン共有法よりも、共有資源を相対的に良好に利用している。しかしながら、相対的に低い優先度を有するデータが、まったく送信されないか、またはその供給が非効率なものになるほどに遅延する可能性があるため、これは、最適な解決策ではない。この理由は、相対的に高い優先度のアプリケーションがネットワーク資源に対して大きな需要を課した場合に、この方法を使用すれば、相対的に低い優先度のアプリケーションが、必要な帯域幅の「飢餓」状態になる可能性があるためである。また、パケットに優先度標識をタグ付けした後に相対的な優先度を変更することができないため（従って、相対的な供給順序を変更することができないため）、この方法は、あまり柔軟ではない。更には、高トラフィック状態に起因し、パケットを伝送スケジュールからドロップさせる必要がある際に、どのパケットをドロップし、どれをブロードキャストするのかを決定するための有意な方法が存在していない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ブロードキャストデータ転送モードを効率的に使用することにより、ネットワーク内において稼動する複数のクライアント装置上において稼動している様々なアプリケーションに対するデータの配布を管理するシステム、装置、及び方法が求められており、この場合に、これらのシステム、装置、及び方法は、既存の方法における前述の欠点を克服している。
【課題を解決するための手段】
【００１８】
本発明は、ネットワーク内において稼動する複数の装置にブロードキャストモードにおいてデータを伝送するシステム、装置、及び方法に関するものである。本発明は、データを利用する装置上において稼動しているアプリケーションにとって望ましいサービス品質レベルを提供しつつ、帯域幅などのネットワーク資源を効率的に利用する方式によって設計及び実装されている。
【００１９】
本発明は、一般的な帯域幅共有法によって提供されているものよりも最適な方法によって複数のアプリケーションが帯域幅を共有する方法を提供している。この機能は、特定タイプのアプリケーションは、帯域幅割り当てのための「ソフト・リアルタイム」要件の下に効率的に動作可能であり、これにより、特定量のネゴシエーション及び帯域幅の（再）割り当てを利用して複数アプリケーションの潜在的に矛盾する需要を満足させることが可能であるという本発明者による認識の結果として得られたものである。本発明は、影響を受けるアプリケーションにとって重要であるサービス品質メトリックに対する影響を極小化する方式により、複数のアプリケーションの間における帯域幅の割り当て及び再割り当てのための経験則及び規則の組との組み合わせにおいて、帯域幅制約の組を利用している。本発明の文脈においては、個々のアプリケーションは、それらが帯域幅について競合している際を除いて、大部分の場合に、複数の帯域幅要求の多重化について認識しておらず、必要に応じて、本発明は、特定の優先度及びサービス保証が維持された状態において、それぞれのアプリケーションに提供されるサービス品質が滑らかに低下するようにするプロセスを実装している。
【００２０】
大部分のブロードキャストデータネットワークを利用するには、データトラフィックをパケットに分割しなければならない。この観点において、本発明は、アプリケーション用のイベントセグメント化及び再アセンブリ機能を提供している。また、ブロードキャストによる配布は、一方通行であって、信頼性が低く（または、低いことがあり得）、一般的に、イベントが生成された時点において受信者が聴取していることを保証するためのメカニズムを欠いているため（例えば、受信が不連続であり、クライアントがストリームの途中においてブロードキャストに参加するため）、本発明は、ブロードキャストのすべてを能動的に受信しなかったクライアント装置に対してデータを提供する能力を向上させる信頼性メカニズムをも含んでいる。
【００２１】
一実施形態においては、本発明は、通信システムを使用してデータを転送する複数のアプリケーション間において通信システムの帯域幅を割り当てる方法に関係している。この方法は、すべてのアプリケーションにとって利用可能である総帯域幅ＢAの値を決定するステップと、それぞれのアプリケーションの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、それぞれのアプリケーションの第２帯域幅限度Ｂ2を決定するステップであって、Ｂ2は、第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、それぞれのアプリケーションの相対的な優先度レベルを決定するステップと、を含んでおり、この場合に、相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している。これらの帯域幅限度は、すべてのアプリケーションのＢ1の合計がＢAを超過しておらず、かつ、それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度Ｐ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、という関係を満足している。本発明の方法は、アプリケーションのそれぞれのものに帯域幅を割り当てており、この場合に、この帯域幅割り当ては、すべてのアプリケーションに対して割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している。
【００２２】
別の実施形態においては、本発明は、通信ネットワーク上においてデータを複数のクライアント装置に対して供給する装置に関するものであり、この場合に、この装置は、アプリケーションを登録すべく構成された登録要素であって、アプリケーションは、クライアント装置に供給されるデータを提供している、登録要素と、通信ネットワークの帯域幅をアプリケーションに割り当てるべく構成された帯域幅割り当て要素と、通信ネットワーク上における搬送のために、提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、フォーマッティングされたデータを通信ネットワーク上における搬送のために通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、含んでいる。
【００２３】
別の実施形態においては、本発明は、装置上において稼動しているアプリケーション宛の通信ネットワーク上において搬送されたデータを受信する装置に関するものであり、この場合に、この装置は、アプリケーションを登録すべく構成された登録要素と、通信ネットワークから受信されたデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットからイベントを生成しているデータアセンブリ要素と、受信したデータを保存すべく構成されたキャッシュと、イベントをアプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、を含んでいる。
【００２４】
別の実施形態においては、本発明は、通信ネットワーク上においてクライアントアプリケーションにデータを供給するためのシステムに関するものであり、このシステムは、サーバー装置と、クライアント装置と、を含んでいる。サーバー装置は、サーバーアプリケーションを登録すべく構成された登録要素であって、サーバーアプリケーションは、クライアントアプリケーションに供給されるデータを提供している、登録要素と、通信ネットワークの帯域幅をサーバーアプリケーションに割り当てるべく構成された帯域幅割り当て要素と、通信ネットワーク上における搬送のために、提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、通信ネットワーク上における搬送のためにフォーマッティングされたデータを通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、を含んでいる。クライアント装置は、クライアントアプリケーションを登録すべく構成された登録要素と、通信ネットワークから受信されたデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットからイベントを生成するデータアセンブリ要素と、受信したデータを保存すべく構成されたキャッシュと、イベントをクライアントアプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、を含んでいる。
【００２５】
別の実施形態においては、本発明は、通信ネットワーク上においてデータを複数のクライアント装置に配布する方法に関係しており、この方法は、データをクライアント装置に提供すべくアプリケーションを登録するステップと、通信ネットワークの帯域幅をアプリケーションに割り当てるステップと、アプリケーションによって提供されたデータを通信ネットワーク上における搬送のために処理するステップと、処理されたデータを通信ネットワーク上において搬送するステップと、を含んでおり、それぞれのクライアント装置について、本方法は、クライアントアプリケーションをクライアント装置に登録するステップと、通信ネットワーク上における搬送の後にデータを受信するステップと、データをストレージ媒体内にキャッシングするステップと、データの供給をスケジューリングするステップと、データをクライアントアプリケーションに提供するステップと、を含んでいる。
【００２６】
本発明のその他の目的及び利点については、添付の図面並びに以下の本発明に関する詳細な説明を参照することにより、当業者に明らかとなろう。
【発明を実施するための最良の形態】
【００２７】
本発明の実施形態及び利益に関する以下の説明を良好かつ十分に理解できるようにするには、使用する特定の用語及び定義を明確にしておくことが有用である。これらの用語及び定義は、わかりやすくすべく提示されるものであって、本発明の実施形態または特許請求されている発明に対して制限または制約を課すためのものではないことを理解されたい。
【００２８】
本発明の説明においては、次の用語は、以下に記述されている一般的な意味を具備しているものと理解されたい。
【００２９】
カルーセル：カルーセルとは、継続的にブロードキャストされるイベントの集まりである。カルーセル内の最後のイベントがブロードキャストされた際には、そのカルーセル内の最初のイベントによってブロードキャストが継続される。任意の時点においてイベントをカルーセル上に配置または除去可能である。ブロードキャストサービスを使用しているそれぞれのアプリケーションには、１以上のカルーセルが割り当てられている。複数のカルーセルを使用することにより、アプリケーションは、自身がブロードキャストしている様々なイベントクラスを優先順序付け可能である。
【００３０】
カルーセル上のイベントは、必ずしも、先入れ先出しなどの設定された順序によって供給する必要はない。カルーセル上のアイテムは、キューの先頭にイベントを移動または配置することにより、あるいは、次にブロードキャストするイベントを決定するなんらかのタイプの優先度システムを使用してイベントにタグ付けすることにより、任意の順序でブロードキャスト可能である。
【００３１】
カルーセルサイズ：カルーセルのサイズは、カルーセル上に含まれているイベントのサイズ及び数によって決定される。カルーセルサイズは、カルーセルの割り当て帯域幅と共に、カルーセル上のイベントをブロードキャスト可能である頻度を決定している。
【００３２】
カルーセルサイクル時間：カルーセルのサイクル時間とは、カルーセルの内容物のすべてをブロードキャストするのに要する時間量である。カルーセルサイクル時間は、カルーセルのサイズと、そのカルーセルに割り当てられた帯域幅によって左右される。
【００３３】
カルーセル帯域幅：カルーセル帯域幅とは、カルーセルのデータをブロードキャストするレートである。
【００３４】
リンガー時間：リンガー時間とは、イベントがカルーセル上に留まる時間である。リンガー時間は、カルーセルのサイクル時間と共に、イベントが（再）ブロードキャストされる回数を決定している。
【００３５】
ブロードキャスト・マネージャ：ブロードキャスト・マネージャは、ブロードキャスト配布ネットワーク上において供給すべく、それぞれのカルーセルからパケットを取得する責任を担っている。ブロードキャスト・マネージャは、対応するセッションポリシーからそれぞれのカルーセルの優先度を取得し、この情報を使用することにより、それぞれのカルーセルからデータを取得するレートを決定している。
【００３６】
イベント・スケジューラ：イベントスケジュールは、それぞれのカルーセルの優先度を決定し、イベントの要件及び優先度に基づいて、それぞれのカルーセルにイベントを配置または除去している。アプリケーションが複数のカルーセルを具備している場合には、スケジューラは、それらのカルーセルの間においてイベントを移動可能である。
【００３７】
インテイク・マネージャ：インテイク・マネージャは、ネットワーク上においてブロードキャストすべく、アプリケーションからイベントを受信している。データ圧縮を使用する場合には、インテイク・マネージャがイベントを圧縮している。
【００３８】
順序どおりの供給などの機能を支援すべく、イベントタグをイベントに付加可能である。イベントは、適切なカルーセル上への配置のために、イベント・スケジューラに伝達されている。
【００３９】
レイテンシー：レイテンシーとは、イベントがカルーセル上に配置された時点とイベントが初めて最終的に完全にブロードキャストされた時点の間の時間を意味している。
【００４０】
ブロードキャスト・サーバー：ブロードキャスト・サーバーは、ブロードキャストネットワーク上においてアプリケーションがイベントをブロードキャストするためのメカニズムを提供している。アプリケーションは、ブロードキャスト資源を共有しているその他のアプリケーションやブロードキャスト媒体上においてデータを実際にブロードキャストすべく使用されているその他のメカニズムについて認識する必要はない。ブロードキャスト・サーバーが、信頼性の高い供給、圧縮、優先度付け、及び帯域幅制御などの機能を提供及び／または管理している。
【００４１】
ブロードキャスト・クライアント・ツールキット：ブロードキャスト・クライアント・ツールキットは、クライアント装置上において稼動しているアプリケーションに対してＡＰＩの組を提供している。これらのＡＰＩにより、クライアントアプリケーションは、ブロードキャストネットワークを使用しているアプリケーションからイベントを受信すべく登録可能である。
【００４２】
イベント：イベントとは、イベントを受信するアプリケーションにとって有意である任意のサイズ及びタイプのデータ片である。イベントは、ファイル、通知、警報、メディアクリップ、またはその他のデータオブジェクトであってよい。イベントは、アプリケーションに応じて、連続的にまたは不定期に送信可能である。
【００４３】
セッション：セッションは、配布するイベントをアプリケーションが具備している際に常にセットアップされる。セッションは、チャネルを使用してイベントをブロードキャストする方法を決定する特定の特性を具備している。これらの特性は、レイテンシー、信頼性、及びリンガー時間などのパラメータを含んでいる。
【００４４】
セグメント化：アプリケーションが送信を所望しているイベントが、基礎をなしているブロードキャストネットワークの最大パケットサイズを上回る可能性がある。このようなケースにおいては、イベントは、最大パケットサイズにフィットする塊に分割しなければならない。このプロセスをセグメント化と呼んでいる。
【００４５】
再アセンブリ：再アセンブリは、複数のパケットを組み合わせることにより、送信されたオリジナルのイベントを再構築するプロセスである。
【００４６】
再ブロードキャスト：再ブロードキャストは、ネットワークを継続的に聴取していない受信機がイベントを受信できるようにすべく、同一のイベントを複数回にわたってネットワーク上において送信するプロセスである。
【００４７】
ＦＥＣ：前進型誤信号訂正は、データ伝送のための誤り低減のシステムであり、この場合には、冗長なデータをブロードキャストデータに加えて送信している。この結果、受信者がデータの再送を送信者に要求することなしに、特定の誤りを検出及び訂正可能である。前進型誤信号訂正の利点は、データの再送を（平均的に相対的に高い帯域幅要件の犠牲を払って）しばしば回避可能であるという点にあり、従って、モバイルブロードキャストネットワークなどのように再送が相対的に高価であるかまたは不可能である状況に適用されている。
【００４８】
多重化：多重化は、複数のアプリケーションが同一のブロードキャスト資源を共有するプロセスである。アプリケーションが最小限の量の帯域幅またはその他のネットワーク資源を受け取ることを別のアプリケーションが妨げることのないように、複数のアプリケーションからのイベントをブロードキャストネットワーク上においてインターリーブしている。
【００４９】
サービス品質（ＱｏＳ）：ＱｏＳとは、（その他にも可能な定義のがあるが）イベントが所望の期間内に正常に供給される確率を意味している。
【００５０】
総帯域幅：総帯域幅とは、同一のネットワーク資源を使用しているすべてのアプリケーションについて、ネットワーク事業者が利用可能であるトータル帯域幅である。
【００５１】
最小保証帯域幅：最小保証帯域幅とは、アプリケーションセッションがイベントの供給のために保証されている最小限の帯域幅である。その他のアプリケーションによってブロードキャストされる相対的に高い優先度のイベントまたは通知が存在していない正常な動作においては、アプリケーションが利用可能である実際の帯域幅は、通常、最小保証帯域幅を上回ることになる。最小保証帯域幅は、一般に、アプリケーションが長期間にわたって正常に動作するのに十分なものになるようには、意図されていない。これは、相対的に高い優先度のアプリケーションによるトラフィック要件に起因して、アプリケーションが絶対に飢餓状態にならないようにすべく使用されるものである。
【００５２】
最大許容可能帯域幅：最大許容可能帯域幅とは、その他のアプリケーションがブロードキャスト資源を使用していない場合にアプリケーションセッションに割り当てられることになる最大限の帯域幅である。最大許容可能帯域幅は、総帯域幅に等しくなるようにしてもよいが、事業者は、その他の理由から、これを更に低く設定することも可能である。
【００５３】
予想帯域幅：予想帯域幅とは、システム内に更に高い優先度のイベントが存在していない限り、アプリケーションが受け取ることが保証されている帯域幅である。同一の優先度レベル以下のアプリケーションは、予想帯域幅を下回るものをアプリケーションに取得させることはできない。更に高い優先度のアプリケーションは、この帯域幅を優先使用可能ではあるが、長期にわたってこれが実行されることを意味するものではない。アプリケーションは、優先使用が短期間にわたってのみ行われるように準備する必要がある。
【００５４】
割り当て帯域幅：割り当て帯域幅とは、アプリケーションが動作することを現在許容されている帯域幅である。これは、以上において定義した閾値の中の１つであってもよく、それらの中間の任意の値であってもよい。アプリケーションがその割り当て帯域幅を下回るものを使用している場合には、後から要求可能であるという保証の下に、その差をシステム内のその他のアプリケーションに提供可能である。アプリケーションは、その割り当て帯域幅を上回るものを使用することはできないが、必要に応じて、更に要求可能である。帯域幅が利用可能であれば、後から取り返されるという条件の下に、そのアプリケーションに割り当てられることになる。割り当て帯域幅は、動的なものであり、その他のアプリケーションの活動に基づいて時間と共に変化可能である。
【００５５】
本発明は、ブロードキャストデータ転送モードを使用することにより、複数の装置上において稼動しているアプリケーションにデータを供給するシステム、装置、及び関連する方法に関するものである。本発明は、通常、命令のセットがクライアント及びサーバー要素の両方において実行されているクライアント−サーバーアーキテクチャに実装される。このアーキテクチャの１つの特徴は、ネットワーク事業者とアプリケーション開発者の両方が利益を享受できるという点にあり、このアーキテクチャにより、事業者は、ブロードキャストネットワークの動作または動作状態に関する詳細事項をアプリケーション開発者に見せることなく、ネットワーク資源の使用を制御し最適化することが可能である。
【００５６】
本発明によれば、ブロードキャスト環境におけるアプリケーションは、同一のブロードキャストネットワークを使用しているその他のアプリケーションとの間において、限られた帯域幅資源を効率的に共有しつつ、イベント、通知、及びその他のデータを確実に、リアルタイムで多数の受信者に配布可能である。アプリケーションは、資源を共有しているその他のアプリケーション、あるいは、ブロードキャスト媒体上においてデータをブロードキャストするのに使用されている方法、プロトコル、またはその他のメカニズムについて認識する必要はない。ネットワーク事業者が、ネットワークのインフラストラクチャ及び資源の使用に関する制御を保持する一方で、最低限のレベルのサービス品質（ＱｏＳ）は、アプリケーションに保証することができる。
【００５７】
一実施形態においては、本発明は、ブロードキャスト・サーバー（Ｂｒｏａｄｃａｓｔ  Ｓｅｒｖｅｒ：ＢＳ）及びブロードキャスト・クライアント・ツールキット（Ｂｒｏａｄｃａｓｔ  Ｃｌｉｅｎｔ  Ｔｏｏｌｋｉｔ：ＢＣＴ）を含むクライアント−サーバーアーキテクチャの形態において実装される。データをサービスするか、通知を送信するか、またはイベントを配布するサーバー側アプリケーションは、ブロードキャスト・サーバーに登録している。このようなデータ、通知、またはイベントの受信を所望するクライアントアプリケーションは、ブロードキャスト・クライアント・ツールキットに登録している。ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、協働することにより、データ、通知、及びイベントを関連するアプリケーションのためにブロードキャストネットワーク上において確実にかつ効率的に伝送している。ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットの各コンポーネントは、イベントのセグメント化及び再アセンブリ、誤り訂正及び再送の形態におけるデータ転送の信頼性、データの圧縮、イベントの優先度付け、順序どおりの供給、及びネットワークの予想性能に関するフィードバックを包含可能である機能を提供している。更には、ブロードキャスト・サーバーは、アプリケーションがネットワーク資源を活用できるようにするためのゲートキーパー及びコントローラとしても機能しているため、ブロードキャストネットワークの事業者に利益を提供する。
【００５８】
本発明は、多数の装置に共有されたブロードキャストネットワーク上においてアプリケーションがイベントを供給できるようにする確実で効率的な方法を含む。アプリケーションは、ネットワーク上におけるイベントの供給に関連した多くの詳細事項及び同一ブロードキャストネットワークを共有しているその他のアプリケーションから遮断される。ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、それぞれのアプリケーションの及び全体的なシステム動作のサービス品質を最適化すべく、アプリケーションに機能の組を提供する。ブロードキャスト・サーバー（ＢＳ）は、ネットワーク上において確実にブロードブロードキャストされると共に多数のクライアントによって受信可能であるイベントをパブリッシュする能力をサーバー側アプリケーションに提供する。クライアント側アプリケーションは、ブロードキャスト・クライアント・ツールキット（ＢＣＴ）を利用することにより、これらのイベントを予約し、受信する。
【００５９】
ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットの主要な要素及び個々の機能については、更に詳述するが、以下の内容は、本発明のシステム内のこれらの要素及びこれらの動作の簡潔な概要である。ブロードキャスト・サーバーは、いくつかのコンポーネントを通じて前述の機能及び能力を提供する。例えば、ポリシーマネージャ要素を使用することにより、ネットワーク事業者またはその他のマネージャは、アプリケーションポリシーの組を生成可能である。アプリケーションポリシーは、ブロードキャスト・サーバーによって提供されるサービスを使用しているそれぞれのアプリケーションの帯域幅限度を定義可能である。また、これらは、利用可能な帯域幅をアプリケーションが共有すると共に個別にその割り当てを受ける方法を決定する優先度及び／またはプロセスを定義することも可能である。
【００６０】
アプリケーションポリシーは、セッションマネージャ及びイベント・スケジューラ要素によって使用されている。セッションマネージャ要素は、イベント（即ち、データ）の発行を望んでいるアプリケーションのためにセッションをセットアップする責任を担っている。イベント・スケジューラ要素は、ブロードキャスト対象のイベントをスケジューリングする責任を担っており、かつ、システムを現在使用しているそれぞれのアプリケーションに対して提供するサービス品質（ＱｏＳ）を決定する。インテイク・マネージャ要素は、アプリケーションからブロードキャストされる新しいイベントを受信する責任を担っており、かつ、それらのイベントを圧縮したり、システムのその他の部分を支援したりすべくそれらに対して追加情報をタグ付け可能である。それぞれのアプリケーションセッションには、イベントカルーセルが割り振られており、イベントカルーセルは、そのアプリケーションについてブロードキャストされるイベントを含む。セッションポリシーを使用することにより、その現在割り当てられている帯域幅、帯域幅限度、及びサービス品質ポリシーなどのそれぞれのカルーセルの特性を規定する。
【００６１】
セッションマネージャ要素は、アプリケーションがセッションを起動した際に初期セッションポリシーを設定し、次いで、イベント・スケジューラ要素が、必要に応じて、システムに進入する新しいイベントまたはアプリケーションポリシー内の変化に基づいて、セッションポリシーを変更する。パケットマネージャ要素は、イベントをパケットに分割し、ブロードキャストネットワーク上における供給のために、それらをフォーマッティングする。これは、関連セッションポリシー内に定義されているサービス品質をサポートすべく前進型誤信号訂正（ＦＥＣ）を追加するステップを包含可能である。ブロードキャスト・マネージャ要素は、ネットワーク上におけるイベントパケットの実際のブロードキャストを制御し、これは、有効なセッションポリシーに基づいて適切なカルーセルからパケットを取得することによって実現される。
【００６２】
ブロードキャスト・クライアント・ツールキット（ＢＣＴ）は、多数のコンポーネントを通じて、クライアント装置上において稼動しているすべてのアプリケーションのための共通サービス及びアクセスポイントを提供する。アプリケーションが、１以上のイベント供給源からイベントを受信すべく登録するのに伴って、クライアントセッションマネージャにより、アプリケーションポリシーをセットアップ可能である。アプリケーションポリシーは、それぞれのアプリケーションが登録する（即ち、イベント／データの受信を所望している先の）イベント供給源と、イベントを順番どおりに受信する必要性などのその他のセッション情報またはサービス要求について記述する。ブロードキャストネットワークからのパケットを再アセンブリマネージャ要素によって受信し、クライアントイベントキャッシュ内に保存する。イベントのすべてのパケットを受信した際に、再アセンブリマネージャ要素は、イベントマネージャ要素に通知する。イベントマネージャ要素は、イベントのタグまたはその他の関連メタデータを検査することにより、そのイベントを受信すべく登録されているアプリケーションにそのイベントを転送するかどうかを決定する。転送することが適切であると決定された場合には、配布マネージャ要素は、タグ情報またはその他のメタデータを除去し、かつ、その供給源（サーバー側）であるアプリケーションからイベントを受信すべく登録されているアプリケーションに対してそのイベントを供給する。アプリケーションがそのイベントの処理を終了したら、イベントマネージャ要素は、キャッシュからのその除去を制御可能である。
【００６３】
以下における図面の更に詳細な検討及び説明においては、様々な図面中の特定の要素を同一符号によって表現する場合があることに留意する。このような場合には、参照された要素は、図面中の、並びに、適宜、それらの図面の添付の説明との関連における同一または等価な要素を表すことを意図している。
【００６４】
図１は、本発明のシステムアーキテクチャ１００の主要機能要素を示すブロックダイアグラムである。図示のように、基本アーキテクチャは、サーバー要素１１０（「ブロードキャスト・サーバー（ＢＳ）」と呼ばれている）と、クライアント要素１２０（「ブロードキャスト・クライアント・ツールキット（ＢＣＴ）」と呼ばれる）と、を含む。動作の際には、１以上のアプリケーション１３０（図面においては、１以上のサービスサイドアプリケーションと呼ばれている）は、その上においてブロードキャスト・クライアント・ツールキット１２０が稼動しているクライアント装置に対してパケット１４０の形態でデータを提供すべく、ブロードキャスト・サーバー１１０に登録する。データパケット１４０は、ブロードキャスト配布ネットワーク１６０上において転送されており、データパケット１５０としてネットワークから出た後に、１以上のクライアント装置によって受信される。１以上のアプリケーション１７０（図面においては、１以上のクライアント側アプリケーションと呼ばれる）は、アプリケーション１３０からデータを受信すべく、それぞれのブロードキャスト・クライアント・ツールキット１２０に登録する。図示されているように、サーバー側アプリケーションは、事実上、ブロードキャスト・サーバー１１０のデータをパブリッシュすることにより、ブロードキャスト・クライアント・ツールキット１２０の仲介によるクライアント側アプリケーションに対するネットワークを介した配布を管理する。ネットワーク資源の使用法及びその他の管理タスクのためのポリシーは、ネットワーク事業者またはその他の管理機能１７０によって提供可能である。
【００６５】
詳述するように、ブロードキャスト・サーバー１１０及びブロードキャスト・クライアント・ツールキット１２０は、本発明のシステムが、所望のレベルのサービス品質をユーザーに提供しつつ、ネットワーク資源を効率的に管理できるようにする複数の機能を実行する。
【００６６】
例えば、これらの機能の中の１つとして、ブロードキャスト・サーバー（ＢＳ）１１０は、次のような能力を提供可能である。
【００６７】
・基礎をなしているネットワークの搬送法及び要素の特性に準拠したパケットへのデータ／イベントのセグメント化
・データ転送の信頼性を向上させるための前進型誤信号訂正（ＦＥＣ）の使用
・すべてのクライアントがイベントを受信する尤度を向上させるためのクライアントに対するイベントのインテリジェントな再ブロードキャスト
・ブロードキャストネットワークを使用しているすべてのアプリケーションにおけるインテリジェントな帯域幅共有（割り当て及び再割り当て）プロセス
・アプリケーションを定義すると共にデータ転送及び帯域幅使用ポリシーを実装するネットワーク事業者制御
・サービス品質（ＱＯＳ）の変化を実装するための優雅でアプリケーションを認識した処理
・順序どおりのイベントの供給を保証するプロセスの実装
【００６８】
同様に、機能の中の１つとして、ブロードキャスト・クライアント・ツールキット（ＢＣＴ）１２０は、次の能力を提供可能である。
【００６９】
・１以上のサーバー側アプリケーションからイベントを受信するためのクライアントアプリケーションの登録の実現
・ブロードキャストネットワークから受信したパケットデータからのイベントの再アセンブリ
・イベントのキャッシングと要求時のイベントの順序どおりの供給
・同一クライアント上において稼動している複数のクライアントアプリケーションに対する同一イベント／データの供給
【００７０】
図２は、本発明のブロードキャスト・サーバー１１０要素の主要な機能要素を示すブロックダイアグラムである。ブロードキャスト・サーバー（ＢＳ）１１０は、一般に、アプリケーションが、データ、コンテンツ、通知などを、ブロードキャストを介してネットワーク１６０上においてユーザーの組に提供できるようにするのに必要な機能を実行する。ネットワークは、別のエンティティによって運営及び／または管理され、このエンティティは、（１）受信者に価値を提供すると共にサービス品質及びその他のサービス標識に関するアプリケーション（またはアプリケーションの所有者／管理者）に対する義務を満足する方式によるデータなどの効率的な供給と、（２）複数のこのようなアプリケーション及び受信者間におけるネットワーク資源の費用効率の優れた効果的な使用法、という少なくとも２つの主要な目的に関心を有することになる。ブロードキャスト・サーバー１１０により、ネットワークエンティティは、アプリケーションにとって基本的にトランスペアレントな方式によってこれらの目的を実現可能であり、この結果、このようなアプリケーションは、ネットワークまたはネットワーク資源を要求しているその他のアプリケーションに関する知識をまったく必要としていないかまたはほとんど必要としていない。
【００７１】
図２に示されているように、ブロードキャスト・サーバー１１０は、通常、複数の機能要素を含んでいる。なお、これらの要素は、図面には、個別のブロックとして示されているが、これらが実行する機能のいくつかまたはすべてをその他のブロックに内蔵することも可能であり、この結果、サーバー内のこのような機能要素の数は増減可能であることに留意する。
【００７２】
ブロードキャスト・サーバー１１０は、ネットワーク資源の割り当て及び共有ポリシーの実装を定義及び支援すべく機能すると共にアプリケーションによる実際の帯域幅（並びに、その他のネットワーク資源）の使用法に関するデータを提供するポリシーマネージャ２１０を含む。ポリシーマネージャ２１０によって定義された１以上のポリシーは、ネットワーク事業者、管理エンティティ、ポリシーマネージャ、または管理機能２１２により、アプリケーション及び／またはネットワークとは無関係にまたはこれとの関連において、生成可能である。
【００７３】
ポリシーマネージャ２１０は、ネットワーク事業者またはその他の管理エンティティに、アプリケーションポリシーを生成及び変更する能力を提供し、このアプリケーションポリシーが、複数のアプリケーション間におけるネットワーク資源の割り当て及び共有を決定する。また、ポリシーマネージャは、履歴的な並びにリアルタイムのアプリケーション資源の使用法について報告することにより、課金、入札またはその他のビジネスモデルに基づいた資源の割り当て、及び将来のポリシーの改良をサポートする。この結果、その他のネットワーク資源の使用法または割り当ての考慮事項とは無関係にまたはこれらとの関連において、これらのポリシーに基づいてリアルタイムでアプリケーションポリシーを変更する能力がネットワーク事業者に提供される。ポリシーマネージャ２１０は、更には、実装されるポリシー及び資源割り当ての決定が、一貫性を有すると共に、帯域幅またはその他の資源の特定の割り当ての結果生成されるものなどの矛盾を生成しないことを保証すべく機能する。一例として、ポリシーマネージャ２１０は、すべてのアプリケーションの最小保証アプリケーション帯域幅の合計が、利用可能であるトータル帯域幅を超過しないことを保証する。
【００７４】
前述のように、アプリケーションポリシーにより、ネットワーク事業者は、複数のアプリケーション間において帯域幅を割り当てる方法を制御可能であり、これらの複数のアプリケーションのそれぞれは、独立した帯域幅要件を具備可能である。１つの機能は、アプリケーションが、アプリケーションのグループに割り当てられた総帯域幅を超過しないことを保証するというものである。更には、ブロードキャスト・サーバー１１０によって実装された帯域幅管理を使用することにより、個別のアプリケーションに対する資源割り当てに関する相対的に繊細なレベルの制御を提供可能である。例えば、ネットワーク事業者は、相対的に大きな帯域幅がアプリケーションにとって利用可能である場合にも、アプリケーションが利用可能な帯域幅の量を制限すべく選択可能である。同様に、事業者は、アプリケーションの帯域幅の使用を制限する代わりに、アプリケーションがその最小帯域幅割り当てを超過することを許容し、これにより、予め合意した取り決め（購入の取り決めの選択肢または優先権など）、擬似リアルタイム入札、またはその他の形態のビジネスモデルに基づいて、使用された追加の帯域幅について課金することも可能である。このような場合には、余剰の利用可能な帯域幅を契約の条項などに従って最高の入札者に割り当て可能である。
【００７５】
また、ネットワーク事業者は、それぞれのアプリケーションの稼動中の帯域幅をリアルタイムで監視可能であり、ポリシーの変化をリアルタイムで効果的に導入可能である。アプリケーションポリシーの変化は、そのポリシーが変更された１以上のアプリケーションのみならず、その他のアプリケーションの利用可能な帯域幅にも影響を及ぼすことになることに留意する。このような場合には、影響を受けたアプリケーションに対して変化について通知可能であり、この結果、それらのアプリケーションは、関連する優先度またはポリシーと一貫性を有する状態において、相応して反応可能である。
【００７６】
ブロードキャスト・サーバー１１０の要素の説明を継続すれば、このサーバーは、セッションマネージャ２４０を更に含む。アプリケーション１３０は、ブロードキャストすべく１以上の関係するイベントを具備する場合には、セッションマネージャ２４０を使用してセッションをセットアップする。アプリケーションの要件、予想資源使用法、及び任意の関連するポリシーに基づいて、セッションマネージャ２４０は、アプリケーションのイベントカルーセル２９０を生成し、カルーセルの帯域幅パラメータを設定している。セッションに割り当てられる初期帯域幅は、例えば、イベントサイズ及び頻度の関数であるが、ネットワーク事業者によってセットアップされたアプリケーションポリシーにより、またはシステムを使用しているその他のアプリケーションの現在の帯域幅使用法により、制約することも可能である。また、セッションマネージャ２４０は、サービス品質（ＱｏＳ）の変化についてアプリケーションに通知すべく機能しており、この結果、これらのアプリケーションは、必要に応じて、影響を受けたデータ及びイベントの供給に対する変化を起動可能である。
【００７７】
ブロードキャスト・サーバー１１０は、インテイク・マネージャ２２０を更に含んでいる。インテイク・マネージャ２２０は、セッションを使用しているアプリケーションのためのインターフェイスを提供する。アプリケーションは、ブロードキャスト対象のデータ／イベントなどをインテイク・マネージャ２２０に伝達する。インテイク・マネージャ２２０は、必要に応じて、イベントを圧縮すべく機能し、ブロードキャスト・サーバー１１０及びブロードキャスト・クライアント・ツールキット１２０によって使用されるように、タイムスタンプ及び連番などのタグをイベントに対して追加可能である。次いで、データ／イベントなどは、適切なアプリケーションカルーセル２９０上に配置されるように、イベント・スケジューラ２３０に伝達される。
【００７８】
また、ブロードキャスト・サーバー１１０は、基礎をなしているブロードキャストネットワークにフィットするパケットにイベントを分割するパケットマネージャ２８０をも含んでいる。使用するブロードキャスト技術に応じて、情報をパケットに付加することにより、ブロードキャスト・クライアント・ツールキットにおける再アセンブルを円滑に実行する必要があろう。パケットマネージャ２８０は、セッション／カルーセルポリシー２６０をチェックすることにより、ブロードキャストの信頼性を向上させるべくＦＥＣ（前進型誤信号訂正）が使用されるかどうかを判断し、要求されている場合には、その機能を提供する。
【００７９】
ブロードキャスト・マネージャ２７０は、パケットマネージャ２８０と通信することにより、パケットを取得する先であるアプリケーションカルーセル２９０について、この要素に通知する。ブロードキャスト・マネージャ２７０は、ブロードキャスト対象のデータパケットをパケットマネージャ２８０から受信し、パケットのブロードキャストネットワーク１６０への送信の責任を担う。ブロードキャスト・マネージャ２７０は、イベント・スケジューラ２３０によってセットアップされたセッション／カルーセルポリシー２６０を使用して送信対象のパケットを決定し、パケットマネージャ２８０に対してそれらのパケットを要求する。
【００８０】
パケットマネージャ２８０は、指定されたカルーセル２９０からイベントを取得し、かつ、パケットを生成してブロードキャスト・マネージャ２７０に付与する。ブロードキャスト・マネージャ２７０は、イベントの全体を取得するのに十分なパケットを要求しない可能性があるため、パケットマネージャ２８０は、通常、同一のカルーセルにおける将来の要求を満足できるように、状態データを維持することになる。この点において、パケットマネージャ２８０は、いくつかの方法の中の１つにおいて動作可能である。パケットマネージャは、要求の前にイベントを分割することにより、準備が完了した状態においてパケットを具備可能である。これには、パケットを要求の時点まで保存する必要があるが、この結果、パケットマネージャは、要求を相対的に迅速に満足可能である。あるいは、この代わりに、パケットマネージャは、必要に応じてパケットを生成することも可能である。
【００８１】
前進型誤信号訂正（ＦＥＣ）及びデータの再送を通じて、イベントの信頼性の向上を実現可能である。ＦＥＣによれば、多少の帯域幅を犠牲にすることにより、特定のイベントが誤りを伴うことなしに受信され、意図されたとおりに使用される尤度が向上することになる。再送によれば、イベントが最初に利用可能となった際にクライアントがブロードキャストを聴取していなかった場合に、イベントを受信可能である。アプリケーションは、そのニーズに応じて、これらの信頼性メカニズムの中の１つまたは両方を利用可能である。例えば、アプリケーションのイベントが、以前のイベントにおいて送信された情報に基づいて構築されている場合には、クライアントにこれらの以前のイベントを確実に受信させることが重要である。この場合には、アプリケーションは、イベントを頻繁に再送することにより、クライアントがすべてのイベントを受信する尤度を向上させるべく選択可能である。
【００８２】
インテイク・マネージャ２２０を使用することにより、ブロードキャスト・サーバーは、アプリケーション要求に応じて、イベントにタグ付け可能である。いくつかのタグは、ブロードキャスト・サーバーによってのみ使用されており、クライアント装置上に存在しているブロードキャスト・クライアント・ツールキットに対してイベントと共にブロードキャストされない。この例は、イベントをカルーセルから除去することを要する時期を通知するタイムスタンプや、イベントがブロードキャストされた回数を規定しているブロードキャストカウントであってよい。その他のタグは、ブロードキャスト・クライアント・ツールキットにおいて使用されるように、イベントと共に包含可能である。この例は、順序どおりの供給を保証すべく使用可能である連番であろう。イベントを送信するアプリケーションにしても、イベントを受信する１以上のアプリケーションにしても、タグについて認識する必要はない。
【００８３】
図３は、本発明のブロードキャスト・クライアント・ツールキット１２０要素の主要な機能要素を示すブロックダイアグラムである。動作においては、クライアント装置１７０上に存在するアプリケーションは、ブロードキャスト・クライアント・ツールキット１２０に登録することにより、自身がイベントを受信すべく利用可能であることをツールキット１２０に通知する。この登録は、クライアントセッションマネージャ３１０を介して実現される。アプリケーションは、登録することにより、１以上の供給源からイベントを受信可能である。重要な機能は、複数のアプリケーションが同一供給源からイベントを受信する能力である。この点において、複数のアプリケーションをサポートするのに必要とされているのは、イベントの１つの複写をブロードキャスト及びキャッシングすることのみである。イベントは、そのイベントを受信すべく登録されたすべてのアプリケーションがその処理を終了。時点まで、維持されている。セッションマネージャ３１０に登録されているアプリケーションに基づいて、特定のアプリケーションポリシー３６０を適用することにより、データをアプリケーションに提供するまたはこれをアプリケーションによって提示する方法に対して影響を与えることができる。このようなポリシー３６０は、例えば、登録されているアプリケーションの優先度方式などを包含可能である。
【００８４】
再アセンブリマネージャ３２０は、ブロードキャストネットワーク１６０からパケットを受信し、これらをオリジナルのイベントに再アセンブルする。再アセンブリマネージャ３２０は、ＦＥＣを使用することにより、イベントを確実に再アセンブル可能である。部分的に再アセンブルされたイベントを一定の期間にわたって保存可能である。イベントが既定の時間量によって完全に再アセンブルされない場合には、そのイベントの一部をイベントキャッシュ３３０から除去可能である。イベントが完全に再アセンブルされた際に、再アセンブルマネージャ３２０は、イベントマネージャ３４０に通知し、この結果、そのイベントを処理可能である。
【００８５】
イベントマネージャ３４０は、受信したイベントを処理することにより、そのイベントをアプリケーションに転送するかどうかを決定する。これは、連番、タイムスタンプ、あるいは、イベントまたはその提供方法を記述しているその他のデータについてイベントタグ情報を調査するステップを伴う。アプリケーションポリシーと共にタグデータを使用することにより、アプリケーションに付与すべくイベントの準備が完了した時期を決定可能である。例えば、順序どおりの供給が要求されている場合には、イベントマネージャは、誤った順序で受信されたイベントを保持し、以前のイベントの転送が完了した際にのみ、これらをアプリケーションに転送することになる。イベントマネージャ３４０は、イベントをアプリケーションに転送する準備が整ったと決定した際には、配布マネージャ３５０に通知することになる。イベントがもはやクライアント装置上のアプリケーションによって必要とされていない際には、イベントマネージャ３４０は、イベントキャッシュ３３０からのイベントの除去を制御することになる。複数のアプリケーションが同一のイベントを受信している可能性があるため、イベントマネージャ３４０は、そのイベントを使用しているそれぞれのアプリケーションのニーズを追跡することにより、そのイベントをキャッシュから除去可能である時期を決定する。
【００８６】
配布マネージャ３５０は、データ／イベントを受信すべく登録したアプリケーション１７０に対してイベントを配布する責任を担う。これは、イベントが利用可能であることをアプリケーションに通知し、アプリケーションがそれを要求した際に、タグデータを伴うことなしに、そのイベントを供給することになる。アプリケーションがイベントの処理を終了した際に、配布マネージャ３５０は、イベントマネージャ３４０に通知しており、この結果、イベントマネージャは、イベントキャッシュ３３０からイベントを除去するかどうかを決定可能である。
【００８７】
全体的なシステムアーキテクチャ並びにブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットの主要な機能に関する以上の説明は、本発明のシステムの要素と機能を紹介すべく提供したものである。要素の動作及びいくつかの機能の実装の更なる詳細について、添付の図面を参照して説明する。
【００８８】
図４は、ブロードキャスト・サーバー要素を通るイベントの代表的なフローを示す図である。同様に、図５は、ブロードキャスト・クライアント・ツールキット要素を通るイベントの代表的なフローを示す図である。以下の説明は、ブロードキャスト・サーバー１１０とブロードキャスト・クライアント・ツールキット１２０の間のイベントのプロセス及びデータフローに関係し、図４及び図５の両方の図の要素を参照している。
【００８９】
典型的な例では、以下の段階やプロセスが含まれる（但し、それぞれのケースにおいて、すべてのものが実行されたり、すべてが図示の順序どおりに実行される必要はない）。
【００９０】
１．サーバー側アプリケーション１３０は、ブロードキャスト・サーバー１１０のセッションマネージャ２４０により、イベントセッションをオープンする（段階４１０）。これを実行する際に、アプリケーション１３０は、その動作における所望のサービス品質（ＱｏＳ）レベルを規定可能である。セッションマネージャ２４０は、ＱｏＳ要件を検証してそれらを満足可能（適用可能）であることを確認し、イベントカルーセル及び初期セッションポリシーを生成すると共に、必要に応じてその他のセッションに割り当てられた帯域幅を調節して新しいセッションの帯域幅を割り当てる（段階４１２）。
【００９１】
２．クライアント側アプリケーション１７０は、ブロードキャスト・クライアント・ツールキット１２０のセッションマネージャ３１０に登録することにより、自身がサーバー側アプリケーション１３０からイベントを受信することを所望することを通知する（段階５１０）。
【００９２】
３．サーバー側アプリケーション１３０は、ブロードキャスト・サーバー１１０のインテイク・マネージャ２２０にイベント／データを発行する（段階４２０）。
【００９３】
４．インテイク・マネージャ２２０は、（必要に応じて）連番によってイベント／データにタグ付けし、そのイベントをイベント・スケジューラ２３０に伝達する（段階４３０）。
【００９４】
５．イベント・スケジューラ２３０は、イベント／データをアプリケーションのカルーセル２９０上に配置し、そのイベント／データ及びブロードキャストすべく既にスケジュールされているその他のイベントの優先度に基づいて、そのアプリケーションないしその他のアプリケーションの帯域幅割り当てを変更可能である（段階４４０）。
【００９５】
６．パケットマネージャ２８０は、ブロードキャストネットワーク１６０にフィットするパケット４４５にイベント／データを分割し、かつ、セッションポリシー２６０内に規定されている場合にＦＥＣを付加する（段階４５０）。
【００９６】
７．ブロードキャスト・マネージャ２７０は、セッションポリシー２６０を使用することにより、イベントのパケットをネットワーク１６０上においてブロードキャストする時期を決定する（段階４６０）。
【００９７】
８．ブロードキャスト・クライアント・ツールキットの再アセンブリマネージャ３２０は、ブロードキャストネットワーク１６０からパケット５１２を受信し、ＦＥＣが存在している場合にはＦＥＣを使用してイベントを再アセンブルすると共に、部分的に受信したイベントをイベントキャッシュ３３０内に保存する（段階５２０）。
【００９８】
９．イベントのすべてのパケットが受信されたら、再アセンブリマネージャ３２０は、イベントマネージャ３４０に通知する（段階５３０）。
【００９９】
１０．イベントマネージャ３４０は、イベントの連番タグを検査し、それをサーバー側アプリケーション１３０のイベントを受信すべく登録されているアプリケーションに供給可能であるかどうかを決定する（段階５４０）。
【０１００】
１１．順序どおりのイベントの並びが必要とされており、かつ、クライアント側アプリケーション１７０がすべての以前のイベントを受信している場合には、イベントマネージャ３４０は、イベントをクライアント側アプリケーション１７０に供給可能であることを配布マネージャ３５０に通知する。
【０１０１】
１２．配布マネージャ３５０は、イベントタグを除去し、イベントをクライアント側アプリケーション１７０（並びに、それらのイベントを受信すべく登録されているその他のアプリケーション）に供給している（段階５５０）。
【０１０２】
１３．クライアント側アプリケーション１７０（並びに、そのイベントを受信すべく登録されているすべてのその他のアプリケーション）がイベントの処理を終了したら、イベントマネージャ３４０は、イベントキャッシュ３３０からイベントを削除し、これにより、イベントの寿命を終了させる。
【０１０３】
アプリケーション要件は、例えば、イベントの所望のレイテンシー、信頼性、圧縮、及びリンガー時間を包含可能であることに留意する。アプリケーションは、これらのパラメータを明示的に規定することも可能であり、あるいは、イベントストリーム、通知サービス、またはデータオブジェクトカルーセルなどの特定のタイプのデータ供給モードを所望していることを通知するなどのように、一般的な表現で規定することも可能である。イベントストリームサービスによれば、アプリケーションは、イベントの連続したストリームを多数のクライアントに対して送信可能である。代表的なイベントストリームアプリケーションは、株価表示器及びスポーツの得点を含んでいる。このような場合には、アプリケーションは、ブロードキャストカルーセル上に残っているイベントの数及び／または新しいイベントの所望のレイテンシーを規定可能である。ブロードキャストされるイベントのタイプによっては、多数回にわたるイベントの再ブロードキャストが重要ではない場合があることに留意する。この場合には、カルーセルが相対的に小さく維持されることになるため、１以上のイベントを相対的に迅速に配布可能である。その他のアプリケーションの場合には、新しいイベントをブロードキャストするのに相対的に長い時間を所要することを意味している場合にも、多数のイベントが常にクライアントに対して提供可能である状態になっていることを保証することが重要であろう。このような場合には、カルーセルは、相対的に多くのアイテムを含むことになり、この結果、特定のイベントのレイテンシーが相対的に大きなものになろう。イベントストリームサービスにとって通常重要であるサービス品質パラメータには、平均イベントサイズ及び頻度と、所望のイベントレイテンシー及びリンガー時間が含まれる。
【０１０４】
データ供給の別のモードは、通知サービスのモードであり、これによれば、アプリケーションは、豊富な通知（例えば、通知は、ビデオクリップを包含可能であろう）を多数のクライアントに対して不定期に送信可能である。このイベントストリームの平均的な帯域幅の使用量は、小さなものになるが、通知をタイムリーに供給するためには、その他のアプリケーションの帯域幅を優先使用することが重要であろう。このようなサービスを利用可能であるアプリケーションの例には、緊急事態の通知、ニュース速報、及び天気予報が含まれる。通知サービスにとって通常重要であるサービス品質パラメータは、通知を供給するための最大通知サイズ、所望のレイテンシー、及び最大レイテンシーである。
【０１０５】
第３のデータ供給モードは、データオブジェクト供給サービスのモードであり、これによれば、アプリケーションは、クライアントによる「バックグランド」受信のためにデータオブジェクトをカルーセルに追加またはこれから除去可能である。これらのオブジェクトは、クライアント装置上にファイルとして保存可能であり、あるいは、受信アプリケーションによって直接的に使用することも可能である。このようなサービスを利用可能なアプリケーションの例には、スポーツアプリケーションにおけるハイライトクリップが含まれる。データオブジェクト供給サービスにとって通常重要であるサービス品質パラメータは、平均オブジェクトサイズ、カルーセル上に含まれるオブジェクトの平均数、及び所望のオブジェクトレイテンシーを含んでいる。
【０１０６】
それぞれのアプリケーションは、いくつかのデータキャストセッションを要求可能であり、またはこれと関連付け可能であることに留意する。アプリケーションセッションに割り当てられた帯域幅は、次のものを含むいくつかの要因に基づいて変化可能である。
【０１０７】
・そのセッションのためにアプリケーションが要求したＱｏＳ
・セッションの優先度
・セッションの現在の活動レベル
・アプリケーションによって定義されたその他のセッションの活動
・同一グループ内のその他のアプリケーションのセッションの活動
・事業者ポリシー
【０１０８】
前述のように、新しいアプリケーションセッションがセットアップされた際には、その他のアプリケーションのセッションに割り当てられた帯域幅に影響が及ぶ可能性がある。この可能性に対処すべく、アプリケーションは、セッションをセットアップする際にコールバックを提供可能であり、この結果、セッションの割り当て帯域幅の変化をアプリケーションに伝達可能である。次いで、アプリケーションは、この通知に基づいてその動作を変更すべく選択可能である。あるいは、この代わりに、アプリケーションは、セッションの割り当て帯域幅が変化した際にブロードキャスト・サーバー１１０が遵守することになるポリシーをセットアップすることも可能である。
【０１０９】
アプリケーションポリシー２５０は、ブロードキャストネットワークを使用すべく許容されているアプリケーションと、その許容された使用法を規定する。これは、アプリケーションのグループにとって利用可能であるトータル帯域幅を定義するステップを含んでいる。更には、特定のアプリケーションに割り当てられている帯域幅に関する任意の制限をこれらのポリシーによって定義することも可能である。アプリケーションポリシー２５０は、例えば、時刻に基づいて、または現在アクティブであるその他のアプリケーションに基づいて、異なる優先度、帯域幅範囲、または割り当てを規定可能である。
【０１１０】
一例として、３つの異なる相対的な優先度レベルにおいて定義されたアプリケーションのための次のシナリオを検討する。この例においては、システム全体の総帯域幅は、１００Ｋｂ／秒である。最大許容可能帯域幅は定義されてはおらず、これは、これらがすべて１００Ｋｂ／秒を既定値としていることを意味している。
【０１１１】
【表１】
2009525641.tif 000003
【０１１２】
ポリシーマネージャ２１０の重要な機能は、アプリケーション帯域幅ポリシーの中のいずれか１つが遵守されないという状況が生じる可能性なしに、事業者やその他のいかなる団体によって規定されたアプリケーションポリシーであっても、共存することを保証することにあるということに留意する。後程更に詳述するこの共存を保証している２つの制約には、次のものが含まれる。
【０１１３】
・システム（グループ）内に存在するものとして定義されたすべてのアプリケーションの最小保証帯域幅の合計は、システム（グループ）にとって利用可能である総帯域幅を超過することはできない。
【０１１４】
・特定の優先度レベルにおけるすべてのアプリケーションの予想帯域幅の合計と更に低い優先度を有するすべてのアプリケーションの保証最小帯域幅の合計を加算したものは、システム（グループ）にとって利用可能である総帯域幅を超過することはできない。
【０１１５】
先程定義した例示用のアプリケーション帯域幅ポリシーの場合には、これらの両方の考慮事項が遵守されている。第１に、最小保証帯域幅の合計である１００Ｋｂ／ｓは、システム用に定義されている総帯域幅を超過していない（こちらも、１００Ｋｂ／ｓである）。第２に、１つの優先度レベルにおける予想帯域幅の合計とすべての更に低い優先度レベルにおける保証帯域幅の合計を加算したものは、総帯域幅を超過していない。最低優先度のアイテムを調査すれば、予想帯域幅の合計である３０Ｋｂ／ｓは、総帯域幅を十分に下回っている。中間優先度のアイテムを調べれば、予想帯域幅の合計である５０Ｋｂ／ｓと最低優先度の保証最小帯域幅の合計である４Ｋｂ／ｓを加算したものは、１００Ｋｂ／ｓの総帯域幅未満に留まっている。最後に、最高優先度の予想帯域幅の合計である９０Ｋｂ／ｓと低い及び中間優先度の帯域幅の合計である１０Ｋｂ／ｓを加算したものは、１００Ｋｂ／ｓの総帯域幅を超過していない。
【０１１６】
ネットワーク事業者は、中間優先度アプリケーションの予想帯域幅を増大可能であろう。しかしながら、これらの帯域幅の合計は、最大で、１００Ｋｂ／ｓから低優先度アプリケーションの保証最小帯域幅の合計である４Ｋｂ／ｓを減算したもの、即ち、９６Ｋｂ／ｓとなるであろう。この理由は、これを上回る割り当ては、ポリシーにおける矛盾を生成することになるためである。
【０１１７】
アプリケーションポリシーは、この例よりも更に複雑なものにすることも可能であることに留意する。例えば、日時が要因となろう。この点において、株価表示器アプリケーションは、取引時間内においては、相対的に大きな帯域幅を必要とすることになろう。野球の実況アプリケーションは、野球の試合が進行中である際にのみ帯域幅を必要とすることになろう。交通警報アプリケーションは、ラッシュアワー以外においては、あまり高い優先度の帯域幅を取得しないであろう。これらの場合には、それぞれのアプリケーションポリシーが有効な状態に留まっているそれぞれの期間について、アプリケーションの帯域幅制約をチェックする必要があろう。
【０１１８】
また、アプリケーションレベルのポリシーに加えて、本発明のシステムは、セッションレベルのポリシーを実装することも可能である。セッションポリシーとは、セッションポリシー２６０によって示されているように、それぞれのアプリケーションセッションにおいて有効なポリシーを意味している。このようなポリシーは、事業者によって設定された様々な帯域幅限度、カルーセルに割り振られた現在の割り当て帯域幅、順序どおりの供給、圧縮、及びＦＥＣなどの選択肢のためのアプリケーションのセッションパラメータ、並びに、割り当てられた帯域幅の変化をブロードキャスト・サーバー１１０に自動的に処理させるべくアプリケーションによってセットアップされた任意のＱｏＳポリシーを包含可能である。割り当て帯域幅が、ネットワークのトラフィック状態の変化に応じて頻繁に変化可能であるため、このようなＱｏＳポリシーが必要となる。そして、これらの変化は、アプリケーションセッションが経験するＱｏＳに影響する可能性があり、この結果、アプリケーションは、割り当て帯域幅の減少（または、増大）に応答すべく実施する自動アクションを規定することを望む。
【０１１９】
イベント・スケジューラ２３０は、カルーセルポリシーを管理し、イベントをネットワーク上においてブロードキャストする順序が決定される。それぞれのアプリケーションに割り当てられる帯域幅は、動的なものであり、かつ、システムに追加されるそれぞれのイベントと共に変化可能である。アプリケーションが、自身に割り当てられたすべての帯域幅を使用していない場合には、イベント・スケジューラ２３０は、未使用の帯域幅をその他のアプリケーションに割り当て可能である。イベント・スケジューラ２３０は、アプリケーションポリシーと、ネットワーク帯域幅の使用法に関する現在のトラフィックパターンと、を使用することにより、システム全体の帯域幅を最適に割り当てる。この意味において、イベント・スケジューラ２３０は、それぞれのカルーセルまたはネットワーク上においてブロードキャストされるイベントの組の優先度を動的に決定すべく動作する。これは、システム要件及びイベントの優先度に基づいてそれぞれのカルーセルにイベントを配置（即ち、順序付けるかまたは最初に配置）したり、これから除去すべく機能する。また、これは、現在のトラフィックパターンに基づいてセッションポリシーを更新すべく動作する。
【０１２０】
一般的に、アプリケーションは、最大で、「予想帯域幅」と呼ばれるものまで使用可能である。但し、同一ブロードキャスト資源を共有しているその他のアプリケーションが、アイドル状態にあるか、またはそれらの割り当て帯域幅を十分に利用していない場合には、その予想帯域幅を上回るものをアプリケーションに割り当て可能である。共有されている１００Ｋｂ／ｓの資源の例を使用し、高優先度アプリケーションがアイドル状態にあるとしよう。
【０１２１】
【表２】
2009525641.tif 000004
【０１２２】
すべての中間及び低優先度アプリケーションがブロードキャスト対象のイベントを持っており、それらの予想帯域幅を使用している場合にも、１００Ｋｂ／ｓの中の８０Ｋｂ／ｓのみが使用されることになる。この結果、余剰の帯域幅を様々な方法によって割り当て可能である。例えば、余剰の帯域幅は、アクティブなアプリケーションに対して均等に割り当て可能であろう。アプリケーションがその利用可能なすべての帯域幅を使用することになると仮定した場合には、余剰の２０Ｋｂ／ｓは、４つのアプリケーション間において等しく分割され、この結果、それぞれのアプリケーションは、追加の５Ｋｂ／ｓを取得することになろう。
【０１２３】
【表３】
2009525641.tif 000005
【０１２４】
余剰の帯域幅を割り当てるための別の方法は、アプリケーションに定義されている予想帯域幅に比例した量をそれぞれのアプリケーションに付与するというものであろう。例えば、別のアプリケーションと比べて２倍の予想帯域幅を有するアプリケーションは、その他のアプリケーションが利用可能である余剰の帯域幅の２倍を取得することになる。この方法をこの例に使用すれば、予想帯域幅の合計は、８０Ｋｂ／ｓであって、余剰の帯域幅は、２０Ｋｂ／ｓであることから、これは、それぞれのアプリケーションに、次式を使用して帯域幅が割り当てることになることを意味している。
【０１２５】
割り当て帯域幅＝予想帯域幅＋（予想帯域幅＊２０／８０）
【０１２６】
この結果、次の割り当てが得られることになろう。
【０１２７】
【表４】
2009525641.tif 000006
【０１２８】
いくつかのアプリケーションは、その最低レベルを上回る帯域幅に対するニーズを具備していない場合があり、あるいは、事業者が、アプリケーションが使用可能な最大帯域幅を課している場合がある。この場合には、対象のアプリケーションに追加の帯域幅を割り当て不可能であるか、あるいは、さもなければ割り当てられたであろうものよりも小さな量の帯域幅のみが割り当てられることになろう。そして、残りのものを残りのアプリケーション間において分割可能である。
【０１２９】
次に、低い及び中間優先度アプリケーションがその割り当て帯域幅を使用している以前の例を検討しよう。高優先度の交通警報アプリケーションが、ブロードキャストすべくイベントを送信する場合には、これに４０Ｋｂ／ｓが割り当てられることになる。残りの６０Ｋｂ／ｓは、中間及び低優先度アプリケーションに割り当てられることになる。この場合にも、１００Ｋｂ／ｓの総帯域幅を超過することにならないため、中間優先度アプリケーションは、依然として、合計が５０Ｋｂ／ｓであるそのそれぞれの予想帯域幅に対するアクセスを有することになる。この結果、残りの１０Ｋｂ／ｓが、低優先度アプリケーションに割り当てられることになる。これらは、合計３０Ｋｂ／ｓであるその個々の予想帯域幅に対するアクセスを有することにはならない。ネットワーク事業者が、同一優先度におけるアプリケーションの帯域幅は、予想帯域幅に比例して割り当てられると規定している場合には、天気アプリケーションは、１０Ｋｂ／ｓの２／３を取得することになり、ヘッドラインニュースアプリケーションは、１０Ｋｂ／ｓの１／３を取得することになる。この結果、次の帯域幅割り当てが得られることになる。
【０１３０】
【表５】
2009525641.tif 000007
【０１３１】
交通警報アプリケーションがイベントを送信する代わりに、国土安全保障省アプリケーションがイベントを送信するケースを更に検討する。これには、５０Ｋｂ／ｓが割り当てられることになる。残りの５０Ｋｂ／ｓは、中間及び低優先度アプリケーションに割り当てられることなる。中間優先度アプリケーションが、その個々の予想帯域幅（合計で５０Ｋｂ／ｓである）に対するアクセスを得た場合には、低優先度アプリケーションには、なにも残らなくなるであろう。低優先度アプリケーションには、最低でそれぞれ２Ｋｂ／ｓが保証されているため、これらは、合計で、４Ｋｂ／ｓを下回らないものを取得しなければならない。その保証されているそれぞれ２Ｋｂ／ｓの最小量がそれぞれに付与された場合には、残りの４６Ｋｂ／ｓを中間優先度アプリケーションに割り当て可能である。ネットワーク事業者が、同一優先度におけるアプリケーションの帯域幅は、予想帯域幅に比例して割り当てられると規定している場合には、株価表示器アプリケーションは、４６Ｋｂ／ｓの２／５を取得することになり、野球の実況アプリケーションは、４６Ｋｂ／ｓの３／５を取得することになる。この結果、次の帯域幅割り当てが得られることになる。
【０１３２】
【表６】
2009525641.tif 000008
【０１３３】
相対的に高い優先度のイベントに起因し、その他のアプリケーションに割り当てられる帯域幅の減少が発生する際には、イベント・スケジューラ２３０は、そのイベントのブロードキャストが完了する時期を決定するのに十分な情報を有していることに留意する。イベントのブロードキャスト時間は、イベントのサイズと、イベントのアプリケーションセッションに割り当てられた帯域幅に依存することになる。このイベントは、帯域幅の優先使用が不可能であるため、割り当て帯域幅は、このイベントのブロードキャストの持続時間にわたって有効な状態に留まる必要がある。イベント・スケジューラ２３０は、高優先度イベントのブロードキャスト持続時間に関する知識を使用することにより、その他のアプリケーションに提供されているサービス品質（ＱｏＳ）を低下させる方法に対して影響を及ぼすか、あるいは、その情報をその他のアプリケーションに提供可能であり、この結果、それらのアプリケーションは、割り当て帯域幅の減少を処理すべくその独自の戦略に基づいて決定を下すことができる。なお、このような場合には、帯域幅の再割り当てに関するこのような予測は、その時点のものに過ぎないことに留意する。別の高優先度イベントが、その最初のものがブロードキャストを完了させる前に到来した場合には、オリジナルの予測は、不正確なものとなる。但し、高優先度イベントは、頻繁には発生しないものと予想されることから、予測は、多くの場合に信頼性が高く、従って、時折、不正確になるのみであろう。
【０１３４】
（セッションポリシー）
セッションマネージャ２４０及びセッションポリシー２６０の検討を参照して説明したように、本発明のシステムは、アプリケーションレベルにおいて実装されるものに加えて、セションレベルにおいてポリシーを実装する能力をも有している。セッションポリシーとは、それぞれのアプリケーションセッションにおいて有効であるポリシーを意味している。セッションポリシーは、事業者によって設定された様々な帯域幅限度、カルーセルに割り振られた現在の割り当て帯域幅、順序どおりの供給、圧縮、またはＦＥＣなどの選択肢のためのアプリケーションのセッションパラメータ、及びブロードキャスト・サーバーがサービス品質の変化を自動的に処理できるようにすべくアプリケーションが定義または要求したポリシーを包含可能である。ブロードキャスト・マネージャは、セッションの割り当て帯域幅を使用することにより、それぞれのアプリケーションのカルーセルからパケットを取得するレートを決定している。ネットワーク上におけるブロードキャストのためのそれぞれのカルーセルにおけるイベントのパケットへの分割は、パケットマネージャによって実行される。
【０１３５】
単一のアプリケーションが複数のブロードキャストセッションのセットアップを要求しかつこれに参加可能である。この結果、異なる優先度によってブロードキャストされる異なるタイプのイベントを送信する能力がアプリケーションに付与されている。ブロードキャスト・サーバー１１０は、アプリケーションの優先度付けを処理する。アプリケーションは、アプリケーションポリシー内においてそのアプリケーションに定義されているものを上回る優先度をセッションに付与することはできないという制限の下に、セッションの優先度を規定する。一例として、ネットワーク事業者によって定義された次に示されているアプリケーションポリシーを有する株価表示器アプリケーションを検討する。
【０１３６】
【表７】
2009525641.tif 000009
【０１３７】
株価表示器アプリケーションは、リアルタイム株価情報用のものと、履歴株価情報用のものという２つのブロードキャストセッションを有することができる。株価表示器は、次の特性を有する２つのセッションを要求可能であろう。
【０１３８】
【表８】
2009525641.tif 000010
【０１３９】
セッションマネージャ２４０の重要な機能の１つは、アプリケーションによって定義されたセッションが、事業者によって定義されたアプリケーションポリシーを遵守していることを保証することにあることに留意する。これには、アプリケーションが認可されているものよりも高い優先度によってアプリケーションがセッションを定義することを防止することのみならず、アプリケーションポリシーに規定されている制約との関係における帯域幅要求に関するポリシーも含まれる。後程詳述する２つのこのようなポリシーには、次のものが含まれる。
【０１４０】
・すべてのセッションの最低保証帯域幅の合計は、アプリケーションポリシー内に定義されている最小保証帯域幅を超過することができない。
【０１４１】
・特定の優先度レベルにおけるすべてのセッションの予想帯域幅の合計と更に低い優先度を有するすべてのセッションの最小保証帯域幅の合計を加算したものは、アプリケーションポリシーに定義されている予想帯域幅を超過することができない。
【０１４２】
前述の例において付与された要求によれば、これらのセッション帯域幅制約が満足されていることに留意する。最小保証帯域幅の合計は、アプリケーションの最小保証帯域幅以下になっている。また、中間優先度セッションの予想帯域幅の合計と低優先度セッションの保証最小帯域幅を加算したものは、アプリケーションの予想帯域幅を超過してはいない。アプリケーションが中間優先度セッションの予想帯域幅を２０Ｋｂ／ｓに増大させることを試みた場合には、この制約に違反することになる。アプリケーションが、このような変化のサポートの実現を所望した場合には、低優先度セッションの保証最小帯域幅を次のように０Ｋｂ／ｓに低減可能であろう。
【０１４３】
【表９】
2009525641.tif 000011
【０１４４】
異なる優先度の複数のアプリケーションが同一の優先度を具備したセッションを定義する場合があり、この結果、これらのセッションは、同一の帯域幅資源について競合することになる。このような状況においては、これらのセッションは、技術的には同一の優先度を具備しているものの、個々のアプリケーションの優先度を使用することにより、相対的に大きな帯域幅をそれらの中の１つのものに割り当てることになる。これは、予想帯域幅ポリシーを実施するために必要である。一例として、次の内容を検討する。
【０１４５】
【表１０】
2009525641.tif 000012
【０１４６】
ヘッドラインニュースアプリケーション用の１つのものと、株価表示器アプリケーション用の２つのものという次の３つのセッションがセットアップされていると仮定する。
【０１４７】
【表１１】
2009525641.tif 000013
【０１４８】
帯域幅割り当ての際に、中間優先度セッションが、１８Ｋｂ／ｓのその予想帯域幅を取得すると共に、割り当てるべく８Ｋｂ／ｓが残っている場合には、株価表示器の低優先度セッションには、その予想量のすべてが付与されることになり、ヘッドラインニュースセッションは、残りのものを受け取ることになる。
【０１４９】
【表１２】
2009525641.tif 000014
【０１５０】
株価表示器の低優先度セッションは、ヘッドラインニュースセッションと同一の優先度を有してはいるが、その親アプリケーションの優先度が、ヘッドラインニュースの優先度を上回っているため、帯域幅割り当ては、このように実行される。実際に、これは、ヘッドラインニュースセッションの帯域幅を優先使用する。
【０１５１】
アプリケーションは、セッション間におけるイベントの移動を要求可能である。例えば、高優先度イベントを短期間において頻繁に再ブロードキャストし、次いで、この後に、更に低速で反復させるべく更に低い優先度に降格させる場合がある。イベント・スケジューラ２３０は、これらの要求の実装をも処理する。
【０１５２】
（帯域幅及びネットワーク資源の割り当て）
以上の説明から明らかなように、帯域幅管理（例えば、割り当て及び再割り当て）は、ブロードキャスト・サーバー１１０が提供している最も重要な機能の１つである。これは、複数のアプリケーションが効率的に同一のブロードキャスト資源を共有可能であるというこの管理機能に起因したものである。この意味において、帯域幅管理の１つの目的は、共有されたブロードキャスト資源を使用しているすべてのアプリケーションに最良のサービス品質を提供することにある。
【０１５３】
ネットワーク事業者は、通常、使用可能なブロードキャスト媒体の一部を割り当てており、またはネットワーク事業者には、これが提供されている。任意の時点におけるすべてのアプリケーションの帯域幅使用量の合計は、この量を超過不可能であるため、これを総帯域幅と呼んでいる。ブロードキャスト・サーバー１１０は、割り当てられた総帯域幅を超過してイベントをブロードキャストネットワーク１６０上において伝送することがないように機能しており、この場合に、ネットワーク事業者は、ポリシーマネージャ２１０を使用することにより、この値を定義する。
【０１５４】
ネットワーク事業者は、アプリケーションのグループを定義可能であり、この場合に、それぞれのグループには、データチャネルが付与されており、このデータチャネルは、ネットワーク事業者が利用可能であった帯域幅資源の一部である。それぞれのアプリケーショングループには、通常、その独自の定義された総帯域幅が割り振られることになり、すべてのグループの総帯域幅の合計は、利用可能なトータル資源を超過することはできない。このような場合には、通常、任意の帯域幅の規則または制約が、それぞれのグループに個別に適用されることになろう。グループを定義することに伴う利益の１つは、この結果、ネットワーク事業者は、特定のアプリケーションをその他のものから分離すると共に、規則の組をそれらの規則が最も関係しているグループに対して適用可能であるという点にある。この結果、同一の帯域幅資源を共有している際にアプリケーションが互いに影響しあう方法に対する更なる制御がネットワーク事業者に付与されることになる。但し、グループの定義は、ネットワーク事業者が利用可能なトータル帯域幅資源の共有という観点においては、相対的に低い効率をもたらす可能性があることに留意する。この理由は、通常、グループ間において別のグループの未使用帯域幅を利用することができないためである。
【０１５５】
アプリケーションに割り当てられた帯域幅は、動的であると共に、その他のアプリケーションの活動に基づいて変化可能である。但し、大部分の種類のアプリケーションは、かなり一定の帯域幅要件を具備している。これらは、利用可能である際には、追加の帯域幅を利用可能であるが、通常の状況においては、その帯域幅消費量は、相対的に予測可能なレベルに固定されている。
【０１５６】
但し、あまり予測可能ではない帯域幅要件を有する種類のアプリケーションも存在している。１つの例が、警報通知サービスである。警報は、予測不能な時点において発生し、通常は、その他のアプリケーションよりも高い優先度が付与されている。大部分の時点において、警報通知サービスは、アイドル状態にあり、かつ、大きな帯域幅資源を使用してはいない。このような場合には、その帯域幅が頻繁に未使用状態に留まることになるため、帯域幅をこのようなアプリケーションに専用とすることは、帯域幅資源の効率的な使用法にならないであろう。しかしながら、警報が発生した際には、そのイベントは、その他の相対的に低い優先度アプリケーションによる活動の帯域幅を優先使用することになる。このような際には、その他のアプリケーションが利用可能である帯域幅が大幅に減少可能である。この減少により、そのアプリケーションのサービス品質が、許容可能なまたは望ましいレベルを下回るところまで低下する可能性がある。このような状況においても、アプリケーションは、帯域幅に対する飢餓状態とはならず、その代わりに、このような変化に反応するための機会が提供されることになる。警報通知のブロードキャストが完了した後には、帯域幅をシステム内のその他のアプリケーションに返すことが可能であるため、これらの減少は、通常、持続時間が限られていることに留意する。
【０１５７】
アプリケーションの様々なタイプの特性に起因し、本発明によれば、それぞれのアプリケーションごとに、いくつかの帯域幅閾値、制約、値、または関係を定義可能である。ポリシーマネージャ２１０により、ネットワーク事業者は、これらの閾値または値を規定可能であり、かつ、これらは、必要に応じて変更可能である。詳述するように、ブロードキャスト・サーバー１００は、特定の規定された規則または関係に従って、これらの閾値または値を適用すべく機能しており、かつ、閾値または値が変化した際には、アプリケーションに通知する。
【０１５８】
第１の閾値、制約、値などは、アプリケーションにとって利用可能である保証最小帯域幅と呼ばれる。これは、その他の相対的に高い優先度トラフィックがシステム内に存在している場合にも、その独自の使用のために保証最小帯域幅を下回るものがアプリケーションに付与されないように割り当てられる帯域幅として定義される。この閾値の値は、アプリケーションが所望のサービス品質レベルを提供するには低過ぎる可能性があるが、アプリケーションは、長期間にわたってこのレベルにおいて稼動する必要はないと想定可能であることに留意する。ネットワーク事業者は、帯域幅を割り当てる際には、同時に稼動可能であるすべてのアプリケーションの合計が総帯域幅を超過しないように保証最小帯域幅を定義する必要がある。この理由は、さもなければ、ブロードキャスト・サーバーが１以上のアプリケーションの最小帯域幅保証に違反することになるためである。これを防止すべく、ポリシーマネージャ２１０が、この制約を適用しており、これにより、このような違反を生成可能なポリシーが定義されることを許容しないようにする。
【０１５９】
第２の帯域幅閾値は、予想帯域幅と呼ばれる。これは、相対的に高い優先度アプリケーションがその帯域幅の使用を必要としていない限り、アプリケーションに対して保証された帯域幅である。システム内において稼動しているすべてのアプリケーションが同一の優先度を具備している場合には、アプリケーションにとって、常に、予想帯域幅が利用可能となる。システム内のその他のトラフィックに応じて、アプリケーションに予想帯域幅よりも大きな帯域幅を付与または提供することは可能であるが、アプリケーションは、通常は、このレベルにおいて稼動する必要があろう。これは、アプリケーションが、正常な動作状態において期待可能である帯域幅のベースレベルであるため、アプリケーションが、予想帯域幅を上回る帯域幅を必要とするセッションを開始することは許容されていない。
【０１６０】
特定の優先度レベルの予想帯域幅の合計にすべての更に低い優先度のアプリケーションの保証最小帯域幅の合計を加算したものは、総帯域幅を超過することができないことに留意する。さもなければ、ブロードキャスト・サーバーが、相対的に低い優先度アプリケーションの最小保証帯域幅を遵守することができないか、または相対的に高い優先度のアプリケーションの予想帯域幅を遵守することができないという状況を生成可能であろう。この場合にも、ポリシーマネージャ２１０が、この状況を引き起こすポリシーまたはポリシーの組をネットワーク事業者が適用することを許容してはいない。
【０１６１】
最高の優先度において定義されたアプリケーションの場合には、予想帯域幅は、保証最小帯域幅と等しくなければならないことに留意する。これは、これらが最高の優先度レベルにあるため、これらの帯域幅を優先使用可能であるアプリケーションは存在していないという事実に起因している。
【０１６２】
使用可能である別の帯域幅閾値は、最大許容可能帯域幅と呼ばれる。これは、特定レベルの帯域幅使用量を超過することを防止すべく、ネットワーク事業者が、アプリケーションに対して課すことができる任意選択の限度である。このような状況においては、相対的に大きな帯域幅が利用可能である場合にも、アプリケーションは、それを使用することが許容されなくなる。事業者が、アプリケーションに最大許容可能帯域幅を設定しないことを選択した場合には、既定値は、総帯域幅である。
【０１６３】
これらの帯域幅閾値または値の観点において、帯域幅の割り当て方法及びプロセスの動作を特徴付ける特定の関係を導出可能であることに留意する。以下においては、アプリケーショングループにとって利用可能であるトータル帯域幅が、ブロードキャストネットワーク事業者によって提供されており、ブロードキャスト・サーバー上においてアプリケーションを構成する際に、これが事業者によって使用されている。１以上のアプリケーションのグループに割り当てられた帯域幅の観点において、次のように定義可能である。
【０１６４】
【数１】
2009525641.tif 000015
【０１６５】
：アプリケーションまたはアプリケーションのグループに割り振られたデータチャネルのトータル帯域幅
【０１６６】
グループ内のすべてのアプリケーションのすべてのセッションによる任意の瞬間のトータル帯域幅使用量は、
【０１６７】
【数２】
2009525641.tif 000016
【０１６８】
を超過できないことに留意する。
【０１６９】
アプリケーションごとにネットワーク事業者によって規定されたものとして、前述の帯域幅閾値に基づいて以下のシンボルを定義しよう。
【０１７０】
Ａ：グループ内のアプリケーションの組
【０１７１】
【数３】
2009525641.tif 000017
【０１７２】
：アプリケーションａにとって利用可能である保証最小帯域幅
【０１７３】
【数４】
2009525641.tif 000018
【０１７４】
：アプリケーションａにとって利用可能である予想帯域幅
【０１７５】
【数５】
2009525641.tif 000019
【０１７６】
：アプリケーションａにとって利用可能である最大許容可能帯域幅
【０１７７】
Ｐ：優先度レベルの組
【０１７８】
【数６】
2009525641.tif 000020
【０１７９】
：アプリケーションａ内のセッションの最高優先度
【０１８０】
以下の関係が成立していることに留意する。
【０１８１】
【数７】
2009525641.tif 000021
【０１８２】
これらの定義及び関係と関連する制約の観点において、それぞれの優先度レベルにおいて、アプリケーションは、その帯域幅が優先使用されていない際には、更に低い優先度のアプリケーションの帯域幅を優先使用してでも、その予想帯域幅において稼動可能でなければならないことに留意する。即ち、次式に示されているように、所与の優先度値を有するすべてのアプリケーションを稼動させることに加えて（すべてのそれらの予想帯域幅がその優先度において使用されていると仮定した場合に）、すべての更に低い優先度アプリケーションをその保証最小帯域幅において稼動させることが可能でなければならない。
【０１８３】
【数８】
2009525641.tif 000022
【０１８４】
（セッションの帯域幅制約）
アプリケーションのグループを参照して説明した帯域幅の制約に加えて、ブロードキャストセッションに適用される帯域幅の制約及び関係も存在する。代表的な例においては、アプリケーションは、セッションが要求された時点において、所望のサービス品質レベルを含むセッションパラメータを提供することになり、次いで、これらのパラメータを、ＱｏＳ管理の検討を参照して説明するように、有効帯域幅に変換可能である。
【０１８５】
定義：
Ｓ：セッションの組
Ｓa：アプリケーションａ∈Ａに属するセッションのサブセット
【０１８６】
それぞれのセッションには、次の資源（即ち、帯域幅）パラメータを割り振り可能であり、これらのパラメータは、付与されるか、またはＱｏＳパラメータから導出されている。
【０１８７】
Ｍs：セッションｓの保証最小帯域幅
Ｅs：セッションｓの予想帯域幅
ｐs：セッションｓの優先度
【０１８８】
動作の際には、アプリケーションは、セッションを生成または除去可能であり、あるいは、セッションのパラメータを変更可能である。Ｍ、Ｅ、及びｐの値は、アプリケーションによる長期的な平均帯域幅使用法を反映しているため、通常、アプリケーションは、セッションを生成し、その後に、これらの値を固定された状態において維持することになると予想されるが、理論的には、いずれのパラメータも、時間と共に変化可能である。
【０１８９】
セッションの優先度は、アプリケーションの最大優先度を超過することはできないが、低下させることは可能である。
【０１９０】
【数９】
2009525641.tif 000023
【０１９１】
更には、アプリケーションのセッションの保証最小帯域幅の合計は、アプリケーションの保証最小帯域幅を超過することはできない。
【０１９２】
【数１０】
2009525641.tif 000024
【０１９３】
アプリケーションのセッションは、互いの帯域幅を優先使用することによって共存可能である必要がある。即ち、セッションが存在しているそれぞれの優先度レベルにおいて、その優先度を有するアプリケーション内のすべてのセッションをその予想帯域幅において稼動させると共に、すべての更に低い優先度のセッションをその保証帯域幅において稼動させることが可能である必要があり、これらは、いずれも、そのアプリケーションの予想帯域幅内において行われる必要がある。
【０１９４】
【数１１】
2009525641.tif 000025
【０１９５】
（アプリケーションによる動的な帯域幅の要求）
アプリケーションの帯域幅使用量の変動に対処すべく、アプリケーションは、次のように、現在の要求帯域幅値を、ＱｏＳパラメータの組の形態において、または予想平均Ｅsに対する係数として、規定可能であることに留意する。
【０１９６】
Ｄs：セッションｓによって現在要求されている帯域幅（既定値：Ｅs）
【０１９７】
また、アプリケーションは、次のように、利用可能である場合には自身が更に大きな帯域幅を利用可能であると規定することも可能である。
【０１９８】
Ｘs：セッションｓによって要求されている最大帯域幅（既定値：Ｄs）
【０１９９】
これらの値を使用することにより、セッションに対する余剰帯域幅の割り当てに影響を与えることができる。アプリケーションは、Ｅsを超過している場合には、正常な動作状態においても、要求の帯域幅の取得が保証されていないことに留意する。更には、アプリケーションは、実際には、Ｅsを下回るものを要求することにより、その他のアプリケーションに対して帯域幅を一時的に提供することも可能である。例えば、通知セッションは、通知がアクティブでない際には、これを暗黙のうちに実行している。
【０２００】
セッション更新を実行して余剰の帯域幅をセッションに跨って再割り当てした際には、システム内のそれぞれのセッションｓには、公称帯域幅ｂsが割り当てられる。任意の適切なアルゴリズムまたは経験則を使用することにより、この（再）割り当てを以下の条件に従って実行可能である。
【０２０１】
１．すべてのアプリケーションセッションに割り当てられた帯域幅の合計は、定義されているトータルデータチャネル帯域幅を超過することができない。
【０２０２】
【数１２】
2009525641.tif 000026
【０２０３】
セッションは、その１以上の最小帯域幅を下回るものを要求している可能性があることに留意する。従って、次のように定義しよう。
【０２０４】
Ｅ’s＝ｍｉｎ（Ｅs，Ｄs）：セッションｓの動的な予想帯域幅
Ｍ’s＝ｍｉｎ（Ｍs，Ｄs）：セッションｓの動的な保証帯域幅
【０２０５】
２．割り当て帯域幅は、次の範囲内になければならない。
【０２０６】
∀ｓ∈Ｓ：Ｍ’s≦ｂs≦Ｘs
【０２０７】
３．更には、セッションは、少なくともその所望の帯域幅を取得する必要があり、そうでない場合には、それは、すべての更に高い優先度のセッションが、その要求を上回らないものを取得したという場合であろう。
【０２０８】
∀ｓ∈Ｓ：ｂs＜Ｄs⇒∀ｔ∈Ｓ｜ｐt＞ｐs：ｂt≦Ｄt
【０２０９】
４．同様に、セッションは、少なくともその動的な予想帯域幅を取得する必要があり、そうでない場合には、すべての更に高い優先度のセッションが、その有効予想帯域幅を上回らないものを取得したということであろう。
【０２１０】
∀ｓ∈Ｓ：ｂs＜Ｅ’s⇒∀ｔ∈Ｓ｜ｐt＞ｐs：ｂt≦Ｅ’t
【０２１１】
５．最後に、セッションは、更に高い優先度を有するものが帯域幅を要求していない場合には、少なくともその動的な予想帯域幅を取得する必要がある。
【０２１２】
【数１３】
2009525641.tif 000027
【０２１３】
アプリケーションの帯域幅提供プロセスが、関連する制約を満足している場合には、この最後の条件を満足することが一般的に可能であることに留意する。
【０２１４】
これらの制約内において、本システムは、セッション間において余剰の帯域幅を分配する方法に影響を与えるガイドとして要求の最大及び保証帯域幅を使用することにより、任意の適用可能なアルゴリズム、規則の組、または経験則に従って、資源を割り当て可能である。後程詳述するように、帯域幅の割り当ては、イベント・スケジューラ２３０によって管理されている。イベント・スケジューラ２３０は、事業者によってセットアップされたアプリケーションポリシー、アプリケーションの現在の要件、及びシステム内のその他のアプリケーションによる帯域幅使用量を使用することにより、割り当て帯域幅を決定している。
【０２１５】
アプリケーションの割り当て帯域幅の変化をそのアプリケーションに伝達することにより、そのアプリケーションが、それらの変化に反応する機会を得るようにする必要があることに留意する。アプリケーションは、リアルタイムで帯域幅の変化に反応することも可能であり、あるいは、帯域幅の変化が発生した際にブロードキャスト・サーバーが実装するポリシーを予めセットアップしておくことも可能である。
【０２１６】
（帯域幅の割り当て−概要）
以下、複数のアプリケーション間において帯域幅を割り当てるべく本発明が利用している方法及びプロセスについて、更に詳細に説明することとする。なお、帯域幅の割り当てに関係するプロセスは、次のように要約可能ではあるが、説明するプロセスのすべての段階が、それぞれのアプリケーションまたはセッションにおいて実行されるということではない。
【０２１７】
・ネットワーク事業者は、ブロードキャスト帯域幅をアプリケーションまたはアプリケーションのグループに割り振る。
【０２１８】
・適宜、事業者は、グループ内のそれぞれのアプリケーションの帯域幅使用量に関して制約を規定する。これらの割り当ては、全体的なグループの帯域幅の割り当てと一貫性を有していなければならない。
【０２１９】
・グループ内のそれぞれのアプリケーションは、全体的なＱｏＳパラメータ及びそれぞれのセッションの優先度を規定することにより、１以上のセッションを動的に追加または削除可能である。
【０２２０】
・セッションのセットアップが完了したら、アプリケーションは、長期的な要件よりも多くの（または、少ない）帯域幅をそのセッションのために一時的に要求可能である。
【０２２１】
・セッションパラメータの変化が存在するたびに、現在の要求ＱｏＳに基づいて、公称帯域幅をセッションごとに割り当てる。これには、その他のセッションに割り当てられた帯域幅を変更するステップと、その変化の影響を受けたアプリケーションに対して通知するステップが伴うことになろう。
【０２２２】
・ブロードキャスト・サーバーは、影響を受けたアプリケーションに対する通知を伴うことなしに、かつ、公称割り当てにも拘わらず、セッション内の瞬間的な資源使用量に基づいて、帯域幅を内部的に再配分可能である。但し、資源の使用を開始する場合にセッションにとって利用可能であるのは、公称帯域幅である。
【０２２３】
（帯域幅割り当て−詳細）
以下の内容は、既存のセッション及び関連するアプリケーションレベルの制約に基づいて、前述の定義及び制約に従い、帯域幅をセッションに割り当てるべくセッションマネージャが使用可能である可能な帯域幅割り当てのプロセス、アルゴリズム、規則の組、または経験則の一例である。
【０２２４】
１．アプリケーションによって規定されたサービス品質パラメータに基づいて予想帯域幅要件を決定する。
【０２２５】
２．必要な予想帯域幅、このアプリケーションがオープンしているその他のセッション、及び事業者によって設定されたアプリケーションポリシーに基づいて、（前述のセッション帯域幅の制約に従って）新しい要求がアプリケーションのセッション制約の違反を生成するかどうかを判断する。
２−ａ．新しい要求と同一の優先度を有するすべてのセッションの予想帯域幅、新しいセッションによって要求された予想帯域幅、及び新しい要求よりも低い優先度を有するすべてのセッションの保証最小帯域幅を合計する。
２−ｂ．前述の合計が、アプリケーションポリシーにおいて事業者が設定している予想帯域幅を上回っている場合には、その要求を拒絶し、
２−ｂ−ｉ．アプリケーションポリシーに定義されている予想帯域幅と先程演算した合計の間の差からこの新しい要求を減算したものとして、割り当て可能な予想帯域幅を演算し、
２−ｂ−ｉｉ．先程演算した帯域幅に基づいて、要求されたオリジナルのサービス品質との関係において付与可能である予想サービス品質を演算し、この値をアプリケーションに返す。
【０２２６】
３．予想帯域幅がアプリケーションポリシーによって許容されている場合には、要求と共に供給された相対的なサービス品質に基づいて、アプリケーションによって要求された最小保証帯域幅を演算し、新しい要求がアプリケーションのセッションレベルの帯域幅制約の違反を生成することになるかどうかを（前述のセッションの帯域幅制約に従って）判断する。
３−ａ．アプリケーションが既にオープンしているその他のセッションに定義されている最小保証帯域幅を新しい要求と合計し、
３−ａ−ｉ．この合計がアプリケーションポリシー内に定義されている最小保証帯域幅を上回っている場合には、その要求を拒絶し、かつ、次の３−ａ−ｉ−１段階を実行するにより、サポート可能な最小保証サービス品質についてアプリケーションに通知する。
３−ａ−ｉ−１．アプリケーションポリシーに定義されている最小保証帯域幅からアプリケーションが既にオープンしているすべてのセッションに定義されている最小保証帯域幅の合計を減算する。
３−ｂ．生成されるセッションの優先度レベルを上回るそれぞれの優先度レベルについて、
３−ｂ−ｉ．現在の優先度レベルを有するすべてのアプリケーションセッションの予想帯域幅、現在の優先度を下回る優先度を有するすべてのアプリケーションセッションの最小保証帯域幅、及び新しい要求の最小保証帯域幅を合計し、
３−ｂ−ｉ−１．この合計がアプリケーションポリシーに定義されている予想帯域幅を上回っている場合には、その要求を拒絶し、次の３−ｂ−ｉ−１−ａ段階を実行することにより、サポート可能な最小保証サービス品質についてアプリケーションに通知する。
３−ｂ−ｉ−１−ａ．アプリケーションポリシーに定義されている予想帯域幅から、現在の優先度レベルを有するすべてのアプリケーションセッションの予想帯域幅の合計に現在の優先度を下回る優先度を有するすべてのアプリケーションセッションの最小保証帯域幅を加算したものを減算する。
【０２２７】
新しいセッション要求が、セッションの帯域幅制約に違反していない場合には、公称割り当て帯域幅を演算可能である。これには、その他のアプリケーションのセッションを含むその他のセッションの帯域幅の再割り当てを実行するステップを伴うことになろう。この手順またはこれに等価なものは、アプリケーションがその要求帯域幅を動的に変更する際に使用される。
【０２２８】
４．予想帯域幅をサポート可能であり、最小保証帯域幅を（それが規定されているときに）サポート可能である場合には、
４−ａ．次の２つの中の最小値として最大使用可能帯域幅を計算する。
４−ａ−ｉ．アプリケーションポリシー内の固有の最大許容可能帯域幅、または
４−ａ−ｉｉ．最大使用可能サービス品質が規定されている場合に、帯域幅に変換された最大使用可能サービス品質
４−ｂ．次の２つを使用することにより、アプリケーションの所望の帯域幅を演算する。
４−ｂ−ｉ．サービス品質が与えられている場合には、所望のサービス品質
４−ｂ−ｉｉ．サービス品質が与えられていない場合には、予想帯域幅を使用する。
４−ｃ．セッションに現在割り当て可能である帯域幅を次のように計算する。
４−ｃ−ｉ．未使用の帯域幅が容易に入手可能である場合には、最大で、アプリケーションの最大使用可能帯域幅まで割り当てる。
４−ｃ−ｉｉ．以前の段階において割り当てられた帯域幅が、アプリケーションの所望の帯域幅を下回っている場合には、必要な追加の帯域幅を計算し、帯域幅再割り当てアルゴリズムを使用することにより、次の制約の下に既存のアプリケーションから帯域幅を取得する。
４−ｃ−ｉｉ−１．その所望のまたはその最小保証帯域幅の小さいほうを下回るように既存のアプリケーションの帯域幅を削減することはできない。
４−ｃ−ｉｉ−２．対象のアプリケーションの優先度レベル以下の優先度レベルを有するその他のアプリケーションが、その所望のまたは予想帯域幅の小さいほう以下において動作していない限り、その所望のまたは予想帯域幅の小さいほうを下回るようにそのアプリケーションの帯域幅を削減することはできない。
４−ｄ．将来の計算において帯域幅を分配する際に使用すべく、アプリケーションの所望の帯域幅、予想帯域幅、最小保証帯域幅、及び最小使用可能帯域幅をセッションのポリシーと共に保存する。
４−ｅ．ベースサービス品質値を予想帯域幅に割り振る。
４−ｆ．ベースサービス品質値との関係において、最小保証帯域幅、現在の割り当て帯域幅、及び最大許容可能帯域幅におけるサービス品質値を計算する。
４−ｇ．このアプリケーションに最初に割り振られている帯域幅を割り当てる。
４−ｈ．予想サービス品質値、最小保証サービス品質値、最大サービス品質値、及び現在の割り当てサービス品質値をアプリケーションに返す。
【０２２９】
以下の内容は、前述の帯域幅割り当て手順の段階４−ｃ−ｉｉにおいて必要とされているすべての優先度レベルに跨って帯域幅を再分配する帯域幅再割り当てアルゴリズムの例である。この同一のアルゴリズムは、新しいセッションが生成される際、セッションのパラメータが変更される際、またはセッションが閉鎖される際に、使用可能である。
【０２３０】
１．以下の計算においては、セッションの所望の帯域幅がセッションの予想帯域幅を下回っている場合には、セッションの予想帯域幅の代わりに、セッションの所望の帯域幅を使用する（即ち、Ｅ’s＝ｍｉｎ（Ｅs，Ｄs））。
【０２３１】
２．以下のすべての計算においては、セッションの所望の帯域幅がセッションの最小保証帯域幅を下回っている場合には、セッションの最小保証帯域幅の代わりに、セッションの所望の帯域幅を使用する（即ち、Ｍ’s＝ｍｉｎ（Ｍs，Ｄs））。
【０２３２】
３．それぞれのアプリケーションにその最大使用可能帯域幅を付与するのに十分な帯域幅が存在している場合には、最大使用可能帯域幅をそれぞれのアプリケーションセッションに割り当てる。終了。
【０２３３】
４．その所望の帯域幅をそれぞれのアプリケーションに付与するのに十分な帯域幅が存在している場合には、
４−ａ．所望の帯域幅をそれぞれのアプリケーションセッションに割り当てる。
４−ｂ．更なる帯域幅が利用可能である場合には、最高優先度のセッションから始めて、更なる帯域幅が利用可能である限り、次のように継続する。
４−ｂ−ｉ．この優先度レベルにおけるそれぞれのアプリケーションセッションの最大許容可能帯域幅と所望の帯域幅の間の差を合計する。
４−ｂ−ｉｉ．合計が残りの帯域幅を下回っている場合には、最大許容可能帯域幅をこの優先度レベルにおけるすべてのアプリケーションセッションに割り当て、かつ、次の更に低い優先度レベルにおいて継続する。
４−ｂ−ｉｉｉ．合計が残りの帯域幅を上回っている場合には、この優先度レベルにおけるすべてのアプリケーションセッションの最大使用可能帯域幅と所望の帯域幅の間の差に比例した値において残りの帯域幅を割り当てる。終了。
【０２３４】
５．その予想帯域幅をそれぞれのアプリケーションに付与すべく十分な帯域幅が存在している場合には、
５−ａ．予想帯域幅をそれぞれのアプリケーションセッションに割り当て、
５−ｂ．更なる帯域幅が利用可能である場合には、最高優先度のセッションから始めて、更なる帯域幅が利用可能である限り、次のように継続する。
５−ｂ−ｉ．この優先度レベルにおけるそれぞれのアプリケーションの所望の帯域幅と予想帯域幅の間の差を合計し、
５−ｂ−ｉｉ．合計が残りの帯域幅を下回っている場合には、所望の帯域幅をこの優先度レベルにおけるすべてのアプリケーションセッションに割り当て、かつ、次の更に低い優先度レベルにおいて継続し、
５−ｂ−ｉｉｉ．合計が残りの帯域幅を上回っている場合には、この優先度レベルにおけるすべてのアプリケーションセッションの所望の帯域幅と予想帯域幅の間の差に比例した値において残りの帯域幅を割り当てる。終了。
【０２３５】
６．保証最小帯域幅をそれぞれのアプリケーションセッションに割り当てる。
【０２３６】
７．更なる帯域幅が利用可能である場合には、最高優先度のセッションから始めて、更なる帯域幅が利用可能である限り、次のように継続する。
７−ａ．この優先度レベルにおけるそれぞれのアプリケーションセッションの予想帯域幅と最小保証帯域幅の間の差を合計し、
７−ｂ．合計が残りの帯域幅を下回っている場合には、予想帯域幅をこの優先度レベルのすべてのアプリケーションセッションに割り当て、次の更に低い優先度レベルにおいて継続し、
７−ｃ．合計が残りの帯域幅を上回っている場合には、この優先度レベルにおけるすべてのアプリケーションセッションの予想帯域幅と最小保証帯域幅の差に比例した値において残りの帯域幅を割り当てる。終了。
【０２３７】
図６〜図８は、アプリケーションによって要求されたブロードキャストセッションに帯域幅を割り当てる際に利用可能であるセッションマネージャ２４０のある動作を示している。図６は、本発明の一部として利用可能であるアプリケーションセッションを生成するプロセスを示す図である。この図を参照して説明するプロセスにおいては、アプリケーションは、ＱｏＳパラメータを規定することによって新しいまたは変更されたセッションを要求するが、帯域幅の値または範囲を規定することも可能である。説明対象のプロセスは、通常、ブロードキャスト・サーバー１１０のセッションマネージャ２４０によって実行される機能またはプロセスの一部として実装される。
【０２３８】
図６に示されているように、アプリケーション１３０は、予想ＱｏＳパラメータ（ＥＱｏＳ）、優先度（Ｐ）、並びに、任意選択により、相対的な最小ＱｏＳ（ＭＱｏＳ）、最大ＱｏＳ（ＸＱｏＳ）、及び現在の所望のＱｏＳ（ＤＱｏＳ）を指定することにより、新しいまたは変更されたセッションを要求する（段階６１０）。次いで、セッションマネージャ２４０は、要求されたＥＱｏＳをサポートするのに必要な帯域幅（ＥＢ）を計算する（段階６２０）。次いで、（図７を参照して説明するように）値ＥＢを試験することにより、それが事業者によって定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足しているかどうかを判断する（段階６３０）。この値が、定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足していない場合には、パラメータＥＱｏＳをサポート不可能である。この場合には、セッションマネージャ２４０は、サポート可能なＥＱｏＳ値を計算し、これをアプリケーションに返す（段階６４０）。ＥＢ値が、定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足している場合には、セッションマネージャ２４０は、ＭＱｏＳ値がアプリケーションによって規定されているかどうかを判断する（段階６５０）。この値が規定されていない場合には、セッションマネージャは、必要に応じて、その他のセッションの帯域幅の再割り当てを実行することにより、このセッションの帯域幅を割り当て、このセッションに割り振られたすべてのＱｏＳ値をアプリケーションに返す（段階６６０）。ＭＱｏＳ値の値が規定されている場合には、セッションマネージャは、ＭＱｏＳ値をサポートするのに必要な帯域幅（ＭＢ）を計算する（段階６７０）。次に、セッションマネージャは、ＭＢ値が、関連する事業者によって定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足しているかどうかを（図８を参照して説明するように）判断する（段階６８０）。帯域幅値がアプリケーション及び適用可能なセッションポリシーを満足している場合には、セッションマネージャは、必要に応じて、その他のセッションの帯域幅の再割り当てを実行することにより、このセッションの帯域幅を割り当て、このセッションに割り当てられたすべてのＱｏＳ値をアプリケーションに返している（段階６６０）。帯域幅値が、アプリケーション及び適用可能なセッションポリシーを満足していない場合には、パラメータＭＱｏＳをサポート不可能である。この場合には、セッションマネージャ２４０は、サポート可能なＭＱｏＳ値を計算し、これをアプリケーションに返す（段階６４０）。
【０２３９】
図７は、セッションが生成または変更される際に予想帯域幅チェックを実行するプロセスを示す図である。図６を参照して説明したように、このプロセスにおいては、値ＥＢを試験することにより、それが、事業者によって定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足しているかどうかを判断する。図７に示されているように、プロセスに対する入力は、そのセッションの要求された予想帯域幅の値（ＥＢ）と、セッション優先度（Ｐ）である（段階７１０）。次いで、適用可能な事業者によって定義されたアプリケーションポリシーから、予想（Ｅ）帯域幅値を取得する（段階７２０）。次いで、本プロセスは、アプリケーションが同一の優先度レベルＰにおいてオープンしているすべてのセッションについて、予想帯域幅を合計する（Ｓｕｍ（ＥＢＳ））（段階７３０）。次いで、本プロセスは、アプリケーションがＰよりも低い優先度レベルにおいて既にオープンしているすべてのセッションについて、保証最小帯域幅を合計する（Ｓｕｍ（ＭＢＳ））（段階７４０）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階７５０）
【０２４０】
Ｓｕｍ（ＥＢＳ）＋Ｓｕｍ（ＭＢＳ）＋ＥＢ＜＝Ｅ
【０２４１】
この関係が真である場合には、ＥＢ値をサポート可能である（段階７６０）。この関係が偽である場合には、ＥＢ値をサポート不可能である（段階７７０）。
【０２４２】
図８は、セッションが生成または変更される際に保証最小帯域幅チェックを実行するプロセスを示す図である。図６を参照して説明したように、このプロセスにおいては、セッションマネージャは、ＭＢ帯域幅値が、関連する事業者によって定義されたアプリケーションポリシー及び適用可能なセッションポリシーを満足しているかどうかを判断する。図８に示されているように、このプロセスに対する入力は、そのセッションの要求された最小保証帯域幅の値（ＭＢ）と、セッション優先度（Ｐ）である（段階８１０）。次いで、事業者によって定義されたアプリケーションポリシーから、保証最小（Ｍ）及び予想（Ｅ）帯域幅限度の値を取得する（段階８２０）。次いで、本プロセスは、アプリケーションがすべての優先度レベルにおいてオープンしているすべてのセッションについて、保証最小帯域幅を合計する（Ｓｕｂ（ＭＢＳ））（段階８３０）。次いで、プロセスは、次の関係が真であるか偽であるかを判断する（段階８４０）。
【０２４３】
Ｓｕｍ（ＭＢＳ）＋ＭＢ＜＝Ｍ
【０２４４】
この関係が偽である場合には、ＭＢ値をサポート不可能である（段階８５０）。この関係が真である場合には、本プロセスは、アプリケーションに定義されているすべてのセッションについて、最大セッション優先度Ｍａｘ（ｐ）を計算する（段階８６０）。次いで、優先度値ｐ＝Ｐ＋１から始まって（段階８８０）、本プロセスは、ｐ＞Ｍａｘ（ｐ）であるかどうかを判断する（段階８８０）。この結果が、この関係が満足されているというものである場合には、ＭＢ値をサポート可能である（段階８９０）。この結果が、この関係が満足されないというものである場合には、本プロセスは、アプリケーションがｐを下回る優先度レベルにおいてオープンしているすべてのセッションについて、保証最小帯域幅を合計する。Ｓｕｍ（ＭＢＳｐ）。（段階８９２）。次いで、本プロセスは、アプリケーションが優先度レベルｐにおいてオープンしているすべてのセッションについて、予想帯域幅を合計する。Ｓｕｍ（ＥＢＳｐ）。（段階８９４）。次いで、本プロセスは、次の関係が真であるか偽であるかを決定している（段階８９６）。
【０２４５】
Ｓｕｍ（ＥＢＳｐ）＋Ｓｕｍ（ＭＢＳｐ）＋ＭＢ＜＝Ｅ
【０２４６】
この関係が真である場合には、本プロセスは、優先度を増分しｐ＝ｐ＋１（段階８９８）、制御を段階８８０に渡している。この関係が偽である場合には、ＭＢ値をサポート不可能である（段階８５０）。
【０２４７】
本発明の一実施形態に従って複数のセッション間において帯域幅を割り当てるのに好適な帯域幅割り当てプロセスについて、図９〜図１２を参照して説明する。図９は、帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。この図に示されているように、プロセスの各段階は、通常、イベント・スケジューラ２３０によって実行される機能の一部として実装されることになる。図に示されているように、本プロセスは、アプリケーショングループにとって利用可能である総帯域幅の値Ｂを取得することにより、開始する（段階９１０）。次いで、本プロセスは、それぞれのセッションの最大許容可能帯域幅を合計する。Ｓｕｍ（Ｘ）。（段階９１２）。次いで、本プロセスは、次の関係が真であるかまたは偽であるかを判断する（段階９１４）
【０２４８】
Ｓｕｍ（Ｘ）＜＝Ｂ
【０２４９】
この関係が真である場合には、本プロセスは、最大許容可能帯域幅をそれぞれのセッションに割り当てる（段階９１６）。この関係が偽である場合には、本プロセスは、それぞれのセッションの所望の帯域幅を合計する。Ｓｕｍ（Ｄ）。（段階９１８）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階９２０）。
【０２５０】
Ｓｕｍ（Ｄ）＜＝Ｂ
【０２５１】
この関係が真である場合には、本プロセスは、図１０を参照して説明する方法またはアルゴリズムを使用することにより、帯域幅Ｂを割り当てる（段階９２２）。この関係が偽である場合には、本プロセスは、それぞれのセッションの所望のまたは予想帯域幅の最小値を合計する。Ｓｕｍ（Ｅ）。（段階９２４）。次いで、本プロセスは、次の関係が真であるか偽であるかを決定する（段階９２６）。
【０２５２】
Ｓｕｍ（Ｅ）＜＝Ｂ
【０２５３】
この関係が真である場合には、本プロセスは、図１１を参照して説明する方法またはアルゴリズムを使用することにより、帯域幅Ｂを割り当てる（段階９２８）。この関係が偽である場合には、本プロセスは、図１２を参照して説明する方法またはアルゴリズムを使用することにより、帯域幅Ｂを割り当てる（段階９３０）。
【０２５４】
前述のように、図１０は、すべてのアプリケーションの所望の帯域幅の合計（Ｓｕｍ（Ｄ））が、アプリケーショングループに割り当てられた総帯域幅（Ｂ）以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。このプロセスは、所望の帯域幅をそれぞれのオープンセッションに割り当てることにより、開始される（段階１０１０）。次いで、本プロセスは、次式を決定することにより、未割り当て状態に留まっている総帯域幅が存在しているかどうかを判断する（段階１０１２）。
【０２５５】
Ｂ＝Ｂ−Ｓｕｍ（Ｄ）
【０２５６】
次いで、本プロセスは、この値がゼロを上回っているかどうかを判断する（段階１０１４）。値がゼロを上回っていない場合には、本プロセスは、終了。（段階１０１６）。値がゼロを上回っている場合には、本プロセスは、すべてのオープンセッションについて、最大セッション優先度Ｍａｘ（ｐ）及び最小セッション優先度Ｍｉｎ（ｐ）を計算する（段階１０１８）。次いで、本プロセスは、優先度値である優先度ｐ＝Ｍａｘ（ｐ）において開始し（段階１０２０）、本プロセスは、優先度ｐにおいてオープン状態にあるすべてのセッションについて、最大許容可能帯域幅及び所望帯域幅の間の差を合計する。Ｓｕｍ（ＸＤｐ）（段階１０２２）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階１０２４）。
【０２５７】
Ｓｕｍ（ＸＤｐ）＜＝Ｂ
【０２５８】
この関係が偽である場合には、本プロセスは、優先度ｐにおけるすべてのセッションについて、それぞれのセッションの最大許容可能帯域幅と所望の帯域幅の差に基づいて比例するように残りのＢを割り当てた後に（段階１０２６）、本プロセスは終了する（段階１０２８）。この関係が真である場合には、本プロセスは、優先度ｐにおけるすべてのセッションについて、最大許容可能帯域幅を割り当てる（段階１０３０）。次いで、本プロセスは、次式を決定する（段階１０３２）。
【０２５９】
Ｂ＝Ｂ−Ｓｕｍ（ＸＤｐ）
【０２６０】
次いで、本プロセスは、ｐ＝ｐ−１を設定することにより、優先度を減分する（段階（１０３４）。本プロセスは、次式が成立するかどうかを判断する（段階１０３６）。
【０２６１】
ｐ＜Ｍｉｎ（ｐ）
【０２６２】
この関係が真である場合には、本プロセスは、終了。（段階１０２８）。この関係が偽である場合には、本プロセスは、制御を段階１０２２に返す。
【０２６３】
図１１は、すべてのアプリケーションセッションの所望の帯域幅と予想帯域幅の小さいほうの合計が、アプリケーショングループに割り当てられた総帯域幅以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。本プロセスは、所望の帯域幅及び予想帯域幅の小さいほうをそれぞれのオープンセッションに割り当てることにより、開始する（段階１１１０）。次いで、本プロセスは、次式を決定することにより、未割り当て状態において残っている総帯域幅が存在しているかどうかを判断する（段階１１１２）。
【０２６４】
Ｂ＝Ｂ−Ｓｕｍ（Ｅ）
【０２６５】
次いで、本プロセスは、この値がゼロを上回っているかどうかを判断する（段階１１１４）。値がゼロを上回っていない場合には、本プロセスは、終了。（段階１１１６）。値がゼロを上回っている場合には、本プロセスは、すべてのオープンセッションについて、最大セッション優先度Ｍａｘ（ｐ）及び最小セッション優先度Ｍｉｎ（ｐ）を計算する（段階１１１８）。次いで、本プロセスは、優先度値である優先度ｐ＝Ｍａｘ（ｐ）において開始し（段階１１２０）、本プロセスは、優先度ｐにおいてオープン状態にあり、予想帯域幅を下回っていない所望の帯域幅を具備したすべてのセッションについて、所望の帯域幅と予想帯域幅の間の差を合計する。Ｓｕｍ（ＤＥｐ）（段階１１２２）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階１１２４）。
【０２６６】
Ｓｕｍ（ＤＥｐ）＜＝Ｂ
【０２６７】
この関係が偽である場合には、本プロセスは、優先度ｐにおいてオープン状態にあり、予想帯域幅を下回っていない所望帯域幅を持つすべてのセッションについて、それぞれのセッションの所望の帯域幅と予想帯域幅の間の差に基づいて比例するように残りのＢを割り当てた後に（段階１１２６）、本プロセスは、終了する（段階１１２８）。この関係が真である場合には、本プロセスは、優先度ｐにおいてオープン状態にあり、予想帯域幅を下回っていない所望の帯域幅を持つすべてのセッションについて、所望の帯域幅を割り当てる（段階１１３０）。次いで、本プロセスは、次式を決定する（段階１１３２）。
【０２６８】
Ｂ＝Ｂ−Ｓｕｍ（ＤＥｐ）
【０２６９】
次いで、本プロセスは、ｐ＝ｐ−１を設定することにより、優先度値を減分する。次いで、本プロセスは、次式が成立するかどうかを判断する（段階１１３６）。
【０２７０】
ｐ＜Ｍｉｎ（ｐ）
【０２７１】
この関係が真である場合には、本プロセスは、終了。（段階１１２８）。この関係が偽である場合には、本プロセスは、制御を段階１１２２に返す。
【０２７２】
図１２は、すべてのアプリケーションセッションにおける所望の帯域幅と保証最小帯域幅の小さいほうの合計が、アプリケーショングループに割り当てられた総帯域幅以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。このプロセスは、所望の帯域幅及び保証最小帯域幅の小さいほうをそれぞれのオープンセッションに割り当てることにより、開始する（段階１２１０）。次いで、本プロセスは、次式を決定することにより、未割り当て状態において残っている総帯域幅が存在しているかどうかを判断する（段階１２１２）。
【０２７３】
Ｂ＝Ｂ−Ｓｕｍ（Ｍ）
【０２７４】
次いで、本プロセスは、この値がゼロを上回っているかどうかを判断する（段階１２１４）。値がゼロを上回っていない場合には、本プロセスは、終了する（段階１２１６）。値がゼロを上回っている場合には、本プロセスは、すべてのオープンセッションについて、最大セッション優先度Ｍａｘ（ｐ）及び最小セッション優先度Ｍｉｎ（ｐ）を計算する（段階１２１８）。次いで、本プロセスは、優先度値である優先度ｐ＝Ｍａｘ（ｐ）において開始し（段階１２２０）、本プロセスは、優先度ｐにおいてオープン状態にあり、保証最小帯域幅を下回っていない所望の帯域幅を持つすべてのセッションについて、所望の帯域幅と予想帯域幅の小さいほうと保証最小帯域幅の差を合計する。Ｓｕｍ（ＥＭｐ）（段階１２２２）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階１２２４）。
【０２７５】
Ｓｕｍ（ＥＭｐ）＜＝Ｂ
【０２７６】
この関係が偽である場合には、本プロセスは、優先度ｐにおいてオープン状態にあり、保証最小帯域幅を下回っていない所望の帯域幅を持つすべてのセッションについて、それぞれのセッションの所望の帯域幅と予想帯域幅の小さいほうと最小保証帯域幅の差に基づいて比例するように残りのＢを割り当てた後に（段階１２２６）、本プロセスは終了する（段階１２２８）。この関係が真である場合には、本プロセスは、優先度ｐにおいてオープン状態にあり、保証最小帯域幅を下回っていない所望の帯域幅を持つすべてのセッションについて、所望の帯域幅と予想帯域幅の小さいほうを割り当てる（段階１２３０）。次いで、本プロセスは、次式を決定する（段階１２３２）。
【０２７７】
Ｂ＝Ｂ−Ｓｕｍ（ＥＭｐ）
【０２７８】
次いで、本プロセスは、ｐ＝ｐ−１を設定することにより、優先度値を減分する（段階１２３４）。次いで、本プロセスは、次式が成立するかどうかを判断する（段階１２３６）。
【０２７９】
ｐ＜Ｍｉｎ（ｐ）
【０２８０】
この関係が真である場合には、本プロセスは、終了。（段階１２２８）。この関係が偽である場合には、本プロセスは、段階１２２２に制御を返す。
【０２８１】
（一時的な帯域幅の適合）
動的な帯域幅割り当てｂsは、それぞれのセッションにとって利用可能である公称帯域幅である。これらは、必要に応じて、セッション構成動作（セッションパラメータの生成、削除、再構成、動的帯域幅の要求）または事業者ポリシーの変化が発生した際に、更新可能である。
【０２８２】
動作の際には、ブロードキャスト・サーバーは、セッションが現在帯域幅を十分に利用してはおらず、要求されたＱｏＳを現在割り当てられている帯域幅よりも少ない帯域幅によって維持可能であることを検知可能であろう。例えば、データオブジェクトセッションは、レイテンシーＱｏＳのターゲットを公称割り当てよりも低いパケットレートによって維持できるように、平均して予想されているものよりも少ない数のファイルをカルーセル上に持つことができる。この場合に、ブロードキャスト・サーバーは、その帯域幅を使用して別のセッションのＱｏＳ要求または要件を満足可能である場合には、そのセッションに使用されている帯域幅を内部的に低減可能である。動作の際には、イベント・スケジューラは、認知した需要に基づいてセッションの所望の帯域幅を内部的に変更し、その影響を受けるセッションの動的な帯域幅再割り当てを再計算する。この調節は、ある種類のイベントが発行された結果として実行することも可能であり、あるいは、定期的に適用することも可能である。帯域幅を借りた先のセッションが、後から、その公称帯域幅を要求した場合には、帯域幅再割り当てプロセスを使用することにより、資源をそのアプリケーションに返却可能である。
【０２８３】
同様に、アプリケーションは、その現在の割り当て帯域幅またはサービス品質が許容しているものを上回るイベントを一時的に送信可能である。この場合には、アプリケーションが、その現在の割り当て帯域幅またはサービス品質が許容しているものを下回る数のイベントを一時的に送信する状況と同様に、そのサービス品質に影響を与えることなしに、使用される実際の帯域幅を適合可能であろう。
【０２８４】
このような適合が存在しない場合には、ブロードキャスト・サーバーは、そのサービス品質が（システム内のその他のアプリケーションによる活動とは対照的に）それ自体の動作に起因して変化していることをアプリケーションに通知する必要があろう。この場合には、セッションに割り当てられている実際の帯域幅が変化することはなく、サービス品質のみであることに留意する。例えば、アプリケーションが、現在割り当てられているサービス品質が許容しているものの２倍のレートで同一の帯域幅においてイベントを送信することを開始した場合には、サービス品質は、使用する帯域幅が同一に留まる場合にも、オリジナルの値の半分に劣化することになる。このＱｏＳの低下は、例えば、相対的に長いレイテンシーの形態をとる可能性がある。あるいは、この代わりに、アプリケーションは、現在のサービス品質が許容しているものの半分のレートでイベントを送信することを開始可能である。この場合には、サービス品質は、割り当てられた帯域幅における変更を伴うことなしに、倍増可能であり、これは、相対的に短いレイテンシーの形態をとることになろう。
【０２８５】
しかしながら、適合化を行うことにより、ブロードキャスト・サーバーは、アプリケーションセッションの動作によって発生するサービス品質の一時的な変動を利用して、そのセッションによって使用されている実際の帯域幅を適合させることができる。この適合化の目的は、必要に応じて帯域幅を一時的に再割り当てすることにより、すべてのセッションに跨ってサービス品質を維持することにある。例えば、サービス品質が一時的に増大しているセッションから帯域幅を借り受けて、サービス品質が一時的に減少しているセッションに対して再割り当て可能である。
【０２８６】
イベント・スケジューラは、この適合化プロセスに対する責任を担っており、かつ、一実施形態においては、これを次の段階によって実行している。
【０２８７】
１．セッションを定期的にスキャンし、それらの現在のサービス品質が割り当て済みのものと異なっているかどうかを判断し、
１−ａ．最大粒度としては、これは、イベントが任意のセッションのイベントカルーセルに追加されるかまたはこれから除去されるたびに発生することになる。
【０２８８】
２．サービス品質を増大可能である場合、
２−ａ．アプリケーションが、追加のサービス品質を利用しないと通知している場合、またはサービス品質の変化が特定の閾値を下回っている場合には、現在の割り当てサービス品質を維持すべく実行可能である帯域幅の低減を決定し、
２−ａ−ｉ．この帯域幅値を、別のアプリケーションセッションによって一時的に使用されるべく利用可能であることを通知している適合テーブル内に保存し、
２−ｂ．アプリケーションがサービス品質を利用可能であり、かつ、サービス品質の変化がなんらかの閾値を上回っている場合には、新しい相対的なサービス品質を演算し、セッションのサービス品質が増大したことをアプリケーションに通知する。
【０２８９】
３．サービス品質を低下させる必要がある場合、
３−ａ．サービス品質の変化が特定の閾値を下回っている場合には、現在の割り当てサービス品質を維持するのに必要である帯域幅の増大を決定し、
３−ａ−ｉ．この帯域幅値を、このアプリケーションが追加帯域幅を使用可能であることを通知する適合テーブル内に保存する。
３−ｂ．サービス品質の変化がなんからの閾値を上回っている場合には、新しい相対サービス品質を演算し、セッションのサービス品質が低下したことをアプリケーションに通知する。
【０２９０】
４．適合テーブル内のエントリに基づいて、帯域幅分配アルゴリズムを使用することにより、更なる帯域幅を必要としているアプリケーションに対して利用可能である余剰の帯域幅を割り当てる。
【０２９１】
帯域幅を提供するのか、帯域幅を借りるのか、またはサービス品質の変化をアプリケーションに通知するのかを決定するための閾値は、時間に基づいたものであるか、割合の変化に基づいたものであるか、またはこれらの両方の組み合わせであってよい。例えば、閾値は、・１０秒を超過して継続する変化、・１０％を上回る変化、または・５％を上回っており、５秒を上回って継続する変化として指定可能であろう。
【０２９２】
余剰の帯域幅を持つアプリケーションから追加帯域幅を使用可能であるアプリケーションに追加帯域幅を割り当てるのに使用可能な帯域幅分配アルゴリズムの例は、次のとおりである。
【０２９３】
１．システム内のすべてのアプリケーションセッションによって要求されている追加帯域幅を合計する。
【０２９４】
２．システム内のすべてのセッションから入手可能である追加帯域幅を合計する。
【０２９５】
３．要求された追加帯域幅の合計が、入手可能なものの合計を下回っている場合には、最低優先度から始めて、すべての帯域幅要求が満足される時点まで継続し、
３−ａ．この優先度レベルにおけるすべてのセッションから入手可能である余剰の帯域を合計する。
３−ｂ．合計が懸案の帯域幅要求を下回っている場合には、このような要求を有するセッションにすべての帯域幅を割り当て、次の最高優先度レベルにおいて継続する。
３−ｃ．合計が未解決の帯域幅要求を上回っている場合には、それぞれのセッションから余剰の帯域幅の比例した量を取得し、これを要求元のセッションに割り当てる。終了する。
【０２９６】
４．要求された追加帯域幅が入手可能なものを上回っている場合には、最高優先度において始めて、入手可能な余剰帯域幅が存在している限り継続し、
４−ａ．この優先度レベルにおけるすべてのセッションの帯域幅要求を合計し、
４−ｂ．合計が入手可能な余剰の帯域幅を下回っている場合に、余剰の帯域幅をこの優先度レベルにおけるすべてのセッションに割り当て、次の更に低い優先度レベルにおいて継続し、
４−ｃ．合計が入手可能な余剰の帯域幅を上回っている場合には、それぞれのセッションの要求に比例するように余剰の帯域幅を割り当てる。終了する。
【０２９７】
本発明の一部として実装するのに好適な帯域幅の適合化または再割り当てプロセスについて、図１３〜図１５を参照して説明する。図１３は、帯域幅を提供するかまたは追加帯域幅を要求することにより、帯域幅の適合化または再割り当てプロセスに参加可能であるアプリケーションを決定するプロセスを示す図である。本プロセスは、それぞれのアプリケーションセッションについて、現在の割り当て帯域幅（ＡＢ）、ＡＢに基づいてセッションが約束されているサービス品質（ＰＱｏＳ）、及びセッションの最大使用可能サービス品質（ＸＱｏＳ）を取得することにより、開始する（段階１３１０）。次いで、本プロセスは、アプリケーションセッションが実際に送信しているイベントの頻度及びサイズに基づいて、ＰＱｏＳをサポートするのに必要な帯域幅（ＮＢ）を計算する（段階１３２０）。次いで、本プロセスは、ＮＢ＞ＡＢであるかどうかを判断する（段階１３３０）。この関係が真である場合には、本プロセスは、ＰＱｏＳのサポートを継続するのに必要な余剰の帯域幅を計算する。ＲＢ＝ＮＢ−ＡＢ（段階１３３２）。次いで、本プロセスは、ＲＢ＞閾値であるかどうかを判断する（段階１３３４）。この関係が真でない場合には、本プロセスは、このセッションがＰＱｏＳを維持することができるようにＲＢに対する要求を実行した後に、本プロセスは終了する（段階１３３６）。しかしながら、段階１３３４において判断された関係が真である場合には、本プロセスは、セッションに対して供給可能であるサービス品質を計算し、変化についてセッションに通知した後に、本プロセスは終了する（段階１３３８）。段階１３３０の説明に戻り、この段階において決定された関係が偽である場合には、本プロセスは、その他のセッションに提供可能である余剰の帯域幅を計算する。ＥＢ＝ＡＢ−ＮＢ（段階（１３４０）。次いで、本プロセスは、ＥＢ＞閾値であるかどうかを判断する（段階１３４２）。この関係が真ではない場合には、本プロセスは、ＥＢを使用可能であるその他のアプリケーションセッションに対してＥＢを提供する（段階１３４４）。しかしながら、段階１３４２において判断された関係が真である場合には、本プロセスは、ＸＱｏＳ＞ＰＱｏＳであるかどうかを判断している（段階１３４６）。この関係が真である場合には、本プロセスは、制御を段階１３３８に渡す。この関係が偽である場合には、本プロセスは、制御を段階１３４４に渡す。
【０２９８】
図１４は、利用可能な帯域幅の合計が要求された帯域幅の合計を下回っている際に帯域幅の適合化または再割り当てを実行する方式を示す図である。本プロセスは、その割り当てられている帯域幅（ＡＢ）を十分に使用していないアプリケーションから入手可能である帯域幅を合計することにより、開始する（段階１４１０）。次いで、本プロセスは、その割り当て帯域幅を上回って利用しているアプリケーションが必要としている帯域幅を合計する（ＮＢ）（段階１４２０）。次いで、本プロセスは、ＡＢ＜ＮＢであるかどうかを判断する（段階１４３０）。この関係が偽である場合には、プロセスは、図１５を参照して説明するＡＢ＞ＮＢ法を使用することにより、ＡＢを帯域幅を必要としているセッションに割り当てた後に、本プロセスは終了する（段階１４４０）。段階１４３０において決定された関係が真である場合には、本プロセスは、すべてのオープンセッションについて、最大セッション優先度Ｍａｘ（ｐ）及び最小セッション優先度Ｍｉｎ（ｐ）を計算する（段階１４４２）。次いで、本プロセスは、優先度値をｐ＝Ｍａｘ（ｐ）に設定している（段階１４４４）。次いで、本プロセスは、帯域幅を必要としている優先度ｐにおいてオープン状態にあるすべてのセッションについて、必要とされている帯域幅を合計する。Ｓｕｍ（ＮＢｐ）（段階１４４６）。次いで、本プロセスは、次の関係が真であるか偽であるかを決定する（段階１４４８）。
【０２９９】
Ｓｕｍ（ＮＢｐ）＜ＡＢ
【０３００】
この関係が偽である場合には、本プロセスは、帯域幅を必要としている優先度ｐにおけるすべてのセッションについて、帯域幅を必要としているそれぞれのセッションに対して比例するように残りのＡＢを割り当てた後に、本プロセスは終了している（段階１４５０）。段階１４４８において決定された関係が真である場合には、本プロセスは、帯域幅を必要としている優先度ｐにおけるすべてのセッションについて、ＡＢからの帯域幅を割り当てる（段階１４５２）。次いで、本プロセスは、次式を決定する（段階１４５４）。
【０３０１】
ＡＢ＝ＡＢ−Ｓｕｍ（ＮＢｐ）
【０３０２】
次いで、本プロセスは、ｐ＝ｐ−１を設定することにより、優先度値を減分する（段階１４５６）。次いで、本プロセスは、ｐ＜Ｍｉｎ（ｐ）であるかどうかを判断する（段階（１４５８）。この関係が真である場合には、本プロセスは終了する（段階１４６０）。この関係が偽である場合には、本プロセスは、制御を段階１４４６に渡す。
【０３０３】
図１５は、利用可能な帯域幅の合計が、要求された帯域幅の合計以上である際に帯域幅の適合化または再割り当てを実行する方式を示す図である。このプロセスは、その割り当てられている帯域幅を十分に使用していないアプリケーションから入手可能である帯域幅（ＡＢ）を合計することにより、開始する（段階１５１０）。次いで、本プロセスは、その割り当て帯域幅を上回って利用しているアプリケーションが必要としている帯域幅ＮＢを合計する（段階１５２０）。次いで、本プロセスは、ＡＢ＞ＮＢであるかどうかを判断する（段階１５３０）。この関係が真である場合には、本プロセスは、ＡＢ＝ＮＢであると認識し、ＡＢを、帯域幅を必要としているセッションに割り当てた後に、本プロセスは終了する（段階１５４０）。段階１５３０において決定された関係が真である場合には、本プロセスは、すべてのオープンセッションについて、最大セッション優先度Ｍａｘ（ｐ）及び最小セッション優先度Ｍｉｐ（ｐ）を計算する（段階１５４２）。次いで、本プロセスは、優先度値をｐ＝Ｍａｘ（ｐ）に設定する（段階１５４４）。次いで、本プロセスは、利用可能な帯域幅を具備する優先度ｐにおいてオープン状態にあるすべてのセッションについて、利用可能な帯域幅を合計しているＳｕｍ（ＡＢｐ）（段階１５４６）。次いで、本プロセスは、次の関係が真であるか偽であるかを判断する（段階１５４８）。
【０３０４】
Ｓｕｍ（ＡＢｐ）＜ＮＢ
【０３０５】
この関係が偽である場合には、本プロセスは、利用可能な帯域幅を持つ優先度ｐにおけるすべてのセッションについて、それらのセッションから、帯域幅ＮＢを必要としている残りのアプリケーションに対して、比例するように帯域幅を割り当てており、プロセスは、終了する（段階１５５０）。段階１５４８において決定された関係が真である場合には、本プロセスは、利用可能な帯域幅を具備した優先度ｐにおけるすべてのセッションについて、帯域幅を、帯域幅ＮＢを必要としているアプリケーションに割り当てる（段階１５５２）。次いで、本プロセスは、次式を決定する（段階１５５４）。
【０３０６】
ＮＢ＝ＮＢ−Ｓｕｍ（ＡＢｐ）
【０３０７】
次いで、本プロセスは、ｐ＝ｐ＋１を設定することにより、優先度値を増分する（段階１５５６）。次いで、本プロセスは、ｐ＞Ｍａｘ（ｐ）であるかどうかを判断する（段階１５５８）。この関係が真である場合には、本プロセスは終了する（段階１５６０）。この関係が偽である場合には、本プロセスは制御を段階１５４６に渡す。
【０３０８】
（ＱｏＳ管理）
前述のように、ある意味においては、サービス品質（ＱｏＳ）とは、サーバーアプリケーションからクライアントアプリケーションにタイムリーにデータ／イベントを正常に供給するシステムの能力を意味している。アプリケーションは、自身がそのセッションに対して所望しているサービス品質を定義可能であり、本発明のシステムは、ネットワーク事業者によって設定された制約内において、かつ、ブロードキャストシステム内のその他の活動に基づいて、これらの要求を満足させるべく試みることになる。追加のアプリケーション要求に起因し、資源が、制約された状態となることから、ブロードキャストシステムは、１以上のセッションのサービス品質を変更することにより、新しい需要を満足させると共に、その全体的なＱｏＳの義務を充足するその能力を維持する必要があろう。
【０３０９】
アプリケーションは、次の特徴の中の１以上のものを定義することにより、セッションの特定のサービス品質を要求可能である。
【０３１０】
・イベントサイズ
・イベント頻度
・誤り訂正（ＦＥＣ）
・それぞれのイベントの再送回数またはイベントのリンガー時間（再送のためにイベントがカルーセル上に留まる時間）
・イベントカルーセル上に保持されるイベントの数
・イベントのレイテンシー（イベントがクライアントに到達するのに所要する時間）
・カルーセルサイクルタイム
【０３１１】
イベントサイズとは、それぞれのイベントのバイトを単位としたサイズを意味している。アプリケーションは、固定されたまたは可変のイベントサイズを具備可能である。
【０３１２】
イベント頻度とは、新しいイベントが生成されるレートを意味している。株価表示器アプリケーションなどのいくつかのアプリケーションにおいては、イベントは、相対的に固定されたインターバルにおいて生成されている。その他のアプリケーションの場合には、イベントは、ニュースや交通アプリケーションなどのように、予想不能な時点において発生可能である。
【０３１３】
ＦＥＣなどの誤り訂正は、それぞれのイベントについてブロードキャストすることを要するデータ量を増大させるが、イベントがクライアント装置において誤りを伴うことなしに受信される確率を増大させる。
【０３１４】
再送回数とは、カルーセルから除去される前に、イベントをブロードキャストすることを要する回数を意味している。アプリケーションセッションは、ネットワークから離脱またはこれに参加する（または、さもなければ、間欠的な接続性を具備する）クライアント装置が、ネットワークから離脱している際に逃したイベントを受信する機会を具備するように、イベントを複数回にわたってブロードキャストすることを所望可能である。
【０３１５】
イベントのリンガー時間は、再ブロードキャストを規定する別の方法である。リンガー時間とは、イベントがカルーセル上に留まることを要する時間量を意味している。イベントは、カルーセル上に留まっている限り、再ブロードキャストされることになる。イベントが再ブロードキャストされる回数は、カルーセル上におけるイベントの合計数によって左右されることになる。アプリケーションは、イベントが、特定の時間量にわたって関係しており、その後には、もはや重要ではないまたは使用不能となる際に、リンガー時間を規定可能である。
【０３１６】
イベントカルーセル上に保持されるイベントの数は、特定量の履歴の提供を所望しているアプリケーションによって使用可能である。カルーセルが規定のサイズに到達したら、ブロードキャスト・サーバーは、新しいものが追加されるのに伴って古いイベントを自動的に削除することになる。
【０３１７】
イベントレイテンシーとは、イベントがクライアントによって受信されるのに所要する時間量を意味している。レイテンシーは、伝送を要するデータ量と、カルーセル内においてその前に位置しているイベントの数に依存している。
【０３１８】
カルーセルサイクルタイムとは、イベントカルーセルの全体のコンテンツをブロードキャストするのに必要な時間量を意味している。アプリケーションは、固定されたカルーセルサイクルタイムを維持すべく、そのカルーセル上のイベント数の時間に伴う変動を許容することを所望可能である。
【０３１９】
アプリケーションセッションが受け取るサービス品質は、主には、そのセッションに割り当てられている帯域幅に依存している。但し、帯域幅は、予め定義されている様々なＱｏＳ特性の実現または最適化をサポートすべく、様々な方法によって再割り当て可能である。この結果、帯域幅が変化した際に、サービス品質の様々な側面が影響を受けることになる。アプリケーションは、割り当て帯域幅が変化した際に影響を受けるサービス品質の側面及びその方式を定義可能であり、また、アプリケーションがポリシーを定義していない場合には、ブロードキャスト・サーバーが、影響を受ける側面または特性を選択可能である。
【０３２０】
一般に、アプリケーションは、特定のセッションに割り当てられている帯域幅について認識していないか、または認識する必要がない。アプリケーションは、通常、これよりも、自身が経験しているサービス品質について、並びに、更に具体的には、現在割り当てられている帯域幅がアプリケーションが関心を有している様々なサービス品質パラメータに影響を及ぼす方法について、関心を有している。例えば、アプリケーションは、イベントリンガー時間にのみ注意しているまたは最も関心を有している可能性があり、この結果、その割り当てられた帯域幅の変化がイベントリンガー時間に影響を与える方式について知ることを所望することになろう。
【０３２１】
アプリケーションセッションに割り当てられた帯域幅は、定義された期間内に伝送可能であるデータ量を決定する。この意味において、アプリケーションセッションをサポートするのに必要な帯域幅は、所望のレイテンシーと、セッションが伝送を試みるデータ量に依存している。アプリケーションが伝送するデータ量は、イベントサイズ、イベントの生成頻度、並びに、誤り訂正または複数回のデータ再伝送などのそれぞれのイベントごとに送信を要するデータ量を増大させる使用可能な様々な信頼性メカニズムに依存している。
【０３２２】
代表的な動作においては、アプリケーションは、セッションをセットアップする際には、実際の帯域幅値を要求しない可能性がある。この代わりに、アプリケーションは、（例えば、図６の説明を参照して説明したように）実際の帯域幅値に変換可能である特定のサービス品質要件を具備可能である。通常、アプリケーションにとって重要なことは、帯域幅の変化との関連においてサービス品質が変化する方式である。この理由から、アプリケーションには、特定の動作状態においてそのアプリケーションに適用される相対的なサービス品質範囲を通知可能である。例えば、１００のＱｏＳ値を割り振ることにより、アプリケーションが当初要求している所望のサービス品質を通知可能である。事業者によってセットアップされたアプリケーション要求及びアプリケーションポリシーに基づいて、ブロードキャスト・サーバーは、アプリケーションに適用されることになるサービス品質の相対的なフロア及びシーリング値を決定可能である。このアプリケーション要求が、例えば、１０Ｋｂ／ｓの帯域幅に変換され、かつ、アプリケーションを５Ｋｂ／ｓの最小値に低減または２０Ｋｂ／ｓの最大値に増大可能である場合には、初期要求の１００という相対的な値に基づいて、５０の値に低減または２００の値に増大可能であるとアプリケーションに通知可能であろう。この結果、アプリケーションは、この情報を使用することによりい、割り当て帯域幅が変動した場合にブロードキャスト・サーバーが実装するポリシーをセットアップ可能である。
【０３２３】
前述のように、セッションをセットアップする際にアプリケーションがブロードキャスト・サーバーに提供するサービス品質要件は、多少、アプリケーションが提供しているサービスのタイプに依存している。イベントストリームサービス、通知サービス、及びデータオブジェクト供給サービスという３つのタイプのアプリケーションのそれぞれごとに、通常は最大の関心事である１以上の関連するＱｏＳパラメータが存在している。イベントストリームサービスにとって通常重要であるサービス品質パラメータは、平均イベントサイズ及び頻度と、所望のイベントレイテンシー及びリンガー時間を含んでいる。通知サービスにとって通常重要であるサービス品質パラメータは、通知を供給するための最大通知サイズ、所望のレイテンシー、及び最大レイテンシーである。データオブジェクト供給サービスにとって通常重要であるサービス品質パラメータは、平均オブジェクトサイズ、カルーセル上に含まれるオブジェクトの平均数、及び所望のオブジェクトレイテンシーを含んでいる。
【０３２４】
図６を参照して説明したように、セッションをセットアップまたは変更する際には、アプリケーションは、アプリケーションが所望する予想サービス品質レベルのサービス品質パラメータを提供可能である。これは、サービス品質は、帯域幅の優先使用に起因し、そのレベル未満に一時的に低下可能であるという理解の下に、通常、アプリケーションが正常に動作するのに必要なベースラインサービス品質レベルを定義している。更には、アプリケーションは、アプリケーションが通常動作することを所望しているサービス品質レベルを供給可能であり、これは、予想サービス品質を上回るものであってよい。また、アプリケーションは、自身が利用可能である最大サービス品質値と、自身が動作可能である最低保証サービス品質を規定することも可能である。これらの追加サービス品質値は、通常、予想サービス品質との関係において規定されている。例えば、イベントストリーミングセッションをオープンしているアプリケーションは、次のように、その予想サービス品質を規定可能である。
【０３２５】
平均イベントサイズ：  １Ｋｂ
平均イベント頻度：  ２イベント／秒
予想レイテンシー：  ５秒
予想リンガー時間：  １０秒
【０３２６】
これらの要件が、例えば、１００の値などのサービス品質のベースレベルに対応することになると知ることにより、アプリケーションは、任意選択により、追加の相対的なサービス品質要件を次のように規定可能である。
【０３２７】
所望のサービス品質：  １５０
最大使用可能サービス品質：  ２００
最小保証サービス品質：  ５０
【０３２８】
セッションマネージャは、これらのＱｏＳレベルを評価することにより、アプリケーションが要求したそれぞれのサービス品質レベルに対応した実際の帯域幅レベルを決定することになる。それらの実際の帯域幅レベルに基づいて、セッションマネージャは、ＱｏＳレベル要求をアプリケーションと関連するアプリケーションポリシーと比較することにより、予想最小保証及び最大帯域幅要件を満足可能であるかどうかを決定可能である。最小帯域幅要件を満足することができない場合には、セッション要求は、拒絶されることになり、どのポリシーの制約によって拒絶が発生したのかについて、アプリケーションにフィードバックが提供される。最小帯域幅要件を満足可能である場合には、セッションマネージャは、アプリケーションの要件及び関連するアプリケーションポリシーに基づいて、セッションに対して供給可能な最大サービス品質を演算することになる。
【０３２９】
最大ＱｏＳレベルは、利用可能であるとアプリケーションが規定したものを下回る可能性があることに留意する。現在定義されているその他のアプリケーションセッションに対する現在の帯域幅割り当てに基づいて、セッションマネージャは、アプリケーションに最初に付与された実際の帯域幅を割り当てることになる。次いで、セッションマネージャは、アプリケーションに割り振られたサービス品質レベルをアプリケーションに提供するが、これは、アプリケーションが規定した予想サービス品質と関係したものとなる。例えば、ブロードキャスト・サーバーは、予想サービス品質に対応するように値１００を割り当て、かつ、その他のサービス品質レベルの相対的な値をアプリケーションに返すことが可能である。
【０３３０】
【表１３】
2009525641.tif 000028
【０３３１】
予想されるように、新しいアプリケーションセッションは、セットアップされた際に、その他のアプリケーションのセッションに割り当てられた帯域幅に影響を付与可能である。新しいセッションは、帯域幅の割り当てを要求することになり、その帯域幅の一部または全部は、その他のセッションから到来する必要があろう。アプリケーションがそのセッションパラメータを変更した際にも、同一の状況が発生可能である。変更は、更に大きなまたは更に小さな帯域幅の要求を結果的にもたらす可能性があり、この場合に、余剰の帯域幅が、その他のセッションから到来することを要する可能性があり、あるいは、システムに返された帯域幅をその他のセッションに割り当てる可能性もある。同様に、アプリケーションセッションがクローズされた際にも、そのセッションによって使用されていた帯域幅をその他のセッションに割り当て可能である。
【０３３２】
前述のように、アプリケーションは、セッションの割り当て帯域幅の変化についてアプリケーションに伝達できるように、セッションをセットアップする際に、コールバック機能を供給可能である。通知された際に、アプリケーションは、このフィードバックに基づいてその動作を変更すべく選択可能である。これは、アプリケーションがブロードキャストしているイベントのサイズ及び頻度を変更するステップ、または影響を受けたセッションに適用すべく異なるサービス品質パラメータの組をセッションマネージャに供給するステップを伴うことになろう。あるいは、この代わりに、アプリケーションは、セッションの割り当て帯域幅が変化した際にブロードキャスト・サーバーが実装するポリシーをセットアップすることを所望する可能性もある。これを実行する１つの方法は、アプリケーションが、その初期のサービス品質パラメータ値を規定すると共に、サービス品質の変化に伴ってそれらの値を変更するのに使用する方法を提供するか、またはアプリケーションに適用可能である様々なサービス品質レベルにおけるパラメータの値を明示的に供給するというものである。
【０３３３】
前述のように、様々な種類のアプリケーションセッションは、様々なサービス品質の側面を規定可能であり、この理由は、これらの側面が、そのタイプのアプリケーションに最も関係しているからである。例えば、イベントストリームサービスが規定可能であるのは、新しいイベントの所望の平均レイテンシーのみである。データオブジェクト供給サービスは、イベントカルーセル上に維持されているオブジェクトのリンガー時間の規定に対して、より大きな関心が有していよう。緊急事態通知サービスは、豊富なイベントを短い期間において可能な限り多数回にわたって再ブロードキャストした後に、そのイベントの短縮バージョンを相対的に長い期間にわたって相対的に低いレートでブロードキャストすることを必要としよう。
【０３３４】
（ＱｏＳレベルの変化の管理）
アプリケーションセッションの割り当て帯域幅が、システム内のその他のアプリケーションセッションのニーズに起因して減少した場合には、そのセッションが受け取るサービスの品質を低減する必要があろう。サービス品質の低減を実装可能である方法には、いくつかのものが存在している。２つの基本的な方法は、レイテンシーを増大させると共に／または、ブロードキャストすることを要するデータ量を低減するというものである。
【０３３５】
レイテンシーを増大させる方法は、変化についてアプリケーションセッションに通知する以外に対策を必要としないことから、相対的に簡単である。イベントは、新しい更に小さな割り当て帯域幅においてブロードキャストされ、この結果、アプリケーションは、新しいイベントを生成する頻度を低減する必要があろう。この理由は、さもなければ、ブロードキャスト可能なものを上回る頻度で新しいイベントが生成された場合に、レイテンシーが継続的に増大する可能性があるためである。
【０３３６】
ブロードキャストすることを要するデータ量の低減は、いくつかの方法によって実現可能である。これらの方法には、次のように、イベントの頻度またはサイズの低減を伴うものもあり、そうでないものもある。
【０３３７】
・ＦＥＣなどの誤り訂正を使用するセッションの場合には、誤り訂正を中止することにより、それぞれのイベントごとにブロードキャストすることを要するデータ量が低減されることになる。
【０３３８】
・また、イベントのリンガー時間を低減することにより、送信を要するデータ量が低減されることになる。それぞれのイベントがカルーセル上において消費する時間が減少し、従って、再ブロードキャストされる回数が低減されることになる。また、イベントが再ブロードキャストされる回数を明示的に低減することにより、これを実現することも可能である。
【０３３９】
・イベントカルーセル上に保持するオブジェクトの数を規定しているアプリケーションセッションの場合には、この数を低減することにより、ブロードキャストすることを要するデータの合計量も低減されることになる。
【０３４０】
・また、アプリケーションは、ブロードキャストすることを要するデータ量を低減すべく、イベントを送信する頻度を自発的に低減するかまたはイベントサイズを低減可能である。いくつかの状況においては、ブロードキャスト・サーバーは、小さな割り当て帯域幅と大きなカルーセルサイズの組み合わせによって正当化される場合には、新しいイベントの受け入れを拒絶可能である。
【０３４１】
サービス品質の変化を管理可能であるいくつかの方法に起因し、アプリケーションは、アプリケーションセッションに割り当てられた帯域幅が変化した際にブロードキャスト・サーバーが実装するポリシーを定義可能である。一例として、ブロードキャスト・サーバーは、以下の段階を適用することにより、帯域幅の変化に基づいてアプリケーションのサービス品質を変更可能である。
【０３４２】
１．現在の利用可能な帯域幅に対応した相対的なサービス品質値を演算する。この値は、アプリケーションが当初要求した予想サービス品質と、その要求が対応している実際の帯域幅に関係している。
【０３４３】
２．先程演算した対応するサービス品質値について変更可能であるサービス品質パラメータを通知するサービス品質ポリシーをアプリケーションが定義している場合には、アプリケーションによって規定されている対策を実行し、その対策についてアプリケーションに通知する。あるいは、
【０３４４】
３．実施するべき自動的な対策についてアプリケーションが規定していない場合には、サービス品質が先程演算された値に変化したことをアプリケーションに通知し、かつ、新しいレベルをサポートすべくサービス品質パラメータを変更する機会をアプリケーションに付与する。
３−ａ．アプリケーションが対策を実施した場合には、レイテンシーを増大させなければならない場合にも、セッションのカルーセルに既に追加されたイベントが少なくとも１回だけブロードキャストされることを保証する既定のアルゴリズムを使用することにより、サービス品質パラメータを変更し、かつ、カルーセルサイズがなんらかの最大サイズに到達した場合には、新しいイベントを拒絶する。
【０３４５】
帯域幅再割り当ての状況においてＱｏＳの低下を実装する方法は、セッションを最初にセットアップする際に予め定義しておくことも可能であり、あるいは、アプリケーションによってリアルタイムに決定することも可能である。セッションのセットアップの際に予め定義した場合には、ブロードキャスト・サーバーが、アプリケーションセッションの大部分のＱｏＳの変化を処理することになる。例えば、アプリケーションセッションは、次の特性を規定可能である。
【０３４６】
イベントレート：２イベント／秒
イベントサイズ：１Ｋｂ
ＦＥＣ：はい（イベントのサイズを倍増させる）
それぞれのイベントのブロードキャスト回数：５回
所望のレイテンシー：１秒
【０３４７】
初期要求に基づいて、適用可能なポリシー及び現在の帯域幅割り当てが許容していると仮定した場合に、このアプリケーションセッションには、２０Ｋｂ／ｓの帯域幅が割り当てられることになる。ＦＥＣにより、それぞれのイベントブロードキャストは、２Ｋｂとなる。２イベント／秒において、アプリケーションは、４Ｋｂ／ｓをカルーセルに追加することになる。それぞれのイベントは、５回ずつブロードキャストされるため、５＊４Ｋｂ／ｓ、即ち、実際には、２０Ｋｂ／ｓがカルーセルに追加されることになる。１秒の所望のレイテンシーの場合には、カルーセルは、イベントを２０Ｋｂ／ｓで伝送することが必要になる。
【０３４８】
このアプリケーションの最小保証帯域幅が１Ｋｂ／ｓである場合には、アプリケーションは、更に高い優先度のイベントがシステムに進入した場合に、その割り当て帯域幅をこのレベルに降下させるべく準備しておく必要がある。割り当て帯域幅は、システム内のその他の活動に応じて、１Ｋｂ／ｓと、最初に割り当てられた２０Ｋｂ／ｓの間において変動可能であることに留意する。この例の場合には、アプリケーションは、２０Ｋｂ／ｓを上回る追加帯域幅を利用することにはならないものと仮定する。
【０３４９】
この例においては、２０Ｋｂ／ｓの予想帯域幅に対応した初期要求の１００というＱｏＳ値と、１Ｋｂ／ｓの最小保証帯域幅に対応した５というＱｏＳ値がアプリケーションに返されることになる。
【０３５０】
前述のように、アプリケーションは、ＱｏＳ変更ポリシーを定義することにより、帯域幅の変動を処理可能である。アプリケーションは、その保証最小帯域幅に対応した５未満の相対的なＱｏＳ値を自身に割り当てることは不可能であることを知っている。追加帯域幅を使用しないというアプリケーションの通知に基づいて、アプリケーションは、その予想帯域幅に対応した１００を上回るＱｏＳ値も受領しない。従って、アプリケーションは、５〜１００の範囲において変化するＱｏＳパラメータを定義する必要があろう。可能なＱｏＳ変更ポリシーの一例は、次のとおりである。
【０３５１】
【表１４】
2009525641.tif 000029
【０３５２】
このＱｏＳ変更ポリシーが付与された場合に、ブロードキャスト・サーバーは、次のように、ＱｏＳを２Ｋｂ／ｓに低減すべく試みることになる。
【０３５３】
【表１５】
2009525641.tif 000030
【０３５４】
動作の際には、割り当てられた帯域幅が２Ｋｂ／ｓ未満になった場合には、ブロードキャスト・サーバーは、イベントレイテンシーが増大し始めることにはなるが、新しいイベントのカルーセル上への継続的な配置を許容する。レイテンシーが１０秒を超過しない限り、ブロードキャスト・サーバーは、新しいイベントを受け入れる。割り当て帯域幅の低減が、レイテンシーが１０秒を超過しない十分に短い時間においてのみ継続した場合には、イベントをドロップする必要はない。割り当て帯域幅の増大に伴って、ブロードキャスト・サーバーは、先程の表に従ってブロードキャストまたはＦＥＣの追加を検討する前に、レイテンシーが１秒に低減される時点まで待つことになる。割り当て帯域幅の低減が、レイテンシーを１０秒に増大させるのに十分なほどに長時間継続した場合には、ブロードキャスト・サーバーは、レイテンシーを１０秒の最大値に維持するのに必要とされるように、新しいイベントを拒絶することになる。
【０３５５】
アプリケーションには、割り当て帯域幅のそれぞれの変化と、有効なポリシーに従ってアプリケーションの代わりにブロードキャスト・サーバーが実行したＱｏＳの変化について通知されることになる。アプリケーションは、この情報を使用することにより、その動作を変更するか、ブロードキャストしているイベントのコンテンツを変更するか、またはＱｏＳポリシーを変更可能である。ＱｏＳレベル管理ポリシーが定義されている場合には、ブロードキャスト・サーバーが、セッションがセットアップされた際に定義されたポリシーに基づいてＱｏＳの変化を自動的に処理するため、アプリケーションが対策を実行する必要はない。
【０３５６】
（システムによってサポートされている追加の動作及び管理機能）
ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、例えば、順序どおりのイベントの供給などのデータ及びイベントのブロードキャスト及び供給における価値を提供するその他の動作及び管理機能をもサポートしている。イベントがデータカルーセルを使用してブロードキャストされており、かつ、クライアントは、任意の地点または時点においてブロードキャストの受信を開始可能であるため、クライアントは、イベントを誤った順序で受信する可能性である。この場合には、ブロードキャスト・クライアント・ツールキットは、先行するイベントを逃したことを検出し、先行するイベントが受信される時点まで、イベントをキャッシング可能である。受信した後に、すべてのイベントを意図する順序において１以上のアプリケーションに供給可能である。これを実現すべく、ブロードキャスト・サーバーは、ブロードキャストするそれぞれのイベントにイベントＩＤを付加可能である。この結果、ブロードキャスト・クライアント・ツールキットは、イベントをクライアントアプリケーションに送信する前に、イベントＩＤを調べることにより、自身がすべての先行するイベントを受信しているかどうかを決定可能である。
【０３５７】
クライアントが、すべての先行するイベントが（再）ブロードキャストされていない地点においてイベントの受信を開始したり、一時的にネットワークから離脱して過剰な範囲を逃したりして、逃したすべてのイベントを受信することが不可能であるという状況が存在する可能性がある。このような状況においては、ブロードキャスト・クライアント・ツールキットは、自身がすべての先行するイベントに対するアクセスを有することにならないことを認識し、自身がキャッシングしておいた先行するイベントをクライアントアプリケーションに伝達するステップを開始する必要があろう。これは、いくつかの方法の中の１つによって実現可能である。ブロードキャスト・サーバーは、カルーセル上における最も早期のイベントのＩＤをそれぞれのイベントに付加可能である。ブロードキャスト・クライアント・ツールキットは、この情報を使用することにより、クライアントアプリケーションへのイベントの送信を開始する時期を決定可能である。代替方法は、現在カルーセル上に存在しているものについて記述したコンテンツテーブルをブロードキャスト・サーバーが送信するというものであろう。ブロードキャスト・クライアント・ツールキットは、この情報を使用することにより、取得可能なイベントを決定し、相応して動作可能である。また、誤った順序で受信したイベントを無視する必要があるとアプリケーションが規定することも可能である。この場合には、既に受信及び処理済みのイベントよりも先行するＩＤを具備したイベントをブロードキャスト・クライアント・ツールキットが受信した場合には、そのイベントを破棄可能である。
【０３５８】
ＱｏＳの変化について通知された際には、ブロードキャストされているイベントのタイプをアプリケーションが変更することが必要になる可能性があることに留意する。例えば、アプリケーションの割り当て帯域幅が大幅に低下した場合には、アプリケーションは、以前に使用していたもの以外の異なるイベントストリームを使用する動作モードに入ることを決定可能である。以前にブロードキャストされたイベントをカルーセルからクリアするには、多少の時間を所要することになるため、新しいイベントストリームを可能な限り迅速にサポートできるように、アプリケーションには、カルーセル内のすべてのイベントを即座に削除する能力を付与可能である。
【０３５９】
ブロードキャスト・サーバーによって提供可能な別の機能は、イベントの置換である。これは、イベントが別のイベントに取って代わる際に有用である。このような場合に、同一時点においてデータカルーセル上に古いイベントと新しいイベントの両方を具備することは、資源の非効率的な使用法である。例えば、株価表示器アプリケーションにおいては、株式は、アクティブに取り引きされている可能性がある。アプリケーションは、ネットワークに出入りするクライアントをサポートすべく、データカルーセル上に、その価格が変化した最新の５０種類の株式について株式価格の変化を具備可能である。新しい価格情報をブロードキャストする必要がある際に株価情報が既にカルーセル上に存在している場合には、ブロードキャスト・サーバーは、同一時点においてカルーセル上に両方の価格情報を具備することを回避すべく、既存の価格情報を新しいものによって置換可能である。連番を使用することにより、クライアントが古い価格情報を使用しないようにするという目的を実現することは可能であるが、古い価格情報と新しい価格情報の両方が保存及びブロードキャストされるため、これは、結果的に、帯域幅の非効率的な使用法をもたらすことになろう。
【０３６０】
ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、特定のタイプのアプリケーションに対して更なるコンテンツ供給支援を提供可能であることに留意する。この支援は、完全かつ増分的な状態管理を包含可能である。特定のタイプのアプリケーションは、なんらかの相対的に静的な状態に対する変更である頻繁な更新イベントを送信している。これらの更新イベントは、完全なアプリケーション状態と比べて、小さいものである。完全なアプリケーション状態は、相対的に静的な状態に留まっており、更新が生成される際に、その中の小さな部分が変化しているのみである。このようなアプリケーションの例が、ブロードキャストスポーツイベント、リアルタイム選挙結果、並びに、通勤スケジュール及び状態を含んでいる。スポーツアプリケーションの場合には、頻繁な更新は、個々のプレイ、得点の変化、またはプレーヤーの入れ替えであろう。相対的に静的な状態は、スコアボードなどの全体的な試合の状態、現在のプレーヤー、及びチームの概要であろう。選挙結果の場合には、頻繁な更新は、ローカルな候補者の投票数または話題であろう。相対的に静的な状態は、全国レベルの共和党及び民主党の獲得議席数や、ローカルな予想結果であろう。通勤スケジュールの場合には、頻繁な更新は、実際の列車、バス、または飛行機の到着または出発時刻であろう。相対的に静的な状態は、列車、バス、または飛行機のスケジュール自体であろう。
【０３６１】
このようなアプリケーションによって対処することを要する共通的な課題は、ブロードキャストの途中においてネットワークに参加するクライアント、またはブロードキャストの聴取を一時的に停止し、後から再度参加すべく試みるクライアントの処理である。このようなクライアントは、アプリケーションの現在の状態の完全なバージョンを取得する必要があり、新しい更新イベントの監視を開始する必要がある。更新は、通常、ベースラインを伴うことなしには、有意なものにならず、ベースラインそれ自体またはそれ単独では、クライアントを完全に最新の状態にするのに十分ではない。ベースラインアプリケーション状態を取得すると共に、すべての関連する更新を追跡する必要があるため、慎重な計画を伴うことなしには、クライアントがキャッチアップするのに長時間を要するか、またはこれが不可能であろう。
【０３６２】
完全な状態及び更新（増分）イベントのブロードキャストに使用される方法は、多少、アプリケーションが利用可能である帯域幅に依存している。例えば、相対的に大きな帯域幅を利用可能である際には、完全な状態は、相対的に頻繁にブロードキャスト可能であり、更新イベントは、最後の完全な状態以降のすべての変化を包含可能である。帯域幅が限られている際には、完全な状態は、頻繁に送信不可能であり、更新イベントは、通常、小さなサイズに維持されることになろう。このような場合には、更新イベントは、単一の更新のみを包含しており、かつ、すべての以前の更新イベントの正常な受信に依存する可能性がある。ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、アプリケーション自体が帯域幅の変化に反応することを必要とすることなしに、利用可能な現在の帯域幅に基づいてプロセスの最適化を提供可能である。この結果、ブロードキャスト・サーバーは、完全な状態及び更新イベント情報を供給するための最良の方法を決定可能である。
【０３６３】
クライアントアプリケーションがイベントストリームの受信を開始する際には、動作を正常に開始するのに十分な状態情報を再構成するのにある程度の時間をかけることができる。また、クライアントアプリケーションが、ネットワークまたはその他のクライアント固有の状態に起因して遅延し、正常に動作できない場合も存在可能である。このような場合には、クライアントを迅速に最新の状態にすることができるように、ブロードキャスト・サーバーに対するポイントツーポイント接続によってクライアントに自身を対話的に更新させることが望ましいであろう。多数のクライアントがこの修復を同時に試みた結果、ネットワークがこのような要求によって輻輳する状況を回避すべく、利用可能である場合には、この機能を適切にサポートする必要がある。これを実現するための１つの方法は、クライアントが対話型更新を試みることができる時期を通知する情報をアプリケーションイベントストリームに包含するというものであろう。この機能は、プレミアム加入者に制限することも可能であり、この場合には、ネットワーク上に生じる追加の需要を追加料金によって負担することになる。
【０３６４】
増分更新及び状態管理に関する課題の以上の説明から明らかなように、本発明のシステムが通常動作している環境において対処を要する課題は、一連のデータの組のブロードキャストの途中においてネットワークに参加するクライアント、または、ブロードキャストの聴取を一時的に停止し、その後に再度参加すべく試みるクライアントの処理である。このようなクライアントは、通常、アプリケーションの現在の状態の完全なバージョンを取得すると共に、更新イベントに関するデータブロードキャストの監視を開始することが必要になる。更新は、通常、ベースラインを伴うことなしには、有意なものにならず、かつ、ベースラインそれ自体またはそれ単独では、クライアントを完全に最新の状態するのに十分ではないことに留意する。
【０３６５】
ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、このような状況をサポートすると共に、ブロードキャストに参加するクライアントが、ブロードキャストの全体を通じて、迅速にキャッチアップし、最新の状態に留まることを保証するための効率的な方法を提供可能である。これは、それぞれのアプリケーションが、ブロードキャストの途中において参加するまたはブロードキャストの最中に離脱して（再）参加するクライアントを処理するためのその独自のメカニズムを考案する必要性を軽減している。本発明のシステムの一実施形態においては、これは、相対的に静的な状態用の１つのブロードキャストセッションと、更新イベント用の別のブロードキャストセッションを提供することにより、実現される。この結果、ブロードキャストの途中において参加または再参加するクライアントは、アプリケーションの現在の完全な状態を構築すべく、両方のセッションからデータを取得することになろう。一旦最新の状態になった後には、更新を更新イベントセッションから取得することになるため、クライアントは、状態セッションからのデータをめったに使用しないことになる。この理由から、通常は、最良のサービス品質をクライアントアプリケーションに提供すべく、更新イベントセッションに相対的に高い優先度を割り振ることになろう。
【０３６６】
アプリケーションは、アプリケーションの完全な状態を構成する別個のデータコンポーネントを定義可能である。コンポーネントは、ブロードキャストイベントにおいて追加または削除可能である。これらのコンポーネントは、必要に応じたコンポーネントのブランチの削除を円滑に実行すべく、階層的な方式によって定義可能である。更新イベントは、１つまたは少数のコンポーネントに影響を与えることになるため、アプリケーション定義コンポーネントのコレクションは、相対的に静的な状態であると見なすことができる。コンポーネントが変化した際には、アプリケーションは、新しいコンポーネント値をブロードキャスト・サーバーに提供することになろう。次いで、ブロードキャスト・サーバーは、そのコンポーネントの新しい更新がアプリケーションによって生成される時点まで、特定の期間にわたって、相対的に高い優先度の更新イベントセッション上において更新をブロードキャストし、かつ、相対的に低い優先度のデータオブジェクトセッション上において、コンポーネントをブロードキャストすることになろう。
【０３６７】
この方法によれば、サーバー側アプリケーションは、１．完全なアプリケーション状態を構成するすべてのコンポーネントを定義し、２．変化したコンポーネントの更新イベントを提出することにより、変化したコンポーネント及びその新しい値を通知すると共に、３．必要に応じて、アプリケーション状態コンポーネントを追加または除去することになろう。
【０３６８】
同様に、クライアント側アプリケーションは、１．それが、古くなっており、かつ、受信されるすべての状態コンポーネントを必要としていることをブロードキャスト・クライアント・ツールキット（ＢＣＴ）に通知し、２．それが、最新の状態になっており、その結果、更新イベントのみが必要であることをＢＣＴに通知することになろう。
【０３６９】
この結果、ブロードキャスト・サーバーは、次の段階を実行することにより、アプリケーションをサポートすることになろう。
【０３７０】
１．低優先度を有するデータオブジェクト供給セッションを生成する。
１−ａ．それぞれのコンポーネントの最新のバージョンをデータカルーセル上に配置する。
【０３７１】
２．イベントストリームセッションを生成する。
２−ａ．データオブジェクト供給セッションとの関連において相対的に高いＱｏＳパラメータを規定する。
【０３７２】
３．定義されたそれぞれのアプリケーションコンポーネントごとに、そのコンポーネントの最新バージョンを保存する。
３−ａ．新しい及び削除済みのコンポーネントについてＢＣＴに通知する。
【０３７３】
４．新しい更新がポスティングされた際に、
４−ａ．データオブジェクト供給セッションからの対応するコンポーネントを置換し、
４−ｂ．イベントストリームセッション上にイベントを配置する。
【０３７４】
同様に、ブロードキャスト・クライアント・ツールキットは、次の段階を実行することにより、アプリケーションをサポートすることになろう。
【０３７５】
１．それぞれのコンポーネントごとに、クライアントが受信したそのコンポーネントの最新バージョンを通知するテーブルをセットアップし、この場合に、
１−ａ．テーブルは、以下の方法によって構築及び維持される。
１−ａ−ｉ．テーブル内にまだ存在していない識別子を具備したコンポーネントまたはイベントを受信した場合には、新しいエントリをテーブルに追加し、
１−ａ−ｉｉ．値を持たないイベントを受信した場合には、そのコンポーネントを、階層構造が定義されている場合には、その子と共に、テーブルから削除する。
【０３７６】
２．データオブジェクトセッション及びイベントストリームセッションの両方を聴取し、
【０３７７】
３．コンポーネントまたは更新イベントを受信した際には、
３−ａ．バージョン番号に注目し、これをテーブル内のバージョン番号と比較し、
３−ｂ．受信したコンポーネントまたは更新イベントのバージョン番号が、そのコンポーネントについてテーブル内に保存されているものよりも新しいか、あるいは、このイベントまたはコンポーネントが、受信されておらず、かつ、アプリケーションが、自身が古くなった状態にあると通知した場合には、
３−ｂ−ｉ．テーブル内のバージョン番号を更新し、
３−ｂ−ｉｉ．イベントまたはコンポーネントをクライアントアプリケーションに転送する。
【０３７８】
この方法の例として、毎日の得点及びスケジュールと現在進行中の野球の試合に対するリアルタイム更新を提供する野球データキャストアプリケーションを検討する。野球アプリケーションは、次のように、様々なタイプのデータを送信する必要がある。
【０３７９】
・その日の試合のスケジュール
・それぞれの試合に関する情報
・試合がまだ開始していない場合：
・試合時間、場所、球場の状態、スターティングメンバ
・試合が終了している場合：
・得点、勝利投手、試合の概要などの最終的な試合の概要
・試合が進行中である場合：
・現在のスコアボード
・イニングごとの得点、合計得点、ヒット及びエラー
・イニングの概要
・現在の投手、出塁状況、アウトカウント、前の打者の結果
・打席の概要
・個々の投球場所、現在のカウント、現在の打者
【０３８０】
野球アプリケーションの完全な状態は、以上において列挙されたデータを含んでいるが、任意の時点において、データの特定の部分のみが変化可能である。この状況に対処すべく、野球アプリケーションは、次のコンポーネントを定義可能である。
【０３８１】
・毎日の試合スケジュールレコード
・その日にスケジューリングされているそれぞれの試合のレコード
・試合が始まっていない場合には、このレコードは、試合時間、場所、球場の状態、スターティングメンバなどの試合情報を含むことになる。
・試合が終了している場合には、このレコードは、得点、勝利投手、及び試合のハイライトなどの最終的な試合の概要を含むことになる。
・試合が進行中である場合には、このレコードは、イニングごとの得点、合計得点、ヒット及びエラーと共に、現在の試合のスコアボードを含むことになる。
・進行中のそれぞれの試合のイニングの概要
・進行中のそれぞれの試合の打席の概要
【０３８２】
アプリケーションの開始時点において、野球アプリケーションは、毎日の試合のスケジュールコンポーネントと、その日のそれぞれの試合のコンポーネントを定義することになろう。様々な野球の試合の開始及び終了に伴って、野球アプリケーションは、イニング及び打席の概要コンポーネントを追加または削除することになる。コンポーネントのセットアップの後に、野球アプリケーションは、それらの変化に伴って新しいコンポーネント値をブロードキャスト・サーバーに提供することになろう。ブロードキャスト・サーバー及びブロードキャスト・クライアント・ツールキットは、クライアントが、ブロードキャストに参加するのに伴って最新の状態になると共に、すべての試合について最新の情報によって最新の状態に留まることができるように、前述の方法を使用して協働することになろう。
【０３８３】
ネットワーク内において稼動しているクライアント装置に対してイベント及びデータを配布するためのクライアント−サーバーアーキテクチャについて説明した。このシステムは、通常、無線ネットワーク上におけるブロードキャスト手段により、通知、イベント、及びその他の形態のデータをクライアント装置に配布するブロードキャストデータ転送モードを使用している。アプリケーションは、サーバーに登録することにより、イベント／データを提供しており、クライアント装置上において稼動しているアプリケーションは、登録することにより、これらのイベント／データを受信している。本システムは、アプリケーション及びデータブロードキャストセッションに対して帯域幅を割り当てるためのプロセスを含んでおり。この場合に、定義された帯域幅限度及び関係に従って、初期割り当てをシステムによって変更することにより、追加帯域幅を必要としているアプリケーションの相対的に効率的な動作を実現可能である。また、本システムは、帯域幅の再割り当てが実行された際に、アプリケーションにとって重要であるサービスの品質メトリックを維持するまたはこれに対する影響を最小限に留めることができるプロセスをも含んでいる。
【０３８４】
その特徴、利益、及び利点の例として、本発明のシステムは、次のものを提供している。
【０３８５】
動的なイベントスケジューリング：それぞれのアプリケーションセッションにおいてイベントを送信するレートを現在のアプリケーションの活動に基づいて変更する能力である。これは、複数のアプリケーションセッションからのすべてのイベントについてリアルタイムでイベント優先度を割り振るステップを伴っており、これについては、イベント・スケジューラ要素を参照して説明している。
【０３８６】
複数のクライアントアプリケーションが同一の供給源からイベントを受信する能力：この結果、複数のクライアントアプリケーションに対して同一のイベントストリームを送信する必要性が除去され、帯域幅の消費量が低減される。
【０３８７】
ブロードキャストネットワークを使用しているアプリケーションからの帯域幅要件、パケットサイズ、ＦＥＣ、及び再送などのブロードキャスト伝送の詳細事項の効率的な抽出。
【０３８８】
サービス品質を低下させる方法：これは、有効な帯域幅が低減された際に、レイテンシー、ＦＥＣ、再ブロードキャスト回数などのパラメータを規定することにより、イベントストリームの処理方法を規定する能力をアプリケーションに対して提供する。この機能については、サービス品質の議論を参照して説明する。
【０３８９】
その現在のサービス品質を維持するためにその現在の帯域幅を必要としていないアプリケーションから、その現在のサービス品質をサポートするために追加の帯域幅を使用可能であるアプリケーションに対して帯域幅を再割り当てする適応型の帯域幅再割り当てプロセス。
【０３９０】
一実施形態においては、無線ネットワーク内において動作するモバイル装置に対してデータまたはイベントをブロードキャストしている環境において、本発明について説明しているが、これは、その他の環境においても同様に利用可能であることを理解されたい。例えば、本発明のシステム、装置、及び方法は、「同時放送」ポイントツーポイント型データ転送モードにおいても利用可能であり、この場合には、ネットワーク事業者は、それぞれのクライアント−サーバー接続の帯域幅使用量の制御に関心を有している。この場合には、いくつかの状況において、複数のアプリケーションが、同時放送を受信しているそれぞれの装置の同一の限られたポイントツーポイント資源について競合する可能性があるため、本明細書に記述されている帯域幅割り当て及び適合化方法を適用可能であり、かつ、これが有益であろう。
【０３９１】
更には、ブロードキャストデータ転送モードまたはポイントツーポイントデータ転送モードのいずれを使用するのかとは無関係に、本発明は、限定を伴うことなしに、携帯電話機、ＰＤＡ、スマートフォン、ラップトップコンピュータ、情報キオスク、ＡＴＭ装置などを含む各種モバイル、セミモバイル、または場所固定型装置において利用可能である。同様に、本発明は、携帯電話ネットワークまたはインターネットなどの固定高速双方向ネットワークなどの無線または有線ネットワークにおいても使用可能である。更には、ブロードキャストまたはポイントツーポイントデータ転送の環境において、前述のタイプのクライアント装置またはネットワークのいずれかと共に、本明細書に記述されている資源割り当て方法を使用することにより、アプリケーションまたはアプリーションのグループの帯域幅を割り当てると共に／または、所望のレベルのサービス品質を確立または制御可能である。
【０３９２】
前述の本発明の特定の要素は、コンピュータソフトウェアを使用する制御ロジックの形態においてモジュラー方式または統合された方式で実装可能であることを理解されたい。本明細書に提供されている開示及び教示内容に基づいて、当業者であれば、ハードウェア及びハードウェアとソフトウェアの組み合わせを使用して本発明を実装するその他の方法及び／または方法を認識し理解するであろう。
【０３９３】
本出願に記述されているソフトウェアコンポーネントまたは機能は、いずれも、例えば、従来のまたはオブジェクト指向の技法を使用した、例えば、Ｊａｖａ、Ｃ＋＋、またはＰｅｒｌなどの任意の適切なコンピュータ言語を使用することにより、プロセッサによって実行されるソフトウェアコードとして実装可能である。ソフトウェアコードは、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブまたはフロッピーディスクなどの磁気媒体、またはＣＤ−ＲＯＭなど光学媒体などのコンピュータ可読媒体上に一連の指示または命令として保存可能である。このような任意のコンピュータ可読媒体は、単一の演算装置上にまたはその内部に存在可能であり、システムまたはネットワーク内の異なる演算装置上にまたはその内部に存在可能である。
【０３９４】
以上、特定の例示的な実施形態について詳細に説明すると共に、添付の図面に図示したが、これらの実施形態は、例示を目的としたものに過ぎず、かつ、広範な本発明を制限することを意図したものではなく、当業者であれば、様々なその他の変更を想起可能であることから、本発明は、図示及び説明した特定の構成及び構造に限定されるものではないことを理解されたい。
【０３９５】
本明細書に使用されている「１つの」（「ａ」、「ａｎ」、または「ｔｈｅ」）は、特記されていない限り、「少なくとも１つの」（「ａｔ  ｌｅａｓｔ  ｏｎｅ」）を意味すべく意図されている。
【図面の簡単な説明】
【０３９６】
【図１】本発明のシステムアーキテクチャの主要機能要素を示すブロックダイアグラムである。
【図２】本発明のブロードキャスト・サーバー要素の主要機能要素を示すブロックダイアグラムである。
【図３】本発明のブロードキャスト・クライアント・ツールキットの主要機能要素を示すブロックダイアグラムである。
【図４】ブロードキャスト・サーバー要素を通じたイベントの代表的なフローを示す図である。
【図５】ブロードキャスト・クライアント・ツールキット要素を通じたイベントの代表的なフローを示す図である。
【図６】本発明の一部として利用可能であるアプリケーションセッションを生成するプロセスを示す図である。
【図７】セッションが生成または変更される際に予想帯域幅チェックを実行するプロセスを示す図である。
【図８】セッションが生成または変更される際に保証最小帯域幅チェックを実行するプロセスを示す図である。
【図９】帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。
【図１０】すべてのアプリケーションセッションの所望の帯域幅の合計（Ｓｕｍ（Ｄ））がアプリケーショングループに割り当てられた総帯域幅（Ｂ）以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。
【図１１】すべてのアプリケーションセッションの所望の及び予想帯域幅の小さいほうの合計がアプリケーショングループに割り当てられた総帯域幅以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。
【図１２】すべてのアプリケーションセッションの所望の及び保証最小帯域幅の小さいほうの合計がアプリケーショングループに割り当てられた総帯域幅以下である場合に図９の帯域幅割り当てアルゴリズムを実装するプロセスを示す図である。
【図１３】帯域幅を提供するかまたは追加帯域幅を要求することによって帯域幅の適合化または再割り当てプロセスに参加可能であるアプリケーションを決定するプロセスを示す図である。
【図１４】利用可能な帯域幅の合計が要求帯域幅の合計を下回っている際に帯域幅の適合化または再割り当てを実行する方式を示す図である。
【図１５】利用可能な帯域幅の合計が要求帯域幅の合計以上である際に帯域幅の適合化または再割り当てを実行する方式を示す図である。
【図１】
2009525641.tif 000031
【図２】
2009525641.tif 000032
【図３】
2009525641.tif 000033
【図４】
2009525641.tif 000034
【図５】
2009525641.tif 000035
【図６】
2009525641.tif 000036
【図７】
2009525641.tif 000037
【図８】
2009525641.tif 000038
【図９】
2009525641.tif 000039
【図１０】
2009525641.tif 000040
【図１１】
2009525641.tif 000041
【図１２】
2009525641.tif 000042
【図１３】
2009525641.tif 000043
【図１４】
2009525641.tif 000044
【図１５】
2009525641.tif 000045
【手続補正書】
【提出日】平成20年12月26日(2008.12.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信システムを使用してデータを転送する複数のアプリケーション間で前記通信システムの帯域幅を割り当てる方法において、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
前記帯域幅限度は、
前記複数のアプリケーションのすべてのＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップであって、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を含む方法。
【請求項２】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、前記アプリケーションのそれぞれのものに帯域幅を割り当てるステップは、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しておらず、
前記複数のアプリケーションのそれぞれには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられており、
前記ＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられず、かつ、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項１に記載の方法。
【請求項３】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップは、前記それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む請求項１に記載の方法。
【請求項４】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、前記帯域幅調節が、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、該帯域幅は、その個々の帯域幅を十分に利用していない他の１以上のアプリケーションから割り当られ、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを有しており、かつ、前記１以上のアプリケーションには、前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、調節するステップと、
を更に含む、請求項１に記載の方法。
【請求項５】
アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項１に記載の方法。
【請求項６】
通信ネットワーク上においてデータを複数のクライアント装置に供給する装置であって、
アプリケーションを登録すべく構成された登録要素であって、前記アプリケーションが前記クライアント装置に供給されるデータを提供している、登録要素と、
前記通信ネットワークの帯域幅を前記アプリケーションに割り当てるべく構成された帯域幅割り当て要素と、
前記通信ネットワーク上における伝送のために前記提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、
前記通信ネットワーク上における伝送のために前記フォーマッティングされたデータを前記通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、
を備える装置。
【請求項７】
前記登録要素が複数のアプリケーションを登録し、更に、前記帯域幅割り当て要素が前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されている、請求項６に記載の装置。
【請求項８】
前記帯域幅割り当て要素が、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されており、
前記帯域幅割り当てプロセスが、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、Ｂ1が最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、前記相対的な優先度レベルが値Ｐiを有し、Ｐ<iがＰiを下回るすべての優先度レベルを表しており、Ｐ>iがＰiを上回るすべての優先度レベルを表している、ステップであり、
前記帯域幅限度が、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれに割り当てるステップであって、前記帯域幅割り当てが、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を含む、請求項７に記載の装置。
【請求項９】
前記帯域幅割り当てプロセスが、前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、
更に、帯域幅を前記アプリケーションのそれぞれに割り当てるステップが、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しない、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられる、
ＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられない、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している、請求項８に記載の装置。
【請求項１０】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップが、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項８に記載の装置。
【請求項１１】
前記帯域幅割り当てプロセスが、
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つに割り当てられた帯域幅を、該アプリケーションに通知を提供することなしに、調節するステップであって、前記帯域幅調節が、
前記アプリケーションが、割り当てられた帯域幅を現在十分に利用していない場合には、前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、該帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられ、前記１以上のアプリケーションが、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを有し、前記１以上のアプリケーションには、前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、調節するステップと、
を更に含む、請求項８に記載の装置。
【請求項１２】
前記帯域幅割り当てプロセスが、
前記アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項８に記載の装置。
【請求項１３】
前記フォーマッティングされたデータが、前記通信ネットワーク上においてブロードキャストされる、請求項６に記載の装置。
【請求項１４】
通信ネットワーク上において伝送されたデータを受信する装置であって、前記データが前記装置上で稼動しているアプリケーションに提供されるものである装置であり、
前記アプリケーションを登録すべく構成された登録要素と、
前記通信ネットワークから受信したデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットからイベントを生成するデータアセンブリ要素と、
前記受信したデータを保存すべく構成されたキャッシュと、
前記イベントを前記アプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、
を備える装置。
【請求項１５】
前記受信したデータが、前記通信ネットワーク上においてブロードキャストされたものである請求項１４に記載の装置。
【請求項１６】
前記スケジューリング要素が、前記イベントに必要なすべてのデータが受信され、所望の順序に配置されたと判断された後に、前記イベントを前記アプリケーションに提供すべく構成されている、請求項１４に記載の装置。
【請求項１７】
通信ネットワーク上においてクライアント装置にデータを供給するためのシステムであって、
サーバーアプリケーションを登録すべく構成された登録要素であって、前記サーバーアプリケーションは、前記クライアントアプリケーションに供給されるデータを提供している、登録要素と、
前記通信ネットワークの帯域幅を前記サーバーアプリケーションに割り当てるべく構成された帯域幅割り当て要素と、
前記通信ネットワーク上における搬送のために前記提供されたデータをフォーマッティングすべく構成された通信ネットワークフォーマッティング要素と、
前記通信ネットワーク上における搬送のために前記フォーマッティングされたデータを前記通信ネットワークに提供すべく構成された通信ネットワーク制御要素と、
を有するサーバー装置と、
前記クライアントアプリケーションを登録すべく構成された登録要素と、
前記通信ネットワークから受信したデータを処理すべく構成されたデータアセンブリ要素であって、１以上のデータパケットを生成するデータアセンブリ要素と、
前記受信したデータを保存すべく構成されたキャッシュと、
前記イベントを前記クライアントアプリケーションに提供する時期を決定すべく構成されたスケジューリング要素と、
を有するクライアント装置と、
を備えるシステム。
【請求項１８】
前記通信ネットワークが、前記サーバー装置及びクライアント装置の間においてデータを伝送すべく構成されている、請求項１７に記載のシステム。
【請求項１９】
前記データは、前記通信ネットワーク上においてブロードキャストされる、請求項１７に記載のシステム。
【請求項２０】
前記通信ネットワークが、無線ネットワークである、請求項１７に記載のシステム。
【請求項２１】
前記サーバー装置の登録要素が、複数のアプリケーションを登録し、更に、前記帯域幅割り当て要素が、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されている、請求項１７に記載のシステム。
【請求項２２】
前記帯域幅割り当て要素が、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を前記複数のアプリケーションに割り当てるべく構成されており、
前記帯域幅割り当てプロセスが、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、Ｂ2が、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、前記相対的な優先度レベルが、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであり、
前記帯域幅限度が、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しない、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過しない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれに割り当てるステップであって、前記帯域幅割り当てが、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しない、という関係を満足している、ステップと、
を含む、請求項２１に記載のシステム。
【請求項２３】
前記帯域幅割り当てプロセスが、
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有し、更に、帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップが、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しない、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てられる、
そのＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回っていないものが割り当てられていない限り、Ｂ2を下回るものが割り当てらない、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足している請求項２２に記載のシステム。
【請求項２４】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップが、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項２２に記載のシステム。
【請求項２５】
前記帯域幅割り当てプロセスが、
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、前記帯域幅調節が、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、該帯域幅が、その個々の帯域幅を十分に利用していない他の１以上のアプリケーションから割り当てられており、前記１以上のアプリケーションが、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを有し、前記１以上のアプリケーションには、前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、調節するステップと、
を更に含む、請求項２２に記載のシステム。
【請求項２６】
前記帯域幅割り当てプロセスが、
前記サーバーアプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記サーバーアプリケーションに提供するステップと、
を更に含む、請求項２２に記載のシステム。
【請求項２７】
通信ネットワーク上においてデータを複数のクライアント装置に配布する方法であって、前記方法が、
前記クライアント装置にデータを提供すべくアプリケーションを登録するステップと、
前記アプリケーションに前記通信ネットワークの帯域幅を割り当てるステップと、
前記通信ネットワーク上における搬送のために前記アプリケーションによって提供されたデータを処理するステップと、
前記処理されたデータを前記通信ネットワーク上において伝送するステップと、
を含み、
それぞれのクライアント装置について、前記方法が、
前記クライアント装置にクライアントアプリケーションを登録するステップと、
前記通信ネットワーク上における伝送の後に前記データを受信するステップと、
前記データをストレージ媒体内にキャッシングするステップと、
前記データの供給をスケジューリングするステップと、
前記データを前記クライアントアプリケーションに提供するステップと、
を含む方法。
【請求項２８】
前記処理されたデータを前記通信ネットワーク上において伝送するステップが、前記データを前記通信ネットワーク上においてブロードキャストするステップを更に含む、請求項２７に記載の方法。
【請求項２９】
前記通信ネットワークが、無線ネットワークである、請求項２７に記載の方法。
【請求項３０】
データを前記クライアント装置に提供すべくアプリケーションを登録するステップは、複数のアプリケーションを登録するステップを更に有しており、かつ、更には、この場合に、前記通信ネットワークの帯域幅を前記アプリケーションに割り当てるステップは、帯域幅割り当てプロセスを実行することにより、前記通信ネットワークの帯域幅を複数のアプリケーションに割り当てるステップを更に有しており、
前記帯域幅割り当てプロセスは、
前記複数のアプリケーションのすべてにとって利用可能である総帯域幅ＢAの値を決定するステップと、
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1を決定するステップであって、この場合に、Ｂ1は、最小保証帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの第２帯域幅限度Ｂ2を決定するステップであって、この場合に、Ｂ2は、前記第１帯域幅限度を下回っていない予想帯域幅限度を表している、ステップと、
前記複数のアプリケーションのそれぞれの相対的な優先度レベルを決定するステップであって、この場合に、前記相対的な優先度レベルは、値Ｐiを具備しており、Ｐ<iは、Ｐiを下回るすべての優先度レベルを表しており、Ｐ>iは、Ｐiを上回るすべての優先度レベルを表している、ステップであって、
この場合に、前記帯域幅限度は、
前記複数のアプリケーションのすべてにおけるＢ1の合計がＢAを超過しておらず、かつ、
それぞれの相対的な優先度値Ｐiについて、優先度レベルＰiにおけるそれぞれのアプリケーションのＢ2の合計に優先度レベルＰ<iにおけるそれぞれのアプリケーションのＢ1の合計を加算したものがＢAを超過していない、
という関係を満足している、ステップと、
帯域幅を前記アプリケーションのそれぞれに割り当てるステップであって、この場合に、前記帯域幅割り当ては、前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過していないという関係を満足している、ステップと、
を有する請求項２７に記載の方法。
【請求項３１】
前記複数のアプリケーションのそれぞれの所望の帯域幅Ｄを決定するステップを更に有しており、かつ、更には、この場合に、帯域幅を前記アプリケーションのそれぞれのものに割り当てるステップが、
前記複数のアプリケーションのすべてに割り当てられた帯域幅の合計がＢAを超過しない、
それぞれのアプリケーションには、Ｄ及びＢ1の少なくとも小さいほうが割り当てらる、
ＤがＢ2を下回っていない優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＢ2を上回らないものが割り当てられていない限り、Ｂ2を下回るものが割り当てられない、
優先度Ｐiにおけるそれぞれのアプリケーションには、優先度Ｐ>iにおけるそれぞれのアプリケーションにＤを上回らないものが割り当てられていない限り、Ｄを下回るものが割り当てられない、
という関係を満足する、請求項３０記載の方法。
【請求項３２】
前記複数のアプリケーションのそれぞれの第１帯域幅限度Ｂ1、第２帯域幅限度Ｂ2、及び所望の帯域幅Ｄを決定するステップが、それぞれのアプリケーションごとに、
前記アプリケーションの予想サービス品質（ＱｏＳ）レベルを決定するステップと、
前記予想ＱｏＳレベルを前記アプリケーションのＢ2の等価な値に変換するステップと、
Ｂ1及びＤを前記アプリケーションのＢ2との関係においてＱｏＳ値に変換するステップと、
を更に含む、請求項３０に記載の方法。
【請求項３３】
前記複数のアプリケーションの中の１つのものの所望のサービス品質（ＱｏＳ）レベルを決定するステップと、
前記複数のアプリケーションの中の前記１つのものに割り当てられた帯域幅を、そのアプリケーションに通知を提供することなしに、調節するステップであって、この場合に、前記帯域幅調節が、
前記アプリケーションがその割り当てられた帯域幅を現在十分に利用していない場合には、結果的に前記アプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅を提供し、
前記アプリケーションがその割り当てられた帯域幅を現在過剰に利用している場合には、前記アプリケーションの所望のＱｏＳを維持するのに十分な追加の帯域幅を提供し、
追加の帯域幅が前記アプリケーションに提供される場合に、その帯域幅は、その個々の帯域幅を十分に利用していない１以上のその他のアプリケーションから割り当てられており、この場合に、前記１以上のアプリケーションは、それぞれ、関連する所望のサービス品質（ＱｏＳ）レベルを具備しており、かつ、前記１以上のアプリケーションには、結果的に前記１以上のアプリケーションの所望のＱｏＳに影響を与えない場合にのみ、更に小さな帯域幅が提供されるように、
実行される、ステップと、
を更に含む、請求項３０に記載の方法。
【請求項３４】
前記アプリケーションに関連するサービス品質（ＱｏＳ）レベルを決定するステップと、
前記ＱｏＳレベルの変化に関するデータを前記アプリケーションに提供するステップと、
を更に含む、請求項２７に記載の方法。
【国際調査報告】
2009525641.tif 000046
2009525641.tif 000047