JP2006186446A - 通信方法 - Google Patents

Abstract

【課題】 アドホックネットワークを構成するクラスタを適正に構成できる通信方法を提供する。
【解決手段】 本発明は、同一のクラスタＩＤを有する複数のノード１２から成るクラスタ１１を生成し、クラスタ１１間で通信を行うアドホックネットワークを構成する通信方法であり、ノードＶｉは、隣接するノードのクラスタＩＤを取得し、隣接ノードのクラスタＩＤが、ノードＶｉのクラスタＩＤと異なり、且つ、前記ノードのクラスタＩＤとは異なるクラスタＩＤを有する隣接ノードの割合が、全ての前記隣接ノードに対して所定の値以上であるときは、前記ノードのクラスタＩＤを更新する。
【選択図】 図１

Description

本発明は、通信方法に関し、特に、アドホックネットワークを構成するクラスタを適正に生成できる通信方法に関するものである。

アドホックネットワークとは、有線ネットワークにおけるルータのようなルーティング機能を持つモバイル端末の集合である。モバイル端末が他のモバイル端末と通信する場合、送信元モバイル端末から発生したデータパケットは、他のモバイル端末を経由する。すなわち、アドホックネットワークにおけるモバイル端末は、携帯電話システムのような基地局を用いることなく通信が行える。モバイル端末がどの方向へ、またどんな速度でネットワーク内を移動しても、集合から離れなければお互いに通信することが可能である。

アドホックネットワークを用いる場合は、クラスタリングとルーティングを適正に行うことが重要である（下記特許文献１を参照）。ここで、クラスタリングとはネットワークをクラスタと呼ばれるサブネットワークに分割することである。また、ルーティングとは、パケット（情報）を転送する端末間の経路を決定することである。
特開２００４−２１５０６４号公報

しかしながら、一般的なクラスタリングでは、各クラスタの地理的形状が考慮されていない。従って、細長いクラスタの形状が構成されてしまう恐れがある。この場合は、クラスタ内のゲートウェイ数が増加し、クラスタ間のパケットコリージョンが引き起こされる恐れがある。更に、クラスタ間のルーティングが非効率に成ってしまう可能性もある。

また、各モバイル端末の地理的位置情報を利用することにより、上記の問題は回避可能である。しかしながら、地理的位置情報を用いると、各モバイル端末を経由する情報量が増大してネットワークに与える負荷が大きくなってしまう問題があった。

本発明は、上記問題を鑑みて成されたものである。本発明の主たる目的は、ネットワークの接続状態が変化した場合でも、クラスタの地理的な形状が考慮された通信方法を提供することにある。

本発明の通信方法は、同一のクラスタＩＤを有する複数のノードから成るクラスタを生成し、前記クラスタでアドホックネットワークを構成する通信方法であり、前記ノードは、隣接する隣接ノードのクラスタＩＤを取得し、前記ノードのクラスタＩＤとは異なるクラスタＩＤを有する隣接ノードの割合が、全ての前記隣接ノードに対して所定の値以上であるときは、前記ノードのクラスタＩＤを更新することを特徴とする。

更に本発明の通信方法では、前記隣接ノードの少なくとも１つは、前記ノードと同一のクラスタＩＤを有することを特徴とする。

更に本発明の通信方法では、前記クラスタを構成するノードは、クラスタを管理するクラスタヘッドと、異なるクラスタＩＤを有するノードに隣接するゲートウェイを含み、前記隣接ノードの全ては、前記ゲートウェイであることを特徴とする。

更に本発明の通信方法では、前記ノードは、移動可能な通信端末であることを特徴とする。

更に本発明の通信方法では、前記ノードのクラスタＩＤとは異なるクラスタＩＤを有する隣接ノードの割合が、全ての前記隣接ノードに対して４０％以上であるときに、前記ノードのクラスタＩＤを更新することを特徴とする。

更に本発明の通信方法は、同一のクラスタＩＤを有する複数のノードから成るクラスタを生成し、前記クラスタでアドホックネットワークを構成する通信方法であり、前記ノードは、隣接する隣接ノードのクラスタＩＤを取得し、前記ノードと同一のクラスタＩＤを有する前記隣接ノードの数が、前記ノードとは異なるクラスタＩＤを有する前記隣接ノードよりも少ないときは、前記ノードのクラスタＩＤを更新することを特徴とする。

更に本発明の通信方法では、前記ノードと同一のクラスタＩＤを有する隣接ノードの数が２以下、且つ、前記ノードとは異なるクラスタＩＤを有する前記隣接ノードの数が３以上であるときに、前記ノードのクラスタＩＤを更新することを特徴とする。

更に本発明の通信方法では、前記クラスタを構成するノードは、クラスタを管理するクラスタヘッドと、異なるクラスタＩＤを有するノードに隣接するゲートウェイを含み、前記隣接ノードの全ては、前記ゲートウェイであることを特徴とする。

更に本発明の通信方法では、前記ノードは、移動可能な通信端末であることを特徴とする。

本発明の通信方法に依れば、地理的な形状が考慮されたクラスタリングを行うことができる。従って、各クラスタは丸みを帯びた形状となる。結果的に、各クラスタのゲートウェイ数を削減することが可能となる。従って、ノードが移動することによりネットワークトポロジが変化した場合でも、丸みを帯びたクラスタを再構築することができる。

更に、クラスタリングを行う際に、各ノードの地理的位置情報を用いていないので、制御パケット数の増加を抑止して、効率的なクラスタリングを行うことができる。

以下、図を参照して本発明の実施の形態を説明する。

先ず、図１を参照してアドホックネットワーク１０の概要を説明する。

アドホックネットワークとは、モバイル基地局や優先リンクを持たず、基本的に交換機能を有するモバイル端末（以下ノードを呼ぶ）だけで構成されるネットワークである。本形態では、アドホックネットワークは、複数のクラスタに分割されている。ここでは、アドホックネット１０は、第１のクラスタ１１Ａ、第２のクラスタ１１Ｂおよび第３のクラスタ１１Ｃの３つに分割されている。実際は、更に多数個のクラスタ１１によりネットワークが構成される。

クラスタ１１は複数のノード１２から構成される。ここでは、第1のクラスタ１１Ａはノード１２Ａ〜１２Ｄから成る。そして、第２のクラスタ１１Ｂは、ノード１２Ｅ〜１２Ｈから成る。更に、第３のクラスタ１１Ｃは、ノード１２Ｊ〜１２Ｌから成る。各ノードは、クラスタヘッド、ゲートウェイ、クラスタメンバの何れかの役割を有する。

本形態では、クラスタは以下の特徴が満たされるように維持される。クラスタヘッドのノードＩＤが管理するクラスタのＩＤとなり、このＩＤをクラスタＩＤと呼ぶ。クラスタ内の任意のノードは、同じクラスタＩＤを持つ隣接ノード間の無線リンクによって接続される。更に、クラスタのサイズは下限Ｌ及び上限Ｕで制限される。例えば、クラスタ内のノードの数は、１０から２５程度の間に制限することができる。更に、各ノードは、ノードＩＤ、クラスタＩＤ、状態、隣接ノードリストの状態に関する情報を所有している。

例えば、アドホックネットワークを用いて、モバイル端末であるノード１２Ａとノード１２Ｌとが通信を行う場合は、以下の経路にて両者が接続される。即ち、１２Ａ→１２Ｂ→１２Ｆ→１２Ｈ→１２Ｉ→１２Ｋ→１２Ｌの経路で、ノード１２Ａとノード１２Ｌとは通信可能になる。

図２を参照して、アドホックネットワークを構成するクラスタを更に詳細に説明する。

クラスタヘッドとは、クラスタを管理するノードである。図２で示されるように、クラスタヘッドはクラスタ内の全ノードに関する情報を効率良く収集するため、クラスタ内にスパニングツリーを形成する。スパニングツリーとは、クラスタヘッドを根としたツリー状の接続形態であり、クラスタ内のデータパケットの転送に利用される。スパニングツリーを用いることにより、ループを無くした経路が実現される。

クラスタヘッドは、収集した情報を元に、クラスタ内のノードのリストを作成する。次に、クラスタヘッドは、隣接クラスタに関する情報を収集することで、隣接する全てのクラスタのリストを作成する。これら二つのリストを用いて、クラスタヘッドは以下のようにクラスタ内のノード数を調整する。即ち、クラスタ内のノード数がＬ（例えば１０個）未満の場合、クラスタヘッドは全隣接クラスタのサイズを調べ、自クラスタを隣接クラスタの一つと結合する。また、クラスタ内のノード数がＵ（例えば２５個）より大きい場合、クラスタヘッドは自クラスタを二つのクラスタに分割する。どちらの場合も、結合あるいは分割されたクラスタの隣接クラスタは更新されるが、クラスタの結合及び分割の影響は制限される。なぜなら、クラスタの維持は局所的に行われるからである。

ゲートウェイは、異なるクラスタＩＤを有するノードに隣接しているノードである。ここでは、黒塗りで示されているノードがゲートウェイである。即ち、ノードＶ_ｉのクラスタＩＤと異なるクラスタＩＤを持つノードがＶ_ｉに隣接している場合、Ｖ_ｉはゲートウェイと呼ばれる。ゲートウェイＶ_ｉは、隣接クラスタ内のゲートウェイと情報を交換することで、その隣接クラスタのノード数を知ることができる。

クラスタ維持のため、クラスタヘッドは定期的にクラスタ内に''clustermember''メッセージをブロードキャストする。ここで、ブロードキャストとは、クラスタ内の全てのノードに対して情報を発信することを指す。clustermemberメッセージを受信したクラスタ内の各ノードは、木に沿ってクラスタヘッドに向けてＲＥＰＬＹメッセージを返信する。このとき、クラスタメンバ及びゲートウェイは、それぞれ自分自身のＩＤ及び隣接クラスタの情報をＲＥＰＬＹメッセージに含める。その結果、クラスタヘッドはクラスタ内のクラスタメンバと隣接クラスタの両方に関する情報を集めることができる。各ノードは隣接ノードがブロードキャストするあらゆるメッセージを受信できるので、局所情報を収集できる。また、各ノードはその局所情報に従ってクラスタ内の自分の役割を変化させるため、自律的にクラスタを構成することが可能となる。

図３を参照して、次に、クラスタを構成するノードの状態と役割に関して説明する。本形態のクラスタリング手法では、各ノードは一つの状態を持ち、その状態に対応する役割を果たす。ノードは、ＮＳＮ、ＣＮ、ＢＮ、ＢＣＮ、ＯＮのいずれかの状態にあり、各状態での役割を以下で説明する。
・Normal State Node（ＮＳＮ）:ノードはクラスタヘッドや、ゲートウェイの機能を持たない。例えば、第１のクラスタ１１Ａに含まれるノード１２Ｃが、ＮＳＮの一例である。
・Control Node（ＣＮ）:ノードはクラスタヘッドの役割を果たす。例えば、第１のクラスタ１１Ａに含まれるノード１２Ａが、ＣＮの一例である。ここでは、ノード１２Ａにより、第１のクラスタ１１Ａに含まれる全てのノードが制御されている。そして、ノード１２ＡのノードＩＤが、第１のクラスタ１１ＡのクラスタＩＤとなる。
・Border Node（ＢＮ）：ノードはゲートウェイとなる。例えば、第１のクラスタ１１Ａに含まれる、ノード１２Ｂおよびノード１２Ｄが、ＢＮの一例である。
・Border Control Node（ＢＣＮ）：ノードはクラスタヘッドとゲートウェイの役割を担うことになる。例えば、第２のクラスタ１１Ｂに含まれるノード１２Ｆが、ＢＣＮの一例である。
・Orphan Node（ＯＮ）：ノードの状態がＯＮのとき。ノードはクラスタＩＤを持たない。新しくネットワークに加えられたノードは、最初はこの状態である。例えば、第３のノード１１Ｃに含まれるノード１２Ｍが、ＯＮの一例である。

次に、ノードの状態遷移に関して説明する。クラスタヘッドやゲートウェイのような、クラスタリングにおいて不可欠な役割を果たすノードさえもネットワーク中を動き回る。そのため、そのノードが役割を果たせなくなった場合はいつでも、他のノードが代わりにその役割を果たさなければならない。ノードが移動してもクラスタリングを維持するために、ノードは自律的に自分の状態を変化させ、その状態に対応した役割を果たす。各ノードの状態は、隣接ノードの状態の変化に応じて変化する。ノードは常にネットワーク中を移動するので、ノードの移動に対する適応性はクラスタリングにとって最も重要な特徴の一つである。

図４を参照して、上記各状態に於ける動作を説明する。ここで、ＮＮ_ｉをノードＶｉの隣接ノードの集合とする。ノードＶｉは隣接ノードからのhelloパケットを受信することでこの集合を認識する。ＮＮ_ｉにおけるノードのクラスタＩＤも、helloパケットから得られる。このクラスタＩＤに基づき、ノードＶｉが持つべきクラスタＩＤは以下のように割り当てられるか、あるいは更新される。ここでは、ノードの状態が、ＯＮの場合とそれ以外の場合に分けて説明する。

ノードＶｉの状態がＯＮの場合は、以下の２つのケース（ケース１およびケース２）に従って、クラスタＩＤが更新される。

ケース１：図４（Ａ）参照
ノードＶｉがＯＮであるノードからhelloパケットを受信した場合、ノードＶｉは隣接ノードも全てＯＮであると認識し、ある確率で自分のクラスタＩＤにｉを割りあてる。具体的には、ノード１２Ａ〜１２Ｆから成るＮＮ_ｉが構成されている。そして、Ｖｉは、状態がＯＮであるノード１２ＤからHELLOパケットを受信すると、集合体ＮＮ_ｉを構成する全てのノード１２の状態がＯＮであると判断される。そして、ＶｉのクラスタＩＤにｉを割り当てる。

