JP2012502571A - サービス品質をサポートする方法 - Google Patents

Abstract

事業者ネットワークとユーザ装置（ＵＥ）との間のデータフローに対するサービス品質（ＱｏＳ）をサポートする方法を提供する。ＵＥは、宅内ネットワーク（ＣＰＮ）に接続される。データフローは、事業者ネットワークおよびＣＰＮ内の通信路上でトランスポートされる。ＣＰＮは、ホームゲートウェイ（ＨＧＷ）を通じて事業者ネットワークに接続され、ＨＧＷは、ＣＰＮ内に配置され、ＣＰＮの内部構造は、事業者ネットワークには実質的に未知である。リソース・アドミッション制御サブシステム（ＲＡＣＳ）が、事業者ネットワーク内のＱｏＳを制御する。本方法は、ホームリソース・アドミッション制御機能（Ｈ−ＲＡＣＦ）がＨＧＷに設けられ、Ｈ−ＲＡＣＦはＣＰＮ内のＱｏＳを制御可能であり、シグナリングメッセージがデータフローに対するＱｏＳを設定するためにＨ−ＲＡＣＦとＲＡＣＳとの間で交換され、ＲＡＣＳが事業者ネットワーク内の通信路の第１の部分におけるＱｏＳを制御し、Ｈ−ＲＡＣＦがＣＰＮ内の通信路の第２の部分におけるＱｏＳを制御することを特徴とする。

Description

本発明は、事業者ネットワークとユーザ装置（ＵＥ）との間のデータフローに対するサービス品質（ＱｏＳ）をサポートする方法に関する。前記ＵＥは、宅内ネットワーク（ＣＰＮ, customer premises network）に接続される。前記データフローは、前記事業者ネットワークおよび前記ＣＰＮ内の通信路上でトランスポートされる。前記ＣＰＮは、ホームゲートウェイ（ＨＧＷ, home gateway）を通じて前記事業者ネットワークに接続される。前記ＨＧＷは、前記ＣＰＮ内に配置される。前記ＣＰＮの内部構造は、前記事業者ネットワークには実質的に未知である。リソース・アドミッション制御サブシステム（ＲＡＣＳ, resource and admission control subsystem）が、前記事業者ネットワーク内のＱｏＳを制御する。

近年、専用ネットワークにもともと制限されていたＩＰ（internet protocol）ベースのサービスを処理するために十分な帯域を提供するいくつかのネットワーク技術が開発されている。このようなサービスの例として、ビデオストリーミングや音声サービスがある。多様な情報やサービス、例えば音声、データ、およびすべての種類のメディア（例えばビデオ）に対してただ１つのネットワークを提供するというアイデアは、いわゆる次世代ネットワーク（ＮＧＮ, Next Generation Network）の基盤である。ＮＧＮは、コアネットワーク、アグリゲーションネットワーク、およびアクセスネットワークにおけるいくつかの主要なアーキテクチャ上の展開に対する大まかで、あまり明確に定義されていない用語である。一般的に、ＮＧＮとは、通信サービス等のサービスを提供可能であり、広帯域でサービス品質対応の複数のトランスポート技術を利用可能であり、サービス関連機能が下位のトランスポート関連技術とは独立した、パケットベースのネットワークである。ＮＧＮは一般に、コアネットワークとアクセスネットワークに分けられる。また、ＮＧＮはアグリゲーションネットワークを含んでもよい。

ＩＰ（Internet Protocol）を用いて次世代ネットワーク上で新しいサービスを提供するには、ネットワークにおけるアドミッション制御およびサービス品質（ＱｏＳ）施行を実行するための効果的でスケーラブルな方法が要求される。特に、キャリア級のサービス、すなわち、高い信頼性、利用可能性、および品質のサービスでは、特にＱｏＳに関して高度な要求が生じる。現在の設計では、アクセスネットワーク、アグリゲーションネットワーク、およびコアネットワーク内でのリソース制御が可能である。設計の一例が非特許文献１に記載されている。

一般的に、これらのアプローチは、データフローをトランスポートするＮＧＮが完全にＮＧＮ事業者の制御下にある限りにおいて、高い水準を提供する。残念ながら、ほとんどのユーザ装置（ＵＥ）、すなわちユーザの通信デバイス／端末は、事業者ネットワークに直接には接続されていない。たいていＵＥは宅内ネットワーク（ＣＰＮ）に接続され、ＣＰＮが事業者ネットワークへのアクセスを提供する。ＣＰＮは、ＬＡＮ（ローカルエリアネットワーク）、Ｗ−ＬＡＮ（無線ＬＡＮ）や他の有線または無線ネットワークを含むことが可能であり、ＵＥとリモートサーバやリモートＵＥとの間で事業者ネットワークを用いた接続を提供する。ＣＰＮは一般的に、ホームゲートウェイ（ＨＧＷ）を通じて事業者ネットワークに接続される。このような応用場面においては、リソースのボトルネックはＣＰＮ内にある場合がある。たとえ事業者ネットワークがＨＧＷに対してある一定のＱｏＳを提供することができても、ＵＥへの通信路全体では、要求されるＱｏＳが利用可能でないことがある。このため、真のエンドツーエンドのソリューションが妨げられる。

