JP6027629B2 - 最小限接続オブジェクト・ネットワークのための支援型インテリジェント・ルーティング - Google Patents

Description

本開示は、一般に、コンピュータ・ネットワークに関する。

低電力高損失ネットワーク（ＬＬＮ：low-power and Lossy Networks）、例えば、センサ・ネットワークは、スマート・グリッド、スマート・シティ、家庭および建物の自動化等のような、無数の用途がある。ＬＬＮには、損失が多いリンク、低い帯域幅、バッテリ動作、低いメモリおよび／または処理能力等というような、種々の課題がある。大規模ＩＰスマート・オブジェクト・ネットワークは、多数の技術的課題を提起する。例えば、このようなネットワークの密度(degree of density)（多数のセンサおよびアクチュエータがあるスマート・グリッド・ネットワーク、スマート、シティ、または高度測定インフラストラクチャ即ち「ＡＭＩ」ネットワーク）は、非常に高いこともあり、各ノードが数百もの近隣(neighbor)に遭遇する(see)ことも希ではない。

ＬＬＮの課題に対するルーティング解決策の一例が、ＬＬＮ用ルーティング・プロトコル、即ち、「ＲＰＬ」と呼ばれるプロトコルである。これは、制御トラフィックを結び付ける、サポート・ローカル（および低速）リペアをサポートする等のための１組の機構(feature)に加えて、無閉路有向グラフ（ＤＯＤＡＧ：Destination Oriented Directed Acyclic Graph、または単にＤＡＧ）を構築する距離ベクトル・ルーティング・プロトコルである。ＲＰＬの中核をなす態様の１つは、ノードがどのようにＤＡＧに加入する(join)かにしたがって規則を決定するＤＡＧルート上に構成される目的関数（ＯＦ）の使用にある。ＯＦは、多数の規則および目的に加えて、ＤＡＧを構築するために用いられるメトリックおよび制約のリストを指定する。スマート測定用途における典型的なＯＦは、「バッテリ動作ノードを回避しつつ、信頼性メトリックに基づいて最短経路（つまり、最も信頼性がある経路）を発見すること」であろう。サブステーション自動化用途における典型的なＯＦは、「暗号化リンクを用いつつ、遅延メトリックに基づいて最も短い経路（最短遅延）を発見すること」であろう。

ＲＰＬ、および他の複雑なルーティング・プロトコルは、確かに、数千ものノードを含む既存のネットワークにおけるルーティングには非常に適している。とは言え、このようなプロトコルは、多数の利用可能なパラメータ、チューニング、任意の構築ブロック等によって非常に精緻化され、制約があるネットワークにおいて運用するのは難しい場合もある。例えば、現在の推定では、ＲＰＬは状態保持のために数ＫバイトのＲＡＭを必要とし、フラッシュに関してはそれよりも多少大目のメモリを必要とすることが示される。生憎、分散型ルーティング手法を使用するＬＬＮにおけるルーティングの課題に固有の複雑度のレベルは、ネットワークにおけるノード数と共に急速に増大する。

添付図面と合わせて以下の説明を参照することによって、本発明の実施形態は一層深く理解できよう。添付図面では、同様の参照番号は、同一のエレメントまたは機能的に同様のエレメントを示すこととする。

図１は、コンピュータ・ネットワークの一例を示す。 図２Ａは、図１のコンピュータ・ネットワーク内部におけるデータ・フローの例を示す。 図２Ｂは、図１のコンピュータ・ネットワーク内部におけるデータ・フローの例を示す。 図２Ｃは、図１のコンピュータ・ネットワーク内部におけるデータ・フローの例を示す。 図２Ｄは、図１のコンピュータ・ネットワーク内部におけるデータ・フローの例を示す。 図２Ｅは、図１のコンピュータ・ネットワーク内部におけるデータ・フローの例を示す。 図３は、複雑なシステムにおける機能性とスケーラビリティとの間のトレードオフの一例を示す。 図４は、最小限接続オブジェクト（ＭＣＯ）について本明細書において説明するアーキテクチャによるコンピュータ・ネットワークの図の一例を示す。 図５は、ＭＣＯデバイスの一例を示す。 図６は、分散型インテリジェント・エージェント（ＤＩＡ）デバイスの一例を示す。 図７は、中央インテリジェンス・コントローラ（ＣＩＡ）デバイスの一例を示す。 図８は、ネットワーク・ドメイン（ＬＬＮまたはＩｏＴドメイン）の一例を示す。 図９は、図８の特定のネットワーク・ドメイン内における最小限の現行ルーティング・トポロジ（無閉路有向グラフ(DAG))の一例を示す。 図１０は、図８の特定のネットワーク・ドメイン内における最適ルーティング・トポロジの一例を示す。 図１１Ａは、図９の現行ルーティング・トポロジの反復最適化の例を示す。 図１１Ｂは、図９の現行ルーティング・トポロジの反復最適化の例を示す。 図１２は、最小限接続オブジェクト（ＭＣＯ）の観点から、支援型インテリジェント・ルーティングの簡略化した手順の一例を示す。 図１３は、分散型インテリジェント・エージェント（ＤＩＡ）の観点から、支援型インテリジェント・ルーティングの簡略化した手順の他の例を示す。

全体像
本開示の１つ以上の実施形態によれば、分散型インテリジェント・エージェント（ＤＩＡ）が、コンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）からローカル状態情報を収集する。ＭＣＯ毎のローカル状態情報は、対応する近隣リストと、それぞれのＭＣＯについての選択された次のホップ(next-hop)とを含み、ＭＯＣの内１つ以上が、自己最適化を全く行わずに、これらの次のホップを選択するように構成される。次いで、ＤＩＡは、選択された次のホップを組みあわせた結果である、現行ルーティング・トポロジを、計算された最適ルーティング・トポロジと比較して分析して、現ルーティング・トポロジを最適化するか否か判断することができる。現ルーティング・トポロジを最適化すべきであると判断したことに応答して、ＤＩＡはユニキャスト・ルーティング命令を１つ以上の個々のＭＣＯにしかるべく送信して、これら個々のＭＣＯに、現ルーティング・トポロジをどのように最適化するか命令する。
説明
コンピュータ・ネットワークは、地理的に分散され、通信リンクによって相互接続されたノードと、エンド・ノード間でデータを移送する(transport)セグメントとの集合体である。エンド・ノードとは、パーソナル・コンピュータおよびワークステーション、またはセンサのような他のデバイス等である。多くのタイプのネットワークが利用可能であり、ローカル・エリア・ネットワーク（ＬＡＮ）からワイド・エリア・ネットワーク（ＷＡＮ）までの範囲に及ぶ。ＬＡＮは、通例、建物または大学構内というような同じ物理的場所に配置された専用の私有通信リンクを通じてノードを接続する。一方、ＷＡＮは、通例、長距離通信リンクを通じて、地理的に散らばったノードを接続する。長距離通信リンクは、共通キャリア電話回線、光学光路(optical lightpath)、同期光ネットワーク（ＳＯＮＥＴ）、同期ディジタル回想（ＳＤＨ）リンク、またはIEEE 61334、IEEE P1901.2というようなパワーライン通信（ＰＬＣ：Powerline Communications）等である。加えて、移動体アドホック・ネットワーク（ＭＡＮＥＴ）は、ワイヤレス・アドホック・ネットワークの一種であり、ワイヤレス・リンクによって接続された移動体ルート（および関連するホスト）の自己構成ネットワークと一般に見なされ、ワイヤレス・リンクの合体が、任意のトポロジを形成する。

具体的にはセンサ・ネットワークのような、スマート・オブジェクト・ネットワークは、センサ、アクチュエータ等のような、空間的に分散された自律デバイスを有する特定のタイプのネットワークであり、これらのデバイスが協働して、例えば、エネルギ／電力消費、資源消費（例えば、高度測定インフラストラクチャ、即ち、「ＡＭＩ」用途のための水／ガス等）、温度、圧力、振動、音、放射線、運動、汚染物等のような、異なる場所における物理的または環境的状態を監視する。他のタイプのスマート・オブジェクトには、例えば、エンジンをオン／オフに切り替える役割、または他のあらゆる動作(action)を実行するアクチュエータが含まれる。センサ・ネットワークは、スマート・オブジェクト・ネットワークの一種であり、通例、ワイヤレスまたはＰＬＣネットワークのような、共有媒体ネットワークである。即ち、１つ以上のセンサに加えて、センサ・ネットワークにおける各センサ・デバイス（ノード）は、通常、無線送受信機またはＰＬＣのような他の通信ポート、マイクロコントローラ、およびバッテリのようなエネルギ源が装備される。多くの場合、スマート・オブジェクト・ネットワークは、フィールド・エリア・ネットワーク（ＦＡＮ）、近隣エリア・ネットワーク（ＮＡＮ）等と見なされる。一般に、スマート・オブジェクト・ノード（例えば、センサ）に対するサイズおよびコストの制約の結果、エネルギ、メモリ、計算速度、および帯域幅というようなリソースにも、対応する制約が生ずる。

注記すべきは、メッシュ・ネットワークが近年増々普及し実用化されつつあることである。具体的には、ワイヤレスまたはPLCネットワークのような共有媒体メッシュ・ネットワークが、低電力大損失ネットワーク（ＬＬＮ）と呼ばれるものの上にあることが多い。低電力大損失ネットワークとは、ルータおよびそれらの相互接続に制約がある、一種の(class)のネットワークである。ＬＬＮルータは、通例、処理パワー、メモリ、および／またはエネルギ（バッテリ）の制約を受けて動作し、これらの相互接続は、代表的には、高い損失率、低いデータ・レート、および／または不安定によって特徴付けられる。ＬＬＮは、数十から数千、または数百万ものＬＬＮルータからのいずれかで構成され、二点間トラフィック（ＬＬＮ内部のデバイス間）、一点対多点トラフィック（ルート・ノードのような中央制御ポイントからＬＬＮ内部のデバイスの部分集合へ）、および多点対一点（ＬＬＮ内部のデバイスから中央制御ポイントへ）をサポートする。

大雑把に言うと、「モノのインターネット」（Internet of Things）即ち「ＩｏＴ」は、一意に識別可能なオブジェクト（モノ）およびネットワーク・ベース・アーキテクチャにおけるそれらの仮想表現を指すために、当業者によって、用いられる場合がある。具体的には、インターネットの進化における次の境界は、単にコンピュータおよび通信デバイスだけを接続する能力に留まらず、照明具、アプライアンス、車両、ＨＶＡＣ（加熱、換気、および空調）、窓および日よけおよびブラインド、ドア、鍵等というような「オブジェクト」全般を接続する能力である。つまり、「モノのインターネット」とは、一般に、センサやアクチュエータというような、オブジェクト（例えば、スマート・オブジェクト）の、コンピュータ・ネットワーク（例えば、ＩＰ）を通じた相互接続を指し、このコンピュータ・ネットワークは、公衆インターネットでもまたは私有ネットワークであってもよい。このようなデバイスは、何十年もの間産業界において、大抵の場合プロトコル変換ゲートウェイによってＩＰネットワークに接続される非ＩＰまたは企業固有のプロトコルの形態で用いられていた。スマート・グリッド、スマート、シティ、ならびに建物および産業自動化、更には自動車（例えば、電力品質、タイヤ圧力、および温度のようなものを検知するための数百万もの物体を相互接続することができ、更にエンジンや照明具を作動させることができる）というような無数の用途の出現により、これらのネットワークのためにＩＰプロトコルの一揃い(suite)を拡大することがこの上なく重要になっている。

図１は、種々の通信方法によって相互接続されたノード／デバイスを例示的に含む、コンピュータ・ネットワークの一例１００の模式ブロック図である。例えば、リンク（図示せず）は、有線リンクまたは共有媒体（例えば、ワイヤレス・リンク、ＰＬＣリンク等）であってもよく、例えば、ルータ、センサ、コンピュータというようなある種のノードが、例えば、距離、信号強度、現動作ステータス、位置等に基づいて、他のノードと通信することができる。当業者は、コンピュータ・ネットワークではいずれの数のノード、デバイス、リンク等でも使用できること、そしてここで示す図は簡略化のためであることを理解されよう。また、当業者は、このネットワークが一定の方位で示されるが、ネットワーク１００は単なる図示例に過ぎず、本開示を限定する意図はないことも、更に理解されよう。

例示的なネットワーク１００によれば、複数のネットワーク「階層」を作成することができ、各階層は、一般に異種の(disparate type)デバイスおよび／または通信プロトコルで構成されるのでもよいが、そうする必要はない。図示のように、ＩｏＴドメイン１１０（ＬＬＮ１１０とも呼ぶ）は、センサ、アクチュエータ等のような「オブジェクト」の埋め込みスタックで構成することができ、前述のように、これらのオブジェクトは通常低電力および／または高損失リンクによって相互接続される。実例として、ＩｏＴドメインは数百万個のオブジェクト１１５で構成される場合も考えられる。

各ＩｏＴドメイン１１０（明確化のために１つのみを示す）は、フィールド・エリア・ネットワーク１２０のような次の階層レベルに相互接続されてもよく、次の階層レベルは、実例として、「クラウド」またはコア・ネットワーク１３０のエッジを設ける。フィールド・エリア・ネットワーク（１つまたは複数）１２０は、１つ以上のＩｏＴドメインをコア・ネットワーク１３０に相互接続することができ、一般に複数のルータ１２５（あるいはスイッチまたはゲートウェイ）を含む。一実施形態例では、フィールド・エリア・ネットワークにおける通信は、「３Ｇ」、「４Ｇ」、「ＬＴＥ」等のようなマルチ・サービス・プロトコルを含むことができる。これは、当技術分野では明確に理解されよう。通例、１つのフィールド・エリア・ネットワーク内にあるデバイス１２５の数は、数万に達することもあり得る。

究極的には、注記したように、フィールド・エリア・ネットワーク１２０（明確化のために１つだけ示す）は、インターネット・プロトコル（ＩＰ）ネットワークおよび／またはコア・ルータ、スイッチ等のような通常更に高機能な(more capable)デバイス（例えば、数千個のこれら）のマルチ・プロトコル・ラベル交換（ＭＰＬＳ：Multi-Protocol Label Switching）ネットワークというような、コア・ネットワーク１３０によって相互接続される。一般に、この階層レベルは、ＩｏＴドメインのセキュリティ、サービス品質（ＱｏＳ）、マルチキャスト動作等を、フィールド・エリア・ネットワーク自体におけるこれらの特徴をサポートすることに加えて、制御する。ＩｏＴ分析、ネットワーク管理サービス（ＮＭＳ）等のホスティングというような、種々の高レベル機能性を設けるために、ネットワーク管理コンポーネント１４０が、コア・ネットワーク１３０内に存在してもよく、またはコア・ネットワーク１３０を通じて相互接続されてもよい。例えば、ネットワーク管理コンポーネント１４０は、ネットワーク１００のネットワーク動作を通じて高レベル制御を行うように構成された１つ以上のサーバで構成することもでき、本明細書において説明するように、ユーザ（管理者）へのインターフェースを設けることもできる。

データ・パケット１５０（例えば、デバイス／ノード間で送られるトラフィックおよび／またはメッセージ）は、コンピュータ・ネットワークのノード／デバイス間で、一定の既知の有線プロトコル、ワイヤレス・プロトコル（例えば、IEEE規格802.15.4、WiFi、Bluetooth（登録商標）等）、ＰＬＣプロトコル、または該当する場合には他の共有媒体プロトコルというような、既定のネットワーク通信プロトコルを用いて交換することができる。このコンテキストでは、プロトコルは、ノードが互いにどのように相互作用するか定める１組の規則で構成される。前述のように、各階層は、互いに異なるプロトコルを利用してもよく、そして実際には、階層内の他のサブドメイン（例えば、異なるＩｏＴドメイン１１０またはフィールド・エリア・ネットワーク１２０）とは異なるプロトコルを利用してもよいが、そうする必要はない。

図２Ａ〜図２Ｅは、一般的なＩｏＴ動作によるというような、コンピュータ・ネットワーク１００内におけるデータ・フローの例を示し、本明細書において説明する技法にしたがって用いることができる。例えば、図２Ａに示すように、データ２５０が種々のオブジェクト１１５によって収集され、１つ以上のフィールド・エリア・ネットワーク・デバイス１２５に至る経路に沿って送信されてもよく（例えば、パケット１５０として）、そして種々の度合いの凝集(aggregation)、欠落等を途中で受ける場合もある。フィールド・エリア・ネットワーク・デバイス１２５は、次いで、図２Ｂに示すように、センサ・アプリケーション、制御、および相関付けというような他のインテリジェンス(intelligence)を、データ２５０に適用することができ、処理されたデータは、次いで、図２Ｃに示すようにネットワーク管理コンポーネント１４０に送信することができる。更に、移動体オブジェクトを例示するためのＩｏＴ動作の特定例として、図２Ｄおよび図２Ｅは、車両２６０（一般に、車両は実際に多くのネットワーク接続「オブジェクト」を含むので）のようなオブジェクト１１５がどのようにＩｏＴドメイン１１０間を通過すればよいか、そして近接度(proximity)に応じて、フィールド・エリア・ネットワーク・デバイス１２５（フィールド・エリア・ルータ即ち「ＦＡＲ」のような）間また更にはフィールド・エリア・ネットワーク１２０一般の間でどのように転送されればよいかについて示す。

先に注記したように、過去数年の間に、センサおよびアクチュエータのようなスマート接続オブジェクトの観念は、スマート・グリッド、接続車両、スマート・シティ、スマート健康管理、その他数多くというような、無数の用途にその扉を開いた。このために、様々な「アーキテクチャ」が提案され、これらのアーキテクチャは、マルチ・プロトコル・ゲートウェイを通じてこれらのデバイスを接続するか、または種々の混合選択肢に加えて、ＩＰ（ｖ６）端末間(end-to-end)を用いることのいずれかで構成される。

マルチ・プロトコル・ゲートウェイを用いるアイデアは、多数の理由のために問題を生ずるが、プロトコル移行(protocol migration)や時間に制限がある方略(strategy)には利点があり、既存の旧プロトコルからＩＰへの移行経路を提供する。前述の問題の一部には、動作の複雑さ、スケーラビリティの欠如（プロトコル変換の指数的数）、ＱｏＳおよびルーティング一貫性の欠如、単一障害点(single point of failure)（ステートフルなマルチ・プロトコル・ゲートウェイの使用は、非常にコストがかかる選択肢である）、セキュリティ・ホール等が含まれる。

このため、ＩＰ端末間を支持する明確なモーメンタム(momentum)が出現し、２００７年以降次のような多数の技術が開発され指定された。
−数ＫバイトのＲＡＭおよびフラッシュならびに８／１６ビット・マイクロコントローラが装備された低電力マイクロコントローラ上で実行する軽量オペレーティング・システム、および
−最適化ＩＰｖ６スタックおよび新たな低電力ＰＨＹ／ＭＡＣ技術の出現（例えば、IEEE802.15.4、低電力Wifi、P1901.2、PRIME、HP GreenPHY等）。

ＩＰプロトコルの一揃いを注意深く分析した後、これらの非常に制約が多く過酷な環境には新たなＩＰプロトコルが必要であることが認識された。いくつかの主要な例は、次を含む。

１）６ＬｏＷＰＡＮ：ヘッダ圧縮に加えて低ＭＴＵリンクに対する断片化を扱う適合層(adaptation layer)、
２）ＲＰＬ：ＬＬＮ用の新たなルーティング・プロトコル、
３）ＣｏＡＰ：ＳＮＭＰよりも遙かに軽量な、低電力端末デバイス上で実行するように構成された軽量リソース管理プロトコル、および
４）リンク層にホストされる種々の最適化機能（例えば、15.4gPLC（P1901.2)等のための周波数ホッピング）。

これまでは、典型的な方略は、制約があるデバイス上に極めて複雑なネットワーキング・プロトコルを実現することによって構成された。この制約のあるデバイスは、ＱｏＳ、ルーティング、管理、トラフィック設計、検知、ＬＬＮにおけるトラフィック削減アルゴリズム、低帯域幅リンク上においてチャネル容量を増やすための極めて複雑な方略、 制約があるルーティング、呼受付制御（ＣＡＣ）、およびバック・プレッシャ・メカニズムに加えて高速障害回復のための自己回復（self-healing)技法等を扱う役割を果たす。言い換えると、目標は、モノのインターネット（ＩｏＴ）をできるだけスマートにしつつ、なおも ＩｏＴ（ＬＬＮ）のエッジにおいて必要とされるリソースを結合することであった。

しかしながら、複雑なシステムにおける機能性とスケーラビリティとの間には繊細なトレードオフがある。即ち、多くのエリアにおいて、図３に示す現象を観察することができる。機能性がデバイスに追加されるに連れて、全ての機構を組みあわせるシステム全体（単に「ネットワーク」とも呼ぶ）の複雑さが、変曲点に当たる前に増分コストが容認できる点まで増大する。その時点で、そのシステムの全体的な理解(understanding)およびスケーラビリティは劇的に落下する。このようなモデルを確率的ペトリ・ネットワークまたはマルコフ・チェーンによって数学的にモデル化することは非常にやりがいがあるが、このような経験的分析は、複雑なシステムを設計し動作させる長年の経験によって、殆ど駆逐されている。尚、スケーラビリティは因子の数にしたがって変化する多重多項式関数であるが、「理解」因子の重みが疑いなく大きいことに注意すること。多くの状況では、技術が分野において選択されなかったのは、これらが技術的な観点から本質的にスケーラブルでないからではなく、エンド・ユーザに対して追加される価値と照らし合わせると、システム全体を理解することが高くつき過ぎるからである。例えば、純粋に技術的な観点から、あるシステムを理解することができても、機能性のレベルが高まるに連れて、異常な(pathological)理解されない場合の事例も極めて速く増大する。

