(57)【要約】【課題】【解決手段】  ネットワークにおいてルーティング情報を更新する方法であり、ネットワークの他のノードのリブート情報は、所定のノードが最近のルート更新データを有するか否かを判定するために使用される。所定のノードが最近リブートされていないことをリブート情報が示す場合、所定のノードからのルーティング情報は、比較するノードのルーティング情報を更新するために使用される。リブート情報は、ノードがリブート処理を行なったことに応答してノードによりインクリメントされるリブートカウンタであっても良い。ノードはリブートすると、隣接ノードからのリブートカウンタを要求しても良い。受信したリブートカウンタは、少なくとも１つのノードに関して格納されたリブートカウンタと比較される。リブートするノードは、自身のリブートカウンタを格納されたリブートカウンタから変更していないノードからルーティング情報を受信するように選択しても良い。隣接ノードのいずれも未変更のリブートカウンタを有さない場合、リブートするノードがリブートカウンタに従って最近リブートされていないノードを発見するまで対応して格納されたリブートカウンタと比較され且つそのノードからルーティング情報をダウンロードしてもよい他のノードのリブートカウンタに対して要求が行なわれても良い。ユーティリティネットワークのノードに対して電力が回復された後、そのノードはユーティリティの中央制御設備にメッセージをルーティングするために１つ以上の隣接ノードをプロキシとして採用する。
2011515988.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおける第１のノードによりルーティング情報を更新する方法であって、
前記第１のノードと関連付けられたメモリに前記ネットワークにおける第１のノードのルーティング情報を格納するステップと、
前記ネットワークにおける第２のノードがリブートしたか否かに関する情報を含む前記第２のノードのリブート情報を前記メモリに格納するステップと、
前記ネットワークにおける前記第１のノードがリブートすると、前記ネットワークにおける前記第２のノードからリブート情報を受信するステップと、
前記第２のノードに関して前記格納されたリブート情報を前記メモリから取得するステップと、
前記第１のノードのリブートと同時期に前記第２のノードがリブートされたか否かを前記第１のノードにおいて判定するため、前記受信された第２のノードのリブート情報と前記取得された第２のノードのリブート情報とを前記第１のノードにおいて比較するステップと、
前記第１のノードのリブートと同時期に前記第２のノードがリブートしていないと判定された場合、前記第２のノードからダウンロードされたルーティング情報により前記第１のノードの前記格納されたルーティング情報を更新するステップと
を含むことを特徴とする方法。
【請求項２】
前記リブート情報は、リブートカウンタを含み、
前記リブートカウンタのより大きな値は、前記リブートカウンタと関連付けられた前記ノードによるより多くのリブートを示す
ことを特徴とする請求項１記載の方法。
【請求項３】
前記リブート情報は、
前記リブートカウンタが最後に更新された時間を示すリブート時間情報を更に含む
ことを特徴とする請求項２記載の方法。
【請求項４】
前記第２のノードが最近リブートされたことを前記リブートカウンタが示す場合、前記第１のノードと同時期にリブートされていないことを受信したリブート情報が示すノードを見つけるまで、前記ネットワークにおける少なくとも１つの他のノードから前記リブート情報を要求及び受信するステップと、
前記見つけられたノードからダウンロードされたルーティング情報により前記第１のノードの前記メモリに格納された前記ルーティング情報を更新するステップと
を更に含むことを特徴とする請求項２記載の方法。
【請求項５】
前記ネットワークにおける前記第１のノードがリブートすると、複数のノードにリブート情報要求を送出するステップを更に含み、
前記複数のノードを識別する情報は、前記第１のノードと関連付けられた前記メモリに格納される
ことを特徴とする請求項４記載の方法。
【請求項６】
前記第１のノードと同時期にリブートされていないことを関連するリブート情報が示すノードが見つけられない場合、
別のパワーノードを選択するステップと、
前記選択した別のパワーノードからルーティング更新情報を取得するステップと、
前記選択した別のパワーノードから取得された前記ルーティング更新情報により前記第１のノードの前記格納されたルーティング情報を更新するステップと
を更に含むことを特徴とする請求項４記載の方法。
【請求項７】
ネットワークにおけるノード間でルーティング情報を更新する方法であって、
前記ネットワークにおける第１のノードと関連付けられた不揮発性メモリに前記第１のノードのルーティング情報を格納するステップと、
前記ネットワークにおける少なくとも１つの追加のノードが実行したリブートの回数を示すリブートカウンタを含むとともに、該ノードに関連付けられるリブート情報を前記少なくとも１つの追加のノードから前記第１のノードにおいて受信するステップと、
前記受信したリブート情報を前記不揮発性メモリに格納するステップと、
前記第１のノードがリブートした場合に前記ネットワークにおける前記少なくとも１つの追加のノードからのリブート情報を要求するステップと、
前記少なくとも１つの追加のノードが実行したリブートの回数を示すリブートカウンタを含むとともに、該ノードに関連付けられる更新されたリブート情報を前記ネットワークにおける前記少なくとも１つの追加のノードから受信するステップと、
前記不揮発性メモリから前記少なくとも１つの追加のノードの前記格納されたリブート情報を取得するステップと、
前記取得及び格納されたリブート情報が受信されてから前記少なくとも１つの追加のノードがリブートされていないか否かを前記第１のノードにおいて判定するため、前記ネットワークにおける前記少なくとも１つの追加のノードからの前記受信及び更新されたリブート情報と、前記少なくとも１つの追加のノードの前記取得及び格納されたリブート情報とを前記第１のノードにおいて比較するステップと、
前記取得及び格納されたリブート情報が前記少なくとも１つの追加のノードから受信されてから前記少なくとも１つの追加のノードがリブートされていないと判定される場合、前記少なくとも１つの追加のノードからのルーティング情報により前記第１のノードの前記格納されたルーティング情報を更新するステップと
を含むことを特徴とする方法。
【請求項８】
前記少なくとも１つの追加のノードの前記取得及び格納されたリブート情報が受信されてから前記少なくとも１つの追加のノードがリブートされていない場合、前記少なくとも１つの追加のノードの前記取得及び格納されたリブート情報が受信されてからリブートされていない前記少なくとも１つの追加のノードからのルーティング情報を要求するステップ
を更に含むことを特徴とする請求項７記載の方法。
【請求項９】
前記少なくとも１つの追加のノードから受信された前記リブート情報に含まれた前記リブートカウンタは、前記少なくとも１つの追加のノードが実行したリブートの回数を示す整数値である
ことを特徴とする請求項７記載の方法。
【請求項１０】
前記第１のノードがリブートすると、前記第１のノードのリブートカウンタをインクリメントするステップと、
前記ネットワークにおける少なくとも１つの他のノードに前記第１のノードのリブートカウンタを送信するステップと
を更に含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記第１のノードのリブートカウンタは、
前記ネットワークにおける別のノードから受信されたルーティング更新要求に応答して送信される
ことを特徴とする請求項１０記載の方法。
【請求項１２】
前記第１のノードのリブートカウンタは、
リブート情報に関する要求で前記第１のノードから前記ネットワークにおける少なくとも１つの他のノードに送信される
ことを特徴とする請求項１０記載の方法。
【請求項１３】
前記第１のノードのリブートカウンタは、
前記第１のノードのリブートカウンタの前記インクリメントに応答して送信される
ことを特徴とする請求項１０記載の方法。
【請求項１４】
第１のネットワークにおける第１のノードがリブートすると、前記第１のネットワークにおける追加のノードの予め設定されたグループがリブートされたか否かを前記第１のノードにおいて判定するステップと、
前記追加のノードの予め設定されたグループがリブートされたと判定される場合に、前記第１のネットワークのメンバであり且つ前記第１のネットワークとは異なる第２のネットワークのメンバであるネットワークオーバラップノードを選択するステップと、
前記選択したネットワークオーバラップノードから更新情報を取得するステップと
を含むことを特徴とする方法。
【請求項１５】
前記ノードの予め設定されたグループがリブートしたか否かを判定するステップは、
前記ノードの予め設定されたグループの１つのノードに関して受信されたノードリブート情報と、受信された前記ノードリブート情報の送信元の前記ノードに関して取得されたノードリブート情報とを前記第１のノードにおいて比較するステップと、
前記関連するノードが前記第１のノードと同時期にリブートされていないか否かを判定するため、前記受信されたノードリブート情報と前記取得されたノードリブート情報とを比較するステップと、
前記第１のノードと同時期にリブートされていないと判定された前記ノードからダウンロードされたルーティング情報により前記第１のノードの前記格納されたルーティング情報を更新するステップと
を含むことを特徴とする請求項１４記載の方法。
【請求項１６】
前記リブート情報は、リブートカウンタを含み、
前記リブートカウンタのより大きな値は、前記リブートカウンタと関連付けられた前記ノードによるより多くのリブートを示す
ことを特徴とする請求項１５記載の方法。
【請求項１７】
前記リブート情報は、
前記リブートカウンタが最後に更新された時間を示すリブート時間情報を更に含む
ことを特徴とする請求項１６記載の方法。
【請求項１８】
前記リブートカウンタと関連付けられた前記ノードが最近リブートされたことを前記リブートカウンタが示す場合、前記第１のノードと同時期にリブートされていないことを受信したリブート情報が示すノードを見つけるまで、前記ノードの予め設定されたグループの少なくとも１つの他のノードから前記リブート情報を要求及び受信するステップと、
前記見つけられたノードからダウンロードされたルーティング情報により前記第１のノードの前記ルーティング情報を更新するステップと
を更に含むことを特徴とする請求項１６記載の方法。
【請求項１９】
前記ネットワークオーバラップノードを前記選択するステップは、
所定のノードが異なるネットワークに対応するネットワークアドレスを有するか否かを判定するため、前記所定のノードに対応する前記ネットワークアドレスを比較するステップ
を含むことを特徴とする請求項１４記載の方法。
【請求項２０】
ネットワークオーバラップノードが更新情報を受信できない場合、
別のパワーノードを選択するステップと、
前記選択した別のパワーノードから更新情報を取得するステップと
を更に含むことを特徴とする請求項１４記載の方法。
【請求項２１】
ユーティリティ通信ネットワークにおいて停電からの回復の通知を提供する方法であって、
前記ユーティリティ通信ネットワークにおけるノードがリブートすると、前記ノードが通信可能な前記通信ネットワークにおける隣接ノードを発見するステップと、
発見した隣接ノードを前記リブートしたノードに対するプロキシとして選択するステップと、
前記リブートしたノードが前記ネットワーク内で最近オンラインになったことを示す回復メッセージを前記リブートしたノードから前記メッセージの宛先である前記選択したプロキシノードに送信するステップと
を含むことを特徴とする方法。
【請求項２２】
前記プロキシノードは、
所定の宛先に前記メッセージをルーティングするために前記メッセージの受信に応答可能である
ことを特徴とする請求項２１記載の方法。
【請求項２３】
前記プロキシノードの選択は、前記隣接ノードの有効期間に依存して行なわれる
ことを特徴とする請求項２１記載の方法。
【請求項２４】
前記プロキシノードの選択は、所定の宛先ノードにメッセージを転送する機能に依存して行なわれる
ことを特徴とする請求項２１記載の方法。
【請求項２５】
前記リブートが前記ノードに対する電力の損失の結果として起こったか否かを判定するステップと、
前記リブートが前記ノードに対する電力の損失の結果として起こったと判定されたか否かに依存して前記選択するステップ及び前記送信するステップを選択的に実行するステップと
を更に含むことを特徴とする請求項２１記載の方法。
【請求項２６】
ユーティリティ通信ネットワークにおいて停電からの回復の通知を提供する方法であって、
前記ユーティリティ通信ネットワークにおけるノードがリブートすると、前記リブートが前記ノードに対する電力の損失の結果として起こったか否かを判定するステップと、
前記リブートが前記ノードに対する電力の損失の結果として起こったと判定される場合に、前記ノードが前記電力の損失から回復したことを示し且つ前記電力の損失からの回復状態に関連するパラメータ値を含む回復メッセージを前記ノードから自動的に送信するステップと
を含むことを特徴とする方法。
【請求項２７】
前記ノードがリブートすると通信可能な前記通信ネットワークにおける隣接ノードを発見するステップと、
発見した隣接ノードを前記リブートしたノードに対するプロキシとして選択するステップと、
前記メッセージの宛先である前記選択したプロキシノードに前記回復メッセージを送信するステップと
を更に含むことを特徴とする請求項２６記載の方法。
【請求項２８】
前記プロキシノードは、
前記メッセージを所定の宛先にルーティングするために前記回復メッセージの受信に応答可能である
ことを特徴とする請求項２７記載の方法。
【請求項２９】
前記プロキシノードの選択は、前記隣接ノードの有効期間に依存して行なわれる
ことを特徴とする請求項２７記載の方法。
【請求項３０】
前記プロキシノードの選択は、所定の宛先ノードにメッセージを転送する機能に依存して行なわれる
ことを特徴とする請求項２７記載の方法。
【請求項３１】
前記パラメータ値は、
前記停電の発生、電力の回復及び前記停電の長さのうちの少なくとも１つに関連する時間値を含む
ことを特徴とする請求項２６記載の方法。
【請求項３２】
前記パラメータ値は、前記ノードに関するリブートカウンタを含む
ことを特徴とする請求項２６記載の方法。
【請求項３３】
前記メッセージは、
予め格納されたデータベースからのルーティングパラメータに関する入手可能な情報を更に含む
ことを特徴とする請求項２６記載の方法。
【請求項３４】
前記リブートしたノードは、
前記ネットワークにおける別のノードとの通信リンクを確立する前に前記メッセージをブロードキャストする
ことを特徴とする請求項２６記載の方法。
【請求項３５】
ユーティリティ通信ネットワークにおける停電からの回復の通知を提供する方法であって、
隣接ノードが前記ネットワークにおいてアクティブである期間を示す前記隣接ノードの有効期間が所定の閾値より短いか否かを判定するため、前記ネットワークにおける第１のノードにおいて複数の隣接ノードから受信されたメッセージを検査するステップと、
前記隣接ノードが前記閾値より短い有効期間を有すると判定される場合、前記隣接ノードが前記ネットワークにおいて現在アクティブであることを示すメッセージを前記第１のノードにおいて自動的に作成及び送信するステップと
を含むことを特徴とする方法。
【請求項３６】
前記メッセージは、前記隣接ノードの前記有効期間の指示を含む
ことを特徴とする請求項３７記載の方法。
【請求項３７】
前記メッセージは、タイムスタンプを更に含む
ことを特徴とする請求項３６記載の方法。
【請求項３８】
前記第１のノードの有効期間が第２の閾値より長い場合、前記第１のノードは前記メッセージのみを作成及び送信する
ことを特徴とする請求項３５記載の方法。
【請求項３９】
前記第２の閾値は、動的に調整可能である
ことを特徴とする請求項３８記載の方法。
【請求項４０】
前記第２の閾値の動的な調整は、領域における停電の状況に基づいて行なわれる
ことを特徴とする請求項３９記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信ネットワークにおけるパケットのルーティングに関し、特に、通信の割込み後にルーティング情報を迅速に更新し且つそれに関する通知を送出する機能に関する。
【背景技術】
【０００２】
最初にノードがネットワークにおいて立ち上がった時、ノードは、宛先ノードとの通信を可能にする情報を取得する必要がある。固定の有線ネットワークの場合、その情報はノードに予めプログラムされていても良い。その結果、ノードは起動されると、他のノードとすぐに通信できる。しかし、他の種類のネットワークにおいては、ノードは他の所望のノードと効果的に通信できるようになる前にネットワークの構成に関して学習する必要がある場合もある。例えば、無線アドホック・サブネットワークは、サブネットワークのノードがサブネットワーク外の宛先と通信する際に介することができるアクセスポイントを１つのみ又は最大でも数個しか有さない場合がある。サブネットワークの全てのノードがアクセスポイントに直接リンクを有するわけではないため、ノードはアクセスポイントに対する通信パスを提供する隣接ノードに依存する。従って、ネットワーク内の効率的な通信を容易にするために、ノードはアクセスポイントまでの種々のルートの品質、長さ、待ち時間等に関するデータを提供するルーティング情報をやり取りしても良い。
【０００３】
最初にノードがアドホックネットワークに組み込まれる場合、ノードは、最近接する隣接ノード、すなわち、直接通信リンクを有する他のノードのうちアクセスポイントまでのパスを提供できるノードを識別する発見処理が行なわれても良い。ノードは、動的に変化するネットワーク条件下で効果的にアクセスポイントと確実に通信する機能を保証するために、隣接ノードと情報をやり取りし且つルーティング情報を更新し続けても良い。ノードがアクセスポイントへのパスを確立する際に介する手順の一例は、特許文献１に記載されている。
【０００４】
ノードがルーティング情報を確立又は確認する必要がある別の状況は、ノードに対してリブート動作が行なわれた後である。リブートは、ソフトウェアのアップグレード、電力損失、定期的にスケジューリングされた保守手順等の種々の異なる条件の結果行なわれるであろう。リブート後、ノードは、ルーティング情報を取得するとともに通信を再開するために、例えば、上述したような全てのネットワーク発見処理が行なわれても良い。しかし、この処理は、非常に時間がかかる可能性がある。ノードがリブート後に迅速に回復し且つ通信を再開することを可能にするために、リブート前に行なわれたネットワーク通信の結果としてノードが既に利用可能である可能性がある情報を採用するのが好ましい。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００７／０１２０７０５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
１つの特定の応用例において、無線アドホックネットワークは、電気ユーティリティの中央制御設備と、ユーティリティ（utility）により供給された電力の顧客の消費量を測定するメータとの間の通信を提供するために採用されても良い。消費量測定電気メータが同一の場所に配置される顧客に給電する配電インフラストラクチャにおいて停電が起こった場合、メータと関連し且つ同一の場所に配置されたアドホック無線ネットワークの通信ノードは電力を失い、給電が再開した時にリブートすることが必要となるであろう。場合によっては、ユーティリティ制御設備は、顧客の建物（premise）で電気メータと同一の場所に配置されたネットワークノードがネットワークに再度参加し且つ動作を再開したことを報告するまで電力が顧客の建物に対して回復されたことに気付かないこともある。大規模な停電が起こり、サービススタッフが障害を回復するために現場にいる場合、ユーティリティは、電力が回復されたか否か、並びに回復された場合は回復されたノード及び配電インフラストラクチャの部分を迅速に知ることが望ましい。これを知ることにより、ユーティリティは、全ての障害が修復され且つ回復活動が終了したか、又は他の障害が依然として存在し且つ一部の顧客が電力を得られないままであるかを判定できる。
【課題を解決するための手段】
【０００７】
開示された本発明の１つの態様によると、ルーティング情報は、ネットワークの他のノードから入手可能なルーティング情報の信頼性を評価することにより、リブート動作が行なわれたノードにおいて更新される。第１のノードがリブートされると、第１のノードはネットワーク内の少なくとも１つの他のノードからリブート情報を受信する。第１のノードは、メモリに予め格納された他のノードに関するリブート情報を取得する。他のノードから受信したリブート情報は、メモリから取得されたリブート情報と比較される。受信したリブート情報と取得されたリブート情報との比較により、他のノードが第１のノードと同時期にリブートされていないことが示される場合、第１のノードのルーティング情報は、第２のノードからダウンロードされたルーティング情報により更新される。
【０００８】
開示された本発明の別の態様によると、電力がユーティリティネットワークのノードに対して回復した後、そのノードはユーティリティの中央制御設備にメッセージを中継するために隣接ノードのうちの１つをプロキシとして採用する。メッセージは、回復されたノードに関する情報を含み、１つ以上の隣接ノードに関する情報を更に含む。この情報は、リブートカウンタ、ノードがダウンしていた時間の長さ、瞬間的な停電又は電力の変動、並びに／あるいは電力回復の時間を含んでも良い。
【図面の簡単な説明】
【０００９】
【図１】可能な一実施形態に従って、ルート更新処理が実現されるネットワークを概略的に示すブロック図である。
【図２】可能な一実施形態に従って、リブート情報を更新し且つリブート情報を他のノードに通知する処理を概略的に示すフローチャートである。
【図３】可能な一実施形態に従って、別のノードからのルーティング情報が所定のノードのルーティング情報を更新するために使用されてもよいかを判定するためにリブート情報を使用する処理を概略的に示すフローチャートである。
【図４】可能な一実施形態に従って、複数のノードを有する通信ネットワークを概略的に示すブロック図である。
【図５】可能な一実施形態に従って、リブートするノードにより情報更新のためのノードを発見する処理を概略的に示すフローチャートである。
【図６Ａ】停電を経験したユーティリティ通信ネットワーク及び回復したノードの通知を提供するための種々の実施形態を示す図である。
【図６Ｂ】停電を経験したユーティリティ通信ネットワーク及び回復したノードの通知を提供するための種々の実施形態を示す図である。
【図６Ｃ】停電を経験したユーティリティ通信ネットワーク及び回復したノードの通知を提供するための種々の実施形態を示す図である。
【図６Ｄ】停電を経験したユーティリティ通信ネットワーク及び回復したノードの通知を提供するための種々の実施形態を示す図である。
【発明を実施するための形態】
【００１０】
本発明の上述の態様及び付随する利点の多くは、添付の図面と共に以下の詳細な説明を参照することにより更に容易に且つ更によく理解されるであろう。
【００１１】
図１は、複数のノード１０１を有する通信ネットワーク１００を概略的に示すブロック図である。ノード１０１は、処理ユニット、メモリ（例えば、不揮発性メモリ）及びネットワークインタフェースを含んでも良い。通信ネットワークが無線通信ネットワークであれば、ノードは、ネットワークにおける他のノードと通信するため、１つ以上の無線機（又は無線トランシーバ）を含んでいても良い。１つ以上のノードは、別のネットワーク１０３へのアクセスポイント（又はゲートウェイ）１０２として動作しても良い。１つ以上の電子演算装置１０５は、通信ネットワーク１０３に接続されても良い。電子演算装置の例としては、サーバ、パーソナルコンピュータ、ハンドヘルドデバイス、モバイル演算装置、移動電話等が含まれるが、これらに限定されない。１つ以上のノードは、ノード間や、１つ以上のノード１０１とゲートウェイ１０２との間の少なくともいずれかでパケットを中継する中継ノード１０４であっても良い。
【００１２】
アクセスポイントノードを有する通信ネットワークにおいて、１つのノードは、アクセスポイントノードにより近接するという観点から別のノードの「上流」であると考えられても良い（より近接するということは、ホップ数、地理的な近さ、リンクコスト、リンク信頼性、それらの組合せ、あるいは追加の要素又は一覧表示した要素以外の要素と組み合わせた追加の要素を参照しても良い）。「下流」ノードは、上流ノードからルーティング更新データを受信することが好ましい、且つ／又は選択しても良い。
【００１３】
通信ネットワーク１００の動作中、ノードは、多くの理由によりリブート（自発的又は非自発的に）しても良い。それらの理由には、電力損失、動作保守、サービス自動切断、ファームウェアアップグレード後の通常のノードリフレッシュ又は他の理由が含まれるが、これらに限定されない。リブートするノードがリブート後に再開した時、リブートするノードは、「ダウン」していた間にルーティング情報更新データを受信できなかった可能性があるため、他のノードからルーティング情報を受信するのが好ましい。通信ネットワークの他のノードもダウンし、最近リブートした可能性があるため、リブートするノードは、最近リブートしていないノード又は少なくともリブートするノードより前にリブートしており且つより最新のルーティング情報を有している可能性がより高いノードからルーティング更新データ又は他の更新データを受信するのが好ましい。
【００１４】
図２は、リブート情報を更新し且つ通信ネットワークの他のノードにリブート情報を提供する処理を概略的に示すフローチャートである。ステップ２０１において、ノードはリブートする。リブートに応答して、ステップ２０２において、ノードは自身のリブート情報を更新する。ノードは、リブート中又はリブート後にリブート情報を更新しても良い。リブート情報がリブートカウンタであれば、更新はリブートカウンタをインクリメントすることであっても良い。リブートカウンタは、１インクリメントされても良いし、また、リブートカウンタに対する他の演算により変更されても良い。リブート情報がリブートタイムスタンプであれば、リブートタイムスタンプは、リブートを反映するように変更される。リブート情報が最近のリブート値であれば、最近のリブート値は、予め決められた期間内のリブートを示す値を示すように設定されても良い。他のリブート情報は、隣接ノードにおける最新のファームウェアアップグレード、リンク及びパス品質の変更、並びに隣接ノード間の情報成功統計のリストを含んでいても良いが、これらに限定されない。ステップ２０３において、リブート情報が格納される。本発明の好適な一実施形態において、リブート情報は、ノードの不揮発性メモリに格納される。不揮発性メモリの種類の一例としては、フラッシュメモリが挙げられる。他の実施形態は、ノードの揮発性メモリ、あるいはノードがアクセスできるデバイス又はコンピュータの揮発性メモリ又は不揮発性メモリにリブート情報を格納しても良い。
【００１５】
ステップ２０４において、リブートしたノード等のノードは、通信ネットワークの別のノードから情報に対する要求を受信する。情報に対する要求は、リブート情報に対する特定の要求であっても良く、あるいは、要求は、リンク又はルーティング情報に対する要求等の他の情報に対するものであっても良い。ステップ２０５において、ノードはルーティング情報に対する要求に応答する。要求がルーティング情報又は他の情報に対するものである場合、リブート情報は応答に含まれるのが好ましい。更に、ノードにより受信されたルート情報に対する要求は、通信ネットワークにおける他のノードに対応するリブート情報を含んでも良い。別の一実施形態において、リブート情報は、ルーティング情報とは別個にやり取りされる。他のノードに対応するリブート情報が情報に対する要求において受信される場合、ノードは受信したリブート情報を格納しても良い。リブート情報は、フラッシュメモリ等のノードの不揮発性メモリに格納されるのが好ましい。他の実施形態では、ノードの揮発性メモリ、あるいはノードがアクセスできるデバイス又はコンピュータの揮発性メモリ又は不揮発性メモリに受信したリブート情報を格納しても良い。
【００１６】
要求元ノードは、少なくとも１つの他のノードからリブート情報を受信する。要求元ノードは、受信したリブート情報を格納しても良い。リブート情報は、ノードに関連付けられた記憶装置又はメモリに格納されても良い。好適な一実施形態において、リブート情報は、フラッシュメモリ等の受信ノードの不揮発性メモリに格納される。他の実施形態では、受信ノードの揮発性メモリ、あるいは受信ノードがアクセスできるデバイス又はコンピュータの揮発性メモリ又は不揮発性メモリに受信したリブート情報を格納しても良い。
【００１７】
図３は、別のノードからのルーティング情報が、所定のノードのルーティング情報の更新に関して使用されるか否かを判定するため、リブート情報を使用する処理３００を概略的に示すフローチャートである。ステップ３０１において、第１のノード（又はリブートするノード）がリブートする。リブート中又はリブート後、第１のノードは、ルーティング更新処理を開始し、ステップ３０２において、第１のノードは、少なくとも１つの隣接ノードにルーティング情報更新メッセージを送出する。好適な一実施形態において、第１のノードは、既に認識しているノードにルーティング更新メッセージを送出する。第１のノードが認識しているノードはリストに含まれても良い。このリストは、揮発性メモリ又は不揮発性メモリのその場所又はセキュリティ上安全であり且つ／又は確実にアクセスできる異なる場所に格納されても良い。これらのノードは隣接ノードであるのが好ましい。あるいは、第１のノードが通信ネットワークの他のノードを認識していない場合に行なわれるように（ノードが最初にネットワークに参加するために行なわれるように、あるいは既知のノードのリストが失われたか又は削除された場合に行なわれるように、あるいは既知のノードのリストが取得できないか又は信頼できないと考えられる場合に行なわれるように）、第１のノードはノードを発見するために発見処理を開始しても良い。ルーティング更新メッセージは、第１のノードのリブート情報を含んでも良く、リブート情報更新に対する要求を含んでも良い。発見されたノードのリストは、ステップ３０２で送出されたルーティング更新メッセージに対して使用されても良い。ステップ３０３において、第１のノードは、ルーティング更新情報を受信する。好適な一実施形態において、ルーティング更新情報応答はリブート情報を含む。別の実施形態において、リブート情報は個別のメッセージで受信されても良い。このメッセージは、ルーティング更新要求に応答して受信されても良いし、リブート情報要求に応答して受信されても良いし、他の情報に対する要求に応答して受信されても良いし、あるいはリブートするノードからの要求なしで自動的に受信されても良い。ステップ３０４において、第１のノードは、自身が保持する他のノードに関するリブート情報を取得しても良い。上述したように、リブート情報は、メモリ、あるいは別のアクセス可能なデバイス又は記憶装置に格納されても良く、ステップ３０４において、第１のノードはその場所から他のノードに関する格納されたリブート情報を取得する。好適な実施形態において、第１のノードが少なくとも１つのノードに対する格納されたリブート情報及び受信したリブート情報の双方にアクセスできるように、取得したリブート情報は、受信したリブート情報と関連付けられた少なくとも１つのノードに対応しても良い。
【００１８】
ステップ３０５において、第１のノードは、例えば、少なくとも１つのノードに対する格納されたリブート情報と受信したリブート情報とを比較することにより検査し、関連する１つ又は複数のノードが最近リブートされたか否かを判定しても良い。特に、第１のノードは、格納されたリブート情報及び受信したリブート情報に対応する所定のノードが第１のノードより最新のルーティング情報を有するかに関して判定しても良い。所定のノードが対応する格納されたリブート情報を受信してからリブートしていない場合、あるいは所定のノードが第１のノードのリブートの前の予め決められた期間内にリブートしていない場合、第１のノードは、自身のルーティング情報を更新するために所定のノードから入手可能なリブート情報を使用することを判定しても良い。上述した比較は、入手可能なリブート情報の種類によって異なっても良い。例えば、リブート情報がリブートカウンタであれば、比較は、格納されたリブートカウンタが受信したリブートカウンタと等しいかという比較であっても良い。格納されたリブートカウンタが受信したリブートカウンタと等しい場合、所定のノードが格納されたリブートカウンタを受信してからリブートしていないことや、第１のノードが所定のノードからのルーティング情報を使用して自身のルーティング情報を更新することが判定されても良い。ステップ３０５において、比較において少なくとも１つのノードが第１のノードのルーティング情報より最新のルーティング情報を有することが判定された場合、ステップ３０６において、第１のノードは、第１のノードより最新のルーティング情報を有すると判定された少なくとも１つのノードからのルーティング情報を使用してルーティング情報を更新する。ルーティング情報がまだ受信されていない場合、第１のノードは、第１のノードを更新する時に使用されるルーティング情報に対する要求を行なっても良い。
【００１９】
ステップ３０５で検査されたノードがいずれも第１のノードのルーティング情報より最新のルーティング情報を有さないと判定された場合、ステップ３０７において、第１のノードは、比較されてもよい追加のノードが存在するかを判定しても良い。比較されてもよい追加のノードがない場合、処理はステップ３０８で終了しても良い。ステップ３０７において、比較される追加のノードが存在すると第１のノードが判定した場合、ステップ３０２に戻り、他のノードから追加の情報を取得し、ステップ３０２からの比較処理が行なわれる。第１のノードがリブート情報を保持する全てのノードを比較すると、第１のノードはステップ３０２に進み、他のノードに対する格納されたリブート情報を要求し且つ要求した格納されたリブート情報に対応するノードからのリブート情報を要求する。あるいは、ステップ３０７において、最近のリブートに関して検査される追加のノードが存在すると第１のノードが判定し且つ第１のノードが検査に必要な情報を有する場合、第１のノードはステップ３０４、３０５又は他のいずれかのステップに適宜戻っても良い。
【００２０】
ステップ３０５において、第１のノードは、第１のノードのルーティング情報より最新のルーティング情報を有するノードを見つけられるまで第１のノードの既知の他のノードの格納されたリブート情報と受信したリブート情報とを比較しても良い。これは、他のノードのリブート情報に対する他のリブート情報要求を送出することを含んでも良い。最近リブートされていないノードが見つけられた場合、第１のノードはステップ３０６に進み、自身のルーティング情報を更新する。
【００２１】
上記処理は、種々の実施形態において変更を伴って又は変更なしで全体的に又は部分的に組み合わされても良い。例示する目的で、複数の例示的な実施形態を以下に提供する。
【００２２】
上記実施形態は、ルーティング情報の更新に関するものであったが、別の実施形態は、ルーティング情報に加えて他の情報を更新しても良く、あるいはルーティング情報を更新せずに他の情報を更新しても良い。
【００２３】
例１  複数のサブネットワークを含み且つ５，０００個のノードを含む無線ＦＨＳＳ（周波数ホッピング方式：Frequency Hopping Spread Spectrum）通信ネットワークは、５，０００個のユーティリティメータとの通信を提供するため、ＩＰを用いたプロトコル（例えば、ＩＰｖ４又はＩＰｖ６）を使用する。ユーティリティメータは、ユーティリティにより提供されたコモディティの消費量を測定する（本例においては、測定されたコモディティは電気であるが、他の実施形態は水道、ガス又は他のコモディティをそれぞれ単独で又は組み合わせて測定できる）。ユーティリティノード（メータを読み且つ／又は制御することを可能にするためにメータを含んでも良く又はメータに結合しても良い）は、ノードが複数のアクセスポイントノードを介して１つ以上のバック・オフィス・システムと通信できるようにするためのルーティング情報を含む。ユーティリティネットワークの殆どのユーティリティノードは、アクセスポイントノードと直接通信できない。従って、バック・オフィス・システムとの通信の一部として所定のノードに又は所定のノードから送出されたパケットは、一般に、最初に別のユーティリティノードに送出され、その別のユーティリティノードは、所定のノードと１つ以上のアクセスポイントノードとの間でパケットを中継する。
【００２４】
ユーティリティノードは、リブートカウンタを保持し且つやり取りする。リブートカウンタは、ユーティリティノードが行なったリブートの回数を表す整数値である。通信ネットワークのユーティリティノードに対するリブートカウンタは、ユーティリティノードのフラッシュメモリに格納される。例えば、ＵＮ−４７１で指定された所定のユーティリティノードが３回リブートした場合、そのユーティリティノードは、リブートカウンタ（ＲｅｂｏｏｔＣｏｕｎｔｅｒ＝３）を保持しても良い。ユーティリティノードＵＮ−４７１は、リブートすると、自身のリブートカウンタを１インクリメントするため、ＲｅｂｏｏｔＣｏｕｎｔｅｒ＝４となる。ユーティリティノードＵＮ−４７１は、自身のリブートカウンタを隣接ノード（本例においては、そのユーティリティノードが認識しており且つ通信するための情報を保持するノード）と共有する。リブートカウンタがインクリメントされた直後に共有され、更に定期的に共有されてもよい（例えば、リンク及び他の情報を更新した時、あるいはパケットをやり取りした時）。
【００２５】
ユーティリティノードＵＮ−４７１は、リブートを実行した場合、最初に格納された隣接ノード情報に基づいて１つ以上の隣接ノードとの接続を確立する。１つ以上の隣接ノードとの接続を確立した後、ユーティリティノードＵＮ−４７１は、リブートカウンタを提供するために少なくとも１つの隣接ノードの要求を行なう。ユーティリティノードＵＮ−４６４がユーティリティノードＵＮ−４７１と通信中の隣接ノードであり且つユーティリティノードＵＮ−４７１がユーティリティノードＵＮ−４６４のリブートカウンタを要求した場合、ユーティリティノードＵＮ−４６４は、ＲｅｂｏｏｔＣｏｕｎｔｅｒｒｅｃｅｉｖｅｄ＝６である自身のリブートカウンタを与えることにより応答しても良い。ユーティリティノードＵＮ−４７１は、ＲｅｂｏｔＣｏｕｎｔｅｒｓｔｏｒｅｄ＝５であるＵＮ−４６４に対する格納されたリブートカウンタを取得する。ユーティリティノードＵＮ−４７１は、ＵＮ−４６４に対する格納されたリブートカウンタを受信したリブートカウンタと比較し、格納されたリブートカウンタが受信したリブートカウンタと等しくないことに基づいて、ＵＮ−４６４に対するリブートカウンタが最後に更新されてからＵＮ−４６４がリブートしたと判断する。従って、ＵＮ−４６４のルーティング情報は、ＵＮ−４７１のルーティング情報を更新するのに使用されないと判定される。ＵＮ−４７１は、格納されたリブートカウンタの値を超えてリブートカウンタをインクリメントしていないノードを見つけようとする。ＵＮ−４７１は、自身が対応する格納されたリブートカウンタを有する受信した他のノードのリブートカウンタを比較しても良い。更にＵＮ−４７１は、他のユーティリティノードからリブートカウンタを要求しても良い。ユーティリティノードＵＮ−４７１は、他の５つのノードＵＮ−４６９、ＵＮ−４７２、ＵＮ−４７３、ＵＮ−４７８及びＵＮ−４８５に対するリブートカウンタを受信し、それらのノードに対して格納されたリブートカウンタを有する。格納されたリブートカウンタと受信したリブートカウンタとを比較することにより、ＵＮ−４７１は、ＵＮ−４８５及びＵＮ−４７３がリブートカウンタをインクリメントしていないことを判定する（ＵＮ−４８５に対する格納されたリブートカウンタ及び受信したリブートカウンタの双方が２であり、ＵＮ−４７３に対する格納されたリブートカウンタ及びインクリメントしたリブートカウンタの双方が１１である）。ＵＮ−４８５がＵＮ−４７１の上流であるため（すなわち、ＵＮ−４７１及びＵＮ−４８５の双方が同一のサブネットにあり、ＵＮ−４８５のサブネットのアクセスポイントまでのホップ数がより少なく、ＵＮ−４７１及びＵＮ−４８５からのパケットが種々のルートに従ってＵＮ−４８５を効率的に通過できるため）、ＵＮ−４７１は、ＵＮ−４７１のルーティング情報を更新するためにＵＮ−４８５からの情報を使用する。従って、ＵＮ−４７１は、ＵＮ−４８５からのルーティング更新情報を要求し、ＵＮ−４７１のルーティング情報を更新するために受信したルート更新情報を使用する。
【００２６】
例２  センサの無線メッシュネットワーク（無線センサネットワーク）は、８００個のセンサノードを有する。メッシュネットワークは、３つの別個のサブネットを有し、いくつかのセンサノードは、２つ以上のサブネットにある。センサノードは、ノードがリブートした最新の日時を示すリブートタイムスタンプを保持する。ＳＮ−２０６で指定された無線メッシュネットワーク内の１つのセンサノードは、２００７年８月２３日午前４時１３分に最後にリブートしたため、リブートタイムスタンプはＲＢＴＳ＝０８２３０７０４１３である。ＳＮ−２０６は、他のノードがＳＮ−２０６からのリンク又はルーティング情報を要求した時に自身のタイムスタンプを他のノードと共有する。ＳＮ−２０６は、ＳＵＢ−１及びＳＵＢ−２で指定された無線メッシュネットワークの２つのサブネット上にある。ＳＮ−２０６は、リンク情報を保持するＳＵＢ−１上に１０個の隣接ノードを有し、それら１０個の全ての隣接ノードに対するリブートタイムスタンプを格納する。２００７年９月１７日午後３時４４分にＳＮ−２０６はリブートした。リブート処理中、ＳＮ−２０６はリブートタイムスタンプを更新し、現在はＲＢＴＳ＝０９１７０７１５４４である。リブート後、ＳＮ−２０６は、隣接センサノードとの接続を確立し、全ての隣接ノードからのタイムスタンプ情報を要求する。本実施形態の例において、ＳＮ−２０６は、リブート情報を要求する前に、直接接続された隣接ノードが安定するまで待機する。ＳＵＢ−１の１０個の隣接ノードのうち、８つの隣接ノードが応答できる。ＳＮ−２０６は、応答した８つのノードに対する格納されたタイムスタンプと受信したタイムスタンプとを比較する。ＳＵＢ−１のＳＮ−２０６に対する８個の隣接ノードのうち、２つの隣接ノードのみがＳＮ−２０６のメモリに格納されたタイムスタンプをＳＮ−２０６が受信してからリブートした。ＳＮ−２０６は、ルーティング更新情報を要求するために、最近リブートしていないと判定された６つの隣接ノードのうち１つを選択する。本実施形態の例において、ＳＮ−２０６は、サブネットＳＵＢ−１においてＳＮ−２０６の「上流」である最小のリンクコストを有する隣接ノードを選択し、そのノードからのルーティング情報を要求し、受信するルーティング情報を使用してサブネットワークＳＵＢ−１に対するＳＮ−２０６のルーティング情報を更新する。同様に、ＳＮ−２０６はサブネットＳＵＢ−２上の隣接ノードとの接続を更に確立する。ＳＮ−２０６はＳＵＢ−２に５つの隣接ノードを有し、５つの全ての隣接ノードからのリブートタイムスタンプ情報を要求する。５つの全ての隣接ノードは、現在のリブートタイムスタンプをＳＮ−２０６に提供することにより応答する。ＳＮ−２０６は、格納されたリブートタイムスタンプと受信したリブートタイムスタンプとを比較することにより、応答する隣接ノードのいずれも最近リブートしていないと判定する。従って、ＳＮ−２０６は、サブネットＳＵＢ−２においてＳＮ−２０６の「上流」である最小のリンクコストを有する隣接ノードを選択し、そのノードからのルーティング情報を要求し、受信するルーティング情報を使用してＳＵＢ−２に対するＳＮ−２０６のルー���ィング情報を更新する。
【００２７】
例３  サブネットを有さない単一のネットワークに配置された１，２００個の通信ノードを含む無線メッシュネットワーク。通信ノードは、予め決められた地理的領域に配置される。無線メッシュ通信ネットワークにおいて、２つのアクセスポイントノード及び複数の中継ノードが存在する。通信ノードは、通信ノードが予め設定された期間内にリブートしたかを示す最新リブート値であるリブート情報を使用してリブートを常時監視する。通信ノードＣＮ−７８３は、１時間を超える期間にわたりリブートされていないため、最新リブート値はゼロに設定される（ＲＲＣＮ−７８３＝０）。２００７年９月１９日午前９時２１分にＣＮ−７８３がリブートした。リブート中、ＣＮ−７８３は、最近リブート処理が行なわれたことを示すように最新リブート値を１に設定する（ＲＲＣＮ−７８３＝１）。ＣＮ−７８３は、直接アクセスできる隣接ノードからのリブート情報を要求する。ＣＮ−７８３は、７つの直接アクセスできる隣接ノードを有し、そのうち５つが過去１時間以内のリブートを示す最新リブート値１を返す。２つの直接アクセスできるノードＣＮ−７７３及びＣＮ−７７９は、過去１時間以内にリブートしていないことを示す最新リブート値０を返す。ＣＮ−７８３は、返された最新リブート値に基づいて、ルーティング更新データを受信するために最近リブートしていない直接アクセスできるノードを選択する。ＣＮ−７８３は、リンクコスト要素に基づいて、ルーティング情報を更新するためにＣＮ−７７９からルーティング情報を要求し且つ受信することを選択する。リブートから１時間後、別のリブートが行なわれていない場合、ＣＮ−７８３は、所定の「最近」の時間フレーム内でリブートされていないことを示すように最新リブート値をゼロに戻す。同様に、無線メッシュネットワークの他の通信ノードは、設定に従って最新リブートカウンタを更新する。
【００２８】
図４は、複数のノード４０１を有する通信ネットワーク４００を概略的に示すブロック図である。ノード４０１は、２つのサブネットワーク４００−ａ及び４００−ｂに配置される。２つ以上のネットワークのメンバであるノードは、ネットワークオーバラップノード（ＮＯＮ）４０５と呼ばれても良いし、また、複数のネットワークに参加するノードと呼ばれても良い。ネットワークオーバラップノードの一例は、所定のネットワーク内の複数のサブネットのメンバであるノードである。サブネットは、地理的領域を含むがそれに限定されない多くの可能な基準に従って編成されても良い。サブネットが地理的に配置される以下の例において説明するように、ネットワークオーバラップノードは、２つ以上のサブネットがオーバラップする領域に存在するため、２つ以上のサブネットにおいて通信できても良い。１つ以上のノードは、別のネットワーク４０３に対するアクセスポイント（又はゲートウェイ）４０２として動作しても良い。１つ以上の電子演算装置４０７は、通信ネットワーク４０３に接続されても良い。電子演算装置の例には、サーバ、パーソナルコンピュータ、ハンドヘルドデバイス、移動演算装置、移動電話等が含まれるが、それらに限定されない。１つ以上のノードは、ノード間及び／又は１つ以上のノード４０１とゲートウェイ４０２との間でパケットを中継する中継ノード４０４であっても良い。中継ノードは、更に２つのサブネットの一部であっても良く、ネットワークオーバラップ中継ノード（ＮＯＮ中継器）４０６と呼ばれても良い。
【００２９】
上述のように、アクセスポイントノードを有する通信ネットワークにおいて、１つのノードは、アクセスポイントノードにより近接するという観点から別のノードの「上流」であると考えられても良い（より近接するということは、ホップ数、地理的な近さ、リンクコスト、リンク信頼性、それらの組合せ又は追加の要素を参照してもよい）。「下流」ノードは、上流ノードからルーティング更新データを受信することが好ましい、且つ／又は選択しても良い。
【００３０】
通信ネットワーク４００の動作中、ノード又はネットワークオーバラップノードは、多くの理由によりリブート（自発的又は非自発的に）しても良い。それらの理由には、電力損失、動作保守、サービス自動切断、ファームウェアアップグレード後の通常のノードリフレッシュ又は他の理由が含まれるが、これらに限定されない。リブートするノードがリブート後に再開した時、リブートするノードは、「ダウン」していた間にルーティング情報更新データを受信できなかった可能性があるため、他のノードからルーティング情報を受信するのが好ましい。通信ネットワークの他のノードもダウンし、最近リブートした可能性があるため、リブートするノードは、最近リブートしていないノード又は少なくともリブートするノードより前にリブートしており且つより最新のルーティング情報を有している可能性がより高いノードからルーティング更新データ又は他の更新データを受信するのが好ましい。更に、ネットワークオーバラップノードがより最新のルーティング又は他の情報を有する可能性があるため、あるいはネットワークアクセスノードが通信できる別のネットワークを介して所定のノード又はネットワークへのアクセス権をネットワークオーバラップノードが提供してもよいため、リブートするノードは、ネットワークオーバラップノードからルーティング更新情報を受信するのが好ましい。
【００３１】
図５は、リブートするノードが、情報更新に関するノードを発見する処理５００を概略的に示すフローチャートである。ステップ５０１において、第１のノード（又はリブートするノード）はリブートする。リブート中又はリブート後、第１のノードはルーティング更新処理を開始しても良く、ステップ５０２において、第１のノードは少なくとも１つの隣接ノードにルーティング情報更新メッセージを送出する。好適な一実施形態において、第１のノードは既に認識しているノードにルーティング更新メッセージを送出する。第１のノードが認識しているノードはリストに含まれても良い。このリストは、揮発性メモリ又は不揮発性メモリのその場所又はセキュリティ上安全であり且つ／又は確実にアクセスできる異なる場所に格納されても良い。これらのノードは隣接ノードであるのが好ましい。あるいは、第１のノードが通信ネットワークの他のノードを認識していない場合に行なわれるように（ノードが最初にネットワークに参加するために行なわれるように、あるいは既知のノードのリストが失われたか又は削除された場合に行なわれるように、あるいは既知のノードのリストが取得できないか又は信頼できないと考えられる場合に行なわれるように）、第１のノードはノードを発見するために発見処理を開始しても良い。ルーティング更新データは、第１のノードのリブート情報を含んでも良いし、リブート情報更新に対する要求を含んでも良い。発見されたノードのリストは、ステップ５０２で送出されたルーティング更新メッセージに対して使用されても良い。ステップ５０３において、第１のノードはルーティング更新情報を受信する。好適な一実施形態において、ルーティング更新情報応答はリブート情報を含む。別の実施形態において、リブート情報は個別のメッセージで受信されても良い。このメッセージは、ルーティング更新要求に応答して受信されても良く、リブート情報要求に応答して受信されても良く、他の情報に対する要求に応答して受信されても良く、あるいはリブートするノードからの要求なしで自動的に受信されても良い。ステップ５０４において、第１のノードは、自身が保持する他のノードに関するリブート情報を取得しても良い。上述したように、リブート情報は、メモリ、あるいは別のアクセス可能なデバイス又は記憶装置に格納されても良く、ステップ５０４において、第１のノードはその場所から他のノードに関する格納されたリブート情報を取得する。好適な実施形態において、第１のノードが少なくとも１つのノードに対する格納されたリブート情報及び受信したリブート情報の双方にアクセスできるように、取得したリブート情報は、受信したリブート情報と関連付けられた少なくとも１つのノードに対応しても良い。
【００３２】
ステップ５０５において、第１のノードは、例えば、少なくとも１つのノードに対する格納されたリブート情報と受信したリブート情報とを比較することにより検査し、関連する１つ又は複数のノードが最近リブートしたか否かを判定しても良い。特に、第１のノードは、格納されたリブート情報及び受信したリブート情報に対応する所定のノードが第１のノードより最新のルーティング情報を有するか否かに関して判定しても良い。所定のノードが対応する格納されたリブート情報を受信してからリブートされていない場合、あるいは所定のノードが第１のノードのリブートの前の予め決められた期間内にリブートされていない場合、第１のノードは、自身のルーティング情報を更新するために所定のノードから入手可能なリブート情報を使用することを判定しても良い。上述した比較は、入手可能なリブート情報の種類によって異なっても良い。例えば、リブート情報がリブートカウンタであれば、比較は、格納されたリブートカウンタが受信したリブートカウンタと等しいかという比較であっても良い。格納されたリブートカウンタが受信したリブートカウンタと等しい場合、所定のノードが格納されたリブートカウンタを受信してからリブートされていないこと及び第１のノードが所定のノードからのルーティング情報を使用して自身のルーティング情報を更新することが判定されても良い。ステップ５０５において、比較において少なくとも１つのノードが第１のノードのルーティング情報より最新のルーティング情報を有することが判定された場合、ステップ５０６において、第１のノードは、第１のノードより最新のルーティング情報を有すると判定された少なくとも１つのノードからのルーティング情報を使用してルーティング情報を更新する。ルーティング情報がまだ受信されていない場合、第１のノードは、第１のノードを更新する時に使用されるルーティング情報に対する要求を行なっても良い。
【００３３】
ステップ５０５で検査されたノードがいずれも第１のノードのルーティング情報より最新のルーティング情報を有さないと判定された場合、ステップ５０７において、第１のノードは、比較されてもよいネットワークオーバラップノードが存在するかを判定しても良い。検査するか又は更新情報を取得するネットワークオーバラップノードが存在するかの判定は、存在するか又は種々の場所から取得される種々の情報に基づいても良い。例えば、第１のノードは、ノードのメモリに格納されてもよいネットワークオーバラップノードのリストを保持しても良い。ノードは、どのノードも第２の（又は更に多くの）ネットワークで通信できるかを判定するためにノードに関して有する情報を比較しても良い。別の実施形態は、ネットワークオーバラップノードを識別するか又はネットワークオーバラップノード情報要求に対する応答からネットワークオーバラップノードを判定することを可能にする情報を要求するために第１のノードにメッセージを送出させても良い。
【００３４】
ネットワークオーバラップノードが存在する場合、第１のノードは、ステップ５０２に戻り、ネットワークオーバラップノードに関する情報を要求しても良く、あるいは別のステップに適宜戻り、ネットワークオーバラップノードが最近リブートしたかを判定するためにネットワークオーバラップノードを検査する。本発明の好適な実施形態において、第１のノードは、ネットワークオーバラップノードが最近リブートした場合は、ルーティング情報更新のためにそのネットワークオーバラップノードを選択しない。しかし、別の実施形態は、他のあらゆるネットワークオーバラップノードを含む最近リブートしていない別のノードを見つけられない場合は、最近リブートしたネットワークオーバラップノードからリブート情報を受信するように選択しても良い。
【００３５】
好適な一実施形態において、ネットワークオーバラップノードが見つけられない場合、あるいは最近リブートしていないネットワークオーバラップノードが見つけられない場合、第１のノードは、ステップ５０８に進み、別のパワーノードが存在するかを判定しても良い。別のパワーノードは、別の電源を有するどのようなノードであっても良い。例えば、第１のノードが第１の電力ネットワーク上にある場合、リブートは、第１の電力ネットワークにおける電力損失の結果として起こった可能性がある。第１の電力ネットワークが停電又は電力損失を経験した場合、別の電源を使用するノード、すなわち、第１の電力ネットワークとは異なる電源を使用するノードは、電力損失を経験していないであろう。別の電源の例は、別個の電気グリッド、「オフグリッド」電源（バックアップ発生器により発生するような、風、太陽等の別の電源）、バッテリ又はバックアップバッテリ（第１の電源等の電源からの電力で正常に動作し且つ１つ又は複数の主電源が損失した場合に給電するバッテリを更に有するバックアップバッテリノード）であっても良い。
【００３６】
更新情報を検査又は要求する別のパワーノードが存在するかの判定は、存在するか又は種々の場所から取得されてもよい種々の情報に基づいて行なわれても良い。例えば、第１のノードは、第１のノードのメモリに格納されてもよい別のパワーノードのリストを保持しても良い。第１のノードは、自身が有するノードに関する情報を比較し、いずれかのノードが別のパワーノードであるかを判定しても良い。別の実施形態は、別のパワーノードを識別するか又は別のパワーノード情報要求に対する応答から別のパワーノードを判定することを可能にする情報を要求するために第１のノードにメッセージを送出させても良い。ステップ５０８において、別のパワーノードが存在すると第１のノードが判定した場合、第１のノードは、ステップ５０２に戻り、別のパワーノードに関する情報を要求しても良く、あるいは別のステップに適宜戻り、別のパワーノードのいずれかが最近リブートしたかを判定するためにそれらの別のパワーノードを検査しても良い。好適な一実施形態において、別のパワーノードが最近リブートした場合、第１のノードは、ルーティング情報更新のためにその別のパワーノードを選択しない。しかし、別の実施形態は、他のあらゆるパワーノードを含む最近リブートしていない別のノードを見つけられない場合は、最近リブートした別のパワーノードからリブート情報を受信するように選択しても良い。
【００３７】
追加のノードを検査できない場合、処理はステップ５０９で終了する。ステップ５０７又は５０８において、比較する追加のノードが存在すると第１のノードが判定した場合、ステップ５０２に戻り、それらの他のノードから追加の情報を取得し、ステップ５０２からの比較処理が行なわれる。第１のノードがリブート情報を保持する全てのノードを比較すると、第１のノードはステップ５０２に進み、他のノードに対する格納されたリブート情報を要求し且つルーティング更新を要求する。あるいは、ステップ５０７又は５０８において、最近のリブートに関して検査する追加のノードが存在すると第１のノードが判定し且つ第１のノードが検査に必要な情報を有する場合、第１のノードはステップ５０４、５０５又は他のいずれかのステップに適宜戻っても良い。
【００３８】
ステップ５０５において、第１のノードは、第１のノードのルーティング情報より最新のルーティング情報を有するノードを見つけられるまで、第１のノードが認識している他のノードの格納されたリブート情報と受信したリブート情報とを比較しても良い。これは、他のノードのリブート情報に対する他のリブート情報要求を送出することを含んでも良い。最近リブートしていないノードが見つけられた場合、第１のノードはステップ５０６に進み、自身のルーティング情報を更新する。
【００３９】
図５に示した処理は、ネットワークオーバラップノード又は別のパワーノードを見つけるために第１のノードにノードを検査させるが、他の実施形態は、別のパワーノード及びネットワークオーバラップノードの双方であるノードを見つけようとしても良い。図５に示した処理は、別のパワーノードを見つけるためにノードを検査する前に、ネットワークオーバラップノードを見つけるために第１のノードにノードを検査させるが、他の実施形態は、ネットワークオーバラップノードを見つけようとする前に別のパワーノードを見つけようとしても良く、あるいはネットワークオーバラップノード及び別のパワーノードを同時に見つけようとしても良く、あるいは別のパワーノード及びネットワークオーバラップノードの双方を見つけようとせずにネットワークオーバラップノード又は別のパワーノードのいずれかを見つけようとしても良い。図５に示した処理は、ノードが別のパワーノードであるか又はノードがネットワークオーバラップノードであるかを判定した後に第１のノードに最近のリブートに関してノードを比較させるが、別の実施形態は、見つけたノードがネットワークオーバラップノードであるか又は別のパワーノードであること（あるいは、ネットワークオーバラップノード及び別のパワーノードの双方であること）を判定した直後にルーティング更新情報を受信及び／又は使用し始めても良い。図５に示した処理は、ネットワークオーバラップノード又は別のパワーノードのいずれか（あるいは、ネットワークオーバラップノード及び別のパワーノードの双方）を見つけるためにノードを検査する前に、ノードが最近リブートしたかを判定するために第１のノードにノードを検査させるが、他の実施形態は、別のパワーノードでないか又はネットワークオーバラップノードでない（あるいは、パワーノードでもネットワークオーバラップノードでもない）ノードを見つけようとする前に別のパワーノード又はネットワークオーバラップノードのいずれか（あるいは、パワーノード及びネットワークオーバラップノードの双方）を見つけようとしても良い。
【００４０】
上記処理は、種々の実施形態において変更を伴って又は変更なしで全体的に又は部分的に組み合わされても良い。例示する目的で、複数の例示的な実施形態を以下に提供する。
【００４１】
例４  ユーティリティメータに結合される６，０００個のユーティリティノードを含む無線メッシュネットワーク。無線ユーティリティノードは、ＵＮ−ＳＵＢ１及びＵＮ−ＳＵＢ２と呼ばれる２つのサブネットに配置される。ＵＮ−ＳＵＢ１及びＵＮ−ＳＵＢ２の各々は、単一のアクセスポイントノードを有する。Ｍ２３８１で指定されたネットワーク内のユーティリティノードは、ＵＮ−ＳＵＢ１に常駐する。ユーティリティノードＭ２３８１は、２６個の直接アクセス可能な隣接ノードを有する。ネットワーク内のＭ２３８１及び他のユーティリティノードは、自身の不揮発性メモリに隣接ノードリブート情報を保持する。特に、本実施形態のユーティリティネットワークノードは、リブートカウンタを使用し、それらのユーティリティネットワークノードは、ルーティングネットワーク保守のメッセージング中に隣接ノードとリブートカウンタをやり取りする。リブート後、Ｍ２３８１は、直接リンクする隣接ノードを含む他のノードからのリブートカウンタを要求する。隣接ノードは、それぞれのリブートカウンタを使用して応答する。ユーティリティノードＭ２３８１は、受信したリブートカウンタを対応して格納されたリブートカウンタと比較し、応答する全てのノードが最近リブートしたことを判定する。ユーティリティノードＭ２３８１は、追加のノードのリブート情報を要求する。特に、Ｍ２３８１は上流ノードからのリブート情報を要求する。応答を受信し、受信したリブートカウンタと格納されたリブートカウンタとを比較した後、最近リブートしていないノードは発見されない。ユーティリティノードＭ２３８１は、サブネットＵＮ−ＳＵＢ１が全体的に停電したと判断する。従って、ユーティリティノードＭ２３８１は、ルーティング更新情報を受信するためにルート・アドバータイズメント・メッセージに対する要求を１つ以上のネットワークオーバラップノードに送出する。ルート・アドバータイズメント・メッセージを受信するように選択されたネットワークオーバラップノードは、ユーティリティノードＭ２３８１のメモリから取得される。偶然にも、メモリから取得されたネットワークオーバラップノードのいずれもＭ２３８１が既に接続しているノードではない。問い合わせされたネットワークオーバラップノードから受信した応答に基づいて、１つのネットワークオーバラップノードＭ３９４７は、当該時間フレーム内にリブートしていないと判定される。従って、Ｍ２３８１は、Ｍ３９４７から取得したルーティング情報に基づいて自身のルーティング情報を更新し始める。
【００４２】
上記例においては、ネットワークオーバラップノードは、リブート後にＭ２３８１により先に接続されていた隣接したノードではないが、他の実施形態は、サブネットが全体的に停電したと判定する前にリブート情報に対する要求の間に接続されたノード中に１つ以上のネットワークオーバラップノードを有しても良い。
【００４３】
例５  ユーティリティメータに結合された１０，０００個のユーティリティノードを含む無線メッシュネットワーク。無線ユーティリティノードは、サブネットＵＮ−ＳＵＢ６及びＵＮ−ＳＵＢ７を含む複数のサブネットに配置される。ＵＮ−ＳＵＢ６及びＵＮ−ＳＵＢ７の各々は単一のアクセスポイントノードを有する。ＵＭ６４１１で指定されたネットワーク内のユーティリティノードは、ＵＭ−ＳＵＢ６に常駐する。ユーティリティノードＵＭ６４１１は、５３個の直接アクセスできる隣接ノードを有する。リブート後、ＵＭ６４１１は、複数のノードからのサブネットメンバーシップ情報を要求する。隣接ノードは、自身のサブネットメンバーシップ情報を使用して応答する。ユーティリティノードＵＭ６４１１は、受信したサブネットメンバーシップ情報を解析し、ＵＭ６４１１がメンバであるサブネット以外のサブネット、特に、サブネットＵＮ−ＳＵＢ６以外のサブネット上に応答するノードのいずれかがあるかを判定する。サブネットメンバーシップ情報により応答した別のユーティリティノードＵＭ７９４８は、ＵＮ−ＳＵＢ６に加えてＵＮ−ＳＵＢ７のメンバであるため、ネットワークオーバラップノードである。従って、ユーティリティノードＵＭ６４１１は、ルーティング更新情報を受信するためにルート・アドバータイズメント・メッセージに対する要求をＵＭ７９４８に送出する。ＵＭ６４１１は、ＵＭ７９４８から取得したルーティング情報に基づいて自身のルーティング情報を更新し始める。
【００４４】
上記例においては、ノードＵＭ６４１１は、サブネットメンバーシップ情報に対する第１の要求からネットワークオーバラップノードの場所を特定できたが、他の実施形態は、ネットワークオーバラップノードの場所を特定するために複数のメッセージが送出されることを要求しても良い。
【００４５】
上記例においては、ノードＵＭ６４１１は、リブート後に送出されたサブネットメンバーシップ情報に対する第１の要求からネットワークオーバラップノードの場所を特定できたが、他の実施形態は、サブネットメンバーシップ情報に対する要求を送出する前にネットワークオーバラップノードの場所を特定するためにノードに自身の格納された情報をチェックさせても良い。
【００４６】
上記例においては、ノードＵＭ６４１１は、ネットワークオーバラップノードの場所を特定できたが、他の実施形態において、ノードはネットワークオーバラップノードの場所を特定できない可能性があり、上記他の実施形態において説明したように、最近リブートしていないノードからリブート情報を受信するために他のノードのリブート情報をチェックしても良い。
【００４７】
上記実施形態の例では、リブート情報に基づいてルーティング情報を更新したが、他の実施形態では、他の情報を更新しても良い。他の情報には、パス及びリンクコスト、周囲雑音レベル、上流ノードの集合を参照した情報成功率、ＭＡＣアドレス、時間同期情報及びＦＨＳＳ拡散シーケンスコードが含まれるが、これらに限定されない。ルーティング情報は、宛先までの完全なパス、宛先までの部分的なパス又はパケットが宛先に到達するために転送される次のノード、あるいはノードがパケットを宛先にルーティングする際に使用できるあらゆる情報を含んでも良い。なお、宛先は送出元ノードと同一のサブネット又はネットワーク上にある必要はない。
【００４８】
いくつかの他の実施形態において、リブートした要求元ノードは、全てが同一のリブートカウンタ設定及びパスコストを有する他のノードの中から、使用可能時間（ノードが使用され且つ動作していた長さとして規定される）に基づいてルーティング情報及び更新及び可能な次のホップ選択に対してノードを選択しても良い。
【００４９】
上述したように、ノードをリブートさせる原因となる状況の１つは電力の損失である。電力の損失は、配電インフラストラクチャの所定の領域におけるサービスの中断又は停電により起こる可能性がある。図６Ａは、停電が起こったユーティリティ通信ネットワークの一例を示す。ユーティリティネットワークは、各々が顧客の建物にあるユーティリティメータに結合される複数のノード６０１から構成された無線メッシュネットワーク６００を含む。ユーティリティノードは、ユーティリティノード６０１により形成された無線メッシュネットワーク６００の入り口及び出口を提供する１つ以上のアクセスポイント６０３を使用してユーティリティのバック・オフィス・サーバ６０２と通信する。アクセスポイント６０３は、例えば、ワイドエリアネットワークである適切な通信ネットワーク６０４を介してバック・オフィス・サーバ６０２と通信する。図６Ａの例において、「Ａ」〜「Ｈ」のラベルが付けられたユーティリティノードは、現在アクティブであり、ネットワーク６００内の無線リンク６０５を介して互いに通信する。この例において、停電は無線ネットワーク６００の有効範囲に含まれた配電ネットワークのある部分において発生し、それにより、斜線をつけて示した多くの他のユーティリティノードは電力を供給されなくなり、通信できなくなる。
【００５０】
図６Ｂは、以前に電力が供給されていなかったユーティリティノードのいくつかと関連付けられた建物に対して電力が回復された状況を示す。これらの新たに回復したノードは破線で描かれた円で表され、「Ｊ」〜「Ｑ」及び「Ｘ」のラベルが付けられる。上記例において説明したように、ノードは、リブート後にルーティング情報を迅速に取得し、正常なネットワーク動作を再開できる。本発明の別の態様によると、そのような正常動作が完全に回復される前であっても、バック・オフィス・サーバ６０２は、電力が顧客の建物と関連付けられた個々のノードに対して回復されたことを通知される。バック・オフィス・サーバにそのような通知を提供する種々の実施形態を以下に説明する。
【００５１】
一実施形態においては、ノードに対する電力が回復し且つノードがリブート動作を完了した後、ノードは、隣接ノード、すなわち、直接通信できる他のノードを発見する処理を開始する。図６Ｂの例において、ノードＸは、現在アクティブである隣接ノードがノードＣ、Ｅ、Ｇ、Ｌ、Ｎ及びＱを含むことを発見する。ノードＸが隣接ノードの各々との通信を確立する場合、ノードは特に有効期間、すなわち、ノードが前回のリブートからネットワークにおいて継続してアクティブである期間及びルーティング状態を含むメッセージをやり取りする。ノードＸは、この情報から隣接ノードをプロキシとして選択し、宛先がプロキシノードである回復メッセージを送出する。このメッセージの受信に応答して、プロキシノードは、正常に機能し、メッセージをバック・オフィス・サーバにルーティングし、ノードＸが電力損失から回復したことを通知する。
【００５２】
プロキシノードの選択は、１つ以上の基準に基づいても良い。例えば、選択するノードは、有効期間が特定の閾値を超え且つ／又はアクセスポイント６０３へのパスを有することをアドバータイズする隣接ノードのみを選択しても良い。複数の隣接ノードがそのようなパスをアドバータイズする場合、選択するノードは、最小のパスコスト及びリンクコストを有する隣接ノードをプロキシとして選択しても良い。ここで、低いコストはルーティングの信頼性を表す。図６Ｂの例において、ノードＬ、Ｎ及びＱは、ノードＸとのオンラインに最近参加したため、それらの有効期間の値は小さすぎる。これに対して、ノードＣ、Ｅ及びＧは、停電の影響を受けなかったため、受け入れ可能な有効期間の値を有する。更に、ノードＣ、Ｅ及びＧの各々は、アクセスポイント６０３へのパスを提供できる。ノードＸは、アクセススポイントまでの最短のパス、すなわち、最小のホップ数を提供することに基づいて、回復メッセージを送出するためにこれらの３つのノードのうちノードＣをプロキシとして選択しても良い。なお、最短のパスは単に１つのオプションである。他の実施形態において、より長いパスが最短のパスのオプションと比較してより小さいパスコスト及びリンクコストを提供する場合、より長いパスがルーティングのために受け入れ可能であっても良い。
【００５３】
回復するノードＸがプロキシノードＣに向ける回復メッセージは、回復状態に関する関連情報を含む。その情報は、回復ノードのリブートカウンタ、回復ノードに電力が供給されなかった時間の長さ、回復ノードが経験したあらゆる瞬間的な停電又は電力の変動、並びに／あるいは電力回復時間を含んでも良い。回復メッセージの内容は、ノードＸが発見したノードＸの隣接ノードに関する情報を更に含んでも良い。例えば、図６Ｂの例において、ノードＮの全ての隣接ノードが停電の影響を受けたために選択に対するいかなる基準も満たさない可能性があるため、ノードＮは、回復メッセージを送出するためのプロキシをまだ見つけていない。ノードＸからの回復メッセージは、ノードＬ、Ｎ及びＱの各々との通信を確立できたことを示す情報、並びに可能性としてそれらノードの各々の回復状態を含んでも良い。その結果、それらのノードの各々が自身の状態をユーティリティに直接通信できるようになっていないが、ユーティリティは、電力がそれらのノード全てに対して回復したことを通知される。ノードＸからの回復メッセージは、ユーティリティが回復するノードの各々に関して受信する情報がどの程度新しいものかを判定できるように適切なタイムスタンプを含むのが好ましい。
【００５４】
メッセージは認証されても良い。回復するノードは、メッセージに署名するために公開鍵暗号法を使用しても良く、あるいは共有秘密及び対称鍵暗号法を使用しても良い。送出元ノードが公開鍵暗号法を使用する場合、プロキシ隣接ノード及びバック・オフィス・サーバの双方は、メッセージが適切なノードから送信されたと判定できる。対称鍵暗号法が使用される場合、認証処理は２段階で行なわれても良い。回復するノードは、そのノードとプロキシ隣接ノードとの間で共有される鍵を選択しても良い。その後、プロキシはメッセージの信憑性をチェックし、メッセージが信頼できるものである場合、プロキシは自身の鍵でメッセージに再署名し、それをバック・オフィス・サーバに送出しても良い。あるいは、回復するノードはバック・オフィス・サーバと共有された秘密を使用してメッセージに署名しても良い。この場合、プロキシノードはメッセージの信憑性をチェックできない場合がある。
【００５５】
回復メッセージを受信するプロキシノード、すなわち、上述の例においてはノードＣが例外トラッピングとして既知の機構を介してバック・オフィス・サーバ６０２にメッセージを転送できる。ネットワーク内において、特定の事象が例外として識別され、ユーティリティは、その例外に関して即座に通知されるべきである。停電及び停電からの回復は、２つのそのような例外である。例外トラッピングメッセージは、ユーティリティ・バック・オフィス・サーバ６０２への迅速な配信を容易にするために、無線ネットワーク内においてアクセスポイント６０３により優先される。例外トラッピングがメッセージを送出するために採用される場合、ユーティリティサーバは、適切に対処できるようにメッセージを受信したことを即座に通知される。
【００５６】
別の実施形態において、回復したノードは通知処理を開始するために隣接ノードの発見を待つ必要はない。本実施形態の一例を図６Ｃに示す。図６Ｃを参照すると、電力が回復され、ノードＮがリブートするとすぐに、ノードＮは、回復メッセージを自動的にブロードキャストし始める。このブロードキャストは、発見処理の前及び／又は発見処理中に行なわれる。ノードの地理的な分散が十分に密集している場合、現在アクティブのノードは、ブロードキャストするノードＮの直接の隣接ノードのうちの１つでない場合でもブロードキャストされた回復メッセージを受信する可能性がある。図６Ｃの例において、ノードＣ及びＧの各々は、ノードＮからブロードキャストされたメッセージを受信する。そのようなメッセージが受信されるとすぐに、受信ノードは、プロキシとして機能し、ブロードキャストされた回復メッセージをアクセスポイント６０３を介してバック・オフィス・サーバ６０２に転送して、電力がノードＮに対して回復されたことをサーバ及びアクセスポイントに通知できる。
【００５７】
上記の実施形態において、回復するノードは、停電後のノードの電力の回復についてバック・オフィス・サーバに通知する回復メッセージを送出する主導権をとる。別の実施形態において、サーバの通知は最近回復したノード以外のノードにより開始される。図６Ｄを参照すると、電力が回復した後、ノードＬ、Ｘ及びＱは、停電の影響を受けなかったアクティブな隣接ノードＡ、Ｃ、Ｅ及びＧを発見した。発見処理中にやり取りされるメッセージの結果として、ノードＡ、Ｃ、Ｅ及びＧの各々は、ノードＬ、Ｘ及びＱが、例えば、５分である所定の閾値未満の有効期間を有すると判定できるであろう。停電の影響を受けなかったノードが、例えば、１０分である最短期間の間有効であった場合、それらのノードは、自身で指定したプロキシとして機能し、ネットワークにおいて最近アクティブになった特定のノードが発見されたことをバック・オフィス・サーバに通知するメッセージを生成する。従って、この例において、ノードＡは、ノードＬが発見されたというメッセージをバック・オフィス・サーバに送出し且つその有効期間を報告できる。ノードＣは、ノードＬ及びＸの各々が発見されたというメッセージを送出し且つそれらの有効期間を報告できる。ノードＥは、ノードＸの発見及びその有効期間に関する報告を送出できる。ノードＧは、ノードＸ及びＱの発見及び有効期間に関するメッセージを送出できる。本実施形態において、バック・オフィス・サーバは、最近回復したノードの発見について認識し且つ通知するために「より古い」ノードに依存する。
【００５８】
本実施形態のいくつかの実現例において、自身が指定したプロキシノードとして機能して回復したノードに関する情報を報告する特定のノードは、複数の冗長情報収集技術を使用することにより可能な限り迅速にノードを動作中に戻すために、ネットワークの密度、ネットワークにおける停電事象の履歴及び／又はユーティリティサーバにより設定された性能計測値に基づいてノードに報告するための有効期間閾値を動的に再設定することにより判定される。例えば、停電領域の近傍にあるか又は停電から最近回復したノードの一部であるより多くのノードが自身の隣接ノードの状態及び状況に関してサーバに報告することを可能にするために、ノードに報告するための有効期間閾値は減少されても良い。これにより、回復が実際に実行中であることをサーバが保証することが支援されるであろう。
【００５９】
理論上、回復メッセージは、ノードがリブートする度にバック・オフィス・サーバに送出される。しかし、実際的な観点から、リブートがサーバからのコマンド等に応答して、例えば、ソフトウェアアップグレード、予定された保守の結果として演繹的に認識される事象である場合、そのようなメッセージを送出する必要はない。この状況において送出されたメッセージは、ネットワークにおいて不必要なトラフィックとなる。従って、回復メッセージの送信は、電力の損失又はノードを予期せずにシャットダウンさせる他の事象の結果としてリブートが起こるような状況に限定される。
【００６０】
このために、ノードは、リブート時にリブートが計画されたものか又は予想外のものかを判定できるようにする機構を備える。一例として、ノードが計画されたリブートを行なう場合、ノードは自身の状態を保存し且つデータが失われないことを保証するために、順序だったシャットダウン処理を進める。この処理の終了時、ノードは、シャットダウンが計画的であり且つ適切に完了したことを示すフラグを設定できる。リブートすると、ノードは、フラグの状態をチェックし、フラグが設定されていた場合は通常の発見処理を継続し且つルーティング情報を取得できる。しかし、フラグが設定されておらず、シャットダウンが予想されたものではなく且つ／又は順序立てて実行されなかったことを示す場合、回復メッセージは可能な限り迅速に送信される。
【００６１】
いくつかの実施形態において、ノードは、主電源が遮断された時期を認識し、電力を失っているという「最後の」メッセージを送信し且つ順序だったシャットダウンを行なうことによりそのような状況に応答する機能を有しても良い。例えば、ノードはそのような動作を実行するのに十分な電力を供給する、例えば、バッテリ又は容量性記憶装置である小型のバックアップエネルギー源を有しても良い。これらの実施形態において、ノードは停電のためにシャットダウンしていることを示すようにフラグを設定できる。ノードはリブートすると、フラグの状態をチェックし、フラグが設定されている場合は電力が回復したことを示す回復メッセージを送出できる。
【００６２】
従って、ノードが、例えば、電力損失のために予期せずにシャットダウンした場合、専用のメッセージがバック・オフィス・サーバに迅速に送出され、ノードが再度オンラインになっているという通知を提供する。このメッセージは、回復するノードがメッセージのルーティングと関連する正常なネットワーク動作を再開する前でも送出可能である。発信元であるノードから宛先であるバック・オフィス・サーバへ終端間でメッセージを送出するのではなく、回復メッセージは、回復するノードに対してプロキシとして機能し且つメッセージがバック・オフィス・サーバ又は他の適切な宛先に配信されることを保証するためにルーティング機能として動作する隣接ノードに向けられる。
【００６３】
本明細書で提示された実施形態は、現在の好適な実施形態を示すためにサブシステム及び機能性を組み合わせる。別の実施形態は、より少ないサブシステム、処理又は機能面、あるいは追加のサブシステム、処理又は機能面を含んでも良く、あるいは所望の実現例に依存して他のサブシステム、処理又は機能面と共に使用されても良い。本発明の種々の特徴及び利点を以下の請求の範囲に示す。
【図１】
2011515988.tif 000003
【図２】
2011515988.tif 000004
【図３】
2011515988.tif 000005
【図４】
2011515988.tif 000006
【図５】
2011515988.tif 000007
【図６Ａ】
2011515988.tif 000008
【図６Ｂ】
2011515988.tif 000009
【図６Ｃ】
2011515988.tif 000010
【図６Ｄ】
2011515988.tif 000011
【国際調査報告】
2011515988.tif 000012
2011515988.tif 000013
2011515988.tif 000014
2011515988.tif 000015
2011515988.tif 000016