JP5313100B2

JP5313100B2 - クラスタヘッド決定方法、該方法を実行するノードおよび制御プログラム

Info

Publication number: JP5313100B2
Application number: JP2009224245A
Authority: JP
Inventors: 健久保; 輝之長谷川; 亨長谷川
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2009-09-29
Filing date: 2009-09-29
Publication date: 2013-10-09
Anticipated expiration: 2029-09-29
Also published as: JP2011076184A

Description

本発明は、Ｐ２Ｐネットワークやセンサーネットワークのようなマルチホップネットワーク内に形成されるクラスタにおいて、１台のノードをクラスタヘッドとして選出する方法、該方法を実行するノードおよび制御プログラムに関するものである。ここでクラスタとは、ネットワークをグラフとみなしたときに、何らかの指標に対して同じ値（または同じ状態）を持つノード群が、連結な部分グラフを構成していることを指す。クラスタヘッドに選出されたノードは例えば何らかのサーバ機能を提供し、クラスタ内の調停役を努める。

Ｐ２Ｐネットワークは、インターネットの仕組みの上に構築されたエンドホスト間で構成される仮想的なネットワークである（オーバレイネットワークともいう）。この仮想的なネットワークでは、インターネットの制約（アドレス、名前解決など）に縛られない、自由な（独自の）ルール・プロトコルを規定し運用することができる。Ｐ２Ｐネットワークでは、すべてのエンドホストが対等の関係にあり、適宜サーバおよびクライアントの両方の役割を果たす。一方で、Ｐ２Ｐネットワーク内を適度に階層化して、階層ごとに特定の（または特別な）役割を果たすエンドホストを置くことによって、ネットワーク全体を効率よく制御することが行われている（Ｓｋｙｐｅなど）。

センサーネットワークでは、環境を測定するセンサーデバイスは、単一のデバイスだけで利用されるだけでなく、多数のデバイスを環境中に分散配置して、広い範囲にわたる環境情報を取得するという用途にも利用される。多くの場合、ノード群が取得した環境情報は、ある特定のノードまで配送され、そのノードからインターネットのデータベースなどで登録される。センサーノード群を階層的なノード群の集まり（クラスタ）だとみなし、クラスタの代表（クラスタヘッド）が集約されたルーティング情報を管理し、パケットの転送を行うことによって、ルーティングを効率化する手法などがある。

上記のＰ２Ｐネットワークやセンサーネットワークは、すべてのノードがサーバおよびクライアントの役割を同時に果たすことが想定されることが多い。これは、ネットワークを構成するノード群がすべて同じ能力を持っているということを表しているが、「特別な役割を果たすノード」が存在しないということを意味しているわけではない。ある時点に着目すれば、サーバのような機能を提供するノードと、それを利用するクライアントとなるノードが存在する。例えばネットワークをクラスタと呼ばれるノードの集合と考え、クラスタごとにサーバ機能を持ったノードにクラスタ内を調停させることによって、ネットワーク全体を効率よく動作させることもある。このようにネットワーク内にクラスタを作り、クラスタヘッドを選出するアルゴリズムはクラスタリングアルゴリズムと呼ばれる。

Ｐ２Ｐネットワークのクラスタリングアルゴリズムには、通信コスト（クラスタヘッドまでのホップ数や遅延）等に基づいてクラスタの構成およびクラスタヘッドを選出するものがある（非特許文献１、２）。選出されたクラスタヘッドのノード（ｓｕｐｅｒｎｏｄｅとも呼ばれる）が、クラスタ内の代表として他のクラスタのクラスタヘッドと情報転送の仲介などを行う。クラスタ内のノードは他のクラスタのノードと通信しようとする場合に、そのクラスタのクラスタヘッドに情報を送れば、クラスタヘッドから所望のクラスタのクラスタヘッドに情報が転送され、そこから宛先のノードへと情報が送られる。また、同様の考え方は、センサーネットワークにも適用されている（非特許文献３、４）。

上述の手法は、クラスタ構築とクラスタヘッドの選出を同時に実施する手法であるが、ノード群の中から特定のノードをクラスタヘッドとして選出する手法として、リーダ選出アルゴリズムがある（非特許文献５、６）。

Wei Zheng,Sheng Zhang, Yi Ouyang, Fillia Makedon and James Ford, "Node clusteringbased on link delay in P2P networks," Proceedings of the 2005 ACMsymposium on Applied computing, Distributed systems and grid computing (DSGC),pp. 744 - 749, 2005. L. Ramaswamy,A. Iyengar, L. Liu, and F. Douglis,"Connectivity based node clustering indecentralized peer-to-peer networks," in the 3rd International Conferenceon Peer-to-Peer Computing, 2003. W. B.Heinzelman, A. P. Chandrakasan, and H. Balakrishnan, "Anapplication-specific protocol architecture for wireless microsensornetworks," IEEE Transactions on Wireless Communications, Vol. 1, Issue 4,pp. 660-670, 2002. Ossama Younisand Sonia Fahmy, "Distributed Clustering in Ad-hoc Sensor Networks: AHybrid, Energy-Efficient Approach," in Proceedings of IEEE INFOCOM, 2004. Ernest Changand Rosemary Roberts, "An improved algorithm for decentralizedextrema-finding in circular configurations of processes," Communicationsof the ACM, Volume 22, Issue 5, pp.281 - 283, 1979. Ernest Changand Rosemary Roberts, "An O(nlog n) Unidirectional Algorithm for theCircular Extrema Problem," ACM Transactions on Programming Languages andSystems, Volume 4, Issue 4, pp.758 - 762, 1982.

しかしながら、非特許文献１、２、３、４に記載の（およびそこから派生した）クラスタリングアルゴリズムは、ネットワーク内にクラスタが存在しない状態から、通信効率を最適化するようなクラスタを構築し、同時にクラスタヘッドも選出するという手法である。つまり、ここで形成されたクラスタは、通信コスト最適化という指標に基づいて出来上がったクラスタである。逆に言えば、全く異なる指標でクラスタが形成された場合に、その状態で最も通信効率がいいクラスタヘッドを選出することはできない。

さらに、非特許文献５、６に記載の手法は、ノード群（つまりクラスタ）の中から１台のリーダ（つまりクラスタヘッド）を選出するアルゴリズムであるが、これらはＩＤをベースにした手法である。すべてのノードが重複しないユニークなＩＤを持っており（ＩＤ同士は数値として大小の比較が可能であるとする）、ネットワーク内のすべてのノードの中で最も大きなＩＤの値を持つノードがリーダとなる。従って、選出されたリーダが、通信コストという観点で最適な位置にあるノードであるとは限らない。

そこで本発明は、すでに形成されているクラスタの中から、そのクラスタ内の全ノードからの距離（ホップ数）の分散が一番小さいノードをクラスタヘッドとして選出するクラスタヘッド決定方法、該方法を実行するノードおよび制御プログラムを提供することを目的とする。

上記目的を実現するため本発明によるクラスタヘッド決定方法は、ネットワーク内に形成されたクラスタ内のノードが、クラスタヘッドを決定する方法であって、ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信するステップと、他ノードからホップ情報を受信し、記録するステップと、前記受信したホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送するステップと、前記記録されたホップ情報から自ノードのホップ数分散情報を算出するステップと、前記自ノードのホップ数分散情報を隣接ノードに送信するステップと、前記自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断するステップと、自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信するステップとを含む。

また、前記判断するステップは、前記自ノードのホップ数分散情報が、隣接ノードから送信されたホップ数分散情報より低い場合、自ノードがクラスタヘッドになるべきと判断するステップであることも好ましい。

また、前記受信し、記録するステップは、既に記録済みのノードＩＤと異なるノードＩＤ、および自ノードと同じクラスタ変数を含むポップ情報を受信し記録することも好ましい。

また、前記ノードは、前記クラスタヘッド広告を他ノードに送信した後、または前記クラスタヘッド広告を他ノードから受信した後、所定の時間経過後にクラスタヘッドを再度決定することも好ましい。

また、前記ホップ数分散情報を算出するステップは、前記ホップ情報を他ノードに送信した後、または前記ホップ情報を他ノードから受信した後、所定の時間経過後に行うことも好ましい。

また、前記判断するステップは、隣接ノードのすべてからホップ数分散情報を受信した後に行うことも好ましい。

また、前記転送するステップは、前記受信したホップ情報のホップ数を一定数増加させた後、該ホップ情報を記録しておき、所定の時間経過後、記憶されたホップ情報を隣接ノードに転送することも好ましい。

また、前記ホップ数分散情報は、他ノードから受信したホップ情報内のホップ数の分散であることも好ましい。

上記目的を実現するため本発明によるネットワーク内に形成されたクラスタ内のノードは、ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信する、および他ノードからホップ情報を受信し、該ホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送するホップ情報転送部と、前記他ノードから受信したホップ情報を記録するホップ情報管理部と、前記記録されたホップ情報から自ノードのホップ数分散情報を算出し、該自ノードのホップ数分散情報を隣接ノードに送信し、該自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断するクラスタヘッド選出部と、自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信するクラスタヘッド広告部とを備えている。

上記目的を実現するためクラスタヘッドを決定するプログラムは、ネットワーク内に形成されたクラスタ内のノードを、ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信する手段と、他ノードからホップ情報を受信し、記録する手段と、前記受信したホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送する手段と、前記記録されたホップ情報から自ノードのホップ数分散情報を算出する手段と、前記自ノードのホップ数分散情報を隣接ノードに送信する手段と、前記自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断する手段と、自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信する手段として機能させる。

本発明の方法によれば、ネットワーク内に何らかの指標に基づくクラスタが存在するときに、自律分散的にクラスタヘッドを１台決めることができる。この場合、各ノードはクラスタヘッドに至るための次ホップを容易に知ることができ、システム全体の状況を把握しているような中央集中的なサーバが必要ない。

このように決められたノードをクラスタヘッドとして選出することによって、クラスタ内部での通信（クラスタヘッドとその他のノードの通信）についてホップ数の観点から極端な偏りを排除することができる。これによって、クラスタヘッドから一番遠くのノードとの通信遅延に引きずられてクラスタ全体の様々な制御に時間がかかることの防止、クラスタ内全体でやり取りされるメッセージ数の低減などの効果が期待できる。

また、ネットワークトポロジやクラスタ構成の変化などによってクラスタヘッドが最適な位置ではなくなっても、定期的な選出手順によって、再度クラスタヘッドの選出が可能となる。

本実施形態におけるネットワークを示す。本実施形態におけるノードの内部構成を示す。ホップ情報のフラッディング処理のフローチャートを示す。クラスタヘッド選出のための計算処理のフローチャートを示す。他の実施形態のホップ情報のフラッディング処理のフローチャートを示す。

本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。図１は本実施形態におけるネットワークを示す。図１に示すように、複数のノードで構成されたＰ２Ｐネットワークにおいて、いくつかのクラスタが存在しているものとする。本実施形態ではＰ２Ｐネットワークを例にとって説明するが、センサーネットワークでも全く同様である。

ここで、クラスタを構成するための指標として簡単のため変数Ｃを考え、すべてのノードがクラスタ変数（変数Ｃとする）を保持しており、クラスタ変数Ｃの値が同一かつお互いが連結しているようなノード群をひとつのクラスタと考える。図１では、２つのクラスタ（Ｃ＝１、Ｃ＝１５）が存在する。クラスタ変数Ｃは、例えば各ノードが保持している情報の種別を数値で表現したものやセンサーが測定した環境の値（温度など）などが考えられる。本実施形態ではクラスタ変数Ｃはスカラ量として説明するがベクトル量でも問題なく、さらには各ノードが同一のクラスタであるかそうでないかを判別できる情報であればどのようなものでも良い。なお本発明では、Ｐ２Ｐネットワークはすでに与えられているものとし、その構築については取り扱わない。

