(57)【要約】【課題】無線通信システムにおいて、外部システムとの連携に有利だがビット長の大きいグローバルIDの活用と、無線端末の通信量の低減とを両立する。【解決手段】無線端末は初期登録時のみグローバルIDを送信し、サーバによってビット長の小さいローカルIDを割り当てられた後はローカルIDのみを使用する。サーバはグローバルIDとローカルIDの関連付けを管理し、システム外との通信では無線端末の識別にグローバルIDを使用する。【選択図】図１０
2006060515.tif 000002
【特許請求の範囲】
【請求項１】
複数の無線端末と、1つ以上の無線基地局と、1つ以上のサーバからなる無線通信システムであって、
前記無線端末は、
前記無線基地局と通信するための無線通信手段と、
本無線端末を一意に識別するためのグローバルIDと、
前記無線通信手段を用いて前記グローバルIDを前記サーバへ送信する手段と、
前記グローバルIDに対応してサーバが本無線端末に割り当てるローカルIDを記憶する手段とを有し、
前記無線基地局は、
前記無線端末と通信するための無線通信手段と、
前記サーバと通信するための通信手段と、
前記無線端末と前記サーバの通信を中継する手段とを有し、
前記サーバは、
前記無線基地局と通信するための通信手段と、
前記通信手段を用いて前記無線端末からのグローバルIDを受信する手段と、
前記無線端末のグローバルIDと1対1に対応し、前記グローバルIDよりもビット長の小さい、ローカルIDを生成する手段と、
前記グローバルIDと前記ローカルIDの対応関係を記憶し相互に変換するための手段と、
前記通信手段を用いて前記ローカルIDを前記無線端末へ送信する手段とを有し、
前記無線端末と前記サーバの間の通信を前記無線基地局が中継し、
前記無線端末は初期的な通信において前記グローバルIDを前記サーバへ送信し、
前記サーバは、前記無線端末より受信した前記グローバルIDに対して前記ローカルIDを1つ割り当てて前記無線端末へ送信し、
前記無線端末は前期サーバより受信した前記ローカルIDを記憶し、
以後の通信においては前記無線端末、前記無線基地局、前記サーバのいずれもが、前記無線端末を識別するために前記ローカルIDを使用する
ことを特徴とする無線通信システム。
【請求項２】
請求項１に記載の無線通信システムであって、
前記無線通信システムは広域ネットワークと接続され、
前記サーバは、
前記広域ネットワークを介して外部通信装置と通信するための通信手段と、
前記外部通信装置に対して前記無線端末に関わる情報を提示する手段か、前記外部システムと前記無線端末または前期無線基地局との通信を中継する手段の少なくとも1つとを有し、
前記外部通信装置との直接的な通信は前記サーバが代表して行い、
前記無線端末または前記無線基地局は、前記サーバを介して間接的に前記外部通信装置と通信可能であって、
前記サーバは、
前記外部通信装置との通信において、前記無線端末を識別する際に前記グローバルIDを使用し、
前記無線端末または前記無線基地局と前記外部通信装置との通信を中継する際に、
前記無線端末または前期無線基地局とのシステム内通信においては前記無線端末を識別する際に前記ローカルIDを使用し、
前記外部通信装置とのシステム外通信においては前記無線端末を識別する際に前記グローバルIDを使用し、
前記システム内通信と前記システム外通信を中継する際に前記ローカルIDと前記グローバルIDを相互に変換する
ことを特徴とする無線通信システム。
【請求項３】
請求項１に記載の無線通信システムであって、
各々の無線端末に割り当てられる前記ローカルIDのビット長が可変であることを特徴とする無線通信システム。
【請求項４】
請求項１に記載の無線通信システムであって、
前記無線端末または前記サーバが、
動作中の任意の時点において、前記無線端末にローカルIDを再割り当てするための通信手順を開始する手段を有し、
前記無線端末は、
初期的な通信により前記サーバから第1のローカルIDを割り当てられ、前記第1のローカルIDを使用して任意の期間動作した後に、前記無線端末または前記サーバにより前記通信手順が開始されることにより前記サーバから第2のローカルIDを再割り当てされ、以後前記第2のローカルIDを使用して動作する
ことを特徴とする無線通信システム。
【請求項５】
請求項１に記載の無線通信システムであって、
前記無線基地局のうちの1つと前記サーバとが単一の装置であることを特徴とする無線通信システム。
【請求項６】
複数の無線端末と、1つ以上の無線基地局と、1つ以上のサーバからなる無線通信システムであって、
前記無線端末は、
前記無線基地局と通信するための無線通信手段と、
本無線端末を一意に識別するためのグローバルIDと、
前記無線通信手段を用いて前記グローバルIDを前記サーバへ送信する手段と、
前記グローバルIDに対応してサーバが本無線端末に割り当てるローカルIDを記憶する手段とを有し、
前記無線基地局は、
前記無線端末と通信するための無線通信手段と、
前記サーバと通信するための通信手段と、
前記無線端末と前記サーバの通信を中継する手段と、
前記グローバルIDと前記ローカルIDの対応関係を記憶し相互に変換するための手段とを有し、
前記サーバは、
前記無線基地局と通信するための通信手段と、
前記通信手段を用いて前記無線端末からのグローバルIDを受信する手段と、
前記無線端末のグローバルIDと1対1に対応し、前記グローバルIDよりもビット長の小さい、ローカルIDを生成する手段と、
前記グローバルIDと前記ローカルIDの対応関係を記憶し前記グローバルIDから前記ローカルIDを検索するための手段と、
前記通信手段を用いて前記ローカルIDを前記無線端末へ送信する手段とを有し、
前記無線端末と前記サーバの間の通信を前記無線基地局が中継し、
前記無線端末は初期的な通信において前記グローバルIDを前記サーバへ送信し、
前記サーバは、前記無線端末より受信した前記グローバルIDに対して前記ローカルIDを1つ割り当てて前記無線基地局および前記無線端末へ送信し、
前記無線基地局は前記サーバより受信した前記グローバルIDと前記ローカルIDの対応関係を記憶し、
前記無線端末は前期サーバより受信した前記ローカルIDを記憶し、
以後の通信においては、
前記無線端末と前記無線基地局との通信においては前記無線端末を識別するために前記ローカルIDを使用し、
前記無線基地局と前記サーバとの通信においては前記無線端末を識別するために前記グローバルIDを使用し、
前記無線基地局が、前記無線端末と前記サーバとの通信を中継する際に前記ローカルIDと前記グローバルIDを相互に変換する
ことを特徴とする無線通信システム。
【請求項７】
複数の無線端末と、1つ以上の無線基地局と、1つ以上のサーバからなる無線通信システムであって、
前記無線端末は
前記無線基地局と通信するための無線通信手段と、
本無線端末を一意に識別するためのグローバルIDと、
前記無線通信手段を用いて前記グローバルIDを前記サーバへ送信する手段と、
前記グローバルIDに対応してサーバが本無線端末に割り当てるローカルIDを記憶する手段とを有し、、
前記無線基地局は、
前記無線端末と通信するための無線通信手段と、
前記サーバと通信するための通信手段と、
前記無線端末と前記サーバの通信を中継する手段と、
前記無線通信手段を用いて前記無線端末からのグローバルIDを受信する手段と、
前記無線端末のグローバルIDと1対1に対応し、前記グローバルIDよりもビット長の小さい、ローカルIDを生成する手段と、
前記グローバルIDと前記ローカルIDの対応関係を記憶し相互に変換するための手段と、
前記無線通信手段を用いて前記ローカルIDを前記無線端末へ送信する手段とを有し、
前記サーバは前記無線基地局と通信するための通信手段を有し、
前記無線端末は初期的な通信において前記グローバルIDを前記無線基地局へ送信し、
前記無線基地局は、前記無線端末より受信した前記グローバルIDに対して前記ローカルIDを1つ割り当てて前記無線端末へ送信し、
前記無線端末は前期無線基地局より受信した前記ローカルIDを記憶し、
以後の通信においては、
前記無線端末と前記サーバの間の通信を前記無線基地局が中継し、
前記無線端末と前記無線基地局との通信においては前記無線端末を識別するために前記ローカルIDを使用し、
前記無線基地局と前記サーバとの通信においては前記無線端末を識別するために前記グローバルIDを使用し、
前記無線基地局が、前記無線端末と前記サーバとの通信を中継する際に前記ローカルIDと前記グローバルIDを相互に変換する
ことを特徴とする無線通信システム。
【請求項８】
請求項１に記載の無線通信システムであって、
前記無線通信システムは広域ネットワークと接続され、
前記サーバは、
前記無線端末のグローバルIDと1対1に対応し、前記通信システム内で一意な識別情報を記憶する手段と、
前記グローバルIDと前記識別情報の対応関係を記憶し相互に変換するための手段と、
前記広域ネットワークを介して外部通信装置と通信するための通信手段と、
前記外部通信装置に対して前記無線端末に関わる情報を提示する手段か、前記外部システムと前記無線端末または前期無線基地局との通信を中継する手段の少なくとも1つとを有し、
前記外部通信装置との直接的な通信は前記サーバが代表して行い、
前記無線端末または前記無線基地局は、前記サーバを介して間接的に前記外部通信装置と通信可能であって、
前記サーバは、
前記外部通信装置との通信において、前記無線端末を識別する際に前記識別情報を使用し、
前記無線端末または前記無線基地局と前記外部通信装置との通信を中継する際に、
前記無線端末または前期無線基地局とのシステム内通信においては前記無線端末を識別する際に前記ローカルIDを使用し、
前記外部通信装置とのシステム外通信においては前記無線端末を識別する際に前記識別情報を使用し、
前記システム内通信と前記システム外通信を中継する際に前記ローカルIDと前記識別情報を相互に変換する
ことを特徴とする無線通信システム。
【請求項９】
複数の端末と、１つ以上の基地局とを有する通信システムであって、
前記端末は、
前記基地局と通信するための通信手段と、
端末を一意に識別するための第１のIDを記憶する第１のメモリと、
前記第１のIDに対応する第２のIDを記憶する第２のメモリとを有し、
前記基地局は、
前記無線端末と通信するための通信手段を有し、
前記端末は前記第１のIDを前記基地局に向けて送信し、前記第１のIDに対応する第２のIDを前記基地局から受信し、受信した第２のIDを上記第２のメモリに記憶し、それ以後の通信において、上記第２のIDを用いることを特徴とする通信システム。
【請求項１０】
前記端末は前記第１のIDを前記基地局に向けて送信し、
前記基地局はサーバ装置に向けて前記第１のIDを送信し、
前記サーバ装置は前記第１のIDと1対1に対応し、前記第１のIDよりもビット長の小さい第２のIDを生成し、前記第１のIDと前記第２のIDの対応関係を記憶することを特徴とする請求項９記載の通信システム。
【請求項１１】
複数の端末と、該端末と無線で通信する１つ以上の基地局とを有する通信システムに於ける通信方法であって、
前記端末は、
自己を特定する第１のＩＤを上記基地局に送信し、
上記第１のＩＤと対応する第２のＩＤを上記基地局から受信し、
上記第２のＩＤを記憶し、
上記第２のＩＤを記憶した以後の通信においては、前記端末および前記基地局は、前記端末を識別するために前記第２のＩＤ使用することを特徴とする通信方法。
【請求項１２】
基地局と無線で通信する無線端末であって、前記無線端末は、
前記基地局と通信するための無線モジュールと、
第１のＩＤを記憶する第１のメモリと、
書き込み可能な第２のメモリと、
前記無線モジュール、第１及び第２のメモリを制御するコントローラと、
上記無線モジュール、第１及び第２のメモリ、およびコントローラに電力を供給する電源を有し、
前記コントローラは、上記第１のＩＤを含むデータを上記無線モジュールを介して上記基地局に送信し、上記基地局から送信される上記第１のＩＤに対応する第２のＩＤを上記無線モジュールで受信すると、該第２のＩＤを上記第２のメモリに記憶し、該第２のＩＤを用いて通信するように制御することを特徴とする無線端末。
【請求項１３】
上記コントローラは、上記第２のＩＤを上記第２のメモリに記憶した以後の通信においては、上記第２のＩＤを用いて、上記基地局と交信を行うように制御することを特徴とする請求項１２記載の無線端末。
【請求項１４】
複数の端末と、該端末と無線通信を行う１つ以上の基地局とを有する通信システムに接続されるサーバであって、該サーバは、
前記基地局と通信するための通信ユニットと、
メモリと、
上記通信ユニット及びメモリを制御するコントローラと、を有し、
上記コントローラは、
前記端末から前記基地局を経由して送付される第１のＩＤを前記通信ユニットにより受信すると、該第１のＩＤと1対1に対応し前記第１のＩＤよりもビット長の小さい第２のＩＤを生成し、生成した該第２のＩＤを上記メモリに格納し、該第２のＩＤを前記通信ユニットを用いて前記端末へ送信するように制御を行うことを特徴とするサーバ。
【請求項１５】
前記メモリは、前記第１のＩＤと第２のＩＤの対応表を記憶することを特徴とする請求項１４記載のサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信端末と無線基地局を含む通信システムに関する。
特に、前記無線通信端末がセンサを搭載した小型半導体チップであるようなセンサネットワークシステムに関する。
【背景技術】
【０００２】
あらゆるモノのネットワーク接続を可能とするユビキタス社会の実現を目指した研究開発が盛んである。非接触ICカードやRFIDといった無線通信機能を有する小型ICチップが急速に普及しつつあり、商品の流通管理、生産管理、電子マネー等への応用が広がっている。また、このようなICチップに各種センサ機能を搭載することによって、生産ラインの監視、ホームセキュリティ、環境計測等を実現する試みも進められている。このようなセンサチップが構成するネットワークおよびサービスはセンサネットと呼ばれ、現実世界のリアルタイムの情報をネットワークへ取り込むことを可能とし、ユビキタス社会の情報基盤となる技術として期待されている。
既に広く使用されている非接触ICカードの近距離無線通信の規格として、非特許文献１に記載の国際標準規格が定められている。
【０００３】
【非特許文献１】ISO/IEC IS 18092
【発明の開示】
【発明が解決しようとする課題】
【０００４】
現状のセンサネットは、個々の研究機関やメーカが独自仕様のプロトタイプや製品を開発し、個別の応用に適用している段階にある。これらのセンサチップでは通信の仕様もまちまちであり、物理レイヤにしてもMACレイヤ以上にしても互いに互換性はない。多くの製品では、個々のセンサチップを識別するのに8ビットや16ビットといった、ビット長の小さいローカルIDを用いている。これらのローカルIDは、当該メーカにおいてのみ、あるいは当該システムにおいてのみ一意であることが保証されている。従ってメーカの異なるセンサチップ同士は互いに通信できなかった。あるいは同一のメーカであっても納入先の異なるセンサチップ同士は互いに通信できない場合もあった。これまでのところセンサネットは大規模な普及に至っておらず、このような現状であっても差し当たって問題とはならなかった。しかし今後、普及の広がりや各種仕様の標準化と共に、複数のメーカから購入したセンサチップが同一のシステム内に共存したり、別々に構築したシステム同士が互いに連携したりする技術が求められるようになるであろう。これらを実現するためには、センシングしたデータを収集するための、特定のメーカの仕様に依存しない汎用的なアーキテクチャが必要となる。
【０００５】
非接触ICカードやRFIDの分野では、チップの各々を一意に識別するために、世界中で一意なグローバルIDを策定する動きが進んでいる。例えば、日本を拠点とする業界団体であるユビキタスIDセンターでは128ビットの「ユビキタスID」を、米国を拠点とする業界団体であるEPCglobalでは64ビットまたは96ビットの「EPC（Electronic Product Code）」を提案している。このような動きはいずれセンサネットへも適用され、個々のセンサチップに全世界で一意なIDを付与することが必須となるであろう。
【０００６】
非接触ICカードやRFIDでは、リーダから照射される電磁波をエネルギー源として動作するパッシブ給電方式が一般的である。一方センサネットを構成するセンサチップは、広域に配置され自律的にセンシングやデータ送信を行うため、チップ内に電池または発電装置を内蔵するアクティブ給電方式が一般的である。具体的には、一次電池（乾電池等）、二次電池（充電池）、燃料電池、太陽光発電装置、微小振動発電装置等を用いる方式がある。
【０００７】
センサチップを人やモノに付けたり環境中に多数配置することを考えると、センサチップは可能な限り小型化する必要がある。センサチップの小型化にはアクティブ給電装置の小型化も必要だが、これは電源容量の縮小を意味する。一方、実用性の向上のためには個々のセンサチップを長時間駆動できなければならない。従って、センサチップの低消費電力化の必然性が生じる。
【０００８】
センサチップの消費電力のほとんどは無線通信に費やされ、場合によっては9割以上を占める。従って、センサチップの低消費電力化のためには無線通信の低消費電力化が必須である。その一環として、送受信するデータ総量の削減が重要である。前述したように、センサチップへも世界で一意のグローバルIDを付与することが必須となると見込まれる。このようなとき、多くの場合、送信したい測定データそのものは典型的には数10ビット程度である。このような状況の下でビット長の大きいグローバルIDをそのまま使用すると、データそのものに比して実際の通信量が必要以上に増大してしまう。
【０００９】
例えば、128ビットのグローバルIDをそのまま通信時のパケットヘッダに使用する場合、送信元と宛先の両方を指定するプロトコルであれば、これだけで256ビットのオーバヘッドが発生する。一方、測定データのサイズはセンサの種類や測定対象によるが、温度データの場合を考えれば、典型的なビット長は16ビットあるいはせいぜい32ビットである。ある程度のリアルタイム性が要求される用途では、センサチップは一度の測定の度にデータを送信する必要がある。このときに、グローバルIDのために256ビットものオーバヘッドを課すのは非効率である。従来の有線系通信や、無線LANやBluetooth（登録商標）のように比較的電力に余裕のあることを前提とする無線系通信においては、この程度のオーバヘッドは問題視されなかった。しかし、低速・低電力通信が前提となるセンサチップにおいては、1パケットあたり200ビット以上ものオーバヘッドは通信性能に重大な悪影響を与える。
【００１０】
以上のように、従来のセンサチップで用いられてきたローカルIDでは、当該メーカにおいてのみ、あるいは当該システムにおいてのみの一意性しか有しておらず、システム外との通信において個々のセンサチップを一意に特定する汎用的な方法がなかった。一方、将来必須となると見込まれるグローバルIDをそのまま用いて無線通信を行った場合、センサチップの通信データに占めるオーバヘッドの割合が増大し、通信帯域および消費電力を浪費してしまう。本発明の課題は、センサチップの消費電力低減のための通信量低減と、外部システムとの連携に有利なグローバルIDの活用とを両立することである。
【課題を解決するための手段】
【００１１】
本発明は、世界中で一意なグローバルIDを有するセンサチップが初期的な通信において前記グローバルIDをサーバへ送信し、前記サーバは前記グローバルIDに対してシステム内でのみ一意なローカルIDを1つ割り当てて前記センサチップへ送信し、前記センサチップは前期サーバより受信した前記ローカルIDを記憶し、以後の通信においては前記センサチップ、前記サーバ、前記センサチップと前記サーバの通信を中継する無線基地局のいずれもが、前記センサチップを識別するために前記ローカルIDを使用することを特徴とする。具体的な通信方法としては、ローカルIDを割り当てられた後の通信においては、グローバルIDを含まずローカルIDを含む情報を送受信する。
【００１２】
なお、ローカルIDを割り当てるためには、必ずしもローカルＩＤを一つづつ生成して割り当てる必要はない。例えば、サーバ起動時に複数のローカルＩＤを生成してプールしておき、センサチップからの要求を受信するたびに、当該プールから１つのＩＤを割り当てても良い。簡単な例としては、ローカルＩＤのプールをスタック型のデータ構造で管理しておき、要求を受信するたびに、先頭から順にプッシュしていく方法がある。
【００１３】
また本発明は、広域ネットワークを介した外部通信装置との通信を前記サーバが代表して行い、前記外部通信装置との通信において前記センサチップを識別する際に前記グローバルIDを使用し、前記サーバが前記外部通信装置との通信を前記センサチップまたは前記無線基地局へ中継する際には、前記グローバルIDと前記ローカルIDを相互に変換することを特徴とする。
【００１４】
なお、一面において本発明と類似していると思われがちな従来技術に、IP（Internet Protocol）アドレスの変換を行うNAT（Network Address TranslatorまたはNetwork Address Translation）技術がある。しかしNAT技術は、ローカルアドレスのみを有しグローバルアドレスを有さない端末に対して、NAT装置が自装置内のみで前記ローカルアドレスと特定のグローバルアドレスを関連付け、IPパケットを転送する際に両アドレスを相互変換することを特徴としている。従ってNAT装置の配下に接続される前記端末は自身に割り当てられたグローバルアドレスを知ることもなく、最初から一貫してローカルアドレスのみを用いた通信を行う。このように、本発明が従来のNAT技術とは全く異なる複数の技術的特徴を有していることは明白であろう。
【００１５】
本発明の特徴を要約すると、本発明の通信システムは、複数の端末と、１つ以上の基地局とを有する通信システムである。ここで端末は、基地局と通信するための通信手段と、端末を一意に識別するための第１のIDを記憶する第１のメモリと、第１のIDに対応する第２のIDを記憶する第２のメモリとを有する。また基地局は、無線端末と通信するための通信手段を有し、端末は第１のIDを基地局に向けて送信し、第１のIDに対応する第２のIDを基地局から受信し、受信した第２のIDを第２のメモリに記憶することを特徴とする。端末は例えば種々のセンサを備えたチップ構成である。端末と基地局の間の通信は無線で行われることが好適である。第２のＩＤは基地局と接続されるサーバなどで生成され、基地局を経由して受信した第１のＩＤに基づいてサーバが第２のＩＤを生成し、第２のＩＤは基地局を経由して端末に送られることにしてもよい。
サーバは第１のIDと1対1に対応し、第１のIDよりもビット長の小さい第２のIDを生成し、第１のIDと第２のIDの対応関係を記憶するように構成することができる。
【００１６】
本発明の通信方法は、複数の端末と、端末と無線で通信する１つ以上の基地局とを有する通信システムに於ける通信方法である。
端末は、自己を特定する第１のＩＤを上記基地局に送信し、第１のＩＤと対応する第２のＩＤを上記基地局から受信し、第２のＩＤを記憶し、第２のＩＤを記憶した以後の通信においては、端末および前記基地局は、端末を識別するために第２のＩＤを使用する。
このような、第２のＩＤの割り当ては、端末設置の直後、例えば通信システム初期化時に行うことができる。
【００１７】
本発明の無線端末は、基地局と無線で通信する無線端末であって、基地局と通信するための無線モジュールと、第１のＩＤを記憶する第１のメモリと、書き込み可能な第２のメモリと、無線モジュール、第１及び第２のメモリを制御するコントローラと、無線モジュール、第１及び第２のメモリ、およびコントローラに電力を供給する電源を有する。ここでコントローラは、第１のＩＤを含むデータを無線モジュールを介して基地局に送信し、基地局から（または、基地局を経由して）送信される第１のＩＤに対応する第２のＩＤを無線モジュールで受信すると、第２のＩＤを第２のメモリに記憶するように制御する。このような、コントローラの機能はマイクロプロセッサ上で実行されるソフトウエアにより実現できるほか、専用のハードウエアで実現することもできる。
【００１８】
コントローラは、第２のＩＤを第２のメモリに記憶した以後の通信においては、第２のＩＤを用いて、基地局と交信を行うように制御する。第２のＩＤが第１のＩＤよりも短い
ビット長を持っていれば、通信されるデータ総量（ＩＤ含む）が少なくて済み、電源として電池を用いた場合、その寿命を長持ちさせることができる。
【００１９】
本発明のサーバは、複数の端末と、端末と無線通信を行う１つ以上の基地局とを有する通信システムに接続されるサーバである。このサーバは、基地局と通信するための通信ユニットと、メモリと、通信ユニット及びメモリを制御するコントローラとを有し、コントローラは、端末から基地局を経由して送付される第１のＩＤを通信ユニットにより受信すると、第１のＩＤと1対1に対応し第１のＩＤよりもビット長の小さい第２のＩＤを生成し、生成した第２のＩＤをメモリに格納し、第２のＩＤを通信ユニットを用いて端末へ送信するように制御を行う。メモリは、第１のＩＤと第２のＩＤの対応表を記憶するように構成できる。
【発明の効果】
【００２０】
本発明に拠れば、システム内通信、特に無線通信において、低電力・低速通信に適した、ビット長の小さいローカルIDを使用できる。また、サーバがシステム外との通信を仲介することにより、外部システムとの連携に適した、全世界で一意なグローバルIDも活用できる。
また、グローバルIDがシステム内の通信仕様に直接影響を及ぼさないので、グローバルIDの仕様変更に容易に対応可能である。
【発明を実施するための最良の形態】
【００２１】
自動化・無人化の必要とされる工場の大規模生産ラインにおいて、製造工程を監視する多数のセンサチップを配置する。工場は全国に散在しており、各工場においてセンサネットワークシステムが構築されている。これら全てをインターネットを介して中央管理センターで監視することにより、製造工程を一元的に監視することができ、生産性向上のための種々の施策を促進するための情報基盤とすることができる。
【実施例１】
【００２２】
図１に、外部システムを含むセンサネットシステムの全体構成を示す。
センサチップ（101〜108）は、センサ機能や無線通信機能を備えた小型ICチップである。多数のセンサチップが、人やモノに付けられたり環境中に配置されたりする。個々のセンサチップは定期的にセンシングを行ったり、データ送信を行ったりする。
【００２３】
無線基地局（111〜113）は、センサチップ（101〜108）から送信されたデータを受信し、サーバへ転送する役割を果たす。一般的に、無線基地局の数はセンサチップの数と比較すると少数である。各々の無線基地局は通信可能なエリアを有し、センサチップの配置されるエリア全体をカバーするように配置される。無線通信はノイズの影響を受け易いため、1つのセンサチップが常に複数の無線基地局と通信可能なように、無線基地局を密に配置する場合もあるが、センサチップがマルチホップ通信を行い、無線基地局を密に配置する必要のない場合もある。
【００２４】
サーバ（131）は、基地局が受信したセンサチップからの測定データを、LAN（120）を介して受信する。個々のセンサチップから収集した測定データを、データベースに蓄積する。また、クライアント（141）や外部サーバ（171）からのアクセスを受け付け、これらに対してデータベースの情報を提供したり、反対に情報の提供を受けたりする。
【００２５】
クライアント（141）は、本システムにおけるユーザとのインタフェースを提供する。例えば温度モニタリングのようなアプリケーションを実現するためのフロントエンドとなり、サーバ（131）にアクセスし、データベースの情報を取得し、温度モニタリング画面を表示する。また、ユーザからの管理コマンドを受け付け、サーバ、基地局、センサチップに対する制御を実行する。クライアント（141）が直接通信するのはサーバ（131）であるので、基地局やセンサチップに対する管理コマンドはまずサーバ（131）に受け付けられ、サーバ（131）から基地局、さらにセンサチップへ転送される。なお、クライアント（141）は発明の内容と直接の関係を持たないため、本明細書では詳細な説明は行わない。
【００２６】
LAN（120）は、ユーザサイドで構築されたローカルエリアネットワークである。LANを構成する技術としてはイーサネット（登録商標）技術が広く普及しており、スイッチングハブや無線LANアクセスポイント等によって構成される。また、Bluetooth（登録商標）、ECHONET（登録商標）、HAVi（登録商標）のような、他のLAN向け通信技術を併用することもできる。LAN（120）へは、無線基地局、サーバ、クライアント等が接続され、これらの装置間の通信を仲介する。
【００２７】
ルータ（151）は、LAN（120）を公衆網であるInternet（160）へ接続するためのゲートウェイである。ルータの基本機能はIPパケットを中継することであるが、多種多様なゲートウェイ機能を備えるものが市販されており、それらの機能を必要に応じて活用することができる。例えば、LAN（120）内の各装置に自動的にIPアドレスを割り当てるためのDHCP機能やLAN（120）内でプライベートIPアドレスを使用する場合のNAT（Network Address Translation）機能を利用することができる。特に、外部からInternet（160）を介したLAN（120）内への不正アクセスを防止するため、ルータ（151）はファイアウォール機能を有するものが適している。その場合、サーバ（131）は、本図のように他の機器同様LAN内に設置しても良いし、セキュリティをより強固にするために、ルータの特定ポートに接続し、DMZ（De-Militarized Zone）を構成しても良い。
以上が、ユーザサイドにおいて構築されたセンサネットシステムの構成である。ここでユーザとは、個人、企業、自治体等のいずれであっても良い。
【００２８】
前記のようなセンサネットシステムは、ルータ（151）を介してInternet（160）へ接続される。ルータ（151）とInternet（160）を接続するアクセス回線は、通信事業者の提供する多種多様な回線を使用することができる。代表的なものに、アナログ電話回線、デジタル専用線、ADSL、CATV、FTTH等が挙げられる。センサネットシステムのユーザが個人や小規模な企業である場合には、アクセス回線は典型的にはまずISP（Internet Service Provider）のネットワークへ収容され、そこからInternet（160）へ接続される。
【００２９】
外部サーバ（171）は、センサネットシステムから見ればInternet（160）上の外部通信機器である。典型的には、有償で特定のアプリケーションを提供するASP（Application Service Provider）であったり、無償で公開されたWebサイトであったりする。外部サーバ（171）を所有する事業主体に応じてInternet（160）への実際の接続は異なるが、ISPのネットワークを介して接続されるのが一般的である。
【００３０】
センサネットシステムと外部サーバとの関係は必ずしも1対1でなくても良い。単一の外部サーバが複数のセンサネットシステムと連携しても良いし、単一のセンサネットシステムが複数の外部サーバと連携しても良い。あるいは、外部サーバ（171）が、図１とは別のセンサネットシステムにおけるサーバであっても良く、その場合には別々のセンサネットシステム同士が互いに連携する形となる。
【００３１】
図２に、センサチップ（101）の内部構成を示す。
電源（210）は、センサチップ（101）の各機能部が動作するための電力を供給する。一次電池（乾電池やボタン電池等）、二次電池（充電池）、燃料電池、太陽光発電装置、微小振動発電装置等が使用できる。
【００３２】
センサ（220）は、マイコン（250）からの測定命令に従いセンシングを行い、測定値をマイコンに受け渡す。測定対象となり得る物理量は、温度、圧力、加速度、赤外線量、電位等であり、測定対象に応じた受容機構を備える。一次測定値がアナログ信号として得られる場合には、マイコン（250）が扱えるデジタル値に変換するためのAD変換器を備える。センサチップ（101）が種々の応用に適用できるように、センサ（220）は単体で複数の受容機構を備えても良いし、受容機構の異なる複数のセンサを目的に応じて換装できるようにしても良い。
【００３３】
RF（230）は、アンテナと高周波回路より構成され、無線基地局や他のセンサチップとの間でデータを送受信する。通信に用いる無線周波数帯や、無線変調方式等によって、アンテナや高周波回路に採用すべき実装技術は異なってくる。
【００３４】
ROM（240）には、プログラムコードと、グローバルIDを含む各種パラメータが書き込まれている。センサチップ（101）の起動時、マイコン（250）がROM（240）からプログラムコードを読み出し、実行する。プログラムコードはOS（Operating System）を含んでいても良い。プログラムコードのバージョンアップやパラメータの変更等、センサチップ（101）の出荷後にROM（240）の内容を書き換える可能性がある場合には、フラッシュメモリ等の実装技術が利用できる。ただしグローバルIDの値はメーカが出荷前にセンサチップ毎に固定値を書き込むものであって、通常の運用においては出荷後に書き換えることは想定されない。
【００３５】
マイコン（250）は、プラグラムコードを実行することによってセンサチップ（101）の動作全体を制御する。ROM（240）やRAM（260）とだけではなく、センサ（220）やRF（230）ともデータの送受を行うので、これらの各機能部との間の入出力インタフェースを備える。また、センサ（220）やRF（230）からイベント駆動でデータを取り込むための割り込み機能や、定期的なセンシング、測定時刻の記録、データ送信時の再送制御等のためのタイマ機能等を備える。マイコン（250）の実装技術には、組み込み機器向けの汎用8ビットマイコンを使用しても良いし、センサネット向けに低消費電力特性や信号処理機能を向上させたカスタム品を使用しても良い。
【００３６】
RAM（260）は、センサチップ（101）が動作する際の作業記憶となる。ROM（240）内に書き込まれたプログラムコードがOSを含む場合、OSやOS上で動作する実行プロセスがRAM（260）上にロードされる。プログラムコードがOSを含まない場合、プログラムコードはRAM（260）上にロードされることなく、1命令づつ直接マイコン（250）に読み込まれ実行される。動作時には、RAM（260）はセンサ（220）から取得した測定値を保持したり、データ送受信時のパケットの生成や解析のための領域となる。特に本発明に関わり、初期登録時にサーバから割り当てられるローカルIDがRAM（260）上に記憶され、毎回の測定データの送信時に使用される。
【００３７】
図３に、無線基地局（111）の内部構成を示す。
電源（310）は、無線基地局（111）の各機能部が動作するための電力を供給する。最も標準的な給電方法は通常の家庭用電源に接続して外部給電する方法であるが、PoE（Power over Ethernet（登録商標）。）やUSBのような、有線の通信ケーブルを電力線としても利用する技術を使用しても良い。その場合にはNIF（320）が電源部の役割を兼ねる。また、センサチップの場合と同様に電池または発電機構を備えて内部給電しても構わない。
【００３８】
NIF（320）は、LAN（120）への通信インタフェースであり、サーバ（131）との間で通信を行う。典型的なインタフェースとしては10/100BASE-T、無線LAN、Bluetooth（登録商標）等がある。後述するようにサーバ（131）との通信ではネットワークレイヤにIP（Internet Protocol）を使用するので、NIF（320）にはIPアドレスが設定され、IPパケットの送受信機能が具備される。
【００３９】
RF（330）は、アンテナと高周波回路より構成され、センサチップが送信した測定データを受信したり、またサーバからの応答等をセンサチップへ送信する。無線基地局はセンサチップと比較して大きさや電力の制約が小さいので、2本以上のアンテナを用いるダイバーシティ技術や複雑な信号処理による干渉低減技術等を適用することができる。また、1台の無線基地局が多数のセンサチップと通信するため、無線多重化やパケット処理等にはセンサチップよりも高い性能が必要となる。
【００４０】
ROM（340）には、OSを含むプログラムコードと各種パラメータが書き込まれる。これらは一般的にファームウェアと呼ばれる。ファームウェアは出荷後にオンラインでアップデートする技術が普及しており、ROM（340）の実装技術としては、内容の書き換えが可能なフラッシュメモリを採用するのが一般的である。
【００４１】
CPU（350）は、プラグラムコードを実行することによって無線基地局（111）の動作全体を制御する。ROM（340）やRAM（360）とだけではなく、NIF（320）やRF（330）ともデータの送受を行うので、これらの各機能部との間の入出力インタフェースを備える。CPU（350）の実装技術には、組み込み機器向けの16ビットや32ビットのプロセッサを使用しても良いし、信号処理等の性能を向上させたカスタム品を使用しても良い。
【００４２】
RAM（360）は、無線基地局（111）が動作する際の作業記憶となる。ROM（340）からは、OSやOS上で動作する実行プロセスがRAM（360）上にロードされる。また、データ送受信時のパケットの生成や解析のための領域となる。
図４に、サーバ（131）の内部構成を示す。一般的なPCや業務用サーバと同様のアーキテクチャである。
【００４３】
電源（410）は、サーバ（131）の各機能部が動作するための電力を供給する。通常の家庭用電源や業務用電源に接続して外部給電する方法が一般的である。特に業務用途への適用に際しては、瞬断や停電等の電源異常に対応するための無停電電源装置（UPS）と併用することができる。
【００４４】
NIF（420）は、LAN（120）あるいはルータ（151）へ接続するための通信インタフェースであり、無線基地局（111〜113）、クライアント（141）、外部サーバ（171）との間で通信を行う。典型的なインタフェースとしては100BASE-TX、1000BASE-T、1000BASE-TX等がある。一般家庭用のような、小規模であったり高い信頼性を要求しないような用途であれば、無線LANのようなインタフェースを用いても良い。サーバ（131）の行う通信はネットワークレイヤにIPを使用するので、NIF（420）にはIPアドレスが設定され、IPパケットの送受信機能が具備される。
【００４５】
補助記憶（430）には、OSを含むプログラムコードと各種パラメータが書き込まれる。また補助記憶（430）には、センサチップから収集した測定データを管理するためのデータテーブル（431）が保持されたり、OSの仮想メモリ機能によって作業記憶領域が割り当てられたりする。補助記憶（430）の実装技術としては、センサチップの数やセンシングするデータ量の多い大規模なセンサネットシステム向けにはHDDを用いるのが適している。比較的小規模なセンサネットシステムであれば、数10〜数100メガバイト程度の記憶容量を持つフラッシュメモリ等でも良い。
【００４６】
CPU（440）は、プラグラムコードを実行することによってサーバ（131）の動作全体を制御する。また、補助記憶（430）、RAM（450）、NIF（320）との間でデータの送受を行うための入出力インタフェースを備える。CPU（440）の実装技術には、業務用途向けにはハイエンドの高速プロセッサを使用すれば良いし、一般家庭用等の小規模用途向けには組み込み機器向けの16ビットや32ビットのプロセッサを使用すれば良い。
【００４７】
RAM（450）は、サーバ（131）が動作する際の作業記憶となる。補助記憶（430）からは、OSやOS上で動作する実行プロセスがRAM（450）上にロードされる。また、RAM（450）は補助記憶（430）と比較してアクセス速度が速いので、アクセス頻度の高いデータや、高速アクセスが必要なデータは記憶容量が許す限りRAM（450）上に保持するのが良い。本発明の主要な構成要素の1つであるIDテーブル（451）はそのようなデータの1つである。
【００４８】
本図には示していないが、サーバ（131）はこの他にも、保守管理用のディスプレイ装置、キーボード、マウス等の入出力用のデバイスやインタフェースを備えていても良い。
外部サーバ（171）に関しては、本発明の詳細に規定するところではないが、一例として図４に示したサーバ（131）と同様の構成を想定することができる。
【００４９】
図５に、本実施例における各装置のプロトコルスタックを示す。プロトコルスタック図は、各装置のプロトコル機能の関連性を示したものである。論理的な接続関係と、各プロトコルレイヤの連携の仕方を示す。
センサチップ（101）のプロトコルスタックにおいて、RF-APLレイヤは、測定データを無線基地局に送信するためのフォーマットにカプセル化する。RF-NWレイヤは、グローバルIDおよびローカルIDを管理したり、送受信パケットの欠落や二重受信を検出する等の機能を提供する。RF-MACレイヤは、メッセージの種別を定義したり、フレームの誤り検出を行う等の機能を提供する。これらの各レイヤ機能は、マイコン（250）が実行するプログラムコードとして実装される。RF-PHYレイヤの機能はRF（230）に実装され、無線の符号化や多重化、無線信号の送受信等の機能を提供する。
【００５０】
本実施例では、グローバルIDおよびローカルIDはRF-NWレイヤにおいて管理されるものとしたが、実装によってはRF-MACレイヤにおいて管理しても良い。プロトコルスタックにおけるレイヤ間の機能分担に関するこのような議論は実装方法に関する問題であって、どのような機能分担による実装を行ったとしても本発明の基本原理に影響を与えるものではない。
【００５１】
センサチップ（101）は少なくとも1つの無線基地局と、直接的または間接的に無線通信を行う。例えばセンサチップ（101）と無線基地局（111）とが互いに通信可能なエリアに位置する場合には、両者は直接的な通信を行う。センサチップ（101）が無線基地局（111）と直接通信できない場合には、近隣のセンサチップ間でデータのマルチホップを行い、最終的に無線基地局（111）までデータを伝送しても良い。その場合、点線（501）で示した箇所に1つ以上のセンサチップが位置する。
【００５２】
無線基地局（111）においても、RF-PHYレイヤの機能はRF（330）に実装される。RF-MACレイヤ以上の無線側プロトコルと、TCP/IPレイヤ以上のLAN側プロトコルは、CPU（350）が実行するプログラムコードとして実装される。無線側プロトコルのうち、RF-NWレイヤおよびRF-APLレイヤの各機能は、LAN側プロトコルであるSN-APLレイヤへマッピングされる。マッピングの結果としてデータフォーマットの変換を伴っても構わないが、測定データ、グローバルID、ローカルID等の情報を欠落させることなく含める。SN-APLレイヤは、伝送レイヤにTCP/IPを用いる。実装によってはUDP/IPを用いても良いが、その場合には無線基地局（111）とサーバの間でパケットの欠落や二重受信の検出および再送制御を行う必要がある。この処理はSN-APLレイヤにマッピングされたRF-NWレイヤの機能によって実現される。Ether-MACレイヤおよび100BASE-Tレイヤの機能はNIF（320）に実装される。
無線基地局（111）とサーバ（131）の間には、無線LANアクセスポイント、スイッチングハブ、ルータ等、LANを構成する中継装置が1つ以上あっても良い。図中では点線（502）で示した箇所に位置する。
【００５３】
サーバ（131）は、TCP/IP上を伝送されてきたSN-APLレイヤを終端する。SN-APLレイヤによって収集された各センサチップからの測定データは、データテーブル（431）へ格納される。SN-APLレイヤは、センサチップからのデータを収集したり個々のセンサチップを制御したりするためシステム内プロトコルなので、外部サーバ（171）との通信においてはより汎用的なプロトコルを用いる。XML-APLレイヤは、データフォーマットにXML（Extensible Markup Language）を採用することにより、多様なシステム関連携への対応が可能な汎用性を備える。XML-APLレイヤのデータフォーマットをInternet（160）上で伝送するために、SOAP（Simple Object Access Protocol）およびHTTP（HyperText Transfer Protocol）を利用する。このような、XMLやHTTPを用いたアプリケーションプロトコルの設計方法やその上で実現されるサービスは「Webサービス」と呼ばれ、インターネットを介した電子商取引や多種多様な企業間連携に活用されている。外部サーバ（171）との通信にXML/HTTPの枠組みを採用することにより、多様なサービスプロバイダとの連携が可能になる。
【００５４】
サーバ（131）におけるTCP/IPレイヤ以上の各プロトコルは、CPU（440）が実行するプログラムコードとして実装される。一方、Ether-MACレイヤ以下はNIF（420）に実装される。なお本図では、サーバ（131）のネットワークインタフェースとして無線基地局（111）側とルータ（151）側の2つが別々にあるように見えるが、これはプロトコルスタック図の表現上の問題であって、必ずしもNIF（420）が2つの物理インタフェースを備えることを意味してはいない。IP通信は単一の物理インタフェース上で多重可能であるため、NIF（420）が単一の物理インタフェースしか有さなくても機能上の問題は発生しない。なお2つの物理インタフェースを備えた場合には、通信帯域の増強、通信経路の二重化、セキュリティ設計の容易化等の効果が得られる。
【００５５】
サーバ（131）とルータ（151）の間には、無線LANアクセスポイント、スイッチングハブ、ルータ等、LANを構成する中継装置が1つ以上あっても良い。図中では点線（503）で示した箇所に位置する。
ルータ（151）は、サーバ（131）と外部サーバ（171）の間の通信をIPレイヤで中継する。すなわち宛先IPアドレスから転送先のインタフェースを決定する。設定に応じて、パケットに対してNATやパケットフィルタリング等の処理を施しても良い。
【００５６】
ルータ（151）と外部サーバ（171）の間では、Internet（160）を構成するルータ、長距離伝送装置等を複数経由するのが一般的である。また、ルータ（151）や外部サーバ（171）が企業のネットワーク内に設置された場合やISPを経由してInternet（160）へアクセスする場合には、それらのネットワークを構成するゲートウェイ、ルータ、スイッチ等も経由する。これらの各種装置は図中では波線（504）で示した箇所に位置する。
外部サーバ（171）は、サーバ（131）からのXML-APLレイヤを終端する。また、バックエンドの各種のデータベース、アプリケーションサーバ、さらには他のサービスプロバイダがインターネット上で公開する別の外部サーバと連携しても構わない。このような多種多様な連携は、Webサービスの持つ汎用性によって容易に実現することができる。
【００５７】
本図では、LAN（120）内やシステム外の通信におけるMACレイヤおよびPHYレイヤを一律にEther-MACおよび100BASE-Tとしたが、IPレイヤを伝送するためのMACレイヤやPHYレイヤには多様な種類があり、それらのうちいずれを用いても構わない。例えばルータ（151）をInternet（160）に接続するためのアクセス回線にはADSLや光ファイバを用いても構わないし、Internet（160）を構成する通信事業者のネットワーク内ではMACレイヤにMPLSを、PHYレイヤにOC-192を用いても構わない。
なお、本発明に大きく関わらないためクライアント（141）についての説明は本図には含めなかったが、一例として、外部サーバ（171）と同様にXML-APLを用いてサーバ（131）と通信するといった実装が可能である。
【００５８】
図６に、センサチップ初期登録時の通信シーケンスを示す。
センサチップ（10１）が初期起動状態（621）から登録要求メッセージ（611）を送信し、登録待ち状態（622）へ遷移する。登録要求メッセージ（611）を受信した無線基地局（111）は、プロトコル変換（631）を行った上で該メッセージをサーバ（131）へ転送する。転送された登録要求メッセージ（612）を受信したサーバ（131）はローカルIDを割り当て（641）、登録完了メッセージ（613）を無線基地局（111）へ返送する。無線基地局（111）は、プロトコル変換（632）を行った上で該メッセージをセンサチップ（101）へ転送する。転送された登録完了メッセージ（614）を受信したセンサチップ（101）はローカルIDを記憶し（623）、運用状態（624）へ遷移する。
【００５９】
本実施例ではローカルIDの割り当てのみを行う初期登録シーケンスを示しているが、初期登録シーケンスを利用して、暗号化通信の設定、通信間隔の設定、その他各種通信パラメータの設定等、センサチップ（101）とサーバ（131）の間での各種のネゴシエーションを実行することも可能である。
【００６０】
図７に、初期登録時におけるセンサチップ（101）の動作フローを示す。
センサチップ（101）は、初期起動状態（621）から登録要求メッセージ（611）を送信する。該メッセージ中には自身のグローバルID値が格納される。メッセージ送信後、タイマを起動し（701）、登録待ち状態（622）へ遷移する。登録待ち状態（622）は、サーバからの登録完了メッセージ（614）を受信するための待機時間であり、タイマは待機時間の長さを設定する。タイムアウト時間T1は、無線通信や有線通信における通信ノイズによるパケットロス、LAN（120）の輻輳、サーバ（131）の過負荷等がない状況において確実に登録完了メッセージ（614）が返送されるであろう応答時間を基準として設定し、典型的には数秒程度である。登録完了メッセージ（614）を受信せずにタイムアウトが発生した場合の代表的な処理は、前記のような通信障害が発生したとみなして登録要求メッセージを再送することである。本図では、タイムアウト前に登録完了メッセージ（614）を受信した場合を示している。登録完了メッセージ（614）を受信するとタイマを停止し（702）、該メッセージに格納されたローカルID値をRAM（260）に記憶し（623）、運用状態（624）へ遷移する。運用状態（624）における通信では該ローカルIDを使用する。
【００６１】
図８に、初期登録時における無線基地局（111）の動作フローを示す。
無線基地局（111）は、受信待ち状態（801）においてセンサチップ（101）からの登録要求メッセージ（611）を受信すると、図５に示したプロトコルスタックに従って該メッセージを無線側プロトコルのデータフォーマットからLAN側プロトコルのデータフォーマットへ変換し、変換後の登録要求メッセージ（612）をサーバ（131）へ転送し、受信待ち状態（802）へ戻る。サーバ（131）からの登録完了メッセージ（613）を受信した場合も同様のフローを実行し、LAN側プロトコルのデータフォーマットから無線側プロトコルのデータフォーマットへ変換した上で変換後の登録完了メッセージ（614）をセンサチップへ転送する。
【００６２】
図９に、初期登録時におけるサーバ（131）の動作フローを示す。
サーバ（131）が受信待ち状態（901）においてセンサチップ（101）からの登録要求メッセージ（612）を受信すると、該メッセージ中に格納されたグローバルID値に対して、新たにシステム内で一意なローカルID値を割り当て、IDテーブル（451）に両ID値の組を登録する（641）。さらに、センサチップ（101）の構成情報や測定データを格納するためのデータテーブル（431）のエントリを作成する（902）。その後、センサチップ（101）に向けて登録完了メッセージ（613）を送信し、受信待ち状態（903）へ戻る。
【００６３】
図１０に、サーバ（131）の管理するIDテーブル（451）の構成を示す。
IDテーブル（451）は、個々のセンサチップに対応するエントリより構成され、各々のエントリは、グローバルID、ローカルID、データテーブル（431）へのインデックスにより構成される。本図では、グローバルIDが128ビット、ローカルIDが8ビットの場合を示している。見やすさのために、両ID値は16進数で表記し、またグローバルID値は16ビット毎にコロン（：）で区切って表記している。
【００６４】
本IDテーブル（451）は、グローバルIDからローカルIDへの変換、ローカルIDからグローバルIDへの変換に使用される。また、グローバルIDまたはローカルIDをキーとしてデータテーブル（431）へのインデックス値を取得するためにも使用される。インデックス値の示す先には、対応するセンサチップの情報が格納される。
【００６５】
データテーブル（431）には、個々のセンサチップの構成情報や測定データが格納される。測定データの例としては、生データである測定値そのもの、前記測定値をSI単位に変換した値、測定時刻等が挙げられる。センサチップの構成情報の例としては、製造元メーカ、センサの種類、電源容量、無線周波数をはじめとする通信パラメータ等が挙げられる。これらの構成情報を取得する手段の例としては、ユーザが手動で設定する、センサチップの製品パッケージに添付された媒体からインストールする、メーカのサポート用Webサイトからオンラインで取得する、センサチップの初期登録時または初期登録後の設定シーケンスにおいてセンサチップから自動的に取得する等の手段が挙げられる。
【００６６】
ローカルIDはシステム内で一意な値となるようにサーバ（131）が管理する。8ビットのローカルIDを使用する本実施例では最大で256個のセンサチップを収容可能である。本テーブルは頻繁に参照され、また検索の高速性が求められるので、サーバ（131）のRAM（450）上で管理される。検索を高速化するための汎用的な技術として、検索専用メモリであるCAM（Contents Addressable Memory）や、多数のデータを効率的に管理するアルゴリズムであるハッシュ法等を使用することができる。
【００６７】
図１１に、センサチップ（101）と無線基地局（111）の通信において使用される無線フレームの構成を示す。
各フィールドは、1111〜1116の順番で無線伝送される。Frame Length（1111）とMessage Type（1112）はRF-MACレイヤのヘッダである。Local ID（1113）とSequence Number（1114）はRF-NWレイヤのヘッダである。Data（1115）はRF-APLレイヤのデータである。FCS（1116）はRF-MACレイヤのトレイラである。
【００６８】
登録要求を表すMessage Type（1112）の値は0x1である。登録要求メッセージ（611）において、Local ID（1113）の値は割り当て前であることを示す0x00である。Sequence Number（1114）の値は、センサチップ（101）が起動してから最初のメッセージシーケンスであることを示す0x01である。Data（1115）には、センサチップ（101）のグローバルID値が格納される。Frame Length（1111）の値は0x12である。これは、RF-MACレイヤのヘッダおよびトレイラを除いたペイロード部、すなわちLocal ID（1113）、Sequence Number（1114）、Data（1115）の合計が18オクテットであることを示す。FCS（1116）には、自身を除くRF-MACフレーム全体、すなわち（1111〜1115）に対するCRC（Cyclic Redundancy Check）の演算結果が格納される。
【００６９】
登録完了を表すMessage Type（1112）の値は0x2である。登録完了メッセージ（614）において、Local ID（1113）の値はサーバ（131）によってセンサチップ（101）に対して割り当てられた一意な値0x5aである。Sequence Number（1114）の値は、本メッセージが登録要求メッセージ（611）に対する応答であるため、登録要求メッセージ（611）における値0x01を引き継ぐ。Data（1115）には、本メッセージがセンサチップ（101）に宛てたものであることを示すために、登録要求メッセージ（611）に格納されていたセンサチップ（101）のグローバルID値がそのまま返送される。グローバルID以外にも、サーバ（131）からセンサチップ（101）に通知するための各種情報をData（1115）に含めても良い。このような情報の代表的な例として、無線通信や暗号化通信に関わる動作パラメータが挙げられる。
【００７０】
無線基地局（111）とサーバ（131）の通信において使用されるパケットは、図５において示したようにTCP/IPによってカプセル化される。最も単純な実装では、SN-APLレイヤのデータフォーマットは、図１１に示した無線フレームがそのまま格納されたものであって構わない。あるいは、簡単なフォーマット変換を施して、テキスト形式に直したものであっても良い。より高度な実装においては、XMLのように構造化されたテキスト形式のフォーマットに変換することも可能であろう。後に示す図１８や図１９はXMLフォーマットの一例であり、これらと同様の構造を有するSN-APLレイヤのデータフォーマットを設計することは容易であろう。SN-APLレイヤのデータフォーマットの設計の際にはいくつかの異なる観点が考えられ、基地局における実装が簡単となるようにするという観点や、基地局における実装が多少複雑になっても、サーバにおいてデータテーブル（431）への登録のためにより都合が良いようなフォーマットにするという観点がある。実装者は自身のシステムに最適な観点に基づいてSN-APLレイヤのデータフォーマットを設計して構わない。
【００７１】
図１２に、センサチップ（101）からサーバ（131）へのデータ収集時の通信シーケンスを示す。
センサチップ（101）は運用状態（1221）において、設置された環境に対して定期的にセンサ（220）による測定を行い、測定データを無線送信した後に応答待ち状態（1222）へ遷移する。測定データメッセージ（1211）を受信した無線基地局（111）は、プロトコル変換（1231）を行った上で該メッセージをサーバ（131）へ転送する。転送された測定データメッセージ（1212）を受信したサーバ（131）は測定データをデータテーブル（431）へ登録し（1241）、確認応答メッセージ（1213）を無線基地局（111）へ返送する。無線基地局（111）は、プロトコル変換（1232）を行った上で該メッセージをセンサチップ（101）へ転送する。転送された確認応答メッセージ（1214）を受信したセンサチップ（101）は運用状態（1223）へ戻る。
【００７２】
図１３に、データ収集時におけるセンサチップ（101）の動作フローを示す。
センサチップ（101）は、運用状態（1221）のある時点において測定データメッセージ（1211）を送信する。送信処理を起動するタイミングとしては、毎回のデータ測定の都度送信する方法、RAM（260）に記憶しておいた複数回分の測定データをまとめて送信する方法、サーバ（131）からのデータ収集要求への返送として送信する方法等がある。測定データメッセージ（1211）では、初期登録時にサーバ（131）から割り当てられたローカルIDが使用される。メッセージ送信後、タイマを起動し（1301）、応答待ち状態（1222）へ遷移する。応答待ち状態（1222）は、サーバ（131）からの確認応答メッセージ（1214）を受信するための待機時間であり、タイマは待機時間の長さを設定する。タイムアウト時間T2は、典型的には初期登録時のタイムアウト時間T1と同じ長さである。タイムアウトが発生した場合の代表的な処理は、初期登録時と同様に測定データメッセージを再送することであるが、該測定データを次回のデータ収集時まで保持しておき、次回に改めて送信しても良い。本図では、タイムアウト前に確認応答メッセージ（1214）を受信した場合を示している。確認応答メッセージ（1214）を受信するとタイマを停止し（1302）、運用状態（1223）へ戻る。該測定データは、サーバ（131）のデータテーブル（431）へ登録されたことが確実であるので、センサチップ（101）は確認応答メッセージ（1214）を受信した時点で該測定データをRAM（260）から消去しても構わない。
【００７３】
データ収集時における無線基地局（111）の動作フローは、図８に示したのと同様である。本実施例においては、無線基地局（111）はセンサチップ（101）とサーバ（131）との通信を単純なデータフォーマットの変換のみを施して転送するのみであって、受信したメッセージがどのようなものであるかによって動作を変える必要はなく、RF（330）から受信したメッセージはNIF（320）へ転送し、NIF（320）から受信したメッセージはRF（330）へ転送するというような機械的な動作であって構わない。
【００７４】
図１４に、データ収集時におけるサーバ（131）の動作フローを示す。
サーバ（131）が受信待ち状態（1401）においてセンサチップ（101）からの測定データメッセージ（1212）を受信すると、該メッセージ中に格納された測定データをデータテーブル（431）へ登録する（1241）。登録処理の手順としては、まず該メッセージ中に格納されたローカルIDを取得し、本ローカルID値をキーとしてIDテーブル（451）を検索する。その結果、センサチップ（101）に対応するデータテーブル（431）へのインデックス値が得られる。本インデックス値を用いてデータテーブル（431）へアクセスし、該メッセージ中に格納された測定データを所定のフォーマットで登録する。登録処理（1241）の完了後、センサチップ（101）に向けて確認応答メッセージ（1213）を送信し、受信待ち状態（1402）へ戻る。
【００７５】
データ収集時の無線フレームの構成は、図１１に示す通りである。
測定データを表すMessage Type（1112）の値は0x3である。測定データメッセージ（1211）において、Local ID（1113）の値はサーバ（131）によって割り当て済みである一意な値0x5aである。Sequence Number（1114）の値は、前回のメッセージシーケンスの際に使用した値に1を加えた値であり、初期登録シーケンスの後の最初のシーケンスである場合を想定して図１１では0x02としている。Data（1115）には、測定値そのものや測定値に関連する付加情報を格納することができ、図１１では付加情報としてセンサ種別と測定時刻を格納する例を示している。センサ種別は、該測定値が例えば温度センサの測定値であることを示す。測定時刻は、実際の測定から測定データの送信までに時間差がある場合には必須であり、秒単位、ミリ秒単位等の必要な精度を持たせる。
【００７６】
確認応答を表すMessage Type（1112）の値は0x4である。確認応答メッセージ（1214）において、Sequence Number（1114）の値は、本メッセージが測定データメッセージ（1211）に対する応答であるため、測定データメッセージ（1211）における値0x02を引き継ぐ。Data（1115）には、必要に応じてサーバ（131）からセンサチップ（101）に通知するための各種情報を含めても良い。
【００７７】
以上のように、データ収集時にはセンサチップ（101）とサーバ（131）の両方が、ローカルID値0x5aによってセンサチップ（101）を識別できる状態にあるため、測定データメッセージ（1211）および確認応答メッセージ（1214）ではローカルID値のみを用いてセンサチップ（101）を識別することができ、グローバルID値を使用する必要はない。
【００７８】
図１５に、本センサネットシステムが外部サーバ（171）と通信する際の、通信シーケンスの一例を示す。
外部サーバ（171）との直接の通信はサーバ（131）が行う。外部サーバ（171）はまずクエリ（1511）をサーバ（131）へ送信する。本クエリは、サーバ（131）の保持するデータテーブル（431）の参照（1522）等によってサーバ（131）単体で応答することができる種類のものである。このようなクエリの例として、本センサネットシステムにおいて現在稼動中のセンサチップの一覧の取得、特定のセンサチップの過去の測定データの取得等が挙げられる。サーバ（131）は本クエリに対してアンサ（1512）によって応答する。
クエリ（1511）およびアンサ（1512）においては、センサチップを示す識別情報はグローバルIDである。ローカルIDはシステム内でのみ有効な識別情報であるのでシステム外通信においては使用しない。
【００７９】
次に、外部サーバ（171）はクエリ（1513）をサーバ（131）へ送信する。本クエリは、サーバ（131）単体で応答することができず、センサチップ（101）への問い合わせ等が必要となる種類のものである。このようなクエリの例として、現在時刻における測定データの取得、センサチップ（101）の動作パラメータの変更要求等が挙げられる。サーバ（131）はクエリ（1513）への応答のためにセンサチップ（101）への問い合わせが必要と判断すると、センサチップ（101）へクエリ（1514）を発行する。クエリ（1514）は、クエリ（1513）を単にプロトコル変換して転送したものであっても良いし、クエリ（1513）を元に意味的に再構成したものであっても良い。いずれであっても、クエリ（1513）ではセンサチップ（101）の識別情報としてグローバルIDを使用し、クエリ（1514）ではローカルIDを使用する。サーバ（131）はこのためのID変換を行う（1524）。
【００８０】
クエリ（1514）は、無線基地局（111）においてプロトコル変換され（1531）、センサチップ（101）へ転送される。センサチップ（101）はクエリ（1515）の内容に応じた処理、例えばセンシング等を実行し（1541）、アンサ（1516）を返送する。本アンサは無線基地局（111）においてプロトコル変換され（1532）、サーバ（131）へ転送される。サーバ（131）はアンサ（1517）に含まれるローカルIDをグローバルIDに変換し（1526）、アンサ（1518）を外部サーバ（171）へ返送する。
【００８１】
クエリ（1511）とクエリ（1513）は、内容的に独立した2つのクエリであっても良いし、クエリ（1511）に対するアンサ（1512）を受けてクエリ（1513）が発行されるというように一続きのシーケンスを構成しても良い。一続きのシーケンスである場合の典型的な例として、クエリ（1511）によって特定の条件にマッチするセンサチップを問い合わせ、該当するセンサチップに対してクエリ（1513）で詳細な問い合わせを行うというシーケンスが挙げられる。
【００８２】
図１６に、サーバ（131）がクエリ（1511）を受信してからアンサ（1512）を返送するまでの動作フローを示す。
受信待ち状態（1521）においてクエリ（1511）を受信し、クエリ内容に応じてデータテーブル（431）を参照する（1522）。データテーブル（431）の参照のためには必要に応じてIDテーブル（451）を参照し、検索対象となるセンサチップに対応するインデックス値を取得する。データテーブル（431）の参照結果からアンサ（1512）を生成し、外部サーバ（171）へ送信後、受信待ち状態（1523）へ戻る。
【００８３】
図１７に、サーバ（131）がクエリ（1513）を受信してからアンサ（1518）を返送するまでの動作フローを示す。
受信待ち状態（1523）においてクエリ（1513）を受信すると、クエリ内容を解析し、センサチップ（101）への問い合わせが必要だと判断する。クエリ（1513）に含まれるグローバルID値をキーとしてIDテーブル（451）を検索し、対応するローカルID値を得（1524）、またXML-APLからSN-APLへのプロトコル変換を行う。必要であればクエリ内容の再構成も行う。このようにしてクエリ（1514）を生成し、センサチップへ向けて転送する（1701）。クエリ転送後、タイマを起動し（1702）、応答待ち状態（1525）へ遷移する。応答待ち状態（1525）は、センサチップ（101）からのアンサ（1517）を受信するための待機時間であり、タイマは待機時間の長さを設定する。タイムアウト時間T3は、無線通信や有線通信における通信ノイズによるパケットロス、LAN（120）の輻輳、センサチップ（101）の動作異常等がない状況において確実にアンサ（1517）が返送されるであろう応答時間を基準として設定し、典型的には数秒程度である。アンサ（1517）を受信せずにタイムアウトが発生した場合の代表的な処理は、前記のような通信障害が発生したとみなしてクエリ（1514）を再送することである。本図では、タイムアウト前にアンサ（1517）を受信した場合を示している。アンサ（1517）を受信するとタイマを停止する（1704）。アンサ（1517）中に含まれるローカルID値をキーとしてIDテーブル（451）を検索し、対応するグローバルID値を得（1526）、またSN-APLからXML-APLへのプロトコル変換を行う。必要であればアンサ内容の再構成も行う。このようにしてアンサ（1518）を生成し、外部サーバ（171）へ向けて転送（1518）した後に、受信待ち状態（1527）へ戻る。
【００８４】
図１８に、クエリ（1511）におけるXML-APLレイヤのフォーマットを示す。
行（1801）は、本クエリがXMLフォーマットに従うことを表す。
本文全体は行（1802）と（1830）に挟まれ、センサネットワーク向けに規定されたサービス規約に従うものであることを表す。
【００８５】
行（1803）、（1804）、（1805）はそれぞれ、本クエリの発行日時、発行元である外部  サーバ（171）の識別子、宛先であるサーバ（131）の識別子を表す。
クエリ（1511）の実体は行（1806）と（1829）に挟まれて記述される。
行（1807）は本クエリの識別子を表す。
行（1808）と（1812）で挟まれた部分はアンサの出力形式に関する記述であり、アンサ（1512）が、センサチップのID、すなわちグローバルIDを一覧形式で出力することを要求するものである。
【００８６】
行（1813）と（1828）で挟まれた部分は検索条件に関する記述である。検索条件の全体は行（1814）と（1827）に挟まれており、センサチップに関する記述であることを意味している。行（1815）は、溶接ルームに設置されたセンサチップが対象であることを表す。行（1816）と（1826）で挟まれた部分はセンサに関する記述である。行（1817）は温度センサを有するセンサチップが対象であることを表す。行（1818）と（1825）で挟まれた部分は測定データに関する記述である。行（1819）は、本日、すなわち本クエリの発行日である2004年7月12日の測定データが対象であることを表す。行（1820）と（1824）で挟まれた部分は測定データに関する条件式である。行（1821）、（1822）、（1823）により、摂氏28.0度以上という条件式が規定される。
このように、図１８のXMLフォーマットによって構成されるクエリ（1511）の意味は、「2004年7月12日の溶接ルームの室温として摂氏28.0度以上を測定したセンサチップの一覧を表示せよ」となる。
【００８７】
図１９に、アンサ（1512）におけるXML-APLレイヤのフォーマットを示す。
行（1901）は、本アンサがXMLフォーマットに従うことを表す。
本文全体は行（1902）と（1920）に挟まれ、センサネットワーク向けに規定されたサービス規約に従うものであることを表す。
行（1903）、（1904）、（1905）はそれぞれ、本アンサの発行日時、発行元であるサーバ（131）の識別子、宛先である外部サーバ（171）の識別子を表す。
【００８８】
アンサ（1512）の実体は行（1906）と（1919）に挟まれて記述される。
行（1907）は本アンサの識別子を表す。
行（1908）と（1910）で挟まれた部分は元のクエリ（1511）の識別子であり、本アンサがクエリ（1511）に対する応答であることを表す。行（1911）は本アンサがクエリ（1511）に対する正常応答であることを表す。
行（1912）と（1918）で挟まれた部分は、クエリ（1511）で指定された出力形式に従った検索結果の表示であり、条件にマッチしたセンサチップのグローバルIDの一覧である。
【００８９】
このように、図１９のXMLフォーマットによって構成されるアンサ（1512）は、クエリ（1511）を受けてサーバが自身のデータテーブル（431）を検索した結果、検索条件にマッチしたセンサチップを3つ発見し、それらのグローバルIDを回答している。
クエリ（1513）、アンサ（1518）に関しても、図１８、図１９と同様のフォーマットにより記述される。
クエリ（1514）は、SN-APLレイヤのフォーマット規約に従い記述される。XMLのようなテキストベースの構造化フォーマットであっても良いし、図１１に示したようなバイナリベースのフォーマットであっても良い。アンサ（1517）に関しても同様である。
クエリ（1515）、アンサ（1516）は、図１１に示したのと同様のフォーマットにより記述される。
【００９０】
これらのフォーマットの詳細に関しては種々の実装が可能であるが、本発明の適用範囲は個々のフォーマットの違いに左右されるものではない。本発明の意図する点は、これらのフォーマットがいかなるものであったとしても、センサチップの識別子として、クエリ（1511）、アンサ（1512）、クエリ（1513）、アンサ（1518）のようなシステム外通信においてはグローバルIDを用い、クエリ（1514）、クエリ（1515）、アンサ（1516）、アンサ（1517）のようなシステム内通信においてはローカルIDを用いる、という点である。
【００９１】
本実施例では外部サーバ（171）がサーバ（131）に対して通信を発行する例を示したが、サーバ（131）が外部サーバ（171）に対して通信を発行しても構わない。また、送受信するメッセージの種別をクエリ＆アンサの形態に限定したり、XMLを用いた実装に限定する必要もない。例えば、TELNETやSNMPといったプロトコルを用いた実装を行っても構わない。
【実施例２】
【００９２】
実施例１では、ローカルIDは8ビット固定長であった。これに対して本実施例では、ローカルIDがシステム内で可変長である。
図２０に、本実施例においてサーバ（131）の管理するIDテーブル（451）の構成を示す。
グローバルIDは図１０と同様に128ビットである。一方、ローカルIDはセンサチップ毎に異なるビット長の値が割り当てられる。図２０では、グローバルIDは16進数で表記しているが、ローカルIDはビット長が可変であることが見やすいように2進数で表記している。
【００９３】
図１０との違いの1つは、センサチップの各々について通信コストが管理される点にある。通信コストとは、個々のセンサチップにおける無線通信処理のコストを消費電力の観点から評価した量である。
【００９４】
図２１に、本実施例における通信コストの算定式を示す。
本図の定義によれば、電源容量（Cap）が大きいほど通信コスト（Cost）は小さくなる。また、1ビットの送受信に要する電力（W）が大きいほど通信コスト（Cost）は大きくなる。また、1フレームのビット長（L）が大きいほど通信コスト（Cost）は大きくなる。また、送受信頻度（F）が大きいほど通信コスト（Cost）は大きくなる。
【００９５】
すなわち、通信コスト（Cost）が大きいセンサチップほど動作可能な時間が短い。通信コスト（Cost）を決定付ける個々のパラメータはセンサチップ毎に異なる値を取り得るが、通信コスト（Cost）は各パラメータの寄与を総合し、動作寿命に関する一元的な評価指標を与える。
通信コストの算定式においては、W、L、Fの各パラメータを送信時と受信時に分けて評価したり、センサやマイコンの消費電力のような、本図に示した以外の要素を加味しても良い。また、無線通信の周波数帯、符号化方式、多重化方式等に関してさらに詳細な定式化も可能である。通信コストの定義は、実用的な運用にとって必要なだけの詳細化を行っても良いし、また逆に簡略化を行っても良い。
【００９６】
図２０におけるセンサチップ（102）と（103）の通信コスト（Cost）はそれぞれ6.2と8.1であるため、図１０に示した8ビット固定長のローカルIDを使用した場合には、センサチップ（103）はセンサチップ（102）の77％程度の動作寿命しか持たないことになる。本実施例によれば、このような状況においても個々のセンサチップの寿命のばらつきをなるべく平滑化し、システム全体としての寿命を延ばすことができる。図２０では、通信コスト（Cost）の大きいセンサチップに対してはビット長の小さいローカルIDを割り当て、通信コスト（Cost）の小さいセンサチップに対してはビット長の大きいローカルIDを割り当てている。これにより1フレームのビット長（L）が変化し、通信コスト（Cost）の差を相殺しようとする効果を生む。無線フレーム構成のローカルID以外の部分が図１１に示した構成と同様であるという条件の下で、図２０に示したようにセンサチップ（102）には1ビットのローカルIDを、センサチップ（103）には8ビットのローカルIDを割り当てると、1ビットの送受信に要する電力（W）が送信時と受信時で同一であると仮定すると、動作寿命の比は87％程度にまで緩和される。
【００９７】
固定長であるグローバルIDに対して可変長であるローカルIDを割り当てる方法には、データ圧縮の分野で広く用いられる各種のＦＶ符号（Fixed-Variable Length Code）を適用することができる。
【００９８】
FV符号の代表的なものにハフマン符号がある。本実施例においてハフマン符号を適用すれば、システム全体としての通信コストを理論的に最小にすることができる。また、ハフマン符号は接頭符号（Prefix Code）と呼ばれる性質を有しており、上位ビットから順にマッチングを取ることによってどの符号であるか一意に確定することができる。そのため、フレームフォーマットにおいてローカルIDのビット長を指定するフィールドを別途設ける必要がない。すなわち、本実施例においても図１１に示した無線フレーム構成をそのまま適用することができる。
【００９９】
ハフマン符号の通常の適用先であるデータ圧縮では、出現率の高いデータに対してビット長の小さい符号を割り当てる。本実施例においてハフマン符号化のアルゴリズムを適用するにあたっては、「符号化対象のデータ」を「グローバルID」に、「データの出現率」を「通信コスト」に置き換える。すなわち、通信コストの大きいセンサチップのグローバルIDに対してビット長の小さいローカルIDを割り当てるようにハフマン符号化のアルゴリズムを適用する。
【０１００】
本実施例においては、センサチップ各々の通信コストが運用前にあらかじめ固定的に分かる場合と、運用中に動的に変化する場合とがある。運用前にあらかじめ固定的に分かる場合の例として、センサチップの出荷時の製品仕様から固定的に算出可能な場合、センサチップの測定間隔、測定データ送信間隔、送信電力強度等の動作パラメータをユーザが明示的に設定する場合等がある。運用中に動的に変化する場合の例として、複数の部品を組み合わせて運用する等の理由によりセンサチップの出荷時の製品仕様から固定的に算出不可能な場合、前記のようなセンサチップの動作パラメータが運用中に動的に変化する場合、センサチップの電源が太陽光発電装置や微小振動発電装置等の発電装置であって電力残量が増減する場合、等である。
【０１０１】
センサチップ各々の通信コストが運用前にあらかじめ固定的に分かり、かつ運用中に新たなセンサチップが追加されたり使用中だったセンサチップが除去されることが少ない場合には、システム全体の導入時に全てのセンサチップの初期登録を一括して行い、可変長のローカルIDを各センサチップに固定的に割り当てた状態で運用することにより、以後の運用における個々のセンサチップの寿命のばらつきの平滑化と、システム全体としての寿命の延長を達成することができる。
【０１０２】
センサチップ各々の通信コストが運用中に動的に変化する場合や、センサチップ各々の通信コストが運用前にあらかじめ固定的に分かる場合であっても運用中に新たなセンサチップが追加されたり使用中だったセンサチップが除去されることが多い場合には、センサチップ間の通信コストの大小関係が運用中に動的に変化し得るため、初期登録によって最初に割り当てたローカルIDを固定的に使用し続けても、個々のセンサチップの寿命のばらつきの平滑化や、システム全体としての寿命の延長を達成できるとは限らない。このような場合には、定期的あるいは必要になった時点で個々のセンサチップに対してローカルIDを割り当て直すことによって対応することができる。
【０１０３】
ローカルIDの動的な再割り当てを実現するための通信シーケンスには複数の方法が考えられるであろう。一つの実現方法としては、図６に示したような、初期登録時と同様の通信シーケンスを実行することである。これはセンサチップがサーバに対してローカルIDの再割り当てを要求するという方法であり、センサチップが自身の運用中の通信コスト値を算出する手段を有する場合に最も効率良く機能する。センサチップが自身の運用中の通信コスト値を算出する手段を有さない場合の最も単純な方法は、定期的にセンサチップが再割り当てを要求するシーケンスを起動することである。例えば平均的な動作寿命の一割の期間毎に起動すれば良い。図６に示したのと若干異なる通信シーケンスによる別の実現方法として、サーバがローカルIDの再割り当ての必要性を判断し、再割り当てしたい新たなローカルID値をセンサチップへ通知することである。
【０１０４】
本シーケンスはサーバが起動するものであるので、サーバが各々のセンサチップの運用中の通信コスト値を算出する手段を有する場合に適する。さらに別の通信シーケンスによる実現方法では、各センサチップが定期的またはサーバからの指示により自身の運用中の通信コスト値を前記サーバへ通知し、全てのセンサチップからの通信コスト値を収集した前記サーバが前記全てのセンサチップに対してローカルIDの再割り当ての必要性を判断し、再割り当てが必要と判断した時点で全てのセンサチップに対して再割り当てを実行する。
【０１０５】
前記のように、ローカルIDの動的な再割り当てを実現するための通信シーケンスは様々な方法が用いられ得るが、どのような実現方法に拠ったとしても本発明の基本原理に影響を与えるものではない。
【０１０６】
以上のように、本実施例ではローカルIDがシステム内で可変長であることを特徴としている。なお、実施例１ではローカルIDはシステム内で固定長であったが、当該システムの規模に応じてローカルIDのビット長を選択することは可能である。例えば実施例１に拠る複数のセンサネットシステムAとBがあった場合に、センサネットシステムAにおけるローカルIDは8ビット固定長であって、センサネットシステムBにおけるローカルIDは16ビット固定長であっても構わない。この場合、センサネットシステムAは最大256個のセンサチップを収容することができ、センサネットシステムBは最大65536個のセンサチップを収容することができる。
【実施例３】
【０１０７】
実施例１および実施例２では、サーバ（131）においてローカルIDを割り当て、グローバルIDとローカルIDの関連付けおよび変換もサーバ（131）において行う方法を示した。本発明にはこれ以外にもいくつかの変形が可能である。
本実施例では、サーバ（131）においてローカルIDを割り当てるが、グローバルIDとローカルIDの関連付けを無線基地局（111）が記憶し、無線基地局（111）がセンサチップ（101）とサーバ（131）の間の通信を仲介する際にグローバルIDとローカルIDを相互に変換する。
【０１０８】
図２２に、本実施例におけるセンサチップ初期登録時の通信シーケンスを示す。
各装置間で送受されるメッセージシーケンスは、図６に示した実施例１の場合と同等である。図６との違いは、無線基地局（111）がサーバ（131）からの登録完了メッセージ（613）をセンサチップ（101）へ転送する際に、グローバルIDとローカルIDの関連付けを自身の有するIDテーブルへ登録すること（2201）である。
【０１０９】
図２３に、本実施例におけるデータ収集時の通信シーケンスを示す。
各装置間で送受されるメッセージシーケンスは、図１２に示した実施例１の場合と同等である。図１２との違いは、無線基地局（111）がセンサチップ（101）からの測定データメッセージ（1211）をサーバ（131）へ転送する際に、ローカルIDをグローバルIDに変換すること（2301）、またサーバ（131）からの確認応答メッセージ（1213）をセンサチップ（101）へ転送する際に、グローバルIDをローカルIDに変換すること（2302）である。
【０１１０】
各装置の機能構成や動作フローに関しても、実施例１に若干の変更を加えることで本実施例の構成を容易に実現できることは明らかであろう。以下では若干の補足を行う。
センサチップ（101）の機能構成や動作フローは実施例１の場合と全く同等である。無線基地局（111）は、実施例１においてサーバ（131）が保持していたIDテーブル（451）と同様の、グローバルIDとローカルIDを関連付けるためのIDテーブルを管理する。図２２に示したように、本テーブルのエントリは登録完了メッセージ（613）の転送時に登録される。サーバ（131）は、センサチップを基本的にはグローバルIDによって識別するので、システム内通信とシステム外通信を仲介する際にも、グローバルIDとローカルIDの相互変換を行う必要がない。ただし、個々のセンサチップに割り当てるローカルIDの一意性を保証する必要があるので、IDテーブル（451）もしくは類似の代替手段によってグローバルIDとローカルIDの関連付けを管理する必要性は残るであろう。
【０１１１】
本実施例では、ローカルIDはセンサチップから無線基地局までの無線通信においてのみ使用され、システム内通信であっても無線基地局からサーバまでの通信ではグローバルIDが使用される。従って、サーバが送受信するプロトコルおよびデータ形式を、システム内通信であってもシステム外通信であってもXML-APLに統一することも可能である。XMLを含むWebサービス関連技術は分散型、相互連携型のネットワークアプリケーションの標準技術として広く普及しており、オープンな開発環境の整備も進んでいる。センサネットシステムにおいてもWebサービス関連技術の適用を進めていくことによって、システム開発の容易化、機能拡張性の向上、複雑なアプリケーション連携の容易化等の効果が得られるであろう。
【実施例４】
【０１１２】
実施例１では、外部サーバ（171）との通信において個々のセンサチップを識別するのにグローバルIDを使用する方法を示した。本実施例ではセンサチップを識別するのにグローバルIDそのものは使用せず、サーバ（131）内でグローバルIDと関連付けられた別の識別情報を使用する方法を示す。
図２４に、本実施例におけるサーバ（131）と外部サーバ（171）の間の通信シーケンスの一例を示す。
【０１１３】
まず外部サーバ（171）は、サーバ（131）の一般的なシステム情報を取得する（2410）。すなわち、HTTPシーケンス（2411）と（2412）により、URL（2441）へアクセスする。本URLはサーバ（131）のトップページを表すHTMLドキュメントである。トップページに一般的なシステム情報を掲載するのは、データの階層化の観点からも都合が良い。
【０１１４】
次に、外部サーバ（171）はセンサチップの一覧情報を取得する（2420）。すなわち、HTTPシーケンス（2421）と（2422）により、URL（2442）へアクセスする。本URLはトップページ（2441）からリンクされたHTMLドキュメントであり、外部サーバ（171）がトップページ（2441）の情報を元に、次にどのURLへアクセスするかを決定する手段により選択された結果である。外部サーバ（171）におけるこのURL決定手段としては、ユーザがWebブラウザを用いて対話的に決定するという方法でも良いし、外部サーバ（171）に実装されたプログラムが自動的に決定するという方法でも良い。URL（2442）中に記載されるセンサチップの一覧情報は、実施例１の場合とは異なり、センサチップの識別情報にグローバルIDは使用せず、グローバルIDの代わりとなる何らかの文字列を使用する。例えば、温度センサを備えたセンサチップであれば “thermo1”、“thermo2”、というような文字列を使用することができる。本識別情報は少なくともシステム内で一意でなければならないが、どのような形式のものでも構わない。本識別情報はユーザが手動で設定しても良いし、サーバ（131）がセンサチップから取得した情報を元に自動的に生成しても良い。
【０１１５】
次に、外部サーバ（171）は特定のセンサチップの測定履歴情報を取得する（2430）。すなわち、HTTPシーケンス（2431）と（2432）により、URL（2443）へアクセスする。本URLにおいて、“get-sensing-data.cgi” はセンサチップの情報を取得するためのCGIプログラムのファイル名を示している。“node=thermo2” と “period=today” は本CGIへ渡すパラメータを示しており、“thermo2” というセンサチップの本日の測定履歴を取得することを指定している。これらのCGI名、パラメータ名、それらの意味、用法等の情報は、センサチップ一覧のページ（2442）に記載したり、あるいはページ（2442）からリンクされた別のページに記載したりすることができる。URL（2443）を指定する手段としては、ユーザがWebブラウザを用いて対話的に決定するというものでも良いし、外部サーバ（171）に実装されたプログラムが自動的に決定するというものでも良い。
【０１１６】
本実施例では、図２４に示した限りにおいて、センサチップを識別するためにグローバルIDを用いていない。代わりに、サーバ（131）は外部サーバ（171）に対してURL（2442）中で “thermo2” のような別の識別情報を提示する。外部サーバ（171）は、この “thermo2” をセンサチップの識別子として、該センサチップの詳細情報や測定履歴にアクセスするので、サーバ（131）は、内部的に本識別情報とグローバルIDとの対応付けを管理する必要がある。これは、システム内通信におけるグローバルIDとローカルIDの対応付けを管理するのと同様の事情であり、また管理の実現方法としても同様の技術が適用できる。
【０１１７】
本実施例では、サーバ（131）が外部サーバ（171）へ開示するセンサチップの識別情報は、少なくともシステム内で一意であるような、任意の形式の情報である。本実施例のようにセンサチップの種類や用途を反映した文字列を使用した場合には、ユーザにとっての分かり易さが向上するという効果が得られる。また、サードパーティの提供するサービスと連携する場合に、グローバルIDを隠蔽しておけばサードパーティはメーカのサポートサイト等との連携も不可能であるので、詳細情報のシステム外への不必要な漏洩を防止する効果も得られる。勿論、積極的に詳細情報を開示したい場合には、前記識別情報と共にグローバルIDも公開しても構わない。本実施例においては、例えばURL（2442）中で、“thermo2” という識別子とグローバルID値を併記すれば良い。あるいは、URL（2442）からリンクされた “http://factory-1.corp-a.com/sensors/thermo2.html” というURLに、センサチップ “thermo2” に関する詳細情報を記述し、その詳細情報の1つとしてグローバルID値も含めても良い。
【０１１８】
本実施例のようにシステム外通信にHTTPを用いる方法は、ユーザが対話的にサーバのデータベースへアクセスする場合に適している。データがHTMLフォーマットで取得できるため、汎用的なWebブラウザにより容易に可視化される。また、パスワードによるアクセス制限や、SSLを用いた暗号化通信も容易である。これらの各種技術はWebページ作成技術として広く使用されており、開発環境も整っている。また、ユーザによる対話的な操作を介さずに構造化されたデータへの自動的なアクセスを実現する場合には、ネットワーク監視に広く用いられるSNMP（Simple Network Management Protocol）や、ディレクトリサービスを実現するLDAP（Lightweight Directory Access Protocol）等を利用することもできる。
【実施例５】
【０１１９】
他の実施例では、無線基地局においてローカルIDを割り当て、またグローバルIDとローカルIDの関連付けおよび変換も無線基地局において行う。本実施例では、サーバはローカルIDを全く意識せず、グローバルIDのみによってセンサチップを識別する。最も単純な実装においては、個々の無線基地局が全く独立にローカルIDを割り当てる。この場合、ローカルIDの一意性は個々の無線基地局の通信エリア内でしか保証されないので、センサチップがある無線基地局の通信エリアから別の無線基地局の通信エリアへ移動する場合には、移動先の無線基地局においてローカルIDの再割り当てを行う。また別の実装においては、システム内でのローカルIDの一意性を保証するために、新たなセンサチップが登録される度に無線基地局同士でIDテーブルの更新情報を相互に交換し、IDテーブルの情報を共有する。
【０１２０】
さらに他の実施例では、図１におけるような独立したサーバ装置は存在せず、複数の無線基地局のうちの特定の1つがサーバ機能を具備する。例えば図１における無線基地局（111）が、無線基地局兼サーバ装置であったとする。
【０１２１】
無線基地局（112）や（113）がセンサチップからのメッセージを受信すると、該メッセージは無線基地局兼サーバ装置（111）へ転送され、本装置のサーバ機能部において処理される。前記無線基地局兼サーバ装置（111）の無線基地局機能部がセンサチップからのメッセージを受信すると、該メッセージは内部的に自装置内のサーバ機能部へ転送される。この場合には、図６、図１２、図１５に示した通信シーケンスの各々における、無線基地局（111）とサーバ（131）の間の通信シーケンスが、単一装置の内部シーケンスに置き換えられる。本実施例は比較的小規模なセンサネットシステムにおける適用が有効であり、無線基地局機能とサーバ機能をコンパクトな筐体に一体化することで設置スペースの削減や運用コストの低減を実現する効果がある。本実施例の特別な場合には、比較的少数のセンサチップと、コンパクトな無線基地局兼サーバ装置一台によってセンサネットシステムが構築される。本構成は、一般家庭におけるセンサネットシステムの手軽な利用を促進するのに役立つであろう。
【０１２２】
本発明と類似の方法であって、本発明の目的の一部を達成するための方法の一つに、サーバではなくセンサチップ自身がローカルIDを生成する方法がある。例えば、擬似乱数を生成しこれをローカルIDとすることが考えられる。また、グローバルIDに対して固定的な演算を施すことによってローカルIDを生成しても良い。具体的には、グローバルIDに対して特定のハッシュ演算を施すことによってローカルIDを生成したり、グローバルIDから特定のビット、例えば下位16ビットを抽出し、これをローカルIDとすることが考えられる。特にグローバルIDに対して固定的な演算を施すことによってローカルIDを生成する方法の場合には、センサチップは運用中にローカルIDを記憶しておく必要がない。ただしこれらの方法に共通する問題として、個々のセンサチップが勝手に生成したローカルIDがシステム内で一意となる保証がなく、サーバが一意なローカルIDを生成する本発明と比較すれば実用性は劣る。これらの方法においては、いかにしてローカルIDが衝突する確立を低くするか、またいかにしてローカルIDが衝突した場合の回復可能を提供するか、が大きな課題となるであろうが、本課題の解決は容易ではないであろう。
【０１２３】
本発明では、グローバルIDはセンサチップ（101）のメーカにおいて出荷前にROM（240）に書き込まれることを前提としている。これは、イーサネット（登録商標）におけるMACアドレスと同様のものと想定している。ただしMACアドレスの場合、NIFカードの実装によっては、ROMに記憶されているMACアドレスをユーザが書き換えることができたり、ROMに記憶されているのとは別の値をデバイスドライバに記憶させて実際にはこちらの値を使用したり、複数のMACアドレスを記憶させて状況に応じて使い分けたりすることのできるものが存在している。このような機器や使用方法の存在にもかかわらず、全体として見ればMACアドレスは依然として出荷時に書き込まれるものであって出荷後の書き換えは不可能であるという前提の下で運用されており、前記のような機器や使用方法が有益な効果を生み出す場面もある。
【０１２４】
本発明におけるグローバルIDについても同様であって、少数のセンサチップにおいて例外的にグローバルIDの書き換えや使い分けが行われたとしても本発明の基本原理に影響を与えるものではなく、またそのような例外的な使用を拒絶するものではない。ただしグローバルIDはあくまでも全世界で一意であることを前提とするので、書き換え等の際に正規のグローバルIDを取得するための手順を規定したり、グローバルIDの特定のビット領域をユーザが自由に使用可能なローカル領域として定義したりすることによって、グローバルIDに本来求められている一意性を全体として損なわせないための最大限の方策を採る必要性があるであろう。
【産業上の利用可能性】
【０１２５】
本発明が広く適用可能であることは、（発明が解決しようとする課題）の項や、各々の実施例として記載した内容により明らかであろう。
【図面の簡単な説明】
【０１２６】
【図１】構成機器間の接続関係である。（実施例１）
【図２】センサチップの内部構成である。（実施例１）
【図３】無線基地局の内部構成である。（実施例１）
【図４】サーバの内部構成である。（実施例１）
【図５】構成機器間のプロトコルスタックである。（実施例１）
【図６】センサチップ初期登録時における通信シーケンスである。（実施例１）
【図７】初期登録時におけるセンサチップの動作フローである。（実施例１）
【図８】初期登録時における無線基地局の動作フローである。（実施例１）
【図９】初期登録時におけるサーバの動作フローである。（実施例１）
【図１０】サーバの管理するIDテーブルの構成である。（実施例１）
【図１１】センサチップと無線基地局の通信で使用される無線フレームの構成である。（実施例１）
【図１２】センサチップからサーバへのデータ収集時の通信シーケンスである。（実施例１）
【図１３】データ収集時におけるセンサチップの動作フローである。（実施例１）
【図１４】データ収集時におけるサーバの動作フローである。（実施例１）
【図１５】本センサネットシステムが外部サーバと通信する際の、通信シーケンスの一例である。（実施例１）
【図１６】サーバがクエリ（1511）を受信してからアンサ（1512）を返送するまでの動作フローである。（実施例１）
【図１７】サーバがクエリ（1513）を受信してからアンサ（1518）を返送するまでの動作フローである。（実施例１）
【図１８】クエリ（1511）におけるXML-APLレイヤのフォーマットである。（実施例１）
【図１９】アンサ（1512）におけるXML-APLレイヤのフォーマットである。（実施例１）
【図２０】サーバの管理するIDテーブルの構成である。（実施例２）
【図２１】通信コストの算定式である。（実施例２）
【図２２】センサチップ初期登録時の通信シーケンスである。（実施例３）
【図２３】データ収集時の通信シーケンスである。（実施例３）
【図２４】サーバと外部サーバの間の通信シーケンスの一例である。（実施例４）
【符号の説明】
【０１２７】
１０１〜１０８    センサチップ
１１１〜１１３    無線基地局
１３１    サーバ
１７１    外部サーバ
４５１    IDテーブル
４３１    データテーブル
６１１、６１２    登録要求メッセージ
６１３、６１４    登録完了メッセージ
６２３    ローカルID記憶
６４１    ローカルID割り当て
１２１１、１２１２    測定データメッセージ
１２１３、１２１４    確認応答メッセージ
１５１１、１５１３〜１５１５    クエリ
１５１２、１５１６〜１５１８    アンサ
１５２４、１５２６    ID変換
１９１４〜１９１６    グローバルID
２２０１    IDテーブルへ登録
２３０１、２３０２    ID変換、プロトコル変換。
【図１】
2006060515.tif 000003
【図２】
2006060515.tif 000004
【図３】
2006060515.tif 000005
【図４】
2006060515.tif 000006
【図５】
2006060515.tif 000007
【図６】
2006060515.tif 000008
【図７】
2006060515.tif 000009
【図８】
2006060515.tif 000010
【図９】
2006060515.tif 000011
【図１０】
2006060515.tif 000012
【図１１】
2006060515.tif 000013
【図１２】
2006060515.tif 000014
【図１３】
2006060515.tif 000015
【図１４】
2006060515.tif 000016
【図１５】
2006060515.tif 000017
【図１６】
2006060515.tif 000018
【図１７】
2006060515.tif 000019
【図１８】
2006060515.tif 000020
【図１９】
2006060515.tif 000021
【図２０】
2006060515.tif 000022
【図２１】
2006060515.tif 000023
【図２２】
2006060515.tif 000024
【図２３】
2006060515.tif 000025
【図２４】
2006060515.tif 000026