JP3445444B2 - メッセージの経路選択方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コネクションオリ
エント型やコネクションレス型の分散型ネットワーク上
における通信に適する経路選択方法及びルーチングテー
ブルに関する。

【０００２】

【従来の技術】例えば、インターネットやＩＳＤＮ（総
合ディジタル通信網）といった分散型ネットワークにお
いては、ネットワークを構成する各ノードにメッセージ
を送信するためのルーチングテーブルを保持させる（Co
mputer Networks Andrews. Tanenbaum Prentice Hal
l）。

【０００３】

【発明が解決しようとする課題】ところで、上記のよう
なネットワークにおいて、各ノードに保管するルーチン
グテーブルを適切に設定することは、ルーチングの最適
化を図る上で重要な課題となる。即ち、メッセージの送
信には最短のルートあるいは最も経済的なルートを選定
し、更にネットワークのトラヒック増大を防止するよう
なルーチングが要求される。特に、マルチキャスト通信
においては一度に多くの宛先にメッセージを送信するた
め、トラヒックの増大防止を図る要求が強い。しかも、
ネットワークの規模が増大すれば、ルーチングテーブル
自身も複雑になる。従って、ルーチングテーブル自身の
増大防止を図ることも重要な課題となる。

【０００４】

【課題を解決するための手段】本発明は以上の点を解決
するため次の構成を採用する。 〈構成１〉本発明は、自ノードから宛先ノードへの確定リンクを定
め、該確定リンクを介して上記自ノードから上記宛先ノ
ードへメッセージを転送する経路選択方法であって、上
記自ノードから上記宛先ノードへ上記メッセージを転送
する時に、上記自ノードからメッセージを転送すべき他
の宛先ノードへの最短経路となる出力リンクに転送する
のに要するコストと、上記自ノードから上記確定リンク
を経由して上記他の宛先ノードに転送するのに要するコ
ストとを比較し、両コストの差が一定以下の場合に上記
他の宛先ノードのメッセージを上記確定リンク上で相乗
りさせて転送することを特徴とするメッセージの経路選
択方法。

【０００５】〈構成２〉構成１において、何らかのメッ
セージが自ノードに到着するたびに、どのリンクからメ
ッセージが到着したかを監視して，その情報を蓄積する
トラヒック監視テーブルを設けて、このトラヒック監視
テーブルを参照して、どのリンクにメッセージを転送す
ればそのメッセージが宛先に近づくかを判断し、そのメ
ッセージを宛先に近づくような確定リンクに相乗りさせ
ることを特徴とするメッセージの経路選択方法。

【０００６】〈構成３〉構成２において、いずれかのノ
ードからいずれかのリンクを通じてメッセージが到着し
たとき、ルーチングテーブル上のそのノードに該当する
宛先に対応させて、上記リンクにトラヒックが存在した
旨を記録することを特徴とするメッセージの経路選択方
法。

【０００７】〈構成４〉構成３において、アドレスが位
置情報に従って各ノードに割りつけられているとき、ト
ラヒック監視テーブル上のアドレスの一部が一致する全
てのノードからもメッセージが到着したものとして、ト
ラヒックが存在した旨を記録することを特徴とするメッ
セージの経路選択方法。

【０００８】〈構成５〉構成４において、受け取ったメ
ッセージの送信元ノードが自ノードから遠くに存在する
場合にのみ、アドレスの一部が一致する全てのノードか
らもメッセージが到着したものとすることを特徴とする
メッセージの経路選択方法。

【０００９】〈構成６〉構成５において、メッセージが
到着したリンク方向へメッセージを転送した場合に要す
るコストが閾値を越えていたとき、受け取ったメッセー
ジの送信元ノードが自ノードから遠くに存在すると判定
することを特徴とするメッセージの経路選択方法。

【００１０】

【００１１】

【００１２】

【００１３】

【００１４】

【００１５】

【００１６】

【００１７】

【００１８】

【００１９】

【００２０】

【００２１】

【００２２】

【００２３】

【００２４】

【発明の実施の形態】以下、本発明の実施の形態を具体
例を用いて説明する。 《具体例１》 〈ルーチングテーブル参照方式〉図１に、具体例１にお
けるメッセージの転送手順フローチャートを示す。この
説明の前に、比較のための従来の転送手順を説明する。
ルーチングテーブルの参照のみによってルーチングを決
定する方法で最も単純なアルゴリズムとしては、各宛先
に対して最短ルートを算出し、それぞれの宛先に最短ル
ートでメッセージを送信する方法がある。これは、マル
チキャスト通信の各宛先に対して最短ルートのルーチン
グを行い、転送先が一致したメッセージを相乗りさせる
というものである。これは、ＭＩＮＤＣ（Minimum Dest
inationCost Routing）として既に知られている方法で
ある。

【００２５】図２に、マルチキャスト通信のメッセージ
が到着した中継ノードにおける「ＭＩＮＤＣ」の送信手
順を示す。しかし、ＭＩＮＤＣでは、次のような場合
に、適切な判断が行われない場合が生じる。例えば、宛
先ノードＮ1 、Ｎ2 へのマルチキャスト通信のメッセー
ジが、あるノードＮC に到着したとする。ステップＳ１
で自ノード宛のメッセージを取り込み、ステップＳ２〜
ステップＳ７のループに移る。ステップＳ３では最短距
離の出力リンクをサーチする。このとき、ノードＮC に
おいて、Ｎ1 への最短経路が同コストで複数存在し、そ
の最短経路となる出力リンクがＬ1 、Ｌ2 の２種類が考
えられたとする。また、Ｎ2 への最短経路となる出力リ
ンクがＬ2 であったとする。このようなとき、Ｎ1 への
メッセージは、Ｌ2 に転送されればＮ2 へのメッセージ
と相乗りすることができるので当然Ｌ2 に転送されるべ
きである。しかしながら、ＭＩＮＤＣにおいては、Ｎ1
への最短経路となる出力リンクは、Ｎ2への最短経路と
なる出力リンクと無関係に決定されるため、Ｎ1 へのメ
ッセージの出力リンクとしてＬ2 が選択されるとは限ら
ない（ステップＳ４〜ステップＳ７）。

【００２６】この問題を解消したのがこの具体例の方式
であり、ルーチングテーブルの参照のみによって、相乗
り効果を最大限に引き出すルーチングアルゴリズムであ
る。また、ＭＩＮＤＣでは、各宛先への最短経路を重要
視しているが、メッセージが効果的に相乗りし、その結
果得られた経路が宛先までに要するコストをさして増大
させるものでない場合には、最短経路にはこだわる必要
もないと考えられる。よって、この具体例は、最短経路
よりもメッセージの相乗りに重きをおいたルーチング手
法として意義がある。

【００２７】〈アルゴリズム〉この具体例では、マルチ
キャスト通信の各宛先への最短経路となる出力リンクを
考慮しながら、メッセージの転送を行う。また、各宛先
までの最短経路を考慮しながらも、相乗り効果を最大限
に引き出す。図１は、マルチキャスト通信のメッセージ
が到着した中継ノードにおけるメッセージの転送手順を
示す。 ステップＳ１．メッセージの宛先群の中に自ノードが含
まれていたら、そのメッセージを取り込み、宛先群の中
から自ノードを削除する。 ステップＳ２．残された宛先群の中で、最も自ノードか
ら近くに存在する宛先（最もコストをかけないで到着す
ることができるノード）をサーチし、このノードを確定
宛先Ｎx とする。 ステップＳ３．このノードへの最短経路となる出力リン
クを確定リンクＬk とする。また、この宛先Ｎx へのメ
ッセージを確定リンクＬk の送信バッファに格納し、Ｎ
x を宛先群の中から削除する。

【００２８】残りの宛先群の各宛先に対して、ステップ
Ｓ４〜ステップＳ８のループで以下の処理を施す。当該
宛先へ最短経路になるような出力リンクに転送した場合
に宛先に到着するまでに要するコストと、確定リンクＬ
k に転送した場合に宛先に到着するまでに要するコスト
を比較する（ステップＳ５）。これらの間に大きな差が
認められなかった場合には、当該宛先へのメッセージを
確定リンクＬk のバッファに格納されているメッセージ
に相乗りさせ（ステップＳ６）、宛先群から当該宛先を
削除する（ステップＳ７）。

【００２９】ステップＳ９．確定リンクＬk にメッセー
ジを転送する。 ステップＳ１０．全ての宛先に向けてメッセージが転送
されていれば処理を終了する。また、全ての宛先に向け
てメッセージが転送されていない場合には、ステップＳ
２に戻り、上記の処理を全ての宛先に向けてメッセージ
が転送されるまで繰り返す。図３には、以上の処理の結
果得られた、回り込みルーチングの例説明図を示す。図
のように、相乗り区間のスループットは増大するが、全
体としてスループットが低下する。

【００３０】〈具体例１の効果〉以上に示したように、
この具体例では、確定宛先以外の各宛先へのメッセージ
を確定リンクに転送するか否かの判定が重要な要素とな
る。確定リンクというのは、事前に確定した任意のリン
クであればよい。ここでは、あるメッセージに対して、
確定リンクへ転送した場合に宛先に到着するまでに要す
るコストをＣｏｓｔ１、最短経路となるリンクに転送し
た場合に宛先に到着するまでに要するコストをＣｏｓｔ
２とした場合に、以下の判定を行う。 Ｃｏｓｔ１≦Ｃｏｓｔ２＋threshold （閾値）

【００３１】この条件式の真偽値がＴｒｕｅであれば、
このメッセージを確定リンクへ転送し、Ｆａｌｓｅであ
れば確定リンクには転送しない。従って、当然ながら、
この閾値threshold が重要なポイントとなる。この閾値
が０の場合は、確定宛先以外の宛先への最短経路も確保
されることになり、各宛先への最短経路を確保しなが
ら、その上で無駄のないメッセージの相乗り効果が得ら
れる。一方、閾値として０以外の値を設定した場合に
は、ある宛先Ｎ1 までに要するコストがたいして増大し
ないならば、Ｎ1 へのメッセージを無理やり他の宛先へ
のメッセージに相乗りさせてしまい、宛先Ｎ1 への最短
経路とならない出力リンクにメッセージの出力を行う。

【００３２】《具体例２》 〈ルーチングテーブルの参照＋トラヒック監視方式〉具
体例１で紹介した方法は、ルーチングテーブルのみを参
照して得た情報から、マルチキャスト通信における各宛
先への転送先を決定した。この方法は、ノードにおける
処理が極めて少ないことから、簡略性という観点からす
ると優れた方法であるといえる。しかし、ルーチングに
用いる情報がルーチングテーブルに記載されている宛先
と各出力リンクに転送した場合に宛先に到着するまでに
要するコストのみであり、マルチキャスト通信のルーチ
ングを決定する情報量としては不足しているケースもあ
る。

【００３３】また、閾値を０より大きな値に設定した場
合においては、パケットの相乗り効果は大きくなるもの
の、メッセージが無駄な経路を中継されるときは、全体
としてのスループットの向上が小さいこともある。従っ
て、ルーチングテーブル上の情報の他に、マルチキャス
ト通信のルーチングに何らかの情報を寄与するデータを
各ノードが有していれば、更に高スループットのルーチ
ングを行うことができるといえる。

【００３４】しかし、一方で、ノードにおけるルーチン
グに要する処理量の増加も抑えなければならないという
ことも考慮しなければならず、「マルチキャストルーチ
ングに何らかの情報を寄与するデータ」は、データの収
集、及びその利用が簡単に行えるものでなければならな
い。また、「各ノードのルーチングテーブルの宛先が集
約されている状態で実現が可能なルーチング手法」とす
るためには、ルーチングテーブルの集約が行われている
環境下で、その力が最大限に発揮される「ルーチングに
何らかの情報を寄与するデータ」であることが望まし
い。

【００３５】これらのことを総合的に考慮し、ここで
は、ノード間の方向性に関する情報、即ち、「あるノー
ドＮx へは、大体こちら方向のリンクに転送すれば良
い」といった類のいわゆる曖昧な情報が「ルーチングに
何らかの情報を寄与するデータ」として有効であると見
なし、他のノードから転送されてくるメッセージのトラ
ヒックを監視することにより、各ノードに、ネットワー
ク中の他のノード間の方向性を持たせ、これをマルチキ
ャスト通信のルーチングに用いる。

【００３６】〈概要〉ここで示す具体例２は、まず通常
の１：１型通信のトラヒックに関して、「ノードＮx か
らのメッセージが当該ノードに到着した際、どのリンク
からそのメッセージが到着したか」を監視する。そし
て、各ノードは、この監視して得た情報を蓄積してお
き、マルチキャスト通信のメッセージが到着した際に役
立てる。従って、各ノードには、ルーチングテーブルの
他にルーチングテーブルと同様の大きさでこのトラヒッ
ク監視結果を格納するデータ格納メモリが必要になる
が、ルーチングテーブル上の宛先は集約されており、そ
れほど大きな容量にはならない。

【００３７】図４には、ルーチングテーブルとトラヒッ
ク監視テーブルの説明図を示す。このトラヒック監視結
果を格納するテーブル（以降、トラヒック監視テーブル
と呼ぶ）は、ルーチングテーブルと同様の宛先と、出力
リンクの項目を有している。初期状態では、全ての項目
は０で初期化されているものとする。このトラヒック監
視テーブルの各項目の情報を、何らかのメッセージがノ
ードに到着する度に更新（具体的には、値をインクリメ
ントする等）していく。その結果、このノードでは、ル
ーチングテーブル上の集約されている宛先に関して、
「どのリンクにメッセージを転送すれば、そのメッセー
ジが宛先に近づくことができるか」といった情報を得る
ことができるようになる。これによって、宛先までのメ
ッセージの出力先に幅を持たせることができるようにな
り、マルチキャスト通信のメッセージの転送時に適応が
可能となる。

【００３８】なお、この方法では、トラヒックの監視が
十分に行われていない場合には、適切な判断をしかねる
場合も生じるが、実際には、少なくともルーチングテー
ブルを作成する際に各ノードの情報はブロードキャスト
されているはずであるし、ルーチングに関する情報の交
換等も半定期的に行われる。また、この他にも各ノード
間で行われる制御用のメッセージの交換は莫大になると
考えられることから、これらのトラヒックを監視するだ
けでもある程度の効果が認められる。しかし、ネットワ
ークの状況に変化が生じた場合には、これまで蓄積して
きた情報の信頼性が落ちることから、これを反映するべ
く、蓄積してきた情報の濃度を低くする等といった処置
が行われることが好ましい。

【００３９】〈アルゴリズム〉図５には、具体例２にお
ける、マルチキャスト通信のメッセージが到着した際の
転送の手順を示す。 ステップＳ１．メッセージの宛先群の中に自ノードが含
まれていたら、そのメッセージを取り込む。 ステップＳ２．残された宛先群の中で、最も自ノードか
ら近くに存在する宛先（最もコストをかけないで到着す
ることができるノード）をサーチし、このノードを確定
宛先Ｎx とする。 ステップＳ３．このノードへの最短経路となる出力リン
クを確定リンクＬk とする。この宛先Ｎx へのメッセー
ジを確定リンクＬk の送信バッファに格納し、Ｎx を宛
先群の中から削除する。

【００４０】ステップＳ４〜ステップＳ９のループで
は、残りの宛先群の各宛先に対して、以下の処理を施
す。ステップＳ４では、当該宛先をルーチングテーブル
上でサーチし、該当するルーチングテーブル上の宛先を
摘出する。ステップＳ５では、確定リンクＬk が、上の
処理で摘出した該当するルーチングテーブル上の宛先へ
の最短経路となる出力リンクのうちの一つとなっている
かどうかを判定する。ステップＳ６では、上の処理で摘
出した該当するルーチングテーブル上の宛先に対応する
トラヒック監視テーブルの項目を参照した結果、当該宛
先（ルーチングテーブル上の集約された宛先）からのメ
ッセージが、確定リンクＬk より頻繁に到着した経歴が
あるかどうかを判定する。

【００４１】ステップＳ７、Ｓ８．ステップＳ５とステ
ップＳ６の判定結果のいずれかがＹＥＳならば、当該宛
先へのメッセージを確定リンクのバッファに格納されて
いるメッセージに相乗りさせ、宛先群から当該宛先を削
除する。 ステップＳ１０．確定リンクＬk にメッセージを転送す
る。 ステップＳ１１．全ての宛先に向けてメッセージが転送
されていれば処理を終了する。また、全ての宛先に向け
てメッセージが転送されていない場合には、ステップＳ
２以下の処理を全ての宛先に向けてメッセージが転送さ
れるまで繰り返す。

【００４２】〈具体例２の効果〉具体例２では、具体例
１で相乗り不可能と判断されたメッセージを、再度、別
のトラヒック監視結果によるフィルタによって、確定リ
ンクＬk に相乗りさせるか否かを判定することになる。
この作業により、確定リンクに相乗りで転送すべき宛先
として、よりふさわしいものが選択されることになり、
具体例１よりも更に高スループットを得られる。

【００４３】《具体例３》 〈トラヒック監視手法〉具体例２においては、いうまで
もなくトラヒック監視テーブルに記載されているトラヒ
ック監視結果がメッセージ転送時の重要な要素となる。
このトラヒック監視テーブルの作成方法としてはさまざ
まなものが考えられるが、ここでは、次の二通りの手順
を示す。この説明は、図４を参照する。まず、ノードＮ
1 からのメッセージがリンクＬ1 より到着したとする。
このとき、ノードＮ1 をルーチングテーブル上でサーチ
し、Ｎ1 に該当するルーチングテーブル上の宛先を抽出
する。次に、トラヒック監視テーブル上の、リンクＬ1
とＮ1 に該当するルーチングテーブル上の宛先に対応す
る項目に、トラヒックが存在した旨を記録する。これ
は、当該項目に格納されている値をインクリメントする
等の処理によって行われる。

【００４４】〈トラヒック監視手法〉図６には、トラヒ
ック監視手続の説明図を示す。この手法は、アドレス
が、位置情報に従って各ノードに割り当てられているこ
とを利用する方法である。例えば、アドレスが「１−１
−２−＊」のノード群と、アドレスが「１−１−１−
＊」のノード群は、互いに近傍に位置している、という
ことを利用する。具体的なトラヒック監視テーブルの作
成手順（トラヒックの監視手順）を以下に示す。まず、
アドレスが「１−１−１−１」であるノードＮ1 からの
メッセージがリンクＬ1 より到着したとする。このと
き、ノードＮ1 をルーチングテーブル上でサーチし、Ｎ
1 に該当するルーチングテーブル上の宛先を抽出する。
次に、トラヒック監視テーブル上の、リンクＬ1 と上で
抽出した宛先の項目にトラヒックが存在した旨を記録す
る。更に、トラヒック監視テーブル上の、リンクＬ1 と
アドレス「１−１−１−＊」に該当する全ての項目にト
ラヒックが存在した旨を記録する。

【００４５】以上のように、トラヒック監視テーブルの
当該宛先以外の項目にもメッセージが到着したと同様の
旨を記録し、これによって、トラヒック監視テーブルの
持つ方向性に関する情報に一段と幅を持たせることがで
きる。なお、この手法は、ルーチングテーブルの宛先の
集約が行われていない場合においても実現が可能であ
る。

【００４６】《具体例４》以上のトラヒック監視手法に
おいて注意が必要なことは、自ノードの近傍に位置する
ノードからのメッセージに対してこの作業を行うと、と
んでもないことが生じる危険があるということである。
例えば、図６に示したネットワークにおいて、アドレス
が「１−２−１−２」であるノードに、ノード「１−１
−１−０」からのメッセージがノード「１−２−１−
１」方面から到着した場合を考える。このとき、トラヒ
ック監視テーブルの、「１−１−１−＊」に該当する全
ての項目にトラヒックが存在した旨を記載する。ここ
で、ノード「１−１−１−３」へのメッセージをノード
「１−２−１−１」方面に転送するとすれば、大幅なコ
ストの増大が発生する。それにも関わらず、上記の手法
ではノード「１−１−１−３」からのメッセージがノー
ド「１−２−１−１」方面から到着したこととして記録
されてしまう。

【００４７】更に、トラヒック監視テーブルの、「１−
１−＊−＊」に該当する全ての項目にトラヒックが存在
した旨を記載してしまうとなると、後のマルチキャスト
通信時に自ノード「１−２−１−２」と隣接している
「１−１−１−６」、「１−２−１−３」、「１−２−
１−６」といったノードへのメッセージも「１−２−１
−１」方面に転送するといった事態が発生することにな
り、更にとんでもないことになってしまう。このような
事態を避けるために、以下のような制限を加えることが
好ましい。

【００４８】即ち、受け取ったメッセージの送信元が自
ノードから遠くに存在する場合のみに、アドレスのclas
s Ａをワイルドカードとして、トラヒック監視テーブル
の該当する全ての項目にトラヒックが存在した旨を記載
する。なお、class Ａ−Ｂ−Ｃ−Ｄは１−１−１−０に
対応させている。なお、この場合において、class Ｂま
でワイルドカードとすると、その対象となるノードがか
なり増えることから、上記の事態と類似した問題が発生
する可能性があるので、これは行わない。

【００４９】また、受け取ったメッセージの送信元が自
ノードの近傍に存在しているか否かの判定は、宛先の集
約手法によっては難解になる場合もあるが、ここでは以
下のようにして行うものとする。 １．受け取ったメッセージの送信元アドレスをルーチン
グテーブル上でサーチし、これに該当するルーチングテ
ーブル上の宛先を抽出する。 ２．ルーチングテーブル上に記載されている、１．で抽
出した宛先に、メッセージが到着したリンク方向へメッ
セージを転送した場合に要するコストを抽出し、このコ
ストがある閾値を超えていた場合には、受け取ったメッ
セージの送信元が自ノードから遠くに存在するものと見
なす。

【００５０】《具体例５》 〈ルーチングテーブル参照＋ＡＣＫ方式〉ＣＡＴＶ等と
いったサービスにおいては、一旦経路が設定されると、
ネットワークの故障、ネットワークトポロジーの変化、
新規視聴者の追加、視聴者の削除等といった何らかの変
化が起こるまで、設定された経路が用いられることにな
り、経路を設定するまでに必要とされる制御に要する帯
域、処理量よりも、設定された経路のスループットが大
きな問題となる。従って、このようなサービスを行うト
ラヒックに関しては、経路を設定するまでに必要とされ
る制御の複雑さよりも、設定された経路のスループット
が重要視されなければならないことになる。

【００５１】これまでに紹介した具体例は、送信元から
各宛先までの経路設定が、通信要求の生起と共に行われ
る場合にも実現が可能なものであり、コネクションレス
型のパケット交換等の通信においてもその適応が可能で
ある。しかし、マルチメディア通信の実現性が問われて
いて広帯域伝送が必要とされており、なおかつ広域にま
たがっているネットワークにおいては、今後、ＡＴＭ
（非同期転送モード）が導入される可能性が高い。実
際、既にＬＡＮ（ローカルエリアネットワーク）のハブ
としてＡＴＭが導入されているところも多く、これらの
バックボーンネットワークは、ＡＴＭもしくは、ＡＴＭ
に類似したコネクションオリエンテッド型の通信方式が
採用されるべきであろう。

【００５２】コネクションオリエンテッド型の通信方式
においては、情報の転送に先立って、通信経路の確保と
いったコネクション確立の制御が行われる。このよう
に、コネクションを確立してから情報の送信が始まるよ
うな通信においては、宛先から、経路を決定していくこ
とも考えられる。また、分散データベースアクセス等と
いったｎ：１型の通信は、マルチキャスト通信において
宛先から通信が行われると考えることができ、宛先から
経路を決定することによって、これを実現することもで
きる。具体例５の手法は、宛先が相互に協調作業を行い
ながら当該通信の経路を決定していくという方式であ
り、経路を設定するまでに要する処理量は前述の方式と
比較して大きくなっても構わないが、設定された経路の
スループットを大きく向上させることを目的としてい
る。

【００５３】〈概要〉この具体例では、経路設定の作業
は、五つの作業ステップＳ１〜Ｓ５が段階的に行われる
ことによって完了する。まず、ここでは、そのダイアグ
ラムを掴むべく、これらの作業ステップの概要を解説す
る。なお、各作業ステップの詳細は後ほど改めて記述す
る。図７と図８に、具体例５における経路設定手順説明
図を示す。 〈ステップＳ１〉マルチキャスト通信の要求が生起する
と、まず、従来の経路選択方式（ＭＩＮＤＣ）や具体例
１〜４に示したいずれかの方法で、当該通信における全
ての宛先ノードまで「送信要求」を転送する。 〈ステップＳ２〉送信要求パケットを受け取った各宛先
ノードでは、自ノードの近隣に本通信における宛先が存
在するか否かを判定する。近隣に本通信における宛先が
存在した場合には、近隣に存在するノードの集まりで一
つのグループを形成する。更に、グループ内で相互に情
報を交換し、各グループの代表ノード（ボス）を決定す
る。このとき、「ボス」は、そのグループ内で最も送信
元ノードまで近いノードとする。

【００５４】〈ステップＳ３〉各グループの代表ノー
ド、もしくはグループを形成しなかった各宛先ノード
は、送信元に向けてＡＣＫ（アクノレッジ応答メッセー
ジ）を返送する。ただし、このＡＣＫを転送する各中継
ノードでも、近隣に本通信の宛先ノードが存在するか否
かの判定を行い、近隣に宛先ノードが存在した場合に
は、ＡＣＫ目的地を「送信元」からその「近隣に存在す
る宛先ノード」へと変更する。

【００５５】〈ステップＳ４〉ＡＣＫの目的地が「近隣
に存在する宛先ノード」へと変更された場合には、その
ＡＣＫを受け取ったノード（近隣に存在する宛先ノー
ド）は、そのＡＣＫをステップＳ３の手順に従って送信
元に向けて送信する。以降、ＡＣＫの目的地が「近隣に
存在する宛先ノード」へと変更された場合には、同様の
手順を繰り返す。 〈ステップＳ５〉送信元は、全ての宛先からＡＣＫを受
け取ったのを確認の上、送信を開始する。なお、ステッ
プＳ３〜ステップＳ４の過程において、通信路中にルー
プを生じる場合が考えられるが、これについては、中継
ノードがＡＣＫの情報を蓄積することによって解決さ
れ、設定された経路にループが生じることはない。

【００５６】この手順では、以上に示したステップＳ１
〜ステップＳ５までの作業が各ノードで行われ、経路の
設定が行われる。ここで注意しなければならないこと
は、ステップＳ３以降の処理は、全ての宛先においてス
テップＳ２の作業が終了してから行われなければならな
いということである。従って、ステップＳ３の作業は、
ステップＳ１が行われてから一定の時間をおいた後に開
始されることが好ましい。以降では、各作業ステップの
詳細をステップごとに説明する。

【００５７】〈各ステップの詳細なアルゴリズム〉 〈ステップＳ１〉ステップＳ１では、まず各宛先ノード
に、通信の要求がある旨を伝える「送信要求」メッセー
ジが転送される。この転送に用いられる経路は、この具
体例で最終的に決定される経路とは無関係であり、従来
の方式でマルチキャストしてよい。なお、当然ながら、
このマルチキャストも高スループットを得た方がよいの
で、前述の各具体例のうちのいずれか実現可能な方法で
転送することが望ましい。

【００５８】図９に、「送信要求」のメッセージフォー
マットを示す。この図に示す「送信要求」メッセージに
は、ヘッダに宛先アドレスを入れ、本通信における全て
の宛先のアドレスと、後のステップで用いられることに
なるコストの閾値が情報として格納されている。

【００５９】〈ステップＳ２〉「送信要求」メッセージ
を受け取った各宛先ノードは、「送信要求」のメッセー
ジ中の情報より、本通信における全ての宛先を認識でき
る。まず、各ノードは、この全ての宛先についてルーチ
ングテーブルを参照し、それぞれの宛先ノードに関し
て、自ノードからの距離（自ノードからその宛先ノード
までメッセージが到着するのに要するコスト）を算出す
る。このとき、「送信要求」メッセージに記載されてい
るコストの閾値を用い、その宛先ノードが自ノードから
見て近隣ノードであるか否かの判定を行う。具体的に
は、その宛先ノードまでのコストがこの閾値以下であっ
た場合には、このノードを近隣に存在するノードとして
扱うことになる。つまり、この近隣ノードであるか否か
の判定は、あるノードＮx に到着するまでに要するコス
トをｃｏｓｔ（Ｎx ）、「送信要求」に記載されている
コストの閾値をthreshold とした場合、次の判定式によ
って行われる。 ｃｏｓｔ（Ｎx ）≦threshold （閾値）

【００６０】この判定式の真偽値がＴｒｕｅであれば、
その宛先ノードＮx は近隣ノードであると見なされ、真
偽値がＦａｌｓｅであれば、その宛先ノードＮx は近隣
ノードと見なされない。以上の処理によって、自ノード
に近隣ノードが存在しないことが明らかになった場合に
は、ステップＳ２においてはこれ以上の処理を行わずス
テップＳ３の作業に移るが、近隣ノードが存在する場合
には、近隣ノードで形成される「グループ」を作成す
る。

【００６１】図１０に、近隣ノード認知要求のメッセー
ジフォーマットを示す。グループの形成は、各近隣ノー
ド間で、近隣ノードであると認めたノードに「近隣ノー
ド認知要求」メッセージを送信し合うことによって行わ
れる。「近隣ノード認知要求」のメッセージフォーマッ
トは、図に示すように、自ノードから送信元ノードまで
のコストを知らせ合うものとなる。

【００６２】図１１に、グループ形成の様子説明図を示
す。各ノード間で近隣ノードの認知が正常に行われてい
た場合には、自ノードで近隣ノードと認めた全てのノー
ドから「近隣ノード認知要求」が送信されてくるはずで
ある。なお、自ノードで近隣ノードと認めたノードのう
ち、「近隣ノード認知要求」が送信されてこなかったノ
ードに関しては、以降、近隣ノードでないものとして扱
う。即ち、ノードＡ〜Ｆが同一グループに属するとすれ
ば、図の矢印に示すように認知要求が送出される。

【００６３】次に、グループ内で、最も送信元ノードに
近いノードをボスとして選出する処理を行う。ボスの選
出においては、「近隣ノードの認知は各ノードで独立に
行われることから、実際に形成されるグループは、互い
に隣接ノードとして認めていないノード同士が同一のグ
ループに属することもある」ということに注意する必要
がある。これは、例えば以下のような場合に生じる事象
である。あるマルチキャスト通信において、その宛先に
ノードＮ1 、Ｎ2 、Ｎ3 が含まれていたとする。このと
き、ノードＮ1 とＮ2 同士は直接的には隣接ノードとし
て認められないが、これらに対して第三のノードＮ3 が
Ｎ1 の近隣ノードであり、同時にＮ2 の近隣ノードであ
る場合、Ｎ1 、Ｎ2 、Ｎ3 は同一グループに属すること
になる。このようなことは頻繁に生じることになると考
えられることから、ボスの選出作業はやや複雑になる。
グループにおけるボスの選出は、以下に示す３段階の作
業によって行われる。なお、グループ内のボス以外のノ
ードを「メンバ」と呼ぶ。

【００６４】〈仮ボスの選出〉図１２に、仮ボスの設定
動作説明図を示す。各ノードは、自ノードの近隣ノード
からは「近隣ノード認知要求」メッセージを受け取って
いることになるので、各近隣ノードから送信元ノードま
でに要するコストは把握している状態となっている。こ
の情報を用いて、自ノードから送信元ノードまでに要す
るコストと、各近隣ノードから送信元ノードまでに要す
るコストの比較を行い、自ノード、及び近隣ノードのう
ち、最も送信元ノードの近くに存在する（最も低コスト
で送信元ノードまで到着できる）ノードをサーチする。
その結果、自ノードが最も送信元ノードに近い場合には
何もせず、自ノードよりも送信元ノードに近い近隣ノー
ドが存在した場合には、その「自ノードの近隣ノード中
で最も送信元ノード近いノード」へ「仮ボス認定」の旨
を図の矢印のように送信し伝達する。以上の処理が終了
した時点で、全ての近隣ノードから「仮ボス認定」を伝
達されたノードが、「仮ボス」となる。なお、仮ボスは
図２に示すように一グループ内に複数存在することが考
えられる。

【００６５】〈仮ボス間の抗争〉図１３に、「ボス認知
要求」のメッセージフォーマット説明図を示す。仮ボス
の認定を受けたノードは、自ノードがグループ内の全て
のノードに当該グループのボスとして認められるか否か
を知る必要がある。まず、各仮ボスとなったノードは、
全ての近隣ノードに自ノードが仮ボスである旨を伝達す
るため、図に示す「ボス認知要求」メッセージを全ての
近隣ノードに転送する。ここには、その仮ボスから送信
元までのコストが情報として含められる。更に、この伝
達を受けた各ノードでは、この「ボス認知要求」を、各
ノードにおける各近隣ノード（ただし「ボス認知要求」
が送られてきたノードを除く）に転送する。

【００６６】図１４には、「ボス認知要求」の配送状況
説明図を示す。もし、図のように、グループ内に仮ボス
（ここではＡとＥ）が複数存在した場合には、この仮ボ
スの「ボス認知要求」メッセージの伝達がグループ内の
どこかのノードで（ここではＣやＦ）衝突することにな
る。「ボス認知要求」メッセージの伝達が衝突した場
合、衝突が起こったノードでは双方の仮ボスから送信元
ノードまでの距離（仮ボスから送信元ノードまでに要す
るコスト）を比較し、送信元ノードまでの距離が小さい
方の「ボス認知要求」のみを近隣ノードに転送する。こ
れを繰り返すことにより、グループ内に複数の仮ボスが
存在していても、最終的には、グループ内には唯一の、
ここではＥの「ボス認知要求」のみが行き届くことにな
る。

【００６７】〈ボスの認知〉図１５に、「ボス認知」の
メッセージフォーマットを示す。また、図１６に、「ボ
ス認知」メッセージの配送状況説明図を示す。「ボス認
知要求」メッセージの発信からしばらくたち、上述の作
業によって、グループ内で最も送信元ノードに近いノー
ドから発せられた「ボス認知要求」がグループ内に行き
届くと、全近隣ノードから同一の「ボス認知要求」メッ
セージが送信されてきたノードが存在することになる。
全近隣ノードから同一の「ボス認知要求」メッセージが
送信されてきたノードは、確かにその「ボス認知要求」
を認めたとして、「ボス認知」メッセージを、全近隣ノ
ードに送信する。この、「ボス認知」メッセージメッセ
ージを受け取った各ノードでは、前フェーズにおいて当
該「ボス認知要求」メッセージが送信されてきたノード
以外の全近隣ノードから「ボス認知」メッセージが到着
したことを確認した後に、前フェーズにおいて当該「ボ
ス認知要求」メッセージが送信されてきたノードに向け
て「ボス認知」メッセージを送信する。これを繰り返す
ことにより、グループのボスとなるノードに「ボス認
知」メッセージが届けられることになる。

【００６８】なお、この「ボス認知」メッセージには、
図１５に示すように、経路の履歴情報も併記し、図１６
に示すように、ボスからグループ内の各ノードへの経路
を作成する。Ａ，Ａ−Ｂ，Ａ−Ｂ−Ｃというように、経
路情報は各ノードを通過する度に付加されていく。

【００６９】図１７に、ボスから各メンバへの送信経路
説明図を示す。以上の作業によって、グループのボスが
選出され、ボスは当該グループに属する各メンバのアド
レス、及びボスから各メンバへの送信経路を得ることが
できる。

【００７０】〈ステップＳ３、ステップＳ４〉ステップ
Ｓ３では、各グループのボスとなったノード、及びグル
ープを形成しなかった宛先ノードが、送信元ノードに向
けてＡＣＫを返送する。図１８に、このＡＣＫのメッセ
ージフォーマットを示す。この図に示したように、ＡＣ
Ｋには、本通信における「近隣ノード」判定に用いるコ
ストの閾値をＡ領域に、本通信における全ての宛先から
自ノード及びグループを形成している場合にはそのグル
ープのメンバを除いた宛先のアドレスをＢ領域に、ＮＵ
ＬＬをＣ領域に、そして、当該グループに属する宛先ア
ドレスをＤ領域に、それぞれ記載する。

【００７１】ＡＣＫは送信元ノードに向けて送信される
が、途中の各中継ノードにおいて、当該ＡＣＫのＢ領域
に記載されているノードが近隣に存在するか否かの判定
を行い、もし、中継ノードにおいて近隣に本通信におけ
る宛先が存在した場合には、ＡＣＫの目的地をそのノー
ドへと変更する。また、送信元に至るまでの各中継ノー
ドで近隣に本通信の宛先が存在しなかった場合には、送
信元ノードにＡＣＫが届けられ、当該ＡＣＫに関する処
理は終了し、ステップＳ４が行われることなくステップ
Ｓ５へと移る。なお、この作業によって得られる経路は
各中継ノードにおいて記録され、後にステップＳ５、及
び本通信が行われる際に用いられることになる。

【００７２】ステップＳ３における作業において、ＡＣ
Ｋの目的地が本通信における宛先の一つへと変更された
場合は、以上に示したステップＳ３の処理が、再びＡＣ
Ｋが送信元ノードに到着するまで繰り返される。具体的
には以下のような処理が行われる。 １．ＡＣＫがグループのメンバに到着した場合には、Ａ
ＣＫを自ノードが所属しているグループのボスに転送す
る。ＡＣＫがグループのボス、もしくはグループを形成
しない宛先に到着した場合には何もせずに、次の２．の
処理を行う。 ２．ＡＣＫを受け取ったグループのボス（もしくはグル
ープを形成しない宛先）は、ＡＣＫのＢ領域に記載され
ている宛先群から、当該グループに含まれる宛先を全て
削除する（グループを形成していない場合は自ノードを
削除する）。また、ＡＣＫのＣ領域「中継ノード履歴情
報」に自ノード（ボス）のアドレスを書き込み、その
後、ステップＳ３と同様、ＡＣＫを送信元に向けて送信
する。

【００７３】これにより、ＡＣＫは必要に応じて寄り道
をしながら送信元まで到着することになる。以上の処理
がステップＳ４である。図１９と図２０に、本通信にお
ける送信元がＮx 、宛先がＮ1 、Ｎ2 、Ｎ3 、Ｎ4 、Ｎ
5 、Ｎ6 である通信におけるステップＳ３〜ステップＳ
４の作業の様子を示す。

【００７４】図では、Ｎ1 、Ｎ2 によって構成されてい
るグループと、Ｎ3 、Ｎ4 、Ｎ5 によって構成されてい
るグループができている。Ｎ1 、Ｎ2 によって構成され
ているグループから送信されたＡＣＫは、送信元ノード
までの経路上の中継ノードにおいて近隣に宛先が存在し
ないため、寄り道をせず送信元まで到着している。ま
た、グループを形成しなかった宛先ノードＮ6 は、自ノ
ードからＡＣＫを送信し、このＡＣＫも寄り道をせずに
送信元ノードまで辿り着いている。なお、これらのＡＣ
Ｋに記載されている情報は図２０に示した通り（ａ区間
のＡＣＫ、ｄ区間のＡＣＫ）である。

【００７５】一方、Ｎ3 、Ｎ4 、Ｎ5 によって構成され
ているグループから送信されたＡＣＫは、送信元ノード
までの経路上で近隣に本通信の宛先ノード（Ｎ2 ）を発
見したため、一旦目的地をＮ2 に変更している。このＡ
ＣＫを受け取ったＮ2 は、グループのボスであるＮ1 に
ＡＣＫを転送する。その後、Ｎ1 において、ＡＣＫに記
載されている「本通信における全宛先から当該グループ
に属する宛先を除いたアドレス群」から自ノードが所属
しているグループに属するノード（即ち、Ｎ1、Ｎ2 ）
を削除し、更に「中継ノード履歴情報」に自ノードを書
き加えた後、再び送信元ノードに向けてＡＣＫを転送す
る。この処理によって、ＡＣＫに記載されている情報が
変更される点に注意が必要である（図中の「ｂ区間のＡ
ＣＫの内容」と「ｃ区間のＡＣＫの内容」が異なってい
る点に注意）。これにより、いったん経由したノードが
次の経由先から除外されるからＡＣＫが無限ループに陥
り、送信元ノードまで辿り着かないといった事態を回避
している。

【００７６】〈ステップＳ５〉ステップＳ５は、ステッ
プＳ４までの作業で決定された経路を用いて、実際の情
報送信に伴って行われるフェーズである。実際の情報の
送信は、全ての宛先からＡＣＫを受け取った送信元ノー
ド及びＡＣＫを中継したノードが、ＡＣＫが通ってきた
経路を逆に辿って行われることになるが、ステップＳ４
の処理によって、経路中にループ（メッセージが同じ経
路を往復するといった無駄な状態）が生じていることも
考えられる。この無駄を省く処理がステップＳ５で行わ
れる。ステップＳ５の処理を、事例を示し、その事例上
で説明する。図２１に、マルチキャスト通信の一例説明
図を示す。図のようなネットワークにおいて、宛先がＮ
1 、Ｎ5 、Ｎ7 である通信経路の設定要求があった場合
を考える。なお、Ｎ1 、Ｎ5 、Ｎ7 は、ともにグループ
を形成しなかったものとする。

【００７７】図２２に、Ｎ1 からのＡＣＫの転送動作説
明図を示す。このとき、Ｎ1 からのＡＣＫは、図２２に
示したように、最初は、送信元ノードを目指して矢印ａ
のように転送されるが、その過程でＮ3 に到着すると、
宛先の一つであるＮ5 が近隣ノードと認識されるため、
矢印ｂのようにして目的地をＮ5 に変更する。このＡＣ
Ｋを受け取ったＮ5 は、ＡＣＫ上の情報をステップＳ４
のところで説明したように書き換えた後に、再びＮ1 か
らのＡＣＫを矢印ｃのように送信元に向けて転送する。
ここでＡＣＫがＮ3 に到着すると、再びＮ1 及びＮ5 が
近隣ノードとして認識されることになるが、Ｎ5 におい
てＡＣＫ上の情報を更新しているため、経由先から除外
され、再度Ｎ1 、Ｎ5 には立ち寄ることなく、このＡＣ
Ｋは送信元に向けて転送される。

【００７８】図２３に、Ｎ5 からのＡＣＫの転送動作説
明図を示す。同様に、Ｎ5 からのＡＣＫも、図２３に示
したように、矢印ａ、ｂ、ｃの順序で、Ｎ1 を経由した
後に送信元に転送される。

【００７９】図２４に、Ｎ7 からのＡＣＫの転送動作説
明図を示す。次に、Ｎ7 からのＡＣＫが、Ｎ5 の近隣を
通ったためにＮ5 に立ち寄った。このＡＣＫは、その
後、Ｎ5 からのＡＣＫと全く同様の経路を通って送信元
に転送される。以上で全宛先からのＡＣＫが送信元に転
送されたことになり、これを確認した送信元は、本通信
を開始する。この本通信のメッセージは、Ｎ6 を経由し
てＮ3に到着することになるが、ここでＮ3 が、受け取
ったＡＣＫの通りに本通信のメッセージを転送すると、
Ｎ3 は同一のＡＣＫを重複して交換しているために無駄
が生じることになる。

【００８０】図２５に、Ｎ3 が受け取って転送したＡＣ
Ｋの説明図を示す。Ｎ3 には、合計６回ＡＣＫが到着し
ているが、これは同一のＡＣＫを複数回受け取っている
ためで、実際の宛先は三つしかなく、更に本送信を転送
する方向は２方向のみである。従って、これらのＡＣＫ
のうちのいくつかを消去し、必要な経路にのみ本通信の
メッセージを転送する必要がある。これは、Ｎ3 におい
て、 １．同一のＡＣＫを複数回受け取った場合は、２回目以
降に受け取ったＡＣＫをステップＳ５では無視する。 ２．上の処理で残ったＡＣＫのうちで、あるＡＣＫに記
載されているＤ領域「ＡＣＫの送り出し元」とＣ領域
「中継ノード履歴情報」の内容が、他のＡＣＫのそれに
完全に含まれている場合には、そのＡＣＫをステップＳ
５では無視するという処理を行うことによって実現され
る。なお、受け取ったＡＣＫが以前に受け取ったことが
あるか否かの判定は、ＡＣＫのＤ領域を参照することに
よって行われる。

【００８１】図２６に、ステップＳ５におけるＡＣＫの
選定動作説明図を示す。図２５のＡＣＫにおいて、
「ｃ」と「ｅ」は同一のものであり、「ｂ」と「ｆ」
も、同一である。また、「ａ」と「ｄ」も同一である。
ここで、「ａ」、「ｂ」、「ｅ」は共に二回目に受け取
ったＡＣＫであるので、これらを消去する。これによっ
て、「ｃ」と「ｄ」と「ｆ」が残るが、このうち、
「ｆ」のＡＣＫに記載されているそれ（即ちＮ5 、Ｎ7
）に完全に含まれているため、これも消去する。Ｎ3
では、これによって残された「ｃ」と「ｄ」のＡＣＫを
元に本通信のメッセージを転送する。以上のような処理
を、複数のＡＣＫを受け取った各中継ノードで行い、残
されたＡＣＫの到着したリンクにのみ本通信におけるメ
ッセージを転送すれば、無駄がなくなり、効率の良い通
信が可能になる。

【００８２】〈ルーチングテーブル容量の削減〉上記の
ような各ノードが持つルーチングテーブルは、ネットワ
ークに接続されているノード数の増加に比例して拡大す
る。長期的に見れば、ネットワークは宛先数の増加に伴
って半無限に成長し続けると考えられる。図２７には、
ルーチングテーブルに記載する宛先数の説明図を示す。
この縦軸は、ルーチングテーブルに記載する宛先数で、
上に行くほど多くなることを示す。また、横軸はネット
ワークに接続されているノード数で、右に行くほど多く
なることを示す。ここで、宛先の増加と共に、そのまま
ルーチングテーブルの記載を増加させると、矢印ａに示
すように、直線的にルーチングテーブルの大きさが増大
する。

【００８３】一方、この具体例の方法では、宛先を集約
することによって、図のＢに示すような曲線とする。即
ち、ネットワーク中のノード数が大幅に増えてもある一
定値でルーチングテーブルに記載する宛先数が飽和する
ようにした。この飽和値はその都度任意に選定できるよ
うにする。

【００８４】〈第一の宛先集約方法〉この方法では、宛
先アドレスを広域部と狭域部の二階層構造にする。広域
部は上位アドレス、狭域部は下位アドレスに相当する。
そして、各宛先ノードのアドレスと自ノードのアドレス
を比較し、広域部が一致する宛先ノードの場合には、狭
域部までの情報をルーチングテーブルに記載する。一
方、広域部が不一致の宛先ノードについては広域部だけ
の情報をルーチングテーブルに記載する。この方法によ
って、ルーチングテーブルに記載される宛先数は、（自
ノードのアドレスと広域部が同一のアドレスのノード
数）＋（広域アドレス数−１）となる。

【００８５】即ち、図４を用いて説明したルーチングテ
ーブルの宛先部分を、広域部が一致するものについては
宛先ノード数分だけを用意し、広域部が不一致のものに
ついては広域アドレスのみを宛先とする。これ以上のル
ーチングは広域部が一致するノードで行えば良いという
ことである。これによって、ルーチングテーブルに記載
される宛先数の集約が可能となる。

【００８６】図２８には、広域部と狭域部の割当てのバ
リエーションを示す。この図に示すように、例えばアド
レスが上位アドレスから順にＤ−Ｃ−Ｂ−Ａというよう
に階層化されている場合に、広域部を最も上位のレベル
Ｄに設定する場合、レベルＤとＣに設定する場合、ある
いはレベルＤ，Ｃ，Ｂを含めたものに設定する場合で、
それぞれ集約化の異なる結果が得られる。即ち、バリエ
ーション番号を図のように１，２，３とした場合に、第
一番目のバリエーションではルーチングテーブルの広域
アドレス数は少なくなり、同一広域アドレスのノード数
が多くなる。逆にバリエーションナンバーが３のケース
では広域アドレス数が多くなり、同一広域アドレスのノ
ード数が小さくなる。従って、ネットワークの置かれた
環境やその拡張の見込み等を考慮して、いずれかの形式
を採用すれば良い。

【００８７】〈第二の宛先集約方法〉図２９には、第二
の宛先集約方法の説明図を示す。この例では、宛先ノー
ドのアドレスと自ノードのアドレスとをその一致状況に
よって分類する。アドレスは、例えば上位からＤ−Ｃ−
Ｂ−Ａというように４階層に分ける。そして、各ノード
をこの図に示すように、広帯域ノード、中広帯域ノー
ド、中狭帯域ノード、狭帯域ノードの４種類に分ける。
広帯域ノードはレベルＤから異なっているノードであ
る。中帯域ノードはレベルＤが一致するノードである。
中狭帯域ノードはレベルＤ，Ｃが一致するノードであ
る。狭帯域ノードはレベルＤ，Ｃ，Ｂが一致するノード
である。

【００８８】図３０は、第二の宛先集約方法によるルー
チングテーブルの説明図である。この例の場合、広帯域
ノードについてはレベルＤの情報だけをルーチングテー
ブルの宛先情報とする。また、中広帯域ノードについて
はレベルＤ，Ｃの情報だけ、中狭帯域ノードについては
レベルＤ，Ｃ，Ｂの情報だけをルーチングテーブルの宛
先とする。狭帯域ノードは全てとする。このように段階
的にアドレスのレベルを比較して宛先を設定することに
よってもルーチングテーブルの集約が可能である。こう
した集約方法によれば、ルーチングテーブルの情報をア
ドレスが近いものほど比較的具体的に表示でき、しかも
集約によるテーブル容量の縮小化を図ることができる。

【００８９】〈第三の宛先集約方法〉図３１に、ホップ
数による宛先集約方法説明図を示す。ここでは、自ノー
ドから宛先ノードまでのホップ数によりノードを分類す
る。ホップ数というのは、メッセージ送信の際に経由す
るノードの数等に対応させた数値である。図に示すｈ１
〜ｈ３は、任意の基準でこの数を設定する。図の例で
は、ｈ１が最も大きく、ｈ３が最も小さくなるように設
定している。こうして、広帯域ノードはｈ１以下では到
着しないノードとし、中広帯域ノードではｈ２以下では
到着しないノードとする。また、中狭帯域ノードはｈ３
以下では到着しないノードとし、狭帯域ノードはｈ３以
下で到着するノードする。境界部分は図に示す通りにす
る。このようにしてノードを分類し、その後は図３０に
示す通りの要領でルーチングテーブルに記載すべき宛先
を設定する。

【００９０】従って、この例では、ホップ数と各ノード
のアドレス階層とは必ずしも対応しなくて良い。これに
よって、複雑な経路を辿ってメッセージが到着するノー
ドの場合にはアドレスの上位のみがルーチングテーブル
に表示される。こうして、宛先数の集約が行われる。

【００９１】〈第四の宛先集約方法〉第三の宛先集約方
法においては、ホップ数を基準にノードを分類した。第
四の方法では、自ノードから宛先ノードまでの送信に要
するコストに着目して各ノードを分類する。コストはメ
ッセージの遅延、スループット、信頼性、通信料金等の
要素を加味して算定する。図３２には、コストを基準と
した宛先集約方法の説明図を示す。この図に示すよう
に、例えばコストをｃ１，ｃ２，ｃ３という閾値と比較
する。この閾値はｃ１が最も高く、ｃ３が最も低いもの
にする。こうして、広帯域ノードをｃ１以下では到着し
ないノードとし、中帯域ノードｃ２では到着しないノー
ドとする。また、中狭帯域ノードはｃ３以下では到着し
ないものとし、狭帯域ノードはｃ３以下で到着するノー
ドとする。これによって、各ノードを分類し、図３０と
同様の方法によってそれぞれルーチングテーブルに記載
すべき宛先を設定する。

【００９２】〈ルーチングテーブル容量の削減効果〉分
散ネットワーク上の各ノードが持つルーチングテーブル
の大きさの減少を図ることができ、かつ、この効果はネ
ットワーク規模によらず得られる。 １：ｎ型マルチキャスト通信への適用 １：ｎ型マルチキャスト通信におけるルーチングが実現
でき、かつ、上記で示した効果を活用できる。

【図面の簡単な説明】

【図１】具体例１におけるメッセージの転送手順フロー
チャートである。

【図２】具体例１における中継ノードにおける「ＭＩＮ
ＤＣ」のメッセージの転送手順フローチャートである。

【図３】回り込みルーチングの例説明図である。

【図４】ルーチングテーブルとトラヒック監視テーブル
の説明図である。

【図５】具体例２におけるメッセージが到着した際の転
送手順フローチャートである。

【図６】トラヒック監視手法の説明図である。

【図７】具体例５における経路設定手順説明図（その
１）である。

【図８】具体例５における経路設定手順説明図（その
２）である。

【図９】「送信要求」のメッセージフォーマットであ
る。

【図１０】近隣ノード認知要求のメッセージフォーマッ
トである。

【図１１】グループ形成の様子説明図である。

【図１２】仮ボスの設定動作説明図である。

【図１３】「ボス認知要求」のメッセージフォーマット
説明図である。

【図１４】「ボス認知要求」の配送状況説明図である。

【図１５】「ボス認知」のメッセージフォーマットであ
る。

【図１６】「ボス認知」の配送状況説明図である。

【図１７】ボスから各メンバへの送信経路説明図であ
る。

【図１８】ＡＣＫのメッセージフォーマットである。

【図１９】ステップＳ３〜ステップＳ４の処理説明図
（その１）である。

【図２０】ステップＳ３〜ステップＳ４の処理説明図
（その２）である。

【図２１】マルチキャスト通信の一例説明図である。

【図２２】Ｎ1 からのＡＣＫの転送動作説明図である。

【図２３】Ｎ5 からのＡＣＫの転送動作説明図である。

【図２４】Ｎ7 からのＡＣＫの転送動作説明図である。

【図２５】Ｎ3 が受け取って転送したＡＣＫの説明図で
ある。

【図２６】ステップＳ５におけるＡＣＫの選定動作説明
図である。

【図２７】ルーチングテーブルに記載する宛先数の説明
図である。

【図２８】広域部と狭域部の割当てのバリエーションで
ある。

【図２９】第二の宛先集約方法の説明図である。

【図３０】第二の宛先集約方法によるルーチングテーブ
ルの説明図である。

【図３１】ホップ数による宛先集約方法説明図である。

【図３２】コストを基準とした宛先集約方法の説明図で
ある。

【符号の説明】

ステップＳ１〜ステップＳ１１ 処理ステップ

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】 自ノードから宛先ノードへの確定リンク
   を定め、該確定リンクを介して前記自ノードから前記宛
   先ノードへメッセージを転送する経路選択方法であっ
   て、 前記自ノードから前記宛先ノードへ前記メッセージを転
   送する時に、 前記自ノードからメッセージを転送すべき他の宛先ノー
   ドへの最短経路となる出力リンクに転送するのに要する
   コストと、前記自ノードから前記確定リンクを経由して
   前記他の宛先ノードに転送するのに要するコストとを比
   較し、 両コストの差が一定以下の場合に前記他の宛先ノードの
   メッセージを前記確定リンク上で相乗りさせて転送す
   る、 ことを特徴とするメッセージの経路選択方法。
2. 【請求項２】 請求項１において、 何らかのメッセージが自ノードに到着するたびに、どの
   リンクからメッセージが到着したかを監視して、その情
   報を蓄積するトラヒック監視テーブルを設けて、 このトラヒック監視テーブルを参照して、どのリンクに
   メッセージを転送すればそのメッセージが宛先に近づく
   かを判断し、そのメッセージを宛先に近づくような確定
   リンクに相乗りさせることを特徴とするメッセージの経
   路選択方法。
3. 【請求項３】 請求項２において、 いずれかのノードからいずれかのリンクを通じてメッセ
   ージが到着したとき、ルーチングテーブル上のそのノー
   ドに該当する宛先に対応させて、前記リンクにトラヒッ
   クが存在した旨を記録することを特徴とするメッセージ
   の経路選択方法。
4. 【請求項４】 請求項３において、 アドレスが位置情報に従って各ノードに割りつけられて
   いるとき、トラヒック監視テーブル上のアドレスの一部
   が一致する全てのノードからもメッセージが到着したも
   のとして、トラヒックが存在した旨を記録することを特
   徴とするメッセージの経路選択方法。
5. 【請求項５】 請求項４において、 受け取ったメッセージの送信元ノードが自ノードから遠
   くに存在する場合にのみ、アドレスの一部が一致する全
   てのノードからもメッセージが到着したものとすること
   を特徴とするメッセージの経路選択方法。
6. 【請求項６】 請求項５において、 メッセージが到着したリンク方向へメッセージを転送し
   た場合に要するコストが閾値を越えていたとき、受け取
   ったメッセージの送信元ノードが自ノードから遠くに存
   在すると判定することを特徴とするメッセージの経路選
   択方法。