なお、本発明ではいくつかのメッセージをブロードキャスト（broadcast）するが、これはすべての隣接ノードに送信するということを表しており、センサーネットワークのような無線環境であれば、いわゆるブロードキャストが行われ、Ｐ２Ｐネットワーク等ではすべての隣接ノードに対してユニキャスト（unicast）を行うものとする。また、フラッディング（flooding）もホップごとに見ればブロードキャストが行われるので、上記と同様にブロードキャストまたはユニキャストを行う。

本発明では、各ノードは次の情報を保持している。
・自ノードＩＤ：ＩＰアドレスなど。各ノードはネットワーク内全ノードでユニークなＩＤを保持している。
・クラスタ変数（変数Ｃ）：クラスタを区別するための変数。クラスタ変数の値が同じく、連結の関係があれば同じクラスタに所属する。なお、連結の関係がなければ、クラスタ変数の値が同じであっても、同一のクラスタにならない。
・クラスタヘッドＩＤ：自ノードが属しているクラスタのクラスタヘッドのノードＩＤ。本ＩＤはノード上で動作するアプリケーションで使用される。具体的なアプリケーション、アプリケーションでの使用方法等は本発明の対象外であるため、記載しない。

なお、明記しないが各ノードは自身の隣接ノードのノード数を知っているものとする。このノード数は、各ノードがＨｅｌｌｏメッセージを広告するなど、一般的な方法で容易に知ることができる。

各ノードはクラスタヘッドを選出するために以下の３種類のメッセージを送受信する。
・ホップ情報：ホップ情報には自身のノードＩＤ、クラスタ変数Ｃの値、起点からのホップ数の情報が格納され、各ノードが起点となってそれを送出（フラッディング）する。
・ホップ数分散情報：各ノードがホップ情報を集め、そこから計算したホップ数に関する分散の値が格納される。
・クラスタヘッド広告：自分がクラスタヘッドであることを宣言するためのメッセージ。

図２は、本実施形態におけるノードの内部構成を示す。ノード１は図２の機能ブロックから構成される。
・ホップ情報転送部１１：クラスタヘッドを選出するために手続きとしてホップ情報パケットを他のノード１にフラッディングする。ホップ情報転送部１１はホップ情報パケットの中身によって当該情報をさらに転送する（さらなるフラッディングをする）かしないかを判断し、必要なら転送する。
・ホップ情報管理部１２：転送したホップ情報に書かれていた情報を記憶しておく。
・クラスタヘッド選出部１３：ホップ情報管理部１２がもつ情報を元にホップ数の分散を計算し、計算結果（ホップ数分散情報）をブロードキャストする。また、隣接ノードからブロードキャストされたホップ数の分散と自身のホップ数の分散を比較し、自身がクラスタヘッドになるべきかを判断する。さらに、クラスタヘッド選出に関するタイマを制御する。
・クラスタヘッド広告部１４：自身がクラスタヘッドであることを宣言するメッセージ（クラスタヘッド広告）をフラッディングする。
・サーバ動作部１５：自ノードが唯一のクラスタヘッドとなったときに、特定の機能（サーバ機能）を提供する。本発明では、具体的な動作は対象外なので規定しない。

次に各ノードの動作を説明する。本発明では、クラスタヘッドの選出はホップ情報のフラッディングによって、クラスタ内のあらゆるノードとの距離（ホップ数）を取得し、取得したホップ数についての分散を計算する。そして、得られた分散の値を隣接ノードに広告する。これによって各ノードは自身が求めたホップ数の分散と隣接ノードが求めたホップ数の分散を比較が可能となる。クラスタの中で最も分散が低いノードは、隣接ノードの中で最も分散が小さくなるはずなので、隣接ノードの中に自身のホップ数の分散よりも小さい値を持つノードが存在しなければ、自身がクラスタヘッドになると判断する。クラスタヘッドになったノードは、自分がクラスタヘッドであることをクラスタ内に宣言し、さらにサーバ機能を起動する。