１つの可能なアプローチとして、ＣＰＮの内部構造を事業者ネットワークに明らかにすることが挙げられる。その場合、事業者ネットワーク内のＱｏＳ制御ユニットが、ＨＧＷとＵＥとの間の通信路上のＱｏＳも制御することが可能である。一般的に、リソース・アドミッション制御サブシステム（ＲＡＣＳ）が、事業者ネットワーク内のサービス品質を制御する。ＲＡＣＳは、ＣＰＮ内のＱｏＳを制御することも可能である。しかし、このアプローチは、セキュリティおよびユーザプライバシーが欠けている。というのは、ＣＰＮのインフラストラクチャおよび内部データフローに関する情報を明かさなければならないからである。この情報は攻撃者によって利用される可能性がある。

ネットワークアドレス変換（ＮＡＴ）が実行される場合には、追加的な問題が生じる。ユーザに利用可能なＩＰアドレス数の減少により、ＮＡＴは、ＣＰＮにおいて非常に多くの場合に使用される。一般的に、ユーザが利用可能なＩＰアドレスは１個または数個のみであるが、事業者ネットワークへの接続を必要とするＵＥはいくつもある。通常、ＮＡＴホールパンチングやＳＴＵＮ（Session Traversal Utilities for NAT）のようなＮＡＴ通過のための回避策が使用される。しかし、この回避策からは、さらなるセキュリティ問題が生じる。

他のソリューションとして、ＨＧＷ内のアプリケーション層ゲートウェイ（ＡＬＧ, application layer gateway）に基づくものがある。しかし、このようなアプローチもまた、この問題を解決しない。というのは、暗号化されたシグナリングフローを解釈することができないからである。また、非特許文献２に記載されているような現在利用可能なシステムは、ＡＬＧに依拠し、ＣＰＮ内のリソースを考慮していない。このような方法が対象としているのは、アクセスライン上で利用可能なリソースのみである。

Broadband ForumのＴＲ−６９ Ｓｕｉｔｅのような、他の従来のリモート管理アーキテクチャは、リアルタイムデバイス制御のためには設計されていない。ＴＲ−６９は、自動コンフィグレーション、動的サービスプロビジョニング、ソフトウェア／ファームウェアのイメージ管理、ステータス・パフォーマンスの監視・診断のために設計されている。ＨＧＷは、再起動、ファームウェア更新の完了、あるいはエラーの検出のような重大イベントが発生したときにのみ接続可能である。しかし、ＴＲ−６９は、フローが確立または削除されるべき場合や、リソース利用可能性をチェックしなければならない場合には使用可能でない。

ETSI ES 282 003 V2.0.0 "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture", ２００８年５月公表 "Home Gateway Technical Requirements: Residential Profile, Version 1.0", http://www.homegatewayinitiative.org, ２００８年４月２９日公開

したがって、本発明の目的は、頭書のようなサービス品質をサポートする方法において、事業者ネットワークおよびＣＰＮにわたるエンドツーエンドのソリューションに対してＱｏＳがサポートされるような改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、以下のことを特徴とする。すなわち、ホームリソース・アドミッション制御機能（Ｈ−ＲＡＣＦ, home resource and admission control function）が前記ＨＧＷに設けられる。前記Ｈ−ＲＡＣＦは前記ＣＰＮ内のＱｏＳを制御可能である。シグナリングメッセージが前記データフローに対するＱｏＳを設定するために前記Ｈ−ＲＡＣＦと前記ＲＡＣＳとの間で交換される。前記ＲＡＣＳが事業者ネットワーク内の前記通信路の第１の部分におけるＱｏＳを制御し、前記Ｈ−ＲＡＣＦがＣＰＮ内の前記通信路の第２の部分におけるＱｏＳを制御する。

本発明によって初めて認識されたこととして、ＣＰＮの内部インフラストラクチャを事業者ネットワークに明らかにすることなく、事業者ネットワークおよびＣＰＮにわたるエンドツーエンドのソリューションが可能となる。本発明によれば、ホームリソース・アドミッション制御機能（Ｈ−ＲＡＣＦ）がＨＧＷに設けられる。このＨ−ＲＡＣＦは、ＣＰＮ内のＱｏＳを制御可能である。事業者ネットワークおよびＣＰＮにわたるデータフローに対するＱｏＳを制御するため、ＲＡＣＳが事業者ネットワーク内のＱｏＳを制御し、Ｈ−ＲＡＣＦがＣＰＮ内のＱｏＳを制御する。ＲＡＣＳおよびＨ−ＲＡＣＦのいずれも、通信路のそれぞれの担当部分におけるＱｏＳを制御する。ＱｏＳ制御ステップを協調させるため、シグナリングメッセージがＨ−ＲＡＣＦとＲＡＣＳとの間で交換される。このようにして、データフローのための通信路全体で、協調的なＱｏＳ制御が可能となる。Ｈ−ＲＡＣＦを設けることで、ＲＡＣＳ（あるいは一般に事業者ネットワーク）は、ＣＰＮの内部インフラストラクチャについて知る必要がない。ＲＡＣＳは、事業者ネットワーク内の通信路の第１の部分に対するＱｏＳを制御し、ＣＰＮ内の通信路の第２の部分はＨ−ＲＡＣＦによって制御される。こうして、データフローの通信路全体に対するＱｏＳがサポート可能となり、事業者ネットワークおよびＣＰＮにわたる真のエンドツーエンドのソリューションが可能となる。

