JP6206483B2 - 通信方法、通信プログラム、および、ノード装置 - Google Patents

Description

本発明は、複数のノード装置を含むネットワークで行われる通信に関する。

アドホックネットワークに参加するノード装置は他のノード装置との間でＨｅｌｌｏフレームを送受信することにより、ネットワークを形成することができる。例えば、あるアドホックネットワークに属するノードＡは、ノードＡが保持している経路情報を含むＨｅｌｌｏフレームを生成し、周期的にブロードキャストする。Ｈｅｌｌｏフレームを受信したノードＢは、ノードＢが保持している経路情報と、Ｈｅｌｌｏフレームに含まれている情報を比較し、ノードＢが保持していなかった経路情報をＨｅｌｌｏフレームから取得する。

アドホックネットワークに含まれるノード装置の数が大きくなると、図１に示すように、アドホックネットワークが複数のクラスタに分けられる場合がある。図１の黒色の丸はノード装置を表すものとする。図１の例では、アドホックネットワークは、クラスタＡ〜Ｃに分けられている。図１に示す破線は、各ノード装置からの電波が届く範囲を示す。例えば、ノードＮ１からの電波はノードＮ２、Ｎ４などに届くので、ノードＮ１は、フレームをノードＮ２、Ｎ４に送信することができる。ノードＮ１のように、複数のクラスタが接する境界の近傍に位置するノード装置は、隣接クラスタに含まれるノード装置にアクセスすることができる。このため、例えば、図１中の二重線で示すようにクラスタ間での通信経路が形成されたとすると、クラスタＡに含まれているノード装置は、ノードＮ１〜Ｎ３のいずれかを経由して他のクラスタに含まれているノード装置と通信することができる。同様に、クラスタＢに含まれているノード装置は、ノードＮ４〜Ｎ７を介して他のクラスタ中のノード装置と通信でき、クラスタＣに含まれているノード装置は、ノードＮ８〜Ｎ１１を介して他のクラスタ中のノード装置と通信できる。

関連する技術として、複数のモバイルノードが複数のモバイルグループに分けられているネットワークも知られている。アドミニストレータは、モバイルグループに含まれているモバイルノードの１つを、モバイルグループのグループリーダとして、静的に設定する。モバイルグループリーダは、モバイルグループの管理制御を行う。

特表２００９−５０８４３４号公報

アドホックネットワーク中のノード装置の数が増大するにつれて、隣接するクラスタ中のノード装置と通信可能なノード装置の数も増大する可能性がある。クラスタ間の通信を行わないノード装置は、そのノード装置と同じクラスタに属しているノード装置のうちで、隣接するクラスタ中のノード装置と通信可能なノード装置に、他のクラスタ中のノード装置宛のフレームを転送する。このため、他のクラスタ中のノード装置と通信しようとするノード装置にとっては、隣接するクラスタ中のノード装置と通信できるノード装置の数が増大すると、フレームの転送先の候補の数が増大することになる。フレームの転送先となりうるノード装置の数が多い場合、ノード装置はフレームの転送先を決定するための処理を行うことになるので、フレームの転送処理が複雑になる。また、経路の決定の処理が複雑になると、経路の決定にかかる時間も長くなり、遅延が発生してしまう恐れがある。

本発明は、１つの側面では、クラスタ間の通信を効率的にすることを目的とする。

実施形態にかかる方法では、第１のクラスタ中に位置し、前記第１のクラスタに隣接する第２のクラスタ中のノード装置と通信可能なノード装置のグループである第１のグループから選択装置が選択される。選択装置は、前記第１のクラスタ中のノード装置と前記第２のクラスタ中のノード装置の間の通信に使用されるフレームである中継フレームを中継する第１の中継装置を、前記第１のグループから選択する。前記選択装置は、前記選択装置に隣接するノード装置へ、前記第１の中継装置の識別子を通知する通知フレームを送信する。前記選択装置に隣接するノード装置であって前記通知フレームにより通知される前記第１の中継装置の識別子が自身の識別子である該ノード装置である前記第１の中継装置は、前記中継フレームを受信すると、第２のグループに含まれるノード装置のうち、前記第１の中継装置に隣接するノード装置を、前記中継フレームを前記第２のクラスタ中のノード装置へ中継する第２の中継装置に決定する。ここで、第２のグループは、前記第２のクラスタ中に位置し、かつ、前記第１のクラスタ中のノード装置と通信可能なノード装置のグループである。

クラスタ間の通信が効率化される。

アドホックネットワークの例を示す図である。 実施形態にかかる通信方法の例を説明する図である。 Ｈｅｌｌｏフレームのフォーマットの例を示す図である。 ノード装置の構成の例を示す図である。 スレーブ側クラスタテーブルの例を示す図である。 マスタ側クラスタ情報とマスタ側クラスタテーブルの例を示す図である。 ノード装置のハードウェア構成の例を示す図である。 サブゲートウェイの設定方法の例を説明する図である。 第１の実施形態で行われる処理の例を説明するシーケンス図である。 第１の実施形態で行われる処理の例を説明するシーケンス図である。 マスタ側クラスタテーブルの例を示す図である。 スレーブ側クラスタテーブルとマスタ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルとスレーブ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルの例を示す図である。 スレーブ側クラスタテーブルの例を示す図である。 サブゲートウェイの変更方法の例を説明する図である。 マスタ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルとスレーブ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルの例を示す図である。 ノード装置で行われる処理の例を示すフローチャートである。 マスタ側クラスタ情報の処理の例を説明するフローチャートである。 マスタ側クラスタ情報の処理の例を説明するフローチャートである。 Ｈｅｌｌｏフレームの送信元が属するクラスタの情報の処理の例を説明するフローチャートである。 マスタ側サブゲートウェイの更新処理の例を説明するフローチャートである。 データフレームの例を示す図である。 第２の実施形態で用いられるマスタ側クラスタテーブルの例を示す図である。 第２の実施形態で用いられるスレーブ側クラスタテーブルの例を示す図である。 障害の発生によるサブゲートウェイの変更方法の例を説明する図である。 マスタ側クラスタテーブルの例を示す図である。 マスタ側クラスタテーブルの例を示す図である。 障害発生時にマスタ側クラスタ中の境界ノードが行う処理の例を説明するフローチャートである。 障害発生時にスレーブ側クラスタ中の境界ノードが行う処理の例を説明するフローチャートである。 第２の実施形態におけるマスタ側クラスタ情報の処理の例を説明するフローチャートである。 第２の実施形態におけるマスタ側クラスタ情報の処理の例を説明するフローチャートである。 Ｈｅｌｌｏフレームの送信元が属するクラスタの情報の処理の例を説明するフローチャートである。

図２は、実施形態にかかる通信方法の例を説明する図である。図２では、理解し易くするために、２つのクラスタに分けられている無線アドホックネットワークを例として説明する。

隣接するクラスタに含まれているノード装置と通信可能なノード装置は、そのノード装置の識別子（ノードＩＤ）と参加しているクラスタの識別子（クラスタＩＤ）を含む通知フレームを、隣接するノード装置に送信する。図２では、理解しやすくするために、互いに隣接するノード装置を実線で結んでいる。あるノード装置に「隣接する」ノード装置とは、あるノード装置から送信されたフレームを受信することができる範囲内に位置するノード装置のことを指すものとする。また、あるノード装置から送信されたフレームを受信できる範囲に位置するノード装置のことを、そのノード装置の「隣接ノード装置」と記載することがある。

ノード装置は、参加しているクラスタのクラスタＩＤと受信した通知フレームに含まれているクラスタＩＤを比較する。クラスタＩＤに含まれる数値が小さい方のクラスタに含まれているノード装置の間では、中継装置を選択するノード装置が選択される。以下、中継装置を選択するノード装置を「選択装置」と記載する。以下、選択装置を太線で示すものとする。図２（ａ）の例では、クラスタＩＤ＝１中のノードＡが選択装置として選択されている。

選択装置は、選択装置が含まれているクラスタ中に位置するノード装置のうち、隣接するクラスタ中のノード装置と通信可能なノード装置の中から、第１の中継装置を選択する。選択装置は、第１の中継装置のノードＩＤを選択装置の隣接ノードに通知する。第１の中継装置のノードＩＤを通知されたノード装置は、同じクラスタに属する隣接ノード装置に、第１の中継装置のノードＩＤを通知する。例えば、図２（ａ）の例では、ノードＢが第１の中継装置に選択されている。また、クラスタＩＤ＝１に含まれるノード装置は、ノードＢが第１の中継装置であることを、ノードＢからの通知を用いて認識する。

自ノードに割り当てられているノードＩＤと、第１の中継装置として動作するノードのＩＤが一致したノード装置は、自ノードが位置するクラスタと隣接するクラスタの間の通信を中継することを認識する。さらに、第１の中継装置は、隣接するノード装置のうち、隣接クラスタに含まれているノード装置から、第２の中継装置を選択する。第１の中継装置は、第２の中継装置に、クラスタ間の通信の中継を開始するように要求する。第２の中継装置は、第１の中継装置からの要求に応じて、クラスタ間の通信の中継を行うノード装置として選択されたことを認識する。図２（ｂ）の例では、第１の中継装置に選択されたノードＢは、隣接クラスタ中の隣接ノードであるノードＣを第２の中継装置に選択する。ノードＣは、クラスタＩＤ＝７に含まれる他のノード装置に、ノードＣが第２の中継装置であることを通知する。

その後、第１の中継装置と第２の中継装置が、クラスタ間の通信を中継する。従って、図２（ｂ）の例では、クラスタＩＤ＝１のクラスタに含まれるノード装置は、クラスタＩＤ＝７のクラスタに含まれているノード装置宛のフレームを、ノードＢに送信する。ノードＢは、クラスタＩＤ＝７のクラスタ中のノード装置宛のフレームを、ノードＣに転送する。ノードＣは宛先のノード装置にフレームを送信する。また、クラスタＩＤ＝７のクラスタ中のノード装置は、クラスタＩＤ＝１のクラスタ中のノード装置宛のフレームをノードＣに送信する。ノードＣは、クラスタＩＤ＝１のクラスタ中のノード装置宛のフレームをノードＢに送信する。ノードＢは、ノードＣから転送されてきたフレームを宛先のノード装置に送信する。

このように、隣接する２つのクラスタの一方では、クラスタ間を中継するノード装置が自律的に決定されるので、クラスタ間の通信を中継するノード装置の数が減少する。さらに、同じクラスタ内の選択装置からクラスタ間の通信を中継する中継装置として選択された第１の中継装置は、第1の中継装置の隣接ノード装置であって、隣接するクラスタ中のノード装置から、第２の中継装置を選択する。このため、自律的にクラスタ間の通信を中継するノード装置を選択していないクラスタにおいても、クラスタ間の通信を中継するノードの数が限定される。クラスタ間の通信を中継するノードの数が減少するため、経路の決定の処理が単純化され、経路の決定にかかる時間が短縮化される。

＜通知フレーム＞
通知フレームとしてＨｅｌｌｏフレームが用いられることがある。また、第１または第２の中継装置として動作することを要求するための情報もＨｅｌｌｏフレームに含まれていてもよい。このように変形すると、Ｈｅｌｌｏフレーム以外の制御フレームを用いずに中継装置の設定ができるので、ネットワークに負荷をかけずに中継装置の設定を行うことができる。

以下、通知フレームとしてＨｅｌｌｏフレームが用いられる場合を例として説明する。以下の説明では、隣接するクラスタに含まれているノード装置と直接通信することが可能なノード装置のことを「境界ノード」と記載することがある。また、クラスタ間の通信を行うノード装置のことを「サブゲートウェイ」と記載する。さらに、同じクラスタ中のノード装置からサブゲートウェイを選択するノード装置のことを「リーダーノード」と記載する。隣接するクラスタの区別を容易にするために、隣接するクラスタの組合せのうちで、リーダーノードが属するクラスタのことを「マスタ側クラスタ」、リーダーノードが含まれない方のクラスタのことを「スレーブ側クラスタ」と記載する。従って、サブゲートウェイに設定されたノード装置は、図２で説明した中継装置の例であり、リーダーノードに選択されたノード装置は、図２を参照しながら説明した選択装置の例である。リーダーノードは、マスタ側クラスタ中の境界ノードの中からサブゲートウェイを選択する。マスタ側クラスタで選択されたサブゲートウェイは、スレーブ側クラスタのサブゲートウェイを選択することになる。

図３にＨｅｌｌｏフレームのフォーマットの例を示す。Ｈｅｌｌｏフレームは、フレームタイプ、アドレス情報、経路情報、クラスタ情報（Cluster Information、ＣＩ）、マスタ側クラスタ情報（Master Cluster Information、ＭＣＩ）、隣接クラスタ数（Cluster Count、ＣＣＮＴ）を含む。アドレス情報は、グローバル宛先（Global Destination、ＧＤ）、グローバル送信元（Global Source、ＧＳ）、ローカル宛先（Local Destination、ＬＤ）、ローカル送信元（Local Source、ＬＳ）を含む。なお、Ｈｅｌｌｏフレーム中のマスタ側クラスタ情報フィールドは、マスタ側クラスタに含まれている境界ノードで生成されるＨｅｌｌｏフレームで使用される。

フレームタイプは、フレームの種類を一意に表す情報である。例えば、Ｈｅｌｌｏフレームではフレームタイプ＝０に設定され、データフレームではフレームタイプ＝１に設定される。「グローバル宛先」は、フレームの最終的な宛先を指す。一方、フレームを生成したノード装置を「グローバル送信元」と記載する。「ローカル宛先」は、フレームを最終的な宛先に送信するために行われる１ホップの転送の際に、宛先として指定されるノード装置のことを指す。「ローカル送信元」は、フレームが１ホップ転送される場合の転送元のノード装置である。Ｈｅｌｌｏフレームは送信元のノード装置から１ホップのノード装置にブロードキャストされる。このため、Ｈｅｌｌｏフレームの場合、ローカル送信元とグローバル送信元はいずれも、Ｈｅｌｌｏフレームを生成したノード装置である。また、Ｈｅｌｌｏフレームのローカル宛先とグローバル宛先は、いずれも、全ての隣接ノード装置へのブロードキャストを表すアドレスである。

経路情報は、Ｈｅｌｌｏフレームを生成したノード装置がフレームを送信する経路を保持しているノード装置を識別する情報を含む。クラスタ情報は、Ｈｅｌｌｏフレームを生成したノード装置が参加しているクラスタに関する情報である。クラスタ情報には、クラスタＩＤやクラスタ内に含まれているノード装置の識別子が含まれる。さらに、クラスタ内でサブゲートウェイに設定されているノード装置については、クラスタ情報は、ノード装置に割り当てられた識別子に対応付けて、サブゲートウェイに設定されていることを表す情報も含む。以下、クラスタの識別子は、アルファベットのＣの後に、クラスタを一意に特定するために使用する数値を付したものとする。一方、ノード装置の識別子は、アルファベットのＮの後に、ノード装置を一意に特定するために使用する数値を付したものとする。なお、クラスタ情報は、実装に応じて他の情報をさらに含んでもよい。例えば、クラスタが動的に形成されるシステムでは、クラスタに含まれているノード装置の数が上限に達しているかを示す情報がクラスタ情報に含まれることがある。

マスタ側クラスタ情報フィールドは、マスタ側クラスタの境界ノードが保持している情報を通知するために使用される。マスタ側クラスタ情報フィールドを用いて通知される情報については後述する。

隣接クラスタ数は、Ｈｅｌｌｏフレームを生成したノード装置が通信可能なノード装置が含まれるクラスタのうち、Ｈｅｌｌｏフレームを生成したノード装置が参加しているクラスタ以外のクラスタの数である。例えば、クラスタＣ１中のノードＮ１の隣接ノード装置がノードＮ２〜Ｎ６であり、ノードＮ２〜Ｎ４はクラスタＣ１、ノードＮ５はクラスタＣ２、ノードＮ６はクラスタＣ３に含まれているとする。この場合、ノードＮ１の隣接クラスタ数は２となる。

＜装置構成＞
図４は、ノード装置１０の構成の例を示す。図４は、Ｈｅｌｌｏフレームによって中継装置の設定を行う場合に用いられるノード装置１０の例である。

ノード装置１０は、受信部１１、送信部１２、フレーム処理部１３、Ｈｅｌｌｏフレーム生成部１４、データフレーム処理部１５、クラスタ処理部２０、ルーティング処理部２５、サブゲートウェイ設定部３０、記憶部５０を備える。クラスタ処理部２０は、クラスタ管理部２１と抽出処理部２２を有する。ルーティング処理部２５は、経路情報処理部２６と転送処理部２７を有する。サブゲートウェイ設定部３０は、処理種別判定部３１、スレーブ側テーブル更新部３２、マスタ側テーブル更新部３３、決定処理部４０を備える。決定処理部４０は、リーダーノード特定部４１、サブゲートウェイ選択部４２、中継先決定部４３を有する。記憶部５０は、ノード種別情報５１、ルーティングテーブル５２、マスタ側クラスタテーブル５３、スレーブ側クラスタテーブル５４、クラスタ情報テーブル５５、データ５６を保持する。

受信部１１は、ノード装置１０に送信されてきたフレームを受信する。受信部１１は、受信したフレームをフレーム処理部１３に出力する。フレーム処理部１３は、入力されたフレームに含まれているフレームタイプを確認する。フレームタイプの値は、フレームの種類によって異なり、例えば、Ｈｅｌｌｏフレームとデータフレームでは、異なる値となっている。フレーム処理部１３は、予め、ノード装置１０が受信する可能性があるフレームの種類の各々に対応するフレームタイプの値を記憶することができ、また、適宜、記憶部５０から取得することもできる。フレーム処理部１３は、Ｈｅｌｌｏフレームを抽出処理部２２と経路情報処理部２６に出力し、データフレームをデータフレーム処理部１５に出力する。送信部１２は、Ｈｅｌｌｏフレーム生成部１４、データフレーム処理部１５または転送処理部２７から入力されたフレームを、フレームのローカル宛先に送信する。Ｈｅｌｌｏフレーム生成部１４は、周期的にＨｅｌｌｏフレームを生成する。Ｈｅｌｌｏフレーム生成部１４は、Ｈｅｌｌｏフレームを送信部１２に出力する。データフレーム処理部１５は、自ノード宛のフレームを、アプリケーションにより処理する。一方、フレーム処理部１３から入力されたフレームのグローバル宛先が他のノード装置１０である場合、データフレーム処理部１５は、転送処理部２７にフレームを出力する。

クラスタ処理部２０は、クラスタの生成や維持に関する処理を行う。ここで、クラスタは静的に決定されても、動的に生成されても良いものとする。クラスタ管理部２１は、クラスタごとに含まれるノード装置１０の情報を処理する。クラスタ管理部２１は、クラスタに含まれるノード装置１０が静的に決定される場合、クラスタ情報テーブル５５に基づいて、自ノードが参加しているクラスタを特定する。クラスタ情報テーブル５５は、クラスタの識別子に対応付けてそのクラスタに含まれているノード装置１０の識別子を記録する。一方、アドホックネットワークに含まれているノード装置１０の数やノード装置１０の位置などに応じて、クラスタが動的に決定される場合、クラスタ管理部２１は、クラスタの生成処理を行う。この場合、クラスタ管理部２１は、クラスタの生成や統合なども行う。さらに、クラスタ管理部２１は、クラスタ情報テーブル５５を更新する。

抽出処理部２２は、隣接するノード装置１０から受信したＨｅｌｌｏフレームから、クラスタ情報、マスタ側クラスタ情報、隣接クラスタ数を抽出する。抽出処理部２２は、Ｈｅｌｌｏフレームに含まれているクラスタ情報を、クラスタ管理部２１に出力する。さらに、抽出処理部２２は、クラスタ情報、マスタ側クラスタ情報、および、隣接クラスタ数を処理種別判定部３１に出力する。

ルーティング処理部２５は、フレームのルーティングに関する処理を行う。経路情報処理部２６は、隣接するノード装置１０から受信したＨｅｌｌｏフレームから、経路情報を取得し、ルーティングテーブル５２を生成する。転送処理部２７は、フレームのグローバル宛先に応じて、ルーティングテーブル５２を用いて、転送先を決定する。

サブゲートウェイ設定部３０は、サブゲートウェイの決定に関する処理を行う。処理種別判定部３１は、自ノードが境界ノードであるかを判定する。自ノードが境界ノードである場合、処理種別判定部３１は、さらに、自ノードがマスタ側クラスタに含まれているかを判定する。処理種別判定部３１は、判定の結果に応じて、抽出処理部２２から入力された情報の出力先を決定する。処理種別判定部３１は、自ノードが参加しているクラスタのクラスタＩＤと、抽出処理部２２から入力されたクラスタ情報に含まれているクラスタＩＤを比較することにより判定を行う。自ノードが参加しているクラスタＩＤ以外のクラスタＩＤを含むＨｅｌｌｏフレームが受信されていない場合、処理種別判定部３１には、自ノードが参加しているクラスタの以外のクラスタのクラスタＩＤは入力されない。この場合、処理種別判定部３１は、自ノードは境界ノードではないと判定する。そこで、処理種別判定部３１は、抽出処理部２２から入力された情報を廃棄する。

一方、処理種別判定部３１に、自ノードが参加しているクラスタのクラスタＩＤよりも大きな数字を含むクラスタＩＤが入力されたとする。すると、処理種別判定部３１は、自ノードが参加しているクラスタは入力されたクラスタＩＤで識別されるクラスタに対するマスタ側のクラスタであると判定する。このため、処理種別判定部３１は、自ノードはマスタ側クラスタの境界ノードとして動作すると判定する。そこで、処理種別判定部３１は、マスタ側クラスタ情報と隣接クラスタ数を、リーダーノード特定部４１に出力する。

自ノードが参加しているクラスタのクラスタＩＤよりも小さな数字を含むクラスタＩＤが入力された場合、処理種別判定部３１は自ノードが参加しているクラスタは入力されたクラスタＩＤで識別されるクラスタに対するスレーブ側のクラスタであると判定する。このため、処理種別判定部３１は、自ノードはスレーブ側クラスタの境界ノードとして動作すると判定する。そこで、処理種別判定部３１は、マスタ側クラスタ情報と隣接クラスタ数を、スレーブ側テーブル更新部３２に出力する。

スレーブ側テーブル更新部３２は、スレーブ側クラスタの境界ノードであると判定された場合に、処理種別判定部３１から入力された情報を用いてスレーブ側クラスタテーブル５４を更新する。スレーブ側クラスタテーブル５４の例を図５に示す。スレーブ側クラスタテーブル５４は、マスタ側クラスタごとに、マスタ側クラスタで設定されたサブゲートウェイのノード識別子を対応付けて記録している。図５の例では、マスタ側クラスタとなる隣接クラスタが複数（ｍ個）の場合を示している。また、図５の例では、マスタ側クラスタとの間の通信を中継するサブゲートウェイも複数である。例えば、クラスタＣ１との通信を中継するサブゲートウェイの数はｋ１個、クラスタＣ２との通信ではｋ２個、クラスタＣｍとの間ではｋｍ個である。

マスタ側テーブル更新部３３、リーダーノード特定部４１、サブゲートウェイ選択部４２、中継先決定部４３は、マスタ側クラスタの境界ノードであると判定されたノード装置１０で動作する。マスタ側テーブル更新部３３は、マスタ側クラスタ情報を用いてマスタ側クラスタテーブル５３を更新する。Ｈｅｌｌｏフレームに含まれているマスタ側クラスタ情報の例を図６（ａ）に示す。マスタ側クラスタ情報は、スレーブ側のクラスタに割り当てられたクラスタＩＤに、サブゲートウェイの設定に用いられる情報とリーダーノードの情報を対応付けたものである。サブゲートウェイの設定に用いられる情報には、スレーブ側クラスタのサブゲートウェイの識別子（ＳＩＤ）、マスタ側クラスタのサブゲートウェイの識別子（ＭＧＷ）、マスタ側クラスタのサブゲートウェイの隣接クラスタ数（ＳＧWＣＮＴ）が含まれる。マスタ側サブゲートウェイに関するシーケンス番号（ＳＧＷＳＮ）もマスタ側クラスタ情報に含まれる。マスタ側サブゲートウェイに関するシーケンス番号は、マスタ側のサブゲートウェイのＨｅｌｌｏフレーム毎に異なる値となっており、マスタ側サブゲートウェイに関する情報の新しさの指標として用いられる。

マスタ側クラスタのリーダーノードの情報、マスタ側クラスタ内のサブゲートウェイ候補の情報も、マスタ側クラスタ情報に含まれる。マスタ側クラスタのリーダーノードの情報は、リーダーノードの識別子（ＬＩＤ）と、リーダーノードに関するシーケンス番号（ＬＩＤＳＮ）が含まれる。リーダーノードに関するシーケンス番号は、リーダーノードが生成したＨｅｌｌｏフレーム毎にインクリメントされる値である。リーダーノードに関するシーケンス番号は、リーダーノードに関する情報の新しさの指標として用いられる。マスタ側クラスタ内のサブゲートウェイ候補（ＣＳＩＤ）は、マスタ側クラスタの現在のサブゲートウェイよりもサブゲートウェイとしての条件が良好であると判定されたノード装置１０の情報が含まれている。サブゲートウェイ候補の隣接クラスタ数（ＣＳＣＮＴ）は、サブゲートウェイ候補のノードＩＤに対応付けられている。

マスタ側クラスタテーブル５３は、スレーブ側の隣接クラスタごとに、マスタ側クラスタ情報を記録しているテーブルである。マスタ側クラスタテーブル５３の例を図６（ｂ）に示す。図６（ｂ）の例では、隣接するスレーブ側のクラスタの数はｎ個である。なお、ｎは任意の自然数を取りうる。

リーダーノード特定部４１は、マスタ側クラスタ情報に含まれているリーダーノードと自ノードのいずれかをリーダーノードとして特定する。自ノードがリーダーノードである場合、マスタ側クラスタ情報をサブゲートウェイ選択部４２に出力して、サブゲートウェイの選択を要求する。一方、自ノードがリーダーノードではない場合、マスタ側クラスタ情報をマスタ側テーブル更新部３３に出力する。リーダーノード特定部４１は、特定した結果をマスタ側クラスタテーブル５３のリーダーノードの欄に記録する。リーダーノードの選択基準は、予め、各ノード装置１０に設定されているものとする。リーダーノードの選択基準は、各ノード装置１０で同一の基準であれば、実装に応じて任意に設定できる。後で、ノードＩＤに含まれている数値が小さいほどリーダーノードに選択されやすい場合を例として、リーダーノードの選択方法を説明する。

サブゲートウェイ選択部４２は、リーダーノードに選択されたノード装置１０で動作する。サブゲートウェイ選択部４２は、マスタ側クラスタ中でサブゲートウェイとして動作するノード装置１０を決定する。マスタ側クラスタ中のサブゲートウェイの選択基準は、予め、各ノード装置１０のサブゲートウェイ選択部４２に設定されているものとする。マスタ側クラスタ中のサブゲートウェイの選択基準も、各ノード装置１０で同一の基準であれば、実装に応じて任意に設定できる。後で、隣接クラスタ数が大きいほどサブゲートウェイに選択されやすい場合を例として、サブゲートウェイの選択方法を説明する。リーダーノードのサブゲートウェイ選択部４２は、サブゲートウェイに選択したノード装置１０の識別子と隣接クラスタ数を、マスタ側クラスタテーブル５３に記録する。マスタ側クラスタ情報にサブゲートウェイ候補情報が含まれている場合、サブゲートウェイ選択部４２は、前に決定したサブゲートウェイと通知されたサブゲートウェイ候補を比較し、一方をサブゲートウェイに選択する。

中継先決定部４３は、マスタ側クラスタのサブゲートウェイに決定されたノード装置１０において動作する。中継先決定部４３は、スレーブ側クラスタに含まれている隣接ノード装置から、クラスタ間の通信に用いられるフレームの中継先とするノード装置１０を選択する。ここで選択されたノード装置１０は、スレーブ側クラスタ中でのサブゲートウェイとなる。中継先決定部４３は、決定した中継先の情報をマスタ側クラスタテーブル５３に記録する。

ノード種別情報５１は、自ノードがサブゲートウェイに設定されているかを示す情報を保持する。データ５６は、フレーム処理部１３、Ｈｅｌｌｏフレーム生成部１４、データフレーム処理部１５、クラスタ処理部２０、ルーティング処理部２５、サブゲートウェイ設定部３０の処理に用いられるデータである。データ５６は、オペレータ等により設定されたデータの他、フレーム処理部１３、Ｈｅｌｌｏフレーム生成部１４、データフレーム処理部１５、クラスタ処理部２０、ルーティング処理部２５、サブゲートウェイ設定部３０の処理により得られたデータも含む。

図７は、ノード装置１０のハードウェア構成の例を示す図である。ノード装置１０は、プロセッサ１００、バス１０１（１０１ａ〜１０１ｃ）、タイマＩＣ１０４、Dynamic Random access Memory（ＤＲＡＭ）１０６、フラッシュメモリ１０７、無線モジュール１０８を備える。ノード装置１０は、オプションとして、有線通信に用いられるPHYsical layer（ＰＨＹ）チップ１０２を含むことができる。バス１０１ａ〜１０１ｃは、プロセッサ１００、ＰＨＹチップ１０２、タイマＩＣ１０４、ＤＲＡＭ１０６、フラッシュメモリ１０７、および、無線モジュール１０８を、データの入出力が可能になるように接続する。

プロセッサ１００は、MicroProcessingUnit（ＭＰＵ）などを含む任意の処理回路である。プロセッサ１００は、フラッシュメモリ１０７に格納されたファームウェアなどのプログラムを読み込んで処理を行う。このとき、プロセッサ１００は、ＤＲＡＭ１０６をワーキングメモリとして使用できる。ノード装置１０において、プロセッサ１００は、フレーム処理部１３、Ｈｅｌｌｏフレーム生成部１４、データフレーム処理部１５、クラスタ処理部２０、ルーティング処理部２５、サブゲートウェイ設定部３０として動作する。ノード装置１０において、ＤＲＡＭ１０６は、記憶部５０として動作する。受信部１１と送信部１２は、無線モジュール１０８により実現される。

タイマＩＣ１０４は、Ｈｅｌｌｏフレームを送信する間隔の計測や、隣接するノード装置１０からＨｅｌｌｏフレームを受信する間隔を計測するときに用いられる。つまり、タイマＩＣ１０４は、Ｈｅｌｌｏフレーム生成部１４や経路情報処理部２６などの一部として動作する。

なお、ファームウェアなどのプログラムは、コンピュータ読み取り可能な記憶媒体に格納されて提供され、ノード装置１０にインストールされてもよい。または、プログラムは、ネットワークからＰＨＹチップ１０２や無線モジュール１０８を介してダウンロードされることによりノード装置１０にインストールされてもよい。また、実施形態に応じて、ＤＲＡＭ１０６やフラッシュメモリ１０７以外の他の種類の記憶装置が利用されることがある。また、ノード装置１０は、コンピュータによって実現されても良い。

＜第１の実施形態＞
以下、サブゲートウェイの設定方法の例を、サブゲートウェイが新規に設定される場合と、ノード装置１０の増減によってサブゲートウェイが変更される場合に分けて説明する。

〔サブゲートウェイの設定〕
図８は、サブゲートウェイの設定方法の例を説明する図である。図８の例では、クラスタＣ１とクラスタＣ７が隣接している。クラスタＣ１にはノードＮ１〜Ｎ５が含まれており、クラスタＣ７には、ノードＮ６〜Ｎ８が含まれている。隣接ノードとの間でＨｅｌｌｏフレームを送受信することにより、隣接するクラスタに含まれているノード装置からのＨｅｌｌｏフレームを受信することができるノード装置は、境界ノードであると認識する。図８（ａ）の例では、ノードＮ３〜Ｎ６、Ｎ８が境界ノードとなり得る。図８では、境界ノードとなり得るノードを破線で囲んでいる。境界ノードは、隣接するノード装置が属するクラスタのクラスタＩＤと、自ノードが参加しているクラスタのクラスタＩＤを比較することにより、マスタ側クラスタを決定する。図８（ａ）のケースでは、クラスタＣ１がマスタ側クラスタとなり、クラスタＣ７がスレーブ側クラスタとなる。従って、ノードＮ３〜Ｎ５は、マスタ側クラスタの境界ノードとして動作し、ノードＮ６とＮ８はスレーブ側クラスタの境界ノードとして動作する。

リーダーノードは、マスタ側クラスタの境界ノードの中から選択される。ノードＩＤに含まれている数値が小さいほどリーダーノードになりやすい場合、図８（ｂ）に示すように、ノードＮ３がリーダーノードに設定される。リーダーノードは、マスタ側クラスタ中のサブゲートウェイを選択する。マスタ側クラスタ中の境界ノードは、リーダーノードに選択されなかった場合は、サブゲートウェイを選択することはできず、リーダーノードの選択に従う。図８（ｃ）の例では、リーダーノードであるノードＮ３は、ノードＮ３をサブゲートウェイに選択している。このため、図８（ｃ）の例では、ノードＮ３がリーダーノードとサブゲートウェイを兼ねている。マスタ側クラスタのサブゲートウェイは、スレーブ側クラスタに参加している隣接ノードから、スレーブ側クラスタ中のサブゲートウェイを決定する。図８（ｄ）の例では、ノードＮ３はノードＮ６をスレーブ側サブゲートウェイに決定している。

ここで、Ｈｅｌｌｏフレームの送信を行った順序によっては、リーダーノードがサブゲートウェイを決定した後で、既にサブゲートウェイとして動作しているノード装置１０よりもサブゲートウェイとしての条件が良好なノード装置１０が発生する場合がある。そこで、マスタ側クラスタ中の境界ノードは、現在サブゲートウェイに設定されているノード装置１０よりもサブゲートウェイとしての条件が良いノード装置１０があるかを、マスタ側クラスタ情報を用いて判定する。リーダーノードは、サブゲートウェイとしての条件がより良いノード装置１０を発見すると、サブゲートウェイを変更する。リーダーノード以外の境界ノードは、現在サブゲートウェイに設定されているノード装置１０よりもサブゲートウェイとしての条件が良好なノード装置１０を発見すると、発見したノード装置１０の情報をサブゲートウェイ候補としてリーダーノードに通知する。リーダーノードは、マスタ側クラスタ内の他の境界ノードから通知されたサブゲートウェイ候補の条件を、サブゲートウェイに設定されているノード装置１０の条件と比較する。サブゲートウェイ候補の条件のほうが良ければ、リーダーノードは、マスタ側クラスタのサブゲートウェイを変更する。スレーブ側クラスタについては、マスタ側クラスタのサブゲートウェイが変更することができる。例えば、マスタ側クラスタのサブゲートウェイは、スレーブ側サブゲートウェイより良い条件のノード装置１０を発見すると、サブゲートウェイを変更する。

図９Ａ、図９Ｂは、第１の実施形態で行われる処理の例を説明するシーケンス図である。以下、図９Ａ、図９Ｂを用いて、サブゲートウェイが変更される過程を含めて、サブゲートウェイの決定方法の具体例を説明する。なお、図９Ａ、図９Ｂでも、図８（ａ）に示すアドホックネットワークでの例を説明する。なお、手順（１）の段階では、いずれのノード装置１０も、境界ノードであるかを知らないものとする。また、図９Ａ、図９Ｂの説明の際に、マスタ側クラスタテーブル５３やスレーブ側クラスタテーブル５４の例を示している他の図を参照することがある。そこで、図１０（ａ）〜図１４では、テーブルの参照番号の後に、アンダースコアを挟んで、テーブルが更新された手順の番号を記載する。例えば、手順（２）によって得られるマスタ側クラスタテーブル５３は「５３＿２」という番号を付している。また、図の参照を容易にするために、図９Ａと図９Ｂにおいても、更新後のテーブルの番号を示す。

（１）ノードＮ６のＨｅｌｌｏフレーム生成部１４は、Ｈｅｌｌｏフレームを生成する時刻になると、Ｈｅｌｌｏフレームを生成する。Ｈｅｌｌｏフレーム生成部１４は、クラスタ管理部２１からクラスタＩＤ（Ｃ７）を取得して、以下のような情報要素を含むＨｅｌｌｏフレームを生成する。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ６
ＬＳ ：ノードＮ６
クラスタ情報中のクラスタＩＤ：Ｃ７
マスタ側クラスタ情報 ：なし
隣接クラスタ数 ：０

Ｈｅｌｌｏフレーム生成部１４は、生成したＨｅｌｌｏフレームを送信部１２に出力する。ノードＮ６の送信部１２は、隣接するノード装置１０にＨｅｌｌｏフレームを送信する。

（２）ノードＮ３はノードＮ６から送信されたＨｅｌｌｏフレームを受信する。以下、図８を参照しながら、ノードＮ３がＮ６からＨｅｌｌｏフレームを受信したときに行われる処理を手順（２ａ）〜（２ｄ）に分けて詳しく説明する。

（２ａ）ノードＮ３のフレーム処理部１３は、受信部１１を介してノードＮ６から受信したＨｅｌｌｏフレームを、抽出処理部２２に出力する。抽出処理部２２は、ノードＮ６から受信したＨｅｌｌｏフレームに含まれているクラスタ情報と隣接クラスタ数を処理種別判定部３１に出力する。ノードＮ３の処理種別判定部３１は、ノードＮ３が参加しているクラスタのクラスタＩＤがＣ１であることを記憶している。処理種別判定部３１は、ノードＮ３が参加しているクラスタのクラスタＩＤがＣ１であることと、受信したＨｅｌｌｏフレームに含まれているクラスタＩＤがＣ７であることから、ノードＮ３が境界ノードであると判定する。さらに、処理種別判定部３１は、Ｃ１とＣ７では、Ｃ１の方がクラスタＩＤ中の数字が小さいことから、図８（ａ）に示すように、クラスタＣ１を、クラスタＣ７との組み合わせではマスタ側クラスタとする。

（２ｂ）処理種別判定部３１は、抽出処理部２２から入力された情報を、リーダーノード特定部４１に出力する。ノードＮ３にはいずれのノード装置１０からもマスタ側クラスタ情報を含むＨｅｌｌｏフレームが送信されてきていないので、ノードＮ３のリーダーノード特定部４１が境界ノードであることを認識しているノードは、ノードＮ３だけである。そこで、リーダーノード特定部４１は、図８（ｂ）に示すように、ノードＮ３をリーダーノードに設定する。さらに、リーダーノード特定部４１は、マスタ側クラスタテーブル５３に以下の情報を記録する。
隣接クラスタＩＤ ：Ｃ７
リーダーノードのノードＩＤ ：Ｎ３
リーダーノードのシーケンス番号：０

（２ｃ）ノードＮ３のリーダーノード特定部４１は、サブゲートウェイ選択部４２にサブゲートウェイの選択を要求する。サブゲートウェイ選択部４２は、クラスタＣ１中のクラスタＣ７との境界ノードの中から、隣接クラスタ数が最も多いノード装置１０を、サブゲートウェイに選択する。ここでは、ノードＮ３は、クラスタＣ１とＣ７の間の境界ノードとしては、ノードＮ３以外を認識していない。このため、ノードＮ３のサブゲートウェイ選択部４２は、図８（ｃ）に示すように、ノードＮ３をサブゲートウェイに選択する。そこで、サブゲートウェイ選択部４２は、マスタ側クラスタテーブル５３の隣接クラスタＩＤ＝Ｃ７のエントリに、以下の情報を記録する。
サブゲートウェイのノードＩＤ ：Ｎ３
サブゲートウェイのシーケンス番号 ：０
サブゲートウェイの隣接クラスタ数 ：１
サブゲートウェイ候補 ：なし
サブゲートウェイ候補の隣接クラスタ数：０

（２ｄ）ノードＮ３の中継先決定部４３は、ノードＮ３がマスタ側クラスタのサブゲートウェイに決定されたため、スレーブ側クラスタのサブゲートウェイを決定する。ノードＮ３はノードＮ６からＨｅｌｌｏフレームを受信しているので、中継先決定部４３は、ノードＮ６がスレーブ側クラスタのＣ７に含まれている隣接ノード装置であると判定する。この時点では、他にスレーブ側クラスタのＣ７に含まれている隣接ノード装置を検出していないので、中継先決定部４３は、ノードＮ６をスレーブ側クラスタ中でのサブゲートウェイとして選択する。ノードＮ６をサブゲートウェイに決定すると、図８（ｄ）に示すようにサブゲートウェイが設定されることになる。中継先決定部４３は、決定した中継先の情報をマスタ側クラスタテーブル５３の隣接クラスタＩＤ＝Ｃ７のエントリに記録する。

手順（２ａ）〜（２ｄ）の処理により、ノードＮ３が保持するマスタ側クラスタテーブル５３は、図１０（ａ）に示すようになる。ただし、手順（２ｄ）の段階では、ノードＮ３がノードＮ６に対して、サブゲートウェイとして動作することを要求することが決定されているが、ノードＮ６はまだサブゲートウェイとしては動作していない。

（３）図９Ａの手順（３）では、ノードＮ５がノードＮ６から受信したＨｅｌｌｏフレームを処理する。ノードＮ５で行われる処理は、手順（２）で述べた処理と同様である。ノードＮ５での処理により、ノードＮ５が保持するマスタ側クラスタテーブル５３は、図１０（ｂ）に示すようになる。

（４）ノードＮ８は、ノードＮ６からＨｅｌｌｏフレームを受信する。受信部１１、フレーム処理部１３、抽出処理部２２の処理は手順（２ａ）でノードＮ３の場合を例として説明したとおりである。処理種別判定部３１は、ノードＮ８が参加しているクラスタのクラスタＩＤがＣ７であることと、受信したＨｅｌｌｏフレームに含まれているクラスタＩＤもＣ７であることから、ノードＮ８が境界ノードではないと判定する。そこで、ノードＮ８の処理種別判定部３１は、抽出処理部２２から入力された情報を破棄する。一方、同じクラスタ内のノード装置１０からＨｅｌｌｏフレームを受信したことから、経路情報処理部２６は、Ｈｅｌｌｏフレームに含まれている経路情報を取得し、ルーティングテーブル５２を更新する。ノードＮ７もノードＮ６からのＨｅｌｌｏフレームを受信すると、ノードＮ８と同様に処理する。

（５）ノードＮ３のＨｅｌｌｏフレーム生成部１４は、Ｈｅｌｌｏフレームを生成する時刻になると、Ｈｅｌｌｏフレームを生成する。Ｈｅｌｌｏフレーム生成部１４は、クラスタ管理部２１からクラスタＩＤ（Ｃ１）を取得する。さらに、図１０（ａ）に示すマスタ側クラスタテーブル５３から生成したマスタ側クラスタ情報をＨｅｌｌｏフレームに含める。マスタ側クラスタ情報に含まれる要素が図６（ａ）に示す通りである場合、生成されたＨｅｌｌｏフレームには、以下の情報要素が含まれる。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ３
ＬＳ ：ノードＮ３
クラスタ情報中のクラスタＩＤ ：Ｃ１
クラスタ情報中のサブゲートウェイ：ノードＮ３
隣接クラスタ数 ：１
マスタ側クラスタ情報
隣接クラスタＩＤ ：Ｃ７
スレーブ側サブゲートウェイのノードＩＤ：Ｎ６
リーダーノードのノードＩＤ ：Ｎ３
リーダーノードのシーケンス番号 ：１
サブゲートウェイのノードＩＤ ：Ｎ３
サブゲートウェイのシーケンス番号 ：１
サブゲートウェイの隣接クラスタ数 ：１
サブゲートウェイ候補 ：なし
サブゲートウェイ候補の隣接クラスタ数 ：０

Ｈｅｌｌｏフレーム生成部１４は、生成したＨｅｌｌｏフレームを送信部１２に出力する。ノードＮ３の送信部１２は、隣接するノード装置１０にＨｅｌｌｏフレームを送信する。

（６）ノードＮ４は、ノードＮ３からＨｅｌｌｏフレームを受信する。この時点では、ノードＮ４はクラスタＣ７に含まれているノード装置１０からＨｅｌｌｏフレームを受信していなので、ノードＮ４は、ノードＮ４が境界ノードであると認識していない。さらに、ノードＮ４の処理種別判定部３１は、ノードＮ４がクラスタＣ１に参加していることと、受信したＨｅｌｌｏフレームに含まれているクラスタＩＤもＣ１であることから、ノードＮ４が境界ノードではないと判定する。従って、ノードＮ４では、手順（４）のノードＮ７、Ｎ８と同様に、境界ノードとしての処理が行われない。なお、ノードＮ３から受信したＨｅｌｌｏフレームのクラスタ情報には、ノードＮ３がサブゲートウェイであることが記録されている。そこで、ノードＮ４のクラスタ管理部２１は、ノードＮ３がクラスタＣ１中のサブゲートウェイであることを認識する。

（７）ノードＮ２もノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ２の処理種別判定部３１はノードＮ２が境界ノードではないと判定するので、ノードＮ２は、境界ノードとしての処理を行わない。ノードＮ２のクラスタ管理部２１も、ノードＮ４と同様に、Ｈｅｌｌｏフレーム中のクラスタ情報を読み込むことにより、ノードＮ３がクラスタＣ１中のサブゲートウェイであることを認識する。

（８）ノードＮ５はノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ５の処理種別判定部３１は、手順（３）において、ノードＮ５のことをクラスタＣ１とＣ７の間のサブゲートウェイの設定の際にマスタ側クラスタ中の境界ノードとして動作すると判定している。そこで、処理種別判定部３１は、ノードＮ３から受信したＨｅｌｌｏフレームに含まれているマスタ側クラスタ情報を、リーダーノード特定部４１に出力する。

ノードＮ５のリーダーノード特定部４１は、マスタ側クラスタ情報に含まれているリーダーノードのノードＩＤと、ノードＮ５が保持しているマスタ側クラスタテーブル５３のリーダーノードの情報を比較する。Ｈｅｌｌｏフレームで通知されてきたリーダーノードはノードＮ３であり、マスタ側クラスタテーブル５３に記録されているリーダーノードはノードＮ５である。そこで、リーダーノード特定部４１は、ノードＮ５よりもノードＮ３のほうがリーダーノードとしての条件がよいと判定し、リーダーノードの設定を、図１０（ｃ）に示すように変更する。

ノードＮ５がリーダーノードではなくなったので、マスタ側テーブル更新部３３は、ノードＮ３から通知されたマスタ側クラスタ情報に従って、マスタ側クラスタテーブル５３を変更する。このため、図１０（ｃ）に示すように、マスタ側クラスタのサブゲートウェイは、リーダーノードであるノードＮ３の決定に従って、ノードＮ３に変更される。さらに、マスタ側テーブル更新部３３は、スレーブ側クラスタのサブゲートウェイも、リーダーノードの決定に従って更新する。ここでは、ノードＮ３からの通知を受ける前にノードＮ５はノードＮ６をスレーブ側のサブゲートウェイとすることを決定していたので、スレーブ側クラスタのサブゲートウェイの設定は変更されない。

さらに、ノードＮ５のクラスタ管理部２１は、クラスタ情報に基づいて、ノードＮ３がクラスタＣ１中のサブゲートウェイであることを認識する。また、クラスタ管理部２１は、ノードＮ５がサブゲートウェイではなくなったという情報もマスタ側テーブル更新部３３から取得する。

（９）ノードＮ６はノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ６の処理種別判定部３１は、ノードＮ６がクラスタＣ７に参加していて、受信したＨｅｌｌｏフレームに含まれているクラスタＩＤがＣ１であることから、ノードＮ６がスレーブ側クラスタ中の境界ノードであると判定する。そこで、スレーブ側テーブル更新部３２は、マスタ側クラスタ情報を用いて、クラスタＣ１がマスタ側クラスタであるエントリを、スレーブ側クラスタテーブル５４に生成する。スレーブ側テーブル更新部３２は、マスタ側クラスタ情報に含まれているサブゲートウェイのノードＩＤが自ノードのノードＩＤと一致するので、サブゲートウェイとして動作することを要求されていると判定する。スレーブ側テーブル更新部３２の処理により、図１１（ａ）に示すスレーブ側クラスタテーブル５４が生成される。ノードＮ６は、クラスタＣ７のサブゲートウェイとしての動作を開始する。

（１０）ノードＮ８もノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ８で行われる処理は、ノードＮ６の処理として手順（９）で説明した処理と同様である。ただし、ノードＮ８のスレーブ側テーブル更新部３２は、マスタ側クラスタ情報に含まれているサブゲートウェイのノードＩＤがＮ６であるので、ノードＮ８はサブゲートウェイとして動作することを要求されていないと判定する。そこで、ノードＮ８中のスレーブ側クラスタテーブル５４は、図１１（ｂ）に示すようになる。

（１１）ノードＮ８のＨｅｌｌｏフレーム生成部１４は、Ｈｅｌｌｏフレームを生成する時刻になると、Ｈｅｌｌｏフレームを生成する。ノードＮ８はスレーブ側クラスタ内の境界ノードであるので、以下の情報要素を含むＨｅｌｌｏフレームが生成される。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ８
ＬＳ ：ノードＮ８
クラスタ情報中のクラスタＩＤ：Ｃ７
マスタ側クラスタ情報 ：なし
隣接クラスタ数 ：１
生成されたＨｅｌｌｏフレームは、ノードＮ８の隣接ノードに送信される。

（１２）ノードＮ６はノードＮ８からＨｅｌｌｏフレームを受信する。ノードＮ６はスレーブ側クラスタ内の境界ノードであるが、同じクラスタ内のノード装置１０からＨｅｌｌｏフレームを受信したため、手順（４）と同様の処理を行う。

（１３）ノードＮ５は、ノードＮ８からＨｅｌｌｏフレームを受信する。ノードＮ５はマスタ側クラスタ内の境界ノードであるので、マスタ側テーブル更新部３３は、隣接クラスタ数を、マスタ側クラスタテーブル５３のスレーブ側のサブゲートウェイ候補の隣接クラスタ数と比較する。この時点では、図１０（ｃ）に示すように、スレーブ側クラスタのサブゲートウェイはノードＮ６であり、ノードＮ６の隣接クラスタ数は０となっている。そこで、ノードＮ５は、ノードＮ８の方がノードＮ６よりもサブゲートウェイとしての条件が良好であると判定し、マスタ側クラスタテーブル５３を図１１（ｃ）に示すように変更する。

（１４）ノードＮ４も、ノードＮ８からＨｅｌｌｏフレームを受信する。ノードＮ４はノードＮ８からのＨｅｌｌｏフレームを受信するまでは、クラスタＣ７とクラスタＣ１の境界ノードであると認識していない。そこで、ノードＮ４で行われる処理は、手順（２）で述べた処理と同様である。ノードＮ４での処理により、ノードＮ４が保持するマスタ側クラスタテーブル５３は、図１２（ａ）に示すようになる。

（１５）ノードＮ３もノードＮ８からＨｅｌｌｏフレームを受信する。ノードＮ３はマスタ側クラスタ中のサブゲートウェイであるので、中継先決定部４３は、隣接クラスタ数を、マスタ側クラスタテーブル５３のスレーブ側のサブゲートウェイ候補の隣接クラスタ数と比較する。この時点では、図１０（ａ）に示すように、スレーブ側クラスタのサブゲートウェイはノードＮ６であり、ノードＮ３のマスタ側クラスタテーブル５３では、ノードＮ６の隣接クラスタ数は０となっている。そこで、ノードＮ３は、ノードＮ８の方がノードＮ６よりもサブゲートウェイとしての条件が良好であると判定し、サブゲートウェイをノードＮ６からノードＮ８に変更する。さらに、スレーブ側のサブゲートウェイ候補も、ノードＮ８に変更する。このため、ノードＮ３のマスタ側クラスタテーブル５３は図１２（ｂ）に示すようになる。

（１６）次に、ノードＮ５がＨｅｌｌｏフレームを生成したとする。Ｈｅｌｌｏフレームの生成は、手順（５）で説明した処理と同様に行われる。Ｈｅｌｌｏフレームを生成するときのノードＮ５のマスタ側クラスタテーブル５３は、図１１（ｃ）に示すとおりである。このため、生成されたＨｅｌｌｏフレームには、以下の情報要素が含まれる。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ５
ＬＳ ：ノードＮ５
クラスタ情報中のクラスタＩＤ ：Ｃ１
クラスタ情報中のサブゲートウェイ：ノードＮ３
隣接クラスタ数 ：１
マスタ側クラスタ情報
隣接クラスタＩＤ ：Ｃ７
スレーブ側サブゲートウェイのノードＩＤ：Ｎ６
リーダーノードのノードＩＤ ：Ｎ３
リーダーノードのシーケンス番号 ：１
サブゲートウェイのノードＩＤ ：Ｎ３
サブゲートウェイのシーケンス番号 ：１
サブゲートウェイの隣接クラスタ数 ：１
サブゲートウェイ候補 ：なし
サブゲートウェイ候補の隣接クラスタ数 ：０
なお、手順（１５）においてノードＮ３がスレーブ側クラスタのサブゲートウェイをノードＮ６からノードＮ８に変更することを決定しているが、ノードＮ３はサブゲートウェイの変更を決定した後にＨｅｌｌｏフレームを送信していない。このため、ノードＮ３以外のノード装置１０は、スレーブ側クラスタでサブゲートウェイが変更されることを認識していない。このため、ノードＮ５は、スレーブ側サブゲートウェイのノードＩＤをＮ６に設定したＨｅｌｌｏフレームを生成する。Ｈｅｌｌｏフレームは、ノードＮ５に隣接するノード装置１０に送信される。

（１７）ノードＮ３はノードＮ５からＨｅｌｌｏフレームを受信する。ノードＮ３のサブゲートウェイ選択部４２は、ノードＮ５から受信したＨｅｌｌｏフレームにサブゲートウェイ候補が含まれていないので、マスタ側のサブゲートウェイは変更されないと判定する。このため、マスタ側クラスタテーブル５３は変更されない。

（１８）ノードＮ６のスレーブ側テーブル更新部３２は、ノードＮ５からＨｅｌｌｏフレームを受信すると、スレーブ側クラスタテーブル５４を用いて、Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイかを判定する。この時点でのノードＮ６のスレーブ側クラスタテーブル５４は、図１１（ａ）に示すとおりである。そこで、スレーブ側テーブル更新部３２は、ノードＮ５はマスタ側クラスタのサブゲートウェイではないと判定する。すると、スレーブ側テーブル更新部３２は、処理を終了する。

（１９）ノードＮ８のスレーブ側テーブル更新部３２は、ノードＮ５からＨｅｌｌｏフレームを受信すると、Ｈｅｌｌｏフレームの送信元はマスタ側クラスタのサブゲートウェイではないと判定する。ノードＮ８はサブゲートウェイとして動作していないので処理を終了する。

（２０）次に、ノードＮ４がＨｅｌｌｏフレームを生成したとする。Ｈｅｌｌｏフレームの生成は、手順（５）で説明した処理と同様に行われる。このときノードＮ４は、ノードＮ４をリーダーノードであると認識しており、図１２（ａ）に示すマスタ側クラスタテーブル５３を保持しているので、以下の情報要素を含むＨｅｌｌｏフレームを生成する。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ４
ＬＳ ：ノードＮ４
クラスタ情報中のクラスタＩＤ ：Ｃ１
クラスタ情報中のサブゲートウェイ：ノードＮ４
隣接クラスタ数 ：１
マスタ側クラスタ情報
隣接クラスタＩＤ ：Ｃ７
スレーブ側サブゲートウェイのノードＩＤ：Ｎ８
リーダーノードのノードＩＤ ：Ｎ４
リーダーノードのシーケンス番号 ：１
サブゲートウェイのノードＩＤ ：Ｎ４
サブゲートウェイのシーケンス番号 ：１
サブゲートウェイの隣接クラスタ数 ：１
サブゲートウェイ候補 ：なし
サブゲートウェイ候補の隣接クラスタ数 ：０
Ｈｅｌｌｏフレームは、ノードＮ４に隣接するノード装置１０に送信される。

（２１）ノードＮ３はノードＮ４からＨｅｌｌｏフレームを受信する。ノードＮ３での処理は手順（１７）と同様であり、マスタ側クラスタテーブル５３は変更されない。

（２２）ノードＮ８はノードＮ４からＨｅｌｌｏフレームを受信する。ノードＮ８では手順（９）と同様に処理が行われる。このため、ノードＮ８は、図１２（ｃ）に示すスレーブ側クラスタテーブル５４を生成する。このため、手順（２２）の時点では、マスタ側クラスタ（Ｃ１）では、ノードＮ３とノードＮ４の２つがマスタ側サブゲートウェイとなっており、スレーブ側クラスタ（Ｃ７）では、ノードＮ６とノードＮ８の２つがスレーブ側サブゲートウェイとなる。

（２３）次に、ノードＮ６が再度、Ｈｅｌｌｏフレームを生成する。このとき生成されるＨｅｌｌｏフレームには、以下の情報が含まれる。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ６
ＬＳ ：ノードＮ６
クラスタ情報中のクラスタＩＤ ：Ｃ７
クラスタ情報中のサブゲートウェイ：ノードＮ６
マスタ側クラスタ情報 ：なし
隣接クラスタ数 ：１
Ｈｅｌｌｏフレームは、ノードＮ６に隣接するノード装置１０に送信される。

（２４）ノードＮ３は、ノードＮ６からＨｅｌｌｏフレームを受信すると、手順（１５）と同様に処理する。この時点では、図１２（ｂ）に示すように、スレーブ側クラスタのサブゲートウェイはノードＮ８であり、ノードＮ８の隣接クラスタ数は１となっている。一方、Ｈｅｌｌｏフレームにより、ノードＮ６も隣接クラスタ数が１であることが通知されている。隣接クラスタ数が同じであるので、中継先決定部４３は、ノードＩＤ中の番号が比較的小さいノードであるＮ６をスレーブ側のサブゲートウェイに設定する。さらに、中継先決定部４３は、スレーブ側のサブゲートウェイ候補もノードＮ６に変更するので、ノードＮ３のマスタ側クラスタテーブル５３は図１３（ａ）に示すようになる。

（２５）ノードＮ５は、ノードＮ６からＨｅｌｌｏフレームを受信する。ノードＮ５はマスタ側クラスタ内の境界ノードであるので、手順（１３）と同様の処理が行われる。このため、ノードＮ５は、ノードＮ６の方がノードＮ８よりもサブゲートウェイとしての条件が良好であると判定し、マスタ側クラスタテーブル５３を図１３（ｂ）に示すように変更する。

（２６）ノードＮ７、Ｎ８は、ノードＮ６からＨｅｌｌｏフレームを受信すると手順（４）に述べた処理を行う。さらに、ノードＮ７とＮ８のいずれでも、クラスタ管理部２１がクラスタ情報を処理することにより、クラスタＣ７中でノードＮ６がサブゲートウェイとして動作していることを認識する。このため、ノードＮ７は、クラスタＣ７中のサブゲートウェイとしてノードＮ６を認識し、ノードＮ８は、クラスタＣ７中のサブゲートウェイはノードＮ６とＮ８であると認識している。

（２７）ノードＮ３は、再度、Ｈｅｌｌｏフレームを隣接ノードに送信する。このとき送信されるＨｅｌｌｏフレームは、シーケンス番号以外は手順（５）と同じ情報要素を含む。

（２８）ノードＮ４は、ノードＮ３からＨｅｌｌｏフレームを受信すると、手順（８）のノードＮ５と同様の処理を行う。なお、このとき、ノードＮ４のマスタ側テーブル更新部３３は、スレーブ側のサブゲートウェイの情報も更新する。このため、ノードＮ４のマスタ側クラスタテーブル５３は、図１３（ｃ）に示すように更新される。このため、ノードＮ４のクラスタ管理部２１は、クラスタＣ１中のサブゲートウェイはノードＮ３であると認識する。

（２９）ノードＮ５は、ノードＮ３からＨｅｌｌｏフレームを受信すると手順（８）に述べた処理を行う。このとき、ノードＮ５のマスタ側クラスタテーブル５３は、シーケンス番号以外は変更されない。

（３０）ノードＮ６のスレーブ側テーブル更新部３２は、ノードＮ３からＨｅｌｌｏフレームを受信すると、スレーブ側クラスタテーブル５４を用いて、Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイであると判定する。スレーブ側テーブル更新部３２は、スレーブ側クラスタのサブゲートウェイの設定が変更されていないと判定し、処理を終了する。

（３１）ノードＮ８のスレーブ側テーブル更新部３２は、ノードＮ３からＨｅｌｌｏフレームを受信すると、Ｈｅｌｌｏフレームの送信元がスレーブ側クラスタテーブル５４にマスタ側のサブゲートウェイとして登録されているかを判定する。この時点では、ノードＮ８が保持するスレーブ側クラスタテーブル５４は、図１２（ｃ）に示す情報を保持しており、マスタ側サブゲートウェイはノードＮ４になっている。このため、スレーブ側テーブル更新部３２は、ノードＮ３から受信したＨｅｌｌｏフレームに基づいてスレーブ側クラスタテーブル５４を変更しない。

（３２）ノードＮ８は再度、Ｈｅｌｌｏフレームを送信する。このとき生成されるＨｅｌｌｏフレームは、以下の情報を含む。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ８
ＬＳ ：ノードＮ８
クラスタ情報中のクラスタＩＤ ：Ｃ７
クラスタ情報中のサブゲートウェイ：ノードＮ８
マスタ側クラスタ情報 ：なし
隣接クラスタ数 ：１
ノードＮ３〜Ｎ５はいずれもノードＮ８からのＨｅｌｌｏフレームを処理するが、いずれのノード装置１０でもマスタ側クラスタテーブル５３の情報は変化しない。

（３３）ノードＮ５は再度、Ｈｅｌｌｏフレームを送信する。ノードＮ３はノードＮ５からのＨｅｌｌｏフレームを処理するが、マスタ側クラスタテーブル５３の情報は変化しない。ノードＮ６、Ｎ８もノードＮ５からのＨｅｌｌｏフレームを処理するが、スレーブ側クラスタテーブル５４の情報は変化しない。

（３４）ノードＮ４は再度、Ｈｅｌｌｏフレームを送信する。ノードＮ３はノードＮ４からのＨｅｌｌｏフレームを処理するが、マスタ側クラスタテーブル５３の情報は変化しない。

ノードＮ８は、ノードＮ４からのＨｅｌｌｏフレームを受信すると、Ｈｅｌｌｏフレームの送信元がスレーブ側クラスタテーブル５４にマスタ側のサブゲートウェイとして登録されているかを判定する。この時点では、ノードＮ８が保持するスレーブ側クラスタテーブル５４は、図１２（ｃ）に示す情報を保持しており、マスタ側サブゲートウェイはノードＮ４になっている。このため、スレーブ側テーブル更新部３２は、マスタ側クラスタ情報からスレーブ側クラスタのサブゲートウェイのノードＩＤを取得する。取得したノードＩＤはノードＮ６のＩＤであるので、スレーブ側テーブル更新部３２は、スレーブ側クラスタのサブゲートウェイの設定が変更されたと判定し、サブゲートウェイとしての処理を終了する。さらに、スレーブ側テーブル更新部３２は、スレーブ側クラスタテーブル５４を図１４に示すように変更する。このため、ノードＮ８のクラスタ管理部２１は、ノードＮ６がクラスタＣ７中のサブゲートウェイであると認識する。

図８〜図１４を参照しながら説明したようにサブゲートウェイが決定されると、サブゲートウェイとして動作するノード装置１０の識別子は、Ｈｅｌｌｏフレーム中のクラスタ情報に含められる。境界ノードではないノード装置１０は、Ｈｅｌｌｏフレーム中のクラスタ情報を用いて、自ノードと同じクラスタ中でサブゲートウェイとして動作するノード装置１０を特定することができる。例えば、図９（ｂ）の手順（２８）の処理が行われた後、ノードＮ３、Ｎ４、Ｎ５は、いずれも、ノードＮ３がサブゲートウェイとして動作していることをクラスタ情報に含めたＨｅｌｌｏフレームを送信する。このためノードＮ２は、クラスタＣ１ではノードＮ３がサブゲートウェイとして動作していると認識する。さらに、ノードＮ２も、ノードＮ３がサブゲートウェイであるということをクラスタ情報に含めたＨｅｌｌｏフレームをブロードキャストする。すると、ノードＮ１は、ノードＮ２からＨｅｌｌｏフレームを受信することにより、ノードＮ３を介して他のクラスタ中のノード装置１０と通信できると認識する。

その後、例えば、ノードＮ１がノードＮ７にフレームを送信しようとする場合、ノードＮ７はノードＮ１と異なるクラスタに含まれているので、ノードＮ１は、サブゲートウェイに向けてフレームを転送することを決定する。ノードＮ１には、ノードＮ３がサブゲートウェイとして動作することが既に通知されているので、ノードＮ１は、ノードＮ７宛てのフレームをノードＮ３に向けて送信する。つまり、第１の実施形態によると、ノードＮ１は、クラスタ間の通信の中継を行うノード装置１０を境界ノードの中から選択しなくても良くなる。このため、ノードＮ１がノードＮ７宛てのフレームを生成してから、フレームの転送先を特定するための処理が簡略化できる。このため、ノードＮ１でノードＮ７宛てのフレームの経路の決定にかかる時間を短縮化できる。ノードＮ１からノードＮ７宛てのフレームを受信したノードＮ２も、ノードＮ１と同様に、ノードＮ７がクラスタＣ１に含まれていないことを特定すると、ノードＮ７宛てのフレームをノードＮ３に送信する。従って、ノードＮ２についても、フレームの転送先をクラスタＣ１中の境界ノードの中から選択する場合に比べて、第１の実施形態による方法の方が、処理負担が軽減されているといえる。

〔サブゲートウェイの変更方法〕
図１５は、サブゲートウェイの変更方法の例を説明する図である。図１５を参照しながら、新たなクラスタを検出したときに行われるサブゲートウェイの変更方法の例を説明する。

図１５（ａ）は、図８（ａ）に示すアドホックネットワークにノードＮ９が加わり、ノードＮ９がクラスタＣ９に含まれている場合を例としてサブゲートウェイの変更方法の例を説明する。図１５（ａ）に示すようにノードＮ９がアドホックネットワークに参加しても、ノードＮ９がＨｅｌｌｏフレームを送信する前は、サブゲートウェイの設定は図８を参照しながら説明した場合から変化しない。このときのノードＮ３〜Ｎ５が保持するマスタ側クラスタテーブル５３の例を、図１６に示す。図１６（ａ）はノードＮ３、図１６（ｂ）はノードＮ５、図１６（ｃ）はノードＮ４が保持するマスタ側クラスタテーブル５３の例である。

次に、ノードＮ９が以下の情報要素を含むＨｅｌｌｏフレームを送信したとする。
タイプ ：Ｈｅｌｌｏフレーム
ＧＳ ：ノードＮ９
ＬＳ ：ノードＮ９
クラスタ情報中のクラスタＩＤ：Ｃ９
マスタ側クラスタ情報 ：なし
隣接クラスタ数 ：０
図１５（ａ）の例では、ノードＮ９の隣接ノードであるノードＮ４がＨｅｌｌｏフレームを受信する。ノードＮ４は、ノードＮ９から受信したＨｅｌｌｏフレームにより、ノードＮ９とクラスタＣ９の存在を検出する。そこで、ノードＮ４のマスタ側テーブル更新部３３は、マスタ側クラスタテーブル５３にクラスタＣ９についてのエントリを追加する。さらに、ノードＮ４の処理種別判定部３１は、クラスタＣ１がクラスタＣ９に対するマスタ側クラスタであると判定し、マスタ側クラスタ情報をリーダーノード特定部４１に出力する。リーダーノード特定部４１は、ノードＮ４を、クラスタＣ１とＣ９の間のサブゲートウェイの設定の際のリーダーノードに選択する。さらに、サブゲートウェイ選択部４２は、ノードＮ４を、クラスタＣ１とＣ９の間のマスタ側サブゲートウェイに決定する。中継先決定部４３は、ノードＮ９をスレーブ側のサブゲートウェイに決定する。

また、ノードＮ４は、ノードＮ４の隣接クラスタの数を１から２に変更する。サブゲートウェイ選択部４２は、ノードＮ４の隣接クラスタ数が２に変更されたことにより、現在クラスタＣ１でクラスタＣ９以外のクラスタとの間のサブゲートウェイに設定されているノード装置１０よりも自ノードの条件が良くなったかを判定する。クラスタＣ１とクラスタＣ４の間の通信に用いられるサブゲートウェイは、ノードＮ３でありノードＮ３の隣接クラスタの数は１である。このため、ノードＮ４のサブゲートウェイ選択部４２は、ノードＮ４の方がノードＮ３よりも、サブゲートウェイとしての条件が良いと判定する。ノードＮ４のサブゲートウェイ選択部４２は、ノードＮ４がクラスタＣ１とクラスタＣ７の間の通信に用いられるサブゲートウェイを決定する際のリーダーノードではないので、ノードＮ４を、クラスタＣ７との間のサブゲートウェイ候補とする。これらの処理により、Ｈｅｌｌｏフレームを受信した後のノードＮ４のマスタ側クラスタテーブル５３は、図１７（ａ）に示すように更新される。

次に、ノードＮ４がＨｅｌｌｏフレームを生成したとする。ノードＮ４は、ノードＮ４が保持するマスタ側クラスタテーブル５３（図１７（ａ）参照）のうち、スレーブ側のサブゲートウェイ候補以外の情報を、Ｈｅｌｌｏフレームに含める。従って、マスタ側クラスタ情報には、クラスタＣ７の情報と、クラスタＣ９の情報がＨｅｌｌｏフレームに含められる。ノードＮ４で生成されたＨｅｌｌｏフレームは、ノードＮ４の隣接ノード装置に送信される。

ノードＮ４から送信されたＨｅｌｌｏフレームをノードＮ９が受信すると、図９Ａを参照して説明した手順（９）のノードＮ６と同様の処理を行う。このため、ノードＮ９のスレーブ側クラスタテーブル５４は、図１７（ｂ）に示すように更新される。

ノードＮ４から送信されたＨｅｌｌｏフレームをノードＮ３も受信する。この時点ではクラスタＣ１とＣ７の間の通信でのマスタ側サブゲートウェイはノードＮ３である。このため、ノードＮ３のサブゲートウェイ選択部４２は、Ｈｅｌｌｏフレーム中のサブゲートウェイ候補の情報と、ノードＮ３の情報を比較する。ノードＮ３の隣接クラスタ数が１であり、ノードＮ４の隣接クラスタ数は２である。このため、ノードＮ３のサブゲートウェイ選択部４２は、ノードＮ４の方がノードＮ３よりも、サブゲートウェイとしての条件が良いと判定する。ノードＮ３のサブゲートウェイ選択部４２は、ノードＮ３がクラスタＣ１とクラスタＣ７の間の通信に用いられるサブゲートウェイを決定する際のリーダーノードであるので、ノードＮ４を、クラスタＣ７との間のサブゲートウェイとする。また、サブゲートウェイ候補の情報は記録しない。このため、ノードＮ３のマスタ側クラスタテーブル５３は、図１７（ｃ）に示す通りになる。

さらに、ノードＮ３がＨｅｌｌｏフレームを生成したとする。ノードＮ３は、ノードＮ３が保持するマスタ側クラスタテーブル５３（図１７（ｃ）参照）のうち、スレーブ側のサブゲートウェイ候補以外の情報を、Ｈｅｌｌｏフレームに含める。ノードＮ３で生成されたＨｅｌｌｏフレームは、ノードＮ３の隣接ノード装置に送信される。

ノードＮ４は、ノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ４のサブゲートウェイ選択部４２は、クラスタＣ１とＣ７の通信に関するマスタ側クラスタ情報において、ノードＮ４がマスタ側サブゲートウェイに設定されていることを検出する。すると、ノードＮ４は、マスタ側サブゲートウェイとして動作を開始する。このため、図１５（ｂ）に示すようにサブゲートウェイが設定される。さらに、ノードＮ４のマスタ側テーブル更新部３３は、マスタ側クラスタテーブル５３を、Ｈｅｌｌｏフレームを用いて、図１８（ａ）に示すように変更する。

ノードＮ５は、ノードＮ３からＨｅｌｌｏフレームを受信する。ノードＮ５のサブゲートウェイ選択部４２は、ノードＮ４がマスタ側サブゲートウェイに設定されていることを検出すると、マスタ側クラスタテーブル５３を、Ｈｅｌｌｏフレームを用いて、図１８（ｂ）に示すように変更する。

その後、ノードＮ４が再度、Ｈｅｌｌｏフレームを生成したとする。ノードＮ４は、ノードＮ４が保持するマスタ側クラスタテーブル５３（図１８（ａ）参照）のうち、スレーブ側のサブゲートウェイ候補以外の情報を、Ｈｅｌｌｏフレームに含める。ノードＮ４で生成されたＨｅｌｌｏフレームは、ノードＮ４の隣接ノード装置に送信される。

ノードＮ４から送信されたＨｅｌｌｏフレームをノードＮ８が受信すると、ノードＮ８のスレーブ側テーブル更新部３２は、クラスタＣ１とクラスタＣ７の通信において、ノードＮ８がスレーブ側のサブゲートウェイに設定されていることを検出する。そこで、ノードＮ８は、スレーブ側サブゲートウェイとして動作を開始する。このため、図１５（ｃ）に示すようにサブゲートウェイが設定される。

ノードＮ４から送信されたＨｅｌｌｏフレームをノードＮ３が受信すると、ノードＮ３のマスタ側テーブル更新部３３は、クラスタＣ７についてのエントリの処理を行う。マスタ側テーブル更新部３３は、クラスタＣ７において、ノードＮ８がスレーブ側のサブゲートウェイに決定されたことを検出する。そこで、ノードＮ３は、スレーブ側サブゲートウェイの情報を更新し、マスタ側クラスタテーブル５３を図１９（ａ）に示すように更新する。

ノードＮ４から送信されたＨｅｌｌｏフレームをノードＮ９が受信すると、ノードＮ９のスレーブ側テーブル更新部３２は、ノードＮ９がスレーブ側のサブゲートウェイに設定されていることを検出する。そこで、ノードＮ９は、スレーブ側サブゲートウェイとして動作を開始する。このため、図１５（ｄ）に示すようにサブゲートウェイが設定される。

その後、ノードＮ３がＨｅｌｌｏフレームを生成すると、図１９（ａ）に含まれている情報のうちのサブゲートウェイ候補以外の情報が、ノードＮ３の隣接ノードに通知される。そこで、ノードＮ５は、クラスタＣ１とクラスタＣ７の通信の際にスレーブ側サブゲートウェイとして動作するノードがノードＮ８であることを認識する。このため、ノードＮ５のマスタ側クラスタテーブル５３は、図１９（ｂ）に示すように変更される。

図２０は、ノード装置１０で行われる処理の例を示すフローチャートである。なお、ステップＳ３とＳ４の順序は、実装に応じて変更することができる。ノード装置１０は、クラスタに所属しているかを判定する（ステップＳ１）。いずれかのクラスタに所属しているノード装置１０は、クラスタに所属しているノード装置１０からＨｅｌｌｏフレームを受信したかを判定する（ステップＳ１でＹｅｓ、ステップＳ２）。クラスタに所属しているノード装置１０からＨｅｌｌｏフレームを受信した場合、ノード装置１０は、Ｈｅｌｌｏフレームで通知されたマスタ側クラスタ情報を処理する（ステップＳ２でＹｅｓ、ステップＳ３）。さらに、ノード装置１０は、マスタ側クラスタ中のノード装置１０である場合、Ｈｅｌｌｏフレームの送信元のノード装置１０が参加しているクラスタの情報を更新する（ステップＳ４）。

図２１Ａと図２１Ｂは、受信したマスタ側クラスタ情報の処理の例を説明するフローチャートである。図２１Ａと図２１Ｂは、Ｈｅｌｌｏフレームを受信したノード装置１０が行う処理の例である。処理種別判定部３１は、受信したＨｅｌｌｏフレームにマスタ側クラスタ情報があるかを判定する（ステップＳ１１）。Ｈｅｌｌｏフレームにマスタ側クラスタ情報が含まれていない場合、処理種別判定部３１は、マスタ側クラスタに含まれている境界ノードからＨｅｌｌｏフレームを受信しなかったと判定し、マスタ側クラスタ情報の処理を終了する（ステップＳ１１でＮｏ）。一方、Ｈｅｌｌｏフレームにマスタ側クラスタ情報が含まれている場合、処理種別判定部３１は、変数ｎを１に設定する（ステップＳ１２）。処理種別判定部３１は、マスタ側クラスタ情報の中から、ｎ番目に含まれているエントリの取得を試みる。以下の説明で、マスタ側クラスタ情報の中に含まれているエントリのことを「ＭＣＩエントリ」と記載する。処理種別判定部３１は、ｎ番目のＭＣＩエントリを取得できない場合、マスタ側クラスタ情報の処理を終了する（ステップＳ１３でＮｏ）。

