論 文
広域センサネットワークの運用構造と多属性検索
落合 秀也† a)江崎

松浦知史†† b)

砂原 秀樹†† c)

中山 雅哉† d)浩† e)Operating Architecture and Multi-Attribute Search for Wide Area Sensor Networks
Hideya OCHIAI†a) , Satoshi MATSUURA††b) , Hideki SUNAHARA††c) , Masaya
NAKAYAMA†d) , and Hiroshi ESAKI†e)

あらまし センサによる環境データ収集は組織単位で独立に運用される．本研究は，これらの組織間で環境データの再利用を促進する広域センサネットワークを実現するため，その運用アーキテクチャと多属性検索機能の導入を提案する．本研究では，まず標準化の方法で組織間での相互接続性を確立する．データ公開に関するア
クセスコントロールの実現要求を想定し，データを各自組織のローカルサーバで保管する状況を設定する．この状況下で，分散インデックスを用いたセンサの多属性検索機能を導入する．属性群の定義を運用段階で管理し，柔軟にシステム全体へ反映させる手法もあわせて提案する．提案システムでは，各組織のサーバノードで構成されるネットワークは階層的に運用される．本研究では，サーバノード間の相互接続性，データ提供先のアクセス
コントロール機能，種々検索キーによるセンサ検索実現，の観点でシステム検証を行い，これらを同時に実現可能なことを確認した．2007 年 11 月現在，本提案システムは Live E!広域センサネットワークとして，4 台のサーバノードで運用されている．
キーワード
コントロール

広域センサネットワーク，運用アーキテクチャ，相互接続性，多属性検索，データ提供アクセス状を打開する必要がある．一方で，実際的な広域セン

1. は じ め にサネットワーク運用においては，データ提供先のアク

近年，組込みコンピュータとインターネットの融合

セスコントロールが要求される場合がある他，広域ににより，小型な設備で遠隔地の環境情報を観測する

分散したセンサデータを種々観点から発見するためのことが可能になった．いまや多くのセンサがインター

多属性検索を実現する必要もある．本研究では，このネットに接続され，結果として広域センサ網ができつような状況を踏まえた広域センサネットワークのアーつある．ところが実際には，これらのセンサシステム

キテクチャを提案する．

は運用組織ごと独自な設計で開発されているのが現状

本研究で想定するセンサシステムは，遠隔地のセンで，多くのセンサデータがオンラインなのにもかかわ

サの観測データが，インターネット等を介して，指定らず，その一部しか利用できない状況にある．それぞされたサーバに定期的に通知される方式のものである．

れのセンサデータは，気象観測，災害対策，農業など

センサ設置および運用は，複数の組織によって独立に多くの場面で再利用できる可能性を秘めているが，こ行われ，それぞれの組織でインターネットに接続されれを実現するには，データ共有を妨げている上記の現たデータ収集サーバを運用している．

†††

それぞれの組織のサーバが異なるスキーマで独自に
東京大学
The University of Tokyo

構築されている場合，これらを相互接続するために奈良先端科学技術大学院大学

Broker を導入する方法がよく知られている (Mediator

Nara Institute of Science and Technology

もしくは Agent と呼ばれることもある)．この方式でa) E-mail: jo2lxq@hongo.wide.ad.jpb) E-mail: sato-mat@is.naist.jp

は，アクセスインタフェースやセンサデータの表現をc) E-mail: suna@wide.ad.jp

統一するため，Broker と各サーバ間に Wrapper を作d) E-mail: nakayama@nc.u-tokyo.ac.jpe) E-mail: hiroshi@wide.ad.jp

成する．Wrapper は，作成コストの他，対象サーバ

電子情報通信学会論文誌 X Vol. Jxx–X No. xx pp. 1–11 xxxx 年 xx 月

1

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xxに不足するデータ項目を付け足すなどの操作を伴う案する．

ことがあり，運用コストの点で実際的でない．Peter

以下，本論文の構成を示す．第 2 章で関連研究を述

Wegner [1] の分類における標準化方式でサーバ間の相べ，第 3 章にて Live E!システムデザインを述べる．

互接続性を実現すれば，この問題は解消できる．本研

第 4 章で，実装と運用状況に言及し，第 5 章で評価を究でもそのアプローチを取る．

行い，第 6 章で考察し，第 7 章で結論を述べる．

実際的なシステムを構築する上では，組織 A,B,C にはデータ提供するが，組織 D,E にはデータ提供しない

2. 関 連 研 究といったアクセスコントロールが必要になる状況も考MetBroker [2] は，複数の組織で独立に構築された

慮に入れなければならない．それぞれのサーバで自組センサデータベースを統合し，統一的なインタフェー

織のデータを管理し，ここでユーザ認証 (組織認証) を

スを，ユーザアプリケーションに提供する．各組織の行い，オンデマンドにデータ提供を行う形態を取れば，データベースと，Broker との間にそれぞれ Wrapper

アクセスコントロールを現実的なコストで運用できるをプログラムすることで，アクセスインタフェースやことは広く知られている．センサ運用者から離れたとデータ表現を統一する．Wrapper の作成・維持は人為

ころにデータを集めて管理する広域センサネットワー

的に行われるため，システム管理にかかるコストが規ク研究が多い中で，本研究では，アクセスコントロー

模の増加と共に増大する．

ルを実現する要求を想定し，センサ運用者からデータを離さずに管理する状況を設定する．

GSN [3] は，仮想化と呼ばれる手法でセンサを標準形で表現し，サーバ間の相互接続性を実現している．

本研究では，センサをプロファイル部とデータ部

明確には述べられていないが，Mill [4] や IrisNet [5]で表現する．センサには固有の ID を割り当て，プも，センサデータがシステム内で標準化された状況を

ロファイルおよびデータは，この ID で結び付けられ想定している．Mill は Chord [6] と同様のアーキテクる．プロファイル部には，センサに関する各種属性

チャを持ち，Z-ordering によって生成される 2 次元 ID

prof ile(n)(e.g., n は，設置場所の緯度経度，住所，管空間を管理することで地理位置検索に関してスケール

理者名，センサ機種，設置環境，移動体名，関連河川

性を持たせている．ただし，本研究が想定するアクセ

名など) が記載され，ユーザアプリケーションは，こスコントロールや位置以外を検索キーにする場合につの属性を参照することで，センサの分類や各種データ

いては，明確に述べられていない．IrisNet は，OA に加工に利用する．データ部は，センサが通知してきたより地理的な住所構成の木を作成し，その上にセンサ

データ集合 data(t) であり，最新値データから過去のデータを対応づける．XPath による検索を実現し，位

アーカイブまで，理論的には，すべてが時刻 t を指定

置以外のものも検索キーに含むことが可能だが，SAすることで読出し可能であるとする．

からのデータを複数の OA に通知する状況が想定されセンサ検索においては，一般に利用形態にあわせて，ており，アクセスコントロールをどのように設定可能

複数の属性が独立に検索キーとなる．地表面モデル

なのかが明確に述べられていない．本研究では，セン(経緯度モデル) 上での検索，特定の会社に属するセンサ運用組織にデータ公開権限を持たせ，センサ運用組

サの検索 (組織名検索) の他，移動体名や河川名を検索

織のポリシーでアクセスコントロール設定を行える状

キーとするような状況が考えられる．このような機能況を想定している．

を実現する検索を多属性検索と呼ぶ．

Intentional Naming System(INS) [7] は，こちらは本研究ではアクセスコントロールに関する要求やフラットなネットワーク構造を持ち，複数の属性を

多属性検索を実現するため，センサデータを運用組

階層的に持つことが可能な Name-speciﬁer(i.e., 検索

織のローカルサーバで管理させた上で，SiteTable とキー) でサービス検索ができる．サーバが発行する

IndexTable を用いた分散環境上の検索手法を提案すName-speciﬁer はネットワーク全体に広告され，サーる．検索キーの属性は，文字列型の場合もあれば，浮バへの最短経路は分散 Bellman-Ford 法 [8] で作成す

動小数点数型である場合もある．緯度，経度，河川なる．各ノードでのルックアップ処理は Name-speciﬁer

どの属性群 (スキーマ) は，システムで唯一定義され，の木構造を生かしたインデックスにより達成される．

全体で共有されていなければならない．これが定期的

一方，Live E!は，階層的なネットワーク構造を持ち，に更新されるような状況も想定したシステムとして提並列な属性群で構成されるセンサプロファイル上の検2

論文／広域センサネットワークの運用構造と多属性検索

索を行う．センサプロファイルを上位ネットワーク階層へ広告することで経路構築が可能で，検索インデッ
クスは (属性名, 属性値) のペアに対して作成される．

Hyo-Sang Lim et al [9] によると，本研究で対象としているシステムは，Query-initiative 型に分類される．予め分散的に蓄えられているデータに対して，クエリを発行し，データを取得する方式である．一方，予めクエリを発行しておき，発生するセンサデータを

図 1 Live E! 広域センサネットワーク・層アーキテクチャ
Fig. 1 Architecture of Live E! wide area sensor network

能動的にイベント情報として購読者に配信する Data-

initiative 型のシステムもある．GSN [3] や，[10] [11]は，このような型のシステムを研究している．

3. Live E!システムデザイン
Live E!プロジェクト [12] では，本提案システムをデザインするまでの，2005 年 5 月〜2007 年 5 月の 2
年間に渡り，実際的な広域センサネットワークへの要
求条件を調査した．調査結果のうち，本研究で取り組む要求条件を下記に挙げる．

a ) 標準形式による相互接続
相互接続の対象となる組織名やサービス場所を設定

図 2 階層構造による Live E!運用ネットワーク
Fig. 2 Hierachical operation of Live E! network

ファイルに数行書込めば，自律的にコントロール情報が交換され，数時間で，センサ検索やデータ共有を可義を動的に変更できる必要がある．新規にプロファイ

能にする．

ル属性を追加する場合がこのような状況に相当する．

b ) 組織単位のセンサプロファイル管理

本研究が対象とする運用形態においては，経験上，ス

単一組織が管理するセンサは 100 台程度で，各センキーマの動的更新が 1 日以内に達成できれば十分でサに設定されるプロファイルは 10 項目程度である．プ

ある．

ロファイルが更新される頻度は，経験上平均 1.0[回/
年・センサ] 以下である．

本研究の段階では，実展開／実運用を行う上での上c ) データ提供先のアクセスコントロール

記の課題について解決することに焦点を当てている．

d ) 分散環境におけるセンサ検索

スケール性，遅延に関する目標の設定やデザインの提e ) 複数の検索キーの同時サポート

案は将来的な課題である．

検索キーが A,B,C とあったときに，A に関する条

3. 1 アーキテクチャ

件でも，B に関する条件でも，C に関する条件でも検Live E!広域センサネットワークとして，図 1 に示す索を可能にする．検索キーのデータ型は，少なくとも，

層アーキテクチャを提案する．システム全体としてこ数値と文字列には対応しなければならない．比較演算の層構造を持つが，サーバ単独でもこの層構造を持っとしては，<, >, ==, <=, >= があれば，実際的な環境ている．サーバ間はインターネット上のオーバレイとでは経験上十分である．

して結合され，ネットワークを形成する．結合されたf ) プロファイルスキーマの柔軟な更新

リンクの上で，コントロール情報が交換され，全体とプロファイルスキーマは，プロファイルの属性名やして一つのシステムとして協調動作する．

属性型などの定義で，プロファイル記法および広域検ネットワーク・トポロジは，図 2 に示すような階索 (分散環境におけるセンサ検索) のクエリ記法，検層構造になるように，管理層で静的に設定するもの

索処理を規定する．スキーマは，配布ソフトウェアにとする．静的なのは運用時に計画的なトポロジ設計

暗黙的に書込まれるべきではなく，運用中に新しいタを行えるようにするためである．サーバには DNS

イプのアプリケーションが登場する状況を想定し，定と同じ Variable-Depth 木 [13] で名前を与える．トポ3電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

ロジに階層構造を採用した理由には，多くの組織の構造が階層的であること，プロファイルスキーマの配信が容易なこと，クエリのルーティングプロトコ
ルが簡素になる（注 1）ことがある．サーバは DNS と同
じ Master/Slave 方式で冗長構成をとることが可能である．

3. 2 管理/API 層
管理層では，システム全体でプロファイルスキーマ
を一つ管理し，ルートサーバから配信している．具体的には，各サーバが上位階層サーバのスキーマを定期的に読み込むことで，ルートサーバによって発行されたスキーマを，システム全体に行渡らせる．このようにすることで，プロファイルスキーマの柔軟な更新を可能にする．

図3

スキーマ，プロファイル，クエリ，検索プロセスの関係
Fig. 3 Schema, Proﬁle, Query, Processing

各センサ運用組織の管理層では，下記の設定を行う
ことができる．

•

近隣ノードとのリンク設定

対して行われ，センサ検索後のオンデマンドなデータ•

センサプロファイルの発行取得要求に対して働く．

•

データ提供先アクセスコントロール設定

API 層は，ユーザアプリケーションがセンサ検索／•

各種パラメータ (キャッシュ時間など) の設定

データ読出しを行うためのインタフェースを提供する．

•

基本設定 (ログ出力先など)

全センサの最新値データの取得，特定の領域の最新値

センサは，各組織で設置され運用されることを考え

データの取得などのインタフェースを提供する．ユー

ると，プロファイルは組織ごとに発行することが妥当

ザリクエストを受信してから，分散環境の中で検索をである．ここでプロファイルのいくつかの属性は，自実行し，データを読み出すまで，本研究の段階では，動生成することも可能だが，全属性の設定の自動化は単一の Remote Procedure Call(RPC) の中で行うよ難しいため，人の手で設定できる必要がある．GPS に

うに API をデザインしている．

より経緯度情報は自動化できるし，センサ機器自身が3. 3 センサ検索層

機種情報を持つことでの自動化もできる．しかし，どセンサ検索層では，管理層で設定された Live E!ネッのような設置環境 (e.g., 路面, 公園) かや，移動体名な

トワーク上での，センサ広域検索を実現する．下位階

どの情報は人手による設定が実際的である．更新頻度層のサーバノードのプロファイルを定期的に読み込み，は経験上 1.0[回/年・センサ] 程度と予測されるため，

検索クエリのルーティングを自律的に実現する．

人の手による運用でも十分対応可能である．

図 3 にプロファイルスキーマ，プロファイル，検索

アクセスコントロール設定は，組織のセンサ公開ポ

クエリ，検索プロセスの関係を示す．検索プロセスは，

リシーを設定するものである．本提案システムでは，検検索クエリに合致するプロファイルを含むサーバをリ

索要求およびデータ取得要求は各サーバが発行し，発ストアップする処理である．スキーマは，プロファイ

行組織名 (サーバ名) を許可リストや拒否リストに追加

ル属性名，属性型，取りうる値などを規定するもので，することで設定する．図 2 において，<*.x.>を許可リス

管理層から与えられる．各センサ運用組織は，センサ

トに加えた場合，{<a.x.>, <b.x.>, <c.x.>, <x.>} からに対して，このスキーマに適合するプロファイルを発のデータ取得要求は許可される．アクセスコントロー

行し，ローカルサーバに登録してある．検索クエリもル設定は，データ転送層の Reference Monitor [14] にスキーマに適合する形で作成され，検索プロセスに利用される．具体的には，検索条件が 34<latitude<35 ∧（注 1）：階層的なネットワークであれば，プロファイル情報を上位階層へ広告すればよい．一方，一般的な (i.e., フラットな) ネットワークでは，
プロファイル情報を全体で共有する必要があり，さらには経路にループができないようにしなければならない．

4

139<longitude<140 であるような検索クエリを発行することが可能で，検索対象とするサーバ (組織名) を限定することも可能である (図 3 の例では，site で検論文／広域センサネットワークの運用構造と多属性検索

図 5 クエリの転送処理
Fig. 5 Query forwarding process

図 4 クエリ経路表の構築
Fig. 4 Construction of query routing table

索対象とするサーバを限定している)．組織名検索はされる (このとき，子孫である {<a.x.>, ..., <b.y>} のDNS 同様に Patricia-Trie アルゴリズム [15] で達成さプロファイル情報も {<x.>, <y.>} 経由で，<.>に届い

れる．

ている)．

本研究では，分散インデックスを用意し，検索クエ

図 4 にノード<y.>でのクエリ経路表の作成手順を

リをルーティングすることで，検索プロセスを分散環示す．<y.>には，子ノード {<a.y.>, <b.y.>} があり，境上で実現する形態をとる [16]．検索を，近隣ノード<a.y.>およびその子孫にあたるノードにはセンサ Aへのクエリ転送処理の連続形に，抽象化することで，と B，<b.y.>およびその子孫にあたるノードにはセ

分散環境上での検索プロセスの実装を将来的に交換しンサ C が存在している．それぞれのセンサプロファ

やすくするためである．本研究では，クエリ問合せ先

イルは，図 4 に示す通りとする．ここでプロファイ

ノードが，応答としてリダイレクション (i.e., 次に問ルの属性は，I および J(e.g., 緯度, 経度) は浮動小数い合わせるべきノードの情報) を発行することを転送

点数型，S が文字列型 (e.g., センサ機種) とするようと呼び，転送を連続的に行うことでネットワーク上でにプロファイルスキーマで規定されている．<y.>は，の検索を実現させることをルーティングと呼ぶ．本研<a.y.>および<b.y.>から，センサプロファイルを受け

究では，分散インデックスをクエリ経路表と呼ぶ．検取り，SiteTable と IndexTable を次のように作成す

索クエリのルーティングを自律的に実現するために，

る．SiteTable では，センサ ID と子ノードを対応さ

プロファイルを上位サーバノードが定期的に読み込ん

せ，IndexTable には，それぞれのセンサプロファイル

でいる．

を (センサ ID, 属性名, 文字列型の値, 浮動小数点数型

INS [7] では，Name-speciﬁer の木構造を生かしたの値) で展開する．図の例では，I および J は浮動小数

インデックスを作成するが，本研究のクエリ経路表で点数なので，fValue に値が格納され，S は文字列型なは，(属性名, 属性値) のペアに対して，インデックス

ので，sValue に値が格納されている．次に述べる転送を作成している．以下，クエリ経路表の作成方法とク処理のため，(name, sValue) および (name,fValue)，

エリ転送処理について解説する．(ここではサーバのそれぞれに関して，検索インデックスを作成してある．

ことをノードと表現する)．

IndexTable，SiteTable は，定期的に (e.g., 10 分おき

クエリ経路表の作成 図 2 において，すべてのノー
ドはクエリ経路表を保持する．この経路表の作成は，に) 上記の操作が実行されることで更新され，最新の状態に保たれる．

子ノードの保有する (そのすべての子孫も含めた) プ

クエリ転送処理 すべてのノードはクエリ経路表を

ロファイル情報を読み込んだ上で行われる．<x.>で保持しており，クエリ問い合わせがあると，応答としあれば，{<a.x.>,<b.x.>,<c.x.>} からプロファイル情て次に問い合わせるべきノード情報 (i.e., 転送先 IP

報を読み込み，経路表が作成される．<.>であれば，アドレス等) を返す．クエリは，検索対象となるノー{<x.>,<y.>} からプロファイル情報を読み込み，作成

ド名の範囲と，複数の属性に関する条件式で構成され
5

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

る．転送処理は，次のようになる．まず，(1) 検索ク

3. 4 データ管理/転送層, センサ層

エリを，属性ごとの条件文に分割し，IndexTable に

データ管理層では，センサ層で認証されたセンサ

おいて，それぞれ条件に適合するセンサ ID を考える．

データを扱う．センサから受け付けたデータは，まず(2)SiteTable において，それらセンサ ID の積集合を最新値データとして扱われ，アグリゲーション (e.g.,

取り，最終的に残ったセンサ ID を持つ子ノードをクMAX, MIN, AVERAGE 演算) 用に展開され，オンエリの転送先として算出する．

ラインに読み出せる形で保存される．ローカルサー

具体例として，図 4 で示した，<y.>で作成された経バ内にデータを配置し，Reference Monitor [14] をそ

路表に基づき解説する．図 5 に示す意味の検索クエの前に設置することでアクセスコントロールを行う．

リが発行されたとする．site が，検索対象となるノー

Reference Monitor は，管理層での設定に従って，要ド名の範囲で，I および J が属性に関する条件式であ

求発行元のサーバにデータを提供すべきかどうか判断る．(1) まず検索クエリを，条件 I と条件 J に分割し，する．要求発行元のサーバ識別はデータ取得要求時に，

IndexTable において適合するセンサ ID を，それぞれ

自サーバ名を同時に提示させることで行う．本研究の{B,C}，{A,C} と算出する．(2)SiteTable にてセンサ

対象外だが，要求身元の確認 (ベリファイ) や改竄を防

ID の積集合を取ると C のみが残るので，<b.y.>がクぐ機構などはここに組み込まれる．

エリの転送先として導出される．

データ転送層では，センサ検索層でリストアップされたサーバそれぞれに対して，データ取得要求を発行

この方式により，プロファイル属性を検索キーにしし，その結果取得できたデータをマージする．ここで，たノード検索が可能になる．検索対象領域が狭ければ，データ取得要求は，最新値データ，過去データ，アグ

クエリ転送処理は多くの場合 O(logN ) 以下で達成でリゲーションされたデータの読出し要求に分類され，きる (N はセンサ数，検索対象領域が狭い状況ではイ

その分類の中でも，時刻範囲や経緯度範囲など，選択

ンデックス検索コストが支配的)．この方式自体では，的にそのサーバノードが管理しているデータを指定でノードの経路表は O(N ) で増加する．経路表の作成コ

きる．

ストは，検索インデックスが B-Tree [17] で実装されていれば，O(N logN ) に従う．

センサ層では，センサとの通信機能を提供し，セン
サ認証も行う．データ通知インタフェースは，システ

センサ数の増大に伴い，上位ノードの経路表が増大

ム内で標準化されており，そのインタフェースに適合してくる．結果，(1) 定期的に実行されるクエリ経路表

したセンサがデータを通知してくる状況を想定しての作成処理時間が増大する．同時に (2) クエリで指定いる．

された検索対象領域が広い場合，転送処理時間が増大する．スケール性を実現する研究は将来的な課題とし，

4. 実装/運用状況

本研究の段階では，検索の機能性を犠牲にすることで2007 年 11 月現在，Live E! プロジェクトで展開を

この問題に対処することを考えている．ルートサーバ

行っている典型的な Live E!サーバは，Java2 ver.1.5.

から途中の階層まで組織名 (サーバノード名) をキーで実装され，その規模はクラス数にして 291 個である．

とした検索を行なわせ，その先から，他のキーでの検データベースに PostgreSQL を使用し，クエリ経路表

索を行わせる．一定規模以上になった場合，上位ノーはデータベースのテーブルとして実装している．サー

ドでの SiteTable, IndexTable の作成を諦めるか，検バ間通信は，SOAP で行われ，交換されるメッセージ

索対象領域が広いクエリの転送処理を禁止する．提案は XML で記述されている．SOAP エンジンの実装にシステムでは，組織名をキーにした検索では，クエリ

は，Axis1.4 を使用している．

転送処理時間は事実上 O(1) になる (理由: SiteTable,

IndexTable での処理が不要なため)．

このシステムは，2007 年 8 月から運用を開始した．
図 6 に 2007 年 11 月現在の運用状況を示す．

検索の実装 [18] には，Iterative 方式を採用していルートサーバ<.>, <wrapper.>, <jp.>は，東京大学にる．Iterative 方式は，Recursive 方式と比較しセッショ設置されており，それぞれ 0 個，148 個，3 個のセン

ン時間が短く，上位ノードの負荷を小さく抑えること

サを管理している．<nara.jp.>は，奈良先端科学技術が可能であると共に，タイムアウト閾値を低く抑える

大学院大学に設置され，2 個のセンサを管理している．

ことが可能なためである．

サーバ間の Round Trip Time(RTT) は，最大 10ms

6

論文／広域センサネットワークの運用構造と多属性検索

Fig. 6図 6 2007 年 11 月現在の運用状況
The current operational status in Nov. 2007.

図 8 ルートサーバでのクエリ転送処理時間分布
Fig. 8 Distribution of query forwarding processing
time at the root server

Fig. 7図 7 ユーザリクエスト処理時間分布
Distribution of user request processing time程度である．

図 9 ”wide”の Global Live E! Network への参加実験
Fig. 9 ”wide” is joining to the Global Live E! Network

図 7 に，<jp.>で実際に観測された「ユーザリクエス
トの処理時間分布」を示す．Hourly，Daily，Monthly，

GetLatestDataAll は，それぞれ，(1) 時間単位，(2)日単位，(3) 月単位でアグリゲートされたデータと (4)5. システム評価
5. 1 相互接続性と運用管理

最新データ，の読出しリクエストを意味する．リクエ

センサ運用組織 wide と，その子組織 hongo, naist

ストごと扱うデータ量が異なるため，単純な比較はでが独自にセンサを管理運営しており，Live E!の他組織

きないが，この分布から処理時間の期待値を計算したとのデータ共有を行う状況を想定する．それぞれの組

ところ，次のようになった．

織で Live E!サーバをインストールし，図 9 のように，•

Hourly - 478ms