数年に及ぶ深い技術的調査の後、スマート・オブジェクトによってサポートされる全体的な複雑さは、これらのネットワークのサイズやサポートされる機構の数と共に線形に増大するのではなく、指数的に増大し、システム全体自体のスケーラビリティが崩壊する原因になる。ＩｏＴの場合、次の２つの理由からこの現象の拡大を予期することができる。（１）このようなネットワークの規模が、潜在的に数百万個のデバイスを有する可能性がある、これまで知られている最も大きなネットワークを大きく超過する。（２）予期せずに、軽量プロトコル（メモリおよび帯域幅の使用に関してフットプリントが小さい）の設計に、挙動パターンが未知の極めて複雑な技法が必要となり、ＬＬＮ（低電力高損失ネットワーク）またはＩＰスマート・オブジェクト・ネットワークとしても知られる、ネットワークのこの部分が一層複雑化する。

本明細書において説明する例示的なネットワーク・アーキテクチャの目的は、端末デバイスの分散型インテリジェンスを追加することで構成される現在のモデルを考え直し、代わりに、安全な接続を提供するために必要とされる最小限にインテリジェンスを制限することである。以下で説明するが、本明細書においてエッジ・ルータと呼ぶフィールド・エリア・ネットワークのエッジ・デバイス（例えば、ルータ）上にホストされる中間エージェントを導入し、これらが、多数の判断決定プロセス（ＱｏＳ、ネットワーク管理、トラフィック設計等）においてこれらの端末デバイスを補助し、中央インテリジェンス（例えば、データ・センタにおいてホストされるコンピュータまたは更に性能が高いコンピュータ）と密接に相互作用して、例えば、トラフィック観察（例えば、深いパケット分析）によって供給される学習機械、１組の目的(objective)（例えば、サービス・レベル・アグリーメント、即ちＳＬＡ）、性能監視、挙動パターンおよびネットワーク・ダイナミクス（例えば、最適化と安定性との間のトレードオフ）等によって、しかるべき判断を下す。

具体的には、例示的なアーキテクチャは、インテリジェンスおよびネットワーク制御をルータ・エッジ境界に切り替えることに対処する。先に指摘したように、モノのインターネット（ＩｏＴ）に対して根本的に新しいネットワーキング・モデルを考えることには価値があり、ルーティング、自己回復技法、ＱｏＳ、ＣＡＣ、ＮＭＳ、信頼性、またはセキュリティというような、多数のエリアにおけるネットワーキングに関して劇的な移行をもたらす。以下で説明する実施形態によれば、本明細書における技法は、ネットワークの第２ティア(tier)におけるネットワーキング・インテリジェンスを、ＬＬＮ（ＬＢＲ、即ちＬＬＮ境界ルータとも呼ばれることもある）の縁(fringe)に移動させることで構成され、ＬＬＮにおけるデバイス（センサ／アクチュエータ／タグ）とは対照的に、リソースは「無限」と見なすことができる。主要な原理は、ＬＢＲおよび他のコンポーネント（ルータ上で実行するアプリケーション、帯域外ルータ／サーバ等）の機能をホストする能力にあり、その出力が次に最小限接続オブジェクト即ち「ＭＣＯ」（「スマート・オブジェクト」とは対照的に、ダム接続オブジェクト即ち「ＤＣＯ」(dumb connected objects)と呼ぶこともできる）に供給される。

この例示的なアーキテクチャ・モデルでは、センサ／アクチュエータは、スマート・オブジェクト（最近の１０年間産業全体が促進していたトレンド）ではなく、故意にＩＰｖ６「最小限接続オブジェクト」になる。

理論的根拠として、１つの主要な技術的理由は、現在のネットワークよりも１桁大きいサイズにネットワークをスケーリングできる能力にある。単純な数学は、これらのネットワークを効果的に管理するためには、極めて大規模なＬＬＮは非常に進んだ技術（以前には指定されなかったおよび／または知られていなかった）を伴うことを示す。つまり、このようなネットワークが自動であり、自己構成され、自己回復技術および自動構成をサポートするためにローカル・インテリジェンスが埋め込まれ、ローカル・トラブルシューティングを実行できることを記すことが重要になる。大きなドメインをそれよりも小さなドメインに分割することによって、全体的な複雑さを低下させるのに役立つが、一時的な対策に過ぎない。

これらのデバイスを「スマート」にするのではなく「単に接続」することによって構成される根本的に異なる方略を選択することによって、本明細書において説明するアーキテクチャは、大きなエコ・システムを可能にし、極めて制約が多いデバイス（エネルギ回収可能デバイス）上における接続を可能にし、ネットワークには貴重なデータが「供給」され、こうしてネットワークがインバウンド・インテリジェンス(in-bound intelligence)をホストする理論的根拠を増加させ、それを将来のプラットフォームにする。

具体的には、根本的に異なるアーキテクチャをモノのインターネット（ＩｏＴ）／ＬＬＮに用いることによって、ＬＬＮを接続する「従来のＩＰネットワーク」の縁において、ＬＢＲに基本的な安全な接続を提供することに限定された最小限接続オブジェクト（ＭＣＯ）に、スマート・オブジェクトが置き換えられる。実例として(illustratively)、ＬＢＲは、分散型インテリジェンス・エージェント（ＤＩＡ）をホストする。分散型インテリジェンス・エージェントは、例えば、深いパケット分析を用いるトラフィック・フロー観察、ユーザによって指定され中央インテリジェンス・コントローラ（ＣＩＣ）によって規定されるＳＬＡ要件というような多数の入力が供給されるソフトウェア／ハードウェア・モジュールである。また、ネットワーク管理、ルーティング、サービス品質（ＱｏＳ）、呼受付制御（ＣＡＣ）等のようなネットワークにおいて必要とされるネットワーキング機構をアクティブ化するか否か、いつ／どこでアクティブ化するかということのために、ＭＣＯと相互作用する多数のタスクをＤＩＡが更に実行できるように、ＤＩＡは、フローならびにネットワーク・ダイナミクスおよび挙動傾向を観察する学習機械もホストすることができる。

即ち、図４に示すように、例示的なネットワーク・アーキテクチャは、１つ以上の最小限接続オブジェクト（ＭＣＯ）５００、１つ以上の分散型インテリジェント・エージェント（ＤＩＡ）６００、および１つ以上の中央インテリジェンス・コントローラ（ＣＩＣ）７００を含む。具体的には、各ＭＣＯは、通常、それに指定されるそれぞれのタスクを実行し、コンピュータ・ネットワークに安全に加入し、基準状態（nominal state)情報を提供するのに十分なインテリジェンスに限定され、ＭＣＯは、サービス品質（ＱｏＳ)判定を行う、呼受入制御（ＣＡＣ）動作に関与する、トラフィック設計（ＴＥ）サービスを提供する、極めて複雑な信頼性プロトコルを実行する、またはネットワーク管理情報を外挿補間するというような、複雑な用途特定データ処理や複雑なネットワーキング・タスクを実行するように構成されない。これは、現行のＩｏＴアーキテクチャとは対照をなす。また、ＤＩＡは、ＭＣＯのコンピュータ・ネットワークにエッジ(edge)を提供するように構成され、ＭＣＯのネットワーキング管理を担い、およびＭＣＯのために複雑な用途特定データ処理を実行する役割を果たす。最後に、ＣＩＣは、コンピュータ・ネットワーク内部で動作し、ＭＣＯおよびＤＩＡ動作の制御を支配する(overarch)複雑なタスクを実行するためにＤＩＡと通信し、更にＭＣＯおよびＤＩＡ動作に対する１組のユーザ定義規則を受けるために１つ以上のインターフェースを提供するように構成される。

実例として、例示的なアーキテクチャに関して本明細書において説明する技法は、デバイスのタイプ（ＭＣＯ、ＤＩＡ、ＣＩＣ）毎に特定的なそれぞれのプロセスにしたがってというように、ハードウェア、ソフトウェア、および／またはファームウェアによって実行することができ、本明細書において説明する新規な技法に関する機能を、例えば、それぞれのデバイス上で実行する他のプロセスと共に実行するためにプロセッサによって実行されるコンピュータ実行可能命令を収容することができる。例えば、本明細書における技法は、種々のルーティング、通信、および／または管理プロトコルというような、従来のプロトコルに対する拡張として扱うことができ、したがって、これらのタイプのプロトコルを実行することが当技術分野において理解されている同様のコンポーネントによってしかるべく処理されてもよい。

尚、種々のコンピュータ読み取り可能媒体を含む、他のプロセッサおよびメモリ・タイプも、本明細書において説明する技法に関するプログラム命令を格納および実行するために用いてもよことは、当業者には明白であろう。また、この説明は種々のプロセスを例示するが、種々のプロセスは、本明細書における技法にしたがって動作するように構成されたモジュールとして具体化できる（例えば、同様のプロセスの機能性にしたがって）ことが考えられるのは明らかである。更に、ある種のプロセスは別々に示すこともできるが、これらのプロセスが他のプロセス内におけるルーチンまたはモジュールであってもよいことも、当業者には認められよう。

例示的なアーキテクチャによれば、先に注記したように、最小限接続オブジェクト（ＭＣＯ）５００は、低いインテリジェンスおよび意思決定のために処理要件が極めて軽量なオブジェクト（例えば、センサ、アクチュエータ、無線周波識別（ＲＤＩＦ）タグ、または単純な縮退ルータ）である。現在の「スマート・オブジェクト」手法とは対照的に、ＭＣＯは、縮退ルーティング手法を用いて安全にネットワークに加入するのに十分なだけのインテリジェンスしか有しておらず、その機能性、リソース、およびサポート能力に関しては十分なだけの状態情報をＤＩＡ／ＣＤＣ（以下で説明する）に提供するに過ぎない。ＭＣＯは、一般に、（自己指令）ＱｏＳも、いずれの形態のＣＡＣ、ＴＥも、極めて複雑な信頼性機構も、ネットワーク管理情報（例えば、ネットワーク統計）も、更には用途特定データ処理も実行しない。何故なら、これらの機能は、以下で説明するように、ここではＤＩＡ６００上にホストされるからである。

図５は、本明細書においてＭＣＯとして説明される１つ以上の実施形態と共に用いることができるデバイス例５００の模式ブロック図である。このデバイスは、１つ以上のネットワーク・インターフェース５１０（例えば、有線、ワイヤレス、ＰＬＣ等）、プロセッサ５２０、およびシステム・バス５５０によって相互接続されたメモリ５４０、ならびに電源５６０（例えば、バッテリ、プラグイン等）を含むことができる。加えて、ＭＣＯは、通常、センサおよび／またはアクチュエータ・コンポーネント５７０も含むことができる。

ネットワーク・インターフェース（１つまたは複数）５１０は、ネットワーク１００に結合されたリンクを通じて、即ち、ＩｏＴドメイン１１０内においてデータを伝達するために機械的、電気的、およびシグナリング回路を内蔵する。ネットワーク・インターフェースは、種々の異なる通信プロトコルを用いてデータを送信／受信するように構成することができる。更に、ノードは異なる２種類のネットワーク接続５１０、例えば、ワイヤレスおよび有線／物理接続を有してもよいこと、そしてこの図は単に例示のために過ぎないことを注記しておく。また、ネットワーク・インターフェース５１０は電源５６０とは別に示されているが、ＰＬＣでは、ネットワーク・インターフェース５１０は、電源５６０を経由して通信することもでき、または電源の一体コンポーネントであってもよい。具体的な構成では、ＰＬＣ信号が、電源に接続する（feed)電源ラインに結合されてもよい場合もある。

メモリ５４０は、本明細書において説明する実施形態に関連付けられたソフトウェア・プログラムおよびデータ構造を格納するために、プロセッサ５２０およびネットワーク・インターフェース５１０によってアドレス可能な複数の記憶位置を含む。尚、ある種のデバイスは、メモリが限られていたり、またはメモリを有さない場合もあることを注記しておく（例えば、デバイスおよび付随するキャッシュ上で動作するプログラム／プロセスの格納用以外のメモリがない）。プロセッサ５２０は、ソフトウェア・プログラムを実行しデータ構造５４５を操作するように構成された、必要なエレメントまたはロジックを含むことができる。オペレーティング・システム５４２は、その一部が通例メモリ５４０内に存在しプロセッサによって実行されるが、特に、デバイス上で実行するソフトウェア・プロセスおよび／またはサービスをサポートするための動作を呼び出すことによって、機能的にデバイスを編成する。これらのソフトウェア・プロセスおよび／またはサービスは、実例として、「ＭＣＯプロセス」５４８を構成する。このプロセス５４８は、本明細書において説明するような、ルーティング・プロセス／サービス５４８ａというような１つ以上のサブプロセスを含むこともできる。

先に注記したように、各ＭＣＯ５００は、それぞれの指定タスク（例えば、検知、作動、ルーティング）を実行し、コンピュータ・ネットワークに安全に加入し、基準状態情報を提供するのに十分なインテリジェンスに限定される。したがって、ＭＣＯプロセス５４８は、それに応じて、このようなＭＣＯアクションに関係する機能を実行するためにプロセッサ５２０によって実行されるコンピュータ実行可能命令を収容する。したがって、本明細書において説明するように、ＭＣＯプロセスは、複雑な用途特定データ処理を実行し、ＱｏＳ判断を行い、ＣＡＣ動作に関与し、ＴＥサービスを提供し、極めて複雑な信頼性プロトコルを実行し、ネットワーク管理情報を外挿補間するように構成されない。ルーティング・プロセス５４８ａは、全体的に縮退ルーティング・プロセスであり、ＭＣＯ５００から他のデバイス（他のＭＣＯ５００またはＤＩＡ６００）に通信を提供するだけのために、しかるべく簡素に保たれる。例えば、トポロジ情報は、以下で述べるように、単にＤＩＡから受信されればよく、またはＭＣＯがルーティング・エントリを格納することが全くできない場合、ルーティング・プロセス５４８は、セキュア・ルーティング技法に必要なメカニズムを設けることだけで構成されてもよい。即ち、セキュア・ルーティングのために、ネットワークにおける他のデバイスは、低機能デバイス(less capable device)にどこにパケットを送るか正確に伝えることができ、この低機能デバイスは、単に指令された通りにパケットを転送する。あるいは、種々の簡略化リンク状態プロトコル、例えば、Dimitrelis, at al.（２００２年１０月バージョン）による"Autocongifuration of routers using a link state routing protocol"（リンク状態ルーティング・プロトコルを用いたルータの自動構成）<draft-dimitri-zospf-00>と題するInternet Engineering Task Force (IETF) Internet Draft（インターネット設計専門委員会（ＩＥＴＦ）インターネット草稿）において指定されるような、zeroconfiguration Open Shortest Path Firstまたは「ｚＯＳＰＦ」、あるいは同様のＲＰＬの簡略化バージョンというような、ルーティング・プロトコルの最小限バージョンを使用してもよい。ＲＰＬの完全バージョンは、Winters, et al.（２０１１年３月１３日バージョン）による"RPL:IPv6 Routing Protocol for Low Power and Lossy Networks" （ＲＰＬ：低電力高損失ネットワークのためのＩＰｖ６ルーティング・プロトコル）<draft-iets-roll-rpl-19>と題するIETF Internet Draft（ＩＥＴＦインターネット草稿）において明記されている。

本明細書において説明する例示的なアーキテクチャによれば、他のタイプのデバイス、即ち、分散型インテリジェンス・エージェント（ＤＩＡ）６００は、ネットワーク（フィールド・エリア・ネットワーク１２０）のエッジにホストされた１組のソフトウェア／ハードウェア・モジュールによって構成され、ＩｏＴ／ＬＬＮ１１０内におけるルーティング、ＱｏＳを動的にアクティブにするか否か(whether/if)、どのようにアクティブにするかについての決定、ＣＡＣ、トラフィック設計、ＮＭＳ関連処理（例えば、ネットワーク統計の集計）、アプリケーション認識データ処理(application aware data processing)（例えば、ＭＣＯ５００からのデータを解釈し、潜在的にデータ・パケットを凝集／欠落させ、ローカル作動(local actuation)を誘起する等ができるアプリケーションをホストする）というような、多数のネットワーキングおよび用途指向機能性(application oriented functionality)を担う。当業者には認められようが、ＤＩＡ６００は、通例、深いパケット分析、インターネット・プロトコル・フロー情報エキスポート（ＩＰＦＩＸ）動作能力等が装備された、それよりも高機能なデバイス（例えば、エッジ・ルータ）上にホストされる。

