JP4787376B2 - マルチキャストベアラリソースを制御するための方法、装置、およびシステム - Google Patents

Description

関連出願の相互参照
本発明は、２００７年１月１３日に出願された中国特許出願第２００７１０１１１０１９．３号の優先権を主張する、２００８年５月７日に出願されたＰＣＴ／ＣＮ２００８／０７０９０４の出願であり、これら２件の出願の内容は参照により本明細書に組み込まれている。
本発明は、通信およびネットワークの分野に関し、特に、マルチキャストベアラリソースを制御するための方法、装置、およびシステムに関する。

インターネットプロトコルテレビジョン（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）（ＩＰＴＶ）サービスは、ブロードバンドＩＰネットワークに基づいており、主としてストリーミングメディアに焦点が合わせられている。従来のＴＶに比較して、ＩＰＴＶは、より豊富かつ柔軟なサービスをサポートすることと、包括的なＩＰＴＶ付加価値サービスプラットフォームを提供することと、通信、データ、ビデオ、およびオーディオなどのサービスを実現することとが可能である。ＩＰＴＶのうち、ライブテレビジョン／放送テレビジョン（ｌｉｖｅ ｔｅｌｅｖｉｓｉｏｎ／ｂｒｏａｄｃａｓｔ ｔｅｌｅｖｉｓｉｏｎ）（ＬＴＶ／ＢＴＶ）サービス、すなわち、ポイントツーマルチポイント通信においては、ソースによって生成されたデータが、複数の宛先ノードに送信される必要がある。現在のところ、ポイントツーマルチポイント通信の解決法は、ネットワーク帯域幅を効果的に利用して、帯域幅リソースの無駄を回避することが可能な、マルチキャスト技術である。

関連技術１：マルチキャスト技術をサポートするために、リソース受付制御サブシステム（Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）（ＲＡＣＳ）アーキテクチャが提案されており、これは、テレコミュニケーション・アンド・インターネット・コンバージド・サービス・アンド・プロトコルズ・フォー・アドバンスト・ネットワーキング（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ）（ＴＩＳＰＡＮ）において詳細に記載されている。

リソース受付制御を実装することによって、ＲＡＣＳは、トランスポートネットワークのリソースの正しくかつ適切な使用を確実にし、かくして、サービスのサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）（ＱｏＳ）を保証し、帯域幅およびサービスが使われてしまうのを防止するように、トランスポートネットワークの詳細をサービス層から隠し、サービス制御とトランスポート機能との分離をサポートし、そして、トランスポートネットワークのリソース利用状況を認識するようになる。図１は、ＲＡＣＳの機能アーキテクチャを示す。図中の主要なネットワーク要素について、以下で紹介する。

サービスベースのポリシー決定機能（ｓｅｒｖｉｃｅ−ｂａｓｅｄ ｐｏｌｉｃｙ ｄｅｃｉｓｉｏｎ ｆｕｎｃｔｉｏｎ）（ＳＰＤＦ）は、アプリケーション層への汎用インタフェースを提供し、基礎をなすネットワークトポロジおよび特定のアクセスタイプを隠し、サービスベースのポリシー制御を提供する。ＳＰＤＦは、アプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）（ＡＦ）の要求に従って、ローカルポリシーを選択し、その要求を、インターネットプトロコルサービス品質（ＩＰＱｏＳ）パラメータにマッピングし、そして、そのパラメータを、対応するリソースを要求するために、アクセスリソース受付制御機能（Ａｃｃｅｓｓ−Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）（Ａ−ＲＡＣＦ）およびボーダーゲートウェイ機能（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）（ＢＧＦ）に送信する。

Ａ−ＲＡＣＦは、アクセスネットワーク内に配置され、受付制御機能およびネットワークポリシー収束（ｎｅｔｗｏｒｋ ｐｏｌｉｃｙ ｃｏｎｖｅｒｇｅｎｃｅ）機能を有する。Ａ−ＲＡＣＦは、ＳＰＤＦからの要求を受信し、そして次に、記憶されたポリシーに従って受付制御を実現し、かくして、トランスポートリソースに対する要求を受け入れるか、または拒否する。Ａ−ＲＡＣＦは、ネットワーク接続情報（ｎｅｔｗｏｒｋ ａｔｔａｃｈｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）およびユーザＱｏＳリスト情報（ｕｓｅｒ ＱｏＳ ｌｉｓｔ ｉｎｆｏｒｍａｔｉｏｎ）を、ｅ４参照点（ｅ４ ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）を介して、ネットワーク接続サブシステム（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｍｅｎｔ Ｓｕｂ−Ｓｙｓｔｅｍ）（ＮＡＳＳ）から取得する。したがって、利用可能なネットワークリソースが、ネットワーク位置情報（例えば、アクセスユーザの物理的なノードアドレス）に応じて判定され得る。その一方で、ユーザＱｏＳリスト情報は、リソース割り当て要求が処理される際に参照される。

トランスポート層は、３つのタイプの機能エンティティを含む。それらのうち、ＢＧＦは、（コアボーダーゲートウェイ（ｃｏｒｅ ｂｏｒｄｅｒ ｇａｔｅｗａｙ）の機能を実現するために）アクセスネットワークとコアネットワークとの間に配置されてもよく、（インターネットボーダーゲートウェイ（Ｉｎｔｅｒｎｅｔ ｂｏｒｄｅｒ ｇａｔｅｗａｙ）の機能を実現するために）２つのコアネットワークの間に配置されてもよい、ボーダーゲートウェイである。ＳＰＤＦの制御下で、ＢＧＦは、ネットワークアドレス変換（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）（ＮＡＴ）、ゲーティング、ＱｏＳラベル、帯域幅制限、測定、およびリソース同期の機能を完了する。リソース制御実行機能（Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（ＲＣＥＦ）は、ゲーティング、ＱｏＳラベル、帯域幅制限、およびその他の機能を達成するために、Ａ−ＲＡＣＦによってＲｅ参照点を介して送信された、アクセスオペレータによって定義されたレイヤ２／レイヤ３（Ｌ２／Ｌ３）メディアストリームポリシーを実装する。レイヤ２終端機能（Ｌａｙｅｒ ２ Ｔｅｒｍｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）（Ｌ２ＴＦ）は、アクセスネットワーク内のレイヤ２接続を終端する機能エンティティである。ＲＣＥＦとＬ２ＴＦとは異なる機能エンティティであり、一般に、物理的装置ＩＰエッジ（ＩＰ Ｅｄｇｅ）上で一緒に実現される。

さらに、ＲＡＣＳ Ｒ２の最新のドラフトでは、リソース受付制御を実行するためにコアネットワーク内に配置される新しい機能、すなわち、コアＲＡＣＦ（Ｃｏｒｅ−ＲＡＣＦ）（Ｃ−ＲＡＣＦ）が定義されている。

関連技術２：マルチキャストベアラリソースの制御について行う以下の説明を容易にするために、ベアラ層ネットワーク（ｂｅａｒｅｒ ｌａｙｅｒ ｎｅｔｗｏｒｋ）は、図２に示すように、アクセスネットワーク、アクセス収束ネットワーク、およびコアネットワークという３つのセグメントに分割される。ユーザ装置（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）（ＵＥ）と、受付制御ポリシー実行ノード（ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｏｌｉｃｙ ｅｎｆｏｒｃｅｍｅｎｔ ｎｏｄｅ）（ＡＮまたはＩＰエッジであってもよい）との間のセグメントは、アクセスネットワークと呼ばれる。このノードと、コアボーダーノードとの間のセグメントは、アクセス収束ネットワークと呼ばれる。コアボーダーノードを越えるセグメントは、コアネットワークセグメントと呼ばれる。ＳＰＤＦは、ＡＦに、最終的なリソース許可結果を返す。

ＩＰＴＶマルチキャストサービスは、現在のところ、従来のネットワーク内で運用されているが、ＲＡＣＳ内でのマルチキャストベアラリソースの効果的な制御は実現されていない、ということを、発明者は、研究および適用の間に見出した。

したがって、本発明は、リソース受付制御サブシステム（ＲＡＣＳ）に基づいてマルチキャストベアラリソースを制御するように、マルチキャストベアラリソースを制御するための、方法、装置、およびシステムに関する。

本発明の方法は、以下のステップを含む。

ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信し、マルチキャストベアラリソースを制御する。

本発明のネットワークエンティティは、ＲＡＣＳ内に配置され、ベアラ層ネットワークエンティティからマルチキャストベアラリソースを制御する要求を受信するように適合された受信ユニットと、マルチキャストベアラリソースを制御するように適合された制御ユニットと、を含む。

本発明の、マルチキャストベアラリソースを制御するためのシステムは、マルチキャストベアラリソースを制御する要求を発する（ｉｎｉｔｉａｔｅ）ように適合されたベアラ層ネットワークエンティティと、ベアラ層ネットワークエンティティからマルチキャストベアラリソースを制御する要求を受信し、マルチキャストベアラリソースを制御するように適合されたＲＡＣＳ内のネットワークエンティティと、を含む。

本発明では、ユーザから、マルチキャストベアラリソースを制御する要求を受信した後で、ベアラ層ネットワークエンティティは、ＲＡＣＳに、マルチキャストベアラリソースを制御する要求を転送し、そして、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信した後で、ＲＡＣＳ内のネットワークエンティティは、マルチキャストベアラリソースを制御する。したがって、ＲＡＣＳは、マルチキャストトラフィックフローのリソース制御をサポートすることが可能である。このように、マルチキャストリソースのための管理および受付制御機能は、ベアラ層エンティティ内に導入される必要はない。その一方で、ユニキャストおよびマルチキャストリソースの集中型の統合された管理が達成されることが可能であり、したがって、ユニキャストサービスとマルチキャストサービスとがベアラリソースを完全に共用できることが保証される。

従来のＲＡＣＳの機能アーキテクチャを示す。 従来技術における、３つのセグメントに分割されたベアラ層ネットワークの概略図である。 本発明の一実施形態による、マルチキャストベアラリソースを制御するための方法のフローチャートである。 本発明の一実施形態による、マルチキャストベアラリソースを制御するための装置の、ＲＡＣＳ内のネットワークエンティティの概略構成図である。 本発明の第１の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第２の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第３の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第４の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第５の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第６の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第７の実施形態による、マルチキャストベアラリソースを制御するための方法のフローチャートである。

リソース受付制御サブシステム（ＲＡＣＳ）を適用することによってマルチキャストベアラリソースを制御するために、本発明は、マルチキャストトラフィックフローのリソース制御をＲＡＣＳがサポートすることを可能にし、かくして、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスの円滑な進行を保証するように、ＲＡＣＳを使用してマルチキャストベアラリソースを制御する、解決法を提案する。

上記の目的に基づいて、本発明は、マルチキャストベアラリソースを制御するための方法を提供する。図３を参照すると、この方法は以下のステップを含む。

ステップＳ１で、ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信する。

ＲＡＣＳによるマルチキャストベアラリソースの制御を達成するために、マルチキャストグループ参加要求メッセージ、リソース変更要求メッセージ、またはリソース解放要求メッセージをユーザから受信した後で、アクセスノード（ａｃｃｅｓｓ ｎｏｄｅ）（ＡＮ）またはＩＰエッジであってもよい、ベアラ層エンティティは、ＲＡＣＳに、マルチキャストベアラリソースを制御する要求を能動的に発し、かくして、マルチキャストベアラリソースの制御をＲＡＣＳに引き渡す必要がある。

ステップＳ２で、ＲＡＣＳ内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースを制御する。

ＲＡＣＳ内のネットワークエンティティが、ベアラ層ネットワークエンティティによって発された要求に従って、マルチキャストベアラリソースを制御し、制御応答を返すプロセスは、ユーザによって発されたさまざまな制御要求に応じて、以下の場合を含む。

場合１：ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信し、そして、ＲＡＣＳ内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、そして、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、アクセスリソース受付制御機能（Ａ−ＲＡＣＦ）である場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、Ａ−ＲＡＣＦは、要求に従って、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、そして、アクセス側の申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、Ａ−ＲＡＣＦは、要求に従って、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、サービスベースのポリシー決定機能（ＳＰＤＦ）またはコア−ＲＡＣＦ（Ｃ−ＲＡＣＦ）に、コアネットワークのマルチキャストベアラリソースを申し込み、そして、アクセス側およびコアネットワークの申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、ＳＰＤＦである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを申し込み、そして、アクセス側の申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦおよびＣ−ＲＡＣＦに、アクセス側およびコアネットワークのマルチキャストベアラリソースをそれぞれ申し込み、そして、アクセス側およびコアネットワークの申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。

場合２：ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信し、そして、ＲＡＣＳ内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、そして、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、Ａ−ＲＡＣＦである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、Ａ−ＲＡＣＦは、要求に従って、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、そして、アクセス側の変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、Ａ−ＲＡＣＦは、マルチキャストベアラリソースを変更する要求に従って、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、ＳＰＤＦまたはＣ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを変更することを要求し、そして、アクセス側およびコアネットワークの変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、ＳＰＤＦである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを変更することを要求し、そして、アクセス側の変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦおよびＣ−ＲＡＣＦに、アクセス側およびコアネットワークのマルチキャストベアラリソースを変更することをそれぞれ要求し、そして、アクセス側およびコアネットワークの変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。

場合３：ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信し、そして、ＲＡＣＳ内のネットワークエンティティは、対応するマルチキャストベアラリソースを解放し、そして、ベアラ層ネットワークエンティティに、解放結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、Ａ−ＲＡＣＦである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、Ａ−ＲＡＣＦは、アクセス側のマルチキャストベアラリソースを解放し、そして、アクセス側の解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、Ａ−ＲＡＣＦは、アクセス側のマルチキャストベアラリソースを解放し、ＳＰＤＦまたはＣ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを解放することを要求し、そして、アクセス側およびコアネットワークの解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。

特に、ベアラ層ネットワークエンティティと相互作用する、ＲＡＣＳ内のネットワークエンティティが、ＳＰＤＦである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを解放することを要求し、そして、アクセス側の解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、ＳＰＤＦは、Ａ−ＲＡＣＦおよびＣ−ＲＡＣＦに、アクセス側およびコアネットワークのマルチキャストベアラリソースを解放することをそれぞれ要求し、そして、アクセス側およびコアネットワークの解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。

本発明は、ＲＡＣＳ内に配置された、Ａ−ＲＡＣＦまたはＳＰＤＦであってもよい、ネットワークエンティティをさらに提供する。図４を参照すると、ネットワークエンティティは、受信ユニットと、制御ユニットとを含み、そして、応答ユニットをさらに含んでもよい。

受信ユニットは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように適合される。

制御ユニットは、受信ユニットによって受信された要求に従って、マルチキャストベアラリソースを制御するように適合される。

応答ユニットは、マルチキャストベアラリソースを制御する要求を発するベアラ層ネットワークエンティティに、制御応答を返すように適合される。

本発明は、マルチキャストベアラネットワークをさらに提供する。マルチキャストベアラネットワークは、ベアラ層ネットワークエンティティとＲＡＣＳ内のネットワークエンティティとを含む。

ベアラ層ネットワークエンティティは、マルチキャストベアラリソースを制御する要求を発するように適合される。

ＲＡＣＳ内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように、そして、マルチキャストベアラリソースを制御する要求に従って、マルチキャストベアラリソースを制御するように、そして、ベアラ層ネットワークエンティティに制御応答を返すように、適合される。特に、ＲＡＣＳ内のネットワークエンティティは、マルチキャストベアラリソースを制御する要求に従って、アクセス側のマルチキャストベアラリソースを制御するか、または、マルチキャストベアラリソースを制御する要求に従って、アクセス側およびコアネットワークのマルチキャストベアラリソースを制御する。

以下の６つの実施形態を参照して、本発明についてさらに詳細に説明する。

第１の実施形態では、Ａ−ＲＡＣＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮは、ユーザから、マルチキャストグループ参加要求を受信した後で、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを申し込み、Ａ−ＲＡＣＦは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行する。場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよい。Ａ−ＲＡＣＦは、アクセス側の状況に応じて、または、ネットワーク全体の申し込み結果に従って、ベアラ層に、最終的な応答を返す。図５を参照すると、この実施形態は、以下のステップを含む。

１．ＩＰエッジまたはＡＮは、ユーザからマルチキャストグループ参加要求を受信し、そして、ユーザが参加しようと意図しているマルチキャストグループのアドレスと、ユーザのＩＰアドレスとを、マルチキャストグループ参加要求から取得し、そして、１つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード（例えば、ＥＸＣＬＵＤＥまたはＩＮＣＬＵＤＥ）などのその他の情報をさらに取得してもよい。

２．ＩＰエッジまたはＡＮは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ユーザのＩＰアドレスまたはＩＤと、マルチキャストストリームの記述情報とを運ぶ。マルチキャストストリームの記述情報は、マルチキャストグループのＤクラスアドレスを含まなければならず、そして、場合によっては、１つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード（例えば、ＥＸＣＬＵＤＥまたはＩＮＣＬＵＤＥ）を含む。ＩＰエッジまたはＡＮに、マルチキャストグループによって要求される帯域幅リソースに関する情報が設定されている場合、その情報も、マルチキャストベアラリソースを申し込む要求の中で運ばれなければならない。

３．このステップのリソース許可に関する内容は、以下の２つの部分を含む。

最初に、場合によっては、Ａ−ＲＡＣＦは、ユーザのマルチキャストサービス権限に応じて、マルチキャストベアラリソースを申し込む要求に従って、サービス許可を実行してもよい。

その後、Ａ−ＲＡＣＦは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための受付許可およびリソース予約を実行する。特に、マルチキャストベアラリソースを申し込む要求が帯域幅情報を含まない場合、Ａ−ＲＡＣＦは、マルチキャストグループによって要求される帯域幅を取得するために、ローカル構成に問い合わせる。マルチキャストストリームがＩＰエッジまたはＡＮにおいてすでに存在していることをＡ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークのリソースを許可および予約する必要があり、マルチキャストストリームがＩＰエッジまたはＡＮにおいて存在していないことをＡ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークおよび収束ネットワークのリソースを許可および予約する必要がある。

さらに、場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよく、すなわち、プロセスはステップ４〜６に進む。

４．Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを申し込む要求を発する。コアネットワークのマルチキャストベアラリソースを申し込む要求は、ステップ２におけるのと同じ情報を運ぶ。

５．ＳＰＤＦ／Ｃ−ＲＡＣＦは、コアネットワークのリソースを許可する。

６．ＳＰＤＦ／Ｃ−ＲＡＣＦは、リソース許可が認められたかどうかを示すために、許可結果を返す。

７．Ａ−ＲＡＣＦは、アクセス側の申し込み結果に従って、または、アクセス側およびコア側の申し込み結果に従って、ＩＰエッジまたはＡＮに、リソース許可結果応答を返す。

第２の実施形態では、Ａ−ＲＡＣＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮが、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信した後で、ＩＰエッジまたはＡＮは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを変更する要求を発し、そして、Ａ−ＲＡＣＦは、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行する。場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを変更することを、さらに要求する。最後に、Ａ−ＲＡＣＦは、ＩＰエッジまたはＡＮに、リソース変更結果応答を返す。図６を参照すると、この実施形態は、以下のステップを含む。

１．ＩＰエッジまたはＡＮは、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信し、マルチキャストソースアドレスを変更する要求から、ユーザのＩＰアドレスを取得し、そして、ユーザが変更を要求するマルチキャストソースアドレス、またはその他のＱｏＳ情報を取得してもよい。

２．ＩＰエッジまたはＡＮは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを変更する要求を発する。マルチキャストベアラリソースを変更する要求は、ユーザのＩＰアドレスまたはＩＤを運ぶ必要があり、そして、場合によっては、変更されるマルチキャストソースアドレス、またはその他のＱｏＳ情報を運ぶ。

３．Ａ−ＲＡＣＦは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース予約を実行する。場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを変更することをさらに要求してもよく、すなわち、プロセスはステップ４〜６に進む。

４．Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、マルチキャストリソースを変更する要求を発する。マルチキャストリソースを変更する要求は、ステップ２におけるのと同じ情報を運ぶ。

５．ＳＰＤＦ／Ｃ−ＲＡＣＦは、コアネットワークのリソース状況に応じて、コアネットワークのマルチキャストリソースの変更を許可する。

６．ＳＰＤＦ／Ｃ−ＲＡＣＦは、マルチキャストリソース変更許可応答を返す。

７．Ａ−ＲＡＣＦは、アクセス側のマルチキャストリソース変更結果に従って、または、アクセス側およびコア側のマルチキャストリソース変更結果に従って、ＩＰエッジまたはＡＮに、最終的な許可応答を返す。

第３の実施形態では、Ａ−ＲＡＣＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮが、マルチキャストグループ離脱要求をユーザから受信した後、または、マルチキャストグループをユーザが異常に離脱したことを検出した後で、ＩＰエッジまたはＡＮは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを解放する要求を発する。Ａ−ＲＡＣＦは、アクセスネットワークのマルチキャストベアラリソースを、または、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストベアラリソースを、解放する。場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのリソースを解放することを、さらに要求してもよい。最後に、Ａ−ＲＡＣＦは、ＩＰエッジまたはＡＮに、リソース解放応答を返す。図７を参照すると、この実施形態は、以下のステップを含む。

１．マルチキャストグループを離脱する要求をユーザから受信した後、または、ユーザがマルチキャストグループを異常に離脱したことを検出した後で、ＩＰエッジまたはＡＮは、ユーザが離脱しようと意図しているマルチキャストグループのアドレスと、ユーザのＩＰアドレスとを、マルチキャストグループを離脱する要求から取得する。

２．ＩＰエッジまたはＡＮは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを解放する要求を発する。ＩＰエッジまたはＡＮと、Ａ−ＲＡＣＦとの間のインタフェースが、ダイアメータプロトコル（ｄｉａｍｅｔｅｒ ｐｒｏｔｏｃｏｌ）を採用している場合、マルチキャストベアラリソースを解放する要求は、セッションＩＤを運ぶ必要があり、ＩＰエッジまたはＡＮと、Ａ−ＲＡＣＦとの間のインタフェースが、ダイアメータプロトコルを採用していない場合、マルチキャストベアラリソースを解放する要求は、ユーザのＩＰアドレスまたはＩＤと、マルチキャストグループの記述情報とを運ぶ必要がある。

３．Ａ−ＲＡＣＦは、アクセスネットワークのマルチキャストベアラリソースを解放する。Ａ−ＲＡＣＦが、ＩＰエッジまたはＡＮにおける少なくとも１つの他のユーザがマルチキャストグループに属することを判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークのリソースを解放する必要があるのみである。ユーザが、マルチキャストグループを離脱する、ＩＰエッジまたはＡＮにおける最後の１つである場合、Ａ−ＲＡＣＦは、アクセスネットワークと収束ネットワークとの両方のリソースを解放する必要がある。場合によっては、Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを解放することをさらに要求してもよく、すなわち、プロセスはステップ４〜６に進む。

４．Ａ−ＲＡＣＦは、ＳＰＤＦ／Ｃ−ＲＡＣＦに、マルチキャストベアラリソースを解放する要求を発する。マルチキャストベアラリソースを解放する要求は、セッションＩＤを運ぶ。

５．ＳＰＤＦ／Ｃ−ＲＡＣＦは、コアネットワークのマルチキャストリソースを解放する。

６．ＳＰＤＦ／Ｃ−ＲＡＣＦは、マルチキャストリソース解放応答を返す。

７．Ａ−ＲＡＣＦは、アクセス側のマルチキャストリソース解放結果に従って、または、アクセス側およびコア側のマルチキャストリソース解放結果に従って、ＩＰエッジまたはＡＮに、最終的な応答を返す。

第４の実施形態では、ＳＰＤＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮと、ＳＰＤＦとの間で、マルチキャストリソース申し込み要求／応答が転送される必要がある。（従来技術において、ユニキャストリソース許可要求／応答を転送するように適合された）Ｇｑ’インタフェースが、ＩＰエッジまたはＡＮと、ＳＰＤＦとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース申し込み要求／応答の転送をサポートするように拡張されてもよい。

ユーザから、マルチキャストグループ参加要求を受信した後で、ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストベアラリソースを申し込む要求を発する。ＳＰＤＦは、マルチキャストベアラリソースを申し込む要求を許可し、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを申し込む。Ａ−ＲＡＣＦは、アクセス側について指摘する、ポリシーと、リソースの状況とに応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、同時に、ＳＰＤＦに、申し込み結果を返す。場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよい。ＳＰＤＦは、アクセス側またはネットワーク全体のリソース許可状況に応じて、ＩＰエッジまたはＡＮに、最終的な応答を返す。図８を参照すると、この実施形態は、以下のステップを含む。

１．ＩＰエッジまたはＡＮは、ユーザからマルチキャストグループ参加要求を受信し、そして、ユーザが参加しようと意図しているマルチキャストグループのアドレスと、ユーザのＩＰアドレスとを、メッセージから取得し、そして、１つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード（例えば、ＥＸＣＬＵＤＥまたはＩＮＣＬＵＤＥ）などのその他の情報をさらに取得してもよい。

２．ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ユーザのＩＰアドレスまたはＩＤと、マルチキャストストリームの記述情報とを運ぶ。マルチキャストストリームの記述情報は、マルチキャストグループのＤクラスアドレスを含まなければならず、そして、場合によっては、１つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード（例えば、ＥＸＣＬＵＤＥまたはＩＮＣＬＵＤＥ）を含む。ＩＰエッジまたはＡＮに、この時マルチキャストグループによって要求される帯域幅リソースに関する情報が設定されている場合、その情報は、マルチキャストベアラリソースを申し込む要求の中で運ばれなければならない。

３．ＳＰＤＦは、マルチキャストベアラリソースを申し込む要求に従って、サービス許可を実行する。その一方で、場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを許可することを要求してもよく、すなわち、プロセスはステップ７〜９に進む。

４．ＳＰＤＦは、Ａ−ＲＡＣＦに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ステップ２におけるのと同じ情報を運ぶ。

５．マルチキャストベアラリソースを申し込む要求を受信した後で、Ａ−ＲＡＣＦは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための受付許可およびリソース予約を実行する。特に、Ａ−ＲＡＣＦは、対応するマルチキャストストリームが、対応するＩＰエッジまたはＡＮにおいてすでに存在しているかどうかを判定する。対応するマルチキャストストリームが、対応するＩＰエッジまたはＡＮにおいてすでに存在していることをＡ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークのネットワークリソース状況に応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、対応するマルチキャストストリームが、対応するＩＰエッジまたはＡＮにおいてまだ存在していないことをＡ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークおよびアクセス収束ネットワークのネットワークリソース状況に応じて、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストベアラリソースのための、受付許可およびリソース予約を実行する。

６．Ａ−ＲＡＣＦは、マルチキャストリソース許可が認められたかどうかを示すために、許可結果を返す。

７．場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを申し込む。

８．Ｃ−ＲＡＣＦは、コアネットワークのリソース状況に応じて、マルチキャストベアラリソースを申し込む要求を許可する。

９．Ｃ−ＲＡＣＦは、ＳＰＤＦに、許可応答を返す。

１０．ＳＰＤＦは、アクセス側のマルチキャストリソース許可結果に従って、または、アクセス側およびコア側のマルチキャストリソース許可結果に従って、ベアラ層に応答を返す。

第５の実施形態では、ＳＰＤＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮと、ＳＰＤＦとの間で、マルチキャストリソース変更要求／応答が転送される必要がある。（従来技術において、ユニキャストリソース許可変更要求／応答を転送するように適合された）Ｇｑ’インタフェースが、ＩＰエッジまたはＡＮと、ＳＰＤＦとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース変更要求／応答の転送をサポートするように拡張されてもよい。

ＩＰエッジまたはＡＮが、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信した後で、ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストベアラリソースを変更する要求を発する。ＳＰＤＦは、マルチキャストベアラリソースを変更する要求を許可し、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを変更することを要求する。場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを変更することをさらに要求してもよい。最後に、ＳＰＤＦは、ＩＰエッジまたはＡＮに、リソース変更結果応答を返す。図９を参照すると、この実施形態は、以下のステップを含む。

１．ＩＰエッジまたはＡＮは、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信し、マルチキャストソースアドレスを変更する要求から、ユーザのＩＰアドレスを取得し、そして、変更されるマルチキャストソースアドレス、またはその他のＱｏＳ情報を取得してもよい。

２．ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストベアラリソースを変更する要求を発する。マルチキャストベアラリソースを変更する要求は、ユーザのＩＰアドレスを運び、そして、場合によっては、変更されるマルチキャストソースアドレス、またはその他のＱｏＳ情報を運ぶ。

３．ＳＰＤＦは、Ａ−ＲＡＣＦに、マルチキャストリソースを変更する要求を発する。マルチキャストリソースを変更する要求は、ステップ２におけるのと同じ情報を運ぶ。

４．ＳＰＤＦによって送信された、リソースを変更する要求を受信した後で、Ａ−ＲＡＣＦは、マルチキャストリソースを変更する要求に従って、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースを変更するための受付許可およびリソース予約を実行する。

５．Ａ−ＲＡＣＦは、マルチキャストリソース変更許可結果を返す。

６．場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを変更することを要求する。

７．Ｃ−ＲＡＣＦは、コアネットワークのリソース状況に応じて、コアネットワークのマルチキャストベアラリソースの変更を許可する。

８．Ｃ−ＲＡＣＦは、マルチキャストベアラリソース変更応答を返す。

９．ＳＰＤＦは、アクセス側のマルチキャストリソース変更許可結果に従って、または、アクセス側およびコア側のマルチキャストリソース変更許可結果に従って、ＩＰエッジまたはＡＮに、最終的な応答を返す。

第６の実施形態では、ＳＰＤＦが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティＩＰエッジまたはＡＮと、ＳＰＤＦとの間で、マルチキャストリソース解放要求／応答が転送される必要がある。（従来技術において、ユニキャストリソース許可要求／応答を転送するように適合された）Ｇｑ’インタフェースが、ＩＰエッジまたはＡＮと、ＳＰＤＦとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース解放要求／応答の転送をサポートするように拡張されてもよい。

ＩＰエッジまたはＡＮが、ユーザから、マルチキャストグループ離脱要求を受信した後で、ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストリソースを解放する要求を発する。ＳＰＤＦは、Ａ−ＲＡＣＦに、アクセス側のマルチキャストベアラリソースを解放することを要求する。Ａ−ＲＡＣＦは、応答を返す。この時、場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを解放することをさらに要求してもよい。最後に、ＳＰＤＦは、ＩＰエッジまたはＡＮに、リソース解放応答を返す。図１０を参照すると、この実施形態は、以下のステップを含む。

１．ユーザから、マルチキャストグループを離脱する要求を受信した後で、ＩＰエッジまたはＡＮは、ユーザが離脱しようと意図しているマルチキャストグループのアドレスと、ユーザのＩＰアドレスとを、メッセージから取得する。

２．ＩＰエッジまたはＡＮは、ＳＰＤＦに、マルチキャストベアラリソースを解放する要求を発する。ＩＰエッジまたはＡＮと、ＳＰＤＦとの間のインタフェースが、ダイアメータプロトコルを採用している場合、マルチキャストベアラリソースを解放する要求は、セッションＩＤを運ぶ必要があるのみであり、ＩＰエッジまたはＡＮと、ＳＰＤＦとの間のインタフェースが、ダイアメータプロトコルを採用していない場合、マルチキャストベアラリソースを解放する要求は、ユーザのＩＰアドレスまたはＩＤと、マルチキャストグループの記述情報とを運ぶ必要がある。

３．ＳＰＤＦは、アクセス側のマルチキャストリソースを解放するようＡ−ＲＡＣＦに要求するために、Ａ−ＲＡＣＦに、マルチキャストリソース解放要求を発する。要求は、セッションＩＤを運ぶ。

４．ＳＰＤＦによって送信されたリソース解放要求を受信した後で、Ａ−ＲＡＣＦは、対応するマルチキャストリソースを解放する。特に、Ａ−ＲＡＣＦは、対応するＩＰエッジまたはＡＮにおいてマルチキャストストリームを使用しているユーザがいないかどうかを判定する。対応するＩＰエッジまたはＡＮにおいて、マルチキャストストリームを使用しているユーザがいないということを、Ａ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークおよびアクセス収束ネットワークの、対応するマルチキャストストリームによって占有されているネットワークリソースを解放し、対応するＩＰエッジまたはＡＮにおいて、マルチキャストストリームを使用しているユーザがいるということを、Ａ−ＲＡＣＦが判定した場合、Ａ−ＲＡＣＦは、アクセスネットワークの、対応するマルチキャストストリームによって占有されているネットワークリソースを解放するのみである。

５．Ａ−ＲＡＣＦは、マルチキャストリソース解放結果を返す。

６．場合によっては、ＳＰＤＦは、Ｃ−ＲＡＣＦに、コアネットワークのマルチキャストベアラリソースを解放することを要求する。

７．Ｃ−ＲＡＣＦは、コアネットワークのマルチキャストベアラリソースを解放する。

８．Ｃ−ＲＡＣＦは、リソース解放応答を返す。

９．ＳＰＤＦは、アクセス側のマルチキャストリソース解放結果に従って、または、アクセス側およびコア側のマルチキャストリソース解放結果に従って、ＩＰエッジまたはＡＮに、最終的な応答を返す。

第７の実施形態では、上記の実施形態からわかるように、マルチキャスト技術とユニキャスト技術との間の違いにより、ＳＰＤＦおよび／またはＡ−ＲＡＣＦは、マルチキャストベアラリソースの制御をＲＡＣＳが実装することを可能にするために、マルチキャスト技術の特性に従ってマルチキャストリソース関連の要求（申し込み、解放、または変更）を処理する機能をさらに備える必要がある。ここでは、Ａ−ＲＡＣＦによってマルチキャストリソース関連の要求を処理するためのアルゴリズムを、以下に例示する。

（Ｓ，Ｇ）は、マルチキャストストリームを表し、ここで、Ｓは、マルチキャストソースアドレスであり、Ｇは、マルチキャストグループアドレスであり、そして、Ｎは、ＩＰエッジまたはＡＮにおいて（Ｓ，Ｇ）によってサービスを提供される、アクセスユーザの数である。

マルチキャストリソース要求を処理するためのプロセスを決定するために、Ａ−ＲＡＣＦは、リソースを要求しているマルチキャストストリーム（Ｓ，Ｇ）と、マルチキャストストリームを受信しているユーザの数（Ｎ）との間の対応する関係を記憶し、そして、Ｎをリアルタイムで更新する必要がある。Ａ−ＲＡＣＦによってマルチキャストリソース関連の要求を処理するためのアルゴリズムを、図１１に示す。Ａ−ＲＡＣＦが、ＳＰＤＦから、マルチキャストリソース要求を受信した場合、Ａ−ＲＡＣＦは、要求のタイプを判定する。

ａ）マルチキャストリソースを申し込む要求。Ａ−ＲＡＣＦは、マルチキャストストリーム（Ｓ，Ｇ）がすでに存在しているかどうかを判定する。Ａ−ＲＡＣＦが、マルチキャストストリーム（Ｓ，Ｇ）は存在していないと判定した場合、Ａ−ＲＡＣＦは、この（Ｓ，Ｇ）のための対応するＮ（Ｎ＝１）を作成し、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストリソースを同時に許可する。対応するＮがすでに存在している場合は、Ｎ＝Ｎ＋１とし、アクセスネットワークのマルチキャストリソースが許可される。

ｂ）マルチキャストリソースを解放する要求。Ａ−ＲＡＣＦは、（Ｓ，Ｇ）に対応するＮが、（Ｎ＝Ｎ−１）の後で、０に等しいかどうかを判定する。（Ｓ，Ｇ）に対応するＮが、（Ｎ＝Ｎ−１）の後で、０に等しいとＡ−ＲＡＣＦが判定した場合は、（Ｓ，Ｇ）とＮとの間の対応する関係は削除され、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストリソースが、解放されることが許可される。それ以外の場合は、アクセスネットワークのマルチキャストリソースが、解放されることが許可される。

ｃ）マルチキャストリソースを変更する要求。最初に、ａ）で説明したアルゴリズムに従って、新しいマルチキャストリソースが申し込まれ、そして、ｂ）で説明したアルゴリズムに従って、元のマルチキャストリソースが解放される。

要約すると、マルチキャストリソース管理およびマルチキャストリソース受付制御機能は、一般に、現在のライブテレビジョン／放送テレビジョン（ＬＴＶ／ＢＴＶ）システムのアーキテクチャ内のベアラ層エンティティにおいて直接実現される。一方では、この方法は、マルチキャストリソースの管理と受付制御とがベアラ層エンティティにおいて実現されることを要求するため、ベアラ層装置の複雑さが増加し、また、イーサネット（登録商標）スイッチおよびルータなどの多くの既存のベアラ層装置は、マルチキャストリソースの管理機能および受付制御機能をサポートしないため、実際のネットワーキング適用例内にこの方法を実装することは困難である。他方では、この方法では、マルチキャストベアラリソースはベアラ層エンティティにおいて管理されるが、これに対して、現在の次世代ネットワーク（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｎｅｔｗｏｒｋ）（ＮＧＮ）アーキテクチャでは、ユニキャストベアラリソースはＲＡＣＳ内で管理される。結果として、ユニキャストおよびマルチキャストベアラリソースの管理はＮＧＮネットワーク内で分離され、ユニキャストサービスとマルチキャストサービスとがネットワークベアラリソースを完全に共用することはできないということがもたらされるか、または、ユニキャストサービスとマルチキャストサービスとの間でのネットワークリソースの共用を達成するために、複雑なネットワークベアラリソース同期機構を導入する必要がある。本発明によって提供される、ＮＧＮネットワーク内のＲＡＣＳを使用することによってマルチキャストベアラリソースを制御するための方法は、好ましい解決法である。

現在のところ、ＲＡＣＳアーキテクチャは、ユニキャストベアラリソースの管理をサポートするのみであり、しかし、マルチキャストベアラリソースの制御をサポートすることはできない。

したがって、本発明では、ユーザから、マルチキャストベアラリソースを制御する要求を受信した後で、ベアラ層エンティティは、その要求をＲＡＣＳに転送し、そして、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信した後で、ＲＡＣＳ内のネットワークエンティティは、マルチキャストベアラリソースを制御する要求に従って、マルチキャストベアラリソースを制御し、ベアラ層ネットワークエンティティに、制御応答を返す。したがって、ＲＡＣＳは、マルチキャストトラフィックフローのリソース制御をサポートすることが可能である。このように、マルチキャストリソースのための管理および受付制御機能は、ベアラ層エンティティ内に導入される必要はない。その一方で、ユニキャストおよびマルチキャストリソースの集中型の統合された管理が達成されることが可能であり、したがって、ユニキャストサービスとマルチキャストサービスとがベアラリソースを完全に共用することが保証される。それゆえ、ＩＰＴＶマルチキャストサービスのＱｏＳは向上し、かくして、ＩＰＴＶサービスの円滑な進行が保証される。

本発明の実施形態による方法のステップのすべてまたは一部は、関連するハードウェアに指示するプログラムによって実装されてもよいということを、当業者は理解すべきである。プログラムは、コンピュータ読み取り可能な記憶媒体内に記憶されてもよい。プログラムが実行される場合、本発明の実施形態による方法のステップが実行される。記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、および光ディスクなどの、プログラムコードを記憶することが可能な任意の媒体であってもよい。

最後に、上記の実施形態は、本発明の技術的解決法を説明するためにのみ使用され、限定するためには使用されないということが理解されるべきである。上記の好ましい実施形態を参照した、本発明の詳細な説明にもかかわらず、さまざまな修正、変更、または等価な置換が、本発明の範囲を逸脱することなく当業者によって行われることが可能であり、本発明の特許請求の範囲に含まれることが可能であるということが理解されるべきである。

Claims (15)

1. マルチキャストベアラリソースを制御するための方法であって、
   サービスベースのポリシー決定機能（ＳＰＤＦ）によって、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信し、
   前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御する、
   ことを含み、
   前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、アクセスリソース受付制御機能（Ａ−ＲＡＣＦ）にアクセス側のマルチキャストベアラリソースを申し込み、
   前記ＳＰＤＦによって、コアリソース受付制御機能（Ｃ−ＲＡＣＦ）にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
   方法。
2. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、アクセス側及びコアネットワークの申し込み結果に従って前記ベアラ層ネットワークエンティティにリソース申し込み結果応答を返すことを含む、
   請求項１の方法。
3. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、マルチキャストベアラリソースを申し込む前に、マルチキャストサービス許可に従ってマルチキャストベアラリソースを申し込む要求に従ったサービス許可を行う、
   請求項１又は２の方法。
4. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、前記ベアラ層ネットワークエンティティから、前記マルチキャストベアラリソースを変更する要求を受信し、
   前記ＳＰＤＦによって、前記マルチキャストベアラリソースを変更するための受付許可およびリソース変更を実行し、
   前記ＳＰＤＦによって、前記ベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
   請求項１に記載の方法。
5. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、アクセス側及びコアネットワークの変更結果に従って前記ベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
   請求項４に記載の方法。
6. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、アクセス側のマルチキャストベアラリソースを変更することをＡ−ＲＡＣＦに要求し、
   前記ＳＰＤＦによって、コアネットワークのマルチキャストベアラリソースを変更することをＣ−ＲＡＣＦに要求し、
   前記ＳＰＤＦによって、アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
   請求項１、４又は５の方法。
7. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、前記ベアラ層ネットワークエンティティから、前記マルチキャストベアラリソースを解放する要求を受信し、
   前記ＳＰＤＦによって、対応するマルチキャストベアラリソースを解放し、
   前記ＳＰＤＦによって、前記ベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
   請求項１に記載の方法。
8. 前記ＳＰＤＦによって、前記マルチキャストベアラリソースを制御することは、
   前記ＳＰＤＦによって、アクセス側のマルチキャストベアラリソースを解放することをＡ−ＲＡＣＦに要求し、
   前記ＳＰＤＦによって、コアネットワークのマルチキャストベアラリソースを解放することをＣ−ＲＡＣＦに要求し、
   前記ＳＰＤＦによって、アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
   請求項７の方法。
9. リソース受付制御サブシステム（ＲＡＣＳ）内に配置されたネットワークエンティティであって、
   ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように適合された受信ユニットと、
   前記マルチキャストベアラリソースを制御するように適合された制御ユニットと、
   を具備し、
   前記ネットワークエンティティは、サービスベースのポリシー決定機能（ＳＰＤＦ）であり、
   前記マルチキャストベアラリソースを制御することは、
   アクセスリソース受付制御機能（Ａ−ＲＡＣＦ）にアクセス側のマルチキャストベアラリソースを申し込み、
   コアリソース受付制御機能（Ｃ−ＲＡＣＦ）にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
   ネットワークエンティティ。
10. 前記マルチキャストベアラリソースを制御する前記要求を発する前記ベアラ層ネットワークエンティティに、制御応答を返すように適合された応答ユニットをさらに具備する、請求項９に記載のエンティティ。
11. 前記マルチキャストベアラリソースを制御することは、
    アクセス側のマルチキャストベアラリソースを変更することをＡ−ＲＡＣＦに要求し、
    コアネットワークのマルチキャストベアラリソースを変更することをＣ−ＲＡＣＦに要求し、
    アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項９又は１０のエンティティ。
12. 前記マルチキャストベアラリソースを制御することは、
    アクセス側のマルチキャストベアラリソースを解放することをＡ−ＲＡＣＦに要求し、
    コアネットワークのマルチキャストベアラリソースを解放することをＣ−ＲＡＣＦに要求し、
    アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項９、１０又は１１のエンティティ。
13. マルチキャストベアラリソースを制御するためのシステムであって、
    マルチキャストベアラリソースを制御する要求を発するように適合されたベアラ層ネットワークエンティティと、
    前記ベアラ層ネットワークエンティティから前記マルチキャストベアラリソースを制御する要求を受信し、前記マルチキャストベアラリソースを制御するように適合されたサービスベースのポリシー決定機能（ＳＰＤＦ）と、
    を具備し、
    前記マルチキャストベアラリソースを制御することは、
    前記ＳＰＤＦによって、アクセスリソース受付制御機能（Ａ−ＲＡＣＦ）にアクセス側のマルチキャストベアラリソースを申し込み、
    前記ＳＰＤＦによって、コアリソース受付制御機能（Ｃ−ＲＡＣＦ）にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
    システム。
14. 前記マルチキャストベアラリソースを制御することは、
    前記ＳＰＤＦによって、アクセス側のマルチキャストベアラリソースを変更することをＡ−ＲＡＣＦに要求し、
    前記ＳＰＤＦによって、コアネットワークのマルチキャストベアラリソースを変更することをＣ−ＲＡＣＦに要求し、
    前記ＳＰＤＦによって、アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項１３のシステム。
15. 前記マルチキャストベアラリソースを制御することは、
    前記ＳＰＤＦによって、アクセス側のマルチキャストベアラリソースを解放することをＡ−ＲＡＣＦに要求し、
    前記ＳＰＤＦによって、コアネットワークのマルチキャストベアラリソースを解放することをＣ−ＲＡＣＦに要求し、
    前記ＳＰＤＦによって、アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項１３又は１４のシステム。

Images