JP2004501548A - プロトコール・スタック - Google Patents
プロトコール・スタック Download PDFInfo
- Publication number
- JP2004501548A JP2004501548A JP2001585037A JP2001585037A JP2004501548A JP 2004501548 A JP2004501548 A JP 2004501548A JP 2001585037 A JP2001585037 A JP 2001585037A JP 2001585037 A JP2001585037 A JP 2001585037A JP 2004501548 A JP2004501548 A JP 2004501548A
- Authority
- JP
- Japan
- Prior art keywords
- class
- layer
- protocol stack
- protocol
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
Abstract
通信システムに対するプロトコール・スタックは、スタックのリコンフィギュレーションを支援することの出来るアクティブ・プログラム・インターフェースを構成するアーキテクチャを有する。スタックは複数のレイヤ（プロレイヤ）及び、レイヤ・クラスとプログラミング・インターフェース・クラスによりそれぞれの機能が定義される複数のオブジェクト指向のインターフェース（プロインターフェース）を有している。これら機能の実装はスレッド・オブジェクトにより制御される。
Description
【０００１】
本発明は、プロトコール・スタック及びプロトコール・スタックを有する通信システムのような通信システムに関する。
【０００２】
本発明は、専用的ではないが特殊なアプリケーションに対し、所謂ソフトウェア・リコンフィギュラブル無線（ＳＷＲ：ｓｏｆｔｗａｒｅ−ｒｅｃｏｎｆｉｇｕｒａｂｌｅ ｒａｄｉｏ）、即ちソフト無線を提供するものである。
【０００３】
現在、プロトコール・スタックは、マルチプル・レイヤが互いの上に位置付けされ（即ち、成層方法（ｓｔｒａｔｉｆｉｃａｔｉｏｎ ａｐｐｒｏａｃｈ））、各レイヤは他のレイヤに対し、内的機能及びサービス・アクセス・ポイント（ＳＡＰ）として知られている標準化されたインターフェースを使ったアプリケーションを提供するよう実施されている。
【０００４】
更に特定すれば、プロトコール・スタックは数個の単一プロトコール（レイヤ）の集合であり、各プロトコールは、或る機能を有し、或るタスクを行うものである。従来のものでは、プロトコール・フレームワークは複合メカニズムとしての成層方法を使用している。スタックの１レイヤにおけるプロトコールは、下位のレイヤの特性に鈍感である。各レイヤは“ブラックボックス”として扱われ、スタックにおいて発生する可能性のある機能冗長性を特定／バイパスするメカニズムを有しない。
プロトコール・スタックを文書化した例はＯＳＩＲＭ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌ）であり、これは、次の７レイヤからなる。即ち、アプリケーション・レイヤ、プレゼンテーション・レイヤ、セッション・レイヤ、トランスポート・レイヤ、ネットワーク・レイヤ、データ−リンク・レイヤ、及び物理レイヤである。これらの各レイヤは、次の上位レイヤにサービスを提供し又は、直近下位レイヤからのサービスを予定するという完全なプロトコールを表している。この構造は“Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ”（Ａ．Ｓ．Ｔａｎｅｎｂａｕｍ，第３版、Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，１９９６発行）に記述されている。同じ原則が、移動及び固定ラインの通信ネットワークに適用されている。そしてインターワーキング機能（ｉｎｔｅｒｗｏｒｋｉｎｇ ｆｕｎｃｔｉｏｎａｌｌｉｔｙ）は別々のプロトコールで定義される。レイヤ間の通信はＳＡＰを通して行われる。これらＳＡＰを通して、或るレイヤのプリミティブのセットは、次の上位レイヤで利用可能になる。サービスはレイヤ内で実装される操作（ｏｐｅｒａｔｉｏｎ）を定義し、上位レイヤにより要求される。実際に、ＳＡＰはレイヤをカプセル化し、レイヤの複雑性を隠し、レイヤが提供する機能及び上位レイヤユーザーがレイヤから要求するものを一通りに記述するのに用いられる。しかし、ＳＡＰは静的で、柔軟性を欠く。ＳＡＰはプロトコール・スタックにおける柔軟な変化をサポートしないし、変更が必要となる時には、再標準化されることが必要である。
【０００５】
従来のプロトコール・スタックの欠点は、特に、ＳＷＲ実装に重大な障害をもたらす。ＳＷＲは、再プログラミング（例えば、“Ｔｈｅ Ｓｏｆｔｗａｒｅ Ｒａｄｉｏ Ａｒｃｈｉｔｅｃｔｕｒｅ”、Ｊ Ｍｉｔｏｌａ ＩＩＩ 、ＩＥＥＥ Ｃｏｍｍ．Ｍａｇ．Ｍａｙ １９９５ ｐｐ２６−３８ 及び“Ｔｈｅ Ｌａｙｅｒｅｄ Ｒａｄｉｏ”Ｍ Ｂｕｔｌｅｒ ｅｔ ａｌ， ＭＩＬＣＯＭ， １９９８， ｐｐ １７９−１７９）を行って様々な異なる標準又はプロトコールを実装する万能無線（ａｌｌ−ｐｕｒｐｏｓｅ ｒａｄｉｏ）へ進化している。マルチモード・ターミナルは、可能な／既存の標準を含む“Ｖｅｌｃｒｏ ａｐｐｒｏａｃｈ”を用いないものであるが、ＳＷＲは、該マルチモード・ターミナルに対する重要な代替手段として登場している。それ故、種々のサービス品質（ＱｏＳ）要求及び種々のトラフィック特性を有する多くの多様なアプリケーションをサポートするために、次世代の移動端末とネットワークノードには、制御面でかなり豊富な能力が要求される。
【０００６】
ＳＷＲ端末は、また、再プログラム可能でなければならない。このリコンフィギュレーション要請は物理レイヤだけに限られるものではない。要するに、仮にソフトウェア・ダウンロード、リコンフィギュレーション及び管理に対する能力が端末に備えられ、ネットワークのインフラストラクチャーによりサポートされるなら、将来のＳＷＲ端末、装置及びネットワーク・エンティティは、アプリケーションの必要性とユーザーの好みに対し効率的に対応することができる。しかし、これは既存の固定プロトコール成層方法では、できない。
【０００７】
本発明の１つの目的は、前記の問題の少なくともいくつかについて，問題を軽減することである。それは、従来のプロトコール・スタックで使用されている静的なＳＡＰに置換わるアクティブ・プログラミング・インターフェース（プロトコール・プログラミング・インターフェース（ＰＰＩ）／アプリケーション・プログラミング・インターフェース（ＡＰＩ））を有するプロトコール・スタックを提供することにより実現される。
【０００８】
“Ｔｏｗａｒｄｓ ａｎ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ”（Ｄ Ｔａｎｎｅｎｎｂａｕｍ ｅｔ ａｌ， Ｃｏｍｐ．Ｃｏｍｍｕｎ．ＲｅｖＶｏｌ２６，Ｎｏ２，Ａｐｒ １９９６）、“Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ Ｓｏｕｒｃｅｓ ｆｏｒ Ｗｉｒｅｄ／Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｓ”（Ａ Ｋｕｌｋａｒｎｉ ｅｔ Ａｌ， Ｐｒｏｃ．ＩＮＦＯＣＯＭ９９，Ｖｏｌ３，ＮＹ１９９９）及び“Ｃｏｍｐｏｓｉｎｇ Ｐｒｏｔｏｃｏｌ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ａｃｔｉｖｅ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｓ”（Ａ Ｋｕｌｋａｒｎｉ ｅｔ ａｌ ＩＥＥＥ Ｃｏｍｍｕｎ Ｍａｇ Ｍａｒ ２０００）に記載されているように、アクティブ・ノードとインターフェースは、新たなマルチメディア・アプリケーションをサポートし、メディア・プロトコール（インターネット及びＩＮ）と異なるシグナリング・システム（ＳＳ７，Ｈ３２３等）の間のインターワーキング機能の円滑化を提供して、特殊化又は統合化サービスの導入を促進する。同様に、ネットワーク管理は、更にインテリジェントになり、ネットワーク能力は、ネットワークのインフラストラクチュアのアップグレード化を必要とせず、ソフトウェアを変更することで、急速に進化している。このように、将来のリコンフィギュラブル移動ネットワークは、アクティブ・ノードとサービス・インターフェースの発展から恩恵を受けることが予想される。
【０００９】
プロトコールレイヤ間にプログラミング・インターフェースを導入するリコンフィギュレーションは、高級プログラミング言語（例えば、ジャバアプリケーションは異なるＡＰＩを使用する。ＡＰＩは、実行時結合しているクラス・ライブラリーの一部である。これは、機能が、ＡＰＩへのアウトソースされ、アプリケーションが単にシーケンスを定義し、ＡＰＩ内の方法に渡すパラメータを決定することを意味する。）でアプリケーションを書くのと同様のやり方で、単一プロトコール又は全プロトコール・スタックを書く可能性を開くものである。ソフトウェア無線設計における他の重要な設計問題は、無線の本来のリコンフィギュレーション（即ち、動作時リコンフィギュレーション管理、ｏｖｅｒ−ｔｈｅ −ａｉｒダウンロード・プロトコール（“Ｔｅｒｍｉｎａｌ Ｒｅｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ−Ｔｈｅ Ｓｏｆｔｗａｒｅ Ｄｏｗｎｌｏａｄ Ａｓｐｅｃｔ” Ｋ Ｍｏｅｓｓｎｅｒ ｅｔ ａｌ ＩＥＥ Ｉｎｔ Ｃｏｎｆ Ｏｎ ３Ｇ ２０００，Ｍａｒ ２０００，Ｌｏｎｄｏｎ ＵＫに説明されている）及びセキュリティ関連を管理するリコンフィギュレーション管理）に関するものである。
【００１０】
この一般問題に対するもう１つの文書化されたアプローチは“Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｅｎｖｉｒｏｎｍｅｎｔ”（ＭＡＳＥ）である。これはＡＣＴＳプロジェクト“ Ｏｎ ｔｈｅ Ｍｏｖｅ”ｔｈｅ Ｇｌｏｂａｌ Ｍｏｂｉｌｅ ＡＰＩ Ｆｒａｍｅｗｏｒｋ， ｔｈｅ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｅｘｅｃｕｔｉｏｎ （ＭＥｘＥ）ＧＳＭ ０２．５７Ｖ７０．０ＥＴＳＩ，１９９８ 、及び、 ＩＥＥＥ Ｐ１５２０ ネットワークのためのアプリケーション・プログラミング・インターフェースのためのＩＥＥＥ標準の一部として開発されたものである。
【００１１】
本発明によれば、スタックは、スタックのリコンフィギュレーションをサポートすることが出来るアクティブ・プログラミング・インターフェースを組み込んだ構成を有し、このようなスタックを有する通信システムのためのプロトコール・スタックを備える。
【００１２】
アクティブ・プログラミング・インターフェースは、オブジェクトであり、オブジェクト指向設計原則に適合させる必要がある。
【００１３】
本発明は新概念を導入するものであり、この新概念とはプロトコール・レイヤ間のインターフェースを再定義するもので、プロトコール・スタック内の異種レイヤ間のインターアクションを分類し、プロトコールのリコンフィギュレーションをサポートする構成を備えるものである。これは、アクティブ・プログラミング・インターフェースを、プロトコール・スタック内のオブジェクトとして実装することにより、又、この新規のプロトコール・スタック構成を定義するオブジェクト指向設計方法を用いることにより達成することができる。標準化されたアクティブ・プログラミング・インターフェースは、端末及びネットワークにおいてプロトコール・スタックの標準的リコンフィギュレーションに必要な追加的自由度を導入する
【００１４】
本発明の実施例を図面に基づいて説明するが、これは一実施例であって、これに限定されるものではない。
説明する実施例はオープン・プロトコール・プログラミング・インターフェース・モデル及び、以下ＯＰｔＩＭＡと呼ぶアーキテクチャに適合するものである。
【００１５】
（最適なアプローチ）
ソフトウェアのリコンフィギュレーションは、ソフトウェア規定無線（ｓｏｆｔｗａｒｅ ｄｅｆｉｎｅｄ ｒａｄｉｏｓ）を実現するのに不可欠の技術であるとされて来ている。主たる重要な機能はプロトコール・ソフトウェア‘ｏｎ ｔｈｅ ｆｌｙ’を交換する能力及び完全なプロトコール・スタックを再構成（ｒｅｃｏｎｆｉｇｕｒｅ）する能力であり、これは様々な環境で必要となるものである。
【００１６】
ここに紹介する方法はプロトコール・スタック・リコンフィギュレーションのためのフレームワークを与えるものである。プロトコール・スタックは、クラス・ライブラリーを構成する一般“ｃｌａｓｓｅｓ”のタームで記述される多数の機能エンティティティに分解される。これらは、リコンフィギュラブル・プロトコール・スタックを実装するために、動作時にダイナミックに結合する。そして、フレームワークは、構成要素であるプロトコール（ｃｏｍｐｏｓｉｂｌｅ ｐｒｏｔｏｃｏｌ）をサポートすることができる。単一のプロトコール・レイヤは、特定の機能を実装する一群のコンポーネントによって置換され得る。ソフト無線端末の内部で、“リコンフィギュレーション管理”ユニットが、コンポーネントの選択、削除／アップグレード及びＰＰＩとの通信を制御する。ＯＰｔＩＭＡ仕様によれば、定義されたＡＰＩ及びＰＰＩを使って、標準化され、財産権のあるプロトコール・スタックを、作成／実装するためのガイドラインが提供される。
【００１７】
（ＩＩ．１ アプリケーション・プログラミング・インターフェース及びオブジェクト指向設計原則）
一般に、インターフェースは、数個の下部レイヤの隠れた機能へのアクセス・ポイントを表現するものである。このようなインターフェースの目的は、複雑な機能の実装をカプセル化すること、及びこの機能をユーザー／プログラマー／アプリケーションに対しこの機能へのアクセスを最も簡単な形で提供することである。
【００１８】
アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、一般的に、インターフェースが実際には如何に複雑に機能が実現されるか、その複雑さを隠しているものであるという、パラダイムに基づいている。これによれば、プログラマーは、各単一機能呼び出しに対し、どのようにインターフェースを使い、どのパラメータを渡せばいいかについてのガイドラインに従えばよい。アプリケーションは、これらＡＰＩ実装の範囲内で予め定義された機能の一連の呼び出しとなる。従って、このアプリケーション内での多くの複雑性は、下位レイヤに、これらプログラミング・インターフェースの下に隠される。ＡＰＩの利点の一つは、その拡張性と、部分的な、又は、完全な交換可能性（この交換可能性はアプリケーション・コードの完全な再書き込みを必ずしも要求しない）である。プログラミング・インターフェースの他の利点はスケーラビリティと、この構成の単純な使用である。
【００１９】
オブジェクト指向の基本アイデアは、システムの動作と特性を、例えば、“Ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ Ａｎａｌｙｓｉｓ，ｂｙ Ｃｏａｄ ｅｔ ａｌ， ２ｎｄＥｄｉｔｉｏｎ，Ｅｎｇｌｅｗｏｏｄ Ｃｌｉｆｆｓ，Ｎ Ｊ： Ｙｏｕｒｄｅｎ Ｐｒｅｓｓ，１９９１ ”に記載される個別エンティティ（ｄｉｓｃｒｅｔｅ ｅｎｔｉｔｉｅｓ）に組み込むことである。また、このことは、システムの機能的に異なるパーツを特定することを要請する。一旦、エンティティ及び、これらエンティティの状態又は動作（機能ｆｕｎｃｔｉｏｎａｌｉｔｙ）間の内部関係が解析されると、クラスとして形成（ｆｏｒｍａｌｉｓａｔｉｏｎ）され、記述がなされる。オブジェクト指向は、数多くの基本原則に基づいている。例えば、クラスはその主要な１つである。更に概念として、“ＯｂｊｅｃｔＯｒｉｅｎｔｅｄ Ａｎａｌｙｓｉｓ ａｎｄ Ｄｅｓｉｇｎ ｗｉｔｈ Ａｐｐｌｉｃｔｉｏｎ”（Ｂｏｏｃｈ，２ｎｄＥｄｉｔｉｏｎ，Ｂｅｎｊａｍｉｎ／Ｃｕｍｍｉｎｇｓ Ｐｕｂｌｉｓｈｉｎｇ， Ｒｅｄｗｏｏｄ Ｃｉｔｙ，ＣＡ １９９１）に記載されているように、オブジェクト、アブストラクション、属性、操作／メソッド／サービス、メッセージ、カプセル化、継承（Ｉｎｈｅｒｉｔａｎｃｅ），ポリモーフィズム、再使用がある。例えば、大半のＪＦＣ（Ｊａｖａ Ｆｏｕｎｄａｔｉｏｎ Ｃｌａｓｓｅｓ）は、基本クラス‘オブジェクト’から（１乃至数レベルの階レイヤを経て）派生するクラスにおいて実装される。同様のことが、ＭＦＣ（Ｍｉｃｒｏｓｏｆｔ Ｆｏｏｕｎｄａｔｉｏｎ Ｃｌａｓｓｅｓ）に応用できる。該ＭＦＣは、ウィンドーズ・プラットフォームに対するアプリケーション・プログラミングの基本実装クラスを有している。
【００２０】
（ＩＩ．２ システム・アーキテクチャ）
ＯＰｔＩＭＡモデルの目的の１つは、フレームワークを導入することである。フレームワークによれば、実装時のプロトコールの交換、及びレイヤ処理系にアクセスせずに、異なるプロトコール・スタック・レイヤのインターフェース間で直接シグナリング通信を可能にするようなインターフェースの積極的な関与を可能にする。このためには、システムに対し、多少異なる考え方をしなければならない。
このアプローチにおいては、プロトコールは、図１に示される‘プロインターフェース’及び‘プロレイヤ’に２分される。
【００２１】
プロインターフェースは、基本クラスから派生するクラス内で定義されるａｃｔｉｖｅ 実装である。ここで、エンティティの定義は、スタックにおける位置（ｐｏｓｉｔｉｏｎ）による（プロインターフェース→２つのプロレイヤの間）。この基本クラスは全ての可能なプロインターフェースの一般機能（ｇｅｎｅｒｉｃ ｆｕｎｃｔｉｏｎａｌｉｔｙ）を定義する。更なる特化は、その後派生されたプロインターフェース・クラス内で達成される。オブジェクトとして実装されると、インターフェース（即ちプロインターフェース）は、追加機能及び追加アーキテクチャー複合体（ａｒｃｈｉｔｅｃｔｕｒａｌ ｃｏｍｐｌｅｘｉｔｙ）を引き渡す。
【００２２】
プロレイヤはアクチュアル・プロトコール実装であり、これはプロインターフェースを通してデータを取得し、これらデータを操作し、プロインターフェースを介してこれらデータをエクスポートするものである。プロインターフェース及びプロレイヤ・クラス内での機能／メソッドの実装はスレッド・オブジェクト（ｔｈｒｅａｄ−ｏｂｊｅｃｔ）により管理される。このような構成は、実装時、古典的なプロトコール・スタックに代えて、フレキシブルなスタックリコンフィギュレーションを可能にするという、高度に柔軟なプラットフォームを提供する。換言すれば、スレッド・オブジェクトは、全てのプロレイヤ及びプロインターフェースに亘って、メッセージ転送と操作を管理するクラスの実装を行う。
【００２３】
図２に示されるように、到着すると、スレッドは、完全プロトコール・スタック内でメッセージとその処理に対して責任を引き受け、これらメッセージのレファレンスをその宛先に渡す。
【００２４】
（ＩＩ．３ クラス・アーキテクチャ）
図３には、プロトコール・スタックの‘機能分割（ｆｕｎｃｔｉｏｎａｌ ｄｅｃｏｍｐｏｓｉｔｉｏｎ）’が示されている。該スタックは、オープン・プロトコール実装のための基本的エンティティから合成されるものである。
【００２５】
下記の４つの異なるクラス・タイプが特定される。
１．レイヤ・クラス（Ｌ−クラスがプロレイヤを定義する）が、プロトコール・スタック内で（即ち、物理レイヤの（Ｐ−Ｌ）−，リンク・レイヤの（ＬＣＬ）−，ネットワーク・レイヤの（ＮＣＬ）−及びシグナリング・アプリケーション（ＢＳＡ）−機能）単一プロトコールの機能を表す。図４に示したように、レイヤ・クラス（プロレイヤ）は、一般（プロ）レイヤ・クラスから機能を継承する。
【００２６】
２． プログラミング・インターフェース・クラス（ＰＩ−クラスはプロ−インターフェースを定義する）は、プロトコール（Ｌ−クラス）間の各種プログラミング・インターフェースを表す。ＰＩ−クラスは、基本クラス（ＧＰＩ）で定義される一般的プリミティブを特定し、実装するメソッドから構成される。クラスの構成及びプリミティブの記述は、図５と図７にそれぞれ示されている。ＰＩクラスはイベント（即ち、数個のプロトコールからのメッセージ）を検出し、適切なスレッドの実装にトリガーをかける。
【００２７】
３． スレッド・クラス（Ｔクラス）は予め定義した手順（例えばコネクション、モービリティ、無線源又はＱｏＳの管理−シグナリング）を実装する。図６に示されているように、他の、定義されていない、標準化されていないシグナリング手順はカスタム化されたスレッド・クラス、即ち（ＳＳＴ）内で実装される。メッセージ列の実装に加えて、スレッドも、完全なプロトコール・スタックの柔軟性を高める。シグナリング手順を実装するためにスレッドを使用すると、プログラマーが、数個のシグナリング手続きを並列に実装することができる。この特徴は、１点−多点通信に関し有利である。スレッド・クラスは一体化され、ＰＩ及びＬクラスにおいて定義されたメソッドを用いる。
【００２８】
４．プロトコール・スタック・クラス（ＰＳクラス）は完全なプロトコール・スタックの実装を定義する。種々の旧式スタック（例えば、ＧＳＭスタック）は、標準を実装するための適当なクラスを含む特定の構成子（ｃｏｎｓｔｒｕｃｔｏｒ）を使う。他方では、他のスタックは自由に定義することが出来る。ＰＳクラスは、プロトコール・クラス・ライブラリー内で公衆がアクセスできる唯一のクラスである．更に、図８に示すように、ＰＳクラスは、Ｌ，ＰＩ又はＴクラスが実装中に交換される時に、プロトコール・リコンフィギュラビリティ（再構築可能性）を管理する。図示の通り、スレッド・クラス（ＳＳＴ）はＰＩ及びＬクラスで定義されたメソッドを使う。
【００２９】
要約すれば、Ｌ，ＰＩ及びＴクラスは、プロトコール・スタックの能力、メソッド及び性質を定義し、他方、ＰＳクラスはこれらクラスを実装し、又、プロトコール・スタック構造を定義する。
【００３０】
（ＩＩ．４ 設計ガイドライン）
ＯＰｔＩＭＡは、前記クラス及び一組の設計ルール（該ルールは、どのようにクラスと完全なプロトコール・スタックを実装するかを定めるものである）に基づく。プロトコール・スタック実装の基礎は、図１２Ａ及び図１２Ｂに示されるコード−スケルトンである。
１つのプロトコール・スタック内で、‘プロトコール・スタック’クラスは一般インターフェースをエクスポートする唯１のクラスである。それはＬ，ＰＩ及びＴオブジェクトを実装し、プロトコール・スタックの構成を定義するものである。アーキテクチャは、全体として、異なるインターフェースと異なるレイヤクラスの両方の階層構造を定義するために継承（ｉｎｈｅｒｉｔａｎｃｅ）を使う。従って、それは、プロインターフェース及びプロレイヤをそれぞれ派生するために、一般的インターフェース・クラス及び基本プロトコール・クラスを使用する。
【００３１】
（ＩＩ．５プロトコール・スタック及びスレッド・クラス）
クラス（ＰＩ，Ｌ，Ｔ）の３グループが、プロトコール・スタック・クラスのインスタンスによってインスタンス化され、実装され、管理される。従って、このＰＳオブジェクトは、完全なプロトコール・スタックを定義する。機能グループ（スレッド、インターフェース及びレイヤ）の１つの中でクラスはクラス・ライブラリーに位置している。各クラス・ライブラリーは、特殊な（派生の）クラスの或るグループのために機能を提供する。図３は、プロトコール・スタック及びそのクラス・ライブラリー内におけるクラスの依存関係及び‘論理的位置’を示す。スレッド・クラスは、プロトコール・スタック中を通るメッセージを実際に管理するエンティティである。スレッド・クラスは単一のメッセージ・シーケンスを処理するために使用される（即ち、各スレッドは１シーケンスを管理する）。
【００３２】
（ＩＩＩ ．プロトコール・レイヤ及びインターフェースの合成）
プロトコール・スタック機能をプロレイヤ及びプロインターフェースに分離することは、プロトコール・スタックに対して新たなパラダイムが形成される。そこでは、機能の分散がオープン・プロトコール・プログラミング・インターフェースにより容易になる。図示された実装では、ＯＰｔＩＭＡアーキテクチャは５つのレイヤから構成されており、各レイヤはそれ自身のタスクと機能を有している。‘分解された’プロトコール・スタック（プロレイヤ、プロインターフェース及びスレッド）内の全てのエンティティは、分離クラス（ｓｅｐａｒａｔｅ ｃｌａｓｓｅｓ）として実装される。プロレイヤ・クラス（Ｌクラス）は、そのプロトコール（レイヤ）の属性を含んでおり、対応するプロレイヤから（及びに関連して）得られる情報を格納するために使用される。Ｌクラスのメソッドは入力する情報を処理し、適正な応答を生成し、続くシーケンスを開始するために使われる。この実施レイヤにおいては、レイヤクラス及びその機能は以下の通りである。
物理レイヤ（モデム、チャネルアクセス、ＦＥＣ，暗号化等）
リンク・レイヤ制御（リンク制御）
ネットワーク制御レイヤ（制御メッセージ・ルーティング）
シグナリング・アプリケーション・レイヤ（接続制御、ソース及びモービリティ管理シグナリング）
アプリケーション・レイヤ、ＡＰＩ仕様に適合するアプリケーション
【００３３】
（ＩＩＩ ．１アクティブ・プログラミング・インターフェース）
プロレイヤはプロインターフェース（ＰＩ）により分離され、隔離される。これにより、交換可能性と拡張可能性（動作中のプロトコール実装の）が確保される。この意味で、プロトコールは、プロレイヤに対し、レガシー（旧タイプ）・プロトコールである。これに対し、プロレイヤは、ＯＰｔＩＭＡ内でのレガシー（そして財産権の可能性を持つ）プロトコール機能の実装である。適当なＰＩが定義され（図５のクラスアーキテクチャを参照）、プロトコール実装（プロレイヤ）間に導入される。
プロインターフェースはオープン・プロトコール−プログラミング・プラットフォームを提供する。プロインターフェースは、シグナリング・メッセージの相互交換を可能にし、プロトコール・レイヤ・クラスへアクセスを渡す。この実施例では、４つのインターフェース・クラスが完全プロトコール・スタックを実装するために定義される（図５参照）。
ＰＰＩ１２ （物理レイヤとリンク・レイヤ制御との間）
ＰＰＩ２３ （リンク・レイヤ制御とネットワーク制御レイヤとの間）
ＰＰＩ３４ （ネットワーク制御レイヤとシグナリング・アプリケーション・レイヤの間）
ＡＰＩ （アプリケーション・プログラミング・インターフェース）
【００３４】
プロインターフェースは一般インターフェース・クラス（ＧＰＩ）から派生したもので、プリミティブとして知られている制御メッセージの４つの基本タイプを定義する。プリミティブのタスクは、イベントについて各プロレイヤに通知し、プロレイヤとトリガー・メソッド（該メソッドは、これらプロレイヤ・クラスに実装される）との間の変数に対し新しい値を渡す事である。図７を参照すると、これら４つのプリミティブ・タイプは以下の通りである。
サービス・リクエスト・メッセージ（ＳＲＭ）：典型的には非永続的な即時動 作を実装する非同期プリミティブ。ＳＲＭに対する流れの方向は上位レイヤか ら下位レイヤへである。
リクエスト応答（ＲＲ）：永続状態又は長期間計測プリミティブ。
ＲＲに対する流れの方向は下位レイヤから上位レイヤへである。
レイヤ状態情報（ＬＳＩ）：永続状態プリミティブ。ＬＳＩに対する方向は、 上位レイヤから下位レイヤへである。
非同期イベント通知（ＡＥＮ）：最新の、典型的には非永続的イベントをレポ ートするプリミティブ。ＡＥＮに対する流れの方向は常に下位レイヤから上位 レイヤへである。
【００３５】
オブジェクト指向のプログラミング技術の開発に当たり、各プロインターフェース・クラスは、ＧＰＩと呼ばれるスーパークラスから一般機能を継承する。この‘親’クラスは、分離エンティティとして、実装プロトコール・スタックの一部ではない。しかし、それは、図９に示すように、全ての（派生された）ＰＩに対し、最小アクセス・インターフェース（即ちプリミティブ）を独占的に定義する。全般的アーキテクチャ上のフレームワークとの関連でアクティブ・インターフェース・オブジェクトのオブジェクト指向構成は、追加的特徴の実装を可能にする。即ち、（アクティブ）プロインターフェースは、アプリケーション開発のために、メッセージを渡し、共通シグナリングとデータＡＰＩを容易にするために、代替媒介物（ａｌｔｅｒｎａｔｉｖｅ ｍｅｄｉｕｍ）を提供する。
【００３６】
図１０に示されているように、アクティブ・インターフェースは以下の２通りの方法によりプロレイヤ内で属性へのアクセスを提供するために使用される。：連続的方法（シリーズＡ）及び非連続的方法（シリーズＢ）。シリーズＢにおいては、プロレイヤＮＣＬからの属性は、ＰＰＩ及びＡＰＩプロインターフェースを通して、これら属性を必要としないＢＳＡプロレイヤを飛び越え、アプリケーション・レイヤに供給される。
【００３７】
このアーキテクチャの利点は、ＯＰｔＩＭＡが異なる通信ネットワークで使用されるとき明らかになる。アプリケーションのためのシグナリング・インターフェースは、実装プロトコール・スタックとシステムのトランスポート手段とから独立しており不変である。目標のシグナリング・システムへの適応は適当なプロトコール（プロレイヤ）において行われ、実装中柔軟に交換され得る。
【００３８】
（ＩＩＩ ．２ アーキテクチャの全般的な実装）
Ｌ及びＰＩクラスは、オープン・プログラマブル・プロトコール・インターフェースに基づくプロトコール・スタックを実装する２つの主要ファミリ・グループを形成する。しかしながら、シグナリング・シーケンスを制御し、周期的なタスクを処理し（例えば、最下位レイヤにおけるチャネル測定）、外部トリガーに応答する際に必要な機能も備えねばならない。
【００３９】
これらのタスクを行うために、スレッド・クラス（Ｔクラス）のファミリが導入された。実装に当たり、それらは、現行メッセージ処理を実装するために、Ｊａｖａ（登録商標）のマルチスレッド特徴を用いる。Ｊａｖａを実装プラットフォームとして選択した。それは、Ｊａｖａの特徴として、ダイナミックな結合とプラットフォーム独立性があるからである。しかし、Ｔクラスは他の機能を定義しない。むしろ、Ｔクラスは、Ｌ（及びＰＩ）クラスで定義されたメソッドにアクセスし、これらクラスの適当な機能を呼び出す。スレッドの優先性（従ってメッセージ・シーケンスの実装優先性）は、スレッドのインスタンス化の期間に定義される。
【００４０】
プロトコール・スタック・クラス（ＰＳクラス）は、全プロトコール・スタックを表す。このクラスの属性は他の（前記した）全てのクラスのインスタンスである。このように、ＰＳクラスは、Ｌクラスの機能と情報を用い（ｅｘｐｌｏｉｔ）、ＰＩクラスで定義したプリミティブを使用し、インスタンス化されたＴオブジェクトのタスクの実装を制御する。これは、ＰＳクラスのインスタンスが、要求されるオブジェクトを実装することにより、所望のプロトコール・スタック機能を渡すことを意味する。適当なＰＳクラスの構成要素（ｃｏｎｓｔｒｕｃｔｏｒ）は標準プロトコール・スタック（これら標準のためのレイヤクラスが利用可能であることを条件として）を実装するために使用することが出来る。この構成を使用すると、プロトコール・スタックは、適当なクラス（プロレイヤ及びスレッド）を交換することにより、どのような要求にもダイナミックに適応することができる。
【００４１】
次のクラス関係は、アーキテクチャの複雑性を表す（図１１参照）。
【００４２】
ＬクラスはＰＩクラス定義に依存する。：Ｌオブジェクトは、上位又は下位レイヤと通信するためにＰＩクラスのプリミティブにアクセスできるが、一方、ＰＩクラスはＬオブジェクトにおいて格納された情報へのアクセスを提供するか、又は、この（Ｌ）オブジェクト内で実装されるメソッドをトリガーする。
【００４３】
Ｌ及びＰＩクラスはＴクラスに依存する。：Ｔオブジェクトは、予め定義したタスクを実行するために、適当な属性並びにＬ及びＰＩオブジェクトのメソッドを使うことが出来る。
【００４４】
ＰＳクラスはＬ、ＰＩ及びＴオブジェクトを属性として持つ。：ＰＳオブジェクトはこれらオブジェクトにおいて定義された機能及び情報を使うことができる。
【００４５】
ＴクラスはＰＳクラスに依存する。：ＰＳオブジェクトはその主なメソッドにおいて様々なスレッドの開始と停止を制御するが、Ｔオブジェクトは、単に、タスク実装に責任を有するのみである。図１１にこれを示す。
【００４６】
全てのクラスはクラス・ライブラリに組立られている。クラス・ライブラリは、どのようなネットワーク・エンティティに対しても、要求されるシグナリング機能を提供する。何故クラスをパッケージとしてグループ化するかの理由は、セキュリティに基本レベルを設けるからである。ＰＳクラスを宣言することにより、他のオブジェクトは、どのような他の非関連のオブジェクトに対しても、（理論的には）不可視（ｉｎｖｉｓｉｂｌｅ）になり、アクセス不可になる。
【００４７】
Ｔオブジェクトは、直接ＰＳオブジェクトの主たるメソッドにおいて用いられるが、Ｌ、ＰＩ及びＴオブジェクトは、ＰＳクラス内で属性として使用される。そして、これら属性はインスタンスであり、プロトコール・スタックのメンバーとして適当なオブジェクトを定義する。例えば、ＰＳオブジェクトのレファレンスはＬクラスのメソッドにおけるパラメータとしてよく用いられる。このように、仮にＬオブジェクトのメソッドが呼び出されたならば、オブジェクトは、同一のＰＳオブジェクトに属するＰＩオブジェクトを特定し、それら属性及びメソッド（即ちメッセージ）を使用する。
【００４８】
図９にこれを示す。プロトコール・スタックに対する２つの操作モードはシグナリング／メッセージ・シーケンスをトリガーする。これらは次の２つである。内部モード（即ち、ＰＳオブジェクトは、外部トリガーでは無く、タイムアウトによりスレッド実装を開始又は終了する）又は外部モード（例えば、アプリケーション又は物理レイヤで生じるイベント）。結果的に、これら２つの操作モードは適当なスレッドのインスタンス化（ｉｎｓｔａｎｔｉａｔｉｏｎ）又は終了に導く。
【００４９】
このアーキテクチャ面からのアプローチの柔軟性は一般ＰＩの導入に基づくものであり、数個の同時発生スレッドを使用することにより更に柔軟性は高められる。一般ＰＩはＬオブジェクトにアクセスし、Ｔオブジェクトをサポートするのに必要な手段を渡すもので、異なるプロトコール・スタック標準をサポートし、実装するために必要な柔軟な構成を提供する。ＰＳの機能エンティティ間のプリミティブの一般の組は、不変である（例え新規なプロレイヤ実装が導入されたとしても、メッセージが４つのプリミティブタイプに適合する限りは）。これは、ＰＩクラスが、変化を受けることなく、プロレイヤ・クラスにアクセス出来ることを意味する。
【００５０】
（ＩＶ 実装モデル）
ここで、ＯＰｔＩＭＡモデルの特定の実装について説明する。
【００５１】
プログラミング・インターフェースの適当な機能を評価するために、メッセージ、メソッド及びクラスに関連した一組のＱｏＳが、クラス・ライブラリにおいて定義され、構成される。ＱｏＳシグナリングをテストケースとして選択した理由は、ユーザが、移動通信ネットワークの未来世代において、混合サービス（例えば、音声／ビデオ／データ及びその他のインターネット・サービス）を要求する時に、予想されるインターラクションの複雑性とＯｏＳの多様性が増大することであった。Ａｕｒｒｅｃｏｅｃｈｅａは（”Ａ ｓｕｒｖｅｙ ｏｆ ＱｏＳ Ａｒｃｈｉｔｅｃｔｕｒｅｓ”， ＡＣＭ／Ａｐｒｉｎｇｅｒ Ｖｅｒｌａｇ Ｍｕｌｔｉｍｅｄｉａ Ｓｙｓｔｅｍｓ Ｊｏｕｒｎａｌ， Ｓｐｅｃｉａｌ Ｉｓｓｕｅ ｏｎ ＱｏＳＸ Ａｒｃｈｉｔｅｃｔｕｒｅ， Ｖｏｌ６， Ｎｏ．３， ｐｐ１３８−１５１， Ｍａｙ １９９８）、多数の異なるＱｏＳアーキテクチャを比較し、それらの独自の特徴を検討している。そして、大半のＱｏＳアーキテクチャは単に、マルチメディア通信のためのエンド・ツー・エンド・ＱｏＳサポートより、むしろ単一アーキテクチャ・レベルを検討していると述べている。更に、ＱｏＳ管理の特徴は、プロトコール・スタックの各レイヤ内で用いられるべきであり、ＱｏＳ制御・管理メカニズムは全てのアーキテクチャ・レイヤ上に正しく配置されるべきであると指摘している。
【００５２】
ここで、エンドーツーエンドに対するサポートとレベル制御されたＱｏＳネゴーシエーションを組み込んだモデルが、機能を示し、ＯＰｔＩＭＡアーキテクチャ・フレームワーク内の通信シグナリングの動作をテストする例として実装された。
その後、一般ＱｏＳシグナリング・メッセージ仕様の定義、プロトコール・スタック記述及びＱｏＳネゴシエーション・インプリメンテーションが続く。モデル１実装はＲＭＩプラットフォーム（ＳｕｎＳｏｌａｒｉｓワークステーション上で実装する）に基づくものである。そこでは多数のアプレットが実装され、シグナリング（アプリケーション）エンド・ポイント表示として使用される。
【００５３】
１組のメッセ−ジとパラメータが、ＯＰｔＩＭＡプロトコール・フレームワーク上に構築された一般ＱｏＳシグナリング構成に対し、特定され、定義される。ＡＰＩ−プロインターフェースに対するメッセージとそのタイプ（即ちプリミティブ）が図１２ｂに示される。メソッド／機能の呼のネーミングは、一般ルールに従う。メッセージ・フォーマット及びメッセージ・ネーム仕様は次のとおり定義される。
［プログラミング・インターフェースの名称］［プリミティブのタイプ］［記述］（アーギュメント／パラメータ）
【００５４】
次のメッセージを例として挙げる。
ＡＰＩＳＲＭＳｅｒＲｅｑ（ＳｔｒｉｎｇＴｙｐｅＯｆＳｅｒｖｉｃｅ）｛ ｝
【００５５】
このメッセージはＡＰＩ（Ｉｎｔｅｒｆａｃｅ ｂｅｔｗｅｅｎ Ｓｉｇｎａｌｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）の一部である。それはプリミティブ・タイプ‘サービス・リクエスト・メッセージ（ＳＲＭ）’から派生するものであり、アーギュメント（例えばｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅ）としてストリングを有する。全てのメッセージ（即ち、ＳＲＭ， ＬＳＩ， ＲＲ及びＡＥＮ）は、下方に又は上方に一方向である。そして、ＳＲＭ及びＬＳＩは下方（上位レイヤから下位レイヤへ）であり、ＲＲ及びＡＥＮは上方に（即ち、下位レイヤから上位レイヤへ）渡される。
【００５６】
上位から下位レベルへ、又は、下位から上位への流れの方向は、又、ナンバリング・システムで表示される。
【００５７】
いくつかのメッセージはＯＰｔＩＭＡの特徴を使用してもよい。また、続くレイヤ以外のレイヤにアクセスしなければならないかもしれない（例えばリンク・レイヤに直接メッセージを送るアプリケーション）。同様に、これはコマンドネーミングで次のように定義される。：ＡＰＩ２ＳＲＭＴｙｐｅＯｆＳＲＭ（ａｒｇｕｍｅｎｔｓ）｛ ｝
【００５８】
この部分の残り（ｒｅｍａｉｎｄｅｒ）は、例として、ＱｏＳシグナリングＡＰＩに対し定義されたＳＲＭ，ＬＳＩ，ＲＲ及びＡＥＮの完全なリストを定める。モデル１はプログラミング・インターフェースのアーキテクチャ及び仕様について検証（ｖｅｒｆｉｃａｔｉｏｎ）及び妥当性検証（ｖａｌｉｄａｔｉｏｎ）を可能にする。ＯＰｔＩＭＡ及びプロインターフェースの実装の固有機能を検証するために、ＡＰＩのＱｏＳメッセージ部分が例として取り上げられてきた。
【００５９】
サービス・リクエスト・メッセージ（ＳＲＭ）
【表１】
【００６０】
レイヤ状態情報（ＬＳＩ）
【表２】
【００６１】
非同期イベント通知（ＡＥＮ）
【表３】
リクエスト応答（ＲＲ）は適用できない。
【００６２】
図１２ａ及び１２ｂは、ＱｏＳネゴシエーションのためのスケルトン・コード及びＡＰＩプロインターフェースのためのメッセージの組をそれぞれ意味するものである。そこで、次に、ＡＰＩにおけるＱｏＳネゴシエーションと管理のための実装されたモデルとクラス構造について説明する。
【００６３】
（ＩＶ．１ モデル記述）
モデル１において、実装は、１つのサーバー・アプレット及び多数のクライアント・アプレットからなる。２つのアプレット・クラスはＱｏＳネゴシエーションを表現するものである。ＯＰｔＩＭＡにおいて定義されたＱｏＳクラスは、トランスポート・メディアとしてＪａｖａＲＭＩを使って、クライアントとサーバーの間のメッセージのやり取りを容易にする。
【００６４】
アプレットは、ＱｏＳセッティングを交渉し、表示するために終端へシグナリングするのに使用される。これら終端間の通信はＡＰＩを通して、下位にあるレイヤ・クラス（プロレイヤ）を使って行われる。これは、インターフェース（スタブとスケルトン）を経由してＪａｖａオブジェクト・ブローカ（ＲＭＩ）にＲＭＩ接続を実装するものである。このモデルにおけるクライアント−スタッブ及びサーバー−スケルトンの実装は、プロレイヤ・クラスを表わすものである。プロトコール・スタック（このテスト・プラットフォームにおいて用いられる）はアプリケーション・レイヤ（Ｌクラス）、ＡＰＩ及び、残りのプロトコール・スタックを表す一般レイヤ・クラス（Ｌクラス）から構成される。このモデルの機能は基本クライアント／サーバー原則に基づくものである。それによれば、オブジェクトはネットワークに分散されており、ミドルウェアレイヤ（オブジェクト・ブローカ）を介して通信を行う。クライアントは、リクエスト・ブローカを介して、遠方サーバ・オブジェクトからのサービスを要求する。（ＲＭＩ）ブローカは、それぞれスタブとスケルトンと呼ばれる、クライアントとサーバの実装に関係するインターフェースを使用する。
スタブとスケルトンはクライアントとサーバ間の通信の複雑性を隠すものであり、パラメータのｓｔｅｒｉｌｉｓａｔｉｏｎ とｄｅ−ｍａｒｓｈａｌｌｉｎｇを制御し、遠方にあるエンティティ間の接続を確立し、維持し、終了する。アプリケーション・レイヤ・クラスはアプレット（クライアント・アプレット及びサーバ・アプレット）として実装され、シグナリング終端のグラフィカル・ユーザ・インターフェース（ＧＵＩ）を提供する。ＪａｖａＡＷＴ（アブストラクト・ウィンドイング・ツールキット）はＧＵＩ及び、処理プラットフォームとしてＳｕｎワークステーション上のＳｏｌａｒｉｓを実装するのに用いられる。
【００６５】
一般レイヤ・クラス（ＭＴＩクラス・クライアント及びクラス・サーバ）は、プロトコール・スタックのテスト・プラットフォーム版を表す。このクラスはシグナリング・アプリケーション・レイヤ・クラスから派生するもので、下位レイヤで利用できる全てのＱｏＳ情報はこのクラスを介してアクセスされる。更に、一般レイヤ・クラスはＪａｖａのＲＭＩスタブ及びスケルトン・クラスにアクセスする。
ＲＭＩクライアント及びＲＭＩサーバ・クラスは、別のクラスとして実装され、図１３に示すように、（ＲＭＩ）分散オブジェクトの計算エンドポイントのための手段を提供する。クライアントとサーバのアプレットを、それぞれ、図１４及び１５に示す。そのデータ・フィールドは、要求され、提供されたＱｏＳパラメータを表す。
【００６６】
アプレット‘クライアント’は、次の要素を有する多数のコンポーネントから構成される。
・ テキスト領域、一般イベントについてユーザに通知するのに使用される。
・ ９つのテキスト・フィールド、確立した接続についてのパラメータを表す。
・ 多数選択、ユーザが特定サービスを要求できるようにする。
・ テキスト・フィールド、ユーザが宛先ＩＤを挿入する
・ 多数のボタン、ユーザがターミナルと相互にやり取りする。
【００６７】
アプレット‘サーバ’は以下のコンポーネント・セットから構成される。
・ テキスト領域、一般イベントについての管理者に通知するのに使用される。
・ ９つのテキスト・フィールド欄、確立した接続又はリクエストのパラメータ（最後のリクエストのタイプによる）についてのパラメータを表す。
・ 多数選択の欄、マニュアルでネットワークの現行状態を決める。手でネットワーク状態を決定する事は必要である。というのはユーザデータの現在のフローがないからである。テスト・プラットフォームはプロトコール
・ スタックのシグナリング・プレーン（ｐｌａｎｅ）を実装する。遅延及びＢＥＲのようなフロー・パラメータの測定は不可能である。
・ 選択、これは、管理者が現行ネットワーク状態とは無関係に、全てのリクエストを拒否する事を可能にする。
【００６８】
通信サービスの品質及び接続（又はサービス・リクエスト）によって提供される品質を記述するのに用いられるパラメータは以下のとおりである。
・ 標準：例えば、ＧＳＭ、ＤＥＣＴ他のような標準タイプを決定する。
・ Ｉｄフィールド：クライアントのアイデンティティ（例えば、ＧＭＳのためにＴＭＳＩ／ＩＭＳＩ）を決定する。
・ ロケーションＩｄ：移動クライアント（例えば、ＧＭＳのためのＬＡＩ）の位置を特定する。
・ 帯域幅：接続又はリクエストのバンド幅（ｋｂｐｓで）を決定する。この帯域幅は、標準型に依存して、平均値、最大値、ベスト・エフォート、予測又は保証帯域幅を特定することができる。
・ 遅延：接続又はリクエストの遅延を特定する。それは、標準型に依存して、平均値、最大値、ベスト・エフォート、予測又は保証帯域幅を参照することができる。
・ 優先：接続がそのＱｏＳのレベルを下げる（必要があれば）オーダに関連して、又、接続が資源を回復する（必要があれば）ために開放されるオーダに関連して、接続についての相対的重要性を特定する。
・ 保護：サービス・プロバイダーが非許可モニタリング又はユーザ発信情報の操作を防止しようとするレベルを決定する。
【００６９】
実験装置は、ＳＵＮのＳｏｌａｒｉｓサーバ上で動作するサーバ・アプレット、及び、分散ｘ端末上で動作する多数のクライアント・アプレットから構成した。それらは、ＡＴＭハブ（１０／１００Ｍｂｉｔ／ｓＥｔｈｅｒｎｅｔ（登録商標）接続上で）を介して、サーバマシンに接続した。
モデル１実装の操作例として、我々は、図１６に示すＱｏＳ再交渉のための単純化されたシグナリング・メッセージ・シーケンスの動作を、簡単に説明する。
クライアントが、サーバから既に提供されたサービスの修正を要求する（サービス修正）。それは、クライアントの識別に関連する要求された全てのＱｏＳパラメータ及び情報をサーバに渡す。サーバは、このリクエストを処理し、要求されたＱｏＳ、ローカル資源（即ち、全クライアントに予定している現行ローディング）及び、このクライアントに既に割当てた資源を検査する。そしてサーバーは、クライアントに新リクエストを受け入れるか否か通知する（サービス修正応答）。クライアントは前回のメッセージの受信確認を行う（サービス修正応答の受信確認）。リクエストが受け入れられなかった場合は、クライアントは、前回のＱｏＳ値を維持した現行セッションを切断するか、接続を維持するかどちらかを選択出来る。
【００７０】
前記の実施例は以下の重要な特徴を有する。
・ 一般インターフェース・クラス（ＡＰＩ／ＰＰＩ）のライブラリの詳細仕様を含むプロトコール・リコンフィギュレーション・プラットフォーム（即ちアーキテクチャ上のフレームワーク）が、設けられる。該プラットフォームは、オブジェクト指向プログラミング技術を使って、柔軟なオープンな手法で、リコンフィギュラブル・プロトコール・スタックを実装するために、使用される。
・ （前記定義されたライブラリにおいて備えられた）ＡＰＩ及びＰＰＩを使用する標準と非標準プロトコール・スタックを構成するためのガイドライン／仕様の実装。オープン・プログラミング・プラットフォームを使用すると、アプリケーションとプロトコール・レイヤをどのようにプログラムするかの仕様が要求される。
・ ＡＰＩ／ＰＰＩは、プロトコール・レイヤの旧式な実装と共に、並びに、プロトコール・レイヤのコンポーネントベースの形式と共に動作する。即ち、フレームワークは構成可能なプロトコールをサポートする。
・ プロトコール・リコンフィギュレーションは、“リコンフィギュレーション・マネージャ”ユニットの制御／管理を要求する。
・ 提案されたオープン・プログラマブル・プロトコール・インターフェースのための二つの異なる実装モデルは、提案され、評価された。２つとも、プロトコール・スタック・リコンフィギュレーションをサポートするために要求される柔軟性を提供するものである。第１の方法はインターフェースがオブジェクトとして実装されるアーキテクチャを提案するものである。これに対して第２のものは、ＡＰＩの古典的な定義に従うもので、ＡＰＩは、下位レイヤに実装される、単に形式的な定義である。二つの実装方法はＯＰｔＩＭＡ内でサポートすることが出来るけれども、現行ＯＰｔＩＭＡアーキテクチャは二つの実装モデルのうちの前者に基づくものであった。
・ 既存の基本プロトコール・クラス及びカスタム化を拡張することによって、アプリケーション−特化の振る舞い（ｂｅｈａｖｉｏｕｒ）を実装することは可能である。即ち、ユーザは、自分達自身のカスタム・プロトコール・スタック、プロトコール・レイヤ又はコンポーネントの付加／消去を所与のレイヤ内で、インストールし動作させることが許される。こうして、プロトコールの機能／コンポーネントをアプリケーションの要求に合わせることができる。ベンダが、プロトコール・クラスを適当なＡＰＩ／ＰＰＩに対応して実装することを前提とする。
・ 提案されたＰＩは、アプリケーションＱｏＳをネットワーク及びリンク・レイヤのＱｏＳパラメータにマッピングすることが出来る。このことは、無線移動ネットワーク内で要求される事である。
・ ＯＰｔＩＭＡアーキテクチャはＪａｖａで実装される。Ｊａｖａが、コード・モービリティ、ＯＯ特性、直列化（ｓｅｒｉａｌｉｓａｔｉｏｎ）、継承及びカプセル化特性をサポートすることから、Ｊａｖａプラットフォームを選択した。
【図面の簡単な説明】
【図１】
古いタイプのＧＳＭの制御プレーン（Ｃ）と‘アクティブ・プログラム・インターフェース’プロトコール・スタックとの間との比較図である。
【図２】
スレッド・制御メッセージ・ハンドリングを示す概略図である。
【図３】
プロトコール・スタック構成及びプロトコール・スタック・クラス・ライブラリの関係図である。
【図４】
プロレイヤ・クラスの構成を示す図である。
【図５】
インターフェース・クラス階層図である。
【図６】
スレッド・クラス階層図である。
【図７】
インターフェース・プリミティブと各レイヤーとの関係を示す図である。
【図８】
ＰＳクラス関係を表す図である。
【図９】
各階層とクラス関係を示す図である。
【図１０】
アクティブ・インターフェース・オブジェクトの構成図である。
【図１１】
プロトコール・スタック内のクラス関係を示す関連図である。
【図１２】
プロレイヤとプロインターフェースのためのフレームワーク図及びスレッド・クラスの例を示す図である。
【図１３】
モデル・インプリメンテーション・プロトコール・スタックの図である。
【図１４】
図１３のモデルで用いたサーバ・アプレット図である。
【図１５】
図３のモデルで用いたクライアント・アプレット図である。
【図１６】
ＱｏＳ修正メッセージ・シーケンス図である。
本発明は、プロトコール・スタック及びプロトコール・スタックを有する通信システムのような通信システムに関する。
【０００２】
本発明は、専用的ではないが特殊なアプリケーションに対し、所謂ソフトウェア・リコンフィギュラブル無線（ＳＷＲ：ｓｏｆｔｗａｒｅ−ｒｅｃｏｎｆｉｇｕｒａｂｌｅ ｒａｄｉｏ）、即ちソフト無線を提供するものである。
【０００３】
現在、プロトコール・スタックは、マルチプル・レイヤが互いの上に位置付けされ（即ち、成層方法（ｓｔｒａｔｉｆｉｃａｔｉｏｎ ａｐｐｒｏａｃｈ））、各レイヤは他のレイヤに対し、内的機能及びサービス・アクセス・ポイント（ＳＡＰ）として知られている標準化されたインターフェースを使ったアプリケーションを提供するよう実施されている。
【０００４】
更に特定すれば、プロトコール・スタックは数個の単一プロトコール（レイヤ）の集合であり、各プロトコールは、或る機能を有し、或るタスクを行うものである。従来のものでは、プロトコール・フレームワークは複合メカニズムとしての成層方法を使用している。スタックの１レイヤにおけるプロトコールは、下位のレイヤの特性に鈍感である。各レイヤは“ブラックボックス”として扱われ、スタックにおいて発生する可能性のある機能冗長性を特定／バイパスするメカニズムを有しない。
プロトコール・スタックを文書化した例はＯＳＩＲＭ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌ）であり、これは、次の７レイヤからなる。即ち、アプリケーション・レイヤ、プレゼンテーション・レイヤ、セッション・レイヤ、トランスポート・レイヤ、ネットワーク・レイヤ、データ−リンク・レイヤ、及び物理レイヤである。これらの各レイヤは、次の上位レイヤにサービスを提供し又は、直近下位レイヤからのサービスを予定するという完全なプロトコールを表している。この構造は“Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ”（Ａ．Ｓ．Ｔａｎｅｎｂａｕｍ，第３版、Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，１９９６発行）に記述されている。同じ原則が、移動及び固定ラインの通信ネットワークに適用されている。そしてインターワーキング機能（ｉｎｔｅｒｗｏｒｋｉｎｇ ｆｕｎｃｔｉｏｎａｌｌｉｔｙ）は別々のプロトコールで定義される。レイヤ間の通信はＳＡＰを通して行われる。これらＳＡＰを通して、或るレイヤのプリミティブのセットは、次の上位レイヤで利用可能になる。サービスはレイヤ内で実装される操作（ｏｐｅｒａｔｉｏｎ）を定義し、上位レイヤにより要求される。実際に、ＳＡＰはレイヤをカプセル化し、レイヤの複雑性を隠し、レイヤが提供する機能及び上位レイヤユーザーがレイヤから要求するものを一通りに記述するのに用いられる。しかし、ＳＡＰは静的で、柔軟性を欠く。ＳＡＰはプロトコール・スタックにおける柔軟な変化をサポートしないし、変更が必要となる時には、再標準化されることが必要である。
【０００５】
従来のプロトコール・スタックの欠点は、特に、ＳＷＲ実装に重大な障害をもたらす。ＳＷＲは、再プログラミング（例えば、“Ｔｈｅ Ｓｏｆｔｗａｒｅ Ｒａｄｉｏ Ａｒｃｈｉｔｅｃｔｕｒｅ”、Ｊ Ｍｉｔｏｌａ ＩＩＩ 、ＩＥＥＥ Ｃｏｍｍ．Ｍａｇ．Ｍａｙ １９９５ ｐｐ２６−３８ 及び“Ｔｈｅ Ｌａｙｅｒｅｄ Ｒａｄｉｏ”Ｍ Ｂｕｔｌｅｒ ｅｔ ａｌ， ＭＩＬＣＯＭ， １９９８， ｐｐ １７９−１７９）を行って様々な異なる標準又はプロトコールを実装する万能無線（ａｌｌ−ｐｕｒｐｏｓｅ ｒａｄｉｏ）へ進化している。マルチモード・ターミナルは、可能な／既存の標準を含む“Ｖｅｌｃｒｏ ａｐｐｒｏａｃｈ”を用いないものであるが、ＳＷＲは、該マルチモード・ターミナルに対する重要な代替手段として登場している。それ故、種々のサービス品質（ＱｏＳ）要求及び種々のトラフィック特性を有する多くの多様なアプリケーションをサポートするために、次世代の移動端末とネットワークノードには、制御面でかなり豊富な能力が要求される。
【０００６】
ＳＷＲ端末は、また、再プログラム可能でなければならない。このリコンフィギュレーション要請は物理レイヤだけに限られるものではない。要するに、仮にソフトウェア・ダウンロード、リコンフィギュレーション及び管理に対する能力が端末に備えられ、ネットワークのインフラストラクチャーによりサポートされるなら、将来のＳＷＲ端末、装置及びネットワーク・エンティティは、アプリケーションの必要性とユーザーの好みに対し効率的に対応することができる。しかし、これは既存の固定プロトコール成層方法では、できない。
【０００７】
本発明の１つの目的は、前記の問題の少なくともいくつかについて，問題を軽減することである。それは、従来のプロトコール・スタックで使用されている静的なＳＡＰに置換わるアクティブ・プログラミング・インターフェース（プロトコール・プログラミング・インターフェース（ＰＰＩ）／アプリケーション・プログラミング・インターフェース（ＡＰＩ））を有するプロトコール・スタックを提供することにより実現される。
【０００８】
“Ｔｏｗａｒｄｓ ａｎ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ”（Ｄ Ｔａｎｎｅｎｎｂａｕｍ ｅｔ ａｌ， Ｃｏｍｐ．Ｃｏｍｍｕｎ．ＲｅｖＶｏｌ２６，Ｎｏ２，Ａｐｒ １９９６）、“Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ Ｓｏｕｒｃｅｓ ｆｏｒ Ｗｉｒｅｄ／Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｓ”（Ａ Ｋｕｌｋａｒｎｉ ｅｔ Ａｌ， Ｐｒｏｃ．ＩＮＦＯＣＯＭ９９，Ｖｏｌ３，ＮＹ１９９９）及び“Ｃｏｍｐｏｓｉｎｇ Ｐｒｏｔｏｃｏｌ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ａｃｔｉｖｅ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｓ”（Ａ Ｋｕｌｋａｒｎｉ ｅｔ ａｌ ＩＥＥＥ Ｃｏｍｍｕｎ Ｍａｇ Ｍａｒ ２０００）に記載されているように、アクティブ・ノードとインターフェースは、新たなマルチメディア・アプリケーションをサポートし、メディア・プロトコール（インターネット及びＩＮ）と異なるシグナリング・システム（ＳＳ７，Ｈ３２３等）の間のインターワーキング機能の円滑化を提供して、特殊化又は統合化サービスの導入を促進する。同様に、ネットワーク管理は、更にインテリジェントになり、ネットワーク能力は、ネットワークのインフラストラクチュアのアップグレード化を必要とせず、ソフトウェアを変更することで、急速に進化している。このように、将来のリコンフィギュラブル移動ネットワークは、アクティブ・ノードとサービス・インターフェースの発展から恩恵を受けることが予想される。
【０００９】
プロトコールレイヤ間にプログラミング・インターフェースを導入するリコンフィギュレーションは、高級プログラミング言語（例えば、ジャバアプリケーションは異なるＡＰＩを使用する。ＡＰＩは、実行時結合しているクラス・ライブラリーの一部である。これは、機能が、ＡＰＩへのアウトソースされ、アプリケーションが単にシーケンスを定義し、ＡＰＩ内の方法に渡すパラメータを決定することを意味する。）でアプリケーションを書くのと同様のやり方で、単一プロトコール又は全プロトコール・スタックを書く可能性を開くものである。ソフトウェア無線設計における他の重要な設計問題は、無線の本来のリコンフィギュレーション（即ち、動作時リコンフィギュレーション管理、ｏｖｅｒ−ｔｈｅ −ａｉｒダウンロード・プロトコール（“Ｔｅｒｍｉｎａｌ Ｒｅｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ−Ｔｈｅ Ｓｏｆｔｗａｒｅ Ｄｏｗｎｌｏａｄ Ａｓｐｅｃｔ” Ｋ Ｍｏｅｓｓｎｅｒ ｅｔ ａｌ ＩＥＥ Ｉｎｔ Ｃｏｎｆ Ｏｎ ３Ｇ ２０００，Ｍａｒ ２０００，Ｌｏｎｄｏｎ ＵＫに説明されている）及びセキュリティ関連を管理するリコンフィギュレーション管理）に関するものである。
【００１０】
この一般問題に対するもう１つの文書化されたアプローチは“Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｅｎｖｉｒｏｎｍｅｎｔ”（ＭＡＳＥ）である。これはＡＣＴＳプロジェクト“ Ｏｎ ｔｈｅ Ｍｏｖｅ”ｔｈｅ Ｇｌｏｂａｌ Ｍｏｂｉｌｅ ＡＰＩ Ｆｒａｍｅｗｏｒｋ， ｔｈｅ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｅｘｅｃｕｔｉｏｎ （ＭＥｘＥ）ＧＳＭ ０２．５７Ｖ７０．０ＥＴＳＩ，１９９８ 、及び、 ＩＥＥＥ Ｐ１５２０ ネットワークのためのアプリケーション・プログラミング・インターフェースのためのＩＥＥＥ標準の一部として開発されたものである。
【００１１】
本発明によれば、スタックは、スタックのリコンフィギュレーションをサポートすることが出来るアクティブ・プログラミング・インターフェースを組み込んだ構成を有し、このようなスタックを有する通信システムのためのプロトコール・スタックを備える。
【００１２】
アクティブ・プログラミング・インターフェースは、オブジェクトであり、オブジェクト指向設計原則に適合させる必要がある。
【００１３】
本発明は新概念を導入するものであり、この新概念とはプロトコール・レイヤ間のインターフェースを再定義するもので、プロトコール・スタック内の異種レイヤ間のインターアクションを分類し、プロトコールのリコンフィギュレーションをサポートする構成を備えるものである。これは、アクティブ・プログラミング・インターフェースを、プロトコール・スタック内のオブジェクトとして実装することにより、又、この新規のプロトコール・スタック構成を定義するオブジェクト指向設計方法を用いることにより達成することができる。標準化されたアクティブ・プログラミング・インターフェースは、端末及びネットワークにおいてプロトコール・スタックの標準的リコンフィギュレーションに必要な追加的自由度を導入する
【００１４】
本発明の実施例を図面に基づいて説明するが、これは一実施例であって、これに限定されるものではない。
説明する実施例はオープン・プロトコール・プログラミング・インターフェース・モデル及び、以下ＯＰｔＩＭＡと呼ぶアーキテクチャに適合するものである。
【００１５】
（最適なアプローチ）
ソフトウェアのリコンフィギュレーションは、ソフトウェア規定無線（ｓｏｆｔｗａｒｅ ｄｅｆｉｎｅｄ ｒａｄｉｏｓ）を実現するのに不可欠の技術であるとされて来ている。主たる重要な機能はプロトコール・ソフトウェア‘ｏｎ ｔｈｅ ｆｌｙ’を交換する能力及び完全なプロトコール・スタックを再構成（ｒｅｃｏｎｆｉｇｕｒｅ）する能力であり、これは様々な環境で必要となるものである。
【００１６】
ここに紹介する方法はプロトコール・スタック・リコンフィギュレーションのためのフレームワークを与えるものである。プロトコール・スタックは、クラス・ライブラリーを構成する一般“ｃｌａｓｓｅｓ”のタームで記述される多数の機能エンティティティに分解される。これらは、リコンフィギュラブル・プロトコール・スタックを実装するために、動作時にダイナミックに結合する。そして、フレームワークは、構成要素であるプロトコール（ｃｏｍｐｏｓｉｂｌｅ ｐｒｏｔｏｃｏｌ）をサポートすることができる。単一のプロトコール・レイヤは、特定の機能を実装する一群のコンポーネントによって置換され得る。ソフト無線端末の内部で、“リコンフィギュレーション管理”ユニットが、コンポーネントの選択、削除／アップグレード及びＰＰＩとの通信を制御する。ＯＰｔＩＭＡ仕様によれば、定義されたＡＰＩ及びＰＰＩを使って、標準化され、財産権のあるプロトコール・スタックを、作成／実装するためのガイドラインが提供される。
【００１７】
（ＩＩ．１ アプリケーション・プログラミング・インターフェース及びオブジェクト指向設計原則）
一般に、インターフェースは、数個の下部レイヤの隠れた機能へのアクセス・ポイントを表現するものである。このようなインターフェースの目的は、複雑な機能の実装をカプセル化すること、及びこの機能をユーザー／プログラマー／アプリケーションに対しこの機能へのアクセスを最も簡単な形で提供することである。
【００１８】
アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、一般的に、インターフェースが実際には如何に複雑に機能が実現されるか、その複雑さを隠しているものであるという、パラダイムに基づいている。これによれば、プログラマーは、各単一機能呼び出しに対し、どのようにインターフェースを使い、どのパラメータを渡せばいいかについてのガイドラインに従えばよい。アプリケーションは、これらＡＰＩ実装の範囲内で予め定義された機能の一連の呼び出しとなる。従って、このアプリケーション内での多くの複雑性は、下位レイヤに、これらプログラミング・インターフェースの下に隠される。ＡＰＩの利点の一つは、その拡張性と、部分的な、又は、完全な交換可能性（この交換可能性はアプリケーション・コードの完全な再書き込みを必ずしも要求しない）である。プログラミング・インターフェースの他の利点はスケーラビリティと、この構成の単純な使用である。
【００１９】
オブジェクト指向の基本アイデアは、システムの動作と特性を、例えば、“Ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ Ａｎａｌｙｓｉｓ，ｂｙ Ｃｏａｄ ｅｔ ａｌ， ２ｎｄＥｄｉｔｉｏｎ，Ｅｎｇｌｅｗｏｏｄ Ｃｌｉｆｆｓ，Ｎ Ｊ： Ｙｏｕｒｄｅｎ Ｐｒｅｓｓ，１９９１ ”に記載される個別エンティティ（ｄｉｓｃｒｅｔｅ ｅｎｔｉｔｉｅｓ）に組み込むことである。また、このことは、システムの機能的に異なるパーツを特定することを要請する。一旦、エンティティ及び、これらエンティティの状態又は動作（機能ｆｕｎｃｔｉｏｎａｌｉｔｙ）間の内部関係が解析されると、クラスとして形成（ｆｏｒｍａｌｉｓａｔｉｏｎ）され、記述がなされる。オブジェクト指向は、数多くの基本原則に基づいている。例えば、クラスはその主要な１つである。更に概念として、“ＯｂｊｅｃｔＯｒｉｅｎｔｅｄ Ａｎａｌｙｓｉｓ ａｎｄ Ｄｅｓｉｇｎ ｗｉｔｈ Ａｐｐｌｉｃｔｉｏｎ”（Ｂｏｏｃｈ，２ｎｄＥｄｉｔｉｏｎ，Ｂｅｎｊａｍｉｎ／Ｃｕｍｍｉｎｇｓ Ｐｕｂｌｉｓｈｉｎｇ， Ｒｅｄｗｏｏｄ Ｃｉｔｙ，ＣＡ １９９１）に記載されているように、オブジェクト、アブストラクション、属性、操作／メソッド／サービス、メッセージ、カプセル化、継承（Ｉｎｈｅｒｉｔａｎｃｅ），ポリモーフィズム、再使用がある。例えば、大半のＪＦＣ（Ｊａｖａ Ｆｏｕｎｄａｔｉｏｎ Ｃｌａｓｓｅｓ）は、基本クラス‘オブジェクト’から（１乃至数レベルの階レイヤを経て）派生するクラスにおいて実装される。同様のことが、ＭＦＣ（Ｍｉｃｒｏｓｏｆｔ Ｆｏｏｕｎｄａｔｉｏｎ Ｃｌａｓｓｅｓ）に応用できる。該ＭＦＣは、ウィンドーズ・プラットフォームに対するアプリケーション・プログラミングの基本実装クラスを有している。
【００２０】
（ＩＩ．２ システム・アーキテクチャ）
ＯＰｔＩＭＡモデルの目的の１つは、フレームワークを導入することである。フレームワークによれば、実装時のプロトコールの交換、及びレイヤ処理系にアクセスせずに、異なるプロトコール・スタック・レイヤのインターフェース間で直接シグナリング通信を可能にするようなインターフェースの積極的な関与を可能にする。このためには、システムに対し、多少異なる考え方をしなければならない。
このアプローチにおいては、プロトコールは、図１に示される‘プロインターフェース’及び‘プロレイヤ’に２分される。
【００２１】
プロインターフェースは、基本クラスから派生するクラス内で定義されるａｃｔｉｖｅ 実装である。ここで、エンティティの定義は、スタックにおける位置（ｐｏｓｉｔｉｏｎ）による（プロインターフェース→２つのプロレイヤの間）。この基本クラスは全ての可能なプロインターフェースの一般機能（ｇｅｎｅｒｉｃ ｆｕｎｃｔｉｏｎａｌｉｔｙ）を定義する。更なる特化は、その後派生されたプロインターフェース・クラス内で達成される。オブジェクトとして実装されると、インターフェース（即ちプロインターフェース）は、追加機能及び追加アーキテクチャー複合体（ａｒｃｈｉｔｅｃｔｕｒａｌ ｃｏｍｐｌｅｘｉｔｙ）を引き渡す。
【００２２】
プロレイヤはアクチュアル・プロトコール実装であり、これはプロインターフェースを通してデータを取得し、これらデータを操作し、プロインターフェースを介してこれらデータをエクスポートするものである。プロインターフェース及びプロレイヤ・クラス内での機能／メソッドの実装はスレッド・オブジェクト（ｔｈｒｅａｄ−ｏｂｊｅｃｔ）により管理される。このような構成は、実装時、古典的なプロトコール・スタックに代えて、フレキシブルなスタックリコンフィギュレーションを可能にするという、高度に柔軟なプラットフォームを提供する。換言すれば、スレッド・オブジェクトは、全てのプロレイヤ及びプロインターフェースに亘って、メッセージ転送と操作を管理するクラスの実装を行う。
【００２３】
図２に示されるように、到着すると、スレッドは、完全プロトコール・スタック内でメッセージとその処理に対して責任を引き受け、これらメッセージのレファレンスをその宛先に渡す。
【００２４】
（ＩＩ．３ クラス・アーキテクチャ）
図３には、プロトコール・スタックの‘機能分割（ｆｕｎｃｔｉｏｎａｌ ｄｅｃｏｍｐｏｓｉｔｉｏｎ）’が示されている。該スタックは、オープン・プロトコール実装のための基本的エンティティから合成されるものである。
【００２５】
下記の４つの異なるクラス・タイプが特定される。
１．レイヤ・クラス（Ｌ−クラスがプロレイヤを定義する）が、プロトコール・スタック内で（即ち、物理レイヤの（Ｐ−Ｌ）−，リンク・レイヤの（ＬＣＬ）−，ネットワーク・レイヤの（ＮＣＬ）−及びシグナリング・アプリケーション（ＢＳＡ）−機能）単一プロトコールの機能を表す。図４に示したように、レイヤ・クラス（プロレイヤ）は、一般（プロ）レイヤ・クラスから機能を継承する。
【００２６】
２． プログラミング・インターフェース・クラス（ＰＩ−クラスはプロ−インターフェースを定義する）は、プロトコール（Ｌ−クラス）間の各種プログラミング・インターフェースを表す。ＰＩ−クラスは、基本クラス（ＧＰＩ）で定義される一般的プリミティブを特定し、実装するメソッドから構成される。クラスの構成及びプリミティブの記述は、図５と図７にそれぞれ示されている。ＰＩクラスはイベント（即ち、数個のプロトコールからのメッセージ）を検出し、適切なスレッドの実装にトリガーをかける。
【００２７】
３． スレッド・クラス（Ｔクラス）は予め定義した手順（例えばコネクション、モービリティ、無線源又はＱｏＳの管理−シグナリング）を実装する。図６に示されているように、他の、定義されていない、標準化されていないシグナリング手順はカスタム化されたスレッド・クラス、即ち（ＳＳＴ）内で実装される。メッセージ列の実装に加えて、スレッドも、完全なプロトコール・スタックの柔軟性を高める。シグナリング手順を実装するためにスレッドを使用すると、プログラマーが、数個のシグナリング手続きを並列に実装することができる。この特徴は、１点−多点通信に関し有利である。スレッド・クラスは一体化され、ＰＩ及びＬクラスにおいて定義されたメソッドを用いる。
【００２８】
４．プロトコール・スタック・クラス（ＰＳクラス）は完全なプロトコール・スタックの実装を定義する。種々の旧式スタック（例えば、ＧＳＭスタック）は、標準を実装するための適当なクラスを含む特定の構成子（ｃｏｎｓｔｒｕｃｔｏｒ）を使う。他方では、他のスタックは自由に定義することが出来る。ＰＳクラスは、プロトコール・クラス・ライブラリー内で公衆がアクセスできる唯一のクラスである．更に、図８に示すように、ＰＳクラスは、Ｌ，ＰＩ又はＴクラスが実装中に交換される時に、プロトコール・リコンフィギュラビリティ（再構築可能性）を管理する。図示の通り、スレッド・クラス（ＳＳＴ）はＰＩ及びＬクラスで定義されたメソッドを使う。
【００２９】
要約すれば、Ｌ，ＰＩ及びＴクラスは、プロトコール・スタックの能力、メソッド及び性質を定義し、他方、ＰＳクラスはこれらクラスを実装し、又、プロトコール・スタック構造を定義する。
【００３０】
（ＩＩ．４ 設計ガイドライン）
ＯＰｔＩＭＡは、前記クラス及び一組の設計ルール（該ルールは、どのようにクラスと完全なプロトコール・スタックを実装するかを定めるものである）に基づく。プロトコール・スタック実装の基礎は、図１２Ａ及び図１２Ｂに示されるコード−スケルトンである。
１つのプロトコール・スタック内で、‘プロトコール・スタック’クラスは一般インターフェースをエクスポートする唯１のクラスである。それはＬ，ＰＩ及びＴオブジェクトを実装し、プロトコール・スタックの構成を定義するものである。アーキテクチャは、全体として、異なるインターフェースと異なるレイヤクラスの両方の階層構造を定義するために継承（ｉｎｈｅｒｉｔａｎｃｅ）を使う。従って、それは、プロインターフェース及びプロレイヤをそれぞれ派生するために、一般的インターフェース・クラス及び基本プロトコール・クラスを使用する。
【００３１】
（ＩＩ．５プロトコール・スタック及びスレッド・クラス）
クラス（ＰＩ，Ｌ，Ｔ）の３グループが、プロトコール・スタック・クラスのインスタンスによってインスタンス化され、実装され、管理される。従って、このＰＳオブジェクトは、完全なプロトコール・スタックを定義する。機能グループ（スレッド、インターフェース及びレイヤ）の１つの中でクラスはクラス・ライブラリーに位置している。各クラス・ライブラリーは、特殊な（派生の）クラスの或るグループのために機能を提供する。図３は、プロトコール・スタック及びそのクラス・ライブラリー内におけるクラスの依存関係及び‘論理的位置’を示す。スレッド・クラスは、プロトコール・スタック中を通るメッセージを実際に管理するエンティティである。スレッド・クラスは単一のメッセージ・シーケンスを処理するために使用される（即ち、各スレッドは１シーケンスを管理する）。
【００３２】
（ＩＩＩ ．プロトコール・レイヤ及びインターフェースの合成）
プロトコール・スタック機能をプロレイヤ及びプロインターフェースに分離することは、プロトコール・スタックに対して新たなパラダイムが形成される。そこでは、機能の分散がオープン・プロトコール・プログラミング・インターフェースにより容易になる。図示された実装では、ＯＰｔＩＭＡアーキテクチャは５つのレイヤから構成されており、各レイヤはそれ自身のタスクと機能を有している。‘分解された’プロトコール・スタック（プロレイヤ、プロインターフェース及びスレッド）内の全てのエンティティは、分離クラス（ｓｅｐａｒａｔｅ ｃｌａｓｓｅｓ）として実装される。プロレイヤ・クラス（Ｌクラス）は、そのプロトコール（レイヤ）の属性を含んでおり、対応するプロレイヤから（及びに関連して）得られる情報を格納するために使用される。Ｌクラスのメソッドは入力する情報を処理し、適正な応答を生成し、続くシーケンスを開始するために使われる。この実施レイヤにおいては、レイヤクラス及びその機能は以下の通りである。
物理レイヤ（モデム、チャネルアクセス、ＦＥＣ，暗号化等）
リンク・レイヤ制御（リンク制御）
ネットワーク制御レイヤ（制御メッセージ・ルーティング）
シグナリング・アプリケーション・レイヤ（接続制御、ソース及びモービリティ管理シグナリング）
アプリケーション・レイヤ、ＡＰＩ仕様に適合するアプリケーション
【００３３】
（ＩＩＩ ．１アクティブ・プログラミング・インターフェース）
プロレイヤはプロインターフェース（ＰＩ）により分離され、隔離される。これにより、交換可能性と拡張可能性（動作中のプロトコール実装の）が確保される。この意味で、プロトコールは、プロレイヤに対し、レガシー（旧タイプ）・プロトコールである。これに対し、プロレイヤは、ＯＰｔＩＭＡ内でのレガシー（そして財産権の可能性を持つ）プロトコール機能の実装である。適当なＰＩが定義され（図５のクラスアーキテクチャを参照）、プロトコール実装（プロレイヤ）間に導入される。
プロインターフェースはオープン・プロトコール−プログラミング・プラットフォームを提供する。プロインターフェースは、シグナリング・メッセージの相互交換を可能にし、プロトコール・レイヤ・クラスへアクセスを渡す。この実施例では、４つのインターフェース・クラスが完全プロトコール・スタックを実装するために定義される（図５参照）。
ＰＰＩ１２ （物理レイヤとリンク・レイヤ制御との間）
ＰＰＩ２３ （リンク・レイヤ制御とネットワーク制御レイヤとの間）
ＰＰＩ３４ （ネットワーク制御レイヤとシグナリング・アプリケーション・レイヤの間）
ＡＰＩ （アプリケーション・プログラミング・インターフェース）
【００３４】
プロインターフェースは一般インターフェース・クラス（ＧＰＩ）から派生したもので、プリミティブとして知られている制御メッセージの４つの基本タイプを定義する。プリミティブのタスクは、イベントについて各プロレイヤに通知し、プロレイヤとトリガー・メソッド（該メソッドは、これらプロレイヤ・クラスに実装される）との間の変数に対し新しい値を渡す事である。図７を参照すると、これら４つのプリミティブ・タイプは以下の通りである。
サービス・リクエスト・メッセージ（ＳＲＭ）：典型的には非永続的な即時動 作を実装する非同期プリミティブ。ＳＲＭに対する流れの方向は上位レイヤか ら下位レイヤへである。
リクエスト応答（ＲＲ）：永続状態又は長期間計測プリミティブ。
ＲＲに対する流れの方向は下位レイヤから上位レイヤへである。
レイヤ状態情報（ＬＳＩ）：永続状態プリミティブ。ＬＳＩに対する方向は、 上位レイヤから下位レイヤへである。
非同期イベント通知（ＡＥＮ）：最新の、典型的には非永続的イベントをレポ ートするプリミティブ。ＡＥＮに対する流れの方向は常に下位レイヤから上位 レイヤへである。
【００３５】
オブジェクト指向のプログラミング技術の開発に当たり、各プロインターフェース・クラスは、ＧＰＩと呼ばれるスーパークラスから一般機能を継承する。この‘親’クラスは、分離エンティティとして、実装プロトコール・スタックの一部ではない。しかし、それは、図９に示すように、全ての（派生された）ＰＩに対し、最小アクセス・インターフェース（即ちプリミティブ）を独占的に定義する。全般的アーキテクチャ上のフレームワークとの関連でアクティブ・インターフェース・オブジェクトのオブジェクト指向構成は、追加的特徴の実装を可能にする。即ち、（アクティブ）プロインターフェースは、アプリケーション開発のために、メッセージを渡し、共通シグナリングとデータＡＰＩを容易にするために、代替媒介物（ａｌｔｅｒｎａｔｉｖｅ ｍｅｄｉｕｍ）を提供する。
【００３６】
図１０に示されているように、アクティブ・インターフェースは以下の２通りの方法によりプロレイヤ内で属性へのアクセスを提供するために使用される。：連続的方法（シリーズＡ）及び非連続的方法（シリーズＢ）。シリーズＢにおいては、プロレイヤＮＣＬからの属性は、ＰＰＩ及びＡＰＩプロインターフェースを通して、これら属性を必要としないＢＳＡプロレイヤを飛び越え、アプリケーション・レイヤに供給される。
【００３７】
このアーキテクチャの利点は、ＯＰｔＩＭＡが異なる通信ネットワークで使用されるとき明らかになる。アプリケーションのためのシグナリング・インターフェースは、実装プロトコール・スタックとシステムのトランスポート手段とから独立しており不変である。目標のシグナリング・システムへの適応は適当なプロトコール（プロレイヤ）において行われ、実装中柔軟に交換され得る。
【００３８】
（ＩＩＩ ．２ アーキテクチャの全般的な実装）
Ｌ及びＰＩクラスは、オープン・プログラマブル・プロトコール・インターフェースに基づくプロトコール・スタックを実装する２つの主要ファミリ・グループを形成する。しかしながら、シグナリング・シーケンスを制御し、周期的なタスクを処理し（例えば、最下位レイヤにおけるチャネル測定）、外部トリガーに応答する際に必要な機能も備えねばならない。
【００３９】
これらのタスクを行うために、スレッド・クラス（Ｔクラス）のファミリが導入された。実装に当たり、それらは、現行メッセージ処理を実装するために、Ｊａｖａ（登録商標）のマルチスレッド特徴を用いる。Ｊａｖａを実装プラットフォームとして選択した。それは、Ｊａｖａの特徴として、ダイナミックな結合とプラットフォーム独立性があるからである。しかし、Ｔクラスは他の機能を定義しない。むしろ、Ｔクラスは、Ｌ（及びＰＩ）クラスで定義されたメソッドにアクセスし、これらクラスの適当な機能を呼び出す。スレッドの優先性（従ってメッセージ・シーケンスの実装優先性）は、スレッドのインスタンス化の期間に定義される。
【００４０】
プロトコール・スタック・クラス（ＰＳクラス）は、全プロトコール・スタックを表す。このクラスの属性は他の（前記した）全てのクラスのインスタンスである。このように、ＰＳクラスは、Ｌクラスの機能と情報を用い（ｅｘｐｌｏｉｔ）、ＰＩクラスで定義したプリミティブを使用し、インスタンス化されたＴオブジェクトのタスクの実装を制御する。これは、ＰＳクラスのインスタンスが、要求されるオブジェクトを実装することにより、所望のプロトコール・スタック機能を渡すことを意味する。適当なＰＳクラスの構成要素（ｃｏｎｓｔｒｕｃｔｏｒ）は標準プロトコール・スタック（これら標準のためのレイヤクラスが利用可能であることを条件として）を実装するために使用することが出来る。この構成を使用すると、プロトコール・スタックは、適当なクラス（プロレイヤ及びスレッド）を交換することにより、どのような要求にもダイナミックに適応することができる。
【００４１】
次のクラス関係は、アーキテクチャの複雑性を表す（図１１参照）。
【００４２】
ＬクラスはＰＩクラス定義に依存する。：Ｌオブジェクトは、上位又は下位レイヤと通信するためにＰＩクラスのプリミティブにアクセスできるが、一方、ＰＩクラスはＬオブジェクトにおいて格納された情報へのアクセスを提供するか、又は、この（Ｌ）オブジェクト内で実装されるメソッドをトリガーする。
【００４３】
Ｌ及びＰＩクラスはＴクラスに依存する。：Ｔオブジェクトは、予め定義したタスクを実行するために、適当な属性並びにＬ及びＰＩオブジェクトのメソッドを使うことが出来る。
【００４４】
ＰＳクラスはＬ、ＰＩ及びＴオブジェクトを属性として持つ。：ＰＳオブジェクトはこれらオブジェクトにおいて定義された機能及び情報を使うことができる。
【００４５】
ＴクラスはＰＳクラスに依存する。：ＰＳオブジェクトはその主なメソッドにおいて様々なスレッドの開始と停止を制御するが、Ｔオブジェクトは、単に、タスク実装に責任を有するのみである。図１１にこれを示す。
【００４６】
全てのクラスはクラス・ライブラリに組立られている。クラス・ライブラリは、どのようなネットワーク・エンティティに対しても、要求されるシグナリング機能を提供する。何故クラスをパッケージとしてグループ化するかの理由は、セキュリティに基本レベルを設けるからである。ＰＳクラスを宣言することにより、他のオブジェクトは、どのような他の非関連のオブジェクトに対しても、（理論的には）不可視（ｉｎｖｉｓｉｂｌｅ）になり、アクセス不可になる。
【００４７】
Ｔオブジェクトは、直接ＰＳオブジェクトの主たるメソッドにおいて用いられるが、Ｌ、ＰＩ及びＴオブジェクトは、ＰＳクラス内で属性として使用される。そして、これら属性はインスタンスであり、プロトコール・スタックのメンバーとして適当なオブジェクトを定義する。例えば、ＰＳオブジェクトのレファレンスはＬクラスのメソッドにおけるパラメータとしてよく用いられる。このように、仮にＬオブジェクトのメソッドが呼び出されたならば、オブジェクトは、同一のＰＳオブジェクトに属するＰＩオブジェクトを特定し、それら属性及びメソッド（即ちメッセージ）を使用する。
【００４８】
図９にこれを示す。プロトコール・スタックに対する２つの操作モードはシグナリング／メッセージ・シーケンスをトリガーする。これらは次の２つである。内部モード（即ち、ＰＳオブジェクトは、外部トリガーでは無く、タイムアウトによりスレッド実装を開始又は終了する）又は外部モード（例えば、アプリケーション又は物理レイヤで生じるイベント）。結果的に、これら２つの操作モードは適当なスレッドのインスタンス化（ｉｎｓｔａｎｔｉａｔｉｏｎ）又は終了に導く。
【００４９】
このアーキテクチャ面からのアプローチの柔軟性は一般ＰＩの導入に基づくものであり、数個の同時発生スレッドを使用することにより更に柔軟性は高められる。一般ＰＩはＬオブジェクトにアクセスし、Ｔオブジェクトをサポートするのに必要な手段を渡すもので、異なるプロトコール・スタック標準をサポートし、実装するために必要な柔軟な構成を提供する。ＰＳの機能エンティティ間のプリミティブの一般の組は、不変である（例え新規なプロレイヤ実装が導入されたとしても、メッセージが４つのプリミティブタイプに適合する限りは）。これは、ＰＩクラスが、変化を受けることなく、プロレイヤ・クラスにアクセス出来ることを意味する。
【００５０】
（ＩＶ 実装モデル）
ここで、ＯＰｔＩＭＡモデルの特定の実装について説明する。
【００５１】
プログラミング・インターフェースの適当な機能を評価するために、メッセージ、メソッド及びクラスに関連した一組のＱｏＳが、クラス・ライブラリにおいて定義され、構成される。ＱｏＳシグナリングをテストケースとして選択した理由は、ユーザが、移動通信ネットワークの未来世代において、混合サービス（例えば、音声／ビデオ／データ及びその他のインターネット・サービス）を要求する時に、予想されるインターラクションの複雑性とＯｏＳの多様性が増大することであった。Ａｕｒｒｅｃｏｅｃｈｅａは（”Ａ ｓｕｒｖｅｙ ｏｆ ＱｏＳ Ａｒｃｈｉｔｅｃｔｕｒｅｓ”， ＡＣＭ／Ａｐｒｉｎｇｅｒ Ｖｅｒｌａｇ Ｍｕｌｔｉｍｅｄｉａ Ｓｙｓｔｅｍｓ Ｊｏｕｒｎａｌ， Ｓｐｅｃｉａｌ Ｉｓｓｕｅ ｏｎ ＱｏＳＸ Ａｒｃｈｉｔｅｃｔｕｒｅ， Ｖｏｌ６， Ｎｏ．３， ｐｐ１３８−１５１， Ｍａｙ １９９８）、多数の異なるＱｏＳアーキテクチャを比較し、それらの独自の特徴を検討している。そして、大半のＱｏＳアーキテクチャは単に、マルチメディア通信のためのエンド・ツー・エンド・ＱｏＳサポートより、むしろ単一アーキテクチャ・レベルを検討していると述べている。更に、ＱｏＳ管理の特徴は、プロトコール・スタックの各レイヤ内で用いられるべきであり、ＱｏＳ制御・管理メカニズムは全てのアーキテクチャ・レイヤ上に正しく配置されるべきであると指摘している。
【００５２】
ここで、エンドーツーエンドに対するサポートとレベル制御されたＱｏＳネゴーシエーションを組み込んだモデルが、機能を示し、ＯＰｔＩＭＡアーキテクチャ・フレームワーク内の通信シグナリングの動作をテストする例として実装された。
その後、一般ＱｏＳシグナリング・メッセージ仕様の定義、プロトコール・スタック記述及びＱｏＳネゴシエーション・インプリメンテーションが続く。モデル１実装はＲＭＩプラットフォーム（ＳｕｎＳｏｌａｒｉｓワークステーション上で実装する）に基づくものである。そこでは多数のアプレットが実装され、シグナリング（アプリケーション）エンド・ポイント表示として使用される。
【００５３】
１組のメッセ−ジとパラメータが、ＯＰｔＩＭＡプロトコール・フレームワーク上に構築された一般ＱｏＳシグナリング構成に対し、特定され、定義される。ＡＰＩ−プロインターフェースに対するメッセージとそのタイプ（即ちプリミティブ）が図１２ｂに示される。メソッド／機能の呼のネーミングは、一般ルールに従う。メッセージ・フォーマット及びメッセージ・ネーム仕様は次のとおり定義される。
［プログラミング・インターフェースの名称］［プリミティブのタイプ］［記述］（アーギュメント／パラメータ）
【００５４】
次のメッセージを例として挙げる。
ＡＰＩＳＲＭＳｅｒＲｅｑ（ＳｔｒｉｎｇＴｙｐｅＯｆＳｅｒｖｉｃｅ）｛ ｝
【００５５】
このメッセージはＡＰＩ（Ｉｎｔｅｒｆａｃｅ ｂｅｔｗｅｅｎ Ｓｉｇｎａｌｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）の一部である。それはプリミティブ・タイプ‘サービス・リクエスト・メッセージ（ＳＲＭ）’から派生するものであり、アーギュメント（例えばｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅ）としてストリングを有する。全てのメッセージ（即ち、ＳＲＭ， ＬＳＩ， ＲＲ及びＡＥＮ）は、下方に又は上方に一方向である。そして、ＳＲＭ及びＬＳＩは下方（上位レイヤから下位レイヤへ）であり、ＲＲ及びＡＥＮは上方に（即ち、下位レイヤから上位レイヤへ）渡される。
【００５６】
上位から下位レベルへ、又は、下位から上位への流れの方向は、又、ナンバリング・システムで表示される。
いくつかのメッセージはＯＰｔＩＭＡの特徴を使用してもよい。また、続くレイヤ以外のレイヤにアクセスしなければならないかもしれない（例えばリンク・レイヤに直接メッセージを送るアプリケーション）。同様に、これはコマンドネーミングで次のように定義される。：ＡＰＩ２ＳＲＭＴｙｐｅＯｆＳＲＭ（ａｒｇｕｍｅｎｔｓ）｛ ｝
【００５８】
この部分の残り（ｒｅｍａｉｎｄｅｒ）は、例として、ＱｏＳシグナリングＡＰＩに対し定義されたＳＲＭ，ＬＳＩ，ＲＲ及びＡＥＮの完全なリストを定める。モデル１はプログラミング・インターフェースのアーキテクチャ及び仕様について検証（ｖｅｒｆｉｃａｔｉｏｎ）及び妥当性検証（ｖａｌｉｄａｔｉｏｎ）を可能にする。ＯＰｔＩＭＡ及びプロインターフェースの実装の固有機能を検証するために、ＡＰＩのＱｏＳメッセージ部分が例として取り上げられてきた。
【００５９】
サービス・リクエスト・メッセージ（ＳＲＭ）
【表１】
レイヤ状態情報（ＬＳＩ）
【表２】
非同期イベント通知（ＡＥＮ）
【表３】
【００６２】
図１２ａ及び１２ｂは、ＱｏＳネゴシエーションのためのスケルトン・コード及びＡＰＩプロインターフェースのためのメッセージの組をそれぞれ意味するものである。そこで、次に、ＡＰＩにおけるＱｏＳネゴシエーションと管理のための実装されたモデルとクラス構造について説明する。
【００６３】
（ＩＶ．１ モデル記述）
モデル１において、実装は、１つのサーバー・アプレット及び多数のクライアント・アプレットからなる。２つのアプレット・クラスはＱｏＳネゴシエーションを表現するものである。ＯＰｔＩＭＡにおいて定義されたＱｏＳクラスは、トランスポート・メディアとしてＪａｖａＲＭＩを使って、クライアントとサーバーの間のメッセージのやり取りを容易にする。
【００６４】
アプレットは、ＱｏＳセッティングを交渉し、表示するために終端へシグナリングするのに使用される。これら終端間の通信はＡＰＩを通して、下位にあるレイヤ・クラス（プロレイヤ）を使って行われる。これは、インターフェース（スタブとスケルトン）を経由してＪａｖａオブジェクト・ブローカ（ＲＭＩ）にＲＭＩ接続を実装するものである。このモデルにおけるクライアント−スタッブ及びサーバー−スケルトンの実装は、プロレイヤ・クラスを表わすものである。プロトコール・スタック（このテスト・プラットフォームにおいて用いられる）はアプリケーション・レイヤ（Ｌクラス）、ＡＰＩ及び、残りのプロトコール・スタックを表す一般レイヤ・クラス（Ｌクラス）から構成される。このモデルの機能は基本クライアント／サーバー原則に基づくものである。それによれば、オブジェクトはネットワークに分散されており、ミドルウェアレイヤ（オブジェクト・ブローカ）を介して通信を行う。クライアントは、リクエスト・ブローカを介して、遠方サーバ・オブジェクトからのサービスを要求する。（ＲＭＩ）ブローカは、それぞれスタブとスケルトンと呼ばれる、クライアントとサーバの実装に関係するインターフェースを使用する。
スタブとスケルトンはクライアントとサーバ間の通信の複雑性を隠すものであり、パラメータのｓｔｅｒｉｌｉｓａｔｉｏｎ とｄｅ−ｍａｒｓｈａｌｌｉｎｇを制御し、遠方にあるエンティティ間の接続を確立し、維持し、終了する。アプリケーション・レイヤ・クラスはアプレット（クライアント・アプレット及びサーバ・アプレット）として実装され、シグナリング終端のグラフィカル・ユーザ・インターフェース（ＧＵＩ）を提供する。ＪａｖａＡＷＴ（アブストラクト・ウィンドイング・ツールキット）はＧＵＩ及び、処理プラットフォームとしてＳｕｎワークステーション上のＳｏｌａｒｉｓを実装するのに用いられる。
【００６５】
一般レイヤ・クラス（ＭＴＩクラス・クライアント及びクラス・サーバ）は、プロトコール・スタックのテスト・プラットフォーム版を表す。このクラスはシグナリング・アプリケーション・レイヤ・クラスから派生するもので、下位レイヤで利用できる全てのＱｏＳ情報はこのクラスを介してアクセスされる。更に、一般レイヤ・クラスはＪａｖａのＲＭＩスタブ及びスケルトン・クラスにアクセスする。
ＲＭＩクライアント及びＲＭＩサーバ・クラスは、別のクラスとして実装され、図１３に示すように、（ＲＭＩ）分散オブジェクトの計算エンドポイントのための手段を提供する。クライアントとサーバのアプレットを、それぞれ、図１４及び１５に示す。そのデータ・フィールドは、要求され、提供されたＱｏＳパラメータを表す。
【００６６】
アプレット‘クライアント’は、次の要素を有する多数のコンポーネントから構成される。
・ テキスト領域、一般イベントについてユーザに通知するのに使用される。
・ ９つのテキスト・フィールド、確立した接続についてのパラメータを表す。
・ 多数選択、ユーザが特定サービスを要求できるようにする。
・ テキスト・フィールド、ユーザが宛先ＩＤを挿入する
・ 多数のボタン、ユーザがターミナルと相互にやり取りする。
【００６７】
アプレット‘サーバ’は以下のコンポーネント・セットから構成される。
・ テキスト領域、一般イベントについての管理者に通知するのに使用される。
・ ９つのテキスト・フィールド欄、確立した接続又はリクエストのパラメータ（最後のリクエストのタイプによる）についてのパラメータを表す。
・ 多数選択の欄、マニュアルでネットワークの現行状態を決める。手でネットワーク状態を決定する事は必要である。というのはユーザデータの現在のフローがないからである。テスト・プラットフォームはプロトコール
・ スタックのシグナリング・プレーン（ｐｌａｎｅ）を実装する。遅延及びＢＥＲのようなフロー・パラメータの測定は不可能である。
・ 選択、これは、管理者が現行ネットワーク状態とは無関係に、全てのリクエストを拒否する事を可能にする。
【００６８】
通信サービスの品質及び接続（又はサービス・リクエスト）によって提供される品質を記述するのに用いられるパラメータは以下のとおりである。
・ 標準：例えば、ＧＳＭ、ＤＥＣＴ他のような標準タイプを決定する。
・ Ｉｄフィールド：クライアントのアイデンティティ（例えば、ＧＭＳのためにＴＭＳＩ／ＩＭＳＩ）を決定する。
・ ロケーションＩｄ：移動クライアント（例えば、ＧＭＳのためのＬＡＩ）の位置を特定する。
・ 帯域幅：接続又はリクエストのバンド幅（ｋｂｐｓで）を決定する。この帯域幅は、標準型に依存して、平均値、最大値、ベスト・エフォート、予測又は保証帯域幅を特定することができる。
・ 遅延：接続又はリクエストの遅延を特定する。それは、標準型に依存して、平均値、最大値、ベスト・エフォート、予測又は保証帯域幅を参照することができる。
・ 優先：接続がそのＱｏＳのレベルを下げる（必要があれば）オーダに関連して、又、接続が資源を回復する（必要があれば）ために開放されるオーダに関連して、接続についての相対的重要性を特定する。
・ 保護：サービス・プロバイダーが非許可モニタリング又はユーザ発信情報の操作を防止しようとするレベルを決定する。
【００６９】
実験装置は、ＳＵＮのＳｏｌａｒｉｓサーバ上で動作するサーバ・アプレット、及び、分散ｘ端末上で動作する多数のクライアント・アプレットから構成した。それらは、ＡＴＭハブ（１０／１００Ｍｂｉｔ／ｓＥｔｈｅｒｎｅｔ（登録商標）接続上で）を介して、サーバマシンに接続した。
モデル１実装の操作例として、我々は、図１６に示すＱｏＳ再交渉のための単純化されたシグナリング・メッセージ・シーケンスの動作を、簡単に説明する。
クライアントが、サーバから既に提供されたサービスの修正を要求する（サービス修正）。それは、クライアントの識別に関連する要求された全てのＱｏＳパラメータ及び情報をサーバに渡す。サーバは、このリクエストを処理し、要求されたＱｏＳ、ローカル資源（即ち、全クライアントに予定している現行ローディング）及び、このクライアントに既に割当てた資源を検査する。そしてサーバーは、クライアントに新リクエストを受け入れるか否か通知する（サービス修正応答）。クライアントは前回のメッセージの受信確認を行う（サービス修正応答の受信確認）。リクエストが受け入れられなかった場合は、クライアントは、前回のＱｏＳ値を維持した現行セッションを切断するか、接続を維持するかどちらかを選択出来る。
【００７０】
前記の実施例は以下の重要な特徴を有する。
・ 一般インターフェース・クラス（ＡＰＩ／ＰＰＩ）のライブラリの詳細仕様を含むプロトコール・リコンフィギュレーション・プラットフォーム（即ちアーキテクチャ上のフレームワーク）が、設けられる。該プラットフォームは、オブジェクト指向プログラミング技術を使って、柔軟なオープンな手法で、リコンフィギュラブル・プロトコール・スタックを実装するために、使用される。
・ （前記定義されたライブラリにおいて備えられた）ＡＰＩ及びＰＰＩを使用する標準と非標準プロトコール・スタックを構成するためのガイドライン／仕様の実装。オープン・プログラミング・プラットフォームを使用すると、アプリケーションとプロトコール・レイヤをどのようにプログラムするかの仕様が要求される。
・ ＡＰＩ／ＰＰＩは、プロトコール・レイヤの旧式な実装と共に、並びに、プロトコール・レイヤのコンポーネントベースの形式と共に動作する。即ち、フレームワークは構成可能なプロトコールをサポートする。
・ プロトコール・リコンフィギュレーションは、“リコンフィギュレーション・マネージャ”ユニットの制御／管理を要求する。
・ 提案されたオープン・プログラマブル・プロトコール・インターフェースのための二つの異なる実装モデルは、提案され、評価された。２つとも、プロトコール・スタック・リコンフィギュレーションをサポートするために要求される柔軟性を提供するものである。第１の方法はインターフェースがオブジェクトとして実装されるアーキテクチャを提案するものである。これに対して第２のものは、ＡＰＩの古典的な定義に従うもので、ＡＰＩは、下位レイヤに実装される、単に形式的な定義である。二つの実装方法はＯＰｔＩＭＡ内でサポートすることが出来るけれども、現行ＯＰｔＩＭＡアーキテクチャは二つの実装モデルのうちの前者に基づくものであった。
・ 既存の基本プロトコール・クラス及びカスタム化を拡張することによって、アプリケーション−特化の振る舞い（ｂｅｈａｖｉｏｕｒ）を実装することは可能である。即ち、ユーザは、自分達自身のカスタム・プロトコール・スタック、プロトコール・レイヤ又はコンポーネントの付加／消去を所与のレイヤ内で、インストールし動作させることが許される。こうして、プロトコールの機能／コンポーネントをアプリケーションの要求に合わせることができる。ベンダが、プロトコール・クラスを適当なＡＰＩ／ＰＰＩに対応して実装することを前提とする。
・ 提案されたＰＩは、アプリケーションＱｏＳをネットワーク及びリンク・レイヤのＱｏＳパラメータにマッピングすることが出来る。このことは、無線移動ネットワーク内で要求される事である。
・ ＯＰｔＩＭＡアーキテクチャはＪａｖａで実装される。Ｊａｖａが、コード・モービリティ、ＯＯ特性、直列化（ｓｅｒｉａｌｉｓａｔｉｏｎ）、継承及びカプセル化特性をサポートすることから、Ｊａｖａプラットフォームを選択した。
【図面の簡単な説明】
【図１】
古いタイプのＧＳＭの制御プレーン（Ｃ）と‘アクティブ・プログラム・インターフェース’プロトコール・スタックとの間との比較図である。
【図２】
スレッド・制御メッセージ・ハンドリングを示す概略図である。
【図３】
プロトコール・スタック構成及びプロトコール・スタック・クラス・ライブラリの関係図である。
【図４】
プロレイヤ・クラスの構成を示す図である。
【図５】
インターフェース・クラス階層図である。
【図６】
スレッド・クラス階層図である。
【図７】
インターフェース・プリミティブと各レイヤーとの関係を示す図である。
【図８】
ＰＳクラス関係を表す図である。
【図９】
各階層とクラス関係を示す図である。
【図１０】
アクティブ・インターフェース・オブジェクトの構成図である。
【図１１】
プロトコール・スタック内のクラス関係を示す関連図である。
【図１２】
プロレイヤとプロインターフェースのためのフレームワーク図及びスレッド・クラスの例を示す図である。
【図１３】
モデル・インプリメンテーション・プロトコール・スタックの図である。
【図１４】
図１３のモデルで用いたサーバ・アプレット図である。
【図１５】
図３のモデルで用いたクライアント・アプレット図である。
【図１６】
ＱｏＳ修正メッセージ・シーケンス図である。
Claims (34)
- スタックが、アクティブ・プログラミング・インターフェースを組み込んだアーキテクチャを有する通信システムのためのプロトコール・スタックであって、
前記アクティブ・プログラミング・インターフェースは前記スタックのリコンフィギュレーションを支援することができるプロトコール・スタック。 - 複数のプロトコール・レイヤと複数の前記アクティブ・プログラミング・インターフェースを有する請求項１記載のプロトコール・スタックであって、
前記アクティブ・プログラミング・インターフェースは前記プロトコール・レイヤとインターリーブしており、
前記プロトコール・レイヤの機能はプロトコール・レイヤ・クラスにより規定され、前記アクティブ・プログラミング・インターフェースの機能はプログラミング・インターフェース・クラスにより規定されるプロトコール・スタック。 - 前記プロトコール・レイヤ・クラスと前記プログラミング・インターフェース・クラスのそれぞれの機能の実行が、スレッド・クラスにより規定されるスレッド・オブジェクトにより制御される請求項２記載のプロトコール・スタック。
- 前記クラスは１つ又は２以上のクラス・ライブラリに格納される請求項３記載のプロトコール・スタック。
- 前記プロトコール・レイヤ・クラスが一般レイヤ・クラスから派生する機能を有し、前記プログラミング・インターフェース・クラスが一般インターフェース・クラスから派生する機能を有する請求項２記載のプロトコール・スタック。
- 前記プロトコール・レイヤ・クラス、前記プログラミング・インターフェース・クラス及び前記スレッド・クラスがプロトコール・スタック・クラスにより実装され、制御される請求項３記載のプロトコール・スタック。
- 前記プロトコール・スタック・クラスが、プロトコール・リコンフィギュレーション期間において、前記プロトコール・レイヤ、プログラミング・インターフェース及びスレッド・クラスの交換を容易化する請求項６記載のプロトコール・スタック。
- 前記プロトコール・スタック・クラスが、スタック構成を規定する請求項７記載のプロトコール・スタック。
- 前記プロトコール・レイヤが、物理レイヤ、リンク制御レイヤ、ネットワーク制御レイヤ、シグナリング・アプリケーション・レイヤ及びアプリケーション・レイヤからなる請求項１〜８のいずれか１項記載のプロトコール・スタック。
- 前記アクティブ・プログラミング・インターフェースが、前記プロトコール・レイヤの実装にアクセスせずに、種々のアクティブ・プログラミング・インターフェース間の直接シグナリング通信を可能にするように構成された請求項２〜９のいずれか１項記載のプロトコール・スタック。
- 前記一般インターフェース・クラスが複数の基本制御メッセージ（プリミティブ）を規定する請求項５記載のプロトコール・スタック。
- サービス・リクエスト・メッセージ、リクエスト応答、レイヤ状態情報及び非同期事象通知からなる４つの前記プリミティブが存在する請求項１１記載のプロトコール・スタック。
- 少なくとも１つの前記クラスが、少なくとも１つの他のクラスに依存する請求項２〜４のいずれか１項記載のプロトコール・スタック。
- 前記１又は２以上のクラス・ライブラリが安全な（ｓｅｃｕｒｅ）ライブラリである請求項４記載のプロトコール・スタック。
- 前記プロトコール・スタック・クラスが公衆利用可能である請求項６〜８のいずれか１項記載のプロトコール・スタック。
- 前記アクティブ・プログラミング・インターフェースがスタックのプロトコール・レイヤ内の属性に、連続的又は非連続的にアクセスできる請求項１記載のプロトコール・スタック。
- 複数のプロトコール・レイヤと複数のアクティブ・プログラミング・インターフェースを有する通信システムのためのリコンフィギュラブル・プロトコール・スタックであって、
前記アクティブ・プログラミング・インターフェースは前記プロトコール・レイヤとインターリーブしており、
前記プロトコール・レイヤは、複数の種々のレイヤ・クラスのそれぞれの１つから選択されるレイヤ・オブジェクトにより規定される機能を有し、
前記アクティブ・プログラミング・インターフェースは、複数の種々のインターフェース・クラスのそれぞれの１つから選択されるインターフェース・オブジェクトにより規定される機能を有し、
スレッド・オブジェクトは、プロトコール・スタック内のメッセージ列を制御するための複数のスレッド・クラスから選択されるリコンフィギュラブル・プロトコール・スタック。 - 前記各インターフェース・クラスは、前記全てのインターフェース・クラスに共通する一般インターフェース・クラスから機能を継承する請求項１７記載のプロトコール・スタック。
- 前記各インターフェース・クラスは、前記それぞれのインターフェース・クラス特有の追加的機能を規定する請求項１８記載のプロトコール・スタック。
- 前記一般インターフェース・クラスは複数の基本制御メッセージ・タイプを規定する請求項１８又は請求項１９記載のプロトコール・スタック。
- 前記基本制御メッセージ・タイプは、サービス・リクエスト・メッセージ、リクエスト応答、レイヤ状態情報及び非同期事象通知を含む請求項２０記載のプロトコール・スタック。
- 前記レイヤ・クラス、前記インターフェース・クラス及び前記スレッド・クラスを実装するためのプロトコール・スタック・クラスを含む請求項１７〜２１のいずれか１項記載のプロトコール・スタック。
- 前記プロトコール・スタック・クラスは、更に、実行時間中に、前記１つのレイヤ・オブジェクトを前記同一レイヤ・クラスの前記他のレイヤ・オブジェクトに交換し、及び／又は、前記１つのインターフェース・オブジェクトを前記同一インターフェース・クラスの前記他のインターフェース・オブジェクトに交換し、それにより、プロトコール・スタック・リコンフィギュレーション期間に、対応する前記プロトコール・レイヤ及び／又は対応する前記アクティブ・プログラミング・インターフェースの機能を変換する請求項２２記載のプロトコール・スタック。
- 前記レイヤ・クラス、前記インターフェース・クラス及び前記スレッド・クラスがクラス・ライブラリに格納され、クラス・ライブラリから選択される請求項１７〜２３のいずれか１項記載のプロトコール・スタック。
- 前記レイヤ・クラス、前記インターフェース・クラス及び前記スレッド・クラスが、クラス・ライブラリに格納され、選択され、
前記プロトコール・スタック・クラスの実装が公衆インターフェースを備える請求項２２又は請求項２３記載のプロトコール・スタック。 - 前記アクティブ・プログラミング・インターフェースは、メッセージが、介在する（ｉｎｔｅｒｖｅｎｉｎｇ）プロトコール・レイヤをバイパスする前記どの２つのアクティブ・プログラミング・インターフェース間をパスすることを許可するように構成される請求項１７〜２５のいずれか１項記載のプロトコール・スタック。
- 前記各レイヤー・クラスが、前記全レイヤ・クラスに共通する一般レイヤ・クラスから機能を継承し、前記それぞれのレイヤ・クラス特有の追加的機能を有する請求項１〜２６のいずれか１項記載のプロトコール・スタック。
- 前記レイヤ・クラスは、前記一般インターフェース・クラスから機能を継承する請求項１８〜２１のいずれか１項記載のプロトコール・スタック。
- 前記スレッド・クラスは、前記レイヤ・クラス及びインターフェース・クラスから機能を継承するプロトコール・スタック。
- ネットワークと、請求項１〜２９記載のプロトコール・スタックをそれぞれ組み込んだ少なくとも１以上の端末とを有する通信システムであって、
前記各プロトコール・スタックが独立してリコンフィギュラブルである通信システム。 - 前記少なくとも１つ以上の端末はソフトウェア・リコンフィギュラブル無線である請求項３０記載の通信システム。
- 通信システムのためのプロトコール・スタックをリコンフィギュレーションする方法であって、
前記プロトコール・スタックは、複数のプロトコール・レイヤと複数の前記アクティブ・プログラミング・インターフェースを有し、
前記アクティブ・プログラミング・インターフェースは前記プロトコール・レイヤとインターリーブしており、
前記プロトコール・レイヤは、複数の種々のレイヤ・クラスのそれぞれの１つから選択されるレイヤ・オブジェクトにより規定される機能を有し、
前記アクティブ・プログラミング・インターフェースは、複数の種々のインターフェース・クラスのそれぞれの１つから選択されるインターフェース・オブジェクトにより規定される機能を有するものであって、
前記方法は、前記１つのレイヤ・オブジェクトを前記同一レイヤ・クラスの前記他のレイヤ・オブジェクトに交換するステップと、及び／又は、
前記１つのインターフェース・オブジェクトを前記同一インターフェース・クラスの前記他のインターフェース・オブジェクトに交換するステップと、を有し、
それにより、対応する前記プロトコール・レイヤ及び／又は対応する前記アクティブ・プログラミング・インターフェースの機能を変換するものである、
通信システムのためのプロトコール・スタックをリコンフィギュレーションする方法。 - 実質的に、別添図面に関して明細書に記載されたプロトコール・スタック。
- 実質的に、別添図面に関して明細書に記載された通信システム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0011954.5 | 2000-05-17 | ||
| GBGB0011954.5A GB0011954D0 (en) | 2000-05-17 | 2000-05-17 | Protocol stacks |
| PCT/GB2001/002169 WO2001088707A2 (en) | 2000-05-17 | 2001-05-16 | Protocol stacks |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004501548A true JP2004501548A (ja) | 2004-01-15 |
| JP2004501548A5 JP2004501548A5 (ja) | 2008-06-26 |
| JP4777587B2 JP4777587B2 (ja) | 2011-09-21 |
Family
ID=9891805
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001585037A Expired - Fee Related JP4777587B2 (ja) | 2000-05-17 | 2001-05-16 | プロトコール・スタック |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20030174731A1 (ja) |
| EP (1) | EP1285338A2 (ja) |
| JP (1) | JP4777587B2 (ja) |
| AU (1) | AU2001262480A1 (ja) |
| GB (1) | GB0011954D0 (ja) |
| WO (1) | WO2001088707A2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014072647A (ja) * | 2012-09-28 | 2014-04-21 | Nec Commun Syst Ltd | 通信装置、通信制御方法およびプログラム |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100694026B1 (ko) * | 1999-11-01 | 2007-03-12 | 삼성전자주식회사 | 광대역 무선 전송방법 및 장치 |
| US7043636B2 (en) | 2000-09-26 | 2006-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Data integrity mechanisms for static and dynamic data |
| GB0028463D0 (en) | 2000-11-22 | 2001-01-10 | Univ Surrey | Reconfiguration management architectures |
| US7492737B1 (en) * | 2001-05-23 | 2009-02-17 | Nortel Networks Limited | Service-driven air interface protocol architecture for wireless systems |
| DE10143795A1 (de) * | 2001-09-06 | 2003-04-03 | Deutsch Zentr Luft & Raumfahrt | Verfahren zur Ausführung von auf dem Internet-Protokoll (IP) basierten Anwendungen mit Dienstgüte in heterogenen Zugangsfunknetzen |
| DE10153385A1 (de) * | 2001-10-30 | 2003-05-22 | Infineon Technologies Ag | Verfahren zur objektorientierten Datenkommunikation zwischen Schichten eines Datenkommunikationsprotokolls |
| US8079015B2 (en) | 2002-02-15 | 2011-12-13 | Telefonaktiebolaget L M Ericsson (Publ) | Layered architecture for mobile terminals |
| US7240830B2 (en) | 2002-02-15 | 2007-07-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Layered SIM card and security function |
| US7286823B2 (en) | 2002-02-15 | 2007-10-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile multimedia engine |
| US7363033B2 (en) | 2002-02-15 | 2008-04-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of and system for testing equipment during manufacturing |
| US7536181B2 (en) | 2002-02-15 | 2009-05-19 | Telefonaktiebolaget L M Ericsson (Publ) | Platform system for mobile terminals |
| US7415270B2 (en) | 2002-02-15 | 2008-08-19 | Telefonaktiebolaget L M Ericsson (Publ) | Middleware services layer for platform system for mobile terminals |
| US7885409B2 (en) | 2002-08-28 | 2011-02-08 | Rockwell Collins, Inc. | Software radio system and method |
| EP1530849B1 (en) * | 2002-08-29 | 2018-10-24 | Callahan Cellular L.L.C. | Reconfigurable compute engine interconnect fabric |
| US7149510B2 (en) | 2002-09-23 | 2006-12-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Security access manager in middleware |
| US7478395B2 (en) | 2002-09-23 | 2009-01-13 | Telefonaktiebolaget L M Ericsson (Publ) | Middleware application message/event model |
| US7350211B2 (en) | 2002-09-23 | 2008-03-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Middleware application environment |
| CN1275480C (zh) * | 2003-07-31 | 2006-09-13 | 上海贝尔阿尔卡特股份有限公司 | 一种多标准软件无线电(sdr)基带处理方法 |
| KR100548414B1 (ko) * | 2003-10-09 | 2006-02-02 | 엘지전자 주식회사 | 트리플 모드 기능을 구비한 이동통신단말기 |
| EP1678920B1 (en) * | 2003-10-15 | 2007-04-18 | NTT DoCoMo, Inc. | Apparatus and method for controlling an operation of a plurality of communication layers in a layered communication scenario |
| WO2005041533A1 (en) * | 2003-10-15 | 2005-05-06 | Ntt Docomo, Inc. | Apparatus and method for controlling an operation of a plurality of communication layers |
| US7489707B2 (en) * | 2003-10-16 | 2009-02-10 | National University Of Singapore | System and method for a dynamic protocol framework |
| US7756990B2 (en) * | 2003-10-29 | 2010-07-13 | Nokia Corporation | Configurable protocol engine |
| US8027280B2 (en) * | 2004-10-27 | 2011-09-27 | Honeywell International Inc. | Layered architecture for data management in a wireless sensor network |
| US7590098B2 (en) * | 2004-10-27 | 2009-09-15 | Honeywell International Inc. | Publish/subscribe model in a wireless sensor network |
| US7664080B2 (en) * | 2004-10-27 | 2010-02-16 | Honeywell International Inc. | Discreet event operators for event management in a wireless sensor network |
| US7561544B2 (en) * | 2004-10-27 | 2009-07-14 | Honeywell International Inc. | Machine architecture for event management in a wireless sensor network |
| US7630336B2 (en) * | 2004-10-27 | 2009-12-08 | Honeywell International Inc. | Event-based formalism for data management in a wireless sensor network |
| US7715308B2 (en) * | 2004-12-09 | 2010-05-11 | Honeywell International Inc. | Fault tolerance in a wireless network |
| US7539205B1 (en) * | 2005-01-07 | 2009-05-26 | Juniper Networks, Inc. | Service-specific logical interfaces for providing VPN customers access to external multicast content |
| US7535926B1 (en) * | 2005-01-07 | 2009-05-19 | Juniper Networks, Inc. | Dynamic interface configuration for supporting multiple versions of a communication protocol |
| US7921216B2 (en) * | 2005-02-01 | 2011-04-05 | Microsoft Corporation | System and method for building and using communication binding objects |
| US7471689B1 (en) * | 2005-04-22 | 2008-12-30 | Sun Microsystems, Inc. | Method and apparatus for managing and accounting for bandwidth utilization within a computing system |
| US20070030812A1 (en) * | 2005-08-03 | 2007-02-08 | Mac Donald Casey R | Protocol designer |
| US7492766B2 (en) * | 2006-02-22 | 2009-02-17 | Juniper Networks, Inc. | Dynamic building of VLAN interfaces based on subscriber information strings |
| US7808994B1 (en) | 2006-02-22 | 2010-10-05 | Juniper Networks, Inc. | Forwarding traffic to VLAN interfaces built based on subscriber information strings |
| US7720506B1 (en) | 2006-07-28 | 2010-05-18 | Rockwell Collins, Inc. | System and method of providing antenna specific front ends for aviation software defined radios |
| US7831255B1 (en) | 2006-07-31 | 2010-11-09 | Rockwell Collins, Inc. | System and method of providing automated availability and integrity verification for aviation software defined radios |
| US8311046B2 (en) | 2006-11-28 | 2012-11-13 | Core Wireless Licensing S.A.R.L. | Method for the delivery of messages in a communication system |
| US20080273520A1 (en) * | 2007-05-04 | 2008-11-06 | Samsung Electronics Co. Ltd. | NETWORK ARCHITECTURE FOR DYNAMICALLY SETTING END-TO-END QUALITY OF SERVICE (QoS) IN A BROADBAND WIRELESS COMMUNICATION SYSTEM |
| US9509549B2 (en) * | 2013-03-15 | 2016-11-29 | Cisco Technology, Inc. | Extending routing rules from external services |
| US9772828B2 (en) * | 2014-04-22 | 2017-09-26 | Oracle International Corporation | Structural identification of dynamically generated, pattern-instantiation, generated classes |
| CN105282207B (zh) * | 2014-07-25 | 2019-01-22 | 中国科学院声学研究所 | 一种基于可拼装通信协议栈的通信方法及系统 |
| CN107291750B (zh) | 2016-03-31 | 2020-11-06 | 阿里巴巴集团控股有限公司 | 一种数据迁移方法和装置 |
| US11201951B2 (en) * | 2020-04-29 | 2021-12-14 | So-ming Daniel Shia | Multi-role group inheritance for interacting computer systems |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03154960A (ja) * | 1989-11-13 | 1991-07-02 | Matsushita Electric Ind Co Ltd | 計算機システム |
| JPH0749823A (ja) * | 1993-01-29 | 1995-02-21 | Internatl Business Mach Corp <Ibm> | 通信方法及びシステム |
| JPH09506726A (ja) * | 1993-12-17 | 1997-06-30 | オブジェクト テクノロジー ライセンシング コーポレイション | オブジェクト指向ネットワーク・プロトコル構成システム |
| JPH09191332A (ja) * | 1996-01-09 | 1997-07-22 | Nec Eng Ltd | 通信装置および通信方式 |
| JPH09265409A (ja) * | 1996-03-08 | 1997-10-07 | Internatl Business Mach Corp <Ibm> | 高性能ユーザ・レベル・ネットワーク・プロトコル・サーバ・システムのための動的実行ユニット管理 |
| JP2000324174A (ja) * | 1999-03-22 | 2000-11-24 | Nokia Mobile Phones Ltd | パケット交換型セルラー無線ネットワークでマルチメディア関連情報の送信準備を行なうための方法および構成 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5515508A (en) * | 1993-12-17 | 1996-05-07 | Taligent, Inc. | Client server system and method of operation including a dynamically configurable protocol stack |
| US5499343A (en) * | 1993-12-17 | 1996-03-12 | Taligent, Inc. | Object-oriented networking system with dynamically configurable communication links |
| US5491800A (en) * | 1993-12-20 | 1996-02-13 | Taligent, Inc. | Object-oriented remote procedure call networking system |
| US5903754A (en) * | 1994-06-21 | 1999-05-11 | Microsoft Corporation | Dynamic layered protocol stack |
| US6070198A (en) * | 1995-10-19 | 2000-05-30 | Hewlett-Packard Company | Encryption with a streams-based protocol stack |
| US5938733A (en) | 1996-03-08 | 1999-08-17 | International Business Machines Corporation | Object oriented representation of network requests in a client server model |
| US5764915A (en) * | 1996-03-08 | 1998-06-09 | International Business Machines Corporation | Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack |
-
2000
- 2000-05-17 GB GBGB0011954.5A patent/GB0011954D0/en not_active Ceased
-
2001
- 2001-05-16 WO PCT/GB2001/002169 patent/WO2001088707A2/en active Application Filing
- 2001-05-16 US US10/275,776 patent/US20030174731A1/en not_active Abandoned
- 2001-05-16 AU AU2001262480A patent/AU2001262480A1/en not_active Abandoned
- 2001-05-16 JP JP2001585037A patent/JP4777587B2/ja not_active Expired - Fee Related
- 2001-05-16 EP EP01936606A patent/EP1285338A2/en not_active Withdrawn
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03154960A (ja) * | 1989-11-13 | 1991-07-02 | Matsushita Electric Ind Co Ltd | 計算機システム |
| JPH0749823A (ja) * | 1993-01-29 | 1995-02-21 | Internatl Business Mach Corp <Ibm> | 通信方法及びシステム |
| JPH09506726A (ja) * | 1993-12-17 | 1997-06-30 | オブジェクト テクノロジー ライセンシング コーポレイション | オブジェクト指向ネットワーク・プロトコル構成システム |
| JPH09191332A (ja) * | 1996-01-09 | 1997-07-22 | Nec Eng Ltd | 通信装置および通信方式 |
| JPH09265409A (ja) * | 1996-03-08 | 1997-10-07 | Internatl Business Mach Corp <Ibm> | 高性能ユーザ・レベル・ネットワーク・プロトコル・サーバ・システムのための動的実行ユニット管理 |
| JP2000324174A (ja) * | 1999-03-22 | 2000-11-24 | Nokia Mobile Phones Ltd | パケット交換型セルラー無線ネットワークでマルチメディア関連情報の送信準備を行なうための方法および構成 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014072647A (ja) * | 2012-09-28 | 2014-04-21 | Nec Commun Syst Ltd | 通信装置、通信制御方法およびプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| GB0011954D0 (en) | 2000-07-05 |
| WO2001088707A2 (en) | 2001-11-22 |
| EP1285338A2 (en) | 2003-02-26 |
| US20030174731A1 (en) | 2003-09-18 |
| JP4777587B2 (ja) | 2011-09-21 |
| WO2001088707A3 (en) | 2002-05-16 |
| AU2001262480A1 (en) | 2001-11-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4777587B2 (ja) | プロトコール・スタック | |
| EP0726003B1 (en) | Object-oriented network protocol configuration system | |
| US7739657B2 (en) | Pipeline architecture for use with net-centric application program architectures | |
| EP1463259B1 (en) | Method, system and computer program for transmitting and receiving messages through a customizable communication channel | |
| US8010967B2 (en) | Method and system for dynamic configuration of interceptors in a client-server environment | |
| de Keijzer et al. | JAIN: A new approach to services in communication networks | |
| US20020138659A1 (en) | Method and system for application development and a data processing architecture utilizing destinationless messaging | |
| WO2000045256A1 (en) | Method and system for dynamic configuration of interceptors in a client-server environment | |
| AU2002319843A1 (en) | General and reusable components for defining net-centric application program architectures | |
| EP1656800B1 (en) | System architecture method and computer program product for managing telecommunication networks | |
| US20180302496A1 (en) | Self-Driving Content Distribution | |
| EP0841618A2 (en) | Method and apparatus for defining the scope of a search oparation | |
| Law et al. | A design and implementation of active network socket programming | |
| US20020087945A1 (en) | System and method for providing flexible network service application components | |
| Coulson et al. | A Retrospective on the Design of the GOPI Middleware Platform | |
| van Gurp et al. | Service grid variability realization | |
| Adamopoulos et al. | Continuous media support in the distributed component object model | |
| Pryce et al. | Dynamic architectures and architectural styles for distributed programs | |
| CA2551059C (en) | Pipeline architecture for use with net-centric application program architectures | |
| CN111200533A (zh) | 基于OpenDDS的分布式网络配置部署方法 | |
| Blair et al. | Service Architectures | |
| Moessner et al. | OPtIMA: An open protocol programming interface model and architecture for reconfiguration in soft-radios | |
| Korba et al. | Towards policy-driven agent system development and management | |
| Kramp et al. | Descriptive-procedural configuration of communication bindings | |
| Mokdad et al. | The computational object approach for network and systems management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080509 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080509 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20101029 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101130 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110228 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110531 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110630 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140708 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |