JP3963391B2 - ジグビーネットワークにおけるマルチキャスト方法 - Google Patents

Description

本発明は、ジグビーネットワーク、特に、ジグビーネットワークを構成している複数のノードのうち、一部のノードから構成されたマルチキャストグループにマルチキャストデータパケットを送信する方法に関する。

ジグビーアライアンス(ＺｉｇＢｅｅ Ａｌｌｉａｎｃｅ）とは、ＩＥＥＥ８０２.１５.４規格に基盤をおいた効率的な費用、低い電力消費などが可能な無線ネットワークを実現するために共同で研究する会社で構成される組織である。

前記ジグビーネットワークのユニキャストルーティングプロトコルは、クラスターツリー（ｃｌｕｓｔｅｒ ｔｒｅｅ）プロトコルと、ＡＯＤＶ（Ａｄ ｈｏｃ Ｏｎ Ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ）プロトコルとから構成される。一般に、前記ジグビーネットワークは、ユニキャストルーティングプロトコルはサポートするが、マルチキャストルーティングプロトコルはサポートしない。しかし、前記ジグビーネットワークにおいて、センサネットワークを效率よくサポートするための方法としてマルチキャストの概念が注目されている。

図１は、複数のノードから構成された一般的なジグビーネットワークを示している。以下、前記図１を利用して、複数のノードから構成されたジグビーネットワークにおいて、データパケットを送信する過程について述べる。前記ジグビーネットワークは、ノードＡないしノードＭから構成される。前記ノードＡは、前記ジグビーネットワークを構成しているノードを管理するジグビーコーディネイター(ＺｉｇＢｅｅ Ｃｏｏｒｄｉｎａｔｏｒ：以下、「ＺＣ」と記す)である。前記ノードＢないしノードＭは、前記ノードＡの管理下でデータパケットを送受信する。

以下、前記マルチキャストルーティングプロトコルが必要な理由について述べる。前記ノードＡが、ノードＣ、ノードＥ、ノードＧ、ノードＨ、ノードＩに同じデータパケットを送信すると仮定する。この場合、前記ノードＡは、前記データパケットをユニキャストに送信したり、マルチキャストに送信したりできる。すなわち、前記ノードＡは、前記ノードＣのアドレスを送信先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓ）に設定したデータパケットをユニキャストする。また、ノードＡは、前記ノードＥのアドレスを送信先アドレスに設定したデータパケットをユニキャストする。このように、ノードＡは、データパケットを順次にユニキャストすることにより、前記ノードＣ、ノードＥ、ノードＧ、ノードＨ、ノードＩに同じデータパケットを(異なる送信先アドレスで)送信する。

第２の方法として、前記ノードＡがジグビーコーディネイターを構成しているノードに前記データパケットをブロードキャストする方法がある。この場合、前記ノードＡは、前記データパケットの送信先アドレスをブロードキャストパケットであることを意味するアドレスに設定する。したがって、前記ジグビーコーディネイターを構成しているノードＢないしノードＭは、前記ノードＡからデータパケットを受信する。しかし、前記ノードＢ、ノードＤ、ノードＦ、ノードＪないしノードＭは、受信したデータパケットが不必要なので、前記データパケットを廃棄する。

このように、従来、ジグビーネットワークを構成している複数のノードのうちの一部ノードにパケットを送信する２つの方法は短所を有している。すなわち、ユニキャストにパケットを送信する場合、送信ノードは、送信先アドレスだけが異なるパケットを複数回にわたって送信しなければならない。また、ブロードキャストに送信する場合、所望しないノードがパケットを受信するので、負荷の増加をもたらす。

そこで、本発明は、前記問題点を解決するためになされたものであって、その目的は、ジグビーネットワークを構成しているノードのうちの特定グループを構成しているノードにデータパケットを效率的に送信できる方法を提案することにある。

本発明の他の目的は、ジグビーネットワークを構成しているノードが最小限の情報だけを利用して前記データパケットを送信することにより、前記情報を格納するメモリの大きさを減少させることができる方法を提案することにある。

本発明のさらに他の目的は、ジグビーネットワークを構成している各ノードが同じデータパケットを重複して送信することにより発生する負荷を減少させることのできる方法を提案することにある。

なお、本発明のさらに他の目的は、グループを構成しているノードに送信するデータパケットが前記グループの外部に送信されることを防止できる方法を提案することにある。

そこで、本発明は、複数のノードから構成されたジグビーネットワークにおいて、前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、前記副マルチキャストルータが前記マルチキャストグループに加入を要請する場合、自分の状態を前記マルチキャストコーディネイターに変更することを特徴とするジグビーネットワークの管理方法を提案する。

本発明の第１の態様によれば、マルチキャストルーティングテーブルを使用せずにビットマップを使用することにより、メモリの大きさを減らすことができ、かつ、マルチキャストパケットデータをマルチキャストグループを構成しているノードだけに送信することにより、前記パケットデータを迅速に送信できる。また、重複してデータを送信するのを防止することにより、各ノードの負荷を減らすことができる。

また、本発明の第２の態様によれば、ルーティングテーブルの代わりに子孫ノードの個数をカウントすることにより、メモリの大きさを減らすことができ、父ノードだけからデータパケットを受信することにより、重複してデータパケットが送信されることを防止できる。

さらに、本発明の第３の態様によれば、１バイト(マルチキャストグループアドレスは除外)から構成されたＭＲＴを提案することにより、メモリの大きさを減らすことができることは勿論、父ノードからデータパケットを受信することにより、重複してデータパケットが送信されることを防止できる。また、リアルタイムでマルチキャストグループを更新することにより、常に最小大きさのマルチキャストグループを構成できる。

以下、添付図面を参照して本発明の実施形態に係るジグビーネットワークを構成しているノードで行われる動作について詳細に説明する。

本発明は、ジグビーネットワークを構成しているノードのうち、少なくとも２つのノードから構成されたマルチキャストグループを提案している。前記マルチキャストグループを構成しているノードは、同じマルチキャストグループアドレス(Ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ａｄｄｒｅｓｓ)を割り当てられる。以下、マルチキャストグループアドレスを割り当てる過程について述べる。

第１の方法は、ネットワーク階層アドレスの一部領域をマルチキャストグループアドレス領域として用いる方法である。前記ネットワーク階層アドレスは、１６ビットの個人領域ネットワーク識別子(Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ(ＰＡＮ)ＩＤ)と、１６ビットのノードＩＤとから構成される。

以下、ＰＡＮ ＩＤを利用してマルチキャストグループアドレスを割り当てる方法について述べる。１６ビットのアドレス領域を２つの領域に区分する。一例として、前記１６ビットからなる領域は、４ビットからなる第１領域と、１２ビットからなる第２領域とに区分する。前記第１領域を構成している４ビットを利用して、第１マルチキャストグループアドレスを割り当てる。すなわち、１６個の場合の数のうち、１つの数を選択し、第１マルチキャストグループアドレスに割り当てる。前記第１マルチキャストグループアドレスは、固定される。次いで、第２領域を構成している１２ビットを利用して、第２マルチキャストグループアドレスを割り当てる。前記第２マルチキャストグループアドレスの数は、全て４０９５(ブロードキャストのため、１つを除外する)個である。前記マルチキャストグループアドレスは、第１マルチキャストグループアドレスと第２マルチキャストグループアドレスとを組み合わせて生成する。

第２の方法は、ジグビーネットワーク階層ヘッダのブロードキャストアドレスビットを使用する方法である。すなわち、ブロードキャストアドレスビットに送信先アドレスが設定されていなければ、通常のブロードキャストデータパケットとして取り扱い、送信先アドレスが設定されていれば、マルチキャストデータパケットとして取扱う。

図２は、本発明の実施形態に係る複数のノードから構成されたジグビーネットワークを示している。以下、図２に基づいて、ジグビーネットワークを構成しているノードの役割について説明する。

前記図２に示されているジグビーネットワークもまた、前記図１と同様にノードＡないしノードＭから構成されている。前記ノードＡは、ジグビーコーディネイター(ＺＣ)である。前記ＺＣは、前記ジグビーネットワークを構成しているノードの情報を格納しており、格納している情報を利用して前記ノードを管理する。また、前記ノードＡは、前記ジグビーネットワークを構成している少なくとも２つのノードがマルチキャストグループを形成している場合、前記マルチキャストグループに対するマルチキャストグループ情報を管理する。すなわち、前記ノードＡは、前記マルチキャストグループを構成しているノードのアドレス、前記ノードの位置(クラスターツリー上での位置)についての情報を管理する。前記ノードＡは、少なくとも１つのマルチキャストグループを管理する。もちろん前記ノードＡもまた前記マルチキャストグループに加入できるが、前記図２に示されているノードＡは、マルチキャストグループに加入していない。

ノードＢは、副−マルチキャストルータ(Ｓｕｂ−Ｍｕｌｔｉｃａｓｔ Ｒｏｕｔｅｒ：以下、「ＭＲ′」と記す)である。前記ＭＲ′は、クラスターツリー上において、後述するグループコーディネイター(Ｇｒｏｕｐ Ｃｏｏｒｄｉｎａｔｏｒ：以下、「ＧＣ」と記す)とＺＣとの間に位置しているノードを意味する。すなわち、前記クラスターツリー上において、ＺＣの深さ(ｄｅｐｔｈ)より小さな深さを有するノードを意味する。すなわち、前記ノードＢは、ツリーの下方にマルチキャストグループがあることを認知しており、ＺＣとＧＣとを中継する役割を行なう。

ノードＣは、ＧＣである。前記ＧＣは、マルチキャストグループを管理するノードである。したがって、前記ＧＣは、マルチキャストグループを管理できる位置にあるノードに選択される。すなわち、前記ＧＣは、クラスターツリー上において、マルチキャストグループの上端の境界となる。前記ノードＣは、前記マルチキャストグループを構成しているノードのマルチキャスト情報を格納しており、格納している情報に基づいて前記ノードを管理する。すなわち、前記ノードＣは、前記マルチキャストグループを構成しているノードのアドレス、前記ノードの位置に対する情報を管理する。前記ＧＣは、前記マルチキャストグループのメンバであるが、マルチキャストグループに加入を要請しないノードであってもよい。すなわち、前記ノードＣは、必要に応じて単独でＧＣの役割だけを行なうことができる。

ノードＤは、マルチキャストルータ(Ｍｕｌｔｉｃａｓｔ Ｒｏｕｔｅｒ：以下、「ＭＲ」と記す)である。前記ＭＲは、マルチキャストグループに加入を要請しないノードのうち、クラスターツリー上においてＧＣとグループメンバー(ｇｒｏｕｐ ｍｅｍｂｅｒ：以下、「ＧＭ」と記す)との間に位置しているノードである。すなわち、前記ＭＲは、マルチキャストグループを構成しているノードを相互接続する役割を果たす。図２に示すとおり、前記ノードＥはＧＭであり、前記ノードＣはＧＣである。もちろん、クラスターツリー上でＧＭとＧＭとの間に位置しているノードもＭＲの役割を果たす。

ノードＥ、ノードＧ、ノードＨ、ノードＩは、ＧＭである。前記ＧＭは、マルチキャストグループに加入を要請した(構成している)ノードである。ノードＦ、ノードＪないしノードＭは、マルチキャストメンバーでないノードを意味する。

以下、本発明に係るジグビーネットワークを構成しているノードで行なう動作について実施形態を挙げて詳細に述べる。

−第１実施形態−
１.マルチキャストグループの加入
１)マルチキャストグループに加入しようとするノード(以下、「加入ノード」と記す)は、自分の状態を分析する。前記自分の状態がＭＲ、ＭＲ′、ＺＣでなければ、前記加入ノードは父ノードに加入要請メッセージ(Ｊｏｉｎｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ)を送信する。前記自分の状態がＭＲであれば、前記加入ノードは、自分の状態をＭＲからＧＭへ変更することにより加入手順を終了する。

前記自分の状態がＺＣまたはＭＲ′であれば、前記加入ノードは、自分の状態をＧＣに変更する(ノードＢが加入を要請する場合)。また、前記ＧＣ状態に変更した加入ノードは、ＧＣ更新メッセージ(ＧＣ Ｕｐｄａｔｅ Ｍｅｓｓａｇｅ)を生成する。前記ＺＣに変更した加入ノードは、前記ＧＣ更新メッセージをクラスターツリーの下方に送信し、前記マルチキャストグループの新しいＧＣとなる。現在のＧＣは、前記新しいＧＣが送信したＧＣ更新メッセージを受信することにより、ＧＣの役割をあきらめ、ＧＣ更新メッセージの再送信を中断する(ノードＣがノードＢからＧＣ更新メッセージを受信した場合)。

２)子ノードから加入要請メッセージを受信した父ノードは、格納している隣接ノードリストから前記子ノードに割り当てるマルチキャストグループアドレスがあるか否かをチェックする。すなわち、前記父ノードの状態がＧＭ、ＭＲ、ＭＲ′、ＧＣであれば、前記父ノードは、前記子ノードに割り当てるマルチキャストグループアドレスがあることを認知するようになり、前記マルチキャストグループアドレスが含まれた加入応答メッセージ(Ｊｏｉｎｉｎｇ Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ)を送信する(ノードＦが送信した加入要請メッセージをノードＤが受信した場合)。前記父ノードの状態がＧＭ、ＭＲ、ＭＲ′、ＧＣでない場合、すなわち、マルチキャストグループのメンバーでなければ、前記加入要請メッセージを自分の父ノードに送信する(ノードＬが送信した加入要請メッセージをノードＫが受信した場合)。上述した過程は、加入要請メッセージがＧＭ、ＭＲ、ＭＲ′、ＧＣ、ＺＣに到達するまで繰り返し行われる。

３)加入要請メッセージが前記ＺＣに到達すると、前記加入ノードは、マルチキャストグループに加入を要請した最初のノードとなる(ノードＬが送信した加入要請メッセージがノードＫ、ノードＪを経てノードＡに到達した場合)。したがって、前記ＺＣは、前記加入ノードのためにマルチキャストグループアドレスを生成し、前記生成したマルチキャストグループアドレスが含まれた加入応答メッセージをクラスターツリーに沿って前記加入ノードに送信する。もちろん、前記加入応答メッセージは、前記加入ノードがＧＣの役割を行なうように指示するために、ＧＣフラグ(ＧＣ ｆｌａｇ)を設定する。

４)加入応答メッセージを受信した加入ノードは、ＧＣフラグが設定されているか否かをチェックし、ＧＣフラグが設定されていれば、ＧＣの役割を行なう。ＧＣフラグが設定されていない場合は、前記加入ノードは、マルチキャストクラスターツリーを探すためにルーティングを行い、前記遂行結果、探索された父ノードからマルチキャストグループアドレスを割り当てられる。

５)前記加入ノードは、マルチキャストグループを探索するために設定された回数(Ｍａｘ Ｊｏｉｎ Ａｔｔｅｍｐｔｓ Ｔｉｍｅｓ)だけ加入要請メッセージを送信する。すなわち、加入要請メッセージに対する加入応答メッセージが受信されなくても、前記加入ノードは設定された回数だけ一定周期間隔で加入応答メッセージを繰り返し送信する。

以下、図３に基づいて、本発明に係る加入ノードを含むジグビーネットワークについて述べる。

前記図３において、ノードＥ、ノードＨおよびノードＬが、マルチキャストグループに加入を要請する。

前記ノードＥは、前記ノードＤに加入要請メッセージを送信する（段階Ｓ３００）。前記ノードＤはＭＲであるから、前記ノードＥが加入しようとするマルチキャストグループのマルチキャストグループアドレスを認知している。したがって、前記ノードＤは、マルチキャストグループアドレスが含まれた加入応答メッセージを前記ノードＥに送信する（段階Ｓ３０２）。

ノードＨは、ノードＧに加入要請メッセージを送信する（段階Ｓ３１０）。前記ノードＧは、マルチキャストグループアドレスを認知していないので、受信した加入要請メッセージをノードＢに送信する（段階Ｓ３１２）。前記ノードＢは、マルチキャストグループアドレスを認知しているので、加入応答メッセージをノードＧに送信する（段階Ｓ３１４）。前記ノードＧは、受信した加入応答メッセージをノードＨに送信する（段階Ｓ３１６）。もちろん、前記加入応答メッセージを受信した前記ノードＧは、状態をＭＲに変更する。段階Ｓ３２０ないし段階Ｓ３２６は、前記段階Ｓ３１０ないし段階Ｓ３１６と同様に行われる。

２.マルチキャストグループの脱退
１)マルチキャストグループを脱退しようとするノード(以下、「脱退ノード」という）は、自分がリーフ(ｌｅａｆ)ノードであるか否かを判断する。前記判断の結果、リーフノードであれば、前記脱退ノードは父ノードに脱退要請メッセージ(Ｌｅａｖｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ)を送信する。前記判断結果、リーフノードでなければ、前記脱退ノードは自分の状態をＧＭからＭＲに変更する。すなわち、前記脱退ノードは、マルチキャストグループのルータの役割を行う。

２)子ノード(脱退ノード)から脱退要請メッセージを受信した父ノードは、前記子ノードに脱退応答メッセージ(Ｌｅａｖｉｎｇ Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ)を送信する。前記父ノードは、前記脱退ノードに関するマルチキャストグループ情報を削除する。

３)脱退要請メッセージを送信した子ノードの状態がＭＲである場合、前記父ノードは、マルチキャストグループにおいてリーフノードであるか否かを判断する。前記判断の結果、リーフノードであれば、前記父ノードはマルチキャストクラスターツリーの不必要な部分を除去するために、自分の父ノードに脱退要請メッセージを送信する。これについては、図４に基づいて詳細に述べる。

４)子ノードの脱退によりマルチキャストグループ内に単一の子ノードのみを有するようになれば、ＧＣは、自分の状態がＧＭであるか否かを判断する。前記判断の結果、自分の状態がＧＭでなければ、前記ＧＣはＧＣの役割をあきらめる。

５)マルチキャストグループ内のすべての子ノードが脱退すれば、前記ＧＣもマルチキャストグループを脱退する。この場合、前記ＧＣは、全てのＭＲ′とＺＣに脱退要請メッセージを送信し、全てのマルチキャストグループ情報を削除する。

図４は、本発明の第１実施形態に係るマルチキャストグループからの脱退を要請したノードを含むジグビーネットワークを示している。ノードＥは、マルチキャストグループを脱退するために、ノードＤに脱退要請メッセージを送信する（段階Ｓ４００）。前記ノードＤは、ＭＲであるから、前記ノードＥに脱退応答メッセージを送信する（段階Ｓ４０２）。前記ノードＤは、前記ノードＥが脱退することで、マルチキャストグループにおいてリーフノードであることを認知するようになる。

したがって、前記ノードＤは、マルチキャストグループを脱退するために、ノードＣに脱退要請メッセージを送信する（段階Ｓ４０４）。前記ノードＣは、前記ノードＤに脱退応答メッセージを送信する（段階Ｓ４０６）。また、前記ノードＣは、自分の状態がＧＭであるか否かを判断する。前記判断の結果、前記ノードＣの状態がＧＭでなければ、前記ノードＣは、ＧＣの役割を中断するために、ＧＣ更新メッセージを生成する。

前記ノードＣは、前記ＧＣ更新メッセージをノードＧに送信し（段階Ｓ４０８）、前記ノードＧは、受信したＧＣ更新メッセージをノードＨに送信する（段階Ｓ４１０）。前記ＧＣ更新メッセージを送信したノードＣは、自分の状態をＧＣからＭＲ′に変更し、ノードＧは、自分の状態をＭＲからＭＲ′に変更する。前記ＧＣ更新メッセージを受信したノードＨは、自分の状態をＧＭからＧＣに変更する。

３.グループメンバーのマーキング(ｍａｒｋｉｎｇ)
加入と脱退の過程を行なうことでマルチキャストグループを構成している各ノードは、マルチキャストクラスターツリーを更新しなければならない。前記マルチキャストクラスターツリーに接続しているノードに対する情報を記録するために、各ノードはビットマップを使用する。前記ビットマップを利用して、各ノードは自分と接続しているノードについてその状態がＧＭ、ＧＣ、ＭＲであるノードをマーキングする。Ｃｍ(最大子ノードの個数)に依存するビットマップは、８/１６/３２ビットから構成される。すなわち、前記ビットマップのビット数は、Ｃｍの大きさより１だけ大きい。

前記ビットマップのビット０は、父ノードを意味し、ビットｎは、ｎ番目の子ノードを意味する。例えば、ビットマップのビット０、２、５が１とマーキングされていれば、父ノード、２番目の子ノード、５番目の子ノードの状態はＧＭ、ＭＲ、ＧＣのうちのいずれかである。このようにビットマップを使用することにより、各ノードはマルチキャストクラスターツリーに接続しているノードを記録するためのメモリ空間を減らすことができるようになる。すなわち、一般的に、ノードのアドレスは１６または３２ビットであるので、接続しているノードの個数に比例してメモリ空間が必要となる。しかし、ビットマップを使用する場合、１つのビットマップを使用して８個のノードをマーキングすることができる。すなわち、マルチキャストルーティングテーブルの代わりにビットマップを使用することにより、メモリ空間を減らすことができる。

４.ＧＣの役割を行なうノードの移転(Ｍｉｇｒａｔｉｏｎ)
ＧＣの役割は、マルチキャストパケットがマルチキャストクラスターツリーの外部に送信されることを防止することである。したがって、前記ＧＣによりマルチキャストクラスターツリーの上段の境界が設定される。しかし、前記マルチキャストクラスターツリーの上段は、固定されておらず、マルチキャストグループの加入または脱退するノードにより流動的である。以下、ＧＣの役割を行なうノードが移転される場合について述べる。

１)新しいＧＭのマルチキャストグループの加入
図５は、本発明の第１実施形態において、新しいＧＭがマルチキャストグループに加入を要請した場合、ＧＣの役割を果たすノードが移転される場合のメッセージの流れを示している。図５においては、ノードＤがＧＣの役割を行なっており、ノードＢ、ノードＣがＭＲ′の役割を行う。

図５において、ノードＪは、マルチキャストグループに加入を要請した加入ノードである。したがって、前記ノードＪは、加入要請メッセージをノードＩに送信する（段階Ｓ５００）。前記ノードＩは、受信した加入要請メッセージをノードＨに送信する（段階Ｓ５０４）。前記ノードＨは、受信した加入要請メッセージをノードＢに送信する（段階Ｓ５０８）。前記ノードＢは、マルチキャストグループアドレスを認知しているので、加入応答メッセージを生成し、前記生成した加入応答メッセージを前記ノードＨに送信する（段階Ｓ５１０）。前記ノードＨは、受信した加入応答メッセージを前記ノードＩに送信し（段階Ｓ５０６）、前記ノードＩは、受信した加入応答メッセージをノードＪに送信する（段階Ｓ５０２）。上述した過程を行なうことにより、前記ノードＪは、マルチキャストグループに加入することになる。もちろん、前記ノードＨ、ノードＩは、自分の状態をＭＲに変更する。

前記加入応答メッセージを送信したノードＢは、ＧＣ更新メッセージを生成し、前記生成したＧＣ更新メッセージを前記ノードＣに送信する（段階Ｓ５１２）。前記ＧＣ更新メッセージを送信したノードＢは、ＧＣの役割を行なうために自分の状態をＧＣに変更する。また、前記ＧＣ更新メッセージを受信したノードＣは、自分の状態をＭＲ′からＭＲに変更する。元の状態がＭＲ′であるノードＣは、受信したＧＣ更新メッセージを前記ノードＤに送信する（段階Ｓ５１４）。すなわち、前記ＧＣ更新メッセージは、現在のＧＣの役割を行なうノードに到達するまで順次に送信される。現在のＧＣであるノードＤは、前記ＧＣ更新メッセージを受信することにより、ＧＣの役割を中断する。前記ＧＣの役割を中断したノードＤは、元の状態がＧＭである場合、ＧＭに変更、元の状態がＧＭでない場合にはＭＲに変更する。

２)現在ＧＣの役割を行なうノードの脱退
前記ＧＣの役割を行なうノードが脱退する場合は、ＧＭ状態であると同時に、ＧＣ役割を行なうノードが脱退する場合と、ＧＭ状態でないＧＣ役割を行なうノードが子ノードの脱退によってマルチキャストグループ内に１つの子ノードのみを有することになった場合との２つの場合に区分される。これらの場合、前記ＧＣ役割を行なうノードは、マルチキャストグループに対するＧＣの役割をあきらめる。以下、図６に基づいて、前記現在ＧＣの役割を行なうノードの脱退が要求されるジグビーネットワークについて述べる。図６において、ノードＣがＧＣの役割を行なう。

ノードＥは、マルチキャストクラスターツリーに沿って前記ノードＤに脱退要請メッセージを送信する（段階Ｓ６００）。前記脱退要請メッセージを受信したノードＤは、前記ノードＥに脱退応答メッセージを送信する。前記脱退応答メッセージを送信したノードＤは、自分の元の状態をチェックする。自分の元の状態がＧＭであったならば、前記ノードＤは、自分の状態をＧＭに変更する。

一方、前記図６に示されているように、前記ノードＤは、元来、非マルチキャストグループノード(ｎｏｎ−ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ｎｏｄｅ)であるが、ノードＥによってＭＲの役割を行なっていた。また、前記ノードＤは、マルチキャストグループ内に子ノードがないことを認知するようになるので、ノードＣに脱退要請メッセージを送信する（段階Ｓ６０４）。前記ノードＣは、前記ノードＤに脱退応答メッセージを送信する（段階Ｓ６０６）ことにより、前記ノードＤは、非マルチキャストグループノードに変更される。

前記脱退応答メッセージを送信したノードＣは、自分の元の状態をチェックする。自分の元の状態がＧＭであったならば、前記ノードＣは、ＧＣの役割を続けて行う。しかし、前記ノードＣの元の状態がＧＭでなく、マルチキャストグループ内の子ノードが１つであれば、前記ノードＣは、これ以上ＧＣの役割を行なう必要がない。したがって、前記ノードＣは、自分の状態を非マルチキャストグループノードに変更した後、生成したＧＣ更新メッセージをノードＦに送信する（段階Ｓ６０８）。前記ＧＣ更新メッセージを受信したノードＦは、自分と接続しているマルチキャストグループを構成している子ノードの個数をチェックする。前記マルチキャストグループを構成している子ノードの個数が少なくとも２つであれば、前記ノードＦは自分の状態をＧＣに変更した後、メッセージの伝達を終了する。前記マルチキャストグループを構成している子ノードの個数が１つであれば、前記ノードＦは、自分の状態を非マルチキャストグループノードに変更した後、段階Ｓ６１０で受信したＧＣ更新メッセージをノードＧに送信する。前記ノードＧもまた自分と接続しているマルチキャストグループを構成している子ノードの個数をチェックする。図６において、前記マルチキャストグループを構成している子ノードの個数が２つ(ノードＨ、ノードＩ)であるから、前記ノードＧは、自分の状態をＭＲからＧＣに変更する。

５.マルチキャストグループの解体
マルチキャストグループに関連した該当動作が完了したならば、マルチキャストグループを構成しているノードのうちのいずれかがグループ解体メッセージ(Ｇｒｏｕｐ Ｄｉｓｍｉｓｓ Ｍａｓｓａｇｅ)を生成する。前記ノードのアプリケーション階層(ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ)は、前記生成したグループ解体メッセージが正確なものであるか否か(エラーであるか否か)を決定する。前記生成したグループ解体メッセージは、マルチキャストグループを構成している全てのノードに送信される。前記グループ解体メッセージを受信したノードは、全てのマルチキャストグループ情報を削除する。前記グループ解体メッセージは、上述したＧＭの脱退過程と同一に処理することにより、制御トラフィックを減少させることができる。

６.データパケット送信メカニズム
アプリケーション階層からマルチキャストデータパケットの送信が要請されれば、送信元（ｓｏｕｒｃｅ）ノードのネットワーク階層は、ネットワークヘッダの送信先アドレスをマルチキャストアドレスに設定する。また、ＭＡＣ層(ＭＡＣ ｌａｙｅｒ)は、マックフレームの送信先アドレスをブロードキャストアドレスに設定する。送信元ノードのＭＡＣ層は、送信先アドレス(ディスティネーションＰＡＮ ＩＤ)とマックアドレスとを設定したパケットをブロードキャストする。

隣接ノードのＭＡＣ層は、前記ブロードキャストパケットを受信してネットワーク階層に送信する。前記ネットワーク階層は、ブロードキャストアドレスと、ネットワークヘッダにある送信先アドレスとをチェックすることによって、マルチキャストデータパケットの処理が必要であるか否か、必要であれば、どのように処理するかを決定する。以下、データパケットを受信したノードで行われる動作について詳細に説明する。

１)データパケットを受信したノードがＧＭである場合
受信したデータパケットの以前ホップがマルチキャストクラスターツリー上の隣接ノード(父ノードまたは子ノード)であれば、前記ＧＭは、受信したデータパケットを上位階層に送信する。受信したデータパケットの以前ホップがマルチキャストクラスターツリー上の隣接ノードでなければ、受信したデータパケットを再ブロードキャストする。しかし、前記ＧＭがリーフノードであれば、受信したデータパケットを再ブロードキャストしない。

２)データパケットを受信したノードがＭＲである場合
前記ＭＲは、受信したデータパケットを上位階層に送信しない。前記ＭＲの残りの動作は、前記ＧＭで行なう動作と同じである。

３)データパケットを受信したノードがＭＲ′またはＺＣである場合
受信したデータパケットの以前ホップ（Ｐｒｅｈｏｐ）がマルチキャストクラスターツリー上の子ノードでなければ、前記ＭＲ′またはＺＣは、受信したデータパケットをマルチキャストクラスターツリー上の子ノードにユニキャストする。すなわち、前記ＭＲ′またはＺＣは、受信したデータパケットをマルチキャストグループに送信する。また、前記受信したデータパケットの以前ホップがマルチキャストクラスターツリー以外の子ノードであれば、前記ＭＲ′またはＺＣは、受信したデータパケットをマルチキャストクラスターツリー上の子ノードにユニキャストする。

一方、受信したデータパケットの以前ホップがマルチキャストクラスターツリー上の子ノードであれば、前記ＭＲ′またはＺＣは、受信したデータパケットを廃棄する。すなわち、前記ＭＲ′またはＺＣは、受信したデータパケットがマルチキャストグループの外部に送信されることを防止する。これは前記ＧＣがブロードキャストしたデータパケットを父ノードのＭＲ′が受信する場合に発生する。

４)その他(データパケットを受信したノードが非マルチキャストグループノードである場合)
非マルチキャストグループノードは、受信したデータパケットをマルチキャストグループに送信するために、ＺＣに向かってマルチキャストクラスターツリー上の父ノードに送信する。前記ＺＣに向かって送信する途中で、ＭＲ′に出会うと、前記ＭＲ′は、受信したデータパケットをＺＣに送信せずに、マルチキャストクラスターツリーの子ノードに送信する。

７.データパケットの重複送信を防止するための方法
１)マルチキャスト送信記録(Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｒｅｃｏｒｄ：ＭＴＲ)
各ノードは、マルチキャスト送信テーブル(Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓａｃｔｉｏｎ Ｔａｂｌｅ：ＭＴＴ)を保有する。前記ＭＴＴの項目は、前記ＭＴＲであるマルチキャストアドレス(送信先アドレス)、送信元アドレス、パケットのシーケンス番号などを含む。ノードのネットワーク階層は、マルチキャストグループのために、２バイトのマルチキャストグループアドレス、２バイトの送信元アドレス、１バイトのパケットのシーケンス番号(ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ)を割り当てることができる。もし、ＰＡＮ ＩＤを使用するならば、前記マルチキャストグループアドレスと、送信元アドレスとは、４バイト以上を必要とする。前記各ノードは、受信したパケットの情報とＭＴＴの情報とを比較することにより、パケットの重複送信、重複受信を防止できる。

しかし、前記方法はメモリを使用するため、ＲＮ−ノードには適合しない。前記ＲＮ−ノードは、メモリの大きさ(容量)が制限されているノードを意味する。

２)ビットマップを利用する方法
ビットマップを利用する方法は、ビットマップの長さが最大１バイト(Ｃｍ≦７)である場合に使用する。ノードは、ネットワークパケットのヘッダを構成しているシーケンス番号フィールド(１バイト)を使用して、ビットマップを送信する。前記シーケンス番号は、受信したパケットを処理する父ノードまたは子ノードに対応するビットマップのビットをチェックする。パケットを受信したノードは、受信したパケットを構成しているビットマップがチェックされているか否かを判断し、ビットマップがチェックされていない場合には、受信したパケットを送信したり、処理せずに廃棄したりすることにより、パケットが重複して送信されることを防止する。前記方法を使用するためには、各ノードは、自分の父ノードの何番目の子ノードであるかを知っていなければならない。前記各ノードは、クラスターツリー構造(ｃｌｕｓｔｅｒ ｔｒｅｅ ｃｏｎｓｔｒｕｃｔｉｏｎ)アルゴリズムにより自分が何番目の子ノードであるかを知ることができる。

前記方法を使用することにより、各ノードはＭＴＴを構成する必要がなく、ネットワーク階層でデータパケットのための余裕空間が不必要となる。しかし、前記方法は、シーケンス番号フィールドが１バイトであるため、ビットマップが１バイトを超過する場合には使用できない。

３)データパケットに以前ホップアドレスを付加して送信する方法
第３の方法は、ビットマップの長さが１バイトを超過する場合にも使用できる方法を提案する。すなわち、ビットマップの長さが１バイトを超過する場合、ネットワークヘッダのシーケンス番号フィールドにビットマップを挿入することができないため、データパケットに以前ホップアドレスを付加して送信される。

ノードは、マルチキャストデータパケットを中継する前に、自分のアドレスを前記パケットに付加する。前記マルチキャストデータパケットを受信したノードは、前記マルチキャストデータパケットを構成しているアドレスをチェックする。前記マルチキャストデータパケットを構成しているアドレスと自分のアドレスとが同一であれば、前記受信ノードは、受信したマルチキャストデータパケットを廃棄する。前記マルチキャストデータパケットを構成しているアドレスと自分のアドレスとが同一でなければ、前記受信ノードは、該当動作を行う。

前記方法は、マルチキャストパケットがマルチキャストクラスターツリー構造に沿って送信される場合に効果がある。前記以前ホップアドレスは、ネットワーク階層のペイロードの一部である２または４バイトを利用して送信される。

８.データパケット送信を向上させるための方法
１)ブロードキャストデータパケットによるオーバーヘッドを減少させるために、マルチキャストクラスターツリー上で隣接ノードの個数が２つより多い場合にだけ、各ノードはマルチキャストデータパケットをブロードキャストしたり再ブロードキャストしたりする。一方、前記ノードは、隣接ノードが２つ以下である場合にはユニキャストを行う。

２)マルチキャストクラスターツリーに沿ってブロードキャストパケットを送信する基本アルゴリズム以外に、前記データパケットを迅速に送信するために兄弟ノード(ｓｉｂｌｉｎｇ ｎｏｄｅ)であるＧＭやＭＲに送信することも可能である。この場合、データパケットの重複送信を防止するためにＭＴＲを使用する。

９.非マルチキャストグループメンバーの動作
１)非マルチキャストグループメンバーは、マルチキャストグループにパケットを送信するものの、前記マルチキャストグループからパケットを受信しない。

２)非マルチキャストグループメンバーは、自分がマルチキャストツリーに接続(ｌｉｎｋ)されていない場合には、ＺＣに向かってパケットをユニキャストする。

３)ＭＲ′またはＺＣでない非マルチキャストグループメンバーは、パケットをユニキャストで受信した場合には、受信したパケットを父ノードに送信する。

４)ＭＲ′またはＺＣは、マルチキャストグループ情報を有しているので、受信したデータパケットをマルチキャストクラスターツリーに沿ってマルチキャストグループにユニキャストする。

−第２実施形態−
ジグビーネットワークを構成しているノードは、メモリの大きさに応じてＲＮ−とＲＮ＋とに区分される。前記ＲＮ−は、前記ＲＮ＋に比べて、相対的に小さなメモリを有する。本発明の第２実施形態は、前記メモリの大きさが小さなＲＮ−でも活用可能なマルチキャスト方法を提案する。前記第２実施形態の基本的な概念は、送信元ノードは生成したマルチキャストデータパケットを最初にＺＣに送信する。

１.マルチキャストグループの加入
各マルチキャストグループのメンバー(ノード)は、子孫マルチキャストグループメンバーの数(Ｎｕｍｂｅｒ ｏｆ ｄｅｓｃｅｎｄａｎｔ ｎｏｄｅｓ：以下、「ＮｕｍＤｅｓＭｅｍ」と記す)を記録する。マルチキャストグループメンバーが記録した前記ＮｕｍＤｅｓＭｅｍが０であれば、前記メンバーはリーフノードである。以下、非マルチキャストグループノードが前記マルチキャストグループに加入を要請する場合について述べる。ＭＲがマルチキャストグループに加入を要請する場合、単純に自分の状態をＧＭに変更すればよい。

１)マルチキャストグループに加入しようとするノードは、ＺＣに加入要請メッセージを送信する。
２)前記ＺＣは、加入要請メッセージを受信した場合、新しいＧＣを計算する。新しいＧＣが現在ＧＣと同一でなければ、前記ＺＣは、ＧＣ更新メッセージを現在ＧＣと新しいＧＣとに送信する。
３)また前記ＺＣは、新しく加入を要請したノードに、マルチキャストクラスターツリー経路に沿って加入応答メッセージを送信する。
４)前記加入応答メッセージを受信したマルチキャストクラスターツリー経路上のノードは、ＮｕｍＤｅｓＭｅｍを１つだけ増加させる。
５)すなわち、ＧＭまたはＭＲが加入応答メッセージを受信すれば、前記ＧＭまたはＭＲはＮｕｍＤｅｓＭｅｍを増加させ、非マルチキャストグループノードＭが加入応答メッセージを受信すれば、ＭＲに変更すると同時にＮｕｍＤｅｓＭｅｍを１に設定する。

２.マルチキャストグループからの脱退
１)マルチキャストグループを脱退しようとするノードは、ＺＣに脱退要請メッセージを送信する。
２)前記ＺＣは、脱退要請メッセージを受信した場合、新しいＧＣを計算する。新しいＧＣが現在ＧＣと同一でなければ、前記ＺＣは、ＧＣ更新メッセージを現在ＧＣと新しいＧＣとに送信する。

３)また、前記ＺＣは脱退を要請したノードに、マルチキャスタークラスターツリー経路に沿って、脱退応答メッセージを送信する。
４)前記脱退応答メッセージを受信したマルチキャストクラスターツリー経路上のノードは、ＮｕｍＤｅｓＭｅｍを１つだけ減少させる。

５)すなわち、ＧＭまたはＭＲが脱退応答メッセージを受信した場合は、前記ＧＭまたはＭＲはＮｕｍＤｅｓＭｅｍを１つだけ減少させる。前記減少によりＮｕｍＤｅｓＭｅｍが０であれば、前記ＧＭまたはＭＲはリーフノードとなり、特に、前記ＭＲは非マルチキャストグループノードとなる。もし、ＧＭが脱退応答メッセージを受信した場合には、前記ＧＭは、ＭＲとなったり(クラスターツリー経路上にＧＭまたはＭＲである子孫ノードがある場合、すなわちＮｕｍＤｅｓＭｅｍが１以上の場合)、非マルチキャストグループノード(ＮｕｍＤｅｓＭｅｍが０の場合)となる。

３.データパケット送信メカニズム
１) 送信元ノードは、マルチキャストデータパケットが生成されれば、前記マルチキャストデータパケットをＺＣに向けてユニキャストする。
２)ＧＣがマルチキャストクラスターツリー経路上でソースノードとＺＣとの間に位置する場合には、前記ＧＣは、送信されたマルチキャストデータパケットを父ノードに送信せずに、マルチキャストクラスターツリーに沿って子ノードにブロードキャストする。

３)ＧＣがマルチキャストクラスターツリー経路上で送信元ノードとＺＣとの間に位置しなければ、前記ＺＣは、ＧＣに前記マルチキャストデータパケットを送信する。前記ＧＣは、送信されたマルチキャストデータパケットをマルチキャストクラスターツリーに沿って子ノードにブロードキャストする。

４)リーフノードが前記マルチキャストデータパケットを受信した場合には、さらなる送信を中断する。ＭＲが前記マルチキャストデータパケットを受信した場合には、前記受信したマルチキャストデータパケットをマルチキャストクラスターツリーに沿って子ノードにブロードキャストする。

５)非マルチキャストグループノードが前記マルチキャストデータパケットを受信した場合には、さらなる送信を中断する。
前記第２実施形態の長所は、父ノードから受信したデータパケットが子ノードにブロードキャストされるため、ＭＴＲなしでもデータパケットが重複して送信されることを防止できるということである。

−第３実施形態−
第３実施形態は、前記第２実施形態に比べてパケットをマルチキャストするために必要なメモリを減少させる方法を提案する。前記第３実施形態は、前記第１実施形態または第２実施形態で提案したＭＲ′の概念は用いない。

１.マルチキャストルーティングテーブル(Ｍｕｌｔｉｃａｓｔ Ｒｏｕｔｉｎｇ Ｔａｂｌｅ：ＭＲＴ)
前記第３実施形態は、マルチキャストアドレスのためのマルチキャストルーティングテーブル(ＭＲＴ)を提案する。図７は、マルチキャストグループアドレス(Ｍｕｌｔｉｃａｓｔ Ｇｒｏｕｐ Ａｄｄｒｅｓｓ)フィールドと、ＧＭフィールドと、ＧＣフィールドと、ＧＭまたはＭＲ状態の子ノードの数フィールドとから構成されるＭＲＴを示す。前記マルチキャストグループアドレスフィールドは、１６ないし３２ビットで構成され、前記ＧＭフィールドとＧＣフィールドとは１ビットで構成される。ノードは、自分の状態がＧＭであれば、ＧＭフィールドをチェックし、自分の状態がＧＣであれば、ＧＣフィールドをチェックする。前記ＧＭまたはＭＲ状態の子ノードの数フィールドは、６ビットから構成される。しかし、前記各フィールドのビット数は、ユーザの設定に応じて変えることができる。前記ＧＭまたはＭＲ状態の子ノードの数は、前記第２実施形態に記載されているＮｕｍＤｅｓＭｅｍと差がある。すなわち、前記ＧＭまたはＭＲ状態の子ノードの数は、マルチキャストクラスターツリー上で子ノードだけをカウントするが、前記第２実施形態に記載されているＮｕｍＤｅｓＭｅｍは、マルチキャストトリー上で子孫ノードをカウントするからである。

図８は、マルチキャストクラスターツリーを構成している各ノードにおいて、ＭＲＴを構成した例を示している。前記図８に示されるように、第３実施形態は、ＭＲ′の概念を使用せず、非マルチキャストグループノードとして取扱う。ノードＤは(ｘｘｘ，１，１，２)であるＭＲＴを構成している。すなわち、前記マルチキャストグループアドレスは「ｘｘｘ」であり、前記ノードＤは、ＧＭであると共にＧＣである。また、前記ノードＤのＧＭまたはＭＲ状態である子ノードの数は、２(ノードＥ、ノードＨ)である。ノードＥは、(ｘｘｘ，０，０，１)であるＭＲＴを構成している。すなわち、前記マルチキャストグループアドレスは「ｘｘｘ」であり、前記ノードＥは、ＧＭ、ＧＣの、いずれでもない。また、前記ノードＤのＧＭまたはＭＲ状態の子ノードの数は、１(ノードＦ)である。

２.マルチキャストグループの加入
図９は、本発明の係る第３実施形態において、マルチキャストグループに加入を要請したノードが含まれているジグビーネットワークを示している。以下、図９に基づいて、マルチキャストグループに加入を要請したノードで行われる動作について述べる。

ノードＦ、ノードＩ、ノードＭは、マルチキャストグループに加入を要請する。もちろん前記ノードは、互いに独立してマルチキャストグループに加入を要請する。したがって、前記ノードＦは、ノードＡ(ＺＣ)に加入要請メッセージを送信するために、クラスターツリーに沿ってノードＥに前記加入要請メッセージをユニキャストする（段階Ｓ９００）。前記ノードＩは、ノードＨに加入要請メッセージをユニキャストし（段階Ｓ９０２）、ノードＭは、ノードＬに加入要請メッセージをユニキャストする（段階Ｓ９０４）。

前記ノードＦから加入要請メッセージを受信したノードＥは、ＭＲＴを格納しているので、受信した加入要請メッセージの再送信を中断する。すなわち、ＭＲＴを格納しているノードは、受信した加入要請メッセージの再送信を中断する。前記ノードＩから加入要請メッセージを受信したノードＨは、ＭＲＴを格納していないため、受信した加入要請メッセージをノードＣ(父ノード)に送信する（段階Ｓ９０６）。前記ノードＭから加入要請メッセージを受信したノードＬは、段階Ｓ９０８で受信した加入要請メッセージをノードＫ(父ノード)に送信する。

前記加入要請メッセージを受信したノードＥ、ノードＣ、ノードＫは、ＭＲＴを更新する。すなわち、ＧＭまたはＭＲ状態である子ノードの数を１つ増加させ、前記加入要請メッセージに対する応答である加入応答メッセージを生成する。前記加入応答メッセージはマルチキャストグループアドレスに関する情報を含む。前記加入応答メッセージは、前記加入要請メッセージを生成したノードに送信される。すなわち、ノードＥは、ノードＦに加入応答メッセージを送信し（段階Ｓ９１０）、ノードＣは、ノードＨに加入応答メッセージを送信する（段階Ｓ９１２）。またノードＫは、ノードＬに加入応答メッセージを送信する（段階Ｓ９１４）。

前記加入応答メッセージを受信したノードＨは、自分の状態をＭＲに変更すると同時にＭＲＴを生成する。前記生成したＭＲＴのＧＭまたはＭＲ状態の子ノードの数は１に設定する。前記ノードＨは、受信した加入応答メッセージをノードＩに送信する。前記ノードＬもまたノードＨと同じ動作を行う。

前記ノードＨは、ノードＩに加入応答メッセージを送信し（段階Ｓ９１６）、前記ノードＬは、ノードＭに加入応答メッセージを送信する（段階Ｓ９１８）。

前記加入応答メッセージを受信したノードＦ、ノードＩ、ノードＭは、自分の状態をＧＭに変更すると同時にＭＲＴを生成する。前記生成したＭＲＴのＧＭまたはＭＲ状態の子ノードの数は０に設定する。

以下では、前記加入要請メッセージがＺＣまで送信される場合について述べる。すなわち、ノードＤがマルチキャストグループに加入を要請する場合を例に挙げて説明する。

ノードＯは、前記ノードＢに加入要請メッセージを送信する（段階Ｓ９２０）。前記ノードＯから加入要請メッセージを受信したノードＢは、受信した加入要請メッセージを段階Ｓ９２２でノードＡ(父ノード)に送信する。前記ノードＡは、前記加入要請メッセージに対する応答である加入応答メッセージを生成し、前記生成した加入応答メッセージをノードＢに送信し（段階Ｓ９２４）、ノードＢは、ノードＡから受信した加入応答メッセージをノードＯに送信する（段階Ｓ９２６）。前記ノードＢで行われる動作は、前記ノードＨで行われる動作と同じであり、前記ノードＯで行われる動作は、前記ノードＩで行われる動作と同じである。前記加入応答メッセージを送信したノードＡは、ＧＣの役割を行なうノードを新しく決定する。

上述したように、ＺＣは、複数のマルチキャストグループについての情報を有している。すなわち、ノードＡは、ノードＢがＧＣの役割を行なうように指示するＧＣ更新メッセージを生成し、前記生成したＧＣ更新メッセージを現在ＧＣ(ノードＣ)と新しいＧＣ(ノードＢ)に送信する。前記ＧＣ更新メッセージを受信したノードＢは、ＧＣの役割を担当するためにＭＲＴの一部の情報を更新する。すなわち、前記ノードＢは、ＧＣフィールドを「１」に設定する。前記ＧＣ更新メッセージを受信したノードＣもまたＭＲＴの一部の情報を更新する。すなわち、前記ノードＣは、ＧＣフィールドを１から０へ変更する。

上述した方法以外に、前記ノードＡは、クラスターツリーに沿って現在ＧＣ(ノードＣ)にＧＣ更新メッセージを送信する。前記ＧＣ更新メッセージは、現在ＧＣのアドレスと新しく加入したメンバー(ノードＯ)のアドレスとを含む。前記ＧＣ更新メッセージを受信したノードＢは、新しく加入したメンバーが自分の子孫ノードであるか否かを判断する。前記判断の結果、前記新しく加入したメンバーが自分の子孫ノードである場合には、前記ノードＢは、前記ＧＣ更新メッセージをノードＣに送信する。

前記ノードＣは、新しく加入したメンバーが自分の子孫ノードでないことを認知するので、前記自分の父ノード(ノードＢ)を新しいＧＣに設定する。また前記ノードＣは、前記ＧＣ更新メッセージをそれ以上送信しない。ただし、前記ノードＣは、自分の父ノードにＧＣ更新確認メッセージ(ＧＣ Ｕｐｇｒａｄｅ ＡＣＫ Ｍｅｓｓａｇｅ)を送信する。前記ＧＣ更新確認メッセージを受信したノードＢは、ＭＲＴを生成し、前記生成したＭＲＴの情報を更新する。もちろん、前記ノードＣもまたＭＲＴを更新する。

３.マルチキャストグループの脱退
１)リーフＧＭは、マルチキャストグループの脱退を要請するために、父ノードに脱退要請メッセージを送信する。前記脱退要請メッセージを受信した父ノードは、ＧＭまたはＭＲ状態である子ノードの数を１つ減少させた後、前記リーフＧＭに脱退応答メッセージを送信する。

２)前記脱退応答メッセージを送信したＭＲの状態がマルチキャストツリー上でリーフノードであれば、前記ＭＲもまた父ノードに脱退要請メッセージを送信する。前記ＭＲの父ノードもまた脱退応答メッセージを前記ＭＲに送信し、ＧＭまたはＭＲ状態の子ノードの数を１つ減少させる。

３)前記マルチキャストグループを脱退したノードによって、自分がマルチキャストグループのリーフノードとなるＭＲは、受信したデータパケットのそれ以上の送信を中断する。

４)前記ＧＭの役割を行なわないＧＣが、マルチキャストグループを脱退したノードＭらによって１つのＧＭまたはＭＲである子ノードのみを有するようになった場合には、そのＧＣはＧＣ更新メッセージを送信する。前記ＧＣ更新メッセージを受信したＧＭは、自分が新しいＧＣの役割を行なう。また、前記ＧＭはＺＣにＧＣが変更されたことを意味するＧＣ更新確認メッセージを送信する。

５)前記ＧＣ更新メッセージを受信したＭＲは、ＭＲまたはＧＭである子ノードの個数を数える。ＧＭまたはＭＲである子ノードが少なくとも２つであれば、前記ＭＲは自分が新しいＧＣの役割を行なう。また、前記ＭＲは、ＺＣにＧＣが変更されたことを意味するＧＣ更新確認メッセージを送信する。ＧＭまたはＭＲである子ノードが１つであれば、前記ＭＲは、前記ＧＣ更新メッセージをＧＭまたはＭＲである子ノードに送信する。

６)マルチキャストグループを脱退したＧＭが子ノードであるＧＭまたはＭＲを１つも有しない場合には、ＭＲＴを削除する。もし、マルチキャストグループを脱退したＧＭが少なくとも１つのＧＭやＭＲを有するようになれば、ＭＲの役割を行なう。

７)子ノードであるＧＭまたはＭＲが全てマルチキャストグループを脱退した場合、ＭＲ(父ノード)はＭＲＴを削除する。

４.データパケット送信のメカニズム
図１０は、本発明の第３実施形態に係るマルチキャストグループにデータパケットを送信する例を示す図面である。

ノードＪは、マルチキャストグループに送信するデータパケットが発生すれば、ノードＨに前記データパケットをユニキャストする（段階Ｓ１０００）。前記ノードＨは、送信されたデータパケットをノードＣにユニキャストする（段階Ｓ１００２）。前記ノードＣは、ＧＣの役割を行なうので、送信されたデータパケットをＺＣにユニキャストしない。その代わりに、前記ノードＣは、送信されたデータパケットを子ノード(ノードＤ、ノードＨ、ノードＬ)にブロードキャストする（段階Ｓ１００４）。

ノードＣからデータパケットを受信したノードＬは、自分の上位階層に前記データパケットを送信する。また、前記ノードＬは、ＧＭまたはＭＲ状態である子ノードがあるので、前記データパケットを再ブロードキャストする（段階Ｓ１００６）。

前記データパケットを受信したノードＭは、ＭＲ状態であるから、自分の上位階層に前記データパケットを送信しない。ただし、ノードＭは、ＧＭまたはＭＲである子ノードがあるので、前記データパケットを再ブロードキャストする（段階Ｓ１００８）。ノードＮは、受信したデータパケットを自分の上位階層に送信し、リーフノードであるので、前記データパケットを再ブロードキャストしない。ノードＯは、受信したデータパケットを廃棄する。

前記データパケットを受信したノードＤとノードＨもまた、前記ノードＬが行なう動作と同じ動作を行なうので省略する。
以下、ノードＰ(ＧＣの子孫ノードでないノード)から送信するデータパケットが生成される場合について述べる。

マルチキャストグループにデータパケットを送信しようとするノードは、前記データパケットをＺＣ(ノードＡ)にユニキャストする。すなわち、ノードＰは、マルチキャストグループに送信するデータパケットが発生すれば、ノードＢに前記データパケットをユニキャストする（段階Ｓ１０１０）。前記ノードＢは、受信したデータパケットをノードＡにユニキャストする（段階Ｓ１０１２）。前記データパケットを受信したノードＡは、前記データパケットをＧＣであるノードＣに送信するために、データパケットをノードＢに送信し（段階Ｓ１０１４）、ノードＢは、前記送信されたデータパケットをノードＣに送信する（Ｓ１０１６段階）。以後行われる過程については省略する。

次いで、同じ送信元ノードから複数のデータパケットがマルチキャストグループに送信される場合について述べる。特に、ＧＣの子孫ノードでないノードからデータパケットを送信する場合について述べる。

前記データパケットを受信したＧＣであるノードＣは、プロキシ探索パケット(Ｐｒｏｘｙ Ｄｉｓｃｏｖｅｒｙ Ｐａｃｋｅｔ)をクラスターツリーに沿ってノードＡに送信する。前記プロキシ探索パケットは、送信元ノードアドレスと、マルチキャストグループアドレスとを含んでいる。もちろん、前記ノードＡは、プロキシ探索パケットを生成し、前記生成したプロキシ探索パケットをクラスターツリーに沿ってノードＣに送信できる。

前記ノードＣが送信したプロキシ探索パケットは、送信元ノードとＧＣとを子孫ノードに有する先祖ノードが受信するまでノードＡに送信される。すなわち、前記ノードＢは、送信元ノード(ノードＤ)とノードＣ(ＧＣ)とを子孫ノードに有する先祖ノードである。以後、前記ノードＢがプロキシノードの役割を行なう。すなわち、前記ノードＢには、仮ルーティングテーブルを生成する。前記仮ルーティングテーブルは、マルチキャストグループアドレス、ＧＣアドレス、終了時間、送信元ノードアドレスなどが含まれる。

以後、前記ノードＢは、ノードＣから受信したデータパケットをノードＡに送信せずに、仮ルーティングテーブルを利用しノードＣに直接送信する。

なお、本発明は、上記の実施形態に限定されるものではなく、本発明に係る技術的思想から逸脱しない範囲内で様々な変更が可能であり、それらも本発明の技術的範囲に属する。

複数のノードから構成されたジグビーネットワークを示す図である。 本発明に係るジグビーネットワークを構成している各ノードの状態を示す図である。 本発明の第１実施形態において、マルチキャストグループの加入を要請したノードが発生した場合、各ノードで行われる動作を示す図である。 本発明の第１実施形態において、マルチキャストグループの脱退を要請したノードが発生した場合、各ノードで行われる動作を示す図である。 本発明の第１実施形態において、マルチキャストグループを構成しているグループコーディネイター(ＧＣ)の役割を行なうノードを更新する過程を示す図である。 本発明の第１実施形態において、マルチキャストグループを構成しているＧＣが脱退を要請した場合、各ノードで行われる動作を示す図である。 本発明の第３実施形態において、マルチキャストルーティングテーブルの一例を示す図である。 本発明の第３実施形態において、ジグビーネックワークを構成しているノードで格納しているマルチキャストルーティングテーブルを示す図である。 本発明の第３実施形態において、マルチキャストグループの加入を要請したノードが発生した場合、各ノードで行われる動作を示す図である。 本発明の第３実施形態において、マルチキャストグループにデータパケットを送信する場合、各ノードで行われる動作を示す図である。

Claims (42)

1. 複数のノードから構成されたジグビーネットワークにおいて、
   前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、
   前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、
   前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、
   前記副マルチキャストルータが前記マルチキャストグループに加入を要請する場合、自分の状態を前記マルチキャストコーディネイターに変更することを特徴とするジグビーネットワークの管理方法。
2. 複数のノードから構成されたジグビーネットワークにおいて、
   前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、
   前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、
   前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、
   前記ジグビーコーディネイターまたは前記副マルチキャスタールータがマルチキャストグループに加入を要請する場合、自分の状態を前記マルチキャストコーディネイターに変更すると同時に、現在のマルチキャストコーディネイターにマルチキャストコーディネイター変更を通知するマルチキャストコーディネイター更新メッセージを送信することを特徴とするジグビーネットワークの管理方法。
3. 前記マルチキャストコーディネイターは、前記マルチキャストグループを構成しているノードのうちの残りのノードを子孫ノードに有する先祖ノードとして設定することを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
4. 前記マルチキャストグループを構成しているノードは、マルチキャストグループアドレスを割り当てられていることを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
5. 複数のノードから構成されたジグビーネットワークにおいて、
   前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、
   前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、
   前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、
   非マルチキャストグループメンバーがマルチキャストグループに加入を要請する場合、非マルチキャストグループメンバーは、加入要請メッセージを父ノードに送信し、
   前記加入要請メッセージを受信した父ノードが、マルチキャストメンバー、マルチキャストルータ、マルチキャストコーディネイター、または副マルチキャスタールータであれば、前記父ノードは、マルチキャストグループアドレスが含まれた加入応答メッセージを、前記加入要請メッセージを送信したノードに送信することを特徴とするジグビーネットワークの管理方法。
6. 複数のノードから構成されたジグビーネットワークにおいて、
   前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、
   前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、
   前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、
   非マルチキャストグループメンバーがマルチキャストグループに加入を要請する場合、非マルチキャストグループメンバーは、加入要請メッセージを父ノードに送信し、
   前記加入要請メッセージを受信した父ノードが非マルチキャストグループメンバーであり、かつ副マルチキャストルータでない場合は、受信した加入要請メッセージを自分の父ノードである第２の父ノードに送信し、
   前記第２の父ノードから受信した加入応答メッセージを子ノードに送信し、自分の状態をマルチキャストルータに変更することを特徴とするジグビーネットワークの管理方法。
7. 前記加入要請メッセージを受信したノードがジグビーコーディネイターであれば、前記ジグビーコーディネイターは、前記加入要請メッセージを生成したノードがマルチキャストコーディネイターに設定されるように指示することを特徴とする請求項６に記載のジグビーネットワークの管理方法。
8. 複数のノードから構成されたジグビーネットワークにおいて、
   前記複数のノードのうちの少なくとも２つのノードから構成されたマルチキャストグループを生成するステップと、前記マルチキャストグループを構成しているノードのうち、前記マルチキャストグループを管理するマルチキャストコーディネイターを設定するステップとからなり、
   前記マルチキャストグループは、前記マルチキャストコーディネイター、前記マルチキャストグループに加入を要請したマルチキャストメンバー、前記マルチキャストメンバーとを相互接続したり、前記マルチキャストメンバーと前記マルチキャストコーディネイターとを相互接続したりするマルチキャストルータより選ばれる少なくとも１つを含み、
   前記ジグビーネットワークは、ジグビーコーディネイターと、前記ジグビーコーディネイターと前記マルチキャストコーディネイターとを接続する副マルチキャスタールータとを含み、
   前記マルチキャストグループを脱退しようとするマルチキャストメンバーがマルチキャストグループのリーフノードであれば、自分の状態を非マルチキャストグループノードに変更し、リーフノードでなければ、自分の状態をマルチキャストルータに変更することを特徴とするジグビーネットワークの管理方法。
