WO2011121676A1

WO2011121676A1 - 通信装置および通信方法

Info

Publication number: WO2011121676A1
Application number: PCT/JP2010/002402
Authority: WO
Inventors: 岩尾忠重; 古賀俊介
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2010-03-31
Filing date: 2010-03-31
Publication date: 2011-10-06
Anticipated expiration: 2012-09-30
Also published as: JP5423878B2; JPWO2011121676A1

Abstract

　通信装置は、資源の使用状況を表す計量値を得、計量値がある条件を満たすとき、最終宛先ごとの資源の使用状況にしたがい、当該通信装置がデータの転送を休止しようとする最終宛先である第１の通信装置を決定し、第１の通信装置を最終宛先とするデータの当該通信装置への送信を休止するよう要求する第１のポーズデータを送信する。第２の通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータを受信したとき、通信装置は、データを送信する送信経路を識別する情報を含む経路制御情報のうち、第２の通信装置を識別する情報に対応づけられている経路制御情報を、第２の通信装置を最終宛先とするデータの送信経路から第２のポーズデータを受信した経路を除外するように更新する。また、通信装置は、経路制御情報にしたがって、送信対象データの送信経路を決定し、送信対象データを送信する。

Description

通信装置および通信方法

　本発明は、アドホックネットワークにおける通信の制御に関する。

　ネットワークにおける通信に関しては、経路制御、輻輳制御、フロー制御など、様々な観点から様々な技術が開発されている。
　例えば、ＩＰ（Internet Protocol）電話網において発生した輻輳を解消するための、ＩＰ電話網における輻輳制御システムが提案されている。この輻輳制御システムは、ＩＰ電話網に配置されて呼発信を中継して呼発信の着番号へ接続する中継サーバを有する。

　上記中継サーバは、呼発信を受信して記憶するとともに当該記憶の容量を越えた呼発信に対し容量を越えたことを通知するための受信ソケットバッファを備える。また、上記中継サーバは、記憶された呼発信について所定の振分条件に基づき、呼発信を接続処理する正常系処理と非接続とする異常系処理とに振分けるための上位処理制限手段を備える。

　また、無線マルチホップネットワークにおいて、必要以上の無線帯域の使用を抑えることにより、輻輳状態を回避して、エンドツーエンド（end-to-end）におけるスループットの公平性を担保するための技術も提案されている。

　具体的には、送信キューが、宛先別に区分され、それぞれソースキューおよび転送キューの種別に区分され、さらに優先度毎に区分される。そして、エンキュー制御部が、上位層からのパケットを、その宛先、種別および優先度に基づいて、該当する区分のキューに保持させる。また、デキュー制御部は、送信キューの何れかの区分のキューから送信データを取り出して、対応する宛先局に宛てて送出する。デキューの際には、無線マルチホップネットワークにおけるホップ数に基づいた閾値を基準としてデキュー動作が終了する。また、各区分のキューの送出量の比率は、ホップ数に基づいて設定される。

　さらに、優先度などの条件に合わせて装置間のデータ流量を細かく制御することができるフロー制御方法も提案されている。
　具体的には、上記フロー制御方法は、受信装置が、入力バッファを監視し、入力バッファの残量が所定の閾値より少ないか否かを判断するステップを含む。また、上記フロー制御方法は、受信装置が、入力バッファの残量が所定の閾値より少ないと判断した場合に、拡張ポーズフレームを送信するステップを含む。拡張ポーズフレームにおいて、ＭＡＣ（Media Access Control）制御コードのフィールドには、拡張ポーズフレームであることを示す識別子が設定される。また、中断時間のフィールドには、入力バッファの残量に基づく、クラスごとの制御情報である出力制御情報が設定される。上記フロー制御方法は、さらに、送信装置が、拡張ポーズフレームの出力制御情報に基づき、優先度のクラスごとに帯域制御を行うステップを含む。

　また、近年ではアドホックネットワークが注目を集めている。無線アドホックネットワークだけでなく、有線アドホックネットワークも研究されており、センサネットワークへの応用が試みられている。

　例えば、「Ｓ－ｗｉｒｅ」と呼ばれる有線式のセンサネットワークでは、各通信装置が有線で複数の通信装置に接続されており、有線によりデータ通信および電源の供給が行われる。有線式の利点として、センサを土中、水中や構造物などへ埋め込むことが可能である点や、切断などの検出が可能である点が挙げられる。

特開２００６－１４０２１号公報特開２００８－１０３８９９号公報特開２００８－２３６３０８号公報

岩尾忠重、山田健二、野村浩司、細川武司著「多用途向け有線センサネットワーク：Ｓ－ｗｉｒｅ」雑誌ＦＵＪＩＴＳＵ、２００６年５月号（ＶＯＬ．５７、ＮＯ．３）、２８５～２９０ページ

　例えばポーズフレームなどの制御情報を用いることでデータの送信を抑制する技術は、輻輳の回避には有効である。しかし、輻輳を回避するために、送信対象のデータが破棄されてしまうこともありうる。

　他方で、送信対象のデータの破棄は、データを無駄にすることにつながる。よって、もし輻輳が回避可能なのであれば、データを破棄するよりはデータの中継を継続する方が好ましい。

　そこで本発明は、輻輳を回避しつつデータの中継も継続するための技術を提供することを目的とする。

　一態様による通信装置は、データを送信する送信部と、データを受信する受信部と、経路制御情報記憶部と、監視部と、ポーズ制御部と、経路制御情報更新部と、経路制御部を備える。

　前記経路制御情報記憶部は、データの最終宛先を識別する最終宛先識別情報に対応づけて、前記データを送信する送信経路を識別する送信経路識別情報を含む経路制御情報を記憶する。

　前記監視部は、前記通信装置における資源の使用状況を監視し、前記使用状況を表す計量値を得る。
　前記ポーズ制御部は、前記計量値が所定の条件を満たすとき、最終宛先ごとの前記資源の使用状況にしたがって、前記通信装置がデータの転送を休止しようとする最終宛先である第１のポーズ対象通信装置を決定し、前記第１のポーズ対象通信装置を最終宛先とするデータの前記通信装置への送信を休止するよう要求する第１のポーズデータを生成し、前記第１のポーズデータを送信するよう前記送信部を制御する。

　前記経路制御情報更新部は、前記受信部が、第２のポーズ対象通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータを受信したとき、前記第２のポーズ対象通信装置を最終宛先とするデータの送信経路から前記第２のポーズデータを受信した経路を除外するように、前記第２のポーズ対象通信装置を識別する最終宛先識別情報に対応づけられて前記経路制御情報記憶部に記憶されている前記経路制御情報を更新する。

　前記経路制御部は、前記経路制御情報記憶部に記憶された前記経路制御情報にしたがって、送信の対象である送信対象データの送信経路を決定し、決定した前記送信経路に前記送信対象データを送信するよう前記送信部を制御する。

　上記通信装置によれば、ポーズフレームの受信を契機として、場合に応じて適宜、今まで送信に使われていた送信経路とは別の経路が送信に利用されるようになるので、データの中継は継続される。また、高負荷の通信装置においては、他の通信装置が第１のポーズフレームにしたがって振る舞うことで、受信するフレームの量が減り、負荷が軽減される。よって、負荷の集中による輻輳も防止される。

ポーズ制御の第１の動作例を説明する図（その１）である。ポーズ制御の第１の動作例を説明する図（その２）である。ポーズ制御の第１の動作例を説明する図（その３）である。ポーズ制御の第２の動作例を説明する図（その１）である。ポーズ制御の第２の動作例を説明する図（その２）である。通信装置の機能構成図である。テーブル格納部に格納されるテーブルの例を示す図（その１）である。ルーティングテーブルでのポート状態の状態遷移図である。ループ検出テーブルでのポート状態の状態遷移図である。テーブル格納部に格納されるテーブルの例を示す図（その２）である。第１実施形態の通信装置が適用されるネットワークの例を示す図である。障害発生時の代替経路探索を説明する概念図である。フレームの形式を説明する図である。フレーム受信処理のフローチャートである。ポーズ設定処理のフローチャートである。第２の動作例におけるポーズ設定処理の例を説明する図である。ポーズ解除処理のフローチャートである。ＧＤ別バッファ使用量加算処理のフローチャートである。受信データフレーム処理のフローチャート（その１）である。受信データフレーム処理を説明するフローチャート（その２）である。受信データフレーム処理を説明するフローチャート（その３）である。バッファ解放処理のフローチャートである。データフレーム送信処理のフローチャート（その１）である。データフレーム送信処理のフローチャート（その２）である。ポーズ制御処理のフローチャートである。ポーズ要求フレーム送信処理の第１の例のフローチャートである。ポーズ要求フレーム送信処理の第２の例のフローチャートである。ポーズ解除フレーム送信処理の第１の例のフローチャートである。ポーズ解除フレーム送信処理の第２の例のフローチャートである。ポーズ解除フレーム送信処理の第３の例のフローチャートである。ポーズ対象ＧＤ決定処理の第１の例のフローチャートである。ポーズ対象ＧＤ決定処理の第２の例のフローチャートである。ポーズ対象ＧＤ決定処理の第３の例のフローチャートである。ポーズ対象ＧＤ決定処理の第４の例のフローチャートである。ルーティングテーブルカウンタ処理のフローチャートである。第２実施形態でのルーティングテーブルの例を示す図である。通信装置のハードウェア構成図である。

　以下、実施形態について、図面を参照しながら詳細に説明する。説明の順序は次のとおりである。
　まず、いくつか用語について説明してから、第１実施形態の通信装置によるポーズ制御の概要を、図１～図５に示す２つの動作例を参照しながら説明する。

　その後、第１実施形態の通信装置の構成について図６を参照して説明する。次に、図６に示す各種テーブルの詳細について図７～図１０を参照して説明する。
　その後、図６のような通信装置を複数含むネットワークにおけるルーティングに関する分散協調動作の概要を、図１１と図１２を参照して説明する。あわせて、図１３を参照して、フレーム形式の例についても説明する。

　そして、図１４～図３５を参照して、個々の通信装置の動作の詳細を説明する。個々の通信装置の動作の説明においては、適宜図１～図１３を参照して、個々の通信装置の動作と、ネットワーク全体の振る舞いとの関連についても説明する。その後、第２実施形態およびその他の実施形態について説明する。

　ここで、下記の各実施形態における用語についていくつか説明する。
　下記の実施形態では、複数の通信装置がネットワーク内に含まれる。ネットワークトポロジの観点からは、個々の通信装置はネットワーク内の個々のノードであるので、通信装置を「ノード装置」または「ノード」ともいう。また、１つまたは複数の通信装置を含むネットワークを「ノード群」ともいう。ノード群は、より大きなネットワークの一部であってもよい。

　また、以下では、第１の通信装置と第２の通信装置が直接通信可能な場合、第１と第２の通信装置が「隣接している」という。すなわち、互いに隣接する２つの通信装置間のホップ数は１である。換言すれば、第１と第２の通信装置の間に有線または無線のリンクが確立している場合、第１と第２の通信装置は互いに隣接している。

　具体的には、第１と第２の通信装置が直接ケーブルで接続されており、第１と第２の通信装置がケーブルを介して情報を通信しあうことができるとき、第１と第２の通信装置の間には有線リンクが存在し、第１と第２の通信装置は互いに隣接する。また、第１と第２の通信装置が、第３の通信装置による中継を経ずに直接、無線により情報を通信しあうことができるとき、第１と第２の通信装置の間には無線リンクが存在し、第１と第２の通信装置は互いに隣接する。

　なお、リンクは固定的ではなく、動的に変化することがありうる。天候や遮蔽物などの影響で、無線リンクが新たに確立されたり、今まで確立されていた無線リンクが消滅したりすることがある。通信装置が可動式であれば、通信装置間の距離の変動によってリンクの有無が変化することもある。また、ケーブルの接続替えにより、新たな有線リンクが確立されたり、今まで存在していた有線リンクが消滅したりすることがあり、ケーブルの切断等の障害によって有線リンクが消滅することもある。

　また、上記のように第１と第２の通信装置が隣接するとき、第１の通信装置にとっての第２の通信装置を「隣接通信装置」ということがある。同様に、第２の通信装置にとっては、第１の通信装置が「隣接通信装置」である。なお、「通信装置」を「ノード」ということがあるのと同様に、「隣接通信装置」を「隣接ノード」ということもある。

　また、以下では通信装置間で通信手順（プロトコル）に従って送受信されるデータの単位であるＰＤＵ（Protocol Data Unit）、および、送受信の単位データそのものを「フレーム」と称する。下記の実施形態では、様々なフレームが処理される。フレームは、以下のようにいくつかの観点から分類される。

　フレームは、図１３に示す「アドホックヘッダ」を含むか否かによって分類することができる。以下では、アドホックヘッダを含むフレームを「アドホックフレーム」という。他方、アドホックヘッダを含まないフレームの例は、例えば、周知のイーサネット（登録商標）で利用されるイーサネットフレームである。

　なお、アドホックフレームは、アドホックヘッダの後に続くイーサネットフレームを含むデータフレームと、アドホックヘッダの後にその他の特定の形式の制御データを含む制御フレームに、さらに分類することもできる。制御フレームには複数の種類があってもよい。下記の各実施形態で利用されるポーズフレームと、第２実施形態に関して後述するＡＣＫ（ACKnowledge）フレームは、制御フレームの具体例である。

　また、フレームには、１つの通信装置だけが最終的な宛先として指定されるユニキャストフレームもあるし、隣接する複数の通信装置に送信されるフレームもある。さらに、ネットワーク内にフラッディングされるブロードキャストフレームなど、他の種類のフレームがあってもよい。

　以下の説明においては、必要に応じて、上記のような観点からのフレームの分類を明示する。なお、文脈から分類が明らかであるか、または分類に無関係な箇所では、簡単のために単純に「フレーム」と述べる場合もある。

　さて、図１～図３は、第１実施形態によるポーズ制御の第１の動作例を説明する図であり、図４と図５は、第１実施形態によるポーズ制御の第２の動作例を説明する図である。詳しくは後述するが、通信装置におけるポーズ制御は、その通信装置へのフレームの送信を休止するよう隣接通信装置に要求するための制御と、フレームの転送を再開することを隣接通信装置に通知するための制御を含む。

　さて、図１～図５に示すネットワーク１は、ノード２～７とノード群８～１３を含む。ネットワーク１のトポロジは、以下のとおりである。
　・ノード２とノード３は隣接している。

　・ノード３とノード４は隣接している。
　・ノード２は、ノード群８内の１つ以上のノードと隣接している。
　・ノード２は、ノード群９内の１つ以上のノードと隣接している。

　・ノード３は、ノード群１０内の１つ以上のノードと隣接している。
　・ノード３は、ノード群１１内の１つ以上のノードと隣接している。
　・ノード４は、ノード群９内の１つ以上のノードと隣接している。

　・ノード４は、ノード群１２内の１つ以上のノードと隣接している。
　・ノード５は、ノード群９内の１つ以上のノードと隣接している。
　・ノード６は、ノード群９内の１つ以上のノードと隣接している。

　・ノード７は、ノード群９内の１つ以上のノードと隣接している。
　・ノード群９内のあるノードとノード群１３内のあるノードが隣接している。
　・ノード群１２内のあるノードとノード群１３内のあるノードが隣接している。

　上記のようなトポロジのネットワーク１は、例えば、ノード５～７をゴールノードとして、ノード５～７に他のノードからの情報を収集する用途に利用されてもよい。
　例えば、ノード群８内のあるノードは、ノード５を最終的な宛先としてフレームを送信してもよいし、ノード群８の他のノードは、ノード６またはノード７を最終的な宛先としてフレームを送信してもよい。あるいは、ノード群８内のある１つのノードが、送信する情報の種類などに応じて、ノード５～７のうちの２つ以上のゴールノードを最終的な宛先としてフレームを送信してもよい。ノード群９～１３内の不図示の各ノードについても同様である。

　詳しくは後述するが、第１実施形態においてノードとして使われる通信装置は、フレームの最終的な宛先ごとに、フレームを送信する経路を制御する。以下では、フレームの、ネットワーク１内における最初の送信元の通信装置を「ＧＳ（Global Source）」といい、フレームの、ネットワーク１内における最終的な宛先の通信装置を「ＧＤ（Global Destination）」という。

　例えば、ノード群１０内のノードである通信装置がＧＳとしてフレームを送信する場合、このフレームの最終的な宛先がノード５とすると、ＧＤはノード５である。そして、図１～図５のネットワーク１においては、このフレームはノード３によって中継される。

　ノード３は、フレームのＧＤに応じて、フレームの送信経路を制御する。例えば、ノード３は、フレームのＧＤがノード５であれば、隣接するノード４にフレームを送信し、フレームのＧＤがノード６または７であれば、隣接するノード２にフレームを送信してもよい。

　このように、ＧＤではないノード３は、受信したフレームを、中継（relay）する（つまり転送（forward）する）ために、隣接通信装置であるノード２または４に送信することがある。以下では、互いに隣接する２つの通信装置間でのフレームの送信において、フレームの送信元の通信装置を「ＬＳ（Local Source）」といい、フレームの宛先の通信装置を「ＬＤ（Local Destination）」という。例えば、上記の例では、ノード群１０内のノードがＧＳとなって送信した、ＧＤとしてノード５が指定されたフレームの送信において、ノード３がＬＳであり、ノード４がＬＤである。

　ＧＤごとの送信経路の制御の具体的方法については後述するが、第１実施形態の通信装置は、送信経路をＧＤごとに制御することに対応して、ポーズ制御もＧＤごとに行う。送信経路の制御とポーズ制御がともにＧＤごとに行われることによって、ネットワーク１全体としては負荷の偏りが小さく抑えられ、個々の通信装置における負荷の変動も小さく抑えられる。その結果、より良い負荷分散が実現される。図１～図５は、第１実施形態による負荷分散の具体例を示す。

　例えば、ネットワーク１では、図１に示す時刻Ｔ１までは、ノード５～７をＧＤとするフレームによってノード５～７に情報を収集することが定常的に行われていたとし、定常的に送信されるフレームの量が次のとおりであったとする。

　ＧＤとしてノード５が指定されており、ノード群８内の１つまたは複数の隣接ノードからノード２が単位時間あたりに受信するフレームの量は、ある適宜の量を単位量とすると、１であるとする。また、ＧＤとしてノード６が指定されており、ノード群８内の１つまたは複数の隣接ノードからノード２が単位時間あたりに受信するフレームの量は、上記単位量によれば１単位であるとする。そして、ＧＤとしてノード７が指定されており、ノード群８内の１つまたは複数の隣接ノードからノード２が単位時間あたりに受信するフレームの量は、上記単位量によれば１単位であるとする。

　以下では説明の便宜上、単位時間あたりに受信するフレームの量を、上記単位量を用いて、式（１）のような表記法を用いてＧＤ別に表すことにする。
　　｛〈ノード５，１〉，
　　　〈ノード６，１〉，
　　　〈ノード７，１〉｝　　　　　　　　　（１）

　式（１）は、上記で説明したような、ノード群８内の１つまたは複数の隣接ノードからノード２が単位時間あたりに受信するフレームの量をＧＤ別に示している。換言すれば、式（１）は、ノード群８に起因してノード２が単位時間あたりに処理するデータ量Ｄ１０１を示す。

　図１～図５では、ＧＤがノード５であるフレームの量を、白い矩形の高さで表し、ＧＤがノード６であるフレームの量を、黒い矩形の高さで表し、ＧＤがノード７であるフレームの量を、斜線パターンの矩形の高さで表している。

　また、ノード群１０内の１つまたは複数の隣接ノードからノード３が単位時間あたりに受信するフレームの量をＧＤ別に示すと、式（２）のとおりであるとする。式（２）は図１のデータ量Ｄ１０２に対応する。
　　｛〈ノード５，１〉，
　　　〈ノード６，１〉，
　　　〈ノード７，１〉｝　　　　　　　　　　（２）

　そして、ノード群１１内の１つまたは複数の隣接ノードからノード３が単位時間あたりに受信するフレームの量をＧＤ別に示すと、式（３）のとおりであるとする。式（３）は図１のデータ量Ｄ１０３に対応する。
　　｛〈ノード５，１〉，
　　　〈ノード６，１〉，
　　　〈ノード７，１〉｝　　　　　　　　　　（３）

　また、ノード群１２内の１つまたは複数の隣接ノードからノード４が単位時間あたりに受信するフレームの量をＧＤ別に示すと、式（４）のとおりであるとする。式（４）は図１のデータ量Ｄ１０４に対応する。
　　｛〈ノード５，２〉，
　　　〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　（４）

　そして、ノード３が送信経路の制御（つまりフレームのルーティング）を行う方針が、次のとおりであるとする。すなわち、ノード３は、ＧＤがノード５のフレームに関しては、ＬＤとしてノード４を選択し、ＧＤがノード６または７のフレームに関しては、ＬＤとしてノード２を選択するものとする。

　すると、式（２）と（３）より、ノード３がノード２に送信するフレームの量は式（５）のように表され、ノード３がノード４に送信するフレームの量は式（６）のように表される。式（５）と（６）はそれぞれ図１のデータ量Ｄ１０５とＤ１０６に対応する。
　　｛〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　（５）
　　｛〈ノード５，２〉｝　　　　　　　　　　（６）

　また、ノード２は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信するよう、送信経路の制御を行うとする。なお、下記の３つのノードが、３つの異なるノードであっても、２つの異なるノードであっても、同じ１つのノードであっても、以下の議論には影響がない。
　・ＧＤがノード５のフレームのＬＤとしてノード２が選択するノード群９内のノード
　・ＧＤがノード６のフレームのＬＤとしてノード２が選択するノード群９内のノード
　・ＧＤがノード７のフレームのＬＤとしてノード２が選択するノード群９内のノード

　よって、以下では単に「ノード２は、ＧＤがノード５～７のフレームをノード群９に送信する」のように述べることがある。そして、ノード２は、ＧＤがノード５～７のフレームをノード群９に送信するので、式（１）と（５）より、ノード２がノード群９内の１つ以上の隣接ノードに送信するフレームの量は、式（７）のように表される。式（７）は図１のデータ量Ｄ１０７に対応する。
　　｛〈ノード５，１〉，
　　　〈ノード６，３〉，
　　　〈ノード７，３〉｝　　　　　　　　　　　（７）

　また、ノード４は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信するよう、送信経路の制御を行うとする。すると、式（４）と（６）より、ノード４がノード群９内の１つ以上の隣接ノードに送信するフレームの量は、式（８）のように表される。式（８）は図１のデータ量Ｄ１０８に対応する。
　　｛〈ノード５，４〉，
　　　〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　（８）

　したがって、時刻Ｔ１までの定常的な状態では、式（１）、（５）、（７）より、ノード２の処理負荷は、式（９）のように表される。
　　（１＋１＋１）＋（２＋２）
　＝１＋３＋３
　＝７　　　　　　　　　　　　　　　　　　　　（９）

　同様に、式（２）、（３）、（５）、（６）より、ノード３の処理負荷は式（１０）のように表され、式（４）、（６）、（８）より、ノード４の処理負荷は式（１１）のように表される。
　　（１＋１＋１）＋（１＋１＋１）
　＝（２＋２）＋２
　＝６　　　　　　　　　　　　　　　　　　　　（１０）
　　（２＋２＋２）＋２
　＝４＋２＋２
　＝８　　　　　　　　　　　　　　　　　　　　（１１）

　ここで、説明の便宜上、ノード２～４はいずれも、処理負荷が１０を超えるとビジー状態に陥るとする。換言すれば、ノード２～４の処理能力を、処理遅延やフレームの廃棄などを生じることなく正常に処理を遂行することの可能な処理負荷の量により表すと、１０であるとする。式（９）～（１１）が示すとおり、時刻Ｔ１ではノード２～４のいずれもビジー状態には陥っていない。

　ところが、あるとき、例えばノード群１１にノードが追加されたなどの何らかの理由により、ノード群１１からノード３が受信するフレーム（具体的には、ＧＤがノード５のフレーム）の量が増えたとする。すると、このフレームの量の増大に対応して、ノード４がビジー状態に陥る。図２は、上記のようにしてノード４がビジー状態に陥った時刻Ｔ２のネットワーク１を示す図である。

　図２において、ノード群８からノード２へ送信されるデータ量Ｄ２０１は、図１のデータ量Ｄ１０１と同様であり、式（１）により表される。また、ノード群１０からノード３に送信されるデータ量Ｄ２０２は、図１のデータ量Ｄ１０２と同様であり、式（２）により表される。そして、ノード群１２からノード４に送信されるデータ量Ｄ２０４は、図１のデータ量Ｄ１０４と同様であり、式（４）により表される。

　他方で、ノード群１１内の１つまたは複数の隣接ノードからノード３が単位時間あたりに受信するフレームの量をＧＤ別に示すと、式（１２）のとおりであるとする。
　　｛〈ノード５，４〉，
　　　〈ノード６，１〉，
　　　〈ノード７，１〉｝　　　　　　　　　　　　　（１２）

　式（１２）は図２のデータ量Ｄ２０３に対応する。また、図１のデータ量Ｄ１０３に対応する式（３）との比較から明らかなように、増加したのはＧＤがノード５のフレームである。そして、増加した量は、上記の単位量を用いて表せば、３（＝４－１）である。

　ここで、上記のとおりノード３は、ＧＤがノード６または７のフレームに関しては、ＬＤとしてノード２を選択する。つまり、ノード３がノード２に送信するフレームの量は、ＧＤがノード５のフレームの量が増えても影響を受けず、図１のデータ量Ｄ１０５と同じく式（５）により表される。

　また、上記のとおり、データ量Ｄ２０１とＤ２０５が図１のデータ量Ｄ１０１とＤ１０５とそれぞれ同じなので、ノード２がノード群９に送信するフレームの量も、図１の場合と同じである。つまり、図２のデータ量Ｄ２０７は、図１のデータ量Ｄ１０７と同じく、式（７）により表される。

　他方、上記のとおりノード３は、ＧＤがノード５のフレームに関しては、ＬＤとしてノード４を選択する。よって、ノード３がノード４に送信するフレームの量は、図１のデータ量Ｄ１０６に対応する式（６）と比較すると増加し、具体的には式（１３）のとおりである。式（１３）は図２のデータ量Ｄ２０６に対応する。

　　｛〈ノード５，５〉｝　　　　　　　　　　　　　　（１３）
　したがって、ノード４がノード群９に送信するフレームの量は、データ量Ｄ２０４に対応する式（４）とデータ量Ｄ２０６に対応する式（１３）から、式（１４）のように表される。
　　｛〈ノード５，７〉，
　　　〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　（１４）

　よって、時刻Ｔ２において、ノード２の処理負荷は、図１に関して説明した式（９）のとおりである。また、ノード３の処理負荷は、式（２）、（１２）、（５）、（１３）より、式（１５）のように表される。よって、ノード２と３は時刻Ｔ２でもビジー状態には陥っていない。
　　（１＋１＋１）＋（１＋１＋４）
　＝（２＋２）＋５
　＝９　　　　　　　　　　　　　　　　　　　　　　　（１５）

　他方、ノード４の処理負荷は、式（４）、（１３）、（１４）より、式（１６）のように表される。
　　（２＋２＋２）＋５
　＝７＋２＋２
　＝１１　　　　　　　　　　　　　　　　　　　　　　（１６）

　そして、１１＞１０なので、ノード４はビジー状態に陥る。そこで、ノード４は、ノード４へのフレームの送信を休止するよう隣接ノードに要求することで、負荷の低減を図り、ひいてはビジー状態からの回復を図る。第１実施形態では、フレームの送信の休止の要求は、ポーズ要求フレームの送信により実現される。

　ポーズ要求フレームの具体的な形式の例は図１３とともに後述するが、ポーズ要求フレームは、フレームの種類がポーズ要求フレームであることを示す情報と、どのノードをＧＤとするフレームの送信の休止を要求するかを指定する情報を含む。詳しくは後述するとおり、ポーズ要求フレームで指定されるＧＤの数は、１つでもよいし、複数でもよい。

　図２の例では、ノード４が、ノード７をＧＤとするフレームのノード４への送信を休止するよう要求するポーズ要求フレームＰ１を各隣接ノードに送信する。なお、ポーズ要求フレームで指定するＧＤを決定する処理は、詳しくは図３１～図３４とともに説明するとおり、実施形態に応じて様々に異なる。ここでは、ノード４が何らかの基準にしたがって、「ポーズ要求フレームＰ１で指定するＧＤとして適切なのはノード７である」と決定するものとする。

　図３は、ポーズ要求フレームＰ１の送信から少し時間が経過した時刻Ｔ３におけるネットワーク１の状態を示す。ポーズ要求フレームＰ１を受信するのはノード４の隣接ノードのみなので、ノード４に隣接しないノード群８、１０、１１などはポーズ要求フレームＰ１の直接の影響は受けない。

　よって、図３において、ノード群８からノード２に送信されるデータ量Ｄ３０１は、図２のデータ量Ｄ２０１と同様であり、式（１）により表される。また、ノード群１０からノード３に送信されるデータ量Ｄ３０２は、図２のデータ量Ｄ２０２と同様であり、式（２）により表される。そして、ノード群１１からノード３に送信されるデータ量Ｄ３０３は、図２のデータ量Ｄ２０３と同様であり、式（１２）により表される。

　他方、ノード群１２においてノード４に隣接する１つ以上のノードは、ポーズ要求フレームＰ１を受信済みなので、ノード７をＧＤとするフレームをノード４に送信することを休止する。すなわち、ノード群１２においてノード４に隣接する１つ以上のノードは、ノード７をＧＤとするフレームをノード４とは別の経路（具体的にはノード群１３内のノード）に送信する。

　その結果、ノード群１２からノード４に送信されるフレームの量をＧＤ別に表すと、式（１７）のようになる。式（１７）は図３のデータ量Ｄ３０４を示す。
　　｛〈ノード５，２〉，
　　　〈ノード６，２〉｝　　　　　　　　　　　　　　　（１７）

　また、ノード群１２からノード群１３に送信されるフレームの量をＧＤ別に表すと、式（１８）のようになる。式（１８）は図３のデータ量Ｄ３０９を示す。
　　｛〈ノード７，２〉｝　　　　　　　　　　　　　　　（１８）

　また、上記のように、ノード３がノード４に送信するフレームは、ノード５をＧＤとするフレームのみである。つまり、ノード３からノード４へ送信されるデータ量Ｄ３０６は、ポーズ要求フレームＰ１による影響を受けないので図２のデータ量Ｄ２０６と変わらず、式（１３）により表される。

　同様に、ノード３からノード２へ送信されるデータ量Ｄ３０５も、図２のデータ量Ｄ２０５と変わらず、式（５）により表される。したがって、ノード３からノード群９に送信されるデータ量Ｄ３０７も、図２のデータ量Ｄ２０７と同じであり、式（７）により表される。

　ここでノード４に注目すると、ノード４に流入するデータ量Ｄ３０４とＤ３０６は、それぞれ式（１７）と（１３）により表される。また、上記のとおりノード４は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信する。よって、ノード４が処理するデータ量は、すなわちノード４がノード群９に送信するデータ量Ｄ３０８である。また、式（１７）と（１３）から、データ量Ｄ３０８は、以下の式（１９）によって表される。
　　｛〈ノード５，７〉，
　　　〈ノード６，２〉｝　　　　　　　　　　　　　　　（１９）

　なお、ノード群１２からノード群１３に送信された、ノード７をＧＤとするデータ量Ｄ３０９のフレームは、ノード群１３からノード群９に送信される。図３のデータ量Ｄ３１０は、こうしてノード群１３からノード群９に送信されるフレームの量を示しており、データ量Ｄ３０９と同様に上記の式（１８）により表される。

　以上から、時刻Ｔ３においても、ノード２の処理負荷は、図１に関して説明した式（９）と同じである。また、ノード３の処理負荷は、図２に関して説明した式（１５）と同じである。

　そして、時刻Ｔ３においてノード４の処理負荷は、式（１７）、（１３）、（１９）より、式（２０）のように表される。
　　（２＋２）＋５
　　＝７＋２
　　＝９　　　　　　　　　　　　　　　　　　　　　　　（２０）

　ここで９≦１０なので、ノード４は図２のビジー状態から回復する。そこで、ノード４は、ビジー状態からの回復を隣接ノードに通知する。すなわち、ノード４は、ノード７をＧＤとするフレームの転送を再開することを隣接ノードに通知する。換言すれば、ノード４は、ノード７をＧＤとするフレームのノード４への送信を隣接ノードに許可するための通知を出す。

　上記通知は、第１実施形態では、ポーズ解除フレームの送信により実現される。ポーズ解除フレームの具体的な形式の例は図１３とともに後述するが、ポーズ解除フレームは、フレームの種類がポーズ解除フレームであることを示す情報と、どのノードをＧＤとするフレームの転送を再開するのかを明示的または暗黙的に指定する情報を含む。詳しくは後述するとおり、ポーズ解除フレームで明示的にＧＤが指定される場合、指定されるＧＤの数は、１つでもよいし、複数でもよい。

　図３の例では、ビジー状態から回復したノード４が、ポーズ要求フレームＰ１で指定したのと同じノード７をポーズ解除対象のＧＤとして指定したポーズ解除フレームＲ１を、各隣接ノードに送信する。後述するように、ポーズ解除フレームによる通知は必ずしも必要ではないが、ネットワークリソースの有効利用に役立つ。

　なお、図３の例の場合、以下の３つの理由から、ポーズ解除フレームＲ１に起因する送信経路の変更は起こらない。
　第１の理由は、ポーズ解除フレームＲ１を受信したノード３は、もともとノード７をＧＤとするフレームをノード４ではなくノード２に送信するよう、送信経路を制御しているからである。よって、ノード３からノード４への送信は、ポーズ解除フレームＲ１の影響を受けない。

　第２の理由は、ノード群１２においてノード４に隣接する１つ以上のノードは、ノード７をＧＤとするフレームをノード４ではなくノード群１３に送信するよう、送信経路の制御方針を変更済みだからである。そして、第３の理由は、図３の例では、ノード群１２からノード群１３とノード群９を介してノード７へと、障害なくフレームを送信することが可能な経路が存在するからである。

　第２と第３の理由から、ノード７をＧＤとするフレームを図２の時刻Ｔ２の時点ではノード４に送信していたノード群１２内の１つ以上のノードにおいては、時刻Ｔ３の後に再度あえて送信経路の制御方針を変更する必要性がない。よって、ノード群１２においてノード４に隣接する１つ以上のノードは、ポーズ要求フレームＰ１の受信に応じて変更した送信経路を時刻Ｔ３以降も使い続ける。

　ところで、上記のとおり、ポーズ要求フレームに指定するＧＤを決定する処理のアルゴリズムは様々である。よって、アルゴリズムに応じて、ノード４が時刻Ｔ２において、「ポーズ要求フレームで指定するＧＤとして適切なのはノード５である」と判断することもありうる。図４と図５は、ノード４がそのように判断した場合の例を示す。

　ノード４が、ＧＤとしてノード５を指定するポーズ要求フレームを送信した場合、ノード４に隣接しないノード群８、１０、１１はポーズ要求フレームの直接の影響を受けない。よって、図４において、ノード群８からノード２に送信されるデータ量Ｄ４０１は、図２のデータ量Ｄ２０１と同様であり、式（１）により表される。また、ノード群１０からノード３に送信されるデータ量Ｄ４０２は、図２のデータ量Ｄ２０２と同様であり、式（２）により表される。そして、ノード群１１からノード３に送信されるデータ量Ｄ４０３は、図２のデータ量Ｄ２０３と同様であり、式（１２）により表される。

　他方、ノード群１２においてノード４に隣接する１つ以上のノードは、図４には不図示のポーズ要求フレームを受信済みなので、ノード５をＧＤとするフレームをノード４に送信することを休止する。すなわち、ノード群１２においてノード４に隣接する１つ以上のノードは、ノード５をＧＤとするフレームをノード４とは別の経路（具体的にはノード群１３内のノード）に送信する。

　その結果、ノード群１２からノード４に送信されるフレームの量は、ＧＤ別に表すと、式（２１）のようになる。式（２１）は図４のデータ量Ｄ４０４を示す。
　　｛〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　（２１）

　また、上記の不図示のポーズ要求フレームを受信したノード３は、ノード５をＧＤとするフレームを、ノード４とは別の経路に送信するようになる。具体的には、ノード３は、ノード６または７をＧＤとするフレームだけでなく、ノード５をＧＤとするフレームをも、ノード２に送信するようになる。その結果、ノード３からノード２に送信されるフレームの量は、ＧＤ別に表すと、式（２２）のようになる。式（２２）は図４のデータ量Ｄ４０５を示す。
　　｛〈ノード５，５〉，
　　　〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　（２２）

　ここで、ノード２に注目すると、ノード２に流入するデータ量Ｄ４０１とＤ４０５は、それぞれ式（１）と（２２）により表される。また、上記のとおりノード２は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信する。よって、ノード２が処理するデータ量は、すなわちノード２がノード群９に送信するデータ量Ｄ４０７であり、データ量Ｄ４０７は、式（１）と（２２）から、式（２３）のように表される。
　　｛〈ノード５，６〉，
　　　〈ノード６，３〉，
　　　〈ノード７，３〉｝　　　　　　　　　　　　　　（２３）

　ここで、式（１）、（２２）、（２３）から、時刻Ｔ４におけるノード２の処理負荷は、式（２４）のように表される。
　　（１＋１＋１）＋（５＋２＋２）
　＝６＋３＋３
　＝１２　　　　　　　　　　　　　　　　　　　　　　（２４）

　そして、１０＜１２なので、ノード２はビジー状態に陥る。すなわち、時刻Ｔ２にビジー状態に陥ったノード４が、ＧＤとしてノード５を指定した不図示のポーズ要求フレームを送信したことが原因で、いわばビジー状態がノード４からノード２へと伝播してしまう。

　その結果、ノード２は、何らかの基準にしたがってノード６を選択し、ノード６をＧＤとするフレームのノード２への送信を休止するよう要求するポーズ要求フレームＰ３を隣接ノードに送信する。

　ところで、ノード５をＧＤとするフレームを時刻Ｔ２まではノード４に送信していたノード３は、不図示のポーズ要求フレームをノード４から受信すると、上記のとおり、ノード５をＧＤとするフレームをノード４に送信しないようになる。したがって、ノード４に流入するフレームの量（換言すればノード４が処理するフレームの量）は、データ量Ｄ４０４に等しい。

　また、上記のとおりノード４は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信する。よって、ノード４がノード群９に送信するデータ量Ｄ４０８も、データ量Ｄ４０４に等しく、式（２１）により表される。

　したがって、時刻Ｔ４におけるノード４の処理負荷は、式（２１）より、式（２５）のように表される。
　　２＋２
　＝２＋２
　＝４　　　　　　　　　　　　　　　　　　　　　　　　（２５）

　ここで４≦１０なので、ノード４はビジー状態から回復する。そして、ノード４は、図４に示すように、ノード５をＧＤとするフレームの転送を再開することを隣接ノードに通知するためのポーズ解除フレームＲ２を送信する。

　なお、上記の不図示のポーズ要求フレームをノード４から受信したノード群１２内のノードは、ノード５をＧＤとするフレームを、ノード４とは別の経路に送信するようになる。よって、ノード群１２からノード群１３に送信されるフレームの量をＧＤ別に表すと、式（２６）のとおりである。式（２６）は図４のデータ量Ｄ４０９を示す。
　　｛〈ノード５，２〉｝　　　　　　　　　　　　　　　（２６）

　ノード群１２からノード群１３に送信された、ノード５をＧＤとするデータ量Ｄ４０９のフレームは、ノード群１３からノード群９に送信される。図４のデータ量Ｄ４１０は、こうしてノード群１３からノード群９に送信されるフレームの量を示しており、やはり式（２６）により表される。

　このように、ポーズ要求フレームに指定されるＧＤによっては、ポーズ要求フレームを送信したノード４自体はビジー状態から回復することができても、他のノード２がビジー状態に陥ってしまうことがありうる。しかしながら、第１実施形態によれば、たとえ他のノード２にビジー状態が伝播したとしても、少し時間が経てば、ノード２もまたビジー状態から回復する。すなわち、第１実施形態の通信装置を個々のノードとして含むネットワーク１は、ときには多少の試行錯誤をともなうにしても、負荷の偏りの少ない状態へと自律的に遷移する。

　具体的には、図４のようにノード２がポーズ要求フレームＰ３を送信すると、図５に示すように、ノード群８においてノード２に隣接する１つ以上のノードは、ＧＤがノード６のフレームのノード２への送信を休止する。その結果、ノード群８からノード２に送信されるフレームの量は、ＧＤ別に表すと、式（２７）のようになる。式（２７）は図５のデータ量Ｄ５０１を示す。
　　｛〈ノード５，１〉，
　　　〈ノード７，１〉｝　　　　　　　　　　　　　　　（２７）

　なお、ノード群８においてノード２に隣接する１つ以上のノードは、ＧＤがノード６のフレームを、ノード２とは異なる経路で送信するようになる。図５の例は、ＧＤがノード６のフレームがノード群８からノード群９へと送信されるようになる例である。こうしてノード群８からノード群９へ送信されるフレームの量は、ＧＤ別に表すと、式（２８）のとおりであり、式（２８）は図５のデータ量Ｄ５１１を示す。
　　｛〈ノード６，１〉｝　　　　　　　　　　　　　　　（２８）

　また、図４のポーズ要求フレームＰ３を受信したノード３は、ノード６をＧＤとするフレームのノード２への送信を休止する。その結果、ノード３からノード２に送信されるフレームの量は、ＧＤ別に表すと、式（２９）のようになる。式（２９）は図５のデータ量Ｄ５０５を示す。
　　｛〈ノード５，５〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　　（２９）

　なお、ノード３は、ポーズ要求フレームＰ３の受信を契機に、ノード６をＧＤとするフレームを、ノード２とは異なる経路に送信するようになる。具体的には、ノード３は、ノード６をＧＤとするフレームをノード４に送信する。その結果、ノード３からノード４に送信されるフレームの量は、ＧＤ別に表すと、式（３０）のようになる。式（３０）は図５のデータ量Ｄ５０６を示す。
　　｛〈ノード６，２〉｝　　　　　　　　　　　　　　　（３０）

　他方、ノード２に隣接しないノード群１０～１３は、ポーズ要求フレームＰ３の直接の影響は受けない。よって、ノード群１０からノード３に送信されるデータ量Ｄ５０２は、図４のデータ量Ｄ４０２と同様であり、式（２）により表される。また、ノード群１１からノード３に送信されるデータ量Ｄ５０３は、図２のデータ量Ｄ２０３と同様であり、式（１２）により表される。

　そして、ノード群１２からノード４に送信されるデータ量Ｄ５０４は、図４のデータ量Ｄ４０４と同様であり、式（２１）により表される。また、ノード群１２からノード群１３に送信されるデータ量Ｄ５０９は、図４のデータ量Ｄ４０９と同様であり、式（２６）により表される。同様に、ノード群１３からノード群９に送信されるデータ量Ｄ５１０は、図４のデータ量Ｄ４１０と同様であり、データ量Ｄ５０９と同じく式（２６）により表される。

　さて、ポーズ要求フレームＰ３の受信を契機として上記のようにノード３とノード群８内のノードが経路制御の方針を変えると、結果として、ノード２が処理するデータ量は、流入するデータ量Ｄ５０１とＤ５０５の合計となる。また、上記のとおりノード２は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信する。

　よって、図５に示す時刻Ｔ５においてノード２からノード群９へ送信されるデータ量Ｄ５０７は、データ量Ｄ５０１を示す式（２７）とデータ量Ｄ５０５を示す式（２９）より、下記の式（３１）のとおりである。
　　｛〈ノード５，６〉，
　　　〈ノード７，３〉｝　　　　　　　　　　　　　　　（３１）

　よって、式（２７）、（２９）、（３１）より、時刻Ｔ５におけるノード２の処理負荷は、式（３２）のように表される。
　　（１＋１）＋（５＋２）
　＝６＋３
　＝９　　　　　　　　　　　　　　　　　　　　　　　　（３２）

　そして、９≦１０なので、ノード２はビジー状態から回復する。そこで、ノード２は、ビジー状態からの回復を隣接ノードに通知する。すなわち、ノード２は、図４のポーズ要求フレームＰ３で指定したのと同じノード６をポーズ解除対象のＧＤとして指定したポーズ解除フレームＲ３を、各隣接ノードに送信する。

　なお、図３の例に関して、ポーズ解除フレームＲ１に起因する送信経路の変更が起こらない理由として説明したのと同様の理由から、ポーズ解除フレームＲ３に起因する送信経路の変更は起こらない。

　なお、時刻Ｔ４でビジー状態から回復したノード４の時刻Ｔ５における処理負荷は、流入するデータ量Ｄ５０４とＤ５０６の合計に等しい。そして、上記のとおりノード４は、受信したフレームのＧＤがノード５～７のいずれであっても、フレームをノード群９内の隣接ノードに送信する。

　したがって、ノード４からノード群９に送信されるデータ量Ｄ５０８は、式（２１）、（３０）より、式（３３）のように表される。
　　｛〈ノード６，４〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　　（３３）

　そして、式（２１）、（３０）、（３３）より、時刻Ｔ５におけるノード４の処理負荷は、式（３４）のように表される。
　　（２＋２）＋２
　　＝４＋２
　　＝６　　　　　　　　　　　　　　　　　　　　　　　（３４）

　ここで、６≦１０なので、図４に示すように一旦ビジー状態から回復したノード４は、時刻Ｔ５においても通常の状態を保ち続けている。したがって、たとえ一時的に図４に示すようなビジー状態の伝播が生じたとしても、しばらくすれば、ネットワーク１は、どのノードもビジー状態ではない、安定的な状態（換言すれば負荷の偏りの少ない状態）へと自律的に遷移する。

　以上のように、ネットワーク１内の個々のノードがポーズ要求フレームとポーズ解除フレームを用いてポーズ制御を行うことで、ネットワーク１全体としては適切な負荷分散が実現される。

　また、以上概要を説明したように、第１実施形態では、「ビジー状態に陥ったノードまたはその隣接ノードが、フレームを廃棄することによりビジー状態からの回復を図る」といったアプローチとは異なるアプローチがとられている。すなわち、第１実施形態では、ビジー状態に陥ったノードの隣接ノードが、フレームの送信経路を切り換えることにより、ビジー状態に陥ったノードの負荷の軽減と、途中まで転送されてきたフレームの廃棄の防止の双方を実現する。よって、第１実施形態によれば、輻輳を回避しつつデータの中継も継続することができる。

　そして、第１実施形態のようなＧＤごとのポーズ制御は、ネットワーク１全体での負荷の平均化に有益であり、換言すれば、リソースの有効活用に有益である。この利点についての理解を助けるため、次に、ＧＤを指定する情報がポーズ要求フレームとポーズ解除フレームにまったく含まれない比較例について説明する。

　例えば、図２の時刻Ｔ２において、ノード４が、ＧＤを指定する情報を含まないポーズ要求フレームを送信したとする。すると、ノード４に隣接する各ノードは、フレームのＧＤによらず、フレームのノード４への送信を休止する。

　したがって、この比較例においては、ノード３は、ノード４からのポーズ要求フレームの受信を契機として、今までノード４へ送信していたデータ量Ｄ２０６のフレームを、例えばノード２に送信するようになる。また、ノード群１２内においてノード４に隣接するノードも、ノード４からのポーズ要求フレームの受信を契機として、今までノード４へ送信していたデータ量Ｄ２０４のフレームを、例えばノード群１３内のノードに送信するようになる。

　すると、ノード３からノード２へ送信されるフレームのデータ量は、式（３５）のとおり、図２のデータ量Ｄ２０５とＤ２０６の和となる。
　　｛〈ノード５，５〉，
　　　〈ノード６，２〉，
　　　〈ノード７，２〉｝　　　　　　　　　　　　　　　（３５）

　また、ノード２には、図２と同様に、ノード群８からデータ量Ｄ２０１のフレームも送信される。したがって、ノード２の処理負荷は、式（３６）のとおりである。
　　（５＋１）＋（２＋１）＋（２＋１）
　＝６＋３＋３
　＝１２　　　　　　　　　　　　　　　　　　　　　　　（３６）

　すると、１０＜１２なので、今度はノード２がビジー状態に陥る。そこで、ノード２がポーズ要求フレームを送信する。本比較例では、このポーズ要求フレームも、ＧＤを指定する情報を含まないとする。

　すると、ノード２に隣接する各ノードは、フレームのＧＤによらず、フレームのノード２への送信を休止する。
　例えば、ノード群８内においてノード２に隣接するノードは、ノード２からのポーズ要求フレームの受信を契機として、図５に示すノード群８と９の間の経路に、データ量Ｄ２０１のフレームを送信するようになる。

　また、上記のようにノード４がポーズ要求フレームを送信した後は、ノード４へはフレームが送信されなくなるので、ノード４ではやがてビジー状態が解消し、処理負荷が０となる。そして、ノード４はポーズ解除フレームを隣接する各ノードに送信する。例えば、ノード３が、ノード２からのポーズ要求フレームを受信する前に、ノード４からのポーズ解除フレームを既に受信しているとする。すると、ノード３は、ノード２からのポーズ要求フレームの受信を契機として、式（３５）に示す合計９（＝５＋２＋２）のデータ量のフレームを、ビジー状態が解消したノード４へと送信するようになる。

　また、ノード２からのポーズ要求フレームの送信後は、ノード２へはフレームが送信されなくなるので、ノード２ではやがてビジー状態が解消し、処理負荷が０となる。
　以上説明したような比較例では、ポーズ要求フレームがＧＤを指定する情報を含まないので、隣接ノード間で送信されるフレームのデータ量が、ポーズ要求フレームを契機として、激しく変動する。例えば、上記で例示したように、ノード４の処理負荷は、図２のデータ量Ｄ２０８（つまり合計１１）から、０へと変動する。また、ノード２の処理負荷も、式（３６）の１２から、０へと変動する。

　つまり、ポーズ要求フレームがＧＤを指定する情報を含まない本比較例では、あるノードが隣接ノードに送信するフレームのデータ量は、ポーズ要求フレームを契機として一気に０になってしまい、いわばオール・オア・ナッシング式に変動する。そして、隣接ノード間で送信されるフレームのデータ量の変動が激しいと、ビジー状態も伝播しやすい。例えば、上記の例ではノード４からノード２へのビジー状態が伝播している。

　それに対して、図１～５を参照して説明した第１実施形態によれば、あるノードが隣接ノードに送信するフレームのデータ量は、ポーズ要求フレームを契機として減りはするものの、必ずゼロになるというわけではない。よって、比較例と比べると、第１実施形態は、ポーズ要求フレームの送信を契機とした、隣接ノード間で送信されるフレームのデータ量の変動が、より緩やかである。したがって、第１実施形態は、ネットワーク１全体での負荷の平均化に有益であり、換言すれば、リソースの有効活用に有益である。

　別の観点から説明すると、第１実施形態によれば、ポーズ要求フレームやポーズ解除フレームを利用したポーズ制御によって輻輳が回避される。そして、第１実施形態によれば、輻輳を回避しつつ、データの破棄を防ぐこと（すなわち、輻輳を回避しつつ、データの中継を継続すること）が実現される。

　図６は、通信装置の機能構成図である。図６の通信装置１００は、各種テーブルを格納するテーブル格納部１０１と、フレームを格納するバッファ１０２を有する。また、通信装置１００は、受信部１０３、受信フレーム制御部１０４、上位層処理部１０５、テーブル制御部１０６、ポート監視部１０７、ポート選択部１０８、タイマ１０９、送信フレーム制御部１１０、および送信部１１１を有する。なお、ポート選択部１０８はポーズ制御部１１２を含む。また、通信装置１００はさらに、ビジー検出部１１３とバッファ使用総量カウンタ１１４を有する。

　テーブル格納部１０１は、ルーティングテーブル１２１、ループ検出テーブル１２２、ポートリンク状態テーブル１２３、ＭＡＣテーブル１２４、ポーズ状態管理テーブル１２５、バッファ使用中ＧＤテーブル１２６、およびポーズ履歴テーブル１２７を格納する。テーブル格納部１０１は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）により実現されてもよいし、ＣＡＭ（Content-Addressable Memory）とＳＲＡＭ（Static Random Access Memory）により実現されてもよい。また、各テーブルの詳細は、図７～１０とともに後述する。

　バッファ１０２は、フレームを格納するために使われる。バッファ１０２は、例えば、ＤＲＡＭである。なお、バッファ１０２の使用総量は、バッファ使用総量カウンタ１１４に記録される。

　なお、通信装置１００は、テーブル格納部１０１とバッファ１０２のほかにも不図示の記憶装置を有する。例えば、通信装置１００は、フラッシュメモリなどの不揮発性記憶装置を有し、不揮発性記憶装置にはノード装置１００自身のノードＩＤ、ノード装置１００自身のＭＡＣアドレスなどが記憶されている。また、通信装置１００がＭＰＵ（MicroProcessing Unit）を含む場合、不揮発性記憶装置には、ＭＰＵが実行するプログラムも記憶される。また、ＤＲＡＭは、バッファ１０２として使われるだけでなく、ＭＰＵがプログラムを実行するときのワーキングエリアとしても使われる。

　また、受信部１０３はフレームを受信し、受信したフレームをバッファ１０２に格納し、受信したフレームのサイズに応じてバッファ使用総量カウンタ１１４のカウント値を増やす。受信部１０３を実現するハードウェアは、例えば、複数の物理ポートと、物理層処理チップ（ＰＨＹチップ）を含む。

　受信フレーム制御部１０４は、受信部１０３により受信されてバッファ１０２に格納されたフレームを、タイプや宛先などの情報に応じて分類する。つまり、受信フレーム制御部１０４は、バッファ１０２からタイプや宛先などの情報を読み出し、読み出した情報に応じた制御を行う。

　例えば、受信部１０３が受信したフレームのＧＤの値が、通信装置１００自身のノードＩＤと一致する場合、受信フレーム制御部１０４は、上位層処理部１０５にフレームのペイロードを処理するよう依頼する。また、受信部１０３でポーズ要求フレームまたはポーズ解除フレームが受信されたとき、受信部１０３は、指定されている内容に応じてルーティングテーブル１２１を制御する。それにより、後に受信されるデータフレームのルーティングに関する方針が影響を受ける。

　そして、上位層処理部１０５は、通信装置１００自身をＧＤとして指定するフレームを処理する。なお「上位層」とは、アドホックフレームが規定される層よりも上位の層という意味であり、アドホックフレームのペイロードに相当する層である。また、上位層処理部１０５は、通信装置１００自身がＧＳとなって送信するフレームのペイロードも作成する。

　つまり、上位層処理部１０５は、通信装置１００宛に送信されてきてバッファ１０２に格納されたフレームのペイロードを読み出して処理したり、通信装置１００から送信するフレームのペイロードをバッファ１０２上に作成したりする。上位層処理部１０５は、バッファ１０２上にデータを作成した場合はバッファ使用総量カウンタ１１４のカウンタ値を増やし、バッファ１０２からデータを削除した場合はバッファ使用総量カウンタ１１４のカウンタ値を減らす。

　また、テーブル制御部１０６は、テーブル格納部１０１に格納される各種テーブルのエントリを作成・更新・削除することで、各種テーブルの内容を制御する。例えばテーブル格納部１０１を実現するのにＣＡＭとＳＲＡＭが使われる場合、テーブル制御部１０６は、ＣＡＭの検索および検索結果として得られたＳＲＡＭのアドレスへのアクセスを行ってもよい。テーブル制御部１０６は、受信フレーム制御部１０４、ポート監視部１０７、ポート選択部１０８、タイマ１０９、および送信フレーム制御部１１０から与えられる制御情報にしたがって各種テーブルの内容を制御する。

　ポート監視部１０７は、通信装置１００が備える複数のポートそれぞれの状態を監視する。そして、ポート監視部１０７は、テーブル制御部１０６を介して、監視結果をポーズ状態管理テーブル１２５に書き込む。

　例えば、受信部１０３と送信部１１１を実現するハードウェアは共通のハードウェアでもよく、受信部１０３と送信部１１１は、複数の物理ポートと、各物理ポートに接続されたＰＨＹチップを含む。なお、ポートとＰＨＹチップは１：１対応でもＮ：１対応でもよい。

　この場合、物理ポートに接続されたＰＨＹチップが、各物理ポートに接続されているリンクがダウンしているか否かを検出してもよく、ポート監視部１０７は、ＰＨＹチップから出力される検出結果を読み取ることでポートの状態を監視してもよい。

　ポート選択部１０８は、テーブル格納部１０１に格納されているテーブルを参照して、フレームの送信先ポートを選択する。選択は、受信フレーム制御部１０４から出力される、フレームのヘッダ情報に応じてなされる。ポート選択部１０８は、テーブル制御部１０６を介してテーブルを参照してもよいし、直接テーブルを参照してもよい。

　タイマ１０９は、各種テーブルにおけるエントリのエージングに利用される時刻情報をテーブル制御部１０６に通知する。なお、エージングのために、各種テーブルのエントリは、有効期間を示すフィールドを含んでもよいが、説明の簡略化のため、図７と１０には有効期間を示すフィールドの図示を省略した。

　送信フレーム制御部１１０は、フレームの送信に関わる各種の制御を行う。例えば、送信フレーム制御部１１０は、バッファ１０２にペイロードが格納されているフレームのヘッダを生成したり、書き換えたりする。具体的には、送信フレーム制御部１１０は、ポート選択部１０８が選択した送信ポートからフレームを送信するための制御を行う。

　送信部１１１は、バッファ１０２からフレームを読み出し、送信フレーム制御部１１０により指定されたポートにフレームを送信する。また、送信部１１１は、送信するフレームのサイズに応じてバッファ使用総量カウンタ１１４のカウント値を減らす。送信部１１１を実現するハードウェアは、受信部１０３と共通でもよく、例えば、複数の物理ポートと、ＰＨＹチップを含む。

　ポーズ制御部１１２は、ポート選択部１０８に含まれる。ポーズ制御部１１２は、ポーズ要求フレームとポーズ解除フレームの送信を制御する。
　ビジー検出部１１３は、バッファ使用総量カウンタ１１４のカウンタ値を参照することで、通信装置１００がビジー状態に陥っているのか否かを判断する。例えば、カウンタ値が所定の閾値以上のとき、ビジー検出部１１３は、「通信装置１００がビジー状態に陥っている」と判断してもよい。また、通信装置１００がＭＰＵを含むとき、ビジー検出部１１３は、さらにＭＰＵの使用率あるいは使用時間を参照して、通信装置１００がビジー状態に陥っているか否かを判断してもよい。ビジー検出部１１３は、判断の結果をポーズ制御部１１２に通知する。

　バッファ使用総量カウンタ１１４は、バッファ１０２の使用総量を示すカウンタである。受信部１０３と上位層処理部１０５は、フレームのデータをバッファ１０２に出力するとき、フレームのサイズに応じてバッファ使用総量カウンタ１１４のカウンタ値を増やす。また、送信部１１１と上位層処理部１０５は、フレームのデータをバッファ１０２から読み出し、データが格納されていた領域を解放するとき、フレームのサイズに応じてバッファ使用総量カウンタ１１４のカウンタ値を減らす。

　受信フレーム制御部１０４、上位層処理部１０５、テーブル制御部１０６、ポート監視部１０７、ポート選択部１０８、タイマ１０９、送信フレーム制御部１１０、ポーズ制御部１１２、およびビジー検出部１１３を実現するハードウェアは実施形態により任意である。例えば、これら各部は、ＦＰＧＡ（Field Programmable Gate Array）により実現されてもよし、ＭＰＵにより実現されてもよいし、ＡＳＩＣ（Application Specific Integrated Circuit）により実現されてもよい。

　図７は、テーブル格納部１０１に格納されるテーブルの例を示す図（その１）である。
　図７のルーティングテーブル１２１は、下記の情報を互いに対応づけるエントリを有する。
　　・フレームのＧＤである「宛先」
　　・通信装置１００が備えるｘ個のポートそれぞれの状態を示すｘ個の「ポート状態」
　　・ｘ個のポートそれぞれについての「カウンタ」
　　・「宛先」が示すＧＤ宛のフレームの転送を、通信装置１００自身が、休止するか否かを示す「ポーズＧＤ」

　図７には、ｎ個のエントリを含むルーティングテーブル１２１が例示されている。後述するように、各エントリは、通信装置１００が受信したフレームに基づいて、ルーティングテーブル１２１に追加されたものである。また、各エントリは、所定の時間アクセスされない場合にはルーティングテーブル１２１から削除される。

　ルーティングテーブル１２１において、例えばｉ番目（１≦ｉ≦ｎ）のエントリでは、宛先ＧＤ_ｉに、ｘ個のポートそれぞれの状態ＲＰ_１ｉ～ＲＰ_ｘｉが対応付けられている。なお、以下、本実施形態の通信装置１００のポートは、送受信の機能を兼ね備えるものとして説明する。

　ここで、宛先ＧＤ_ｉは、通信装置１００と同様の複数の通信装置を含む有線アドホックネットワークにおいて、フレームの宛先となる通信装置を識別する識別情報である。第１実施形態では、各通信装置に、有線アドホックネットワーク内で一意な３バイトのＩＤ（IDentification）が予め割り当てられており、以下では、通信装置に割り当てられたＩＤを「ノードＩＤ」という。宛先ＧＤ_ｉは、具体的にはノードＩＤである。宛先ＧＤ_ｉは、ＭＡＣアドレスなど、通信装置を識別するための他の情報でもよい。

　通信装置１００が、宛先ＧＤ_ｉへのフレームをいずれかのポートで受信し、受信したフレームを他の通信装置へ送信しようとするとき、ポート選択部１０８がルーティングテーブル１２１を参照し、送信ポートを決定する。

　ルーティングテーブル１２１のｉ番目のエントリにおいて、ｊ番目（１≦ｊ≦ｘ）のポートの状態ＲＰ_ｊｉは、「Ｕ」（Used）、「Ｅ」(Empty）、「Ｌ」（Loop）、「Ｐ」（Pause）および「Ｄ」（Down）という５つの状態のうちのいずれかである。

　「Ｕ」は使用状態を示す。具体的には、宛先ＧＤ_ｉというノードＩＤで識別される他の通信装置へのフレームを送信するための、通信装置１００内での送信先ポートとして、ｊ番目のポートが実際に使われている場合、ポート状態ＲＰ_ｊｉは「Ｕ」である。つまり、「Ｕ」状態は、「送信可能」を示す状態の例である。

　「Ｅ」は未使用状態を示す。具体的には、宛先ＧＤ_ｉというノードＩＤで識別される他の通信装置へのフレームを送信するための、通信装置１００内での送信先ポートとして、ｊ番目のポートが使われたことがない場合、ポート状態ＲＰ_ｊｉは「Ｅ」である。つまり、「Ｅ」状態は、「送信可能」を示す状態の例である。

　「Ｌ」はループ状態を示す。具体的には、次の２つの条件がともに成立すると、状態ＲＰ_ｊｉは「Ｌ」に更新される。
　・宛先ＧＤ_ｉというノードＩＤで識別される他の通信装置へのフレームを送信するための、通信装置１００内での送信先ポートとして、かつてｊ番目のポートが使われたことがある。
　・宛先ＧＤ_ｉというノードＩＤで識別される他の通信装置へとｊ番目のポートから送信したフレームが、ネットワーク内でループして通信装置１００自身に戻ってきた（すなわち、通信装置１００で再度受信された）。

　なお、状態ＲＰ_ｊｉが「Ｌ」の場合、ポート状態ＲＰ_ｊｉは、「宛先ＧＤ_ｉへのフレームをポートｊ番目のポートから送信するとループしてしまうので、宛先ＧＤ_ｉへのフレームはポートｊ番目のポートから送信すべきではない」ということを意味している。つまり「Ｌ」状態は、「送信不可」を示す状態の例である。

　「Ｐ」はポーズ状態を示す。具体的には、ｊ番目のポートから（すなわち、ｊ番目のポートを介して接続された不図示の隣接ノード装置から）、「ポーズ要求」を受けている場合、ポート状態ＲＰ_ｊｉは「Ｐ」となる。なお、「ポーズ要求」とは、フレームの集中などによって処理負荷が高まったノード装置が、隣接ノード装置に対して、自ノード装置へのフレームの送信を一定期間「休止」（pause）するよう求める要求である。ポーズ要求は、具体的には、図１～５に関連して説明したポーズ要求フレームとして送信される。

　通信装置１００は、ｊ番目のポートでポーズ要求フレームを受信したとき、ｊ番目のポートに接続されている隣接ノードがビジー状態であると認識する。
　ここで、図１～５とともに説明したように、ポーズ要求フレームにはＧＤが指定されている。さらに、図１～５に関する説明では省略したが、ポーズ要求フレームには、時間の長さを示す値（以下「カウンタ」という）も指定されている。

　よって、ｊ番目のポートでポーズ要求フレームを受信した通信装置１００は、カウンタにより指定されている期間中は、ポーズ要求フレームでＧＤとして指定されているノード宛のフレームを、ポーズ要求フレームを送信してきた隣接ノード装置には送信しない。つまり、通信装置１００のポーズ制御部１１２は、「ポーズ要求フレームでＧＤとして指定されているノード宛のフレームを、ポーズ要求フレームを送信してきた隣接ノード装置に送信すべきではない」と認識する。

　そして、受信フレーム制御部１０４は、上記認識に基づいて、ルーティングテーブル１２１においてｊ番目のポートに対応する状態ＲＰ_ｊｉを「Ｐ」に設定する。以上から明らかなとおり、「Ｐ」状態は「送信不可」を示す状態の例である。

　「Ｄ」はリンクダウン状態を示す。例えば、ｊ番目のポートに接続されたケーブルが物理的に切断されている場合など、ケーブルを搬送される信号をｊ番目のポートにおいて電気的に検出することができない場合、状態ＲＰ_ｊｉは「Ｄ」となる。「Ｄ」状態も、「送信不可」を示す状態の例である。

　なお、「Ｄ」状態は、フレームの宛先とは独立した概念である。しかし、第１実施形態では、ある１つのポート（例えばｊ番目のポート）の状態ＲＰ_ｊ１～ＲＰ_ｊｎのうち一部が「Ｄ」となり、一部が「Ｄ」以外となることもある。なぜなら、後述のように第１実施形態では、ルーティングテーブル１２１のエントリの更新は、フレーム受信を契機として行われるので、各エントリの更新のタイミングに時差があるからである。

　図８は、ルーティングテーブル１２１でのポート状態の状態遷移図である。ルーティングテーブル１２１のポート状態には、前述のとおり、「Ｅ（Empty）」状態、「Ｕ（Used）」状態、「Ｐ（Pause）」状態、「Ｌ（Loop）」状態、「Ｄ（Down）」状態がある。ポート状態の初期状態は「Ｅ」状態である。

　なお、太線で囲った「Ｅ」状態と「Ｕ」状態は、このポート状態に対応するポートが送信先として使用可能であることを示す。それ以外の「Ｐ」状態と「Ｌ」状態と「Ｄ」状態は、このポート状態に対応するポートが送信先として使用不能であることを示す。

　また、ポーズ要求フレームの受信を契機として、ポート状態は「Ｅ」状態から「Ｐ」状態へ遷移する（後述の図１４のステップＳ１０５を参照）。なお、他の「Ｕ」状態、「Ｌ」状態、「Ｄ」状態からも、ポーズ要求フレームの受信を契機として、ポート状態が「Ｐ」状態へ遷移することがある（後述の図１４のステップＳ１０５を参照）。

　逆に、ポーズ解除フレームが受信されると、受信を契機として、ポート状態が「Ｐ」状態から「Ｅ」状態に遷移する（後述の図１４のステップＳ１０６を参照）。さらに、ポーズ要求フレームで指定された時間が経過した場合も、ポート状態が「Ｐ」状態から「Ｅ」状態に遷移する（後述の図３５のステップＳ１８０６を参照）。

　また、あるＧＤに対応するエントリのあるポートのポート状態が「Ｅ」状態であり、このＧＤに対してこのポートがＬＤとして選択されたとする。すると、その選択を契機として、ポート状態は「Ｅ」状態から「Ｕ」状態へ遷移する（後述の図２０のステップＳ５１３、図２１のステップＳ５２９、図２４のステップＳ７１４を参照）。

　また、あるポートでリンクダウン状態が検出された後、フレームのルーティングが生じると、「Ｅ」状態、「Ｕ」状態、「Ｐ」状態、「Ｌ」状態のいずれの状態からも、「Ｄ」状態に遷移する可能性がある（後述の図２０のステップＳ５１０、図２１のステップＳ５２５、図２４のステップＳ７１１を参照）。逆に、あるポートがリンクダウン状態から復旧した後で、フレームのルーティングが生じると、「Ｄ」状態からは「Ｅ」状態に遷移する（後述の図２０のステップＳ５１０、図２１のステップＳ５２５、図２４のステップＳ７１１を参照）。

　また、あるＧＤに対応するエントリのあるポートのポート状態が「Ｕ」状態の場合に、ループの発生が検出され、フレームのルーティングが行われるとする。このとき、ポート状態は「Ｕ」状態から「Ｌ」状態へ遷移する（後述の図２１のステップＳ５２６を参照）。

　さて、ここで図７のルーティングテーブル１２１の説明に戻る。宛先ＧＤ_ｉと対応するエントリにおいて、ｊ番目のポートに対応するカウンタＣＴ_ｊｉは、ｊ番目のポートのポート状態が「Ｐ」状態の場合のみ意味を持つ。

　カウンタＣＴ_ｊｉは、宛先ＧＤ_ｉを指定するポーズ要求フレームを受信部１０３がｊ番目のポートで受信した場合に、受信フレーム制御部１０４により設定される値である。具体的には、ポーズ要求フレームに含まれるカウンタの値がルーティングテーブル１２１のカウンタＣＴ_ｊｉにコピーされる。

　そして、カウンタＣＴ_ｊｉは、定期的にカウントダウンされる。カウンタＣＴ_ｊｉが０になると、通信装置１００は、ポーズ要求フレームの送信元の隣接ノードがビジー状態から回復したと見なす。具体的には、カウンタＣＴ_ｊｉが０になると、テーブル制御部１０６が、対応するポート状態ＲＰ_ｊｉを通常状態（すなわち「Ｅ」状態）に設定しなおす。

　また、ルーティングテーブル１２１において宛先ＧＤ_ｉに対応するポーズＧＤ・ＰＧＤ_ｉは、通信装置１００自身が隣接ノードに対して、宛先ＧＤ_ｉを指定したポーズ要求フレームを送信した場合に「１」である。「１」は「選択中」を示す。

　通信装置１００が、宛先ＧＤ_ｉを指定したポーズ要求フレームを送信していない場合、ポーズＧＤ・ＰＧＤ_ｉは、「０」である。「０」は「非選択」を示す。また、通信装置１００が、宛先ＧＤ_ｉを指定したポーズ要求フレームを送信した後、ビジー状態から復旧すると、ポーズＧＤ・ＰＧＤ_ｉは、「１」から「０」に戻る。

　なお、テーブル制御部１０６とタイマ１０９は協働して、ルーティングテーブル１２１に対するエージング処理を定期的に行う。具体的には、下記３つの時点のうち最新の時点から所定時間以上が経過した古いエントリを、テーブル制御部１０６は、ルーティングテーブル１２１から削除する。
　・エントリが作成された時点
　・エントリが最後に更新された時点
　・エントリが検索条件に合致して見出された最後の時点

　また、図７のループ検出テーブル１２２は、「送信元」と「ＦＩＤ（Frame IDentification）」の組に、「ＯＬＳ（Original Local Source）ポート」と各ポートの状態を示すｘ個の「ポート状態」を対応付けて記憶するテーブルである。

　図７には、ｍ個のエントリを含むループ検出テーブル１２２が例示されている。後述するように、各エントリは、通信装置１００が受信したフレームに基づいて、ループ検出テーブル１２２に追加される。また、各エントリは、所定の時間が経過するとループ検出テーブル１２２から削除される。

　ループ検出テーブル１２２において、例えばｉ番目（１≦ｉ≦ｍ）のエントリでは、送信元ＧＳ_ｉとＦＩＤ_ｉの組に、ＯＬＳポートＯＬＳＰ_ｉと、各ポートのポート状態ＬＰ_１ｉ～ＬＰ_ｘｉとが対応付けられている。

　ここで、送信元ＧＳ_ｉは、通信装置１００と同様の複数の通信装置を含む有線アドホックネットワークにおいて、フレームの送信元である通信装置を識別する識別情報であり、具体的にはノードＩＤである。また、ＦＩＤ_ｉは、送信元通信装置（すなわちノードＩＤがＧＳ_ｉの通信装置）が、送信するフレームに割り当てた、フレームを一意に識別する識別情報である。ＦＩＤ_ｉは、例えばシーケンス番号でもよい。

　通信装置１００が、いずれかのポートでフレームを受信し、受信したフレームを送信しようとするとき、ポート選択部１０８は、ルーティングテーブル１２１だけでなくループ検出テーブル１２２も参照する。そして、ポート選択部１０８は、ループ検出テーブル１２２にも基づいて、受信したフレームを送信するポートを選択する。

　ループ検出テーブル１２２のｉ番目のエントリにおけるＯＬＳポートＯＬＳＰ_ｉは、ｉ番目のエントリを作成する契機となるフレームが通信装置１００において受信されたときに、当該フレームを受信したポートを示す。

　具体的には、送信元通信装置（つまりＧＳ_ｉというノードＩＤで識別される通信装置）においてＦＩＤ_ｉというＦＩＤが割り当てられたフレームが、通信装置１００のｒ番目のポート（１≦ｒ≦ｘ）で受信され、ループ検出テーブル１２２にこの送信元通信装置（ＧＳ_ｉ）とＦＩＤ（ＦＩＤ_ｉ）のエントリがなかった場合、ＯＬＳポートＯＬＳＰ_ｉとしてｒが登録される。そして、ｒ番目のポートのポート状態ＬＰ_ｒｉは、「Ｏ（Original Local Source）」状態に設定される。

　なお、ＯＬＳポートＯＬＳＰ_ｉは、ｘ個のポート状態ＬＰ_ｊｉのうち、いずれが「Ｏ」状態であるのかを示す。本実施形態では、どのポートが「Ｏ」状態なのかを検索する時間を省くため、ＯＬＳポートのフィールドがループ検出テーブル１２２に設けられているが、ＯＬＳポートのフィールドはなくてもよい。

　ループ検出テーブル１２２のポート状態ＬＰ_ｊｉには、上記「Ｏ」状態のほかに、さらに、「Ｅ（Empty）」状態、「Ｕ（Used）」状態、および「Ｌ（Loop）」状態がある。
　「Ｕ」状態は、ルーティングテーブル１２１に関して説明したのと同様に使用状態を示す。ループ検出テーブル１２２においては、具体的には、次の２つの条件が成立するとき状態ＬＰ_ｊｉは「Ｕ」である。
　・送信元ＧＳ_ｉというノードＩＤで識別される送信元通信装置においてＦＩＤ_ｉというＦＩＤが割り当てられたフレームを、かつて通信装置１００が送信したことがある。
　・その送信の際に、通信装置１００内での送信先ポートとしてｊ番目のポートが使われた。

　「Ｅ」状態は、ルーティングテーブル１２１に関して説明したのと同様に未使用状態を示し、ループ検出テーブル１２２においては、具体的には、次のような意味である。すなわち、送信元ＧＳ_ｉというノードＩＤで識別される送信元通信装置においてＦＩＤ_ｉというＦＩＤが割り当てられたフレームをかつて通信装置１００が送信したときの、送信先ポートがｊ番目のポートではなく、かつｊ≠ｒならば、状態ＬＰ_ｊｉは「Ｅ」である。

　そして、「Ｌ」状態は、ルーティングテーブル１２１に関して説明したのと同様にループ状態を示す。ループ検出テーブル１２２においては、具体的には、次の２つの条件が成立するとき状態ＬＰ_ｊｉが「Ｌ」となる。
　・送信元ＧＳ_ｉというノードＩＤで識別される送信元通信装置においてＦＩＤ_ｉというＦＩＤが割り当てられたフレームを、ｊ番目のポートを送信先ポートとして通信装置１００が送信したことがある。
　・送信後に当該フレームが通信装置１００で受信された。

　なお、ルーティングテーブル１２１においては、「Ｕ」状態と「Ｅ」状態は「送信可能である」つまり「送信先ポートとして選択可能である」という意味では共通である。しかし、ループ検出テーブル１２２では、「Ｕ」状態と「Ｅ」状態は次のように峻別される。すなわち、ループ検出テーブル１２２における「Ｕ」状態は、仮に今後ループが検出されることがあれば、「送信不可」を意味する「Ｌ」状態に遷移させる対象を示している。それに対し、ループ検出テーブル１２２における「Ｅ」状態は、仮に今後ループが検出されることがあっても、当該送信の時点では依然として送信先ポートとして選択可能であることを示す。

　なお、テーブル制御部１０６とタイマ１０９は協働して、ループ検出テーブル１２２に対するエージング処理を定期的に行う。具体的には、作成から所定時間以上が経過した古いエントリを、テーブル制御部１０６は、ルーティングテーブル１２１から削除する。

　さて、図９は、ループ検出テーブルでのポート状態の状態遷移図である。ループ検出テーブル１２２のポート状態には、前述のとおり、「Ｅ（Empty）」状態、「Ｕ（Used）」状態、「Ｌ（Loop）」状態、「Ｏ（Original Local Source）」状態がある。

　初期状態は、ポートに応じて異なる（後述の図２０のステップＳ５１４と図２４のステップＳ７１５を参照）。すなわち、あるＧＳとＦＩＤの組により識別されるエントリにおいて、このＧＳから送信された、このＦＩＤを持つフレームを最初に受信したポートのポート状態は、「Ｏ」状態に設定される。また、このＧＳから送信された、このＦＩＤを持つフレームを最初に受信したときに、送信先として選択されたポートのポート状態は、「Ｕ」状態に設定される。そして、その他のポートは、「Ｅ」状態に設定される。

　なお、「Ｏ」状態からは他の状態に遷移しない。
　また、あるＧＳとＦＩＤの組により識別されるエントリにおいて、あるポートのポート状態が「Ｅ」状態だとする。このとき、このＦＩＤを持つこのＧＳからのフレームに対して、このポートがＬＤとして選び直されると、ポート状態は「Ｅ」状態から「Ｕ」状態に遷移する（後述の図２１のステップＳ５３０を参照）。そして、ループ発生が検出されると、「Ｕ］状態から「Ｌ」状態への遷移が起こる（後述の図２１のステップＳ５２３を参照）。なお、「Ｌ」状態からは他の状態に遷移しない。

　ここで、図７の他のテーブルについての説明に戻る。図７のポートリンク状態テーブル１２３は、ｘ個のポートのそれぞれに対応するｘ個のエントリを有する。例えば、ｉ番目（１≦ｉ≦ｘ）のポート対応するエントリでは、ｉ番目のポートを識別するポートＩＤ・ＰＩＤ_ｉと、ｉ番目のポートに接続されたリンクが通信可能な状態であるか否かを示すリンク状態Ｌ_ｉが対応付けられている。

　なお、ｉ番目のポートに接続されたリンクが通信可能な状態であれば、リンク状態Ｌ_ｉの値は「Ｃ」（Connected）であり、ｉ番目のポートに接続されたリンクがダウンしており通信不能な状態であれば、リンク状態Ｌ_ｉの値は「Ｄ」（Down）である。リンク状態Ｌ_ｉは２値なので、１ビットで表すことができる。

　なお、ポートリンク状態テーブル１２３は、次のようにして定期的に更新される。すなわち、ポート監視部１０７は、ｉ番目（１≦ｉ≦ｘ）のポートに注目し、ｉ番目のポートが接続状態であるか否かを判断する。例えば、ｉ番目のポートに接続されたケーブルが通信可能な状態であるかそれともリンクダウン状態であるかを示すＰＨＹチップの出力に基づいて、ポート監視部１０７は判断を行う。

　もし、ｉ番目のポートに接続されたケーブルが通信可能な状態であり、ｉ番目のポートがケーブルを介して隣接通信装置と有効に接続された状態であれば、ポート監視部１０７は、テーブル制御部１０６を介して、ｉ番目のポートのリンク状態Ｌ_ｉを「Ｃ」状態に設定する。

　逆に、ｉ番目のポート接続されたケーブルがリンクダウン状態であれば、ポート監視部１０７は、テーブル制御部１０６を介して、ｉ番目のポートのリンク状態Ｌ_ｉを「Ｄ」状態に設定する。
　以上の処理を、ポート監視部１０７は、各ｉ（１≦ｉ≦ｘ）について行う。それにより、ポートリンク状態テーブル１２３は、定期的に更新される。

　続いて、図７のＭＡＣテーブル１２４について説明する。ＭＡＣテーブル１２４の１つのエントリは、有線アドホックネットワーク内の１つの通信装置に対応する。図７には、ｂ個のエントリを有するＭＡＣテーブル１２４が例示されている。例えば、ＭＡＣテーブル１２４のｉ番目（１≦ｉ≦ｂ）のエントリでは、次の２つの情報が対応付けられている。
　・有線アドホックネットワーク内のある通信装置に接続された外部機器（例えばＰＣやセンサなど）のＭＡＣアドレスＭＡＣ_ｉ
　・ＭＡＣアドレスＭＡＣ_ｉを有する上記外部機器が接続されている上記通信装置に割り当てられている、有線アドホックネットワーク内で一意なノードＩＤであるＮＩＤ_ｉ
　通信装置１００は、アドホックフレーム４００（図１３を参照）を受信すると、ＭＡＣ－ＳＡ４２２とＧＳ４１２（図１３を参照）の組を学習する。

　すなわち、テーブル制御部１０６は、受信したアドホックフレーム４００におけるＭＡＣ－ＳＡ４２２とＧＳ４１２の値に合致するエントリがＭＡＣテーブル１２４に存在するか否かを判断する。そして、もしＭＡＣ－ＳＡ４２２とＧＳ４１２の値に合致するエントリが存在しなければ、テーブル制御部１０６は、ＭＡＣ－ＳＡ４２２の値とＧＳ４１２の値を対応付ける新たなエントリを作成して、ＭＡＣテーブル１２４に追加する。

　また、通信装置１００は、図６には不図示の汎用ＬＡＮ（Local Area Network）ポートを備えてもよい。通信装置１００は、汎用ＬＡＮポートを介して接続された第１の外部機器からイーサネットフレーム４２０（図１３を参照）を受信すると、ＭＡＣ－ＤＡ４２１（図１３を参照）の値を検索キーにしてＭＡＣテーブル１２４を検索する。

　検索の結果エントリが見つかれば、通信装置１００は、見つかったエントリに含まれるノードＩＤの値をＧＤ４１１に設定したアドホックヘッダ４１０を作成して、イーサネットフレーム４２０の前に付加する。つまり、ＭＡＣ－ＤＡ４２１の値で識別される第２の外部機器と接続された、有線アドホックネットワーク内の他の通信装置のノードＩＤを、通信装置１００はＧＤ４１１に設定する。

　例えば、後述の図１１の例において、ＰＣ２０３からＰＣ２０５へフレームが送信されるとき、有線アドホックネットワーク２００において送信経路上にある通信装置１００ｂは、次のようにしてＭＡＣテーブル１２４の学習を行う。

　上記の例では、通信装置１００ｂが通信装置１００ｃから受信したアドホックフレーム４００において、ＭＡＣ－ＳＡ４２２にはＰＣ２０３のＭＡＣアドレスが指定されており、ＧＳ４１２には通信装置１００ｃのノードＩＤが指定されている。よって、通信装置１００ｂは、ＰＣ２０３のＭＡＣアドレスと通信装置１００ｃのノードＩＤの対応付けを学習し、必要に応じてＭＡＣテーブル１２４へのエントリ追加を行う。

　また、この学習の後に、例えばＰＣ２０１からＬ２ＳＷ２０２を介して、ＰＣ２０５宛の新たなイーサネットフレーム４２０を通信装置１００ｂが受信したとする。すると、通信装置１００ｂは、当該新たなイーサネットフレーム４２０のＭＡＣ－ＤＡ４２１の値を検索キーにしてＭＡＣテーブル１２４を検索する。

　すなわち、通信装置１００ｂは、ＰＣ２０５のＭＡＣアドレスを検索キーにしてＭＡＣテーブル１２４を検索する。その結果、通信装置１００ｂは、ＰＣ２０５と接続された有線アドホックネットワーク２００内の通信装置１００ｇのノードＩＤを得る。よって、通信装置１００ｂは、通信装置１００ｇのノードＩＤをＧＤ４１１に指定したアドホックヘッダ４１０を生成して上記の新たなイーサネットフレーム４２０の前に付与することで、新たなアドホックフレーム４００を生成する。そして、通信装置１００ｂは、当該新たなアドホックフレーム４００を送信する。

　なお、通信装置１００ｃは、ＰＣ２０５のＭＡＣアドレスと通信装置１００ｇのノードＩＤの対応付けを学習する前に、ＰＣ２０５宛のイーサネットフレーム４２０をＰＣ２０３から受信した場合、例えば次のように動作してもよい。

　すなわち、ブロードキャストアドレスを示す所定の値をＧＤ４１１に指定したアドホックヘッダ４１０を有する、ノードＩＤ問い合わせ用のアドホックフレームを、通信装置１００ｃは有線アドホックネットワーク２００内にブロードキャストしてもよい。ノードＩＤ問い合わせ用のアドホックフレームのペイロードには、ＰＣ２０５のＭＡＣアドレスが含まれる。

　そして、有線アドホックネットワーク２００内をブロードキャストされたフレームにより問い合わせを受けた通信装置１００ｇは、通信装置１００ｃに返信する。つまり、通信装置１００ｇは、ＰＣ２０５のＭＡＣアドレスと通信装置１００ｇのノードＩＤの対応付けを通知するための、特殊な制御用のアドホックフレームを返信する。その結果、通信装置１００ｃは、返信されたアドホックフレームから、ＰＣ２０５のＭＡＣアドレスと通信装置１００ｇのノードＩＤの対応付けを学習し、ＭＡＣテーブル１２４にエントリを追加する。

　さて、図１０は、テーブル格納部に格納されるテーブルの例を示す図（その２）である。
　図１０のポーズ状態管理テーブル１２５は、１つのエントリのみを持つ。ポーズ状態管理テーブル１２５は、ビジー検出部１１３からの出力に応じて、ポーズ制御部１１２により管理される。ポーズ状態管理テーブル１２５は、ノード装置１００自身から隣接ノード装置へのポーズ要求フレームおよびポーズ解除フレームの送信の制御に利用される。

　図１０に示すように、ポーズ状態管理テーブル１２５は、ポーズ状態ＳＳと、カウンタＳＣｏｕｎｔと、ポーズ開始時刻ＳｔａｒｔＴｉｍｅとを含む。
　ポーズ状態ＳＳの値は、ノード装置１００自身がビジー状態に陥っているとき「Ｐ」（Pause）であり、ノード装置１００自身がビジー状態ではないとき「Ｎ」（Normal）である。例えば、ビジー検出部１１３は、バッファ使用総量カウンタ１１４のカウンタ値を監視し、カウンタ値が所定の閾値を超えていれば、「ノード装置１００自身がビジー状態である」と判定してもよく、このとき、ポーズ制御部１１２がポーズ状態ＳＳの値を「Ｐ」に設定してもよい。

　カウンタＳＣｏｕｎｔには、ノード装置１００自身から他のノード装置へとポーズ要求を送信するときに、ポーズフレームにカウンタとして指定する値が設定される。すなわち、カウンタＳＣｏｕｎｔには、隣接ノード装置に対して「フレームの送信を休止してほしい」とノード装置１００自身が要求する期間の長さが設定される。

　ポーズ制御部１１２は、カウンタＳＣｏｕｎｔの値を任意に設定することができる。実施形態によって、ポーズ制御部１１２は、予め決められた定数値をカウンタＳＣｏｕｎｔに設定してもよいし、バッファ１０２の使用率に応じた可変パラメタの値をカウンタＳＣｏｕｎｔに設定してもよい。

　ポーズ開始時刻ＳｔａｒｔＴｉｍｅは、ノード装置１００自身が隣接ノード装置へポーズ要求フレームを送信した時刻が設定される。
　また、図１０のバッファ使用中ＧＤテーブル１２６は、バッファ１０２の使用量をＧＤごとに表す情報を格納するテーブルである。図１０には、Ｎ個のエントリを含むバッファ使用中ＧＤテーブル１２６が例示されている。バッファ使用中ＧＤテーブル１２６のｉ（１≦ｉ≦Ｎ）番目のエントリでは、ノードＩＤであるＧＤ_ｉと、ＧＤ_ｉがＧＤとして指定されているフレームによってバッファ１０２がどれほど使用されているかを表すバッファカウンタＢＣ_ｉが対応づけられている。

　バッファカウンタＢＣ_ｉは、資源（例えばバッファ１０２）の使用状況を表す計量値の一例である。バッファカウンタＢＣ_ｉは、例えば、バッファ使用量を所定の単位（１バイトまたは６４バイトなど）で表した数値でもよいし、ノードＧＤ_ｉ宛のフレームのための記憶領域がバッファ１０２全体の記憶容量に占める割合を示す数値でもよい。資源の使用状況としては、他にも、ＭＰＵの使用率などが使われてもよい。つまり、バッファカウンタＢＣ_ｉの代わりに（あるいは、バッファカウンタＢＣ_ｉとあわせて）、ノードＧＤ_ｉ宛のフレームを処理するスレッドのＭＰＵ使用率が使われてもよい。

　バッファカウンタＢＣ_ｉの値は、ＧＤ_ｉ宛のフレームを受信部１０３が受信すると、受信フレーム制御部１０４により、テーブル制御部１０６を介して増やされる。また、バッファカウンタＢＣ_ｉは、ＧＤ_ｉ宛のフレームを送信部１１１が送信するとき、例えば送信フレーム制御部１１０により、テーブル制御部１０６を介して減らされる。

　なお、バッファ使用中ＧＤテーブル１２６の代わりに、履歴情報を含むバッファ使用中ＧＤテーブル１２６ａが使われてもよい。バッファ使用中ＧＤテーブル１２６ａでは、各ＧＤ_ｉにＭ個のバッファカウンタＢＣ_１ｉ～ＢＣ_Ｍｉが対応づけられている。

　テーブル制御部１０６は、Ｍ個のバッファカウンタＢＣ_１ｉ～ＢＣ_Ｍｉのうちのいずれが最新の情報を示すのかを表すポインタを有し、例えば、Ｍ＝４でポインタが２を示す場合、バッファカウンタＢＣ_２ｉが最新の情報を示し、バッファカウンタＢＣ_３ｉが最古の履歴を示す。つまり、新しいものから順に、バッファカウンタＢＣ_２ｉ、ＢＣ_１ｉ、ＢＣ_４ｉ、ＢＣ_３ｉである。テーブル制御部１０６は、定期的にポインタの示す値を更新する。

　例えば、テーブル制御部１０６が、ポインタの示す値を２から３に変える場合、テーブル制御部１０６は、１≦ｉ≦Ｎなる各ｉについて、現在のバッファカウンタＢＣ_２ｉの値をバッファカウンタＢＣ_３ｉにコピーして、バッファカウンタＢＣ_３ｉを初期化する。

　また、バッファ使用中ＧＤテーブル１２６ａが使われる場合、受信フレーム制御部１０４は、フレームの受信時に、テーブル制御部１０６を介して、ポインタが示す最新のバッファカウンタの値を増やす。同様に、例えば送信フレーム制御部１１０は、フレームの送信時に、テーブル制御部１０６を介して、ポインタが示す最新のバッファカウンタの値を減らす。

　以上のようなバッファ使用中ＧＤテーブル１２６ａによれば、どのノード宛のフレームに関する処理負荷が高いのかについて、経時的な変化をポーズ制御部１１２が認識することができる。したがって、ポーズ制御部１１２は、経時的な変化に応じたポーズ制御を行なうこともできる。例えば、ポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６ａから、処理負荷が高まる傾向にあるＧＤを認識し、認識したＧＤを指定するポーズ要求フレームを生成してもよい。

　また、図１０には、ポーズ履歴テーブル１２７も例示されている。ポーズ履歴テーブル１２７は、実施形態によっては省略可能である。しかし、ポーズ要求で指定するＧＤの対象から除外することが好ましいＧＤをポーズ制御部１１２が認識するために、本実施形態ではポーズ履歴テーブル１２７が用いられる。

　図１０のポーズ履歴テーブル１２７は、Ｐ個のエントリを含む。各エントリでは、ＧＤを識別するノードＩＤであるＧＤ_ｉが、そのＧＤ_ｉを指定するポーズ要求フレームを通信装置１００が送信した時刻ＰＴ_ｉと対応づけられる。

　ポーズ制御部１１２は、ポーズ要求フレームの送信のたびにポーズ履歴テーブル１２７におけるエントリの追加または更新を行う。また、タイマ１０９による定期的に発生するトリガに応じて、テーブル制御部１０６は、エージング処理を行い、古いエントリをポーズ履歴テーブル１２７から削除する。

　続いて、図６と同様のコンポーネントを有する複数の通信装置を含むネットワークにおける、分散協調動作の概要について、フレーム形式の例とあわせて、図１１～図１３を参照しながら説明する。

　図１１は、第１実施形態の通信装置が適用されるネットワークの例を示す図である。
　図１１の有線アドホックネットワーク２００は、複数の通信装置１００ａ～１００ｉを含む。有線アドホックネットワーク２００において通信装置１００ａ～１００ｉは、ケーブル（例えば、銅ケーブルなどの金属線ケーブル、または光ファイバケーブル）により、物理的にはメッシュ状（換言すれば格子状）に接続されている。

　もちろん、有線アドホックネットワークにおける物理的な接続トポロジは、実施形態に応じて任意であり、必ずしもメッシュ状でなくてもよい。
　また、通信装置１００ａ～１００ｉの各々は、図６と同様のコンポーネントを有する。なお、上記の例（例えば図７のルーティングテーブル１２１とループ検出テーブル１２２でのポート状態の列の数を参照）では、通信装置１００がｘ個のポートを有しているが、図１１には、具体的にはｘ＝４の例を示してある。

　例えば、通信装置１００ａは、４つのポート１３１ａ～１３４ａを有する。他の通信装置１００ｂ～１００ｉについても同様である。また、互いに同様のコンポーネントには、「１３１ａ」、「１３１ｂ」などのように、「ａ」や「ｂ」などの添え字を除いて同じ参照符号を割り当て、詳しい説明を省略することがある。

　図１１に示すメッシュ状の物理的なトポロジは、具体的には、次のようなケーブル配線により実現されている。
　・通信装置１００ａと１００ｄは、ポート１３１ａと１３１ｄの間のリンク２１５により接続されている。

　・通信装置１００ａと１００ｂは、ポート１３４ａと１３１ｂの間のリンク２１６により接続されている。
　・通信装置１００ｂと１００ｅは、ポート１３２ｂと１３２ｅの間のリンク２１７により接続されている。

　・通信装置１００ｂと１００ｃは、ポート１３４ｂと１３１ｃの間のリンク２１８により接続されている。
　・通信装置１００ｃと１００ｆは、ポート１３３ｃと１３３ｆの間のリンク２１９により接続されている。

　・通信装置１００ｄと１００ｇは、ポート１３２ｄと１３２ｇの間のリンク２２１により接続されている。
　・通信装置１００ｄと１００ｅは、ポート１３４ｄと１３１ｅの間のリンク２２２により接続されている。

　・通信装置１００ｅと１００ｈは、ポート１３３ｅと１３３ｈの間のリンク２２３により接続されている。
　・通信装置１００ｅと１００ｆは、ポート１３４ｅと１３１ｆの間のリンク２２４により接続されている。

　・通信装置１００ｆと１００ｉは、ポート１３４ｆと１３４ｉの間のリンク２２５により接続されている。
　・通信装置１００ｇと１００ｈは、ポート１３４ｇと１３１ｈの間のリンク２２６により接続されている。

　・通信装置１００ｈと１００ｉは、ポート１３４ｈと１３１ｉの間のリンク２２７により接続されている。
　もちろん、実施形態に応じて、図１１に例示した以外の組み合せのポート間をケーブルで接続することで図１１と等価なメッシュトポロジを実現することも可能である。

　ところで、図１１の例では、有線アドホックネットワーク２００は孤立したネットワークではなく、ＬＡＮやＷＡＮ（Wide Area Network）などの他のネットワーク（以下「外部ネットワーク」という）とも接続される。

　具体的には、図１１の通信装置１００ａ～１００ｉは、図６に示したコンポーネントだけでなく、有線アドホックネットワーク２００と外部ネットワークとの接続インタフェイスとして、さらにそれぞれ汎用ＬＡＮポート１３５ａ～１３５ｉを有する。図１１では、汎用ＬＡＮポート１３５ａ～１３５ｉを斜線で示して、有線アドホックネットワークポート１３１ａ～１３４ｉとは区別してある。なお、図１１における汎用ＬＡＮポート１３５ａ～１３５ｉは有線ＬＡＮポートであるが、実施形態によっては無線ＬＡＮインタフェイスを代わりに用いることもできる。

　例えば、図１１の例では、有線アドホックネットワーク２００は次のようにして外部ネットワークと接続される。すなわち、リンク２１１を介してＰＣ（Personal Computer）２０１と接続されたＬ２ＳＷ（Layer 2 Switch）２０２が、通信装置１００ａと１００ｂそれぞれの汎用ＬＡＮポート１３５ａと１３５ｂに、それぞれリンク２１２と２１３を介して接続されている。また、ＰＣ２０３、２０５、２０６が、通信装置１００ｃ、１００ｇ、１００ｈそれぞれの汎用ＬＡＮポート１３５ｃ、１３５ｇ、１３５ｈに、それぞれリンク２１４、２２８、２２９を介して接続されている。

　なお、Ｌ２ＳＷ２０２は、不図示のルータや、不図示の他のＰＣとさらに接続されていてもよい。また、ＰＣ２０３、２０５、および２０６も、不図示の他の外部ネットワークに接続されていてもよい。

　また、説明の便宜上、図１１には９個の通信装置１００ａ～１００ｉを含む有線アドホックネットワーク２００を例示したが、実施形態によっては、例えば数千個～数十万個といった多数の通信装置を有線アドホックネットワークが含んでいてもよい。

　例えば、いたる所に配置された多数のセンサから様々な情報を収集するためのネットワークであるセンサネットワークに、第１実施形態の有線アドホックネットワークが適用されてもよい。その場合、多数のセンサに対応して、有線アドホックネットワークは、数千個～数十万個のオーダの、多数の通信装置を含んでもよい。センサネットワークでは、例えば、画像センサ、温度センサ、湿度センサ、圧力センサ、加速度センサなど、任意の種類のセンサが利用される。

　図１１も、第１実施形態による有線アドホックネットワークの、センサネットワークへの適用例の１つを示している。すなわち、図１１において通信装置１００ｅと１００ｉそれぞれの汎用ＬＡＮポート１３５ｅと１３５ｉには、ＬＡＮインタフェイスを備えたセンサ２０４と２０７が、それぞれリンク２２０と２３０を介して接続されている。センサ２０４と２０７は、感知した結果を示すデータを、ＬＡＮインタフェイスを介してイーサネットフレームとして出力する。これらのセンサ２０４と２０７の種類は任意である。

　図１１に示すような第１実施形態による有線アドホックネットワークを利用すると、無線通信では通信困難な環境でも有線通信ならば通信可能な場合が多いため、過酷な環境においてもセンサネットワークを構築することが可能となる。

　例えば、畑や崖などの土中、水田や河川や海などの水中、建物の壁や柱などの構造物中などに、センサと、汎用ＬＡＮポートを介して当該センサに接続された通信装置とが埋め込まれてもよい。そのような場合でも、通信装置は有線接続によって他の通信装置と確実に通信することが可能である。よって、第１実施形態による有線アドホックネットワークを利用すると、土中、水中、構造物中などの、無線通信が困難な環境においても、センサネットワークを構築することが可能である。

　以上、図１１におけるネットワーク構成を説明したので、続いて、図１１の有線アドホックネットワーク２００における分散協調動作の概要を説明する。なお、個々の通信装置１００ａ～１００ｉの動作の詳細はフローチャートとともに後述する。

　以下では、ＰＣ２０３がフレームをＰＣ２０５に送信する場合を例にして、障害発生時の、有線アドホックネットワーク２００におけるフレーム送信経路の切り替えについて説明する。

　ＰＣ２０３がリンク２１４を介してイーサネットフレームを送信すると、通信装置１００ｃは、イーサネットフレームを受信し、受信したイーサネットフレームにアドホックヘッダを付加する。

　そして、各通信装置が後述のフローチャートにしたがって動作することで実現される自律的分散協調により、アドホックフレームは、有線アドホックネットワーク２００において、通信装置１００ｃから通信装置１００ｇへと送信されていく。そして、通信装置１００ｇがアドホックフレームからアドホックヘッダを取り除く。その結果得られたイーサネットフレームは、通信装置１００ｇからリンク２２８を介してＰＣ２０５へと出力される。

　図１１に示した各リンクが正常である場合、通信装置１００ｃから通信装置１００ｇへの送信経路として、例えば、リンク２１８、２１６、２１５、および２２１からなる経路が選択されているとする。当該経路は、下記のような分散協調によって選択される。

　ＰＣ２０３からフレームを受信した通信装置１００ｃは、フレームの送信先ポートとして、リンク２１８を介して通信装置１００ｂと接続されたポート１３１ｃを選択する。すると、通信装置１００ｃからフレームを受信した通信装置１００ｂが、フレームの送信先ポートとして、リンク２１６を介して通信装置１００ａと接続されたポート１３１ｂを選択する。

　そして、通信装置１００ｂからフレームを受信した通信装置１００ａが、フレームの送信先ポートとして、リンク２１５を介して通信装置１００ｄと接続されたポート１３１ａを選択する。続いて、通信装置１００ａからフレームを受信した通信装置１００ｄが、フレームの送信先ポートとして、リンク２２１を介して通信装置１００ｇと接続されたポート１３２ｄを選択する。

　ところが、あるときリンク２１５に物理的な障害が発生したとする。リンク２１５の障害発生後に、ＰＣ２０３が再度ＰＣ２０５へフレームを送信しようとすると、有線アドホックネットワーク２００内での送信経路は、以下のような分散協調制御により切り替えられる。

　通信装置１００ｃは、フレームの送信先ポートとして正常時と同様にポート１３１ｃを選択し、通信装置１００ｂも、フレームの送信先ポートとして正常時と同様にポート１３１ｂを選択する。すると、通信装置１００ａがフレームを受信する。

　しかし、図１１に示すように、通信装置１００ａは、有線アドホックネットワーク２００内において通信装置１００ｂおよび１００ｄという２つの通信装置とだけ接続されており、通信装置１００ｄとの間のリンク２１５には障害が発生している。したがって、通信装置１００ａは、リンク２１６を介して通信装置１００ｂから受信したフレームを、正常なリンクを介して、通信装置１００ｂ以外の有線アドホックネットワーク２００内の通信装置に送信することができない。

　そこで、通信装置１００ａは、通信装置１００ａ自身からフレームを送信することができないことを通知するために、リンク２１６を介してフレームを通信装置１００ｂに返送する。すると、通信装置１００ｂは、通信装置１００ｂ自身が送信したフレームを受信する。

　よって、通信装置１００ｂは、ルーティングテーブル１２１において通信装置１００ｇに対応付けられたポート状態情報ではポート１３１ｂは「Ｌ」状態（すなわちループ状態）であることを認識する。すなわち通信装置１００ｂは、「有線アドホックネットワーク２００内での最終的な宛先が通信装置１００ｇであるフレームを送信する際には、通信装置１００ａと接続されたポート１３１ｂへフレームを送信すべきではない」と認識する。

　上記の認識にしたがい、通信装置１００ｂは、フレームの送信先ポートとして利用可能な、ポート１３１ｂ以外の正常なポートを探す。この場合、正常なリンク２１７を介して通信装置１００ｅと接続されたポート１３２ｂが見つかる。

　よって、通信装置１００ｂは、通信装置１００ａから戻されたフレームを、今度はポート１３２ｂへ送信する。
　すると、通信装置１００ｅがフレームを受信する。図１１の例では、通信装置１００ｅに接続されている各リンクは正常である。よって、通信装置１００ｅは、例えば、リンク２２３を介して通信装置１００ｈと接続されているポート１３３ｅを、フレームの送信先ポートとして選択することができる。

　この選択の結果、フレームは、ポート１３３ｅから送信され、リンク２２３を介して通信装置１００ｈで受信される。すると、通信装置１００ｈは、正常なリンク２２６を介して通信装置１００ｇと接続されたポート１３１ｈを選択し、ポート１３１ｈからフレームを送信する。

　その結果、通信装置１００ｇはフレームを受信することができる。このように、今まで使用されていた経路上のリンク２１５に障害が発生した場合であっても、有線アドホックネットワーク２００内の各通信装置の分散協調によって、自動的に経路の切り替えが行われる。

　なお、図７に示すようにルーティングテーブル１２１は宛先ごとにエントリを有しているので、フレームの宛先によっては通信装置１００ｂがポート１３１ｂを送信先ポートとして選択する場合もある。つまり、上記のように通信装置１００ｂにおいて、通信装置１００ｇに対応してポート１３１ｂが「Ｌ」状態と認識された場合であっても、通信装置１００ｂは、通信装置１００ａ宛てのフレームをポート１３１ｂから送信することができる。このように第１実施形態によれば、あるポートからのフレームの送信が可能か否かは、フレームの宛先に依存して管理される。

　続いて、図１２を参照して、以上説明した経路の切り替えを別の観点から説明する。
　図１２は障害発生時の代替経路探索を説明する概念図である。図１２には、上記の例において有線アドホックネットワーク２００内における送信元である通信装置１００ｃをルートノードとし、有線アドホックネットワーク２００内における送信先である通信装置１００ｇをリーフノードとする探索木３００が示してある。

　探索木３００における、あるノードを便宜的に「第１のノード」ということにし、第１のノードに相当する有線アドホックネットワーク２００内の通信装置を「第１の通信装置」ということにする。また、第１の通信装置のルーティングテーブル１２１において、宛先である通信装置１００ｇに対応するエントリで、他の通信装置（便宜的に「第２の通信装置」という）の状態が「Ｕ」状態または「Ｅ」状態であるとする。このとき、探索木３００において、第１のノードは第２の通信装置に対応する子ノードを有する。

　図１１に関して説明した、リンク２１５の障害発生前の送信経路は、有線アドホックネットワーク２００における分散協調の結果として、図１２の探索経路３０１に対応して見出された経路である。探索経路３０１は、探索木３００におけるルートノードである通信装置１００ｃから、通信装置１００ｂ、１００ａ、および１００ｄを経由して、探索木３００におけるリーフノードである通信装置１００ｇにいたる経路である。

　また、図１１に関して説明した、リンク２１５に障害が発生したときの経路の切り替え（すなわち代替経路探索）は、図１２の探索経路３０２に対応する。探索経路３０２は図１２に示すようにバックトラック３０３を含む。

　すなわち、「図１１に関して説明した経路の切り替えは、有線アドホックネットワーク２００全体として、探索木３００におけるバックトラック３０３を含む深さ優先探索が行われることに相当する」と見なせる。バックトラック３０３を含む探索経路３０２が、リーフノードである通信装置１００ｇにいたると、探索は成功し、有線アドホックネットワーク２００におけるフレームの送信経路が確立される。

　探索木３００において通信装置１００ａでバックトラック３０３が生じているのは、図１１の説明において通信装置１００ａがフレームを通信装置１００ｂに返送することに対応する。そして、探索木３００の探索経路３０２により最終的に見つかった、探索木３００におけるルートノードからリーフノードへの経路が、有線アドホックネットワーク２００における通信装置１００ｃから通信装置１００ｇへの新たなフレーム送信経路に相当する。つまり、図１２に示すように、通信装置１００ｃ、１００ｂ、１００ｅ、１００ｈ、１００ｇを通る経路が、新たなフレーム送信経路として見つかる。

　以上の説明から理解されるように、送信元の通信装置１００ｃから送信先の通信装置１００ｇまでの経路が有線アドホックネットワーク２００中に１つでも存在する限り、必ず、深さ優先探索の結果として、経路が発見される。

　続いて、図１１における有線アドホックネットワーク２００の内側と外側でのフレームの形式の違いについて、図１３を参照して説明する。図１３は、フレームの形式を説明する図である。なお、第１実施形態による「アドホックフレーム」は、有線アドホックネットワーク内の通信装置間で送受信されるフレームである。

　図１３に示すように、アドホックフレーム４００は、一般的なイーサネットフレーム４２０の前に、第１実施形態で定義される特定の形式のヘッダである「アドホックヘッダ」が付加された形式のフレームである。換言すれば、アドホックヘッダ４１０は、外部ネットワークであるイーサネットと、第１実施形態の有線アドホックネットワークとのインタフェイスとして働く情報である。

　第１実施形態のアドホックヘッダ４１０は、図１３に示すように１４バイトであり、ＧＤ４１１、ＧＳ４１２、タイプ４１３、ＦＩＤ４１４、ＴＴＬ４１５、長さ４１６、ＦＣＳ４１７の各フィールドを含む。また、詳しくは後述するが、アドホックヘッダ４１０は、有線アドホックネットワーク内の通信装置により付与される。なお、以下では表記の簡単化のため、例えば「ＧＤフィールド」を単に「ＧＤ」のように表記することがある。

　３バイトのＧＤ（Global Destination）４１１には、有線アドホックネットワーク内でのフレームの送信元の通信装置を、有線アドホックネットワーク内で一意に識別するための識別情報（例えばノードＩＤ）が指定される。また、３バイトのＧＳ（Global Source）４１２には、有線アドホックネットワーク内でのフレームの送信先の通信装置を、有線アドホックネットワーク内で一意に識別するための識別情報（例えばノードＩＤ）が指定される。

　例えば、図１１の例で、ＰＣ２０３からＰＣ２０５へのフレームが有線アドホックネットワーク２００を経由して送信される場合、有線アドホックネットワーク２００内での送信元の通信装置は、ＰＣ２０３と接続された通信装置１００ｃである。そして、有線アドホックネットワーク２００内での送信先の通信装置は、ＰＣ２０５と接続された通信装置１００ｇである。

　したがって、この場合、有線アドホックネットワーク２００内で送信されるアドホックフレーム４００では、通信装置１００ｃのノードＩＤがＧＤ４１１に指定されている。また、ＧＳ４１２には、通信装置１００ｇのノードＩＤが指定されている。

　ＧＤ４１１およびＧＳ４１２に指定される値は、上記のように、例えば、予め各通信装置に割り当てられたノードＩＤであり、ノードＩＤは識別番号でもよい。あるいは、有線アドホックネットワーク内の各通信装置が同一ベンダの製品であれば、通信装置のＭＡＣアドレスの下位３バイトを、ＧＤ４１１およびＧＳ４１２用の識別情報として用いることもできる。なぜなら、ＭＡＣアドレスの上位３バイトはＯＵＩ（Organizationally Unique Identifier）であり、下位３バイトはベンダ内で一意であるためである。

　なお、「ＧＤ」および「ＧＳ」という名称における「グローバル」という語の含意を、図１１の例に即して説明すると、次のとおりである。
　有線アドホックネットワーク２００内を通信装置１００ｃから通信装置１００ｇへとアドホックフレーム４００が送信されるとき、通信装置１００ｃからの直接の送信先は、通信装置１００ｃに隣接する通信装置（例えば通信装置１００ｂ）である。そこで、直接の送信先である通信装置１００ｂと、最終的な送信先である通信装置１００ｇを明示的に区別する場合には、有線アドホックネットワーク２００内での最終的な送信先である通信装置１００ｇを「グローバルな送信先」という。そして、通信装置１００ｃと直接ケーブルで接続された、通信装置１００ｃに隣接する通信装置１００ｂを「ローカルな送信先」という。

　したがって、通信装置１００ｂにとっては、通信装置１００ｃは、グローバルな送信元でもあり、かつローカルな送信元でもある。また、通信装置１００ｇにとっては、通信装置１００ｃは、グローバルな送信元ではあるが、（直接通信装置１００ｇと１００ｃが接続されているわけではないので）ローカルな送信元ではない。なお、図１１からも明らかなように、有線アドホックネットワークにおいては、ローカルな送信先はフレームの送信先のポートと１対１に対応し、ローカルな送信元はフレームを受信したポートと１対１に対応する。

　ここで図１３の説明に戻ると、４ビットのタイプ４１３には、アドホックフレーム４００のタイプ（種別）を識別する値が指定される。例えば、実施形態に応じて、下記に例示するようないくつかのタイプを識別する値が、タイプ４１３に指定される。
　・データフレーム（アドホックヘッダ４１０に続いて、イーサネットフレーム４２０を含むアドホックフレーム４００の一種）
　・その他のいくつかの種類の制御フレーム（アドホックヘッダ４１０に続いて、イーサネットフレーム４２０ではない所定形式のデータを含むアドホックフレームの一種）。制御フレームの中には、図１～５に例示したようなポーズ要求フレームとポーズ解除フレームが含まれる。

　また、１２ビットのＦＩＤ（Frame Identification）４１４には、ＧＳ４１２の値で識別される送信元の通信装置がアドホックフレーム４００に割り当てた識別情報が指定される。ＦＩＤ４１４に指定される値は、例えば、通信装置が不図示の内蔵カウンタ回路を用いて生成するシーケンス番号でもよい。

　また、２バイトのＴＴＬ（Time To Live）４１５には、アドホックフレーム４００の有効期間が、有線アドホックネットワーク内でのホップ数によって指定される。アドホックフレーム４００が有線アドホックネットワーク内でホップするたびに、ＴＴＬ４１５の値は、通信装置によりカウントダウンされる。

　ＴＴＬ４１５の初期値（すなわち、ＧＳ４１２の値で識別される送信元の通信装置により割り当てられる値）は、第１実施形態では、２バイトすべてのビットが「１」となる値（すなわち６５５３５）である。このように大きな値がＴＴＬ４１５の初期値として設定されるため、第１実施形態は、数十万の通信装置を含む有線アドホックネットワークにも好適に適用することができる。もちろん、実施形態に応じて、ＴＴＬ４１５の初期値は任意である。

　２バイトの長さ４１６には、アドホックヘッダ４１０以外の部分の長さ（例えば、図１３に例示したアドホックフレーム４００の場合はイーサネットフレーム４２０の長さ）をバイト単位で数えた値が指定される。

　また、２バイトのＦＣＳ（Frame Check Sequence）４１７は、アドホックヘッダ４１０の、ＧＤ４１１から長さ４１６までの各フィールドから得られる、ＣＲＣ（Cyclic Redundancy Check）コードなどの、誤り検出符号が指定される。

　イーサネットフレーム４２０は、以下の各フィールドを含む。
　・６バイトのＭＡＣ－ＤＡ（Media Access Control Destination Address）４２１
　・６バイトのＭＡＣ－ＳＡ（Media Access Control Source Address）４２２
　・２バイトのタイプ／長さ４２３
　・４６～１５００バイトの可変長のＬ３（Layer 3）パケット４２４
　・４バイトのＦＣＳ４２５

　イーサネットフレーム４２０の形式は周知なので詳しい説明は省略するが、例えば、図１１の例で、有線アドホックネットワーク２００を経由してＰＣ２０３からＰＣ２０５へフレームが送信される場合の具体例を説明すると、次のとおりである。

　すなわち、ＰＣ２０３では、ＰＣ２０５のＭＡＣアドレスをＭＡＣ－ＤＡ４２１に指定し、ＰＣ２０３自身のＭＡＣアドレスをＭＡＣ－ＳＡ４２２に指定したイーサネットフレーム４２０を生成し、リンク２１４を介して通信装置１００ｃに送信する。すると、通信装置１００ｃが、上記で説明したようなアドホックヘッダ４１０をイーサネットフレーム４２０の前に付与してアドホックフレーム４００を作成する。

　アドホックフレーム４００は、有線アドホックネットワーク２００内で通信装置１００ｇへと送信され、通信装置１００ｇは、アドホックヘッダ４１０を除くイーサネットフレーム４２０を、リンク２２８を介してＰＣ２０５に出力する。

　なお、アドホックヘッダ４１０におけるタイプ４１３に、制御フレームを示す値が指定されている場合、アドホックフレームは、アドホックヘッダ４１０の後に、イーサネットフレーム４２０以外の所定の形式のペイロードを含む。

　制御フレームの具体例は、ポーズフレーム４３０である。ポーズフレーム４３０は、アドホックヘッダ４１０とポーズ制御情報４４０を含む。ポーズフレーム４３０には、ポーズ要求フレームとポーズ解除フレームの２種類がある。

　また、ポーズ要求フレームとポーズ解除フレームの具体的な形式は、実施形態に応じて任意である。図１３には、ポーズ要求フレームの２種類の形式と、ポーズ解除フレームの３種類の形式を示した。実施形態に応じて、１種類のみのポーズ要求フレームが使われてもよいし、複数種類のポーズ要求フレームが使われてもよい。同様に、１種類のみのポーズ解除フレームが使われてもよいし、複数種類のポーズ解除フレームが使われてもよい。

　例えば、ポーズ要求フレームにおけるポーズ制御情報４４０は、ポーズ制御情報４４０ａのように、ポーズ要求を示す制御タイプ４４１と、１つのＧＤ４４２と、０以上の値を示すカウンタ４４３を含んでもよい。あるいは、ポーズ要求フレームにおけるポーズ制御情報４４０は、ポーズ制御情報４４０ｂのように、ポーズ要求を示す制御タイプ４４１と、１つ以上のＧＤを含むリストであるＧＤリスト４４４と、０以上の値を示すカウンタ４４３を含んでもよい。尚、ＧＤリスト４４４には、例えばリストに含まれるＧＤの個数などの、ＧＤリスト構造を識別可能な情報が含まれる場合もある。

　カウンタ４４３の値が、受信フレーム制御部１０４によってルーティングテーブル１２１のカウンタＣＴ_ｊｉに設定される。なお、実施形態によっては、カウンタ４４３が省略されてもよい。その場合、受信フレーム制御部１０４は、デフォルトの値をルーティングテーブル１２１のカウンタＣＴ_ｊｉに設定する。つまり、ポーズ要求フレームは、カウンタ４４３のように明示的な値を含んでもよいし、明示的には含まれないデフォルト値により暗黙的に期間の長さを指定してもよい。

　また、ポーズ解除フレームにおけるポーズ制御情報４４０は、ポーズ制御情報４４０ｃのように、ポーズ解除を示す制御タイプ４４５と、１つのＧＤ４４６と、０を示すカウンタ４４７を含んでもよい。あるいは、ポーズ解除フレームにおけるポーズ制御情報４４０は、ポーズ制御情報４４０ｄのように、ポーズ解除を示す制御タイプ４４５と、１つ以上のＧＤを含むリストであるＧＤリスト４４８と、０を示すカウンタ４４７を含んでもよい。

　または、ポーズ解除フレームにおけるポーズ制御情報４４０は、ポーズ制御情報４４０ｅのように、ポーズ解除を示す制御タイプ４４５と、０を示すカウンタ４４７を含んでもよい。つまり、ポーズ制御情報４４０ｅは、暗黙裡に「すべてのＧＤに関してポーズ要求を解除する」ということを指定している。

　なお、制御タイプ４４１または４４５は、省略されてもよい。なぜなら、正のカウンタ４４３を含むのはポーズ要求フレームであり、０のカウンタ４４７を含むのはポーズ解除フレームなので、カウンタの値から制御タイプが判別可能だからである。もちろん、実施形態に応じて、上記に例示した以外の形式のポーズフレーム４３０が使われてもよい。

　以上、図６の各コンポーネントを有する通信装置を複数含む有線アドホックネットワークにおける分散協調の概要について、図１１～図１３を参照して説明した。以下では、上記のような分散協調を実現するための、個々の通信装置の具体的動作を、フローチャートを参照して詳しく説明する。

　図１４は、フレーム受信処理のフローチャートである。フレーム受信処理は、受信部１０３がフレームを受信すると開始される。以下、通信装置１００が備えるｘ個のポートのうち、ｒ番目のポートでフレームが受信されたものとして説明する。

　ステップＳ１０１で、受信部１０３は、バッファ１０２上の領域を確保し、受信したフレームを、確保した領域に格納する。
　また、次のステップＳ１０２で、受信部１０３は、ステップＳ１０１で確保した領域のサイズに相当する値を、バッファ使用総量カウンタ１１４に加算する。そして、受信部１０３はフレームの受信を受信フレーム制御部１０４に通知する。

　なお、本実施形態では、この通知は、ステップＳ１０１で受信部１０３が確保した領域の先頭アドレスを表す情報と、受信部１０３がフレームを受信したポートを識別するポートＩＤを含む。

　また、図１４での図示は省略したが、通知を受けた受信フレーム制御部１０４は、図７に関して説明したＭＡＣテーブル１２４の学習を行うよう、テーブル制御部１０６に指示し、テーブル制御部１０６はＭＡＣテーブル１２４の学習を行う。

　次のステップＳ１０３では、受信フレーム制御部１０４は、受信されたフレームがポーズフレームであるか否かを判断する。この判断は、データフレームよりもポーズフレームを優先的に処理するために行われる。また、この判断は、受信フレーム制御部１０４が、バッファ１０２に格納されたフレームのタイプ４１３を参照することで行われる。

　受信されたフレームがポーズフレームの場合、処理はステップＳ１０４に移行する。他方、受信されたフレームがポーズフレームではない場合（すなわち、受信されたフレームがデータフレームである場合）、処理はステップＳ１０８に移行する。

　ステップＳ１０４で、受信フレーム制御部１０４は、受信したポーズフレームの制御タイプまたはカウンタの値に基づき、受信したポーズフレームがポーズ要求フレームなのかポーズ解除フレームなのかを判断する。受信したポーズフレームがポーズ要求フレームならば、処理はステップＳ１０５に移行し、受信したポーズフレームがポーズ解除フレームならば、処理はステップＳ１０６に移行する。

　なお、ポーズ要求フレームは、新たなポーズ要求のために使われてもよいし、ポーズ延長要求のために使われてもよい。過去に第１のポーズ要求を出したノード装置が、第１のポーズ要求を表すポーズフレームに指定した期間の経過後にもまだビジー状態が続いている場合に、第１のポーズ要求の解除を通知する代わりに再度第２のポーズ要求を出すことがある。この第２のポーズ要求が、ポーズ延長要求である。

　ステップＳ１０５では、受信フレーム制御部１０４が図１５のポーズ設定処理を行う。また、ステップＳ１０６では、受信フレーム制御部１０４が図１７のポーズ解除処理を行う。そして、ステップＳ１０５またはＳ１０６の実行後、処理はステップＳ１０７に移行する。

　ステップＳ１０７では、受信部１０３が、ステップＳ１０１で確保した領域のサイズに相当する値を、バッファ使用総量カウンタ１１４から減じる。つまり、受信部１０３はステップＳ１０２の加算を相殺する。また、受信部１０３は、受信したポーズ要求フレームがバッファ１０２上で占めていた領域を解放する。そして、フレーム受信処理は終了する。

　他方、受信されたフレームがポーズフレームではないとき、ステップＳ１０８で、受信フレーム制御部１０４は、受信フレームが、通信装置１００自身宛か否かを判断する。すなわち、受信フレーム制御部１０４は、通信装置１００自身のノードＩＤと、受信フレームのＧＤ４１１の値とが一致するか否かを判断する。

　通信装置１００自身のノードＩＤとＧＤ４１１の値が一致すれば、受信フレームは通信装置１００自身に宛てたものなので、処理はステップＳ１１０に移行する。逆に、通信装置１００自身のノードＩＤとＧＤ４１１の値が一致しなければ、受信フレームは通信装置１００自身に宛てたものではない。そこで、処理はステップＳ１０９に移行する。

　ステップＳ１０９で受信フレーム制御部１０４は、図１８のＧＤ別バッファ使用量加算処理を行う。そして、処理はステップＳ１１０に移行する。
　また、ステップＳ１１０で受信フレーム制御部１０４は、受信フレーム制御部１０４が内部データとして保持する受信キューに、ステップＳ１０１で受信部１０３が確保した領域の先頭アドレスと、フレームが受信されたポートのポートＩＤの組を追加する（つまり、先頭アドレスとポートＩＤの組をエンキューする）。そして、フレーム受信処理は終了する。

　図１５は、図１４のステップＳ１０５に相当するポーズ設定処理のフローチャートである。
　ステップＳ２０１で、受信フレーム制御部１０４は、ポーズフレーム４３０（図１５においては、具体的にはポーズ要求フレーム）を受信したポートを、「受信ポート」として記憶する。なお、受信部１０３からのステップＳ１０２での通知により、受信フレーム制御部１０４は、ポーズ要求フレームが受信されたポート（換言すればポーズ要求フレームの送信元の隣接ノード装置）を認識している。

　そして、次のステップＳ２０２で、受信フレーム制御部１０４は、ポーズフレーム４３０のポーズ制御情報４４０から、カウンタ４４３の値を取り出し、記憶する。なお、受信部１０３からのステップＳ１０２での通知により、受信フレーム制御部１０４は、受信されたポーズ要求フレームが格納されているバッファ１０２内の領域の先頭アドレスを認識している。よって、受信フレーム制御部１０４は、バッファ１０２からポーズ制御情報４４０の内容を読み取ることができる。

　そして、次のステップＳ２０３で受信フレーム制御部１０４は、ポーズ制御情報４４０内で未処理のＧＤが残っているか否かを判断する。もし、ＧＤ４４２、またはＧＤリスト４４４内にリストアップされたＧＤで、当該ＧＤに関してステップＳ２０４以降の処理が済んでいないものが残っていれば、処理はステップＳ２０４に移行する。逆に、ＧＤ４４２に関してステップＳ２０４以降の処理が済んでいるか、ＧＤリスト４４４内のすべてのＧＤに関してステップＳ２０４以降の処理が済んでいる場合、ポーズ設定処理が終了する。

　ステップＳ２０４で受信フレーム制御部１０４は、受信されたポーズフレーム４３０のポーズ制御情報４４０から、未処理とステップＳ２０３で判断したＧＤを１つ取り出す。つまり、受信フレーム制御部１０４は、ポーズ制御情報４４０ａからＧＤ４４２を取り出すか、ポーズ制御情報４４０ｂのＧＤリスト４４４から１つのＧＤを取り出す。

　そして、ステップＳ２０５で受信フレーム制御部１０４は、取り出したＧＤを検索キーにして、ルーティングテーブル１２１を検索する。
　続いて、ステップＳ２０６で受信フレーム制御部１０４は、検索の結果、取り出したＧＤがルーティングテーブル１２１において見つかったか否かを判断する。取り出したＧＤを「宛先」として含むエントリがルーティングテーブル１２１にある場合、処理はステップＳ２０７に移行する。逆に、取り出したＧＤを「宛先」として含むエントリがルーティングテーブル１２１にない場合、処理はステップＳ２０９に移行する。

　そして、ステップＳ２０７で受信フレーム制御部１０４は、検索の結果として見つかったルーティングテーブル１２１のエントリにおいて、ステップＳ２０１で記憶した受信ポートの「ポート状態」を「Ｐ」状態に設定する。

　続いて、ステップＳ２０８で受信フレーム制御部１０４は、検索の結果として見つかったルーティングテーブル１２１のエントリにおいて、ステップＳ２０１で記憶した受信ポートの「カウンタ」を、ステップＳ２０２で記憶した値に設定する。そして、処理はステップＳ２０３に戻る。

　他方、ステップＳ２０５の検索の結果、エントリが見つからなかった場合、ステップＳ２０９で受信フレーム制御部１０４は、ルーティングテーブル１２１に新規エントリを追加する。そして、受信フレーム制御部１０４は、追加したエントリを初期化する。すなわち、受信フレーム制御部１０４は、追加したエントリの「宛先」に、ステップＳ２０４で取り出したＧＤを設定し、ｘ個の「ポート状態」をすべて「Ｅ」状態に初期化し、ｘ個の「カウンタ」をすべて０に初期化し、「ポーズＧＤ」を０に初期化する。

　そして、ステップＳ２１０で受信フレーム制御部１０４は、ステップＳ２０９で追加したエントリにおいて、ステップＳ２０１で記憶した受信ポートに対応する「ポート状態」を、「Ｐ」状態に更新する。

　さらに、ステップＳ２１１で受信フレーム制御部１０４は、ステップＳ２０９で追加したエントリにおいて、ステップＳ２０１で記憶した受信ポートに対応する「カウンタ」を、ステップＳ２０２で記憶した値に設定する。そして、処理はステップＳ２０３に戻る。
　なお、上記の図１５の処理において、受信フレーム制御部１０４によるルーティングテーブル１２１の検索と更新は、テーブル制御部１０６を介してなされる。

　図１６は、図４～図５を参照して説明した第２の動作例における、図１５のポーズ設定処理の例を説明する図である。
　図２のノード３は、ノード２およびノード４と接続されている。また、ノード３は、４つのポート１３１～１３４を有する。具体的には、ポート１３１がノード２と接続されており、ポート１３２がノード４と接続されている。

　よって、ノード３が記憶しているルーティングテーブル１２１ａの各エントリは、図１６に示すように、４つのポート１３１～１３４にそれぞれ対応する「ポート状態」と「カウンタ」を含む（すなわち、図７におけるｘが、図１６では４である）。

　図１６は、図４と図５に関して説明した不図示のポーズ要求フレームを受信したノード３が図１５のポーズ設定処理を行う場合を示している。ここで、説明の便宜上、このポーズ要求フレームでＧＤとして指定されているノード５を識別するノードＩＤを、ＧＤ_αとする。

　すると、ノード３がステップＳ２０１で記憶する受信ポートは、ポーズ要求フレームの送信元であるノード４と接続されたポート１３２である。また、ノード３は、ステップＳ２０４でＧＤ_αを取り出し、ステップＳ２０５の検索により、ＧＤ_αを含むエントリを見つけ出す。そこで、ノード３は、見つけたエントリをステップＳ２０７とＳ２０８で更新する。

　例えば、見つかったエントリが、具体的には、図１６のエントリＥ１のように、下記のような値を含むとする。
　　・「宛先」が、ノード５を表す「ＧＤ_α」である。
　　・ポート１３１～１３４に対応する「ポート状態」は、それぞれ「Ｅ」、「Ｕ」、「Ｌ」、「Ｌ」である。
　　・ポート１３１～１３４に対応する「カウンタ」がすべて０である。
　　・「ポーズＧＤ」が０である。

　すると、ステップＳ２０７でノード３は、受信ポートであるポート１３２に対応する「ポート状態」を、「Ｕ」状態から「Ｐ」状態に更新する。また、ステップＳ２０８でノード３は、ポート１３２に対応する「カウンタ」を、０から、ポーズ要求フレームで指定されている値Ｃ_αに更新する。

　なお、エントリＥ１によれば、ノード５をＧＤとするフレームの送信先として、ノード４と接続されたポート１３２が選択されている。このことは、図４の時刻Ｔ４の前の図１の時刻Ｔ１において、ノード３からノード４へ、ノード５をＧＤとするフレームが送信されていることに対応する。

　また、ノード５をＧＤとするフレームの送信先としてはポート１３３と１３４が使えないということが、エントリＥ１の「ポート状態」により示されている。なお、ポート１３１は、選択されていないが、ノード５をＧＤとするフレームの送信先として選択可能である。

　なお、図４には、ノード３が、ポーズ要求フレームの受信後は、ノード５をＧＤとするフレームをノード２へ送信することが示されている。このことは、図１６において、ノード２と接続されたポート１３１の「ポート状態」が「Ｅ」から「Ｕ」に更新されることに対応する。すなわち、「Ｅ」状態は選択可能なことを示すので、ノード５をＧＤとするフレームの送信先として、ノード３はノード２を選択することができる。この「Ｅ」から「Ｕ」への更新は、後述の受信データフレーム処理において行われる。

　さて、図１７は、図１４のステップＳ１０６に相当するポーズ解除処理のフローチャートである。
　ステップＳ３０１で、受信フレーム制御部１０４は、受信したポーズフレーム４３０（図１７においては、具体的にはポーズ解除フレーム）のポーズ制御情報４４０の中にＧＤの指定があるか否かを判断する。ＧＤの指定がなければ（つまり、ポーズ制御情報４４０がポーズ制御情報４４０ｅの形式ならば）、処理はステップＳ３０２に移行する。逆に、ＧＤの明示的な指定があれば（つまり、ポーズ制御情報４４０がポーズ制御情報４４０ｃまたは４４０ｄの形式ならば）、処理はステップＳ３０４に移行する。

　ステップＳ３０２で受信フレーム制御部１０４は、ポーズフレーム４３０を受信したポートについて、ルーティングテーブル１２１のすべてのエントリにおける「ポート状態」を、「Ｅ」状態に更新する。つまり、ルーティングテーブル１２１に「宛先」として登録されているすべてのＧＤに関して、受信フレーム制御部１０４は、ポーズフレーム４３０を受信したポートの「ポート状態」を「Ｅ」状態に戻す。なお、受信部１０３からのステップＳ１０２での通知により、受信フレーム制御部１０４は、ポーズ解除フレームが受信されたポートを認識している。

　また、ステップＳ３０３で受信フレーム制御部１０４は、ポーズフレーム４３０を受信したポートについて、ルーティングテーブル１２１のすべてのエントリにおける「カウンタ」をクリアする（つまり、０に設定しなおす）。そして、ポーズ解除処理は終了する。

　他方、ポーズ解除フレームに明示的なＧＤの指定が含まれる場合、ステップＳ３０４で受信フレーム制御部１０４は、ポーズフレーム４３０を受信したポートを記憶する。
　そして、次のステップＳ３０５で受信フレーム制御部１０４は、ポーズ制御情報４４０内で未処理のＧＤが残っているか否かを判断する。もし、ＧＤ４４６、またはＧＤリスト４４８内にリストアップされたＧＤで、当該ＧＤに関してステップＳ３０６以降の処理が済んでいないものが残っていれば、処理はステップＳ３０６に移行する。逆に、ＧＤ４４６に関してステップＳ３０６以降の処理が済んでいるか、ＧＤリスト４４８内のすべてのＧＤに関してステップＳ３０６以降の処理が済んでいる場合、ポーズ解除処理が終了する。

　ステップＳ３０６で受信フレーム制御部１０４は、受信されたポーズフレーム４３０のポーズ制御情報４４０から、未処理とステップＳ３０５で判断したＧＤを１つ取り出す。つまり、受信フレーム制御部１０４は、ポーズ制御情報４４０ｃからＧＤ４４６を取り出すか、ポーズ制御情報４４０ｄのＧＤリスト４４８から１つのＧＤを取り出す、
　そして、ステップＳ３０７で受信フレーム制御部１０４は、取り出したＧＤを検索キーにして、ルーティングテーブル１２１を検索する。

　続いて、ステップＳ３０８で受信フレーム制御部１０４は、検索の結果、取り出したＧＤがルーティングテーブル１２１において見つかったか否かを判断する。取り出したＧＤを「宛先」として含むエントリがルーティングテーブル１２１にある場合、処理はステップＳ３０９に移行する。

　逆に、取り出したＧＤを「宛先」として含むエントリがルーティングテーブル１２１にない場合、処理はステップＳ３０５に戻る。例えば、エージング処理によるエントリの削除の結果、ステップＳ３０７の検索でエントリが見つからないことがある。

　そして、ステップＳ３０９で受信フレーム制御部１０４は、検索の結果として見つかったルーティングテーブル１２１のエントリにおいて、ステップＳ３０４で記憶した受信ポートの「ポート状態」を、初期状態である「Ｅ」状態に戻す。

　さらに、ステップＳ３１０で受信フレーム制御部１０４は、検索の結果として見つかったルーティングテーブル１２１のエントリにおいて、ステップＳ３０４で記憶した受信ポートの「カウンタ」をクリアする。そして、処理はステップＳ３０５に戻る。

　なお、上記の図１７の処理において、受信フレーム制御部１０４によるルーティングテーブル１２１の検索と更新は、テーブル制御部１０６を介してなされる。
　さて、図１８は、図１４のステップＳ１０９において行われるＧＤ別バッファ使用量加算処理のフローチャートである。

　図１８のステップＳ４０１において、受信フレーム制御部１０４は、受信したフレーム（すなわち、受信部１０３が受信して図１４のステップＳ１０１でバッファ１０２に格納したフレーム）のＧＤ４１１を抽出する。

　そして、ステップＳ４０２で受信フレーム制御部１０４は、ステップＳ４０１で抽出したＧＤ４１１を検索キーにして、バッファ使用中ＧＤテーブル１２６を検索する。
　次のステップＳ４０３で受信フレーム制御部１０４は、検索の結果としてエントリが見つかったか否かを判断する。エントリが見つかった場合、処理はステップＳ４０４に移行し、エントリが見つからなかった場合、処理はステップＳ４０５に移行する。

　そして、ステップＳ４０４で受信フレーム制御部１０４は、見つかったエントリの「バッファカウンタ」に、受信したフレーム用に受信部１０３がバッファ１０２上に確保した領域のサイズに相当する値を加算する。

　なお、この領域のサイズは、例えば、受信フレーム制御部１０４がバッファ１０２に格納されているフレームの「長さ」フィールド４１６の値を読み出し、読み出した値から計算してもよい。または、受信部１０３がステップＳ１０２で受信フレーム制御部１０４に対して、領域のサイズも通知してもよい。いずれにしろ、受信フレーム制御部１０４は、領域のサイズを認識することができる。

　ステップＳ４０４での加算が済むと、ＧＤ別バッファ使用量加算処理も終了する。
　また、ステップＳ４０２の検索でエントリが見つからなかった場合、ステップＳ４０５で受信フレーム制御部１０４は、バッファ使用中ＧＤテーブル１２６に新規エントリを追加する。

　そして、ステップＳ４０６で受信フレーム制御部１０４は、追加したエントリの「ＧＤ」に、ステップＳ４０１で抽出したＧＤ４１１を設定する。
　また、ステップＳ４０７で受信フレーム制御部１０４は、追加したエントリの「バッファカウンタ」に、受信したフレーム用に受信部１０３がバッファ１０２上に確保した領域のサイズに相当する値を設定する。そして、ＧＤ別バッファ使用量加算処理も終了する。

　なお、上記の図１８の処理において、受信フレーム制御部１０４によるバッファ使用中ＧＤテーブル１２６の検索と更新は、テーブル制御部１０６を介してなされる。
　続いて、図１４の処理とは独立して実行される受信データフレーム処理について、図１９～２１を参照して説明する。受信データフレーム処理は、通信装置１００に電源が入っている間はずっと実行され続ける常駐プロセスであってもよい。つまり、受信データフレーム処理は、通信装置１００に電源が入れられ、テーブル格納部１０１内の各種テーブルの初期化などの所定の処理が終了した後に開始され、以後、通信装置１００の電源が切られるまで継続されてもよい。

　図１９のステップＳ５０１に示すように、受信フレーム制御部１０４は、受信キューが空の間は待機する。そして、受信キューが空でないとき、処理はステップＳ５０２に移行する。なお、図１４のステップＳ１１０に関して説明したとおり、受信キューには、受信部１０３が受信したデータフレームが格納されているバッファ１０２上の領域の先頭アドレスと受信ポートの組がエンキューされている。

　そして、ステップＳ５０２で受信フレーム制御部１０４は、受信キューの先頭に記録されたアドレスとポートＩＤの組をデキューし、デキューしたアドレスから始まる領域に格納されている受信フレームに着目する。以下、受信部１０３により受信され、バッファ１０２に格納されている１つまたは複数のデータフレームのうち、ステップＳ５０２で着目されたフレームを単に「受信フレーム」ともいう。

　続いて、ステップＳ５０３で受信フレーム制御部１０４は、受信フレームが、通信装置１００自身宛か否かを判断する。すなわち、受信フレーム制御部１０４は、通信装置１００自身のノードＩＤと、受信フレームのＧＤ４１１の値とが一致するか否かを判断する。

　通信装置１００自身のノードＩＤとＧＤ４１１の値が一致すれば、受信フレームは通信装置１００自身に宛てたものなので、処理はステップＳ５０４に移行する。
　逆に、通信装置１００自身のノードＩＤとＧＤ４１１の値が一致しなければ、受信フレームは通信装置１００自身に宛てたものではない。そこで、処理は図２０のステップＳ５０６に移行する。

　ステップＳ５０４では上位転送処理が行われる。すなわち、ステップＳ５０４で受信フレーム制御部１０４は、受信フレームが格納されている先頭アドレスを上位層処理部１０５に通知する。受信フレーム制御部１０４は、さらに、先頭アドレスから計算した、受信フレームのペイロードたるイーサネットフレーム４２０の先頭アドレスを上位層処理部１０５に通知してもよい。

　そして、上位層処理部１０５は、通知されたアドレスにしたがって、バッファ１０２から受信フレームのペイロードを読み出し、適宜の処理を行う。例えば、上位層処理部１０５は、受信フレームのペイロード内にＬ３パケット４２４として含まれるデータを処理したり、受信フレームに基づく適宜のコントロールを実行したりする。

　ペイロードを使った処理の実行後、上位層処理部１０５は、受信フレームがバッファ１０２内で占めていた領域を解放し、解放した領域のサイズに相当する値を、バッファ使用総量カウンタ１１４から減じる。そして、処理はステップＳ５０１に戻る。

　ステップＳ５０６で受信フレーム制御部１０４は、受信フレームに該当するエントリがループ検出テーブル１２２にあるか否かを判断する。つまり、受信フレーム制御部１０４は、テーブル制御部１０６を介して、受信フレームのＧＳ４１２の値とＦＩＤ４１４の値の組を検索キーにしてループ検出テーブル１２２を検索する。

　検索の結果、送信元ＧＳ_ｉがＧＳ４１２の値と一致するとともにＦＩＤ_ｉがＦＩＤ４１４の値と一致するエントリが見つかれば（１≦ｉ≦ｍ）、処理は図２１のステップＳ５２２に移行する。他方、検索の結果、上記のようなエントリが見つからなければ、処理は図２０のステップＳ５０７に移行する。なお、上記のようなエントリは、存在するとしても１個だけである。

　ステップＳ５０７で、受信フレーム制御部１０４は、ポート選択部１０８に対して送信先のポートを決定する処理を開始するよう依頼する。そして、ポート選択部１０８は、テーブル制御部１０６を介して、受信フレームのＧＤ４１１の値でルーティングテーブル１２１を検索する。

　次のステップＳ５０８で、ポート選択部１０８は、検索の結果、ＧＤ４１１の値を「宛先」として持つエントリがルーティングテーブル１２１内に見つかったか否かを、判断する。上記のエントリが見つからなかった場合、処理はステップＳ５０９に移行し、上記のエントリが見つかった場合、処理はステップＳ５１０に移行する。なお、上記のエントリは、見つかるとしても１つしか存在しない。

　ステップＳ５０９でポート選択部１０８は、テーブル制御部１０６を介してルーティングテーブル１２１に新規エントリを登録する。当該新規エントリにおいて、宛先の値は、受信フレームのＧＤ４１１の値に設定され、ｘ個のポートの「ポート状態」はすべて「Ｅ」状態に設定され、ｘ個のポートの「カウンタ」はすべて０に設定され、「ポーズＧＤ」は０に設定される。そして、処理はステップＳ５１０に移行する。

　図２０に関する以下の説明では、ステップＳ５０７の検索の結果見つかった１つのエントリまたはステップＳ５０９で新規に登録されたエントリのことを「注目エントリ」といい、注目エントリはルーティングテーブル１２１のｆ番目のエントリであるとする。

　なお、図７の例に即して説明すれば、ステップＳ５０７で注目エントリが見つかった場合は１≦ｆ≦ｎであり、ステップＳ５０９で注目エントリが登録された場合はｆ＝ｎ＋１である。

　ステップＳ５１０でポート選択部１０８は、現在のポートリンク状態をルーティングテーブル１２１の注目エントリに反映する。つまり、ステップＳ５１０でポート選択部１０８は、１≦ｋ≦ｘなる各ｋについて、ｋ番目のポートの「ポート状態」に対して次の操作を行う。

　・ｋ番目のポートのポート状態ＲＰ_ｋｆが「Ｄ」状態のとき、ポート選択部１０８は、ポートリンク状態テーブル１２３のリンク状態Ｌ_ｋを参照する。そして、リンク状態Ｌ_ｋが「Ｃ」状態であれば、ポート選択部１０８は、ポート状態ＲＰ_ｋｆを「Ｅ」状態に更新する。逆に、リンク状態Ｌ_ｋが「Ｄ」状態であれば、ポート選択部１０８は、ポート状態ＲＰ_ｋｆを「Ｄ」状態のままにする。

　・ｋ番目のポートのポート状態ＲＰ_ｋｆが「Ｄ」状態以外の状態のとき、ポート選択部１０８は、ポートリンク状態テーブル１２３のリンク状態Ｌ_ｋを参照する。そして、リンク状態Ｌ_ｋが「Ｃ」状態であれば、ポート選択部１０８は、ポート状態ＲＰ_ｋｆを変更しない。逆に、リンク状態Ｌ_ｋが「Ｄ」状態であれば、ポート選択部１０８は、ポート状態ＲＰ_ｋｆを「Ｄ」状態に更新する。

　さらに、ステップＳ５１１でポート選択部１０８は、ルーティングテーブル１２１の注目エントリを参照する。そしてポート選択部１０８は、受信フレームを受信したｒ番目のポート（１≦ｒ≦ｘ）以外であり、かつ状態が「Ｌ」、「Ｐ」、「Ｄ」状態以外のポートのうちの１つを、送信先ポートとして選択する。なお、状態が「Ｌ」、「Ｐ」、「Ｄ」状態以外とは、換言すれば「Ｅ」状態または「Ｕ」状態ということである。

　第１実施形態では、ポート選択部１０８は、ステップＳ５１１において「Ｕ」状態のポートを「Ｅ」状態のポートよりも優先して選ぶ。なぜなら、「Ｕ」状態のポートは、過去に送信先ポートとして使用した実績があり、ループが発生しないことがステップＳ５０６で確認されているので、信頼性が確立されているためである。

　なお、本明細書においてデータフレームは、特に断らない限りユニキャストフレームである。よって、「Ｕ」状態のポートは、注目エントリ中に存在するとしても、１個しか存在しない。

　また、ポート選択部１０８がステップＳ５１１で「Ｅ」状態のポートを選ぶ場合で、注目エントリ中に「Ｅ」状態のポートが複数ある場合は、ポート選択部１０８は、例えば、最初に見つけた「Ｅ」状態のポートを選択してもよい。

　ただし、「受信フレームを受信したｒ番目のポート以外であり、しかも注目エントリにおいて状態が『Ｅ』または『Ｕ』に設定されている」という条件を満たすポートが、存在しない可能性もある。

　そこで、ステップＳ５１２でポート選択部１０８は、ステップＳ５１１で選択された送信先ポートがあるか否かを判断する。ステップＳ５１１で選択された送信先ポートがある場合は、処理はステップＳ５１３に移行し、ステップＳ５１１で送信先ポートが見つからなかった場合は、処理はステップＳ５１８に移行する。

　ステップＳ５１３でポート選択部１０８は、ルーティングテーブル１２１の注目エントリにおける送信先ポートの状態を「Ｕ」状態に更新する。例えば、ステップＳ５１１でｅ番目のポート（１≦ｅ≦ｘ）が送信先ポートとして選択された場合、ステップＳ５１３では、状態ＲＰ_ｅｆの値が「Ｕ」に設定される。

　そして、ステップＳ５１４でポート選択部１０８は、テーブル制御部１０６を介して、ループ検出テーブル１２２に新規エントリを追加登録する。当該新規エントリが例えば（ｍ＋１）番目のエントリであるとすると、当該新規エントリの各フィールドの内容は次のとおりである。
　・送信元ＧＳ_ｍ＋１は、受信フレームのＧＳ４１２の値に設定される。
　・ＦＩＤ_ｍ＋１は、受信フレームのＦＩＤ４１４の値に設定される。
　・ＯＬＳポートＯＬＳＰ_ｍ＋１は、ｒに設定される（なお、上記のとおり、フレームを受信したポートをｒ番目のポートとする）。
　・選ばれたｅ番目のポートに対応するポート状態ＬＰ_{ｅ（ｍ＋１）}は「Ｕ」に設定され、ｒ番目のポートに対応するポート状態ＬＰ_{ｒ（ｍ＋１）}は「Ｏ」に設定され、それ以外のポートに対応するポート状態はすべて「Ｅ」に設定される。

　ステップＳ５１４で上記のような新規エントリがループ検出テーブル１２２に追加されると、処理はステップＳ５１５に移行する。
　ステップＳ５１５でポート選択部１０８は、テーブル制御部１０６を介して、ステップＳ５１４で追加した新規エントリのタイマ（図７には不図示）に、現在の内部タイマ値（つまり現在時刻）を設定する。例えばこのような設定により、エージング処理が可能となる。

　そして、次のステップＳ５１６では、ステップＳ５１１または後述のステップＳ５１９で送信先ポートとして選択されたポートにフレームが送信される。
　具体的には、ポート選択部１０８は、送信先ポートとして選択したポートと、送信対象のフレーム（すなわちステップＳ５０２で着目した受信フレーム）のバッファ１０２内での先頭アドレスを、送信フレーム制御部１１０に指示する。すると、送信フレーム制御部１１０は、バッファ１０２上の受信フレームのアドホックヘッダ４１０を書き換える。具体的には、送信フレーム制御部１１０は、ＴＴＬ４１５を１減らし、ＦＣＳ４１７を再計算する。

　さらに、送信フレーム制御部１１０は、アドホックヘッダ４１０がこうして書き換えられた受信フレームを、ポート選択部１０８により選択された送信ポートから送信するための制御を行う。例えば、送信フレーム制御部１１０は、アドホックヘッダ４１０が書き換えられた受信フレームの、サイズと、バッファ１０２内での先頭アドレスを送信部１１１に通知する。また、送信フレーム制御部１１０は、選択された送信ポートのポートＩＤも送信部１１１に通知する。

　そして、送信部１１１は、通知された先頭アドレスからフレームのデータを読み出し、通知された送信ポートからフレームを送信する。フレームの送信後、処理はステップＳ５１７に移行する。

　ステップＳ５１７では、図２２に示すバッファ解放処理が行われる。そして、処理は図１９のステップＳ５０１に戻る。
　また、ステップＳ５１８でポート選択部１０８は、受信フレームのＧＳ４１２が自ノードＩＤと等しいか否かを判断する。受信フレームのＧＳ４１２が自ノードＩＤと等しくないとき、処理はステップＳ５１９に移行し、両者が等しいとき、処理はステップＳ５２０に移行する。

　なお、ステップＳ５１８が実行されるのは、受信フレームに対応するエントリがループ検出テーブル１２２にないとステップＳ５０６で判明しているときである。よって、後述するように、ループ検出テーブル１２２のエージング時間がアドホックネットワーク内でのフレームのループにかかる時間を考慮して適切に設定されていれば、フレームが自ノードにループして戻ってくる前にループ検出テーブル１２２からエントリがなくなることはないため、処理はステップＳ５１９へ移行し、ステップＳ５２０が実行されることはない。

　ステップＳ５１９でポート選択部１０８は、受信フレームを受信したｒ番目のポートを送信ポートとして選ぶ。そして、処理は前述のステップＳ５１５に移行する。よって、受信フレームはやがてステップＳ５１６でｒ番目のポートから送信される。

　つまり、「ｒ番目のポートで受信したフレームを送信しようとしても、送信することが可能なポートが見つからない」と通知するため、ステップＳ５１９では、ｒ番目のポートが受信フレームを返送するためのポートとして選択される。

　また、ステップＳ５２０でポート選択部１０８は、送信フレーム制御部１１０を介して上位層処理部１０５に送信失敗を通知する。上位層処理部１０５への送信失敗の通知は、例えば、受信フレームのバッファ１０２における先頭アドレスを含んでもよい。そして、処理はステップＳ５１７に移行する。

　さて、受信フレームに対応するエントリがループ検出テーブル１２２にあるとステップＳ５０６で判明した場合、図２１のステップＳ５２２以下の処理が行われる。すなわち、図２１の処理は、過去に通信装置１００自身が送信したユニキャストフレームが有線アドホックネットワーク内をループして通信装置１００に戻り、ｒ番目のポートにおいて受信された場合の処理である。例えば、図１２において、探索経路３０２でのバックトラック３０３の後の、通信装置１００ａからフレームを受信した通信装置１００ｂにおける処理が、図２１に対応する。

　ステップＳ５２２では、ポート選択部１０８が、ステップＳ５０６の検索によってループ検出テーブル１２２で検出されたエントリを参照し、当該エントリからＯＬＳポートの値を読み出し、ＯＬＳポートを認識する。例えば、受信フレーム制御部１０４がステップＳ５０６の検索で検出したエントリのアドレスをポート選択部１０８に通知してもよく、それにより、ポート選択部１０８による当該エントリの参照が可能となる。

　続いて、ステップＳ５２３では、ポート選択部１０８が、ステップＳ５０６で検出されたループ検出テーブル１２２のエントリにおいて「Ｕ」状態のポート状態を「Ｌ」状態に変更する。

　例えば、検索の結果、ステップＳ５０６ではループ検出テーブル１２２のｉ番目のエントリがヒットしたとする。ここで、ステップＳ５２３は、ユニキャストされたフレームに関して実行されるステップであるから、ｉ番目のエントリにおけるポート状態ＬＰ_１ｉ～ＬＰ_ｘｉのうち、値が「Ｕ」であるものは、１つしかない。以下、説明の便宜上、ｔ番目（１≦ｔ≦ｘ）のポートのポート状態ＬＰ_ｔｉの値が「Ｕ」であるとする。

　すなわち、ＧＳ４１２に送信元ＧＳ_ｉが設定され、ＦＩＤ４１４にＦＩＤ_ｉと同じ値が設定されたアドホックフレーム４００を、ｔ番目のポートから通信装置１００がかつて送信したことがあった場合、ステップＳ５２３においてポート状態ＬＰ_ｔｉの値は「Ｕ」である。そして、この場合、ステップＳ５２３において、ポート状態ＬＰ_ｔｉの値は「Ｕ」から「Ｌ」に更新される。

　さらに、ステップＳ５２４でポート選択部１０８は、テーブル制御部１０６を介して、受信フレームのＧＤ４１１の値に対応するルーティングテーブル１２１のエントリを検索する。

　なお、第１実施形態では、ルーティングテーブル１２１のエージング期間（すなわち各エントリの有効期間）の方が、ループ検出テーブル１２２のエージング期間よりも長い。そのため、ステップＳ５２４では検索の結果、必ず１つのエントリがヒットすると保証される。

　ルーティングテーブル１２１のエージング期間は、例えば２２５秒といった比較的長い時間でよい。それに対し、ループ検出テーブル１２２のエージング期間は、例えば１秒未満の比較的短い時間にするのが好ましい。その理由は、ルーティングテーブル１２１の１つのエントリは有線アドホックネットワーク内の１つの通信装置に対応するのに対し、ループ検出テーブル１２２の１つのエントリは１つのアドホックフレーム４００に対応するためである。

　つまり、ループ検出テーブル１２２には、ルーティングテーブル１２１よりもはるかに頻繁にエントリが追加されると予測される。したがって、ループ検出テーブル１２２のエントリ数の増えすぎによるオーバフローを防ぐために、ループ検出テーブル１２２のエージング期間は比較的短い時間に設定される。

　なお、ループ検出テーブル１２２のエージング期間の長さとして適切な値は、例えば予備実験を行うなどして、有線アドホックネットワーク内でのループにかかる時間を考慮に入れて定めることが好ましい。

　以下では説明の便宜上、ステップＳ５２４でルーティングテーブル１２１のｊ番目のエントリがヒットしたと仮定する。すなわち、受信フレームのＧＤ４１１の値が、ルーティングテーブル１２１における宛先ＧＤ_ｊの値と一致したとする。

　すると、ステップＳ５２５でポート選択部１０８は、現在のポートリンク状態を、ルーティングテーブル１２１の、ステップＳ５２４で検出したエントリに反映する。ステップＳ５２５の処理はステップＳ５１０と同様なので説明を省略する。

　さらに、ステップＳ５２６でポート選択部１０８は、ルーティングテーブル１２１の、ステップＳ５２４で検出したエントリにおいて、注目しているｔ番目のポートの「ポート状態」を「Ｌ」状態に設定する。つまり、ステップＳ５２３でループ検出テーブル１２２において「Ｕ」状態から「Ｌ」状態へと変更されたｔ番目のポートに関して、ステップＳ５２６では、ルーティングテーブル１２１においても状態が「Ｌ」に設定される。具体的には、ルーティングテーブル１２１のｊ番目のエントリにおいて、ｔ番目のポートのポート状態ＲＰ_ｔｊの値が「Ｌ」に更新される。

　以上のステップＳ５２３～Ｓ５２６により、有線アドホックネットワーク内をループして戻ってきたフレームを通信装置１００が受信した場合、戻ってきたフレームと宛先が同じフレームは、以後、今までの送信先ポートからは送信されないようになる。つまり、通信装置１００はループが生じるポートを学習し、以後、ループが生じるポートへの送信を控えるようになる。その結果、有線アドホックネットワーク全体としても、無駄なトラフィックが減る。

　続いて、ステップＳ５２７においてポート選択部１０８は、ルーティングテーブル１２１のｊ番目のエントリ（つまりステップＳ５２４でヒットしたエントリ）を検索し、下記２つの条件をともに満たすポートを探す。
　・ステップＳ５０６で検出されたループ検出テーブル１２２のｉ番目のエントリにおけるＯＬＳポートＯＬＳＰ_ｉではない。
　・「ポート状態」が「Ｅ」状態である。

　つまり、ポート選択部１０８は、ＦＩＤ_ｉと宛先ＧＤ_ｊが指定された送信元ＧＳ_ｉからのアドホックフレーム４００を最初に受信したポート以外で、送信するときの送信先ポートとしてまだ試したことがなく、かつ現在使用可能な（つまり「Ｄ」状態でも「Ｐ」状態でもない）ポートを探す。

　そして、ステップＳ５２８でポート選択部１０８は、ステップＳ５２７の検索の結果、「Ｅ」状態のポートが見つかったか否かを判断し、見つからなかった場合には処理がステップＳ５３３へ移行し、見つかった場合には処理がステップＳ５２９へ移行する。

　ステップＳ５２９では、ポート選択部１０８が、ステップＳ５２７で見つかった「Ｅ」状態のポートのうちの任意の１つ（例えば、最初に見つかったポート）を送信先ポートとして選択する。そして、ポート選択部１０８は、ルーティングテーブル１２１のｊ番目のエントリにおいて、送信先ポートとして選択した該当ポートの状態を「Ｕ」に設定する。

　例えば、ステップＳ５２９でｇ番目のポート（１≦ｇ≦ｘ）が選択されたとすると、ステップＳ５２４でヒットしたルーティングテーブル１２１のｊ番目のエントリにおいて、ｇ番目のポートの状態ＲＰ_ｇｊの値が、「Ｕ」に設定される。

　そして、ステップＳ５３０では、ポート選択部１０８がさらに、ループ検出テーブル１２２でも該当ポートを「Ｕ」状態に設定する。つまり、ステップＳ５０６で見つかったループ検出テーブル１２２のｉ番目のエントリにおいて、送信先ポートとしてステップＳ５２９で選択されたｇ番目ポートのポート状態ＬＰ_ｇｉの値が、「Ｕ」に設定される。そして処理はステップＳ５３１に移行する。

　ステップＳ５３１では、ステップＳ５２９または後述のステップＳ５３４で送信先ポートとして選択されたポートにフレームが送信される。ステップＳ５３１の詳細はステップＳ５１６と同様なので説明を省略する。

　また、次のステップＳ５３２では、図２２のバッファ解放処理が行われる。そして、処理は図１９のステップＳ５０１に戻る。
　他方、ステップＳ５２８で「Ｅ」状態のポートがないと判断された場合、ステップＳ５３３でポート選択部１０８は、受信フレームのＧＳ４１２が自ノードＩＤと等しいか否かを判断する。受信フレームのＧＳ４１２が自ノードＩＤと等しくないとき、処理はステップＳ５３４に移行し、両者が等しいとき、処理はステップＳ５３５に移行する。

　そして、ステップＳ５３４でポート選択部１０８は、ステップＳ５２２で認識したＯＬＳポートを、送信先ポートとして選択する。そして処理はステップＳ５３１に移行する。
　このステップＳ５３４が実行されるのは、ｒ番目のポートで受信したフレームを送信しようとしても、送信することが可能なポートが見つからない場合である。ここで「送信することが可能なポート」とは、具体的には、同じＦＩＤのフレームを最初に受信したＯＬＳポート以外の、「Ｌ」状態でも「Ｄ」状態でも「Ｐ」状態でもないポートのことである。

　つまり、通信装置１００が、受信したフレームを、最初にこのフレームを受信したＯＬＳポートと接続された隣接通信装置以外の他の隣接通信装置に送信することができないとき、ステップＳ５３４が実行される。よって、通信装置１００は、受信したフレームを返送するために、ＯＬＳポートを送信先ポートにする。

　返送により、通信装置１００は、ＯＬＳポートと接続された隣接通信装置に対して、「通信装置１００で送信経路が袋小路になっている」ということを知らせることができる。その結果、返送されたフレームを受信した隣接通信装置は、ループ検出テーブル１２２により、「宛先ＧＤ_ｊ宛てのフレームを通信装置１００と接続されたポートに送信してもループしてしまう」と認識することができる。

　例えば、図１２の例で、バックトラック３０３により通信装置１００ａから返送されたフレームを受信することでループを検出した通信装置１００ｂにおいて、通信装置１００ｅとの間のリンク２１７がリンクダウン状態だったとする。すると、探索経路３０２とは異なり、さらに通信装置１００ｂでもバックトラックが生じる。つまり、通信装置１００ｂは、ステップＳ５３４で、通信装置１００ｃと接続されたポート１３４ｂを送信先ポートとして選択する。

　その結果、通信装置１００ｃは、通信装置１００ｂから返送されたフレームを受信する。よって、通信装置１００ｃは、「通信装置１００ｇのノードＩＤがＧＤ４１１に設定されたアドホックフレーム４００の送信先ポートとして、通信装置１００ｂと接続されたポート１３１ｃは、不適切である」と認識する。つまり、通信装置１００ｃのルーティングテーブル１２１において、通信装置１００ｇのノードＩＤに対応付けられたポート１３１ｃの状態は、「Ｌ」に設定される。

　そして、通信装置１００ｃは、ポート１３１ｃとは別のポート１３３ｃをステップＳ５２９で選択する。このように、探索木３００においてバックトラックが複数回繰り返されることで新たな送信経路が見つかる場合もある（なお、図１２の探索経路３０２では１回バックトラックしただけで新たな送信経路が見つかっている）。

　さて、ステップＳ５３５でポート選択部１０８は、送信フレーム制御部１１０を介して上位層処理部１０５に送信失敗を通知する。そして、処理はステップＳ５３２に移行する。なお、ステップＳ５３５が実行されるのは、図１２の探索木３００がすべて探索された場合に相当する。送信失敗の通知後、処理はステップＳ５３２に移行する。

　以上のように、ループが発生したときは、ステップＳ５２９～Ｓ５３１によって別の新たな送信経路が試されるか、またはステップＳ５３４とＳ５３１によってバックトラックが発生する。なお、ステップＳ５２９～Ｓ５３１による新たな送信経路への切り替えは、通信装置１００内の各部がＦＰＧＡにより実現される場合、例えば、数μｓで行われる。

　また、バックトラックが発生したとしても、例えば図１２の探索経路３０２のように、バックトラックにより探索木３００を遡る回数が少なければ、有線アドホックネットワーク全体として見ても、非常に短い時間で送信経路の切り替えが完了する。このように、第１実施形態によれば、障害発生またはその他の理由でループが発生した場合に、非常に高速にフレームの送信経路の切り替えが実現される。

　なお、図１９～２１では説明の簡単化のため図示を省略したが、通信装置１００は、ルーティング処理においてＴＴＬ４１５の値に基づいてフレームを破棄する場合もある。すなわち、受信フレームのＴＴＬ４１５の値が１のとき、例えば次のように処理が行われてもよい。
　・図２１では、ステップＳ５２９～Ｓ５３１、Ｓ５３４の処理が省略される。
　・図２０ではステップＳ５０６とＳ５１７以外の処理が省略される。

　あるいは、受信フレームのＴＴＬ４１５の値が１のとき、図２０と図２１の処理は、ステップＳ５１７のバッファ解放処理を除いてすべて省略されてもよい。
　または、受信フレームのＴＴＬ４１５の値が１のときの処理は、図１４のフレーム受信処理に例外処理として含まれてもよい。例えば、ＴＴＬ４１５のチェックは、ＦＣＳ４１７のチェックの後、ステップＳ１１０での受信キューへのエンキューの前に、例えば以下に説明するようにして行われてもよい。

　上記の説明では省略したが、受信フレーム制御部１０４は、例えば図１４のステップＳ１０２とＳ１０３の間で、受信したフレームのＦＣＳ４１７のチェックを行う。そして、ＦＣＳ４１７がアドホックヘッダ４１０と不整合のとき、受信フレーム制御部１０４は受信部１０３に対してステップＳ１０７と同様の処理を行うよう命じる。それにより、フレームは破棄され、図１４の処理も終了する。

　逆に、ＦＣＳ４１７が適切な値であると判明した場合、受信フレーム制御部１０４は、続いて、ＴＴＬ４１５の値が１か否かを判断してもよい。そして、ＴＴＬ４１５の値が１のとき、受信フレーム制御部１０４は受信部１０３に対してステップＳ１０７と同様の処理を行うよう命じる。それにより、フレームは破棄され、図１４の処理も終了する。

　逆に、ＴＴＬ４１５の値が１より大きいとき、受信フレーム制御部１０４は、ステップＳ１０３以降の処理を行う。つまり、この例によれば、ステップＳ１１０で受信キューに先頭アドレスがエンキューされるフレームは、ＴＴＬ４１５が１より大きいフレームのみであるから、図１９～２１の処理は、ＴＴＬ４１５が１より大きいフレームに関してのみ行われる。

　以上例示したように、ＴＴＬ４１５やＦＣＳ４１７に応じた例外処理は、実施形態に応じて適宜行われる。
　また、図１９～２１には、図１１のポート１３１ａのような有線アドホックネットワークポートで受信されるフレームに関する処理を示したが、通信装置１００は、汎用ＬＡＮポート（例えば汎用ＬＡＮポート１３５ａ）で受信されるフレームに関する処理をさらに行ってもよい。

　すなわち、イーサネットフレーム４２０が汎用ＬＡＮポート１３５で受信された場合は、上位層処理部１０５がイーサネットフレーム４２０を処理する。上位層処理部１０５は、通信装置１００自身を宛先とするイーサネットフレーム４２０も処理する。

　逆に、他の通信装置を宛先とするイーサネットフレーム４２０は、送信フレーム制御部１１０によってアドホックヘッダ４１０が付与され、有線アドホックネットワークポートのいずれかから送信される。その際、図２０のステップＳ５１４と同様に、ループ検出テーブル１２２へのエントリの追加も行われる。

　また、上位層処理部１０５がイーサネットフレーム４２０を生成した場合は、イーサネットフレーム４２０は、ＭＡＣ－ＤＡ４２１に応じて、以下のいずれかの処理が行われる。
　・汎用ＬＡＮポート１３５からイーサネットフレーム４２０が送信される。
　・イーサネットフレーム４２０にアドホックヘッダ４１０が付与されて、有線アドホックネットワークポートのいずれかから送信される。その際、図２０のステップＳ５１４と同様にループ検出テーブル１２２へのエントリの追加も行われる。

　続いて、図２０のステップＳ５１７と図２１のステップＳ５３２で行われるバッファ解放処理について説明する。図２２は、バッファ解放処理のフローチャートである。バッファ解放処理は、通信装置１００が受信したフレームに対して、送信先ポートが決められて、フレームが転送される場合、あるいは、適切な送信先ポートがない場合に行われる。

　なお、図２２の処理は、例えば、送信先ポートが決められた場合は送信部１１１が行ってもよいし、送信先ポートがないために上位層処理部１０５に送信失敗が通知された場合は、上位層処理部１０５が行ってもよい。あるいは、送信フレーム制御部１１０が図２２の処理を行ってもよい。

　ステップＳ６０１で、受信フレームがバッファ１０２に占める領域のサイズに相当する値が、バッファ使用総量カウンタ１１４から減算される。
　続いて、ステップＳ６０２では、バッファ１０２に格納されている受信フレームのＧＤ４１１が抽出される。

　そして、ステップＳ６０３では、抽出されたＧＤ４１１を検索キーにして、バッファ使用中ＧＤテーブル１２６が検索される。検索の結果、必ず１つエントリが見つかる。
　すると、ステップＳ６０４で、検索の結果見つかったエントリの「バッファカウンタ」から、受信フレーム用に確保した領域のサイズに相当する値が減算される。

　そして、次のステップＳ６０５では、減算された「バッファカウンタ」の値が０か否かが判断される。「バッファカウンタ」の値が０のとき、処理はステップＳ６０６に移行し、「バッファカウンタ」の値が０ではないとき、処理はステップＳ６０７に移行する。

　ステップＳ６０６では、ステップＳ６０３の検索の結果見つかったエントリがバッファ使用中ＧＤテーブル１２６から削除される。
　そして、ステップＳ６０７では、受信フレームがバッファ１０２に占める領域が解放され、バッファ解放処理が終了する。

　さて、図２３と図２４は、通信装置１００がＧＳとなってフレームを送信するときに行うデータフレーム送信処理のフローチャートである。
　ステップＳ７０１で送信フレーム制御部１１０は、上位層処理部１０５による上位層のプロトコルの処理の結果として、ＧＤ４１１の値と、バッファ１０２に上位層処理部１０５が作成したペイロード（具体的には、アドホックフレーム４００のペイロードであるイーサネットフレーム４２０）を取得する。なお、上位層処理部１０５は、ペイロードの先頭アドレスを送信フレーム制御部１１０に通知することで、送信フレーム制御部１１０にペイロードを認識させてもよい。

　そして、ステップＳ７０２で送信フレーム制御部１１０は、データフレーム（つまりアドホックフレーム４００）の長さ４１６に設定する値として、ペイロードの長さを求める。

　また、ステップＳ７０３で送信フレーム制御部１１０は、送信しようとするデータフレームのＧＳ４１２に、自ノードＩＤを設定する。
　さらに、ステップＳ７０４で送信フレーム制御部１１０は、新たなＦＩＤを生成しデータフレームのＦＩＤ４１４に、生成した値を設定する。

　また、ステップＳ７０５で送信フレーム制御部１１０は、「データフレーム」を示す値を、データフレームのタイプ４１３として設定する。
　さらに、ステップＳ７０６で、送信フレーム制御部１１０はその他のアドホックヘッダ４１０内の各フィールドにも適宜値を設定する。こうして、完成したデータフレームがバッファ１０２に格納された状態となる。

　そして、ステップＳ７０７で送信フレーム制御部１１０は、データフレームのサイズ（つまり、データフレームがバッファ１０２内で占める領域のサイズ）に相当する値を、バッファ使用総量カウンタ１１４に加算する。

　続いて、ステップＳ７０８で送信フレーム制御部１１０は、ポート選択部１０８に、ＧＤ４１１の値を指定し、送信ポートを決定する処理を開始するよう依頼する。すると、ポート選択部１０８は、指定されたＧＤ４１１の値を用いて、ルーティングテーブル１２１を検索する。

　そして、ステップＳ７０９でポート選択部１０８は、ＧＤ４１１の値を「宛先」として含むエントリがルーティングテーブル１２１において登録されているか否かを、ステップＳ７０８の検索の結果に応じて判断する。エントリが登録されていた場合、処理は図２４のステップＳ７１１に移行する。エントリが見つからなかった場合、処理はステップＳ７１０に移行する。

　ステップＳ７１０でポート選択部１０８は、ルーティングテーブル１２１に、ＧＤ４１１の値を「宛先」として含むエントリを新規登録する。ステップＳ７１０の詳細は図２０のステップＳ５０９と同様なので説明を省略する。

　以下、図２４に関する説明では、ステップＳ７０８の検索の結果見つかった１つのエントリまたはステップＳ７１０で新規に登録されたエントリのことを「注目エントリ」という。

　図２４のステップＳ７１１でポート選択部１０８は、現在のポートリンク状態をルーティングテーブル１２１の注目エントリに反映する。ステップＳ７１１の詳細は図２０のステップＳ５１０と同様なので説明を省略する。

　そして、次のステップＳ７１２でポート選択部１０８は、ルーティングテーブル１２１の注目エントリを参照する。そしてポート選択部１０８は、状態が「Ｌ」、「Ｐ」、「Ｄ」状態以外のポートのうちの１つを、送信先ポートとして選択する。なお、図２０のステップＳ５１１に関して説明したのと同じ理由から、ポート選択部１０８は、「Ｕ」状態のポートを「Ｅ」状態のポートよりも優先して選ぶことが好ましい。

　ただし、「注目エントリにおいて状態が『Ｅ』または『Ｕ』に設定されている」という条件を満たすポートが、存在しない可能性もある。そこで、ステップＳ７１３でポート選択部１０８は、ステップＳ７１２で選択された送信先ポートがあるか否かを判断する。ステップＳ７１２で選択された送信先ポートがある場合は、処理はステップＳ７１４に移行し、ステップＳ７１２で送信先ポートが見つからなかった場合は、処理はステップＳ７１９に移行する。なお、送信先ポートが見つからなかった場合、ポート選択部１０８は、送信先ポートが見つからなかったことを送信フレーム制御部１１０に通知する。

　すなわち、ステップＳ７１４でポート選択部１０８は、ルーティングテーブル１２１の注目エントリにおける送信先ポートの状態を「Ｕ」状態に更新する。ステップＳ７１４の詳細は、図２０のステップＳ５１３と同様である。

　そして、ステップＳ７１５でポート選択部１０８は、テーブル制御部１０６を介して、ループ検出テーブル１２２に新規エントリを追加登録する。当該新規エントリが例えば（ｍ＋１）番目のエントリであるとすると、当該新規エントリの各フィールドの内容は次のとおりである。
　・送信元ＧＳ_ｍ＋１には、通信装置１００の自ノードＩＤが設定される。
　・ＦＩＤ_ｍ＋１には、図２３のステップＳ７０４で生成された値が設定される。
　・ＯＬＳポートＯＬＳＰ_ｍ＋１には、ポートＩＤとして使われないダミーの値が設定される。
　・送信先ポートとして選ばれたｅ番目のポートに対応するポート状態ＬＰ_{ｅ（ｍ＋１）}は「Ｕ」に設定され、それ以外のポートに対応するポート状態はすべて「Ｅ」に設定される。

　そして、ステップＳ７１５で上記のような新規エントリがループ検出テーブル１２２に追加されると、処理はステップＳ７１６に移行する。ステップＳ７１６でポート選択部１０８は、テーブル制御部１０６を介して、ステップＳ７１５で追加した新規エントリのタイマ（図７には不図示）に、現在の内部タイマ値（つまり現在時刻）を設定する。

　そして、次のステップＳ７１７では、ステップＳ７１２で送信先ポートとして選択されたポートにフレームが送信される。
　具体的には、ポート選択部１０８は、送信先ポートとして選択したポートを送信フレーム制御部１１０に通知する。すると、送信フレーム制御部１１０は、データフレームの、サイズと、バッファ１０２内での先頭アドレスを送信部１１１に通知する。また、送信フレーム制御部１１０は、選択された送信ポートのポートＩＤも送信部１１１に通知する。

　そして、送信部１１１は、通知された先頭アドレスからフレームのデータを読み出し、通知された送信ポートからフレームを送信する。フレームの送信後、処理はステップＳ７１８に移行する。

　ステップＳ７１８では、送信フレーム制御部１１０が、データフレームのサイズに相当する値（つまりステップＳ７０７で加算した値）をバッファ使用総量カウンタ１１４から減算する。そして、データフレーム送信処理は終了する。

　他方、送信先ポートが見つからなかった場合、ステップＳ７１９で送信フレーム制御部１１０は、上位層処理部１０５に送信失敗を通知する。この送信失敗の通知は、例えば、ステップＳ７０１で上位層処理部１０５から通知されたペイロードの先頭アドレスを含んでもよい。

　そして、ステップＳ７２０では、データフレームが破棄される。すなわち、データフレームが格納されていたバッファ１０２上の領域が解放される。例えば、上位層処理部１０５が送信フレーム制御部１１０に対して「送信失敗の通知を認識した」という返答を返す場合、送信フレーム制御部１１０が、アドホックフレーム４００であるデータフレーム全体をバッファ１０２から削除してもよい。あるいは、アドホックヘッダ４１０を送信フレーム制御部１１０が削除し、送信失敗の通知を受けた上位層処理部１０５がペイロード（例えばイーサネットフレーム４２０）を削除してもよい。

　いずれにしろ、ステップＳ７２０では、送信可能なポートが見つからないために送信に失敗したデータフレームが破棄される。そして、処理は前述のステップＳ７１８に移行する。

　さて、続いて、通信装置１００自身の状態（つまり通信装置１００がビジー状態か否か）に応じた、通信装置１００からのポーズ要求フレームまたはポーズ解除フレームの送信に関する各種の処理について説明していく。

　図２５は、通信装置１００が通信装置１００自身について行うポーズ制御処理のフローチャートである。例えば、図２５の処理は、予め決められた間隔で定期的に実行されてもよい。

　ステップＳ８０１でビジー検出部１１３は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳの値を参照し、通信装置１００自身がポーズ状態か否かを判断する。ポーズ状態ＳＳの値が「Ｐ」であるとき、処理はステップＳ８０４に移行し、ポーズ状態ＳＳの値が「Ｎ」であるとき、処理はステップＳ８０２に移行する。

　ステップＳ８０２でビジー検出部１１３は、通信装置１００自身がビジー状態か否かを判断する。例えば、バッファ使用総量カウンタ１１４の値が所定の閾値を超えていれば、ビジー検出部１１３は「通信装置１００自身がビジー状態である」と判断し、処理はステップＳ８０３に移行する。逆に、バッファ使用総量カウンタ１１４の値が上記の閾値以下であれば、ビジー検出部１１３は「通信装置１００自身はビジー状態ではない」と判断し、図２５の処理を終了する。

　なお、ビジー状態の判断に関する条件は、資源の使用状況に関する、実施形態に応じた任意の条件でよい。例えば、ビジー検出部１１３は、ＭＰＵの使用率を考慮に入れて、通信装置１００自身がビジー状態か否かを判断してもよい。

　ステップＳ８０３では、ポーズ要求フレーム送信処理が行われ、通信装置１００に隣接する各隣接ノードにポーズ要求フレームが送信される。ポーズ要求フレーム送信処理は、図２６の処理でもよいし、図２７の処理でもよい。ステップＳ８０３の実行後、図２５の処理は終了する。なお、ステップＳ８０３が実行されるのは、今までビジー状態ではなかった通信装置１００が新たにビジー状態に陥ったことがビジー検出部１１３により検知された場合である。

　さて、ステップＳ８０１でポーズ状態ＳＳの値が「Ｐ」であったとき、ステップＳ８０４でビジー検出部１１３は、通信装置１００自身がビジー状態か否かを、ステップＳ８０２と同様の方法で判断する。「通信装置１００自身がビジー状態である」とビジー検出部１１３が判断すると、処理はステップＳ８０６に移行する。逆に、「通信装置１００自身はビジー状態ではない」とビジー検出部１１３が判断すると、処理はステップＳ８０５に移行する。

　ステップＳ８０５では、ポーズ解除フレーム送信処理が行われ、通信装置１００に隣接する各隣接ノードにポーズ解除フレームが送信される。ポーズ解除フレーム処理は、図２８の処理でもよいし、図２９の処理でもよいし、図３０の処理でもよい。

　ステップＳ８０５の処理は、隣接ノード装置に対して過去に出したポーズ要求を解除するための通知を、隣接ノード装置に出すための処理である。すなわち、ステップＳ８０５の処理は、予測よりも早くビジー状態から通信装置１００が回復したときに、回復を隣接ノードに通知するための処理である。ステップＳ８０５の実行後、図２５の処理は終了する。

　また、ステップＳ８０６でビジー検出部１１３は、タイマ１０９から供給される現在のタイマ値（すなわち現在時刻）とポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅとの差分を、ポーズ状態管理テーブル１２５のカウンタＳＣｏｕｎｔと比較する。

　そしてステップＳ８０７でビジー検出部１１３は、上記差分が既にポーズ状態管理テーブル１２５のカウンタＳＣｏｕｎｔの値に達しているか否かを判断する。
　上記差分が既にカウンタＳＣｏｕｎｔの値に達していれば、過去のポーズ要求において通信装置１００が隣接ノード装置に要求した時間が既に経過したにもかかわらず、まだ通信装置１００自身がビジー状態から復帰することができていないということである。したがって、このとき処理はステップＳ８０８に移行する。

　逆に、上記差分がカウンタＳＣｏｕｎｔの値よりも小さければ、過去のポーズ要求において通信装置１００が隣接ノード装置に要求した時間がまだ経過していないということなので、図２５の処理は終了する。

　ステップＳ８０８では、ポーズ要求フレーム送信処理が行われる。ポーズ要求フレーム送信処理は、図２６の処理でもよいし、図２７の処理でもよい。ステップＳ８０８の実行後、図２５の処理は終了する。

　図２６は、ポーズ要求フレーム送信処理の第１の例のフローチャートである。図２６の処理は、ビジー検出部１１３からポーズ制御部１１２への指示を契機として開始される。
　ステップＳ９０１でポーズ制御部１１２は、タイマ１０９が示す現在時刻を、ポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅに設定する。また、ポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳを「Ｐ」状態に設定する。

　そして、ステップＳ９０２でポーズ制御部１１２は、ポーズ対象ＧＤ決定処理を行う。ポーズ対象ＧＤ決定処理の詳細は実施形態に応じて様々であり、そのいくつかの例については、図３１～３４とともに後述する。ポーズ対象ＧＤ決定処理により、ポーズ制御部１１２は、１つ以上のＧＤを、ポーズ対象ＧＤ（すなわちポーズ要求フレームに指定するＧＤ）として決定する。

　続いて、ステップＳ９０３でポーズ制御部１１２は、ルーティングテーブル１２１の、ステップＳ９０２で決定した１つ以上のＧＤにそれぞれ対応する各エントリで、「ポーズＧＤ」を、「選択中」を示す値（図７の例では「１」）に設定する。

　そして、ステップＳ９０４でポーズ制御部１１２は、ビジー検出部１１３から通知されたビジー状況に応じて、ポーズカウンタ値（つまり、ポーズ要求フレームに設定するカウンタ４４３の値）を決定する。そして、ポーズ制御部１１２は、決定した値を、ポーズ状態管理テーブル１２５のカウンタＳＣｏｕｎｔにも設定する。

　例えば、ビジー検出部１１３は、ポーズ要求フレーム送信処理を開始するよう、図２５のステップＳ８０３またはＳ８０８でポーズ制御部１１２に命令するときに、ビジー状況を表す値をポーズ制御部１１２に通知してもよい。ビジー状況を表す値は、例えば、ビジー検出部１１３がバッファ使用総量カウンタ１１４から読み取った値、ＭＰＵの使用率、または両者に基づいて計算したスコアなどである。よって、ポーズ制御部１１２は、ビジー状況に応じてカウンタ４４３の値を決定することができる。

　実施形態によっては、「通信装置１００がビジー状態に陥っている」という状況に基づき、ポーズ制御部１１２がカウンタ４４３とカウンタＳＣｏｕｎｔに、一律のデフォルト値を設定してもよい。

　さて、次のステップＳ９０５でポーズ制御部１１２は、ステップＳ９０２で決定したすべてのＧＤを含むリストと、ステップＳ９０４で決定したポーズカウンタ値とを含むポーズ要求フレームを生成する。つまり、ポーズ制御部１１２は、図１３のポーズ制御情報４４０ｂを含むポーズフレーム４３０を生成する。なお、ポーズ制御部１１２は、ポーズ要求フレームのタイプ４１３には、ポーズフレームであることを示す値を設定する。

　そして、ステップＳ９０６でポーズ制御部１１２は、生成したポーズ要求フレームの送信を送信フレーム制御部１１０に依頼する。すると、送信フレーム制御部１１０は、通信装置１００の全ポートを送信先ポートとして送信部１１１に指示する。よって、送信部１１１は、生成されたポーズ要求フレームを全ポートから送信する。

　続いて、ポーズ制御部１１２は、ステップＳ９０７において、タイマ１０９から現在時刻を取得し、記憶する。
　そして、ステップＳ９０８でポーズ制御部１１２は、ステップＳ９０２で決定した１つ以上のＧＤのうち、ステップＳ９０９以降の処理をまだ行っていない未処理のものがあるか否かを判断する。未処理のＧＤがある場合、続いてステップＳ９０９が実行され、ステップＳ９０２で決定したすべてのＧＤに対してステップＳ９０９以降の処理が済んでいる場合、ポーズ要求フレーム送信処理は終了する。

　ステップＳ９０９でポーズ制御部１１２は、ステップＳ９０２で決定した１つ以上のＧＤのうち、未処理のＧＤを１つ選ぶ。
　そして、ステップＳ９１０でポーズ制御部１１２は、ステップＳ９０９で選んだＧＤを検索キーにして、ポーズ履歴テーブル１２７を検索する。

　さらに、ステップＳ９１１でポーズ制御部１１２は、ステップＳ９１０の検索の結果、エントリが見つかったか否かを判断する。エントリが見つかった場合、処理はステップＳ９１２に移行し、エントリが存在しなかった場合、処理はステップＳ９１３に移行する。

　ステップＳ９１２でポーズ制御部１１２は、ステップＳ９１０の検索の結果見つかったエントリの「ポーズ要求フレーム送信時刻」に、ステップＳ９０７で取得した時刻を設定する。そして、処理はステップＳ９０８に戻る。

　また、ステップＳ９１３でポーズ制御部１１２は、ステップＳ９０９で選んだＧＤと、ステップＳ９０７で取得した時刻とを有する新たなエントリを、ポーズ履歴テーブル１２７に追加する。そして、処理はステップＳ９０８に戻る。

　さて、図２７は、ポーズ要求フレーム送信処理の第２の例のフローチャートである。図２７の処理も、ビジー検出部１１３からポーズ制御部１１２への指示を契機として開始される。

　ステップＳ１００１でポーズ制御部１１２は、タイマ１０９が示す現在時刻を、ポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅに設定する。また、ポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳを「Ｐ」状態に設定する。

　そして、ステップＳ１００２でポーズ制御部１１２は、ポーズ対象ＧＤ決定処理を行う。ポーズ対象ＧＤ決定処理は、図３１～３４のいずれに示す処理でもよい。ポーズ対象ＧＤ決定処理により、ポーズ制御部１１２は、１つ以上のＧＤを、ポーズ対象ＧＤ（すなわちポーズ要求フレームに指定するＧＤ）として決定する。

　続いて、ステップＳ１００３でポーズ制御部１１２は、ルーティングテーブル１２１の、ステップＳ１００２で決定した１つ以上のＧＤにそれぞれ対応する各エントリで、「ポーズＧＤ」を、「選択中」を示す値（図７の例では「１」）に設定する。

　そして、ステップＳ１００４でポーズ制御部１１２は、ビジー検出部１１３から通知されたビジー状況に応じて、ポーズカウンタ値を決定し、決定した値を、ポーズ状態管理テーブル１２５のカウンタＳＣｏｕｎｔにも設定する。ステップＳ１００４の詳細はステップＳ９０４と同様である。

　続いて、ステップＳ１００５でポーズ制御部１１２は、ステップＳ１００２で決定した１つ以上のＧＤのうち、ステップＳ１００６以降の処理をまだ行っていない未処理のものがあるか否かを判断する。未処理のＧＤがある場合、続いてステップＳ１００６が実行され、ステップＳ１００２で決定したすべてのＧＤに対してステップＳ１００６以降の処理が済んでいる場合、ポーズ要求フレーム送信処理は終了する。

　ステップＳ１００６でポーズ制御部１１２は、ステップＳ１００２で決定した１つ以上のＧＤのうち、未処理のＧＤを１つ選ぶ。
　そして、ステップＳ１００７でポーズ制御部１１２は、ステップＳ１００６で選んだ１つのＧＤと、ステップＳ１００４で決定したポーズカウンタ値とを含むポーズ要求フレームを生成する。つまり、ポーズ制御部１１２は、図１３のポーズ制御情報４４０ａを含むポーズフレーム４３０を生成する。なお、ポーズ制御部１１２は、ポーズ要求フレームのタイプ４１３には、ポーズフレームであることを示す値を設定する。

　そして、ステップＳ１００８でポーズ制御部１１２は、生成したポーズ要求フレームの送信を送信フレーム制御部１１０に依頼する。すると、送信フレーム制御部１１０は、通信装置１００の全ポートを送信先ポートとして送信部１１１に指示する。よって、送信部１１１は、生成されたポーズ要求フレームを全ポートから送信する。

　続いて、ステップＳ１００９でポーズ制御部１１２は、タイマ１０９から現在時刻を取得し、記憶する。
　そして、ステップＳ１０１０でポーズ制御部１１２は、ステップＳ１００６で選んだＧＤを検索キーにして、ポーズ履歴テーブル１２７を検索する。

　さらに、ステップＳ１０１１でポーズ制御部１１２は、ステップＳ１０１０の検索の結果、エントリが見つかったか否かを判断する。エントリが見つかった場合、処理はステップＳ１０１２に移行し、エントリが存在しなかった場合、処理はステップＳ１０１３に移行する。

　ステップＳ１０１２でポーズ制御部１１２は、ステップＳ１０１０の検索の結果見つかったエントリの「ポーズ要求フレーム送信時刻」に、ステップＳ１００９で取得した時刻を設定する。そして、処理はステップＳ１００５に戻る。

　また、ステップＳ１０１３でポーズ制御部１１２は、ステップＳ１００６で選んだＧＤと、ステップＳ１００９で取得した時刻とを有する新たなエントリを、ポーズ履歴テーブル１２７に追加する。そして、処理はステップＳ１００５に戻る。

　続いて、ポーズ解除フレーム送信処理の３つの例を説明する。
　図２８は、ポーズ解除フレーム送信処理の第１の例のフローチャートである。図２８の処理は、ビジー検出部１１３からポーズ制御部１１２への指示を契機として開始される。

　ステップＳ１１０１でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅをクリアする。
　また、ステップＳ１１０２でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のカウンタＳＣｏｕｎｔの値をクリアする。

　そして、ステップＳ１１０３でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳを「Ｎ」状態（つまり通常状態）に設定する。
　さらに、ステップＳ１１０４でポーズ制御部１１２は、ルーティングテーブル１２１のすべてのエントリで、「ポーズＧＤ」を、「非選択」を示す値（具体的には、第１実施形態では「０」）に設定する。

　また、ステップＳ１１０５でポーズ制御部１１２は、制御タイプ４４５にポーズ解除フレームであることを示す値を設定し、カウンタ４４７として０を設定したポーズ制御情報４４０ｅを含むポーズ解除フレームを生成する。なお、ポーズ制御部１１２は、ポーズ解除フレームのタイプ４１３には、ポーズフレームであることを示す値を設定する。

　次のステップＳ１１０６でポーズ制御部１１２は、ステップＳ１１０５で生成したポーズ解除フレームを送信するよう送信フレーム制御部１１０に要求する。すると、送信フレーム制御部１１０は、全ポートを送信先ポートとして決定し、送信部１１１を制御する。送信部１１１は、生成されたポーズ解除フレームを、送信フレーム制御部１１０による制御にしたがって、全ポートから送信する。すなわち、送信部１１１は、すべての隣接ノードに、ポーズ解除フレームを送信する。そして、図２８のポーズ解除フレーム送信処理は終了する。

　図２９は、ポーズ解除フレーム送信処理の第２の例のフローチャートである。図２９の処理も、ビジー検出部１１３からポーズ制御部１１２への指示を契機として開始される。
　ステップＳ１２０１でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅをクリアする。

　また、ステップＳ１２０２でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のカウンタ値ＳＣｏｕｎｔをクリアする。
　そして、ステップＳ１２０３でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳを「Ｎ」状態（つまり通常状態）に設定する。

　さらに、ステップＳ１２０４でポーズ制御部１１２は、「ＧＤリスト」を空に初期化する。このＧＤリストは、図２９の処理においてポーズ制御部１１２が使用するローカルなデータである。

　ステップＳ１２０５でポーズ制御部１１２は、ルーティングテーブル１２１のすべてのエントリに注目したか否か、すなわち、すべてのエントリに関してステップＳ１２０６以降の処理を行ったか否かを判断する。まだステップＳ１２０６以降の処理を行っていないエントリがルーティングテーブル１２１に残っている場合、処理はステップＳ１２０６に移行し、すべてのエントリが注目済みのとき、処理はステップＳ１２１０に移行する。

　ステップＳ１２０６でポーズ制御部１１２は、ルーティングテーブル１２１においてまだ注目していないエントリを１つ選び、選んだエントリに注目する。以下、ステップＳ１２０６で選ばれたエントリを「注目エントリ」という。

　そして、ステップＳ１２０７でポーズ制御部１１２は、注目エントリにおいて、「ポーズＧＤ」の値が、「選択中」を示す値であるか否かを判断する。
　「ポーズＧＤ」の値が、「選択中」を示す値であるとき、注目エントリの「宛先」のＧＤは、通信装置１００がかつて送信したポーズ要求フレームにおいて指定されたＧＤである。よって、処理はステップＳ１２０８に移行する。

　逆に、「ポーズＧＤ」の値が、「非選択」を示す値であるとき、注目エントリの「宛先」のＧＤは、通信装置１００がかつて送信したポーズ要求フレームにおいて指定されたＧＤではない。よって、注目エントリの「宛先」のＧＤは、そもそも解除の通知を行う対象ではないので、処理はステップＳ１２０５に戻る。

　そして、ステップＳ１２０８でポーズ制御部１１２は、ルーティングテーブル１２１の注目エントリで、「ポーズＧＤ」を、「非選択」を示す値に設定する。
　また、ステップＳ１２０９でポーズ制御部１１２は、ルーティングテーブル１２１の注目エントリに「宛先」として含まれるＧＤを、ＧＤリストに追加する。そして、処理はステップＳ１２０５に戻る。

　また、ポーズ制御部１１２は、ルーティングテーブル１２１のすべてのエントリに注目し終わると、ステップＳ１２１０で、ポーズ解除フレームを生成する。具体的には、ポーズ制御部１１２は、ステップＳ１２０４で初期化した後でステップＳ１２０９においてＧＤを追加することで最終的に得られたＧＤリストをＧＤリスト４４８として含み、カウンタ４４７として０を設定したポーズ解除フレームを生成する。つまり、ポーズ制御部１１２は、ポーズ制御情報４４０ｄを含むポーズフレーム４３０を生成する。なお、ポーズ制御部１１２は、ポーズ解除フレームのタイプ４１３には、ポーズフレームであることを示す値を設定する。

　そして、次のステップＳ１２１１でポーズ制御部１１２は、ステップＳ１２１０で生成したポーズ解除フレームを送信するよう送信フレーム制御部１１０に要求する。すると、送信フレーム制御部１１０は、全ポートを送信先ポートとして決定し、送信部１１１を制御する。送信部１１１は、生成されたポーズ解除フレームを、送信フレーム制御部１１０による制御にしたがって、全ポートから送信する。すなわち、送信部１１１は、すべての隣接ノードに、ポーズ解除フレームを送信する。そして、図２９のポーズ解除フレーム送信処理は終了する。

　図３０は、ポーズ解除フレーム送信処理の第３の例のフローチャートである。図３０の処理も、ビジー検出部１１３からポーズ制御部１１２への指示を契機として開始される。
　ステップＳ１３０１でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ開始時刻ＳｔａｒｔＴｉｍｅをクリアする。

　また、ステップＳ１３０２でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のカウンタ値ＳＣｏｕｎｔをクリアする。
　そして、ステップＳ１３０３でポーズ制御部１１２は、ポーズ状態管理テーブル１２５のポーズ状態ＳＳを「Ｎ」状態（つまり通常状態）に設定する。

　次に、ステップＳ１３０４でポーズ制御部１１２は、ルーティングテーブル１２１のすべてのエントリに注目したか否か、すなわち、すべてのエントリに関してステップＳ１３０５以降の処理を行ったか否かを判断する。まだステップＳ１３０５以降の処理を行っていないエントリがルーティングテーブル１２１に残っている場合、処理はステップＳ１３０５に移行し、すべてのエントリが注目済みのとき、ポーズ解除フレーム送信処理は終了する。

　ステップＳ１３０５でポーズ制御部１１２は、ルーティングテーブル１２１においてまだ注目していないエントリを１つ選び、選んだエントリに注目する。以下、ステップＳ１３０５で選ばれたエントリを「注目エントリ」という。

　そして、ステップＳ１３０６でポーズ制御部１１２は、注目エントリにおいて、「ポーズＧＤ」の値が、「選択中」を示す値であるか否かを判断する。
　「ポーズＧＤ」の値が、「選択中」を示す値であるとき、注目エントリの「宛先」のＧＤは、通信装置１００がかつて送信したポーズ要求フレームにおいて指定されたＧＤである。よって、処理はステップＳ１３０７に移行する。

　逆に、「ポーズＧＤ」の値が、「非選択」を示す値であるとき、注目エントリの「宛先」のＧＤは、通信装置１００がかつて送信したポーズ要求フレームにおいて指定されたＧＤではない。よって、注目エントリの「宛先」のＧＤは、そもそも解除の通知を行う対象ではないので、処理はステップＳ１３０４に戻る。

　そして、ステップＳ１３０７でポーズ制御部１１２は、ルーティングテーブル１２１の注目エントリで、「ポーズＧＤ」を、「非選択」を示す値に設定する。
　また、ステップＳ１３０８でポーズ制御部１１２は、ルーティングテーブル１２１の注目エントリに「宛先」として含まれるＧＤをＧＤ４４６として含み、カウンタ４４７として０を設定したポーズ解除フレームを生成する。つまり、ポーズ制御部１１２は、ポーズ制御情報４４０ｃを含むポーズフレーム４３０を生成する。なお、ポーズ制御部１１２は、ポーズ解除フレームのタイプ４１３には、ポーズフレームであることを示す値を設定する。

　そして、次のステップＳ１３０９でポーズ制御部１１２は、ステップＳ１３０８で生成したポーズ解除フレームを送信するよう送信フレーム制御部１１０に要求する。すると、送信フレーム制御部１１０は、全ポートを送信先ポートとして決定し、送信部１１１を制御する。送信部１１１は、生成されたポーズ解除フレームを、送信フレーム制御部１１０による制御にしたがって、全ポートから送信する。すなわち、送信部１１１は、すべての隣接ノードに、ポーズ解除フレームを送信する。そして、処理はステップＳ１３０４に戻る。

　続いて、図２６のステップＳ９０２または図２７のステップＳ１００２において、ポーズ要求フレームに指定するＧＤ（以下「ポーズ対象」という）を決めるために実行されるポーズ対象ＧＤ決定処理の４つの例について、詳しく説明する。

　図３１は、ポーズ対象ＧＤ決定処理の第１の例のフローチャートである。図３１の処理は、他のノードへの影響を小さくすることを優先する処理である。また、図３１の処理では１つだけＧＤがポーズ対象として決定されるので、図３１の処理は図１３のポーズ制御情報４４０ａの形式に特に好適である。

　ステップＳ１４０１でポーズ制御部１１２は、「バッファカウンタ」の昇順にバッファ使用中ＧＤテーブル１２６のエントリをソートする。
　そして、ステップＳ１４０２でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６の１番目のエントリのＧＤを選択する。すなわち、ポーズ制御部１１２は、「バッファカウンタ」の値が最小のＧＤを選択する。

　次のステップＳ１４０３でポーズ制御部１１２は、今回のポーズ対象を決定する際に、ポーズ制御部１１２が今までポーズ対象としてどのＧＤを選んできたのかという履歴を考慮するか否かを判断する。

　例えば、通信装置１００の動作パラメタとして、履歴を考慮するか否かを指定する値が設定されていてもよく、具体的には、「履歴考慮モード」と「履歴不使用モード」のような２つの動作モードのいずれかが通信装置１００に設定されていてもよい。その場合、ポーズ制御部１１２は、動作モードの値にしたがってステップＳ１４０３の判断を行う。

　あるいは、通信装置１００は、固定的に履歴考慮モードと履歴不使用モードのどちらで動作するかが決められた装置であってもよい。その場合、ポーズ制御部１１２は、暗黙裡に固定的に決められた動作モードの値にしたがってステップＳ１４０３の判断を行う。

　そして、今回のポーズ対象を決定する際に履歴を考慮する場合、処理はステップＳ１４０５に移行し、履歴を考慮しない場合、処理はステップＳ１４０４に移行する。
　ステップＳ１４０４でポーズ制御部１１２は、ステップＳ１４０２または後述のステップＳ１４０８で選択したＧＤをポーズ対象に決定する。そして、ポーズ対象ＧＤ決定処理は終了する。

　また、ステップＳ１４０５でポーズ制御部１１２は、ステップＳ１４０２または後述のステップＳ１４０８で選択したＧＤを検索キーにして、ポーズ履歴テーブル１２７を検索する。

　そして、ステップＳ１４０６でポーズ制御部１１２は、ステップＳ１４０５の検索の結果、エントリが見つかったか否かを判断する。エントリが見つからなかった場合、処理はステップＳ１４０４に移行し、エントリが見つかった場合、処理はステップＳ１４０７に移行する。

　ステップＳ１４０７でポーズ制御部１１２は、現在選択中のＧＤ（つまりステップＳ１４０２または後述のステップＳ１４０８で選択したＧＤ）が、バッファ使用中ＧＤテーブル１２６の最後のエントリのＧＤであるか否かを判断する。そして、現在選択中のＧＤが最後のエントリのＧＤのとき、処理はステップＳ１４０９に移行する。他方、現在選択中のＧＤが最後以外のエントリのＧＤのとき、処理はステップＳ１４０８に移行する。

　そして、ステップＳ１４０８でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、現在選択中のＧＤを含むエントリの次のエントリのＧＤを、選択する。そして、処理はステップＳ１４０５に戻る。

　また、ステップＳ１４０９でポーズ制御部１１２は、ステップＳ１４０１でソートされたバッファ使用中ＧＤテーブル１２６の１番目のエントリのＧＤをポーズ対象に決定する。そして、ポーズ対象ＧＤ決定処理は終了する。

　以上の図３１のポーズ対象ＧＤ決定処理によれば、他のノードへの影響を小さくすることを優先して、ポーズ対象が１つ決定される。図１～５を参照して説明したように、ポーズ要求フレームの送信は、他のノードをビジー状態に陥れるおそれがある。そして、バッファ使用中ＧＤテーブル１２６の「バッファカウンタ」の値が大きいほど、ポーズ要求フレームが他のノードに与える影響が大きく、他のノードがビジー状態に陥る蓋然性も高い。そこで、図３１の処理では、他のノードへの影響を小さくするために上記のような各ステップの処理が行われる。

　すなわち、ポーズ制御部１１２が履歴を考慮しない場合は、「バッファカウンタ」が最小のＧＤがポーズ対象として選ばれる（ステップＳ１４０２とＳ１４０４を参照）。
　また、ポーズ制御部１１２が履歴を考慮する場合は、ポーズ対象として選択しない方が好ましいＧＤがポーズ対象の候補から除外される（ステップＳ１４０５とＳ１４０６を参照）。そして、その他のＧＤのうちで「バッファカウンタ」が最小のＧＤが、ポーズ対象として選ばれる（なぜなら、ステップＳ１４０１でバッファ使用中ＧＤテーブル１２６が昇順にソートされており、１番目のエントリから順に注目されるので）。

　なお、上記の「ポーズ対象として選択しない方が好ましいＧＤ」について補足すると、次のとおりである。
　ポーズ履歴テーブル１２７に、ＧＤ_ｉとＰＴ_ｉを含むエントリがあり、かつ、同じＧＤ_ｉを含むエントリがバッファ使用中ＧＤテーブル１２６にあるということは、次のことを意味する。

　・ＧＤ_ｉを指定したポーズ要求フレームが時刻ＰＴ_ｉに送信された。なお、時刻ＰＴ_ｉは、比較的最近の時刻である（なぜなら、ＧＤ_ｉとＰＴ_ｉを含むエントリがエージングされずに残っているので）。

　・それにもかかわらず、ＧＤ_ｉ宛のフレームのＬＤとして、通信装置１００を選択する隣接ノードが存在する。そのせいで、同じＧＤ_ｉを含むエントリが、通信装置１００のバッファ使用中ＧＤテーブル１２６に存在している。

　・つまり、上記隣接ノードは、時刻ＰＴ_ｉに送信されたポーズ要求フレームの受信を契機として、ＧＤ_ｉ宛のフレームのＬＤとして通信装置１００以外のノードを選択するように、経路選択の方針を変えたはずである。しかし、時刻ＰＴ_ｉより後に通信装置１００が送信したポーズ解除フレームの受信後は、上記隣接ノードは、再びＧＤ_ｉ宛のフレームのＬＤとして通信装置１００を選ぶようになった。

　・換言すれば、上記隣接ノードにとっては、ＧＤ_ｉ宛のフレームのＬＤとして通信装置１００が最適である。あるいは、上記隣接ノードにとっては、ＧＤ_ｉ宛のフレームのＬＤとして選択可能なのは、通信装置１００のみである。

　・よって、ＧＤ_ｉを指定したポーズ要求フレームを通信装置１００が送信することは、上記隣接ノードにとっては明らかに不適切な経路選択を上記隣接ノードに対して強いることを意味する。したがって、上記隣接ノードへの影響を考慮すると、ＧＤ_ｉは、ポーズ対象として選択しない方が好ましいＧＤである。

　つまり、ポーズ履歴テーブル１２７は、ポーズ対象として選択しない方が好ましいＧＤの記録のために使われる。そして、図３１の処理によれば、ポーズ対象として選択しない方が好ましいＧＤ以外のＧＤのうちで「バッファカウンタ」が最小のＧＤが、ポーズ対象として選ばれる。なお、すべてのＧＤが、ポーズ対象として選択しない方が好ましいＧＤである場合は、「バッファカウンタ」が最小のＧＤが、ステップＳ１４０９でポーズ対象として選ばれる。

　図３２は、ポーズ対象ＧＤ決定処理の第２の例のフローチャートである。図３２の処理は、他のノードへの影響が大きくなりすぎない範囲で、できるだけ通信装置１００の負荷を減らそうとする処理である。また、図３２の処理では複数のＧＤがポーズ対象として決定されることがあるので、図３２の処理が行われる場合、図１３のポーズ制御情報４４０ｂの形式のポーズ制御情報４４０を含むポーズフレーム４３０が使われる。

　ステップＳ１５０１でポーズ制御部１１２は、図３２の処理を行うための内部データである「合計値」を０に初期化する。
　また、ステップＳ１５０２でポーズ制御部１１２は、基準値を取得する。基準値は、予め固定的に決められて、通信装置１００内の不揮発性記憶装置に記憶された値でもよい。固定的に決められる基準値は、他のノードへの影響が大きすぎないように（換言すれば、他のノードをビジー状態に陥れる蓋然性が低くなるように）、例えば予備実験やシミュレーションに基づいて決められることが好ましい。

　あるいは、基準値は、ポーズ制御部１１２が動的に計算することで取得する値でもよい。例えば、ポーズ制御部１１２は、ビジー検出部１１３から通知された、ビジー状況を表す値と、通信装置１００がビジー状態か否かの判断に使われる閾値との差を計算し、計算した差を基準値として取得してもよい。あるいは、ポーズ制御部１１２は、計算した差に、所定のマージンを加えた値を、基準値として取得してもよい。

　そして、ステップＳ１５０３でポーズ制御部１１２は、「バッファカウンタ」の昇順にバッファ使用中ＧＤテーブル１２６のエントリをソートする。
　次のステップＳ１５０４でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６の１番目のエントリのＧＤを選択する。すなわち、ポーズ制御部１１２は、「バッファカウンタ」の値が最小のＧＤを選択する。

　ステップＳ１５０５でポーズ制御部１１２は、今回のポーズ対象を決定する際に、ポーズ制御部１１２が今までポーズ対象としてどのＧＤを選んできたのかという履歴を考慮するか否かを判断する。ステップＳ１５０５の判断は、図３１のステップＳ１４０３の判断と同様である。そして、今回のポーズ対象を決定する際に履歴を考慮する場合、処理はステップＳ１５１３に移行し、履歴を考慮しない場合、処理はステップＳ１５０６に移行する。

　ステップＳ１５０６でポーズ制御部１１２は、ステップＳ１５０４または後述のステップＳ１５１０で選択したＧＤをポーズ対象に決定する。
　そして、ステップＳ１５０７でポーズ制御部１１２は、ステップＳ１５０４または後述のステップＳ１５１０で選択したＧＤ（すなわちポーズ対象に決定したＧＤ）の「バッファカウンタ」を、合計値に足す。そして、ポーズ制御部１１２は、加算結果を新たな合計値として記憶する。

　続いて、ステップＳ１５０８でポーズ制御部１１２は、合計値が基準値以上か否かを判断する。合計値が基準値以上のとき、図３２のポーズ対象ＧＤ決定処理は終了する。合計値が基準値未満のとき、さらにポーズ対象のＧＤを選ぶため、処理はステップＳ１５０９に移行する。

　そして、ステップＳ１５０９でポーズ制御部１１２は、現在選択中のＧＤ（つまりステップＳ１５０４または後述のステップＳ１５１０で選択したＧＤ）が、バッファ使用中ＧＤテーブル１２６の最後のエントリのＧＤであるか否かを判断する。そして、現在選択中のＧＤが最後のエントリのＧＤのとき、処理はステップＳ１５１１に移行する。他方、現在選択中のＧＤが最後以外のエントリのＧＤのとき、処理はステップＳ１５１０に移行する。

　そして、ステップＳ１５１０でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、現在選択中のＧＤを含むエントリの次のエントリのＧＤを、選択する。そして、処理はステップＳ１５０５に戻る。

　また、ステップＳ１５１１でポーズ制御部１１２は、今までにステップＳ１５０６でポーズ対象に決定したＧＤが１つ以上あるか否かを判断する。ポーズ対象に決定されたＧＤが存在する場合、図３２の処理は終了する。ポーズ対象に決定されたＧＤが存在しない場合、処理はステップＳ１５１２に移行する。

　そして、ステップＳ１５１２でポーズ制御部１１２は、ステップＳ１５０３でソートされたバッファ使用中ＧＤテーブル１２６の１番目のエントリのＧＤをポーズ対象に決定する。そして、ポーズ対象ＧＤ決定処理は終了する。

　また、ポーズ制御部１１２が履歴を考慮する場合、ステップＳ１５１３でポーズ制御部１１２は、ステップＳ１５０４またはステップＳ１５１０で選択したＧＤを検索キーにして、ポーズ履歴テーブル１２７を検索する。

　そして、ステップＳ１５１４でポーズ制御部１１２は、ステップＳ１５１３の検索の結果、エントリが見つかったか否かを判断する。エントリが見つからなかった場合、処理はステップＳ１５０６に移行し、エントリが見つかった場合、処理はステップＳ１５０９に移行する。

　以上の図３２のポーズ対象ＧＤ決定処理では、他のノードへの影響が大きすぎない範囲を規定する基準値が使われる。そして、他のノードへの影響が大きくなりすぎない範囲で、できるだけ多くのＧＤがポーズ対象として決定され、できるだけ通信装置１００の負荷軽減が図られる。

　すなわち、ポーズ制御部１１２が履歴を考慮しない場合は、「バッファカウンタ」の合計値がはじめて基準値以上になるまで、「バッファカウンタ」の小さいＧＤから順に、１つ以上のＧＤが、ポーズ対象として選ばれる。

　また、ポーズ制御部１１２が履歴を考慮する場合は、ポーズ対象として選択しない方が好ましいＧＤがポーズ対象の候補から除外され、その他のＧＤの中からポーズ対象が選ばれる。具体的には、「バッファカウンタ」の合計値がはじめて基準値以上になるまで、「バッファカウンタ」の小さいＧＤから順に、候補から除外されていない１つ以上のＧＤが、ポーズ対象として選ばれる。

　なお、すべてのＧＤが、ポーズ対象として選択しない方が好ましいＧＤである場合は、「バッファカウンタ」が最小のＧＤが、ステップＳ１５１２でポーズ対象として選ばれる。ステップＳ１５１２は、「バッファカウンタ」が基準値に最も近いＧＤ、あるいは「バッファカウンタ」が基準値以下のＧＤのうちで「バッファカウンタ」が最大のＧＤを選ぶ処理に置き換えられてもよい。

　また、図３２では、ステップＳ１５０６～Ｓ１５０８に示すように、合計値がはじめて基準値以上になった時点で、ポーズ制御部１１２は、新たなＧＤをポーズ対象に追加しないように振る舞う。よって、合計値が基準値を超えることもある。しかし、実施形態によっては、ポーズ制御部１１２は、合計値が基準値を超えないという制約条件下でポーズ対象のＧＤを決定してもよい。

　図３３は、ポーズ対象ＧＤ決定処理の第３の例のフローチャートである。図３３の処理は、他のノードへの影響が大きくなりすぎない範囲で、できるだけ通信装置１００の負荷を減らそうとする点で、図３２の処理に似ている。しかし、図３２の処理では、「バッファカウンタ」の値の小さい複数のＧＤがポーズ対象として選ばれることがあるのに対し、図３３の処理では、ポーズ対象として選択するＧＤの数を１つに限定するために、２つの閾値が使われる。

　多数のＧＤがポーズ要求フレームに指定されると、多数のＧＤに関してそれぞれ隣接ノードが経路選択の方針を変更する（つまりルーティングテーブル１２１を書き換える）ことになる。よって、環境（例えば、ネットワークトポロジや、どの経路をどれ程のフレームが送信されるか）によっては、ネットワーク全体でフレームのルーティング経路が不安定になるおそれがある。あるいは、多くのノードで、経路切り替えのための処理にＭＰＵなどの資源が使われ、ノードの処理負荷が高まるかもしれない。

　よって、図３３の処理では、ポーズ対象として選択するＧＤの数が１つに限定される。具体的には、図３３の処理は、第１閾値と第２閾値を用いて、以下のようにして行われる。なお、第１閾値は第２閾値未満である。

　ステップＳ１６０１でポーズ制御部１１２は、「バッファカウンタ」の降順にバッファ使用中ＧＤテーブル１２６のエントリをソートする。
　次のステップＳ１６０２でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、「バッファカウンタ」の値が第２閾値以下となる最初のエントリを調べる。

　そして、ステップＳ１６０３でポーズ制御部１１２は、ステップＳ１６０２においてエントリが見つかったか否かを判断する。エントリが見つからなかった場合、処理はステップＳ１６０４に移行する。逆に、エントリが見つかった場合、処理はステップＳ１６０５に移行する。

　なお、第２閾値は、例えば固定的に定められた値である。第２閾値は、他のノードへの影響が大きすぎないように（換言すれば、ポーズ要求フレームを契機として他のノードをビジー状態に陥れる蓋然性が低くなるように）、例えば予備実験やシミュレーションに基づいて決められることが好ましい。また、第２閾値は、他のノードへの影響が大きすぎない範囲で、できるだけ大きな値であることが好ましい。

　ステップＳ１６０４でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６の最後のエントリのＧＤをポーズ対象に決定する。すなわち、バッファ使用中ＧＤテーブル１２６のすべてのエントリの「バッファカウンタ」の値が第２閾値を超えている場合、「バッファカウンタ」の値が最小のＧＤがポーズ対象として決定される。決定後、ポーズ対象ＧＤ決定処理は終了する。

　また、ステップＳ１６０５でポーズ制御部１１２は、ステップＳ１６０１でのソート後のバッファ使用中ＧＤテーブル１２６の最初のエントリの「バッファカウンタ」の値が、第１閾値以上であるか否かを判断する。第１閾値は、通信装置１００がビジー状態から回復するために減らすことが望ましい負荷の量を示す。

　なお、例えば、図２５の処理が行われる間隔がＸ秒であるとして、「Ｘ秒の間にバッファ使用総量カウンタ１１４の値がＹ以上増えることはない」ということが、回線速度や隣接ノードの数などから判明しているか、あるいは実験的に判明していることもある。その場合、第１閾値は、固定的に上記の値Ｙに定められていてもよい。

　あるいは、第１閾値は、ポーズ制御部１１２が動的に計算することで取得する値でもよい。例えば、ポーズ制御部１１２は、ビジー検出部１１３から通知された、ビジー状況を表す値と、通信装置１００がビジー状態か否かの判断に使われる閾値との差を計算し、計算した差を第１閾値として用いてもよい。または、ポーズ制御部１１２は、計算した差に、所定のマージンを加えた値を、第１閾値として用いてもよい。

　そして、最初のエントリの「バッファカウンタ」の値が、第１閾値未満の場合、処理はステップＳ１６０６に移行する。逆に、最初のエントリの「バッファカウンタ」の値が、第１閾値以上の場合、処理はステップＳ１６０７に移行する。

　ステップＳ１６０６でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６の最初のエントリのＧＤをポーズ対象に決定する。すなわち、バッファ使用中ＧＤテーブル１２６のすべてのエントリの「バッファカウンタ」の値が第１閾値未満の場合、「バッファカウンタ」の値が最大のＧＤがポーズ対象として決定される。決定後、ポーズ対象ＧＤ決定処理は終了する。

　そして、「バッファカウンタ」の値が第１閾値以上かつ第２閾値以下のエントリがバッファ使用中ＧＤテーブル１２６に存在する場合に、ステップＳ１６０７以下の処理が行われる。具体的に、ステップＳ１６０７でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、「バッファカウンタ」の値が第２閾値以下となる最初のエントリのＧＤを選択する。

　続いて、ステップＳ１６０８でポーズ制御部１１２は、今回のポーズ対象を決定する際に、ポーズ制御部１１２が今までポーズ対象としてどのＧＤを選んできたのかという履歴を考慮するか否かを判断する。ステップＳ１６０８の判断は、図３１のステップＳ１４０３の判断と同様である。そして、今回のポーズ対象を決定する際に履歴を考慮する場合、処理はステップＳ１６１０に移行し、履歴を考慮しない場合、処理はステップＳ１６０９に移行する。

　ステップＳ１６０９でポーズ制御部１１２は、ステップＳ１６０７または後述のステップＳ１６１３で選択したＧＤをポーズ対象に決定する。そして、ポーズ対象ＧＤ決定処理は終了する。

　他方、ステップＳ１６１０では、ポーズ制御部１１２は、ステップＳ１６０７または後述のステップＳ１６１３で選択したＧＤを検索キーにして、ポーズ履歴テーブル１２７を検索する。

　そして、ステップＳ１６１１でポーズ制御部１１２は、ステップＳ１６１０の検索の結果、エントリが見つかったか否かを判断する。エントリが見つからなかった場合、処理はステップＳ１６０９に移行し、エントリが見つかった場合、処理はステップＳ１６１２に移行する。

　ステップＳ１６１２でポーズ制御部１１２は、現在選択中のＧＤ（つまりステップＳ１６０７または後述のステップＳ１６１３で選択したＧＤ）が、バッファ使用中ＧＤテーブル１２６の、見つけた範囲内で最後のエントリのＧＤか否かを判断する。なお、ここで、「見つけた範囲」とは、「バッファカウンタ」の値が第１閾値以上第２閾値以下である範囲のことである。現在選択中のＧＤが、見つけた範囲内で最後のエントリのＧＤである場合、処理はステップＳ１６１４に移行する。他方、現在選択中のＧＤが見つけた範囲内で最後ではないエントリのＧＤのとき、処理はステップＳ１６１３に移行する。

　そして、ステップＳ１６１３でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、現在選択中のＧＤを含むエントリの次のエントリのＧＤを、選択する。そして、処理はステップＳ１６１０に戻る。

　また、ステップＳ１６１４でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６において、「バッファカウンタ」の値が第２閾値以下となる最初のエントリのＧＤをポーズ対象に決定する。

　以上の図３３のポーズ対象ＧＤ決定処理では、通信装置１００自身のビジー状態を解消するのに有効なレベルを示す第１閾値と、他のノードへ悪影響を与えにくいレベルの上限を示す第２閾値が使われる。そして、「バッファカウンタ」の値が、第１閾値以上第２閾値以下という特定範囲内のＧＤがもしあれば、「バッファカウンタ」の値が特定範囲内のＧＤがポーズ対象に決定される。逆に、「バッファカウンタ」の値が特定範囲外のＧＤしかなければ、「バッファカウンタ」の値が特定範囲に最も近いＧＤがポーズ対象に決定される。

　また、「バッファカウンタ」の値が特定範囲内のＧＤがある場合において、履歴が考慮されないのであれば、「バッファカウンタ」の値が第２閾値に最も近いＧＤがポーズ対象に決定される。逆に、履歴が考慮される場合は、ポーズ対象として選択しない方が好ましいＧＤがポーズ対象の候補から除外され、その他のＧＤの中から、「バッファカウンタ」の値が特定範囲内という制約条件下で「バッファカウンタ」の値が最大のＧＤがポーズ対象として決定される。なお、「バッファカウンタ」の値が特定範囲内のすべてのＧＤが、ポーズ対象として選択しない方が好ましいＧＤである場合、「バッファカウンタ」の値が特定範囲内という制約条件下で「バッファカウンタ」の値が最大のＧＤがポーズ対象として決定される。

　図３４は、ポーズ対象ＧＤ決定処理の第４の例のフローチャートである。この第４の例は、第１～第３の例（および、ポーズ対象ＧＤ決定処理に関するその他の不図示の様々な変形例）を一般化して表したものである。

　ステップＳ１７０１でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６に記録されており、かつ、まだポーズ制御部１１２がポーズ対象として選択していないＧＤの中から、所定の基準を満たすＧＤを探す。なお、上記「所定の基準」は、例えば、１つまたは２つの閾値で規定される範囲内に「バッファカウンタ」の値が含まれるという基準でもよく、具体的には、以下のような基準でもよい。
　・「バッファカウンタ」の値が、ある閾値以上である。
　・「バッファカウンタ」の値が、ある閾値以下である。
　・「バッファカウンタ」の値が、２つの閾値ではさまれた範囲内である。
　・「バッファカウンタ」の値は、既にポーズ対象として決定したＧＤの「バッファカウンタ」の値の合計値との和が、ある閾値以下となるような値である。
　あるいは、上記「所定の基準」は、「バッファカウンタ」の値が任意でよい、ということを示す基準でもよい。

　そして、次のステップＳ１７０２でポーズ制御部１１２は、ステップＳ１７０１でＧＤが１つ以上見つかったか否かを判断する。ステップＳ１７０１でＧＤが１つ以上見つかった場合、処理はステップＳ１７０３に移行する。逆に、ＧＤが１つも見つからなかった場合、処理はステップＳ１７０９に移行する。

　ステップＳ１７０３でポーズ制御部１１２は、ステップＳ１７０１での探索の結果見つかった１つ以上のＧＤの中で、基準に照らして最適な１つのＧＤを選ぶ。例えば、図３１と図３２の例では、基準に照らして最適なＧＤとは、見つかった１つ以上のＧＤの中で、「バッファカウンタ」の値が最小のＧＤである。また、図３３の例では、基準に照らして最適なＧＤとは、見つかった１つ以上のＧＤの中で、「バッファカウンタ」の値が最大のＧＤである。実施形態によっては、見つかった１つ以上のＧＤの中での「バッファカウンタ」の値の分布に応じて、その他のＧＤが最適なＧＤとして選ばれてもよい。

　そして、ステップＳ１７０４でポーズ制御部１１２は、今回のポーズ対象を決定する際に、ポーズ制御部１１２が今までポーズ対象としてどのＧＤを選んできたのかという履歴を考慮するか否かを判断する。ステップＳ１７０４の判断は、図３１のステップＳ１４０３の判断と同様である。そして、今回のポーズ対象を決定する際に履歴を考慮する場合、処理はステップＳ１７０７に移行し、履歴を考慮しない場合、処理はステップＳ１７０５に移行する。

　ステップＳ１７０５でポーズ制御部１１２は、ステップＳ１７０３で選択したＧＤをポーズ対象に決定する。
　そして、次のステップＳ１７０６でポーズ制御部１１２は、終了条件が満たされているか否かを判断する。終了条件は、例えば以下のような条件であってもよいし、以下のような条件を２つ以上、選言的あるいは連言的に組み合わせた条件でもよい。
　・所定個数（例えば１個でもよい）のＧＤがポーズ対象として決定されている。
　・ポーズ対象として決定したＧＤの「バッファカウンタ」の値の合計値が、基準値以上である。
　・バッファ使用中ＧＤテーブル１２６に記録されているＧＤがもうない。

　そして、終了条件が満たされるとき、ポーズ対象ＧＤ決定処理は終了する。逆に、終了条件が満たされないとき、処理はステップＳ１７０１に戻る。
　また、今回のポーズ対象を決定する際に履歴を考慮する場合、ステップＳ１７０７でポーズ制御部１１２は、ステップＳ１７０３で選んだＧＤが除外対象か否かを判断する。すなわち、図３１のステップＳ１４０５～Ｓ１４０６と同様に、ポーズ制御部１１２は、ポーズ履歴テーブル１２７を検索することで、ステップＳ１７０３で選んだＧＤが、ポーズ対象として選択しない方が好ましいＧＤ（すなわち除外対象）か否かを判断する。

　ステップＳ１７０３で選んだＧＤが除外対象のとき、処理はステップＳ１７０８に移行し、ステップＳ１７０３で選んだＧＤが除外対象ではないとき、処理はステップＳ１７０５に移行する。

　そして、ステップＳ１７０８でポーズ制御部１１２は、次候補のＧＤがあるか否かを判断する。つまり、バッファ使用中ＧＤテーブル１２６に記録されているＧＤのうち、ステップＳ１７０１の所定の基準を満たすＧＤで、まだポーズ対象として選ばれていないＧＤが残っているか否かを判断する。ステップＳ１７０１の所定の基準を満たし、かつ、まだポーズ対象として選ばれていないＧＤが残っていれば、処理はステップＳ１７０１に戻る。逆に、ステップＳ１７０１の所定の基準を満たし、かつ、まだポーズ対象として選ばれていないＧＤがもうなければ、処理はステップＳ１７０９に移行する。

　ステップＳ１７０９でポーズ制御部１１２は、１つ以上のＧＤが既にステップＳ１７０５でポーズ対象として決定済みか否かを判断する。そして、１つ以上のＧＤがポーズ対象として決定済みならば、ポーズ対象ＧＤ決定処理は終了する。逆に、ポーズ対象として決定済みのＧＤが１つもない場合は、処理はステップＳ１７１０に移行する。

　ステップＳ１７１０でポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６に登録されているＧＤのうち、基準に照らして最適な１つのＧＤを、ポーズ対象に決定する。そして、ポーズ対象ＧＤ決定処理は終了する。

　なお、ステップＳ１７１０が実行されるのは、以下の２つのいずれかの場合である。
　・ステップＳ１７０１における「所定の基準」を満たすＧＤが存在しない場合
　・履歴を考慮する場合において、ステップＳ１７０１における「所定の基準」を満たすＧＤはすべてステップＳ１７０７の除外対象である場合
　また、ステップＳ１７１０の具体例は、図３１のステップＳ１４０９、図３２のステップＳ１５１２、図３３のステップＳ１６０４、Ｓ１６０６、Ｓ１６１４である。ステップＳ１７１０での決定後、ポーズ対象ＧＤ決定処理は終了する。

　さて、図３５は、ルーティングテーブルカウンタ処理のフローチャートである。図３５の処理は、タイマ１０９から定期的に出力されるトリガ（例えば割り込み信号）にしたがい、定期的にテーブル制御部１０６により行われる。なお、実施形態によっては、タイマ１０９からの出力にしたがい、ポーズ制御部１１２が図３５の処理を行ってもよい。

　ステップＳ１８０１でテーブル制御部１０６は、ルーティングテーブル１２１の１番目のエントリに着目する。そして、処理はステップＳ１８０２に移行する。
　ステップＳ１８０２でテーブル制御部１０６は、ステップＳ１８０１または後述のステップＳ１８１０で着目したエントリ（以下「着目エントリ」という）の１番目のポートに着目する。そして、処理はステップＳ１８０３に移行する。

　ステップＳ１８０３でテーブル制御部１０６は、着目エントリにおいて、ステップＳ１８０２または後述のステップＳ１８０８で着目したポート（以下「着目ポート」という）のカウンタの値が０であるか否かを判断する。カウンタの値が０の場合、処理はステップＳ１８０７に移行する。カウンタの値が０でない場合（すなわちカウンタの値が正の場合）、処理はステップＳ１８０４に移行する。

　ステップＳ１８０４でテーブル制御部１０６は、着目エントリの着目ポートのカウンタをカウントダウンする。
　そして次のステップＳ１８０５でテーブル制御部１０６は、着目エントリの着目ポートのカウンタの値が０であるか否かを再度判断する。カウンタの値が０の場合、処理はステップＳ１８０６に移行する。カウンタの値が０でない場合、処理はステップＳ１８０７に移行する。

　ステップＳ１８０６が実行されるのは、ステップＳ１８０４でのカウントダウンの結果として着目エントリの着目ポートのカウンタの値が０になった場合である。よって、ステップＳ１８０６でテーブル制御部１０６は、着目エントリの着目ポートのポート状態を、「Ｐ」状態から通常状態（すなわち「Ｅ」状態）に変更する。そして、処理はステップＳ１８０７に移行する。

　ステップＳ１８０７でテーブル制御部１０６は、まだ着目していない次のポートが着目エントリの中にあるか否かを判断する。そして、次のポートがあれば処理はステップＳ１８０８に移行する。逆に、着目エントリにおいてすべてのポートに着目済みであれば、処理はステップＳ１８０９に移行する。

　ステップＳ１８０８でテーブル制御部１０６は、着目エントリにおいてまだ着目していない次のポートに着目する。そして、処理はステップＳ１８０３に戻る。
　また、ステップＳ１８０９でテーブル制御部１０６は、まだ着目していない次のエントリがルーティングテーブル１２１にあるか否かを判断する。そして、次のエントリがあれば処理はステップＳ１８１０に移行する。逆に、ルーティングテーブル１２１のすべてのエントリに着目済みであれば、図３７の処理も終了する。

　また、ステップＳ１８１０でテーブル制御部１０６は、ルーティングテーブル１２１においてまだ着目していない次のエントリに着目する。そして、処理はステップＳ１８０２に戻る。

　以上説明した第１実施形態には、図１～５を参照して説明したような、輻輳を防ぎつつ、データの無駄な破棄をなくし、ネットワーク全体の負荷を平均化する効果がある。
　また、第１実施形態には、ルーティングに関する以下のような利点もある。すなわち、第１実施形態によれば、各通信装置１００は、ループ検出テーブル１２２を利用することで、何ら算術演算を行うことなしに、しかも自己完結的にループを検出し、ループが発生する経路に対応する送信先ポートを学習することができる。なおここで「自己完結的」というのは、他の通信装置との間でネットワークトポロジに関する情報をやりとりしていないことを指している。

　このように、各通信装置１００は自己完結的に振る舞っているにもかかわらず、バックトラックにより、有線アドホックネットワーク全体では、図１２のような、分散協調による深さ優先探索が実現される。そして、深さ優先探索の結果として新たな経路が発見され、その新たな経路に切り換わるまでの時間が、第１実施形態では、上記のように１秒よりも遥かに短い。

　このように障害発生時にも短い時間で経路が切り換わるため、第１実施形態による有線アドホックネットワークは、ミッションクリティカルなネットワークシステムにも好適に適用することができる。例えば、１秒間に数回～数十回程度の頻度でデータを出力するセンサを利用したセンサネットワークに第１実施形態を適用する場合、１秒よりも遥かに短い時間で経路の切り替えが完了するため、障害発生時のデータ消失の蓋然性は低い。

　また、第１実施形態の利点は他にもある。具体的には、第１実施形態によれば、ネットワーク管理者が有線アドホックネットワークのトポロジを事前に設計したり、通信装置１００にパラメタなどを設定したりする必要がない、という点である。

　設計や設定にかかる手間は、ネットワークに含まれる通信装置の数が増えるにつれて深刻化する。よって、例えばセンサネットワークなどの、ネットワーク内に多数の通信装置が含まれる応用分野では、「設計や設定をせずにすぐに使える」という特徴は、非常に好ましい特徴である。

　そして、第１実施形態によれば、新たな経路が選択されるまでのコンバージェンス（収束）に、１秒より遥かに短い時間（例えば数μｓ）しかかからない。換言すれば、第１実施形態では、実用上問題のない範囲に収束時間を抑えるために事前にネットワーク設計を行うという必要性が、ないのである。このように、第１実施形態によれば、煩雑な設計・設定作業を行わずとも、適切なパフォーマンスと冗長化が実現される。

　さらに第１実施形態には、ネットワーク資源を十分に利用することが可能であるという利点もある。すなわち、有線アドホックネットワーク内のリンクは、平常時用と障害発生時用で区別されて冗長化されているわけではないので、第１実施形態によれば、ネットワーク資源を休眠させることなく、十分に利用することが可能である。

　続いて、第２実施形態について説明する。第１実施形態では、通信装置１００装置間のリンクが有線リンクであるが、第２実施形態では、通信装置間のリンクは無線リンクである。すなわち、第２実施形態では、通信装置同士は、無線通信を行う。

　通信装置が無線通信を行う場合にも、第１実施形態と同様に、通信装置は、送信経路の制御とポーズ制御の双方をＧＤごとに行うことで、図１～５とともに説明したように、輻輳を回避しつつデータの中継も継続することが可能となる。

　以下、第２実施形態に関して、第１実施形態との相違を中心に説明する。無線通信を行う通信装置は、自ノードＩＤを含む「ハローフレーム」と呼ばれる制御フレームを送信する。すると、ハローフレームを受信した他の通信装置は、ハローフレームに含まれるノードＩＤを有する通信装置を、隣接する通信装置であると認識する。

　例えば、図１～５に示した動作は、第２実施形態でも同様であり、ネットワーク１は無線通信ネットワークでもよい。その場合、例えば、ノード３がハローフレームを送信し、ノード２がハローフレームを受信し、ノード２は「ノード２にはノード３が隣接している」と認識する。同様にして、例えばノード３は、ノード２と４からそれぞれハローフレームを受信することで、「ノード３にはノード２と４が隣接している」と認識する。

　あるノードに隣接するノードは、無線ネットワークでは動的に変化する。よって、第２実施形態の通信装置は、隣接ノードとして認識した他の通信装置のノードＩＤを含むエントリを不図示の隣接ノード管理テーブルに記録し、隣接ノード管理テーブルのエントリに対して、エージング処理を行う。

　また、第１実施形態では通信装置１００同士が有線リンクで接続されているのでポートと隣接ノードは１対１に対応する。しかし、第２実施形態では、そのような対応関係がない。そのため、第２実施形態では、図７のルーティングテーブル１２１の代わりに、例えば図３６のようなルーティングテーブル１２１ｂが使われる。図３６は、第２実施形態でのルーティングテーブルの例を示す図である。

　ルーティングテーブル１２１ｂは、「宛先」と「ポーズＧＤ」のフィールドを有する。また、無線ネットワークにおいては、隣接ノードの数が可変なので、ルーティングテーブル１２１ｂは、１つの「宛先」に対して任意の個数のエントリを有する。そして、各エントリは、以下の項目を有する。
　・エージング処理用の「最終更新時刻」
　・隣接ノードのノードＩＤである「ＬＤ」
　・「宛先」に示されるノードをＧＤとするフレームのルーティング先として、「ＬＤ」に示される隣接ノードはどの程度好ましいのかを示す「重み」
　・「ＬＤ」に示される隣接ノードからポーズ要求フレームを受信したか否かを示す「ポーズ要求受付フラグ」
　・「ＬＤ」に示される隣接ノードからポーズ要求フレームを受信した場合に、ポーズ要求フレームで指定されたカウンタの値に設定され、その後カウントダウンされる「カウンタ」

　例えば、ある通信装置が、「隣接ノードは、ノードＡ、Ｂ、Ｃの３つである」と認識しているとする。また、ルーティングテーブル１２１ｂには、例えば、「宛先」としてノードＸが記録されているとする。図３６の例では、この場合、次のような情報がルーティングテーブル１２１ｂに含まれる。

　ポーズＧＤ・ＰＧＤ_Ｘの値は、ルーティングテーブル１２１ｂを有する通信装置自身が、ノードＸをＧＤ４４２として指定するポーズ要求フレームを送信した場合、「選択中」である。また、通信装置が、ポーズ要求フレームの送信後に、ノードＸを明示的または暗黙的に指定するポーズ解除フレームを送信した場合、ポーズＧＤ・ＰＧＤ_Ｘの値は、「非選択」である。すなわち、ポーズＧＤ・ＰＧＤ_Ｘは、第１実施形態におけるルーティングテーブル１２１のポーズＧＤと同様である。

　ノードＸに対応する３つのエントリのうち、１つ目のエントリは隣接ノードＡに対応し、２つ目のエントリは隣接ノードＢに対応し、３つ目のエントリは隣接ノードＣに対応する。

　例えば、１つ目のエントリの最終更新時刻ＴＷ_Ｘ，Ａは、１つ目のエントリの最終更新時刻を示し、エージング処理に使われる。また、この１つ目のエントリのＬＤは、ノードＡのノードＩＤすなわち「Ａ」である。

　また、１つ目のエントリの重みＷ_Ｘ，Ａは、ノードＸをＧＤ４１１として含むデータフレームのＬＤとしてノードＡを指定することがどれほど好適であるかを示す。例えば、重みＷ_Ｘ，Ａは０以上１以下の値であり、初期値が０．５でもよい。そして、「重みＷ_Ｘ，Ａの値が小さいほど、ノードＸをＧＤ４１１として含むデータフレームのＬＤとしてノードＡを指定することが好ましい」としてもよい。

　そして、１つ目のエントリのポーズ要求受付フラグＰＲ_Ｘ，Ａは、ノードＡからポーズ要求フレームを受信したときに１、ノードＡからポーズ要求フレームを受信していないとき（およびノードＡからポーズ解除フレームを受信したとき）に０でもよい。

　また、１つ目のエントリのカウンタＣＴ_Ｘ，Ａは、ノードＡからポーズ要求フレームを受信したときに、ポーズ要求フレームに設定されているカウンタ４４３の値に設定され、その後カウントダウンされる。すなわち、カウンタＣＴ_Ｘ，Ａは、第１実施形態におけるルーティングテーブル１２１のカウンタと同様である。

　第１実施形態におけるルーティングテーブル１２１の「ポート状態」は、ルーティングテーブル１２１ｂにおける「重み」と「ポーズ要求受付フラグ」の組み合わせに対応する。

　・ポーズ要求受付フラグＰＲ_Ｘ，Ａが１の場合は、第１実施形態における「Ｐ」状態に対応する。したがって、第１実施形態で「ポート状態」を「Ｐ」状態に設定する処理は、第２実施形態では、「ポーズ要求受付フラグ」を１に設定する処理に置き換えられる。また、第１実施形態で「ポート状態」を「Ｐ」状態から「Ｅ」状態に戻す処理は、第２実施形態では、「ポーズ要求受付フラグ」を０に設定する処理に置き換えられる。

　・ポーズ要求受付フラグＰＲ_Ｘ，Ａが０で重みＷ_Ｘ，Ａが１の場合は、第１実施形態における「Ｌ」状態に対応する。したがって、第１実施形態で「ポート状態」を「Ｌ」状態に設定する処理は、第２実施形態では、「重み」を１に設定する処理に置き換えられる。

　・第２実施形態では、あるノードからのハローフレームが受信されなくなると、そのノードに対応するエントリはエージングによりルーティングテーブル１２１ｂから削除される。よって、第１実施形態における「Ｄ」状態に対応するのは「エントリが存在しない」という事実である。

　・ポーズ要求受付フラグＰＲ_Ｘ，Ａが０の場合は、重みＷ_Ｘ，Ａに応じて、第１実施形態における「Ｕ」状態または「Ｅ」状態に対応する。例えば、ポーズ要求受付フラグＰＲ_Ｘ，ＡとＰＲ_Ｘ，ＢとＰＲ_Ｘ，Ｃがすべて０で、重みＷ_Ｘ，ＡとＷ_Ｘ，ＢとＷ_Ｘ，Ｃはすべて１未満で、これらのうちで重みＷ_Ｘ，Ｂが最小だとすると、ノードＢが「Ｕ」状態に対応し、ノードＡとＣは「Ｅ」状態に対応する。

　なお、第２実施形態では、アドホックヘッダ４１０に、さらにＬＤとＬＳのフィールドが含まれる。通信装置は、ＬＳのフィールドに自ノードＩＤを設定し、ＬＤのフィールドに、送信先として選択した隣接ノードのノードＩＤを設定する。なお、ポーズ要求フレームやポーズ解除フレームに関しては、１ホップの範囲でのブロードキャストを示す特殊なブロードキャストアドレスがＬＤのフィールドに設定される。

　そして、無線通信アドホックフレームを受信した場合、第２実施形態の通信装置は、図１４のフレーム受信処理において、ステップＳ１０２とＳ１０３の間で、ＬＤのフィールドを確認し、自ノードＩＤまたは上記のブロードキャストアドレスが指定されていれば、ステップＳ１０３に処理を進める。逆に、ＬＤのフィールドに他のノードのノードＩＤが指定されていれば、第２実施形態の通信装置は、受信したフレームを破棄し、ステップＳ１０７の処理を行い、フレーム受信処理を終了する。

　また、第２実施形態の通信装置は、ステップＳ１１０の前に、受信したデータフレームに対するＡＣＫフレームを返信する。なお、ＡＣＫフレームのＬＳには自ノードＩＤが指定され、ＡＣＫフレームのＬＤにはデータフレームのＬＳの値がコピーされる。ＡＣＫフレームのＧＤ４１１はダミーの値でよく、ＧＳ４１２とＦＩＤ４１４にはそれぞれデータフレームのＧＳ４１２とＦＩＤ４１４の値がコピーされる。

　なお、第２実施形態の通信装置は、データフレームの送信後、ＡＣＫフレームを受信することができたら、ルーティングテーブル１２１ｂの「重み」の値を小さくし、ＡＣＫフレームを受信することができなかったら「重み」の値を大きくする。

　また、第１実施形態では隣接ノードと通信装置１００自身のポートが１対１に対応するので、例えば、図１５のステップＳ２０１では受信ポートが記憶される。しかし、第２実施形態では、受信フレームのＬＳの値が、ポートの代わりに記憶される。他のステップに関しても同様である。

　また、第２実施形態では、ループ検出テーブル１２２の代わりに、次のようなフィールドを含む不図示のループ検出テーブルが使われる。
　・ループ検出テーブル１２２と同様の「送信元」と「ＦＩＤ」
　・「ＯＬＳポート」の代わりの「ＯＬＳノードＩＤ」。具体的には、「ＯＬＳノードＩＤ」は、「送信元」と「ＦＩＤ」の組で識別されるフレームを最初に受信したとき、そのフレームのＬＳのフィールドに設定されていたノードＩＤである。あるいは、通信装置自身がＧＳとなってデータフレームを送信した場合は、「ＯＬＳノードＩＤ」は、自ノードＩＤである。

　・ｘ個のポートに対応する「ポート状態」の代わりの、１つの「ＬＤ」。この「ＬＤ」には、「送信元」と「ＦＩＤ」の組で識別されるフレーム送信したときに、隣接ノードのうちＬＤ（すなわち送信先）として選択したノードのノードＩＤが記録される。つまり、この「ＬＤ」は、第１実施形態のループ検出テーブル１２２において「ポート状態」が「Ｕ」状態のポートがどれか、という情報に対応する。

　第２実施形態では、以上のようなルーティングテーブルとループ検出テーブルとフレームの形式に関する変形に応じて、適宜処理の詳細が変形される。
　しかし、いずれの実施形態においても、ルーティングテーブルが、データ（具体的にはフレーム）の最終宛先を識別する最終宛先識別情報（例えばＧＤのノードＩＤ）に対応づけて、データを送信する送信経路を識別する送信経路識別情報（例えばポートＩＤまたはＬＤのノードＩＤ）を含む経路制御情報（例えばルーティングテーブルの各エントリ）を記憶する経路制御情報記憶部として使われることに変わりはない。

　そして、ビジー検出部１１３は、通信装置における資源の使用状況を監視し、使用状況を表す計量値を得る監視部の一例である。
　また、通信装置のポーズ制御部１１２が、最終宛先ごとの資源の使用状況にしたがって、通信装置がデータの転送を休止しようとする最終宛先である第１のポーズ対象通信装置を決定する点も、両実施形態で共通である。そして、ポーズ制御部１１２が、第１のポーズ対象通信装置を最終宛先とするデータの通信装置への送信を休止するよう要求する第１のポーズデータ（例えばポーズ要求フレーム）を生成し、第１のポーズデータを送信するよう送信部１１１を制御することも、両実施形態で共通である。

　そして、受信部１０３が、第２のポーズ対象通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータ（例えばポーズ要求フレーム）を受信したとき、どちらの実施形態の通信装置の受信フレーム制御部１０４も、次のように動作する経路制御情報更新部として機能する。すなわち、経路制御情報更新部としての受信フレーム制御部１０４は、第２のポーズ対象通信装置を最終宛先とするデータの送信経路から、第２のポーズデータを受信した経路を除外するように、第２のポーズ対象通信装置を識別する最終宛先識別情報（例えばＧＤのノードＩＤ）に対応づけられて経路制御情報記憶部（例えばルーティングテーブル）に記憶されている経路制御情報を更新する。

　具体的には、第２のポーズデータを受信した経路は、第１実施形態では、ポーズ要求フレームを受信したポートにより識別され、第２実施形態では、ポーズ要求フレームのＬＳフィールドの値により識別される。よって、経路制御情報更新部としての受信フレーム制御部１０４は、例えば、ポーズ要求フレームを受信したポートに対応する「ポート状態」を「Ｐ」状態を設定したり、ルーティングテーブル１２１ｂにおいて「ＬＤ」の値がポーズ要求フレームのフィールドの値と一致するエントリの「ポーズ要求受付フラグ」を１に設定したりする。

　また、どちらの実施形態のポート選択部１０８と送信フレーム制御部１１０も、次のような経路制御部として機能する。すなわち、経路制御部は、経路制御情報記憶部に記憶された経路制御情報にしたがって、送信の対象である送信対象データの送信経路を決定し、決定した送信経路に送信対象データを送信するよう送信部を制御する。

　また、バッファ使用中ＧＤテーブル１２６と１２６ａにおけるバッファカウンタは、最終宛先ごとの資源の使用状況を表す個別使用状況値の具体例である。
　そして、ポーズ履歴テーブル１２７は、ポーズ制御部１１２がどの通信装置を第１のポーズ対象通信装置として決定したかを表す履歴情報を記憶する履歴情報記憶部の具体例である。ポーズ制御部１１２は、受信部１０３が受信したデータの最終宛先が、過去に第１のポーズ対象通信装置として決定された通信装置であるか否かを、履歴情報を参照して判断する判断部としても機能する。そして、ポーズ制御部１１２は、下記２つの条件がともに成立するとき、受信されたデータの最終宛先を新たな第１のポーズ対象通信装置として決定することを避ける（例えば図３４のステップＳ１７０４とＳ１７０５を参照）。

　・判断部としてのポーズ制御部１１２が、「受信されたデータの最終宛先が、過去に第１のポーズ対象通信装置として決定された通信装置である」と判断した。
　・監視部としてのビジー検出部１１３が得る前記計量値が、ポーズ制御部１１２が第１のポーズ対象通信装置を決定して第１のポーズデータを生成および送信するための条件を満たす。

　ところで、上記のとおり、第１実施形態の通信装置と第２実施形態の通信装置は類似である。よって、実施形態によっては、無線通信機能と有線通信機能を兼ね備えた通信装置が使われてもよい。図３７はそのような通信装置のハードウェア構成図である。

　図３７の通信装置１００ａは、ＭＰＵ５０１、ｘ個のＰＨＹチップ５０２－１～５０２－ｘ、各ＰＨＹチップ５０２－ｉ（１≦ｉ≦ｘ）に接続されたポート５０３－ｉ、タイマＩＣ（Integrated Circuit）５０４、ＤＲＡＭ（Dynamic Random access Memory）５０５、フラッシュメモリ５０６および無線モジュール５０７を備える。

　ＭＰＵ５０１と各ＰＨＹチップ５０２－ｉの間を接続する通信インタフェイスは、ＭＩＩ／ＭＤＩＯ（Media Independent Interface or Management Data Input/Output）５０８である。また、ＭＰＵ５０１とタイマＩＣ５０４は、Ｉ^２Ｃ／ＰＩＯ（Inter-Integrated Circuit or Parallel Input/Output）バス５０９を介して接続されている。そして、ＤＲＡＭ５０５とフラッシュメモリ５０６と無線モジュール５０７は、ＰＣＩ（Peripheral Component Interconnect）バス５１０を介してＭＰＵ５０１に接続されている。

　例えば、受信部１０３と送信部１１１を実現するのに、ＰＨＹチップ５０２－１～５０２－ｘとポート５０３－１～５０３－ｘが使われてもよいし、無線モジュール５０７が使われてもよい。第１実施形態の通信装置１００は、図３７の通信装置１００ａから無線モジュール５０７を省略したハードウェア構成でもよい。また、第２実施形態の通信装置は、図３７の通信装置１００ａからＰＨＹチップ５０２－１～５０２－ｘとポート５０３－１～５０３－ｘを省略したハードウェア構成でもよい。

　テーブル格納部１０１とバッファ１０２とバッファ使用総量カウンタ１１４は、ＤＲＡＭ５０５により実現されてもよい。また、タイマ１０９はタイマＩＣ５０４により実現されてもよい。

　受信フレーム制御部１０４、上位層処理部１０５、テーブル制御部１０６、ポート監視部１０７、ポート選択部１０８、送信フレーム制御部１１０、ポーズ制御部１１２、ビジー検出部１１３は、ＭＰＵ５０１により実現されてもよい。

　なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
　上記実施形態では、各種データ例をテーブル形式で示したが、実施形態によっては、テーブル形式以外の形式で各種データを通信装置１００が保持していてもよい。

　また、図１３のアドホックフレーム４００の形式は一例である。アドホックヘッダ４１０におけるフィールドの順序や各フィールドの長さは実施形態に応じて任意である。また、タイプ４１３の具体的な値、通信装置１００がＦＩＤ４１４の値を生成する方法、ＴＴＬ４１５の初期値、ＦＣＳ４１７の算出アルゴリズムなども、実施形態に応じて任意に定めることができる。

　また、図１１において、例えばセンサ２０４は、通信装置１００ｅの外部に図示されている。しかし、実施形態によっては、センサを通信装置が内蔵してもよい。例えば、図３７の各ハードウェアに加えて、さらに通信装置が内蔵センサを有してもよい。

　また、図１１では、センサ２０４が汎用ＬＡＮポート１３５ｅを介して通信装置１００ｅに接続されているが、センサ２０４と通信装置１００ｅとの接続インタフェイスは、汎用ＬＡＮポート１３５ｅ以外の任意のインタフェイスでもよい。

　また、ルーティングテーブル１２１において「ポート状態」と「ポーズ状態」を別々に持っていてもよい。すなわち、「ポート状態」の値が「Ｅ」、「Ｕ」、「Ｄ」または「Ｌ」のみであってもよく、第２実施形態の「ポーズ要求受付フラグ」と同様のフラグをポートの個数（ｘ個）分、ルーティングテーブル１２１の各エントリが含んでいてもよい。

　また、ビジー検出部１１３は、複数の閾値を使って段階的に通信装置１００のビジー状況を検出してもよい。
　また、図１０のバッファ使用中ＧＤテーブル１２６と１２６ａは、いずれも、ポーズ対象のＧＤを決定するためにＧＤごとにバッファ１０２の使用量を記録するためのテーブルである。しかし、実施形態によっては、ＧＤと隣接ノード（つまりデータフレームのＬＳ）の組み合わせを単位として、バッファ１０２の使用量が記録されてもよい。そして、通信装置１００は、ポーズ要求フレームの送信先として、隣接ノードのうちの一部のノードのみを、ポーズ要求フレームの送信先として選択してもよい。

　例えば、図２のノード４は、ノード７をＧＤとするデータフレームのＬＳである、ノード群１２内の隣接ノードにのみ、ノード７を指定したポーズ要求フレームＰ１を送信してもよい。つまり、図２の例では、ノード４にとってノード３は、ノード７をＧＤとするデータフレームのＬＳではないので、ノード４は、ノード３へポーズ要求フレームＰ１を送信しなくてもよい。

　また、上記実施形態におけるバッファ使用中ＧＤテーブル１２６と１２６ａの各エントリのバッファカウンタは、ある時刻でのバッファ使用量を示す。しかし、実施形態によっては、ある一定期間の時間帯におけるバッファ使用量を統計的に積み上げた値がバッファ使用中ＧＤテーブル１２６ａの各エントリの「バッファカウンタｉ」（１≦ｉ≦Ｍ）に記録されてもよい。その場合、上記実施形態の処理は、以下のように３つの点から変形される。

　第１に、図２２のステップＳ６０４の減算が省略される。
　第２に、テーブル制御部１０６は、Ｍ個のバッファカウンタＢＣ_１ｉ～ＢＣ_Ｍｉのうちのいずれが最新の情報を示すのかを表すポインタを更新するとき、新たなポインタが指すバッファカウンタの列の値を０に初期化する。例えば、テーブル制御部１０６が、ポインタの示す値を２から３に変える場合、テーブル制御部１０６は、１≦ｉ≦Ｎなる各ｉについて、バッファカウンタＢＣ_３ｉの値を０に初期化する。よって、ポインタの更新周期ごとに異なる列でバッファ使用量が積算される。

　第３に、図３１～３４のいずれかのポーズ対象ＧＤ決定処理を行うとき、ポーズ制御部１１２は、テーブル制御部１０６のポインタに基づいて、以前の周期のバッファカウンタを使って処理を行う。

　例えば、Ｍ＝４でポインタの値が３のとき、現在の周期のバッファ１０２の使用状況は、「バッファカウンタ３」に積算中の値で表され、１つ前の周期のバッファ１０２の使用状況は、「バッファカウンタ２」の列に記録済みである。よって、この場合、ポーズ制御部１１２は、バッファ使用中ＧＤテーブル１２６の「バッファカウンタ」の列のデータの代わりに、バッファ使用中ＧＤテーブル１２６ａの「バッファカウンタ２」の列のデータを使って、図３１～３４の処理を行ってもよい。あるいは、Ｍ＝４でポインタの値が３のとき、ポーズ制御部１１２は、２つ前と３つ前の周期のバッファ１０２の使用状況を示す「バッファカウンタ１」と「バッファカウンタ４」の列のデータもさらに使って、ポーズ対象のＧＤを決定してもよい。

　また、ポーズ要求フレームで指定されるカウンタ４４３と、ポーズ解除フレームのどちらか一方があればよい。つまり、ポーズ解除フレームを使わない実施形態も可能である。なぜなら、ポーズ要求フレームを受信した通信装置は、カウンタ４４３により、ポーズ要求が解除されるタイミングを認識することができるからである。逆に、ポーズ要求フレームにはカウンタ４４３がなくてもよい。カウンタ４４３がなくても、ポーズ解除フレームがあれば、ポーズ解除フレームを受信した通信装置は、ポーズ要求が解除されるタイミングを認識することができるからである。

　ただし、カウンタ４４３とポーズ解除フレームの双方を使う実施形態は、好ましい。理由は次のとおりである。ビジー状態が持続する時間の最長の長さがどれくらいかという見込みを、通信装置１００はカウンタ４４３により隣接ノードに通知することができる。一方で、予想より早くビジー状態から回復できた場合、通信装置１００はポーズ解除フレームにより、回復を隣接ノードに通知することができる。

　また、図２５のステップＳ８０８でポーズ要求フレーム送信処理が行われる場合、ポーズ制御部１１２は、さらに、ルーティングテーブル１２１において現在「ポーズＧＤ」が「選択中」になっているすべてのＧＤをも、ポーズ対象として選択してもよい。

Claims

　通信装置であって、
　データを送信する送信部と、
　データを受信する受信部と、
　データの最終宛先を識別する最終宛先識別情報に対応づけて、前記データを送信する送信経路を識別する送信経路識別情報を含む経路制御情報を記憶する経路制御情報記憶部と、
　前記通信装置における資源の使用状況を監視し、前記使用状況を表す計量値を得る監視部と、
　前記計量値が所定の条件を満たすとき、
　　最終宛先ごとの前記資源の使用状況にしたがって、前記通信装置がデータの転送を休止しようとする最終宛先である第１のポーズ対象通信装置を決定し、
　　前記第１のポーズ対象通信装置を最終宛先とするデータの前記通信装置への送信を休止するよう要求する第１のポーズデータを生成し、
　　前記第１のポーズデータを送信するよう前記送信部を制御する
　ポーズ制御部と、
　前記受信部が、第２のポーズ対象通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータを受信したとき、前記第２のポーズ対象通信装置を最終宛先とするデータの送信経路から前記第２のポーズデータを受信した経路を除外するように、前記第２のポーズ対象通信装置を識別する最終宛先識別情報に対応づけられて前記経路制御情報記憶部に記憶されている前記経路制御情報を更新する経路制御情報更新部と、
　前記経路制御情報記憶部に記憶された前記経路制御情報にしたがって、送信の対象である送信対象データの送信経路を決定し、決定した前記送信経路に前記送信対象データを送信するよう前記送信部を制御する経路制御部と、
　を備えることを特徴とする通信装置。
　前記計量値が前記条件を満たすとき、前記ポーズ制御部は、
　　前記最終宛先ごとの前記資源の前記使用状況を表す個別使用状況値が、最終宛先として指定される複数の通信装置のうちで最小の通信装置を、前記第１のポーズ対象通信装置として決定する
　ことを特徴とする請求項１に記載の通信装置。
　前記計量値が前記条件を満たすとき、前記ポーズ制御部は、
　　最終宛先として指定される複数の通信装置のうちで、前記最終宛先ごとの前記資源の前記使用状況を表す個別使用状況値が、決められた範囲に含まれる通信装置を、前記第１のポーズ対象通信装置として決定する
　ことを特徴とする請求項１に記載の通信装置。
　前記決められた範囲が、所定の２つの固定値により規定される範囲であるか、または、
　前記条件は、前記計量値が所定の閾値を越えるときに満たされ、前記決められた範囲は、前記閾値を前記計量値から引いた差により下限が規定される範囲である
　ことを特徴とする請求項３に記載の通信装置。
　前記ポーズ制御部は、前記個別使用状況値が前記決められた範囲に含まれ、かつ最終宛先として指定される複数の通信装置のうちで相対的に前記個別使用状況値が大きい通信装置を、前記複数の通信装置の中から優先的に選んで、前記第１のポーズ対象通信装置として決定する
　ことを特徴とする請求項３または４に記載の通信装置。
　前記計量値が前記条件を満たすとき、前記ポーズ制御部は、
　　最終宛先として指定される複数の通信装置のうちで、前記最終宛先ごとの前記資源の前記使用状況を表す個別使用状況値が小さい通信装置から順に、
　　前記個別使用状況値を足した合計値が、決められた範囲に含まれるという制約のもとで、１つまたは複数の通信装置を選んで前記第１のポーズ対象通信装置として決定する
　ことを特徴とする請求項１に記載の通信装置。
　前記計量値が、一旦前記条件を満たした後で前記条件を満たさなくなったとき、前記ポーズ制御部は、
　　前記第１のポーズ対象通信装置を最終宛先とするデータの前記通信装置からの転送を再開することを通知する第１のポーズ解除データを生成し、
　　前記第１のポーズ解除データを送信するよう前記送信部を制御し、
　前記第２のポーズ対象通信装置を最終宛先とするデータの転送を再開することを通知する第２のポーズ解除データを、前記受信部が受信したとき、前記経路制御情報更新部は、
　　前記第２のポーズ対象通信装置を最終宛先とするデータの送信経路として前記第２のポーズ解除データを受信した経路が使用可能であることを示すように、前記第２のポーズ対象通信装置を識別する前記最終宛先識別情報に対応づけられて前記経路制御情報記憶部に記憶されている前記経路制御情報を更新する
　ことを特徴とする請求項１～６のいずれか１項に記載の通信装置。
　前記ポーズ制御部がどの通信装置を前記第１のポーズ対象通信装置として決定したかを表す履歴情報を記憶する履歴情報記憶部と、
　前記受信部が受信したデータの最終宛先が、過去に前記第１のポーズ対象通信装置として決定された通信装置であるか否かを、前記履歴情報を参照して判断する判断部をさらに備え、
　受信された前記データの前記最終宛先が、過去に前記第１のポーズ対象通信装置として決定された通信装置である、と前記判断部が判断し、かつ、前記計量値が前記条件を満たすとき、前記ポーズ制御部は、受信された前記データの前記最終宛先を新たな第１のポーズ対象通信装置として決定することを避ける
　ことを特徴とする請求項１～７のいずれか１項に記載の通信装置。
　通信装置が実行する通信制御方法であって、
　前記通信装置における資源の使用状況を監視し、
　前記使用状況を表す計量値を得、
　前記計量値が所定の条件を満たすとき、
　　最終宛先ごとの前記資源の使用状況にしたがって、前記通信装置がデータの転送を休止しようとする最終宛先である第１のポーズ対象通信装置を決定し、
　　前記第１のポーズ対象通信装置を最終宛先とするデータの前記通信装置への送信を休止するよう要求する第１のポーズデータを生成し、
　　前記第１のポーズデータを送信経路に送信し、
　第２のポーズ対象通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータを受信したとき、
　　データの最終宛先の通信装置を識別する最終宛先識別情報に対応づけられて前記通信装置内の経路制御情報記憶部に記憶されている、前記データを送信する送信経路を識別する送信経路識別情報を含む経路制御情報のうち、前記第２のポーズ対象通信装置を識別する最終宛先識別情報に対応づけられている経路制御情報を、前記第２のポーズ対象通信装置を最終宛先とするデータの送信経路から第２のポーズデータを受信した経路を除外するように更新し、
　送信の対象である送信対象データが存在するとき、
　　前記経路制御情報記憶部に記憶された前記経路制御情報にしたがって、前記送信対象データの送信経路を決定し、
　　決定した前記送信経路に前記送信対象データを送信する
　ことを特徴とする通信制御方法。
　通信装置に、
　前記通信装置における資源の使用状況を監視し、
　前記使用状況を表す計量値を得、
　前記計量値が所定の条件を満たすとき、
　　最終宛先ごとの前記資源の使用状況にしたがって、前記通信装置がデータの転送を休止しようとする最終宛先である第１のポーズ対象通信装置を決定し、
　　前記第１のポーズ対象通信装置を最終宛先とするデータの前記通信装置への送信を休止するよう要求する第１のポーズデータを生成し、
　　前記第１のポーズデータを複数の送信経路に送信し、
　第２のポーズ対象通信装置を最終宛先とするデータの送信を休止するよう要求する第２のポーズデータを受信したとき、
　　データの最終宛先の通信装置を識別する最終宛先識別情報に対応づけられて前記通信装置内の経路制御情報記憶部に記憶されている、前記データを送信する送信経路を識別する送信経路識別情報を含む経路制御情報のうち、前記第２のポーズ対象通信装置を識別する最終宛先識別情報に対応づけられている経路制御情報を、前記第２のポーズ対象通信装置を最終宛先とするデータの送信経路からは前記第２のポーズデータを受信した経路を除外するように更新し、
　送信の対象である送信対象データが存在するとき、
　　前記経路制御情報記憶部に記憶された前記経路制御情報にしたがって、前記送信対象データの送信経路を決定し、
　　決定した前記送信経路に前記送信対象データを送信する
　ことを含む処理を実行させるプログラム。