JP4981444B2 - プロセッサ間通信プロトコル - Google Patents

Description

本発明は一般的に電子分野に関し、特には、プロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。

ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の、多くのネットワーク要素（部品）からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信（ＩＰＣ）と呼ばれる。

近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。ＩＰＣの一例はＰＣＩＡＧＰコントローラ（ＰＡＣ）であって、Ｈｏｓｔ‐ｔｏ‐ＰＣＩブリッジ、ＤＲＡＭコントローラ、およびデータ経路とＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）インターフェイスを集積する。ＩＰＣの別例はＯＭＡＰ（登録商標）プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル（物理層）では設計自由度はほとんどない。

例えば、ＰＡＣプラットフォームは閉構造で、オペレーティング・システムのＴＡＰＩ層に埋め込まれており、ＩＰＣコードは開発者にはアクセスできない。従って、これらのプラットフォームは部品システムには拡張しないので、ＩＰＣ源の動的割り当てをできないだけでなく、ＩＰＣ源の動的割り当て、ハードウェア・サポート機能、マルチノード・ルーチングをできない。

リアルタイム処理アプリケーション等のアプリケーションにおける１つの問題は、異なるプロセッサ上のサービスの発見及びＩＰＣ要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する１つの側面は、無線通信装置における移動体アプリケーション（ＭＡ）等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにＩＰＣデータを輸送し、そして、そのデータを対象のMAに再度ルーチングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう１つの側面は、専用リンク（ポート）を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るＩＰＣプロトコルに対するニーズが、当分野に存在する。

本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。

本明細書は、本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
ＩＰＣは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ（ＡＰ）及びベースバンドプロセッサ（ＢＰ）が含まれる無線通信装置に用いる二重プロセッサ（又は多重プロセッサ）無線アーキテクチャにおいて、ＩＰＣは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。ＩＰＣは、ＡＰ又はＢＰの設計に何らかの制約を課すことなく、このサポートを提供する。

ＩＰＣをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、ＩＰＣにより、その２つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、ＩＰＣは、異なるプロセッサ間において信頼性の高い通信を提供する。

ＩＰＣハードウェアは、異なるプロセッサをＩＰＣネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。ＩＰＣネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる（例えば、ＩＰＣアドレス）。また、データパケットは、本発明の一実施形態におけるＩＰＣネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する必要がある。また、好適には、パケットは、従来の周期的冗長検査（ＣＲＣ）手法を用いて、エラーが無いかチェックされる。本発明のＩＰＣネットワークのネットワークアクティビティは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ネットワーク等のＩＰトランスポート層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のＩＰＣは、ＴＣＰ／ＩＰネットワークのようにゲートウェイにより小規模なネットワークに分割されない。

次に、図１において、本発明の実施形態に基づくＩＰＣネットワーク１００を示す。ＩＰＣネットワーク１００には、複数のＩＰＣクライアント１０２−１０６と、幾つかの実例として、共有メモリ１１０、ユニバーサル非同期受信機／送信機（ＵＡＲＴ）１１２及びユニバーサル・シリアル・バス（ＵＳＢ）１１４等の異なるＩＰＣ物理リンクを用いて、ＩＰＣクライアント１０２−１０６に接続されたＩＰＣサーバ１０８とが含まれる。本発明のＩＰＣにより、ＩＰＣクライアント１０２−１０６は、現ＩＰＣサーバ１０８と折衝して役割を交替し得ることに留意されたい。ＩＰＣクライアント１０２−１０６が、ＩＰＣサーバになるように折衝して新しいＩＰＣサーバになる場合、残りの全てのＩＰＣクライアントは、ＩＰＣサーバの変更があった場合、サーバのＩＰＣアドレスを変更するように指示される。

図２において、本発明の実施形態に基づくＩＰＣサーバ１０８（又はＩＰＣクライアント１０２−１０８）のＩＰＣスタック２００を示す。ＩＰＣスタック２００は、オペレーティングシステム（ＯＳ）の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズへのサポートを提供するように設計されている。ＩＰＣスタックは、次の３つの主な層から構成される。即ち、
（１）ＩＰＣプレゼンテーション・マネージャ（２０２）：この層は、異なるシステムコンポーネント（例えば、ソフトウェア・スレッド）間においてあるデータタイプを他の異なるデータタイプに変換するために用いられる。

（２）ＩＰＣセッション・マネージャ（２０４）：この層は、ＩＰＣスタックと全システムコンポーネントとの間における全着信／発信ＩＰＣトラフィック用の中央収納場所である。ＩＰＣセッション・マネージャ２０４は、幾つかの機能を有する。即ち、ＩＰＣコンポーネントを参加させるためのコンポーネントＩＤの割当て；ＩＰＣデータをカプセル化する必要があるかどうかの判断；ＩＰＣデータのルーチング、ＩＰＣトラフィックの終止；ＩＰＣプロセッサ用のプレースホルダ；ＩＰＣアドレスの提供、ＩＰＣクライアントの割当及び認証等を有する。

ＩＰＣトランスポート層（２０８）：ＩＰＣセッション・マネージャ（層）２０４内に配置される。ＩＰＣトランスポート層２０８は、異なるプロセッサ間において、ＩＰＣデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、ＩＰＣトランスポート層２０８は、ＩＰＣメッセージを、ＩＰＣネットワーク１００上のそれらの最終宛先にルーチングする役割を担う。トランスポート層のルーチング機能は、ＩＰＣサーバ上でのみ使用可能である。

ＩＰＣルータブロック（２１０）：宛先コンポーネント（図示せず）にＩＰＣデータを輸送する。着信ＩＰＣメッセージは、とりわけ、発生元コンポーネントＩＤや、音声及びモデム等のＩＰＣメッセージＯＰコードを搬送する。本発明の実施形態によれば、固有のＯＰコードが、ＩＰＣネットワークに接続された音声及びモデム等の各コンポーネント／ソフトウェア・スレッドに割り当てられることに留意されたい（例えば、図５の５０２参照）。ＩＰＣセッション・マネージャ２０４は、ルータブロック２１０に依拠して、ＩＰＣデータを正しいコンポーネント（１つ又は複数）に送る。

（３）デバイス・インターフェイス層（２０６）：ＩＰＣ物理対論理ＩＰＣチャネルを管理する役割を果たす。その主な機能は、スタックＩＰＣがハードウェアに依存しなくなるように、ＩＰＣハードウェアを完全に抽象化することである。デバイス・インターフェイス層２０６は、直下のＩＰＣリンクの物理帯域幅を管理して全ＩＰＣ論理チャネルをサポートする。着信経路において、デバイス・インターフェイス層２０６は、異なる物理チャネル１１０−１１４からデータを受信して、そのデータを残りのＩＰＣスタックに渡す。発信経路上では、デバイス・インターフェイス層２０６は、ＩＰＣ論理チャネルのデータローディングを、データを適切な物理チャネル上に送ることによって管理する。また、デバイス・インターフェイス層２０６は、同じＩＰＣチャネルに属するＩＰＣパケットの連結を行い、その後、それらをＩＰＣハードウェアに送る。チャネル要件は、ＩＰＣセッション・マネージャ２０４とＩＰＣデバイス・インターフェイス層２０６との間で事前に折衝される。デバイス・インターフェイス層２０６は、ハードウェアポートを備え、これは、ＩＰＣクライアント１０２−１０６とのデバイス・インターフェイスを提供する。

図３において、ＩＰＣコンポーネントＩＤ割当てルーチンを示す。ＩＰＣ通信に加わりたい新しいコンポーネントは、いずれも、（例えば、セッション・マネージャ２０４等の）そのＩＰＣセッション・マネージャから、ステップ３０２において、ＩＰＣ識別番号（ＩＤ）をまず要求する。すると、ローカル・セッション・マネージャ（例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ）は、新しいＩＰＣコンポーネントのＩＰＣサーバ・セッション・マネージャを呼出し、ステップ３０４において、コンポーネントＩＤ割当てを行う。本発明の実施形態によれば、コンポーネントＩＤは、動的であり、セッション・マネージャによって割り当てられる。主なＩＰＣサーバ位置は、主ＡＰ上となる可能性が最も高い。各ＩＰＣノードは、好適には、固有のＩＰＣノードＩＤを有し、セッション・マネージャは、そのデータベース中に、各関係ＩＰＣノード用の以下の情報を保持する。即ち、：
・ＩＰＣノードタイプ：例えば、特定のＢＰ又はＡＰ、無線ローカルエリアネットワーク（ＷＬＡＮ）ＡＰ等。

・ＩＰＣアドレス：ＩＰＣノードのＩＰＣアドレス。
・データタイプ：ＩＰＣノードのデータタイプ。
・ＯＰコードリスト：これは、コンポーネントが登録した全ＩＰＣメッセージのＯＰコードのリストである。

・コンポーネントＩＤ：全コンポーネントＩＤのリスト。
次に、図４において、全ての主ＩＰＣテーブルと共にＩＰＣスタックを示す。動的ルーチングテーブル４０２には、ノードタイプ、ＩＰＣアドレス／ポート＃情報、データタイプ及び登録リストが含まれる。コンポーネントルーチングテーブル４０４には、ＯＰコード情報と各特定のＯＰコードを登録した全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル４０６には、物理チャネルＩＤのリストとの各チャネルＩＤのリンクが含まれる。

