JP2006519518A - 柔軟なプロトコル・スタック - Google Patents

柔軟なプロトコル・スタック Download PDF

Info

Publication number
JP2006519518A
JP2006519518A JP2005518549A JP2005518549A JP2006519518A JP 2006519518 A JP2006519518 A JP 2006519518A JP 2005518549 A JP2005518549 A JP 2005518549A JP 2005518549 A JP2005518549 A JP 2005518549A JP 2006519518 A JP2006519518 A JP 2006519518A
Authority
JP
Japan
Prior art keywords
function
module
protocol
general
device specific
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.)
Pending
Application number
JP2005518549A
Other languages
English (en)
Inventor
ファーナム、ティモシー・デビッド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Publication of JP2006519518A publication Critical patent/JP2006519518A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/03—Protocol definition or specification 
    • 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
    • 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/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • 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/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Stored Programmes (AREA)

Abstract

本発明は特に、しかしそれに限らず、携帯電話、ラップトップ・コンピュータ、及び基地局といった通信端末のためのプロトコル・スタック及びプロトコル・スタック内のプロトコル層に関係する。本発明はプロセッサ及びメモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法を提供し、プロトコルは複数のプロトコル層によって定義され、その方法はソフトウェア・モジュールをメモリに搭載し、そのモジュールは前記層の一つに対応する一組の一般的機能に従って信号を受信し、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、機能写像オブジェクトをメモリに搭載し、そのオブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行することを含む。

Description

本発明は特に、しかしそれに限らないが、携帯電話、ラップトップ・コンピュータ、及び基地局といった通信端末のためのプロトコル・スタック及びプロトコル・スタック内のプロトコル層に関係する。
携帯電話、ラップトップ・コンピュータ及び基地局といった通信デバイスは、(潜在的に同時に) 潜在的に異なる任意の機能に対応する多数の無線アクセス網規格に対応可能にするために、異なる構成を持つ多数のプロトコル・スタックにますます対応する必要がある。例えば、ラップトップ・コンピュータは無線構内通信網（wireless local area network）、ＧＳＭまたはＵＭＴＳ、及びブルートゥース（Bluetooth）上で安全及び不安全な双方のインターネット・アクセスに対応する必要がある。回線層（link layer）における暗号化に加えてＩＰプロトコル・スタック内のＶＰＮ機能の一部として提供される安全性は、プロトコル・スタック内の異なるオプションとして提供される。しかしながら、暗号化されないパケットは他の不安全な（もしくは、あまり安全でない）スタックに送られないことが重要である。従って、これらの異なる通信規格に対応するプロトコル・スタックは安全な枠組で提供される必要がある。理想的には、これらのプロトコル・スタックは新しいプロトコル・ソフトウェア・モジュールをダウンロードすることによって、新しい通信規格またはオプション及び現行規格への拡張に対応可能にするように再構成可能でなければならない。さらに、通信デバイスは乏しい電池及び無線周波数資源を使用できることがますます必要である。
従って、より一層の安全性、性能、電力消費最適化といった追加の機能性を含め、新しい空中インタフェース技術及びオプション機能及びそれらの技術への拡張を可能にする通信ソフトウェアをインストールすることができる必要性がある。
プロトコル・スタックの再構成は層間のインタフェースが動的に変わることなく、且つ旨く定義されるように実行されるプロトコル・スタック・ソフトウェアのモジュール化を必要とする。プロトコル・スタックと網インタフェース・ドライバ・ソフトウェアの枠組は、プロトコル（或いは、ドライバ）モジュールがこれらのインタフェース定義の正しい版に適合し、その後、システムへモジュールをインストールするために実行環境（オペレーティング・システム）特定機構を利用することを調べる多くのオペレーティング・システム上に存在する。ソフトウェアを有効とし、且つプロトコル・ソフトウェアによって実行できる機能に制限を行う対策がまた取られる。しかしながら、前述のように、これらの制限はプロトコル・スタック配列の状況を通常考慮せず、それは対応するサービスの形式によって安全性（実行環境）保護対策及び性能に対して異なる要求をもつことができる。また、これらの現行の方法はプロトコル・スタック配列を実施するために多数の実行環境の使用を考慮していない。
通常は、移動体通信デバイスのためのプロトコル・スタックは一つの供給元（a single vendor）によって提供される。将来において、端末デバイスは異なる通信技術に対応するためにより柔軟なプロトコル・スタックを必要とし、多くの供給元がプロトコル・スタック解決に関連するようになる。これは多くのオプション機能によっていくつかの規格に対応する必要がある無線端末において特に重要である。従って、プロトコル・スタックのますます増加する更新を可能にすることは非常に魅力的である。
プロトコル・スタックはその各々が受信パケットまたはメッセージに対して（プロトコルに対応する）一連の所定のステップ を実行するソフトウェア処理と見なされ、或るプロトコル実施に関連する一組の層から成る。多数の論理プロトコル・スタックは多数のトラフィック・クラスまたは同じ基本形の網インタフェースに対応するように、例えば多数のスレッド（threads）を用いて、所定のシステムにおいてインスタンス化（instantiated）される。同じプロトコル・スタックの多数の論理インスタンスは、これら全ての論理プロトコル・スタック・インスタンスについて一つのソフトウェア（プロトコル・スタック構成）配列を用いることによってもともとは達成される。しかしながら、これは異なる安全性、及び異なる論理的インスタンスに関する実行環境最適化を提供する際に柔軟性を制限する。
必要な時宜を得て、そして使用されているプロトコル定義に従って全てのモジュールが旨く相互に関係する場合のみプロトコル・スタックの予想される振る舞いが達成される。大抵のプロトコルは通信の接続を設定且つ維持するために異なるデバイスに関するプロトコル間の相互関係に頼っているので、これはまた多数のデバイスに対するプロトコル・スタック実施に依存する。ソフトウェア層の動的な挿入交換または修正を可能にする柔軟なプロトコル・スタックは、プロトコル定義に従わないか、不正受信者にパケットを送信するか、パケットを駄目にするか、正しくない、または無効のパケットを形成するか、または意図的に傍受、または安全な接続へのアクセスを得るためにパケットを遮断または送るか、または単に引き延ばしておくか（そのままにして置くか）いずれかによって、プロトコル・スタックの全体の動作及び安全性に影響を及ぼす（悪意のある、またはまさに悪く振る舞う）不正ソフトウェアに常に無防備である。
不正行動の影響を最小にし、且つ邪魔なモジュールの検知及び除去を可能にするため、プロトコル・ソフトウェアの機能性を制限するオペレーティング・システム特定機構を使用することによって、この問題は現在のところ解決される。
WO０２／２８０５２はプログラム可能なプロトコル・スタック行動を定義するパラメータを使用する適応可能プロトコルを持つ無線網インタフェースを開示している。これは、限られた量の再構成が異なるパラメータを使用することによって起こることを可能にする。しかしながら、それは新しいプロトコル・ソフトウェア・モジュールまたは層の動的な挿入を許さない。起こり得る限られた量の再構成しかないので、プログラム可能なプロトコル・スタック行動を定義するパラメータを使用する適応可能プロトコルはより予測可能な行動を有する。それらはまた新しいプロトコル・ソフトウェア・モジュールの動的な挿入を可能にするプロトコル・スタックと同様な柔軟性を提供しない。
米国特許５７５１９７２号は網上で異なるプロトコルを使用してデータ転送経路を確立するために実行時間（ランタイム）の間コンピュータを動的に構成することを開示している。プロトコル・スタックの合成はオペレーティング・システム特定回線機構を使用することによって達成される。これは各プロトコル・スタック・モジュールが特定のオペレーティング・システム従属インタフェース定義に適合しなければならないという点で柔軟性を制限してきた。同じく、そのスタックが旨く動作するように層の間の相互関係が旨く定義されることを保証するために、限定された範囲のプロトコル・モジュールだけが利用可能である。
WO０１／８８７０７号はプロトコル・スタックの各層間の稼働（active）プログラミング・インタフェース層を使用する柔軟なプロトコル・スタック・アーキテクチャを開示しており、これがランタイムにおいて変化できるようにプロトコル層の上或いは下の間で柔軟な連結を提供する。しかしながら、これらの追加中間層はスタックの複雑さを増加し、混合した実行環境実施が必要とされればその性能を著しく低下せせることになる。同じく、ソフトウェア・モジュールの連結は実行環境及びプログラミング言語特定様式（Ｊａｖａ仮想マシン）において行われ、プロトコル・スタックの動的な再構成を可能にするＪａｖａにおける動的クラス負荷概念を利用するために最適化される。
一般に、一形態において、本発明は実行環境から取出される柔軟なプロトコル・スタック、及び／またはプロトコル・スタック・ソフトウェア層の間で相互に作用するプログラミング言語特定機能を提供し、このようにして異なるソフトウェア層が異なる実行環境において実行され、異なるプログラミング言語において書かれることを可能にする。これは層を通過することにより達成され、モジュールそのものがその後で異なるモジュール（プロトコル層）、またはモジュールとオペレーティング・システムとの間で直接に連結を行う必要なしに他のモジュールに送信できることを可能にするために、作業用メモリにおけるコード・モジュール、信号中の一組の実行環境機能ポインタとして、もしくはモジュール入力点機能パラメータとして実施される。これはオペレーティング・システムが各モジュールのフォーマットを「知る」のとは対照的であり、それは次に連結ができるモジュールについて非常に特定のフォーマットを必要とする。このように、その層は「言語に無関係（language independent）」であり、実行環境機能ポインタによって提供される共通のオペレーティング・システム機能ポインタを用いて相互に作用する。
仕様のために、用語「プロトコル・スタック層」または「ソフトウェア層」は作業メモリに搭載されたコード・ブロックまたはモジュールとして実装され、実行環境によって実行または「作動（run）」され、所定のステップの集合（プロトコルに対応する）に従って入来信号またはパケットを処理する機能的実体を示す。その層はこのプロトコルに従って処理された信号またはパケットを出力する。プロトコル・スタックにおける層の概念は当業者によってよく理解されており、その最良の例はこれに対応するそれらの役割に従って通信プロトコル・スタック中のソフトウェア層を定義するＯＳＩ規格によって与えられる。
モジュールは、作業メモリ、関連プロセッサ及びオペレーティング・システム（及びオプション的に仮想マシン環境）といった実行環境において編集（compiled）され、或いは実行可能なプログラム・コード（特にオブジェクトまたは実行コード）のブロックとして定義される。この仕様では、モジュールは一般的にプロトコル・スタックにおける機能性の層に対応する。このように、モジュールは一以上の所定のステップを実行し、もしくは対応する層に関連するプロトコルに従って入来信号について処理を行うであろう。
論理層インスタンス（Logical Layer Instance：ＬＬＩ）は、例えば信号スレッドに対応する層ソフトウェア（モジュール）の論理インスタンスである。同じ層ソフトウェアに対応する多数のＬＬＩは、例えば関連コード・モジュールを持つ多数のスレッドを用いて実施可能である。各ＬＬＩは本発明において別々に構成（及び最適化）される。
一実施例では、メモリ内の割当及びアクセス信号といった他のモジュールまたは層及びデータと相互に作用するために、モジュールがその時「create_new_LLI」といった機能を実行するために呼出すオペレーティング・システム機能のリスト、及び他のオペレーティング特定機能を機能ポインタは含む。
別の実施例では、仮想オペレーティング・システム機能リストが使用され、その各機能はいくつかの異なる実行環境（オペレーティング・システム）における対応する機能に写像する。このように、仮想オペレーティング・システムを使用することによって、機能リスト、ソフトウェア層及びモジュールは言語に無関係であると同様にオペレーティング・システムまたは実行環境にも無関係にできる。
特に、一つの形態では、本発明はいくつかのソフトウェア層を含む柔軟なプロトコル・スタックを提供し、各層はそのスタックが動的に構成可能である（そして、再び結合メッセージを用いて再構成可能である）ように相互に作用するどちらか他のスタックを決定するためランタイムに結合メッセージを受信するための結合メッセージ・ハンドラを含む。このように一つの層への結合命令はそれがその出力を渡すべき別の層を示す。前述の相互作用はプログラミング言語に無関係に、好しくは層間のインタフェースが前に行われたよりもあまり厳密でない方式で再定義できるように実行環境に無関係な方法で支援される。これは（例えば共通層インタフェース定義の更新を必要とせずに）層ソフトウェアの動的な更新及び多数の供給元によるプロトコル・スタックの提供の支援を行う。
いくつかの既知のアーキテクチャにおいて使用されるように、この配置は各プロトコル・スタック層の間の言語または実行環境特定中間インタフェース層の必要性を回避する。インタフェース層の制限はその機能呼出仕様（パラメータ受渡し機構）及びパラメータ構文が良く定義され、及び理解され、そして全てのソフトウェア・モジュールによって正しく実施されなければならないことである。これらの機構は一般にオペレーティング・システム及びプログラミング言語に依存しており、その上コンパイラに依存し、従って、異種の環境におけるそのような解の柔軟性を制限する。従って、本発明はまた異なる言語で書かれ、及び／または異種の処理環境において動作するソフトウェア層の使用を可能にする。
特に、別の形態では、プロセッサ及びメモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法が提供される；その方法は：メモリにソフトウェア・モジュールを搭載し、そのモジュールは層の一つに対応する一組の一般的機能に従って信号を受信し、且つ処理するために配置され、そのモジュールは機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含み、；機能写像オブジェクトをメモリに搭載し、オブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み；プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行することを含む。
好ましくは、モジュールは信号に対応するプロトコル・メッセージを他のモジュールと交換するように配置され、他のモジュールは他の層に対応する一組の一般的な機能に信号を処理するように配置される。
好ましくは、その方法はさらに他のソフトウェア・モジュールをメモリに搭載し、他のモジュールは機能写像オブジェクトにおける一般的機能に対応する一般的機能ポインタを含み；他の各モジュールについて、機能写像オブジェクトをメモリに搭載し、オブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み； プロトコル層に従って受信信号を処理するために写像された装置特定機能に従って他のモジュールを実行することを含む。
好ましくは、その方法はさらに別のモジュールに関する識別子を含む結合メッセージを受取るその、或いは各搭載ソフトウェア・モジュールを含み、第一のモジュールはプロトコル・メッセージを結合メッセージによって識別された他のモジュールと交換するように配置される。
好ましくは、モジュールはプロトコル・メッセージを処理するために異なる構成オプションを持っている。
好ましくは、結合メッセージはモジュールの実行においてどの構成オプションを実施するかを決定するための識別子を含む。
好ましくは、プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである。
好ましくは、その方法はさらに：第二のソフトウェア・モジュールをメモリに搭載し、第二のモジュールは第二の層に対応する一組の一般的機能に従って信号を受取り、且つ処理し、第二のモジュールは第二の機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含み；第二の機能写像オブジェクトをメモリに搭載し、オブジェクトは一般的機能を一以上の第二の装置特定機能に写像するため一般的機能に対応する装置特定機能ポインタを含み；プロトコル層に従って受信信号を処理するために写像された第二の装置特定機能に従って第二のモジュールを実行することを含み；そのように、第一及び第二のモジュールが異なる実行または装置特定環境において実行される。
好ましくは、モジュールは言語に無関係である。
好ましくは、その方法はさらに層に対応する一般的機能の集合に従って信号を処理するための高級（high-level）ソフトウェア言語コードを提供すること；及びコードを言語に無関係なソフトウェア・モジュールに編集することを含む。
好ましくは、その方法はさらにプロトコル層に従って受信信号を処理するため、且つモジュールの二つの論理インスタンスを提供するために第二の実行処理においてモジュールを実行することを含む。
好ましくは、その方法はさらに：第二の機能写像オブジェクトをメモリに搭載し、オブジェクトは一般的機能を一以上の第二の装置特定機能に写像するため一般的機能に対応する第二の装置特定機能ポインタを含み；及び第一の実行処理に加えて、プロトコル層に従って受信信号を処理するため、且つ二つのモジュールの論理インスタンスを提供するために写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行することを含み、そのように二つのモジュールの論理インスタンスは異なる機能写像オブジェクトに従って実行される。
好ましくは、二つの実行処理は異なる実行または装置特定環境において実行する。
好ましくは、その方法はさらに別のモジュールに関する識別子を含む第二の結合メッセージを受取る搭載ソフトウェア・モジュールの第二のインスタンスを含み、第一のモジュールの第二のインスタンスはプロトコル・メッセージを第二の結合メッセージによって識別された他のモジュールと交換するように配置される。
好ましくは、モジュールはプロトコル・メッセージを処理するために各インスタンスについて異なる構成オプションを持ち、そこでは各結合メッセージはそれぞれのモジュール・インスタンスの実行においてどの構成オプションを実行すべきかを決定するための識別子を含む。
好ましくは、その、または各モジュールは個別の実行処理において実行される。好ましくは、各実行処理はスレッドである。
好ましくは、プロトコル・メッセージの交換はモジュール実行処理からの個別の実行処理によるものである。
好ましくは、メッセージはメモリ中の永久メッセージ列から提示されて、取出される。
好ましくは、その方法はさらに：中間機能写像オブジェクトをメモリに搭載することを含み、オブジェクトは一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクト中の一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む。
好ましくは、プロトコルは通信プロトコル・スタック、及び好ましくは無線通信プロトコル・スタックである。
特に別の形態では、本発明はプロセッサ及びメモリを持つ処理装置において信号を処理するための動的再構成可能なプロトコル・スタックを提供する方法を提供し、プロトコルは複数のプロトコル層によって定義される；プロトコル・スタックは：各モジュールが一つの層に対応する一組の一般的機能に従って信号を受取り、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール；オブジェクトが一般的機能をそれぞれのモジュールにおける一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト；それぞれのプロトコル層に従って受信信号を処理するために写像された装置特定機能に従って実行されるモジュールを含む；その方法は：別のモジュールに関する識別子を含む結合メッセージを受信する各モジュールを含み、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールによって交換するように配置される。
好ましくは、その方法はさらに：更新ソフトウェア・モジュールをメモリに搭載し、そのモジュールは一つの層に対応する一組の一般的機能に従って信号を受取り、且つ処理し、そのモジュールは機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含み；機能写像オブジェクトをメモリに搭載し、そのオブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み；プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行することを含み；そのモジュールは別のモジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはそれぞれの結合メッセージによって識別された他のモジュールによってプロトコル・メッセージを交換するように配置される。
特に別の形態では、本発明はプロトコルに従って信号を処理する方法を提供し、プロトコルは複数のプロトコル層によって定義される；その方法は：一つの層に対応する一組の一般的機能に従って信号を受信し、且つ処理すること；一般的機能を装置特定機能に写像すること；プロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することを含む。
好ましくは、その方法はさらに：他の層に対応する一組の一般的機能に従って信号を受信し、且つ処理すること；一般的機能を装置特定機能に写像すること；他のプロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することを含む。
好ましくは、受信及び処理は一般的機能の順序がプロトコル・スタックに対応するように配列される。
好ましくは、その方法は信号を処理することによる一般的機能の順序を決定するために結合メッセージを受取ることを含む。
好ましくは、各層の一般的機能に基づく受信及び処理はソフトウェア・モジュールを実行することによって実施される。
好ましくは、その方法は一般的機能を中間機能へ写像すること、その後中間機能を装置特定機能へ写像することを含む。
別の形態では、本発明は信号を処理するための通信プロトコルを提供する装置を提供し、その装置はプロセッサ及びメモリを有し、プロトコルは複数のプロトコル層によって定義される；その装置は：モジュールが一つの層に対応する一組の一般的機能に従って信号を受取り、且つ処理し、そのモジュールは機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、ソフトウェア・モジュールをメモリに搭載するための手段；オブジェクトが一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、機能写像オブジェクトをメモリに搭載する手段；プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行する手段を具備する。
好ましくは、そのモジュールは他のモジュールを持つ信号に対応するプロトコル・メッセージを交換するように配置され、他のモジュールは他の層に対応する一組の一般的機能に従って信号を処理するように配置される。
好ましくは、その装置はさらに、他のモジュールが機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、他のソフトウェア・モジュールをメモリに搭載する手段；オブジェクトが一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、他の各モジュールが機能写像オブジェクトをメモリに搭載するための手段；プロトコル層に従って受信信号を処理するために写像された装置特定機能に従って他のモジュールを実行する手段を具備する。
好ましくは、その装置はさらに搭載されたその、または各ソフトウェア・モジュールに別のモジュールに関する識別子を含む結合メッセージを送る手段を具備し、第一のモジュールは結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換する。
好ましくは、そのモジュールはプロトコル・メッセージを処理するため異なる構成オプションを持つ。
好ましくは、結合メッセージはモジュールの実行において実装すべき構成オプションを決定するための識別子を含む。
好ましくは、プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである。
好ましくは、その装置はさらに：第二のモジュールが第二の層に対応する一組の一般的機能に従って信号を受取り、且つ処理し、第二のモジュールは第二の機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、第二のソフトウェア・モジュールをメモリに搭載する手段；オブジェクトが一般的機能を一以上の第二の装置特定機能に写像するため一般的機能に対応する第二の装置特定機能ポインタを含む、第二の機能写像オブジェクトをメモリに搭載する手段；プロトコル層に従って受信信号を処理するために写像された第二の装置特定機能に従って第二のモジュールを実行する手段を具備し；そのように、第一及び第二のモジュールが異なる実行または装置特定環境において実行される。
好ましくは、モジュールは言語に無関係である。
好ましくは、その装置はさらに層に対応する一般的機能の集合に従って信号を言語に無関係なソフトウェア・モジュールへ処理するための高級（high-level）ソフトウェア言語コードを編集する手段を具備する。
好ましくは、その装置はさらにプロトコル層に従って受信信号を処理するために、且つ二つのモジュールの論理インスタンスを提供するために写像された装置特定機能に従って第二の実行処理においてモジュールを実行する手段を具備する。
好ましくは、その装置はさらに：オブジェクトが一般的機能を一以上の第二の装置特定機能に写像するため一般的機能に対応する第二の装置特定機能ポインタを含む、第二の機能写像オブジェクトをメモリに搭載する手段；及び第一の実行手段に加えて、プロトコル層に従って受信信号を処理するため、且つ二つのモジュールの論理インスタンスを提供するために、写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行する手段を具備し、そのように二つのモジュールの論理インスタンスは異なる機能写像オブジェクトに従って実行される。
好ましくは、二つの実行処理は異なる実行または装置特定環境において実行する。
好ましくは、その装置はさらに別のモジュールに関する識別子を含む第二の結合メッセージを受取る搭載ソフトウェア・モジュールの第二のインスタンスを含み、第一のモジュールの第二のインスタンスは第二の結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置される。
好ましくは、そのモジュールはプロトコル・メッセージを処理するための各インスタンスについて異なる構成オプションを持ち、そこでは結合メッセージはそれぞれのモジュール・インスタンスにおいて実装すべき構成オプションを決定するための識別子を含む。
好ましくは、その、または各モジュールは個別の実行処理おいて実行される。好ましくは、各実行手段はスレッドを含む。
好ましくは、その装置はさらに：中間機能写像オブジェクトをメモリに搭載する手段を具備し、そのオブジェクトは一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクトにおける一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ、及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む。
好ましくは、その装置は通信端末、基地局、または網デバイス、特に無線に関係するデバイスである。
特に別の形態では、本発明はプロセッサ及びメモリを持つ処理装置において信号を処理するための動的再構成可能なプロトコル・スタックに提供するための装置を提供し、プロトコルは複数のプロトコル層によって定義される；その装置は：各モジュールが一つの層に対応する一組の一般的機能に従って信号を受取り、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール；オブジェクトが一般的機能をそれぞれのモジュールにおける一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト；それぞれのプロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行する手段を具備する。
好ましくは、その装置はさらに別のモジュールに関する識別子を含む結合メッセージを各モジュールに送る手段を含み、受信モジュールはそれぞれの結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置される。
好ましくは、その装置はさらに：モジュールが一つの層に対応する一組の一般的機能に従って信号を受取り、且つ処理し、そのモジュールは機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含む、更新ソフトウェア・モジュールをメモリに搭載する手段；オブジェクトが一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、機能写像オブジェクトをメモリに搭載する手段；プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行する手段を具備し；そのモジュールは別のモジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはそれぞれの結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置される。
特に別の形態では、プロトコルに従って信号を処理するための装置が提供され、プロトコルは複数のプロトコル層によって定義される；装置は：一組の一般的機能に従って信号を受信し、且つ処理する手段；一般的機能を装置特定機能に写像する手段；プロトコル層に従って受信信号を処理するために、写像された装置特定機能を実行する手段を具備する。
好ましくは、その装置はさらに他方の層に対応する一組の一般的機能に従って信号を受信し、処理するように配置され；一般的機能を装置特定機能に写像する手段；他のプロトコル層に従って受信信号を処理するために、写像された装置特定機能を実行する手段を具備する。
好ましくは、受信及び処理は一般的機能の順序がプロトコル・スタックに対応するように配列される。好ましくは、装置はさらに信号をどちらで処理するかによって一般的機能の順序を決定するために結合メッセージを受信する手段を具備する。
好ましくは、各層の一般的機能に基づく受信及び処理はソフトウェア・モジュールを実行することによって実行される。
好ましくは、装置はさらに一般的機能を中間機能に写像し、それから中間機能を装置特定機能に写像する手段を具備する。
また、前述の定義された方法のどれでも実行する処理装置を制御するためコンピュータまたは処理装置プログラムが提供される。また、前述の定義されたすべての装置に従って構成された構成可能な装置が提供される。また、前述のいずれかの定義に従って方法或いは装置を実施するためのプロセッサ制御コードを担持する担体媒体が提供される。
また、前述の定義された方法及び装置を実行或いは実施するのに適当な前述の定義に基づくソフトウェア・モジュールが提供される。プロトコル層を実施し、且つオブジェクトを写像するモジュールは代りに他のデータ構造として実施される。
また、ソフトウェア・モジュールとして実施され、及び結合メッセージをプロトコル・スタックの層を実施するモジュールに送るように構成される構造マネージャ（configuration manager）が提供される。構造マネージャはまたモジュールを作業メモリに搭載し、それぞれの写像オブジェクトを搭載モジュールに渡すように構成される。
マネージャはまた修正されたプロトコル・スタックを実施するため新しい、または代替モジュールをダウンロードするように構成され、プロトコル・スタックは結合メッセージを新しい、或いは代替モジュール（代替モジュールが適当であれば）に渡すことによって再構成される。
また、構造マネージャと同様に、高級プログラム・コードをモジュール及び／または写像オブジェクトに編集するためコンパイラが提供される。
また、前述の定義された方法及び装置における使用のためにモジュールを伝送するための方法及び装置が提供される。前述の定義された方法及び装置における使用のため、及び対応するモジュールを生成するためコードを随意に編集するためにモジュールに対応するプログラム・コードを伝送るための方法及び装置が提供される。
特に別の形態では、いくつかのプロトコル・ソフトウェア層を含む柔軟なプロトコル・スタックが提供され、各層は、そのスタックがランタイムに動的に形成可能であるように、他のプロトコル・ソフトウェア層のどちらと相互に作用するかを決定するためにランタイムに結合メッセージを受取る手段を含む。
好ましくは、その相互作用は他の層からのプロトコル・メッセージを送信及び／または受信することを含む。
好ましくは、結合メッセージはプロトコル・メッセージがどこに送られるべきかをただ一つ識別する他の層に関連する識別子を含む。
好ましくは、結合及びプロトコル・メッセージは共通の一般的フォーマットである。
好ましくは、各層はさらに一般的機能、及びその層が実行される実行環境に対応する実行環境特定機能にその機能を写像する手段を含む。
好ましくは、その手段はランタイムにおいて結合メッセージ中のオペレーティング・システム表を受信することを含む。
好ましくは、その表は各一般的機能から対応する実行環境特定機能へのポインタを有する。
代わりに、その表は各一般的機能に対応する実行環境特定機能を有する。
好ましくは、その層の少なくとも二つは異なる実行環境において実行され、或いは異なるプログラミング言語で書かれる。
好ましくは、その層に関するその、または各実行環境は層ごとに標準オペレーティング・システムまたはカスタム・スレッドまたは実行処理を割当てるように配置される。
好ましくは、結合メッセージはまた層に関する構造情報を含む。
好ましくは、その層はその層のいくつかの論理層インスタンスの一つとして実施される。各論理層インスタンスは異なる実行環境においてただ一つ識別可能及び構成可能及び実行可能である。
また、前述の定義に従って一以上のプロトコル・スタックを含む通信装置が提供される。
好ましくは、プロトコル・スタックは無線通信回線及び網を提供する。
また、前述の定義に従ってプロトコル・スタックを実施する方法が提供される。
また、前述の定義に従ってプロトコル・スタックを実施する装置が提供される。
また、いくつかのプロトコル・ソフトウェア層を含む柔軟なプロトコル・スタックに関するプロトコル・ソフトウェア層が提供され、その層は、スタックがランタイムに動的に形成可能であるように、相互に作用すべき他のプロトコル・ソフトウェア層を決定するためランタイムに結合メッセージを受信する手段を含む。
特に別の形態では、いくつかのプロトコル・ソフトウェア層を含む柔軟なプロトコル・スタックが提供され、各層は一般的機能、及びその層が実行される実行環境に対応する実行環境特定機能にその機能を写像する手段を含む。
好ましくは、その写像手段はランタイムにオペレーティング・システム機能写像を含むメッセージを受信する手段を含む。
好ましくは、その写像は各一般的機能から対応する実行環境特定機能へのポインタまたは他の参照の手段を有する。
好ましくは、その写像は各一般的機能に対応する実行環境特定機能を有する。
好ましくは、その写像は各一般的機能から、実行環境特定機能を呼出すことを可能にする対応する仮想オペレーティング・システム写像へのポインタまたは他の参照の形式を有する。
代わりに、その写像は各一般的機能に対応する仮想オペレーティング・システム機能を持ち、各仮想オペレーティング・システムは実行環境特定機能に対応する。
好ましくは、そのスタックはさらに、そのスタックがランタイムに動的に構成可能であるように相互に作用する他のプロトコル・ソフトウェア層のどちらかを決定するためにランタイムに結合メッセージを受信する手段を含む。
好ましくは、その相互作用は他の層からプロトコル・メッセージを送信、及び／または受信することを含む。
好ましくは、結合メッセージは送信されるプロトコル・メッセージがどこにあるかを示す他の層と関連する識別子を含む。
好ましくは、結合及びプロトコル・メッセージは共通の一般的フォーマットである。
好ましくは、その層の少なくとも二つは異なる実行環境において実行され、及び／または異なるプログラミング言語で書かれる。
好ましくは、その層に関するその、もしくは各実行環境は層ごとに標準オペレーティング・システムまたはカスタム・スレッドまたは処理または実行を割当てるために配置される。
好ましくは、結合メッセージはまたその層に関する構造情報を含む。
好ましくは、その層はその層のいくつかの論理層インスタンスの一つとして実施される。各論理層インスタンスは異なる実行環境においてただ一つ識別可能及び構成可能及び実行可能である。
好ましくは、同じ層の異なる層インスタンスは異なる実行環境において実行される。
好ましくは、同じ層の異なる層インスタンスは異なって構成される。
また、前述の定義に従って一以上のプロトコル・スタックを含む通信装置が提供される。
好ましくは、プロトコル・スタックは無線通信回線または網を提供する。
また、前述の定義に従ってプロトコル・スタックを実行する方法が提供される。
また、前述の定義に従ってプロトコル・スタックを実行するための装置が提供される。
また、いくつかのプロトコル・ソフトウェア層を含む柔軟なプロトコル・スタックに関するプロトコル・ソフトウェア層が提供され、その層は一般的機能、及び層が実行される実行環境に対応する実行環境特定機能にその機能を写像するための手段を含む。
特に別の形態では、また、動的に構成可能なプロトコル・スタックに従って信号を処理するための装置が提供される；その装置は：プロトコル・スタックの層に従って信号に対応するパケットを処理するいくつかの処理手段；スタックの第一のプロトコル層に従って処理されたパケットをスタックの別のプロトコル層に従って処理する別の処理手段に渡すように配置された第一の処理手段；第一の処理手段が変化の間にパケットを処理し続けるように、パケットを渡すべき他の処理手段のどちらかを動的に変える手段を有する第一の処理手段を具備する。
好ましくは、その処理手段はプロセッサ及びメモリ手段によって提供される実行環境において実行されるソフトウェア・コードである。
好ましくは、動的に変えるための手段はパケットを渡すべき他のモジュールに対応する識別子を含む結合メッセージを受信するための手段を含み、識別子はスタックの第一のプロトコル層に従って処理されたパケットをスタックの別のプロトコル層に従って処理する別の処理手段に振り向けるために第一のモジュールによって使用される。
特に別の形態では、動的に構成可能なプロトコル・スタックに従って信号を処理するための装置が提供される；その装置は：各ソフトウェア・モジュールがそのプロトコル・スタックのプロトコル層に従って信号に対応するパケットを処理する使用において配置される、いくつかのプロトコル層ソフトウェア・モジュールを実行するためのプロセッサ及びメモリ手段；モジュールが一以上のプロトコル・モジュールを動かすように適応される、プロセッサ及びメモリ手段に関して構成された実行環境ソフトウェア・モジュール；プロセッサ及びメモリ手段を使用してプロトコル・モジュールを動かすために、実行環境モジュールにおいて命令（instruction）を写像するための写像識別子をランタイムに受信するように配置された第一のモジュールを具備する。
特に別の形態では、メモリを持つ処理装置において信号を処理するための再構成可能な通信プロトコルを提供する方法が提供され、プロトコルは複数のプロトコル層によって定義される；その方法は：ソフトウェア・モジュールをメモリに搭載し、そのモジュールはその層の一つに対応する一組の機能に従って信号を受信し、且つ処理するように配置され、そのモジュールはその層の別の一つに対応する別の組の機能に従って処理信号を受信し、且つ処理するように配置されるメモリ中の別のソフトウェア・モジュールに対応する目的モジュール識別子を受信し；第一のモジュールは処理された信号を識別子に対応する別のモジュールに送るように配置され；受信信号がモジュールによって処理され、且つ目的モジュール識別子に対応する別のモジュールに送られるように、最初のモジュールを実行することを含む。
これはプロトコル・スタックが中間層を必要しないでランタイムに動的に再構成が行えることを可能にする。
特に別の形態では、いくつかのプロトコル・ソフトウェア層を含む柔軟なプロトコル・スタックが提供され、各層は一般的機能、及びその層が実行される実行環境に対応する実行環境特定機能にその機能を写像する手段を含む。
特に別の形態では、メモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法が提供され、そのプロトコルは複数のプロトコル層によって定義される；その方法は：ソフトウェア・モジュールをメモリに搭載し、そのモジュールはその層の一つに対応する一組の一般的機能に従って信号を受信し、且つ処理するように配置され、そのモジュールは機能写像オブジェクト中に一般的機能に対応する一般的機能ポインタを含み；機能写像オブジェクトをメモリに搭載し、そのオブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み；プロトコル層に従って受信信号を処理するためにモジュールを実行することを含む。
信号フォーマットは拡張可能なテンプレート定義を使用して定義され、そして信号が生成され、そしてそれらのデータ要素は一般的機能をまた使用してアクセスされる。信号データ要素を生成し、且つアクセスするための一般的機能の振る舞いはランタイムに提供されるテンプレートによって決定される。従って、データ記憶機構及びフォーマットが特定の明細の判っている信号データを使用してソフトウェア・モジュールなしで特定の実行環境について最適化される。
これはプロトコル・スタックの層を実施するモジュールがプラットホーム及び／または言語に無関係であることを可能にする。
一般論として別の形態では、本発明はいくつかのプロトコル層を持つプロトコル・スタックを提供し、そのスタックは各ＬＬＩに関連する実行の一つの主オペレーティング・システム・スレッドがあるように配置される。
言換えれば、（処理された）パケットは一つのＬＬＩから別のＬＬＩに渡されるので、それは単に一つのスレッドから別のスレッドへの一般的にスレッド・メッセージ受渡しとして知られている方法によって転送される。これは、動的にプロトコル・スタック内の他のＬＬＩに影響を及ぼすことなくプロトコル・スタックにおけるもとの場所で一つの層を動的に更新、或いは置換することをより容易にする。ＬＬＩの間で渡されるメッセージはパケットの損失なしに実時間で動的な再構成を可能にするために永久記憶機構を用いて列に並べられる。
特に一つの形態では、信号を処理するためのプロトコル・スタックが提供され、そのスタックはいくつかのプロトコル・ソフトウェア層を含み、各層は別々の処理（例えば、スレッド）によって実行され、各層は処理に無関係なメッセージによって部分的に処理された信号を別の層に渡すように配置される。
各層の多数の論理層インスタンス（ＬＬＩ）は層を実行する多数の実行環境処理を提供することによって提供でき、各ＬＬＩは異なる構造オプションが可能、或いは持ち、そして異なる実行環境において随意に実行する。
好ましくは、各層はさらに一般的機能、及びその層が実行される実行環境に対応する実行環境特定機能にその機能を写像する手段を含む。
好ましくは、その手段はランタイムに結合メッセージ中のオペレーティング・システム表を受信することを含む。
好ましくは、その表は各一般的機能から対応する実行環境特定機能へのポインタを持つ。
好ましくは、その表は各一般的機能に対応する実行環境特定機能を持つ。
好ましくは、その層の少なくとも二つは異なる実行環境において実行され、もしくは異なるプログラミング言語で書かれる。
好ましくは、その層に関するその、或いは各実行環境は層ごとに標準オペレーティング・システムまたはカスタム・スレッドまたは実行処理を割当てるように配置される。
各層は層のいくつかの論理層インスタンスの一つとして実施される。各論理層インスタンスは異なる実行環境においてただ一つ識別可能及び構成可能及び実行可能である。
好ましくは、そのスタックはさらにそのスタックがランタイムに動的に構成可能であるように相互に作用する他のプロトコル・ソフトウェア層のどれかを決定するためにランタイムに結合メッセージを受信するための手段を含む。
好ましくは、その相互作用は他の層からプロトコル・メッセージを送信及び／または受信することを含む。
好ましくは、結合メッセージはプロトコル・メッセージがどこに送られるかを示す他の層に関連する識別子を含む。
好ましくは、結合及びプロトコル・メッセージは共通の一般的フォーマットである。
好ましくは、結合メッセージはまた層に関する構造情報を含む。
特に別の形態では、メモリを持つ処理装置において信号を処理する通信プロトコルを提供する方法が提供され、そのプロトコルはメモリ中のソフトウェア・モジュールに各々対応する複数のプロトコル層によって定義される；その方法は：各層について、その層に対応する一組の機能に従って信号を受信及び処理するように、且つ処理された信号を別のモジュールに送信するように配置されたソフトウェア・モジュールを搭載すること；処理された信号が処理に無関係な他のモジュールに送られる独立の処理（例えば、スレッド）として各モジュールを実行することを含む。
これは異なるモジュールが異なる実行環境においてより容易に動作することを可能し、モジュールを通してパケットのより良い流れを提供する。
一般論として別の形態では、本発明はいくつかのプロトコル層を持つ一以上のプロトコル・スタックを提供し、その層は、例えば異なるスレッドを使用して、別々の論理インスタンスとして何度もインスタンス化される。
多数のＬＬＩは、例えば暗号化が可能か否かに拘らず異なるオプションによって構成される。同じ層の多数のインスタンスはまた異なるオペレーティング・システム処理またはさらに異なるオペレーティング・システム内といった異なる実行環境において実行するように構成される。これは異なる層インスタンスが異なる安全性及び性能構成を持つ異なる実行環境において実行することを可能にすることによって特別な安全性または性能を提供する。
このように二つのプロトコル・スタック・インスタンスは同じソフトウェア・プロトコル層の異なるＬＬＩから成り、その各々はそれぞれのスタック内の上及び／または下でその層のＬＬＩと直接相互に作用する。
ＬＬＩ間の相互作用は対応するＬＬＩを支援する実行環境の中で容易に支援される方法を用いてプロトコル・メッセージを渡すこと、転送することを含む。使用される機構は異なるＬＬＩについて異なる。従って、共通の命名法及び一般的拡張メッセージ・データ・フォーマットが相互運用を保証するためにプロトコル及び制御メッセージについて必要とされる。
特に一つの形態では、構造オプションを持つ共通の層を含むいくつかのプロトコル層を各々含む一組の２プロトコル・スタックが提供され、共通の層は各スタックに関する論理層インスタンスとしてインスタンス化される；ここでは各インスタンスは異なる構造を有する。
好ましくは、各層はさらに一般的機能、及びその層が実行される実行環境に対応する実行環境特定機能にその機能を写像するための手段を含む。
好ましくは、その手段はランタイムに結合メッセージ中のオペレーティング・システム表を受信することを含む。
好ましくは、その表は各一般的機能から対応する実行環境特定機能へのポインタを有する。
好ましくは、その表は各一般的機能に対応する実行環境特定機能を有する。
好ましくは、その層の少なくとも二つは異なる実行環境において実行され、もしくは異なるプログラミング言語で書かれる。
好ましくは、その層に関するその、もしくは各実行環境は層ごとに標準オペレーティング・システムまたはカスタム・スレッドまたは実行の処理を割当てるように配置される。各層はその層のいくつかの論理層インスタンスの一つとして実施される。
各論理層インスタンスは異なる実行環境においてただ一つ識別可能及び構成可能及び実行可能である。
好ましくは、そのスタックはさらにそのスタックがランタイムに動的に構成可能であるように他のプロトコル・ソフトウェア層のどちらと相互に作用するかを決定するためランタイムに結合メッセージを受信する手段を含む。
好ましくは、その相互作用は他の層からプロトコル・メッセージを送信及び／または受信することを含む。
好ましくは、結合メッセージはプロトコル・メッセージがどこに送られるかを示す他の層に関連する識別子を含む。
好ましくは、結合及びプロトコル・メッセージは共通の一般的フォーマットである。
好ましくは、結合メッセージはまたその層に関する構造情報を含む。
特に別の形態では、メモリを持つ処理装置において信号を処理する通信プロトコルを提供する方法が提供され、そのプロトコルはメモリ中のソフトウェア・モジュールに各々対応する複数のプロトコル層によって定義される；その方法は：各層について、その層、構造オプションを持つ少なくとも一つのモジュールに従って信号を受信及び処理するように配置されたソフトウェア・モジュールを搭載すること；モジュールを実行するために二つの独立した実行処理を提供することによって構造オプションを持つモジュール二つの論理インスタンスを提供すること；モジュールに関する異なる構造オプションに対応する二つの構造オブジェクトを提供すること；二つの独立した実行処理を用いてモジュールを実行することを含み、各処理はモジュールの各論理インスタンスによって受信された信号が異なって処理されるように異なる構造オブジェクトを使用する。
これはコード・モジュールの二つの複製（各複製は異なるオプションに従って僅かに修正される）を作成しなければならないことを回避する。それはまた異なる性能及び安全対策が適用されることを可能にするためにスタックの異なるインスタンスが異なる実行環境において実行されることを可能にする。
一般論として別の形態では、本発明はモジュールとして実施されるいくつかのプロトコル層を含む動的に再構成可能なプロトコル・スタックと共に使用する構造マネージャを提供し、そのマネージャは他のモジュールのどちらと相互に作用するかをモジュールに指示するために結合メッセージをモジュールに送信する。
一般論として別の形態では、本発明は一般的機能ポインタを含むモジュールとして実施されるいくつかのプロトコル層を含む動的に再構成可能なプロトコル・スタックと共に使用する構造マネージャを提供し、そのマネージャは、一般的機能ポインタが関連する実行環境機能に対応するために、実行環境にモジュールを搭載し、且つ一組の実行環境機能を各モジュールと関連させるように配置される。
上で提供された発明の様々な形態は方法または装置として実施できる。本発明はまた適切なプラットホーム（プロセッサ及びメモリを含むハードウェア、及びオペレーティング・システムまたはプラットホーム中核部及びオプション的に仮想マシン環境）で実施されるとき、これらの方法及び装置の機能性を提供するモジュールといったプログラム・コードまたはソフトウェア・オブジェクトを提供する。このコードはオブジェクト、バイト・コードまたは実行可能なコード・ブロックまたはモジュールの形式、またはいくつか他のデータ構造形式である。そのコードはまたＣまたはＪａｖａといった高級言語で書かれたソース・コードの形式である。
本発明はまた高級プログラム・コードを発明の形態において実施に適したオブジェクト・コード・モジュールまたはデータ構造に変換することが可能なコンパイラを提供する。コンパイラは高級コードを本発明の実施例と共に使用に適したオブジェクト・コードに直接編集し、またはそれは高級コードを中間形式に編集する。この場合には、別のコンパイラが中間形式コードを本発明の実施例と共に使用に適したオブジェクト・コード・モジュールに変換するために提供される。
実施例は図を参照して、例のみによって、及び制限する意図無くここに記述されるであろう。
図１は当業者によく知られているであろう通信プロトコル・スタックを例示する。プロトコル・スタックは信号またはプロトコル・メッセージが処理されるいくつかのソフトウェアまたはプロトコル層Ｌ１〜Ｌ７から構成される。例えば、アプリケーション（Ｌ７）はＷｅｂブラウザまたはＧＳＭ音声呼出のための制御器であり、アプリケーション（Ｌ７）によって生成された信号及びメッセージは例えば電波（radiowaves）、銅線または光ケーブルといったある物理回線（physical link）を通して別のアプリケーションと通信するために下位層Ｌ１〜Ｌ６を通して下方に処理される。
図２は通信スタック層の一つの単純化された例を示す。如何に各層が機能するかの実際の詳細は使用される特定のプロトコルによって決まるであろう。その層は音声呼出またはｗｅｂページの一部といったパケットを受取る。その層は受取られたパケットに対して一連の所定のステップ（プロトコル）を実行するソフトウェア処理である。最初のステップはチェックサム計算を行い、もし必要ならばパケットを棄却し、その後パケット・ヘッダを取除き、そして別のステップはそのデータ・ペイロードを暗号の復号化を行う。さらなるステップにおいて、その層は修正されたより大きなパケットを上位層に渡す前にいくつかの受信パケットのデータ内容を累積する。この累積は不必要なメモリ複製化を回避するために共有バッファ（または、待ち行列）において行われることがある（及びしばしば行われる）。一般的に、通信層はまたより高レベルの層からより低レベルの層に反対方向にパケットを処理するであろう。原則として、二つの隣接層は他の層が何をしているか、及び如何にそれをするかを「知る」必要はない；しかし、実際には、層間のインタフェースは、データ（パケット） 内容の正確なフォーマット及び渡されるバッファ記憶配置、及び、例えばこのデータをどちらの層に渡すか、如何に渡されたデータを処理するこの層を開始するかを知って、如何にこれが達成されるかに関して定義される必要がある。既知の配置に関して上で述べられたように、これはスタックの柔軟性を制限する。
一般的に携帯電話等における従来の再構成可能でない通信プロトコル・スタックは製造時に設定され、作業メモリにおいて様々なソフトウェア層をインスタンス化することが必要なソフトウェア・コードは恐らくは電話の中のファームウェアとして固定され、且つ記憶される。このことは、層の一つが更新を必要とすれば、プロトコル・スタックは閉鎖され、全体のコード、または少なくとも更新された層コードは通信デバイスに書直され、その後、端末は再起動され（re-booted）、更新されたプロトコル・スタックは再インスタンス化される必要があることを意味する。これは通信デバイスに対するすべての稼働呼出も終結されること、そのデバイスは呼出についてオフラインが取られることを必要とする。この方法に関する別の問題は、いくつかの前述の引例において注目されたように異なる層は一般的にプロトコル・スタックを働かせるために非常に特別の方法で相互にインタフェースされることである。これは新しい、もしくは更新ソフトウェアの提供者（provider）は特定の実装及びプラットホームについて上と下の層とを相互に作用する方法を正確に前もって知る必要があることを意味する。さらに、これはスタックの柔軟性を制限する。
ランタイムのプロトコル・スタックの再構成を支援するために提案された他の方法は、プロトコル・ソフトウェアのダウンロードと、一時的にスタック実行を停止すること、及び実行環境及びプログラミング言語特定機構を使用して現存のスタックを新しいソフトウェアに関連づけることによって、現存プロトコル・スタックへのプロトコル・ソフトウェアの動的挿入を可能にする。これはさらに、他のスタック・ソフトウェアとインタフェースするもの、問題の層に特定の共有パケット・バッファ配置、及び言語及びオペレーティング・システム特定命令及びデータ・フォーマットを提供することに関してこれを行う方法を新しいソフトウェアの提供者が知るのと同時に、稼働通信セッションの一時的停止を必要とする。この方法はまた、ソフトウェアがおかしなふるまいをすれば、その問題が検知され、不正ソフトウェアが除去されるまで、それは多数の稼働通信セッションを中断させるかもしれないという危険性がある。また、論理インスタンスは汎用のインタフェース層には見えないので、新しいモジュールの挿入を許容する層間のインタフェースはプロトコル・ソフトウェアの異なる論理インスタンス間の相互作用を制限するように容易に更新されず、または個々に構成されないことがある。
その上、層が他の層とは異なるソフトウェア言語で書かれる将来の必要性がありそうである。例えば、物理層の近くの層は高速処理を必要とし、そのため高速実行のための高度に最適化されたハードウェア特定マシン語に前もって編集され（precompiled）、一方、スタックの上方の上位層はプラットホームに無関係であり、従って仮想マシン環境またはインタープリタ上で動作し、そのため非常に遅いがプラットホームに無関係にするのにより柔軟であり、従って第三者（third parties）が新しいアプリケーションを開発するのを奨励する。しかしながら、異なる言語を用いる二つの層は言語特定データ構造、命名法（命名分断法）及び機能呼出（パラメータ受渡し）法に関して既知の共通言語を利用できない。
現行の方法に関する別の問題は、各々の層が大抵は言語及びオペレーティング・システム（実行環境）特定の層の上或いは下の層間の相互作用に対応するインタフェース定義（共有バッファ配置を含む）によってきつく制約されているので、スタックを更新する能力を制限することである。将来、プロトコル・スタックの異なる層は、同じ言語（及びさらにいくつかの環境では同じコンパイラ）を使用するインタフェース及びそれらがインタフェースするために必要とする層に関するインタフェース機能、及び共有バッファ・フォーマットを提供しなければならない異なる供給元によって供給されるであろうという有り得る事象においてこの状況は悪化する。
動的に柔軟なＪａｖａプロトコル・スタックを提供することに対する一つの既知の方法は図３に例示され、各プロトコル・スタック層（Ｌ１〜Ｌ４）間のインタフェース層を利用する。これはＷＯ０１／８８７０７における開示に対応する。二つのプロトコル・スタック層の間で、その上或いは下の層によって「既知の（known）」インタフェース・フォーマットを持つインタフェースまたは中間層がインスタンス化される。インタフェース層はそれがどちらの高位プロトコル層とインタフェースすべきかを決定するために表を調べ、既知の（Ｊａｖａ）インタフェースを使用する。このように、図３に示した例では、更新されたプロトコル層Ｌ２′がインスタンス化され、インタフェース層Ｉ１はそれが層Ｌ１から来るパケットを層Ｌ２ではなく層Ｌ２′に送るべきであることを検索表から決定する。そして、層Ｌ２′はこれらをプロトコル・スタック層Ｌ３に送り直すインタフェース層Ｌ２にパケットを送る。このように、各プロトコル・スタック層（Ｌ１〜Ｌ４）間のこれらのインタフェース層（Ｉ１〜Ｉ３）及び検索表の使用によって、そのプロトコル・スタックは動的に再構成される。しかしながら、まだインタフェース及びプロトコル層間の回線がよく定義されるべきであるとの要請があり（それらの層は全てＪＶＭにあり、もしくは、そしてクラス搭載、継承、クラス生成及び破壊及びメソッド識別及び呼出仕様といったＪａｖａ言語の特徴を使用する）、正しいインタフェースを提供することが必要ならば変換（包含機能（wrapper functions））が行われる。また、インタフェース層は同期して隣接層の間の相互作用を支援するので、それはパケットを記憶するための共有バッファ配置を支援せず、異なる層間でメッセージを受渡しているとき過度のパケット・データ複製及びメモリ要求につながることがある。その上、この方法は一つの言語プロトコル・スタックについては適切であるが、異なる言語の層が様々な機能呼出しとして使用され、及びフォーマットされたデータが言語特定フォーマットとプロセッサ及びメモリ集約的な命名法との間で変換されなければならない点では、扱いにくい。
図４は実施例に従ってプロトコル・スタックを例示する。そのスタックはいくつかのプロトコル層（Ｌ１〜Ｌ４）を含み、それはそれらの間に信号パケットのようなプロトコル・メッセージを受渡す（図７）。一方、これらは低位層から高位層に進むことが示される；同じ原理がスタックを介して下方へ進行する信号も同様に適用されることは理解されるであろう。各層は結合メッセージを受取り（図５）、出力を向けるべき他の層のどれかを結合メッセージから決定する結合ハンドラを含む。
出力が向けられる次の層は唯一の識別子（bind ref.）によって示される。メッセージを層の間で受渡す好ましい方法は永久メッセージ列を使用するが、これが行われる方法、及び如何に実行が一つの層から他の層へ受渡されるか具体的な詳細は下記でさらに詳述されるようにプロトコル層ソフトウェアから取出される。
図５を参照すると、結合メッセージは例えばＬ２のような唯一のＬＬＩ名または識別子（instance.ref）を含む。同じ層について多数の論理層インスタンス（ＬＬＩ）が並行して（例えば、異なる呼出を処理する別のスタック・インスタンスにおいて）使用される場合、ＬＬＩ名は同じ層の他のインスタンス；例えば、Ｌ２１及びＬ２２と比較してその層インスタンスを唯一つ識別する；多数の層のインスタンス化は下記でさらに詳述する。
結合メッセージはまた言語特定機能表を含み、それはＪａｖａまたはＣ＋＋「プロトコル・スタック・オペレーティング・システム」クラスに動的にカプセル化され、或いはＣ構造、及び層ソフトウェアの中でそれらにアクセスするために使用される一組のラッパー機能に含まれるオペレーティング・システムのアプリケーション・プログラマー・インタフェース（Application Programmer Interface：ＡＰI）を表す。機能表は、新しいＬＬＩインスタンス生成（create_new_LLI）及びＬＬＩメッセージ通信（send_message. receive_message）といった基礎的なオペレーティング・システム機能の所定の集合を含む。提供された表は層（或いは、さらに層の多数のＬＬＩの一つ）が実行されるであろう実行環境によって決まるであろう。言い換えれば、それらの機能自身はオペレーティング・システムまたは仮想マシン（例えば、ＪＶＭ）環境に固有であり、しかしながら、それらは結合時に層（インスタンス）に渡されるので、これは、層（インスタンス）自身がオペレーティング・システム及び実行環境に無関係であり、適切な方法でそのスタック中の他の層と相互に作用するために機能を用いることを意味する。
代替配置では、結合メッセージは例えば共有メモリ中の表に記憶できる必要なオペレーティング・システム特定機能に対するポインタ（function.pointer ）を含む。
図６の例示では、層によって使用される所定の一般的機能（Func#l - Func#n）はオペレーティング・システム特定機能（op.sys.func1 - op.sys.funcn）に写像される。いくつかの典型的な機能の例、例えば、オペレーティング・システムが層のために実行する create_new_LLI が示される。
このように、他の層と相互動作することを可能にするが、それがオペレーティング・システム特定機能としてどちらのオペレーティング・システム環境において実行されるであるかを知らずに、結合時にそれに渡される一般的機能呼出（Func#1〜Func#n）を各層は含むであろう。これはまたコード・モジュールとして実施されるソフトウェア層からＬＬＩ間の相互作用を支援するために使用される特定形式の相互処理通信（メッセージ通信）、及び安全機構を取出すことができる。 唯一の要件は、層の供給元が適切な所定の一般的機能呼出-例えば、新しいＬＬＩを開始するFunc#1、メッセージを別のＬＬＩに送る Func#2、別のＬＬＩからメッセージを受取る Func#3 を使用しなければならないことである。同様に、二つのＬＬＩは同じ特定オペレーティング・システム機能を渡されるであろうから、その後それらは同じメッセージ通過機能を使用することによって相互にインタフェースすることができるであろう。
さらにこれを挙げると、二つのＬＬＩは異なるオペレーティング・システム特定機能を渡され、それによって下記でさらに詳述されるように仮想オペレーティング・システム機能表を使用して異なる実行環境において動作する。このように、それらの層はオペレーティング・システム及び言語に無関係である。必要なオペレーティング・システム特定機能は、結合／再結合時にそれらに渡される残りのスタックによって相互動作する必要がある。
同じ層の異なるインスタンスは、それらの結合メッセージにおいて異なるオペレーティング・システム特定機能を持つ異なる機能表を渡されることによって異なる環境において実行する。このように、一片のコード（モジュール）は、各ＬＬＩにおける一般的な send_message 及び receive_message 機能に写像されたオペレーティング・システム特定機能を単に持つことによって、他のコード（モジュール）のビットと異なって相互に作用することができる（例えば、他における一つの及び非同期メッセージ受渡しにおける機能呼出）。これは、一般的な send_message を対応するオペレーティング・システム特定機能に写像するために使用される表がＬＬＩごとの基準に基づいて行われるためである。しかしながら、ＬＬＩが別のＬＬＩと首尾よく通信することを欲すれば、両者は一般的なsend_message 及び receive_message からオペレーティング・システム機能への同じ写像を行う必要があり、そうでなければ、ＬＬＩが send_message を実行したとき受信ＬＬＩは何も受信しないであろう。
結合メッセージはまたその層のインスタンスを適切に層のその論理インスタンスに構成するために層インスタンス構造情報（config_1 から config_n へ）を含むことができる。例えば、異なる選択プロトコル機能を可動もしくは不能にする。
この一般的及び非層特定結合機構を使用することによって、各論理層インスタンスは別の結合メッセージをそのインスタンスへ送ることによって相互に作用する新しい論理層インスタンスに動的に（ランタイムに）向けることができる。これは新しい層の動的な挿入を含み、その上、層間の言語無関係な相互作用を可能にすることが理解できる。
図７を参照すると、プロトコル・メッセージはプロトコル・スタックを上下に信号またはパケット情報を通信するために層間で受渡される。各プロトコル・メッセージは送信層に関係する bind.ref 識別子に従って送信層（例えば、１層）から行先層（例えば、２層）へ向けられ、その結合メッセージ中のその送信層に対して提供されるであろう（図５参照）。プロトコル・メッセージは共有メモリ中に信号データまたは信号データを指示する信号ポインタを含むであろう。さら、信号データ（或いは、ポインタ）及び識別子（send.inst.ref 及び dest.inst.ref）は共通の一般的共有データ・フォーマットである。
プロトコル及び結合メッセージはプロトコル・スタック実体（様々なＬＬＩ）の間で受渡される信号であり、この信号受渡しは機能呼出またはスレッド・メッセージ通信機構といった異なる機構を用いて行われる。通常、スレッド・メッセージ通信は異なるオペレーティング・システム・スレッドの間であり、メッセージは配列上に置かれ、そしてオペレーティング・システムはその配列からメッセージを読取るために受信スレッドを起動する（計画する）。
一般的機能（例えば、send_message 及び receive_message）は、どのような方法がその特定の相互作用について目標プラットホームに適しているかにおいてメッセージ受渡しを可能にするために使用される。コード自身はどのような方法が使われるかを知る必要はない。しかしながら、send_message 機能を呼出すことは送られるメッセージが一般的フォーマットであり、所定の方法でその send_message 機能に渡されることを必要とする。それらのメッセージは send_message 機能の中で使用できるメッセージについて取扱い（或いは、参照）を生成する一般的な create_message 機能（また、オペレーティング・システム特定機能表の中で提供される）を使用することによって動的に造られ、且つ識別可能である。メッセージを send_message 機能に渡す好ましい方法は参照（reference）によってそれを受渡すことである（メッセージへのポインタは機能呼出において渡される）。これは発生するデータの複製量を最小にし、そうでなければメッセージ・データは堆積（或いは、共有）メモリからスタック・メモリに複製され、その後堆積或いは共有メモリを取消すことになる。好ましい方法は効率的であり、メッセージ・データの余計な複製を含まない。実際、メッセージ・データが堆積或いは共有メモリに常に保持されれば全ての複製は全く必要でなくなる。
このように、その層ソフトウェア（モジュール）は、それがそれに利用可能であるsend_message 及び create_message 機能の呼出法を知る必要があるので、それがメッセージを送っているソフトウェア層（モジュール）内で使用される言語、またはさらに呼出法の知識を全く必要としない。その上、受信ソフトウェア層（モジュール）だけは receive_message 機能について知る必要がある。その後、実際のメッセージ内容はアクセスされなければならず、共通の一般的共有データ記憶方法はこのデータにアクセスするために言語特定アクセス機能と共に使用される。同様に、結合メッセージまたはプロトコル・メッセージ（パケット）はプログラミング言語及び実行環境に関係なく各層によって一般的方法でアクセスできる。
データにアクセスするために使用される機能は結合メッセージ中のオペレーティング・システム特定機能の一部としてソフトウェア層（コード・モジュール）に渡される。メッセージ（或いは、信号）、構成及び共有データを異なるプログラミング言語によって効率的にアクセスすることができ、また更新を可能にするため、そのフォーマットは拡張可能でなければならない。例えば、拡張可能マークアップ言語（eXtensible Markup Language：ＸＭＬ）或いは他の（抽象構文表示法ＡＮＳ．１（Abstract Syntax Notation ASN.l）など）テンプレート定義はデータ・フォーマットを定義し、またデータ要素及びそれらの対応データ形式を識別する唯一の識別子を使うことによってランタイムに共有データ記憶構造にアクセスするために使用できる。そして、言語特定データ・アクセス機能は効率的に必要な要素を取出すことができる。これはプロトコル・ソフトウェアの異なるバージョンによる同じデータの使用を可能にする。古いバージョンは新しいデータ・メンバーへのアクセスを必要とせず、それらにアクセスしようと試みないであろう。旧いデータ・メンバーの知識の除去は新ソフトウェアバージョンにおいても可能であるが、データ・テンプレート定義は古いソフトウェア・モジュールバージョンに対応する旧いデータ・メンバーに関するプレースホルダーをまだ有しているであろう。データ・メンバー（全ての旧いデータ・メンバーを含む）を唯一つ同定する識別子はこれらのデータ・メンバーにアクセスするためにソフトウェア・モジュールの中で使用される。しかしながら、言語特定データ・アクセス機能によって提供された遠回しのやり方のために、実際のデータは共通の共有メモリ領域に全て記憶することができ、適切な安全対策 (例えば、読取り及び書込みロック機構を使用するデータ形式または要素レベル認可)は個々のＬＬＩによるデータへの未認可アクセスを防止する。
これらの機能は現存もしくは新しい要素技術の性能の開発を可能にするためにもっと複雑なインタフェース定義言語（Interface Definition Language：ＩＤＬ）体系の中でカプセル化される。言語特定ＩＤＬ定義はまた異なる言語（例えば、一組のＪａｖａクラス及びＪａｖａ層に関する要素インタフェース及びＣ＋＋層に関する一組のＣ＋＋インタフェース・クラス、等々）間で容易に写像できない複合データ形式の利用を可能にするであろう。特定のＩＤＬのＸＭＬまたはＡＳＮ．１テンプレートへの或いはそこからの写像は、この追加の要素インタフェース・ソフトウェアによって取扱われる必要があるであろう。共通の記憶構造を使用して多量の共有データに対するアクセス速度を向上させるために、それらの識別子は関連リスト（linked lists）に階層的に、もしくは所望の要素を設置するために必要な検索時間を最小にするためのデータ・アレイの中に連続して配置することができる。
プログラミング言語に無関係なデータ・テンプレート定義の例はそれぞれ拡張可能マークアップ言語 （ＸＭＬ）スキーマまたは抽象構文表記（ＡＳＮ）タグまたはデータ系列定義である。データ要素（或いは、属性）アクセス機能は下記の表に示されるように、アクセス特性を向上させるために、データ要素系列内の実際の項目にアクセスするために間接法（メモリ・ポインタ）を利用することができる。このように、データ要素の分解はテンプレートにおいて定義されたように検索操作、及び必要なデータ・フォーマットへの結果の鋳込みまたは変換になる。
Figure 2006519518
 ここで例ＡＳＮ‐１定義は：
Message ：：＝ SEQUENCE {
Message_Number INTEGER OPTIONAL,
Message Name STRING
}
である。
メッセージ・データにアクセスするために使用される一般的機能は、またプラットホームについて最適化されるデータ・アクセス機能の実際の実施を可能にするため、結合メッセージによって渡される一般的オペレーティング・システム表の中に含まれる。例えば、固有の識別子「１２４３」を持つデータ要素について、ソフトウェア層は一般的層機能 get_attribute ("1243") を呼出す。層ソフトウェアはＸＭＬ或いはＡＳＮ．１テンプレート・フォーマットにおいて定義された要素のデータ形式を知る必要がある。層ソフトウェアによって使用される構造データ及びメッセージに対応するテンプレートは形式変換を適切なものとして許容するために一般的 get_attribute 及び set_attribute 機能によって知られなければならない。従って、 get_attribute 及び set_attribute 機能はテンプレート定義への取扱い（参照）をパラメータとして取る。取扱い（或いは、参照）は一般的 load_template 機能によって生成される。一般的機能 get_attribute 及び set_attribute はまた構造データもしくはメッセージ取扱い（或いは、参照）を取り、特定のデータ要素についてメモリ・ポインタ参照を記憶し、且つその固有の識別子参照を記録することができるために検索表を保持するであろう。
別の選択肢は同じ実際のデータ要素を指示する二つの属性の識別子を持つことである。異なる識別子が実際に同じデータ要素に対応するが異なる変換形式を伴うとき、これはデータ重複を回避するのに魅力的であるかもしれない。例えば、データ要素識別子「１２４３」がデータ要素に対応すれば、それはテンプレート中で「メッセージ名」であるとして指定され、ゼロ終端のユニコード列である。属性識別子「１２４４」はまた同じ「メッセージ名」に対応しているが、異なるフォーマット、例えば２５５バイトＡＳＣＩＩ文字列に対応しているであろう。形式の変換は get_attribute 機能によってソフトウェア層から隠される。従って、Ｊａｖａソフトウェア・モジュールが get_attribute を呼出すならば、それは識別子「１２４３」を使用しており、ユニコード列を得るであろうし、Ｃ＋＋モジュールがデータ要素にアクセスすることを望めば、それは「１２４４」要素に関する get_attribute を呼出し、２５５バイトのＡＳＣＩＩ列を得るであろう。
好ましい実施例では、メッセージを送信、且つ受信しているＬＬＩに関係なくメッセージ・データ全てについて同じテンプレートが使用される。これはＬＬＩ内のプロトコル機能に無関係ないわゆる一般的サービス・アクセス点（Generic Service Access Point ：ＧＳＡＰ）を提供する。ＧＳＰについての可能な一般的なテンプレート定義例は下記に示される。
−− 一覧表及び形式定義（Enumeration and type definitions）
GPI_PRIMITIVETYPE : := ENUMERATED { GPIJBIND(1), GPI_REBIND(2), GPI_SUSPEND(3), GPI_RESUME(4), GPI_UNBIND(5), GPI_TERMINATE(6), GPI_UPGRADE(7), GPI_OPTIMISE(8), GPI_OK(9), GPI_ERR(10) };
−− 一般的ＭＡＣ層（for a Generic MAC Layer）
GPI_MACTYPE : := ENUMERATED { GPI_CSMACA(0), GPI_CSMACD(1), GPI_TPB(2), GPI_TPR(3), GPI_TDMA(4) };
GPI_CRCTYPE : := ENUMERATED { GPI_CRC32(0), GPI_CRC16(1), GPI_CRC24(2) };
GPI_ARQTYPE : := ENUMERATED { GPI_SAW(0) , GPI_GBN(1), GPI_SEL(2), GPI_NONE(3) };
GPI_HARQTYPE : := ENUMERATED { GPI_TYPE1(0) , GPI_TYPE2(1), GPI_NONE(2) };
GPI_HARQCODETYPE : := ENUMERATED { GPI_GOLAY(0), GPI_RS(1), GPI_NONE(2) };
GPI_CRYPTOTYPE : := ENUMERATED {GPI_RSA(0) ,GPI_DES (1) ,GPI_3DES (2) ,GPI_GEA3 (3), GPI_NONE(4) };
−− 結合原型（for Bind primitives）
GPI_QOSTYPE : := ENUMERATED {GPI_CO(0) , GPI_CL(1) };
−− 接続指向及び無接続（connection oriented and connectionless）
GPI_SECURITYLEVEL : := ENUMERATED { GPI_HIGH(0), GPI_MEDIUM(1), GPI_LOW(2) };
−− 一般的データ・パケット原型（for generic data packet primitive）
GPI_PACKETTYPE : := ENUMERATED { GPI_IP(0), GPI_ETHER(1), GPI_PPP(2) };
GPI_DIRECTION : := ENUMERATED { GPI_UP(0), GPI_DOWN(1) };
GPI_TFTYPE : := SEQUENCE {
−− 一般的伝送フォーマット形式の定義（Generic transport format type definitions）
GPI_MOD GPI_MODTYPE [変調形式（Modulation type）],
GPI_CODING GPI_CODINGTYPE [チャネル符号化形式（Channel coding type）],
GPI_BLOCKSIZE INTEGER [伝送ブロック・サイズ（バイト）（Transport block size in bytes）],
GPI_ ANTENNA INTEGER OPTIONAL [利用アンテナ指示（Indication of which antenna to utilise）]
}
−− 原型定義（Primitive definitions）
GPI_MANPRIMITIVE : := SEQUENCE {
−− 一般的ＧＰＩ管理原型（Generic GPI management primitives）
GPI_PRIMITIVE GPI_PRIMITIVETYPE [これは特定プロトコル・メッセージの原型である（This is the specific protocol message primitive type）],
−− プロトコル・モジュール無関係部分（Protocol module independent part）
GPI_REQUESTOR GPI_LL_IDENT [これは要求ＬＬＩである（This is the requesting LLI）],
−− 原型の形式に依存する選択部分 − 結合は付加情報を含む（Optional part depending on type of primitive −bind contains additional information）
GPI_BIND GPI_BINDPRIMITIVE OPTIONAL [ 結合、再結合、最適化（for bind, rebind, optimise）]
}
GPI BINDPRIMITIVE : := SEQUENCE {
GPI_UPPER_SAP STRING [これはＬＬＩの上のサービス・アクセス点名称である（This is the Service Access Point name above the LLI）],
GPI_UPPER_USER GPI_LL_IDENT [ これはＳＡＰを使用し、パケットが受信及び送信されるそのＬＬＩの唯一の識別子である（This is the unique identifier(s) of the LLI that use the SAP and to which packets are received and sent）],
GPI_LOWER_SAP STRING [これはＬＬＩの下のサービス・アクセス点名称である（This is the Service Access Point name below the LLI ）],
GPI_LOWER_USER GPI_LL_IDENT [これはＳＡＰを使用し、パケットが受信及び送信されるそのＬＬＩの唯一の識別子である（This is the unique identifier(s) of the LLI that use the SAP and to which packets are received and sent）],
GPI_GSAP GPI_GSAP_TABLE [これは安全な方法で言語無関係、性能最適化、ＧＳＡＰ境界を跨ぐ相互作用を可能にするためにＬＬＩに関する環境を設定する（仮想）オペレーティング・システムである（this is the (virtual) operating system table that sets the environment for the LLI in order to allow language independence, performance optimisation and interaction across the GSAP boundary in a secure manner ）],
−− 一般的方法においてＬＬＩを構成するＱｏＳ属性（QoS attributes to configure the LLI in a generic manner）
GPI_QOS GPI_QOSTYPE [ＬＬＩに関連するＱｏＳ（QoS associated with the LLI）],
GPI_RCV_THROUGH_TARGET INTEGER [秒当たりｋビットでの目標受信処理量（Target receive throughput in k bits per second）],
GPI_RCV_THROUGH_ACCEPT INTEGER [秒当たりｋビットでの許容可能受信処理量（Acceptable receive throughput in k bits per second）],
GPI_RCV_TRANSDELAY_TARGET INTEGER [目標受信待ち時間（ミリ秒）（Target receive latency in milliseconds）],
GPI_RCV_TRANSDELAY_ACCEPT INTEGER [許容可能受信待ち時間（ミリ秒）（ Acceptable receive latency in milliseconds）],
GPI_XMT_THROUGH_TARGET INTEGER [秒当たりｋビットでの目標伝送処理量（Target transmit throughput in k bits per second）],
GPI_XMT_THROUGH_ACCEPT INTEGER [秒当たりｋビットでの許容可能伝送処理量（Acceptable transmit throughput in k bits per second）],
GPI_XMT_TRANSDELAY_TARGET INTEGER [目標伝送待ち時間（ミリ秒）（Target transmit latency in milliseconds ）],
GPI_XMT_TRANSDELAY_ACCEPT INTEGER [許容可能伝送待ち時間（ミリ秒）（Acceptable transmit latency in milliseconds）],
GPI_PRIORITY_MIN INTEGER (0..100) [トラフィック・クラス／接続の最小優先権（Minimum priority of traffic class / connection）],
GPI_PROTECTION_MIN INTEGER [ GPI_NONE, GPI_MONITOR, GPI_MAXIMUM ],
GPI_PRIORITY_MAX INTEGER (0..100) [トラフィック・クラス／接続の最大優先権（Maximum priority of traffic class /. Connection）],
GPI_PROTECTION_MAX INTEGER [ GPI_NONE, GPI_MONITOR, GPI_MAXIMUM ] ,
GPI_RESILIENCE_DISC_PROB INTEGER (0..10000) [接続切断への回復（Resilience to disconnection）],
GPI_RESILIENCE_RESET_PROB INTEGER (0..10000) [接続再設定への回復（Resilience to connection reset）],
GPI_RESIDUAL_SUCCESS INTEGER (0.10000000) [ 誤り率の剰余成功率逆数（Residual success rate recipricol of error rate）],
−− 任意費用及び電力消費、資源利用及び安全性要件（Optional cost and power consumption, resource utilisation and security requirements）
GPI_RCV_COST_TARGET INTEGER OPTIONAL [現行単位での目標処理量における分当たりの目標受信費用（Target receive cost per minute at target throughput in currency units）],
GPI_RCV_COST_ACCEPT INTEGER OPTIONAL [分当たりの許容可能受信費用（Acceptable receive cost per minute）],
GPI_XMT_COST_TARGET INTEGER OPTIONAL [現行単位での目標処理量における分当たりの目標送信費用（Target transmit cost per minute at target throughput in currency units ）],
GPI_XMT_COST_ACCEPT INTEGER OPTIONAL [分当たりの許容可能受信費用（Acceptable transmit cost per minute）],
GPI_POWER_CONSUMPTION_TARGET INTEGER OPTIONAL (0..100) [目標最大電力消費（許容可能な電池寿命を達成するために許容される最大電力消費の％）（Target max power consumption as % of maximum power consumption permissible to achieve acceptable battery life）],
GPI_SECURITY GPI_SECURITYLEVEL OPTIONAL [必要な安全性レベル（Required security level）],
GPI_MEMORY_TARGET INTEGER (0..100) OPTIONAL [目標最大メモリ処理（全体の％）（Target max memory usage % of total）],
GPI_PROCESSOR_TARGET INTEGER (0..100) OPTIONAL [目標最大プロセッサ処理（全体の％）（Target max processor usage % of total）],
−− ＬＬＩ特定部分 − ここで使用される属性は主としてＬＬＩの形式による（LLI specific part − the attributes used here depend largely on the type of LLI）
GPI_MAC GPI_MACTYPE OPTIONAL [これはＭＡＣの形式を示す（This indicates the type of MAC）],
GPI_MAC_AIFS INTEGER OPTIONAL [時間スロットにおける調停フレーム間の間隔（Arbitration interframe separation in time slots）],
GPI_.MAC_SLOTTIME INTEGER OPTIONAL [ＣＳＭＡ及びＴＤＭＡに基づくＭＡＣに関するスロット時間（ミリ秒）（slot time for CSMA and TDMA based MAC in microseconds）],
GPI_MAC_FRAMESIZE INTEGER OPTIONAL [時間スロット中のフレーム・サイズ（frame size in time slots）],
GPI_MAC_BACKOFFWINDOW INTEGER OPTIONAL [時間スロット中の初期バックオフ・ウィンドウ・サイズ（initial backoff window size in time slots）],
GPI_HEADER_CRC GPI_CRCTYPE OPTIONAL [一般的ヘッダーＣＲＣに関する設定（Setting for Generic Header CRC）],
GPI_PAYLOAD_CRC GPI_CRCTYPE OPTIONAL [一般的ペイロードＣＲＣに関する設定（Setting for Generic Payload CRC）],
GPI_HEADER_CRC_GEN INTEGER OPTIONAL [ヘッダーＣＲＣに関する生成多項式（Generator polynomial for header CRC）],
GPI_PAYLOAD_CRC_GEN INTEGER OPTIONAL [ペイロードＣＲＣに関する生成多項式（Generator polynomial for payload CRC）],
GPI_ARQ GPI_ARQ_TYPE OPTIONAL [ＡＲＱに関する設定（Setting for ARQ）],
GPI_ARQ_BLOCKSIZE INTEGER OPTIONAL [再伝送ブロック・サイズ（バイト）（Retransmission block size in bytes）],
GPI_ARQ_WINDOWSIZE INTEGER OPTIONAL [ＧＢＮに関する再伝送ウィンドウ・サイズ（選択可能）（Retransmission window size for GBN and Selective）],
GPI_HARQ GPI_HARQTYPE OPTIONAL [ハイブリッドＡＲＱに関する設定（Setting for hybrid ARQ ）],
GPI_HARQ_CODE GPI_HARQCODETYPE OPTIONAL [ハイブリッドＡＲＱ符号化に関する設定（Setting for hybrid ARQ coding）],
−− 暗号化／暗号解読設定 − 一般的暗号化ＬＬＩについて使用される（Encryption / decryption settings − used for generic ciphering LLI）
GPI_CRYPTO GPI_CRYPTOTYPE OPTIONAL [暗号化／暗号解読に関する設定（Setting for encryption / decryption） ],
GPI_CRYPTO_IV GPI_IV OPTIONAL [暗号加入者のための初期化ベクトル（Initialisation vector for crypto）],
GPI_CRYPTO_KEY GPIJKEY OPTIONAL [暗号化／暗号解読に関するセッション鍵（Session key for encryption / decryption）]
}
GPI_PACKET : := SEQUENCE {
−− 一般的データ・パケット（或いは、フレーム）定義（Generic data packet (or frame) definition）
−− 必須パケット情報（Mandatory packet information）
GPI_PACKET GPI_PACKETTYPE [これはパケット形式である（This is the packet type）],
GPI_PACKET_HEADER_PTR GPI_PACKET_HEADER [プロトコル特定フォーマットにおける実際のパケット・ヘッダ（Actual packet header in protocol specific format）],
GPI_PACKET_PAYLOAD_PTR GPI_PACKET_PAYLOAD [プロトコル特定フォーマットにおける実際のパケット・ペイロード（Actual packet payload in protocol specific format）],
GPI_PACKET_HEADER_LEN INTEGER [ ヘッダ長（バイト）（Header length in bytes）],
GPI_PACKET_PAYLOAD_LEN INTEGER [ペイロード長（バイト）（Payload length in bytes）],
−− 任意パケット情報（Optional packet information）
GPI_TRCH GPI_TRCH_IDENT OPTIONAL [伝送チャネル識別子（transport channel identifier）],
GPI_TF GPI_TFTYPE OPTIONAL [伝送フォーマット（transport format）],
GPI_DEST_MAC GPI_MAC_ADDRESS OPTIONAL [送信先ＭＡＣアドレス（destination MAC address）],
GPI_SRC_MAC GPI_MAC_ADDRESS OPTIONAL [送信元ＭＡＣアドレス（source MAC address）],
GPI_DEST_IP GPI_IP_ADDRESS OPTIONAL [送信先ＩＰアドレス（destination IP address）],
GPI_SRC_IP GPI_IP_ADDRESS OPTIONAL [送信元ＩＰアドレス（source IP address）],
GPI_DEST_PORT INTEGER OPTIONAL [送信先ポート番号（destination port number）],
GPI_SRC_PORT INTEGER OPTIONAL [送信元ポート番号source port number ],
GPI_SN INTEGER OPTIONAL [系列番号（sequence number）],
GP I_I P_HEADER_CHKSUM GP I_I P_HEADER_CHECK_SUM OPTIONAL [ＩＰチェックサム（IP check sum）],
GPI_TRAFFICCLASS INTEGER OPTIONAL [トラフィック形式に関する識別子（identifier for the traffic type）],
GPI_PACKETDIRECTION GPI_DIRECTION OPTIONAL [プロトコル・スタック中のパケットの方向（direction of packet in the protocol stack）]
}
層における一般的機能とそれらの実行環境におけるＬＬＩによって呼出されるオペレーティング・システム特定機能との間の写像はいくつかの方法で実行される。図８を参照すると、各ソフトウェア層（例えば、Ｌ２）はいくつかの所定の一般的機能を含む。Ｌ２層の供給元が所定の一般的機能を使用すると仮定すると、この層はプロトコル・スタックの中の他の層と相互動作するであろう。プロトコル・スタックの層に対応する実行環境はオペレーティング・システム表（ＯＳ１）と、その実行環境における一般的機能を実行するであろうオペレーティング・システム特定機能にその層と関連する一般的機能を効果的に写像する他のオブジェクトに関連する。示した例では、Ｌ２における一般的機能１、例えば receive_message はＵＮＩＸ ＰＯＳＩＸに基づく実行環境について同等の機能に変換される。オペレーティング・システム表（ＯＳ）または写像オブジェクトは例えばプロトコル・スタックのオペレータ、或いは実行環境提供者といった他のいくつかの実体によって提供される。
図９は別の配置を示し、その中ではソフトウェア層Ｌ２はオペレーティング・システム表（ＯＳ２）、または他の写像オブジェクトによって直接それらのＬ２フォーマットから近くの（local）オペレーティング・システム・フォーマットに写像されるその層に特定の機能を含む。このように、例えば、Ｌ２機能１（それはさらに send_message に対応する）はオペレーティング・システム表によって、近くの（local）ＵＮＩＸ ＰＯＳＩＸに基づく実行環境機能または receive_message 機能に関する機能に写像される。この特定の配置では、ソフトウェア層の供給元は、また対応するオペレーティング・システム表ＯＳ２、或いはまたはＵＮＩＸオペレーティング・システム環境のための写像オブジェクトを提供することも有り得るかもしれない。Ｌ２供給元は、供給元提供のＬ２ソフトウェア層を解釈（interpret）するために異なる形式のオペレーティング・システムに関するいくつかのオペレーティング・システム表を提供することができる。
図１０は適当なオペレーティング・システム-示された例ではＵＮＩＸ（ＯＳ１）またはマイクロソフトＷｉｎｄｏｗｓ（ＲＴＭ）（ＯＳ２）へ、一般的機能呼出を指示するために使用できる仮想オペレーティング・システム（ＶＯＳ）の使用を図式的に示す。このように、例えば、一以上のオペレーティング・システムまたは実行環境オプションが、例えば基地局或いは端末といったデバイスまたは装置上で通常のプロトコル層を動かすために使用され、ＶＯＳは一般的機能呼出を例えばソフトウェア層Ｌ２からＵＮＩＸまたはマイクロソフトＷｉｎｄｏｗｓ（ＲＴＭ）オペレーティング・システム表のいずれか、または写像オブジェクトへ指示することができる。同じソフトウェア層の二つのインスタンスが異なるオペレーティング環境において実行される場合には、ＶＯＳは同じ一般的機能（例えば、一般的機能１）を例えば第一のＬＬＩについてはＵＮＩＸオペレーティング・システム表（ＯＳ１）へ、及び第二のＬＬＩについてはマイクロソフトＷｉｎｄｏｗｓ（ＲＴＭ）オペレーティング・システム表（ＯＳ３）へ写像することができ、そこでは同じ一般的機能が op.sys function x 及び op.sys. function a に対応する。ソフトウェア層Ｌ２は一般的機能を使用しているので、Ｌ２の供給元は実際の層ソフトウェア（モジュール）をただ提供するのみで良く、ＶＯＳ及びオペレーティング・システム表ソフトウェアに掛かり合いになっている必要はない。ＶＯＳの動作はさらに下記で詳述する。
さて図１１を参照すると、供給元が提供するＬ２ソフトウェア層はさらにオペレーティング・システム特定表（ＯＳ２、ＯＳ４、ＯＳ５）、またはＬ２特定機能をそれぞれのオペレーティング・システム機能、例えばＵＮＩＸまたはマイクロソフトＷｉｎｄｏｗｓ（ＲＴＭ）にそれぞれ写像するために、同じくＬ２供給元によって提供される写像オブジェクトを使用して、異なるオペレーティング・システム間で、Ｌ２特定機能を写像することができる同じくＬ２供給元によって提供された仮想オペレーティング・システム（ＶＯＳ）によって写像される層特定機能を含む。このように、様々な実施例はプロトコル層ソフトウェアの言語及び／またはオペレーティング・システムへの非依存性を達成するために実施される。
図１１はまた、例えば異なるＬＬＩに各々対応する二つのスレッドが異なる実行環境において実行のため異なるオペレーティング・システム表に如何に写像されるかを例示する。スレッド１はＬ２特定機能（Ｌ２機能１）によってＶＯＳ表または写像（map）において特定の先頭アドレスに指定され、同様にＵＮＩＸ環境において実行される機能（op.sys 機能ｘ）に対応するＵＮＩＸオペレーティング・システム表において特定の先頭アドレスに指定される。そして、スレッド１は層Ｌ２モジュールにおける次の機能ポインタ（Ｌ２機能２）に戻る。異なる実施例では、スレッド１はＷｉｎｄｏｗｓ環境において層Ｌ２モジュールにおける層Ｌ２特定機能ポインタ（Ｌ２機能１）に対応するＷｉｎｄｏｗｓ特定機能ポインタ（op.sys 機能ａ）の実行のために、ＶＯＳによってＷｉｎｄｏｗｓオペレーティング・システム表ＯＳ４に指定される。
スレッド２は異なるＬｉｎｕｘ実行環境において実行される同じ層Ｌ２の異なるＬＬＩに対応する。この筋書き（scenario）では、Ｌ２特定機能ポインタ（例えば、Ｌ２機能３）はＬｉｎｕｘ特定機能（op.sys 機能ｍ）に写像され、それが実行され、そしてスレッド２は層Ｌ２モジュールにおけるその次の機能ポインタ（Ｌ２機能４）に戻る。
図１２は多数のプロトコル・スタックにおける層の多数のインスタンス化を示す。ＵＭＴＳビデオコール及び二つのＷＬＡＮインターネットブラウジング・プロトコル・スタックが同時に稼働していることが示されている。一つのインターネット・スタックは無制限インターネット閲覧に対応しており、一方他のものはイントラネット閲覧に対応し、それ自体は（例えば仮想私設網（Virtual Private Networking）ＶＰＮプロトコルに基づいて）暗号化を支援しているはずである。二つのブラウザ・スタックはＷＬＡＮに接続された四つのプロトコル層インスタンス（それぞれ、Ｌ４１〜Ｌ１１及びＬ４２〜Ｌ１２）を有し、しかしながら２層インスタンス（Ｌ２１及びＬ２２）は各々において別々に構成される。ここで暗号化に対応する２層の第二インスタンスを示すインターネット・スタックはＬ２２（sec）によって、暗号化に対応しない２層の第一インスタンスを示すインターネット・スタックではＬ２１（non-sec）によって例示される。これらの構造はこの層の各インスタンス（Ｌ２１及びＬ２２）に送られる元の結合メッセージによって決定されるものである。層１、３及び４は二つのブラウザ・スタックについて同じであり、別々に（それぞれ、Ｌ１１、Ｌ３１、及びＬ１２、Ｌ３２、Ｌ４２）含むが、それぞれの層の全く同じに構成されたインスタンスを含む。
安全なスタック層インスタンスを実行するために使用される実行環境は、安全でないインスタンスからのメッセージまたは構造データへのアクセスのあらゆる可能性を防ぐように構成される。例えば、これは安全なスタック・インスタンスからそれらを分離するために、全てのメモリ・アクセス及びメッセージ通信操作の認可を行うオペレーティング・システム機能表を使用することによって達成される。例えば、send_message 機能の根本的な実施は、ＶＯＳ及び／またはオペレーティング・システム写像オブジェクト提供者が行うべき機能を必要とするものによって決定される。従って、例えばソフトウェア層が信頼されなければ、send_message 及び receive_message 機能はより一層安全性を意識する。これは例えば基本的検索データ機能に結合された認可機能を含む。さらなる例では、create_LLI 機能は、信頼のあるソフトウェア・モジュールによって使用されるメモリにその層がアクセスできる可能性がないことを保証するために、それ自身のメモリ領域によって個別の処理を生成する。オペレーティング・システム自身が十分に信頼されていなかったと見なされたならば、それは、個別のオペレーティング・システム環境においても実行されたであろう。
各層はまた異なる性能最適化によって、例えば処理集約的暗号化操作を行ってスタック・インスタンスに与えられた優先権によって実行される。
２層の第二のＬＬＩ（Ｌ２２）は第一のＬＬＩ（Ｌ２１）として同じコード・モジュール（２層）を使用するが、作業メモリに書き込まれたコード・モジュールのさらなる複製というよりは新しい論理実体（この場合には、オペレーティング・システム実行または処理スレッド）である。例えば、第二のＬＬＩ（Ｌ２２）はオペレーティング・システムによって制御され、それに関連するそれ自身の固有の識別子及び構造を持つこのコード・モジュール内の第二の実行スレッドである。この構造情報はただ論理層のそのＬＬＩ（例えば、スレッド）及び各インスタンスに関する構造を設定する制御実体（下記でさらに詳述されるＣＭ）にアクセス可能である。ＬＬＩ間の相互作用はまたＣＭによって構成され、（実行環境構造指標を介して）相互作用する必要がないＬＬＩを相互作用から防ぐことができる。
さらに、２層の二つのＬＬＩ（Ｌ２１及びＬ２２）は共通の機能性に対応するが、それらは異なって構成される。この例では、Ｌ２２は暗号化／復号化に対応するが、Ｌ２１はしない。これらの構造設定は結合メッセージによって設定され、各インスタンス（ＬＬＩ）に関連するスタックにおける適当な場所または作業メモリ内の表に記憶される。
２層ソフトウェアの第二のＬＬＩは異なる出力層にそれを関連付ける異なる結合参照［bind. ref］と同様に、異なるＬＬＩ識別子［instance. ref ］を持つであろう。［function. ref］によって識別されたオペレーティング・システム機能表（或いは、オペレーティング・システム・クラス）は、それぞれの実行環境の中でこれらの機能を実行することが必要とされるオペレーティング・システム特定機能に一般的機能を写像する異なるオペレーティング・システム機能表を必要とするであろう場合において、それが異なる実行環境で動作していない限り、２層の第一のＬＬＩによって使用されるのと同じオペレーティング・システム表であってもよい。第二のＬＬＩはまたそれ自身の実行スタック（Ｌ２２スタック）及び領域メモリを持つであろう。各ＬＬＩは利用可能な同じ構造オプションを持つであろうが、それとは異なりこれらを稼働／不能にすることができる。これらはそれらのそれぞれのＬＬＩ構造の中にパラメータとして記憶される。
各層は所定の一般的機能呼出を利用し、それはメモリ管理機能と同様にスレッド管理を含むであろう。そして、これらはターゲットデバイス上のオペレーティング・システム特定機能の集合へランタイムに写像される。一以上のＬＬＩによってアクセスされるデータ（例えば、オペレーティング・システム機能表及び信号パケット）は所定のフォーマットで提供され、それは各ＬＬＩが所定の機能呼出の集合を使用してこの情報にアクセスすることを可能にする。
結合信号［bind. para］はＬＬＩによっていつでも受信され、元の結合信号の後に含み、従って、ＬＬＩの構造オプションが変わるのを可能にし、その上 bind. ref パラメータを変えることによってＬＬＩが別のＬＬＩに結合するのを可能にし、このようにしてプロコル・スタックの動的な再結合を可能にする。
プロトコル層のＬＬＩは制御の程度及び他の実行スレッド（例えば優先権に基づく異なるスレッド間のマルチタスクを終結及び提供することができる）からの分離を行うため、それ自身の実行スタックを持つオペレーティング・システム・スレッドをインスタンス化することによって生成される。代りに、異なるＬＬＩは、各処理をそれ自身のメモリ領域に与え、且つ他のＬＬＩからのアクセスを防ぐことによってより大きな程度の分離及び制御を行うために、異なるオペレーティング・システム処理としてインスタンス化される。しかしながら、これは優先権に基づくマルチタスク（即ち、スレッドに並べられた処理間の文脈切替）においてオーバーヘッド増加の不利益（penalty）を被る。最終的に、ＬＬＩは同じオペレーティング・システム・スレッドの中でインスタンス化される。これは、ＬＬＩを設定及び制御する際に最小のオーバーヘッドがあるが、個別のスタックまたは領域はなく、従って、データ（例えば、ＬＬＩ構造）へのアクセス及びその実行（即ち、優先順位付け等）は、オペレーティング・システム安全基準が頼りであれば、親スレッドに強く依存するという利点がある。この後者の場合には、ＬＬＩによって使用されるプログラミング言語及び実行環境が親スレッドと同じであるならば、それは好ましいが、これは必須ではない。
さらに前述のオペレーティング・システム実行環境に対して、ＦＰＧＡまたはＤＳＰといった外部プログラム可能デバイスにおいてＬＬＩをインスタンス化することも可能である。これらの実行環境は同じオペレーティング・システムの制御の下で一つの（或いは多数の）プロセッサ配置内の環境と非常に異なる。しかしながら、仮想オペレーティング・システム機能表（ＶＯＳ）はデバイス間通信の複雑さが異なるデバイス上でＬＬＩを実行するソフトウェア・モジュールから取出されることを可能にする。
前述の方法において、多数の論理層インスタンスは異なる実行または処理スレッドを使用して異なる実行環境において生成される。さらにこれに対して、各ＬＬＩは異なるプロトコル特性（構造オプション）によって構成できるが、共通データ・アクセス機構を使用して信号メッセージ・データ及び他の共有データにアクセスすることができる。上で述べられたように、一以上のＬＬＩが同じスレッド内で生成されるとき、特別な状況が発生する。
既に論じられたように、異なるレベルの安全性および性能を提供するために、（同じ、或いは異なる）プロトコル・スタック層の異なるＬＬＩを異なる実行環境において実行することが可能である。例えば、ブルートゥース・スタックは安全な高速接続及び安全でない低速接続の両方に対応している。安全な高速接続を扱うＬＬＩに関する実行環境は安全性及び性能に対して最適化でき、低速接続に対応するＬＬＩはあまり安全でない、あまり最適化されていない実行環境において対応されるであろう。
この方法は、各ＬＬＩについて（適切な安全基準が）必要であれば異なる実行環境を用いてＬＬＩ間の相互作用を制限し、且つ適切にそれらを分離する。このように、信頼度の高いソフトウェアはより多くの自由度を許容し、厳しいランタイム安全性検査や機能性への制限なしで実行することができるが、一方、あまり信頼のないソフトウェアを使用するＬＬＩは他のＬＬＩとの許容可能な相互作用に対してより多くの制限を行うことでより安全な環境において実行することができる。これらの基準はまたソフトウェアの中の信用レベルだけでなくＬＬＩによって支援されるサービスの形式に関連する完全性及び他の安全性要件（例えば、プライバシー及び秘密など）によって決まるであろう。
図１３は層をインスタンス化するための、携帯電話を例にした場合の一つのソフトウェア層を別のソフトウェア層に結合するための設定及び更新シナリオである。電話は作業メモリに直接に（即ち、そのまま（natively））または仮想マシン環境機構（例えば、Ｊａｖａクラスローディング原理）を用いてロードされるいくつかのソフトウェア・コード・モジュール及び同定された入力点（entry points）を記憶、或いはダウンロードする。示された例では、これは層１〜３、及びソフトウェア層に対応するコード・モジュールを作業メモリに搭載し、入力点を呼出し、且つ層を構成あるいは再構成する適切な結合メッセージを送信することによってプロトコル・スタックの配列を制御する構造マネージャ（ＣＭ）を含む。例えば、１層に送られる結合メッセージはそれを２層に「結合する（bind）」ように指示する。
２層が２′層に置き換えられる更新シナリオでは、２′層ソフトウェア層ファイルまたはコード・モジュールは作業メモリ（Ｌ２′）にロードされ、構造マネージャ（ＣＭ）は新しい層に対して層入力点を呼出す。そして、その出力を３層に方向付けし、且つ適切なプロトコル選択を設定するためにそれは結合メッセージを２′層に与える。構造マネージャはまたその出力を２層から２′層に再方向付けするために結合メッセージを１層に方向付けする。この更新再構成はランタイムの間に起こり、また比較的簡単な結合メッセージを実施することだけを要求する。また、それは（古い）２層（Ｌ２）を通過するあらゆるパケットが処理、且つ３層（Ｌ３）に渡され続けることを可能にし、そのため関連セッションは動的再構成によって終結されない。このように、新しいインスタンスが古いインスタンスの構造（状態を含む）データへのアクセスを有していれば、スタックの再構成の間セッション終結の必要性がない。
図１４を参照すると、例えば２層の第一のインスタンス（Ｌ２１）をインスタンス化するために、構造マネージャ（ＣＭ）は２層コード・モジュールを作業メモリ（或いは、仮想マシン環境）のプログラム・コード領域にロードする。そして、構造マネージャは固有のソフトウェア・モジュールの場合には作業メモリ中のコードの入力点（層入力点）を呼出すことによって、また仮想マシン環境では層入力点メンバー機能（ラン・メソッド）を呼出すことによってＬＬＩを開始する。
ＣＭはロード手順を起動し、従って、Ｊａｖａについてはそれはクラス・ファイルをロードすることを意味し、固有の層についてはそれは実行環境に適切な方法でメモリにコードの一部（a section）をロードすることである。ＣＭは実行環境を知っているので、それはモジュールをロードし、適切な初期設定（default）ＶＯＳ及び／またはオペレーティング・システム表（ＯＳ）を渡す 方法を知っている。これらの例はさらに下記で詳述される。ネイティブコード層では、これは入力点機能を放置し、且つ実行することによる入力点の起動を必要とするであろう。入力点機能は結合メッセージが受取られることを可能にする初期設定動作を有する必要がある。例えば、Ｊａｖａクラスにおいて、これは receive_message 機能を呼出すために初期設定ＶＯＳ及び／またはオペレーティング・システム特定クラスをＪＶＭにロードすることを起動する（invoke）であろう。ネイティブの層では、入力点は初期設定ＶＯＳ及び／またはオペレーティング・システム特定表へのポインタであるパラメータを含むであろう。一旦、モジュール入力点が初期化されると（例えば、それはＶＯＳ或いはＯＳの複製及びいくつかの作業または領域メモリの割当を起動することになると）、ＶＯＳ（或いは、オペレーティング・システム機能表）中の receive_message 機能を呼出し、そしてこれは結合メッセージが受信されるまでその他には何も行わない。
前述の初期化（initialise）機能は初期設定ＶＯＳ（或いは、オペレーティング・システム）表を得て、必要ならばそれを複製し（または共有メモリ中のその場所を指示し）、receive_message 機能を呼出す単にブートストラップ方法である。
receive_message 機能はＶＯＳまたはオペレーティング・システム表（ＯＳ）にあり、従って、それは（機能呼出しまたはオペレーティング・システム・メッセージ通信等のいずれかによって）そのメッセージがいかに送られるかを決定するＶＯＳまたはＯＳである。結合メッセージは特定のメッセージ形式である（全てのメッセージはメッセージの形式の決定を可能にする固有の識別子を有する）。従って、結合メッセージを待っているとき、他のメッセージは（クリーンな出口を通常強要するであろう端末は別として）無視される。
結合ハンドラは、新しいスレッドまたは処理インスタンスを起動するかもしれない、もしくは実際にこれを行わず、ＬＬＩ表を単に修正するＶＯＳまたはＯＳ機能である create_new_LLI を単に呼出す。しかしながら、結合メッセージからの構造情報はその構造がそのＬＬＩについて設定されることを可能にするために、create_new_LLI 機能に渡される。これはＬＬＩによって使用される特定のＶＯＳ及び／またはＯＳ表への参照を含む。その層がプロトコル・メッセージを異なる実行環境における層に渡す必要があれば、これは初期化機能によって複製される、または使用されるＶＯＳ及び／またはＯＳ表とは異なる。新しいスレッドは処理すべきメッセージを待つために、特定のＶＯＳ（或いは、オペレーティング・システム表）中のメッセージ機能を呼出す。
上で論じたように、結合メッセージは層の出力を次の層に方向付けする相互作用もしくはインタフェース情報を含む。結合メッセージはまたこれ（機能表）を行うために必要な機能呼出を含む。例えば、機能の初期化テンプレートまたは機能ポインタはモジュール入力点に渡され、一方、処理機能のもっと特定のテンプレートは、例えば関連するＬＬＩについて選択された構造オプション、及び／またはその実行環境に依存して、結合メッセージによってモジュールに渡される。そして、ＣＭは新しいＬＬＩから許容可能な他のＬＬＩへの相互作用を可能にする実行環境特定安全機構に指示することができ、且つ新しいＬＬＩによって許容可能な構造データの部分のみにアクセスを許すことができる共有データに対するクセス制御機構を随意に設定することができる。
結合メッセージ構造オプションは、安全性、性能及び電力消費に関する一般的構造優先権を使用することによって層内で暗号化を可能にするかどうかといった可能にすべき特性を決定することができる。多数のプロトコル・スタック・インスタンスが同時に使用される所では、層ごとの多数のＬＬＩがあり、これらは固有のインスタンス識別子（instance.ref ）によって識別される。同じ層の異なるＬＬＩは異なる構造を有し、例えばいくつかは暗号化に対応し、いくつかは対応しないことがある。
入力点呼出及びパラメータ受渡しは特定の実施の詳細に関係なく一般的方法で対応される。好ましくは、ＡＮＳＩ標準のＣ（さもなければ、Ｃdecl と云う）仕様は固有ソフトウェア・モジュールに関するパラメータ 、例えば（function.pointer）または（start.pointer）をスレッド生成及びメッセージ通信関係機能（構造データ・アクセス機能を含む）といった実行環境関係機能を提供する入力点に受渡しするために使用される。しかしながら、Ｊａｖａ層について、ソフトウェア層に関するＪａｖａクラスはスレッドＪａｖａクラスを拡張し、その層がＪＶＭに搭載されるとき、ラン・メソッドは自動的に呼出される。固有の層入力点が新しいスレッドをインスタンス化するために呼出されれば、新しいインスタンスは新しい実行スレッド及び入力点復帰において生成される。
代わりに、（特に層が仮想マシン環境において実行するが、単にこれらの層に限定されないとき）入力点クラス（或いは、場所）は層ソフトウェア・モジュールに付随する明白な（メタ）情報ファイルにおいて示される。結合メッセージが処理されるとき、新しいインスタンスのスレッドは create_new_LLI を用いて生成され、それは receive_message を用いてプロトコル・メッセージを待つ。
各層インスタンス構造データは［signal.pointer］といったパケットまたはプロトコル・メッセージを送るために次の層インスタンスに関する情報を含む。このように、層がパケット（プロトコル・メッセージの中に含まれる）を次の層へ送ることを必要とするとき、結合参照（bind.ref）に関する get_attribute 機能がＬＬＩ構造データからメッセージを送る次の層インスタンスを得るために使用される。
同じ層の多数のＬＬＩをインスタンス化しているとき、結合ハンドラは（Ｌ２２スタックにおける）新しい層インスタンスに関する構造データの新しいインスタンスを形成するであろう。前に述べた構造データはインスタンスについて固有の識別子を含み、一旦新しいスレッド・インスタンスが生成されると受信通知（acknowledgement）がその後適切な実行環境安全基準を設定することができるＣＭに返される。結合メッセージはインスタンスの構造を変えるために直接ＣＭによってＬＬＩへ送られる。
前に述べたように、入来結合メッセージはインスタンス番号［instance. ref］を含む。結合参照［bind. ref］は出力プロトコル・メッセージが送られるべき現在のＬＬＩの上の層のＬＬＩを識別する。その層が所定数の機能（例えば、create_new_LLI） の一つを呼出すとき、機能ポインタは、 ＬＬＩが作動している特定の実行環境またはオペレーティング・システムについてこの機能に関する正しくフォーマットされた機能を含む適切な場所、及びメモリ呼出を指示するように、機能ポインタ［function.pointers］は特定のＬＬＩに適切なオペレーティング・システム機能表（ＯＳ及び恐らくはＶＯＳ）を識別する、言い換えれば、オペレーティング・システム機能表は、これらの機能を実行するためにＬＬＩ中の「一般的」機能呼出をオペレーティング・システムによって使用される言語及びオペレーティング・システム従属機能に写像する。機能表は一般的に層の間を通過する信号パケットまたは他のメッセージにアクセスすることを含むメモリ・アクセス及び管理機能を含む。このように例えば、１層はオペレーティング・システム機能 send_message を使用して２層内のＬＬＩに信号パケット（signal_packet_2 に関する）ポインタ［signal.pointer］を渡す。これによって２層ＬＬＩはオペレーティング・システム機能表によって提供された機能を使用し、且つそれ自身のＬＬＩ実行スタック（Ｌ２１スタック）を利用してその内部プロトコル機能に従ってこの特定の信号パケットにアクセスし、さらに処理することを可能にする。
上で論じたように、共通プラットホームに無関係な仮想オペレーティング・システム（ＶＯＳ）機能表は実行環境機能及びＬＬＩ構造情報へアクセスを行うために利用される。これは、実行環境（オペレーティング・システム及び仮想マシン）非依存性を向上させ、そして図１５で例示される。更新された３層（Ｌ３′）に加えて「古い」３層（Ｌ３）を含む五つの層（Ｌ１〜Ｌ４）が示されている。Ｊａｖａ仮想マシン（ＪＶＭ）内で動作する二つの層（Ｌ３′及びＬ４）が示される。ＪＶＭは実時間でこれらの層に対応するソフトウェア・モジュールのコードを解釈（interpret）するためにインタープリタまたは仮想マシン環境を必要とし、また非Ｊａｖａソフトウェアとインタフェースする固有インタフェース（ＮＩ）を提供する。他の層（Ｌ１〜Ｌ３）はオブジェクト・コードに事前編集（precompiled）され、オペレーティング・システムによって独自にランタイムに実行される。
それはまた示されたように多数の実行環境が提供されることを可能にし、そこではオペレーティング・システム１及びオペレーティング・システム２各々が異なる層を実行するが、層がなお相互に通信することができる。
層における一般的機能呼出はオペレーティング・システム機能表（ＯＳ）を使用して実際のオペレーティング・システム特定機能に変換される。ＶＯＳの場合には、さらなる変換または写像が必要である。各ＬＬＩへの結合メッセージは層が実行するのを可能にするためにＯＳにおいてそれ自身がオペレーティング・システム特定機能を指し示すＶＯＳ機能表に機能ポインタを提供する。ＶＯＳ機能表は異なるオペレーティング・システム特定機能において再指示できるので、これはオペレーティング・システム非依存性を提供する。例えば、ＣＭは、ＬＬＩによって使用される一般的機能に対応するオペレーティング・システム特定機能のＶＯＳ表を、例えばＵＮＩＸ準拠ＰＯＳＩＸ機能（ＯＳｘ）からＵＮＩＸ準拠システムＶオペレーティング・システム機能（ＯＳｙ）へランタイムに動的に変えるように、ＬＬＩに（結合メッセージを介して）指示することができる。しかしながら、或るオペレーティング・システム特定機能はシステム状態関係情報（セマフォ及びメモリ割当のような他のシステム資源取扱機能）を含み、且つ変化するので、動的な変化は注意を必要とし、従って、ＶＯＳ概念は必要があればこれらの間接機構内の情報（intelligence）及びオペレーティング・システム抽象概念を提供することによってＯＳ環境間で途切れなく切換える能力を与える。それはまたソフトウェア・コード・モジュールが異なる実行環境へ対応するために可能な最も一般的方法で書かれることを可能にする。
プロトコル・ソフトウェアでは、ストリング操作はあまり行われない、しかしながら「calculate_crc」または「convert_ip_address_2_string」のような或る頻繁な操作は、オペレーティング・システム表（ＯＳ）またはＶＯＳ表において対応するオペレーティング特定機能を持つ一般的機能として含まれる。代りの配置では、暗号化及び復号化といった或る信号データ操作機能は、異なる暗号化／復号化層を実行するために構成される一般的暗号化／復号化層において実施される。これは最も数学的な機能を含み、（必要であれば）そして、それはこれらの複雑な数学機能に関する性能促進装置によって（コプロセッサのような）実行環境において動作することができるので、数学的拡張性を持つＶＯＳまたはオペレーティング・システム表を使用することができる。そして、他の、或いは一般的プロトコル層はこれらの拡張のない一般用途ＶＯＳまたはオペレーティング・システム表（ＯＳ）を使用するであろう。
機能ポインタが実行環境及び言語無関係な方法においてモジュールに渡される方法は図１６及び１７に例示される。特に、これはＣのような元々のコード例を示し、図１６は既知の動的な連結方法を示し、図１７は実施例に従って機能表ポインタを受渡す方法を示す。
図１６を参照すると、ソフトウェア・モジュールの供給元は、一連のＡＰＩ機能（ｘ及びｙ）及びターゲットプラットホーム（ハードウェア、機能ライブラリ集合及び入力／出力のようなオペレーティング・システム機能）のメモリに記憶されたデータと相互作用する変数を含む（この例では、Ｃプログラミング言語における）ソース・コード・プログラム、及び恐らくはプラットホーム上で動作する他のＡＰＩライブラリ・モジュールを開発する。ソース・コードは既知のコンパイラによってオブジェクト・コードに編集され、それは一連の機能をターゲットプラットホームに特定の二進マシン（または、オブジェクト）コードに変換する。二進コードは各々がＡＰＩライブラリ・モジュールに中の一連の機能（ｘ及びｙ）の一つに対応する一連のplace-holdersまたはシンボル（シンボルＸ及びシンボルＹ）を含む。
オブジェクト・コードが実行のためにターゲットプラットホーム上のメモリにロードされるとき、動的なリンカはコードを検査し、ライブラリ・ソース・コードにおける機能（それぞれｘ及びｙ）に対応する以前ロードされたＡＰＩライブラリ・モジュール中のＡＰＩライブラリ機能（mem.loc(X) 及び mem.loc(Y)）のメモリ場所をもつ一連のシンボル（シンボルＸ及びシンボルＹ）を置換える。ライブラリ・モジュールがまだロードされてなければ、それは動的なリンカ（もしくは、Ｊａｖａ準拠実施の場合には、クラス搭載器）によって動的にロードされる。そして、そのプラットホームはプログラム命令を含む一連のメモリ場所を通してプログラム・カウンタを進め、且つソフトウェア・モジュールによって必要とされるＡＰＩライブラリ機能呼出（mem.loc(x)、mem.loc(y)）に対応するメモリ場所にジャンプする（分岐する）ことによってコードを実行することができる。
図１７を参照すると、ターゲットにロードされるソフトウェア・モジュールの供給元（Ｃプログラマ）は実際のＡＰＩ機能呼出（機能ｘ及び機能ｙ）が図１６の方法に使用される場所に対応する一連のＡＰＩ機能呼出（redirect.f(x) 及び redirect.f(y)）を含むソース・コード・プログラムを開発する。出力先変更機能は単に機能呼出を指定されたＶＯＳまたはＯＳ機能ポインタ表中の特定の先頭アドレスのメモリ場所に出力先を変更する（アレイ内の領域もしくは共有メモリ中の或る-編集時には判らない-場所で保持される）。Ｃソース・コードはコンパイラによってさらに二進マシン・コードを含むオブジェクト・コードに編集されるが、しかしながらソース・コード中の機能に対応するシンボル（Ｘ及びＹ）はない。その代り、出力先変更機能は単にランタイムに目標プラットホーム上にロードされるメモリ駐在機能表内の先頭アドレス（各入口は一つのＡＰＩ機能に対応する）へのジャンプ（或いは、分岐）命令に編集される。
このように、多数の実行スレッドはソフトウェア・モジュールを動的に再連結することを必要とせず異なるＡＰＩ実施コードを用いてソフトウェア・モジュール・コードを動かすことができる。
コンパイラは出力先変更機能を相対的なメモリ・ポインタに変換し、それはランタイムにＯＳまたはＶＯＳ表の開始に相対的であり、従ってオブジェクト・コードによって示された適切な実行環境特定機能を指し示す。この場合には、ソース・コードは図１６のＡＰＩ形式機能ではなく出力先変更機能を使用して書く必要がある。
代わりの配置では、従来技術のソース・コード・プログラムは修正されたコンパイラによって同じオブジェクト・コードに変換され、コンパイラは（動的にランタイムにロードされる）機能表の使用を可能にするためにＣ特定機能（例えば、機能ｘ）を出力先変更機能呼出 redirect.f(x) に変換する。
このソフトウェア・モジュール・オブジェクト・コードがメモリにロードされるとき、それは領域または共有メモリに対応するプラットホーム特定写像表（例えば、メモリ中の開始アドレス）に参照を渡される。機能ポインタの初期設定表はオブジェクト・コードに関して所定の相対的メモリ場所にロードされ、またソフトウェア・モジュールが入力点、及び表参照ポインタ内の受渡しの他の手段を含まないインスタンスについても可能である。
そして、プラットホームは、プラットホーム上の実際のＯＳもしくはＶＯＳライブラリ機能（mem.loc(x)）のメモリ場所にあるメモリ値対応の表入力（redirect.f(x)）にプログラム・カウンタを出力先変更（ジャンプもしくは分岐）する redirect.f(x) から編集される一連の命令を介して動かすことによって、このオブジェクト・コードを実行する。その機能は実行され、プログラム・カウンタはジャンプ（或いは、分岐）がソフトウェア・モジュール・オブジェクト・コードにおいて生じたところに戻る。
このことはプラットホーム（オペレーティング・システム、動的なリンカまたはＪａｖａ仮想マシン）が特定の言語及びソフトウェア・モジュール・コードの意味（semantics）の知識を持つ必要がないという意味において、位置に無関係なコード（即ち、どのメモリ・アドレスからでも実行できるコード）に編集されるロード可能なソフトウェア・モジュールがプラットホーム非依存であることを可能にすることが理解されるであろう。編集されたオブジェクト・コードは動的なローダ（loader）がプラットホーム特定機能に関するメモリ場所によって解釈、及び置換を必要とするであろう所定のシンボルではなく写像表と同じポインタを含むので、ソース・コードは言語に無関係になることが同じく理解されるであろう。例えば、Ｃ、ＶｉｓｕａｌＢａｓｉｃ或いはＰａｓｃａｌで書かれたプログラムは実行環境特定機能が位置しているメモリにおける開始点を通過する相対機能ポインタの同じオブジェクト・コードに各々編集され、相対ポインタはこの開始点から対応する機能の相対的な場所を示す。これによって供給元はどんな言語で書かれたソフトウェア・モジュール（オブジェクト・コード）でも提供することが可能となり、それはプラットホームに依存しない。
最後に、ソフトウェア・モジュール・コードを実行する各スレッドまたは処理はライブラリ機能が実施される方法において、同じコードの一部の振る舞いが完全に異なることが可能なように異なるライブラリ機能表写像によってそうすることができる。従って、（メモリ駐在の二進またはバイトのコード・モジュール上での）一つの実行スレッドは、性能を最適化するため軽量ライブラリ機能集合を実施するライブラリ機能を呼出し、（同じメモリ駐在コードの）別の実行スレッドは、例えばインスタンスに関する安全性を最適化するために重量ライブラリ機能実施を使用することができる。
図１８及び１９を参照すると、動的な連結（クラス・ローダ）及び機能ポインタ受渡し方法がそれぞれＪａｖａ言語準拠層プログラムについて示される。固有のソフトウェア・モジュールとＪａｖａソフトウェア・モジュールとの間の主な差異は、Ｊａｖａにおいては余分の間接層がＪａｖａソフトウェア・モジュールと固有のソフトウェア・モジュールとの間を横断して導入されることである。Ｊａｖａソフトウェア・モジュールは、固有のライブラリ機能 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) に出力先変更するため写像表を使用するであろう。
これは明らかにプラットホーム特定の方法で実行され、各プラットホームは実際の固有ＡＰＩライブラリがアクセスされることを可能にするために対応するインタフェース・ライブラリの集合を有することを必要とするので、Ｊａｖａクラス・ローダは固有のインタフェース・ライブラリをロードするこの中間手段を取除くためにカスタム化される。
図２０はプロトコル・スタックの実施へのメッセージごとのスレッド方法を例示する。この方法では、スレッドはプロトコル・スタックを横切る各パケットまたは信号に関連する。示された例では、スレッド信号１はスタック・インスタンス内で１層によって処理されるプロトコル・メッセージ信号１に関連し、その後、図示の様々な機能またはサブモジュール（図１４におけるコード・ブロックまたはモジュールのパケットまたはプロトコル・メッセージ処理部分）によってそのメッセージが処理される２層上に続き、そして実行はそのメッセージがさらに処理される３層上に続く。同様に、スレッド信号２は１層を介して、及び示された時間の特定点においてそれが２層の「チェックサム」部分機能に到達した２層上に受渡されるプロトコル・メッセージ信号２に関連する。この方法は現在の提案された枠組と類似しているが、しかしながら大部分のマルチタスク・オペレーティング・システムによって提供される異なる安全性及び性能構造を持つその異なる実行環境は、異なるＬＬＩを区別するのに容易に使用できないという難点があり、その代りに、ＬＬＩに基づいて必要に応じてスレッドを先取するであろうカスタム化スケジューラが実施される必要があるであろう。
累積（accumulate）機能は破線で示されているが、説明を容易にするために上では述べられていない。累積機能がメッセージ当たりスレッド方法で実施されるところでは、二つの実施の可能性がある。一つはスレッドを単に終結させることであるが、しかしながらこれはバッファされたパケットをサービスするためにバッファを監視する別のスレッドに依存する。もう一つは呼出し機能に戻すことであり、実行スレッドは別のメッセージを処理するために使用される。非常に軽量のスレッド・モデルが実行されない限りスレッド生成遅延及びオーバーヘッドがオペレーティング・システム上で非常に高いので、これはスレッドを終結させるより魅力的である。
領域及び他の共有メモリ・オブジェクトと同様に、これはこれらのコード・ブロックを介して様々な実行スタックに関連する実行スタックと共に、二つのコード・ブロック２が作業メモリに示される図２１に図式的に見られる。様々な実行スタックはマイクロプロセッサ・レジスタの現在の状態、機能内の静的データ及びコード・モジュールといった様々なパラメータ及び機能呼出パラメータ受渡しのための様々なパラメータを記憶するであろう。スケジューラ及びスレッド・マネージャは、現在の、もしくは実際のスレッドに関するそれぞれのスタックの適切な内容をマイクロプロセッサ・レジスタにロードし、且つ切替えられた（文脈切替として知られる）スレッドに関する適切なレジスタの内容を記憶することによって、既知の方法で様々なスレッドの操作を制御する。例えば、Ｌ２コード・ブロック中の thread_signal 1 （ＴＳ１）に関する実行点はコードを介して thread_signal 2（ＴＳ２）よりさらに前進したことがわかる-ここで、（ＴＳ１）及び（ＴＳ２）は各スレッドについてのプログラム・カウンタ値を表し、従って、そのスレッドについて次に実行するコード・モジュール中の点を指示する。他の様々な実行スタックはプロトコル・スタックの様々なコード・ブロックＬ１〜Ｌ５を通過する他の信号に関連しているであろう。各スレッドは一つの信号に関連しており、同期的方法においてプロトコル・スタックを経て「それの後に続く（follows it）」ということがわかるであろう。
図２２で例示されるように、さらなる実施例は対照的にＬＬＩごとのスレッドを使用する。Thread_ layer2_LLI#1 は下位層（例えば、１層）から信号またはパケット（プロトコル・メッセージ）を受取った２層またはコード・モジュール内の一つのスレッドに対応する。そのスレッドは層の様々な部分機能（sub-functions）によってこれを処理し、処理された出力（信号、パケットまたはメッセージ）を高位層（例えば、３層）に渡す。そして、それは次のプロトコル・メッセージを処理する準備が整ったその関連する２層の受信メッセージまたは入力機能に返す。同様に、スレッド thread_layer2_LLI#2 は第一のスレッドと同じ層（２層）における、しかし異なるインスタンスまたはＬＬＩにおける個別のパケットまたはプロトコル・メッセージに関連する。示された時間の点で、この第二のスレッドまたは実行点は２層の復号化部分機能に到達した。一度、各スレッドがそのＬＬＩを介してプロトコル・メッセージを処理すると、それはアイドル状態に戻り、低位層から新しいパケットを待つために receive_message オペレーティング・システム機能を呼出す。ＬＬＩを実行する実行環境が個別の物理プロセッサ上に常駐しているとき、ＬＬＩ間のメッセージ受渡しは、包含されるいずれかのＬＬＩからの異なるオペレーティング・システム・スレッドまたは処理（例えば、thread_send_message(x)）を恐らくは用いて、実行環境によって扱われる。receive_message 機能は所定のメッセージ配列内においてメッセージを単に待ち、再生する。同様に、send_message 機能はメッセージを所定のメッセージ配列上に置く。
このスレッドごとのＬＬＩ（thread-per-LLI）方法の以前の方法に対する利点は、おかしな動作をするあらゆるソフトウェア・モジュールが他のＬＬＩの動作に影響を及ぼすことを防ぐ代わりに 、異なる優先権（適切であれば）を持ち、且つ異なる安全基準をもつ異なる実行環境（必要であれば）において動作するように構成されることである。
さらに累積機能は最初の説明を単純化するために破線で示されてきたが、しかしながらプロトコル・スタックに対するこの方法は実際本質的に非同期的であり（即ち、メッセージの累積を持つ）、そしてメッセージ（パケット）が送信機及び受信機の双方にアクセス可能である共通及び永久的方法でバッファされるように非同期的メッセージ受渡しを使用することは利点である。累積が層コード内で当然行われれば（メッセージごとのスレッド法の場合のように）、メッセージ・データは送信機から累積バッファに複製され、その後再びバッファから、そして次の層に複製されなければならない。
永久共有メモリ配列を持つことはメッセージがあらゆるデータ複製を必要としないで配列に配置されることを可能にする。プロトコル・スタック実施における複製作成はよい性能を得るために最小にされなければならない。従って、 send_message 機能が受信者メッセージ配列中のメッセージへ単にポインタを置けば、複製するデータは全くなく、受信者は同じ方法でデータになおアクセスすることができる。他の利点は、一つの層インスタンスＬＬＩが別のＬＬＩによって再構成（置換）されつつあるとき、その配列はまだそこにあり、且つメッセージ・データがまだそこにあり、従って何も失われず、そして何も起こらなかったかのように処理が続くことである。
さらなる利点は、スタックにおけるＬＬＩの更新及び置換の間、更新されないＬＬＩによって処理されるプロトコル・メッセージ（信号）が影響を受けないことである。また、必要ならば、事前実行切替は古いインスタンスに行くことになっているパケットを新しいインスタンスによって使用されるであろう配列へ出力先変更することによって、或いは古いインスタンスを一旦停止することによって達成される（このようにしてパケットを廃棄せずに古いバージョンによってさらなる処理を防ぐ）。パケットは新しいＬＬＩインスタンスに備えて配列に並べられ始めるので、例えば、send_message 及び receive_message 機能が永久共有メモリ待機によって実施され、そして待ち行列が新しいＬＬＩのインスタンス化の前に新しいＬＬＩ版インスタンスの上或いは下のＬＬＩインスタンスに結合メッセージを送信するＣＭによって再連結できれば、これは可能である。新しいＬＬＩのインスタンス化は時間消費になるので、この方法は魅力的であり、例えば、安全でないＬＬＩから安全なＬＬＩ版への切替があれば、安全でない方法におけるパケットの継続的処理はシステムにおける脆弱性を打開するかもしれない。
図２３は図２１に類似のメッセージごとのスレッド方法の図式を示しているが、インスタンスごとのスレッド方法に対応する実行スタックを示す。例えば、二つのスレッドは層２コード・モジュールに関連して示されているが、 しかしながら 各々はＬ２内の異なるプロトコル・メッセージとは対照的に異なるＬ２のインスタンス（ＬＬＩ）に関連している。（ＴＬ２１）、（ＴＬ２２）及び（ＴＬ１１）は各ＬＬＩスレッドに関するコード・モジュールにおけるプログラム・カウンタまたは位置を例示する。
図２４及び２５は実施例におけるアプリケーションについてコード・モジュールに到達するための異なる経路（routes）を例示する。図２４において、供給元はＣ＋＋ソース・コード・プログラムを開発し、それは機能テンプレートにおける一般的機能に対応する一連のポインタを含む一般的実行コード・モジュール・フォーマットに、ソース・コードを変換する「ソース対ポインタ（source-to-pointer）」コンパイラによって編集される。ポインタは前述のように共通データ・フォーマットであり、ＯＳ表またはオブジェクトにおいて対応するオペレーティング・システム特定機能に相対的なメモリ・ポインタである。例えば、create_new_LLI である第一の一般的機能（例えば、Func#1）はＯＳにおける第一のオペレーティング・システム特定機能に対応する。対応するＯＳがメモリのどこにあるかを知って、それはモジュールを実行するので、実行環境はＯＳにおける適切にフォーマットされた実行環境特定機能を指示される。
図２５に示された代わりの配置では、供給元は標準のＣ＋＋コンパイラによって後でプラットホーム特定Ｃ＋＋コード・モジュールに編集される同じＣ＋＋ソース・コード・プログラムを開発する。そして、さらなるコンパイラは上述のような、且つＯＳ（及びいくつかの実施例では、ＶＯＳ）による実行に適した一般的機能ポインタ・コード・モジュールにこのモジュールを変換するために必要とされる。
図２６は上述のいくつかの実施例を使用する実施の例を示す。ブルートゥース機能を持つ端末デバイスは固有言語ソフトウェア層（ソフトウェア層＃１及び＃２）内の標準ブルートゥース・プロトコル・スタックを動かす。ブルートゥース・スタックは、プラットホーム・オペレーティング・システム及び言語非依存プロトコル層が動的に連結されることを可能にするために上述の結合機能性を使用する。二つのプロトコル・スタック・インスタンスが示され、（Instance#1 及び Instance#2）は異なるブルートゥース・サービスを提供するように構成される。例えば、ＬＡＮアクセス形状（profile）インスタンス及びＶｅＩＰ（Veke Over IP）またはブルートゥース網カプセル化形状インスタンス。そして、ＬＡＮアクセス形状は個人のブルートゥース・アクセス点を使用してウェブ閲覧（web browsing）を行うために使用され、ＶｅＩＰは同じ時間に同じアクセス点を経由して電話呼出を行うために使用される。
そして、ブルートゥース・スタックは図２７に示されたようにダウンロードされたＪａｖａ層（層＃３）を使用して新しい形状（profile）へ対応追加することによってカスタム化される。この層は（例えば）安全性または性能の向上または新しいサービス機能性を提供する。Ｊａｖａ層は動的にロードされ、新しい層インスタンス（ＬＬＩ＃１及びＬＬＩ＃２）は利用される実施例によってブルートゥース・スタックを再起動させることを必要としないで現在の固有言語ブルートゥース・スタックに結合される。従って、現在のブルートゥース接続セッションは乱されない。そして、新しい層は端末とアクセス点との間でデータを暗号化及び復号化するために使われる向上した安全性形状をインスタンス化するために使用される。
オペレーティング・システム非依存性に対応するために、プロトコル・スタックの中で他のモジュールと相互に作用するためモジュールの中で使用される必要なプラットホーム特定機能（例えば、共有メモリ割当及びスレッド・メッセージ通信等を可能にする機能）のオペレーティング・システム機能表が使用される。結合メッセージはまた他のモジュールのどちらがそれとの相互作用が許容されるかを決定し、実行環境機構はこれらのソースの信頼性を証明するために存在するであろう。結合メッセージはまたプロトコル層によって必要とされる必要な初期構造データ全てを含まなければならない。
このブルートゥース・スタック内の層は異なる実行スレッドを用いてインスタンス化され、各層はＶＯＳまたはＯＳがＬＬＩの選ばれた実行環境に適切な相互作用の実施を可能にするため、プロトコル・メッセージ入力及び出力としてそれぞれＶＯＳまたはＯＳの receive_message 及び send_message を利用する。スレッドまたは処理は固有のＬＬＩ名によって識別され、それは固有の層名（この場合は「ブルートゥース・スタック層＃３」）及び層インスタンス識別子（この場合は「ＬＬＩ＃１」及び「ＬＬＩ＃２」）から成る。このように、スレッド名は層インスタンスを唯一つ識別するために使用される。ＶＯＳ及びＯＳはＬＬＩとＬＬＩスレッド及び処理の予定計画（scheduling）との間の相互作用に対応するためオペレーティング・システム特定機構を用い、或いは独自の高最適化された機構がまた使われる。これは安全性、性能に関して、或いはメモリ及び消費電力といった資源利用に関しても最適化される。
この方法によってＬＬＩは異なる構造によって生成されることが可能になる。各ＬＬＩはそのＬＬＩが通信するであろう他のＬＬＩだけでなく特定のインスタンスに使用する構造データも識別する結合信号によって結合処理の間に構成される。
ＶＯＳ対応のＬＬＩメッセージ列はプロトコル・スタックがまだ稼働している間、ソフトウェアの動的な更新を可能にするために永久共有メモリに保持される。ＬＬＩの再結合はまた稼働プロトコル・スタックへの層の挿入を容認するために可能である。
新しい層（ブルートゥース・スタック層＃３）をプロトコル・スタックに構成する処理は次の通りである：
１．最初のステップは関連するモジュール入力点を呼出すことによって「ブルートゥース・スタック層＃３」の実行を開始することである。Ｊａｖａモジュールの場合は、クラス・ファイルはＣＭによって選択されたＪＶＭ環境にロードされる。まだロードされていなければ、モジュールは初期設定のＶＯＳまたはＯＳのＡＰＩをロードする。そして、ラン・メソッドはＪＶＭによって自動的に呼出され、層ソフトウェア（モジュール）は続いて構造及びメッセージ・データにアクセスすることができるために load_template 機能を呼出し、結合メッセージを待つために receive_message 機能を呼出す。
２．結合メッセージは必要な構造情報を持つ「ブルートゥース・スタック＃３」スレッドに渡される。そして、そのスレッドはＶＯＳもしくはＯＳの create_new_LLI 機能を呼出すことによって新しいＬＬＩインスタンスを造る。新しいＬＬＩの中で、ＬＬＩ特定ＶＯＳ及び／またはＯＳ表が必要ならばロードされる。スレッド「ブルートゥース・スタック層＃３インスタンス＃１」が生成され、ＯＫ応答が送り返される。新しいＬＬＩはメッセージ及び構造データへのアクセスを可能にするために（異なるテンプレートが必要であれば）一般的 load_template 機能を実行し、次のメッセージを待つために receive_message を呼出す。
３．再結合を確認するためＯＫメッセージによって応答する「ブルートゥース・スタック層＃２インスタンス＃１」への再結合要求メッセージ、及び元来「ホスト・インターネット・スタック」に行くことになっている全ての後続パケットは、ここで「ブルートゥース・スタック層＃２ＬＬＩ＃１」に送られる。
４．「ホスト・インターネット・スタック」への再結合メッセージ及び経路表は更新され、ＯＫ応答が受信される。
５．ＬＬＩ＃１が稼働になり、同じ手順が層＃３ＬＬＩ＃２について繰返される。
Ｊａｖａブルートゥース・スタック層＃３が固有のブルートゥース・スタック層＃２及びホスト・インターネット・スタックと容易に相互運用するために、相互作用及びスレッドと処理の予定計画のための前述の共通ＶＯＳ及び／またはＯＳ支援機構が使用される。プラットホーム無関係な方法においてこの共通機能性にアクセスするために使用される方法は、動的にロード可能なＶＯＳ及び／またはＯＳ機能ライブラリによるものである。
「ブルートゥース・スタック層＃３」がＪＶＭ環境の中でインスタンス化されるとき、初期設定ＶＯＳ及び／またはＯＳライブラリをロードするＪａｖａ呼出が行われる。ＶＯＳ及び／またはＯＳライブラリは一組のシステム資源関係処理機能を含む。これらは最小限として：
・ 信号及びメモリ割付機能
・スレッド生成（及び破壊）機能
・ メッセージ送信及び受信機能
・ 構造及び信号データ・アクセス機能
を含む。
ＶＯＳ及び／またはＯＳ機能ライブラリは（適当なロードテンプレートを使用して）他の ＬＬＩと通信し、且つ構造データにアクセスするために続けて使用される。一般的ＬＬＩ及びＶＯＳ機能はいくつかの異なるオペレーティング・システム上で支援され、多くの異なる言語及び仮想マシン環境からアクセスされる。機能ライブラリはまたメッセージ列、信号及び構造データへのアクセス制御を提供する。例えば、機能ライブラリはＬＬＩ識別子に基づいて構造データへのアクセスを制限することができ、また適切に認可された源（sources）及び目的先（destinations）に送信、及び受信するメッセージの使用を制御することができる。このように、安全な言語そしてオペレーティング・システム非依存プロトコル・スタック実行環境が造られる。
このように、例えば「ブルートゥース・スタック層＃３ＬＬＩ＃１」は暗号化機能設定のある集合によって造られる。これらの設定は「ブルートゥース・スタック層＃３ＬＬＩ＃２」では異なり、結合処理において使用される結合メッセージにおいて定義される。そして、ＬＬＩ＃２がＬＬＩ＃１のパラメータにアクセスすることは不可能で、逆もまた同じであり、ＬＬＩ＃１がＬＬＩ＃２向けのパケットを遮ることは不可能で、逆も同様である。
上述の装置及び方法は、例えばディスク、ＣＤ‐或いはＤＶＤ‐ＲＯＭといった坦持媒体、読取専用メモリのようなプログラム・メモリ（ファームウェア）、または光学または電気信号担体といったデータ担体上のプロセッサ制御コードとして具体化されることを当業者は認識するであろう。多くの応用について、本発明の実施例はＤＳＰ（ディジタル信号プロセッサ）、ＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールド・プログラム可能ゲートアレイ）上で実施されるであろう。このように、コードは従来のプログラム・コードまたはマイクロコードもしくは、例えば、ＡＳＩＣまたはＦＰＧＡを設定、もしくは制御するためのコードを含む。コードはまた再プログラム可能論理ゲートアレイのような再構成可能な装置を動的に構成するコードを含む。同様に、コードはＶｅｒｉｌｏｇ（商標）またはＶＨＤＬ（高速集積回路ハードウェア記述言語）といったハードウェア記述言語のためのコードを含む。当業者は認識するように、コードは相互に通信している複数の接続要素の間で分配される。適切であれば、実施例はまたアナログ用ハードウェアを構成するためにフィールド（再）プログラム可能アナログ・アレイで稼働するコードを使用して実施される。
様々な実施例及びそれらに関して記述された特定の特徴は、前述の教示に一般的に合致する他の実施例またはそれらの特に記述された特徴と自由に組合わすことができることを当業者はまた認識するであろう。様々な変更及び修正は提示された請求項から逸脱することなしに記述された特定の例に行うことができることを当業者はまた認識するであろう。
通信プロトコル・スタックを示す。 図１の通信スタックの概念層を示す。 動的再構成可能通信プロトコル・スタックを実施するための既知のアーキテクチャを示す。 実施例に従って動的再構成可能プロトコル・スタックに関するアーキテクチャを示す。 結合メッセージを例示する。 機能ポインタ表を例示する。 プロトコル・メッセージを例示する。 層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。 層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。 層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。 層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。 実施例に従って多数の層のインスタンス化を例示する。 実施例に従ってプロトコル・スタックにおけるソフトウェア層のインスタンス化及び結合を例示する。 実施例のブロック・コード表現を例示する。 実施例に従って仮想オペレーティング・システムを例示する。 Ｃコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。 Ｃコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。 Ｊａｖａコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。 Ｊａｖａコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。 既知のメッセージ・プロトコルごとのスレッド・アーキテクチャを示す。 図１６及び１７の実施例に関する図式メモリ・アーキテクチャを示す。 実施例に従って層ごとのスレッド・アーキテクチャを例示する。 図２０の実施例に関する図式メモリ・アーキテクチャを示す。 高級ソース・コードを実施例において使用のためのモジュールに編集する方法を示す。 高級ソース・コードを実施例において使用のためのモジュールに編集する方法を示す。 実施例に従ってＢｌｕｅｔｏｏｔｈＴＭの複合プロトコル・スタックの実施例を例示する。 更新されたＢｌｕｅｔｏｏｔｈＴＭプロトコル・スタックを例示する。

Claims (60)

  1. プロセッサ及びメモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法であって、プロトコルは複数のプロトコル層によって定義され、
    ソフトウェア・モジュールをメモリに搭載し、モジュールは前記層の一つに対応する一組の一般的機能に従って前記信号を受信、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
    前記機能写像オブジェクトをメモリに搭載し、オブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する方法。
  2. モジュールは前記信号に対応するプロトコル・メッセージを他のモジュールと交換するように配置され、他のモジュールは他の前記層に対応する一組の一般的機能に従って前記信号を処理するように配置される、請求項１記載の方法。
  3. 前記他のソフトウェア・モジュールをメモリに搭載し、他のモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
    他の各モジュールについて、前記機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って他のモジュールを実行することをさらに含む、請求項２記載の方法。
  4. 別の前記モジュールに関する識別子を含む結合メッセージを受信するその、もしくは各搭載ソフトウェア・モジュールをさらに含み、第一のモジュールは前記結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置された、請求項２または３記載の方法。
  5. モジュールは前記プロトコル・メッセージを処理するための異なる構造オプションを持つ、請求項２乃至４のいずれか1項に記載の方法。
  6. 前記結合メッセージは前記モジュールの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項５記載の方法。
  7. プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである、請求項１乃至６のいずれか1項に記載の方法。
  8. 第二のソフトウェア・モジュールをメモリに搭載し、第二のモジュールは第二の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、第二のモジュールは第二の機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
    前記第二の機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含み、
    前記プロトコル層に従って受信信号を処理するために前記写像された第二の装置特定機能に従って第二のモジュールを実行することをさらに含み、その結果第一及び第二のモジュールが異なる実行環境または装置特定環境において実行される、請求項１乃至７のいずれか1項に記載の方法。
  9. 前記モジュールは言語非依存である、請求項１乃至８のいずれか1項に記載の方法。
  10. 前記層に対応する一般的機能の前記集合に従って前記信号を処理するための高級ソフトウェア言語コードを提供すること、及び前記コードを前記言語非依存ソフトウェア・モジュールにコンパイルすることをさらに含む、請求項９記載の方法。
  11. 前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された装置特定機能に従って第二の実行処理においてモジュールを実行することをさらに含む、請求項１乃至１０のいずれか1項に記載の方法。
  12. 第二の機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含み、及び
    前記第一の実行処理に加えて、前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行することをさらに含み、その結果モジュールの二つのインスタンスが異なる機能写像オブジェクトに従って処理される、請求項１乃至１１のいずれか1項に記載の方法。
  13. 二つの実行処理は異なる実行環境または装置特定環境において実行する、請求項１２記載の方法。
  14. 別の前記モジュールに関する識別子を含む第二の結合メッセージを受信する搭載ソフトウェア・モジュールの第二のインスタンスをさらに含み、第一のモジュールの第二のインスタンスがプロトコル・メッセージを前記第二の結合メッセージによって識別された他のモジュールと交換するように配置される、請求項１２または１３記載の方法。
  15. モジュールは前記プロトコル・メッセージを処理するための各前記インスタンスに関する異なる構造オプションを持ち、各前記結合メッセージは前記それぞれのモジュール・インスタンスの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項１４記載の方法。
  16. その、もしくは各前記モジュールは個別の実行処理において実行される、請求項１乃至１５のいずれか1項に記載の方法。
  17. 各前記実行処理はスレッドである、請求項１４乃至１６のいずれか1項に記載の方法。
  18. プロトコル・メッセージの前記交換はモジュール実行の処理からの個別の実行処理によるものである、請求項２記載の方法。
  19. メッセージはメモリにおける永久メッセージ配列から転記され、且つ回復される、請求項１８記載の方法。
  20. 中間機能写像オブジェクトをメモリに搭載することをさらに含み、そのオブジェクトは前記一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクト中の一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む、請求項１乃至１９のいずれか1項に記載の方法。
  21. プロトコルは通信プロトコル・スタックであり、好ましくは無線通信プロトコル・スタックである、請求項１乃至２０のいずれか1項に記載の方法。
  22. プロセッサ及びメモリを持つ処理装置において信号を処理するための動的に再構成可能なプロトコル・スタックを提供する方法であって、プロトコルは複数のプロトコル層によって定義され、プロトコル・スタックは、
    各モジュールが一以上の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール、
    オブジェクトが前記一般的機能をそれぞれのモジュールにおける一以上の装置特定機能へ写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト、
    前記それぞれのプロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って実行されるモジュールを含み、
    別の前記モジュールに関する識別子を含む結合メッセージを受信する各モジュールを含み、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換するように配置される方法。
  23. 更新ソフトウェア・モジュールをメモリに搭載し、そのモジュールは前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
    前記機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行することをさらに含み、
    モジュールは別の前記モジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換する、請求項２２記載の方法。
  24. プロトコルに従って信号を処理するための方法であって、そのプロトコルは複数のプロトコル層によって定義され、
    前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理し、
    一般的機能を装置特定機能に写像し、
    前記プロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することを含む方法。
  25. 他の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理し、
    一般的機能を装置特定機能に写像し、
    前記他のプロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することをさらに含む、請求項２４記載の方法。
  26. 前記受信及び処理することは前記一般的機能の順序が前記プロトコル・スタックに対応するように配置される、請求項２５記載の方法。
  27. 前記信号を処理することによって前記一般的機能の順序を決定するために結合メッセージを受信することをさらに含む、請求項２６記載の方法。
  28. 各層の一般的機能に従って前記受信及び処理することはソフトウェア・モジュールを実行することによって実施される、請求項２４乃至２７のいずれか1項に記載の方法。
  29. 一般的機能を中間機能に写像し、その後中間機能を装置特定機能に写像することをさらに含む、請求項２４乃至２８のいずれか1項に記載の方法。
  30. 信号を処理するための通信プロトコルを提供する装置であって、その装置はプロセッサ及びメモリを持ち、そのプロトコルは複数のプロトコル層によって定義され、
    モジュールが前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、ソフトウェア・モジュールをメモリに搭載する手段、
    オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、前記機能写像オブジェクトをメモリに搭載する手段、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する手段、を具備する装置。
  31. モジュールは前記信号に対応するプロトコル・メッセージを他のモジュールと交換するように配置され、他のモジュールは他の前記層に対応する一組の一般的機能に従って前記信号を処理するように配置される、請求項３０記載の装置。
  32. 他のモジュールが機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、前記他のソフトウェア・モジュールをメモリに搭載する手段、
    オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、他の各モジュールについて前記機能写像オブジェクトをメモリに搭載する手段、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って他のモジュールを実行する手段をさらに具備する、請求項３１記載の装置。
  33. 別の前記モジュールに関する識別子を含む結合メッセージをその、もしくは各ソフトウェア・モジュールに送る手段をさらに具備し、第一のモジュールは前記結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置される、請求項３１または３２記載の装置。
  34. モジュールは前記プロトコル・メッセージを処理するための異なる構造オプションを持つ、請求項３１乃至３３のいずれか1項に記載の装置。
  35. 前記結合メッセージは前記モジュールの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項３４記載の装置。
  36. プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである、請求項３０乃至３５のいずれか1項に記載の装置。
  37. 第二のモジュールが第二の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、第二のモジュールは第二の機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、第二のソフトウェア・モジュールをメモリに搭載する手段、
    オブジェクトが前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含む、前記第二の機能写像オブジェクトをメモリに搭載する手段、
    前記プロトコル層に従って受信信号を処理するために前記写像された第二の装置特定機能に従って第二のモジュールを実行する手段をさらに具備し、その結果第一及び第二のモジュールが異なる実行環境または装置特定環境において実行される、請求項３０乃至３６のいずれか1項に記載の装置。
  38. 前記モジュールは言語非依存である、請求項３０乃至３７のいずれか1項に記載の装置。
  39. 前記層に対応する一般的機能の前記集合に従って前記信号を処理するための高級ソフトウェア言語コードを提供する手段、及び前記コードを前記言語非依存ソフトウェア・モジュールにコンパイルする手段をさらに具備する、請求項３８記載の装置。
  40. 前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された装置特定機能に従って第二の実行処理においてモジュールを実行する手段をさらに具備する、請求項３０乃至３９のいずれか1項に記載の装置。
  41. オブジェクトが前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含む、第二の機能写像オブジェクトをメモリに搭載する手段、及び
    前記第一の実行手段に加えて、前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行する手段をさらに具備し、その結果モジュールの二つのインスタンスが異なる機能写像オブジェクトに従って処理される、請求項３０乃至４０のいずれか1項に記載の装置。
  42. 二つの実行処理は異なる実行環境または装置特定環境において実行する、請求項４１記載の装置。
  43. 別の前記モジュールに関する識別子を含む第二の結合メッセージを受信する搭載ソフトウェア・モジュールの第二のインスタンスをさらに含み、第一のモジュールの第二のインスタンスがプロトコル・メッセージを前記第二の結合メッセージによって識別された他のモジュールと交換するように配置される、請求項４１または４２記載の装置。
  44. モジュールは前記プロトコル・メッセージを処理するための各前記インスタンスに関する異なる構造オプションを持ち、各前記結合メッセージは前記それぞれのモジュール・インスタンスの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項４３記載の装置。
  45. その、もしくは各前記モジュールは個別の実行処理において実行される、請求項３０乃至４４のいずれか1項に記載の装置。
  46. 各前記実行処理はスレッドである、請求項４３乃至４５のいずれか1項に記載の装置。
  47. 中間機能写像オブジェクトをメモリに搭載する手段をさらに具備し、そのオブジェクトは前記一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクトにおける一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む、請求項３０乃至４６のいずれか1項に記載の装置。
  48. 装置は通信端末、基地局、または網（network）デバイスである、請求項３０乃至４７のいずれか1項に記載の装置。
  49. プロセッサ及びメモリを持つ処理装置において信号を処理するための動的に再構成可能なプロトコル・スタックを提供する装置であって、プロトコルは複数のプロトコル層によって定義され、
    各モジュールが一以上の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール、
    オブジェクトが前記一般的機能をそれぞれのモジュールにおける一以上の装置特定機能へ写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト、
    前記それぞれのプロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って実行される手段、を具備する装置。
  50. 別の前記モジュールに関する識別子を含む結合メッセージを各モジュールに送る手段をさらに具備し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換するように設置される、請求項４９記載の装置。
  51. モジュールが前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、更新ソフトウェア・モジュールをメモリに搭載する手段、
    オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、前記機能写像オブジェクトをメモリに搭載する手段、
    前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する手段をさらに具備し、
    モジュールは別の前記モジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換する、請求項５０記載の装置。
  52. プロトコルに従って信号を処理するための装置であって、プロトコルは複数のプロトコル層によって定義され、
    前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理する手段、
    一般的機能を装置特定機能に写像する手段、
    前記プロトコル層に従って受信信号を処理するために写像された装置特定機能を実行する手段を具備する装置。
  53. 他の前記層に対応する一組の一般的機能に従って前記信号を処理するためにさらに配置され、
    一般的機能を装置特定機能に写像する手段、
    前記他のプロトコル層に従って受信信号を処理するために写像された装置特定機能を実行する手段を具備する、請求項５２記載の装置。
  54. 前記受信及び処理することは前記一般的機能の順序が前記プロトコル・スタックに対応するように配置される、請求項５３記載の装置。
  55. 前記信号を処理することによって前記一般的機能の順序を決定するために結合メッセージを受信する手段をさらに具備する、請求項５４記載の装置。
  56. 各層の一般的機能に従って前記受信及び処理することはソフトウェア・モジュールを実行することによって実施される、請求項５２乃至５５のいずれか1項に記載の装置。
  57. 一般的機能を中間機能に写像し、その後中間機能を装置特定機能に写像する手段をさらに具備する、請求項５２乃至５６のいずれか1項に記載の装置。
  58. 請求項１乃至２９のいずれか1項に従ってその方法を実行するために処理装置を制御するためのプログラム。
  59. 請求項３０乃至５７のいずれか1項に従って構成された構成可能な装置。
  60. 請求項１乃至５７のいずれか1項に従ってその方法を実行するためにプロセッサ制御コードを搭載する担持媒体。
JP2005518549A 2003-10-01 2004-09-30 柔軟なプロトコル・スタック Pending JP2006519518A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0322985A GB2406663B (en) 2003-10-01 2003-10-01 Flexible protocol stack
PCT/JP2004/014785 WO2005034478A1 (en) 2003-10-01 2004-09-30 Flexible protocol stack

Publications (1)

Publication Number Publication Date
JP2006519518A true JP2006519518A (ja) 2006-08-24

Family

ID=29415302

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005518549A Pending JP2006519518A (ja) 2003-10-01 2004-09-30 柔軟なプロトコル・スタック

Country Status (6)

Country Link
US (1) US20050120122A1 (ja)
EP (1) EP1521428A1 (ja)
JP (1) JP2006519518A (ja)
CN (1) CN1701586A (ja)
GB (1) GB2406663B (ja)
WO (1) WO2005034478A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012509531A (ja) * 2008-11-18 2012-04-19 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 組み込みプラットフォームにおけるプログラムの動的リンキング方法および組み込みプラットフォーム
JP2016005284A (ja) * 2014-06-19 2016-01-12 エックスプライアント， インコーポレイテッド 変更のためにパケットを個々のレイヤに分割し、変更後のレイヤを情報処理で継合する方法およびその装置
JP2017505578A (ja) * 2014-01-21 2017-02-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド ソフトウェア・デファインド・プロトコル・ネットワークノードのためのシステムおよび方法
WO2020004270A1 (ja) * 2018-06-26 2020-01-02 日本電信電話株式会社 ネットワーク機器及びネットワーク機器の設定方法

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7468975B1 (en) 2002-05-06 2008-12-23 Foundry Networks, Inc. Flexible method for processing data packets in a network routing system for enhanced efficiency and monitoring capability
US7649885B1 (en) * 2002-05-06 2010-01-19 Foundry Networks, Inc. Network routing system for enhanced efficiency and monitoring capability
US20120155466A1 (en) 2002-05-06 2012-06-21 Ian Edward Davis Method and apparatus for efficiently processing data packets in a computer network
US7187687B1 (en) 2002-05-06 2007-03-06 Foundry Networks, Inc. Pipeline method and system for switching packets
US6901072B1 (en) 2003-05-15 2005-05-31 Foundry Networks, Inc. System and method for high speed packet transmission implementing dual transmit and receive pipelines
US7817659B2 (en) * 2004-03-26 2010-10-19 Foundry Networks, Llc Method and apparatus for aggregating input data streams
US8730961B1 (en) 2004-04-26 2014-05-20 Foundry Networks, Llc System and method for optimizing router lookup
US7535926B1 (en) * 2005-01-07 2009-05-19 Juniper Networks, Inc. Dynamic interface configuration for supporting multiple versions of a communication protocol
US7539205B1 (en) * 2005-01-07 2009-05-26 Juniper Networks, Inc. Service-specific logical interfaces for providing VPN customers access to external multicast content
US8949181B2 (en) * 2005-02-25 2015-02-03 Solarwinds Worldwide, Llc Real-time threshold state analysis
US7716279B2 (en) * 2005-09-21 2010-05-11 Sap Ag WS addressing protocol for web services message processing runtime framework
US7721293B2 (en) * 2005-09-21 2010-05-18 Sap Ag Web services hibernation
US8745252B2 (en) * 2005-09-21 2014-06-03 Sap Ag Headers protocol for use within a web services message processing runtime framework
US7711836B2 (en) * 2005-09-21 2010-05-04 Sap Ag Runtime execution of a reliable messaging protocol
US20070067461A1 (en) * 2005-09-21 2007-03-22 Savchenko Vladimir S Token streaming process for processing web services message body information
US7606921B2 (en) * 2005-09-21 2009-10-20 Sap Ag Protocol lifecycle
US7716360B2 (en) * 2005-09-21 2010-05-11 Sap Ag Transport binding for a web services message processing runtime framework
US7788338B2 (en) * 2005-09-21 2010-08-31 Sap Ag Web services message processing runtime framework
US7761533B2 (en) * 2005-09-21 2010-07-20 Sap Ag Standard implementation container interface for runtime processing of web services messages
US8448162B2 (en) 2005-12-28 2013-05-21 Foundry Networks, Llc Hitless software upgrades
US7808994B1 (en) 2006-02-22 2010-10-05 Juniper Networks, Inc. Forwarding traffic to VLAN interfaces built based on subscriber information strings
US7492766B2 (en) * 2006-02-22 2009-02-17 Juniper Networks, Inc. Dynamic building of VLAN interfaces based on subscriber information strings
GB2438665B (en) * 2006-06-01 2008-10-15 Toshiba Res Europ Ltd A framework for a terminal network protocol reconfiguration
US8238255B2 (en) 2006-11-22 2012-08-07 Foundry Networks, Llc Recovering from failures without impact on data traffic in a shared bus architecture
US8395996B2 (en) 2007-01-11 2013-03-12 Foundry Networks, Llc Techniques for processing incoming failure detection protocol packets
US20080307056A1 (en) * 2007-06-07 2008-12-11 Vladimir Videlov Web Services Reliable Messaging
US8271859B2 (en) 2007-07-18 2012-09-18 Foundry Networks Llc Segmented CRC design in high speed networks
US8458383B1 (en) * 2007-08-30 2013-06-04 Altera Corporation Flexible interface for stacked protocol in a programmable integrated circuit device
US20090064202A1 (en) * 2007-09-04 2009-03-05 Apple, Inc. Support layer for enabling same accessory support across multiple platforms
US8509236B2 (en) 2007-09-26 2013-08-13 Foundry Networks, Llc Techniques for selecting paths and/or trunk ports for forwarding traffic flows
US8959137B1 (en) 2008-02-20 2015-02-17 Altera Corporation Implementing large multipliers in a programmable integrated circuit device
CN102016866B (zh) * 2008-03-04 2014-05-21 苹果公司 基于授予承载商的权利授权在设备上执行软件代码的系统和方法
CN101277301B (zh) * 2008-04-24 2012-04-25 华为技术有限公司 分布式系统的接口调用方法、装置和系统
US8589593B2 (en) * 2009-02-10 2013-11-19 Alcatel Lucent Method and apparatus for processing protocol messages for multiple protocol instances
US8090901B2 (en) * 2009-05-14 2012-01-03 Brocade Communications Systems, Inc. TCAM management approach that minimize movements
US9292702B2 (en) * 2009-08-20 2016-03-22 International Business Machines Corporation Dynamic switching of security configurations
US8230478B2 (en) 2009-08-27 2012-07-24 International Business Machines Corporation Flexibly assigning security configurations to applications
US8599850B2 (en) * 2009-09-21 2013-12-03 Brocade Communications Systems, Inc. Provisioning single or multistage networks using ethernet service instances (ESIs)
KR101770299B1 (ko) * 2011-01-18 2017-09-05 삼성전자주식회사 데이터 전송 방법 및 장치와 데이터 처리 방법 및 장치
WO2012167464A1 (zh) * 2011-07-01 2012-12-13 华为技术有限公司 心跳消息发送方法和心跳代理服务器
US9053045B1 (en) 2011-09-16 2015-06-09 Altera Corporation Computing floating-point polynomials in an integrated circuit device
US8949298B1 (en) 2011-09-16 2015-02-03 Altera Corporation Computing floating-point polynomials in an integrated circuit device
US9098332B1 (en) 2012-06-01 2015-08-04 Altera Corporation Specialized processing block with fixed- and floating-point structures
US8996600B1 (en) 2012-08-03 2015-03-31 Altera Corporation Specialized processing block for implementing floating-point multiplier with subnormal operation support
CN104756078B (zh) * 2012-08-20 2018-07-13 唐纳德·凯文·卡梅伦 处理资源分配的装置和方法
US9207909B1 (en) 2012-11-26 2015-12-08 Altera Corporation Polynomial calculations optimized for programmable integrated circuit device structures
US9189200B1 (en) 2013-03-14 2015-11-17 Altera Corporation Multiple-precision processing block in a programmable integrated circuit device
US20140344467A1 (en) * 2013-05-14 2014-11-20 Honeywell International Inc. Loadable flexible protocol profiles
US9348795B1 (en) 2013-07-03 2016-05-24 Altera Corporation Programmable device using fixed and configurable logic to implement floating-point rounding
US9118809B2 (en) 2013-10-11 2015-08-25 Edifire LLC Methods and systems for multi-factor authentication in secure media-based conferencing
US9262136B2 (en) * 2013-11-07 2016-02-16 Netronome Systems, Inc. Allocate instruction and API call that contain a sybmol for a non-memory resource
CN105282207B (zh) * 2014-07-25 2019-01-22 中国科学院声学研究所 一种基于可拼装通信协议栈的通信方法及系统
US9131112B1 (en) 2014-09-29 2015-09-08 Edifire LLC Dynamic signaling and resource allocation in secure media-based conferencing
US9167098B1 (en) 2014-09-29 2015-10-20 Edifire LLC Dynamic conference session re-routing in secure media-based conferencing
US9282130B1 (en) * 2014-09-29 2016-03-08 Edifire LLC Dynamic media negotiation in secure media-based conferencing
US9137187B1 (en) 2014-09-29 2015-09-15 Edifire LLC Dynamic conference session state management in secure media-based conferencing
US9513978B2 (en) * 2014-10-17 2016-12-06 International Business Machines Corporation Integrated support for application porting transparency and streamlined system migration in heterogeneous platform environments
WO2017084719A1 (en) * 2015-11-20 2017-05-26 Abb Ag Managing communication between gateway and building automation device by installing protocol software in gateway
WO2017214861A1 (en) * 2016-06-14 2017-12-21 SZ DJI Technology Co., Ltd. Supporting protocol independent movable object application development
CN106341419B (zh) * 2016-10-17 2019-04-19 重庆邮电大学 一种调用外接加解密模块的方法及移动终端
DE102018104752A1 (de) * 2018-03-01 2019-09-05 Carl Zeiss Ag Verfahren zum Ausführen und Übersetzen eines Computerprogrammes in einem Rechnerverbund, insbesondere zum Steuern eines Mikroskops
CN111371820A (zh) * 2018-12-25 2020-07-03 上海亮衡信息科技有限公司 一种基于定时器触发的通信方法、系统及通信设备
CN113139176A (zh) * 2020-01-20 2021-07-20 华为技术有限公司 恶意文件的检测方法、装置、设备及存储介质
CN115769668A (zh) * 2020-06-09 2023-03-07 哲库科技有限公司 用于高吞吐量和低延迟数据传输的模块化5gue层2数据栈解决方案

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339430A (en) * 1992-07-01 1994-08-16 Telefonaktiebolaget L M Ericsson System for dynamic run-time binding of software modules in a computer system
US5446736A (en) * 1993-10-07 1995-08-29 Ast Research, Inc. Method and apparatus for connecting a node to a wireless network using a standard protocol
US5448566A (en) * 1993-11-15 1995-09-05 International Business Machines Corporation Method and apparatus for facilitating communication in a multilayer communication architecture via a dynamic communication channel
US5903754A (en) * 1994-06-21 1999-05-11 Microsoft Corporation Dynamic layered protocol stack
US5734822A (en) * 1995-12-29 1998-03-31 Powertv, Inc. Apparatus and method for preprocessing computer programs prior to transmission across a network
US6976080B1 (en) * 1998-03-27 2005-12-13 Hewlett-Packard Development Company, L.P. Multiple-protocol communication subsystem controller
WO2002028052A2 (en) * 2000-09-28 2002-04-04 Koninklijke Philips Electronics N.V. Wireless network interface
US7526577B2 (en) * 2003-09-19 2009-04-28 Microsoft Corporation Multiple offload of network state objects with support for failover events

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012509531A (ja) * 2008-11-18 2012-04-19 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 組み込みプラットフォームにおけるプログラムの動的リンキング方法および組み込みプラットフォーム
US8499291B2 (en) 2008-11-18 2013-07-30 Tencent Technology (Shenzhen) Company Limited Method for dynamically linking program on embedded platform and embedded platform
JP2017505578A (ja) * 2014-01-21 2017-02-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド ソフトウェア・デファインド・プロトコル・ネットワークノードのためのシステムおよび方法
US10644941B2 (en) 2014-01-21 2020-05-05 Huawei Technologies Co., Ltd. System and method for a software defined protocol network node
JP2016005284A (ja) * 2014-06-19 2016-01-12 エックスプライアント， インコーポレイテッド 変更のためにパケットを個々のレイヤに分割し、変更後のレイヤを情報処理で継合する方法およびその装置
WO2020004270A1 (ja) * 2018-06-26 2020-01-02 日本電信電話株式会社 ネットワーク機器及びネットワーク機器の設定方法
JP2020005042A (ja) * 2018-06-26 2020-01-09 日本電信電話株式会社 ネットワーク機器及びネットワーク機器の設定方法

Also Published As

Publication number Publication date
GB0322985D0 (en) 2003-11-05
GB2406663A (en) 2005-04-06
EP1521428A1 (en) 2005-04-06
WO2005034478A1 (en) 2005-04-14
US20050120122A1 (en) 2005-06-02
GB2406663B (en) 2006-03-22
CN1701586A (zh) 2005-11-23

Similar Documents

Publication Publication Date Title
JP4271234B2 (ja) 修正関数を有するプロトコルスタック
JP2006519518A (ja) 柔軟なプロトコル・スタック
US11146665B2 (en) Methods and apparatus for sharing and arbitration of host stack information with user space communication stacks
EP1680900B1 (en) Configurable protocol engine
US8769127B2 (en) Cross-domain solution (CDS) collaborate-access-browse (CAB) and assured file transfer (AFT)
RU2536347C2 (ru) Способы и системы реализации физического устройства для дифференциации множества виртуальных машин системы хост-компьютера
US20070011332A1 (en) Dynamically adding application logic and protocol adapters to a programmable network element
CN113556359B (zh) 一种通讯协议转换方法、设备、系统及网关设备
CN116917853A (zh) 网络接口设备
Tennenhouse et al. Toward an active network architecture
Salz et al. {TESLA}: A Transparent, Extensible {Session-Layer} Architecture for End-to-end Network Services
US11966351B2 (en) Network interface device
EP2055073B1 (en) Interface module
KR100914308B1 (ko) 티씨피 처리 시스템 및 그 제어방법
Chimata Path of a packet in the linux kernel stack
US11960596B2 (en) Network interface device
Hlavatý Network Interface Controller Offloading in Linux
Patel Active network technology
Rouhana et al. Yaap: Yet another active platform
Kawashima et al. FreeNA: A multi-platform framework for inserting upper-layer network services
川島龍太 et al. A study on a framework for transparently extending networking services for adaptive communications
Cook The design and evaluation of a multiple-language active network architecture enabled via middleware
WO2017085685A1 (en) Packet processing execution environment
GB2436420A (en) Reconfigurable communications apparatus

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080219

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080701