(57)【要約】【課題】  アドホック網上に、グリッドサービス環境を効率よく構築し、高品質な分散協調処理を実現する。【解決手段】  クライアントノード２０ｃは、ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計する。サーバノード２０ｓ−１〜２０ｓ−ｎは、依頼されたジョブを実行する場合にはサーバ動作となって、クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果をクライアントノード２０ｃへ送信する。【選択図】  図１
2006201896.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワーク上で通信を行うネットワークシステムにおいて、
ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計するクライアントノードと、
依頼されたジョブを実行する場合にはサーバ動作となって、前記クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果を前記クライアントノードへ送信するサーバノードと、
を有し、固定局を不要として、無線通信により移動可能な複数のノードで構築されたアドホック網上で分散協調処理を行うことを特徴とするネットワークシステム。
【請求項２】
前記サーバノードは、過去に実行したジョブ処理の実行履歴を保持し、前記クライアントノードからの問い合わせに対して、前記実行履歴を応答し、前記クライアントノードは、前記実行履歴にもとづいて、前記サーバノードのジョブ処理の実績を判断して、ジョブ処理の受け入れ可能なノードを決定することを特徴とする請求項１記載のネットワークシステム。
【請求項３】
前記サーバノードは、過去のジョブ実行履歴にもとづいて、ジョブ処理への参加意思を動的に求め、前記クライアントノードからのジョブ実行依頼に対して、ジョブ処理を受け入れ可能かを応答することを特徴とする請求項１記載のネットワークシステム。
【請求項４】
前記クライアントノードと前記サーバノードとのネットワーク接続性が失われた場合は、複数ノードからのジョブ処理結果を、ジョブ依頼元の前記クライアントノード以外のノードが受信した上で集計して一定時間バッファリングし、一定時間内にネットワーク接続性が回復された場合に、元の前記クライアントノードへ処理結果を送信することを特徴とする請求項１記載のネットワークシステム。
【請求項５】
無線ネットワーク上で通信を行う移動通信ノードにおいて、
クライアントから依頼を受けたジョブを処理するグリッドジョブ処理部と、
ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼及びジョブ処理結果を集計し、依頼されたジョブを実行する場合にはサーバ動作となって、前記クライアントからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答するジョブ管理部と、
ジョブ実行に必要なノードのリソースを管理し、かつ過去のジョブ実行履歴にもとづいて、ジョブ処理への参加意思を動的に求めるリソース管理部と、
を有し、固定局を不要として、無線通信により移動可能な複数のノードで構築されたアドホック網上で分散協調処理を行うことを特徴とする移動通信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム及び移動通信ノードに関し、特に無線ネットワーク上で通信を行うネットワークシステム及び無線通信を行う移動通信ノードに関する。
【背景技術】
【０００２】
近年、IEEE（the Institute of Electrical and Electronic Engineers）802.11で規格が統一化された無線ＬＡＮやBluetoothといったディジタル無線通信技術が発展し、また、ノートパソコンやＰＤＡ（Personal Digital Assistants：携帯情報端末）などを用いたモバイルコンピューティングが急速に普及しており、両者の特性を活かしたアドホック網（ad hoc network）技術が注目されている。
【０００３】
アドホック網とは、無線ＬＡＮのようなアクセスポイント（ＬＡＮにつないである中継器（無線局）のこと）を必要としない、無線で接続できるノード（例えば、ノートパソコン、ＰＤＡ、携帯電話など）のみで構成されたネットワークのことである。アドホック網は、基地局やアクセスポイントを持たないので、安価にネットワークを構築することができ、限られた域内での簡易なネットワークの構築手段として有望視されている。
【０００４】
アドホック網では、移動可能なノードが無線により通信を行う。例えば、ノードＡ、Ｂが通信する場合、通信に使用する電磁波が直接到達可能な範囲にあるならば、ノードＡ、Ｂは直接通信を行う。また、電磁波が直接到達不可能な範囲にノードＡ、Ｂが位置するならば、ノードＡ、Ｂからの電磁波が到達可能な位置に存在するノードＣがノードＡ、Ｂの通信内容を中継して通信を実現する。
【０００５】
したがって、アドホック網を構成するノード自身は、通信の送受信を行う主体（終端点）である一方、他のノードを終端点とする通信の中継、すなわちルーチングを行う主体（ルータ）の機能をも同時に備えることになる。
【０００６】
一方、近年になって、グリッドコンピューティング（Grid Computing）と呼ばれる技術の研究開発が進められている。グリッドコンピューティングとは、地理的に分散した計算機リソースをネットワークで接続し、あたかも１つの計算機システムのように利用する分散協調処理技術のことである。
【０００７】
グリッドコンピューティングは例えば、１台の計算能力ではスーパーコンピュータに劣るパソコンを、インターネットを経由して数十台〜数百台と接続して、スーパーコンピュータを越える計算能力を引き出し、工学や医学等の分野での膨大な量の計算を実行させたりするものである。
【０００８】
グリッドコンピューティングのサービス環境（グリッドサービス環境）において、ユーザは、計算処理がどのコンピュータで実行されているか、どのデータベースからデータを転送しているか等は全く意識する必要がなく、仮想的なスーパーコンピュータとして利用することができる。
【０００９】
また、グリッドサービス環境では、スケジューラと呼ばれるサーバが存在し、グリッドサービス環境内の各ノードの認証や、各ノードが持つ計算資源情報の管理を行っている。さらに、スケジューラは、クライアントからの依頼を受けて、ジョブの各ノードへの分配や、スケジューリングといった役目を担う。
【００１０】
従来の分散処理の技術としては、処理依頼に対して、自己の能力を評価して受け付けるか否かを判断し、分散処理を行う技術が提案されている（例えば、特許文献１）。
【特許文献１】特開平０７−１２９５２０号公報（段落番号〔００１４〕〜〔００１８〕，第２図）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記で説明したアドホック網では、基地局を持たずに、移動可能な各ノードが、無線による通信を互いに対等に行うという性質から、アドホック網へのノードの参加・脱退は随時行われる。
【００１２】
また、ノードの移動によって、ノード間の物理的な位置関係の変化や、電磁波の伝播状況の変化によるネットワークトポロジの変化が煩雑に起こり得る。さらに、ノードは移動通信機であるので、電池駆動が前提であり、必然的に各ノードは消費電力の節約を意識し、アドホック網上で動作するプロトコルは、電力を消費する不要な通信を抑制する必要がある。
【００１３】
このように、アドホック網では、既存の有線通信技術を前提としたイーサネット（登録商標）のような網とは特性が全く異なるものなので、既存の有線通信技術上でチューニングされたアプリケーションやミドルウェアなどはアドホック網上では効率的に動作しない。したがって、これまで特に有線通信技術を前提に研究開発が進められてきたグリッドサービス環境を、アドホック網上で実現する場合においても、例えば、以下のような困難が存在する。
【００１４】
アドホック網上では、電磁波の伝播状況の変化による一時的な通信不能状態や、ノードの電池切れ、移動によるアドホック網からの離脱が煩雑に発生し得ることから、既存のグリッドサービス環境の方式をそのままアドホック網上で構築すると、極めて信頼性に乏しいものとなることが予想される。
【００１５】
アドホック網上では、すべてのノードが自由にネットワークに参加・離脱できることから、グリッドサービスで存在していた固定局としてのスケジューラを設置することができない。
【００１６】
アドホック網を構成するノードは、既存のグリッドコンピューティングを構成するワークステーションや数値演算用コンピュータに比較して、処理能力に劣る限定的なものとなる。また、無線通信インタフェースの帯域幅は、有線通信インタフェースの帯域幅に対して狭いことから、既存のグリッドサービス環境に比べて性能的に劣るものになる。
【００１７】
これらの障害から、グリッドサービスをアドホック網上で実現するには、既存の有線通信技術を前提としたグリッドサービス方式を適用するのではなく、移動体端末の限定的な処理能力や無線帯域、煩雑に変化するネットワークトポロジといったアドホック網の特性を考慮して最適化したグリッドサービスを実現することが必要となる。
【００１８】
本発明はこのような点に鑑みてなされたものであり、アドホック網上にグリッドサービス環境を効率よく構築し、高品質な分散協調処理を実現したネットワークシステムを提供することを目的とする。
【００１９】
また、本発明の他の目的は、アドホック網上にグリッドサービス環境を効率よく構築し、高品質な分散協調処理を実現した移動通信ノードを提供することである。
【課題を解決するための手段】
【００２０】
本発明では上記課題を解決するために、図１に示すような、無線通信を行うネットワークシステム１において、ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計するクライアントノード２０ｃと、依頼されたジョブを実行する場合にはサーバ動作となって、クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果をクライアントノード２０ｃへ送信するサーバノード２０ｓ−１〜２０ｓ−ｎと、を有し、固定局を不要として、無線通信により移動可能な複数のノードで構築されたアドホック網１ａ上で分散協調処理を行うことを特徴とするネットワークシステム１が提供される。
【００２１】
ここで、クライアントノード２０ｃは、ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計する。サーバノード２０ｓ−１〜２０ｓ−ｎは、依頼されたジョブを実行する場合にはサーバ動作となって、クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果をクライアントノード２０ｃへ送信する。
【発明の効果】
【００２２】
本発明のネットワークシステムは、クライアントノードでは、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、サーバノードでは、クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果を送信する構成とした。これにより、不安定要素の多いアドホック網上に、有線通信技術を前提としたグリッドサービス環境を効率よく構築することができ、高品質な分散協調処理を実現することが可能になる。
【００２３】
また、本発明の移動通信ノードは、ジョブ管理部では、ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼及びジョブ処理結果を集計し、依頼されたジョブを実行する場合にはサーバ動作となって、クライアントからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答する構成とした。これにより、不安定要素の多いアドホック網上に、有線通信技術を前提としたグリッドサービス環境を効率よく構築することができ、高品質な分散協調処理を実現することが可能になる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態を図面を参照して説明する。図１はネットワークシステムの原理図である。ネットワークシステム１は、固定局を持たずに、無線通信により移動可能な複数の移動通信ノード（以下、単にノード）で構築されたネットワーク（アドホック網１ａ）上で分散協調処理（グリッドサービス）を行うシステムである。
【００２５】
ネットワークシステム１では、各ノードが無線通信を行いながら協調し、単一ノードでは実現不可能な処理を実現する。なお、ネットワークシステム１のアドホック網１ａ上で実現されるグリッドサービスを以降ではアドホックグリッドサービスとも呼ぶ。
【００２６】
クライアントノード２０ｃは、ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思の問い合わせ（クエリ：query）を行い、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計する。
【００２７】
サーバノード２０ｓ−１〜２０ｓ−ｎは、依頼されたジョブを実行する場合にはサーバ動作となって、クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果をクライアントノード２０ｃへ送信する。
【００２８】
図２はネットワークシステム１のサービス動作例を示す図である。図では、ノード１１が、ジョブを依頼してクライアントノードとなり、グリッドサービス環境を通じて他ノード１２〜１５にジョブが分配されて処理が行われる様子を示している。
【００２９】
アドホックグリッドサービスに関与するノード上では、グリッドサービス環境１１ｂ〜１５ｂが動作中であり、この環境を介してクライアントアプリケーション２１とグリッドジョブ処理部２２−１〜２２−５が協調動作を行う。
【００３０】
アドホック網は、無線通信機能を備える複数のノードにより構成されるもので、通信内容であるトラヒックの中継を専門に行うノードは（既存の有線インターネットとの中継を行うゲートウェイノードを除いては）存在せず、各ノードは通信を終端する機能と、他ノードの通信内容を中継する機能を持つ。
【００３１】
なお、各ノード間の通信は無線で行われるため、目視可能な通信ケーブルの類は存在しないが、図２においては、通信可能なノードの関係を明示するため、通信可能なノード同士を矢印で結んで示している。
【００３２】
各ノードは対等の立場であり、アドホックグリッドサービス環境を備えるノードは、状況に応じてジョブを依頼するクライアントにも、依頼を受けてジョブを処理するサーバにもなり得る。このためクライアントとサーバという関係は固定したものではなく、ジョブを依頼した時点でそのノードはクライアントの役割を担い（クライアントロール）、またジョブ依頼を受けたノードはサーバの役割を担う（サーバロール）。
【００３３】
次に構成・動作の詳細を説明する前に、グリッドサービスをアドホック網上で実現したネットワークシステム１の全体的な特徴について（Ａ１）〜（Ａ４）で説明する。
（Ａ１）アドホック網上では、ネットワークトポロジが煩雑に変化し得ることから、特定のノードがネットワーク上で必ず到達可能であることを前提にできない。特にGlobus等、既存のグリッドサービス環境でサーバノードの認証、サーバノード間でのジョブの分配等を行うスケジューラの存在を前提とできない。
【００３４】
このため、ネットワークシステム１では、アドホック網を構成する各ノード自身がスケジューラ機能を有する構成とした（１つのノードは、クライアント、サーバの両方の機能を持つ）。
【００３５】
（Ａ２）アドホック網を構成するノードの性能、またネットワークインタフェースの帯域が極めて限定的なものであること、またノードのほとんどが電池駆動であることから、不要な処理、通信を可能な限り抑制する必要がある。
【００３６】
また、アドホック網は可搬なノードで構成される一時的なネットワークであることから、網上のノード間で逐一認証処理を実施することは非効率的な場合が多い。また認証処理は処理能力・ネットワーク帯域の双方でオーバヘッドとなる場合がある。
【００３７】
このため、ネットワークシステム１の各ノードでは、自ノードのバッテリ電力を節約、またはオーバヘッドの削減のために、ノード間での認証処理を省いてノード間で通信を行う構成とした。
【００３８】
言い換えれば、ネットワークシステム１のアドホックグリッド上では、ジョブ処理の依頼元と依頼先の両ノード間で認証を必要とするような秘匿性、機密性を持ったアプリケーションよりも、簡素に入力データから処理結果を得る、また各ノードの可搬性を活かして、ノードの持つセンサから得た測定結果を処理した結果を集計するといったアプリケーションが有効である。
【００３９】
（Ａ３）ノードの可搬性、また電池駆動であることから、ジョブ処理を依頼したサーバノードが予測不可能な状況で通信不能となったりすることが考えられる。このため、ネットワークシステム１では、サーバノードが通信不能となった場合を予想して、他ノードへのジョブ処理が実行される構成とした。
【００４０】
（Ａ４）アドホックグリッドサービスにおいて、アドホック網上で既存のHPC分野等のアプリケーションが満足できる性能を得られるとは考えづらい。したがって、必ずしも処理能力を求めない、アドホック網に適したアプリケーションとしては、多数のサーバに依頼したジョブの処理結果がすべて得られなければ効果が得られないようなものよりも、依頼したジョブの一部について処理結果が得られれば有効であるようなものを対象とした。
【００４１】
次にネットワークシステム１を構築するノード２０の構成について説明する。図３はノード２０の構成を示す図である。ノード２０は、クライアントアプリケーション２１、グリッドジョブ処理部２２、ジョブ管理部２３、リソース管理部２４、ノード状態計測部２５、アドホック網プロトコル処理部２６、ＩＰ処理／無線通信インタフェース部２７から構成される。
【００４２】
クライアントアプリケーション２１は、アドホックグリッドサービスを利用するアプリケーションであり、アドホックグリッドサービスを提供する各ノード上に配備される。アドホックグリッドサービス稼動時には、このクライアントアプリケーション２１を起動したノードが、クライアントノードとしての役割を担うことになる。
【００４３】
グリッドジョブ処理部２２は、アドホックグリッドサービス環境上で、クライアントノードから依頼を受けたジョブを処理する部分である。ジョブ管理部２３は、ジョブ管理表２３ａとジョブ履歴表２３ｂを含み、クライアントアプリケーション２１からのジョブ要求を受けて、ジョブの分配と、ジョブ処理結果の集計を行う。
【００４４】
ジョブ管理表２３ａは、他ノードに処理依頼中のジョブの情報、また他ノードから依頼されて処理中のジョブの情報を保持し管理する。ジョブ履歴表２３ｂは、他ノードとのアドホックグリッドサービスに関連する通信内容に対して、これまでの自ノードでのジョブ処理の履歴及び他ノードへのジョブ依頼の履歴を一定期間記録し保持する。
【００４５】
リソース管理部２４は、リソース管理表保持部２４ａとノード構成情報保持部２４ｂを含み、ジョブの遂行に必要なリソースの情報を把握する。リソースには、ジョブを実行する他ノードの情報などが含まれる。
【００４６】
リソース管理表保持部２４ａは、現在依頼しているジョブと、ジョブの依頼先ノードとの対応関係、また依頼されているジョブと、ジョブの依頼元ノードとの対応関係などを記憶する。
【００４７】
ノード構成情報保持部２４ｂは、ノードの静的な特性を記憶する。ノードの静的な特性としては、ノードの計算処理能力、無線通信インタフェースの最大帯域、バッテリの最大容量（最大限充電した場合の最大駆動時間）などが含まれる。
【００４８】
ノード状態計測部２５は、ノードの動的な状態を計測し、ノード状態をリソース管理部２４に提供する。ノードの動的な状態としては、ノードの計算処理負荷、無線通信インタフェースの帯域占有率、バッテリの残余時間などが含まれる。
【００４９】
アドホック網プロトコル処理部２６は、アドホック網の構築・維持を担う機能であり、通信の必要に応じた経路の探索（宛先ノードのアドレス情報を元にした、パケットの転送先ノードの探索）、通信の必要が生じる以前の、事前の経路情報の蓄積（近隣ノード情報を予め収集しておき、パケットの宛先ノードアドレスとパケットを次に転送すべきノードの対応関係を保持しておく）、ノードの移動や障害発生時の経路情報の更新などを行う。
【００５０】
なお、通信内容の中継を制御する際に参照される経路表は、アドホック網プロトコルにより動的に形成されることから、事前のコンフィグレーションを必要としない（アドレス等のデータ設定が不要）。
【００５１】
ＩＰ処理／無線通信インタフェース部２７は、アドホック網プロトコル処理部２６の下位層を形成する。すなわち、無線通信プロトコル処理を基盤として、ＩＰ通信処理のインタフェース制御を行う。
【００５２】
次にノード２０がクライアントノードになった場合の処理の流れについて説明する。図４はクライアントノードの処理の流れを示す図である。ノード２０がクライアントとして動作する場合の、機能ブロック間の処理の流れを示している（すなわち、ジョブの処理を他ノードへ依頼し、処理結果を受信する過程の動作を示している）。
【００５３】
〔Ｓ１〕アドホックグリッドサービス上で処理すべきジョブを持つノードは、クライアントアプリケーション２１からジョブ管理部２３にジョブ処理を要求する。
〔Ｓ２〕ジョブ管理部２３は、ジョブの計算量を見積もり、ジョブを依頼するサーバ数を導出し、リソース管理部２４にリソース探索要求を出す。
【００５４】
〔Ｓ３〕リソース管理部２４は、リソース管理表保持部２４ａを参照し、ジョブ依頼先として有効な（充分に新しいエントリであり、かつ依頼するジョブ処理に必要な属性を持つ）サーバ情報を抽出する。
【００５５】
〔Ｓ３ａ〕抽出されたサーバ数が、ジョブ管理部２３から要求されたサーバ数に満たない場合、リソース管理部２４は、ＩＰ処理／無線通信インタフェース部２７を通じて他にサーバとなり得るノードを探索する。
【００５６】
〔Ｓ４〕リソース管理部２４は、ＩＰ処理／無線通信インタフェース部２７から受け取ったリソース探索結果を参照し、ノード探索の成否を判断する。
〔Ｓ５〕ノード探索に成功した場合、リソース管理部２４は、得られたリソース探索の結果をジョブ管理部２３に返す。
【００５７】
〔Ｓ６〕ジョブ管理部２３は、得られたリソース探索結果を元にジョブの依頼先サーバを決定し、ＩＰ処理／無線通信インタフェース部２７を介してジョブを依頼する。
例えば、リソース探索結果として、サーバノードの過去に実行したジョブ処理の実行履歴にもとづいて、サーバノードのジョブ処理の実績を判断して、ジョブ処理の受け入れ可能なノードを決定する。
【００５８】
または、サーバノードのバッテリ残余時間にもとづいて、サーバノードでのバッテリ切れによるジョブ処理のシャットダウンを予測して、ジョブ処理の受け入れ可能なノードを決定する。
【００５９】
〔Ｓ７〕ジョブ依頼後、ジョブ処理結果を得るまでの期間、リソース管理部２４は、ＩＰ処理／無線通信インタフェース部２７にリソース監視要求を発行する。
〔Ｓ８〕ＩＰ処理／無線通信インタフェース部２７は、現在、該当のジョブ処理を行っているノードに対するリソース監視結果を返信し、リソース管理部２４は、適宜ジョブ依頼先サーバの動作状況を確認する。
【００６０】
〔Ｓ９〕ジョブ処理依頼中、処理結果が得られるまでの間にノードの移動、電磁波の伝播状況の変化などによりアドホック網のトポロジに変動が発生する場合がある。このようなネットワーク上での変動の結果、アドホック網プロトコル処理部２６で管理する経路情報が変化した場合、アドホック網プロトコル処理部２６はリソース管理部２４にトポロジの変化を通知する。
【００６１】
〔Ｓ１０〕サーバノードからジョブ処理結果が返ってきた場合、ジョブ管理部２３は、処理結果を元にジョブ管理表２３ａを更新し、処理結果を集計する。
〔Ｓ１１〕ジョブ管理部２３は、リソース管理部２４に対し、ジョブ依頼先サーバのジョブ処理結果を登録する。
【００６２】
〔Ｓ１２〕すべてのジョブの処理結果が得られた場合、ジョブ管理部２３は、処理結果をクライアントアプリケーション２１に返し、アドホックグリッドサービスの分散協調処理を完了する。
【００６３】
次にノード２０がサーバノードになった場合の処理の流れについて説明する。図５はサーバノードの処理の流れを示す図である。ノード２０がサーバとして動作する場合の、機能ブロック間の処理の流れを示している（すなわち、依頼されたジョブを処理し、処理結果を送信する過程の動作を示している）。
【００６４】
〔Ｓ２１〕ジョブ管理部２３は、ＩＰ処理／無線通信インタフェース部２７を介して、ジョブ要請メッセージを受信することで、サーバノードとなる。
〔Ｓ２２〕ジョブ管理部２３は、ジョブ要請メッセージを受信すると、ジョブ実行履歴、ノード構成情報、またノード状態計測部２５から得られるノード状態からジョブを受け付けるべきか否かの指標となるwillingness（参加意思）情報を動的に導出し（過去のジョブ実行履歴として、例えば、ノードの計算処理負荷、帯域占有率、バッテリ残余時間の少なくとも１つにもとづき、参加意思を動的に求める）、この値を元にジョブ受付の可否を判断し、問い合わせに応答する（ジョブ要請応答メッセージの返信）。
【００６５】
〔Ｓ２３〕ジョブ管理部２３は、クライアントからジョブ処理要求を受信する。
〔Ｓ２４〕ジョブ管理部２３は、ジョブ受付の最終的な可否を判断し、ジョブを受け付けると判断した場合は、クライアントノードに受け付けた旨の応答を返す（ジョブ受付通知の返信）。
【００６６】
〔Ｓ２５〕ジョブ管理部２３は、要求を受けたジョブを自ノードで処理すると判断した場合は、ジョブ管理表２３ａにジョブ内容を記録し、グリッドジョブ処理部２２にジョブ処理要求を渡す。
【００６７】
〔Ｓ２６〕グリッドジョブ処理部２２は、ジョブ処理を完了すると、ジョブ管理部２３に処理結果を返す。
〔Ｓ２７〕ジョブ管理部２３は、ジョブ管理表２３ａから対応するエントリを削除し、ジョブ履歴表２３ｂに処理結果を記録する。その後、ジョブ管理部２３は、ＩＰ処理／無線通信インタフェース部２７を介して、ジョブ処理結果をクライアントノードに返す。
【００６８】
次にノード２０の主要構成要素の１つであるジョブ管理部２３の詳細動作について説明する。最初にクライアントロール時の動作について図６、図７を用いて説明する。
図６はクライアントロール時のジョブ管理部２３の動作フローを示す図である。図７はジョブ管理表２３ａの構成を示す図である。ジョブ管理表２３ａは、依頼ジョブ管理表２３ａ−１及び被依頼ジョブ管理表２３ａ−２から構成される。依頼ジョブ管理表２３ａ−１はクライアントロール時に、被依頼ジョブ管理表２３ａ−２はサーバロール時に使用される。
【００６９】
〔Ｓ３０〕クライアントアプリケーション２１は、ジョブ処理要求をジョブ管理部２３へ送信する。
〔Ｓ３１〕ジョブ管理部２３は、ジョブ処理要求を受けると、リソース管理部２４にリソース探索要求を出す。このとき、リソースであるサーバの処理能力等に関する条件とリソース探索範囲を指定する。
【００７０】
〔Ｓ３２〕ジョブ管理部２３は、リソース管理部２４からリソース探索結果を受け取る。
〔Ｓ３２ａ（図７）〕ジョブ管理部２３は、探索結果として得られたノード群の情報を依頼ジョブ管理表２３ａ−１に追加する。このとき、オリジナルジョブ識別子ｋ１の欄及びジョブ依頼元ｋ２の欄は空欄に設定する。
【００７１】
〔Ｓ３３〕ジョブ管理部２３は、得られたサーバノード数と、ジョブの必要とするサーバノード数（ｎ個とする）とを比較する。
〔Ｓ３４〕得られたサーバノード数がジョブの必要とするサーバノード数に対して少ない場合、リソース探索範囲、必要なサーバの条件を緩和し、リソース管理部２４に再びリソース探索要求を出す。
【００７２】
〔Ｓ３５〕得られたサーバノード数がジョブの必要とするサーバノード数に対して多い場合、サーバ探索終了後、ジョブ管理部２３はＩＰ処理／無線通信インタフェース部２７を通じて、ジョブ管理表２３ａの先頭のｎ個のサーバに対してジョブ処理要求を送信する。
【００７３】
〔Ｓ３５ａ（図７）〕ジョブ処理要求を送信したサーバノードに対しては、依頼先ステータスｋ３を要求中に設定する（なお、ＩＰ処理／無線通信インタフェース部２７を通じてジョブ処理結果を受け取ったジョブ管理部２３は、依頼ジョブ管理表２３ａ−１の依頼先ステータスｋ３を完了に更新する）。
【００７４】
〔Ｓ３６〕処理を依頼中のサーバが監視不能となった場合、またはジョブ処理進捗が遅い場合、リソース管理部２４はジョブ管理部２３へ通知する。
〔Ｓ３７〕通知を受けたジョブ管理部２３は、該当サーバに対応する依頼先ステータスｋ３をofflineに設定し、依頼ジョブ管理表２３ａ−１より依頼先ステータスｋ３が要求中でもofflineでもないノードを選択し、回復の見込みのないジョブの依頼を、選択したノードに対して再試行する。
【００７５】
〔Ｓ３８〕ジョブ管理部２３は、ジョブ処理結果を受信する。
〔Ｓ３９〕すべてのジョブ処理結果の受信を完了しなければステップＳ３６へ戻り、完了すればステップＳ３９ａへいく。
【００７６】
〔Ｓ３９ａ〕ジョブ管理部２３は、ジョブ処理結果をクライアントアプリケーション２１に返した後、ジョブ履歴表２３ｂに該当ジョブに対応するエントリを追加する。
次にサーバロール時のジョブ管理部２３の動作について図７〜図９を用いて説明する。図８はサーバロール時のジョブ管理部２３の動作フローを示す図である。図９はジョブ履歴表２３ｂの構成を示す図である。ジョブ履歴表２３ｂは、ジョブ処理履歴表２３ｂ−１とジョブ依頼履歴表２３ｂ−２から構成される。
【００７７】
〔Ｓ４１〕クライアントからのジョブサーバ要請メッセージは、ＩＰ処理／無線通信インタフェース部２７経由でジョブ管理部２３が受け取る。
〔Ｓ４２ａ〕ジョブ管理部２３は、リソース管理部２４にノード構成、ノード状態を問い合せる。
【００７８】
〔Ｓ４２ｂ〕ジョブ管理部２３は、リソース管理部２４から問い合せたノード構成、ノード状態を受け取る。
〔Ｓ４３〕ジョブ管理部２３は、得られた結果を収容したジョブサーバ要請応答メッセージをＩＰ処理／無線通信インタフェース部２７を介して返す。
【００７９】
〔Ｓ４４〕クライアントからのジョブ処理要求メッセージは、ＩＰ処理／無線通信インタフェース部２７経由でジョブ管理部２３が受け取る。
〔Ｓ４５〕ジョブ管理部２３は、ジョブ処理要求メッセージの内容を解析し、自ノード内で処理する場合はステップＳ４６ａへ、他ノードに処理を委譲する場合はステップＳ４７ａへいく。
【００８０】
〔Ｓ４６ａ〕自ノード内で処理する場合、ジョブ管理部２３は図７の被依頼ジョブ管理表２３ａ−２に該当ジョブ情報を追加する。このとき、ジョブ処理区分ｋ４をownedに更新する。表への追加後、グリッドジョブ処理部２２にジョブ処理要求を送る。
【００８１】
〔Ｓ４６ｂ〕グリッドジョブ処理部２２は、ジョブを処理し、処理結果をジョブ管理部２３へ送信する。
〔Ｓ４６ｃ〕ジョブ管理部２３は、被依頼ジョブ管理表２３ａ−２の該当エントリを削除した後、ＩＰ処理／無線通信インタフェース部２７経由でクライアントノードに処理結果を返す。
【００８２】
〔Ｓ４６ｄ（図９）〕ジョブ管理部２３は、ジョブ処理履歴表２３ｂ−１にエントリを追加する。
〔Ｓ４７ａ〕他ノードに処理を委譲する場合は、被依頼ジョブ管理表２３ａ−２に該当ジョブのエントリを追加した後、クライアントノードとして、クライアントノード時のジョブ管理部２３の動作フローに従い動作する。
【００８３】
〔Ｓ４７ｂ（図７）〕ただし、このとき、被依頼ジョブ管理表２３ａ−２の該当エントリのジョブ処理区分はpassedに更新し、依頼ジョブ管理表２３ａ−１のオリジナルジョブ識別子ｋ１には、依頼を受けたジョブのジョブ識別子を設定し（図中、００１を設定している）、ジョブ依頼元ｋ２には依頼元ノードのアドレスを設定する（図中、addr aを設定している）。以降の処理は、クライアントロール時の処理に準ずる。処理完了後はジョブ処理履歴表２３ｂ−１、ジョブ依頼履歴表２３ｂ−２にエントリを追加する。
【００８４】
次にノード２０の主要構成要素の１つであるリソース管理部２４の詳細動作について説明する。リソース管理部２４の動作としては、以下の（Ａ）〜（Ｄ）の動作がある。
（Ａ）リソース管理部２４の通常時の動作
ノードの通常時のリソース管理部２４の動作では、アドホック網プロトコル処理部２６内の経路表情報を定期的に取得する。図１０はアドホック網プロトコル処理部２６が有する経路表を示す図である。図は、あるタイミングｔｎのときの経路表（ｔｎ）と、その１回前のタイミング（ｔｎ−１）での経路表（ｔｎ−１）をそれぞれ示している。
【００８５】
図１１はリソース管理表保持部２４ａの構成を示す図である。リソース管理表保持部２４ａは、リソース管理表２４ａ−１とリソース管理履歴表２４ａ−２から構成される。リソース管理部２４は、時系列上連続する経路表の差分を取り、変化が生じた場合にリソース管理表２４ａ−１を更新する。
【００８６】
〔Ｓ５０ａ（図１０）〕任意の宛先アドレスについて、次ホップアドレスが変化した場合は、リソース管理履歴表２４ａ−２に該当アドレスのエントリを新規に作成し、変化時刻と変化内容（neighbor changed）を設定する。
【００８７】
〔Ｓ５０ｂ（図１０）〕ホップ数が変化した場合も、リソース管理履歴表２４ａ−２に該当アドレスのエントリを新規に作成し、変化時刻と変化内容（distance changed）を設定する。経路表上に新規に出現した宛先アドレスについて、経路表から削除された宛先アドレスについても同様である。
【００８８】
（Ｂ）サーバ探索時のリソース管理部２４の動作
図１２はリソース管理部２４の探索時の動作フローを示す図である。ノードがクライアントロールとして動作する際の、サーバ探索時の動作を示している。
【００８９】
〔Ｓ５１〕リソース管理部２４は、ジョブ管理部２３からリソース探索要求を受け取る。
〔Ｓ５２〕リソース管理部２４は、ジョブサーバ要請メッセージを生成し、このとき、オプションとしてジョブサーバ要請メッセージに自ノードのジョブ処理履歴を収容する場合があれば、ジョブサーバ要請メッセージ生成の前にリソース管理表２４ａ−１の内容の抽出を行う。
【００９０】
〔Ｓ５３〕リソース管理部２４は、ＩＰ処理／無線通信インタフェース部２７を介して、生成されたジョブサーバ要請メッセージを出力する。
〔Ｓ５４〕リソース管理部２４は、ノードからＩＰ処理／無線通信インタフェース部２７を介してジョブサーバ要請応答メッセージを受信し、リソース管理表２４ａ−１の該当サーバノードのアドレスに対応するエントリの最新タイムスタンプｅ１（図１１）を更新する。
【００９１】
〔Ｓ５５〕リソース探索の経過時間を計測する。タイマ設定時間以内にジョブサーバ要請応答メッセージを受信した場合はステップＳ５６へ、そうでなければサーバからの応答を待つ。
【００９２】
〔Ｓ５６〕リソース探索結果をジョブ管理部２３へ返す。
（Ｃ）ノード監視時のリソース管理部２４の動作
図１３はリソース管理部２４のノード監視時の動作フローを示す図である。ノードがジョブを依頼してクライアントロールとして動作する際、またはジョブ依頼を受けてサーバロールとして動作する際の、ノード監視時におけるリソース管理部２４の動作を示している。
【００９３】
〔Ｓ６１〕ノードのアドホック網からの離脱、ノードのアドホック網への参加その他アドホック網のトポロジが変化すると、アドホック網プロトコル処理部２６が動作し、経路の導出を行う。このときトポロジ変化情報は、アドホック網プロトコル処理部２６からリソース管理部２４へ送られる。
【００９４】
〔Ｓ６１ａ（図１１）〕トポロジ変化の通知を受けたリソース管理部２４は、リソース管理表２４ａ−１内でトポロジ変化の影響を受けるノードのアドレス、変化時刻、変化の内容をリソース管理履歴表２４ａ−２に登録する。
【００９５】
〔Ｓ６２〕トポロジの変化によりノードがネットワーク的に到達不可能となったか否かを判断する。
〔Ｓ６３〕到達不可能となったノードに対しては、該当ノードがリソース管理表２４ａ−１に存在する場合、リソース応答受信待ちタイマを起動後、ＩＰ処理／無線通信インタフェース部２７を介して該当サーバにリソース監視メッセージを送信する。
【００９６】
〔Ｓ６４〕リソース管理部２４は、リソース応答メッセージを受信した場合、リソース管理表２４ａ−１の該当アドレスの最新タイムスタンプを更新する。
〔Ｓ６５〕リソース応答受信待ちタイマ期限切れか否かを判断する。
【００９７】
〔Ｓ６６〕リソース応答受信待ちタイマ期限切れまでにリソース応答メッセージを受信できなかった場合、リソース管理表２４ａ−１の対応するエントリを削除し、ジョブ管理部２３にノード監視不能を通知する。
【００９８】
（Ｄ）サーバ探索応答処理時のリソース管理部２４の動作
図１４はリソース管理部２４のサーバ探索応答処理時の動作フローを示す図である。サーバ探索中のクライアントノードへの応答処理におけるリソース管理部２４の動作を示している。
【００９９】
〔Ｓ７１〕クライアントノードから、ＩＰ処理／無線通信インタフェース部２７経由でジョブサーバ要請メッセージを受信する。
〔Ｓ７２〕ノード構成情報を取得する。
【０１００】
〔Ｓ７３〕ノード状態計測部２５にノード状態を問い合わせる。
〔Ｓ７４〕ノード状態計測部２５からの計測結果を受信する。
〔Ｓ７５〕ジョブサーバ要請メッセージがwillingness形式（該当ジョブを処理するか否かの参加意思を求める形式）での応答要求か否かを判断する。willingness形式での応答要求ならステップＳ７６へ、そうでなければステップＳ７７へいく。
【０１０１】
〔Ｓ７６〕willingness形式での応答を要求していた場合は、収集した情報からwillingnessを動的に導出する。
〔Ｓ７７〕収集・導出された情報からジョブサーバ要請応答メッセージを構築する。
【０１０２】
〔Ｓ７８〕ＩＰ処理／無線通信インタフェース部２７経由でジョブサーバ要請メッセージを送信元のクライアントノードへ返す。
次にアドホック網を構成するノード間でジョブ処理を分担、融通しあい、アドホック網全体であたかも高性能な単一の計算機であるかのように計算処理を行うときのネットワークシステム１の動作について詳しく説明する。最初に、メッセージの詳細を以下の（１）、（１−１）〜（１−４）で説明する。
【０１０３】
（１）プロトコルメッセージの送信
図１５はアドホック網の構成を示す図である。ノード５１〜５８は、無線通信を行って移動可能であり、図中の矢印ａ１〜ａ７は、無線通信に用いる電磁波が到達可能で、直接通信可能である状態を表している。
【０１０４】
アドホックグリッドサービスを制御するアドホックグリッドプロトコルメッセージは、アドホック網上で交換される。各ノードではアドホック網プロトコルが動作し、プロトコルメッセージを交換することでメッセージのルーチングに必要な情報であるルーチング情報を生成し、ノード内に該当情報を保持する。
【０１０５】
ルーチング情報には、受信したメッセージを転送する際に、メッセージの転送元とメッセージの宛先から自ノードがメッセージの転送をすべきか否かを判断するための経路表と、ブロードキャストメッセージを受信した際に自ノードがメッセージの転送をすべきか否かを判断するための情報とが含まれる。
【０１０６】
そして、アドホックグリッドプロトコルメッセージの種類には、既存ネットワークプロトコルと同様にユニキャストメッセージとブロードキャストメッセージ２種類が存在する。
【０１０７】
（１−１）ユニキャストメッセージの送信
図１５に対し、ノード５１を送信元、ノード５７を宛先とするユニキャストメッセージが伝送される場合を考える。ユニキャストメッセージの転送処理は、既存のアドホック網プロトコル上で処理される。ノード５１から送信されたユニキャストメッセージは、まず隣接する（通信に用いる電磁波が直接到達可能な）ノード５６により受信される（矢印ｙ１）。
【０１０８】
ノード５６は、アドホック網を制御する経路表を検索し、ノード５１方向から受信したメッセージを宛先ノード５７へ転送する経路上に自ノードが存在することを認識すると、メッセージをノード５７に転送する（矢印ｙ２）。
【０１０９】
ノード５７は、メッセージの宛先が自ノードであることを確認すると、メッセージをアプリケーションで処理する。このとき、ノード５１から受信したメッセージを宛先ノード５７へ転送する経路上に自ノードが存在しないノード（ノード５２、５４）は、たとえメッセージを受信したとしても転送を行わず、特にエラーを通知することなく（silently）メッセージを破棄する。
【０１１０】
なお、アドホックグリッドプロトコルの内、ジョブ依頼メッセージ、ノード監視メッセージ、ノード監視応答メッセージ、ジョブ処理結果メッセージがユニキャストメッセージ中に収容される。
【０１１１】
（１−２）ブロードキャストメッセージの送信
図１６はブロードキャストメッセージの送信の様子を示す図である。ノード５１を送信元、メッセージの到達範囲を２とするブロードキャストメッセージが伝送される様子を示している。ブロードキャストメッセージの転送処理は、既存のアドホック網プロトコル上で処理される。ノード５１から送信されたブロードキャストメッセージは、まず隣接するノード５２、５４、５６により受信される（矢印ｂ１、ｂ３、ｂ５）。
【０１１２】
メッセージ送信時、メッセージのヘッダ中のパケット寿命フィールドには非０の整数値が収容される。パケット寿命フィールドの値はメッセージを転送可能な最大数を表す（すなわちブロードキャストメッセージの到達範囲を表す）。
【０１１３】
メッセージを受信した各ノード５２、５４、５６は、アドホック網を制御する経路表を検索し、ノード５１方向から受信したメッセージをブロードキャストする際に自ノードがブロードキャストの転送を受け持つノードであるか否かの情報を参照する。自ノードがブロードキャストメッセージの転送を行うノードである場合は、該当メッセージの転送を試みる（矢印ｂ２、ｂ４、ｂ６、ｂ７）。
【０１１４】
ノードは転送時に、メッセージのヘッダに含まれるパケット寿命フィールドが０でない場合には１減ずる。もしパケット寿命フィールドが０である場合は該当メッセージの転送を行わず、特にエラーを通知することなく（silently）メッセージを破棄する。
【０１１５】
図の場合ノード５３、５５、５７、５８はパケット寿命フィールドが０のブロードキャストパケットを受信するため、これらのノードはこれ以上該当ブロードキャストパケットの転送を行わない。また、アドホックグリッドプロトコルの内、ジョブサーバ要請メッセージがブロードキャストメッセージ中に収容される。
【０１１６】
（１−３）メッセージフォーマット
図１７はアドホックグリッドサービス上で交換されるプロトコルメッセージのフォーマットを示す図である。プロトコルメッセージには、（１−１）（１−２）で述べた通り、ユニキャストメッセージＵ１と、ブロードキャストメッセージＢ１の２種類が存在する。ユニキャストメッセージＵ１は、ユニキャストメッセージヘッダＵ１ａとメッセージボディｍ１０からなる。
【０１１７】
ブロードキャストメッセージＢ１は、ブロードキャストメッセージヘッダＢ１ａとメッセージボディｍ１０からなる。アドホックグリッドメッセージで用いるメッセージのメッセージボディｍ１０のフォーマットは共通であり、アドホックグリッドメッセージヘッダｍ１１とアドホックグリッドメッセージボディｍ１２からなる。
【０１１８】
アドホックグリッドメッセージヘッダｍ１１は、メッセージを生成したノードを特定するメッセージ生成ノードアドレスｍ１１ａ、メッセージの宛先ノードを特定するメッセージ宛先ノードアドレスｍ１１ｂ、メッセージ交換に用いるアドホックグリッドプロトコルの版数を示すプロトコルバージョンｍ１１ｃ、アドホックグリッドメッセージボディに収容されるメッセージの種類を示すメッセージ種別ｍ１１ｄ、メッセージのサイズを示すメッセージ長ｍ１１ｅからなる。
【０１１９】
一方、アドホックグリッドメッセージボディｍ１２は、メッセージを構成する属性であるメッセージフィールドｍ１２ｄの任意の個数の連結で構成される。各メッセージフィールドは、収容される属性の種類を示すフィールドタイプｍ１２ａ、メッセージフィールドのサイズを示すフィールド長ｍ１２ｂ、属性値を示すフィールドボディｍ１２ｃで構成される。
【０１２０】
（１−４）メッセージボディ形式
図１８、図１９はメッセージボディｍ１０の詳細を示す図である。アドホックグリッドサービス上で交換されるプロトコルメッセージのメッセージボディｍ１０の内容を示している。
【０１２１】
メッセージの種類はアドホックグリッドメッセージヘッダｍ１１のメッセージ種別ｍ１１ｄで表され、メッセージにはジョブサーバ要請メッセージ１０１、ジョブサーバ要請応答メッセージ１０２、ジョブ処理要求メッセージ１０３、ジョブ処理結果メッセージ１０４、ノード監視メッセージ１０５、ノード監視応答メッセージ１０６といった種類がある。
【０１２２】
ジョブサーバ要請メッセージ１０１は、ジョブを識別するためにジョブの依頼元が付与するジョブID１０１ａ、ジョブの依頼元を識別するためのジョブ依頼元ID１０１ｂ、ジョブの種類を概略的に示すジョブ分野１０１ｃ、ジョブの種類を詳細に示すジョブ種別１０１ｄ、ジョブ処理の負荷を示すジョブ単位１０１ｅ、センサや２次記憶バッファ等、ジョブの遂行に必要な機器を示す必須機器１０１ｆ、依頼を受けたジョブを他のノードに委譲/分配可能か否かを示す委譲／分配可否１０１ｇ、ジョブ処理要求を送信してから結果を受信するまでの最大ターンアラウンド時間を示す許容応答時間１０１ｈ、自ノードがこれまで処理してきたジョブ処理履歴１０１ｉ（オプション）等から構成される。
【０１２３】
ジョブサーバ要請応答メッセージ１０２は、対応するジョブサーバ要請メッセージ中のジョブID１０２ａ、処理サーバの処理能力を示すサーバ計算能力１０２ｂ、ノードが保持するセンサ等を示す保有機器１０２ｃ、自ノードが処理を引き受けたいと希望する度合いを示す処理willingness１０２ｄ、処理要求を受信してから処理結果を送信するまでの処理遅延として保証可能な時間長を示す保証応答時間１０２ｅ、自ノードのネットワークモビリティ（自ノードがアドホック網から離脱・参加を繰り返し、その頻度が高い場合に大きい値をとる）を示すモビリティ１０２ｆ、自ノードがこれまで処理してきたジョブ処理履歴１０２ｇ（オプション）等から構成される。
【０１２４】
ジョブ処理要求メッセージ１０３は、当初ジョブの依頼元がジョブサーバ要請メッセージ１０１送信時に付与したオリジナルジョブID１０３ａ、依頼時に細分化されたジョブ毎に割り当てられたジョブユニットID１０３ｂ、個々のジョブ処理に必要なジョブパラメータ１０３ｃ、ジョブデータ１０３ｄ等から構成される。
【０１２５】
ジョブ処理結果メッセージ１０４は、対応するジョブ処理要求メッセージ１０３中のジョブID１０４ａ、ジョブユニットID１０４ｂ、ジョブ処理を他ノードへ委譲や分配した場合に、その履歴を収容するジョブ処理履歴１０４ｃ、ジョブ処理結果１０４ｄ等から構成される。
【０１２６】
ノード監視メッセージ１０５は、対応するジョブ処理要求メッセージ１０３中のジョブID１０５ａ、ジョブユニットID１０５ｂ、該当ノード監視メッセージの送信元がメッセージを識別するために付与する監視メッセージID１０５ｃ等から構成される。
【０１２７】
ノード監視応答メッセージ１０６は、対応するノード監視メッセージ中のジョブID１０６ａ、ジョブユニットID１０６ｂ、監視メッセージID１０６ｃ、さらにジョブの進捗状況を示すジョブ進捗１０６ｄ、ジョブ処理中に生じたエラーや障害を報告するエラーメッセージ１０６ｅ（エラーが発生している場合にのみ）等から構成される。
【０１２８】
次にジョブサーバ要請メッセージ１０１の詳細を以下の（２）、（２−１）、（２−２）で説明する。
（２）ジョブサーバ要請メッセージ１０１
図２０はジョブサーバ要請メッセージ１０１の送信の様子を示す図である。アドホックグリッドサービス開始のためのサーバノード情報収集の様子を示している。クライアントノード５１は、サーバとして利用可能なノードを募集するため、ジョブサーバ要請メッセージ１０１をブロードキャストメッセージとして送信する（矢印ｃ１〜ｃ３）。
【０１２９】
ブロードキャストされたジョブサーバ要請メッセージ１０１は、直接通信可能な、隣接する（電磁波が到達可能な）すべてのノードに受信される。メッセージを受信したノードは、該当メッセージがブロードキャストメッセージであること、メッセージに設定されているパケット寿命フィールドの値が非０であることを確認すると、メッセージ中のパケット寿命を１減じた後、隣接するノードに転送する（矢印ｃ４〜ｃ７）。図の場合、メッセージのパケット寿命の初期値が２であったため、転送は１回だけ行われ、それより遠いノードへは転送されない（矢印ｃ８）。
【０１３０】
図２１はジョブサーバ要請応答メッセージ１０２の送受信の様子を示す図である。ジョブサーバ要請応答メッセージは、個々のサーバノードからクライアントメッセージに向けて送信される（矢印ｄ１〜ｄ７）。
【０１３１】
（２−１）ジョブサーバ要請メッセージ１０１の送信と応答
図２２はクライアントノードとサーバノードの間のジョブ要請・応答の送受信の様子を示す図である。
【０１３２】
〔Ｓ８１〕クライアントノードは、サーバノード群に対しブロードキャストでジョブサーバ要請メッセージ１０１を送信する。
〔Ｓ８２〕クライアントノードから送信されるジョブサーバ要請メッセージ１０１を受信した各サーバノードは、ノード状態を計測、ノード構成情報を取得する。
【０１３３】
〔Ｓ８３〕サーバノードは、ジョブサーバ要請応答メッセージ１０２中に自ノードの構成、自ノードの状態、自ノードのネットワークモビリティ、自ノードのジョブ処理履歴の情報を収容し応答する。
【０１３４】
〔Ｓ８４〕ジョブサーバ要請応答メッセージ１０２を受信したクライアントノードは、アドホックグリッドアプリケーションの必要とする構成、状態と照合し、該当クライアントノードをジョブ依頼対象とするか否かを判断する。
【０１３５】
〔Ｓ８５〕ネットワークモビリティの条件と適合するか判断する。
〔Ｓ８６〕ジョブ処理履歴条件に適合するか判断する。
〔Ｓ８７〕ステップＳ８４〜Ｓ８６の条件に適合したら、リソース管理表２４ａ−１に該当ノードを追加する。
【０１３６】
〔Ｓ８８〕ジョブサーバ要請応答メッセージ待ち時間を計測し、メッセージ待ち時間が期限切れとなった場合、ジョブサーバ要請処理を終了する。期限切れとなっていない場合、ステップＳ８３へ戻り、再度ジョブサーバ要請応答メッセージ待機状態に入る。
【０１３７】
（２−２）（２−１）の手順の代替手段
図２３はクライアントノードとサーバノードの間のジョブ要請・応答の送受信の様子を示す図である。図２２で示した処理の代替処理を示している。
【０１３８】
〔Ｓ９１〕クライアントノードはサーバノード群に対しブロードキャストでジョブサーバ要請メッセージ１０１を送信する。ジョブサーバ要請メッセージ１０１には、ジョブ実行に必要な処理能力、ジョブ実行に必要な機能、クライアントノードのネットワークモビリティ、クライアントノードのジョブ処理履歴、ジョブＩＤ、必要ノード構成などが含まれる。
【０１３９】
〔Ｓ９２〕ジョブサーバ要請メッセージ１０１を受信したサーバノードは、自ノードの構成、ステータス、機能、クライアントノードのネットワークモビリティ、クライアントノードのジョブ実行履歴を収集する。
【０１４０】
〔Ｓ９３〕サーバノードは、ジョブ実行の意思を表すwillingnessを導出する。
〔Ｓ９４〕ジョブサーバ要請応答メッセージ１０２中にwillingnessを収容しジョブクライアントノードに応答する。
【０１４１】
〔Ｓ９５〕ジョブサーバ要請応答メッセージ１０２を受信したクライアントノードは、メッセージ中のwillingnessが、ジョブ依頼対象となるか否かを示す最低限の閾値より大きいか判断する。大きい場合ステップＳ９６へ、大きくなければステップＳ９７へいく。
【０１４２】
〔Ｓ９６〕リソース管理表２４ａ−１に該当ノードを追加する。
〔Ｓ９７〕ジョブサーバ要請応答メッセージ待ち時間を導出し、メッセージ待ち時間が期限切れとなった場合、ジョブサーバ要請処理を終了する。期限切れとなっていない場合、ステップＳ９４へ戻り、再度ジョブサーバ要請応答メッセージ待機状態に入る。
【０１４３】
（３）クライアントからのジョブ依頼
図２４はクライアントからのジョブ依頼の様子を示す図である。ジョブ依頼メッセージはジョブクライアントからサーバノード５２、５６に向けてユニキャストで送信される（矢印ｆ１、ｆ２）。ジョブ依頼メッセージを受信したサーバノードが、自身がアドホック網制御プロトコル上ブロードキャストメッセージの中継を行うノードである場合（ノード５６）、ジョブサーバ要請メッセージ中の指示に従い自身の隣接ノードの処理能力、その他の情報を元にジョブサーバ要請応答メッセージを構築できる。
【０１４４】
クライアントからジョブ依頼メッセージを受信したサーバは、メッセージを受け取った隣接ノード以外の隣接ノード５７、５８にジョブのすべて、あるいは一部を依頼できる（矢印ｆ３、ｆ４）。ジョブの依頼対象となる隣接ノードは複数存在し得る。
【０１４５】
（４）サーバ進捗監視
図２５はサーバによるジョブ実行中の監視処理の様子を示す図である。クライアントノードからサーバノードへのジョブ依頼後、サーバからクライアントへジョブ処理結果が返されるまでは、サーバはジョブ実行中である。
【０１４６】
クライアントノードは、実行中のジョブの状態を把握するため、アドホック網プロトコル処理部２６の把握するアドホック網の経路表の時系列変化を調べる。経路表に変化が生じた場合、ジョブ実行中のサーバノードが変化に含まれるかを判断し、含まれる場合は該当サーバノードに監視要求メッセージを送信する。
【０１４７】
図中、ジョブ処理中に移動の結果クライアントノードの隣接ノードでなくなったサーバノード５２を検知したクライアントノード５１は、該当サーバノードに向けて監視要求メッセージを送信する。監視要求メッセージ送信は、何回か再試行される。図では移動してきた別ノード５０ａにより新たな経路ｐ１が形成され、該当経路上で監視要求メッセージが転送される。
【０１４８】
監視要求メッセージを受信したサーバノードは、自身のジョブ処理状況を収容した監視応答メッセージを応答する。監視応答メッセージを受信したジョブクライアントノードは、メッセージ中のジョブ処理状況を確認する。ジョブ処理状況が、サーバの申請した処理能力と依頼からの経過時間の積から期待される予想ジョブ処理量よりも著しく少ない場合、また監視応答メッセージが時間切れまでに受信できなかった場合、ジョブ復旧処理を行う。
【０１４９】
（５）ジョブ復旧処理
（４）のサーバ進捗監視プロセスにおいて、サーバがアドホックグリッドサービス環境からの離脱が確認された場合、またジョブ処理の進捗が予想より大幅に遅れている場合、またはネットワーク環境の変化により、依頼を受けたジョブのすべてを実行できなくなった場合など、例外的状況として他サーバノードへジョブを振り分け、復旧処理を行う。
【０１５０】
図２６はサーバによる復旧処理の様子を示す図である。ジョブ復旧処理において、ジョブクライアントノードはジョブサーバ要請段階において作成されたリソース管理表２４ａ−１を検索し、ジョブを依頼していない、空いているサーバに対し、ジョブ依頼メッセージを送信する（矢印ｇ１）。
【０１５１】
空いているサーバがない場合、リソース管理表２４ａ−１中のエントリが時間の経過などにより無効となっている場合には、ジョブサーバ要請のプロセスを再度実行する。この際、ブロードキャストの範囲を広げるなどの対処を施し、新たなサーバノード探索を行う。
【０１５２】
図ではメッセージの転送可能回数を増やしてジョブサーバ要請メッセージを送信していることから、図２０におけるメッセージ到達範囲（矢印ｃ８）より遠くまで、ジョブサーバ要請メッセージが到達している（矢印ｇ２）。
【０１５３】
（６）ジョブ処理結果のバッファリング及び集計処理
ジョブ処理サーバがジョブ処理を完了し、クライアントノードへ処理結果を応答する際に、クライアントノードと該当ジョブ処理サーバ間のネットワーク接続性が失われている場合、ジョブ処理サーバはジョブ処理結果を一定時間バッファリングする。
【０１５４】
ネットワーク接続性が回復した場合（ネットワーク接続性の喪失が偶発的な電磁波の不到達によるものであった場合等）、またはアドホック網プロトコル処理部２６がジョブクライアントとの間の代替経路の探索に成功した場合、バッファリングされたジョブ処理結果をジョブクライアントへ送信する。
【０１５５】
クライアントからではなく、サーバノードからジョブ依頼メッセージを受信したサーバノードは、ジョブ処理終了後、ジョブ依頼メッセージの送信元であるクライアントノードにジョブ処理結果を応答する。ジョブ処理結果を受信したクライアントノードは、他サーバノードから受信したジョブ処理結果、また自ノードのジョブ処理結果を集計し、ジョブ依頼元へ応答する。
【０１５６】
図２７はジョブ処理サーバがジョブ処理を完了し、処理結果をクライアントノードへ返す様子を示す図である。サーバノード５７、５８はジョブを終了するとジョブ依頼を受けたサーバノード５６へジョブ処理結果メッセージを送信する（矢印ｈ１、ｈ２）。ジョブ処理結果メッセージを受信したサーバノード５６は、ジョブ処理結果メッセージを統合し、ジョブクライアントノードへ送信する（矢印ｈ３）。
【０１５７】
以上説明したように、ネットワークシステム１では、スケジューラを必要とせず、アドホックグリッドサービスの利用を必要とする状況に応じて、アドホック的にジョブを依頼可能なノードを召集し、ジョブを依頼する構成とした。
【０１５８】
これによりアドホック網上で、処理能力、消費電力、ネットワーク帯域等の観点から効率的にグリッドサービス環境を構築でき、アドホック網上に存在する多数の計算資源を共有して、仮想的に強力な計算能力を利用できるようになる。
【０１５９】
また、ネットワークシステム１のアドホック網の性質を利用して、空間的に広範囲をカバーするセンサや、ノードの利用者や存在位置を反映した多種多様なデータソースとして利用することができる。
【０１６０】
さらに、アドホック網上での効率的なグリッドサービスの実現により、アドホック網により構成されたセンサネットワーク上で計測情報を収集すると同時に、計測結果を分散処理することや、災害時に構成されたアドホック網上での避難経路シミュレーション、市街地に携帯端末を使ったマーケティングリサーチといった、これまでにないアプリケーションを実行することが可能になる。
【０１６１】
（付記１）  無線ネットワーク上で通信を行うネットワークシステムにおいて、
ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼し、ジョブ処理結果を集計するクライアントノードと、
依頼されたジョブを実行する場合にはサーバ動作となって、前記クライアントノードからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答し、受け入れた場合にはジョブを実行して、処理結果を前記クライアントノードへ送信するサーバノードと、
を有し、固定局を不要として、無線通信により移動可能な複数のノードで構築されたアドホック網上で分散協調処理を行うことを特徴とするネットワークシステム。
【０１６２】
（付記２）  前記サーバノードは、過去に実行したジョブ処理の実行履歴を保持し、前記クライアントノードからの問い合わせに対して、前記実行履歴を応答し、前記クライアントノードは、前記実行履歴にもとづいて、前記サーバノードのジョブ処理の実績を判断して、ジョブ処理の受け入れ可能なノードを決定することを特徴とする付記１記載のネットワークシステム。
【０１６３】
（付記３）  前記サーバノードは、自ノードのバッテリ残余時間を計測し、前記クライアントノードからの問い合わせに対して、前記バッテリ残余時間を応答し、前記クライアントノードは、前記バッテリ残余時間にもとづいて、前記サーバノードでのバッテリ切れによるジョブ処理のシャットダウンを予測して、ジョブ処理の受け入れ可能なノードを決定することを特徴とする付記１記載のネットワークシステム。
【０１６４】
（付記４）  前記サーバノードは、過去のジョブ実行履歴にもとづいて、ジョブ処理への参加意思を動的に求め、前記クライアントノードからのジョブ実行依頼に対して、ジョブ処理を受け入れ可能かを応答することを特徴とする付記１記載のネットワークシステム。
【０１６５】
（付記５）  前記クライアントノード及び前記サーバノードは、他ノードの前記アドホック網の参加・離脱により生じるネットワークトポロジの変化を検出して、経路の導出を行い、ノードのネットワーク接続状況を確認することを特徴とする付記１記載のネットワークシステム。
【０１６６】
（付記６）  前記サーバノードは、前記クライアントノードからの依頼されたジョブを受信した場合に、依頼されたジョブを実行できなくなった場合は、依頼を受けたジョブの全部または一部を、他のノードに分配・転送することを特徴とする付記１記載のネットワークシステム。
【０１６７】
（付記７）  前記クライアントノードと前記サーバノードとのネットワーク接続性が失われた場合は、複数ノードからのジョブ処理結果を、ジョブ依頼元の前記クライアントノード以外のノードが受信した上で集計して一定時間バッファリングし、一定時間内にネットワーク接続性が回復された場合に、元の前記クライアントノードへ処理結果を送信することを特徴とする付記１記載のネットワークシステム。
【０１６８】
（付記８）  前記クライアントノード及び前記サーバノードは、自ノードのバッテリ電力を節約し、かつオーバヘッドを削減するために、ノード間での認証処理を省いてノード間で通信を行うことを特徴とする付記１記載のネットワークシステム。
【０１６９】
（付記９）  前記クライアントノードは、センサ機能を有し、センサで測定した測定情報の処理を前記サーバノードへ依頼し、処理結果を集計することを特徴とする付記１記載のネットワークシステム。
【０１７０】
（付記１０）  無線ネットワーク上で通信を行う移動通信ノードにおいて、
クライアントから依頼を受けたジョブを処理するグリッドジョブ処理部と、
ジョブの実行を依頼する場合にはクライアント動作となって、他のノード群に対し、処理能力及び参加意思を問い合わせ、応答内容にもとづいて、ジョブ処理の受け入れ可能なノードを決定して、ジョブの実行を分配・依頼及びジョブ処理結果を集計し、依頼されたジョブを実行する場合にはサーバ動作となって、前記クライアントからの問い合わせに対して、処理能力及び参加意思により、依頼されたジョブの実行を受け入れるか否かを応答するジョブ管理部と、
ジョブ実行に必要なノードのリソースを管理し、かつ過去のジョブ実行履歴にもとづいて、ジョブ処理への参加意思を動的に求めるリソース管理部と、
を有し、固定局を不要として、無線通信により移動可能な複数のノードで構築されたアドホック網上で分散協調処理を行うことを特徴とする移動通信ノード。
【０１７１】
（付記１１）  前記ジョブ管理部は、サーバ動作時は、過去に実行したジョブ処理の実行履歴を保持し、クライアントからの問い合わせに対して、実行履歴を応答し、クライアント動作時は、前記実行履歴にもとづいて、サーバのジョブ処理の実績を判断して、ジョブ処理の受け入れ可能なノードを決定することを特徴とする付記１０記載の移動通信ノード。
【０１７２】
（付記１２）  前記ジョブ管理部は、サーバ動作時、自ノードのバッテリ残余時間を計測し、クライアントからの問い合わせに対して、前記バッテリ残余時間を応答し、クライアント動作時は、前記バッテリ残余時間にもとづいて、サーバでのバッテリ切れによるジョブ処理のシャットダウンを予測して、ジョブ処理の受け入れ可能なノードを決定することを特徴とする付記１０記載の移動通信ノード。
【０１７３】
（付記１３）  他ノードの前記アドホック網の参加・離脱により生じるネットワークトポロジの変化を検出して、経路の導出を行い、ノードのネットワーク接続状況を確認するアドホック網プロトコル処理部をさらに有することを特徴とする付記１０記載の移動通信ノード。
【０１７４】
（付記１４）  前記ジョブ管理部は、サーバ動作時、クライアントからの依頼されたジョブを受信した場合に、依頼されたジョブを実行できなくなった場合は、依頼を受けたジョブの全部または一部を、他のノードに分配・転送することを特徴とする付記１０記載の移動通信ノード。
【０１７５】
（付記１５）  前記ジョブ管理部は、ノード間のネットワーク接続性が失われた場合は、複数ノードからのジョブ処理結果を、ジョブ依頼元のクライアント以外のノードが受信した上で集計して一定時間バッファリングし、一定時間内にネットワーク接続性が回復された場合に、元のクライアントへ処理結果を送信する制御を行うことを特徴とする付記１０記載の移動通信ノード。
【０１７６】
（付記１６）  前記ジョブ管理部は、自ノードのバッテリ電力を節約し、かつオーバヘッドを削減するために、ノード間での認証処理を省いたノード間での通信を行うことを特徴とする付記１０記載の移動通信ノード。
【０１７７】
（付記１７）  センサ機能をさらに有し、前記ジョブ管理部は、センサで測定した測定情報の処理を前記サーバノードへ依頼し、処理結果を集計することを特徴とする付記１０記載の移動通信ノード。
【０１７８】
（付記１８）  クライアント上のアドホック網プロトコルにより、ノード上に生成され保持される情報をもとに自ノードのネットワークへの接続状況の変化を判断し、クライアントがどのノードにジョブを依頼するかを判断する移動通信制御方法。
【０１７９】
（付記１９）  ノード上のルーチングプロトコルにより生成され保持される情報をもとに、クライアントのネットワークへの接続状況の変化を判断し、ノードがクライアントからのジョブを受け入れ可能かを判断する移動通信制御方法。
【図面の簡単な説明】
【０１８０】
【図１】ネットワークシステムの原理図である。
【図２】ネットワークシステムのサービス動作例を示す図である。
【図３】ノードの構成を示す図である。
【図４】クライアントノードの処理の流れを示す図である。
【図５】サーバノードの処理の流れを示す図である。
【図６】クライアントロール時のジョブ管理部の動作フローを示す図である。
【図７】ジョブ管理表の構成を示す図である。
【図８】サーバロール時のジョブ管理部の動作フローを示す図である。
【図９】ジョブ履歴表の構成を示す図である。
【図１０】アドホック網プロトコル処理部が有する経路表を示す図である。
【図１１】リソース管理表保持部の構成を示す図である。
【図１２】リソース管理部の探索時の動作フローを示す図である。
【図１３】リソース管理部のノード監視時の動作フローを示す図である。
【図１４】リソース管理部のサーバ探索応答処理時の動作フローを示す図である。
【図１５】アドホック網の構成を示す図である。
【図１６】ブロードキャストメッセージの送信の様子を示す図である。
【図１７】アドホックグリッドサービス上で交換されるプロトコルメッセージのフォーマットを示す図である。
【図１８】メッセージボディの詳細を示す図である。
【図１９】メッセージボディの詳細を示す図である。
【図２０】ジョブサーバ要請メッセージの送信の様子を示す図である。
【図２１】ジョブサーバ要請応答メッセージの送受信の様子を示す図である。
【図２２】クライアントノードとサーバノードの間のジョブ要請・応答の送受信の様子を示す図である。
【図２３】クライアントノードとサーバノードの間のジョブ要請・応答の送受信の様子を示す図である。
【図２４】クライアントからのジョブ依頼の様子を示す図である。
【図２５】サーバによるジョブ実行中の監視処理の様子を示す図である。
【図２６】サーバによる復旧処理の様子を示す図である。
【図２７】ジョブ処理サーバがジョブ処理を完了し、処理結果をクライアントノードへ返す様子を示す図である。
【符号の説明】
【０１８１】
１  ネットワークシステム
１ａ  アドホック網
２０ｃ  クライアントノード
２０ｓ−１〜２０ｓ−ｎ  サーバノード
【図１】
2006201896.tif 000003
【図２】
2006201896.tif 000004
【図３】
2006201896.tif 000005
【図４】
2006201896.tif 000006
【図５】
2006201896.tif 000007
【図６】
2006201896.tif 000008
【図７】
2006201896.tif 000009
【図８】
2006201896.tif 000010
【図９】
2006201896.tif 000011
【図１０】
2006201896.tif 000012
【図１１】
2006201896.tif 000013
【図１２】
2006201896.tif 000014
【図１３】
2006201896.tif 000015
【図１４】
2006201896.tif 000016
【図１５】
2006201896.tif 000017
【図１６】
2006201896.tif 000018
【図１７】
2006201896.tif 000019
【図１８】
2006201896.tif 000020
【図１９】
2006201896.tif 000021
【図２０】
2006201896.tif 000022
【図２１】
2006201896.tif 000023
【図２２】
2006201896.tif 000024
【図２３】
2006201896.tif 000025
【図２４】
2006201896.tif 000026
【図２５】
2006201896.tif 000027
【図２６】
2006201896.tif 000028
【図２７】
2006201896.tif 000029