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

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

Info

Publication number
JP4787376B2
JP4787376B2 JP2010500058A JP2010500058A JP4787376B2 JP 4787376 B2 JP4787376 B2 JP 4787376B2 JP 2010500058 A JP2010500058 A JP 2010500058A JP 2010500058 A JP2010500058 A JP 2010500058A JP 4787376 B2 JP4787376 B2 JP 4787376B2
Authority
JP
Japan
Prior art keywords
resource
multicast
spdf
multicast bearer
racf
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010500058A
Other languages
English (en)
Other versions
JP2010523026A (ja
Inventor
ファン、シビ
ツオ、ユー
チュー、ニン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2010523026A publication Critical patent/JP2010523026A/ja
Application granted granted Critical
Publication of JP4787376B2 publication Critical patent/JP4787376B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation
    • H04L47/781Centralised allocation of resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/806Broadcast or multicast traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

関連出願の相互参照
本発明は、2007年1月13日に出願された中国特許出願第200710111019.3号の優先権を主張する、2008年5月7日に出願されたPCT/CN2008/070904の出願であり、これら2件の出願の内容は参照により本明細書に組み込まれている。
本発明は、通信およびネットワークの分野に関し、特に、マルチキャストベアラリソースを制御するための方法、装置、およびシステムに関する。
インターネットプロトコルテレビジョン(Internet Protocol Television)(IPTV)サービスは、ブロードバンドIPネットワークに基づいており、主としてストリーミングメディアに焦点が合わせられている。従来のTVに比較して、IPTVは、より豊富かつ柔軟なサービスをサポートすることと、包括的なIPTV付加価値サービスプラットフォームを提供することと、通信、データ、ビデオ、およびオーディオなどのサービスを実現することとが可能である。IPTVのうち、ライブテレビジョン/放送テレビジョン(live television/broadcast television)(LTV/BTV)サービス、すなわち、ポイントツーマルチポイント通信においては、ソースによって生成されたデータが、複数の宛先ノードに送信される必要がある。現在のところ、ポイントツーマルチポイント通信の解決法は、ネットワーク帯域幅を効果的に利用して、帯域幅リソースの無駄を回避することが可能な、マルチキャスト技術である。
関連技術1:マルチキャスト技術をサポートするために、リソース受付制御サブシステム(Resource and Admission Control Subsystem)(RACS)アーキテクチャが提案されており、これは、テレコミュニケーション・アンド・インターネット・コンバージド・サービス・アンド・プロトコルズ・フォー・アドバンスト・ネットワーキング(Telecommunication and Internet converged Services and Protocols for Advanced Networking)(TISPAN)において詳細に記載されている。
リソース受付制御を実装することによって、RACSは、トランスポートネットワークのリソースの正しくかつ適切な使用を確実にし、かくして、サービスのサービス品質(Quality of Service)(QoS)を保証し、帯域幅およびサービスが使われてしまうのを防止するように、トランスポートネットワークの詳細をサービス層から隠し、サービス制御とトランスポート機能との分離をサポートし、そして、トランスポートネットワークのリソース利用状況を認識するようになる。図1は、RACSの機能アーキテクチャを示す。図中の主要なネットワーク要素について、以下で紹介する。
サービスベースのポリシー決定機能(service−based policy decision function)(SPDF)は、アプリケーション層への汎用インタフェースを提供し、基礎をなすネットワークトポロジおよび特定のアクセスタイプを隠し、サービスベースのポリシー制御を提供する。SPDFは、アプリケーション機能(Application Function)(AF)の要求に従って、ローカルポリシーを選択し、その要求を、インターネットプトロコルサービス品質(IPQoS)パラメータにマッピングし、そして、そのパラメータを、対応するリソースを要求するために、アクセスリソース受付制御機能(Access−Resource and Admission Control Function)(A−RACF)およびボーダーゲートウェイ機能(Border Gateway Function)(BGF)に送信する。
A−RACFは、アクセスネットワーク内に配置され、受付制御機能およびネットワークポリシー収束(network policy convergence)機能を有する。A−RACFは、SPDFからの要求を受信し、そして次に、記憶されたポリシーに従って受付制御を実現し、かくして、トランスポートリソースに対する要求を受け入れるか、または拒否する。A−RACFは、ネットワーク接続情報(network attachment information)およびユーザQoSリスト情報(user QoS list information)を、e4参照点(e4 reference point)を介して、ネットワーク接続サブシステム(Network Attachment Sub−System)(NASS)から取得する。したがって、利用可能なネットワークリソースが、ネットワーク位置情報(例えば、アクセスユーザの物理的なノードアドレス)に応じて判定され得る。その一方で、ユーザQoSリスト情報は、リソース割り当て要求が処理される際に参照される。
トランスポート層は、3つのタイプの機能エンティティを含む。それらのうち、BGFは、(コアボーダーゲートウェイ(core border gateway)の機能を実現するために)アクセスネットワークとコアネットワークとの間に配置されてもよく、(インターネットボーダーゲートウェイ(Internet border gateway)の機能を実現するために)2つのコアネットワークの間に配置されてもよい、ボーダーゲートウェイである。SPDFの制御下で、BGFは、ネットワークアドレス変換(Network Address Translation)(NAT)、ゲーティング、QoSラベル、帯域幅制限、測定、およびリソース同期の機能を完了する。リソース制御実行機能(Resource Control Enforcement Function)(RCEF)は、ゲーティング、QoSラベル、帯域幅制限、およびその他の機能を達成するために、A−RACFによってRe参照点を介して送信された、アクセスオペレータによって定義されたレイヤ2/レイヤ3(L2/L3)メディアストリームポリシーを実装する。レイヤ2終端機能(Layer 2 Termination Function)(L2TF)は、アクセスネットワーク内のレイヤ2接続を終端する機能エンティティである。RCEFとL2TFとは異なる機能エンティティであり、一般に、物理的装置IPエッジ(IP Edge)上で一緒に実現される。
さらに、RACS R2の最新のドラフトでは、リソース受付制御を実行するためにコアネットワーク内に配置される新しい機能、すなわち、コアRACF(Core−RACF)(C−RACF)が定義されている。
関連技術2:マルチキャストベアラリソースの制御について行う以下の説明を容易にするために、ベアラ層ネットワーク(bearer layer network)は、図2に示すように、アクセスネットワーク、アクセス収束ネットワーク、およびコアネットワークという3つのセグメントに分割される。ユーザ装置(user equipment)(UE)と、受付制御ポリシー実行ノード(admission control policy enforcement node)(ANまたはIPエッジであってもよい)との間のセグメントは、アクセスネットワークと呼ばれる。このノードと、コアボーダーノードとの間のセグメントは、アクセス収束ネットワークと呼ばれる。コアボーダーノードを越えるセグメントは、コアネットワークセグメントと呼ばれる。SPDFは、AFに、最終的なリソース許可結果を返す。
IPTVマルチキャストサービスは、現在のところ、従来のネットワーク内で運用されているが、RACS内でのマルチキャストベアラリソースの効果的な制御は実現されていない、ということを、発明者は、研究および適用の間に見出した。
したがって、本発明は、リソース受付制御サブシステム(RACS)に基づいてマルチキャストベアラリソースを制御するように、マルチキャストベアラリソースを制御するための、方法、装置、およびシステムに関する。
本発明の方法は、以下のステップを含む。
RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信し、マルチキャストベアラリソースを制御する。
本発明のネットワークエンティティは、RACS内に配置され、ベアラ層ネットワークエンティティからマルチキャストベアラリソースを制御する要求を受信するように適合された受信ユニットと、マルチキャストベアラリソースを制御するように適合された制御ユニットと、を含む。
本発明の、マルチキャストベアラリソースを制御するためのシステムは、マルチキャストベアラリソースを制御する要求を発する(initiate)ように適合されたベアラ層ネットワークエンティティと、ベアラ層ネットワークエンティティからマルチキャストベアラリソースを制御する要求を受信し、マルチキャストベアラリソースを制御するように適合されたRACS内のネットワークエンティティと、を含む。
本発明では、ユーザから、マルチキャストベアラリソースを制御する要求を受信した後で、ベアラ層ネットワークエンティティは、RACSに、マルチキャストベアラリソースを制御する要求を転送し、そして、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信した後で、RACS内のネットワークエンティティは、マルチキャストベアラリソースを制御する。したがって、RACSは、マルチキャストトラフィックフローのリソース制御をサポートすることが可能である。このように、マルチキャストリソースのための管理および受付制御機能は、ベアラ層エンティティ内に導入される必要はない。その一方で、ユニキャストおよびマルチキャストリソースの集中型の統合された管理が達成されることが可能であり、したがって、ユニキャストサービスとマルチキャストサービスとがベアラリソースを完全に共用できることが保証される。
従来のRACSの機能アーキテクチャを示す。 従来技術における、3つのセグメントに分割されたベアラ層ネットワークの概略図である。 本発明の一実施形態による、マルチキャストベアラリソースを制御するための方法のフローチャートである。 本発明の一実施形態による、マルチキャストベアラリソースを制御するための装置の、RACS内のネットワークエンティティの概略構成図である。 本発明の第1の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第2の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第3の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第4の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第5の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第6の実施形態による、マルチキャストベアラリソースを制御するための方法のフロー図である。 本発明の第7の実施形態による、マルチキャストベアラリソースを制御するための方法のフローチャートである。
リソース受付制御サブシステム(RACS)を適用することによってマルチキャストベアラリソースを制御するために、本発明は、マルチキャストトラフィックフローのリソース制御をRACSがサポートすることを可能にし、かくして、インターネットプロトコルテレビジョン(IPTV)サービスの円滑な進行を保証するように、RACSを使用してマルチキャストベアラリソースを制御する、解決法を提案する。
上記の目的に基づいて、本発明は、マルチキャストベアラリソースを制御するための方法を提供する。図3を参照すると、この方法は以下のステップを含む。
ステップS1で、RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信する。
RACSによるマルチキャストベアラリソースの制御を達成するために、マルチキャストグループ参加要求メッセージ、リソース変更要求メッセージ、またはリソース解放要求メッセージをユーザから受信した後で、アクセスノード(access node)(AN)またはIPエッジであってもよい、ベアラ層エンティティは、RACSに、マルチキャストベアラリソースを制御する要求を能動的に発し、かくして、マルチキャストベアラリソースの制御をRACSに引き渡す必要がある。
ステップS2で、RACS内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースを制御する。
RACS内のネットワークエンティティが、ベアラ層ネットワークエンティティによって発された要求に従って、マルチキャストベアラリソースを制御し、制御応答を返すプロセスは、ユーザによって発されたさまざまな制御要求に応じて、以下の場合を含む。
場合1:RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信し、そして、RACS内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、そして、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、アクセスリソース受付制御機能(A−RACF)である場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、A−RACFは、要求に従って、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、そして、アクセス側の申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、A−RACFは、要求に従って、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、サービスベースのポリシー決定機能(SPDF)またはコア−RACF(C−RACF)に、コアネットワークのマルチキャストベアラリソースを申し込み、そして、アクセス側およびコアネットワークの申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、SPDFである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、SPDFは、A−RACFに、アクセス側のマルチキャストベアラリソースを申し込み、そして、アクセス側の申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを申し込む要求を受信した後で、SPDFは、A−RACFおよびC−RACFに、アクセス側およびコアネットワークのマルチキャストベアラリソースをそれぞれ申し込み、そして、アクセス側およびコアネットワークの申し込み結果に従って、ベアラ層ネットワークエンティティに、リソース申し込み結果応答を返す。
場合2:RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信し、そして、RACS内のネットワークエンティティは、要求に従って、マルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、そして、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、A−RACFである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、A−RACFは、要求に従って、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、そして、アクセス側の変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、A−RACFは、マルチキャストベアラリソースを変更する要求に従って、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行し、SPDFまたはC−RACFに、コアネットワークのマルチキャストベアラリソースを変更することを要求し、そして、アクセス側およびコアネットワークの変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、SPDFである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、SPDFは、A−RACFに、アクセス側のマルチキャストベアラリソースを変更することを要求し、そして、アクセス側の変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを変更する要求を受信した後で、SPDFは、A−RACFおよびC−RACFに、アクセス側およびコアネットワークのマルチキャストベアラリソースを変更することをそれぞれ要求し、そして、アクセス側およびコアネットワークの変更結果に従って、ベアラ層ネットワークエンティティに、リソース変更結果応答を返す。
場合3:RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信し、そして、RACS内のネットワークエンティティは、対応するマルチキャストベアラリソースを解放し、そして、ベアラ層ネットワークエンティティに、解放結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、A−RACFである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、A−RACFは、アクセス側のマルチキャストベアラリソースを解放し、そして、アクセス側の解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、A−RACFは、アクセス側のマルチキャストベアラリソースを解放し、SPDFまたはC−RACFに、コアネットワークのマルチキャストベアラリソースを解放することを要求し、そして、アクセス側およびコアネットワークの解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。
特に、ベアラ層ネットワークエンティティと相互作用する、RACS内のネットワークエンティティが、SPDFである場合、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、SPDFは、A−RACFに、アクセス側のマルチキャストベアラリソースを解放することを要求し、そして、アクセス側の解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。あるいは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを解放する要求を受信した後で、SPDFは、A−RACFおよびC−RACFに、アクセス側およびコアネットワークのマルチキャストベアラリソースを解放することをそれぞれ要求し、そして、アクセス側およびコアネットワークの解放結果に従って、ベアラ層ネットワークエンティティに、解放結果応答を返す。
本発明は、RACS内に配置された、A−RACFまたはSPDFであってもよい、ネットワークエンティティをさらに提供する。図4を参照すると、ネットワークエンティティは、受信ユニットと、制御ユニットとを含み、そして、応答ユニットをさらに含んでもよい。
受信ユニットは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように適合される。
制御ユニットは、受信ユニットによって受信された要求に従って、マルチキャストベアラリソースを制御するように適合される。
応答ユニットは、マルチキャストベアラリソースを制御する要求を発するベアラ層ネットワークエンティティに、制御応答を返すように適合される。
本発明は、マルチキャストベアラネットワークをさらに提供する。マルチキャストベアラネットワークは、ベアラ層ネットワークエンティティとRACS内のネットワークエンティティとを含む。
ベアラ層ネットワークエンティティは、マルチキャストベアラリソースを制御する要求を発するように適合される。
RACS内のネットワークエンティティは、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように、そして、マルチキャストベアラリソースを制御する要求に従って、マルチキャストベアラリソースを制御するように、そして、ベアラ層ネットワークエンティティに制御応答を返すように、適合される。特に、RACS内のネットワークエンティティは、マルチキャストベアラリソースを制御する要求に従って、アクセス側のマルチキャストベアラリソースを制御するか、または、マルチキャストベアラリソースを制御する要求に従って、アクセス側およびコアネットワークのマルチキャストベアラリソースを制御する。
以下の6つの実施形態を参照して、本発明についてさらに詳細に説明する。
第1の実施形態では、A−RACFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANは、ユーザから、マルチキャストグループ参加要求を受信した後で、A−RACFに、マルチキャストベアラリソースを申し込み、A−RACFは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行する。場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよい。A−RACFは、アクセス側の状況に応じて、または、ネットワーク全体の申し込み結果に従って、ベアラ層に、最終的な応答を返す。図5を参照すると、この実施形態は、以下のステップを含む。
1.IPエッジまたはANは、ユーザからマルチキャストグループ参加要求を受信し、そして、ユーザが参加しようと意図しているマルチキャストグループのアドレスと、ユーザのIPアドレスとを、マルチキャストグループ参加要求から取得し、そして、1つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード(例えば、EXCLUDEまたはINCLUDE)などのその他の情報をさらに取得してもよい。
2.IPエッジまたはANは、A−RACFに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ユーザのIPアドレスまたはIDと、マルチキャストストリームの記述情報とを運ぶ。マルチキャストストリームの記述情報は、マルチキャストグループのDクラスアドレスを含まなければならず、そして、場合によっては、1つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード(例えば、EXCLUDEまたはINCLUDE)を含む。IPエッジまたはANに、マルチキャストグループによって要求される帯域幅リソースに関する情報が設定されている場合、その情報も、マルチキャストベアラリソースを申し込む要求の中で運ばれなければならない。
3.このステップのリソース許可に関する内容は、以下の2つの部分を含む。
最初に、場合によっては、A−RACFは、ユーザのマルチキャストサービス権限に応じて、マルチキャストベアラリソースを申し込む要求に従って、サービス許可を実行してもよい。
その後、A−RACFは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための受付許可およびリソース予約を実行する。特に、マルチキャストベアラリソースを申し込む要求が帯域幅情報を含まない場合、A−RACFは、マルチキャストグループによって要求される帯域幅を取得するために、ローカル構成に問い合わせる。マルチキャストストリームがIPエッジまたはANにおいてすでに存在していることをA−RACFが判定した場合、A−RACFは、アクセスネットワークのリソースを許可および予約する必要があり、マルチキャストストリームがIPエッジまたはANにおいて存在していないことをA−RACFが判定した場合、A−RACFは、アクセスネットワークおよび収束ネットワークのリソースを許可および予約する必要がある。
さらに、場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよく、すなわち、プロセスはステップ4〜6に進む。
4.A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースを申し込む要求を発する。コアネットワークのマルチキャストベアラリソースを申し込む要求は、ステップ2におけるのと同じ情報を運ぶ。
5.SPDF/C−RACFは、コアネットワークのリソースを許可する。
6.SPDF/C−RACFは、リソース許可が認められたかどうかを示すために、許可結果を返す。
7.A−RACFは、アクセス側の申し込み結果に従って、または、アクセス側およびコア側の申し込み結果に従って、IPエッジまたはANに、リソース許可結果応答を返す。
第2の実施形態では、A−RACFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANが、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信した後で、IPエッジまたはANは、A−RACFに、マルチキャストベアラリソースを変更する要求を発し、そして、A−RACFは、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース変更を実行する。場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースを変更することを、さらに要求する。最後に、A−RACFは、IPエッジまたはANに、リソース変更結果応答を返す。図6を参照すると、この実施形態は、以下のステップを含む。
1.IPエッジまたはANは、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信し、マルチキャストソースアドレスを変更する要求から、ユーザのIPアドレスを取得し、そして、ユーザが変更を要求するマルチキャストソースアドレス、またはその他のQoS情報を取得してもよい。
2.IPエッジまたはANは、A−RACFに、マルチキャストベアラリソースを変更する要求を発する。マルチキャストベアラリソースを変更する要求は、ユーザのIPアドレスまたはIDを運ぶ必要があり、そして、場合によっては、変更されるマルチキャストソースアドレス、またはその他のQoS情報を運ぶ。
3.A−RACFは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースを変更するための、受付許可およびリソース予約を実行する。場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースを変更することをさらに要求してもよく、すなわち、プロセスはステップ4〜6に進む。
4.A−RACFは、SPDF/C−RACFに、マルチキャストリソースを変更する要求を発する。マルチキャストリソースを変更する要求は、ステップ2におけるのと同じ情報を運ぶ。
5.SPDF/C−RACFは、コアネットワークのリソース状況に応じて、コアネットワークのマルチキャストリソースの変更を許可する。
6.SPDF/C−RACFは、マルチキャストリソース変更許可応答を返す。
7.A−RACFは、アクセス側のマルチキャストリソース変更結果に従って、または、アクセス側およびコア側のマルチキャストリソース変更結果に従って、IPエッジまたはANに、最終的な許可応答を返す。
第3の実施形態では、A−RACFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANが、マルチキャストグループ離脱要求をユーザから受信した後、または、マルチキャストグループをユーザが異常に離脱したことを検出した後で、IPエッジまたはANは、A−RACFに、マルチキャストベアラリソースを解放する要求を発する。A−RACFは、アクセスネットワークのマルチキャストベアラリソースを、または、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストベアラリソースを、解放する。場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのリソースを解放することを、さらに要求してもよい。最後に、A−RACFは、IPエッジまたはANに、リソース解放応答を返す。図7を参照すると、この実施形態は、以下のステップを含む。
1.マルチキャストグループを離脱する要求をユーザから受信した後、または、ユーザがマルチキャストグループを異常に離脱したことを検出した後で、IPエッジまたはANは、ユーザが離脱しようと意図しているマルチキャストグループのアドレスと、ユーザのIPアドレスとを、マルチキャストグループを離脱する要求から取得する。
2.IPエッジまたはANは、A−RACFに、マルチキャストベアラリソースを解放する要求を発する。IPエッジまたはANと、A−RACFとの間のインタフェースが、ダイアメータプロトコル(diameter protocol)を採用している場合、マルチキャストベアラリソースを解放する要求は、セッションIDを運ぶ必要があり、IPエッジまたはANと、A−RACFとの間のインタフェースが、ダイアメータプロトコルを採用していない場合、マルチキャストベアラリソースを解放する要求は、ユーザのIPアドレスまたはIDと、マルチキャストグループの記述情報とを運ぶ必要がある。
3.A−RACFは、アクセスネットワークのマルチキャストベアラリソースを解放する。A−RACFが、IPエッジまたはANにおける少なくとも1つの他のユーザがマルチキャストグループに属することを判定した場合、A−RACFは、アクセスネットワークのリソースを解放する必要があるのみである。ユーザが、マルチキャストグループを離脱する、IPエッジまたはANにおける最後の1つである場合、A−RACFは、アクセスネットワークと収束ネットワークとの両方のリソースを解放する必要がある。場合によっては、A−RACFは、SPDF/C−RACFに、コアネットワークのマルチキャストベアラリソースを解放することをさらに要求してもよく、すなわち、プロセスはステップ4〜6に進む。
4.A−RACFは、SPDF/C−RACFに、マルチキャストベアラリソースを解放する要求を発する。マルチキャストベアラリソースを解放する要求は、セッションIDを運ぶ。
5.SPDF/C−RACFは、コアネットワークのマルチキャストリソースを解放する。
6.SPDF/C−RACFは、マルチキャストリソース解放応答を返す。
7.A−RACFは、アクセス側のマルチキャストリソース解放結果に従って、または、アクセス側およびコア側のマルチキャストリソース解放結果に従って、IPエッジまたはANに、最終的な応答を返す。
第4の実施形態では、SPDFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANと、SPDFとの間で、マルチキャストリソース申し込み要求/応答が転送される必要がある。(従来技術において、ユニキャストリソース許可要求/応答を転送するように適合された)Gq’インタフェースが、IPエッジまたはANと、SPDFとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース申し込み要求/応答の転送をサポートするように拡張されてもよい。
ユーザから、マルチキャストグループ参加要求を受信した後で、IPエッジまたはANは、SPDFに、マルチキャストベアラリソースを申し込む要求を発する。SPDFは、マルチキャストベアラリソースを申し込む要求を許可し、A−RACFに、アクセス側のマルチキャストベアラリソースを申し込む。A−RACFは、アクセス側について指摘する、ポリシーと、リソースの状況とに応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、同時に、SPDFに、申し込み結果を返す。場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースをさらに申し込んでもよい。SPDFは、アクセス側またはネットワーク全体のリソース許可状況に応じて、IPエッジまたはANに、最終的な応答を返す。図8を参照すると、この実施形態は、以下のステップを含む。
1.IPエッジまたはANは、ユーザからマルチキャストグループ参加要求を受信し、そして、ユーザが参加しようと意図しているマルチキャストグループのアドレスと、ユーザのIPアドレスとを、メッセージから取得し、そして、1つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード(例えば、EXCLUDEまたはINCLUDE)などのその他の情報をさらに取得してもよい。
2.IPエッジまたはANは、SPDFに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ユーザのIPアドレスまたはIDと、マルチキャストストリームの記述情報とを運ぶ。マルチキャストストリームの記述情報は、マルチキャストグループのDクラスアドレスを含まなければならず、そして、場合によっては、1つ以上のマルチキャストソースアドレス、およびソースアドレスフィルタリングモード(例えば、EXCLUDEまたはINCLUDE)を含む。IPエッジまたはANに、この時マルチキャストグループによって要求される帯域幅リソースに関する情報が設定されている場合、その情報は、マルチキャストベアラリソースを申し込む要求の中で運ばれなければならない。
3.SPDFは、マルチキャストベアラリソースを申し込む要求に従って、サービス許可を実行する。その一方で、場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを許可することを要求してもよく、すなわち、プロセスはステップ7〜9に進む。
4.SPDFは、A−RACFに、マルチキャストベアラリソースを申し込む要求を発する。マルチキャストベアラリソースを申し込む要求は、ステップ2におけるのと同じ情報を運ぶ。
5.マルチキャストベアラリソースを申し込む要求を受信した後で、A−RACFは、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースのための受付許可およびリソース予約を実行する。特に、A−RACFは、対応するマルチキャストストリームが、対応するIPエッジまたはANにおいてすでに存在しているかどうかを判定する。対応するマルチキャストストリームが、対応するIPエッジまたはANにおいてすでに存在していることをA−RACFが判定した場合、A−RACFは、アクセスネットワークのネットワークリソース状況に応じて、アクセス側のマルチキャストベアラリソースのための、受付許可およびリソース予約を実行し、対応するマルチキャストストリームが、対応するIPエッジまたはANにおいてまだ存在していないことをA−RACFが判定した場合、A−RACFは、アクセスネットワークおよびアクセス収束ネットワークのネットワークリソース状況に応じて、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストベアラリソースのための、受付許可およびリソース予約を実行する。
6.A−RACFは、マルチキャストリソース許可が認められたかどうかを示すために、許可結果を返す。
7.場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを申し込む。
8.C−RACFは、コアネットワークのリソース状況に応じて、マルチキャストベアラリソースを申し込む要求を許可する。
9.C−RACFは、SPDFに、許可応答を返す。
10.SPDFは、アクセス側のマルチキャストリソース許可結果に従って、または、アクセス側およびコア側のマルチキャストリソース許可結果に従って、ベアラ層に応答を返す。
第5の実施形態では、SPDFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANと、SPDFとの間で、マルチキャストリソース変更要求/応答が転送される必要がある。(従来技術において、ユニキャストリソース許可変更要求/応答を転送するように適合された)Gq’インタフェースが、IPエッジまたはANと、SPDFとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース変更要求/応答の転送をサポートするように拡張されてもよい。
IPエッジまたはANが、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信した後で、IPエッジまたはANは、SPDFに、マルチキャストベアラリソースを変更する要求を発する。SPDFは、マルチキャストベアラリソースを変更する要求を許可し、A−RACFに、アクセス側のマルチキャストベアラリソースを変更することを要求する。場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを変更することをさらに要求してもよい。最後に、SPDFは、IPエッジまたはANに、リソース変更結果応答を返す。図9を参照すると、この実施形態は、以下のステップを含む。
1.IPエッジまたはANは、ユーザから、マルチキャストソースアドレスを変更する要求、またはリソース変更をトリガすることが可能なその他のシグナリングメッセージを受信し、マルチキャストソースアドレスを変更する要求から、ユーザのIPアドレスを取得し、そして、変更されるマルチキャストソースアドレス、またはその他のQoS情報を取得してもよい。
2.IPエッジまたはANは、SPDFに、マルチキャストベアラリソースを変更する要求を発する。マルチキャストベアラリソースを変更する要求は、ユーザのIPアドレスを運び、そして、場合によっては、変更されるマルチキャストソースアドレス、またはその他のQoS情報を運ぶ。
3.SPDFは、A−RACFに、マルチキャストリソースを変更する要求を発する。マルチキャストリソースを変更する要求は、ステップ2におけるのと同じ情報を運ぶ。
4.SPDFによって送信された、リソースを変更する要求を受信した後で、A−RACFは、マルチキャストリソースを変更する要求に従って、アクセス側のポリシーとリソース状況とに応じて、アクセス側のマルチキャストベアラリソースを変更するための受付許可およびリソース予約を実行する。
5.A−RACFは、マルチキャストリソース変更許可結果を返す。
6.場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを変更することを要求する。
7.C−RACFは、コアネットワークのリソース状況に応じて、コアネットワークのマルチキャストベアラリソースの変更を許可する。
8.C−RACFは、マルチキャストベアラリソース変更応答を返す。
9.SPDFは、アクセス側のマルチキャストリソース変更許可結果に従って、または、アクセス側およびコア側のマルチキャストリソース変更許可結果に従って、IPエッジまたはANに、最終的な応答を返す。
第6の実施形態では、SPDFが最終的なポリシー決定点として使用される場合、ベアラ層ネットワークエンティティIPエッジまたはANと、SPDFとの間で、マルチキャストリソース解放要求/応答が転送される必要がある。(従来技術において、ユニキャストリソース許可要求/応答を転送するように適合された)Gq’インタフェースが、IPエッジまたはANと、SPDFとの間で再利用されてもよく、インタフェース能力は、マルチキャストリソース解放要求/応答の転送をサポートするように拡張されてもよい。
IPエッジまたはANが、ユーザから、マルチキャストグループ離脱要求を受信した後で、IPエッジまたはANは、SPDFに、マルチキャストリソースを解放する要求を発する。SPDFは、A−RACFに、アクセス側のマルチキャストベアラリソースを解放することを要求する。A−RACFは、応答を返す。この時、場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを解放することをさらに要求してもよい。最後に、SPDFは、IPエッジまたはANに、リソース解放応答を返す。図10を参照すると、この実施形態は、以下のステップを含む。
1.ユーザから、マルチキャストグループを離脱する要求を受信した後で、IPエッジまたはANは、ユーザが離脱しようと意図しているマルチキャストグループのアドレスと、ユーザのIPアドレスとを、メッセージから取得する。
2.IPエッジまたはANは、SPDFに、マルチキャストベアラリソースを解放する要求を発する。IPエッジまたはANと、SPDFとの間のインタフェースが、ダイアメータプロトコルを採用している場合、マルチキャストベアラリソースを解放する要求は、セッションIDを運ぶ必要があるのみであり、IPエッジまたはANと、SPDFとの間のインタフェースが、ダイアメータプロトコルを採用していない場合、マルチキャストベアラリソースを解放する要求は、ユーザのIPアドレスまたはIDと、マルチキャストグループの記述情報とを運ぶ必要がある。
3.SPDFは、アクセス側のマルチキャストリソースを解放するようA−RACFに要求するために、A−RACFに、マルチキャストリソース解放要求を発する。要求は、セッションIDを運ぶ。
4.SPDFによって送信されたリソース解放要求を受信した後で、A−RACFは、対応するマルチキャストリソースを解放する。特に、A−RACFは、対応するIPエッジまたはANにおいてマルチキャストストリームを使用しているユーザがいないかどうかを判定する。対応するIPエッジまたはANにおいて、マルチキャストストリームを使用しているユーザがいないということを、A−RACFが判定した場合、A−RACFは、アクセスネットワークおよびアクセス収束ネットワークの、対応するマルチキャストストリームによって占有されているネットワークリソースを解放し、対応するIPエッジまたはANにおいて、マルチキャストストリームを使用しているユーザがいるということを、A−RACFが判定した場合、A−RACFは、アクセスネットワークの、対応するマルチキャストストリームによって占有されているネットワークリソースを解放するのみである。
5.A−RACFは、マルチキャストリソース解放結果を返す。
6.場合によっては、SPDFは、C−RACFに、コアネットワークのマルチキャストベアラリソースを解放することを要求する。
7.C−RACFは、コアネットワークのマルチキャストベアラリソースを解放する。
8.C−RACFは、リソース解放応答を返す。
9.SPDFは、アクセス側のマルチキャストリソース解放結果に従って、または、アクセス側およびコア側のマルチキャストリソース解放結果に従って、IPエッジまたはANに、最終的な応答を返す。
第7の実施形態では、上記の実施形態からわかるように、マルチキャスト技術とユニキャスト技術との間の違いにより、SPDFおよび/またはA−RACFは、マルチキャストベアラリソースの制御をRACSが実装することを可能にするために、マルチキャスト技術の特性に従ってマルチキャストリソース関連の要求(申し込み、解放、または変更)を処理する機能をさらに備える必要がある。ここでは、A−RACFによってマルチキャストリソース関連の要求を処理するためのアルゴリズムを、以下に例示する。
(S,G)は、マルチキャストストリームを表し、ここで、Sは、マルチキャストソースアドレスであり、Gは、マルチキャストグループアドレスであり、そして、Nは、IPエッジまたはANにおいて(S,G)によってサービスを提供される、アクセスユーザの数である。
マルチキャストリソース要求を処理するためのプロセスを決定するために、A−RACFは、リソースを要求しているマルチキャストストリーム(S,G)と、マルチキャストストリームを受信しているユーザの数(N)との間の対応する関係を記憶し、そして、Nをリアルタイムで更新する必要がある。A−RACFによってマルチキャストリソース関連の要求を処理するためのアルゴリズムを、図11に示す。A−RACFが、SPDFから、マルチキャストリソース要求を受信した場合、A−RACFは、要求のタイプを判定する。
a)マルチキャストリソースを申し込む要求。A−RACFは、マルチキャストストリーム(S,G)がすでに存在しているかどうかを判定する。A−RACFが、マルチキャストストリーム(S,G)は存在していないと判定した場合、A−RACFは、この(S,G)のための対応するN(N=1)を作成し、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストリソースを同時に許可する。対応するNがすでに存在している場合は、N=N+1とし、アクセスネットワークのマルチキャストリソースが許可される。
b)マルチキャストリソースを解放する要求。A−RACFは、(S,G)に対応するNが、(N=N−1)の後で、0に等しいかどうかを判定する。(S,G)に対応するNが、(N=N−1)の後で、0に等しいとA−RACFが判定した場合は、(S,G)とNとの間の対応する関係は削除され、アクセスネットワークおよびアクセス収束ネットワークのマルチキャストリソースが、解放されることが許可される。それ以外の場合は、アクセスネットワークのマルチキャストリソースが、解放されることが許可される。
c)マルチキャストリソースを変更する要求。最初に、a)で説明したアルゴリズムに従って、新しいマルチキャストリソースが申し込まれ、そして、b)で説明したアルゴリズムに従って、元のマルチキャストリソースが解放される。
要約すると、マルチキャストリソース管理およびマルチキャストリソース受付制御機能は、一般に、現在のライブテレビジョン/放送テレビジョン(LTV/BTV)システムのアーキテクチャ内のベアラ層エンティティにおいて直接実現される。一方では、この方法は、マルチキャストリソースの管理と受付制御とがベアラ層エンティティにおいて実現されることを要求するため、ベアラ層装置の複雑さが増加し、また、イーサネット(登録商標)スイッチおよびルータなどの多くの既存のベアラ層装置は、マルチキャストリソースの管理機能および受付制御機能をサポートしないため、実際のネットワーキング適用例内にこの方法を実装することは困難である。他方では、この方法では、マルチキャストベアラリソースはベアラ層エンティティにおいて管理されるが、これに対して、現在の次世代ネットワーク(next generation network)(NGN)アーキテクチャでは、ユニキャストベアラリソースはRACS内で管理される。結果として、ユニキャストおよびマルチキャストベアラリソースの管理はNGNネットワーク内で分離され、ユニキャストサービスとマルチキャストサービスとがネットワークベアラリソースを完全に共用することはできないということがもたらされるか、または、ユニキャストサービスとマルチキャストサービスとの間でのネットワークリソースの共用を達成するために、複雑なネットワークベアラリソース同期機構を導入する必要がある。本発明によって提供される、NGNネットワーク内のRACSを使用することによってマルチキャストベアラリソースを制御するための方法は、好ましい解決法である。
現在のところ、RACSアーキテクチャは、ユニキャストベアラリソースの管理をサポートするのみであり、しかし、マルチキャストベアラリソースの制御をサポートすることはできない。
したがって、本発明では、ユーザから、マルチキャストベアラリソースを制御する要求を受信した後で、ベアラ層エンティティは、その要求をRACSに転送し、そして、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信した後で、RACS内のネットワークエンティティは、マルチキャストベアラリソースを制御する要求に従って、マルチキャストベアラリソースを制御し、ベアラ層ネットワークエンティティに、制御応答を返す。したがって、RACSは、マルチキャストトラフィックフローのリソース制御をサポートすることが可能である。このように、マルチキャストリソースのための管理および受付制御機能は、ベアラ層エンティティ内に導入される必要はない。その一方で、ユニキャストおよびマルチキャストリソースの集中型の統合された管理が達成されることが可能であり、したがって、ユニキャストサービスとマルチキャストサービスとがベアラリソースを完全に共用することが保証される。それゆえ、IPTVマルチキャストサービスのQoSは向上し、かくして、IPTVサービスの円滑な進行が保証される。
本発明の実施形態による方法のステップのすべてまたは一部は、関連するハードウェアに指示するプログラムによって実装されてもよいということを、当業者は理解すべきである。プログラムは、コンピュータ読み取り可能な記憶媒体内に記憶されてもよい。プログラムが実行される場合、本発明の実施形態による方法のステップが実行される。記憶媒体は、ROM、RAM、磁気ディスク、および光ディスクなどの、プログラムコードを記憶することが可能な任意の媒体であってもよい。
最後に、上記の実施形態は、本発明の技術的解決法を説明するためにのみ使用され、限定するためには使用されないということが理解されるべきである。上記の好ましい実施形態を参照した、本発明の詳細な説明にもかかわらず、さまざまな修正、変更、または等価な置換が、本発明の範囲を逸脱することなく当業者によって行われることが可能であり、本発明の特許請求の範囲に含まれることが可能であるということが理解されるべきである。

