(57)【要約】本発明は特に、しかしそれに限らず、携帯電話、ラップトップ・コンピュータ、及び基地局といった通信端末のためのプロトコル・スタック及びプロトコル・スタック内のプロトコル層に関係する。本発明はプロセッサ及びメモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法を提供し、プロトコルは複数のプロトコル層によって定義され、その方法はソフトウェア・モジュールをメモリに搭載し、そのモジュールは前記層の一つに対応する一組の一般的機能に従って信号を受信し、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、機能写像オブジェクトをメモリに搭載し、そのオブジェクトは一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、プロトコル層に従って受信信号を処理するために写像された装置特定機能に従ってモジュールを実行することを含む。
2006519518.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサ及びメモリを持つ処理装置において信号を処理するための通信プロトコルを提供する方法であって、プロトコルは複数のプロトコル層によって定義され、
ソフトウェア・モジュールをメモリに搭載し、モジュールは前記層の一つに対応する一組の一般的機能に従って前記信号を受信、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
前記機能写像オブジェクトをメモリに搭載し、オブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する方法。
【請求項２】
モジュールは前記信号に対応するプロトコル・メッセージを他のモジュールと交換するように配置され、他のモジュールは他の前記層に対応する一組の一般的機能に従って前記信号を処理するように配置される、請求項１記載の方法。
【請求項３】
前記他のソフトウェア・モジュールをメモリに搭載し、他のモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
他の各モジュールについて、前記機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って他のモジュールを実行することをさらに含む、請求項２記載の方法。
【請求項４】
別の前記モジュールに関する識別子を含む結合メッセージを受信するその、もしくは各搭載ソフトウェア・モジュールをさらに含み、第一のモジュールは前記結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置された、請求項２または３記載の方法。
【請求項５】
モジュールは前記プロトコル・メッセージを処理するための異なる構造オプションを持つ、請求項２乃至４のいずれか1項に記載の方法。
【請求項６】
前記結合メッセージは前記モジュールの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項５記載の方法。
【請求項７】
プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである、請求項１乃至６のいずれか1項に記載の方法。
【請求項８】
第二のソフトウェア・モジュールをメモリに搭載し、第二のモジュールは第二の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、第二のモジュールは第二の機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
前記第二の機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含み、
前記プロトコル層に従って受信信号を処理するために前記写像された第二の装置特定機能に従って第二のモジュールを実行することをさらに含み、その結果第一及び第二のモジュールが異なる実行環境または装置特定環境において実行される、請求項１乃至７のいずれか1項に記載の方法。
【請求項９】
前記モジュールは言語非依存である、請求項１乃至８のいずれか1項に記載の方法。
【請求項１０】
前記層に対応する一般的機能の前記集合に従って前記信号を処理するための高級ソフトウェア言語コードを提供すること、及び前記コードを前記言語非依存ソフトウェア・モジュールにコンパイルすることをさらに含む、請求項９記載の方法。
【請求項１１】
前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された装置特定機能に従って第二の実行処理においてモジュールを実行することをさらに含む、請求項１乃至１０のいずれか1項に記載の方法。
【請求項１２】
第二の機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含み、及び
前記第一の実行処理に加えて、前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行することをさらに含み、その結果モジュールの二つのインスタンスが異なる機能写像オブジェクトに従って処理される、請求項１乃至１１のいずれか1項に記載の方法。
【請求項１３】
二つの実行処理は異なる実行環境または装置特定環境において実行する、請求項１２記載の方法。
【請求項１４】
別の前記モジュールに関する識別子を含む第二の結合メッセージを受信する搭載ソフトウェア・モジュールの第二のインスタンスをさらに含み、第一のモジュールの第二のインスタンスがプロトコル・メッセージを前記第二の結合メッセージによって識別された他のモジュールと交換するように配置される、請求項１２または１３記載の方法。
【請求項１５】
モジュールは前記プロトコル・メッセージを処理するための各前記インスタンスに関する異なる構造オプションを持ち、各前記結合メッセージは前記それぞれのモジュール・インスタンスの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項１４記載の方法。
【請求項１６】
その、もしくは各前記モジュールは個別の実行処理において実行される、請求項１乃至１５のいずれか1項に記載の方法。
【請求項１７】
各前記実行処理はスレッドである、請求項１４乃至１６のいずれか1項に記載の方法。
【請求項１８】
プロトコル・メッセージの前記交換はモジュール実行の処理からの個別の実行処理によるものである、請求項２記載の方法。
【請求項１９】
メッセージはメモリにおける永久メッセージ配列から転記され、且つ回復される、請求項１８記載の方法。
【請求項２０】
中間機能写像オブジェクトをメモリに搭載することをさらに含み、そのオブジェクトは前記一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクト中の一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む、請求項１乃至１９のいずれか1項に記載の方法。
【請求項２１】
プロトコルは通信プロトコル・スタックであり、好ましくは無線通信プロトコル・スタックである、請求項１乃至２０のいずれか1項に記載の方法。
【請求項２２】
プロセッサ及びメモリを持つ処理装置において信号を処理するための動的に再構成可能なプロトコル・スタックを提供する方法であって、プロトコルは複数のプロトコル層によって定義され、プロトコル・スタックは、
各モジュールが一以上の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール、
オブジェクトが前記一般的機能をそれぞれのモジュールにおける一以上の装置特定機能へ写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト、
前記それぞれのプロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って実行されるモジュールを含み、
別の前記モジュールに関する識別子を含む結合メッセージを受信する各モジュールを含み、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換するように配置される方法。
【請求項２３】
更新ソフトウェア・モジュールをメモリに搭載し、そのモジュールは前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含み、
前記機能写像オブジェクトをメモリに搭載し、そのオブジェクトは前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含み、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行することをさらに含み、
モジュールは別の前記モジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換する、請求項２２記載の方法。
【請求項２４】
プロトコルに従って信号を処理するための方法であって、そのプロトコルは複数のプロトコル層によって定義され、
前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理し、
一般的機能を装置特定機能に写像し、
前記プロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することを含む方法。
【請求項２５】
他の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理し、
一般的機能を装置特定機能に写像し、
前記他のプロトコル層に従って受信信号を処理するために写像された装置特定機能を実行することをさらに含む、請求項２４記載の方法。
【請求項２６】
前記受信及び処理することは前記一般的機能の順序が前記プロトコル・スタックに対応するように配置される、請求項２５記載の方法。
【請求項２７】
前記信号を処理することによって前記一般的機能の順序を決定するために結合メッセージを受信することをさらに含む、請求項２６記載の方法。
【請求項２８】
各層の一般的機能に従って前記受信及び処理することはソフトウェア・モジュールを実行することによって実施される、請求項２４乃至２７のいずれか1項に記載の方法。
【請求項２９】
一般的機能を中間機能に写像し、その後中間機能を装置特定機能に写像することをさらに含む、請求項２４乃至２８のいずれか1項に記載の方法。
【請求項３０】
信号を処理するための通信プロトコルを提供する装置であって、その装置はプロセッサ及びメモリを持ち、そのプロトコルは複数のプロトコル層によって定義され、
モジュールが前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、ソフトウェア・モジュールをメモリに搭載する手段、
オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、前記機能写像オブジェクトをメモリに搭載する手段、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する手段、を具備する装置。
【請求項３１】
モジュールは前記信号に対応するプロトコル・メッセージを他のモジュールと交換するように配置され、他のモジュールは他の前記層に対応する一組の一般的機能に従って前記信号を処理するように配置される、請求項３０記載の装置。
【請求項３２】
他のモジュールが機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、前記他のソフトウェア・モジュールをメモリに搭載する手段、
オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、他の各モジュールについて前記機能写像オブジェクトをメモリに搭載する手段、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って他のモジュールを実行する手段をさらに具備する、請求項３１記載の装置。
【請求項３３】
別の前記モジュールに関する識別子を含む結合メッセージをその、もしくは各ソフトウェア・モジュールに送る手段をさらに具備し、第一のモジュールは前記結合メッセージによって識別された他のモジュールとプロトコル・メッセージを交換するように配置される、請求項３１または３２記載の装置。
【請求項３４】
モジュールは前記プロトコル・メッセージを処理するための異なる構造オプションを持つ、請求項３１乃至３３のいずれか1項に記載の装置。
【請求項３５】
前記結合メッセージは前記モジュールの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項３４記載の装置。
【請求項３６】
プロトコル・メッセージ、結合メッセージ及び一般的機能ポインタは共通の一般的フォーマットである、請求項３０乃至３５のいずれか1項に記載の装置。
【請求項３７】
第二のモジュールが第二の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように構成され、第二のモジュールは第二の機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、第二のソフトウェア・モジュールをメモリに搭載する手段、
オブジェクトが前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含む、前記第二の機能写像オブジェクトをメモリに搭載する手段、
前記プロトコル層に従って受信信号を処理するために前記写像された第二の装置特定機能に従って第二のモジュールを実行する手段をさらに具備し、その結果第一及び第二のモジュールが異なる実行環境または装置特定環境において実行される、請求項３０乃至３６のいずれか1項に記載の装置。
【請求項３８】
前記モジュールは言語非依存である、請求項３０乃至３７のいずれか1項に記載の装置。
【請求項３９】
前記層に対応する一般的機能の前記集合に従って前記信号を処理するための高級ソフトウェア言語コードを提供する手段、及び前記コードを前記言語非依存ソフトウェア・モジュールにコンパイルする手段をさらに具備する、請求項３８記載の装置。
【請求項４０】
前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された装置特定機能に従って第二の実行処理においてモジュールを実行する手段をさらに具備する、請求項３０乃至３９のいずれか1項に記載の装置。
【請求項４１】
オブジェクトが前記一般的機能を一以上の第二の装置特定機能に写像するために一般的機能に対応する第二の装置特定機能ポインタを含む、第二の機能写像オブジェクトをメモリに搭載する手段、及び
前記第一の実行手段に加えて、前記プロトコル層に従って受信信号を処理するために、且つ前記モジュールの二つの論理インスタンスを提供するために前記写像された第二の装置特定機能に従って第二の実行処理においてモジュールを実行する手段をさらに具備し、その結果モジュールの二つのインスタンスが異なる機能写像オブジェクトに従って処理される、請求項３０乃至４０のいずれか1項に記載の装置。
【請求項４２】
二つの実行処理は異なる実行環境または装置特定環境において実行する、請求項４１記載の装置。
【請求項４３】
別の前記モジュールに関する識別子を含む第二の結合メッセージを受信する搭載ソフトウェア・モジュールの第二のインスタンスをさらに含み、第一のモジュールの第二のインスタンスがプロトコル・メッセージを前記第二の結合メッセージによって識別された他のモジュールと交換するように配置される、請求項４１または４２記載の装置。
【請求項４４】
モジュールは前記プロトコル・メッセージを処理するための各前記インスタンスに関する異なる構造オプションを持ち、各前記結合メッセージは前記それぞれのモジュール・インスタンスの実行においていずれの前記構造オプションを実施すべきかを決定するための識別子を含む、請求項４３記載の装置。
【請求項４５】
その、もしくは各前記モジュールは個別の実行処理において実行される、請求項３０乃至４４のいずれか1項に記載の装置。
【請求項４６】
各前記実行処理はスレッドである、請求項４３乃至４５のいずれか1項に記載の装置。
【請求項４７】
中間機能写像オブジェクトをメモリに搭載する手段をさらに具備し、そのオブジェクトは前記一般的機能を一以上の中間機能ポインタに、且つさらに第一の機能写像オブジェクトにおける一以上の装置特定機能に写像するために一般的機能に対応する中間機能ポインタ及び第一の機能写像オブジェクト中に一以上の装置特定機能を含む、請求項３０乃至４６のいずれか1項に記載の装置。
【請求項４８】
装置は通信端末、基地局、または網（network）デバイスである、請求項３０乃至４７のいずれか1項に記載の装置。
【請求項４９】
プロセッサ及びメモリを持つ処理装置において信号を処理するための動的に再構成可能なプロトコル・スタックを提供する装置であって、プロトコルは複数のプロトコル層によって定義され、
各モジュールが一以上の前記層に対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールはそれぞれの機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、メモリに搭載されたいくつかのソフトウェア・モジュール、
オブジェクトが前記一般的機能をそれぞれのモジュールにおける一以上の装置特定機能へ写像するために一般的機能に対応する装置特定機能ポインタを含む、メモリに搭載されたいくつかの機能写像オブジェクト、
前記それぞれのプロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従って実行される手段、を具備する装置。
【請求項５０】
別の前記モジュールに関する識別子を含む結合メッセージを各モジュールに送る手段をさらに具備し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換するように設置される、請求項４９記載の装置。
【請求項５１】
モジュールが前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理するように配置され、そのモジュールは機能写像オブジェクト中に前記一般的機能に対応する一般的機能ポインタを含む、更新ソフトウェア・モジュールをメモリに搭載する手段、
オブジェクトが前記一般的機能を一以上の装置特定機能に写像するために一般的機能に対応する装置特定機能ポインタを含む、前記機能写像オブジェクトをメモリに搭載する手段、
前記プロトコル層に従って受信信号を処理するために前記写像された装置特定機能に従ってモジュールを実行する手段をさらに具備し、
モジュールは別の前記モジュールに関する識別子を含む結合メッセージを受信し、受信モジュールはプロトコル・メッセージをそれぞれの結合メッセージによって識別された他のモジュールと交換する、請求項５０記載の装置。
【請求項５２】
プロトコルに従って信号を処理するための装置であって、プロトコルは複数のプロトコル層によって定義され、
前記層の一つに対応する一組の一般的機能に従って前記信号を受信し、且つ処理する手段、
一般的機能を装置特定機能に写像する手段、
前記プロトコル層に従って受信信号を処理するために写像された装置特定機能を実行する手段を具備する装置。
【請求項５３】
他の前記層に対応する一組の一般的機能に従って前記信号を処理するためにさらに配置され、
一般的機能を装置特定機能に写像する手段、
前記他のプロトコル層に従って受信信号を処理するために写像された装置特定機能を実行する手段を具備する、請求項５２記載の装置。
【請求項５４】
前記受信及び処理することは前記一般的機能の順序が前記プロトコル・スタックに対応するように配置される、請求項５３記載の装置。
【請求項５５】
前記信号を処理することによって前記一般的機能の順序を決定するために結合メッセージを受信する手段をさらに具備する、請求項５４記載の装置。
【請求項５６】
各層の一般的機能に従って前記受信及び処理することはソフトウェア・モジュールを実行することによって実施される、請求項５２乃至５５のいずれか1項に記載の装置。
【請求項５７】
一般的機能を中間機能に写像し、その後中間機能を装置特定機能に写像する手段をさらに具備する、請求項５２乃至５６のいずれか1項に記載の装置。
【請求項５８】
請求項１乃至２９のいずれか1項に従ってその方法を実行するために処理装置を制御するためのプログラム。
【請求項５９】
請求項３０乃至５７のいずれか1項に従って構成された構成可能な装置。
【請求項６０】
請求項１乃至５７のいずれか1項に従ってその方法を実行するためにプロセッサ制御コードを搭載する担持媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は特に、しかしそれに限らないが、携帯電話、ラップトップ・コンピュータ、及び基地局といった通信端末のためのプロトコル・スタック及びプロトコル・スタック内のプロトコル層に関係する。
【背景技術】
【０００２】
携帯電話、ラップトップ・コンピュータ及び基地局といった通信デバイスは、(潜在的に同時に) 潜在的に異なる任意の機能に対応する多数の無線アクセス網規格に対応可能にするために、異なる構成を持つ多数のプロトコル・スタックにますます対応する必要がある。例えば、ラップトップ・コンピュータは無線構内通信網（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）に階層的に、もしくは所望の要素を設置するために必要な検索時間を最小にするためのデータ・アレイの中に連続して配置することができる。
【０１２４】
プログラミング言語に無関係なデータ・テンプレート定義の例はそれぞれ拡張可能マークアップ言語 （ＸＭＬ）スキーマまたは抽象構文表記（ＡＳＮ）タグまたはデータ系列定義である。データ要素（或いは、属性）アクセス機能は下記の表に示されるように、アクセス特性を向上させるために、データ要素系列内の実際の項目にアクセスするために間接法（メモリ・ポインタ）を利用することができる。このように、データ要素の分解はテンプレートにおいて定義されたように検索操作、及び必要なデータ・フォーマットへの結果の鋳込みまたは変換になる。
【０１２５】
【表１】
2006519518.tif 000003
ここで例ＡＳＮ‐１定義は：
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）に送信、及び受信するメッセージの使用を制御することができる。このように、安全な言語そしてオペレーティング・システム非依存プロトコル・スタック実行環境が造られる。
【０１９９】
このように、例えば「ブルートゥース・スタック層＃３ＬＬＩ＃１」は暗号化機能設定のある集合によって造られる。これらの設定は「ブルートゥース・スタック層＃３ＬＬＩ＃２」では異なり、結合処理において使用される結合メッセージにおいて定義される。そして、ＬＬＩ＃２がＬＬＩ＃１のパラメータにアクセスすることは不可能で、逆もまた同じであり、ＬＬＩ＃１がＬＬＩ＃２向けのパケットを遮ることは不可能で、逆も同様である。
【０２００】
上述の装置及び方法は、例えばディスク、ＣＤ‐或いはＤＶＤ‐ＲＯＭといった坦持媒体、読取専用メモリのようなプログラム・メモリ（ファームウェア）、または光学または電気信号担体といったデータ担体上のプロセッサ制御コードとして具体化されることを当業者は認識するであろう。多くの応用について、本発明の実施例はＤＳＰ（ディジタル信号プロセッサ）、ＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールド・プログラム可能ゲートアレイ）上で実施されるであろう。このように、コードは従来のプログラム・コードまたはマイクロコードもしくは、例えば、ＡＳＩＣまたはＦＰＧＡを設定、もしくは制御するためのコードを含む。コードはまた再プログラム可能論理ゲートアレイのような再構成可能な装置を動的に構成するコードを含む。同様に、コードはＶｅｒｉｌｏｇ（商標）またはＶＨＤＬ（高速集積回路ハードウェア記述言語）といったハードウェア記述言語のためのコードを含む。当業者は認識するように、コードは相互に通信している複数の接続要素の間で分配される。適切であれば、実施例はまたアナログ用ハードウェアを構成するためにフィールド（再）プログラム可能アナログ・アレイで稼働するコードを使用して実施される。
【０２０１】
様々な実施例及びそれらに関して記述された特定の特徴は、前述の教示に一般的に合致する他の実施例またはそれらの特に記述された特徴と自由に組合わすことができることを当業者はまた認識するであろう。様々な変更及び修正は提示された請求項から逸脱することなしに記述された特定の例に行うことができることを当業者はまた認識するであろう。
【図面の簡単な説明】
【０２０２】
【図１】通信プロトコル・スタックを示す。
【図２】図１の通信スタックの概念層を示す。
【図３】動的再構成可能通信プロトコル・スタックを実施するための既知のアーキテクチャを示す。
【図４】実施例に従って動的再構成可能プロトコル・スタックに関するアーキテクチャを示す。
【図５】結合メッセージを例示する。
【図６】機能ポインタ表を例示する。
【図７】プロトコル・メッセージを例示する。
【図８】層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。
【図９】層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。
【図１０】層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。
【図１１】層ソフトウェア及びオペレーティング・システム特定写像オブジェクトの実施例を例示する。
【図１２】実施例に従って多数の層のインスタンス化を例示する。
【図１３】実施例に従ってプロトコル・スタックにおけるソフトウェア層のインスタンス化及び結合を例示する。
【図１４】実施例のブロック・コード表現を例示する。
【図１５】実施例に従って仮想オペレーティング・システムを例示する。
【図１６】Ｃコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。
【図１７】Ｃコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。
【図１８】Ｊａｖａコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。
【図１９】Ｊａｖａコードに関して、既知の動的連結方法及びオペレーティング・システム機能表受渡し法を示す。
【図２０】既知のメッセージ・プロトコルごとのスレッド・アーキテクチャを示す。
【図２１】図１６及び１７の実施例に関する図式メモリ・アーキテクチャを示す。
【図２２】実施例に従って層ごとのスレッド・アーキテクチャを例示する。
【図２３】図２０の実施例に関する図式メモリ・アーキテクチャを示す。
【図２４】高級ソース・コードを実施例において使用のためのモジュールに編集する方法を示す。
【図２５】高級ソース・コードを実施例において使用のためのモジュールに編集する方法を示す。
【図２６】実施例に従ってＢｌｕｅｔｏｏｔｈＴＭの複合プロトコル・スタックの実施例を例示する。
【図２７】更新されたＢｌｕｅｔｏｏｔｈＴＭプロトコル・スタックを例示する。
【図１】
2006519518.tif 000004
【図２】
2006519518.tif 000005
【図３】
2006519518.tif 000006
【図４】
2006519518.tif 000007
【図５】
2006519518.tif 000008
【図６】
2006519518.tif 000009
【図７】
2006519518.tif 000010
【図８】
2006519518.tif 000011
【図９】
2006519518.tif 000012
【図１０】
2006519518.tif 000013
【図１１】
2006519518.tif 000014
【図１２】
2006519518.tif 000015
【図１３】
2006519518.tif 000016
【図１４】
2006519518.tif 000017
【図１５】
2006519518.tif 000018
【図１６】
2006519518.tif 000019
【図１７】
2006519518.tif 000020
【図１８】
2006519518.tif 000021
【図１９】
2006519518.tif 000022
【図２０】
2006519518.tif 000023
【図２１】
2006519518.tif 000024
【図２２】
2006519518.tif 000025
【図２３】
2006519518.tif 000026
【図２４】
2006519518.tif 000027
【図２５】
2006519518.tif 000028
【図２６】
2006519518.tif 000029
【図２７】
2006519518.tif 000030
【国際調査報告】
2006519518.tif 000031
2006519518.tif 000032
2006519518.tif 000033