上述で概略した手順において、各ノード１のクラスタヘッド選出部１３が中心となってクラスタヘッド選出処理を制御する。クラスタヘッド選出部１３は下記２種類のタイマを管理し、クラスタヘッド選出処理の開始や終了を制御する。
・sleepタイマ：sleepタイマが動作している期間は、クラスタヘッド選出処理を行わない。つまり、すでにクラスタヘッドが選出された後の状態であり、自身がクラスタヘッドになると宣言した直後、またはクラスタヘッド広告メッセージを受け取った直後にタイマをセットする（セットされる値はSLEEP_INTERVAL秒とする）。このsleepタイマによって定期的にクラスタヘッドの再選出を行う。なお、ノードが起動した直後は即座にクラスタヘッド選出処理を開始する。
・判定待ちタイマ：判定待ちタイマは、sleepタイマ満了後または、前回クラスタヘッドが選出された後はじめてホップ情報を受信したときにタイマをセットする（セットされる値はJUDGE_WAIT秒とする）。判定待ちタイマが満了すると、ホップ数の分散を計算し、隣接ノードに広告する。ただし、判定待ちタイマが満了する前にホップ数分散情報を受け取ると、タイマをJUDGE_WAITにリセットする。

ここで、sleepタイマにセットするSLEEP_INTERVALが長すぎると、ネットワークが変化しても最適ではないノードをクラスタヘッドとして使い続けてしまう可能性があるが、逆に短すぎるとクラスタヘッド選出手順が頻繁に発生し、通信量が多くなってしまう。また、判定待ちタイマにセットするJUDGE_WAITが長すぎると、クラスタヘッド選出手順に時間がかかってしまうが、逆に短すぎると正しくクラスタ内の全ノードとのホップ数の測定ができず、正しくクラスタヘッドの選出ができなくなる可能性がある。ネットワークの変化が比較的頻繁に起こらないと仮定すれば、例えばSLEEP_INTERVALを６００秒（またはそれ以上）、JUDGE_WAITを１５秒程度にすれば良いと考えられる。

クラスタヘッド選出部１３によるクラスタヘッド選出手順を説明する。ここでは、すでにクラスタヘッドが選出された状態で、クラスタ内のいずれかのノードのsleepタイマが満了した直後からのクラスタヘッド選出手順について説明する。なお、ノードの起動直後でも処理は同様である。

以下は、２つのタイマに関する処理であり、同時にクラスタヘッド選出手順の開始処理でもある。
（１）sleepタイマが満了すると、クラスタヘッド選出部１３は、ホップ情報転送部１１に自ノードのホップ情報を送出するよう指示する。ホップ情報には、自ノードＩＤ、クラスタ変数の値、ホップ数を格納する。なお、ホップ数には１をセットする。
（２）ホップ情報を受信したとき、もしsleepタイマによる待ち状態であればsleepタイマを停止する（ホップ情報転送部１１からクラスタヘッド選出部１３へホップ情報受信の通知を送り、必要ならクラスタヘッド選出部１３はsleepタイマを停止する）。sleepタイマを停止した後、上記手順（１）を実施する。

図３は、ホップ情報のフラッディング処理のフローチャートを示す。本フローチャートにより、ホップ情報のフラッディング処理を説明する。
ステップ３１：ホップ情報転送部１１は、ホップ情報を受信すると、そこに格納されているクラスタ変数と自身のクラスタ変数を比較し、同一であれば受信し次のステップに進む。異なれば破棄し処理を終了する。
ステップ３２：さらに、受信したホップ情報のＩＤがすでにホップ情報管理部１２に記録済みならそのホップ情報を破棄し処理を終了する。記録がなければ受理し次のステップに進む。
ステップ３３：ホップ情報を受理した場合、判定待ちタイマをJUDGE_WAITにリセットする。また、ホップ情報転送部１１からクラスタヘッド選出部１３へホップ情報受信の通知を送る（上述の手順（２）に相当する）。
ステップ３４：受理したホップ情報に書かれているノードＩＤとホップ数をホップ情報管理部１２に記録する。
ステップ３５：受理したホップ情報のホップ数を１増加させ（ノードＩＤおよびクラスタ変数の値は変更しない）、ホップ情報を転送する。