Claims (15)

  1. マルチキャストベアラリソースを制御するための方法であって、
    サービスベースのポリシー決定機能(SPDF)によって、ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信し、
    前記SPDFによって、前記マルチキャストベアラリソースを制御する、
    ことを含
    前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセスリソース受付制御機能(A−RACF)にアクセス側のマルチキャストベアラリソースを申し込み、
    前記SPDFによって、コアリソース受付制御機能(C−RACF)にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
    方法。
  2. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側及びコアネットワークの申し込み結果に従って前記ベアラ層ネットワークエンティティにリソース申し込み結果応答を返すことを含む、
    請求項1の方法。
  3. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、マルチキャストベアラリソースを申し込む前に、マルチキャストサービス許可に従ってマルチキャストベアラリソースを申し込む要求に従ったサービス許可を行う、
    請求項1又は2の方法。
  4. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、前記ベアラ層ネットワークエンティティから、前記マルチキャストベアラリソースを変更する要求を受信し、
    前記SPDFによって、前記マルチキャストベアラリソースを変更するための受付許可およびリソース変更を実行し、
    前記SPDFによって、前記ベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む
    請求項1に記載の方法。
  5. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側及びコアネットワークの変更結果に従って前記ベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項4に記載の方法。
  6. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側のマルチキャストベアラリソースを変更することをA−RACFに要求し、
    前記SPDFによって、コアネットワークのマルチキャストベアラリソースを変更することをC−RACFに要求し、
    前記SPDFによって、アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項1、4又は5の方法。
  7. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、前記ベアラ層ネットワークエンティティから、前記マルチキャストベアラリソースを解放する要求を受信し、
    前記SPDFによって、対応するマルチキャストベアラリソースを解放し、
    前記SPDFによって、前記ベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項1に記載の方法。
  8. 前記SPDFによって、前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側のマルチキャストベアラリソースを解放することをA−RACFに要求し、
    前記SPDFによって、コアネットワークのマルチキャストベアラリソースを解放することをC−RACFに要求し、
    前記SPDFによって、アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項7の方法。
  9. リソース受付制御サブシステム(RACS)内に配置されたネットワークエンティティであって、
    ベアラ層ネットワークエンティティから、マルチキャストベアラリソースを制御する要求を受信するように適合された受信ユニットと、
    前記マルチキャストベアラリソースを制御するように適合された制御ユニットと、
    を具備
    前記ネットワークエンティティは、サービスベースのポリシー決定機能(SPDF)であり、
    前記マルチキャストベアラリソースを制御することは、
    アクセスリソース受付制御機能(A−RACF)にアクセス側のマルチキャストベアラリソースを申し込み、
    コアリソース受付制御機能(C−RACF)にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
    ネットワークエンティティ。
  10. 前記マルチキャストベアラリソースを制御する前記要求を発する前記ベアラ層ネットワークエンティティに、制御応答を返すように適合された応答ユニットをさらに具備する、請求項に記載のエンティティ。
  11. 前記マルチキャストベアラリソースを制御することは、
    アクセス側のマルチキャストベアラリソースを変更することをA−RACFに要求し、
    コアネットワークのマルチキャストベアラリソースを変更することをC−RACFに要求し、
    アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項9又は10のエンティティ。
  12. 前記マルチキャストベアラリソースを制御することは、
    アクセス側のマルチキャストベアラリソースを解放することをA−RACFに要求し、
    コアネットワークのマルチキャストベアラリソースを解放することをC−RACFに要求し、
    アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項9、10又は11のエンティティ。
  13. マルチキャストベアラリソースを制御するためのシステムであって、
    マルチキャストベアラリソースを制御する要求を発するように適合されたベアラ層ネットワークエンティティと、
    記ベアラ層ネットワークエンティティから前記マルチキャストベアラリソースを制御する要求を受信し、前記マルチキャストベアラリソースを制御するように適合されたサービスベースのポリシー決定機能(SPDF)と、
    を具備
    前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセスリソース受付制御機能(A−RACF)にアクセス側のマルチキャストベアラリソースを申し込み、
    前記SPDFによって、コアリソース受付制御機能(C−RACF)にコアネットワークのマルチキャストベアラリソースを申し込むことを含む、
    システム。
  14. 前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側のマルチキャストベアラリソースを変更することをA−RACFに要求し、
    前記SPDFによって、コアネットワークのマルチキャストベアラリソースを変更することをC−RACFに要求し、
    前記SPDFによって、アクセス側及びコアネットワークの変更結果に従ってベアラ層ネットワークエンティティにリソース変更結果応答を返すことを含む、
    請求項13のシステム。
  15. 前記マルチキャストベアラリソースを制御することは、
    前記SPDFによって、アクセス側のマルチキャストベアラリソースを解放することをA−RACFに要求し、
    前記SPDFによって、コアネットワークのマルチキャストベアラリソースを解放することをC−RACFに要求し、
    前記SPDFによって、アクセス側及びコアネットワークの解放結果に従ってベアラ層ネットワークエンティティに解放結果応答を返すことを含む、
    請求項13又は14のシステム。
