JP2009105949A - ＱｏＳ制御を実行することが可能な端末 - Google Patents

Abstract

【課題】サービスを受ける終端の端末でＱｏＳを取り扱えるようにする。
【解決手段】本発明では、終端の端末２１がＱｏＳに関連する機能を取り扱い、終端点間のＱｏＳを達成する端末ベースのＱｏＳ管理スキームが行われる。端末でＱｏＳの管理を行うため、端末は、ネットワーク条件や他のエンティティの状態などを把握して、どのような操作を行うべきかを知る必要がある。例えば、端末は、パケットの監視や利用情報の収集を行い、収集されたデータをセントラルサーバ（ＳＬＡマネージャ２８）に報告する。セントラルサーバは、その管理ドメイン内のすべての端末からこれらの情報を収集する。また、セントラルサーバは、個々の端末ごとに設定されているサービスレベルなどの情報を参照して、各端末に行わせる操作を決定し、決定した動作を端末に行わせる。
【選択図】図２

Description

本発明は、ＱｏＳ制御を実行することが可能な端末に関し、特に、無線技術を利用したモバイルネットワークにおいてＱｏＳ制御を実行することが可能な端末に関する。また、本発明は、終端点間のＱｏＳを保証するために、異種のネットワーク環境においても、適用可能である。

ＩＰネットワークは、元来、ベストエフォート型トラフィックを運ぶように設計された。ベストエフォート型サービスでは、パケットの伝送は保証されていない。リアルタイムのマルチメディアアプリケーションなどのように遅延に敏感なアプリケーションにとって、データは、利用可能となるように限定された特定の遅延内に到着する必要がある。したがって、これらのアプリケーションは、これらのデータが利用可能となるよう、ネットワークから時間通りに適切に到着するための、あるレベルのサービス保証を必要とする。しかしながら、ベストエフォート型サービスは、これらのアプリケーションの必要条件を満たすには十分でない。

したがって、サービス品質（ＱｏＳ：Quality of Service）のサポートは、サービスを受けるユーザに対してあるレベルのサービス保証を提供するために、システム内で必須の要素となっている。システムにＱｏＳを提供する非常によく使用されている２つの方法として、統合サービス（Integrated Service：IntServ）（下記の非特許文献１）及び分化サービス（Differentiated Service：DiffServ）（下記の非特許文献２）、又はそれらの変異が使用されている。

IntServフレームワークは、個々のアプリケーションセッション（フロー）に特化したＱｏＳ保証を提供するために、ＩＥＴＦ（Internet Engineering Task Force）で発展した。それは、終端点間のＱｏＳを確実に満足させるのに十分なリソースを予約することができる個々のセッションを必要としている。また、IntServは、個々のフローに基づいて動作する。IntServでの各フローのリソース予約は、ルータがリソース予約を処理してルータを通る各フローのフロー状態を保持する必要性を含んでいる。これによって、大量のオーバヘッドが各フローのそれぞれの状態を保持することになり、IntServの解決策はあまりスケーラブルではない。

スケーラビリティの問題を解決するために、DiffServの解決策が、後にＩＥＴＦによって推奨されている。DiffServの解決策では、同様の特徴を有するフローがクラスに集められる。クラスの数は、DiffServフレームワークをサポートするネットワークによって、あらかじめ定められる。このフレームワークでは、パケットは、ＩＰヘッダ（ＤＳＣＰ：Differentiated Services Code Point）の数ビットでパケット自身の状態を運び、各フローの状態を維持するためにルータを必要としない。そのうえ、IntServとは対照的に、同一のフローにおけるパケットは同一のパスに従わないこともある。各パケットは、このＤＳＣＰに基づく特別の転送の取り扱いを受ける。このＤＳＣＰの値は、このパケットがどのように取り扱われるかを決定して、例えば、高い優先度のＤＳＣＰを持つパケットが、まず転送されることになる。

通常、IntServとDiffServのサポートはネットワークで扱われ、終端の端末は、これらの取り扱いが行われていることを知らない。あらゆるマーキング、スケジューリング、ポリシングは、終端の端末の代わりに、ネットワークにおけるネットワーク構成要素によって実行される。これらの方法によって、個々の終端の端末ではなく、ネットワークが、全体として、現在のネットワーク条件に基づくＱｏＳに関連する機能性を取り扱う。したがって、端末自体がどのような状態にあるかをより良く知っているときには、より良い終端点間のＱｏＳを提供するために、終端の端末自体がＱｏＳの機能性の取り扱いを実行する必要がある。
IETF Integrated Service working group、http://www.ietf.org/html.charters/intserv-charter.html IETF Differentiated Service Working Group、http://www.ietf.org/html.charters/diffserv-charter.html IETF Resource Reservation Protocol (RFC2205)、http://www.ietf.org/rfc/rfc2205.txt 3GPP、http://www.3gpp.org 3GPP2、http://www.3gpp2.org "Network Architecture" 3GPP TS 23.002 V5.8.0 (2002-09)、ftp://ftp.3gpp.org/specs/archive/23_series/23.002/ SIP : Session Initiation Protocol − RFC2543 SDP : Session Description Protocol − RFC2327 EAP AKA Authentication、http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-08.txt "Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security"、IEEE Std 802.11i/D3.0, November 2002 "IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control"、IEEE Std 802.1x-2001 "DRAFT IEEE Standard for Local and Metropolitan Area Networks−Port Based Network Access Control−Amendment 1: Technical and Editorial Corrections"、IEEE DRAFT P802.1aa/D4 November 5, 2002 ITU-T Z.120 Message Sequence Chart, 11/1999 Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance V.1 N.4, August 1993, pp.397-413 D. Clark and W. Fang, "Explicit allocation of best effort packet delivery service", IEEE Trans. Networking, 6(4), 1998, pp.362-373.

昨今、サービス品質（ＱｏＳ）のサポートは、良いシステムを作る必須要素の１つとなっている。従来、ＱｏＳは、ユーザに対してサービスを提供するネットワークによって扱われる。端末は、アプリケーションレベルでＱｏＳ処理を行うのみであり、例えば、ＲＳＶＰ（非特許文献３）を利用して、アプリケーションの要求に基づいて、ネットワークから所定のリソースを要求する。しかし、無線環境では、ＲＳＶＰはもはやＱｏＳ制御には適していない。移動端末は、その接続点を随時変え、その結果、１回のサービスセッションが終わる前でさえ、異なったデータパスを使用することがある。さらに、ＲＳＶＰは、データパスに沿ったあらゆるノードに対してサポートを要求するので、大きく複雑なシステムでは必ずしも可能なものではない。

終端点間のＱｏＳに着目した場合、コンテンツの受信者でありサービスのユーザである移動端末が、常に一方の終端を構成している。すなわち、端末は、必ずＱｏＳ制御に参加しなければならない。従来のネットワークに基づくＱｏＳ制御はローカライズされており、すなわち、その制御はローカルネットワークの条件にのみ基づいている。例えば、いくつかのネットワークを通じて別の端末に２Ｍｂｐｓのトラフィックを送る端末では、それぞれのネットワークにおいてパケットが失われてしまうかもしれない。また、それぞれのネットワークは、別々にその制御を実行しており、この種の非調整制御は最適化されず効率が悪い。しかしながら、移動端末はトラフィックの最終消費者なので、この移動端末で行われるＱｏＳに関するすべての情報を有しており、この情報を使用してＱｏＳの制御を行うシステムでは、ユーザはより良いサービスを得ることが可能である。

また、ネットワークを中心とするＱｏＳ制御（中継ネットワーク内のネットワークエレメントなどで行われるＱｏＳ制御）では、ネットワークは、トラフィックの輻輳を軽減するために、唯一、キューイング（queuing：パケットの転送順序制御）又はドロッピング（パケットの廃棄制御）のみを行うことができたが、これによって、問題が完全に解決することができたというわけではない。例えば、端末が速く送信を行うことによって輻輳が生じる場合には、ネットワークのドロッピングやキューイングを実行することによって、当該端末又はその他の端末が悪いサービスを受けることになってしまう。したがって、より良い方法によって、ソースや移動端末がそのトラフィックのスケジューリングを適切な方法で実行することが許容されるべきであり、移動端末用のシグナリングやトラフィック制御を発展させることが必要である。

ネットワークがＱｏＳ管理を実行することができないという極端な場合でも、端末中心のＱｏＳ制御が、依然として、ある程度のＱｏＳ保証を行う可能性がある。端末自体が動作を行い、不必要にネットワークに負荷をかけなければ、完全に輻輳を回避することが可能となる。

上記の問題を解決するため、本発明では、ネットワークから端末に、ＱｏＳ制御モジュールを移す。端末はトラフィックの条件を知り、ネットワークにその制御を任せる代わりに、修正が必要な場合には、端末自体で修正を行うようにしている。これによって、トラフィックを不必要に輻輳させないようにすることが可能となり、ＱｏＳに関連するすべての機能を取り扱うネットワーク管理システムに依存しないようにすることができる。

さらに、ネットワーク管理システムが存在する場合には、付加的なレベルで管理を行うことができるという利点もある。また、ネットワーク管理システムが存在しない場合でも、例えば、より低い送信レートで送信を行ったり、より低い優先度への設定を示すパケットを送信したりするなど、端末自体が、ＱｏＳの実施と動作の修正を適応させる能力を有する。また、ＱｏＳに関する能力がないネットワークでも、このネットワークに接続する端末がすべての動作を行うことが可能ならば、端末は、依然として所定のレベルのＱｏＳを保持することが可能である。

また、終端の端末自体は、ネットワークの状態に合わせて送信の容量を知る必要がある。ネットワークの条件を知るためには、セントラルサーバなどの集中化されたエンティティが、実際のデータ及びネットワークの条件を集めて統合して、各端末にフィードバック修正を行う必要がある。

本発明によれば、サービスを受ける終端のエンティティである端末でＱｏＳを取り扱うことが可能となる。これによって、ソースがリソースを効率よく管理できるようになり、ネットワークが不必要に輻輳することを避けることが可能となる。ＱｏＳ制御を備えていないネットワークの場合でも、ネットワークに接続する端末が個別にＱｏＳ制御を備えている場合には、端末は、依然としてある程度のＱｏＳ保証を有することになり、端末は、送信するパケット量や要求の量を制御することによって、ネットワークの動きを妨げることはない。また、これによって、ネットワークが、このＱｏＳ制御を行わずにすむようになる。

本発明は、より有効な終端点間のＱｏＳ管理を行うため、ＱｏＳの管理機能を端末に移すようにしている。移動端末は、その送信レートを管理したり、さらには取得する要求の数を制御することによって受信レートを管理したりするなどのＱｏＳの管理能力を備えており、本発明は、移動端末のユーザとサービスプロバイダとの間のサービスレベル協定に直接基づいて、すべての端末を監視する中央サーバ（セントラルサーバ）を有している。セントラルサーバは、ユーザのホームネットワークに存在する。このホームネットワークは、ユーザがサービスに加入しているネットワークである。また、端末は、報告及び監視を行うＱｏＳ制御モジュールを有している。このＱｏＳコントローラも、どの値が変更されるべきなのかを端末に告げる実施データを受信した場合でも、動作変更に反応することが可能であり、その後は、ＱｏＳコントローラは新しい値の閾値及びその範囲内で動作を行う。

以下、通信ネットワークに基づいて、端末をパケットのＱｏＳサービスコントロールに順応させるための装置及び方法が開示される。本発明の理解を助けるため、次の定義を使用する。

「ＷＬＡＮ」は、ワイヤレスローカルエリアネットワークを示す。これは、無線技術を通じて、移動端末に対してＬＡＮサービスを提供するために、任意の数のデバイスを含むものである。

「３Ｇネットワーク」は、第３世代の公衆アクセスネットワークを示す。例えば、３ＧＰＰ（非特許文献４）又は３ＧＰＰ２（非特許文献５）によって定義されるシステムである。

「移動端末（Mobile Terminal：ＭＴ）」は、無線技術を通じて、ＷＬＡＮやその他のネットワークによって提供されるサービスへのアクセスに使用されるデバイスを示す。

「ホームネットワーク」は、移動端末の相互接続のシナリオにおいて、移動端末が最初に属しているネットワークを示す。

「移動先ネットワーク」は、移動端末が接続するネットワークを示す。このネットワークは、移動端末にアクセスサービスを提供するものである。

「ネットワークエレメント」は、情報処理を行うネットワークで機能するあらゆるデバイスを示す。

「ルールエンジン」は、下記のルールサーバによって設定され、下記のルールインタプリタによってローカルに特有のコマンドに解釈されるルールを実行するネットワークエレメントを示す。

「ルールインタプリタ」は、下記のルールサーバによって与えられるルールを読み込み、適切なパラメータを用いてローカルの技術に特有のコマンドに解釈して、そのコマンドを実行するルールエンジンに対して供給するネットワークエレメントを示す。

「ルールサーバ」は、ルールインタプリタやルールエンジンに対して、要求を受けた場合又は要求を受けずに、適切なルールのセットを送信するネットワークエレメントを示す。

「エアインタフェース」は、移動端末がＷＬＡＮにアクセスするためのあらゆる無線アクセス技術を示す。

「ストリーム」は、所定の属性が共通であり、ネットワークで転送されるパケットの集まりである。

「トラフィック」は、ネットワークで転送されるストリームの集まりである。

「フロー」は、データパスや、ストリームを伝送するときに使用されるデータパスに必要なネットワークリソースを示す。

「ＱｏＳ」は、データストリーム又はトラフィックのサービス品質（Quality of Service）を示す用語である。

「メッセージ」は、相互接続を制御するために、ネットワークエレメント間で交換される情報を示す。

「動作シーケンス」は、相互接続の制御に関して、任意のネットワークエレメント間で任意の順序で交わされる一連のメッセージ交換を示す。

「上位レイヤ」は、あるエンティティから渡されたパケットを処理する、当該エンティティの上部に位置するあらゆるエンティティを示す。

「ＳＬＡ」は、サービスレベルの協定（Service Level Agreement：サービスレベルアグリメント）を示す。

「ユーザＳＬＡ」は、サービスプロバイダとユーザとの間のサービスレベルアグリメントを示す。

「ネットワークＳＬＡ」は、サービスプロバイダと別のサービスプロバイダとの間のサービスレベルアグリメントを示す。

「ＡＡＡ」は、移動端末へのサービス提供に関する認証（Authentication）、許可（Authorization）、課金（Accounting）を示す。

以下の説明では、本発明を完全に理解できるよう、具体的な数、時間、構造、プロトコルの名前、その他のパラメータが使用されるが、このような具体的な詳述がなくても、本発明の実施が可能なことは当業者にとって明白である。また、各事例では、本発明を不明瞭なものとしないよう、よく知られた構成要素やモジュールがブロック図で示される。

図１は、本発明の実施の形態における端末ベースの制御で終端点間のＱｏＳを実現する構成を示す模式図である。ここでは、システムアーキテクチャとして、３Ｇネットワークなどが用いられているが、同様のアーキテクチャや制御方式を有する他のネットワークにも適用可能であることは、当業者にとって明白である。

各移動端末（以下、単に端末とも呼ぶ）１１には、端末のＱｏＳコントローラモジュール１１Ａがインストールされている。この端末ＱｏＳコントローラモジュール１１Ａは、トラフィック調整、動作監視、パケットの再スケジューリングなどのＱｏＳ管理を実行する能力を有している。アクセスポイント１２は、移動先ネットワーク１３への端末の接続点である。移動先ネットワーク１３は、端末へのアクセスサービスを提供するネットワークであり、１つ又は複数の中継ネットワーク１７を介して端末のホームネットワーク１６と接続している。中継ネットワーク１７は、例えば、ＩＰバックボーンやＡＴＭネットワークなどを始めとして、どのようなタイプのものでもよい。