なお、上記ステップ３２およびステップ３５の処理は一般的なフラッディングの処理に相当する。ステップ３１において、クラスタ変数の比較を行うことによって、無関係なクラスタへはホップ情報が伝播せず、同一クラスタ内のみでクラスタヘッドの選出が可能となる。

図４は、クラスタヘッド選出のための計算処理のフローチャートを示す。本フローチャートにより、クラスタヘッド選出のための計算処理の部分を説明する。
ステップ４１：判定待ちタイマが満了すると、クラスタヘッド選出部１３はホップ情報管理部１２に記録された情報からホップ数の分散を計算し、計算結果（ホップ数分散情報）をブロードキャストする。ホップ数分散情報には、自ノードのＩＤとホップ数の分散の値を格納する。なお、当該ホップ数分散情報のブロードキャストはsleepタイマが新たにセットされるまで、つまりクラスタヘッドが選出されるまで定期的に行う（送信間隔はADVERT_INTERVAL秒とする。この値は１０秒程度でよいと考えられる）。
ステップ４２：クラスタヘッド選出部１３は、隣接ノードがブロードキャストしたホップ数分散情報を受信した時は、ノードＩＤとともに記録する。なお、自ノードの判定待ちタイマが満了していなくても、ホップ数分散情報を受信する可能性があるが、タイマの満了に関係なく、記録を行う。
ステップ４３：クラスタヘッド選出部１３は、自身に隣接するすべてのノードからホップ数分散情報を受信したら、ステップ４２で記録したすべての分散値と自ノードのホップ数の分散を比較する。自ノードのホップ数の分散が最小でなければ、以降は上記ステップ３１で示した定期的なブロードキャスト以外は何も行わない。分散の値が最小ならステップ４４に進む。
ステップ４４：自身がクラスタヘッドになるので、クラスタヘッド選出部１３はクラスタヘッド広告部１４にクラスタヘッド広告をフラッディングするよう指示する。クラスタヘッド広告１４には、自ノードのＩＤを格納する。
ステップ４５：クラスタヘッド選出部１３はサーバ動作部１５にサーバ動作を開始するよう指示する（もともとクラスタヘッドだった場合は何もしない）。
ステップ４６：sleepタイマをセットする。ホップ数の分散値のブロードキャストを停止する。また、ホップ情報管理部１２のすべての情報を削除する。

上記ステップ４１におけるホップ数の分散の計算式は以下の通りである。

ただし、Ｎは受信した総ホップ情報数、ｘ_ｉはホップ情報に含まれていたホップ数の値（ｘ_１〜ｘ_Ｎまである）、Ａは受信したホップ情報に含まれていたホップ数の平均で、Ｖが求めるべき分散の値である。各ノードがそれぞれ分散を計算するので、Ｖはノードごとに異なる。Ｎはすべてのノードで同じあり、クラスタ内の総ノード数に等しくなることが理想であるが、パケットロス等の影響でＮはクラスタ内の総ノード数よりも小さくなる可能性がある。