グローバル Live E!ネットワークに接続した (管理層で•Daily - 178ms

各リンクを設定した)．動作開始の数秒後，リンクの接•Monthly - 94ms

続状態がアクティブになり，グローバル Live E!ネット•

GetLatestDataAll - 283ms

ワークで管理されているプロファイルスキーマが，こユーザリクエストの平均処理時間が 100ms〜500ms程度で運用されていることがわかる．

れら 3 台のサーバに配布される様子が観測された．上位サーバからのスキーマ読み込み周期を，300 秒 (=5

図 8 に，「ルートサーバにおけるクエリ転送処理時間分) に設定した場合，定常動作状態においては，<.>で分布」を月ごとに示す．クエリ転送は 2〜4ms でほぼ更新されたスキーマは，10 分以内に，<hongo.wide.>

完了している．各月の総クエリ数は下記であった．

や<naist.wide.>へ到達した．<.>のスキーマに更新が•

8 月 1026 回•

9 月 814 回<hongo.wide.>と<naist.wide.>が，さらにその 5 分後•

10 月 3500 回に，<wide.>からスキーマを読み込んだケースが到達•

11 月 3992 回

時間が最大になる場合で，10 分であった．

あった 5 分後に，<wide.>がそのスキーマを読み込み，7電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

こうして構築されたネットワーク上で，それぞれの組織の管理下で，独立にセンサ登録やプロファイル管理を行えることを確認した．登録したプロファイルは，上位のサーバに伝播することも確認した．伝播周期をし可能になった．こうして目的のアクセスコントロー
ルを実現できることが確かめられた．

6. 考察と課題

300 秒に設定した結果，<hongo.wide.>に登録したセWrapper をプログラムして複数のデータベース間のンサのプロファイルは，10 分以内に<.>にまで到達す

相互接続性を確立する方式と比べ，本研究の方式 (i.e.,

ることが確かめられた．ここで 10 分間は，実運用上

データ表現やアクセスインタフェースを標準化し，自ほとんど問題にならない時間だと考えている．従来型

律分散的に広域検索を実現させる) では，相互接続に方式の場合，相互接続のための Wrapper 作成に，日関するコストを (時間にして 10−4 程度に) 削減でき

単位での時間を要していた．つまり，10

−4

程度の時

間短縮を実現できたことになる．

5. 2 検索た．これはネットワークのトポロジに柔軟性を与えることが可能になったことを示唆する．実際的な運用にあたっては，トポロジ設計を計画的に行う必要がある．

次の状況を想定し，組織名，経緯度，移動体名，河川

国ごと地域ごとに運用サーバを計画的に配置すること

名，それぞれをキーとした検索が可能であることを確で，検索に伴う分岐が減少し，検索効率を上げること認した．(1)hongo は，東日本エリアを重点的にセンサが可能になると考えられる．計画的な割り当ては，シ展開する．河川情報に強く関係した水位センサや，列ステム全体のパフォーマンスに左右するとする見解は車に取り付けられたセンサも管理している．(2)naist

RFC2050 [19] でも述べられている．

は，西日本エリアを重点的にセンサ展開する．水位セ

計画的な運用には，プロファイルスキーマ管理も挙ンサや，列車のセンサも管理している．(3)wide は，げることができる．プロファイルスキーマを発行する

hongo や naist に属しない wide メンバが持つセンサ

ルートサーバの役割は，インターネットでの Internetを管理する．日本全体にセンサを展開するが，河川関Assigned Numbers Authority(IANA) [20] に相当す

連のセンサや，列車についたセンサも管理している．

る．スキーマを動的に配信する仕組みを導入したこ

サーバのトポロジ上では，センサは組織で分類されとで，システム全体に渡ったプロファイル記法や検索ているが，経緯度，移動体，河川は，複数の組織にまたキーの管理を可能にしたが，具体的なプロファイルス

がって存在するといった現実に起こりうる状況を再現しキーマのモデル設定・管理方法は運用上の課題である．

ている．例えば，hongo と wide は，river=jp.arakawa

本研究では，種々検索キーでの広域検索を実現するに関連するセンサをそれぞれで持っている．

ために，センサプロファイルを上位サーバノードに読以上の状況を想定し，図 10 のようにプロファイル

み込ませることで，検索クエリを広域にわたってルー登録した．検索実験と結果を，表 5. 2 に示す．この結ティングさせる手法を提案し，一定の規模においては果からわかるように，複数の異なる検索キーで，それ実現可能であることが明らかとなった．本研究で扱っぞれ検索可能であった．

た規模であれば，集中インデックスサーバを設置し，

5. 3 センサデータの公開制御

そこに問い合わせるだけでクエリに合致するすべての

図 9 の Live E!ネット ワ ー ク ト ポ ロ ジ に お い て ，ノードを応答する検索方式も可能かもしれない．あえwide(hongo, naist を含む) の特定のセンサデータは，てクエリ・ルーティングにより検索を実現する手法 [16]wide 内だけで閉じて，外部に公開すべきでない状況を採用したのは，将来的に様々なルーティング実装をを考える．hongo で収集しているデータは，wide 内

組込み可能にするためである．

での共有により組織全体の活動に貢献できるが，不特本研究の段階では，移動体は，移動体名をキーにす

定多数の外部組織への公開は不利益を生じうる場合でることで検索をする利用シナリオを考えていた．これある．

は，刻々と変化する経緯度をプロファイルとして扱う

hongo に お い て ，こ の セ ン サ に 対 す る デ ーと，ネットワーク内でのプロファイル伝播遅延問題を

タ 公 開 ポ リ シ ー を<*.wide.>の み に 設 定 し た ．結扱う必要が出てくるためである．開発したシステムで

果 ，外 側 の 組 織<wrapper.>, <jp.>, <nara.jp.>か らは，経緯度を含め，あらゆる属性は，プロファイルとの<hongo.wide.>の デ ー タ 読 出 し は 不 可 能 と な り，

してもデータとしても登録できるようになっており，<wide.>, <naist.wide.>, <hongo.wide.>からのみ読出

実際的な運用では移動体の刻々と変化する経緯度情報8

論文／広域センサネットワークの運用構造と多属性検索

図 10 組織名，緯度経度，河川名，移動体名による検索実験環境
Fig. 10 Search experiment on organization names, latitude and longitude, rivernames and vehicle names

Table 1

検索キー
組織名

条件
*
*.wide.
naist.wide.
経緯度[36,40] × [139,140][30,35] × [130,133]
河川名jp.arakawa
jp.fujikawa
移動体名jp.tokai.e981
jp.tokai.e982
jp.tokai.e983
組織名+経緯度 *.wide.+[36,40] × [139,140]

表 1 検索実験結果
The result of the search experiment
平均検索時間 (ms)
354
167
58
248
224
157
234
208
149
118
119

結果
., jp., nara.jp, wrapper., wide., naist.wide., hongo.wide.
wide., naist.wide., hongo.wide.,
naist.wide.,
wrapper., wide., hongo.wide.,
wrapper., wide., naist.wide.,wide., hongo.wide.,
naist.wide., hongo.wide.,wide., naist.wide., hongo.wide.,
naist.wide.,wide.,
wide., hongo.wide.,

は，データとして扱うことになる．経緯度をプロファ本研究では，データ提供先のアクセスコントロール

イルとしても登録し，経緯度による検索で発見できるに関する要求を考慮し，それぞれのセンサ運用組織

ようにするには，プロファイルの伝播遅延等の課題をのローカルサーバでデータを保管する状況を考えた．

今後扱わなければならない．

その上で，プロファイルを広域で共有させることで，種々検索キー (i.e., 組織名，緯度経度，河川名，移動

7. お わ り に体名) によるセンサ検索を分散的に実現した．検索には，SiteTable と IndexTable を組み合わせたクエリ

本研究では，インターネット上のセンサデータを自

経路表の作成と，クエリ転送処理を伴う方式を提案し

律分散的に共有する Live E!広域センサネットワーク

た．この方式は，センサ数の増大に伴うスケール性にの提案を行った．データ表現やアクセスインタフェー

課題が残ると予想され，今後さらなる改良が要求されスの標準化により，データ共有にかかる運用コスト

る．プロファイルおよび検索は，システム全体で管理の削減 (分単位でのネットワーク構築) を可能にした．
9電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

されるプロファイルスキーマに基づいて規定されるように設計し，柔軟な属性変更が可能になった．センサ

system”, IEEE/IPSJ SAINTW’07, p. 74 (2007).
[12]

hara: “Live E! project: Sensing the earth”, LNCS,

運用組織は，データ提供先の許可／禁止リストを作成するだけで，アクセスコントロールを実現できた．

4311, pp. 61–74 (2006).
[13]

謝辞
ワーク技術開発の一環として実施したものである．総

123–133 (1988).
[14]

pp. 414–418, Peason Education, Inc., second edition(2006).

ジェント技術の研究開発」の成果の一部を活用したも
[15]

のである．
献

of the ACM, 15, 4, pp. 514–534 (1968).

P. Wegner: “Interoperability”, ACM Computing Sur-

[16]

S. Ninomiya, T. Kiura, A. Yamakawa, T. Fukatsu,
K. Tanaka, H. Meng and M. Hirafuji:“Seamless

Systems, pp. 23–32 (2002).
[17]

B-Trees, pp. 434–454, MIT Press, second edition

databases by metbroker”, IEEE/IPSJ SAINT2007
K. Aberer, M. Hauswirth and A. Salehi: “Infrastruc-(2001).
[18]

pp. 205–209, Peason Education, Inc., second edition

sensor networks”, IEEE MDM 2007 (2007).
geographical location oriented overlay network man-(2006).
[19](2007).
[5]

P. B. Gibbons, B. Karp, Y. Ke, S. Nath and S. Se-

K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg
and J. Postel: “RFC2050: internet registry ip alloca-

aging data of ubiquitous sensors”, IEICE Transactions on Communications, E90-B, 10, pp. 2720–2728

A. S. Tanenbaum and M. V. Steen: “Distributed Systems”, chapter Implementation of Name Resolution,

ture for data processing in large-scale interconnected
S. Matsuura, K. Fujikawa and H. Sunahara: “Mill: A

T. H. Cormen, C. E. Leiserson, R. L. Rivest andC. Stein: “Introduction to Algorithms”, chapter 18:

integration of sensor network and legacy weather
workshop, p. 68 (2007).

H. Crespo, A. Garcia-Molina: “Routing indices forpeer-to-peer systems”, IEEE Distributed Computing

veys, 28, 1, pp. 285–287 (1996).

[4]

D. R. Morrison: “PATRICIA - practical algorithm toretrieve information coded in alphanumeric”, Journal

文[3]

A. S. Tanenbaum and M. V. Steen: “Distributed
Systems”, chapter General Issues in Access Control,

務省の委託研究「ユビキタスネットワーク認証・エー[2]

P. V. Mockapetris and K. J. Dunlap: “Developmentof the domain name system”, ACM SIGCOMM, pp.

本研究は，Live E!プロジェクトの広域センサネット[1]

M. Nakayama, S. Matsuura, H. Esaki and H. Suna-tion guidelines” (1996).
[20]“Iana”. http://www.iana.org/.

（平成 xx 年 xx 月 xx 日受付）

shan: “Irisnet: an architecture for a world wide sensor web”, IEEE Pervasive Computing, 2, 4, pp. 22–33(2003).
[6]

I. Stoica, R. Morris, D. Karger, M. F. Kaashoek and
H. Balakrishnan: “Chord: A scalable peer-to-peer
lookup service for internet applications”, ACM SIGCOMM, pp. 149–160 (2001).

[7]

W. Adjie-Winoto, E. Schwartz, H. Balakrishnan and
J. Lillery: “The design and implementation of an
intentional naming system”, Proceedings of the 7th

落合 秀也
平成 18 東京大学・工・電子情報卒．同
年 同大学大学院・情報理工学系研究科修士課程．現在に至る．組込みシステム，広域
センサネットワークの研究に従事．

ACM symposium on Operating systems principles,
pp. 186–201 (1999).
[8]

R. Bellman: “On a routing problem”, in Quarterly[9]

H.-S. Lim, J.-G. Lee, M.-J. Lee, K.-Y. Whang andof Applied Mathematics, 16, 1, pp. 87–90 (1958).
I.-Y. Song: “Continuous query processing in data
streams using duality of data and queries”, ACM
SIGMOD (2006).
[10]

D. J. Abadi, W. Lindner, S. Madden and J. Schuler:“An integration framework for sensor networks and松浦 知史
平成 15 立命館大学・理工・物理卒．平成17 奈良先端科学技術大学院大学・情報科

学研究科修士課程了．同年より同大学・情報科学研究科博士課程．オーバレイネット
ワーク，センサネットワークの研究に従事．

data stream management systems”, 30th VLDB Conference, pp. 1361–1364 (2004).
[11]

H. Ochiai, Z. Wang, R. Oguchi, A. Sugiyama,
Y. Sakamoto, S. Ishida and H. Esaki: “Applicationof content-based network for sensor data distribution

10

砂原 秀樹
昭和 58 慶大・工・電気卒．昭和 63 同

論文／広域センサネットワークの運用構造と多属性検索
大学大学院博士課程了．同年

電通大・情報・助手．平成 6 奈良先端科学技術大学院
大学・情報科学センター・助教授．平成 13
同大学・情報科学センター・教授．平成 17
同大学・情報科学研究科・教授，現在に至る．工学博士． インターネット，大規模広域分散環境，ネット
ワーク，並列処理，オペレーティングシステム，電子図書館に関する研究に従事．情報処理学会，電子情報通信学会，ACM，
IEEE 各会員．

中山雅哉

昭和 59 慶大・工・電気卒．平成元 東京
大学大学院博士課程了．同年 豊橋技術科学
大・知識情報工・助手．平成 5 東京大学・
大型計算機センター・助教授．平成 10 同大学大学院・工学系研究科・助教授 (兼担)．
平成 11 同大学・情報基盤センター・助教
授．平成 13 同大学大学院・新領域創成科学研究科・助教授 (兼担)．IEEE， 電子情報通信学会， 情報処理学会， 各会員．

江崎浩

昭和 62 九州大学・工・電子 修士課程了．
同年 (株) 東芝 入社．平成 2 米国ニュージャージ州 ベルコア社．平成 6 コロンビア大学・客員研究員．平成 10 東京大学 大型
計算機センター・助教授．平成 13 同大学
大学院・情報理工学系研究科・助教授．平成 17 同大学大学院・同研究科・教授，現在に至る．工学博士(東京大学)．MPLS-JAPAN 代表，IPv6 普及・高度化推進協
議会専務理事，JPNIC 理事，ISOC 理事．

11

Abstract Environment sensing systems must be operated independently by organizations. This paper
proposes an operating architecture and multi-attribute search for wide area sensor networks intended toshare and reuse those data. Standardization allows interoperability among servers of those organizations.
Sensor data must be managed at their origin server to implement access control functionality. Unter thesituation, we challenge multi-attribute sensor search, with addressing schema administration of the attributes. We evaluate our system in terms of interoperability, access control, and multi-attribute search.
Our proposed system works with four server nodes as Live E! wide area sensor network in Nov. 2007.
Key words Wide Area Sensor Networks, Operating Architecture, Interoperability, Multi-Attribute
Search, Access Control