処理種別判定部３１は、ｎ番目のＭＣＩエントリを取得した場合、自ノードがＨｅｌｌｏフレームの送信元と同じクラスタに所属しているかを判定する（ステップＳ１３でＹｅｓ、ステップＳ１４）。Ｈｅｌｌｏフレームの送信元と同じクラスタに所属しているノード装置１０のリーダーノード特定部４１は、処理対象のＭＣＩエントリと同じクラスタＩＤのエントリを、マスタ側クラスタテーブル５３から取得しようとする（ステップＳ１４でＹｅｓ、Ｓ１５）。リーダーノード特定部４１は、エントリの取得に成功すると、処理対象のＭＣＩエントリに含まれているリーダーノードのノードＩＤを、マスタ側クラスタテーブル５３に設定されているリーダーノードのノードＩＤと比較する（ステップＳ１６でＹｅｓ、ステップＳ１７）。処理対象のＭＣＩエントリに含まれているリーダーノードのノードＩＤ中の数字の方が小さい場合、リーダーノード特定部４１は、より良いリーダーノードが通知されたと判定し、リーダーノードを変更する（ステップＳ１７でＹｅｓ、ステップＳ１８）。その後、サブゲートウェイ選択部４２により、マスタ側サブゲートウェイ（ＳＧＷ）の更新処理が行われる（ステップＳ１９）。一方、より良いリーダーノードが通知されていないと判定した場合、リーダーノードが変更されずに、マスタ側サブゲートウェイの更新処理が行われる（ステップＳ１７でＮｏ、ステップＳ１９）。その後、処理種別判定部３１は、ｎを１つインクリメントしてステップＳ１３以降の処理を行う（ステップＳ２０）。

図２１Ｂを参照しながら、ステップＳ１４でＮｏと判定された場合に行われる処理を説明する。Ｈｅｌｌｏフレームの送信元と同じクラスタに所属していないノード装置１０では、スレーブ側テーブル更新部３２は、処理対象のＭＣＩエントリ中のスレーブ側クラスタが自ノードのクラスタであるかを判定する（ステップＳ３１）。処理対象のＭＣＩエントリ中のスレーブ側クラスタが自ノードのクラスタでない場合、処理種別判定部３１は、隣接クラスタと他のクラスタとの間の通信に用いるサブゲートウェイを決定するための情報を含むＭＣＩエントリを取得したと判定する。そこで、処理種別判定部３１は、取得したＭＣＩエントリは処理対象ではないと判定し、廃棄する（ステップＳ３１でＮｏ、ステップＳ３２）。

スレーブ側クラスタが自ノードのクラスタである場合、スレーブ側テーブル更新部３２は、処理対象のＭＣＩエントリと同じクラスタＩＤに対応付けられたエントリをスレーブ側クラスタテーブル５４から取得する（ステップＳ３１でＹｅｓ、ステップＳ３３）。次に、スレーブ側テーブル更新部３２は、処理対象のＭＣＩエントリにおいて、自ノードがスレーブ側サブゲートウェイに指定されているかを判定する（ステップＳ３４）。自ノードがスレーブ側サブゲートウェイに指定されていない場合、スレーブ側テーブル更新部３２は、スレーブ側クラスタテーブル５４中に、Ｈｅｌｌｏフレームの送信元がマスタ側サブゲートウェイとして登録されているかを判定する（ステップＳ３４でＮｏ）。スレーブ側テーブル更新部３２は、Ｈｅｌｌｏフレームの送信元がサブゲートウェイであるエントリがあれば、そのエントリを、スレーブ側クラスタテーブル５４から削除する（ステップＳ３６）。一方、処理対象のＭＣＩエントリ中のスレーブ側サブゲートウェイが自ノードである場合、スレーブ側テーブル更新部３２は、Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイであるかを判定する（ステップＳ３４でＹｅｓ、ステップＳ３５）。Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイである場合、スレーブ側テーブル更新部３２は、自ノードをスレーブ側クラスタのサブゲートウェイに設定する（ステップＳ３５でＹｅｓ、ステップＳ３７）。一方、Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイではない場合、Ｈｅｌｌｏフレームの送信元がマスタ側サブゲートウェイとして登録されているかを判定する（ステップＳ３５でＮｏ）。Ｈｅｌｌｏフレームの送信元がマスタ側クラスタのサブゲートウェイである場合、ステップＳ３６の処理が行われる。

図２２は、Ｈｅｌｌｏフレームの送信元が属するクラスタの情報の処理の例を説明するフローチャートである。処理種別判定部３１は、スレーブ側クラスタ中のノード装置１０からＨｅｌｌｏフレームを受信したかを判定する（ステップＳ４１）。スレーブ側クラスタ中のノード装置１０からＨｅｌｌｏフレームを受信した場合、マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレームの送信元が属するクラスタに対するエントリをマスタ側クラスタテーブル５３から取得することを試みる（ステップＳ４２）。エントリの取得に成功すると、マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレームの送信元の条件を、マスタ側クラスタテーブル５３中のスレーブ側のサブゲートウェイ候補の条件と比較する（ステップＳ４３でＹｅｓ、ステップＳ４４）。Ｈｅｌｌｏフレームの送信元が、スレーブ側のサブゲートウェイ候補よりも条件が良い場合、マスタ側テーブル更新部３３は、スレーブ側サブゲートウェイ候補を変更する（ステップＳ４４でＹｅｓ、ステップＳ４５）。さらに、サブゲートウェイ選択部４２は、自ノードがマスタ側クラスタのサブゲートウェイであるかを判定する（ステップＳ４６）。自ノードがマスタ側クラスタのサブゲートウェイである場合、サブゲートウェイ選択部４２は、スレーブ側サブゲートウェイを変更する（ステップＳ４６でＹｅｓ、ステップＳ４７）。一方、自ノードがマスタ側クラスタのサブゲートウェイでない場合、サブゲートウェイ選択部４２は処理を終了する（ステップＳ４６でＮｏ）。また、Ｈｅｌｌｏフレームの送信元の条件が、スレーブ側のサブゲートウェイ候補の条件以下である場合、マスタ側テーブル更新部３３は、処理を終了する（ステップＳ４４でＮｏ）。さらに、ステップＳ４１でＮｏと判定された場合、処理種別判定部３１は処理を終了する。

ステップＳ４３でエントリの取得に失敗すると、マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレームの送信元のノード装置１０が属するクラスタに関するエントリをマスタ側クラスタテーブル５３に生成する（ステップＳ４８）。リーダーノード特定部４１は、新たにエントリが生成されたクラスタについては、自ノードをリーダーノードに設定する。さらに、サブゲートウェイ選択部４２は、新たにエントリが生成されたクラスタについて、自ノードをマスタ側のサブゲートウェイに設定する（ステップＳ４９）。さらに、中継先決定部４３は、Ｈｅｌｌｏフレームの送信元を、スレーブ側クラスタのサブゲートウェイに設定する（ステップＳ５０）。

図２３は、マスタ側サブゲートウェイの更新処理の例を説明するフローチャートである。サブゲートウェイ選択部４２は、処理対象のＭＣＩエントリに、自ノードよりも条件が良いサブゲートウェイ候補の情報が含まれているかを判定する（ステップＳ６１）。自ノードよりも条件が良いサブゲートウェイ候補の情報が含まれていない場合、サブゲートウェイ選択部４２は、現在のマスタ側サブゲートウェイに設定されているノード装置１０について、隣接クラスタ数とノードＩＤを取得する（ステップＳ６２）。サブゲートウェイ選択部４２は、現在のマスタ側サブゲートウェイに設定されているノード装置１０と、自ノードの条件を比較し、自ノードの方が現在のマスタ側サブゲートウェイよりも良好な条件を備えているかを判定する（ステップＳ６３）。自ノードの条件の方が良好である場合、サブゲートウェイ選択部４２は、自ノードがリーダーノードであるかを判定する（ステップＳ６４）。自ノードがリーダーノードである場合、サブゲートウェイ選択部４２は、マスタ側サブゲートウェイを自ノードに変更するとともに、マスタ側クラスタテーブル５３を適宜変更する（ステップＳ６４でＹｅｓ、ステップＳ６５）。例えば、サブゲートウェイ選択部４２は、マスタ側クラスタのサブゲートウェイの隣接クラスタの値やシーケンス番号を、自ノードの値に変更する。また、スレーブ側サブゲートウェイを、自ノードが保持しているマスタ側クラスタテーブル５３に含まれているスレーブ側のサブゲートウェイ候補にする。一方、自ノードがリーダーノードでない場合、サブゲートウェイ選択部４２は、自ノードをマスタ側サブゲートウェイ候補に設定する（ステップＳ６６）。ステップＳ６３において、自ノードが現在設定されているマスタ側サブゲートウェイよりも条件が悪いと判定すると、サブゲートウェイ選択部４２は処理を終了する。

次に、ステップＳ６１において処理対象のＭＣＩエントリに、自ノードよりも条件が良いサブゲートウェイ候補の情報が含まれていると判定された場合の処理について説明する。この場合も、サブゲートウェイ選択部４２は、現在のマスタ側サブゲートウェイに設定されているノード装置１０について、隣接クラスタ数とノードＩＤを取得する（ステップＳ６７）。サブゲートウェイ選択部４２は、現在のマスタ側サブゲートウェイに設定されているノード装置１０よりも、サブゲートウェイ候補の方が良好な条件を備えているかを判定する（ステップＳ６８）。サブゲートウェイ候補の条件の方が良好である場合、サブゲートウェイ選択部４２は、自ノードがリーダーノードであるかを判定する（ステップＳ６８でＹｅｓ、ステップＳ６９）。自ノードがリーダーノードである場合、サブゲートウェイ選択部４２は、マスタ側サブゲートウェイをサブゲートウェイ候補として通知されたノード装置に変更するとともに、マスタ側クラスタテーブル５３を適宜変更する（ステップＳ６９でＹｅｓ、ステップＳ７０）。例えば、サブゲートウェイ選択部４２は、マスタ側クラスタのサブゲートウェイの隣接クラスタの値やシーケンス番号を、サブゲートウェイ候補の値に変更する。一方、自ノードがリーダーノードでない場合、サブゲートウェイ選択部４２は、処理を終了する（ステップＳ６９でＮｏ）。ステップＳ６８において、サブゲートウェイ候補の条件は現在設定されているマスタ側サブゲートウェイの条件以下であると判定すると、サブゲートウェイ選択部４２は、サブゲートウェイ候補の情報を記憶しない（ステップＳ７１）。

境界ノードは、図２０〜図２３を参照しながら説明したような処理を行うため、クラスタの増減やノード装置１０の数の増設にも柔軟に対応してサブゲートウェイを決定することができる。

図１５〜図２３を参照しながら説明したように、クラスタの増設やノード装置１０の増減により、サブゲートウェイが変更された場合も、サブゲートウェイとして動作するノード装置１０の識別子は、Ｈｅｌｌｏフレーム中のクラスタ情報に含められる。このため、境界ノード以外のノード装置１０も、Ｈｅｌｌｏフレームにより、サブゲートウェイが変更されたことと、変更後のサブゲートウェイを特定することができる。例えば、図１５（ｄ）の例では、クラスタＣ１中のいずれのノード装置１０も、クラスタＣ７またはＣ９に含まれているノード装置１０に宛てたフレームを、ノードＮ４に送信すれば良いことがＨｅｌｌｏフレームから特定できる。このため、クラスタ中のノード装置は、他のクラスタ中のノード装置１０に宛てたフレームの転送先を、フレームの転送のたびに境界ノードの中から選択しなくても良い。このため、各ノード装置１０の転送処理における負担が軽減される。

ここで、フレームの中継先を指定する方法の例を説明する。例えば、ノードＮ１がデータフレームをノードＮ７に送信しようとしているとする。ノードＮ１のデータフレーム処理部１５が生成するデータフレームの例を図２４（ａ）に示す。データフレームには、送信されるデータ、タイプ情報、グローバル宛先アドレス、グローバル送信元アドレス、ローカル宛先アドレス、ローカル送信元アドレスが含まれる。ノードＮ１の転送処理部２７は、クラスタＣ１に含まれていないノード装置１０に宛てたフレームを転送する場合、フレームにサブゲートウェイ情報（ＳＧＷ情報）を付加する。サブゲートウェイ情報を含むデータフレームを図２４（ｂ）に示す。ここでは、クラスタＣ１のサブゲートウェイはノードＮ４であることが予め通知されているため、サブゲートウェイ情報にノードＮ４のアドレスが設定されるものとする。サブゲートウェイ情報は、クラスタ内の通信においては、グローバル宛先と同様に扱われる。例えば、ノードＮ２は、ノードＮ１から受信したフレームのサブゲートウェイ情報を確認することにより、受信フレームをＮ４に転送することを決定する。このとき、ノードＮ２の転送処理部２７は、データフレーム中のローカル宛先アドレスとローカル送信元アドレスを変更した上で、フレームをノードＮ４に転送する。ノードＮ４は、サブゲートウェイ情報に設定されているアドレスがノードＮ４に割り当てられているアドレスであることを特定すると、受信したフレームからサブゲートウェイ情報を除去する。さらに、ノードＮ４は、サブゲートウェイを除去した後のフレームを隣接クラスタのサブゲートウェイに転送する。なお、１つのクラスタに複数のサブゲートウェイがある場合、サブゲートウェイ情報に指定されるアドレスは、１つのクラスタ中の全てのサブゲートウェイを指定するマルチキャストアドレスであっても良い。１つのクラスタ中の全てのサブゲートウェイにフレームがマルチキャスト送信されたとしても、サブゲートウェイの数は、境界ノードの数よりも少ないので、輻輳が発生しにくい。

第１の実施形態にかかる方法は、サブゲートウェイがフレームの中継先のノード装置１０への経路情報を保持する場合に適応でき、また、サブゲートウェイが自クラスタ以外の経路情報を保持していない場合にも適応できる。サブゲートウェイが中継先のクラスタ中の経路情報を保持する場合、サブゲートウェイとして動作するノード装置１０の数が多い程、複数のノード装置１０で他クラスタの経路情報を重複して記憶するケースが多くなる。例えば、図８（ａ）において、クラスタＣ１中のノードＮ３〜Ｎ５の全てがクラスタＣ１とクラスタＣ７の間の通信を中継する場合、ノードＮ３〜Ｎ５の全てがクラスタＣ１とクラスタＣ７の経路情報を保持することになってしまう。同様に、第１の実施形態にかかる方法を適応しないと、クラスタＣ７では、ノードＮ６とＮ８の両方が、クラスタＣ１とクラスタＣ７の経路情報を保持することになる。しかし、第１の実施形態を適応することにより、図８（ａ）に示すネットワークでは、ノードＮ３とＮ６がクラスタ間の通信を中継するために、クラスタＣ１とクラスタＣ７の経路情報を保持すればよい。従って、他クラスタの経路情報が複数のノード装置１０に重複して記憶されないので、第１の実施形態では、ノード装置が保持するメモリが効率的に使用される。

さらに、第１の実施形態にかかる方法では、クラスタ間の通信を中継するノード装置１０が、境界ノードの中から自律的に選択される。このため、第１の実施形態にかかる方法は、ノードの数が多い大規模なネットワークや、クラスタの設定の変更が頻繁に行われる場合にも使用できる。

＜第２の実施形態＞
第２の実施形態として、アドホックネットワークに参加しているノード装置１０が隣接ノード装置１０に障害が発生したかを判定し、障害を検出すると動的にサブゲートウェイを変更する場合について説明する。

第２の実施形態では、マスタ側クラスタ中の境界ノードは、リーダーノードからＨｅｌｌｏフレームを受信する間隔をモニタすることにより、リーダーノードに障害が発生しているかを判定する。リーダーノードに障害が発生した場合、マスタ側クラスタ中の境界ノードは、リーダーノードを変更する。例えば、リーダーノードの障害を検出した境界ノードは、自ノードをリーダーノードに指定したＨｅｌｌｏフレームを隣接ノードに送信することにより、リーダーノードの変更を行う。

リーダーノードは、マスタ側のサブゲートウェイからＨｅｌｌｏフレームが送信される間隔をモニタすることにより、マスタ側のサブゲートウェイに障害が発生しているかを判定する。リーダーノードは、マスタ側のサブゲートウェイの障害を検出すると、新たにマスタ側のサブゲートウェイを設定する。例えば、リーダーノードは、自ノードをサブゲートウェイに設定したＨｅｌｌｏフレームを送信することにより、マスタ側のサブゲートウェイを選択することができる。

マスタ側のサブゲートウェイは、スレーブ側のサブゲートウェイからＨｅｌｌｏフレームを受信する間隔をモニタすることにより、スレーブ側のサブゲートウェイに障害が発生しているかを判定する。スレーブ側のサブゲートウェイに障害が発生すると、マスタ側のサブゲートウェイは、他の隣接ノードをスレーブ側のサブゲートウェイに設定することができれば、スレーブ側のサブゲートウェイを変更する。一方、他にスレーブ側のサブゲートウェイに指定できるノード装置がない場合、マスタ側サブゲートウェイは、境界ノードではなくなったと判定する。すると、マスタ側クラスタテーブル５３から隣接しなくなったクラスタについてのエントリを削除する。その後、マスタ側サブゲートウェイに指定されているノード装置１０は、境界ノードではなくなったことをＨｅｌｌｏフレームでマスタ側クラスタ中の境界ノードに通知する。すると、リーダーノードは、新たにマスタ側のサブゲートウェイを設定しなおす。

さらに、スレーブ側クラスタ中のノード装置１０も、マスタ側クラスタのサブゲートウェイからのＨｅｌｌｏフレームを受信する頻度をモニタすることにより、マスタ側クラスタのサブゲートウェイの障害を検出することができる。スレーブ側クラスタのサブゲートウェイは、マスタ側クラスタのサブゲートウェイの障害を検出すると、障害を検出したノードをサブゲートウェイとしているエントリをスレーブ側クラスタテーブル５４から削除する。

以上の処理を行うために、第２の実施形態では、ノード装置１０はマスタ側クラスタテーブル５３の代わりにマスタ側クラスタテーブル６１を備え、スレーブ側クラスタテーブル５４の代わりにスレーブ側クラスタテーブル６２を備える。

図２５は、第２の実施形態で用いられるマスタ側クラスタテーブル６１の例を示す。マスタ側クラスタテーブル６１は、マスタ側クラスタテーブル５３に含まれている情報要素に加え、マスタ側サブゲートウェイ、スレーブ側サブゲートウェイ、リーダーノードについてのTime To Live（ＴＴＬ）を含む。マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレームに含まれているリーダーノードのシーケンス番号を、マスタ側クラスタテーブル６１でのリーダーノードのシーケンス番号と比較する。比較した結果、Ｈｅｌｌｏフレーム中のシーケンス番号の方が大きい場合、マスタ側テーブル更新部３３は、リーダーノードが正常にＨｅｌｌｏフレームを送信できたと判定し、リーダーノードのＴＴＬをリセットする。ＴＴＬの初期値は任意の正の整数である。一方、Ｈｅｌｌｏフレーム中のシーケンス番号がマスタ側クラスタテーブル６１に記録されている値以下の場合、マスタ側テーブル更新部３３は、すでに受信しているＨｅｌｌｏフレームを再度受信したと判定してＨｅｌｌｏフレームの処理を行わない。マスタ側テーブル更新部３３は、リーダーノードについてのＴＴＬの値を一定の時間ごとに１つデクリメントしていき、ＴＴＬの値が０になると、リーダーノードに障害が発生したと判定する。マスタ側テーブル更新部３３は、リーダーノードが新たに設定されると、リーダーノードのＴＴＬの値をリセットする。

マスタ側テーブル更新部３３は、マスタ側サブゲートウェイについても、リーダーノードと同様の方法により、ＴＴＬの値を更新する。リーダーノードは、サブゲートウェイ選択部４２が新たにマスタ側のサブゲートウェイを設定すると、ＴＴＬの値をリセットする。

マスタ側のサブゲートウェイのマスタ側テーブル更新部３３は、スレーブ側サブゲートウェイからＨｅｌｌｏフレームを受信すると、スレーブ側サブゲートウェイについてのＴＴＬの値をリセットする。なお、マスタ側のサブゲートウェイとスレーブ側サブゲートウェイは、互いに隣接しているので、処理済のＨｅｌｌｏフレームを再度受信する可能性は低い。このため、マスタ側のサブゲートウェイのマスタ側テーブル更新部３３は、スレーブ側サブゲートウェイから受信するＨｅｌｌｏフレームについては、シーケンス番号をモニタしなくても良い。マスタ側テーブル更新部３３は、スレーブ側サブゲートウェイについてのＴＴＬの値を一定の時間ごとに１つデクリメントしていき、ＴＴＬの値が０になると、スレーブ側サブゲートウェイに障害が発生したと判定する。

図２６は、第２の実施形態で用いられるスレーブ側クラスタテーブル６２の例を示す。スレーブ側クラスタテーブル６２には、マスタ側クラスタのＴＴＬと、マスタ側サブゲートウェイのＴＴＬが含まれている。スレーブ側テーブル更新部３２は、隣接するクラスタ中のノード装置１０から受信したＨｅｌｌｏフレームのクラスタ情報を抽出し、スレーブ側クラスタテーブル６２中のエントリと比較する。Ｈｅｌｌｏフレーム中のクラスタＩＤで識別されるクラスタのエントリについて、スレーブ側テーブル更新部３２は、マスタ側クラスタについてのＴＴＬをリセットする。スレーブ側テーブル更新部３２は、マスタ側クラスタについてのＴＴＬの値を一定の時間ごとに１つデクリメントしていき、ＴＴＬの値が０になると、マスタ側クラスタが消失したか、自ノードが隣接ノードではなくなったと判定する。スレーブ側テーブル更新部３２は、ＴＴＬの値が０になったマスタ側クラスタについてのエントリをスレーブ側クラスタテーブル６２から削除する。

スレーブ側クラスタ中のスレーブ側テーブル更新部３２は、マスタ側クラスタのサブゲートウェイからＨｅｌｌｏフレームを受信すると、マスタ側クラスタのサブゲートウェイについてのＴＴＬの値をリセットする。スレーブ側テーブル更新部３２は、マスタ側サブゲートウェイについてのＴＴＬの値を一定の時間ごとに１つデクリメントしていき、ＴＴＬの値が０になると、マスタ側サブゲートウェイに障害が発生したと判定する。スレーブ側テーブル更新部３２は、ＴＴＬの値が０になったマスタ側サブゲートウェイについてのエントリをスレーブ側クラスタテーブル６２から削除する。

図２７は、障害の発生によるサブゲートウェイの変更方法の例を示す。初期状態では、ノードＮ３がリーダーノードに設定され、マスタ側サブゲートウェイ、スレーブ側サブゲートウェイも図２７（ａ）に示すように設定されているものとする。図２７（ａ）の状態のときに、ノードＮ３〜Ｎ５が保持しているマスタ側クラスタテーブル６１の例を図２８に示す。図２８（ａ）はノードＮ４、図２８（ｂ）はノードＮ５、図２８（ｃ）はノードＮ３のマスタ側クラスタテーブル６１の例を示す。

その後、図２７（ｂ）に示すように、ノードＮ８に障害が発生したとする。ノードＮ８は、Ｈｅｌｌｏフレームの送信を中止する。ノードＮ４は、ノードＮ８からＨｅｌｌｏフレームを受信できなくなると、ノードＮ８についてのＴＴＬの値を一定時間ごとに１つずつデクリメントする。ノードＮ４は、ノードＮ８についてのＴＴＬの値が０になると、ノードＮ８に障害が発生したと判定する。ノードＮ４には、ノードＮ８以外にクラスタＣ７中の隣接ノードがない。このため、ノードＮ４は、クラスタＣ７に隣接しなくなったと判定し、マスタ側クラスタテーブル６１からクラスタＣ７のエントリを削除する。この処理により、ノードＮ４のマスタ側クラスタテーブル６１は、図２９（ａ）に示すようになる。

ノードＮ４に備えられているマスタ側クラスタテーブル６１からクラスタＣ７のエントリがなくなると、ノードＮ４は、生成するＨｅｌｌｏフレームに、クラスタＣ７についてのＭＣＩエントリを含めない。このため、ノードＮ３は、ノードＮ４からクラスタＣ７についてのＭＣＩエントリを受信することができない。ノードＮ３のマスタ側テーブル更新部３３は、クラスタＣ７のマスタ側サブゲートウェイであるノードＮ４からクラスタＣ７のＭＣＩエントリが送られてこないため、マスタ側サブゲートウェイのＴＴＬを一定時間ごとに１つずつデクリメントする。ノードＮ３は、マスタ側サブゲートウェイのＴＴＬが０になると、ノードＮ４はクラスタＣ７に隣接していないと判定する。ノードＮ３はリーダーノードであるので、ノードＮ３のサブゲートウェイ選択部４２は、ノードＮ３をクラスタＣ７との通信に用いられるマスタ側サブゲートウェイに設定する。さらに、ノードＮ３の中継先決定部４３は、ノードＮ３がマスタ側サブゲートウェイに設定されたため、ノードＮ６をスレーブ側サブゲートウェイに設定する。これらの処理により、サブゲートウェイは、図２７（ｃ）に示すように変更される。さらに、ノードＮ３の備えるマスタ側クラスタテーブル６１は、図２９（ｂ）に示すように更新される。

ノードＮ３は、サブゲートウェイを図２７（ｃ）に示すように変更した後、マスタ側サブゲートウェイがノードＮ３、スレーブ側サブゲートウェイがノードＮ６であることを通知するＨｅｌｌｏフレームを隣接ノードに送信する。このため、ノードＮ３からＨｅｌｌｏフレームを受信したノードＮ５では、マスタ側クラスタテーブルが図２８（ｂ）の状態から図２９（ｃ）に示すように変更される。

図３０は、障害発生時にマスタ側クラスタ中の境界ノードが行う処理の例を説明するフローチャートである。ノード装置１０は、ＴＴＬ＝０を含むエントリがあると判定すると、リーダーノードでＴＴＬ＝０になっているかを判定する（ステップＳ８１でＹｅｓ、ステップＳ８２）。リーダーノードでＴＴＬ＝０になっている場合、リーダーノード特定部４１は、自ノードをリーダーノードに設定し、リーダーノードのＴＴＬの値をリセットする（ステップＳ８２でＹｅｓ、ステップＳ８３）。リーダーノードでＴＴＬ＝０になっていない場合、ノード装置１０は、マスタ側サブゲートウェイについてのＴＴＬが０になっているかを判定する（ステップＳ８２でＮｏ、ステップＳ８４）。マスタ側サブゲートウェイについてのＴＴＬが０になっている場合、サブゲートウェイ選択部４２は、自ノードがリーダーノードであるかを判定する（ステップＳ８４でＹｅｓ、ステップＳ８５）。自ノードがリーダーノードでない場合、サブゲートウェイ選択部４２は処理を終了する（ステップＳ８５でＮｏ）。一方、自ノードがリーダーノードである場合、サブゲートウェイ選択部４２は、マスタ側のサブゲートウェイを変更し、ＴＴＬの値をリセットする（ステップＳ８５でＹｅｓ、ステップＳ８６）。

ステップＳ８４において、マスタ側サブゲートウェイについてのＴＴＬが０になっていない場合、中継先決定部４３は、スレーブ側サブゲートウェイに障害が発生したと判定する（ステップＳ８４でＮｏ）。そこで、中継先決定部４３は、自ノードがマスタ側サブゲートウェイであるかを判定する（ステップＳ８７）。自ノードがマスタ側サブゲートウェイでない場合、処理を終了する（ステップＳ８７でＮｏ）。自ノードがマスタ側サブゲートウェイである場合、スレーブ側サブゲートウェイを変更できるかを判定する（ステップＳ８７でＹｅｓ、ステップＳ８８）。スレーブ側サブゲートウェイを変更できる場合、中継先決定部４３は、新たなスレーブ側サブゲートウェイを決定した上で、ＴＴＬの値をリセットする（ステップＳ８８でＹｅｓ、ステップＳ８９）。スレーブ側サブゲートウェイを変更できない場合、中継先決定部４３は、ＴＴＬ＝０を含むエントリを削除する（ステップＳ８８でＮｏ、ステップＳ９０）。

図３１は、障害発生時にスレーブ側クラスタ中の境界ノードが行う処理の例を説明するフローチャートである。スレーブ側テーブル更新部３２は、ＴＴＬ＝０を含むエントリがあると判定すると、マスタ側クラスタのＴＴＬが０になっているかを判定する（ステップＳ９１でＹｅｓ、ステップＳ９２）。マスタ側クラスタのＴＴＬが０になっている場合、スレーブ側テーブル更新部３２は、ＴＴＬ＝０となっているマスタ側クラスタを含むエントリをスレーブ側クラスタテーブル６２から削除する（ステップＳ９２でＹｅｓ、ステップＳ９３）。マスタ側クラスタのＴＴＬが０になっていない場合、マスタ側サブゲートウェイのＴＴＬが０となっているかを判定する（ステップＳ９２でＮｏ、ステップＳ９４）。マスタ側サブゲートウェイのＴＴＬが０になっていない場合、スレーブ側テーブル更新部３２は処理を終了する（ステップＳ９４でＮｏ）。マスタ側サブゲートウェイのＴＴＬが０になっている場合、スレーブ側テーブル更新部３２は、ＴＴＬ＝０となっているマスタ側サブゲートウェイを含むエントリをスレーブ側クラスタテーブル６２から削除する（ステップＳ９４でＹｅｓ、ステップＳ９５）。

図３２Ａと図３２Ｂは、第２の実施形態におけるマスタ側クラスタ情報の処理の例を説明するフローチャートである。ステップＳ１０１〜Ｓ１０７は、図２１Ａを参照しながら説明したステップＳ１１〜Ｓ１７と同様である。通知されたリーダーノードの条件が現在のリーダーノードの条件以下の場合、マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレーム中のリーダーノードのシーケンス番号ＳＮが更新されているかを判定する（ステップＳ１０７でＮｏ、ステップＳ１０８）。Ｈｅｌｌｏフレーム中のリーダーノードのシーケンス番号が更新されている場合、マスタ側テーブル更新部３３は、リーダーノードのＴＴＬの値をリセットする（ステップＳ１０８でＹｅｓ、ステップＳ１０９）。さらに、マスタ側テーブル更新部３３は、リーダーノードのシーケンス番号を更新する。一方、現在のリーダーノードの条件よりも、通知されたリーダーノードの条件の方が良い場合、マスタ側テーブル更新部３３は、リーダーノードを変更する（ステップＳ１０７でＹｅｓ、ステップＳ１１０）。さらに、マスタ側テーブル更新部３３は、リーダーノードのＴＴＬをリセットし、シーケンス番号を更新する（ステップＳ１１１）。ステップＳ１０８でＮｏと判定された場合か、ステップＳ１０９、Ｓ１１１の処理の後、ステップＳ１１２の処理により、マスタ側サブゲートウェイが更新される。ステップＳ１１２については後述する。その後、マスタ側サブゲートウェイのＴＴＬがリセットされる（ステップＳ１１３）。さらに、ｎが１つインクリメントされ、ステップＳ１０３以降の処理が繰り返される（ステップＳ１１４）。

図３２ＢのステップＳ１２１〜Ｓ１２３は、図２１Ｂを参照しながら説明したステップＳ３１〜Ｓ３３と同様である。ステップＳ１２３の処理の後、スレーブ側テーブル更新部３２は、処理対象のＭＣＩに対応するスレーブ側クラスタテーブル６２のエントリについて、マスタ側クラスタのＴＴＬをリセットする（ステップＳ１２４）。ステップＳ１２５〜Ｓ１２７の処理は、図２１Ｂを参照しながら説明したステップＳ３４〜Ｓ３６と同様である。ステップＳ１２６でＹｅｓと判定されると、スレーブ側テーブル更新部３２は、自ノードを、スレーブ側サブゲートウェイに設定する。さらに、スレーブ側テーブル更新部３２は、スレーブ側クラスタテーブル６２中のマスタ側サブゲートウェイのＴＴＬをリセットする（ステップＳ１２８）。