ケース２：図４（Ｂ）参照
ノードＶｉが、クラスタＩＤがｋである隣接ノードからHELLOパケットを受信した場合、ノードＶｉはクラスタＩＤｋを持つ隣接ノードの存在を認識する。そして、ノードＶｉのクラスタＩＤはｋとなる。

ノードＶｉの状態が、ＣＮ、ＢＣＮ、ＢＮ、ＮＳＮの何れかである場合（ＯＮ以外である場合）は、以下のケース３に従って、クラスタＩＤが更新される。

ケース３：図４（Ｃ）参照
ノードＶｉのクラスタＩＤはｋである。そして、ノードＶｉにはクラスタＩＤｋを有する隣接ノードがいたと仮定する。ノードＶｉが各隣接ノードからHELLOパケットを受信して、そのパケットのクラスタＩＤがｋ以外であった場合、ノードＶｉはクラスタＩＤｋを有する隣接ノードは全て消失したと認識する。即ち、ノードＶｉを取り巻く隣接ノードのクラスタＩＤは、ｋ以外であると認識する。そして、全隣接ノードに対して最も多いノードが有するクラスタＩＤを、ノードＶｉのクラスタＩＤとする。

具体的には、ノードＶｉは、第１のクラスタ１１Ａ、第２のクラスタ１１Ｂおよび第３のクラスタ１１Ｃに囲まれている。第１のクラスタ１１ＡのクラスタＩＤはｐであり、第２クラスタ１１ＢのクラスタＩＤはｑであり、第３のクラスタ１１ＣのクラスタＩＤはｒである。また、第１のクラスタ１１Ａは２つのノードを含み、第２のクラスタ１１Ｂも２つのノードを含み、第３のクラスタ１１Ｃは３つのノードを含む。また、この状態では、ノードＶｉは、自分自身と同一のクラスタＩＤは隣接ノードに存在しないと認識している。

ノードＶｉは、各クラスタ１１から得られたHELLOパケットを基に、自らのクラスタＩＤを決定する。更に、最も数が多いノードのクラスタＩＤに、ノードＶｉのクラスタＩＤは更新される。ここでは、３つの各クラスタ１１Ａ、１１Ｂ、１１Ｃに含まれるノード１２の各々から、HELLOパケットがノードＶｉに発信されている。そして、第３のクラスタ１１Ｃは、３つのノード１２がノードＶｉに隣接しており、最も数が多い。そして、第３のクラスタＩＤは、ｒである。従って、ノードＶｉのクラスタＩＤは、ｒに更新される。即ち、ノードＶｉは、第３のクラスタ１１Ｃに取り込まれる。

図５を参照して、本形態では、ノードＶｉが持つべきクラスタＩＤは、隣接するのノードの集合体から得られる。更に、このクラスタＩＤの情報に基づき、ノードＶｉが持つべき状態は、以下のように変化する。本形態では、この状態変化を状態遷移と呼ぶ。

以下で記述する状態遷移条件が満たされるなら、ノードＶｉは図５に示すような状態遷移Ａ−Ｅを行う。
・遷移Ａの条件：クラスタＩＤが変更され、そのＩＤがＶｉのノードＩＤと一致した。この遷移は、ノードＶｉにクラスタヘッドの役割の追加することを意味している。
・遷移Ｂの条件：クラスタＩＤが変更され、そのＩＤがノードＶｉのノードＩＤと一致しない。この遷移は、ノードＶｉが通常の端末に戻ることを意味している。
・遷移Ｃの条件：ノードＶｉのノードＩＤと異なる隣接ノードが現れた。この遷移は、ノードＶｉにゲートウェイの役割を追加することを意味している。
・遷移Ｄの条件：全ての隣接ノードのＩＤが、ノードＶｉのノードＩＤと一致しない。この遷移は、ノードＶｉから、ゲートウェイの役割の削除を意味している。
・遷移Ｅの条件：ノードＶｉに隣接するノードが無くなった。あるいは、ノードＶｉがクラスタヘッドからのメッセージをある期間受信できない。この遷移は、ノードＶｉをＯＮ状態にすることを意味している。

上述したように、各ノードのクラスタＩＤは、ケース１、２、３で説明したように変化する。ネットワークが密な場合は、上述した方法を用いると、クラスタ間のパケットコリジョンや非効率なルーティングが発生する恐れがある。その理由は、この方法ではクラスタの地理的形状が考慮されていないので、細長い形状のクラスタが形成される恐れがあるからである。

パケットコリジョンとは、パケット同士が衝突する不具合のことである。具体的には、クラスタの形状が細長くなり、ゲートウェイ数が増加することにより、この問題は引き起こされる。非効率なルーティングも、クラスタが細長くなることにより引き起こされる。即ち、クラスタの形状が細長い場合、データパケットが多くのゲートウェイを介して遠回りしてしまう。

図６から図８を参照して、クラスタの地理的形状が考慮されたクラスタリング手法を説明する。以下に説明するクラスタリング手法では、ＯＮを除く各ノードのクラスタＩＤは、ケースＡ、ケースＢ、ケースＣで説明されるように変化する。以下の説明では、ノードに関する地理的情報を利用せずに、地理的形状が考慮されたクラスタリングを行うことができる。

ケースＡ：図６を参照
このケースは、等しいクラスタＩＤを有するノードＶｉの隣接ノードが消失した場合のクラスタリングである。図６（Ａ）はケースＡのクラスタリングを行う前のクラスタを示し、図６（Ｂ）はクラスタリングを行った後のクラスタを示す図である。

図６（Ａ）を参照して、ノードＶｉは、第１のクラスタ１１Ａ、第２のクラスタ１１Ｂおよび第３のクラスタ１１Ｃに囲まれている。第１のクラスタ１１Ａおよび第２のクラスタ１１Ｂは、２つのノード１２を含み、第３のクラスタ１１Ｃは３つのノードを含む。

ここで、ノードＶｉのクラスタＩＤがｋであり、且つ、ノードＶｉにはクラスタＩＤｋを有する隣接ノードが存在していたと仮定する。ノードＶｉは、隣接ノードからHELLOパケットを受信することで、クラスタＩＤｋを有する隣接ノードが全て消滅したと認識する。次に、ノードＶｉのクラスタＩＤは、ｋ以外に更新される。ここでは、全ノードに対して最も数が多いノードが有するクラスタＩＤが採用される。即ち、第３のクラスタ１１ＣのクラスタＩＤであるｒが、ノードＶｉのクラスタＩＤとなる。

図６（Ｂ）を参照して、ケースＡのクラスタリングを行うことにより、ノードＶｉは第３のクラスタに取り込まれている。

ケースＢ：図７を参照
このケースは、ノードＶｉが細長いクラスタに囲まれた場合のクラスタリングである。図７（Ａ）はケースＢのクラスタリングを行う前のクラスタを示し、図７（Ｂ）はクラスタリングを行った後のクラスタを示す図である。

図７（Ａ）を参照して、ここでは、第１のクラスタ１１Ａ〜第４のクラスタ１１Ｄが隣接している。第１のクラスタ１１Ａは直列に配置された６個のノード１２からなり、細長く延在している。第２のクラスタ１１Ｂに含まれるノードＶｉは、第１のクラスタ１１Ａに囲まれるように位置している。第３のクラスタ１１Ｃおよび第４のクラスタ１１Ｄに含まれるノード１２も、ノードＶｉに隣接している。上述したケースＡでは、ノードＶｉと同様のクラスタＩＤを有する隣接ノードが消滅していたが、ケースＢでは同様のクラスタＩＤを有する隣接ノードが存在している。

ノードＶｉは、隣接ノードからHELLOパケットを受信して、クラスタＩＤを更新する。具体的には、隣接ノード数が最も多く、そのノード数が全隣接ノード数のｈ％以上であった場合に、ノードＶｉのクラスタＩＤはそのノードのクラスタＩＤに更新される。具体的なｈ％の値としては、例えば、４０％、５０％、６０％、７０％、８０％等が採用される。

ここでは、ノード１２Ａ〜ノード１２Ｉ間での９個のノードが、ノードＶｉに隣接している。第１のクラスタ１１Ａでは、ノード１２Ａから１２Ｆまでの６個のノードが、ノードＶｉに隣接している。そして、第３のクラスタ１１Ｃでは、１つのノード１２ＩのみがノードＶｉに隣接している。また、第４のクラスタ１１Ｄでも、１つのノード１２ＧのみがノードＶｉに隣接している。従って、最も多くのノード１２が隣接しているクラスタは、第１のクラスタ１１Ａであり、そのノード数の全隣接ノードに占める割合は約６７％である。更に、ノードＶｉの隣接ノードは全てがゲートウェイである。このことから、ｈの値を６０以下にした場合は、この第１のクラスタ１１ＡのクラスタＩＤであるｐが、ノードＶｉのクラスタＩＤとなる。

図７（Ｂ）を参照して、上記クラスタリングにより、ノードＶｉは第１のクラスタ１１Ａに取り込まれている。ノードＶｉが取り込まれることにより、第１のクラスタ１１Ａは丸みを帯びた形状となり、総ノード数に対するゲートウェイ数が削減されている。

このケースＢは、ノードＶｉが属するクラスタが細長くない場合でも、ゲートウェイであるノードＶｉが、細長い他のクラスタに囲まれることで、ノードＶｉがそのクラスタに取り込まれる。

ケースＣ：図８を参照
このケースは、ノードＶｉ自身が属するクラスタが細長い形状を有する場合のクラスタリングである。図８（Ａ）はケースＢのクラスタリングを行う前のクラスタを示し、図８（Ｂ）はクラスタリングを行った後のクラスタを示す図である。

図８（Ａ）を参照して、ここでは、第１のクラスタ１１Ａ〜第４のクラスタ１１Ｄが隣接している。第1のクラスタ１１Ａおよび第２のクラスタ１１Ｂは、ノードＶｉに隣接するノード１２を２個含んでいる。また、第３のクラスタ１１Ｃは、ノードＶｉに隣接するノードを３個含んでいる。ここでは、ノードＶｉは、それ自身が細長く延在する第４のクラスタ１１Ｄの端部に位置するノードである。

ノードＶｉは、隣接ノードからHELLOパケットを受信して、クラスタＩＤを更新する。そして、ノードＶｉと同じクラスタＩＤｋを有する隣接ノードの数よりも、異なるクラスタＩＤを有する隣接ノードの数が多かった場合に、ノードＶｉのクラスタＩＤは更新される。例えば、同じクラスタＩＤを有する隣接ノードの数が２個以下、且つ、異なるクラスタＩＤを有する隣接ノードが３個以上であった場合に、ノードＶｉのクラスタＩＤは更新される。また、ノードＶｉのクラスタＩＤは、全隣接ノードに対して数が最も多いノードが属するクラスタＩＤに変更される。更に、隣接ノードの全てがゲートウェイであることも、ノードＶｉのクラスタＩＤを更新するための条件である。

ここでは、ノードＶｉと同じクラスタＩＤｋを有するノードは、ノード１２Ｉおよびノード１２Ｈの２つのノードがある。そして、クラスタＩＤｐを有する２つのノード１２Ａ、１２Ｂが、ノードＶｉに隣接している。更に、クラスタＩＤｑを有する２つのノード１２Ｃ、１２Ｄが、ノードＶｉに隣接している。更にまた、クラスタＩＤｒを有する３つのノード１２Ｅ、１２Ｆおよび１２Ｇが、ノードＶｉに隣接している。

上記のことから、ノードＶｉとは異なるクラスタＩＤであるクラスタＩＤｒを有する隣接ノードの数が最も多く、その個数は３個である。一方、ノードＶｉと同じくラスタＩＤｒを有するノードの数は２個である。従って、ノードＶｉのクラスタＩＤを変更する上記の条件は満たされているので、ノードＶｉのクラスタＩＤは、ｋからｒに変更される。

図８（Ｂ）を参照して、ノードＶｉのクラスタＩＤはｒに変更されて、第３のクラスタ１１Ｃに取り込まれている。このことにより、第４のクラスタ１１Ｄの形状は丸みを帯びる。

上記したケースＢでは、ノードＶｉの隣接ノードが以下の条件を満たすと、ノードＶｉと同様のクラスタＩＤが隣接している場合でも、そのクラスタＩＤが更新される。
・ゲートウェイであるノードのみに囲まれている。
・隣接ノードの大部分が、ノードＶｉとは異なるクラスタＩＤを有している。

また、ケースＣでは、ノードＶｉの隣接ノードが以下の条件を満たすと、ノードＶｉと同様のクラスタＩＤが隣接している場合でも、そのクラスタＩＤが更新される。従って、ノードＶｉのリンクが切れる可能性を回避することができる。
・ゲートウェイであるノードのみに囲まれている。
・ノードＶｉと等しいクラスタＩＤの隣接ノードが、１つまたは２つしかない。

上記したケースＢは、ノードＶｉが細長いクラスタに囲まれたときに、その細長いクラスタにノードＶｉが取り込まれることで、クラスタの形状を丸くすることができる。また、ケースＣでは、ノードＶｉが属するクラスタ自身が細長いときに、クラスタの端部に位置するノードＶｉが他のクラスタに属することで、クラスタの形状を丸くすることができる。従って、ケースＢとケースＣとは互いに補完する関係にあるので、両者を用いたクラスタリングを行うことにより、結果としてゲートウェイ数を削減することができる。従って、効率よく通信を行うことができるアドホックネットワークを構成することができる。

次に、図９以降の図を参照して、上記本形態のクラスタリングをシミュレーションにより評価する。ここでは、本形態のクラスタリングを以下の２つの基準で評価する。
（１）ゲートウェイ数：総ゲートウェイ数とクラスタ毎の平均ゲートウェイ数をシミュレーション実験で計測した。
（２）クラスタの形状：一般的に、クラスタの形状が丸みを帯びているかどうかを量的に示すのは難しい。そのため、各ノードにおいて、そのノードのクラスタＩＤと同じクラスタＩＤを持つ平均隣接ノード数と、各ノードの平均隣接ノード数をシミュレーション実験で計測した。後者の平均数に対する前者の平均数の割合を計算した。

全てのクラスタのサイズ（すなわち、ノード数）がほぼ等しい場合は、上記の割合が高くなるにつれ、クラスタの形状はより丸みを帯びたものになると言える。

図９（Ａ）および（Ｂ）に、本シミュレーションの条件を示す。各パラメータの組み合わせに対して10回ずつシミュレーション実験を行った。尚、以下の説明では上記したケース１、ケース２、ケース３を適用したクラスタリングを比較例「Previous」とする。また、Ｇ−４０、Ｇ−５０、Ｇ−６０、Ｇ−７０、Ｇ−８０はそれぞれ、上記したケースＢに於けるｈの値が４０、５０、６０、７０、８０である時の本形態のクラスタリングを示す。

図１０から図１４を参照して、シミュレーション結果を説明する。

図１０はネットワーク中の総ゲートウェイ数を表している。これらの値は、０．２５秒毎に計測したネットワーク中の総ゲートウェイ数の平均により求められている。シミュレーションの総ノード数は１５０であるため、比較法と本形態でのゲートウェイ数は、それぞれ全ノード数の約７５％と６０％に相当する。ゲートウェイ数は５ｍ／ｓから２０ｍ／ｓまで徐々に減少しており、どの場合でも減少割合はほとんど同じである。従って、どのノード速度においても本形態では約２０％ゲートウェイ数を削減している。

図１１を参照して、次に、各クラスタのゲートウェイ数に関する結果を示す。図１１（Ａ）と図１１（Ｂ）は、それぞれ各クラスタの平均ゲートウェイ数と平均ノード数を表す。これらの値は、０．２５秒毎に計測したネットワーク中の各クラスタ内のゲートウェイ数とノード数の平均により求められている。図１１（Ａ）と図１１（Ｂ）で示されているように、各クラスタのゲートウェイ数とノード数はノード速度が速くなるにつれて増加しており、増加割合はどの場合でもほとんど同じである。本形態による各クラスタのゲートウェイ数は約２０％減少している。一方、各クラスタのノード数は比較法でも本形態でもほぼ同数である。この結果は、本形態はクラスタサイズを維持しつつ、ゲートウェイの大幅な削減を実現していることを意味する。

図１２を参照して、クラスタの形状に関する結果を説明する。このグラフは、各ノードにおいて、ノードのクラスタＩＤと同じクラスタＩＤを持つ平均隣接ノード数を表している。本形態での同じクラスタＩＤをもつ隣接ノード数は、どのノード速度でも比較法より多く、ノードの速度が速い場合は約１０％から２０％多い。

図１３（Ａ）は、平均隣接ノード数に対する上記の平均数の割合を示している。ノードの速度が速い場合は本形態における割合は約７０％、比較法における割合は約５５％となっているため、割合は約２０％減少していることを示している。これらの結果から、本形態でのクラスタの形状は比較法と比較すると丸みを帯びていると言える。

図１３（Ｂ）を参照して、オーバヘッドに関する結果を説明する。比較法と本形態での制御パケット数を比較することで、本形態のオーバヘッドを考察する。このグラフは制御パケット数を示しており、本形態における制御パケット数は比較法とほとんど等しい。この結果から、本形態で新しく導入されたケースＢおよびケースＣは余分な制御パケットを生成してはいないと言える。この理由は、隣接クラスタに関する位置情報に基づいて自律的に各ノードがクラスタＩＤを変化させるからである。従って、ほとんど同じオーバヘッドであるにも関わらず、本形態によってゲートウェイ数が大幅に削減され、クラスタが丸みを帯びた形状になったことは注目に値する。

図１４（Ａ）は、ケースＢあるいはケースＣの適用回数に対するケースＢの割合を表している。本形態では、ケースＢとケースＣを適用させることでゲートウェイ数を削減した。ケースＢの定義から、値ｈが小さくなるほどケースＢはケースＣより適用されるようになる。この図から、割合はノード速度に依存せず、ｈの値が小さくなるにつれて割合は増加しているが、増加割合は減少しており、ｈが５０のときはほとんど０になっていることが分かる。ケースＢとケースＣは互いにほとんど依存性がないから、ケースＢの値ｈが変わったときでさえケースＣの適応回数ほとんど変化していない。最適なｈの値は、上述した割合だけでなく以下のオシレーションも考慮して決定すべきである。ここで、あるノードのクラスタＩＤが変わってから２秒以内に再びそのノードのクラスタＩＤ変わることをオシレーションと定義する。オシレーションとは、非効率的なクラスタＩＤの変化を意味する。

