JP2007500474A

JP2007500474A - サービス品質保証及び選択的ブロードキャストを提供するプロセッサ間通信プロトコル

Info

Publication number: JP2007500474A
Application number: JP2006521897A
Authority: JP
Inventors: カワンド、シャーベル; リウ、ビン; カワンド、ジーン; ダブリュ．ミラー、ジアンピン
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2003-07-29
Filing date: 2004-07-20
Publication date: 2007-01-11
Also published as: EP1652101A1; KR20060041301A; US20050027824A1; WO2005013140A1; KR100812680B1

Abstract

プロセッサ間通信（ＩＰＣ）プロトコル・ネットワーク（１００）は、１つ以上のＩＰＣクライアント（１０２）と、ＩＰＣサーバ（１０８）とを備える。ＩＰＣプロトコルにより、ＩＰＣクライアント（１０２）がＩＰＣサーバ（１０８）に登録することが可能となる。これにより、各々依存するソフトウェア・アーキテクチャ、オペレーティングシステム、ハードウェア等に対して何ら制約を課すことなく、両者が自在に通信するための手段が提供される。本発明の一実施形態のＩＰＣプロトコルにより、コンポーネントは異なるサービス品質（ＱｏＳ）を動的に要求することが可能となる。別の実施形態では、ＩＰＣノードは送信者により選択されるノードに対しメッセージを選択的にブロードキャストすることが可能である。

Description

本発明は電子工学の分野に関する。より詳細には、本発明は、サービス品質（ＱｏＳ）保証及び選択的ブロードキャスト機能を提供するプロセッサ間通信（ＩＰＣ）プロトコル／ネットワークに関する。

大抵の電子工学システムは、ハードウェア及びソフトウェア等、システムを形成する多数のネットワーク化された要素（コンポーネント）を備える。大抵の電子工学システムには、ネットワーク化された要素を形成する異なるコンポーネント間の通信や、異なるネットワーク化された要素自身の間の通信を担う層が存在する。この層は、通常、プロセッサ間通信（ＩＰＣ）層と呼ばれる。

最近の数年において、プロセッサ間通信を処理するために幾つかのプロトコルが導入されている。ＩＰＣ製品の一例は、ホスト−ＰＣＩブリッジ、動的ランダム・アクセス・メモリ（ＤＲＡＭ）コントローラ、及びデータ・パスと、アクセラレーテッド・グラフィックス・ポート（ＡＧＰ）インタフェースとを統合する、ＰＣＩＡＧＰコントローラ（ＰＡＣ）である。ＩＰＣ製品の別の例は、ＯＭＡＰ（登録商標）プラットフォームである。いずれのプラットフォームにおいても、低位のコンポーネント、即ち、チャネルレベル（ハードウェアレベル）における設計の柔軟性は提供されていない。

例えば、ＰＡＣプラットフォームは非公開のアーキテクチャであり、オペレーティングシステムのＴＡＰＩ層に埋め込まれているため、開発者がＩＰＣコードにアクセスすることは不可能である。したがって、それらのプラットフォームはコンポーネントレベルまで拡張されないため、ＩＰＣリソースの動的割り当てや、サービス性能のコンポーネントによる判定は不可能であり、多ノード経路制御は提供されない。

実時間処理に関する主な問題のうちの１つは、異なる移動体アプリケーション（ＭＡ）上で動作する全ての参加ソフトウェアコンポーネントに対し、サービス品質（ＱｏＳ）保証が必要なことである。例えば、携帯無線通信デバイスが、モトローラ（Ｍｏｔｏｒｏｌａ）社のｉＤＥＮ（商標）広域ローカル・エリア・ネットワーク（ＷＬＡＮ）ベースバンドＭＡと共に、ＰＣＳＳＹＭＢＩＡＮ（登録商標）系アプリケーション・プロセッサを備える場合がある。一般に、ソフトウェア・コンポーネントは、ＱｏＳや、ＱｏＳが如何にして保証され得るかを認識しない。従来技術システムにおいては、一定レベルのハードウェア性能保証を必要とするコンポーネントは、異なるハードウェア・プラットフォームに関して異なって調整される必要がある。密結合システムの個々のコンポーネントに一定のハードウェア性能レベル（例えば、一定量のデータ帯域幅）を保証することが必要な場合、通常、ＩＰＣをプラットフォーム固有とするような手法によりＱｏＳ要件を調整する必要がある。当然のことながら、このことはデバイスの移植性（再利用）において大きな問題である。

従来技術のＩＰＣシステムにより経験される別の問題は、事前割り当て（ｐｒｅ−ａｓｓｉｇｎｍｅｎｔ）に関する問題である。事前割り当てにおいては、ＩＰＣにてデータを送受信するために編集する（ｃｏｍｐｉｌｅ）ことが必要なデータ帯域幅を、各ソフトウェア・コンポーネントに予め認識させる。ＩＰＣチャネルの事前割り当てにおいては、ＩＰＣにおける同じ正確なチャネル割り当てを全てのＭＡに所有させるが、これは現代の市場において所望される解決法ではない。また、事前割り当てにおいてはコンポーネントにチャネル及びそのコンポーネントのリソースをブロックさせるが、コンポーネントがチャネル・リソースを使用していない場合、さらなる非効率を生じる。したがって、当該技術分野においては、従来技術の欠点のうちの幾つかを解決し得るＩＰＣプロトコルが必要である。

本発明の一実施形態においては、ＩＰＣネットワークに接続されたコンポーネントは異なるＱｏＳレベルを動的に要求することが可能である。ＱｏＳは優先度及びデータレートに関して保証されるが、保証されるパラメータはそれらに限定されず、ＱｏＳ手法により他のＱｏＳ因子を考慮に含めることも可能である。ＩＰＣにおいてＱｏＳを保証することの利点は、プラットフォームからのアーキテクチャ抽象化や、異なるＭＡ間におけるコンポーネント移植性である。

本発明の選択的ブロードキャスト機能により、ＩＰＣノードがメッセージを送信し、ＩＰＣネットワークに接続されたＩＰＣノードを選択することが可能となる。送信者により選択されたノードに対しＩＰＣサーバがブロードキャスト・メッセージを送信することが可能であるように、ネットワークはフィルタ・テーブルを使用する。また、ＩＰＣノードにより、ＩＰＣリンクを介してフィルタ・テーブルが動的に更新されることも可能である。本発明の一実施形態においては、選択的ブロードキャスト機能により動的な方法が可能となり、この方法により、ソフトウェア・コンポーネントは異なるＭＡ上の他のソフトウェア・コンポーネントと通信することが可能である。これにより、一部の従来技術システムの場合のように専用のＩＰＣ帯域幅及びチャネルからなる固定された組にＭＡを構成することは、不要となる。また、ＩＰＣスタック及びＩＰＣスタックに接続されたハードウェアは、コンポーネントが必要に従い異なるリンクを選択して通信することが可能であるように抽象化される。

最初にＩＰＣネットワークを説明し、続いて本発明のＱｏＳ及び選択的ブロードキャスト機能を説明する。
本発明のＩＰＣにより、ＩＰＣネットワーク内で動作する異なるプロセッサが相互に通信するために必要なサポートが提供される。例えば、アプリケーション・プロセッサ（ＡＰ）及びベースバンド・プロセッサ（ＢＰ）を備える無線通信デバイス用のデュアル・プロセッサ無線アーキテクチャにおいては、本発明のＩＰＣにより、効率的な手法にてプロセッサが相互に通信するために必要なサポートが提供される。本発明のＩＰＣにおいては、このサポートは、ＡＰ又はＢＰの設計に対して何ら制約を課すことなく提供される。

本発明のＩＰＣにより、プロセッサ間通信スタックとして本発明のＩＰＣを採用する任意のプロセッサは、共通のオペレーティングシステム及びメモリを共有する同じプロセッサ・コア上で２つのプロセッサが実際に動作しているように共存して動作することが可能となる。基準となる通信デバイスにおいて複数のプロセッサを用いる場合、本発明のＩＰＣにより、異なるプロセッサ間において信頼性のある通信が提供される。

ＩＰＣハードウェアは、異なるプロセッサをＩＰＣネットワークへ接続する物理接続を提供する。本発明の一実施形態では、異なるホスト間で非同期にデータ・パケットが輸送される。ＩＰＣネットワークに接続されたプロセッサは、静的又は動的に割り当てられた自身の物理アドレス及び論理アドレスを有する（例えば、ＩＰＣアドレス）。また、本発明の一実施形態ではデータ・パケットはＩＰＣネットワーク内の任意の方向へ流れ得るため、パケットは、そのパケットが到達することを試みるプロセッサの宛先アドレスを有する。また、パケットは公知の巡回冗長検査（ＣＲＣ）手法を用いて誤りを検査される。本発明のＩＰＣネットワークのネットワーク・アクティビティは、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）ネットワーク等、ＩＰトランスポート層を用いるインターネットのネットワークにおいて見出されるネットワーク・アクティビティと何らかの類似性を有する場合がある。しかしながら、本発明のＩＰＣネットワークは、ＴＣＰ／ＩＰネットワークにおけるように、ゲートウェイを備えた小さなネットワークに分割されない。

ここで図１を参照する。図１には、本発明の一実施形態によるＩＰＣネットワーク１００を示す。ＩＰＣネットワーク１００は、複数のＩＰＣクライアント１０２〜１０６と、ＩＰＣサーバ１０８とを備える。図の例に示すように、ＩＰＣサーバ１０８は共有メモリ１１０、ユニバーサル非同期受信機／発信機（ＵＡＲＴ）１１２及びユニバーサル・シリアル・バス（ＵＳＢ）１１４等、異なるＩＰＣ物理リンクを用い、ＩＰＣクライアント１０２〜１０６に接続されている。なお、本発明のＩＰＣにおいては、ＩＰＣクライアント１０２〜１０６は現在のＩＰＣサーバ１０８と交渉（ｎｅｇｏｔｉａｔｅ）し、役割を交換することが可能である。ＩＰＣクライアント１０２〜１０６がＩＰＣサーバとなるよう交渉し、新たなＩＰＣサーバとなる場合、残りのＩＰＣクライアントの全ては、ＩＰＣサーバの変更によりサーバのＩＰアドレスを変更するように指示される。

図２には、本発明の一実施形態によるＩＰＣサーバ１０８（又はＩＰＣクライアント１０２〜１０６）のＩＰＣスタック２００を示す。ＩＰＣスタック２００は、オペレーティングシステム（ＯＳ）の下で統合され、かつ、コンポーネント・トラフィックに関するプロセッサ間通信の必要のサポートを提供するように設計されている。ＩＰＣスタックは、次の３つの主な層から構成される。

（１）ＩＰＣプレゼンテーション・マネージャ（２０２）：この層は、異なるシステム・コンポーネント（例えば、ソフトウェア・スレッド）間において異なるデータ型を翻訳するために用いられる。

（２）ＩＰＣセッション・マネージャ（２０４）：この層は、ＩＰＣスタックと全てのシステム・コンポーネントとの間の全ての着信／発信ＩＰＣトラフィックに対する中央リポジトリである。ＩＰＣセッション・マネージャ２０４は、参加ＩＰＣコンポーネントに対するコンポーネントＩＤの割り当て、ＩＰＣデータのカプセル化が必要か否かの決定、ＩＰＣデータの経路制御、ＩＰＣトラフィックの中断、ＩＰＣプロセッサのプレースホルダ（ｐｌａｃｅｈｏｌｄｅｒ）、ＩＰＣアドレスの提供、ＩＰＣクライアントの割り当て及び認証等、幾つかの機能を有する。

ＩＰＣトランスポート層（２０８）：ＩＰＣセッション・マネージャ（層）２０４内に存在し、異なるプロセッサ間においてＩＰＣデータを輸送するための非常に基本的な巡回冗長検査を提供する。加えて、ＩＰＣトランスポート層２０８は、ＩＰＣメッセージのＩＰＣネットワーク１００における最終宛先までの経路制御を担う。トランスポート層の経路制御機能は、ＩＰＣサーバにおいてのみ有効である。

ＩＰＣルータ・ブロック（２１０）：ＩＰＣデータを宛先コンポーネント（図示せず）へ輸送する。着信のＩＰＣメッセージは、特に、発信者コンポーネントＩＤと、「オーディオおよびモデム（ＡｕｄｉｏａｎｄＭｏｄｅｍ）」等のＩＰＣメッセージ・オプコードとを有する。なお、本発明の一実施形態においては、ＩＰＣネットワークに接続された「オーディオおよびモデム」等、各コンポーネント／ソフトウェア・スレッド（例えば、図５の５０２を参照）に対し、ユニークなオプコードが割り当てられる。ＩＰＣセッション・マネージャ２０４はルータ・ブロック２１０により、正しいコンポーネントに対しＩＰＣデータを送信する。

（３）デバイス・インタフェース層（２０６）：ＩＰＣ物理チャネル−論理ＩＰＣチャネルの管理を担う。主な機能は、スタックＩＰＣがハードウェアから独立するようにＩＰＣハードウェアを完全に抽象化することである。デバイス・インタフェース層２０６は、全てのＩＰＣ論理チャネルをサポートするように、ＩＰＣリンク下の物理帯域幅を管理する。着信パスにおいて、デバイス・インタフェース層２０６は異なる物理チャネル１１０〜１１４からデータを選定し、そのデータをＩＰＣスタックの残部分へ渡す。発信パスにおいては、デバイス・インタフェース層２０６はデータを適切な物理チャネル上で送信することにより、ＩＰＣ論理チャネルのデータ負荷を管理する。また、デバイス・インタフェース層２０６は、ＩＰＣハードウェアに対しＩＰＣパケットを送信する前に、同じＩＰＣチャネルに属するＩＰＣパケットの連結を処理する。チャネル要件は、ＩＰＣセッション・マネージャ２０４とＩＰＣデバイス・インタフェース層２０６との間において、予め交渉される。デバイス・インタフェース層２０６がハードウェア・ポートを提供し、ハードウェア・ポートがＩＰＣクライアント１０２〜１０６に対するデバイス・インタフェースを提供する。

図３には、ＩＰＣコンポーネントＩＤ割り当てルーチンを示す。工程３０２にて、ＩＰＣ通信に参加することを所望する新たなコンポーネントは、最初に工程３０２にてＩＰＣセッション・マネージャ（例えば、セッション・マネージャ２０４等）にＩＰＣ識別番号（ＩＤ）を要求する必要がある。続いて、ローカル・セッション・マネージャ（例えば、そのコンポーネントが接続されているクライアントに存在するセッション・マネージャ）はＩＰＣサーバのセッション・マネージャに新たなＩＰＣコンポーネントをアラートし、工程３０４にて、コンポーネントＩＤ割り当てが提供される。本発明の一実施形態では、コンポーネントＩＤは動的であり、セッション・マネージャ（例えば、サーバのセッション・マネージャ）により再割当されることが可能である。大抵の場合、主なＩＰＣサーバの位置は主ＡＰ上である。各ＩＰＣノードはユニークなＩＰＣノードＩＤを有し、セッション・マネージャは各参加ＩＰＣノードに対する以下の情報を自身のデータベースに保持する。
・ＩＰＣノード型：例えば、特定のＢＰ又はＡＰ、無線ローカル・エリア・ネットワーク（ＷＬＡ）、ＡＰ等。
・ＩＰＣアドレス：ＩＰＣノードのＩＰＣアドレス。
・データ型：ＩＰＣノードのデータ型。
・オプコードのリスト：コンポーネントにサブスクライブ（ｓｕｂｓｃｒｉｂｅ）された全てのＩＰＣメッセージのオプコードのリスト。
・コンポーネントＩＤ：全てのコンポーネントＩＤのリスト。

ここで図４を参照する。図４には、ＩＰＣスタックと共に、全ての主なＩＰＣテーブルを示す。動的経路制御テーブル４０２は、ノード型、ＩＰＣアドレス／ポート番号情報、データ型、及びサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）・リストを含む。コンポーネント経路制御テーブル４０４は、オプコード情報と各特定のオプコードにサブスクライブした全てのコンポーネントとをリンクする情報を含む。最後に、チャネル・リソース・テーブル４０６は、各チャネルＩＤと物理チャネルＩＤのリストとのリンクを含む。

図５には、本発明の一実施形態においてＩＰＣスタックがソフトウェア・スレッド等（例えば、オーディオ等）のコンポーネントにＩＰＣチャネルを提供する手法のブロック図を示す。最初に、工程５０４にて、コンポーネント５０２がＩＰＣチャネルを要求する。工程５０６にて、図５に示すセッション・マネージャは定義済みＡＰＩを用い、コンポーネントの要求をデバイス層と交渉する。続いて、デバイス層（デバイス・インタフェース）はデータ・チャネル５０８等のハードウェア・リソースを要求する。この要求に応答して、工程５１０にて、図５に示すセッション・マネージャは要求者にＩＰＣチャネルを許可する。次に、コンポーネント５０２は割り当てられたチャネル５０８上でデータを送信する。続いて、デバイス層はＩＰＣネットワークへデータを転送する。論理チャネルの物理チャネルＩＤへのマッピングは、ＩＰＣデバイス・インタフェースの機能である。

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

図７には、ＩＰＣクライアント初期化処理において実行される工程をより詳細に示す。工程７０２にて、クライアント・セッション・マネージャ（図には、セッション（クライアント）、として示す）は、ＩＰＣサーバのセッション・マネージャ（図には、セッション（サーバ）、として示す）に対し、構成要求を送信する。工程７０４にて、ＩＰＣサーバのセッション・マネージャにより認証が要求される。続いて、工程７０６にて、ＩＰＣクライアントとＩＰＣサーバとの間の認証が実行される。

構成要求のパラメータにはノード型及びデータ型が含まれる。工程７０２の構成要求に応答して、セッション・サーバは要求者にＩＰＣアドレスを割り当てる。また、要求者に対する動的経路制御テーブルが存在しない場合、要求者に対する動的経路制御テーブルも設定する。続いて、工程７０８にて、要求者に構成表示を送信する。構成表示のパラメータには、サーバのＩＰＣアドレスと、新たに割り当てられたクライアントのＩＰＣアドレスとが含まれる。

構成表示の受信に応答して、セッション・クライアントに接続されたコンポーネントはクライアントのセッション・マネージャに制御／データを要求することが可能である。続いて、工程７１０にて、セッション・クライアントはセッション・サーバに対し構成表示確認メッセージを送信する。「構成表示確認」メッセージにはパラメータは存在しない。工程７１０にて構成表示確認メッセージを受信すると、セッション・サーバは新たに構成されたセッション・クライアントに対しＩＰＣストリームを初期化することが可能である。続いて、工程７１２，７１４において、セッション・サーバはセッション・クライアントに対し構成更新メッセージを送信する。これにより、図７に示すセッション・クライアントの両方は、それぞれの動的経路制御テーブル（図示せず）を更新し、工程７１６，７１８にて、構成更新確認メッセージをセッション・サーバに対し送信する。構成更新確認メッセージを受信することにより、セッション・サーバは全てのＩＰＣ参加者が更新されたことを確認する。

ＩＰＣセッション・マネージャは、発信元コンポーネントＩＤ、宛先ＩＤ、チャネルＩＤ、及びＢＰ又はＡＰの型を含むデータ形式にてパケットを受信する。宛先ＩＤが挿入されていない場合、ＩＰＣセッション・マネージャは宛先コンポーネントＩＤを追加する。また、ＩＰＣセッション・マネージャはＩＰＣアドレスも挿入する。受信したメッセージ・オプコードに基づき宛先ＩＤを発見するのは、ＩＰＣセッション・マネージャである。宛先ＩＤは参照テーブルに基づく。この参照テーブルは、コンポーネントが新たなＩＰＣメッセージ・オプコードにサブスクライブする（例えば、オーディオ・コンポーネントはＩＰＣセッション・マネージャに要求を送信することにより、オーディオ・メッセージにサブスクライブする）毎に動的に更新される。

図８には、本発明の一実施形態によるコンポーネントと、そのＩＰＣセッション・マネージャとの間の一般的な宛先ＩＤ発見シーケンスにおけるイベントのシーケンスを示す。工程８０２にて、コンポーネントは、その発信元ＩＤ、宛先ＢＰ又はＡＰの型、並びにヘッダ及びデータを含むＩＰＣデータを送信する（宛先ＩＤは送信しない）。工程８０４にて、対応する動的経路制御テーブルを参照して正しい宛先アドレスを見出すため、ＩＰＣセッション・マネージャはＩＰＣデータ・ヘッダ・オプコードと、宛先ＢＰ又はＡＰの型とを参照する。工程８０６にて、ＩＰＣセッション・マネージャはコンポーネントのＩＰＣアドレスを挿入し、デバイス層へ送信する。

図９には、ＩＰＣコンポーネント初期化において実行される通常の工程を示す。図９に示すＩＰＣサーバによりＢＰが構成されると、コンポーネント９０２等のコンポーネントは異なるサービスにサブスクライブすることが可能となる。工程９０４にて、コンポーネントはオーディオ、ビデオ等の機能をサブスクライブする。続いて、コンポーネントＩＤ作成（まだＩＤが割り当てられていない場合）と、特定のＩＰＣアドレスに対する動的経路制御テーブルの作成又は更新とのため、コンポーネント・サブスクリプション情報がＩＰＣセッション・マネージャに対し送信される（工程９０６）。工程９０６からの情報により、工程９０８にて、セッション・マネージャはＩＰＣサーバを更新する。工程９１２にて、ＩＰＣサーバはＩＰＣクライアントに対し動的経路制御テーブルの確認を送信する。サーバがアラートされると、工程９１０にて、新たな動的経路制御テーブル更新が全ての参加プロセッサに対しブロードキャストされる。

図１０には、コンポーネント（クライアント）１００２、セッション（クライアント）１００４、及びセッション（サーバ）１００６の間における、同じコンポーネント初期化処理を示す。セッション（クライアント）１００４は、クライアント・セッション・マネージャとしても周知であり、セッション（サーバ）１００６は、サーバ・セッション・マネージャとしても周知である。工程１００８にて、コンポーネント（クライアント）１００２はコンポーネント構成要求を送信する。この要求に応答して、クライアント・セッション・マネージャ１００４は、そのデバイス層（図示せず）と論理チャネルを交渉する。また、クライアント・セッション・マネージャ１００４はコンポーネントＩＤを割り当て、その動的経路制御テーブル（図示せず）に新たなオプコードのリストを追加する。工程１０１０にて、クライアント・セッション・マネージャ１００４は、パラメータとしてコンポーネントＩＤ及びチャネルＩＤを含む構成応答を送信する。この構成応答に応答して、コンポーネント（クライアント）１００２は、そのＩＤ及びチャネルＩＤをクライアントのセッション・マネージャ１００４から受信する。

クライアント・セッション・マネージャ１００４は、工程１０１０にて工程１００８の構成要求に対し応答すると、セッション・サーバ１００６に対し構成更新要求を送信する（工程１０１２）。構成更新要求のパラメータは、動的経路制御テーブルにおいてなされた任意の新たな変更である。セッション・マネージャは、そのＩＰＣアドレスに対する動的経路制御テーブルを更新する。続いて、サーバ・セッション・マネージャ１００６は、工程１０１４にてそのＩＰＣクライアントに対し構成更新表示を送信し、工程１０１６にて全てのＩＰＣクライアントに対し構成更新を送信する。サーバのセッション・マネージャ１００６は、送信された変更によりＩＰＣサーバがその経路制御テーブルを更新したことを確認する。

パラメータとして動的経路制御テーブルを含む、工程１０１６の構成更新メッセージにおいて、セッション・サーバ１００６は動的経路制御テーブルを更新し、工程１０１８にて構成更新確認メッセージを送信する。続いて、セッション・サーバ１００６は全てのＩＰＣ参加者が更新されたことを確認する。

ＩＰＣセッション・マネージャは、着信及び発信ＩＰＣパケットの経路制御パスを決定する。発信パケットの経路は、コンポーネントのＩＰＣアドレスにより決定される。宛先アドレスがローカル・プロセッサのアドレスであった場合、そのセッション・マネージャ内においてオペレーティングシステム（ＯＳ）に対するＩＰＣのマッピングが実行される。宛先アドレスがローカルＩＰＣクライアントであった場合、さらなる処理（例えば、カプセル化）のため、パケットはＩＰＣスタックに対し送信される。なお、宛先コンポーネントがＩＰＣパケットを送信するコンポーネントと同じプロセッサに存在する場合、カプセル化は不要であり、パケットは通常のＯＳメッセージ呼出（例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）メッセージ・キュー等）を介して渡される。この手法においては、コンポーネントはその入力方式の修正について考慮する必要はなく、メッセージ・ポスト方法をＯＳ固有設計からＩＰＣ呼出へ変更することのみが必要である。

着信パケットにおいては、メッセージの宛先アドレスがＩＰＣサーバのアドレスと等しくない場合、着信パケットは適正なＩＰＣクライアントへと経路制御される。着信パケットの経路制御はＩＰＣサーバのセッション・マネージャにより扱われる。メッセージの宛先アドレスがＩＰＣサーバのアドレスと等しい場合、そのメッセージは、コンポーネント宛先ＩＤが有効なコンポーネントＩＤに設定されているか否か、又は０ＸＦＦに設定されているか否かに応じて、１つ以上の正しいコンポーネントに対し転送される。

ＩＰＣルータ・ブロックはＩＰＣデータを宛先コンポーネントに輸送する。着信ＩＰＣメッセージは、特に、発信者コンポーネントＩＤと、オーディオ、モデム等に対するオプコード等、ＩＰＣメッセージ・オプコードとを有する。ＩＰＣセッション・マネージャは、コンポーネント経路制御テーブルにより、ＩＰＣデータを１つ以上の正しいコンポーネントに対し送信する。動的経路制御テーブル及びコンポーネント経路制御テーブルの両方は、ＩＰＣサーバ／クライアントにより更新される。

起動中、各コンポーネントは自身をセッション・マネージャに登録し、ＩＰＣコンポーネントＩＤを取得する必要がある。加えて、各コンポーネントは、オーディオ、モデム等の着信ＩＰＣメッセージにサブスクライブする必要もある。この情報は、ＩＰＣセッション・マネージャによる使用のため、コンポーネント経路制御テーブルに記憶される。

図１１に示すように、工程１１０４にてコンポーネント１１０２がＩＰＣセッション・マネージャに対しデータ要求を送信するとき、宛先ＩＰＣノード（例えば、ＢＰ）に対し検査が行われる。ＩＰＣノードがＩＰＣメッセージ・オプコードをサポートしない場合、エラー応答がコンポーネント１１０２に返される。エラー応答に加えて、ＩＰＣセッション・マネージャは、その特定のオプコードを受信することが可能な全てのＩＰＣノードの更新を返す。コンポーネントがメッセージを再送信するＩＰＣノードは、コンポーネントにより決定される。ＩＰＣセッション・マネージャ１１０６は、宛先コンポーネントがＩＰＣネットワーク内に存在するがローカル・プロセッサ内には存在しないと判定した場合、ＩＰＣネットワークにてデータを送信する前に、ＩＰＣヘッダ情報を用いてデータをカプセル化する。

図１２には、本発明の一実施形態によるＩＰＣデータ・ヘッダ１２０２を示す。ヘッダは、ＩＰＣルータにより提供される発信元ＩＰＣアドレス、宛先ＩＰＣアドレス、発信元ポート及び宛先ポートと、ＩＰＣトランスポートにより提供される長さ及びチェックサム情報と、セッション・マネージャにより提供される発信元ＩＰＣコンポーネント及び宛先ＩＰＣコンポーネントとを含む。メッセージ・オプコード、メッセージ長さ及びＩＰＣデータは、コンポーネント１２０４により提供される。

図１３には、本発明の一実施形態による典型的なＩＰＣデータ要求を示す。工程１３０２にて、コンポーネントが更新要求を送信する。コンポーネント更新パラメータは、ノード型及びオプコードを含む。コンポーネントは宛先オプコードをサポートするノード型を調査する。ノード型が０ＸＦＦに等しい場合、セッション・マネージャは全てのＩＰＣ参加者の全てのノード・テーブルに対しコンポーネント情報を送信する。オプコード・フィールドが０ＸＦＦに等しい場合、セッション・マネージャはコンポーネントに対し、指定されたノード型に属するオプコードのリストを送信する。また、オプコードが特定の値である場合、セッション・マネージャはコンポーネントに対し、その特定のオプコードをノード型がサポートするか否かに対応する真偽値を送信する。

工程１３０４にて、コンポーネントに対しコンポーネント更新表示が送信される。ノード型が０ＸＦＦに等しい場合、ノード・テーブルがコンポーネントに返される。オプコード・フィールドが０ＸＦＦに等しい場合、オプコードのリストがコンポーネントに返される。しかしながら、オプコードが特定の値である場合、真偽メッセージが返される。工程１３０６にて、コンポーネント・データ要求が行われる。コンポーネント・データ要求のパラメータは、ノード型、ＩＰＣメッセージ・オプコード、ＩＰＣメッセージ・データ、チャネルＩＤ及びコンポーネントＩＤを含む。コンポーネント・データ要求において、セッション・マネージャはノード型を検査し、オプコードがサポートされるか否かを判定する。ノード型がオプコードをサポートしない場合、工程１３０８にてコンポーネント更新表示が送信される。しかしながら、ノード型がオプコードをサポートする場合、工程１３１０にてデバイス層に対しデータ要求が送信される。データ要求パラメータは、ＩＰＣメッセージ、チャネルＩＤ及びＩＰＣヘッダを含む。

デバイス層はチャネルＩＤに基づき、データ要求メッセージの送信をスケジューリングする。デバイス層はポート番号ヘッダ情報に基づき、ＩＰＣハードウェアを選択する。データがコミットされると、工程１３１２にて、セッション・マネージャに対しデータ確認メッセージが送信される。工程１３１４にて、セッション・マネージャはコンポーネントに対しコンポーネント・データ確認メッセージを送信する。コンポーネントは、さらなるＩＰＣメッセージを送信する前に、確認を待機することが可能である。データ確認が受信されると、コンポーネントは次のＩＰＣメッセージを送信することが可能である。

工程１３１６にて、デバイス層はＩＰＣメッセージ・データ及びＩＰＣヘッダを含むデータ表示メッセージを送信する。セッション・マネージャはメッセージの宛先ＩＰＣヘッダを検査し、ローカルＩＰＣアドレスと異なる場合、そのメッセージを正しいＩＰＣノードに送信する（経路制御する）。工程１３１０にて、セッション・マネージャは予約済みチャネルＩＤを用い、デバイス層に対しデータ要求を送信する。セッション・マネージャは宛先コンポーネントＩＤを検査し、０ＸＦＦに等しい場合、そのオプコードにサブスクライブした全てのコンポーネントに、そのメッセージを経路制御する。工程１３１８にて、セッション・マネージャはコンポーネント・データ表示メッセージを送信し、コンポーネントはＩＰＣデータを受信する。

ＩＰＣスタックは、全ての参加ＩＰＣノードの間における通信のため、予約済み制御チャネルを用いる。起動時、このリンクを用いて、ＩＰＣサーバのセッション・マネージャはＩＰＣクライアントにメッセージをブロードキャストし、反対に、ＩＰＣクライアントはＩＰＣサーバのセッション・マネージャにメッセージをブロードキャストする。通常の動作中、この制御チャネルは、全てのＡＰ及びＢＰの間において制御情報を搬送するために用いられる。

図１４には、ＩＰＣスタックとＩＰＣハードウェアとの間に存在する制御チャネル１４０２〜１４０６を示す。異なるＩＰＣハードウェア間においてデータを送信するとき、データ・パケット１４１０と共に制御チャネル情報１４０８も送信される。ＩＰＣクライアントは最初にＩＰＣ制御チャネル上で構成要求をブロードキャストする。ＩＰＣサーバはブロードキャストを受信し、そのクライアントに対するＩＰＣアドレスにより応答する。このＩＰＣアドレスは、その特定のプロセッサ（ＡＰ又はＢＰ）に対する動的経路制御テーブルに関連付けられる。

［ＩＰＣアプリケーション・プログラム・インタフェース（ＡＰＩ）］
本発明のＩＰＣプロトコルのＡＰＩのうちの一部を以下に挙げる。
１）コンポーネント・インタフェースからＩＰＣセッション・マネージャへ
ＣｒｅａｔｅＣｏｍｐｏｎｅｎｔＩｎｓｔ（）：
ＩＰＣセッション・マネージャにコンポーネント・データベースを作成する。コンポーネント・データ型（ビッグ・エンディアンかリトル・エンディアンか）及びメッセージ・オプコードに対するサブスクリプション等の情報は、ＩＰＣアドレスに属する動的データ経路制御テーブルにおいて用いられる。

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

ＯｐｅｎＣｈａｎｎｅｌ（）：
ＩＰＣチャネルを開き、利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）を発行する。パラメータは、ＯｐｅｎＣｈａｎｎｅｌＫｅｅｐ（）にて原始的に用いられるパラメータと同じである。

ＯｐｅｎＣｈａｎｎｅｌＷＴｈｒｕ（）：
ＩＰＣチャネルを開き、利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）を発行する。これは、このチャネル上でカプセル化が無効とされることを示すライト・スルー・チャネル（ｗｒｉｔｅｔｈｒｕｃｈａｎｎｅｌ）の要求である（例えば、非ＵＤＰＡＴコマンド）。

ＣｌｏｓｅＣｈａｎｎｅｌ（）：
ＩＰＣチャネルを閉じることを要求する。もはやコンポーネントはチャネルを必要としない。続いてリソースが解放される。

ＣｈａｎｎｅｌＧｒａｎｔ（）：
チャネルが要求者に対し許可される。まだチャネルＩＤが割り当てられていない場合、ＩＰＣセッション・マネージャはチャネルＩＤを割り当てる。

ＣｈａｎｎｅｌＥｒｒｏｒ（）：
チャネル誤りが発生。チャネルは閉じられ、要求者に通知される。
ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）：
チャネル上のデータが配信されることが要求者にアラートされる。このメッセージは、ＩＰＣプレゼンテーション・マネージャにより対象のコンポーネントに対し送信される。これには制御チャネル・データも含まれる。

ＤａｔａＣｈａｎｎｅｌＲｅｑｕｅｓｔ（）：
要求者は開かれたチャネル上でデータを送信することを所望する。これには制御チャネル・データも含まれる。

ＣｈａｎｎｅｌＣｌｏｓｅ（）：
ＩＰＣチャネルを閉じることを要求する。チャネル無効化タイマの期限が経過し、タイムアウトに関連するチャネルが閉じられる。チャネル誤りによることも可能である。

２）ＩＰＣセッション・マネージャからＩＰＣデバイス・インタフェースへ／ＩＰＣデバイス・インタフェースからＩＰＣセッション・マネージャへ
ＯｐｅｎＣｈａｎｎｅｌ（）：
論理ＩＰＣチャネルを開き、利用可能な場合、ＣｈａｎｎｅｌＧｒａｎｔ（）を発行する。ＩＰＣセッション・マネージャはＩＰＣデバイス・インタフェース・マネージャに対しチャネル優先度要求を送信する。

ＣｌｏｓｅＣｈａｎｎｅｌ（）：
ＩＰＣ論理チャネルを閉じることを要求する。コンポーネントは、もはやチャネルを必要としないことを決定する。

ＣｈａｎｎｅｌＧｒａｎｔ（）：
論理チャネルが要求者に対し許可される。
ＣｈａｎｎｅｌＥｒｒｏｒ（）：
チャネル誤りが発生（例えば、着信データにおけるＣＲＣ不良、又は物理チャネル不良）。

ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）：
チャネル上のデータが配信されることが要求者にアラートされる。
ＤａｔａＣｈａｎｎｅｌＲｅｑｕｅｓｔ（）：
要求者は論理チャネル上でデータを送信することを所望する。

３）ＩＰＣセッション・マネージャからＩＰＣプレゼンテーション・マネージャへ
ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）：
チャネル上のデータが配信されることが要求者にアラートされる。この情報は、正しいデータ・フォーマットにより対象のコンポーネントに対し転送される。

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

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

ＣｈａｎｎｅｌＧｒａｎｔ（）：
物理チャネルが要求者に対し許可される。
ＣｈａｎｎｅｌＥｒｒｏｒ（）：
チャネル誤りが発生（例えば、着信データにおけるＣＲＣ不良、又は物理チャネル不良）。

ＣｈａｎｎｅｌＤａｔａＩｎｄｉｃａｔｉｏｎ（）：
チャネル上のデータが配信されることが要求者にアラートされる。
ＤａｔａＣｈａｎｎｅｌＲｅｑｕｅｓｔ（）：
要求者は物理チャネル上でデータを送信することを所望する。

図１５には、無線通信デバイス（例えば、セルラー電話機等）１５００等の電子デバイスのブロック図を示す。無線通信デバイス１５００は、ＩＰＣネットワークを用いて相互に通信するベースバンド・プロセッサ（ＢＰ）１５０２及びアプリケーション・プロセッサ（ＡＰ）１５０４を備える。本発明のＩＰＣプロトコルにより、通信デバイス等、システム内の多プロセッサ間における通信が提供される。ＩＰＣにより、移動体アプリケーション（ＭＡ）クライアント（例えば、ｉＤＥＮ（商標）ＷＬＡＮ）がパーソナル通信システム（ＰＣＳ）アプリケーション等のＭＡサーバに登録することが可能となる。これにより、各々自身のＭＡ内部に依存するソフトウェア・アーキテクチャ、オペレーティングシステム、ハードウェア等に対して何ら制約を課すことなく、２つのＭＡが自在に通信するための手段が提供される。

ここで図１６を参照する。図１６には、ソフトウェア・スレッド等の３つのコンポーネント１６０２，１６０４，１６０６と、それらのコンポーネントがアウトバウンド・ストリーミングを確立する手法を示す。例えば、ソフトウェア・スレッド１６０２は所定のＱｏＳ１６０８に対する要求１６１２を送信し、オプコード・サブスクリプション・リスト１６１０を提出する。応答して、応答メッセージ１６１８にて、ソフトウェア・スレッド１６０２にチャネルＩＤ１６１４及びコンポーネントＩＤ１６１６が割り当てられる。本発明の一実施形態においては、ソフトウェア・スレッド等のコンポーネント１６０２，１６０４，１６０６には、そのコンポーネントの要件に応じてＩＰＣハードウェア・リソースが割り当てられる。コンポーネント１６０２，１６０４，１６０６は、システム要件に応じて動的にインストール又はアンインストールされることが可能である。

図１７において、コンポーネント１６０２，１６０４，１６０６は、ソフトウェア・スレッド１６０２のチャネル１７０２等、割り当てられたチャネル上でＩＰＣデータを送信する。コンポーネント１６０２，１６０４，１６０６は対象のＩＰＣノードと共にデータを提出するが、ノードが指定されていない場合、コンポーネントが全てのＩＰＣノードに対しメッセージをブロードキャストすることも可能である。コンポーネント１６０２，１６０４，１６０６は、宛先コンポーネントＩＤや、そのコンポーネントに関連するチャネル、ＩＰＣアドレスを認識する必要はない。インバウンド・ストリーミングに関しては、コンポーネントはメッセージ・オプコードにより識別される。例えば、図１８では、コンポーネント１６０２，１６０４，１６０６は、メッセージ・オプコードにより識別される。コンポーネントＩＤは、上述のコンポーネント経路制御テーブルを介して発見される。ＩＰＣセッション・マネージャは、メッセージのＩＰＣオプコードにサブスクライブした全てのコンポーネントに着信データを経路制御する。

［サービス品質］
図１９には、異なるデータ帯域幅及びチャネル優先度を有する３つのチャネル、チャネルＡ１９０２，チャネルＢ１９０４，チャネルＣ１９０６を示す。この例においては、チャネルＣ１９０６は、チャネルＢ１９０４より優先度が高く、チャネルＢ１９０４は、チャネルＡ１９０２より優先度が高い。各チャネル１９０２〜１９０６は対応するチャネル・バッファ１９１０〜１９１４を備える。チャネル・バッファ１９１０〜１９１４には、各チャネルからの着信データが取り込まれる。ＩＰＣスタックのデバイス・インタフェース層に存在するＩＰＣスケジューラ１９１６はチャネル・バッファ１９１０〜１９１４から着信データ・パケットを読み出し、チャネル１９０２〜１９０６の帯域幅及びチャネル優先度を考慮に含めて、ＩＰＣフレーム１９１８を形成する。ＩＰＣチャネル・バッファ１９１０〜１９１４からのデータを円滑に移動させるため、スケジューラ１９１６は、スケール決定（ｓｃａｌｅ）されたＩＰＣフレーム時間に等しいデータレートにスケール決定されるように、チャネル・バッファ１９１０〜１９１４から記憶されたデータを引き出す。ＩＰＣフレーム時間はＩＰＣネットワークの特定の設計要件に応じて変化し得る。

上述のように、ＩＰＣネットワークに参加することを所望するコンポーネントは、最初にＩＰＣスタックに登録し、続いて何らかのＱｏＳパラメータに基づきＩＰＣチャネルを要求する必要がある。ＱｏＳパラメータは、以下に限定されないが、チャネルの優先度、データレート、その他の周知のＱｏＳパラメータを含む。デバイス層のスケジューラ１９１６は、チャネルのデータレート及び優先度の保証を担う。チャネルが許可されるとき、デバイス層は、そのチャネルを優先されたタスクとする。したがって、優先度の高いチャネルはデバイス層において優先度の高いタスクであることが保証される。デバイス層は、優先度が異なるＯＳタスクとしてチャネル優先度を実装することが可能である。これにより、データを送信するソフトウェア・コンポーネント間の待機時間のチャネル優先度と、そのデータのＩＰＣスケジューリングとが考慮される。

スケジューラ１９１６は、ＩＰＣリンク上の各チャネルのデータレートを保証する役割を担う。このことは、各チャネルをラウンドロビン方式で（例えば、高い優先度から低い優先度へ）用いること、及び各チャネルに対し割り当てられたデータレートへの適合に充分なデータを、そのチャネルから選択する（ＩＰＣフレームを時間においてスケール決定する）ことにより行われる。データが全く存在しない、又は充分に存在しない場合、未使用データの差分は次のチャネルに与えられる。したがって、本発明の一実施形態においては、各ソフトウェア・コンポーネント毎のＱｏＳという概念と共に、タスク優先度及びデータレート・スケジューラの組み合わせにより、ＱｏＳ手法が提供される。

本発明の一実施形態では、あるＱｏＳを有するチャネルは、コンポーネントがそのＱｏＳを要求したポートにおいてのみ有効である。例えば、あるデータレートは、ソフトウェア・スレッド１９２２等のコンポーネントがＱｏＳレベルを要求した、同期シリアル・インタフェース（ＳＳＩ）１９２０等のポートにおいてのみ保証され得る。しかしながら、ＢＬＵＥＴＯＯＴＨ（登録商標）リンクの場合、ＱｏＳ割り当て後にポートが変更される場合があるので、ＢＬＵＥＴＯＯＴＨ（登録商標）リンクでは保証されない。

［選択的ブロードキャスト］
図２０には、２つのコンポーネント２００２，２００４が同じプロセッサに接続される場合のコンポーネント間（ｃｏｍｐｏｎｅｎｔ−ｔｏ−ｃｏｍｐｏｎｅｎｔ）メッセージ送信を示す。この例示では、コンポーネントＡ２００２が本発明のＩＰＣインタフェースを用いて、コンポーネントＸ２００４に対しメッセージを送信する。コンポーネントＸ２００４の存在する場所はＩＰＣセッション・マネージャ２００６により認識されるため、コンポーネントＡ２００２がコンポーネントＸ２００４の存在する場所を認識する必要はない。ＩＰＣセッション・マネージャ２００６は、コンポーネントＩＤ割り当て及びコンポーネント位置（プロセッサに接続されたコンポーネント）を保持している。この特定の例においては、コンポーネントＸ２００４がコンポーネントＡ２００２と同じプロセッサに存在することを、セッション・マネージャ２００６がデータベースから発見する。工程２０１０にて、ＩＰＣセッション・マネージャのコンポーネント参照テーブル２００８の情報を参照することにより、コンポーネントＡ２００２及びコンポーネントＸ２００４が同じプロセッサに存在することが判定される。そのためメッセージはＩＰＣカプセル化されず、通常のＯＳメッセージ呼出（例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）メッセージ・キュー）を介してコンポーネントＸ２００４へ渡される。工程２０１２にて、ＩＰＣ呼出がＯＳインタフェース規格に対しマッピングされる。この手法において、コンポーネント２００２，２００４等のコンポーネントは、メッセージ入力方式の修正について考慮する必要はない。コンポーネント２００２，２００４は、メッセージ・ポスト方法をＯＳ固有の方法からＩＰＣ呼出の方法へ変更する必要はなく、メッセージの適正な経路制御はＩＰＣスタックにより実行される。

ここで図２１を参照する。図２１には、２つのコンポーネントが異なるプロセッサに接続される場合のコンポーネント間メッセージ送信の例を示す。この例において、コンポーネントＡ２１０２はコンポーネントＸ２１０４と同じプロセッサ（図示せず）には存在せず、別のプロセッサに存在する。ＩＰＣセッション・マネージャ２１０６はコンポーネント参照テーブル２１０８にてコンポーネントＸ２１０４を参照し、工程２１１０にて、コンポーネントＸ２１０４がローカル・プロセッサに存在するか否かを判定する。この例においては、セッション・マネージャ２１０６はコンポーネントＸ２１０４がローカル・プロセッサに存在しないと判定し、工程２１１２にて適切なヘッダ情報及び他の情報によりメッセージをカプセル化する。続いて、メッセージはコンポーネントＸ２１０４への配信のため、ＩＰＣネットワークへ送信される。

ここで図２２を参照する。図２２には、ＷＩＮＤＯＷＳ（登録商標）ＣＥＡＰ等のＩＰＣサーバ２２０２を備えるＩＰＣネットワークを示す。ＩＰＣサーバ２２０２は、モデムＢＰ等、第１のクライアント２２０４と、ＧＳＭＢＰ等、第２のクライアント２２０６とに接続されている。サーバ２２０２内に存在するのは、第１のクライアント２２０４に関連するフィルタリング・テーブル（単にフィルタとも称する）２２０８と、第２のクライアント２２０６に関連する第２のフィルタリング・テーブル２２１０とである。サーバ２２０２に接続されているのは、ソフトウェア・スレッド（例えば、オーディオ）等のコンポーネント２２２４である。また、第１のクライアント２２０４は、コンポーネント２２１６，２２１８に対し送信されるメッセージのフィルタリングに用いられるフィルタリング・テーブル２２１２を有し、第２のクライアント２２０６は、コンポーネント２２２０，２２２２に対し送信されるメッセージのフィルタリングに用いられるフィルタリング・テーブル２２１４を有する。フィルタリング・テーブル２２３０を有するクライアント２２２８は、デイジーチェーンによりクライアント２２０４に接続されている。コンポーネント２２２６はクライアント２２２８に接続されている。

ここで図２３を参照する。図２３には、コンポーネント２２１６からオプコード２３０４を含むメッセージを受信するフィルタリング・テーブル２３０８を示す。フィルタリング・テーブル２３０８は、オプコード２３０４に基づきメッセージが転送されることが必要なコンポーネント／ノードを判定するために用いられる。例えば、オプコード「００１０」を有するオーディオ・アプリケーションにおいては、そのオプコードに関連する全てのコンポーネントに対し、メッセージが転送される。本発明の選択的ブロードキャスト手法により、フィルタリング・テーブルを動的に更新することが可能となり、ＩＰＣネットワーク内のどこへメッセージを送信するかをクライアントが決定することが可能となる。

本発明の一実施形態では、図２３に示す組み合わされたコンポーネント／ノード・フィルタリング・テーブル２３０８を用いる代わりに、別個のテーブルが各クライアント及びサーバに保持される。この実施形態では、別個のコンポーネント・フィルタ・テーブル及びノード・フィルタ・テーブルが用いられ、ＩＰＣノード（クライアント及びサーバ）毎にコンポーネント・フィルタリング・テーブル及びノード・フィルタリング・テーブルが存在する。クライアント２２０４等、別のクライアントに対し、クライアント２２２８等のクライアントが直接的にメッセージを転送することが可能であるので、これは真である（クライアント２２２８，２２０４はデイジーチェーンにより接続されている）。この例のノード・テーブルは特定のノードによりサポートされるデータ型のノードとリンクするため、コンポーネント・テーブルは特定のオプコードにリンクされているそのクライアント又はサーバのコンポーネントのリストを保持する。

図２４には、ＩＰＣサーバ２４１４に接続された複数のＩＰＣクライアント２４０２〜２４１２の図を示す。本発明の一実施形態による選択的ブロードキャストの一例では、ＩＰＣクライアント２４１２（ＩＰＣクライアント６）はＩＰＣクライアント２４１２に対し割り当てられたフィルタリング・テーブルを用い、ＩＰＣネットワークを介してメッセージをブロードキャストする。各クライアント２４０２〜２４１２は関連するフィルタリング・テーブルを有し、ＩＰＣサーバはクライアントを選択するために用いられるフィルタリング・テーブルを有する。示す例において、ＩＰＣクライアント２４１２からメッセージを受信すると、ＩＰＣサーバ２４１４に存在するクライアント６フィルタリング・テーブル２４１６により、ＩＰＣクライアント２４０２（ＩＰＣクライアント１）、ＩＰＣクライアント２４０６（ＩＰＣクライアント３）、及びＩＰＣクライアント２４１０（ＩＰＣクライアント５）に対するメッセージの選択的ブロードキャストが補助される。この例では、フィルタリング・テーブル２４１６により、ＩＰＣクライアント２４０４（ＩＰＣクライアント２）及びＩＰＣクライアント２４０８（ＩＰＣクライアント４）は、メッセージを受信しない。

各ＩＰＣクライアントは自身に対し割り当てられ、かつＩＰＣサーバ２４１２内に存在するフィルタリング・テーブルを有する。ＩＰＣクライアント２４０２〜２４１２の各々のフィルタリング・テーブルは、ＩＰＣリンクを介してＩＰＣノードにより動的に更新され得る。この選択的ブロードキャスト機能を用い、メッセージが送信される必要のないＩＰＣクライアントをフィルタリングして除くことにより、ＩＰＣクライアントは選択された対象にメッセージを送信することが可能となる。フィルタ・テーブル２４１６により、通信用のＩＰＣデータ・リンクに任意のＩＰＣクライアントを動的に含めることが可能となる。したがって、この手法により、編集時間に依存することなく、ＩＰＣネットワークが動的に形成され得る。選択的ブロードキャスト機能により、ソフトウェア・コンポーネントが異なるＩＰＣクライアント上の他のソフトウェア・コンポーネントと互いに通信するための動的な方法が提供される。選択的ブロードキャスト機能により、専用のＩＰＣチャネル及び専用の帯域幅からなる固定された組にＩＰＣクライアントを事前に構成することは不要となる。また、ＩＰＣスタック及びＩＰＣスタック下に存在するハードウェアは、コンポーネントが必要に応じて異なるリンクを選択して通信することが可能であるように抽象化される。

ＩＰＣプロトコルにより、ＭＡを確認するＩＰＣを通信用のＩＰＣリンクに動的に追加することが可能となる。したがって、編集時間に依存することなく、又は任意の他のソフトウェア条件によることなく、ＩＰＣネットワークが形成される。本発明のＩＰＣにより、ソフトウェア・コンポーネントがＩＰＣスタックと通信する標準的な手法が提供される。また、ＩＰＣスタック下のハードウェアは、異なるリンクを選択してコンポーネントが通信することが可能であるように抽象化される。ＱｏＳ及び選択的ブロードキャスト機能により、クライアント及びコンポーネントの柔軟性が改良され、ＩＰＣ性能が改良される。

本発明の一実施形態によるＩＰＣネットワークの図。本発明の一実施形態によるＩＰＣスタックの図。本発明の一実施形態によるＩＰＣコンポーネントＩＰＣ割り当ての図。本発明の一実施形態による主なＩＰＣテーブルの図。本発明の一実施形態によるチャネル割り当ての図。本発明の一実施形態によるＩＰＣクライアント初期化ルーチンに含まれる工程を示す図。本発明の一実施形態によるＩＰＣクライアント初期化ルーチンに含まれる工程を示す別の図。本発明の一実施形態による第１レベルのＩＰＣカプセル化を示す図。本発明の一実施形態によるＩＰＣコンポーネント初期化にて実行される工程を示す図。本発明の一実施形態によるコンポーネント初期化にて実行される工程を示す図。本発明の一実施形態によるＩＰＣクライアントとＩＰＣサーバとの間におけるＩＰＣデータの移動を示す図。本発明の一実施形態によるＩＰＣデータヘッダの図。本発明の一実施形態によるＩＰＣデータ要求にて実行される工程の図。本発明の一実施形態によるＩＰＣネットワークの図。本発明の一実施形態による無線通信デバイス等の電子デバイスの図。本発明の一実施形態によるアウトバウンド・ストリーミングの図。本発明の一実施形態によるアウトバウンド・ストリーミングの図。本発明の一実施形態によるインバウンド・ストリーミングの図。本発明の一実施形態によるＱｏＳ手続を示す図。本発明の一実施形態によるコンポーネント間メッセージ送信を示す図。本発明の一実施形態による異なるプロセッサに存在するコンポーネントにおけるコンポーネント間メッセージ送信を示す図。本発明の一実施形態によるフィルタリング・テーブルを示すＩＰＣネットワークの図。本発明の一実施形態によるフィルタリング・テーブルの図。本発明の一実施形態によるメッセージの選択的ブロードキャストを提供するＩＰＣネットワークの図。

Claims

プロセッサ間通信（ＩＰＣ）クライアントと、
ＩＰＣクライアントに接続されたコンポーネントと、
ＩＰＣクライアントに接続されたＩＰＣサーバと、
ＩＰＣサーバはコンポーネントにより送信されるメッセージが送信されることが必要な場所を決定するための１つ以上のフィルタリング・テーブルを有することとからなるＩＰＣネットワーク。
コンポーネントからのメッセージは、オプコードと、コンポーネントにより送信されるメッセージが送信されることが必要な場所をオプコードを用いて決定する１つ以上のフィルタリング・テーブルとを含む請求項１に記載のＩＰＣネットワーク。
ＩＰＣクライアント及びＩＰＣサーバは１つ以上のフィルタリング・テーブルのコンテンツを交渉する請求項１に記載のＩＰＣネットワーク。
ＩＰＣクライアントはフィルタリング・テーブルを有する請求項１に記載のＩＰＣネットワーク。
ＩＰＣクライアントに存在するフィルタリング・テーブルはコンポーネントによりメッセージが受信されることが必要か否かを判定する請求項４に記載のＩＰＣネットワーク。
ＩＰＣクライアントに接続された第２のコンポーネントを含み、
ＩＰＣクライアントに存在するフィルタリング・テーブルは、ＩＰＣクライアントにより送信されたメッセージをＩＰＣクライアントに接続された第１のコンポーネント及び第２のコンポーネントのうちの任意のコンポーネントが受信することが必要か否かを判定する請求項５に記載のＩＰＣネットワーク。
プロセッサ間通信（ＩＰＣ）クライアントと、ＩＰＣクライアントに接続されたＩＰＣサーバ及びコンポーネントとからなるＩＰＣネットワークにおける選択的ブロードキャスト方法であって、
オプコードを含むメッセージをコンポーネントが送信する工程と、
ＩＰＣサーバにてメッセージを受信する工程と、
ＩＰＣクライアントに関連するフィルタ・テーブルを用いて、メッセージが送信されることが必要な場所をサーバが決定する工程とからなる方法。
ＩＰＣクライアントはフィルタ・テーブルのコンテンツに関してＩＰＣサーバと交渉する請求項７に記載の方法。
フィルタ・テーブルは、ＩＰＣネットワークに接続されており、かつ、コンポーネントにより送信されるオプコードを含むメッセージを受信する全ての他のコンポーネントを、オプコードとリンクさせる請求項７に記載の方法。
オプコードは特定の型のサービスに関連する請求項７に記載の方法。
プレゼンテーション・マネージャと、プロセッサ間通信（ＩＰＣ）セッション・マネージャと、デバイス・インタフェース層とを有するＩＰＣスタックと、
ＩＰＣスタックに接続されており、かつ、サービス品質（ＱｏＳ）に基づきチャネルが割り当てられているコンポーネントと、
デバイス・インタフェース層に接続されており、かつ、チャネルに対するＱｏＳの割り当てを担うＩＰＣスケジューラとからなるＩＰＣネットワーク。
ＩＰＣスケジューラはチャネルに要求されるデータレートを保証する請求項１１に記載のＩＰＣネットワーク。
チャネルに接続されており、かつ、チャネルを介して送信されるデータを記憶するチャネル・バッファを含む請求項１２に記載のＩＰＣネットワーク。
ＩＰＣスケジューラはチャネルに要求されるデータレートのサポートに充分なデータをチャネル・バッファから選択する請求項１３に記載のＩＰＣネットワーク。
ＩＰＣスケジューラはＩＰＣスケジューラにより用いられるＩＰＣフレームのサイズに応じてチャネル・バッファから選定するデータをスケール決定する請求項１４に記載のＩＰＣネットワーク。