図５において、本発明の実施形態に基づくＩＰＣスタックが、ソフトウェア・スレッド等（例えば、音声等）のコンポーネントにＩＰＣチャネルを如何に提供するかのブロック図を示す。コンポーネント５０２は、まず、ステップ５０４において、ＩＰＣチャネルを要求する。図５に示すセッション・マネージャは、定義されたＡＰＩを用いて、ステップ５０６において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層（デバイスインターフェイス）は、データチャネル５０８等のハードウェア資源を要求する。要求に応答して、図５に示すセッション・マネージャは、ステップ５１０において、要求側にＩＰＣチャネルを与える。次に、コンポーネント５０２は、割り当てられたチャネル５０８上でそのデータを送る。そして、デバイス層は、ＩＰＣネットワークにデータを転送する。論理から物理チャネルＩＤへのマッピングは、ＩＰＣデバイス・インターフェイスの機能である。

次に、図６において、ＩＰＣクライアント初期化における第１ステップは、ＩＰＣクライアント６０２とＩＰＣサーバ６０４との間において、登録要求（ステップ６０６）を送信することである。そして、ＩＰＣサーバ６０４は、ステップ６０８において、ＩＰＣクライアント６０２による要求を認証する。この後、ＩＰＣアドレスが、ＩＰＣクライアントに送信され、ステップ６１０において登録が完了する。ＩＰＣクライアントのセッション・マネージャは、ステップ６１２において、ＩＰＣクライアント６０２の動的ルーチングテーブルのコピーをＩＰＣサーバに送る。

ＩＰＣクライアント初期化プロセス時に行われる詳細なステップを図７に示す。クライアント・セッション・マネージャ（セッション（クライアント）としてテーブルに示す）は、ステップ７０２において、ＩＰＣサーバのセッション・マネージャ（セッション（サーバ）としてテーブルに示す）に設定要求を送る。ステップ７０４において、認証は、ＩＰＣサーバのセッション・マネージャによって要求される。そして、ＩＰＣクライアントとＩＰＣサーバとの間の認証は、ステップ７０６で実行される。

設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ７０２において、設定要求に応答して、セッションサーバは、要求側にＩＰＣアドレスを割り当てる。また、もしなければ、要求側用の動的ルーチングテーブルを設定する。そして、ステップ７０８において、要求側に設定指示を送る。設定指示パラメータには、サーバのＩＰＣアドレス及びクライアントの新規に割り当てられたＩＰＣアドレスが含まれる。

設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御／データを要求し得る。そして、セッションクライアントは、ステップ７１０において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、パラメータを有さない。ステップ７１０における設定指示確認メッセージの受信時、セッションサーバは、新規に設定されたセッションクライアントへのＩＰＣストリームを開始し得る。そして、セッションサーバは、ステップ７１２及び７１４において、セッションクライアントに設定更新メッセージを送る。これによって、図７に示す両セッションクライアントは、それらのそれぞれの動的ルーチングテーブル（図示せず）を更新し、ステップ７１６及び７１８において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、参加した全ＩＰＣが、更新されたことを確認する。

パケットは、ＩＰＣセッション・マネージャによって受信される時、送信元コンポーネントＩＤ、宛先ＩＤ、チャネルＩＤ及びＢＰ又はＡＰのタイプが含まれるデータの形態でやって来る。ＩＰＣセッション・マネージャは、宛先ＩＤが挿入されていない場合、宛先コンポーネントのＩＤである宛先ＩＤをパケットに挿入する。また、ＩＰＣセッション・マネージャは、ＩＰＣアドレスをパケットに挿入する。受信されたメッセージＯＰコードに基づき宛先コンポーネントＩＤを発見するのは、ＩＰＣセッション・マネージャである。宛先ＩＤは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいＩＰＣメッセージのＯＰコードに登録する（例えば、音声コンポーネントが、ＩＰＣセッション・マネージャに要求を送信することによって音声メッセージに登録する）度に、動的に更新される。

図８において、コンポーネントと本発明の実施形態に基づくそのＩＰＣセッション・マネージャとの間における一般的な宛先ＩＤ発見シーケンス時の一連のイベントを示す。ステップ８０２において、コンポーネントは、その送信元ＩＤ（宛先ＩＤはない）、宛先ＢＰ又はＡＰのタイプ、及びヘッダ及びデータが含まれるＩＰＣデータを送る。ステップ８０４において、ＩＰＣセッション・マネージャは、対応する動的ルーチングテーブルを検索し、正しい宛先アドレスを見つけるために、ＩＰＣデータヘッダＯＰコード、及び宛先ＢＰ又はＡＰのタイプを見る。ステップ８０６において、ＩＰＣセッション・マネージャは、コンポーネントのＩＰＣアドレスを挿入し、それをデバイス層に送る。

図９において、ＩＰＣコンポーネント初期化時に行われる代表的なステップを示す。ＢＰが、図９に示すＩＰＣサーバによって一旦設定されると、コンポーネント９０２等のコンポーネントは、異なるサービスに加入し得る。コンポーネントは、ステップ９０４において、音声や映像等の機能にコンポーネント自体を登録する。そして、コンポーネント登録情報は、ＩＰＣセッション・マネージャに送られ、（ＩＤがまだ割り当てられていない場合）コンポーネントＩＤの生成が行われ、また、特定のＩＰＣアドレス用動的ルーチングテーブルの生成又は更新が行われる（ステップ９０６）。ステップ９０８において、セッション・マネージャは、ステップ９０６からの情報でＩＰＣサーバを更新する。ステップ９０８において、更新された動的ルーチングテーブルを受信すると、ステップ９１２において、更新の確認が、ＩＰＣサーバによってＩＰＣクライアントに送信される。サーバが、一旦呼び出されると、新しい動的ルーチングテーブルの更新内容は、ステップ９１０において、関係する全プロセッサに一斉送信される。

図１０において、同じコンポーネント初期化プロセスを、コンポーネント（クライアント）１００２と、クライアント・セッション・マネージャ１００４としても知られているセッション（クライアント）と、サーバ・セッション・マネージャ１００６としても知られているセッション（サーバ）との間に示す。ステップ１００８におけるコンポーネント設定要求は、コンポーネント（クライアント）１００２によって送信される。要求に応答して、クライアント・セッション・マネージャ１００４は、デバイス層（図示せず）と論理チャネルを取り決める。また、クライアント・セッション・マネージャ１００４は、コンポーネントＩＤを割当て、その動的ルーチングテーブル（図示せず）に新しいＯＰコードリストを付加する。ステップ１０１０において、クライアント・セッション・マネージャ１００４は、パラメータとして、コンポーネントＩＤ及びチャネルＩＤが含まれる設定応答を送る。設定応答に応じて、コンポーネント（クライアント）１００２は、そのＩＤ及びチャネルＩＤをクライアントのセッション・マネージャ１００４から受信する。

一旦クライアント・セッション・マネージャ１００４が、ステップ１００８における設定要求に対して、ステップ１０１０で返信すると、クライアント・セッション・マネージャ１００４は、ステップ１０１２において、セッションサーバ（サーバ・セッション・マネージャ）１００６に設定更新要求を送る。設定更新要求のパラメータは、動的ルーチングテーブル（図示せず）において行われた何らかの新しい変更である。サーバのセッション・マネージャ１００６は、そのＩＰＣアドレス用の動的ルーチングテーブルを更新する。そして、ステップ１０１６において、サーバのセッション・マネージャ１００６は、全てのＩＰＣクライアント（図示せず）に設定更新内容を送り、その間、ステップ１０１４において、クライアントのセッション・マネージャ１００４に設定更新指示を送る。サーバのセッション・マネージャ１００６は、サーバが、送られた変更でそのルーチングテーブルを更新したことを確認する。

パラメータ（１つ又は複数）として動的ルーチングテーブルを含むステップ１０１６の設定更新メッセージにおいて、セッションサーバ１００６は、動的ルーチングテーブルを更新し、ステップ１０１８において、設定更新確認メッセージを送る。そして、サーバは、参加した全ＩＰＣが更新されたことを確認する。

ＩＰＣセッション・マネージャは、着信及び発信ＩＰＣパケットのルーチング経路を決定する。発信パケットのルートは、コンポーネントのＩＰＣアドレスによって決定される。宛先アドレスが、ローカルプロセッサの宛先アドレスであると分かった場合、オペレーティングシステム（ＯＳ）へのＩＰＣのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルＩＰＣクライアント用であると分かった場合、パケットは、ＩＰＣスタックに送られ、更に処理（例えば、カプセル化）される。宛先コンポーネントが、ＩＰＣパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、カプセル化は不要であり、パケットは、通常のＯＳメッセージ呼出し（例えば、マイクロソフト・メッセージ・キュー等）を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の変更について心配する必要はない。必要なことは、それらのメッセージのポスティング方法を、むしろＯＳ特有の方法からＩＰＣ呼出しに変更することだけである。

着信パケットの場合、メッセージの宛先アドレスが、ＩＰＣサーバのものと等しくない場合、着信パケットは、妥当なＩＰＣクライアントにルーチングされる。着信パケットのルーチングは、ＩＰＣサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先ＩＤが、有効なコンポーネントＩＤに又は０ＸＦＦに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。

ＩＰＣルータブロック（例えば、図２におけるＩＰＣルータブロック２１０参照）は、宛先コンポーネントにＩＰＣデータを輸送する。着信ＩＰＣメッセージは、とりわけ、発生元コンポーネントＩＤ、及び音声やモデム用等のＩＰＣメッセージＯＰコードを搬送する。ＩＰＣセッション・マネージャは、そのコンポーネントルーチングテーブルに依拠して、正しいコンポーネント（１つ又は複数）にＩＰＣデータを送る。動的ルーチングテーブル及びコンポーネントルーチングテーブルは、双方共、ＩＰＣサーバ／クライアントによって更新される。

起動時、各コンポーネントは、そのセッション・マネージャにそれ自体を登録して、ＩＰＣコンポーネントＩＤを取得しなければならない。更にまた、各コンポーネントは、音声やモデム等の着信ＩＰＣメッセージに登録しなければならない。この情報は、ＩＰＣセッション・マネージャによって用いられるために、コンポーネントルーチングテーブルに記憶される。

図１１に示すように、コンポーネント（例えば、ソフトウェア・スレッド）１１０２が、ステップ１１０４において、そのデータ要求をＩＰＣセッション・マネージャに送る場合、宛先ＩＰＣノード（例えば、ＢＰ）についてチェックが行われる。ＩＰＣノードが、ＩＰＣメッセージＯＰコードをサポートしない場合、エラー応答が、コンポーネント１１０２に返される。エラー応答に加えて、ＩＰＣセッション・マネージャは、その特定のＯＰコードを受信し得る全ＩＰＣノードの更新内容を返す。メッセージをＩＰＣノード（１つ又は複数）のどれに転送するか判断するのは、コンポーネント次第である。ＩＰＣセッション・マネージャ１１０６は、引き続きＩＰＣヘッダ情報によるデータのカプセル化を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、ＩＰＣネットワークに配置されていると判断した場合、ＩＰＣネットワーク上で送られる。

図１２において、本発明の実施形態に基づくＩＰＣデータヘッダ１２０２を示す。このヘッダには、送信元及び宛先ＩＰＣアドレス、送信元ポート、ＩＰＣルータによって提供された宛先ポート、ＩＰＣトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元ＩＰＣコンポーネント及び宛先ＩＰＣコンポーネントが含まれる。メッセージＯＰコード、メッセージ長及びＩＰＣデータは、コンポーネント１２０４によって提供される。

本発明の実施形態に基づく代表的なＩＰＣデータ要求を図１３に示す。ステップ１３０２において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びＯＰコードが含まれる。コンポーネントは、その宛先ＯＰコードをサポートするノードタイプを検索する。ノードタイプが０ｘＦＦに等しい場合、セッション・マネージャ（図１３において、”セッション”として示す）は、引き続き、全ての参加したＩＰＣ用の全ノードテーブルにコンポーネント情報を送信する。ＯＰコードフィールドが、０ｘＦＦに等しい場合、図１３に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するＯＰコードリストをコンポーネントに送る。他方、ＯＰコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のＯＰコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。

ステップ１３０４において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが０ｘＦＦに等しい場合、ノードテーブルが、コンポーネントに返される。ＯＰコードフィールドが０ｘＦＦに等しい場合、ＯＰコードのリストは、コンポーネントに返される。しかしながら、ＯＰコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ１３０６において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、ＩＰＣメッセージＯＰコード、ＩＰＣメッセージデータ、チャネルＩＤ及びコンポーネントＩＤが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、ＯＰコードがサポートされるかどうか判断する。ノードタイプがＯＰコードをサポートしない場合、コンポーネント更新指示は、ステップ１３０８において送られる。しかしながら、ノードタイプがＯＰコードをサポートする場合、データ要求が、ステップ１３１０においてデバイス層に送られる。データ要求パラメータには、ＩＰＣメッセージ、チャネルＩＤ及びＩＰＣヘッダが含まれる。

デバイス層は、チャネルＩＤに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート＃ヘッダ情報に基づき、ＩＰＣハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、１３１２においてセッション・マネージャに送られる。ステップ１３１４において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、ＩＰＣメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のＩＰＣメッセージを送信し得る。

ステップ１３１６において、デバイス層は、ＩＰＣメッセージデータ及びＩＰＣヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先ＩＰＣヘッダをチェックし、ローカルＩＰＣアドレスと異なる場合、セッション・マネージャは、正しいＩＰＣノードにメッセージを送る（ルーチングする）。ステップ１３１０において、セッション・マネージャは、予約チャネルＩＤと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントのＩＤである宛先をチェックし、それが０ｘＦＦに等しい場合、そのＯＰコードに登録された全コンポーネントにメッセージをルーチングする。ステップ１３１８において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、ＩＰＣデータを受信する。

ＩＰＣスタックは、全ての関係するＩＰＣノード間での通信のために予約制御チャネルを用いる。起動時、ＩＰＣサーバのセッション・マネージャは、このリンクを用いて、ＩＰＣクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのＡＰとＢＰ間において制御情報を搬送するために用いられる。

図１４において、ＩＰＣスタック（ＩＰＣスタック及びＩＰＣスタックサーバとして示す）とＩＰＣハードウェアとの間に配置された制御チャネル１４０２−１４０６を示す。また、制御チャネル情報１４０８は、異なるＩＰＣハードウェア間でデータを送信する時、データパケット１４１０と共に送信される。ＩＰＣクライアントは、初期的には、ＩＰＣ制御チャネル上でその設定要求を一斉送信する。ＩＰＣスタックサーバは、一斉送信を受信し、そのクライアント用のＩＰＣアドレスで応答する。このＩＰＣアドレスは、その特定のプロセッサ（ＡＰ又はＢＰ）用の動的ルーチングテーブルに対応付けられる。

ＩＰＣアプリケーション・プログラム・インターフェイス（ＡＰＩ）
以下に、本発明のＩＰＣプロトコル用ＡＰＩの幾つかを列記する。
１）ＩＰＣセッション・マネージャからコンポーネントインターフェイスへ
ＣｒｅａｔｅＣｏｍｐｏｎｅｎｔＩｎｓｔ（）
ＩＰＣセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ（ビッグ・エンディアン対リトル・エンディアン）等の情報及びメッセージＯＰコードの登録が、ＩＰＣアドレスに属する動的データルーチングテーブルにおいて用いられる。

ＯｐｅｎＣｈａｎｎｅｌＫｅｅｐ（）
ＩＰＣチャネルを開く。そして、それが利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）が発行される。チャネルは、ＣｌｏｓｅＣｈａｎｎｅｌ（）が発行されるまで予約される。コンポーネントは、ＩＰＣセッション・マネージャにQoS要求を送る。コンポーネントＩＤがまだ割り当てられていない場合、ＩＰＣチャネルは、それを割り当てる（例えば、ＣｈａｎｎｅｌＧｒａｎｔ（））。

ＯｐｅｎＣｈａｎｎｅｌ（）
ＩＰＣチャネルを開く。そして、それが利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）が発行される。パラメータは、ＯｐｅｎＣｈａｎｎｅｌＫｅｅｐ（）基本要素に用いられるものと同じである。

ＯｐｅｎＣｈａｎｎｅｌＷＴｈｒｕ（）
ＩＰＣチャネルを開く。そして、それが利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である（例えば、非ＵＤＰ＿ＡＴ命令）。

ＣｌｏｓｅＣｈａｎｎｅＩ（）
ＩＰＣチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。

ＣｈａｎｎｅｌＧｒａｎｔ（）
チャネルが要求側に与えられる。チャネルＩＤは、まだ、それが割り当てられていない場合、ＩＰＣセッション・マネージャによって割り当てられる。

ＣｈａｎｎｅｌＥｒｒｏｒ（）
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、ＩＰＣプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。

ＤａｔａＣｈａｎｎｅｔＲｅｑｕｅｓｔ（）
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。

ＣｈａｎｎｅｌＣｌｏｓｅ（）
ＩＰＣチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。

２）ＩＰＣセッション・マネージャとＩＰＣデバイス・インターフェイス間
ＯｐｅｎＣｈａｎｎｅｌ（）
論理ＩＰＣチャネルを開く。そして、それが利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）が発行される。ＩＰＣセッション・マネージャは、ＩＰＣデバイスインターフェイスマネージャにチャネル優先権要求を送る。

ＣｌｏｓｅＣｈａｎｎｅｌ（）
ＩＰＣ論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。

ＣｈａｎｎｅｌＧｒａｎｔ（）
論理チャネルが、要求側に与えられる。
ＣｈａｎｎｅｌＥｒｒｏｒ（）
チャネルエラーが発生した。（例えば、着信データに関するＣＲＣ障害又は物理チャネル障害）
ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）
要求側は、チャネルに関するデータを送付すべきであると警告される。

ＤａｔａＣｈａｎｎｅｌＲｅｑｕｅｓｔ（）
要求側が、論理チャネルに関するデータを送りたい。
ＣｈａｎｎｅｌＣｌｏｓｅ（）
ＩＰＣチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。

３）ＩＰＣセッション・マネージャからＩＰＣプレゼンテーション・マネージャへ
ＣｈａｎｎｅｔＤａｔａＩｎｄｉｃａｔｉｏｎ（）
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。

４）ＩＰＣハードウェア／ＩＰＣスタックインターフェイス
ＯｐｅｎＣｈａｎｎｅｌ（）
物理ＩＰＣチャネルを開く。そして、それが利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）が発行される。ＩＰＣセッション・マネージャは、ＩＰＣハードウェアにチャネル優先権要求を送る。

ＣｌｏｓｅＣｈａｎｎｅｌ（）
ＩＰＣ物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。

ＣｈａｎｎｅｌＧｒａｎｔ（）
物理チャネルが、要求側に与えられる。
ＣｈａｎｎｅｌＥｒｒｏｒ（）
チャネルエラーが発生した（例えば、着信データに関するＣＲＣ障害又は物理チャネル障害）。

ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）
要求側は、チャネルに関するデータを送付すべきであると警告される。
ＤａｔａＣｈａｎｎｅｔＲｅｑｕｅｓｔ（）
要求側が、物理チャネルに関するデータを送りたい。

ＣｈａｎｎｅｌＣｌｏｓｅ（）
ＩＰＣチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。

図１５において、ＩＰＣネットワークを用いて互いに通信を行うベースバンドプロセッサ（ＢＰ）１５０２及びアプリケーションプロセッサ（ＡＰ）１５０４を有する（例えば、携帯電話等）無線通信装置１５００等の電子装置のブロック図を示す。本発明のＩＰＣプロトコルは、通信装置１５００等のシステム中の複数のプロセッサ間において、通信を提供する。ＩＰＣは、専用通信システム（ＰＣＳ）アプリケーション等のＭＡサーバへの移動体アプリケーション（ＭＡ）クライアント（例えば、ｉＤＥＮＴＭ＿ＷＬＡＮ）の登録を可能にし、また、２つのＭＡが、それ自体のＭＡ内で、どんなソフトウェア・アーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。

ＩＰＣプロトコルは、任意のＩＰＣ準拠MAをＩＰＣリンクに動的に付加し通信を行わせる。従って、ＩＰＣネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のＩＰＣは、ソフトウェア・コンポーネントがＩＰＣスタック（図１５に示さず）と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。

本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。

本発明の実施形態に基づくＩＰＣネットワークを示す図。 本発明の実施形態に基づくＩＰＣスタックを示す図。 本発明の実施形態に基づくＩＰＣコンポーネントＩＰＣ割当てを示す図。 本発明の実施形態に基づく主ＩＰＣテーブルを示す図。 本発明の実施形態に基づくチャネルアロケーションを示す図。 本発明の実施形態に基づくＩＰＣクライアント初期化ルーチン時に関与するステップを強調表示して示す図。 本発明の実施形態に基づくＩＰＣクライアント初期化時に関与するステップを強調表示して示すもう１つの図。 本発明の実施形態に基づく第１レベルのＩＰＣカプセル化を強調表示して示す図。 本発明の実施形態に基づくＩＰＣコンポーネント初期化時に行われるステップを強調表示して示す図。 本発明の実施形態に基づくコンポーネント初期化時に行われるステップを強調表示して示す図。 本発明の実施形態に基づくＩＰＣクライアントとＩＰＣサーバとの間のＩＰＣデータ転送を示す図。 本発明の実施形態に基づくＩＰＣデータヘッダを示す図。 本発明の実施形態に基づくＩＰＣデータ要求時に行われるステップを示す図。 本発明の実施形態に基づくＩＰＣネットワークを示す図。 本発明の実施形態に基づく無線通信装置等の電子装置を示す図。

Claims (10)

1. プロセッサ間通信（ＩＰＣ）用のＩＰＣネットワーク（１００）であって、前記ＩＰＣネットワーク（１００）は、
   ＩＰＣサーバ（１０８）として動作する第１のプロセッサと；
   前記ＩＰＣサーバ（１０８）に接続され、且つＩＰＣクライアント（１０２）として動作する、第２のプロセッサと
   からなり、
   前記ＩＰＣサーバ（１０８）と前記ＩＰＣクライアント（１０２）とはそれぞれ、ＩＰＣスタック（２００）を備え、前記ＩＰＣスタック（２００）は、
   プレゼンテーション・マネージャ（２０２）と；
   前記プレゼンテーション・マネージャ（２０２）に接続されたセッション・マネージャ（２０４）と；
   前記セッション・マネージャ（２０４）に接続されたデバイス・インターフェイス（２０６）と
   を備え、
   前記ＩＰＣクライアント（１０２）は、前記ＩＰＣサーバ（１０８）に通信するために前記ＩＰＣスタック（２００）を使用し、
   前記ＩＰＣサーバ（１０８）と前記ＩＰＣクライアント（１０２）とが交渉により機能を交換することによって、前記ＩＰＣクライアント（１０２）は、新しいＩＰＣサーバ（１０８）である新ＩＰＣサーバになり得て、
   前記ＩＰＣネットワーク（１００）は、複数の前記ＩＰＣクライアント（１０２）を有し、
   前記ＩＰＣネットワーク（１００）の中で、複数の前記ＩＰＣクライアント（１０２、１０４，１０８）のうちの１つが前記新ＩＰＣサーバになった場合は、前記新ＩＰＣサーバにならなかった残りの前記ＩＰＣクライアントは、前記ＩＰＣサーバ（１０８）のＩＰＣアドレスを変更すべく指示され、
   前記ＩＰＣネットワーク（１００）は、前記ＩＰＣスタック（２００）を採用するすべてのプロセッサを共存させ、
   前記ＩＰＣネットワーク（１００）は、２つの前記ＩＰＣスタック（２００）があたかも、互いに共通のオペレーティング・システムとメモリとを共有する同一のプロセッサコア上で動作するように、前記ＩＰＣネットワーク（１００）は動作する、ＩＰＣネットワーク。
