JP4271234B2 - 修正関数を有するプロトコルスタック - Google Patents

Description

本発明は、モバイル電話、ラップトップコンピュータ及び基地局などの通信端末に限らないが、特にこれらについてのプロトコルスタックとプロトコルスタック内のプロトコルレイヤとに関する。

モバイル電話、ラップトップコンピュータ及び基地局などの通信デバイスは、異なる任意の特徴を潜在的に（潜在的に同時に）支援するする多重無線アクセスネットワーク規格の支援を可能にするために異なる構成を有する多重プロトコルスタックを支援することを益々必要としている。例えば、ラップトップコンピュータは、無線ローカルエリアネットワーク、ＧＳＭ又はＵＭＴＳ及びBluetooth（登録商標）上の安全及び安全でないインターネットアクセスの両方を支援する必要がある。リンクレイヤでの暗号化及びＩＰプロトコルスタック内のＶＰＮ特徴の一部として設けられるセキュリティはプロトコルスタック内の異なるオプションとして設けられている。しかしながら、暗号化されていないパケットが他の安全でない（又は安全性が低い）スタックに転送されないことが重要である。従って、これらの異なる通信規格をサポートするプロトコルスタックは安全なフレームワークに設ける必要がある。理想的にはこれらのプロトコルスタックは、新たなプロトコルソフトウェアモジュールをダウンロードすることによって新たな通信規格又はオプション及び既存の規格の拡張を支援できるように構成可能にする必要がある。さらに、通信デバイスはバッテリ不足及び無線周波数リソースを効率的に使用できることを益々必要としている。

従って、セキュリティ強化、性能又は電力消費最適化などの更なる機能性を含む、新たなエアインタフェース技術及び任意の特徴と、これらの技術の拡張とを許容する通信ソフトウェアをインストールすることができることが必要である。

通常、プロトコルスタックの再構成はレイヤ間のインタフェースが動的に変化せずうまく定義されるように実行されるプロトコルスタックソフトウェアのモジュールを必要とする。プロトコルスタック及びネットワークインタフェースドライバソフトウェアのフレームワークは、プロトコル（又はドライバ）モジュールがこれらのインタフェース定義の正確なバージョンに準拠し、モジュールをシステムにインストールする特定の機構に実行環境（オペレーティングシステム）を利用することをチェックするために多数のオペレーティングシステム上に存在している。ソフトウェアを認証し、プロトコルソフトウェアによって実行可能な関数上の制約を強化するための方法も用いてもよい。しかしながら、これらの制約は上述したプロトコルスタック構成の状況を通常考慮しておらず、これは、サポートされているサービスのタイプに応じてセキュリティ（実行環境）保護方法及び性能に関して異なる要件を有する可能性がある。また、これらの既存のアプローチは、プロトコルスタック構成を実行するための複数の実行環境の使用については考慮していない。

通常、モバイル通信デバイス用のプロトコルスタックは単一のベンダによって提供される。将来、端末デバイスは異なる通信技術をサポートするためのより柔軟なプロトコルスタックを必要とし、複数のベンダがプロトコルスタック解に関与することになる。このことは、多数のオプション関数を有する複数の規格をサポートする必要のある無線端末においてとりわけ重要である。従って、プロトコルスタックの付加的更新を可能にすることは非常に魅力的である。

プロトコルスタックは、各々が受信パケット又はメッセージ上の（プロトコルに対応する）一連の所定のステップを実行するソフトウェアプロセスと見なすことができ、また一定のプロトコル実現と関連付けることができるレイヤのセットにより構成される。複数の論理プロトコルスタックは、例えば複数のスレッドを使用して所定のシステムにおいてインスタンスを作成して、同一のベーシックタイプの複数のトラフィッククラスやネットワークインタフェースを同時にサポートすることができる。同一のプロトコルスタックの複数の論理インスタンスは従来、これらの論理プロトコルスタックインスタンスの全てについて単一のソフトウェア構成（プロトコルスタック構成）を使用することによって達成される。しかしながら、これは、異なるセキュリティと、異なる論理インスタンスに対する実行環境の最適化とを提供する際の柔軟性を制限する。

プロトコルスタックの想定されている挙動は、全モジュールが必要な適時性とうまく相互作用し、また使用中のプロトコル定義に従っている場合にのみ達成される。これはまた、多くのプロトコルは通信接続をセットアップして維持するために異なるデバイス上のプロトコルスタック間の相互作用に依存しているので、複数のデバイス上のプロトコルスタックの実現に依拠している。ソフトウェアレイヤの動的な挿入置換又は修正を許容する柔軟なプロトコルスタックは通常、プロトコル定義に従わない、パケットを間違った受信者に送る、パケットを破壊する、正しくない又は無効なパケットを形成する、あるいは安全な接続に意図的に侵入したりアクセスしたりするためにパケットを遮断及び転送する、又は単に引き延ばす（ハンギングする）ことのいずれかによってプロトコルスタックの全動作又はセキュリティに影響する可能性がある（悪意がある、又はひどい挙動をする）危険なソフトウェアに対して弱い。

国際公開第０２／２８０５２号は、プログラマブルプロトコルスタックの動きを定義するためのパラメータを使用する適合可能なプロトコルを有する無線ネットワークインタフェースを開示している。これによって、異なるパラメータを使用することによって限られた量の再構成が実行可能となる。しかしながら、これは新たなプロトコルソフトウェアモジュールやレイヤの動的挿入は許容しない。プログラマブルプロトコルスタックの動きを定義するためのパラメータを使用する適合性プロトコルは、行うことができる限定された量の再構成しか存在しないので、より予測可能な挙動を伴う。これらはまた、新たなプロトコルソフトウェアモジュールを動的に挿入することを可能にするプロトコルスタックほどの柔軟性を与えない。

米国特許第５７５１９７２号は、ランタイム時にネットワーク上の異なるプロトコルを使用するデータ送信経路を確立するコンピュータを動的に構成することを開示している。プロトコルスタックの構成は、オペレーティングシステム固有のリンク付け機構を使用して達成される。これは、各プロトコルスタックモジュールは特定のオペレーティングシステム依存性インタフェース定義に準拠していなければならないという点において柔軟性が制限されている。また、限られた範囲のプロトコルモジュールのみが、レイヤ間の相互作用がうまく定義されてスタックがうまく動作することを保証するために使用可能である。

国際公開第０１／８８７０７号は、上下のプロトコルレイヤ間に柔軟なリンクを提供するプロトコルスタックのレイヤの各々間のアクティブプログラミングインタフェースレイヤを用いて、ランタイム時に変更可能な柔軟性プロトコルスタックアーキテクチャを開示している。しかしながら、これらの更なる中間レイヤはスタックの複雑さに加わり、込み入った実行環境の実現が必要な場合にはこれの性能を著しく低下させる可能性がある。また、ソフトウェアモジュールのリンク付けは実行環境及びプログラミング言語固有の方法（Ｊａｖａ(登録商標)仮想マシン）で実行され、プロトコルスタックの動的再構成を可能にするＪａｖａにおける動的クラスロードコンセプトを有効に利用するために最適化される。

プロトコルスタックにおけるレイヤは一般的に、多数の所定の状態のうちの１つに存在するように設計される。特定の状態におけるレイヤは特定のメッセージ又は信号を受信し、それに応答するように動作できるようき構成される。メッセージはレイヤを別の所定の状態に変換するか、あるいはレイヤの状態をそのまま維持するかのいずれかである。

これらの所定の状態間でのレイヤの条件的遷移は、レイヤによる受信されるメッセージに依存する。レイヤが柔軟に動くことの有効性は、メッセージが使用されているコンピュータプログラミング言語に関係なく対処されるようにすること、すなわち言語独立性を促進すること、及び異なる実行環境において状態機能性の実行を可能にすることによって高められる。

レイヤの効果的かつ永続的な設計と、適切なソフトウェアの設計による実現を可能にするために、設計者は、レイヤの状態と、受信メッセージに応答してレイヤの所望の動きを記述する状態間の遷移とを最初に決定してもよい。従って、レイヤの各状態は最も適切な言語の対応する関数モジュールによって実現されて、最も適切な実行環境において実行されることが可能である。

この場合、状態モジュールは、インスタンスを作成可能なレイヤのある特定の状態の自己完結的関数を定義してそれを直接適用するメッセージを捕捉するのに対して、別の状態にある場合にはレイヤの動きに対処する別のモジュールによる処理について適用しないメッセージを無視する。

プロトコルスタックが定義されているデバイスの寿命の間に、スタックの１つ以上のレイヤにおいて１つ以上のモジュールの機能性を変更することが必要であろう。これは、例えばプロトコルスタックの機能性が新たな通信技術を収容するなどのために拡張される必要がある場合、又は少数の改善がプロトコルスタックの１つ以上のレイヤに必要とされる場合に必要であろう。レイヤのロード関数を利用してレイヤ全体を置換することは可能であろう。プロトコルスタックへの新たなレイヤのロードを可能にする一般的な関数について添付の図面を参照して次に説明する。これは、過去に提出されている英国特許出願公開第０３２２９８５．３号にすでに説明されており、このコピーは本出願に具備され、ここに参照して組み込まれている。

図１は、当業者には既知の通信プロトコルスタックを示している。プロトコルスタックは、信号やプロトコルメッセージが処理される多数のソフトウェアつまりプロトコルレイヤＬ１からＬ７を備える。例えばアプリケーション（Ｌ７）はＧＳＭボイスコール用のウェブブラウザやコントローラであってもよく、アプリケーション（Ｌ７）によって生成された信号及びメッセージは、例えば電波、銅線、又は光ケーブルなどの物理的インクにわたる別のアプリケーションと通信するために下レイヤＬ１からＬ６を介して処理される。

図２は通信スタックレイヤの１つの簡略例を示している。各レイヤの動作する様子に関する実際の詳細は使用されている特定のプロトコルに依存する。レイヤはボイスコールやウェブページの一部などのパケットを受信する。レイヤは受信パケット上で一連の所定のステップ（プロトコル）を実行するソフトウェアプロセスである。第１のステップはチェックサム計算を実行して、必要ならばパケットを拒絶してからパケットヘッダを取り除き、別のステップはこれのデータペイロードを暗号解読する。さらなるステップにおいて、次いでレイヤは、修正された大きなパケットを高次のレイヤにパスする前に多数の受信パケットのデータコンテンツを蓄積することができる。この蓄積は、不要なメモリコピーを回避する共有バッファ（つまりキュー）において実行可能である（そしてしばしば実行される）。通常通信レイヤはまたレイヤの高レベルから低レベルへと反対方向にパケットを処理する。原理上、２つの隣接するレイヤは、他のレイヤが実行していること及びその様子を「知る」必要はないが、実際レイヤ間のインタフェースはデータ（パケット）コンテンツの正確なフォーマットと、パスしたバッファ記憶構成と、これが達成される様子、例えばどのレイヤがこのデータをパスするか、及びパスされたデータを処理するこのレイヤの開始方法を知ることに関して定義する必要がある。これは、既知の構成に関して上述されたスタックの柔軟性を制限する。

モバイル電話などにおける代表的な一般の再構成不可通信プロトコルスタックは製造時に設定され、作業メモリにおける種々のソフトウェアレイヤについてインスタンスを作成するのに必要なソフトウェアコードは、できれば電話内のファームウェアとして固定及び記憶される。これは、レイヤの１つがアップグレードを必要な場合、プロトコルスタックがシャットダウンされて、コード全体又は少なくともアップグレードされたレイヤコードが通信デバイスに書き換えられて、次いで端末が再起動されてアップグレードされたプロトコルスタックが再びインスタンスを作成されることを意味している。このことは、通信デバイス上の任意のアクティブコールが終了させられてデバイスがコールをオフラインにされることを必要とする。このアプローチに関する別の問題は、異なるレイヤは通常、上記の参照の一部に記されているようにプロトコルスタックを動作させる極めて特殊な方法で相互にインタフェース接続されているという点である。このことは、新たな又はアップグレードされたソフトウェアのプロバイダが特定の実行及びプラットフォームについて上下のレイヤとの相互作用方法を事前に正確に知る必要があることを意味している。またこれはスタックの柔軟性を制限する。

ランタイム時にプロトコルスタックの再構成をサポートする他の提案されるアプローチは、一時的にスタック実行を停止して、新たなソフトウェアを、既存の実行環境及びプログラミング言語固有の機構を使用して既存のスタックにリンク付けすることによってプロトコルソフトウェアのダウンロード及び、プロトコルソフトウェアの既存のプロトコルスタックへの動的挿入を可能にする。これはまた、アクティブ通信セッションの一時的停止ならびに、いずれの他のスタックソフトウェアがインタフェース接続するかを知っている新たなソフトウェアのプロバイダと、問題になっているレイヤ専用の共有パケットバッファ構成と、言語及びオペレーティングシステム固有のコマンド及びデータフォーマットとを提供する観点においてこれを実行する方法とを必要とする。これらのアプローチはまた、ソフトウェアがうまく機能しない場合に、問題が検出されて危険なソフトウェアが取り除かれるまでアクティブ通信セッションの多くを壊してしまうという危険がある。また、新たなモジュールの挿入を許容するレイヤ間のインタフェースは容易にアップグレードすることはできず、あるいは、論理インスタンスが汎用インタフェースレイヤには見えないのでプロトコルソフトウェアの異なる論理インスタンス間の相互作用を制限するように個々に構成することはできない。

さらに、レイヤが他のレイヤと異なるソフトウェア言語で書き込まれることが将来的に必要である。例えば、物理レイヤに近いレイヤは迅速な処理を必要としているために、高速実行用にかなり最適化されているハードウェア固有のマシン言語に事前コンパイルされている可能性があるのに対して、スタックより高いレイヤはプラットフォーム独立型であり、そのために仮想マシン環境やインタプリタ上で動作し、プラットフォーム独立性を許容するために非常にゆっくりであるがより柔軟性があり、従って第三者の新たなアプリケーションの開発を促進する。しかしながら、異なる言語を使用する２つのレイヤは、言語固有データ構成、ネーミング定義（ネームハンドル定義）及び関数コール（パラメータパス）定義の観点で既知の共通言語を検索することができない。

現アプローチに関する別の問題は、レイヤの各々が、しばしば言語及びオペレーティングシステム（実行環境）固有である上下のレイヤ間の相互作用をサポートする（共有バッファ構成を含む）インタフェース定義によって厳しく制約されるために、スタックをアップグレードする性能を制限してしまう点である。この状況は、インタフェース接続を必要とするレイヤに対して同一の言語（及び環境によっては同一のコンパイラ）と、インタフェース関数及び共有バッファフォーマットとを使用するインタフェースを提供しなければならない様々なベンダによってプロトコルスタックの異なるレイヤが将来提供される可能性において深刻である。

動的柔軟性Ｊａｖａプロトコルスタックを提供する既知のアプローチが図３に示されており、各プロトコルスタックレイヤ（Ｌ１からＬ４）間のインタフェースレイヤを利用している。これは国際公開第０１／８８７０７号の開示に対応する。２つのプロトコルスタックレイヤ間に、インタフェースすなわち中間レイヤが、その上下のレイヤに「既知の」インタフェースフォーマットによってインスタンスを作成される。インタフェースレイヤはテーブルを調べていずれの高次プロトコルレイヤをインタフェース接続するかを判断し、そして既知の（Ｊａｖａ）インタフェースを使用する。従って、示されている例において、アップグレードされたプロトコルレイヤＬ２’はインスタンスを作成され、インタフェースレイヤｌ_１はルックアップテーブルより、レイヤＬ１からレイヤＬ２ではなくレイヤＬ２’に入ってくるパケットに向かうべきと判断する。そしてレイヤＬ２’はパケットを、これらをプロトコルスタックレイヤＬ３にリダイレクトするインタフェースレイヤｌ_２に向ける。従って、各プロトコルスタックレイヤ（Ｌ１からＬ４）とルックアップテーブル間のこれらのインタフェースレイヤ（ｌ_１からｌ_３）の使用によって、プロトコルスタックは動的に再構成可能である。しかしながら、インタフェースとプロトコルレイヤ間のリンクがうまく定義されるための要件があり（レイヤは全てＪＶＭにあり、またクラスロード、インヘリタンス、クラス作成及び破壊、方法識別及びコール定義などのＪａｖａ言語の使用特徴である）、変換（ラップ関数）が正しいインタフェースを提供する必要がある場合に実行される。また。インタフェースレイヤが隣接するレイヤ間の相互作用を同期的にサポートするため、パケットを記憶するための共有バッファ構成をサポートせず、これは、異なるレイヤ間のメッセージをパスするときに過度のパケットデータのコピーとメモリ要件につながる可能性がある。さらに、このアプローチが単一の言語のプロトコルスタックに適切であるのに対して、種々の関数コールとフォーマット化されたデータが言語固有のフォーマットと、プロセッサ及びメモリインテンシブなネーミング定義との間で変換されなければならないために異なる言語のレイヤが使用されている場合には面倒である。

図４は、実施形態に従ったプロトコルスタックを示している。スタックは多数のプロトコルレイヤ（Ｌ１からＬ４）を備えており、これはレイヤ間の信号パケットなどのプロトコルメッセージ（図７）をパスする。これらは低次のレイヤから高次のレイヤへと続いて示されているが、同一の原理は、スタックを介して下方に進む信号について等しく適用することが分かる。各レイヤはバインドメッセージ（図５）を受信し、バインドハンドラを備えており、これがバインドメッセージからいずれのレイヤに出力するかを判断する。

出力される次のレイヤは一意の識別子（bind ref.）によって示される。レイヤ間でメッセージをパスする好ましい方法は永続的なメッセージキューを使用するが、これが実行される方法と、１つのレイヤから別のレイヤへ実行がパスされる様子についての具体的な詳細は、以下により詳細に説明されるようにプロトコルレイヤソフトウェアから要約される。

図５を参照すると、バインドメッセージは、例えばＬ２などの一意のＬＬＩ名すなわち識別子（instance.ref）を含む。同じレイヤに対して複数の論理レイヤインスタンス（ＬＬＩ）が平行して（例えば、異なるコールを処理する別のスタックインスタンスにおいて）使用される場合、ＬＬＩ名は、例えばＬ２_１及びＬ２_２という同じレイヤの他のインスタンスと比較してそのレイヤインスタンスを一意に識別する。レイヤの複数のインスタンス作成について以下により詳細に説明する
バインドメッセージはまた言語特定関数のテーブルを備えていてもよく、これは、ＪａｖａやＣ＋＋「プロトコルスタックオペレーティングシステム」クラスに動的にカプセル化されてもよく、あるいはＣ構成及び、レイヤソフトウェア内でそれらにアクセスするのに使用される１セットのラップ関数に含有されてもよいオペレーティングシステムアプリケーションプログラマインタフェース（ＡＰＩ）を示している。関数のテーブルは、新たなＬＬＩインスタンス作成（create_new_LLI）及びＬＬＩメッセージ（send_message.receive_message）などの所定のセットの基本オペレーティングシステム関数を備える。提供されているテーブルは、レイヤ（又はレイヤの複数のＬＬＩのうちの１つ）が稼動する実行環境に依存する。すなわち、関数自体はオペレーティングシステムあるいは仮想マシン（例えばＪＶＭ）環境固有のものであるが、これらはバインド時にレイヤ（インスタンス）にパスされるので、このことは、レイヤ（インスタンス）自体がオペレーティングシステム及び実行環境独立型であり、関数テーブルを使用して、これのスタックの他のレイヤと適切に相互作用することを意味している。

代替構成において、バインドメッセージは必要なオペレーティングシステム特定関数へのポインタ（function.pointer）を含んでおり、これは例えば共有メモリのテーブルに記憶されていてもよい。

図６の図示において、レイヤに使用される所定の汎用関数（Func#1からFunc#n）はオペレーティングシステム特定関数（op.sys.func1.からop.sys.funcn）にマッピングされる。一部の一般的な例の関数、例えばオペレーティングシステムがレイヤのために実行するcreate_new_LLIが示されている。

従って、各レイヤは、他のレイヤとの相互動作を可能にする汎用関数コール（Func#1からFunc#n）を備えるが、オペレーティングシステム特定関数がバインド時にパスされるのでいずれのオペレーティングシステム環境が実行されるかは分からない。これはまた、ＬＬＩ間の相互作用をサポートするのに使用されるプロセス間通信（メッセージ）及びセキュリティ機構の特定のタイプのコードモジュールとして実現されているソフトウェアレイヤから抽出可能である。唯一の要件は、レイヤのベンダが、新たなLLI、Func#2を開始するため、別のLLI、Func#3にメッセージを送るため、別のＬＬＩなどからメッセージを受信するために、例えばFunc#1などの適切な所定の汎用関数コールを使用しなければならないことである。同様に、２つのＬＬＩが同じ特定のオペレーティングシステム関数をパスされると、同じメッセージパス関数を使用することによって相互にインタフェース接続することが可能になる。

これをさらに用いると、２つのＬＬＩには異なるオペレーティングシステム特定関数がパスされて、これによって、以下により詳細に説明される仮想オペレーティングシステム関数テーブルを使用する異なる実行環境において動作することができる。このように、レイヤはオペレーティングシステム及び言語独立型である。残りのスタックと相互動作するために必要とされる必要なオペレーティングシステム特定関数はバインド／リバインド時にパスされる。

同一レイヤの異なるインスタンスは、これのバインドメッセージにおいて異なるオペレーティングシステム特定関数を有する異なる関数テーブルをパスされることによって異なる環境で実行可能である。従って１つのコード（モジュール）は、各ＬＬＩの一般的なsend_message及びreceive_message関数にマッピングされている異なるタイプのオペレーティングシステム特定関数を有することによってのみ、他のビットのコード（モジュール）と様々に相互作用することができる（例えば、一方では関数コール、他方では非同期メッセージパス）。これは、一般的なsend_message関数を対応するオペレーティングシステム特定関数にマッピングするのに使用されるテーブルがＬＬＩ単位で実行されるからである。しかしながら、ＬＬＩが別のＬＬＩとうまく通信するためには、両方のＬＬＩが一般的なsend_message及びreceive_message関数からオペレーティングシステム関数への同じマッピングを使用する必要があり、そうでなければＬＬＩの受信は、ＬＬＩがsend_messageを実行する場合に何も受信しない。

バインドメッセージはまた、レイヤのインスタンスを、例えば異なる任意のプロトコル特徴を有効化あるいは無効化するレイヤの論理インスタンスに適切に構成するレイヤインスタンス構成情報（config_1からconfig_n）を含んでいてもよい。

この一般的かつレイヤ固有でないバインド機構を使用することによって、各論理レイヤインスタンスは、別のバインドメッセージをそのインスタンスに送ることによって新たな論理レイヤインスタンスに相互作用することを動的に（ランタイム時に）命令されることが可能である。このことは新たなレイヤの動的挿入を含んでいてもよく、さらにレイヤ間の言語独立型相互作用を見込んでいることが分かる。

図７を参照すると、プロトコルメッセージが、プロトコルスタックの上下に信号又はパケット情報を通信するためにレイヤ間でパスされる。各プロトコルメッセージは、送信元レイヤと関連したｂｉｎｄ．ｒｅｆ識別子に従って送信元レイヤ（例えばレイヤ１）から宛先レイヤ（例えばレイヤ２）に送られ、これのバインドメッセージの送信元レイヤに提供される（図５参照）。プロトコルメッセージはまた信号データ、あるいは共有メモリの信号データを示す信号ポインタを備える。また信号データ（又はポインタ）及び識別子（send.inst.ref及びdest.inst.ref）は共通の汎用共有データフォーマットである。

プロトコル及びバインドメッセージはプロトコルスタックエンティティ（種々のＬＬＩ）間でパスされる信号であり、この信号パスは、関数コールやスレッドメッセージ機構などの異なる機構を使用して実行可能である。通常スレッドメッセージは異なるオペレーティングシステムスレッド間にあり、メッセージがキュー上に置かれてから、オペレーティングシステムが、キューからメッセージを読むために受信スレッドを呼び起こす（スケジューリングする）。

（send_message及びreceive_messageなどの）汎用関数を使用して、どのような方法も特定の相互作用に対するターゲットプラットフォームに適しているメッセージパスを可能にする。コード自体はいずれの方法が使用されるかを知る必要はない。しかしながら、send_message関数を呼び出すことは、送信中のメッセージが汎用フォーマットであり、所定の方法でsend_message関数にパスされることを必要とする。メッセージは（オペレーティングシステム特定関数のテーブル内に供給されている）一般的なcreate_message関数を使用することによって動的に作成されて識別されることができ、これはsend_message関数内で使用可能なメッセージのハンドル（又はレファレンス）を生成する。メッセージをsend_message関数にパスするための好ましい方法は、それをレファレンスによってパスすることである（メッセージへのポインタは関数コールにおいてパスされる）。これは生じるはずのデータのコピー量を最小限にするが、そうでなければメッセージデータはヒープ（又は共有）メモリからスタックメモリへ、そしてヒープ（又は共有）メモリに戻ってコピーされる。好ましいアプローチは効率的であり、メッセージデータの過度なコピーを伴わない。実際、メッセージデータが常にヒープ又は共有メモリに保持されている場合、コピーはまったく必要ない。

従ってレイヤソフトウェア（モジュール）は、使用可能なsend_message及びcreate_message関数のコール定義を知るだけでよいために、メッセージを送信中のソフトウェアレイヤ（モジュール）内で使用されている言語について、又はコール定義についてさえも知識を必要としない。同様に、受信ソフトウェアレイヤ（モジュール）はreceive_message関数については知る必要がある。そして実際のメッセージコンテンツはアクセスされなければならず、共通の汎用共有データ記憶方法は、このデータにアクセスする言語固有のアクセス関数と共に使用される。同様の方法で、バインドメッセージやプロトコルメッセージ（パケット）は、プログラミング言語及び実行環境に関係なく各レイヤによって一般的な方法でアクセス可能である。

データにアクセスするのに使用される関数は、バインドメッセージ内のオペレーティングシステム特定関数の一部としてソフトウェアレイヤ（コードモジュール）にパスされることが可能である。メッセージ（又は信号）、構成及び共有データが異なるプログラミング言語によって効率的にアクセスされることを可能にし、またアップグレードを可能にするために、フォーマットは拡張可能であるべきである。例えば、拡張可能なマークアップ言語（ＸＭＬ）や（Abstract Syntax Notation ＡＳＮ．１などの）他のテンプレート定義を使用して、データフォーマットを定義し、そして、データ要素とこれの対応するデータタイプとを識別するための一意の識別子を使用することによってランタイム時に共有データ記憶構成にアクセスすることができる。そして言語固有のデータアクセス関数は必要とされる要素を効率的に検索する。これによって、異なるバージョンのプロトコルソフトウェアによる同一データの使用が可能になる。古いバージョンは新たなデータメンバにアクセスする必要はなく、またそれらにアクセスしようともしない。破棄されたデータメンバに関する知識の除去はまたより新しいソフトウェアバージョンで可能であるが、データテンプレート定義は依然として、古いソフトウェアモジュールバージョンをサポートするための破棄されたデータメンバに対するプレースホルダ（placeholder）を有している。（全ての破棄されたデータメンバを含む）データメンバを一意に識別する識別子は、これらのデータメンバにアクセスするソフトウェアモジュール内で使用される。しかしながら、言語固有のデータアクセス関数によって提供された間接参照（indirection）のために、実際のデータは全て、個々のＬＬＩによるデータへの不正アクセスを防止するために共通の共有メモリ領域及び（読書きロック機構を使用するデータタイプや要素レベル認証などの）適切なセキュリティ手段に記憶することが可能である。

これらの関数はより複雑なインタフェース定義言語（ＩＤＬ）スキーム内にカプセル化されて、既存の又は新たなコンポーネント技術の特徴の取得を可能にすることができる。言語固有のＩＤＬ定義はまた異なる言語間（例えば、Ｊａｖａレイヤ用の１セットのＪａｖａクラス及びコンポーネントインタフェースと、Ｃ＋＋レイヤ用の１セットのＣ＋＋インタフェースクラスなど）で容易にマッピングできない複雑なデータタイプの取得を可能にする。ＸＭＬ又はＡＳＮ．１テンプレートに対する特定のＩＤＬのマッピングは、この追加コンポーネントインタフェースソフトウェアによって対処することを必要とする。共通の記憶構成を使用する大量の共有データへのアクセス速度を改良するために、識別子はリンク付けされたリスト又はデータアレイ内に順次階層的に構成されて、所望の要素を検索するのに必要なルックアップタイムを最小にすることができる。

プログラミング言語独立型データテンプレート定義の一例はそれぞれ、拡張可能なマークアップ言語（ＸＭＬ）スキームや、Abstract Syntax Notation（ＡＳＮ）タグや、データシーケンス定義である。データ要素（又は属性）アクセス関数は、下記の表に示されているようなアクセス性能を改良するためのデータ要素シーケンス内の実際の項目にアクセスする間接参照（メモリポインタ）を利用することができる。このように、データ要素の解決はルックアップ動作及び、テンプレートに定義されているような必要なデータフォーマットへの結果のキャスティング又は変換になる。

但し、例ＡＳＮ−１定義は
Message::=SEQUENCE(
Message_Number INTEGER OPTIONAL,
Message_Name STRING
｝である。

メッセージデータにアクセスするのに使用される汎用関数はまた、データアクセス関数の実際の実現をプラットフォームに対して最適化するバインドメッセージによってパスされた関数の汎用オペレーティングシステムテーブル内に含まれていてもよい。例えば一意の識別子「１２４３」を有するデータ要素について、ソフトウェアレイヤは汎用レイヤ関数get_attribute（「１２４３」）を呼び出す。レイヤソフトウェアはＸＭＬ又はＡＳＮ．１テンプレートフォーマットで定義されている要素のデータタイプを知る必要がある。レイヤソフトウェアによって使用されている構成データ及びメッセージに対応するテンプレートは、必要に応じてタイプ変換を可能にするために、一般的なget_attribute及びset_attribute関数によって知られる必要がある。従って、get_attribute及びset_attribute関数はテンプレート定義に対するハンドル（レファレンス）をパラメータとする。ハンドル（又はレファレンス）は一般的なload_template関数によって生成される。汎用関数get_attribute及びset_attributeはまた構成データかメッセージハンドル（又はレファレンス）を用い、特定のデータ要素に対するメモリポインタレファレンスを記憶し、これの一意の識別子のレファレンスを記録することができるようにルックアップテーブルを保持する。

別のオプションは、同一の実際のデータ要素を示す２つの属性識別子を有することである。これは、異なる識別子が実際に同一のデータ要素に対応しているが異なる変換タイプを有する場合にデータの重複を回避するのに魅力的である。例えば、データ要素識別子「１２４３」がデータ要素に対応する場合、それはテンプレート内で「メッセージ名」として特定されて、ヌルで終わるＵｎｉｃｏｄｅストリングである。属性識別子「１２４４」はまた同一の「メッセージ名」に対応するが、例えば２５５バイトのＡＳＣＩＩ文字列などの異なるフォーマットである。タイプの変換は、get_attribute関数によってソフトウェアレイヤから隠される。従って、Ｊａｖａソフトウェアモジュールがget_attributeを呼び出す場合、それは識別子「１２４３」を使用中であり、Ｕｎｉｃｏｄｅストリングを取得し、またＣ＋＋モジュールがデータ要素へのアクセスを望む場合には、「１２４４」要素上のget_attributeを呼び出して、２５５バイトのＡＳＣＩＩストリングを取得する。

好ましい実施形態において、同一のテンプレートが、メッセージ送信及び受信するＬＬＩに関係なく全メッセージデータについて使用される。これは、ＬＬＩ内のプロトコル関数から独立したＬＬＩにいわゆる汎用サービスアクセスポイント（ＧＳＡＰ）を提供する。ＧＳＡＰに対する考えられる例示的な汎用テンプレート定義を以下に示す。

・列挙及びタイプ定義
GPI_PRIMITIVETYPE::=ENUMERATED{GPI_BIND(1),GPI_REBIND（２），GPI_SUSPEND（３），GPI_RESUME（４），GPI_UNBIND（５），GPI_TERMINATE（６），GPI_UPGRADE（７），GPI_OPTIMISE（８），GPI_OK（９），GPI_ERR（１０）｝；
・汎用ＭＡＣレイヤについて
GPI_MACTYPE::=ENUMERATED{GPI_CSMACA(0),GPI_CSMACD（１），GPI_TPB（２），GPI_TPR（３），GPI_TDMA（４）｝；
GPI_CRCTYPE::=ENUMERATED{GPI_CRC32（０），GPI_CRC16（１），GPI_CRC24（２）｝；
GPI_ARQTYPE::=ENUMERATED{GPI_SAW（０），GPI_GBN（１），GPI_SEL（２），GPI_NONE（３）｝；
GPI_HARQTYPE::=ENUMERATED{GPI_TYPE1（０），GPI_TYPE2（１），GPI_NONE（２）｝；
GPI_HARQCODETYPE::=ENUMERATED{GPI_GOLAY（０），GPI_RS（１），GPI_NONE（２）｝；
GPI_CRYPTOTYPE::=ENUMERATED
{GPI_RSA（０），GPI_DES（１），GPI_3DES（２），GPI_GEA3（３），GPI_NONE（４）｝；
・バインドプリミティブについて
GPI_QOSTYPE::=ENUMERATED{GPI_CO（０），GPI_CL（１）｝；
・接続指向及び接続なし
GPI_SECURITYLEVEL::=ENUMERATED{GPI_HIGH（０），GPI_MEDIUM（１），GPI_LOW（２）｝；
・汎用データパケットプリミティブについて
GPI_PACKETTYPE::=ENUMERATED{GPI_IP（０），GPI_ETHER（１），GPI_PPP（２）｝；
GPI_DIRECTION::=ENUMERATED{GPI_UP（０），GPI_DOWN（１）｝；
GPI_TFTYPE::=SEQUENCE{
・汎用トランスポートフォーマットタイプ定義
GPI_MOD GPI_MODTYPE［変調タイプ］，
GPI_CODING GPI_CODINGTYPE［チャネル符号化タイプ］
GPI_BLOCKSIZE INTEGER［バイト単位のトランスポートブロックサイズ］，
GPI_ANTENNA INTEGER OPTIONAL［どのアンテナを利用するかを指示］
｝
・プリミティブ定義
GPI_MANPRIMITIVE::=SEQUENCE{
・汎用ＧＰＩ管理プリミティブ
GPI_PRIMITIVE GPI_PRIMITIVETYPE［これは特定のプロトコルメッセージプリミティブタイプである］，
・プロトコルモジュール独立型パート
GPI_REQUESTOR GPI_LL_IDENT［これはリクエストＬＬＩである］，
・プリミティブ−バインドのタイプに応じた任意のパートは追加情報を含む
GPI_BIND GPI_BINDPRIMITIVE OPTIONAL［バインド、リバインド、最適化について］
｝
GPI_BINDPRIMITIVE::=SEQUENCE{
GPI_UPPER_SAP STRING［これはＬＬＩ上のサービスアクセスポイント名である］，
GPI_UPPER_USER GPI_LL_IDENT［これは、ＳＡＰを使用し、かつパケットが受信及び送信されるＬＬＩの（複数の）一意の識別子である］，
GPI_LOWER_SAP STRING［これはＬＬＩの下のサービスアクセスポイント名である］，
GPI_LOWER_USER GPI_LL_IDENT［これは、ＳＡＰを使用し、かつパケットが受信及び送信されるＬＬＩの（複数の）一意の識別子である］，
GPI_GSAP GPI_GSAP_TABLE［これは、言語独立性、性能の最適化、及びＧＳＡＰ境界にわたる相互作用を安全に許容するためにＬＬＩの環境を設定する（仮想）オペレーティングシステムテーブルである］，
・一般的な方法でＬＬＩを構成するＱｏＳ属性
GPI_QOS GPI_QOSTYPE［ＬＬＩと関連するＱｏＳ］，
GPI_RCV_THROUGH_TARGET INTEGER［ｋビット／秒のターゲット受信スループット］，
GPI_RCV_THROUGH_ACCEPT INTEGER［ｋビット／秒の受容可能な受信スループット］，
GPI_RCV_TRANSDELAY_TARGET INTEGER［ミリ秒単位のターゲット受信待ち時間］，
GPI_RCV_TRANSDELAY_ACCEPT INTEGER［ミリ秒単位の受容可能な受信待ち時間］，
GPI_XMT_THROUGH_TARGET INTEGER［ｋビット／秒のターゲット送信スループット］，
GPI_XMT_THROUGH_ACCEPT INTEGER［ｋビット／秒の受容可能な送信スループット］，
GPI_XMT_TRANSDELAY_TARGET INTEGER［ミリ秒単位のターゲット送信待ち時間］，
GPI_XMT_TRANSDELAY_ACCEPT INTEGER［ミリ秒単位の受容可能な送信待ち時間］，
GPI_PRIORITY_MIN INTEGER(0..100)［トラフィッククラス／接続の最低優先順位］，
GPI_PROTECTION_MIN INTEGER[GPI_NONE,GPI_MONITOR,GPI_MAXIMUM],
GPI_PRIORITY_MAX INTEGER(0..100)［トラフィッククラス／接続の最高優先順位］，
GPI_PROTECTION_MAX INTEGER[GPI_NONE,GPI_MONITOR,GPI_MAXIMUM],
GPI_RESILIENCE_DISC_PROB INTEGER(0..10000)［切断に対する復元力］，
GPI_RESILIENCE_RESET_PROB INTEGER(0..10000)［接続リセットに対する復元力］，
GPI_RESIDUAL_SUCCESS INTEGER(0.10000000)［エラーレートの余剰サクセスレートの逆数］，
・任意のコスト及び電力消費、リソース利用及びセキュリティ要件
GPI_RCV_COST_TARGET INTEGER OPTIONAL［電流単位のターゲットスループットにおけるターゲット受信コスト／分］，
GPI_RCV_COST_ACCEPT INTEGER OPTIONAL［受容可能な受信コスト／分］，
GPI_XMT_COST_TARGET INTEGER OPTIONAL［電流単位のターゲットスループットにおけるターゲット送信コスト／分］，
GPI_XMT_COST_ACCEPT INTEGER OPTIONAL［受容可能な送信コスト／分］，
GPI_POWER_CONSUMPTION_TARGET INTEGER OPTIONAL(0..100)［受容可能なバッテリ寿命を達成するために許容可能な最大電力消費量の％としてのターゲット最大電力消費量］，
GPI_SECURITY GPI_SECURITYLEVEL OPTIONAL［必要なセキュリティレベル］，
GPI_MEMORY_TARGET INTEGER(0..100)OPTIONAL［全体のうちのターゲット最大メモリ使用％］，
GPI_PROCESSOR_TARGET INTEGER(0..100)OPTIONAL［全体のうちのターゲット最大プロセッサ使用％］，
・ＬＬＩ固有のパート−ここで使用されている属性はＬＬＩのタイプに大きく依拠している
GPI_MAC GPI_MACTYPE OPTIONAL［これはＭＡＣのタイプを示している］，
GPI_MAC_AIFS INTEGER OPTIONAL［タイムスロットのアービトレーションフレーム間分離］，
GPI_MAC_SLOTTIME INTEGER OPTIONAL［マイクロ秒単位のＣＳＭＡ及びＴＤＭＡ系ＭＡＣのスロットタイム］，
GPI_MAC_FRAMESIZE INTEGER OPTIONAL［タイムスロットのフレームサイズ］，
GPI_MAC_BACKOFFWINDOW INTEGER OPTIONAL［タイムスロットの開始バックオフウィンドウサイズ］，
GPI_HEADER_CRC GPI_CRCTYPE OPTIONAL［汎用ヘッダＣＲＣの設定］，
GPI_PAYLOAD_CRC GPI_CRCTYPE OPTIONAL［汎用ペイロードＣＲＣの設定］，
GPI_HEADER_CRC_GEN INTEGER OPTIONAL［ヘッダＣＲＣの生成器多項式］，
GPI_PAYLOAD_CRC_GEN INTEGER OPTIONAL［ペイロードＣＲＣの生成器多項式］，
GPI_ARQ GPI_ARQ_TYPE OPTIONAL［ＡＲＱの設定］，
GPI_ARQ_BLOCKSIZE INTEGER OPTIONAL［バイト単位の再送信ブロックサイズ］，
GPI_ARQ_WINDOWSIZE INTEGER OPTIONAL［ＧＢＮ及びSelectiveの再送信ウィンドウサイズ］
GPI_HARQ GPI_HARQTYPE OPTIONAL［ハイブリッドＡＲＱの設定］，
GPI_HARQ_CODE GPI_HARQCODETYPE OPTIONAL［ハイブリッドＡＲＱ符号化の設定］，
・暗号化／解読設定−汎用暗号化ＬＬＩに使用される
GPI_CRYPTO GPI_CRYPTOTYPE OPTIONAL［暗号化／解読の設定］，
GPI_CRYPTO_IV GPI_IV OPTIONAL［暗号の初期化ベクトル］，
GPI_CRYPTO_KEY GPI_KEY OPTIONAL［暗号化／解読のセッションキー］
｝
GPI_PACKET::=SEQUENCE{
・汎用データパケット（又はフレーム）定義
・必須パケット情報
GPI_PACKET GPI_PACKETTYPE［これはパケットタイプである］，
GPI_PACKET_HEADER_PTR GPI_PACKET_HEADER［プロトコル固有のフォーマットの実際のパケットヘッダ］，
GPI_PACKET_PAYLOAD_PTR GPI_PACKET_PAYLOAD［プロトコル固有のフォーマットの実際のパケットペイロード］，
GPI_PACKET_HEADER_LEN INTEGER［バイト単位のヘッダ長］，
GPI_PACKET_PAYLOAD_LEN INTEGER［バイト単位のペイロード長］，
・任意のパケット情報
GPI_TRCH GPI_TRCH_IDENT OPTIONAL［トランスポートチャネル識別子］，
GPI_TF GPI_TFTYPE OPTIONAL［トランスポートフォーマット］，
GPI_DEST_MAC GPI_MAC_ADDRESS OPTIONAL［宛先ＭＡＣアドレス］，
GPI_SRC_MAC GPI_MAC_ADDRESS OPTIONAL［送信元ＭＡＣアドレス］，
GPI_DEST_IP GPI_IP_ADDRESS OPTIONAL［宛先ＩＰアドレス］，
GPI_SRC_IP GPI_IP_ADDRESS OPTIONAL［送信元ＩＰアドレス］，
GPI_DEST_PORT INTEGER OPTIONAL［宛先ポート番号］，
GPI_SRC_PORT INTEGER OPTIONAL［送信元ポート番号］，
GPI_SN INTEGER OPTIONAL［シーケンス番号］，
GPI_IP_HEADER_CHKSUM GPI_IP_HEADER_CHECK_SUM OPTIONAL［ＩＰチェックサム］，
GPI_TRAFFICCLASS INTEGER OPTIONAL［トラフィックタイプの識別子］，
GPI_PACKETDIRECTION GPI_DIRECTION OPTIONAL［プロトコルスタックにおけるパケットの方向］
｝
レイヤにおける汎用関数と、これの実行環境においてＬＬＩによって呼び出されたオペレーティングシステム特定関数との間のマッピングは多数の方法で実行可能である。図８を参照すると、各ソフトウェアレイヤ（例えばＬ２）は多数の所定の汎用関数を備える。Ｌ２レイヤのベンダが所定の汎用関数を使用すると仮定すると、このレイヤはプロトコルスタック内の他のレイヤと相互動作する。プロトコルスタックのレイヤをサポートする実行環境はオペレーティングシステムテーブル（ＯＳ１）や他のオブジェクトと関連付けられており、これはレイヤと関連付けられている汎用関数を、その特定の実行環境において汎用関数を実行するオペレーティングシステム特定関数に効率的にマッピングする。示されている例において、Ｌ２の汎用関数１、例えばreceive_messageはＵＮＩＸ（登録商標） ＰＯＳＩＸ系実行環境ついての等価関数に変換される。オペレーティングシステムテーブル（ＯＳ）やマッピングオブジェクトは、例えばプロトコルスタックのオペレータによって、あるいは実行環境プロバイダなどの他のエンティティによって供給されてもよい。

図９は代替構成を示しており、ソフトウェアレイヤＬ２は、オペレーティングシステムテーブル（ＯＳ２）や他のマッピングオブジェクトによってこれのＬ２フォーマットから直接ローカルオペレーティングシステムフォーマットにマッピングされることが可能なレイヤに特定関数を備える。従って、例えば（これもまたsend_messageに対応する）Ｌ２の関数１はオペレーティングシステムテーブルＯＳ２によって、ローカルＵＮＩＸ ＰＯＳＩＸ系実行環境関数又はｒeceive_message関数に対する関数にマッピングされる。この具体的な構成において、Ｌ２ソフトウェアレイヤのベンダはまた対応するオペレーティングシステムテーブルＯＳ２やマッピングオブジェクトをＵＮＩＸオペレーティングシステム環境に供給してもよい。Ｌ２のベンダは、ベンダが供給したＬ２ソフトウェアレイヤを解釈するために、異なるタイプのオペレーティングシステムについての多数のオペレーティングシステムテーブルを供給することができる。

図１０は、示されている例において汎用関数コールを適切なオペレーティングシステム−ＵＮＩＸ（ＯＳ１）やMICROSOFT WINDOWS（登録商標）（ＲＴＭ）（ＯＳ２）にポインティングするために使用可能な仮想オペレーティングシステム（ＶＯＳ）の使用を概略的に示している。従って、例えば１つ以上のオペレーティングシステムや実行環境オプションが、例えば基地局や端末などのデバイスや装置上で通常のプロトコルレイヤを駆動するために使用される場合、ＶＯＳは汎用関数コールを、ソフトウェアレイヤＬ２から、例えばＵＮＩＸやMicrosoft Windows（ＲＴＭ）のオペレーティングシステムテーブル(それぞれOS1又はＯＳ２）、あるいはマッピングオブジェクトのいずれかに向けることができる。同一ソフトウェアレイヤの２つのインスタンスが異なる動作環境で実行される場合、ＶＯＳは同一の汎用関数（例えば汎用関数１）を、第１のＬＬＩのＵＮＩＸオペレーティングシステムテーブル（ＯＳ１）と、第２のＬＬＩのMicrosoft Windows（ＲＴＭ）オペレーティングシステムテーブル（ＯＳ３）とにマッピングすることができ、ここでは同一の汎用関数はそれぞれop.sys function xとop.sys function.aとに対応している。ソフトウェアレイヤＬ２は汎用関数を使用しているために、Ｌ２のベンダは実際のレイヤソフトウェア（モジュール）を供給することのみを必要としており、ＶＯＳやオペレーティングシステムテーブルソフトウェアを伴う必要はない。ＶＯＳの動作を以下により詳細に説明する。

次に図１１を参照すると、ベンダが供給したＬ２ソフトウェアレイヤは、異なるオペレーティングシステム間のＬ２特定関数をマッピング可能なＬ２のベンダによって供給されてもよい仮想オペレーティングシステム（ＶＯＳ）によってマッピングされるレイヤ特定関数を備えており、これはまたＬ２特定関数をそれぞれのオペレーティングシステム関数、例えばそれぞれＵＮＩＸ及びMicrosoft Windows（ＲＴＭ）にマッピングするために、Ｌ２のベンダによって供給されてもよいオペレーティングシステム固有のテーブル（ＯＳ２、ＯＳ４、ＯＳ５）やマッピングオブジェクトを使用している。従って、種々の実施形態が実現されて、プロトコルレイヤソフトウェアとは無関係の言語及び／又はオペレーティングシステムを達成することができる。

図１１はまた、例えば各々が異なるＬＬＩに対応している２つのスレッドは異なる実行環境の実行に関する異なるオペレーティングシステムテーブルにマッピング可能である様子を示している。スレッド１はＶＯＳテーブルにおける固有のエントリにポインティングされ、Ｌ２特定関数（Ｌ２の関数１）によってマッピングし、一方でＵＮＩＸ環境において実行可能な関数（op.sys.function.x）に対応するＵＮＩＸオペレーティングシステムテーブルＯＳ２における特定のエントリにポインティングされる。そしてスレッド１はレイヤＬ２モジュールの次の関数ポインタ（Ｌ２の関数２）に戻る。異なる実施形態において、スレッド１は、Windowsの環境において、レイヤＬ２モジュールにおけるＬ２特定関数ポインタ（Ｌ２の関数１）に対応するWindows特定関数（op.sys.function.a）の実行について、ＶＯＳによってWindowsのオペレーティングシステムテーブルＯＳ４にポインティングされてもよい。

スレッド２は異なるＬｉｎｕｘ（登録商標）実行環境において実行された同一のレイヤＬ２の異なるＬＬＩに対応していてもよい。このシナリオにおいて、Ｌ２特定関数ポインタ（例えばＬ２の関数３）はＬｉｎｕｘ特定関数（op.sys.function.m）にマッピングされ、これが実行されるとスレッド２はレイヤＬ２モジュールにおけるこれの次の関数ポインタ（Ｌ２の関数４）に戻る。

図１２は、複数のプロトコルスタックにおけるレイヤの複数のインスタンス作成を示している。ＵＭＴＳビデオコールと２つのＷＬＡＮインターネット閲覧プロトコルスタックが同時にアクティブに示されている。インターネットスタックのうちの１つが無制限なインターネット閲覧をサポートしているのに対して、他方はイントラネットの閲覧をサポートしており、このこと自体が（例えば仮想プライベートネットワーキングＶＰＮプロトコルに基づいて）暗号化をサポートしているにちがいない。２つのブラウザスタックは各々ＷＬＡＮに結合されている４つのプロトコルレイヤインスタンス（それぞれＬ４_１からＬ１_１とＬ４_２からＬ１_２）を有しているが、レイヤ２のインスタンス（Ｌ２_１とＬ２_２）はそれぞれ別々に構成されている。これは、暗号化をサポートするレイヤ２の第２のインスタンスを示すインターネットスタックにおけるＬ２_２（sec）と、暗号化をサポートしないレイヤ２の第１のインスタンスを示すインターネットスタックにおけるＬ２_１（non-sec）とによって図示されている。これらの構成はこのレイヤ（Ｌ２_１とＬ２_２）の各インスタンスに送られたオリジナルのバインドメッセージによって判断される。レイヤ１、３及び４は２つのブラウザスタックについて同一であり、それぞれのレイヤの別個である（それぞれＬ１_１、Ｌ３_１、Ｌ４_１とＬ１_２、Ｌ３_２、Ｌ４_２）が等しく構成されているインスタンスを含む。

安全なスタックレイヤインスタンスを実行するのに使用されている実行環境は安全でないインスタンスからのメッセージや構成データへのアクセスの可能性をなくすように構成できる。例えば、これは、全メモリアクセスの認証と、安全なスタックインスタンスから分離するためのメッセージ動作とを実行するオペレーティングシステム関数テーブルを使用して遂行される。例えばsend_message関数の根本的な実現は、ＶＯＳ及び／又はオペレーティングシステムマッピングオブジェクトの供給者が何を行うかを関数に求めることによって決定される。従って、例えばソフトウェアレイヤが信頼できない場合、send_message及びreceive_message関数によって実行され関数はなおさらセキュリティに関して敏感である。このことは、例えば基本的な検索データ関数に結合された認証関数を含んでいてもよい。さらなる例において、create_LLI関数は自身のメモリ領域を有する別個のプロセスを作成し、レイヤが信用できるソフトウェアモジュールによって使用されているメモリにアクセスできる可能性がないことを保証する。オペレーティングシステム自体が十分に信頼されていないと思われる場合は、別個のオペレーティングシステム環境においても実行可能である。

各レイヤはまた異なる性能最適化、例えば処理集中的な暗号化動作を実行するスタックインスタンスに与えられた優先順位によって実現されてもよい。

レイヤ２の（Ｌ２_２の）第２のＬＬＩは第１のＬＬＩ（Ｌ２_１）と同じコードモジュール（レイヤ２）を使用しているが、それは作業メモリにロードされているコードモジュールの更なるコピーではなく新たな論理エンティティ（この場合は実行又はプロセスのオペレーティングシステムスレッド）である。例えば、第２のＬＬＩ（Ｌ２_２）はこのコードモジュール内の第２の実行スレッドであってもよく、これはオペレーティングシステムによってコントロールされており、また自身の一意の識別子とそれに関連した構成を有している。この構成情報は論理レイヤのＬＬＩ（例えばスレッド）と、インスタンスごとに構成をセットアップするコントロールエンティティ（以下により詳細に説明するＣＭ）にのみアクセス可能である。ＬＬＩ間の相互作用はまたＣＭによって構成されており、必要ではないＬＬＩが（実行環境構成手段を介して）相互作用することを防ぐことができる。

さらに、レイヤ２の２つのＬＬＩ（Ｌ２_１とＬ２_２）は共通の機能性をサポートしているが、これらは別々に構成されてもよい。この例において、Ｌ２_２は暗号化／解読をサポートするが、Ｌ２_１はサポートしない。これらの構成設定はバインドメッセージによって設定され、スタックにおける適切な位置や各インスタンス（ＬＬＩ）と関連付けられた作業メモリにおけるテーブルに記憶されてもよい。

レイヤ２のソフトウェアの第２のＬＬＩは異なるＬＬＩ識別子［instance.ref］ならびに、異なる出力レイヤにリンクしている異なるバインドレファレンス［bind.ref］を有する。汎用関数を、これのそれぞれの実行環境内でこれらの関数を実行するために必要なオペレーティングシステム特定関数にマッピングするための異なるオペレーティングシステム関数テーブルを必要とする異なる実行環境において動作していなければ、［function.ref］によって同定されるオペレーティングシステム関数テーブル（又はオペレーティングシステムクラス）はレイヤ２の第１のＬＬＩによって使用されているのと同じオペレーティングシステムテーブルであってもよい。第２のＬＬＩはまたこれ自体の実行スタック（Ｌ２_２スタック）とヒープメモリとを有していてもよい。各ＬＬＩは使用可能な同一の構成オプションを有するが、これらを別々に有効化／無効化することができる。これらはパラメータとしてこれのそれぞれのＬＬＩ構成に記憶されてもよい。

各レイヤは所定の汎用関数コールを利用し、これはスレッド管理ならびにメモリ管理関数を含む。そしてこれらはランタイム時に、ターゲットデバイス上でオペレーティングシステム特定関数のセットにマッピングされる。（オペレーティングシステム関数テーブル及び信号パケットなどの）１つ以上のＬＬＩにアクセスされたデータは所定のフォーマットで提供され、これによって各ＬＬＩは所定の関数コールのセットを使用してこの情報にアクセスすることができる。

バインド信号［bind.para］はオリジナルなバインド信号の後も含めて常にＬＬＩによって受信可能であり、従ってＬＬＩの構成オプションを変更可能にし、さらにはbind.refパラメータを変更することによってＬＬＩを別のＬＬＩに結びつけることができ、それによってプロトコルスタックの動的リバインドを可能にしている。

プロトコルレイヤのＬＬＩは、（例えば、異なるスレッド間の優先順位ベースのマルチタスクを終了及び提供できる）他の実行スレッドからの一定の制御及び分離を行う自己実行スタックを有するオペレーティングシステムのスレッドにインスタンスを作成することによって生成可能である。あるいはまた、異なるＬＬＩは異なるオペレーティングシステムプロセスとしてインスタンスを作成されて、各プロセスにこれ自身のメモリヒープを提供して、他のＬＬＩからのアクセスを防止することによって更なる分離及び制御を行うことができる。しかしながら、このことは、優先順位ベースのマルチタスク（つまり、スレッドに並列するプロセス間のコンテクスト切り替え）を実行する際のオーバーヘッド増大のペナルティを招く。最終的に、ＬＬＩは同一のオペレーティングシステムスレッド内でインスタンスを作成できる。このことは、ＬＬＩをセットアップして制御する際にはオーバーヘッドは最小であるという利点を有するが、別個のスタックやヒープはなく、それゆえに（ＬＬＩ構成などの）データへのアクセス及びこれの実行に関する制御（つまり優先順位付け）は、オペレーティングシステムのセキュリティ手段に依存している場合には親スレッドに大きく依存できる。この後者の場合、ＬＬＩに使用されるプログラミング言語及び実行環境はこれの親スレッドと同じであるが、これは必須ではないという点が好ましい。

上記のオペレーティングシステムの実行環境に加えて、ＦＰＧＡやＤＳＰなどの外部プログラマブルデバイスにおいてＬＬＩにインスタンスを作成することもできる。これらの実行環境は、同一のオペレーティングシステムのコントロール下の単一の（又は複数の）プロセッサ構成内の環境とかなり異なる。しかしながら、仮想オペレーティングシステム関数テーブル（ＶＯＳ）によってデバイス間通信の複雑さは、ＬＬＩを異なるデバイス上に実現するソフトウェアモジュールから取り除かれる。

上記の方法で、複数の論理レイヤインスタンスは、異なる実行又はプロセススレッドを使用する異なる実行環境において作成できる。これに加えて、各ＬＬＩは異なるプロトコル特徴（構成オプション）で構成できるが、共通のデータアクセス機構を使用して信号メッセージデータ及び他の共有データにアクセスすることができる。上記の通り１つ以上のＬＬＩが同一のスレッド内で作成される場合に特殊な場合が生じる。

既に述べたとおり、異なる実行環境において（同一又は異なる）プロトコルスタックレイヤの異なるＬＬＩを実行し、様々なレベルのセキュリティ及び性能を提供することが可能である。例えば、Bluetoothスタックは、安全な高速接続と、安全でない低速接続との両方をサポートしていてもよい。安全な高速接続に対処するＬＬＩの実行環境はセキュリティ及び性能について最適化可能であり、低速接続をサポートするＬＬＩは、安全が低くかつそれほど最適化されていない実行環境においてサポートできる。

このアプローチはＬＬＩ間の相互作用を制限し、必要ならばＬＬＩごとに（適切なセキュリティ手段によって）異なる実行環境を使用して適切にこれらを分離する。このように、かなり信頼できるソフトウェアにはさらなる自由が認められ、実行中の危険なランタイムセキュリティチェックや機能性への制限なしに、より最適化された実行環境において実行できるのに対して、信頼性の低いソフトウェアを使用するＬＬＩは、他のＬＬＩとの可能な相互作用についてより多くの制限を有するより安全な環境で実行される。これらの手段はまたソフトウェア内の信頼レベルだけではなく、ＬＬＩにサポートされているサービスタイプと関連した完全性及び（プライバシー及び機密性などの）他のセキュリティ要件にも依存している。

図１３は、例えば携帯電話においてレイヤにインスタンスを作成し、一方のソフトウェアレイヤから別のソフトウェアレイヤにバインドするためのセットアップ及びアップグレードシナリオを示している。電話は、作業メモリに直接（すなわちネイティブに）ロードされている多数のソフトウェアコードモジュールを記憶又はダウンロードをし、又は（Ｊａｖａクラスのロード原理などの）仮想マシン環境機構を使用するとエントリポイントが識別される。示されている例において、これはレイヤ１から３と、ソフトウェアレイヤに対応するコードモジュールを作業メモリにロードし、エントリポイントを呼び出し、レイヤを構成又は再構成するための適切なバインドメッセージを送信することによってプロトコルスタックの構成をコントロールする構成マネージャ（ＣＭ）とを含む。例えば、レイヤ１に送られたバインドメッセージはそれにレイヤ２を「バインド」することを命令する。

レイヤ２がレイヤ２’と置換されるアップグレードシナリオにおいて、レイヤ２’のソフトウェアレイヤファイル又はコードモジュールは作業メモリ（Ｌ２’）にロードされて、構成マネージャ（ＣＭ）はレイヤエントリポイントを新たなレイヤに呼び出す。そしてバインドメッセージをレイヤＬ２’に発行し、これの出力をレイヤ３に向け、適切なプロトコルオプションをセットアップする。構成マネージャはまたバインドメッセージをレイヤ１に向け、レイヤ２からレイヤ２’に変更する。このアップグレード再構成はランタイム時に生じ、また比較的簡単なバインドメッセージの実現を必要としているにすぎない。またこれによって（古い）レイヤ２（Ｌ２）を通過するパケットはいずれも処理を継続されてレイヤ３（Ｌ３）にパスすることができ、これによって関連セッションは動的再構成によって終了されない。従って、スタックの再構成時のセッションの終了の必要はなく、新たなインスタンスが古いインスタンスの（状態を含む）構成データにアクセスすることになる。

図１４を参照すると、例えばレイヤ２の第１のインスタンス（Ｌ２_１）にインスタンスを作成するために、構成マネージャ（ＣＭ）はレイヤ２のコードモジュールを作業メモリのプログラムコードエリア（又は仮想マシン環境）にロードする。そして構成マネージャは、ネイティブソフトウェアモジュールの場合には直接作業メモリにおけるコードのエントリポイント（レイヤエントリポイント）を呼び出し、又は仮想マシン環境におけるレイヤエントリポイントメンバ関数（稼動方法）を呼び出すことによってＬＬＩを開始する。

ＣＭは、クラスファイルをロードすることを意味するＪａｖａと、実行環境に適切な方法で１セクションのコードをメモリにロードしているネイティブレイヤとについてロード手順を実行する。ＣＭは実行環境を知っているので、モジュールのロード方法を知っており、デフォルトの適切なＶＯＳ及び／又はオペレーティングシステムテーブル（ＯＳ）をパスする。これらの例を以下により詳細に説明する。ネイティブコードレイヤにおいて、これはエントリポイント関数を構成及び実行することによってエントリポイントを呼び出すことを要求できた。エントリポイント関数は、バインドメッセージを受信可能にするデフォルトの動きを有する必要がある。例えばＪａｖａクラスにおいて、receive_message関数を呼び出せるように、デフォルトＶＯＳ及び／又はオペレーティングシステム固有のクラスをＪＶＭにロードすることを実行する。ネイティブレイヤにおいて、エントリポイントは、デフォルトＶＯＳ及び／又はオペレーティングシステム固有の（ＯＳ）テーブルへのポインタであるパラメータを含んでいてもよい。モジュールエントリポイントが初期化されると（例えばＶＯＳ又はＯＳテーブルのコピーと、作業又はヒープメモリの割り当てを実行してもよく）、ＶＯＳ（又はオペレーティングシステム関数テーブル）におけるreceive_message関数を呼び出し、そしてバインドメッセージが受信されるまでは何もしない。

上記の初期化関数は、デフォルトＶＯＳ（又はオペレーティングシステム）テーブルを取得し、必要ならばそれをコピーし（又は共有メモリにおけるこれの位置にポインティングし）、receive_message関数を呼び出すというブートストラップ方法にすぎない。

receive_message関数はＶＯＳ又はオペレーティングシステムテーブル（ＯＳ）にあり、（関数コールかオペレーティングシステムスレッドメッセージのいずれかによる）メッセージの送信方法を判断するのはＶＯＳかＯＳである。バインドメッセージは特殊なメッセージタイプである（全てのメッセージは、メッセージのタイプを判断できる一意の識別子を有している）。従って、（通常クリーンな出口を強いる終了とは異なる）他のメッセージは、バインドメッセージを待機している時には無視される。

バインドハンドラは、新たなスレッド又はプロセスインスタンスを実行してもよいが、実際はこれを実行できずにＬＬＩテーブルを修正するだけのＶＯＳ又はＯＳ関数であるcreate_new_LLIを単に呼び出すだけである。しかしながら、バインドメッセージからの構成情報は、構成がそのＬＬＩについてセットアップされるように、create_new_LLI関数にパスされる。これはＬＬＩが使用する特殊なＶＯＳ及び／又はＯＳテーブルへのレファレンスを含む。これは、例えばレイヤが異なる実行環境においてプロトコルメッセージをレイヤにパスする必要がある場合には、初期化関数によってコピー又は使用されるＶＯＳ及び／又はＯＳテーブルと異なっていてもよい。新たなスレッドは、処理するメッセージを待機するために特殊なＶＯＳ（又はオペレーティングシステムテーブル）内のreceive_message関数を呼び出す。

上記のとおり、バインドメッセージは、レイヤの出力を次のレイヤに向けるための相互作用又はインタフェース情報を含む。バインドメッセージはまた、これ（関数テーブル）を実行するのに必要な関数コールを備えていてもよい。例えば関数又は関数ポインタの初期化テンプレートはモジュールエントリポイントにパスされてもよいのに対して、処理関数のより具体的なテンプレートは、例えば関連ＬＬＩについて選択された構成オプション及び／又はこれの実行環境に応じて、バインドメッセージによってモジュールにパスされてもよい。そしてＣＭは実行環境特有のセキュリティ機構に新たなＬＬＩから許容された他のＬＬＩへの相互作用を可能にすることを命令し、また共有構成データへのアクセスコントロール機構を任意に設定して、新たなＬＬＩによって許容された構成データの一部へのみアクセスを許容することができる。

バインドメッセージ構成オプションは、セキュリティ、性能及び電力消費についての汎用構成の優先順位を使用してレイヤ内の暗号化を有効化するか否かなどの、有効にする特徴を判断することができる。複数のプロトコルスタックインスタンスが同時に使用中である場合、１つのレイヤにつき複数のＬＬＩがあってもよく、これらは一意のインスタンス識別子（instance.ref）によって識別される。同一レイヤの異なるＬＬＩが異なる構成を有しており、例えば一部は暗号化をサポートし、一部はサポートしないということもまた可能である。

エントリポイントの呼び出しとパラメータのパスは、実現の具体的な詳細に関係なく一般的な方法でサポートされている。好ましくは、ＡＮＳＩ規格Ｃ（Ｃｄｅｃｌとも称される）定義を使用して、ネイティブソフトウェアモジュール、例えば（function.pointer）や（start.pointer）のパラメータを、（構成データアクセス関数を含む）スレッド作成及びメッセージ関連関数などの実行環境関連関数を与えるエントリポイントにパスする。しかしながら、Ｊａｖａレイヤについては、ソフトウェアレイヤのＪａｖａクラスはスレッドＪａｖａクラスを拡張し、稼動方法は、レイヤがＪＶＭにロードされるときに自動的に実行される。ネイティブのレイヤエントリポイントが呼び出されて新たなスレッドにインスタンスを作成すると、新たなインスタンスが新たな実行スレッドにおいて作成されて、エントリポイントは戻る。

あるいはまた、（とりわけレイヤが仮想マシン環境において実行するがこれらのレイヤだけに制限されない場合）エントリポイントクラス（又は位置）はレイヤソフトウェアモジュールを伴うマニフェスト（メタ）情報ファイルにおいて示されることが可能である。バインドメッセージが処理されると、新たなインスタンススレッドがｃｒｅａｔｅ＿ｎｅｗ＿ＬＬＩを使用して作成されて、次にreceive_message関数を使用してプロトコルメッセージを待機する。

各レイヤインスタンス構成データは、［signal.pointer］などのパケットやプロトコルメッセージを送るための次の（複数の）レイヤインスタンスに関する情報を含む。従って、レイヤが（プロトコルメッセージ内に含まれている）パケットを次のレイヤに送る必要がある場合、バインドレファレンス（bind.ref）のget_attribute関数を使用して、メッセージが送られる次のレイヤインスタンスをＬＬＩ構成データから取得する。

同一レイヤの複数のＬＬＩにインスタンスを作成する場合、バインドハンドラは（Ｌ２_２スタックにおける）新たなレイヤインスタンスについて構成データの新たなインスタンスを形成する。上記の構成データはインスタンスについての一意の識別子を含んでおり、新たなスレッドインスタンスが認証を作成するとＣＭに戻され、次にこれは適切な実行環境セキュリティ手段をセットアップする。バインドメッセージはＣＭによってＬＬＩに直接送られ、インスタンスの構成を変更する。

上述のとおり、着信バインドメッセージはインスタンス番号［instance.ref］を備える。バインドレファレンス［bind.ref］は、出力プロトコルメッセージが向けられるべき現在のＬＬＩの上のレイヤのＬＬＩを識別する。関数ポインタ［function.pointers］は特定のＬＬＩに適したオペレーティングシステム関数テーブル（ＯＳ及び、可能ならばＶＯＳ）を識別して、レイヤが所定数の関数のうちの１つ（例えば「create_new_LLI」）を呼び出すと、関数ポインタは、ＬＬＩが動作中の具体的な実行環境又はオペレーティングシステムに関するこの関数の現在フォーマット化されている関数コールを含む適切な位置及びメモリにポインティングする。すなわち、オペレーティングシステム関数テーブルはＬＬＩ内の「汎用」関数コールを、オペレーティングシステムによって使用される言語及びオペレーティングシステム依存関数にマッピングしてこれらの関数を実行する。関数テーブルは通常、信号パケットや、レイヤ間でパスされる他のメッセージにアクセスすることを含むメモリアクセス及び管理関数を含む。従って、例えばレイヤ１が（signal_packet_2の）信号パケットポインタ［signal.pointer］を、オペレーティングシステム関数send_messageを使用してレイヤ２内のＬＬＩに渡してもよい。これによってレイヤ２のＬＬＩはこの具体的な信号パケットにアクセスでき、さらにそれを、オペレーティングシステム関数テーブルによって提供された関数を使用し、またこれ自体のＬＬＩ実行スタック（Ｌ２_１スタック）を利用するこれの内部プロトコル関数に従って処理することができる。

上述のとおり、共通のプラットフォーム独立型仮想オペレーティングシステム（ＶＯＳ）関数テーブルを利用して、実行環境関数及びＬＬＩ構成情報にアクセスすることができる。これは実行環境（オペレーティングシステム及び仮想マシン）独立性を改良し、図１５に示されている。「古い」レイヤ３（Ｌ３）並びにアップグレードされたレイヤ３（Ｌ３’）を含む５つのレイヤ（Ｌ１からＬ４）が示されている。レイヤのうちの２つ（Ｌ３’とＬ４）が、Ｊａｖａ仮想マシン（ＪＶＭ）内で動作している様子が示されている。ＪＶＭは、これらのレイヤに対応するソフトウェアモジュールのコードをリアルタイムに解釈するためのインタプリタや仮想マシン環境を必要とし、また非Ｊａｖａソフトウェアとのインタフェース接続用のネイティブインタフェース（ＮＩ）を提供する。他のレイヤ（Ｌ１からＬ３）はオブジェクトコードに事前コンパイルされており、オペレーティングシステムによってランタイム時にネイティブに実行される。

またオペレーティングシステム１及びオペレーティングシステム２は各々異なるレイヤを実行するように示されている複数の実行環境を提供可能であるが、レイヤは依然として相互に通信可能である。

レイヤにおける汎用関数コールは、オペレーティングシステム関数テーブル（ＯＳ）を使用して実際のオペレーティングシステム特定関数に変換される。ＶＯＳの場合、更なる変換又はマッピングが必要である。各ＬＬＩへのバインドメッセージは、それ自体がＯＳにおけるオペレーティングシステム特定関数にポインティングしてレイヤの実行を可能にするＶＯＳ関数テーブルに関数ポインタを与える。これは、ＶＯＳ関数テーブルは異なるオペレーティングシステム特定関数において再ポインティングされることが可能であるために、オペレーティングシステム独立性を提供する。例えばＣＭは（バインドメッセージを介して）ＬＬＩに、例えばＵＮＩＸ系ＰＯＳＩＸ関数（ＯＳｘ）からＵＮＩＸ系システムＶオペレーティングシステム関数（ＯＳｙ）にＬＬＩによってランタイム時に動的に使用される汎用関数に対応するオペレーティングシステム特定関数のＬＬＩのＶＯＳテーブルを変更することを命令可能である。しかしながら動的変化は、一定のオペレーティング特定関数はシステム状態関連情報（とりわけセマフォ及びメモリ割り当てのような他のシステムリソース取扱関数）を含有又は変更するためにケアを必要とし、従ってＶＯＳのコンセプトによって、これらの間接参照機構内のインテリジェンス及びオペレーティングシステムの要約を提供することによって必要ならばＯＳ環境間で途切れることなく切り替えが可能である。それによってまた、異なる実行環境をサポートすることができる最も一般的な方法でソフトウェアコードモジュールが書き込まれる。

プロトコルソフトウェアにおいて、ストリング操作は頻繁には実行されないが、「calculate_crc」や「convert_ip_address_2_string」などの任意の頻繁な動作は対応するオペレーティング特定関数を有する汎用関数としてオペレーティングシステムテーブル（ＯＳ）やＶＯＳテーブルに含まれていてよい。代替構成において、暗号化及び解読などの一定の信号データ操作関数は、異なる暗号化及び解読動作を実行するように構成可能な汎用暗号化／解読レイヤにおいて実現可能である。これは、最も数学的関数を含んでおり、またこれらの複雑な数学的関数についての性能アクセラレータによって（コプロセッサのように）実行環境で動作可能であるために、数学的な拡張子を有するＶＯＳ又はオペレーティングシステムテーブル（ＯＳ）を（必要ならば）使用可能なレイヤである。そして、その他のかつ一般的なプロトコルレイヤはこれらの拡張子のない汎用ＶＯＳやオペレーティングシステムテーブル（ＯＳ）を使用する。

関数ポインタが実行環境及び言語独立的な方法でモジュールにパスされる方法が図１６及び１７に示されている。具体的には、これはＣなどのネイティブコードの例を示しており、図１６は既知の動的リンク付け方法を示しており、図１７は実施形態に従って関数テーブルポインタをパスする方法を示している。

図１６を参照すると、ソフトウェアモジュールのベンダは、一連のＡＰＩ関数（ｘ及びｙ）と、ターゲットプラットフォームのメモリに記憶されているデータと相互作用するための変数（ハードウェア、関数ライブラリセット、及び入力／出力などのオペレーティングシステム関数）と、可能ならばプラットフォーム上で動作する他のＡＰＩライブラリモジュールとを備える（この例ではＣプログラミング言語の）ソースコードプログラムを開発する。ソースコードは既知のコンパイラによってオブジェクトコードにコンパイルされており、これは一連の関数を、ターゲットプラットフォームに固有のバイナリマシン（又はオブジェクト）コードに翻訳する。バイナリコードは、各々がＡＰＩライブラリモジュールにおける一連の関数（ｘ及びｙ）のうちの１つに対応する一連のプレースホルダやシンボル（シンボルＸ及びシンボルＹ）を備える。

オブジェクトコードがターゲットプラットフォーム上のメモリにロードされて実行される場合、動的リンカーはコードを検査し、一連のシンボル（シンボルＸ及びシンボルＹ）を、ライブラリソースコードにおける関数（それぞれｘ及びｙ）に対応する事前ロードされているＡＰＩライブラリモジュールにおけるＡＰＩライブラリ関数（mem.loc(X)及びmem.loc(Y)）のメモリ位置と置き換える。ライブラリモジュールがまだロードされていない場合は、動的リンカー（又はＪａｖａ系実現の場合はクラスローダー）によって動的にロード可能である。そしてプラットフォームは、プログラム命令を含む一連のメモリ位置を介してプログラムカウンタをステッピングし、ソフトウェアモジュールが必要とするようなＡＰＩライブラリ関数コール（mem.loc(x)、mem.loc(y)）に対応するメモリ位置にジャンプする（分岐する）ことによってコードを実行可能である。

図１７を参照すると、ターゲットにロードするソフトウェアモジュールのベンダ（Ｃプログラマ）は、実際のＡＰＩ関数コール（関数ｘ及び関数ｙ）が図１６のアプローチで使用されている場所に対応する一連のＡＰＩ関数コール（redirect.f(x)及びredirect.f(y)）を備えるソースコードプログラムを開発する。出力先変更関数(redirect function)は、（アレイ内のヒープ又は共有メモリにおけるコンパイルタイムロケーションでは、一部は未知のまま保持されている）特定化されたＶＯＳ又はＯＳ関数ポインタテーブル内の特殊エントリのメモリ位置に関数コールを出力先変更するだけである。Ｃソースコードは、またもバイナリマシンコードを備えるオブジェクトコードにコンパイラによってコンパイルされているが、ソースコードにおける関数に対応するシンボル（Ｘ及びＹ）はない。その代わり、出力先辺呼応関数は、ターゲットプラットフォームにランタイム時にロードされているメモリ常駐関数テーブル内のエントリ（各エントリは１つのＡＰＩ関数に対応する）に保持されているメモリ位置へのジャンプ（分岐）命令に単にコンパイルされる。

このように、複数の実行スレッドは、ソフトウェアモジュールを動的に再リンクする必要なく異なるＡＰＩ実現コードを使用してソフトウェアモジュールコードを稼動させることができる。

コンパイラはリダイレクト関数を相対的なメモリポインタに翻訳し、これはランタイム時にＯＳ又はＶＯＳテーブルの開始に関連しており、それゆえに、オブジェクトコードによって示されている適切な実行環境特定関数でポインティングする。この場合、ソースコードは、図１６のＡＰＩ型関数ではなく出力先変更関数を使用して書き込まれる必要がある。

代替構成において、従来技術のソースコードプログラムは修正コンパイラによって同一のオブジェクトコードに翻訳され、コンパイラはＣ特定関数（例えば関数ｘ）をリダイレクト関数コールredirect.f(x)に翻訳して、（ランタイム時に動的にロードされた）関数テーブルの使用を可能にする。

このソフトウェアモジュールオブジェクトコードはメモリにロードされると、（メモリの開始アドレスなどの）プラットフォーム固有のマッピングテーブルのレファレンスがパスされ、これはヒープ又は共有メモリ内の場所に対応する。関数ポインタのデフォルトテーブルは、例えばソフトウェアモジュールがテーブルレファレンスポインタにエントリポイント関数や他のパス手段を含んでいない場合にもまた可能であるオブジェクトコードに関して、所定の相対的なメモリ位置にロードされることが可能である。

そしてプラットフォームは、プラットフォーム上の実際のＯＳ又はＶＯＳライブラリ関数（mem.loc(x)）のメモリ位置にあるテーブルエントリ（redirect.f(x)）に対応するメモリ値にプログラムカウンタを出力先変更（ジャンプ又は分岐）するredirect.f(x)からコンパイルされる一連の命令を実行することによってこのオブジェクトコードを実行することができる。関数は実行されて、プログラムカウンタは、ジャンプ（又は分岐）がソフトウェアモジュールオブジェクトコードにおいて生じた場所に戻る。

これによって、プラットフォーム（オペレーティングシステム、動的リンカー、あるいはＪａｖａ仮想マシン）がソフトウェアモジュールコードの特殊な言語及び意味や他のモジュールとどのように相互作用するかについての知識を有している必要がないという意味において、位置独立型コード（つまり任意のメモリアドレスから実行可能なコード）にコンパイルされてプラットフォーム独立的になるロード可能なソフトウェアモジュールが可能になることが分かる。また、動的ローダーがプラットフォーム特定関数について解釈しまたメモリ位置と置換する必要がある所定のシンボルではなくマッピングテーブルへの同一ポインタをコンパイルされたオブジェクトコードは含むので、ソースコードは言語と無関係であってもよいことがわかる。例えば、C、VisualBasic、あるいはPascalで書かれたプログラムは各々相対的な関数ポインタの同じオブジェクトコードにコンパイルされて、これは実行環境特定関数が配置されているメモリ内の開始ポイントにパスされて、相対的ポインタはこの開始ポイントからの対応する関数の相対的位置を示している。これによってベンダは、いずれの言語でも書き込みができ、またプラットフォームとは無関係のソフトウェアモジュール（オブジェクトコード）を提供することができる。

最終的に、ソフトウェアモジュールコードを実行する各スレッド又はプロセスは異なるライブラリ関数テーブルマッピングによってこのように実行でき、同じコードの動きを、ライブラリ関数が実現されている方法で全く異なるものとすることができる。従って、（メモリ常駐バイナリ又はバイトコードモジュール上の）１つの実行スレッドは、軽量のセットのライブラリ関数を実現して性能について最適化するライブラリ関数を呼び出すことができ、また（同じメモリ常駐コードの）別の実行スレッドは重量のライブラリ関数実現を使用して、例えばセキュリティについて最適化することができる。

図１８及び１９を参照すると、Ｊａｖａ言語系レイヤプログラムについて動的リンク付け（クラスローダー）及び関数ポインタパス方法がそれぞれ示されている。ネイティブ及びＪａｖａソフトウェアモジュール間の主な違いは、Ｊａｖａにおいて、間接参照についての余分なレイヤが導入されてＪａｖａ及びネイティブソフトウェアモジュール間をまたぐことである。Ｊａｖａソフトウェアモジュールは、ネイティブライブラリ関数Java_class_redirect.f(x)及びJava_class_redirect.f(y)にそれぞれ対応するＪａｖａのネイティブインタフェース方法redirect.m(x)とredirect.m(y)とを有している。Ｊａｖａのネイティブインタフェース方法はクラスローダーによってネイティブ関数にマッピングされる。通常、標準ＪＶＭクラスローダーを使用する場合は、ネイティブライブラリモジュールはSystem.LoadLibrary方法を使用してロードされなければならない。しかしながら、クラス及びライブラリをロードする他の方法を使用してもよいカスタムＪａｖａクラスローダーを作成することも可能である。

そしてクラスローダーは、この例においてはＪａｖａのネイティブインタフェースクラス（mem.loc(redirect.f(x)）とmem.loc(redirect.f(y)）において使用されているネイティブシンボルを解決する。そしてこれらの出力先変更関数は、ネイティブ出力先変更関数と同様に動作し、マッピングテーブルを使用して、関数コールを真の関数、mem.loc(x)とmem.loc(y)とに出力先変更する。

Ｊａｖａクラスローダーは、明らかにプラットフォーム固有の方法で実行されて、かつ各プラットフォームは対応するセットのインタフェースライブラリを有しており実際のネイティブＡＰＩライブラリへのアクセスを可能にすることを必要としているために、ネイティブインタフェースライブラリをロードするというこの中間ステップを排除するようにカスタマイズされることが可能である。

図２０はプロトコルスタックの実現に対するスレッド／メッセージアプローチを示している。このアプローチにおいて、スレッドはプロトコルスタックにまたがる各パケット又は信号と関連付けられている。示されている例において、thread_signal１は、スタックインスタンス内のレイヤ１によって処理されて、示されている種々の関数やサブモジュールによってメッセージが処理される（パケット又はプロトコルメッセージは図１４においてコードブロック又はモジュールの一部を処理する）レイヤ２上に継続するプロトコルメッセージ信号１と関連しており、実行は、メッセージがさらに処理されるレイヤ３上に継続する。同様に、thread_signal２はプロトコルメッセージ信号２に関連しており、これはレイヤ１を介してレイヤ２上にパスされて、示されている特定の時点でレイヤ２の「チェックサム」サブ関数に到着する。このアプローチは既存の提案されるフレームワークに類似しているが、多くのマルチタスクオペレーティングシステムによって提供されている異なるセキュリティ及び性能構成を有する異なる実行環境は異なるＬＬＩを識別するのに容易に使用することができず、代わりに、ＬＬＩに基づいて必要ならばスレッドを事前に空にすることができるカスタマイズされたスケジューラを実現する必要があるという欠点がある。

蓄積関数が破線のアウトラインで示されているが、説明を容易にするために上述されていない。蓄積関数がスレッド／メッセージアプローチにおいて実現される場合、実現について２つの可能性がある。１つはスレッドを単に終了させることであるが、これは、バッファされているパケットを提供するためにバッファをモニタする別のスレッドに依存している。もう１つはコール関数に戻ることであり、実行スレッドを使用して、別のメッセージを処理することができる。非常に軽量のスレッドモデルが実現されない限り、オペレーティングシステム上でのスレッド作成の待ち時間及びオーバーヘッドはかなりかかるために、これはスレッドを終了するよりも魅力的である。

これは図２１に概略的に見られ、２つのコードブロック２が、これらのコードブロックを介する種々の実行スレッドと関連している実行スタックと、ヒープ又は他の共有メモリオブジェクトと共に、作業メモリに示されている。種々の実行スタックは、マイクロプロセッサのレジスタの現在の状態、関数及びモジュール内の静的データ、及び関数コールパラメータパスについての種々のパラメータを記憶する。スケジューラ及びスレッドマネージャは既知の方法で種々のスレッドの動作をコントロールし、現在又は存続しているスレッドについてのそれぞれのスタックの適切なコンテンツによってマイクロプロセッサのレジスタをロードし、レジスタのコンテンツを、（コンテクスト切り替えとして既知の）切り替えられたスレッドについての適切なスタックに記憶する。例えば、コード（ＴＳ１）のＬ２ブロックにおけるthread_signal１の実行ポイントがコードを介してthread_signal２（ＴＳ２）よりもさらに進められており、ここでは（ＴＳ１）と（ＴＳ２）はスレッドごとのプログラムカウンタ値を示しており、それゆえにコードモジュールのいずれのポイントをそのスレッドの次に実行するのかを示しているということが分かる。種々の他の実行スタックはプロトコルスタックの種々のコードブロックＬ１からＬ５を介してパスする他の信号と関連している。各スレッドが単一の信号と関連しており、同期的な方法でプロトコルスタックを介して「それに続く」ことが分かる。

逆にさらなる実施形態は図２２に示されているようにＬＬＩごとにスレッドを使用している。thread_layer2_LLI#１はレイヤ２又はコードモジュール内の１つのスレッドに対応しており、これが下部レイヤ（例えばレイヤ１）から信号やパケット（プロトコルメッセージ）を受信している。スレッドはレイヤの種々のサブ関数を介してこれを処理して、処理した出力（信号、パケットあるいはメッセージ）を高次のレイヤ（例えばレイヤ３）にパスする。そして、これの関連レイヤ２の受信メッセージや入力関数に戻り、次のプロトコルメッセージの処理にそなえる。同様にthread_layer2_LLI2は第１のスレッドと同じレイヤ（レイヤ２）における分離パケットやプロトコルメッセージと関連しているが、異なるインスタンス又はＬＬＩにある。示されている時点で、この第２のスレッド又は実行ポイントはレイヤ２の暗号解読サブ関数に到達している。各スレッドがこれのＬＬＩを介してプロトコルメッセージを処理すると、アイドル状態に戻り、receive_messageオペレーティングシステム関数を呼び出して下部レイヤからの新たなパケットを待つ。ＬＬＩ間をパスするメッセージは実行環境によって、可能ならば、ＬＬＩを実行する実行環境が別個の物理的プロセッサ上に常駐している場合には関連するＬＬＩのいずれかからの異なるオペレーティングシステムスレッド又はプロセス（例えばthread_send_message(x)）を使用して対処される。receive_message関数は所定のメッセージキューにおいてメッセージを待機して検索するだけである。同様に、send_message関数はメッセージを所定のメッセージキューに置く。

先ほどのアプローチに対するこのスレッド／ＬＬＩアプローチの利点は、不当に動作したソフトウェアモジュールが他のＬＬＩの動作に悪影響を及ぼすのを回避するために、各ＬＬＩが（必要ならば）異なる優先順位を有し、また（適切な場合は）異なるセキュリティ手段を適所に有している異なる実行環境において動作するように構成可能であることである。

また蓄積関数が、最初の説明を簡潔にするために破線のアウトラインで示されているが、プロトコルスタックに対するこのアプローチは元来本質的に非同期的である（すなわちメッセージの蓄積を有している）ため、非同期メッセージのパスを使用することは魅力的であり、メッセージ（パケット）は、送信者及び受信者双方がアクセス可能である共通の永続的な方法でバッファされている。（スレッド／メッセージアプローチの場合同様に）蓄積がレイヤコード内で自然に実行される場合、メッセージデータは送信者から蓄積バッファにコピーされて、再びバッファから次のレイヤにコピーされなければならない。

永続的な共有メモリキューを有することによって、メッセージはデータコピーの必要なくキューにポスティングされる。プロトコルスタック実現におけるコピーは良好な性能を得るために最小化されなければならない。従って、send_message関数が受信者のメッセージキューのメッセージへのポインタを単に置くだけならば、データコピーは全くなく、受信者は依然として同様にデータにアクセスできる。他の利点は、１つのレイヤインスタンスＬＬＩが別のＬＬＩによって再構成（つまり置換）されている場合、依然としてキューは存在し、またメッセージデータも依然として存在するために、何もなくならず、何事も起こらなかったように処理は継続可能である点である。

さらなる利点は、スタックにおけるＬＬＩのアップグレード又は置換時に、ＬＬＩによって処理されているがアップグレードされていないプロトコルメッセージ（信号）が影響を受けないという点である。また、必要ならば、事前実行切り替えが、古いインスタンス向けのパケットを、新たなインスタンスによって、又は古いインスタンスを停止することによって（これによってパケットを破棄せずに古いバージョンによる更なる処理を防ぐ）使用されるキューに出力先変更することによって達成できる。パケットは新たなＬＬＩインスタンスにそなえてキューに入れられ始めるので、例えば、send_messageとreceive_message関数が永続的な共有メモリキューで実現されて、キューが、新たなＬＬＩのインスタンスの作成前に新たなＬＬＩバージョンインスタンスの上下のＬＬＩインスタンスに対してＣＭ送信バインドメッセージによって再度関連付けられることができる場合にこれは可能である。このアプローチは、新たなＬＬＩのインスタンスの作成は時間がかかるものであってもよいために魅力的であり、例えば安全でないＬＬＩバージョンから安全なＬＬＩバージョンに切り替わると、安全でない方法で続けられているパケット処理はシステムにおける脆弱さを現すであろう。

図２３は、図２１に類似の、スレッド／メッセージアプローチの概略を示しているが、スレッド／インスタンスアプローチに対応する実行スタックを示している。例えば、レイヤ２のコードモジュールに関連した２つのスレッドが示されているが、各々は、Ｌ２内の異なるプロトコルメッセージとは反対にＬ２の異なるインスタンス（ＬＬＩ）と関連している。（ＴＬ２_１）、（ＴＬ２_２）及び（ＴＬ１_１）は、ＬＬＩスレッドごとのコードモジュールにおけるプログラムカウンタ値又は位置を示している。

図２４及び２５は、実施形態におけるアプリケーションについてコードモジュールに到達するための異なるルートを示している。図２４において、ベンダはＣ＋＋ソースコードプログラムを開発しており、これは、関数テンプレートにおける汎用関数に対応する一連のポインタを備える汎用実行コードモジュールフォーマットにソースコードを翻訳するために、「ソーストゥポインタ（source-to-pointer）」コンパイラによってコンパイルされている。ポインタは上述のように共通のデータフォーマットであり、ＯＳテーブルやオブジェクトにおける対応するオペレーティングシステム特定関数への相対的なメモリポインタである。例えば、第１の汎用関数（例えば、create_new_LLIであるFunc#１）はＯＳにおける第１のオペレーティングシステム特定関数に対応する。対応するＯＳがメモリ内のどこにあるかを知っていれば、モジュールを実行できるので、実行環境はＯＳにおける適切にフォーマット化された実行環境特定関数にポインティングされる。

図２５に示されている代替構成において、ベンダは同じＣ＋＋ソースコードプログラムを開発し、これは標準Ｃ＋＋コンパイラによってプラットフォーム固有のＣ＋＋コードモジュールにコンパイルされる。さらなるコンパイラは、上述のような、かつＯＳ（別の実施形態においてはＶＯＳ）による実行に適した汎用関数ポインタコードモジュールにこのモジュールを変換する必要がある。

図２６は上記の実施形態の一部を使用する例示的実現を示している。Bluetooth性能を有する端末デバイスは、ネイティブ言語ソフトウェアレイヤ（ソフトウェアレイヤ＃１及び＃２）内で標準Bluetoothプロトコルスタックを稼動する。Bluetoothスタックは、プラットフォームオペレーティングシステム及び言語独立型プロトコルレイヤが動的に共にリンク付けされることを可能にする上記のバインド機能性を使用する。２つのプロトコルスタックインスタンスが示されており、（インスタンス＃１及びインスタンス＃２）は異なるBluetoothサービスを提供するように構成可能である。例えば、ＬＡＮアクセスプロファイルインスタンス及びVoIP又はBluetoothネットワークカプセル化プロファイルインスタンスである。そしてＬＡＮアクセスプロファイルを使用して専用Bluetoothアクセスポイントを使用するウェブ閲覧を実行し、ＶｏＩＰプロファイルを使用して同時に同じアクセスポイントを介して電話をかける。

そしてBluetoothスタックは、図２７に示されているようなダウンロードされたＪａｖａレイヤ（レイヤ＃３）を使用する新たなプロファイルに対するサポートを付加することによってカスタマイズ可能である。このレイヤは（例えば）強化されたセキュリティや性能、又は新たなサービス機能性を提供する。Ｊａｖａレイヤは動的にロードされて、新たなレイヤインスタンス（ＬＬＩ＃１及びＬＬＩ＃２）は、用いられている実施形態のおかげでBluetoothスタックを再開する必要なく既存のネイティブ言語のBluetoothスタックに結びつく。従って、既存のBluetoothの接続セッションは切断されない。そして新たなレイヤを使用して、端末とアクセスポイント間でデータを暗号化及び解読するのに使用される強化セキュリティプロファイルにインスタンスを作成可能である。

オペレーティングシステムの独立性をサポートするために、プロトコルスタック内の他のモジュールと相互作用するためにモジュール内で使用される必要のあるプラットフォーム特定関数のオペレーティングシステム関数テーブル（例えば共有メモリ割り当て及びスレッドメッセージなどを可能にする関数）が使用される。バインドメッセージはまた、いずれの他のモジュールが相互作用可能であるかを判断し、実行環境機構はこれらのソースの認証を検証するために存在する。バインドメッセージはプロトコルレイヤが必要とする全ての必要な開始構成データを含んでいなければならない。

このBluetoothスタック内のレイヤは異なる実行スレッドを使用してインスタンスが作成されて、各レイヤはプロトコルメッセージエントリ及び出力ポイントとしてＶＯＳ又はＯＳのreceive_message及びsend_messageをそれぞれ利用して、ＶＯＳ又はＯＳが、ＬＬＩの選択された実行環境に適した相互作用機構を実現することを可能にする。スレッド又はプロセスは一意のＬＬＩ名によって識別可能であり、これは一意のレイヤ名（この場合は「Bluetoothスタックレイヤ＃３」とレイヤインスタンス識別子（この場合は「ＬＬＩ＃１」と「ＬＬＩ＃２」）から成る。このように、スレッド名を使用してレイヤインスタンスを一意に識別する。ＶＯＳ及びＯＳはオペレーティングシステム特有の機構を使用して、ＬＬＩ間の相互作用及びＬＬＩスレッドのスケジューリングをサポートすることができ、またプロセスや独自性（ｐｒｏｐｒｉｅｔａｒｙ）や高度に最適化された機構もまた用いることができる。これは、セキュリティや性能の観点、さらにはメモリ及び電力消費などのリソース利用の観点から最適化されることができる。

このアプローチによってＬＬＩは異なる構成によって生成可能である。各ＬＬＩはバインドプロセス時に、ＬＬＩが通信する他のＬＬＩだけではなく、特定のインスタンスについて使用する構成データをも同定するバインド信号によって構成される。

ＶＯＳにサポートされているＬＬＩメッセージキューは永続的な共有メモリに保持されて、ソフトウェアの動的アップグレードを可能にするのに対してプロトコルスタックは依然としてアクティブである。ＬＬＩのリバインドはまた、レイヤのアクティブプロトコルスタックへの挿入を可能にすることができる。

新たなレイヤ（Bluetoothスタックレイヤ＃３）をプロトコルスタックに構成するプロセスは以下のとおりである。

１．第１のステップは関連モジュールエントリポイントを呼び出すことによって「Bluetoothスタックレイヤ＃３」の実行を開始することである。Ｊａｖａモジュールの場合、クラスファイルがＣＭによって選択されたＪＶＭ環境にロードされる。モジュールは、まだロードされていない場合にはデフォルトＶＯＳ又はＯＳのＡＰＩをロードする。そして稼動方法はＪＶＭによって自動的に呼び出されて、レイヤソフトウェア（モジュール）は、構成及びメッセージデータに引き続きアクセスできるようにload_template関数を呼び出して、またreceive_message関数を呼び出してバインドメッセージを待機する。

２．バインドメッセージは必要な構成情報を有する「Bluetoothスタックレイヤ＃３」スレッドにパスされる。そしてスレッドは、ＶＯＳ又はＯＳのcreate_new_LLI関数を呼び出すことによって新たなＬＬＩインスタンスを作成する。新たなＬＬＩ内で、ＬＬＩ固有のＶＯＳ及び／又はＯＳテーブルは必要ならばロードされる。スレッド「Ｂｌｕｅｔｏｏｔｈスタックレイヤ＃３のインスタンス＃１」が作成されてＯＫ応答が送り返される。新たなＬＬＩは（異なるテンプレートが必要ならば）汎用load_template関数を実行して、メッセージ及び構成データへのアクセスを可能にして、そして次のメッセージを待機するためにreceive_messageを呼び出す。

３．「Bluetoothスタックレイヤ＃２のインスタンス＃１」へのリバインドリクエストメッセージはＯＫメッセージによって応答してリバインドを確認して、「ホストインターネットスタック」を元々目的とする次のパケットは全て「Bluetoothスタックレイヤ＃２のＬＬＩ＃１」に送られる。

４．「ホストインターネットスタック」に対するリバインドメッセージ及びルーティングテーブルは更新されてＯＫ応答が受信される。

５．ＬＬＩ＃１が次にアクティブとなり、同じ手順がレイヤ＃３のＬＬＩ＃２について繰り返される。

Java Bluetoothスタックレイヤ＃３がネイティブ言語Bluetoothスタックレイヤ＃２及びホストインターネットスタックと容易に相互動作できるように、上記の共通ＶＯＳ及び／又はＯＳがサポートしている相互作用機構と、スレッド及びプロセスのスケジューリングが使用される。プラットフォーム独立的にこの共通機能性にアクセスするのに使用される方法は、動的にロード可能なＶＯＳ及び／ＯＳ関数ライブラリによる。

「Bluetoothスタックレイヤ＃３」スレッドがＪＶＭ環境においてインスタンスを作成されると、デフォルトＶＯＳ及び／又はＯＳライブラリをロードするためのＪａｖａコールが実行される。ＶＯＳ及び／又はＯＳライブラリは１セットのシステムリソース関連取扱関数を含む。これらは最小限以下を含む。

・信号及びメモリ割当関数
・スレッド作成（及び破棄）関数
・メッセージ送信及び受信関数
・構成及び信号データアクセス関数
関数のＶＯＳ及び／又はＯＳライブラリを引き続き使用して（適切なロード済みテンプレートを使用する）他のＬＬＩ及びアクセス構成データと通信する。汎用ＬＬＩ及びＶＯＳ関数は多数の異なるオペレーティングシステム上でサポート可能であり、また多数の異なる言語及び仮想マシン環境からアクセスできる。関数のライブラリはまたメッセージキュー、信号及び構成データへのコントロールされたアクセスを提供する。例えば、関数のライブラリはＬＬＩ識別子に基づいた構成データへのアクセスを制限可能であり、また適切に認証された送信元及び宛先に対するメッセージの送信及び受信の使用を制御できる。このようにして、安全な言語及びオペレーティングシステム独立型プロトコルスタックの実行環境が作成される。

このようにして、例えば「Bluetoothスタックレイヤ＃３のＬＬＩ＃１」が一定のセットの暗号化機能性設定によって作成可能である。これらの設定は「Bluetoothスタックレイヤ＃３のＬＬＩ＃２」においては異なっていてもよく、バインドプロセスで使用されるバインドメッセージで定義される。そしてＬＬＩ＃２はＬＬＩ＃１のパラメータにアクセスすることができず、この逆も同様であり、またＬＬＩ＃１はＬＬＩ＃２向けのパケットを遮断することはできず、この逆も同様である。

しかしながら、（コンピュータ実行可能な命令によって定義されているような）機能性の全く新たなレイヤのプロトコルスタックへのロードは、プロトコルスタックが定義されているコンピュータにおいて実質的なメモリリソースを拡張可能であるために、環境によっては困難である。

メモリがコンピュータにおいてリソース不足である場合、追加レイヤの動的ロードは、追加レイヤを定義するマシンコード命令の更なるメモリリソースの保持が必要であるために望ましくない。これはコンピュータの性能の悪さや誤作動につながる可能性がある。

さらに、実際は、追加レイヤは、これの機能性の特定な部分を除いて置換することを意図しているために、プロトコルスタックのレイヤと実質的に同じマシンコード命令によって定義されてもよい。従って、使用に際して、追加レイヤを含むプロトコルスタックのインスタンスは、追加レイヤの導入によって強化されなかった置換されたレイヤの機能性に関する多数の命令のうちの２つコピーを記憶する必要がある。実質的なメモリリソースを有するコンピュータにおいて、これは実際的な問題ではないのに対して、これはプロトコルスタックと平行して更なる機能性の稼動を可能にするために、コンピュータにおけるメモリ消費を削減する方法を見出すことは常に望ましい。

プロトコルスタックにおけるレイヤは従来多数の所定の状態のうちの１つに存在するように設計される。特定の状態にあるレイヤは一定のメッセージを受信し、それに応答し（メッセージは所定の状態のうちの別の状態にレイヤを変換する）、あるいはレイヤの状態をそのままにしておくように動作可能であるように構成される。

これらの所定の状態間のレイヤの条件的遷移はレイヤによるプロトコルメッセージの受信に依存している。柔軟に動作するレイヤの有効性は、メッセージが利用されているコンピュータプログラミング言語に関係なく対処されること、すなわち言語独立性を促進することによって高められる。

レイヤの有効かつ永続的な設計を可能にし、また適切なソフトウェアの設計によって実現するために、設計者はレイヤの状態、及び受信メッセージに応答してレイヤの所望の動きを記述する状態間の遷移を最初に決定してもよい。従って、レイヤの各状態は関数モジュールによって実現される。

モジュールはレイヤがインスタンスを作成されるコンピュータの自己完結機能性を定義し、それに直接適用するメッセージを捕捉する一方で、別の状態にある場合にはレイヤの動きに対処する別のモジュールによって処理するために、適用しないメッセージを無視する。

従って、状態を定義する複数の関数モジュールのようなレイヤのコンテクストにおいて、また受信メッセージに応答した状態間の所定の遷移によって、更なる機能性のレイヤへの所望の導入は状態定義モジュールのうちの１つにのみ変化する必要があるということが可能である。

上記の例において、置換レイヤに関する対応するマシンコード命令のかなりの割合が元のレイヤに対する命令と同じであろうがなかろうが、レイヤ全体を置換することが必要である。これはまずメモリを不必要に拡張するが、いずれの方法にせよ、新たなマシンコード命令をコンピュータにロードするという動作は、コンピュータに既に存在している命令をロードすることに関係する。

従って、レイヤを定義する状態マシン全体ではなく、変更する必要のある状態マシン内の状態を定義するマシンコード命令のみをロードすることができるというのが望ましい。これは、一方で、メモリがそれほど高価ではなく、また送信ソースが制限された送信リンク上でより少数のマシンコード命令の転送を介して達成可能であるという解決策につながる点において好都合である。

コンピュータに送信されたデータ量を削減するという関数は動作環境を表すという点が理解される。従って、状態ベースのレイヤプロトコルスタックを実行するコンピュータに、レイヤの改良をレイヤの置換機能性の導入によって実行可能にする関数を提供する一方で、そのまま、レイヤの機能性が事前ロードされたマシンコード命令によって実現されているということがさらに望ましい。

本発明の一態様は、プロセッサ及びメモリを有する処理装置に与えられる信号を処理するための通信プロトコルを修正するための方法を提供し、前記プロトコルは複数のプロトコルレイヤによって定義されており、少なくとも１つのレイヤが使用中に複数の所定の状態のうちの１つを占めることが可能であり、各レイヤは、他の状態のうちの１つへの前記レイヤのメッセージ依存性遷移を含む所定の機能性と関連しており、前記方法は、ソフトウェア更新モジュールをメモリにロードすることを備えており、前記モジュールは前記レイヤのうちの１つの前記状態の１つに対応する１つ以上のメッセージを受信及び処理するように構成されており、前記モジュールは別の状態にレイヤを遷移させるように動作可能である少なくとも１つのメッセージ依存性遷移ユニットを備える。

好ましくは、前記モジュールは対応する状態を実現する前記所定の機能性を意図したメッセージを傍受して、前記メッセージ依存性遷移ユニットに関係のない前記所定の機能性メッセージにパスするように動作できる。

本発明の好ましい実施形態において、前記更新モジュールは、メッセージを受信及び処理して、別の状態にレイヤを遷移させるように動作でき、前記メッセージは前記モジュールのロード前に前記レイヤを遷移させるようには動作できない。

前記更新モジュールは、前記信号に対応するプロトコルメッセージを他のモジュールと交換するように構成されてもよく、前記他のモジュールは、前記他のレイヤに対応する１セットの汎用関数に従って前記信号を処理するように構成されている。

前記方法はさらに、前記他のソフトウェアモジュールを前記メモリにロードすることを備えており、前記他のモジュールは、関数マッピングオブジェクトにおける前記汎用関数に対応する汎用関数ポインタを備えており、
他のモジュールごとに、前記関数マッピングオブジェクトを前記メモリにロードし、前記オブジェクトは、前記汎用関数を１つ以上の装置特定関数にマッピングするために、前記汎用関数に対応する装置特定関数ポインタを備えており、
受信信号をプロトコルレイヤに従って処理するために、前記マッピングされた装置特定関数に従って前記他のモジュールを実行する。

好ましくは、前記方法はさらに、前記別のモジュールに対する識別子を備えるバインドメッセージを受信する各ロード済みソフトウェアモジュールを備えており、第１のモジュールはバインドメッセージによって同定された前記他のモジュールとプロトコルメッセージとを交換するように構成されている。

前記モジュールは前記プロトコルメッセージを処理するための異なる構成オプションを有していてもよい。

前記バインドメッセージは、前記モジュールの前記実行において実現する前記構成オプションを判断するための識別子を備えていてもよい。

前記プロトコルメッセージ、前記バインドメッセージ及び前記汎用関数ポインタは共通の汎用フォーマットであってもよい。

好ましくは、前記方法はさらに、第２のソフトウェアモジュールを前記メモリにロードすることを備えており、前記第２のモジュールは、第２のレイヤに対応する１セットの汎用関数に従って前記信号を受信及び処理するように構成されており、前記第２のモジュールは第２の関数マッピングオブジェクトにおける前記汎用関数に対応する汎用関数ポインタを備えており、前記第２の関数マッピングオブジェクトを前記メモリにロードすることを備えており、前記オブジェクトは、前記汎用関数を１つ以上の第２の装置特定関数にマッピングするために前記汎用関数に対応する第２の装置特定関数ポインタを備えており、前記プロトコルレイヤに従って受信信号を処理するために前記マッピングされた第２の装置特定関数に従って前記第２のモジュールを実行することで成り、前記第１及び第２のモジュールは異なる実行又は装置固有の環境で実行する。

前記更新モジュールは言語独立型であってもよい。

高レベルソフトウェア言語コードは、前記レイヤに対応する前記１セットの汎用関数に従って前記信号を処理するために提供されてもよく、前記コードを前記言語独立型ソフトウェアモジュールにコンパイルする。

本発明の第２の態様は、好ましい形態で本発明の前記第１の態様の方法を実行するための処理装置をコントロールするためのプログラムを備える。

記憶媒体が提供されてもよく、設定可能装置にロードされる場合に、前記設定可能装置に好ましい形態で本発明の前記第１の態様の方法を実行させるためのプログラムを実行可能にするデータを有している。

信号が提供されてもよく、設定可能装置にロードされる場合に、前記設定可能装置に好ましい形態で本発明の前記第１の態様の方法を実行させるためのプログラムを実行可能にするデータを有している。

本発明の第３の態様によれば、プロセッサとメモリを有する処理装置に与えられる信号を処理するための通信プロトコルを修正するための装置が提供されており、前記プロトコルは複数のプロトコルレイヤによって定義されており、少なくとも１つのレイヤは使用中に複数の所定の状態のうちの１つを占めることが可能であり、各状態は、他の状態のうちの１つへのレイヤのメッセージ依存性遷移を含む所定の機能性と関連しており、前記装置はソフトウェア更新モジュールをメモリにロードするための手段を備えており、前記更新モジュールは前記レイヤのうちの１つの前記状態の１つに対応する１つ以上のメッセージを受信及び処理するように構成されており、前記モジュールは別の状態に前記レイヤを遷移させるように動作可能な少なくとも１つのメッセージ依存性遷移ユニットを備える。

本発明の第４の態様は、本発明の第３の態様のような装置として構成された設定可能装置を提供する。

本発明の具体的な実施形態を、添付の図面を参照して例示によってのみ次に説明する。

図２８に示されているように、（後に説明する図３０に示されている）汎用プロトコルスタックのレイヤ１０は３つの可能な状態を有しており、遷移はこれらの状態間で定義される。本例において、３つの状態は切断状態１２と、connect_pending状態１４と接続状態１６とを有する。

切断状態１２は状態メッセージ取扱関数ポインタＦＵＮＣ＃１を含む。connect_pending状態１４は２つのメッセージ取扱関数ポインタＦＵＮＣ＃２及びＦＵＮＣ＃３を含んでおり、接続状態１６はまた２つのメッセージ取扱関数ポインタＦＵＮＣ＃４及びＦＵＮＣ＃５を含む。

関数ポインタはレイヤが受信したプロトコルメッセージを検出するように動作可能であり、レイヤは対応する状態１２、１４、１６にある場合、対応するオペレーティングシステム関数にアクセスすることによって適切なメッセージの受信に応答する。これらの関数は、プロトコルスタックに沿った送信についての更なるプロトコルメッセージの生成をもたらす。

図２９は、メッセージ取扱関数ポインタＦＵＮＣ＃１からＦＵＮＣ＃５とオペレーティングシステム関数間の関係を示している。メッセージ取扱関数ポインタはオペレーティングシステム関数又はそのシーケンスに対応し、意図している方法でシステム又は実行環境リソースにアクセスする。

明確には、メッセージ取扱関数ポインタは同定可能な動作に対応し、connect_req（接続リクエスト関数）、connect_conf（接続確認関数）、connect_res（接続リクエスト関数への応答）、切断及びchange_QoS（サービス品質変更関数）というラベルに関連している。

図３０に示されているように、通信デバイス２９は、マシンコード実行可能な命令を実行することができ、無線通信リンクによってアンテナ２８を介して別のデバイスへの物理的接続を確立するための通信ハードウェアユニットにバス２４を介して接続されているプロセッサ２２と、（オーディオ又はディスプレイ手段によって）ユーザとのデータ出力を確立するためのユーザ出力ユニット３０と、適切な入力デバイス上のユーザ入力動作を検出するためのユーザ入力管理ユニット３２とを含む。

ユーザ入力管理ユニット３２は、キーパッド、スクリーン上のポインティングデバイス、タブレット及び書き込み実現、スクリーン上のダイレクトペン動作、音声入力及びその適切な解釈、そしてまた光線などの上級の入力技術の起動などのユーザの入力動作を受容することができ、プロセッサ２２はまた、加入者同定モジュール（ＳＩＭ）などの内部メモリ及び／又はリムーバブル記憶メモリを含んでいてもよい記憶デバイス３４に対するレファレンスを作成できる。

プロセッサ２２はさらに作業メモリ３６と通信しており、本例ではここに、３つのレイヤ、つまりレイヤ１、レイヤ２及びレイヤ３とプロトコルレイヤインスタンス構成データ（各インスタンスは異なる方法で構成可能である）を備えるプロトコルスタックが記憶されている。

使用中、図３１に示されているように、モバイル通信デバイスは無線インターネットアクセスユニット４０と無線通信を確立することができ、それによってこれはインターネット４２と、ひいては適切な手段、第２の強化状態（connect_pending状態１４）を備える第１のアップグレードユニット４６、及び複数の状態へのモジュール強化を備える第２のアップグレードユニット４８によってポスティングされているサーバ４４との接続を確立することができる。

図３２に示されているように、示されている通信デバイス２９は、適切な手段によって、第２の状態の強化機能性を含むモジュール４６のコピーを受信している。作業メモリ３６におけるこのモジュール４６の記憶によって、レイヤ２の動作が強化される。これが達成される手段について次に図３３を参照して説明する。図３３に示されているように、connect_pending#２状態モジュールは、オリジナル関数ポインタＦＵＮＣ＃２に対応するリダイレクト関数５０と、オリジナルのconnect_pending状態１４の関数ポインタＦＵＮＣ＃３に対応する更新関数ポインタ５２とを備える。これの更新の性質について、この関数ポインタ５２はＦＵＮＣ＃３＿１と名づけられる。

図２８に示されているレイヤ１０の使用において、レイヤ１０が、状態１４がアクティブになる状態にある場合に、取扱関数ポインタＦＵＮＣ＃２又はＦＵＮＣ＃３に対応するプロトコルメッセージが想定可能である。図２８に示されている場合において、関数ＦＵＮＣ＃２を実行させるプロトコルメッセージの受信は状態の遷移をもたらさない。反対に、関数ＦＵＮＣ＃３の呼び出しはconnect_pending１４から接続状態１６への遷移をもたらす。connect_pending#２状態の拡張子を定義する更新モジュール４６によって、レイヤ１０がconnect_pending状態１４内にある場合に、拡張子４６はオリジナル状態メッセージ取扱関数に取って代わり、プロトコルメッセージを受信するように動作可能である。使用中に、取扱関数ＦＵＮＣ＃２に対応するプロトコルメッセージはリダイレクト関数ポインタ５０によって捕捉され、これはconnect_pending状態１４のオリジナル関数ポインタＦＵＮＣ＃２に対応する。

他方で、メッセージ取扱関数ＦＵＮＣ＃３に対応するプロトコルメッセージが受信されると、更新関数ユニットＦＵＮＣ＃３＿１（図３３の参照番号５２）はメッセージを捕捉し、モジュール４６内の新たなメッセージ処理コードを実行させる。このように、元々提供されている状態で定義されている機能性が強化されることが可能である。そして、関数ポインタＦＵＮ-Ｃ＃３＿１を介する更新コードの実行は、connect_pending状態１４から接続状態１６への状態の遷移をもたらす。

状態の遷移は、上記の共通の共有構成データによって達成される。構成データは（任意のプロトコルレイヤ特徴の構成を定義するパラメータに加えて）、プロトコルレイヤ状態マシンインスタンスの状態ごとのメッセージ取扱関数に対応するエントリを有する関数ポインタテーブルを保持している。新たなレイヤインスタンスが作成される場合、構成データはバインドメッセージのレイヤインスタンスに送られるべきである。従って、モジュール（例えばモジュール４６）に送られた構成データが既存のレイヤ２のインスタンスの構成データに基づいている場合、（バインドハンドラ関数の）モジュールは（必要ならば）エントリを、新たなモジュールが取り扱うメッセージに対応する関数取扱ポインタ情報に重畳及び付加することができる。この場合、ＦＵＮＣ＃１＿１及びＦＵＮＣ＃３＿１は既存のＦＵＮＣ＃１及びＦＵＮＣ＃３にそれぞれ重畳する。しかし、エントリは削除不可能である。以下の表はこのような関数ポインタテーブルの例を示している。

構成データはまた、テーブルにおいて実行する信号取扱関数を決定するのに使用されるＣｕｒｒｅｎｔＳｔａｔｅポインタを保持している。信号取扱関数自体を実現するコードは、それぞれ、上記のオペレーティングシステム及び仮想オペレーティングシステムの使用のおかげでプログラミング言語及びオペレーティングシステムとは無関係である。

オペレーティングシステム（又は仮想オペレーティングシステム）のテーブルコンセプトを使用する再構成可能な状態マシンの実現を達成するためには２つの主要な方法がある。１つはスレッド／レイヤインスタンスアプローチであり、全着信メッセージに対処する論理レイヤインスタンスごとの実行スレッドがあるとする。そしてスレッドは、（例えばＶＯＳ関数コールget_message_typeを介して得られるような）メッセージタイプに対応する、対応するメッセージ取扱関数を呼び出す。そしてレイヤインスタンスに対応するテーブルを使用して、（CurrentState属性から得られるような）現在の状態についての対応する関数を実行可能である。状態変更は、次の状態名（つまり、属性を変更後に現在の状態になる状態）に対応する構成データテーブルから得られたポインタレファレンスにCurrentState属性を変更するための適切な関数を呼び出すことによって簡単に達成される。

第２のアプローチは、メッセージ取扱関数ごとに論理スレッドを有することである。これは必ずしも真のオペレーティングシステムスレッドに対応するわけではないが、（ＶＯＳ実現が用いられていれば）ＶＯＳスレッドである可能性がある。状態遷移が開始されるたびに、ＶＯＳ関数chnage_state（new_state_name）を呼び出すことによって、change_state関数は、論理レイヤインスタンスに対応する構成データテーブルにおけるメッセージ取扱関数についての新たなＶＯＳスレッドを開始する。メッセージ取扱関数が実行する第１の動作は、特定のメッセージタイプについてのVOS receive_message関数である。このように、ＶＯＳは必要なメッセージのみをメッセージ取扱関数に転送する。このアプローチはまた、もはや現在の状態に対応していないメッセージ取扱スレッドが終了又は停止されることを必要とする。

図３４は、作業メモリ３６において、プロトコルスタックのレイヤ２と関連した動作についてモジュール強化ユニット４８を検索する通信ユニット２０を示している。モジュール強化ユニット４８を内蔵するプロトコルスタックの動作について、図３５を参照して次に説明する。

図３５は、更新切断状態disconnected#２ ５４と、更新connect_pending状態connect_pending＃２ ５６と、２つのモード（又はネットワーク）を同時に使用するハイブリッドネットワークシステムについて第２の接続を確立するのに使用される新たなsubs_connect_pending状態５８と、subs_connected_pending状態５８によって提供されている追加のシステム機能性の導入に関して既存の接続状態１６の機能性を高めるのに使用されるconnected＃２状態モジュール５９と、を備えるものとしてモジュール強化ユニット４８を示している。

disconnected＃２状態は、強化connect_REQ関数にポインティングする関数ポインタＦＵＮＣ＃１＿１を含んでおり、connect_pending＃２状態拡張子５６は、元々実現されているconnect_pending状態のオリジナル関数ポインタＦＵＮＣ＃２に対応するリダイレクト関数ポインタ６２と、元々実現されているconnect_pending状態４０におけるオリジナル関数ポインタＦＵＮＣ＃３の代わりにメッセージを捕捉する強化関数ＦＵＮＣ＃３＿１（図３５の参照番号６４）へのポインタとを含んでいる。

さらに、subs_connect_pending条件を記述する新たな状態モジュール５８は、使用中に、connected#２状態強化において定義されているような第１の接続と関連して使用される第２のネットワークへの次の接続の起動が、新たな関数ＦＵＮＣ＃７に含まれているロード共有機能性を実現できる関数ＦＵＮＣ＃６へのポインタ６６を含む。

新たなconnected#２状態モジュール５９は、既存の関数ＦＵＮＣ＃４及びＦＵＮＣ＃５へのメッセージ対処ポインタ６７、６８と、新たなロード共有関数ＦＵＮＣ＃７へのメッセージ取扱ポインタ６９とを含む。

新たに導入された関数ポインタ６０、６４、６６及び６９は、レイヤ内の別の状態への修正された遷移を備える。関数ＦＵＮＣ＃１＿１は、connect_pending#２を定義する際に、更新状態５４のdisconnected#２からアップグレードされた状態５６への遷移に対する状態を提供する。新たな関数ポインタＦＵＮＣ＃３＿１は、connect_pending状態１４におけるＦＵＮＣ＃３によって既に占められている状態遷移を接続状態１６に継承する。さらに、新たな状態subs_connect_pending５８は関数ポインタＦＵＮＣ＃６を有しており、これは接続状態１６にも状態遷移を提供し、またＦＵＮＣ＃７はdata_transferメッセージを取り扱い、２つのネットワーク接続間の動的ロード共有を可能にする機能性を内蔵している。これらの状態遷移は図３６に示されている。

モジュール４８に提供されている強化機能性は、汎用関数ポインタテーブル（マッピングオブジェクト）をサポートするというＶＯＳコンセプトを使用することによって、オリジナルの機能性とは異なる実行環境（例えば、異なるＪＶＭ又はオペレーティングシステム環境）において実行可能である。また同様に、強化モジュールで使用されているプログラミング言語はオリジナルコードと異なっていてもよい。

当業者は、上記の装置及び方法は、例えばディスク、ＣＤ又はＤＶＤ−ＲＯＭ、ＲＯＭ（ファームウェア）などのプログラムメモリなどのキャリア媒体上、あるいは光学又は電気信号キャリアなどのデータキャリア上でプロセッサコントロールコードとして具現化されてもよいことはいうまでもない。多数のアプリケーションについて、本発明の実施形態はＤＳＰ（ディジタル信号プロセッサ）、ＡＳＩＣ（アプリケーション特定用途向け集積回路）又はＦＰＧＡ（フィールドプログラマブルゲートアレイ）上で実現される。従って、コードは従来のプログラムコードやマイクロコード、あるいは例えばＡＳＩＣやＦＰＧＡをセットアップ又はコントロールするためのコードを備えていてもよい。コードはまたリプログラマブル論理ゲートアレイなどの再設定可能装置を動的に構成するためのコードを備えていてもよい。同様に、コードはＶｅｒｉｌｏｇ（商標）やＶＨＤＬ（超高速集積回路ハードウェア記述言語）などのハードウェア記述言語のコードを備えていてもよい。当業者は理解するように、コードは相互に通信している複数の結合されたコンポーネント間に分配されてもよい。適切ならば、実施形態はまた、アナログハードウェアを構成するためにフィールド（リ）プログラマブルアナログアレイや類似のデバイス上で稼動するコードを使用して実現可能である。

当業者はまた、種々の実施形態及び、これらに関して説明されている具体的な特徴は、上記の教示に一般的に従って、他の実施形態又はこれの具体的に説明されている特徴と自由に組み合わせ可能である点を理解するであろう。当業者はまた、種々の変更及び修正が、添付の請求項の範囲を逸脱することなく、説明されている具体例に対して成されてもよいことを理解するであろう。

上記の例示的な背景例の通信プロトコルスタックを示す図である。 上記の図１の通信スタックの概念レイヤを示す図である。 上記の動的に再構成可能な通信プロトコルスタックを実現するための既知のアーキテクチャを示す図である。 上記の例示的な背景例に従って動的に再構成可能なプロトコルスタックのアーキテクチャを示す図である。 上記のバインドメッセージを示す図である。 上記の関数ポインタテーブルを示す図である。 上記のプロトコルメッセージを示す図である。 上記のレイヤソフトウェア及びオペレーティングシステム固有のマッピングオブジェクトの複数の例を示す図である。 上記のレイヤソフトウェア及びオペレーティングシステム固有のマッピングオブジェクトの複数の例を示す図である。 上記のレイヤソフトウェア及びオペレーティングシステム固有のマッピングオブジェクトの複数の例を示す図である。 上記のレイヤソフトウェア及びオペレーティングシステム固有のマッピングオブジェクトの複数の例を示す図である。 上記の例示的な例に従ったレイヤの複数のインスタンス作成を示す図である。 上記の例示的な例に従った、プロトコルスタックにおけるソフトウェアレイヤのインスタンス作成及びバインドを示す図である。 上記の例示的な例を示すブロックコードを示す図である。 上記の例示的な例に従った仮想オペレーティングシステムを示す図である。 上記のＣコードについて、既知の動的リンク付け方法を示す図である。 上記のＣコードについて、オペレーティングシステム関数テーブルパス方法を示す図である。 上記のＪａｖａコードについて、既知の動的リンク付け方法を示す図である。 上記のＪａｖａコードについて、オペレーティングシステム関数テーブルパス方法を示す図である。 上記のメッセージプロトコルスタックアーキテクチャごとの既知のスレッドを示す図である。 上記の図１０の例の概略メモリアーキテクチャを示す図である。 上記の例示的な例に従ったレイヤアーキテクチャごとのスレッドを示す図である。 上記の図２０の例の概略メモリアーキテクチャを示す図である。 上記の例における使用について高レベルのソースコードをモジュールにコンパイルするための方法を示す図である。 上記の例における使用について高レベルのソースコードをモジュールにコンパイルするための方法を示す図である。 Ｂｌｕｅｔｏｏｔｈ（商標）コンプレックスプロトコルスタックの例示的実現を示す図である。 上記の例示的な例のアップグレードされたＢｌｕｅｔｏｏｔｈ（商標）プロトコルスタックを示す図である。 状態ベースの機能性の上記説明のコンテクストにおいて、上記のプロトコルスタックのレイヤを示す図である。 図２８に示されているレイヤの関数ルックアップテーブルを示す図である。 図２８に示されているレイヤを含むレイヤベースのプロトコルスタックによって構成された通信デバイスの概略図である。 プロトコルスタックの更新はダウンロードに使用可能である、図３０の通信デバイスを含むシステムの概略図である。 プロトコルスタックのレイヤの第１のアップグレードを内蔵している、図３０に示されている通信デバイスの別の図である。 図３２に示されている通信デバイスを構成するプロトコルスタックのレイヤの第１のアップグレードされた状態モジュールを示す図である。 通信デバイスを構成するプロトコルスタックのレイヤの第２のアップグレードを含む、図３０に示されている通信デバイスを示す図である。 図３４に示されている通信デバイスに内蔵されている第２のアップグレードモジュール強化を示す図である。 図３５に示されているモジュール強化を含む、図２８に示されているレイヤの強化状態遷移図である。

Claims (20)

1. プロセッサ及びメモリを有する処理装置に設けられる、信号を処理するための通信プロトコルを修正するための方法であって、前記プロトコルは複数のプロトコルレイヤによって定義され、少なくとも１つのレイヤは各状態が他の状態のうちの１つへの前記レイヤのメッセージ依存性遷移を含む所定の機能性を有し、該レイヤと関連していた複数の所定の状態のうちの１つを使用時に占有できる、前記方法において、
   ソフトウェア更新モジュールをメモリにロードすることを含み、前記モジュールは前記レイヤのうちの１つの前記状態のうちの１つに対応する１つ以上のメッセージを受信し、処理するように配置され、前記モジュールは前記レイヤを別の状態に遷移させるように動作可能な少なくとも１つのメッセージ依存性遷移ユニットを備える、方法。
2. 前記モジュールは前記対応する状態を実現する前記所定の機能性を意図しているメッセージを傍受し、前記メッセージ依存性遷移ユニットに関係しない前記所定の機能性メッセージに移行するように動作できる、請求項１に記載の方法。
3. 前記更新モジュールはメッセージを受信し、処理し、且つ前記レイヤを他の状態に遷移させるように動作可能であり、前記メッセージは前記モジュールをロードする前に前記レイヤに遷移を生じさせるようには動作不可能である、請求項１または２に記載の方法。
4. 前記信号に対応するプロトコルメッセージと他のモジュールとを交換する前記更新モジュールを構成することであって、前記他のモジュールは、前記他のレイヤに対応する１セットの汎用関数に従って前記信号を処理するように構成されていることを含む、請求項１乃至請求項３のいずれか１項に記載の方法。
5. 前記他のソフトウェアモジュールを前記メモリにロードすることであって、前記他のモジュールは関数マッピングオブジェクトにおける前記汎用関数に対応する汎用関数ポインタを備えること、
   他のモジュールごとに前記関数マッピングオブジェクトを前記メモリにロードすることであって、前記オブジェクトは、前記汎用関数を１つ以上の装置特定関数にマッピングするために、前記汎用関数に対応する装置特定関数ポインタを備えること、
   受信信号を前記プロトコルレイヤに従って処理するために前記マッピングされた装置特定関数に従って前記他のモジュールを実行することをさらに含む、請求項１乃至請求項４のいずれか１項に記載の方法。
6. 第２のソフトウェアモジュールを前記メモリにロードすることであって、前記第２のモジュールは前記第２のレイヤに対応する１セットの汎用関数に従って前記信号を受信し、処理するように構成されており、前記第２のモジュールは第２の関数マッピングオブジェクトにおける前記汎用関数に対応する汎用関数ポインタを備えること、
   前記第２の関数マッピングオブジェクトを前記メモリにロードすることであって、前記オブジェクトは、前記汎用関数を１つ以上の第２の装置特定関数にマッピングするために前記汎用関数に対応する第２の装置特定関数ポインタを備えること、
   前記プロトコルレイヤに従って受信信号を処理するために前記マッピングされた第２の装置特定関数に従って前記第２のモジュールを実行して、前記第１及び第２のモジュールは異なる実行または装置固有の環境において実行されることをさらに含む、請求項１乃至請求項５のいずれか１項に記載の方法。
7. 前記更新モジュールは言語独立型である、請求項１乃至請求項６のいずれか１項に記載の方法。
8. 前記レイヤに対応する前記１セットの汎用関数に従って前記信号を処理するための高レベルソフトウェア言語コードを提供すること、
   前記言語独立型ソフトウェアモジュールに前記コードをコンパイルすることを含む、請求項１乃至請求項７のいずれか１項に記載の方法。
9. 請求項１乃至請求項８のいずれか１項に記載の方法を実行するための処理装置をコントロールするためのプログラム。
10. 構成可能な装置にロードされている場合に、前記構成可能な装置に請求項１乃至請求項９のいずれか１項に記載の方法を実行させるためのプログラムを実行可能なデータを有する記憶媒体。
11. 構成可能な装置にロードされている場合に、前記構成可能な装置に請求項１乃至請求項１０のいずれか１項に記載の方法を実行させるためのプログラムを実行可能なデータを有する信号。
12. プロセッサ及びメモリを有する処理装置に設けられる、信号を処理するための通信プロトコルを修正するための装置であって、前記プロトコルは複数のプロトコルレイヤによって定義され、少なくとも１つのレイヤは各状態が他の状態のうちの１つへの前記レイヤのメッセージ依存性遷移を含む所定の機能性を有し、該レイヤと関連していた複数の所定の状態のうちの１つを使用時に占有できる、前記装置において、
    ソフトウェア更新モジュールをメモリにロードすることを含み、前記モジュールは前記レイヤのうちの１つの前記状態のうちの１つに対応する１つ以上のメッセージを受信し、処理するように配置され、前記モジュールは前記レイヤを別の状態に遷移させるように動作可能な少なくとも１つのメッセージ依存性遷移ユニットを備える、装置。
13. 前記更新モジュールは、更新された機能性を与える前記状態の前記所定の機能性から言語独立方法で機能するように動作可能である、請求項１２に記載の装置。
14. 前記更新モジュールは、このモジュールにロードされているレイヤが少なくとも１つの追加状態を占有できるようにする装置を構成するように動作可能であり、またさらに、前記少なくとも１つの追加状態への、及びからのメッセージ依存性遷移を含む前記少なくとも１つの追加状態と所定の機能性を関連付ける前記装置を構成するように動作可能である、請求項１２又は請求項１３に記載の装置。
15. 請求項１２に記載の装置として構成された構造化可能装置。
16. プロセッサ及びメモリを有する処理装置に設けられる、信号を処理するための通信プロトコルを修正するための更新モジュールであって、前記プロトコルは複数のプロトコルレイヤによって定義され、少なくとも１つのレイヤは各状態が他の状態のうちの１つへの前記レイヤのメッセージ依存性遷移を含む所定の機能性を有し、該レイヤと関連していた複数の所定の状態のうちの１つを使用時に占有できる、前記更新モジュールにおいて、
    前記更新モジュールは前記レイヤのうちの１つの前記状態のうちの１つに対応する１つ以上のメッセージを受信し、処理するように前記装置におけるメモリにロード可能であり、前記更新モジュールは前記レイヤを別の状態に遷移させるように動作可能な少なくとも１つのメッセージ依存性遷移ユニットを備える、更新モジュール。
17. 前記更新モジュールは、更新された機能性を与える前記状態の前記所定の機能性から言語独立機能するように動作可能である、請求項１６に記載の更新モジュール。
18. 前記更新モジュールは、このモジュールにロードされているレイヤが少なくとも１つの追加状態を占有できるようにする装置を構成するように動作可能であり、またさらに、前記少なくとも１つの追加状態への、及びからのメッセージ依存性遷移を含む前記少なくとも１つの追加状態と所定の機能性を関連付ける前記装置を構成するように動作可能である、請求項１６又は請求項１７に記載のモジュール。
19. 請求項１６乃至請求項１８のいずれか１項に記載の更新モジュールが、プロセッサ手段及びメモリを含む処理装置のメモリにロードされるようにするプロセッサ読み取り可能な命令を記憶する記憶媒体。
20. 請求項１６乃至請求項１８のいずれか１項に記載の更新モジュールが、プロセッサ手段及びメモリを含む処理装置のメモリにロードされるようにするプロセッサ読み取り可能な命令を有する信号。

Images