(57)【要約】  マルチキャスト認可制御ノードがユーザのマルチキャストサービス権限情報を動的に更新し、動的に更新されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する、マルチキャストサービス認可制御支援方法、装置、及びシステム。本方法は、マルチキャスト認可制御ノードによって負荷制御レイヤとの相互作用の期間中にユーザのマルチキャストサービス権限情報を取得し、マルチキャスト認可制御ノードによって取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施することを含む。本発明におけるマルチキャスト認可制御ノードは、負荷制御レイヤとの相互作用の期間中に、ユーザのマルチキャストサービス権限情報を取得する取得ユニットと、取得ユニットによって取得されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する認可制御ユニットとを含む。
2010529725.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャスト認可制御点によって、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得し、
前記マルチキャスト認可制御点によって、前記取得したマルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施すること
を含む、マルチキャストサービス認可制御方法。
【請求項２】
前記マルチキャスト認可制御点が、前記ユーザのマルチキャストサービス権限情報を取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ネットワーク接続サブシステム（ＮＡＳＳ）が前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に配信する、第１の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報をリソース受付制御サブシステム（ＲＡＣＳ）に要求して取得する、第２の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を、前記ＮＡＳＳに要求して取得する、第３の手法と
のうちの１つである、請求項１に記載の方法。
【請求項３】
前記第１の手法において、前記ＮＡＳＳが前記ユーザのマルチキャストサービス権限情報を配信する手法は、
前記ＮＡＳＳが、前記ユーザのマルチキャストサービス権限情報を、前記ＲＡＣＳ内のアクセスリソース受付制御機能（Ａ−ＲＡＣＦ）を介して前記マルチキャスト認可制御点に配信する、第１１の手法と、
前記ＮＡＳＳ内のユーザアクセス認可機能（ＵＡＡＦ）が、前記ユーザのマルチキャストサービス権限情報を、前記マルチキャスト認可制御点に直接配信する、第１２の手法と
のうちの１つである、請求項２に記載の方法。
【請求項４】
前記第２の手法において、前記マルチキャスト認可制御点が、前記ユーザのマルチキャストサービス権限情報を、前記ＲＡＣＳに要求して取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、前記ＮＡＳＳが前記ユーザのマルチキャストサービス権限情報をＡ−ＲＡＣＦに配信し、前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記Ａ−ＲＡＣＦに要求した場合に、前記Ａ−ＲＡＣＦが前記ユーザの現在のマルチキャストサービス権限情報を前記マルチキャスト認可制御点に返す、第２１の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記Ａ−ＲＡＣＦに要求した場合に、前記Ａ−ＲＡＣＦが前記ユーザのマルチキャストサービス権限情報を前記ＮＡＳＳから取得し、前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に返す、第２２の手法と
のうちの１つである、請求項２に記載の方法。
【請求項５】
前記マルチキャストサービス権限情報は、前記ユーザのインターネットプロトコル（ＩＰ）アドレス又は識別情報と、少なくとも１つのマルチキャストアドレス及び少なくとも１つのマルチキャスト権限グループ識別情報の少なくとも一方とを含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得するように構成された、取得ユニットと、
前記取得ユニットによって取得された前記マルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施するように構成された、認可制御ユニットと
を備える、マルチキャスト認可制御点。
【請求項７】
前記マルチキャスト認可制御点は、インターネットプロトコル（ＩＰ）エッジ又はアクセスノード（ＡＮ）である、請求項６に記載のマルチキャスト認可制御点。
【請求項８】
前記取得ユニットが前記ユーザのマルチキャストサービス権限情報を取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ネットワーク接続サブシステム（ＮＡＳＳ）が前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に配信する、第１の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報をリソース受付制御サブシステム（ＲＡＣＳ）に要求して取得する、第２の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記ＮＡＳＳに要求して取得する、第３の手法と
のうちの１つである、請求項６又は７に記載のマルチキャスト認可制御点。
【請求項９】
前記ユーザのマルチキャストサービス権限情報は、拡張インタフェースプロトコルを介して前記取得ユニットに転送される、請求項８に記載のマルチキャスト認可制御点。
【請求項１０】
マルチキャスト認可制御点と、ユーザ端末とを備える、マルチキャストサービス認可制御システムであって、前記マルチキャスト認可制御点は、
ベアラ制御レイヤとの相互作用のプロセスの中で、ユーザのマルチキャストサービス権限情報を取得するように構成された、取得ユニットと、
前記取得ユニットによって取得された前記マルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施するように構成された、認可制御ユニットと
を備える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信の分野に関し、特に、マルチキャストサービス認可制御方法、装置、及びシステムに関する。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ）テレビジョン（ＩＰＴＶ）サービスは、ブロードバンドＩＰネットワークに基づき、ストリーミングメディアに主に依拠するサービスである。従来のテレビ（ＴＶ）と比較して、ＩＰＴＶは、より豊富で柔軟なサービスと包括的なＩＰＴＶ付加価値サービスプラットフォームとを提供して、通信、データ、ビデオ、オーディオ、及びその他のサービスを実現することが可能である。ＩＰＴＶにおけるライブＴＶ／ブロードキャストＴＶ（ＬＴＶ／ＢＴＶ）サービスでは、ソースノードによって生成されたデータを複数の対象ノードに送信すること、すなわち、ポイントツーマルチポイント通信が必要である。現在、ポイントツーマルチポイント通信のための最も効果的な解決法は、ネットワーク帯域幅を効果的に利用して帯域幅リソースの浪費を防ぐことが可能な、マルチキャスト技術である。
【０００３】
マルチキャスト技術をサポートするために、ＴＩＳＰＡＮ（ｔｅｌｅｃｉｍｍｕｎｉｃａｔｉｏｎ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  ｓｅｒｖｉｃｅｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  ａｄｖａｎｃｅｄ  ｎｅｔｗｏｒｋｉｎｇ）において策定された次世代ネットワーク（ＮＧＮ）アーキテクチャでは、ＮＧＮは、サービスレイヤとトランスポートレイヤとに分割されている。トランスポートレイヤは、ネットワーク接続サブシステム（ＮＡＳＳ）と、独立したユーザアクセスマネージャ機能を上位サービスレイヤに提供することを担当する、リソース受付制御サブシステム（ＲＡＣＳ）とを含む。
【０００４】
リソース受付制御を実施することによって、ＲＡＣＳは、トランスポートネットワークの具体的な詳細を、上位のサービスレイヤに対して隠して、トランスポート機能からのサービス制御の分離をサポートし、そして、下位のトランスポートネットワークのリソース使用状況を検知して、トランスポートネットワークリソースの適正かつ妥当な使用を確実にする。従って、サービスのサービス品質（ＱｏＳ）が保証され、帯域幅及びサービスの盗用という現象が防止される。ＲＡＣＳの機能アーキテクチャ図を、図１に示し、この図の主要なネットワーク要素について以下で紹介する。
【０００５】
サービスベースのポリシー決定機能（ＳＰＤＦ）は、アプリケーションレイヤへの統一インタフェースを提供し、底層ネットワークのトポロジと具体的なアクセスタイプとを隠して、サービスベースのポリシー制御を提供する。ＳＰＤＦは、アプリケーション機能（ＡＦ）の要求に従ってローカルポリシーを選択し、要求をＩＰＱｏＳパラメータ内にマッピングし、ＩＰＱｏＳパラメータをアクセスリソース受付制御機能（Ａ−ＲＡＣＦ）及びボーダーゲートウェイ機能（ＢＧＦ）に送信して、対応するリソースを要求する。
【０００６】
Ａ−ＲＡＣＦは、アクセスネットワーク内に配置されており、受付制御及びネットワークポリシー収束の機能を有する。Ａ−ＲＡＣＦは、ＳＰＤＦからの要求を受信し、次に、保存されたポリシーに基づいて受付制御を実現して、トランスポートリソースを求める要求を受け入れるか、又は拒否する。Ａ−ＲＡＣＦは、ネットワーク接続情報及びユーザＱｏＳリスト情報を、ｅ４参照点を介してＮＡＳＳから取得する。従って、利用可能なネットワークリソースが、ネットワーク位置情報（例えば、アクセスユーザの物理ノードアドレス）に応じて判定可能であり、同時に、ユーザＱｏＳリスト情報が、リソース割り当て要求の処理において参照される。
【０００７】
トランスポートレイヤは、３種類の機能エンティティを含む。ＢＧＦは、ボーダーゲートウェイであり、（コアＢＧＦを実現するために）アクセスネットワークとコアネットワークとの間に配置されてもよく、又は、（相互接続ＢＧＦを実現するために）２つのコアネットワークの間に配置されてもよい。ＳＰＤＦの制御下で、ＢＧＦは、ネットワークアドレス変換（ＮＡＴ）、ゲーティング、ＱｏＳラベリング、帯域幅制限、使用量計測、及びリソース同期を含む機能を達成する。リソース制御実施機能（ＲＣＥＦ）は、Ａ−ＲＡＣＦからＲｅ参照点を介して移送された、アクセス事業者によって定義されたレイヤ２／レイヤ３（Ｌ２／Ｌ３）メディアストリームポリシーを実施して、ゲーティング、ＱｏＳラベリング、帯域幅制限、及びその他の機能を実施する。レイヤ２終端機能（Ｌ２ＴＦ）は、アクセスネットワーク内のレイヤ２接続を終端する機能エンティティである。ＲＣＥＦとＬ２ＴＦとは異なる機能エンティティであり、通常、物理装置のＩＰエッジ上でともに実現される。
【０００８】
ＮＡＳＳは、ユーザが接続されたアクセスネットワークの管理を達成する。ＮＡＳＳの機能アーキテクチャ図を、図２に示し、この図の主要なネットワーク要素について以下で紹介する。
【０００９】
ＮＡＳＳは、ネットワークアクセス構成機能（ＮＡＣＦ）と、ユーザアクセス認可機能（ＵＡＡＦ）と、接続性セッションロケーション及びリポジトリ機能（ＣＬＦ）と、アクセスマネージャ機能（ＡＭＦ）と、その他の論理機能ユニットとからなる。ＮＡＣＦは、ＩＰアドレスをユーザ装置（ＵＥ）に割り当てることと、ＵＥによって要求される、ドメインネームサーバ（ＤＮＳ）アドレス及び上位レイヤサービスアクセス点アドレスなどの、その他のネットワーク構成パラメータを提供することとを担当する。ＮＡＣＦは、更に、ＵＥが接続されたアクセスネットワークを一意に識別する、アクセスネットワーク識別子をＵＥに提供する。この識別子を使用して、上位レイヤアプリケーションは、ＣＬＦを見つけることができる。ＵＡＡＦは、ユーザ認証及び認可検査機能を提供する。ＵＡＡＦは、プロファイルデータベース機能（ＰＤＢＦ）内に含まれたユーザの加入情報から、ユーザ認証及びネットワーク認可情報を取得する。ＵＡＡＦは、更に、請求書発行のための課金データを収集する。ＣＬＦは、ＵＥに割り当てられたＩＰアドレスと、ＮＡＣＦによって提供された関連するネットワーク位置情報及び地理的位置情報とを登録し、情報を関連付ける。ＣＬＦは、更に、ユーザ識別情報と、ユーザのＱｏＳリストと、ユーザの位置情報のプライバシー設定とを記憶する。ＣＬＦは、上位レイヤサービスに、位置問い合わせ機能を提供する。ＡＭＦは、ＵＥのアクセス要求を変換することと、ＩＰアドレス及びネットワーク構成パラメータの割り当てを求めるＵＥの要求をＮＡＣＦに転送することと、ユーザ認証要求をＵＡＡＦに転送することとを担当する。逆方向においては、ＡＭＦは、ＮＡＣＦ又はＵＡＡＦからの応答をＵＥに転送する。アクセスリレー機能（ＡＲＦ）は、ＮＡＳＳの構成要素ではなく、カスタマネットワークゲートウェイ（ＣＮＧ）とＮＡＳＳとの間に配置され、中継器として、アクセスネットワークによって提供された位置情報をユーザの要求内に挿入することができる。通常のＵＥアクセスプロセスでは、ＵＥが最初に、ＡＲＦ／ＡＭＦを介してＵＡＡＦと相互作用（対話）して、認証及びネットワーク認可を達成し、次に、ＡＲＦ／ＡＭＦを介してＮＡＣＦと相互作用して、ＩＰアドレス及びアクセスのためのその他の構成パラメータを取得する。ＵＡＡＦとＮＡＣＦとは、ＣＬＦにおける関連付けと記憶とのために、ＣＬＦにユーザ関連情報をそれぞれ送信し、その後、ＲＡＣＳと上位レイヤサービスとは情報を問い合わせることができる。ＡＭＦの位置は、使用されるアクセス認証技術に関連し、ポイントツーポイントプロトコルオーバイーサネット（ＰＰＰｏＥ）認証が使用される場合、ＡＭＦはＩＰエッジに配置され、動的ホスト構成プロトコル（ＤＨＣＰ）認証手法が使用される場合、ＡＭＦはＩＰエッジに配置されるか、又はＮＡＣＦと同じエンティティ内に配置されてもよい。
【００１０】
ＩＰマルチキャスト技術は、ＩＰＴＶサービスの発展のために重要な意味を有する。マルチキャストサービスでは、サービスを制御可能とし、サービスの操作可能性と管理可能性とを保証するために、いくつかの必要なポリシーが採用されなければならない。マルチキャストユーザの制御は、多くの種類のマルチキャスト制御ポリシーのうちの１つであり、その重要な技術手段は、ユーザの認証及び認可である。現在運営中のネットワークでは、マルチキャストユーザの認可手法は主として、ベアラレイヤのマルチキャスト認可制御点にユーザのマルチキャストサービス権限情報を静的に設定し、情報に従って、マルチキャスト認可制御点によって、ユーザが番組を見ることを認可されるかどうかを判定し、それにより、ＩＰＴＶの正当なユーザのみにパケットを転送することである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明を実現する間に、ベアラレイヤのマルチキャスト認可制御点は、ノードに関連付けられた全てのユーザのマルチキャストサービス権限情報を記憶する必要があるが、ユーザがローミングするか又は関連付けられた制御ノードをその他の理由で置き換える場合、あるいはユーザが加入情報を変更する場合、マルチキャスト制御ノードによって記憶されたマルチキャストサービス権限情報は更新される必要があるということを、発明者は見出した。多数のマルチキャスト認可制御点がネットワーク内に存在するため、マルチキャスト認可制御点にユーザのマルチキャストサービス権限情報を静的に設定するという既存の方法では、複数のマルチキャスト認可制御点上に分散させられたユーザのマルチキャストサービス権限情報をネットワークが保守する必要が発生する。権限情報に対する修正、削除、追加、及びその他の操作は、情報が分散させられた複数の認可制御点上でそれぞれ実行される必要があり、従って、複雑な操作と、高い実装コストと、高い管理及び保守コストとがもたらされる。
【課題を解決するための手段】
【００１２】
本発明は、マルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を動的に更新し、動的に更新されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する、ということを支援する、マルチキャストサービス認可制御方法、装置、及びシステムに関する。
【００１３】
一実施形態では、本発明は、マルチキャスト認可制御点によって、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得し、マルチキャスト認可制御点によって、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施することを含む、マルチキャストサービス認可制御方法を提供する。
【００１４】
一実施形態では、本発明は、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得するよう構成された、取得ユニットと、取得ユニットによって取得されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施するよう構成された、認可制御ユニットとを含む、マルチキャスト認可制御点を提供する。
【００１５】
一実施形態では、本発明は、マルチキャスト認可制御点と、ユーザ端末とを含む、マルチキャストサービス認可制御システムを提供する。マルチキャスト認可制御点は、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得するよう構成された、取得ユニットと、取得ユニットによって取得されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施するよう構成された、認可制御ユニットとを含む。
【発明の効果】
【００１６】
本発明の実施形態では、マルチキャスト認可制御点が、ベアラ制御レイヤとの相互作用のプロセスにおいて、ベアラ制御レイヤから送られたユーザのマルチキャストサービス権限情報を取得するため、ユーザのマルチキャストサービス権限情報はマルチキャスト認可制御点によって動的に更新され、従って、保守は単純である。その後、マルチキャスト認可制御点は、新たに取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施してもよく、それにより、従来技術よりも良好な制御効果が達成される。
【図面の簡単な説明】
【００１７】
【図１】既存のＲＡＣＳの機能アーキテクチャ図である。
【図２】既存のＮＡＳＳの機能アーキテクチャ図である。
【図３】本発明の一実施形態による、マルチキャストサービス認可制御方法のフローチャートである。
【図４】本発明の一実施形態による、マルチキャスト認可制御点の概略構成図である。
【図５】本発明の第１の実施形態におけるフロー図である。
【図６】本発明の第２の実施形態におけるフロー図である。
【図７】本発明の第３の実施形態におけるフロー図である。
【図８】本発明の第４の実施形態におけるフロー図である。
【図９】本発明の第５の実施形態におけるフロー図である。
【発明を実施するための形態】
【００１８】
従来技術の分析からわかるように、ＩＰＴＶサービスの現在の発展傾向によれば、マルチキャスト技術はＩＰＴＶのベアラレイヤにおいて広く適用されるようになり、マルチキャストユーザの認可制御はＩＰＴＶサービスの動作及び発展を保証するための鍵となる。しかし、マルチキャストユーザの現在の認可制御は、静的な手法によるものであり、保守が困難で柔軟性に欠ける。結果として、現在の認可制御手法は、マルチキャストサービスの発展の初期段階における、少数のユーザとチャネルとの場合にのみ適用可能であり、ＩＰＴＶサービスを大規模に実行するという要求を完全に満たすことはできない。
【００１９】
ベアラレイヤ内のマルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を動的に更新し、番組を見ることを求めるユーザのマルチキャストサービス要求に対する認可制御の実施を支援して、ＩＰＴＶサービスを大規模に発展させるという要求を満たすために、以下が行われる。
【００２０】
本発明の一実施形態では、マルチキャストサービス認可制御方法が提供される。図３に示すように、本方法は、以下の主要なステップを含む。
【００２１】
ステップＳ１で、マルチキャスト認可制御点は、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得する。
【００２２】
このステップにおいて、マルチキャスト認可制御点は、ユーザのマルチキャストサービス権限情報を、以下の手法のうちの１つで取得する。
【００２３】
第１の手法では、ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ＮＡＳＳが、ユーザのマルチキャストサービス権限情報を、マルチキャスト認可制御点に配信する。
【００２４】
第２の手法では、マルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を、ＲＡＣＳに要求して取得する。
【００２５】
第３の手法では、マルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を、ＮＡＳＳに要求して取得する。
【００２６】
ステップＳ２で、マルチキャスト認可制御点は、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。
【００２７】
具体的な実施手法に応じて、ユーザのマルチキャストサービス権限情報は、様々な手法で示されてもよいということに留意されたい。１つの手法は、ユーザの、許容されるマルチキャストアドレスリストを直接提供することである。しかし、ユーザのマルチキャストアドレスリストは多くの内容を有し、多くのユーザのマルチキャストサービス権限は同じであるため、多数のマルチキャストアドレスリストをインタフェース上で転送するのを回避すると同時に、異なるユーザ間でマルチキャストサービス権限情報を共有するために、いくつかのマルチキャスト権限グループが定義されてもよい。例えば、基本番組権限、映画チャンネル番組権限、及びスポーツチャンネル番組権限は、それぞれ、異なるマルチキャスト権限グループによって示されてもよい。このようにして、インタフェース上で転送されるマルチキャスト権限情報は、例えば物理的なマルチキャスト権限グループの名前などの、送信側及び受信側エンティティの両方のパーティによって理解されるマルチキャスト権限グループ識別情報を使用することによって識別されてもよい。マルチキャスト権限グループの概念が導入された場合、後述の解決法において記載されるユーザのマルチキャストサービス権限情報は、例えば、ユーザのＩＰアドレス又は識別情報と、１つ以上の許容されるマルチキャストアドレス及び／又は１つ以上のマルチキャスト権限グループ識別情報とによって示される、マルチキャストサービス権限情報を含むが、これらに限定されない。
【００２８】
本発明の一実施形態では、マルチキャスト認可制御点が更に提供される。マルチキャスト認可制御点は、具体的には、ユーザのマルチキャストサービス権限情報を動的に取得する機能を有する、ＩＰエッジ又はアクセスノード（ＡＮ）（あるいはその他のエンティティ）であってもよい。図４に示すように、マルチキャスト認可制御点１は、取得ユニットと、認可制御ユニットとを含む。
【００２９】
取得ユニット１０１は、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得するように構成される。具体的には、取得ユニット１０１は、ユーザのマルチキャストサービス権限情報を、以下の手法のうちの１つで取得する。第１の手法では、ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ＮＡＳＳが、ユーザのマルチキャストサービス権限情報を、マルチキャスト認可制御点に配信する。第２の手法では、マルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を、ＲＡＣＳに要求して取得する。第３の手法では、マルチキャスト認可制御点が、ユーザのマルチキャストサービス権限情報を、ＮＡＳＳに要求して取得する。
【００３０】
認可制御ユニット１０２は、取得ユニット１０１によって取得されたマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施するように構成される。
【００３１】
本発明の一実施形態では、マルチキャストサービス認可制御システムが更に提供される。前記システムは、図４に示すマルチキャスト認可制御点と、ユーザ端末とを含んでもよい。
【００３２】
具体的な説明を、５つの実施形態により以下に示す。
【００３３】
第１の実施形態では、ＮＡＳＳが、ユーザのマルチキャストサービス権限情報を、ＲＡＣＳを介してＩＰエッジ又はＡＮに配信し、ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。
【００３４】
図５に示すように、ＮＡＳＳが、ユーザのマルチキャストサービス権限情報を、ＲＡＣＳを介してＩＰエッジ又はＡＮに配信する部分（手段）は、以下のステップを含む。
【００３５】
（１）ＮＡＳＳは、ユーザ端末の、ベアラリソースの取得とアクセスネットワークへの接続とを求める要求、又はＲＡＣＳにプッシュされたユーザアクセス加入ファイルの修正を求める要求を受信する。
【００３６】
（２）ＮＡＳＳは、ユーザアクセス加入ファイル（マルチキャストサービス権限情報を含む）を、Ａ−ＲＡＣＦに通知する。ＣＬＦとＡ−ＲＡＣＦとの間のインタフェースは、ＲＡＣＳ  Ｒ１において定義されており（ｅ４）、このインタフェースはＤｉａｍｅｔｅｒプロトコルを使用する。ＣＬＦがセッション関連情報をＡ−ＲＡＣＦに転送するための、プッシュ通知要求（ＰＮＲ）コマンドが定義されている。しかし、現在のセッション情報は、サービス権限情報を含まず、従って、例えば、ユーザＩＰアドレス及び／又はユーザ識別情報と、ユーザが受信することを認可されるマルチキャストアドレスリスト及び／又はマルチキャスト権限グループリストとを含む、ユーザのマルチキャストサービス権限情報をインタフェースが転送できるように、インタフェース機能は拡張される必要がある。
【００３７】
（３）Ａ−ＲＡＣＦは、関連情報が十分であるかどうかを調べ、結果を示すためにＮＡＳＳに応答を返す。
【００３８】
（４）Ａ−ＲＡＣＦは、ユーザのマルチキャストサービス権限情報を、ＩＰエッジ又はＡＮに送信する。サービス権限情報がＩＰエッジに設定される場合、Ａ−ＲＡＣＦと、ＩＰエッジ上の機能エンティティＲＣＥＦとの間には、Ｒｅインタフェース（このインタフェースを介してＡ−ＲＡＣＦはベアラ制御ポリシーをＲＣＥＦに配信する）が存在しており、そのため、Ｒｅインタフェース機能はマルチキャストサービス権限情報の転送をサポートするように拡張される必要がある。サービス権限情報がＡＮに設定される場合、情報は、Ａ−ＲＡＣＦとＡＮとの間で定義されたＲａインタフェースを介して転送されてもよく、Ｒａインタフェースはやはり、マルチキャストサービス情報を転送する機能を有する必要がある。
【００３９】
（５）ＩＰエッジ又はＡＮは、ユーザのマルチキャストサービス権限情報を記憶し、データベースを更新して、応答を返す。
【００４０】
ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する部分は、具体的には、ＩＰエッジ又はＡＮによって、マルチキャストグループに参加することを求めるユーザの要求が受信されたら、ユーザに対してマルチキャスト認可制御を実施し、要求されたマルチキャストグループのマルチキャストサービス権限をユーザが有する場合は、要求されたマルチキャストグループにユーザが参加することを許可し、それ以外の場合は、要求されたマルチキャストグループにユーザが参加することを拒否することを含む。
【００４１】
第２の実施形態では、ＮＡＳＳが、ユーザのマルチキャストサービス権限を、ＩＰエッジに直接配信し、ＩＰエッジが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。（この実施形態は、ＩＰエッジがマルチキャスト認可制御点として働く場合にのみ適用可能であることに留意されたい。）
【００４２】
図６に示すように、ＮＡＳＳが、ユーザのマルチキャストサービス権限を、ＩＰエッジに直接配信する部分は、以下のステップを含む。
【００４３】
（１）ユーザはネットワークにアクセスするための認証要求を発する。ＰＰＰプロトコルが使用される場合、ここでの要求は、ＩＰアドレスを取得するためにユーザによって発されるＰＰＰ確立要求であり、ＤＨＣＰモードが使用される場合、要求は、８０２．１ｘ／ＰＡＮＡ及びその他の手法に基づいてユーザによって発される認証要求である。
【００４４】
（２）認証要求は、ＵＡＡＦにユーザ認証を要求するために、ＩＰエッジを介して送信される。
【００４５】
（３）ＵＡＡＦは、ＰＤＢＦに問い合わせてユーザ加入ファイルを取得し、ユーザがネットワークへのアクセスを認可されるかどうかを判定し、ＩＰエッジを介してユーザに認証応答を返す。
【００４６】
ユーザがネットワークへのアクセスを認可される場合、ＵＡＡＦは、ＰＤＢＦにおいて取得されたユーザ加入ファイル（マルチキャストサービス権限情報を含む）を、返される認証応答内で運ぶ。現在、ユーザ加入ファイルはマルチキャストサービス権限情報を含んでおらず、従って、インタフェースがマルチキャストサービス権限情報を転送できるように、情報が追加される必要があり、かつ、関連情報が拡張される必要がある。
【００４７】
（４）ＩＰエッジは、認証応答をユーザに更に転送する。ユーザのマルチキャストサービス権限情報が応答内で運ばれる場合、ＩＰエッジは、マルチキャストサービス権限を記憶し、同時に、応答内の前記情報を削除した後で、認証応答をユーザに転送する。
【００４８】
ＩＰエッジが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する部分は、具体的には、ＩＰエッジによって、マルチキャストグループに参加することを求めるユーザの要求が受信されたら、ユーザに対してマルチキャスト認可制御を実施し、要求されたマルチキャストグループのマルチキャストサービス権限をユーザが有する場合は、要求されたマルチキャストグループにユーザが参加することを許可し、それ以外の場合は、要求されたマルチキャストグループにユーザが参加することを拒否することを含む。
【００４９】
アクセス加入ファイルの修正を求める要求をユーザが発するプロセスは、第２の実施形態で説明したステップと実質的に一致しており、ここでは繰り返さないということに留意されたい。
【００５０】
第３の実施形態では、ＩＰエッジ又はＡＮが、ユーザのマルチキャストサービス権限を、ＲＡＣＳに要求して取得し、ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。
【００５１】
図７に示すように、ＩＰエッジ又はＡＮが、ユーザのマルチキャストサービス権限を、ＲＡＣＳに要求して取得する部分は、以下のステップを含む。
【００５２】
（１）ＮＡＳＳは、ユーザ端末の、ベアラリソースの取得とアクセスネットワークへの接続とを求める要求、又はＡ−ＲＡＣＦにプッシュされたユーザアクセス加入ファイルの修正を求める要求を受信する。
【００５３】
（２）ＮＡＳＳは、ユーザアクセス加入ファイル（マルチキャストサービス権限情報を含む）を、Ａ−ＲＡＣＦに配信する。ＣＬＦとＡ−ＲＡＣＦとの間のインタフェースは、ＲＡＣＳ  Ｒ１において定義されており（ｅ４）、このインタフェースはＤｉａｍｅｔｅｒプロトコルを使用する。ＣＬＦがセッション関連情報をＡ−ＲＡＣＦに転送するための、ＰＮＲコマンドが定義されている。しかし、現在のセッション情報は、マルチキャストサービス権限情報を含まず、従って、ユーザのマルチキャストサービス権限情報をインタフェースが転送できるように、セッション情報は拡大される必要があり、かつ、インタフェース機能は拡張される必要がある。
【００５４】
（３）Ａ−ＲＡＣＦは応答を返す。
【００５５】
（４）ＩＰエッジ又はＡＮは、ユーザのＩＰアドレス又は識別情報を運ぶ、ユーザのマルチキャストサービス権限を求める要求を、Ａ−ＲＡＣＦに発する。現在、Ａ−ＲＡＣＦがベアラ制御ポリシーをＩＰエッジ又はＡＮに転送するために、ＩＰエッジとＡ−ＲＡＣＦとの間、及びＡＮとＡ−ＲＡＣＦとの間に、Ｒｅインタフェース、及びＲａインタフェースが存在しているが、関連するポリシーを求めるベアラレイヤの要求を上向きにはサポートしない。従って、ＩＰエッジ又はＡＮがＲＡＣＳへマルチキャストサービス権限の取得を求める要求を発することを、インタフェースがサポートできるように、インタフェースの機能は拡張される必要がある。
【００５６】
（５）Ａ−ＲＡＣＦは、ユーザのマルチキャストサービス権限情報を、ＩＰエッジ又はＡＮに配信する。
【００５７】
ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する部分は、具体的には、ＩＰエッジ又はＡＮによって、マルチキャストグループに参加することを求めるユーザの要求が受信されたら、ユーザに対してマルチキャスト認可制御を実施し、要求されたマルチキャストグループのマルチキャストサービス権限をユーザが有する場合は、要求されたマルチキャストグループにユーザが参加することを許可し、それ以外の場合は、要求されたマルチキャストグループにユーザが参加することを拒否することを含む。
【００５８】
第４の実施形態では、ＩＰエッジ又はＡＮが、ユーザのマルチキャストサービス権限を、ＲＡＣＳに要求して取得し、ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。
【００５９】
図８に示すように、ＩＰエッジ又はＡＮが、ユーザのマルチキャストサービス権限を、ＲＡＣＳに要求して取得する部分は、以下のステップを含む。
【００６０】
（１）ＩＰエッジ又はＡＮは、ユーザのＩＰアドレス又は識別情報を運ぶ、ユーザのマルチキャストサービス権限を求める要求を、Ａ−ＲＡＣＦに発する。現在、Ａ−ＲＡＣＦがベアラ制御ポリシーをＩＰエッジ又はＡＮに転送するために、ＩＰエッジとＡ−ＲＡＣＦとの間、及びＡＮとＡ−ＲＡＣＦとの間に、Ｒｅインタフェース、及びＲａインタフェースが存在しているが、関連するポリシーを求めるベアラレイヤの上向きの要求はサポートしない。従って、ＩＰエッジ又はＡＮがＲＡＣＳへマルチキャストサービス権限の取得を求める要求を発することを、インタフェースがサポートできるように、インタフェースの機能は拡張される必要がある。
【００６１】
（２）Ａ−ＲＡＣＦは、ユーザ加入ファイルの問い合わせを求める要求を、ＮＡＳＳに発し、この要求はユーザのＩＰアドレス又は識別情報を含む。
【００６２】
（３）ＮＡＳＳは、問い合わせを行い、ユーザアクセス加入ファイル（マルチキャストサービス権限情報を含む）を返す。ＣＬＦとＡ−ＲＡＣＦとの間のインタフェースは、ＲＡＣＳ  Ｒ１において定義されており（ｅ４）、このインタフェースはＤｉａｍｅｔｅｒプロトコルを使用する。ＣＬＦがセッション関連情報をＡ−ＲＡＣＦに転送するための、ＰＮＲコマンドが定義されている。しかし、現在のセッション情報は、マルチキャストサービス権限情報を含まず、従って、ユーザのマルチキャストサービス権限情報をインタフェースが転送できるように、セッション情報は拡大される必要があり、かつ、インタフェース機能は拡張される必要がある。
【００６３】
（４）Ａ−ＲＡＣＦは、ユーザのマルチキャストサービス権限情報を、ＩＰエッジ又はＡＮに配信する。
【００６４】
ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する部分は、具体的には、ＩＰエッジ又はＡＮによって、マルチキャストグループに参加することを求めるユーザの要求が受信されたら、ユーザに対してマルチキャスト認可制御を実施し、要求されたマルチキャストグループのマルチキャストサービス権限をユーザが有する場合は、要求されたマルチキャストグループにユーザが参加することを許可し、それ以外の場合は、要求されたマルチキャストグループにユーザが参加することを拒否することを含む。
【００６５】
第５の実施形態では、ＩＰエッジが、ユーザのマルチキャストサービス権限を、ＮＡＳＳに要求して取得し、ＩＰエッジ又はＡＮが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する。（この実施形態は、ＩＰエッジがマルチキャスト認可制御点として働く場合にのみ適用可能であることに留意されたい。）
【００６６】
図９に示すように、ＩＰエッジが、ユーザのマルチキャストサービス権限を、ＮＡＳＳに要求して取得する部分は、以下のステップを含む。
【００６７】
１）ＩＰエッジは、ユーザのマルチキャストサービス権限情報を、ＮＡＳＳに要求する。この要求は、ユーザのＩＰアドレス又は識別情報を運ぶ。
【００６８】
２）ＮＡＳＳは、問い合わせを行い、ユーザのマルチキャストサービス権限を返す。
【００６９】
ＩＰエッジが、取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施する部分は、具体的には、ＩＰエッジによって、マルチキャストグループに参加することを求めるユーザの要求が受信されたら、ユーザに対してマルチキャスト認可制御を実施し、要求されたマルチキャストグループのマルチキャストサービス権限をユーザが有する場合は、要求されたマルチキャストグループにユーザが参加することを許可し、それ以外の場合は、要求されたマルチキャストグループにユーザが参加することを拒否することを含む。
【００７０】
上記の５つの実施形態において、ユーザがオンラインである場合、マルチキャスト認可制御点は、ユーザのマルチキャストサービス権限情報を一度だけ取得し、次に、情報に従って、ユーザに対してマルチキャスト認可制御を実施してもよいということに留意されたい。マルチキャスト認可制御点は、また、ユーザのマルチキャストサービス権限情報を、ユーザがベアラリソースを取得して、アクセスネットワークへの接続を求める要求を発するか、又はＡ−ＲＡＣＦにプッシュされたユーザアクセス加入ファイルの修正を求める要求を発する際に毎回取得し、次に、新たなマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施してもよい。
【００７１】
上記を鑑みると、本発明の実施形態では、マルチキャスト認可制御点が、ベアラ制御レイヤとの相互作用のプロセスにおいて、ベアラ制御レイヤから送られたユーザのマルチキャストサービス権限情報を取得する（能動的に取得するか、又は受動的に受信する）ため、ユーザのマルチキャストサービス権限情報はマルチキャスト認可制御点によって動的に更新される。本発明の実施形態では、マルチキャスト認可制御点によって保存されたマルチキャストサービス権限情報が動的な手法で更新されるため、多数のマルチキャスト認可制御点がネットワーク内に存在する場合でも、多数のマルチキャスト認可制御点上に分散させられた、ユーザのマルチキャストサービス権限情報のネットワーク保守は単純であり、それにより、低い実装コストと管理及び保守コストとが達成され、ＩＰＴＶサービスを将来大規模に実行するという要求に適応可能となる。
【００７２】
その後、マルチキャスト認可制御点は、新たに取得したマルチキャストサービス権限情報に従って、ユーザに対してマルチキャスト認可制御を実施してもよい。本発明の実施形態では、マルチキャスト認可制御点によって保存されたマルチキャストサービス権限情報が動的な手法で更新され、動的な手法は従来技術における静的な設定手法に比較して明らかに、よりリアルタイムな特性を有するため、従来技術よりも良好な制御効果が達成される。
【００７３】
更に、本発明の実施形態では、マルチキャスト認可制御点がベアラ制御レイヤとの相互作用のプロセスの中でユーザのマルチキャストサービス権限情報を取得するための、様々な手法が提供されることで、本発明はより良好にサポートされる。
【００７４】
最後に、上記の実施形態は、本発明の技術的解決法を説明するために提供されたものに過ぎず、本発明を限定することを意図するものではないということに留意されたい。本発明について、前述の実施形態を参照して詳細に説明してきたが、前述の実施形態で説明した技術的解決法に対する修正、又は、前述の実施形態におけるいくつかの技術的特徴に対する、均等物による置換が、そのような修正又は置換によって、対応する技術的解決法の本質が本発明の実施形態における技術的解決法の精神及び範囲から逸脱しない限り、行われてもよいということを当業者は理解されたい。
【図１】
2010529725.tif 000003
【図２】
2010529725.tif 000004
【図３】
2010529725.tif 000005
【図４】
2010529725.tif 000006
【図５】
2010529725.tif 000007
2010529725.tif 000008
【図６】
2010529725.tif 000009
【図７】
2010529725.tif 000010
2010529725.tif 000011
【図８】
2010529725.tif 000012
【図９】
2010529725.tif 000013
【手続補正書】
【提出日】平成21年12月1日(2009.12.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチキャスト認可制御点によって、ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得し、
前記マルチキャスト認可制御点によって、前記取得したマルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施すること
を含む、マルチキャストサービス認可制御方法。
【請求項２】
前記マルチキャスト認可制御点が、前記ユーザのマルチキャストサービス権限情報を取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ネットワーク接続サブシステム（ＮＡＳＳ）が前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に配信する、第１の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報をリソース受付制御サブシステム（ＲＡＣＳ）に要求して取得する、第２の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を、前記ＮＡＳＳに要求して取得する、第３の手法と
のうちの１つである、請求項１に記載の方法。
【請求項３】
前記第１の手法において、前記ＮＡＳＳが前記ユーザのマルチキャストサービス権限情報を配信する手法は、
前記ＮＡＳＳが、前記ユーザのマルチキャストサービス権限情報を、前記ＲＡＣＳ内のアクセスリソース受付制御機能（Ａ−ＲＡＣＦ）を介して前記マルチキャスト認可制御点に配信する手法と、
前記ＮＡＳＳ内のユーザアクセス認可機能（ＵＡＡＦ）が、前記ユーザのマルチキャストサービス権限情報を、前記マルチキャスト認可制御点に直接配信する手法と
のうちの１つである、請求項２に記載の方法。
【請求項４】
前記第２の手法において、前記マルチキャスト認可制御点が、前記ユーザのマルチキャストサービス権限情報を、前記ＲＡＣＳに要求して取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、前記ＮＡＳＳが前記ユーザのマルチキャストサービス権限情報をＡ−ＲＡＣＦに配信し、前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記Ａ−ＲＡＣＦに要求した場合に、前記Ａ−ＲＡＣＦが前記ユーザの現在のマルチキャストサービス権限情報を前記マルチキャスト認可制御点に返す手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記Ａ−ＲＡＣＦに要求した場合に、前記Ａ−ＲＡＣＦが前記ユーザのマルチキャストサービス権限情報を前記ＮＡＳＳから取得し、前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に返す手法と
のうちの１つである、請求項２に記載の方法。
【請求項５】
前記マルチキャストサービス権限情報は、前記ユーザのインターネットプロトコル（ＩＰ）アドレス又は識別情報と、少なくとも１つのマルチキャストアドレス又は少なくとも１つのマルチキャスト権限グループ識別情報と、を含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
ベアラ制御レイヤとの相互作用のプロセスにおいて、ユーザのマルチキャストサービス権限情報を取得するように構成された、取得ユニットと、
前記取得ユニットによって取得された前記マルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施するように構成された、認可制御ユニットと
を備える、マルチキャスト認可制御点。
【請求項７】
前記マルチキャスト認可制御点は、インターネットプロトコル（ＩＰ）エッジ又はアクセスノード（ＡＮ）である、請求項６に記載のマルチキャスト認可制御点。
【請求項８】
前記取得ユニットが前記ユーザのマルチキャストサービス権限情報を取得する手法は、
前記ユーザがネットワークにアクセスする際、又は加入情報を修正する際に、ネットワーク接続サブシステム（ＮＡＳＳ）が前記ユーザのマルチキャストサービス権限情報を前記マルチキャスト認可制御点に配信する、第１の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報をリソース受付制御サブシステム（ＲＡＣＳ）に要求して取得する、第２の手法と、
前記マルチキャスト認可制御点が前記ユーザのマルチキャストサービス権限情報を前記ＮＡＳＳに要求して取得する、第３の手法と
のうちの１つである、請求項６又は７に記載のマルチキャスト認可制御点。
【請求項９】
前記ユーザのマルチキャストサービス権限情報は、拡張インタフェースプロトコルを介して前記取得ユニットに転送される、請求項８に記載のマルチキャスト認可制御点。
【請求項１０】
マルチキャスト認可制御点と、ユーザ端末とを備える、マルチキャストサービス認可制御システムであって、前記マルチキャスト認可制御点は、
ベアラ制御レイヤとの相互作用のプロセスの中で、ユーザのマルチキャストサービス権限情報を取得するように構成された、取得ユニットと、
前記取得ユニットによって取得された前記マルチキャストサービス権限情報に従って、前記ユーザに対してマルチキャスト認可制御を実施するように構成された、認可制御ユニットと
を備える、システム。
【国際調査報告】
2010529725.tif 000014
2010529725.tif 000015
2010529725.tif 000016
2010529725.tif 000017