(57)【特許請求の範囲】
【請求項１】
複数のプロトコール・レイヤ（L）及び前記プロトコール・レイヤ（L）とインターリーブされた複数のアクティブ・プログラミング・インターフェース（PI）を有するプロトコール・スタック（PS）であって、
前記各プロトコール・レイヤ（L）は複数の種々のレイヤ・クラスのそれぞれ１つのインスタンスであるレイヤ・オブジェクトにより定義される機能を持ち、
前記各アクティブ・プログラミング・インターフェース（PI）は複数の種々のインターフェース・クラスのそれぞれ１つのインスタンスであるインターフェース・オブジェクトにより定義される機能を持ち、スレッド・オブジェクト(複数)はプロトコール・スタック（PS）内のメッセージ・シーケンスをコントロールするための複数の種々のスレッド・クラスのインスタンス（複数）であり、
前記プロトコール・スタック(PS)はリコンフィギュラブルであるプロトコール・スタック（PS）であり、属性として、前記レイヤ・クラス、前記インターフェースクラス（複数）、前記インターフェースクラス(複数)、前記スレッドクラス（複数）のインスタンス(複数)をもつプロトコール・スタック・クラスを有し、
前記プロトコール・スタック・クラスは、更に、前記プロトコールスタックのランタイム中に、“前記１つのレイヤクラスの１つのインスタンスである前記1つのレイヤ・オブジェクト”を、“前記異なるレイヤクラスの１つのインスタンスである前記別のレイヤ・オブジェクト”に交換し、及び/又は、
前記プロトコールスタックのランタイム中に、“前記１つのインターフェースクラスの１つのインスタンスである前記1つのインターフェース・オブジェクト”を、“前記異なるインターフェースクラスのインスタンスである前記別のインターフェース・オブジェクト”に交換し、それにより、プロトコール・スタック・リコンフィギュレーション期間に、“１つの対応する前記プロトコール・レイヤ（L）”及び／又は“１つの対応する前記アクティブ・プログラミング・インターフェース（PI）”の機能を変更することを特徴とするプロトコール・スタック（PS）を有する通信システム。
【請求項２】
請求項１に記載されたプロトコール・スタックであって、前記各インターフェース・クラスは、前記全てのインターフェース・クラスに共通する一般インターフェース・クラス（GPI）から機能を継承することを特徴とするプロトコール・スタックを有する通信システムを有する通信システム。
【請求項３】
請求項２に記載されたプロトコール・スタックであって、前記各インターフェース・クラスは、前記それぞれのインターフェース・クラス特有の追加的機能を規定することを特徴とするプロトコール・スタックを有する通信システムを有する通信システム。
【請求項４】
請求項２又は請求項３に記載されたプロトコール・スタックであって、前記一般インターフェース・クラス（GPI）は複数の基本制御メッセージ・タイプを規定することを特徴とするプロトコール・スタックを有する通信システムを有する通信システム。
【請求項５】
請求項４に記載されたプロトコール・スタックであって、前記基本制御メッセージ・タイプは、サービス・リクエスト・メッセージ（SRM）、リクエスト応答（RR）、レイヤ状態情報（LSI）及び非同期事象通知（AEN）を含むことを特徴とするプロトコール・スタックを有する通信システムを有する通信システム。
【請求項６】
請求項１乃至５のいずれか１項に記載されたプロトコール・スタックであって、前記レイヤ・クラス、前記インターフェース・クラス及び前記スレッド クラスがクラス・ライブラリに格納され、クラス・ライブラリから選択されることを特徴とするプロトコール・スタックを有する通信システムを有する通信システム。
【請求項７】
請求項１に記載されたプロトコール・スタックであって、前記レイヤ・クラス、前記インターフェース・クラス及び前記スレッド・クラスが、クラス・ライブラリに格納され、選択され、前記プロトコール・スタック・クラスの実装が公衆インターフェースを備えることを特徴とするプロトコール・スタックを有する通信システム。
【請求項８】
請求項１乃至７のいずれか１項に記載されたプロトコール・スタックであって、前記アクティブ・プログラミング・インターフェース（PI）は、メッセージが、介在する（intervening）プロトコール・レイヤ（L）をバイパスする前記どの２つのアクティブ・プログラミング・インターフェース（PI）間をパスすることを許可するように構成されることを特徴とするプロトコール・スタックを有する通信システム。
【請求項９】
請求項１乃至８のいずれか１項に記載されたプロトコール・スタックであって、前記各レイヤ・クラスが、前記全レイヤ・クラスに共通する一般レイヤ・クラス（GLC）から機能を継承し、前記それぞれのレイヤ・クラス特有の追加的機能を有することを特徴とするプロトコール・スタックを有する通信システム。
【請求項１０】
請求項2乃至５のいずれか１項に記載されたプロトコール・スタックであって、前記レイヤ・クラスは、前記一般インターフェース・クラス（GIC）から機能を継承することを特徴とするプロトコール・スタックを有する通信システム。
【請求項１１】
請求項１乃至１０のいずれか１項に記載されたプロトコール・スタックであって、前記スレッド・クラスは、前記レイヤ・クラス及びインターフェース・クラスから機能を継承することを特徴とするプロトコール・スタックを有する通信システム。
【請求項１２】
ネットワークと、請求項１〜１１記載のプロトコール・スタック（PS）をそれぞれ組み込んだ少なくとも１以上の端末とを有する通信システムであって、前記各プロトコール・スタック（PS）が独立してリコンフィギュラブルである通信システム。
【請求項１３】
前記少なくとも１つ以上の端末はソフトウェア・リコンフィギュラブル無線である請求項１２に記載の通信システム。
【請求項１４】
通信システムのためのプロトコール・スタックを実装する方法であって、
前記プロトコール・スタックは、複数のプロトコール・レイヤ（L）と複数の前記アクティブ・プログラミング・インターフェースを有し、
前記アクティブ・プログラミング・インターフェース(PI)は前記プロトコール・レイヤ（L）とインターリーブしており、
前記各プロトコール・レイヤ(L)は、複数の種々のレイヤ・クラスのそれぞれの１つの１つのインスタンスであるレイヤ・オブジェクトにより規定される機能を有し、
前記各アクティブ・プログラミング・インターフェース(PI)は、複数の種々のインターフェース・クラスのそれぞれの１つのインスタンスであるインターフェース・オブジェクトにより規定される機能を有するものであって、
スレッド・オブジェクト(複数)はプロトコール・スタック（PS）内のメッセージ・シーケンスをコントロールするための複数の種々のスレッド・クラスであり、
前記方法は、属性として、前記レイヤ・クラス(複数)、前記インターフェース・クラス(複数)およびスレッドクラス（複数）のインスタンスを有する、リコンフィギュアラブルであるプロトコール・スタックをリコンフィギュアするためのものであり、
前記方法は、
前記プロトコールスタックのランタイム中に、“前記１つのレイヤクラスの１つのインスタンスである前記1つのレイヤ・オブジェクト”を、“前記異なるレイヤクラスの１つのインスタンスである前記別のレイヤ・オブジェクト”に交換するステップ、及び/又は、
前記プロトコールスタックのランタイム中に、“前記１つのインターフェースクラスの１つのインスタンスである前記1つのインターフェース・オブジェクト”を、“前記異なるインターフェースクラスのインスタンスである前記別のインターフェース・オブジェクト”に交換するステップを有し、それにより、プロトコール・スタック・リコンフィギュレーション期間に、“１つの対応する前記プロトコール・レイヤ（L）”及び／又は“１つの対応する前記アクティブ・プログラミング・インターフェース（PI）”の機能を変更することを特徴とする通信システムのためのプロトコール・スタックを実装する方法。
【発明の詳細な説明】
【０００１】
本発明は、プロトコール・スタック及びプロトコール・スタックを有する通信システムのような通信システムに関する。
【０００２】
本発明は、専用的ではないが特殊なアプリケーションに対し、所謂ソフトウェア・リコンフィギュラブル無線（ＳＷＲ：software-reconfigurable radio）、即ちソフト無線を提供するものである。
【０００３】
現在、プロトコール・スタックは、マルチプル・レイヤが互いの上に位置付けされ（即ち、成層方法（stratification approach））、各レイヤは他のレイヤに対し、内的機能及びサービス・アクセス・ポイント（ＳＡＰ）として知られている標準化されたインターフェースを使ったアプリケーションを提供するよう実施されている。
【０００４】
更に特定すれば、プロトコール・スタックは数個の単一プロトコール（レイヤ）の集合であり、各プロトコールは、或る機能を有し、或るタスクを行うものである。従来のものでは、プロトコール・フレームワークは複合メカニズムとしての成層方法を使用している。スタックの１レイヤにおけるプロトコールは、下位のレイヤの特性に鈍感である。各レイヤは“ブラックボックス”として扱われ、スタックにおいて発生する可能性のある機能冗長性を特定／バイパスするメカニズムを有しない。
プロトコール・スタックを文書化した例はＯＳＩＲＭ（Open Systems Interconnection Reference Model）であり、これは、次の７レイヤからなる。即ち、アプリケーション・レイヤ、プレゼンテーション・レイヤ、セッション・レイヤ、トランスポート・レイヤ、ネットワーク・レイヤ、データ−リンク・レイヤ、及び物理レイヤである。これらの各レイヤは、次の上位レイヤにサービスを提供し又は、直近下位レイヤからのサービスを予定するという完全なプロトコールを表している。この構造は“Computer Networks”(A.S.Tanenbaum,第３版、Prentice Hall,1996発行)に記述されている。同じ原則が、移動及び固定ラインの通信ネットワークに適用されている。そしてインターワーキング機能（interworking functionallity）は別々のプロトコールで定義される。レイヤ間の通信はSAPを通して行われる。これらSAPを通して、或るレイヤのプリミティブのセットは、次の上位レイヤで利用可能になる。サービスはレイヤ内で実装される操作（operation）を定義し、上位レイヤにより要求される。実際に、ＳＡＰはレイヤをカプセル化し、レイヤの複雑性を隠し、レイヤが提供する機能及び上位レイヤユーザーがレイヤから要求するものを一通りに記述するのに用いられる。しかし、ＳＡＰは静的で、柔軟性を欠く。ＳＡＰはプロトコール・スタックにおける柔軟な変化をサポートしないし、変更が必要となる時には、再標準化されることが必要である。
【０００５】
従来のプロトコール・スタックの欠点は、特に、ＳＷＲ実装に重大な障害をもたらす。ＳＷＲは、再プログラミング（例えば、“The Software Radio Architecture”、J Mitola III 、IEEE  Comm.Mag.May 1995 pp26-38 及び“The Layered Radio”M Butler et al, MILCOM, 1998, pp 179-179）を行って様々な異なる標準又はプロトコールを実装する万能無線(all-purpose radio)へ進化している。マルチモード・ターミナルは、可能な／既存の標準を含む“Velcro approach”を用いないものであるが、ＳＷＲは、該マルチモード・ターミナルに対する重要な代替手段として登場している。それ故、種々のサービス品質（QoS）要求及び種々のトラフィック特性を有する多くの多様なアプリケーションをサポートするために、次世代の移動端末とネットワークノードには、制御面でかなり豊富な能力が要求される。
【０００６】
SWR端末は、また、再プログラム可能でなければならない。このリコンフィギュレーション要請は物理レイヤだけに限られるものではない。要するに、仮にソフトウェア・ダウンロード、リコンフィギュレーション及び管理に対する能力が端末に備えられ、ネットワークのインフラストラクチャーによりサポートされるなら、将来のSWR端末、装置及びネットワーク・エンティティは、アプリケーションの必要性とユーザーの好みに対し効率的に対応することができる。しかし、これは既存の固定プロトコール成層方法では、できない。
【０００７】
本発明の１つの目的は、前記の問題の少なくともいくつかについて,問題を軽減することである。それは、従来のプロトコール・スタックで使用されている静的なSAPに置換わるアクティブ・プログラミング・インターフェース（プロトコール・プログラミング・インターフェース（PPI）／アプリケーション・プログラミング・インターフェース（API））を有するプロトコール・スタックを提供することにより実現される。
【０００８】
“Towards an Active Network Architecture”（D Tannennbaum et al, Comp.Commun.RevVol26,No2,Apr 1996）、“Active Networking Sources for Wired/Wireless Networks”(A Kulkarni et Al, Proc.INFOCOM99,Vol3,NY1999)及び“Composing Protocol Framework for Active Wireless Networks”(A Kulkarni et al IEEE Commun Mag Mar 2000)に記載されているように、アクティブ・ノードとインターフェースは、新たなマルチメディア・アプリケーションをサポートし、メディア・プロトコール（インターネット及びIN）と異なるシグナリング・システム（ＳＳ７,H３２３等）の間のインターワーキング機能の円滑化を提供して、特殊化又は統合化サービスの導入を促進する。同様に、ネットワーク管理は、更にインテリジェントになり、ネットワーク能力は、ネットワークのインフラストラクチュアのアップグレード化を必要とせず、ソフトウェアを変更することで、急速に進化している。このように、将来のリコンフィギュラブル移動ネットワークは、アクティブ・ノードとサービス・インターフェースの発展から恩恵を受けることが予想される。
【０００９】
プロトコールレイヤ間にプログラミング・インターフェースを導入するリコンフィギュレーションは、高級プログラミング言語（例えば、ジャバアプリケーションは異なるＡＰＩを使用する。ＡＰＩは、ランタイム（実行）時結合しているクラス・ライブラリーの一部である。これは、機能が、ＡＰＩへのアウトソースされ、アプリケーションが単にシーケンスを定義し、ＡＰＩ内の方法に渡すパラメータを決定することを意味する。）でアプリケーションを書くのと同様のやり方で、単一プロトコール又は全プロトコール・スタックを書く可能性を開くものである。ソフトウェア無線設計における他の重要な設計問題は、無線の本来のリコンフィギュレーション（即ち、ランタイム時リコンフィギュレーション管理、over-the -airダウンロード・プロトコール(“Terminal Reconfigurability-The Software Download Aspect” K Moessner et al IEE Int Conf On 3G 2000,Mar 2000,London UKに説明されている)及びセキュリティ関連を管理するリコンフィギュレーション管理）に関するものである。
【００１０】
この一般問題に対するもう１つの文書化されたアプローチは“Mobile Application Support Environment”（ＭＡＳＥ）である。これはＡＣＴＳプロジェクト“ On the Move”the Global Mobile API Framework, the Mobile Station Application Execution (MExE)GSM 02.57V70.0ETSI,1998 、及び、 IEEE P1520 ネットワークのためのアプリケーション・プログラミング・インターフェースのためのＩＥＥＥ標準の一部として開発されたものである。
【００１１】
本発明によれば、スタックは、スタックのリコンフィギュレーションをサポートすることが出来るアクティブ・プログラミング・インターフェースを組み込んだ構成を有し、このようなスタックを有する通信システムのためのプロトコール・スタックを備える。
【００１２】
アクティブ・プログラミング・インターフェースは、オブジェクトであり、オブジェクト指向設計原則に適合させる必要がある。
【００１３】
本発明は新概念を導入するものであり、この新概念とはプロトコール・レイヤ間のインターフェースを再定義するもので、プロトコール・スタック内の異種レイヤ間のインターアクションを分類し、プロトコールのリコンフィギュレーションをサポートする構成を備えるものである。これは、アクティブ・プログラミング・インターフェースを、プロトコール・スタック内のオブジェクトとして実装することにより、又、この新規のプロトコール・スタック構成を定義するオブジェクト指向設計方法を用いることにより達成することができる。標準化されたアクティブ・プログラミング・インターフェースは、端末及びネットワークにおいてプロトコール・スタックの標準的リコンフィギュレーションに必要な追加的自由度を導入する
【００１４】
本発明の実施例を図面に基づいて説明するが、これは一実施例であって、これに限定されるものではない。
説明する実施例はオープン・プロトコール・プログラミング・インターフェース・モデル及び、以下ＯＰｔＩＭＡと呼ぶアーキテクチャに適合するものである。
【００１５】
（最適なアプローチ）
ソフトウェアのリコンフィギュレーションは、ソフトウェア規定無線（software defined radios）を実現するのに不可欠の技術であるとされて来ている。主たる重要な機能はプロトコール・ソフトウェア‘on the fly’を交換する能力及び完全なプロトコール・スタックを再構成（reconfigure）する能力であり、これは様々な環境で必要となるものである。
【００１６】
ここに紹介する方法はプロトコール・スタック・リコンフィギュレーションのためのフレームワークを与えるものである。プロトコール・スタックは、クラス・ライブラリーを構成する一般“classes”のタームで記述される多数の機能エンティティティに分解される。これらは、リコンフィギュラブル・プロトコール・スタックを実装するために、ランタイム（実行）時にダイナミックに結合する。そして、フレームワークは、構成要素であるプロトコール（composible protocol）をサポートすることができる。単一のプロトコール・レイヤは、特定の機能を実装する一群のコンポーネントによって置換され得る。ソフト無線端末の内部で、“リコンフィギュレーション管理”ユニットが、コンポーネントの選択、削除／アップグレード及びＰＰＩとの通信を制御する。ＯＰｔＩＭＡ仕様によれば、定義されたＡＰＩ及びＰＰＩを使って、標準化され、財産権のあるプロトコール・スタックを、作成／実装するためのガイドラインが提供される。
【００１７】
（II．１  アプリケーション・プログラミング・インターフェース及びオブジェクト指向設計原則）
一般に、インターフェースは、数個の下部レイヤの隠れた機能へのアクセス・ポイントを表現するものである。このようなインターフェースの目的は、複雑な機能の実装をカプセル化すること、及びこの機能をユーザー／プログラマー／アプリケーションに対しこの機能へのアクセスを最も簡単な形で提供することである。
【００１８】
アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、一般的に、インターフェースが実際には如何に複雑に機能が実現されるか、その複雑さを隠しているものであるという、パラダイムに基づいている。これによれば、プログラマーは、各単一機能呼び出しに対し、どのようにインターフェースを使い、どのパラメータを渡せばいいかについてのガイドラインに従えばよい。アプリケーションは、これらＡＰＩ実装の範囲内で予め定義された機能の一連の呼び出しとなる。従って、このアプリケーション内での多くの複雑性は、下位レイヤに、これらプログラミング・インターフェースの下に隠される。ＡＰＩの利点の一つは、その拡張性と、部分的な、又は、完全な交換可能性（この交換可能性はアプリケーション・コードの完全な再書き込みを必ずしも要求しない）である。プログラミング・インターフェースの他の利点はスケーラビリティと、この構成の単純な使用である。
【００１９】
オブジェクト指向の基本アイデアは、システムの動作と特性を、例えば、“Object Oriented Analysis,by Coad et al, 2nd Edition,Englewood Cliffs,N J: Yourden Press,1991 ”に記載される個別エンティティ（discrete entities）に組み込むことである。また、このことは、システムの機能的に異なるパーツを特定することを要請する。一旦、エンティティ及び、これらエンティティの状態又は動作（機能functionality）間の内部関係が解析されると、クラスとして形成（formalisation）され、記述がなされる。オブジェクト指向は、数多くの基本原則に基づいている。例えば、クラスはその主要な１つである。更に概念として、“ObjectOriented Analysis and Design with Appliction”(Booch,2nd Edition,Benjamin/Cummings Publishing, Redwood City,CA 1991)に記載されているように、オブジェクト、アブストラクション、属性、操作／メソッド／サービス、メッセージ、カプセル化、継承（Inheritance）,ポリモーフィズム、再使用がある。例えば、大半のJFC(Java Foundation Classes)は、基本クラス‘オブジェクト’から（1乃至数レベルの階レイヤを経て）派生するクラスにおいて実装される。同様のことが、MFC（Microsoft Fooundation Classes）に応用できる。該MFCは、ウィンドーズ・プラットフォームに対するアプリケーション・プログラミングの基本実装クラスを有している。
【００２０】
（II.2  システム・アーキテクチャ）
ＯＰｔＩＭＡモデルの目的の１つは、フレームワークを導入することである。フレームワークによれば、ランタイム中のプロトコールの交換、及びレイヤ処理系にアクセスせずに、異なるプロトコール・スタック・レイヤのインターフェース間で直接シグナリング通信を可能にするようなインターフェースの積極的な関与を可能にする。このためには、システムに対し、多少異なる考え方をしなければならない。
このアプローチにおいては、プロトコールは、図１に示される‘プロインターフェース’及び‘プロレイヤ’に２分される。
【００２１】
プロインターフェースは、基本クラスから派生するクラス内で定義されるactive 実装である。ここで、エンティティの定義は、スタックにおける位置（position）による（プロインターフェース→２つのプロレイヤの間）。この基本クラスは全ての可能なプロインターフェースの一般機能（generic functionality）を定義する。更なる特化は、その後派生されたプロインターフェース・クラス内で達成される。オブジェクトとして実装されると、インターフェース（即ちプロインターフェース）は、追加機能及び追加アーキテクチャー複合体（architectural complexity）を引き渡す。
【００２２】
プロレイヤはアクチュアル・プロトコール実装であり、これはプロインターフェースを通してデータを取得し、これらデータを操作し、プロインターフェースを介してこれらデータをエクスポートするものである。プロインターフェース及びプロレイヤ・クラス内での機能／メソッドの実装はスレッド・オブジェクト（thread-object）により管理される。このような構成は、ランタイム中、古典的なプロトコール・スタックに代えて、フレキシブルなスタックリコンフィギュレーションを可能にするという、高度に柔軟なプラットフォームを提供する。換言すれば、スレッド・オブジェクトは、全てのプロレイヤ及びプロインターフェースに亘って、メッセージ転送と操作を管理するクラスの実装を行う。
【００２３】
図２に示されるように、到着すると、スレッドは、完全プロトコール・スタック内でメッセージとその処理に対して責任を引き受け、これらメッセージのレファレンスをその宛先に渡す。
【００２４】
（II.３  クラス・アーキテクチャ）
図３には、プロトコール・スタックの‘機能分割（functional decomposition）’が示されている。該スタックは、オープン・プロトコール実装のための基本的エンティティから合成されるものである。
【００２５】
下記の４つの異なるクラス・タイプが特定される。
１．  レイヤ・クラス（Ｌ−クラスがプロレイヤを定義する）が、プロトコール・スタック内で（即ち、物理レイヤの（Ｐ−Ｌ）−，リンク・レイヤの（ＬＣＬ）−，ネットワーク・レイヤの（ＮＣＬ）−及びシグナリング・アプリケーション（ＢＳＡ）−機能）単一プロトコールの機能を表す。図４に示したように、レイヤ・クラス（プロレイヤ）は、一般（プロ）レイヤ・クラスから機能を継承する。
【００２６】
２．  プログラミング・インターフェース・クラス（ＰＩ−クラスはプロ−インターフェースを定義する）は、プロトコール（Ｌ−クラス）間の各種プログラミング・インターフェースを表す。ＰＩ−クラスは、基本クラス（ＧＰＩ）で定義される一般的プリミティブを特定し、実装するメソッドから構成される。クラスの構成及びプリミティブの記述は、図５と図７にそれぞれ示されている。ＰＩクラスはイベント（即ち、数個のプロトコールからのメッセージ）を検出し、適切なスレッドの実装にトリガーをかける。
【００２７】
３．  スレッド・クラス（Ｔクラス）は予め定義した手順（例えばコネクション、モービリティ、無線源又はＱｏＳの管理−シグナリング）を実装する。図６に示されているように、他の、定義されていない、標準化されていないシグナリング手順はカスタム化されたスレッド・クラス、即ち（ＳＳＴ）内で実装される。メッセージ列の実装に加えて、スレッドも、完全なプロトコール・スタックの柔軟性を高める。シグナリング手順を実装するためにスレッドを使用すると、プログラマーが、数個のシグナリング手続きを並列に実装することができる。この特徴は、１点−多点通信に関し有利である。スレッド・クラスは一体化され、PI及びＬクラスにおいて定義されたメソッドを用いる。
【００２８】
４.  プロトコール・スタック・クラス（ＰＳクラス）は完全なプロトコール・スタックの実装を定義する。種々の旧式スタック（例えば、ＧＳＭスタック）は、標準を実装するための適当なクラスを含む特定の構成子（constructor）を使う。他方では、他のスタックは自由に定義することが出来る。ＰＳクラスは、プロトコール・クラス・ライブラリー内で公衆がアクセスできる唯一のクラスである．更に、図８に示すように、ＰＳクラスは、Ｌ，ＰＩ又はＴクラスがランタイム中に交換される時に、プロトコール・リコンフィギュラビリティ（再構築可能性）を管理する。図示の通り、スレッド・クラス（ＳＳＴ）はＰＩ及びＬクラスで定義されたメソッドを使う。
【００２９】
要約すれば、Ｌ，ＰＩ及びＴクラスは、プロトコール・スタックの能力、メソッド及び性質を定義し、他方、ＰＳクラスはこれらクラスを実装し、又、プロトコール・スタック構造を定義する。
【００３０】
（II．４  設計ガイドライン）
ＯＰｔＩＭＡは、前記クラス及び一組の設計ルール（該ルールは、どのようにクラスと完全なプロトコール・スタックを実装するかを定めるものである）に基づく。プロトコール・スタック実装の基礎は、図12A及び図12Bに示されるコード−スケルトンである。
１つのプロトコール・スタック内で、‘プロトコール・スタック’クラスは一般インターフェースをエクスポートする唯１のクラスである。それはL,PI及びTオブジェクトを実装し、プロトコール・スタックの構成を定義するものである。アーキテクチャは、全体として、異なるインターフェースと異なるレイヤクラスの両方の階層構造を定義するために継承（inheritance）を使う。従って、それは、プロインターフェース及びプロレイヤをそれぞれ派生するために、一般的インターフェース・クラス及び基本プロトコール・クラスを使用する。
【００３１】
（II．５プロトコール・スタック及びスレッド・クラス）
クラス（ＰＩ，Ｌ，Ｔ）の３グループが、プロトコール・スタック・クラスのインスタンスによってインスタンス化され、実装され、管理される。従って、このＰＳオブジェクトは、完全なプロトコール・スタックを定義する。機能グループ（スレッド、インターフェース及びレイヤ）の１つの中でクラスはクラス・ライブラリーに位置している。各クラス・ライブラリーは、特殊な（派生の）クラスの或るグループのために機能を提供する。図３は、プロトコール・スタック及びそのクラス・ライブラリー内におけるクラスの依存関係及び‘論理的位置’を示す。スレッド・クラスは、プロトコール・スタック中を通るメッセージを実際に管理するエンティティである。スレッド・クラスは単一のメッセージ・シーケンスを処理するために使用される（即ち、各スレッドは１シーケンスを管理する）。
【００３２】
（III ．プロトコール・レイヤ及びインターフェースの合成）
プロトコール・スタック機能をプロレイヤ及びプロインターフェースに分離することは、プロトコール・スタックに対して新たなパラダイムが形成される。そこでは、機能の分散がオープン・プロトコール・プログラミング・インターフェースにより容易になる。図示された実装では、ＯＰｔＩＭＡアーキテクチャは５つのレイヤから構成されており、各レイヤはそれ自身のタスクと機能を有している。‘分解された’プロトコール・スタック（プロレイヤ、プロインターフェース及びスレッド）内の全てのエンティティは、分離クラス（separate classes）として実装される。プロレイヤ・クラス（Ｌクラス）は、そのプロトコール（レイヤ）の属性を含んでおり、対応するプロレイヤから（及びに関連して）得られる情報を格納するために使用される。Ｌクラスのメソッドは入力する情報を処理し、適正な応答を生成し、続くシーケンスを開始するために使われる。この実施レイヤにおいては、レイヤクラス及びその機能は以下の通りである。
物理レイヤ（モデム、チャネルアクセス、ＦＥＣ，暗号化等）
リンク・レイヤ制御（リンク制御）
ネットワーク制御レイヤ（制御メッセージ・ルーティング）
シグナリング・アプリケーション・レイヤ（接続制御、ソース及びモービリティ管理シグナリング）
アプリケーション・レイヤ、ＡＰＩ仕様に適合するアプリケーション
【００３３】
（III ．１アクティブ・プログラミング・インターフェース）
プロレイヤはプロインターフェース（ＰＩ）により分離され、隔離される。これにより、交換可能性と拡張可能性（ランタイム中のプロトコール実装の）が確保される。この意味で、プロトコールは、プロレイヤに対し、レガシー（旧タイプ）・プロトコールである。これに対し、プロレイヤは、ＯＰｔＩＭＡ内でのレガシー（そして財産権の可能性を持つ）プロトコール機能の実装である。適当なＰＩが定義され（図５のクラスアーキテクチャを参照）、プロトコール実装（プロレイヤ）間に導入される。
プロインターフェースはオープン・プロトコール−プログラミング・プラットフォームを提供する。プロインターフェースは、シグナリング・メッセージの相互交換を可能にし、プロトコール・レイヤ・クラスへアクセスを渡す。この実施例では、４つのインターフェース・クラスが完全プロトコール・スタックを実装するために定義される（図５参照）。
ＰＰＩ１２    （物理レイヤとリンク・レイヤ制御との間）
ＰＰＩ２３    （リンク・レイヤ制御とネットワーク制御レイヤとの間）
ＰＰＩ３４    （ネットワーク制御レイヤとシグナリング・アプリケーション・レイヤの間）
ＡＰＩ        （アプリケーション・プログラミング・インターフェース）
【００３４】
プロインターフェースは一般インターフェース・クラス（ＧＰＩ）から派生したもので、プリミティブとして知られている制御メッセージの４つの基本タイプを定義する。プリミティブのタスクは、イベントについて各プロレイヤに通知し、プロレイヤとトリガー・メソッド（該メソッドは、これらプロレイヤ・クラスに実装される）との間の変数に対し新しい値を渡す事である。図７を参照すると、これら４つのプリミティブ・タイプは以下の通りである。
サービス・リクエスト・メッセージ（ＳＲＭ）：典型的には非永続的な即時動
作を実装する非同期プリミティブ。ＳＲＭに対する流れの方向は上位レイヤか
ら下位レイヤへである。
リクエスト応答（ＲＲ）：永続状態又は長期間計測プリミティブ。
ＲＲに対する流れの方向は下位レイヤから上位レイヤへである。
レイヤ状態情報（ＬＳＩ）：永続状態プリミティブ。ＬＳＩに対する方向は、
上位レイヤから下位レイヤへである。
非同期イベント通知（ＡＥＮ）：最新の、典型的には非永続的イベントをレポ
ートするプリミティブ。ＡＥＮに対する流れの方向は常に下位レイヤから上位
レイヤへである。
【００３５】
オブジェクト指向のプログラミング技術の開発に当たり、各プロインターフェース・クラスは、ＧＰＩと呼ばれるスーパークラスから一般機能を継承する。この‘親’クラスは、分離エンティティとして、実装プロトコール・スタックの一部ではない。しかし、それは、図９に示すように、全ての（派生された）ＰＩに対し、最小アクセス・インターフェース（即ちプリミティブ）を独占的に定義する。全般的アーキテクチャ上のフレームワークとの関連でアクティブ・インターフェース・オブジェクトのオブジェクト指向構成は、追加的特徴の実装を可能にする。即ち、（アクティブ）プロインターフェースは、アプリケーション開発のために、メッセージを渡し、共通シグナリングとデータAPIを容易にするために、代替媒介物（alternative medium）を提供する。
【００３６】
図１０に示されているように、アクティブ・インターフェースは以下の２通りの方法によりプロレイヤ内で属性へのアクセスを提供するために使用される。：連続的方法（シリーズA）及び非連続的方法（シリーズB）。シリーズBにおいては、プロレイヤNCLからの属性は、PPI及びAPIプロインターフェースを通して、これら属性を必要としないBSAプロレイヤを飛び越え、アプリケーション・レイヤに供給される。
【００３７】
このアーキテクチャの利点は、OPtIMAが異なる通信ネットワークで使用されるとき明らかになる。アプリケーションのためのシグナリング・インターフェースは、実装プロトコール・スタックとシステムのトランスポート手段とから独立しており不変である。目標のシグナリング・システムへの適応は適当なプロトコール（プロレイヤ）において行われ、実装中柔軟に交換され得る。
【００３８】
（III ．２  アーキテクチャの全般的な実装）
L及びPIクラスは、オープン・プログラマブル・プロトコール・インターフェースに基づくプロトコール・スタックを実装する２つの主要ファミリ・グループを形成する。しかしながら、シグナリング・シーケンスを制御し、周期的なタスクを処理し（例えば、最下位レイヤにおけるチャネル測定）、外部トリガーに応答する際に必要な機能も備えねばならない。
【００３９】
これらのタスクを行うために、スレッド・クラス（Tクラス）のファミリが導入された。実装に当たり、それらは、現行メッセージ処理を実装するために、Jａｖａ(登録商標)のマルチスレッド特徴を用いる。Ｊａｖａを実装プラットフォームとして選択した。それは、Ｊａｖａの特徴として、ダイナミックな結合とプラットフォーム独立性があるからである。しかし、Ｔクラスは他の機能を定義しない。むしろ、Ｔクラスは、Ｌ（及びＰＩ）クラスで定義されたメソッドにアクセスし、これらクラスの適当な機能を呼び出す。スレッドの優先性（従ってメッセージ・シーケンスの実装優先性）は、スレッドのインスタンス化の期間に定義される。
【００４０】
プロトコール・スタック・クラス（ＰＳクラス）は、全プロトコール・スタックを表す。このクラスの属性は他の（前記した）全てのクラスのインスタンスである。このように、ＰＳクラスは、Ｌクラスの機能と情報を用い（exploit）、ＰＩクラスで定義したプリミティブを使用し、インスタンス化されたＴオブジェクトのタスクの実装を制御する。これは、ＰＳクラスのインスタンスが、要求されるオブジェクトを実装することにより、所望のプロトコール・スタック機能を渡すことを意味する。適当なＰＳクラスの構成要素（constructor）は標準プロトコール・スタック（これら標準のためのレイヤクラスが利用可能であることを条件として）を実装するために使用することが出来る。この構成を使用すると、プロトコール・スタックは、適当なクラス（プロレイヤ及びスレッド）を交換することにより、どのような要求にもダイナミックに適応することができる。
【００４１】
次のクラス関係は、アーキテクチャの複雑性を表す（図11参照）。
【００４２】
ＬクラスはＰＩクラス定義に依存する。：Ｌオブジェクトは、上位又は下位レイヤと通信するためにＰＩクラスのプリミティブにアクセスできるが、一方、ＰＩクラスはＬオブジェクトにおいて格納された情報へのアクセスを提供するか、又は、この（Ｌ）オブジェクト内で実装されるメソッドをトリガーする。
【００４３】
Ｌ及びＰＩクラスはＴクラスに依存する。：Ｔオブジェクトは、予め定義したタスクを実行するために、適当な属性並びにＬ及びＰＩオブジェクトのメソッドを使うことが出来る。
【００４４】
ＰＳクラスはＬ、ＰＩ及びＴオブジェクトを属性として持つ。：ＰＳオブジェクトはこれらオブジェクトにおいて定義された機能及び情報を使うことができる。
【００４５】
ＴクラスはＰＳクラスに依存する。：ＰＳオブジェクトはその主なメソッドにおいて様々なスレッドの開始と停止を制御するが、Ｔオブジェクトは、単に、タスク実装に責任を有するのみである。図１１にこれを示す。
【００４６】
全てのクラスはクラス・ライブラリに組立られている。クラス・ライブラリは、どのようなネットワーク・エンティティに対しても、要求されるシグナリング機能を提供する。何故クラスをパッケージとしてグループ化するかの理由は、セキュリティに基本レベルを設けるからである。ＰＳクラスを宣言することにより、他のオブジェクトは、どのような他の非関連のオブジェクトに対しても、（理論的には）不可視（invisible）になり、アクセス不可になる。
【００４７】
Ｔオブジェクトは、直接ＰＳオブジェクトの主たるメソッドにおいて用いられるが、L、ＰＩ及びTオブジェクトは、ＰＳクラス内で属性として使用される。そして、これら属性はインスタンスであり、プロトコール・スタックのメンバーとして適当なオブジェクトを定義する。例えば、ＰＳオブジェクトのレファレンスはLクラスのメソッドにおけるパラメータとしてよく用いられる。このように、仮にLオブジェクトのメソッドが呼び出されたならば、オブジェクトは、同一のＰＳオブジェクトに属するＰＩオブジェクトを特定し、それら属性及びメソッド（即ちメッセージ）を使用する。
【００４８】
図９にこれを示す。プロトコール・スタックに対する２つの操作モードはシグナリング／メッセージ・シーケンスをトリガーする。これらは次の２つである。内部モード（即ち、ＰＳオブジェクトは、外部トリガーでは無く、タイムアウトによりスレッド実装を開始又は終了する）又は外部モード（例えば、アプリケーション又は物理レイヤで生じるイベント）。結果的に、これら２つの操作モードは適当なスレッドのインスタンス化（instantiation）又は終了に導く。
【００４９】
このアーキテクチャ面からのアプローチの柔軟性は一般ＰＩの導入に基づくものであり、数個の同時発生スレッドを使用することにより更に柔軟性は高められる。一般ＰＩはLオブジェクトにアクセスし、Tオブジェクトをサポートするのに必要な手段を渡すもので、異なるプロトコール・スタック標準をサポートし、実装するために必要な柔軟な構成を提供する。ＰＳの機能エンティティ間のプリミティブの一般の組は、不変である（例え新規なプロレイヤ実装が導入されたとしても、メッセージが４つのプリミティブタイプに適合する限りは）。これは、PIクラスが、変化を受けることなく、プロレイヤ・クラスにアクセス出来ることを意味する。
【００５０】
（IV  実装モデル）
ここで、ＯＰｔＩＭＡモデルの特定の実装について説明する。
【００５１】
プログラミング・インターフェースの適当な機能を評価するために、メッセージ、メソッド及びクラスに関連した一組のQoSが、クラス・ライブラリにおいて定義され、構成される。QoSシグナリングをテストケースとして選択した理由は、ユーザが、移動通信ネットワークの未来世代において、混合サービス（例えば、音声／ビデオ／データ及びその他のインターネット・サービス）を要求する時に、予想されるインターラクションの複雑性とOoSの多様性が増大することであった。Aurrecoecheaは（”A survey of QoS Architectures”, ACM/Apringer Verlag Multimedia Systems Journal, Special Issue on QoSX Architecture, Vol6, No.3, pp138-151, May 1998）、多数の異なるQoSアーキテクチャを比較し、それらの独自の特徴を検討している。そして、大半のQoSアーキテクチャは単に、マルチメディア通信のためのエンド・ツー・エンド・QoSサポートより、むしろ単一アーキテクチャ・レベルを検討していると述べている。更に、QoS管理の特徴は、プロトコール・スタックの各レイヤ内で用いられるべきであり、QoS制御・管理メカニズムは全てのアーキテクチャ・レイヤ上に正しく配置されるべきであると指摘している。
【００５２】
ここで、エンドーツーエンドに対するサポートとレベル制御されたQoSネゴーシエーションを組み込んだモデルが、機能を示し、OPtIMAアーキテクチャ・フレームワーク内の通信シグナリングの動作をテストする例として実装された。
その後、一般QoSシグナリング・メッセージ仕様の定義、プロトコール・スタック記述及びQoSネゴシエーション・インプリメンテーションが続く。モデル１実装はRMIプラットフォーム（SunSolarisワークステーション上で実装する）に基づくものである。そこでは多数のアプレットが実装され、シグナリング（アプリケーション）エンド・ポイント表示として使用される。
【００５３】
１組のメッセ−ジとパラメータが、OPtIMAプロトコール・フレームワーク上に構築された一般QoSシグナリング構成に対し、特定され、定義される。API−プロインターフェースに対するメッセージとそのタイプ（即ちプリミティブ）が図１２ｂに示される。メソッド／機能の呼のネーミングは、一般ルールに従う。メッセージ・フォーマット及びメッセージ・ネーム仕様は次のとおり定義される。
[プログラミング・インターフェースの名称][プリミティブのタイプ][記述]（アーギュメント/パラメータ）
【００５４】
次のメッセージを例として挙げる。
ＡＰＩＳＲＭＳｅｒＲeq（StringTypeOfService）｛  ｝
【００５５】
このメッセージはAPI(Interface between Signaling Application Layer and Application Layer)の一部である。それはプリミティブ・タイプ‘サービス・リクエスト・メッセージ（SRM）’から派生するものであり、アーギュメント（例えばtype Of Service）としてストリングを有する。全てのメッセージ（即ち、SRM, LSI, RR及びAEN）は、下方に又は上方に一方向である。そして、SRM及びLSIは下方（上位レイヤから下位レイヤへ）であり、RR及びAENは上方に（即ち、下位レイヤから上位レイヤへ）渡される。
【００５６】
上位から下位レベルへ、又は、下位から上位への流れの方向は、又、ナンバリング・システムで表示される。
0004777587.tif 000002
【００５７】
いくつかのメッセージはOPtIMAの特徴を使用してもよい。また、続くレイヤ以外のレイヤにアクセスしなければならないかもしれない（例えばリンク・レイヤに直接メッセージを送るアプリケーション）。同様に、これはコマンドネーミングで次のように定義される。：API２SRMTypeOfSRM（arguments）{  }
【００５８】
この部分の残り（remainder）は、例として、QoSシグナリングAPIに対し定義されたSRM,LSI,RR及びAENの完全なリストを定める。モデル１はプログラミング・インターフェースのアーキテクチャ及び仕様について検証（verfication）及び妥当性検証（validation）を可能にする。OPtIMA及びプロインターフェースの実装の固有機能を検証するために、APIのQoSメッセージ部分が例として取り上げられてきた。
【００５９】
サービス・リクエスト・メッセージ（SRM）
【表１】
0004777587.tif 000003
【００６０】
レイヤ状態情報（LSI）
【表２】
0004777587.tif 000004
【００６１】
非同期イベント通知（AEN）
【表３】
0004777587.tif 000005
リクエスト応答（RR）は適用できない。
【００６２】
図１２ａ及び１２ｂは、QoSネゴシエーションのためのスケルトン・コード及びＡＰＩプロインターフェースのためのメッセージの組をそれぞれ意味するものである。そこで、次に、ＡＰＩにおけるQoSネゴシエーションと管理のための実装されたモデルとクラス構造について説明する。
【００６３】
（IV．１  モデル記述）
モデル１において、実装は、１つのサーバー・アプレット及び多数のクライアント・アプレットからなる。２つのアプレット・クラスはQoSネゴシエーションを表現するものである。ＯＰｔＩＭＡにおいて定義されたQoSクラスは、トランスポート・メディアとしてJavaＲＭＩを使って、クライアントとサーバーの間のメッセージのやり取りを容易にする。
【００６４】
アプレットは、QoSセッティングを交渉し、表示するために終端へシグナリングするのに使用される。これら終端間の通信はＡＰＩを通して、下位にあるレイヤ・クラス（プロレイヤ）を使って行われる。これは、インターフェース（スタブとスケルトン）を経由してJavaオブジェクト・ブローカ（ＲＭＩ）にRMI接続を実装するものである。このモデルにおけるクライアント−スタッブ及びサーバー−スケルトンの実装は、プロレイヤ・クラスを表わすものである。プロトコール・スタック（このテスト・プラットフォームにおいて用いられる）はアプリケーション・レイヤ（Lクラス）、API及び、残りのプロトコール・スタックを表す一般レイヤ・クラス（Lクラス）から構成される。このモデルの機能は基本クライアント／サーバー原則に基づくものである。それによれば、オブジェクトはネットワークに分散されており、ミドルウェアレイヤ（オブジェクト・ブローカ）を介して通信を行う。クライアントは、リクエスト・ブローカを介して、遠方サーバ・オブジェクトからのサービスを要求する。（RMI）ブローカは、それぞれスタブとスケルトンと呼ばれる、クライアントとサーバの実装に関係するインターフェースを使用する。
スタブとスケルトンはクライアントとサーバ間の通信の複雑性を隠すものであり、パラメータのsterilisation とde-marshallingを制御し、遠方にあるエンティティ間の接続を確立し、維持し、終了する。アプリケーション・レイヤ・クラスはアプレット（クライアント・アプレット及びサーバ・アプレット）として実装され、シグナリング終端のグラフィカル・ユーザ・インターフェース（GUI）を提供する。JavaAWT（アブストラクト・ウィンドイング・ツールキット）はGUI及び、処理プラットフォームとしてSunワークステーション上のSolarisを実装するのに用いられる。
【００６５】
一般レイヤ・クラス（MTIクラス・クライアント及びクラス・サーバ）は、プロトコール・スタックのテスト・プラットフォーム版を表す。このクラスはシグナリング・アプリケーション・レイヤ・クラスから派生するもので、下位レイヤで利用できる全てのQoS情報はこのクラスを介してアクセスされる。更に、一般レイヤ・クラスはJavaのRMIスタブ及びスケルトン・クラスにアクセスする。
RMIクライアント及びRMIサーバ・クラスは、別のクラスとして実装され、図１３に示すように、（RMI）分散オブジェクトの計算エンドポイントのための手段を提供する。クライアントとサーバのアプレットを、それぞれ、図１４及び１５に示す。そのデータ・フィールドは、要求され、提供されたQoSパラメータを表す。
【００６６】
アプレット‘クライアント’は、次の要素を有する多数のコンポーネントから構成される。
・  テキスト領域、一般イベントについてユーザに通知するのに使用される。
・  ９つのテキスト・フィールド、確立した接続についてのパラメータを表す
。
・  多数選択、ユーザが特定サービスを要求できるようにする。
・  テキスト・フィールド、ユーザが宛先IDを挿入する
・  多数のボタン、ユーザがターミナルと相互にやり取りする。
【００６７】
アプレット‘サーバ’は以下のコンポーネント・セットから構成される。
・  テキスト領域、一般イベントについての管理者に通知するのに使用される
。
・  ９つのテキスト・フィールド欄、確立した接続又はリクエストのパラメー
タ（最後のリクエストのタイプによる）についてのパラメータを表す。
・  多数選択の欄、マニュアルでネットワークの現行状態を決める。手でネッ
トワーク状態を決定する事は必要である。というのはユーザデータの現在
のフローがないからである。テスト・プラットフォームはプロトコール
・  スタックのシグナリング・プレーン（plane）を実装する。遅延及びＢＥ
Ｒのようなフロー・パラメータの測定は不可能である。
・  選択、これは、管理者が現行ネットワーク状態とは無関係に、全てのリク
エストを拒否する事を可能にする。
【００６８】
通信サービスの品質及び接続（又はサービス・リクエスト）によって提供される品質を記述するのに用いられるパラメータは以下のとおりである。
・  標準：例えば、ＧＳＭ、ＤＥＣＴ他のような標準タイプを決定する。
・  Ｉｄフィールド：クライアントのアイデンティティ（例えば、GMSのため
にＴＭＳＩ/IMSI）を決定する。
・  ロケーションIｄ：移動クライアント（例えば、GMSのためのLAI）の位置
を特定する。
・  帯域幅：接続又はリクエストのバンド幅（kbpsで）を決定する。この帯域
幅は、標準型に依存して、平均値、最大値、ベスト・エフォート、予測又
は保証帯域幅を特定することができる。
・  遅延：接続又はリクエストの遅延を特定する。それは、標準型に依存して
、平均値、最大値、ベスト・エフォート、予測又は保証帯域幅を参照する
ことができる。
・  優先：接続がそのQoSのレベルを下げる（必要があれば）オーダに関連し
て、又、接続が資源を回復する（必要があれば）ために開放されるオーダ
に関連して、接続についての相対的重要性を特定する。
・  保護：サービス・プロバイダーが非許可モニタリング又はユーザ発信情報
の操作を防止しようとするレベルを決定する。
【００６９】
実験装置は、ＳＵＮのSolarisサーバ上で動作するサーバ・アプレット、及び、分散ｘ端末上で動作する多数のクライアント・アプレットから構成した。それらは、ATMハブ（１０/１００Mｂｉｔ/ｓEthernet(登録商標)接続上で）を介して、サーバマシンに接続した。
モデル１実装の操作例として、我々は、図１６に示すQoS再交渉のための単純化されたシグナリング・メッセージ・シーケンスの動作を、簡単に説明する。
クライアントが、サーバから既に提供されたサービスの修正を要求する（サービス修正）。それは、クライアントの識別に関連する要求された全てのQoSパラメータ及び情報をサーバに渡す。サーバは、このリクエストを処理し、要求されたQoS、ローカル資源（即ち、全クライアントに予定している現行ローディング）及び、このクライアントに既に割当てた資源を検査する。そしてサーバーは、クライアントに新リクエストを受け入れるか否か通知する（サービス修正応答）。クライアントは前回のメッセージの受信確認を行う（サービス修正応答の受信確認）。リクエストが受け入れられなかった場合は、クライアントは、前回のQoS値を維持した現行セッションを切断するか、接続を維持するかどちらかを選択出来る。
【００７０】
前記の実施例は以下の重要な特徴を有する。
・  一般インターフェース・クラス（API／PPI）のライブラリの詳細仕様を含
むプロトコール・リコンフィギュレーション・プラットフォーム（即ちア
ーキテクチャ上のフレームワーク）が、設けられる。該プラットフォーム
は、オブジェクト指向プログラミング技術を使って、柔軟なオープンな手
法で、リコンフィギュラブル・プロトコール・スタックを実装するために
、使用される。
・  （前記定義されたライブラリにおいて備えられた）ＡＰＩ及びＰＰＩを使
用する標準と非標準プロトコール・スタックを構成するためのガイドライ
ン／仕様の実装。オープン・プログラミング・プラットフォームを使用す
ると、アプリケーションとプロトコール・レイヤをどのようにプログラム
するかの仕様が要求される。
・  ＡＰＩ/ＰＰＩは、プロトコール・レイヤの旧式な実装と共に、並びに、
プロトコール・レイヤのコンポーネントベースの形式と共に動作する。即
ち、フレームワークは構成可能なプロトコールをサポートする。
・  プロトコール・リコンフィギュレーションは、“リコンフィギュレーショ
ン・マネージャ”ユニットの制御／管理を要求する。
・  提案されたオープン・プログラマブル・プロトコール・インターフェース
のための二つの異なる実装モデルは、提案され、評価された。２つとも、
プロトコール・スタック・リコンフィギュレーションをサポートするため
に要求される柔軟性を提供するものである。第１の方法はインターフェー
スがオブジェクトとして実装されるアーキテクチャを提案するものである
。これに対して第２のものは、ＡＰＩの古典的な定義に従うもので、ＡＰ
Ｉは、下位レイヤに実装される、単に形式的な定義である。二つの実装方
法はＯＰｔＩＭＡ内でサポートすることが出来るけれども、現行ＯＰｔＩ
ＭＡアーキテクチャは二つの実装モデルのうちの前者に基づくものであっ
た。
・  既存の基本プロトコール・クラス及びカスタム化を拡張することによって
、アプリケーション−特化の振る舞い（behaviour）を実装することは可
能である。即ち、ユーザは、自分達自身のカスタム・プロトコール・スタ
ック、プロトコール・レイヤ又はコンポーネントの付加／消去を所与のレ
イヤ内で、インストールし動作させることが許される。こうして、プロト
コールの機能／コンポーネントをアプリケーションの要求に合わせること
ができる。ベンダが、プロトコール・クラスを適当なAPI／PPIに対応して
実装することを前提とする。
・  提案されたＰＩは、アプリケーションQoSをネットワーク及びリンク・レ
イヤのＱｏＳパラメータにマッピングすることが出来る。このことは、無
線移動ネットワーク内で要求される事である。
・  ＯＰｔＩＭＡアーキテクチャはＪａｖａで実装される。Javaが、コード・
モービリティ、ＯＯ特性、直列化（serialisation）、継承及びカプセル
化特性をサポートすることから、Ｊａｖａプラットフォームを選択した。
【図面の簡単な説明】
【図１】  古いタイプのGSMの制御プレーン（C）と‘アクティブ・プログラム・インターフェース’プロトコール・スタックとの間との比較図である。
【図２】  スレッド・制御メッセージ・ハンドリングを示す概略図である。
【図３】  プロトコール・スタック構成及びプロトコール・スタック・クラス・ライブラリの関係図である。
【図４】  プロレイヤ・クラスの構成を示す図である。
【図５】  インターフェース・クラス階層図である。
【図６】  スレッド・クラス階層図である。
【図７】  インターフェース・プリミティブと各レイヤーとの関係を示す図である。
【図８】  PSクラス関係を表す図である。
【図９】  各階層とクラス関係を示す図である。
【図１０】  アクティブ・インターフェース・オブジェクトの構成図である。
【図１１】  プロトコール・スタック内のクラス関係を示す関連図である。
【図１２】  プロレイヤとプロインターフェースのためのフレームワーク図及びスレッド・クラスの例を示す図である。
【図１３】  モデル・インプリメンテーション・プロトコール・スタックの図である。
【図１４】  図１３のモデルで用いたサーバ・アプレット図である。
【図１５】  図３のモデルで用いたクライアント・アプレット図である。
【図１６】  ＱｏＳ修正メッセージ・シーケンス図である。
【図１】
0004777587.tif 000006
【図２】
0004777587.tif 000007
【図３】
0004777587.tif 000008
【図４】
0004777587.tif 000009
【図５】
0004777587.tif 000010
【図６】
0004777587.tif 000011
【図７】
0004777587.tif 000012
【図８】
0004777587.tif 000013
【図９】
0004777587.tif 000014
【図１０】
0004777587.tif 000015
【図１１】
0004777587.tif 000016
【図１２】
0004777587.tif 000017
【図１３】
0004777587.tif 000018
【図１４】
0004777587.tif 000019
【図１５】
0004777587.tif 000020
【図１６】
0004777587.tif 000021