好ましくは、ＱｏＳ管理やその他のシグナリングメッセージに関するＨ−ＲＡＣＦとの通信は、制御チャネルを通じて送信される。この制御チャネルは、制御チャネルに基づく将来のアプリケーションをサポートするために、オープンな形で設計されてもよい。制御チャネルは、「通常の」データパケットとともにトランスポートされるある特定の制御データパケットを用いて実装されてもよい。制御データパケットは、一般的に用いられるパケットタイプでもよい。制御チャネル上の通信のため、ホームリソース制御プロトコル（ＨＲＣＰ, home resource control protocol）を用いてもよい。ＨＲＣＰは、制御チャネル上で交換されるリソース要求やその他のシグナリングメッセージの構造およびコンテンツを規定する。

特に好ましい実施形態によれば、制御チャネル上に送信されるメッセージはＳＩＰ（セッション確立プロトコル）メッセージである。一般的に用いられるＳＩＰインバイトの代わりにＳＩＰメッセージを用いることで、本方法は、３ＧＰＰ ＩＭＳ（IP Multimedia System）やＥＴＳＩ ＴＩＳＰＡＮのような他のアーキテクチャに準拠し、必要なシグナリングステップが少なくなる。

ＳＩＰメッセージのコンテンツは、異なるタイプでもよい。ＳＩＰメッセージ内にカプセル化される１つの可能なプロトコルとして、ＲＦＣ３５８８によるＤＩＡＭＥＴＥＲがある。しかし、好ましいコンテンツタイプはＸＭＬ（Extensible Mark-up Language）である。これは、かなり汎用の記述言語であり、容易に拡張可能である。また、ＸＭＬは、他のシグナリングメッセージ内で直接にトランスポート可能である。ＳＩＰメッセージは、コンテンツタイプ application/XML であってもよく、ＸＭＬを埋め込むために使用可能である。このように、ＨＲＣＰは、ＳＩＰおよびＸＭＬに基づいてもよい。

ＨＲＣＰの１つの好ましい実施形態については、図面を用いて詳細に説明する。この実施形態において、ＨＲＣＰはＸＭＬコード内にカプセル化される。ＸＭＬコードは、ＳＩＰメッセージ内にカプセル化され、ＳＩＰメッセージがＴＣＰ（Transport Control Protocol）／ＵＤＰ（Universal Datagram Protocol）／ＴＬＳ（Transport Layer Security）を用いてトランスポートされる。これらのパケットは、ＩＰ（Internet Protocol）を用いてトランスポートされる。この汎用アプローチにより、ＨＲＣＰおよび制御チャネルは一般に、ほとんどのＮＧＮシステムで実装可能である。

好ましくは、ＣＰＮ内のＱｏＳの制御は、リソース要求によって開始される。このリソース要求は、ＨＧＷにおけるＨ−ＲＡＣＦによって受信される。このリソース要求に応答して、Ｈ−ＲＡＣＦは、データフローに対するＣＰＮ内のＱｏＳを制御する。有利な態様として、リソース要求は、ＱｏＳを制御するために必要な情報を含む。これは、要求帯域幅、最大許容ジッタ、および最大許容遅延に関する情報を含んでもよい。リソース要求は、さらに、ＵＥのアドレスに関する情報を含んでもよい。これにより、ＱｏＳオペレーションの実行対象となるＵＥの識別が可能となる。このアドレスは、リソース要求を送信するネットワークエンティティのＩＰアドレスであっても、ＵＥのＩＰアドレスであってもよい。アドレスは、ＳＩＰ ＵＲＩ（Session Initiation Protocol Uniform Resource Identifier）であってもよい。リソース要求は、通信路上で使用すべきＱｏＳメカニズムに関する情報を含んでもよい。

ＣＰＮは、ローカルなアプリケーション層ゲートウェイ（ＡＬＧ）を含んでもよい。ＡＬＧは、ＨＧＷに統合されていてもよい。ＡＬＧは、セッション確立のために使用されるデータパケットを検出する。ＡＬＧは、セッション確立のためのシグナリングが暗号化されていない場合に適用可能である。

本発明の一実施形態によれば、リソース要求はこのＡＬＧによって生成される。ＡＬＧは、セッション確立を検出すると、Ｈ−ＲＡＣＦをトリガしてリソースの予約または割当をさせるためにリソース要求を生成する。リソース要求は、制御チャネルを通じて送信されてもよい。これは、ＡＬＧがＨＧＷとは異なるネットワークエンティティとして実装される場合に必要となる可能性がある。しかし、トリガメッセージは、通信のためのプロトコルを用いずに直接にＨ−ＲＡＣＦへ送信されてもよい。直接通信は、ＡＬＧがＨＧＷ内に統合されている場合に使用することが考えられる。

本発明の別の実施形態によれば、リソース要求はＲＡＣＳによって生成される。ＲＡＣＳは、新たなデータフローに対するリソースの予約または割当をするようにトリガされる場合がある。その場合、ＲＡＣＳは、事業者ネットワークのＱｏＳを制御する。同時に、または続いて、ＲＡＣＳは、対応するＨＧＷの位置を判定し、ＨＧＷ内のＨ−ＲＡＣＦへリソース要求を送信する。

ＲＡＣＳは、事業者ネットワークに設けられるアプリケーション機能（ＡＦ, application function）によってトリガされてもよい。ＡＦとＵＥは、例えば電話通話を開始すべき場合に、セッション確立のためのシグナリングを交換してもよい。その場合、アプリケーション機能は、ＲＡＣＳをトリガして、ＡＦとＵＥとの間のデータフローによって使用される通信路上のＱｏＳを制御させる。この場合のＱｏＳの制御は、リソースの割当またはリソースの予約を含む。

本発明の別の実施形態において、リソース要求は、別のネットワークノードによって生成されてもよい。このネットワークノードは、ＣＰＮ内または事業者ネットワーク内のいずれに配置されてもよい。リソース要求を生成するＣＰＮ内の１つの可能なネットワークノードとして、フェムトセルアクセスポイント（ＦＣＡＰ, Femto-Cell Access Point）が考えられる。ＵＥはＦＣＡＰに接続し、電話通話、ビデオストリーム等のためのセッション確立をトリガする場合がある。その場合、ＦＣＡＰは、Ｈ−ＲＡＣＦに接続し、Ｈ−ＲＡＣＦへリソース要求を送信する。リソース要求に応答して、Ｈ−ＲＡＣＦは、前記ＣＰＮ内のＱｏＳを制御する。この場合、その制御は、リソースの割当または予約を含んでもよい。Ｈ−ＲＡＣＦは、ＲＡＣＳをトリガして、事業者ネットワーク内のリソースの割当または予約を実行させるために、シグナリングメッセージを送信する。

ＣＰＮ内のＱｏＳの制御は、一般的に、リソースの利用可能性をチェックすることを含んでもよい。これは、ある一定のＱｏＳ制約を有するデータフローが確立されるかどうかをネットワークノードが知りたいときに、第１のステップとなり得る。これは、ＵＥで実行されるアプリケーションが、ある一定の解像度を有するビデオストリームを確立したい場合に適用可能な場合がある。このビデオストリームに対して要求されるＱｏＳが提供できない場合、より低い解像度を有する別のビデオストリームを選択してもよい。ＣＰＮのＱｏＳを制御する別のステップとして、リソースの割当が挙げられる。これは、リソース利用可能性チェック後の第２のステップとなり得る。ＱｏＳを制御するために実行される別のステップとして、割当または予約されたリソースを解放することが挙げられる。セッションが終了し、データフローのための通信路がもはや不要になったときには、データフローによって使用されたリソースを解放すべきである。

ＱｏＳを制御する際に、Ｈ−ＲＡＣＦは、通信路上の通信に関与するネットワークエンティティへＱｏＳシグナリングメッセージを送信してもよい。別法として、Ｈ−ＲＡＣＦは、ＱｏＳ制御エンティティとコンタクトし、ＱｏＳ制御エンティティが、必要なＱｏＳシグナリングメッセージを生成し、通信路上の通信に関与するネットワークエンティティへ送信してもよい。この場合、Ｈ−ＲＡＣＦは、必要なＱｏＳ制約を示す情報をＱｏＳ制御エンティティへ送信するだけである。

ＣＰＮ内のＱｏＳを制御するため、Ｈ−ＲＡＣＦは、ＣＰＮ内で利用可能なリソースに関する情報を有する必要がある。この情報は、ＨＧＷを事業者ネットワークにリンクするアクセスラインのリソースの利用可能性を参照する場合もある。この情報は、Ｈ−ＲＡＣＦがこのアクセスラインにおけるＱｏＳも制御する場合に必要となることがある。しかし、アクセスライン上のＱｏＳは、ＲＡＣＳによって制御されてもよい。

ＣＰＮ内および／またはアクセスライン上でのリソース利用可能性に関する情報を取得するため、Ｈ−ＲＡＣＦは、ＣＰＮ内のリソースを追跡してもよい。ＣＰＮ内のＱｏＳはＨ−ＲＡＣＦによって制御されるので、Ｈ−ＲＡＣＦは一般的に、ＣＰＮ内のＵＥと事業者ネットワークとの間の動作中のコネクションに関する情報を有する。しかし、Ｈ−ＲＡＣＦは、第三のネットワークエンティティに対して、リソース利用可能性に関する情報を問い合わせてもよい。このネットワークエンティティは、動作中のコネクションおよびそのそれぞれの制約に関する情報を保存するＣＰＮ内のサーバであってもよい。第３のネットワークエンティティは、自己のポートのネットワーク負荷を追跡するＣＰＮ内のルータであってもよい。リソース利用可能性に関する情報を保存するようなその他のネットワークエンティティに問い合わせてもよい。

リソース要求を受信した後、Ｈ−ＲＡＣＦは、ＵＥへの通信路のためにＣＰＮ内で利用可能なリソースを計算する。さらに、アクセスライン上で利用可能なリソースを計算してもよい。その後、Ｈ−ＲＡＣＦは、リソースの割当または予約を行い、新たなデータフローに対するポリシーを確立する。このポリシーは、ホームリソース制御・施行機能（Ｈ−ＲＣＥＦ, home resource control and enforcement function）に課されてもよい。Ｈ−ＲＣＥＦは、Ｈ−ＲＡＣＦによって確立された各ＱｏＳポリシーを保存し施行する。リソース要求がリソースの解放をトリガしている場合、Ｈ−ＲＡＣＦは、対応するＱｏＳポリシーを削除するためにＨ−ＲＣＥＦに接続してもよい。