上記ステップ４３で、分散が最小ではなかったノードは、他のノードからクラスタヘッド広告が届くのを待つのみである。クラスタヘッド広告を受信すると、クラスタヘッド広告部１４は当該メッセージをさらに転送する（フラッディングする）とともに、クラスタヘッド選出部１３にクラスタヘッド広告を受信したことを通知する。当該通知を受けたクラスタヘッド選出部１３は、sleepタイマをセットし、ホップ数の分散値のブロードキャストを停止し、ホップ情報管理部１２のすべての情報を削除する。また、クラスタヘッドが広告に記載されたノードＩＤを持つノードであると認識する（クラスタヘッドＩＤに当該ノードを記録する）。以前のsleep期間中にクラスタヘッドであったノードが、今回の選出手順で他ノードからクラスタヘッド広告を受け取った場合は、クラスタヘッド選出部１３はサーバ動作部１５にサーバ動作を停止するように指示する。クラスタヘッド広告を行ったノードがsleepタイマによる待ち時間の途中で、自ノードのノードＩＤよりも大きなノードＩＤの値を持つクラスタヘッド広告を受け取った場合、サーバ動作部１５にサーバ動作を停止するように指示する。そして、クラスタヘッドが受信したクラスタヘッド広告に記載のノードＩＤをもつノードであると認識する（クラスタヘッドＩＤに当該ノードＩＤを記録する）。これは、パケットロス等の障害によって、正しくホップ情報がフラッディングされなかったときなどに、クラスタ内で複数のノードがクラスタヘッド広告を送信してしまった場合に対応する手順である。

なお、クラスタヘッド選出部１３は、クラスタヘッド広告を受け取ったときの直前のホップ（隣接ノード）のノードＩＤを同時に記録しておけば、そのノードＩＤはクラスタヘッドへアクセスする際の次ホップとして利用できる。

上記実施形態では、クラスタヘッド選出手順のたびに各ノードがホップ情報をフラッディングする。クラスタ内にＮノード存在すればＮ回のフラッディングが起こるため、フラッディングによる総メッセージ数はＮ^２となる。

本発明の他の実施形態では、各ノードが複数のホップ情報を重畳して送出することによって、総メッセージ数を少なく抑えることができる。図５は、他の実施形態のホップ情報のフラッディング処理のフローチャートを示す。本フローチャートにより、ホップ情報の重畳を行うための前述のステップ３１〜３５を変更した手順を示す。本実施形態では、ホップ情報転送部１１に新たにtentative情報とflooding待ちタイマを導入する。

ステップ５１：ホップ情報転送部１１は、ホップ情報を受信すると、そこに格納されているクラスタ変数と自身のクラスタ変数を比較し、同一であれば受信、異なれば破棄する。なお、受信したホップ情報は、後述するとおり複数のホップ情報を含んでいる可能性がある（ステップ５６参照）。その場合クラスタ変数との比較と受信、破棄の判断はホップ情報ごとに行う。もし、すべてのホップ情報を破棄した場合は処理を終了する。
ステップ５２：さらに、受信したホップ情報のＩＤがすでにホップ情報管理部に記録済みならそのホップ情報を破棄する。記録がなければ受理する。上記手順ステップ５１と同様、複数のホップ情報が含まれている場合には、ＩＤが記録済みかどうかのチェックはホップ情報ごとに行い、もしすべてのホップ情報を破棄した場合は処理を終了する。
ステップ５３：ホップ情報を受理した場合、判定待ちタイマをJUDGE_WAITにリセットする。また、ホップ情報転送部１１からクラスタヘッド選出部１３へホップ情報受信の通知を送る（上記実施形態のステップ３３に相当する）。
ステップ５４：受理したホップ情報に書かれているノードＩＤとホップ数をホップ情報管理部１２に記録する。
ステップ５５：受理したホップ情報のホップ数を１増加させ、当該ホップ情報をtentative情報として記録する。tentative情報にひとつもホップ情報が記録されていなければ、flooding待ちタイマをセットする（セットする値はFLOODING_WAIT秒とする）。
ステップ５６：flooding待ちタイマが満了したら、tentative情報として記録されているすべてのホップ情報をブロードキャストする。ここで、一つ一つのホップ情報はノードＩＤとホップ数の組であり、複数の組が一回のブロードキャストで送出される。

上述手順ステップ５５のFLOODING_WAITを長くするとホップ情報の重畳度が増し、総メッセージ数が削減されることが期待される。しかし長くしすぎるとクラスタヘッド選出に時間がかかる。また、本実施形態を適用する場合は、JUDGE_WAITを大きくする必要がある（例えば、FLOODING_WAITの１０倍以上など）。