また、ポリシーアテンダント１４は、各移動先ネットワーク１３に存在している。このポリシーアテンダント１４は、移動先ネットワーク１３のルールエンジンとして機能し、移動先ネットワーク１３におけるＱｏＳ制御を実施するために、ポリシーコントロールフレームワークによって取得されるルールを実行する。また、ポリシーアテンダント１４は、移動先ネットワーク１３におけるローカルポリシーに基づいて、接続許可の制御を行う。

ＳＬＡマネージャ１５は、ホームネットワーク１６に存在する特別なサーバであり、このネットワークに加入するあらゆるユーザのＳＬＡに関する情報を有するＳＬＡデータベース１８を含むメインデータベースにアクセスを行う。また、ＳＬＡデータベース１８は、例えば、位置やサービス利用情報などの各ユーザのサービスステータスを含んでいる。３Ｇネットワークでは、このようなデータベースの一例として、ＨＳＳ６サーバ（非特許文献６）が挙げられる。また、ＳＬＡマネージャ１５は、ホームネットワーク１６における処理サーバとして機能し、ユーザの加入プロフィールやネットワークポリシーに基づいて、サービス提供の決定を行う。この決定は、ポリシーコントロールフレームワークによって各ネットワークのポリシーアテンダント１４や、本発明のシグナリング方法によって移動端末１１に伝えられる。

移動端末１１及びポリシーアテンダント１４は、望ましいＱｏＳでユーザにサービスを提供するために、適切に動作を行うことが可能である。また、ここで使用されるポリシーコントロール方法は、ネットワーク配置に依存する。なお、本発明では、既存のポリシーコントロールフレームワークを利用し、ポリシーコントロールフレームワークに付加的な条件を与えるものではない。また、本実施の形態では、シグナリングはＩＰに基づくプロトコルによって行われるが、例えば、ＳＳ７やＡＴＭなどの他の通信プロトコルによる実現が可能であることは、当業者にとって明白である。

端末はモバイルなので、異なる接続点で異なるネットワークに接続することが可能である。端末が接続するネットワークは、そのホームネットワーク１６又は移動先ネットワーク１３（ホームネットワーク１６以外のあらゆるネットワーク）である。端末が直接ホームネットワーク１６に接続する場合には、直接ＳＬＡマネージャ１５に接続する信号経路が保証される。また、端末が移動先ネットワーク１３に接続する場合には、端末によるすべての要求が、移動先ネットワーク１３に送られる必要があり、移動先ネットワーク１３はその要求をホームネットワーク１６に転送する必要がある。すなわち、ホームネットワーク１６と移動先ネットワーク１３とによって双方向の通信が行われる。このような状況における移動端末１１への信号経路を確立する方法はいくつか存在しており、それらは以下のようにして導入される。

図２は、本発明の実施の形態における端末中心のＱｏＳ制御フレームワークの詳細なアーキテクチャを示すブロック図である。なお、この図では、シグナリング及び制御に係るもののみが示され、それらに無関係なエンティティは省略されている。このアーキテクチャでは、セッション管理プロトコルが、端末のＱｏＳ報告及びフィードバック制御に利用される。例えば、セッション管理プロトコルとしては、ＳＩＰが使用可能である。なお、必要最小限の改変によって、他のセッション管理プロトコルでも動作することは、当業者にとって明白である。以下に、このアーキテクチャでの各モジュールの機能を簡潔に説明する。

端末２１は、ユーザ機器であり、例えば、移動端末である。これは、図１の端末１１及びＱｏＳコントローラモジュール１１Ａと同等のものである。

ＳＩＰアプリケーション２２は、セッション管理の基本的なプロトコルであるＳＩＰを使用する端末２１のアプリケーションである。

ＱｏＳコントローラ２３は、端末２１でＱｏＳを管理するエンティティであり、パケットの再スケジューリング、パケットのキューイング、パケットの廃棄、実行されるリクエストの量の調節などの動作監視やトラフィック調整を行う。これは、図１に示されるＱｏＳコントローラモジュール１１Ａの一例である。

移動先ネットワーク２４は、端末２１が現在接続しているネットワークである。

移動先ネットワーク２４におけるＳＩＰプロキシ２５は、実際の目的地に対してＳＩＰメッセージを転送するポイントとして機能する。

ポリシーアテンダント２６は、移動先ネットワーク２４のローカルな処理を管理する機能を有し、ポリシーコントロールフレームワークによって、ホームネットワーク２７のＳＬＡマネージャ２８と接続する。

ホームネットワーク２７は、端末２１がサービスに加入するネットワークである。

ＳＬＡマネージャ２８は、ＳＬＡデータベース２９にアクセスして、ユーザ報告を集め、ＱｏＳの取り扱い及び実施を決定するコントローラモジュールである。

ＳＬＡデータベース２９は、すべてのＳＬＡを格納する集中データ格納手段であり、ユーザとサービスプロバイダとの間のＳＬＡや、サービスプロバイダ間のＳＬＡを含んでいる。さらに、例えば、その位置や要求されたサービスなどの各ユーザに関するサービスステータスをも保持している。ホームＳＩＰプロキシ３０は、ホームネットワーク２７に存在するＳＩＰプロキシである。

図３は、図２のアーキテクチャで使用される、端末が直接ホームネットワークに接続していない場合のＱｏＳの報告及びフィードバックのためのシグナリングを示すシーケンスチャートである。端末２１は、移動先ネットワーク２４に接続し、ホームネットワーク２７へのダイレクトＩＰ接続を利用することはできない。ホームネットワーク２７によって提供されるサービスにアクセスするため、端末２１は、あるセッション管理メカニズムを使用する必要があり、この例では、ＳＩＰが図示されている。なお、他のセッション管理プロトコルでも動作可能なことは、当業者にとっては明白である。

端末２１が要求先パーティ（Callee party）とのセッションを開始する場合、ＳＩＰアプリケーション２２によって、対応するセッション記述プロトコルで、ＳＤＰメッセージとしても知られている“INVITE”を発行する（３０１：INVITE(SDP)）。ＳＤＰ内には、この端末にＱｏＳ制御能力があることを示すＱｏＳ制御能力タグが埋め込まれる。“INVITE”メッセージは、まず、移動先ネットワーク２４のＳＩＰプロキシ２５を通る。移動先ネットワーク２４のＳＩＰプロキシ２５はこのパケットを調べて、ホームネットワーク２７のホームＳＩＰプロキシ３０にＳＩＰメッセージを転送する（３０２：INVITE(SDP)）。ホームＳＩＰプロキシ３０は、ホームネットワーク２７に存在するＳＩＰプロキシであり、さらなる処理のためにこの要求を他のエンティティに転送する前に、要求されたサービスの許可を行うＳＬＡマネージャ２８に、このサービス要求をチェックさせる（３０３：Check Srv Req）。なお、この情報は、ＳＬＡデータベース２９に格納されている要求元のＳＬＡの一部である。

ＳＬＡマネージャ２８は、要求元のＳＬＡを保持していない場合には、ＳＬＡデータベース２９から要求元のＳＬＡを抽出する動作を行い（３０４：CheckSLA）、ＳＬＡデータベース２９は、ＳＬＡマネージャ２８に対してサービスを許可し、要求元のＳＬＡ情報を渡す（３０５：SLA OK）。このとき、渡されるＳＬＡ情報は、ユーザのＳＬＡの完全なものでなくてもよく、メッセージ（CheckSLA）でＳＬＡマネージャ２８によって示されたサービス要求に関した情報のみを含めればよい。要求元のＳＬＡに基づいてサービスが許可された場合には、ＳＬＡマネージャ２８は、セッション処理を続けるようにホームＳＩＰプロキシ３０に通知を行う（３０６：Srv Req OK）。一方、サービスが許可されない場合には、ＳＬＡマネージャ２８は、セッション要求を拒絶して、以降の処理を中止する。

次に、サービス要求に応じて、ホームＳＩＰプロキシ３０は、さらなる処理を行うために、例えば、サービスを要求されているホームＳＩＰプロキシなどのサービスプラットフォームに対して、ＳＩＰメッセージを転送する（３０７：サービスプラットフォームへのReqの転送）。この処理３０７でのサービスプラットフォームの処理が成功の場合には、ホームＳＩＰプロキシ３０は、ＳＩＰ１８３メッセージを受け取る（非特許文献７、８）。端末２１からのＳＤＰメッセージにＱｏＳ制御能力タグが含まれている場合には、ホームＳＩＰプロキシ３０は、ＳＬＡマネージャ２８に“Start PMSession”メッセージを発行する（３０８：Start PMSession）。この“Start PMSession”を受けた場合、ＳＬＡマネージャ２８は、監視セッションを開始することとなる。

また、必要に応じて、ＳＬＡマネージャ２８は、ＳＬＡデータベース２９に格納されたユーザのＳＬＡをアップデートする（３２４：ＳＬＡ更新）。なお、必要に応じてＳＬＡを更新するメカニズムと同一のものを適用することができることは、当業者にとっては明白である。また、同時に、ホームＳＩＰプロキシ３０は、ＱｏＳ制御能力タグが埋め込まれたＳＩＰ１８３メッセージを、移動先ネットワーク２４のＳＩＰプロキシ２５に中継する（３０９：SIP 183(SDP)）。この承認メッセージ（ＳＩＰ１８３メッセージ）のＱｏＳ制御能力タグは、端末２１にＱｏＳコントローラモジュールを開始できることを告げるものである。このメッセージを端末２１に転送する前に、移動先ネットワーク２４のＳＩＰプロキシ２５は、ポリシーアテンダント２６と共に端末２１が移動先ネットワーク２４のリソースの使用を許可されるか否かをチェックする（３１０：Auth req(SDP)）。

要求されたサービスが許可される場合には、リソースが利用可能な場合には、許可を示す情報（Authorize Token：オーソライズトークン）が、ポリシーアテンダント２６から移動先ネットワーク２４のＳＩＰプロキシ２５に送られる（３１１：Ack(Auth token)）。オーソライズトークンを受信した後、移動先ネットワーク２４のＳＩＰプロキシ２５は、端末２１に対して、このトークンと共にＳＩＰ１８３メッセージを転送する（３１２：SIP 183(SDP, Auth Token)）。端末２１は、このメッセージを受け取った場合には、ＱｏＳコントローラ２３にこのセッションに関する情報を通知して、ＱｏＳコントローラ２３の動作が開始される（３１３：Start QoS Controller）。

ポリシーアテンダント２６が、ローカルポリシー、又は、リソースが制限されているという理由によって、サービスを許可することができない場合には、メッセージ３１１には無効を示す情報が含まれることになる。この無効を示す情報を受信した場合、移動先ネットワーク２４のＳＩＰプロキシ２５は、ＳＩＰ１８３メッセージをユーザに送らず、代わりに、端末２１に対して、無効を示す情報と共にＳＩＰ４８８エラーメッセージを送る。端末２１が無効を示す情報を受け取ると、端末２１は、ＳＩＰプロキシ２５を介して、セッションを閉じる通るための“BYE”メッセージを開始する。なお、許可に失敗した場合のシナリオにおけるこのメッセージ交換処理は、図３では図示省略している。

端末２１がＳＩＰ１８３メッセージを受信した後、端末２１は、ＳＩＰで制御された通常のサービスセッションを開始する（３１４：ユーザセッション）。このサービスセッションの間、ＱｏＳコントローラ２３は、サービスセッションに関するＱｏＳレポートを作り、上記のＳＩＰ信号経路を利用して、ホームネットワーク２７のＳＬＡマネージャ２８にフィードバックを行う。

ＱｏＳコントローラ２３は、定期的に、サービスセッションに関するＱｏＳレポートを、対応するＳＩＰアプリケーション２２に渡す（３１５：QoS Report）。これを行うため、例えば、“REPORT”というメッセージのために、新しいＳＩＰの方法を定義することができる。ＳＩＰアプリケーション２２は、“REPORT”メッセージを生成し、そのＳＤＰ属性フィールド内に、ＱｏＳコントローラ２３から取得したＱｏＳレポート情報を挿入する。また、このメッセージに関する宛先アドレスを、ホームネットワーク２７のＳＩＰプロキシ３０とする。そして、ＳＩＰアプリケーション２２は、このレポートメッセージを移動先ネットワーク２４のＳＩＰプロキシ２５に転送し（３１６：Report(QoS Report)）、移動先ネットワーク２４のＳＩＰプロキシ２５は、メッセージ内の特定の宛先アドレス（ホームＳＩＰプロキシ３０）に転送する（３１７：Report(QoS Report)）。なお、移動先ネットワーク２４のＳＩＰプロキシ２５において、このREPORTの方法がサポートされていない場合には、ＳＩＰプロキシ２５は、これを“オプション”の方法として取り扱う。

ホームＳＩＰプロキシ３０は、この方法の要求を受け取ると、埋め込まれているＱｏＳレポート情報を抽出して、さらなる処理のために、ＳＬＡマネージャ２８に転送する（３１８：QoS Report）。ＳＬＡマネージャ２８は、このＱｏＳレポート情報を受け取った後、ネットワークポリシーやその他の関連情報を用いて、ＱｏＳ制御管理（QoS Control Management）を行う（３１９：ＱｏＳ制御管理）。この管理では、端末２１に割り当てられるＱｏＳパラメータの調整、及び／又は、ＳＬＡデータベース２９での対応するデータの更新も行われる。

例えば、“REPORT”メッセージは、以下のようになる。
/*ＱｏＳの報告を運ぶ新しいＲＥＰＯＲＴの方法*/
REPORT sip:foo.bar.com SIP/2.0
From : sip:[email protected] /*端末のＳＩＰアドレス*/
To : sip: [email protected] /*ホームＳＩＰプロキシのアドレス*/
Cseq : 1 REPORT
a = packet_sent:xxxx /*ＱｏＳパラメータ情報を運ぶ属性フィールド*/ a = packet_recv:xxxx
a = avg_bandwidth:xxxx

レポートのために含まれ得るその他のＱｏＳパラメータとしては、ＱｏＳクラス、送信容量（送信バイト）、受信容量（受信バイト）、廃棄容量（廃棄バイト）、廃棄パケット数、平均帯域幅、最大帯域幅、廃棄インターバル、平均遅延時間、ジッタ、利用情報、送信廃棄閾値などが挙げられる。なお、ＱｏＳパラメータはさらに拡張可能であり、上記に限定されるものではない。

ＱｏＳの調整が必要な場合には、ＳＬＡマネージャ２８は、端末２１の識別子と共にＱｏＳ制御メッセージをホームＳＩＰプロキシ３０に送る（３２０：QoS Control）。このとき、ホームＳＩＰプロキシ３０は、ＱｏＳ制御が目的であることを示す特別なコードを有するＳＩＰメッセージを作成し、受け取ったＱｏＳ制御メッセージをその中に入れる。例えば、QOS_ENFORCEメッセージという、別の新しい方法を定義することができる。ホームＳＩＰプロキシ３０は、端末２１の移動先ネットワーク２４のＳＩＰプロキシ２５に、このQOS_ENFORCEメッセージを転送する（３２１：QOS_ENFORCE(QoS Control)）。移動先ネットワーク２４のＳＩＰプロキシ２５は、端末２１のＳＩＰアプリケーション２２に、このメッセージを即座に転送する（３２２：QOS_ENFORCE(QoS Control)）。

端末２１のＳＩＰアプリケーション２２は、ＱｏＳ制御を示すコードを読むと、SIP TBDメッセージから、埋め込まれたＱｏＳ制御情報を抽出して、ＱｏＳコントローラ２３に、サービスセッション情報と共に、抽出されたＱｏＳ制御メッセージを送る（３２３：QoS Control）。そして、ＱｏＳコントローラ２３は、ＱｏＳ制御メッセージによって提供された指示に従って動作し、サービスセッションにとってより良いＱｏＳを達成できるよう、端末２１の動作を調整する。図１２は、本発明の実施の形態における操作＿ＩＤ(Action_ID)のテンプレートである。以下のように、例えば、上記の指示は“操作＿ＩＤ”属性フィールドで運ばれる。“操作＿ＩＤ”属性フィールドには、例えば、図１２の表に列挙したものが存在する。

QOS_ENFORCE sip:home.com SIP/2.0
From : sip: [email protected]
To : sip:[email protected]
Cseq : 1 QOS_ENFORCE
A = action_id:xxxx /*action attribute*/
A= <Qos Parameter>:yyyy

なお、ＳＬＡマネージャ２８が同一のメカニズムを使用して、要求されていないＱｏＳ制御メッセージを送ることも可能なことは、当業者にとっては明白である。例えば、ネットワーク状態が変化したり、ネットワーク処理が異なったりする場合には、ＳＬＡマネージャ２８は、端末２１のＱｏＳ制御パラメータを調整する必要であり、これによって、端末２１にＱｏＳ制御メッセージを発信することが可能となる。

また、端末２１のＱｏＳコントローラ２３は、端末２１内のアプリケーションを越えて共有される。したがって、アプリケーションが動作している限り、ＱｏＳコントローラ２３は有効な状態となっている。新しいセッションが、ＱｏＳコントローラ２３が既に実行していることを検出した場合には、ＱｏＳコントローラ２３の新しいプロセスは始まらず、すでに存在しているものを用いて、監視、報告、実施が行われる。

図４は、図１で示される端末中心のＱｏＳ制御フレームワークのための代替アーキテクチャの一例を示すブロック図である。このアーキテクチャでは、ＡＡＡ（認証、許可、課金処理）フレームワークが、ＱｏＳ報告及び制御の実施を確立するために利用される。この図４では、シグナリングと制御に係る要素のみが図示されている。端末４１は、シグナリングのために２つの構成要素、ＱｏＳコントローラ４２及びＡＡＡスタック４３を有している。 ＱｏＳコントローラ４２は、図１で示されるＱｏＳコントローラモジュール１１Ａであり、端末４１でＱｏＳを実施して、端末４１から出力されるトラフィックを制御する。また、ＱｏＳコントローラ４２は、端末４１のＱｏＳ利用情報を監視して集め、端末４１のホームネットワーク４６内のＳＬＡマネージャ４８にフィードバックする。

また、ＡＡＡスタック４３は、端末４１のＡＡＡ（認証、許可、課金処理)手続きを制御するエンティティである。例えば、３Ｇネットワークでは、EAP-AKA（非特許文献９）を用いることが可能であり、また、IEEE802.11i（非特許文献１０）ＷＬＡＮのシステムでは、IEEE802.1x（非特許文献１１、１２）に鍵の管理を行うエンティティを加えたものを用いることが可能である。ＡＡＡスタック４３は、標準のネットワークで必要なものであり、したがって、本発明はネットワークに余分な要求を行うものではない。端末４１は、移動先ネットワーク４４に接続する。移動先ネットワーク４４は、端末４１からホームネットワーク４６内のＡＡＡサーバ４７まで、ＡＡＡメッセージを中継するための標準のＡＡＡ設備、すなわちＡＡＡプロキシ４５を提供する。実際には、ＡＡＡプロキシ４５は、他のネットワークエレメントと共存することが可能であり、例えば、IEEE802.11iシステムでは、ＡＡＡプロキシ４５は、アクセスポイント内にある認証装置とすることが可能であり、これによって、端末４１からのＥＡＰパケットは、Radius／Diameterパケットにカプセル化される。ホームネットワーク４６におけるＳＬＡマネージャ４８及びＳＬＡデータベース４９は、図１で定義されている構成要素１５及び１８と同一である。

また、図５は、本発明の実施の形態における端末中心のＱｏＳ制御を達成するために、図４で導入されているフレームワークを使用する信号シーケンスの一例を示すシーケンスチャートである。端末４１が移動先ネットワーク４４に接続して、あるサービスに初めてアクセスする場合、移動先ネットワーク４４では、端末４１のＡＡＡスタック４３が、“AAA request”をＡＡＡプロキシ４５に送る（５０１：AAA request(NAI)）。この“AAA request”は、端末４１の識別情報及びホームドメイン情報を含んでいる。例えば、３Ｇネットワークでは、この情報は、ネットワークアクセス識別子（ＮＡＩ）の形式で存在している。ＮＡＩの内容は、例えば、“[email protected]”などが可能である。ここで“terminal1”は識別子であり、“foo.bar.com”はホームドメイン情報である。ＡＡＡプロキシ４５は、ＮＡＩ内に記載されているドメイン情報を使用して、要求（AAA Request、以下、ＡＡＡ要求とも呼ぶ）をユーザのホームネットワーク４６のＡＡＡサーバ４７に転送する（５０２：AAA request(NAI)）。

メッセージを受信した後、ホームネットワーク４６のＡＡＡサーバ４７は、ＡＡＡ要求から、ユーザ識別子とサービス情報とを抽出する。ＡＡＡサーバ４７は、さらにこの要求をＳＬＡマネージャ４８に送り、ＳＬＡ内のユーザの加入情報に対して、サービスが許可されるかどうかをチェックする（５０３：ユーザの加入情報をチェック）。もし利用が不可能ならば、ＳＬＡマネージャ４８は、ＳＬＡデータベース４９からユーザのＳＬＡを抽出する（５０４：ＳＬＡを要求、５０５：ＳＬＡを取得）。一方、ユーザのＳＬＡに基づき、要求されたサービスが許可されるならば、ＳＬＡマネージャ４８は、ＳＬＡに格納されたネットワークポリシーやＳＬＡ内のその他の情報に従って、さらなるサービス構成情報を提供し（５０６：サービス許可段階、初期のＱｏＳを構成）、さらに、ＳＬＡマネージャ４８は、ＡＡＡ要求に埋め込まれたＮＡＩによって、端末４１の能力をチェックする。端末４１がＱｏＳ制御を行うことが可能ならば、疑似サービス“ＱｏＳ制御”が、実際のサービスと共にデフォルトで要求される。

例えば、ＮＡＩがサービスを示すために使用される場合には、[email protected]という形式も可能である。ここで、“@”のすぐ右の“QoS Control”は、端末４１がＱｏＳ制御を行うことが可能であることを示している。なお、サービスを特定するためにＡＡＡ手続きで採用されるスキームに依存して、その他の指示情報を用いることが可能なことは、当業者にとっては明白である。

ＳＬＡマネージャ４８がこの“QoS Control”疑似サービスを発見した場合には、端末４１のサービス監視を開始して、ＱｏＳ制御のための接続を設定するパラメータを構成する。この構成は、ＱｏＳコントローラ４２のためのＱｏＳ初期パラメータの設定、ＱｏＳ制御のためのホームネットワークアドレスの割当て、制御メッセージ用のトンネル構成の管理などを含んでいる。このような特別な設定が、通常のサービス構成に含まれるようにすることも可能であり、この場合には、まとめてＡＡＡサーバ４７に送られる（５０７：Service Auth(QoS Control Setup)）。なお、必要ならば、ＳＬＡマネージャ４８は、同時にＳＬＡデータベース４９に格納されたＳＬＡの更新も行う（５０８：ＳＬＡ更新）。そして、ＡＡＡサーバ４７は、“Service Config”メッセージを作成して、その中にすべての設定を埋め込み、移動先ネットワーク４４のＡＡＡプロキシ４５を介して、それを端末４１のＡＡＡスタック４３に送る（５０９：Service Config(QoS Control Setup)、５１０：Service Config(QoS Control Setup)）。

ＡＡＡスタック４３は、“Service Config”メッセージを受け取った場合には、埋め込まれているサービス情報をすべて抽出して、それらを対応するアプリケーションに渡す。また、同様に、“QoS Control”疑似サービスの構成は、端末４１のＱｏＳコントローラ４２に渡されて（５１１：QoS Control Setup）、ＱｏＳサービスセッションが開始される。ＱｏＳコントローラ４２は、端末４１でＱｏＳ制御を行うため、ＡＡＡ要求に埋め込まれていた初期のＱｏＳ構成を使用する。また、ＱｏＳコントローラ４２は、ホームネットワーク４６のＳＬＡマネージャ４８に向かうトンネルをセットアップするために、ＡＡＡ要求に埋め込まれていたトンネル構成を使用する（５１２：ＱｏＳ制御トンネル設定）。このトンネルは、ＳＬＡコントローラ４２がＳＬＡマネージャ４８に対してＱｏＳ統計量を報告するために使用され、ＳＬＡマネージャ４８がＱｏＳコントローラ４２に対してＱｏＳ実行指示を送るために使用される。

このスキームでは、ＱｏＳコントローラ４２は、ＡＡＡスタック４３に対して、通常のアプリケーションのように動作を行う。 ＱｏＳ設定やトンネル設定は、ＡＡＡスタック４３にとっては明白である。したがって、たとえ、ＱｏＳコントローラ４２がその設定にＡＡＡフレームワークを使用しても、標準のＡＡＡスタック４３からの変更は全く必要としない。 すなわち、これは、どんな標準ネットワークでも、本発明が、高い適応性を有していることを示すものである。

ユーザセッションが進むと、ＱｏＳコントローラ４２は、端末４１で観測されたサービスを反映するＱｏＳ統計量を生成する。ＱｏＳコントローラ４２は、上記のトンネル設定を使用して、この情報をＳＬＡマネージャ４８に報告する（５１３：ＱｏＳ報告）。図９は、本発明の実施の形態における端末からＳＬＡマネージャに送られるＱｏＳデータを報告するための報告メッセージ（ＱｏＳ報告）のフォーマットを示す図である。報告メッセージは、最初にメッセージ＿ＩＤフィールド９１、続いてメッセージ長フィールド９２、さらにペイロードを有している。ペイロードは、属性値ペア情報９３からなり、属性には、ＱｏＳパラメータ又は情報の属性が含まれている。

ＱｏＳパラメータの例としては、ＱｏＳクラス、送信容量（送信バイト）、受信容量（受信バイト）、廃棄容量（廃棄バイト）、廃棄パケット、平均帯域幅、最大帯域幅、廃棄インターバル、平均遅延時間、ジッタ、利用情報、送信廃棄閾値などが挙げられる。なお、ＱｏＳパラメータはさらに拡張可能であり、上記に限定されるものではない。この例では、固定長の属性値のペアが使用されており、したがって、メッセージ長フィールド９２だけが唯一、メッセージ全体に関して必要な情報となる。なお、可変長の属性値のペアを採用している場合には、各ペアは、属性値のペアの長さを示す付加的な長さフィールドを必要とする。

ＱｏＳコントローラ４２から報告を受け取った後に、ＳＬＡマネージャ４８は、何らかのＱｏＳ管理プロセスを実行して、端末４１で何らかの調整が行われる必要があるか否かを決定する。また、必要ならば、ＳＬＡデータベース４９内のＳＬＡの更新を行う。端末４１で何らかの変更が必要な場合には、ＳＬＡマネージャ４８は、ＱｏＳ制御トンネル設定５１２でＱｏＳ実行メッセージをＱｏＳコントローラ４２に送る（５１４：ＱｏＳ実行制御）。図１０は、本発明の実施の形態におけるＳＬＡマネージャから端末に送られるＱｏＳ実行メッセージのフォーマットを示す図である。ＱｏＳ実行メッセージは、メッセージ＿ＩＤフィールド１０１、メッセージ長フィールド１０２、操作＿ＩＤフィールド１０３、ＱｏＳパラメータフィールド（属性値ペア情報）１０４を有している。ＱｏＳ実行メッセージには、あらかじめ定義されたメッセージテンプレートのセットが存在する。上述の報告メッセージのフォーマットと同様に、ＱｏＳパラメータフィールド１０４は、０個、１個、又は、複数個のＱｏＳデータフィールドであり得る。操作_ＩＤフィールド１０３及び対応する操作の一例は、図１２に示されているものと同様である。

ＱｏＳ制御トンネル設定５１２でトンネルがいったん設定されれば、ＳＬＡマネージャ４８とＱｏＳコントローラ４２にとって、そのトンネルは利用可能なものとなる。２つのノードが互いに、同一のサブネットに存在するように通信を行う。ＳＬＡマネージャ４８のアドレスと対応するポートナンバーとが、“ＱｏＳ制御”サービスの設定時間中に（ＱｏＳ制御設定５１１のときに）、ＱｏＳコントローラ４２に送信されるようにすることも可能である。端末４１のアドレスは、サービス許可段階５０６の間に、ＳＬＡマネージャ４８によって割り当てられて、常に利用可能である。

ＱｏＳ制御のための終端点間の通信では、ＳＬＡマネージャ４８は、例えば、ポート“ｓｓ”のＩＰアドレス“ｘｘｘｘ”のように、端末４１のアドレス及びあらかじめ定められたポートナンバーのみを記す必要があり、一方、端末４１のＱｏＳコントローラ４２は、例えば、ポート“ｐｐ”のＩＰアドレス“ｙｙｙｙ”のように、ＳＬＡマネージャ４８のアドレス及びサービス許可段階５０６で取得したポートナンバーのみを記す必要がある。中継のルートは、トンネルチャンネル内で扱われる。なお、本発明では、絶対的なアドレスを使用する代わりに、どのようなアドレス方法にも適用可能なことは、当業者にとっては明白である。

トンネルチャンネルは、端末４１ごとに設定される必要があり、通常は、移動先ネットワーク４４におけるサービスで最初に要求される。すなわち、端末４１ごとに、疑似サービス“ＱｏＳ制御”が１つだけ存在する。ＳＬＡマネージャ４８は、チャンネルの中止を決めることができる。例えば、端末がもはや移動先ネットワーク４４に接続していない場合や、サービスセッションがもはや存在しない場合には、ＳＬＡマネージャ４８は、制御ノード（例えば、ＧＧＳＮ）での設定を削除するために、ＡＡＡサーバ４７にシグナリングを行うことができる。

また、ＳＬＡマネージャ４８は、求められていないＱｏＳ実行制御メッセージ５１４をＱｏＳコントローラ４２に送ることも可能である。また、システム全体は、報告及び実行／更新の概念に基づいて動作する。図１に示すポリシーアテンダント１４及びＱｏＳコントローラ１１Ａの両方は、ＳＬＡマネージャ１５に報告を行いながら動作する必要がある。ＱｏＳコントローラ１１Ａは、端末１１で観測される状態に関して報告を行い、一方、ポリシーアテンダント１４は、ネットワークの状態と条件をＳＬＡマネージャ１５に報告する。報告は、定期的又は要請された場合に行われ得る。ＳＬＡマネージャ１５は、ポリシーアテンダント１４又はＱｏＳコントローラ１１Ａの一方からの報告に基づく調整の必要性を判断した場合に、ＱｏＳ実行メッセージを発行する。なお、必要に応じて、ＳＬＡマネージャ１５がポリシーフレームワーク（不図示）をさらに使用して、同時にネットワークを調整できることは、当業者にとっては明白である。

先に説明した２つのシグナリングは、終端点間のＱｏＳ制御を達成するため、端末１１からホームネットワーク１６又はその逆の方向にＱｏＳデータを渡す経路を設定する必要があるシグナリングのメカニズムである。