図１４（Ｂ）は、ケースＢとケースＣによるクラスタＩＤ変更回数に対するオシレーション回数の割合を表している。この図から、ｈの値が小さくなるにつれて割合は増加している。従って、ケースＢあるいはケースＣの適用回数とオシレーションが起こる回数はトレードオフの関係にある。ケースＢとケースＣを多く適用し、かつ非効率的なオシレーションを可能な限り回避することがベターである。これら２つの観点から、６０が適当なｈの値と考えられる。

本発明を適用したアドホックネットワークを示す図である。 本発明を適用したアドホックネットワークを構成するクラスタを示す図である。 本発明を適用したアドホックネットワークを構成するクラスタを示す図である。 （Ａ）、（Ｂ）および（Ｃ）は、本発明を適用したクラスタリングの基本的方法を説明する図である。 本発明を適用したアドホックネットワークを構成するノードの役割を説明する図である。 （Ａ）および（Ｂ）は、本発明を適用したクラスタリングを説明する図である。 （Ａ）および（Ｂ）は、本発明を適用したクラスタリングを説明する図である。 （Ａ）および（Ｂ）は、本発明を適用したクラスタリングを説明する図である。 （Ａ）および（Ｂ）は、シミュレーションの条件を示す表である。 シミュレーション結果を示すグラフである。 （Ａ）および（Ｂ）は、シミュレーション結果を示すグラフである。 シミュレーション結果を示すグラフである。 （Ａ）および（Ｂ）は、シミュレーション結果を示すグラフである。 （Ａ）および（Ｂ）は、シミュレーション結果を示すグラフである。

符号の説明

１０ アドホックネットワーク
１１Ａ〜１１Ｄ クラスタ
１２Ａ〜１２Ｈ ノード

Claims (9)

1. 同一のクラスタＩＤを有する複数のノードから成るクラスタを生成し、前記クラスタでアドホックネットワークを構成する通信方法であり、
   前記ノードは、隣接する隣接ノードのクラスタＩＤを取得し、
   前記ノードのクラスタＩＤとは異なるクラスタＩＤを有する隣接ノードの割合が、全ての前記隣接ノードに対して所定の値以上であるときは、前記ノードのクラスタＩＤを更新することを特徴とする通信方法。
2. 前記隣接ノードの少なくとも１つは、前記ノードと同一のクラスタＩＤを有することを特徴とする請求項１記載の通信方法。
3. 前記クラスタを構成するノードは、クラスタを管理するクラスタヘッドと、異なるクラスタＩＤを有するノードに隣接するゲートウェイを含み、
   前記隣接ノードの全ては、前記ゲートウェイであることを特徴とする請求項１記載の通信方法。
4. 前記ノードは、移動可能な通信端末であることを特徴とする請求項１記載の通信方法。
5. 前記ノードのクラスタＩＤとは異なるクラスタＩＤを有する隣接ノードの割合が、全ての前記隣接ノードに対して４０％以上であるときに、前記ノードのクラスタＩＤを更新することを特徴とする請求項１記載の通信方法。
6. 同一のクラスタＩＤを有する複数のノードから成るクラスタを生成し、前記クラスタでアドホックネットワークを構成する通信方法であり、
   前記ノードは、隣接する隣接ノードのクラスタＩＤを取得し、
   前記ノードと同一のクラスタＩＤを有する前記隣接ノードの数が、前記ノードとは異なるクラスタＩＤを有する前記隣接ノードよりも少ないときは、前記ノードのクラスタＩＤを更新することを特徴とする通信方法。
7. 前記ノードと同一のクラスタＩＤを有する隣接ノードの数が２以下、且つ、前記ノードとは異なるクラスタＩＤを有する前記隣接ノードの数が３以上であるときに、前記ノードのクラスタＩＤを更新することを特徴とする請求項６記載の通信方法。
8. 前記クラスタを構成するノードは、クラスタを管理するクラスタヘッドと、異なるクラスタＩＤを有するノードに隣接するゲートウェイを含み、
   前記隣接ノードの全ては、前記ゲートウェイであることを特徴とする請求項６記載の通信方法。
9. 前記ノードは、移動可能な通信端末であることを特徴とする請求項６記載の通信方法。
   
   

Images