図面 (/)

技術 ノード可用性に基づく通信のルーティング

出願人 アイトロンインコーポレイテッド
発明者 ヴェト-ハングエンバスティアンメイナウドファブリスモニエルジェロームバルティエ
出願日 2012年1月30日 (9年0ヶ月経過) 出願番号 2014-541033
公開日 2015年1月19日 (6年0ヶ月経過) 公開番号 2015-502072
状態 特許登録済
技術分野 移動無線通信システム
主要キーワード ユーティリティネットワーク 周波数センサ ネットワーク記憶デバイス 可用性データ ハードウェアパラメータ 電気消費 ネットワークストレージデバイス 計測モジュール
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年1月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題・解決手段

ノードは、宛先に送信されることになる情報を受信する。情報を受信すると、ノードは、ビジーデバイスリストクエリして、1つまたは複数の隣接ノード可用性を判定してもよい。そして、ノードは、ビジーデバイスリストにしたがって、送信を受信するのに利用可能であり、情報を宛先に伝搬することが可能である隣接ノードを識別してもよい。そして、ノードは、識別された隣接ノードに情報を送信してもよい。

概要

背景

本願は、2011年11月11日に出願され、および、「ノード可用性に基づく通信ルーティング」と題する欧州特許出願第1118890.4号の優先権を主張するものであり、上記出願は参照により本明細書に組み込まれる。

メッシュネットワークなどの通信ネットワークは、種々の異なるデバイスを接続するために使用されている。例えば、メッシュネットワークは、ユーティリティメータセルラリレー変圧器、および/またはノードを接続するために、ユーティリティ産業で採用されてきた。メッシュネットワークにおけるノードは、主として、隣接ノードからデータを受信し、および、他の、隣接ノードに中継もしくは伝搬することが可能である。

従来の有線ネットワークでは、ソースと宛先との間の最も少ないホップ数に基づいてメッセージをルーティングするルーティングメトリック(routing metric)が使用されることがある。しかしながら、無線メッシュネットワークでは、ノード間のデータレートは、1つのリンクから別のリンクへと大きく変化することがある。このデータレートの変動は、メッシュネットワークが、異なる特徴および能力(capability)を有する複数の異なる世代のノードを含むことが多いという事実に少なくとも部分的に起因することがある。例えば、異なる世代のノードは、異なる変調技術および/またはデータレートを採用することがあり、または、採用することが可能である。このことは、とりわけ、ノードが時間とともに次第にサービスに置かれ、および、比較的長いライフサイクル(例えば、20年以上)、当該分野に存続することが予想されるユーティリティメッシュネットワークに当てはまる。一般に、より新たな世代のノードは、旧世代のノードよりも追加的な変調およびより高いデータレートの能力がある。

加えて、複数の異なるノードが同時に異なるチャネル上で送信しているマルチチャネルネットワークケースでは、一部の宛先ノードは、異なるチャネル上で送信または受信することにビジー(busy)であることを理由に、それらに対して意図された送信をミス(miss)してしまうことがある。従来では、別のデバイスを通信しているビジーな宛先デバイスにメッセージを送信するノードは、宛先デバイスから応答を受信しないであろう。そのケースでは、メッセージを送信しているノードは、粗悪なリンク品質(poor link quality)を理由に、衝突を理由に(すなわち、同時に同一のチャネル上の複数の送信)、または、宛先デバイスが単に、別のチャネル上で別のデバイスと通信するのにビジーであったことを理由に、送信が失敗したかを知る方法を有さない。

したがって、既存のルーティングメトリックは、複数の異なる世代のノードまたは異なる能力を有するノードを含む異種(heterogeneous)マルチチャネル無線メッシュネットワーク内で送信をルーティングする効果的な方法を提供しない。

概要

ノードは、宛先に送信されることになる情報を受信する。情報を受信すると、ノードは、ビジーデバイスリストクエリして、1つまたは複数の隣接ノードの可用性を判定してもよい。そして、ノードは、ビジーデバイスリストにしたがって、送信を受信するのに利用可能であり、情報を宛先に伝搬することが可能である隣接ノードを識別してもよい。そして、ノードは、識別された隣接ノードに情報を送信してもよい。

目的

RFフロントエンド202は、アンテナによって提供され、および、ノード102の1つもしくは複数から取得される信号を同調し、ならびに/または、減衰するなどの機能を提供する

効果

実績

技術文献被引用数
1件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

マルチチャネル通信ネットワークノードの制御の下、宛先に送信されることになる情報を受信するステップと、前記ノードのメモリにおいて維持されたビジーデバイスリストクエリするステップであって、前記ビジーデバイスリストは、1つまたは複数の隣接ノード可用性に関する情報を含んでいる、ステップと、前記ビジーデバイスリストにしたがって、送信を受信するのに利用可能であり、および、前記情報を前記宛先に伝搬することが可能な隣接ノードを識別するステップと、前記情報を前記識別された隣接ノードに送信するステップとを備えたことを特徴とする方法。

請求項2

前記情報を受信するステップは、前記情報が前記宛先に送信されることになることのインジケーションとともに、前記情報を隣接ノードから受信するステップを備えていることを特徴とする請求項1に記載の方法。

請求項3

前記情報を受信するステップは、前記ノードのローカル計測モジュールから前記情報を受信するステップを備えており、前記情報は、前記宛先に送信されることになるリソース消費データを含んでいることを特徴とする請求項1に記載の方法。

請求項4

前記ビジーデバイスリストは、前記ノードの媒体アクセス制御(MAC)サブレイヤにおいて維持されることを特徴とする請求項1に記載の方法。

請求項5

前記マルチチャネル通信ネットワークの制御チャネル上で前記ノードによってオーバーヒアされたメッセージに含まれるリザベーション情報に基づいて、前記ビジーデバイスリストを更新するステップをさらに備えたことを特徴とする請求項1に記載の方法。

請求項6

前記ノードによってオーバーヒアされた前記メッセージは、前記マルチチャネル通信ネットワークの他のノードにアドレス指定された送信要求RTS)メッセージ、および/または、前記マルチチャネル通信ネットワークの他のノードにアドレス指定された送信可CTS)メッセージを含んでいることを特徴とする請求項5に記載の方法。

請求項7

前記マルチチャネル通信ネットワークの制御チャネル上でリスンするステップと、前記制御チャネル上で他のノードによって送信され、および/または、他のノードに向けられたメッセージをオーバーヒアするステップであって、前記オーバーヒアされたメッセージは、前記他のノードの非可用性および非可用性の期間を示している、ステップと、前記オーバーヒアされたメッセージに基づいて、前記他のノードの非可用性および非可用性の期間を含むように、前記ビジーデバイスリストを更新するステップとをさらに備えたことを特徴とする請求項1に記載の方法。

請求項8

前記情報を前記識別された隣接ノードに送信するステップは、制御チャネル上で送信要求(RTS)メッセージを前記識別された隣接ノードに送信するステップであって、前記RTSメッセージは、送信されることになる情報のサイズ、および、前記情報が送信されることになるデータチャネルを示している、ステップと、送信可(CTS)メッセージを前記識別された隣接ノードから受信するステップであって、前記CTSメッセージは、前記識別された隣接ノードが前記情報を受信することに利用可能であることと、前記情報が送信されることになる前記データチャネルが受理可能であることの確認、または、前記情報を送信する代替データチャネルの指定と、前記情報の前記サイズおよび前記ノードと前記識別された隣接ノードとの間の送信の最大データレートに基づいている、前記情報の送信の予想される時間と、を示している、ステップと、前記CTSメッセージにおいて確認された前記データチャネル、または、前記CTSメッセージにおいて指定された前記代替データチャネル上で、前記情報を前記識別された隣接ノードに送信するステップとを備えていることを特徴とする請求項1に記載の方法。

請求項9

前記ノードは、スマートユーティリティメータを備えていることを特徴とする請求項1に記載の方法。

請求項10

マルチチャネル通信ネットワークのノードの1つまたは複数のコンピュータ可読媒体であって、前記媒体は、前記ノードの1つまたは複数のプロセッサによって実行されると、前記ノードが請求項1乃至9のいずれか一項に記載の方法を実行するように構成する命令を格納していることを特徴とする媒体。

請求項11

ネットワークコンピューティングデバイスであって、1つまたは複数のプロセッサと、前記1つまたは複数のプロセッサに通信可能に結合されたメモリと、前記ネットワークコンピューティングデバイスの前記メモリにおいて維持されたビジーデバイスリストであって、前記ビジーデバイスリストは、マルチチャネル通信ネットワークの他のネットワークコンピューティングデバイスの非可用性および非可用性の期間を示している、ビジーデバイスリストと、前記メモリに格納され、および、前記ビジーデバイスリストに少なくとも部分的に基づいて前記ネットワークコンピューティングデバイスからの通信をルーティングするように前記1つまたは複数のプロセッサによって実行可能なルーティングモジュールとを備えたことを特徴とするネットワークコンピューティングデバイス。

請求項12

複数の異なるチャネル上で通信を送信および受信することが可能なマルチチャネル無線と、前記マルチチャネル通信ネットワークの所定の周波数ホッピングパターンにしたがって、前記複数の異なるチャネル間で切替わるように構成された周波数ホッピングモジュールとをさらに備えたことを特徴とする請求項11に記載のネットワークコンピューティングデバイス。

請求項13

前記ルーティングモジュールは、前記マルチチャネル通信ネットワークの制御チャネル上で、前記ネットワークコンピューティングデバイスによってオーバーヒアされたメッセージに含まれるリザベーション情報に基づいて、前記ビジーデバイスリストを更新するようにさらに構成されており、前記リザベーション情報は、ビジーであるネットワークコンピューティングデバイスのインジケーション、および、ネットワークコンピューティングデバイスがビジーとなる機関を含んでいることを特徴とする請求項11に記載のネットワークコンピューティングデバイス。

請求項14

前記メモリに格納され、ならびに、前記ネットワークコンピューティングデバイスと1つまたは複数の他のネットワークコンピューティングデバイスとの間のリンクリンク品質を判定し、1つまたは複数のリンクのリンク品質が所定の閾値品質を満たすかを判定したことに応答して、前記ネットワークコンピューティングデバイスとそれぞれのネットワークコンピューティングデバイスとの間の前記1つまたは複数のリンクを適格とし、および、適格とされたリンクのリストを前記ネットワークコンピューティングデバイスの前記メモリに格納するように前記1つまたは複数のプロセッサによって実行可能である適格化モジュールをさらに備えたことを特徴とする請求項11に記載のネットワークコンピューティングデバイス。

請求項15

前記メモリに格納され、および、前記ネットワークコンピューティングデバイスの物理ロケーションからリソース消費データを収集するように前記1つまたは複数のプロセッサによって実行可能である計測モジュールをさらに備えており、前記リソース消費データは、電気消費データ、水道消費データ、および/または、天然ガス消費データを備えていることを特徴とする請求項11に記載のネットワークコンピューティングデバイス。

技術分野

0001

本出願は、通信ルーティング技術に関する。

背景技術

0002

本願は、2011年11月11日に出願され、および、「ノード可用性に基づく通信のルーティング」と題する欧州特許出願第1118890.4号の優先権を主張するものであり、上記出願は参照により本明細書に組み込まれる。

0003

メッシュネットワークなどの通信ネットワークは、種々の異なるデバイスを接続するために使用されている。例えば、メッシュネットワークは、ユーティリティメータセルラリレー変圧器、および/またはノードを接続するために、ユーティリティ産業で採用されてきた。メッシュネットワークにおけるノードは、主として、隣接ノードからデータを受信し、および、他の、隣接ノードに中継もしくは伝搬することが可能である。

0004

従来の有線ネットワークでは、ソースと宛先との間の最も少ないホップ数に基づいてメッセージをルーティングするルーティングメトリック(routing metric)が使用されることがある。しかしながら、無線メッシュネットワークでは、ノード間のデータレートは、1つのリンクから別のリンクへと大きく変化することがある。このデータレートの変動は、メッシュネットワークが、異なる特徴および能力(capability)を有する複数の異なる世代のノードを含むことが多いという事実に少なくとも部分的に起因することがある。例えば、異なる世代のノードは、異なる変調技術および/またはデータレートを採用することがあり、または、採用することが可能である。このことは、とりわけ、ノードが時間とともに次第にサービスに置かれ、および、比較的長いライフサイクル(例えば、20年以上)、当該分野に存続することが予想されるユーティリティメッシュネットワークに当てはまる。一般に、より新たな世代のノードは、旧世代のノードよりも追加的な変調およびより高いデータレートの能力がある。

0005

加えて、複数の異なるノードが同時に異なるチャネル上で送信しているマルチチャネルネットワークケースでは、一部の宛先ノードは、異なるチャネル上で送信または受信することにビジー(busy)であることを理由に、それらに対して意図された送信をミス(miss)してしまうことがある。従来では、別のデバイスを通信しているビジーな宛先デバイスにメッセージを送信するノードは、宛先デバイスから応答を受信しないであろう。そのケースでは、メッセージを送信しているノードは、粗悪なリンク品質(poor link quality)を理由に、衝突を理由に(すなわち、同時に同一のチャネル上の複数の送信)、または、宛先デバイスが単に、別のチャネル上で別のデバイスと通信するのにビジーであったことを理由に、送信が失敗したかを知る方法を有さない。

0006

したがって、既存のルーティングメトリックは、複数の異なる世代のノードまたは異なる能力を有するノードを含む異種(heterogeneous)マルチチャネル無線メッシュネットワーク内で送信をルーティングする効果的な方法を提供しない。

0007

添付図面を参照して、発明の詳細な説明が示される。図面では、参照番号の最も左の桁が、参照番号が最初に現れる図を識別する。異なる図面における同一の参照番号の使用は、類似のもしくは同一の項目を示す。

図面の簡単な説明

0008

複数の異なる能力を有するノード間で送信を効果的にルーティングすることができる、マルチチャネル無線メッシュネットワークの例示的なアーキテクチャの図である。
図1のアーキテクチャの例示的なノードの追加的な詳細を示す図である。
ネットワークのノード間のリンクの品質にしたがって、マルチチャネル無線メッシュネットワークにおいて送信をルーティングする例示的な方法を示すフローチャートである。
マルチチャネル無線メッシュネットワークのリンクの品質を判定する例示的な方法の信号フローチャートである。
マルチチャネル無線メッシュネットワークにおいて送信をルーティングするためのビジーなデバイスリストを採用する例示的な方法を示すフローチャートである。
ノードがデータを別のノードに送信することを望んでいることを示すのに使用することができる送信要求メッセージ(request-to-send message)の例示的なフレーム構造の図である。
ノードがデータを受信するのに利用可能であることを示すのに使用することができる送信可メッセージ(clear-to-send message)の例示的なフレーム構造の図である。

実施例

0009

概要
上述したように、既存のルーティングメトリックは、マルチチャネル無線メッシュネットワーク内で送信をルーティングする効果的な方法を提供しない。例えば、既存のルーティングメトリックは、送信データレートがリンクからリンクへと変化することがあるように、ノードが異なる能力を有する異種無線メッシュネットワークにおいて通信をルーティングするのに適していない。本明細書で使用されるように、「リンク」は無線周波数(RF)によってなど、ネットワークの2つのノード間での直接送信パス(別のノードを通じて渡すことなく)を指す。2つのノード間のリンクに渡ってのデータレートは、少なくとも部分的には、2つのノードの送信能力(例えば、互換性のある変調技術およびデータレート)に依存する。このように、リンクを渡っての最大データレートは、リンクの最も遅いノードの能力によって制限される。

0010

本願は、異種無線メッシュネットワークのノード間で高度に(intelligently)通信をルーティングするための技術を説明する。例えば、本願は、ネットワークのノード間でリンクの品質を判定し、および、当該判定されたリンクの品質に少なくとも部分的に基づいて通信をルーティングすることを説明する。

0011

従来のルーティングメトリックはまた、主として、宛先ノードが、異なるチャネル上で送信または受信することにビジーであることを理由に、宛先ノードに対して意図された送信をミスしてしまうことがある、いわゆる「ミシンデスティネーション問題(missing destination problem」を考慮しない。従来のルーティングメトリックを採用するときに、意図された宛先ノードから応答を受信しないノードは、衝突が発生し、および、コンテンションウィンドウのサイズ(すなわち、ノードがメッセージを再送信する前に待機する平均時間量)が増大したと考えることがある。この増大した待機時間は、不必要な遅延およびその意図された宛先への送信を伝搬する非効率性をもたらすことがある。

0012

本願はまた、1つまたは複数の隣接ノードに対する可用性情報(availability information)を含む、各ノードに対するビジーデバイスリストを維持することを説明する。通信は、ビジーデバイスリストにおいて維持された隣接ノードの可用性情報に少なくとも部分的に基づいて、ルーティングされてもよい。

0013

したがって、本願において示される種々の実施形態では、送信は、リンク品質(例えば、適格とされた(qualified)リンクのリストに基づいて)、隣接ノードの可用性(例えば、ビジーデバイスリストに基づいて)、またはその両方に基づいて、マルチチャネルメッシュネットワークなどの通信ネットワークにおいてルーティングされてもよい。

0014

ルーティング技術は、複数のノードを含むユーティリティメッシュネットワークのコンテキストで示される。ユーティリティメッシュネットワークのノードは、例えば、スマートユーティリティメータ(例えば、電気ガスおよび/または水道メータ)、センサ(例えば、温度センサウェザーステーション(weather stations)、周波数センサなど)、制御デバイス、変圧器、ルータサーバ、リレー(例えば、セルラリレー)、スイッチ、バルブ、および、他のネットワークデバイスを含んでもよい。ルーティング技術がユーティリティメッシュネットワークのコンテキストで示されるが、ルーティング技術は追加的に、または、代替的に、他のネットワークおよび/もしくは他の応用例に適用可能であってもよい。このように、他の実装において、ノードは、通信ネットワークに結合され、ならびに、データを送信および/または受信することが可能な任意のデバイスを含んでもよい。

0015

複数のおよび多様な実装および実施形態が、以下、「リンク品質に基づくルーティング」および「ノード可用性に基づくルーティング」の概要から始まって示される。これらの概要は、本明細書で示されるルーティング技術を実装するのに使用可能な「例示的なアーキテクチャ」および「例示的なノード」の詳細に従う。次に、本願は、リンク品質に基づくルーティングの例示的なプロセス」および「ノード可用性に基づくルーティングの例示的なプロセス」の追加的な詳細を示す。例示的なルーティングプロセスの詳細な議論に従って、本願は、本明細書で説明されるようなルーティング方法を実装するのに使用することができるいくつかの「例示的なプロトコルデータユニットPDU)」の詳細を含む。最後に、本願は、簡潔な「結論」で結論づける、この概要およびセクションの冒頭を含む以下のセクションは、単に実装および実施形態を例示するものであり、特許請求する範囲を制限するものと解釈すべきではない。

0016

<リンク品質に基づくルーティングの概要>
1つの例示的な実施形態では、本願は、マルチチャネルユーティリティネットワークなどの通信ネットワークのノード間のリンクの品質を判定し、および、判定されたリンクの品質に少なくとも部分的に基づいて通信をルーティングすることを示す。この例では、ノードは、ノードと複数の隣接ノードとの間のリンク品質を判定する。複数の隣接ノードの各々に対し、ノードは、ノードとそれぞれの隣接ノードとの間の判定されたリンク品質を、所定の閾値品質と比較する。リンク品質が所定の閾値品質を満たす場合は、ノードはリンクを適格とし(qualify)、および、当該リンクを、閾値リンク品質を満たす適格とされたリンクのリストに追加してもよい。そして、ノードは、適格とされたリンクを有するノードとの隣接ノードに通信をルーティングしてもよい。

0017

ノードは、ノードと1つまたは複数のその隣接ノードとの間のリンクの品質を判定してもよい。一例では、ノードが比較的少数の隣接ノード(例えば、10より少ない)を有している場合、ノードは、当該ノードとその隣接ノードのすべてとの間のリンクの品質を判定してもよい。代わりに、ノードが多数の隣接ノードを有している場合、ノードは自身とその隣接ノードのサブセットとの間のリンク品質を判定してもよい。一例では、ノードは、当該ノードが閾値リンク品質を満たす所定の数のリンク(例えば、5、10、20など)を判定するまで、その隣接ノードとのリンクの品質を判定することを継続してもよく、その結果、ノードに対する十分な数の良好な通信パス保証する。

0018

ノードは、リンク上の隣接ノードとの通信のシリーズ(series)を交換することによって、隣接ノードとのリンクの品質を判定してもよい。例えば、一実施形態では、ノードは、送信要求RTS:request-to-send)メッセージを隣接ノードに送信してもよい。送信要求メッセージは、テストする通信チャネルシーケンスを指定してもよい。例えば、テストされることになる通信チャネルのシーケンスは、テストするチャネル番号、テストするチャネル間のステップ間隔、および、テストするチャネルの数を始める(begin)ことによって、指定されてもよい。それに応じて、ノードは隣接ノードから、当該隣接ノードが送信を受信するのに利用可能であることを示す送信可CTS:clear-to-send)メッセージを受信してもよい。そして、ノードは、テストする通信チャネルのシーケンスにしたがって、隣接ノードにテストデータパケットを送信することによって、ノードとそれぞれの隣接ノードとの間の通信チャネルのシーケンスをテストすることを進めてもよい。テストデータパケットを受信すると、隣接ノードは、通信チャネルの同一のシーケンスにしたがって、テストデータパケットを送信し返してもよい。テストデータパケットの各々は、リンクを通じた送信の時間におけるコストのインジケーションを含んでもよい。

0019

隣接ノードからテストデータパケットを受信すると、ノードは、通信チャネルのシーケンスのテストに基づいて、ノードと隣接ノードとの間のリンク品質を算出してもよい。ノードはまた、ノードが隣接ノードから受信した多数のテストデータパケットを含む確認パケットを送信してもよい。隣接ノードは、確認パケットを使用して、ノードとそれぞれの隣接ノードとの間のリンク品質を評価してもよい。リンク品質が所定の閾値品質を満たす場合は、ノードはリンクを適格とし、および、閾値リンク品質を満たす適格とされたリンクのリストに当該リンクを追加してもよい。リンクは、通信チャネルのすべてのまたはその一部に対して適格とされてもよい。例えば、チャネルダイバシティを促進して他の隣接ノードからの干渉および衝突の可能性を減少させるために、リンクはチャネルの一部に対して適格とされてもよい。また、例えば、1つまたは複数のチャネルがテストデータの交換の間に発見されて、干渉を経験し、または、粗悪な品質の送信を有していた場合は、ノードはチャネルの一部に対して適格とされてもよい。一部の例では、適格とされたリンクのリストは、ノードとそれぞれの隣接ノードとの間のリンクの相対品質にしたがって、隣接ノードを順位付けることを含んでもよい。このケースでは、ノードは、リンクの相対品質に少なくとも部分的に基づいて、その隣接ノードに通信をルーティングしてもよい(例えば、最も高い品質を有するリンクによってノードに接続された利用可能な隣接ノードに通信をルーティングする)。

0020

種々の異なるメトリックが使用されて、ノード間のリンク品質を算出してもよい。1つの特定の例では、リンク品質は、リンクにわたる(across)通信の予想される送信時間(ETT:expected transmission time)に基づいて算出されてもよい。ETTは、式1に基づいて算出されてもよい。

0021

0022

Pは、リンク上のロスレート(loss rate)であり、Pfは、データパケットが隣接ノードに到達することに成功する確立(probability)であり、Prは、隣接ノードからの確認が受信されるのに成功する確立であり、Sは、データパケットのパケットサイズ(例えば、ビットまたは他の単位)であり、および、Bは、2つのノード間のリンクの帯域幅(例えば、ビット/秒または他の単位)である。

0023

例えば、2つのノードxおよびyを考えると、ノードxに対するPfは、ノードxからノードyによって受信されたテストデータパケットの数を、ノードxによって送信されたテストデータパケットで割ったものとなる。ノードxに対するPrは、ノードyからノードxによって受信されたテストデータパケット数を、ノードyによって送信されたテストデータパケットで割ったものとなる。ノードyに対するPfおよびPrは、同様の方法で計算される。式1は、リンク品質を測定するのに使用されてもよいルーティングメトリックの1つの例にすぎず、他の例では、種々の他のメトリックがリンク品質を測定するのに使用されてもよい。

0024

RTSを受信した後に、隣接ノードが通信を受信するのに利用可能でない場合は(例えば、隣接ノードが既に前もってスケジューリングされた通信を有している場合)、隣接ノードは、送信不可NCTS:not-clear-to-send)メッセージを送信し返してもよい。隣接ノードが別のチャネル上で通信するのにビジーである場合は、隣接ノードはRTSを受信しなくてもよく、したがって、応答しない。ノードがNCTSを受信し、または、応答を受信しない場合は、当該ノードは一定時間待機し、ならびに、異なる隣接ノードを再び試み、および/または、試みてもよい。

0025

<ノード可用性に基づくルーティングの概要>
別の例示的な実施形態では、本願は、1つまたは複数の隣接ノードに対する可用性情報を含む、各ノードに対するビジーデバイスリストを維持し、ならびに、隣接ノードの可用性に基づいて送信をルーティングすることを示す。この例では、ノードは宛先に送信されることになるいくつかの情報(例えば、リソース消費情報、レポートアラートステータスメッセージソフトウェアファームウェアアップデートなど)を受信する。情報は、隣接ノードからまたはシステムもしくはノード自体のコンポーネント(例えば、ローカルセンサまたは計測モジュール)から受信されてもよい。情報を受信すると、ノードは、ビジーデバイスリストをクエリして、1つまたは複数の隣接ノードの可用性を判定してもよい。そして、ノードは、ビジーデバイスリストにしたがって、送信を受信することに利用可能であり、および、情報を宛先に伝搬することが可能な隣接ノードを識別してもよい。そして、ノードは、情報を識別された隣接ノードに送信してもよい。

0026

ビジーデバイスリストは一般に、ノード自体のローカルメモリにおいて維持される(例えば、ノードの媒体アクセス制御(MAC)サブレイヤにおいて)。しかしながら、一部の実施形態では、ビジーデバイスリストは、追加的にもしくは代替的に、ネットワーク上の別のロケーションにおいて維持されてもよい(例えば、親ノード、セルラルータ、リレー、またはネットワークストレージデバイスなど)。

0027

ビジーデバイスリストは、マルチチャネル通信ネットワークの制御チャネル上のノードによってオーバーヒアされた(overheard)メッセージに含まれるリザベーション情報(reservation information)に基づいて、生成され、維持され、および、更新されてもよい。リザベーション情報は、ビジーであるノード、および、それらがビジーである時間を識別してもよい。このリザベーション情報は、例えば、マルチチャネル通信ネットワークの他のノードにアドレス指定された送信要求(RTS)メッセージ、および/またはマルチチャネル通信ネットワークの他のノードにアドレス指定され送信可(CTS)メッセージを含む、種々のメッセージに含まれてもよい。

0028

<例示的なアーキテクチャ>
図1は、リンク品質および/またはノードの可用性にしたがって、送信をルーティングすることができる、マルチチャネル無線メッシュネットワークの例示的なアーキテクチャ100の図である。アーキテクチャ100は、直接通信パスすなわち「リンク」を介して互いに通信可能に結合された複数のノード102A、102B、102C...102N(総称してノード102と称される)を含む。この例では、Nは、ワイドエリアネットワークWAN)、メトロポリタンネットワーク(MAN)、ローカルエリアネットワーク(LAN)、ネイバーフッドエリアネットワーク(NAN)またはパーソナルエリアネットワーク(PAN)などの自立的ルーティングエリア(ARA)におけるノードの数を表す。

0029

上述したように、用語「リンク」は、2つのノード間の直接通信パス(別のノードを通らずまたは別のノードによって伝搬されない)を指す。各リンクは、ノードがデータを送信または受信することが可能な複数のチャネルを表してもよい。複数のチャネルの各々は、当該複数のチャネルの各々に対して同一または異なる周波数範囲によって定義されてもよい。一部のインスタンスでは、複数のチャネルは、RFチャネルを備える。複数のチャネルは、制御チャネルおよび複数のデータチャネルを備えてもよい。一部のインスタンスでは、制御チャネルは、ノード間において1つまたは複数のメッセージを通信して、データを転送するのに利用されることになるデータチャネルの1つを特定するのに利用される。一般に、制御チャネル上の送信は、データチャネル上の送信と比較して短い。

0030

ノード102の各々は、例えば、スマートユーティリティメータ(例えば、電気、ガス、および/または水道メータ)、センサ(例えば、温度センサ、ウェザーステーション、周波数センサなど)、制御デバイス、変圧器、ルータ、サーバ、リレー(例えば、セルラリレー)、スイッチ、バルブ、それらの組合せ、または、通信ネットワークに結合可能であり、ならびに、データを送信および/もしくは受信することが可能な任意のデバイス、などの種々の従来のコンピューティングデバイスのいずれかとして実装されてもよい。

0031

この例では、ノード102はまた、インターネットなどのバックホールネットワーク106へのARAの接続ポイントとしてサービスするエッジデバイス(edge device)(例えば、セルラリレー、セルラルータ、エッジルータDODAGルートなど)を介して中央オフィス104と通信するように構成される。例示された例では、ノード102Aは、ARAの他のノード102B乃至102Nから中央オフィス104へ、および中央オフィス104から、ネットワーク10を介して通信を中継するセルラリレーとしてサービスする。

0032

ノード102Cは、ノード102の各々の代表であり、ならびに、無線108およびプロセシングユニット110を含む。無線108は、複数のチャネル/周波数のうちの1つまたは複数を介して無線周波数(RF)信号を送信および/または受信するように構成されたRF送受信機を備える。一部の実施形態では、ノード102の各々は、各通信リンクの制御チャネルおよび複数のデータチャネルなどの、複数の異なるチャネル上でデータを送信および受信するように構成された単一無線108を含む。無線108はまた、複数の異なる変調技術、データレート、プロトコル信号強度、および/または電力レベルを実装するように構成されてもよい。アーキテクチャ100は、ノード102が、異なるタイプのノード(例えば、スマートメータ、セルラリレー、センサなど)、異なる世代もしくはモデルのノード、ならびに/あるいは、異なるチャネル上で、または、異なる変調技術、データレート、プロトコル、信号強度および/もしくは電力レベルを使用して送信することが可能なノードを含んでもよいという点で、ノードの異種ネットワークを表してもよい。

0033

プロセシングユニット110は、メモリ114と通信可能に結合された1つまたは複数のプロセッサ112を含んでもよい。メモリ114は、プロセッサ112上で実行可能であり、種々の機能を実装する1つまたは複数のソフトウェアおよび/またはファームウェアモジュールを格納するように構成されてもよい。モジュールは、本明細書においてプロセッサ上で実行可能なソフトウェアおよび/またはファームウェアとして示されているが、他の実施形態では、モジュールの一部もしくはすべては、示された機能を実行するハードウェア(例えば、ASIC、特殊プロセシングユニットとして)全体として、または、その一部として実装されてもよい。

0034

図1の実施形態では、メモリ114は、ルーティングモジュール116、適格化モジュール(qualification module)118およびビジーデバイスリストモジュール120を含む。ルーティングモジュール116は、適格化モジュール118によって判定されたノード102間のリンクの品質、ビジーデバイスリストモジュール120によって判定されたノード102の可用性、および/または、1つまたは複数の他のファクタに基づいて、ARAのノード102間で送信をルーティングするように構成される。これらおよび他のファクタに基づいて、ルーティングモジュール116がどのように通信をルーティングするかの追加の詳細は、図2乃至5の議論において以下に提供される。

0035

適格化モジュール118は、ノード102間のリンクの品質を判定するように構成される。例示された例では、ノード102Cの適格化モジュール118は、ノード102Cとその隣接ノード102Aおよび102Cとの間のリンクが、品質の閾値レベルを満たし、したがって、「適格とされたリンク」(qualified links)として指定されると判定している。一方で、適格化モジュール118は、ノード102Cとその隣接ノード102Bとの間のリンクの品質を判定しておらず、または、適格化モジュール118は、ノード102Cとその隣接ノード102Bとの間のリンクが品質の閾値レベルを満たしていないと判定している(例えば、リンクは干渉を経験し、弱くもしくは減退した信号を有しており、または、送信に対して適切でない)。したがって、ノード102Cとその隣接ノード102Bとの間のリンクは、図1において、適格とされていないリンク(unqualified link)として指定される。

0036

ビジーデバイスリストモジュール120は、ノード102の可用性を判定し、ならびに、ビジーであるノードおよびそれらがビジーである期間(duration)をリスト化することを維持するように構成される。例示された例では、ビジーデバイスリストモジュール120は、ノード102Bがノード102Aにデータを送信するのにビジーであり、したがって、ノード102Cからの送信を受信することが利用可能でないことを示している。

0037

メモリ114は、コンピュータ可読媒体を備えてもよく、ならびに、ランダムアクセスメモリ(RAM)などの揮発性メモリ、および/またはリードオンリメモリ(ROM)もしくはフラッシュRAMなどの不揮発性メモリ形式をとってもよい。コンピュータ可読媒体は、コンピューティングデバイスの1つもしくは複数のプロセッサによる実行のためのコンピュータ可読命令データ構造プログラムモジュールもしくは他のデータなどの、情報の格納のための任意の方法もしくは技術において実装される、揮発性および不揮発性着脱可能および着脱不能媒体を含む。コンピュータ可読媒体の例は、相変化メモリ(PRAM:phase change memory)、静的ランダムアクセスメモリ(SRAM)、動的ランダムアクセスメモリ(DRAM)、もしくは他のタイプのランダムアクセスメモリ、リードオンリメモリ(ROM)、電気的消去可能リードオンリメモリ(EEPROM)、フラッシュメモリもしくは他のメモリ技術コンパクトディスクリードオンリメモリ(CD−ROM)、デジタル多用途ディスク(DVD)、もしくは他の光学記憶装置磁気カセット磁気テープ磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、コンピューティングデバイスによるアクセスのための情報を格納するのに使用することができる任意の他の非送信媒体を含むが、それらに限定されない。本明細書で定義されるように、コンピュータ可読媒体は、変調データ信号および搬送波などの通信媒体を含まない。

0038

ネットワーク106は、それ自体が無線もしくは有線ネットワークまたはそれらの組合せを備えることができるバックホールネットワークを表している。ネットワーク106は、互いに相互接続された個々のネットワークの集合であってもよく、ならびに、単一の大規模ネットワーク(例えば、インターネットまたはイントラネット)として機能していてもよい。さらに、個々のネットワークは、無線もしくは有線ネットワークまたはそれらの組合せであってもよい。

0039

中央オフィス104は、サーバ、パーソナルコンピュータラップトップコンピュータなどの1つまたは複数のコンピューティングデバイスによって実装されてもよい。1つまたは複数のコンピューティングデバイスは、メモリに通信可能に結合された1つまたは複数のプロセッサを備えてもよい。一部の例では、中央オフィス104は、1つまたは複数のノード102から受信されたデータの処理、分析、格納および/または管理を実行する、集中型メータデータ管理システム(centralized meter data management system)を含む。例えば、中央オフィス104は、スマートユーティリティメータ、センサ、制御デバイス、ルータ、レギュレータ、サーバ、リレー、スイッチ、バルブおよび/または他のノードから取得されたデータを処理、分析、格納、および/または管理してもよい。図1の例は、単一のロケーションにおける中央オフィス104を示しているが、一部の例では、中央オフィスは、複数のロケーション間で分散されてもよく、および/または、完全に除外されてもよい(例えば、高度非集中型分散コンピューティングプラットフォーム)。

0040

<例示的なノード>
図2は、図1のノード102Cの例の追加の詳細を示す図である。この例では、無線108は、RFフロントエンド202およびベースバンドプロセッサ204に結合されたアンテナ200を含む。RFフロントエンド202は、送信および/または受信機能を提供してもよい。RFフロントエンド202は、アンテナによって提供され、および、ノード102の1つもしくは複数から取得される信号を同調し、ならびに/または、減衰するなどの機能を提供する、高周波数アナログ、および/もしくは、ハードウェアコンポーネントを含んでもよい。RFフロントエンド202は、信号をベースバンドプロセッサ204に提供してもよい。

0041

1つの例では、ベースバンドプロセッサ204のすべてもしくは一部は、ソフトウェア(SW)定義無線(software defined radio)として構成されてもよい。1つの例では、ベースバンドプロセッサ204は、周波数および/またはチャネル選択機能を無線108に提供する。例えば、SW定義無線は、プロセッサもしくは特定用途向け集積回路(ASIC)または他の組み込みコンピューティングデバイスによって実行されるソフトウェアで実装される、ミキサフィルタ増幅器変調器復調器ディテクタなどを含んでもよい。SW定義無線は、プロセッサ112、ならびに、メモリ114において定義されおよび格納されたソフトウェアを利用してもよい。代わりに、無線108は、アナログコンポーネントを少なくとも部分的に使用して実装されてもよい。

0042

プロセシングユニット110はまた、時間を維持するように構成されたクロック206を含んでもよい。クロック206はまた、1つまたは複数のカウントアップまたはカウントダウンタイマを提供するように構成されてもよい。このようなタイマは、複数の通信チャネル間での周波数ホッピングに使用されてもよい。

0043

周波数ホッピングモジュール208は、ベースバンドプロセッサ204およびクロック206と通信するように構成されてもよい。1つの例では、周波数ホッピングモジュール208は、時間情報を取得し、および/または、クロック206に周波数ホッピングタイマを設定するように構成される。このような時間情報および/またはタイマは、異なるチャネルもしくは周波数を「ホッピング」または同調するときを周波数ホッピングモジュール208に示す。加えて、周波数ホッピングモジュール208は、SW定義無線または無線108の他のコンポーネントを命令して、実際の周波数変更(frequency changes)を実行するように構成されてもよい。したがって、周波数ホッピングモジュール208は、合意した(agreed upon)周波数間で、合意した時間で、繰り返しシフトし、ならびに、合意した期間、および合意したプロトコルで別のノードと通信することが可能である。

0044

一部の実装では(例えば、ノードがユーティリティメータのときに)、メモリ114はまた、1つまたは複数のリソース(例えば、電気、水、天然ガスなど)の消費データ収集するように構成された計測モジュール210を含んでもよく、消費データは、最終的に中央オフィス104または他の宛先への伝搬のために、1つまたは複数の他のノード102に送信されてもよい。

0045

上述したように、メモリ114はまた、適格化モジュール118およびビジーデバイスリストモジュール120を含んでもよい。適格化モジュール118は、ノード間のリンクの品質を判定し、ならびに、適格とされたリンクリスト(qualified links list)212もしくは他のリンク品質情報レポジトリに、リンクの品質に関する情報を格納する。同様に、ビジーデバイスリストモジュール120は、ノード102の可用性を判定し、ならびに、ビジーであるノードおよびビジーとなる期間(duration)をビジーデバイスリスト214もしくは他のノード可用性データのレポジトリにリスト化することを維持する。適格とされたリンクリスト212およびビジーデバイスリスト214が、ノード102Cのローカルメモリに格納されたデータのリストであるとして示されているが、他の実施形態では、リンク品質およびノード可用性情報は、単一リストもしくはリストでない形式で格納されてもよい。さらに、一部の実施形態では、リンク品質およびノード可用性情報は、追加的にもしくは代替的に、ネットワーク上の1つまたは複数の他のロケーションにおいて(例えば、親ノード、セルラルータ、リレー、またはネットワーク記憶デバイスなど)維持されてもよい。

0046

上述したように、適格とされたリンクリスト212およびビジーデバイスリスト214は、別個のリストとして、または、1つの複合リストとして維持されてもよい。例示された例では、適格とされたリンクリスト212およびビジーデバイスリスト214は、メモリ114において複合リスト216として格納される。この図で例示されるように、この例における適格とされたリンクリスト212およびビジーデバイスリスト214は、一部の重複する情報を含む。

0047

一般に適格とされたリンクリスト212に対応する複合リスト216の一部は、鎖線領域によって区切られ、ならびに、この例では、ノードがそれとの通信リンクを有する隣接ノード(ヘッダ「Neighbors」の下(under the heading "Neighbors"))のリスト、各隣接ノードとのリンクが適格とされるかのインジケーション(ヘッダ「Qualified」の下)、各リンクに対して適格とされたチャネルのリスト(ヘッダ「Channels」の下)、ならびに、リンクの相対品質によるリンクの順位付け(ヘッダ「Rank」の下)を含む。しかしながら、他の実施形態では、適格とされたリンクリスト212は、追加のもしくは代替的な情報(例えば、リンクの相対品質スコア、各リンクの個々のチャネルの相対品質、各リンクもしくは各リンクの各チャネルに対する最大データレートなど)を含んでもよい。

0048

一般にビジーデバイスリスト214に対応する複合リスト216の一部は、鎖線領域によって区切られ、ならびに、この例では、ノードがそれとの通信リンクを有する隣接ノードのリスト(ヘッダ「Neighbors」の下)、各リンクに対して適格とされたチャネルのリスト(ヘッダ「Channels」の下)、各ノードの可用性状態(ヘッダ「Availability」の下)、ならびに、可用性状態に対応する期間(ヘッダ「Duration」の下)を含む。本明細書で使用されるように、ノードがビジーデバイスリストにおいて利用可能であるとして肯定的に示される場合(例えば、通信を受信するのにスケジューリングされ/予約された時間を有する)、または、暗に利用可能である場合(例えば、利用可能でないとして示されず、従って、利用可能であると想定されるノード)、当該ノードは送信を受信するのに「利用可能であり」もしくは「可用性を有する」。他の実施形態では、ビジーデバイスリスト214は、追加的なもしくは代替的な情報を有してもよい(例えば、ビジーノードによって実行されているオペレーションのタイプ、ビジーノードによって送信/受信されているデータのサイズなど)。

0049

ルーティングモジュール116は、適格とされたリンクリスト212において示されるようなリンク品質、ビジーデバイスリスト214において示されるような隣接ノードの可用性、または、複合リスト216を使用することの両方に基づいて、送信をルーティングしてもよい。例えば、1つの例示的なルーティングメトリックにしたがって、ノードは、最良のリンク品質ランクを有する利用可能なノードに送信をルーティングすることを試みてもよい。したがって、例示された例では、ノードNは、無期限に利用可能であり(available for an indefinite duration)、および、利用可能な最良の品質の適格とされたリンク(すなわち、最も低いランク)の両方であるので(ノードNはその最終的な宛先へ送信を伝搬することが可能であることを想定する)、ノード102Cは、チャネル5を除く(以下に述べるように、チャネル5は現在、ノードAおよびBによって使用されている)チャネル1乃至7のうちの1つの上でノードNに送信をルーティングしてもよい。この例では、ノードAは、チャネル5上でのノードBにデータを送信するのにビジーであるので、送信を受信するのにすぐには利用可能とはならず、それゆえに、ノードCは、ノードAがより高い品質のリンク(すなわちより低いランク)を有しているという事実にも関わらず、ノードAに送信をルーティングしない。また、ノードCは、チャネル5上でノードAとBとの間の送信を阻害することを回避するために、チャネル5上でノードNにルーティングしない。

0050

代替的なルーティングメトリックにしたがって、ルーティングモジュール116は、リンク品質を可用性よりも高く重み付けしてもよい。このケースでは、再び例示された実施形態を参照して、利用可能であるノードにデータを即時に送信するのではなく、ノードCは、ノードAがより高い品質(すなわち、より低いランク)のリンク品質を有していることを理由に、ノードAが利用可能になるときに、ノードAにデータを送信することを待機することを選択してもよい。さらなる別の代替では、ノードCは、ノードAが比較的短い期間に利用可能なる場合のみに、通信をノードAにルーティングすることを待機することを選択してもよい。言い換えると、通信をどこにルーティングするかの決定は、リンク品質と利用可能になるまでの期間との間のバランスをとってもよい。

0051

<リンク品質に基づくルーティングの例示的な方法>
図3は、メッシュネットワークのノード間のリンクの品質を判定し、および、リンク品質に少なくとも部分的に基づいて通信をルーティングする例示的な方法300を示している。方法300は、便宜上、図1の例示的なアーキテクチャ100を参照して示される。しかしながら、方法300は、図1の例示的なアーキテクチャ100での使用に限定されず、他のアーキテクチャおよびデバイスを使用して実装されてもよい。

0052

方法300は、ブロック302において、ノード102などのノードがノード102Nなどの隣接ノードとのリンクの品質を判定することで開始する。リンク品質の判定は、ノード102Cの適格化モジュール118などの適格化モジュールによって実行されてもよい。リンク適格化プロセス(link qualification process)の追加の詳細は、図4を参照して以下に示される。

0053

ブロック304において、ノード102Cが隣接ノード102Nとのリンクの品質を判定すると、ノード102Cの適格化モジュール118は、判定されたリンク品質を閾値リンク品質と比較する。判定されたリンク品質が閾値リンク品質を満たす場合(すなわち、閾値以上である)、ブロック306において、ノード102Cはノード102Cと隣接ノード102Nとの間のリンクを適格とし、および、当該リンクを適格とされたリンクリスト212に追加する。

0054

ブロック308において、ノード102Cは、所定の数の適格とされたリンクが存在するかを判定する。所定の数の適格とされたリンクは、ノードが有するその周辺の(immediate)隣接ノードとのリンクの数に等しくてもよく、または、所定の数の適格とされたリンクは、ノードが有するその周辺の隣接ノードとのリンクの数のすべてよりも少なくてもよい。例えば、所定の数の適格とされたリンクは、高いネットワークのトラフィックの時間の間でさえ、ノードに対する良好な通信パスを保証するのに十分な数(例えば、3、5、10など)を備えてもよい。ブロック308において、ノード102Cが所定の数の適格とされたリンクが存在しないと判定した場合、ノード102Cは、所定の数の適格とされたリンクが達成されるまで、ブロック302乃至306のオペレーションを繰り返してもよい。一方、ブロック308において、ノード102Cが所定の数の適格とされたリンクが存在すると判定した場合、ノード102Cは、ブロック310において、一部の実施形態に進み、ノード102Cと隣接ノード102A、102Bおよび102Nとの間のリンクの相対品質にしたがって、隣接ノードを順位付けしてもよい。しかしながら、他の実施形態では、順位付けオペレーション310は、省略されてもよい。

0055

ブロック312において、ノード102Cのルーティングモジュール116は、それとの適格とされたリンクを有する隣接ノードに通信をルーティングすることを開始してもよい。したがって、例示された例では、ノード102Cは、ノード102Cがノード102Aおよび102Nとの適格とされたリンクを有しているが、ノード102Bとは適格とされたリンクを有しないので、ノード102Bではなく、ノード102Aおよび102Nに通信をルーティングすることを開始してもよい。適格とされたリンクの存在に単に基づいて通信をルーティングすることに加えて、またはそれに代えて、ブロック310において、ノード102Cがリンク品質に基づいて隣接ノードを順位付けした場合、ノード102Cは、リンク品質の順位付けに基づいて、通信をルーティングしてもよい(例えば、優先度を与えて、より高い品質のリンクを介して通信を送信する)。

0056

図4は、リンクの品質に基づいてリンクを適格化する例示的な方法400の追加の詳細を示す信号フローチャートである。便宜上、方法400は、図1の例示的なアーキテクチャ100のノード102Cおよび102Nを参照して示される。しかしながら、方法400は、図1の例示的なアーキテクチャ100での使用に限定されず、他のアーキテクチャおよびデバイスを使用して実装されてもよい。

0057

図4では、ノード102Cなどのノードは、リンク上でノード102Nなどの隣接ノードと通信のシリーズを交換することによって、隣接ノードとのリンクの品質を判定してもよい。例えば、オペレーション402において、ノード102Cは、隣接ノード102Nに送信要求(RTS)メッセージを送信してもよい。送信要求メッセージは、テストする通信チャネルのシーケンスを指定してもよい。例えば、テストされることになる通信チャネルのシーケンスは、テストするチャネル番号X、テストするチャネル間のステップインターバルY、およびテストするチャネルの数Mを始める(begin)ことによって、指定されてもよい。チャネルのシーケンスは、以下の式2にしたがって、数学的に表現されてもよい。

0058

0059

式2において、kは、シーケンスにおけるチャネルの番号である(例えば、テストされる第1のチャネル)。

0060

その後、オペレーション404において、ノード102Cは、隣接ノード102Nから、隣接ノードが送信を受信するのに利用可能であることを示す送信可(CTS)メッセージを受信してもよい。オペレーション406において、ノード102Cは、テストする通信チャネルのシーケンスにしたがって、隣接ノードにテストデータパケットを送信することによって、ノード102Cとそれぞれの隣接ノード102Nとの間の通信チャネルのシーケンスをテストすることに進んでもよい。テストデータパケットを受信すると、オペレーション408において、隣接ノード102Nは、通信チャネルの同一のシーケンスにしたがって、テストデータパケットを送信し返してもよい。オペレーション408において返されたテストデータパケットの各々は、リンクを通じた送信の時間のコストと、ノード102Nがノード102Cから受信したテストデータパケットの数のインジケーションを含んでもよい。

0061

隣接ノードからテストデータパケットを受信し返すと、オペレーション410において、ノード102Cは、通信チャネルのシーケンスのテストに基づいて、ノード102Cと隣接ノード102Nとの間のリンク品質を算出してもよい。例えば、ノード102Cは、上記式1にしたがって、リンク品質を算出してもよい。代わりに、種々の他のメトリックが使用されて、リンク品質を算出してもよい。リンク品質が所定の閾値品質を満たす場合は、ノード102Cは、当該リンクを適格としてもよく、および、当該リンクを、図3を参照して上述した閾値リンク品質を満たす適格とされたリンクのリストに追加してもよい。

0062

オペレーション412において、ノード102Cはまた、ノード102Cが隣接ノード102Nから受信したテストデータパケットの番号を含む確認パケットを送信してもよい。オペレーション414において、隣接ノード102Nは、102Cによって送信された確認パケットの受信に成功したことを示す確認応答パケットをノード102Cに送信してもよい。オペレーション416において、隣接ノード102Nは、確認パケットを使用して、ノード102Cと隣接ノード102Nとの間のリンクの品質を評価してもよい(例えば、上記式1のリンク品質メトリックを使用して)。リンク品質が所定の閾値品質を満たす場合は、隣接ノード102Nは、当該リンクを適格とし、および、当該リンクを、図3を参照して上述した閾値リンク品質を満たす適格とされたリンクのリストに追加してもよい。方法400は、各ノードに対する所定の数のリンクを適格とするのに必要とされるように、何度も実行されてもよい。

0063

<ノード可用性に基づくルーティングの例示的な方法>
図5は、メッシュネットワークのノード間のリンクを適格とする例示的な方法500を示している。方法500は、便宜上、図1の例示的なアーキテクチャ100を参照して示される。しかしながら、方法500は、図1の例示的なアーキテクチャ100での使用に限定されず、他のアーキテクチャおよびデバイスを使用して実装されてもよい。

0064

方法500にしたがって、ブロック502において、ノード102Cなどのノードは、ノード102A、102Bおよび102Nなどの隣接ノードの可用性情報(すなわち、ビジー、利用可能、非利用可能など)を含むビジーデバイスリストを維持し、および、更新する。ビジーデバイスリストは、例えば、MACサブレイヤにおいて実装されてもよく、および、ノード102Cのメモリに格納されてもよい。

0065

特に、ブロック504において、ノード102Cは、制御チャネルをリスンすることによって(すなわち、無線108を制御チャネルに同調させて、制御チャネル上で送信された任意の通信を受信する)、ビジーデバイスリストを維持/更新してもよい。ブロック506において、ノード102Cは、ネットワーク上で他のノードによって送信されたRTSメッセージまたはCTSメッセージなどの1つまたは複数のメッセージをオーバーヒア(overhear)してもよい。オーバーヒアされたメッセージは、可用性情報(例えば、特定のノードが1つまたは複数の特定されたデータチャネル上でデータを送信または受信することを意図すること)を含むリザベーション情報、ならびに、期間情報(duration information)(例えば、送信されることになるデータのサイズ、送信の時間、および/または送信に対する開始時間)を含んでもよい。ブロック508において、ノード102Cは、オーバーヒアされたメッセージに関連付けられた他のノードの可用性および可用性の期間を含むように、そのビジーデバイスリストを更新してもよい。

0066

ブロック510において、ノード102Cは、宛先に送信されることになる情報(例えば、隣接ノードから伝搬される情報、ノードの自身の計測モジュールからの消費情報(consumption information))を受信してもよい。ブロック512において、ノード102Cは、ビジーデバイスリストをクエリし、ブロック514において、ビジーデバイスリストにしたがって、宛先へ情報を伝搬することに利用可能であり、および、伝搬することが可能な1つまたは複数の隣接ノードを識別する。1以上の隣接ノードがこの基準を満たす場合、ノード102Cは、1つまたは複数の他の基準(例えば、リンク品質、ネットワークトラフィックランダム選択など)に基づいて、どの隣接ノードに情報を送信するかを選択してもよい。

0067

どの隣接ノードに情報を送信するかを識別した後に、ブロック516において、ノード102Cは、識別された隣接ノードに情報を送信する。特に、ブロック518における送信プロセスの1つの例では、ノード102Cは、制御チャネル上で識別された隣接ノードにRTSメッセージを送信してもよい。RTSメッセージは、例えば、送信されることになる情報のサイズ、ノード102Cが情報を送信するのを選ぶ(prefer to)データチャネル、送信が開始される時間、および/または、送信をネゴシエートするのに有用な任意の他の情報を含んでもよい。RTSを受信した隣接ノードが利用可能である場合、ブロック520において、ノード102Cは、隣接ノードからCTSメッセージを受信する。CTSメッセージは、識別された隣接ノードが利用可能であることのインジケーション、RTSで特定されたデータチャネルの確認もしくは送信に対する代替データチャネルの指定、送信の予想される時間(データのサイズおよびリンクに渡っての最大データレートに基づいて)、および/または、送信をネゴシエートするのに有用な任意の他の情報を含んでもよい。最後に、ブロック522において、ノード102Cは、確認されたデータチャネルまたは代替データチャネル上で、識別された隣接ノードに情報を送信する。

0068

方法300、400および500は、ブロック、ならびに、ハードウェア,ソフトウェア、ファームウェアもしくはそれらの組合せで実装することができるオペレーションのシーケンスを表す論理フローチャートにおける矢印の集合として示される。ブロックが示される順序は、限定として解釈されることを意図せず、示された任意の数のオペレーションを任意の順序で組み合わせて、方法または代替の方法を実装することができる。加えて、個々のオペレーションは、本明細書で示される本発明の精神および範囲から逸脱することなく、当該方法から省略されてもよい。ソフトウェアのコンテキストにおいて、コンピュータ命令を表すブロックは、1つまたは複数のプロセッサによって実行されると、定義されたオペレーションを実行する。ハードウェアのコンテキストにおいて、ブロックは、定義されたオペレーションを実行するように構成された1つまたは複数の回路を表してもよい(例えば、特定用途向け集積回路(ASIC))。

0069

<例示的なプロトコルデータユニット(PDU)>
図6および7は、制御チャネルおよび/またはデータチャネルを介して転送することができるいくつかの例示的なプロトコルデータユニット(PDU)を示す。用語PDUは、本明細書においては、一般に任意の通信、 メッセージ、または図1に示すような通信ネットワーク内の送信を参照する(refer to)のに使用される。用語PDUは、少なくとも概念的には、オープンシステムインターコネクションOSI)モデルに基づいてもよく、および、例えば、ビット、フレームパケットセグメントなどを備えてもよい。一部のインスタンスでは、OSIモデルの1つまたは複数のレイヤは、ノード間で1つまたは複数のPDUを転送するために利用されてもよい。例えば、OSIモデルのデータリンクレイヤは、アーキテクチャ100における2つ以上のノード102間でPDUを転送するのに利用されてもよい。特定の実装では、データリンクレイヤの媒体アクセス制御(MAC)サブレイヤは、2つ以上のノード102間でPDUを転送するのに利用されてもよい。さらに、一部の実装では、PDUを転送するのに、キャリアセンス多重アクセス衝突回避(CSMA/CA)などのアクセス方法が利用されてもよい。

0070

図6は、ノードがデータを別のノードに送信することを望んでいることを示すのに使用することができる例示的な送信要求(RTS)フレーム600を示しており、図7は、ノードがデータを受信するのに利用可能であることを示すのに使用することができる例示的な送信可(CTS)フレーム700を示している。一部の例では、RTSメッセージを受信すると、ノードは(利用可能である場合は)、CTSメッセージを送信することによって応答してもよい。この例では、RTSおよびCTSフレーム構造は、IEEE802.15.4(e)スタンダードによって部分的に定義される。しかしながら、他の例では、他のPDU構造が、RTSメッセージ、CTSメッセージ、または、マルチチャネル通信ネットワークに関連付けられたリザベーション情報を搬送する他の通信に使用されてもよい。

0071

上述したように、RTSフレーム600およびCTSフレーム700(総称して、データフレーム600および700)は、マルチチャネル通信ネットワークのノード間のリンクを適格とし、および、マルチチャネル通信ネットワークのノード間で通信をルーティングするのに使用可能な情報を含む。フレーム600および700は、便宜上、図1のアーキテクチャ100の例示的なネットワーク、ならびに、例示的な方法300、400および500を参照して示される。しかしながら、例示的なフレーム600および700は、例示的なアーキテクチャ100もしくは方法300、400および500での使用に限定されず、他のアーキテクチャおよびデバイスを使用して実装されてもよく、ならびに/または、他の方法を実行してもよい。

0072

図6を参照すると、例示的なRTSフレームが使用されて、隣接ノードに、ノードがデータを送信することを望んでおり、および、別の送信に対して利用可能でないことを通知し、ならびに、特定のデータチャネル、および、1つまたは複数の物理(PHY)パラメータ(例えば、データレートおよび/または変調技術)を意図された受信ノードとネゴシエートしてもよい。図6に示すように、RTSフレームは、以下のフィールドフレーム制御(FC)、シーケンス番号、宛先パーソナルエリアネットワーク(PAN)識別子、宛先アドレス、ソースPAN識別子、ソースアドレス補助セキュリティヘッダ(auxiliary security header)、ペイロード、および、フレームチェックシーケンスFCS)、を含む。ペイロード以外のRTSフレームの上記フィールドの詳細は、当業者にとって周知であり、本明細書においては詳細な説明は行わない。しかしながら、RTSフレームのペイロードは、上述したルーティング技術、および、他の機能を実装するためにカスタマイズされる。ペイロードは、サイズが可変であってもよく、および、例えば、1つまたは複数の以下のフィールドを含んでもよい。
Type:このフィールドは、フレームのタイプ、例えば、RTS、CTS、送信不可(NCTS:not-clear-to-send)などを示す。図6の例では、このフィールドは、フレームがRTSフレームであることを示す。
HW:このフィールドは、RTSフレームを送信するノードのハードウェアのタイプを示す。タイプは、例えば、デバイスのバージョンもしくは世代、および/または、ノードの能力を判定するのに使用可能な任意の他の情報(例えば、電池式(battery powered)、変調技術、および/またはノードによってサポートされるデータレート)を含んでもよい。
Rank:このフィールドは、RTSフレームを送信しているノードの低電力・高損失ネットワーク(RRL:Low power and Lossy networks)のランク(知っている場合)に対するルーティングプロトコルを示す。ランクは、隣接ノードからセルルータへのパスのコストを表しており、ならびに、例えば、ETTを算出する式1のメトリック(metric)を使用して算出されてもよい。より高位のランクは、セルルータからより遠いノードである。このフィールドは、MACサブレイヤにおいてルーティングの一貫した検知のためにノードを受信することによって利用されてもよい。
DODAG ID:このフィールドは、Destination Oriented Directed Acyclic Graph(DODAG)ルート(例えば、ネットワーク境界ルータ(network border router)、セルラルータ、リレーなど)を識別する、DODAG識別子(ID)であり、DODAGルートを通じて、RTSを送信しているノードは、中央オフィスまたは他のネットワークコンピューティングデバイスとの通信のために、インターネットなどのバックホールネットワークに接続される。図1のアーキテクチャ100のコンテキストにおいて、ノードAは、バックホールネットワークの例であるネットワーク106と通信しているアーキテクチャ100のDODAGルートの例である。DODAG_IDは、RTSフレームを受信するノードが、MACサブレイヤにおいてルーティングの一貫した状態(routing consistency conditions)を検証することによって、RTSフレームを受理または拒絶することを可能にする。
Duration:このフィールドは、RTSにおいて特定されるデータフレームを交換することに対するトータルの予想される時間を示す。Durationは、特定されたデータフレームを送信するための時間、フレーム間のフレーム間隔時間(IFS:inter-frame spacing)(例えば、SIFS、GIFSなど)などの待機時間、および、肯定応答ACK)もしくは否定応答(NACK)の応答を含んでもよい。Durationフィールドは、ノードが別のノードと通信するのにビジーであり、したがって、受信するのに利用可能でない期間を判定するのに使用されてもよい。Durationフィールドは、図2に示されるビジーデバイスリスト214などの、ビジーデバイスリストの「Duration」列に追加する(populate)ために使用されてもよい。
Ch:このフィールドは、RTSがチャネルリストを含むかを示すフラグを含む。
Channels List:このフィールドは、RTSフレームを送信するノードに対して利用可能であるチャネルのリストを含む、チャネルリストを含む。RTSフレームを受信するノードは、利用可能なチャネルからチャネルを選択してもよく、および、CTSフレーム内部のこの選択されたチャネルを特定してもよい。一部の例では、チャネルリストは、ノードに対して利用可能なすべてのチャネルよりも少ないチャネルを含んでもよい。例えば、直接シーケンススペクトル拡散(DSSS:Direct-sequence Spread Spectrum)変調が採用される場合、チャネルリストは、915MHISM帯域における13チャネルに限定されてもよい。チャネルリストは、例えば、RTSを送信したノードとRTSを受信したノードとの間の適格とされたチャネルのリストを備えてもよい。適格とされたチャネルのリストは、図2を参照して示されたノード102Cのメモリ114において維持される適格とされたリンク212のリストなどの、RTSを送信したノード、および/またはRTSを受信したノードのメモリにおいて維持されてもよい。
Date Rate(DR)parameter:このフィールドは、RTSフレームを送信するノードによってサポートされ、および/または、提案される最大データレートを示す。RTSフレームを受信するノードは、このフィールドを利用して、ノードを送信および受信することの両方が可能なデータレートを判定してもよい。判定されたデータレートは、CTSフレームを使用して、当該送信しているノードに送信されてもよい。判定されたデータレートは、最大でも、2つのノードのより遅い方の最大データレートに設定される。したがって、RTSが、受信ノードよりも高いデータレートを提案することが可能な場合、受信ノードは、CTSフレームを送信するときに、より低いデータレート(最大でも、受信ノードの最大データレート)を設定する。
Data_ID:このフィールドは、データパケットのIDを含む。このIDは、RTSフレームの内部で提示されてもよい。このフィールドは、例えば、データパケットが特定のノードによって送信されているが、肯定応答が、データパケットを送信したノードにおいて受信されなかった場合に、利用されてもよい。このケースでは、Data_IDとともにデータパケットを送信したノードは、データパケットが受信されなかったと想定してもよく、および、同一のData_IDに対するRTSフレームを再送信してもよい。一部のケースでは、特定のノードが、受信された最後のData_IDの番号を記録するときに、特定のノードは、CTSフレームの代わりに、ACKフレームで応答してもよく、したがって、データフレームの再送信を回避する。
F_ID:このフィールドは、RTSフレームのMACフレームIDを含む。RTSフレームの意図された宛先は、このRTSフレームに応答するCTSフレームにおいて、このF_IDを複製する。RTSフレームを送信するノードがCTSフレームを受信するときに、当該ノードは、CTSフレームにおけるF_IDを使用して、CTSフレームが予想された1つであるかを判定してもよい(すなわち、それは、ノードが以前に送信したRTSフレームへの応答において送信されている)。
NP:このフィールドは、RTSフレームを受信するノードと交換されることになるパケットの数を示す。このフィールドは、制御チャネルをリスンすることに切り替わる前に、受信ノードがいくつのパケットを特定されたデータチャネル上でリスンするかを示す。このフィールドはまた、特定のチャネルの可用性を判定する際に有用であってもよい。
Pre_Ch:このフィールドは、ノードが図4に示すテストデータフレームなどのデータフレームを交換するのに利用することを選ぶチャネルを示す。この交換に関与されないが、RTSをオーバーヒアするノードは、このフィールドに基づいてビジーデバイスリスト(例えば、図3を参照して示される)を更新してもよい。デフォルトにより、RTSフレームの受信側は、可能である場合は、データ交換に対してこのチャネルを選択してもよい。しかしながら、このチャネルがビジーであり、または、リンクの適格とされたチャネルでない場合、受信側ノードはCTSにおいて異なるチャネルを指定してもよい。
DIR:このフィールドは、トラフィックがルートからであるか、または、トラフィックがルートに送信されることになるかを示す。ルートからリーフへ送信されるトラフィックは、「ダウンストリーム」と称され、ルートへ送信されるすべての通信は「アップストリーム」と称される。このフィールドは、例えば、アップストリームトラフィックに対しては1に、ダウンストリームトラフィックに対しては0に設定されてもよい。

0073

図7は、ノードがデータを受信するのに利用可能であることを示すのに通信されるフレームの形式での例示的なCTSメッセージ700を示している。CTSフレーム700は、例えば、物理パラメータおよび第1のノードによって選択されたデータチャネルを含んでもよい。一部のインスタンスでは、CTSフレームは、隣接ノードにRTSを送信しているノードおよびCTSを送信しているノードが利用可能であり、ならびに、選択されたデータチャネルが、特定の時間の間、ビジーであることを通知するのに利用される。図7の例では、CTSフレームは、以下のフィールド、FC、シーケンス番号、宛先PAN識別子、宛先アドレス、ソースPAN識別子,ソースアドレス、補助セキュリティヘッダ、ペイロード、および、FCSを含む。ペイロード以外のCTSフレームの上記フィールドの詳細は、当業者にとって周知であり、本明細書においては詳細な説明は行わない。しかしながら、CTSフレームのペイロードは、上述したルーティング技術、および、他の機能を実装するためにカスタマイズされる。CTSフレームのペイロードは、サイズが可変であってもよく、および、例えば、1つまたは複数の以下のフィールドを含んでもよい。
Type:このフィールドは、図6を参照して示されたのと同様の情報を示してもよい。図7の例では、このフィールドは、フレームがCTSフレームであることを示す。
HW:このフィールドは、RTSフレームを受信したノード(すなわち、当該ノードはCTSフレームを送信する)のハードウェアパラメータ(例えば、デバイスのタイプ、デバイスのバージョンまたは世代)を含む。
Rank:このフィールドは、RTSフレームの対応するフィールドに類似しているが、CTSフレームに適用されるものに類似してもよい。このフィールドは、例えば、図2で示す適格化リンクリスト212における相対品質にしたがって、リンクを順位付けする際に使用されてもよい。
DODAG_ID:このフィールドは、RTSフレームの対応するフィールドに類似しているが、CTSフレームに適用されるものに類似してもよい。特に、このフィールドは、MACサブレイヤにおいてルーティングの一貫した状態を検証することによって、CTSフレームを受信して、受理または拒絶するノードに対して選択を提供するDODAG識別子である。
Duration:このフィールドは、RTSフレームの対応するフィールドに類似しているが、CTSフレームに適用されるものに類似してもよく、図2のビジーデバイスリスト214を維持するためなど、可用性および可用性の期間を判定するのに使用されてもよい。
Channel:このフィールドは、RTSフレームを受信したノードによって選択されるデータチャネルを示している。
DR:このフィールドは、RTSフレームを受信したノードによって選択されるデータレートを示している。データレートは、RTSにおいて特定されたデータレートと同一であってもよく(受信ノードがデータレートに順応できる(capable of the data rate)場合)、または、異なってもよい(受信ノードがデータレートに順応できない場合)。このデータレートは、データチャネル上で図4を参照して示されたテストデータパケットなどのデータを転送するために実装されてもよい。
F_ID:このフィールドは、RTSフレームのF_ID値と同一であってもよいCTSフレームのMACフレームIDを含む。

0074

上述したように、RTSおよびCTSフレーム600および700は、単に、本明細書で示されたルーティング技術を実装するために使用することができる一部のPDUの例である。他の実施形態では、種々の他のPDUが上述したルーティング技術を実装するのに採用されてもよい。

0075

<結論>
本願は、実施形態が特定の構造的な特徴および/または方法的な動作を有することを説明したが、特許請求の範囲は、必ずしも説明した特定の特徴または動作に限定されないことが理解される。むしろ、当該特定の特徴および動作は、単に、本願の特許請求の範囲に含まれる一部の実施形態を例示するものである。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社NTTドコモの「 ユーザ端末及び無線通信方法」が 公開されました。( 2020/12/17)

    【課題・解決手段】ビーム失敗回復手順に用いられる周波数リソースを適切に設定するために、ユーザ端末は、ビーム失敗を検出した場合にビーム失敗回復要求を送信する送信部と、前記ビーム失敗回復要求に対する応答を... 詳細

  • 株式会社NTTドコモの「 ユーザ装置」が 公開されました。( 2020/12/17)

    【課題・解決手段】ユーザ装置であって、当該ユーザ装置の能力情報を格納する能力情報格納部と、前記能力情報を基地局に通知する能力情報通知部とを有し、前記能力情報通知部は、当該ユーザ装置によってサポートされ... 詳細

  • 株式会社NTTドコモの「 ユーザ装置、及び上り送信タイミング調整方法」が 公開されました。( 2020/12/17)

    【課題・解決手段】基地局とユーザ装置とを備える無線通信システムにおける前記ユーザ装置において、前記基地局に上り信号を送信する信号送信部と、前記基地局から下り信号を受信する信号受信部と、前記信号送信部か... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