端末１１はいったんＳＬＡマネージャ１５からＱｏＳ実行指示を受信すると、端末１１のＱｏＳコントローラ１１Ａは、このＱｏＳ実行指示に応じて、現在の状態をＱｏＳ実行指示されたものに置き換える。図６は、本発明の実施の形態におけるＱｏＳコントローラのＱｏＳ監視の一例を示す図である。これは、ハイレベルメッセージシーケンス（非特許文献１３）を使用してモデル化されている。端末１１のＱｏＳコントローラ１１Ａが起動すると、あるプリセットの初期値又は初期構成状態から取得される初期値が構成される（６０１：初期構成の設定）。これらの値は、動作データの監視を行うために使用される異なるＱｏＳメトリックを含んでいる。端末１１のＱｏＳコントローラ１１Ａは起動すると、動作を開始して、利用データの収集及び監視を行う。さらに、収集したデータをフィードバックし、周知のフォーマットに詰めて、統合を行っているセントラルサーバに送る報告を行う（６０２：動作データの監視及び報告）。この場合、セントラルサーバは、例えば、ＳＬＡマネージャ１５である。動作の監視の間、セントラルサーバは動作データとその閾値との比較を行い、違反が起こる（６０３：閾値違反が起こる）と、この違反を処理するために必要な修正を実行する（６０４：違反の処理）。

ここで行われる修正動作は、伝送帯域幅が閾値を超えている場合には、送信パケットの遅延、パケットの完全な廃棄及び／又はパケットの再スケジューリング、あるいは、セッションの完全な終了である。したがって、このようにして、伝送帯域幅を制御することが可能となる。パケットを受ける場合には、入力パケットの要求を最小化して、受信帯域幅を制御し、さらに、すべての入力パケットの帯域幅要求を抑えることができる。また、ネットワークの状態が変化する場合には、ポリシーサーバ（セントラルサーバ）は、ＳＬＡマネージャ１５にこれらの変化を通知する。そして、ＳＬＡマネージャ１５はポリシーの変更に関する決定を行う。これは、更新後の新しい閾値でＱｏＳを管理するため、ポリシーサーバのルールエンジンの更新、及び／又は、影響を受ける端末１１のＱｏＳコントローラの構成の更新を含むものである。影響を受ける端末１１の構成の更新では、上記の影響を受ける端末１１に対して、実行データが渡される。上記の影響を受ける端末１１は、実行データを受信して（６０５：実行データの受信）、このデータの要求に基づいて、必要な更新又は変更を行う（６０６：要求された動作を行う）。そして、監視処理が、更新後の新たな値に基づいて再開される。

図７は、本発明の実施の形態におけるＳＬＡマネージャが監視しているセッションをモデル化した図である。動作監視セッションが開始した場合、ＳＬＡマネージャ１５は監視のために、ＳＬＡデータベース１８から必要なＳＬＡ情報と現在のルールを読み込む（７０１：ルールの読み込み）。ＳＬＡマネージャ１５は、定期的に、端末１１とポリシーサーバのステータスに関する報告を受け取る（７０２：ネットワーク及び端末の監視）。なお、例えば、ＳＬＡマネージャ１５に積極的に送信したり、ＳＬＡマネージャ１５からの要求に応えたりすることによって、ＳＬＡマネージャ１５が非周期的な方法で報告を受け取ることも可能である。ステータスはＳＬＡ情報と比較される。もし、警告又は違反が検出された場合（７０３：違反の検出）には、ＳＬＡマネージャ１５は、違反の性質とネットワーク及び端末１１の両方の状態に依存して、行うべき操作を決定する（７０４：輻輳回避処理、新しいルールの実行）。例えば、ＳＬＡマネージャ１５は、新しいルールを実行したり実行データを決めたりして、周知のフォーマットにその情報を詰めて、新しいルールでポリシーサーバを更新する実行メカニズムを行うか、又は、端末１１に対して、その構成を変更するよう要求する。

また、図１１は本発明の実施の形態における端末のＱｏＳコントローラのためのアーキテクチャを示す図である。このＱｏＳコントローラ １１０１は、次に示すサブコンポーネントを有している。監視モジュール１１０３は、計測モジュール１１０２を有し、動作監視データを収集して、さらに、閾値違反を確認する。また、実行モジュール１１０７は、トラフィック整理を行う分類装置１１０４、マーカ１１０５、パケット遅延／パケット廃棄装置１１０６を有している。また、通信モジュール１１１０は、計測モジュール１１０２からのすべての動作監視データを集めて格納する利用情報及びトラフィックプロフィール１１０８と、ＳＬＡマネージャと通信を行う報告モジュール１１０９を有している。なお、この通信モジュール１１１０は、実行データを受信しているときには、修正を実行するために実行モジュールとしても機能する。

データパケット１１１２は、端末から出力される前に、その優先順位に従って分類装置１１０４によって分類される必要がある。各アプリケーションには、事前に定義された優先順位があり、分類装置１１０４による分類後、データパケット１１１２は、マーカ１１０５に送られて、“in_profile”、“out_profile”のようにマークされる。計測モジュール１１０２は、利用情報及びトラフィックプロフィール１１０８に対してチェックを行い、端末の現在の状態をマーカ１１０５に通知する。そして、マーカ１１０５は、現在の状態に従って“in_profile”、“out_profile”のようにパケットをマークする。

このマークプロセスの後に、パケット遅延／パケット廃棄装置１１０６は、パケットの発信を遅らせるか、又は、パケット全体を廃棄するかを決定する。さらに、パケット遅延／パケット廃棄装置１１０６は、パケットの遅延又は廃棄に関わらず、計測モジュール１１０２を通じて現在の端末をチェックする。“out_profile”がマークされているパケットは、“in_profile”がマークされているパケットよりも高い確率で廃棄処理される。出力データパケット１１１３は実際に出力されるパケットである。報告モジュール１１０９は、定期的にＳＬＡマネージャ１１１１に報告を行い、ＳＬＡマネージャ１１１１は、報告モジュール１１０９を通じて端末にＱｏＳ実行メッセージを送り返す。何らかの実行動作が要求された場合には、ＱｏＳ実行メッセージが、関連する実行モジュール１１０７で実行される。

また、図８は、本発明の実施の形態におけるＱｏＳコントローラがＱｏＳ監視及びトラフィック制御を行う方法を示す図である。輻輳が起こると、ＳＬＡマネージャ１１１１は、端末のＱｏＳコントローラ１１０１にＱｏＳ実行データを渡して、動作を変更させる。この例では、データパケットは分類装置１１０４によって４つの異なった優先順位Ａ、Ｂ、Ｃ、Ｄに分類される。Ａは最も高い優先度、Ｄは最も低い優先度を示している。また、端末に割り当てられる伝送帯域幅が、修正を実行する決定因子として使用される。さらに、修正を実行するために、その他のパラメータを決定因子に用いることも可能である。

ＱｏＳコントローラ１１０１が、その帯域幅を下げるよう指示するＱｏＳ実行データを受け取る場合には、ＱｏＳコントローラ１１０１は、現在の値から、受信した新しい値に変更して、新しい保証値を設定する（８０１：実行データの受信、新しい保証値の設定）。また、輻輳が起こる場合に関しては、ＳＬＡマネージャ１１１１は、割り当てられた伝送帯域幅を低い優先順位の端末と同一のレベルまで落とし、その影響が出る端末に対して、必要な情報を含む実行データを送る。端末は、この実行データを受信すると、更新を行う前の値と実行データとの比較を行う。また、“total allocated bandwidth”（総割当帯域幅）の測定データに関しては、新しい値が既存の値以下の場合には、修正を実行する。

