JP5435147B2 - 通信装置および方法 - Google Patents

通信装置および方法 Download PDF

Info

Publication number
JP5435147B2
JP5435147B2 JP2012546598A JP2012546598A JP5435147B2 JP 5435147 B2 JP5435147 B2 JP 5435147B2 JP 2012546598 A JP2012546598 A JP 2012546598A JP 2012546598 A JP2012546598 A JP 2012546598A JP 5435147 B2 JP5435147 B2 JP 5435147B2
Authority
JP
Japan
Prior art keywords
communication device
node
packet
transmission
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012546598A
Other languages
English (en)
Other versions
JPWO2012073316A1 (ja
Inventor
潤 伊吹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Application granted granted Critical
Publication of JP5435147B2 publication Critical patent/JP5435147B2/ja
Publication of JPWO2012073316A1 publication Critical patent/JPWO2012073316A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワーク通信技術に関する。
複数の通信装置を含むネットワークにおいては、通信負荷の集中は好ましくない。しかしながら、状況によっては、ある通信装置に通信負荷が集中してしまうことがある。そこで、例えば、通信ネットワークシステムにおけるノードの状態とリンクの状態とに基づいて、ネットワークリソースを最適に利用することができるようにする技術を提供することを目的とする、以下のような通信ネットワークシステムが提案されている。
すなわち、当該通信ネットワークシステムは、複数の装置が備えるネットワークリソースの状況を管理する手段と、ネットワークリソースの適応制御が必要か否かを判定する手段を有する。また、当該通信ネットワークシステムは、ネットワークリソースの適応制御が必要であると判定された場合には、装置が備える機能および処理対象の配置または装置間のパスの構成を計画する手段を有する。さらに、当該通信ネットワークシステムは、計画に応じて、装置が備える機能および処理対象の再配置または装置間のパスの再構成を行う手段を有する。
特開２００４−２４１８４５号公報
例えば、ネットワーク構成によっては、多くの通信装置から送信されたデータが、ある特定の通信装置を経由することがある。したがって、当該特定の通信装置に通信負荷が集中することが起こり得る。また、自らが起点となって多くのデータを送信する通信装置においては、当然、通信負荷は高い。
そして、通信負荷が集中する特定の通信装置がボトルネックとなって、例えば、伝送遅延の拡大、タイムアウトによるデータ再送の増加、あるいはその他の様々な問題が生じ得る。よって、ボトルネックを予測して予防すること、または、ボトルネックを検出してボトルネックの解消のための対策をとることは、ネットワークの運用にとって有益である。
他方、ボトルネックの予測または検出のためにネットワークに過剰な負荷をかけることは、好ましくない。
例えば、特定の管理装置が、ボトルネックの予測または検出のために用いる情報をネットワーク内の各通信装置から収集する中央管理的なネットワークシステムは、情報の収集のためのトラヒック自体がネットワークに大きな負荷をかけるおそれがある。よって、過剰な負荷を避けるために、ネットワーク内の各通信装置が自律的にボトルネックを予測または検出することができるような技術が望まれる。
そこで本発明は、ネットワーク内の通信装置による自律的なボトルネックの予測または検出を可能にすることを目的とする。
一態様による通信装置は、複数の通信装置を含むネットワークにおける第１の通信装置である。
前記第１の通信装置は、第２の通信装置にデータを送る際に選択可能な、前記第１の通信装置に隣接する第３の通信装置を記憶した経路情報記憶部を有する。また、前記第１の通信装置は、前記第１の通信装置に隣接する第４の通信装置から、該第４の通信装置が所定期間に前記第１の通信装置を介して送信する前記第２の通信装置宛の第１の送信データ量の通知を受信する受信部を有する。
そして、前記第１の通信装置は、前記第１の送信データ量を含む、前記第１の通信装置から前記所定期間に送信する前記第２の通信装置宛の第２の送信データ量を前記第３の通信装置に通知する送信量通知部を有する。また、前記第１の通信装置は、前記第２の送信データ量が所定の基準を超えているかを判定する判定部も有する。
さらに、前記第１の通信装置は、前記第２の送信データ量が前記所定の基準を超えていると前記判定部が判定した場合に、前記第１の通信装置が前記ネットワークにおけるボトルネックであることを、予め定められた第５の通信装置に通知する送信ボトルネック通知部も有する。
上記のとおり、第１の通信装置の経路情報記憶部は、第２の通信装置にデータを送る際に選択可能な第３の通信装置を記憶しており、第１の通信装置の送信量通知部は、第２の送信データ量を他ならぬ第３の通信装置に通知する。したがって、ネットワーク内の各ノードに相当する各通信装置が、上記第１の通信装置のように構成されていれば、第２の通信装置に至るデータ送信経路に沿って、次々に送信データ量が通知されて累積される。そして、累積された送信データ量に応じて、第２の通信装置に至るデータ送信経路上の各通信装置の判定部が、判定を行う。
また、上記の第１の通信装置に関する説明から明らかなように、第１と第２の送信データ量の通知は、将来予測される送信データ量に関する通知に限定されるわけでもなく、現在の実際の送信データ量に関する通知に限定されるわけでもない。よって、上記の第１の通信装置は、ボトルネックを予測することもできるし、ボトルネックを検出することもできる。
したがって、ネットワーク内の各ノードが上記第１の通信装置のように構成されていれば、各通信装置が自律的に、当該通信装置自身が第２の通信装置に至るデータ送信経路上のボトルネックであるか否かに関して、予測または検出を行うことができる。
第１実施形態の通信装置のブロック構成図である。 通信装置の第１のハードウェア構成図である。 通信装置の第２のハードウェア構成図である。 ネットワークの第１の例を示す図である。 第２実施形態の通信装置のブロック構成図である。 第３実施形態におけるデータパケットの送受信に関するタイミングチャートである。 第３実施形態の通信装置のブロック構成図である。 第３実施形態のリンクテーブルの例を示す図である。 第３実施形態のルーティングテーブルの例を示す図である。 第３実施形態で使われるパケットの例を示す図である。 いくつかの実施形態で共通のパケット受信処理のフローチャートである。 第３実施形態におけるデータパケット受信処理のフローチャートである。 第３実施形態における受信トラヒック設定処理のフローチャートである。 第３実施形態におけるボトルネック検出処理のフローチャートである。 第３実施形態におけるデータパケット送信処理のフローチャートである。 第４実施形態におけるハローパケットの送受信に関するタイミングチャートである。 第４実施形態の通信装置のブロック構成図である。 第４実施形態のリンクテーブルの例を示す図である。 第４実施形態で使われるパケットの例を示す図である。 第４実施形態におけるハローパケット受信処理のフローチャートである。 第４実施形態におけるハローパケット送信処理のフローチャートである。 第５実施形態におけるボトルネック検出処理のフローチャートである。 第６実施形態におけるリンクテーブルの例を示す図である。 第６実施形態におけるハローパケット受信処理のフローチャートである。 第６実施形態におけるボトルネック検出処理のフローチャートである。 ネットワークの第２の例を示す図である。
以下、各種実施形態について、図面を参照しながら詳細に説明する。下記の各種実施形態は、いずれもアドホックネットワークにおけるボトルネックの予測または検出に好適である。そこで、以下ではまずアドホックネットワークにおけるボトルネックに関して簡単な説明を行い、その後、第１〜１１実施形態および各種変形例について順に説明する。
さて、アドホックネットワークの特長の１つは、データ送信経路などに関する事前の設計や設定がほとんど不要な点である。一方、アドホックネットワークの実際の運用においては、ノードの配置その他の様々な要因から、ネットワーク内にボトルネックが生じることがある。
なお、従来想定され、利用されていた小規模なアドホックネットワークでは、あまりボトルネックの発生は問題にならなかった。しかし、近年のアドホックネットワークの利用拡大にともなって、従来は想定されていなかった大規模なアドホックネットワークも使われるようになってきた。
また、定常的に比較的多くのトラヒックを流すような、従来はあまり想定されていなかった用途にも、アドホックネットワークが使われるようになりつつある。例えば、アドホックネットワークの新たな用途の１つは、定期的にセンサの出力を送信する多数のノードを含む、大規模センサネットワークである。
そして、以上のようなアドホックネットワークの利用拡大にともない、ボトルネックの発生が新たな問題として顕在化しつつある。下記各種実施形態は、新たな問題への対策を提供するものである。
ネットワーク内にボトルネックがあると、例えば、ボトルネックのノードにおけるバッファオーバフローによりデータが消失するかもしれない。あるいは、タイムアウトが頻発し、その結果として、データの再送や送信経路の切り換えなども頻発し、ネットワークにおけるデータの伝送遅延も増大するかもしれない。
しかし、「事前の設計や設定がほとんど不要であり、ネットワーク全体を集中管理するノードも不要である」というアドホックネットワークの性質を考慮すると、ボトルネックの予測または検出を特定の１つの管理装置が行うことは、好ましいとは言えない。なぜなら、ボトルネックの予測または検出のために、特定の１つの管理装置がネットワーク内の各ノードから情報を改めて収集することになるからである。つまり、情報収集のためのトラヒックが、ネットワークに過剰な負荷をかけるおそれがある。
そこで、ボトルネックの予測または検出のためにネットワークに新たに生じる負荷を小さく抑えつつ、ボトルネックの予測または検出を可能とすることが望まれる。
ところで、ある特定のノードがボトルネックとなる要因としては、特定のノードに流入するトラヒックが多いこと、あるいは特定のノードから流出するトラヒックが多いことが挙げられる。つまり、実際のデータ送信経路に沿って流れるトラヒックの多さがボトルネックの要因である。
ここで、アドホックネットワーク内の各ノードは、実際にデータを送信する際に用いる経路に関して、経路の全体を認識している必要はないが、少なくとも当該ノード自身に隣接する次ホップのノードは認識している。このことから、発明者は次のような考察を得た。すなわち、各ノードが、当該ノード自身が認識している次ホップに関する情報を用いることで、ネットワークに過剰な負荷をかけることなく、各ノードによる自律的なボトルネックの予測または検出が可能となる。
以下では、各ノードによる自律的なボトルネックの予測または検出を可能とする各種実施形態について説明する。また、以下の各種実施形態におけるネットワークは任意のネットワークでよいが、以下の各種実施形態はアドホックネットワークに好適である。
図１は、第１実施形態の通信装置のブロック構成図である。図１の通信装置１００は、複数の通信装置を含むネットワークで使われる。ネットワークは、例えば、アドホックネットワークである。
以下、図１〜４に関する説明においては、便宜上、ネットワーク内の以下のような通信装置をそれぞれ「第１の通信装置」〜「第６の通信装置」という。
便宜上、通信装置１００自体を「第１の通信装置」という。
また、便宜上、ネットワーク内でのデータの最終的な送信先である、特定の通信装置を「第２の通信装置」という。第２の通信装置は、例えば、上記ネットワークと他のネットワークとの間のゲートウェイであってもよい。
さらに、通信装置１００が第２の通信装置にデータを送る際に直接の宛先として選択可能な、通信装置１００に隣接する通信装置を、便宜上、「第３の通信装置」という。
なお、「通信装置１００に隣接する通信装置」とは、通信装置１００との間のホップ数が１の通信装置のことである。通信装置１００には１つまたは複数の通信装置が隣接していてよい。
そして、通信装置１００に隣接する１つまたは複数の通信装置のうち、通信装置１００が第２の通信装置にデータを送る際に直接の送信先として選択可能な通信装置は、１つのこともあるし、複数のこともある。第３の通信装置は、選択可能な１つまたは複数の通信装置の中の１つである。
例えば、第３の通信装置は、選択可能な１つまたは複数の通信装置のうち、所定の規則にしたがって動的に変更される評価値が最も高い評価を示す通信装置であってもよい。また、第２の通信装置が通信装置１００に隣接している場合は、第３の通信装置は第２の通信装置と同じでもよい。
また、通信装置１００に隣接する通信装置が選択可能であるか否かは、例えば、通信装置１００が採用するルーティングアルゴリズムによる。あるルーティングアルゴリズムによれば、通信装置１００に隣接するすべての通信装置が、通信装置１００が第２の通信装置にデータを送る際に直接の送信先として選択可能である。別のルーティングアルゴリズムによれば、通信装置１００に隣接する通信装置のうち、評価値がベストＭ（１≦Ｍ）に入るものだけが、通信装置１００が第２の通信装置にデータを送る際に直接の送信先として選択可能である。
さらに、第２の通信装置宛のデータを、通信装置１００を介して送信する、通信装置１００に隣接する通信装置を、便宜上、「第４の通信装置」という。第４の通信装置が１つだけ存在する場合もあるし、複数の第４の通信装置が存在する場合もある。
さらに、通信装置１００自身が後述のようにして「通信装置１００は、ネットワーク内で通信負荷の集中するボトルネックである」と判定した場合に、通信装置１００が判定結果を通知する先の予め決められた通信装置を、便宜上、「第５の通信装置」という。
なお、ネットワーク内の特定の１つの通信装置が、第５の通信装置として予め決められていてもよい。例えば、第５の通信装置と第２の通信装置が同じでもよい。あるいは、複数の通信装置が、複数の第５の通信装置として予め決められていてもよい。例えば、ネットワーク内の通信装置１００以外のすべての通信装置が、複数の第５の通信装置として予め決められていてもよい。
また、通信装置１００が第２の通信装置にデータを送る際に、直接の送信先として選択可能な、通信装置１００に隣接する通信装置のうち、第３の通信装置以外のものを、便宜上、「第６の通信装置」という。第３の通信装置に関して述べたとおり、選択可能な通信装置は１つのこともあるし、複数のこともある。
なお、「第４の通信装置が第６の通信装置でもある」という状況もある。なぜなら、第４の通信装置は、第１の通信装置に隣接しているので、潜在的には、第１の通信装置が第２の通信装置宛のデータを送る際に直接の送信先として選択可能だからである。
さて、図１の通信装置１００は、以上のような第１〜第６の通信装置を含むネットワークにおける第１の通信装置である。そして、図１に示すように、通信装置１００は、通知受信部１０１、送信量通知部１０２、ボトルネック判定部１０３、送信ボトルネック通知部１０４、および経路情報記憶部１０５を有する。
通知受信部１０１は、第４の通信装置から、第４の通信装置が通信装置１００を介して所定期間に送信する第２の通信装置宛の第１の送信データ量の通知を受信する。送信量通知部１０２は、第１の送信データ量を含む、通信装置１００から所定期間に送信する第２の通信装置宛の第２の送信データ量を、第３の通信装置に通知する。
例えば、「所定期間」が１時間であり、第４の通信装置が２つあるとする。そして、第４の通信装置のうちの１つは、中継するデータと当該第４の通信装置自身が生成するデータとを合わせて、１時間あたり３０００ＫＢ（キロバイト）のデータを、通信装置１００を介して第２の通信装置宛に送信するものとする。また、もう１つの第４の通信装置は、中継するデータと当該第４の通信装置自身が生成するデータとを合わせて、１時間あたり２４００ＫＢのデータを、通信装置１００を介して第２の通信装置宛に送信するものとする。
すると、通信装置１００の通知受信部１０１は、２つの第４の通信装置から、それぞれの第１の送信データ量の通知として、「１時間あたり３０００ＫＢ」という通知と「１時間あたり２４００ＫＢ」という通知を受信する。また、通信装置１００自身が、第２の通信装置宛のデータを１時間あたり２００ＫＢ生成して送信するとする。すると、第２の送信データ量は、５６００（＝３０００＋２４００＋２００）ＫＢである。
送信量通知部１０２は、上記のようにして、通知受信部１０１が受信した第１の送信データ量の通知に基づいて、第２の送信データ量を計算してもよい。そして、送信量通知部１０２は、計算した第２の送信データ量をボトルネック判定部１０３に出力してもよい。
すると、ボトルネック判定部１０３は、第２の送信データ量が所定の基準を超えているかを判定する。所定の基準は、実施形態に応じて様々であってよい。例えば、ボトルネック判定部１０３は、単純に、第２の送信データ量と所定の閾値を比較してもよい。そして、第２の送信データ量が所定の閾値を超えていれば、ボトルネック判定部１０３は、「第２の送信データ量が所定の基準を超えている」と判定してもよい。所定の基準の他の具体例については後述する。
そして、「第２の送信データ量が所定の基準を超えている」とボトルネック判定部１０３が判定した場合、送信ボトルネック通知部１０４は、「通信装置１００はネットワークにおけるボトルネックである」ということを、第５の通信装置に通知する。第５の通信装置への通知は、換言すれば、「通信装置１００の通信負荷が過剰である」という警告である。
よって、送信ボトルネック通知部１０４から第５の通信装置への通知にしたがって、過剰な負荷を軽減するための対策がとられることが望ましい。
例えば、第５の通信装置は、ディスプレイを有し、送信ボトルネック通知部１０４からの通知の内容をディスプレイに表示してもよい。そして、例えばネットワーク管理者などがディスプレイを見て、何らかの対策をとってもよい。
例えば、ネットワーク管理者は、「通信装置１００はネットワークにおけるボトルネックである」という通知に基づいて、通信装置１００の近傍に新たな１つまたは複数の通信装置を配置することで、通信装置１００への通信の集中の緩和を図ってもよい。あるいは、ネットワーク管理者は、第２の通信装置に宛てて送信するために所定期間あたりに生成するデータの量を減らすように、ネットワーク内の一部または全部の通信装置の設定を変更してもよい。
もちろん、第５の通信装置は、送信ボトルネック通知部１０４からの通知を契機に、自動的に、ネットワーク内の一部または全部の通信装置に対して、設定変更を命じてもよい。つまり、第２の通信装置に宛てて送信するために所定期間あたりに生成するデータの量を減らすように、第５の通信装置は、自動的に、一部または全部の通信装置に命令を送信してもよい。
以上のような送信規制は、例えば、「優先度（換言すれば、緊急度または重要度）の低い特定のタイプのデータのみ送信を控える」などの規則にしたがって行われてもよい。すると、送信規制下においても、優先度の高いデータは、確実に送信される。
あるいは、上記のようにネットワーク内における通信装置１００以外のすべての通信装置が第５の通信装置であってもよい。この場合、各第５の通信装置は、当該第５の通信装置自身が第２の通信装置に宛てて送信するために所定期間あたりに生成するデータの量を、送信ボトルネック通知部１０４からの通知を契機に減らしてもよい。
なお、通知受信部１０１が通知を受ける第１の送信データ量と、送信量通知部１０２が通知を出す第２の送信データ量は、今後の運用において送信される予定のデータの量であってもよいし、実際に送信されたデータの量であってもよい。
第１と第２の送信データ量が、予定されるデータの量を示す場合、第５の通信装置への通知は、今後の運用において予測されるボトルネックについての警告である。逆に、第１と第２の送信データ量が、実際に送信されるデータの量を示す場合、第５の通信装置への通知は、実際にボトルネックを検出したことを示す警告である。
ところで、経路情報記憶部１０５は、通信装置１００が第２の通信装置宛のデータを送る際に、直接の宛先として選択可能な通信装置として、第３の通信装置を記憶する。よって、送信量通知部１０２は、経路情報記憶部１０５を参照することにより、第２の送信データ量の通知の送信先である第３の通信装置を認識することができる。
経路情報記憶部１０５は、さらに、通信装置１００が第５の通信装置宛のデータを送る際に直接の宛先として選択可能な通信装置を記憶してもよい。すると、特定の１つの通信装置が第５の通信装置として予め決められている場合、送信ボトルネック通知部１０４は、経路情報記憶部１０５を参照することで、警告を第５の通信装置に最終的に通知する際の直接の送信先を決められる。
あるいは、ネットワーク内の通信装置１００以外のすべての通信装置が複数の第５の通信装置として予め決められている場合は、送信ボトルネック通知部１０４は警告を単にブロードキャストすればよい。よって、この場合、送信ボトルネック通知部１０４は、経路情報記憶部１０５を参照する必要はない。
経路情報記憶部１０５は、具体的には、第３の通信装置を識別するための識別情報を含む情報を記憶する。経路情報記憶部１０５が記憶する情報の内容と形式は実施形態に応じて様々である。そして、実施形態によっては、ボトルネック判定部１０３は、第２の送信データ量が所定の基準を超えているか否かの判断を行うときに、経路情報記憶部１０５が記憶する情報を参照してもよい。
例えば、経路情報記憶部１０５は、第３の通信装置と通信装置１００との間の通信品質の第１の評価値をさらに記憶していてもよい。この場合、ボトルネック判定部１０３は、第２の送信データ量と第１の評価値を使った所定の計算を行い、計算結果として得られる第１の値を第１の閾値と比較してもよい。そして、ボトルネック判定部１０３は、第１の値が第１の閾値より大きい場合に、「第２の送信データ量は所定の基準を超えている」と判定してもよい。
以下では説明の便宜上、通信品質を示す第１の評価値は、値が小さいほど高い品質を示すように定義されるものとする。しかし、もちろん実施形態によっては、第１の評価値は、値が大きいほど高い品質を示すように定義されてもよい。
第１の値は、第２の送信データ量が多いほど大きくなるように、かつ、第１の評価値が高い品質を示すほど（つまり第１の評価値が小さいほど）小さくなるように、定義されている。例えば、第１の値は、第２の送信データ量と第１の評価値の積でもよい。
より具体的には、第１の評価値は、以下に例示する様々な指標のうちの１つまたは複数に基づいて定義される値であってよい。例えば、第１の評価値は、無線ネットワークにおいては、受信電力またはリトライ回数に基づく値でもよい。また、ネットワークが無線か有線かに関わらず、第１の評価値は、パケットエラー率、パケットロス率、スループット、または、ネットワーク内の各通信装置から定期的に送信されることになっている制御パケットの受信間隔の揺れに基づく値でもよい。
例えば、第１の評価値は、受信電力（換言すれば電界強度）が大きいほど、小さくなる（高い品質を示す）ように定義されていてもよい。逆に、第１の評価値は、コリジョンの発生によってリトライ回数が増えるほど、大きくなる（低い品質を示す）ように定義されていてもよい。
また、通信装置１００が受信したパケットが、チェックサムや巡回冗長検査（Cyclic Redundancy Check）などの誤り検出符号を含む場合、通信装置１００は、受信したパケットがエラーを含む率を認識することができる。そこで、第１の評価値は、パケットエラー率が高いほど、大きくなる（低い品質を示す）ように定義されていてもよい。
なお、本明細書においては、特定のプロトコルにしたがって通信装置間で送受信されるＰＤＵ（Protocol Data Unit）を「パケット」という。ただし、「パケット」という用語は、上記「特定のプロトコル」を限定することを意図したものでもなく、上記「特定のプロトコル」がどのレイヤのプロトコルであるかを限定することを意図したものでもない。
また、通信装置１００は、第３の通信装置にパケットを送信した後に、所定時間以内に第３の通信装置からＡＣＫ（acknowledgment）信号を受信することができなければ、パケットが消失したと見なしてもよい。
あるいは、通信装置１００は、第３の通信装置にパケットを送信した後に、所定時間以内にＡＣＫ信号を受信することができなければ、パケットの送信を再度試みてもよい。そして、通信装置１００は、必要に応じて所定回数までのリトライを行い、所定回数のリトライを行ってもなおＡＣＫ信号を受信することができなければ、パケットが消失したと見なしてもよい。
いずれにしろ、通信装置１００は、パケットロス率を認識することができる。そこで、第１の評価値は、パケットロス率が高いほど、大きくなる（低い品質を示す）ように定義されていてもよい。
また、通信装置１００は、第３の通信装置との間のスループットを計測してもよい。そして、第１の評価値は、スループットが大きいほど、小さくなる（高い品質を示す）ように定義されていてもよい。正確なスループットの計測は必ずしも容易ではないが、例えば、通信装置１００は、テストパケットを用いて、スループットの近似値を得てもよい。
さらに、ネットワーク内の各通信装置が、ある種の制御パケットを定期的に送信するように設定される実施形態では、第１の評価値は、制御パケットの受信間隔の揺れが大きいほど、大きくなる（低い品質を示す）ように定義されていてもよい。例えば、アドホックネットワークでは、各通信装置は、隣接する通信装置に存在を通知するために、「ハローパケット」などと呼ばれる制御パケットを定期的に送信することがある。
この場合、通信装置１００と第３の通信装置の間のリンクの通信品質が非常に良ければ、定期的に第３の通信装置から送信されるハローパケットは、すべて正常に通信装置１００で受信される。したがって、ハローパケットの受信間隔の揺れはほとんどゼロである。
逆に、通信装置１００と第３の通信装置の間のリンクの通信品質が悪ければ、定期的に第３の通信装置から送信されるハローパケットのうちいくつかは、通信装置１００で受信されない。その結果、通信装置１００でのハローパケットの受信間隔は均等でなくなり、受信間隔の揺れが拡大する。
したがって、第１の評価値は、ハローパケットの受信間隔の揺れが大きいほど、大きくなる（低い品質を示す）ように定義されていてもよい。受信間隔の揺れは、例えば、受信間隔の分散または標準偏差によって表すことができる。
以上のように、第１の評価値の具体的な定義は実施形態に応じて様々である。しかし、第１の評価値の具体的な定義がどうであれ、経路情報記憶部１０５が第１の評価値をさらに記憶している場合、ボトルネック判定部１０３は、第２の送信データ量と第１の評価値とを基に計算した第１の値と第１の閾値を比較することができる。
そして、ボトルネック判定部１０３は、第１の値が第１の閾値より大きい場合に、「第２の送信データ量は所定の基準を超えている」と判定することができる。第２の送信データ量が同じであっても、第１の評価値が異なれば、通信装置１００が過負荷に陥るか否かは異なる。よって、単に第２の送信データ量だけに基づく判定よりも、上記のように第１の評価値を考慮に入れた判定の方が好ましい。
また、経路情報記憶部１０５は、第３の通信装置と通信装置１００との間の通信品質の第１の評価値だけでなく、１つまたは複数の第６の通信装置の各々と通信装置１００との間の通信品質の第２の評価値をさらに記憶していてもよい。
この場合、ボトルネック判定部１０３は、第２の送信データ量と第１の評価値と第２の評価値を使った所定の計算を行い、計算結果として得られる第２の値を第２の閾値と比較してもよい。そして、ボトルネック判定部１０３は、第２の値が第２の閾値より大きい場合に、「第２の送信データ量は所定の基準を超えている」と判定してもよい。
第２の評価値も、第１の評価値と同様の指標に基づいて定義される。換言すれば、第１と第２の評価値は、１つまたは複数の同じ指標に基づいて、第３と第６の通信装置に対してそれぞれ定義される評価値である。
第２の値は、第２の送信データ量が多いほど大きくなるように定義されている。また、第２の値は、第１の評価値が高い品質を示すほど（つまり第１の評価値が小さいほど）小さくなるように、かつ、第２の評価値が高い品質を示すほど（つまり第２の評価値が小さいほど）小さくなるようにも、定義されている。
第２の値を得るための上記の所定の計算の典型例の１つは、第１の評価値の逆数と、１つまたは複数の第６の通信装置各々に対応する各第２の評価値の逆数との和によって、第２の送信データ量を割る計算である。
つまり、通信装置１００が第２の通信装置宛のデータを送る際に直接の宛先として選択可能な通信装置の数を重み付けして数えた結果により、第２の送信データ量を割った値が、第２の値である。重みとしては、上記の例のように、評価値の逆数が利用可能である。
なお、通信装置１００が第２の通信装置宛のデータを送る際に直接の宛先として選択可能な通信装置の数は、換言すれば、通信装置１００が潜在的に選択可能な送信経路の数である。よって、上記のように通信装置の数を重み付けして数えた結果のことを、以下では「重み付け送信経路数」ともいう。
品質の良いリンクで通信装置１００と結ばれた通信装置ほど、対応する評価値が小さいので、重みの値（例えば、評価値の逆数）は大きい。よって、品質の良いリンクで通信装置１００と結ばれた通信装置が多いほど、重み付け送信経路数は大きい。逆に、品質の悪いリンクで通信装置１００と結ばれた通信装置が多いほど、重み付け送信経路数は小さい。また、そもそも通信装置１００と結ばれた通信装置の数自体が少なければ、当然ながら重み付け送信経路数は小さい。
そして、上記の例では、第２の値は、第２の送信データ量を重み付け送信経路数で割ることにより得られるので、重み付け送信経路数が大きいほど、第２の値は小さい。つまり、品質の良いリンクで通信装置１００と結ばれた通信装置が多いほど、第２の値は小さい。
換言すれば、第２の値が第２の閾値を超えた場合は、品質の良いリンクで通信装置１００と結ばれた通信装置が不足しており、通信装置１００はボトルネックになり得る。そこで、ボトルネック判定部１０３は、上記のとおり、第２の値が第２の閾値より大きい場合に、「第２の送信データ量は所定の基準を超えている」と判定してもよい。
このように第２の評価値をも利用することの利点は、ネットワークの状況の動的な変化に応じて、通信装置１００が、第２の通信装置宛のデータを経由させる隣接通信装置を切り換える場合に、通信装置１００が過負荷に陥る危険性を見積もれる点である。
つまり、ネットワークの状況の変化によっては、通信装置１００が、第２の通信装置宛のデータを、第３の通信装置ではなく、第６の通信装置のうちの１つを介して送信するように、動作を切り換えるかもしれない。ここで、もし、１つまたは複数の第６の通信装置のうちのいずれもが、通信装置１００との間のリンクの通信品質が悪ければ、通信装置１００は、動作の切り換えを契機として過負荷に陥る危険性が高い。つまり、通信装置１００は、ネットワークの状況の動的な変化に対する頑健性が低い。
他方、実際にネットワークの状況が変化する前に、頑健性の低さを予め検出することが可能であれば、例えば、通信装置１００の近くに新たな通信装置を追加したり、通信装置１００の位置を移動させたり、といった何らかの対策をとることができる。その結果、実際にネットワークの状況が変化した際に通信装置１００が過負荷に陥ることを予防することも可能である。
なお、ボトルネック判定部１０３は、例えば、第２の送信データ量と所定の閾値の比較結果と、第１の値と第１の閾値の比較結果と、第２の値と第２の閾値の比較結果とを組み合わせて、最終的な判定を行ってもよい。
また、通知受信部１０１が第４の通信装置から受信する第１の送信データ量の通知は、独立したパケットとして送られてもよい。しかし、ネットワークの負荷軽減という観点からは、第４の通信装置から第１の通信装置を介して第２の通信装置宛に送られ、かつ第１の送信データ量の計量の対象である第１のデータが、第１の送信データ量の通知を含むことが好ましい。
第１のデータは、具体的にはデータパケットであってもよい。第１のデータが第１の送信データ量の通知を含む場合、送信量通知部１０２は、第１のデータを第３の通信装置に転送するときに、第１のデータの中に第２の送信データ量の通知を含めることにより、第２の送信データ量を第３の通信装置に通知する。
あるいは、ネットワークの負荷軽減という観点からは、第４の通信装置がブロードキャストする第２のデータが、通信装置１００を識別する情報とともに第１の送信データ量の通知を含むことも好ましい。第２のデータが第１の送信データ量の通知を含む場合、送信量通知部１０２は、次のようにして第２の送信データ量を第３の通信装置に通知する。
つまり、送信量通知部１０２は、第３のデータをブロードキャストするときに、第３のデータの中に第２の送信データ量の通知を、第３の通信装置を識別する情報とともに含めることにより、第２の送信データ量を第３の通信装置に通知する。なお、第２と第３のデータは、具体的にはハローパケットであってもよい。
上記のようにデータパケットまたはハローパケットに送信データ量の通知が含まれる場合、ボトルネックの予測または検出のためにネットワーク上に新たに加わる負荷は、わずかである。すなわち、新たに別のパケットが送信されることもなく、単にデータパケットまたはハローパケットのペイロード長が、送信データ量の通知のぶんだけ長くなるだけである。
ところで、図１に示した通信装置１００は、例えば図２または図３に示すハードウェアにより実現されてもよい。例えば、通信装置１００を含むネットワークが無線ネットワークである場合、図１の通信装置１００は、具体的には図２の通信装置２００により実現されてもよい。また、通信装置１００を含むネットワークが有線ネットワークである場合、図１の通信装置１００は、具体的には図３の通信装置３００により実現されてもよい。
図２の通信装置２００は、ＭＰＵ（MicroProcessing Unit）２０１と、タイマＩＣ（Integrated Circuit）２０２と、ＤＲＡＭ（Dynamic Random Access Memory）２０３と、フラッシュメモリ２０４を有する。通信装置２００は、フラッシュメモリ２０４の代わりに他の不揮発性メモリを有していてもよい。
ＭＰＵ２０１は、フラッシュメモリ２０４に記憶されたプログラムをＤＲＡＭ２０３にロードし、ＤＲＡＭ２０３をワークエリアとして使いながらプログラムを実行する。タイマＩＣ２０２は、特定の処理をＭＰＵ２０１が定期的に行うことができるようにするために、適宜のタイミングで割り込み信号を出力する。
通信装置２００はさらに、無線通信モジュールを有する。無線通信モジュールとしては、例えば、図２に例示したような、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５や８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６などが利用可能である。なお、本明細書において「ＰＨＹ／ＭＡＣチップ」とは、物理層とＭＡＣ（Media Access Control）副層の処理を行うハードウェア回路のことである。
８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１５．４規格にしたがった無線通信機能を提供する。また、８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６は、ＩＥＥＥ ８０２．１１ｂ規格にしたがった無線通信機能を提供する。通信装置２００は、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５と８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６の双方を有してもよいし、一方のみを有していてもよい。あるいは、通信装置２００は、他の無線通信規格にしたがった別のＰＨＹ／ＭＡＣチップを有していてもよい。
さらに、通信装置２００は、センサ２０７を有していてもよい。センサ２０７は、画像センサ、温度センサ、湿度センサ、あるいは圧力センサなど、任意のセンサでよい。
そして、タイマＩＣ２０２はＩ２Ｃ／ＰＩＯ（Inter-Integrated Circuit or Parallel Input/Output）バス２０８を介してＭＰＵ２０１と接続されている。また、ＤＲＡＭ２０３、フラッシュメモリ２０４、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５、８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６、およびセンサ２０７は、ＰＣＩ（Peripheral Component Interconnect）バス２０９を介してＭＰＵ２０１と接続されている。
例えば、通信装置２００は、通常の通信をＩＥＥＥ８０２．１５．４規格にしたがって行い、図１に関して説明した、送信ボトルネック通知部１０４から第５の通信装置への通知のみをＩＥＥＥ ８０２．１１ｂ規格にしたがって行ってもよい。つまり、通信装置２００は、通常は、低消費電力が特長のＩＥＥＥ ８０２．１５．４規格にしたがって、通信を行ってもよい。そして、通信装置２００は、緊急の警告を通知する際だけ、ＩＥＥＥ ８０２．１５．４規格と比べて１ホップでの通信距離がより長いＩＥＥＥ ８０２．１１ｂ規格にしたがって、通信を行ってもよい。
なお、ここで上記「通常の通信」の例は、センサ２０７が出力するデータをペイロードに含むデータパケットの送受信である。上記「通常の通信」の別の例は、ハローパケットやＡＣＫパケットなどの制御パケットの送受信である。
また、上記のとおり、図１の通知受信部１０１が第４の通信装置から受信する第１の送信データ量の通知は、専用の制御パケットにより実現されてもよいが、通常の通信で使われるパケットに付加されることが好ましい。なぜなら、通常の通信で使われるパケットに第１の送信データ量の通知が付加される場合、新たな専用の制御パケットの送信にともなう種々のオーバヘッドが生じないので、第１の送信データ量の通知のために生じるトラヒックの増大を最低限に抑えられるからである。
同様に、図１の送信量通知部１０２が第３の通信装置に送信する第２の送信データ量の通知も、通常の通信で使われるパケットに付加されることが好ましい。よって、以下では、第１と第２の送信データ量の通知が、通常の通信で使われるパケットに付加される場合について説明する。
この場合、図１の通知受信部１０１は、図２の８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現される。８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は受信したパケットをＤＲＡＭ２０３に出力し、パケットの受信をＭＰＵ２０１に通知する。
第１の送信データ量の通知を含むパケットを第４の通信装置が送信した場合、送信量通知部１０２の一部として動作するＭＰＵ２０１は、受信されたパケットの中から、第１の送信データ量の通知を抽出する。また、ＭＰＵ２０１は、第１の送信データ量を第４の通信装置と関連付けて、ＤＲＡＭ２０３に記憶する。
そして、ＭＰＵ２０１は、ＤＲＡＭ２０３を参照して、１つまたは複数の第４の通信装置から通知されたそれぞれの第１の送信データ量と、通信装置２００自身が所定期間に生成して第２の通信装置宛に送信するデータの量を足す。以上のようにして、ＭＰＵ２０１は、加算により第２の送信データ量を求める。なお、通信装置２００自身が生成して第２の通信装置宛に送信するデータの具体例は、例えば、センサ２０７が出力するデータをペイロードに含むデータパケットである。
そして、ＭＰＵ２０１は、データパケットまたはハローパケットなどの、通常の通信で使われるパケットを第３の通信装置に送信する（またはブロードキャストする）ときに、当該パケットに第２の送信データ量の通知を付加する。すると、第２の送信データ量の通知を含むパケットが、送信量通知部１０２の一部としての８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５を介して第３の通信装置に送信される。
また、ＭＰＵ２０１は、図１のボトルネック判定部１０３としても動作する。つまり、ＭＰＵ２０１は、上記のようにして計算した第２の送信データ量が所定の基準を超えているか否かを判定する。所定の基準の具体例は、図１に関して説明したとおりである。
そして、ＭＰＵ２０１は、送信ボトルネック通知部１０４の一部としても動作する。すなわち、第２の送信データ量が所定の基準を超えている場合、ＭＰＵ２０１は、「通信装置２００はネットワークにおけるボトルネックである」と判定する。そして、ＭＰＵ２０１は、判定結果を第５の通信装置に通知するためのパケットを生成する。送信ボトルネック通知部１０４の一部としての８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６は、ＭＰＵ２０１により生成されたパケットを送信する。
もちろん、実施形態によっては、送信ボトルネック通知部１０４から第５の通信装置への通知も、通常の通信と同じ通信規格にしたがって行われてもよい。例えば、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５が、通知受信部１０１の一部として動作し、かつ送信量通知部１０２の一部としても動作し、かつ送信ボトルネック通知部１０４の一部としても動作する実施形態も、可能である。
なお、図１の経路情報記憶部１０５は、ＤＲＡＭ２０３またはフラッシュメモリ２０４により実現される。以上のように、通信装置１００を含むネットワークが無線ネットワークである場合、図１の通信装置１００は、具体的には図２の通信装置２００により実現されてもよい。
他方、通信装置１００を含むネットワークが有線ネットワークである場合、図１の通信装置１００は、具体的には図３の通信装置３００により実現されてもよい。
図３の通信装置３００は、４つの物理ポート３０１ａ〜３０１ｄと、対応する物理ポート３０１ａ〜３０１ｄにそれぞれ接続された４つのＰＨＹチップ３０２ａ〜３０２ｄを有する。もちろん、物理ポート３０１ａ〜３０１ｄの数は、図３に例示した４以外の任意の数でもよい。
通信装置３００はさらに、４つのＰＨＹチップ３０２ａ〜３０２ｄとそれぞれＭＩＩ（Media Independent Interface）を介して接続されたＦＰＧＡ（Field Programmable Gate Array）３０３を有する。ＦＰＧＡ３０３は、タイマ３０４を含む。タイマ３０４は、定期的な処理の実行を実現するための割り込み信号を出力する。
また、通信装置３００は、ＦＰＧＡ３０３に接続された、ＦＰＧＡ３０３から参照可能なメモリ３０５を有する。メモリ３０５は、例えば、ＣＡＭ（Content Addressable Memory）と、ＳＲＡＭ（Static Random Access Memory）と、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）を含んでもよい。
例えば、ＳＲＡＭは、ＦＰＧＡ３０３の動作を定義するＬＵＴ（Look-Up Table）を記憶してもよい。また、ＣＡＭの検索結果としてＳＲＡＭのアドレスが得られるように、メモリ３０５が構成されていてもよい。
そして、通信装置３００は、ＦＰＧＡ３０３に接続されたＭＰＵ３０６と、ＭＰＵ３０６に接続された、ＭＰＵ３０６から参照可能なメモリ３０７を含む。メモリ３０７は、例えば、ワークエリア用のＤＲＡＭと、プログラムを記憶するための不揮発性メモリ（例えばフラッシュメモリ）を含んでもよい。
また、通信装置３００は、ＭＰＵ３０６に接続されたセンサ３０８をさらに含んでもよい。センサ３０８は、図２のセンサ２０７と同様に、任意のセンサでよい。
ところで、有線ネットワークにおいて互いに隣接する通信装置同士は、直接ケーブルで接続されている。例えば、図１に関して説明した第１の通信装置である通信装置１００が図３の通信装置３００により実現される場合、通信装置３００には４つの物理ポート３０１ａ〜３０１ｄがあるので、通信装置３００に隣接する通信装置は最大で４つまでである。
以下では説明の便宜上、物理ポート３０１ａには第３の通信装置が接続されており、物理ポート３０１ｂには第４の通信装置が接続されているものとする。また、物理ポート３０１ｃには第６の通信装置が接続されており、物理ポート３０１ｄにはもう１つの第６の通信装置が接続されているものとする。
すると、第４の通信装置から第１の送信データ量の通知を受信する図１の通知受信部１０１は、具体的には、物理ポート３０１ｂとＰＨＹチップ３０２ｂにより実現される。ＰＨＹチップ３０２ｂは、第４の通信装置から受信したパケットをＦＰＧＡ３０３に出力する。
なお、通信装置３００が実行する各種処理のうち、どの処理をＦＰＧＡ３０３が実行し、どの処理をＭＰＵ３０６が実行するかは、実施形態に応じて任意である。例えば、データパケットのルーティングをＦＰＧＡ３０３がＬＵＴにしたがって行い、ルーティング以外の処理をＭＰＵ３０６が行ってもよい。
例えば、有線ネットワークには、「隣接する通信装置の数の上限が物理ポートの数により決まっている」という特徴がある。また、有線リンクにおいては、無線リンクのような品質の変動は無視することができる。つまり、無線リンクの状態は連続値で表されることが望ましいが、有線リンクの状態は「接続されているか、切断されているか」という２値で表しても何ら問題はない。
したがって、有線ネットワーク（より具体的には有線アドホックネットワーク）におけるルーティングは、ＦＰＧＡ３０３のような組み合わせ論理回路により実現するのに適している。よって、ルーティングをＦＰＧＡ３０３が行い、パケットの内容に応じたより複雑な処理は、ＭＰＵ３０６が行ってもよい。
以下では説明の便宜上、ＦＰＧＡ３０３がルーティングを行い、他の処理はＭＰＵ３０６が行うものとする。また、通信装置３００が受信したパケットは、メモリ３０５またはメモリ３０７に一時的にバッファリングされる。
よって、第４の通信装置からの第１の送信データ量の通知を含むパケットが物理ポート３０１ｂで受信されると、送信量通知部１０２の一部として動作するＭＰＵ３０６は、パケットの中から、第１の送信データ量の通知を抽出する。また、ＭＰＵ３０６は、第１の送信データ量を第４の通信装置と関連付けて、メモリ３０７に記憶する。
そして、ＭＰＵ３０６は、メモリ３０７を参照して、１つまたは複数の第４の通信装置から通知されたそれぞれの第１の送信データ量と、通信装置３００自身が所定期間に生成して第２の通信装置宛に送信するデータの量を足す。以上のようにして、ＭＰＵ３０６は、加算により第２の送信データ量を求める。
なお、上記仮定では、第４の通信装置は、物理ポート３０１ｂに接続された１つの通信装置のみである。また、通信装置３００自身が生成して第２の通信装置宛に送信するデータの具体例は、例えば、センサ３０８が出力するデータをペイロードに含むデータパケットである。
ＭＰＵ３０６は、通常の通信で使われるパケットを第３の通信装置に送信するときに、当該パケットに第２の送信データ量の通知を付加する。すると、第２の送信データ量の通知を含むパケットが、送信量通知部１０２の一部としてのＰＨＹチップ３０２ａと物理ポート３０１ａを介して、第３の通信装置に送信される。
また、ＭＰＵ３０６は、図１のボトルネック判定部１０３としても動作する。つまり、ＭＰＵ３０６は、上記のようにして計算した第２の送信データ量が所定の基準を超えているか否かを判定する。所定の基準の具体例は、図１に関して説明したとおりである。
そして、ＭＰＵ３０６は、送信ボトルネック通知部１０４の一部としても動作する。すなわち、第２の送信データ量が所定の基準を超えている場合、ＭＰＵ３０６は、「通信装置３００はネットワークにおけるボトルネックである」と判定する。そして、ＭＰＵ３０６は、判定結果を第５の通信装置に通知するためのパケットを生成する。
生成されたパケットは、物理ポート３０１ａ〜３０１ｄの一部または全部から送信される。図１に関して説明したように、送信ボトルネック通知部１０４が判定結果を通知する第５の通信装置は、１つでもよいし複数あってもよい。
例えば、送信ボトルネック通知部１０４は、ブロードキャストによって複数の第５の通信装置に判定結果を通知してもよい。この場合、送信ボトルネック通知部１０４は、物理ポート３０１ａ〜３０１ｄとＰＨＹチップ３０２ａ〜３０２ｄとＦＰＧＡ３０３とＭＰＵ３０６により実現される。
あるいは、送信ボトルネック通知部１０４は、特定の１つの第５の通信装置に判定結果を通知してもよい。この場合、送信ボトルネック通知部１０４は、ＭＰＵ３０６だけではなく、第５の通信装置宛のパケットのルーティング先を決定するＦＰＧＡ３０３を含む。また、送信ボトルネック通知部１０４は、ＦＰＧＡ３０３により決定された直接の送信先と接続されている、いずれか１つの物理ポートと、当該物理ポートと接続されているＰＨＹチップをさらに含む。
なお、上記のようにＦＰＧＡ３０３がパケットのルーティングを行う（すなわち、パケットの最終的な送信先から直接の送信先を決定する）場合、図１の経路情報記憶部１０５は、ＦＰＧＡ３０３が参照するメモリ３０５により実現されてもよい。
ところで、以上の図１〜３に関する説明では、第１〜６の通信装置を含むネットワークについて言及した。以下では、第１〜６の通信装置の関係についての理解を助けるため、ネットワークの具体例を参照して、より詳しい説明を行う。
図４は、ネットワークの第１の例を示す図である。図４のネットワーク４００は、ノードＡ〜ＩとゲートウェイＧＷ１を含む。ネットワーク４００は、無線アドホックネットワークでもよいし、有線アドホックネットワークでもよい。
ネットワーク４００におけるデータの最終的な送信先である第２の通信装置は、図４の例では、ゲートウェイＧＷ１である。また、図４の例では、送信ボトルネック通知部１０４が判定結果を通知する第５の通信装置も、ゲートウェイＧＷ１であるとする。第１実施形態では、ゲートウェイＧＷ１以外のノードＡ〜Ｈは、いずれも、図１の通信装置１００と同様に構成された通信装置である。
図４において破線の両向き矢印または実線の片向き矢印で結ばれているノード同士は、互いに隣接しており、互いに１ホップで通信可能である。また、実線の片向き矢印は、宛先がゲートウェイＧＷ１のパケットの送信のときに実際に選択される経路を示す。
例えば、ノードＤを例に矢印の意味を説明すれば以下のとおりである。
ノードＡからノードＤに向かう実線の矢印は、「ノードＡは、ゲートウェイＧＷ１宛のパケットを送信する際に、直接の送信先としてノードＤを選択する」ということを示す。つまり、第１の通信装置としてノードＡに注目した場合、ノードＤは第３の通信装置である。逆に、第１の通信装置としてノードＤに注目した場合、ノードＡは第４の通信装置であり、ルーティングアルゴリズムによっては第６の通信装置でもある。
また、ノードＤからノードＥに向かう実線の矢印は、「ノードＤは、ゲートウェイＧＷ１宛のパケットを送信する際に、直接の送信先としてノードＥを選択する」ということを示す。つまり、第１の通信装置としてノードＤに注目した場合、ノードＥは第３の通信装置である。逆に、第１の通信装置としてノードＥに注目した場合、ノードＤは第４の通信装置であり、ルーティングアルゴリズムによっては第６の通信装置でもある。
そして、ノードＢとノードＤを結ぶ破線の矢印は、以下の３つのことを示す。すなわち、第１に、ノードＢとノードＤは、物理的には１ホップでパケットを送受信することが可能である。第２に、ノードＢがゲートウェイＧＷ１宛のパケットを送信するときに、ノードＢが直接の送信先として選択するノードは、ノードＤではない。第３に、ノードＤがゲートウェイＧＷ１宛のパケットを送信するときに、ノードＤが直接の送信先として選択するノードは、ノードＢではない。
つまり、第１の通信装置としてノードＢに注目した場合、ノードＤは第６の通信装置かもしれないが、第３の通信装置ではないし、第４の通信装置でもない。逆に、第１の通信装置としてノードＤに注目した場合、ノードＢは第６の通信装置かもしれないが、第３の通信装置ではないし、第４の通信装置でもない。
以上説明した矢印の意味によれば、図４のネットワーク４００は、以下のように構成されている。
ノードＡは、ノードＢおよびＤと隣接しているが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＤを送信先として選択する。ノードＢは、ノードＡ、Ｃ、ＤおよびＥと隣接しているが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＥを送信先として選択する。ノードＣは、ノードＢおよびＥと隣接しているが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＥを送信先として選択する。
また、ノードＤは、ノードＡ、ＢおよびＥと隣接しているが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＥを送信先として選択する。ノードＥは、ノードＢ、Ｃ、ＤおよびＦと隣接しているだが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＦを送信先として選択する。ノードＦは、ノードＥ、Ｇ、ＨおよびＩと隣接しているが、ゲートウェイＧＷ１宛のパケットの送信のときにはノードＨを送信先として選択する。
そして、ノードＧは、ノードＦおよびＨならびにゲートウェイＧＷ１と隣接している。また、ノードＨは、ノードＦ、ＧおよびＩならびにゲートウェイＧＷ１と隣接している。さらに、ノードＩは、ノードＦおよびＨならびにゲートウェイＧＷ１と隣接している。これらのノードＧ、ＨおよびＩは、ゲートウェイＧＷ１宛のパケットの送信のときにはゲートウェイＧＷ１自体を送信先として選択する。
以上の説明から明らかなように、第１の通信装置としてノードＡ、Ｂ、Ｃ、ＧまたはＩに注目した場合、第４の通信装置は存在しない。なぜなら、ノードＡ、Ｂ、Ｃ、ＧまたはＩに向かう実線矢印はないからである。
このように、第４の通信装置が存在しない場合、第１の通信装置としての図１の通信装置１００において、通知受信部１０１は、第１の送信データ量の通知を受信しない。この場合、送信量通知部１０２は、第１の送信データ量をゼロと見なす。したがって、送信量通知部１０２は、通信装置１００自身が所定期間に生成する第２の通信装置宛のデータの量を、第２の送信データ量として第３の通信装置に通知する。
また、ノードＥに向かう実線の矢印は３本あるので、第１の通信装置としてノードＥに注目した場合には、第４の通信装置が３つある（すなわち３つのノードＢ、ＣおよびＤが、第４の通信装置である）。一方、第１の通信装置としてノードＤに注目した場合には、上記のように、第４の通信装置に相当するノードは、１つのノードＡのみである。このように、第４の通信装置の数は、０、１、または複数である。
そして、ゲートウェイＧＷ１へ向かう実線矢印の出発点であるノードＧに第１の通信装置として注目すると、ゲートウェイＧＷ１は第２の通信装置でもあり、かつ第３の通信装置でもある。このように、第２の通信装置と第３の通信装置が同じ場合もある。
さて、以上説明したネットワーク４００において、ノードＡ〜Ｉがそれぞれ図１の通信装置１００のように構成されているものとする。この場合に、具体的にはどのようにしてボトルネックが予測または検出されるか、以下に数値の例を挙げて説明する。
簡単のため、ノードＡ〜Ｉの各々が所定期間に生成してゲートウェイＧＷ１宛に送信するデータの量を「１」とする。また、説明の便宜上、ボトルネック判定部１０３は、送信量通知部１０２から出力される第２の送信データ量が所定の閾値「５」を超えたときに「第２の送信データ量が所定の基準を超えている」と判定するものとする。
なお、所定期間の長さと、送信データ量の単位は実施形態に応じて任意である。例えば、単位量が１００ＫＢで、所定期間が５分間ならば、「１」という値は「１００ＫＢ／５分間」の意味であり、「５」という値は「５００ＫＢ／５分間」の意味である。
また、送信データ量は、データパケットのペイロード長に基づいて計量されてもよい。あるいは、データパケットが固定長の場合は、送信データ量は、データパケットの個数（換言すれば送信回数）に基づいて計量されてもよい。例えば、所定期間が３０分の場合、「１」という値が「１回／３０分」を意味してもよい。
上記のとおり、第１の通信装置としてノードＡに注目した場合、第４の通信装置は存在しない。よって、ノードＡの送信量通知部１０２は、「１」という送信データ量をノードＤに通知する。
同様に、ノードＢの送信量通知部１０２は、「１」という送信データ量をノードＥに通知する。また、ノードＣの送信量通知部１０２も、同様に「１」という送信データ量をノードＥに通知する。なお、１≦５なので、ノードＡ、Ｂ、Ｃのいずれにおいても、ボトルネック判定部１０３は、「第２の送信データ量は所定の基準を超えていない」と判定する。
ノードＤの通知受信部１０１は、ノードＡから「１」という送信データ量の通知を受信する。すると、ノードＤの送信量通知部１０２は、ノードＤ自身が生成してゲートウェイＧＷ１宛に送信するデータの量である「１」と、通知された送信データ量「１」を足し、和として得られた送信データ量「２」をノードＥに通知する。なお、２≦５なので、ノードＤのボトルネック判定部１０３も、「第２の送信データ量は所定の基準を超えていない」と判定する。
ノードＥの通知受信部１０１は、ノードＢからは「１」という送信データ量の通知を受信し、ノードＣからは「１」という送信データ量の通知を受信し、ノードＤからは「２」という送信データ量の通知を受信する。すると、ノードＥの送信量通知部１０２は、ノードＥ自身が生成してゲートウェイＧＷ１宛に送信するデータの量である「１」と、通知された「１」、「１」および「２」という送信データ量を足す。そして、ノードＥの送信量通知部１０２は、和として得られた送信データ量「５」をノードＦに通知する。なお、５≦５なので、ノードＥのボトルネック判定部１０３も、「第２の送信データ量は所定の基準を超えていない」と判定する。
ノードＦの通知受信部１０１は、ノードＥから「５」という送信データ量の通知を受信する。すると、ノードＦの送信量通知部１０２は、ノードＦ自身が生成してゲートウェイＧＷ１宛に送信するデータの量である「１」と、通知された送信データ量「５」を足し、和として得られた送信データ量「６」をノードＨに通知する。
なお、６＞５なので、ノードＦのボトルネック判定部１０３は、「第２の送信データ量は所定の基準を超えている」と判定する。したがって、ノードＦの送信ボトルネック通知部１０４は、「ノードＦはネットワーク４００におけるボトルネックである」と判定し、判定結果をゲートウェイＧＷ１に通知する。
また、上記のとおり、第１の通信装置としてノードＧに注目した場合、第４の通信装置は存在しない。よって、ノードＧの送信量通知部１０２は、「１」という送信データ量をゲートウェイＧＷ１に通知する。
ノードＨの通知受信部１０１は、ノードＦから「６」という送信データ量の通知を受信する。すると、ノードＨの送信量通知部１０２は、ノードＨ自身が生成してゲートウェイＧＷ１宛に送信するデータの量である「１」と、通知された送信データ量「６」を足し、和として得られた送信データ量「７」をゲートウェイＧＷ１に通知する。
なお、７＞５なので、ノードＨのボトルネック判定部１０３は、「第２の送信データ量は所定の基準を超えている」と判定する。したがって、ノードＨの送信ボトルネック通知部１０４は、「ノードＨはネットワーク４００におけるボトルネックである」と判定し、判定結果をゲートウェイＧＷ１に通知する。
また、上記のとおり、第１の通信装置としてノードＩに注目した場合、第４の通信装置は存在しない。よって、ノードＩの送信量通知部１０２は、「１」という送信データ量をゲートウェイＧＷ１に通知する。
ゲートウェイＧＷ１は、以上のようにして、ノードＧ、ＨおよびＩからそれぞれ、「１」、「７」および「１」という送信データ量の通知を受信する。また、ゲートウェイＧＷ１は、ノードＦとＨからそれぞれ、「ノードＦがボトルネックである」という通知と「ノードＨがボトルネックである」という通知を受信する。
なお、ノードＦとＨからゲートウェイＧＷ１へのボトルネックの通知は、例えば、通常のデータパケットと同様にネットワーク４００内を実線矢印に沿ってルーティングされることにより、ゲートウェイＧＷ１まで送信されてもよい。
また、ゲートウェイＧＷ１は、ボトルネックの通知を受けたら、通知された内容をディスプレイに表示してもよい。あるいは、ゲートウェイＧＷ１は、例えばネットワーク管理者宛に電子メールでボトルネックの通知を送信してもよい。すると、ディスプレイを見るか電子メールを受信するかしたネットワーク管理者は、例えば、新たなノードを設置するなどの適宜の対策をとることができる。
以上、図１〜４を参照して説明した第１実施形態によれば、ネットワークにおけるボトルネックの予測または検出が可能となるので、非常に有益である。また、第１の送信データ量の通知と第２の送信データ量の通知を、通常の通信で用いるパケットに含めることにより、余計なトラヒックの増加を招かずに、ネットワーク４００内の各ノードが自律的にボトルネックを予測または検出することが可能となる。
ところで、上記の第１実施形態では、ボトルネック判定部１０３は、通信装置１００が受信するデータの量を示す第１の送信データ量と、通信装置１００自身が生成する第２の通信装置宛のデータの量とを合計した第２の送信データ量に基づく判断を行う。しかしながら、実施形態によっては、第２の通信装置宛のデータを自ら生成することのない通信装置（すなわち中継専用の通信装置）もあり得る。また、ある通信装置が、もしも隣接する他の通信装置からのデータ受信だけで過負荷に陥るならば、さらに第２の通信装置宛のデータを自ら生成して送信したら、過負荷状態が悪化するのは明らかである。
そこで、図５に示す第２実施形態においては、通信装置は、自らが生成するデータの量には関係なく、隣接する他の通信装置からのデータ受信の量に基づいて、通信装置自身がネットワーク内のボトルネックか否かを判断する。
図５は、第２実施形態の通信装置のブロック構成図である。図５の通信装置５００は、複数の通信装置を含むネットワークで使われる。ネットワークは、例えば、有線または無線のアドホックネットワークであり、より具体的には、図４のネットワーク４００でもよい。以下、図５に関する説明においては、便宜上、ネットワーク内の以下の通信装置をそれぞれ「第１の通信装置」〜「第４の通信装置」という。なお、図５の説明における第１〜第４の通信装置は、図１〜４の説明における第１〜第４の通信装置とは異なるので注意されたい。
便宜上、通信装置５００自体を「第１の通信装置」という。
また、便宜上、通信装置５００に隣接する１つ以上の通信装置をそれぞれ「第２の通信装置」という。
そして、便宜上、ネットワーク内でのデータの最終的な送信先である、特定の通信装置を「第３の通信装置」という。第３の通信装置は、例えばゲートウェイＧＷ１でもよい。
また、「通信装置５００は、ネットワーク内で通信負荷の集中するボトルネックである」と通信装置５００自身が判定した場合に、通信装置５００が判定結果を通知する先の予め決められた通信装置を、便宜上、「第４の通信装置」という。
なお、ネットワーク内の特定の１つの通信装置が、第４の通信装置として予め決められていてもよい。例えば、第４の通信装置と第３の通信装置が同じでもよい。あるいは、複数の通信装置が、複数の第４の通信装置として予め決められていてもよい。例えば、ネットワーク内の通信装置５００以外のすべての通信装置が、複数の第４の通信装置として予め決められていてもよい。
さて、図５の通信装置５００は、以上のような第１〜第４の通信装置を含むネットワークにおける第１の通信装置である。そして、図５に示すように、通信装置５００は、通知受信部５０１、ボトルネック判定部５０２、および受信ボトルネック通知部５０３を有する。
通知受信部５０１は、通信装置５００に隣接する１つ以上の第２の通信装置の各々から、各第２の通信装置が所定期間に送信する第３の通信装置宛のデータの第１の送信データ量の通知を受信する。
なお、通知受信部５０１の動作は図１の通知受信部１０１と類似であり、所定期間の長さは任意でよい。また、第１実施形態と同様に、トラヒック抑制の観点からは、第１の送信データ量は、専用の制御パケットを用いて通知されるよりも、通常の通信で使われるパケットに付加される形で通知される方が好ましい。
ボトルネック判定部５０２は、１つ以上の第２の通信装置の各々から通知されたそれぞれの第１の送信データ量を集約した第２の送信データ量を計算する。さらに、ボトルネック判定部５０２は、計算した第２の送信データ量が所定の基準を超えているかを判定する。
なお、ボトルネック判定部５０２が行う集約は、例えば、単純な加算でもよい。また、ボトルネック判定部５０２は、計算した第２の送信データ量を所定の閾値と比較し、第２の送信データ量が所定の閾値を超えていれば「第２の送信データ量は所定の基準を超えている」と判定してもよい。
そして、「第２の送信データ量が所定の基準を超えている」とボトルネック判定部５０２が判定した場合に、受信ボトルネック通知部５０３は、「通信装置５００はネットワークにおけるボトルネックである」ということを第４の通信装置に通知する。第４の通信装置への通知は、換言すれば、「通信装置５００が受信するデータの量は過剰であり、データの受信だけで通信装置５００は過負荷に陥ってしまう」という警告である。
よって、受信ボトルネック通知部５０３から第４の通信装置への通知にしたがって、過剰な負荷を軽減するための対策がとられることが望ましい。なお、対策の例については、第１実施形態に関して説明したので、説明を省略する。
また、以上説明した通信装置５００は、例えば図２または図３に示すハードウェアにより実現されてもよい。
例えば、通信装置５００を含むネットワークが無線ネットワークである場合、通信装置５００は、図２の通信装置２００により実現されてもよい。すなわち、通知受信部５０１は、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよく、ボトルネック判定部５０２は、ＭＰＵ２０１とＤＲＡＭ２０３により実現されてもよい。
そして、受信ボトルネック通知部５０３は、ＭＰＵ２０１と８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６により実現されてもよいし、ＭＰＵ２０１と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよい。また、通信装置５００が中継専用の場合、センサ２０７は省略可能である。
あるいは、通信装置５００を含むネットワークが有線ネットワークである場合、通信装置５００は、図３の通信装置３００により実現されてもよい。説明の便宜上、例えば、２つの第２の通信装置があり、２つの第２の通信装置はそれぞれ物理ポート３０１ａと３０１ｂに接続されているものとする。すると、通知受信部５０１は、具体的には、物理ポート３０１ａ〜３０１ｂとＰＨＹチップ３０２ａ〜３０２ｂにより実現される。
また、図３に関する上記の説明と同様に、ＦＰＧＡ３０３がルーティングを行い、他の処理はＭＰＵ３０６が行うものとする。すると、ボトルネック判定部５０２は、ＭＰＵ３０６とメモリ３０７により実現される。
ＭＰＵ３０６は、受信ボトルネック通知部５０３の一部としても動作する。すなわち、第２の送信データ量が所定の基準を超えている場合、ＭＰＵ３０６は、「通信装置３００はネットワークにおけるボトルネックである」と判定する。そして、ＭＰＵ３０６は、判定結果を第４の通信装置に通知するためのパケットを生成する。
生成されたパケットは、物理ポート３０１ａ〜３０１ｄの一部または全部から送信される。上記のとおり、第２実施形態における第４の通信装置は、１つでもよいし複数あってもよい。
例えば、受信ボトルネック通知部５０３がブロードキャストによって複数の第４の通信装置に判定結果を通知してもよい。この場合、受信ボトルネック通知部５０３は、物理ポート３０１ａ〜３０１ｄとＰＨＹチップ３０２ａ〜３０２ｄとＦＰＧＡ３０３とＭＰＵ３０６により実現される。
あるいは、受信ボトルネック通知部５０３は、特定の１つの第４の通信装置に判定結果を通知してもよい。この場合、受信ボトルネック通知部５０３は、ＭＰＵ３０６だけではなく、第４の通信装置宛のパケットのルーティング先を決定するＦＰＧＡ３０３を含む。また、受信ボトルネック通知部５０３は、ＦＰＧＡ３０３により決定された直接の送信先と接続されている、いずれか１つの物理ポートと、当該物理ポートと接続されているＰＨＹチップをさらに含む。
例えば、図４のネットワーク４００において、第１実施形態とは異なり、ノードＨが中継専用の通信装置であるとする。そして、ノードＡ〜ＧおよびＩは第１実施形態の通信装置１００であり、ノードＨが第２実施形態の通信装置５００であるとする。また、ボトルネック判定部５０２は、集約により得た第２の送信データ量が所定の閾値「５」を超えたときに「第２の送信データ量が所定の基準を超えている」と判定するものとする。
第１実施形態に関して説明したように、ノードＦの送信量通知部１０２は、「６」という送信データ量をノードＨに通知する。よって、ノードＨの通知受信部５０１は、ノードＦから「６」という送信データ量の通知を受信する。
図４のネットワーク４００においては、第２実施形態の第１の通信装置としてノードＨに注目すると、第２の通信装置に相当するのはノードＦのみである。よって、ノードＨのボトルネック判定部５０２は、単に、ノードＦから通知された「６」という送信データ量そのものを、集約された第２の送信データ量として認識する。そして、６＞５なので、ノードＨのボトルネック判定部５０２は、「第２の送信データ量は所定の基準を超えている」と判定し、判定結果を第４の通信装置としてのゲートウェイＧＷ１に通知する。
なお、以上説明した第２実施形態の通信装置５００は、以下のように変形されてもよい。すなわち、通信装置５００は、不図示の送信量通知部をさらに有してもよい。そして、不図示の送信量通知部は、ボトルネック判定部５０２が集約して得た第２の送信データ量を、第３の通信装置宛のデータを通信装置５００が送信する際に直接の送信先として選択可能な、通信装置５００に隣接する通信装置に、通知してもよい。不図示の送信量通知部を有するように変形された通信装置５００は、例えば、中継専用の通信装置に好適である。
なお、上記の不図示の送信量通知部は、例えば、図２の８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよい。または、上記の不図示の送信量通知部は、図３の物理ポート３０１ａ〜３０１ｄとＰＨＹチップ３０２ａ〜３０２ｄの一部または全部により実現されてもよい。
ところで、第１〜第２実施形態に関して説明したとおり、送信データ量は、通常の通信で使われるパケットに埋め込まれる形で通知されることが好ましい。そこで、以下ではより具体的に、送信データ量がデータパケットに埋め込まれる第３実施形態について、図６〜１５を参照して説明し、送信データ量がハローパケットに埋め込まれる第４実施形態について、図１６〜２１を参照して説明する。
その後、第３または第４実施形態を変形した第５〜第１１実施形態について説明する。なお、以下の説明においては、ネットワークの具体例として図４のネットワーク４００を参照する。また、ネットワーク４００は有線アドホックネットワークでもよいが、以下では説明の便宜上、ネットワーク４００が無線アドホックネットワークである場合について主に説明する。
図６は、第３実施形態におけるデータパケットの送受信に関するタイミングチャートである。図６のタイミングチャートは、図４のノードＡ〜Ｉの各々が、図７とともに後述する第３実施形態の通信装置６００である場合の、データパケットの送受信を表す。
なお、第３実施形態では、ネットワーク４００内でのデータパケットの最終的な送信先は、具体的には、ゲートウェイＧＷ１であるとする。また、ノードＡ〜Ｉの各々がボトルネックに関する判定結果を通知する先も、ゲートウェイＧＷ１であるとする。
さて、ノードＡ〜Ｉは、それぞれ適宜のタイミングでデータパケットを送信する。図６では、各データパケットは、３文字の参照符号で識別される。１文字目はデータパケットを示す「Ｄ」である。２文字目は、個々のデータパケットを識別するための数字である。
また、データパケットは、マルチホップ送信の対象であり、第３実施形態では、ホップごとにデータパケットの一部のフィールドの値が書き換えられる。そこで、ホップごとの変化を識別するため、各データパケットの参照符号の３文字目には、各ホップでの直接の送信元のノードの参照符号である英文字が使われている。
また、詳しくは図１０とともに後述するが、第３実施形態ではデータパケットが「送信トラヒック」というフィールドを含む。第１実施形態に関して説明した第１と第２の送信データ量に相当する値が、第３実施形態においては、いずれも、送信トラヒックとして設定される。そして、送信トラヒックの値が、ホップごとに書き換えられる。
図６では、個々の矢印により、個々のデータパケットの１ホップの送信を示している。そして、各矢印に重ねて描かれた矩形内の数値が、当該矢印が表すデータパケット中の送信トラヒックの値である。
なお、以下では説明の便宜上、図４に関する説明と同様に、ノードＡ〜Ｉの各々が所定期間に生成してゲートウェイＧＷ１宛に送信するデータの量の期待値を「１」とする。また、ボトルネックの判定用の閾値を「５」とする。
なお、ノードが、所定の量のデータを所定期間に生成してゲートウェイＧＷ１宛に送信するように、実際に設定されており、かつ設定にしたがって動作する場合は、上記「期待値」は、設定された所定の量のことである。よって、この場合、実際のボトルネックの検出が可能である。
また、上記「期待値」は、予定または予測される値でもよい。例えば、「設定値を変更したら新たにボトルネックが生じるおそれがないかを、実際に設定値を変更する前に調査する」といった目的で、設定変更後に予定される値が「期待値」として使われてもよい。この場合、ボトルネックの予測が可能である。
ノードＡ〜Ｉは、例えば予め決められたスケジュールにしたがって、センサから出力されたデータをペイロードとして含むデータパケットを生成して送信してもよい。あるいは、ノードＡ〜Ｉは、センサの出力の変化等に応じて、事前には決められていない可変のタイミングで、データパケットを生成して送信してもよい。すなわち、ネットワーク４００内の各ノードＡ〜Ｉがデータパケットを送信するタイミングは任意である。
また、ここで、「ネットワーク４００内のすべてのノードＡ〜Ｉが少なくとも１回ずつゲートウェイＧＷ１宛にデータパケットを送信し、それらのデータパケットがゲートウェイＧＷ１に届くのにかかる時間」のことを、便宜上「１ラウンド」ということにする。以下に説明する図６の例から理解されるように、各ノードＡ〜Ｉがどのような順序でデータパケットを送信しようとも、ネットワーク４００内におけるすべてのボトルネックが予測または検出されるまでにかかる時間は、最大でも１ラウンドである。
さて、図６には、一例として、以下のような場合が例示されている。
まず、ノードＦがデータパケットＤ１Ｆを送信する。データパケットＤ１Ｆに設定される送信トラヒックの値は「１」である。なぜなら、データパケットＤ１Ｆの送信の前には、ノードＦは他のノードからいかなるデータパケットも受信していないからである。そのため、データパケットＤ１Ｆには、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、データパケットＤ１Ｆのネットワーク４００内での最終的な宛先は、ゲートウェイＧＷ１である。しかし、図４で実線矢印により示すとおり、ノードＦがゲートウェイＧＷ１に送信するパケットは、直接的にはノードＦに隣接するノードＨに送信され、ノードＨにより中継されて、ゲートウェイＧＷ１に到達する。
以下では、ネットワーク４００内でのパケットの最終的な送信先をＧＤ（Global Destination）といい、ネットワーク４００内でのパケットの最初の送信元をＧＳ（Global Source）という。また、１ホップの送信に着目したときの、直接的な送信先をＬＤ（Local Destination）といい、直接的な送信元をＬＳ（Local Source）という。
例えば、ノードＦがゲートウェイＧＷ１宛に送信するパケットに関しては、ＧＤはゲートウェイＧＷ１であり、ＧＳはノードＦである。ＧＤとＧＳは、パケットがネットワーク４００内をマルチホップ送信される間も変化しない。
他方、ＬＤとＬＳはホップごとに変化する。つまり、ＧＤがゲートウェイＧＷ１のパケットがノードＦから送信される時点では、ＬＤはノードＨであり、ＬＳはノードＦであるが、パケットがノードＨにより中継される時点では、ＬＤはゲートウェイＧＷ１であり、ＬＳはノードＨである。したがって、上記のデータパケットＤ１Ｆに関しては、ＧＤはゲートウェイＧＷ１であり、ＧＳはノードＦであり、ＬＤはノードＨであり、ＬＳはノードＦである。
さて、ノードＨは、ノードＦからデータパケットＤ１Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ１Ｈを送信する。データパケットＤ１ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、図６の例では、ノードＨは、データパケットＤ１Ｆを受信するよりも前には、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ１Ｈの送信トラヒックには、データパケットＤ１Ｆに設定されていた「１」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「２」が設定される。そして、ノードＨが送信したデータパケットＤ１Ｈは、ゲートウェイＧＷ１に受信される。
さて、図６の例では、続いて、ノードＨがゲートウェイＧＷ１宛の新たなデータパケットＤ２Ｈを生成して送信する。図４においてノードＨからゲートウェイＧＷ１への実線矢印があるので、データパケットＤ２Ｈは、１ホップでゲートウェイＧＷ１に届く。
また、データパケットＤ２Ｈの送信の前に、ノードＨは、既にノードＦからデータパケットＤ１Ｆを受信している。よって、データパケットＤ１Ｈと同様にデータパケットＤ２Ｈにおいても、送信トラヒックとして「２」という値が設定される。そして、データパケットＤ２Ｈは、ゲートウェイＧＷ１に受信される。
また、図６の例では、続いて、ノードＤがゲートウェイＧＷ１宛の新たなデータパケットＤ３Ｄを生成して送信する。図４の実線矢印が示すように、ノードＤがゲートウェイＧＷ１に宛てて送信するデータパケットは、ノードＥ、ＦおよびＨを経由してゲートウェイＧＷ１に届く。
ここで、図６によれば、データパケットＤ３Ｄの送信の前には、ノードＤは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ３Ｄには、送信トラヒックとして、ノードＤが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。
ノードＤから送信されたデータパケットＤ３Ｄは、隣接するノードＥで受信される。ノードＥは、データパケットＤ３Ｄを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ３Ｅを送信する。データパケットＤ３ＥのＬＤとＬＳは、それぞれ、ノードＦとノードＥである。
また、図６の例では、ノードＥは、データパケットＤ３Ｄを受信するよりも前には、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ３Ｅの送信トラヒックには、データパケットＤ３Ｄに設定されていた「１」という値と、ノードＥが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「２」が設定される。そして、ノードＥが送信したデータパケットＤ３Ｅは、ノードＦに受信される。
ノードＦは、データパケットＤ３Ｅを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ３Ｆを送信する。データパケットＤ３ＦのＬＤとＬＳは、それぞれ、ノードＨとノードＦである。
また、図６によれば、ノードＦは、データパケットＤ３Ｅを受信するよりも前には、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ３Ｆの送信トラヒックには、データパケットＤ３Ｅに設定されていた「２」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「３」が設定される。そして、ノードＦが送信したデータパケットＤ３Ｆは、ノードＨに受信される。
ノードＨは、データパケットＤ３Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ３Ｈを送信する。データパケットＤ３ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、ノードＨは、データパケットＤ３Ｆの受信よりも前に、既にデータパケットＤ１Ｆを受信している。しかし、以前受信したデータパケットＤ１ＦのＬＳは、今回受信したデータパケットＤ３ＦのＬＳと等しいので、ノードＨは、データパケットＤ１Ｆに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ３Ｈの送信トラヒックには、データパケットＤ３Ｆに設定されていた「３」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「４」が設定される。そして、ノードＨが送信したデータパケットＤ３Ｈは、ゲートウェイＧＷ１に受信される。
図６の例では、続いて、ノードＡがゲートウェイＧＷ１宛の新たなデータパケットＤ４Ａを生成して送信する。図４の実線矢印が示すように、ノードＡがゲートウェイＧＷ１に宛てて送信するデータパケットは、ノードＤ、Ｅ、ＦおよびＨを経由してゲートウェイＧＷ１に届く。
ここで、図６によれば、データパケットＤ４Ａの送信の前には、ノードＡは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ４Ａには、送信トラヒックとして、ノードＡが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。
ノードＡから送信されたデータパケットＤ４Ａは、隣接するノードＤで受信される。ノードＤは、データパケットＤ４Ａを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ４Ｄを送信する。データパケットＤ４ＤのＬＤとＬＳは、それぞれ、ノードＥとノードＤである。
また、図６の例では、ノードＤは、データパケットＤ４Ａを受信するよりも前には、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ４Ｄの送信トラヒックには、データパケットＤ４Ａに設定されていた「１」という値と、ノードＤが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「２」が設定される。そして、ノードＤが送信したデータパケットＤ４Ｄは、ノードＥに受信される。
ノードＥは、データパケットＤ４Ｄを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ４Ｅを送信する。データパケットＤ４ＥのＬＤとＬＳは、それぞれ、ノードＦとノードＥである。
また、ノードＥは、データパケットＤ４Ｄの受信よりも前に、既にデータパケットＤ３Ｄを受信している。しかし、以前受信したデータパケットＤ３ＤのＬＳは、今回受信したデータパケットＤ４ＤのＬＳと等しいので、ノードＥは、データパケットＤ３Ｄに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ４Ｅの送信トラヒックには、データパケットＤ４Ｄに設定されていた「２」という値と、ノードＥが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「３」が設定される。そして、ノードＥが送信したデータパケットＤ４Ｅは、ノードＦに受信される。
ノードＦは、データパケットＤ４Ｅを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ４Ｆを送信する。データパケットＤ４ＦのＬＤとＬＳは、それぞれ、ノードＨとノードＦである。
また、ノードＦは、データパケットＤ４Ｅの受信よりも前に、既にデータパケットＤ３Ｅを受信している。しかし、以前受信したデータパケットＤ３ＥのＬＳは、今回受信したデータパケットＤ４ＥのＬＳと等しいので、ノードＦは、データパケットＤ３Ｅに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ４Ｆの送信トラヒックには、データパケットＤ４Ｅに設定されていた「３」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「４」が設定される。そして、ノードＦが送信したデータパケットＤ４Ｆは、ノードＨに受信される。
ノードＨは、データパケットＤ４Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ４Ｈを送信する。データパケットＤ４ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、ノードＨは、データパケットＤ４Ｆの受信よりも前に、既にデータパケットＤ１ＦとＤ３Ｆを受信している。しかし、以前受信したデータパケットＤ１ＦとＤ３ＦのＬＳは、いずれも、今回受信したデータパケットＤ４ＦのＬＳと等しいので、ノードＨは、データパケットＤ１ＦとＤ３Ｆに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ４Ｈの送信トラヒックには、データパケットＤ４Ｆに設定されていた「４」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「５」が設定される。そして、ノードＨが送信したデータパケットＤ４Ｈは、ゲートウェイＧＷ１に受信される。
図６の例では、続いて、ノードＣがゲートウェイＧＷ１宛の新たなデータパケットＤ５Ｃを生成して送信する。図４の実線矢印が示すように、ノードＣがゲートウェイＧＷ１に宛てて送信するデータパケットは、ノードＥ、ＦおよびＨを経由してゲートウェイＧＷ１に届く。
ここで、図６によれば、データパケットＤ５Ｃの送信の前には、ノードＣは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ５Ｃには、送信トラヒックとして、ノードＣが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。
ノードＣから送信されたデータパケットＤ５Ｃは、隣接するノードＥで受信される。ノードＥは、データパケットＤ５Ｃを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ５Ｅを送信する。データパケットＤ５ＥのＬＤとＬＳは、それぞれ、ノードＦとノードＥである。
また、ノードＥは、データパケットＤ５Ｃの受信よりも前に、既にデータパケットＤ３ＤとＤ４Ｄを受信している。ここで、データパケットＤ３ＤとＤ４Ｄは、どちらもＬＳがノードＤであるが、データパケットＤ５ＣのＬＳはノードＣである。
よって、ノードＥは、ＬＳが互いに等しい２つのデータパケットＤ３ＤとＤ４Ｄのうちで古い方のデータパケットＤ３Ｄに設定されていた送信トラヒックの値は無視するが、新しい方のデータパケットＤ４Ｄに設定されていた送信トラヒックの値は考慮に入れる。また、ノードＥは、ＬＳがノードＤとは異なるデータパケットＤ５Ｃに設定されていた送信トラヒックの値も、考慮に入れる。
よって、データパケットＤ５Ｅの送信トラヒックには、データパケットＤ４ＤとＤ５Ｃにそれぞれ設定されていた「２」と「１」という値と、ノードＥが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「４」が設定される。そして、ノードＥが送信したデータパケットＤ５Ｅは、ノードＦに受信される。
ノードＦは、データパケットＤ５Ｅを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ５Ｆを送信する。データパケットＤ５ＦのＬＤとＬＳは、それぞれ、ノードＨとノードＦである。
また、ノードＦは、データパケットＤ５Ｅの受信よりも前に、既にデータパケットＤ３ＥとＤ４Ｅを受信している。しかし、以前受信したデータパケットＤ３ＥとＤ４ＥのＬＳは、いずれも、今回受信したデータパケットＤ５ＥのＬＳと等しいので、ノードＦは、データパケットＤ３ＥとＤ４Ｅに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ５Ｆの送信トラヒックには、データパケットＤ５Ｅに設定されていた「４」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「５」が設定される。そして、ノードＦが送信したデータパケットＤ５Ｆは、ノードＨに受信される。
ノードＨは、データパケットＤ５Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ５Ｈを送信する。データパケットＤ５ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、ノードＨは、データパケットＤ５Ｆの受信よりも前に、既にデータパケットＤ１ＦとＤ３ＦとＤ４Ｆを受信している。しかし、以前受信したデータパケットＤ１ＦとＤ３ＦとＤ４ＦのＬＳは、いずれも、今回受信したデータパケットＤ５ＦのＬＳと等しいので、ノードＨは、データパケットＤ１ＦとＤ３ＦとＤ４Ｆに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ５Ｈの送信トラヒックには、データパケットＤ５Ｆに設定されていた「５」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「６」が設定される。そして、ノードＨが送信したデータパケットＤ５Ｈは、ゲートウェイＧＷ１に受信される。
また、上記の仮定より、ボトルネックの判定のための閾値は「５」であり、６＞５である。よって、ノードＨは、データパケットＤ５Ｆの受信を契機として、「ノードＨはネットワーク４００内のボトルネックである」と判定し、判定結果をゲートウェイＧＷ１に通知する。
以下では説明の便宜上、ボトルネックの判定結果の通知のことを「ボトルネック通知」ともいう。なお、図６では、ボトルネック通知の図示は省略されている。
ボトルネック通知は、例えば、通常のデータパケットと同様にしてネットワーク４００内をルーティングされてゲートウェイＧＷ１に送信されてもよい。あるいは、ボトルネック通知は、通常のデータパケットとは異なる方法でゲートウェイＧＷ１に送信されてもよい。
例えば、多重チャネルの通信システムでは、ボトルネック通知は、通常のデータパケット用に使われる無線周波数チャネルとは異なる無線周波数チャネルを介して送信されてもよい。ボトルネック通知は警報の一種なので、ボトルネック通知専用の無線周波数チャネルを用いることで、通常のデータパケットの通信とのコリジョンを避けて、確実に、ボトルネック通知を宛先のゲートウェイＧＷ１まで送信することが可能となる。ボトルネック通知専用の無線周波数チャネルが利用される場合でも、ボトルネック通知は、データパケットと同様にネットワーク内をルーティングされてよい。
あるいは、ボトルネック通知は、通常のデータパケットの通信で使われる通信規格とは異なる通信規格にしたがって送信されてもよい。例えば、通常のデータパケットは、低消費電力が特長のＩＥＥＥ ８０２．１５．４規格にしたがって送信されてもよい。一方で、ボトルネック通信は、ＩＥＥＥ ８０２．１５．４規格と比べると消費電力が高いが通信可能な距離はやや長めのＩＥＥＥ ８０２．１１ｂ規格にしたがって送信されてもよい。
すると、通常の運用では低消費電力という利点を享受することが可能である。一方で、ボトルネックが予測または検出された場合には、高出力で確実に、そして少ないホップ数で素早く、ゲートウェイＧＷ１がボトルネックを認識することが可能である。
なお、以上のように２つの異なる通信規格が用いられる場合、ボトルネック通知がルーティングされる経路は、一般には、データパケットがルーティングされる経路とは異なる。よって、各ノードは、２つの規格それぞれについて経路情報を管理する。
さて、以上のようにしてデータパケットＤ５Ｆの受信を契機にして、ノードＨが、データパケットＤ５Ｈおよびボトルネック通知を送信した後、図６の例では、続いて、ノードＢがゲートウェイＧＷ１宛の新たなデータパケットＤ６Ｂを生成して送信する。図４の実線矢印が示すように、ノードＢがゲートウェイＧＷ１に宛てて送信するデータパケットは、ノードＥ、ＦおよびＨを経由してゲートウェイＧＷ１に届く。
ここで、図６によれば、データパケットＤ５Ｂの送信の前には、ノードＢは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ５Ｂには、送信トラヒックとして、ノードＢが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。
ノードＢから送信されたデータパケットＤ６Ｂは、隣接するノードＥで受信される。ノードＥは、データパケットＤ６Ｂを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ６Ｅを送信する。データパケットＤ６ＥのＬＤとＬＳは、それぞれ、ノードＦとノードＥである。
また、ノードＥは、データパケットＤ６Ｂの受信よりも前に、既にデータパケットＤ３ＤとＤ４ＤとＤ５Ｃを受信している。ここで、データパケットＤ３ＤとＤ４Ｄは、どちらもＬＳがノードＤである。また、データパケットＤ５ＣのＬＳはノードＣであり、データパケットＤ６ＢのＬＳはノードＢである。
よって、ノードＥは、ＬＳが互いに等しい２つのデータパケットＤ３ＤとＤ４Ｄのうちで古い方のデータパケットＤ３Ｄに設定されていた送信トラヒックの値は無視するが、新しい方のデータパケットＤ４Ｄに設定されていた送信トラヒックの値は考慮に入れる。また、ノードＥは、ＬＳがノードＤとは異なるデータパケットＤ５Ｃに設定されていた送信トラヒックの値も、考慮に入れる。さらに、ノードＥは、ＬＳがノードＤともノードＣとも異なるデータパケットＤ６Ｂに設定されていた送信トラヒックの値も、考慮に入れる。
よって、データパケットＤ６Ｅの送信トラヒックには、「５」が設定される。「５」という値は、データパケットＤ４ＤとＤ５ＣとＤ６Ｂにそれぞれ設定されていた「２」と「１」と「１」という値と、ノードＥが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である。そして、ノードＥが送信したデータパケットＤ６Ｅは、ノードＦに受信される。
ノードＦは、データパケットＤ６Ｅを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ６Ｆを送信する。データパケットＤ６ＦのＬＤとＬＳは、それぞれ、ノードＨとノードＦである。
また、ノードＦは、データパケットＤ６Ｅの受信よりも前に、既にデータパケットＤ３ＥとＤ４ＥとＤ５Ｅを受信している。しかし、以前受信したデータパケットＤ３ＥとＤ４ＥとＤ５ＥのＬＳは、いずれも、今回受信したデータパケットＤ６ＥのＬＳと等しいので、ノードＦは、データパケットＤ３ＥとＤ４ＥとＤ５Ｅに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ６Ｆの送信トラヒックには、データパケットＤ６Ｅに設定されていた「５」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「６」が設定される。そして、ノードＦが送信したデータパケットＤ６Ｆは、ノードＨに受信される。
また、上記の仮定より、ボトルネックの判定のための閾値は「５」であり、６＞５である。よって、ノードＦは、データパケットＤ６Ｅの受信を契機として、「ノードＦはネットワーク４００内のボトルネックである」と判定し、ボトルネック通知をゲートウェイＧＷ１宛に送信する。
そして、ノードＨは、データパケットＤ６Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ６Ｈを送信する。データパケットＤ６ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、ノードＨは、データパケットＤ６Ｆの受信よりも前に、既にデータパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５Ｆを受信している。しかし、以前受信したデータパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５ＦのＬＳは、いずれも、今回受信したデータパケットＤ６ＦのＬＳと等しいので、ノードＨは、データパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５Ｆに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ６Ｈの送信トラヒックには、データパケットＤ６Ｆに設定されていた「６」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「７」が設定される。そして、ノードＨが送信したデータパケットＤ６Ｈは、ゲートウェイＧＷ１に受信される。
また、上記の仮定より、ボトルネックの判定のための閾値は「５」であり、７＞５である。よって、ノードＨは、データパケットＤ６Ｈの受信を契機として、再度ボトルネック通知をゲートウェイＧＷ１に送信する。
続いて、図６の例では、ノードＩがゲートウェイＧＷ１宛の新たなデータパケットＤ７Ｉを生成して送信する。図４においてノードＩからゲートウェイＧＷ１への実線矢印があるので、データパケットＤ７Ｉは、１ホップでゲートウェイＧＷ１に届く。
また、図６によれば、データパケットＤ７Ｉの送信の前には、ノードＩは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ７Ｉには、送信トラヒックとして、ノードＩが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。そして、ノードＩが送信したデータパケットＤ７Ｉは、ゲートウェイＧＷ１に受信される。
続いて、図６の例では、ノードＥがゲートウェイＧＷ１宛の新たなデータパケットＤ８Ｅを生成して送信する。図４の実線矢印が示すように、ノードＥがゲートウェイＧＷ１に宛てて送信するデータパケットは、ノードＦとＨを経由してゲートウェイＧＷ１に届く。
ここで、図６によれば、データデータパケットＤ８Ｅの送信の前に、ノードＥは、既にデータパケットＤ３ＤとＤ４ＤとＤ５ＣとＤ６Ｂを受信している。ここで、データパケットＤ３ＤとＤ４Ｄは、どちらもＬＳがノードＤである。また、データパケットＤ５ＣのＬＳはノードＣであり、データパケットＤ６ＢのＬＳはノードＢである。
よって、ノードＥは、データパケットＤ６Ｅと同様に、データパケットＤ８Ｅにおいても、送信トラヒックとして「５」を設定する。そして、ノードＥが送信したデータパケットＤ８Ｅは、ノードＦに受信される。
ノードＥから送信されたデータパケットＤ８Ｅは、隣接するノードＦで受信される。ノードＦは、データパケットＤ８Ｅを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ８Ｆを送信する。データパケットＤ８ＦのＬＤとＬＳは、それぞれ、ノードＨとノードＦである。
また、ノードＦは、データパケットＤ８Ｅの受信よりも前に、既にデータパケットＤ３ＥとＤ４ＥとＤ５ＥとＤ６Ｅを受信している。しかし、以前受信したデータパケットＤ３ＥとＤ４ＥとＤ５ＥとＤ６ＥのＬＳは、いずれも、今回受信したデータパケットＤ８ＥのＬＳと等しいので、ノードＦは、データパケットＤ３ＥとＤ４ＥとＤ５ＥとＤ６Ｅに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ８Ｆの送信トラヒックには、データパケットＤ８Ｅに設定されていた「５」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「６」が設定される。さらに、ノードＦは、データパケットＤ６Ｅを受信したときと同様に、データパケットＤ８Ｅの受信を契機として、再度ボトルネック通知をゲートウェイＧＷ１宛に送信する。
そして、ノードＦが送信したデータパケットＤ８Ｆは、ノードＨに受信される。ノードＨは、データパケットＤ８Ｆを受信すると、ＬＤとＬＳと送信トラヒックを書き換えたデータパケットＤ８Ｈを送信する。データパケットＤ８ＨのＬＤとＬＳは、それぞれ、ゲートウェイＧＷ１とノードＨである。
また、ノードＨは、データパケットＤ８Ｆの受信よりも前に、既にデータパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５ＦとＤ６Ｆを受信している。しかし、以前受信したデータパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５ＦとＤ６ＦのＬＳは、いずれも、今回受信したデータパケットＤ８ＦのＬＳと等しい。よって、ノードＨは、データパケットＤ１ＦとＤ３ＦとＤ４ＦとＤ５ＦとＤ６Ｆに設定されていた送信トラヒックの値は無視する。
その結果、データパケットＤ８Ｈの送信トラヒックには、データパケットＤ８Ｆに設定されていた「６」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」の和である「７」が設定される。そして、ノードＨが送信したデータパケットＤ８Ｈは、ゲートウェイＧＷ１に受信される。
さらに、ノードＨは、データパケットＤ６Ｆを受信したときと同様に、データパケットＤ８Ｆの受信を契機として、再度ボトルネック通知をゲートウェイＧＷ１宛に送信する。
続いて、図６の例では、ノードＧがゲートウェイＧＷ１宛の新たなデータパケットＤ９Ｇを生成して送信する。図４においてノードＧからゲートウェイＧＷ１への実線矢印があるので、データパケットＤ９Ｇは、１ホップでゲートウェイＧＷ１に届く。
また、図６によれば、データパケットＤ９Ｇの送信の前には、ノードＧは、他のノードからいかなるデータパケットも受信していない。よって、データパケットＤ９Ｇには、送信トラヒックとして、ノードＧが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が設定される。そして、ノードＧが送信したデータパケットＤ９Ｇは、ゲートウェイＧＷ１に受信される。
以上のように、図６には１ラウンドのタイミングチャートが例示されている。そして、図６の例からも明らかなように、１ラウンドの終了までには、ノードＦとＨからボトルネック通知が送信される。第３実施形態では、データパケットに送信トラヒックが埋め込まれているので、データパケットが実際にルーティングされる経路に沿って送信トラヒックの値も累積される。よって、ボトルネックになるノードがネットワーク内に存在する場合には、経路の安定後、遅くとも１ラウンド以内には、ボトルネック通知が確実に送信されることになる。
さて、以上、図６を参照して説明した各ノードの動作が、より具体的にはどのようにして実現されるのかについて、以下では図７〜１５を参照してさらに詳しく説明する。
図７は、第３実施形態の通信装置のブロック構成図である。第３実施形態では、ノードＡ〜Ｉの各々が、図７の通信装置６００のように構成される。
図７の通信装置６００は、図１の通知受信部１０１、送信量通知部１０２、ボトルネック判定部１０３、送信ボトルネック通知部１０４とそれぞれ類似の、通知受信部６０１、送信量通知部６０２、ボトルネック判定部６０３、ボトルネック通知部６０４を有する。また、通信装置６００は、図１の経路情報記憶部１０５と類似の経路情報記憶部６０５を有する。
さらに、通信装置６００は、受信したパケットのタイプを判定するタイプ判定部６０６と、データパケットを一時的に格納するバッファ部６０７を有する。また、通信装置６００は、データパケットの送受信に関する処理を行うデータパケット処理部６０８を有し、データパケット処理部６０８は、上記の通知受信部６０１と送信量通知部６０２を含む。データパケット処理部６０８はさらに、データパケットのペイロードに関する処理を行う上位層処理部６０９と、データパケットのＧＤに応じてＬＤを決定する（すなわちデータパケットをルーティングする経路を決定する）ルーティング制御部６１０も含む。
また、経路情報記憶部６０５は、通信装置６００に隣接する他の通信装置に関する情報を記憶するリンクテーブル６１１を含む。経路情報記憶部６０５は、さらに、データパケットのＬＤを決定するための情報を記憶するルーティングテーブル６１２も含む。リンクテーブル６１１とルーティングテーブル６１２それぞれの具体例については、図８と９とともに後述する。
そして、通信装置６００は、通信装置６００自身が所定期間に生成してゲートウェイＧＷ１宛に送信するデータパケットの量の期待値を記憶する送信量記憶部６１３を有する。例えば、図６の例では、送信量記憶部６１３は「１」という値を記憶する。
また、通信装置６００は、ハローパケットの送受信に関する処理を行うハローパケット処理部６１４を有する。ハローパケット処理部６１４は、具体的には、受信したハローパケットに基づいてリンクテーブル６１１を更新するリンク管理部６１５と、ハローパケットを定期的に送信する存在通知部６１６を有する。
なお、ゲートウェイＧＷ１は、必ずしも通信装置６００のように構成されている必要はない。しかし、以下では説明の簡単化のため、第３実施形態ではゲートウェイＧＷ１がボトルネック通知部６０４以外の図７の各構成要素を有するものとする。
ところで、通信装置６００が無線ネットワークで使われる装置の場合、通信装置６００は、例えば図２の通信装置２００により実現されてもよい。例えば、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５がパケットを受信すると、パケットは、バッファ部６０７としてのＤＲＡＭ２０３に格納されてもよい。そして、ＭＰＵ２０１がタイプ判定部６０６としてパケットのタイプを判定してもよい。
あるいは、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、ＭＰＵ２０１の代わりにタイプ判定部６０６としてパケットのタイプの判定を行うように構成されていてもよい。その場合、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、受信したパケットが制御パケットであればパケット全体をＭＰＵ２０１に出力してもよい。逆に、受信したパケットがデータパケットであれば、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、パケットのヘッダだけをＭＰＵ２０１に出力し、ヘッダを含むパケットの全体をバッファ部６０７としてのＤＲＡＭ２０３に格納してもよい。
ＭＰＵ２０１はさらに、データパケット処理部６０８として各種の処理を行ってもよい。データパケット処理部６０８のうち上位層処理部６０９を実現するために、さらにセンサ２０７が使われてもよい。また、データパケット処理部６０８内の送信量通知部６０２は、ＭＰＵ２０１と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよい。
経路情報記憶部６０５と送信量記憶部６１３は、ＤＲＡＭ２０３により実現されてもよいし、フラッシュメモリ２０４により実現されてもよい。
また、ボトルネック判定部６０３もＭＰＵ２０１によって実現することができる。ボトルネック通知部６０４は、ＭＰＵ２０１と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよいが、ＭＰＵ２０１と８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６により実現されてもよい。
そして、リンク管理部６１５もＭＰＵ２０１によって実現することができる。存在通知部６１６は、ＭＰＵ２０１とタイマＩＣ２０２と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現することができる。
以上とは逆に、通信装置６００が有線ネットワークで使われる装置の場合、通信装置６００は、例えば図３の通信装置３００により実現されてもよい。例えば、物理ポート３０１ａ〜３０１ｄのいずれかがパケットを受信すると、パケットは、対応するＰＨＹチップ（つまりＰＨＹチップ３０２ａ〜３０２ｄのいずれか）を介して、バッファ部６０７としての、メモリ３０５またはメモリ３０７に出力されてもよい。
タイプ判定部６０６は、ＦＰＧＡ３０３により実現されてもよいし、ＭＰＵ３０６により実現されてもよい。例えば、ＦＰＧＡ３０３がタイプを判定し、受信されたパケットがデータパケットの場合のみパケットをＭＰＵ３０６が処理し、受信されたパケットが制御パケットの場合は、パケットをＦＰＧＡ３０３が処理してもよい。
また、ＭＰＵ３０６は、データパケット処理部６０８として各種の処理を行ってもよい。データパケット処理部６０８のうち上位層処理部６０９を実現するために、さらにセンサ３０８が使われてもよい。また、データパケット処理部６０８内の送信量通知部６０２は、ＭＰＵ３０６と、ＦＰＧＡ３０３と、ＰＨＹチップ３０２ａ〜３０２ｄと、物理ポート３０１ａ〜３０１ｄにより、実現されてもよい。
経路情報記憶部６０５はメモリ３０５により実現されてもよい。また、送信量記憶部６１３はメモリ３０７により実現されてもよい。
そして、ボトルネック判定部６０３もＭＰＵ３０６により実現することができる。ボトルネック通知部６０４は、ＭＰＵ３０６と、ＦＰＧＡ３０３と、ＰＨＹチップ３０２ａ〜３０２ｄと、物理ポート３０１ａ〜３０１ｄにより実現されてもよい。
また、リンク管理部６１５はＦＰＧＡ３０３により実現することができる。存在通知部６１６は、タイマ３０４を含むＦＰＧＡ３０３とＰＨＹチップ３０２ａ〜３０２ｄと物理ポート３０１ａ〜３０１ｄにより実現することができる。
さて、図８は、第３実施形態のリンクテーブル６１１の例を示す図である。図８には、リンクテーブル６１１の具体例が４つ示されている。以下ではまず、リンクテーブル６１１の形式について説明し、その後、４つの具体的なリンクテーブル６１１それぞれの内容について説明する。
リンクテーブル６１１の各エントリは、通信装置６００に隣接する各通信装置に対応する。なお、通信装置６００に隣接する通信装置は、ゲートウェイＧＷ１のこともある。そして、図８に示すように、リンクテーブル６１１内の各エントリは、「リンク名」、「受信トラヒック」、「ハローパケット受信時刻」および「トラヒック認識時刻」というフィールドを含む。
リンク名は、通信装置６００に隣接する他の通信装置との間の個々のリンクを識別するための情報である。換言すれば、リンク名は、通信装置６００に隣接する個々の通信装置を識別するための情報である。
例えば、ネットワーク内の各通信装置に、ネットワーク内で一意なノードＩＤ（identification）が割り当てられている場合、隣接する通信装置のノードＩＤがリンク名として利用可能である。また、リンク名は、隣接する通信装置のアドレス（例えばＭＡＣアドレスなど）でもよい。図示の便宜上、図８では、図４での各ノードの参照符号をリンク名として示している。
受信トラヒックは、リンク名で識別される隣接通信装置から通信装置６００が受信したデータパケットの送信トラヒックフィールドに設定されていた値を示す。
例えば、通信装置６００がノードＨである場合、通信装置６００がノードＦから受信したデータパケットＤ１Ｆには、「１」という値が設定されている。そして、この「１」という値は、通信装置６００にとっての隣接通信装置であるノードＦから、「１」という値で示される量のデータを通信装置６００が受信することを示す。よって、通信装置６００がノードＨである場合、通信装置６００がデータパケットＤ１Ｆを受信した時点におけるリンクテーブル６１１は、ノードＦを識別するリンク名と対応づけて、「１」という値を受信トラヒックとして記憶する。
また、ハローパケット受信時刻は、リンク名で識別される隣接通信装置から通信装置６００がハローパケットを受信した最新時刻を示す。ハローパケット受信時刻は、ネットワークの動的な変化に応じて変化し得る隣接通信装置を通信装置６００が正しく認識することができるようにするために、利用される。
つまり、リンク管理部６１５は、例えばタイマＩＣ２０２またはタイマ３０４から定期的に出力される割り込み信号にしたがって、定期的にエージング処理を行う。具体的には、リンク管理部６１５は、現在時刻とハローパケット受信時刻との差が所定の閾値よりも大きいエントリ（すなわち古い状態のまま更新されていないエントリ）をリンクテーブル６１１から削除する。上記閾値は、ハローパケットの送信間隔に基づいて決められることが好ましい。
なお、ネットワークの動的な変化の原因としては、例えば、ノードの追加、ノードの削除、ノードの移動、遮蔽物の出現、遮蔽物の消失、遮蔽物の移動、電波干渉源の出現、電波干渉源の消失、電波干渉源の移動、などがあり得る。
トラヒック認識時刻は、通信装置６００が、リンク名で識別される隣接通信装置からデータパケットを受信し、データパケット内に設定された送信トラヒックの値を認識した時刻を示す。古すぎるデータパケットに埋め込まれた送信トラヒックの値を使ってボトルネックの予測または検出が行われると、予測または検出が不正確になる。そこで、そのような不正確な予測または検出を防止するために、トラヒック認識時刻が利用される。
つまり、リンク管理部６１５は、例えばタイマＩＣ２０２またはタイマ３０４から定期的に出力される割り込み信号にしたがって、定期的に受信トラヒックに関する初期化を行う。具体的には、リンク管理部６１５は、現在時刻とトラヒック認識時刻との差が所定の閾値よりも大きいエントリにおける受信トラヒックの値を、「０」に初期化する。例えば各ノードが所定の間隔で定期的にデータパケットを送信する場合、上記閾値は、データパケットの送信間隔に基づいて決められることが好ましい。
さて、以上説明した４つのフィールドを含むリンクテーブル６１１の具体例として、図８には、（Ａ１）〜（Ａ４）の４つの例が示されている。
（Ａ１）データパケットＤ４ＡをノードＤが受信した直後の、ノードＤのリンクテーブル６１１Ｄ−１。
（Ａ２）データパケットＤ４ＤをノードＥが受信した直後の、ノードＥのリンクテーブル６１１Ｅ−１。
（Ａ３）データパケットＤ５ＣをノードＥが受信した直後の、ノードＥのリンクテーブル６１１Ｅ−２。
（Ａ４）データパケットＤ６ＢをノードＥが受信した直後の、ノードＥのリンクテーブル６１１Ｅ−３。
以下、図４と６も参照しながら、これらの４つのリンクテーブル６１１Ｄ−１および６１１Ｅ−１〜６１１Ｅ−３の内容を説明する。なお、図６ではハローパケットの送受信が省略されているが、ネットワーク４００内のノードＡ〜ＩとゲートウェイＧＷ１は、隣接する装置に自分の存在を通知するために、定期的にハローパケットを送信する。
ここでは説明の簡単化のために、ノードＤは、データパケットＤ４Ａを受信した時点で既に、隣接するノードＡ、ＢおよびＥの各々からハローパケットを受信しているものとする。よって、リンクテーブル６１１Ｄ−１には、ノードＡ、ＢおよびＥにそれぞれ対応する３つのエントリがある。
アドホックネットワークのルーティングアルゴリズムには様々なものがあるが、一般には、各ノードがまずハローパケットを用いて隣接ノードを認識し、その後、データパケットの送信経路が構築される。図６のタイミングチャートは、具体的には、例えば、送信経路が一旦構築されて安定した段階における1ラウンドを示す。よって、上記の「ノードＤは、データパケットＤ４Ａを受信した時点で既に、隣接するノードＡ、ＢおよびＥの各々からハローパケットを受信している」という仮定は、現実的な仮定である。
さて、図８の例では、ノードＤがノードＡ、ＢおよびＥからそれぞれハローパケットを受信した最新時刻は、ハローパケット受信時刻として記憶されているとおり、それぞれＰＡＤ１、ＰＢＤ１およびＰＥＤ１である。そして、これら３つの時刻は、ノードＤがデータパケットＤ４Ａを受信した時刻ＱＡＤ１よりも前である。
ノードＡからデータパケットＤ４Ａを受信したノードＤは、データパケットＤ４Ａに送信トラヒックとして設定されている「１」という値を、リンクテーブル６１１Ｄ−１においてノードＡに対応する１つ目のエントリの受信トラヒックフィールドに設定する。また、ノードＤは、ノードＤがデータパケットＤ４Ａを受信した時刻ＱＡＤ１を、１つ目のエントリのトラヒック認識時刻フィールドに設定する。
なお、データパケットＤ４Ａを受信した時刻ＱＡＤ１までに、ノードＤは、ノードＢからもノードＥからも、いかなるデータパケットも受信してはいない。または、時刻ＱＡＤ１以前の経路が不安定な過渡的状況において、ノードＢまたはＥからノードＤがデータパケットを受信したことがあるかもしれないが、時刻ＱＡＤ１の時点では既に、上記の初期化処理によって、古い受信トラヒックの値は初期化されているとする。
よって、ノードＢとＥに対応する２つ目と３つ目のエントリにおける受信トラヒックの値は「０」である。また、２つ目と３つ目のエントリのトラヒック認識時刻は無効である。
さて、データパケットＤ４Ａの受信を契機として、ノードＤにおけるリンクテーブル６１１は、図８のリンクテーブル６１１Ｄ−１のとおりとなる。また、データパケットＤ４Ａの受信を契機として、ノードＤは、データパケットＤ４Ｄを送信する。すると、ノードＥはデータパケットＤ４Ｄを受信する。
ここでは説明の簡単化のために、ノードＥは、データパケットＤ４Ｄを受信した時点で既に、隣接するノードＢ、Ｃ、ＤおよびＦの各々からハローパケットを受信しているものとする。よって、リンクテーブル６１１Ｅ−１には、ノードＢ、Ｃ、ＤおよびＦにそれぞれ対応する４つのエントリがある。
図８の例では、ノードＥがノードＢ、Ｃ、ＤおよびＦからそれぞれハローパケットを受信した最新時刻は、ハローパケット受信時刻として記憶されているとおり、それぞれＰＢＥ１、ＰＣＥ１、ＰＤＥ１およびＰＦＥ１である。そして、これら４つの時刻は、ノードＥがデータパケットＤ４Ｄを受信した時刻ＱＤＥ１よりも前である。
そして、ノードＤからデータパケットＤ４Ｄを受信したノードＥは、データパケットＤ４Ｄに送信トラヒックとして設定されている「２」という値を、リンクテーブル６１１Ｅ−１においてノードＤに対応する３つ目のエントリの受信トラヒックフィールドに設定する。また、ノードＥは、ノードＥがデータパケットＤ４Ｄを受信した時刻ＱＤＥ１を、３つ目のエントリのトラヒック認識時刻フィールドに設定する。
なお、データパケットＤ４Ｄを受信した時刻ＱＤＥ１までに、ノードＥは、ノードＢからもノードＣからもノードＦからも、いかなるデータパケットも受信してはいない。あるいは、経路が不安定な過渡的状況においてノードＢ、ＣまたはＦからノードＥがデータパケットを受信したことがあったとしても、時刻ＱＤＥ１までには、古い受信トラヒックの値は既に初期化されているとする。
よって、ノードＢとＣとＦに対応する１つ目と２つ目と４つ目のエントリにおける受信トラヒックの値は「０」である。また、１つ目と２つ目と４つ目のエントリのトラヒック認識時刻は無効な初期値のままである。
ところで、データパケットＤ４Ｄの受信後しばらく経つと、図６に示すとおり、ノードＥは、ノードＣからデータパケットＤ５Ｃを受信する。なお、ノードＥは、データパケットＤ４Ｄの受信からデータパケットＤ５Ｃの受信までの間にも、ノードＢ、Ｃ、ＤおよびＦの各々からハローパケットを受信することがある。
図８の例では、ノードＥがノードＢ、Ｃ、ＤおよびＦからそれぞれハローパケットを受信した最新時刻は、ハローパケット受信時刻として記憶されているとおり、それぞれＰＢＥ２、ＰＣＥ２、ＰＤＥ２およびＰＦＥ２である。そして、これら４つの時刻は、正確には、ノードＥがデータパケットＤ５Ｃを受信した時刻ＱＣＥ２から見た最新時刻なので、当然、時刻ＱＣＥ２よりも前である。
そして、ノードＣからデータパケットＤ５Ｃを受信したノードＥは、データパケットＤ５Ｃに送信トラヒックとして設定されている「１」という値を、リンクテーブル６１１Ｅ−２においてノードＣに対応する２つ目のエントリの受信トラヒックフィールドに設定する。また、ノードＥは、ノードＥがデータパケットＤ５Ｃを受信した時刻ＱＣＥ２を、２つ目のエントリのトラヒック認識時刻フィールドに設定する。なお、他のエントリの受信トラヒックの値は変化しない。
したがって、データパケットＤ５Ｃを受信したノードＥは、リンクテーブル６１１Ｅ−２の全エントリそれぞれの受信トラヒックの値と、ノードＥ自身が送信量記憶部６１３に保持する値との和を計算し、「４」という結果を得る。そして、ノードＥは、計算した「４」という値をデータパケットＤ５Ｅに送信トラヒックとして設定する。
さて、データパケットＤ５Ｃの受信後しばらく経つと、図６に示すとおり、ノードＥは、ノードＢからデータパケットＤ６Ｂを受信する。なお、ノードＥは、データパケットＤ５Ｃの受信からデータパケットＤ６Ｂの受信までの間にも、ノードＢ、Ｃ、ＤおよびＦの各々からハローパケットを受信することがある。
図８の例では、ノードＥがノードＢ、Ｃ、ＤおよびＦからそれぞれハローパケットを受信した最新時刻は、ハローパケット受信時刻として記憶されているとおり、それぞれＰＢＥ３、ＰＣＥ３、ＰＤＥ３およびＰＦＥ３である。そして、これら４つの時刻は、正確には、ノードＥがデータパケットＤ６Ｂを受信した時刻ＱＢＥ３から見た最新時刻なので、当然、時刻ＱＢＥ３よりも前である。
そして、ノードＢからデータパケットＤ６Ｂを受信したノードＥは、データパケットＤ６Ｂに送信トラヒックとして設定されている「１」という値を、リンクテーブル６１１Ｅ−３においてノードＢに対応する１つ目のエントリの受信トラヒックフィールドに設定する。また、ノードＥは、ノードＥがデータパケットＤ６Ｂを受信した時刻ＱＢＥ３を、１つ目のエントリのトラヒック認識時刻フィールドに設定する。なお、他のエントリの受信トラヒックの値は変化しない。
したがって、データパケットＤ６Ｂを受信したノードＥは、リンクテーブル６１１Ｅ−３の全エントリそれぞれの受信トラヒックの値と、ノードＥ自身が送信量記憶部６１３に保持する値との和を計算し、「５」という結果を得る。そして、ノードＥは、計算した「５」という値をデータパケットＤ６Ｅに送信トラヒックとして設定する。
図９は、第３実施形態のルーティングテーブル６１２の例を示す図である。ルーティングテーブル６１２に格納される情報は、ルーティング制御部６１０がＧＤからＬＤを決めることを可能にする情報であれば、どのような形式であってもよい。図９には、一例として、第３実施形態においてノードＤが保持するルーティングテーブル６１２Ｄが図示されている。
ルーティングテーブル６１２Ｄの各エントリは、ＧＤとなり得る各ノードに対応する。図９では、ゲートウェイＧＷ１とノードＢにそれぞれ対応する２つのエントリが例示されている。しかし、実施形態によっては、「ネットワーク内の特定の１つのノード（例えばゲートウェイＧＷ１）以外がＧＤに指定されることがない」という方針にしたがってネットワークが運用されることもある。
ルーティングテーブル６１２Ｄの各エントリは、「ＧＤ」、「第１候補ＬＤ」の「ノードＩＤ」および「評価値」、「第２候補ＬＤ」の「ノードＩＤ」および「評価値」、ならびに「第３候補ＬＤ」の「ノードＩＤ」および「評価値」というフィールドを含む。つまり、各エントリは、当該エントリに対応するＧＤに対して選択可能なＬＤの候補を、最大で３つまで記憶することができる。また、ＬＤの各候補は、ノードＩＤにより識別され、評価値によってＬＤとしての好ましさが評価される。
もちろん、実施形態によっては、ルーティングテーブル６１２は、ＧＤとなり得る１つのノードに対応して、３つより多くの候補、または３つより少ない候補についての情報を記憶する形式でもよい。また、ＧＤとなり得る１つのノードに対応するＬＤの候補の数は、任意に可変であってもよい。
ルーティングテーブル６１２の内容は、より詳しくは下記のとおりである。
すなわち、１つ目のエントリは、ＧＤがゲートウェイＧＷ１である場合に対応する。１つ目のエントリには、ＧＤがゲートウェイＧＷ１のときにノードＤがＬＤとして選択可能なノードの候補として、ノードＥとＢの２つが登録されている。そして、ノードＥのＬＤとしての好ましさは「０．１」という評価値によって表されており、ノードＢのＬＤとしての好ましさは「０．５」という評価値によって表されている。
なお、以下では説明の便宜上、評価値は０以上１以下であり、「０」が最高の評価であり、「１」が最低の評価であるものとする。したがって、ルーティングテーブル６１２Ｄを有するノードＤにとっては、ＧＤがゲートウェイＧＷ１のときのＬＤとしては、「０．５」という評価値のノードＢよりは、「０．１」という評価値のノードＥの方が、ＬＤとしては好ましい。
そのため、ノードＤは、ルーティングテーブル６１２Ｄにしたがって、ＧＤがゲートウェイＧＷ１のデータパケットを送信する際には、選択可能なＬＤの２つの候補の中から、より好ましいノードＥをＬＤ（つまり直接の送信先）として選択する。図４におけるノードＤからノードＥへの実線矢印は、以上のようなルーティングテーブル６１２Ｄの評価値にしたがった選択の結果を示す。
なお、ルーティングテーブル６１２では、最大で３つのＬＤの候補は、評価値によってソートされ、ソート結果に応じて、第１候補ＬＤから順に登録されている。ルーティング制御部６１０は、評価値を変更する場合は、再度ＬＤの候補をソートする。
また、図９の例では、ルーティングテーブル６１２Ｄが２つ目のエントリも有する。２つ目のエントリは、ＧＤがノードＢである場合に対応する。２つ目のエントリには、ＧＤがノードＢのときにノードＤがＬＤとして選択可能なノードの候補として、ノードＢとＡとＥの３つが登録されている。そして、ノードＢのＬＤとしての好ましさは「０．０」という評価値によって表されており、ノードＡのＬＤとしての好ましさは「０．２」という評価値によって表されており、ノードＥのＬＤとしての好ましさは「０．７」という評価値によって表されている。
続いて、図１０を参照して、第３実施形態で使われるパケットの例について説明する。第３実施形態で使われるパケット７００は、アドホックヘッダ７０１を含み、タイプに応じてさらに適宜のペイロードを含む。ペイロードはオプショナルなので、タイプによっては、パケット７００はペイロードを含まなくてもよい。また、パケット７００は、誤り検出符号を含むトレイラをさらに含んでいてもよい。
アドホックヘッダ７０１は、具体的には、「ＬＤ」、「ＬＳ」、「ＩＤ」および「タイプ」という４つのフィールドを含む。フィールドの順序や長さは実施形態に応じて適宜変更されてよい。
アドホックヘッダ７０１において、ＬＤフィールドとＬＳフィールドには、それぞれ、パケット７００のＬＤとＬＳのノードを識別する情報が格納される。ノードを識別する情報は、例えば、ネットワーク内で一意のノードＩＤでもよいし、ＭＡＣアドレスなどのアドレスでもよい。図示の便宜上、図１０では、ノードを識別する情報として、図４での各ノードの参照符号を用いている。
アドホックヘッダ７０１において、ＩＤフィールドには、パケット７００を生成したノードが割り当てるＩＤが格納される。図示の便宜上、図１０では４桁のシーケンス番号がＩＤとして例示されているが、もちろん、ＩＤの桁数や形式は、実施形態に応じて任意である。
また、アドホックヘッダ７０１において、タイプフィールドには、パケット７００のタイプを識別するための値が設定される。第３実施形態では、少なくとも、データパケット、ハローパケットおよびＡＣＫパケットという３種類のパケットが使われる。図１０には、パケット７００の具体例として、データパケット７１０、ハローパケット７２０およびＡＣＫパケット７３０が図示されている。図示の便宜上、図１０では上記の３つのタイプを識別する値がそれぞれ「Ｄａｔａ」、「Ｈｅｌｌｏ」および「ＡＣＫ」と示されている。
もちろん、実施形態によっては他のタイプのパケットがさらに使われてもよい。逆に、有線ネットワークの場合には、ほぼ１００％確実にパケット送信が成功するので、ＡＣＫパケット７３０は使われなくてもよい。また、タイプを識別する値の形式は実施形態に応じて任意であり、例えば数値によってタイプが識別されてもよい。
さて、データパケット７１０は、パケット７００におけるペイロードとして、「ＧＤ」、「ＧＳ」、「長さ」、「送信トラヒック」および「ペイロード」という５つのフィールドを含む。
ＧＤフィールドとＧＳフィールドには、それぞれ、データパケット７１０のＧＤとＧＳのノードを識別する情報が格納される。長さフィールドは、ペイロードフィールドの長さを示す。送信トラヒックフィールドは、図６に関して説明したとおりである。ペイロードフィールドには、データパケット７１０を定義するプロトコルよりも上位のレイヤで使われる任意のデータ（例えば、センサ２０７またはセンサ３０８から出力されたデータなど）が格納される。
データパケット７１０の具体例として、図１０には、図６のデータパケットＤ４Ｄが例示されている。図６に示すとおり、データパケットＤ４Ｄは、ノードＡが生成してゲートウェイＧＷ１に宛てて送信したデータパケットＤ４Ａの一部を、ノードＤが書き換えたものであり、ノードＤからノードＥへ送信される。
よって、データパケットＤ４Ｄにおいて、ＬＤはノードＥであり、ＬＳはノードＤである。また、図１０によれば、ノードＡがデータパケットＤ４Ａを生成したときにデータパケットＤ４Ａに割り当てた「１２３４」というＩＤが、そのままデータパケットＤ４ＤにもＩＤとして設定される。そして、データパケットＤ４Ｄのタイプの値は、データパケットを示す「Ｄａｔａ」である。
また、データパケットＤ４Ｄにおいて、ＧＤはゲートウェイＧＷ１であり、ＧＳはノードＡである。そして、図１０の例では、ペイロードフィールドの長さは「２００」である。また、図６にも示したように、データパケットＤ４Ｄにおける送信トラヒックフィールドの値は「２」である。
なお、長さフィールドと送信トラヒックフィールドの単位は異なっていてよい。例えば長さフィールドの単位が「バイト」で、送信トラヒックフィールドの単位が「キロバイト／５分間」でもよい。
ところで、第３実施形態のハローパケット７２０は、ペイロードを持たない。また、ハローパケット７２０は、１ホップの範囲内でブロードキャストされ、マルチホップ送信の対象外である。
例えば、ハローパケット７２０は、具体例にはハローパケット７２１のような内容を持つ。ハローパケット７２１は、ある時点でノードＤから送信される。
上記のとおりハローパケット７２１はブロードキャストされる。よって、ハローパケット７２１のＬＤには、１ホップの範囲内でのブロードキャストを示すブロードキャストアドレス（図１０では「ＢＣ」と表記）が設定される。
また、ハローパケット７２１はノードＤから送信されるので、ハローパケット７２１のＬＳはノードＤである。そして、ハローパケット７２１のＩＤには、ノードＤが割り当てた「０９８７」という値が設定されている。また、ハローパケット７２１のタイプの値は、ハローパケットを示す「Ｈｅｌｌｏ」である。
図１０にはさらに、ＡＣＫパケット７３０も示されている。ＡＣＫパケット７３０は、データパケット７１０に対する肯定応答（acknowledgment）である。ＡＣＫパケット７３０は、パケット７００におけるペイロードとして、具体的には「ＧＳ」フィールドを含む。
データパケット７１０のＩＤの値は、データパケット７１０のＧＳのノードが割り当てるので、異なるノードが偶然同じＩＤを異なるデータパケット７１０に割り当てる場合がある。よって、マルチホップ送信されても変化しないデータパケット７１０の同一性（identity）は、正確には、データパケット７１０のＧＳとＩＤの値の組み合わせによって識別される。
よって、ＡＣＫパケット７３０は、どのデータパケット７１０に対する肯定応答なのかを示すため、ＩＤだけでなく、ＧＳフィールドを含む。
例えば、ノードＤから受信したデータパケットＤ４Ｄに対応してノードＥが送信するＡＣＫパケット７３１のＧＳとＩＤの値は、データパケットＤ４ＤにおけるＧＳとＩＤの値に等しい。また、ＡＣＫパケット７３１のＬＤは、データパケットＤ４ＤのＬＳに等しく、ノードＤである。そして、ＡＣＫパケット７３１のＬＳは、データパケットＤ４ＤのＬＤに等しく、ノードＥである。
さて、以下では、いくつかのフローチャートを参照して、図７の通信装置６００の動作を説明する。以下に説明するように動作する通信装置６００を図４のノードＡ〜Ｉとして用いることにより、図６を参照して説明したような、ボトルネックの検出または予測が可能となる。
図１１は、いくつかの実施形態で共通のパケット受信処理のフローチャートである。以下では説明の便宜上、第３実施形態の通信装置６００が図１１の処理を行う場合を具体例として挙げるが、例えば図１７とともに後述する第４実施形態の通信装置８００も、図１１と類似の処理を行う。
ステップＳ１０１で通信装置６００は、パケット７００を受信するまで待機する。そして、パケット７００が受信されると、処理はステップＳ１０２に移行する。
ステップＳ１０２でタイプ判定部６０６は、受信されたパケット７００のアドホックヘッダ７０１のタイプの値から、パケット７００のタイプを判定する。
タイプ判定部６０６は、「受信されたパケット７００はハローパケット７２０である」と判定した場合、ハローパケット７２０をハローパケット処理部６１４内のリンク管理部６１５に出力する。そして、処理はステップＳ１０３に移行する。
また、タイプ判定部６０６は、「受信されたパケット７００はデータパケット７１０である」と判定した場合、データパケット７１０の受信を、通知受信部６０１とルーティング制御部６１０に通知する。そして、処理はステップＳ１０４に移行する。
あるいは、タイプ判定部６０６は、「受信されたパケット７００はＡＣＫパケット７３０である」と判定した場合、ＡＣＫパケット７３０をルーティング制御部６１０に出力する。そして、処理はステップＳ１０６に移行する。
ステップＳ１０３でリンク管理部６１５は、ハローパケット受信処理を行う。ハローパケット受信処理の内容は、第３実施形態と第４実施形態で異なる。第３実施形態では、リンク管理部６１５は、ステップＳ１０３で具体的には以下のような処理を行う。
リンク管理部６１５は、まず、受信されたハローパケット７２０のＬＳと同じ値をリンク名として持つエントリをリンクテーブル６１１において検索する。そして、検索の結果エントリが見つかった場合、リンク管理部６１５は、見つかったエントリにおけるハローパケット受信時刻として、現在時刻を設定する。
逆に、エントリが見つからなかった場合、リンク管理部６１５は、リンクテーブル６１１に新規エントリを追加する。そして、リンク管理部６１５は、新規エントリにおけるリンク名として、受信されたハローパケット７２０のＬＳの値を設定する。また、リンク管理部６１５は、新規エントリにおける受信トラヒックの値を「０」に初期化する。さらに、リンク管理部６１５は、新規エントリにおけるハローパケット受信時刻として、現在時刻を設定し、新規エントリにおけるトラヒック認識時刻を無効な値に初期化する。
以上のようなハローパケット受信処理が終わると、通信装置６００は再びステップＳ１０１でパケット７００の受信を待つ。
また、ステップＳ１０４では、受信されたデータパケット７１０がバッファ部６０７に格納される。
そして、次のステップＳ１０５では、通信装置６００がデータパケット受信処理を実行する。データパケット受信処理の内容は、第３実施形態と第４実施形態で異なる。第３実施形態では、通信装置６００は、具体的には図１２の処理を実行する。そして、データパケット受信処理が終わると、通信装置６００は再びステップＳ１０１でパケット７００の受信を待つ。
また、ステップＳ１０６でルーティング制御部６１０は、受信されたＡＣＫパケット７３０のＬＤの値が自ノードＩＤ（すなわち通信装置６００自身のノードＩＤ）であるか否かを判断する。
受信されたＡＣＫパケット７３０のＬＤの値が、通信装置６００自身のノードＩＤと異なる場合とは、通信装置６００以外の他の通信装置が以前に送信したデータパケット７１０に対するＡＣＫパケット７３０が、通信装置６００でも偶然受信可能だった場合である。この場合、ＡＣＫパケット７３０は無視して構わないので、処理はステップＳ１０１に戻る。
逆に、受信されたＡＣＫパケット７３０のＬＤの値が、通信装置６００自身のノードＩＤである場合は、通信装置６００が以前に送信したデータパケット７１０に対するＡＣＫパケット７３０が今回受信された場合である。よって、この場合、処理はステップＳ１０７に移行する。
ステップＳ１０７でデータパケット処理部６０８内のルーティング制御部６１０は、受信されたＡＣＫパケット７３０に対応する送信済みのデータパケット７１０を特定する。第３実施形態の通信装置６００は、リトライに備えて送信済みのデータパケット７１０をバッファ部６０７に保持する。そこで、ステップＳ１０７でルーティング制御部６１０は、バッファ部６０７を検索して、受信されたＡＣＫパケット７３０のＧＳとＩＤに等しいＧＳとＩＤを有する送信済みのデータパケット７１０を特定する。
そして、次のステップＳ１０８でルーティング制御部６１０は、ステップＳ１０７で特定したデータパケット７１０をバッファ部６０７から削除する。
さらに、次のステップＳ１０９でルーティング制御部６１０は、ステップＳ１０７で特定したデータパケット７１０の転送または送信に関するプロセス（あるいはスレッド）を再開させる。詳しくは後述するが、他の通信装置から受信したデータパケット７１０を転送するプロセスと、上位層処理部６０９が生成した新たなデータパケット７１０を送信するプロセスは、いずれも、ＡＣＫパケット７３０の受信を待つステップを含む。そして、ＡＣＫパケット７３０の受信を待つ間、プロセスはスリープする。
よって、ステップＳ１０９でルーティング制御部６１０は、スリープさせていたプロセスを、ＡＣＫパケット７３０の受信を契機としてレジュームさせる。レジュームしたプロセスは、図１１の処理とは並行して実行される。一方で、図１１の処理は、ステップＳ１０１に戻る。
さて、図１２は、第３実施形態において図１１のステップＳ１０５で行われるデータパケット受信処理のフローチャートである。
ステップＳ２０１でルーティング制御部６１０は、通信装置６００が受信したデータパケット７１０のＬＤの値が、自ノードＩＤ（すなわち通信装置６００自身のノードＩＤ）であるか否かを判断する。そして、データパケット７１０のＬＤの値が、通信装置６００自身のノードＩＤと異なれば、処理はステップＳ２０２に移行する。逆に、データパケット７１０のＬＤの値が、通信装置６００自身のノードＩＤと同じであれば、処理はステップＳ２０２に移行する。
ステップＳ２０２でルーティング制御部６１０は、受信されたデータパケット７１０をバッファ部６０７から削除する。そして、データパケット受信処理は終了する。
例えば、図６の例で、ノードＦが送信したデータパケットＤ１ＦのＬＤはノードＨである。しかし、ノードＦには、ノードＨだけではなくノードＥ、ＧおよびＩも隣接している。よって、ノードＥ、ＧおよびＩにおいても、データパケットＤ１Ｆが受信可能なことがある。その場合、ノードＥ、ＧおよびＩのルーティング制御部６１０は、ステップＳ２０２で、データパケットＤ１Ｆをバッファ部６０７から削除する。
他方、ステップＳ２０３でルーティング制御部６１０は、受信されたデータパケット７１０に対応する新たなＡＣＫパケット７３０を生成して送信する。なお、ＡＣＫパケット７３０の送信機能は、例えば８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよい。
例えば、図１０のデータパケットＤ４ＤをノードＥが受信した場合に、ノードＥのルーティング制御部６１０は、ステップＳ２０３でＡＣＫパケット７３１を生成して送信する。
また、次のステップＳ２０４では、通知受信部６０１が、図１３に詳細を示す受信トラヒック設定処理を行い、リンクテーブル６１１を更新する。例えば、ノードＥの通知受信部６０１は、時刻ＱＣＥ２に行うステップＳ２０４の処理によって、リンクテーブル６１１を、図８のリンクテーブル６１１Ｅ−１の状態からリンクテーブル６１１Ｅ−２の状態に更新する。
続いて、ステップＳ２０５では、図１４に詳細を示すボトルネック検出処理が実行される。その結果、必要に応じてボトルネック通知が送信される。例えば、ノードＨがデータパケットＤ５Ｆを受信した場合に、ステップＳ２０５でボトルネック通知が送信される。
その後、ステップＳ２０６でルーティング制御部６１０は、受信されたデータパケット７１０のＧＤの値が自ノードＩＤ（すなわち通信装置６００自身のノードＩＤ）であるか否かを判断する。そして、データパケット７１０のＧＤの値が通信装置６００自身のノードＩＤであれば、処理はステップＳ２０７に移行する。逆に、データパケット７１０のＧＤの値が通信装置６００自身のノードＩＤと異なれば、処理はステップＳ２０８に移行する。
ステップＳ２０７では、上位層処理部６０９が、受信されたデータパケット７１０のペイロードを適宜処理する。ペイロードの処理が終わると、上位層処理部６０９は、データパケット７１０をバッファ部６０７から削除する。そして、図１２のデータパケット受信処理も終了する。
例えば、上述のとおり、第３実施形態ではゲートウェイＧＷ１もボトルネック通知部６０４以外は通信装置６００と同様の構成要素を有する。ゲートウェイＧＷ１の上位層処理部６０９は、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットのペイロードをステップＳ２０７で適宜処理する。
他方、ステップＳ２０８以降の処理は、データパケット７１０のＧＤの値が通信装置６００自身のノードＩＤではない場合に実行される。具体的には、まず、ステップＳ２０８でルーティング制御部６１０が、転送の試行をやめる条件が成立するか否かを判定する。
ルーティング制御部６１０がしたがうルーティングアルゴリズムは、実施形態に応じて様々であってよい。よって、ルーティングアルゴリズムに応じて、上記の転送の試行をやめる条件も、様々であってよい。転送の試行をやめる条件の詳細は、ステップＳ２１０〜Ｓ２１５とも関連するので、後述する。
転送の試行をやめる条件が成立する場合、処理はステップＳ２０９に移行する。逆に、転送の試行をやめる条件が成立していない場合、処理はステップＳ２１０に移行する。
ステップＳ２０９でルーティング制御部６１０は、今回通信装置６００が受信したデータパケット７１０をバッファ部６０７から削除する。そして、データパケット受信処理は終了する。つまり、「通信装置６００が、他の通信装置がＧＤとして指定されているデータパケット７１０を受信したが、適切な転送先の隣接ノードを見つけ出してデータパケット７１０を転送することはできなかった」という場合、データパケット７１０が破棄される。
他方、ステップＳ２１０では、転送の試行をやめる条件が成立していない。よって、ルーティング制御部６１０は、転送の試行のため、まず、データパケット７１０の転送先として指定するＬＤを決める。そして、ルーティング制御部６１０は、決めたＬＤを送信量通知部６０２に通知する。
具体的には、ルーティング制御部６１０は、ルーティングテーブル６１２において、受信されたデータパケット７１０のＧＤの値と等しいＧＤの値を持つエントリを検索する。そして、ルーティング制御部６１０は、検索の結果見つかったエントリを参照し、当該エントリに含まれるＬＤの候補のうちの１つを選択する。ＬＤの候補の選択の仕方は、ルーティング制御部６１０がしたがうルーティングアルゴリズムによって様々であってよく、詳細については後述する。
そして、次のステップＳ２１１で送信量通知部６０２は、ステップＳ２０５と同様の方法で送信トラヒックを再度計算する。または、送信量通知部６０２は、ステップＳ２０５で計算した結果を記憶しておき、記憶した結果を、ステップＳ２１１で送信トラヒックとして用いてもよい。
続いて、ステップＳ２１２で送信量通知部６０２は、ステップＳ２１１で得た送信トラヒック含むデータパケット７１０を、ルーティング制御部６１０が決めたＬＤ宛に送信する。そして、送信量通知部６０２等を含むデータパケット処理部６０８は、ＡＣＫパケット７３０の受信を待つ。すなわち、データパケット処理部６０８は、「ＡＣＫタイムアウト時間」として予め決められた所定の時間が経過するか、または、送信したデータパケット７１０に対応するＡＣＫパケット７３０が受信されるまで、図１２のプロセスをスリープさせる。なお、ＡＣＫタイムアウト時間の経過は、例えば、タイマＩＣ２０２またはタイマ３０４により検出可能である。
例えば、通信装置６００がノードＥであり、図６と１０に示すデータパケットＤ４Ｄの受信を契機として図１２のデータパケット受信処理が実行される場合を例にステップＳ２１２の詳細を説明すれば、以下のとおりである。
図６のとおり、ステップＳ２１０で決められたＬＤはノードＦである。また、図６と、図８のリンクテーブル６１１Ｅ−１から明らかなように、ステップＳ２１１で得られる送信トラヒックの値は「３」である。
よって、ステップＳ２１２で送信量通知部６０２は、バッファ部６０７に格納されている図１０のデータパケットＤ４Ｄにおいて、ＬＤ、ＬＳおよび送信トラヒックの値を、それぞれ、ノードＦのノードＩＤ、ノードＥ自身のノードＩＤおよび「３」に書き換える。そして、送信量通知部６０２は、以上の書き換えによって得られたデータパケットＤ４Ｅを送信する。送信後、データパケット処理部６０８は、データパケットＤ４Ｅに対するＡＣＫパケット７３０の受信を待つ。
ステップＳ２１２の次のステップＳ２１３は、一旦スリープした図１２のプロセスが、ＡＣＫタイムアウト時間の経過またはＡＣＫパケット７３０の受信によりレジュームすると、実行される。ステップＳ２１３においてルーティング制御部６１０は、ＡＣＫタイムアウト時間が経過する前にＡＣＫパケット７３０が受信されたのか否かを判定する。
ＡＣＫタイムアウト時間が経過する前にＡＣＫパケット７３０が受信された場合（つまり、ＡＣＫパケット７３０の受信を契機にプロセスがレジュームした場合）、ステップＳ２１２でのデータパケット７１０の転送が成功したので、処理はステップＳ２１４に移行する。
逆に、ＡＣＫタイムアウト時間が経過するまでにＡＣＫパケット７３０が受信されなかった場合（つまり、ＡＣＫタイムアウト時間の経過を契機にプロセスがレジュームした場合）、ステップＳ２１２でのデータパケット７１０の転送は失敗したので、処理はステップＳ２１５に移行する。
ステップＳ２１４でルーティング制御部６１０は、データパケット７１０の転送の成功を反映させるために、必要に応じてルーティングテーブル６１２を更新する。そして、データパケット受信処理が終了する。
例えば、ステップＳ２１４でルーティング制御部６１０は、ステップＳ２１０で参照したルーティングテーブル６１２のエントリにおいて、ステップＳ２１０で選択したＬＤの評価値を小さくしてもよい（つまり評価を上げてもよい）。評価値をどの程度小さくするかは、実施形態に応じて任意である。
ステップＳ２１５でルーティング制御部６１０は、データパケット７１０の転送の失敗を反映させるために、必要に応じてルーティングテーブル６１２を更新する。そして、処理はステップＳ２０８に戻る。その結果、通信装置６００がデータパケット７１０の転送に成功するか、または、「適切な転送先が見つからない」と判明するまで、転送の試行が繰り返される。
例えば、ステップＳ２１５でルーティング制御部６１０は、ステップＳ２１０で参照したルーティングテーブル６１２のエントリにおいて、ステップＳ２１０で選択したＬＤの評価値を大きくしてもよい（つまり評価を下げてもよい）。評価値をどの程度大きくするかは、実施形態に応じて任意である。
ところで、詳細の説明を省略したステップＳ２０８とＳ２１０は、ステップＳ２１５とも関連する。そこで、ステップＳ２０８、Ｓ２１０およびＳ２１５の関連について、以下に例を示す。
上記のとおり、転送の試行をやめる条件が成立するまで、１回または複数回、転送の試行が行われる。例えば、あるルーティングアルゴリズムによれば、ルーティング制御部６１０は、１回目のステップＳ２１０においては、最も評価の高い（すなわち最も評価値の小さい）ＬＤの候補を選択してもよい。
そして、ＡＣＫタイムアウト時間の経過前にＡＣＫパケット７３０が受信されなかった場合、ステップＳ２１５でルーティング制御部６１０は評価値を更新する。すると、２回目以降のステップＳ２１０においては、ルーティング制御部６１０は、単純に最も評価の高いＬＤの候補を選択してもよいし、あるいは、以前の繰り返しにおけるステップＳ２１０で未選択のものの中で最も評価の高いＬＤの候補を選択してもよい。
また、例えば、評価値の範囲が０以上１以下と決められており、１が最も低い評価を示すものとする。この場合、ルーティング制御部６１０は、ステップＳ２０８において、例えば以下の条件（Ｂ１）と（Ｂ２）の少なくとも一方が成立する場合に、転送の試行をやめる条件が成立している、と判定してもよい。
（Ｂ１）１未満の評価値を持つＬＤの候補が存在しない。
（Ｂ２）１未満の評価値を持つＬＤの候補のすべてが、既に以前の繰り返しにおけるステップＳ２１０で選択済みである。
また、図１２では説明を省略したが、ある種のルーティングアルゴリズムは、ネットワーク内のノードが、実際のデータパケット７１０の送信時に試行錯誤を行って自律分散的に適切な経路を発見することができるようにするための仕組みを提供する。具体的には、一旦送信量通知部６０２が送信したデータパケット７１０が、ネットワーク内をループして通信装置６００に戻ってきたときに、ルーティング制御部６１０は、ループを検出してもよい。
例えば、初期状態において、図４の各ノードは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケット７１０について、ＬＤとしてどの隣接ノードを選択するのが適切なのか、ということを認識していない。よって、例えば、以下のような状況も起こり得る。
ノードＤが、ＧＤとしてゲートウェイＧＷ１を指定したデータパケット７１０を送信したとする。その際、ノードＤは、偶然、ノードＥをＬＤとして選択したとする。すると、ノードＥは、データパケット７１０を受信する。ここで、ノードＥは、偶然、ＬＤとしてノードＢを選択したとする。すると、データパケット７１０は、例えば、ノードＢとＣを経由して、ノードＥに戻ってくることがある。
以上のような状況において、ノードＥは、データパケット７１０のＧＳとＩＤの組み合わせから、「以前ノードＢに送信したデータパケット７１０がループしてノードＣから戻ってきた」と認識することができる。つまり、ノードＥは、転送済みの各データパケット７１０について、ＧＳとＩＤを記憶しておくことにより、ループを検出することができる。以上のようなループ検出の結果に基づいて、ノードＥは、ノードＢがＬＤとして不適切なことを学習し、ノードＢの評価値を最大値（つまり最悪の評価）に変更してもよい。
また、ノードＥは、以上のようにしてループを検出すると、次に、別のＬＤの候補を転送先として選ぼうとする。その際に、ノードＥは、ステップＳ２１０での選択における優先度が最下位の候補として、最初にデータパケット７１０を送信してきたＬＳ（つまりノードＤ）を、ルーティングテーブル６１２に記録されているか否かによらず、考慮に入れる。
ここで、便宜上、あるＧＳとＩＤの組み合わせで識別されるデータパケット７１０が最初に受信されたときのＬＳを「オリジナルＬＳ」という。上記の例では、ノードＥにとってのオリジナルＬＳは、ノードＤである。
ノードＥは、転送済みの各データパケット７１０について、ＧＳとＩＤだけでなくオリジナルＬＳもあわせて記憶することにより、上記のようにノードＤの優先度が最下位であることを認識することができる。つまり、オリジナルＬＳは、たとえステップＳ２１０でＬＤとして選ばれることがあるとしても、最後の繰り返しのときにしか選ばれない。
例えば、ノードＥは、上記のループ検出の結果からノードＢがＬＤとして不適切であることを学習する。そして、ノードＥは、オリジナルＬＳであるノードＤ以外の隣接ノード（つまりノードＣとＦ）の中から、次のＬＤの候補を選択する。例えば、ノードＥは、次にステップＳ２１０でノードＦをＬＤとして選択してもよい。
その結果、データパケット７１０の転送が成功すれば、ノードＥは、ノードＦがＬＤとして適切であるということを学習する。具体的には、ノードＥのルーティング制御部６１０は、学習結果をルーティングテーブル６１２の評価値に反映する。
なお、オリジナルＬＳに関する上記の議論を踏まえると、ステップＳ２０８でルーティング制御部６１０は、「（（Ｃ１）または（Ｃ２））かつ（（Ｃ３）または（Ｃ４））」という条件を「転送の試行をやめる条件」として用いてもよい。
（Ｃ１）ルーティングテーブル６１２において、オリジナルＬＳとは異なり、かつ１未満の評価値を持つＬＤの候補が存在しない。
（Ｃ２）ルーティングテーブル６１２において、オリジナルＬＳとは異なり、かつ１未満の評価値を持つＬＤの候補のすべてが、既に以前の繰り返しにおけるステップＳ２１０で選択済みである。
（Ｃ３）最後のＬＤの候補として、オリジナルＬＳも、前回の繰り返しのステップＳ２１０で選択済みである。
（Ｃ４）データパケット７１０のＧＳが通信装置６００自身である（すなわちオリジナルＬＳが定義されない）。
以上、図１２を参照して説明したように、第３実施形態では、通常のデータパケット７１０の受信を契機とする、転送等の一連の処理の中に、ボトルネックの予測または検出のための処理が組み入れられている。また、ボトルネックの予測または検出に使われる情報も、専用の制御パケットではなく、通常のデータパケット７１０の中に含まれる。よって、ボトルネックの予測または検出のためにネットワークに生じる負荷は小さい。
さて、図１３は、第３実施形態において図１２のステップＳ２０４で行われる受信トラヒック設定処理のフローチャートである。
ステップＳ３０１で通知受信部６０１は、受信されたデータパケット７１０から、送信トラヒックの値を抽出する。
そして、次のステップＳ３０２で通知受信部６０１は、リンクテーブル６１１において、リンク名が、受信されたデータパケット７１０のＬＳと等しいエントリを検索する。例えば、図１０のデータパケットＤ４Ｄを受信したノードＥの通知受信部６０１は、リンク名がノードＤのエントリを検索する。
続いて、ステップＳ３０３で通知受信部６０１は、ステップＳ３０２の検索の結果、エントリが見つかったか否かを判定する。エントリが見つかった場合、処理はステップＳ３０４に移行する。逆に、エントリが見つからなかった場合、処理はステップＳ３０６に移行する。なお、通常はエントリが見つかる。エントリが見つからないのは、通信装置６００が、新たな隣接ノードから、ハローパケット７２０を受信する前にデータパケット７１０を受信するような、例外的な場合である。
ステップＳ３０４で通知受信部６０１は、ステップＳ３０１で抽出した値を、ステップＳ３０２の検索の結果見つかったエントリの受信トラヒックとして設定する。そして、次のステップＳ３０５で通知受信部６０１は、ステップＳ３０２の検索の結果見つかったエントリのトラヒック認識時刻として、現在時刻を設定する。すると、受信トラヒック設定処理も終了する。なお、ステップＳ３０４とＳ３０５の順序は逆でもよい。
例えば、図１０のデータパケットＤ４Ｄを受信したノードＥの通知受信部６０１は、リンクテーブル６１１内のリンク名がノードＤのエントリにおいて、受信トラヒックに「２」を設定し、トラヒック認識時刻に現在時刻ＱＤＥ１を設定する。その結果、ノードＥのリンクテーブル６１１は、図８のリンクテーブル６１１Ｅ−１のとおりとなる。
他方、ステップＳ３０６で通知受信部６０１は、リンクテーブル６１１に新規エントリを追加する。
そして、次のステップＳ３０７で通知受信部６０１は、受信したデータパケット７１０のＬＳの値を、ステップＳ３０６で追加した新規エントリのリンク名として設定する。また、次のステップＳ３０８で通知受信部６０１は、ステップＳ３０１で抽出した値を、ステップＳ３０６で追加した新規エントリの受信トラヒックとして設定する。
さらに、次のステップＳ３０９で通知受信部６０１は、ステップＳ３０６で追加した新規エントリのトラヒック認識時刻として、現在時刻を設定する。すると、受信トラヒック設定処理も終了する。なお、ステップＳ３０７〜Ｓ３０９の順序は任意に入れ替え可能である。
さて、図１４は、第３実施形態において図１２のステップＳ２０５で行われるボトルネック検出処理のフローチャートである。
ステップＳ４０１で送信量通知部６０２は、送信トラヒックの量を示す変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃに、送信量記憶部６１３に記憶されている値を代入する。
そして、次のステップＳ４０２で送信量通知部６０２は、リンクテーブル６１１の１つ目のエントリに注目する。続いて、処理はステップＳ４０３に移行する。
ステップＳ４０３で送信量通知部６０２は、変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値と、リンクテーブル６１１において注目しているエントリの受信トラヒックの値との和を計算し、計算結果を変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃに代入する。
そして、次のステップＳ４０４で送信量通知部６０２は、リンクテーブル６１１のすべてのエントリに注目し終えたか否かを判断する。送信量通知部６０２がまだ注目していないエントリが残っていれば、処理はステップＳ４０５に移行する。逆に、送信量通知部６０２がすべてのエントリに既に注目済みならば、処理はステップＳ４０６に移行する。
ステップＳ４０５で送信量通知部６０２は、リンクテーブル６１１の次のエントリに注目する。そして、処理はステップＳ４０３に戻る。
他方、ステップＳ４０６で送信量通知部６０２は、変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値をボトルネック判定部６０３に通知する。すると、ボトルネック判定部６０３は、通知された値を、所定の閾値Ｔｏｕｔと比較する。
変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値が閾値Ｔｏｕｔよりも大きいとき、ボトルネック判定部６０３は「通信装置６００はボトルネックである」と判定し、判定結果をボトルネック通知部６０４に通知する。そして、処理はステップＳ４０７に移行する。
逆に、変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値が閾値Ｔｏｕｔ以下のとき、ボトルネック判定部６０３は「通信装置６００はボトルネックではない」と判定する。そして、ボトルネック検出処理は終了する。
ステップＳ４０７では、ボトルネック判定部６０３から通知を受けたボトルネック通知部６０４が、警報（すなわちボトルネック通知）を送信する。
上述したように、ボトルネック通知は、通常のデータパケット７１０と同じプロトコルにしたがって送信されてもよいし、別のプロトコルにしたがって送信されてもよい。また、ボトルネック通知は、特定の１つの宛先（例えばゲートウェイＧＷ１）をＧＤとするマルチホップ送信の対象であってもよいし、ネットワーク４００全体にフラッディングされてもよい。
例えば、送信量通知部６０２と存在通知部６１６はＩＥＥＥ ８０２．１５．４規格にしたがって、それぞれデータパケット７１０とハローパケット７２０を送信してもよい。他方で、ボトルネック通知部６０４は、ＩＥＥＥ ８０２．１１ｂ規格にしたがってボトルネック通知を送信してもよい。
その場合、リンクテーブル６１１とルーティングテーブル６１２では、ＩＥＥＥ ８０２．１５．４規格で通信可能な範囲にあるノード同士が隣接ノードとして管理される。他方で、ボトルネック通知部６０４は、ＩＥＥＥ ８０２．１１ｂ規格で通信可能な範囲にあるノード同士を隣接ノードとして管理する不図示のテーブルを有してもよい。
また、ボトルネック通知が特定の１つの宛先に送信される場合、ボトルネック通知は、例えば、図１０のアドホックヘッダ７０１に加えて、ＧＤとＧＳのフィールドを有する形式のパケット７００であってもよい。この場合、ボトルネック通知部６０４は、ボトルネック通知の宛先（例えばゲートウェイＧＷ１）のノードＩＤをＧＤとして設定し、通信装置６００自身のノードＩＤをＧＳとして設定する。また、ネットワーク内の各ノード（つまり通信装置６００）は、ボトルネック通知を、通常のデータパケット７１０と類似の方法でルーティングする。
あるいは、ネットワークの用途によっては、送信規制の要否を各ノードが自律的に判断するためにボトルネック通知が使われてもよい。そのために、ボトルネック通知はネットワーク全体にブロードキャストされ、フラッディングされてもよい。
例えば、ボトルネック通知用のパケットのタイプが次のように定義されていてもよい。ボトルネック通知は、例えば、図１０のアドホックヘッダ７０１に加えて、ＧＤとＧＳのフィールドを有する。そして、ＧＤとＬＤがブロードキャスト用の特殊な値に設定され、ＧＳがボトルネックのノードを示す。
すると、ボトルネック通知用のパケットを受信した通信装置６００では、タイプ判定部６０６が「受信されたパケットは、ボトルネック通知用のパケットである」と判定した場合、以下のような処理を行う。
すなわち、通信装置６００は、ボトルネック通知用のパケットを受信すると、パケットのＩＤとＧＳのペアを一定の時間、記憶し続ける。そして、通信装置６００は、記憶しているＩＤとＧＳのペアの中に、受信したパケットのＩＤとＧＳのペアと同じＩＤとＧＳのペアがあるか否かを判定する。
受信したパケットのＩＤとＧＳのペアと同じＩＤとＧＳのペアが見つかった場合、通信装置６００は、「過去に受信したことのあるボトルネック通知用のパケットと同じパケットを再度受信した」と判定し、受信したパケットを破棄する。逆に、受信したパケットのＩＤとＧＳのペアと同じＩＤとＧＳのペアが見つからなかった場合、通信装置６００は、受信したボトルネック通知用のパケットのＬＳのみを書き換えて、ボトルネック通知用のパケットをブロードキャストする。
以上のような処理により、ボトルネック通知用のパケットはネットワーク全体にブロードキャストされる。よって、ネットワーク内の各ノード（つまり通信装置６００）は、パケットのＧＳのノードにおいてボトルネックが検出されたことを認識することができる。通信装置６００は、上記認識に基づいて、例えば、「通信装置６００自身が生成して送信するデータの量を減らす」などの措置をとってもよい。
ところで、以上図１１〜１４を参照して説明した処理は、何らかのタイプのパケット７００の受信を契機として通信装置６００が行う処理である。しかし、通信装置６００は、パケット７００の受信とは独立したいくつかの処理も行う。
例えば、通信装置６００の存在通知部６１６は、定期的にハローパケット７２０を送信する。例えば、タイマＩＣ２０２またはタイマ３０４から、所定の間隔で定期的に出力される割り込み信号を契機として、存在通知部６１６は、ハローパケット７２０を生成し、送信する。
また、通信装置６００は、定期的または不定期に、ＧＳとしてデータパケット７１０を送信する。具体的には、通信装置６００は図１５の処理を行う。図１５は、第３実施形態におけるデータパケット送信処理のフローチャートである。例えば、ノードＦは、図１５の処理により、図６のデータパケットＤ１Ｆを生成して送信する。
まず、ステップＳ５０１で、上位層処理部６０９は、ＧＤの値とペイロードを取得する。
ＧＤの値は、固定的に、ネットワーク内の特定のノード（例えばゲートウェイＧＷ１）のノードＩＤに決められていてもよい。あるいは、上位層処理部６０９がＧＤの値を動的に決めてもよい。
また、ペイロードの内容は任意である。上位層処理部６０９は、例えば、センサ２０７またはセンサ３０８からの出力をペイロードとして取得してもよい。
次に、ステップＳ５０２で上位層処理部６０９は、ペイロードの長さを求める。
そして、ステップＳ５０３で上位層処理部６０９は、新たなデータパケット７１０用にバッファ部６０７の領域を割り当てる。上位層処理部６０９は、ステップＳ５０２で求めた長さに基づいて、割り当てる領域の大きさを決めることができる。そして、上位層処理部６０９は、割り当てた領域にペイロードを出力する。
続いて、ステップＳ５０４で上位層処理部６０９は、データパケット７１０の長さフィールドとＧＤフィールドに、それぞれ、ステップＳ５０２とＳ５０１で得た値を設定する。
また、次のステップＳ５０５で上位層処理部６０９は、データパケット７１０のＧＳフィールドとＬＳフィールドに、自ノードＩＤ（つまり通信装置６００自身のノードＩＤ）を設定する。
さらに、ステップＳ５０６で上位層処理部６０９は、新たなＩＤを生成する。そして、上位層処理部６０９は、データパケット７１０のＩＤフィールドに、生成した新たなＩＤの値を設定する。
そして、ステップＳ５０７で上位層処理部６０９は、データパケットを示す値（図１０の例では「Ｄａｔａ」）をデータパケット７１０のタイプとして設定する。
また、ステップＳ５０８で上位層処理部６０９は、ルーティング制御部６１０にデータパケット７１０の送信を依頼する。すると、ルーティング制御部６１０は送信量通知部６０２に送信トラヒックの計算を依頼し、送信量通知部６０２は、図１４のステップＳ４０１〜Ｓ４０５と同様にして、送信トラヒックを計算する。そして、送信量通知部６０２は、計算した値を、データパケット７１０の送信トラヒックとして設定する。
以上のステップＳ５０３〜Ｓ５０８により、バッファ部６０７上には、ＬＤ以外のフィールドが適宜設定された新たなデータパケット７１０が完成する。なお、ステップＳ５０４〜Ｓ５０８の実行順は適宜入れ替えられてもよい。
さて、ステップＳ５０８に続いて、ステップＳ５０９では、ルーティング制御部６１０が、送信の試行をやめる条件が成立するか否かを判定する。そして、送信の試行をやめる条件が成立する場合、処理はステップＳ５１０に移行する。逆に、送信の試行をやめる条件が成立していない場合、処理はステップＳ５１２に移行する。なお、送信の試行をやめる条件の詳細については後述する。
ステップＳ５１０では、送信の試行をやめる条件が成立している。よって、ルーティング制御部６１０は、データパケット７１０をバッファ部６０７から削除する。
そして、次のステップＳ５１１でルーティング制御部６１０は、上位層処理部６０９に対して送信失敗を報告する。すると、上位層処理部６０９は適宜のエラー処理を行う。そして、データパケット送信処理も終了する。
他方、ステップＳ５１２では、送信の試行をやめる条件が成立していない。よって、ルーティング制御部６１０は、送信の試行のため、まず、データパケット７１０の送信先として指定するＬＤを決める。そして、ルーティング制御部６１０は、決めたＬＤの値をバッファ部６０７のデータパケット７１０に設定する。
例えば、ルーティング制御部６１０は、ルーティングテーブル６１２において、データパケット７１０に設定されたＧＤの値と同じＧＤの値を持つエントリを検索する。そして、ルーティング制御部６１０は、検索の結果見つかったエントリを参照し、当該エントリに含まれるＬＤの候補のうちの１つを選択する。ＬＤの候補の選択の仕方は、ルーティング制御部６１０がしたがうルーティングアルゴリズムによって様々であってよく、詳細については後述する。
そして、次のステップＳ５１３で送信量通知部６０２は、送信トラヒックを含むデータパケット７１０を、ステップＳ５１２でルーティング制御部６１０が決めたＬＤ宛に送信する。そして、送信量通知部６０２等を含むデータパケット処理部６０８は、ＡＣＫパケット７３０の受信を待つ。すなわち、データパケット処理部６０８は、ＡＣＫタイムアウト時間が経過するか、または、送信したデータパケット７１０に対応するＡＣＫパケット７３０が受信されるまで、図１５のプロセスをスリープさせる。
ステップＳ５１３の次のステップＳ５１４は、一旦スリープした図１５のプロセスが、ＡＣＫタイムアウト時間の経過またはＡＣＫパケット７３０の受信によりレジュームすると、実行される。ステップＳ５１４においてルーティング制御部６１０は、ＡＣＫタイムアウト時間が経過する前にＡＣＫパケット７３０が受信されたのか否かを判定する。
ＡＣＫタイムアウト時間が経過する前にＡＣＫパケット７３０が受信された場合（つまり、ＡＣＫパケット７３０の受信を契機にプロセスがレジュームした場合）、ステップＳ５１３でのデータパケット７１０の送信が成功したので、処理はステップＳ５１５に移行する。
逆に、ＡＣＫタイムアウト時間が経過するまでにＡＣＫパケット７３０が受信されなかった場合（つまり、ＡＣＫタイムアウト時間の経過を契機にプロセスがレジュームした場合）、ステップＳ５１３でのデータパケット７１０の送信は失敗したので、処理はステップＳ５１６に移行する。
ステップＳ５１５でルーティング制御部６１０は、データパケット７１０の送信の成功を反映させるために、必要に応じてーティングテーブル６１２を更新する。そして、データパケット送信処理が終了する。例えば、図１２のステップＳ２１４と同様に、ルーティング制御部６１０は、ステップＳ５１２で選択したＬＤの評価値を小さくしてもよい（つまり評価を上げてもよい）。
他方、ステップＳ５１６でルーティング制御部６１０は、データパケット７１０の送信の失敗を反映させるために、必要に応じてルーティングテーブル６１２を更新する。そして、処理はステップＳ５０９に戻る。例えば、図１２のステップＳ２１５と同様に、ルーティング制御部６１０は、ステップＳ５１２で選択したＬＤの評価値を大きくしてもよい（つまり評価を下げてもよい）。
ところで、以上説明したとおり、送信の試行をやめる条件が成立するまで、１回または複数回、送信の試行が行われる。例えば、あるルーティングアルゴリズムによれば、ルーティング制御部６１０は、１回目のステップＳ５１２においては、最も評価の高い（すなわち最も評価値の小さい）ＬＤの候補を選択してもよい。
そして、ＡＣＫタイムアウト時間の経過前にＡＣＫパケット７３０が受信されなかった場合、ステップＳ５１６でルーティング制御部６１０は評価値を更新する。すると、２回目以降のステップＳ５１２においては、ルーティング制御部６１０は、単純に最も評価の高いＬＤの候補を選択してもよいし、あるいは、以前の繰り返しにおけるステップＳ５１２で未選択のものの中で最も評価の高いＬＤの候補を選択してもよい。
また、例えば、評価値の範囲が０以上１以下と決められており、１が最も低い評価を示すものとする。この場合、ルーティング制御部６１０は、ステップＳ５０９において、下記の（Ｄ１）または（Ｄ２）が成立する場合に、送信の試行をやめる条件が成立している、と判定してもよい。
（Ｄ１）データパケット７１０に設定されたＧＤの値と同じＧＤの値を有するルーティングテーブル６１２のエントリにおいて、１未満の評価値を持つＬＤの候補が存在しない。
（Ｄ２）上記（Ｄ１）のエントリにおいて、１未満の評価値を持つＬＤの候補のすべてが、既に以前の繰り返しにおけるステップＳ５１２で選択済みである。
また、図１２に関して説明したのと同様のループ検出が行われてもよい。つまり、通信装置６００は、ステップＳ５０６で生成したＩＤを、通信装置６００自身のノードＩＤ（つまりＧＳを示すノードＩＤ）と対応づけて記憶し、記憶したＩＤとＧＳの値をループ検出用に用いてもよい。
続いて、以上説明した第３実施形態とは異なり、送信トラヒックがハローパケットに埋め込まれる第４実施形態について、図１６〜２１を参照して説明する。
図１６は、第４実施形態におけるハローパケットの送受信に関するタイミングチャートである。図１６のタイミングチャートは、図４のノードＡ〜Ｉの各々が、図１７とともに後述する第４実施形態の通信装置８００である場合の、ハローパケットの送受信を表す。
なお、ゲートウェイＧＷ１は、必ずしもノードＡ〜Ｉと同様に構成されている必要はないが、少なくともハローパケットの送信に関しては、ゲートウェイＧＷ１もノードＡ〜Ｉと同様の動作を行う。また、以下では説明の簡単化のため、ノードＡ〜ＩおよびゲートウェイＧＷ１が、いずれも同じ間隔ΔＨで定期的にハローパケットを送信するものとする。
図１６では、各ハローパケットは、３文字または４文字の参照符号で識別される。１文字目はハローパケットを示す「Ｈ」である。最後の文字は、同じノードから送信される複数のハローパケットを区別するための数字である。真ん中の１文字または２文字は、ハローパケットを送信するノードを示す。
また、ネットワーク４００内でのデータパケットの最終的な送信先は、第３実施形態と同様に、ゲートウェイＧＷ１であるとする。さらに、ノードＡ〜Ｉの各々がボトルネックに関する判定結果を通知する先も、ゲートウェイＧＷ１であるとする。
そして、詳しくは図１９とともに後述するが、第４実施形態では、データパケットではなくハローパケットが「送信トラヒック」フィールドを含む。さらに、ハローパケットは、「当該ハローパケットの送信元のノードが、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、どの隣接ノードをＬＤとして選択するか」を示す「選択ＬＤ」というフィールドも含む。
そして、ハローパケットは、１ホップの範囲内でブロードキャストされる。図１６では、同じ１点から出る複数本の矢印により、ハローパケットのブロードキャストを示している。また、矢印に重ねて描かれた矩形内の数値が、当該矢印の表すハローパケット中の送信トラヒックの値である。
なお、以下では説明の便宜上、図４に関する説明と同様に、ノードＡ〜Ｉの各々が所定期間に生成してゲートウェイＧＷ１宛に送信するデータの量の期待値を「１」とする。また、ボトルネックの判定用の閾値を「５」とする。「期待値」の意味については第３実施形態と同様である。
さらに、図１６に関する以下の説明では、「既に図４に実線矢印で示す経路が構築されている」と仮定する。この仮定が意味するのは、「経路が構築されて安定する前に送受信されるハローパケットに含まれる送信トラヒックの値に基づくボトルネックの予測または検出の結果は、構築中の過渡的な経路を反映した暫定的な結果に過ぎない」ということである。つまり、この仮定について補足説明をすれば、以下のとおりである。
アドホックネットワークにおいては、一般には、複数のノードがそれぞれハローパケットを送信することで自らの存在を通知し、その結果として、各ノードは隣接する他のノードの存在を認識する。そして、データパケットがルーティングされる経路は、経路構築アルゴリズムにもよるが、隣接ノードの認識の後に構築されることが多い。
もちろん、ハローパケットは、経路の構築後も引き続いて繰り返し送信される。なぜなら、ノード同士の隣接関係は変化し得るからである。そして、経路もずっと固定されるわけではなく、ノード同士の隣接関係の変化に応じて、適宜再構築され得る。
このように、経路が安定する前（つまり経路の構築中）にも、経路が安定した後にも、ハローパケットは繰り返し送信される。そして、経路が安定する前に送信されるハローパケットにも送信トラヒックが含まれていてよい。
しかし、経路が安定する前に送受信されるハローパケットに含まれる送信トラヒックの値に基づくボトルネックの予測または検出の結果は、構築中の過渡的な経路を反映した暫定的な結果に過ぎない。第４実施形態では、経路が構築され安定した後、さらにある程度の回数のハローパケットの送信が行われると、安定した経路を反映した、適切な、ボトルネックの予測または検出の結果が得られる。
よって、図１６に関する以下の説明では、上記のとおり「既に図４に実線矢印で示す経路が構築されている」と仮定する。そして、この仮定のもとで、「経路の構築後に、上記のようにある程度の回数のハローパケットの送信が行われると、ボトルネックの予測または検出の、適切な結果が得られる」ということを説明する。
なお、経路が安定するまでに送信されたハローパケットに含まれる送信トラヒックの影響が、経路の構築後に打ち消されるまでには、何回か余計にハローパケットの送信が必要になる場合がある。よって、上記影響の打ち消しにかかる時間の短縮を図るため、各ノードは、経路が安定したと見なせるようになるまでは、ハローパケットに送信トラヒックとして「０」を設定してもよい。
例えば、各ノードは、最初に電源が入れられてから、ゲートウェイＧＷ１宛のデータパケットの送信時にＬＤとして選択したノードの履歴を監視してもよい。経路が安定するまでは、各ノードが試行錯誤的にＬＤを選択するので、ループが発生することもあるし、ＬＤとして選択される隣接ノードがデータパケットの送信のたびに変わることもあり得る。しかし、経路が安定すれば、同じ隣接ノードが連続してＬＤとして選択されるようになる。
よって、各ノードは、例えば、最初に電源が入れられてから、同じＧＤに対して初めて所定の回数連続して同じ隣接ノードをＬＤとして選択したら、「経路が安定した」と見なしてもよい。そして、各ノードは、経路が安定したと見なせるようになるまでは、ハローパケットに送信トラヒックとして「０」を設定してもよい。
以下では説明の簡略化のため、経路が安定するまでに送信されるハローパケットには「０」という送信トラヒックが設定されているものと仮定する。そして、この仮定にしたがって、以下では、経路が安定するまでに送信されるハローパケットに含まれる送信トラヒックの影響の打ち消しについては説明を省略する。
さて、図１６には、一例として、経路が安定した後の、下記のような処理シーケンスが例示されている。
まず、ノードＡがハローパケットＨＡ１を送信する。ハローパケットＨＡ１に設定される送信トラヒックの値は「１」である。なぜなら、ハローパケットＨＡ１の送信の前には、ノードＡは、「０」以外の送信トラヒックが設定されたいかなるハローパケットも、他のノードから受信してはいないからである。そのため、ハローパケットＨＡ１には、ノードＡが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＡは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＤを選択する。よって、ハローパケットＨＡ１には、選択ＬＤとしてノードＤが指定される。
ここで、図４に示すように、ノードＡにはノードＢとＤが隣接する。よって、ハローパケットＨＡ１はノードＢとＤにおいて受信される。
ノードＢは、ハローパケットＨＡ１に指定された選択ＬＤではないので、ハローパケットＨＡ１の送信トラヒックの値を無視する。他方、ノードＤは、選択ＬＤなので、ハローパケットＨＡ１のＬＳであるノードＡと対応づけて、ハローパケットＨＡ１に設定された送信トラヒックの「１」という値を記憶する。
さて、図１６の例では、偶然にもハローパケットＨＡ１の送信とほぼ同時に、ゲートウェイＧＷ１が、ハローパケットＨＧＷ１を送信する。ハローパケットＨＧＷ１において、送信トラヒックの値は「０」であり、選択ＬＤの値は、ノードＩＤとしては無効な特殊な値である。なぜなら、ゲートウェイＧＷ１自身は、他のノードにデータパケットを送信しないからである。
また、図４に示すように、ゲートウェイＧＷ１にはノードＧ、ＨおよびＩが隣接する。よって、ハローパケットＨＧＷ１はノードＧ、ＨおよびＩにおいて受信される。ところが、ノードＧ、ＨおよびＩのいずれも、選択ＬＤではないので、ハローパケットＨＧＷ１の送信トラヒックの値を無視する。
そして、図１６の例では、次にノードＤがハローパケットＨＤ１を送信する。ハローパケットＨＤ１に設定される送信トラヒックの値は「２」である。なぜなら、ノードＤは既にハローパケットＨＡ１を受信しており、ノードＡと対応づけて「１」という値を記憶しているからである。よって、ノードＤは、ノードＡと対応づけて記憶している「１」という値と、ノードＤ自身が所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和である「２」を、ハローパケットＨＤ１に送信トラヒックとして設定する。
また、図４の実線矢印に示すように、ノードＤは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＥを選択する。よって、ハローパケットＨＤ１には、選択ＬＤとしてノードＥが指定される。
ここで、図４に示すように、ノードＤにはノードＡ、ＢおよびＥが隣接する。よって、ハローパケットＨＤ１はノードＡ、ＢおよびＥにおいて受信される。
しかし、ノードＡとＢは、いずれも、ハローパケットＨＤ１に指定された選択ＬＤではないので、ハローパケットＨＤ１の送信トラヒックの値を無視する。他方、ノードＥは、選択ＬＤなので、ハローパケットＨＤ１のＬＳであるノードＤと対応づけて、ハローパケットＨＤ１に設定された送信トラヒックの「２」という値を記憶する。
さらに、図１６の例では、偶然にもハローパケットＨＤ１とほぼ同時に、ノードＧがハローパケットＨＧ１を送信する。ハローパケットＨＧ１に設定される送信トラヒックの値は「１」である。なぜなら、ハローパケットＨＧ１の送信の前には、ノードＧは、「０」以外の送信トラヒックが設定されたいかなるハローパケットも、他のノードから受信してはいないからである。そのため、ハローパケットＨＧ１には、ノードＧが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＧは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてゲートウェイＧＷ１を選択する。よって、ハローパケットＨＧ１には、選択ＬＤとしてゲートウェイＧＷ１が指定される。
ここで、図４に示すように、ノードＧには、ノードＦおよびＨ、ならびにゲートウェイＧＷ１が隣接する。よって、ハローパケットＨＧ１は、ノードＦおよびＨ、ならびにゲートウェイＧＷ１において受信される。ところが、ノードＦとＨは、選択ＬＤではないので、ハローパケットＨＧ１の送信トラヒックの値を無視する。また、第４実施形態では、ゲートウェイＧＷ１は「ゲートウェイＧＷ１自身がボトルネックか否か」を判定しないので、ゲートウェイＧＷ１も送信トラヒックの値を無視する。
そして、図１６の例では、次にノードＢがハローパケットＨＢ１を送信する。ハローパケットＨＢ１に設定される送信トラヒックの値は「１」である。なぜなら、ノードＢは、既にハローパケットＨＤ１を受信してはいるが、上記のとおりハローパケットＨＤ１の送信トラヒックの値は考慮に入れないからである。したがって、ハローパケットＨＢ１には、ノードＢが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＢは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＥを選択する。よって、ハローパケットＨＢ１には、選択ＬＤとしてノードＥが指定される。
ここで、図４に示すようにノードＢにはノードＡ、Ｃ、ＤおよびＥが隣接する。よって、ハローパケットＨＢ１はノードＡ、Ｃ、ＤおよびＥにおいて受信される。
しかし、ノードＡ、ＣおよびＤは、いずれも、ハローパケットＨＢ１に指定された選択ＬＤではないので、ハローパケットＨＢ１の送信トラヒックの値を無視する。他方、ノードＥは、選択ＬＤなので、ハローパケットＨＢ１のＬＳであるノードＢと対応づけて、ハローパケットＨＢ１に設定された送信トラヒックの「１」という値を記憶する。
また、図１６の例では、続いて、ノードＨがハローパケットＨＨ１を送信する。ハローパケットＨＨ１に設定される送信トラヒックの値は「１」である。なぜなら、ノードＨは、既にハローパケットＨＧＷ１とＨＧ１を受信してはいるが、上記のとおり、ハローパケットＨＧＷ１とＨＧ１の送信トラヒックの値は考慮に入れないからである。したがって、ハローパケットＨＨ１には、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＨは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてゲートウェイＧＷ１を選択する。よって、ハローパケットＨＨ１には、選択ＬＤとしてゲートウェイＧＷ１が指定される。
ここで、図４に示すように、ノードＨには、ノードＦ、ＧおよびＩ、ならびにゲートウェイＧＷ１が隣接する。よって、ハローパケットＨＨ１は、ノードＦ、ＧおよびＩ、ならびにゲートウェイＧＷ１において受信される。ところが、ノードＦ、ＧおよびＩは、選択ＬＤではないので、ハローパケットＨＨ１の送信トラヒックの値を無視する。また、ゲートウェイＧＷ１は、ハローパケットＨＧ１と同様に、ハローパケットＨＨ１の送信トラヒックの値も無視する。
続いて、図１６の例では、ノードＥがハローパケットＨＥ１を送信する。ハローパケットＨＥ１に設定される送信トラヒックの値は「４」である。なぜなら、ノードＥは既にハローパケットＨＤ１とＨＢ１を受信しており、ノードＤおよびＢとそれぞれ対応づけて、「２」および「１」という値を記憶しているからである。よって、ノードＥは、記憶している「２」および「１」という値と、ノードＥ自身が所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和である「４」を、ハローパケットＨＥ１に送信トラヒックとして設定する。
また、図４の実線矢印に示すように、ノードＥは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＦを選択する。よって、ハローパケットＨＥ１には、選択ＬＤとしてノードＦが指定される。
ここで、図４に示すように、ノードＥには、ノードＢ、Ｃ、ＤおよびＦが隣接する。よって、ハローパケットＨＥ１は、ノードＢ、Ｃ、ＤおよびＦにおいて受信される。
しかし、ノードＢ、ＣおよびＤは、いずれも、ハローパケットＨＥ１に指定された選択ＬＤではないので、ハローパケットＨＥ１の送信トラヒックの値を無視する。他方、ノードＦは、選択ＬＤなので、ハローパケットＨＥ１のＬＳであるノードＥと対応づけて、ハローパケットＨＥ１に設定された送信トラヒックの「４」という値を記憶する。
そして、図１６の例では、次にノードＩがハローパケットＨＩ１を送信する。ハローパケットＨＩ１に設定される送信トラヒックの値は「１」である。なぜなら、ノードＩは、既にハローパケットＨＧＷ１とＨＨ１を受信してはいるが、上記のとおり、ハローパケットＨＧＷ１とＨＨ１の送信トラヒックの値は考慮に入れないからである。したがって、ハローパケットＨＩ１には、ノードＩが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＩは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてゲートウェイＧＷ１を選択する。よって、ハローパケットＨＩ１には、選択ＬＤとしてゲートウェイＧＷ１が指定される。
ここで、図４に示すように、ノードＩには、ノードＦおよびＨ、ならびにゲートウェイＧＷ１が隣接する。よって、ハローパケットＨＩ１は、ノードＦおよびＨ、ならびにゲートウェイＧＷ１において受信される。ところが、ノードＦとＨは、選択ＬＤではないので、ハローパケットＨＩ１の送信トラヒックの値を無視する。また、ゲートウェイＧＷ１は、ハローパケットＨＧ１やＨＨ１と同様に、ハローパケットＨＩ１の送信トラヒックの値も無視する。
続いて、図１６の例では、ノードＣがハローパケットＨＣ１を送信する。ハローパケットＨＣ１に設定される送信トラヒックの値は「１」である。なぜなら、ノードＣは既にハローパケットＨＢ１とＨＥ１を受信してはいるが、上記のとおり、ハローパケットＨＢ１とＨＥ１の送信トラヒックの値は考慮に入れないからである。したがって、ハローパケットＨＣ１には、ノードＣが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」が、送信トラヒックとして設定される。
また、図４の実線矢印に示すように、ノードＣは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＥを選択する。よって、ハローパケットＨＣ１には、選択ＬＤとしてノードＥが指定される。
ここで、図４に示すように、ノードＣには、ノードＢとＥが隣接する。よって、ハローパケットＨＣ１は、ノードＢとＥにおいて受信される。ノードＢは、ハローパケットＨＣ１に指定された選択ＬＤではないので、ハローパケットＨＣ１の送信トラヒックの値を無視する。他方、ノードＥは、選択ＬＤなので、ハローパケットＨＣ１のＬＳであるノードＣと対応づけて、ハローパケットＨＣ１に設定された送信トラヒックの「１」という値を記憶する。
続いて、図１６の例では、ノードＦがハローパケットＨＦ１を送信する。ハローパケットＨＦ１に設定される送信トラヒックの値は「５」である。なぜなら、第１に、ノードＦは、既に受信したハローパケットのうち、ハローパケットＨＧ１とＨＨ１とＨＩ１の送信トラヒックの値は上記のとおり考慮に入れないからである。そして、第２に、ノードＦは、既に受信したハローパケットＨＥ１の送信トラヒックの「４」という値を、ノードＥと対応づけて記憶しているからである。よって、ノードＦは、記憶している「４」という値と、ノードＦ自身が所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和である「５」を、ハローパケットＨＦ１に送信トラヒックとして設定する。
また、図４の実線矢印に示すように、ノードＦは、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケットを送信するときに、ＬＤとしてノードＨを選択する。よって、ハローパケットＨＦ１には、選択ＬＤとしてノードＨが指定される。
ここで、図４に示すように、ノードＦには、ノードＥ、Ｇ、ＨおよびＩが隣接する。よって、ハローパケットＨＦ１は、ノードＥ、Ｇ、ＨおよびＩにおいて受信される。
しかし、ノードＥ、ＧおよびＩは、いずれも、ハローパケットＨＦ１に指定された選択ＬＤではないので、ハローパケットＨＦ１の送信トラヒックの値を無視する。
他方、ノードＨは、選択ＬＤなので、ハローパケットＨＦ１のＬＳであるノードＦと対応づけて、ハローパケットＨＦ１に設定された送信トラヒックの「５」という値を記憶する。さらに、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」と上記の「５」という値の和は、閾値の「５」を超える。よって、ノードＨは「ノードＨはネットワーク４００におけるボトルネックである」と判定し、ボトルネック通知を送信する。
そして、図１６の例では、ハローパケットＨＡ１の送信から間隔ΔＨをおいて、ノードＡがハローパケットＨＡ２を送信する。また、ハローパケットＨＧＷ１の送信から間隔ΔＨをおいて、ゲートウェイＧＷ１がハローパケットＨＧＷ２を送信する。さらに、ハローパケットＨＤ１の送信から間隔ΔＨをおいて、ノードＤがハローパケットＨＤ２を送信する。
また、ハローパケットＨＧ１の送信から間隔ΔＨをおいて、ノードＧがハローパケットＨＧ２を送信する。そして、ハローパケットＨＢ１の送信から間隔ΔＨをおいて、ノードＢがハローパケットＨＢ２を送信する。
以上のハローパケットＨＡ２、ＨＧＷ２、ＨＤ２、ＨＧ２およびＨＢ２には、それぞれ、ハローパケットＨＡ１、ＨＧＷ１、ＨＤ１、ＨＧ２およびＨＢ１と同じ値の送信トラヒックが設定されている。よって、ハローパケットＨＡ２、ＨＧＷ２、ＨＤ２、ＨＧ２およびＨＢ２の送信が引き起こす結果は、ハローパケットＨＡ１、ＨＧＷ１、ＨＤ１、ＨＧ２およびＨＢ１が送信されたときと同じである。
その後、ノードＨが、ハローパケットＨＨ１の送信から間隔ΔＨをおいて、ハローパケットＨＨ２を送信する。ノードＨは、ハローパケットＨＨ１を送信した時点では、まだハローパケットＨＦ１を受信していなかった。そのため、ハローパケットＨＨ１の送信トラヒックの値は上記のとおり「１」である。
しかし、ハローパケットＨＨ２を送信する時点では、ノードＨは既にハローパケットＨＦ１を受信しており、ハローパケットＨＦ１の送信トラヒックの「５」という値をノードＦと対応づけて記憶している。よって、ハローパケットＨＨ２の送信トラヒックの値は、ハローパケットＨＨ１とは異なり、記憶している「５」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和の、「６」である。
ただし、ハローパケットＨＨ１の場合と同様に、ハローパケットＨＨ２の送信トラヒックの値は、ノードＦ、ＧおよびＩ、ならびにゲートウェイＧＷ１に無視される。よって、ハローパケットＨＨ２の受信を契機としてボトルネック通知が送信されることはない。
その後、ノードＥが、ハローパケットＨＥ１の送信から間隔ΔＨをおいて、ハローパケットＨＥ２を送信する。ノードＥは、ハローパケットＨＥ１を送信した時点では、まだハローパケットＨＣ１を受信していなかった。そのため、ハローパケットＨＥ１の送信トラヒックの値は上記のとおり「４」である。
しかし、ハローパケットＨＥ２を送信する時点では、ノードＥは既にハローパケットＨＣ１を受信しており、ハローパケットＨＣ１の送信トラヒックの「１」という値をノードＣと対応づけて記憶している。また、もちろんノードＥは、ハローパケットＨＤ２の受信を契機として、ハローパケットＨＤ２の送信トラヒックの「２」という値をノードＤと対応づけて記憶している。さらに、ノードＥは、ハローパケットＨＢ２の受信を契機として、ハローパケットＨＢ２の送信トラヒックの「１」という値をノードＢと対応づけて記憶してもいる。
よって、ハローパケットＨＥ２の送信トラヒックの値は、ハローパケットＨＥ１とは異なり、記憶している上記の「１」と「２」と「１」という値と、ノードＥが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和の、「５」である。
そして、ハローパケットＨＥ２は、ノードＢ、Ｃ、ＤおよびＦで受信される。ノードＢ、ＣおよびＤは、ハローパケットＨＥ２に指定された選択ＬＤではないので、ハローパケットＨＥ２の送信トラヒックの値を無視する。
しかし、ノードＦは、選択ＬＤなので、ハローパケットＨＥ２のＬＳであるノードＥと対応づけて、ハローパケットＨＥ２に設定された送信トラヒックの「５」という値を記憶する。つまり、ノードＦは、今までノードＥと対応づけて記憶していた「４」という値を「５」に更新する。
また、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」と上記の「５」という値の和は、閾値の「５」を超える。よって、ノードＦは「ノードＦはネットワーク４００におけるボトルネックである」と判定し、ボトルネック通知を送信する。
その後、ノードＩが、ハローパケットＨＩ１の送信から間隔ΔＨをおいて、ハローパケットＨＩ２を送信する。また、ノードＣが、ハローパケットＨＣ１の送信から間隔ΔＨをおいて、ハローパケットＨＣ２を送信する。
ハローパケットＨＩ２およびＨＣ２には、それぞれ、ハローパケットＨＩ１およびＨＣ１と同じ値の送信トラヒックが設定されている。よって、ハローパケットＨＩ２およびＨＣ２の送信が引き起こす結果は、ハローパケットＨＩ１およびＨＣ１が送信されたときと同じである。
その後、ノードＦが、ハローパケットＨＦ１の送信から間隔ΔＨをおいて、ハローパケットＨＦ２を送信する。ノードＦは、上記のとおり、ハローパケットＨＥ２の受信を契機として、ノードＥと対応づけて記憶していた値を更新している。したがって、その更新に応じて、ハローパケットＨＦ２に設定される送信トラヒックの値も、ハローパケットＨＥ１に設定されていた値とは異なるものとなる。すなわち、更新後の「５」という値と、ノードＦが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和である「６」が、ハローパケットＨＦ２の送信トラヒックとして設定される。
そして、ハローパケットＨＦ２は、ノードＥ、Ｇ、ＨおよびＩにおいて受信される。ノードＥ、ＧおよびＩは、ハローパケットＨＦ２に指定された選択ＬＤではないので、ハローパケットＨＦ２の送信トラヒックの値を無視する。
しかし、ノードＨは、選択ＬＤなので、ハローパケットＨＦ２のＬＳであるノードＦと対応づけて、ハローパケットＨＦ２に設定された送信トラヒックの「６」という値を記憶する。つまり、ノードＨは、今までノードＦと対応づけて記憶していた「５」という値を「６」に更新する。
また、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」と上記の「６」という値の和は、閾値の「５」を超える。よって、ノードＨは「ノードＨはネットワーク４００におけるボトルネックである」と判定し、ボトルネック通知を送信する。
その後、ハローパケットＨＡ２の送信から間隔ΔＨをおいて、ノードＡがハローパケットＨＡ３を送信する。また、ハローパケットＨＧＷ２の送信から間隔ΔＨをおいて、ゲートウェイＧＷ１がハローパケットＨＧＷ３を送信する。さらに、ハローパケットＨＤ２の送信から間隔ΔＨをおいて、ノードＤがハローパケットＨＤ３を送信する。
また、ハローパケットＨＧ２の送信から間隔ΔＨをおいて、ノードＧがハローパケットＨＧ３を送信する。そして、ハローパケットＨＢ２の送信から間隔ΔＨをおいて、ノードＢがハローパケットＨＢ３を送信する。
以上のハローパケットＨＡ３、ＨＧＷ３、ＨＤ３、ＨＧ３およびＨＢ３には、それぞれ、ハローパケットＨＡ２、ＨＧＷ２、ＨＤ２、ＨＧ２およびＨＢ２と同じ値の送信トラヒックが設定されている。よって、ハローパケットＨＡ３、ＨＧＷ３、ＨＤ３、ＨＧ３およびＨＢ３の送信が引き起こす結果は、ハローパケットＨＡ２、ＨＧＷ２、ＨＤ２、ＨＧ２およびＨＢ２が送信されたときと同じである。
その後、ノードＨが、ハローパケットＨＨ２の送信から間隔ΔＨをおいて、ハローパケットＨＨ３を送信する。ノードＨは、上記のとおり、ハローパケットＨＦ２の受信を契機として、ノードＦと対応づけて記憶していた値を更新している。したがって、その更新に応じて、ハローパケットＨＨ３に設定される送信トラヒックの値も、ハローパケットＨＨ２に設定されていた値とは異なるものとなる。すなわち、更新後の「６」という値と、ノードＨが所定期間にゲートウェイＧＷ１宛に送信するデータ量の期待値である「１」との和である「７」が、ハローパケットＨＨ３の送信トラヒックとして設定される。
ただし、ハローパケットＨＨ１およびＨＨ２の場合と同様に、ハローパケットＨＨ３の送信トラヒックの値は、ノードＦ、ＧおよびＩ、ならびにゲートウェイＧＷ１に無視される。よって、ハローパケットＨＨ３の受信を契機としてボトルネック通知が送信されることはない。
以下同様に、ネットワーク４００内のノードＡ〜ＩおよびゲートウェイＧＷ１は、それぞれ間隔ΔＨでハローパケットの送信を繰り返す。しかし、図１６に示すように、送信トラヒックの値は、ハローパケットＨＨ３の送信の時点で収束する。
以上のように、ネットワーク４００内の各ノードがハローパケットを送信する順序によっては、経路が安定してから各ノードが１回ずつハローパケットを送信するだけでは、まだボトルネックの予測または検出は不完全である。しかし、何回かハローパケットの送信が繰り返されるうちに、送信トラヒックの値は収束し、ボトルネックが漏れなく予測または検出されるようになる。
ボトルネックが漏れなく予測または検出されるまでにかかる最大時間は、具体的には、次のように定式化することができる。
図４のようなネットワークトポロジにおいて、ＧＤを根ノードと見なすことにする。また、データパケットの送信に使われるリンク（つまり図４の実線矢印）で接続された互いに隣接する２つのノードのうち、ＬＳたるノードを子ノードと見なすことにし、ＬＤたるノードを親ノードと見なすことにする。
すると、葉ノードが送信するハローパケットの送信トラヒックの値は、常に「既に収束している」と見なしてよい。また、葉ノードではない或るノードが送信するハローパケットの送信トラヒックの値を「既に収束している」と見なしてよいのは、当該或るノードがすべての子ノードから「既に収束している」と見なせる送信トラヒックを含むハローパケットを受信した後である。
そして、送信トラヒックの値が「既に収束している」か否かについて、以上のように定義した場合に、経路が安定してから、根ノードが、根ノードのすべての子ノードから、それぞれ「既に収束している」と見なしてよいハローパケットを受信するまでにかかる時間が、上記最大時間である。
上記定義によれば、ノードＡ、Ｂ、Ｃ、ＧおよびＩは、葉ノードである。これらの葉ノードから送信されるハローパケットの送信トラヒックの値は、「既に収束している」と見なせるし、図１６に示すように、経路が安定した後は変化しない。
また、上記定義によれば、例えば、葉ノードではないノードＥが、子ノードのノードＣからハローパケットＨＣ１を受信する前に送信するハローパケットＨＥ１の送信トラヒックは、まだ「収束している」と見なせない。しかし、ハローパケットＨＥ２の送信トラヒックの値は、「既に収束している」と見なせる。
同様に、ハローパケットＨＦ１、ＨＨ１およびＨＨ２の送信トラヒックの値は、まだ「収束している」と見なせない。しかし、ハローパケットＨＦ２とＨＨ３の送信トラヒックの値は、「既に収束している」と見なせる。
よって、図１６の例では、「ボトルネックが漏れなく予測または検出されるまでにかかる最大時間」とは、「経路が安定してから、ゲートウェイＧＷ１がハローパケットＨＨ３を受信するまでにかかる時間」のことである。
なお、ネットワーク４００内のノードＡ〜Ｉは、ランダムな順序でハローパケットを送信する可能性がある。また、上記の説明から明らかなとおり、上記最大時間は、データパケットが送信される経路のトポロジに依存する。そのため、上記最大時間を事前に正しく認識することは困難である。
そこで、上記最大時間の近似値として、例えば、ハローパケットの送信間隔ΔＨと、ネットワーク４００内におけるゲートウェイＧＷ１までの最大ホップ数（またはその近似値として見積もられる値）との積が、参照されてもよい。例えば、ゲートウェイＧＷ１は、最大時間待っても警告を受信しなければ、「ボトルネックのノードはない」と判断してもよい。
さて、以上、図１６を参照して説明した各ノードの動作が、より具体的にはどのようにして実現されるのかについて、以下では図１７〜２１を参照してさらに詳しく説明する。
図１７は、第４実施形態の通信装置のブロック構成図である。第４実施形態では、ノードＡ〜Ｉの各々が、図１７の通信装置８００のように構成される。
図１７の通信装置８００は、図１の通知受信部１０１、送信量通知部１０２、ボトルネック判定部１０３、送信ボトルネック通知部１０４とそれぞれ類似の、通知受信部８０１、送信量通知部８０２、ボトルネック判定部８０３、ボトルネック通知部８０４を有する。また、通信装置８００は、図１の経路情報記憶部１０５と類似の経路情報記憶部８０５を有する。
さらに、通信装置８００は、受信したパケットのタイプを判定するタイプ判定部８０６と、データパケットを一時的に格納するバッファ部８０７を有する。また、通信装置８００は、データパケットの送受信に関する処理を行うデータパケット処理部８０８を有する。データパケット処理部８０８は、データパケットのペイロードに関する処理を行う上位層処理部８０９と、データパケットのＧＤに応じてＬＤを決定する（すなわちデータパケットをルーティングする経路を決定する）ルーティング制御部８１０を有する。
また、経路情報記憶部８０５は、通信装置８００に隣接する他の通信装置に関する情報を記憶するリンクテーブル８１１を含む。経路情報記憶部８０５は、さらに、データパケットのＬＤを決定するための情報を記憶するルーティングテーブル８１２も含む。
なお、リンクテーブル８１１の具体例については図１８とともに後述する。また、ルーティングテーブル８１２は、図９のルーティングテーブル６１２Ｄと同様の形式なので、詳細についての説明は割愛する。
さらに、通信装置８００は、通信装置８００自身が所定期間に生成してゲートウェイＧＷ１宛に送信するデータパケットの量の期待値を記憶する送信量記憶部８１３を有する。例えば、図１６の例では、送信量記憶部８１３は「１」という値を記憶する。
そして、通信装置８００は、ハローパケットの送受信に関する処理を行うハローパケット処理部８１４を有する。ハローパケット処理部８１４は、上記の通知受信部８０１を含む。ハローパケット処理部８１４はさらに、受信したハローパケットに基づいてリンクテーブル８１１を更新するリンク管理部８１５と、ハローパケットを定期的に送信する存在通知部８１６を含む。なお、上記の送信量通知部８０２は、存在通知部８１６に含まれる。
ところで、通信装置８００が無線ネットワークで使われる装置の場合、通信装置８００は、例えば図２の通信装置２００により実現されてもよい。例えば、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５がパケットを受信すると、パケットは、バッファ部８０７としてのＤＲＡＭ２０３に格納されてもよい。そして、ＭＰＵ２０１がタイプ判定部８０６としてパケットのタイプを判定してもよい。
あるいは、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、ＭＰＵ２０１の代わりにタイプ判定部８０６としてパケットのタイプの判定を行うように構成されていてもよい。その場合、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、受信したパケットが制御パケットであればパケット全体をＭＰＵ２０１に出力してもよい。逆に、受信したパケットがデータパケットであれば、８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５は、パケットのヘッダだけをＭＰＵ２０１に出力し、ヘッダを含むパケットの全体をバッファ部８０７としてのＤＲＡＭ２０３に格納してもよい。
ＭＰＵ２０１はさらに、データパケット処理部８０８として各種の処理を行ってもよい。データパケット処理部８０８のうち上位層処理部８０９を実現するために、さらにセンサ２０７が使われてもよい。また、データパケット処理部８０８がデータパケットを送信する機能は、ＭＰＵ２０１と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよい。
経路情報記憶部８０５と送信量記憶部８１３は、ＤＲＡＭ２０３により実現されてもよいし、フラッシュメモリ２０４により実現されてもよい。
また、ボトルネック判定部８０３もＭＰＵ２０１によって実現することができる。ボトルネック通知部８０４は、ＭＰＵ２０１と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５により実現されてもよいが、ＭＰＵ２０１と８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６により実現されてもよい。
そして、ハローパケット処理部８１４もＭＰＵ２０１によって実現することができる。なお、ハローパケット処理部８１４内の存在通知部８１６は、ＭＰＵ２０１だけでなくさらにタイマＩＣ２０２と８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５を用いることで、実現することができる。
以上とは逆に、通信装置８００が有線ネットワークで使われる装置の場合、通信装置８００は、例えば図３の通信装置３００により実現されてもよい。例えば、物理ポート３０１ａ〜３０１ｄのいずれかがパケットを受信すると、パケットは、対応するＰＨＹチップ（つまりＰＨＹチップ３０２ａ〜３０２ｄのいずれか）を介して、バッファ部８０７としての、メモリ３０５またはメモリ３０７に出力されてもよい。
タイプ判定部８０６は、ＦＰＧＡ３０３により実現されてもよいし、ＭＰＵ３０６により実現されてもよい。例えば、ＦＰＧＡ３０３がタイプを判定し、受信されたパケットがデータパケットの場合のみパケットをＭＰＵ３０６が処理し、受信されたパケットが制御パケットの場合は、パケットをＦＰＧＡ３０３が処理してもよい。
また、ＭＰＵ３０６は、データパケット処理部８０８として各種の処理を行ってもよい。データパケット処理部８０８のうち上位層処理部８０９を実現するために、さらにセンサ３０８が使われてもよい。また、データパケット処理部８０８がデータパケットを送信する機能は、ＦＰＧＡ３０３とＰＨＹチップ３０２ａ〜３０２ｄと物理ポート３０１ａ〜３０１ｄにより実現されてもよい。
経路情報記憶部８０５はメモリ３０５により実現されてもよい。また、送信量記憶部８１３はメモリ３０７により実現されてもよい。
そして、ボトルネック判定部８０３もＭＰＵ３０６により実現することができる。ボトルネック通知部８０４は、ＭＰＵ３０６と、ＦＰＧＡ３０３と、ＰＨＹチップ３０２ａ〜３０２ｄと、物理ポート３０１ａ〜３０１ｄにより実現されてもよい。
また、ハローパケット処理部８１４もＦＰＧＡ３０３によって実現することができる。なお、存在通知部８１６を実現するために、ＦＰＧＡ３０３内のタイマ３０４が使われてもよい。また、存在通知部８１６は、ＦＰＧＡ３０３だけでなく、ＰＨＹチップ３０２ａ〜３０２ｄと物理ポート３０１ａ〜３０１ｄを用いることによって、実現することができる。
さて、図１８は、第４実施形態のリンクテーブルの例を示す図である。図１８には、リンクテーブル８１１の具体例が４つ示されている。図１８に示すように、リンクテーブル８１１内の各エントリは、「リンク名」、「受信トラヒック」および「ハローパケット受信時刻」というフィールドを含む。つまり、リンクテーブル８１１の形式は、第３実施形態のリンクテーブル６１１のトラヒック認識時刻を省略した形式である。
第３実施形態とは異なり、第４実施形態では、ハローパケットに送信トラヒックの値が埋め込まれているので、ハローパケット受信時刻とトラヒック認識時刻が等しい。そのため、第４実施形態のリンクテーブル８１１は、ハローパケット受信時刻とトラヒック認識時刻を別々に記憶する必要がない。したがって、リンクテーブル８１１には、「トラヒック認識時刻」というフィールドはない。
さて、以上説明した３つのフィールドを含むリンクテーブル８１１の具体例として、図１８には、次の（Ｅ１）〜（Ｅ４）の４つの例が示されている。
（Ｅ１）ハローパケットＨＤ１をノードＥが受信した直後の、ノードＥのリンクテーブル８１１Ｅ−１。
（Ｅ２）ハローパケットＨＢ１をノードＥが受信した直後の、ノードＥのリンクテーブル８１１Ｅ−２。
（Ｅ３）ハローパケットＨＣ１をノードＥが受信した直後の、ノードＥのリンクテーブル８１１Ｅ−３。
（Ｅ４）ハローパケットＨＦ１をノードＥが受信した直後の、ノードＥのリンクテーブル８１１Ｅ−４。
以下、図１６も参照しながら、これら４つのリンクテーブル８１１Ｅ−１〜８１１Ｅ−４の内容を説明する。
なお、図１６に関しては、上記のとおり、経路が安定するまでに送信されるハローパケットには「０」という送信トラヒックが設定されている、と仮定した。実際には、経路が安定する前に送信されたハローパケットを通信装置８００が受信すると、受信を契機としてリンクテーブル８１１にエントリが追加されることがある。しかし、図１８では説明の便宜上、経路が安定する前のハローパケットの受信を契機として追加されたエントリの図示は、省略されている。
さて、図１６に示すように、ノードＥは、ノードＤから、選択ＬＤとしてノードＥが設定されたハローパケットＨＤ１を受信する。すると、ノードＥは、ハローパケットＨＤ１のＬＳであるノードＤがリンク名として指定されたリンクテーブル８１１のエントリにおいて、ハローパケットＨＤ１の送信トラヒックの「２」という値を、受信トラヒックフィールドに設定する。また、ノードＥは、当該エントリにおいて、ハローパケットＨＤ１を受信した時刻ＴＤＥ１を、ハローパケット受信時刻フィールドに設定する。
その後、ノードＥは、図１６に示すように、選択ＬＤとしてノードＥが設定されたハローパケットＨＢ１を受信する。すると、ノードＥは、ハローパケットＨＢ１のＬＳであるノードＢがリンク名として指定されたリンクテーブル８１１のエントリにおいて、ハローパケットＨＢ１の送信トラヒックの「１」という値を、受信トラヒックフィールドに設定する。また、ノードＥは、当該エントリにおいて、ハローパケットＨＢ１を受信した時刻ＴＢＥ２を、ハローパケット受信時刻フィールドに設定する。
その後、ノードＥは、図１６に示すように、選択ＬＤとしてノードＥが設定されたハローパケットＨＣ１を受信する。すると、ノードＥは、ハローパケットＨＣ１のＬＳであるノードＣがリンク名として指定されたリンクテーブル８１１のエントリにおいて、ハローパケットＨＣ１の送信トラヒックの「１」という値を、受信トラヒックフィールドに設定する。また、ノードＥは、当該エントリにおいて、ハローパケットＨＣ１を受信した時刻ＴＣＥ３を、ハローパケット受信時刻フィールドに設定する。
その後、ノードＥは、図１６に示すように、選択ＬＤとしてノードＥではなくノードＨが設定されたハローパケットＨＦ１を受信する。この場合、ノードＥは、ハローパケットＨＦ１の送信トラヒックの値を無視する。つまり、ノードＥは、ハローパケットＨＦ１のＬＳであるノードＦがリンク名として指定されたリンクテーブル８１１のエントリにおける受信トラヒックフィールドの値を「０」に設定する。また、ノードＥは、当該エントリにおいて、ハローパケットＨＦ１を受信した時刻ＴＦＥ４を、ハローパケット受信時刻フィールドに設定する。
以上のようにして、図１８に示したように、ノードＥのリンクテーブル８１１は、ハローパケットの受信のたびに書き換えられてゆく。
続いて、図１９を参照して、第４実施形態で使われるパケットの例について説明する。第４実施形態でも、パケット７００の一般形とＡＣＫパケット７３０の形式は、図１０の第３実施形態と同様である。
しかし、第４実施形態のデータパケット７４０は、第３実施形態のデータパケット７１０とは異なり、送信トラヒックフィールドを含まない。データパケット７４１はデータパケット７４０の具体例である。
例えば、データパケット７４１のＬＤとＬＳは、それぞれ、ノードＥとＤを示す。また、データパケット７４１において、ＩＤは「３４５６」という値であり、タイプとしてはデータパケットを示す「Ｄａｔａ」が設定されている。そして、データパケット７４１のＧＤとＧＳは、それぞれ、ゲートウェイＧＷ１とノードＡを示す。また、データパケット７４１のペイロードには任意のデータが格納されていてよく、図１９の例ではペイロードの長さが２５０なので、長さフィールドには「２５０」という値が設定される。
また、第４実施形態のハローパケット７５０は、第３実施形態のハローパケット７２０とは異なり、「選択ＬＤ」と「送信トラヒック」という２つのフィールドをペイロードとして有する。
なお、送信トラヒックフィールドを含む点において第４実施形態のハローパケット７５０と第３実施形態のデータパケット７１０は共通するが、選択ＬＤフィールドを含むのはハローパケット７５０のみである。
第３実施形態のデータパケット７１０においては、アドホックヘッダ７０１内のＬＤフィールド自体が、データパケット７１０が送信されるときのＬＤ（つまり選択ＬＤ）を示す。よって、データパケット７１０においては、選択ＬＤを示すためのさらに別のフィールドは不要である。したがって、データパケット７１０は選択ＬＤフィールドを含まない。
他方、ハローパケット７５０のアドホックヘッダ７０１内のＬＤフィールドは、データパケット７４０が送信されるときのＬＤを示すものではない。したがって、実際にデータパケットが送信される経路に沿っての送信トラヒックの積算を可能とするために、ハローパケット７５０は、ハローパケット７５０のアドホックヘッダ７０１内のＬＤフィールドとは別に、選択ＬＤフィールドを含む。そして、ハローパケット７５０は、選択ＬＤフィールドによって、データパケット７４０が送信されるときのＬＤを示す。
具体的には、例えば、図１６のハローパケットＨＥ２では、図１９に示すとおり、ＬＤには、１ボップの範囲内でのブロードキャストを示す特殊な値が指定され、ＬＳにはノードＥが指定される。また、ハローパケットＨＥ２において、ＩＤには「８７６５」という値が設定され、タイプにはハローパケットを示す「Ｈｅｌｌｏ」という値が設定される。
そして、ハローパケットＨＥ２において、選択ＬＤとしては、ハローパケットＨＥ２を送信するノードＥがゲートウェイＧＷ１宛のデータパケット７４０を送信するときにＬＤとして選択するノードＦが指定されている。また、図１６に示すように、ハローパケットＨＥ２の送信トラヒックの値は「５」である。
なお、実施形態によっては、ＧＤとして指定され得るノードがネットワーク内に複数存在していてもよく、その場合、ハローパケット７６０のような形式のハローパケットが使われてもよい。ハローパケット７６０に関しては、第１１実施形態とともに後述する。
さて、以下では、いくつかのフローチャートを参照して、図１７の通信装置８００の動作を説明する。以下に説明するように動作する通信装置８００を図４のノードＡ〜Ｉとして用いることにより、図１６を参照して説明したような、ボトルネックの検出または予測が可能となる。なお、ゲートウェイＧＷ１は、少なくとも存在通知部８１６を有するが、もちろん、存在通知部８１６以外の通信装置８００内の構成要素をさらに有していてもよい。
さて、通信装置８００は、第３実施形態の通信装置６００と同様に、図１１の処理を行う。ただし、いくつかの点で、第３実施形態と第４実施形態では図１１の処理の詳細が異なる。第３実施形態との主な違いのみを簡単に説明すれば、以下のとおりである。
ステップＳ１０２において、タイプ判定部８０６は、「受信されたパケット７００はハローパケット７５０である」と判定した場合、ハローパケット７５０をハローパケット処理部８１４内の通知受信部８０１とリンク管理部８１５に出力する。また、タイプ判定部８０６は、「受信されたパケット７００はデータパケット７４０である」と判定した場合、データパケット７４０の受信をルーティング制御部８１０に通知する。
また、ステップＳ１０３のハローパケット受信処理は、第４実施形態では、図２０に示す処理である。
そして、ステップＳ１０５のデータパケット受信処理は、第４実施形態では、具体的には、図１２の処理の一部を省略した処理である。すなわち、第４実施形態では、ステップＳ２０４とＳ２０５とＳ２１１が省略される。また、第４実施形態では、ステップＳ２１２において、送信トラヒックを含まないデータパケット７４０をデータパケット処理部８０８が送信する。
さて、図２０は、第４実施形態において図１１のステップＳ１０３で行われるハローパケット受信処理のフローチャートである。
ステップＳ６０１でリンク管理部８１５は、受信されたハローパケット７５０のＬＳと同じ値をリンク名として持つエントリをリンクテーブル８１１において検索する。
そして、ステップＳ６０２でリンク管理部８１５は、検索の結果としてエントリが見つかったか否かを判定する。
エントリが見つかった場合とは、既知の隣接ノードからのハローパケット７５０を通信装置８００が受信した場合である。この場合、処理はステップＳ６０３に移行する。
逆に、エントリが見つからなかった場合とは、未知の新たな隣接ノードからのハローパケット７５０を通信装置８００が受信した場合である。この場合、処理はステップＳ６０４に移行する。
そして、ステップＳ６０３でリンク管理部８１５は、見つかったエントリにおけるハローパケット受信時刻として、現在時刻を設定する。また、リンク管理部８１５は、見つかったエントリを、「注目エントリ」として通知受信部８０１に通知する。そして、処理はステップＳ６０８に移行する。
他方、ステップＳ６０４でリンク管理部８１５は、リンクテーブル８１１に新規エントリを追加する。
そして、次のステップＳ６０５でリンク管理部８１５は、新規エントリにおけるリンク名として、受信されたハローパケット７５０のＬＳの値を設定する。
さらに、次のステップＳ６０６でリンク管理部８１５は、新規エントリにおける受信トラヒックの値を、「０」に初期化する。
また、次のステップＳ６０７でリンク管理部８１５は、新規エントリにおけるハローパケット受信時刻として、現在時刻を設定する。さらに、リンク管理部８１５は、ステップＳ８０４で追加した新規エントリを、「注目エントリ」として通知受信部８０１に通知する。
なお、ステップＳ６０５〜Ｓ６０７の実行順序は適宜入れ替えられてもよい。ステップＳ６０５〜Ｓ６０７の実行後、処理はステップＳ６０８に移行する。
さて、ステップＳ６０８では、通知受信部８０１が、受信されたハローパケット７５０に設定されている選択ＬＤの値が自ノードＩＤ（つまり通信装置８００自身のノードＩＤ）と等しいか否かを判定する。そして、選択ＬＤの値が通信装置８００自身のノードＩＤと等しければ、処理はステップＳ６０９に移行する。他方、選択ＬＤの値が通信装置８００自身のノードＩＤと異なれば、処理はステップＳ６１２に移行する。
ステップＳ６０９で通知受信部８０１は、受信されたハローパケット７５０から、送信トラヒックの値を抽出する。例えば、図１９のハローパケットＨＥ２を受信したノードＦの通知受信部８０１は、「５」という値を抽出する。
そして、次のステップＳ６１０で通知受信部８０１は、ステップＳ６０９で抽出した値を、リンク管理部８１５から通知された注目エントリにおける受信トラヒックとして設定する。
続いて、ステップＳ６１１では、図１４と同様のボトルネック検出処理が行われる。なお、第４実施形態では、送信量通知部８０２とボトルネック判定部８０３とボトルネック通知部８０４がボトルネック検出処理を行う。ボトルネック検出処理が終了すると、ハローパケット受信処理も終了する。
他方、ステップＳ６１２では、通知受信部８０１が、注目エントリにおける受信トラヒックの値を「０」に初期化する。例えば、ノードの追加または削除などによりネットワークトポロジが変化した場合などに、変化に追従して経路の一部が変化することもある。よって、経路が変化した場合に、変化に追従した適切なトラヒックの計算を可能とするために、通知受信部８０１は、ステップＳ６１２において注目エントリにおける受信トラヒックの値を「０」に初期化する。初期化が終了すると、ハローパケット受信処理も終了する。
ところで、通信装置８００は、上記のようにパケット７００の受信を契機とする処理以外のいくつかの処理も行う。
例えば、通信装置８００のデータパケット処理部８０８は、定期的または不定期に、ＧＳとしてデータパケット７４０を送信する。具体的には、データパケット処理部８０８は図１５と類似の処理を行う。ただし、第４実施形態では、図１５のステップＳ５０８は省略され、ステップＳ５１３では送信トラヒックを含まないデータパケット７４０が送信される。
また、通信装置８００の存在通知部８１６は、図２１の処理を行う。図２１は、第４実施形態におけるハローパケット送信処理のフローチャートである。
ステップＳ７０１で存在通知部８１６は、現在時刻がハローパケット７５０の送信予定時刻になるまで待機する。そして、ハローパケット７５０の送信予定時刻になると、処理はステップＳ７０２に移行する。
例えば、ハローパケット７５０は定期的に送信されることが好ましい。よって、例えばタイマＩＣ２０２またはタイマ３０４が、所定の間隔で定期的に割り込み信号を出力してもよい。割り込み信号が出力されると、存在通知部８１６は「現在時刻がハローパケット７５０の送信予定時刻である」と認識する。
そして、ステップＳ７０２で送信量通知部８０２は、送信するハローパケット７５０に設定する送信トラヒックの値を計算する。具体的には、送信量通知部８０２は、図２０のステップＳ６１１のボトルネック検出処理（詳細は図１４）におけるステップＳ４０１〜Ｓ４０５と同様にして、送信トラヒックの値を計算する。
また、ステップＳ７０３で送信量通知部８０２は、ルーティングテーブル８１２を参照する。第４実施形態では、ネットワーク４００内でＧＤとして指定され得るのは、ゲートウェイＧＷ１のみなので、送信量通知部８０２は、ルーティングテーブル８１２において、ＧＤの値がゲートウェイＧＷ１を示すエントリを検索する。そして、送信量通知部８０２は、検索の結果見つかったエントリにおいて、最も評価の高い（つまり最も評価値の小さい）ＬＤの候補を認識する。
例えば、ルーティングテーブル８１２は、図９のルーティングテーブル６１２Ｄと同様の形式でもよい。その場合、ＧＤとしてのゲートウェイＧＷ１に対応して、最大で３つのノードが、選択可能なＬＤの候補としてルーティングテーブル８１２に登録されている。
そこで、送信量通知部８０２は、選択可能なＬＤの候補の中から、最も評価の高い候補を認識する。なぜなら、ＧＤとしてゲートウェイＧＷ１が指定されたデータパケット７４０の送信において、ルーティング制御部８１０が最優先でＬＤとして選択するのは、最も評価の高い候補だからである。
続いて、ステップＳ７０４において送信量通知部８０２は、ステップＳ７０２で計算した送信トラヒックと、ステップＳ７０３で認識したＬＤ（つまり選択ＬＤ）とを設定したハローパケット７５０を生成する。
なお、送信量通知部８０２は、ハローパケット７５０のアドホックヘッダ７０１において、ＬＤにはブロードキャストを示す特定の値を設定し、ＬＳには通信装置８００自身のノードＩＤを設定する。また、送信量通知部８０２は、新たなＩＤを生成してハローパケット７５０のＩＤとして設定し、タイプとして「Ｈｅｌｌｏ」を設定する。
そして、ステップＳ７０５で送信量通知部８０２は、ステップＳ７０４で生成したハローパケット７５０を送信する。すると、処理はステップＳ７０１に戻る。
以上説明した第４実施形態によれば、定期的に送信されるハローパケット７５０を利用して、ネットワーク４００内の各ノードＡ〜Ｉが、自律的にボトルネックの検出または予測を行うことができる。つまり、ボトルネックの予測または検出のために専用の制御パケットを導入する必要がないので、ボトルネックの予測または検出のためにネットワークに生じる負荷は小さい。
続いて、図１４とは異なる基準にしたがってボトルネックの予測または検出が行われる第５実施形態について説明する。第５実施形態では、図７の通信装置６００が、送信量通知部６０２とボトルネック判定部６０３の代わりに図５のボトルネック判定部５０２を含み、ボトルネック通知部６０４の代わりに受信ボトルネック通知部５０３を含む。そして、第５実施形態では、送信トラヒックの量ではなく受信トラヒックの量に基づいて、ボトルネックの予測または検出が行われる。
図２２は、第５実施形態におけるボトルネック検出処理のフローチャートである。なお、ボトルネック検出処理以外の点では、第５実施形態は第３実施形態と同様なので、詳しい説明は割愛する。
ステップＳ８０１でボトルネック判定部５０２は、受信トラヒックの量を示す変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃを「０」に初期化する。
そして、次のステップＳ８０２でボトルネック判定部５０２は、リンクテーブル６１１の１つ目のエントリに注目する。続いて、処理はステップ８０３に移行する。
ステップＳ８０３でボトルネック判定部５０２は、変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃの値と、リンクテーブル６１１において注目しているエントリの受信トラヒックの値との和を計算し、計算結果を変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃに代入する。
そして、次のステップＳ８０４でボトルネック判定部５０２は、リンクテーブル６１１のすべてのエントリに注目し終えたか否かを判断する。ボトルネック判定部５０２がまだ注目していないエントリが残っていれば、処理はステップＳ８０５に移行する。逆に、ボトルネック判定部５０２がすべてのエントリに既に注目済みならば、処理はステップＳ８０６に移行する。
ステップＳ８０５でボトルネック判定部５０２は、リンクテーブル６１１の次のエントリに注目する。そして、処理はステップＳ８０３に戻る。
他方、ステップＳ８０６でボトルネック判定部５０２は、変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃの値を、所定の閾値Ｔｉｎと比較する。
変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃの値が閾値Ｔｉｎよりも大きいとき、ボトルネック判定部５０２は「通信装置６００はボトルネックである」と判定し、判定結果を受信ボトルネック通知部５０３に通知する。そして、処理はステップＳ８０７に移行する。
逆に、変数ＩｎｂｏｕｎｄＴｒａｆｆｉｃの値が閾値Ｔｉｎ以下のとき、ボトルネック判定部５０２は「通信装置６００はボトルネックではない」と判定する。そして、ボトルネック検出処理は終了する。
ステップＳ８０７では、ボトルネック判定部５０２から通知を受けた受信ボトルネック通知部５０３が、警報（すなわちボトルネック通知）を送信する。ステップＳ８０７の詳細は、図１４のステップＳ４０７と同様なので、説明を割愛する。
続いて、図１４とも図２２とも異なる基準にしたがってボトルネックの予測または検出が行われる第６実施形態について、図２３〜２５を参照して、第３実施形態との違いを主体に説明する。具体的には、第６実施形態では、第１実施形態に関して説明した「重み付け送信経路数」に基づく判定が行われる。
なお、重み付け送信経路数の計算において用いられる重みは、リンクの品質を反映する値でさえあれば、どのような重みでもよい。また、リンクの品質を測る基準は実施形態に応じて様々である。
一例として、第６実施形態では、ハローパケット７２０の受信間隔の揺れが、リンクの品質を測る基準として使われる。そのため、第６実施形態では、リンクテーブルの形式が第３実施形態とは異なり、図１１のステップＳ１０３で行われるハローパケット受信処理の詳細が第３実施形態とは異なる。
さて、図２３は、第６実施形態におけるリンクテーブルの例を示す図である。具体的には、図２３のリンクテーブル６１１Ｈは、図６のタイミングチャートにおいてデータパケットＤ６Ｆを受信した時点よりも後の、ノードＨにおけるリンクテーブル６１１である。
第３実施形態の図８のリンクテーブル６１１Ｄ−１および６１１Ｅ−１〜６１１Ｅ−３と比べると、図２３のリンクテーブル６１１Ｈには、「品質」および「最新受信時刻のインデックス」という新たなフィールドが追加されている。また、リンクテーブル６１１Ｈには、ハローパケット受信時刻のフィールドが、１つではなく複数（具体的にはＮ個）ある。
品質フィールドは、リンク名で識別される隣接ノードとの間のリンクの品質を示す。そして、品質の値は、Ｎ個のハローパケット受信時刻から求められる（Ｎ−１）個の受信間隔の揺れに基づいて計算される。
また、Ｎ個のハローパケット受信時刻は、０から（Ｎ−１）までのインデックスと対応づけられて、リングバッファと同様の形式で記憶される。最新受信時刻のインデックスは、リングバッファにおけるポインタの役割を果たす。
例えば、Ｎ＝２０であり最新受信時刻のインデックスの値が「２」であるとする。すると、記憶されている２０個のハローパケット受信時刻のうちで最新の時刻は、「２」というインデックスと対応づけられた時刻である。そして、２番目に新しい時刻は「１」というインデックスと対応づけられた時刻であり、３番目に新しい時刻は「０」というインデックスと対応づけられた時刻であり、４番目に新しい時刻は「１９」というインデックスと対応づけられた時刻である。また、最も古い時刻は、「３」というインデックスと対応づけられた時刻である。
なお、以上説明したような形式のリンクテーブル６１１Ｈにおけるエントリとして、図２３は具体的には次の２つのエントリが例示されている。
１つ目のエントリでは、リンク名がノードＦを示し、受信トラヒックの値は、データパケットＤ６ＦやＤ８Ｆに送信トラヒックとして設定されている「６」という値である。また、品質の値は「１０」である。そして、各インデックスｊ（０≦ｊ≦Ｎ−１）には、ハローパケット受信時刻ＰＦＨ，ｊが対応づけられており、最新受信時刻のインデックスの値は「２」である。また、トラヒック認識時刻はＱＦＨである。
２つ目のエントリでは、リンク名がノードＧを示す。また、ノードＨは、ノードＧからＬＤとして指定されないので、受信トラヒックの値は「０」である。そして、品質の値は「２０」である。また、各インデックスｊ（０≦ｊ≦Ｎ−１）には、ハローパケット受信時刻ＰＧＨ，ｊが対応づけられており、最新受信時刻のインデックスの値は「４」である。さらに、トラヒック認識時刻はＱＧＨである。
さて、図２４は、第６実施形態におけるハローパケット受信処理のフローチャートである。ハローパケット受信処理は、図１１のステップＳ１０３で行われる。以下では説明の便宜上、第６実施形態における通信装置６００の例として、図２３のリンクテーブル６１１Ｈを持つノードＨに注目して、図２４の処理について説明する。
ステップＳ９０１でリンク管理部６１５は、受信されたハローパケット７２０のＬＳと同じ値をリンク名として持つエントリをリンクテーブル６１１Ｈにおいて検索する。
そして、ステップＳ９０２でリンク管理部６１５は、検索の結果としてエントリが見つかったか否かを判定する。
エントリが見つかった場合とは、既知の隣接ノードからのハローパケット７２０を通信装置６００（例えばノードＨ）が受信した場合である。この場合、処理はステップＳ９０３に移行する。
逆に、エントリが見つからなかった場合とは、未知の新たな隣接ノードからのハローパケット７２０を通信装置６００が受信した場合である。この場合、処理はステップＳ９０５に移行する。
そして、ステップＳ９０３でリンク管理部６１５は、見つかったエントリにおける最新受信時刻のインデックスの値を変数ｉｄｘに代入する。
さらに次のステップＳ９０４でリンク管理部６１５は、変数ｉｄｘの値に１を足した値をＮで割った剰余を計算し、計算結果を変数ｉｄｘに代入する。そして、処理はステップＳ９０９に移行する。
例えば、受信されたハローパケット７２０のＬＳがノードＦを示す場合、図２３によれば、リンク名がノードＦを示す１番目のエントリにおける最新受信時刻のインデックスの値は２である。したがって、ステップＳ９０４では、３（＝２＋１）をＮで割った剰余が計算される。
他方、ステップＳ９０５でリンク管理部６１５は、リンクテーブル６１１Ｈに新規エントリを追加する。また、初期状態における新規エントリの各フィールドの値は、ヌル（null）などの無効な値である。
続くステップＳ９０６でリンク管理部６１５は、新規エントリにおけるリンク名として、受信されたハローパケット７２０のＬＳの値を設定する。
さらに、次のステップＳ９０７でリンク管理部６１５は、新規エントリにおける受信トラヒックの値を、「０」に初期化する。
また、次のステップＳ９０８でリンク管理部６１５は変数ｉｄｘに初期値として「０」を代入する。そして、処理はステップＳ９０９に移行する。
さて、以下では説明の便宜上、ステップＳ９０１の検索の結果として見つかったか、またはステップＳ９０５で追加されたエントリのことを、「注目エントリ」という。ステップＳ９０９でリンク管理部６１５は、注目エントリにおいて、最新受信時刻のインデックスとして、変数ｉｄｘの値を設定する。また、リンク管理部６１５は注目エントリにおいて、ｉｄｘ番目のハローパケット受信時刻のフィールドに、現在時刻を設定する。
そして、次のステップＳ９１０でリンク管理部６１５は、注目エントリにおけるハローパケット受信時刻から、品質を計算する。
例えば、説明の便宜上、Ｎ＝２０とし、受信されたハローパケット７２０のＬＳがノードＦを示すものとして、ステップＳ９１０での計算について説明する。ステップＳ９１０における計算は、具体的には、以下の３つの場合があり得る。
第１の場合は、最新受信時刻のインデックスの値が０であり、かつ、１から（Ｎ−１）までの各インデックスに対応づけられたハローパケット受信時刻がまだ無効な値のままという場合である。換言すれば、第１の場合とは、ノードＨがまだノードＦから１回しかハローパケット７２０を受信していない場合のことであり、すなわち、ステップＳ９０５で新規エントリが追加された場合である。
よって、第１場合では、ハローパケット７２０の受信間隔は定義されない。したがって、リンク管理部６１５は、予め決められた定数値を、ステップＳ９１０で品質の値として得る。定数値は、例えば、予備実験の結果などに基づいて平均的に期待される品質の値でもよい。
第２の場合は、０から（Ｎ−１）までのインデックスに対応づけられたハローパケット受信時刻の中に、無効な値がない場合である。換言すれば、第２の場合とは、ノードＨが既にノードＦからＮ個以上のハローパケット７２０を受信した場合のことである。第２の場合、注目エントリに記録されたＮ個のハローパケット受信時刻から、（Ｎ−１）個の受信間隔が定義される。
説明の便宜上、Ｎ個のハローパケット受信時刻のうち最も古い時刻を「ｔ０」と表記し、最も新しい時刻を「ｔＮ−１」と表記することにする。例えば、最新受信時刻のインデックスが２の場合、「３」というインデックスに対応づけられたハローパケット受信時刻が時刻ｔ０であり、「２」というインデックスに対応づけられたハローパケット受信時刻が時刻ｔＮ−１である。
すると、（Ｎ−１）個の受信間隔の平均μは式（１）のとおりであり、（Ｎ−１）個の受信間隔の標準偏差σは式（２）のとおりである。
Figure 0005435147
Figure 0005435147
リンク管理部６１５は、式（２）の標準偏差σ自体を、品質の値として得てもよい。あるいは、リンク管理部６１５は、標準偏差σの関数として表される値を、品質の値として得てもよい。つまり、第６実施形態では、品質の値が小さいほど、品質は良い。
例えば、後述の図２５のステップＳ１００５において、品質の値は除数として利用される。そこで、品質の値がゼロになるのを防ぐため、リンク管理部６１５は、所定の小さな定数値αを標準偏差σに足した結果（σ＋α）を、品質の値としてステップＳ９１０で得てもよい。あるいは、リンク管理部６１５は、所定の定数値αとβを用いて計算した値（βσ＋α）など、標準偏差σの関数として表される適宜の値を、品質の値として得てもよい。
また、実施形態によっては、存在通知部６１６は、ハローパケット７２０のようなペイロードのない形式ではなく、ペイロードを持つハローパケットを送信してもよい。具体的には、存在通知部６１６は、リンク管理部６１５により計算された上記の標準偏差σの値（または品質の値）を、リンク名と対応づけてハローパケットのペイロードに格納してもよい。
そして、リンク管理部６１５は、受信されたハローパケットのペイロードにおいて通信装置６００自身のノードＩＤと対応づけられている値を、上記のようにしてリンク管理部６１５自身が計算した標準偏差σとともに用いて、品質の値を計算してもよい。すると、あるリンクを介して互いに隣接する２つの通信装置６００が、同じリンクについて、双方向の品質を考慮に入れた同じ値を得ることも可能となる。
さて、ステップＳ９１０の計算に関する第３の場合とは、０から（Ｎ−１）までのインデックスに対応づけられたハローパケット受信時刻の中に無効な値があり、かつ、有効な値が２つ以上ある場合である。換言すれば、第３の場合とは、ノードＨが既にノードＦから受信したハローパケット７２０の個数が、２以上Ｎ未満の場合である。
第３の場合、少なくとも１つ以上の受信間隔が定義される。よって、リンク管理部６１５は、定義可能なすべての受信間隔を用いて、第２の場合と類似の計算により、ステップＳ９１０で品質の値を計算する。
最後に、ステップＳ９１１で通知受信部６０１は、注目エントリの品質として、ステップＳ９１０で計算した値を設定する。
さて、図２５は、第６実施形態におけるボトルネック検出処理のフローチャートである。ボトルネック検出処理は、図１１のステップＳ１０５に当たる図１２のデータパケット受信処理の中のステップＳ２０５で行われる。
ステップＳ１００１で送信量通知部６０２は、重み付き送信経路数（換言すれば、通信装置６００の潜在的な送信容量）を示す変数Ｐｏｔｅｎｔｉａｌの値を「０」に初期化する。
そして、次のステップＳ１００２で送信量通知部６０２は、ルーティングテーブル６１２において、ＧＤとしてゲートウェイＧＷ１が指定されたエントリに注目する。
さらに、次のステップＳ１００３で送信量通知部６０２は、注目エントリ内の１つ目のＬＤの候補に注目する。そして、処理はステップＳ１００４に移行する。
ステップＳ１００４で送信量通知部６０２は、注目したＬＤの候補と等しいリンク名を持つ、リンクテーブル６１１Ｈ内のエントリから、品質の値を読み出す。
そして、ステップＳ１００５で送信量通知部６０２は、ステップＳ１００４で読み出した品質の値の逆数を変数Ｐｏｔｅｎｔｉａｌの値に足し、得られた和を新たに変数Ｐｏｔｅｎｔｉａｌに代入する。
さらに、次のステップＳ１００６で送信量通知部６０２は、ルーティングテーブル６１２の注目エントリ内のすべてのＬＤの候補に注目し終えたか否かを判断する。
例えば、ルーティングテーブル６１２が、図９のルーティングテーブル６１２Ｄのように最大で３つまでＬＤの候補を登録可能な形式とする。この場合、「注目エントリ内のすべてのＬＤの候補」とは、第１〜第３候補のうち、ノードＩＤとして有効な値が指定されているすべての候補のことである。
そして、送信量通知部６０２がまだ注目していないＬＤの候補がルーティングテーブル６１２の注目エントリ内に残っている場合、処理はステップＳ１００７に移行する。逆に、送信量通知部６０２がルーティングテーブル６１２の注目エントリ内のすべてのＬＤの候補に注目し終えた場合、処理はステップＳ１００８に移行する。処理がステップＳ１００８に移行する時点における変数Ｐｏｔｅｎｔｉａｌの値が、重み付き送信経路数を示す。
ステップＳ１００７で送信量通知部６０２は、ルーティングテーブル６１２の注目エントリ内の次のＬＤの候補に注目する。そして、処理はステップＳ１００４に戻る。
他方、ステップＳ１００８で送信量通知部６０２は、送信トラヒックの量を示す変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃに、送信量記憶部６１３に記憶されている値を代入する。
また、次のステップＳ１００９で送信量通知部６０２は、リンクテーブル６１１Ｈの１つ目のエントリに注目する。続いて、処理はステップＳ１０１０に移行する。
ステップＳ１０１０で送信量通知部６０２は、変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値と、リンクテーブル６１１Ｈにおいて注目しているエントリの受信トラヒックの値との和を計算し、計算結果を変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃに代入する。
そして、次のステップＳ１０１１で送信量通知部６０２は、リンクテーブル６１１Ｈのすべてのエントリに注目し終えたか否かを判断する。送信量通知部６０２がまだ注目していないエントリが残っていれば、処理はステップＳ１０１２に移行する。逆に、送信量通知部６０２がすべてのエントリに既に注目済みならば、処理はステップＳ１０１３に移行する。
ステップＳ１０１２で送信量通知部６０２は、リンクテーブル６１１Ｈの次のエントリに注目する。そして、処理はステップＳ１０１０に戻る。
他方、ステップＳ１０１３で送信量通知部６０２は、変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値を変数Ｐｏｔｅｎｔｉａｌの値で割り、得られた商をボトルネック判定部６０３に通知する。すると、ボトルネック判定部６０３は、通知された値を、所定の閾値Ｔｐｏｔと比較する。
上記の商の値が閾値Ｔｐｏｔよりも大きいとき、ボトルネック判定部６０３は「通信装置６００はボトルネックである」と判定し、判定結果をボトルネック通知部６０４に通知する。そして、処理はステップＳ１０１４に移行する。
逆に、上記の商の値が閾値Ｔｐｏｔ以下のとき、ボトルネック判定部６０３は「通信装置６００はボトルネックではない」と判定する。そして、ボトルネック検出処理は終了する。
ステップＳ１０１４では、ボトルネック判定部６０３から通知を受けたボトルネック通知部６０４が、警報（すなわちボトルネック通知）を送信する。ステップＳ１０１４における送信の詳細は実施形態に応じて様々でよい。ステップＳ１０１４の詳細は図１４のステップＳ４０７と同様なので、説明を割愛する。
以上説明した第６実施形態によれば、ボトルネックの予測または検出が、潜在的に送信可能な容量と送信トラヒックとに基づいて行われる。よって、第６実施形態では、潜在的に生じ得るネットワークトポロジの変化に応じて通信装置６００がボトルネックになってしまうリスクの評価が可能である。以下に、第６実施形態における具体的な計算の例を説明する。
例えば、図４のネットワーク４００において、ノードＡ〜Ｉの各々が所定期間に生成してゲートウェイＧＷ１宛に送信するデータの量の期待値を「１」とする。すると、図４のように経路が構築されている場合、ノードＡ〜Ｉの各々で変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値として計算される送信トラヒックは、以下のとおりである。
ノードＡの送信トラヒックは「１」である。また、ノードＢの送信トラヒックは「１」である。ノードＣの送信トラヒックも「１」である。
そして、ノードＡから送信されるデータパケット７１０を中継するノードＤの送信トラヒックは「２」である。また、ノードＢ、ＣおよびＤから送信されるデータパケット７１０を中継するノードＥの送信トラヒックは「５」である。
そして、ノードＥから送信されるデータパケット７１０を中継するノードＦの送信トラヒックは、「６」である。他方、ノードＧの送信トラヒックは「１」である。
また、ノードＦから送信されるデータパケット７１０を中継するノードＨの送信トラヒックは、「７」である。他方、ノードＩの送信トラヒックは「１」である。
なお、以下では説明の簡単化のため、あるリンクを介して互いに隣接する２つの通信装置６００が、同じリンクについての品質の値として、同じ値を計算するものとする。そして、例えば、各リンクの品質の値が以下のとおりであるとする。
ノードＡとＢの間のリンク、およびノードＢとＣの間のリンクの品質を「４０」とする。また、ノードＡとＤの間のリンク、ノードＢとＤの間のリンク、ノードＢとＥの間のリンク、およびノードＣとＥの間のリンクの品質を「３０」とする。そして、ノードＤとＥの間のリンクの品質を「２０」とし、ノードＥとＦの間のリンクの品質を「１０」とする。
また、ノードＦとＨの間のリンク、およびノードＨとゲートウェイＧＷ１の間のリンクの品質を「１０」とする。そして、ノードＦとＧの間のリンク、ノードＦとＩの間のリンク、ノードＧとＨの間のリンク、ノードＧとゲートウェイＧＷ１の間のリンク、ノードＨとＩの間のリンク、およびノードＩとゲートウェイＧＷ１の間のリンクの品質を「２０」とする。
また、図２５における上記閾値Ｔｐｏｔ（すなわち重み付き送信経路数当たりの送信トラヒックの上限値）を「４０」とする。すると、例えば以下のようにして、ノードＥでボトルネックが検出され、他のノードではボトルネックが検出されない。
例えば、ノードＡは、ＬＤの第１候補としてノードＤを記憶するだけでなく、ＬＤの第２候補としてノードＢを記憶しているとする。すると、ノードＡにおける重み付き送信経路数は、約０．０６（＝１／３０＋１／４０）である。
したがって、ステップＳ１０１３では、「１」という送信トラヒックを重み付け送信経路数で割った約１７という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＡからはボトルネック通知は送信されない。
また、ノードＢは、ＬＤの第１候補としてノードＥを記憶するだけでなく、ＬＤの第２候補と第３候補としてそれぞれノードＣとＤを記憶しているとする。すると、ノードＢにおける重み付き送信経路数は、約０．０９（＝１／３０＋１／４０＋１／３０）である。
したがって、ステップＳ１０１３では、「１」という送信トラヒックを重み付け送信経路数で割った約１１という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＢからはボトルネック通知は送信されない。
そして、ノードＣは、ＬＤの第１候補としてノードＥを記憶するだけでなく、ＬＤの第２候補としてノードＢを記憶しているとする。すると、ノードＣにおける重み付き送信経路数は、約０．０６（＝１／３０＋１／４０）である。
したがって、ステップＳ１０１３では、「１」という送信トラヒックを重み付け送信経路数で割った約１７という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＣからはボトルネック通知は送信されない。
また、ノードＤは、ＬＤの第１候補としてノードＥを記憶するだけでなく、ＬＤの第２候補としてノードＢを記憶しているとする。すると、ノードＤにおける重み付き送信経路数は、約０．０８（＝１／２０＋１／３０）である。
したがって、ステップＳ１０１３では、「２」という送信トラヒックを重み付け送信経路数で割った２４という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＤからはボトルネック通知は送信されない。
また、ノードＥは、ＬＤの第１候補としてノードＦを記憶するが、第２候補と第３候補を記憶していないとする。すると、ノードＥにおける重み付き送信経路数は、０．１（＝１／１０）である。
したがって、ステップＳ１０１３では、「５」という送信トラヒックを重み付け送信経路数で割った５０という値が得られる。得られた値は閾値Ｔｐｏｔより大きいので、ノードＥからはボトルネック通知が送信される。
また、ノードＦは、ＬＤの第１候補としてノードＨを記憶するだけでなく、ＬＤの第２候補と第３候補としてそれぞれノードＧとＩを記憶しているとする。すると、ノードＦにおける重み付き送信経路数は、０．２（＝１／１０＋１／２０＋１／２０）である。
したがって、ステップＳ１０１３では、「６」という送信トラヒックを重み付け送信経路数で割った３０という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＦからはボトルネック通知は送信されない。
そして、ノードＧは、ＬＤの第１候補としてゲートウェイＧＷ１を記憶するだけでなく、ＬＤの第２候補としてノードＨを記憶しているとする。すると、ノードＧにおける重み付き送信経路数は、０．１（＝１／２０＋１／２０）である。
したがって、ステップＳ１０１３では、「１」という送信トラヒックを重み付け送信経路数で割った１０という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＧからはボトルネック通知は送信されない。
また、ノードＨは、ＬＤの第１候補としてゲートウェイＧＷ１を記憶するだけでなく、ＬＤの第２候補と第３候補としてそれぞれノードＧとＩを記憶しているとする。すると、ノードＨにおける重み付き送信経路数は、０．２（＝１／１０＋１／２０＋１／２０）である。
したがって、ステップＳ１０１３では、「７」という送信トラヒックを重み付け送信経路数で割った３５という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＨからはボトルネック通知は送信されない。
また、ノードＩは、ＬＤの第１候補としてゲートウェイＧＷ１を記憶するだけでなく、ＬＤの第２候補としてノードＨを記憶しているとする。すると、ノードＩにおける重み付き送信経路数は、０．１（＝１／２０＋１／２０）である。
したがって、ステップＳ１０１３では、「１」という送信トラヒックを重み付け送信経路数で割った１０という値が得られる。得られた値は閾値Ｔｐｏｔ以下なので、ノードＩからはボトルネック通知は送信されない。
さて、続いて第７実施形態について説明する。第１〜６実施形態では、ボトルネックの検出または予測には単一の条件が使われるが、複数の条件の組み合わせがボトルネックの検出または予測に使われてもよい。例えば、下記（Ｆ１）〜（Ｆ８）の条件を２つ以上任意に組み合わせた条件が利用可能である。
（Ｆ１）第２、５実施形態で使われる「単位時間あたりの受信トラヒックの量が閾値を超えている」という条件。例えば、「各ＬＳからの受信トラヒックの総和ＩｎｂｏｕｎｄＴｒａｆｆｉｃが閾値Ｔｉｎを超えている」という条件。
（Ｆ２）第１、３、４実施形態で使われる「単位時間あたりの送信トラヒックの量が閾値を超えている」という条件。例えば、「各ＬＳからの受信トラヒックの総和に、送信量記憶部６１３または８１３が記憶する値を足した値ＯｕｎｔｂｏｕｎｄＴｒａｆｆｉｃが閾値Ｔｏｕｔを超えている」という条件。
（Ｆ３）第６実施形態で使われる「単位時間あたりの送信トラヒックの量を重み付き送信経路数で割った値が閾値を超えている」という条件。つまり、「ＯｕｎｔｂｏｕｎｄＴｒａｆｆｉｃ／Ｐｏｔｅｎｔｉａｌ＞Ｔｐｏｔ」という条件。
（Ｆ４）「単位時間あたりに通信装置が受信するデータパケットの数が閾値を超えている」という条件。無線通信か有線通信かを問わず、パケット通信では、ヘッダ処理のオーバヘッドが生じる。また、無線通信では、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）による待ち時間（例えばキャリアセンスの時間やバックオフ時間など）のオーバヘッドが比較的大きい。よって、無線通信では特に、データパケットの量（換言すればデータパケットの長さ）だけでなく、データパケットの数も、負荷を計測するための有益な指標の１つである。よって、この（Ｆ４）や下記（Ｆ５）のような条件がボトルネックの検出または予測に使われてもよい。
（Ｆ５）「単位時間あたりに通信装置が送信しようとするデータパケットの数が閾値を超えている」という条件。つまり、「通信装置が実際に送信に成功したデータパケットの数と、通信装置が送信を試みたものの（コリジョンなどの何らかの原因で）送信に失敗したデータパケットの数との和が、閾値を超えている」という条件。
（Ｆ６）「各ＬＳについて、当該ＬＳからの単位時間あたりの受信トラヒックの量と、当該ＬＳとの間のリンクの品質とを基に計算した値を、すべてのＬＳについて足した総和が、閾値を超えている」という条件。例えば、「各ＬＳからの受信トラヒックの量を当該ＬＳとの間のリンクの品質の逆数で割った値を、全ＬＳについて足して得られる総和が、閾値を超えている」という条件。
（Ｆ７）「単位時間あたりの送信トラヒックの量と、ＬＤとの間のリンクの品質とを基に計算した値が、閾値を超えている」という条件。例えば、「変数ＯｕｔｂｏｕｎｄＴｒａｆｆｉｃの値を、ＬＤとの間のリンクの品質の逆数で割った値が、所定の閾値を超えている」という条件。条件（Ｆ７）は、ＬＤの複数の候補にすべて注目して変数Ｐｏｔｅｎｔｉａｌの値を計算する代わりに、最高の評価の１つのＬＤの候補だけに注目して変数Ｐｏｔｅｎｔｉａｌの値を計算するように第６実施形態を変形した場合の、条件（Ｆ３）に相当する。
（Ｆ８）「単位時間あたりに通信装置が受信するデータパケットの数から、単位時間あたりに通信装置が送信するデータパケットの数を引いて得られる値が、閾値を超えている」という条件。リンクの状態によっては、通信装置がデータパケットを受信した後、転送に成功するまでに時間がかかることがある。その結果、バッファ部６０７または８０７の使用量が、増える一方で、減っていかないことがある。すると、いずれバッファオーバフローが起きるかもしれない。つまり、この条件（Ｆ８）が成立する通信装置はボトルネックになる蓋然性が高い。
ボトルネックの予測または検出には、条件（Ｆ１）〜（Ｆ８）の一部または全部を任意に組み合わせた様々な条件が利用可能である。例えば、「条件（Ｆ２）または（Ｆ３）が成立する」、「条件（Ｆ１）〜（Ｆ８）のうち少なくとも１つが成立する」、「（（Ｆ１）または（Ｆ４））かつ（（Ｆ２）または（Ｆ５））が成立する」などの条件が利用可能である。
さらに、条件（Ｆ１）〜（Ｆ８）のいずれに関しても、１つの閾値との比較による判定の代わりに、２つ以上の閾値を利用する判定が行われてもよい。例えば、条件（Ｆ２）を例に説明すると、ボトルネック判定部６０３または８０３は、送信トラヒックの値が以下の（Ｇ１）〜（Ｇ３）のいずれの範囲に含まれるかを判定してもよい。
（Ｇ１）第１の閾値以下
（Ｇ２）第１の閾値より大きく、かつ、第２の閾値以下
（Ｇ３）第２の閾値より大きい
そして、ボトルネック判定部６０３または８０３は、送信トラヒックの値が範囲（Ｇ１）に含まれれば「問題なし」と判定してもよい。この場合、ボトルネック通知部６０４または８０４はボトルネック通知を送信しない。
また、ボトルネック判定部６０３または８０３は、送信トラヒックの値が範囲（Ｇ２）に含まれれば「要注意」と判定してもよい。この場合、ボトルネック通知部６０４または８０４は、「通信装置６００または８００は、ボトルネックになるおそれがあるので、通信装置６００または８００の監視を行うことが望ましい」ということを表す特定の情報を含むボトルネック通知を送信する。上記特定の情報は、例えば、「警戒レベル＝１」のように、単なる数値で表されてもよい。
また、ボトルネック判定部６０３または８０３は、送信トラヒックの値が範囲（Ｇ３）に含まれれば「ボトルネック」と判定してもよい。この場合、ボトルネック通知部６０４または８０４は、「通信装置６００または８００は、ボトルネックである」ということを表す特定の情報を含むボトルネック通知を送信する。上記特定の情報は、例えば、「警戒レベル＝２」のように、単なる数値で表されてもよい。
また、ボトルネック判定部６０３または８０３は、以上のように１つの条件に関して複数の閾値を用いる場合、過去の判定の履歴から、判定結果の傾向を判断し、判定結果の変化をさらに考慮してもよい。例えば、ボトルネック判定部６０３または８０３は、「通信装置６００または８００の負荷は、徐々に悪化する傾向にある」と判定した場合に、ボトルネック通知部６０４または８０４にボトルネック通知の送信を依頼してもよい。
あるいは、ボトルネック判定部６０３または８０３は、「送信トラヒックの値が範囲（Ｇ２）に含まれる」という判定結果を１回得ただけの段階では、まだボトルネック通知部６０４または８０４にボトルネック通知の送信を依頼しなくてもよい。そして、「送信トラヒックの値が範囲（Ｇ２）に含まれる」という判定結果が所定の回数以上連続したら、ボトルネック判定部６０３または８０３は、ボトルネック通知部６０４または８０４にボトルネック通知の送信を依頼してもよい。
続いて、第８実施形態について説明する。第８実施形態では、ボトルネック検出処理が恒常的に行われるのではなく、特定の場合にのみ行われる。
例えば、第３実施形態の通信装置６００は、データパケット７１０を受信するたびに、ボトルネック検出処理を行い、第４実施形態の通信装置８００は、ハローパケット７５０を受信するたびにボトルネック検出処理を行う。このように、上記の各実施形態では、恒常的にボトルネック検出処理が行われる。しかしながら、ネットワーク上のトラヒックの量が安定しており、かつ経路も安定しているならば、恒常的なボトルネック検出処理は、必ずしも必要ではない。
そこで、第８実施形態では、ボトルネック検出処理を行うことによる各ノードの処理負荷を軽減するため、ボトルネック検出処理は、恒常的には行われない。具体的には、各ノードは、通常は、ボトルネック検出処理およびボトルネック検出処理に関連する他の処理を省略する「通常モード」で動作する。そして、各ノードは、特定の条件が成立する場合にのみ、ボトルネック検出処理およびボトルネック検出処理に関連する他の処理を行う「検出モード」で動作する。
通常モードでは、例えば、図１２のステップＳ２０５または図２０のステップＳ６１１に相当するボトルネック検出処理が省略される。さらに、通常モードでは、例えば以下の（Ｈ１）〜（Ｈ４）のような、ボトルネック検出処理に関連する他の処理も省略される。
（Ｈ１）図１２のステップＳ２０４とＳ２１１
（Ｈ２）図１５のステップＳ５０８における送信トラヒックの計算
（Ｈ３）図２０のステップＳ６０８〜Ｓ６１０とＳ６１２
（Ｈ４）図２１のステップＳ７０２とＳ７０３
また、データパケットに送信トラヒックを埋め込む実施形態においては、通常モードで送信されるデータパケットでは、送信トラヒックフィールドが省略されてもよい。あるいは、「−１」などの特定の定数が送信トラヒックフィールドに設定されてもよい。
そして、ハローパケットに送信トラヒックを埋め込む実施形態においては、通常モードで送信されるハローパケットでは、送信トラヒックフィールドと選択ＬＤフィールドが省略されてもよい。あるいは、特定の定数が両フィールドに設定されてもよい。
また、第８実施形態において、通常モードと検出モードの切り替えの契機は、予め決められたスケジュールであってもよいし、ネットワーク全体にフラッディングされる特定の制御パケットであってもよい。
例えば、図４のネットワーク４００内のノードＡ〜Ｉの各々には、「毎日、３時から３時１５分の間だけ、検出モードで動作し、他の時間は通常モードで動作する」などのスケジュールが設定されていてもよい。そして、ノードＡ〜Ｉの各々は、スケジュールにしたがって動作モードを切り換えてもよい。
あるいは、通常モードから検出モードへの切り換えを命令する「検出開始命令パケット」と、検出モードから通常モードへの切り換えを命令する「検出終了命令パケット」のような、特定の制御パケットが使われてもよい。
例えば、ノードＡ〜Ｉの各々は、ゲートウェイＧＷ１から送信されてネットワーク４００全体にブロードキャストされフラッディングされる検出開始命令パケットを受信するまでは、通常モードで動作する。そして、ノードＡ〜Ｉの各々は、検出開始命令パケットを受信すると、検出モードで動作する。そして、ノードＡ〜Ｉの各々は、ゲートウェイＧＷ１から送信されてネットワーク４００全体にブロードキャストされフラッディングされる検出終了命令パケットを受信すると、動作モードを通常モードに戻す。
続いて、第９実施形態について説明する。
検出または予測されたボトルネックを警告するためのボトルネック通知の宛先は、第１実施形態では１つまたは複数の「第５の通信装置」であり、第２実施形態では１つまたは複数の「第４の通信装置」である。また、ボトルネック通知の宛先の具体例の１つとして、図４のネットワーク４００内のゲートウェイＧＷ１を例示し、他の具体例として、ネットワーク４００内の全ノードを例示した。
以上のように、ボトルネック通知の宛先は、実施形態に応じて、１つの装置でもよいし、複数の装置でもよい。また、ボトルネック通知の宛先が１つの装置である場合に、宛先の装置は、ゲートウェイＧＷ１のようなデータパケットのＧＤと同じであってもよいし、データパケットのＧＤとは別の装置でもよい。
例えば、第９実施形態では、ボトルネック通知の宛先は、予め決められた特定の１つの管理サーバである。しかし、管理サーバは、ゲートウェイＧＷ１とは異なる装置である。
例えば、図４のネットワーク４００が、さらに管理サーバを含むとする。管理サーバは、ゲートウェイＧＷ１を介してのみ他のノードＡ〜Ｉと接続されていてもよい。この場合、ボトルネック通知は、データパケットと同じ経路をたどってゲートウェイＧＷ１に送信され、ゲートウェイＧＷ１によって管理サーバへと中継されてもよい。
あるいは、管理サーバは、例えば、ノードＤ、ＥおよびＦと隣接するがゲートウェイＧＷ１とは隣接しない位置に設置されていてもよい。もちろん、管理サーバは、他の場所にあってもよい。
また、ネットワーク４００内に２つ以上の管理サーバがあってもよい。例えば、ノードＡ〜Ｅは、ボトルネック通知を送信する場合に第１の管理サーバを宛先として指定してもよく、他のノードＦ〜Ｉは、ボトルネック通知を送信する場合に第２の管理サーバを宛先として指定してもよい。
続いて、第１０実施形態について説明する。第１０実施形態では、ボトルネック通知がデータパケットのサブタイプとして定義される。
上記のように、ボトルネック通知の送信は、実施形態に応じて様々な方法で実現されてよい。例えば、データパケットやハローパケットの送信に使われるのとは別の周波数チャネルがボトルネック通知の送信に使われてもよい。また、データパケットとハローパケットはＩＥＥＥ ８０２．１５．４規格にしたがって送信され、ボトルネック通知はＩＥＥＥ ８０２．１１ｂ規格にしたがって送信されるなど、ボトルネック通知のみ通常とは異なる通信プロトコルにしたがって送信されてもよい。
しかし、もちろん、ボトルネック通知は、データパケットやハローパケットと同じ周波数チャネルで、同じ通信プロトコルにしたがって送信されてもよい。そこで、第１０実施形態では、データパケットのサブタイプとして、通常のデータパケットを示す第１のサブタイプと、ボトルネック通知を示す第２のサブタイプが定義される。
そして、ボトルネック通知は、ネットワーク内の所定の宛先（例えばゲートウェイＧＷ１）をＧＤとして指定した、第２のサブタイプのデータパケットとして、ネットワーク内をマルチホップ送信される。以上の第１０実施形態によれば、各ノードは、例えば８０２．１５．４ ＰＨＹ／ＭＡＣチップ２０５と８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６の双方を備える必要がないので、安価に製造することが可能である。
続いて、第１１実施形態について説明する。第１１実施形態では、データパケットのＧＤとして指定され得るゲートウェイが、ネットワーク内に複数存在する。ゲートウェイが複数ある場合も、上記各種実施形態と同様に、送信トラヒックフィールドはデータパケットに埋め込まれてもよく、ハローパケットに埋め込まれてもよい。
しかし、ゲートウェイが複数ある場合に、もし、送信トラヒックフィールドがハローパケットに含まれるならば、図１９のハローパケット７５０ではなく図１９のハローパケット７６０が使われる。そこで以下では第１１実施形態について、図２６と１９を参照して説明する。
図２６は、ネットワークの第２の例を示す図である。図２６のネットワーク４１０は、ノードＡ〜Ｋと、ゲートウェイＧＷ２と、ゲートウェイＧＷ３を含む。
図２６において２つのノードを結ぶ細い実線は、２つのノードが隣接することを示す。また、図２６における太い矢印は、データパケットの送信経路を示す。
そして、ノードＡ〜Ｋの各々には、ゲートウェイＧＷ２またはＧＷ３が、データパケットを送信するときのＧＤとして設定されている。具体的には、ノードＡ〜ＥはデータパケットをゲートウェイＧＷ２宛に送信し、ノードＦ〜ＫはデータパケットをゲートウェイＧＷ３宛に送信する。
また、ノードＡは、ノードＢとＤに隣接しており、ノードＢは、ノードＡ、Ｃ、ＤおよびＥに隣接しており、ノードＣは、ノードＢとＥに隣接している。そして、ノードＤは、ノードＡ、ＢおよびＥならびにゲートウェイＧＷ２に隣接している。また、ノードＥは、ノードＢ、Ｃ、Ｄ、ＦおよびＪならびにゲートウェイＧＷ２に隣接している。
そして、ノードＦは、ノードＥ、ＨおよびＩに隣接しており、ノードＧは、ノードＨ、ＪおよびＫに隣接している。また、ノードＨは、ノードＦ、ＧおよびＩに隣接しており、ノードＩは、ノードＦとＨに隣接している。そして、ノードＪは、ノードＥおよびＧならびにゲートウェイＧＷ３に隣接しており、ノードＫは、ノードＧとゲートウェイＧＷ３に隣接している。
そして、図２６の矢印に示すごとく、ノードＡは、ＧＤがゲートウェイＧＷ２のデータパケットを送信する際、ＬＤとしてノードＤを選択する。また、ノードＢとＣは、ＧＤがゲートウェイＧＷ２のデータパケットを送信する際、ＬＤとしてノードＥを選択する。ノードＤとＥは、ＧＤがゲートウェイＧＷ２のデータパケットを送信する際、ＬＤとしてゲートウェイＧＷ２自体を選択する。
また、ノードＥは、ＧＤがゲートウェイＧＷ２のデータパケットだけでなく、ＧＤがゲートウェイＧＷ３のデータパケットも送信する。そして、ノードＥは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてノードＪを選択する。
そして、ノードＦは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてノードＥを選択し、ノードＧは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてノードＫを選択する。また、ノードＨは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてノードＧを選択し、ノードＩは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてノードＦを選択する。そして、ノードＪとＫは、ＧＤがゲートウェイＧＷ３のデータパケットを送信する際、ＬＤとしてゲートウェイＧＷ３自体を選択する。
以上のようなネットワーク４１０内のノードＡ〜Ｋの各々は、例えば第３実施形態の通信装置６００のように構成されていてもよい。この場合、第３実施形態のデータパケット７１０の形式は変更の必要がない。
あるいは、ノードＡ〜Ｋの各々は、第４実施形態の通信装置８００と類似の構成を有してもよい。この場合、第４実施形態のハローパケット７５０の代わりに、第１１実施形態では、図１９のハローパケット７６０が使われ、各ノードの動作は、ハローパケットの形式の変更に合わせて適宜変更される。
具体的には、図１９のハローパケット７６０は、アドホックヘッダ７０１と、Ｍ個の送信トラヒック情報７６１−１〜７６１−Ｍを含む。ここで、Ｍは、ネットワーク内でデータパケットのＧＤとなり得るゲートウェイの数であり、図２６の例ではＭ＝２である。各送信トラヒック情報７６１−ｊ（１≦ｊ≦Ｍ）は、ＧＤと選択ＬＤと送信トラヒックという３つのフィールドを含む。
例えば、ハローパケット７６０の具体例として、図２６のノードＥが送信するハローパケット７６２が図１９には図示されている。なおここで、図２６において、ノードＡ〜Ｋの各々が、単位時間あたりにそれぞれ生成するデータパケットの量を「１」とする。すると、ノードＡ〜Ｋの各々が単位時間あたりに送信するデータパケットの量は、矢印の本数に相当する。
さて、ハローパケット７６２の送信トラヒック情報７６１−１では、ＧＤとしてゲートウェイＧＷ３が指定され、選択ＬＤとしてノードＪが指定され、送信トラヒックの値は「３」である。つまり、ハローパケット７６２の送信トラヒック情報７６１−１は、下記（Ｉ１）と（Ｉ２）を表す。
（Ｉ１）ノードＥが単位時間あたりに送信する、ＧＤとしてゲートウェイＧＷ３が指定されたデータパケットの量は、「３」である。
（Ｉ２）ＧＤとしてゲートウェイＧＷ３が指定されたデータパケットを送信する際、ノードＥは、ＬＤとしてノードＪを選択する。
なお、（Ｉ１）は、図２６において、ノードＥを始点または中継点としてゲートウェイＧＷ３を終点とする矢印が３本あることに対応する。そして、（Ｉ２）は、図２６において、これらの３本の矢印がノードＪを経由することに対応する。
また、ハローパケット７６２の送信トラヒック情報７６１−２では、ＧＤとしてゲートウェイＧＷ２が指定され、選択ＬＤとしてゲートウェイＧＷ２が指定され、送信トラヒックの値は「２」である。つまり、つまり、ハローパケット７６２の送信トラヒック情報７６１−２は、下記（Ｊ１）と（Ｊ２）を表す。
（Ｊ１）ノードＥが単位時間あたりに送信する、ＧＤとしてゲートウェイＧＷ２が指定されたデータパケットの量は、「２」である。
（Ｊ２）ＧＤとしてゲートウェイＧＷ２が指定されたデータパケットを送信する際、ノードＥは、ＬＤとしてゲートウェイＧＷ２を選択する。
なお、（Ｊ１）は、図２６において、ノードＥを中継点としてゲートウェイＧＷ２を終点とする矢印が２本あること（そして、ノードＥを始点としてゲートウェイＧＷ２を終点とする矢印はないこと）に対応する。また、（Ｊ２）は、図２６において、これらの２本の矢印が他のノードを経由せずにノードＥから直接ゲートウェイＧＷ２に向かっていることに対応する。
そして、以上のようなハローパケット７６０の形式に合わせて、第１１実施形態では、リンクテーブル８１１の形式と、送信量記憶部８１３の記憶内容と、図２０のステップＳ６０８以降の処理と、図２１の処理も変更される。具体的には以下のとおりである。
図１８では、リンクテーブル８１１の各エントリが、１つのリンク名に対応して１つの受信トラヒックの値のみを記憶する。それに対して、第１１実施形態では、リンクテーブル８１１の各エントリは、受信トラヒックとＧＤのペアをＭ個含む。
また、第１１実施形態では、Ｍ個のゲートウェイそれぞれをＧＤとして指定するデータパケットを通信装置８００が単位時間あたりに生成する量を、送信量記憶部８１３が記憶する。例えば、図２６のノードＥにおける送信量記憶部８１３は、ゲートウェイＧＷ２と対応づけて「０」という値を記憶するとともに、ゲートウェイＧＷ３と対応づけて「１」という値を記憶する。
また、第１１実施形態では、図２０のステップＳ６０８以降の各ステップは、受信されたハローパケット７６０の送信トラヒック情報７６１−１〜７６１−Ｍの各々に対して（すなわち、Ｍ個のゲートウェイの各々に対して）行われる。
例えば、ハローパケット７６２をノードＥから受信したノードＤは、次のように動作する。
送信トラヒック情報７６１−１の選択ＬＤも、送信トラヒック情報７６１−２の選択ＬＤも、ノードＤとは異なる。よって、ノードＤは、リンクテーブル８１１においてリンク名としてノードＥが指定されたエントリにおいて、ゲートウェイＧＷ２とＧＷ３にそれぞれ対応づけられている受信トラヒックの値を、どちらも「０」に設定する。
また、ハローパケット７６２をノードＥから受信したノードＪは、次のように動作する。
送信トラヒック情報７６１−１の選択ＬＤは、ノードＪ自身を示す。よって、ノードＪは、リンクテーブル８１１においてリンク名としてノードＥが指定されたエントリにおいて、ゲートウェイＧＷ３と対応づけられている受信トラヒックを、送信トラヒック情報７６１−１における送信トラヒックの「３」という値に上書きする。
他方、送信トラヒック情報７６１−２の選択ＬＤは、ノードＪとは異なる。よって、ノードＪは、リンクテーブル８１１においてリンク名としてノードＥが指定されたエントリにおいて、ゲートウェイＧＷ２と対応づけられている受信トラヒックを「０」に設定する。
なお、図２０のステップＳ６１１のボトルネック検出処理は、具体的には、例えば図１４と類似の処理である。しかし、第１１実施形態では、図１４の処理がＭ個のゲートウェイそれぞれに対して行われる。
また、第１１実施形態では、図２１のステップＳ７０２とＳ７０３がＭ個のゲートウェイそれぞれに対して行われ、ステップＳ７０４では、ハローパケット７５０ではなくハローパケット７６０が生成される。
ところで、本発明は上記実施形態に限られるものではない。例えば、上記第１〜１１実施形態は、様々な観点で異なる実施形態の例であるが、複数の実施形態を適宜組み合わせることもできる。例えば、第４実施形態のようにハローパケット７５０に送信トラヒックを埋め込む実施形態において、ボトルネック検出処理の詳細を、第５または第６実施形態のように変形することもできる。
また、上記の説明においてもいくつかの変形について説明したが、さらに例えば下記の観点からの様々な変形も可能である。上記の各種実施形態およびその変形、ならびに下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
送信トラヒックは、図１０に示すようにデータパケットのみに埋め込まれてもよいし、図１９に示すようにハローパケットのみに埋め込まれてもよい。しかし、データパケットとハローパケットの双方に送信トラヒックが埋め込まれてもよい。
また、アドホックネットワークのルーティングアルゴリズムには、例えば、プロアクティブ（proactive）型、リアクティブ（reactive）型、ハイブリッド型などの様々なものがあるが、実施形態に応じて、ルーティングアルゴリズムは、どのタイプでもよい。
より正確には、データパケットなどのマルチホップ送信の対象となるパケットに関するルーティングアルゴリズムは、すべてのボトルネックの予測または検出にかかる時間程度の短いタイムスパンで経路を擬似的に静的と見なせさえすれば、任意である。つまり、頻繁に（例えばデータパケットの送信のたびに）経路が切り換わるようなルーティングアルゴリズムでなければ、ルーティングアルゴリズムは任意である。
換言すれば、たとえ経路が変動するとしても、変動が緩やかに進行するタイプのルーティングアルゴリズムが使われる場合、一旦経路が構築された後は、比較的短いタイムスパンに注目すると、擬似的には、経路は、静的で安定している、と見なせる。なお、「比較的短いタイムスパン」とは、具体的には、図６や１６とともに説明したような、すべてのボトルネックの予測または検出にかかる時間と同程度の時間のことである。よって、変動が緩やかに進行するタイプの任意のルーティングアルゴリズムが利用可能である。
例えば、制御パケットを用いた経路構築フェーズで先に経路を構築してから、データ送信フェーズで実際にデータパケットを送信するように設計されたルーティングアルゴリズムも利用可能である。逆に、経路構築フェーズとデータ送信フェーズを分けずに、実際にデータパケットを送信しながらネットワーク内のノードが自律的に適切な経路を見出すように設計されたルーティングアルゴリズムも利用可能である。
また、上記実施形態におけるいくつかの処理は、閾値との比較を含む。閾値との比較は、実施形態により「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。また、上記の説明では様々な用途の閾値を例示したが、各閾値の具体的な値は、実施形態に応じて適宜任意に決められてよい。
また、ルーティングテーブルにおける評価値や、リンクテーブルにおける品質などに関して、上記の例では、評価または品質が高いほど値が小さい。しかしもちろん実施形態によっては、評価または品質が高いほど値が大きいように、評価値または品質の値が定義されてもよく、定義に合わせて各ノードの動作が適宜変更されてもよい。
また、図６や１６の例では、ノードＡ〜Ｉそれぞれの送信量記憶部６１３または８１３に記憶される値は、いずれも「１」である。しかし、もちろん、実施形態によっては、ノードごとに送信量記憶部６１３または８１３に記憶される値が異なっていてもよい。
また、パケットの形式は実施形態に応じて任意であり、フィールドの順序やサイズは様々であってよい。そして、上記に例示した以外のフィールドを、さらにパケットが含んでいてもよい。
例えば、各ノードは、リンク品質の評価値をハローパケットに含めてもよい。すると、互いに隣接するノードは、ハローパケットの交換をとおして、リンクの双方向の品質を認識することができる。
例えば、ノードＨは、ノードＦからのハローパケットの受信間隔の揺れに基づいて計算した評価値を、ノードＦのノードＩＤと対応づけてハローパケットに含めてもよい。すると、ノードＨからのハローパケットを受信したノードＦは、ノードＦとＨの間のリンクの、ノードＦからノードＨへ向かう方向についての評価値を認識することが可能となる。ノードＦは、重み付き送信経路数の計算において、以上のようにして認識した評価値をさらに利用してもよい。
また、実施形態によっては、例えばボトルネック通知がデータパケットのサブタイプであってもよい。その場合、図２の通信装置２００は８０２．１１ｂ ＰＨＹ／ＭＡＣチップ２０６を持たなくてもよい。
リンクテーブルやルーティングテーブルのデータ形式も、実施形態に応じて適宜変更されてよい。例えば、テーブル以外にも、有限ＦＩＦＯ（First In First Out）、線形リストなどの任意のデータ構造が利用可能である。
さらに、図８と１８ではリンクテーブルが受信トラヒックのフィールドを有するが、受信トラヒックは、隣接ノードと対応づけられて記憶されさえすればよい。例えば、各通信装置は、リンクテーブルとは別の記憶領域に、受信トラヒックと隣接ノードを対応づけて記憶してもよい。
また、図２５の例では、重み付き送信経路数の計算において、ルーティングテーブル６１２内のすべてのＬＤの候補が使われる。しかし、実施形態によっては、ＬＤの候補の一部のみが、重み付き送信経路数の計算に使われてもよい。
例えば、ルーティングテーブルは、評価値がベスト５までの隣接ノードをＬＤの候補として記憶してもよいが、重み付き送信経路数の計算においては、評価値がベスト３以内のＬＤの候補のみが使われてもよい。あるいは、最良の評価値との差が所定範囲内に収まるような評価値を持つＬＤの候補のみが、重み付き送信経路数の計算に使われてもよい。
たとえ経路の切り換えが生じたとしても、最初に代替経路として選択されるのは２番目に評価の良いＬＤの候補である。そして、より下位のＬＤの候補まで（例えば第５候補まで）代替経路として次々に試されるような状況は、しばしば生じるというわけではない。
よって、潜在的な送信容量（あるいはネットワークトポロジの変動に対する頑健性）の指標としての重み付き送信経路数の計算においては、代替経路として実際に選ばれる見込みの高い、評価値が相対的に上位のＬＤの候補さえ考慮に入れられれば十分である。したがって、実施形態によっては、重み付き送信経路数の計算において、必ずしもルーティングテーブル内のすべてのＬＤの候補が使われる必要はない。
また、上記の説明で言及した数値等の具体的な値や具体的な変数名は、説明の便宜上例示したに過ぎない。
そして、図２と３に例示した以外のハードウェアにより通信装置が実現されてもよいことは無論である。通信装置の各機能は、ＡＳＩＣ（Application Specific Integrated Circuit）などの専用ハードウェア回路、ＦＰＧＡなどのリコンフィギュラブル回路、汎用のＭＰＵ、またはそれらの任意の組み合わせにより、実現可能である。
以上、変形例も含めて様々な実施形態について説明したが、いずれの実施形態も、アドホックネットワークの利用拡大にともなって顕在化しつつある新たな問題（すなわちボトルネックの発生）への対策を立てるうえで、非常に有益である。
例えば、新たなアドホックネットワークを構築するには、まず、複数のノードが物理的に配置される。ノードの配置は、例えば、人手により行われてもよい。そして、アドホックネットワークの運用開始の前の試験段階において、アドホックネットワーク全体の動作が検証され、必要に応じた調整が行われる。
具体的には、例えば、試験段階では、ゲートウェイがすべてのノードからのデータパケットを受信することができるか否かが監視される。監視の結果から、各ノードから送信されるデータパケットの中継が問題なく行われるか否かが判断される。
例えば、ある特定の一部のノードからのデータパケットをゲートウェイが受信することができない場合、必要に応じて、ノードの位置の調整、中継用のノードの追加、ノードのアンテナの向きの調整などが行われてもよい。しかし、アドホックネットワークの規模が大きければ、ある特定の一部のノードからのデータパケットがゲートウェイに受信されない場合に、その理由を解明することは難しい。
例えば、理由の１つとしては、「ある２つのノードの間が（例えば物理的に離れすぎているなどの理由から）物理的に通信不能であり、迂回経路も存在しない」ということも考えられる。他方、別の理由として、「いずれかのノードがボトルネックになっている」ということも考えられる。理由に応じて、具体的な対策も異なり得る。
そして、上記の各種実施形態によれば、ボトルネックのノードを速やかに発見することが可能となるので、早期にボトルネックの解消のための対策をとることも可能となる。また、ボトルネックが検出されることにより、ボトルネックの発生とそれ以外の理由との判別も自ずと可能となる。
また、アドホックネットワークの運用開始後に、例えば、「各ノードが単位時間あたりに生成して送信するデータパケットの量を増やす」といった、運用条件の変更が計画されるかもしれない。例えば、各ノードへのセンサの追加や、データパケットの送信間隔の短縮が計画されるかもしれず、そのような計画は、単位時間あたりに生成されるデータパケットの量の増加を意味する。
以上のような計画が立てられた場合にも、上記の各種実施形態によれば、「計画が実行されたとしたら、現状のネットワークが負荷に耐えられるか否か」というシミュレーションを容易に行うことができる。つまり、上記各種実施形態によれば、例えば送信量記憶部６１３または８１３に記憶されている値を変更するだけで、現在運用中のアドホックネットワーク上のデータパケットの送信を妨げることなく、ボトルネックを予測することができる。
したがって、上記の各種実施形態によれば、計画を実行に移す前に、予測される問題を把握し、問題を未然に防ぐための対策（例えばノードの追加や計画の見直しなど）をとることが可能となる。
また、試験段階にしろ、新たな計画が立てられた場合にしろ、上記の各種実施形態によれば、観測用のダミーパケットなどを実際アドホックネットワーク上に流す必要はない。したがって、上記の各種実施形態によれば、ボトルネックの予測または検出するために、通常のデータパケットの送信が圧迫されることもないし、通常のデータパケットの送信を一時的に止める必要もない。
よって、上記の各種実施形態によれば、少ない工数でボトルネックの予測または検出が可能である。また、ボトルネックの予測が行われる場合はさらに、「運用中のアドホックネットワークシステムの運用停止を招くことなく予測が可能である」という優れた効果も得られる。

Claims (6)

  1. 複数の通信装置を含むネットワークにおける第１の通信装置であって、
    第２の通信装置にデータを送る際に選択可能な、前記第１の通信装置に隣接する第３の通信装置を記憶した経路情報記憶部と、
    前記第１の通信装置に隣接する第４の通信装置から、該第４の通信装置が所定期間に前記第１の通信装置を介して送信する前記第２の通信装置宛の第１の送信データ量の通知を受信する受信部と、
    前記第１の送信データ量を含む、前記第１の通信装置から前記所定期間に送信する前記第２の通信装置宛の第２の送信データ量を前記第３の通信装置に通知する送信量通知部と、
    前記第２の送信データ量が所定の基準を超えているかを判定する判定部と、
    前記第２の送信データ量が前記所定の基準を超えていると前記判定部が判定した場合に、前記第１の通信装置が前記ネットワークにおけるボトルネックであることを、予め定められた第５の通信装置に通知する送信ボトルネック通知部と、
    を備える第１の通信装置。
  2. 前記経路情報記憶部は、前記第３の通信装置と前記第１の通信装置との間の通信品質の第１の評価値をさらに記憶し、
    前記判定部は、前記第２の送信データ量と前記第１の評価値とを基に計算した第１の値が第１の閾値より大きい場合に、前記第２の送信データ量が前記所定の基準を超えている、と判定する
    ことを特徴とする請求項１記載の第１の通信装置。
  3. 前記経路情報記憶部は、前記第２の通信装置にデータを送る際に選択可能な、前記第１の通信装置に隣接する第６の通信装置および該第６の通信装置と前記第１の通信装置との間の通信品質の第２の評価値をさらに記憶し、
    前記判定部は、前記第２の送信データ量、前記第１の評価値および第２の評価値を基に計算した第２の値が、第２の閾値より大きい場合に、前記第２の送信データ量が前記所定の基準を超えている、と判定する
    ことを特徴とする請求項２記載の第１の通信装置。
  4. 複数の通信装置を含むネットワークにおける第１の通信装置であって、
    前記第１の通信装置に隣接する１つ以上の第２の通信装置の各々から、各第２の通信装置が所定期間に送信する第３の通信装置宛のデータの第１の送信データ量の通知を受信する受信部と、
    前記１つ以上の第２の通信装置の各々から通知された前記第１の送信データ量を集約した第２の送信データ量が所定の基準を超えているかを判定する判定部と、
    前記第２の送信データ量が前記所定の基準を超えていると前記判定部が判定した場合に、前記第１の通信装置が前記ネットワークにおけるボトルネックであることを、予め定められた第４の通信装置に通知する受信ボトルネック通知部と、
    を備える第１の通信装置。
  5. 複数の通信装置を含むネットワークにおける第１の通信装置が実行する方法であって、
    第２の通信装置にデータを送る際に選択可能な、前記第１の通信装置に隣接する第３の通信装置を記憶した経路情報記憶部を参照して、前記第３の通信装置を認識し、
    前記第１の通信装置に隣接する第４の通信装置から、該第４の通信装置が前記第１の通信装置を介して所定期間に送信する前記第２の通信装置宛の第１の送信データ量の通知を受信し、
    前記第１の送信データ量を含む、前記第１の通信装置から前記所定期間に送信する前記第２の通信装置宛の第２の送信データ量を前記第３の通信装置に通知し、
    前記第２の送信データ量が所定の基準を超えているかを判定し、
    前記第２の送信データ量が前記所定の基準を超えていると判定した場合に、前記第１の通信装置が前記ネットワークにおけるボトルネックであることを、予め定められた第５の通信装置に通知する、
    ことを特徴とする方法。
  6. 複数の通信装置を含むネットワークにおける第１の通信装置が実行する方法であって、
    前記第１の通信装置に隣接する１つ以上の第２の通信装置の各々から、各第２の通信装置が所定期間に送信する第３の通信装置宛のデータの第１の送信データ量の通知を受信し、
    前記１つ以上の第２の通信装置の各々から通知された前記第１の送信データ量を集約した第２の送信データ量が所定の基準を超えているかを判定し、
    前記第２の送信データ量が前記所定の基準を超えていると判定した場合に、前記第１の通信装置が前記ネットワークにおけるボトルネックであることを、予め定められた第４の通信装置に通知する、
    ことを特徴とする方法。
JP2012546598A 2010-11-29 2010-11-29 通信装置および方法 Expired - Fee Related JP5435147B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/071299 WO2012073316A1 (ja) 2010-11-29 2010-11-29 通信装置および方法

Publications (2)

Publication Number Publication Date
JP5435147B2 true JP5435147B2 (ja) 2014-03-05
JPWO2012073316A1 JPWO2012073316A1 (ja) 2014-05-19

Family

ID=46171304

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012546598A Expired - Fee Related JP5435147B2 (ja) 2010-11-29 2010-11-29 通信装置および方法

Country Status (3)

Country Link
US (1) US20130279339A1 (ja)
JP (1) JP5435147B2 (ja)
WO (1) WO2012073316A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120155471A1 (en) * 2010-12-15 2012-06-21 Electronics And Telecommunications Research Institute Method and apparatus for routing
CN105684504A (zh) * 2013-10-28 2016-06-15 日本电气株式会社 通信系统、无线基站、业务负载均衡方法和存储有程序的存储介质
JP2015207918A (ja) * 2014-04-21 2015-11-19 富士通株式会社 設定装置、ネットワークシステム、及び設定プログラム
US10754866B2 (en) * 2015-04-30 2020-08-25 Hitachi, Ltd. Management device and management method
JP6523922B2 (ja) * 2015-10-30 2019-06-05 Kddi株式会社 基地局装置、制御方法およびプログラム
JP6479704B2 (ja) * 2016-03-29 2019-03-06 古河電気工業株式会社 ネットワークシステム、通信装置、および、通信方法
JP6414262B2 (ja) * 2017-03-24 2018-10-31 沖電気工業株式会社 無線中継装置、無線通信装置及び無線通信システム
JP2020145647A (ja) * 2019-03-08 2020-09-10 キヤノン株式会社 システム、クライアント端末、制御方法、および、プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100493234B1 (ko) * 2002-11-25 2005-06-02 한국전자통신연구원 노드 시스템, 이를 이용한 이중링 통신 시스템 및 그 통신방법
US20040213395A1 (en) * 2003-02-03 2004-10-28 Kenji Ishii Apparatus and a method for optimizing network resources employed in data communication
GB0323245D0 (en) * 2003-10-03 2003-11-05 Fujitsu Ltd Soft handover techniques
JP4218499B2 (ja) * 2003-11-07 2009-02-04 富士電機システムズ株式会社 無線端末装置、及びプログラム
KR100560748B1 (ko) * 2003-11-11 2006-03-13 삼성전자주식회사 알피알 공평 메카니즘을 이용한 대역폭 할당 방법
JP4689630B2 (ja) * 2007-01-31 2011-05-25 株式会社エヌ・ティ・ティ・ドコモ 通信端末及び通信制御方法
JP5041948B2 (ja) * 2007-09-28 2012-10-03 京セラ株式会社 無線端末及び無線通信方法

Also Published As

Publication number Publication date
JPWO2012073316A1 (ja) 2014-05-19
WO2012073316A1 (ja) 2012-06-07
US20130279339A1 (en) 2013-10-24

Similar Documents

Publication Publication Date Title
JP5435147B2 (ja) 通信装置および方法
KR101001556B1 (ko) 무선 센서 네트워크의 노드의 패킷 전송 장치 및 방법
KR100900307B1 (ko) 무선통신장치, 통신 경로 제어장치, 통신 경로 제어방법 및통신시스템
JP4571235B2 (ja) 経路制御装置、経路異常予測装置、方法、およびプログラム
JP5464266B2 (ja) 通信システムおよびネットワーク管理方法
CN109219942B (zh) 控制消息模式的方法及装置
JP6036841B2 (ja) 通信制御方法、ネットワークシステム、および通信装置
JPWO2013088498A1 (ja) 送信制御方法、ノードおよび送信制御プログラム
JP5897699B2 (ja) 端末、経路生成方法および経路生成プログラム
WO2016046869A1 (ja) 通信品質計測方法、及び通信システム
JP4796014B2 (ja) 通信制御支援装置及び通信制御支援方法並びにプログラム
US10257763B2 (en) Routing protocol for advanced metering infrastructure system
JP5058020B2 (ja) 通信システム
US9191846B2 (en) Monitoring method of multi-hop wireless network
CN105814850A (zh) 路由数据包的方法、节点和通信系统
JP6617713B2 (ja) 通信装置、通信方法、及びプログラム
US20160254979A1 (en) Communication system, common service control apparatus, data transmission method, and non-transitory computer readable medium
JP5378268B2 (ja) 無線基地局、無線通信システム、無線基地局のトラヒックレベル決定方法
JP6259622B2 (ja) 通信装置、無線ネットワークシステム、無線ネットワーク制御方法、及び、無線ネットワーク制御プログラム
JP6206105B2 (ja) 通信システム、通信方法および通信プログラム
WO2014080564A1 (ja) ネットワークシステム
JP2018019442A (ja) 通信装置、データ送信方法、及び、データ送信プログラム
JP6254824B2 (ja) 通信装置、データ送信方法、及び、データ送信プログラム
JP4311325B2 (ja) ネットワークシステムおよびノードおよび利己的なノードの検出方法
JP3804348B2 (ja) 無線通信ネットワークシステム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131112

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131125

R150 Certificate of patent or registration of utility model

Ref document number: 5435147

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees