JP4750858B2

JP4750858B2 - 顧客トリガ予約要求およびネットワークトリガ予約要求のためのリソース許可制御

Info

Publication number: JP4750858B2
Application number: JP2008546274A
Authority: JP
Inventors: フアン・エウエイク，アドリアヌス・ヨハンネス; デ・クノツデル，ステフアーン・ヨゼフ
Original assignee: アルカテル−ルーセント
Priority date: 2005-12-23
Filing date: 2006-12-20
Publication date: 2011-08-17
Anticipated expiration: 2026-12-20
Also published as: US8111695B2; EP1802046B1; EP1802046A1; US20070147292A1; PL1802046T3; CN1992628A; BRPI0620258A2; ATE433630T1; ES2327428T3; KR101255529B1; WO2007071431A1; DE602005014879D1; RU2008130378A; IL192318A; RU2407192C2; IL192318A0; JP2009521148A; KR20080083675A; CN100579019C

Description

本発明は一般に、典型的にはブロードキャストＩＰＴＶなどのマルチキャストサービスに関連する顧客トリガ予約要求および典型的にはＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩＰ）、ＶｏＤ（ＶｉｄｅｏｏｎＤｅｍａｎｄ）、ビデオ会議、ＩＭＳ（ＩＰマルチメディアサブシステム）対話型サービス等のユニキャストサービスに関連するネットワークトリガ予約要求の両方のためのアクセスネットワークおよびアグリゲーションネットワークにおける許可制御に関するものである。許可制御とは、サービスをセットアップするのに必要なネットワークリソースの予約要求を許可（容認）または拒絶する機能である。

アクセスネットワークおよびアグリゲーションネットワークにおけるクオリティオブサービス（ＱｏＳ）およびリソース許可制御（ＲＡＣ）の需要は、トリプルプレイサービス、すなわち、高速インターネット（ＨＳＩ）アクセス、ＶｏＩＰサービスまたは対話型ＩＰマルチメディアサービスなどの対話型ポイントツーポイントサービス、およびブロードキャストＴＶ（ＢＴＶ）のようなクライアントサーバベースのサービスの平行配置におけるネットワークオペレータの新たな関心に伴っていっそう高まっている。

マルチキャストアプリケーションまたはブロードキャストＴＶのようなブロードキャストアプリケーションは典型的には、アクセスネットワークにおけるリソースを予約するために端末または顧客構内設備（ＣＰＥ）によりトリガされる機構に依存する。エンドユーザのセットトップボックス（ＳＴＢ）、ＰＣまたはホームゲートウェイは、例えば、インターネットグループマルチキャストプロトコル（ＩＧＭＰ）を用いてＴＶチャンネルを選択するか、またはＴＶチャンネル間でザップし、これによりアクセスネットワークにおける必要なリソースの予約を要求してＴＶチャンネルを配信する。実際、異なるＴＶチャンネルは、例えば、品位（ｄｅｆｉｎｉｔｉｏｎ）（標準品位対高品位）あるいはチャンネルがネットワークのより深いノードから検索されるべき状況に対するアクセスノードにおけるチャンネルの利用可能性に応じて、アクセスおよびアグリゲーションネットワークにおいて異なるリソース要件またはクオリティオブサービス（ＱｏＳ）要件を有することがあることに留意されたい。アクセスノード、例えばＤＳＬアクセスネットワークの場合のデジタルサブスクライバラインアクセスマルチプレクサ（ＤＳＬＡＭ）は、ＣＰＥから受信されたＩＧＭＰメッセージを終結し、顧客構内に向かうＤＳＬライン上の利用可能なリソースのその認識およびファーストマイルにおけるブロードキャストＴＶのためのローカルに構成された帯域プロフィールに基づいてリソース許可制御を実行する。受容可能なユーザエクスペリエンスを達成するためにはチャンネル間のザッピングのための遅延はできるだけ小さくなければならないので、ブロードキャストＴＶのようなサービス用の許可制御は、ＣＰＥのできるだけ近くで、すなわち好ましくはアクセスノードにおいて行われなければならない。

一方、ＶｏＩＰ、ビデオ会議、および固定ＩＭＳなどの対話型サービスは典型的には、ネットワークトリガリソース予約機構を使用し、これによりアプリケーションプロキシがネットワークにおいてリソース予約を行う。例としては、そのプロキシコール状態制御機能（Ｐ−ＣＳＣＦ）からのリソース予約要求をアグリゲーションネットワーク内のどこかにある中央リソース許可制御サブシステムに発行する、ゲームサーバまたはＩＰマルチメディアサブシステム（ＩＭＳ）が挙げられる。これに加え、ＩＭＳＰ−ＣＳＣＦは、いわゆる、タイトル「ＮＧＮＦｕｎｃｔｉｏｎａｌＡｒｃｈｉｔｅｃｔｕｒｅ；ＲｅｓｏｕｒｃｅａｎｄＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌＳｕｂｓｙｓｔｅｍ（ＲＡＣＳ）；Ｒｅｌｅａｓｅ１」として２００５年１０月に発行された文献ＥＴＳＩ仕様ＥＳ２８２３００バージョン１．６．６に指定されたようなＧｑインタフェース、Ｇｑ’インタフェースまたはＥＴＳＩＴｉｓｐａｎインタフェースを装備する。中央リソース許可制御サブシステムは典型的には、セッションリソースブローカ、すなわちＳＲＢのような別個のデバイスに統合されるが、ＩＭＳに統合されてもよい。ＶｏＩＰおよびＶｏＤのようなユニキャストサービスのためのアプリケーションサーバ／プロキシはリソース予約要求をこの中央リソース許可制御機能へ送る。中央リソース許可制御機能はアグリゲーションネットワークにおいて（かつ最終的にはアクセスリンク上に）利用可能なリソースの論理的概要を有することになっている。これらの利用可能なリソースのその認識に基づいて、中央許可制御機能はアプリケーションサーバ／プロキシからの要求を許可または拒絶する。

ネットワークトリガ予約要求用の中央リソース許可制御に基づく既存の解決策に関する問題は、中央ＲＡＣ機能がＣＰＥ発信予約要求のためにアクセスノードによって動的に予約される帯域（またはリソース）の量がどれ程かわからないことにある。例えばブロードキャストＴＶ配置の場合、（ビデオプラットフォームがＢＴＶがアクティブであることを中央ＲＡＣ機能に示すと仮定すると）中央ＲＡＣ機能は加入者が自身のセットトップボックスをオンしてＢＴＶを受信する最初の時間のみを知る。この後、中央ＲＡＣ機能には顧客によるチャンネルザッピングに関する情報が知らされないが、そのようなチャンネル変更がアクセスネットワークおよびアグリゲーションネットワークにおけるリソースの利用可能性に影響を及ぼすことがある。ＢＴＶチャンネルは異なるリソース要件（例えば、標準品位対高品位ＢＴＶ）を有し得る。さらに、ＢＴＶチャンネルすべてがアクセスノードにおいて利用可能でないかもしれず、したがって、アグリゲーションネットワークにおけるより深いノードから検索される必要があるかもしれない。アクセスノードのアップリンクインタフェースは混雑するかもしれないかつ／またはアクセスノードから顧客構内へのダウンリンクが混雑するかもしれない。中央ＲＡＣ機能はこのチャンネルザッピングを知らないので、これらの混雑の問題は不十分なリソースが利用可能なネットワークトリガリソース予約要求を結果的に許可し得る中央ＲＡＣ機能には不可視のままになり得る。

同様に、マルチキャストアプリケーションに対する顧客構内発信リソース予約要求を終結するアクセスノードは、ユニキャストアプリケーションのために中央ＲＡＣ機能によって割り当てられる帯域の量を知らない。この結果として、マルチキャストサービス要求はアクセスノードによって承認されると考えられるが、アグリゲーションネットワークにおいては要求されたチャンネルまたはサービスを配信するための不十分な帯域がある。

現在、ネットワークトリガリソース予約要求および端末トリガリソース予約要求の両方のためのリソース許可制御を調整する適切な解決策は存在しない。

端末トリガリソース予約要求およびネットワークトリガリソース予約要求の両方のために許可制御を調整するための簡単なやり方は、ネットワークプランニングであろう。ネットワークプランニングは種々のネットワークリンク上の利用可能な帯域（またはリソース）が対話型サービス（ＩＭＳ、ＶｏＩＰ、ＶｏＤ）用の帯域（またはリソース）バジェット（ｂｕｄｇｅｔ）およびマルチキャストアプリケーション（ＢＴＶ）用の帯域（またはリソース）バジェットに分割されることを暗示する。しかし、ある種のサービス（例えば、ＢＴＶ）専用である帯域バジェットが他のサービスによって使用することができないので、このアプローチは非常に非効率的である。ネットワークプランニングの結果、アクセスおよびアグリゲーションネットワークにおける容量は、ＢＴＶ、ＶｏＤ、ＶｏＩＰおよびＩＭＳサービスなどのＱｏＳを要求するサービス間で厳格に分割される。例えば、ＤＳＬアクセスリンクについては、帯域バジェットがＶｏＩＰのために予約され（典型的には、いくつかの同時的ＶｏＩＰテレフォニ呼またはビデオテレフォニ呼を可能にするための大きさにされる）、別個の帯域バジェットがＢＴＶおよびＶｏＤなどのビデオサービスのために予約される（ビデオバジェットがＢＴＶとＶｏＤとの間で共有され得ると仮定される場合）。この結果、音声およびビデオトラフィックはその個々の計画された帯域バジェットを超えてはならない。このことはファーストマイルの容量の専用部分がＢＴＶ／ＶｏＤ専用であり、ＶｏＩＰまたはＩＭＳのような他のサービスのために使用することはできないことを意味する。ＢＴＶ／ＶｏＤおよびＩＭＳにアクセスすることのできるセットトップボックスについては、例えば６Ｍｂｐｓであるファーストマイルの最大帯域はＢＴＶ／ＶｏＤが利用可能な５Ｍｂｐｓに分割され得、その残りの部分（１Ｍｂｐｓ）はＩＭＳのようなサービスに利用可能となろう。他の分割も存在し得ることは明白であろう。このリソース分割は停止されよう。ビデオサービスと他のサービスとの間でそのようにリソースを分割するネットワークプランニングは、結果として、リソース使用が不十分になることは明白である。特にリソースを多量に使用する対話型サービス（ＩＭＳ、ポイントツーポイントビデオサービス等）が出現するとき、ネットワークプランニング法はもはや適切ではないであろう。実際、ＩＭＳが対話型マルチメディアサービス用の将来の主要なシステムになるためおよびＩＭＳがＶｏＩＰのみに限定されないため、ネットワークトリガ予約要求機構を使用するサービスのためのリソース要件は劇的に増大するであろう。

結果として、本発明の目的は、ＣＰＥトリガリソース予約要求をアクセスノードにおいて取り扱い、ネットワークトリガリソース予約要求を中央ＲＡＣデバイスにおいて取り扱い、および最終的にネットワークプランニングを用いてアクセスおよびアグリゲーションネットワークにおけるそのリソースバジェットを異なるタイプのサービス間で分割する上記欠点に対する解決策を提供することにある。

請求項１に記載の、ダウンリンクを介する顧客構内への直接的または間接的接続および１つまたは複数のアップリンクを介するアグリゲーションネットワークへの接続を有するネットワークノードを用いて先行技術の解決策の欠点が克服され、上記目的が達成される。ネットワークノードは顧客トリガリソース予約要求を受け取り、顧客トリガ予約要求を許可または拒絶するリソース許可制御機能を有する。ネットワークノードはアグリゲーションネットワークにおいて中央リソース許可制御機能からネットワークトリガ予約要求を受け取る手段をさらに有し、そのリソース許可制御機能は顧客構内へのダウンリンク上の少なくとも利用可能なリソースのその認識に基づいて、顧客トリガ予約要求の許可または拒絶をネットワークトリガ予約要求の許可または拒絶と調整するようになされている。

このように、調整された許可制御モデルが実現され、これによりアクセスネットワークにおけるネットワークノードが、ファーストマイルに関する限り、ＣＰＥトリガリソース予約要求およびネットワークトリガリソース予約要求の両方について許可制御を決定する。中央ＲＡＣ機能は依然としてネットワークトリガリソース予約要求についての全体的許可制御決定を担い得るが、その決定は、もはやアグリゲーションネットワークにおける利用可能なリソースのその認識のみに基づくだけでなく、本明細書の請求項１によるアクセスネットワークノードによって発行されるファーストマイル許可制御決定にも基づく。

本発明はさらに、請求項１３に記載の本発明による、ネットワークノードとインタフェースすることが可能な中央許可制御デバイスと、請求項１４に記載の本発明によるネットワークノードおよび中央許可制御デバイスを通して顧客トリガリソース予約要求およびネットワークトリガリソース予約要求を取り扱う方法とに関する。

本発明によるネットワークノードの任意の特徴は、顧客トリガ予約要求およびネットワークトリガ予約要求の許可または拒絶が、アップリンク上の利用可能なリソースの認識を追加で考慮し得ることである。この特徴は請求項２によって定められる。

このように、アクセスネットワークにおけるネットワークノードは、アグリゲーションネットワークへのアクセスノードのファーストマイルおよびアップリンクのための許可制御決定を担う。あるいは、中央ＲＡＣ機能がアクセスノードとアグリゲーションネットワークとの間のアップリンク上に可視性を有するとき、これらのアップリンク上の利用可能なリソースの認識が中央ＲＡＣ機能によって考慮され得る。

本発明によるネットワークノードの実施の特徴は、請求項３に記載の、アグリゲーションネットワークにおける中央許可制御機能との接続のための専用インタフェースを有し得ることである。

したがって、ネットワークトリガリソース許可制御要求および関連するＲＡＣ決定の交換を容易にするために、新しいインタフェースが中央ＲＡＣデバイス、例えばＳＲＢと、アクセスノード、例えばＤＳＬＡＭとの間に提案され得る。このインタフェースは最終的には、アクセスノードと中央ＲＡＣ機能との間で測定レポートの交換を可能にもし得る。あるいは、このインタフェースは例えばアグリゲーションノードのようにノードがネットワークのさらに深いところにあってもよい。

本発明の更なる任意選択の特徴は、請求項４に記載のように、顧客トリガリソース予約要求がマルチキャストサービスに関係し得ることおよびネットワークトリガ予約要求がユニキャストサービスに関係し得ることである。

実際、上に説明したように、マルチキャストサービスのためのリソース予約要求が顧客構内設備によって発行され易く、遅延またはレイテンシーのためにアクセスノードにおいて終結されなければならないかもしれないが、ユニキャストまたはポイントツーポイント対話型サービスのためのリソース予約要求はネットワークにおける要求者から発行し易い。しかし、本発明は、マルチキャストに関連する要求すべてがＣＰＥからのものであるがユニキャストに関連する要求すべてはネットワーク発信のものであるネットワークまたは配置のみに、限定されるものではない。

本発明によるネットワークノードの別の任意選択の特徴は、その許可制御機能が、請求項５に記載のように、顧客トリガ予約要求のために前記顧客構内に対して許可または拒絶を発行するように、かつ請求項６に記載のように、ネットワークトリガ予約要求のために中央許可制御機能に対してその専用インタフェースを介して許可または拒絶を発行するようになされ得ることである。

しかし、明示的な許可または拒絶に代わって、中央許可制御機能に対してリソース測定レポートまたは許可制御レポートを発行する本発明によるネットワークノードの変形実施態様を考えることもできる。許可制御レポートは例えば請求項７に記載されている。

請求項８から１２に示されるように、本発明によるネットワークノードは、例えば、デジタルサブスクライバラインアクセスマルチプレクサ（ＤＳＬＡＭ）、デジタルループキャリア（ＤＬＣ）、光ファイバアグリゲータ、ケーブルモデム終端システム（ＣＭＴＳ）、無線ネットワーク制御（ＲＮＣ）、ＷＩＭＡＸアクセスサービスネットワークゲートウェイ（ＡＳＮ−ＧＷ）、またはネットワークのアグリゲーション区間におけるアグリゲーティングノードさえも可能である。

図１は顧客構内にあるセットトップボックス１０１を示している。セットトップボックス１０１はＡＤＳＬモデム（図１には示さず）およびツイストペア銅線１０２を介してデジタルサブスクライバラインアクセスマルチプレクサ１０４に接続されている。このツイストペア銅線上にはＡＤＳＬまたはＶＤＳＬサービスが配置されている。ペア銅線１０２およびＤＳＬＡＭ１０４はアクセスネットワーク１０３の一部を形成する。ダウンリンク１０２から離れて、ＤＳＬＡＭ１０４はアグリゲーションネットワーク１０６と接続するためのアップリンク１０５を有する。アグリゲーションネットワーク１０６とコアネットワーク（図１には示さず）との境界にはＩＰエッジルーター１０７が設けられている。図１は専用インタフェースまたは論理接続部１０９を介してＤＳＬＡＭ１０４と論理的に相互接続された中央リソース許可制御デバイス１０８をさらに示す。中央リソース許可制御デバイス１０８はさらに、ＩＰマルチメディアサブシステム１１０と論理的にインタフェースを取る。

ＤＳＬＡＭ１０４および中央リソース許可制御デバイス１０８は本発明により動作する。このことはＤＳＬＡＭ１０４が、そのダウンリンク（例えば１０２）およびそのアップリンク（例えば１０５）についてユニキャストフローおよびマルチキャストフローのためのリソース許可制御機能を備えていることを意味する。中央リソース許可制御デバイス１０８はアグリゲーションネットワーク１０６におけるユニキャストフローのための許可制御を実行し、ＤＳＬＡＭ１０４とインタフェースする能力、アクセスネットワーク１０３およびアグリゲーションネットワーク１０６へのアップリンク１０５のためのユニキャストフローの許可／拒絶をＤＳＬＡＭ１０４に要求する能力、ならびにＤＳＬＡＭ１０４から受け取った情報をユニキャストフローのための全体的許可制御に考慮する能力をさらに有する。

ユニキャストおよびマルチキャストリソース許可制御について従う機構が、それぞれ破線矢印および点線矢印で図１に示されている。

ＩＰマルチメディアサブシステム１１０は、例えば、ＶｏＩＰ呼のためのリソース予約要求１２１をプロキシコール状態制御機能（Ｐ−ＣＳＣＦ）（図１には示さず）を通して発行する。このリソース予約要求１２１は中央リソース許可制御デバイス１０８によって受け取られ、解釈される。ＶｏＩＰ呼の許可または拒絶をアクセスネットワーク１０４およびアップリンク１０５に要求するために、ＣＲＡＣデバイス１０８はその専用インタフェース１０９を通してリソース予約要求１２２をＤＳＬＡＭ１０４に送る。リソース予約要求１２２はＩＭＳ１１０から受け取られたリソース予約要求１２１のコピーであってもよいし、アクセスネットワーク１０４およびアップリンク１０５におけるＶｏＩＰ呼のための必要な帯域の予約を基本的に要求する再フォーマットされた要求でもよい。ＤＳＬＡＭ１０４は本発明によるその専用インタフェースで要求１２２を受け取り、要求１２２をそのリソース許可制御機能において解釈する。このリソース許可制御機能は、ＤＳＬＡＭ１０４から顧客構内に向かって延在するダウンリンク上の利用可能なリソース（例えば、利用可能な帯域）およびアグリゲーションネットワーク１０５に向かうアップリンク上の利用可能なリソースの認識を有する。したがって、ＤＳＬＡＭ１０４におけるリソース許可制御機能は、マルチキャストサービス（要求がＳＴＢ１０１のような顧客構内設備から直接来る）およびユニキャストサービス（中央リソース許可制御デバイス１０８によって要求が送られる）両方によって、アクセスネットワークにおいて占められた全リソースおよびアップリンクに関してビューを有する。この認識に基づき、ＤＳＬＡＭ１０４におけるリソース許可制御機能はＶｏＩＰ呼を許可できるか、または拒絶すべきかを決定し、許可／拒絶レポート１２３を中央リソース許可制御デバイスＣＲＡＣ１０８に返送する。このレポート１２３はＶｏＩＰ呼の明示的な許可または拒絶を含むこともできるし、アクセスネットワークおよびアップリンク１０５において測定された利用可能なリソースに関する情報を含むことができ、ＣＲＡＣデバイスが許可または拒絶決定できるようになる。ＣＲＡＣデバイス１０８はこの情報を１２３に応答してアグリゲーションネットワーク１０６における利用可能なリソースのその認識と組み合わせて、最終的許可／拒絶応答１２４をＩＭＳ１１０に対して発行する。要約すると、すなわち、ＣＲＡＣデバイス１０８はアクセスリンクおよびアップリンクに関する許可制御決定をネットワークトリガ予約要求のためのＤＳＬＡＭ１０４に委託し、ネットワークトリガリソース予約要求者、すなわち図１のＩＭＳ１１０に対するその最終的決定１２４にＤＳＬＡＭ１０４の許可制御決定を含める。

マルチキャストフローに関し、例えば、ブロードキャストＴＶチャンネル、セットトップボックスはリソース予約要求１３１を例えばＩＧＭＰメッセージを通して発行する。この要求１３１はＤＳＬＡＭ１０４において終結される。このＤＳＬＡＭのリソース許可制御機能は、ダウンリンク１０２およびアップリンク１０５上に占められたリソースのその認識をマルチキャストサービスおよびユニキャストサービス両方によって組み合わせて、許可／拒絶決定を行う。ＤＳＬＡＭはその決定を応答１３２を介してセットトップボックス１０１に報告する。予約要求メッセージ１３１に用いられるプロトコルに応じて、明示的な応答があってもなくてもよいことに留意されたい（後者の状況では、明示的な要求のみがある）。例えば、ＩＧＭＰの場合、明示的な応答はないが、ビデオストリームは単にセットトップボックスの方にスタートする（ＳＴＢがそのストリームを受け取る）。ＲＳＶＰのような他のプロトコルに関し、明示的な応答がある。ＤＳＬＡＭ１０４はこのように、係るネットワーク開始要求を傍受する中央ＲＡＣデバイス１０８によってＤＳＬＡＭ１０４へ送られる（１３１のような）ＣＰＥ開始予約要求および（１２１のような）ネットワーク開始予約要求に関してリソース許可制御決定を行うＲＡＣ機能を有する。ＤＳＬＡＭ１０４は（１０２のような）ファーストマイルダウンリンクおよびアグリゲーションネットワークへの（１０５のような）アップリンクのためのマルチキャストフローおよびユニキャストフローについてリソース許可制御決定を行う。これに加えて、ＤＳＬＡＭ１０４はＱｏＳまたはリソース予約要求および決定をＣＲＡＣデバイス１０８と交換するための特別なインタフェース１０９を備える。

図１に示した解決策の主な利点は、ファーストマイルおよびアグリゲーションネットワーク上の許可制御がＣＰＥトリガ（典型的にはＢＴＶのための）リソース予約要求およびネットワークトリガ（典型的には対話型サービス）リソース予約要求の両方について調整され、その結果、マルチキャストサービスおよびユニキャストサービスのためのリソース使用がより効果的なものになる。

また、ＤＳＬＡＭ１０４においてアプリケーションシグナリングプロキシ（ＳＩＰ、ＲＴＳＰ等）を実施する必要がない。これらのアプリケーションプロキシは、ネットワークトリガリソース予約を必要とし、ＤＳＬＡＭ１０４にリソース許可制御を実行させるファーストマイル上で用いられるアプリケーションをＤＳＬＡＭに気付かせるべきである。

完全なアクセスネットワークに対してトランスペアレントなＱｏＳまたはリソース予約要求をセットトップボックスから受け取る場合、ＤＳＬＡＭ１０４付近に位置決めされたアプリケーションプロキシ（またはＤＳＬＡＭ１０４と統合されたアプリケーションプロキシでさえも）が最初に中央リソース許可制御デバイス１０８と接触することに代わって、新しいインタフェース１０９を直接使用し得ることにさらに留意されたい。

リソース許可制御はＣＰＥトリガ予約のための先行技術のＤＳＬＡＭ上で既に実施されているので、電気通信機器の当業者であれば、多大な努力をしなくてもＤＳＬＡＭにおいて既に利用可能であるリソース許可制御機能に依存するネットワークトリガ予約に用いることのできる新しいインタフェースを作ることが可能である。

本発明は図１に示した具体的な実施形態を参照して説明されているが、種々の変更および修正が本発明の精神および範囲内でなされてよいことは当業者には明白となろう。したがって、本明細書において開示され主張される基本的で根本的な原理の精神および範囲内に入るあらゆる修正例、変形例および同等例を包含することが想定される。例えば、本発明は図１に関連してなされた構造上または実施上の選択になんら限定されるものではない。セットトップボックスは例えばＳＩＰ電話、ＰＣ、端末、モデム、ホームゲートウェイ等のような他の任意の顧客構内設備と置換されてもよい。最終マイルループ１０２およびモデムのようなある種の顧客構内設備もそれに対して調整される限り、ＤＳＬＡＭ１０４は、例えばケーブルモデム終端システム（ＣＭＴＳ）、デジタルループキャリア（ＤＬＣ）、光ファイバアグリゲータ等のような他の任意のタイプのアクセスノードと置換されてよい。ＤＳＬＡＭ１０４に統合された本発明による機能性は、ネットワークのアグリゲーション区間１０６においてネットワークエンティティまたはノードの一部を形成することもできる。本発明によるＤＳＬＡＭ１０４に統合されたＲＡＣ機能は、ダウンリンクのみ、またはダウンリンクおよびアップリンク両方の利用可能なリソースを考慮することもできる。例えば、その機能がアグリゲーションノードに統合される場合、そういったアグリゲーションノードのアップリンクはいずれにせよ中央ＲＡＣ機能によって監視されるアグリゲーションネットワークの一部を形成するので、その機能はその許可／拒絶決定のためにダウンリンク上の利用可能なリソースのみを考慮すると考えられる。しかし、中央ＲＡＣがヌル機能であり、アグリゲーション部分自体に対してリソース許可制御決定を行わない場合、アグリゲーションノードのアップリンクがその機能によって考慮されることが排除されるものではない。図１のＩＭＳはＶｏＤサーバ、ゲームサーバ、またはユニキャストサービスのための予約要求を発行することのできる他のネットワークエンティティと置換することもできる。ＣＲＡＣデバイス１０８はＴＩＳＰＡＮアクセスリソース許可制御機能（ＡＲＡＣ−Ｆ）を実施するセッションリソースブローカ（ＳＲＢ）のようなスタンドアロン型エンティティであってもよいし、あるいは、例えばＩＭＳ１１０のＰ−ＣＳＣＦと統合され単一ユニットとされてもよい。

本発明によるネットワークノードを備えた実施形態および本発明による中央許可制御デバイスの実施形態を有するネットワークを示す略図である。

Claims

顧客トリガリソース予約要求（１３１）および前記顧客トリガリソース予約要求を許可または拒絶するリソース許可制御機能を受け取る手段を備える、少なくとも１つのダウンリンク（１０２）を介する顧客構内との直接的または間接的接続および少なくとも１つのアップリンク（１０５）を介するアグリゲーションネットワーク（１０６）との接続を有するネットワークノード（１０４）であって、前記ネットワークノード（１０４）が、ネットワークトリガ予約要求（１２２）を受け取る手段も備えること、および、さらに、前記リソース許可制御機能が、前記少なくとも１つのダウンリンク（１０２）上の少なくとも利用可能なリソースの認識に基づいて、前記顧客トリガリソース予約要求（１３１）の許可または拒絶を前記ネットワークトリガ予約要求（１２２）の許可または拒絶と調整するようになされることを特徴とする、ネットワークノード（１０４）。
前記リソース許可制御機能が、さらに、前記少なくとも１つのアップリンク（１０５）上の利用可能なリソースの認識に基づいて、前記顧客トリガリソース予約要求（１３１）の許可または拒絶を前記ネットワークトリガ予約要求（１２２）の許可または拒絶と調整するようになされることを特徴とする、請求項１に記載のネットワークノード（１０４）。
ネットワークトリガ予約要求（１２２）を受け取る前記手段が、前記アグリゲーションネットワーク（１０６）と論理的に相互接続された中央許可制御機能（１０８）との接続のための専用インタフェースであることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記顧客トリガリソース予約要求（１３１）がマルチキャストサービスに関連し、前記ネットワークトリガ予約要求（１２２）がユニキャストサービスに関連することを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記リソース許可制御機能が前記顧客トリガリソース予約要求（１３１）のために前記顧客構内に対して許可または拒絶（１３２）を発行するようになされることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記リソース許可制御機能が前記ネットワークトリガ予約要求（１２２）のために前記専用インタフェースを介して前記中央許可制御機能（１０８）に対して許可または拒絶（１２３）を発行するようになされることを特徴とする、請求項３に記載のネットワークノード（１０４）。
前記リソース許可制御機能が前記ネットワークトリガ予約要求（１２２）のために前記専用インタフェースを介して前記中央許可制御機能（１０８）に対して許可制御レポート（１２３）を発行するようになされることを特徴とする、請求項３に記載のネットワークノード（１０４）。
前記ネットワークノード（１０４）がデジタルサブスクライバラインアクセスマルチプレクサ（ＤＳＬＡＭ）であることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記ネットワークノードがデジタルループキャリア（ＤＬＣ）であることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記ネットワークノードが光ファイバアグリゲータであることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記ネットワークノードがケーブルモデム終端システム（ＣＭＴＳ）であることを特徴とする、請求項１に記載のネットワークノード（１０４）。
前記ネットワークノードがアグリゲーティングノードであることを特徴とする、請求項１に記載のネットワークノード（１０４）。
ネットワークトリガリソース予約要求（１２１）を受け取る手段と前記ネットワークトリガリソース予約要求を許可または拒絶するリソース許可制御機能とを備える、アグリゲーションネットワーク（１０６）に関連して用いられる中央許可制御デバイス（１０８）であって、前記中央許可制御デバイス（１０８）が、請求項１に記載のネットワークノード（１０４）に前記ネットワークトリガリソース予約要求（１２１）を送る手段と、前記ネットワークノード（１０４）から前記ネットワークトリガリソース予約要求についての許可制御レポート（１２３）を受け取る手段とを備えること、ならびにさらに、前記リソース許可制御機能が、前記許可制御レポート（１２３）および前記アグリゲーションネットワーク（１０６）における少なくとも利用可能なリソースの認識に基づいて、前記ネットワークトリガリソース予約要求（１２１）を許可または拒絶するようになされることを特徴とする、中央許可制御デバイス（１０８）。
顧客構内に向かうダウンリンク（１０２）上の少なくとも利用可能なリソースの認識に基づいてアクセスノード（１０４）において顧客トリガリソース予約要求（１３１）を許可または拒絶することと、アグリゲーションネットワーク（１０６）における利用可能なリソースの認識に基づき、前記アグリゲーションネットワーク（１０６）に接続された中央リソース許可制御デバイス（１０８）においてネットワークトリガリソース予約要求（１２１）を許可または拒絶することとを含む、前記顧客構内が少なくとも前記アクセスノード（１０４）を介して前記アグリゲーションネットワーク（１０６）に接続されるネットワークにおいて前記顧客トリガリソース予約要求（１３１）および前記ネットワークトリガリソース予約要求（１２１）を処理する方法であって、前記方法が、前記顧客構内に対するダウンリンク（１０２）上の少なくとも利用可能なリソースの認識に基づいて前記アクセスノード（１０４）による前記ネットワークトリガリソース予約要求（１２１）についての許可制御レポート（１２３）を発行すること、および前記中央リソース許可制御デバイス（１０８）において前記ネットワークトリガリソース予約要求（１２１）を許可または拒絶するときに前記許可制御レポート（１２３）を考慮することをさらに含むことを特徴とする、方法。