この例では、タイプＡに分類されるパケットに対して、最高の優先度が与えられるが、もし、タイプＡのアプリケーションに関して、総帯域幅の保証値が、要求されている帯域幅を十分サポートできない場合（８０２：クラスＡの帯域幅＞新しい保証値）には、現在行っているクラスＡのセッションを終了する （８０３：クラスＡのセッションを終了）。一方、総帯域幅の保証値が、要求されている帯域幅をサポートできる場合には、タイプＡのパケットに要求通りの帯域幅がすべて与えられることとなる（８０４：クラスＡのパケットに完全な帯域幅を割り当てる）。タイプＡのパケットに対してすべて割当てを行った後、残りの帯域幅をタイプＢ、Ｃ、Ｄに、例えば、７：２：１の比率で割り当てる（８０５：クラスＢに残りの帯域幅の７０％を割り当てる、８０６：クラスＣに残りの帯域幅の２０％、クラスＤに残りの帯域幅の１０％を割り当てる）。なお、クラスＢ、Ｃ、Ｄでは、送信レート、パケット廃棄、パケット送信の遅延などによって、帯域幅の調節が行われる。このようにして割り当てられた帯域幅やクラスなど数に従って、異なったクラスごとにパケットがキューイングされ、また、各タイプの閾値が計算される（８０７：新しく割り当てられた帯域幅に従って、閾値を再設定）。また、閾値に達するかどうかに従って、パケットには“in_profile”、“out_profile”がマークされる。例えば、ビデオエンコーダアプリケーションの場合に、帯域幅の利用がタイプＢ用の閾値を超えるなら、ＱｏＳコントローラがビデオエンコーダに接続して、もっと低いビットレートでエンコードを行うよう指示することも可能である。

また、上述のアプリケーションへのインタフェースが全く存在せず、接続できない場合には、ＱｏＳコントローラは、閾値に適合するように選択的にパケットを廃棄すると決定することも可能である。入力パケットは“out_profile”として選択的にマークされて、“out_profile”でマークされたパケットが、まず最初に廃棄される。タイプＣ及びＤに関しては、タイプＣのパケットが、タイプＤのパケットより頻繁にキューイングされ、タイプＤのパケットは、割り当てられた比率に基づいて最後にキューイングされる。なお、上記の比率は、あくまでも一例であり、異なるクラスに帯域幅を割り当てることによって、あらゆる比率が可能となる。また、分類のタイプは、いかなる分類数でも可能であり、タイプＡ、Ｂ、Ｃ、Ｄに制限されるものではない。さらに、ＱｏＳコントローラは、例えば、ＲＥＤ（非特許文献１４）やＲＩＯ（非特許文献１５）などの、他のスケジューリング手段やキューイングのメカニズムＱｏＳコントローラがスケジューリングの他の手段を使用することができる。

本発明の実施の形態における端末ベースの制御で終端点間のＱｏＳを実現する構成を示す模式図 本発明の実施の形態における端末中心のＱｏＳ制御フレームワークの詳細なアーキテクチャを示すブロック図 図２のアーキテクチャで使用される、端末が直接ホームネットワークに接続していない場合のＱｏＳの報告及びフィードバックのためのシグナリングを示すシーケンスチャート 図１で示される端末中心のＱｏＳ制御フレームワークのための代替アーキテクチャの一例を示すブロック図 本発明の実施の形態における端末中心のＱｏＳ制御を達成するために、図４で導入されているフレームワークを使用する信号シーケンスの一例を示すシーケンスチャート 本発明の実施の形態におけるＱｏＳコントローラのＱｏＳ監視の一例を示す図 本発明の実施の形態におけるＳＬＡマネージャが監視しているセッションをモデル化した図 本発明の実施の形態におけるＱｏＳコントローラがＱｏＳ監視及びトラフィック制御を行う方法を示す図 本発明の実施の形態における端末からＳＬＡマネージャに送られるＱｏＳデータを報告するための報告メッセージ（ＱｏＳ報告）のフォーマットを示す図 本発明の実施の形態におけるＳＬＡマネージャから端末に送られるＱｏＳ実行メッセージのフォーマットを示す図 本発明の実施の形態における端末のＱｏＳコントローラのためのアーキテクチャを示す図 本発明の実施の形態における操作＿ＩＤ（Action_ID）のテンプレートを示す図

１１、２１、４１ 移動端末（ＭＴ、端末）
１１Ａ、２３、４２、１１０１ ＱｏＳコントローラモジュール（ＱｏＳコントローラ）
１２ アクセスポイント
１３、２４、４４ 移動先ネットワーク
１４、２６ ポリシーアテンダント
１５、２８、４８、１１１１ ＳＬＡマネージャ
１６、２７、４６ ホームネットワーク
１７ 中継ネットワーク
１８、２９、４９ ＳＬＡデータベース
２２ ＳＩＰアプリケーション
２５ ＳＩＰプロキシ
３０ ホームＳＩＰプロキシ
４３ ＡＡＡスタック
４５ ＡＡＡプロキシ
４７ ＡＡＡサーバ
１１０２ 計測モジュール
１１０３ 監視モジュール
１１０４ 分類装置
１１０５ マーカ
１１０６ パケット遅延／パケット廃棄装置
１１０７ 実行モジュール
１１０８ 利用情報及びトラフィックプロフィール
１１０９ 報告モジュール
１１１０ 通信モジュール
１１１２ データパケット
１１１３ 出力データパケット

Claims (6)

1. 観測されたＱｏＳの統計量が所定の閾値を超えていないかを監視し、ＱｏＳ統計量をセントラルコントローラへ報告し、前記セントラルコントローラからから受信したＱｏＳ実行データに基づくＱｏＳ制御を実行することが可能なＱｏＳ制御モジュールを有する端末であって、
   前記ＱｏＳ制御モジュールが、
   前記端末及び動作中のアプリケーションから、ＱｏＳに係る情報を収集する監視モジュールと、
   前記セントラルコントローラに前記収集されたＱｏＳに係る情報を報告し、前記セントラルコントローラから実行指示を受信する通信モジュールと、
   前記通信モジュールから受信したＱｏＳのメトリックに従って、前記端末の動作を制御する実行モジュールとを、
   有する端末。
2. 前記端末の前記ＱｏＳ制御モジュールが、前記収集されたＱｏＳに係る情報を格納するためのローカルデータベースをさらに有する請求項１に記載の端末。
3. 前記監視モジュールが、
   前記ＱｏＳに係る情報を取得して、前記端末のローカルデータベースに前記ＱｏＳに係る情報を格納するための手段と、
   閾値違反を監視する手段と、
   前記違反が検出された場合には、前記実行モジュールにトラフィック制御を開始させる手段とを、
   有する請求項２に記載の端末。
4. 前記セントラルコントローラに前記ＱｏＳに係る情報を送信する前に、公知のフォーマットで前記ＱｏＳに係る情報を梱包する手段と、
   前記セントラルコントローラから受信したＱｏＳの実行に係る情報を解析する手段と、
   前記セントラルコントローラから受信した前記ＱｏＳの実行に係る情報に基づいて、端末の状態を更新する手段と、
   必要に応じて、前記セントラルコントローラから受信した前記ＱｏＳの実行に係る情報内の適切な修正を、前記実行モジュールに行わせる手段とを、
   有する請求項１から３のいずれか１つに記載の端末。
5. 前記実行モジュールが、前記端末でトラフィック制御を行う手段をさらに有し、前記端末の動作を制御する請求項１から４のいずれか１つに記載の端末。
6. 前記実行モジュールが、
   前記端末において、パケットを異なる優先順位に分類する手段と、
   前記端末に割り当てられるリソース割当が使い切られた場合、前記端末において、パケット廃棄を管理する手段と、
   送信レートを下げることによって、前記端末における輻輳を抑える手段と、
   十分なリソースが前記端末に割り当てられない場合には、パケットの送信を遅延させることによって、前記端末における輻輳を抑える手段と、
   セッションを終了してパケットの送信を中止する手段と、
   現在動作しているセッションの総数を制限することによって、出力パケットを減少させる手段と、
   出力を行うセッションの総数を制限することによって、入力トラフィックを減少させる手段と、
   入力トラフィックを少なくする要求を行うことによって、入力トラフィックを減少させる手段とのうちの少なくとも１つ以上を有する請求項５に記載の端末。