図６は、本明細書ではＤＩＡとして説明される１つ以上の実施形態と共に用いることができるデバイス例６００の模式ブロック図である。デバイス５００と同様、ＤＩＡデバイス６００は、システム・バス６５０によって相互接続された１つ以上のネットワーク・インターフェース６１０、少なくとも１つのプロセッサ６２０、およびメモリ６４０、ならびに電源６６０(例えば、プラグイン）を含むことができる。一般に、ＤＩＡデバイス６００は、制限されたＭＣＯデバイス５００よりも高機能であり、したがって、処理能力が高く、メモリ容量も大きい等であってもよい。

メモリ６４０内部では、オペレーティング・システム６４２は、特に、本明細書において説明するような、「ＤＩＡ−Ｒ」プロセス６４８ａ、「ＤＩＡ−Ｑ」プロセス６４８ｂ、「ＤＩＡ−Ｎ」プロセス６４８ｃ等のような１つ以上のサブプロセスを構成することができる「ＤＩＡプロセス」６４８というような、本デバイス上で実行するソフトウェア・プロセスおよび／またはサービスをサポートするための動作を呼び出すことによって、機能的に本デバイスを編成する。即ち、ＤＩＡは、１組のインテリジェンス・モジュールで構成することができ、各モジュールが、アプリケーション関連機構（ネットワーキング・インテリジェンス自体には関係がない）に加えて、特定のタスク、即ち、ＤＩＡ−Ｎ（ＮＭＳ）６４８ｃ、ＤＩＡ−Ｑ（ＱｏＳ）６４ａｂ、ＤＩＡ−Ｒ（ルーティング）６４８ａ等を担う。更に、メモリ６４０は、１つ以上のデータ構造６４５も適宜格納するために用いることができる。

先に注記したように、各ＤＩＡ６００は、ＭＣＯのコンピュータ・ネットワークにエッジを提供するように構成され、ＭＣＯに対するインテリジェントなネットワーキング管理を担い、ＭＣＯに対して複雑なアプリケーション特定データ処理を実行する役割を果たす。したがって、ＤＩＡプロセス６４８は、このようなＤＩＡアクションに関係する機能をしかるべく実行するために、プロセッサ６２０によって実行されるコンピュータ実行可能命令を収容する。本明細書において説明する場合、したがって、ＤＩＡプロセス６４８は、前述のように、ＭＣＯからのデータを解釈する、ＭＣＯからのデータを集計する、ＭＣＯからデータを欠落させる、ＭＣＯにおけるローカル作動を誘起するというような、複雑なアプリケーション特定データ処理を実行するように構成される。加えて、ＤＩＡプロセス２４８は、更に、ＭＣＯに対してＱｏＳ判断を行う（ＤＩＡ−Ｑプロセス６４８ｂ）、ＭＣＯのためにＣＡＣ動作に関与する、ＴＥサービスをＭＣＯに提供する、そしてＭＣＯについてのネットワーク管理情報を外挿補間する（ＤＩＡ−Ｎプロセス６４８ｃ）役割も果たす。ルーティング・プロセス（ＤＩＡ−Ｒ）６４８ａは、主体的または反応的ルーティング・プロトコルというような、１つ以上のルーティング・プロトコルによって設けられる機能を実行するためにプロセッサ６２０によって実行されるコンピュータ実行可能命令を収容する。これは、当業者には理解されよう。これらの機能は、高機能デバイス上において、例えば、ルーティング／転送の決定を行うために用いられるデータを収容するルーティング／転送表（データ構造６４５）を管理するように構成することができる。

注記すべきは、ＤＩＡ６００は、ＭＣＯによって提供される状態報告、深いパケット分析を用いるトラフィック観察、およびＩＰＦＩＸに大きく頼るが、サービス・レベル・アグリーメントを決定する、および／または動作(performance)を監視してネットワーク性能が目的と整合するか否か（例えば、動作結果報告がＤＩＡ−Ｎによって提供されたか否か）判断するために、ＣＩＣ（１つまたは複数）７００とも密接に相互作用を行うことである。これを遂行するために、種々のＤＩＡプロセス２４８（モジュール２４８ａ−ｃ...）が互いに相互作用することができる。例えば、ＤＩＡ−Ｒ（ルーティング）がＤＩＡ−Ｑ（ＱｏＳ）と相互作用して、ルーティング・トポロジ変更のサービス品質に対する影響(consequences)を判定することができる。尚、このような協力はここでは可能であるが、現行の完全分散型モデルには該当しないことを注記しておく。即ち、ＤＩＡ６００は、一般に、ルーティング・トポロジを計算し、ネットワークにおいていつ／どこでＱｏＳをアクティブにするか否か決定し、ＮＭＳに関係するローカル・タスクを実行し（今日のモデルにおけるように、ＮＭＳとデバイスとの間でピア・ツー・ピア・ネットワーク管理機能を選択する代わりに）、トラフィック設計をどのように実行するか決定する等というような、種々の性質のタスクを実行する役割を果たすインテリジェント・モジュールである。（注記すべきは、これらの機構／アルゴリズムおよび関係するプロトコルの明細はどこかで詳細に明記されているかもしれないが、このような明細は本開示の範囲には含まれないということである。）
ＤＩＡ６００からの出力判断の結果、転送判断に対する変更、パケットに印を付けるまたは優先順位をパケットに付けるというようなＱｏＳ機構のアクティブ化、データ生成のアクティブ化および／または管理（例えば、検知されたデータが正しくないまたは筋が通っていない、または冗長であり、あるいは変化していない等というような場合に、検知されたデータの送出の開始、停止、および／または送出時刻の決定）というような、挙動変更を要求したＭＣＯ５００にメッセージ（例えば、ユニキャスト、またはもっと希に、マルチキャスト・メッセージ）が送られる。加えて、ＤＩＡ６００は、ＣＩＣ（１つまたは複数）７００に、ある種の補正措置を講ずるように要求することもでき、ＣＩＣ（１つまたは複数）は、例えば、機能障害を起こしたデバイス上において新たなソフトウェア／ファームウェアのアップグレードをダウンロードする試みにおいて、ＭＣＯ５００と直接相互作用することもできる。

本明細書において説明する例示的なアーキテクチャによれば、最終的に定められるタイプのデバイス、即ち、中央インテリジェンス・コントローラ（ＣＩＣ）７００は、ＩｏＴドメイン１１０を制御するためだけでなく、エンド・ユーザによって定められた１組の規則（例えば、サービス・レベル・アグリーメント（ＳＬＡ）の指定、セキュリティのレベル、性能監視のためのタスク等）を受けるための一層複雑なタスクをホストするために用いられる。ＣＩＣ（１つまたは複数）は、ＤＩＡ６００との直接通信を行い、ＤＩＡ６００は、決定を行い次いでＭＣＯと通信するが、場合によってはＣＩＣが直接ＭＣＯ５００と相互作用することもできる。

図７は、本明細書においてＣＩＣとして説明される１つ以上の実施形態と共に用いることができるデバイス例７００の模式ブロック図である。デバイス６００と同様、ＣＩＣデバイスは、システム・バス７５０によって相互接続された１つ以上のネットワーク・インターフェース７１０、少なくとも１つのプロセッサ７２０、およびメモリ７４０、ならびに電源７６０（例えば、プラグイン）を含むことができる。メモリ７４０（データ構造７４５を格納することができる）内部では、オペレーティング・システム７４２が、本明細書において説明するような、「ＣＩＣプロセス」７４８というような、本デバイス上で実行するソフトウェア・プロセスおよび／またはサービスをサポートするための動作を呼び出すことによって、機能的に本デバイスを編成する。

具体的には、先に注記したように、ＣＩＣ（１つまたは複数）７００は、ＭＣＯおよびＤＩＡの動作制御を支配するための複雑なタスクを実行するように構成され、更にＭＣＯおよびＤＩＡ動作に対する１組のユーザ定義規則を受けるために１つ以上のインターフェースを設けるように構成される。したがって、ＣＩＣプロセス７４８は、このようなＣＩＣアクションに関係する機能をしかるべく実行するためにプロセッサ７２０によって実行されるコンピュータ実行可能命令を収容する。したがって、本明細書において説明するように、ＣＩＣプロセス７４８は、セキュリティ動作、性能監視、およびＳＬＡ管理等というような、ＣＩＣによって実行されるＭＣＯおよびＤＩＡ動作の制御を支配するための複雑なタスクを実行するように構成される。加えて、前述のように、ＣＩＣプロセス７４８は、ＤＩＡから命令を受け、対応してＭＣＯ動作を更新する（例えば、ＤＩＡを介してまたはＭＣＯに直接）ように構成することもできる。

以上で説明したこのようなアーキテクチャは、従来のコンピュータ・アーキテクチャからの強い枠組みの移行を明記する(specify)。例えば、現行のモデルでは、ＱｏＳは、トラフィック観察やＳＬＡには関係なく、各ノードにおいてアクティブ化されるが、一方、このモデルでは、外部ノード（ＤＩＡをホストする）が、トラフィック観察やＣＩＣによって供給されるＳＬＡに基づいて、ＱｏＳをアクティブ化しなければならないか否か、そしていつアクティブ化しなければならないか決定する。今日のネットワークでは、ルーティングは完全に集中される（例えば、殆どの光／ＳＤＨネットワークにおいて）かまたは分散されるかのいずれかである。本明細書において説明するアーキテクチャでは、しかしながら、ＬＢＲ（ＤＩＡ６００）の役割は、必要な場合、必要なときに、必要な場所で、ルーティング・トポロジを繰り返し改良および／または構築することである。また、ＮＭＳ枠組みも変更される。ＮＭＳとデバイスとの間におけるピア・ツー・ピア・モデルの代わりに、中間インテリジェンスがネットワークに追加され、ＤＩＡにおいて多数のＮＭＳをしかるべく実行する。

支援型インテリジェント・ルーティング
先に注記したように、大規模ＩＰスマート・オブジェクト・ネットワークは、多数の技術的課題を提起する。例えば、このようなネットワーク（多数のセンサおよびアクチュエータがあるスマート・グリッド・ネットワーク、スマート、シティ、または高度測定インフラストラクチャ即ち「ＡＭＩ」ネットワーク）の密度(degree of density)は、非常に高いこともあり、各ノードが数百もの近隣(neighbor)を伴うことも希ではない。これは、特に、制約されたリンクがデータ送信に危害をもたらす可能性があるＬＬＮにとって問題である。

現行の既存モデルに伴う主要な問題の１つは、制約を受けるデバイスの全体的なアーキテクチャの複雑さにある。例えば、ＲＰＬの中核をなす態様の１つは、ノードがどのようにＤＡＧに加入する(join)かにしたがって規則を決定するＤＡＧルート上に構成される目的関数（ＯＦ）の使用にある。ＯＦは、多数の規則および目的に加えて、ＤＡＧを構築するために用いられるメトリックおよび制約のリストを指定する。スマート測定用途における典型的なＯＦは、「バッテリ動作ノードを回避しつつ、信頼性メトリックに基づいて最短経路（つまり、最も信頼性がある経路）を発見すること」であろう。サブステーション自動化用途における典型的なＯＦは、「暗号化リンクを用いつつ、遅延メトリックに基づいて最も短い経路（最短遅延）を発見すること」であろう。

ＲＰＬ（または他のプロトコル）の他の態様も比較的複雑であり、数千のノードを含む既存のネットワークにおけるルーティングには確かに非常に適しているが、制約を受けるネットワーク内では精巧化(sophistication)（多数の利用可能なパラメータ、チューニング、任意の建物ブロック）を扱うのが難しい場合もある。例えば、現在の推定では、ＲＰＬは状態維持のために数ＫバイトのＲＡＭを必要とし、フラッシュに関しては更に多少多いメモリを必要とすることを示す。生憎、分散型ルーティング手法を用いるＬＬＮにおけるルーティングの課題に固有な複雑さのレベルは、ネットワークにおけるノード数と共に急速に高くなる。これは、特に、大規模な分散型ルーティング判断の障害探索を行うことの難しさは言うまでもなく、ＮＣＯ上で必要な処理およびストレージ量を最少にすることを意図する、以上で説明したネットワークにおいて問題である。しかしながら、同時に、このような複雑なルーティング・プロトコルの精巧化を維持することは有益でもある。何故なら、これらは、ルーティングを一層効率的に、一層動的に、そして一層インテリジェントにするために長年にわたって開発されてきたからである。

したがって、本明細書における新規な技法によれば、ＩｏＴ／ＬＬＮの内においてエッジ・ルータ（例えば、ＤＩＡ６００）上にホストされる繰り返しおよび条件付きアルゴリズムを使用することから構成される、モノのインターネットのためのルーティング手法について説明する。これは、ネットワーク状態を収集し、現在のルーティング・トポロジ・インスタンスに対して何らかのルーティング修正を行うべきか否か判断するために多数の入力（例えば、ＳＬＡ、ルーティング状態、種々の性質の規則）を利用する。つまり、ノード(例えば、ＭＣＯ５００）は、簡略化された分散型ルーティング手順を利用することができ、ルーティング・エンジン（例えば、ＤＩＡ）は、種々の入力にしたがって要求されるときにのみ、ルーティング・トポロジを繰り返し改良することによって、特にモノのインターネットにおける大規模なルーティングに非常に適した、新規な分散型／半集中型ルーティング手法が得られる。

具体的には、以下で詳細に説明する本開示の１つ以上の実施形態によれば、分散型インテリジェンス・エージェント（ＤＩＡ）がコンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）からローカル状態情報を収集する。ローカル状態情報は、ＭＣＯ毎にあり、対応する近隣リストと、それぞれのＭＣＯに対して選択された次のホップとを含み、ＭＣＯの内１つ以上が、自己最適化を全く行わずに、それらの次のホップを選択するように構成される。次いで、ＤＩＡは、選択された次のホップを組みあわせた結果である現行ルーティング・トポロジを、計算された最適ルーティング・トポロジと比較して分析し、現在のルーティング・トポロジを最適化するか否か決定する。現在のルーティング・トポロジを最適化すべきであると決定したことに応答して、ＤＩＡはユニキャスト・ルーティング命令を１つ以上の個々のＭＣＯに送信し、これらの個々のＭＣＯに、現在のルーティング・トポロジをどのように最適化するかしかるべく命令することができる。

実例として、ＤＩＡ（またはＬＢＲ）アクションに関して本明細書において説明する技法は、ＤＩＡプロセス６４８、または更に特定すれば、ＤＩＡ−Ｒ（ルーティング）プロセス６４８ａにしたがってというように、ハードウェア、ソフトウェア、および／またはファームウェアによって実行することができ、本明細書において説明する新規の技術に関係する機能を実行するためにプロセッサ６２０によって実行されるコンピュータ実行可能命令を収容することができる。あるいは、ＭＣＯ（またはＬＬＮデバイス）に関して、ＭＣＯプロセス５４８、または更に特定すれば、ルーティング・プロセス５４８ａにしたがってというように、ハードウェア、ソフトウェア、および／またはファームウェアによってアクションを実行することができ、同様に本明細書において説明する新規な技法に関係する機能を実行するためにプロセッサ５２０によって実行されるコンピュータ実行可能命令を収容することができる。

加えて、図１のＬＬＮまたはＩｏＴドメイン１１０の表現例として、図８は、種々の通信方法によって相互接続されたノード／デバイス（例えば、図示のように、「ＬＢＲ／ルート」、「１１」、「１２」．．．「４５」と表記される）を実例として含むコンピュータ・ネットワーク例８００の模式ブロック図である。例えば、以上で説明した例示的なアーキテクチャにしたがって、ＬＢＲ／ルート・デバイスはＤＩＡ６００として構成することができ、一方残りのデバイス１１−４５はＭＣＯ５００とすることができる。

動作に関しては、本明細書における技法は、以下で更に詳しく説明するように、概略的に４つの主要なコンポーネントを基本とする。
１）最少ルーティング・トポロジ（ＭＲＴ）を構築するために必要な機能性から最小限の部分集合を選択することから構成される、ＲＰＬのような極めて複雑なルーティング・プロトコルの縮減バージョン。ＭＲＴは、いずれの形態の最適化も必要としない、最も簡素化された形態のルーティング・トポロジとして定められる。
２）個々のノード各々によって供給されるＤＩＡ−Ｒによるローカル状態の集合体。
３）ＭＲＴを最適化すべきか否か判断するために、他の制約と共に、最適ルーティング・トポロジ（ＯＲＴ）、要求されるサービス・レベル・アグリーメント（ＳＬＡ）を参照するＭＲＴのルーティング分析。
４）新たに計算されたルーティング・トポロジ・インスタンス「ＲＴ（ｉ）」にしたがって、ノードにユニキャスト・ルーティング命令を送る。次いで、本技法は反復し、ステップ３）に戻る。

＝＝ＭＲＴの構築＝＝
先に注記したように、以上のＲＰＬプロトコル例は、ＬＬＮ内部のデバイスから中央制御点（例えば、ＬＬＮ境界ルータ（ＬＢＲ）または「ルート・ノード／デバイス」一般）に向かう多点対１点（ＭＰ２Ｐ）トラフィック、および中央制御点からＬＬＮ内部のデバイスへの１点対多点（Ｐ２ＭＰ）トラフィック（そして二点間即ち「Ｐ２Ｐ」トラフィックも）をサポートするメカニズムを提供する。ＲＰＬ（「リップル」と発音する）は、一般に、制御トラフィックを結び付ける、リペアをサポートする等のための１組の機構に加えて、トラフィック／パケット１５０をルーティングするときに用いる無閉路有向グラフ（ＤＡＧ）を構築する距離ベクトル・ルーティング・プロトコルである。注記すべきは、当業者には認められるであろうが、ＲＰＬはマルチ・トポロジ・ルーティング（ＭＴＲ）の概念もサポートすることであり、これによって、個々の要件にしたがってトラフィックを搬送するために多数のＤＡＧを構築することができる。尚、ＲＰＬプロトコルは、ＭＣＯ上に簡略化したプロセスを維持するために、１組の完全な機能性を定めることができるが、本明細書において詳細に説明するように、ＲＰＬの縮小バージョン、例えば、ルーティング・トポロジを作成する機能性の内最小限の部分集合を用いることもできる。

また、無閉路有向グラフ（ＤＡＧ）は、循環（ループ）が存在しないことを仮定するように全てのエッジが方位付けられるプロパティを有する有向グラフである。全てのエッジは、多くの場合、ＤＡＧのデバイスを、インターネット、ワイド・エリア・ネットワーク、または他のドメインというような、更に大きなインフラストラクチャによって相互接続するために、１つ以上のルート・ノード（例えば、「クラスタヘッド」(clusterhead)または「シンク」(sink)）に向けて方位付けられそこで終端する経路内に含まれる。加えて、宛先指向ＤＡＧ（ＤＯＤＡＧ：Destination Oriented DAG）とは、１つの宛先、即ち、出て行くエッジがない１つのＤＡＧルートにおいて根付く(rooted)ＤＡＧである。ＤＡＧ内における特定のノードの「ペアレント」とは、ＤＡＧルートに向かうパス上においてその特定のノードの直ぐ下に来る後継のことであり、ペアレントは特定のノード自体よりも低いランクを有し、ノードのランクが、ＤＡＧルートに関するノードの位置を識別する（例えば、ノードがルートから遠ざかる程、そのノードのランクは高くなる）。また、ツリーとは一種のＤＡＧであり、ＤＡＧにおける各デバイス／ノードが通常１つのペアレントまたは１つの好ましいペアレントを有することも注記しておく。ＤＡＧは、目的関数（ＯＦ）に基づいて構築することができ(例えば、ルーティング・プロセス５４８ａによって）、その役割は、ＤＡＧをどのように構築するかについての規則を指定することである（例えば、ペアレントの数、バックアップ・ペアレント等）。しかしながら、プロセスを簡素に保つために、目的関数を使用せずに、ＭＣＯによってＤＡＧを構築することもでき、代わりに、本明細書において具体的に説明する、非常に基本的な次位ホップ選択アルゴリズムをここでも用いてもよい。

したがって、本明細書における技法のこのコンポーネントによれば、ＭＣＯ５００の役割は、初期ＭＲＴ、最少ルーティング・トポロジを構築することを含む(consist in)。実例として、この目的のために、ＲＰＬプロトコルの最少部分集合が使用される。ＲＰＬ ＤＯＤＡＧ情報オブジェクト（ＤＩＯ）のようなＤＡＧ情報を伝搬するために、簡略化リンク・ローカル・マルチキャスト・メッセージを用いることができる。ＲＰＬ ＤＯＤＡＧ情報オブジェクト（ＤＩＯ）は、ノードが、ＲＰＬインスタンスを発見し、その構成パラメータを学習し、ＤＯＤＡＧペアレント集合を選択し、上り(upward) ルーティング・トポロジを維持することを可能にする。しかしながら、ローカル・リペアを担うメカニズムの全てと共に、目的関数の観念が除去される。特定の状況の下で、ノードにルーティング近隣発見を要求するために送られる（簡略化されるが、そしてフィルタリングは使用せずに）ＤＩＳ（ＤＯＤＡＳ情報要請）メッセージは保持されるが、一方下りルートをプロビジョニングするためのローカル・ルーティング隣接性およびプレフィックス情報を報告するために用いられる宛先告知オブジェクト（ＤＡＯ：Destination Advertisement Object）メッセージは除去される。単純な中毒(poisoning)の観念は、ループ検出プロセスおよびトリックル・タイマ(trickle timer)の使用と共に保持される（しかし、以下で説明するように修正される）。新たなペアレント選択アルゴリズムおよびＤＩＯ伝搬に対する判断も、以下で説明するように、変更される。

尚、このような変更は非常に劇的であり、分散型および主体的ルーティング・プロトコルによる簡略化された距離ベクトル・ルーティング・トポロジの形成に至ることを注記しておく。言い換えると、ＭＣＯは、自己最適化を全く行わずに、現行ルーティング・トポロジの構築に関与し、現在のルーティング・トポロジ（例えば、ＭＲＴ）の初期インスタンスは、ループ防止を有するが、先に注記したように、目的関数、ローカル・リペア用メカニズムを有さず、または告知メッセージを伝搬しない。

したがって、図９は、例えば、以上で説明した技法によって、図８のネットワーク・ドメイン内に作成することができる最少現行ルーティング・トポロジ（無閉路有向グラフ（ＤＡＧ））の一例を示す。例えば、特定の次のホップ即ち「ペアレント」と通信するために（そして、チャイルドが存在する場合には、逆に、チャイルドと通信するために）、あるリンク８０５をノード毎に選択することができる。ＤＡＧ９１０（太線で示される）から選択されるこれらのリンクは、ルート・ノードから１つ以上のリーフ・ノード（チャイルドがないノード）に向けて延びる。次いで、トラフィック／パケット１５０が、ルートに向かって上流方向またはリーフ・ノードに向かって下流方向のいずれかにＤＡＧ９１０を横断する。尚、現行（例えば、最少）ルーティング・トポロジ、ＤＡＧ９１０は、通常最適化されておらず、機能するが、特に本明細書において説明したように、改良の余地があると考えられる。

＝＝ＤＩＡ−Ｒによるローカル状態の収集＝＝
ＭＣＯ５００は、ローカル状態情報９５０を対応するＤＩＡ６００（例えば、ＬＢＲ）に送信する。このローカル状態情報は、現行ルーティング・トポロジに対する対応する近隣リスト、およびＭＣＯに選択された次のホップを含む。即ち、ネットワークにおける各ノードは、例えば、IPｖ６ND（近隣発見）の使用によって、到達可能な近隣のリストを共有する。次のホップとして選択された近隣には、特定的にフラグが立てられる。注記すべきは、リストのエレメント（近隣）毎に、報告ノード／ＭＣＯが、ノードによって計算することができるコストに応じて、リンクのローカル・コスト（例えば、信頼性、遅延等に関して）というような追加情報を提供できることである。尚、ノードにおける複雑さのレベルを最低に抑えるために、単純なメトリックを用意することが予期されることを注記しておく。例えば、期待送信回数（ＥＴＸ：expected transmission count）は、リンク・ベース受信信号強度指示（ＲＳＳＩ）（またはＰＬＣリンクについての同等の測定値）と同様、リンク・レイヤのために（ＡＣＫ／ＮＡＣＫが用いられる場合）かなり容易にノードによって得ることができる。

尚、近隣リストはルーティング選択には結び付けられず、全ての近隣を羅列する。これは、ルーティングの潜在的な候補とはならないノード（例えば、弱すぎるリンク等）を除外した後でも潜在的に可能である。この近隣リストは、ノード／ＭＣＯによってＤＩＡ６００（ＤＩＡ−Ｒ６４８ａ）に供給され、ＤＨＣＰ（動的ホスト構成プロトコル）内で搬送されブートストラッピング・プロセス中にノード（ＭＣＯ）に供給される、新たに定められた選択肢によって発見することができる。尚、以下で説明するが、ローカル状態情報９５０は、重要な変化が観察されたときにはいつでも（例えば、ヒステリシスを用いて）共有されてもよいことを注記しておく。別の言い方をすると、更新されたローカル状態情報が直前に送信されたローカル状態情報から著しく変化したことに応答して、更新されたローカル状態情報９５０がＭＣＯからＤＩＡに送信されてもよい。

＝＝ＤＩＡ−Ｒルーティング分析および最適化＝＝
一旦ネットワークにおける各ノードの近隣リストが収集されたなら、ＤＩＡ−Ｒ６４８ａは、このリストの収集を用いてネットワーク・データベース（ＮＤＢ）を形成する。このデータベースから、ＤＩＡ−Ｒは、ネットワーク全体を見ることができる１つ以上の精巧なルーティング・アルゴリズムを用いて、最適なルーティング・トポロジを計算することができる。例えば、図１０は、図８の特定のネットワーク・ドメイン内における最適ルーティング・トポロジ（ＤＡＧ１０１０）の一例を示す。例示的な最短パス優先（ＳＰＦ：shortest path first)ダイクストラ(Dijsktra)のアルゴリズム（例えば）を用いて最適ルーティング・トポロジを計算することができ、１つ以上の制約に基づくことができ、あるいは１つ以上の要求されるサービス・レベル・アグリーメント（ＳＬＡ）を満たすことに基づくこともできる。

ＤＩＡは、情報９５０から選択された次のホップを組みあわせた結果である現行ルーティング・トポロジ９１０を、計算された最適ルーティング・トポロジ１０１０と比較して分析して、現行ルーティング・トポロジを最適化するか否か決定する。ルーティング・トポロジを比較するためには、総合的なルーティング・トポロジのコスト（全てのパスの総和）に関する差、予め定められた最大パス・コストおよび最大パス・コスト差を超えるパスの本数、または前述したことのいずれかの重み付け多項式関数というような、種々の技法および判断基準を用いることができる。本明細書において言及する場合、「デルタ」とは最適ルーティング・トポロジと現行ルーティング・トポロジとの間で比較したときの差のことである。尚、分析が１つ以上の要求されたＳＬＡを満たさない現行ルーティング・トポロジ内のパスに基づくことができるように、ＤＩＡ−Ｒの第２入力は、ネットワークにおけるフローについてのＳＬＡ要件を収集する（例えば、ＮＭＳまたはＣＩＣによって）ことで構成されることを注記しておく。

デルタが既定の閾値を超過した場合、および／またはＳＬＡがもはや満たされていない（ＱｏＳをイネーブルすることによって解決できない）とＤＩＡ−Ｒが判断した場合、これは、現行ルーティング・トポロジが最適未満の望ましくないレベルにあることの指示となり、ＤＩＡ−Ｒは反復最適化モードに入る。現行ルーティング・トポロジにおける最適未満の主要なエリアを（ネットワーク・データベースを用いて）識別するためには、周知のアルゴリズムを用いればよい。ＤＩＡ−Ｒは、このように、新たに定められたメッセージを送ることができ、このメッセージは、目標ノード（１つまたは複数）に対して、そのルーティング表を修正しその結果現行ルーティング・トポロジを更新することを求める命令を含む。ＤＩＡ−Ｒが、必要とされる変更の数も考慮できることは注記するに値する。例えば、ルーティング・トポロジにおいて２つの変更を行うことによってデルタが３５％改善し、１０個の変更によって４５％改善する場合、ＤＩＡ−ＲはＳＬＡを満たす限り最小数の変更を選択するとよい。

図１１Ａに示すように、現行ルーティング・トポロジ９１０（図９の）を最適化すべきであると決定したことに応答して、ＤＩＡ６００（ＤＩＡ−Ｒ６４８ａ）は、ユニキャスト・ルーティング命令１１５０を１つ以上の個々のＭＣＯに送り、これらの個々のＭＣＯに、現行ルーティング・トポロジをどのように最適化するかについてしかるべく命令する。例えば、送信されるルーティング命令１１５０は、それぞれの個々のＭＣＯに対する新たな次のホップの選択を含むことができる。図示のように、したがって、ＤＩＡからユニキャスト・ルーティング命令１１５０を受信すると、ＭＣＯは、このルーティング命令にしたがって、更新された現行ルーティング・トポロジに合わせて次のホップ（および任意にバックアップの次のホップ）を選択し直し、こうして現行ルーティング・トポロジ９１０を更新することができる。

次いで、タイマを装備することができ、その満了後に、ＤＩＡ−Ｒによって、最新の更新された現行ルーティング・トポロジ９１０と最適ルーティング・トポロジ１０１０との間におけるコスト差として、ＳＬＡ要件を加味して、デルタを再計算する。条件がなおも満たされない場合、現行ルーティング・トポロジを更に改良しなければならず、最適化プロセスを繰り返し継続する。そうでない場合、本プロセスは停止する。例えば、図１１Ｂは、トポロジ例９１０において行われるかもしれない更なる最適化の繰り返しを示す。具体的には、ＭＣＯから更新されたローカル状態情報９５０を受信すると、ＤＩＡは対応する更新された現行ルーティング・トポロジを分析し、更新された現行ルーティング・トポロジを更に最適化しなければならないと判断したことに応答して、追加のユニキャスト・ルーティング命令１１５０を送信する。尚、現行ルーティング・トポロジを更新することに加えて、ＤＩＡ−Ｒはネットワーク・データベースを更新し続け、継続的にコストのデルタを監視するために最適ルーティング・トポロジ１０１０を計算することも注記しておく。

図１２は、最小限接続オブジェクト（ＭＣＯ）の観点からの、本明細書において説明した１つ以上の実施形態による、支援型インテリジェント・ルーティングのための簡略化した手順の一例を示す。手順１２００はステップ１２０５において開始し、ステップ１２１０に進み、以上で詳しく説明したように、ＭＣＯ５００が、自己最適化を全く行わずに、現行ルーティング・トポロジ（例えば、ＤＡＧ９１０）の構築に関与する。現行ルーティング・トポロジの初期インスタンス、例えば、最少ルーティング・トポロジは、一般に、ループ防止を有するが、目的関数を有さず、ローカル・リペアのためのメカニズムを有さず、告知伝搬メッセージも有さない。

現行ルーティング・トポロジに基づいて、ステップ１２１５において、ＭＣＯは、ＤＩＡ６００に、対応する近隣リストと選択された次のホップとを含むローカル状態情報９５０を適宜送信する。その後、その特定のＭＣＯにおいて現行ルーティング・トポロジを最適化することができそして最適化すべきである場合、この特定のＭＣＯがステップ１２２０においてユニキャスト・ルーティング命令１１５０をＤＩＡから受信することができる。命令１１５０は、現行ルーティング・トポロジをどのように最適化するかについて命令する。したがって、ステップ１２２５において、ＭＣＯは、ＤＩＡからのルーティング命令にしたがって、更新される現行ルーティング・トポロジに対して次のホップを選択し直すことができる。加えて、ステップ１２３０（ステップ１２２５の後に行われるように示されるが、本プロセスにおいて適した時点であればいつでも実行することができる）において、更新したローカル状態情報に、直前に送信されたローカル状態情報から著しい変化があることに応答して、ＭＣＯは更新したローカル状態情報をＤＩＡに送信することができる。プロセス１２００はステップ１２２０に戻ることができ、ここで、ルーティング・トポロジを最適化するために、他の命令を受けることができる。

加えて、図１３は、分散型インテリジェンス・エージェント（ＤＩＡ）の観点からの、本明細書において説明した１つ以上の実施形態による、支援型インテリジェント・ルーティングのための簡略化した手順の他の例を示す。手順１３００はステップ１３０５において開始し、ステップ１３１０に進み、ここで、先に詳しく説明したように、ＤＩＡ６００（例えば、ＬＢＲ）がローカル状態情報９５０をコンピュータ・ネットワークにおける複数のＭＣＯ５００から収集する。ＭＣＯ毎のローカル状態情報は、前述のように、対応する近隣リストと、それぞれのＭＣＯに選択された次のホップとを含み、ＭＣＯの内１つ以上が、自己最適化を全く行わずに、それらの次のホップを選択するように構成される。したがって、ステップ１３１５において、ＤＩＡは、選択された次のホップを組みあわせた結果である現行ルーティング・トポロジ９１０を、計算された最適ルーティング・トポロジ１０１０と比較して分析し、現行ルーティング・トポロジを最適化するか否か決定することができる。ステップ１３２０において、最適化を行うことができそして行うべきであると判断した場合、ステップ１３２５において、ＤＩＡはユニキャスト・ルーティング命令１１５０を１つ以上の個々のＭＣＯに送信し、これらの個々のＭＣＯに、現行ルーティング・トポロジをどのように最適化するかについてしかるべく命令することができる。次いで、手順１３００はステップ１３１０に戻り、更新されたローカル状態情報に基づいて、ルーティング・トポロジ最適化の更なる繰り返しを、対応して行うことができる。

尚、手順１２００〜１３００内におけるあるステップは、先に説明したように任意であってもよく、図１２および図１３に示したステップは例示のための単なる例に過ぎず、ある種の他のステップを所望に応じて含ませるまたは除外してもよいことは注記してしかるべきである。更に、これらのステップを特定の順序で示したが、この順序は単なる例示であり、本明細書における実施形態の範囲から逸脱することなく、これらのステップの適した配列であればいずれでも利用することができる。更に、手順１２００、１３００について別個に説明したが、各手順からのある種のステップを他の各手順に組み込むこともでき、これらの手順は互いに排他的であることを意図しない。

したがって、本明細書において説明した新規な技法は、特にＭＣＯが用いられる場合における、ＬＬＮに対する支援型インテリジェント・ルーティングを提供する。具体的には、本明細書における技法は、縮退ＤＡＧを構築し、最小限の分散型インテリジェンスを要求することによって構成される新たな手法を明記した。ノードは、ＬＢＲ上にホストされた外部ルーティング・エージェント（ＤＩＡ−Ｒ）によって補助され、必要なときおよび必要とされた場合にのみルーティング・トポロジ（ＲＴ）を改良する。即ち、以上のアーキテクチャでは、ＭＣＯにはインテリジェントなルーティング・メカニズムを構成する必要がなく、つまり、本明細書における技法は、ＭＣＯに対する全体的な複雑さ、構成の負担、およびＭＣＯによって扱われるタスクの数を劇的に削減し、こうしてエネルギを節約する。これは、ＬＬＮにおいて極めて重要である。例えば、本明細書における技法は、「程よい」ルーティング・トポロジを提供しつつ、ＭＣＯに対する分散型ルーティングの複雑さのレベルを劇的に低減させ、モノのインターネットおよび遙かに効率的なメカニズムに対して、大規模ＬＬＮおよびモノのインターネットにおけるルーティングの障害回避を行うための非常に柔軟な(scale)ルーティング手法が得られる。

尚、当業者には理解されようが、ルーティング・エージェント、例えば、ＤＩＡ（ＤＩＡ−Ｒ）は、パス計算エレメント（ＰＣＥ）ではないことを注記しておく。具体的には、ＰＣＥは、通常、パス計算クライアント（ＰＣＣ）によって送られる明示的な要求にしたがってパスを計算するルーティング・エンジンである。以上で示し説明したように、ＤＩＡ−Ｒはこのような要求を全く受けず、代わりにルーティング条件およびＣＩＣによって受信される規則またはフィードバックにしたがって、現行ルーティング・トポロジを改良すべきか否か判断する。これは、ＰＣＥによってサポートされる手法とは劇的に異なる手法である。

以上、特にＭＣＯが用いられる場合に、ＬＬＮに対する支援型インテリジェント・ルーティングの機能を提供する例示的な実施形態について示し説明したが、本明細書における実施形態の主旨および範囲内において、種々の他の改造や変更もできることは理解されてしかるべきである。例えば、本明細書では、ＭＣＯと共に用いるための、以上で説明した特定の例示的ＩｏＴアーキテクチャに関して、実施形態を示し説明した。しかしながら、実施形態は、その広義な意味では、そのように限定されるのではなく、実際には、ＬＬＮ一般（比較的「スマート」なオブジェクトを有する）のような他のタイプのネットワークおよび／またはプロトコルとでも、または特に低電力でも高損失でもないネットワークにおいてでも用いることができる。更に、ＲＰＬプロトコルが、ＭＲＴを作成するためにＭＣＯ上における縮小形態で用いられるインテリジェント・ルーティング・プロトコルとして示されたが、他の精巧なルーティング・プロトコルが縮小形態で用いられてもよい。加えて、ＣＩＣがＤＩＡとは別個であるように示されたが、ある種の実施形態では、ＣＩＣ機能性（ＣＩＣプロセス７４８）が１つ以上のＤＩＡ上にローカルに存在することも可能である。即ち、ＣＩＣおよびＤＩＡが、ＣＩＣおよびＤＩＡ機能の双方を構成された１つのデバイスであることも可能である。したがって、（または別個に）、ＤＩＡはユーザ定義規則および構成を受信するためのインターフェースも有してもよい。

以上の説明は、具体的な実施形態を目的とした。しかしながら、説明した実施形態に対して他の変形や変更を行うこともでき、実施形態の利点の一部または全部も達成されることは明白である。例えば、本明細書において説明したコンポーネントおよび／またはエレメントを、コンピュータ、ハードウェア、ファームウェア、またはその組み合わせにおいて実行するプログラム命令を有する有形（一時的でない）コンピュータ読み取り可能媒体（例えば、ディスク／ＣＤ等）に格納されたソフトウェアとして実現することができる。したがって、この説明は、一例のみとして捕らえられるべきであり、本明細書における実施形態の範囲を別段限定するように捕らえてはならない。しがたって、添付した特許請求の範囲の目的は、本明細書における実施形態の真の主旨および範囲に該当するような変形および変更の全てを含むことである。

Claims (21)

1. 分散型インテリジェンス・エージェント（ＤＩＡ）によって、コンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）からローカル状態情報を収集するステップであって、各ＭＣＯについての前記ローカル状態情報が、対応する近隣リストと、それぞれのＭＣＯに選択された次のホップとを含み、前記ＭＣＯの内１つ以上が、自己最適化を全く行わずに、次のホップを選択するように構成される、ステップと、
   前記ＤＩＡによって、前記選択された次のホップを組みあわせた結果である現行ルーティング・トポロジを、計算された最適ルーティング・トポロジと比較して分析し、前記現行ルーティング・トポロジを最適化するか否か決定するステップと、
   前記現行ルーティング・トポロジを最適化すべきであるという決定に応答して、前記ＤＩＡから１つ以上の個々のＭＣＯに、個々のＭＣＯに前記現行ルーティング・トポロジをどのように最適化するかについて命令するユニキャスト・ルーティング命令を送信するステップと
   を含む、方法。
2. 請求項１記載の方法であって、更に、
   前記ＤＩＡにおいて更新されたローカル状態情報を前記ＭＣＯから受信するステップと、
   対応する更新された現行ルーティング・トポロジを分析するステップと、
   前記更新された現行ルーティング・トポロジを更に最適化すべきであるという決定に応答して、追加のユニキャスト・ルーティング命令を送信するステップと
   を含む、方法。
3. 請求項１記載の方法であって、更に、
   １つ以上の制約に基づいて前記最適ルーティング・トポロジを計算するステップを含む、方法。
4. 請求項１記載の方法であって、更に、
   １つ以上の要求されたサービス・レベル・アグリーメント（ＳＬＡ）を満たすことに基づいて、前記最適ルーティング・トポロジを計算するステップを含む、方法。
5. 請求項１記載の方法において、前記現行ルーティング・トポロジを最適化するか否か決定するステップが、前記現行ルーティング・トポロジと前記最適化されたルーティング・トポロジとの間における総合コスト差、前記現行ルーティング・トポロジと前記最適化されたルーティング・トポロジとの間における最大パス・コスト差、前記現行ルーティング・トポロジ内において１つ以上の要求されたサービス・レベル・アグリーメント（ＳＬＡ）を満たさないパス、および前記現行ルーティング・トポロジを最適化するために必要とされる変更の数で構成される群から選択される少なくとも１つの因子に基づく、方法。
6. 請求項１記載の方法において、前記送信されるルーティング命令が、前記個々のＭＣＯそれぞれに対する新たな次のホップの選択を含む、方法。
7. 請求項１記載の方法において、前記ローカル状態情報が、ローカル・リンクのコスト、ローカル・リンクの信頼性、ローカル・リンクの遅延、ローカル・リンクの期待送信回数（ＥＴＸ）、およびリンク・ベース受信信号強度指示（ＲＳＳＩ）の内少なくとも１つを含む、方法。
8. コンピュータ・ネットワークにおいて通信するための１つ以上のネットワーク・インターフェースと、
   前記ネットワーク・インターフェースに結合され１つ以上のプロセスを実行するように構成されたプロセッサと、
   前記プロセッサによって実行可能なプロセスを格納するように構成されたメモリと
   を含む装置であって、前記プロセスが、実行されると、
   コンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）からローカル状態情報を収集し、各ＭＣＯについての前記ローカル状態情報が、対応する近隣リストと、それぞれのＭＣＯに選択された次のホップとを含み、前記ＭＣＯの内１つ以上が、自己最適化を全く行わずに、次のホップを選択するように構成され、
   前記選択された次のホップを組みあわせた結果である現行ルーティング・トポロジを、計算された最適ルーティング・トポロジと比較して分析し、前記現行ルーティング・トポロジを最適化するか否か決定し、
   前記現行ルーティング・トポロジを最適化すべきであるという決定に応答して、１つ以上の個々のＭＣＯに、個々のＭＣＯに前記現行ルーティング・トポロジをどのように最適化するかについて命令するユニキャスト・ルーティング命令を送信する、
   ように動作可能である、装置。
9. 請求項８記載の装置において、前記プロセスが、実行されると、更に、
   更新されたローカル状態情報を前記ＭＣＯから受信し、
   対応する更新された現行ルーティング・トポロジを分析し、
   前記更新された現行ルーティング・トポロジを更に最適化すべきであるという決定に応答して、追加のユニキャスト・ルーティング命令を送信する
   ように動作可能である、装置。
10. 最小限接続オブジェクト（ＭＣＯ）とコンピュータ・ネットワークにおける複数のＭＣＯによって、自己最適化を全く行わずに現行ルーティング・トポロジの構築に関与するステップであって、前記現行ルーティング・トポロジの初期インスタンスが、ループ防止を有するものの、目的関数を有さず、ローカル・リペアのためのメカニズムを有さず、告知伝搬メッセージも有さない、ステップと、
    前記ＭＣＯから分散型インテリジェンス・エージェント（ＤＩＡ）に、対応する近隣リストと前記ＭＣＯに選択された次のホップとを含む、前記現行ルーティング・トポロジについてのローカル状態情報を送信するステップと、
    前記ＭＣＯにおいて、前記ＤＩＡから、前記現行ルーティング・トポロジをどのように最適化するかについて前記ＭＣＯに命令するユニキャスト・ルーティング命令を受信するステップと、
    前記ＤＩＡからの前記ルーティング命令にしたがって、更新された現行ルーティング・トポロジに対して次のホップを選択し直すステップと
    を含む、方法。
11. 請求項１０記載の方法であって、更に、
    前記更新されたローカル状態情報が、直前に送信されたローカル状態情報から著しい変化があることに応答して、前記ＭＣＯから前記ＤＩＡに、更新されたローカル状態情報を送信するステップを含む、方法。
12. 請求項１０記載の方法において、前記ローカル状態情報が、ローカル・リンクのコスト、ローカル・リンクの信頼性、ローカル・リンクの遅延、ローカル・リンクの期待送信回数（ＥＴＸ）、およびリンク・ベース受信信号強度指示（ＲＳＳＩ）の内少なくとも１つを含む、方法。
13. コンピュータ・ネットワークにおいて通信するための１つ以上のネットワーク・インターフェースと、
    前記ネットワーク・インターフェースに結合され１つ以上のプロセスを実行するように構成されたプロセッサと、
    前記プロセッサによって実行可能なプロセスを格納するように構成されたメモリと
    を含む装置であって、前記プロセスが、実行されると、
    コンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）と共に、自己最適化を全く行わずに現行ルーティング・トポロジの構築に関与し、前記現行ルーティング・トポロジの初期インスタンスが、ループ防止を有するものの、目的関数を有さず、ローカル・リペアのためのメカニズムを有さず、告知伝搬メッセージも有さず、
    分散型インテリジェンス・エージェント（ＤＩＡ）に、対応する近隣リストと前記装置に選択された次のホップとを含む、 前記現行ルーティング・トポロジについてのローカル状態情報を送信し、
    前記ＤＩＡから、前記現行ルーティング・トポロジをどのように最適化するかについて前記装置に命令するユニキャスト・ルーティング命令を受信し、
    前記ＤＩＡからの前記ルーティング命令にしたがって、更新された現行ルーティング・トポロジに対する次のホップを選択し直す
    ように動作可能である、装置。
14. コンピュータ・ネットワークにおける複数の最小限接続オブジェクト（ＭＣＯ）であって、当該ＭＣＯが、現行ルーティング・トポロジにおいてそれぞれの次のホップを、自己最適化を全く行わずに選択するように構成され、当該ＭＣＯが、更に、分散型インテリジェンス・エージェント（ＤＩＡ）に、対応する近隣リストと前記それぞれの選択された次のホップとを含むローカル状態情報を送信するように構成される、ＭＣＯと、
    前記選択された次のホップを組みあわせた結果である前記現行ルーティング・トポロジを、計算された最適ルーティング・トポロジと比較して分析し、前記現行ルーティング・トポロジを最適化するか否か決定し、更に、前記現行ルーティング・トポロジを最適化すべきであるという決定に応答して、どのように前記現行ルーティング・トポロジを最適化するかについて個々のＭＣＯに命令するために、１つ以上の個々のＭＣＯにユニキャスト・ルーティング命令を送信するように構成されたＤＩＡと
    を備えるシステムであって、
    前記個々のＭＣＯが、更に、前記ＤＩＡから前記ユニキャスト・ルーティング命令を受信し、前記ＤＩＡからの前記ルーティング命令にしたがって、更新された現行ルーティング・トポロジに対して次のホップを選択し直すように構成される、システム。
15. 請求項１４記載のシステムにおいて、前記ＤＩＡが、更に、
    前記ＤＩＡにおいて前記ＭＣＯから更新されたローカル状態情報を受信し、
    対応する更新された現行ルーティング・トポロジを分析し、
    前記更新された現行ルーティング・トポロジを更に最適化すべきであると決定したことに応答して、追加のユニキャスト・ルーティング命令を送信する
    ように構成される、システム。
16. 請求項１４記載のシステムにおいて、前記ＤＩＡが、更に、１つ以上の制約と、１つ以上の要求されるサービス・レベル・アグリーメント（ＳＬＡ）を満たすことの内少なくとも１つに基づいて、前記最適ルーティング・トポロジを計算するように構成される、システム。
17. 請求項１４記載のシステムにおいて、前記現行ルーティング・トポロジを最適化するか否かの決定が、前記現行ルーティング・トポロジと前記最適化されたルーティング・トポロジとの間における総合コスト差、前記現行ルーティング・トポロジと前記最適化されたルーティング・トポロジとの間における最大パス・コスト差、前記現行ルーティング・トポロジ内において１つ以上の要求されたサービス・レベル・アグリーメント（ＳＬＡ）を満たさないパス、および前記現行ルーティング・トポロジを最適化するために必要とされる変更の数で構成される群から選択される少なくとも１つの因子に基づく、システム。
18. 請求項１４記載のシステムにおいて、前記送信されるルーティング命令が、前記個々のＭＣＯそれぞれに対する新たな次のホップの選択を含む、システム。
19. 請求項１４記載のシステムにおいて、前記ローカル状態情報が、ローカル・リンクのコスト、ローカル・リンクの信頼性、ローカル・リンクの遅延、ローカル・リンクの期待送信回数（ＥＴＸ）、およびリンク・ベース受信信号強度指示（ＲＳＳＩ）の内少なくとも１つを含む、システム。
20. 請求項１４記載のシステムにおいて、前記ＭＣＯが、更に、
    自己最適化を全く行わずに現行ルーティング・トポロジの構築に関与するように構成され、前記現行ルーティング・トポロジの初期インスタンスが、ループ防止を有するものの、目的関数を有さず、ローカル・リペアのためのメカニズムを有さず、告知伝搬メッセージも有さない、システム。
21. 請求項１４記載のシステムにおいて、前記ＭＣＯが、更に、
    更新されたローカル状態情報が、直前に送信されたローカル状態情報から著しい変化があることに応答して、前記更新されたローカル状態情報を前記ＤＩＡに送信するように構成される、システム。

Images