図３３は、Ｈｅｌｌｏフレームの送信元が属するクラスタの情報の処理の例を説明するフローチャートである。ステップＳ１３１〜Ｓ１３３は、図２２を参照しながら説明したステップＳ４１〜Ｓ４３と同様である。マスタ側クラスタテーブル６１からのエントリの取得に成功すると、マスタ側テーブル更新部３３は、Ｈｅｌｌｏフレームの送信元がスレーブ側サブゲートウェイであるかを判定する（ステップＳ１３３でＹｅｓ、ステップＳ１３４）。Ｈｅｌｌｏフレームの送信元がスレーブ側サブゲートウェイでない場合、マスタ側テーブル更新部３３は処理を終了する（ステップＳ１３４でＹｅｓ、ステップＳ１３５）。ステップＳ１３６〜Ｓ１３９の処理は、図２２を参照しながら説明したステップＳ４４〜Ｓ４７と同様である。その後、中継先決定部４３は、スレーブ側サブゲートウェイのＴＴＬをリセットする（ステップＳ１４０）。ステップＳ１３６、Ｓ１３８でＮｏと判定された場合も、ステップＳ１４０の処理が行われる。ステップＳ１４１〜Ｓ１４３の処理は、図２２を参照しながら説明したステップＳ４８〜Ｓ５０と同様である。その後、中継先決定部４３は、スレーブ側サブゲートウェイのＴＴＬをリセットする（ステップＳ１４４）。

以上、説明したように、第２の実施形態では、サブゲートウェイとして動作するノード装置１０に障害が発生しても、自律的にサブゲートウェイの設定が変更される。また、第１の実施形態と同様の利点もある。

＜その他＞
なお、第１および第２の実施形態を含む以上の実施形態は、上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。

上記の例では、理解しやすくするために、１つのクラスタがマスタ側クラスタもしくはスレーブ側クラスタのいずれかとなる場合について説明した。しかし、１つのクラスタがあるクラスタに対してマスタ側クラスタとなり、他のクラスタに対してスレーブ側クラスタとなることもある。例えば、クラスタＣ２がクラスタＣ１、Ｃ３の両方と隣接しているとする。この場合、クラスタＣ２は、クラスタＣ１との間の通信に用いられるサブゲートウェイの決定では、スレーブ側クラスタとなるが、クラスタＣ３との間の通信に用いられるサブゲートウェイの決定では、マスタ側クラスタとなる。

Ｈｅｌｌｏフレームに含まれる情報要素は、実装に応じて追加されても良い。また、前述のとおり、Ｈｅｌｌｏフレーム以外の制御フレームを用いて、サブゲートウェイの設定が行われても良い。また、マスタ側クラスタテーブル５３、６１やスレーブ側クラスタテーブル５４、６２に含まれる情報要素も、実装に応じて変更されても良い。

第１および第２の実施形態を含む以上の実施形態は、クラスタがノード装置１０の増減に応じて動的に形成される場合と、クラスタが固定的に決定されている場合のいずれにも適応されうる。

さらに、リーダーノードやサブゲートウェイの選択条件は、実装に応じて変更されることがある。例えば、ノードＩＤに含まれている数値が大きいほど、リーダーノードに設定されやすくても良い。同様に、サブゲートウェイについても、ノードＩＤの値が大きいノード装置１０ほど選択されやすくなるように、条件が設定されていても良い。

１０ ノード装置
１１ 受信部
１２ 送信部
１３ フレーム処理部
１４ Ｈｅｌｌｏフレーム生成部
１５ データフレーム処理部
２０ クラスタ処理部
２１ クラスタ管理部
２２ 抽出処理部
２５ ルーティング処理部
２６ 経路情報処理部
２７ 転送処理部
３０ サブゲートウェイ設定部
３１ 処理種別判定部
３２ スレーブ側テーブル更新部
３３ マスタ側テーブル更新部
４０ 決定処理部
４１ リーダーノード特定部
４２ サブゲートウェイ選択部
４３ 中継先決定部
５０ 記憶部
５１ ノード種別情報
５２ ルーティングテーブル
５３、６１ マスタ側クラスタテーブル
５４、６２ スレーブ側クラスタテーブル
５５ クラスタ情報テーブル
５６ データ
１００ プロセッサ
１０１ バス
１０２ ＰＨＹチップ
１０４ タイマＩＣ
１０６ ＤＲＡＭ
１０７ フラッシュメモリ
１０８ 無線モジュール

Claims (17)

1. 第１のクラスタ中に位置し、前記第１のクラスタに隣接する第２のクラスタ中のノード装置と通信可能なノード装置のグループである第１のグループから選択された選択装置が、前記第１のクラスタ中のノード装置と前記第２のクラスタ中のノード装置の間の通信に使用されるフレームである中継フレームを中継する第１の中継装置を、前記第１のグループから選択し、
   前記選択装置は、前記選択装置に隣接するノード装置へ、前記第１の中継装置の識別子を通知する通知フレームを送信し、
   前記選択装置に隣接するノード装置であって前記通知フレームにより通知される前記第１の中継装置の識別子が自身の識別子である該ノード装置である前記第１の中継装置は、前記中継フレームを受信すると、前記第２のクラスタ中に位置し、かつ、前記第１のクラスタ中のノード装置と通信可能なノード装置のグループである第２のグループに含まれるノード装置のうち、前記第１の中継装置に隣接するノード装置を、前記中継フレームを前記第２のクラスタ中のノード装置へ中継する第２の中継装置に決定する
   ことを特徴とする通信方法。
2. 前記第１のグループに含まれているノード装置が、自ノード装置が通信可能なクラスタの数を、前記選択装置に通知し、
   前記選択装置は、通信可能なクラスタ数が相対的に大きいノード装置を前記第１の中継装置に選択する
   ことを特徴とする請求項１に記載の通信方法。
3. 前記第２のグループに含まれているノード装置が、通信可能なクラスタの数を、隣接するノード装置に通知し、
   前記第１の中継装置は、前記第２のグループに含まれ、かつ、前記第１の中継装置に隣接するノード装置の中から、通信可能なクラスタ数が相対的に大きいノード装置を前記第２の中継装置に決定する
   ことを特徴とする請求項１または２に記載の通信方法。
4. 前記選択装置は、
   前記第１のグループに含まれている第１のノード装置を前記第１の中継装置に選択した後に、前記第１のグループ中の第２のノード装置から通信可能なクラスタの数を取得し、
   前記第１のノード装置が通信可能なクラスタ数よりも、第２のノード装置が通信可能なクラスタ数のほうが大きいと判定すると、前記第１の中継装置を前記第１のノード装置から前記第２のノード装置に変更する
   ことを特徴とする請求項１〜３のいずれか１項に記載の通信方法。
5. 前記第１の中継装置が前記第１のノード装置から前記第２のノード装置に変更されると、前記第２のノード装置は、前記第２のグループに含まれていて前記第２のノード装置に隣接する第３のノード装置に、前記第２の中継装置として動作することを要求し、
   前記第３のノード装置は、前記第１の中継装置からの要求に応じて、前記中継フレームの中継を開始し、
   前記第１のノード装置が前記第２の中継装置に決定した第４のノード装置は、前記第１のノード装置から、前記第３のノード装置が前記第２の中継装置に設定されたことを通知されると、前記中継フレームの中継を終了する
   ことを特徴とする請求項４に記載の通信方法。
6. 前記第１の中継装置は、
   前記第２のグループに含まれている第４のノード装置を前記第２の中継装置に決定した後に、前記第２のグループ中で前記第１の中継装置に隣接する第５のノード装置から、前記第５のノード装置が通信可能なクラスタ数を取得し、
   前記第４のノード装置が通信可能なクラスタ数よりも、前記第５のノード装置が通信可能なクラスタ数のほうが大きいと判定すると、前記第２の中継装置を前記第４のノード装置から前記第５のノード装置に変更する
   ことを特徴とする請求項１〜５のいずれか１項に記載の通信方法。
7. 前記第１の中継装置に設定された第１のノード装置が、前記第２の中継装置として動作している第４のノード装置に障害が発生しているかを監視し、
   前記第４のノード装置に障害が発生したことにより、前記第１のノード装置が前記第１のグループに含まれなくなった場合、前記第１のノード装置は、前記第１のノード装置が前記第２のクラスタに通信できないことを、前記選択装置に通知し、
   前記選択装置は、前記第１のグループ中の第２のノード装置を選択し、前記第２のノード装置を前記第１の中継装置に設定する
   ことを特徴とする請求項１〜６のいずれか１項に記載の通信方法。
8. 前記第１の中継装置に設定された第１のノード装置が、前記第２の中継装置として動作している第４のノード装置に障害が発生しているかを監視し、
   前記第４のノード装置に障害が発生したことにより、前記第１のノード装置が前記第１のグループに含まれなくなった場合、前記第１のノード装置は、前記第１のノード装置が前記第２のクラスタに通信できないことを、前記第１のノード装置に隣接するノード装置に通知し、
   前記第１のノード装置に隣接する前記第１のグループ中のノード装置は、前記第１の中継装置の候補である候補装置になったことを、隣接するノード装置に通知し、
   前記選択装置は、前記候補装置の中から前記第１の中継装置を選択する
   ことを特徴とする請求項１〜６のいずれか１項に記載の通信方法。
9. 前記選択装置は、前記第１の中継装置に選択した第１のノード装置に障害が発生しているかを監視し、
   前記第１のノード装置に障害が発生したことにより、前記第１のノード装置から前記第２のクラスタ中のノード装置への前記中継フレームの中継ができなくなった場合、前記選択装置は、前記第１のグループ中の第２のノード装置を選択し、前記第２のノード装置を前記第１の中継装置に設定する
   ことを特徴とする請求項１〜８のいずれか１項に記載の通信方法。
10. 隣接するノード装置である隣接ノード装置から、フレームを受信し、
    第１のクラスタ中のノード装置と、前記第１のクラスタに隣接する第２のクラスタ中のノード装置の間の通信を中継する第１の中継装置を前記第１のクラスタ中のノード装置から選択する選択装置を特定し、
    前記選択装置として特定された場合、前記第１のクラスタ中に位置し、かつ、前記第２のクラスタ中のノード装置に通信可能なノード装置のグループである第１グループから、前記第１の中継装置を選択し、前記第１の中継装置に決定されたノード装置を識別する情報を前記第１グループ中の他のノード装置へ送信し、
    前記第１の中継装置に決定されたノード装置を識別する情報の受信により前記選択装置から前記第１の中継装置に選択されたと判明した場合、前記第１のクラスタから前記第２のクラスタに中継される中継フレームの中継に使用する第２の中継装置を、前記第２のクラスタ中に位置する隣接ノード装置に決定し、
    前記隣接ノード装置に、前記第２の中継装置に決定したノード装置を識別する情報を通知するために用いる通知フレームを送信する
    処理を、前記第１のクラスタ中のノード装置に行わせることを特徴とする通信プログラム。
11. 前記選択装置に設定された場合、
    前記第１グループ中のノード装置のうちで、通信可能なクラスタ数が相対的に大きいノード装置を前記第１の中継装置として選択し、
    前記第１の中継装置に設定されているノード装置よりも通信可能なクラスタ数が大きいノード装置が通知されると、通知されたノード装置を前記第１の中継装置に選択することにより、前記第１の中継装置を変更する
    処理をさらに、前記第１のクラスタ中のノード装置に行わせることを特徴とする請求項１０に記載の通信プログラム。
12. 前記第１の中継装置に選択された場合、
    前記第２のクラスタ中に位置し、かつ、前記第１のクラスタ中のノード装置に通信可能なノード装置のグループである第２グループに含まれ、かつ、前記第１の中継装置に隣接するノード装置の中から、通信可能なクラスタ数が相対的に大きいノード装置を前記第２の中継装置に決定し、
    前記第２の中継装置として決定されているノード装置よりも通信可能なクラスタ数が大きいノード装置が通知されると、通知されたノード装置を前記第２の中継装置に決定することにより、前記第２の中継装置を変更する
    処理をさらに、前記第１のクラスタ中のノード装置に行わせることを特徴とする請求項１０または１１に記載の通信プログラム。
13. 前記第１の中継装置に選択された場合、
    前記第２の中継装置に決定したノード装置に障害が発生すると、前記第１の中継装置が前記第２のクラスタ中のノード装置に隣接しないノード装置となったかを判定し、
    前記第１の中継装置が前記第２のクラスタ中のノード装置に隣接しないノード装置となった場合、前記第２のクラスタに隣接していないことを前記選択装置に通知する
    処理をさらに、前記第１のクラスタ中のノード装置に行わせることを特徴とする請求項１０〜１２のいずれか１項に記載の通信プログラム。
14. 隣接するノード装置である隣接ノード装置から、フレームを受信する受信部と、
    第１のクラスタ中のノード装置と、前記第１のクラスタに隣接する第２のクラスタ中のノード装置の間の通信を中継する第１の中継装置を前記第１のクラスタ中のノード装置から選択する選択装置の特定を行う特定部と、
    前記選択装置として特定された場合、前記第１のクラスタ中に位置し、かつ、前記第２のクラスタ中のノード装置に通信可能なノード装置のグループである第１グループから、前記第１の中継装置を選択し、前記第１の中継装置に決定されたノード装置を識別する情報を前記第１グループ中の他のノード装置へ送信する送信部と、
    前記第１の中継装置に決定されたノード装置を識別する情報の受信により前記選択装置から前記第１の中継装置に選択されたと判明した場合、前記第１のクラスタから前記第２のクラスタに中継される中継フレームの中継に使用する第２の中継装置を、前記第２のクラスタ中に位置する隣接ノード装置に決定する決定部と、
    を備え、
    前記送信部は、更に、前記隣接ノード装置に、前記第２の中継装置に決定したノード装置を識別する情報を通知するために用いる通知フレームを送信する
    ことを特徴とするノード装置。
15. 前記選択装置の選択部は、
    前記第１グループ中のノード装置のうちで、通信可能なクラスタ数が相対的に大きいノード装置を前記第１の中継装置として選択し、
    前記第１の中継装置に設定されているノード装置よりも通信可能なクラスタ数が大きいノード装置が通知されると、通知されたノード装置を前記第１の中継装置に選択することにより、前記第１の中継装置を変更する
    ことを特徴とする請求項１４に記載のノード装置。
16. 前記第１の中継装置の決定部は、
    前記第２のクラスタ中に位置し、かつ、前記第１のクラスタ中のノード装置に通信可能なノード装置のグループである第２グループに含まれ、かつ、前記第１の中継装置に隣接するノード装置の中から、通信可能なクラスタ数が相対的に大きいノード装置を前記第２の中継装置に決定し、
    前記第２の中継装置として決定されているノード装置よりも通信可能なクラスタ数が大きいノード装置が通知されると、通知されたノード装置を前記第２の中継装置に決定することにより、前記第２の中継装置を変更する
    ことを特徴とする請求項１４または１５に記載のノード装置。
17. 前記第１の中継装置の決定部は、前記第２の中継装置に決定したノード装置に障害が発生すると、前記第１の中継装置が前記第２のクラスタ中のノード装置に隣接しないノード装置となったかを判定し、
    前記第１の中継装置が前記第２のクラスタ中のノード装置に隣接しないノード装置となった場合、前記第１の中継装置の通知生成部は、前記第２のクラスタに隣接していないことを示す情報を前記通知フレームに含める
    ことを特徴とする請求項１４〜１６のいずれか１項に記載のノード装置。

Images