(57)【要約】【課題】  センサノードの低電力性能を保ちながら、同時に複数データ送達の際の応答性能の向上をも実現する。【解決手段】  間欠動作型無線通信端末への複数データの送信に先立ち、複数データ送信開始メッセージを送信し、複数データの送信が完了した際には複数データ送信終了メッセージを送信する。上記複数データ送信開始メッセージを受信した端末は上記間欠動作の休眠時間をより短い休眠時間に切り替えて動作する。【選択図】  図４
2008072415.tif 000002
【特許請求の範囲】
【請求項１】
センサノード宛のデータを保持する記憶部と、基地局とデータ送受信を行う送受信部とを有するサーバと、
上記サーバに接続され、かつ、上記センサノードと無線接続される中間装置と、上記中間装置に送受信部を介して接続され、処理部に電源の供給される動作期間と、電源の供給されない第１の休眠期間とを繰り返す間欠動作を行うセンサ端末を備えるセンサネットシステムであって、
上記サーバは、上記記憶部に連続した複数のデータを記憶する場合に、送受信部を介して複数データ送信開始メッセージを送信し、
上記送信開始メッセージを上記中間装置を介して受信した上記センサ端末は、上記第１の休眠期間をより短い第２の休眠期間に切り替えて、以降、該第２の休眠期間の休眠後に上記中間装置にポーリングを行い、
上記サーバは上記センサ端末から上記ポーリングを上記中間装置を介して受信した場合に該複数データを逐次該送信部を介して送出し、
該複数データの送信の完了時に複数データ送信終了メッセージを送信し、
該複数データ送信終了メッセージを受信した上記センサ端末は上記第２の休眠時間を上記第１の休眠期間に切り替えることを特徴とするセンサネットシステム。
【請求項２】
上記センサ端末は上記動作期間にセンシングを行ってデータを生成し、
上記送信開始メッセージの受信後の動作期間には該センシング動作を行わないことを特徴とする請求項１記載のセンサネットシステム。
【請求項３】
上記センサ端末は、上記休眠期間に動作する第２の送受信部を有し、
前記第２の送受信部が上記複数データ送信開始メッセージを受信すると、
該センサ端末は動作期間に移行するように制御されることを特徴とする請求項１記載のセンサネットシステム。
【請求項４】
上記サーバの記憶部は、上記複数のデータを上記センサ端末の識別子と対応づけて記憶することを特徴とする請求項１又は２に記載のセンサネットシステム。
【請求項５】
上記センサ端末は上記サーバからのデータを受信すると該データの識別情報を含む受信確認応答を送出し、
該サーバは該受信確認応答の受信および照合によって該データの送達完了を判定することを特徴とする請求項１乃至４の何れかに記載のセンサネットシステム。
【請求項６】
上記サーバは、上記受信確認応答を所定時間内に受信しなかった場合に、該受信確認応答に対応する上記データを上記送受信部を介して再送し、
上記所定期間内に上記受信確認応答を受信できた場合には該データの送信手順を停止し次のデータの送信手順を開始することを特徴とする請求項５記載のセンサネットシステム。
【請求項７】
上記サーバは上記再送を所定回数以上行っても受信確認応答が得られない場合には、該データの再送手順を停止し、送信失敗を表す情報を生成した後に、次のデータの送信手順を開始することを特徴とする請求項６記載のセンサネットシステム。
【請求項８】
上記サーバは上記記憶部に１のセンサ端末宛のデータが複数格納されると、上記複数データ送信開始メッセージを生成し、
上記記憶部に、該センサ端末あてのデータがなくなった時点で上記複数データ送信終了メッセージを生成することを特徴とする請求項1乃至７の何れかに記載のセンサネットシステム。
【請求項９】
上記サーバは、上記センサノードの識別子と、該センサノードの通信用アドレス、所属するネットワーク、基地局の通信用アドレスを対応づけて管理し、
上記複数のデータ、上記複数データ送信開始メッセージ及び上記複数データ送信終了メッセージに上記センサノードの通信用アドレス、所属するネットワーク、基地局の通信用アドレスを付与して送出することを特徴とする請求項1乃至８の何れかに記載のセンサネットシステム。
【請求項１０】
上記基地局は、上記センサノードの接続を検出した時か、上記センサノードが送信した上記サーバあてのデータを受信した時の少なくともいずれかに、上記センサノードの通信用アドレス、上記基地局の通信用アドレスを上記サーバに通知することを特徴とする請求項９に記載のセンサネットシステム。
【請求項１１】
上位装置と無線を介して接続されるセンサ端末であって、
上記上位装置と接続される送受信部と、
センシングデータを取得するセンサと、
上記各部を制御する制御部と、
上記各部に電源を供給する電源と、を有し、
上記電源からの電源が各部に供給され上記センサによるセンシングが行われる動作期間と、該電源が供給されない休眠期間とを交互に第１の所定期間で繰り返すものであって、
上記送受信部を介して複数データ送信開始メッセージを受信すると、
上記制御部は上記休眠期間の時間を、予め設定される上記第１の所定期間より短い第２の所定期間に切り替え、
上記送受信部を介して複数データ送信終了メッセージを受信すると、
上記制御部は上記休眠期間の期間を上記第１の所定期間に切り替えることを特徴とするセンサノード。
【請求項１２】
上記第２の所定時間に切り替わっている間の上記動作期間においては上記センシングを行わないことを特徴とする請求項１０記載のセンサノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、小型低電力無線端末、特にセンサネットワークを構成するセンサノードにおける双方向データ通信技術に関する。
【背景技術】
【０００２】
近年急速に注目が集まっている技術にセンサネットワークがある。センサネットワーク技術を適用することで、現実世界の情報を準リアルタイムにセンシングし、電子的な情報としてITシステムに取り込むことを可能とする。多様なアプリケーションが考案されつつあり、来たるべきユビキタス社会を根底で支える次世代IT技術として期待されている。
【０００３】
センサネットワークにおけるキーデバイスは、小型、低消費電力を特徴とする無線センサノードである。小型であるが故に環境や人を含むあらゆるモノへ付けることが可能となり、低電力であるが故に外部給電することなく電池で数年間稼動させることができる。さらに無線で通信するが故に、基地局または中継ノードを介して広範囲へ配置することが可能である。
【０００４】
センサノードにおける特徴的な動作として、間欠動作がある。これは、センシングやデータ送信のようなタスクを実行する時のみ必要なハードウェアを駆動し、実行すべきタスクがない時はセンサ、RF等の周辺ハードウェアは完全に停止し、マイコンも低電力モードでスリープさせるという動作である。間欠動作を行うことにより、センサノードは、限られたバッテリの下で長時間動作が可能となる。
【０００５】
上記のような間欠動作を行うセンサノードにおいては、低消費電力化を進めれば進めるほどスリープしている時間の割合が増大するので、センサノードがデータを受信することのできるタイミングはスリープ時間の合間に現れるごく短い起動時間の間だけとなってくる。間欠動作を行う小型、低消費電力のセンサノードにおいていかに効率良くデータを送信するかが、システムとしての性能に重要な影響を与える。これに関連して、例えば送信側端末が次回にデータを送信する予定時刻を受信側端末に通知することによってスリープ時間の制御を行う技術がある（例えば、特許文献１）。
【０００６】
【特許文献１】特開2004-320153号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら前記特許文献１の方法では、受信側端末の起動時間を短くすればするほど送信側端末と受信側端末の間の時刻同期に高い精度が要求されてしまう。これは技術的な困難さ、またはハードウェアのコスト増大に繋がってしまう。また、受信端末宛てのデータ（例えばセンシングの即時実行を指令するコマンド）は、アプリケーションユーザやシステム管理者の都合によってどんなタイミングでも発生し得るため、予め次回データ送信予定時刻を指定してもその時刻に実際にセンサノード宛てのデータが発生するとは限らない。よって、予め計画した時刻にデータを送信するとは限らず、効率的なデータ送達は困難になる。
【０００８】
また、特許文献１とは異なり、スリープ時間の制御を行わない代わりに、センサノードが起動時間においてポーリングを行い、自分宛てのデータを自発的に取得する方法も考えられる。しかしながらこの方法では、センサノードに対して複数のデータを送信しようとすると、1つ1つのデータの送達を完了する毎にセンサノードはスリープ状態へ入ってしまうことになり、結果的にセンサノードの間欠動作の周期毎に１つずつのデータしか送達できないことになってしまう。これでは全部のデータの送達が完了するまでの時間がかかりすぎ、システムとしての実用的な応答時間を得ることができない。
【０００９】
そこで本発明は上記問題点に鑑みてなされたものである。本発明は、センサノードの低消費電力性能を維持しつつ、センサノード宛のデータをより効率良く送信する技術を開示することを目的とする。
【課題を解決するための手段】
【００１０】
本願で開示する代表的な発明は以下の通りである。本発明は、複数データの送信に先立って、送信元ノードがセンサノードへ複数データの送信を開始することを意味するデータを送信することを特徴とするものである。具体的には、センサノード宛のデータを保持する記憶部と、基地局とデータ送受信を行う送受信部とを有するサーバ。サーバに接続され、かつ、上記センサノードのデータと無線接続される中間装置。中間装置に送受信部を介して接続され、処理部に電源の供給される動作期間と、電源の供給されない休眠期間とを繰り返す間欠動作を行うセンサ端末を備えるセンサネットシステムである。特にサーバは、上記記憶部に連続した複数のデータを記憶する場合に、送受信部を介して第１に複数データ送信開始メッセージを送信し、送信開始メッセージを上記中間装置を介して受信した上記センサ端末は、上記休眠期間をより短い所定期間に切り替えて、以降、該所定期間経過後に上記中間装置にポーリングを行い、サーバは上記センサ端末から上記ポーリングを上記中間装置を介して受信した場合に該複数データを該送信部を介して送出し、複数データの送信の完了時に複数データ送信終了メッセージを送信する。
【発明の効果】
【００１１】
従って、本発明は、通常状態においてスリープ時間の長いセンサノードに対して、センサノードの低消費電力性能を保ちながら、同時に複数データ送達の際の応答性能の向上をも実現することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００１３】
＜図４＞システム全体構成
図４は、本発明の主要な適用先であるセンサネットシステムの一例を示すシステム全体構成図である。産業上の利用としては、ビル全体の空調管理、工場における製造工程の監視、有毒ガスや火災の検知、幹線道路や工事現場の周辺での騒音測定、等への適用が可能である。
【００１４】
＜図５＞センサノードSS1構成
図５は、センサノードSS1のハードウェア構成を示した図である。バッテリ部Batteryは、センサノードSS1の各ハードウェア部へ電力を供給するためのデバイスである。通常の一次電池、充電可能な二次電池、あるいは太陽電池や振動発電装置のような自己発電デバイスを使用することができる。
【００１５】
マイクロプロセッサMicroProcessorは、センサノードSS1全体の動作を制御する。後述の読み出し専用メモリRead-Only Memoryからプログラムコードを読み込み実行することにより、図８、図９、図１０に示すような、本発明に基づくセンサノードSS1の動作を実現する。なお、本発明において特徴的な役割を果たすにマイクロプロセッサMicroProcessor中の要素機能部として、割り込み制御部Interrupt Controllerとタイマ部Timerが挙げられる。割り込み制御部Interrupt Controllerは、ハードウェア割り込みと呼ばれる機能を実現する機能部であって、周辺の機能部からの割り込み信号を受け付けると即時的に対応するプログラムコードを起動することができる。タイマ部Timerは、時間を測定するための機能部であって、指定された時間が経過すると割り込み信号を発生することができる。本発明においては、スリープ期間中には割り込み制御部Interrupt Controllerとタイマ部Timer以外の全ての機能部への電力供給を停止しておき、タイマ部が定期的に発生する割り込み信号を、割り込み制御部Interrupt Controllerが受信することを契機としてマイクロプロセッサMicroProcessor全体への電源供給を再開するといった利用ができる。
【００１６】
センサノードSS1の記憶装置は、揮発性メモリVolatile Memory、不揮発性メモリNonvolatile Memory、読み出し専用メモリRead-Only Memoryとから構成される。揮発性メモリVolatile Memoryは、ランタイムデータを一時的に格納するためのメモリであり、例えば送受信時のパケットを保持するバッファ領域が確保される。揮発性メモリVolatile Memoryは、電力が給電されている期間のみデータを保持するので、バッテリ部Batteryからの給電が停止したり、パワーオンリセットが発生した際等には、それまで保持していたデータは失われる。デバイスとしてはSRAM、DRAM等が使用可能である。一方、不揮発性メモリNonvolatile Memoryは、一度書き込んだデータは電力の給電がなくなっても保持し続けるので、動作時に長期間保持しておくべきデータを保持する用途で使用される。例えば、電波状態が悪く、センシングしたデータを長期間送信できない場合に、数十回分あるいは数百回分の測定データを保持する用途で用いることができる。また、運用の最初に一度だけ設定し、その後は長期間同じ値で運用し続けるようなランタイムパラメータ、例えばセンシングの周期等のパラメータを保持するのに用いることができる。デバイスとしてはEEPROM等が使用可能である。不揮発性メモリNonvolatile Memoryは読み書きの時以外には電力供給が不要なため、データを長期間保持する際には揮発性メモリVolatile Memoryよりも電力消費が節約されるというメリットがある。また、バッテリ部Batteryを交換したり、パワーオンリセットが発生した場合でもデータが失われないというメリットがある。一方、読み出し専用メモリRead-Only Memoryは、製造工程や保守工程においてはデータの書き込みまたは書き換えが可能であるが、運用時にはデータの読み出しのみに使用する記憶領域であり、プログラムコードや固定的な動作パラメータが格納される。デバイスとしてはフラッシュROM等が使用可能である。
【００１７】
無線通信部は、無線送受信部RF Transceiverと無線受電受信部RF Receiver (Aerial Fed)とから構成される。無線送受信部RF Transceiverは、通常のデータパケットの送受信の際に使用される。無線受電受信部RF Receiver (Aerial Fed)は、データ受信機能に加えて、電磁誘導等の原理に基づく無線給電機能を備えた回路であって、バッテリ部Batteryからの給電を受けることなく所定の周波数帯のデータを受信することができる。無線受電受信部RF Receiver (Aerial Fed)の具体的な構成方法としては、図中に示したように、パッシブ無線タグPassive RFIDと電圧レベル変換回路Level Converterを用いた構成が可能である。無線受電受信部RF Receiver (Aerial Fed)がデータを受信すると、まず割り込み制御部Interrupt Controllerへと割り込み信号IRが入力される。これにより、マイクロプロセッサMicroProcessorはたとえスリープ状態にあったとしても速やかに通常動作へと復帰し、受信データを読み出すことができる。
【００１８】
操作ボタンButtonは、ユーザの操作を受け付ける入力デバイスであり、特定のボタン操作により、センサノードSS1の特定の動作を起動したり、動作パラメータを設定したりすることができる。操作ボタンButtonからの信号は割り込み制御部Interrupt Controllerへと入力されるので、マイクロプロセッサMicroProcessorがスリープ状態にある時でも、ボタン操作に対応する処理は即時的に起動される。
【００１９】
表示部Displayは、ユーザに対して情報を表示するための出力デバイスである。例えば、センサノードSS1が環境計測用に室内または室外に設置する用途である場合には、センサ部Sensor(s)により計測した最新の測定値を表示することができる。その際、低電力化のために、通常時は何も表示せず、特定のボタン操作を行った時のみ、該最新測定値を表示するといった活用が好適である。また、センサノードSS1が名札型や腕時計型等の携帯端末である場合には、通常時は時刻情報を表示し、ミドルウェアサーバMiddleware Serverからテキストメッセージを受信した場合には該メッセージを表示したり、音声メッセージを受信した際には該着信情報を表示するといった活用が好適である。また、ユーザのボタン操作に連動して、階層化された操作メニューを表示することができる。該操作メニューに従ってボタン操作を行うことにより、アプリケーションユーザApplication Userやシステム管理者System Managerは、センサノードの動作パラメータを設定したり、通信失敗時のエラー情報を確認したりすることができる。  センサ部Sensor(s)は、対象の状態を測定するためのデバイスである。具体的には、温度、湿度、加速度、振動、ひずみ等の物理量を測定するための小型センサデバイスが使用可能である。なお、赤外線フォトリフレクタのように、信号を発信する機能と、受信する機能の両方を備えたセンサデバイスもある。
【００２０】
マイク部Microphoneは、上記センサ部Sensor(s)のうち、音声、すなわち空気振動を測定するためのデバイスである。またスピーカ部Speakerは、音声を出力するためのデバイスである。マイク部Microphoneやスピーカ部Speakerは、センサノードSS1が名札型や腕時計型等の携帯端末である場合に、他のセンサノードやPC上のアプリケーション端末（図４中のApplication Client(s)）との間で音声メッセージを送受する用途に使用することができる。
【００２１】
本図で示した各ハードウェア機能部と、図４中で示したセンサノードSS1の機能構成との対応関係について述べる。図４中のセンサノードSS1内の下半分に示した、左上隅に黒い印を付した5つの機能ブロックは、図５に示したハードウェア機能部のうちの、本発明に特徴的な役割を果たすものを特に抽出して示したものである。ただし、図４の表示スペースの都合により、図５中のVolatile Memoryは図４中ではRAMと、図５中のRF Receiver (Aerial Fed)は図４中ではRFID (RF Receiver)と表記している。また、図４中のセンサノードSS1内の上半分に示した４つの機能部は、それぞれソフトウェア機能を表している。図５との関係では、プログラムコードの形で読み出し専用メモリRead-Only Memory中に格納され、運用時にはマイクロプロセッサMicroProcessorによって読み出され、実行される。またこれらのランタイムデータは揮発性メモリVolatile Memoryや不揮発性メモリNonvolatile Memory上に保持される。これらソフトウェア機能部の機能詳細については後述する。
【００２２】
＜図６＞ルータノードRT1構成。
図６は、ルータノードRT1のハードウェア構成を示した図である。ルータノードRT1は、いつ送信されてくるか分からない、センサノードSS1やゲートウェイノードGW1からのデータを常時待ち受けていなければならないので、センサノードSS１と異なり、バッテリではなく外部給電により動作する。電源線Power Lineより供給される電力を、電源回路Power Supply Circuitにより整流等を行った上で各機能部へ供給する。
【００２３】
消費電力の心配をする必要がないため、マイクロプロセッサはセンサノードSS1の場合のようにスリープ状態に入る必要はない。そのため割り込み制御部Interrupt Controllerやタイマ部Timerは図中では省略してあるが、これらの機能は一般的なデータ送受信アルゴリズムの範囲内で活用される。
【００２４】
無線通信部は、無線送受信部RF Transceiverと無線送電送信部RF Transmitter (Aerial Feeding)とから構成される。無線送受信部RF Transceiverは、センサノードSS1の場合と同様、通常のデータパケットの送受信の際に使用される。無線送電送信部RF Transmitter (Aerial Feeding)は、データ送信機能に加えて、電磁誘導等の原理に基づく無線送電機能を備えた、RFIDリーダ等が備えるのと同様の回路である。無線送電送信部RF Transmitter (Aerial Feeding)から送信されたデータは、センサノードSS１がスリープ状態であったとしても、無線受電受信部RF Receiver (Aerial Fed)により受信されることができる。
【００２５】
ルータノードRT1は、揮発性メモリVolatile Memoryまたは不揮発性メモリNonvolatile Memory上に、自分の配下のセンサノード毎に少なくとも1つのデータをバッファリングするためのデータバッファData Bufferを備える。ルータノードRT1の場合は配下のセンサノードはセンサノードSS1のみであるが、例えばルータノードRT4であれば配下のセンサノードは2台、ルータノードRT7であれば配下のセンサノードは3台であるので、データバッファData Bufferは各々のセンサノード毎に独立に管理される。なお、データバッファData Bufferの物理的な実現形態としては、各センサノード毎に物理的に独立したメモリ領域が割り当てられても良いし、全てのセンサノード宛てのデータを共通のメモリ領域に格納しつつも、各々のデータに対して、宛て先となるセンサノードを表す識別情報と、同一の宛て先となるデータ間での送信順序を表す識別情報とが対応付けられて管理されていても良い。また、上記のいずれの実現形態であっても、データバッファData Bufferは本来的に、配下のセンサノードの一覧を管理するテーブル情報としての役割を果たすことができる。しかしながら、配下のセンサノードの一覧情報は、下りデータをバッファリングするというデータバッファData Buffer本来の役割とは異なる場面においても参照する頻度の高いデータである。例えばルータノードRT4の場合、配下に持つのはセンサノードSS5とSS6であるのでこれらのノードが送信したデータについては、責任を持って転送等の処理を行う必要がある。一方で、たまたま近隣に位置するが自身の配下でないセンサノードSS4が送信したデータを受信した場合には、通信帯域の節約やセキュリティ保護の観点から、ルータノードRT4は本データの転送等を行うべきではない。このように、受信したパケットを処理するか否かの判定を行うために、配下のセンサノードの一覧情報は頻繁に参照される。本参照処理を高速化したり、上り通信の処理と下り通信の処理を独立化したりする目的で、この一覧情報を上記データバッファData Bufferとは独立のテーブル情報として管理するといった実施形態も考えられる。
【００２６】
その他、表示部Display、操作ボタンButton、センサ部Sensor(s)のように、センサノードSS1と同等の入出力デバイスを備えていても構わない
本図で示した各ハードウェア機能部と、図４中で示したルータノードRT1の機能構成との対応関係について述べる。図４中のルータノードRT1内の下側に示したRAMと表記した機能ブロックは、図６に示したハードウェア機能部のうちで本発明において最も特徴的な役割を果たす、揮発性メモリVolatile Memoryを示している。また、図４中のルータノードRT1内の上側に示した２つの機能部は、それぞれソフトウェア機能を表している。図６との関係では、プログラムコードの形で読み出し専用メモリRead-Only Memory中に格納され、運用時にはマイクロプロセッサMicroProcessorによって読み出され、実行される。またこれらのランタイムデータは揮発性メモリVolatile Memoryや不揮発性メモリNonvolatile Memory上に保持される。これらソフトウェア機能部の機能詳細については後述する。
【００２７】
＜図７＞ゲートウェイノードGW1構成。
図７は、ゲートウェイノードGW1のハードウェア構成を示した図である。ゲートウェイノードGW1は、IP Networkを介してミドルウェアサーバMiddleware Serverと通信を行うためのLAN通信インタフェースLAN I/Fを備える以外は、ルータノードRT1の構成と同様である。なお、ゲートウェイノードGW1は、図４中のGW2として示したように、ルータノードRT1と全く同様の機能、すなわち1つ以上のセンサノードの親となる機能を有している。従って、ゲートウェイノードGW1が自身の配下にセンサノードを有した場合には、図６に示したのと同様に、揮発性メモリVolatile Memoryまたは不揮発性メモリNonvolatile Memory上に、自分の配下のセンサノード毎に少なくとも1つのデータをバッファリングするためのデータバッファData Bufferを保持することができる。
【００２８】
本図で示した各ハードウェア機能部と、図４中で示したゲートウェイノードGW1の機能構成との対応関係について述べる。図４中のゲートウェイノードGW1内の下側に示したRAMと表記した機能ブロックは、図７に示したハードウェア機能部のうちで本発明において最も特徴的な役割を果たす、揮発性メモリVolatile Memoryを示している。また、図４中のゲートウェイノードGW1内の上側に示した４つの機能部は、それぞれソフトウェア機能を表している。図７との関係では、プログラムコードの形で読み出し専用メモリRead-Only Memory中に格納され、運用時にはマイクロプロセッサMicroProcessorによって読み出され、実行される。またこれらのランタイムデータは揮発性メモリVolatile Memoryや不揮発性メモリNonvolatile Memory上に保持される。これらソフトウェア機能部の機能詳細については後述する。
【００２９】
ミドルウェアサーバMiddleware Serverのハードウェア構成に関しては、LAN通信インタフェースを備えた一般的なPCサーバあるいはワークステーションの構成で構わないので、特に図面は示していない。図４中では、ミドルウェアサーバMiddleware Serverのソフトウェア構成を示している。
【００３０】
データ管理部Data Managerは、センサノードの収集した測定データを、設置位置や意味情報との関連付けにおいて管理する機能部である。本機能部にアクセスすることにより、アプリケーションユーザApplication Userは例えば「生成食料品を保存する冷蔵室Aの、8月1日の温度履歴」といった意味情報にアクセスすることができる。
【００３１】
オブジェクト管理部Object Managerは、データ管理部Data Managerが管理する意味情報の元となる、センサや測定データに対する識別情報を管理する機能部である。例えば図１４に後述するような、センサノードSS1をシステム内で一意に識別するためのテーブルを生成管理したり、各々の測定データを固有の識別情報で管理し、さらに冷蔵室A内に設置された複数のセンサノードの測定データをグループ化するといった機能を提供する。
【００３２】
コマンド管理部Command Managerは、ミドルウェアサーバMiddleware Serverがセンサノード宛ての下りデータを送信する際、そのデータ送信を制御する機能部である。下りデータの種類としては、センサノードの動作パラメータを設定するような「設定コマンド」以外にも、スピーカ部Speakerを備えた端末型センサノードへ対する音声メッセージのようなデータも含まれる。ただしセンサネットのように上り通信が主体となるような通信ネットワークにおいては、下り通信データはその具体的な内容に関わらず「コマンド」と総称される場合がある。「コマンド管理部Command Manager」も、その慣習に従った名称を付したものである。
【００３３】
無線ネットワーク管理部PAN Managerは、PAN（Personal Area Network）と呼ばれる無線ネットワークの構成情報として、図１４において説明するノード管理テーブルを保持・管理し、コマンド管理部Command Managerから渡された下りデータに該テーブルから得た情報を付加する機能部である。
【００３４】
イベント発行部Event Publisherは、ミドルウェアサーバMiddleware Serverが送受する全てのデータに対して、対応する処理部への振り分けを行う機能部である。
【００３５】
プロファイルアダプタProfiled Adapterは、ミドルウェアサーバMiddleware Serverが送受する全てのデータに対して、ミドルウェアサーバMiddleware Server内でのデータ形式と、各通信相手に特化したデータ形式とを相互に変換する機能部である。
【００３６】
IP通信部IP Communicatorは、ミドルウェアサーバMiddleware ServerがLAN通信インタフェースを介して各々の通信機器と通信を行う際に、各通信相手に特化した通信プロトコルを実行するための機能部の総称であり、個別のプロトコルアダプタを含む。図中では、代表的なプロトコルアダプタを6つ示している。ZigBeeAdapterは、ゲートウェイノードGW1〜GW3と通信するためのアダプタである。Client Adapterは、管理用端末Management Clientやアプリケーション端末Application Client(s)と通信するためのアダプタである。Wired-Sensor Adapterは、有線ネットワークを介して接続されたとして接続された有線センサノードWired-Sensorと通信するためのアダプタである。RDB Adapterは、センシングデータの履歴を長期的に保持するためのデータデータベースサーバRDB Serverと通信するためのアダプタである。SMTP Adapterは、システム管理者System ManagerやアプリケーションユーザApplication Userの携帯電話Mobile Phoneに対して重要情報を電子メールの形式で通知するためのアダプタである。RFID Adapterは、無線タグリーダRFID Readerを介して無線タグRFID Tagの情報を取得するためのアダプタである。
【００３７】
図４中、矢印で示しているのは、センサノードSS1が宛先となる場合の、本発明が関係するデータフローである。このうち、(1)〜(4)で示した各矢印群の起点は、複数データの送信源となるデバイスまたは機能ブロックである。
【００３８】
(1)で示した矢印は、システム管理者System Managerが操作する管理用端末Management Clientが複数データの送信源となる場合を示している。このような複数データの例として、例えばセンサノードSS1を最初に現場に設置した際に、間欠動作の周期、通信チャネル、再送回数等の複数のランタイムパラメータの初期設定を、一括して、または対話的に行う場合が挙げられる。
【００３９】
(2)で示した矢印は、アプリケーションユーザApplication Userが操作するアプリケーション端末Application Client(s)が複数データの送信源となる場合を示している。このような複数データの例として、例えばセンサノードSS1が携帯端末型のデバイスであって、アプリケーションユーザApplication Userがアプリケーション端末Application Client(s)を介してセンサノードSS1に対して音声メッセージを送信する場合が挙げられる。音声メッセージのような大容量データは、通常、複数のパケットに分割された上で連続的に送達される。
【００４０】
(3)で示した矢印は、ミドルウェアサーバMiddleware Server内のデータ管理部データ管理部Data Managerが複数データの送信源となる場合を示している。このような複数データの例として、例えば通信環境の悪い状態が継続し、センサノードSS1が測定したデータのうち数十個あるいは数百個がミドルウェアサーバMiddleware Serverに送達されない状態に陥った際、Middleware Serverの側から能動的に測定データの回収を行う場合が挙げられる。
【００４１】
(4)で示した矢印は、他のセンサノード、ここではセンサノードSS2が、複数データの送信源となる場合を示している。このような複数データの例として、例えばセンサノードSS1およびSS2が携帯端末型のデバイスであって、センサノードSS2からセンサノードSS1に対して音声メッセージを送信する場合が挙げられる。
【００４２】
(1)〜(4)の各起点から発行されたデータは、各々の矢印に沿って配送され、Object Managerの位置で合流する。その後は太い矢印で示した共通経路に沿ってセンサノードSS1内タスク管理部Task Managerまで配送される。
【００４３】
確認応答ACKは、矢印で示したのと逆の経路を辿ることによって各起点まで返送される。一般的に確認応答とは、データの送達を示すために、データの受信先が送信元へ返送するパケットであり、シーケンス番号と呼ばれる、確認応答の対象となるデータと同一のデータ識別情報を含むパケットである。一方返戻応答とは、単なる送達確認のみならず、受信側において該データの受信に伴い何らかの処理（センシング処理や動作パラメータ変更）が起動され、その結果を表す情報（成否情報等）を含んだ応答である。本発明ではいずれの場合であっても処理手順に本質的な違いはないため、一般的な確認応答と返戻応答とを総称して確認応答ACKと呼ぶこととする。
【００４４】
図４に示したシステム構成において、発明に特徴的な動作手順は、ミドルウェアサーバMiddleware Server内コマンド管理部Command Managerの保持するデータバッファData Bufferと、ルータノードRT1内のRAMすなわち揮発性メモリVolatileMemoryに確保されるデータバッファData Bufferとの間で、下りデータが調歩同期的に受け渡されながらセンサノードSS1まで送達される際の手順に現れる。ルータノードRT1が保持するデータバッファData Bufferの詳細については図６において既に述べた。コマンド管理部Command Managerが保持するデータバッファData Bufferの詳細については図１１において後述する。2つのデータバッファData Bufferの間の調歩同期的なデータ送受の手順については図９において後述する。
【００４５】
＜図１＞センサノード間欠動作時に、間欠動作を行うセンサノードSSの典型的な動作を図１に示す。図1(A)は、鉛直下向きに時間軸を取っており、該時間軸に沿ってセンサノードSSの動作サイクルを表している。図１(B)は、同じ動作を状態遷移図で表したものである。なお、図１(B)において矢印に付した1行表記の動作は、矢印の基点の状態において発生した状態遷移のトリガとなるイベントを表している。
マイコンが所定のスリープ時間（図中では10分間としている）を満了すると、タイマ部が割り込みを発生させることにより、マイコンは通常動作モードへ復帰する。そして所定の手順に従い、センシングを実行し、センシングしたデータを送信し、自分宛のデータがある場合にはポーリングにより受信し、該データの処理を行う。その時点で実行すべき全てのタスクが終了すれば、再び所定時間のスリープに入る。スリープ期間の合間のタスク処理期間の長さは数10ミリ秒から長くても1秒程度なので、センサノードはほとんどの時間はスリープ状態にあることになる。なお、間欠動作の基本的な特徴は「タスクを実行する必要がない時はスリープする」ことであるので、タスクのスケジューリングの方法によって間欠動作の実施方法には多様な変形が考えられる。例えばセンサノードが複数のセンサを搭載する場合には、センサ毎に別々のセンシング周期を持たせても構わない。また、センシング、データ送信、データ受信の各々は、本来的には独立のタスクであるので、各々のタスク毎に独立の動作周期を持たせても構わない。
【００４６】
ここで、間欠動作を行うセンサノードにおけるデータ受信の方法において、ポーリングにより定期的に自分宛てのデータがあるかどうかを送信元へ問い合わせる方法（ポーリング方式）が消費電力の少なさ、上位装置との同期の不要である点などから有効である。ポーリング方式では、センサノード自身がポーリングしない限りデータが送信されてくることがないので、センサノードは自身の間欠動作周期に従いスリープし、自身の都合の良いタイミングでデータを取得することが可能である。加えて、時刻同期のような複雑な制御が不要であり、低リソースなマイコンでも実装しやすい等、センサノードにおけるデータ受信方法としては非常に好適な特性を備えている。なお、ポーリング方式の場合データがないときであっても送信側への問い合わせを行うことになるが無線通信方式であるZigBeeおよびIEEE802.15.4の場合、送信時と受信時の消費電力は概ね同等であり、ポーリングの際の問合せパケットの送信とそれに対する応答を受信するまでの時間は合わせて1ミリ秒程度である。よって電力消費の増大はごくわずかである。
【００４７】
次に、本願の間欠動作方式およびポーリング方式を備えたセンサノードにおける、データ受信動作について説明する。図２は、図１に示したように間欠動作を行うセンサノードSSにおけるデータ受信動作について説明した図である。なお本図では表記の都合上、スリープ、ポーリング、データ受信以外のセンサノードSSの動作は省略している。前提として、センサノードSSが直接的に通信を行う相手のノードは固定的に決まっているものと想定し、該相手ノードを親ノードと呼ぶこととする。本想定では、センサノードSSと親ノード以外のノードとの通信も、必ず親ノードを経由することにより実現される。またセンサノードSSは同時に複数の親ノードを持つことはできず、親ノードの決定および変更のためには接続手順（Association、Join等と呼ばれる）を実施しなければならない。上記のような一連の想定により、センサノードSS、親ノード、および通信相手におけるデータ送受信手順をシンプルに保つことができる。具体的には、通信相手がセンサノードSSへデータを送信する際には対応する特定の親ノードへ向けて固定的に送信すれば良く、またセンサノードSSが該データを受信する際には該親ノードへ固定的にポーリングを行えば良い。ここで親ノードは、通信相手からセンサノードSSへ宛てたデータを受信し、センサノードがポーリングしてくるまで該データをバッファリングする制御を行う。
【００４８】
さて図２においては、センサノードSSが10分間を周期とする間欠動作を行う場合を示している。まずセンサノードSSがスリープ期間Sleep 1から復帰してタスク処理期間Task Processing 1に入ると、センサノードSSは親ノードParentに対してポーリングPolling 1を行う。この時点では親ノードParentにおいてセンサノードSS宛てのデータは存在しておらず、親ノードParentはセンサノードSSへデータが存在しないことを意味する応答NoData 1を返送する。該応答を受信したセンサノードSSは速やかにスリープ期間Sleep 2へ遷移する。ここで、タスク処理期間Task Processing 1の長さは、センシング、センシングデータの送信、ポーリングといった一連の動作を含めても数ミリ秒から10ミリ秒程度である。
【００４９】
次に、センサノードSSがスリープ期間Sleep 2にある間に、通信相手PeerがセンサノードSS宛てのデータData 1を送信したとする。本データData 1は、親ノードParentにより受信され、センサノードSSがポーリングしてくるまでの間、親ノードParentにおいてバッファリングされる。なお、通信相手Peerと親ノードParentとの間のデータ送達は、シングルホップ通信でも良いが、より一般的には１つ以上のルータノードが介在したマルチホップ通信であっても構わない。その後センサノードSSがスリープ期間Sleep 2から復帰してタスク処理期間Task Processing 2に入ると、センサノードSSは親ノードParentに対してポーリングPolling 2を行う。この時点では親ノードParentにおいてセンサノードSS宛てのデータData 1がバッファリングされているので、親ノードParentはセンサノードSSへ該データData 1を転送する。なお図中では省略しているが、センサノードSSは該データData 1を受信後、該データData 1の内容に応じた処理を行う。例えば該データData 1が動作パラメータの変更のコマンドであった場合には、センサノードSSは該コマンドの指示に従い自身の動作パラメータを変更する。またセンサノードSSが人間が身に付ける情報端末型の装置であって該データData 1が音声メッセージを構成するデータの一部であった場合、センサノードSSは該データData 1を再生バッファに格納するか、または再生処理を行う。このようにしてセンサノードSSが該データData 1を受信し、対応する処理を行った後、センサノードSSはもう一度速やかに親ノードParentに対してポーリングPolling 3を行う。これは、親ノードParentに更なるデータがバッファリングされていないかどうかを確認するためである。この時点では親ノードParentにおいてセンサノードSS宛てのデータはバッファリングされていないので、親ノードParentはセンサノードSSへデータが存在しないことを意味する応答NoData 2を返送する。該応答を受信したセンサノードSSは速やかにスリープ期間Sleep 3へ遷移する。ここで、タスク処理期間Task Processing 2の長さは、タスク処理期間Task Processing 1の長さと比べるとデータData 1に伴う処理の時間が加算されるが、その場合でも合計時間にして10ミリ秒から50ミリ秒程度と、スリープ期間の長さである10分間と比較すれば一瞬と呼んで良い程度に短い期間である。
【００５０】
なお、センサノードSS宛てのデータData 1が送信元の通信相手Peerから送信されてから実際にセンサノードSSによって受信されるまでの所要時間は、親ノードParentにおけるバッファリング期間の長さによって決まる。そして該バッファリング期間は、センサノードSSのポーリング周期と、通信相手PeerがData 1を送信する時刻とのタイミングによって決まる。本例では、センサノードSSのポーリング周期は10分間であるので、該バッファリング時間は最短の場合は0秒間、最長の場合は10分間となる。最短となるタイミングとは、センサノードSSがポーリングPolling 2を行う直前に通信相手PeerがData 1を送信した場合であり、最長となるタイミングとは、センサノードSSがポーリングPolling 1を行った直後か、またはポーリングPolling 2を行った直後かに通信相手PeerがData 1を送信した場合である。
【００５１】
次に、センサノードSSがスリープ期間Sleep 3にある間に、通信相手PeerがセンサノードSS宛てに複数のデータData 2、Data 3、Data 4を順次送信したとする。これら複数のデータは親ノードParentにより受信され、センサノードSSがポーリングしてくるまでの間、親ノードParentにおいて順次バッファリングされ、FIFO方式により管理される。その後センサノードSSがスリープ期間Sleep 3から復帰してタスク処理期間Task Processing 3に入ると、センサノードSSは親ノードParentに対してポーリングPolling 4を行う。この時点では親ノードParentにおいてセンサノードSS宛ての複数のデータData 2、Data 3、Data 4がバッファリングされており、親ノードParentはFIFO方式に従い最初にバッファリングしたData 2をセンサノードSSへ転送する。センサノードSSが該データData 1を受信し対応する処理を行った後、センサノードSSは再び速やかに親ノードParentに対してポーリングPolling 5を行う。この時点で親ノードParentにおいてバッファリングされているのはData 3、Data 4の2つのデータである。親ノードParentはFIFO方式に従い、先にバッファリングしたData 3をセンサノードSSへ転送する。センサノードSSが該データData 3を受信し対応する処理を行った後、センサノードSSは再び速やかに親ノードParentに対してポーリングPolling 6を行う。この時点で親ノードParentにおいてバッファリングされているデータはData 4のみである。親ノードParentは該Data 4をセンサノードSSへ転送する。センサノードSSが該データData 4を受信し対応する処理を行った後、センサノードSSはさらに速やかに親ノードParentに対してポーリングPolling 7を行う。この時点では親ノードParentにおいてセンサノードSS宛てのデータはバッファリングされていないので、親ノードParentはセンサノードSSへデータが存在しないことを意味する応答NoData 3を返送する。該応答を受信したセンサノードSSは速やかにスリープ期間Sleep 4へ遷移する。ここで、タスク処理期間Task Processing 3の長さは、タスク処理期間Task Processing 2の長さと比べるとポーリング回数および受信データ数が多い分だけ長くなるが、長く見積もったとしても合計時間にして数十ミリ秒から100ミリ秒程度であり、スリープ期間の長さである10分間と比較すればやはり一瞬と呼んで良い程度に短い期間である。
【００５２】
なお、センサノードSS宛てのデータData 2、Data 3、Data 4が通信相手Peerから送信されてから実際にセンサノードSSによって受信されるまでの所要時間は、Data 1の場合と同様、親ノードParentにおけるバッファリング期間の長さによって決まり、該バッファリング時間は最短の場合は0秒間、最長の場合は10分間となる。例えばData 2に着目すると、バッファリング時間が最短となるタイミングとは、センサノードSSがポーリングPolling 4を行う直前に通信相手PeerがData 2を送信した場合であり、最長となるタイミングとは、センサノードSSがポーリングPolling 3を行った直後か、またはポーリングPolling 4を行った直後かに通信相手PeerがData 2を送信した場合である。
【００５３】
間欠動作方式およびポーリング方式は、センサノードの低電力化、長寿命化のために必須の技術である。が、マイコンのスリープ中に処理すべきタスクが発生したとしても、マイコンが通常動作モードへ復帰するまでの間は該タスクを処理することができない。このことは特にスリープ中のセンサノードへ宛てた通信（以後「下り通信」と呼ぶ）に関して顕著に現れる。センサノード自身が送信する通信（以後「上り通信」と呼ぶ）に関しては、間欠動作しているとは言え、センサノードは送信するタイミングを自分自身で決めることができるので、基本的には不都合は発生しない。しかしながら下り通信に関しては、図２において示したように、センサノード宛てのデータ（例えばセンシングの実行を指令するコマンド）は、センサノードの間欠動作タイミングとは無関係に、アプリケーションユーザやシステム管理者の都合によってどんなタイミングでも発生し得る。通常運用時のセンサノードのポーリング間隔、すなわちスリープ時間が数分間を超えるような状況では、任意のタイミングで発生し得るデータの送達に関しての即応性を期待することはできない。それでも、図２における複数データData 2、Data 3、Data 4の順次送信のように、連続して複数データを送信する場合には、最悪でもスリープ時間１回分だけ待てば、その時点で発行済みの全てのデータを宛先のセンサノードへ送達することが可能である。しかしながら、複数データの一括送達ができるのは、親ノードParentが複数データをバッファリングできるだけの十分なメモリ容量を備え、かつ該複数データの送達または処理結果を逐次確認する必要がない場合に限られる。これらの条件が満たされない限り、送信側ノードはデータを逐次的に送達または処理結果を確認する制御を行わなければならない。そしてこのような場合には、１つ１つのデータを送達または処理結果を確認する度に、センサノードが毎回スリープ期間に入ってしまうことになり、結果として複数データ送達に対するセンサノードの応答性が大きく低下し、アプリケーションユーザやシステム管理者に対するセンサノードのインタラクティブ性が望みにくい。
【００５４】
例えば、図３は、親ノードParentがセンサノードSS宛てのデータを1つしかバッファリングできない状況における、連続した複数データを送達する際の動作について説明した図である。親ノードParentがセンサノードSS宛てのデータを1つしかバッファリングできない状況は、親ノードParentの備えるメモリ容量そのものが小さい場合や、親ノードParentの備えるメモリ容量に比べて親ノードParentに接続しているセンサノードの数が多く、個々のセンサノードに対して十分なバッファ領域を用意することができない場合に発生する。
【００５５】
まず、センサノードSSがスリープ期間Sleep 4にある間に、通信相手Peerにおいて連続した複数データData 5、Data 6、Data 7が発生したとする。このとき通信相手Peerが複数データData 5、Data 6、Data 7を連続して送信してしまうと、親ノードParentがデータを1つしかバッファリングできないことにより、先着のData 5のみ受け付けられてData 6、Data 7が消失してしまうか、またはバッファが強制的に上書きされてData 5、Data 6が消失してしまうかのいずれかの状況が発生してしまう。従って、通信相手Peerはデータを連続して送信することはできず、まずData 5のみを送信し、Data 6、Data 7は自身でバッファリングしておかなければならない。送信されたデータData 5は、親ノードParentにより受信され、センサノードSSがポーリングしてくるまでの間、親ノードParentにおいてバッファリングされる。
【００５６】
センサノードSSがスリープ期間Sleep 4から復帰してタスク処理期間Task Processing 4に入ると、センサノードSSは親ノードParentに対してポーリングPolling 8を行い、Data 5を受信する。ここでセンサノードSSは、Data 5を受信したことを示す確認応答ACK [Data 5]を通信相手Peerに宛てて返送する。確認応答ACK [Data 5]は親ノードParentを経由して速やかに通信相手Peerまで送達される。通信相手Peerが確認応答ACK [Data 5]を受信した時点では親ノードParentのバッファが空いたことが保障されているので、通信相手PeerはセンサノードSSに宛てた次のデータData 6を速やかに送信することができる。しかしながらData 6が親ノードParentへ到達した時には、センサノードSSは既にポーリングPolling 9の結果としてデータが存在しないという応答NoData 4を受信し、スリープ期間Sleep 5へと移行してしまった後である。そのため、Data 6はセンサノードSSがスリープ期間Sleep 5から復帰するまで親ノードParentにおいてバッファリングされることとなってしまう。結果として、Data 6がセンサノードSSに送達されるのは次のタスク処理期間Task Processing 5におけるポーリングPolling 10のタイミングとなってしまい、通信相手PeerがData 6を送信してから対応する確認応答ACK [Data 6]を受信するまでにはセンサノードSSのスリープ間隔とほぼ同じ10分間のResponse Delayを要してしまうこととなる。通信相手Peerが確認応答ACK [Data 6]を受信した後に送信されるData 7に関しても同様であって、親ノードParentにおいて10分間バッファリングされ、ACK [Data 7]により送達確認が完了するまでに10分間のResponse Delayを要することとなる。結果として、通信相手Peerが3つの連続したデータData 5、Data 6、Data 7を送達し終わるまでのTransaction Delayは、Data 6、Data 7のResponse Delayが固定的に10分間ずつ要することから、少なくとも20分間を要することとなり、さらにData 5のResponse Delayが最悪の場合10分間を要することから、Transaction Delayの最悪値は30分間となってしまう。
【００５７】
このように、親ノードParentがセンサノードSS宛てのデータを1つしかバッファリングできない状況においては、親ノードParentにおけるバッファオーバフローを防ぐために通信相手Peerは1つ1つのデータの確認応答を待つことによる逐次送信をしなければならないが、通信相手Peerが確認応答を受信してから次のデータを送信した時にはセンサノードSSは既にスリープ期間に移行してしまっていることにより、たとえ通信相手Peerが連続した複数データを発生した場合であっても、センサノードSSの間欠動作の周期毎に1つずつのデータしか送達することができないという問題が発生してしまう。これではセンサノードSSへ多数のデータを送信しなければならない場合の応答性が極めて悪く、実用的なシステムを構築することは困難である。
【００５８】
ここで、Data 6が親ノードParentへ到達した時にはセンサノードSSは既にスリープ期間Sleep 5へと移行してしまっていることに関して補足を述べる。センサノードSSは低電力化の要求が強いため、タスク処理期間Task Processing 4をできるだけ早く終了させる必要がある。具体的には、タスク処理期間Task Processing 4の所要時間は長くとも50ミリ秒程度であることが期待される。従って、センサノードSSは確認応答ACK [Data 5]を送信した後、余計な待ち時間を入れずに速やかにポーリングPolling 9を実行せざるを得ない。一方、センサノードSSから送信された確認応答ACK [Data 5]が親ノードParentにより転送されて通信相手Peerへ受信され、通信相手PeerがData 6を送信して親ノードParentが受信するまでに要する時間は、少なく見積もってもセンサノードSSのポーリングPolling 9を親ノードParentが受信するまでに要する時間の数倍はかかってしまう。特に、親ノードParentと通信相手Peerとの間がマルチホップ通信となる場合には、本所要時間は秒のオーダになってしまう。仮にセンサノードSSにおける低電力化の要求を緩和し、ポーリングPolling 9の実行までに多少の待ち時間を入れるという選択肢を許したとしても、秒のオーダの待ち時間を入れてしまっては、センサノードSSにおける低電力性が著しく損なわれてしまう。また親ノードParentと通信相手Peerとの間のデータ往復時間を短くすることも技術的に困難である。結局、センサノードSSにおける低電力性を重視する以上、センサノードSSは速やかにポーリングPolling 9を実行するしかなく、その時点でData 6が親ノードParentに到着している可能性はほとんどないので、Data 6の受信は次のタスク処理期間Task Processing 5に持ち越されてしまうこととなる。
【００５９】
図３の説明においては、親ノードParentがセンサノードSS宛てのデータを1つしかバッファリングできない状況であるものとして説明を行った。この場合には、親ノードParentにおけるバッファオーバフローを防ぐために、通信相手Peerは1つ1つのデータの確認応答を待つことによる逐次送信をしなければならなかった。しかしながら、通信相手Peerが複数データの逐次送信をしなければならない状況はこれに限らない。例えば、一般的に無線通信は有線通信よりもエラーレートが大きいので、データの確実な送達のためにデータ毎に確認応答の受信を必要とする従来技術は非常に多い。このような従来技術では、確認応答を受信できない場合には該データの再送を行うことにより、物理的なエラーレートの高さを補っている。特に、センサノードの初期設定を行う等のトランザクション型の通信や、音声セッションを確立する等のネゴシエーション型の通信では、センサノードSSと通信相手Peerとの間で同期して状態遷移する必要があるため、前のデータの送達が成功しない限り次のデータの送達に移行することができない。また、センサノードSSの動作パラメータをインタラクティブに設定するような場合には、例えば現在の動作パラメータを取得するコマンド、所望のパラメータ値に設定するコマンド等を順次発行し、各コマンドに対する応答メッセージを受信した上で次に発行すべきコマンドを決めるといったように逐次的に操作することとなる。これらの場合にも、本質的な動作、特にセンサノードSSの間欠動作の周期毎に1つずつのデータしか送達することができないという問題点に関しては、図３と全く同等となる。
【００６０】
このように、センサノードSSに対する下り通信においては多くの場面で複数データの逐次送信を行う必要性が生じる。しかるに図３において示したように、間欠動作方式およびポーリング方式に関する従来技術の範囲内では、センサノードSSの低電力性能と複数データ送達の応答性能の向上とを同時に達成することはできなかった。従来技術の範囲内では、センサノードの低電力性能を向上させる代わりに複数データ送達の応答性能を犠牲にするか、あるいは複数データ送達の応答性能を向上させる代わりにセンサノードの低電力性能を犠牲にするかのどちらかの選択肢しかなかった。
【００６１】
図８は、本発明を適用したセンサノードSS1における状態遷移を表した図である。通常スリープ状態Regular Sleep、通常処理状態Regular Processingは、図１において示したスリープ状態Sleep、タスク処理状態Task Processingとに対応する。本発明の特徴は、短期スリープ状態Short Sleepと臨時処理状態Temporary Processingとを設けた点にある。
【００６２】
短期スリープ期間Short Sleepの長さは、図中では一例として3秒間である場合を示しているが、これよりも長くても短くても良い。ミドルウェアサーバMiddleware Serverやシステム管理者System Manager、アプリケーションユーザApplication User等からのコマンドにより動的に変更できても良い。また、センサノードSS1自身が状況適応的に短期スリープShort Sleepの時間を動的に変更しても良い。
【００６３】
短期スリープ期間Short Sleepの長さは、アプリケーションとして要求される応答性能を満たす程度に短い値とすることが好適であるが、無駄なポーリングの失敗を回避するために、センサノードとミドルウェアサーバMiddleware Serverとの間のデータの往復時間よりは長くしておいた方が良い。マルチホップ無線環境を含むセンサネットシステムへの適用においては、センサノードとミドルウェアサーバMiddleware Serverとの間のデータの往復時間は、無線状態の悪化や輻輳時には各通信ホップにおける衝突回避（CSMA/CA）遅延や再送遅延が増大すること等を加味し、少なくとも1秒程度は見込んでおく必要がある。また、実際の複数データの送信の頻度は、アプリケーションの種類にもよっても異なる。音声メッセージの送達のような場合は、大量のデータを可能な限りのスループットで送信したいであろう。一方、システム管理者System Managerによるインタラクティブなコマンド発行のような場合には、前のコマンドを発行、返戻を確認してから次のコマンドを発行するまでにシステム管理者System Managerの思考時間、管理用端末Management Clientの操作時間等が見込まれるので、10秒程度の遅延を見込んでも良い。
【００６４】
本実施例においても、センサノードSS1は、通常スリープ状態Regular Sleepにおけるタイマ（本図では10分間）が満了すると通常処理状態Regular Processingへと遷移し、センシングによる上りデータ生成、生成した上りデータの送信、ポーリングによる下りデータの確認、下りデータが存在した場合の該データの受信、受信した該データの処理といった動作を行う。又、通常処理状態においては予めなされる設定に基いてセンシング動作を行って、データを収集・蓄積する。センシング動作の詳細手順は、センサ部Sensor(s)の初期化、データ蓄積領域の確保、タイミング制御等の手順を含み、センサ制御部Sensor Controllerとして実装されたソフトウェアコードをマイクロプロセッサMicroProcessorが実行することにより実現される。これら全ての処理が完了次第、通常スリープ状態Regular Sleepへ戻る。本願の特徴は、通常処理状態Regular Processingにおいてまとめ送り（Bulk Transfer）の開始を意味するメッセージパケットStart-BT Indicationを受信することによって短期スリープ状態Short Sleepへと遷移する点である。ここで、メッセージパケットStart-BT Indicationは、本目的のために定義された専用のパケットであっても良いし、一般のデータパケットやACKパケットに含まれるビットフラグ等の情報フィールドとして定義されたものであっても良い。短期スリープ状態Short Sleepにおいては、通常スリープ状態の期間に比べて短期間（本図では3秒）のタイマが駆動されており、本タイマが満了すると臨時処理状態Temporary Processingへと遷移する。このShort Sleep用の時間については、初期値として、または設定コマンドを用いることによって、予め端末に設定しておく。臨時処理状態Temporary Processingでは、通常処理状態Regular Processingとは異なり、下りデータに関連する処理、すなわち、ポーリングによる下りデータの確認、下りデータが存在した場合の該データの受信、および受信した該データの処理のみを行う。臨時処理状態Temporary Processingにおいてセンシング動作は行わないのは、本状態が下りデータの受信に関連する処理を行うことに特化して設けた状態だからである。センシング動作は、下りデータの有無とは無関係に、所定のアプリケーションで規定される定期的な測定周期、すなわち通常処理状態Regular Processingの周期（本図では10分間）に基づいて実行される。このように通常処理状態Regular Processingと臨時処理状態Temporary Processingを分離することによって、センシングのためのスケジューリングと下り複数データ受信のためのスケジューリングとを独立に制御することができる。
【００６５】
これら一連の処理を完了次第、センサノードSS1は短期スリープ状態Short Sleepへ戻る。以後、センサノードSS1はしばらくの期間、短期スリープ状態Short Sleepと臨時処理状態Temporary Processingとの間の状態遷移、すなわち臨時動作Temporary Operationを繰り返す。センサノードSS1が通常動作Regular Operation、すなわち通常スリープ状態Regular Sleepと通常処理状態Regular Processingとの間の状態遷移へと復帰するのは、臨時処理状態Temporary Processingにおいてまとめ送りの終了を意味するメッセージパケットStop-BT Indicationを受信した時(A)である。このとき、センサノードSS1は臨時処理状態Temporary Processingから通常スリープ状態Regular Sleepへと遷移し、以降は通常動作Regular Operationへと復帰する。実装によっては、臨時処理状態Temporary Processingにおいてポーリングによって下りデータが存在しないことを検知した時（B）に通常動作Regular Operationへと復帰しても良い。復帰条件(A)と(B)は、いずれかを採用しても良いし、両方の条件を採用しても良い。また、さらに付加的な条件、例えば臨時動作Temporary Operationの最大期間を設け、該タイマの満了時に通常動作Regular Operationへと復帰しても良い。
【００６６】
本状態遷移の全体の制御は、タスク管理部Task Managerとして実装されたソフトウェアコードをマイクロプロセッサMicroProcessorが実行することにより実現される。また、スリープ状態と動作状態との間の相互遷移の際に必要となる、各ハードウェア機能部への電力供給のオン・オフの制御は、電力管理部Power Managerとして実装されたソフトウェアコードをマイクロプロセッサMicroProcessorが実行することにより実現される。
【００６７】
＜図９＞複数データ逐次発行シーケンス 
図９は、ミドルウェアサーバMiddleware ServerがセンサノードSS1に宛てて複数のデータを連続的かつ逐次的に送信する際の通信シーケンスを説明した図である。まず図２および図３との対応関係について説明する。センサノードSS1にとっては、ルータノードRT1が親ノードParentの役割を果たす。また、ゲートウェイノードGW1は、ミドルウェアサーバMiddleware ServerとルータノードRT1との間でデータを中継する役割を果たす。ただしこの中継機能に大きな技術的特徴はないため、本図では図２および図３におけるマルチホップノード（Multi Hop）に対応する位置に図示するにとどめており、実際の中継手順の詳細は図面上では省略している。なお、本図はミドルウェアサーバMiddleware ServerからセンサノードSS1に宛てた通信に着目した図としているが、他のセンサノードに宛てた通信も本図と本質的に同等の図により説明することができる。例えば、センサノードSS6に宛てた通信の場合、ルータノードRT4が親ノードParentの役割を果たす。また、ルータノードRT3、RT2、およびゲートウェイノードGW2の3台のノードは、マルチホップノード（Multi Hop）としての役割を果たす。
【００６８】
図４において述べたように、センサノードに対するデータ送信の起点には(1)〜(4)の４種類が考えられるが、ここではそれらの共通経路に着目し、ミドルウェアサーバMiddleware Serverが起点であるとみなして説明を行う。
【００６９】
以後、通信シーケンスそのものの説明に入るが、まず図９についての留意事項を述べる。作図の都合により、図中の縦方向すなわち時間軸方向の縮尺は、時間的な順序関係は正しく表現しているが、実際の所要時間のスケールを正しく表現してはいない。具体的には、通常処理期間Regular Processingや臨時処理期間Temporary Processingの所要時間は長くとも50ミリ秒程度のオーダである。一方、短期スリープ期間Short Sleepはここでは固定的に3秒間であると想定している。図面上では、この両者が両者が同程度の縮尺となっているが、これはあくまで作図の都合である。
【００７０】
初期状態として、センサノードSS1は通常動作Regular Operationを行っている状態であるとする。センサノードSS1が10分間の通常スリープ期間Regular Sleep Aにある間に、ミドルウェアサーバMiddleware Serverにおいて連続した複数データData A、Data B、Data Cが発生したとする。このような状況は、例えばセンサノードSSが人間が身に付ける情報端末型の装置であって通信相手Peerから音声メッセージを受信するような場合に発生する。ルータノードRT1におけるバッファオーバフローを防ぐため、ミドルウェアサーバMiddleware ServerはセンサノードSS1からの確認応答ACKを待ちながら逐次的にデータを送信しなければならない点は、図３におけるのと同様である。ただし図３と違うのは、複数データの送信に先立ち、ミドルウェアサーバMiddleware ServerはセンサノードSS1に宛てて、まずまとめ送り（Bulk Transfer）を開始することを意味するメッセージパケットStart-BT Indicationを送信する点である。メッセージパケットStart-BT Indicationの種々の構成例については後述するが、最もシンプルな実施形態においては、受信側であるセンサノードSS1が本メッセージ種別を識別するための情報、例えば1バイト分の識別情報フィールドのみが含まれていれば十分である。送信されたメッセージパケットStart-BT Indicationは、ルータノードRT1により受信され、センサノードSS1がポーリングしてくるまでの間、ルータノードRT1においてバッファリングされる。このバッファリング時間は、センサノードSS1の通常動作周期のどのタイミングで該メッセージパケットStart-BT Indicationを送信したかに応じて設定され、例えば最小0分間、最大10分間である。
【００７１】
センサノードSS1が通常スリープ期間Regular Sleep Aから復帰して通常処理期間Regular Processing Aに入ると、センサノードSS1はルータノードRT1に対してポーリングPolling Aを行い、メッセージパケットStart-BT Indicationを受信する。センサノードSS1は、本メッセージパケットStart-BT Indicationを受信したことを示す確認応答ACK [Start-BT]をミドルウェアサーバMiddleware Serverに宛てて返送するが、その後は再度のポーリングを行うことなく速やかに臨時動作Temporary Operation に移行する。本実施例においては例えば3秒間の短期スリープ期間Short Sleep Aへと移行する。コマンド受信したノードの処理詳細については後述する。
【００７２】
一方センサノードSS1が送信した確認応答ACK [Start-BT]は、ルータノードRT1を経由して速やかにミドルウェアサーバMiddleware Serverまで送達される。ミドルウェアサーバMiddleware Serverが確認応答ACK [Start-BT]を受信した時点では、ルータノードRT1は既にセンサノードSS1へのメッセージパケットStart-BT Indicationの送達を完了している。すなわちルータノードRT1が管理するセンサノードSS1用のバッファが空いたことが保障されている。従って、ミドルウェアサーバMiddleware Serverは確認応答ACK [Start-BT]を受信後速やかに、センサノードSS1に宛てた最初のデータData Aを送信することができる。送信されたデータData Aは、ルータノードRT1により受信され、センサノードSS1がポーリングしてくるまでの間、ルータノードRT1においてバッファリングされる。一方センサノードSS1は、この直前に3秒間の短期スリープ期間Short Sleep Aへと入っている。本スリープ期間の満了後、センサノードSS1は臨時処理期間Temporary Processing Aへと復帰し、ルータノードRT1に対してポーリングPolling Bを行う。ここで先程ルータノードRT1にバッファリングされたデータData AがセンサノードSS1に渡される。その後センサノードSS1はData Aを受信したことを示す確認応答ACK [Data A]をミドルウェアサーバMiddleware Serverに宛てて返送し、再び速やかに3秒間の短期スリープ期間Short Sleep Bへと移行する。以降、Data B、Data Cの送達に関しても同様の動作である。センサノードSS1は臨時動作Temporary Operationにおける状態遷移、すなわち短期スリープ状態Short Sleepと臨時処理状態Temporary Processingとを繰り返しながら、3秒間に1回のペースでルータノードRT1へのポーリングを行い、Data B、Data Cを順次取得する。またミドルウェアサーバMiddleware Serverは、センサノードSS1からの確認応答ACKを3秒間に1回のペースで受信することにより、Data B、Data Cを3秒間に1回のペースで送信することができる。
【００７３】
最後に、Data Cの送達完了後、ミドルウェアサーバMiddleware Serverは、ミドルウェアサーバMiddleware ServerはセンサノードSS1に宛てて、まとめ送り（Bulk Transfer）を終了することを意味するメッセージパケットStop-BT Indicationを送信する。送信されたメッセージパケットStart-BT IndicationはルータノードRT1においてバッファリングされた後、センサノードSS1が3秒間の短期スリープ期間Short Sleep Dを満了して臨時処理期間Temporary Processing Dへと復帰したタイミングで、ポーリングPolling EによりセンサノードSS1に取得される。センサノードSS1は、本メッセージパケットStop-BT Indicationを受信したことを示す確認応答ACK [Start-BT]をミドルウェアサーバMiddleware Serverに宛てて返送した後、速やかに10分間の通常スリープ期間Regular Sleep Bへと移行する。ここまでで臨時動作Temporary Operationが終了し、以降は通常動作Regular Operation、すなわち通常スリープ期間Regular Sleepと通常処理期間Regular Processingの繰り返し動作へと復帰する。
【００７４】
本実施例の構成により、低電力性、長時間駆動性を非常に重視し、通常動作状態において間欠動作周期が長く、従来技術によっては複数データ送達時の応答性能が期待できないようなセンサノードSS1に対しても、その低電力性能を保ちながら、同時に複数データ送達の際の応答性能の向上をも達成するという効果が得られる。
【００７５】
なお、本実施例ではルータノードRT1がセンサノードSS1宛てのデータを1つしかバッファリングできない状況であるものとして説明を行った。本状況の下では、ルータノードRT1におけるバッファオーバフローを防ぐために、ミドルウェアサーバMiddleware Serverは1つ1つのデータの確認応答を待つことによる逐次送信をしなければならなかったが、既に述べたように、ミドルウェアサーバMiddleware Serverが複数データの逐次送信をしなければならない状況はこれに限らず広く発生する。例えばデータの確実な送達のためにデータ毎に確認応答の受信を必要とする場合である。特に、センサノードの初期設定を行う等のトランザクション型の通信や、音声セッションを確立する等のネゴシエーション型の通信の場合である。また、センサノードSS1の動作パラメータをシステム管理者System Managerがインタラクティブに設定するような場合には、例えば現在の動作パラメータを取得するコマンド、所望のパラメータ値に設定するコマンド等を順次発行し、各コマンドに対する応答メッセージを受信した上で次に発行すべきコマンドを決めるといったように逐次的に操作することとなる。これらの場合においても、本発明を適用しない場合の応答時間が長いという問題点、および、本発明を適用した場合の応答時間が短縮されるという効果とは、図３および図９において説明したのと全く同等である。
【００７６】
なお本実施例では、センサノードSS1が臨時動作Temporary Operationに入った時の間欠動作周期は、ミドルウェアサーバMiddleware Serverが指定するのではなく、センサノードSS1の自律的な判断により決定している。ミドルウェアサーバMiddleware Serverは、メッセージパケットStart-BT Indicationによって複数データの送信を開始することを通知するのみである。この点の実施方法に関してはいくつかの変形例が考えられる。最もシンプルな実施方法は、センサノードSS1に予め臨時動作Temporary Operation時の間欠動作周期を示す値が読み出し専用メモリRead-Only Memoryに固定的に記憶されており、センサノードSS1はメッセージパケットStart-BT Indicationの受信時に該値に基づき固定的に臨時動作Temporary Operation時の間欠動作周期、すなわち短期スリープShort Sleepの時間を決定する方法である。具体的には、ポーリングにより受信したパケットはZigBee通信部ZigBee Communicatorにより、パケットのヘッダ及びペイロードが解析される。解析の結果、本パケットがStart-BT Indicationを意味する識別情報を含んでいれば、ZigBee通信部ZigBee Communicatorは該情報をタスク管理部Task Managerへ通知する。この時タスク管理部Task Managerは、マイクロプロセッサMicroProcessorの動作を臨時動作Temporary Operationへと遷移させ、特に短期スリープShort Sleepに入る際、読み出し専用メモリRead-Only Memoryに固定的に記憶されている短期スリープShort Sleepの時間（本図では3秒）をタイマ部Timerに設定した上で、マイクロプロセッサMicroProcessorをスリープ状態へと遷移させる。スリープ状態への遷移の際は、電力管理部Power Managerが、タイマ部Timerと割り込み制御部Interrupt Controllerを除く全てのハードウェア機能部への電力供給を停止する制御をマイクロプロセッサMicroProcessorに指示する。別の実施方法は、上記短期スリープShort Sleepの時間の初期値は読み出し専用メモリRead-Only Memoryに固定的に記憶されているが、実際の短期スリープShort Sleepの時間のランタイム値は不揮発性メモリNonvolatile Memoryに記憶されており、該値はミドルウェアサーバMiddleware Serverからの設定コマンドにより動作中に変更可能とする方法である。この場合、ミドルウェアサーバMiddleware Serverが発行する設定コマンドの構成としては、例えば、短期スリープShort Sleepの時間を変更するコマンドであることを表す識別情報フィールドと、新たな短期スリープShort Sleepの時間をミリ秒の単位で指定するフィールドとを含めば良い。このような構成とした場合には、システム管理者System Managerは、各センサノード毎に短期スリープShort Sleepの時間を固有の値に設定することができる。例えばマルチホップの中継数が少ないセンサノードとの通信の方が、マルチホップの中継数が多いセンサノードとの通信よりも通信遅延が短くて済む。例えば1ホップの往復につき100ミリ秒の通信遅延を見込んだとすると、ミドルウェアサーバMiddleware ServerとセンサノードSS1の親ノードであるルータノードRT1との間の中継数は、有線区間を含めて2ホップであるから、センサノードSS1の短期スリープShort Sleepの時間は200ミリ秒もしくそれよりも大きめの値に設定すれば良い。一方、ミドルウェアサーバMiddleware ServerとセンサノードSS6の親ノードであるルータノードRT4との間の中継数は有線区間を含めて4ホップであるから、センサノードSS6の短期スリープShort Sleepの時間は400ミリ秒もしくそれよりも大きめの値に設定すれば良い。このようにすることで、各センサノードの短期スリープShort Sleepの時間を各々の設置環境において最も適した値に調整し、システム全体としての応答性能が最大化することができるという効果が得られる。
【００７７】
またさらに別の実施方法は、ミドルウェアサーバMiddleware Serverが送信するメッセージパケットStart-BT Indicationの中にはこれから送達するデータの特性やその送信タイミングに関する情報が含まれており、センサノードSS1は上記情報を元に実際の短期スリープShort Sleepの時間を動的に決定する方法である。この場合、メッセージパケットStart-BT Indicationの中に格納する情報は、送達しようとするデータの種類、総数、送達優先度、許容送達遅延時間、希望送信時刻、希望送信時刻間隔等のうちの1つ以上の情報を含んでいて良い。例えば、データの種類がリアルタイム音声の場合には、データの受信および再生を可能な限り早く完了するため、センサノードSS1は、短期スリープShort Sleepの時間を可能な限り短くするのが好適であるが、データの種類が非リアルタイム音声の場合には、センサノードSS1が十分な容量の揮発性メモリVolatile Memoryを備えているのであれば、全てのデータの受信が完了した後でゆっくり再生すれば良いので、短期スリープShort Sleepの時間はそれほど短くしなくても構わない。同様に、データの総数、送達優先度等の情報を用いた場合にも、センサノードSS1は短期スリープShort Sleepの時間を自律的に設定することができる。このような、短期スリープShort Sleepの時間を動的に決定する実施方法には種々の変形が考えられるが、いずれの場合であってもデータの送達そのものはあくまでもセンサノードSS1からの主体的なポーリングによって実現されるので、特許文献１の場合とは異なり、ミドルウェアサーバMiddleware ServerとセンサノードSS1との間で精密な時刻同期を行わなくてもデータの送達失敗が起こることはなく、センサノードSS1の低電力性能を保持しつつ安定的にデータ送達が実現される。
【００７８】
上記のような短期スリープShort Sleepの時間の決定の仕方に関する各実施方法の適用の仕方としては、適用先となるセンサネットシステムの規模、あるいはアプリケーションの特性によって使い分けることが考えられる。例えば、短期スリープShort Sleepの時間が固定的であるような実施方法は、動的に変更可能な実施方法と比べると低機能ではあるが、その分センサノードSS1に実装すべき制御が単純であり、必要となるプログラムコードのサイズが少なくて済む。また、センサノード毎のマルチホップの中継数にそれほどばらつきがなく、トラフィック量が通信容量に比べて比較的小さいような場合であれば、短期スリープShort Sleepの時間が固定的であるような実施方法で十分な実用性が確保されるであろう。一方、センサノード毎にマルチホップの中継数が大きく異なる場合、時間的にトラフィック量が大きく変動する場合、リアルタイムの送達性に対する要求性能が大きく異なる複数のデータ種別を有するような場合には、短期スリープShort Sleepの時間をコマンドにより変更可能であるか、またはセンサノードSS1の自己判断により動的に変更可能である実施方法が適している。
【００７９】
上記のような実施方法の変形例の１つとして、ミドルウェアサーバMiddleware ServerがメッセージパケットStart-BT Indicationによって個々のデータの送達予定時刻をミリ秒単位の正確さで指定し、実際にその通りの時刻にルータノードRT1からセンサノードSS1へ送信するといった方法もありえる。このような場合には、センサノードSS1において本発明が前提としているようなポーリング動作が不要とも思われるが、センサノードSS1とルータノードRT1とのデータ送受信をミリ秒単位の正確さで同期させるためには、センサノードSS1とルータノードRT1に精度の高い高価なタイマが必要となってしまう。また、無線通信環境は常に良好とは限らず、例えばノイズや輻輳によるルータノードRT1までのデータの送達が滞る状況も考えられるので、たとえ十分な精度のタイマを搭載した場合であっても、ルータノードRT1が指定した予定時刻にミリ秒単位の正確さでデータを送信することを保証することは実運用上は困難である。そして、予定時刻と実際の送受信時刻との誤差の期待値が数ミリ秒以上になると、センサノードにおける受信待機時間を増大させなければデータの送達が成功せず、結果的にセンサノードの低電力性能は意図に反して本発明と比べて著しく劣る状況となってしまう。
【００８０】
以上のように、センサノードに対する下り通信においては多くの場面で複数データの逐次送信を行う必要性が生じる。しかるに図３において示したように、間欠動作方式およびポーリング方式に関する従来技術の範囲内では、センサノードの低電力性能と複数データ送達の応答性能の向上とを同時に達成することはできなかった。また、時刻同期の正確性を高め、送信予定時刻にのみセンサノードを短時間の待ち受け状態とする代替案も、実運用上では様々な困難が伴い、広く適用できるものではない。本発明では、時刻同期が不要でありながら、センサノードの起動時間を必要最小限とする点に、センサノードの低電力性能の高さと、実運用への適用の容易さとを両立している。
【００８１】
本図では、まとめ送り開始を意味するメッセージパケットStart-BT Indicationは、本目的のために定義された専用のパケットである場合を示したが、既に述べたように、一般のデータパケットや確認応答ACKパケットに含まれるビットフラグ等の情報フィールドとして定義されたものであっても良い。具体的には、例えばミドルウェアサーバMiddleware Serverが、ヘッダ部にStart-BT Indicationフィールドを含み、かつペイロード部にData Aを含むようなデータパケットを送信しても良い。この場合には、図中ではStart-BT IndicationパケットとData Aパケットの2回に分けたパケット送達が、単一のパケットの送達へと縮退されるので、その分だけ全データ送達完了までの時間を短縮することができる。また、本図では省略しているが、センサノードSS1はポーリングPolling Aの直前に、センシングデータをミドルウェアサーバMiddleware Serverへ宛てて送信する上り通信を実施しているはずであり、これに伴いルータノードRT1からセンサノードSS1への確認応答ACKパケットが送達されているはずである。従って、該確認応答ACKパケットのヘッダ部にStart-BT Indicationフィールドを含めることによって、センサノードSS1のポーリング回数を一回分縮退させることもできる。このように、Start-BT Indicationを示す情報の送達は、本図のような専用パケットとしての送達に限らず、他のパケットと縮退した形式により送達することも可能である。
【００８２】
なお本図では、複数データの逐次的送信の場合について説明したが、前のコマンドの実行結果を確認しながら次に発行するコマンドを決定するような、対話的なデータ送達の場合等の動作も、本図と本質的に同等な通信シーケンスによって説明できる。このような場合には、本図におけるACKパケットは、データの送達を示す確認応答のメッセージではなく、コマンドの処理結果の成否情報等を含んだ返戻応答パケットを意味することになるという点に関しては、既に述べた通りである。同様に、本図においては全ての通信区間を通じてACKパケットと総称しているが、センサノードSS1がルータノードRT1へ送信するACKパケット、ルータノードRT1がゲートウェイノードGW1へ転送するACKパケット、ゲートウェイノードGW1がミドルウェアサーバMiddleware Serverへ転送するACKパケットの各々は、通信規格上の表現として別々の名称で定義されていても良いし、ルータノードRT1やゲートウェイノードGW1を経由する際に追加の情報が付与されても構わない。例えば、センサノードSS1がルータノードRT1へ送信するACKパケットには、確認応答の対象となるデータのシーケンス番号のみが含まれており、通信規格上の表現としてもACKパケットと命名されていたとする。ところが、本パケットを受信した直後にルータノードRT1がゲートウェイノードGW1へ送信するパケットには、該シーケンス番号のみならず、次のデータの送信を要求することを意味する識別フィールドが含まれており、かつ通信規格上の表現としてもデータ要求メッセージといった命名がされる場合もあり得る。また、ルータノードRT1が大容量の揮発性メモリVolatile Memoryを備え、ミドルウェアサーバMiddleware Serverが送信しようとする複数のデータをバッファリングすることが可能な場合には、上記データ要求メッセージには、さらにデータをいくつ要求するかを意味するフィールドが含まれている場合もあり得る。ゲートウェイノードGW1がミドルウェアサーバMiddleware Serverへ転送するACKパケットについても同様の変形が施される場合があり得る。このように、確認応答ACKの実施形態および通信規格上の定義名にはいくつかの変形例が考えられるが、通信シーケンスの中での順序関係としてセンサノードSS1へのデータの到達を契機として発生し、少なくとも該データのシーケンス番号に関連する情報をミドルウェアサーバMiddleware Serverまで伝播するためのパケットであるならば、どのような定義名であろうとも、またどのような付加情報を含んでいようとも、本実施例が総称する確認応答ACKの一実施形態であるとみなすことができる。なお、上記のようにルータノードRT1が複数のデータをバッファリングすることが可能な場合には、センサノードSS1は各々の臨時処理期間Temporary Processingにおいて1回のみポーリングを行うのではなく、図２におけるタスク処理期間Task Processingにおけるのと同様に、ルータノードRT1にバッファリングされたデータが存在する限り、ポーリングを繰り返しても良い。ただし、たとえルータノードRT1が大容量の揮発性メモリVolatile Memoryを備えていたとしても、対話的なデータ送達の場合には結局データは1つずつしかルータノードRT1へバッファリングされないことになる。従ってこのような場合には、既に述べた変形例と類似の方策として、メッセージパケットStart-BT Indicationの��に送達しようとするデータの種類を含め、センサノードSS1は該メッセージの後に送信されようとするデータが逐次送信されるのか一括送信されるのかを識別した上で、各々の臨時処理期間Temporary Processingにおいて1回だけポーリングするのか繰り返しポーリングするのかを決定するといった実施形態が有効である。
【００８３】
＜図１０＞複数データ逐次発行シーケンス（強制起動）
ここで、図９に示した実施例の、複数データ送達完了までの応答時間をさらに短縮することを考える。図９では、センサノードSS1が臨時動作Temporary Operationを開始してからの複数データ送達に関しては従来技術と比較して格段に応答性能の向上を達成しているが、ミドルウェアサーバMiddlewareが最初に送信したデータ、本実施例ではStart-BT IndicationメッセージがセンサノードSS1に受信されるまでの所要時間は、相変わらず従来技術と同様である。すなわち、たまたま間欠動作の周期と合致したタイミングで送信されればバッファリング時間がゼロとなりほぼリアルタイムに送達されるが、最悪の場合は間欠動作の周期と同じ10分間もかかってしまう。間欠動作のタイミングとデータ発生のタイミングとの間に相関がない場合には、この所要時間の平均値は5分間と見積もられることとなる。
【００８４】
そこで、本発明の更なる改良として、最初のデータの送達時間の短縮を図ることを考える。
【００８５】
図１０は、図９に示した通信シーケンスに対して、センサノードSS1の強制起動を行う改良を加えた通信シーケンスを示した図である。図９との唯一の違いはStart-BT Indicationメッセージの送信方法である。ルータノードRT1は、無線送電送信部RF Transmitter (Aerial Feeding)を用いてStart-BT Indicationメッセージを送信する。本メッセージは、たとえセンサノードSS1がスリープ期間Regular Sleep Aにあったとしても、無線受電受信部RF Receiver (Aerial Fed)によって受信され、マイクロプロセッサMicroProcessor内の割り込み制御部Interrupt Controllerに入力される。割り込み制御部Interrupt Controllerが割り込み信号を発生することにより、マイクロプロセッサMicroProcessorは電力管理部Power Managerの指示により強制起動Force Wakeupし、通常スリープ期間Regular Sleep Aが解除され速やかに通常処理期間Regular Processing Aへと遷移する。そして先のStart-BT Indicationメッセージに対する確認応答ACK [Start-BT]を送信し、速やかに臨時動作Temporary Operationを開始、すなわち3秒間の短期スリープ期間Short Sleep Aへと移行する。
【００８６】
このように、Start-BT Indicationメッセージを無線送電送信部RF Transmitter (Aerial Feeding)と無線受電受信部RF Receiver (Aerial Fed)を用いて送受信する場合、ルータノードRT1はセンサノードSS1からのポーリングを待つことなく速やかにStart-BT Indicationメッセージを送信することができる。またセンサノードSS1は、通常スリープ期間Regular Sleep A中であっても本メッセージを受信し、速やかに臨時動作Temporary Operationに移行するので、データが発生した時点Data Generationから最初のデータData Aを送信するまでの所要時間、すなわちStart-BT Indicationメッセージの送達が完了するまでの所要時間Response Delayは、ほぼリアルタイム、具体的にはマルチホップ通信時間を含めても1秒以内程度にまで低減することができる。この結果、Data A、Data B、Data Cの全てのデータの送達が完了するまでの所要時間Transaction Delayは10秒程度にまで低減されることとなる。
【００８７】
＜図１１＞Command Manager詳細
図１１は、ミドルウェアサーバMiddleware Server内のコマンド管理部Command Managerの詳細な構成および動作を表した図である。
【００８８】
図の右側は、コマンド管理部Command Managerの構成の詳細を示している。コマンド管理部Command Managerは、各センサノードへ送信するデータをバッファリングするためのデータバッファData Bufferと、データ送信時の動作を制御するためのデータ送信制御部Transmission Controller、複数データ送信時の動作を制御するためのまとめ送り制御部Bulk-Transfer Controllerとから構成される。各センサノード宛てのデータ送信を別々に制御するために、データバッファData Bufferは各センサノード毎に独立に管理される。なお物理的な実現形態としては、各センサノード毎に物理的に独立したメモリ領域が割り当てられても良いし、全てのセンサノード宛てのデータを共通のメモリ領域に格納しつつも、各々のデータに対して、宛て先となるセンサノードを表す識別情報と、同一の宛て先となるデータ間での送信順序を表す識別情報とが対応付けられて管理されていても良い。同様に、データ送信制御部Transmission Controllerとまとめ送り制御部Bulk-Transfer Controllerに関しても、図中では各々単一の機能部として表現しているが、各センサノード毎に別々のメモリ領域が割り当てられるか、共通のメモリ領域内で各センサノードの識別情報により区別されるかにより、各センサノード毎に独立の状態遷移を管理する。
【００８９】
図の左側は、センサノードSS1宛てのデータに着目し、コマンド管理部Command Managerの動作の詳細を示している。なお、ここでは主にデータ送信制御部Transmission Controllerが実行する手順について説明している。今、センサノードSS1宛てに3つのデータ、すなわちData A、Data B、Data Cがバッファリングされているとする。このとき、まず手順[1]のように、最初のデータData Aが無線ネットワーク管理部PAN Managerへ送信される。その後、Data Aに対する確認応答ACKを待ち受ける状態[2]へと遷移する。本図では、該待ち受け時間内に確認応答ACKが受信された場合[3]を示している。この場合、手順[4]のように該確認応答ACKがオブジェクト管理部Object Managerへ転送される。この時点でData Aの送達処理は完了であるので、その後は手順[5]のようにData Aをバッファ先頭から削除し、手順[6]のように次のデータData Bをバッファ先頭に取得する。
【００９０】
＜図１２＞Command Manager状態遷移： データ送信制御
図１２は、コマンド管理部Command Manager内のデータ送信制御部Transmission Controllerが各々のセンサノード毎に管理する状態遷移を表した図である。なお、矢印に付した2行表記の動作は、上の行が矢印の基点の状態において発生した状態遷移のトリガとなるイベントを表しており、下の行が状態遷移の際に実行するアクションを表している。また、図中[1]〜[6]の符号は、図１１において示した手順または状態に対応している。
【００９１】
コマンド管理部Command Managerは、各々のセンサノード毎に、スタンバイ状態StandbyとACK待ち受け状態ACK Waitingの2つの状態を管理する。スタンバイ状態Standbyは、データバッファData Bufferに該センサノード宛てのデータがない時と、図１１の手順[5]のように1つのデータの送達処理が完了した直後とになる状態である。スタンバイ状態Standbyにおいて、バッファ内に処理すべき次のデータがあれば、データ送信制御部Transmission Controllerは該データをバッファ先頭に取得、無線ネットワーク管理部PAN Managerへ送信した後にACK待ち受け状態ACK Waitingへと遷移する。ACK待ち受け状態ACK Waitingでは、本状態の持続時間を計測するための再送タイマRetransmission Timerと、本状態を繰り返した回数を計測するための再送カウンタRetransmission Counterが管理される。手順[3]は、ACK待ち受け状態ACK Waitingへ入ってから所定の時間以内、すなわち再送タイマRetransmission Timerがタイムアウトする前に確認応答ACKを受信した場合である。このとき、コマンド管理部Command Managerは手順[4]の該確認応答ACKの転送、手順[5]の該データの削除を実行した後、スタンバイ状態Standbyへと復帰する。一方、確認応答ACKを受信しないまま再送タイマRetransmission Timerがタイムアウトした場合は、所定回数までの範囲内、すなわち再送カウンタRetransmission Counterが所定の値以下である間は、該データを再送し、再びACK待ち受け状態ACK Waitingへ戻る。所定回数の再送を行ってもなお確認応答ACKが受信されない場合、すなわちリトライアウトが発生した場合には、コマンド管理部Command Managerはそれ以上のデータ再送の試行を諦める。この場合にはオブジェクト管理部Object Managerへ送達失敗のエラー返戻を行うことにより、エラーリカバリの制御を上位レイヤであるオブジェクト管理部Object Managerへ委ねる。その後、該データを削除するか上書きを許可した上で、スタンバイ状態Standbyへと復帰する。
【００９２】
このように、コマンド管理部Command Managerは、再送タイマRetransmission Timerのタイムアウトに伴い所定回数はデータの再送を行うので、一時的な通信環境の悪化に伴うデータロスに強い、信頼性の高い通信を実現することができる。同時に、所定回数以上の送信失敗に対しては上位レイヤに対してエラー返戻を行うので、長期的な通信環境の悪化等の場合に無駄に再送を繰り返すことなく、上位レイヤやシステム管理者に通報し、リカバリ処理を依頼することができる。
【００９３】
＜図１３＞Command Manager状態遷移： まとめ送り制御
図１３は、コマンド管理部Command Manager内のまとめ送り制御部Bulk-Transfer Controllerが各々のセンサノード毎に管理する状態遷移を表した図である。
【００９４】
まとめ送り制御部Bulk-Transfer Controllerは、各々のセンサノード毎に、まとめ送り解除状態OFF-BTとまとめ送り状態ON-BTの2つの状態を管理する。まとめ送り解除状態OFF-BTにおいて、データバッファData Bufferに該センサノード宛てのデータが2つ以上バッファリングされた状態になると、まとめ送り制御部Bulk-Transfer Controllerはまとめ送り開始メッセージStart-BT Indicationを生成し、データバッファData Bufferの先頭へ挿入した後に、まとめ送り状態ON-BTへと遷移する。一方、まとめ送り状態ON-BTにおいて、データバッファData Bufferから該センサノード宛てのデータがなくなった時点で、まとめ送り制御部Bulk-Transfer Controllerはまとめ送り終了メッセージStop-BT Indicationを生成し、データバッファData Bufferの先頭へ挿入した後に、まとめ送り解除状態OFF-BTへと遷移する。
【００９５】
まとめ送り制御部Bulk-Transfer Controllerが本状態遷移に従って動作することにより、ミドルウェアサーバMiddleware Serverは、まとめ送り開始メッセージStart-BT Indicationとまとめ送り終了メッセージStop-BT Indicationを、図９および図１０に示したタイミングで該センサノードに対して発行する機能が実現される。
【００９６】
なお、対話的なコマンド送信のような場合には、管理用端末Management Clientやアプリケーション端末Application Clientが対話的処理の開始、終了を制御する。すなわち、これらの端末が直接、Start-BT IndicationメッセージやStop-BT Indicationメッセージ、またはこれらと同等の意味を有するメッセージを送信することとなる。従って、この場合にはまとめ送り制御部Bulk-Transfer Controllerは特にセンサノードの動作を制御する必要はない。
【００９７】
＜図１４＞ノード管理テーブル in PAN Manager
図１４は、ミドルウェアサーバMiddleware Server内の無線ネットワーク管理部PAN Managerが管理するノード管理テーブルの構成を表した図である。
【００９８】
本ノード管理テーブルは、特定のセンサノードに宛てたデータを送信する際に、転送先のゲートウェイノードを決定し、またパケットヘッダの宛先情報を生成するために参照される。テーブルの各エントリは、各センサノードの情報に対応し、該センサノードに宛てたデータを送信する際に参照する必要のある情報が管理されている。また各エントリは、該センサノードに対してオブジェクト管理部Object Managerが一意に割り当てたインデックス値Sensor Node Indexを用いて管理されている。ここで、インデックス値Sensor Node Indexは、Object ManagerやPAN Managerのみならず、Data Manager、Command Manager、Event Publisher等のミドルウェア各機能部がセンサノードを識別するのに共通に用いる情報である。
【００９９】
各エントリへのアクセスは、上記インデックス値Sensor Node Indexを用いて行われる。そして本テーブルから、該インデックス値Sensor Node Indexに対応するセンサノードのアドレス値、所属しているPANのID値、該PANにおけるゲートウェイノードのアドレス値を参照することができる。このうち、センサノードのアドレス値と所属しているPANのID値とは、ZigBee規格の無線パケットのヘッダを構成する情報である。Command Managerから渡される各センサノード宛てのデータに対してPAN Managerがこれらの情報を追加することによって、実際にパケットの生成を行うZigBee Adapterが、ZigBee規格の無線パケットのヘッダ情報を生成に必要なヘッダ情報を追加することができる。一方、本テーブル中のゲートウェイノードのアドレス値は、該センサノードに宛てたデータをどのゲートウェイノードへ転送すれば良いかを示している。例えば、センサノードSS1に宛てたデータは、(GWaddr1)で示されたゲートウェイノード、すなわちGW1へ転送すれば良いことが分かる。同様に、センサノードSS2とSS3に宛てたデータは、(GWaddr2)で示されたゲートウェイノード、すなわちGW2へ転送すれば良く、またセンサノードSS7とSS8に宛てたデータは、(GWaddr3)で示されたゲートウェイノード、すなわちGW3へ転送すれば良いということが分かる。Command Managerから渡される各センサノード宛てのデータに対してPAN Managerが本情報を追加することによって、実際にパケットを送信するZigBee Adapterが、該パケットをどのゲートウェイノードへ転送すれば良いかを決定することができる。
【０１００】
なお、ゲートウェイノードから各センサノードまでのデータの送達は、ゲートウェイノードやルータノードの自律的な動作により実現することができるので、ミドルウェアサーバMiddleware Serverにおいては無線ネットワークPAN内の通信経路までを指定する必要はない。無線ネットワーク内の経路制御の全体を統括するのはゲートウェイノードであり、またマルチホップ経路の各ホップ間での中継はルータノードにより自律的に制御される。図４において、ゲートウェイノードGW1の無線ネットワーク制御部PAN Controllerは、無線ネットワークPAN1の構成情報として、PAN1に所属しているノードの一覧（ここではRT1とSS1）の情報と、PAN1に所属しているセンサノード（同SS1）の親ノード（同RT1）の情報を管理している。また、ゲートウェイノードGW1やルータノードRT1のルーティング管理部Routing Managerは、無線ネットワークPAN1内のマルチホップ通信のための経路制御情報を管理している。これらの情報は、ルータノードRT1やセンサノードSS1が無線ネットワークPAN1へ接続する際の通信シーケンスや、隣接するルータノード間での定期的な経路情報交換に伴い伝播、更新される。従って、ゲートウェイノードやルータノードは、通信環境の変化や各ノードの移動に伴い無線ネットワークの構成が動的に変更された場合でもこれに自律的に追従し、経路制御を動的に更新することが可能である。
【０１０１】
センサノードSS8に宛てたデータを例に、無線ネットワーク内のデータ送達の手順について説明する。ミドルウェアサーバMiddleware ServerがセンサノードSS8に宛てたデータは、上記のようにPAN ManagerやZigBee Adapterを経由することにより、ゲートウェイノードGW3へ転送される。ゲートウェイノードGW3は無線ネットワーク制御部PAN Controllerが保持する無線ネットワークPAN3の構成情報を参照することにより、センサノードSS8の親がルータノードRT7であることを知る。さらにルーティング管理部Routing Managerの保持する経路情報を参照することにより、ルータノードRT7へデータを送達するための中継先がルータノードRT5またはRT6であることを知る。中継先としてルータノードRT5とRT6のどちらが選択されるかは、先に発見した経路が固定的に優先されても良いし、パケットエラーレート等を元に計測した通信品質に基づいて選択されても良い。中継先として該データを転送されたルータノードRT5またはRT6は、同様に自身のルーティング管理部Routing Managerの保持する経路情報を参照することにより、転送先であるルータノードRT7が自身と直接的に通信可能であることを知る。このようにして、センサノードSS8に宛てたデータは無線ネットワークPAN3内のマルチホップ経路を中継され、親であるルータノードRT7まで転送される。ルータノードRT7からセンサノードSS8へのデータの受け渡しは、図９や図１０で示したようにセンサノードSS8からのポーリングによって実現される。
【０１０２】
以上のように、無線ネットワーク管理部PAN Managerがノード管理テーブルを保持することにより、ミドルウェアサーバMiddleware Serverは任意のセンサノードに対してデータを送達することができる。
【０１０３】
なお、ゲートウェイノードの無線ネットワーク制御部PAN Controllerが保持する無線ネットワークの構成情報や、ゲートウェイノードやルータノードのルーティング管理部Routing Managerが保持する無線ネットワーク内の経路情報は、ルータノードやセンサノードが該無線ネットワークへ接続する際の通信シーケンスや、隣接するルータノード間での定期的な経路情報交換に伴い伝播、更新される。従って、ゲートウェイノードやルータノードは、通信環境の変化や各ノードの移動に伴い該無線ネットワークの構成が動的に変更された場合でもこれに自律的に追従し、マルチホップ経路制御を動的に更新することが可能である。同様に、図１４に示したミドルウェアサーバMiddleware Server内のノード管理テーブルに関しても、無線ネットワークの構成が動的に変更された場合にこれに自律的に追従させることができるので、システム管理者が手動で更新するような作業は不要である。具体的には、ノード管理テーブルが保持している3つの情報（センサノードのアドレス値、所属しているPANのID値、該PANにおけるゲートウェイノードのアドレス値）は全て、ゲートウェイノードが自身の情報、あるいは無線ネットワーク制御部PAN Controllerの管理情報として保持している情報である。従って、例えばゲートウェイノードGW1は、センサノードSS1がPAN1へ接続した時点で、これら3つの情報を含んだ接続通知メッセージをミドルウェアサーバMiddleware Serverへ送信することができ、本接続通知メッセージを受信したミドルウェアサーバMiddleware ServerはセンサノードSS1に対応するノード管理テーブルのエントリを生成することができる。これら3つの情報は、センサノードの接続時だけでなく、センサノードSS1が送信する測定データ等のパケットをゲートウェイノードGW1がミドルウェアサーバMiddleware Serverへ転送する際に、付加情報として必ず追加するようにしても良い。その後もしセンサノードSS1が移動し、PAN2へ接続したとしても、ゲートウェイノードGW2から通知される同様のメッセージにより、ミドルウェアサーバMiddleware Serverはノード管理テーブルのエントリを速やかに最新の状態へと更新することが可能である。すなわち、センサノードSS1の所属するPANがPAN1からPAN2へと変更され、また対応するゲートウェイノードがGW1からGW2へと変更されたことが検出可能である。従って、ミドルウェアサーバMiddleware Serverは任意のセンサノードに対してデータを送達することができるのみならず、任意のセンサノードの移動に対しても自律的に追従することができる。
【０１０４】
上記のようなセンサノードの移動が発生した際には、該センサノードへ宛てた下り通信の経路が変更されることに伴い、一時的に下りデータの送達が滞る状況が発生しうる。具体的には、センサノードSS1がPAN1からPAN2へ移動しようとする最中にもPAN1へ向けてデータが送信されてしまう場合が考えられる。このような場合には、図１２において示したデータ送信制御部Transmission Controllerによる再送手順が非常に有効に機能する。センサノードがPAN1から離脱した直後にPAN1へ向けて送信されたデータは、当然のことながらセンサノードSS1へは受信されないので、再送タイマRetransmission Timerのタイムアウトによって程なく再送手順が起動される。その時点でセンサノードSS1のPAN2への接続手順が完了していれば、無線ネットワーク管理部PAN Managerの保持するノード管理テーブルも最新状態へ更新されているので、再送されたデータはPAN2へ移動したセンサノードSS2へ問題なく送達される。仮にセンサノードSS1のPAN2への接続までにある程度の時間がかかったとしても、コマンド管理部Command Managerがエラー返戻を行うことにより、上位レイヤやシステム管理者によるリカバリ処理が可能である。
【０１０５】
以上のように、無線ネットワーク管理部PAN Managerがノード管理テーブルを管理し、データ送信制御部Transmission Controllerが再送制御を行うことにより、ミドルウェアサーバMiddleware Serverは任意のセンサノードの移動に対しても自律的に追従し、信頼性の高いデータ送達が可能である。
【図面の簡単な説明】
【０１０６】
【図１】センサノードの、間欠動作を表すシーケンス図、およびその状態遷移図。
【図２】センサノードの、ポーリングによるデータ受信を表すシーケンス図。
【図３】従来技術に基づくセンサノードへ、複数のデータを逐次的に送達する際の動作を表すシーケンス図。
【図４】本発明の一実施例における、システム全体の構成図。
【図５】同じく、センサノードSS1のハードウェア構成図。
【図６】同じく、ルータノードRT1のハードウェア構成図。
【図７】同じく、ゲートウェイノードGW1のハードウェア構成図。
【図８】同じく、センサノードSS1の状態遷移図。
【図９】同じく、センサノードSS1へ複数のデータを逐次的に送達する際の動作を表すシーケンス図。
【図１０】同じく、センサノードSS1を強制的に起動し、かつ複数のデータを逐次的に送達する際の動作を表すシーケンス図。
【図１１】同じく、ミドルウェアサーバMiddleware Server内のコマンド管理部Command Managerの詳細な構成および動作を表す図。
【図１２】同じく、コマンド管理部Command Manager内のデータ送信制御部Transmission Controllerの状態遷移図。
【図１３】同じく、コマンド管理部Command Manager内のまとめ送り制御部Bulk-Transfer Controllerの状態遷移図。
【図１４】同じく、ミドルウェアサーバMiddleware Server内の無線ネットワーク管理部PAN Managerが管理するノード管理テーブルの構成図。
【図１】
2008072415.tif 000003
【図２】
2008072415.tif 000004
【図３】
2008072415.tif 000005
【図４】
2008072415.tif 000006
【図５】
2008072415.tif 000007
【図６】
2008072415.tif 000008
【図７】
2008072415.tif 000009
【図８】
2008072415.tif 000010
【図９】
2008072415.tif 000011
【図１０】
2008072415.tif 000012
【図１１】
2008072415.tif 000013
【図１２】
2008072415.tif 000014
【図１３】
2008072415.tif 000015
【図１４】
2008072415.tif 000016