(57)【特許請求の範囲】
【請求項１】
１以上の通信ネットワークにおいて用いられ、コンポーネント及びコンポーネント連鎖のライフサイクルを管理するコンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、アプリケーションへプラットフォーム独立及びネットワーク独立のフレームワークを提供する処理装置であって、
上記コンポーネント調整ユニットにより管理され、プラットフォーム独立及びネットワーク独立の折衝及び再折衝プロトコルを用いて、ローカル及びリモートのリソース管理を調整するＱｏＳブローカユニットと、
上記ＱｏＳブローカユニットにより直接調整され、ネットワークリソース確保及び／又は割当メカニズムを抽出するネットワークリソースブッカユニットと、
上記ＱｏＳブローカユニットにより直接調整され、セッションを確立及び管理することによってセッションレベル詳細を抽出し、セッションライフタイム内においてより低いプロトコル層により生成されたあらゆるＱｏＳ違反信号をＱｏＳブローカ８に報告するセッションマネージャユニットと、
上記ＱｏＳブローカユニットに管理され、ユーザにより要求された許容誤差内のフロー同期を保証するために、それぞれがストリームに関連付けられた１以上のコンポーネント連鎖を管理する１以上の連鎖コーディネータユニットとを備えることを特徴とする処理装置。
【請求項２】
上記プロトコルは、ＱｏＳ折衝及び再折衝のためのピギーバックメカニズムを使用することを特徴とする請求項１記載の処理装置。
【請求項３】
上記フレームワークは、リソース用途に関してそれぞれ異なるＱｏＳレベルを有するアプリケーションクラスの組のうちの１つに各アプリケーションが割り当てられたアプリケーションモデルに基づいていることを特徴とする請求項１又は２に記載の処理装置。
【請求項４】
上記アプリケーションクラス間に逆方向互換性を提供するフォールバックメカニズムを有することを特徴とする請求項３記載の処理装置。
【請求項５】
上記連鎖コーディネータユニットにより調整され、ＣＰＵリソース用途を管理する１以上のＣＰＵマネージャユニットを備える請求項１乃至４のいずれか１項に記載の処理装置。
【請求項６】
上記ＣＰＵマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するＣＰＵリソースコントローラユニットを備える請求項５記載の処理装置。
【請求項７】
上記連鎖コーディネータユニットにより調整され、メモリリソースの用途を管理する１以上のメモリマネージャユニットを備える請求項１乃至６のいずれか１項に記載の処理装置。
【請求項８】
上記メモリマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するメモリコントローラユニットを備える請求項７記載の処理装置。
【請求項９】
上記連鎖コーディネータユニットにより調整され、ネットワークプロトコルリソースの用途を管理する１以上のネットワークプロトコルマネージャユニットを備える請求項１乃至８のいずれか１項に記載の処理装置。
【請求項１０】
上記ネットワークプロトコルマネージャユニットにリソース状態情報の検索及び制御を提供するネットワークプロトコルコントローラユニットを備える請求項９記載の処理装置。
【請求項１１】
上記連鎖コーディネータユニットにより調整され、マルチメディアリソースを管理する１以上のマルチメディアコンポーネントを備える請求項１乃至１０のいずれか１項に記載の記載の処理装置。
【請求項１２】
上記マルチメディアコンポーネントにプラットフォーム独立のリソース状態情報の検索及び制御を提供するマルチメディアコントローラユニットを備える請求項１１記載の処理装置。
【請求項１３】
１以上の通信ネットワークにおいて用いられ、上記１以上の通信ネットワークの１以上のノードの記憶手段に格納可能はソフトウェアとして、コンポーネント及びコンポーネント連鎖のライフサイクルを管理するコンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、アプリケーションへプラットフォーム独立及びネットワーク独立のフレームワークを提供する上記ソフトウェアであって、コンピュータを上記コンポーネント調整ユニットにより管理され、プラットフォーム独立及びネットワーク独立の折衝及び再折衝プロトコルを用いて、ローカル及びリモートのリソース管理を調整するＱｏＳブローカユニット、
上記ＱｏＳブローカユニットにより直接調整され、ネットワークリソース確保及び／又は割当メカニズムを抽出するネットワークリソースブッカユニット、
上記ＱｏＳブローカユニットにより直接調整され、セッションを確立及び管理することによってセッションレベル詳細を抽出し、セッションライフタイム内においてより低いプロトコル層により生成されたあらゆるＱｏＳ違反信号をＱｏＳブローカ８に報告するセッションマネージャユニット、
上記ＱｏＳブローカユニットに管理され、ユーザにより要求された許容誤差内のフロー同期を保証するために、それぞれがストリームに関連付けられた１以上のコンポーネント連鎖を管理する１以上の連鎖コーディネータユニットとして機能させるためのソフトウェア。
【請求項１４】
上記プロトコルは、ＱｏＳ折衝及び再折衝のためのピギーバックメカニズムを使用することを特徴とする請求項１３記載のソフトウェア。
【請求項１５】
上記フレームワークは、リソース用途に関してそれぞれ異なるＱｏＳレベルを有するアプリケーションクラスの組のうちの１つに各アプリケーションが割り当てられたアプリケーションモデルに基づいていることを特徴とする請求項１３又は１４に記載のソフトウェア。
【請求項１６】
上記アプリケーションクラス間に逆方向互換性を提供するフォールバックメカニズムを有することを特徴とする請求項１５記載のソフトウェア。
【請求項１７】
上記コンピュータを更に、上記連鎖コーディネータユニットにより調整され、ＣＰＵリソース用途を管理する１以上のＣＰＵマネージャユニットとして機能させる請求項１３乃至１６のいずれか１項に記載のソフトウェア。
【請求項１８】
上記コンピュータを更に、上記ＣＰＵマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するＣＰＵリソースコントローラユニットとして機能させる請求項１７記載のソフトウェア。
【請求項１９】
上記コンピュータを更に、上記連鎖コーディネータユニットにより調整され、メモリリソースの用途を管理する１以上のメモリマネージャユニットとして機能させる請求項１３乃至１８のいずれか１項に記載のソフトウェア。
【請求項２０】
上記コンピュータを更に、上記メモリマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するメモリコントローラユニットとして機能させる請求項１９記載のソフトウェア。
【請求項２１】
上記コンピュータを更に、上記連鎖コーディネータユニットにより調整され、ネットワークプロトコルリソースの用途を管理する１以上のネットワークプロトコルマネージャユニットとして機能させる請求項１３乃至２０のいずれか１項に記載のソフトウェア。
【請求項２２】
上記コンピュータを更に、上記ネットワークプロトコルマネージャユニットにリソース状態情報の検索及び制御を提供するネットワークプロトコルコントローラユニットとして機能させる請求項２１記載のソフトウェア。
【請求項２３】
上記コンピュータを更に、上記連鎖コーディネータユニットにより調整され、マルチメディアリソースを管理する１以上のマルチメディアコンポーネントとして機能させる請求項１３乃至２２のいずれか１項に記載の記載のソフトウェア。
【請求項２４】
上記コンピュータを更に、上記マルチメディアコンポーネントにプラットフォーム独立のリソース状態情報の検索及び制御を提供するマルチメディアコントローラユニットとして機能させる請求項２３記載のソフトウェア。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、移動マルチメディアミドルウェア、コンピュータネットワーク、分散型処理システム、サービス品質（Quality of Service：ＱｏＳ）、携帯型コンピュータ装置、ウェブブラウザ、ＱｏＳブローカ、ＱｏＳ適応化アーキテクチャ、ＱｏＳ折衝プロトコル、無線通信等に関連する処理装置及びソフトウェアに関する。
【０００２】
特に、本発明は、１以上の通信ネットワークにおいて用いられる処理装置及び１以上の通信ネットワークにおける１以上のノードにおけるメモリにロードされる通信ネットワーク用のソフトウェアに関する。
【０００３】
【発明が解決しようとする課題】
通信ネットワークにおいて、例えば移動端末装置等の間で通信を確立する場合、既存のアーキテクチャは、移動端末装置間のサービスの品質（ＱｏＳ）を様々な種類のアプリケーションにどのように管理させるかについて考慮していない。既存のアーキテクチャの多くは、モジュール式ではなく、完全に自立型のソリューションである。既存のアーキテクチャの多くは、ネットワークリソースの確保及び割当メカニズムについて、何らかの仮定を行う。変化するネットワーク及び演算環境（例えば、ＱｏＳ違反、リソース仕様状況の変化）へのアプリケーションの適応を取り扱うメカニズムについては、これまで、アプリケーション及び通信ライフサイクルの様々なフェーズを明確に区別せずに検討されていた。これまで、折衝プロトコルは、標準化されていなかった。
【０００４】
そこで、本発明は、上述の課題に鑑み、通信ネットワークにおける接続の確立において、相互動作性、モジュール性、構成可能性及び適応性を実現し、標準化可能な処理装置及びソフトウェアを提供することを目的とする。
【０００５】
【課題を解決するための手段】
上述の課題を解決するために、本発明に係る通信装置は、１以上の通信ネットワークにおいて用いられ、プラットフォーム及びネットワーク独立のフレームワークを提供し、コンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、相互適応性を実現するアプリケーションを備える。また、本発明に係るソフトウェアは、１以上の通信ネットワークにおける１以上のノードにおけるメモリにロードされる通信ネットワーク用のソフトウェアにおいて、プラットフォーム及びネットワーク独立のフレームワークを提供し、コンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、相互適応性を実現するアプリケーションを有する。
【０００６】
好ましくは、フレームワークは、ＱｏＳ折衝及び再折衝プロトコルを含むプラットフォーム及びネットワークに中立なアプリケーション適応化メカニズムの組を使用する。この場合、プロトコルは、ＱｏＳ折衝及び再折衝のためのピギーバックメカニズムを使用する。さらに、フレームワークは、モジュール式の進歩的手法に基づいて、既存のアプリケーションから相互適応性を実現するミドルウェアに基づく将来のより高度なアプリケーションに亘る異なる種類のアプリケーションに対応することができる。さらに、フレームワークは、リソース用途に関してそれぞれ異なるＱｏＳレベルを有するアプリケーションクラスの組のうちの１つに各アプリケーションが割り当てられたアプリケーションモデルに基づいているとよい。この場合、アプリケーションクラス間に逆方向互換性を提供するフォールバックメカニズムを有することができる。さらに、フレームワークは、好ましくは、連携して様々なリソースを利用し、所望の全体的ＱｏＳレベルを実現する異なる機能的な通信レベルを有する通信モデルに基づく。ここで、通信レベルには、アプリケーションレベル、セッションレベル、アソシエーションレベル及びストリームレベルが含まれる。
【０００７】
好ましくは、コンポーネント調整ユニットにより管理され、折衝及び再折衝プロトコルを用いて、ローカル及びリモートのリソース管理を調整するＱｏＳブローカユニットを設けるとよい。この場合、ＱｏＳブローカユニットにより直接調整され、実装方式に独立してネットワークリソース確保メカニズムを管理するネットワークリソースブッカユニットを設けてもよい。さらに、ＱｏＳブローカユニットにより直接調整され、実装方式に独立してセッションを確立及び管理するセッションマネージャユニットを設けてもよい。
【０００８】
さらに、好ましくは、セッションマネージャユニットを介して、ＱｏＳブローカユニットに管理され、それぞれがストリームに関連付けられた１以上のコンポーネント連鎖を管理する１以上の連鎖コーディネータユニットを設けてもよい。ここで、連鎖コーディネータユニットにより調整され、ＣＰＵリソース用途を管理する１以上のＣＰＵマネージャユニットを設けてもよい。さらに、ＣＰＵマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するＣＰＵリソースコントローラユニットを設けてもよい。
【０００９】
さらに、好ましくは、連鎖コーディネータユニットにより調整され、メモリリソースの用途を管理する１以上のメモリマネージャユニットを設けてもよい。ここで、メモリマネージャユニットにプラットフォーム独立のリソース状態情報の検索及び制御を提供するメモリコントローラユニットを設けてもよい。さらに、連鎖コーディネータユニットにより調整され、ネットワークプロトコルリソースの用途を管理する１以上のネットワークプロトコルマネージャユニットを設けてもよい。ここで、ネットワークプロトコルマネージャユニットにリソース状態情報の検索及び制御を提供するネットワークプロトコルコントローラユニットを設けてもよい。
【００１０】
さらに、好ましくは、連鎖コーディネータユニットにより調整され、マルチメディアリソースを管理する１以上のマルチメディアコンポーネントを設けてもよい。ここで、マルチメディアコンポーネントにプラットフォーム独立のリソース状態情報の検索及び制御を提供するマルチメディアコントローラユニットを設けてもよい。
【００１１】
本発明は、汎用フレームワークを提供し、これに対しエンドシステムアーキテクチャを開発することができ、このフレームワークにより、あらゆる種類の移動マルチメディア及び（一定の制限内で）旧式のアプリケーションにＱｏＳ及び移動検知性を与えることができる。詳しくは、本発明は、端末装置間のＱｏＳ折衝用のメタプロトコルとともに、技術的ソリューション（ミドルウェア）を提供する。この概念によりアプリケーションは、与えられたＱｏＳ契約に対するＱｏＳの変異及び／又は違反に対して柔軟に対処できるよう設計することができる。
【００１２】
【発明の実施の形態】
以下、本発明に係る処理装置及びソフトウェアについて、図面を参照して詳細に説明する。
【００１３】
まず、本明細書において用いる用語を表１に示す。
【００１４】
【表１】
0004615148.tif 000002
【００１５】
【表２】
0004615148.tif 000003
【００１６】
【表３】
0004615148.tif 000004
【００１７】
【表４】
0004615148.tif 000005
【００１８】
【表５】
0004615148.tif 000006
【００１９】
次に、本明細書において用いる略語を表２に示す。
【００２０】
【表６】
0004615148.tif 000007
【００２１】
現時点で、以下のような技術が知られている。これらは、本発明に密接に関係するものである。
【００２２】
【表７】
0004615148.tif 000008
【００２３】
本発明により解決される課題を表３に示す。各課題を後に参照するために、各課題に課題識別子（P_ID）を付す。さらに、表３では、各課題項目において最も重要な鍵となる性質を列記している。
【００２４】
【表８】
0004615148.tif 000009
【００２５】
ＯＳＩトランスポートレイヤ上では、異なるサービスインターフェイスを識別することができる。各インターフェイスは、特定の種類のアプリケーションに対して機能する。ＱｏＳ及び移動の状態に応じて可能なアプリケーションの種類を表４に示す。以後の説明では、アプリケーションの種類を参照するために、表４の右端の欄に示すインターフェイス識別子を用いる。
【００２６】
【表９】
0004615148.tif 000010
【００２７】
【表１０】
0004615148.tif 000011
【００２８】
【表１１】
0004615148.tif 000012
【００２９】
本発明は、上述した全ての種類のアプリケーションにおけるＱｏＳ及び移動性検知を実現するアーキテクチャを提供する。詳しくは、本明細書では、Ｂ．２及びＢ．３の種類のアプリケーションに関する技術的ソリューション（ミドルウェア）及びこれらのアプリケーションの種類と上の表に列挙されている他のアプリケーションとの関係を説明する。表５は、表３に列挙されている問題に対し、本発明が提供するソリューションの要約を示す表である。
【００３０】
【表１２】
0004615148.tif 000013
【００３１】
【表１３】
0004615148.tif 000014
【００３２】
オプションとして、各アプリケーションクラスをエージェントの組に関連付け、端末から端末（end to end）の調整を保証し、最大限の可能性を引き出すことができる。各エージェントは、表６に示すように、各逆方向互換性に対応できるように特化させることができる。
【００３３】
【表１４】
0004615148.tif 000015
【００３４】
【表１５】
0004615148.tif 000016
【００３５】
１．モジュール性
ここに提案するアーキテクチャは、次の２点に関して、モジュール性を有している。
・このアーキテクチャは、互いに互換性を有する、又は有さない様々な種類のアプリケーションに調和する。モジュール的手法により、開発者は、与えられたアーキテクチャを漸進的（progressively）に展開（deploy）することができる。
・ここに提案するミドルウェアソリューションは、コンポーネントモデルＡＰＩの概念の中心となる。ＱｏＳブローカは、それ自体１つのコンポーネントとなり得る。コンポーネントは、実行時に展開することさえできる（例えば、ＪａｖａＢｅａｎｓにより開発されたコンポーネントは、遠隔に存在する格納装置からダウンロードすることができる）。コンポーネントを取り扱うために、ここに提案するミドルウェアは、コンポーネント調整装置（Component Coordinator；以下、ＣＣという。）の概念の中心となる。ＣＣにより、ユーザアプリケーションは、コンポーネントを処理し、自らのライフサイクル（開発、構成、アクティブ化、非アクティブ化、廃棄）を制御することができる。詳しくは、コンポーネントは、互いに連鎖され（chained together）、それぞれの機能が結合され、これにより情報を所定の及び所望の手法で処理することができる。アプリケーション及び／又はＱｏＳブローカは、所定の刺激（stimulus）（例えば、コーデック変更）に即座に応答するために、実行時においても連鎖を変更することができる。
【００３６】
２．構成可能性
ここに提案するアーキテクチャは、次の２点に関して、構成可能性を有している。
・ＱｏＳイネーブル伝送インターフェイス（QoS-Enabled Transport Interface）は、特定のＱｏＳシグナリングプロトコルにマッピングするために構成することができる。例えば、ソケット式のＱｏＳイネーブル伝送インターフェイスは、リソース確保／割り当てシグナリングのために、ＲＳＶＰ及び／又はＤＳマーカを使用するよう構成することができる。この構成処理は、種類Ａ．１のアプリケーションに対してもトランスペアレントに実行することができる。
・コンポーネントモデルＡＰＩ内の各コンポーネントは、個別に構成することができる。種類Ｂ．２のアプリケーション及びＱｏＳブローカは、通常、ＣＣによりコンポーネントの構成を管理する。
−種類Ｂ．３のアプリケーションについては、ＱｏＳブローカは、ユーザプロファイル情報を考慮してコンポーネント連鎖及びより低いレベルのエンティティ（例えば、ＱｏＳシグナリング、ネットワークデータプロトコル等）の両方を構成する。
−ユーザプロファイル情報は、詳細事項の高レベル又は低レベルにおいて特定される。前者の場合、ＱｏＳブローカは、ＱｏＳパラメータマッピングを行う（すなわち、ユーザの高レベル要求をより低いレイヤ用の構成パラメータの組に変換する）。後者の場合（上級者モード）、ＱｏＳパラメータのマッピングは、部分的に行われるか、あるいは全く必要ない（ユーザの熟練レベルによる）。
−ユーザは、劣化パスとしても知られる追加的な構成情報を特定することもできる。各劣化パスは、予定されたとおりに所定のＱｏＳ違反の種類を特定するために使用できるように、代替的なＱｏＳパラメータ構成を考慮に入れる。
−ユーザが自らのプロファイルを容易に特定できるようにするために、参照構成を含むテンプレートを使用可能にするとよい。この場合、ＱｏＳブローカは、ユーザプロファイルデータベースに依存して動作する。
−ユーザプロファイル記述言語の候補としては、パロアルト（Palo Alto）のヒューレットパッカード研究所技術レポートＨＰＬ−９８−１０ ９８０２１０に記載（Hewlett-Packard Laboratories Technical Report HPL-98-10 980210）されている、スベンド・フロルンド（Svend Frolund）、ジャリ・コイスチネン（Jari Koistinen）による「ＱＭＬ：サービス品質仕様のための言語（QML: A Language/or Quality of Service Specification）」に開示されているＱＭＬがある。ここでは、ＱｏＳ契約は、インターフェイスに関連付けて定義されている。
【００３７】
３．適応化メカニズム
以下では、アプリケーションモデル及び通信モデルを提案する。各モデルについて、個別の適応化メカニズムを説明する。この章の最後に、総合的適応化メカニズム（aggregate adaptation mechanism）を説明する。
【００３８】
３．１  アプリケーションモデル
このモデルは、ローカルリソースに関するアプリケーションライフサイクルに焦点をあてる。リソースの例としては、中央演算処理装置（central processing unit：以下、ＣＰＵという。）、主メモリ、ネットワークプロトコル、処理的観点からアプリケーションを構成する各タスクのためのマルチメディア装置等がある。用法及びＱｏＳが保証されるべきである。しかしながら、多くの文献において指摘されているように、ネットワークにＱｏＳを提供しても、ユーザが所望する（及び料金を支払う）品質のレベルが必ずしも保証されない。
【００３９】
ＰＤＡ又は移動電話等の移動演算装置においては、通常、ローカルリソースは不足しがちである。この不足により、現在のアプリケーション及び／又は同時接続が制限された量のリソースの補償を開始するとすぐに、ＱｏＳ劣化が生じる可能性がある。
【００４０】
基本的には、アプリケーションを新たに開始する（以下、エントリという。）度に、この新たなエントリを受け入れるためにシステムがリソースをリシャッフル（reshuffle）する必要が生じることがあることを考慮に入れなくてはならない。
【００４１】
各アプリケーションの実行は、システムにとって、そして最終的にユーザにとって特別な重要性を有する。例えば、この概念は、所定のアプリケーションに属する各タスクのための実時間ＯＳにおける優先度及び期限（deadline）にマッピングすることができる。すなわち、リシャッフル処理は、既に割り当てられているエントリの重要性に対する新たなエントリの重要性を考慮に入れる必要がある。この情報及び他の情報は、アプリケーションＱｏＳ契約により、アプリケーションに関連付けることができる。この明細書では、ＱｏＳ契約の内容については、詳細には説明しない。本発明は、特定のソリューションを構築できるフレームワークを提供することを目的とする。
【００４２】
この処理は、集合重要性クラス（aggregate importance classes）の組に基づいている。これらのクラスは、（安価な）ＱｏＳ非保証クラス（no-QoS-assurance class）から（高価な）プレミアムＱｏＳ保証クラス（premium-QoS-enforcement class）までを範囲とする。
【００４３】
各アプリケーションは、処置のクラスに割り当てられ、及びクラスにより特定されたＱｏＳのレベルに基づいて、リソースに一時的に割り当てられる。
【００４４】
受入検査（admission test）においてリソースが使用できない場合、低いクラスに属するアプリケーションには、新たなエントリが参加できるようになるまで、より少ないリソースが割り当てられる。このフォールバック（この処理におけるフォールバックという用語は、表６に示す逆方向互換性のメカニズムを示すために使用した同様の用語とは別の意味で用いられている。）処理は、与えられたアプリケーションのクラスの１つ下のクラスから開始され、新たなエントリがリソースを使用できるようになるまで、順次下のクラスに対して継続的に実行される（新たなエントリに比較してより高い、又は同等のクラスを有する他のアプリケーションは、より低いクラスに降格されていることもある。この場合、新たなエントリは、これらのアプリケーションに割り当てられているいかなるリソースも使用する権利を有さない。現在のクラスに対して予備の使用可能なリソースが存在せず、割り当てられている全てのアプリケーションが新たなエントリに比較してより高い又は同等のクラスを有する場合、フォールバック処理は、さらに１つ下のクラスに対して繰り返し実行される）。
【００４５】
降格された、又はより低いクラスの各アプリケーションに対して、同様の処理が適用される。最下位のクラスに属するアプリケーションは、最終的により高いクラスのアプリケーションにリソースを占有されてしまう場合もある。このため、フォールバック処理は、カスケードメカニズム（cascade mechanism）を備える。
【００４６】
フォールバックメカニズムは、ハンドオーバーイベント（hand over events：詳しくは、後の章で説明する。）によりトリガすることもできる。
【００４７】
ユーザは、ＱｏＳ契約に加えてアプリケーション劣化パスを設けることにより、上述のフォールバックメカニズムを制御することができる。このような情報により、フォールバックメカニズムは、ユーザが望む方向に導かれる。
【００４８】
したがって、所定のクラスのアプリケーションは、より高いクラス又は同等のクラスの他のアプリケーションに影響を及ぼす。また、ユーザの希望によりアプリケーションを上のクラスに昇格させ、あるいは下のクラスに降格させることもできる。このようなユーザの要求は、適正なＡＡＡメカニズムにより調整（regulate）される。
【００４９】
３．２  通信モデル
１以上の相手への通信チャンネルを確立することを望むアプリケーションについて考察する。ここで「相手（peer）」という用語は、広義に用いられており、非対称のクライアント−サーバの状況をも含む。各相手は、同じ処理装置上で実行されているものであってもよく、遠隔の処理装置上で実行されているものであってもよい。後者の場合、ネットワークインフラストラクチャのリソース使用に関する制約を追加的に取り扱わなくてはならないという点を除いて、いずれの場合も同様に考えることができる。
【００５０】
包括的には、アプリケーションは、セッションの高レベルコンテキスト内の他の相手と通信を行うことができる。例えば、ビデオ会議アプリケーションは、セッション内の各会議を個別に管理することができる。
【００５１】
セッションは、より精密な通信の抽象化であるアソシエーション（association）に細分化される。上述の具体例においては、アソシエーションは、会議のレッグ（leg）、すなわちこの会議に参加する２つの相手間の連携を表す。
【００５２】
最後に、各アソシエーションは、物理的な接続にマッピングされ、あるいは情報フロー又はストリームの組にさらに分解される。この抽象化は、通常、マルチメディアアプリケーションに適用される。
【００５３】
セッション、アソシエーション、及びストリームは、それぞれＱｏＳ契約に割り当てられる。ユーザは、テンプレートＱｏＳ契約に示されているパラメータの特定の構成を選択し、これらを対応するＱｏＳユーザプロファイル（適応化フレームワークの章で詳細に述べる）に実現する。
【００５４】
３．２．１  セッションの確立
アプリケーションは、十分なローカル及びリモートのリソースが使用可能であれば、確立できる（セッションリソースの例は、セッションの優先度、関連するウィンドウの数、セッション制御メカニズムのために見積もられたメモリ消費量等がある）。例えば、小型の演算装置で制限無くセッションを実行しようとすると、メモリが不足したり、あるいはディスプレイなどの供給リソースが一杯になったりしてしまう。
【００５５】
アプリケーションモデルの章で説明した適応化メカニズムは、このフェーズにも適用できる。
【００５６】
さらに、通信を行う両者が所定のセッションを取り扱えるか否かを判定するために、折衝処理（negotiation process）を行う必要がある。本発明では、緩やかな手法（lazy approach）を提案し、すなわち、セッション折衝フェーズは、第１のアソシエーション確立まで延期される（アソシエーション確立の章参照）。この手法は、セットアップ時間及びネットワークトラフィックを削減することを目的とする。なお、セッションレベルにおいては、折衝処理は、このセッションに参加する両者に要求されることがある。さらに、セッション確立フェーズにおいては、この両者が識別されていないこともある。
【００５７】
いかなる場合も、セッションは、複数のアソシエーション確立時のセッション折衝の結果を調整する必要がある。例えば、ある相手は、与えられたセッションを要求されたＱｏＳで管理できないことがある。なお、各アソシエーションは、他のアソシエーションから独立していてもよく、強い関係を有していてもよい。例えば、前者のとしては、ビデオ会議等の状況があり、後者としては、オンラインゲーム又は分散型アプリケーション等がある。後者の場合、アプリケーション特有のポリシーが折衝処理全体を支配する（例えば、セッションの中断又は強制終了、及び各アソシエーションを単純に共通のＱｏＳ基礎レベルに降格させる等の処理）。
【００５８】
３．２．２  アソシエーション確立
この処理は、１以上の物理的接続を実現するものである。セッション内において、アプリケーションは、十分なローカル及びリモートのリソースに加え十分なネットワークリソース（ネットワークリソースについては、相手先が同じ演算ユニット内に存在する場合は適用されない）が使用可能な状態にあれば、アソシエーションを確立する。
１．受入検査（ＣＰＵ、マルチメディア装置、主メモリ）：十分なリソースがローカルで使用可能な状態にあるか否かを判定する。
２．フォールバックメカニズム：適応化メカニズムの章で説明したものと同様。このメカニズムはクラスに基づいている。
３．折衝：推定されたプロトコル−（リモートの相手に対しての場合はさらにネットワーク−）リソース間の用途、及び同意される劣化パスを含む。セッション確立の章で説明したように、セッション折衝は、このフェーズに含まれる（第１の物理的接続確立期間）。この折衝処理は、与えられた接続内で引き起こる可能性のあるあらゆる偶発的なストリームを考慮に入れなくてはならない（ストリームは、アプリケーション、セッション及びアソシエーションとともに、ＱｏＳに割り当てられている。）。このようなストリームは、演繹的に推測される。例えば、与えられたアソシエーションは、オーディオストリーム、ビデオストリーム及びデータストリームにより確立される可能性がある。この情報は、アソシエーション確立時に既知となる。
４．ＱｏＳシグナリング（リモートの相手先との通信の場合のみ）：相手先同士が折衝において合意した場合、使用可能なＱｏＳシグナリングメカニズム（例えば、ＲＳＶＰ及び／又はＤＳマーキング）を用いて、最終的にネットワークリソースが要求される。
【００５９】
アソシエーションの確立は、２つのフェーズに分割される。すなわち、第１に、アソシエーションを確立し、折衝を行うために、最前の接続可能性（best effrot connectivity）が用いられる。続いて、パーティ間でＱｏＳの共通の組が合意された場合、所望のＱｏＳレベルに対応するようリソースが割り当てられる。同様のメカニズムは、ＱｏＳ違反に対する対応処理にも適用される。
【００６０】
３．２．３  ストリーム確立
ストリームは、アソシエーションのライフタイム期間内において、ユーザの要求又は一時的なサービスの中断（disruption）（実行時及びハンドオーバーの章参照）からの回復により、偶発的に生成されることもある。この場合、受入検査、折衝及びアソシエーション確立の章で説明したＱｏＳシグナリングメカニズムを適用する必要がある。なお、セッション折衝は要求されない。
【００６１】
３．２．４  実行時及びハンドオーバーイベント
以下、セッションのコンテキスト内で、ＱｏＳ及び移動性の管理に使用するメカニズムを示す。
１．ＱｏＳ監視
２．ＱｏＳ強制
２．１．フロー管理（規制（policing）、成形（shaping）、同期等）
２．３．リソース制御（例えば、ネットワーク／ＣＰＵスケジューラに対して行われる。）
２．４．再折衝（例えば、ハンドオーバイベントの結果として）
このように、本発明により、適応化対制御の調整を行うことができる。
【００６２】
３．２．４．１  調整された適応化（Coordinated Adaptation）
適応化の調整とは、通信を行う両者が考慮すべき状況の変化（ＱｏＳ違反及び／又はリソース使用状況の変更）から調整可能に回復できるためのメカニズムである。この調整された適応化により、再折衝を実行する必要が生じる。したがって、調整された適応化の処理は、水平的処理（horizontal process）とみなすことができる。
【００６３】
本発明は、接続確立時において、通信を行う両者により合意されなくてはならない劣化パスに基づいて、再折衝ストラテジ（renegotiation strategy：以下、ＲＳという。）の概念を提供する。ＲＳは、再折衝の状況が生じたときに、通信を行う両者が従うべきポリシーを特定する。ポリシーには、以下の２つがある。
・予め計画されたシーケンス：変化する状況（例えば、ＱｏＳ違反）を記述する情報に基づいて、通信を行う両者は、同様の方針で、ＱｏＳをどの程度のクラスに降格させるかを知る。このように、再折衝処理は、潜在的に行われる。したがって、この処理を管理するために、ネットワークトラフィックを開始する必要はない。
・インデックスに基づく再折衝：通信を行う両者は、与えられたセッションを降格させるべきクラスを個別に見積もる。続いて、単に元の劣化パス項目への参照値の選択された組を単に示す再折衝メッセージが交換される。このように、この再折衝処理は、明示的に実行（すなわち、何らかのネットワークを必要とする）されるが、その一方で通信を行う両者は、与えられた状況における最良の劣化パスの選択において、より高い自由度を有する。例えば、ファジーロジックアルゴリズムは、変化する状況に対応するＱｏＳ関連のパラメータの再構成に対して効果的である。
【００６４】
３．２．４．２  制御
通信を行う両者のそれぞれは、ローカルの演算ユニット及び／又はネットワークにおけるあらゆる状況の変化に効果的且つ効率的に反応するために、特定の適応化メカニズムに頼る前に、ローカルで実行可能な全ての処理を行う。したがって、制御は、垂直的処理（vertical process）とみなすことができる。
【００６５】
ＱｏＳパラメータを与えられたｎ次元空間の要素として包括的に記述できるならば、相手は任意の制御理論に基づくメカニズムを用いて、この要素を中心とする所定の領域内に要素を強制的に配置することができる。
【００６６】
この処理は、例えば、アプリケーションモデルの章に記述されたフォールバックメカニズム及び／又は再構成コンポーネント連鎖（実行時及びハンドオーバイベントの章参照）により説明できる。
【００６７】
３．３  適応化フレームワーク
適応化フレームワークの全体を図１に示す。図１では、拡張ＵＭＬグラフィカル表示とともに、プロファイル（Profile）５ａ〜５ｄ、契約（Contract）６ａ〜６ｄ、契約種類７ａ〜７ｄが示されている。
【００６８】
ＱｏＳプロファイル５ａ〜５ｄは、与えられたインターフェイスにより与えられたＱｏＳ契約６ａ〜６ｄ（問題領域に固有であるが、実装から独立している（implementation-independent））の結合（binding）を特定する。この場合、インターフェイスは、アプリケーション自体及び／又はミドルウェアによりサポートされたＱｏＳ管理インターフェイスである。
【００６９】
上述の章で部分的に示したように、アプリケーション１は、セッション２の調整処理の実行を要求されることがあり、セッション２は、アソシエーション３の調整処理の実行を要求されることがあり、アソシエーション３は、ストリーム４の同期処理の実行を要求されることがある。
【００７０】
この再帰的依存スキーム（recursive dependency scheme）は、様々なＱｏＳプロファイル５ａ〜５ｄに反映する。詳しくは、同期制約（例えば、最大許容音声同期誤差等）のための測定基準（metrics）及び同期が損なわれたときにとるべき行動の種類（例えば、自動的な回復又はユーザによる操作を求める等）を示すポリシーが必要となる。
【００７１】
図２は、調整された適応化と制御メカニズムとの間の区別を明瞭にすることにより、上述した様々なメカニズムをより組織的な手法で要約して示す図である。
詳しくは、図２は、アプリケーションモデルの章で説明したアプリケーション１のみならず、セッション２、アソシエーション３及びストリーム４にも適用されるフォールバックメカニズムを示す図である。すなわち、上述した抽象化された要素は、様々な手法で（具体例に応じて）ローカルリソースを使用する。例えば、セッション２は、所定数のタスクに関連付けられ、各タスクは、ＣＰＵ及びメモリリソースを必要とする。
【００７２】
処理を効果的に行うために、ｎ番目のステップにおいて、ｎ＋１の抽象化された要素の推定された（又はデフォルトの）数のインスタンスが考慮されるように、受入検査及びフォールバックメカニズムが階層的に実行される。この分散的手法により、リソースは、ユーザに対して最小限で有意義な機能が提供できる場合にのみ効果的に割り当てられる。
【００７３】
例えば、リソースが制約されている移動装置において、少なくとも１つの接続を可能とするリソースも残されていない場合、ビデオ会議を開始しようとする処理を行うことは無意味である。このような予約メカニズム（booking mechanism）は、接続確立の速度の向上にも貢献する。
【００７４】
５  エンドシステムリファレンスアーキテクチャ（End System Reference Architecture）
図３は、既存のプロトコル及びここに提案するミドルウェア（表７参照）に関する、表４に示すアプリケーション用語を図式的に示す図である。
【００７５】
【表１６】
0004615148.tif 000017
【００７６】
【表１７】
0004615148.tif 000018
【００７７】
【表１８】
0004615148.tif 000019
【００７８】
【表１９】
0004615148.tif 000020
【００７９】
【表２０】
0004615148.tif 000021
【００８０】
５．  ＯＳＩの観点による本発明を適用したＱｏＳ適応化フレームワーク
この章の目的は、本発明に基づくフレームワークを完全なＯＳＩアーキテクチャに厳密にマッピングすることではなく、上述した概念と、ＯＳＩモデルの鍵となる性質との間の類似性を示すことにある。
【００８１】
ＯＳＩ規格の目的は、オープンシステム間の情報交換を定義することにある。相互に自由に連携できるシステムは、共通の目的を達成する。オープンシステムの鍵となる性質は、相互動作性（interoperability）及びアプリケーションの移動可能性（application portability）である。すなわち、オープンシステムは、共通の機能の組に関する折衝を行い、見かけ上共通に振る舞い、各システムに特有の内部特性を隠すことができる。
【００８２】
本発明を理解する背景となる情報として、以下、本発明を実現するにあたり重要である側面を中心として、アプリケーション、プレゼンテーション、セッション層に関するＯＳＩ概念を説明する。
【００８３】
５．１  ＯＳＩモデルのアプリケーション層−背景知識
図４は、ＯＳＩアプリケーション層の概観を高次元に示す図である。この層は、７層ＯＳＩアーキテクチャの最上位に位置する層である。したがって、この層は、エンドユーザに直接サービス、すなわちアプリケーション処理（Application Process：以下、ＡＰという。）を提供する。ＡＰ２０は、実際にはＯＳＩの概念の外側に存在し、ＯＳＩモデル内では、ＡＰ２０は、アプリケーションエンティティ（Application Entity：以下、ＡＥという。）として表現される。ＡＥ２１は、以下の要素により定義される。
・ＡＥ２１に対し、ＡＰ２０を代表し、したがって現実のシステムとオープンシステムとしての表現との間を結合するユーザエレメント（User Element：以下、ＵＥという。）２２
・機能モジュールとして定義される、論理的に相関関係を有するアプリケーションサービスエレメント（Application Service Elements：以下、ＡＳＥという。）２３，２４の集合
ＯＳＩアプリケーション層は、ＡＰレベルにおける通信をサポートするための機能をＡＥに提供する。この機能は、特定のアプリケーション及び／又は汎用ルーチン（general-purpose routines）用に設計されたプロトコルを介して実行される。
【００８４】
ＡＥの性質は、使用するＡＳＥを選択することにより決定される。これらの要素は、その要素単独では存在することができない。すなわち、ＡＥは、１以上のＡＳＥからなり、各ＡＳＥは、ユーザアプリケーションに代わって特定のタスクを実行する。この結果、アプリケーションサービスのアーキテクチャは、他のＯＳＩ層のアーキテクチャと比べて大きく異なるものとなる。実際、後者は、特定のサービスを提供するエンティティにより表現できるが、アプリケーション層は、ＡＳＥの組と、選択可能な複数のオプションとにより表現される。
【００８５】
詳しくは、各アプリケーションは、特定ＡＳＥ（Specific ASEs：以下、ＳＡＳＥという。）の組により特徴付けられる。ＳＡＳＥは、特別に定義され、設計の目的となるアプリケーションの典型的な機能（例えば、ＦＴＡＭ管理ファイル転送機能）を提供する。
【００８６】
さらに、複数の種類のアプリケーションに共通の機能を抽象化できる。この抽象化に対応するＡＳＥは、共通ＡＳＥ（Common ASE：以下、ＣＡＳＥという。）と呼ばれる。他のＡＳＥにサービスを提供するあらゆるＡＳＥは、ＣＡＳＥとみなすことができる。
【００８７】
手続的観点からは、ＡＰ間の連携は、論理的境界（logical bounds）を介して行われ、アプリケーションアソシエーション（Application Association）と呼ばれ、異なる処理ユニット内に配設された各ＡＥの対の間で確立される。アソシエーションを開始するＡＥは、アソシエーション指示側（Association Initiator）と呼ばれ、この対の他方のＡＥは、アソシエーション応答側（Association Responder）と呼ばれる。すなわち、アプリケーションアソシエーションは、２つのＡＥ間の関係であり、要求された参照構造を提供し、２つのＡＥを連携させる。
【００８８】
アソシエーションを確立するための手続きは、ＯＳＩプレゼンテーション層により提供されるサービスを用いて適正なアプリケーションデータユニット（Application Protocol Data Units：以下、ＡＰＤＵという。）を交換する処理を含む。このＡＰＤＵは、制御情報を伝え、ＡＥは、この制御情報を用いてアプリケーションアソシエーションを管理し、自らの機能を調整することができる。各アプリケーションアソシエーションについて、情報を交換する手法を定義する必要がある。この点において、ＡＥ間で使用される手続きの組は、与えられたアプリケーションアソシエーションにおけるアプリケーションコンテキストと呼ばれる。アプリケーションコンテキストは、与えられたＡＥアソシエーションについてＡＥが要求するあらゆる種類の情報である。例えば、アプリケーションコンテキストは、このアソシエーションに含まれる各ＡＥにより使用されるＡＳＥの組に関する記述を含む。
【００８９】
この点において、ＡＥ間の通信をセットアップするために協力する処理の定義を容易にするために、幾つかの抽象モデル（abstract models）が識別され、各抽象モデルは、与えられたアプリケーションコンテキスト用に既に定義されている機能を論理的にグループ化する。単一アソシエーションオブジェクト（Single Association Object：以下、ＳＡＯという。）は、特定のアプリケーションアソシエーションに対応する機能の抽象モデルである。ＳＡＯは、与えられたＡＥに属する１以上のＡＳＥから構成される。
【００９０】
ＳＡＯに属するＡＳＥは、ＳＡＯにより表されるアプリケーションアソシエーションの一部であり、これらのうちの１つは、アプリケーション制御サービスエレメント（Application Control Service Element：以下、ＡＣＳＥという。）でなくてはならない。このＡＳＥは、アプリケーションアソシエーションの確立、解放、中断等を取り扱う。
【００９１】
各ＳＡＯ内において、ＡＳＥ間のインタラクションを調整する手続きと、このＡＳＥ及びＯＳＩプレゼンテーション層との間のインタラクションを調整する手続きとを識別することができる。単一アソシエーション制御機能（Single Association Control Function：以下、ＳＡＣＦという。）は、上述の手続きを識別する抽象モデルである。ＳＡＣＦは、アプリケーションコンテキスト内で定義された規則の実行を表し、したがってＳＡＣＦの記述は、アプリケーションコンテキスト、特にＡＳＥ記述子内に事実上含まれる。
【００９２】
アプリケーションエンティティがさらなるアソシエーションに開かれている場合、これに対応して複数のＳＡＯを識別することができる。これらのＳＡＯは、異なるＡＳＥの組み合わせを含む。複数アソシエーション制御機能（Multiple Association Control Function）は、所定のＡＥにおいて幾つかの又は全てのアプリケーションアソシエーション間で何らかの調整が必要とされる場合に使用される。実質的に、ＭＡＣＰは、幾つかのアソシエーションに亘って、与えられたＡＥ内のＳＡＯのグループ間のインタラクションを管理する。すなわち、ＭＡＣＰは、様々なアソシエーション内のイベントの時間的シーケンス、これらの関係及び複数のアソシエーションの管理に有用な全てを管理する。
【００９３】
図５は、ＡＥの使用（すなわち、アプリケーションエンティティ呼出（Application Entity Invocation））を説明する図である。図５には、２つのアプリケーションアソシエーションが示されており、一方は、ＳＡＯ１の２つのインスタンス間のアプリケーションアソシエーションであり、他方は、ＳＡＯ２の２つのインスタンス間のアプリケーションアソシエーションである。いずれの場合も、ＭＡＣＦは、ＡＥＩ２内のＳＡＯ１及びＳＡＯ２により提供されるサービスの用途を制御する。図には示していないが、いかなるＭＡＣＦも用いない直接的なアソシエーションも可能である。
【００９４】
以下、ＡＳＥの具体例をまとめて示す。
・ＡＣＳＥ（アソシエーション制御サービスエレメント：Association Control Service Element）：アプリケーションアソシエーションの確立、解放、中断を取り扱う。
・ＦＴＡＭ（ファイル伝送アクセス及び管理：File Transfer Access and Management）：ＯＳＩコンテキスト内のファイル伝送機能を取り扱う。歴史的には、このＦＴＡＭは、最初に開発されたＡＳＥの１つであり、最も重要なアプリケーションの１つである。
・ＲＴＳＥ（高信頼度伝送サービスエレメント：Reliable Transfer Service Element）、信頼できる情報の伝送のための手続的要素を提供する。この機能は、ＯＳＩセッション層１を反映させたものであるが、バイトフォーマットではなくＡＳＮ．１の使用可能性を提供するものであり、これによりセッション層の複雑性を低減している。
・ＲＯＳＥ（リモート操作サービスエレメント：Remote Operation Service Element）：クライアント−サーバモデルに厳密には基づいていない、分散型アプリケーションのイベントをサポートする。
・ＣＣＲ（委任共存回復制御：Commitment Concurrency Recovery control）：分散型アプリケーションにおいて引き起こる調和（consistency）及び共存（concurrency）の問題を解決することにより分散型アプリケーションのを管理するよう設計されている。
・ＣＭＩＳＥ（共通管理情報サービスエレメント：Common Management Information Service Element）及びＳＭＡＳＥ（システム管理アプリケーションサービスエレメント：System Management Application Service Element）：いずれもＯＳＩコンテキスト内のネットワーク管理を取り扱う。いずれも、ＲＯＳＥに基づいている。
【００９５】
５．２  ＯＳＩモデルのプレゼンテーション層−背景知識
ＯＳＩプレゼンテーション層は、ＯＳＩアプリケーション層エンティティ間のセッションの確立、管理、通信の終了に関する処理を行う。ＯＳＩプレゼンテーション層の主な目的は、オープンシステムコンテキストにおいて連携する様々なアプリケーション間で生じる可能性のあるあらゆる統語上の差異（syntactical difference）を仮想化することにある。一方、ＯＳＩアプリケーション層の主な目的は、オープンシステム内のアプリケーション間の意味的差異（semantic difference）を仮想化することにある。すなわち、アプリケーションは、何についてどのように議論を行うかに関する共通の対話コンテキストを共有する。なお、共通の意味とは、共通の統語法の使用を事実上含んでいる。この層のもう一つの鍵となる性質は、データの暗号化であるが、この点については、本発明の趣旨から外れるため、詳細には説明しない。理論的には、暗号化は、７つのＯＳＩ層のいずれにおいても実行できるが、実際には、物理層、セッション層及びプレゼンテーション層が暗号化処理に適するものであると考えられる。この処理は、共通伝送統語法（common transfer syntax）又はデータの共通外部表現（common external representation）を用いて実現される。
【００９６】
ローカルの統語法における具体的なデータ構造は、抽象統語法（Abstract Syntax）を用いて記述されるデータ種類にマッピングされる。抽象統語法の例としては、ＡＳＮ．１標準規格がある。伝送統語法は、抽象統語法に適用され、これにより与えられた抽象データタイプ（一連の番号）に対応する値を得ることができる。
【００９７】
抽象統語法と伝送統語法の組は、プレゼンテーションコンテキストと呼ばれ、プレゼンテーション層により定義されて、その機能を実現する。実際には、プレゼンテーション層は、以下の２つの種類のコンテキストをサポートする。
・定義されたコンテキスト。これは、折衝処理により２つのユーザ及びプレゼンテーション層の間で合意されたコンテキストである。
・デフォルトコンテキスト。これは、プレゼンテーション層において、常に利用可能なコンテキストである。このコンテキストは、定義されたコンテキストが合意に至らなかった場合に使用される。
【００９８】
折衝処理を容易に行うために、各プレゼンテーションコンテキストには、プレゼンテーションコンテキスト識別子（Presentation Context Identifier：以下、ＰＣＩという。）が割り当てられる。ＰＣＩは、例えば、後に特別なコンテキストの参照値として使用できる整数値である。
【００９９】
例えば、ＡＥは、２つのＡＳＥからなる。各ＡＳＥは、相手側のＡＳＥと通信を行うための、自らの抽象統語法を定義できる。通常、これらの抽象統語法は、ＡＳＥにより異なる。混乱を避けるために、プレゼンテーション接続確立処理に置いて、１対のＡＳＥのそれぞれに関する２つの区別されたプレゼンテーションコンテキストが確立される。この区別は、各コンテキストを特定のＰＣＩによりマーキングすることにより実現される。
【０１００】
プレゼンテーション層は、他の機能のうち、プレゼンテーションコンテキストの折衝処理（プレゼンテーション接続確立時）及び再折衝処理（接続期間中）を取り扱うサービス及びプロトコルの組を任命する。
【０１０１】
接続確立時においては、定義されたコンテキストの組（Defined Context Set：以下、ＤＣＳという。）に関する折衝が行われる。接続の開始側は、まず、このＤＣＳにおいて、取り扱うことができる全てのプレゼンテーションコンテキストのリストを特定する。続いて、各コンテキストについて、ＰＣＩ及び抽象統語法が特定される。接続の開始側は、伝送統語法に関する項目は特定しない。接続の開始側により使用されているＯＳＩプレゼンテーション層は、実際にこの情報を提供する。プレゼンテーションエンティティは、ＤＣＳにおいてリストされた与えられた抽象統語法と互換性を有する、全ての可能な伝送統語法を加える。与えられた抽象統語法に対して使用可能な伝送統語法が存在しない場合、アプリケーション処理における例外が適用され、対応する項目（item）がＤＣＳから削除される。
【０１０２】
完全なＤＣＳ情報は、相手側のＯＳＩプレゼンテーション層に供給され、このＯＳＩプレゼンテーション層は、特定されている伝送統語法をサポートできるか否かを確認し、ＤＣＳ内にリストされている各プレゼンテーションコンテキストに関する以下の情報をローカルユーザ（応答側）に供給する。
・ＰＣＩ
・抽象統語法
・特定のプレゼンテーションコンテキストが受け入れられているか否か（受理又はプロバイダによる拒否）を示すフラグ
与えられたコンテキストが拒絶された場合、以下の理由のうちの１つが特定される。
・不明な理由
・抽象統語法がサポートされていない
・提案された伝送統語法のいずれも受理されていない
・ＤＣＳローカル限界に到達
応答側は、プレゼンテーションサービスプロバイダに対し、応答側がどのプレゼンテーションコンテキストをサポートできるかについて返答する。この情報を受けたプレゼンテーション層は、送信側の相手に対し、以下のような項目を返す。
・ＰＣＩ
・抽象統語法
・フラグ：受理／プロバイダ拒否を示すインジケータ
・選択された（固有の）伝送統語法
この情報は、開始側に供給され、折衝は終了する。これにより、ＤＣＳは、通信を行う両者のいずれもがサポートするプレゼンテーションコンテキスト（それぞれ自らに固有の伝送統語法とともに）のみを含むこととなる。
【０１０３】
この処理は、プレゼンテーション接続が有効な期間中において、何回でも繰り返すことができる。
【０１０４】
５．３  ＯＳＩモデルのセッション層−背景知識
ＯＳＩセッション層は、ＯＳＩプレゼンテーション層エンティティ間の通信セッションを確立、管理及び終了する。詳しくは、セッション層の主な目的は、ユーザ間のデータフローを構造化及び調整し、発生し得る失敗、例外的イベントを管理することにある。後者の目的を取り扱うために、セッションサービスは、確認点の概念（checkpoint concept）を用いる。確認点とは、２ユーザ間の接続の有効期間中に挿入される論理的マークである。失敗又は例外が発生した場合、確認点がマークされている接続状態の１つに引き戻して、与えられたイベントから回復することができる。
【０１０５】
ＯＳＩセッション層は、セッション接続を異なる手法で伝送接続（基底に存在するＯＳＩ伝送層により提供される）にマッピングすることができる。すなわち、一対一に対応させる手法、１つのセッション接続を複数の伝送接続に対応させる手法、複数のセッション接続を１つの伝送接続に対応させる手法等がある。伝送接続は、複数のセッション接続において再使用されてもよく、又は与えられたセッション接続に対して新たな伝送接続を確立してもよい。この伝送接続の割り当ては、ユーザのＱｏＳ要求に基づいて行われる。
【０１０６】
５．４  本発明を適用したＱｏＳ適応化フレームワーク
図６は、適応化フレームワークの章で説明され、ＯＳＩモデルのアプリケーション層、ＯＳＩモデルのプレゼンテーション層及びＯＳＩモデルのセッション層の章に示されたＯＳＩの概念に適合するＱｏＳ適応化フレームワークの構成を示す図である。以下では、種類Ｂ．３のアプリケーションをサポートする完全独立型のミドルウェアについて説明する。必要な変更を加えることにより、種類Ｂ．１及び種類Ｂ．２のアプリケーションにも同様の概念を適用することができる。
【０１０７】
ＱｏＳブローカ３０は、（ｉ）主なＱｏＳ適応化ロジックを具現化し、（ｉｉ）様々なエンティティを調整する（例えば、アプリケーションの管理、アソシエーション、セッション及びストリームの調整）。ＱｏＳ仲介装置３０は、それ自体１つのコンポーネントであり、したがって中央コンポーネント調整ＳＷユニットにより管理される。このユニットは、このアーキテクチャに適合する他の全てのコンポーネントを管理する。詳しくは、ＱｏＳブローカ３０は、外部コンポーネントであるＮＲＢ３１に依存し、ユーザは、このＮＲＢ３１に特定のＧＵＩ（このＧＵＩは、ＱｏＳシグナリングが使用できないがＱｏＳ構成が可能な種類Ａ．１及びＡ．２のアプリケーションにおける幾つかの制限とともに、いかなる種類のアプリケーションにも適用できる。）を介して直接アクセスできる。
【０１０８】
ＡＰ３２は、ユーザアプリケーションを表している。ＡＰ３２は、ミドルウェアを使用することができるが、ミドルウェアは、ＡＰ３２に対し、間接的にしか影響を及ぼすことができない。ミドルウェアは、アプリケーションモデルの章で説明したように、ＡＰリソースの用途を調整することによりＱｏＳ適応化を実行する。この意味において、ＡＰ３２は、ＡＥＩ３３と連携する。この連携は、ミドルウェア内でＡＰ３２を表現するＵＥ３４を介して実現される。ＵＥ３４は、優先度、クラス（アプリケーションモデルの章参照）及び（存在する場合）構成情報（例えば、メモリ要求）等、受入検査の実行及びフォールバックメカニズムに有用なＡＰ３２に関する情報を含む。さらにＵＥ３４は、ＱｏＳブローカ３０に直接制御されて、リスト内のオープンセッション（図面を明瞭にするため、図６では、１つのセッションしか示していない。）を調整する。
【０１０９】
通信モデルの章で説明したように、各セッションは、複数のアソシエーションに分割できる。このアソシエーションの組は、セッションマネージャ３５により調整され、したがってセッションマネージャ３５は、ＱｏＳブローカ３０に直接制御されて、ＭＡＣＦとして動作する。
【０１１０】
各アソシエーションは、ＳＡＯ３６、３７により表現される。連鎖コーディネータ３８（適応化フレームワークの章参照）は、ＱｏＳブローカ３０に直接制御されて、ＡＳＥを調整することにより（マルチメディアコンポーネントとリソースマネージャのように−エンドシステム参照アーキテクチャの章参照）、ＳＡＣＦとして動作する。詳しくは、連鎖コーディネータ３８は、与えられたストリームに最終的に関連付けられた複数の連鎖を処理する。すなわち、ＡＳＥは、ストリーム毎にインスタント化される。さらに、与えられたコンポーネントの高レベルなインターフェイスを表すスタブ（stubs）として実現できるコンポーネントもある。このレベルの間接的な手法により、アーキテクチャに多形的性質（polymorphism property）を与えることができる。すなわち、実際のコンポーネントの具現化（骨組み：skeletons）は、通常、コンポーネントスケルトンライブラリの一種として、ＯＳＩプレゼンテーション層内で取り扱われる。多くの場合、マルチメディアコンポーネントは、例えばエンコード、圧縮、暗号化機能等の典型的なＯＳＩ表現に関する処理を取り扱う。一方、この手法によってはモデル化できないマルチメディアコンポーネントは、例えばマルチメディア装置ドライバを取り扱うコンポーネントである。どの骨組みを使用するかの判断は、後述するように、拡張プレゼンテーションコンテキスト折衝処理の結果に依存する。
【０１１１】
このように、本発明は、ＯＳＩモデルとは異なるものである。すなわち、ＱｏＳ情報は、予め、最上位の層で折衝により得られ、折衝により得られた確立すべき物理的接続に固有のＱｏＳ要求として、ＯＳＩ伝送層及びより下位の層に伝えられる。
【０１１２】
リソースコントローラは、ＯＳコンテキストに実質上含まれいているため、図６では、図面を簡潔にするために、リソースコントローラを示していない。
【０１１３】
５．４．１  拡張プレゼンテーションコンテキスト折衝処理
この処理は、通信を行う両者間で追加的コンテキスト情報を交換するために、上述したプレゼンテーションコンテキスト折衝処理を改善したものである。詳しくは、抽象統語法（これは、幾つかの状況では、適用されないこともある。ＯＳＩモデルは、ここでは単なる参照モデルとして使用するものであり、ＯＳＩモデルの概念の全てが必要条件であるわけではない。）に加えて、通信を行う両者は、以下のようなＱｏＳ情報を交換する。
・使用すべきコンポーネントスタブのリスト
・アプリケーションＱｏＳプロファイル
・セッションＱｏＳプロファイル（セッションが使用される場合、デフォルトでは、１つのセッションが仮定される。）
・アソシエーションＱｏＳプロファイル（デフォルトでは、１つのアソシエーションが仮定される。）
・ストリームＱｏＳプロファイル（ストリームが使用される場合、デフォルトでは、１つのストリームが仮定される。）
アソシエーション及びストリームＱｏＳプロファイルは、プロトコルスタックリソースの用途に関する推定情報を含む。これらの推定値は、リソースコントローラにより提供される集中サービスとともに、各フロー及びリソースタイプに専用のリソースマネージャにより、算出される。ＱｏＳブローカは、実行時において、適応化メカニズムの章で説明した適応化メカニズムを用いて、これらの推定値を調整する。
【０１１４】
ＡＳＥ情報は、ＤＣＳに組織化される。ＰＣＩ、抽象統語法（要求される場合）、及びコンポーネントスタブ（必要とされる場合）は、相手側と通信を確立する必要がある各ＡＳＥに割り当てられる。例えば、通信を行う両者が様々な機種／種類の圧縮器を使用することができる場合、開始側は、所定の圧縮比を有するデータ圧縮器を選択できる。これらの圧縮器は、互いに完全な互換性を有していなくてもよい。すなわち、両者は、実際にどの圧縮器（すなわち、骨組み）を使用するかについて合意（すなわち、折衝）する必要がある。ＱｏＳプロファイルは、ＱｏＳプレゼンテーション層プロトコルデータユニットに単純に搬送され（ピギーバック：piggybacked）、ＤＣＳの前に配置される。セッション、アソシエーション、ストリームを相関させるために、各プロファイルは、図７に示すように、識別子に関連付けられる。
【０１１５】
説明を簡潔にするために、図７は、１つのセッション、１つのアソシエーション、１つのストリーム、及び１つのＡＳＥ記述からなる特定の状況を表している。包括的に言えば、これらの記述は、アクティブにされている実際のエンティティに基づいて重複的に設けられ、１データ構造内の折衝情報がグループ化される。これは、通常ＡＳＥに適用されるが、他の抽象化に拡張することもできる。
【０１１６】
開始側のために働くプレゼンテーション層は、ライブラリから伝送統語法（ＯＳＩモデルのプレゼンテーション層の章参照）及び特定された抽象統語法及びコンポーネントスタブにそれぞれ特化されたコンポーネントの骨組みを選択することにより、相手側に送るべき折衝情報を完成させる。相手側では、ＯＳＩプレゼンテーション層は、伝送統語法（存在する場合）及びコンポーネントの骨組み（存在する場合）を評価し、この結果得られた情報を応答側に伝える。応答側は、協働するＱｏＳブローカに案内され、様々な層（下位の層を含む）において、受入検査及びフォールバックメカニズム（アプリケーションモデルの章参照）が実行され、これに基づいて、開始側に応答情報が返答される。このスキームは、ＯＳＩモデルのプレゼンテーション層の章で説明したメカニズムと同様のメカニズムに基づいている。
【０１１７】
開始側が応答側のフィードバックに満足しなかった場合、折衝処理を繰り返すことができる。図９に示すように全てのステップにおいて、リソースは、パスに沿って割り当てられる（図９を詳細に説明する標準ＱｏＳ折衝プロトコルの提案の章参照。）。
【０１１８】
同様のメカニズムを再折衝処理に適用することができ、この場合、主な相異は、通信を行う両者間の通信リンクが既に確立されている点である。
【０１１９】
以上の提案は、ＱｏＳ要求の特定の組が一旦特定されると永続的に持続し、ＱｏＳブローカが調整可能な手法でシステム全体を単に調整することによりこの要求を満足させることができる理想的な状況を反映させたものである。
【０１２０】
現実の世界では、突然のＱｏＳ違反が発生し、その違反が大きいためにＱｏＳブローカの動作がずれてしまうこともある。このような場合、折衝情報に適正な劣化パス情報（適応化メカニズムの章参照）を含ませる必要がある。この追加的情報は、図７に示す手法（参照コンテキストを表す）と同様の手法により、追加的な情報の組として構造化することができる。劣化パスに属する項目を参照コンテキストに属する項目から区別するために、各項目（図７における記述）には、参照コンテキスト内の項目に対応する、数学的に相関された識別子を割り当てる。数学的関係は、適正な階層的ビットマッピングスキーム（hierarchical bit mapping scheme）を用いてもよく、他のソリューションを用いてもよい。本発明は、特定の関係を強制するものではなく、このソリューションは、具現化の手法に基づいて様々なものを選択できる。図８は、折衝情報に劣化情報を適用した具体例を説明する図である。
【０１２１】
適応化メカニズムの章で説明したように、再折衝は、単純な項目ＩＤの交換及び２つのＱｏＳブローカが同期する必要がある場合のみに限定される。デフォルトとして、ＱｏＳブローカは、劣化パス情報を同時に使用できるものであると仮定される。構成タイマの期限が超過したときのみ、監視されているＱｏＳは、（劣化された）ＱｏＳ要求に違反し、ＱｏＳブローカは、再折衝処理を開始し、この再折衝処理では、選択された項目ＩＤの組のみに関する折衝が行われる（この他の対応する情報は、接続確立時に既に折衝により合意されているものとする）。
【０１２２】
通信を行う一方が以前に折衝により得た情報を失った場合、又はユーザが自らの構成情報を変更した場合のみ、明示的な再折衝処理（参照として記述した折衝の場合と同様の処理）が実行される。このような明示的な要求を受け取ったＱｏＳブローカは、自動的に以前の情報を削除し、新たな折衝処理を行うように、再折衝処理を実行する。
【０１２３】
５．４．２  ＯＳＩプレゼンテーションに関する最後の説明
以上、本発明に基づくＱｏＳ適応化フレームワークについて、ＯＳＩプレゼンテーション層に関連させ、拡張された折衝能力とともに説明した。この概念は、（一定の限度において）ＯＳＩモデルに基づいて、フレームワークを形式化（formalize）するために導入された。
【０１２４】
実現のための観点からは、ＯＳＩプレゼンテーション層の機能は、ＣＯＴＳセッションプロトコル実装（COTS Session protocol implementations）（ＳＩＰに類似する）に部分的に含まれており、及びＱｏＳブローカコンポーネントに部分的に含まれている。詳しくは、ＱｏＳブローカコンポーネントは、以下に示す４つの主要なコンポーネントから構成することができる。
・ＱｏＳプロファイルデータベース管理システム
・ＱｏＳパラメータマッパ
・ＱｏＳ制御／調整適応化有限状態マシン
・ＱｏＳ（再）折衝エンジン
後者のコンポーネントは、折衝処理の背後の全ての論理を取り扱い、一方、ＳＩＰ等のセッションプロトコルにより折衝プロトコルを実現することができる。
【０１２５】
５．４．３  ユーザインタラクション
完全に自動的なメカニズムとして折衝処理を説明した。実際、ＱｏＳブローカは、高レベルの自動化を実現する。しかしながら、応答側が与えられたセッション、アソシエーション及びストリームの確立について、開始側に合意する際、人間による一定レベルの操作が求められることもある。
【０１２６】
応答側は、完全に自動的な装置（例えば、ビデオオンデマンドサーバ等）であってもよく、人間が呼出に答えるのみの装置（例えば、ビデオ会議アプリケーション）であってもよい。後者の場合においては、ユーザはＱｏＳブローカをプログラミングして、詳細事項（ＱｏＳに関連する事項）を考慮に入れさせ、高レベルな決定（呼出要求の受理、拒絶、変形等）を行うことができる。
【０１２７】
６．  標準ＱｏＳ折衝プロトコルの提案
本発明は、汎用ＱｏＳ折衝プロトコルの標準化を提案する。このプロトコルは、特定のネットワーク技術に制限されるものではない。実際、本発明は、新たな専用のプロトコルを提案するのではなく、例えばＳＩＰ等の既存のプロトコルに後述するような手続き及び情報エレメントをマッピングすることにより実現できるメタプロトコルを提案する。
【０１２８】
このため、通信を行う両者間の折衝シグナリングを表現し、折衝シグナリングを適切に実行するために、アソシエーション確立、ストリーム確立、肯定応答及び再折衝等の汎用論理メッセージ（以下、メソッドという。）を広く使用することができる。
【０１２９】
これらの汎用メッセージは、プロトコル固有の類似したメッセージにマッピングされる。この処理は、選択されたプロトコルの仕様が拡張可能な特徴を有している場合に有効である。これ以外の場合、適切な標準化規格内で適切な措置が行われ、ここに説明する情報エレメントが明示的にサポートされる。本発明の重要な側面は、実際のプロトコルメッセージが通常の情報とともに折衝情報（劣化パスを含む）を請け負うことである。この柔軟な手法により、明示的な折衝メッセージが必要とされず、プロトコル及びセットアップ（再折衝の場合は、回復）の複雑性から生じる遅延を低減することができる。
【０１３０】
さらに、単純な一対一（end-to-end）のシナリオを説明する。中間に介在するネットワークエンティティ（例えば、プロキシサーバ、ゲートウェイ等）の使用は、具体例に応じて変化するが、メタプロトコルの基本的概念を変化させるものではない。実際に、通信を行う装置は、ネットワーク（アクティブネットワークの場合）に組み込まれたＱｏＳブローカであってもよい。
【０１３１】
６．１  具体的シナリオの例
図９は、最も重要な３つのシナリオ、すなわちアソシエーション確立、ストリーム確立及び再折衝（この具体例では、ハンドオーバーイベントにより生じる）を示す図である。
【０１３２】
図９では、セッション確立シナリオを端末Ｂ（このシナリオでは、被呼出側として振る舞う）に関連させて示している。端末Ａ（呼出側）については、セッションは、以前の他の端末とのアソシエーション確立により既に確立されている。しかしながら、セッション確立の章で説明したように、各アソシエーションの確立処理において、セッションＱｏＳプロファイル情報を伝送することにより、新たなセッションの参加に関するセッション折衝が実行される。
【０１３３】
さらに、アソシエーション確立フェーズにおいては、セッションレベルの劣化パス情報が伝送される。
【０１３４】
いかなる場合も、応答メッセージ（acknowledgement messages）被呼出側の観点からの折衝処理の結果を示す。呼出側がこの結果に同意すると、リソースが割り当てられ、同意しない場合は、修正動作（ユーザとのインタラクションを含む）が実行され、再折衝処理と同様の交換されたメッセージが使用され、新たな接続が明確化される。図面を明瞭にするため、後者の状況は図９には示していない。
【０１３５】
以下の表は、メソッド及びメソッドを構成するビットを詳細に説明するものである。ここで使用される表記では、メソッドをそれぞれが折衝情報の特定の側面を記述する情報エレメントに分解している。さらに、情報エレメントは、最低レベルの情報を記述するトークンに分解される。トークンは、複数の情報エレメントが使用することができ、同様に後者は複数のメソッドにマッピングすることができる。シンボル「ｍ」は、必要条件である（mandatory）エレメントを示し、シンボル「ｏ」は、任意項目である（optional）エレメントを示す。特に、拡張プレゼンテーションコンテキスト折衝処理の章で説明し、図８に示すように、劣化パス情報は、参照エレメントに添付された追加情報としてモデル化され、対応する参照情報にリンクされる。
【０１３６】
【表２１】
0004615148.tif 000022
【０１３７】
【表２２】
0004615148.tif 000023
【０１３８】
【表２３】
0004615148.tif 000024
【０１３９】
【表２４】
0004615148.tif 000025
【０１４０】
【表２５】
0004615148.tif 000026
【０１４１】
【表２６】
0004615148.tif 000027
【０１４２】
【表２７】
0004615148.tif 000028
【０１４３】
具体例
本発明を適用した折衝プロトコルは、ＩＰ技術により実現することができ、インターネットエンジニアリングタスクフォース（Internet Engineering Task Force）により特定されるセッション開始プロトコル（Session Initiation Protocol）に含まれる。上に説明した手続き、メソッド、情報エレメント、トークンは、この場合、ＳＩＰ手続き及びメソッドにマッピングされ、ＳＩＰテキストに基づくメッセージ統語法に基づいてモデル化される。
【０１４４】
例えば、以下のようなマッピングに基づく実現例が可能である。
【０１４５】
【表２８】
0004615148.tif 000029
【０１４６】
本発明は、特に移動アプリケーション及びマルチメディアアプリケーション用のアプリケーションＱｏＳ適応化の分野における具体例に特化した将来の技術にも使用できるフレームワークを提供する。
【０１４７】
本発明の最も重要な側面を示す表である。
【０１４８】
【表２９】
0004615148.tif 000030
【０１４９】
【表３０】
0004615148.tif 000031
【０１５０】
詳しくは、本発明は、図３に示すように、端末装置におけるＱｏＳミドルウェアアーキテクチャを提供する。
【０１５１】
表１４は、このミドルウェアを構成するＳＷユニットの従属要素（dependencies）を示す表である。これらのユニットの詳細な記述を知るには、表１４内の対応するエントリを参照するとよい。
【０１５２】
【表３１】
0004615148.tif 000032
【０１５３】
【表３２】
0004615148.tif 000033
【０１５４】
【表３３】
0004615148.tif 000034
【０１５５】
【発明の効果】
以上のように、本発明に係る処理装置は、１以上の通信ネットワークにおいて用いられ、プラットフォーム及びネットワーク独立のフレームワークを提供し、コンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、相互適応性を実現するアプリケーションを備える。これにより、通信ネットワークにおいて、相互に適応化処理を行うことができる。
【０１５６】
また、本発明に係るソフトウェアは、１以上の通信ネットワークにおける１以上のノードにおけるメモリにロードされる通信ネットワーク用のソフトウェアにおいて、プラットフォーム及びネットワーク独立のフレームワークを提供し、コンポーネント調整ユニットにより上記通信ネットワーク内でＱｏＳ管理のためのコンポーネントを提供することにより、相互適応性を実現するアプリケーションを有する。これにより、通信ネットワークにおいて、相互に適応化処理を行うことができる。
【図面の簡単な説明】
【図１】本発明に基づくＱｏＳ適応化フレームワークの概要を示す図である。
【図２】本発明に基づく調整された適応化と制御メカニズムを説明する図である。
【図３】エンドシステム参照アーキテクチャの具体例を示す図である。
【図４】本発明に基づくＯＳＩアプリケーション層を示す図である。
【図５】単一のアソシエーション及び複数のアソシエーションの具体例を示す図である。
【図６】本発明に基づくＱｏＳ適応化フレームワークを形式的に示す図である。
【図７】本発明に基づく折衝により得られた情報の論理的構造を示す図である。
【図８】本発明に基づく折衝処理において交換される劣化パス情報を示す図である。
【図９】本発明に基づくアソシエーション／ストリームセットアップ及びハンドオーバの処理の具体例を説明する図である。
【符号の説明】
８  ＱｏＳブローカ、９  ＮＲＢ、１０  コンポーネントコーディネータ、１１セッションマネージャ、１２  連鎖コーディネータ、１３  ＣＰＵマネージャ、１４  メモリマネージャ、１５  ネットワークプロトコルマネージャ、１６  マルチメディアコンポーネント、１７  ＣＰＵリソースコントローラ、１８  メモリリソースコントローラ、１９  ネットワークプロトコルコントローラ、２０マルチメディアデバイスドライバ
【図１】
0004615148.tif 000035
【図２】
0004615148.tif 000036
【図３】
0004615148.tif 000037
【図４】
0004615148.tif 000038
【図５】
0004615148.tif 000039
【図６】
0004615148.tif 000040
【図７】
0004615148.tif 000041
【図８】
0004615148.tif 000042
【図９】
0004615148.tif 000043