(57)【要約】第１及び第２機能ユニットの間でデータを交換する方法であって、第１ハンドシェイク手続きにおいて、データが第１機能ユニット（Ｉ）によって選択された通信スレッド（ＴＩＤ）に対応して交換されるステップと、これとは独立に、第２ハンドシェイク手続きにおいて、少なくとも１つの通信スレッドの状態に関する情報が、第２機能ユニット（Ｔ）から第１機能ユニット（Ｉ）に交換されるステップとを有する方法が記載されている。前記情報は、前記第１機能ユニット（Ｉ）が前記少なくとも１つの通信スレッドに関するデータを交換する可能性を予測することができるようにする。
2006525587.tif 000002
【特許請求の範囲】
【請求項１】
第１及び第２の機能ユニットの間でデータを交換する方法であって、
―  第１ハンドシェイク手続きにおいて、データが、前記第１機能ユニットによって選択された通信スレッドに対応して交換されるステップと、
―  これとは独立に、第２ハンドシェイク手続きにおいて、少なくとも１つの通信スレッドの状態に関連する情報が、前記第２機能ユニットから前記第１機能ユニットに交換されるステップと、
を有する方法において、前記情報は、前記第１機能ユニットが、前記少なくとも１つの通信スレッドに関するデータを交換する可能性を予測することができるようにすることを特徴とする方法。
【請求項２】
前記情報は、前記少なくとも１つの通信スレッドに関して確保されているバッファの充填度を示す、請求項１に記載の方法。
【請求項３】
前記情報は、前記少なくとも１つの通信スレッドに関する要求が取り扱われることができるまでの、期待される待ち時間を示している、請求項１に記載の方法。
【請求項４】
第１及び第２機能ユニットを有する処理システムであって、前記処理システムは、第１ハンドシェイク手続きにおいて、前記第１機能ユニットにより選択された通信スレッドに対応してデータを交換し、これとは独立に第２ハンドシェイク手続きにおいて、少なくとも１つの通信スレッドの状態に関する情報を前記第２機能ユニットから前記第１機能ユニットに交換する処理システムにおいて、前記情報は、前記第１機能ユニットが前記少なくとも１つの通信スレッドに関するデータを交換する可能性を予測することができるようにすることを特徴とする処理システム。
【請求項５】
ネットワーク内に複数の機能ユニットを有する請求項４に記載の処理システムであって、前記処理システムは、データと前記データに関する通信スレッド識別子とを、スプリットプロトコルに従って、第１機能ユニット及び第２機能ユニットを含む、ソース機能ユニットから宛先機能ユニットまで１つ以上の中間機能ユニットを介する通信経路に沿って伝送する処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、添付の請求項１の導入部に記載されているデータを伝送する方法に関する。
【０００２】
本発明は、更に、添付の請求項４の導入部に記載されている処理システムに関する。
【背景技術】
【０００３】
第１及び第２機能ユニットの間でデータを交換する方法であって、
―  第１ハンドシェイク手続きにおいて、データが、前記第１機能ユニット（Ｉ）によって選択される通信スレッド（ＴＩＤ）に対応して交換されるステップと、
―  これとは独立に、第２ハンドシェイク手続きにおいて、少なくとも１つの通信スレッドの状態に関する情報が、前記第２機能ユニット（Ｔ）から前記第１機能ユニット（Ｉ）に交換されるステップと、
を有する方法において、前記情報は、前記第１機能ユニット（Ｉ）が少なくとも１つの通信スレッドに関するデータを交換する可能性を予測できるようにすることを特徴とする方法。
【０００４】
データが第１機能ユニットから第２機能ユニットに交換される第１ハンドシェイクは、１つ以上の中間機能ユニットを介する前記ソース機能ユニットから宛先機能ユニットまでのデータ伝送のチェーンの一部であることができる。前記第１ハンドシェイクを開始する前記第１機能ユニットは、イニシエータ又はイニシエータ機能ユニットとも示される。前記第２機能ユニットは、ターゲット又はターゲット機能ユニットとも称される。
【０００５】
前記のようなデータ伝送のチェーンによって、メッセージは、前記ソース機能ユニットによって、宛先機能ユニットに送られることができる。前記メッセージは、命令、アドレス及び／又は他のデータを含み得る。前記宛先機能ユニットは、自身の順番の際に、前記ソース機能ユニットにメッセージを送っても良い。機能ユニットとは、データストリーム内に含まれているいかなるユニットでも良く、例えば、ＣＰＵ、ＤＳＰ若しくはＶＬＩＷのようなデータに演算を実施するユニット、メモリのようなデータを記憶するユニット、又はルータ若しくはインターフェースのようなデータを転送するユニットである。
【０００６】
スプリットプロトコルとは、トランザクションが要求及び応答において分割されるプロトコルとして規定される。ソース機能ユニットから通信経路内の前記第１中間機能ユニットまでの要求の伝送が完了した後、前記ソース機能ユニットは、前記宛先機能ユニットからの前記要求に対する応答を待つ必要なく、次の伝送に進むことができる。
【０００７】
前記宛先又はいかなる中間機能ユニットも、必要であれば、応答を与えるための別個のアービトレーション・手続きを開始する。スプリットバスプロトコルは、スレーブにおける応答生成に時間が掛かる場合に、より効率的である。
【０００８】
パイプラインによって、マスターが複数の未処理の要求（即ち、応答を待っている要求）を有することが可能になる。前記同じ通信スレッド内の全てのトランザクションは、順序化され、即ち前記要求は、これらの応答のための前記要求がマスターによって発行されたのと同じ順序でスレーブによって実行され、応答は、これらの応答のための要求がマスターによって発行されたのと同じ順序で供給される。
【０００９】
通信スレッドは、異なるソース機能ユニットから生じる異なる処理又はデータストリーム間で、データストリームを識別するのに使用されることができる。異なる通信スレッドを有するトランザクションは、いかなる順序化の制約も有さない。
【００１０】
ソース機能ユニットによって送られるメッセージは、命令、アドレス及び／又は他のデータを含み得る。前記メッセージは、１つ以上の中間機能ユニットを経由して、該メッセージが宛先機能ユニットに到達するまで転送される。前記宛先機能ユニットは、自身の順番において、前記ソース機能ユニットにメッセージを送っても良い。
【００１１】
米国特許第６，１８２，１８３号公報は、前記ソース機能ユニットから前記宛先機能ユニットまでの経路において、２つの後続する機能ユニット間でメッセージを交換するためのリンクレベルプロトコルを提供している。既知のプロトコルによれば、マスター機能ユニットは、命令（Ｃｍｄ）、アドレス（Ａｄｄｒ）又はデータ（ＤａｔａＲｅｑ）のような情報を生じると同時に、前記情報が属するスレッドの識別子（ＲｅｑＴｈｒｅａｄＩＤ）を供給する。同様に、前記スレーブ機能ユニットは、情報（ＤａｔａＲｅｓｐ）を供給することができ、前記情報が属するストリームを、識別子（ＲｅｓｐＴｈｒｅａｄＩＤ）によって示すことができる。
【００１２】
更に、前記スレーブは、前記マスターに、通信スレッドのステータスに関する情報（ＲｅｑＴｈｒｅｄＢｕｓｙ）を供給することができる。このことは、前記スレーブが前記マスターに、該スレーブが、特定のスレッドと関連付けられたいかなる新しい要求も獲得することができないことを示すことを可能にする。１つの実施例において、ＲｅｑＴｈｒｅａｄＢｕｓｙ信号は、スレッドごとに１つの信号を有するベクトルであり、アサートされる信号は、関連付けられているスレッドがビジーであることを示す。類似して、応答スレッドビジー（ＲｅｓｐＴｈｒｅａｄＢｕｓｙ）信号は、前記マスターが特定のスレッドと関連付けられているいかなる応答もとることができないことを前記スレーブに示すことを可能にする。
【００１３】
ＴｈｒｅａｄＢｕｓｙ情報（ＲｅｑＴｈｒｅａｄＢｕｓｙ及びＲｅｓｐＴｈｒｅｄＢｕｓｙ）は、イニシエータが伝送を無駄に開始しようとするのを防止する。従って、この情報は、より効率的な通信に寄与している。しかしながら、全てのスレッドがビジーである場合、通信はやはりブロックされる。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、改善された方法及び処理システムを提供することにある。本発明による改善された方法は、添付請求項１の特徴部によって特徴付けられる。前記改善された処理システムは、添付請求項４の特徴部によって特徴付けられる。
【課題を解決するための手段】
【００１５】
本発明の改善された方法において、前記ターゲット機能ユニットによって与えられる情報は、あるスレッドに関する要求又は応答が、前記情報が供給されている瞬間において取り扱われることができるかどうかについて示すだけでなく、該情報は、前記第１機能ユニット（Ｉ）が少なくとも１つの通信スレッドに関するデータを交換する可能性を予測することができるようにする。
【００１６】
このようにして、イニシエータ機能ユニット内のスケジューラは、異なる通信スレッドに関する伝送がどの順序で取り扱われるべきであるかをより良くスケジュールすることができるようになる。
【００１７】
請求項２の実施例において、特定の通信スレッドに関するバッファの充填度を示す情報は、前記イニシエータに、どれだけ長いデータ伝送がバッファのオーバーフローが生じる前に、行われることができるかを示す。これにより、第１機能ユニット（Ｉ）は、前記通信スレッドに関するデータ交換の可能性の終了を予測することができるようになる。
【００１８】
請求項３の実施例において、期待される待ち時間を示す情報によって、第１機能ユニット（Ｉ）は、新しいデータが供給されるとき又は新しいデータが受理されることができるときを予測することができるようになる。前記第２機能ユニットは、例えば、２つの入力ベクトルから得られるベクトルを計算するのに、比較的長い処理時間を必要とし得る。これは、前記得られるベクトルが伝送される第１機能ユニットに、残りの処理時間に関する指示を示すことができる。次いで、前記第１機能ユニット内のスケジューラは、前記得られるベクトルがレディ状態であると期待される時間に、データ伝送をスケジュールすることができる。
【００１９】
例えば、これは、前記バッファのオーバーフローが生じる傾向にある時間に、前記データ伝送を他の通信スレッドに関してスケジュールすることができる。同様に、これは、この指示を入力ベクトルを供給する第１機能ユニットに供給し、該第１機能ユニットは、この情報を自身のスケジューリングに使用することができる。
【００２０】
第１機能ユニット（Ｉ）が通信スレッドに関するデータの交換の可能性を予測することができるようにする情報を、第１機能ユニット（Ｉ）に供給することによって、該第１機能ユニットは、異なる通信スレッドに関する伝送を、より良くスケジュールすることができる。このことは、全ての通信スレッドが同時に利用不可能であることの発生を、減少することを可能にする。
【００２１】
本発明は、ネットワーク内の複数の機能ユニットとして実施されるシステム・オン・シリコンに、特に関連する。システム・オン・シリコンは、ますます増加している既存の機能の新しいフィーチャ及び改善を実施する必要性により、絶え間なく複雑性が増していることを示している。このことは、構成要素が集積回路上に組み込まれることができる集積度を向上することによって、可能にされている。同時に、回路が動作されるクロック速度も増加される傾向にある。増加された集積度の構成要素と組み合わされる高いクロック速度は、同じクロックドメイン内で同期して動作することができる領域を減少してきた。このことは、モジュールの取り組み方の必要性を生じた。前記のような取り組み方によれば、前記処理システムは、複数の比較的独立な、複雑なモジュールを有する。従来型の処理システムにおいて、前記モジュールは、通常、互いにバスを介して通信する。しかしながら、モジュールの数が増加するほど、通信のこの仕方は、以下の理由のために、もはや実用的ではない。一方で、多数のモジュールは、非常に高いバスの負荷を形成する。他方で、前記バスは、１つのデバイスだけがデータを該バスに送信することができるようにするので、通信のボトルネックを形成する。通信ネットワークは、これらの不利な点を克服する効果的な仕方を形成する。前記通信ネットワークは、複数の部分的に接続されているノードを有する。モジュールからのメッセージは、ノードにより、１つ以上の他のノードに転送される。このことは、多くの情報ストリームが、イニシエータ及びターゲットユニットの対の間を通過することを意味している。本発明は、これらのストリームのスケジューリングを容易にする。
【発明を実施するための最良の形態】
【００２２】
これら及び他の見地は、添付図面を参照してより詳細に記載される。
【００２３】
図１は、データを交換する従来型の方法を示している。
【００２４】
ここで、第１処理ユニット（Ｐ）は、通信スレッドに関する識別子ＴＩＤ、前記スレッド用のデータＤＡＴＡ及び信号に関する信号有効性ＶＡＬＩＤを供給する。第２処理ユニットが前記スレッドを受理することができる場合、該第２処理ユニットは、このことを信号ＡＣＣＥＰＴによって伝える。
【００２５】
図２は、第１及び第２機能ユニット間でデータを交換する本発明による方法を模式的に示している。前記方法は、以下のステップを含んでいる。第１ハンドシェイク手続き（ＨＳＤ）において、データは、第１機能ユニット（Ｉ）及び第２機能ユニット（Ｔ）によって選択される通信スレッド（ＴＩＤ）に対応して交換される。同時に、第２機能ユニット（Ｔ）から第１機能ユニット（Ｉ）までの少なくとも１つの通信スレッドの状態に関する第２情報が、第２ハンドシェーク手続き（ＨＳＴ）において第１機能ユニット（Ｉ）から第２機能ユニット（Ｔ）に交換される。前記情報は、第１機能ユニット（Ｉ）が、前記少なくとも１つの通信スレッドに関するデータの交換の可能性を予測することができるようにする。
【００２６】
前記データの伝送に関する第１ハンドシェイクは、ＶＣＩ、ＯＣＰ（図５及び７において詳細に説明される）において使用されているような典型的なハンドシェイク、又はトランザクションがＴＩＤ（図６及び８を参照）上で進行されることができるか若しくは進行されることができないかに関するフィードバックが供給される拡張されたハンドシェイクのいずれであっても良い。この基本的なグループの信号は、通信スレッドのデータがストールを伴わずにスケジュールされることができる情報を集める独立のダイアログとして、他のグループの信号によって拡張される。
【００２７】
第１及び第２ハンドシェイクＨＳＤ及びＨＳＴは独立であり、従って、これらは、並行に処理されることができる。第２ハンドシェイクＨＳＴから収集された情報は、前記イニシエータによって、異なる通信スレッドに関する通信を効率的にスケジュールするのに使用される。
【００２８】
実際の例において、第２ハンドシェイクＨＳＴは、第１信号ＩＮＦＯ  ＴＩＤ、第２信号ＩＮＦＯ  ＶＡＬＩＤ、及び第３信号ＩＮＦＯ  ＩＮＦＯの交換を有する。第１信号ＩＮＦＯ  ＴＩＤは、特定の通信ユニットに関して示している。第２通信信号ＩＮＦＯ  ＶＡＬＩＤは、信号ＩＮＦＯ  ＴＩＤが有効であるかどうかを示している。第３信号ＩＮＦＯ  ＩＮＦＯは、プロトコルの更なる実施に依存して、様々な意味を含むことができる。これは、例えば、期待される待ち時間を示す、即ちデータが利用可能になるとき又はデータが信号ＩＮＦＯ  ＴＩＤによって識別されているスレッドに関して受理されることができるときを、示すことができる。そうでない場合、前記信号は、例えば、バッファの充填度を示すことができる。この情報は、データ消費イニシエータが、データ生成ターゲットが自身のバッファからデータを供給するのをどれだけの長さ継続することができるかを推定するのを助ける。これは、最良の場合の推定又は最悪の場合の推定であっても良い。最悪の場合の推定は、前記バッファの現在の中身を読むのに必要な時間を計算して、行われることができる。最良の場合の推定は、データターゲットが所定のレートでデータを供給し続けると仮定することにより、行われることができる。実際に、ターゲットは、平均時間で、新しいデータを発生することができる。また、これは、データ生成イニシエータが、データ消費ターゲットがデータを受理することをどれだけの長さ継続することができるかを推定するのを助けるることもできる。これも最悪の場合の推定である。実際に、前記ターゲットは、平均時間において、自身のバッファ内に記憶されているデータを処理することができる。最良の場合の推定は、データが処理される平均レートを考慮にいれることにより、行われることができる。
【００２９】
図３に示されているように、この方式において、前記イニシエータは、前記ターゲットからの通信スレッド情報を要求する（ポーリングする）。情報は、同時に、１つの通信スレッドに関して要求され、通信スレッドをＩＮＦＯ  ＴＩＤ信号によって示し、ＩＮＦＯ  ＶＡＬＩＤを上昇させる。前記ターゲットは、ＩＮＦＯ  ＩＮＦＯ信号に関する情報を（この場合、固定された数のサイクルにおいて）供給する。
【００３０】
この方式の場合、複数の異なるハンドシェイク方式が規定されることができる。１つの例は、ＩＮＦＯ  ＴＩＤによって識別されている通信スレッドに関する情報が要求されていることを知らせるために、有効信号（ＩＮＦＯ  ＶＡＬＩＤ）を有することである。これは、所定の時間間隔（例えば、１サイクル）の間、高く保持され、応答（ＩＮＦＯ  ＩＮＦＯ）は、固定された数のサイクル（例えば、１）で到来する。他の例は、前記ターゲットが応答を遅延することを可能にするものであり、応答が到来するまで、有効信号（ＩＮＦＯ  ＶＡＬＩＤ）を高く保持することである。前記応答は、単一のサイクルの間、受理信号によって示され、該単一のサイクルにおいて、前記応答（ＩＮＦＯ  ＩＮＦＯ）も与えられる。
【００３１】
イニシエータが生成側及び消費側であるポーリング方式の例は、それぞれ、図５及び６に詳細に示されている。生成側であるイニシエータの場合、消費側であるターゲットは、例えば、所与の通信スレッド上でデータを受理するのに利用可能であるバッファスペースの量を示す情報を供給することができる。生成側であるターゲットは、例えば、消費側であるイニシエータに、どれくらいのデータが前記所与の通信スレッド内で利用可能であるかを提供する、又は自身が新しいデータを供給する周波数を示すことができる。
【００３２】
図４に示されているように、第２の方式において、前記ターゲットは、情報のフローを前記イニシエータ向けて駆動する。イニシエータに供給されることができる前記情報の例は、幾つのハンドシェイクが、ストールなしに所与の通信スレッド上で実行されることができるかについての、差分又は絶対値のような更新（割り込みに似ている）によって構成されている。様々なハンドシェイク方式が、本発明の拡張において、可能である。
【００３３】
前記イニシエータが生成側及び消費側である割り込み方式の例は、図７及び８にそれぞれ示されている。生成側であるイニシエータの場合、消費側であるターゲットは、所与の通信スレッド上で利用可能となる各新しい空のバッファ位置（又はバッファ位置のグループ）に関してイニシエータに通知することができる。消費側であるイニシエータの場合、前記生成側のターゲットは、利用可能となる各新しいデータエレメント（又はデータエレメントのグループ）に関してイニシエータに通知することができる。
【００３４】
上述で提案された２つの方式は、両方とも異なるコンテキストにおいて利用可能である。前記イニシエータがＣＰＵである場合、前記ポーリング方式（該ポーリング方式は、どれが次にスケジュールされるかを決定するために全ての適切な通信スレッドをチェックする）は、低コストであることができる。前記割り込み方式は、通知が割り込みとして扱われることを必要としており、該割り込みの取り扱いは、これらがコンテキストの切り替えを必要とするので、コストが高い。
【００３５】
専用機能ユニットの場合、フロー制御に類似する前記割り込み方式は、これは、例えば、カウンタの更新を生ずるのみであるので、低コストである。通信スレッドのスケジューラは、少なくとも必要な情報を常に有しており、直ちに進行することができる。
【００３６】
これとは対照的に、専用機能ユニットが情報をポーリングする前記ポーリング方式は、スケジューリングの決定の前に貴重なサイクルを消費するか、又はこれが不完全な情報を使用する（従って、前記スケジューリングの質を低下させる）かのいずれかである。
【００３７】
機能ユニットがこれらの拡張に対応していない場合、基本的なハンドシェイクは変化されておらず、付加的なグループの信号はＩＮＦＯ  ＶＡＬＩＤを低い値にデフォルト設定することにより無視されることができるので、前記機能ユニットは、やはり、上述の拡張された方式の各々と共に使用されることができる。
【００３８】
前記のような拡張に対応していないイニシエータを、これらの拡張の１つに対応しているターゲットに接続することは、単に前記のようなｉｎｆｏのグループを無視することによって、なされることができる。前記ポーリング方式の場合、前記ターゲットは、いかなるポーリングも得ず、従って、いかなる情報も生じない。
【００３９】
前記割り込み方式の場合、生成された前記情報は、無視される。これらの拡張の１つに対応しているイニシエータを、前記のような拡張に対応していないターゲットに接続するには、前記イニシエータが、自身が、ターゲットからの情報を有さなくても通信をスケジュールすることができるように設計されている必要がある。
【００４０】
前記割り込み方式に対応しているイニシエータ機能ユニットを、前記割り込み方式に対応しているターゲット機能ユニットに接続するためには、小さいアダプタが、これら２つの機能ユニットの間に挿入されなければならず、前記ターゲットからの通知が、イニシエータが情報をポーリングする際に該イニシエータに供給されるように記憶される。同様に、前記生成側から消費側に送信されるデータも、前記ハンドシェイク情報を更新するためにこのアダプタを通過しなければならない。例えばターゲット消費側の場合、（前記アダプタによって前記イニシエータに報告されるべき）前記バッファの充填度は、伝送されるデータに伴って増加し、ターゲット生成側の場合、（前記アダプタによって前記イニシエータに報告されるべき）前記データの利用可能度は、伝送されるデータに伴って減少する。
【００４１】
同様に、前記ポーリング方式に対応しているイニシエータを、前記ポーリング方式に対応しているターゲットに接続するには、前記ターゲットをポーリングし、変化について前記イニシエータに通知するアダプタを中間に必要とする。
【００４２】
前記のような２つの拡張は、通信スレッドに関する情報が、付加的なハンドシェイクを介して得られることができる２つの場合のみ、即ち（ａ）イニシエータが情報をポーリングする場合と（ｂ）イニシエータが前記ターゲットにおける何らかの変化に関して通知される場合とを含んでいる。
【００４３】
提案された前記方式は、ＶＣＩ及びＯＣＰのような、独立の通信スレッド上の通信を可能にする装置及びシステムレベルの通信プロトコルに関連している。このことは、現存のリンクレベルの方式を、ターゲットから情報の収集を可能にするように拡張する。この情報は、リンク上の通信スレッドのよりよいスケジューリングを得るように前記イニシエータによって使用される。
【００４４】
上述の提案された２つの方式は、通信スレッドに関する情報が付加的なハンドシェイクを介して得られることができる２つの場合のみ、即ち（ａ）イニシエータが情報をポーリングする場合と（ｂ）イニシエータが前記消費側における何らかの変化に関して通知される場合とを含んでいる。
【００４５】
図９は、データ処理システムを模式的に示しており、該データ処理システムは、複数の機能ユニットを接続しているネットワークを含んでいる。前記処理システムは、データと前記データに関する通信スレッド識別子とを、スプリットプロトコルに従って、ソース機能ユニットＳＦＵから宛先機能ユニットＤＦＵまでの通信経路（矢印で示されている）に沿って、１つ以上の中間機能ユニットＩＦＵ１、…、ＩＦＵ５を介して伝送する。前記通信経路は、図２ないし８の１つの参照することによって説明されているように、少なくとも１対のイニシエータ及びターゲットユニットを含んでいる。前記データを通信スレッド識別子と共に伝送することにより、複数の関連のないトランザクションであって、互いに異なる通信スレッド識別子を有するトランザクションが、独立に発生することができる。
【００４６】
本発明の保護範囲は、本明細書に記載されている実施例に限定されるものではないと述べる。本発明の保護範囲は、添付請求項における符号によって限定されるものでもない。「有する」という語は、請求項に記載されていない他の部分を排除するものではない。単数形の構成要素は、複数のこのような構成要素を排除するものではない。本発明の一部を形成する手段は、専用ハードウェアの形態又はプログラムされた汎用プロセッサの形態の両方において実施されることができる。本発明は、各新しいフィーチャ又はフィーチャの組み合わせにある。
【図面の簡単な説明】
【００４７】
【図１】データを交換する従来型の方法を示している。
【図２】本発明によるデータを交換する方法を模式的に示している。
【図３】本発明による方法の第１実施例を示している。
【図４】本発明による方法の第２実施例を示している。
【図５】前記第１実施例の第１の例を示している。
【図６】前記第１実施例の第２の例を示している。
【図７】前記第２実施例の第１の例を示している。
【図８】前記第２実施例の第２の例を示している。
【図９】本発明による複数の機能ユニットを有するネットワークを示している。
【図１】
2006525587.tif 000003
【図２】
2006525587.tif 000004
【図３】
2006525587.tif 000005
【図４】
2006525587.tif 000006
【図５】
2006525587.tif 000007
【図６】
2006525587.tif 000008
【図７】
2006525587.tif 000009
【図８】
2006525587.tif 000010
【図９】
2006525587.tif 000011
【国際調査報告】
2006525587.tif 000012
2006525587.tif 000013
2006525587.tif 000014