好ましくは、Ｈ−ＲＡＣＦは、受信したリソース要求の送信元のネットワークエンティティへ応答を送信する。この応答は、ＱｏＳオペレーションの完了後に生成してもよい。ＱｏＳオペレーションとしては、リソース利用可能性チェック、リソースの割当または予約、およびリソースの解放が挙げられる。応答は、問合せ元エンティティをトリガして、さらなるステップを実行させてもよい。例えば、ＲＡＣＳがＡＦに代わってリソース要求を送信する場合、Ｈ−ＲＡＣＦからの応答は、ＲＡＣＳをトリガして、要求されたデータフローに対してリソースが予約されたという応答をＡＦへ送信させてもよい。その場合、ＡＦは、ＵＥへの通信路上でデータの送信を開始することができる。

有利な態様として、本方法は、緊急警報システムにおいて使用可能である。このような緊急警報システムの１つの実施例を以下に説明する。緊急警報システムは、ある特定のエリアにおいて送信されるべき緊急警報を追跡する緊急警報サーバを備える。この緊急警報サーバは、ある特定のエリア内で、すべての接続された家庭へ緊急警報を送信すべきことを発見した場合、アプリケーションサーバをトリガする。すると、アプリケーションサーバは、適当なネットワークアタッチメントサブシステム（ＮＡＳＳ, network attachment subsystem）データベースにおける検索を実行することにより、そのエリア内のＨＧＷのすべてのＳＩＰ ＵＲＩを調べる。ＮＡＳＳデータベースから取得した情報により、アプリケーションサーバは、そのエリア内の各ＨＧＷのＨ−ＲＡＣＦに接続するために、制御チャネルを使用する。アプリケーションサーバは、緊急サービスを優先したマルチメディアセッションを確立することを要求するＨＲＣＰメッセージを各ＨＧＷへ送信する。ＨＧＷは、このメッセージを受信すると、メディアコンテンツをレンダリングすることが可能な付属ローカルデバイスの検索を実行する。そして、それらのデバイスに対して、最高の優先度を用いてアプリケーションサーバとのメディアセッションを確立するよう強制する。このために、アプリケーションサーバによって生成されたトークンを受信してもよい。セッション確立の全体は、Ｈ−ＲＡＣＦのための拡張を含むＲＡＣＳに対する既存の手順を使用してもよい。必要であれば、他のメディアセッションを終了してもよい。

制御チャネルは、ＮＡＴバインディングを要求することによって、ネットワークアドレス変換（ＮＡＴ）通過制御を実行するために使用されてもよい。制御チャネルは、対称ＮＡＴの場合であっても使用可能であるため、事業者は、ＮＡＴホールパンチングやＳＴＵＮのようなＮＡＴ通過のために一般的に使用される回避策を配備せずにすむ。

また、制御チャネルは、他のリアルタイム制御手順のために使用してもよい。このような手順は、ＱｏＳやＮＡＴ制御以外でもよい。

なお、本明細書で用いているＲＡＣＳ、ＡＬＧ、あるいはＨＧＷ等の用語は、ＴＩＳＰＡＮの場合に一般的に用いられる用語ではあるが、ＴＩＳＰＡＮの使用に本発明を限定するものでないことはもちろんである。同様の機能を提供する他の技術もまた、本発明とともに使用可能である。また、各エンティティの用語は、そのエンティティを特定の実装に限定するものではない。例えば、ＨＧＷは、同様のゲートウェイを用いて実装されてもよい。さらに、ゲートウェイ機能が統合されたフェムトセルアクセスポイントを含んでもよい。

本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

本発明による方法が使用可能な例示的場面のブロック図である。 ＩＰにおけるＨＲＣＰのカプセル化を示す模式図である。 本発明による方法のステップのシーケンス図である。

図１は、２つのネットワークセクション、すなわち事業者ネットワークと宅内ネットワーク（ＣＰＮ）に分けられたＮＧＮを示している。事業者ネットワークは事業者の制御下にある。このネットワークは、デジタル加入者回線（ＤＳＬ）等であってもよい。ＣＰＮは、事業者の顧客の制御下にあり、顧客は事業者を広域ネットワークとして利用する。顧客は、個人でも企業でもよい。ＣＰＮは、事業者ネットワークにとっては単に「ブラックボックス」にすぎない。すなわち、ＣＰＮの内部構造は、事業者ネットワークには未知である。事業者ネットワークとＣＰＮはＨＧＷによって相互に接続される。ＨＧＷは、ＣＰＮから事業者ネットワークへのゲートウェイを提供する。すなわち、ＣＰＮおよび事業者ネットワークにわたる各データフローは、ＨＧＷを通じてルーティングされる。

ＲＡＣＳが、事業者ネットワーク内のＱｏＳを制御する。ＣＰＮ内のＵＥにサービスを提供するアプリケーション機能（ＡＦ）が、事業者ネットワークに設けられる。ＵＥは、コンピュータ、携帯電話、ノート型コンピュータ、ＴＶ装置、ステレオ装置等とすることが可能である。ＵＥからＣＰＮへのアクセスリンクは、有線（例えばイーサーネット）でも無線（例えばＷ−ＬＡＮ、ＷｉＭＡＸ（World Wide Interoperability for Microwave Access）あるいはＵＭＴＳ（Universal Mobile Telecommunication System））でもよい。事業者ネットワークは、ＨＧＷにおけるＨ−ＢＴＦ（Home Basic Transport Function, ホーム基本トランスポート機能）への物理リンクを提供するトランスポートストラタムを含む。Ｈ−ＢＴＦのほかに、ＨＧＷは、Ｈ−ＢＴＦにリンクされたＨ−ＲＣＥＦを有する。Ｈ−ＲＣＥＦは、Ｈ−ＲＡＣＦによってＨ−ＲＣＥＦに課されたＱｏＳポリシーを保存し施行する。Ｈ−ＲＡＣＦは、Ｈ−ＲＣＥＦにリンクされ、ローカルなＡＬＧへのインタフェースをさらに有する。ＡＬＧは、内部の暗号化されていないシグナリングメッセージを追跡する。図１は、ＵＥとＡＦとの間で暗号化されていないシグナリングフローの一例を示している。このシグナリングはＡＬＧによって追跡される。さらに、暗号化されたシグナリングフローが図１に示されている。暗号化のため、ＡＬＧはこのシグナルフローに対して透過的であり、ＡＬＧは対応するＱｏＳ要求を検出することができない。シグナリングメッセージは、ＵＥとＡＦとの間で直接に交換される。

ＡＦは、参照点Ｇｑ′でＲＡＣＳに接続する。Ｈ−ＲＡＣＦは、新しい参照点でＲＡＣＳに接続する。

ＣＰＮと事業者ネットワークとの間に確立する必要のあるデータフローとして、次の２つの相異なる場合が図１に示されている。
Ａ）ＵＥとネットワークベースのＡＦとの間で交換されるシグナリングによって確立されるフロー
Ｂ）ＣＰＮ内から開始されるフロー

場合Ａ）において、ＡＦは、ＵＥとＡＦとの間のセッション確立中に、メディアチャネルに対してリソース予約が要求されていることを判断する。その場合、ＲＡＣＳをトリガして、リソースを予約させる。この手順は、上記の非特許文献１に記載されている。ＲＡＣＳは、ＡＦのトリガに応答して、対応するＨＧＷの位置を判定し、リソースを予約するためのリソース要求をＨＧＷ内のＨ−ＲＡＣＦへ送信する。リソース要求を受信した後、Ｈ−ＲＡＣＦは、ＵＥへの通信路のためにアクセスライン上およびＣＰＮ内で利用可能なリソースを計算する。Ｈ−ＲＡＣＦは、リソースを予約し、ポリシーをＨ−ＲＣＥＦに課する。そして、「承諾（accept）」メッセージによってＲＡＣＳに応答する。別法として、応答およびポリシー賦課のステップで、ポリシーを変更してもよい。すなわち、Ｈ−ＲＡＣＦはまずリソースを予約し、「承諾」メッセージによってＲＡＣＳに応答してから、ポリシーをＨ−ＲＣＥＦに課する前に、ＲＡＣＳからの確認メッセージを待機する。Ｈ−ＲＡＣＦからポリシーを受信した後、Ｈ−ＲＣＥＦは、ＣＰＮ内のアタッチされたノードにポリシーを課する。使用事例として、例えばＩＭＳ−ＡＫＡ（IP Multimedia System Authentication and Key Agreement）を使用する際の、暗号化ＳＩＰシグナリングを用いた音声通話の確立がある。

場合Ｂ）において、ＨＧＷの内部ＡＬＧは、セッション確立を検出し、リソースを予約するようＨ−ＲＡＣＦに要求する。要求は、リソース要求として送信される。ＡＬＧは、ＨＧＷの内部に実装される。したがって、ＡＬＧとＨ−ＲＡＣＦとの間のプロトコル仕様は不要である。使用事例として、事業者ネットワーク内のアプリケーションによって提供されないゲームトラフィックの、ユーザ設定による優先順位付けがある。

ＡＬＧを使用するもう１つの可能性として、ＡＬＧが、ＲＡＣＳに含まれるＳＰＤＦ（Service-based Policy Decision Function, サービスベースポリシー決定機能）と相互接続する場合がある。このようにして、ＡＬＧはＲＡＣＳをトリガして、通信路上のＱｏＳを制御させてもよい。その場合、制御フローは、ＲＡＣＳのトリガがＡＦによって実行されるのではなくＣＰＮの内部ＡＬＧによって実行されることを除いては、場合Ａ）の制御フローと同様となる。ＡＬＧは、ＡＦによるサービスに基づかないセッションに対して事業者ネットワーク内のリソースを要求するために、ＡＦと相互接続してもよい。その場合、ＡＬＧはＡＦをトリガして、場合Ａ）のステップを実行させる。ＡＬＧのこのような相互接続はＨ−ＲＡＣＦを通るのが好ましい。それにより、Ｈ−ＲＡＣＦは、ＡＬＧによってトリガされたリソース要求であれ、ＲＡＣＳによってトリガされたリソース要求であれ、すべてのリソース要求を知ることができる。

なお、指摘しておかなければならないが、場合Ａ）および場合Ｂ）は、互いに別個に実装することも、組み合わせることも可能である。場合Ａ）のみを適用する場合、ＡＬＧは、図１のシステムにおいて省略してもよい。

図２は、本発明の好ましい一実施形態において使用可能なホームリソース制御プロトコル（ＨＲＣＰ）のために使用される種々のプロトコルのカプセル化を例示する図である。ＨＲＣＰは、ＸＭＬコード内にカプセル化される。ＸＭＬコードは、ＳＩＰメッセージを用いてトランスポートされ、ＳＩＰメッセージは、ＴＣＰ／ＵＤＰ／ＴＬＳおよびＩＰによってトランスポートされる。ＨＲＣＰは、制御チャネルを形成するために使用される。シグナリングメッセージあるいはリソース要求は、ＨＲＣＰを用いてこの制御チャネル上で送信されてもよい。ＸＭＬベースのＨＲＣＰプロトコルに埋め込まれたリソース要求コマンドの一例を以下に示す。

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<hgw_rac_protocol>
<header>
<version>0.0</version>
<command>RR</command>
<type>0</type>
<ipV>IP4</ipV>
<resId>p-cscf-a.nw.neclab.eu;1333D;123</resId>
<authorizationLifetime>450</authorizationLifetime>
<authGracePeriod>0</authGracePeriod>
<numObjects>1</numObjects>
</header>
<body>
<mediaObjects>
<priority>0</priority>
<rsBW>80000</rsBW>
<rrBW>80000</rrBW>
<numberFlows>1</numberFlows>
<flowInformationU>
<flowNumber>1</flowNumber>
<flowStatus>2</flowStatus>
<mediaType>1</mediaType>
<serviceClass>1</serviceClass>
<direction>recv</direction>
<protocolNumber>17</protocolNumber>
<ipLocal>192.168.0.2</ipLocal>
<portLocal>23942</portLocal>
<ipEndpoint>80.80.80.80</ipEndpoint>
<portEndpoint>50000</portEndpoint>
<ipGlobal>60.234.45.8</ipGlobal>
<portGlobal>32168</portGlobal>
<profileId>1</profileId>
<numberParameter>1</numberParameter>
<parameter>2000000</parameter>
</flowInformationU>
</mediaObjects>
</body>
</hgw_rac_protocol>

図３は、本発明による方法のステップのシーケンス図を示している。このシーケンス図は、図１の例示的状況に対応する。図３は、ＳＩＰを用いてマルチメディアセッションを確立するためのリソース予約のステップを示している。ＡＦによってサポートされる他のシグナリングプロトコルにも適用可能である。図３は、ＲＡＣＳが、明示的なコミットメッセージのない予約手順を使用する場合を反映している。本発明は、２段階法（予約およびコミットのフローが別個）とともに使用してもよい。

以下のステップが、図３に示すように実行される。
（１）ＵＥが、マルチメディアセッションを確立する要求をＡＦへ送信する（この場合はＳＩＰ ＩＮＶＩＴＥメッセージ）。
（２）ＡＦが、リソース要求をＲＡＣＳ（すなわちＳＰＤＦ）へ送信する。ＡＦは、要求に、ＵＥのローカルＩＰアドレスおよびポートを追加する。
（３）ＲＡＣＳが、非特許文献１に記載されているようにリソース予約手順を実行する。
（４）ＳＰＤＦが、ＵＥとの間にあるＨＧＷを位置決定する。このために、ＡＦから知ったＩＰアドレスをＳＩＰ ＵＲＩと対応づける。ＳＩＰ ＵＲＩは、ネットワークアタッチメントサブシステム（ＮＡＳＳ）および現在のＳＩＰ登録データベースから取得される。
（５）その後、ＳＰＤＦは、ＨＲＣＰを用いてＨＧＷへリソース要求を送信する。このため、ＳＰＤＦは、ＳＩＰ ＵＥを実装する必要があり、自己の一意的ＳＩＰ ＵＲＩでＩＭＳに登録しておく必要がある。別の選択肢としては、事業者ネットワーク内のＡ−ＲＡＣＦ（Access Resource and Admission Control Function, アクセスリソース・アドミッション制御機能）のインスタンスにおいてＳＩＰ ＵＥを実装する。
（６）ＨＧＷが、サービスを要求したＵＥへの通信路上における、アクセスライン上およびＣＰＮ内のリソースのローカルチェックを実行する。ＨＧＷは、リソース予約のための別のプロトコルを用いて、ホームネットワーク内の他のネットワーク要素とコンタクトしてもよい。
（７）Ｈ−ＲＡＣＦが、Ｈ−ＲＣＥＦに対して、ポリシーを施行するよう要求する。
（８）Ｈ−ＲＣＥＦが、確認メッセージによってＨ−ＲＡＣＦに応答する。
（９）Ｈ−ＲＡＣＦが、確認メッセージによってＲＡＣＳに応答する。
（１０）ＳＰＤＦが、ＢＧＦ（Border Gateway Function, ボーダーゲートウェイ機能）を制御する。
（１１）ＳＰＤＦが、確認メッセージによってＡＦに応答する。

ステップ（５）は、ＳＰＤＦが、ＨＧＷのローカルＩＰアドレスおよびポートならびにＳＩＲ ＵＲＩを含むカスケード化Ａ−ＲＡＣＦインスタンスへ要求を送信することを含んでもよい。この場合、Ａ−ＲＡＣＦは、ＨＧＷとの間でメッセージを交換するＳＩＰクライアントを含む。

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

Claims (16)

1. 事業者ネットワークとユーザ装置（ＵＥ）との間のデータフローに対するサービス品質（ＱｏＳ）をサポートする方法において、前記ＵＥは、宅内ネットワーク（ＣＰＮ）に接続され、
   前記データフローは、前記事業者ネットワークおよび前記ＣＰＮ内の通信路上でトランスポートされ、
   前記ＣＰＮは、ホームゲートウェイ（ＨＧＷ）を通じて前記事業者ネットワークに接続され、前記ＨＧＷは、前記ＣＰＮ内に配置され、前記ＣＰＮの内部構造は、前記事業者ネットワークには実質的に未知であり、
   リソース・アドミッション制御サブシステム（ＲＡＣＳ）が、前記事業者ネットワーク内のＱｏＳを制御し、
   該方法は、
   ホームリソース・アドミッション制御機能（Ｈ−ＲＡＣＦ）が前記ＨＧＷに設けられ、前記Ｈ−ＲＡＣＦは前記ＣＰＮ内のＱｏＳを制御可能であり、
   シグナリングメッセージが前記データフローに対するＱｏＳを設定するために前記Ｈ−ＲＡＣＦと前記ＲＡＣＳとの間で交換され、
   前記ＲＡＣＳが事業者ネットワーク内の前記通信路の第１の部分におけるＱｏＳを制御し、前記Ｈ−ＲＡＣＦがＣＰＮ内の前記通信路の第２の部分におけるＱｏＳを制御することを特徴とする、サービス品質をサポートする方法。
2. シグナリングメッセージが制御チャネル上で前記Ｈ−ＲＡＣＦへ送信され、前記制御チャネル上の通信が、好ましくはホームリソース制御プロトコル（ＨＲＣＰ）を用いて実行されることを特徴とする請求項１に記載の方法。
3. 前記制御チャネル上のシグナリングがＳＩＰ（セッション確立プロトコル）メッセージに基づくことを特徴とする請求項２に記載の方法。
4. 前記ＨＲＣＰがＸＭＬ（Extensible Markup Language）に基づくことを特徴とする請求項２または３に記載の方法。
5. 前記Ｈ−ＲＡＣＦがリソース要求を受信し、該リソース要求に応答して、前記Ｈ−ＲＡＣＦが、前記データフローに対する前記ＣＰＮ内のＱｏＳを制御し、前記リソース要求が、好ましくは前記制御チャネル上で送信されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. アプリケーション層ゲートウェイ（ＡＬＧ）が前記ＨＧＷに設けられ、前記ＡＬＧが、セッション確立シグナリングの存在を追跡し、前記セッション確立シグナリングが検出されたときに、前記ＡＬＧが、好ましくはリソース要求を生成することを特徴とする請求項１ないし５のいずれか１項に記載の方法。
7. 前記ＲＡＣＳがリソース要求を生成することを特徴とする請求項１ないし６のいずれか１項に記載の方法。
8. アプリケーション機能（ＡＦ）が前記事業者ネットワークに設けられ、前記ＡＦが、前記ＲＡＣＳをトリガしてＱｏＳオペレーションを実行させることを特徴とする請求項１ないし７のいずれか１項に記載の方法。
9. 別のネットワークノードがリソース要求を生成し、該ネットワークノードが、前記事業者ネットワーク内または前記ＣＰＮ内に配置されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
10. ＱｏＳを制御するために、前記Ｈ−ＲＡＣＦが、リソース利用可能性をチェックし、および／または、リソースの割当または予約を実行し、および／または、割当／予約されたリソースを解放することを特徴とする請求項１ないし９のいずれか１項に記載の方法。
11. 前記Ｈ−ＲＡＣＦが、前記ＣＰＮ内のリソースを追跡し、または、前記ＣＰＮ内の第３のネットワークエンティティに対してリソース利用可能性を問い合わせることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
12. 前記Ｈ−ＲＡＣＦが、ホームリソース制御・施行機能（Ｈ−ＲＣＥＦ）にＱｏＳポリシーを課し、該Ｈ−ＲＣＥＦが、前記ＣＰＮに対するＱｏＳポリシーを保存し施行することを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
13. 前記Ｈ−ＲＡＣＦが、受信した前記リソース要求の送信元のネットワークエンティティへ応答を送信し、該応答が、前記リソース要求によって要求されたＱｏＳオペレーションの完了後に送信されることを特徴とする請求項５ないし１２のいずれか１項に記載の方法。
14. 前記制御チャネルが、前記ＣＰＮ内の１つまたは複数のＵＥへ緊急警報を送信するために緊急警報システムで使用されることを特徴とする請求項２ないし１５のいずれか１項に記載の方法。
15. 前記制御チャネルが、ＮＡＴバインディングを要求することによって、ＮＡＴ（ネットワークアドレス変換）通過制御を実行するために使用されることを特徴とする請求項２ないし１４のいずれか１項に記載の方法。
16. 前記制御チャネルが、リアルタイム制御手順のために使用されることを特徴とする請求項２ないし１５のいずれか１項に記載の方法。

Images