(57)【要約】【課題】センサ端末の電力消費を抑える。【解決手段】自端末以外の、所定センサ情報を有するソース端末に関する属性を含む要求を送出するセンサ端末において、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成する。この生成された自端末ＩＤを付加して要求を送出する。【効果】自端末ＩＤを自律的に決定することにより、他の端末との間でＩＤ値の調整が必要無いので、その調整にかかる処理が不要となり、センサ端末の電力消費を抑えて電源容量を小さくし、センサ端末全体の大きさをより小さくできる。【選択図】      図１
2006157793.tif 000002
【特許請求の範囲】
【請求項１】
自端末以外の、所定のデータを有するセンサ端末に関する属性を含む要求を送出するセンサ端末であって、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成するＩＤ生成手段と、前記ＩＤ生成手段によって生成された自端末ＩＤを付加して前記要求を送出する要求送出手段とを含むことを特徴とするセンサ端末。
【請求項２】
前記ＩＤ生成手段は、前記自端末ＩＤを、ランダムな値として生成することを特徴とする請求項１記載のセンサ端末。
【請求項３】
自端末に隣接する他の端末を経由する経路を決定するためのルーティングテーブルを含み、前記ルーティングテーブルを参照して前記経路を決定するセンサ端末であって、前記ルーティングテーブルは、ソース端末に関する属性とシンク端末に関するＩＤとの対応関係を示すテーブルであることを特徴とするセンサ端末。
【請求項４】
前記ルーティングテーブルを参照して前記経路を決定する際、前記最適な経路に冗長コストを許容し、その許容範囲内において少なくとも１つの経路を決定することを特徴とする請求項３記載のセンサ端末。
【請求項５】
自端末以外の、所定のデータを有するセンサ端末に関する属性を含む要求を送出するセンサ端末の制御方法であって、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成するＩＤ生成ステップと、前記ＩＤ生成ステップにおいて生成された自端末ＩＤを付加して前記要求を送出する要求送出ステップとを含むことを特徴とするセンサ端末制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はセンサ端末、センサ端末制御方法に関し、特にユビキタス社会の実現のために用いられるセンサネットワークのセンサ端末、センサ端末制御方法に関する。
【背景技術】
【０００２】
ユーザが特に意識することなく、様々な環境で最適なサービスを享受できるユビキタス社会の実現に向け、微小なセンサ端末からなるセンサネットワークの検討が進められている。これらのセンサ端末は環境中の様々な場所に設置され、ユーザの嗜好や状態、また環境情報など多様な情報取得を行う。さらに災害現場や複雑なパイプラインなど、従来観測が困難だった環境での幅広い利用も期待されている。
【０００３】
センサネットワークではセンサ端末の属性を利用した通信が提案されている。すなわち、あるセンサ端末が、自端末以外の、ソース端末に要求を送出する際、その要求にソース端末に関する属性情報を付加する。この送出された要求を他の端末が受信すると、その端末はその属性情報に合致しているデータを取得した場合に、要求を送出した端末に向けてそのデータを返信する。
【０００４】
ここで、要求を送出したシンク端末にデータを返信するには、各端末にアドレスを付与し、このアドレスを指定したアドレス通信を行う必要がある。仮に、センサネットワークにアドレス通信を適用すると、他の端末との間でＩＤ値の調整をした後で通信を開始しなければならない。その場合には、個々のセンサ端末に一意のアドレスを設定するために多大な制御信号が必要になり省電力の観点から有効とはいえない。
【０００５】
ここで、属性を識別子とする利点は、相手のアドレスを正確に知らなくても、自分が必要とする情報（データ）属性を指定した通信要求（クエリ）を送信すれば、その属性に該当するセンサ端末から情報を取得することができる点である。
属性を利用したセンサネットワークのルーティング方式は簡略な方式が多い。情報を要求するセンサ端末（シンク端末）は通信要求（クエリ）を周囲のセンサ端末に送信し、クエリを受信したセンサ端末はシンク方向に勾配／コスト（グラディエント）を設定する。クエリに合った情報（データ）を持つセンサ端末（ソース端末）はそのグラディエントに逆向きにデータを返信する。
【０００６】
属性を利用した代表的ルーティングプロトコルとしてDirected Diffusion（非特許文献１）が知られている。Directed Diffusionにおいて、センサが取得したデータには属性による名前付け（ネーミング）が行われる。そして、あるデータを希望するセンサ端末（シンク端末）は属性の組からなるInterest（クエリ）を近隣センサ端末に配布する。クエリを受けたセンサ端末は、そのクエリ情報を自身で保持し、近隣センサ端末に転送する。
【０００７】
こうしてクエリの配布が進むと、センサネットワークにはシンク端末を中心とした勾配（グラディエント）が形成される。クエリがデータを提供するセンサ端末（ソース端末）に到達すると、ソース端末はInterestによるグラディエントに沿ってデータを転送する。つまり、クエリが配布された経路を逆向きにデータが転送されることになる。
なお、ソース端末とはある情報を持っているセンサ端末であり、シンク端末とはある情報を希望するセンサ端末である。つまり、情報を持っているセンサ端末はソース端末になり、情報の取得を希望するセンサ端末はシンク端末になり、同じセンサ端末がソース端末になったりシンク端末になったりする。
【０００８】
ＧＲＡＢ（非特許文献２）も属性を利用したクエリを送信し、グラディエント構築するルーティング方式である。ＧＲＡＢではシンク端末はAdvertiseメッセージ（クエリ）を送信して中継センサにコストを設定し、シンク端末を中心とするコストフィールドを形成する。ソースが送信するデータパケットにはコスト用のフィールドが定義されており、パケットを中継するセンサ端末はパケットのコストフィールドを参照し、そのコスト値より低いコストを持つ近隣ノードにパケットを転送し、シンク端末までデータを届ける。
【０００９】
【非特許文献１】Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin, John Heidemann, Fabio Silva, Directed Diffusion for wireless sensor networking, IEEE/ACM Transactions on Networking, Volume １１ ,  Issue １ （February ２００３）, pp.２−１６
【非特許文献２】F. Ye, G. Zhong, S. Lu, and L. Zhang,“グラディエントbroadcast: A robust データ delivery protocol for large scale sensor networks,” To appear ACM Wireless Networks, Vol. １１（２）, March ２００５.
【発明の開示】
【発明が解決しようとする課題】
【００１０】
前述したルーティング方式は、通信相手の識別子として要求するデータの属性、つまりソース端末に関する属性を利用する。このソース属性を利用した通信には、ＩＰアドレスのように厳密に通信相手を指定しなくても、自分の要求するデータに関する属性を指定するだけで通信を実現できるという利点がある。しかしながら、前述したルーティング方式を採用すると、以下の問題が生じる。
（複数のシンク端末が存在する場合の問題）
ソース属性を利用したルーティングの課題として、１つのソース属性に複数のシンク端末がクエリを送信してきた場合、ソース端末は複数のシンク端末を識別することができないということが挙げられる。図１２（ａ）は２つのシンク端末が１つのソース端末に同様の属性を利用してクエリＱを送信した状態である。理想的なデータＤの返信例は図１２（ｂ）であるが、実際はこのように返信されない。
【００１１】
図１３には、従来のセンサ端末が保持しているルーティングテーブルの例が示されている。同図に示されているルーティングテーブルでは、１つの属性に対して近隣センサ端末のグラディエント（ルーティング用のコスト）が記されている。すなわち、Ｈｏｐ数をルーティングコストとすれば、「ＳｏｕｒｃｅＡ」については、隣接センサ端末１からのコストが「４Ｈｏｐ」、隣接センサ端末２からのコストが「２Ｈｏｐ」、隣接センサ端末３からのコストが「３Ｈｏｐ」であり、隣接センサ端末２からのコストが最も小さい。一方、「ＳｏｕｒｃｅＢ」については、隣接センサ端末１からのコストが「１Ｈｏｐ」、隣接センサ端末２からのコストが「６Ｈｏｐ」、隣接ノード３からのコストが「４Ｈｏｐ」であり、隣接センサ端末１からのコストが最も小さい。
【００１２】
ソース端末及びパケットを中継するセンサ端末はルーティングテーブルにより、ある属性宛のクエリを送ってきた近隣センサ端末（Neighbor）とその近隣センサ端末に対するグラディエントを知ることはできるが、Neighborより先のどのシンク端末が送信してきたか識別することはできない。すなわち、仮にシンク端末の情報を含めて属性を作成しても、ルーティングテーブルからシンク端末は識別されない。
【００１３】
そのため、単数のシンク端末から発せられたクエリが重複して届いたのか、複数のシンク端末から発信されたのか識別することができない。クエリＱの到着時間やＨｏｐ数などの最適なグラディエントのみに返信すると図１２（ｃ）のように返信されないシンク端末が発生する。また全てのグラディエントに対して返信すると、図１２（ｄ）のようにデータＤの多大なパケットが発生する。
【００１４】
上記非特許文献１に記載されているDirected Diffusionでは、Two−Phase Pullというルーティング方式がある。この方式では、クエリを受信したソース端末が全てのグラディエントに対して一度探索データ（exploratory）を返信し、そのデータを受信したシンク端末が最適な経路を選択して補強（reinforce）し、実際のデータ転送はその補強された経路を利用して行われる。しかし、この方式においては、初めに返信される探索データの増大はさけられない。
また、One−Phase Pullというルーティングでは、クエリを受信したソース端末が最適なグラディエントに対しデータを送信する方法が提案されている。しかし、この場合最適なグラディエントのみしか利用しないため、複数シンク端末には対応できない。
【００１５】
（シンク端末が移動する場合の問題）
ところで、従来のソース属性を利用したルーティングは、シンク端末の移動に対して影響を受けやすい。これについて、図１４を参照して説明する。同図（ａ）は移動前の状態、同図（ｂ）は移動後の状態を示している。
シンク端末が移動すると、シンク端末は移動先で再度クエリを送信し、新たにグラディエントを設定しなくてはならない。すると、ソース端末は移動前にきたクエリと移動後にきたクエリとが、同一のシンク端末から来たのか異なるシンクから来たのかを識別することはできない。このため、どのグラディエントに対してデータを送信すればいいのかわからない。
【００１６】
仮に最新のグラディエントにのみ返信すると、移動前に通信ができていたシンク端末にデータが届かない場合がある。すなわち、同図（ｂ）に示されているように、シンク端末ａにのみ返信すると、シンク端末ｂにはデータが届かない。一方、全てのグラディエントに返信すると、全てのシンク端末と通信可能である。しかし、その場合、図１２（ｄ）の場合と同様に、多大なデータパケットが発生する可能性がある。
【００１７】
またシンク端末の移動は送信に必要なグラディエントの判断の問題だけではなく、実際に通信の断絶という問題を引き起こす。つまり移動する前まで通信ができていても、移動先で無線リンクが切れることがあるし、今までパケットを中継していたセンサ端末とは異なるセンサ端末に接続した場合には、通信が継続できる保障はない。
このような課題に対して、例えば上述した非特許文献２に記載されているＧＲＡＢでは、信頼性を確保するため、シンク端末−ソース端末間の最小コスト値に冗長コストを加えることで、自然とシンク端末に向かうマルチパスを構築する方式を提案している。図１４（ａ）には、Ｈｏｐ数をコストとした場合、シンク端末−ソース端末間の最小コストは「２」であるのに対し、冗長コスト「１」を付加したコスト「３」までのグラディエントを利用してデータを転送した例が示されている。
【００１８】
このようなマルチパスはシンク端末やパケットを中継するセンサ端末の移動に対して有効であり、冗長性の点でマルチシンクに対しても有効に思える。すなわち、図１５（ａ）のシンク端末ａが移動した場合を考えると、同図（ｂ）に破線で示されているいずれの位置にシンク端末ａが移動しても、シンク端末ａにはデータを届けることができる。
しかし、同図（ｂ）のシンク端末ｂのように、シンク端末ａに対して遠くにあるセンサにデータを届けることはできない。仮に冗長コストの値を大きくすると、図１２（ｄ）の場合と同様に多大なデータパケットが発生する可能性がある。
本発明は上述した従来技術の問題点を解決するためになされたものであり、その目的は多大なデータパケットを発生させず、電力の消耗を抑えたデータの授受を実現できるセンサ端末、センサ端末制御方法を提供することである。
【課題を解決するための手段】
【００１９】
本発明の請求項１によるセンサ端末は、自端末以外の、所定のデータを有するセンサ端末に関する属性を含む要求を送出するセンサ端末であって、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成するＩＤ生成手段と、前記ＩＤ生成手段によって生成された自端末ＩＤを付加して前記要求を送出する要求送出手段とを含むことを特徴とする。自端末ＩＤを自律的に決定することにより、他の端末との間でＩＤ値の調整が必要無いので、その調整にかかる処理が不要となり、電力の消耗を抑えることができる。このため、電源容量を小さくでき、センサ端末全体の大きさをより小さくすることができる。
【００２０】
本発明の請求項２によるセンサ端末は、請求項１において、前記ＩＤ生成手段は、前記自端末ＩＤを、ランダムな値として生成することを特徴とする。ランダムな値として自端末ＩＤを生成することにより、他の端末の端末ＩＤと重複する可能性が少なくなり、例えば端末ＩＤを３〜５ビットの値にすれば、個々のセンサに重複しないＩＤを設定した場合と同等な効果が得られる。すなわち、ＩＤを一意に定める場合、その定めるための事前処理に多くの電力が必要となるばかりでなく、ＩＤ自体のビット数が多くなるので、送受信されるデータ量が多くなり、それを通信すると多くの電力を消耗するのに対し、本発明ではそのような問題は生じない。
【００２１】
本発明の請求項３によるセンサ端末は、自端末に隣接する他の端末を経由する経路を決定するためのルーティングテーブルを含み、前記ルーティングテーブルを参照して前記経路を決定するセンサ端末であって、前記ルーティングテーブルは、ソース端末に関する属性とシンク端末に関するＩＤとの対応関係を示すテーブルであることを特徴とする。このようにルーティングテーブルを構成し、これを参照することにより、最適な経路を選択して返信しても、データを届けることができる。
【００２２】
本発明の請求項４によるセンサ端末は、請求項３において、前記ルーティングテーブルを参照して前記経路を決定する際、前記最適な経路に冗長コストを許容し、その許容範囲内において少なくとも１つの経路を決定することを特徴とする。冗長コストを付加した経路を設定とすることにより、シンク端末が移動した場合等にも対応でき、移動したシンク端末もデータを取得することができる。
【００２３】
本発明の請求項５によるセンサ端末制御方法は、自端末以外の、所定のデータを有するセンサ端末に関する属性を含む要求を送出するセンサ端末の制御方法であって、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成するＩＤ生成ステップと、前記ＩＤ生成ステップにおいて生成された自端末ＩＤを付加して前記要求を送出する要求送出ステップとを含むことを特徴とする。自端末ＩＤを自律的に決定することにより、他の端末との間でＩＤ値の調整が必要無いので、その調整にかかる処理が不要となり、電力の消耗を抑えることができる。このため、電源容量を小さくでき、センサ端末全体の大きさをより小さくすることができる。
【００２４】
要するに本発明では、センサネットワークにおける通信識別子である属性に注目し、ソース端末とシンク端末との双方の情報からなる新しい属性設計方式を提案する。つまり、ソース端末に関する属性だけでなく、シンク端末の情報（シンクＩＤ）を識別子に加えることで、複数のシンク端末の識別を可能にする。またこの新規識別子を利用してシンク端末−ソース端末間にセンサ端末の移動特性を考慮した冗長経路を設定し、センサ端末の移動に対してロバストなルーティング方式を提案する。
【発明の効果】
【００２５】
以上説明したように本発明は、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成し、この生成された自端末ＩＤを付加して要求を送出することにより、他の端末との間でＩＤ値の調整が必要無いので、その調整にかかる処理が不要となり、電力の消耗を抑えることができる。このため、電源容量を小さくでき、センサ端末全体の大きさをより小さくすることができるという効果がある。
ソース端末に関する属性とシンク端末に関するＩＤとの対応関係を示すルーティングテーブルを参照して、他の端末を経由する経路を決定することにより、多数のセンサ端末が移動するような環境において、複数シンクが効率よく情報収集することができ、またシンク端末が移動した場合でも通信を継続することができるという効果がある。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
また、以下の説明では、Ｈｏｐ数をルーティングコストとしているが、伝送時間をコストとしてもよい。この伝送時間は、各センサ端末を経由する際に付与されるタイムスタンプ値に基づいて算出される。さらに、無線のリンク品質、センサ端末の持っている電力の残量、センサ端末の移動頻度等に基づいてルーティングコストを決定してもよい。
【００２７】
（通信識別子：目的ソースと複数シンクの識別）
データや端末特性などから属性を決定する方法として、Intentional NamingやLow Level Naming等が提案されている。Intentional Namingは、William Adjie−Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley, The design and implementation of an intentional naming system, Proc. １７th ACM SOSP, Kiawah Island, SC, Dec. １９９９.に記載されている（以下、文献Ａと呼ぶ）。Low Level Namingは、John Heidemann, Fabio Silva, Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin, Deepak Ganesan, Building Efficient Wireless Sensor Networks with Low−Level Naming, Proceedings of the Symposium on Operating Systems Principles, pp. １４６−１５９, Chateau Lake Louise, Banff, Alberta, Canada:ACM, October ２００１.に記載されている（以下、文献Ｂと呼ぶ）。
【００２８】
また、あらかじめデータとソースの属性とを対応付けたリストをシンク端末内に保持しておいてもよい。このリストを参照すれば、シンク端末は自分が要求するデータに応じて属性を指定することができる。特に、シンク端末は必要なデータさえ取得できればいいため、ソースも属性を厳密に一意とする必要がない。
一方、シンク端末の識別子（シンクＩＤ）については、ソースの属性のように重複が発生した場合、シンク端末の違いを識別できない。このため、シンクＩＤに重複が発生した場合、ソースのデータが届かないといった問題が生じる。しかし、前述したように、シンク端末の識別子をネットワーク内で一意にすることは困難であり、厳密に制御を行うと多大な制御パケットが必要になる。
【００２９】
これを解決するために、周知のＭＡＣアドレスのようなハードウェアに一意なアドレスを利用することも考えられる。しかし、その場合、数ビットの信号をやり取りするようなセンサ通信に対し、数十ビットのアドレス空間を用意する必要があり、電力消費に大きな影響を与えてしまう。
センサネットワークでは、消費電力の削減は最大の課題であり、近隣センサ間の通信のため、最適なアドレス長を求める研究も存在するほどである。このような観点からハードウェアに一意なアドレスを直接利用する方式は有効とは言えない。実際に１つのソースに対し、要求が競合するシンク端末の数を想定すると、多くても数十台、少ない場合は数台程度であると予想される。この仮定が正しければ、アドレス空間として５ビット程度を割り当てれば、競合を回避するために実用上十分であると言える。
【００３０】
（シンクＩＤのビット数）
センサ端末において自律的に生成するシンクＩＤのビット数の最適値を求めるために発明者が実験した結果が図２に示されている。同図には、シンクＩＤのアドレス空間すなわちビット数に対する、理想値との割合が示されている。理想値とは、重複しないようにＩＤを設定した場合の成功率である。成功率とは、シンク端末がソース端末にクエリを送信し、その返信をソース端末が受取った確率である。同図では、移動するセンサ端末がシンク端末になる確率（Ｓｉｎｋ  Ｕｐ  Ｒａｔｅ）を１％、５％、１０％と変化させている。シンク端末になる確率が高いほど、シンクＩＤの重複がおきやすい。
【００３１】
同図を参照すると、センサ端末において自律的に生成するシンクＩＤのビット数を３ビットから５ビットにすると、いずれの場合でも、シンクＩＤが重複しないように設定した場合の成功率の９０％程度以上である。このことは、他の端末において生成されるシンクＩＤが重複する可能性が低いことを示している。このため、３〜５ビットのシンクＩＤを生成することが最も実効性があるといえる。
生成するシンクＩＤのビット数を多くすればするほど、シンクＩＤが重複する可能性はより低くなるが、ビット数をあまり多くすると、従来技術と同様に消費電力の問題が生じるので、最大でも１０ビット程度とすることが望ましい。
【００３２】
（ＤＲＩＤ）
以上の点から本発明では、文献Ａや文献Ｂに記載されているように、あるアルゴリズムや、あらかじめ設定されたリストに基づいて決定したソースの属性と共に、数ビット程度のアドレス空間からシンクが任意に選択した識別子（シンクＩＤ）を組み合わせ、１つの識別子とする方式を採用する。この方式をＤＲＩＤ（Designed Source Attribute and Random Sink ＩＤ）と呼ぶ。
【００３３】
このＤＲＩＤのソース属性とシンクＩＤとは、分離して配置される。すなわち、図１に示されているように、通常のＩＰアドレスと同様に、ソース属性とシンクＩＤとは分離して配置される。これは、ソース端末から返信されるパケットを中継するセンサ端末での集約効果を考慮したものである。同図において、ペイロード（Ｐａｙｌｏａｄ）５０に付加されているＤＲＩＤ５１は、ソース属性（Source Attribute）５２と、タイプフィールド（Ｔｙｐｅ）５６と、オプションフィールド（Ｏｐｔ）５３と、シンクＩＤ（ＳｉｎｋＩＤ）５４とから構成されている。なお、オプションフィールド５３は、シンクＩＤ５４の大きさを表している。タイプフィールド５６には、そのパケットがクエリであるかデータであるかを識別する情報が格納される。
シンクＩＤのビット数は、シンク端末が任意に決定することができる。シンクＩＤが衝突を回避する必要がないと判断したらシンクＩＤ用のビットは必要なくなる。一方、端末密度の影響等から通信状態が悪く、一意性を確保したい場合は、シンクＩＤのビット数を増やして設定する。なお、このシンクＩＤを一意に保つための制御信号は必要ない。
【００３４】
（識別子によるルーティングを行うセンサ端末）
前述した識別子を生成し、その識別子によるルーティングを行うセンサ端末の内部構成例について図３を参照して説明する。同図において、センサ端末１００は、自端末のＩＤとソース端末の属性とからなる通信識別子を生成する通信識別子生成部１０１と、シンク端末に返信すべきデータを保持している情報データベース１０２と、通信識別子生成部１０１によって生成される通信識別子及び情報データベース１０２に保持されているデータに基づいてパケットを作成して他のセンサ端末等に発信する発信部１０３と、他のセンサ端末から発信されたパケットを受信し、そのパケットに含まれているデータを必要に応じて情報データベース１０２に保持させる受信部１０４と、パケットの経路を決定するルーティング部１０５と、外部端末等とのインタフェースをなす入出力インタフェース１０６とを含んで構成されている。
【００３５】
（通信識別子生成部）
センサ端末１００内の通信識別子生成部１０１の内部構成例について、図４を参照して説明する。同図において、通信識別子生成部１０１は、ソース属性を発生するソース属性発生部１０１ａと、シンクＩＤを発生するシンクＩＤ発生部１０１ｂと、識別子を発生する識別子発生部１０１ｃと、制御信号等の入出力を行う入出力部１０１ｄとを含んで構成されている。
【００３６】
（データ・クエリ集約のサポート、ルーティングテーブル構築など）
シンク端末はソース端末から目的とするデータを取得するため、通常の属性ルーティングと同様に、ＤＲＩＤを付したクエリを近隣センサに送信する。クエリを受けたセンサ端末はソース属性により自分が条件に当てはまるデータを持つかどうか判断し、シンクＩＤによりクエリ送信元のシンクを識別する。クエリを受信したセンサ端末はさらに、自分のルーティングテーブルにシンク方向へのグラディエントの設定を行う。
【００３７】
従来技術のようにシンクＩＤが付加されていないクエリは１つのグラディエントに集約されるのに対し、本発明のようにシンクＩＤが付加されているクエリはシンクＩＤ毎にグラディエントが管理される。
ここで、ルーティングテーブルの構成例が図５に示されている。同図に示されているルーティングテーブルは、各ソース端末に関する属性毎に区分されている。すなわち、同図中のソース属性「ＳｏｕｒｃｅＡ」、「ＳｏｕｒｃｅＢ」である。
【００３８】
そして、この区分されている各属性において、シンクＩＤ毎に、隣接端末とそのシンク端末までのコストとが格納されている。すなわち、ソース属性「ＳｏｕｒｃｅＡ」において、シンクＩＤが「Ｓｉｎｋα」のシンク端末については、隣接ノード１（Ｎｅｉｇｈｂｏｒ１）からのコストが「４Ｈｏｐ」、隣接ノード２（Ｎｅｉｇｈｂｏｒ２）からのコストが「２Ｈｏｐ」、隣接ノード３（Ｎｅｉｇｈｂｏｒ３）からのコストが「３Ｈｏｐ」であり、隣接ノード２からのコストが最も小さい。また、シンクＩＤが「Ｓｉｎｋβ」のシンク端末については、隣接ノード１からのコストが「５Ｈｏｐ」、隣接ノード２からのコストが「２Ｈｏｐ」、隣接ノード３からのコストが「１Ｈｏｐ」であり、隣接ノード３からのコストが最も小さい。
【００３９】
一方、ソース属性「ＳｏｕｒｃｅＢ」において、シンクＩＤが「Ｓｉｎｋα」のシンク端末については、隣接ノード１からのコストが「１Ｈｏｐ」、隣接ノード２からのコストが「６Ｈｏｐ」、隣接ノード３からのコストが「４Ｈｏｐ」であり、隣接ノード１からのコストが最も小さい。また、シンクＩＤが「Ｓｉｎｋβ」のシンク端末については、隣接ノード１からのコストが「１Ｈｏｐ」、隣接ノード２からのコストが「５Ｈｏｐ」、隣接ノード３からのコストが「５Ｈｏｐ」であり、隣接ノード１からのコストが最も小さい。
要するに、このルーティングテーブルは、ソース端末に関する属性とシンク端末に関するＩＤとの対応関係を示すテーブルである。つまり、シンクＩＤ毎のグラディエントを保持するため、このルーティングテーブルを参照すれば、シンクＩＤ毎に最適なグラディエントを求めることができる。
【００４０】
ＤＲＩＤを利用したデータの授受は、以下のように行われる。まず、クエリがシンク端末から送出されると、そのクエリに付加されている「ソース属性」に自分の属性が一致するソースは、要求されたデータをすでに保持する場合はすぐに返信し、データを持たない場合はデータを取得した時点で返信する。このデータの返信はグラディエントに沿って行われ、クエリと逆方向にグラディエントを下っていきシンク端末に到達する。
このとき、図１に示されているＤＲＩＤを利用すると、ソース端末やパケットを中継するセンサ端末は、同じソース端末に対する複数のシンク端末からのクエリを識別することができる。このため、ソース端末は、シンクＩＤ毎にデータを返信すれば、複数のセンサ端末に必要なデータを送信することができる。
【００４１】
（データパケットの集約）
ソース端末及び中継センサは特定のソース属性に対して集約可能なデータはシンクＩＤを多段にして結合し、近隣センサに転送する。集約されたデータの例が図６に示されている。同図において、ペイロード（Ｐａｙｌｏａｄ）５０に付加されている集約された（Ｍｅｒｇｅｄ）ＤＲＩＤ５１ａは、ソース属性（Source Attribute）５２と、タイプフィールド（Ｔｙｐｅ）５７と、Ｌｅｎフィールド５５と、オプションフィールド（Ｏｐｔ）５３ａ、５３ｂと、シンクＩＤ（ＳｉｎｋＩＤ）５４ａ、５４ｂとから構成されている。なお、オプションフィールド５３ａ、５３ｂは、対応するシンクＩＤ５４ａ、５４ｂの大きさを表している。つまり、オプションフィールド５３ａはシンクＩＤ５４ａに対応付けられ、オプションフィールド５３ｂはシンクＩＤ５４ｂに対応付けて設けられており、本例では２つのシンクＩＤが繋がっている。Ｌｅｎフィールド５５は、繋がるシンクＩＤの長さを表している。タイプフィールド５７には、そのパケットがクエリであるかデータであるかを識別する情報、そのパケットが複数のパケットを集約したものであるかどうかを示す情報が格納される。
【００４２】
ここで、クエリについても同様に、複数のシンクＩＤから来たクエリが同じソース属性に対する場合、図６に示されているように、ソース属性で集約してシンクＩＤを複数繋げた、多段に設定した状態にして送信する。また、ソース端末が複数あり、複数のデータが同一のシンク端末に返信される場合、シンクＩＤを利用して集約すれば、複数のパケットを１つのパケットに集約することも考えられる。
以上のように、複数のシンクに対するデータを集約することができるため、送信電力の低減を図ることができる。
【００４３】
（データパケットの分割）
上記のように集約されたデータを中継するセンサ端末においては、パケットを受信した場合、ルーティングテーブルを参照することによって、そのパケットを複数に分割し、別々のシンク端末に向けて送信することができる。この場合、タイプフィールドを参照することにより、集約されたパケットであるかどうか識別でき、さらにそのパケットに付加されている各シンクＩＤに基づいてルーティングテーブルを参照すれば、シンク端末への経路を決定することができる。
【００４４】
（通信識別子を利用したルーティング：複数シンクへのデータ伝達）
ソースやデータのパケットを中継するセンサ端末は、シンクＩＤ毎にグラディエントを保持するため、シンクＩＤ毎に最適なグラディエントを求めることができる。このシンクＩＤ毎に作成された、図５に示されているようなルーティングテーブルを利用して、ルーティングを行うことにより、複数のシンクに効率的にデータを届けることができる。例えば、最適なグラディエントのみにデータを送信するポリシーを実装すれば、各シンクＩＤに最適な経路で通信を行うことが出きる。また、ある一定条件を満たすグラディエント全てにデータを送信するというポリシーでは、データ経路の冗長性を確保することで、データ到達性を高めることができる。
【００４５】
（ルーティング部）
センサ端末１００内のルーティング部１０５の内部構成例について、図７を参照して説明する。同図において、ルーティング部１０５は、ルーティングテーブル１０５ａと、このルーティングテーブル１０５ａを参照し、あらかじめ定められたアルゴリズムに従ってパケットの送信経路を決定するルーティングエンジン１０５ｂとを含んで構成されている。
ルーティングテーブル１０５ａは、ソース属性毎のテーブルがシンクＩＤ毎のテーブルを内包し、さらにシンクＩＤ毎のテーブルが近隣センサ毎のテーブルを内包した、階層構造になっている。
【００４６】
（センサ端末の動作）
次に、以上の構成からなるセンサ端末の動作について説明する。
（１）クエリ発信時
シンク端末がクエリを発信する場合には、まず通信識別子生成部１０１から識別子を作成する。そして、生成された識別子を付加し、タイプフィールドをクエリとしたパケットとして発信する。
（２）データ返信時
クエリを受信したソース端末がデータを発信する場合には、情報データベース１０２からデータを取得し、クエリに付加されていた識別子を付加し、タイプフィールドをデータとしたパケットとして返信する。
（３）パケット中継時
センサ端末がパケットを中継する場合、入出力インタフェース１０６からパケットを取得し、ルーティング部１０５を用いて転送先の端末を決定する。この決定されたセンサ端末にパケットを送出する。
【００４７】
（４）パケット受信時
センサ端末がパケットを受信する場合、入出力インタフェース１０６からパケットを取得し、ルーティング部１０５を用いて転送先の端末を決定する。ここで、そのパケットに自端末に必要なデータを含む場合、そのデータを受信部１０４に渡し、そのデータを情報データベース１０２に格納する。
また、そのパケットが、自端末の保持するデータに対するクエリの場合、情報データベース１０２からそのデータを引き出し、そのパケットに含まれているシンクＩＤを付加したパケットとして返信する。
【実施例１】
【００４８】
図８（ａ）において、シンク端末ａ及びｂは、上述したシンクＩＤ及びソース属性を含む識別子をクエリＱに付与し、パケットとして近隣センサに送信する。このとき、ソース属性は、要求するデータ情報からある法則・アルゴリズムを利用して決定する。一方、シンクＩＤは、シンク端末が自分で、任意にＩＤの長さやＩＤを設定する。例えばシンクＩＤを２ビットとし、シンク端末ａが「００」、シンク端末ｂが「０１」と設定することが考えられる。つまり、シンク端末は、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成する。
【００４９】
ソース端末やパケットを中継するセンサ端末は、クエリを受信すると、それに含まれているソース属性とシンクＩＤとに基づいて、ルーティングテーブルを作成する。このルーティングテーブルは、図５を参照して説明したように、シンクＩＤ毎のグラディエントを保持するため、シンクＩＤ毎に最適なグラディエントを求めることができる。
センサネットワークが静的で通信が比較的安定して行える状況では、ソース端末やパケットを中継するセンサ端末は、この最適なグラディエントのみを利用しても、複数シンクと精度の高い通信が期待できる。また消費電力の観点からも通信に利用する経路を少なくする方が有効である。このようにシンクＩＤ毎に最適なグラディエントを利用してルーティングを行う方式をＤＲＩＤ−ＯＰＲ（ＤＲＩＤ with Optimal Path Routing）と呼ぶ。
【００５０】
ところで、最適なグラディエントが複数ある場合は、できるだけ送信するデータ信号が少なくすむように、より多くのシンクＩＤを集約可能な近隣センサを選択してデータを送信する。すなわち、図９（ａ）に示されているように、シンクＩＤ及びソース属性を含む識別子が付与されたクエリＱがシンク端末ａ及びｂから近隣センサに送信された場合、ソース端末は、シンク端末ａのシンクＩＤとシンク端末ｂのシンクＩＤとをデータＤに付加してパケットとして返信する。このとき、タイプフィールドには、集約されたデータであることを示す情報が設定される。
【００５１】
すると、シンク端末ａへの最適経路とシンク端末ｂへの最適経路との分岐点となるセンサ端末では、同図（ｂ）に示されているように、それを２つのパケットに分割して送信する。すなわち、シンク端末ａのシンクＩＤが付加されたパケットをシンク端末ａに向けて送信し、シンク端末ｂのシンクＩＤが付加されたパケットをシンク端末ｂに向けて送信する。このように最適経路を途中で分割して送信することができるのは、図５を参照して説明したように、シンクＩＤ毎のグラディエントを保持したルーティングテーブルが、パケットを中継するセンサ端末に設けられているからである。
【００５２】
このＤＲＩＤ−ＯＰＲは信号量の点で優れるが、シンク端末やパケットを中継するセンサ端末が移動した場合、移動先で通信が継続できない可能性が高い。シンク端末やパケットを中継するセンサ端末が移動後に通信を継続する確率を上げるためにはあらかじめ広い範囲にデータを送信しておけばいいが、必要以上に範囲を広げるとセンサ端末の電源消費が増大してしまう。この問題については、次に述べる実施例２によって解決することができる。
【実施例２】
【００５３】
上記の問題を解決するために、シンクＩＤ毎に保持するグラディエントのうち、最適経路以外に、一定の条件を満たすグラディエント全てに対しデータを送信することも考えられる。すなわち、ルーティングテーブルを参照して経路を決定する際、最適な経路に冗長コストを付加する。こうすることで、限られた有効な範囲にのみデータ送信範囲を拡大し、シンク端末や中継センサ端末が移動した場合でも、パケットの到達率を高めることができる。このように冗長経路を付加して通信成功確率の向上を目指したルーティング方式をＤＲＩＤ−ＲＰＲ（ＤＲＩＤ with Redundant Path Routing）と呼ぶ。
【００５４】
すなわち、図８（ｂ）において、Ｈｏｐ数をグラディエントの値とした場合、クエリを受信したソース端末は、シンク端末ａに対する最適グラディエントは「２」、シンク端末ｂに対する最適グラディエントは「３」であることを認識する。シンク端末ａに対する「２」のグラディエントはセンサ端末ｃしかないが、シンク端末ｂに対する「３」のグラディエントはセンサ端末ｃとセンサ端末ｄとがあるため、ソース端末はセンサ端末ｃには、シンク端末ａのシンクＩＤとシンク端末ｂのシンクＩＤとを集約したパケットを送信する。そして、センサ端末ｄにはシンク端末ｂのみをあて先にしたパケットを送信する。このパケットを中継するセンサ端末も同様に、目的のシンクＩＤに対して複数の最適グラディエントがある場合は、複数のグラディエントに対してデータを送信して経路の冗長性を確保する。
パケットに付加されているシンクＩＤにより、あて先が明確であるため、パケットを中継するセンサ端末では、図１２（ｄ）のように同一のデータを逆流させることなく、複数のシンク端末への進行方向のみにパケットを転送することができる。
【００５５】
本例では、最適経路（Optimal）と冗長経路（Redundant）とのポリシーについて説明したが、シンクＩＤ毎にルーティングを行い、端末の移動等を考慮した端末特性に応じて、その送信ポリシーを変更することで複数のシンク端末に効率的にデータを届けることができる。これを実現するには、端末特性を示すフィールドを新たに追加しておき、予め移動することが分かっている場合にはシンク端末においてそのフィールドの内容を設定すればよい。シンク端末に限らず、パケットを中継するセンサ端末が移動する場合は、その中継するセンサ端末においてそのフィールドの内容を設定すればよい。
【００５６】
端末の移動の他、無線リンクの特性や、パケットを中継するセンサ端末の電力残量を上記の端末特性とし、シンク端末やパケットを中継するセンサ端末においてそのフィールドの内容を設定してもよい。このように、端末特性を考慮して必要に応じて冗長経路を設定することにより、通信成功確率を向上させることができる。
なお、以上の場合、Directed Diffusionのように効率のよい経路を発見するため、探索データを送信し、経路を補強する必要はない。
【実施例３】
【００５７】
上述したシンクＩＤはランダムに決定しているが、このシンクＩＤをある一定のアルゴリズムにより定めれば、例えばクエリを送信したシンク端末以外のシンク端末がそのクエリに対する返信パケットを受信することも可能になる。
例えば、センサ端末を製造する企業名や、位置情報・時間など様々な情報を元に、ある決められた法則によりシンクＩＤを決定すれば、それらの内容が近い端末では同じＩＤを持つことができる。
【実施例４】
【００５８】
図１０（ａ）において、あらかじめシンク端末ｂが通信識別子を利用したグラディエントを設定している。その後、図１０（ｂ）において、シンク端末ａがクエリを送信するが、そのクエリには自端末のシンクＩＤではなくシンク端末ｂのシンクＩＤを設定する。すると、図１０（ｃ）に示されているように、ソース端末は、データに、シンク端末ｂのシンクＩＤを付加したパケットを返信することになる。これにより、シンク端末ｂがパケットを受信することになり、クエリを送信していないシンク端末ｂがデータを取得できる。
【実施例５】
【００５９】
図１０においては、データを取得できるシンク端末が単数である（シンク端末ｂ）が、図６に示されているように、複数のシンクＩＤを付加してクエリを送信すれば、それらのシンクＩＤに対応するシンク端末全てがデータを取得できる。これにより、ソース端末が保持しているデータについて、マルチキャスト的な同報通信を行うことができる。
なお、あらかじめシンク端末ｂがグラディエントを設定していなくても、ソース端末からデータをプッシュ型に配信することにより、目的のシンク端末にパケットを送信し、そのシンク端末においてデータを取得させることができる。
【実施例６】
【００６０】
ある地理情報に基づいてシンクＩＤを決定してもよい。このようにシンクＩＤを決定すれば、端末の移動先などの予測ができた場合、移動先のシンク端末にデータをあらかじめ送信しておくといった制御も可能である。
（センサ端末制御方法）
上述したセンサ端末において実現されているセンサ端末制御方法について、図１１を参照して説明する。同図には、自端末以外の、所定センサ情報を有するソース端末に関する属性を含む要求を送出するセンサ端末の制御方法が示されている。同図において、まず、他の端末との間でＩＤ値の調整をすることなく自律的に決定した自端末ＩＤを生成する（ステップＳ２０１）。このステップＳ２０１においては、上記自端末ＩＤを、ランダムな値として生成する。次に、ステップＳ２０１において生成された自端末ＩＤを付加して、要求を送出する（ステップＳ２０２）。
このように、センサ端末が自端末ＩＤを自律的に決定することにより、他の端末との間でＩＤ値の調整が必要無いので、その調整にかかる処理が不要となり、電力の消耗を抑えることができる。このため、電源容量を小さくでき、センサ端末全体の大きさをより小さくすることができる。
【産業上の利用可能性】
【００６１】
本発明は、センサ端末の電力消費を抑えて電源容量を小さくし、センサ端末全体の大きさをより小さくする場合に利用できる。
【図面の簡単な説明】
【００６２】
【図１】本発明による識別子を含む要求のデータ構造を示す図である。
【図２】センサ端末において自律的に生成するシンクＩＤのビット数の最適値を求めるために発明者が実験した結果を示す図である。
【図３】本発明による識別子発生装置と識別子を利用したルーティング装置とを有する通信端末の構成例を示す図である。
【図４】本発明による識別子発生装置の構成例を示す図である。
【図５】本発明による識別子を利用したルーティングテーブルの例を示す図である。
【図６】本発明による識別子を利用したデータ・クエリ集約を示す図である。
【図７】本発明による識別子を利用したルーティング装置の構成例を示す図である。
【図８】本発明による識別子を利用した最適経路ルーティングの例を示す図である。
【図９】本発明による識別子を利用した最適経路ルーティングの例を示す図である。
【図１０】本発明を利用した、クエリ送信シンクとデータ受信シンクが異なる例を示す図である。
【図１１】センサ端末において実現されているセンサ端末制御方法を示すフローチャートである。
【図１２】従来の属性ルーティングの課題（複数シンクへの対応）を説明する図である。
【図１３】従来の属性によるルーティングテーブルの例を示す図である。
【図１４】従来の属性ルーティングの課題（シンク移動への対応）を説明する図である。
【図１５】従来の属性ルーティングの課題（シンク移動と複数シンクへの対応）を説明する図である。
【符号の説明】
【００６３】
５０  ペイロード
５２  ソース属性
５３、５３ａ、５３ｂ  オプションフィールド
５４、５４ａ、５４ｂ  シンクＩＤ
５５  Ｌｅｎフィールド
５６、５７  タイプフィールド
１００  センサ端末
１０１  通信識別子生成部
１０１ａ  ソース属性発生部
１０１ｂ  シンクＩＤ発生部
１０１ｃ  識別子発生部
１０１ｄ  入出力部
１０２  情報データベース
１０３  発信部
１０４  受信部
１０５  ルーティング部
１０５ａ  ルーティングテーブル
１０５ｂ  ルーティングエンジン
１０６  入出力インタフェース
ａ〜ｄ  シンク端末
【図１】
2006157793.tif 000003
【図２】
2006157793.tif 000004
【図３】
2006157793.tif 000005
【図４】
2006157793.tif 000006
【図５】
2006157793.tif 000007
【図６】
2006157793.tif 000008
【図７】
2006157793.tif 000009
【図８】
2006157793.tif 000010
【図９】
2006157793.tif 000011
【図１０】
2006157793.tif 000012
【図１１】
2006157793.tif 000013
【図１２】
2006157793.tif 000014
【図１３】
2006157793.tif 000015
【図１４】
2006157793.tif 000016
【図１５】
2006157793.tif 000017