特許 6067937 コンピュータネットワークにおける低送信電力チャネルおよび中送信電力チャネルのインターリーブ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6067937

(24)【登録日】2017年1月6日

(45)【発行日】2017年1月25日

(54)【発明の名称】コンピュータネットワークにおける低送信電力チャネルおよび中送信電力チャネルのインターリーブ

(51)【国際特許分類】

   H04W 72/04 20090101AFI20170116BHJP

   H04W 40/08 20090101ALI20170116BHJP

   H04L 12/721 20130101ALI20170116BHJP

   H04W 4/04 20090101ALI20170116BHJP

   H04B 1/713 20110101ALI20170116BHJP

【ＦＩ】

   H04W72/04 134

   H04W40/08

   H04L12/721 A

   H04W4/04 190

   H04B1/713

【請求項の数】20

【全頁数】36

(21)【出願番号】特願2016-520583(P2016-520583)

(86)(22)【出願日】2014年5月29日

(65)【公表番号】特表2016-537857(P2016-537857A)

(43)【公表日】2016年12月1日

(86)【国際出願番号】US2014040052

(87)【国際公開番号】WO2015020717

(87)【国際公開日】20150212

【審査請求日】2016年4月5日

(31)【優先権主張番号】13/960,663

(32)【優先日】2013年8月6日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】507308843

【氏名又は名称】シスコ テクノロジー、インコーポレイテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ジョナサン・ダブリュ・フイ

(72)【発明者】

【氏名】ウェイ・ホン

(72)【発明者】

【氏名】ジャン−フィリップ・ヴァサール

【審査官】 吉村 真治▲郎▼

(56)【参考文献】

【文献】 米国特許出願公開第２０１３／０１２１３３５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００９４５３７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００２８２９５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００１６７５９（ＵＳ，Ａ１）

【文献】 特開２０１３−１１８６２１（ＪＰ，Ａ）

【文献】 特開２０１２−１０５２５８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

Ｈ０４Ｌ １２／７２１

Ｈ０４Ｂ １／７１３

(57)【特許請求の範囲】

【請求項1】

複数のコンピューティングデバイスを含む低電力および高損失ネットワーク(LLN)において、前記ネットワーク内の単一のデバイスが、前記ネットワーク内の近隣のデバイスが低電力チャネルと中電力チャネルとの両方を用いて前記単一のデバイスと通信することを可能にし得るように、インターリーブされた低電力チャネルホッピングシーケンスと中電力チャネルホッピングシーケンスとの混合を含む混合されたチャネルホッピングシーケンスを生成するステップを含む方法。

【請求項2】

前記単一のデバイスによって、近隣のデバイスに前記混合されたチャネルホッピングシーケンスを伝達するステップをさらに含む請求項1に記載の方法。

【請求項3】

前記チャネルホッピングシーケンスが、前記近隣のデバイスに制御メッセージを送信することによって伝達され、前記制御メッセージが、前記単一のデバイスの現在の時間およびスロットのインデックスを含む請求項2に記載の方法。

【請求項4】

前記近隣のデバイスが、前記時間および前記スロットのインデックスを前記チャネルホッピングシーケンスを生成するためのチャネルシーケンス機能への入力として使用する請求項3に記載の方法。

【請求項5】

前記制御メッセージは、前記単一のデバイスによって提供される前記チャネルシーケンス機能を示す情報を含む請求項4に記載の方法。

【請求項6】

前記チャネルシーケンス機能が、低電力チャネルのスロットに対する中電力チャネルのスロットの割合がより高いチャネルホッピングシーケンスを生成する請求項4に記載の方法。

【請求項7】

前記単一のデバイスが、イベントに応じて、低電力チャネルのスロットに対してより高い割合の中電力チャネルのスロットを含む前記混合されたチャネルホッピングシーケンスを近隣のデバイスに伝達する請求項6に記載の方法。

【請求項8】

前記イベントが停電である請求項7に記載の方法。

【請求項9】

前記チャネルシーケンス機能が、中電力チャネルのスロットに対する低電力チャネルのスロットの割合がより高いチャネルホッピングシーケンスを生成する請求項8に記載の方法。

【請求項10】

低電力および高損失ネットワーク(LLN)と通信するための1つまたは複数のネットワークインターフェースと、
前記ネットワークインターフェースに結合され、1つまたは複数のプロセスを実行するように適合されたプロセッサと、
前記プロセッサによって実行可能なプロセスを記憶するように構成されたメモリであって、前記プロセスが、実行されるときに、
前記ネットワーク内の単一のデバイスが、前記ネットワーク内の近隣のデバイスが低電力チャネルと中電力チャネルとの両方を用いて前記単一のデバイスと通信することを可能にし得るように、インターリーブされた低電力チャネルホッピングシーケンスと中電力チャネルホッピングシーケンスとの混合を含む混合されたチャネルホッピングシーケンスを生成するように動作可能である、メモリとを含む装置。

【請求項11】

実行されるときに、近隣のデバイスに前記混合されたチャネルホッピングシーケンスを伝達するようにさらに動作可能であるプロセスをさらに含む請求項10に記載の装置。

【請求項12】

前記チャネルホッピングシーケンスが、前記近隣のデバイスに制御メッセージを送信することによって伝達され、前記制御メッセージが、前記装置の現在の時間およびスロットのインデックスを含む請求項11に記載の装置。

【請求項13】

前記近隣のデバイスが、前記時間および前記スロットのインデックスを前記チャネルホッピングシーケンスを生成するためのチャネルシーケンス機能への入力として使用する請求項12に記載の装置。

【請求項14】

前記制御メッセージは、前記単一のデバイスによって提供される前記チャネルシーケンス機能を示す情報を含む請求項13に記載の装置。

【請求項15】

前記チャネルシーケンス機能が、低電力チャネルのスロットに対する中電力チャネルのスロットの割合がより高いチャネルホッピングシーケンスを生成する請求項13に記載の装置。

【請求項16】

前記単一のデバイスが、イベントに応じて、低電力チャネルのスロットに対してより高い割合の中電力チャネルのスロットを含む前記混合されたチャネルホッピングシーケンスを近隣のデバイスに伝達する請求項15に記載の装置。

【請求項17】

前記イベントが停電である請求項16に記載の装置。

【請求項18】

符号化されたソフトウェアを有する有形の非一時的コンピュータ可読媒体であって、前記ソフトウェアが、プロセッサによって実行されるときに、
複数のノードを含む低電力および高損失ネットワーク(LLN)において、前記ネットワーク内の単一のデバイスが、前記ネットワーク内の近隣のデバイスが低電力チャネルと中電力チャネルとの両方を用いて前記単一のデバイスと通信することを可能にし得るように、インターリーブされた低電力チャネルホッピングシーケンスと中電力チャネルホッピングシーケンスとの混合を含む混合されたチャネルホッピングシーケンスを生成するように動作可能である、有形の非一時的コンピュータ可読媒体。

【請求項19】

前記ソフトウェアが、実行されるときに、近隣のデバイスに制御メッセージを伝達するようにさらに動作可能であり、前記制御メッセージが、現在の時間およびスロットのインデックスならびにチャネルシーケンス機能を含み、前記チャネルシーケンス機能が、前記現在の時間および前記スロットのインデックスを用いて前記近隣のデバイス上で前記混合されたチャネルホッピングシーケンスを生成する請求項18に記載のコンピュータ可読媒体。

【請求項20】

前記制御メッセージが、イベントの検出に応じて近隣のデバイスに送信される請求項19に記載のコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願
本特許出願は、2013年8月6日に出願した、「Interleaving Low Transmission Power and Medium Transmission Power Channels in Computer Networks」と題した米国特許出願第13/960,663号の優先権を主張するものである。上で特定された出願の内容の全体は、参照により本明細書に完全に組み込まれている。
本開示は、概して、コンピュータネットワークに関し、より詳細には、多インターフェースネットワークにおいて効率および効果を高めることに関する。

【背景技術】

【0002】

制約されたネットワークは、たとえば、センサーネットワークなどの低電力および高損失ネットワーク(LLN: Low power and Lossy Network)を含む。これらの制約されたネットワークは、スマートグリッド、スマートシティ、家および建物のオートメーションなどの無数のアプリケーションを有する。高損失のリンク、低帯域幅、バッテリー動作、低いメモリおよび/または処理の能力など様々な課題が、LLNにともなって示されている。大規模なインターネットプロトコル(IP)スマートオブジェクト(object)ネットワークは、いくつかの技術的課題をもたらす。たとえば、(多数のセンサーおよびアクチュエータによるスマートグリッドネットワーク、スマートシティ、または高度メータリングインフラストラクチャ(AMI: advanced metering infrastructure)ネットワークなどの)そのようなネットワークの密度は、極めて高い可能性がある。たとえば、各ノードが数百個の近隣のノードを認識することは珍しくない。このアーキテクチャはLLNにとって特に問題になり、制約されたリンクがデータ送信を大混乱に陥れる可能性がある。

【0003】

ネットワークの展開は、RF、電力線通信(PLC)、およびセルラーを含むいくつかの異なるリンクテクノロジーを利用する。それぞれのリンクテクノロジーは、独自の1組の強みおよび弱みをもたらす。概して、これらのネットワーク内のデバイスは、これらのテクノロジーのうちの1つを介してのみ通信し、通常、「シングリーPHY (singly PHY)」デバイスと呼ばれる。代替的な手法は、複数のリンクテクノロジーを同時にサポートするネットワークデバイスを使用することである。これらのネットワーク内のデバイスは、通常、「マルチPHY」または「多インターフェース」デバイスと呼ばれる。たとえば、ネットワークデバイスは、RF通信インターフェースおよびPLC通信インターフェースをサポートする可能性がある。特定の例示的なにおいては、これらのネットワーク内のデバイスは、単一のリンクテクノロジーを利用するが、各デバイスによって使用される送信電力が異なる。たとえば、一部のデバイスが、主として低電力送信チャネルを用いて送信する可能性があり、その他のデバイスが、主として中電力送信チャネルを用いて通信する可能性があり、さらにその他のデバイスが、中電力送信チャネルと低電力送信チャネルとの組合せを用いて送信する可能性がある。

【0004】

ネットワークは、規制遵守のために制約されることが多い。たとえば、(「中」または「低」送信電力など)特定の送信電力が、各ネットワーク内の規定されたチャネルのために指定される可能性があり、概して、ネットワーク内のデバイスまたはノードは、チャネルホッピングするリンクレイヤを用いて通信する。受信者デバイスは、チャネルホッピングスケジュールを決定し、そして、送信側デバイスは、受信者デバイスのチャネルホッピングスケジュールに従って受信者デバイスと同期し、送信しなければならない。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】Internet Engineering Task Force (IETF) Proposed Standard、Request for Comment (RFC) 6550、「RPL: IPv6 Routing Protocol for Low Power and Lossy Networks」、Winterら

【非特許文献2】IETF Internet Draft <draft-ietf-roll-routing-metrics-19> (2011年3月1日バージョン)、「Routing Metrics used for Path Calculation in Low Power and Lossy Networks」、Vasseurら

【非特許文献3】IETF RFC <RFC 6552> (2012年3月バージョン)、「RPL Objective Function 0」、Thubert

【非特許文献4】IETF RFC <RFC 6719> (2012年9月バージョン)、「The Minimum Rank Objective Function with Hysteresis」、O. Gnawaliら

【発明の概要】

【課題を解決するための手段】

【0006】

本開示は、概して、コンピュータネットワークに関し、より詳細には、多インターフェースネットワークにおいて効率および効果を高めることに関する。

【図面の簡単な説明】

【0007】

【図1】特定の例示的な実施形態による例示的な通信ネットワークを示す図である。

【図2】特定の例示的な実施形態による例示的なネットワークデバイス/ノードを示すブロック図である。

【図3】特定の例示的な実施形態によるパケットヘッダおよびペイロードの編成を示すブロック図である。

【図4】特定の例示的な実施形態によるコンピュータネットワーク内で定義される有向非巡回グラフを示す図である。

【図5】特定の代替的な例示的実施形態による例示的な通信ネットワークを示すブロック図である。

【図6】特定の例示的な実施形態によるネットワーク通信中に要求に応じて中から低電力チャネルに切り替えるための方法を示すブロック流れ図である。

【図7】特定の例示的な実施形態によるネットワークに関する中電力および低電力チャネルのルーティングトポロジーを定義するための方法を示すブロック流れ図である。

【図8】特定の例示的な実施形態によるネットワークに関する低電力チャネルのトポロジーを定義するための方法を示すブロック流れ図である。

【図9】特定の例示的な実施形態によるトラフィックを異なるルーティングテクノロジーに動的にマッピングするための方法を示すブロック流れ図である。

【図10】特定の例示的な実施形態によるネットワーク内のネットワークデバイスに関するチャネルホッピングスケジュールを定義するための方法を示すブロック流れ図である。

【図11】特定の例示的な実施形態による、送信するデバイスが受信者に低電力ホッピングスケジュールに切り替えるように要求するための方法を示すブロック流れ図である。

【発明を実施するための形態】

【0008】

概要
本開示の1つまたは複数の実施形態によれば、複数のノードを含むマルチインターフェース低電力および高損失ネットワーク(LLN)において、低送信電力および中送信電力トポロジーが、ネットワークのために定義され、チャネルホッピングスケジュールが、各トポロジーにおいて動作するデバイスのために定義される。送信側デバイスは、データパケットが低送信電力トポロジー上のリンクを介して送信され得ると判定する。例示的な実施形態において、送信側デバイスは、低送信電力チャネル上でのデータの送信に関する送信パラメータを決定し、中送信電力トポロジー上のリンクを介して受信側デバイスに送信パラメータを送信する。送信側デバイスは、データの送信のためのチャネルを決定し、決定されたチャネルまたはチャネルホッピングスケジュールを受信側デバイスに送信する。受信側デバイスは、指定された低電力チャネルまたはチャネルホッピングスケジュールに切り替わり、送信側デバイスは、指定された低電力チャネルまたはチャネルホッピングスケジュールを介して受信側デバイスにデータを送信する。

【0009】

説明
図全体を通じて同様の番号が同様の(しかし、必ずしも同一ではない)要素を表す図面を参照して、例示的な実施形態が説明される。

【0010】

コンピュータネットワークは、エンドノード間でデータを転送するために通信リンクおよびセグメントによって相互に接続されたノードの地理的に分散された集合である。ノードおよびエンドノードは、たとえば、パーソナルコンピュータおよびワークステーション、またはセンサーなどのその他のデバイスを含む。ローカルエリアネットワーク(LAN)から広域ネットワーク(WAN)までの範囲の多くの種類のネットワークが、利用可能である。概して、LANは、建物またはキャンパスなどの同じ大まかな物理的場所に置かれた専用の私設通信リンクを介してノードを接続する。一方、WANは、通常、よくある回線事業者の加入電話回線、光学的光経路、同期光ネットワーク(SONET)、同期デジタルハイアラーキ(SDH)リンク、IEEE 61334、IEEE P1901.2などの電力線通信(PLC)などの長距離通信リンクを介して地理的に散らばったノードを接続する。加えて、モバイルアドホックネットワーク(MANET)は、概して、結合が任意のトポロジーを形成するワイヤレスリンクによって接続されたモバイル経路(および関連するホスト)の自己構成ネットワークと考えられるある種のワイヤレスアドホックネットワークである。

【0011】

センサーネットワークなどのスマートオブジェクトネットワークは、たとえば、エネルギー/電力消費、リソース消費(たとえば、高度メータリングインフラストラクチャまたは「AMI」のアプリケーションのために水/ガスなど)、温度、圧力、振動、音、放射、動き、汚染物質などの、異なる場所における物理的なまたは環境の状態を協力して監視するセンサー、アクチュエータなどの空間的に分散された自律的デバイスを有する特定の種類のネットワークである。その他の種類のスマートオブジェクトは、たとえば、エンジンをオン/オフすることまたは任意のその他の行為を行うことを担うアクチュエータを含む。センサーネットワーク、ある種のスマートオブジェクトネットワークは、通常、ワイヤレスまたはPLCネットワークなどの共有メディア(shared-media)ネットワークである。すなわち、1つまたは複数のセンサーに加えて、センサーネットワーク内の各センサーデバイス(ノード)は、概して、無線トランシーバまたは(PLCなどの)その他の通信ポート、マイクロコントローラ、および(バッテリーなどの)エネルギー源を備える可能性がある。多くの場合、スマートオブジェクトネットワークは、フィールドエリアネットワーク(FAN)、近隣エリアネットワーク(NAN: neighborhood area network)などと考えられる。概して、スマートオブジェクトノード(たとえば、センサー)に対するサイズおよびコストの制約が、エネルギー、メモリ、計算速度、および帯域幅などのリソースに対する対応する制約をもたらす。

【0012】

近年、メッシュネットワークが、ますます普及し、実用的になった。特に、ワイヤレスまたはPLCネットワークなどの共有メディアメッシュネットワークは、低電力および高損失ネットワーク(LLN)と呼ばれるものの上にあることが多い。LLNは、ルータとそれらのルータの相互接続との両方が制約されるネットワークのクラスであり、すなわち、LLNルータは、通常、制約(たとえば、処理能力、メモリ、および/またはエネルギー(バッテリー))を受けながら動作し、それらのLLNルータの相互接続は、例として、高損失率、低データレート、および/または不安定さによって特徴付けられる。LLNは、数十個からまたは最大で数千個もしくはさらには数百万個までの任意の範囲のLLNルータからなり、(LLN内のデバイス間の)ポイントツーポイントトラフィック、(ルートノードなどの中央制御点からLLN内のデバイスのサブセットへの)ポイントツーマルチポイントトラフィック、および(LLN内のデバイスから中央制御点への)マルチポイントツーポイントトラフィックをサポートする。

【0013】

おおざっぱに言って、用語「モノのインターネット」または「IoT」は、ネットワークに基づくアーキテクチャ内の一意に特定可能なオブジェクト(モノ)およびそれらのオブジェクトの仮想的な表現を指すためにネットワークの分野の当業者によって使用される可能性がある。特に、インターネットの発展の次の最前線は、単にコンピュータおよび通信デバイスだけを接続する能力に留まらず、さらに、照明、電化製品、車、HVAC (暖房、換気、および空調)、窓、窓の日よけ、およびブラインド、ドア、鍵など、幅広い「オブジェクト」を接続する能力である。したがって、「モノのインターネット」は、概して、公衆インターネットまたは私設ネットワークである可能性があるコンピュータネットワーク(たとえば、インターネットプロトコル(「IP」))を介したセンサーおよびアクチュエータなどのオブジェクト(たとえば、スマートオブジェクト)の相互接続を指す。そのようなデバイスは、プロトコル変換ゲートウェイを介してIPネットワークに接続される通常は非IPまたは独自仕様のプロトコルの形態で産業において数十年間使用されてきた。スマートグリッド、スマートシティ、建物および工業のオートメーション、ならびに(たとえば、動力の質、タイヤの圧、および温度のようなモノを感知するための数百万個のオブジェクトを相互接続する可能性があり、エンジンおよびライトを駆動する可能性がある)自動車などの無数のアプリケーションの出現によって、IPプロトコルスイートをこれらのネットワークのために拡張することが最重要であった。

【0014】

図1は、通信の様々な方法によって相互接続された(たとえば、示されるように「ルート」、「11」、「12」、...「45」とラベル付けされた)ノード/デバイス200を例として含む例示的なコンピュータネットワーク100の概略的なブロック図である。たとえば、リンク105は、有線リンクまたは共有メディア(たとえば、ワイヤレスリンク、PLCリンクなど)である可能性があり、(たとえば、ルータ、センサー、コンピュータなどの)特定のノード200が、たとえば、距離、信号強度、現在の動作ステータス、位置などに基づいてその他のノード200と通信する可能性がある。当業者は、任意の数のノード、デバイス、リンクなどがコンピュータネットワークにおいて使用され得ることと、本明細書において示される視点が簡単にするためのものであることとを理解するであろう。また、当業者は、ネットワークが特に「ルート」ノードを用いて特定の向きで示されるが、ネットワーク100は本開示を限定するように意図されていない例示的な図示であるに過ぎないことをさらに理解するであろう。加えて、(たとえば、WANを介して)ルートデバイスの向こう側に置かれたネットワーク管理サーバ(NMS) 130またはその他のヘッドエンドアプリケーションデバイスも、ネットワーク100と通信する可能性がある。

【0015】

データパケット140 (たとえば、デバイス/ノードの間で送信されるトラフィックおよび/またはメッセージ)が、特定の知られている有線プロトコル、ワイヤレスプロトコル(たとえば、IEEE Std. .15.15.4、WiFi、Bluetooth(登録商標)など)、PLCプロトコル、または適切な場合、その他の共有メディアプロトコルなどの予め定義されたネットワーク通信プロトコルを用いてコンピュータネットワーク100のノード/デバイス間でやりとりされ得る。この文脈で、プロトコルは、ノードがどのようにして互いにインタラクションするかを定義する1組の規則からなる。

【0016】

図2は、本明細書において説明される1つまたは複数の実施形態で、たとえば、上で図1に示されたノードのいずれかとして使用され得る例示的なノード/デバイス200の概略的なブロック図である。デバイス200は、システムバス250によって相互接続された1つまたは複数のネットワークインターフェース210 (たとえば、有線、ワイヤレス、PLCなど)、少なくとも1つのプロセッサ220、およびメモリ240、ならびに電源260(たとえば、バッテリー、コンセントなど)を含み得る。

【0017】

ネットワークインターフェース210は、ネットワーク100に結合されたリンク105上でデータを伝達するための機械的、電気的、および信号伝達回路を含む。ネットワークインターフェースは、様々な異なる通信プロトコルを用いてデータを送信および/または受信するように構成され得る。さらに、ノードが、複数の種類のネットワーク接続210、たとえば、ワイヤレスおよび有線/物理接続を有する可能性があることと、本明細書において示される視点が例示のためであるに過ぎないこととに留意されたい。また、ネットワークインターフェース210は、電源260と別々に示されているが、電源260を通じて通信する可能性があり、またはたとえばPLCに関しては電源の一体的な構成要素である可能性がある。一部の特定の構成においては、PLC信号が、電源に流れ込む電力線に結合される可能性がある。

【0018】

メモリ240は、本明細書において説明される実施形態に関連するソフトウェアプログラムおよびデータ構造を記憶するためにプロセッサ220およびネットワークインターフェース210によってアドレス指定され得る複数の記憶位置を含む。特定のデバイスは限られたメモリを有するかまたはメモリを持たない可能性がある(たとえば、デバイスおよび関連するキャッシュで動作するプログラム/プロセスのためではない記憶用のメモリを持たない可能性がある)ことに留意されたい。プロセッサ220は、ソフトウェアプログラムを実行し、データ構造245を操作するように適合されたハードウェア要素またはハードウェアロジックを含み得る。概して一部がメモリ240に常駐し、プロセッサ220によって実行されるオペレーティングシステム242は、とりわけ、デバイス上で実行されるソフトウェアプロセスおよび/またはサービスを支援する動作を呼び出すことによってデバイスを機能的に統率する。これらのソフトウェアプロセスおよび/またはサービスは、本明細書において説明されるように、ルーティングプロセス/サービス244および例示的な「QoS監視」プロセス248を含み得る。QoS監視プロセス248は集中化されたメモリ240内にあるところが示されているが、代替的な実施形態は、(プロセス「248a」としての)ネットワークインターフェース210内のネットワークレイヤの動作の構成要素など、特にネットワークインターフェース210内で動作させられるようにプロセスを設けることに留意されたい。

【0019】

様々なコンピュータ可読媒体を含むその他のプロセッサおよびメモリの種類が本明細書において説明される技術に関するプログラム命令を記憶し、実行するために使用され得ることは、当業者に明らかであろう。また、説明は様々なプロセスを示すが、様々なプロセスが本明細書の技術に従って(たとえば、同様のプロセスの機能に従って)動作するように構成されたモジュールとして具現化され得ることは、はっきりと想定される。さらに、プロセスが別々に示されたが、当業者は、プロセスがその他のプロセス内のルーチンまたはモジュールである可能性があることを認めるであろう。

【0020】

ルーティングプロセス(サービス) 244は、当業者によって理解されるであろうように、プロアクティブ型(proactive)またはリアクティブ型(reactive)ルーティングプロトコルなどの1つまたは複数のルーティングプロトコルによって提供される機能を実行するためにプロセッサ220によって実行されるコンピュータが実行可能な命令を含む。これらの機能は、対応デバイス上で、たとえば、ルーティング/フォワーディングの判断を行うために使用されるデータを含むルーティング/フォワーディングテーブル(データ構造245)を管理するように構成され得る。特に、プロアクティブ型ルーティングにおいては、たとえば、開放型最短経路優先(OSPF: Open Shortest Path First)、中間システムツー中間システム(ISIS: Intermediate System to Intermediate System)、または最適化リンク状態ルーティング(OLSR: Optimized Link State Routing)などのリンク状態ルーティングを用いてネットワーク内の任意の送信先への経路を計算する前に接続性が発見され、知られる。一方、リアクティブ型ルーティングは、近隣のノードを発見し(言い換えれば、リアクティブ型ルーティングはネットワークトポロジーの事前の知識を持たない)、送信先への必要とされる経路に応じて、どの近隣のノードが所望の送信先に達するために使用され得るかを判定するためにネットワークに経路要求を送信する。例示的なリアクティブ型ルーティングプロトコルは、アドホックオンデマンド距離ベクトル(AODV: Ad hoc On demand Distance Vector)、動的ソースルーティング(DSR: Dynamic Source Routing)、動的MANETオンデマンドルーティング(DYMO: DYnamic MANET On demand Routing)などを含み得る。特に、ルーティングエントリを記憶する能力がないかまたはルーティングエントリを記憶するように構成されていないデバイス上では、ルーティングプロセス244は、ソースルーティング技術のために必要なメカニズムを提供することのみからなる可能性がある。すなわち、ソースルーティングに関しては、ネットワーク内のその他のデバイスが、より能力の低いデバイスにパケットをどこに送信すべきかを厳密に教えることができ、より能力の低いデバイスは、単純に、指示されたとおりにパケットを転送する。

【0021】

低電力および高損失ネットワーク(LLN)、たとえば、特定のセンサーネットワークは、「スマートグリッド」および「スマートシティ」のためなど、無数のアプリケーションにおいて使用され得る。以下のようなLLNのいくつかの課題が、示されている。
1)パケット伝達レート/率(PDR: Packet Delivery Rate/Ratio)がたとえば干渉の様々な源が原因で劇的に変化する可能性があり、たとえば、ビットエラー率(BER)に著しく影響するように、概して、リンクが高損失である。
2)概して、制御プレーンのトラフィックが制限され、低レートのデータトラフィックと比較して無視できなければならないように、概して、リンクが低帯域幅である。
3)いくつかの使用の場合は、1組のリンクおよびノードのメトリック(metric)を指定することを必要とし、それらのメトリックの一部は動的であり、したがって、帯域幅およびエネルギーを著しく消耗する、ルーティングの不安定さを防止するための特定の平滑化機能を必要とする。
4)たとえば、暗号化されていないリンク、エネルギー不足に陥っているノードなどを避けるルーティング経路を確立するために一部のアプリケーションによって制約ルーティング(constraint routing)が必要とされる可能性がある。
5)ネットワークの規模が、非常に大きくなる、たとえば、およそ数千から数百万個のノードになる可能性がある。
6)ノードが、少ないメモリ、削減された処理能力、少ない電力供給(たとえば、バッテリー)などによって制約される可能性がある。

【0022】

言い換えれば、LLNは、ルータとそれらのルータの相互接続との両方が制約されるネットワークのクラスであり、すなわち、LLNルータは、通常、制約、たとえば、処理能力、メモリ、および/またはエネルギー(バッテリー)を用いて動作し、それらのLLNルータの相互接続は、例として、高損失率、低データレート、および/または不安定さによって特徴付けられる。LLNは、数十個および最大で数千個またはさらには数百万個までのLLNルータからの任意のものからなる。加えて、LLNは、(LLN内のデバイス間の)ポイントツーポイントトラフィック、(中央制御点からLLN内のデバイスのサブセットへの)ポイントツーマルチポイントトラフィック、および(LLN内のデバイスから中央制御点への)マルチポイントツーポイントトラフィックをサポートする。

【0023】

LLNの例示的な実装は、「モノのインターネット」ネットワークである。上述のように、用語「モノのインターネット」または「IoT」は、ネットワークに基づくアーキテクチャ内の一意に特定可能なオブジェクト(モノ)およびそれらのオブジェクトの仮想的な表現を指すために当業者によって使用される可能性がある。特に、用語「IoT」は、概して、公衆インターネットまたは私設ネットワークである可能性があるコンピュータネットワーク(たとえば、IP)を介したセンサーおよびアクチュエータなどのオブジェクト(たとえば、スマートオブジェクト)の相互接続を指す。そのようなデバイスは、プロトコル変換ゲートウェイを介してIPネットワークに接続される通常は非IPまたは独自仕様のプロトコルの形態で産業において数十年間使用されてきた。無数のアプリケーション(たとえば、スマートグリッド、スマートシティ、建物および工業のオートメーションなど)の出現によって、IPプロトコルスイートをこれらのネットワークのために拡張することが最重要であった。

【0024】

1つの例示的なプロトコルが、Winterらによる「RPL: IPv6 Routing Protocol for Low Power and Lossy Networks」と題したInternet Engineering Task Force (IETF) Proposed Standard、Request for Comment (RFC) 6550において規定されている。このプロトコルは、LLN内のデバイスから中央制御点(たとえば、LLN境界ルータ(LBR)または広く「ルートノード/デバイス」)へのマルチポイントツーポイント(MP2P)トラフィック、ならびに中央制御点からLLN内のデバイスへのポイントツーマルチポイント(P2MP)トラフィック(およびポイントツーポイントまたは「P2P」トラフィックも)をサポートするメカニズムを提供する。概して、(「リップル」と発音される) RPLは、制御トラフィックを制限する特徴、修復をサポートする特徴などの1組の特徴を定義することに加えて、トラフィック/パケット140のルーティングにおいて使用するための有向非循環グラフ(DAG)を構築する距離ベクトルルーティングプロトコルとして説明され得る。特に、当業者に理解されるであろうように、RPLは、個々の要件に応じてトラフィックを運ぶために複数のDAGが構築され得るマルチトポロジールーティング(MTR)の概念もサポートする。

【0025】

DAGは、循環(ループ)が存在しないはずであるようにすべての辺(および/または節点)が向きを決められるという特性を有する有向グラフである。すべての辺は、多くの場合、インターネット、広域ネットワーク、またはその他のドメインなどのより大きなインフラストラクチャとDAGのデバイスを相互接続するために、1つまたは複数のルートノード(たとえば、「クラスタヘッド」または「シンク」)に向けて向きを決められ、1つまたは複数のルートノードで終わる経路に含まれる。加えて、送信先指向DAG (DODAG: Destination Oriented DAG)は、単一の宛先、言い換えれば、外に向かう辺を持たない単一のDAGのルートをルートとするDAGである。DAG内の特定のノードの「親」は、親が特定のノード自体よりも低い「ランク」を有するようにDAGのルートに向かう経路上の特定ノードのすぐ後のノードであり、ノードのランクは、DAGのルートに対するノードの位置を特定する(たとえば、ノードがルートから遠いほど、そのノードのランクは高くなる)。さらに、特定の実施形態においては、DAG内のノードの兄弟が、DAG内の同じランクに位置付けられる任意の近隣のノードとして定義される可能性がある。兄弟は必ずしも共通の親を共有せず、概して、兄弟の間の経路は前に進まない(それらの兄弟のランクが同じである)のでDAGの一部ではないことに留意されたい。木は、DAG内の各デバイス/ノードが概して1つの親または1つの好ましい親を有する一種のDAGであることにも留意されたい。

【0026】

概して、DAGは、目的機能(OF: Objective Function)に基づいて(たとえば、DAGプロセスによって)構築され得る。概して、目的機能の役割は、DAGをどのようにして構築するかに関する規則(たとえば、親の数、バックアップの親(backup parent)など)を規定することである。

【0027】

加えて、1つまたは複数のメトリック/制約が、DAGを最適化するためにルーティングプロトコルによってアドバータイズされ得る。また、ルーティングプロトコルは、リンクまたはノードが必要とされる制約を満たさない場合、そのリンクまたはノードが最良の経路を計算するときに候補リストから「刈り取られる」など、制約された経路を計算するために制約の任意の組を含むことを可能にする。代替的に、制約およびメトリックは、目的機能と分けられる可能性がある。加えて、ルーティングプロトコルは、データ収集点、または外部のインフラストラクチャへの接続性を提供するゲートウェイとして働くホストなどのホストまたは1組のホストを定義する「目標」を含む可能性があり、DAGの主な目的は、DAG内のデバイスが目標に達することができるようにさせることである。ノードが目的機能に従うことができないかまたはアドバータイズされたメトリックを理解もしくはサポートしない場合、ノードは、葉ノードとしてDAGに加わるように構成される可能性がある。本明細書において使用されるとき、様々なメトリック、制約、ポリシーなどは、「DAGパラメータ」と考えられる。

【0028】

例として、経路(たとえば、好ましい親)を選択するために使用される例示的なメトリックは、コスト、遅延、レイテンシー、帯域幅、予想送信回数(ETX: expected transmission count)などを含む可能性があり、一方、経路選択に課される可能性がある例示的な制約は、様々な信頼性の閾値、バッテリー動作の制限、多経路の多様性(diversity)、帯域幅の要件、送信の種類(たとえば、有線、ワイヤレスなど)などを含む可能性がある。目的機能は、選択される親の数(たとえば、親が1つの木または親が複数のDAG)などの負荷分散の要件を定義する規則を与える可能性がある。特に、ルーティングのメトリックおよび制約がどのようにして取得され得るかに関する例は、Vasseurらによる「Routing Metrics used for Path Calculation in Low Power and Lossy Networks」と題したIETF Internet Draft <draft-ietf-roll-routing-metrics-19>(2011年3月1日バージョン)に発見され得る。さらに、例示的な目的機能(たとえば、デフォルトの目的機能)は、Thubertによる「RPL Objective Function 0」と題したIETF RFC<RFC 6552>(2012年3月バージョン)およびO. Gnawaliらによる「The Minimum Rank Objective Function with Hysteresis」と題したIETF RFC<RFC 6719>(2012年9月バージョン)に発見され得る。

【0029】

DAGを構築することは、ルータがパケットをそれらのパケットの最終的な送信先にどのようにして転送するかを知るように、ネットワークの論理的表現を構築するための発見メカニズムおよびネットワーク内の状態を確立するための経路の流布を利用する可能性がある。「ルータ」は、トラフィックを転送ならびに生成することができるデバイスを指し、一方、「ホスト」は、トラフィックを生成することができるが転送はしないデバイスを指すことに留意されたい。また、概して、「葉」は、1つまたは複数のルータによってDAGに接続されるが、それ自体はDAG上で受信されたトラフィックをDAG上の別のルータに転送しない非ルータを示すために使用される可能性がある。DAGを構築するときに、発見および経路の流布のために、ネットワークのデバイスの間で制御メッセージが送信され得る。

【0030】

例示的なRPLプロトコルによれば、DODAG情報オブジェクト(DIO: DODAG Information Object)は、ノードがRPLインスタンスを発見し、そのRPLインスタンスの構成パラメータを知り、DODAGの親の組を選択し、上に向かうルーティングトポロジーを維持することを可能にする情報を運ぶ一種のDAG発見メッセージである。加えて、送信先アドバータイズメントオブジェクト(DAO)は、DODAGのルート(および他の中間ノード)が下に向かう経路をプロビジョニングし得るようにDODAGに沿って上に向かって送信先情報を運ぶ一種のDAG発見応答メッセージである。DAOメッセージは、送信先を特定するためのプレフィックス情報、ソースルーティングを支援する経路を記録する能力、および特定のアドバータイズメントの新しさを判定するための情報を含む。特に、「上に向かう」または「上への」経路は、たとえば、DAG内の辺の向きに従って葉ノードからDAGのルートに向かう方向に進む経路である。反対に、「下に向かう」または「下への」経路は、たとえば、概して、DAG内の上に向かうメッセージと反対方向に向かう、DAGのルートから葉ノードに向かう方向に進む経路である。

【0031】

概して、DAG発見要求(たとえば、DIO)メッセージは、DAGのルートデバイスから葉に向かって下向きに送信され、それぞれの連続する受信するデバイスにルートデバイスにどのようして到達するかを知らせる(すなわち、概して、要求が受信されるところがルートの方向である)。したがって、DAGは、ルートデバイスに向かって上に向かう方向に作成される。そのとき、DAG発見応答(たとえば、DAO)が、(上へのフローのみに関してなど不必要でない限り)葉からルートデバイスに返される可能性があり、反対方向のそれぞれの連続する受信するデバイスに下に向かう経路に関して葉にどのようにして到達するかを知らせる。ルーティングの状態を保持することができるノードは、DAOメッセージを送信する前にそれらのノードが受信するDAOメッセージからの経路を集約し得る。しかし、ルーティングの状態を保持することができないノードは、次のホップの親のアドレスを添付し得る。そして、DAOメッセージが、DODAGのルートに直接送信され、そしてさらに、DODAGのルートが、トポロジーを構築し、DODAG内のすべてのノードへの下に向かう経路をローカルで計算することができる。そのとき、そのようなノードは、下に向かうルーティングの状態を記憶することができないDAGの領域を越えてソースルーティングを用いて到達可能である。加えて、RPLは、DAGの近隣のノードを発見し、DAGに加わるかまたは接続性を復元するために特定の状況で送信されるDIS (DODAG情報請求(DODAG Information Solicitation))と呼ばれるメッセージも規定する。

【0032】

図3は、たとえば、DIO、DAO、またはDISメッセージとして、DAGを構築するときに発見および経路の流布のために使用され得る例示的な簡略化された制御メッセージのフォーマット300を示す。メッセージ300は、例として、メッセージの種類(たとえば、RPL制御メッセージ)、およびメッセージの特定の種類、たとえば、DIO、DAO、またはDISを示す特定のコードを特定する1つまたは複数のフィールド312を有するヘッダ310を含む。メッセージの本体/ペイロード320内にあるのは、関係する情報を中継するために使用される複数のフィールドである。特に、フィールドは、当業者によってより詳細に理解されるであろうように、様々なフラグ/ビット321、シーケンス番号322、ランク値323、インスタンスID 324、DODAG ID 325、およびその他のフィールドをそれぞれ含み得る。さらに、DAOメッセージに関しては、とりわけ、送信先プレフィックス326および通過情報フィールド327に関する追加のフィールドも含まれる可能性がある(たとえば、肯定応答(ACK)のために使用されるDAO_Sequenceなど)。任意の種類のメッセージ300に関して、メッセージ300内で追加のまたはカスタムの情報を供給するために1つまたは複数の追加の補助オプションフィールド328が使用される可能性がある。たとえば、オブジェクティブコードポイント(OCP: objective code point)補助オプションフィールドが、関連するDAGを構築するために使用される特定の目的機能を指定するコードを運ぶためにDIO内で使用される可能性がある。代替的に、補助オプションフィールド328は、たとえば、1つまたは複数の種類-長さ-値(TVL)フィールド内のインジケーション、要求、能力、リスト、通知などのその他の情報をメッセージ300内で運ぶために使用される可能性がある。

【0033】

図4は、図1のネットワーク100内でたとえば上述の技術を通じて作成され得る例示的な簡略化されたDAGを示す。たとえば、特定のリンク105が、特定の親と通信するために(およびしたがって、逆に、子が存在する場合には子と通信するために)各ノードに関して選択され得る。これらの選択されたリンクは、ルートノードから1つまたは複数の葉ノード(子のいないノード)に向かって延びる(太線として示される) DAG 410を形成する。そして、(図1に示された)トラフィック/パケット140が、特に本明細書において説明されるように、ルートに向けて上に向かう方向にかまたは葉に向けて下に向かってかのどちらかにDAG 410を通り抜ける可能性がある。本明細書において説明される特定の例はDAGに関連するが、本開示の実施形態はそのように限定されず、特に制約されたネットワークに関する任意の好適なルーティングトポロジーに基づく可能性があることに留意されたい。

【0034】

上述のように、ワイヤレスおよび電力線通信(PLC)ネットワーク(一種の電力線を介した通信)などの共有メディア通信ネットワークは、通信をネットワーク化するための可能にするテクノロジーを提供し、たとえば、高度メータリングインフラストラクチャ(AMI)ネットワークにおいて使用される可能性があり、また、家および建物内で有用である。面白いことに、PLCラインは、低電力無線(ワイヤレス)テクノロジーと多くの特徴を共有する。特に、所与のPLCネットワーク内の各デバイスは同じ物理的な電力線に接続される可能性があるが、それらのデバイスの雑音の多い環境が原因で、PLCリンクは制限された範囲を提供し、接続性は極めて予測しづらく、したがって、信号が弱すぎるときにはマルチホップルーティングを必要とする。たとえば、遠くにまで及ぶ物理的な媒体は、配電変圧器、市販の住宅用電化製品、および漏話の影響によってひどい雑音の多い環境を呈する。例として、建物内でさえも、ホップの平均の数は、2と3との間である(クロスフェーズ(cross phase)を有するときはさらに大きい)可能性がある一方、同じ電力フェーズ線(power phase line)上のAMIネットワーク上では、ホップの数が1日の間に1と15〜20との間で変動する可能性がある。したがって、当業者は、長い電力線、干渉などを含む様々な理由のためにPLC接続が複数のホップを通り抜ける可能性があることを認めるであろう。言い換えれば、PLCは、本質的にマルチホップネットワークであるので、(イーサネット（登録商標）などの)ブロードキャストメディアと同等の「フラットワイヤ(flat wire)」と見なされ得ない。

【0035】

さらに、そのような通信リンクは、通常、(たとえば、ワイヤレスメッシュまたはPLCネットワークによって)共有され、大きく制限された容量(たとえば、数Kbits/sから数十Kbits/s)を提供する。通常、LLNリンクテクノロジーは、経時的に変わる環境の状態によって強く影響を受ける物理的な媒体を介して通信する。たとえば、LLNリンクテクノロジーは、干渉(たとえば、その他のワイヤレスネットワークまたは電化製品)、空間的/物理的障害物(たとえば、ドアの開/閉、または木の葉の密度の季節変化)、および/または物理的な媒体の伝播特性(たとえば、温度、湿度などの変化)の時間的変化を含み得る。そのような時間的変化の時間の尺度は、ミリ秒(たとえば、その他のワイヤレスネットワークからの送信)から月(たとえば、屋外環境の季節変化)までの範囲に及ぶ可能性がある。たとえば、PLCリンクによれば、通常、遠くにまで及ぶ物理的な媒体は、たとえば、配電変圧器、市販の住宅用電化製品、および漏話を含む様々な源が原因でひどい雑音の多い環境を呈する。現実の世界の試験は、PLCリンクテクノロジーが高い不安定さに晒される可能性があることを示唆する。たとえば、試験は、送信先に到達するために必要とされるホップの数が1日のうちに1ホップと17ホップとの間で変動する可能性があり、ほとんど予測することができないことを示唆する。RFおよびPLCリンクはいくつかの障害に遭いやすいことが観測されており、間欠的な接続性と相まって50〜60%にもなる可能性があるパケット損失による極めて高いビット誤り率(BER)が見られることが珍しくない。

【0036】

さらに上で述べられたように、多くのLLN、特にAMIネットワークは、多くの異なるアプリケーションがネットワーク上で動作することを要求する。たとえば、以下のリストのアプリケーションが、AMIネットワーク上で同時に動作する可能性がある。
1)それぞれの個々のメータからヘッドエンドサーバにメータの読み取り値を周期的に取り出すことをともなう自動化されたメータの読み取り。
2)たとえば、ヘッドエンドサーバからネットワーク内の1つのデバイス、複数のデバイス、またはすべてのデバイスに比較的大きなファームウェアイメージ(多くの場合、500KB以上)を伝達することをともなうファームウェアのアップグレード。
3)負荷曲線を取り出すこと。
4)実際にセンサーとして働くメータによって生成されるリアルタイムの警報(たとえば、停電イベント)。
5)各メータから管理システム(NMS) 130へのネットワーク管理情報の周期的取り出し。
6)ヘッドエンドデバイスから多数のメータにマルチキャストメッセージを送信することによって要求応答アプリケーションをサポートすること。
7)その他。

【0037】

当業者は、上に列挙された例がその他の種類のLLNに関しても同様であることを認めるであろう。

【0038】

概して、これらの異なるアプリケーションは、大きく異なるトラフィックの特性、たとえば、ユニキャスト対マルチキャスト、小さなデータの単位対大きなデータの単位、低レイテンシー対耐レイテンシー、ヘッドエンドに向かうフロー対ヘッドエンドから離れるフローなどを有する。さらに、これらのアプリケーションは、厳しく制約されたLLNネットワーク上で同時に動作しなければならないので、ネットワークは、特に、異なるアプリケーションがトラフィックを同時に送信しているときに簡単に混雑に陥る可能性がある。たとえば、LLNリンクの帯域幅は、数Kbits/sしかない可能性があり、(PLCに関して)変圧器をまたぐときにはさらに低い可能性がある。適切なメカニズムがないと、これらの状況は、ネットワークが重大なサービス品質保証契約(SLA)に違反し、たとえば、メータからの重大な警報の受信を遅延させることを引き起こす可能性がある。したがって、サービス品質(QoS)メカニズムは、共有メディア通信ネットワークにおいて、特に厳しく制約されたLLNにおいて重要な機能である。

【0039】

(1)(たとえば、アプリケーションまたはエッジネットワークエントリポイント(Edge network entry point)による)パケットの彩色(coloring)およびクラス分け、(2)伝送制御プロトコル(TCP)上でバックプレッシャーのためのランダムな破棄を用いる混雑回避アルゴリズム(たとえば、WREDなど)、(3)キュー技術(たとえば、プリエンプティブキュー(preemptive queuing) + ラウンドロビン + 動的な優先順位)、(4)帯域幅の確保(たとえば、(CoSによる) DiffServ、Intserv (RSVP (-TE))、など)、(5)入力/出力のシェーピング(たとえば、混雑に基づくトラフィックシェーピング)、(6)リソース予約プロトコル(RSVP)などのプロトコルおよび/または入力トラフィックシェーパを用いる呼アドミッション制御(CAC)、(7)トラフィックエンジニアリング、(8)混雑回避技術などを含む多くのQoSメカニズムが、(制約されていない)「古典的な」IPネットワークに関して開発されてきた。しかし、これらの技術の一部はLLNに当てはまる可能性があるが、ほとんどは、帯域幅(制御プレーンのオーバーヘッド)、メモリ(状態の保守)、および/またはCPUの処理の点でコストが高すぎるために好適でない。確かに、パケットのカラーリングのためにポリシーが指定されなければならず、キュー技術およびWREDなどの混雑回避アルゴリズムがノード上で構成されなければならない。そのようなアルゴリズムは、トラフィックのパターン、リンクレイヤの特性、およびそれぞれの個々のデバイスを構成するためのいくつかのパラメータに関連するノードのリソースの深い知識を必要とする。

【0040】

本明細書において説明される技術はネットワークトラフィックがルート/LBRを通過するLLNに関して示されるが、概して、本明細書において説明される技術は、任意のネットワーク、特に任意の制約されたネットワークに適用され得ることに留意されたい。たとえば、図5に示されるように、(たとえば、LLNのLBRのような)すべてのトラフィックが通される中央ノードを持たないネットワーク100は、本明細書において説明される技術によってネットワーク内のすべての潜在的なトラフィックが監視され、ルーティングされ得ることを保証するためにネットワーク全体を通じて戦略的に重要な位置にある1つまたは複数のシンク500 (たとえば、ノード1、23、および32)を有する可能性がある。そのような環境において、シンクは、本明細書において説明される技術を実行するために独立してまたは(たとえば、互いにまたはNMSと)協力して動作し得る。

【0041】

本明細書において説明される技術は、たとえば、ルーティングプロセス244と連携して本明細書において説明される技術に関連する機能を実行するためにプロセッサ220 (またはインターフェース210の独立したプロセッサ)によって実行されるコンピュータが実行可能な命令を含み得る図2に示された「QoS監視」プロセス248/248aに従うなどしてハードウェア、ソフトウェア、および/またはファームウェアによって実行される可能性がある。たとえば、本明細書の技術は、様々なPLCプロトコルまたはワイヤレス通信プロトコルなどの通常のプロトコルに対する拡張として扱われる可能性があり、したがって、それらのプロトコルを実行する当技術分野で理解される同様の構成要素によって処理される可能性がある。

【0042】

スマートユーティリティネットワークのための低送信電力チャネルおよび中送信電力チャネルのインターリーブ
LLNは、連邦政府によって規制される媒体を用いて通信する。米国においては、連邦通信委員会(FCC)が、無線周波数帯域の使用を規制する。連邦政府の規制の1つの重要な目的は、デバイスが通信媒体を効率的に共有することができることを保証することである。残念なことに、そのような規制は、各国で大きく変わる可能性があり、異なるネットワーキングアーキテクチャ、プロトコル、およびアルゴリズムの必要性を生み出す。1つの例示的な実施形態において、そのような規制は、送信電力、送信継続時間、搬送波感知時間、送信と送信の間の休止の継続時間、および/またはデューティサイクルに基づいて通信を制限する。たとえば、FCCは、915MHz帯においてデューティサイクル(たとえば、20s中に<400ms)およびチャネルホッピング(たとえば、一様でランダムなチャネル選択)の制限を課す。

【0043】

日本においては、電波産業会(ARIB)が、無線スペクトルの使用を規制する。ARIBは、日本においてスマートユーティリティネットワーク(SUN)で使用するために920MHz帯域内のスペクトルを割り当てた。ARIBは、送信の継続時間、休止の継続時間、および任意の1時間当たりの放出時間の和を規定することによって送信を規制する。規定は、送信のための送信電力およびチャネル帯域幅に依存する。たとえば、ARIBは、チャネルBW = 200kHzによって以下の制限を課す。
1)「中」送信電力(>20mWおよび<250mW)に関して
A) 920.5〜922.3MHz帯域において、>5msの搬送波感知、送信の継続時間<4s、休止の継続時間>50ms、任意の時間当たりの放出時間の制限なし。
B) 922.3〜923.5MHz帯域において、>128μsの搬送波感知、送信の継続時間<400ms、任意の時間当たりの放出時間<360s。
2)「低」送信電力(<20mW)
A) 920.5〜923.5MHz帯域において、>5msの搬送波感知、送信の継続時間<4s、休止の継続時間>50ms、任意の時間当たりの放出時間の制限なし。
B) 922.3〜928.1MHz帯域において、>128μsの搬送波感知、送信の継続時間<400ms、任意の時間当たりの放出時間<360s。

【0044】

上の両方の例においては、搬送波感知<5msである場合、休止の継続時間は、送信の継続時間に依存する。送信の継続時間が>200msと<400msとの間である場合、休止の継続時間は前の送信の継続時間の10倍以上である。送信の継続時間が>6msと<200msとの間である場合、休止の継続時間は2msである。送信の継続時間が<6msである場合、休止の継続時間は必要とされない。

【0045】

ARIBの規制とFCCの規制との間には顕著な違いが存在する。たとえば、ARIBの規制は、2つの異なる送信電力を提供する。中送信電力は、より範囲が広いがより少ないチャネルを提供する(15チャネル対38チャネル)。対照的に、FCCは、周波数帯域全体で単一の送信の制限を規定する。別の例において、ARIBは、より低い周波数チャネルがより高い周波数チャネルとは異なる送信パラメータを有することを定める。より低い周波数チャネルは、優先順位を付けられた受動タグシステム(passive tags system)と共有される。より低い周波数チャネルは、より長い搬送波感知時間を有するが、より長い継続時間も有し、任意の時間当たりの放出時間の制限は持たない。対照的に、FCCの規制は、周波数帯域全体で一様なパラメータを規定する。さらに別の例において、ARIBの規制は、低送信電力が922.3〜928.1MHz帯域において送信パラメータに重なりを有し、搬送波感知の継続時間に応じてどちらかをサポートする能力を提供することを定める。

【0046】

概して、LLNは、チャネルホッピングするリンクレイヤを用いて通信する。この要件は、規制遵守と、優れたスペクトル効率を実現することとの両方のために生み出される。例示的な実施形態において、ネットワーク(たとえば、コネクティッドグリッドメッシュ(CG Mesh: Connected Grid Mesh))は、チャネルホッピング手法を実装する。各ネットワークインターフェースは、そのネットワークインターフェース独自のユニキャスト受信スケジュールを決定する。近隣のデバイスは、ユニキャストフレームを適切に伝達するためにそのネットワークインターフェースのユニキャストスケジュールと同期しなければならない。各デバイスにそのデバイス独自のスケジュールを独立して決定させることによって、近隣の送信側-受信側の対は、異なるチャネル上で同時に通信することができる。1つの例示的実施形態において、さらに、ネットワークは、ネットワーク全体に及ぶブロードキャストスケジュールを被せ、すべてのデバイスが、同じチャネルホッピングスケジュールに同期される。ブロードキャストスケジュールは、時間のわずかな部分(たとえば、25%)の間にのみアクティブであるが、単一の送信が任意の数の近隣のノードに到達することができるので効率的なブロードキャストを可能にする。1つの例示的実施形態において、このハイブリッド式の手法は、効率的なブロードキャスト通信も可能にしながら、ネットワークがユニキャスト通信に関するスペクトル効率を最大化することを可能にする。

【0047】

本明細書において説明される技術によれば、リンクレイヤメカニズムが、単一のLLNにおいて中および低送信電力を利用するために提供される。たとえば、デバイスは、デフォルトで、標準的なチャネルホッピングスケジュールに関して中送信電力チャネルのみを使用する。しかし、デバイスは、低送信電力を用いて近隣のノードに送信することが可能であると判定するとき、さらなるチャネルの多様性を活用するために低送信電力チャネルを使用するように一時的に切り替えるように近隣のノードに要求するメッセージを動的に送信し得る。

【0048】

例示的な実施形態において、受信側デバイスは、中送信電力のために使用可能なチャネル(たとえば、920MHz帯域のARIBチャネル23〜38)をリスニングする。この実施形態において、デバイスは、中送信電力チャネルからのランダムシーケンスを使用することをともなう標準的なチャネルホッピングスケジュールを使用する。標準的なチャネルホッピングスケジュールは、受信側デバイスが任意の時間に任意の近隣のノードから中送信電力の送信を受信することを可能にし、LLN内のすべてのデバイスの間の信号対雑音比(SNR)および通信範囲を最大化する。

【0049】

別の例示的な実施形態においては、異なるチャネルまたはチャネルホッピングシーケンスをリスニングするように受信するデバイスに命令する新しい制御メッセージが送信される。送信側デバイスは、その送信側デバイスが低送信電力チャネルを用いて近隣のノードと通信することができると判定する。送信側デバイスは、低送信電力チャネルまたは低送信電力チャネルホッピングシーケンスを指定する制御メッセージを受信側デバイスに送信し、それから、その低電力チャネル上でデータメッセージを送信する。制御メッセージを送信することによって、大きなデータパケットを送信するコストは、異なるチャネル上で生み出される可能性がある。一実施形態において、制御メッセージは、フレーム開始デリミタ(SFD)を検出するのに十分なだけ長くリスニングすべきチャネルを示し得る。別の実施形態において、制御メッセージは、チャネルをどれだけ長くリスニングすべきかを示し、連続した複数のデータフレームの送信を可能にし得る。さらに別の実施形態において、制御メッセージは、制限された期間の間使用すべき低送信電力チャネルホッピングシーケンスまたはスケジュールを示す可能性がある。制御メッセージは、その他の送信パラメータ(たとえば、データレートおよび変調)を含む可能性もある。

【0050】

さらに別の例示的な実施形態においては、肯定応答メッセージが、制御メッセージに応答して送信される。この実施形態において、送信側デバイスは、制御メッセージの肯定応答を受信しない場合、データパケット自体のための送信時間を無駄にすることを避けることができる。一実施形態において、肯定応答メッセージは、制御メッセージが送信された同じチャネル上で送り返される可能性がある。別の実施形態において、肯定応答メッセージは、制御メッセージにおいて示されたチャネルホッピングシーケンスを用いて送り返される可能性がある。さらに別の実施形態において、肯定応答メッセージは、低送信電力チャネル上で送り返され、増やされたチャネルの多様性をよりうまく利用する可能性がある。

【0051】

さらに別の例示的な実施形態において、デバイスは、低送信電力チャネル上で送信すべきか否かを動的に選択する。一実施形態において、デバイスは、予測されるレイテンシーに基づいて低送信電力チャネル上で送信すべきか否かを判定する。この実施形態においては、制御メッセージを送信し、データパケットを送信する前に任意で肯定応答を受信することが、大きな通信レイテンシーを付け加える可能性がある。高い優先順位のまたはレイテンシーに影響されやすいパケットに関して、デバイスは、単純に中送信電力チャネルを用いてデータパケットを送信することを選択する可能性がある。しかし、中送信電力チャネルは、通信範囲および堅牢性を高めるためにより低いデータレートに調整される可能性がある。低送信電力チャネル上で送信するときにより高いデータレートが使用される場合、デバイスは、低送信電力チャネルに切り替えることに関するコストと利益との折り合いを付けなければならない。そのような場合、特にデータパケットが大きいときは、低送信電力チャネルを使用することがやはり有益である可能性がある。

【0052】

別の例示的な実施形態において、デバイスは、リンクの品質に基づいて低送信電力チャネル上で送信すべきか否かを判定する。低送信電力チャネル上で送信することは、範囲および堅牢性を低下させる可能性がある。一実施形態において、受信側は、制御メッセージの受信信号強度インジケータ(RSSI)または位置/品質インジケータ(LQI)を評価し、送信側デバイスがデータメッセージの送信のために低送信電力チャネルに切り替えるべきか否かを肯定応答メッセージにおいて示す可能性がある。別の実施形態においては、制御メッセージおよび/またはデータメッセージの肯定応答メッセージが、将来の送信において送信側デバイスが使用するリンク品質情報(たとえば、RSSIおよび/またはLQI)を含む可能性がある。どちらの場合も、パラメータのうちの1つまたは複数に関する構成可能な閾値が、低送信電力チャネルを使用すべきか否かを判定するために使用される。一実施形態において、閾値は、パケットの優先順位に基づいて調整される可能性がある。別の実施形態において、閾値は、観測されたトラフィックのメトリックに基づいて動的に調整される可能性がある。

【0053】

例示的な実施形態において、デバイスは、デフォルトのチャネルホッピングシーケンスにおいてどの中電力チャネルを使用すべきかを動的に選択する。たとえば、より低い送信電力のチャネル(たとえば、ARIBのチャネル2332)は、搬送波感知の継続時間が>128μsであるより高い送信電力のチャネル(たとえば、ARIBのチャネル3338)よりもずっと長い搬送波感知の継続時間(>5ms)を有する。結果として、より高い送信電力のチャネルが、より高い優先順位のトラフィックをより失敗なく伝達するために使用され得る。また、より低い送信電力のチャネルは、920MHz帯域において受動タグシステムと共有される。一実施形態においては、擬似ランダムなチャネルホッピングシーケンスが、各スロットにおいてより低い送信電力のチャネルおよびより高い送信電力のチャネル(たとえば、ARIBのチャネル2332および3338)を使用することを交互に繰り返し、各帯域/送信電力からのスロットが最大で1スロット離されることを保証し得る。別の例示的な実施形態においては、擬似ランダムなシーケンスが、より低い/より高い送信電力のスロットの比を変えて、各種類のトラフィックに割り当てられる容量を変更する可能性がある。例示的な実施形態において、擬似ランダムなシーケンスパラメータは、IEEE 802.15.4eの強化型ビーコン(Enhanced Beacon)内で運ばれるネットワーク全体に及ぶ構成である可能性がある。別の例示的な実施形態において、擬似ランダムなシーケンスは、1つまたは複数のデバイスによって管理される。

【0054】

住宅用メータの読み取りおよび配電自動化(DA)のアプリケーションは、異なるネットワークの要求を有する。たとえば、住宅用メータの数および密度は、DAのエンドポイントの数よりも遙かに多い。しかし、住宅のメータリングのアプリケーションに比べて、DAのアプリケーションは、概して、より低いレイテンシーの通信を必要とし、停電などの特定のイベントの間に動作することが好ましい。

【0055】

本明細書において説明される技術によれば、低送信電力チャネルと中送信電力チャネルとの両方が、チャネルホッピングによって同じ無線ハードウェアを用いてサポートされる。例示的な実施形態において、チャネルホッピングスケジュールは、各デバイスがサポートするトラフィックフローの種類に基づいて各デバイスのために構成される。たとえば、DAトラフィックを運ぶデバイスは、中送信電力チャネルを使用するように構成される。

【0056】

例示的な実施形態において、チャネルホッピングシーケンスは、2つのインターリーブされたチャネルホッピングシーケンスに分割される。たとえば、単一のチャネルホッピングシーケンスC(1)、C(2)、...、C(n)を有するのではなく、新しいチャネルホッピングシーケンスCa(1)、Cb(1)、Ca(2)、Cb(2)、...、Ca(n)、Cb(n)が定義される。この例において、チャネルは、各シーケンスを交互に繰り返すことに留意されたい。例示的な実施形態において、割り当ておよび周期性は任意である可能性がある。たとえば、シーケンスCa(x)からの3つの連続するスロットがあり、それから、シーケンスCb(x)からのスロットが1つだけある可能性がある。別の例示的な実施形態においては、チャネルのインターリーブが、規則的なパターンに従う必要がない。たとえば、シーケンスは、Ca(x)からの2つの連続するスロットおよびシーケンスCb(y)からの5つの連続するスロットを有する可能性がある。別の例示的な実施形態において、チャネルホッピングスケジュールは、ある継続時間の間、Ca(x)またはCb(y)のみを含む可能性がある。

【0057】

例示的な実施形態においては、一方のチャネルホッピングシーケンスが、低送信電力通信のために使用され、他方のチャネルホッピングシーケンスが、中送信電力通信のために使用される。この実施形態においては、単一のデバイスが、異なる時間に低送信電力チャネルかまたは中送信電力チャネルかのどちらかを用いて近隣のデバイスが送信することを可能にし得る。たとえば、Cl(x)は、低送信電力チャネルを表し、Cm(y)は、中送信電力チャネルを表す。そばにある近隣のデバイスは、Cl(x)がアクティブであるときにはいつでも低通信電力チャネルを用いて通信し得る。それよりも遠い近隣のデバイスは、Cm(y)がアクティブであるときにはいつでも中送信電力チャネルを用いて通信し得る。

【0058】

別の例示的な実施形態においては、チャネルホッピングシーケンスが、近隣のデバイスに伝達される。例示的な実施形態においては、情報が、(たとえば、IEEE 802.15.4e2012を用いるとき)情報要素内で伝達され得る。チャネルホッピング情報は、いくつかの方法で符号化され得る。たとえば、ARIB Japanにおいては、チャネル番号が、送信出力(すなわち、低または中)を定義する。加えて、デバイスが、チャネルシーケンス機能(channel-sequence function)についてより多くの情報を提供する可能性がある。たとえば、1つのチャネルシーケンス機能は、より少ない中送信電力チャネルを生成する可能性があり、別のチャネルシーケンス機能は、より多くの中送信電力チャネルを生成する可能性がある。

【0059】

別の例示的な実施形態において、ネットワークは、2つの重なり合わないブロードキャストスケジュールを利用する。たとえば、ネットワークは、低送信電力のために1つのブロードキャストスケジュールを利用し、中送信電力のために別のブロードキャストスケジュールを利用する。別の例示的な実施形態において、ネットワークは、中送信電力チャネルのみを含む単一のブロードキャストスケジュールを利用する。たとえば、この構成は、静的に構成されるかまたはIEEE 802.15.4e2012の強化型ビーコン内で伝達される可能性がある。別の例において、構成は、フィールドエリアルータ(FAR: Field Area Router)またはネットワーク管理システム(NMS)上で構成される可能性がある。別の実施形態において、この構成は、観測されたトラフィックの特性に基づいて自動的に構成される可能性がある。

【0060】

さらに別の例示的な実施形態において、チャネルホッピングシーケンスは、イベント(たとえば、停電イベント)に基づいて動的に切り替わっている。この実施形態においては、低送信電力チャネルと中送信電力チャネルとの両方をリスニングしていたデバイスが、停電イベントなどの指定されたイベントの間、中送信電力チャネルの割合がより高いシーケンスに切り替わる可能性がある。たとえば、デバイスは、中送信電力チャネルをリスニングするように切り替わる。この動的な切り替えは、公益事業者がDAデバイスに関するトラフィックを優先させ、DAに関するトラフィックの堅牢性を高めたい場合に有益である。

【0061】

別の例示的な実施形態においては、印を付けられたパケットが、低送信電力チャネルまたは中送信電力チャネルにマッピングされる。例示的な実施形態において、中電力送信チャネルは、より高い送信電力を提供するが、同じだけ大きなチャネルの多様性は提供しない。低送信電力チャネルおよび中送信電力チャネルを効果的に利用するために、デバイスは、トラフィックを異なるチャネルにマッピングする。たとえば、IPv6を使用するとき、差別化サービスコードポイント(DSCP: differentiated service code point)の印が、低送信電力チャネルまたは中送信電力チャネルにマッピングされる。1つの例示的な実施形態において、マッピングは、構成(たとえば、DHCPv6またはNMSの登録)を通じて静的に与えられる可能性がある。別の例示的な実施形態において、デバイスは(ローカルでまたはFAR/NMSにおいて集中的に)そのデバイスが転送しているトラフィックを観測し、トラフィックを動的にマッピングする可能性がある。

【0062】

例示的な実施形態において、(1)低送信電力チャネルのみを含むチャネルホッピングスケジュールを用いてリスニングする住宅用メータ(たとえば、住宅用メータに送信するすべてのデバイスは低送信電力を用いて送信する)、(2)低送信電力チャネルのみを含むチャネルホッピングスケジュールを用いてリスニングする、住宅用メータのための接続性を提供するために主に使用されるBBUのないレンジエクステンダ(range extender) (たとえば、BBUのないレンジエクステンダに送信するすべてのデバイスは低送信電力チャネルを用いる)、(3)低送信電力チャネルと中送信電力チャネルとの混合を含むチャネルホッピングスケジュールを用いてリスニングするDAゲートウェイ(たとえば、すべてのデバイスは低送信電力チャネルかまたは中送信電力チャネルかのどちらかを用いてDAゲートウェイに送信する可能性がある)、および(4)低送信電力チャネルと中送信電力チャネルとの混合を含むチャネルホッピングスケジュールを用いてリスニングするBBUのあるレンジエクステンダ(たとえば、すべてのデバイスは低送信電力チャネルかまたは中送信電力チャネルかのどちらかを用いてBBUのあるレンジエクステンダに送信する可能性がある)を含むネットワークアーキテクチャが構築される。

【0063】

この実施形態においては、低送信電力チャネルが、住宅用メータを接続するために主に使用される。低送信電力チャネルはより大きな帯域幅によるより大きなチャネルの多様性および削減された送信電力による空間的な多様性を提供するので、それらの多様性は、住宅用メータの予測される高い密度によく適している。中送信電力チャネルは、接続されたDAデバイスのために主に使用される。中送信電力チャネルは、より広い通信範囲およびより大きな信号対雑音比を提供し、より低いレイテンシーおよびより高い堅牢性を提供する。住宅のメータリングのトラフィックは、メッセージを送信するとき、DAゲートウェイおよび/またはBBUのあるレンジエクステンダと通信する可能性がある。それらは、概して、低送信電力チャネルを用いてメッセージを送信するのみであるが、任意の警報または警告に関しては中送信電力チャネルを用いてメッセージを送信する可能性もある。DAトラフィックは、BBUのあるレンジエクステンダおよび中送信電力チャネルのみを利用する。したがって、リンクレイヤが、各デバイスの能力に基づいて2つの異なるアプリケーションの間にスペクトルリソースを効果的に割り当てる。

【0064】

本明細書において説明される特定の技術によれば、ARIB Japanの規制内の異なるアプリケーションの要件をサポートするルーティングアーキテクチャが提供される。例示的な実施形態においては、複数のルーティングトポロジーが、同じトランシーバ上で送信するときに異なる周波数範囲によって提供される異なる特性を利用するために構築される。しかし、トポロジーの利用は、そのトポロジーが構築されたリンクの種類に必ずしも限定されない。たとえば、中送信電力リンク上で構築されたルーティングトポロジーが、中送信電力チャネルの利用を減らすために、可能な場合、低送信電力リンクを利用する可能性がある。

【0065】

例示的な実施形態においては、複数のルーティングトポロジーが、2つのチャネルホッピングシーケンス上で構築される。たとえば、2つのルーティングトポロジーが定義される。低送信電力チャネルを介して転送するために1つのトポロジーが定義され、中送信電力チャネルを介して転送するために別のトポロジーが定義される。生成するときに、DIOメッセージが低送信電力チャネルを用いて送信されるべきかまたは中送信電力チャネルを用いて送信されるべきかを示すためにDIOパケットに印を付けるようにプログラミングが修正される。別の例示的な実施形態においては、DIOメッセージは近隣のノードを発見し、ルーティング情報を伝播するために使用されるのみであるので、中送信電力チャネルを用いてすべてのDIOメッセージが送信される。

【0066】

別の例示的な実施形態において、デバイスは、より低いチャネルの多様性およびより大きな干渉の範囲を有する中送信電力リンクへの負荷を減らすために、可能な場合、低送信電力リンクに動的に切り替わる。中送信電力トポロジーを構築するとき、中送信電力リンクのみを使用することと、中送信電力チャネルを使用して通信を確立することとによってRPLコンポーネントが始まる可能性がある。しかし、(たとえば、IPv6のNS、キープアライブなどを送信することによって)リンクの品質を評価するとき、RPLコンポーネントは、近隣のデバイスとの低送信電力通信が可能であるか否かを判定する。可能である場合、RPLコンポーネントは、低送信電力リンクに切り替わる可能性がある。結果として、「中間送信電力トポロジー」は、低送信電力チャネルを有するいくつかのリンクを利用する可能性がある。低送信電力リンクまたは中送信電力リンクを動的に選択することによって、必要とされるSLAを満たすためにDODAGの最適性を確保しながら、可能なときにはいつでも低送信電力を使用して所望の特性を提供するための折り合いが見つけられ得る。

【0067】

上記の構成要素はさらなるPHYテクノロジー(たとえば、PLC)を使用することに一般化されることに留意されたい。たとえば、デバイスが実際に3つの異なるPHYレイヤ(802.15.4低送信電力、802.15.4中送信電力、およびP1901.2)をサポートするTEPCOにおいては、3つの種類のリンクの各々を利用する3つのルーティングトポロジーが構築され得る。2つの802.15.4リンクは、仮想的であり、単一のRFフロントエンドによって提供される。例示的な実施形態においては、ルーティングトポロジーが損なわれずに完全なままである限り異なるPHYを用いることに動的に切り替えることが可能である。

【0068】

別の例示的な実施形態において、トラフィックは、異なるルーティングトポロジーに動的にマッピングされる。1つの例示的な実施形態においては、デバイスが、トポロジーを横切ってルーティングときに通信の特性(たとえば、レイテンシー)を判定するための調査を生成する。別の例示的な実施形態においては、デバイスが、パケットの時間を記録するためのIPv6オプションを含み得る。どちらかの実施形態を用いると、フィールドエリアルータ(FAR)またはネットワーク管理システム(NMS)が、どちらのトポロジーが必要とされるSLAをサポートするかを判定し得る。たとえば、低送信電力チャネルを用いるルーティングトポロジーは、ネットワークの直径が小さく(すなわち、低送信電力が問題でない)、ノードの密度が高い(すなわち、より大きなチャネルの多様性)場合に低レイテンシートラフィックを転送するのにより適する可能性がある。この情報を用いて、FAR/NMSは、トラフィックを生成するときにどのトポロジーを使用すべきかを各ノードに示す(たとえば、IPv6のDSCPの印)。別の例示的な実施形態において、FAR/NMSは、1+1またはプライマリ/バックアップ技術を使用するときに使用するための複数のトポロジーを示す可能性がある。

【0069】

例示的な実施形態において、デバイスは、単一のRFフロントエンドによってサポートされる異なる(仮想的または物理的)リンクテクノロジーを用いて複数のルーティングトポロジーを作成する。同じ物理的ハードウェアを利用する異なるリンクテクノロジー(たとえば、低送信電力および中送信電力)を使用するとき、DIOは、ただ1つのリンクテクノロジー(たとえば、中送信電力)を用いて送信される可能性がある。ルーティングトポロジーを確立した後、デバイスは、単一のリンクの異なるネットワークインターフェースを使用すること(たとえば、主に中送信電力のために構築されたDAG上の中電力ではなく低送信電力を使用すること)に動的に切り替わる。どのトラフィックがどのルーティングトポロジーにマッピングされるべきかを判定するために、トラフィックのメトリックが使用される。

【0070】

図6は、特定の例示的な実施形態によるネットワーク通信中に要求に応じて中電力から低電力チャネルに切り替えるための方法600を示すブロック流れ図である。方法600は、図1〜図5に示された構成要素を参照して説明される。

【0071】

例示的な実施形態において、デバイス200は、ネットワーク100を介して1つまたは複数の受信者デバイス/ノード200bに1つまたは複数のデータパケットを送信する送信側デバイス/ノード200aである。特定の例示的な実施形態において、送信側デバイス200aおよび受信側デバイス200bは、同じ無線ハードウェア上で低電力チャネルと中電力チャネルとの両方を用いて単一のネットワークを介して通信する。特定の例示的な実施形態において、ネットワークは、低電力および高損失ネットワーク(LLN)である。特定の例示的な実施形態において、LLNは、スマートユーティリティネットワークであり、ネットワークデバイス200は、住宅用メータと配電自動化(DA)デバイスとの組合せを含む。

【0072】

ブロック610において、ネットワークデバイス200が、ネットワークに関する中電力および低電力チャネルのルーティングトポロジーを定義する。方法610は、図7に示される方法に関連して以降でより詳細に説明される。

【0073】

図7は、図6のブロック610において触れられたように、特定の例示的な実施形態によるネットワークに関する中電力および低電力チャネルのルーティングトポロジーを定義するための方法610を示すブロック流れ図である。方法610は、図1〜図5に示された構成要素を参照して説明される。

【0074】

ブロック710において、送信側デバイス200aが、定義された目的機能に従って中電力チャネルを介してルータアドバータイズメントメッセージを送信する。目的機能は、送信側デバイス200a上で定義された可能性があり、またはルートネットワークデバイスまたはネットワーク管理システム130上で定義され、ルートネットワークデバイスまたはネットワーク管理システム130から受信された可能性がある。特定の例示的な実施形態において、ネットワーク100は、複数の送信側デバイス200を含み得る。目的機能は、ネットワークが含むべきノード、親、およびバックアップの親の数などの、ネットワークを構築するための規則を規定する。ルーティングプロトコルは、DAG情報などのネットワーク構造情報をやりとりするための1組の制御メッセージを規定することによって目的機能を実装する。たとえば、送信側デバイス200aは、送信側デバイス200aの範囲内にある近隣の受信側デバイス200bを特定するために中電力チャネルを用いてDODAG情報オブジェクト(DIO)メッセージを伝達し得る。

【0075】

ブロック720において、送信側デバイス200aの中電力チャネルの範囲内の1つまたは複数の受信側デバイス200bが、中電力チャネルを介してルータアドバータイズメントメッセージを受信する。それから、受信側デバイス200bは、ルータアドバータイズメントメッセージ内で指定されたルーティングプロトコルを処理して、受信側デバイス200bがネットワークに加わるべきかどうかを判定する。たとえば、受信側デバイス200bは、ルータアドバータイズメントメッセージからの入力を用いて予め定義されたアルゴリズムを実行して、受信側デバイス200bがネットワークに加わることに関して目的機能によって定義された基準を満たすかどうかを判定し得る。

【0076】

ブロック730において、ルータアドバータイズメントメッセージを受信し、ネットワークに加わると判断した各受信側デバイス200bが、中電力チャネルを介して、またはルータアドバータイズメントメッセージ内で指定されたチャネルを介してルータアドバータイズメントメッセージの受信を確認するための応答メッセージを送信側デバイス200aに送信する。応答メッセージは、受信側デバイス200bに関する位置情報を含み得る。たとえば、位置情報は、ネットワーク構造情報の階層内で受信側デバイス200bの位置を示す可能性がある。

【0077】

ブロック740において、送信側デバイス200aが、中電力チャネルを介して、またはルータアドバータイズメントメッセージ内で指定されたチャネルを介して受信側デバイス200bから1つまたは複数の応答メッセージを受信する。特定の例示的な実施形態において、応答メッセージの各々は、受信側デバイス200bがネットワークに加わり、送信側デバイス200aとのリンクを形成したことを示す。

【0078】

ブロック750において、送信側デバイス200aが、ネットワークに加わった受信側デバイス200bを含むようにネットワーク構造情報を更新する。たとえば、DAG情報が、ネットワークに加えられた新しい受信側デバイス200bを反映するために更新される。1つの例示的な実施形態において、送信側デバイス200aは、ルートデバイスとどのようにして通信するかを知る必要があるだけであり、どのデバイスがネットワーク構造内でその下にあるかを知る必要がない場合、非記憶モードで動作する可能性がある。したがって、送信側デバイス200aは、送信側デバイス200aに更新ネットワーク構造情報を記憶するのではなく、受信側デバイス200bの応答メッセージをルートネットワークデバイスまたはネットワーク管理システムに転送する。別の例示的な実施形態においては、送信側デバイス200aが、記憶モードにおいて動作し、受信側デバイス200bからの応答内で提供されたネットワーク構造情報に基づいて送信側デバイス200aに記憶されたネットワーク構造情報を更新する可能性がある。記憶モードで動作するとき、送信側デバイス200aは、送信側デバイス200aに記憶されたネットワーク構造情報を更新することに加えて、ルートデバイスに応答メッセージを伝達する可能性もある。複数の送信側デバイス200aにまたがって定義された、またはルートネットワークデバイスまたはネットワーク管理システム130において集中的に定義された更新されたネットワーク構造情報は、ネットワークに関する中電力チャネルのトポロジーを定義する。

【0079】

ブロック760において、受信側デバイス200bが、ネットワーク構造情報から、目的機能によって定義された要件が満たされたかどうかを判定する。たとえば、現在送信側デバイス200aとリンクされている受信側デバイス200bが、目的機能から、さらなる受信側デバイス200bがネットワーク100に追加される必要があるかどうかを判定することができる。さらなる受信側デバイス200bがネットワーク100に追加される必要がある場合、方法は、ブロック710に戻り、ブロック710から750が、現在送信側デバイス200aとして働いている受信側デバイス200bの観点で繰り返される。

【0080】

別の例示的な実施形態においては、2つの別々の目的機能が定義される。第1の目的機能は、中電力チャネルのルーティングトポロジーに関するネットワーク構造の要件を定義し、第2の目的機能は、低電力チャネルのルーティングトポロジーに関するネットワーク構造の要件を定義する。中電力および低電力の目的機能は、送信側デバイス200a、ルートデバイス、ネットワーク管理システム130、またはシステムオペレータによって定義され得る。第1のインスタンス識別子が、中電力チャネルの目的機能を実装するルーティングプロトコルによって定義されたネットワーク構造情報に割り振られ、第2のインスタンス識別子が、低電力の目的機能を実装するルーティングプロトコルによって定義されたネットワーク構造情報に割り振られる。ブロック710および750は、送信側デバイス200aが中電力チャネル上でルータアドバータイズメントを伝達し、低電力チャネル上で別個のルータアドバータイズメントを伝達することを除いて、上で概要を示されたように進行する。上で概要を示されたように、中電力チャネルのアドバータイズメントに肯定応答する受信側デバイスは、中電力ネットワーク構造情報のインスタンスにマッピングされ、低電力チャネルのアドバータイズメントに肯定応答する受信側デバイスは、低電力ネットワーク構造情報のインスタンスにマッピングされる。

【0081】

ブロック760に戻ると、さらなる受信側デバイス200bがネットワークに追加される必要がない場合、方法610は、ブロック770に進む。

【0082】

ブロック770において、ネットワークデバイス200が、同じネットワークに関する低電力チャネルのルーティングトポロジーを定義する。方法770は、図8に示される方法に関連して以降でより詳細に説明される。方法770は、中電力および低電力の目的機能が上記のブロック710〜750において使用される場合は必要とされない。

【0083】

図8は、図7のブロック770において触れられたように、特定の例示的な実施形態によるネットワーク100に関する低電力チャネルのトポロジーを定義するための方法770を示すブロック流れ図である。方法770は、図1〜図5に示された構成要素を参照して説明される。

【0084】

ブロック810において、ネットワーク100内の送信側デバイス200aが、ブロック710〜750において上で定義されたように、それぞれの近隣の受信側デバイス200bのリンクの品質を評価する。たとえば、送信側デバイス200aは、受信側デバイス200bに試験メッセージを伝達する可能性がある。たとえば、試験メッセージは、IPv6のNSメッセージまたはキープアライブメッセージを含む可能性がある。

【0085】

ブロック820において、送信側デバイス200aが、試験メッセージが受信されたかどうかを判定する。たとえば、受信側デバイス200bに送信される試験メッセージは、受信側デバイス200bが試験メッセージを受信することに応答して肯定応答メッセージを送信するための命令を含み得る。送信側デバイス200aは、定義された期間、肯定応答メッセージを待つ可能性がある。肯定応答メッセージが受信されない場合、方法770は、ブロック850に進む。ブロック850は、下でさらに詳細に説明される。肯定応答メッセージが受信される場合、方法は、ブロック830に進む。

【0086】

ブロック830において、送信側デバイス200aが、送信側デバイス200aと受信側デバイス200bとの間のリンクの品質が低電力チャネル通信をサポートするのに十分であるかどうかを判定する。たとえば、リンクの品質は、送信側デバイス200aおよび受信側デバイス200bが低電力チャネル通信に関する定義された信号品質の閾値以内であることを示す可能性がある。送信側デバイス200aは、データ伝送レートおよびレイテンシーなどであるがこれらに限定されないその他のメトリックをさらに評価する可能性がある。特定の例示的な実施形態において、試験メッセージは、送信側デバイス200aと受信側デバイス200bとの間のリンクの品質を送信側デバイス200aが評価することを支援するために受信側デバイス200bが肯定応答に信号品質に関する特定のデータを含めるための命令を含み得る。

【0087】

送信側デバイス200aと受信側デバイス200bとの間のリンクの品質が低電力信号の閾値未満である場合、方法770は、ブロック850に進み、送信側デバイス200aが、評価すべきその他の受信側デバイス200bへのさらなるリンクがあるかどうかを判定する。

【0088】

ブロック830に戻ると、送信側デバイス200aと受信側デバイス200bとの間のリンクの品質が低電力信号の閾値を超える場合、方法770は、ブロック840に進む。

【0089】

ブロック840において、送信側デバイス200aが、送信側デバイス200aが低電力チャネル通信によって通信することができる周りの受信側デバイス200bのトポロジーをマッピングする。たとえば、送信側デバイス200aは、送信側デバイス200aが低電力チャネルを用いて通信することができるリンクを示すためにネットワーク構造情報を更新する可能性がある。結果として、上のブロック750において定義された中電力トポロジーは、より低い電力の送信によって一部のリンクを利用し、それによって、単一のRFフロントエンドを用いて中電力および低電力通信をサポートし得る。そして、低電力または中電力通信の使用が、図6のブロック630から665に関連して下でさらに詳細に説明されるように、ネットワークトラフィックのメトリックまたは所与のデータの種類に応じて動的に決定され得る。

【0090】

ブロック850において、送信側デバイス200aが、その他の受信側デバイス200bへのさらなるリンクが評価されるために残っているかどうかを判定する。送信側デバイス200aが評価すべきさらなるリンクを検出する場合、方法770はブロック810に戻り、ブロック810〜840が繰り返される。送信側デバイス200aが評価すべきさらなるリンクを検出しない場合、方法770は図7のブロック780に進む。

【0091】

図8において触れられた方法770が、さらなるトポロジーをマッピングするために使用され得る。たとえば、ネットワークデバイス200が実際に3つの異なる物理レイヤ(802.15.4低電力、802.15.4中電力、およびP1901.2)をサポートするTEPCOの場合、方法770が、さらなるトポロジーをマッピングするために繰り返され得る。特定の例示的な実施形態においては、ルーティングトポロジーが損なわれずに完全なままである限り異なる物理レイヤを用いることに動的に切り替えることが可能である。

【0092】

図7に戻ると、ブロック780において、ネットワーク管理システム130などのネットワーク制御デバイスが、中電力および低電力のルーティングトポロジーの通信の特性およびネットワークの直径を判定する。方法780は、図9に示される方法に関連して以降でより詳細に説明される。

【0093】

図9は、図7のブロック780において触れられたように、特定の例示的な実施形態によるトラフィックを異なるルーティングテクノロジーに動的にマッピングするための方法780を示すブロック流れ図である。方法780は、図1〜図5に示された構成要素を参照して説明される。

【0094】

ブロック910において、ネットワークデバイス200が、ネットワークの中電力チャネルのルーティングトポロジーを横切って試験メッセージを伝達する。特定の例示的な実施形態において、ネットワークデバイス200は、ネットワーク管理システムデバイス130である。たとえば、ネットワークデバイス200は、端末受信側デバイス200bに試験メッセージを伝達する可能性がある。試験メッセージは、端末受信側デバイス200bが試験メッセージを受信した後に応答メッセージを伝達するための命令を含み得る。

【0095】

ブロック920において、端末受信側デバイス200bが、中電力チャネルのルーティングトポロジーを介してネットワークデバイス200から試験メッセージを受信し、応答メッセージを準備する。

【0096】

ブロック930において、端末受信側デバイス200bが、試験メッセージが受信された同じ中電力チャネルのトポロジーを介してネットワーク制御デバイス130に応答メッセージを伝達する。応答メッセージは、制御メッセージの受信の時間などのさらなる情報を含み得る。

【0097】

ブロック940において、ネットワークデバイス200が、受信側デバイス200bから応答メッセージを受信する。

【0098】

ブロック950において、ネットワークデバイス200が、中電力チャネルのルーティングトポロジーの通信の特性およびネットワークの直径を判定する。たとえば、ネットワーク管理デバイス130は、試験メッセージの受信の時間などの応答メッセージに含まれる情報を用いてネットワークのレイテンシーおよび直径を判定し得る。特定の例示的な実施形態において、ネットワークの直径は、データパケットまたはメッセージがルートネットワークデバイスなどの送信元のネットワークデバイス200から端末受信側デバイス200bまで移動するために必要とされるホップの数を指す。

【0099】

ブロック960において、ネットワークデバイス200が、ネットワークが低電力またはその他の電力チャネルのルーティングトポロジーも含むかどうかを判定する。ネットワークが低電力またはその他の電力チャネルのルーティングトポロジーを確かに含む場合、方法780はブロック910に戻り、試験メッセージが低電力またはその他の電力チャネルのルーティングトポロジーを介して端末受信側デバイス200bに伝達されることを除いてブロック910から950が繰り返される。

【0100】

ネットワークが低電力またはその他の電力チャネルのルーティングトポロジーを含まない場合、方法780は、ブロック960から図6のブロック620に進む。

【0101】

図6に戻ると、ブロック620において、ネットワーク管理デバイス130が、ネットワーク100を介した通信に関するチャネルホッピングスケジュールを定義する。チャネルホッピングスケジュールを定義するための方法620は、図10に示される方法に関連して以降でより詳細に説明される。

【0102】

図10は、図6のブロック620において触れられたように、特定の例示的な実施形態によるネットワークデバイス200に関するチャネルホッピングスケジュールを定義するための方法620を示すブロック流れ図である。方法620は、図1〜図5に示された構成要素を参照して説明される。

【0103】

ブロック1010において、ネットワーク管理デバイス130が、中電力および低電力チャネルホッピングスケジュールを定義する。1つの例示的な実施形態において、中電力チャネルホッピングスケジュールは、中電力チャネルのみを含み得る。同様に、低電力チャネルホッピングスケジュールは、低電力チャネルのみを含み得る。別の例示的な実施形態において、混合されたチャネルホッピングスケジュールが、インターリーブされた中電力チャネルと低電力チャネルとの混合を含み得る。たとえば、単一のチャネルホッピングシーケンスが、交互に入れ替わる中電力チャネルおよび低電力チャネルを含む可能性がある。割り当ておよび周期性は、任意である可能性がある。たとえば、混合されたチャネルホッピングスケジュールは、スケジュールシーケンスに3つの連続する中チャネルのスロットおよびただ1つの低電力チャネルのスロットを含む可能性がある。さらに、たとえば、変化するネットワークトラフィックのメトリックまたはデータの種類に応じて後の時間にパターンを変更することが可能である。たとえば、チャネルホッピングシーケンスは、低電力チャネルの送信が保証されるときに2つのネットワークデバイスの間の増加したトラフィックを可能にするためにより多くの低電力チャネルを含むように変更される可能性がある。交互に入れ替わる中電力チャネルおよび低電力チャネルを用いる混合されたチャネルホッピングシーケンスの使用は、単一のネットワークデバイス200が低電力チャネルかまたは中電力チャネルかのどちらかで近隣のネットワークデバイス200と通信することを可能にする。たとえば、近隣のネットワークデバイス200は、低電力チャネルが両方のデバイス上でチャネルホッピングシーケンスにおいてアクティブであるときにはいつでも低電力チャネルを用いて通信し、中電力チャネルが両方のデバイス上でチャネルホッピングシーケンスにおいてアクティブであるときにはいつでも中電力チャネルを用いて通信し得る。さらなるルーティングトポロジーを用いる実施形態においては、さらなるトポロジーに対応するためのスロットを用いる混合されたチャネルホッピングスケジュールを含むさらなるチャネルホッピングスケジュールが、それらのトポロジーのために定義され得る。

【0104】

ブロック1020において、ルートネットワークデバイス200が、チャネルホッピングシーケンスをネットワーク内のすべてのその他のネットワークデバイス200に伝達する。ルートネットワークデバイス200は、デフォルトのチャネルホッピングスケジュールを定義する可能性がある。1つの例示的な実施形態においては、すべてのネットワークデバイス200が、デフォルトの中電力チャネルホッピングスケジュールを使用する可能性がある。特定の例示的な実施形態においては、複数のチャネルホッピングスケジュールが、各ネットワークデバイス200に提供される。たとえば、ネットワークデバイス200は、中電力チャネルホッピングスケジュール、低電力チャネルホッピングスケジュール、および1つまたは複数の混合されたチャネルホッピングスケジュールを受信する可能性がある。特定の例示的な実施形態においては、ネットワークデバイス200が、それぞれの混合されたチャネルホッピングスケジュールが中電力チャネルのスロットおよび低電力チャネルのスロットの異なる割合およびシーケンスを含むようにして複数の混合されたチャネルホッピングスケジュールを提供される可能性がある。特定のその他の例示的な実施形態において、ネットワークデバイス200は、デバイスの種類、デバイス200が受信および送信する主なデータトラフィック、またはこれらの組合せに基づいてチャネルホッピングスケジュールを受信し得る。たとえば、サイズが小さく、優先順位の低いデータパケットを主に送信するデバイス200は、低電力チャネルホッピングシーケンスまたは低電力チャネルのスロットの割合がより高い混合されたチャネルホッピングシーケンスを与えられる可能性がある。

【0105】

ブロック1030において、各ネットワークデバイス200は、そのネットワークデバイス200に割り振られたデフォルトのチャネルホッピングスケジュール通りにリスニングする。特定の例示的な実施形態において、デフォルトのチャネルホッピングスケジュールは、中電力チャネルホッピングスケジュールである。特定のその他の例示的な実施形態において、デフォルトのチャネルホッピングスケジュールは、混合されたチャネルホッピングスケジュールである。1つの例示的な実施形態において、各デバイスは、その特定のデバイスのためのチャネルホッピングスケジュール通りに動作する。この行為は、各デバイスが任意の所与の時点で異なるチャネルを使用している可能性がより高いので、2つの近隣のネットワークデバイス200がネットワーク内のその他のネットワークデバイス200と最小限の干渉で同時に通信することを可能にする。

【0106】

ブロック1040において、ネットワーク管理デバイス130が、中電力ブロードキャストスケジュールおよび低電力ブロードキャストスケジュールを定義する。ブロードキャストスケジュールは、ネットワーク100上のすべてのデバイス200が同じチャネル上で同期する設定された時間間隔を定義する。この行為は、ネットワークデバイス200が範囲内の任意の隣接するデバイス200にメッセージを送信することを可能にする。たとえば、送信側デバイス200aが低電力チャネルを用いてその送信側デバイス200aが送信したいデータを有するが、隣接するデバイス200が中電力チャネルホッピングスケジュール通りに動作している場合、送信側デバイス200aは、送信側デバイス200aが受信側デバイス200bにデータを伝達することができるように受信側デバイス200bが指定された低電力チャネルホッピングシーケンスに同期することを要求するメッセージを適切なブロードキャスト間隔中に送信することができる。1つの例示的な実施形態において、低電力チャネルホッピングシーケンスは、すべて低電力のチャネルホッピングシーケンスである可能性がある。別の例示的な実施形態において、低電力チャネルホッピングシーケンスは、所与のデータパケットを伝達するのに十分な数の低電力チャネルのスロットを用いる混合されたチャネルホッピングシーケンスである可能性がある。たとえば、比較的大きなデータパケットは、比較的小さなデータパケットよりも多くの低電力チャネルのスロットを必要とする可能性がある。

【0107】

ブロック1040から、方法620は、図6のブロック630に戻る。

【0108】

図6に戻ると、ブロック630において、送信側デバイス200aが、受信者デバイス200bに送信するためのデータを準備する。例示的な実施形態において、データは、ネットワークインターフェース210を介して送信するためにフォーマットされたデータパケットまたはデータを含む。代替的な例示的実施形態において、データは、一連のバイトまたは文字を含む。例示的な実施形態において、送信側デバイス200aは、データをパケットへとフォーマットすることによって受信者デバイス200bに送信するためのデータを準備する。代替的な例示的実施形態においては、データが、1つまたは複数のその他のネットワークデバイス200によって準備され、送信側デバイス200aに送信される。

【0109】

ブロック635において、送信側デバイス200aが、データが低電力通信チャネルを介して送信可能であるかどうかを判定する。たとえば、送信側デバイス200aは、所与のデータパケットのサイズおよびデータパケットの優先順位またはレイテンシーに対する影響されやすさを判定する。所与のデータパケットのサイズおよび優先順位のステータスに関して、システムは、データレートの閾値を定義し、必要とされるデータレートに基づいて中電力またはより低い電力のチャネルを選択し得る。たとえば、中電力チャネルが、より低い電力のチャネルのより高いデータレートと比較して通信範囲および堅牢性を高めるためにより低いデータ転送速度に調整される可能性がある。しかし、所与のデータパケットのサイズが、より低い電力のチャネルのより高いデータレートをより好ましくする可能性がある。1つの例示的な実施形態においては、データパケットが低電力または中電力リンクにマッピングされる可能性がある。たとえば、ネットワークがIPv6を使用する場合、DSCPの印が、低電力チャネルまたは中電力チャネルの送信に関するデータパケットをマッピングする可能性がある。1つの例示的な実施形態において、マッピングは、構成を通じて静的に与えられる可能性がある。たとえば、データの種類が、DHCPv6またはネットワーク管理システム130の登録を用いてマッピングされる可能性がある。別の例示的な実施形態においては、ネットワークデバイス200またはネットワーク管理デバイス130が、以下で説明されるように、それが転送しているデータの種類を観測し、データを動的にマッピングする可能性がある。

【0110】

特定の例示的な実施形態において、送信側デバイス200aは、低電力チャネルを介して情報を伝達することを決定する前に、トリガイベントが起こったかどうかを判定する。たとえば、特定のデータの種類は、レイテンシーに影響されやすく、堅牢な信号を越える即時の通信を必要とする可能性がある。したがって、そのような状況においては、低電力チャネルのトポロジーを介したデータの送信を調整する時間がない可能性がある。特定の例示的な実施形態において、送信側デバイス200aは、トリガイベントの検出に基づいて、パケットが低電力チャネルを介して送信され得るかどうかを判定する。たとえば、スマートユーティリティネットワーク上の配電自動化(DA)デバイスは、停電を検出すると中電力チャネルシーケンスに動的に切り替わってDAデバイスに関するトラフィックの堅牢性を高め得る。したがって、トリガイベントが検出される場合、送信側デバイス200aは、低電力チャネルを介してデータを伝達しない。

【0111】

データが低電力チャネルを介して送信され得ない場合、方法600は、ブロック640に進む。ブロック640において、送信側デバイス200aが、送信側デバイス200aのチャネルホッピングスケジュールに従って中電力チャネルを介してデータを伝達する。送信側デバイス200aは、低電力チャネルのみのスケジュール通りに動作している場合、受信側デバイス200bへのデータ送信を完了するために受信側デバイス200bの中電力チャネルホッピングスケジュールに切り替え得る。特定の例示的な実施形態において、送信側デバイス200aは、送信側デバイス200aが送信しているデータの種類に基づいて中電力チャネルホッピングシーケンスにおいてどの中電力チャネルを使用すべきかを選択する。たとえば、送信側デバイス200aは、データパケットの優先順位のレベルに基づいて使用すべき1つの中電力チャネルまたは複数の中電力チャネルを選択し得る。より低い周波数の中電力チャネルは、搬送波感知の継続時間が128μsを超えるより高い周波数の中電力チャネルよりも長い、たとえば5msを超える搬送波感知の継続時間を有する。結果として、より高い周波数のチャネルが、より高い優先順位のトラフィックを伝達するために使用され得る。一部のLLNは、国の管轄権に依存して、その他のネットワークの種類と帯域幅を共有する。たとえば、電波産業会(ARIB)の規制に従って動作するLLNの低周波数チャネルは、920MHzの範囲において受動タグシステムと帯域幅を共有する。特定の例示的な実施形態において、送信側デバイス200aは、重なり合う帯域幅による干渉の量を最小化するために低周波数チャネルを使用することと高周波数チャネルを使用することとを交互に繰り返す中電力チャネルホッピングシーケンスを選択し得る。

【0112】

ブロック635に戻ると、データが低電力通信チャネルを介して送信され得る場合、方法600は、ブロック650に進む。

【0113】

ブロック650において、送信側デバイス200aが、低電力チャネルに切り替えるように受信側デバイス200bに要求する。受信側デバイス200bに制御メッセージを伝達するための方法は、図11に示される方法に関連して以降でより詳細に説明される。

【0114】

図11は、図6のブロック650において触れられたように、特定の例示的な実施形態による、低電力チャネルに切り替えるための受信側デバイス200bへの要求を送信するデバイス200aが送信するための方法650を示すブロック流れ図である。方法650は、図1〜図5に示された構成要素を参照して説明される。

【0115】

ブロック1110において、送信側デバイス200aが、受信側デバイス200bが同じチャネル上にあるかまたはチャネルホッピングスケジュール通りであるかどうかを判定する。たとえば、送信側デバイス200aは、図10のブロック1020に関連してすでに説明されたように、デフォルトのチャネルホッピングシーケンスがネットワーク内のすべてのデバイスに割り振られたかどうかをその送信側デバイス200a自体のチャネルホッピングシーケンスに基づいて知り得る。代替的に、送信側デバイス200aは、受信側デバイス200bに試験メッセージを送信する可能性がある。たとえば、送信側デバイスは、低電力チャネルを用いて試験メッセージを送信し、受信者デバイス200bからの応答を待つ可能性がある。受信者デバイス200bが定義された量の時間内に試験メッセージに肯定応答しない場合、送信側デバイス200aは、受信側デバイスが低電力チャネルホッピングスケジュール通りに動作していないことを知る。

【0116】

送信側デバイス200aが送信側デバイス200aおよび受信者デバイス200bが同じ低電力チャネルホッピングスケジュール上にあると判定する場合、方法は、ブロック1115に進む。

【0117】

ブロック1115において、送信側デバイス200aが、共有された低電力チャネルホッピングスケジュールを用いて受信側デバイス200bにデータパケットを伝達する。共有された低電力チャネルホッピングスケジュールは、シーケンス内に低電力チャネルのみを含む可能性があり、または所与のデータパケットを伝達するのに十分な低電力チャネルのフレームを有する混合されたチャネルホッピングシーケンスである可能性がある。

【0118】

ブロック1110に戻ると、受信側デバイス200bからの応答メッセージが受信側デバイス200bが所望の低電力チャネルホッピングスケジュール通りでないことを示す場合、方法は、ブロック1120に進む。

【0119】

ブロック1120において、送信側デバイス200aが、受信側デバイス200bに制御メッセージを送信する。制御メッセージは、送信側デバイス200aが異なるチャネル上でまたは低電力チャネルホッピングシーケンスなどのチャネルホッピングシーケンス通りに受信側デバイス200bにデータパケットを伝達するように意図することを示すショートメッセージである。特定の例示的な実施形態において、制御メッセージは、図10のブロック1040に関連して検討されたように、ネットワークのブロードキャストスケジュールに従って伝達される。1つの例示的な実施形態において、制御メッセージは、受信側デバイス200bがリスニングする必要がある低電力チャネルを指定する可能性がある。制御メッセージは、指定された低電力チャネルをどれだけ長くリスニングすべきかの指示をさらに含み得る。制御メッセージ内で示される時間の長さは、受信側デバイス200bがデータパケットに関するフレーム開始デリミタを検出するのに丁度足りるだけ長い可能性があり、または受信側デバイス200bが連続した複数のデータフレームを受信するのに十分なだけ長い可能性がある。特定の例示的な実施形態において、制御メッセージは、制限された期間の間使用すべき低電力チャネルホッピングスケジュールを示す可能性がある。

【0120】

低電力チャネルホッピングシーケンスは、情報要素内で受信側デバイス200bに伝達される可能性がある。チャネルホッピング情報は、いくつかの方法でフォーマットされ得る。特定の例示的な実施形態において、チャネルホッピング情報は、送信側デバイス200aの現在の時間およびスロットのインデックスを含む可能性がある。1つの例示的な実施形態において、受信側デバイス200bは、時間およびスロットのインデックスを、チャネル番号を出力する定義されたチャネルシーケンス機能における入力として使用する。たとえば、1つのデータの種類に関してより適切なより少ない中電力チャネルを生成するチャネルシーケンス機能が存在する可能性があり、別のデータの種類に関して適切なより多くの中電力チャネルを生成する別のチャネルシーケンス機能が存在する可能性がある。送信側デバイス200aは、現在の時間およびスロットのインデックスを伝達するときに、受信側デバイス200bに低電力チャネルシーケンスを生成するための適切なチャネルシーケンス機能を提供し得る。その他の例示的な実施形態においては、適切なチャネルホッピング機能が、受信側デバイス200bにすでに事前インストールされている可能性がある。

【0121】

制御メッセージは、データレートおよび変調などであるがこれらに限定されないその他の送信パラメータをさらに含み得る。制御メッセージは、ネットワークのデフォルトのチャネルホッピングスケジュールによって命じられたように中電力チャネルを介して送信され得る。別の例示的な実施形態において、制御メッセージは、受信側デバイス200bのチャネルホッピングスケジュールによって送信され得る。さらに別の例示的な実施形態において、制御メッセージは、低電力チャネルを介して送信され得る。

【0122】

ブロック1125において、受信側デバイス200bが、送信側デバイス200aから制御メッセージを受信する。1つの例示的な実施形態において、受信側デバイス200bは、制御メッセージの信号品質を評価する可能性がある。たとえば、受信側デバイス200bは、制御メッセージの送信の受信信号強度インジケーション(RSSI: received signal strength indication)およびリンク品質インジケーション(LQI: link quality indication)などであるがこれらに限定されないメトリックを評価する可能性がある。

【0123】

ブロック1130において、受信側デバイス200bが、送信側デバイス200aに肯定応答メッセージを送信する。肯定応答メッセージは、受信側デバイス200bが示された低電力チャネルまたは低電力チャネルホッピングシーケンスに切り替えたことを示し得る。1つの例示的な実施形態において、肯定応答メッセージは、制御メッセージが送信側デバイス200aによって受信側デバイス200bに送信された同じチャネル上で送信側デバイス200aに送り返される可能性がある。別の例示的な実施形態において、肯定応答メッセージは、送信側デバイス200aのチャネルホッピングシーケンスを用いて送り返される可能性がある。さらに別の例示的な実施形態において、肯定応答メッセージは、制御メッセージ内で指定された低電力チャネル上で送り返される可能性がある。1つの例示的な実施形態において、肯定応答メッセージは、上のブロック1120において検討されたリンク品質情報、たとえば、RSSI/LQIを含み得る。

【0124】

ブロック1135において、送信側デバイス200aが、受信側デバイス200bから肯定応答メッセージを受信する。

【0125】

ブロック1140において、送信側デバイス200aが、受信側デバイス200bとのリンク品質が低電力チャネルを介してデータパケットを伝達するのに十分であるかどうかを判定する。たとえば、受信側デバイス200bからの肯定応答メッセージは、リンク品質が悪すぎて低電力チャネルを介して通信することができないことを示す可能性がある。特定の例示的な実施形態において、肯定応答の要求が、低電力チャネルを介して通信する制御メッセージの要求が受信側デバイス200bによって拒否されたことを示す可能性があり、代替的な中電力チャネルまたは中電力チャネルホッピングスケジュールをさらに含む可能性がある。特定の例示的な実施形態において、送信側デバイス200aは、肯定応答メッセージに含まれるリンク品質情報を評価し、リンク品質パラメータが指定された送信パラメータを満たすように確立された構成可能な閾値を超えるかどうかを判定する可能性がある。閾値は、伝達されるデータの種類に基づいて調整される可能性がある。たとえば、閾値は、データパケットが優先パケットとして示される場合に調整される可能性がある。別の実施形態において、閾値は、観測されたトラフィックのメトリックに基づいて動的に調整される可能性がある。たとえば、送信側デバイス200aが、送信側デバイス200aにおいて感知されたかまたはNMS 130などの中央ルーティングデバイスによって与えられたかのどちらかの観測されたトラフィックのメトリックから、トラフィックのレベルが中チャネル上で高いと判定する場合、低電力チャネルを使用すべきかどうかを判定するためのリンク品質の閾値が引き下げられる可能性がある。リンク品質が指定された閾値未満である場合、方法650は図6のブロック640に進み、適切な中電力チャネルがデータを送信するために使用される。

【0126】

ブロック1140に戻ると、リンク品質が指定された閾値を超える場合、方法650は、ブロック1145に進み、送信側デバイス200aが、指定された低電力チャネルまたは低電力チャネルホッピングシーケンスによって受信側デバイス200bにデータパケットを伝達する。

【0127】

ブロック1150において、受信側デバイスが、送信側デバイス200aからデータパケットを受信する。方法650は、図6のブロック660に進む。

【0128】

図6に戻ると、ブロック660において、受信側デバイス200bが、本明細書において説明されたようにチャネルホッピングシーケンスを用いてまたは別のチャネルを介して送信側デバイス200aに肯定応答メッセージを送信し、肯定応答メッセージが、送信されたデータパケットの受信を示す。

【0129】

ブロック670において、送信側デバイス200aが、受信側デバイス200bから肯定応答パケットを受信する。

【0130】

実施形態は、本明細書において説明され、図示された機能を具現化するコンピュータプログラムを含む可能性があり、コンピュータプログラムは、機械可読媒体に記憶された命令および命令を実行するプロセッサを含むコンピュータシステムに実装される。しかし、実施形態をコンピュータプログラミングで実装する多くの異なる方法が存在する可能性があることは明らかであるに違いなく、実施形態は、何らかの1組のコンピュータプログラム命令に限定されると解釈されるべきでない。さらに、通常の技能を有するプログラマーは、添付の流れ図および本出願の本文の関連する説明に基づいて開示された実施形態の実施形態を実装するようにそのようなコンピュータプログラムを記述することができる。したがって、プログラムコードの命令の特定の組の開示は、実施形態をどのように実施し、使用するかを適切に理解するために必須であるとは考えられない。さらに、当業者は、1つまたは複数のコンピューティングシステムにおいて具現化され得るように、本明細書において説明された実施形態の1つまたは複数の態様がハードウェア、ソフトウェア、またはこれらの組合せによって実行され得ることを理解するであろう。さらに、動作がコンピュータによって実行されることに関するいずれの言及も、2つ以上のコンピュータが動作を実行し得るので、単一のコンピュータによって実行されると解釈されるべきでない。

【0131】

本明細書において説明された例示的な実施形態は、本明細書において説明された方法および処理の機能を実行するコンピュータのハードウェアおよびソフトウェアで使用され得る。本明細書おいて説明されたシステム、方法、および手順は、プログラミング可能なコンピュータ、コンピュータが実行可能なソフトウェア、またはデジタル回路で具現化され得る。ソフトウェアは、コンピュータ可読媒体に記憶され得る。たとえば、コンピュータ可読媒体は、フロッピー（登録商標）ディスク、RAM、ROM、ハードディスク、取り外し可能媒体、フラッシュメモリ、メモリスティック、光媒体、光磁気媒体、CD-ROMなどを含み得る。デジタル回路は、集積回路、ゲートアレイ、ビルディングブロック論理(building block logic)、フィールドプログラマブルゲートアレイ(FPGA)などを含み得る。

【0132】

上で示された実施形態において説明された例示的なシステム、方法、および動作は、例示的であり、代替的な実施形態においては、特定の動作が、繰り返され、異なる順序で実行され、互いに並列に実行され、完全に省略され、および/もしくは異なる例示的な実施形態の間で組み合わされる可能性があり、ならびに/または特定のさらなる動作が、様々な実施形態の範囲および精神を逸脱することなく実行され得る。したがって、そのような代替的な実施形態は、本明細書において特許請求された本発明に含まれる。

【0133】

特定の実施形態が上で詳細に説明されたが、説明は例示を目的とするに過ぎない。したがって、上述の多くの態様は、別途明示的に述べられない限り必須のまたは不可欠の要素として意図されていないことを理解されたい。上述の態様に加えて、例示的な実施形態の開示された態様の修正、および例示的な実施形態の開示された態様に対応する均等な構成要素または動作が、添付の請求項において定義される本発明の精神および範囲を逸脱することなく、本開示の恩恵を受ける当業者によってなされる可能性があり、添付の請求項の範囲は、そのような修正および均等な構造を包含するように最も広い解釈を与えられるべきである。

【符号の説明】

【0134】

100 コンピュータネットワーク
130 ネットワーク管理サーバ
140 データパケット
200 ノード/デバイス
200a 送信側デバイス/ノード
200b 受信者デバイス/ノード、受信側デバイス
210 ネットワークインターフェース
220 プロセッサ
240 メモリ
242 オペレーティングシステム
244 ルーティングプロセス/サービス
245 データ構造
248 QoS監視プロセス
250 システムバス
260 電源
300 制御メッセージのフォーマット
310 ヘッダ
312 フィールド
320 本体/ペイロード
321 フラグ/ビット
322 シーケンス番号
323 ランク値
324 インスタンスID
325 DODAG ID
326 送信先プレフィックス
327 通過情報フィールド
328 補助オプションフィールド
410 DAG
500 シンク
600 方法
610 方法
620 方法
770 方法
780 方法

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】