また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。

１ノード
１１ホップ情報転送部
１２ホップ情報管理部
１３クラスタヘッド選出部
１４クラスタヘッド広告部
１５サーバ動作部

Claims

ネットワーク内に形成されたクラスタ内のノードが、クラスタヘッドを決定する方法であって、
ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信するステップと、
他ノードからホップ情報を受信し、記録するステップと、
前記受信したホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送するステップと、
前記記録されたホップ情報から自ノードのホップ数分散情報を算出するステップと、
前記自ノードのホップ数分散情報を隣接ノードに送信するステップと、
前記自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断するステップと、
自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信するステップと、
を含むことを特徴とするクラスタヘッドを決定する方法。
前記判断するステップは、前記自ノードのホップ数分散情報が、隣接ノードから送信されたホップ数分散情報より低い場合、自ノードがクラスタヘッドになるべきと判断するステップであることを特徴とする請求項１に記載のクラスタヘッドを決定する方法。
前記受信し、記録するステップは、既に記録済みのノードＩＤと異なるノードＩＤ、および自ノードと同じクラスタ変数を含むポップ情報を受信し記録することを特徴とする請求項１または２に記載のクラスタヘッドを決定する方法。
前記ノードは、前記クラスタヘッド広告を他ノードに送信した後、または前記クラスタヘッド広告を他ノードから受信した後、所定の時間経過後にクラスタヘッドを再度決定することを特徴とする請求項１から３のいずれか１項に記載のクラスタヘッドを決定する方法。
前記ホップ数分散情報を算出するステップは、前記ホップ情報を他ノードに送信した後、または前記ホップ情報を他ノードから受信した後、所定の時間経過後に行うことを特徴とする請求項１から４のいずれか１項に記載のクラスタヘッドを決定する方法。
前記判断するステップは、隣接ノードのすべてからホップ数分散情報を受信した後に行うことを特徴とする請求項１から５のいずれか１項に記載のクラスタヘッドを決定する方法。
前記転送するステップは、前記受信したホップ情報のホップ数を一定数増加させた後、該ホップ情報を記録しておき、所定の時間経過後、記憶されたホップ情報を隣接ノードに転送することを特徴とする請求項１から６のいずれか１項に記載のクラスタヘッドを決定する方法。
前記ホップ数分散情報は、他ノードから受信したホップ情報内のホップ数の分散であることを特徴とする請求項１から７のいずれか１項に記載のクラスタヘッドを決定する方法。
ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信する、および他ノードからホップ情報を受信し、該ホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送するホップ情報転送部と、
前記他ノードから受信したホップ情報を記録するホップ情報管理部と、
前記記録されたホップ情報から自ノードのホップ数分散情報を算出し、該自ノードのホップ数分散情報を隣接ノードに送信し、該自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断するクラスタヘッド選出部と、
自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信するクラスタヘッド広告部と、
を備えていることを特徴とするネットワーク内に形成されたクラスタ内のノード。
ネットワーク内に形成されたクラスタ内のノードを、
ノードＩＤ、クラスタ変数、および起点からのホップ数を有するホップ情報を他ノードに送信する手段と、
他ノードからホップ情報を受信し、記録する手段と、
前記受信したホップ情報内のホップ数を一定数増加させた後、該ホップ情報を他ノードに転送する手段と、
前記記録されたホップ情報から自ノードのホップ数分散情報を算出する手段と、
前記自ノードのホップ数分散情報を隣接ノードに送信する手段と、
前記自ノードのホップ数分散情報と隣接ノードから送信されたホップ数分散情報に基づき、自ノードがクラスタヘッドになるべきか判断する手段と、
自ノードがクラスタヘッドになると判断した場合、自ノードのノードＩＤを有するクラスタヘッド広告を他ノードに送信する手段と、
して機能させ、クラスタヘッドを決定するプログラム。