JP2010532648A - 通信ネットワークでのリソースプロビジョニングおよびプランニングのための方法および装置 - Google Patents

Abstract

ある態様では、方法は、目標とされたサービスのリソース要件を表わすリソースエンティティを生成し、リソースエンティティは、転送ネットワーク（ＴＮ）依存情報およびＴＮ独立情報の少なくとも１つからモデル化され、リソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定することを含んでいる。装置は、ＴＮ依存情報とＴＮ独立情報の少なくとも１つを受け取る入力ロジック回路と、目標とされたサービスのリソース要件を表わすリソースエンティティを生成し、リソースエンティティはＴＮ依存情報とＴＮ独立情報の少なくとも１つからモデル化され、リソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する処理ロジック回路と、を含んでいる。

Description

本願は、一般にデータネットワークの動作に関し、特に通信ネットワークにおいてリソースプロビジョニングおよびプランニングのための方法および装置に関する。

本特許出願は、２００７年７月３日に提出され、譲受人にこれについて割り当てられ、これによってここに参照することによって組み込まれる「マルチメディア通信ネットワークにおいてリソースプランニングについて方法および装置」と題された仮出願６０／９４７，７１６番に対して優先権を主張する。

末端間マルチメディア通信システムでは、マルチメディアコンテンツは、有線および（または）無線ネットワークを具備する異なるタイプの転送ネットワーク（ＴＮ）上で、コンテンツプロバイダからコンテンツ消費者（エンドユーザとしても知られる）に配信されてもよい。上記のマルチメディアシステムの一実施形態において、１セットの（ビデオおよびオーディオコンポーネントのような）マルチメディアコンポーネントは、エンドユーザに全体として提供され、「サービス」と呼ばれる。サービスコンポーネントに転送を提供するＴＮにおける論理エンティティは、「フロー」と呼ばれる。

システムにおけるサービスはそれぞれ、受信デバイスで望ましい品質水準を提供するために満たされるべきサービス品質（ＱｏＳ）基準に関連付けてもよい。典型的には、ＱｏＳ基準はコンテンツプロバイダとシステムオペレータの間のサービスレイヤ合意で記述される。ＴＮの望ましいＱｏＳを満たすためにそのようなシステムを異なるＴＮ上でサービスを運ぶように設定することは、特に、無線ネットワークとしてリソースが不足し過剰なプロビジョニングが手頃でない転送ネットワークでは非常に複雑になり得る。

したがって、望ましいＱｏＳを有するコンテンツの配信を促進するように、通信システムにおけるリソースプロビジョニングおよびプランニングを提供するために動作するシステムを持っていることは望ましい。

１以上の態様では、通信システムにおけるリソースプロビジョニングおよびプランニングを提供するために動作する、方法と装置を具備するプロビジョニングシステムは提供される。

ある態様では、方法は通信ネットワークにおいてリソースプランニングに提供される。方法は、１以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成することと、リソースエンティティは、転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、１以上のリソースエンティティが１以上の転送ネットワークにサポートされ得るかどうかを判定することを具備する。

ある態様では、装置は通信ネットワークにおいてリソースプランニングに提供される。装置は、転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つを受信する入力ロジック回路と、１以上の目標とされたサービスのリソース要件をそれぞれ表わす１以上のリソースエンティティを生成する処理ロジック回路と、を具備し、リソースエンティティは、転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、前記処理ロジック回路は１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する。

ある態様では、通信ネットワークにおいてリソースプランニングのための装置は、１以上の目標とされたサービスのリソース要件をそれぞれ表わす１以上のリソースエンティティを生成する手段と、ここでリソースエンティティは、転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する手段と、を具備する。

ある態様では、コンピュータプログラム製品は通信ネットワークにおいてリソースプランニングに提供される。コンピュータプログラム製品は、１以上の目標とされたサービスのリソース要件をそれぞれ表わす１以上のリソースエンティティをコンピュータに生成させる第１のコードセットと、ここでリソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを前記コンピュータに判定させる第２のコードセットと、を具備する。

ある態様では、通信ネットワークにおいてプランニングする少なくとも１つの集積回路が提供される。少なくとも１つの集積回路は、１以上の目標とされたサービスのリソース要件をそれぞれ表わす１以上のリソースエンティティを生成する第１のモジュールと、ここでリソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する第２のモジュールと、を具備する。

他の態様は、下記に説明される図面の概要、詳細な説明および請求項の再検討の後に明らかになる。

本明細書で説明された上記態様は、添付の図面と共に以下の詳細な説明を参照することによって、ただちに明らかになるであろう。
図１は、通信システムにおける情報がプロビジョニングシステムの態様において３つのレイヤにどのように分割されるかを示す図を示す。 図２は、プロビジョニングシステムの態様での使用に関するワークフロー図を示す。 図３は、プロビジョニングシステムの態様での使用に関する典型的なＦＬＯプロトコルスタックを示す。 図４は、プロビジョニングシステムの態様での使用に関する典型的なスロット割り当てを示す。 図５は、プロビジョニングシステムの態様での使用に関するリソースプランニングのための典型的な方法を示す。 図６は、プロビジョニングシステムの態様での使用に関する、配信ウィンドウおよびスケジュールウィンドウを示す図を示す。 図７は、プロビジョニングシステムの態様での使用に関するファイル配信リソーススケジューリングアルゴリズムのための典型的な方法を示す。 図８は、プロビジョニングシステムの態様での使用に関する典型的なＮＰＲロジック回路を示す。 図９は、プロビジョニングシステムの態様での使用に関する典型的なプロビジョニングロジック回路を示す。

１以上の態様では、通信ネットワークにおいてリソースプロビジョニングおよびプランニングを提供するために動作するプロビジョニングシステムが提供される。ある態様では、システムは様々なサービスコンテンツタイプをモデル化し、受信デバイスで選択されたＱｏＳを提供するために必要なネットワークリソースを決定するためにこれらのモデルを用いる。その後、システムは、望ましいサービスコンテンツが選択されたＴＮ上に設定され得るかどうかを示すプランニング結果を提供する。

システムは、特に無線ネットワーク環境での使用に十分適しているが、任意のタイプのネットワーク環境において用いられてもよく、通信ネットワーク、インターネットのような公衆網、仮想プライベートネットワーク（ＶＰＮ）のような私設網、ローカルエリアネットワーク、広域ネットワーク、長距離ネットワーク、または他のタイプのデータネットワークを含むがこれらに限定されない。

イントロダクション
プロビジョニングシステムの態様では、「リソース」エンティティは、アプリケーションレイヤサービスに提示されうる異なるＴＮでネットワークリソース利用を記述する論理エンティティとして定義される。リソースは１以上のリソースディスクリプタを含んでもよく、ディスクリプタがそれぞれサービスで独立したメディアコンポーネントに関するネットワークリソース利用を記述する。リソースディスクリプタでのコンフィギュレーションデータは２つのタイプの情報を含むことができる。
１．ＴＮ独立情報：このデータセットは、コンテンツを運ぶ内在するＴＮにかかわらず、アプリケーションレイヤサービスコンポーネントに提示されるＱｏＳを記述する。上記の情報は、サービスコンポーネントに関して、望ましい帯域幅、遅延、信頼性などを含んでいてもよい。
２．ＴＮ特定情報：サービスコンポーネントを運ぶＴＮでのフローのプロトコルスタック特性を記述する１セットのコンフィギュレーション。本明細書で「フロープロファイル」と呼ばれるこのデータセットは、ＱｏＳ要件が満たされるようなサービスコンポーネントを運ぶために、ＴＮにおけるネットワークリソースがどのように用いられるかに関するネットワーク特定情報を記述する。この情報は、個々の特定のＴＮによって提示されたエンコーディング／変調スキームおよび配信スケジュールを含んでいてもよい。

プロビジョニングシステムのある態様では、リソースディスクリプタは、ＴＮ独立したＱｏＳ要件の１つのセット、および複数のＴＮ特定データセット（サービスコンポーネントを運ぶ各ＴＮに関するもの）、を含むことができる。

図１は、通信システムにおける情報がプロビジョニングシステムの態様において次の３つのレイヤにどのように分割されるか示すダイヤグラム１００を示す。
１．サービスレイヤ：サービスレイヤは、メディアコンテンツのアプリケーションレイヤ特性（例えばコンテンツのジャンル（映画対トークショー））を記述する。
２．ネットワークレイヤ：ネットワークレイヤは、内在する物理的な転送ネットワーク（例えばネットワークインフラ階層レイヤ、ネットワークリンクキャパシティなど）のコンフィギュレーションを記述する。
３．リソースレイヤ：リソースレイヤは、マルチメディアサービスに提示されうるＴＮにネットワークリソース利用を記述する。このように、リソースレイヤは、サービスレイヤとネットワークレイヤの間の抽出を提供する。

プロビジョニングシステムの態様では、リソースレイヤは、通信システムにおけるサービスレイヤおよびネットワークレイヤの間の抽出を提供する。リソースレイヤは次の特徴を提供する：
１．サービスレイヤコンフィギュレーションがＴＮ特定データに不可知であることを許容する。言いかえれば、それはネットワークの詳細をサービスコンテンツプロバイダーから隠す。
２．ネットワークレイヤコンフィギュレーションがサービス特有データに不可知であることを許容する。言いかえれば、それはサービスの詳細をネットワークキャリアから隠す。

その結果、任意のサービスについては、異なるＴＮにおける内在するネットワークリソース利用は、サービスのアプリケーションレイヤコンテンツ特性から分離される。サービスは、サービスレイヤコンフィギュレーションに影響を与えずに、任意のＴＮに加えうるか、または取り除かれうる。

