JP2014513445A - ネットワークにおいて一組のルートを発見するための方法 - Google Patents

Abstract

集線装置、スマートメーター、および仮想ノードを含むネットワークにおいて一組のルートが発見される。各集線装置ノード、すなわちソースがルート要求（ＲＲＥＱ）パケットを仮想宛先ノードにブロードキャストする。中間ノードは、このルートを、ＲＲＥＱパケット内のノードリスト（ＮＬ）として、およびそのノードにおけるルートテーブル（ＲＴ）として記憶する。次に、各スマートメーターノードが、ルートテーブルから、スマートメーターノードから任意の集線装置への一次ルートおよび二次ルートを選択することができる。

Description

本発明は、包括的には無線センサーネットワークにおけるパケットのルーティングに関し、特に、スマートメーターネットワークにおいてパケットをルーティングすることに関する。

スマートメーターネットワークは、電気、水道、およびガス等の公益事業サービスを容易にするためのセンサーネットワークである。図１に示すように、スマートメーターネットワークは、スマートメーターセンサー（Ｍ）１０１と、通常、有線リンクを介して制御ネットワークに接続される（１０３）データ集線装置１０２と、を備える。スマートメーターと集線装置との間の通信は、通常、データパケットおよび制御パケットのために、無線リンクを用いる。センサーおよび集線装置は、包括的に「ノード」と呼ばれる。

スマートメーターネットワークは、従来のセンサーネットワークと区別される。スマートメーターネットワークは、数千個のスマートメーターと、１つまたは数個のみのデータ集線装置と、を備えることができる。スマートメーターおよび集線装置の双方が固定であり、例えば自宅および建物に設置される。スマートメーターは、周期的にデータを収集し、そのデータを、無線リンクを介して、１つまたは複数の集線装置に送信する。集線装置は、有線リンクを介して公共事業サービス会社の制御ネットワークにデータを送信する。集線装置は、制御コマンドを１つまたは複数のスマートメーターに送信することができる。データパケットおよび制御パケットは、数秒等の低いレイテンシで、集線装置およびスマートメーターにそれぞれ確実に配信される。

スマートメーターおよび集線装置は大規模なマルチホップメッシュネットワークを形成し、このネットワークでは、パケットは、他のノードを介して中継される必要がある場合がある。パケットが中継される方式は、重大である。したがって、信頼性のあるルートが用いられなくてはならない。

通常のスマートメーターノードＭ１０１は、集線装置Ｃｌを一次集線装置として選択し、集線装置Ｃ２をバックアップ集線装置として選択することができる。ノードＭ１０１は、一次集線装置への２つのルートと、バックアップ集線装置への１つのルートと、を有する。

様々な要件に基づく、無線センサーネットワークおよび移動アドホックネットワークのための複数のルーティング方法が知られている。アドホックオンデマンド距離ベクトル（ＡＯＤＶ）、アドホックオンデマンドマルチパス距離ベクトル（ＡＯＭＤＶ）、および動的ソースルーティング（ＤＳＲ）が既知である。しかしながら、これらのルーティング方法は、任意のノードがソースまたは宛先となり得る同種ネットワークのために設計されているため、スマートメーターネットワークには適していない。さらに、ＡＯＤＶは、単一ルート法である。

ＡＯＭＤＶは、ソースと宛先との間の複数の交わらないルートを発見することを試みる。一方、問題は、ノードによっては、一組の交わらないルートを発見することができないことである。結果として、ＡＯＭＤＶは、幾つかのノードの場合に単一のルートしか発見することができない。

ＤＳＲに伴う主な問題は、各パケットがルート情報、すなわち、ノードリストを含むことである。ノードリストは、特に、ルートが長いときにパケット内のオーバーヘッドを増大させる。

さらに、これらの従来のルーティング方法におけるルートを求めるための複数ネットワーク規模のブロードキャストフラッドによって、それらの通信オーバーヘッドが、大きなスマートメーターネットワークにとって過度に高くなる。

低電力で損失の多いネットワークのためのルーティングプロトコル（ＰＲＬ）が、別のルーティング法である。ＲＰＬは、ルート発見のために無閉路有向グラフ（ＤＡＧ）を用いる。しかしながら、多くの重要な問題がＲＰＬによって解決されないままとなっている。例えば、ＲＰＬのためのランク計算は、説明されていない。

したがって、スマートメーターネットワークが、非常に低いレイテンシでデータパケットおよび制御パケットを確実に配信するためのルーティング方法を開発することが望ましい。

本発明の実施の形態は、大規模マルチホップメッシュネットワークにおいて、フラッドを最小にする、ループのない複数のルートを発見するための方法を提供する。当該技術分野において、フラッドとは、パケットをネットワーク内の全てのノードに送信することを意味する。フラッドによってネットワーク帯域幅が低減する可能性があり、パケットが重複するか、または無限ループに陥る可能性もある。

本発明の実施の形態は、仮想宛先ノードを用いて、全てのスマートメーターノードから集線装置ノードへの一組のルートを発見する。

各スマートメーターノードと集線装置との間の一組の二方向ルートは、信頼性のある２方向通信を保証するように検証される。

障害回復方法は、局所ルート修復を提供し、他のパケット送信との干渉を回避する。

本発明の実施の形態が動作するスマートメーターネットワークの概略図である。 ルート要求（ＲＲＥＱ）パケットがネットワーク全体に伝搬することができないネットワークの一例の概略図である。 本発明の実施の形態による、宛先ノードへのルート発見方法の一例の概略図である。 本発明の実施の形態による、ＲＲＥＱパケットをフィルタリングし処理するプロセスの流れ図である。 本発明の実施の形態による、第１のルートの選択の流れ図である。 本発明の実施の形態による、ノードにおいて第２のルートを選択するためのプロセスの流れ図である。 本発明の実施の形態による、ノードにおいて、連結したルートを最適化するためのプロセスの流れ図である。 本発明の実施の形態による、ノードにおいて、交わらないルートを最適化するためのプロセスの流れ図である。 本発明の実施の形態による、受信ＲＲＥＱパケットを再ブロードキャストするプロセスの流れ図である。 本発明の実施の形態による、ルート回復のために送信された受信ＲＲＥＱパケットの処理の流れ図である。 ノードが２つの交わらないルートを見つけることができない一例の流れ図である。 本発明の実施の形態による、ルートを検証するタイミング図である。 本発明の実施の形態による、ＲＲＥＱパケットのフォーマットのブロック図である。 本発明の実施の形態による、ルート応答（ＲＲＥＰ）パケットのフォーマットのブロック図である。 本発明の実施の形態による、ルート検証（ＲＶＦ）パケットのフォーマットのブロック図である。 本発明の実施の形態による、ルート検証確認応答（ＲＶＦＡ）パケットのフォーマットのブロック図である。 本発明の実施の形態による、タイミングパケットのフォーマットのブロック図である。 本発明の実施の形態による、データパケットおよび制御パケットのフォーマットのブロック図である。

本発明の実施の形態は、スマートメーターネットワークにおいて一組のルートを発見するための方法を提供する。ネットワークは、一組のスマートメーターノードと、一組の集線装置ノードとを備える。ネットワークに対し仮想ノードも指定される。本明細書において定義されるとき、「組」とは１つまたは複数の構成要素を含む。各集線装置ノードは、ルート要求（ＲＲＥＱ）パケットをブロードキャストする。ＲＲＥＱパケットの宛先は、仮想ノードＩであるので、ＲＲＥＱパケットは、全てのノードによって受信される。このため、各中間ノードは、仮想宛先ノードであり得ないので、各中間ノードもＲＲＥＱパケットを再ブロードキャストする。ＲＲＥＱは、ノードリスト（ＮＬ）において指定されたルートを含むので、各スマートメーターノードは、ＲＲＥＱパケットを受信し再ブロードキャストした後、一組のルートを有する。この一組のルートは、受信ＲＲＥＱパケットにおいて指定され、ノードにおけるルートテーブル（ＲＴ）に記憶され、そこから一次ルートおよび二次ルートが選択される。

本発明は、ブロードキャストされるＲＲＥＱパケット数を最小にしてネットワーク規模のブロードキャストフラッドを低減しながら、一組のループのないルートを発見する。ネットワーク規模のブロードキャストフラッドは、ネットワークリソース要件および干渉を増大させる可能性がある。実際に、ブロードキャストによってネットワークにフラッドが生じる回数は、集線装置数以下である。したがって、スマートメーターネットワークが１つの集線装置を有する場合、ネットワーク規模のブロードキャスト（フラッド）は、１回しか必要でない。ルートは、要求に応じて、または周期的に発見することができる。

全てのスマートメーターノードが集線装置への一組のルートを発見することを可能にするために、全てのスマートメーターノードは、集線装置によってブロードキャストされるＲＲＥＱパケットの１つまたは少なくとも２つのコピーを受信することを保証される。

本発明のルーティング方法を従来のルーティング方法と区別するために、まず、ＡＯＤＶ、ＡＯＭＤＶ、およびＤＳＲにおいて用いられるルート要求およびルート応答が、上記の要件を満たすことができないことを説明する。なぜなら、幾つかのノードは、ネットワーク全体にＲＲＥＱパケットを伝搬することが必ずしもできるとは限らないためである。

図２に示すように、ソースノードＳは、ＲＲＥＱパケットをブロードキャストすることによってルート発見を開始する。ＲＲＥＱパケットは、ノードＳ−１−２−ＤおよびＳ−３−Ｄ等の一組のルートに沿ってノードを介して宛先ノードＤへ伝搬する。ノードＤは、ＲＲＥＱパケットを受信するが、ノードＤは、宛先であるので、ＲＲＥＱパケットを再ブロードキャストしない。

代わりに、ノードＤは、ルート応答（ＲＲＥＰ）パケットを生成し、ＲＲＥＰパケットをノードＳに送信する。ノードＤは、ＲＲＥＰパケットを一組のルートに沿ってノードＳにユニキャストまたはブロードキャストすることができる。ノード４は、ノード１、２、３およびＳから離れすぎているので、ノード４は、ノード１、２、３およびＳからＲＲＥＱパケットを受信しない。したがって、ＲＲＥＱパケットネットワーク全体に伝搬しない。

ＲＲＥＱパケットがネットワーク全体に伝搬することを確実にするために、本発明では、図３に示すように宛先ノードとして仮想ノードＩ３００を用いる。仮想ノードＩは、実際にネットワーク内に物理的に存在せず、このためルート発見中、集線装置を含むいかなるノードによっても仮想ノードに到達することができない。したがって、集線装置ＣがＲＲＥＱパケットをブロードキャストするとき、ネットワーク内の全ての実際のノードは、宛先ノードとなることができない。結果として、各ノードがＲＲＥＱパケットを再ブロードキャストしなくてはならず、各ノードがＲＲＥＱパケットのコピーを受信しなくてはならない。これによって、ＲＲＥＱパケットがネットワーク全体に伝搬しなくてはならないことが保証される。また、図３は、各スマートメーターノードから集線装置への一組のループのないルートを示している。

最も単純な説明のために、１つの集線装置を有するスマートメーターネットワークを用いることによって本発明のルート発見方法を説明する。また、各スマートメーターノードは、集線装置への２つのルートを発見する。しかしながら、本発明のルート発見方法は、一組の集線装置および一組のルートを有するネットワークに適用することができる。

初期ルート発見
図７Ａ〜図７Ｆは、本発明の実施の形態によって用いられる様々なパケットのフィールドを示している。

集線装置は、ＲＲＥＱパケット７０１をブロードキャストすることによってルート発見を開始する。図７Ａに示すように、ＲＲＥＱパケットは、ソース識別情報（Ｓ−ＩＤ）、宛先識別情報ＩＤ（Ｄ−ＩＤ）、ノードタイプ（ＮＴ）、有効期間（ＴＴＬ）、ノードリスト（ＮＬ）、シーケンス番号（ＳＮ）、および他のオプションを含む。ＮＴは、ＲＲＥＱパケットが最初に集線装置によってブロードキャストされたか、または、スマートメーターによってブロードキャストされたかを示す。ＮＬの長さは、可変であり、最初は、０にセットされている。各ノードは、発見されたルート数をカウントするルート数（ＮＲ）変数も保持する。ＮＲをも０に初期化される。

集線装置および仮想ノードのためのＩＤが、それぞれＣ−ＩＤおよびＩ−ＩＤであると仮定する。

ルート発見を開始するために、集線装置は、Ｓ−ＩＤをＣ−ＩＤにセットし、Ｄ−ＩＤをＩ−ＩＤ、すなわち、仮想ノードＩにセットし、ＮＴをＣ（集線装置）にセットし、ＴＴＬを所定の値にセットし、ＳＮを０にセットし、ＮＬを空にセットする。次に、集線装置は、ＲＲＥＱパケットをブロードキャストする。

図４Ａ〜図４Ｆは、本発明の実施の形態による初期ルート発見の詳細を示している。

図４Ａに示すように、Ｍ−ＩＤに等しいＩＤを有するノードがＲＲＥＱパケットを受信した（４１０）後、このノードは、まずフィルタリング手順を実行する。ノードは、Ｓ−ＩＤが自身のＩＤ、すなわち、Ｍ−ＩＤに等しいか否かを調べる（４１１）。等しい場合、ＲＲＥＱパケットは、破棄される（４１４）。等しくない場合、ノードは、ＲＲＥＱ内のＮＬがＲＴに記憶されている任意のＮＬと同じであるか否かを判断する。同じである場合、ＲＲＥＱパケットを破棄する（４１４）。同じでない場合、ノードは、自身のＩＤがＲＲＥＱパケットのＮＬ内にあるか否かを調べる（４１５）。ある場合、これは、ループであり、ＲＲＥＱパケットは、破棄される（４１４）。ない場合、ノードは、ＲＲＥＱパケットを処理する（４１６）。ＲＲＥＱパケットが最初に集線装置によってブロードキャストされたか否か（４１７）に依拠して、ＲＲＥＱプロセスは、第１のＲＲＥＱを処理すること（４２０）と、第２のＲＲＥＱを処理すること（４３０）と、最適化のために後続のＲＲＥＱを処理すること（４４０）と、ルート回復のためにＲＲＥＱを処理すること（４５０）とからなる。ＲＴ内の２つのルートが交わらないか否かに依拠して（４１８）、ルート最適化プロセスは、連結したルートを最適化すること（４６０）と、交わらないルートを最適化すること（４７０）と、に分割される。ノードは、異なるコンテンツを有する同じＲＲＥＱパケットの複数のコピーも処理する。

２つのルートの選択が図４Ｂおよび図４Ｃによって示されている。プロセス４２０は、第１のルートを選択し、第１のルートをＲＴに加え（４２３）、ＮＲを１にセットし（４２４）、ＲＲＥＱパケットを再ブロードキャストする（４８０）。

プロセス４３０は、第２のルートを選択し、このルートをＲＴに加え（４３３）、ＮＲ＝２をセットし（４３４）、ＲＲＥＱパケットを再ブロードキャストする（４８０）。

その後に受信されるＲＲＥＱパケットは、図４Ｄおよび図４Ｅに示すように、ルート最適化のために用いられる。

プロセス４６０は、２つの連結したルートを最適化する。この場合、ＲＴ内の２つのルートは、連結されており、最適化は、２つの可能な交わらないルートを選択することである。ＲＲＥＱ内のルートがＲＴ内の双方のルートと交わらない（４６１）場合、ＲＴ内の長い方のルートがＲＲＥＱ内のルートと置き換えられ（４６２）、ＲＲＥＱが再ブロードキャストされる（４８０）。ＲＲＥＱ内のルートがＲＴ内の一方のルートのみと交わらない（４６３）場合、ＲＲＥＱ内のルートに連結するＲＴ内のルートがＲＲＥＱ内のルートと置き換えられ（４６５）、ＲＲＥＱが再ブロードキャストされる（４８０）。ＲＲＥＱ内のルートがＲＴ内の双方のルートと連結する場合、ＲＲＥＱは、破棄される（４６４）。

プロセス４７０は、２つの交わらないルートを最適化する。この場合、ＲＴ内の２つのルートは、交わらず、最適化は、２つのより短い交わらないルートを選択する。ＲＲＥＱ内のルートがＲＴ内の双方のルートと交わらず（４７１）、かつＲＴ内の任意のルートよりも短い（４７２）場合、ＲＴ内の長い方のルートがＲＲＥＱ内のルートと置き換えられ（４７３）、ＲＲＥＱは、破棄または再ブロードキャストすることができる（４７４）。ＲＲＥＱ内のルートがＲＴ内の一方のルートのみと交わらず（４７６）、かつそのルートと連結するＲＴ内のルートよりも短い（４７７）場合、ＲＲＥＱ内のルートと連結するＲＴ内のルートがＲＲＥＱ内のルートと置き換えられ（４７８）、ＲＲＥＱは、破棄または再ブロードキャストすることができる（４７４）。そうでない場合、ＲＥＥＱは、破棄される（４７５）。

プロセス４８０は、図４Ｆに示すように、ＲＲＥＱ再ブロードキャストを実行することである。ＴＴＬは、１だけ減少される（４８１）。ＴＴＬがゼロである（４８３）場合、ＲＲＥＧは、破棄される。そうでない場合、ノードＩＤ、すなわち、Ｍ−ＩＤは、ＲＲＥＱ内のＮＬに挿入され（４８４）、ＲＲＥＱが再ブロードキャストされる（４８５）。

２つの最短ルート、または２つの交わらないルート、または２つのコスト効率のよいルート等の２つのルートを選択する多くの方法が存在する。ＡＯＭＤＶは、複数の交わらないルートを発見することを試みる。しかしながら、場合によっては、幾つかのノードは、複数の交わらないルートを発見することができない。

図５に示すように、ノード５は、２つの交わらないルートを見つけることができない。２つのルートは、ソースおよび宛先以外に共通のノードを有しない場合、交わらない。

本発明の実施の形態では、ノードは、以下の判断基準、またはそれらの組み合わせ、すなわち
ルートが発見された順序、例えば、第１のルートが一次ルートであり、後続のルートが二次ルートとして選択される、
交わらないルートは、独立して不具合を起こす（fail）ので、ルートが交わらないレベル。交わらないレベルは、複数のルートに共通しているノードの数によって決まる。ルートが共通のノードを有しない場合、ルートは完全に交わらない、
より短いルートは、通常、より信頼性があり効率的であるので、ルート内のホップ数、
平均パケットドロップ率、すなわちルートの信頼性、
ルートにおけるバッファリング容量、および
予測伝送遅延、
に従って、ルートを選択することができる。

発見されるルート数に依拠して、ＮＬ内の単数または幾つかの第１のルートがＲＴに加えられる。ノードがＲＲＥＱパケットの後続のコピーを受信するとき、ノードは、その可能なルートを最適化する。交わらないルートは、独立して不具合を起こすので、交わらないルートを選択することが第１の選択肢である。２つの交わらないルートの複数の対が存在する場合、２つの最も短い交わらないルートが選択される。ノードが２つの交わらないルートを発見することができない場合、２つの連結したルートが選択される。

図３に示すように、ノード７は、２つのルート、すなわち７−５−２−Ｃおよび７−４−１−Ｃを選択することができる。ノード８は、２つの交わらないルートを発見することができない。ノード８は、２つの連結したルート８−６−４−２−Ｃおよび８−６−３−１−Ｃを選択することができる。

全てのノードが２つのルートを発見することができることを保証するために、各ノードは、ＲＲＥＱパケットの少なくとも２つのコピーを再ブロードキャストしなくてはならない。再ブロードキャストのためのＲＲＥＱパケットの２つのコピーを選択する多数の方法が存在する。例えば、ＲＲＥＱの第１のコピーおよびより短いルートを有するＲＲＥＱの後続のコピーが選択される。しかしながら、この選択は、幾つかのノードが一組のルートを発見することを妨げる可能性がある。図５に示すように、ノード４が最初にルートＣ−３−４を介してＲＲＥＱパケットを受信する場合、ＲＲＥＱパケットの全ての後続のパケットは、より長いルートを含む。結果として、ノード５は、１つのルートしか発見することができない。

本発明において、ＲＲＥＱの最初の２つのコピーが各ノードによって再ブロードキャストされる。ＲＴ内の２つのルートが連結している場合のみ、ＲＲＥＱの後続のコピーが再ブロードキャストされ、受信ＲＲＥＱパケット内に含まれるルートを用いて、２つの交わらないルートを選択することができる。そうでない場合、ＲＲＥＱの後続のコピーを再ブロードキャストすることは、オプションである。

再ブロードキャスト送信を低減するために、第２の再ブロードキャストから開始して、ＲＲＥＱのＴＴＬを１または２等のより小さな値にセットすることができる。

集約ルート検証
スマートメーターネットワークは、集線装置とスマートメーターノードとの間の２方向の通信を要求する。しかしながら、無線リンクは、任意の一時点において、１方向においてのみ機能することができる。ルート発見は、ブロードキャストを用いる。したがって、これらのルートは、後の時点において、おそらく異なる通信環境においてデータパケットまたは制御パケットのために用いられる前に検証されなくてはならない。

ルート検証（ＲＶＦ）パケット７０３およびルート検証確認応答（ＲＶＦＡ）パケット７０４を用いることによって、ルート検証が実行される。図７Ｃに示すように、ＲＶＦパケットは、Ｓ−ＩＤ、Ｄ−ＩＤ、ルートＩＤ（Ｒ−ＩＤ）、ＳＮ、ＮＬ、および他のオプションを含む。Ｒ−ＩＤは、スマートメーターノードへのルートを識別する。スマートメーターノードは、各ルートにＲ−ＩＤを割り当てる。（Ｓ−ＩＤ、Ｄ−ＩＤ、Ｒ−ＩＤ）は、ネットワーク内のルートを一意に識別する。ＮＬは、検証されるルートを特定し、これはＲＴから取得される。ＲＶＦＡパケットは、Ｓ−ＩＤ、Ｄ−ＩＤ、Ｒ−ＩＤ、ＳＮ、および他のオプションを含む。しかしながら、ＲＶＦＡには、図７Ｄに示すようなＮＬフィールドは存在しない。

ルートを検証するために、スマートメーターノードは、ＲＶＦパケット内のＮＬによって指定されたルートに沿って、ＲＶＦパケットを集線装置にユニキャストする。集線装置は、ＲＶＦパケットを受信すると、ルート情報を記憶し、ＲＶＦパケット内に含まれる逆ルートに沿ってスマートメーターノードにＲＶＦＡパケットをユニキャストする。スマートメーターノードがＲＶＦＡパケットを受信するとき、ルートは、２方向通信ルートとして検証されている。

集線装置は、記憶されたルートを用いて、逆ルート上の任意のノードに制御パケットを送信する。また、ルート上の任意のスマートメーターノードがこのルートを用いて集線装置にデータパケットを送信することができる。

ＲＶＦパケットおよびＲＶＦＡパケットは、中間ノードによって中継される。ＮＬ内のノードがＲＶＦパケットを受信するとき、ノードは、ＲＴ内にこのルートを記憶し、ルート上の次のノードにＲＶＦパケットを転送する。記憶されたルートは、３つの目的、すなわち、
ソースノードへのＲＶＦＡパケットの中継、
データパケットおよび制御パケットの送信、並びに
ルート検証、
に役立つ。

例えば、検証されるルートがＳ−１−２−３−Ｄであり、かつノード１がルート１−２−３−Ｄを有する場合において、ノード１がノードＳ宛てのＲＶＦＡパケットを受信するとき、ノード１は、そのルートルート１−２−３−Ｄも検証している。したがって、ノード１は、ルート１−２−３−Ｄを検証しない。

より長いルートが最初に検証されることが好ましい（図６を参照）。これによって、より短いルートが、より長いルートの検証の一部として検証される可能性が増大する。この集約ルート検証によっても、通信オーバーヘッドが減少する。

ルート回復
従来のセンサーネットワークと対照的に、スマートメーターネットワークは、比較的安定している。第１に、全てのノードは、固定であり、移動センサーノードに関連する他の問題を被らない。さらに、ネットワークのトポロジーは、通常、より長い時間期間にわたって一定のままであり、アドホックセンサーネットワークとは異なる。例えば、スマートメーターが建物内に設置されると、長年にわたって定位置に留まることができる。ノードがネットワークに出入りするときのみトポロジーが変化するが、これは、比較的稀である。

このため、ルートは、不具合を起こすまで用いることができる。一方、スマートメーターノードと集線装置との間には複数のルートが存在するので、スマートメーターノードは、１つのルートをその一次ルートとして選択し、他のルートを二次ルートとして選択する。換言すれば、一組のルートが発見される。この組は、一次ルートおよび二次ルートを含む。一次ルートは、データパケットを集線装置に配信するために用いられる。集線装置は、一次ルートを用いて制御パケットを配信することができる。

ルート回復を円滑に行うために、スマートメーターノードは、近傍のトラフィックパターンを監視して、近傍ノードが送信していない時間期間を求める。この時間期間は、アイドル時間期間と呼ばれる。スマートメーターネットワークでは、データパケットは、周期的に送信され、ノードは、固定である。したがって、そのようなアイドル時間を検出することができる。

ノードが、一次ルートが不具合を起こしたことを検出すると、データパケット配信のために二次ルートのうちの１つを用い、組のための新たなルートを発見する。これを行うために、ノードは、ＲＲＥＱパケットを局所的にブロードキャストする。ノードは、Ｓ−ＩＤを自身のＩＤにセットし、Ｄ−ＩＤをＣ−ＩＤにセットし、ＮＴをＭ（メーター）にセットし、ＴＴＬを１にセットし、ＳＮを０にセットし、ＮＬを空にセットする。他のデータパケット送信との干渉を低減するために、このＲＲＥＱパケットは、すぐに送信されない。代わりに、ノードは、アイドル時間期間中にＲＲＥＱパケットをブロードキャストする。

図４Ｇは、本発明の実施の形態による、ルート回復のために送信された受信ＲＲＥＱパケットを処理するノードのプロセスの流れ図である。Ｍ−ＩＤに等しいノードＩＤを有する各近傍ノードが、集線装置に宛てられた受信ＲＲＥＱパケットを処理する。

Ｍ−ＩＤがＲＲＥＱパケット内のＤ−ＩＤに等しい（４５１）場合、このノードは、宛先集線装置である。集線装置は、図７Ｂに示すようなＲＲＥＰパケット７０２を生成し（４５２）、Ｓ−ＩＤを自身のＩＤにセットし、Ｄ−ＩＤをＲＲＥＱパケットに含まれるＳ−ＩＤにセットし、ＳＮを０にセットし、ＮＬをＲＲＥＱパケットに含まれるＮＬにセットする。

次に、集線装置は、ＲＲＥＰ内のＮＬフィールドによって指定されたルートに沿ってＲＲＥＰパケットをユニキャストし（４５３）、ＲＲＥＱパケットを破棄する（４５４）。同様に、ＲＲＥＰパケットは、アイドル時間期間においても送信される。

受信中のノードが集線装置でない場合、ノードは、宛先集線装置への有効なルートを自身が有するか否か（４５５）を調べる。有する場合、ノードは、Ｓ−ＩＤを自身のＩＤにセットし、Ｄ−ＩＤをＲＲＥＱパケットに含まれるＳ−ＩＤにセットし、ＳＮを０にセットすることによって、ＲＲＥＰパケットを構築する（４５６）。ＮＬは、ＲＲＥＱパケット内に含まれるＮＬをアタッチして、宛先集線装置への自身のルートにおけるＮＬを逆にすることによって構築される。ノードは、アイドル時間期間において、ＲＲＥＱ内に含まれるＮＬによって指定されたルートを介してＲＲＥＰパケットをソースノードに戻してユニキャストし（４５３）、ＲＲＥＱパケットを破棄する（４５４）。

スマートメーターノードは、有効なルートを有しない場合、自身のＩＤをＮＬに挿入し、ＴＴＬを１にセットすることによってＲＲＥＱパケットを更新し、（４５７）、アイドル時間期間において、このＲＲＥＱパケットを再ブロードキャストする（４５８）。

従来のルーティング方法と異なり、ＲＲＥＱパケットがスマートメーターノードによって最初に再ブロードキャストされる場合、ノードは、逆ルートを選択しない。

ソースノードがＲＲＥＰパケットを受信すると、ノードは、ＲＲＥＰパケット内に含まれるＮＬを逆にし、Ｒ−ＩＤを割り当て、ルートをＲＴに記憶する。ノードは、ルートを検証して、ルートが有効な２方向通信パスであることを確実にしなくてはならない。

アイドル時間期間がない場合、ＲＲＥＱパケットおよびＲＲＥＰパケットの送信は、実施態様に依拠する。

一次ルートおよび全ての二次ルートが不具合を起こした場合、ノードは、データパケットをバッファリングし、別の一組のルートを発見する。

ルート維持管理
スマートメーターと集線装置との間のルートが発見され、データパケットまたは制御パケットが送信される前に検証される。ノードが送信するパケットを有するが有効なルートを有しない場合、ノードは、ルート回復において説明したように、一組のルートを発見しなくてはならない。

新たなノードがネットワークに入ると、このノードもルート回復セクションにおいて説明した手順に従い、一組のルートを発見する。

通信リンクは、常に不具合を起こす可能性があるので、二次ルートは、動的にまたは周期的に検証することができる。このルート検証は、可能な限り多くのアイドル時間期間を用いて実行される。

二次ルートが不具合を起こした場合、ノードは、ルート回復セクションにおいて説明したように、別の二次ルートを発見しなくてはならない。

タイミング考察
スマートメーターネットワークが動作する３つのフェーズ、すなわち
フェーズ１：ネットワーク形成、
フェーズ２：ルーティング発見およびルート検証、並びに
フェーズ３：データパケットおよび制御パケットの送信、
が存在し得る。

フェーズ１のネットワーク形成において、スマートメーターノードがネットワークに入る。ネットワークに入るために、スマートメーターノードは、ノードＩＤ、通信に用いられるチャネル、集線装置ＩＤ等の基本ネットワーク情報を取得する。

ネットワークが形成されると、集線装置のうちの１つがスマートメーターノードによって用いられることになる時間パケットをブロードキャストして、ルート検証がいつ開始するかを推定することができる。

図７Ｅに示すように、時間パケット７０５は、以下のフィールド、すなわち、Ｓ−ＩＤ、Ｄ−ＩＤ、ＭＨ（許可される最大ホップ数）、ＭＴ（ネットワーク全体に時間パケットを伝搬するのに必要な最大時間）、ＲＴ（ネットワーク全体にＲＲＥＱパケットを伝搬するのに必要な最大時間）、ＶＴ（全てのルートを検証するのに必要な最大時間）、ＮＨ（時間パケットが進んだホップ数）、および他のオプションを含む。ＮＨは、最初に１にセットされ、パケットが再ブロードキャストされるたびに１だけ増大される。各ノードは、１回のみ時間パケットを再ブロードキャストする。

集線装置は、Ｓ−ＩＤを自身のＩＤにセットし、Ｄ−ＩＤをＩ−ＩＤにセットする。ＭＴ、ＲＴ、およびＶＴは、所定のＭＨ、並びに用いられる媒体アクセス制御および物理（ＭＡＣ／ＰＨＹ）プロトコルを用いることによって推定される。

仮想ノードが時間パケットの宛先であるため、このパケットは、スマートメーターノードによってネットワーク全体に再ブロードキャストされる。

スマートメーターノードは、時間パケットを受信すると、以下のようにルート検証のための待ち時間（ＷＴ）をセットする。

図６に示すように、ＷＴは、より長いルートを有するスマートメーターがルートをより早く検証することを可能にする。集線装置が時間パケットを送信した後、時間パケット、ＲＲＥＱパケット、および検証を伝搬する期間が存在する。ノードが時間パケットを受信した後、ルートを検証する待ち時間期間が存在する。図６に示すように、ノード１のＮＨは、ノード２のＮＨよりも小さいので、ノード１は、ノード２の前に時間パケットを受信する。一方、ノード２は、ノード１よりも早くルート検証を開始する。

データパケットおよび制御パケットの送信
データパケットおよび制御パケットのフォーマット７０６が、図７Ｆに示されている。ＤＳＲと異なり、ＮＬは、データパケットにも制御パケットにも含まれない。パケットは、ペイロードを含む。ソースノードは、データパケットおよび制御パケットを送信するために、一次ルートを用いる。ソースノードは、ＲＴ内のルート情報を用いることによって、パケットを次のホップノードに送信する。ノードがデータパケットまたは制御パケットを受信すると、そのノードは、（Ｓ−ＩＤ、Ｄ−ＩＤ、Ｒ−ＩＤ）を用いてルートを識別し、ＲＴに記憶されたルートから次のノードを参照してパケットを転送する。

例えば、ノードＳは、集線装置Ｃへの２つのルート、すなわちＲ１（Ｓ−１−２−３−Ｃ）およびＲ２（Ｓ−１−４−５−６−７−Ｃ）を有する。ノードＳは、Ｒ１を用いてデータパケットを集線装置Ｃに送信する。ノードＳは、パケットをノード１に送信する。ノード１は、ノードＳの双方のルート上にあるので、ノード１は、ノードＳのための２つのルートを記憶する。ノード１は、受信データパケットのＲ−ＩＤフィールドを調べることによって、Ｒ１を用いるべきであることを知る。したがって、ノード１は、データパケットをノード２に転送する。ノード２は、１に等しいＲ−ＩＤを有する、ノードＳのための１つのルートを記憶する。ノード２は、受信データパケットのＲ−ＩＤフィールドを調べることによって、Ｒ１が正しいルートであることを知る。したがって、ノード２は、データパケットをノード３に転送する。

Claims (13)

1. ネットワークにおいて一組のルートを発見するための方法であって、該ネットワークは、一組のメーターノードと一組の集線装置ノードとを備えるスマートメーター無線ネットワークであり、該方法は、
   前記ネットワーク内の仮想ノードを特定するステップであって、該仮想ノードは、前記ネットワーク内に実際に物理的に存在せず、ルート発見中に前記集線装置を含むいかなるノードによっても到達することができない、ステップと、
   各集線装置ノードによってルート要求（ＲＲＥＱ）パケットをブロードキャストするステップであって、前記ＲＲＥＱは、前記集線装置ノードが前記ＲＲＥＱパケットのソースノードであり、前記仮想ノードが前記ＲＲＥＱパケットの宛先ノードであることを示し、前記ＲＲＥＱパケットは、ノードリスト（ＮＬ）を含み、該ＮＬは、前記ＲＲＥＱパケットを受信した前記メーターノードの識別情報を含む、ステップと、
   各メーターノードにおいて前記ＲＲＥＱパケットを受信し、前記ＮＬ内のルートにルートＩＤを割り当てるとともに、前記ＲＲＥＱパケット内の前記ＮＬをルーティングテーブル（ＲＴ）に記憶するステップと、
   各メーターノードによって前記ＲＲＥＱを少なくとも１回再ブロードキャストするステップと、
   各メーターノードにおいて、前記再ブロードキャストされたＲＲＥＱパケットを受信するとともに、該再ブロードキャストされたＲＲＥＱパケット内の前記ＮＬを前記ＲＴに記憶するステップと、
   各メーターノードにおいて、該メーターノードに記憶された前記ルーティングテーブルから、該メーターノードから各集線装置への一次ルートおよび二次ルートを選択するステップと
   を含む、ネットワークにおいて一組のルートを発見するための方法。
2. 選択されたルートは、ループがない、請求項１に記載の方法。
3. 選択されたルートは、交わらない、請求項１に記載の方法。
4. 前記一次ルートおよび前記二次ルートは、発見されたルートから選択される、請求項１に記載の方法。
5. 前記一次ルートおよび前記二次ルートは、ルートが交わらないレベルに基づいて選択される、請求項１に記載の方法。
6. 前記一次ルートおよび前記二次ルートは、ルート内のホップ数に基づいて選択される、請求項１に記載の方法。
7. 前記一次ルートおよび前記二次ルートを検証するステップと、
   データパケット送信および制御パケット送信のために、検証されたルートを記憶するステップと
   をさらに含む、請求項１に記載の方法。
8. 前記一次ノードを用いて特定のメーターノードから前記集線装置ノードにデータパケットを送信するステップをさらに含む、請求項１に記載の方法。
9. 前記集線装置ノードから特定のメーターノードに制御パケットを送信するステップをさらに含む、請求項１に記載の方法。
10. ルート修復パケットは、アイドル時間期間中に送信される、請求項８に記載の方法。
11. 前記一次ルートに不具合が起きた場合に、前記二次ルートが用いられる、請求項８に記載の方法。
12. 所定の待ち時間後、選択されたルートは、交わらない、請求項１に記載の方法。
13. 前記メーターノードは、スマートメーターノードである、請求項１に記載の方法。

Images