9. 前記子ノードの脱退により、マルチキャストルータである父ノードがマルチキャストグループのリーフノードであれば、前記マルチキャストルータは、マルチキャストグループを脱退することを特徴とする請求項８に記載のジグビーネットワークの管理方法。
10. 子ノードの脱退により、１つのマルチキャストメンバーまたはマルチキャストルータである子ノードを有するようになった前記マルチキャストコーディネイターがマルチキャストメンバーの役割を同時に行わない場合には、マルチキャストコーディネイターの役割を中断することを特徴とする請求項８に記載のジグビーネットワークの管理方法。
11. 前記マルチキャストコーディネイターは、１つのマルチキャストメンバーまたはマルチキャストルータである子ノードにマルチキャストコーディネイターの変更を指示するマルチキャストコーディネイター更新メッセージを送信することを特徴とする請求項１０に記載のジグビーネットワークの管理方法。
12. 前記マルチキャストコーディネイター更新メッセージを受信したノードがマルチキャストメンバーであれば、自分の状態をマルチキャストコーディネイターに変更し、前記マルチキャストコーディネイター更新メッセージを受信したノードがマルチキャストルータであれば、マルチキャストルータまたはマルチキャストメンバーである子ノードの個数をカウントすることを特徴とする請求項１１に記載のジグビーネットワークの管理方法。
13. 前記マルチキャストルータまたはマルチキャストメンバーである子ノードの個数が少なくとも２つであれば、前記マルチキャストルータは自分の状態をマルチキャストコーディネイターに変更し、前記マルチキャストルータまたはマルチキャストメンバーである子ノードが１つであれば、自分の状態を非マルチキャストグループメンバーに変更すると同時に、前記マルチキャストコーディネイター更新メッセージを前記子ノードに送信することを特徴とする請求項１２に記載のジグビーネットワークの管理方法。
14. 前記マルチキャストグループを構成しているノードは、自分と直接接続したマルチキャストグループを構成しているノードに関する情報であるビットマップを格納していることを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
15. 前記ビットマップは、１つの父ノードと、複数個の子ノードのうちのマルチキャストグループを構成するノードとをマーキングすることを特徴とする請求項１４に記載のジグビーネットワークの管理方法。
16. マルチキャストグループアドレスが付加されたデータパケットを受信したマルチキャストメンバーは、前記データパケットを父ノードまたは子ノードから受信した場合のみに上位階層に送信することを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
17. マルチキャストグループアドレスを含むデータパケットを受信したマルチキャストコーディネイターまたは副マルチキャスタールータは、前記データパケットをマルチキャストグループを構成しているマルチキャストクラスターツリー上の子ノードから受信した場合、前記データパケットを廃棄することを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
18. 前記マルチキャストグループを構成しているノードは、送信したデータパケットに関する情報を格納していることを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
19. 前記送信したデータパケットに関する情報は、マルチキャストグループアドレス、送信元アドレス、およびシーケンス番号であることを特徴とする請求項１８に記載のジグビーネットワークの管理方法。
20. 前記マルチキャストグループを構成しているノードは、送信したデータパケットを処理する父ノードと子ノードとを選択し、前記選択したノードに関する情報を前記データパケットに付加して送信することを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
21. 前記マルチキャストグループを構成しているノードは、受信したデータパケットを送信したノードのアドレスを前記データパケットに付加して送信することを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
22. 前記マルチキャストグループを構成しているノードは、マルチキャストメンバーまたはマルチキャストルータである子孫ノードの個数を格納していることを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
23. 前記マルチキャストグループに加入を要請する非マルチキャストグループノードは、クラスターツリーに沿って前記ジグビーコーディネイターに加入要請メッセージを送信することを特徴とする請求項２２に記載のジグビーネットワークの管理方法。
24. 前記加入要請メッセージを受信したジグビーコーディネイターは、新しいマルチキャストコーディネイターを決定し、前記新しく決定したマルチキャストコーディネイターが現在マルチキャストコーディネイターと異なる場合には、マルチキャストコーディネイター変更を通知するマルチキャストコーディネイター更新メッセージを現在マルチキャストコーディネイターと新しく決定したマルチキャストコーディネイターとに送信することを特徴とする請求項２３に記載のジグビーネットワークの管理方法。
25. 前記ジグビーコーディネイターから加入を許諾する加入応答メッセージを受信した中継ノードは、マルチキャストメンバーまたはマルチキャストルータである子孫ノード個数を１つだけ増加させることを特徴とする請求項２３に記載のジグビーネットワークの管理方法。
26. 前記マルチキャストグループの脱退を要請するマルチキャストメンバーは、クラスターツリーに沿って前記ジグビーコーディネイターに脱退要請メッセージを送信することを特徴とする請求項２２に記載のジグビーネットワークの管理方法。
27. 前記脱退要請メッセージを受信したジグビーコーディネイターは、新しいマルチキャストコーディネイターを決定し、前記新しく決定したマルチキャストコーディネイターが現在マルチキャストコーディネイターと異なる場合には、マルチキャストコーディネイター変更を通知するマルチキャストコーディネイター更新メッセージを現在マルチキャストコーディネイターと新しく決定したマルチキャストコーディネイターとに送信することを特徴とする請求項２６に記載のジグビーネットワークの管理方法。
28. 前記ジグビーコーディネイターから脱退を許諾する脱退応答メッセージを受信した中継ノードは、マルチキャストメンバーまたはマルチキャストルータである子孫ノード個数を１つだけ減少させることを特徴とする請求項２６に記載のジグビーネットワークの管理方法。
29. 前記マルチキャストグループの脱退を要請して、脱退応答メッセージを受信したマルチキャストメンバーは、マルチキャストメンバーまたはマルチキャストルータである子孫ノードの個数が少なくとも１つであれば、自分の状態をマルチキャストルータに変更することを特徴とする請求項２６に記載のジグビーネットワークの管理方法。
30. 前記マルチキャストグループに送信するデータパケットが発生すれば、前記ジグビーネットワークを構成するノードのうちのいずれか１つが、前記データパケットをジグビーコーディネイターまたはマルチキャストコーディネイターのうちのいずれかに送信することを特徴とする請求項２２に記載のジグビーネットワークの管理方法。
31. 前記マルチキャストグループを構成しているノードは、マルチキャストメンバーまたはマルチキャストルータである子ノードの個数を格納していることを特徴とする請求項１または請求項２に記載のジグビーネットワークの管理方法。
32. 前記マルチキャストグループに加入を要請したノードから受信した加入要請メッセージは、マルチキャストグループを構成しているノードまたはジグビーコーディネイターに到達するまで送信することを特徴とする請求項３１に記載のジグビーネットワークの管理方法。
33. 前記加入要請メッセージを受信したマルチキャストグループを構成しているノードは、マルチキャストメンバーまたはマルチキャストルータである子ノードの個数を１つだけ増加させることを特徴とする請求項３２に記載のジグビーネットワークの管理方法。
34. 前記加入要請メッセージを受信したジグビーコーディネイターは、新しく決定したマルチキャストコーディネイターが現在マルチキャストコーディネイターと異なる場合には、新しく決定したマルチキャストコーディネイターと現在マルチキャストコーディネイターとにマルチキャストコーディネイター変更を通知するマルチキャストコーディネイター更新メッセージを送信することを特徴とする請求項３２に記載のジグビーネットワークの管理方法。
35. 前記加入要請メッセージを受信したジグビーコーディネイターから前記マルチキャストコーディネイターに順次に送信される新しく加入したノードのアドレスが付加されたマルチキャストコーディネイター変更を指示するマルチキャストコーディネイター更新メッセージを受信したノードは、加入を要請したノードが自分の子孫ノードでなければ、自分の父ノードを新しいマルチキャストコーディネイターと決定することを特徴とする請求項３２に記載のジグビーネットワークの管理方法。
36. 前記マルチキャストグループに脱退を要請したノードから受信した脱退要請メッセージは、マルチキャストグループを構成しているノードまたはジグビーコーディネイターに到達するまで送信することを特徴とする請求項３２に記載のジグビーネットワークの管理方法。
37. 前記脱退要請メッセージの受信に応じて脱退応答メッセージを送信したマルチキャストグループを構成しているノードは、マルチキャストメンバーまたはマルチキャストルータである子ノードの個数を１つだけ減少させることを特徴とする請求項３６に記載のジグビーネットワークの管理方法。
38. 前記ノードの脱退により、１つのマルチキャストメンバーまたはマルチキャストルータである子ノードを有するマルチキャストメンバーの役割を行なわないマルチキャストコーディネイターは、前記子ノードにマルチキャストコーディネイター変更を指示するマルチキャストコーディネイター更新メッセージを送信することを特徴とする請求項３７に記載のジグビーネットワークの管理方法。
39. 前記マルチキャストコーディネイター更新メッセージを受信したマルチキャストルータが少なくとも２つのマルチキャストメンバーまたはマルチキャストルータである子ノードを有していれば、前記マルチキャストルータはマルチキャストコーディネイターの役割を行なうことを特徴とする請求項３８に記載のジグビーネットワークの管理方法。
40. 前記マルチキャストグループに送信するデータパケットが発生すれば、前記ジグビーネットワークを構成するノードのうちのいずれか１つが、前記データパケットをジグビーコーディネイターまたはマルチキャストコーディネイターのうちのいずれかに送信することを特徴とする請求項３１に記載のジグビーネットワークの管理方法。
41. 前記マルチキャストコーディネイターの子孫ノードでないソースノードから前記マルチキャストグループに送信するデータパケットが少なくとも２つ以上発生すれば、前記送信元ノードとマルチキャストコーディネイターとを子孫ノードに有する先祖ノードが決定されることを特徴とする請求項４０に記載のジグビーネットワークの管理方法。
42. 前記送信元ノードは、前記先祖ノードにデータパケットを送信することを特徴とする請求項４１に記載のジグビーネットワークの管理方法。

Images