ＴＮにおけるネットワークのキャパシティが限定的であるので、システムによって提示されたリソースはリソースを提供する任意のＴＮのキャパシティを超えるべきでない。ある態様では、プロビジョニングシステムは、サービスを運ぶためにリソースを提示する前に、ＴＮにおけるリソースをプランニングするために機構を提供する。リソースプランニング中に、ＴＮのキャパシティは、ネットワークリソースの予約を取り過ぎることなしで、設定されたリソースが適応されうることを保証すると確認される。ある態様では、優先度はプランニング中にリソース割当に関するリソースに与えられる。別の態様において、異なるモデリング技法はリソースディスクリプタによって記述された異なるタイプのフローのために用いられる。プランニングが失敗する場合、プロビジョニングシステムは、更新されたリソースがネットワークのキャパシティを超えないシステムで提示されたリソースのコンフィギュレーションを調整するためのプロビジョニングオペレータにフィードバックを提供する。

プロビジョニングシステムの別の態様において、機構は、リソースによって運ばれるサービスのＱｏＳ要件が満たされるように、対応するＴＮにおけるリソースに関する配信スケジュールを生成するために提供される。

成功したリソースプランニングの後、プロビジョニングシステムは、サービスを運ぶためにリソースを提示することができる。別の態様は、リソースにサービスを関連させるために機構を提供する。例えば、リソースがターゲットＴＮにおいてサービスのＱｏＳ要件を満たすことができる限り、サービスはシステムにおける任意のリソースに関連付けることができる。他方では、リソースは、リソースコンフィグレーションがサービスのＱｏＳ要件を満たす限り、任意のサービスを運ぶために提示されうる。システムは、リソースがサービスを運ぶために割り当てられた後、サービスのコンテンツを配信する準備ができている。

別の態様は、リソースコンフィグレーション、（繰り返し発生するテンプレートまたは絶対的な時間のいずれかにおける）配信スケジュール、およびそのサービス関連付け情報がシステムにおける転送ネットワークコンポーネントに送達される機構を提供する。これらのリソースパラメータは、サービスコンポーネントを提供し、かつランタイムアドミッション制御および対応するサービスコンテンツに関するトラフィックポリシーイングを行なうために、転送ネットワークコンポーネントによって用いられる。

別の態様において、サービスに関するリソース配信スケジュールは、エンドユーザ（つまり受信デバイス）に前もって送信されてもよい。その結果、ユーザは、いつ、どのようにサービスコンテンツが配信されたか知ることができ、その結果サービスを受信し始めることができる。これは、デバイスが電力および（または）処理キャパシティを制限した移動通信ネットワークにおいて重要である可能性がある。

典型的な態様
プロビジョニングシステムの態様は、転送ネットワークとして１以上の無線アクセスネットワーク（ＲＡＮ）上の無線装置にマルチメディアコンテンツを効率的に配信するために動作する配信システムのコンテキスト内で下記に述べられる。例えば、ある態様では、ＲＡＮはフォワードリンクオンリー（ＦＬＯ）ネットワークまたは任意の他の適切なタイプのネットワークを具備する。

配信システムは、以下のように記述された２つのセグメントを具備する。
１．内在するＲＡＮと無関係のメディアコンテンツを管理するメディア配信システム（ＭＤＳ）、および
２．モバイルデバイスへマルチメディアコンテンツを経済的にマルチキャストするように設計されているＲＡＮ。

サービスタイプ
プロビジョニングシステムの態様では、サポートされている４つの基本のタイプのサービスがある。しかし、システムは、これらのサービスタイプに限定されず、他のサービスタイプまたはサービスサブタイプをサポートするのに実施可能である。例えば、次のサービスタイプはサポートされる。

１．オーバーヘッドサービスタイプ。オーバーヘッドサービスは、それぞれ固定ビットレートで複数のデータコンポーネントを含んでいる。
２．リアルタイム（ＲＴ）ストリーミングサービスタイプ。ＲＴサービスは次のタイプのうちの１つになりえる。
ａ．リアルタイムのオーディオ／ビデオサービス（それは可変ビットレートでの１つのビデオコンポーネントと固定ビットレートでの１つのオーディオコンポーネントを含んでいる）。
ｂ．リアルタイムのオーディオスライドショーサービス（それは、固定ビットレート（例えば６秒ごとに１つのＩ−フレーム）での１つのビデオコンポーネントと固定ビットレートでの１つのオーディオコンポーネントを含んでいる）。
３．ＩＰ データキャストサービス（ＩＰＤＳ）タイプ。ＩＰＤＳサービスは固定ビットレートで１つのデータコンポーネントを含んでいる。
４．メディアクリップのようなファイルの配信に関する非リアルタイムファイル配信（ＦＤ）サービスタイプ。ＦＤサービスは、異なるサイズのファイルを有する１つのデータコンポーネントを含んでいる。ネットワークにおいて利用可能ビットレートで伝えられる。

リソースエンティティ
リソースエンティティは、ＭＤＳセグメントにＲＡＮ抽出を提供するために、システムにおいて用いられる。配信に関して目標とされた各サービスについて、対応するリソースエンティティは、目標とされたサービスおよび対応するＲＡＮ配信スケジュールおよびコンフィギュレーションのＱｏＳ要件を説明するために、ＴＮ依存および独立情報からモデル化される。

ある態様では、システムにおけるリソースエンティティは次のパラメータを含んでいる。
１．リソースＩＤ−システムにおけるリソースについてユニークなＩＤを指定する。
２．リソースタイプ−リソースのタイプを指定する。リソースは次のタイプのうちの１つになりえる。オーバーヘッド、ＲＴ、ＩＰＤＳおよびＦＤ。
３．優先度−システムにおける他のリソースに関してはリソースのユニークな優先度を指定する。

リソースタイプに基づいて、リソースにおける１以上のリソースディスクリプタは目標とされたサービスコンポーネントを運ぶフローのＱｏＳ要件およびＲＡＮ利用を説明すると決定される。次のパラメータはリソースでの各リソースディスクリプタに関して指定される。
１．リソースディスクリプタＩＤ−システムにおけるリソースディスクリプタを識別するユニークなＩＤを指定する。
２．フロータイプ−リソースディスクリプタが記述する対応するフローのタイプを指定する。各リソースディスクリプタのフロータイプはリソースタイプによって決定される。
３．ＱｏＳ要件−フローによって運ばれた対応するサービスコンポーネントのアプリケーションレイヤＱｏＳ要件を指定する。ＱｏＳ要件のうちのいくつかは、あるタイプのフローに適用するのみでよく、アプリケーションレイヤサービスタイプに依存してもよいことに注意する。ＱｏＳ要件は、次のパラメータの１つ以上を具備する。
− 平均データレート−フローによって運ばれたサービスコンポーネントに関する平均データレートを指定する。
− トラフィッククラス−フローによって運ばれたサービスコンポーネントに関するトラフィッククラスを指定する。
− ピークデータレート−フローによって運ばれたサービスコンポーネントに関するピークデータレートを指定する。
− 末端間レイテンシー−フローによって運ばれたサービスコンポーネントについて末端間レイテンシーを指定する。
− 最大バーストサイズ−フローによって運ばれたサービスコンポーネントに関する最大バーストサイズを指定する。
− 品質メトリック−ビデオサービスコンテンツに関する平均オピニオンスコア（ＭＯＳ）のような品質メトリックを指定する。

対応する目標とされたサービスコンテンツがファイルを含んでいる場合、次のＱｏＳパラメータはファイルごとに指定される。
− ファイルサイズ−ファイルの最大サイズを指定する。
− ファイル配信期限−ＲＡＮがファイルの配信を終了しなければならない時を指定する。
− ファイル配信開始時刻−ＲＡＮがファイルの配信を開始することができる時を指定する。

次のパラメータはリソースを運ぶ転送ネットワークごとに指定される。
１．ネットワークＩＤ−リソースを運ぶネットワークのＩＤを指定する。
２．リソース状態−ネットワーク（例えば、リソースがネットワークにおいて利用可能なサービスに結び付けられるかどうか）においてリソースの状態を指定する。
３．フロープロファイル情報−サービスコンポーネントを運ぶ対応するフローのＲＡＮプロトコルレイヤ特性を記述するフロープロファイルを指定する。フロープロファイルは、次のパラメータの１つ以上を具備する。
− 送信モード−フローの送信モードを指定する。
− 外部コード−フローの外部コードを指定する。
− フラグメンテーションフラグ−フローに関する転送レイヤフラグメンテーション規則を指定する。
− チェックサムフラグ−転送レイヤチェックサムがフローに関して可能になるかどうかを指定する。
− リンクレイヤ暗号化フラグ−リンクレイヤ暗号化がフローに関して可能になるかどうかを指定する。
− ＩＰヘッダーポリシー−フローに関してＩＰヘッダー処理についてのポリシーを指定する。
−配信期間数−１ファイルごとにこのネットワークでの配信期間の数を指定する。

次のパラメータは配信期間ごとに指定される。
・配信ウィンドウ開始時刻−ネットワークにおいて配信期間の開始時刻を指定する。
・配信ウィンドウ終了時刻−ネットワークにおいて配信期間の終了時刻を指定する。

プロビジョニング
プロビジョニングシステムの態様では、プロビジョニングは３つのタスクに分割される。すなわち、ネットワークレベルプロビジョニング、リソースレベルプロビジョニング、およびサービスレベルプロビジョニング。
１．ネットワークプロビジョニングはＲＡＮネットワークインフラおよびハードウェアコンフィギュレーションを管理する。
２．サービスプロビジョニングはサービスの指向のコンテンツコンフィギュレーションに関してコンテンツプロバイダにインタフェースを提供する。
３．リソースプロビジョニングは、ネットワークとサービスをともにリンクし、ＭＤＳセグメントにネットワーク抽出を提供することにより、物理的なネットワーク上でコンテンツの配信を促進する。

「プロビジョニングサブシステム」はシステム内でプロビジョニング関連機能を扱うために定義される。プロビジョニングサブシステムは次の３つのコンポーネントを具備する。
１．コンフィギュレーションマネージャ（ＣＭ）：ＣＭコンポーネントは次のネットワーク関連プロビジョニング機能を提供する。

− ＲＡＮネットワークコンポーネントのコンフィギュレーションを含むＲＡＮ関連プロビジョニング。
− フロープロファイルテンプレートのプロビジョニング。例えば、それらの各々は、ＲＡＮにサポートされたあるタイプのフローについてプロトコルスタック特性を捕らえる。

− ネットワークにおいて他のコンポーネントへのネットワークプロビジョニングデータの配信。
− ＲＡＮコンポーネントへのリソースプロビジョニングデータの配信。

２．ネットワークリソースプランナ（ＮＲＰ）。ネットワークリソースプランナは、システムを介して提示されたサービスへのネットワークリソースの割り当てを決定する。ＮＲＰは、リソースプロビジョニングに必要なネットワーク関連プロビジョニングデータを取り出すために、ＣＭとインタフェースをとる。ＮＲＰは次のリソースプロビジョニング関連機能を提供する。

− ＲＡＮにおけるプロビジョニングネットワークリソース。
− リソースがシステムに収容され得るかどうかを判定するためのリソースプランニング。
− リソースに関する配信スケジュールを生成するリソースプランニング。
− 永続記憶装置に関するＣＭへのリソースデータの配信およびＲＡＮコンポーネントへの配信。
３．サービスプロビジョニングサーバ（ＳＰＳ）。サービスプロビジョニングサーバは、システムサービスと市場に関連するプロビジョニング機能の提供する責任を負う。ＳＰＳは、サービスプロビジョニングに必要な、ネットワークおよびリソース関連プロビジョニングデータを取り出すために、ＣＭとインタフェースをとる。ＳＰＳは次のサービスプロビジョニング関連機能を提供する。
− システム上に配信されるコンテンツを定義するサービスのプロビジョニング。

− ＭＤＳの内のコンポーネントへサービスプロビジョニングデータの配信。

− サービスアソシエーションへのリソースに関するＣＭへのトリガーの配信
プロビジョニングワークフロー
図２は、プロビジョニングシステムの態様での使用に関するワークフロー図２００を示す。ワークフロー図２００は、ネットワークプロビジョニング、ネットワークリソースプロビジョニング、およびサービスプロビジョニングを提供するために、プロビジョニングシステムの態様の動作を示す。ある態様では、ネットワークリソースプランニング（ＮＲＰ）ロジック回路２０２は、ここで説明されるようにリソースプロビジョニングを提供するために動作する。

ワークフロー図２００に関連した動作は以下のように説明される。下記に述べられた動作が任意の適切な順に行なわれてもよいことは注意されるべきである。２つのオペレータブロックは図２に示されるが、オペレータ機能は１以上の人によって行なわれてもよいこともまた注意されるべきである。
１．オペレータは、システムにおいて利用可能になるＲＡＮコンポーネントを設定する。
２．ネットワークコンフィギュレーション情報はＲＡＮコンポーネントに配信される。このネットワークコンフィギュレーション情報も、ネットワークリソースのコンフィギュレーションおよびプランニングに関してＮＲＰに利用可能になる。
３．オペレータはＮＲＰロジック回路２０２でネットワークリソースを設定しプランニングする。
４．一旦ネットワークリソースが正常にプランニングされれば、プランニングされたリソースはすべて、プランニングされたネットワークリソースの現在のセットを維持するＣＭに利用可能になる。
５．ＣＭは、サービスプロビジョニングに関するＳＰＳに利用可能な、プランニングされたネットワークリソースおよびネットワークインフラコンフィギュレーションを作成する。
６．オペレータはＳＰＳでサービスを設定する。
７．オペレータは設定されたサービスをプランニングされたネットワークリソースに結び付ける。
８．ＳＰＳは、ＣＭとのサービス結合へのリソースの情報を送信する。
９．ＣＭは、サービスコンテンツの転送に関するネットワーク論理コンポーネント識別子を生成することによってリソースとサービスの結合を行なう。
１０．ＣＭは、エンドユーザに利用可能になるサービス定義システム情報への包含についてＳＰＳにサービスに関するフローＩＤを送信する。
１１．ＳＰＳは、エンドユーザに利用可能なサービスのスケジューリング情報を作成するＭＤＳコンポーネントにサービスコンフィギュレーションを配信する。
１２．ＣＭは、ＲＡＮコンポーネントへマッピングするサービスへのリソースとリソースコンフィグレーションとを配信する。ＲＡＮコンポーネントは、性能ランタイムフローアドミッション制御およびトラフィックポリシーイングへのリソースコンフィギュレーション情報を用いる。

サービスおよびその対応するリソースがシステムで正常に設定された後、サービスレイヤコンフィギュレーションへの任意の更新は、内在するリソースコンフィグレーションに影響を与えずにＳＰＳでなされうる。

一方、リソースによって運ばれるサービスのＲＡＮコンフィギュレーションまたはＱｏＳ要件への何らかの変更があれば、ＮＲＰはネットワークにおいてリソースを再プランニングし、サービスレイヤコンフィギュレーションにトランスペアラントなリソースを更新する。

リソーススケジューリング手順
プロビジョニングシステムの態様では、ネットワークリソーススケジューリング手順は、システムにともに収容されうる、入力として１セットの候補リソースを処理し、１セットのスケジュール可能なリソースを出力することによって、ＮＲＰロジック回路２０２によって行なわれる。例えば、候補リソースは、ＴＮ依存および独立情報からモデル化された、目標とされたサービスに関連したリソースエンティティである。

図３は、プロビジョニングシステムの態様での使用のためのスケジューリングリソースに関する典型的な方法３００を示す。例えば、方法３００はＮＲＰロジック回路２０２によって行なわれる。明確にするために、候補リソースのリスト（つまりリソースエンティティ）は方法３００への入力として提供されると仮定される。候補リソースのリストは、ネットワークで運ばれる目標とされたサービスに基づいて生成される。候補リソースのリストは高から低への優先順位でソートされる。例えば、目標とされたリアルタイムサービスに関連した候補リソースは、目標とされたＩＰデータキャストサービスに関連した候補リソースよりも高い優先度を与えられる。目標とされたサービスおよびそれらの関連する候補リソースが、候補リソースがソートされる順序を決定するために、任意の望ましい優先順位に割り当てられてもよいことは注意されるべきである。方法３００が、本明細書で説明されたサービスタイプに限定されない任意の適切なサービスタイプから導き出された候補リソースの任意のセットによる使用に適していることもまた注意されるべきである。方法３００の詳細な説明は以下で提供され、次の定義が適用される。
Ｌ_ＩＮ：入力として提供され、高から低への割り当てられた優先順位によってソートされた候補リソースのリスト。
Ｌ_ＩＮ＿Ｊ：リストＬ_ＩＮにおける候補リソースＪ。
Ｌ_ＯＵＴ：スケジュール可能なリソースのリスト。
Ｎ：Ｌ_ＩＮにおける候補リソースの合計数。

ブロック３０２では、方法がスケジュール可能なリソース（Ｌ_ＯＵＴ）の空リストおよび「１」に設定されたインデックスＪで開始する。

ブロック３０４で、候補リソース（Ｌ_ＩＮ）のリストが高から低への優先順位に基づいて一つずつ処理される。例えば、入力リソースリスト（Ｌ_ＩＮ）の最上位の候補リソースは、スケジュール可能なリスト（Ｌ_ＯＵＴ）に加えられる。

ブロック３０６では、更新されたＬ_ＯＵＴリストでのリソースが、候補リソースを運ぶネットワークごとに共にスケジュールされうるかどうかについて、判定がなされる。候補リソースがスケジューリングされえない場合、方法はブロック３０８へ進み、候補リソースがスケジュール可能なリスト（Ｌ_ＯＵＴ）から取り除かれる。ブロック３１０では、ＮＲＰロジック回路２０２は、スケジュール可能でなく、失敗の理由を提供する候補リソースに関してオペレータに通知する。方法３００は、リスト（Ｌ_ＩＮ）での候補リソースがすべてスケジュール可能なリスト（Ｌ_ＯＵＴ）への包含に関してテストされるまで、ブロック３１２で継続する。方法３００の結果では、Ｌ_ＯＵＴは、スケジュール可能なリソースのリストを具備する。

ある態様では、方法３００は、目標とされたＲＴサービス、ＩＰＤＳサービスおよびＦＤサービスから導き出された候補リソースに関して行なわれる。しかし、方法３００は、他のタイプのサービスから導き出された他の候補リソースによる使用に適している。更に、ブロック３０６でＬ_ＯＵＴの成功スケジューリングに用いられた判定基準は、異なるリソースタイプごとに異なってもよい。リソースタイプごとに用いられたアルゴリズムの詳細な説明は次の項において提供される。このように、方法３００はリソースＬ_ＯＵＴのスケジュール可能なリストを決定するために動作する。

リソーススケジューリング手順の要約
プロビジョニングシステムの態様では、スケジューリング手順は、Ｌ_ＯＵＴリストにおけるリソースがネットワークごとに一緒にスケジューリングされうるかどうかを判定するために行なわれる。下記は、プロビジョニングシステムの態様において提供される動作を要約する。

１． オーバーヘッドリソーススケジューリング
２． リアルタイムリソーススケジューリング
３． ＩＰＤＳリソーススケジューリング
４． 帯域幅がオーバーヘッド、ＲＴおよびＩＰＤＳリソースに関して存在するかどうかを判定すること。
５． ファイル配信リソースに関して余っている帯域幅があるかどうかを判定すること。
６． 任意の余っている帯域幅を使用するファイル配信リソーススケジューリング
表記法
次の表記法は、プロビジョニングシステムの態様での使用に関するリソースプランニングアルゴリズムの理解を促進するために定義される。
Ｂ_ｊ：ＭＬＣ ｊに関するアプリケーションレイヤデータレート。
Ｂ^ｉ _Ｙ：ネットワークｉにおけるリソースタイプＹの合計のアプリケーションレイヤデータレート（ここでＹはオーバーヘッド（Ｏ）、ＲＴ、ＩＰＤＳおよびＦＤになりえる）。
Ｄ_ｊ：ＭＬＣ ｊに関する物理レイヤデータレート。
Ｄ^ｉ _Ｙ：ネットワークｉにおけるリソースタイプＹの合計物理レイヤデータレート。
ｓｐ_ｊ：ＭＬＣ ｊに関するＰＬＰ当たりのスロット数。
Ｓｌｏｔ^ｉ _Ｙ：ネットワークｉにおいてリソースタイプＹによって用いられるスーパーフレーム当たりのデータスロットの合計数。
Ｓ^ｉ _Ｙ：ネットワークｉにおいてリソースタイプＹによって用いられるフレーム当たりの物理レイヤＯＦＤＭデータシンボル。
ｅ_Ｙ：リソースタイプＹに関するフレーム当たりのデータスロットの数と、Ｓ^ｉ _Ｙにおけるスロット数との間の比に等しい、リソースタイプＹに関するスロット割り当て効率。

