ポート群を動的に専用化するプロセッサ間通信ネットワーク
ＩＰＣプロトコル／ネットワークによりポート群の動的な専用化が可能になり、これにより、システムの待ち時間が短縮され消費電力が低減する。このＩＰＣシステムにより、ＩＰＣサーバ又はＩＰＣクライアントのいずれかが、ポート（単数又は複数）をリアルタイムデータなどのデータの転送専用に使うよう要求できる。ポートに対するこの要求は、例えばあるクライアントが制御メッセージを、特定のポートを自分専用にするよう要求しているサーバ／別のクライアントに送信することにより生ずる。サーバ及びクライアント（単数又は複数）はポート専用化を交渉し、専用化され次第、クライアントは専用のポートを使用して自身のデータをサーバ又は別のクライアントに転送する。ある実施形態では、そのポートをもっと重大な又はもっと優先権の高い別のデータ転送をサーバが行う為に必要だとサーバが判断した場合、サーバは専用のポートを取り上げる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に電子機器の分野に関し、より具体的にはポート群の動的な専用化を提供するプロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
大部分の電子システムには、そのシステムを形成しているハードウェアやソフトウェアなどの多数のネットワーク要素（コンポーネント群）がある。大部分のシステムには、異なるネットワーク要素とシステム自身との間の通信に加えて、ネットワーク要素を形成する異なるコンポーネント間の通信を担当している層がある。この層は典型的にプロセッサ間通信（ＩＰＣ）層と呼ばれている。
【０００３】
この数年の間に、プロセッサ間通信（ＩＰＣ）に対処する為に幾つかのプロトコルが導入された。ＩＰＣ製品のある例は、ホスト‐ＰＣＩブリッジとＤＲＡＭの制御装置及びデータパスと、加速式グラフィックスポート（ＡＧＰ）のインタフェースとを一体化するＰＣＩのＡＧＰ制御装置（ＰＡＣ）である。ＩＰＣ製品の別の例はＯＭＡＰ（登録商標）プラットフォームである。このどちらのプラットフォームも、より低いレベルのコンポーネントレベル又はチャネルレベル（物理層）では、サポートがあるとしてもハードウェアのレベルを上回るサポートを提供せず、設計の柔軟性もほとんどもたらさない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述のプラットフォームはコンポーネントレベルまでは及ばず、加えて、ハードウェアのサポート能力や、マルチノードのルーティング等を考慮しておらず、しかもＩＰＣリソースの動的な割り当てを考慮していない。低消費電力と短いシステムの待ち時間が必要性なので、当該分野では、ＩＰＣシステムでリアルタイムデータなどのデータを転送する際の無駄な時間を減らすために、ポート群の動的な専用化を提供できるＩＰＣネットワークが必要とされている。
【課題を解決するための手段】
【０００５】
本発明のＩＰＣは、あるシステムで相互通信する異なるプロセッサに必要なサポートを提供する。例えば、アプリケーションプロセッサ（ＡＰ）やベースバンドプロセッサ（ＢＰ）を含む無線通信装置用のデュアルプロセッサ（又はマルチプロセッサ）の無線アーキテクチャで、このＩＰＣは、効率的に通信しあう為にプロセッサ群が必要とするサポートを提供する。このＩＰＣは、ＡＰ又はＢＰの設計に何の抑制も課すことなくこのサポートを提供する。
【０００６】
概して、デュアルコアアーキテクチャは、ＡＰとＢＰとの間で仕事を分けることを表す。ＢＰはリアルタイムの且つ無線によるデータを処理し、ＡＰはそのデータをパッケージし、それをユーザに呈示する。この２つはサービスの為に互いに依存しており、その動作をＩＰＣメッセージ群の交換によって行う。この２つのサービスは変動するので、データの長さも速度も二地点間の交換も変動する。ＩＰＣの目的は、このサービス群が何であるかを定義することでもなければＡＰ及びＢＰの設計に制約を課すことでもない。代わりに、このＩＰＣは、このＩＰＣをプロセッサ間通信のスタックとして採用したＡＰ又はＢＰはどれでも、共存させなくてはならず、このＩＰＣは、共通のＯＳとメモリとを共有している同一のコアでＡＰとＢＰとが実際に動いているかのように動作する。多数のプロセッサを通信装置で使用することが標準になってくると、本発明のＩＰＣは異なるプロセッサ間の信頼性の高い通信を提供する。
【０００７】
このＩＰＣハードウェアは、異なるプロセッサをＩＰＣネットワークに結び付けて物理的に接続する。本発明のある実施形態では、データパケット群が異なるホスト間で同期せずに移送されることが好ましい。このＩＰＣネットワークに接続されたプロセッサ群は、統計的に又は動的に割り当てられた自身の物理アドレスと論理アドレス（例えば、ＩＰＣアドレス）とを持つ。更に、本発明のある実施形態では、データパケット群はこのＩＰＣネットワーク内ではどの方向にも流れる可能性があるので、データパケット群は、自身が到着しようとしているプロセッサの宛先アドレスを持っていなくてはならない。このソースＩＰＣアドレスは直接返答する為に用いられる。パケット群のルーティングが全ノード間でサポートされる。更にパケット群が、従来の巡回冗長検査（ＣＲＣ）技術を用いてエラーを検査することが好ましい。
【発明を実施するための最良の形態】
【０００８】
新規性がある本発明の特質を、添付の請求項で詳細に述べる。本発明を最も良く理解してもらうために、添付の図面を参照して以下の説明を行う。このうち幾つかの図では同じ参照数字が同じ要素を示す。
【０００９】
本明細書は、新規性がある本発明の特質を定義する請求項で締めくくられているが、本発明は、図面を併用して以下の説明を検討することによって、より良く理解されると考えられる。
【００１０】
ここで図１を参照すると、本発明のある実施形態に係るＩＰＣネットワーク１００が示されている。このＩＰＣネットワーク１００には、複数のＩＰＣクライアント１０２〜１０６及びサブクライアント群（他のクライアント群に結合されたクライアント群）１１６〜１１８と、異なるＩＰＣ物理リンク群を用いてこのＩＰＣクライアント群１０２〜１０６に結合されたＩＰＣサーバ１０８とがあり、ＩＰＣ物理リンク群とは、例えば、説明用の実例の、共有されているメモリ１１０や、汎用非同期送受信装置（ＵＡＲＴ）１１２や、ユニバーサルシリアルバス（ＵＳＢ）１１４などである。注目すべきは、本発明のＩＰＣによって、あるＩＰＣクライアント１０２〜１０６が、現在のＩＰＣサーバ１０８と、役割の切り換えについて交渉できることである。あるＩＰＣクライアント１０２〜１０６がＩＰＣサーバになることを交渉し、新しいＩＰＣサーバになることを現サーバが承諾した場合、残りのＩＰＣクライアントの全てが、ネットワークに変更があったことを知らされる。
【００１１】
図２には、本発明の実施形態に係るＩＰＣサーバ１０８（又はＩＰＣクライアント１０２〜１０６）のＩＰＣスタック２００が示されている。このＩＰＣスタック２００の設計は、オペレーティングシステム（ＯＳ）の下で一体化されるよう、コンポーネントのトラフィックのプロセッサ間通信のニーズをサポートするようになされている。このコンポーネント２２４と２２６とが自身のＩＰＣネットワークのサービスをＡＰＩサービス呼群によって請求する。コンポーネント同士間の物理的な通信の複雑な部分がＩＰＣスタック２００により処理され、従って同様にあらゆるハードウェア依存が抽出されつくす。このＩＰＣスタック２００は、ＯＳに特有のＡＰＩ層２２０によって特定のＯＳに結合された状態で示されている。
【００１２】
このＩＰＣスタック２００は下記の５つの主要な層によって構成されている。
（１）ＩＰＣプレゼンテーションマネージャ（２０２） この層は、異なるシステムコンポーネント（例えば、ソフトウェアスレッド）の間で異なるデータタイプを変換する為に使用される。異なるタイプのプロセッサコア同士間のそのデータ変換に伴う問題を克服するのに十分なハードウェアが提供されている場合には、この層を迂回してもよい。
【００１３】
（２）ＩＰＣセッションマネージャ（２０４） この層は、ＩＰＣスタックとシステムコンポーネントの全てとの間の着信／発信のＩＰＣトラフィック全てのセントラルリポジトリである。このＩＰＣセッションマネージャ２０４には主要な機能が幾つかあり、その中には、参加するＩＰＣコンポーネントへのコンポーネントＩＤの割り当て、ＩＰＣアドレスの割り当て、認証／登録と、コンポーネントの認証、コンポーネント群へのルーティング、他のＩＰＣノード群へのルーティングなどがある。この層は、ＩＰＣサーバとクライアントとを区別する唯一の層である。このセッション層はＩＰＣノード群を検出する。
【００１４】
こういったクライアントのセッション層のサービスは、サーバのセッション層のサブセットである。クライアントにより提供されるこういったサービスに加え、サーバが下記の機能を処理する。
【００１５】
１．ＩＰＣノード群の認証及び登録
２．ＩＰＣノードの特権を無効にする権限
３．ＤＲＴの同期
４．ＩＰＣアドレスブロックの割り当て
５．ネットワークセキュリティ
コンパイル時には、あるＩＰＣノードがあるサーバの役割を割り当てられる。しかし、任意の（信頼できる）ＩＰＣノードが実行時間の交渉によってサーバの仕事を引き受ける方法が提供されたほうがよい。この方法は、通信を保持したままでネットワークからサーバのノードを正常に除去するよう柔軟性をもたらすはずである。
【００１６】
（３）ＩＰＣルータ層（２０６） このＩＰＣルータ層は、ネットワークルーティングやポート専用化テーブルなどの必要なルーティング情報の全てを保存する。このＩＰＣルータ層は、割り当てられたアドレス群と、そのサーバ又はあるクライアント内の専用化されたあらゆるポートとを常時監視している。この層は、ネットワーク全体に亘る任意のＱｏＳについてのエンドツーエンドの帯域幅の配分の確保も担当している。
【００１７】
ＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスがそのプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。このＩＰＣサーバによってのみＩＰＣアドレス群が動的に割り当てられる。このサーバを含むある特定のネットワークの中ではＩＰＣノードは最大２５５個である。このネットワークからあるノードが除去されたとき、そのノードのＩＰＣアドレスは無効になり新しいＩＰＣノードに割り当て可能になる。このルータ層はパケット群のブロードキャストとＱｏＳのピアツーピアとをサポートしなければならない。ルータは、そのノードの認証／登録が済むまでは、どんなパケットもルーティングしてはならない。
【００１８】
（４）ＩＰＣデバイスインタフェース層（２０８） このデバイス層は、あらゆるインバウンドトラフィックとアウトバウンドトラフィックの物理媒体を抽出する。このＩＰＣスタックの上位層群は、制御及びコンポーネントを移送するＩＰＣスタックのサービス群とこのリンク全体に亘るコンポーネントのトラフィックとに頼っている。このデバイス層に接続された物理的ＩＰＣリンクは２つ以上の場合がある。このデバイス層の主要な機能の中には、ハードウェアポート群の検出、ポート群の列挙、パケット群の多重化及び多重分離、コンポーネント群への論理チャネル群の割り当て、物理媒体の同期、割り当てられたチャネル毎の物理的な帯域幅の保証などがある。
【００１９】
このデバイス層はＡＰＩの一組のＨＡＬを介してハードウェアとインタフェース接続する。このデバイス層は、ＩＰＣの物理チャネルから論理チャネルへのマッピングの割り当てを管理する。この層は、あらゆるＩＰＣハードウェアポートに亘るデータフローをサポートするようこのＩＰＣリンク下部の物理的な帯域幅の管理を任されている。この層は、多数のポート接続をサポートすると同時にＩＰＣノード群のデイジーチェーン接続もサポートする。このデバイス層は更に、専用の及び非専用のＩＰＣチャネル群のＱｏＳも管理する。この層は、ＩＰＣデータを送受信する為の多重化操作及び多重分離操作を提供する。メッセージ群が構築されたら、この層はそのメッセージ群をその後の処理に向けセッションマネージャ２０４に回送する。
【００２０】
このデバイスインタフェース層は、ＩＰＣの物理ＩＰＣチャネルから論理ＩＰＣチャネルへの管理を担当している。その主要な機能は、このスタックＩＰＣが独立したハードウェアになるよう、ＩＰＣハードウェアを完全に抽出することである。このデバイスインタフェース層は更に、ＩＰＣ論理チャネル群の全てをサポートするようこのＩＰＣリンク下部の物理的な帯域幅を管理する。着信パスでは、このデバイスインタフェース層が異なる物理チャネル群からデータを手に入れこのデータを残りのＩＰＣスタックまで通過させる。発信パスでは、このデバイスインタフェース層が、そのデータを適切な物理チャネル群に送ることによりそのデータをＩＰＣ論理チャネル群がロードするのを管理する。このデバイスインタフェース層は更に、そのデータをＩＰＣハードウェアに送る前に、同一のＩＰＣチャネルに属するＩＰＣパケット群の連結も処理する。チャネルの要求がＩＰＣセッションマネージャとＩＰＣデバイスインタフェース層との間で前もって交渉される。このデバイスインタフェース層は、ハードウェアポート群を提供し、このハードウェアポート群が次にデバイスインタフェースをあるＩＰＣクライアントに提供する。
【００２１】
このＩＰＣスタックは、確保した制御チャネルを全ての参加するＩＰＣノード間で通信する為に使用する。電源投入時に、このＩＰＣセッションマネージャのサーバが、このリンクを使用してメッセージ群をＩＰＣクライアント群にブロードキャストし、また逆の場合も同様である。通常操作の間、このチャネルを使用してあらゆるＡＰ及びＢＰの間で制御情報が運ばれる。制御チャネルは、その真下のＩＰＣリンクから独立して、デバイス層によって帯域幅を保証されている必要がある。
【００２２】
（５）ＩＰＣハードウェアＡＰＩ層（２１０） この層は、物理層のハードウェアポート群と残りのＩＰＣスタックとの間に必要なインタフェースを提供する。このハードウェアＡＰＩ層は更にこのハードウェアポート群とこのＩＰＣスタックとＯＳとの間に任意のプロトコル変換をもたらす。
【００２３】
このＩＰＣネットワークは、一組の物理リンクを介して一緒に通信するＩＰＣノード群から成っている。このＩＰＣネットワークについては、ノードを、このネットワーク上でＩＰＣ制御メッセージ群とデータメッセージ群とを他のノード群へ又は他のノード群から送受信する能力がある完全にＩＰＣスタックに準拠したエンティティと定義する。各ＩＰＣノードが多数のＩＰＣリンクをデイジーチェーン接続操作の為にサポートする。このＩＰＣサーバは単に、このＩＰＣクライアント群の登録／認証及びＩＰＣアドレス割り当てを担当しているノードである。どのネットワークにもＩＰＣサーバは一つだけしかないが、ＩＰＣクライアントのノードは幾つかある。各ＩＰＣノードは、このネットワークへの「ホット接続」の間か電源投入中は、動的に自身に割り当てられた一つの固有なＩＰＣアドレスを持っている。
【００２４】
ＩＰＣデータパケット群及び制御パケット群は、固有なＩＰＣオペコード群（例えば、オーディオ復号のオペコードや、充電の為のＡＴコマンドのオペコード等）を持っている。このＩＰＣオペコード群は、そのＩＰＣパケットで受信するＩＰＣデータのタイプを指定する。ＩＰＣノードタイプはそのＩＰＣノードを識別する固有なものである。コンポーネント２２４や２２６などのＩＰＣコンポーネントには、そのＩＰＣノードタイプ群が何を意味するのかと各ＩＰＣオペコードが何のために用いられるのかについてのプリコンパイル済みの知識がある。
【００２５】
ＩＰＣノードタイプの例には、ｉＤＥＮ（登録商標）のＢＰ、ＧＰＲＳのＢＰ等がある。同様に、別個の文書もそのＩＰＣオペコード群と自身のデータ構造群とを定義する。コンポーネントソフトウェアは、この２つの固有なデータ定義を知ってさえいればよい。通信の複雑な部分はこのＩＰＣスタックに委ねられている。このスタックの一部がルータ群でありＩＰＣノード同士間のメッセージフロー操作を処理する。フロー制御はこのＩＰＣスタック自身の機能であり、セッション層で透かし群を用いて実施される。
ＩＰＣアドレス割り当て
ＩＰＣアドレス群がＩＰＣサーバ１０８とピアノード群とによってのみ割り当てられる。このノードは常に、自身に割り当てられたアドレスの範囲から最上位のＩＰＣアドレスを選び取る。よってこのノードはこのＩＰＣアドレスによって分かる。ノードがもう使用不可能なとき、そのＩＰＣの特権は無効になり、従ってそのＩＰＣアドレスももう有効ではない。このＩＰＣソフトウェアがこのＩＰＣノードの情報を無効化しネットワークから除去する。除去されたＩＰＣノードにメッセージ群が送られた場合、親ルータが不正な宛先アドレスと共にエラーメッセージを戻す。一つのノードが２つ以上のＩＰＣアドレスを持つことはできない。ＩＰＣアドレス群は任意のＩＰＣネットワーク内で固有である。サーバのＩＰＣアドレスは常に２５４に設定されている。サービス群のブロードキャストの為にアドレス２５５が確保される。
【００２６】
ＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスがそのプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。このＩＰＣサーバによってのみＩＰＣアドレス群が動的に割り当てられる。このネットワークからノードが除去されたとき、そのＩＰＣアドレスは無効になり新しいＩＰＣノードに割り当て可能になる。
ＩＰＣメッセージのルーティング
このＩＰＣネットワークで何らかの通信を行うことを希望するＩＰＣノードは全て、まずこのＩＰＣセッションサーバに登録しなければならない。認証が無事終了した後で、要求しているＩＰＣノードがそのＩＰＣネットワークでの通信の資格を得る。どのＩＰＣノードにもルータがある。その機能は、ＩＰＣメッセージ群を次の宛先ノードにルーティングするか、このルータがこのＩＰＣアドレスを任意のハードウェアポートの宛先のどれにも変えられない場合にはＩＰＣメッセージ群を解消させることである。このルータがＩＰＣメッセージ群を別のノードに回送している場合、このルータはこのメッセージをセッションマネージャまで通過させない。多数のノードに亘る通信チャネルを必要とするコンポーネント群は、それぞれ各自のルータを介してその全てのノードに亘る終端間のＱｏＳを要求する必要がある。その下のデバイス層からのチャネルのＱｏＳをルータが要求してもよい。
ＩＰＣヘッダ
図３に示されているのはＩＰＣヘッダ３００である。このヘッダを全てのＩＰＣパケットが持っている。ソースＩＰＣアドレス及び宛先ＩＰＣアドレスをセッションマネージャが埋める。ソースコンポーネント識別番号（ＣＩＤ）はデータ要求の間に送られるものであり、宛先ＣＩＤは任意選択である。目標のＣＩＤが書き込まれなかった場合、この宛先ノードはこのＩＰＣメッセージを全ての加入しているコンポーネントに回送する。宛先ＣＩＤがソースコンポーネントにより書き込まれた場合には、このＩＰＣメッセージはそのコンポーネントにのみルーティングされる。セッション層により最終のデータチェックサムが書き込まれ任意選択で作動させられたり作動させられなかったりする。ルータがＩＰＣヘッダにルータの制御語を書き込んだ場合、このチェックサムは更新される必要がある。このチェックサムの計算にはＩＰＣヘッダとメッセージのデータ部とが含まれる。デバイス層によりセッション層に向けてパケット群が受信側に送り届けられるとき、前者は、何らかのデータを上に向けて回送するより前に、チェックサムが検証されたことを確かめる。データチェックサムを任意選択で省いてもよいが、このＩＰＣヘッダのチェックサムは常に含まれていなくてはならない。このチェックサムの最上位ビットは、このＩＰＣパケットに属するデータがＯＮかＯＦＦかを示す。ＯＮを「１」の状態が示し、ＯＦＦを「０」の状態が示す。このＩＰＣヘッダは合計７バイトである。このＩＰＣデータフィールドは単に図示の為に示されており、そのサイズはＩＰＣパケットのデータ構造に依存している。
【００２７】
ＩＰＣ通信への参加を希望している新しいコンポーネントはみな、こういった動作を、まず、ＩＰＣ識別番号（ＩＤ）をそのＩＰＣセッションマネージャ（例えば、セッションマネージャ２０４など）に要求することによって行わなければならない。このローカルセッションマネージャ（例えば、そのコンポーネントが結合されているクライアントに設置されたセッションマネージャ）は次にＩＰＣサーバのセッションマネージャにこの新しいＩＰＣコンポーネント群について通告し、ＣＩＤの割り当てが提供される。本発明のある実施形態に従って、このＣＩＤ群は動的であり、セッションマネージャ（例えば、サーバのセッションマネージャ）により再び割り当て可能である。このＩＰＣサーバは主要なＡＰ上にある可能性が最も高い。各ＩＰＣノードは固有なＩＰＣノードＩＤを持っていることが好ましく、セッションマネージャはそのデータベースに下記の情報を参加しているＩＰＣノード毎に保持する。
【００２８】
ＩＰＣノードタイプ：例えば、特定のＢＰ又はＡＰ、無線ローカルエリアネットワーク（ＷＬＡＮ）のＡＰなど。
ＩＰＣアドレス：ＩＰＣノードのＩＰＣアドレス。
【００２９】
データタイプ：ＩＰＣノードのデータタイプ。
オペコードリスト：このリストは、コンポーネントが加入しているＩＰＣメッセージオペコード全てのリストである。
【００３０】
コンポーネントＩＤ：ＣＩＤ全てのリスト。
ここで図４を参照すると、ＩＰＣスタックが全ての主要なＩＰＣテーブルと共に示されている。動的なルーティングテーブル（ＤＲＴ）４０２には、ノードタイプ（プロセッサタイプ）、ＩＰＣアドレス情報、データタイプ、加入リストなどがある。この加入リストには、特定のノードのＩＰＣにサポートされたメッセージオペコードの全てが含まれている。コンポーネントルーティングテーブル４０４には、オペコードの情報と各特定のオペコードに加入しているコンポーネントの全てとに関連している情報が含まれている。最後に、チャネルリソーステーブル４０６には各チャネルＩＤを物理チャネルＩＤのリストと関連させることが含まれている。
【００３１】
このＩＰＣスタックの幾つかの重要な機能とサービスとをセッション層（セッションマネージャ）が提供する。クライアントのこのＩＰＣセッション層はサーバのＩＰＣセッション層のサブセットである。ＩＰＣプロトコルをＩＰＣノード群が全部サポートする。ＩＰＣサーバに登録され認証され次第、クライアントのＩＰＣセッション層はこのＩＰＣネットワークを介して通信可能になる。次にＤＲＴがこのノードのセッション層で作成されサーバに送られる。そしてサーバはＤＲＴのコピーをネットワークのそのＩＰＣノード群に回送する。このコピーは活動中のＩＰＣノードの各々にその他の参加しているノードについての十分な情報を提供する。
【００３２】
ＩＰＣノードタイプとＩＰＣオペコードには、各製造者が製造者自身の値を自由に選び割り当てることができる。ＩＰＣノードのタイプをＤＲＴ４０２の第１の入力が識別する。例えば、ｉＤＥＮのベースバンド（ＢＰ）が１６進値の０ｘ０１を持つと仮定する。このＩＰＣアドレスは、このノードがこのＩＰＣネットワークに特定のハードウェアポートでつながれている限り、このノードに固有である。このアドレスは、本文書のルータの節で述べられたように、このノードのピアノード（より高いレベルで結合されたノード）により割り当てられている。このデータタイプがコア及びデータのアライメントのルールのタイプを記載する。このノードに登録され構成されたコンポーネント加入オペコードリスト全てをＩＰＣオペコードリストが組み合わせる。このＤＲＴのコピーが活動中のＩＰＣノード全てにＩＰＣサーバにより回送される。特定のノードについてこのＩＰＣオペコードリストの変更があった場合、新しいコピーがサーバに送られる。するとサーバは新しい情報を活動中のＩＰＣノード全てに回送する。
アウトバウンドデータの為のＩＰＣノードアドレス検出
各ＩＰＣノードがこのＩＰＣネットワークの活動中のＤＲＴ全ての最新のコピーを保有する。各ＩＰＣノードのＤＲＴに変更があった場合、ＩＰＣサーバへの通告をセッション層が担当している。コンポーネントがそのパケットデータを送信の為にこのセッション層に回送するとき、コンポーネントは目標のノードの物理ＩＰＣアドレスについて何も知らない。代わりに、コンポーネントがそのＩＰＣノードタイプにより目標のＩＰＣノードを指定する。目標のＩＰＣノードタイプに対応する目標のＩＰＣアドレスを検出するのはセッション層にかかっている。目標のノードがこのＩＰＣネットワークで使用可能な場合、このＩＰＣアドレスはその対応するＤＲＴからフェッチされる。他の場合には、このコンポーネントにエラーが戻される。よってこのコンポーネントは適切なＡＰＩの機能を使用してネットワークの既存のＩＰＣノードについての情報を知ることができる。
インバウンドデータの為のＩＰＣコンポーネント検出
そのノードでＩＰＣパケットが受信されたとき、ＩＰＣパケットの目標のＩＰＣアドレスがルータにより検査される。そのＩＰＣアドレスがノードのものだった場合、そのパケットはその後の処理に向けセッション層に回送される。このセッションは、登録されているコンポーネント群のオペコード加入リストに基づいて、そのメッセージをそのコンポーネント群に分配することを担当している。ＩＰＣパケット群は、加入リスト群とフィルタテーブル群とに依存して２つ以上のコンポーネントにより消費可能である。前述のように、コンポーネント群は、その構成プロセスの間に自身でＩＰＣオペコード群又はサービス群に加入する。次に、セッション層がオペコード加入リスト（加入リスト）を構築して、インバウンドデータのＩＰＣコンポーネントルーティングを助ける。
ＩＰＣコンポーネントルーティング層
セッションマネージャにはＩＰＣコンポーネントルーティング層が備わっており、加入しているコンポーネント群と、データの完全な消費時にはバッファのないメモリとへのデータパケット群のブロードキャストと分配とを担当している。受信されたデータがどのコンポーネントによっても変えられない又は修正されないことが条件である。バッファデータへの上書きを希望するコンポーネント群は、まずローカルコピーを作り、ＩＰＣコンポーネントルーティング層に本来のバッファの解放の表示を送る。
【００３３】
このＩＰＣコンポーネントルーティング層の一部がフロー制御である。コンポーネント毎に透かしをプログラムできる。データパケット群が蓄積しており開放されてないとき、セッションマネージャは、ＩＰＣネットワークでフロー制御表示をブロードキャストする決定を下す。ＩＰＣノードが十分なパケット群を消費し透かしを下回るとき、データパケット群の受信を再開する為に別のフロー制御表示が送られる。コンポーネントのサービスがどれであるかを明らかにする又は単純に問題になっているＩＰＣノードとの通信を遮断することで、情報を特定のコンポーネントに送るのを控えるようＩＰＣノード群に通告する為にフロー制御を使用できる。
【００３４】
図５には、本発明のある実施形態に係るＩＰＣスタックがＩＰＣチャネルをソフトウェアスレッド（例えば、オーディオ等）などのコンポーネントに提供する方法のブロック図が示されている。まず工程５０４でコンポーネント５０２がＩＰＣチャネルを要求する。図５に示されているセッションマネージャが、定義されたＡＰＩを用いて工程５０６でコンポーネントの要求をデバイス層と交渉する。それからデバイス層（デバイスインタフェース）が、データチャネル５０８などのハードウェアリソースを要求する。図５に示されているセッションマネージャが、工程５１０で、要求に応えて、その要求者にあるＩＰＣチャネルを付与する。次にコンポーネント５０２が割り当てられたチャネル５０８で自身のデータを送る。それからデバイス層がそのデータをＩＰＣネットワークに回送する。論理チャネルＩＤから物理チャネルＩＤへのマッピングはＩＰＣデバイスインタフェースの役目である。
【００３５】
ここで図６を参照すると、ＩＰＣクライアント初期化の第１の工程は、ローカルノードのルータによりＩＰＣアドレス割り当て要求を送る工程である。ここでは全クライアントが、そのクライアントのピアノードからそのクライアントが肯定応答を受信するまで待機する。アドレス割り当てが受信されたとき、このクライアント群はまず、ＩＰＣクライアント６０２とＩＰＣサーバ６０４との間で登録要求を送る（工程６０６）。すると工程６０８でＩＰＣサーバ６０４はＩＰＣクライアント６０２に対しその要求を認証する。これにより工程６１０で登録が完了する。工程６１２でこのＩＰＣクライアントのセッションマンガーがその動的なルーティングテーブルのコピーをＩＰＣサーバに送る。
【００３６】
このＩＰＣクライアント初期化のプロセスの間になされる工程がより詳しく図７に示されている。工程７０２で、クライアントセッションマネージャ（表ではセッション（クライアント）として示す）がＩＰＣサーバのセッションマネージャ（表ではセッション（サーバ）として示す）に構成要求を送る。工程７０４では、このＩＰＣサーバのセッションマネージャにより認証が要求される。よって工程７０６でＩＰＣクライアントとＩＰＣサーバとの間の認証が実行された。
【００３７】
構成要求のパラメータには、ノードタイプ、データタイプ、そのノードの動的なルーティングテーブルなどがある。セッションサーバは工程７０２の構成要求に応えて要求側にＩＰＣアドレスを割り当てる。このセッションサーバは更に、動的なルーティングテーブルがない場合、要求側の為に動的なルーティングテーブルをセットアップする。その後、工程７０８に見られるように、セッションサーバは要求側に構成表示を送る。
【００３８】
この構成表示の受信に応えて、セッションクライアントに付随するコンポーネント群がクライアントのセッションマネージャに制御／データを要求する。すると工程７１０でセッションクライアントは構成表示確認メッセージをセッションサーバに送る。この「構成表示確認」メッセージにはパラメータがなく、工程７１０で構成表示確認メッセージを受信すると、セッションサーバは新たに構成されたセッションクライアントに対しＩＰＣストリーム群を起動できる。それから工程７１２と工程７１４とでセッションサーバはセッションクライアント群に構成更新メッセージ群を送る。これにより、図７に示されているセッションクライアント両方がそれぞれの動的なルーティングテーブル（図示せず）を更新し、工程７１６と工程７１８とでセッションサーバに構成更新確認メッセージを送ることになる。この構成更新確認メッセージ群を受信したとき、セッションサーバはＩＰＣ参加者の全てが更新されたことを確かめる。
【００３９】
別のノードのＩＰＣセッションマネージャによりパケットが受信されたとき、これはデータの形になり、このデータの形には、ソースコンポーネントＩＤ、宛先ＩＤ、ＢＰ又はＡＰのタイプなどがある。このＩＰＣセッションマネージャは、宛先ＩＤが書き込まれなかった場合には宛先コンポーネントＩＤを追加する。このＩＰＣセッションマネージャが、この宛先ＩＤを、受信したメッセージオペコードに基づいて検出する。この宛先ＩＤはあるルックアップテーブルに基づいている。このルックアップテーブルは、コンポーネントが新しいＩＰＣメッセージオペコードに加入する（例えば、ＩＰＣセッションマネージャに要求を送ることによりあるオーディオコンポーネントがオーディオメッセージ群に加入する）たびに動的に更新される。
【００４０】
ＩＰＣノード群がその構成要求をＩＰＣサーバに送ると、そのＩＰＣノード群は認証される。これがなされるのは、電源投入の際か、ネットワークへのそのＩＰＣノードの「ホットプラグ」の際である。このＩＰＣノードはそのノードタイプによって自身を識別する。このネットワークには複製のＩＰＣノードタイプはないものとする。このネットワークに既に存在するタイプの別のＩＰＣノードがネットワークに加わる場合、サーバは拒絶の表示をそのノードに送らなければならない。
【００４１】
図８には、本発明のある実施形態に係る、あるコンポーネントとそのＩＰＣセッションマネージャとの間での、一般的な宛先ＩＤ検出シーケンス中のイベント群のシーケンスが示されている。工程８０２では、このコンポーネントがそのソースＩＤ（宛先ＩＤは送らない）と、宛先ＢＰ又はＡＰのタイプと、ヘッダとデータとを含むＩＰＣデータとを送る。工程８０４では、このＩＰＣセッションマネージャがＩＰＣデータのヘッダのオペコードと宛先ＢＰ又はＡＰのタイプとを調べ、これによって、対応する動的なルーティングテーブルを捜して正しい宛先アドレスを見つける。工程８０６では、このＩＰＣセッションマネージャがそのコンポーネントのＩＰＣアドレスを書き込みそれをデバイス層まで送る。メッセージのブロードキャストが必要な場合、このＩＰＣアドレスの宛先フィールドを０ｘＦＦに設定する。
【００４２】
図９には、ＩＰＣコンポーネントの初期化の間になされる典型的な工程が示されている。図９に示されているＩＰＣサーバによってＢＰが構成され次第、ＢＰはコンポーネント９０２などのコンポーネント群を異なるサービス群に加入させる。工程９０４でコンポーネント群が自身でオーディオやビデオなどの機能に加入できる。次にこのコンポーネント加入情報が、コンポーネントＩＤ作成の為に（ＩＤがまだ割り当てられていない場合）、そして特定のＩＰＣアドレスの動的なルーティングテーブルの作成又は更新の為に、ＩＰＣセッションマネージャに送られる（工程９０６）。工程９０８では、このセッションマネージャが工程９０６の情報によってＩＰＣサーバを更新する。工程９１２でこのＩＰＣサーバにより動的なルーティングテーブルの確認がＩＰＣクライアントに送られる。このサーバが通告され次第、工程９１０で新しい動的なルーティングテーブルの更新が参加するプロセッサ全てにブロードキャストされる。
【００４３】
同様のコンポーネントの初期化プロセスが、図１０では、コンポーネント（クライアント）１００２と、クライアントセッションマネージャとも言うセッション（クライアント）１００４と、サーバセッションマネージャとも言うセッション（サーバ）１００６との間で示されている。工程１００８でコンポーネント（クライアント）１００２によりコンポーネントの構成要求が送られる。更にクライアントセッションマネージャ１００４がコンポーネントＩＤを割り当て新しいオペコードのリストをその動的なルーティングテーブルに追加する（図示せず）。工程１０１０では、クライアントセッションマネージャ１００４が、コンポーネントＩＤを含む構成返答を送る。この構成返答に応えて、コンポーネント（クライアント）１００２がそのＩＤをクライアントのセッションマネージャ１００４から受信する。
【００４４】
工程１００８の構成要求にクライアントセッションマネージャ１００４が工程１０１０で返答し次第、工程１０１２でクライアントセッションマネージャ１００４はセッションサーバ１００６に構成更新要求を送る。構成更新要求のパラメータ群は、動的なルーティングテーブルでなされた任意の新しい変更である。そのＩＰＣアドレスの動的なルーティングテーブルをセッションマネージャが更新する。それから工程１０１６でこのサーバセッションマネージャ１００６が全ＩＰＣクライアントに構成更新を送り、同時に工程１０１４でＩＰＣクライアントに構成更新表示も送る。サーバのセッションマネージャ１００６は、ＩＰＣサーバがそのルーティングテーブルを送られた変更により更新したことを確かめる。
【００４５】
動的なルーティングテーブル群をパラメータ（単数又は複数）として含む工程１０１６の構成更新メッセージでは、セッションサーバ１００６は動的なルーティングテーブル群を更新し、工程１０１８で構成更新確認メッセージを送る。その後このセッションサーバ１００６は、ＩＰＣ参加者の全てが更新されたことを確かめる。
【００４６】
このＩＰＣセッションマネージャが発信ＩＰＣパケット群及び着信のＩＰＣパケット群のルーティングパスを決定する。発信パケットのルートはコンポーネントのＩＰＣアドレスにより決定される。その宛先アドレスがローカルプロセッサのものであることが判明した場合、ＩＰＣからオペレーティングシステム（ＯＳ）へのマッピングがこのセッションマネージャの内部で実行される。その宛先アドレスがあるローカルＩＰＣクライアント用のものであることが判明した場合、このパケットはその後の処理（例えば、カプセル化）に向けＩＰＣスタックに送られる。ここで留意すべきは、そのＩＰＣパケットを送るコンポーネントと同一のプロセッサに宛先コンポーネントが設置されている場合、カプセル化は不要でありそのパケットは通常のＯＳのメッセージ呼び出し（例えば、マイクロソフトメッセージキュー等）により引き渡されることである。このようにコンポーネント群は自身のメッセージ入力方式の修正のことを考えなくてよい。コンポーネント群は自身のメッセージ記入方法論をＯＳに特有の設計の代わりにＩＰＣの呼び出しに変更するだけでよく、このＩＰＣの呼び出しはこの実施形態で指定したＯＳの層で抽出されつくす。
【００４７】
着信パケット群については、メッセージの宛先アドレスがＩＰＣサーバのものに等しくない場合、この着信パケット群はルータにより適正なＩＰＣクライアントへとルーティングされる。着信パケット群のルーティングはＩＰＣノードのルータマネージャにより処理される。他の場合には、このメッセージは、コンポーネントの宛先ＩＤが有効なコンポーネントＩＤ又は０ｘＦＦに設定されているかどうかに依存して正当な単数又は複数のコンポーネントに回送される。
【００４８】
このＩＰＣルータのブロックはＩＰＣデータを宛先コンポーネントに移送する。着信ＩＰＣメッセージ群が、中でも、オーディオやモデム等のものなどの発信者のコンポーネントＩＤとＩＰＣメッセージオペコード群とを持っている。ＩＰＣセッションマネージャはそのコンポーネントルーティングテーブルに頼ってＩＰＣデータを正当なコンポーネント（単数又は複数）に送る。この動的なルーティングテーブル及びコンポーネントルーティングテーブルの両方がＩＰＣサーバ／クライアントによって更新される。
【００４９】
電源投入の間、各コンポーネントが、ＩＰＣコンポーネントＩＤを得る為に自身をそのセッションマネージャに登録している必要がある。加えて、各コンポーネントは、オーディオやモデムなどの着信ＩＰＣメッセージ群に加入している必要もある。この情報は、ＩＰＣセッションマネージャにより使用できるよう、コンポーネントルーティングテーブル及び動的なルーティングテーブルに保存されている。
【００５０】
図１１に示されているように、コンポーネント１１０２が、工程１１０４に見られるようにそのデータ要求をＩＰＣセッションマネージャに送り、宛先ＩＰＣノード（例えばＢＰ）にある検査がなされる。このＩＰＣノードがＩＰＣメッセージオペコードをサポートしない場合、このコンポーネント１１０２にエラー応答が戻される。このエラー応答に加えて、ＩＰＣセッションマネージャは、その特定のオペコードを受信する能力があるＩＰＣノード全ての更新を返す。このメッセージをＩＰＣセッションマネージャがどのＩＰＣノード（単数又は複数）にリダイレクトするかの決定は、このコンポーネントにかかっている。この宛先コンポーネントがＩＰＣネットワークに設置されているがローカルプロセッサには設置されていないことをこのセッションマネージャが判断した場合、このデータがＩＰＣネットワークに送られる前に、このデータをＩＰＣセッションマネージャ１１０６はまずＩＰＣヘッダ情報によってカプセル化する。
【００５１】
ＩＰＣコンポーネント群は、ＩＰＣプロトコルのスタックを用いて一緒に通信するスレッド群又はタスク群である。同一のコアに備わっているコンポーネント群には、他のローカルコンポーネント群との通信用のＩＰＣのＡＰＩを迂回するという選択肢があるが、望ましくはない。ここで意図していることは、そのコンポーネントのソフトウェアを、そのコンポーネントの物理的な場所及び基礎をなしているＯＳから独立した状態に保持することである。ＩＰＣスタックとのコンポーネントのインタフェースは、サーバとクライアントとで違いはない。
ＩＰＣスタックを介したコンポーネントの通信
コンポーネント群は相互通信／内部通信メッセージングの標準的なＡＰＩ呼び出しを使用する。このＡＰＩ呼び出し群は、ひとつのＯＳのプラットフォームから次のものに変わらない。これにより、コンポーネントがどこで動いているかに関わらず、データメッセージ群の移送に対処するコンポーネントソフトウェアを同じ状態のままにしておける。加えて、コンポーネント群は、ＩＰＣセッションマネージャへのサービス呼を介して、要求しているサービス群の中に局所的に存在するもの又はＩＰＣリンクを必要とするものがあるかどうかを検出できる。宛先コンポーネントが局所的に備わっている場合には、ＩＰＣセッションマネージャが、送信用のデバイス層にデータを回送することなく、このメッセージを正当なコンポーネントに回送する。
ＩＰＣコンポーネントＩＤの割り当て
何らかのＩＰＣ通信への参加を希望しているコンポーネントは全て、こういった動作を、まず自身をＩＰＣスタックと一体となるよう構成することによって行わなければならない。ノードのセッションマネージャはコンポーネント群を認証しそのコンポーネント群にＣＩＤを割り当てる。各コンポーネントはＣＩＤを２つ以上持つことはできない。コンポーネント群がＩＰＣノードからアンインストールされた場合には、コンポーネント群のＣＩＤは除去されなくてはならずＩＰＣネットワークに通告する必要がある。適切な除去のコマンドをＩＰＣセッションマネージャに送るのは、アンインストーラ又は同等のソフトウェアの担当である。一般的な使用の場合には、コンポーネント群が、ＩＰＣメッセージを送るのに自身の目標のコンポーネントのＣＩＤを知らなくてもよい。このコンポーネント群からのルーティング抽出を管理するのは、ＩＰＣソフトウェアの担当である。場合によっては受信したＩＰＣメッセージに返答するようなコンポーネント群は、ソースＣＩＤを目標にすることで返事をリダイレクトする。この場合はその目標のノードがメッセージをその特殊なコンポーネントに回送し、加入しているコンポーネント全てには回送しない。コンポーネント群のＣＩＤはそのノード内で固有でありノード同士間では固有ではない。
論理的なＩＰＣチャネル配分
コンポーネント群はＩＰＣネットワークで通信するのに論理チャネル群を用いる。論理チャネル群は、各コンポーネントから要求されたＱｏＳに基づいてデバイス層により割り当てられる。コンポーネント群には多数の論理チャネルが割り当てられる。本発明のある実施形態に従って、チャネルには専用と非専用の２つのタイプがある。コンポーネント群がチャネルのタイプを選ぶ。専用のチャネル群は、そのコンポーネントがそのチャネルを使用するときいつもコンポーネントのＱｏＳが使用可能であることを保証する。異なるＱｏＳのチャネルが２つ以上コンポーネント群に与えられる可能性があるので、ＩＰＣの帯域幅がなくなる恐れがある。
【００５２】
コンポーネント群にこの通信リソース群を共有させ続ける為に、デバイス層が非専用のチャネル群を随意選択で提供する。非専用のチャネルのＱｏＳは、その帯域幅が使用可能な場合には保証され、他の場合には合計のロードに依存してＱｏＳは低下する。多数のノードに亘るＱｏＳを専用のチャネル又は非専用のチャネルに付与することができる。
専用チャネルと非専用のチャネル
専用のチャネル群はコンポーネントから要求されたＱｏＳを保証する。そのチャネルが解放されていない限り、そのチャネルのＱｏＳは履行される。非専用のチャネル群はＱｏＳを保証できないが、余分の帯域幅が使用可能になったときデータを送ろうと連続的に試みる。非専用のチャネル群には予想可能なリアルタイムの性能はないが、非同期の、低帯域幅のデータの為に使用できる。コンポーネント群は、２つ以上のチャネルを要求することにより、異なるＱｏＳを同時に確保できる。コンポーネント群は、自身のチャネル群を解放すると決めるまで、自身のチャネル群を保持する。しかし、優先権の高いほかのものによりスタックが供給されて、ある専用のチャネルについてのあるコンポーネントの特権が除去される。この場合は、あるチャネルを所有しているコンポーネント群が通告され、そのチャネルを解放するかそのコンポーネント群のチャネルを非専用のモードへと変えるよう求められる。
ＱｏＳの割り当て及びコンポーネントの優先権
コンポーネント群が論理チャネル群をあるＱｏＳに基づいて要求する。ＱｏＳの定義はデータ速度である。ＱｏＳがそのコンポーネントにより指定されデバイス層と交渉される。加えて、コンポーネント群が登録及び認証のプロセスの間に優先権を割り当てられる。この優先権はＩＰＣセッションマネージャに用いられ、コンポーネントの特権が、特権の程度の低いコンポーネント群のチャネル群とサービス群とを無効にし要求する際に検証される。
ＩＰＣコンポーネントの加入リスト
ＩＰＣスタックとのコンポーネントの登録の一部は構成要求である。あるコンポーネントが認証されたとき、そのコンポーネントはセッションマネージャからあるＣＩＤを受信する。ここで、このコンポーネントは、異なるＩＰＣオペコードに加入することにより自身をＩＰＣスタックと一体となるよう構成する場合がある。このコンポーネントは、対象となっているオペコード群を選びそのオペコード群をセッション層に登録する。コンポーネントが、別の構成要求をセッションマネージャに送ることにより、自身のオペコードのリストへの加入をやめることを決めたり変更したりしてもよい。
【００５３】
図１２には、ＩＰＣスタックとの典型的なコンポーネントの通信が示されている。示されているのは、あるコンポーネントとＩＰＣスタックとの間の典型的な登録要求と構成要求と論理チャネル要求である。
【００５４】
本発明のある実施形態に係る典型的なＩＰＣデータ要求が図１３に示されている。工程１３０２では、コンポーネントが更新要求を送る。コンポーネント更新パラメータには、好ましくはノードタイプとオペコードとが含まれる。このコンポーネントがその宛先オペコードをサポートするノードタイプ群を検索する。このノードタイプが０ｘＦＦに等しい場合、セッションマネージャはまず、このコンポーネントの情報をＩＰＣ参加者全員のノードテーブル全てに送る。このオペコードフィールドが０ｘＦＦに等しい場合、セッションマネージャはまず、このコンポーネントを指定のノードタイプに属するオペコードリストに送る。一方、オペコードが特殊な値を持っている場合、セッションマネージャはまず、このコンポーネントに、ノードタイプがその特定のオペコードをサポートするかサポートしないかに対応した真の値又は偽の値を送る。
【００５５】
工程１３０４では、このコンポーネントにコンポーネント更新表示が送られる。このノードタイプが０ｘＦＦに等しい場合、ノードテーブル群はコンポーネントに戻される。このオペコードフィールドが０ｘＦＦに等しい場合、オペコードのリストはコンポーネントに戻される。しかし、このオペコードが特殊な値の場合、真のメッセージ又は偽のメッセージが返される。工程１３０６では、コンポーネントデータ要求がなされる。このコンポーネントデータ要求のパラメータには、ノードタイプ、ＩＰＣメッセージオペコード、ＩＰＣメッセージデータ、チャネルＩＤ、コンポーネントＩＤなどがある。コンポーネントデータ要求では、セッションマネージャはノードタイプを検査してこのオペコードがサポートされているかどうかを判断する。ノードタイプがこのオペコードをサポートしていない場合、工程１３０８でコンポーネント更新表示が送られる。しかし、ノードタイプがこのオペコードをサポートしている場合、工程１３１０でデータ要求がデバイス層に送られる。このデータ要求パラメータには、ＩＰＣメッセージ、チャネルＩＤ、ＩＰＣヘッダなどがある。
【００５６】
デバイス層はこのデータ要求メッセージをチャネルＩＤに基づいて送ることになっている。デバイス層はＩＰＣハードウェアをポートのヘッダ情報に基づいて選択する。データがコミットされ次第、１３１２でデータ確認メッセージがセッションマネージャに送られる。工程１３１４では、セッションマネージャはまずコンポーネントにコンポーネントデータ確認メッセージを送る。このコンポーネントは、更に多くのＩＰＣメッセージを送る前にこの確認を待つことも可能である。このコンポーネントは、データ確認が受信され次第、続けて次のＩＰＣメッセージを送ることも可能である。
【００５７】
工程１３１６では、デバイス層が、ＩＰＣメッセージデータやＩＰＣヘッダなどを含むデータ表示メッセージを送る。ルータマネージャはこのメッセージの宛先ＩＰＣヘッダを検査し、ローカルＩＰＣアドレスと異なる場合、マネージャはこのメッセージを正当なＩＰＣノードに送る（ルーティングする）。工程１３１０では、セッションマネージャは確保したチャネルＩＤと共にデータ要求をルータ層に送る。セッションマネージャは宛先コンポーネントＩＤを検査し、これが０ｘＦＦに等しい場合、このメッセージを、このオペコードに加入しているコンポーネント全てにルーティングする。工程１３１８では、セッションマネージャはコンポーネントデータ表示メッセージを送りコンポーネントはＩＰＣデータを受信する。
【００５８】
このＩＰＣスタックは、確保した制御チャネルを全ての参加するＩＰＣノードの間で通信する為に使用する。電源投入時に、ＩＰＣサーバのセッションマネージャは、このリンクを使用してメッセージ群をＩＰＣクライアント群にブロードキャストし、また逆の場合も同様である。通常操作の間、この制御チャネルを使用してあらゆるＡＰ及びＢＰの間で制御情報が運ばれる。
【００５９】
図１４には、ＩＰＣスタックとＩＰＣハードウェアとの間に設置された制御チャネル１４０２〜１４０６が示されている。異なるＩＰＣハードウェア間でデータを送る際に、データパケット群１４１０と共に制御チャネル情報１４０８も送信される。そのＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスはその特定のプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。
ＩＰＣのＡＰＩ（ＡＰＰＬＩＣＡＴＩＯＮ ＰＲＯＧＲＡＭ ＩＮＴＥＲＦＡＣＥ）
以下に、本発明のＩＰＣプロトコルの為の高いレベルのＡＰＩを幾つかリストアップする。各々が定義された一組のＡＰＩの呼び出しを持つ。
１）コンポーネント／セッションの高いレベルのＡＰＩ
コンポーネントの登録及び認証
これは、コンポーネント群とそのローカルセッションマネージャとの間の登録及び認証のプロセスである。
コンポーネントの構成及び管理
これは、コンポーネントのローカルセッションマネージャによるコンポーネントの構成のプロセスである。
コンポーネントチャネルの管理
これは、データを他のＩＰＣノード群に送る為に論理チャネルを取得するプロセスである。
コンポーネントデータの管理
インバウンドＩＰＣデータ及びアウトバウンドＩＰＣデータに加えフロー制御もここで処理される。
コンポーネントルーティングのサービス
ＩＰＣパケット群のコンポーネントルーティングの複雑な部分がここで処理される。
２）デバイス／ルータのインタフェースの高いレベルのＡＰＩ
ＩＰＣパケットのルーティング
ＩＰＣパケット群のルーティングがここで処理される。
チャネル帯域幅の管理
論理チャネル／物理チャネルの管理がここで処理される。
ハードウェアポートのハードウェア検出
ＩＰＣリンクのハードウェア検出がここで処理される。
ＩＰＣ物理チャネル管理
アドレス割り当てがここで処理される。
【００６０】
図１５には、無線通信装置（例えば携帯電話等）などの電子デバイス１５００のブロック図が示されており、この電子デバイス１５００には、あるＩＰＣネットワークを用いて互いに通信しているベースバンドプロセッサ（ＢＰ）１５０２とアプリケーションプロセッサ（ＡＰ）１５０４とがある。本発明のＩＰＣプロトコルは、通信装置などのシステムの多数のプロセッサ同士間の通信を提供する。このＩＰＣは、移動通信応用（ＭＡ）クライアント（例えば、ｉＤＥＮ（登録商標）ＷＬＡＮ）をパーソナル通信システム（ＰＣＳ）応用などのＭＡサーバに登録させ、それぞれが自身のＭＡの中ではそれに依存しているソフトウェアアーキテクチャやオペレーティングシステムやハードウェアなどのうち、どれにおいても、いかなる制限も受けずに２つのＭＡが自由に通信できる手段を提供する。
【００６１】
このＩＰＣプロトコルにより、任意のＩＰＣ適合のＭＡが通信の為にＩＰＣリンクに動的に追加可能になる。よって、コンパイル時又はその他のソフトウェアの前提に全く依存せずにＩＰＣネットワークが形成される。本発明のＩＰＣは、ＩＰＣスタックと通信する為の標準的な方法をソフトウェアコンポーネント群に呈示し、そのスタックの下のハードウェアも抽出されるので、コンポーネント群が通信する為に異なるリンクを選べる。
【００６２】
ここで図１６を参照すると、ソフトウェアスレッド１６０２、１６０４、１６０６などの３つのコンポーネントと、このコンポーネント群がアウトバウンドストリーミングをどのように確立するかが示されている。ソフトウェアスレッド１６０２は、例えば、所定のＱｏＳ１６０８の要求１６１２を送り、自身のオペコード加入リスト１６１０を提出する。代わりに、メッセージ１６１８に応え、ソフトウェアスレッド１６０２はチャネルＩＤ１６１４とコンポーネントＩＤ１６１６とを割り当てられる。本発明のある実施形態に係るソフトウェアスレッド１６０２、１６０４、１６０６などのコンポーネントが、各自の要求に依存してＩＰＣハードウェアリソース群を割り当てられる。このコンポーネント１６０２、１６０４、１６０６は、このシステム要求に依存して動的にインストール又はアンインストール可能である。
【００６３】
図１７では、コンポーネント１６０２、１６０４、１６０６が、各自の割り当てられたチャネル、例えばソフトウェアスレッド１６０２ならチャネル１７０２などでＩＰＣデータを送る。このコンポーネント１６０２、１６０４、１６０６は各自のデータを目標のＩＰＣノードと共に提出し、ノードが指定されていないときはコンポーネント群が更に各自のメッセージを全てのＩＰＣノードにブロードキャストする。このコンポーネント１６０２、１６０４、１６０６は、宛先コンポーネント群のＩＤも、その関連付けられたチャネル群も、そのＩＰＣアドレスも知らなくてよい。インバウンドストリーミングに関しては、メッセージオペコード群がコンポーネント群を識別する。例えば、図１８では、コンポーネント１６０２、１６０４、１６０６がメッセージオペコード群により識別される。先に述べられたコンポーネントルーティングテーブルを介してコンポーネントＩＤ群が検出される。ＩＰＣセッションマネージャは、そのメッセージのＩＰＣオペコードに加入済みのコンポーネント全てに着信データをルーティングする。
ＩＰＣポート群の動的な専用化
改善されたオーバーヘッド効率を提供しシステムの待ち時間を低減させる為に、本発明に係るＩＰＣプロトコル／ネットワークがＩＰＣネットワーク内でのポート群の動的な専用化を提供する。例えば、クライアントのプロセッサが音声のサンプル又は他のリアルタイムデータなどの大量のデータを送信する必要があるとき、本発明に従い、クライアント及びサーバは一つ以上のサーバのポート／クライアントのポートの専用化を交渉する。
【００６４】
図１９にはＩＰＣネットワークが示されており、このＩＰＣネットワークには、サーバ１９０２と、このサーバ１９０２に結合された第１のクライアント（クライアント２）１９０４と第２のクライアント（クライアント３）１９０６と第３のクライアント（クライアント４）１９０８とがある。第１のクライアント１９０４は、自身に結合された２つのサブクライアント、即ちクライアント（２．１）１９１０とクライアント（２．２）１９１２とを持っており、第２のクライアント１９０６は、自身に結合された１つのサブクライアント、即ちクライアント（３．１）１９１４を持っている。第３のクライアント（クライアント４）１９０８は、自身に結合されたカメラ１９１６を持っている。図１９に示されているネットワークについて述べると、互いに直接的に結合されたノードをピアＩＰＣノードと呼び、例えば、クライアント２〜４（１９０４〜１９０８）はサーバ１９０２のピアノードであり、クライアント２．１及び２．２（１９１０〜１９１２）はクライアント２（１９０４）のピアＩＰＣノードである。あるＩＰＣピアノードがある一定のノードより高いレベルでも低いレベルでもよく、例えば、サーバ１９０２はクライアント２（１９０４）のピアＩＰＣノードであり、同時に、低いレベルのサブクライアント２．１及び２．２（１９１０〜１９１２）もクライアント２（１９０４）のピアＩＰＣノードである。
【００６５】
クライアント１９０４〜１９１４の各々はある範囲のアドレス群を割り当てられ、このクライアントの各々は、その範囲の他に、フローチャートに示されているように自身のポートアドレスとしてＩＰＣアドレスを手に入れる。サーバ１９０２は自身が持っているハードウェアポートの総数に亘って全ての使用可能なＩＰＣアドレスを分けるが、サーバ１９０２は自身の為にアドレス「２５４」を確保し、メッセージ群をＩＰＣネットワークに亘りブロードキャストする為にアドレス「０ｘＦＦ」が確保される。
【００６６】
この説明用の実例では、サーバは８つのポートを持っているので、２５６（この例でのアドレスの総数）を８で除算しポート毎に３２のアドレスが得られるものとする。よって第１のクライアント１９０４にアドレス０〜３１が割り当てられ、第２のクライアント１９０６にアドレス３２〜６４が割り当てられる。サブクライアント１９１０〜１９１４を持つクライアント１９０４及び１９０６の各々は、図２１に示されている続きのポート列挙フローチャートに更に示されているように、更に自身に割り当てられているＩＰＣアドレスをそれぞれのサブクライアント群に細分する。
【００６７】
クライアント１９０４〜１９１４の各々はそれぞれ、ＩＰＣアドレス対ハードウェアポートのマッピング情報を含む自身のネットワークルーティングテーブルを埋める。図１９に示されているカメラ１９１６がハードウェアＡＰＩ層（ＨＡＬ）を介してインタフェース接続しているので、このカメラ１９１６にはＰＣポートを割り当てない。このカメラ１９１６はコンポーネントに直接的にインタフェース接続する。そのコンポーネントはこのカメラのインタフェースに関するオペコード群を回送又は受信する。
【００６８】
図２２には、サーバ１９０２のネットワークルーティングテーブルが示されている。この特定の説明用の実例では、サーバのポート１がアドレス０〜３１に関連しており、第１のクライアント１９０４（アドレス３１を持つ）に結合されており、サーバの第２のポートがアドレス３２〜６４に関連しており、第２のクライアント１９０６（アドレス６４）と関連している、といったようになる。クライアント及びサブクライアント１９０４〜１９１４の各々は更に、各自のポート対ＩＰＣアドレスに関連している同様のネットワークルーティングテーブルを持っている。
【００６９】
本発明に従い、サブクライアント（２．１）１９１０が、音声のサンプルなどの情報を、音声のサンプルを復号できる第２のクライアント（クライアント３）１９０６に送信する為に専用のパスを必要とする場合、サブクライアント（２．１）１９１０はＩＰＣネットワークを介して第１のクライアント（クライアント２）１９０４にメッセージを送る。このメッセージは、ノードタイプや必要なＱｏＳを含む。クライアント１９０４は、そのＱｏＳをクライアント１９０４がサポートできる場合、サブクライアント１９１０に結合されたポートを専用化する。クライアント１９０４はメッセージを前述のノードタイプ及びＱｏＳ要求と共にサーバ１９０２に回送する。サーバ１９０２は、その要求をサーバ１９０２がサポートできると判断した場合、サーバ１９０２のポート１及び２の両方を専用化する。それからサーバ１９０２は、そのノードタイプやＱｏＳ情報を含んだメッセージをクライアント１９０６に送る。更にまた、クライアント１９０６がその要求をサポートできる場合、クライアント１９０６は自身のポートをその要求の専用にする。ここで、サブクライアント１９１０はクライアント１９０６までずっと続く専用のパスを手に入れた。リンクを確立しなくてはならない、各ＩＰＣノードのルータ層は、このリンクの次のノードに必要なＱｏＳに基づいてチャネル群の確保を処理する。ルータ層は、デバイス層にチャネルを要求することにより、適切なチャネルを要求し確保しなくてはならない。
【００７０】
ここで図２３を参照すると、サーバ１９０２のポート専用化テーブル２３００が示されている。このポート専用化テーブル２３００はＩＰＣスタックのルータ層に保存されており、サーバのポートの各々をリンクさせ専用の状況又は非専用の状況にする。特定のポート（単数又は複数）が専用化されている場合、サーバ１９０２がその専用化の解除を望む場合（例えば、一つ以上の専用のポートを必要とするもっと優先権の高い要求が入ってきた場合）を除いては、サーバ１９０２はこのポート群を他のタスクには割り当てない。クライアント１９０４〜１９０８とサブクライアント１９１０〜１９１４の各々は、自身のポートと、自身のポートの各々の現在の専用化の状況とに関連するポート専用化テーブルを持つ。
【００７１】
この確保のプロセスは、所望の動作モード毎に違うやり方を選択して実施できる。実例として、ノードのクライアント２．１から２へのパスを、必要なＱｏＳにより専用化することができる場合、ルータはテーブルのポートを専用化する。ネクストホップ要求がリンク内の次のＩＰＣノードに行く。この場合は、ノード２．１はクライアント３に向かうパスの次のリンクを専用化しようとする。クライアント２とクライアント１とがそのリンクを現時点で専用化できない場合には、当面のあいだ待つ為にタイマを始動することができる。タイマの満了時に、本来の要求側にメッセージが送られ、既に確立されたリンクが任意選択で中止されるか、クライアント２とクライアント３との間のタイマが更に延長される。このリンクが無事に確立された場合、ＯＫステータスメッセージが送り返されて、本来の要求していたコンポーネント（単数又は複数）は通告される。
【００７２】
サブクライアント１９１０、クライアント１９０４、サーバ１９０２、クライアント１９０６のそれぞれに専用のルータ層毎に、サブクライアント（クライアント２．１）１９１０はクライアント（クライアント３）１９０６への専用のパスを持っている。これにより、このパスが専用化され次第、パケット群の転送の際にヘッダ情報を含まなくてよいので、データ転送を簡略化しオーバーヘッドを少なくすることができる。
【００７３】
図２４には、コンポーネントチャネル要求シーケンスが示されており、これには、コンポーネントチャネル要求に加え、セッション層からルータ層へのチャネル要求、デバイスからセッション層へのチャネル返答、コンポーネントチャネル返答が含まれる。送信された変数（例えば、ノードＩＤやＱｏＳ等）の全てが示されている。図２５には、チャネル返答やピアツーピア要求が含まれるルータ層のチャネル要求が示されており、ピアツーピア要求には、次のルータ層とのエンドツーエンドのパスでの通信が含まれ、このエンドツーエンドのパスは専用でなくてはならない。更に示されているのは、ピアツーピアタイムアウト要求であり、これは、パスに沿ったデバイス層の一つがチャネルを所定の期間内に配分できない場合、前もって確保されたチャネル全てを含むリンクを解消させる。このルータ層のチャネル要求は、専用である通信パスのリンク毎に（このパスのＩＰＣクライアント／サーバ毎に）繰り返される。
【００７４】
本発明の好適な実施形態が図示され記載されたが、本発明はそのように制限されてはいないことが明白である。当業者は、添付の請求項により規定された本発明から逸脱することなく、非常に多くの、修正、変更、変形、代用、同等物を考え付くであろう。
【図面の簡単な説明】
【００７５】
【図１】本発明のある実施形態に係るＩＰＣネットワークの図。
【図２】本発明のある実施形態に係るＩＰＣスタック。
【図３】本発明のある実施形態に係るＩＰＣコンポーネントのＩＰＣ割り当て。
【図４】本発明のある実施形態に係る主要なＩＰＣテーブル群。
【図５】本発明のある実施形態に係るチャネル配分を示す図。
【図６】本発明のある実施形態に係るＩＰＣクライアントの初期化ルーチンの間に伴う工程を強調表示する図。
【図７】本発明のある実施形態に係るＩＰＣクライアントの初期化の間に伴う工程を強調表示する別の図。
【図８】本発明のある実施形態に係るＩＰＣカプセル化の第１のレベルを強調表示する図。
【図９】本発明のある実施形態に係るＩＰＣコンポーネントの初期化の間になされる工程を強調表示する図。
【図１０】本発明のある実施形態に係るコンポーネントの初期化の間になされる工程を強調表示するチャート。
【図１１】本発明のある実施形態に係るＩＰＣクライアントとＩＰＣサーバとの間のＩＰＣデータの転送。
【図１２】本発明のある実施形態に係るＩＰＣデータのヘッダの図。
【図１３】本発明のある実施形態に係るＩＰＣデータ要求の間になされる工程の図。
【図１４】本発明のある実施形態に係るＩＰＣネットワーク。
【図１５】本発明のある実施形態に係る無線通信装置などの電子デバイス。
【図１６】本発明のある実施形態に係るアウトバウンドストリーミングの図。
【図１７】本発明のある実施形態に係るアウトバウンドストリーミングの図。
【図１８】本発明のある実施形態に係るインバウンドストリーミングの図。
【図１９】本発明のある実施形態に係るＩＰＣシステムの図。
【図２０】本発明のある実施形態に係る図１９に示されているシステムのハードウェアポート列挙フローチャート。
【図２１】図２０のハードウェアポート列挙フローチャートの続き。
【図２２】本発明のある実施形態に係るネットワークルーティングテーブル。
【図２３】本発明のある実施形態に係るポート専用化テーブル。
【図２４】本発明のある実施形態に係るコンポーネントチャネル要求シーケンス。
【図２５】本発明のある実施形態に係るピアツーピアのルータチャネル要求シーケンス。
【技術分野】
【０００１】
本発明は一般に電子機器の分野に関し、より具体的にはポート群の動的な専用化を提供するプロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
大部分の電子システムには、そのシステムを形成しているハードウェアやソフトウェアなどの多数のネットワーク要素（コンポーネント群）がある。大部分のシステムには、異なるネットワーク要素とシステム自身との間の通信に加えて、ネットワーク要素を形成する異なるコンポーネント間の通信を担当している層がある。この層は典型的にプロセッサ間通信（ＩＰＣ）層と呼ばれている。
【０００３】
この数年の間に、プロセッサ間通信（ＩＰＣ）に対処する為に幾つかのプロトコルが導入された。ＩＰＣ製品のある例は、ホスト‐ＰＣＩブリッジとＤＲＡＭの制御装置及びデータパスと、加速式グラフィックスポート（ＡＧＰ）のインタフェースとを一体化するＰＣＩのＡＧＰ制御装置（ＰＡＣ）である。ＩＰＣ製品の別の例はＯＭＡＰ（登録商標）プラットフォームである。このどちらのプラットフォームも、より低いレベルのコンポーネントレベル又はチャネルレベル（物理層）では、サポートがあるとしてもハードウェアのレベルを上回るサポートを提供せず、設計の柔軟性もほとんどもたらさない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述のプラットフォームはコンポーネントレベルまでは及ばず、加えて、ハードウェアのサポート能力や、マルチノードのルーティング等を考慮しておらず、しかもＩＰＣリソースの動的な割り当てを考慮していない。低消費電力と短いシステムの待ち時間が必要性なので、当該分野では、ＩＰＣシステムでリアルタイムデータなどのデータを転送する際の無駄な時間を減らすために、ポート群の動的な専用化を提供できるＩＰＣネットワークが必要とされている。
【課題を解決するための手段】
【０００５】
本発明のＩＰＣは、あるシステムで相互通信する異なるプロセッサに必要なサポートを提供する。例えば、アプリケーションプロセッサ（ＡＰ）やベースバンドプロセッサ（ＢＰ）を含む無線通信装置用のデュアルプロセッサ（又はマルチプロセッサ）の無線アーキテクチャで、このＩＰＣは、効率的に通信しあう為にプロセッサ群が必要とするサポートを提供する。このＩＰＣは、ＡＰ又はＢＰの設計に何の抑制も課すことなくこのサポートを提供する。
【０００６】
概して、デュアルコアアーキテクチャは、ＡＰとＢＰとの間で仕事を分けることを表す。ＢＰはリアルタイムの且つ無線によるデータを処理し、ＡＰはそのデータをパッケージし、それをユーザに呈示する。この２つはサービスの為に互いに依存しており、その動作をＩＰＣメッセージ群の交換によって行う。この２つのサービスは変動するので、データの長さも速度も二地点間の交換も変動する。ＩＰＣの目的は、このサービス群が何であるかを定義することでもなければＡＰ及びＢＰの設計に制約を課すことでもない。代わりに、このＩＰＣは、このＩＰＣをプロセッサ間通信のスタックとして採用したＡＰ又はＢＰはどれでも、共存させなくてはならず、このＩＰＣは、共通のＯＳとメモリとを共有している同一のコアでＡＰとＢＰとが実際に動いているかのように動作する。多数のプロセッサを通信装置で使用することが標準になってくると、本発明のＩＰＣは異なるプロセッサ間の信頼性の高い通信を提供する。
【０００７】
このＩＰＣハードウェアは、異なるプロセッサをＩＰＣネットワークに結び付けて物理的に接続する。本発明のある実施形態では、データパケット群が異なるホスト間で同期せずに移送されることが好ましい。このＩＰＣネットワークに接続されたプロセッサ群は、統計的に又は動的に割り当てられた自身の物理アドレスと論理アドレス（例えば、ＩＰＣアドレス）とを持つ。更に、本発明のある実施形態では、データパケット群はこのＩＰＣネットワーク内ではどの方向にも流れる可能性があるので、データパケット群は、自身が到着しようとしているプロセッサの宛先アドレスを持っていなくてはならない。このソースＩＰＣアドレスは直接返答する為に用いられる。パケット群のルーティングが全ノード間でサポートされる。更にパケット群が、従来の巡回冗長検査（ＣＲＣ）技術を用いてエラーを検査することが好ましい。
【発明を実施するための最良の形態】
【０００８】
新規性がある本発明の特質を、添付の請求項で詳細に述べる。本発明を最も良く理解してもらうために、添付の図面を参照して以下の説明を行う。このうち幾つかの図では同じ参照数字が同じ要素を示す。
【０００９】
本明細書は、新規性がある本発明の特質を定義する請求項で締めくくられているが、本発明は、図面を併用して以下の説明を検討することによって、より良く理解されると考えられる。
【００１０】
ここで図１を参照すると、本発明のある実施形態に係るＩＰＣネットワーク１００が示されている。このＩＰＣネットワーク１００には、複数のＩＰＣクライアント１０２〜１０６及びサブクライアント群（他のクライアント群に結合されたクライアント群）１１６〜１１８と、異なるＩＰＣ物理リンク群を用いてこのＩＰＣクライアント群１０２〜１０６に結合されたＩＰＣサーバ１０８とがあり、ＩＰＣ物理リンク群とは、例えば、説明用の実例の、共有されているメモリ１１０や、汎用非同期送受信装置（ＵＡＲＴ）１１２や、ユニバーサルシリアルバス（ＵＳＢ）１１４などである。注目すべきは、本発明のＩＰＣによって、あるＩＰＣクライアント１０２〜１０６が、現在のＩＰＣサーバ１０８と、役割の切り換えについて交渉できることである。あるＩＰＣクライアント１０２〜１０６がＩＰＣサーバになることを交渉し、新しいＩＰＣサーバになることを現サーバが承諾した場合、残りのＩＰＣクライアントの全てが、ネットワークに変更があったことを知らされる。
【００１１】
図２には、本発明の実施形態に係るＩＰＣサーバ１０８（又はＩＰＣクライアント１０２〜１０６）のＩＰＣスタック２００が示されている。このＩＰＣスタック２００の設計は、オペレーティングシステム（ＯＳ）の下で一体化されるよう、コンポーネントのトラフィックのプロセッサ間通信のニーズをサポートするようになされている。このコンポーネント２２４と２２６とが自身のＩＰＣネットワークのサービスをＡＰＩサービス呼群によって請求する。コンポーネント同士間の物理的な通信の複雑な部分がＩＰＣスタック２００により処理され、従って同様にあらゆるハードウェア依存が抽出されつくす。このＩＰＣスタック２００は、ＯＳに特有のＡＰＩ層２２０によって特定のＯＳに結合された状態で示されている。
【００１２】
このＩＰＣスタック２００は下記の５つの主要な層によって構成されている。
（１）ＩＰＣプレゼンテーションマネージャ（２０２） この層は、異なるシステムコンポーネント（例えば、ソフトウェアスレッド）の間で異なるデータタイプを変換する為に使用される。異なるタイプのプロセッサコア同士間のそのデータ変換に伴う問題を克服するのに十分なハードウェアが提供されている場合には、この層を迂回してもよい。
【００１３】
（２）ＩＰＣセッションマネージャ（２０４） この層は、ＩＰＣスタックとシステムコンポーネントの全てとの間の着信／発信のＩＰＣトラフィック全てのセントラルリポジトリである。このＩＰＣセッションマネージャ２０４には主要な機能が幾つかあり、その中には、参加するＩＰＣコンポーネントへのコンポーネントＩＤの割り当て、ＩＰＣアドレスの割り当て、認証／登録と、コンポーネントの認証、コンポーネント群へのルーティング、他のＩＰＣノード群へのルーティングなどがある。この層は、ＩＰＣサーバとクライアントとを区別する唯一の層である。このセッション層はＩＰＣノード群を検出する。
【００１４】
こういったクライアントのセッション層のサービスは、サーバのセッション層のサブセットである。クライアントにより提供されるこういったサービスに加え、サーバが下記の機能を処理する。
【００１５】
１．ＩＰＣノード群の認証及び登録
２．ＩＰＣノードの特権を無効にする権限
３．ＤＲＴの同期
４．ＩＰＣアドレスブロックの割り当て
５．ネットワークセキュリティ
コンパイル時には、あるＩＰＣノードがあるサーバの役割を割り当てられる。しかし、任意の（信頼できる）ＩＰＣノードが実行時間の交渉によってサーバの仕事を引き受ける方法が提供されたほうがよい。この方法は、通信を保持したままでネットワークからサーバのノードを正常に除去するよう柔軟性をもたらすはずである。
【００１６】
（３）ＩＰＣルータ層（２０６） このＩＰＣルータ層は、ネットワークルーティングやポート専用化テーブルなどの必要なルーティング情報の全てを保存する。このＩＰＣルータ層は、割り当てられたアドレス群と、そのサーバ又はあるクライアント内の専用化されたあらゆるポートとを常時監視している。この層は、ネットワーク全体に亘る任意のＱｏＳについてのエンドツーエンドの帯域幅の配分の確保も担当している。
【００１７】
ＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスがそのプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。このＩＰＣサーバによってのみＩＰＣアドレス群が動的に割り当てられる。このサーバを含むある特定のネットワークの中ではＩＰＣノードは最大２５５個である。このネットワークからあるノードが除去されたとき、そのノードのＩＰＣアドレスは無効になり新しいＩＰＣノードに割り当て可能になる。このルータ層はパケット群のブロードキャストとＱｏＳのピアツーピアとをサポートしなければならない。ルータは、そのノードの認証／登録が済むまでは、どんなパケットもルーティングしてはならない。
【００１８】
（４）ＩＰＣデバイスインタフェース層（２０８） このデバイス層は、あらゆるインバウンドトラフィックとアウトバウンドトラフィックの物理媒体を抽出する。このＩＰＣスタックの上位層群は、制御及びコンポーネントを移送するＩＰＣスタックのサービス群とこのリンク全体に亘るコンポーネントのトラフィックとに頼っている。このデバイス層に接続された物理的ＩＰＣリンクは２つ以上の場合がある。このデバイス層の主要な機能の中には、ハードウェアポート群の検出、ポート群の列挙、パケット群の多重化及び多重分離、コンポーネント群への論理チャネル群の割り当て、物理媒体の同期、割り当てられたチャネル毎の物理的な帯域幅の保証などがある。
【００１９】
このデバイス層はＡＰＩの一組のＨＡＬを介してハードウェアとインタフェース接続する。このデバイス層は、ＩＰＣの物理チャネルから論理チャネルへのマッピングの割り当てを管理する。この層は、あらゆるＩＰＣハードウェアポートに亘るデータフローをサポートするようこのＩＰＣリンク下部の物理的な帯域幅の管理を任されている。この層は、多数のポート接続をサポートすると同時にＩＰＣノード群のデイジーチェーン接続もサポートする。このデバイス層は更に、専用の及び非専用のＩＰＣチャネル群のＱｏＳも管理する。この層は、ＩＰＣデータを送受信する為の多重化操作及び多重分離操作を提供する。メッセージ群が構築されたら、この層はそのメッセージ群をその後の処理に向けセッションマネージャ２０４に回送する。
【００２０】
このデバイスインタフェース層は、ＩＰＣの物理ＩＰＣチャネルから論理ＩＰＣチャネルへの管理を担当している。その主要な機能は、このスタックＩＰＣが独立したハードウェアになるよう、ＩＰＣハードウェアを完全に抽出することである。このデバイスインタフェース層は更に、ＩＰＣ論理チャネル群の全てをサポートするようこのＩＰＣリンク下部の物理的な帯域幅を管理する。着信パスでは、このデバイスインタフェース層が異なる物理チャネル群からデータを手に入れこのデータを残りのＩＰＣスタックまで通過させる。発信パスでは、このデバイスインタフェース層が、そのデータを適切な物理チャネル群に送ることによりそのデータをＩＰＣ論理チャネル群がロードするのを管理する。このデバイスインタフェース層は更に、そのデータをＩＰＣハードウェアに送る前に、同一のＩＰＣチャネルに属するＩＰＣパケット群の連結も処理する。チャネルの要求がＩＰＣセッションマネージャとＩＰＣデバイスインタフェース層との間で前もって交渉される。このデバイスインタフェース層は、ハードウェアポート群を提供し、このハードウェアポート群が次にデバイスインタフェースをあるＩＰＣクライアントに提供する。
【００２１】
このＩＰＣスタックは、確保した制御チャネルを全ての参加するＩＰＣノード間で通信する為に使用する。電源投入時に、このＩＰＣセッションマネージャのサーバが、このリンクを使用してメッセージ群をＩＰＣクライアント群にブロードキャストし、また逆の場合も同様である。通常操作の間、このチャネルを使用してあらゆるＡＰ及びＢＰの間で制御情報が運ばれる。制御チャネルは、その真下のＩＰＣリンクから独立して、デバイス層によって帯域幅を保証されている必要がある。
【００２２】
（５）ＩＰＣハードウェアＡＰＩ層（２１０） この層は、物理層のハードウェアポート群と残りのＩＰＣスタックとの間に必要なインタフェースを提供する。このハードウェアＡＰＩ層は更にこのハードウェアポート群とこのＩＰＣスタックとＯＳとの間に任意のプロトコル変換をもたらす。
【００２３】
このＩＰＣネットワークは、一組の物理リンクを介して一緒に通信するＩＰＣノード群から成っている。このＩＰＣネットワークについては、ノードを、このネットワーク上でＩＰＣ制御メッセージ群とデータメッセージ群とを他のノード群へ又は他のノード群から送受信する能力がある完全にＩＰＣスタックに準拠したエンティティと定義する。各ＩＰＣノードが多数のＩＰＣリンクをデイジーチェーン接続操作の為にサポートする。このＩＰＣサーバは単に、このＩＰＣクライアント群の登録／認証及びＩＰＣアドレス割り当てを担当しているノードである。どのネットワークにもＩＰＣサーバは一つだけしかないが、ＩＰＣクライアントのノードは幾つかある。各ＩＰＣノードは、このネットワークへの「ホット接続」の間か電源投入中は、動的に自身に割り当てられた一つの固有なＩＰＣアドレスを持っている。
【００２４】
ＩＰＣデータパケット群及び制御パケット群は、固有なＩＰＣオペコード群（例えば、オーディオ復号のオペコードや、充電の為のＡＴコマンドのオペコード等）を持っている。このＩＰＣオペコード群は、そのＩＰＣパケットで受信するＩＰＣデータのタイプを指定する。ＩＰＣノードタイプはそのＩＰＣノードを識別する固有なものである。コンポーネント２２４や２２６などのＩＰＣコンポーネントには、そのＩＰＣノードタイプ群が何を意味するのかと各ＩＰＣオペコードが何のために用いられるのかについてのプリコンパイル済みの知識がある。
【００２５】
ＩＰＣノードタイプの例には、ｉＤＥＮ（登録商標）のＢＰ、ＧＰＲＳのＢＰ等がある。同様に、別個の文書もそのＩＰＣオペコード群と自身のデータ構造群とを定義する。コンポーネントソフトウェアは、この２つの固有なデータ定義を知ってさえいればよい。通信の複雑な部分はこのＩＰＣスタックに委ねられている。このスタックの一部がルータ群でありＩＰＣノード同士間のメッセージフロー操作を処理する。フロー制御はこのＩＰＣスタック自身の機能であり、セッション層で透かし群を用いて実施される。
ＩＰＣアドレス割り当て
ＩＰＣアドレス群がＩＰＣサーバ１０８とピアノード群とによってのみ割り当てられる。このノードは常に、自身に割り当てられたアドレスの範囲から最上位のＩＰＣアドレスを選び取る。よってこのノードはこのＩＰＣアドレスによって分かる。ノードがもう使用不可能なとき、そのＩＰＣの特権は無効になり、従ってそのＩＰＣアドレスももう有効ではない。このＩＰＣソフトウェアがこのＩＰＣノードの情報を無効化しネットワークから除去する。除去されたＩＰＣノードにメッセージ群が送られた場合、親ルータが不正な宛先アドレスと共にエラーメッセージを戻す。一つのノードが２つ以上のＩＰＣアドレスを持つことはできない。ＩＰＣアドレス群は任意のＩＰＣネットワーク内で固有である。サーバのＩＰＣアドレスは常に２５４に設定されている。サービス群のブロードキャストの為にアドレス２５５が確保される。
【００２６】
ＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスがそのプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。このＩＰＣサーバによってのみＩＰＣアドレス群が動的に割り当てられる。このネットワークからノードが除去されたとき、そのＩＰＣアドレスは無効になり新しいＩＰＣノードに割り当て可能になる。
ＩＰＣメッセージのルーティング
このＩＰＣネットワークで何らかの通信を行うことを希望するＩＰＣノードは全て、まずこのＩＰＣセッションサーバに登録しなければならない。認証が無事終了した後で、要求しているＩＰＣノードがそのＩＰＣネットワークでの通信の資格を得る。どのＩＰＣノードにもルータがある。その機能は、ＩＰＣメッセージ群を次の宛先ノードにルーティングするか、このルータがこのＩＰＣアドレスを任意のハードウェアポートの宛先のどれにも変えられない場合にはＩＰＣメッセージ群を解消させることである。このルータがＩＰＣメッセージ群を別のノードに回送している場合、このルータはこのメッセージをセッションマネージャまで通過させない。多数のノードに亘る通信チャネルを必要とするコンポーネント群は、それぞれ各自のルータを介してその全てのノードに亘る終端間のＱｏＳを要求する必要がある。その下のデバイス層からのチャネルのＱｏＳをルータが要求してもよい。
ＩＰＣヘッダ
図３に示されているのはＩＰＣヘッダ３００である。このヘッダを全てのＩＰＣパケットが持っている。ソースＩＰＣアドレス及び宛先ＩＰＣアドレスをセッションマネージャが埋める。ソースコンポーネント識別番号（ＣＩＤ）はデータ要求の間に送られるものであり、宛先ＣＩＤは任意選択である。目標のＣＩＤが書き込まれなかった場合、この宛先ノードはこのＩＰＣメッセージを全ての加入しているコンポーネントに回送する。宛先ＣＩＤがソースコンポーネントにより書き込まれた場合には、このＩＰＣメッセージはそのコンポーネントにのみルーティングされる。セッション層により最終のデータチェックサムが書き込まれ任意選択で作動させられたり作動させられなかったりする。ルータがＩＰＣヘッダにルータの制御語を書き込んだ場合、このチェックサムは更新される必要がある。このチェックサムの計算にはＩＰＣヘッダとメッセージのデータ部とが含まれる。デバイス層によりセッション層に向けてパケット群が受信側に送り届けられるとき、前者は、何らかのデータを上に向けて回送するより前に、チェックサムが検証されたことを確かめる。データチェックサムを任意選択で省いてもよいが、このＩＰＣヘッダのチェックサムは常に含まれていなくてはならない。このチェックサムの最上位ビットは、このＩＰＣパケットに属するデータがＯＮかＯＦＦかを示す。ＯＮを「１」の状態が示し、ＯＦＦを「０」の状態が示す。このＩＰＣヘッダは合計７バイトである。このＩＰＣデータフィールドは単に図示の為に示されており、そのサイズはＩＰＣパケットのデータ構造に依存している。
【００２７】
ＩＰＣ通信への参加を希望している新しいコンポーネントはみな、こういった動作を、まず、ＩＰＣ識別番号（ＩＤ）をそのＩＰＣセッションマネージャ（例えば、セッションマネージャ２０４など）に要求することによって行わなければならない。このローカルセッションマネージャ（例えば、そのコンポーネントが結合されているクライアントに設置されたセッションマネージャ）は次にＩＰＣサーバのセッションマネージャにこの新しいＩＰＣコンポーネント群について通告し、ＣＩＤの割り当てが提供される。本発明のある実施形態に従って、このＣＩＤ群は動的であり、セッションマネージャ（例えば、サーバのセッションマネージャ）により再び割り当て可能である。このＩＰＣサーバは主要なＡＰ上にある可能性が最も高い。各ＩＰＣノードは固有なＩＰＣノードＩＤを持っていることが好ましく、セッションマネージャはそのデータベースに下記の情報を参加しているＩＰＣノード毎に保持する。
【００２８】
ＩＰＣノードタイプ：例えば、特定のＢＰ又はＡＰ、無線ローカルエリアネットワーク（ＷＬＡＮ）のＡＰなど。
ＩＰＣアドレス：ＩＰＣノードのＩＰＣアドレス。
【００２９】
データタイプ：ＩＰＣノードのデータタイプ。
オペコードリスト：このリストは、コンポーネントが加入しているＩＰＣメッセージオペコード全てのリストである。
【００３０】
コンポーネントＩＤ：ＣＩＤ全てのリスト。
ここで図４を参照すると、ＩＰＣスタックが全ての主要なＩＰＣテーブルと共に示されている。動的なルーティングテーブル（ＤＲＴ）４０２には、ノードタイプ（プロセッサタイプ）、ＩＰＣアドレス情報、データタイプ、加入リストなどがある。この加入リストには、特定のノードのＩＰＣにサポートされたメッセージオペコードの全てが含まれている。コンポーネントルーティングテーブル４０４には、オペコードの情報と各特定のオペコードに加入しているコンポーネントの全てとに関連している情報が含まれている。最後に、チャネルリソーステーブル４０６には各チャネルＩＤを物理チャネルＩＤのリストと関連させることが含まれている。
【００３１】
このＩＰＣスタックの幾つかの重要な機能とサービスとをセッション層（セッションマネージャ）が提供する。クライアントのこのＩＰＣセッション層はサーバのＩＰＣセッション層のサブセットである。ＩＰＣプロトコルをＩＰＣノード群が全部サポートする。ＩＰＣサーバに登録され認証され次第、クライアントのＩＰＣセッション層はこのＩＰＣネットワークを介して通信可能になる。次にＤＲＴがこのノードのセッション層で作成されサーバに送られる。そしてサーバはＤＲＴのコピーをネットワークのそのＩＰＣノード群に回送する。このコピーは活動中のＩＰＣノードの各々にその他の参加しているノードについての十分な情報を提供する。
【００３２】
ＩＰＣノードタイプとＩＰＣオペコードには、各製造者が製造者自身の値を自由に選び割り当てることができる。ＩＰＣノードのタイプをＤＲＴ４０２の第１の入力が識別する。例えば、ｉＤＥＮのベースバンド（ＢＰ）が１６進値の０ｘ０１を持つと仮定する。このＩＰＣアドレスは、このノードがこのＩＰＣネットワークに特定のハードウェアポートでつながれている限り、このノードに固有である。このアドレスは、本文書のルータの節で述べられたように、このノードのピアノード（より高いレベルで結合されたノード）により割り当てられている。このデータタイプがコア及びデータのアライメントのルールのタイプを記載する。このノードに登録され構成されたコンポーネント加入オペコードリスト全てをＩＰＣオペコードリストが組み合わせる。このＤＲＴのコピーが活動中のＩＰＣノード全てにＩＰＣサーバにより回送される。特定のノードについてこのＩＰＣオペコードリストの変更があった場合、新しいコピーがサーバに送られる。するとサーバは新しい情報を活動中のＩＰＣノード全てに回送する。
アウトバウンドデータの為のＩＰＣノードアドレス検出
各ＩＰＣノードがこのＩＰＣネットワークの活動中のＤＲＴ全ての最新のコピーを保有する。各ＩＰＣノードのＤＲＴに変更があった場合、ＩＰＣサーバへの通告をセッション層が担当している。コンポーネントがそのパケットデータを送信の為にこのセッション層に回送するとき、コンポーネントは目標のノードの物理ＩＰＣアドレスについて何も知らない。代わりに、コンポーネントがそのＩＰＣノードタイプにより目標のＩＰＣノードを指定する。目標のＩＰＣノードタイプに対応する目標のＩＰＣアドレスを検出するのはセッション層にかかっている。目標のノードがこのＩＰＣネットワークで使用可能な場合、このＩＰＣアドレスはその対応するＤＲＴからフェッチされる。他の場合には、このコンポーネントにエラーが戻される。よってこのコンポーネントは適切なＡＰＩの機能を使用してネットワークの既存のＩＰＣノードについての情報を知ることができる。
インバウンドデータの為のＩＰＣコンポーネント検出
そのノードでＩＰＣパケットが受信されたとき、ＩＰＣパケットの目標のＩＰＣアドレスがルータにより検査される。そのＩＰＣアドレスがノードのものだった場合、そのパケットはその後の処理に向けセッション層に回送される。このセッションは、登録されているコンポーネント群のオペコード加入リストに基づいて、そのメッセージをそのコンポーネント群に分配することを担当している。ＩＰＣパケット群は、加入リスト群とフィルタテーブル群とに依存して２つ以上のコンポーネントにより消費可能である。前述のように、コンポーネント群は、その構成プロセスの間に自身でＩＰＣオペコード群又はサービス群に加入する。次に、セッション層がオペコード加入リスト（加入リスト）を構築して、インバウンドデータのＩＰＣコンポーネントルーティングを助ける。
ＩＰＣコンポーネントルーティング層
セッションマネージャにはＩＰＣコンポーネントルーティング層が備わっており、加入しているコンポーネント群と、データの完全な消費時にはバッファのないメモリとへのデータパケット群のブロードキャストと分配とを担当している。受信されたデータがどのコンポーネントによっても変えられない又は修正されないことが条件である。バッファデータへの上書きを希望するコンポーネント群は、まずローカルコピーを作り、ＩＰＣコンポーネントルーティング層に本来のバッファの解放の表示を送る。
【００３３】
このＩＰＣコンポーネントルーティング層の一部がフロー制御である。コンポーネント毎に透かしをプログラムできる。データパケット群が蓄積しており開放されてないとき、セッションマネージャは、ＩＰＣネットワークでフロー制御表示をブロードキャストする決定を下す。ＩＰＣノードが十分なパケット群を消費し透かしを下回るとき、データパケット群の受信を再開する為に別のフロー制御表示が送られる。コンポーネントのサービスがどれであるかを明らかにする又は単純に問題になっているＩＰＣノードとの通信を遮断することで、情報を特定のコンポーネントに送るのを控えるようＩＰＣノード群に通告する為にフロー制御を使用できる。
【００３４】
図５には、本発明のある実施形態に係るＩＰＣスタックがＩＰＣチャネルをソフトウェアスレッド（例えば、オーディオ等）などのコンポーネントに提供する方法のブロック図が示されている。まず工程５０４でコンポーネント５０２がＩＰＣチャネルを要求する。図５に示されているセッションマネージャが、定義されたＡＰＩを用いて工程５０６でコンポーネントの要求をデバイス層と交渉する。それからデバイス層（デバイスインタフェース）が、データチャネル５０８などのハードウェアリソースを要求する。図５に示されているセッションマネージャが、工程５１０で、要求に応えて、その要求者にあるＩＰＣチャネルを付与する。次にコンポーネント５０２が割り当てられたチャネル５０８で自身のデータを送る。それからデバイス層がそのデータをＩＰＣネットワークに回送する。論理チャネルＩＤから物理チャネルＩＤへのマッピングはＩＰＣデバイスインタフェースの役目である。
【００３５】
ここで図６を参照すると、ＩＰＣクライアント初期化の第１の工程は、ローカルノードのルータによりＩＰＣアドレス割り当て要求を送る工程である。ここでは全クライアントが、そのクライアントのピアノードからそのクライアントが肯定応答を受信するまで待機する。アドレス割り当てが受信されたとき、このクライアント群はまず、ＩＰＣクライアント６０２とＩＰＣサーバ６０４との間で登録要求を送る（工程６０６）。すると工程６０８でＩＰＣサーバ６０４はＩＰＣクライアント６０２に対しその要求を認証する。これにより工程６１０で登録が完了する。工程６１２でこのＩＰＣクライアントのセッションマンガーがその動的なルーティングテーブルのコピーをＩＰＣサーバに送る。
【００３６】
このＩＰＣクライアント初期化のプロセスの間になされる工程がより詳しく図７に示されている。工程７０２で、クライアントセッションマネージャ（表ではセッション（クライアント）として示す）がＩＰＣサーバのセッションマネージャ（表ではセッション（サーバ）として示す）に構成要求を送る。工程７０４では、このＩＰＣサーバのセッションマネージャにより認証が要求される。よって工程７０６でＩＰＣクライアントとＩＰＣサーバとの間の認証が実行された。
【００３７】
構成要求のパラメータには、ノードタイプ、データタイプ、そのノードの動的なルーティングテーブルなどがある。セッションサーバは工程７０２の構成要求に応えて要求側にＩＰＣアドレスを割り当てる。このセッションサーバは更に、動的なルーティングテーブルがない場合、要求側の為に動的なルーティングテーブルをセットアップする。その後、工程７０８に見られるように、セッションサーバは要求側に構成表示を送る。
【００３８】
この構成表示の受信に応えて、セッションクライアントに付随するコンポーネント群がクライアントのセッションマネージャに制御／データを要求する。すると工程７１０でセッションクライアントは構成表示確認メッセージをセッションサーバに送る。この「構成表示確認」メッセージにはパラメータがなく、工程７１０で構成表示確認メッセージを受信すると、セッションサーバは新たに構成されたセッションクライアントに対しＩＰＣストリーム群を起動できる。それから工程７１２と工程７１４とでセッションサーバはセッションクライアント群に構成更新メッセージ群を送る。これにより、図７に示されているセッションクライアント両方がそれぞれの動的なルーティングテーブル（図示せず）を更新し、工程７１６と工程７１８とでセッションサーバに構成更新確認メッセージを送ることになる。この構成更新確認メッセージ群を受信したとき、セッションサーバはＩＰＣ参加者の全てが更新されたことを確かめる。
【００３９】
別のノードのＩＰＣセッションマネージャによりパケットが受信されたとき、これはデータの形になり、このデータの形には、ソースコンポーネントＩＤ、宛先ＩＤ、ＢＰ又はＡＰのタイプなどがある。このＩＰＣセッションマネージャは、宛先ＩＤが書き込まれなかった場合には宛先コンポーネントＩＤを追加する。このＩＰＣセッションマネージャが、この宛先ＩＤを、受信したメッセージオペコードに基づいて検出する。この宛先ＩＤはあるルックアップテーブルに基づいている。このルックアップテーブルは、コンポーネントが新しいＩＰＣメッセージオペコードに加入する（例えば、ＩＰＣセッションマネージャに要求を送ることによりあるオーディオコンポーネントがオーディオメッセージ群に加入する）たびに動的に更新される。
【００４０】
ＩＰＣノード群がその構成要求をＩＰＣサーバに送ると、そのＩＰＣノード群は認証される。これがなされるのは、電源投入の際か、ネットワークへのそのＩＰＣノードの「ホットプラグ」の際である。このＩＰＣノードはそのノードタイプによって自身を識別する。このネットワークには複製のＩＰＣノードタイプはないものとする。このネットワークに既に存在するタイプの別のＩＰＣノードがネットワークに加わる場合、サーバは拒絶の表示をそのノードに送らなければならない。
【００４１】
図８には、本発明のある実施形態に係る、あるコンポーネントとそのＩＰＣセッションマネージャとの間での、一般的な宛先ＩＤ検出シーケンス中のイベント群のシーケンスが示されている。工程８０２では、このコンポーネントがそのソースＩＤ（宛先ＩＤは送らない）と、宛先ＢＰ又はＡＰのタイプと、ヘッダとデータとを含むＩＰＣデータとを送る。工程８０４では、このＩＰＣセッションマネージャがＩＰＣデータのヘッダのオペコードと宛先ＢＰ又はＡＰのタイプとを調べ、これによって、対応する動的なルーティングテーブルを捜して正しい宛先アドレスを見つける。工程８０６では、このＩＰＣセッションマネージャがそのコンポーネントのＩＰＣアドレスを書き込みそれをデバイス層まで送る。メッセージのブロードキャストが必要な場合、このＩＰＣアドレスの宛先フィールドを０ｘＦＦに設定する。
【００４２】
図９には、ＩＰＣコンポーネントの初期化の間になされる典型的な工程が示されている。図９に示されているＩＰＣサーバによってＢＰが構成され次第、ＢＰはコンポーネント９０２などのコンポーネント群を異なるサービス群に加入させる。工程９０４でコンポーネント群が自身でオーディオやビデオなどの機能に加入できる。次にこのコンポーネント加入情報が、コンポーネントＩＤ作成の為に（ＩＤがまだ割り当てられていない場合）、そして特定のＩＰＣアドレスの動的なルーティングテーブルの作成又は更新の為に、ＩＰＣセッションマネージャに送られる（工程９０６）。工程９０８では、このセッションマネージャが工程９０６の情報によってＩＰＣサーバを更新する。工程９１２でこのＩＰＣサーバにより動的なルーティングテーブルの確認がＩＰＣクライアントに送られる。このサーバが通告され次第、工程９１０で新しい動的なルーティングテーブルの更新が参加するプロセッサ全てにブロードキャストされる。
【００４３】
同様のコンポーネントの初期化プロセスが、図１０では、コンポーネント（クライアント）１００２と、クライアントセッションマネージャとも言うセッション（クライアント）１００４と、サーバセッションマネージャとも言うセッション（サーバ）１００６との間で示されている。工程１００８でコンポーネント（クライアント）１００２によりコンポーネントの構成要求が送られる。更にクライアントセッションマネージャ１００４がコンポーネントＩＤを割り当て新しいオペコードのリストをその動的なルーティングテーブルに追加する（図示せず）。工程１０１０では、クライアントセッションマネージャ１００４が、コンポーネントＩＤを含む構成返答を送る。この構成返答に応えて、コンポーネント（クライアント）１００２がそのＩＤをクライアントのセッションマネージャ１００４から受信する。
【００４４】
工程１００８の構成要求にクライアントセッションマネージャ１００４が工程１０１０で返答し次第、工程１０１２でクライアントセッションマネージャ１００４はセッションサーバ１００６に構成更新要求を送る。構成更新要求のパラメータ群は、動的なルーティングテーブルでなされた任意の新しい変更である。そのＩＰＣアドレスの動的なルーティングテーブルをセッションマネージャが更新する。それから工程１０１６でこのサーバセッションマネージャ１００６が全ＩＰＣクライアントに構成更新を送り、同時に工程１０１４でＩＰＣクライアントに構成更新表示も送る。サーバのセッションマネージャ１００６は、ＩＰＣサーバがそのルーティングテーブルを送られた変更により更新したことを確かめる。
【００４５】
動的なルーティングテーブル群をパラメータ（単数又は複数）として含む工程１０１６の構成更新メッセージでは、セッションサーバ１００６は動的なルーティングテーブル群を更新し、工程１０１８で構成更新確認メッセージを送る。その後このセッションサーバ１００６は、ＩＰＣ参加者の全てが更新されたことを確かめる。
【００４６】
このＩＰＣセッションマネージャが発信ＩＰＣパケット群及び着信のＩＰＣパケット群のルーティングパスを決定する。発信パケットのルートはコンポーネントのＩＰＣアドレスにより決定される。その宛先アドレスがローカルプロセッサのものであることが判明した場合、ＩＰＣからオペレーティングシステム（ＯＳ）へのマッピングがこのセッションマネージャの内部で実行される。その宛先アドレスがあるローカルＩＰＣクライアント用のものであることが判明した場合、このパケットはその後の処理（例えば、カプセル化）に向けＩＰＣスタックに送られる。ここで留意すべきは、そのＩＰＣパケットを送るコンポーネントと同一のプロセッサに宛先コンポーネントが設置されている場合、カプセル化は不要でありそのパケットは通常のＯＳのメッセージ呼び出し（例えば、マイクロソフトメッセージキュー等）により引き渡されることである。このようにコンポーネント群は自身のメッセージ入力方式の修正のことを考えなくてよい。コンポーネント群は自身のメッセージ記入方法論をＯＳに特有の設計の代わりにＩＰＣの呼び出しに変更するだけでよく、このＩＰＣの呼び出しはこの実施形態で指定したＯＳの層で抽出されつくす。
【００４７】
着信パケット群については、メッセージの宛先アドレスがＩＰＣサーバのものに等しくない場合、この着信パケット群はルータにより適正なＩＰＣクライアントへとルーティングされる。着信パケット群のルーティングはＩＰＣノードのルータマネージャにより処理される。他の場合には、このメッセージは、コンポーネントの宛先ＩＤが有効なコンポーネントＩＤ又は０ｘＦＦに設定されているかどうかに依存して正当な単数又は複数のコンポーネントに回送される。
【００４８】
このＩＰＣルータのブロックはＩＰＣデータを宛先コンポーネントに移送する。着信ＩＰＣメッセージ群が、中でも、オーディオやモデム等のものなどの発信者のコンポーネントＩＤとＩＰＣメッセージオペコード群とを持っている。ＩＰＣセッションマネージャはそのコンポーネントルーティングテーブルに頼ってＩＰＣデータを正当なコンポーネント（単数又は複数）に送る。この動的なルーティングテーブル及びコンポーネントルーティングテーブルの両方がＩＰＣサーバ／クライアントによって更新される。
【００４９】
電源投入の間、各コンポーネントが、ＩＰＣコンポーネントＩＤを得る為に自身をそのセッションマネージャに登録している必要がある。加えて、各コンポーネントは、オーディオやモデムなどの着信ＩＰＣメッセージ群に加入している必要もある。この情報は、ＩＰＣセッションマネージャにより使用できるよう、コンポーネントルーティングテーブル及び動的なルーティングテーブルに保存されている。
【００５０】
図１１に示されているように、コンポーネント１１０２が、工程１１０４に見られるようにそのデータ要求をＩＰＣセッションマネージャに送り、宛先ＩＰＣノード（例えばＢＰ）にある検査がなされる。このＩＰＣノードがＩＰＣメッセージオペコードをサポートしない場合、このコンポーネント１１０２にエラー応答が戻される。このエラー応答に加えて、ＩＰＣセッションマネージャは、その特定のオペコードを受信する能力があるＩＰＣノード全ての更新を返す。このメッセージをＩＰＣセッションマネージャがどのＩＰＣノード（単数又は複数）にリダイレクトするかの決定は、このコンポーネントにかかっている。この宛先コンポーネントがＩＰＣネットワークに設置されているがローカルプロセッサには設置されていないことをこのセッションマネージャが判断した場合、このデータがＩＰＣネットワークに送られる前に、このデータをＩＰＣセッションマネージャ１１０６はまずＩＰＣヘッダ情報によってカプセル化する。
【００５１】
ＩＰＣコンポーネント群は、ＩＰＣプロトコルのスタックを用いて一緒に通信するスレッド群又はタスク群である。同一のコアに備わっているコンポーネント群には、他のローカルコンポーネント群との通信用のＩＰＣのＡＰＩを迂回するという選択肢があるが、望ましくはない。ここで意図していることは、そのコンポーネントのソフトウェアを、そのコンポーネントの物理的な場所及び基礎をなしているＯＳから独立した状態に保持することである。ＩＰＣスタックとのコンポーネントのインタフェースは、サーバとクライアントとで違いはない。
ＩＰＣスタックを介したコンポーネントの通信
コンポーネント群は相互通信／内部通信メッセージングの標準的なＡＰＩ呼び出しを使用する。このＡＰＩ呼び出し群は、ひとつのＯＳのプラットフォームから次のものに変わらない。これにより、コンポーネントがどこで動いているかに関わらず、データメッセージ群の移送に対処するコンポーネントソフトウェアを同じ状態のままにしておける。加えて、コンポーネント群は、ＩＰＣセッションマネージャへのサービス呼を介して、要求しているサービス群の中に局所的に存在するもの又はＩＰＣリンクを必要とするものがあるかどうかを検出できる。宛先コンポーネントが局所的に備わっている場合には、ＩＰＣセッションマネージャが、送信用のデバイス層にデータを回送することなく、このメッセージを正当なコンポーネントに回送する。
ＩＰＣコンポーネントＩＤの割り当て
何らかのＩＰＣ通信への参加を希望しているコンポーネントは全て、こういった動作を、まず自身をＩＰＣスタックと一体となるよう構成することによって行わなければならない。ノードのセッションマネージャはコンポーネント群を認証しそのコンポーネント群にＣＩＤを割り当てる。各コンポーネントはＣＩＤを２つ以上持つことはできない。コンポーネント群がＩＰＣノードからアンインストールされた場合には、コンポーネント群のＣＩＤは除去されなくてはならずＩＰＣネットワークに通告する必要がある。適切な除去のコマンドをＩＰＣセッションマネージャに送るのは、アンインストーラ又は同等のソフトウェアの担当である。一般的な使用の場合には、コンポーネント群が、ＩＰＣメッセージを送るのに自身の目標のコンポーネントのＣＩＤを知らなくてもよい。このコンポーネント群からのルーティング抽出を管理するのは、ＩＰＣソフトウェアの担当である。場合によっては受信したＩＰＣメッセージに返答するようなコンポーネント群は、ソースＣＩＤを目標にすることで返事をリダイレクトする。この場合はその目標のノードがメッセージをその特殊なコンポーネントに回送し、加入しているコンポーネント全てには回送しない。コンポーネント群のＣＩＤはそのノード内で固有でありノード同士間では固有ではない。
論理的なＩＰＣチャネル配分
コンポーネント群はＩＰＣネットワークで通信するのに論理チャネル群を用いる。論理チャネル群は、各コンポーネントから要求されたＱｏＳに基づいてデバイス層により割り当てられる。コンポーネント群には多数の論理チャネルが割り当てられる。本発明のある実施形態に従って、チャネルには専用と非専用の２つのタイプがある。コンポーネント群がチャネルのタイプを選ぶ。専用のチャネル群は、そのコンポーネントがそのチャネルを使用するときいつもコンポーネントのＱｏＳが使用可能であることを保証する。異なるＱｏＳのチャネルが２つ以上コンポーネント群に与えられる可能性があるので、ＩＰＣの帯域幅がなくなる恐れがある。
【００５２】
コンポーネント群にこの通信リソース群を共有させ続ける為に、デバイス層が非専用のチャネル群を随意選択で提供する。非専用のチャネルのＱｏＳは、その帯域幅が使用可能な場合には保証され、他の場合には合計のロードに依存してＱｏＳは低下する。多数のノードに亘るＱｏＳを専用のチャネル又は非専用のチャネルに付与することができる。
専用チャネルと非専用のチャネル
専用のチャネル群はコンポーネントから要求されたＱｏＳを保証する。そのチャネルが解放されていない限り、そのチャネルのＱｏＳは履行される。非専用のチャネル群はＱｏＳを保証できないが、余分の帯域幅が使用可能になったときデータを送ろうと連続的に試みる。非専用のチャネル群には予想可能なリアルタイムの性能はないが、非同期の、低帯域幅のデータの為に使用できる。コンポーネント群は、２つ以上のチャネルを要求することにより、異なるＱｏＳを同時に確保できる。コンポーネント群は、自身のチャネル群を解放すると決めるまで、自身のチャネル群を保持する。しかし、優先権の高いほかのものによりスタックが供給されて、ある専用のチャネルについてのあるコンポーネントの特権が除去される。この場合は、あるチャネルを所有しているコンポーネント群が通告され、そのチャネルを解放するかそのコンポーネント群のチャネルを非専用のモードへと変えるよう求められる。
ＱｏＳの割り当て及びコンポーネントの優先権
コンポーネント群が論理チャネル群をあるＱｏＳに基づいて要求する。ＱｏＳの定義はデータ速度である。ＱｏＳがそのコンポーネントにより指定されデバイス層と交渉される。加えて、コンポーネント群が登録及び認証のプロセスの間に優先権を割り当てられる。この優先権はＩＰＣセッションマネージャに用いられ、コンポーネントの特権が、特権の程度の低いコンポーネント群のチャネル群とサービス群とを無効にし要求する際に検証される。
ＩＰＣコンポーネントの加入リスト
ＩＰＣスタックとのコンポーネントの登録の一部は構成要求である。あるコンポーネントが認証されたとき、そのコンポーネントはセッションマネージャからあるＣＩＤを受信する。ここで、このコンポーネントは、異なるＩＰＣオペコードに加入することにより自身をＩＰＣスタックと一体となるよう構成する場合がある。このコンポーネントは、対象となっているオペコード群を選びそのオペコード群をセッション層に登録する。コンポーネントが、別の構成要求をセッションマネージャに送ることにより、自身のオペコードのリストへの加入をやめることを決めたり変更したりしてもよい。
【００５３】
図１２には、ＩＰＣスタックとの典型的なコンポーネントの通信が示されている。示されているのは、あるコンポーネントとＩＰＣスタックとの間の典型的な登録要求と構成要求と論理チャネル要求である。
【００５４】
本発明のある実施形態に係る典型的なＩＰＣデータ要求が図１３に示されている。工程１３０２では、コンポーネントが更新要求を送る。コンポーネント更新パラメータには、好ましくはノードタイプとオペコードとが含まれる。このコンポーネントがその宛先オペコードをサポートするノードタイプ群を検索する。このノードタイプが０ｘＦＦに等しい場合、セッションマネージャはまず、このコンポーネントの情報をＩＰＣ参加者全員のノードテーブル全てに送る。このオペコードフィールドが０ｘＦＦに等しい場合、セッションマネージャはまず、このコンポーネントを指定のノードタイプに属するオペコードリストに送る。一方、オペコードが特殊な値を持っている場合、セッションマネージャはまず、このコンポーネントに、ノードタイプがその特定のオペコードをサポートするかサポートしないかに対応した真の値又は偽の値を送る。
【００５５】
工程１３０４では、このコンポーネントにコンポーネント更新表示が送られる。このノードタイプが０ｘＦＦに等しい場合、ノードテーブル群はコンポーネントに戻される。このオペコードフィールドが０ｘＦＦに等しい場合、オペコードのリストはコンポーネントに戻される。しかし、このオペコードが特殊な値の場合、真のメッセージ又は偽のメッセージが返される。工程１３０６では、コンポーネントデータ要求がなされる。このコンポーネントデータ要求のパラメータには、ノードタイプ、ＩＰＣメッセージオペコード、ＩＰＣメッセージデータ、チャネルＩＤ、コンポーネントＩＤなどがある。コンポーネントデータ要求では、セッションマネージャはノードタイプを検査してこのオペコードがサポートされているかどうかを判断する。ノードタイプがこのオペコードをサポートしていない場合、工程１３０８でコンポーネント更新表示が送られる。しかし、ノードタイプがこのオペコードをサポートしている場合、工程１３１０でデータ要求がデバイス層に送られる。このデータ要求パラメータには、ＩＰＣメッセージ、チャネルＩＤ、ＩＰＣヘッダなどがある。
【００５６】
デバイス層はこのデータ要求メッセージをチャネルＩＤに基づいて送ることになっている。デバイス層はＩＰＣハードウェアをポートのヘッダ情報に基づいて選択する。データがコミットされ次第、１３１２でデータ確認メッセージがセッションマネージャに送られる。工程１３１４では、セッションマネージャはまずコンポーネントにコンポーネントデータ確認メッセージを送る。このコンポーネントは、更に多くのＩＰＣメッセージを送る前にこの確認を待つことも可能である。このコンポーネントは、データ確認が受信され次第、続けて次のＩＰＣメッセージを送ることも可能である。
【００５７】
工程１３１６では、デバイス層が、ＩＰＣメッセージデータやＩＰＣヘッダなどを含むデータ表示メッセージを送る。ルータマネージャはこのメッセージの宛先ＩＰＣヘッダを検査し、ローカルＩＰＣアドレスと異なる場合、マネージャはこのメッセージを正当なＩＰＣノードに送る（ルーティングする）。工程１３１０では、セッションマネージャは確保したチャネルＩＤと共にデータ要求をルータ層に送る。セッションマネージャは宛先コンポーネントＩＤを検査し、これが０ｘＦＦに等しい場合、このメッセージを、このオペコードに加入しているコンポーネント全てにルーティングする。工程１３１８では、セッションマネージャはコンポーネントデータ表示メッセージを送りコンポーネントはＩＰＣデータを受信する。
【００５８】
このＩＰＣスタックは、確保した制御チャネルを全ての参加するＩＰＣノードの間で通信する為に使用する。電源投入時に、ＩＰＣサーバのセッションマネージャは、このリンクを使用してメッセージ群をＩＰＣクライアント群にブロードキャストし、また逆の場合も同様である。通常操作の間、この制御チャネルを使用してあらゆるＡＰ及びＢＰの間で制御情報が運ばれる。
【００５９】
図１４には、ＩＰＣスタックとＩＰＣハードウェアとの間に設置された制御チャネル１４０２〜１４０６が示されている。異なるＩＰＣハードウェア間でデータを送る際に、データパケット群１４１０と共に制御チャネル情報１４０８も送信される。そのＩＰＣ制御チャネルによってあるＩＰＣクライアントが最初に自身の構成要求をブロードキャストする。そのブロードキャストをＩＰＣサーバが受信しそのクライアントへのＩＰＣアドレスで応じる。このＩＰＣアドレスはその特定のプロセッサ（ＡＰ又はＢＰ）の動的なルーティングテーブルに関連付けられる。
ＩＰＣのＡＰＩ（ＡＰＰＬＩＣＡＴＩＯＮ ＰＲＯＧＲＡＭ ＩＮＴＥＲＦＡＣＥ）
以下に、本発明のＩＰＣプロトコルの為の高いレベルのＡＰＩを幾つかリストアップする。各々が定義された一組のＡＰＩの呼び出しを持つ。
１）コンポーネント／セッションの高いレベルのＡＰＩ
コンポーネントの登録及び認証
これは、コンポーネント群とそのローカルセッションマネージャとの間の登録及び認証のプロセスである。
コンポーネントの構成及び管理
これは、コンポーネントのローカルセッションマネージャによるコンポーネントの構成のプロセスである。
コンポーネントチャネルの管理
これは、データを他のＩＰＣノード群に送る為に論理チャネルを取得するプロセスである。
コンポーネントデータの管理
インバウンドＩＰＣデータ及びアウトバウンドＩＰＣデータに加えフロー制御もここで処理される。
コンポーネントルーティングのサービス
ＩＰＣパケット群のコンポーネントルーティングの複雑な部分がここで処理される。
２）デバイス／ルータのインタフェースの高いレベルのＡＰＩ
ＩＰＣパケットのルーティング
ＩＰＣパケット群のルーティングがここで処理される。
チャネル帯域幅の管理
論理チャネル／物理チャネルの管理がここで処理される。
ハードウェアポートのハードウェア検出
ＩＰＣリンクのハードウェア検出がここで処理される。
ＩＰＣ物理チャネル管理
アドレス割り当てがここで処理される。
【００６０】
図１５には、無線通信装置（例えば携帯電話等）などの電子デバイス１５００のブロック図が示されており、この電子デバイス１５００には、あるＩＰＣネットワークを用いて互いに通信しているベースバンドプロセッサ（ＢＰ）１５０２とアプリケーションプロセッサ（ＡＰ）１５０４とがある。本発明のＩＰＣプロトコルは、通信装置などのシステムの多数のプロセッサ同士間の通信を提供する。このＩＰＣは、移動通信応用（ＭＡ）クライアント（例えば、ｉＤＥＮ（登録商標）ＷＬＡＮ）をパーソナル通信システム（ＰＣＳ）応用などのＭＡサーバに登録させ、それぞれが自身のＭＡの中ではそれに依存しているソフトウェアアーキテクチャやオペレーティングシステムやハードウェアなどのうち、どれにおいても、いかなる制限も受けずに２つのＭＡが自由に通信できる手段を提供する。
【００６１】
このＩＰＣプロトコルにより、任意のＩＰＣ適合のＭＡが通信の為にＩＰＣリンクに動的に追加可能になる。よって、コンパイル時又はその他のソフトウェアの前提に全く依存せずにＩＰＣネットワークが形成される。本発明のＩＰＣは、ＩＰＣスタックと通信する為の標準的な方法をソフトウェアコンポーネント群に呈示し、そのスタックの下のハードウェアも抽出されるので、コンポーネント群が通信する為に異なるリンクを選べる。
【００６２】
ここで図１６を参照すると、ソフトウェアスレッド１６０２、１６０４、１６０６などの３つのコンポーネントと、このコンポーネント群がアウトバウンドストリーミングをどのように確立するかが示されている。ソフトウェアスレッド１６０２は、例えば、所定のＱｏＳ１６０８の要求１６１２を送り、自身のオペコード加入リスト１６１０を提出する。代わりに、メッセージ１６１８に応え、ソフトウェアスレッド１６０２はチャネルＩＤ１６１４とコンポーネントＩＤ１６１６とを割り当てられる。本発明のある実施形態に係るソフトウェアスレッド１６０２、１６０４、１６０６などのコンポーネントが、各自の要求に依存してＩＰＣハードウェアリソース群を割り当てられる。このコンポーネント１６０２、１６０４、１６０６は、このシステム要求に依存して動的にインストール又はアンインストール可能である。
【００６３】
図１７では、コンポーネント１６０２、１６０４、１６０６が、各自の割り当てられたチャネル、例えばソフトウェアスレッド１６０２ならチャネル１７０２などでＩＰＣデータを送る。このコンポーネント１６０２、１６０４、１６０６は各自のデータを目標のＩＰＣノードと共に提出し、ノードが指定されていないときはコンポーネント群が更に各自のメッセージを全てのＩＰＣノードにブロードキャストする。このコンポーネント１６０２、１６０４、１６０６は、宛先コンポーネント群のＩＤも、その関連付けられたチャネル群も、そのＩＰＣアドレスも知らなくてよい。インバウンドストリーミングに関しては、メッセージオペコード群がコンポーネント群を識別する。例えば、図１８では、コンポーネント１６０２、１６０４、１６０６がメッセージオペコード群により識別される。先に述べられたコンポーネントルーティングテーブルを介してコンポーネントＩＤ群が検出される。ＩＰＣセッションマネージャは、そのメッセージのＩＰＣオペコードに加入済みのコンポーネント全てに着信データをルーティングする。
ＩＰＣポート群の動的な専用化
改善されたオーバーヘッド効率を提供しシステムの待ち時間を低減させる為に、本発明に係るＩＰＣプロトコル／ネットワークがＩＰＣネットワーク内でのポート群の動的な専用化を提供する。例えば、クライアントのプロセッサが音声のサンプル又は他のリアルタイムデータなどの大量のデータを送信する必要があるとき、本発明に従い、クライアント及びサーバは一つ以上のサーバのポート／クライアントのポートの専用化を交渉する。
【００６４】
図１９にはＩＰＣネットワークが示されており、このＩＰＣネットワークには、サーバ１９０２と、このサーバ１９０２に結合された第１のクライアント（クライアント２）１９０４と第２のクライアント（クライアント３）１９０６と第３のクライアント（クライアント４）１９０８とがある。第１のクライアント１９０４は、自身に結合された２つのサブクライアント、即ちクライアント（２．１）１９１０とクライアント（２．２）１９１２とを持っており、第２のクライアント１９０６は、自身に結合された１つのサブクライアント、即ちクライアント（３．１）１９１４を持っている。第３のクライアント（クライアント４）１９０８は、自身に結合されたカメラ１９１６を持っている。図１９に示されているネットワークについて述べると、互いに直接的に結合されたノードをピアＩＰＣノードと呼び、例えば、クライアント２〜４（１９０４〜１９０８）はサーバ１９０２のピアノードであり、クライアント２．１及び２．２（１９１０〜１９１２）はクライアント２（１９０４）のピアＩＰＣノードである。あるＩＰＣピアノードがある一定のノードより高いレベルでも低いレベルでもよく、例えば、サーバ１９０２はクライアント２（１９０４）のピアＩＰＣノードであり、同時に、低いレベルのサブクライアント２．１及び２．２（１９１０〜１９１２）もクライアント２（１９０４）のピアＩＰＣノードである。
【００６５】
クライアント１９０４〜１９１４の各々はある範囲のアドレス群を割り当てられ、このクライアントの各々は、その範囲の他に、フローチャートに示されているように自身のポートアドレスとしてＩＰＣアドレスを手に入れる。サーバ１９０２は自身が持っているハードウェアポートの総数に亘って全ての使用可能なＩＰＣアドレスを分けるが、サーバ１９０２は自身の為にアドレス「２５４」を確保し、メッセージ群をＩＰＣネットワークに亘りブロードキャストする為にアドレス「０ｘＦＦ」が確保される。
【００６６】
この説明用の実例では、サーバは８つのポートを持っているので、２５６（この例でのアドレスの総数）を８で除算しポート毎に３２のアドレスが得られるものとする。よって第１のクライアント１９０４にアドレス０〜３１が割り当てられ、第２のクライアント１９０６にアドレス３２〜６４が割り当てられる。サブクライアント１９１０〜１９１４を持つクライアント１９０４及び１９０６の各々は、図２１に示されている続きのポート列挙フローチャートに更に示されているように、更に自身に割り当てられているＩＰＣアドレスをそれぞれのサブクライアント群に細分する。
【００６７】
クライアント１９０４〜１９１４の各々はそれぞれ、ＩＰＣアドレス対ハードウェアポートのマッピング情報を含む自身のネットワークルーティングテーブルを埋める。図１９に示されているカメラ１９１６がハードウェアＡＰＩ層（ＨＡＬ）を介してインタフェース接続しているので、このカメラ１９１６にはＰＣポートを割り当てない。このカメラ１９１６はコンポーネントに直接的にインタフェース接続する。そのコンポーネントはこのカメラのインタフェースに関するオペコード群を回送又は受信する。
【００６８】
図２２には、サーバ１９０２のネットワークルーティングテーブルが示されている。この特定の説明用の実例では、サーバのポート１がアドレス０〜３１に関連しており、第１のクライアント１９０４（アドレス３１を持つ）に結合されており、サーバの第２のポートがアドレス３２〜６４に関連しており、第２のクライアント１９０６（アドレス６４）と関連している、といったようになる。クライアント及びサブクライアント１９０４〜１９１４の各々は更に、各自のポート対ＩＰＣアドレスに関連している同様のネットワークルーティングテーブルを持っている。
【００６９】
本発明に従い、サブクライアント（２．１）１９１０が、音声のサンプルなどの情報を、音声のサンプルを復号できる第２のクライアント（クライアント３）１９０６に送信する為に専用のパスを必要とする場合、サブクライアント（２．１）１９１０はＩＰＣネットワークを介して第１のクライアント（クライアント２）１９０４にメッセージを送る。このメッセージは、ノードタイプや必要なＱｏＳを含む。クライアント１９０４は、そのＱｏＳをクライアント１９０４がサポートできる場合、サブクライアント１９１０に結合されたポートを専用化する。クライアント１９０４はメッセージを前述のノードタイプ及びＱｏＳ要求と共にサーバ１９０２に回送する。サーバ１９０２は、その要求をサーバ１９０２がサポートできると判断した場合、サーバ１９０２のポート１及び２の両方を専用化する。それからサーバ１９０２は、そのノードタイプやＱｏＳ情報を含んだメッセージをクライアント１９０６に送る。更にまた、クライアント１９０６がその要求をサポートできる場合、クライアント１９０６は自身のポートをその要求の専用にする。ここで、サブクライアント１９１０はクライアント１９０６までずっと続く専用のパスを手に入れた。リンクを確立しなくてはならない、各ＩＰＣノードのルータ層は、このリンクの次のノードに必要なＱｏＳに基づいてチャネル群の確保を処理する。ルータ層は、デバイス層にチャネルを要求することにより、適切なチャネルを要求し確保しなくてはならない。
【００７０】
ここで図２３を参照すると、サーバ１９０２のポート専用化テーブル２３００が示されている。このポート専用化テーブル２３００はＩＰＣスタックのルータ層に保存されており、サーバのポートの各々をリンクさせ専用の状況又は非専用の状況にする。特定のポート（単数又は複数）が専用化されている場合、サーバ１９０２がその専用化の解除を望む場合（例えば、一つ以上の専用のポートを必要とするもっと優先権の高い要求が入ってきた場合）を除いては、サーバ１９０２はこのポート群を他のタスクには割り当てない。クライアント１９０４〜１９０８とサブクライアント１９１０〜１９１４の各々は、自身のポートと、自身のポートの各々の現在の専用化の状況とに関連するポート専用化テーブルを持つ。
【００７１】
この確保のプロセスは、所望の動作モード毎に違うやり方を選択して実施できる。実例として、ノードのクライアント２．１から２へのパスを、必要なＱｏＳにより専用化することができる場合、ルータはテーブルのポートを専用化する。ネクストホップ要求がリンク内の次のＩＰＣノードに行く。この場合は、ノード２．１はクライアント３に向かうパスの次のリンクを専用化しようとする。クライアント２とクライアント１とがそのリンクを現時点で専用化できない場合には、当面のあいだ待つ為にタイマを始動することができる。タイマの満了時に、本来の要求側にメッセージが送られ、既に確立されたリンクが任意選択で中止されるか、クライアント２とクライアント３との間のタイマが更に延長される。このリンクが無事に確立された場合、ＯＫステータスメッセージが送り返されて、本来の要求していたコンポーネント（単数又は複数）は通告される。
【００７２】
サブクライアント１９１０、クライアント１９０４、サーバ１９０２、クライアント１９０６のそれぞれに専用のルータ層毎に、サブクライアント（クライアント２．１）１９１０はクライアント（クライアント３）１９０６への専用のパスを持っている。これにより、このパスが専用化され次第、パケット群の転送の際にヘッダ情報を含まなくてよいので、データ転送を簡略化しオーバーヘッドを少なくすることができる。
【００７３】
図２４には、コンポーネントチャネル要求シーケンスが示されており、これには、コンポーネントチャネル要求に加え、セッション層からルータ層へのチャネル要求、デバイスからセッション層へのチャネル返答、コンポーネントチャネル返答が含まれる。送信された変数（例えば、ノードＩＤやＱｏＳ等）の全てが示されている。図２５には、チャネル返答やピアツーピア要求が含まれるルータ層のチャネル要求が示されており、ピアツーピア要求には、次のルータ層とのエンドツーエンドのパスでの通信が含まれ、このエンドツーエンドのパスは専用でなくてはならない。更に示されているのは、ピアツーピアタイムアウト要求であり、これは、パスに沿ったデバイス層の一つがチャネルを所定の期間内に配分できない場合、前もって確保されたチャネル全てを含むリンクを解消させる。このルータ層のチャネル要求は、専用である通信パスのリンク毎に（このパスのＩＰＣクライアント／サーバ毎に）繰り返される。
【００７４】
本発明の好適な実施形態が図示され記載されたが、本発明はそのように制限されてはいないことが明白である。当業者は、添付の請求項により規定された本発明から逸脱することなく、非常に多くの、修正、変更、変形、代用、同等物を考え付くであろう。
【図面の簡単な説明】
【００７５】
【図１】本発明のある実施形態に係るＩＰＣネットワークの図。
【図２】本発明のある実施形態に係るＩＰＣスタック。
【図３】本発明のある実施形態に係るＩＰＣコンポーネントのＩＰＣ割り当て。
【図４】本発明のある実施形態に係る主要なＩＰＣテーブル群。
【図５】本発明のある実施形態に係るチャネル配分を示す図。
【図６】本発明のある実施形態に係るＩＰＣクライアントの初期化ルーチンの間に伴う工程を強調表示する図。
【図７】本発明のある実施形態に係るＩＰＣクライアントの初期化の間に伴う工程を強調表示する別の図。
【図８】本発明のある実施形態に係るＩＰＣカプセル化の第１のレベルを強調表示する図。
【図９】本発明のある実施形態に係るＩＰＣコンポーネントの初期化の間になされる工程を強調表示する図。
【図１０】本発明のある実施形態に係るコンポーネントの初期化の間になされる工程を強調表示するチャート。
【図１１】本発明のある実施形態に係るＩＰＣクライアントとＩＰＣサーバとの間のＩＰＣデータの転送。
【図１２】本発明のある実施形態に係るＩＰＣデータのヘッダの図。
【図１３】本発明のある実施形態に係るＩＰＣデータ要求の間になされる工程の図。
【図１４】本発明のある実施形態に係るＩＰＣネットワーク。
【図１５】本発明のある実施形態に係る無線通信装置などの電子デバイス。
【図１６】本発明のある実施形態に係るアウトバウンドストリーミングの図。
【図１７】本発明のある実施形態に係るアウトバウンドストリーミングの図。
【図１８】本発明のある実施形態に係るインバウンドストリーミングの図。
【図１９】本発明のある実施形態に係るＩＰＣシステムの図。
【図２０】本発明のある実施形態に係る図１９に示されているシステムのハードウェアポート列挙フローチャート。
【図２１】図２０のハードウェアポート列挙フローチャートの続き。
【図２２】本発明のある実施形態に係るネットワークルーティングテーブル。
【図２３】本発明のある実施形態に係るポート専用化テーブル。
【図２４】本発明のある実施形態に係るコンポーネントチャネル要求シーケンス。
【図２５】本発明のある実施形態に係るピアツーピアのルータチャネル要求シーケンス。
【特許請求の範囲】
【請求項１】
ＩＰＣサーバと、
同ＩＰＣサーバに結合された一つ以上のＩＰＣクライアントと、からなり、
同ＩＰＣサーバはポート専用化テーブルを含む、プロセッサ間通信（ＩＰＣ）ネットワーク。
【請求項２】
前記ＩＰＣサーバが一つ以上のポートを含み、前記ポート専用化テーブルが、専用化されている前記一つ以上のポートを常時監視している請求項１に記載のＩＰＣネットワーク。
【請求項３】
前記一つ以上のＩＰＣクライアントがそれぞれ更に、前記ＩＰＣサーバのポートの各々にどのアドレスが割り当てられているかを示すネットワークルーティングテーブルを含む請求項２に記載のＩＰＣネットワーク。
【請求項４】
前記一つ以上のＩＰＣクライアントのうち一つ又は前記ＩＰＣサーバが、ピアＩＰＣノードである一つ以上のＩＰＣクライアントのうち一つからポート専用化メッセージを受信すると、前記ポート専用化メッセージを送ってきた前記ＩＰＣクライアントに、専用化に使用可能なポートを前記ＩＰＣサーバが持っているかどうかを通知する請求項３に記載のＩＰＣネットワーク。
【請求項５】
ピアＩＰＣノードである前記一つ以上のＩＰＣクライアントのうち一つ又は前記ＩＰＣサーバが更に、前記ポート専用化メッセージを送ってきた前記ＩＰＣクライアントに、前記ＩＰＣサーバが持っている使用可能な前記ポート（単数又は複数）についての情報を通知する請求項４に記載のＩＰＣネットワーク。
【請求項６】
前記一つ以上のＩＰＣクライアントの各々がポート専用化テーブルを持っている請求項２に記載のＩＰＣネットワーク。
【請求項７】
前記一つ以上のＩＰＣクライアントの各々にある前記ポート専用化テーブルの各々が、前記ＩＰＣクライアント自身のポート（単数又は複数）についての情報を含んでいる請求項６に記載のＩＰＣネットワーク。
【請求項８】
ＩＰＣサーバとＩＰＣクライアントとを持つＩＰＣネットワークのポートを専用化する方法であって、ＩＰＣサーバとＩＰＣクライアントとがそれぞれのポート専用化テーブルを持ち、
（ａ）前記ＩＰＣクライアントから前記ＩＰＣサーバに、ポート専用化メッセージを送信する工程と、
（ｂ）前記ＩＰＣサーバから前記ＩＰＣクライアントに、前記ＩＰＣサーバが持っている使用可能なポートについて前記ＩＰＣクライアントに通知する情報メッセージを戻す工程と、
（ｃ）前記ＩＰＣクライアントから前記ＩＰＣサーバに、前記ＩＰＣクライアントが専用化を望むポートを選択するメッセージを送信する工程と、
（ｄ）前記ＩＰＣサーバから前記ＩＰＣクライアントに、前記要求されたポートが前記クライアントの使用の為に専用化されたことを前記クライアントに通知する所定のメッセージを送る工程と、を含む方法。
【請求項９】
工程（ｄ）に応えて、前記ＩＰＣクライアントが自身のポート専用化テーブルを更新する請求項８に記載の方法。
【請求項１０】
（ｅ）前記ＩＰＣサーバから、前記専用のポートを解消させるメッセージを送る工程を更に含む請求項８に記載の方法。
【請求項１１】
（ｅ）前記ＩＰＣクライアントから、前記専用のポートの解放を要求する所定のメッセージを送る工程を更に含む請求項８に記載の方法。
【請求項１２】
工程（ｄ）の後で、前記ＩＰＣサーバも自身のポート専用化テーブルを更新する請求項９に記載の方法。
【請求項１３】
工程（ｄ）で前記ポートが専用化され次第、前記所望のデータパスに沿った前記リンクの各々での他のチャネルのデータロードの総計に関わらず、前記専用のポートで送信されたデータがサービス品質（ＱｏＳ）を保証される請求項８に記載の方法。
【請求項１】
ＩＰＣサーバと、
同ＩＰＣサーバに結合された一つ以上のＩＰＣクライアントと、からなり、
同ＩＰＣサーバはポート専用化テーブルを含む、プロセッサ間通信（ＩＰＣ）ネットワーク。
【請求項２】
前記ＩＰＣサーバが一つ以上のポートを含み、前記ポート専用化テーブルが、専用化されている前記一つ以上のポートを常時監視している請求項１に記載のＩＰＣネットワーク。
【請求項３】
前記一つ以上のＩＰＣクライアントがそれぞれ更に、前記ＩＰＣサーバのポートの各々にどのアドレスが割り当てられているかを示すネットワークルーティングテーブルを含む請求項２に記載のＩＰＣネットワーク。
【請求項４】
前記一つ以上のＩＰＣクライアントのうち一つ又は前記ＩＰＣサーバが、ピアＩＰＣノードである一つ以上のＩＰＣクライアントのうち一つからポート専用化メッセージを受信すると、前記ポート専用化メッセージを送ってきた前記ＩＰＣクライアントに、専用化に使用可能なポートを前記ＩＰＣサーバが持っているかどうかを通知する請求項３に記載のＩＰＣネットワーク。
【請求項５】
ピアＩＰＣノードである前記一つ以上のＩＰＣクライアントのうち一つ又は前記ＩＰＣサーバが更に、前記ポート専用化メッセージを送ってきた前記ＩＰＣクライアントに、前記ＩＰＣサーバが持っている使用可能な前記ポート（単数又は複数）についての情報を通知する請求項４に記載のＩＰＣネットワーク。
【請求項６】
前記一つ以上のＩＰＣクライアントの各々がポート専用化テーブルを持っている請求項２に記載のＩＰＣネットワーク。
【請求項７】
前記一つ以上のＩＰＣクライアントの各々にある前記ポート専用化テーブルの各々が、前記ＩＰＣクライアント自身のポート（単数又は複数）についての情報を含んでいる請求項６に記載のＩＰＣネットワーク。
【請求項８】
ＩＰＣサーバとＩＰＣクライアントとを持つＩＰＣネットワークのポートを専用化する方法であって、ＩＰＣサーバとＩＰＣクライアントとがそれぞれのポート専用化テーブルを持ち、
（ａ）前記ＩＰＣクライアントから前記ＩＰＣサーバに、ポート専用化メッセージを送信する工程と、
（ｂ）前記ＩＰＣサーバから前記ＩＰＣクライアントに、前記ＩＰＣサーバが持っている使用可能なポートについて前記ＩＰＣクライアントに通知する情報メッセージを戻す工程と、
（ｃ）前記ＩＰＣクライアントから前記ＩＰＣサーバに、前記ＩＰＣクライアントが専用化を望むポートを選択するメッセージを送信する工程と、
（ｄ）前記ＩＰＣサーバから前記ＩＰＣクライアントに、前記要求されたポートが前記クライアントの使用の為に専用化されたことを前記クライアントに通知する所定のメッセージを送る工程と、を含む方法。
【請求項９】
工程（ｄ）に応えて、前記ＩＰＣクライアントが自身のポート専用化テーブルを更新する請求項８に記載の方法。
【請求項１０】
（ｅ）前記ＩＰＣサーバから、前記専用のポートを解消させるメッセージを送る工程を更に含む請求項８に記載の方法。
【請求項１１】
（ｅ）前記ＩＰＣクライアントから、前記専用のポートの解放を要求する所定のメッセージを送る工程を更に含む請求項８に記載の方法。
【請求項１２】
工程（ｄ）の後で、前記ＩＰＣサーバも自身のポート専用化テーブルを更新する請求項９に記載の方法。
【請求項１３】
工程（ｄ）で前記ポートが専用化され次第、前記所望のデータパスに沿った前記リンクの各々での他のチャネルのデータロードの総計に関わらず、前記専用のポートで送信されたデータがサービス品質（ＱｏＳ）を保証される請求項８に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公表番号】特表２００７−５２１５８４（Ｐ２００７−５２１５８４Ａ）
【公表日】平成１９年８月２日（２００７．８．２）
【国際特許分類】
【出願番号】特願２００６−５４７１５５（Ｐ２００６−５４７１５５）
【出願日】平成１６年１２月１６日（２００４．１２．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０４２４０２
【国際公開番号】ＷＯ２００５／０６２７８７
【国際公開日】平成１７年７月１４日（２００５．７．１４）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成１９年８月２日（２００７．８．２）
【国際特許分類】
【出願日】平成１６年１２月１６日（２００４．１２．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０４２４０２
【国際公開番号】ＷＯ２００５／０６２７８７
【国際公開日】平成１７年７月１４日（２００５．７．１４）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]