2. 少なくとも１つのコンポーネントは、前記ＩＰＣクライアント（１０２）に接続している、
   請求項１記載のＩＰＣネットワーク。
3. 前記コンポーネント間において異なるデータタイプに変換するために、前記プレゼンテーション・マネージャが使用される、
   請求項２記載のＩＰＣネットワーク。
4. 少なくとも１つの前記コンポーネントに、前記セッション・マネージャがコンポーネントＩＤを割り当てる、
   請求項２記載のＩＰＣネットワーク。
5. 前記コンポーネントＩＤは、少なくとも１つの前記コンポーネントに動的に割当てられ、且つ再割当てが可能な、
   請求項４記載のＩＰＣネットワーク。
6. 前記セッション・マネージャ（２０４）はさらに、コンポーネントルーチングテーブル（４０４）を有するＩＰＣルータブロック（２１０）を備え、
   前記コンポーネントルーチングテーブル（４０４）は、前記セッション・マネージャ（２０４）がＩＰＣデータを特定のＯＰコードでリンクされた１以上の前記コンポーネントに送信するために使用される、
   請求項２記載のＩＰＣネットワーク。
7. 少なくとも１つのＩＰＣハードウェアは、デバイス・インターフェイス層（２０６）に接続され、
   前記デバイス・インターフェイス層（２０６）は、前記ＩＰＣスタックがハードウェアに依存しないように、少なくとも１つの前記ＩＰＣハードウェアを抽象化する、
   請求項１記載のＩＰＣネットワーク。
8. ＩＰＣネットワーク（１００）の第１と第２のプロセッサ間でプロセッサ間通信（ＩＰＣ）を行う通信方法であって、前記通信方法は、
   前記第１のプロセッサがＩＰＣサーバ（１０８）として働き、前記第２のプロセッサがＩＰＣクライアント（１０２）として働く工程と；
   前記ＩＰＣネットワーク（１００）を介して、前記ＩＰＣサーバ（１０８）と前記ＩＰＣクライアント（１０２）との間で通信する工程であって、前記ＩＰＣサーバ（１０８）と前記ＩＰＣクライアント（１０２）とはそれぞれ、ＩＰＣスタック（２００）を備えることと；
   前記ＩＰＣサーバ（１０８）と前記ＩＰＣクライアント（１０２）とが互いに交渉し機能を交換することによって、前記ＩＰＣクライアント（１０２）が新しいＩＰＣサーバである新ＩＰＣサーバになる工程と
   を有し、
   前記ＩＰＣネットワーク（１００）は、複数の前記ＩＰＣクライアント（１０２，１０４，１０８）を有し、
   前記ＩＰＣネットワーク（１００）の中で、複数の前記ＩＰＣクライアント（１０２）のうちの１つが前記新ＩＰＣサーバである新ＩＰＣサーバになった場合は、前記新ＩＰＣサーバにならなかった残りの前記ＩＰＣクライアントは、前記ＩＰＣサーバ（１０８）のＩＰＣアドレスを変更すべく指示され、
   前記ＩＰＣスタック（２００）はそれぞれ、
   プレゼンテーション・マネージャ（２０２）と、
   前記プレゼンテーション・マネージャ（２０２）に接続されたセッション・マネージャ（２０４）と、
   前記セッション・マネージャ（２０４）に接続されたデバイス・インターフェイス（２０６）と
   を備え
   前記ＩＰＣクライアント（１０２）は、ＩＰＣサーバ（１０８）に通信するために前記ＩＰＣスタック（２００）を使用し、
   前記ＩＰＣネットワーク（１００）は、前記ＩＰＣスタックを採用するすべてのプロセッサを共存させ、
   前記ＩＰＣネットワーク（１００）は、２つの前記ＩＰＣスタック（２００）があたかも、互いに共通のオペレーティング・システムとメモリとを共有する同一のプロセッサコア上で動作する、通信方法。
9. 前記セッション・マネージャ（２０４）はそれぞれ、動的ルーチングテーブル（４０２）を備え、
   前記通信方法はさらに、前記動的ルーチングテーブル（４０２）それぞれを使用することによって、前記ＩＰＣクライアント（１０２）から前記ＩＰＣサーバ（１０８）に送信されるデータを適切にルーチングする工程を有する、
   請求項８記載の通信方法。
10. 前記ＩＰＣスタック（２００）はそれぞれ、ＩＰＣトランスポート層（２０８）を有するセッション・マネージャ（２０４）を含み、
    前記ＩＰＣトランスポート層（２０８）は、ＩＰＣデータについて周期的な冗長検査を行い、
    前記通信方法は更に、前記ＩＰＣサーバ（１０８）上のみで前記ＩＰＣトランスポート層（２０８）のルーチング機能を可能にする、
    請求項８記載の方法。

Images