ＲＡＮ概要
プロビジョニングシステムの態様、すべてのリソースに共通のＦＬＯプロトコルスタックの詳細な説明、およびスロット割り当てアルゴリズムにおいて用いられるリソースプランニングアルゴリズムの理解を促進することは以下で提供される。

ＦＬＯプロトコルスタック
図４は、プロビジョニングシステムの態様での使用に関する典型的なＦＬＯプロトコルスタック４００を示す。リソース定義はサービスコンポーネントごとにアプリケーションレイヤでＱｏＳ要件（例えばデータレート）を記述する。ＦＬＯ ＲＡＮでは、サービスコンポーネントはそれぞれ個別のフローで運ばれる。１以上のフローはＦＬＯ ＲＡＮでメディア論理チャネル（ＭＬＣ）によって運ばれる。ＦＬＯエアインタフェース上に送信されている間、次のＦＬＯプロトコルスタックオーバーヘッドはフローに加えられる。

転送レイヤ
図４を再び参照して、フローに属するアプリケーションレイヤ４０２のデータトラフィックＢ_ｊは、転送レイヤで複数の１２１バイト（９６８ビット）のフラグメントへ分けられる。１バイトフレーミングヘッダー（ＦＨ）は、１２２のバイトストリームレイヤブロックを形成するために、各フラグメントに加えられる。必要ならば、パディングは、各ブロックが厳密に１２２バイトになるように最後のブロックに加えられる。

ストリームレイヤ
図４を再び参照して、ストリームレイヤはストリームで各フローを運び、３つまでのフローを１つのＭＬＣへ多重化する。ＭＬＣにおいて多重化されたフローは、同じサービスのコンポーネントを運ぶ。ストリーム０パケットは、ストリームレイヤトレーラー、およびＭＡＣカプセルトレーラーを収容する空のフィールドを含む。ストリーム０データのサイズは単なる１つのＭＡＣパケットであると仮定される。

メディアアクセス制御（ＭＡＣ）レイヤ
送信フレームにおけるＭＬＣのコンテンツは、ＭＡＣプロトコルカプセルと呼ばれるエンティティにカプセル化される。ＭＡＣプロトコルカプセルはＭＡＣレイヤパケットで運ばれる。

１． ＭＡＣカプセルトレーラーは、ストリームのベースコンポーネントにおいてストリーム０パケットに加えられる。ストリームレイヤパケットが向上されたコンポーネントを有していれば、ＭＡＣレイヤはストリーム０に関するダミーの向上されたパケットを加える。下記の式（１）に示されるように、ｌは非レイヤの送信モードに関して１と等しく、レイヤの送信モードに関して２と等しい。

２． リードソロモン（ＲＳ）［１６、ｋ、１６−ｋ］エンコーディングは、エラー制御ブロックを生成するために、コードブロック当たり１６のＭＡＣコードパケットで、パケットに適用される。パディングパケットは、ＭＡＣデータパケットの合計数がｋの整数倍数であるようなＭＡＣデータパケットに加えられてもよい。

物理レイヤ
図４を再び参照して、物理レイヤ４０４は、２４ビットのヘッダーを各ＭＡＣレイヤパケットに加えて、１０００ビットの物理レイヤパケット（ＰＬＰ）を形成する。

ＦＬＯ転送レイヤへのＭＬＣ ｊの入力データレートがＢ_ｊビット／秒であるとすると、図４によれば、対応する物理レイヤデータレート（ビット／秒）は下記から決定することができる。

スロット割り当て概要
図５は、プロビジョニングシステムの態様での使用に関する典型的なスロット割り当て５００を示す。ＦＬＯ ＲＡＮにおける物理レイヤパケット（ＰＬＰ）は、データスロットおよびＯＦＤＭデータシンボルで運ばれる。ＦＬＯスーパーフレームでのＯＦＤＭデータシンボルはフレームと呼ばれる４つの等しい部分に分割される。ネットワークのキャパシティはフレーム当たりのデータシンボルの合計数として与えられる。ＭＬＣのＰＬＰはスーパーフレーム当たりのＲＳブロックを単位にしてスケジューリングされ、各ＲＳブロックでのＰＬＰは４つのフレームにおいて平等に配信される。

各ＯＦＤＭシンボルのサブキャリアは７つのスロットに分割される。ＦＬＯ ＲＡＮは、データ配信に関する送信モードの多様なセットを提供する。異なるタイプのメディアコンテンツごとにサービス品質要件を満たすために、異なるＭＬＣは、異なる送信モードを用いて、ＦＬＯ ＲＡＮ上で配信される。１つのＰＬＰを運ぶために必要とされるデータスロット数は異なる送信モードごとに異なってもよい。したがって、６ＭＨｚの周波数帯については、スーパーフレーム当たりの最大物理レイヤローデータは、異なる送信モードごとに１．６８Ｍｂ／ｓから１１．２Ｍｂ／ｓまで変化する。ネットワークｉにおけるタイプＹリソースに関するスーパーフレーム当たりのデータスロットの合計数は、ＭＬＣ Ｄ_ｊ当たりの物理レイヤデータレート（ビット／秒）の関数として与えられえ、以下のように表される。

ここで、１０００がＰＬＰ内のビット数であり、ｌ_ｊは、非レイヤの送信モードに関しては１に等しく、レイヤの送信モードに関しては２に等しい、ｓｐ_ｊはＭＬＣ ｊに関してＰＬＰ当たりのスロット数を表し（レイヤの送信モードに関してｓｐ_ｊはベースレイヤＰＬＰおよびＭＬＣ ｉに関してはエンハンスメントレイヤ当たりのスロット数を表す）、ｎはネットワークｉでのリソースタイプＹに関するＭＬＣの合計数を表す。

送信モードの関数としてのＰＬＰ当たりのスロット数は、下記表１に示される。

ある態様では、異なるリソースタイプに属するＭＬＣは非オーバーラップシンボルにおいてスケジューリングされる。上記の例は図５に示され、ＦＤリソース、ＩＰＤＳリソースおよびオーバーヘッドリソースが「リアルタイム以外の」（ＯＲＴ）リソースとまとめて呼ばれる。図５によって示されたスロット割り当て規則に基づいて、ネットワークｉにおけるタイプＹリソースに関するフレーム当たりのデータシンボル数は、スーパーフレームＳｌｏｔ^ｉ _Ｙ当たりのスロット合計数の関数として与えられ得、下記のように表される。

ここで、４はスーパーフレーム当たりのフレーム数であり、７はＯＦＤＭシンボル当たりのスロット数であり、ｅ_ＹはリソースタイプＹのスロット割り当て効率である。

受信デバイスでのターボデコーダは、単一のＯＦＤＭシンボルにおいてデコードされうるターボパケット数を制限する。これは、ある送信モードのＭＬＣ割り当てがとることができる最大のスロット高さに制約を課する。

ＯＲＴリソースは、２つのＯＲＴリソースにターボパケットコンフリクトがないそれらの最大のスロット高さに基づいてフレームに配置される。あるリソースタイプにおけるすべてのＭＬＣに関して用いられたスロット高さは同じであると仮定されている。スロット割り当て効率はＦＬＯネットワーク特殊データとしてＮＲＰロジック回路２０２に提供される。

オーバーヘッドリソーススケジューリング
ある態様では、オーバーヘッドリソースにおけるフローは転送レイヤに固定データレートで送信される。オーバーヘッドリソーススケジューリングアルゴリズムの要約は以下のとおりである。

入力： スケジューリングされるオーバーヘッドリソース。

出力： オーバーヘッドリソースによって要求される物理データレート（Ｄ^ｉ _ｏ）、およびオーバーヘッドリソースによって要求されるフレーム当たりのＯＦＤＭデータシンボル数（Ｓ^ｉ _ｏ）。

アルゴリズム： 式（１）にしたがって、アプリケーションレイヤデータレートおよびプロトコルオーバーヘッドに基づくオーバーヘッドリソースに関する合計の物理レイヤデータレート（Ｄ^ｉ _ｏ）を計算する。式（２）および（３）にしたがって、合計の物理レイヤデータレートおよび送信モードに基づくオーバーヘッドリソースによって要求されるＯＦＤＭシンボル（Ｓ^ｉ _ｏ）の数を計算する。

リアルタイムリソーススケジューリング
ＲＴリソースは、それらのサブタイプに基づいてＲＴ音声／スライドリソースおよびＲＴ音声／ビデオリソースに分割されうる。ＲＴ音声／スライドリソースは、異なるＭＬＣによって運ばれるオーディオフローおよびスライドフローを具備する。ＲＴ音声／ビデオリソースは、異なるＭＬＣによって運ばれるオーディオフローおよびビデオフローを具備する。

オーディオフローおよびスライドフローの両方については、必要なアプリケーションレイヤデータレート（Ｂ_ｉ）は、リソースコンフィグレーションに記述されるようなフローの平均データレートを表わす固定値である。

ビデオエンコーディングによって導入されたデータレート変動により、Ｂ_ｉはビデオフローについてランダム変数である。それらのデータレート特性に基づいて、ビデオフローは異なるトラフィッククラスに分類される。トラフィッククラスｊごとに、次のＱｏＳ要件は適用される。
１． トラフィッククラス内の「典型的な」フローに関する平均データレート（μ_ｉ）。
２． トラフィッククラス内の「典型的な」フローに関する標準データレート偏差（σ_ｉ）。

ＲＴビデオフローｉごとに瞬間のデータレートを仮定することは、中心極限定理にしたがって、そのトラフィッククラスによって特定されるように平均μ_ｉおよび標準偏差σ_ｉで独立して分布するので、全てのＲＴビデオフローの瞬間の合計データレート（Ｂ_Ｖ）は、平均μ＝Σ_ｊｎ_ｊμ_ｊおよび標準偏差σ＝√Σ_ｊｎ_ｊσ_ｊ ^２での正規部分にしたがう。ここで、ｎ_ｊはトラフィッククラスｊ内のビデオフロー数を表す。したがって、Ｂｖがある値（Ｂ_{Ｖ＿ｍａｘ}）未満である確率は次のように与えられうる。

ここでΦ（ｚ）は標準正規分布に関する分布関数である。

瞬間のトラフィック要求Ｂｖがネットワークのキャパシティを超える場合、再エンコードするスキームは、合計トラフィックがスーパーフレームに収まることができるようなビデオフローのデータレートを縮小するために用いられる。しかしながら、頻繁な再エンコードは、ビデオ品質を下げ、悪いユーザ体験に導く可能性がある。したがって、ＲＴリソースプランニングは、ＲＥＥＮＣＯＤＥ＿ＰＲＯＢパラメータによって指定されるように、スーパーフレーム当たりの目標最大再符号化確率に基づいてＮＲＰロジック回路２０２で行われる。

瞬間のビデオデータレートＢｖがスーパーフレームにおけるＲＥＥＮＣＯＤＥ＿ＰＲＯＢより高い確率を有するＢ_{Ｖ＿ｍａｘ}を超えないような目標の上限を与えられたので、次の関係が適用される。

任意の目標確率ＲＥＥＮＣＯＤＥ＿ＰＲＯＢについては、Ｂ_{Ｖ＿ｍａｘ}は正規分布関数の逆関数によって計算されうる。いくつかの一般に使用される値は、以下の表２で与えられる。

ＲＴプロトコルオーバーヘッドおよび式（２）にしたがって、ビデオフローはすべて同じ送信モードを有していると仮定すると、ネットワークｉでＲＴリソースによって要求されるスーパーフレーム当たりのデータスロット数は、次のように表現されうる。

ここで、ｘはＲＴ Ａ／Ｖリソースの数であり、ｙはネットワークｉでのＲＴ Ａ／Ｓリソースの数であり、ＤＡ＿ｊおよびＤＳ＿ｊは式（１）にしたがってフローｊごとに計算され得、ｌ_Ｖはビデオフローの送信モードに基づいて計算され得、ｌ_Ａ＿ｊおよびｌ_Ｓ＿ｊはオーディオまたはスライドＭＬＣの送信モードに基づいて計算され得、ＶＩＤＥＯ＿ＦＤＳ＿ＯＶＨＤはビデオ送信モードおよび式（１）にしたがって計算されたビデオフローに関するプロトコルスタックオーバーヘッドである。

式（３）にＳｌｏｔ^ｉ _ＲＴを適用すると、ネットワークｉ（Ｓ^ｉ _ＲＴ）におけるＲＴリソースによって要求されるフレーム当たりのデータシンボル数は計算されうる。

ネットワークｉでのＲＴリソーススケジューリングに関する要約は以下に提供される。
入力：
１．スケジューリングされるべきＲＴリソース。
出力：
１．ＲＴリソースアルゴリズムによって要求されるフレーム当たりデータシンボルの最大値（Ｓ^ｉ _ＲＴ）
アルゴリズム：
１．式（１）にしたがってアプリケーションレイヤデータレートおよびプロトコルオーバーヘッドに基づいたスライドフローに関する合計の物理レイヤデータレートを計算する。
２．式（１）にしたがってアプリケーションレイヤデータレートおよびプロトコルオーバーヘッドに基づいたオーディオフローに関する合計の物理レイヤデータレートを計算する。
３．合計のＲＴビデオデータレートがＲＴ＿ＲＥＥＮＣＯＤＥ＿ＰＲＯＢより高い確率を有するスーパーフレームでの境界を越えないように、ＲＴビデオフローに関する上限Ｂ_{Ｖ＿ｍａｘ}を計算する。
４．式（１）にしたがってＢ_{Ｖ＿ｍａｘ}およびプロトコルオーバーヘッドに基づいたビデオフローに関する合計の物理レイヤデータレートを計算する。
５．式（２）および（３）にしたがって、合計の物理レイヤＲＴトラフィック（音声、スライドおよびビデオ）、送信モードおよびＲＴパッキング効率に基づいたＲＴリソースＳ^ｉ _ＲＴによって要求されるＯＦＤＭシンボルの最大値を計算する。

ＩＰＤＳリソーススケジューリング
ＩＰＤＳリソースは、ＦＬＯ転送レイヤの最上にあるアプリケーションレイヤコンテンツを運ぶためにＵＤＰ／ＩＰプロトコルを用いる。ＩＰＤＳリソースはそれぞれ、ＦＬＯ転送レイヤ（Ｂ_ｊ）に入力される、ＩＰＤＳフローの平均データレート入力がリソースコンフィグレーションにおいて与えられるＩＰＤＳフローを含んでいる。

式（２）によれば、ＩＰＤＳリソースによって要求されるスーパーフレーム当たりのデータスロット（Ｓｌｏｔ^ｉ _ＩＰＤＳ）は、次のように表現することができる。

ここでｎはネットワークｉにおけるＩＰＤＳリソースの合計数であり、Ｄ_ＩＰＤＳ＿_ｊは、式（１）とＢ_ｊにしたがってフローｊごとに計算されえ、ｌ_ＩＰＤＳ＿_ｊはＩＰＤＳフローの送信モードに基づいて計算されうる。

式（３）にＳｌｏｔ^ｉ _ＩＰＤＳを適用すると、ネットワークｉにおけるＲＴリソースによって要求されるフレーム当たりのデータシンボル数（Ｓ^ｉ _ＩＰＤＳ）は計算されうる。

ネットワークｉでのＩＰＤＳリソーススケジューリングに関する要約は以下で提供される。
入力：
１．スケジューリングされるべきＩＰＤＳリソース。
出力：
１．ＩＰＤＳリソース（Ｓ^ｉ _ＩＰＤＳ）によって要求されるフレーム当たりのデータシンボル数。
アルゴリズム：
１．式（１）と式（７）にしたがって、転送レイヤ入力データレートおよびプロトコルオーバーヘッドに基づいたＩＰＤＳリソースに関する毎秒のデータスロットの合計数を計算する。
２．式（３）にしたがって、毎秒データスロットの合計数に基づいた、ＩＰＤＳリソース（Ｓ^ｉ _ＩＰＤＳ）によって要求されるＯＦＤＭシンボル数を計算する。

キャパシティ判定
ある態様では、システムは、ＴＮキャパシティが、Ｌ_ＯＵＴにおける、すべてのオーバーヘッド、ＲＴおよびＩＰＤＳリソースに利用可能かどうかを判定するために動作する。全てのオーバーヘッド、ＲＴおよびＩＰＤＳリソースを提供するネットワークｉに十分なキャパシティがあることを保証するために、下記条件を満たさなければならない。

ここでＳ^ｉ _{ａｖａｉｌ}はネットワークｉにおけるフレーム当たりの利用可能なデータシンボルである。そうでなければ、ブロック３０６においてスケジュール条件は失敗し、スケジュール出力リストＬ_ＯＵＴは、入力リストにある候補リソースよりも少ない。

ファイル配信リソーススケジューリング
種々の態様における、ＦＤリソースプランニングは図３にしたがって発生し以下に述べられる。

アプリケーションレイヤオーバーヘッド
デバイスがＲＡＮ上でのＦＤ提示コンテンツを正常に受け取るのを防ぐ２つのタイプの割込がある。
１． デバイスでのデコード失敗およびパケット破損に導く短期の無線チャネル消去。
２． クライアントが提示コンテンツ（例えば同時ＲＴチャネル受信または他のアプリケーションで導入されたＣＰＵ割込）を受け取ることを無効にするデバイスでの長期的な内部割込み。

無線チャネル消去による短期のパケット損失を克服するために、メッセージコーディングスキームは提示コンテンツに適用される。ＦＤ提示は、同じサイズを有するｎコードパケットを生成するために、等しいサイズのｋデータパケットへ分けられる。コードパケットはクライアントへ向けてＲＡＮ上にブロードキャストされる。クライアントは、少なくとも（１＋ε）＊ｋコードパケットがデバイスによって正常に受け取られる場合、提示をデコードすることができる。

デバイス上の同時問題による長期的なパケット受信割込みを克服するために（例えば、ユーザがＲＴチャネルを表示している）、提示はそれぞれＦＤ＿ＮＵＭ＿ＩＮＳＴＡＮＣＥ回反復して配信される。提示反復インスタンスはそれぞれ独立してエンコードされ配信され、同じ提示について任意の２つのインスタンスの配信開始時刻の間の最小のギャップは、ＦＤ＿ＭＩＮ＿ＧＡＰである。

ＦＤリソースに関する用語
次の概念はＦＤリソースプランニングの理解を促進するために導入される。

配信ウィンドウ
配信ウィンドウ（ＤＷ）は、提示インスタンスがデバイスに配信される、スケジューリングされた期間である。提示インスタンスごとに、メッセージ符号化スキームの使用により、コンテンツ配信はデバイス観点から２つのステップに分割することができる。それはコンテンツ収集およびコンテンツデコードである。

図６は、次のコンポーネントを具備するプロビジョニングシステムの態様における使用に関する配信ウィンドウ（ＤＷ）を示すダイヤグラム６００を示す。
１． ブロードキャストウィンドウ（ＢＷ）：提示インスタンスのコードパケットが空中上でブロードキャストされる期間。
２． デコード期間（ＤＤ）：ブロードキャストウィンドウ終了時刻の後、デバイスが提示インスタンスの成功したデコードをするための期間。

スケジュールウィンドウ
図６は、プロビジョニングシステムの態様での使用に関する提示の最初のインスタンスに関するスケジュールウィンドウを示すダイヤグラム６０２を示す。スケジュールウィンドウ（ＳＷ）は、提示インスタンスが配信のために利用可能な期間を指定する。任意の提示インスタンスについて、配信ウィンドウはスケジュールウィンドウの一部でなければならない。提示インスタンスについてスケジュールウィンドウは以下のように計算される。
１． 提示ｊの最初のインスタンスのスケジュールウィンドウ開始時刻は、Ｔ_Ｆ＿ｊ＋ＦＤ＿ＢＥＴＡによって与えられ、ここでＴ_Ｆ＿ｊが提示ｊのフェッチ時間であり、ＦＤ＿ＢＥＴＡは提示フェッチ時刻と提示フェッチ期限との間の期間である。Ｔ_Ｆ＿ｊ＋ＦＤ＿ＢＥＴＡより早い時刻では、提示インスタンスは、提示コンテンツがシステムにおいて利用可能ではないので、送信されえない。
２． 提示ｊの（ｋ＋１）インスタンスに関するスケジュールウィンドウ開始時刻は、提示ｊたすＦＤ＿ＭＩＮ＿ＧＡＰのｋ番目のインスタンスの配信ウィンドウ開始時刻によって与えられる。それより早い時刻では、提示インスタンスは、ＦＤ＿ＭＩＮ＿ＧＡＰ制約を破ることなしでは送信されえない。したがって、提示ｊのｋ番目のインスタンスがスケジューリングされなければ、提示の（ｋ＋１）インスタンスはスケジュールウィンドウ開始時刻を持っておらず、したがって、配信のためにスケジュールされえない。

３． 提示ｊのｋ番目のインスタンスに関するスケジュールウィンドウ終了時刻は、Ｔ_Ｖ＿ｊ−（ＦＤ＿ＮＵＭ＿ＩＮＳＴＡＮＣＥ−ｋ）＊ＦＤ＿ＭＩＮ＿ＧＡＰによって与えられ、Ｔ_Ｖ＿ｊは提示ｊの表示時間である。それより遅い時間では、提示インスタンスは送信されえない。そうでなければ、提示の最後のインスタンスが、ＦＤ＿ＭＩＮ＿ＧＡＰ制約を破ることなしに提示表示時間前にデバイスへ配信され得ない。

ＦＤ帯域幅計算
ＦＤリソースが運ぶことを対象としているので、遅延は非リアルタイムコンテンツを許容する。ＦＤリソースは、スケジュール可能なオーバーヘッドリソース、ＲＴリソースおよびＩＰＤＳリソースの残存のキャパシティでネットワークにおいてスケジューリングされる。したがって、ＦＤリソースに関するフレーム当たりの平均の利用可能なＯＦＤＭシンボルは、次のように与えられうる。

Ｓ^ｉ _ＦＤが与えられていて、式（３）および（２）の逆によれば、ＦＬＯ転送レイヤＢ^ｉ _ＦＤでの利用可能なＦＤスループットは次のように計算されうる。

ここでｌ_ＦＤは、ＦＤリソースの送信モードに基づいて、計算されえて、ＦＤ＿ＦＤＳ＿ＯＶＨＤはＦＤリソースに関するＦＬＯプロトコルスタックオーバーヘッドである。

すべてのＦＤリソースの送信モードが同じであると仮定されていることに注意すること。

［００９６］ ハードウェア制約により、デバイスに関する平均ファイル書出し速度はＭＡＸ＿ＦＤ＿ＡＶＥ＿ＲＡＴＥを超えることができない。他方では、非常に低いデータレートでＦＤリソースを少しずつ移動させることは、デバイス上での電力消費を高める。したがって、Ｂ^ｉ _ＦＤがＭＩＮ＿ＦＤ＿ＡＶＥ＿ＲＡＴＥ未満である場合、ＦＤリソースはネットワークｉにおいてスケジューリングされなくてもよい。ネットワークｉでのＦＤリソーススケジューリングの要約は以下に提供される。
入力：
１．フレーム当たりの利用可能なＯＦＤＭデータシンボル（Ｓ^ｉ _{ａｖａｉｌ}）
２．オーバーヘッドリソースによって要求されるフレーム当たりのＯＦＤＭデータシンボル（Ｓ^ｉ _Ｏ）
３．ＩＰＤＳリソースによって要求されるフレーム当たりのＯＦＤＭデータシンボル（Ｓ^ｉ _ＩＰＤＳ）
４．ＲＴリソースによって要求されるフレーム当たりのＯＦＤＭデータシンボル（Ｓ^ｉ _ＲＴ）
出力：
１．ＦＤリソースに関するＦＬＯ転送レイヤ帯域幅（Ｂ^ｉ _ＦＤ）
アルゴリズム
１．ＦＤリソースに利用可能なシンボルの残存数を次のように計算する。
Ｓ^ｉ _ＦＤ＝Ｓ^ｉ _{ａｖａｉｌ}−Ｓ^ｉ _Ｏ−Ｓ^ｉ _ＩＰＤＳ−Ｓ^ｉ _ＲＴ
２．式（１０）にしたがって、Ｓ^ｉ _ＦＤ、プロトコルオーバーヘッドおよび送信モードに基づいたＦＤリソースに利用可能な残存の帯域幅Ｂ^ｉ _ＦＤを計算する。

Ｂ^ｉ _ＦＤ＞ＭＡＸ＿ＦＤ＿ＡＶＥ＿ＲＡＴＥである場合、
Ｂ^ｉ _ＦＤ＝ＭＡＸ＿ＦＤ＿ＡＶＥ＿ＲＡＴＥになる。
ＢｉＦＤ＜ＭＩＮ＿ＦＤ＿ＡＶＥ＿ＲＡＴＥの場合、
スケジューリングは失敗する。

ＦＤ提示スケジューリングアルゴリズム
ＮＲＰロジック回路２０２によって提供されるＦＤプランニングアルゴリズムは、システムでスケジューリングされうるＦＤリソースのリストを出力する。スケジュール可能なＦＤリソースにおける提示ごとに、ＮＲＰロジック回路２０２は、次の制約によりＦＤリソースを運ぶ各ネットワークにおいて提示インスタンス当たり１つの配信ウィンドウを生成する。
１． 各配信ウィンドウを連続的に維持すること。システムは、１つの提示インスタンスに対して複数の配信ウィンドウを許可しなくてもよい。
２． 配信ウィンドウは互いにオーバラップしなくてもよい。サーバは、次の理由で一度に１つの提示インスタンスを配信してもよい。
− 第１に、デバイスの全体のファイル書出し速度は、同時のファイル書き込み工程数が増加するにつれて減少する。
− 第２に、複数の提示を同時に受け取ることは、次に‥‥デバイスについてのＣＰＵおよび必要メモリをデバイスでのより高いＣＰＵおよびメモリ要求を招く。
− 第３に、デバイスが高データレートで各提示を受け取ることはより電力効率的である。
− 第４に、クライアントは提示収集およびデコードを同時にサポートしなくてよい。

その結果、ＦＤ提示スケジューリング問題は、提示ごとのＦＤ＿ＮＵＭ＿ＩＮＳＴＡＮＣＥ相互依存インスタンスで、Ｎ個の提示に関して先制的でないスケジューリングの問題になる。当業者によって知られるように、依存タスクに関する先制的でないスケジューリングはＮＰ困難な問題である。

以上示されるように、任意の提示については、（ｋ＋１）インスタンスに関するスケジュールウィンドウは、ｋ番目のインスタンスがスケジューリングされた後、計算だけされてもよい。言いかえれば、提示はそれぞれ、いつでもスケジューリングに関して資格があるただ１つのインスタンスを有してもよい。したがって、提示当たりのＦＤ＿ＮＵＭ＿ＩＮＳＴＡＮＣＥインスタンスでのＮ個の提示をプランニングするタスクは、Ｎ個の提示の各々から現在資格のあるインスタンスをスケジューリングすることの再帰的なサブタスクに換言されうる。ここで、異なる提示のインスタンスは独立している。サブタスクごとに、ＮＲＰロジック回路２０２は、先制的でない最も早い期限の第１の発見的問題解決法に基づいて提示インスタンスをスケジューリングする。

図７は、プロビジョニングシステムの態様での使用に関するＦＤリソースプランニングアルゴリズムのための典型的な方法７００を示す。方法７００の明瞭さおよび理解のために、次の定義が提供される。
Ｌ：スケジューリングされるべき提示リスト｛Ｐ１，…，Ｐｎ｝
ｋ：提示ｊに関する現在のインスタンス
ＢＷＳＴｊ＿ｋ：提示ｊのｋ番目のインスタンスに関するＢＷ開始時刻
ＢＷＥＴｊ＿ｋ：提示ｊのｋ番目のインスタンスに関するＢＷ終了時刻
ＤＷＳＴｊ＿ｋ：提示ｊのｋ番目のインスタンスに関するＤＷ開始時刻。

ＤＷＥＴｊ＿ｋ：提示ｊのｋ番目のインスタンスに関するＤＷ終了時刻
ＰＲＮ＿ＳＩＺＥｊ：提示ｊのサイズ
Ｒｊ：提示ｊに関するメッセージコーディングレート（ｎ／ｋ）
Ｅｐｓｉｌｏｎｊ：提示ｊに関するイプシロンパラメータ
ＤＤｊ：提示ｊに関するデコード時間
Ｔ：スケジュール時間
ＮＲＰロジック回路２０２は、提示インスタンスの配信ウィンドウがスケジューリングされうる時間を示す「スケジュール時間」を維持する。個々の資格のある提示インスタンスのスケジュールウィンドウに基づいて、ＮＲＰは、どの提示インスタンスが現在のスケジュール時間でのスケジュールに「利用可能である」かを決定する。図７に示すように、ＮＲＰロジック回路２０２は、下記に記述されるように、先制的でない最も早いスケジュールウィンドウ終了時刻第１発見的問題解決法に基づいてＦＤリソースの利用可能な提示インスタンスをスケジューリングする。

ブロック７０２では、ＮＲＰロジック回路２０２は、すべてのＦＤリソースの提示をリストＬに入れて、各提示の最初のインスタンスに関してスケジュールウィンドウを計算する。最初に、ＮＲＰロジック回路２０２は、スケジュール時間を０に設定する。

ブロック７０４では、ＮＲＰロジック回路２０２は、提示リストＬにおける最も早いスケジュールウィンドウ開始時刻にスケジュール時間を進める。提示インスタンスは、そのスケジュールウィンドウ開始時刻が新規のスケジュール時間に等しい場合、「利用可能」になる。

ブロック７０６では、ＮＲＰロジック回路２０２は、スケジュール時間からの最も早いスケジュールウィンドウ終了時刻を有している利用可能な提示インスタンス（つまり提示ｊのｋ番目のインスタンス）を見つける。利用可能な提示インスタンス間のつながりは、高から低へリソースのプランニング優先度にしたがって断絶される。ＮＲＰロジック回路２０２は、スケジュール時間の提示ｊのｋ番目のインスタンスの配信ウィンドウ開始時刻を設定する。

ブロック７０８では、ＮＲＰロジック回路２０２は、提示ｊのｋ番目のインスタンスに関する配信ウィンドウ終了時刻を計算する。コンタクトウィンドウ開始時刻、コンタクトウィンドウ終了時刻およびコンタクト期間は、提示インスタンスに関して計算される。

ブロック７１０では、判定は、計算された配信ウィンドウが１以上の既存の配信ウィンドウにオーバラップするかどうかに関してなされる。真の場合、方法７００は７１２に進み、配信ウィンドウ開始時刻がオーバラップした配信ウィンドウの最新の終了時刻に進められ、次に方法７００がブロック７０８での動作を繰り返すために進む。

ブロック７１４では、任意の提示インスタンスのスケジュールウィンドウ開始時刻がスケジュール時間および配信ウィンドウ終了時刻以内にある場合、ＮＲＰロジック回路２０２は提示インスタンスを利用可能に設定する。

ブロック７１６では、判定は、計算された配信ウィンドウ終了時刻が、利用可能な提示インスタンスの任意のスケジュールウィンドウから外れるかどうかに関してなされる。そうならば、方法はブロック７１８に進み、ネットワークｉ内のＦＤリソースに関するＬ_ＯＵＴのスケジューリングが失敗する。そうでなければ、スケジュール時間は配信ウィンドウ終了時刻に進められる。

ブロック７２０では、判定は提示ｊのインスタンスがすべてスケジューリングされるかどうかに関してなされる。すべてがスケジューリングされている場合、方法は７２２に進み、提示ｊが提示リストＬから取り除かれる。ブロック７２４では、判定はリストＬにおいてさらに提示があるかどうかに関してなされる。リストＬにおいて提示がこれ以上ない場合、ＦＤリソースに関するＦＤスケジューリングはブロック７２６で成功する。

ブロック７２８では、ＮＲＰロジック回路２０２は、ＦＤ＿ＭＩＮ＿ＧＡＰとｋ番目のインスタンスの配信ウィンドウ開始時刻の和に、提示ｊの（ｋ＋１）インスタンスに、関するスケジュールウィンドウ開始時刻を設定する。

ブロック７３０では、ＮＲＰロジック回路２０２は利用可能な提示インスタンスがリストＬにあるかどうかに関して判定をする。現在のスケジュール時間で利用可能な提示インスタンスがある場合、ＮＲＰロジック回路はブロック７０６での動作を繰り返す。そうでなければ、ＮＲＰロジック回路はブロック７０４に進む。

０秒としての日曜ＡＭ１２：００でのその週の開始、および６０４７９９秒としての土曜ＰＭ１１：５９：５９でのその週の終了を有するＵＴＣタイムゾーン（ＧＭＴ）に関する１週間の期間テンプレートに基づいて、ＮＲＰロジック回路２０２のスケジュール時間およびリソース定義でのシステム時間が指定されることに注意する。ＮＲＰロジック回路２０２は、モジュロ演算を用いて、その週の終了でタイム値を包み込むために動作する。

要約
下記は、プロビジョニングシステムの態様において提供される動作を要約する。
１． 候補リソース生成
目標とされたサービスコンテンツを運ぶための候補リソースエンティティを生成する。
２． リソースプランニング
候補リソースを運ぶための転送ネットワークキャパシティを決定する。
３． サービスアソシエーションへのリソース
転送ネットワークでの目標とされたサービスコンテンツを運ぶためにプランニングされたリソースを割り当てる。

４． リソースコンフィグレーション配信
トラフィックポリシーイング、コンテンツ配信および受信を促進する受信デバイスと同様の、リソースコンフィグレーション配信およびＴＮコンポーネントへのそのサービスアソシエーション。

図８は、プロビジョニングシステムの態様での使用に関するＮＰＲロジック回路８００の図を示す。例えば、ＮＰＲロジック回路８００は、図２に示されるＮＰＲ２０２としての使用に適している。ある態様では、ＮＰＲロジック回路８００は、すべてデータバス８０８につながれた、入力ロジック回路８０２、処理ロジック回路８０４および出力ロジック回路８０６を具備する。

入力ロジック回路８０２は、ＣＰＵ、集積回路、プロセッサ、ゲートアレイ、ハードウェアロジック回路、メモリエレメントおよび（または）ハードウェアとソフトウェアの組み合わせの少なくとも１つを具備する。入力ロジック回路８０２はオペレータおよびコンフィギュレーションマネージャ（ＣＭ）からの入力を受け取るように構成される。例えば、オペレータからの入力は、１以上のＴＮ上で配信されるべき目標とされたサービスについての任意の望ましい情報を具備する。それは、選択されたサービスコンポーネントに関連した平均データレートおよび標準偏差を含んでもよい。ある態様では、ＣＭからの入力は上で説明されたような任意の望ましいＴＮ依存および独立情報を具備する。

処理ロジック回路８０４は、ＣＰＵ、集積回路、プロセッサ、ゲートアレイ、ハードウェアロジック回路、メモリエレメントおよび（または）ソフトウェアを実行するハードウェアの少なくとも１つを具備する。処理ロジック回路８０４は、１以上のＴＮ上で配信されるべき目標とされたサービスを設定しプランニングを立てるために、上で説明されたモデリング手順およびアルゴリズムを行なうように構成される。一旦、目標とされたサービスの配信に関する設定とプランニングが決定されると、処理ロジック回路８０４は、転送ネットワークで目標とされたサービスを運ぶために、リソースエンティティを割り当てるサービスアソシエーションを生成するために動作する。その後、処理ロジック回路８０４は、ＴＮおよび（または）１以上の受信デバイスにリソースコンフィグレーションおよびサービスアソシエーションを配信するために動作する。例えば、処理ロジック回路８０４は、リソースコンフィグレーションおよびサービスアソシエーションを出力するために出力ロジック回路８０６を制御する。

出力ロジック回路８０６は、ＣＰＵ、集積回路、プロセッサ、ゲートアレイ、ハードウェアロジック回路、メモリエレメントおよび（または）ハードウェアとソフトウェアの組み合わせの少なくとも１つを具備する。出力ロジック回路８０６はネットワークプロビジョニング結果を出力するように構成される。ある態様では、出力ロジック回路８０６は、プロビジョニングが成功したかどうか示すプロビジョニング結果を出力する。

ある態様では、プロビジョニングシステムは機械読取可能な媒体上で具現されたコード（「コード」）または１以上のプログラム命令（「命令」）のセットを具備し、それはコンピュータまたは少なくとも１つのプロセッサまたは集積回路（例えば処理ロジック回路８０４でのプロセッサ）によって実行されたときに、ここに説明された機能を提供する。例えば、コードは、フロッピー（登録商標）ディスク、ＣＤＲＯＭ、メモリカード、ＦＬＡＳＨメモリデバイス、ＲＡＭ、ＲＯＭ、またはＮＲＰロジック回路８００に接続する他のタイプのメモリデバイスまたは機械読取可能な媒体のような機械読取可能な媒体からＮＲＰロジック回路８００にロードされてもよい。別の態様において、コードは、外部デバイスまたはネットワークリソースからＮＲＰロジック回路８００へダウンロードされてもよい。コードは、プロセッサによって実行されたときに、ここで説明されたようにプロビジョニングシステムの態様を提供する。

図９は、プロビジョニングシステムの態様での使用に関する典型的なプロビジョニングロジック回路９００を示す。ある態様では、プロビジョニングロジック回路９００は、ここで説明したようにプロビジョニングシステムの態様を提供するように構成された１以上のモジュールを具備する少なくとも１つのプロセッサまたは集積回路によって実装される。例えば、モジュールは、プロビジョニングシステムの態様を提供するために、それぞれハードウェアおよび（または）ソフトウェアを実行するハードウェアを具備する。

プロビジョニングロジック回路９００は、１以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成する手段９０２を具備する第１のモジュールを具備し、リソースエンティティは、転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化される。例えば、ある態様では、手段９０２は処理ロジック回路８０４を具備する。

プロビジョニングロジック回路９００は、１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する手段９０４を具備する第２のモジュールを具備する。例えば、ある態様では、手段９０４は処理ロジック回路８０４を具備する。

種々の具体的なロジック回路、論理ブロック、モジュール、および本明細書で開示された態様に関連して説明された回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブルロジックデバイス、個別のゲートまたはトランジスタロジック回路、個別のハードウェア構成機器またはここに説明された機能を行なうことを目指した任意のそれらの組み合わせに実装されてもよいし行なわれてもよい。汎用プロセッサはマイクロプロセッサでもよいが、代替案では、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラまたは状態機械でもよい。プロセッサは、コンピューティング装置の組合せ（例えば、ＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと共に１以上のマイクロプロセッサ、または任意の別のそのような構成）として実装されてもよい。

本明細書で開示された態様に関連して説明された方法またはアルゴリズムのステップは、直接ハードウェアで、プロセッサによって実行されたソフトウェアモジュールで、または２つの組合せにおいて具現されてもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭまたは当技術において既知の記憶媒体の他の形式で存在してもよい。典型的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるような、プロセッサにつながれる。代替案では、記憶媒体はプロセッサに統合されてもよい。プロセッサ及び記憶媒体はＡＳＩＣ内に存在してもよい。ＡＳＩＣはユーザ端末内に存在してもよい。代替案では、プロセッサ及び記憶媒体はユーザ端末における個別コンポーネントとして存在してもよい。

開示された態様の詳細な説明は、いずれか当業者が本発明を作るか用いることを可能にするために提供される。これらの態様への種々の変更は、当業者に即座に明白である可能性があり、本明細書で定義された総括的な原理は、この発明の精神または範囲から外れずに、他の態様（例えばインスタントメッセージングサービスまたは任意の一般的な無線データ通信アプリケーションにおいて）に適用されてもよい。このように、本発明は、本明細書で示された態様に限定されることを意図されないが、本明細書で開示された原理と新規な特徴に矛盾しない最も広い範囲を与えられることになっている。「典型的な」という単語は、「例、インスタンスまたは実例の役目をする」ことを意味するために排他的に本明細書で用いられる。「典型的である」と本明細書で説明された任意の態様は、好ましいとして、または他の態様に対して有利であるとして、必ずしも解釈される必要はない。

結果として、プロビジョニングシステムの態様が本明細書で示され説明されているが、それらの精神または本質的な特性から外れずに、態様に種々の変更を行なうことができることは認識される。したがって、明細書での開示と詳細な説明は、次のクレームにおける述べられる発明の範囲の説明に役立つが、制限はされないように意図されている。

Claims (35)

1. 通信ネットワークでのリソースプランニング方法であって、
   １以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成し、前記リソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、
   前記１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定することを具備する方法。
2. 前記生成することは、前記１以上の目標とされたサービスに関連したアプリケーションレイヤサービス品質要件と、前記１以上の転送ネットワークに関連した使用要件との間で変換するために、転送ネットワークプロトコルスタックオーバーヘッドを用いることを具備する請求項１の方法。
3. 前記生成することは、関連するリソースエンティティを生成する選択された目標とされたサービスに関連した可変ビットレートトラフィックの集められたトラフィック特性を推定するために統計モデルを用いることを具備する請求項１の方法。
4. 前記１以上のリソースエンティティに優先度を割り当て、
   それぞれのリソースエンティティが、そのそれぞれの優先度に基づいて、前記１以上の転送ネットワークによってサポートされうるかどうかを判定することをさらに具備する請求項１の方法。
5. 非リアルタイムトラフィックのために用いることができる前記１以上の転送ネットワークに関連したリソースの量を判定することをさらに具備する請求項１の方法。
6. 前記判定することは、繰り返し発生するテンプレートに基づいて、前記１以上のリソースエンティティの少なくとも一部分をスケジューリングすることを具備することを特徴とする請求項１の方法。
7. 前記１以上の転送ネットワークで前記１以上の目標とされたサービスを運ぶために前記１以上のリソースエンティティを割り当てるサービスアソシエーションを生成することをさらに具備する請求項１の方法。
8. 前記１以上の転送ネットワークおよび１以上の受信デバイスの少なくとも１つに、前記１以上のリソースエンティティおよび前記サービスアソシエーションを配信することをさらに具備する請求項７の方法。
9. 通信ネットワークでのリソースプランニング装置であって、
   転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つを受け取る入力ロジック回路と、
   １以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成する処理ロジック回路と、前記リソースエンティティは前記転送ネットワーク依存情報および前記転送ネットワーク独立情報の少なくとも１つからモデル化され、前記処理ロジック回路は前記１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する装置。
10. 前記処理ロジック回路は、前記１以上の目標とされたサービスに関連したアプリケーションレイヤサービス品質要件と、前記１以上の転送ネットワークに関連した使用要件との間で変換するために、転送ネットワークプロトコルスタックオーバーヘッドを用いる請求項９の装置。
11. 前記処理ロジック回路は、関連するリソースエンティティを生成する選択された目標とされたサービスに関連した可変ビットレートトラフィックの集められたトラフィック特性を推定するために統計モデルを用いる請求項９の装置。
12. 前記処理ロジック回路は、
    前記１以上のリソースエンティティに優先度を割り当て、
    それぞれのリソースエンティティが、そのそれぞれの優先度に基づいて、前記１以上の転送ネットワークによってサポートされうるかどうかを判定する請求項９の装置。
13. 前記処理ロジック回路は、非リアルタイムトラフィックのための用いることができる前記１以上の転送ネットワークに関連したリソースの量を判定する請求項９の装置。
14. 前記処理ロジック回路は、繰り返し発生するテンプレートに基づいて、前記１以上のリソースエンティティの少なくとも一部分をスケジューリングする請求項９の装置。
15. 前記処理ロジック回路は、前記１以上の転送ネットワークで運ぶために前記１以上のリソースエンティティを割り当てるサービスアソシエーションを生成する請求項９の装置。
16. 前記処理ロジック回路は、前記１以上の転送ネットワークおよび１以上の受信デバイスの少なくとも１つに、前記１以上のリソースエンティティおよび前記サービスアソシエーションを配信する請求項１５の装置。
17. 通信ネットワークでのリソースプランニング装置であって、
    １以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成する手段と、前記リソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、
    前記１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する手段と、を具備する装置。
18. 前記生成手段は、前記１以上の目標とされたサービスに関連したアプリケーションレイヤサービス品質要件と、前記１以上の転送ネットワークに関連した使用要件との間で変換するために、転送ネットワークプロトコルスタックオーバーヘッドを用いる手段を具備する請求項１７の装置。
19. 前記生成手段は、関連するリソースエンティティを生成する選択された目標とされたサービスに関連した可変ビットレートトラフィックの集められたトラフィック特性を推定するために統計モデルを用いる手段を具備する請求項１７の装置。
20. 前記１以上のリソースエンティティに優先度を割り当てる手段と、
    それぞれのリソースエンティティが、そのそれぞれの優先度に基づいて、前記１以上の転送ネットワークによってサポートされうるかどうかを判定する手段と、をさらに具備する請求項１７の装置。
21. 非リアルタイムトラフィックのために用いることができる１以上の転送ネットワークに関連したリソースの量を判定する手段をさらに具備する請求項１７の装置。
22. 前記決定手段は、繰り返し発生するテンプレートに基づいて、前記１以上のリソースエンティティの少なくとも一部分をスケジューリングする手段を具備することを特徴とする請求項１７の装置。
23. 前記１以上の転送ネットワークで前記１以上の目標とされたサービスを運ぶために前記１以上のリソースエンティティを割り当てるサービスアソシエーションを生成する手段をさらに具備する請求項１７の装置。
24. 前記１以上の転送ネットワークおよび１以上の受信デバイスの少なくとも１つに、前記１以上のリソースエンティティおよび前記サービスアソシエーションを配信する手段をさらに具備する請求項２３の装置。
25. 通信ネットワークでのリソースプランニングのためのコンピュータプログラム製品であって、機械読取可能な媒体を具備し、
    コンピュータに、１以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成させる第１コードセットと、前記リソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、
    前記コンピュータに、前記１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定させる第２コードセットと、を具備する機械読取可能な媒体。
26. 前記第１コードセットは、前記コンピュータに、前記１以上の目標とされたサービスに関連したアプリケーションレイヤサービス品質要件と、前記１以上の転送ネットワークに関連した使用要件との間で変換するために、転送ネットワークプロトコルスタックオーバーヘッドを用いさせる請求項２５の機械読取可能な媒体。
27. 前記第１コードセットは、前記コンピュータに、関連するリソースエンティティを生成する選択された目標とされたサービスに関連した可変ビットレートトラフィックの集められたトラフィック特性を推定するために統計モデルを用いさせる請求項２５の機械読取可能な媒体。
28. 前記第１コードセットは、前記コンピュータに、
    前記１以上のリソースエンティティに優先度を割り当てさせ、
    それぞれのリソースエンティティが、そのそれぞれの優先度に基づいて、前記１以上の転送ネットワークによってサポートされうるかどうかを判定させる請求項２５の機械読取可能な媒体。
29. 前記第１コードセットは、前記コンピュータに、前記１以上の転送ネットワークで運ぶために前記１以上のリソースエンティティを割り当てるサービスアソシエーションを生成させる請求項２５の機械読取可能な媒体。
30. 前記第１コードセットは、前記コンピュータに、前記１以上の転送ネットワークおよび１以上の受信デバイスの少なくとも１つに、前記１以上のリソースエンティティおよび前記サービスアソシエーションを配信する請求項２９の機械読取可能な媒体。
31. 通信ネットワークでのリソースプランニングを提供する少なくとも１つの集積回路であって、
    １以上の目標とされたサービスのリソース要件を表わす１以上のリソースエンティティをそれぞれ生成する第１モジュールと、前記リソースエンティティは転送ネットワーク依存情報および転送ネットワーク独立情報の少なくとも１つからモデル化され、
    前記１以上のリソースエンティティが１以上の転送ネットワークによってサポートされ得るかどうかを判定する第２モジュールと、を具備する少なくとも１つの集積回路。
32. 前記第１モジュールは、前記１以上の目標とされたサービスに関連したアプリケーションレイヤサービス品質要件と、前記１以上の転送ネットワークに関連した使用要件との間で変換するために、転送ネットワークプロトコルスタックオーバーヘッドを用いる請求項３１の少なくとも１つの集積回路。
33. 前記第１のモジュールは、
    １以上のリソースエンティティに優先度を割り当て、
    それぞれのリソースエンティティが、そのそれぞれの優先度に基づいて、前記１以上の転送ネットワークによってサポートされうるかどうかを判定する請求項３１の少なくとも１つの集積回路。
34. 前記第１モジュールは、前記１以上の転送ネットワークで前記１以上の目標とされたサービスを運ぶために前記１以上のリソースエンティティを割り当てるサービスアソシエーションを生成する請求項３１の少なくとも１つの集積回路。
35. 前記第１モジュールは、前記１以上の転送ネットワークおよび１以上の受信デバイスの少なくとも１つに、前記１以上のリソースエンティティおよび前記サービスアソシエーションを配信する請求項３４の少なくとも１つの集積回路。

Images