スマート・ストリーミング・ポートによるプロセッサ間通信プロトコル
本発明の一実施形態におけるIPCプロトコルには、SSIポート(1610)等のスマート・ハードウェア・ポートが含まれる。セッションマネージャ(1608)には、ポート(1610)を特定のタスクに専用化するために、ソフトウェアスレッド(1602-1606)等のコンポーネントと折衝するための機能が含まれる。ポート専用化折衝プロセスは、現時点でポートに専用化されている他のOPコードとの間でポートが有し得る競合がないかどうか、IPCスタック(1610)の一部であるセッションマネージャ(1608)にチェックさせる。セッションマネージャ(1608)は、各ソフトウェア・スレッドから受信されたデータと共にコマンドブロックを送付し得る。コマンドブロックは、それがデータに対して行う必要があると思われるあらゆる共同処理についてSSIポート(1610)に通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的に電子分野に関し、特には、スマート・ストリーミング・ポートによるプロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の多くのネットワーク要素（部品）からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信（ＩＰＣ）と呼ばれる。
【０００３】
近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。ＩＰＣの一例はＰＣＩＡＧＰコントローラ（ＰＡＣ）であって、Ｈｏｓｔ‐ｔｏ‐ＰＣＩブリッジ、ＤＲＡＭコントローラ、およびデータ経路とＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）インタフェイスを集積する。ＩＰＣの別例はＯＭＡＰ（登録商標）プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル（物理層）では設計自由度はほとんどない。
【０００４】
例えば、PACプラットフォームは、閉じたアーキテクチャであり、また、オペレーティング・システムのTAPI層に組み込まれ、開発者は、IPCコードを利用できない。従って、これらのプラットフォームは、コンポーネントレベルに達せず、また、IPC資源の動的割当て、ハードウェアサポート機能又はマルチノードルーティングを許さない。
【０００５】
リアルタイム処理アプリケーション等のアプリケーションにおける１つの問題は、異なるプロセッサ上のサービスの発見及びIPC要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する１つの側面は、無線通信装置における移動体アプリケーション(MA)等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにIPCデータを輸送し、そして、そのデータを対象のMAに再度ルーティングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう１つの側面は、専用リンク(ポート)を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るスマート・ストリーミング・ポートによるIPCプロトコルに対するニーズが、当分野に存在する。
【発明を実施するための最良の形態】
【０００６】
新規であると思われる本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。
【０００７】
本明細書は、新規であると見なされる本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
本発明によれば、特定のサービスに対するポート割当ては、動的であり、ソフトウェア・コンポーネントから抽出され、また、複数のサービス(例えば、１つのリンク上での音声及び/又は映像の組合せ)を提供するために用い得る。本発明の実施形態に基づく、サービスにポートを動的にリンクするというIPCの利点は、次のように要約し得る。即ち、
1)トラフィックが非専用IPCリンク上で問題になる場合、ソフトウェア・コンポーネントの待ち時間問題を軽減する。
【０００８】
2)ハードウェアポートに共同処理サポートを提供する。
3)プラットフォームからのコンポーネントアーキテクチャ抽出。
4)異なる移動体アプリケーション(MA)間におけるコンポーネント移植性。
【０００９】
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
【００１０】
IPCをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、IPCにより、その２つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、IPCは、異なるプロセッサ間において信頼性の高い通信を提供する。
【００１１】
IPCハードウェアは、異なるプロセッサをIPCネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。IPCネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる(例えば、IPCアドレス)。また、データパケットは、本発明の一実施形態におけるIPCネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する。また、好適には、パケットは、従来の周期的冗長検査(CRC)手法を用いて、エラーが無いかチェックされる。本発明のIPCネットワークのネットワークアクティビティは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ネットワーク等のIP輸送層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のIPCは、TCP/IPネットワークのようにゲートウェイにより小規模なネットワークに分割されない。
【００１２】
次に、図1において、本発明の実施形態に基づくIPCネットワーク100を示す。IPCネットワーク100には、複数のIPCクライアント102-106及び、幾つかの実例として、共有メモリ110、ユニバーサル非同期受信機／送信機(UART)112及びユニバーサル・シリアル・バス(USB)114等の異なるIPC物理リンクを用いて、IPCクライアント102-106に接続されたIPCサーバ108が含まれる。本発明のIPCにより、IPCクライアント102-106は、現IPCサーバ108と折衝して役割を交替し得ることに留意されたい。IPCクライアント102-106が、IPCサーバになるように折衝して新しいIPCサーバになる場合、残りの全てのIPCクライアントは、IPCサーバの変更があった場合、サーバのIPアドレスを変更するように指示される。
【００１３】
図2において、本発明の実施形態に基づくIPCサーバ108(又はIPCクライアント102-108)のIPCスタック200を示す。IPCスタック200は、オペレーティングシステム(OS)の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズにサポートを提供するように設計されている。IPCスタックは、次の3つの主な層から構成される。即ち、
(1)IPCプレゼンテーション・マネージャ(202)：この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間において異なるデータタイプを変換するために用いられる。
【００１４】
(2)IPCセッション・マネージャ(204)：この層は、IPCスタックと全システムコンポーネントとの間における全着信/発信IPCトラフィック用の中央リポジトリである。IPCセッション・マネージャ204は、幾つかの機能を有する。即ち、IPCコンポーネントを参加させるためのコンポーネントIDの割当て；IPCデータを隠蔽する必要があるかどうかの判断；IPCデータのルーティング、IPCトラフィックの終止；IPCプロセッサ用のプレースホルダ；IPCアドレスの提供、IPCクライアントの割当及び認証等を有する。
【００１５】
IPCトランスポート層(208)：IPCセッション・マネージャ(層)204内に配置される。IPCトランスポート層208は、異なるプロセッサ間において、IPCデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、IPCトランスポート層208は、IPCメッセージを、IPCネットワーク100上のそれらの最終宛先にルーティングする役割を担う。トランスポート層のルーティング機能は、IPCサーバ上でのみ使用可能である。
【００１６】
IPCルータブロック(210)：宛先コンポーネント（図示せず）にIPCデータを輸送する。着信IPCメッセージは、とりわけ、音声及びモデム等の発生元コンポーネントID、IPCメッセージOPコードを搬送する。本発明の実施形態によれば、固有のOPコードが、IPCネットワークに接続された音声及びモデム等の各コンポーネント/ソフトウェア・スレッドに割り当てられることに留意されたい(例えば、図５の502参照)。IPCセッション・マネージャ204は、ルータブロック210に依拠して、IPCデータを正しいコンポーネント（１つ又は複数）に送る。
【００１７】
(3)デバイス・インタフェイス層(206)：IPC物理対論理IPCチャネルを管理する役割を果たす。その主な機能は、スタックIPCがハードウェアに依存しなくなるように、IPCハードウェアを完全に抽出することである。デバイス・インタフェイス層206は、直下のIPCリンクの物理帯域幅を管理して全IPC論理チャネルをサポートする。着信経路において、デバイス・インタフェイス層206は、異なる物理チャネル110-114からデータを傍受して、それらを残りのIPCスタックに渡す。発信経路上では、デバイス・インタフェイス層206は、IPC論理チャネルのデータローディングを、それらを適切な物理チャネル上に送ることによって管理する。また、デバイス・インタフェイス層206は、同じIPCチャネルに属するIPCパケットの連結を行い、その後、それらをIPCハードウェアに送る。チャネル要件は、IPCセッション・マネージャ204とIPCデバイス・インタフェイス層206との間で事前に折衝される。デバイス・インタフェイス層206は、ハードウェアポートを備え、これは、IPCクライアント102-106とのデバイス・インタフェイスを提供する。
【００１８】
図3において、IPCコンポーネントID割当てルーチンを示す。IPC通信に加わりたい新しいコンポーネントは、いずれも、(例えば、セッション・マネージャ204等の)そのIPCセッション・マネージャから、ステップ302において、IPC識別番号(ID)をまず要求することによって、そうしなければならない。すると、ローカル・セッション・マネージャ(例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ)は、新しいIPCコンポーネントのIPCサーバ・セッション・マネージャを呼出し、ステップ304において、コンポーネントID割当てを行う。本発明の実施形態によれば、コンポーネントIDは、動的であり、セッション・マネージャによって割り当てられる。主なIPCサーバ位置は、最も可能性が高いのは、主AP上である。各IPCノードは、好適には、固有のIPCノードIDを有し、セッション・マネージャは、そのデータベース中に、各関係IPCノード用の以下の情報を保持する。即ち、
IPCノードタイプ：例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
【００１９】
IPCアドレス：IPCノードのIPCアドレス
データタイプ：IPCノードのデータタイプ
OPコードリスト：これは、コンポーネントが申し込んだ全IPCメッセージOPコードのリストである。
【００２０】
コンポーネントID：全コンポーネントIDのリスト
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。ダイナミック・ルーティング・テーブル402には、ノードタイプ、IPCアドレス/ポート♯情報、データタイプ及び申込みリストが含まれる。コンポーネント・ルーティング・テーブル404には、OPコード情報と各特定のOPコードに申し込んだ全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
【００２１】
図5において、本発明の実施形態に基づくIPCスタックが、ソフトウェア・スレッド等(例えば、音声等)のコンポーネントにIPCチャネルを如何に提供するかのブロック図を示す。コンポーネント502は、まず、ステップ504において、IPCチャネルを要求する。図5に示すセッション・マネージャは、定義されたAPIを用いて、ステップ506において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層(デバイスインタフェイス)は、データチャネル508等のハードウェア資源を要求する。要求に応答して、図5に示すセッション・マネージャは、ステップ510において、要求側にIPCチャネルを与える。次に、コンポーネント502は、割り当てられたチャネル508上でそのデータを送る。そして、デバイス層は、IPCネットワークにデータを転送する。論理から物理チャネルIDへのマッピングは、IPCデバイス・インタフェイスの機能である。
【００２２】
次に、図6において、IPCクライアント初期化における第１ステップは、IPCクライアント602とIPCサーバ604との間において、登録要求(ステップ606)を送信することである。そして、IPCサーバ604は、ステップ608において、IPCクライアント602による要求を認証する。この後、IPCアドレスが、IPCクライアントに送信され、ステップ610において登録が完了する。IPCクライアントのセッション・マネージャは、ステップ612において、そのダイナミック・ルーティング・テーブルのコピーをIPCサーバに送る。
【００２３】
IPCクライアント初期化プロセス時に行われる詳細なステップを図7に示す。クライアント・セッション・マネージャ(セッション(クライアント)としてテーブルに示す)は、ステップ702において、IPCサーバのセッション・マネージャ(セッション(サーバ)としてテーブルに示す)に設定要求を送る。ステップ704において、認証は、IPCサーバのセッション・マネージャによって要求される。そして、IPCクライアントとIPCサーバとの間の認証は、ステップ706で実行される。
【００２４】
設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ702において、設定要求に応答して、セッションサーバは、要求側にIPCアドレスを割り当てる。また、もしなければ、要求側用のダイナミック・ルーティング・テーブルを設定する。そして、ステップ708において、要求側に設定指示を送る。設定指示パラメータには、サーバのIPCアドレス及びクライアントの新規に割り当てられたIPCアドレスが含まれる。
【００２５】
設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御/データを要求し得る。そして、セッションクライアントは、ステップ710において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、ステップ710における設定指示確認メッセージの受信時、パラメータを有さず、セッションサーバは、新規に設定されたセッションクライアントへのIPCストリームを起動し得る。そして、セッションサーバは、ステップ712及び714において、セッションクライアントに設定更新メッセージを送る。これによって、図7に示す両セッションクライアントは、それらのそれぞれのダイナミック・ルーティング・テーブル（図示せず）を更新し、ステップ716及び718において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、全ての参加したIPCが、更新されたことを確認する。
【００２６】
パケットは、IPCセッション・マネージャによって受信される時、送信元コンポーネントID、宛先ID、チャネルID及びBP又はAPのタイプが含まれるデータの形態でやって来る。IPCセッション・マネージャは、宛先IDが挿入されていない場合、宛先コンポーネントI Dを付加する。また、IPCセッション・マネージャは、IPCアドレスを挿入する。受信されたメッセージOPコードに基づき宛先IDを発見するのは、IPCセッション・マネージャである。宛先IDは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいIPCメッセージOPコードに申し込む(例えば、音声コンポーネントが、IPCセッション・マネージャに要求を送信することによって音声メッセージに申し込む)度に、動的に更新される。
【００２７】
図8において、コンポーネントと本発明の実施形態に基づくそのIPCセッション・マネージャとの間における一般的な宛先ID発見シーケンス時の一連のイベントを示す。ステップ802において、コンポーネントは、その送信元ID(宛先IDはない)、宛先BP又はAPのタイプ、及びヘッダ及びデータが含まれるIPCデータを送る。ステップ804において、IPCセッション・マネージャは、対応するダイナミック・ルーティング・テーブルを検索し、正しい宛先アドレスを見つけるために、IPCデータヘッダOPコード、及び宛先BP又はAPのタイプを見る。ステップ806において、IPCセッション・マネージャは、コンポーネントのIPCアドレスを挿入し、それをデバイス層に送る。
【００２８】
図9において、IPCコンポーネント初期化時に行われる代表的なステップを示す。BPが、図9に示すIPCサーバによって一旦設定されると、コンポーネント902等のコンポーネントは、異なるサービスに申し込み得る。コンポーネントは、ステップ904において、音声や映像等の機能にそれら自体申し込む。そして、コンポーネント申込み情報は、IPCセッション・マネージャに送られ、(IDがまだ割り当てられていない場合)コンポーネントIDの生成が行われ、また、特定のIPCアドレス用ダイナミック・ルーティング・テーブルの生成又は更新が行われる(ステップ906)。ステップ908において、セッション・マネージャは、ステップ906からの情報でIPCサーバを更新する。ステップ908において、更新されたダイナミック・ルーティング・テーブルを受信すると、ステップ912において、更新の確認が、IPCサーバによってIPCクライアントに送信される。サーバが、一旦呼び出されると、新しいダイナミック・ルーティング・テーブル更新内容は、関係する全プロセッサステップ910に一斉送信される。
【００２９】
図10において、同じコンポーネント初期化プロセスを、コンポーネント(クライアント)1002と、クライアント・セッション・マネージャ1004としても知られているセッション(クライアント)と、サーバ・セッション・マネージャ1006としても知られているセッション(サーバ)との間に示す。ステップ1008におけるコンポーネント設定要求は、コンポーネント(クライアント)1002によって送信される。要求に応答して、クライアント・セッション・マネージャ1004は、デバイス層（図示せず）と論理チャネルを取り決める。また、クライアント・セッション・マネージャ1004は、コンポーネントIDを割当て、そのダイナミック・ルーティング・テーブル（図示せず）に新しいOPコードリストを付加する。ステップ1010において、クライアント・セッション・マネージャ1004は、パラメータとして、コンポーネントID及びチャネルIDが含まれる設定応答を送る。設定応答に応じて、コンポーネント(クライアント)1002は、そのID及びチャネルIDをクライアントのセッション・マネージャ1004から受信する。
【００３０】
一旦クライアント・セッション・マネージャ1004が、ステップ1008における設定要求に対して、ステップ1010で返信すると、クライアント・セッション・マネージャ1004は、ステップ1012において、セッションサーバ(サーバ・セッション・マネージャ)1006に設定更新要求を送る。設定更新要求のパラメータは、ダイナミック・ルーティング・テーブル（図示せず）において行われた何らかの新しい変更である。サーバのセッション・マネージャ1006は、そのIPCアドレス用のダイナミック・ルーティング・テーブルを更新する。そして、ステップ1016において、サーバのセッション・マネージャ1006は、全てのIPCクライアント（図示せず）に設定更新内容を送り、その間、ステップ1014において、クライアントのセッション・マネージャ1004に設定更新指示を送る。サーバのセッション・マネージャ1006は、サーバが、送られた変更でそのルーティングテーブルを更新したことを確認する。
【００３１】
パラメータ(１つ又は複数)としてダイナミック・ルーティング・テーブルを含むステップ1016の設定更新メッセージにおいて、セッションサーバ1006は、ダイナミック・ルーティング・テーブルを更新し、ステップ1018において、設定更新確認メッセージを送る。そして、サーバは、参加した全IPCが更新されたことを確認する。
【００３２】
IPCセッション・マネージャは、着信及び発信IPCパケットのルーティング経路を決定する。発信パケットのルートは、コンポーネントのIPCアドレスによって決定される。宛先アドレスが、ローカルプロセッサのそれであると分かった場合、オペレーティングシステム(OS)へのIPCのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルIPCクライアント用であると分かった場合、パケットは、IPCスタックに送られ、更に処理(例えば、隠蔽)される。宛先コンポーネントが、IPCパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、隠蔽は不要であり、パケットは、通常のOSメッセージ呼出し(例えば、マイクロソフト・メッセージ・キュー等)を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の修正について心配する必要はない。必要なことは、それらのメッセージ書き込み方法を、むしろOS特有の設計からIPC呼出しに変更することだけである。
【００３３】
着信パケットの場合、メッセージの宛先アドレスが、IPCサーバのものと等しくない場合、着信パケットは、妥当なIPCクライアントにルーティングされる。着信パケットのルーティングは、IPCサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先IDが、有効なコンポーネントIDに又は0XFFに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。
【００３４】
IPCルータブロック(例えば、図2におけるIPCルータブロック210参照)は、宛先コンポーネントにIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントID、及び音声やモデム用等のIPCメッセージOPコードを搬送する。IPCセッション・マネージャは、そのコンポーネント・ルーティング・テーブルに依拠して、正しいコンポーネント(１つ又は複数)にIPCデータを送る。ダイナミック・ルーティング・テーブル及びコンポーネント・ルーティング・テーブルは、双方共、IPCサーバ/クライアントによって更新される。
【００３５】
起動時、各コンポーネントは、そのセッション・マネージャにそれ自体登録して、IPCコンポーネントIDを取得しなければならない。更にまた、音声やモデム等の着信IPCメッセージを申し込まなければならない。この情報は、コンポーネント・ルーティング・テーブルに記憶され、IPCセッション・マネージャによって用いられる。
【００３６】
図11に示すように、コンポーネント(例えば、ソフトウェア・スレッド)1102が、ステップ1104において、そのデータ要求をIPCセッション・マネージャに送る場合、宛先IPCノード(例えば、BP)についてチェックが行われる。IPCノードが、IPCメッセージOPコードをサポートしない場合、エラー応答が、コンポーネント1102に返される。エラー応答に加えて、IPCセッション・マネージャは、その特定のOPコードを受信し得る全IPCノードの更新内容を返す。メッセージをIPCノード(１つ又は複数)のどれに転送するか判断するのは、コンポーネント次第である。IPCセッション・マネージャ1106は、引き続きIPCヘッダ情報によるデータの隠蔽を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、IPCネットワークに配置されていると判断した場合、IPCネットワーク上で送られる。
【００３７】
図12において、本発明の実施形態に基づくIPCデータヘッダ1202を示す。このヘッダには、送信元及び宛先IPCアドレス、送信元ポート、IPCルータによって提供された宛先ポート、IPCトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元IPCコンポーネント及び宛先IPCコンポーネントが含まれる。メッセージOPコード、メッセージ長及びIPCデータは、コンポーネント1204によって提供される。
【００３８】
本発明の実施形態に基づく代表的なIPCデータ要求を図13に示す。ステップ1302において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びOPコードが含まれる。コンポーネントは、その宛先OPコードをサポートするノードタイプを検索する。ノードタイプが0xFFに等しい場合、セッション・マネージャ(図13において、”セッション”として示す)は、引き続き、全ての参加したIPC用の全ノードテーブルにコンポーネント情報を送信する。OPコードフィールドが、0xFFに等しい場合、図13に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するOPコードリストをコンポーネントに送る。他方、OPコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のOPコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。
【００３９】
ステップ1304において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが0xFFに等しい場合、ノードテーブルが、コンポーネントに返される。OPコードフィールドが0xFFに等しい場合、OPコードのリストは、コンポーネントに返される。しかしながら、OPコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ1306において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、IPCメッセージOPコード、IPCメッセージデータ、チャネルID及びコンポーネントIDが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、OPコードがサポートされるかどうか判断する。ノードタイプがOPコードをサポートしない場合、コンポーネント更新指示は、ステップ1308において送られる。しかしながら、ノードタイプがOPコードをサポートする場合、データ要求が、ステップ1310においてデバイス層に送られる。データ要求パラメータには、IPCメッセージ、チャネルID及びIPCヘッダが含まれる。
【００４０】
デバイス層は、チャネルIDに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート♯ヘッダ情報に基づき、IPCハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、1312においてセッション・マネージャに送られる。ステップ1314において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、IPCメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のIPCメッセージを送信し得る。
【００４１】
ステップ1316において、デバイス層は、IPCメッセージデータ及びIPCヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先IPCヘッダをチェックし、ローカルIPCアドレスと異なる場合、セッション・マネージャは、正しいIPCノードにメッセージを送る(ルーティングする)。ステップ1310において、セッション・マネージャは、予約チャネルIDと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントIDをチェックし、それが0xFFに等しい場合、そのOPコードに申し込んだ全コンポーネントにメッセージをルーティングする。ステップ1318において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、IPCデータを受信する。
【００４２】
IPCスタックは、全ての関係するIPCノード間での通信のために予約制御チャネルを用いる。起動時、IPCサーバのセッション・マネージャは、このリンクを用いて、IPCクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのAPとBP間において制御情報を搬送するために用いられる。
【００４３】
図14において、IPCスタック(IPCスタック及びIPCスタックサーバとして示す)とIPCハードウェアとの間に配置された制御チャネル1402-1406を示す。また、制御チャネル情報1408は、異なるIPCハードウェア間でデータを送信する時、データパケット1410と共に送信される。IPCクライアントは、初期的には、IPC制御チャネル上でその設定要求を一斉送信する。IPCスタックサーバは、一斉送信を受信し、そのクライアント用のIPCアドレスで応答する。このIPCアドレスは、その特定のプロセッサ(AP又はBP)用のダイナミック・ルーティング・テーブルに対応付けられる。
【００４４】
IPCアプリケーション・プログラム・インタフェイス(API)
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインタフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの申込みが、IPCアドレスに属するダイナミック・データ・ルーティング・テーブルにおいて用いられる。
【００４５】
OpenChannelKeep()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
【００４６】
OpenChannel()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
【００４７】
OpenChannelWThru()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
【００４８】
CloseChanneI()
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
【００４９】
ChannelGrant()
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
【００５０】
ChannelError()
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
【００５１】
DataChannetRequest()
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
【００５２】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５３】
2)IPCセッション・マネージャとIPCデバイス・インタフェイス間
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインタフェイスマネージャにチャネル優先権要求を送る。
【００５４】
CloseChannel()
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
【００５５】
ChannelGrant()
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
【００５６】
DataChannelRequest()
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５７】
3)IPCセッション・マネージャからIPCプレゼンテーション・マネージャへ
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
【００５８】
4)IPCハードウェア/IPCスタックインタフェイス
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、aChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
【００５９】
CloseChannel()
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
【００６０】
ChannelGrant()
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
【００６１】
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
【００６２】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００６３】
図15において、IPCネットワークを用いて互いに通信を行うベースバンドプロセッサ(BP)1502及びアプリケーションプロセッサ(AP)1504を有する(例えば、携帯電話等)無線通信装置1500等の電子装置のブロック図を示す。本発明のIPCプロトコルは、通信装置1500等のシステム中の複数のプロセッサ間において、通信を提供する。IPCは、専用通信システム(PCS)アプリケーション等のMAサーバへの移動体アプリケーション(MA)クライアント(例えば、iDENTM_WLAN)の登録を可能にし、また、２つのMAが、それ自体のMA内で、どんなソフトウェアアーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。
【００６４】
IPCプロトコルは、任意のIPC準拠MAをIPCリンクに動的に付加し通信を行わせる。従って、IPCネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のIPCは、ソフトウェア・コンポーネントがIPCスタック(図15に示さず)と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。
【００６５】
スマート・ストリーミング・ポート
本発明の一実施形態によれば、IPCデータを輸送するためにIPCスタックによって用いられるハードウェアポートは、２つの音声ストリームを加算してから、合成されたストリームをIPCネットワーク上で送出する等の共同処理機能に動的に割当て得る。これらの機能は、マルチメディア、ゲーム等に重要なサポートを提供する。他の潜在的な用途には、ほんの一例を挙げてみただけでも、ミキシング、同期化、及び速度変換動作が含まれる。データストリームに対して行われる動作は更なる帯域幅を占有することなく、合成されたデータはマルチメディアにとって非常に魅力的である。ステレオ音声の生成、ゲーム用のバックグラウンドミュージックへの音声付加などの事柄は、スマート・ストリーミング・ポートによるこのIPCを用いて、全て簡単に実現し得る。
共同処理に加えて、IPCセッション・マネージャは、任意の時点で、特定のIPCリンクへのトラフィック負荷がかなり高く、これによって、コンポーネントへのデータの時間通りの送付が遅れる可能性があることを発見し得る。待ち時間の発見は、IPC機能又はコンポーネントのいずれかがその待たれているデータを速く送付するように要求するものであってよい。この考えは、IPCアーキテクチャに由来するが、IPCアーキテクチャは、そのセッション・マネージャが、特定のメッセージをどのポートに流したいか又はどのポートから取り出したいか判断する方法を提供する。IPCによってサポートされた他の任意の輸送メカニズムを用い得ることに留意すべきであるが、IPCセッション・マネージャは、OPコードのリストを同期シリアルインタフェイス(SSI)ポート等のポートに結び付ける。
【００６６】
一例の説明として、非専用リンクが、送信する必要があるデータを適切にリアルタイムに送付していないことを、専用リンク又は非専用IPCリンク上のいずれかにある特定のアプリケーションMAが検出するものとすると、両MAは、代わりに専用リンクの使用について折衝し得る。この例示の事例では、SSIポートが、もし利用可能であるとすれば、この問題に対する最も可能性の高い解決策である。
【００６７】
本発明によれば、(クライアント又はサーバ内のいずれかにある)IPCセッション・マネージャは、特に、メッセージをルーティングし、メッセージの配信を管理する知能を有する。IPCセッション・マネージャは、ダイナミック・ルーティング・テーブルを生成・維持して、IPCノード機能を発見し、また、IPCメッセージのルーティング経路を計算する。セッション・マネージャは、ポートが利用可能であることを教え得るだけであるが、セッション・マネージャとデバイス層との間のAPIを用いることによって、その機能を発見する。デバイス層は、層中に発見された各ポート用の機能について正確に知っている。
【００６８】
例えば、IPCセッション・マネージャは、特定のサービスにポートを専用化すると判断した場合、このようなサービスに属する全てのOPコード用のポート(例えば、SSI)へのリンクを生成する。それ以降は、そのポートに属する特定のOPコードを搬送する全てのIPCメッセージは、このようにルーティングされる。ポートの専用化に加えて、ポートは、IPCチャネル毎にデータストリームに対して共同処理機能を実行するように要求される。コマンドヘッダは、データと共に、或る共同処理機能を実行するように要求しているポートに送られる。例えば、１つのチャネルからの音声ストリームを速度変換するように要求したり、それ自体を他のストリームと加算するように要求したりできる。ポートの出力は、複数のストリームを一体化する１つのストリームであり、現時点で、対象のMAに送る準備が完了している。一例として、SSIは、現在異なるプラットフォームで行われるように、音声搬送に専用化されることがある。IPCセッション・マネージャは、その要求をポート情報と共にデバイス層に送付するが、これは、それが特にそのポート上で送付できるようにするためである。各チャネルは、そのデータの冒頭に、共同処理コマンドブロックを搬送するが、これは、そのチャネルストリーム上でのポート動作を規定する。
【００６９】
図16において、本発明に基づく、セッション・マネージャ1608を有するIPCスタック1610に接続され、異なる帯域幅要件を各々有する３つのソフトウェア・スレッド1602、1604及び1606を示す。SSIポート1610は、ソフトウェア・スレッドから音声データを受信ように割り当てられて(専用化されて)おり、ここでは、図示したソフトウェア・スレッド1602及び1604は、デバイス層1612に配置されたSSIポート1610を通ってそれらのデータを送信している。
【００７０】
図17において、本発明の実施形態に基づく、ポートを専用化する際に行われるステップを強調表示する図を示す。ステップ1702において、ソフトウェア・スレッド1704からの要求は、専用化されるポート(例えば、SSIポート1714)に対してなされる。例えば、SSIポート1714は、音声等のサービスに対して専用化し得る。ポートを専用化することは、IPCデータだけがそのポート上でクライアント間において送られ、IPCヘッダオーバーヘッドが存在しないことを意味する。例えば、SSIポート1714は、IPC_AクライアントとIPC_Bクライアントとの間で音声サンプルを搬送するように専用化し得る。この例では、ポートが専用化されていることから、クライアントA及びBは、それらのデータと共にIPCヘッダを送る必要がなく、これによってシステムオーバーヘッドが低減される。
【００７１】
ステップ1704において、ポートに専用化されたOPコードのリストは、セッション・マネージャ1712によって見直される。ステップ1706において、セッション・マネージャ1712は、以前該当ポートに専用化されたそれらOPコード間の競合を探す。セッション・マネージャは、特定のポートが既に使用されていることを発見した場合、他のプロセッサとそのポートの使用について再折衝し得る。セッション・マネージャは、競合を発見しない場合、或るOPコード及びIPCクライアントにそのポートを専用化し得る。ステップ1708において、セッション・マネージャ1712は、SSIポート1714の用途を音声サービスに専用化する。音声等のタイプのサービスを処理することに加えて、SSIポート1714には、IPCチャネル毎にデータストリームに対して共同処理を実行するように要求し得る。ステップ1710において、セッション・マネージャ1712は、SSIポート1714に制御情報を送り、データストリームに対してどんな共同処理機能を実行するかそれに通知する。図17に示す例において、ソフトウェア・スレッド1716によって送信された音声ストリームには、ソフトウェア・スレッド1718によってSSIポート1714に送信された音声ストリームと合成されるように要求し得る。
【００７２】
図18において、ソフトウェア・スレッド1716及び1718によって送信された同じ音声ストリームを示す。セッション・マネージャ1712は、ソフトウェア・スレッド1716及び1718によって送信されたデータの各ストリームにコマンドヘッダ1802及び1804を付加する。コマンドヘッダ1802及び1804は、SSIポート1714に、それが受信するデータに実行される或る共同処理を実行するように指示する。一例として、コマンドヘッダ1802は、SSIポート1714に対してデータを或る速度に速度変換するように、あるいは、他のデータのストリームとデータを加算するように要求し得る。この特定の例において、SSIポート1714からのデータの出力ストリームは、ソフトウェア・スレッド1716及び1718からのストリームを一体化する１つのストリームである。
【００７３】
例示の実施例として、アプリケーション/コンポーネントは、セッション・マネージャ1712からあるタイプの“サービス”(例えば、速度変換等)を要求する。セッション・マネージャ1712は、その特定のタイプの“サービス”を求めてデバイス層と折衝する。サービスに対する折衝は、要求IDからなる要求を必然的に伴うが、この要求IDは、どんなタイプのサービスが要求されようとしているか、要求の長さ及びデータパラメータをデバイス層に請け負わせる。デバイス層は、ハードウェア(例えば、スマートポート等)又はサービスのサポートに必要な他の資源の利用可能性に基づき、このようなサービスを容認又は拒否する。デバイス層がサービスに対する要求を容認した場合、デバイス層は、そのサービスのサービスIDを与える。サービスIDは、デバイス層からそのチャネル上で要求されたサービスを記述する。サービスIDは、単なる数字であってよい。セッション・マネージャ1712は、サービスを要求したコンポーネントにサービスIDを転送する。そして、コンポーネントは、そのチャネルでそのサービスを実行してほしい時、コプロセッサ・コマンド・ブロックでサービスIDを送る。しかしながら、コンポーネントは、或るサービスをそのチャネルと対応付けたい場合、そのチャネルIDと一緒にそのサービスIDを用いることはない。
【００７４】
本発明において行われるように、ポートをサービスにリンクすることによって、ハードウェアポートにおいて共同処理サポートを実行可能なこと、プラットフォームからのコンポーネントアーキテクチャ抽出、非専用IPCリンク上でトラフィックが問題になる場合の待ち時間問題の低減等を含む数多くの利点が得られる。セッション・マネージャ1712は、例えば、１つのポート上にトラフィックが多すぎると判断した場合、ポートの専用化をそれ自体で決定したり、コンポーネントから要求を受信したりできる。
【００７５】
本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。
【図面の簡単な説明】
【００７６】
【図１】本発明の実施形態に基づくIPCネットワークを示す図。
【図２】本発明の実施形態に基づくIPCスタックを示す図。
【図３】本発明の実施形態に基づくIPCコンポーネントIPC割当てを示す図。
【図４】本発明の実施形態に基づく主IPCテーブルを示す図。
【図５】本発明の実施形態に基づくチャネルアロケーションを示す図。
【図６】本発明の実施形態に基づくIPCクライアント初期化ルーチン時に関与するステップを強調表示して示す図。
【図７】本発明の実施形態に基づくIPCクライアント初期化時に関与するステップを強調表示して示すもう１つの図。
【図８】本発明の実施形態に基づく第１レベルのIPC隠蔽を強調表示して示す図。
【図９】本発明の実施形態に基づくIPCコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１０】本発明の実施形態に基づくコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１１】本発明の実施形態に基づくIPCクライアントとIPCサーバとの間のIPCデータ転送を示す図。
【図１２】本発明の実施形態に基づくIPCデータヘッダを示す図。
【図１３】本発明の実施形態に基づくIPCデータ要求時に行われるステップを示す図。
【図１４】本発明の実施形態に基づくIPCネットワークを示す図。
【図１５】本発明の実施形態に基づく無線通信装置等の電子装置を示す図。
【図１６】本発明の実施形態に基づく専用ポート(１つ又は複数)によるIPCプロトコルを示す図。
【図１７】本発明の実施形態に基づくスマート・ハードウェア・ポートの専用化要求時に行われるステップを示す図。
【図１８】本発明の実施形態に基づきポートが一旦専用化されたデータ転送を強調表示する図17の続きを示す図。
【技術分野】
【０００１】
本発明は一般的に電子分野に関し、特には、スマート・ストリーミング・ポートによるプロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の多くのネットワーク要素（部品）からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信（ＩＰＣ）と呼ばれる。
【０００３】
近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。ＩＰＣの一例はＰＣＩＡＧＰコントローラ（ＰＡＣ）であって、Ｈｏｓｔ‐ｔｏ‐ＰＣＩブリッジ、ＤＲＡＭコントローラ、およびデータ経路とＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）インタフェイスを集積する。ＩＰＣの別例はＯＭＡＰ（登録商標）プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル（物理層）では設計自由度はほとんどない。
【０００４】
例えば、PACプラットフォームは、閉じたアーキテクチャであり、また、オペレーティング・システムのTAPI層に組み込まれ、開発者は、IPCコードを利用できない。従って、これらのプラットフォームは、コンポーネントレベルに達せず、また、IPC資源の動的割当て、ハードウェアサポート機能又はマルチノードルーティングを許さない。
【０００５】
リアルタイム処理アプリケーション等のアプリケーションにおける１つの問題は、異なるプロセッサ上のサービスの発見及びIPC要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する１つの側面は、無線通信装置における移動体アプリケーション(MA)等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにIPCデータを輸送し、そして、そのデータを対象のMAに再度ルーティングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう１つの側面は、専用リンク(ポート)を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るスマート・ストリーミング・ポートによるIPCプロトコルに対するニーズが、当分野に存在する。
【発明を実施するための最良の形態】
【０００６】
新規であると思われる本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。
【０００７】
本明細書は、新規であると見なされる本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
本発明によれば、特定のサービスに対するポート割当ては、動的であり、ソフトウェア・コンポーネントから抽出され、また、複数のサービス(例えば、１つのリンク上での音声及び/又は映像の組合せ)を提供するために用い得る。本発明の実施形態に基づく、サービスにポートを動的にリンクするというIPCの利点は、次のように要約し得る。即ち、
1)トラフィックが非専用IPCリンク上で問題になる場合、ソフトウェア・コンポーネントの待ち時間問題を軽減する。
【０００８】
2)ハードウェアポートに共同処理サポートを提供する。
3)プラットフォームからのコンポーネントアーキテクチャ抽出。
4)異なる移動体アプリケーション(MA)間におけるコンポーネント移植性。
【０００９】
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
【００１０】
IPCをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、IPCにより、その２つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、IPCは、異なるプロセッサ間において信頼性の高い通信を提供する。
【００１１】
IPCハードウェアは、異なるプロセッサをIPCネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。IPCネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる(例えば、IPCアドレス)。また、データパケットは、本発明の一実施形態におけるIPCネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する。また、好適には、パケットは、従来の周期的冗長検査(CRC)手法を用いて、エラーが無いかチェックされる。本発明のIPCネットワークのネットワークアクティビティは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ネットワーク等のIP輸送層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のIPCは、TCP/IPネットワークのようにゲートウェイにより小規模なネットワークに分割されない。
【００１２】
次に、図1において、本発明の実施形態に基づくIPCネットワーク100を示す。IPCネットワーク100には、複数のIPCクライアント102-106及び、幾つかの実例として、共有メモリ110、ユニバーサル非同期受信機／送信機(UART)112及びユニバーサル・シリアル・バス(USB)114等の異なるIPC物理リンクを用いて、IPCクライアント102-106に接続されたIPCサーバ108が含まれる。本発明のIPCにより、IPCクライアント102-106は、現IPCサーバ108と折衝して役割を交替し得ることに留意されたい。IPCクライアント102-106が、IPCサーバになるように折衝して新しいIPCサーバになる場合、残りの全てのIPCクライアントは、IPCサーバの変更があった場合、サーバのIPアドレスを変更するように指示される。
【００１３】
図2において、本発明の実施形態に基づくIPCサーバ108(又はIPCクライアント102-108)のIPCスタック200を示す。IPCスタック200は、オペレーティングシステム(OS)の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズにサポートを提供するように設計されている。IPCスタックは、次の3つの主な層から構成される。即ち、
(1)IPCプレゼンテーション・マネージャ(202)：この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間において異なるデータタイプを変換するために用いられる。
【００１４】
(2)IPCセッション・マネージャ(204)：この層は、IPCスタックと全システムコンポーネントとの間における全着信/発信IPCトラフィック用の中央リポジトリである。IPCセッション・マネージャ204は、幾つかの機能を有する。即ち、IPCコンポーネントを参加させるためのコンポーネントIDの割当て；IPCデータを隠蔽する必要があるかどうかの判断；IPCデータのルーティング、IPCトラフィックの終止；IPCプロセッサ用のプレースホルダ；IPCアドレスの提供、IPCクライアントの割当及び認証等を有する。
【００１５】
IPCトランスポート層(208)：IPCセッション・マネージャ(層)204内に配置される。IPCトランスポート層208は、異なるプロセッサ間において、IPCデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、IPCトランスポート層208は、IPCメッセージを、IPCネットワーク100上のそれらの最終宛先にルーティングする役割を担う。トランスポート層のルーティング機能は、IPCサーバ上でのみ使用可能である。
【００１６】
IPCルータブロック(210)：宛先コンポーネント（図示せず）にIPCデータを輸送する。着信IPCメッセージは、とりわけ、音声及びモデム等の発生元コンポーネントID、IPCメッセージOPコードを搬送する。本発明の実施形態によれば、固有のOPコードが、IPCネットワークに接続された音声及びモデム等の各コンポーネント/ソフトウェア・スレッドに割り当てられることに留意されたい(例えば、図５の502参照)。IPCセッション・マネージャ204は、ルータブロック210に依拠して、IPCデータを正しいコンポーネント（１つ又は複数）に送る。
【００１７】
(3)デバイス・インタフェイス層(206)：IPC物理対論理IPCチャネルを管理する役割を果たす。その主な機能は、スタックIPCがハードウェアに依存しなくなるように、IPCハードウェアを完全に抽出することである。デバイス・インタフェイス層206は、直下のIPCリンクの物理帯域幅を管理して全IPC論理チャネルをサポートする。着信経路において、デバイス・インタフェイス層206は、異なる物理チャネル110-114からデータを傍受して、それらを残りのIPCスタックに渡す。発信経路上では、デバイス・インタフェイス層206は、IPC論理チャネルのデータローディングを、それらを適切な物理チャネル上に送ることによって管理する。また、デバイス・インタフェイス層206は、同じIPCチャネルに属するIPCパケットの連結を行い、その後、それらをIPCハードウェアに送る。チャネル要件は、IPCセッション・マネージャ204とIPCデバイス・インタフェイス層206との間で事前に折衝される。デバイス・インタフェイス層206は、ハードウェアポートを備え、これは、IPCクライアント102-106とのデバイス・インタフェイスを提供する。
【００１８】
図3において、IPCコンポーネントID割当てルーチンを示す。IPC通信に加わりたい新しいコンポーネントは、いずれも、(例えば、セッション・マネージャ204等の)そのIPCセッション・マネージャから、ステップ302において、IPC識別番号(ID)をまず要求することによって、そうしなければならない。すると、ローカル・セッション・マネージャ(例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ)は、新しいIPCコンポーネントのIPCサーバ・セッション・マネージャを呼出し、ステップ304において、コンポーネントID割当てを行う。本発明の実施形態によれば、コンポーネントIDは、動的であり、セッション・マネージャによって割り当てられる。主なIPCサーバ位置は、最も可能性が高いのは、主AP上である。各IPCノードは、好適には、固有のIPCノードIDを有し、セッション・マネージャは、そのデータベース中に、各関係IPCノード用の以下の情報を保持する。即ち、
IPCノードタイプ：例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
【００１９】
IPCアドレス：IPCノードのIPCアドレス
データタイプ：IPCノードのデータタイプ
OPコードリスト：これは、コンポーネントが申し込んだ全IPCメッセージOPコードのリストである。
【００２０】
コンポーネントID：全コンポーネントIDのリスト
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。ダイナミック・ルーティング・テーブル402には、ノードタイプ、IPCアドレス/ポート♯情報、データタイプ及び申込みリストが含まれる。コンポーネント・ルーティング・テーブル404には、OPコード情報と各特定のOPコードに申し込んだ全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
【００２１】
図5において、本発明の実施形態に基づくIPCスタックが、ソフトウェア・スレッド等(例えば、音声等)のコンポーネントにIPCチャネルを如何に提供するかのブロック図を示す。コンポーネント502は、まず、ステップ504において、IPCチャネルを要求する。図5に示すセッション・マネージャは、定義されたAPIを用いて、ステップ506において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層(デバイスインタフェイス)は、データチャネル508等のハードウェア資源を要求する。要求に応答して、図5に示すセッション・マネージャは、ステップ510において、要求側にIPCチャネルを与える。次に、コンポーネント502は、割り当てられたチャネル508上でそのデータを送る。そして、デバイス層は、IPCネットワークにデータを転送する。論理から物理チャネルIDへのマッピングは、IPCデバイス・インタフェイスの機能である。
【００２２】
次に、図6において、IPCクライアント初期化における第１ステップは、IPCクライアント602とIPCサーバ604との間において、登録要求(ステップ606)を送信することである。そして、IPCサーバ604は、ステップ608において、IPCクライアント602による要求を認証する。この後、IPCアドレスが、IPCクライアントに送信され、ステップ610において登録が完了する。IPCクライアントのセッション・マネージャは、ステップ612において、そのダイナミック・ルーティング・テーブルのコピーをIPCサーバに送る。
【００２３】
IPCクライアント初期化プロセス時に行われる詳細なステップを図7に示す。クライアント・セッション・マネージャ(セッション(クライアント)としてテーブルに示す)は、ステップ702において、IPCサーバのセッション・マネージャ(セッション(サーバ)としてテーブルに示す)に設定要求を送る。ステップ704において、認証は、IPCサーバのセッション・マネージャによって要求される。そして、IPCクライアントとIPCサーバとの間の認証は、ステップ706で実行される。
【００２４】
設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ702において、設定要求に応答して、セッションサーバは、要求側にIPCアドレスを割り当てる。また、もしなければ、要求側用のダイナミック・ルーティング・テーブルを設定する。そして、ステップ708において、要求側に設定指示を送る。設定指示パラメータには、サーバのIPCアドレス及びクライアントの新規に割り当てられたIPCアドレスが含まれる。
【００２５】
設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御/データを要求し得る。そして、セッションクライアントは、ステップ710において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、ステップ710における設定指示確認メッセージの受信時、パラメータを有さず、セッションサーバは、新規に設定されたセッションクライアントへのIPCストリームを起動し得る。そして、セッションサーバは、ステップ712及び714において、セッションクライアントに設定更新メッセージを送る。これによって、図7に示す両セッションクライアントは、それらのそれぞれのダイナミック・ルーティング・テーブル（図示せず）を更新し、ステップ716及び718において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、全ての参加したIPCが、更新されたことを確認する。
【００２６】
パケットは、IPCセッション・マネージャによって受信される時、送信元コンポーネントID、宛先ID、チャネルID及びBP又はAPのタイプが含まれるデータの形態でやって来る。IPCセッション・マネージャは、宛先IDが挿入されていない場合、宛先コンポーネントI Dを付加する。また、IPCセッション・マネージャは、IPCアドレスを挿入する。受信されたメッセージOPコードに基づき宛先IDを発見するのは、IPCセッション・マネージャである。宛先IDは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいIPCメッセージOPコードに申し込む(例えば、音声コンポーネントが、IPCセッション・マネージャに要求を送信することによって音声メッセージに申し込む)度に、動的に更新される。
【００２７】
図8において、コンポーネントと本発明の実施形態に基づくそのIPCセッション・マネージャとの間における一般的な宛先ID発見シーケンス時の一連のイベントを示す。ステップ802において、コンポーネントは、その送信元ID(宛先IDはない)、宛先BP又はAPのタイプ、及びヘッダ及びデータが含まれるIPCデータを送る。ステップ804において、IPCセッション・マネージャは、対応するダイナミック・ルーティング・テーブルを検索し、正しい宛先アドレスを見つけるために、IPCデータヘッダOPコード、及び宛先BP又はAPのタイプを見る。ステップ806において、IPCセッション・マネージャは、コンポーネントのIPCアドレスを挿入し、それをデバイス層に送る。
【００２８】
図9において、IPCコンポーネント初期化時に行われる代表的なステップを示す。BPが、図9に示すIPCサーバによって一旦設定されると、コンポーネント902等のコンポーネントは、異なるサービスに申し込み得る。コンポーネントは、ステップ904において、音声や映像等の機能にそれら自体申し込む。そして、コンポーネント申込み情報は、IPCセッション・マネージャに送られ、(IDがまだ割り当てられていない場合)コンポーネントIDの生成が行われ、また、特定のIPCアドレス用ダイナミック・ルーティング・テーブルの生成又は更新が行われる(ステップ906)。ステップ908において、セッション・マネージャは、ステップ906からの情報でIPCサーバを更新する。ステップ908において、更新されたダイナミック・ルーティング・テーブルを受信すると、ステップ912において、更新の確認が、IPCサーバによってIPCクライアントに送信される。サーバが、一旦呼び出されると、新しいダイナミック・ルーティング・テーブル更新内容は、関係する全プロセッサステップ910に一斉送信される。
【００２９】
図10において、同じコンポーネント初期化プロセスを、コンポーネント(クライアント)1002と、クライアント・セッション・マネージャ1004としても知られているセッション(クライアント)と、サーバ・セッション・マネージャ1006としても知られているセッション(サーバ)との間に示す。ステップ1008におけるコンポーネント設定要求は、コンポーネント(クライアント)1002によって送信される。要求に応答して、クライアント・セッション・マネージャ1004は、デバイス層（図示せず）と論理チャネルを取り決める。また、クライアント・セッション・マネージャ1004は、コンポーネントIDを割当て、そのダイナミック・ルーティング・テーブル（図示せず）に新しいOPコードリストを付加する。ステップ1010において、クライアント・セッション・マネージャ1004は、パラメータとして、コンポーネントID及びチャネルIDが含まれる設定応答を送る。設定応答に応じて、コンポーネント(クライアント)1002は、そのID及びチャネルIDをクライアントのセッション・マネージャ1004から受信する。
【００３０】
一旦クライアント・セッション・マネージャ1004が、ステップ1008における設定要求に対して、ステップ1010で返信すると、クライアント・セッション・マネージャ1004は、ステップ1012において、セッションサーバ(サーバ・セッション・マネージャ)1006に設定更新要求を送る。設定更新要求のパラメータは、ダイナミック・ルーティング・テーブル（図示せず）において行われた何らかの新しい変更である。サーバのセッション・マネージャ1006は、そのIPCアドレス用のダイナミック・ルーティング・テーブルを更新する。そして、ステップ1016において、サーバのセッション・マネージャ1006は、全てのIPCクライアント（図示せず）に設定更新内容を送り、その間、ステップ1014において、クライアントのセッション・マネージャ1004に設定更新指示を送る。サーバのセッション・マネージャ1006は、サーバが、送られた変更でそのルーティングテーブルを更新したことを確認する。
【００３１】
パラメータ(１つ又は複数)としてダイナミック・ルーティング・テーブルを含むステップ1016の設定更新メッセージにおいて、セッションサーバ1006は、ダイナミック・ルーティング・テーブルを更新し、ステップ1018において、設定更新確認メッセージを送る。そして、サーバは、参加した全IPCが更新されたことを確認する。
【００３２】
IPCセッション・マネージャは、着信及び発信IPCパケットのルーティング経路を決定する。発信パケットのルートは、コンポーネントのIPCアドレスによって決定される。宛先アドレスが、ローカルプロセッサのそれであると分かった場合、オペレーティングシステム(OS)へのIPCのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルIPCクライアント用であると分かった場合、パケットは、IPCスタックに送られ、更に処理(例えば、隠蔽)される。宛先コンポーネントが、IPCパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、隠蔽は不要であり、パケットは、通常のOSメッセージ呼出し(例えば、マイクロソフト・メッセージ・キュー等)を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の修正について心配する必要はない。必要なことは、それらのメッセージ書き込み方法を、むしろOS特有の設計からIPC呼出しに変更することだけである。
【００３３】
着信パケットの場合、メッセージの宛先アドレスが、IPCサーバのものと等しくない場合、着信パケットは、妥当なIPCクライアントにルーティングされる。着信パケットのルーティングは、IPCサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先IDが、有効なコンポーネントIDに又は0XFFに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。
【００３４】
IPCルータブロック(例えば、図2におけるIPCルータブロック210参照)は、宛先コンポーネントにIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントID、及び音声やモデム用等のIPCメッセージOPコードを搬送する。IPCセッション・マネージャは、そのコンポーネント・ルーティング・テーブルに依拠して、正しいコンポーネント(１つ又は複数)にIPCデータを送る。ダイナミック・ルーティング・テーブル及びコンポーネント・ルーティング・テーブルは、双方共、IPCサーバ/クライアントによって更新される。
【００３５】
起動時、各コンポーネントは、そのセッション・マネージャにそれ自体登録して、IPCコンポーネントIDを取得しなければならない。更にまた、音声やモデム等の着信IPCメッセージを申し込まなければならない。この情報は、コンポーネント・ルーティング・テーブルに記憶され、IPCセッション・マネージャによって用いられる。
【００３６】
図11に示すように、コンポーネント(例えば、ソフトウェア・スレッド)1102が、ステップ1104において、そのデータ要求をIPCセッション・マネージャに送る場合、宛先IPCノード(例えば、BP)についてチェックが行われる。IPCノードが、IPCメッセージOPコードをサポートしない場合、エラー応答が、コンポーネント1102に返される。エラー応答に加えて、IPCセッション・マネージャは、その特定のOPコードを受信し得る全IPCノードの更新内容を返す。メッセージをIPCノード(１つ又は複数)のどれに転送するか判断するのは、コンポーネント次第である。IPCセッション・マネージャ1106は、引き続きIPCヘッダ情報によるデータの隠蔽を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、IPCネットワークに配置されていると判断した場合、IPCネットワーク上で送られる。
【００３７】
図12において、本発明の実施形態に基づくIPCデータヘッダ1202を示す。このヘッダには、送信元及び宛先IPCアドレス、送信元ポート、IPCルータによって提供された宛先ポート、IPCトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元IPCコンポーネント及び宛先IPCコンポーネントが含まれる。メッセージOPコード、メッセージ長及びIPCデータは、コンポーネント1204によって提供される。
【００３８】
本発明の実施形態に基づく代表的なIPCデータ要求を図13に示す。ステップ1302において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びOPコードが含まれる。コンポーネントは、その宛先OPコードをサポートするノードタイプを検索する。ノードタイプが0xFFに等しい場合、セッション・マネージャ(図13において、”セッション”として示す)は、引き続き、全ての参加したIPC用の全ノードテーブルにコンポーネント情報を送信する。OPコードフィールドが、0xFFに等しい場合、図13に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するOPコードリストをコンポーネントに送る。他方、OPコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のOPコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。
【００３９】
ステップ1304において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが0xFFに等しい場合、ノードテーブルが、コンポーネントに返される。OPコードフィールドが0xFFに等しい場合、OPコードのリストは、コンポーネントに返される。しかしながら、OPコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ1306において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、IPCメッセージOPコード、IPCメッセージデータ、チャネルID及びコンポーネントIDが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、OPコードがサポートされるかどうか判断する。ノードタイプがOPコードをサポートしない場合、コンポーネント更新指示は、ステップ1308において送られる。しかしながら、ノードタイプがOPコードをサポートする場合、データ要求が、ステップ1310においてデバイス層に送られる。データ要求パラメータには、IPCメッセージ、チャネルID及びIPCヘッダが含まれる。
【００４０】
デバイス層は、チャネルIDに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート♯ヘッダ情報に基づき、IPCハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、1312においてセッション・マネージャに送られる。ステップ1314において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、IPCメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のIPCメッセージを送信し得る。
【００４１】
ステップ1316において、デバイス層は、IPCメッセージデータ及びIPCヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先IPCヘッダをチェックし、ローカルIPCアドレスと異なる場合、セッション・マネージャは、正しいIPCノードにメッセージを送る(ルーティングする)。ステップ1310において、セッション・マネージャは、予約チャネルIDと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントIDをチェックし、それが0xFFに等しい場合、そのOPコードに申し込んだ全コンポーネントにメッセージをルーティングする。ステップ1318において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、IPCデータを受信する。
【００４２】
IPCスタックは、全ての関係するIPCノード間での通信のために予約制御チャネルを用いる。起動時、IPCサーバのセッション・マネージャは、このリンクを用いて、IPCクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのAPとBP間において制御情報を搬送するために用いられる。
【００４３】
図14において、IPCスタック(IPCスタック及びIPCスタックサーバとして示す)とIPCハードウェアとの間に配置された制御チャネル1402-1406を示す。また、制御チャネル情報1408は、異なるIPCハードウェア間でデータを送信する時、データパケット1410と共に送信される。IPCクライアントは、初期的には、IPC制御チャネル上でその設定要求を一斉送信する。IPCスタックサーバは、一斉送信を受信し、そのクライアント用のIPCアドレスで応答する。このIPCアドレスは、その特定のプロセッサ(AP又はBP)用のダイナミック・ルーティング・テーブルに対応付けられる。
【００４４】
IPCアプリケーション・プログラム・インタフェイス(API)
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインタフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの申込みが、IPCアドレスに属するダイナミック・データ・ルーティング・テーブルにおいて用いられる。
【００４５】
OpenChannelKeep()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
【００４６】
OpenChannel()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
【００４７】
OpenChannelWThru()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
【００４８】
CloseChanneI()
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
【００４９】
ChannelGrant()
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
【００５０】
ChannelError()
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
【００５１】
DataChannetRequest()
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
【００５２】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５３】
2)IPCセッション・マネージャとIPCデバイス・インタフェイス間
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインタフェイスマネージャにチャネル優先権要求を送る。
【００５４】
CloseChannel()
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
【００５５】
ChannelGrant()
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
【００５６】
DataChannelRequest()
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５７】
3)IPCセッション・マネージャからIPCプレゼンテーション・マネージャへ
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
【００５８】
4)IPCハードウェア/IPCスタックインタフェイス
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、aChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
【００５９】
CloseChannel()
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
【００６０】
ChannelGrant()
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
【００６１】
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
【００６２】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００６３】
図15において、IPCネットワークを用いて互いに通信を行うベースバンドプロセッサ(BP)1502及びアプリケーションプロセッサ(AP)1504を有する(例えば、携帯電話等)無線通信装置1500等の電子装置のブロック図を示す。本発明のIPCプロトコルは、通信装置1500等のシステム中の複数のプロセッサ間において、通信を提供する。IPCは、専用通信システム(PCS)アプリケーション等のMAサーバへの移動体アプリケーション(MA)クライアント(例えば、iDENTM_WLAN)の登録を可能にし、また、２つのMAが、それ自体のMA内で、どんなソフトウェアアーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。
【００６４】
IPCプロトコルは、任意のIPC準拠MAをIPCリンクに動的に付加し通信を行わせる。従って、IPCネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のIPCは、ソフトウェア・コンポーネントがIPCスタック(図15に示さず)と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。
【００６５】
スマート・ストリーミング・ポート
本発明の一実施形態によれば、IPCデータを輸送するためにIPCスタックによって用いられるハードウェアポートは、２つの音声ストリームを加算してから、合成されたストリームをIPCネットワーク上で送出する等の共同処理機能に動的に割当て得る。これらの機能は、マルチメディア、ゲーム等に重要なサポートを提供する。他の潜在的な用途には、ほんの一例を挙げてみただけでも、ミキシング、同期化、及び速度変換動作が含まれる。データストリームに対して行われる動作は更なる帯域幅を占有することなく、合成されたデータはマルチメディアにとって非常に魅力的である。ステレオ音声の生成、ゲーム用のバックグラウンドミュージックへの音声付加などの事柄は、スマート・ストリーミング・ポートによるこのIPCを用いて、全て簡単に実現し得る。
共同処理に加えて、IPCセッション・マネージャは、任意の時点で、特定のIPCリンクへのトラフィック負荷がかなり高く、これによって、コンポーネントへのデータの時間通りの送付が遅れる可能性があることを発見し得る。待ち時間の発見は、IPC機能又はコンポーネントのいずれかがその待たれているデータを速く送付するように要求するものであってよい。この考えは、IPCアーキテクチャに由来するが、IPCアーキテクチャは、そのセッション・マネージャが、特定のメッセージをどのポートに流したいか又はどのポートから取り出したいか判断する方法を提供する。IPCによってサポートされた他の任意の輸送メカニズムを用い得ることに留意すべきであるが、IPCセッション・マネージャは、OPコードのリストを同期シリアルインタフェイス(SSI)ポート等のポートに結び付ける。
【００６６】
一例の説明として、非専用リンクが、送信する必要があるデータを適切にリアルタイムに送付していないことを、専用リンク又は非専用IPCリンク上のいずれかにある特定のアプリケーションMAが検出するものとすると、両MAは、代わりに専用リンクの使用について折衝し得る。この例示の事例では、SSIポートが、もし利用可能であるとすれば、この問題に対する最も可能性の高い解決策である。
【００６７】
本発明によれば、(クライアント又はサーバ内のいずれかにある)IPCセッション・マネージャは、特に、メッセージをルーティングし、メッセージの配信を管理する知能を有する。IPCセッション・マネージャは、ダイナミック・ルーティング・テーブルを生成・維持して、IPCノード機能を発見し、また、IPCメッセージのルーティング経路を計算する。セッション・マネージャは、ポートが利用可能であることを教え得るだけであるが、セッション・マネージャとデバイス層との間のAPIを用いることによって、その機能を発見する。デバイス層は、層中に発見された各ポート用の機能について正確に知っている。
【００６８】
例えば、IPCセッション・マネージャは、特定のサービスにポートを専用化すると判断した場合、このようなサービスに属する全てのOPコード用のポート(例えば、SSI)へのリンクを生成する。それ以降は、そのポートに属する特定のOPコードを搬送する全てのIPCメッセージは、このようにルーティングされる。ポートの専用化に加えて、ポートは、IPCチャネル毎にデータストリームに対して共同処理機能を実行するように要求される。コマンドヘッダは、データと共に、或る共同処理機能を実行するように要求しているポートに送られる。例えば、１つのチャネルからの音声ストリームを速度変換するように要求したり、それ自体を他のストリームと加算するように要求したりできる。ポートの出力は、複数のストリームを一体化する１つのストリームであり、現時点で、対象のMAに送る準備が完了している。一例として、SSIは、現在異なるプラットフォームで行われるように、音声搬送に専用化されることがある。IPCセッション・マネージャは、その要求をポート情報と共にデバイス層に送付するが、これは、それが特にそのポート上で送付できるようにするためである。各チャネルは、そのデータの冒頭に、共同処理コマンドブロックを搬送するが、これは、そのチャネルストリーム上でのポート動作を規定する。
【００６９】
図16において、本発明に基づく、セッション・マネージャ1608を有するIPCスタック1610に接続され、異なる帯域幅要件を各々有する３つのソフトウェア・スレッド1602、1604及び1606を示す。SSIポート1610は、ソフトウェア・スレッドから音声データを受信ように割り当てられて(専用化されて)おり、ここでは、図示したソフトウェア・スレッド1602及び1604は、デバイス層1612に配置されたSSIポート1610を通ってそれらのデータを送信している。
【００７０】
図17において、本発明の実施形態に基づく、ポートを専用化する際に行われるステップを強調表示する図を示す。ステップ1702において、ソフトウェア・スレッド1704からの要求は、専用化されるポート(例えば、SSIポート1714)に対してなされる。例えば、SSIポート1714は、音声等のサービスに対して専用化し得る。ポートを専用化することは、IPCデータだけがそのポート上でクライアント間において送られ、IPCヘッダオーバーヘッドが存在しないことを意味する。例えば、SSIポート1714は、IPC_AクライアントとIPC_Bクライアントとの間で音声サンプルを搬送するように専用化し得る。この例では、ポートが専用化されていることから、クライアントA及びBは、それらのデータと共にIPCヘッダを送る必要がなく、これによってシステムオーバーヘッドが低減される。
【００７１】
ステップ1704において、ポートに専用化されたOPコードのリストは、セッション・マネージャ1712によって見直される。ステップ1706において、セッション・マネージャ1712は、以前該当ポートに専用化されたそれらOPコード間の競合を探す。セッション・マネージャは、特定のポートが既に使用されていることを発見した場合、他のプロセッサとそのポートの使用について再折衝し得る。セッション・マネージャは、競合を発見しない場合、或るOPコード及びIPCクライアントにそのポートを専用化し得る。ステップ1708において、セッション・マネージャ1712は、SSIポート1714の用途を音声サービスに専用化する。音声等のタイプのサービスを処理することに加えて、SSIポート1714には、IPCチャネル毎にデータストリームに対して共同処理を実行するように要求し得る。ステップ1710において、セッション・マネージャ1712は、SSIポート1714に制御情報を送り、データストリームに対してどんな共同処理機能を実行するかそれに通知する。図17に示す例において、ソフトウェア・スレッド1716によって送信された音声ストリームには、ソフトウェア・スレッド1718によってSSIポート1714に送信された音声ストリームと合成されるように要求し得る。
【００７２】
図18において、ソフトウェア・スレッド1716及び1718によって送信された同じ音声ストリームを示す。セッション・マネージャ1712は、ソフトウェア・スレッド1716及び1718によって送信されたデータの各ストリームにコマンドヘッダ1802及び1804を付加する。コマンドヘッダ1802及び1804は、SSIポート1714に、それが受信するデータに実行される或る共同処理を実行するように指示する。一例として、コマンドヘッダ1802は、SSIポート1714に対してデータを或る速度に速度変換するように、あるいは、他のデータのストリームとデータを加算するように要求し得る。この特定の例において、SSIポート1714からのデータの出力ストリームは、ソフトウェア・スレッド1716及び1718からのストリームを一体化する１つのストリームである。
【００７３】
例示の実施例として、アプリケーション/コンポーネントは、セッション・マネージャ1712からあるタイプの“サービス”(例えば、速度変換等)を要求する。セッション・マネージャ1712は、その特定のタイプの“サービス”を求めてデバイス層と折衝する。サービスに対する折衝は、要求IDからなる要求を必然的に伴うが、この要求IDは、どんなタイプのサービスが要求されようとしているか、要求の長さ及びデータパラメータをデバイス層に請け負わせる。デバイス層は、ハードウェア(例えば、スマートポート等)又はサービスのサポートに必要な他の資源の利用可能性に基づき、このようなサービスを容認又は拒否する。デバイス層がサービスに対する要求を容認した場合、デバイス層は、そのサービスのサービスIDを与える。サービスIDは、デバイス層からそのチャネル上で要求されたサービスを記述する。サービスIDは、単なる数字であってよい。セッション・マネージャ1712は、サービスを要求したコンポーネントにサービスIDを転送する。そして、コンポーネントは、そのチャネルでそのサービスを実行してほしい時、コプロセッサ・コマンド・ブロックでサービスIDを送る。しかしながら、コンポーネントは、或るサービスをそのチャネルと対応付けたい場合、そのチャネルIDと一緒にそのサービスIDを用いることはない。
【００７４】
本発明において行われるように、ポートをサービスにリンクすることによって、ハードウェアポートにおいて共同処理サポートを実行可能なこと、プラットフォームからのコンポーネントアーキテクチャ抽出、非専用IPCリンク上でトラフィックが問題になる場合の待ち時間問題の低減等を含む数多くの利点が得られる。セッション・マネージャ1712は、例えば、１つのポート上にトラフィックが多すぎると判断した場合、ポートの専用化をそれ自体で決定したり、コンポーネントから要求を受信したりできる。
【００７５】
本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。
【図面の簡単な説明】
【００７６】
【図１】本発明の実施形態に基づくIPCネットワークを示す図。
【図２】本発明の実施形態に基づくIPCスタックを示す図。
【図３】本発明の実施形態に基づくIPCコンポーネントIPC割当てを示す図。
【図４】本発明の実施形態に基づく主IPCテーブルを示す図。
【図５】本発明の実施形態に基づくチャネルアロケーションを示す図。
【図６】本発明の実施形態に基づくIPCクライアント初期化ルーチン時に関与するステップを強調表示して示す図。
【図７】本発明の実施形態に基づくIPCクライアント初期化時に関与するステップを強調表示して示すもう１つの図。
【図８】本発明の実施形態に基づく第１レベルのIPC隠蔽を強調表示して示す図。
【図９】本発明の実施形態に基づくIPCコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１０】本発明の実施形態に基づくコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１１】本発明の実施形態に基づくIPCクライアントとIPCサーバとの間のIPCデータ転送を示す図。
【図１２】本発明の実施形態に基づくIPCデータヘッダを示す図。
【図１３】本発明の実施形態に基づくIPCデータ要求時に行われるステップを示す図。
【図１４】本発明の実施形態に基づくIPCネットワークを示す図。
【図１５】本発明の実施形態に基づく無線通信装置等の電子装置を示す図。
【図１６】本発明の実施形態に基づく専用ポート(１つ又は複数)によるIPCプロトコルを示す図。
【図１７】本発明の実施形態に基づくスマート・ハードウェア・ポートの専用化要求時に行われるステップを示す図。
【図１８】本発明の実施形態に基づきポートが一旦専用化されたデータ転送を強調表示する図17の続きを示す図。
【特許請求の範囲】
【請求項１】
プロセッサ間通信(IPC)ネットワークにおいて、
IPCスタックであって、
プレゼンテーション・マネージャと、
前記プレゼンテーション・マネージャに接続されたセッション・マネージャと、
前記セッション・マネージャに接続されたデバイス・インタフェイスと、
を含む前記IPCスタックと、
前記IPCスタックに接続されたポートと、
前記IPCスタックに接続されたコンポーネントと、が含まれ、これによって、セッション・マネージャは、前記ポートの用途をコンポーネントに専用化し得るプロセッサ間通信(IPC)ネットワーク。
【請求項２】
請求項1に記載のIPCネットワークであって、前記コンポーネントには、ソフトウェア・スレッドが含まれるIPCネットワーク。
【請求項３】
請求項1に記載のIPCネットワークであって、前記セッション・マネージャは、前記コンポーネントからの要求の受信に応答して、前記ポートを専用化するIPCネットワーク。
【請求項４】
請求項1に記載のIPCネットワークであって、前記セッション・マネージャは、前記コンポーネントによる特定のサービス用途に前記ポートを専用化するIPCネットワーク。
【請求項５】
請求項4に記載のIPCネットワークであって、前記セッション・マネージャは、前記特定のサービスに対応するOPコードを前記ポートにリンクすることによって、前記ポートを専用化するIPCネットワーク。
【請求項６】
セッション・マネージャが含まれるプロセッサ間通信(IPC)スタックに接続された少なくとも１つのコンポーネントを有するプロセッサ間ネットワークにおいてポートを提供するための方法であって、
前記セッション・マネージャによって、特定タイプのサービスに前記ポートを専用化する段階と、
そのサービスを用いて、前記少なくとも１つのコンポーネントによって送信されたメッセージを前記ポートにルーティングする段階と、
が含まれる方法。
【請求項７】
請求項6に記載の方法であって、
前記ポートを専用化する段階には、前記サービスに対応する少なくとも１つのOPコードを前記ポートにリンクする段階が含まれる方法。
【請求項８】
請求項7に記載の方法であって、前記セッション・マネージャは、前記少なくとも１つのコンポーネントの内の１つからの要求の受信に応答して、前記ポートを専用化する方法。
【請求項９】
請求項7に記載の方法であって、前記セッション・マネージャが前記ポートの専用化を開始する方法。
【請求項１０】
請求項7に記載の方法であって、更に、
前記ポートを介して前記少なくとも１つのコンポーネントによって送信された前記ポートに対応付けられた前記少なくとも１つのOPコードを搬送するあらゆるメッセージをルーティングする段階が含まれる方法。
【請求項１】
プロセッサ間通信(IPC)ネットワークにおいて、
IPCスタックであって、
プレゼンテーション・マネージャと、
前記プレゼンテーション・マネージャに接続されたセッション・マネージャと、
前記セッション・マネージャに接続されたデバイス・インタフェイスと、
を含む前記IPCスタックと、
前記IPCスタックに接続されたポートと、
前記IPCスタックに接続されたコンポーネントと、が含まれ、これによって、セッション・マネージャは、前記ポートの用途をコンポーネントに専用化し得るプロセッサ間通信(IPC)ネットワーク。
【請求項２】
請求項1に記載のIPCネットワークであって、前記コンポーネントには、ソフトウェア・スレッドが含まれるIPCネットワーク。
【請求項３】
請求項1に記載のIPCネットワークであって、前記セッション・マネージャは、前記コンポーネントからの要求の受信に応答して、前記ポートを専用化するIPCネットワーク。
【請求項４】
請求項1に記載のIPCネットワークであって、前記セッション・マネージャは、前記コンポーネントによる特定のサービス用途に前記ポートを専用化するIPCネットワーク。
【請求項５】
請求項4に記載のIPCネットワークであって、前記セッション・マネージャは、前記特定のサービスに対応するOPコードを前記ポートにリンクすることによって、前記ポートを専用化するIPCネットワーク。
【請求項６】
セッション・マネージャが含まれるプロセッサ間通信(IPC)スタックに接続された少なくとも１つのコンポーネントを有するプロセッサ間ネットワークにおいてポートを提供するための方法であって、
前記セッション・マネージャによって、特定タイプのサービスに前記ポートを専用化する段階と、
そのサービスを用いて、前記少なくとも１つのコンポーネントによって送信されたメッセージを前記ポートにルーティングする段階と、
が含まれる方法。
【請求項７】
請求項6に記載の方法であって、
前記ポートを専用化する段階には、前記サービスに対応する少なくとも１つのOPコードを前記ポートにリンクする段階が含まれる方法。
【請求項８】
請求項7に記載の方法であって、前記セッション・マネージャは、前記少なくとも１つのコンポーネントの内の１つからの要求の受信に応答して、前記ポートを専用化する方法。
【請求項９】
請求項7に記載の方法であって、前記セッション・マネージャが前記ポートの専用化を開始する方法。
【請求項１０】
請求項7に記載の方法であって、更に、
前記ポートを介して前記少なくとも１つのコンポーネントによって送信された前記ポートに対応付けられた前記少なくとも１つのOPコードを搬送するあらゆるメッセージをルーティングする段階が含まれる方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公表番号】特表２００７−５２７５６６（Ｐ２００７−５２７５６６Ａ）
【公表日】平成１９年９月２７日（２００７．９．２７）
【国際特許分類】
【出願番号】特願２００６−５１８７３３（Ｐ２００６−５１８７３３）
【出願日】平成１６年６月３０日（２００４．６．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２１０１０
【国際公開番号】ＷＯ２００５／００８４７５
【国際公開日】平成１７年１月２７日（２００５．１．２７）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成１９年９月２７日（２００７．９．２７）
【国際特許分類】
【出願日】平成１６年６月３０日（２００４．６．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２１０１０
【国際公開番号】ＷＯ２００５／００８４７５
【国際公開日】平成１７年１月２７日（２００５．１．２７）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]