(57)【要約】【課題】ノード装置の死活状況に応じて、アドホックネットワーク上のデータフレームのルーティングを制御する技術を提供する。【解決手段】隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置は、いずれかのノード装置が異常状態か否かを示すノード死活情報を記憶する記憶部と、データフレームを受信し、記憶部に記憶されたノード死活情報に基づいて、データフレームから取得した送信先のノード装置の死活状態の判定を行い、判定の結果に応じて、データフレームから取得した送信先のノード装置及びデータフレームから取得した送信元のノード装置から、データフレームの宛先を決定する決定部と、決定した宛先が設定された前記データフレームを送信する送信部と、を含むことにより、上記課題の解決を図る。【選択図】図１５
2015097347.tif 000002
【特許請求の範囲】
【請求項１】
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置であって、
いずれかのノード装置が異常状態か否かを示すノード死活情報を記憶する記憶部と、
データフレームを受信し、前記記憶部に記憶された前記ノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定する決定部と、
決定した前記宛先が設定された前記データフレームを送信する送信部と、
を備えることを特徴とするノード装置。
【請求項２】
前記ノード装置は、さらに、
自ノード装置と隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を取得する取得部
を備えることを特徴とする請求項１に記載のノード装置。
【請求項３】
前記送信部は、さらに、自ノードと隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を、自ノードと隣接するノード装置に送信する
ことを特徴とする請求項１に記載のノード装置。
【請求項４】
前記決定部は、前記判定の結果に応じて、前記データフレームの宛先を、該データフレームから取得した送信元のノード装置に決定する場合、前記データフレームから取得した送信先への送信が失敗したことを示す送信失敗情報を該データフレームに付与する
ことを特徴とする請求項１〜３のうちいずれか１項に記載のノード装置。
【請求項５】
前記ノード装置は、さらに、
自ノード装置が生成して送信したデータフレームであって、前記送信失敗情報が付与された該データフレームを受信した場合、該データフレームの宛先を他のノード装置に変更する変更部
を備えることを特徴とする請求項４に記載のノード装置。
【請求項６】
前記ノード装置は、さらに、
異常状態から復旧したノード装置についての前記ノード死活情報を異常状態から正常状態へ変更させる要求を、隣接するノード装置へ送信する要求部
を備えることを特徴とする請求項１〜５のうちいずれか１項に記載のノード装置。
【請求項７】
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置に処理を実行させる制御プログラムであって、
データフレームを受信し、記憶部から読み出したいずれかのノード装置が異常状態か否かを示すノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、
該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定し、
決定した前記宛先が設定された前記データフレームを送信する、
処理を実行させる制御プログラム。
【請求項８】
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置の動作方法であって、
前記ノード装置は、
データフレームを受信し、記憶部から読み出したいずれかのノード装置が異常状態か否かを示すノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、
該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定し、
決定した前記宛先が設定された前記データフレームを送信する、
ことを実行するノード装置の動作方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置に関する。
【背景技術】
【０００２】
アドホック通信技術とは、アクセスポイントを介さずに機器同士が直接通信を行う通信技術をいう。近年、アドホック通信技術を適用した各通信機器が周囲の通信機器を認識して、無線アドホックネットワーク技術が注目されている。
【０００３】
アドホックネットワークのルーティングプロトコル（アドホックプロトコル）の一例として、リアクティブ型のＡＯＤＶ（Adhoc On Demand Distance Vector Algorithm）やプロアクティブ型のＯＬＳＲ（Optimized Link State Routing）が挙げられる。プロアクティブ型ルーティングプロトコルの一例としては、通信要求に先立って、予め各ノードが自律的にデータ通信を行うための経路（ルート）を構築し、更に、最適な経路を随時学習し、経路変更するプロトコルがある。
【０００４】
アドホックネットワークに関する技術の一例として、複数のネットワーク・ノードから成る複数ホップの無線通信ネットワークにおいて、ルーティングを行うシステムに関する第１の技術がある（例えば、特許文献１）。このシステムは、インフラ・ノード間のリンク状態を示す品質情報を取得する手段、予測手順を用いるインフラ・ノード内の経路決定プロセスにおいてリンク品質情報を用いる手段、決定された経路に従ってデータパケットを送るルーティング手段からなる。リンク品質情報は、リンク状態の時間的に変化する情報についての情報を含んでいる。予測手順は、予測手順の中でリンク状態の時間的に変化する情報を使用する。
【０００５】
また、ネットワークシステムでの通信障害経路回避技術の一例として、経路選択装置からの送出パケットを抑制する第２の技術がある（例えば、特許文献２。）。第２の技術では、特定ルート障害発生を検出した隣接経路選択装置からの宛先到達不能報告（ＩＣＭＰメッセージ）を受信した場合に、隣接経路選択装置が次の処理を行う。すなわち、隣接経路選択装置は、ルーティング宛先隣接経路選択装置を切り替えると共に、ネットワーク負荷に対応したリンク状態のデータベース更新を行い、現隣接経路選択装置でのトラヒック情報具合いに応じて送信するＩＰパケットを抑制する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２００７−５２９１３５号公報
【特許文献２】特開２００２−９８２０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
アドホックネットワークにおいて、データフレームの送信先のノード装置が故障した場合、その故障したノードに隣接するノード間でデータフレームがループし、そのようにループしたデータフレームは、それを検出したノードにより異常なフレームとして廃棄されてしまうおそれがある。
【０００８】
本発明は、一側面として、ノード装置の死活状況に応じて、アドホックネットワーク上のデータフレームのルーティングを制御する技術を提供する。
【課題を解決するための手段】
【０００９】
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置は、記憶部、決定部、送信部を含む。記憶部は、いずれかのノード装置が異常状態か否かを示すノード死活情報を記憶する。決定部は、データフレームを受信し、記憶部に記憶されたノード死活情報に基づいて、データフレームから取得した送信先のノード装置の死活状態の判定を行い、判定の結果に応じて、データフレームから取得した送信先のノード装置及びデータフレームから取得した送信元のノード装置から、データフレームの宛先を決定する。送信部は、決定した宛先が設定されたデータフレームを送信する。
【発明の効果】
【００１０】
本発明によれば、一側面として、ノード装置の死活状況に応じて、アドホックネットワーク上のデータフレームのルーティングを制御することができる。
【図面の簡単な説明】
【００１１】
【図１】メッシュ状のアドホックネットワーク構成の一例を示す。
【図２】図１に示すノード（Ｙ）が最終宛先であるゲートウェイ（ＧＷ）までの経路をＨＥＬＬＯメッセージの伝搬により構築する例を説明するための図である。
【図３】死活監視にて異常が検出された場合のアドホックネットワークの混乱状態を説明するための図である。
【図４】本実施形態におけるノード装置の一例を示す。
【図５】本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図（その１）である。
【図６】本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図（その２）である。
【図７】本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図（その３）である。
【図８】本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図（その４）である。
【図９】本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図（その５）である。
【図１０】本実施形態における死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームが伝達される前に、死活監視異常状態にあるノードへ送信されたデータフレームのルーティングを説明するための図（その１）である。
【図１１】本実施形態における死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームが伝達される前に、死活監視異常状態にあるノードへ送信されたデータフレームのルーティングを説明するための図（その２）である。
【図１２】本実施形態における死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームが伝達される前に、死活監視異常状態にあるノードへ送信されたデータフレームのルーティングを説明するための図（その３）である。
【図１３】本実施形態における、ノードＸについての死活監視異常情報をクリアにする要求をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図である。
【図１４】本実施形態におけるノードのハードウェア構成例である。
【図１５】本実施形態におけるフレーム送受信に関するノードの機能ブロック図の一例である。
【図１６】本実施形態（実施例１）における死活監視異常の通知の伝播手順を説明するための図（その１）である。
【図１７】本実施形態（実施例１）における死活監視異常の通知の伝播手順を説明するための図（その２）である。
【図１８】本実施形態（実施例１）における死活監視異常の通知の伝播手順を説明するための図（その３）である。
【図１９】本実施形態（実施例１）における死活監視異常の通知の伝播手順を説明するための図（その４）である。
【図２０】本実施形態（実施例２）における、正常にアドホックネットワークが構築されている状態で、ノードＦからノードＸへデータが送信された場合のデータの流れを説明するための図である。
【図２１】本実施形態（実施例２）における、ノードＡがノードＸの死活監視異常を検出し、その異常検出がノードＣとノードＦに通知されていない状態で、ノードＦからノードＸ宛のデータフレームが送信された場合のデータフレームの流れを説明するための図である。
【図２２】本実施形態（実施例３）における、アドホックネットワーク内の全ノードに、ノードＸの死活監視異常解除が通知されることを説明するための図（その１）である。
【図２３】本実施形態（実施例３）における、アドホックネットワーク内の全ノードに、ノードＸの死活監視異常解除が通知されることを説明するための図（その２）である。
【図２４】本実施形態（実施例３）における、アドホックネットワーク内の全ノードに、ノードＸの死活監視異常解除が通知されることを説明するための図（その３）である。
【図２５】本実施形態（実施例１〜３）におけるノードの全体処理のフローを示す。
【図２６】本実施形態におけるＨＥＬＬＯメッセージフレーム生成・送信処理（Ｓ８）の詳細フローを示す。
【図２７】本実施形態における死活監視処理（Ｓ１）の詳細フローを示す。
【図２８】本実施形態におけるルーティング処理（Ｓ６）の詳細フローを示す。
【図２９】本実施形態における経路構築処理（Ｓ７）の詳細フローを示す。
【発明を実施するための形態】
【００１２】
以下、本実施形態について、図面を参照して詳細に説明する。まず、本明細書での用語について説明をする。
【００１３】
「フレーム」とは、プロトコルが扱うデータ単位のことを指す。「フレーム」には、例えば、「ハローメッセージフレーム」、「データフレーム」が含まれるが、これらに限定はされない。
【００１４】
「ハローメッセージフレーム（ＨＥＬＬＯメッセージフレーム）」とは、制御情報を通信するための制御フレームの一種であり、ノード装置が、別のノード装置に対して互いの存在・状態の確認のために送出する特別なフレームのことを指す。なお、ＨＥＬＬＯメッセージフレームを単に、ＨＥＬＬＯメッセージと称する場合もある。
【００１５】
「データフレーム」とは、ネットワークが（スタートノードからゴールノードへと）伝送しようとするデータのことを指す。なお当然のことながらノード装置は、「ハローフレーム」と「データフレーム」を識別するための適切な手段を有することができる。
【００１６】
「Local Destination（ＬＤ）」とは、或るノード装置を主体として観たときに、次にフレームを渡すべき隣接ノード装置を表すあて先ノードＩＤのことを指す。なお本明細書ではLDのことを、「ローカル宛先アドレス」と称することもある。
【００１７】
「Local Source（ＬＳ）」とは、ＬＤへフレームを送るその直接の送り元となるノード装置を表したノードＩＤのことを指す。なお本明細書ではＬＳのことを、「ローカル差出アドレス」と称することもある。
【００１８】
「Global Destination（ＧＤ）」とは、データフレームのネットワークに跨った一連の伝播に関する最終的なあて先となるノードＩＤのことを指す。なお本明細書ではＧＤのことを、「グローバル宛先アドレス」と称することもある。
【００１９】
「Global Source（ＧＳ）」とは、データフレームのネットワークに跨った一連の伝播に関する最初の送り元であるノードＩＤのことを指す。なお本明細書ではＧＳのことを、「グローバル差出アドレス」と称することもある。
【００２０】
図１は、メッシュ状のアドホックネットワーク構成の一例を示す。レイヤ３（Ｌ３）ネットワーク２には、ネットワークサーバ１、Ｌ３ネットワークゲートウェイノード装置（ＧＷ）が接続されている。ＧＷは、ネットワーク間の接続を中継する装置であり、通信プロトコルの異なるデータを相互に変換し、データを中継する。図１では、例えば、ＧＷは、Ｌ３で用いられている通信プロトコルとアドホックプロトコルとを相互に変換して、通信を可能にする。
【００２１】
ノード装置（以下、ノードという）ａ〜ｅ，Ｙは、無線アドホック通信技術を搭載した通信端末である。各ノードでは、隣接するノードとの間で経路情報やノード間リンクの通信品質情報等のノード情報を含むメッセージ（ＨＥＬＬＯメッセージ）の送受信を定期的に行う。これにより、ノードは、ＨＥＬＬＯメッセージの情報に応じて各経路の通信品質を計算し、その計算結果に基づいて、最終宛先までの複数の経路の構築及び最適な経路の確定を行う。
【００２２】
また、各ノードは、構築した経路に関して、実際のデータ通信の実績と隣接ノードとの定期的なメッセージ（ＨＥＬＬＯメッセージ）をやり取りする。そして、ノードは、各経路の通信品質を再計算（更新）した結果に基づいて、経路の維持や最適経路の学習をし、随時変更を行っている。
【００２３】
図２は、図１に示すノード（Ｙ）が最終宛先であるゲートウェイ（ＧＷ）までの経路をＨＥＬＬＯメッセージの伝搬により構築する例を説明するための図である。
【００２４】
まず、ＧＷは、自分のＨＥＬＬＯメッセージの送信タイミングが到来した場合、自身が保持するノード情報（経路情報／ノード間リンクの通信品質情報）を含むＨＥＬＬＯメッセージをブロードキャスト送信する。隣接するノードａ，ｂ，ｃは、ＧＷからのＨＥＬＬＯメッセージを受信する（図２（Ａ））。
【００２５】
ノードａ，ｂ，ｃは、ＧＷからのＨＥＬＬＯメッセージを受信すると、それぞれ、経路情報テーブル（ルーティングテーブル）にＧＷを登録する。それと共に、ノードａ，ｂ，ｃは、ＧＷからのＨＥＬＬＯメッセージに含まれた、ＧＷが保持しているノード情報を使用して、経路品質やノード間リンクの通信品質を計算する。ノードａ，ｂ，ｃは、その計算結果を経路情報テーブル（ルーティングテーブル）やリンク情報テーブル（リンクテーブル）に登録する。尚、ノードａ，ｂ，ｃはＧＷから受信したＨＥＬＬＯメッセージの再ブロードキャスト（フラッディング）を行わない。
【００２６】
次に、例えばノードｂの場合、自分のＨＥＬＬＯメッセージの送信タイミングが到来した場合、自身が保持するノード情報を含むＨＥＬＬＯメッセージをブロードキャスト送信する（図２（Ｂ））。ノードｂのＨＥＬＬＯメッセージには、ＧＷや他のノード情報が含まれる。
【００２７】
ノードＹはノードｂからのＨＥＬＬＯメッセージを受信して、ノードｂを経路情報テーブルに登録する。それと共に、ノードＹは、ＧＷ宛の経路はノードｂ経由であること、その経路品質／リンク品質を計算し、その計算結果をルーティングテーブル／リンクテーブルに登録する。
【００２８】
ノードｄ，ｅについても、ノードｂ同様に、それぞれのＨＥＬＬＯメッセージの送信タイミングが到来したら、ＨＥＬＬＯメッセージをブロードキャスト送信する。ノードＹではＧＷ宛ての経路としてノードｂ，ｄ，ｅをそれぞれ次転送候補とする（Ｒ１）〜（Ｒ３）の複数の経路が構築され、各経路での経路品質／リンク品質情報により、最終宛先（ＧＷ）までの最適経路が確定される（図２（Ｃ））。
【００２９】
このように、各ノードがＨＥＬＬＯメッセージを交換することによりノード間で経路情報・品質情報が伝搬され、各ノードでは最終宛先までの経路が複数構築される。
【００３０】
上述のように、アドホックネットワークにおいては、通常、経路が複数ある。そのため、仮に、ある経路が途中に存在するノードの異常等により最終宛先までの経路が不通になった場合でも別の経路に切り替えて送信することで、最終宛先までデータを届けることが可能である。
【００３１】
例えば、図２（Ｃ）にて、最適な経路としてルート（Ｒ１）（Ｙ→ｂ→ＧＷ）があったときに、ノードｂで異常が発生し、ノードｂが転送不可となった場合であっても、ノードＹは、次の処理を行う。すなわち、ノードＹは、ルート（Ｒ２）（Ｙ→ｄ→ａ→ＧＷ）またはルート（Ｒ３）（Ｙ→ｅ→ｃ→ＧＷ）の経路に切り替えてデータを送信する。これにより、最終宛先であるＧＷまでデータを届けることが出来る。
【００３２】
更に、ノード間では、定期的にＨＥＬＬＯメッセージを交換し、各ノードが持つ経路情報やノード間のリンク品質情報を交換し、伝搬させる。これにより、各ノードは、ノード間リンクの通信品質再計算（更新）を行い、通信経路の維持や最適経路の学習をし、随時経路情報の変更を行う。また、ノードは、ＨＥＬＬＯメッセージ交換により、相手方のノードが正常に動作している（正常状態）か、または動作していない（異常状態）かを判定する死活監視処理を行う。以下では、ＨＥＬＬＯメッセージ交換による死活監視の結果、異常と判定されたノードの状態を「死活監視異常」または「死活監視異常状態」という。
【００３３】
ところが、上記方式では、ＨＥＬＬＯメッセージ交換による死活監視の結果、異常を検出した場合に、その情報がアドホックネットワーク全体に伝搬する前では、死活監視による異常を検出しているノードと検出していないノードが混在する。この場合には、正常な通信ルートが構築されずに、転送されたフレームが転送途中で異常フレームと判断され廃棄される等により通信失敗となる可能性が高い。
【００３４】
特にネットワークサーバ１へＧＷを経由してデータ転送するイベント（例えば定期通信など）直前に、そのＧＷが死活監視異常状態となった場合には、次のことが生じる可能性がある、すなわち、アドホックネットワーク内をデータフレームが右往左往することにより、トラフィックを高め、またサーバまで到達できないこともある。そのため、顕著にシステム全体に悪影響を及ぼすこととなる。これについて、図３を用いて説明する。
【００３５】
図３は、死活監視にて異常が検出された場合のアドホックネットワークの混乱状態を説明するための図である。図３（Ａ）は、ノードＡ〜Ｆ，Ｘに関するアドホックネットワークの経路例を示す。なお、図３（Ｂ）（Ｃ）中のルーティングテーブルにおいて、「ＧＤ」は、グローバル宛先アドレス、ＬＤはローカル宛先アドレスを示す。ＬＤには、ＧＤ単位で、ローカル宛先ノードまでの複数経路のうち、受信強度（または通信品質）が良い順に所定の数（この例では、３つ）の経路（第１候補（ＬＤ１）、第２候補（ＬＤ２）第３候補（ＬＤ３））が記憶されている。
【００３６】
図３（Ｂ）では、各ノードからノードＸ宛への経路のうち、第１候補（ＬＤ１）宛ての経路を矢印で示す。図３（Ｂ）の状態において、ノードＡとノードＢがそれぞれ、死活監視によりノードＸの異常、すなわち通信不可を検出した場合、図３（Ｃ）のように自動的に経路が変更される。すなわち、ノードＸからのＨＥＬＬＯメッセージが受信されない結果、ノードＡのルーティングテーブルにて、その時点での最もよい通信品質を有するＨＥＬＬＯメッセージを送信したノードＢが、第１候補（ＬＤ１）となる。また、ノードＢのルーティングテーブルにて、その時点での最もよい通信品質を有するＨＥＬＬＯメッセージを送信したノードＡが、第１候補（ＬＤ１）となる。
【００３７】
このように、ノードＡとノードＢはノードＸの死活監視異常を検出した為、それまでの第一候補であったＬＤ１＝ノードＸをそれぞれ、ＬＤ１＝ノードＢ、ＬＤ１＝ノードＡに変更する。これによりことで、ノードＡとノードＢは、相互に相手方を最適経路と勘違いした状態となる。さらにノードＣ，Ｄ，Ｅ，Ｆは、ノードＸの死活監視異常を検出していない為、それまで通り最適経路としてノードＡ，Ｂが設定されたままである。
【００３８】
この状態でノードＸ宛の通信を行おうとした場合、ノードＡ−Ｂ間でループが発生してしまい、フレームをロスしてしまう可能性がある。
【００３９】
このように、死活監視異常を検出したノードと、それを検出していないノードが混在しているアドホックネットワークにおいて、その死活監視異常となったノード宛にデータ転送を行った場合、ネットワーク内をフレームがループしてしまう。そこで、そのようなループしているフレーム（ループフレーム）を検知した転送ノードがそのフレームを異常フレームとして廃棄することを防止することが求められる。
【００４０】
また、フレームを廃棄することで、送信元ノードは、宛先まで届いていないにも関わらず送信完了したと見なす。そこで、そのような場合には、送信元ノードにて、最終宛先への送信失敗時に行う送信元ノードでの宛先切り替えが求められる。
【００４１】
また、ループフレームを転送する度に転送ノードは経路品質を見直すことで、それまでの最適な経路を壊してしまう。そこで、ループフレームを転送する度に最適な経路を壊さないようにすることが求められる。
【００４２】
図４は、本実施形態におけるノード装置の一例を示す。ノード装置１１は、隣接するノード装置間で無線通信することにより無線通信ネットワークを構築する。ノード装置は、記憶部１２、決定部１３、送信部１４を含む。
【００４３】
記憶部１２は、いずれかのノード装置が異常状態か否かを示すノード死活情報を記憶する。記憶部１２の一例として、ルーティングテーブル３９が挙げられる。
【００４４】
決定部１３は、データフレームを受信し、記憶部１２に記録されたノード死活情報に基づいて、データフレームから取得した送信先のノード装置の死活状態の判定を行う。決定部１３は、判定の結果に応じて、データフレームから取得した送信先のノード装置及びデータフレームから取得した送信元のノード装置から、データフレームの宛先を決定する。決定部１３の一例として、ルーティング部３４が挙げられる。
【００４５】
送信部１４は、決定した宛先が設定されたデータフレームを送信する。送信部１４の一例として、フレーム送信処理３２が挙げられる。
【００４６】
このように構成することにより、ノード装置の死活状況に応じて、アドホックネットワーク上のデータフレームのルーティングを制御することができる
ノード装置１１は、さらに、取得部１５を含む。取得部１５は、自ノード装置と隣接するノード装置についてのノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を取得する。取得部１５の一例として、死活監視部３５が挙げられる。
【００４７】
このように構成することにより、各ノードは、アドホックネットワーク上の他のノードの死活情報を取得することができる。
【００４８】
送信部１４は、さらに、自ノードと隣接するノード装置についてのノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を、自ノードと隣接するノード装置に送信する。
【００４９】
このように構成することにより、異常が生じたノードについての死活情報を、アドホックネットワーク全体に伝播させることができる。
【００５０】
決定部１３は、判定の結果に応じて、データフレームの宛先を、データフレームから取得した送信元のノード装置に決定する場合、データフレームから取得した送信先への送信が失敗したことを示す送信失敗情報をデータフレームに付与する。
【００５１】
このように構成することにより、データフレームの送信が失敗したことを送信元へ通知することができる。
【００５２】
ノード装置は、さらに、変更部１６を含む。変更部１６は、自ノード装置が生成して送信したデータフレームであって、送信失敗情報が付与されたデータフレームを受信した場合、データフレームの宛先を他のノード装置に変更する。変更部１６の一例として、ルーティング部３４が挙げられる。
【００５３】
このように構成することにより、送信先への送信が失敗に終わった場合には、予め登録した他のノードに送信することができる。
【００５４】
ノード装置は、さらに、要求部１７を含む。要求部１７は、異常状態から復旧したノード装置についてのノード死活情報を異常状態から正常状態へ変更させる要求を、隣接するノード装置へ送信する。要求部１７の一例として、死活監視部３５が挙げられる。
【００５５】
図５〜図１３は、本実施形態におけるアドホックネットワークの動作を説明するための図である。図５〜図９は、本実施形態におけるノードＸについての死活監視異常情報をアドホックネットワーク上の全ノードに伝播させる動作を説明するための図である。例えば、正常時のアドホックネットワークの構成の一例として、図５に示すネットワークがあるとする。
【００５６】
この時点では、ノードＸは、正常に動作している。以下では、ノードＸ，Ａ，Ｂ，Ｃ，・・・等のアドレスをそれぞれ、ノードＩＤ＝Ｘ，Ａ，Ｂ，Ｃ，・・・等で示す。また、各ノードは、最終的な宛先ノード（ＧＤ）単位で管理される隣接ノードに対するルーティング情報を保持するルーティングテーブルを有する。
【００５７】
ノードＡが有するＧＤ＝Ｘについてのルーティングテーブルについて、ＬＤには、第１候補としてＸ、第２候補してＢ、第３候補してＣが格納されている。
【００５８】
ノードＢが有するＧＤ＝Ｘについてのルーティングテーブルについて、ＬＤには、第１候補としてＸ、第２候補してＡ、第３候補してＥが格納されている。
【００５９】
また、ルーティングテーブルにおいて、「ＧＤ：正常」は、死活監視異常フラグ＝ＯＦＦ、すなわちＧＤとして登録されているノードが正常に動作していることを示す。
【００６０】
次に、ノードＸに異常が発生したとする。この場合、図６に示すように、ノードＡ，Ｂは、ノードＸからのＨＥＬＬＯメッセージが不達のため、ノードＸの死活監視異常を検出する。ノードＡおよびノードＢはそれぞれ、最終宛先（ＧＤ）であるノードＸの死活監視異常を検出すると、ＬＤの第１〜３候補の経路を見直し、ルーティングテーブルのノードＸ宛て経路情報にある死活監視異常フラグをＯＮ（＝異常）する。経路の見直しの結果、ノードＡが有するＸ宛（ＧＤ）のルーティングテーブルの第１候補（ＬＤ１）は「Ｂ」になり、ノードＢが有するＸ宛（ＧＤ）のルーティングテーブルの第１候補（ＬＤ１）は「Ａ」になるとする。
【００６１】
すると、図７に示すように、ノードＡおよびノードＢは、自身が送信するＨＥＬＬＯメッセージフレームにおいて、ノードＸが異常であることを示すビットをＯＮ（死活監視異常フラグ＝ＯＮ）にセットしてブロードキャスト送信する。図７において、実線の矢印は、ノードＡによるＨＥＬＬＯメッセージの送信を示す。また、破線の矢印は、ノードＢによるＨＥＬＬＯメッセージの送信を示す。
【００６２】
次に、図８に示すように、ノードＣ，Ｄ,Ｅは、ノードＸについて死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームを受信すると、ルーティングテーブルのノードＸ宛て経路情報にある「死活監視異常フラグ」をＯＮ（＝異常）する。
【００６３】
次に、図９に示すように、図７で説明したノードＡ，Ｂと同様に、ノードＣ，Ｄ，Ｅは、ＨＥＬＬＯメッセージフレームに、ノードＸが異常であることを示すビット（ノードＸについて死活監視異常フラグ）をＯＮにセットしてブロードキャスト送信する。
【００６４】
ノードＦは、ノードＸについて死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームを受信すると、ルーティングテーブルのノードＸ宛て経路情報にある「死活監視異常フラグ」をＯＮ（＝異常）する。これにより、死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームをノードＦまで伝達する事で、アドホックネットワークの全ノードにノードＸが死活監視異常状態であることが伝わる。
【００６５】
例えば、図９の状態で、ノードＸに対してノードＦの定期通信タイミングが到来した場合、ノードＸについて死活監視異常フラグがＯＮであるため、ノードＦは、データ送信を行わない。このようにデータ送信を抑止する事でアドホックネットワーク内に無駄なフレームの転送や迂回を行う事がなくなり、トラフィックを低減することが可能となる。
【００６６】
ところが、死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームが伝達される前に死活監視異常のノードへデータフレームが送信される場合がある。これについて図１０−図１２を用いて説明する。
【００６７】
図１０−図１２は、本実施形態における死活監視異常フラグがＯＮであるＨＥＬＬＯメッセージフレームが伝達される前に、死活監視異常状態にあるノードへ送信されたデータフレームのルーティングを説明するための図である。例えば、ノードＡ、ＢがＨＥＬＬＯメッセージフレームを送信する前（図８）、図１０のようなアドホックネットワーク構成になる。すなわち、ノードＡ、Ｂ間のアドホックネットワークでは、ノードＡ、Ｂのルーティングテーブルの死活監視異常フラグがＯＮになっている。また、ノードＣ、Ｄ、Ｅ、Ｆ間のアドホックネットワークでは、ノードＣ、Ｄ、Ｅ、Ｆのルーティングテーブルの死活監視異常フラグがＯＦＦになっている。
【００６８】
図１１に示すように、ノードＦにおいて、ノードＸへの定期通信タイミングが到来した場合、死活監視異常フラグ：ＯＦＦのアドホックネットワーク内では、ノードＦ、ノードＤ、ノードＡという順番にデータフレームの転送が行われる。その際のデータフレーム内にあるノードＸへの送信失敗フラグにはＯＦＦが設定されている。
【００６９】
ここで、データフレームについて説明する。データフレームはヘッダ部分とデータ部分を含む。データフレームのヘッダは、「ＬＤ」、「ＬＳ」、「ＧＤ」、「ＧＳ」、「送信失敗フラグ」を含む。「ＬＤ」には、ローカル宛先アドレスが設定される。「ＬＳ」には、ローカル送信元アドレスが設定される。「ＧＤ」には、グローバル宛先アドレスが設定される。「ＧＳ」には、グローバル送信元アドレスが設定される。「送信失敗フラグ」には、ＧＤへの送信に失敗したか否かを示すフラグが設定される。送信失敗フラグのデフォルト値はＯＦＦであり、送信に失敗した場合には送信失敗フラグ＝ＯＮになる。
【００７０】
ノードＦからノードＤへ送信されるフレーム（１）のヘッダには、「ＬＤ：Ｄ、ＬＳ：Ｆ、ＧＤ：Ｘ、ＧＳ：Ｆ、送信失敗フラグ：ＯＦＦ」が設定されている。ノードＤからノードＡへ送信されるフレーム（２）のヘッダには、「ＬＤ：Ａ、ＬＳ：Ｄ、ＧＤ：Ｘ、ＧＳ：Ｆ、送信失敗フラグ：ＯＦＦ」が設定されている。
【００７１】
ノードＡが有するＧＤ：Ｘに関するルーティングテーブルにおいて、死活監視異常フラグ：ＯＮである。この場合、ノードＡは、ノードＸ宛ての転送フレーム（２）を受信した場合、次の処理が行われる。すなわち、図１２に示すように、ノードＡは、そのフレームヘッダ（２）の送信失敗フラグがＯＦＦであるため、送信失敗フラグをＯＮに設定し、そのフレームのＬＤ、ＬＳを書き換えて、送信元であるノードＤに、フレーム（３）を返送する。
【００７２】
ノードＤは、受信したフレームの送信失敗フラグがＯＮであるため、ノードＸへはフレームの到達はできないと判断し、そのフレームのＬＤ、ＬＳを書き換えて、送信元であるノードＦに対して、フレーム（４）を返送する。ノードＸ宛てフレーム（１）が送信失敗フラグがＯＮとなって戻ってきたために、ノードＦは、定期送信が失敗したと判断する。
【００７３】
次に、ノードＸが復旧した場合について、図１３を用いて説明する。ノードＸの復旧後でも、ノードＸの周辺のノードがノードＸを死活監視異常であると判定している可能性がある。そのため、ノードＸは、再起動時には死活監視異常ＯＦＦ要求のフレームをアドホックネットワーク内に対して、ブロードキャスト送信する。死活監視異常ＯＦＦ要求は、その要求を受信したノードのルーティングテーブルにて、死活監視異常フラグがＯＮになっている場合には、ＯＦＦに更新することを要求するコマンドである。各ノードは、死活監視異常ＯＦＦ要求を受信すると、ルーティングテーブルにおいて、ノードＸ宛ての死活監視異常フラグをＯＦＦに変更するとともに転送を行う。各ノードは、これらを繰り返すことでアドホックネットワーク内に即座にノードＸが復旧した事を通知することができる。
【００７４】
本実施形態によれば、定期的にＧＷ経由で情報をサーバに伝達することが目的のマルチホップを行う無線アドホックネットワーク環境において、次のことが実現できる。すなわち、サーバとアドホックネットワークを構築するノードが死活監視異常状態となり、その異常を検出したノードと検出していないノードが混在する状況でもネットワークの擾乱を引き起こすフレームの送信を抑止することができる。また、ネットワークの擾乱を引き起こすフレームを送信した場合にも無駄なトラフィックとなるような転送・迂回をさせることなく送信元まで戻すことが可能である。
【００７５】
以下に本実施形態の実施例を説明する。
図１４は、本実施形態におけるノードのハードウェア構成例である。ノード２１は、ＣＰＵ（Central Processing Unit）２２、ＲＡＭ（Random Access Memory）２３、不揮発性メモリ２４、無線通信インターフェース２５を含む。ＣＰＵ２２は、ＲＡＭ２３、不揮発性メモリ２４、無線通信インターフェース２５と所定のバスにより接続されている。
【００７６】
ＣＰＵ２２は、各種計算処理を担う。ＣＰＵ２２は、不揮発性メモリ２４等に格納した後述する処理を実現するプログラムを読み出し、当該プログラムを実行する。不揮発性メモリは、例えばＲＯＭ（Read Only Memory）、または読み書き可能なＳＳＤ（Solid State Drive）等の半導体メモリである。ＲＡＭ２３は、データを一時的に保持する揮発性メモリである。
【００７７】
無線通信インターフェース２５は、無線ＬＡＮ（Local Area Network）接続のための処理を行うハードウェアである。無線通信インターフェース２５は、例えばアンテナ、ＡＤＣ（Analog-to-Digital Converter）、ＤＡＣ（Digital-to-Analog Converter）、変調器、復調器などを含む。
【００７８】
また、ノードは、これらの電子部品に電力を供給して動作させるための電源としての充電池も搭載している。また図示されていないが、ノード２１は計時のためのクロックまたはタイマを含む。
【００７９】
後述する実施形態で説明する処理を実現するプログラムは、プログラム提供者側から通信ネットワークを介して、例えば不揮発性メモリ２４等の記憶装置に格納してもよい。また、後述する実施形態で説明する処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置に設定されて、ＣＰＵ２２によってそのプログラムが読み出されて、実行されてもよい。
【００８０】
図１５は、本実施形態におけるフレーム送受信に関するノードの機能ブロック図の一例である。図１５において、ノード２１は、ＣＰＵ２２、無線通信インターフェース（無線通信Ｉ／Ｆ）２５、ＲＡＭ２３を含む。ＲＡＭ２３には、経路情報テーブル（ルーティングテーブルとも呼ばれる）３９、リンク情報テーブル（リンクテーブルとも呼ばれる）等が格納されている。
【００８１】
無線通信インターフェース（Ｉ／Ｆ）２５は、受信部３７および送信部３８を含み、他のノードとの通信を行うための処理を行う。受信部３７は、ノード２１に送信されてきたフレームの信号を受信し、受信した信号をフレーム受信処理部３３に出力する。
【００８２】
ＣＰＵ２２は、不揮発性メモリ２４等に格納したプログラムを読み出し、ＨＥＬＬＯ制御部３１、フレーム送信処理部３２、フレーム受信処理部３３、ルーティング部３４、死活監視部３５、アプリケーション処理部３６として機能する。
【００８３】
フレーム受信処理部３３は、受信部３７から入力されたフレームを、ルーティング部３４及び死活監視部３５で処理させるように、振り分ける。フレーム受信処理部３３で振り分けられるフレームには、経路情報フレーム、経路情報フレーム以外の制御フレーム、ユーザデータを格納したデータフレームなどが含まれる。フレーム受信処理部３３は、振り分けたフレームをルーティング部３４及び死活監視部３５に出力する。
【００８４】
アプリケーション処理部３６は、ノード２１宛のフレームがルーティング部３４から入力されると、入力されたフレームをアプリケーションプログラムにより処理する。また、アプリケーション処理部３６は、アプリケーションプログラムの処理によって他のノード２１に送信するデータフレームを生成することもできる。アプリケーション処理部３６は、生成したデータフレームをルーティング部３４に出力する。
【００８５】
ルーティング部３４は、入力されたフレームを、自ノード宛てのものか、ブロードキャスト送信のものかの判断を行い、自ノード宛てのものである場合には、アプリケーション処理部３６に通知する。ルーティング部３４は、入力されたフレームに含まれているアドホックヘッダに基づいて、ルーティングテーブル３９に受信したＨＥＬＬＯメッセージの送信元をルーティングテーブル３９に登録する。また、受信したＨＥＬＬＯメッセージに含まれているノード情報を使用して経路品質やノード間リンクの通信品質を計算し、結果をルーティングテーブル３９やリンクテーブルに登録する。ルーティング部３４は、ルーティングテーブル３９やリンクテーブルに登録された情報を含むフレームを送信するようにフレーム送信処理部３２を制御する。
【００８６】
また、ルーティング部３４は、データフレームが入力された場合、ルーティングテーブル３９に記録された死活監視異常フラグに基づいて、データフレームから取得した送信先のノードが死活監視異常であるか否かを判定する。ルーティング部３４は、判定の結果に応じて、データフレームから取得した送信先のノード装置及びデータフレームから取得した送信元のノード装置から、データフレームの宛先を決定する。
【００８７】
また、ルーティング部３４は、判定の結果に応じて、データフレームの宛先を、データフレームから取得した送信元のノードに決定する場合、送信失敗フラグ＝ＯＮをデータフレームに設定する。
【００８８】
また、ルーティング部３４は、自ノードが生成して送信したデータフレームであって送信失敗フラグにＯＮが設定されたデータフレームを受信した場合、データフレームの宛先を予め登録してある他のノード装置に変更する。
【００８９】
また、ルーティング部３４は、アプリケーション処理部により生成されたデータフレームの宛先のノードについてのルーティングテーブル３９の死活監視異常フラグがＯＮ（異常）の場合には、そのノードへデータフレームを送信しない。この場合には、ルーティング部３４は、宛先を予め登録してある他のノード装置に変更して送信する。
【００９０】
ＨＥＬＬＯ制御部３１は、ルーティングテーブル３９に登録された情報を用いて、ＨＥＬＬＯメッセージフレームを生成し、フレーム送信処理部３２に出力する。ＨＥＬＬＯ制御部３１は、ルーティングテーブル３９に含まれている経路に関する情報を含むハローフレームを生成することができる。
【００９１】
フレーム送信処理部３２は、送信部３８を制御して、フレームの送信を行う。
死活監視部３５は、ルーティングテーブル３９に登録された隣接するノードからのＨＥＬＬＯメッセージフレームを所定時間受信していない場合には、その隣接するノードが異常のため通信できないと判断する。それから、死活監視部３５は、その異常が生じたノード宛のルーティングテーブル３９に格納されている死活監視異常フラグをＯＮに設定する。また、自ノードと隣接していないノードについての死活監視異常フラグがＯＮに設定されたＨＥＬＬＯフレームを、隣接するノードより受信した場合、死活監視部３５は、次の処理を行う。すなわち、死活監視部３５は、そのＨＥＬＬＯフレームにおいて死活監視異常フラグがＯＮに設定されているノード宛のルーティングテーブル３９に格納されている死活監視異常フラグをＯＮに設定する。また、死活監視部３５は、フレーム送信処理部３２を介して、死活監視異常ＯＦＦ要求を送信する。
【００９２】
このようなノードを用いて、以下の実施例を説明する。
（実施例１）
実施例１では、いずれかのノードの死活監視異常を検出した場合にアドホックネットワーク内の全ノードに対して、そのノードが死活監視異常状態であることを伝播させることについて説明する。
【００９３】
図１６〜図１９は、本実施形態（実施例１）における死活監視異常の通知の伝播手順を説明するための図である。図１６には、正常にアドホックネットワークが構築されている場合の各ノードのルーティングテーブル及びＨＥＬＬＯメッセージフレームを示す。各ノードは、死活監視異常フラグにＯＦＦが設定されたＨＥＬＬＯメッセージフレームを、隣接するノードにブロードキャスト送信している。ここでの「ブロードキャスト」は「隣接するすべてのノード装置へのブロードキャスト」であり、「ネットワーク全体へのフラッディング」ではないので注意されたい。
【００９４】
その後、図１７に示すように、ノードＸに異常が発生し、ノードＸが通信できなくなったとする。
【００９５】
図１７は、ノードＡ及びノードＢがノードＸが死活監視異常状態であることを検知した際の動作を説明するための図である。ノードＡ及びノードＢは、ノードＸからのＨＥＬＬＯメッセージフレームを一定期間未受信状態であったため、ノードＸが死活監視異常と判定する。
【００９６】
ノードＡ及びノードＢは、隣接ノードより受信したＨＥＬＬＯメッセージフレームを用いて、死活監視異常を検出したノードＸ宛のルーティングテーブルの経路ＬＤ１〜ＬＤ３を見直す。それと同時に、ノードＡ及びノードＢは、ノードＸ宛のルーティングテーブルの死活監視異常フラグをＯＮ（異常）に設定する。
【００９７】
次に、図１８に示すように、ノードＸが死活監視異常であることを検知したノードが周囲のノードへノードＸの死活監視異常を通知する。ノードＸの死活監視異常を検出したノードＡ、ノードＢは、次から送信するＨＥＬＬＯメッセージフレーム(1-i),(1-ii)の死活監視異常フラグにＯＮ（異常）を設定して送信する。
【００９８】
すると、ノードＣ、ノードＤ、ノードＥは、ノードＡ、ノードＢから送信されたＨＥＬＬＯメッセージフレーム(1-i),(1-ii)を受信すると、そのフレームヘッダからノードＸが死活監視異常状態であることを検知する。すると、図１９に示すように、ノードＣ、ノードＤ、ノードＥはそれぞれ、ノードＸ宛のルーティングテーブルの死活監視異常フラグをＯＮ（異常）とする。
【００９９】
図１９に示すように、ノードＣ，Ｄ，Ｅについても、ノードＡ、ノードＢと同様に、ノードＸが死活検出異常状態であることを通知する。具体的には、ノードＸの死活監視異常を検出したノードＣ、Ｄ、Ｅは、ノードＡ，Ｂ同様に、次から送信するＨＥＬＬＯメッセージフレーム(1-iii),(1-iv),(1-v)の死活監視異常フラグにＯＮ（異常）を設定して送信する。
【０１００】
ノードＦがノードＣ，Ｄ，Ｅから送信されたＨＥＬＬＯメッセージフレーム(1-iii)，(1-iv)，(1-v)を受信する。すると、ノードＦはノードＸが死活監視異常状態であることを検知し、ノードＸ宛のルーティングテーブルの死活監視異常フラグにＯＮ（異常）を設定とする。
【０１０１】
このように、ノードが送信するＨＥＬＬＯメッセージフレームに死活監視異常状態であるノードの情報を搭載することで、特定のノードが死活監視異常状態であることを周囲のノードに通知することができる。
【０１０２】
（実施例２）
実施例２では、正常にアドホックネットワークが構築されている状態でのノード間のデータの流れ及び死活監視異常状態のノードが存在する場合でのノード間のデータの流れを説明する。
【０１０３】
図２０は、本実施形態（実施例２）における正常にアドホックネットワークが構築されている状態で、ノードＦからノードＸへデータが送信された場合のデータの流れを説明するための図である。ノードＦがノードＸ宛にデータフレームを送信する。ここでは、ノードＦはノードＸ宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＣへデータフレーム(2-i)を送信する。
【０１０４】
ノードＣがノードＸ宛にデータフレーム(2-ii)を転送する。ここでは、ノードＣは、自身が有するノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＦＦ（正常）なので、ノードＸ宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＡへデータフレーム(2-ii)を転送する。
【０１０５】
ノードＡは、ノードＸ宛にデータフレーム(2-iii)を転送する。ここでは、ノードＡは、自身が有するノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＦＦ（正常）なので、ノードX宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＸ（ＧＤ）へデータフレーム(2-iii)を転送する。
【０１０６】
次に、ノードＡがノードＸの死活監視異常を検出し、その異常検出がノードＣとノードＦに通知されていない状態で、ノードＦからノードＸ宛のデータフレームが送信された場合のデータフレームの流れを、図２１を用いて説明する。ここで、ノードＦには、サーバなどへの外部ネットワーク接続を行うノードの第一候補にノードＸが設定され、第二候補にノードＹが設定されているとする。
【０１０７】
ノードＦは、ノードＸ宛にデータフレーム（2-iv）を送信する。ここでは、ノードＦは、自身が有するノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＦＦ（正常）なので、ＬＤ１であるノードＣへデータフレーム（2-iv）を送信する。
【０１０８】
ノードＣは、ノードＸ宛（ＧＤ）にデータフレーム（2-v）を転送する。ここでは、ノードＣは、自身が有するノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＦＦ（正常）なので、ノードＸ宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＡへデータフレーム（2-v）を転送する。
【０１０９】
ノードＡは、ノードＦ宛（ＧＳ）にデータフレーム（2-vi）を転送する。ここでは、ノードＡは、自身が有するノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＮ（死活監視異常（＝通信不可））なので、ＧＤであるノードＸへ送信せず、ＧＳであるノードＦへデータフレーム（2-vi）を返信する。その際、ノードＡは、データフレーム中の送信失敗フラグをＯＮに設定し、ノードＦ宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＣへデータフレーム（2-vi）を転送する。
【０１１０】
ノードＣは、ノードＦ宛（ＧＳ）にデータフレーム（2-vii）を転送する。ここでは、ノードＣは、受信したデータフレーム中の送信失敗フラグがＯＮなので、ＧＤであるノードＸへ送信せず、ＧＳであるノードＦへデータフレームを返信する。ノードＣは、ノードＦ宛ルーティングテーブルにおいて最適経路の第１候補（ＬＤ１）であるノードＦへデータフレーム（2-vii）を転送する。
【０１１１】
ノードＦは、受信したフレームの送信失敗フラグがＯＮなので、第一候補ノードＸへのデータフレームの転送が失敗と判断する。この場合、ノードＦは、送信先（ＧＤ）を第二候補のノードＹ宛に変更して、ノードＹ宛ルーティングテーブルを参照して、ＬＤ１であるノードＧへデータフレーム（2-viii）を転送する。
【０１１２】
ノードＧは、ノードＨ（ＬＤ）に対して、ノードＹ宛（ＧＤ）のデータフレーム（2-ix）を転送する。ノードＨは、ノードＹ（ＬＤ）に対して、ノードＹ宛（ＧＤ）のデータフレーム（2-x）を転送する。
【０１１３】
このように、ノードＦは、ノードＸ宛ルーティングテーブルの死活監視異常フラグがＯＮ（異常）になった場合には、ノードＸ宛のデータフレームを送信しない。
【０１１４】
（実施例３）
実施例３では、アドホックネットワーク内の各ノードのルーティングテーブルに設定された死活監視異常をクリアすることについて説明する。本実施形態（実施例３）における、アドホックネットワーク内の全ノードに、ノードＸの死活監視異常の解除が通知されることを、図２２〜図２４を用いて説明する。
【０１１５】
図２２は、本実施形態（実施例３）における、ノードＡとノードＢがノードＸの死活監視異常を検出し、アドホックネットワーク内の全ノードに、ノードＸの死活監視異常の解除が通知された状態を説明するための図である。この場合、全てのノードが有するノードＸ宛（ＧＤ）のルーティングテーブルの死活監視異常フラグはＯＮ（異常）に設定されている。
【０１１６】
その後、ノードＸは、復旧すると、死活監視異常ＯＦＦ要求フレーム（ブロードキャストフレーム）を送信する。ノードＡとノードＢがノードＸからの死活監視異常ＯＦＦ要求フレームを受信したときの各ノードのノードＸ宛（ＧＤ）のルーティングテーブルを、図２３に示す。
【０１１７】
死活監視異常ＯＦＦ要求フレーム（ブロードキャストフレーム）を受信したノードの処理は、死活監視異常ＯＦＦ要求フレームを送信したノードから１ホップ目のノードと、送信したノードから２ホップ目以降のノードで異なる。死活監視異常ＯＦＦ要求フレームを送信したノードから１ホップ目のノードとは、図２３で言えば、ノードＸから死活監視異常ＯＦＦ要求フレームを直接受けたノードＡとノードＢをいう。また、死活監視異常ＯＦＦ要求フレームを送信したノードから２ホップ目以降のノードとは、図２３で言えば、ノードＸ以外のノードが転送した死活監視異常ＯＦＦ要求フレームを受けたノードであり、例えば、ノードＣ，Ｄ,Ｅ，Ｆをいう。
【０１１８】
１ホップ目のノードは、死活監視異常ＯＦＦ要求フレームの送信元ノードＸをＧＤとするルーティングテーブルの死活監視異常フラグをＯＦＦ（正常）に変更し、ノードＸ宛のルーティングテーブルのＬＤ１を送信元ノードＸへ変更する。２ホップ目以降のノードは、死活監視異常ＯＦＦ要求フレームの送信元ノードＸをＧＤとするルーティングテーブルの死活監視異常フラグをＯＦＦ（正常）に変更する。
【０１１９】
ノードＡがノードＸからの死活監視異常ＯＦＦ要求フレームを受信し、死活監視異常ＯＦＦ要求フレーム（ブロードキャストフレーム）を送信した後の各ノードのルーティングテーブルを、図２４に示す。なお、ノードＢも死活監視異常ＯＦＦ要求フレームを送信するが、ここでは割愛する。
【０１２０】
その後、ノードＦはノードＣ，Ｄ，Ｅのいずれかのノードが転送した死活監視異常ＯＦＦ要求フレームを受信し、ノードＸ宛ルーティングテーブルの死活監視異常フラグをＯＦＦ（正常）に変更する。
【０１２１】
次に、実施例１〜３についてのノードの処理フローについて説明する。
図２５は、本実施形態（実施例１〜３）におけるノードの全体処理のフローを示す。ＣＰＵ２２は、不揮発性メモリ２４等に格納したプログラムを読み出し、ＨＥＬＬＯ制御部３１、フレーム送信処理部３２、フレーム受信処理部３３、ルーティング部３４、死活監視部３５、アプリケーション処理部３６として機能して、図２５の処理を行う。
【０１２２】
まず、ＣＰＵ２２は、死活監視処理を行う（Ｓ１）。Ｓ１の詳細は、図２７にて詳述する。
【０１２３】
ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームの送信タイミングが到来したか否かを判定する（Ｓ２）。ＨＥＬＬＯメッセージフレームの送信タイミングが到来した場合（Ｓ２で「Ｙｅｓ」）、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレーム生成・送信処理を行う（Ｓ８）。Ｓ８の詳細は、図２６にて詳述する。
【０１２４】
ＨＥＬＬＯメッセージフレームの送信タイミングが到来していない場合（Ｓ２で「Ｎｏ」）、ＣＰＵ２２は、自ノードがデータフレームを生成する場合（Ｓ３で「Ｙｅｓ」）、データフレームを生成する（Ｓ９）。Ｓ９の処理後、Ｓ６の処理へ進む。
【０１２５】
ＣＰＵ２２は、無線通信Ｉ／Ｆ２５からフレームを受信した場合（Ｓ４で「Ｙｅｓ」）、フレームを振り分ける（Ｓ５）。受信したフレームがデータフレームである場合（Ｓ５で「Ｙｅｓ」）、ＣＰＵ２２は、ルーティング処理を行う（Ｓ６）。Ｓ６の詳細は、図２８にて詳述する。
【０１２６】
受信したフレームがＨＥＬＬＯメッセージフレームである場合（Ｓ５で「Ｎｏ」）、ＣＰＵ２２は、経路構築処理を行う（Ｓ７）。Ｓ７の詳細は、図２９にて詳述する。
【０１２７】
図２６は、本実施形態におけるＨＥＬＬＯメッセージフレーム生成・送信処理（Ｓ８）の詳細フローを示す。ＣＰＵ２２は、ＲＡＭ２３から１つのルーティングテーブル３９を読み出す（Ｓ８−１）。
【０１２８】
ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームを生成する（Ｓ８−２）。ＨＥＬＬＯメッセージフレームは、ローカル宛先アドレス（ＬＤ）、ローカル差出アドレス（ＬＳ）、グローバル宛先アドレスＧＤ、グローバル差出アドレス（ＧＳ）、フレームＩＤ（ＦＩＤ）、タイプ、死活監視異常フラグの各フィールドを含むヘッダを有する。ここでは、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームのＬＤに、隣接するすべてのノード装置へのブロードキャストを表す特殊な値ＦＦという所定の値を設定し、ＬＳに自ノードのアドレスを設定する。
【０１２９】
なお、ここでの「ブロードキャスト」は「隣接するすべてのノード装置へのブロードキャスト」であり、「ネットワーク全体へのフラッディング」ではないので注意されたい。
【０１３０】
ＣＰＵ２２は、読み出したルーティングテーブル３９の死活監視異常フラグがＯＮか否かを判定する（Ｓ８−３）。ルーティングテーブル３９の死活監視異常フラグがＯＮの場合（Ｓ８−３で「Ｙｅｓ」）、ＣＰＵ２２は、次の処理を行う、すなわち、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームに、そのルーティングテーブル３９のＧＤに対して設定されたノードについての死活監視異常フラグをＯＮに設定する（Ｓ８−４）。ここで、ＨＥＬＬＯメッセージフレームへのそのノードについての死活監視異常フラグの設定は、そのノードが異常であることを示すビットをＯＮにする。例えば、ブロードキャスト時にＨＥＬＬＯメッセージフレームにて有効に使用していない項目に死活監視異常のノードを特定するノードＩＤを設定し、死活監視異常フラグフィールドのビットをＯＮにしてもよい。または死活監視異常ノードを指定するフィールドをフレームのヘッダに設けて、そのフィールドに死活監視異常ノードのノードＩＤを設定しても良い。
【０１３１】
ルーティングテーブル３９の死活監視異常フラグがＯＦＦの場合（Ｓ８−３で「Ｎｏ」）、ＣＰＵ２２は、次の処理を行う、すなわち、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームに、そのルーティングテーブル３９のＧＤに設定されたノードについての死活監視異常フラグをＯＦＦに設定する（Ｓ８−５）。
【０１３２】
Ｓ８−３〜Ｓ８−５の処理は、ＲＡＭ２３に格納されているルーティングテーブル３９に登録されているＧＤ数分、繰り返される。
【０１３３】
ＣＰＵ２２は、生成したＨＥＬＬＯメッセージフレームを、ブロードキャスト送信する（Ｓ８−６）。これにより、ＨＥＬＬＯメッセージフレーム１つでルーティングテーブルの複数エントリ分を送信することができる。
【０１３４】
図２７は、本実施形態における死活監視処理（Ｓ１）の詳細フローを示す。ノードが起動直後でない場合（Ｓ１−１）、Ｓ１−３の処理へ進む。ノードが起動直後である場合（Ｓ１−１で「Ｙｅｓ」）、ＣＰＵ２２は、死活監視異常ＯＦＦ要求を、隣接するすべてのノード装置へブロードキャスト送信する（Ｓ１−２）。
【０１３５】
次に、ＣＰＵ２２は、ＲＡＭ２３に格納しているルーティングテーブル３９においてＧＤとして登録された各ノードから送信されるＨＥＬＬＯメッセージの受信間隔を監視し、その確認を行う（Ｓ１−３）。
【０１３６】
その受信間隔の確認の結果、所定の監視時間内に、ルーティングテーブル３９においてＧＤとして登録されたいずれかのノードからＨＥＬＬＯメッセージが受信できなかった場合（Ｓ１−４で「Ｙｅｓ」）、ＣＰＵ２２は、次の処理を行う。すなわち、ＣＰＵ２２は、そのノード（ＧＤ）宛のルーティングテーブル３９において、死活監視異常フラグをＯＮにする（Ｓ１−５）。
【０１３７】
図２８は、本実施形態におけるルーティング処理（Ｓ６）の詳細フローを示す。ＣＰＵ２２は、受信したフレームが死活監視異常ＯＦＦ要求フレームであるか否かを判定する（Ｓ６−１）。
【０１３８】
受信したフレームが死活監視異常ＯＦＦ要求フレームである場合（Ｓ６−１で「Ｙｅｓ」）、ＣＰＵ２２は、次の処理を行う。すなわち、ＣＰＵ２２は、データフレームの送信元（ＧＳ）をＧＤとするルーティングテーブルを検索し、検索されたルーティングテーブルの死活監視異常フラグをＯＦＦにする（Ｓ６−１４）。
【０１３９】
ＣＰＵ２２は、死活監視異常ＯＦＦ要求フレームをブロードキャスト送信する（Ｓ６−１５）。なお、ここでの「ブロードキャスト」はネットワーク全体へのフラッディングを伴うブロードキャストである。
【０１４０】
受信したフレームが死活監視異常ＯＦＦ要求フレームでない場合（Ｓ６−１で「Ｎｏ」）、ＣＰＵ２２は、受信したフレームのヘッダに含まれる送信失敗フラグがＯＦＦか否かを判定する（Ｓ６−２）。
【０１４１】
受信したフレームのヘッダに含まれる送信失敗フラグがＯＦＦである場合（Ｓ６−２で「Ｙｅｓ」）、ＣＰＵ２２は、受信したフレームのヘッダからグローバル宛先アドレス（ＧＤ）を取得し、そのＧＤについてのルーティングテーブルを検索する（Ｓ６−７）。
【０１４２】
ＣＰＵ２２は、検索されたルーティングテーブルの死活監視異常フラグがＯＮか否かを判定する（Ｓ６−８）。
【０１４３】
検索されたルーティングテーブルの死活監視異常フラグがＯＦＦである場合（Ｓ６−８で「Ｎｏ」）、ＣＰＵ２２は、その検索されたルーティングテーブルに格納されたローカル宛先アドレス（ＬＤ１，ＬＤ２，ＬＤ３）から転送先を選択する。ＣＰＵ２２は、選択した転送先をローカル宛先アドレス（ＬＤ）としてデータフレームを送信する（Ｓ６−１３）。
【０１４４】
検索されたルーティングテーブルの死活監視異常フラグがＯＮである場合（Ｓ６−８で「Ｙｅｓ」）、ＣＰＵ２２は、そのフレームが自ノードで生成されたフレームか否かを判定する（Ｓ６−９）。
【０１４５】
そのフレームが自ノードで生成されたフレームである場合（Ｓ６−９で「Ｙｅｓ」）、ＣＰＵ２２は、送信先（ＧＤ）が他にあるかを判定する（Ｓ６−１１）。送信先（ＧＤ）が他にある場合（Ｓ６−１１で「Ｙｅｓ」）、ＣＰＵ２２は、Ｓ６−５の処理を行う。送信先（ＧＤ）が他にない場合（Ｓ６−１１で「Ｎｏ」）ＣＰＵ２２は、データフレームを送信せずに、廃棄する（Ｓ６−１２）。そのフレームが自ノードで生成されたフレームでない場合（Ｓ６−９で「Ｎｏ」）、ＣＰＵ２２は、データフレーム内の送信失敗フラグにＯＮを設定し（Ｓ６−１０）、Ｓ６−６へ進む。
【０１４６】
Ｓ６−２において、受信したフレームのヘッダに含まれる送信失敗フラグがＯＮである場合（Ｓ６−２で「Ｎｏ」）、ＣＰＵ２２は、そのフレームが自ノードで生成されたフレームか否かを判定する（Ｓ６−３）。
【０１４７】
そのフレームが自ノードで生成されたフレームである場合（Ｓ６−３で「Ｙｅｓ」）、ＣＰＵ２２は、送信先（ＧＤ）が他にあるかを判定する（Ｓ６−４）。送信先（ＧＤ）が他にない場合（Ｓ６−４で「Ｎｏ」）、ＣＰＵ２２は、Ｓ６−１２の処理を行う。送信先（ＧＤ）が他にある場合（Ｓ６−４で「Ｙｅｓ」）ＣＰＵ２２は、そのＧＤについてのルーティングテーブルを検索する。ＣＰＵ２２は、その検索されたルーティングテーブルに格納されたローカル宛先アドレス（ＬＤ１，ＬＤ２，ＬＤ３）から転送先を選択する。ＣＰＵ２２は、選択した転送先をローカル宛先アドレス（ＬＤ）としてデータフレームを送信する（Ｓ６−５）。
【０１４８】
そのフレームが自ノードで生成されたフレームでない場合（Ｓ６−３で「Ｎｏ」）、ＣＰＵ２２は、受信したフレームのヘッダからグローバル差出アドレス（ＧＳ）を取得し、そのＧＳをＧＤとするルーティングテーブルを検索する。ＣＰＵ２２は、その検索されたルーティングテーブルに格納されたローカル宛先アドレス（ＬＤ１，ＬＤ２，ＬＤ３）から転送先を選択する。ＣＰＵ２２は、選択した転送先をローカル宛先アドレス（ＬＤ）としてデータフレームを送信する（Ｓ６−６）。ここで送信されるデータフレーム内の送信失敗フラグはＯＮになっている。
【０１４９】
図２９は、本実施形態における経路構築処理（Ｓ７）の詳細フローを示す。ＣＰＵ２２は、受信したＨＥＬＬＯメッセージフレームに設定された死活監視異常フラグがＯＮか否かを判定する（Ｓ７−１）。受信したＨＥＬＬＯメッセージフレームに設定された死活監視異常フラグがＯＦＦの場合、Ｓ７−３へ進む。
【０１５０】
受信したＨＥＬＬＯメッセージフレームに設定された死活監視異常フラグがＯＮの場合（Ｓ７−１で「Ｙｅｓ」）、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームから、死活監視による異常状態にあるとして設定されたノードＩＤを読み出す。ＣＰＵ２２は、その読み出したノードＩＤをＧＤとするルーティングテーブルを検索する。ＣＰＵ２２は、検索されたルーティングテーブルの死活監視異常フラグをＯＮに設定する（Ｓ７−２）。
【０１５１】
その後、ＣＰＵ２２は、通常のＨＥＬＬＯメッセージフレーム受信処理を行う（Ｓ７−３）。例えば、ＣＰＵ２２は、ＨＥＬＬＯメッセージフレームに設定された情報に基づいて、各経路の通信品質を計算し、その計算結果に基づいて、最終宛先までの複数の経路を構築する。このとき、ＣＰＵ２２は、リンクテーブルの新規作成、更新、または削除、及びルーティングテーブルの新規作成、更新、または削除等を行う。
【０１５２】
なお、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【０１５３】
上記実施形態に関し、更に以下の付記を開示する。
（付記１）
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置であって、
いずれかのノード装置が異常状態か否かを示すノード死活情報を記憶する記憶部と、
データフレームを受信し、前記記憶部に記憶された前記ノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定する決定部と、
決定した前記宛先が設定された前記データフレームを送信する送信部と、
を備えることを特徴とするノード装置。
（付記２）
前記ノード装置は、さらに、
自ノード装置と隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を取得する取得部
を備えることを特徴とする付記１に記載のノード装置。
（付記３）
前記送信部は、さらに、自ノードと隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を、自ノードと隣接するノード装置に送信する
ことを特徴とする付記１に記載のノード装置。
（付記４）
前記決定部は、前記判定の結果に応じて、前記データフレームの宛先を、該データフレームから取得した送信元のノード装置に決定する場合、前記データフレームから取得した送信先への送信が失敗したことを示す送信失敗情報を該データフレームに付与する
ことを特徴とする付記１〜３のうちいずれか１項に記載のノード装置。
（付記５）
前記ノード装置は、さらに、
自ノード装置が生成して送信したデータフレームであって、前記送信失敗情報が付与された該データフレームを受信した場合、該データフレームの宛先を他のノード装置に変更する変更部
を備えることを特徴とする付記４に記載のノード装置。
（付記６）
前記ノード装置は、さらに、
異常状態から復旧したノード装置についての前記ノード死活情報を異常状態から正常状態へ変更させる要求を、隣接するノード装置へ送信する要求部
を備えることを特徴とする付記１〜５のうちいずれか１項に記載のノード装置。
（付記７）
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置に処理を実行させる制御プログラムであって、
データフレームを受信し、記憶部から読み出したいずれかのノード装置が異常状態か否かを示すノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、
該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定し、
決定した前記宛先が設定された前記データフレームを送信する、
処理を実行させる制御プログラム。
（付記８）
前記制御プログラムは、前記ノード装置に、さらに、
自ノード装置と隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を取得する
処理を実行させることを特徴とする付記７に記載の制御プログラム。
（付記９）
前記制御プログラムは、前記ノード装置に、さらに、
自ノードと隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を、自ノードと隣接するノード装置に送信する
処理を実行させることを特徴とする付記７または８に記載の制御プログラム。
（付記１０）
前記判定の結果に応じて、前記データフレームの宛先を、該データフレームから取得した送信元のノード装置に決定する場合、前記データフレームから取得した送信先への送信が失敗したことを示す送信失敗情報を該データフレームに付与する
ことを特徴とする付記７〜９のうちいずれか１項に記載の制御プログラム。
（付記１１）
前記制御プログラムは、前記ノード装置に、さらに、
自ノード装置が生成して送信したデータフレームであって、前記送信失敗情報が付与された該データフレームを受信した場合、該データフレームの宛先を他のノード装置に変更する
処理を実行させることを特徴とする付記９に記載の制御プログラム。
（付記１２）
前記制御プログラムは、前記ノード装置に、さらに、
異常状態から復旧したノード装置についての前記ノード死活情報を異常状態から正常状態へ変更させる要求を、隣接するノード装置へ送信する
処理を実行させることを特徴とする付記７〜１１のうちいずれか１項に記載の制御プログラム。
（付記１３）
隣接するノード装置間で無線通信することにより無線通信ネットワークを構築するノード装置の動作方法であって、
前記ノード装置は、
データフレームを受信し、記憶部から読み出したいずれかのノード装置が異常状態か否かを示すノード死活情報に基づいて、該データフレームから取得した送信先のノード装置の死活状態の判定を行い、
該判定の結果に応じて、前記データフレームから取得した送信先のノード装置及び前記データフレームから取得した送信元のノード装置から、該データフレームの宛先を決定し、
決定した前記宛先が設定された前記データフレームを送信する、
ことを実行するノード装置の動作方法。
（付記１４）
前記ノード装置は、さらに、
自ノード装置と隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を取得する
ことを実行する付記１３に記載のノード装置の動作方法。
（付記１５）
前記ノード装置は、さらに、
自ノードと隣接するノード装置についての前記ノード死活情報、または自ノード装置と隣接していないノード装置についてのノード死活情報を、自ノードと隣接するノード装置に送信する
処理を実行させることを特徴とする付記１３または１４に記載の動作方法。
【符号の説明】
【０１５４】
１１    ノード装置
１２    記憶部
１３    決定部
１４    送信部
１５    取得部
１６    変更部
１７    要求部
２１    ノード装置
２２    ＣＰＵ
２３    ＲＡＭ
２４    不揮発性メモリ
２５    無線通信インターフェース
３１    ＨＥＬＬＯ制御部
３２    フレーム送信処理部
３３    フレーム受信処理部
３４    ルーティング部
３５    死活監視部
３６    アプリケーション処理部
３７    受信部
３８    送信部
３９    ルーティングテーブル
【図１】
2015097347.tif 000003
【図２】
2015097347.tif 000004
【図３】
2015097347.tif 000005
【図４】
2015097347.tif 000006
【図５】
2015097347.tif 000007
【図６】
2015097347.tif 000008
【図７】
2015097347.tif 000009
【図８】
2015097347.tif 000010
【図９】
2015097347.tif 000011
【図１０】
2015097347.tif 000012
【図１１】
2015097347.tif 000013
【図１２】
2015097347.tif 000014
【図１３】
2015097347.tif 000015
【図１４】
2015097347.tif 000016
【図１５】
2015097347.tif 000017
【図１６】
2015097347.tif 000018
【図１７】
2015097347.tif 000019
【図１８】
2015097347.tif 000020
【図１９】
2015097347.tif 000021
【図２０】
2015097347.tif 000022
【図２１】
2015097347.tif 000023
【図２２】
2015097347.tif 000024
【図２３】
2015097347.tif 000025
【図２４】
2015097347.tif 000026
【図２５】
2015097347.tif 000027
【図２６】
2015097347.tif 000028
【図２７】
2015097347.tif 000029
【図２８】
2015097347.tif 000030
【図２９】
2015097347.tif 000031