JP2010500058A 2007-06-13 2008-05-07 マルチキャストベアラリソースを制御するための方法、装置、およびシステム Expired - Fee Related JP4787376B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200710111019.3 2007-06-13
CN2007101110193A CN101325500B (zh) 2007-06-13 2007-06-13 一种组播承载资源的控制方法及系统
PCT/CN2008/070904 WO2008151528A1 (fr) 2007-06-13 2008-05-07 Procédé, dispositif et système pour commander une ressource de multidiffusion

Publications (2)

Publication Number Publication Date
JP2010523026A JP2010523026A (ja) 2010-07-08
JP4787376B2 true JP4787376B2 (ja) 2011-10-05

Family

ID=40129237

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010500058A Expired - Fee Related JP4787376B2 (ja) 2007-06-13 2008-05-07 マルチキャストベアラリソースを制御するための方法、装置、およびシステム

Country Status (5)

Country Link
US (1) US8264998B2 (ja)
EP (1) EP2081323A4 (ja)
JP (1) JP4787376B2 (ja)
CN (1) CN101325500B (ja)
WO (1) WO2008151528A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010233174A (ja) * 2009-03-30 2010-10-14 Kddi Corp ルータ、ネットワークシステムおよび通信方法
CN101753453B (zh) * 2009-12-23 2013-02-27 中兴通讯股份有限公司 一种分组传送网环网的组网方法
CN102378115A (zh) * 2010-08-16 2012-03-14 杭州华三通信技术有限公司 组播接入控制方法、系统和装置
US9667485B2 (en) * 2011-10-04 2017-05-30 Juniper Networks, Inc. Methods and apparatus for a self-organized layer-2 enterprise network architecture
US9173073B2 (en) * 2011-12-19 2015-10-27 Motorola Solutions, Inc. Method and apparatus for processing group event notifications and providing group policy in a communication system
CN108377365B (zh) * 2018-02-08 2020-03-24 江苏恒信和安电子科技有限公司 基于视频安全接入路径的视频监控系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006087067A1 (en) * 2005-02-16 2006-08-24 Matsushita Electric Industrial Co. Ltd. Providing information on the individual bearers ' relationships to mobile terminals receiving a multicast or broadcast service

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE0400340D0 (sv) * 2004-02-11 2004-02-11 Ericsson Telefon Ab L M Method in a communication system
CN1272943C (zh) * 2004-03-24 2006-08-30 华为技术有限公司 一种组播业务的实现方法
CN100426815C (zh) * 2004-09-08 2008-10-15 华为技术有限公司 一种ngn中的资源和准入控制子系统及方法
CN100459518C (zh) * 2005-09-02 2009-02-04 华为技术有限公司 资源接纳控制处理方法
CN100450087C (zh) * 2005-09-02 2009-01-07 华为技术有限公司 实现一组特定流的QoS控制的方法
CN100461951C (zh) * 2005-11-11 2009-02-11 华为技术有限公司 一种组播切换方法和设备
CN101030921B (zh) * 2006-03-02 2012-05-23 华为技术有限公司 一种组播控制系统和方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006087067A1 (en) * 2005-02-16 2006-08-24 Matsushita Electric Industrial Co. Ltd. Providing information on the individual bearers ' relationships to mobile terminals receiving a multicast or broadcast service

Also Published As

Publication number Publication date
JP2010523026A (ja) 2010-07-08
CN101325500A (zh) 2008-12-17
WO2008151528A1 (fr) 2008-12-18
EP2081323A1 (en) 2009-07-22
US20090207841A1 (en) 2009-08-20
US8264998B2 (en) 2012-09-11
CN101325500B (zh) 2012-12-12
EP2081323A4 (en) 2009-10-28

Similar Documents

Publication Publication Date Title
CN101299825B (zh) 一种实现组播承载资源控制的方法、系统及装置
EP2124385B1 (en) Method, device and system for multicast service authorization controlling
CN101369907B (zh) 组播业务的实现方法及其装置和系统
US8930451B2 (en) Multicast/unicast admission control method, device and system
JP4787376B2 (ja) マルチキャストベアラリソースを制御するための方法、装置、およびシステム
US8072897B2 (en) Method, system and device for selecting edge connection link across different management domain networks
KR20120076444A (ko) EMBMS 채팅 서비스 제공 시스템 및 EMBMS 채팅 서비스 제공 시스템의 서비스 제공자 서버, eBM-SC 및 사용자 단말의 제어 방법
US20100304775A1 (en) Processing method for resource request in ngn
CN100450087C (zh) 实现一组特定流的QoS控制的方法
CN101313515A (zh) 媒体流控制方法、媒体流转换设备及组播系统
WO2009056013A1 (en) A policy control method and system for layer two device
KR101517380B1 (ko) 멀티캐스팅을 요청하고, 멀티캐스팅 요청들을 처리하고 이러한 처리를 보조하기 위한 방법 및 디바이스
WO2008046336A1 (fr) Système et procédé permettant un contrôle d'accès réparti dans un service multidiffusion
WO2009132492A1 (zh) 一种racs支持移动ip的系统及方法
WO2008017226A1 (fr) Système et procédé de commande de multidiffusion
WO2009111990A1 (zh) 一种组播控制的方法、设备和系统
WO2009100625A1 (zh) 资源接纳控制系统中的策略决策功能实体的选择方法
WO2009100623A1 (zh) 下一代网络组播业务接纳控制方法
WO2011032374A1 (zh) 批发场景下的拉模式资源接纳控制方法和系统
WO2008025267A1 (fr) Procédé, système, unité de commande d'admission et de ressource pour établir le service de multidiffusion
JP2011188030A (ja) マルチキャスト帯域を確保する中継ノード、通信システムおよびその方法
CN102098204A (zh) 一种管理组播资源的方法和系统
WO2009105942A1 (zh) 资源接纳控制子系统及发送资源决策请求消息的方法
WO2009105980A1 (zh) 一种多播广播业务的授权控制方法、系统及装置
WO2007098699A1 (fr) Procédé de commande de flux multimédia, dispositif de conversion de flux multimédia et système de multiffusion

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110322

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110603

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110705

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110714

R150 Certificate of patent or registration of utility model

Ref document number: 4787376

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140722

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees