特許 6596575 ネットワークにおけるリンクロスの処理のためのシステムおよび方法

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

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

(11)【特許番号】6596575

(24)【登録日】2019年10月4日

(45)【発行日】2019年10月23日

(54)【発明の名称】ネットワークにおけるリンクロスの処理のためのシステムおよび方法

(51)【国際特許分類】

   H04L 12/717 20130101AFI20191010BHJP

   H04L 12/707 20130101ALI20191010BHJP

【ＦＩ】

   H04L12/717

   H04L12/707

【請求項の数】17

【全頁数】17

(21)【出願番号】特願2018-507538(P2018-507538)

(86)(22)【出願日】2016年10月21日

(65)【公表番号】特表2018-531535(P2018-531535A)

(43)【公表日】2018年10月25日

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

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

(87)【国際公開日】20170511

【審査請求日】2018年4月23日

(31)【優先権主張番号】14/929,991

(32)【優先日】2015年11月2日

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

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】ジャヤラマン，アルンクマー

(72)【発明者】

【氏名】サムエル，ラジクマー

(72)【発明者】

【氏名】ゲルブマン，ピーター

(72)【発明者】

【氏名】ハート，マイケル・ジョン

【審査官】 大石 博見

(56)【参考文献】

【文献】 特開２０１２−０４９６７４（ＪＰ，Ａ）

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

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

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

【文献】 米国特許第０６３９２９８９（ＵＳ，Ｂ１）

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

Ｈ０４Ｌ １２／７１７

Ｈ０４Ｌ １２／７０７

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

【請求項1】

ネットワークを管理するためのシステムであって、
複数のプライマリリンクを介して相互接続された複数のネットワークノードと、
前記複数のネットワークノードと通信するコントローラとを備え、前記コントローラは１つ以上のプロセッサを含み、前記１つ以上のプロセッサは、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルを前記複数のネットワークノードに提供するように構成され、
前記複数のネットワークノードの各々は、
特定のリンクロスイベントが発生したと判断し、
前記イベントプロファイルに基づいて、前記特定のリンクロスイベントに関するルーティング変更を決定し、
前記決定したルーティング変更を実現するように構成され、
前記コントローラはさらに、
前記複数のネットワークノードから情報を受信し、
前記受信した情報に基づいて、故障する可能性が高い前記リンクの組み合わせに対応する前記イベントプロファイルをアップデートするように構成されている、システム。

【請求項2】

前記受信した情報は、リンク切断の可能性が高いリンクを識別し、
前記コントローラはさらに、前記識別したリンクが失われたというシナリオを補償する前記イベントプロファイルが無い場合は、前記識別したリンクが失われたというシナリオを補償する前記イベントプロファイルをさらに追加する、請求項１に記載のシステム。

【請求項3】

前記複数のネットワークノードは、前記複数のネットワークノード上のアプリケーションおよびＬ２分離制御経路のうちの少なくとも一方を通じてリンクロスイベントを相互に伝達する、請求項１または２に記載のシステム。

【請求項4】

前記リンクロスイベントを前記アプリケーションを通じて伝達することは、
前記複数のネットワークノードのうちの第１のノードによって、特殊なイーサタイプのフレームをブロードキャストすることと、
前記複数のネットワークノードのうちの第２のノードによって、前記イーサタイプを検出し、前記フレームを前記第２のノード上で実行中のアプリケーションに転送すること
とを含む、請求項３に記載のシステム。

【請求項5】

前記第２のノードは、前記フレームを再びブロードキャストするかどうかを判断するように構成され、前記判断は、前記フレームが１つ以上のインターフェースでまだ送信されていないことに基づいている、請求項４に記載のシステム。

【請求項6】

前記フレームを再びブロードキャストするかどうかの判断は、前記第２のノード上の前記アプリケーションによって前記フレーム内のクッキーを見ることを含む、請求項５に記載のシステム。

【請求項7】

ネットワークノード内のルーティング情報をアップデートする方法であって、
コントローラから、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルを受信するステップと、
１つ以上のプロセッサを用いて、特定のリンクロスイベントが発生したと判断するステップと、
前記１つ以上のプロセッサを用いて、前記イベントプロファイルに基づいて、前記特定のリンクロスイベントに関してルーティング変更を決定するステップと、
前記１つ以上のプロセッサを用いて、前記決定したルーティング変更を実現するステップと、
ネットワーク内の１つ以上のリンクの状態を示す情報を前記コントローラに提供するステップとを含み、
前記情報の提供に応じて、アップデートされた故障する可能性が高い前記リンクの組み合わせに対応するイベントプロファイルを前記コントローラから受信するステップを含む、方法。

【請求項8】

前記情報は、リンク切断の可能性が高いリンクを識別する、請求項７に記載の方法。

【請求項9】

特定のリンクロスイベントが発生したと判断するステップは、前記ネットワークノードに直接連結されたリンクの故障を検出するステップを含む、請求項７または８に記載の方法。

【請求項10】

特定のリンクロスイベントが発生したと判断するステップは、隣接ノードから前記リンクロスイベントの通知を受信するステップを含む、請求項７または８に記載の方法。

【請求項11】

前記ネットワークノードが以前に前記通知を他のノードに送信したかどうかを判断するステップと、
前記通知がまだ送信されていない場合、前記通知を再送信するステップとをさらに含む、請求項１０に記載の方法。

【請求項12】

前記ネットワークノードが以前に前記通知を送信したかどうかを判断するステップは、前記ネットワークノード上で実行中のアプリケーションによって、フレーム内のクッキーを見るステップを含む、請求項１１に記載の方法。

【請求項13】

前記ネットワークノード上で実行中のアプリケーションを通じてリンクロスイベントをネットワーク内の他のノードに対して伝達するステップをさらに含む、請求項７〜１２のいずれか１項に記載の方法。

【請求項14】

前記アプリケーションを通じて前記リンクロスイベントを伝達するステップは、前記他
のノードによって検出可能な特殊なイーサタイプのフレームをブロードキャストするステップを含む、請求項１３に記載の方法。

【請求項15】

１つ以上のルーティングテーブルを格納するメモリと、
前記メモリと通信する１つ以上のプロセッサとを備えるネットワークノードであって、前記１つ以上のプロセッサは、
コントローラから、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルを受信し、
特定のリンクロスイベントが発生したと判断し、
前記イベントプロファイルに基づいて、前記特定のリンクロスイベントに関するルーティング変更を決定し、
前記決定したルーティング変更を実現し、
ネットワーク内の１つ以上のリンクの状態を示す情報を前記コントローラに提供し、
前記情報の提供に応じて、アップデートされた故障する可能性が高い前記リンクの組み合わせに対応するイベントプロファイルを前記コントローラから受信するようにプログラムされている、ネットワークノード。

【請求項16】

特定のリンクロスイベントが発生したと判断することは、隣接ノードから前記リンクロスイベントの通知を受信することを含み、
前記ネットワークノードはさらに、
以前に前記通知を他のノードに対して送信したかどうかを判断し、
前記通知をまだ送信していない場合、前記通知を再送信するようにプログラムされている、請求項１５に記載のネットワークノード。

【請求項17】

前記ネットワークノードは１つ以上のアプリケーションを実行し、前記１つ以上のアプリケーションは、以前に前記通知が送信されたかどうかを判断し、前記通知を再送信する、請求項１６に記載のネットワークノード。

【発明の詳細な説明】

【技術分野】

【0001】

関連の出願の相互参照
本特許出願は、２０１５年１１月２日に出願された米国特許出願第１４／９２９，９９１号の継続出願であって、その開示が本明細書に引用により援用される。

【背景技術】

【0002】

発明の背景
クラウド管理されたmmWaveベースのポイントツーマルチポイントメッシュバックホールには、中央クラウドソフトウェア定義無線ネットワーク（Software Defined Wireless Network：ＳＤＷＮ）コントローラによって完全に調整されるべきmmWave送信および受信の集中型スケジューリングが必要である。さらに、ネットワーク内のノードにまたがるネットワークレベルルーティングの決定も、コントローラによって調整される。これは、管理されるmmWaveノードとＳＤＷＮクラウドコントローラとの間の信頼性が高い接続性を前提としている。しかしながら、mmWaveリンク技術はきわめて高い無線周波数で動作し、見通し内（line-of-sight：ＬＯＳ）無線経路を通常必要とする。これらのＬＯＳ無線経路は、よりロバストな非見通し内（non-line-of-sight：ＮＬＯＳ）無線経路において動作可能である、本質的に低周波数の従来の無線通信システムと比べて信頼性が低い場合がある。

【0003】

コントローラに対する通信の場合は帯域外メカニズムが存在しないという重要な仮定の下に、バックホール内のノード間のデータ経路ルーティングは、ノードからコントローラへの制御経路通信と同じリンク経路を使用する。コントローラ自体への通信に関してならびにルーティングおよびチャネルスケジューリングアップデートの管理に関してコントローラによって管理されるリンクを同時に使用すると、アクティブリンクのロスの間に問題が生じる。リンクロスの間、ノードは、コントローラに対する現在の構築されたネットワーク経路を失う。ローカルなまたは分散されたルーティングに戻るには、ネットワークにおいてループまたはブロードキャストストームを引き起こす危険を冒すことになる、または、ネットワーク管理オーバヘッドを生成する複雑なローカル分散アルゴリズムが必要になる可能性がある。

【0004】

ネットワークのなかには同様のユースケースに関してコントローラとの帯域外接続性を活用するものもあり、アクティブに管理されたリンクは、コントローラとの接続性に関して使用されない。これにより、通信経路に、管理されているリンクから信頼性が独立したコントローラが提供される。しかしながら、これには、管理されているノード上で実現されるべき付加的な接続性技術が必要になり、ハードウェア、ソフトウェア、および管理コストならびに複雑性オーバヘッドがプロダクトに追加される可能性がある。

【発明の概要】

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

【0005】

簡潔な要約
本開示は、リンクロス中にコントローラがトポロジに対するルーティングおよびスケジューリング変更を一元的に処理し続けることを可能にする、クラウド管理されたポイントツーマルチポイントmmWaveメッシュバックホールに適用可能なメカニズムを強調する。データ経路ルーティングおよびコントローラに対する制御経路通信のために使用されるアクティブリンクが切断されると、利用可能な代替リンクが使用される。これらのメカニズムは、mmWave物理層通信の高指向性に対応可能であり、それらには、たとえば、高利得で幅の狭いビームアンテナ、フェーズドアレイなどのダイナミックビームフォーミング技術が含まれる。

【0006】

本開示の一態様は、ネットワークを管理するためのシステムを提供する。システムは、複数のプライマリリンクを介して相互接続された複数のネットワークノードと、複数のネットワークノードと通信するコントローラとを備える。コントローラは、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルを複数のネットワークノードに提供するように構成された１つ以上のプロセッサを備える。複数のノードの各々は、特定のリンクロスイベントが発生したと判断し、イベントプロファイルに基づいて特定のリンクロスイベントに関するルーティング変更を決定し、決定したルーティング変更を実現するように構成されている。

【0007】

本開示の別の態様は、ネットワークノード内のルーティング情報をアップデートする方法を提供する。この方法は、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルをコントローラから受信することを含む。この方法はさらに、１つ以上のプロセッサを用いて特定のリンクロスイベントが発生したと判断することと、１つ以上のプロセッサを用いてイベントプロファイルに基づいて、特定のリンクロスイベントに関するルーティング変更を決定することと、１つ以上のプロセッサを用いて、決定したルーティング変更を実現することとを含む。

【0008】

本開示のさらに別の態様は、ネットワークノードを提供する。このネットワークノードは、１つ以上のルーティングテーブルを格納するメモリと、メモリと通信する１つ以上のプロセッサとを備える。１つ以上のプロセッサは、さまざまなリンクロスシナリオで実現されるべきルーティング変更を示すイベントプロファイルを、コントローラから受信するようにプログラムされている。１つ以上のプロセッサはさらに、特定のリンクロスが発生したと判断し、イベントプロファイルに基づいて、特定のリンクロスイベントに関してルーティング変更を決定し、決定したルーティング変更を実現するようにプログラムされている。

【図面の簡単な説明】

【0009】

【図1】本開示の態様に係るシステムの例を示す概略図である。

【図2】本開示の態様に係るコントローラの例を示すブロック図である。

【図3】本開示の態様に係るノードの例を示すブロック図である。

【図4】本開示の態様に係るイベントプロファイルの例を示す図である。

【図5】本開示の態様に係る方法の例を示すフロー図である。

【図6】本開示の態様に係る方法の別の例を示すフロー図である。

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

【0010】

詳細な説明
概要
本開示は、一般に、クラウド管理されたmmWaveベースのポイントツーマルチポイントメッシュバックホールなどの、ネットワークにおけるスケジューリングおよびルーティング決定の管理に関する。中央クラウドソフトウェア定義無線ネットワーク（Software Defined Wireless Network:ＳＤＷＮ）コントローラは、ネットワークに対するルーティングおよびスケジューリング変更を一元的に管理する。ネットワーク内の各ノードには、たとえばリンク故障または他の状況が原因であるリンクロスの場合に実現されるべき新しいルートを識別するイベントプロファイルが設けられる。特定のリンクまたはリンクの組合せが故障すると、故障したリンクに接続されているノード上で実行中のアプリケーションが、リンクダウン状態をブロードキャストし得る。加えて、ネットワーク内のノードは、それら自体のルーティングテーブルをアップデートして、イベントプロファイル内に設けられている新しいルーティングスキームを実現する。新しいルーティングスキームを実現しているノードは、ネットワーク内の付加的なノードが故障したリンクに直接接続されていないにもかかわらずこの変更によって影響を受けるこれらのノードを含み得る。

【0011】

ネットワークノードは、隣接ノードと通信するために、コントローラによってセットアップされた数ギガバイトの速度の無線通信デバイスを含み得る。コントローラは、集中型スケジューリングを全ての接続されたノードにプッシュして可能なリンクを構築する。リンクは、高指向性を有している。フェーズドアレイは、高指向性リンク技術の一例である。プライマリリンクは、コントローラによって選択される、コントローラトラフィックおよびノーマルユーザデータのルーティングを行なう経路を含む。リンクレベル無線リソーススケジューリングは、ネットワークレベルルーティング決定で調整されて、所与のノードが所望のピアとビームフォーミングされる。指向性フェーズドアレイを用いて、バックホールトポロジは代替（冗長）リンクを有することが予想される。ノードは、これらのリンクがビームフォーミングされたリンクを維持するように、これらのリンクにおける時間の一部のみを費やすと予想され、その第一の目的は、きわめて低い帯域幅制御トラフィックの交換である。これらの代替リンクは、プライマリリンクロス中にコントローラに可能な経路を提供する。しかしながら、プライマリリンクの故障時に少なくとも１つのアクティブな代替リンクが存在するべきである。また、リンクロスの際にトラフィックの復元における遅延を避けるために、待ち時間を可能な限り最短に保つべきである。

【0012】

ネットワークは、たとえば１００を超えるノードなど多くのノードを含み得る。そのため、リンク故障のすべての順列に関してスケジューリングおよびルートを決定する複雑な計算は、時間的制約がある中ではきわめて難しい場合がある。

【0013】

イベントプロファイルは、通常動作の場合および１つ以上のリンクが故障した場合のルーティングおよびスケジューリング命令を有する。このトポロジでは、すべてのスケジューリングおよびルーティング決定は、十分に同期されている必要がある。これに対応するために、ノードがリンクロスにどのように応答するべきかを示すプロファイルは、リンクロスのすべての入れ替え可能な可能性を有する。イベントプロファイルはたとえば、ルックアップテーブル、または可能なリンクロスイベントを提案されたノード応答と関連付ける他のデータ構造でもよい。

【0014】

また、コントローラは、定期的にプロファイルをアップデートする。アップデートは、あらゆるリンク変更イベントを補償し得る。プロファイルは、mmWaveノードがそれほどダイナミックではないチャネル状態を有する固定ノードであるということを利用して、アダプティブになるようにリアルタイムフィードバックに基づいて選択される。コントローラは、定期的なリンクアップデートを通じて、リンク切断の可能性が高いリンクについて学習し、それらの順列の場合のみにプロファイルアップデートを提供して、クラウドの実現の大半によって管理可能な計算上の複雑さを低下させる。

【0015】

プロファイルエントリにマッチングしないリンクロスの組合せの場合、ノードは、データフレームのいかなるさらなる転送も停止し、バッファリングモードになる。リンクロスブロードキャストは、最終的にコントローラネットワークに対して有線接続性を有するハブノードを介してコントローラに達し、コントローラは、新しいルートアップデートをプッシュすることによって応答する。新しいルートが構築されるまでネットワークルートが不安定な状態にあることを考慮すると、ハブノードは、コントローラによって新しいルートアップデートをブロードキャストをすると予想される。いくつかの実施態様では、ノードは、プロファイルにマッチングするリンクロスイベントについて一時的なバッファリング状態になり得、転送状態に移行する前にすべての隣接ノードに関してルートアップデートを保証する。

【0016】

なお、故障したリンクについて２つのノードが存在する。双方のノードは、プロファイルテーブル内に入力されている同じクッキーを任意で用いて、すべての利用可能なリンク上のリンクロスをブロードキャストし得る。新しいプロファイルがコントローラによってプッシュされる前に新たに選択されたプライマリリンクも故障すれば、ノードは、マッチングプロファイルなしでそのイベントをリンクロスとして処理するように選択し、新しいルートアップデートに関してコントローラにリンクロスイベントを、再びブロードキャストとして、可能であればすべての利用可能なリンクで送ってもよい。

【0017】

そのような状況は珍しいことが予想され、リンクロスイベントがコントローラに到達した後のアップデートでコントローラがターンアラウンドするまでは、そのような変更は一時的である。

【0018】

ルーティングに必要とされるプライマリリンクが故障したときに起こるように、故障したリンクを有するノードによって使用されるブロードキャストメカニズムおよびノード間通信メカニズムは、コントローラセットアップＳＤＮルーティングに依存しない。特定のリンクが故障すると、故障したリンクを有するノードが通知をブロードキャストする。この通知は、さまざまな伝搬方法のうちのいずれかを使用してブロードキャスト可能である。一例によると、ルーティングメカニズムは、任意にコントローラプロキシとして１つ以上のノードを使用して、ローソケット（raw socket）および特殊なイーサタイプを使用し得る。たとえば、故障したリンクを有するノードは、特殊なイーサタイプを有するフレームをブロードキャストする。イーサタイプを検出しそれをノード上で実行中のアプリケーションに転送するスイッチングエントリで、すべてのノードのセットアップが行なわれる。アプリケーションはそれをローソケットで受信し、基礎をなすネットワークは、ブロードキャストされたフレームの再分散を行なわない。受信ノードは、過去に構成された期間内にマッチングするクッキーのためにブロードキャストをまだ行っていない場合、すべての利用可能なインターフェース上のリンク故障を再送信するように選択可能である。アプリケーションは、ブロードキャストされたフレーム内の特定のクッキーを見て以前にフレームを転送したかどうかを識別し、再びそれを転送しようとする前に、トポロジ内にループが存在しないことを保証する。有線ネットワークによってコントローラに接続されている「ハブノード」は、付加的にブロードキャストされたフレームをコントローラに送り、それによって、コントローラは今後の決定を行なうことができる。

【0019】

別の例によると、標準層２／標準層３（Ｌ２／Ｌ３）ルーティングメカニズムを使用可能である。たとえば、制御トラフィックは、仮想ローカルエリアネットワーク（ＶＬＡＮ）内などにおいて、Ｌ２隔離され得る。さらに別のアプローチでは、待ち時間およびmmWave特性について最適化された標準Ｌ２／Ｌ３ルーティングアルゴリズムを変更する。一例として、最適化リンク状態ルーティング（Optimized Link State Routing:ＯＬＳＲ)アルゴリズムでは、必要とされるいかなる動作またはパラメータも、より速いルート収束について変更し得る。さらに、ブロードキャスト待ち時間も、制御された指向性mmWaveネットワークについて変更し得る。コントローラおよびノード間メッセージ通信メカニズムは、たとえば、特定のネットワークのシステム展開シナリオおよびルーティング特性に基づいて事前に決められ得る。

【0020】

各ノードは、ブロードキャストされたフレームを受信しそれを転送するかどうかを判断すると、それ自体のルーティングテーブルをイベントプロファイルに基づいてアップデートする。たとえば、所与のノードは、リンクの特定の組合せが故障したと示す、複数のブロードキャストされたフレームを受信し得る。所与のノードは、イベントプロファイルを調べ、当該故障したリンクの特定の組合せに対応する、所定の推奨された応答を識別する。所与のノードは、その後所定の推奨された応答に基づいて、それ自体のルーティングテーブルをアップデート可能である。ネットワーク内の他の各ノードも、同じ手続きを実行する。

【0021】

上記の技術は、コントローラに対する帯域外アクセスについてプロダクトが付加的なロバスト無線技術を必要としないため、必要とするプロダクトコストおよびパワーが低く、かつ、ルートの再構築に必要なローカルノード間通信としてのより良好な性能がコントローラ応答よりも待ち時間が短いと予想されるという点で、有利である。

【0022】

システムの例
図１は、クラウドコントローラ１１０と相互接続された複数のノード１５２〜１５８とを含むシステム１００の例を示す図である。数個のノードしか図示されていないが、非常に多くのノードが含まれ得ると理解するべきである。ノードは、リンク１８２を介してクラウドコントローラ１１０と相互接続され、複数のプライマリリンク１８４〜１８６および代替リンク１９２〜１９６を介して互いに相互接続されている。

【0023】

ネットワーク１１２は、ＳＤＷＮ、またはデータセンター、負荷が分散されたサーバファーム、相互接続された周辺機器のバックプレーン、マザーボード上の構成要素のシステムなどの、いかなる他のタイプのネットワークでもよい。ネットワーク１１２および間にあるノードは、インターネット、ワールドワイドウェブ、イントラネット、仮想プライベートネットワーク、広域ネットワーク、ローカルネットワーク、１つ以上の企業が所有する通信プロトコルを使用したプライベートネットワーク、イーサネット（登録商標）、ＷｉＦｉ（登録商標）（８０２．１１、８０２．１１ｂ、ｇ、ｎ、または他のそのような規格）、ＨＴＴＰ、および上述したもののさまざまな組合せを含むさまざまな構成およびプロトコルを備え得る。

【0024】

コントローラは、たとえば、ネットワークに対するルーティングおよびスケジューリング変更を一元的に管理する中央クラウドＳＤＷＮコントローラであり得る。コントローラは、集中型スケジューリングをすべての接続されたノードにプッシュして可能なリンクを構築する。また、コントローラは、ネットワーク内の各ノードに、リンクロスの場合に実現されるべき新しいルートを識別するイベントプロファイルを提供する。また、コントローラは、定期的にプロファイルをアップデートする。アップデートは、ダウンリンク、修復されたリンク、および欠陥の可能性が高いリンクなど、いかなるリンク変更イベントも補償し得る。プロファイルは、アダプティブになるようにリアルタイムフィードバックに基づいて選択される。

【0025】

ノード１５２〜１５８は、たとえば、隣接ノードと通信するためにコントローラによってセットアップされた数ギガバイトの速度の無線通信デバイスであり得る。ノード１５２〜１５８の各々は、他のノードとの通信に使用可能なアプリケーションを実行する。たとえば、ノード１５４は、特定のリンクまたはリンクの組合せの故障を識別する場合、当該故障をアプリケーションを通じてネットワーク内の他のノードにブロードキャストし得る。リンク１８４、１８６が依然としてアクティブであると仮定すると、ノード１５２および１５８上で実行中のアプリケーションは、ローソケットによってブロードキャストされた「リンクダウン」情報を受信する。受信ノード１５２、１５８は、以前に同じ「リンクダウン」情報をブロードキャストしたかどうかを判断し、ブロードキャストしていない場合、ノード１５２、１５８は、当該「リンクダウン」情報を他の接続されたノードにブロードキャストする。

【0026】

コントローラ１１０に接続されているノード１５２は、ハブノードとして機能する。上述の例を続けると、ノード１５２が「リンクダウン」情報を受信すると、コントローラ１１０にもこの情報を転送して、コントローラ１１０が今後のルーティング決定を行なえるようにする。

【0027】

ネットワーク内のノードは、それら自体のルーティングテーブルをアップデートして、イベントプロファイルに設けられた新しいルーティングスキームを実現する。たとえば、それら自体に接続された１つ以上のリンクがダウンしたと検出することによって、または接続されたノードによってブロードキャストされた「リンクダウン」情報を受信することによってリンクダウンイベントを識別すると、ノードは、識別したリンクダウンイベントをどのように処理するかについての命令に関するイベントプロファイルを参照し得る。イベントプロファイルは、ノードが１つ以上の経路をイベントプロファイルにおいて識別された１つ以上の新しい経路で置換えるべきだと示し得る。新しいルーティングスキームを実現するノードは、この変更によって影響を受けたネットワーク内の付加的なノードを、これらの付加的なノードが故障リンクに直接接続されていないにもかかわらず、含み得る。たとえば、リンク１８４が故障したと示す「リンクダウン」情報をノード１５６が受信した場合、ノード１５６は、イベントプロファイルを調べ、それに応じてそのルーティングテーブルをアップデートしてもよい。

【0028】

プライマリリンク１８４〜１８６は、フェーズドアレイなどのmmWave物理層通信に関する高指向性リンクでもよい。プライマリリンク１８４〜１８６は、コントローラ１１０によって選択された、コントローラトラフィックおよびノーマルユーザデータをルーティングする経路を含む。リンクレベル無線リソーススケジューリングは、ネットワークレベルルーティング決定に合わせて調整されて、所与のノードは所望のピアとビームフォーミングされる。指向性フェーズドアレイでは、バックホールトポロジは代替（冗長）リンクを有すると予想される。ノードは、ビームフォーミングされたリンクを維持するようにこれらのリンクにおいて一部の時間のみを費やすと予想され、その第一の目的は、きわめて低い帯域幅制御トラフィックの交換である。

【0029】

代替リンク１９２〜１９６は、プライマリリンクロス中にコントローラに可能な経路を提供する。リンクがプライマリリンクとみなされるかまたは代替リンクとみなされるかは、特定のノードまたは経路に関係がある場合がある。たとえば、ノード１５２からノード１５４へのプライマリ経路はプライマリリンク１８４を含み得る一方で、代替経路は代替リンク１９２、１９４を含み得る。プライマリリンク故障の時に少なくとも１つのアクティブな代替リンクが存在するべきである。また、リンクロスにおけるトラフィックの復元の際の遅延を避けるために、待ち時間を可能な限り最短に保つべきである。

【0030】

一例によると、ノード１５４は、プライマリリンク１８６の故障を検出可能である。ノード１５４によって使用されるノード間通信メカニズムは、いかなる特定のルーティングにも依存しない。そうではなく、故障リンクを有するノード１５４は、特殊なイーサタイプを有するフレームをブロードキャストする。ノード１５２〜１５８はすべて、イーサタイプを検出しノード上で実行中のアプリケーションにそれを転送するスイッチングエントリでセットアップされる。したがって、ノード１５２、１５６、１５８上で実行中のアプリケーションは、ローソケットでブロードキャストされたフレームを受信し、基礎をなすネットワークはブロードキャストされたフレームを再分配しない。ノード１５２、１５６、１５８の各々の上で実行中のアプリケーションは、ブロードキャストされたフレーム内の特定のクッキーを見て、以前にフレームを転送したかどうかを識別する。受信ノード１５２、１５６、１５８上のアプリケーションのいずれかが以前にフレームを転送していない場合、そのアプリケーションは、すべての利用可能なインターフェースでフレームを再送信する。

【0031】

故障したプライマリリンク１８６もノード１５２に連結されているので、ノード１５２は、ノード１５４と同時にすべての利用可能なリンク上のリンクロスの検出およびブロードキャストを行ない得る。いくつかの例では、ノード１５２によるブロードキャストは、ノード１５４によるブロードキャストと同じクッキーを含み得る。

【0032】

上記の例を続けると、各受信ノード１５２、１５６、１５８は、イベントプロファイルに基づいてそれ自体のルーティングテーブルをアップデートする。たとえば、ノード１５６は、各々が異なる故障リンクを識別する複数のブロードキャストされたフレームを受信し得る。まとめると、複数のブロードキャストされたフレームは、故障したリンクの特定の組合せを示す。いくつかの例では、ノード１５６は、１つ以上のフレームを収集し、故障したリンクの組合せに対応するルーティングアップデートに関するイベントプロファイルを調べる。他の例では、ノード１５６は、受信された各個別の通知に関するイベントプロファイルを調べる。どちらの場合でも、ノード１５６はその後、イベントプロファイル内の所定の推奨された応答に基づいてそれ自体のルーティングテーブルをアップデート可能である。ネットワーク内の他のノード１５２、１５８も、同じ手続きを行なう。いくつかの例では、ノード１５２、１５６、１５８は、ブロードキャストされたフレームを再送信しつつ転送状態に移行する前に一時的な干渉状態になり得る。

【0033】

いくつかの例では、リンクロスの組合せはプロファイルエントリにマッチングしない場合がある。このイベントでは、ノード１５２〜１５８は、データフレームのいかなるさらなる転送も中止可能であり、干渉モードになり得る。リンクロスブロードキャストは、コントローラネットワークに対する優先接続性を有するハブノード１２０を介して、たとえばリンク１８２を介して、最終的にコントローラ１１０に到達する。それに応じて、コントローラ１１０は、新しいルートアップデートをプッシュする。ハブノード１５２は、新しいルートアップデートをブロードキャストする。

【0034】

新たに選択されたプライマリリンクも、新しいプロファイルがコントローラによってプッシュされる前に故障する可能性がある。この場合、ノードは、そのイベントをマッチングプロファイルを有さないリンクロスとして処理するように選択可能である。したがって、ノードは、新しいルートアップデートに関してコントローラにリンクロスイベントを、たとえば、すべての利用可能なリンクでブロードキャストされるように送ることができる。

【0035】

図２は、コントローラ１１０をより詳細に示す。コントローラ１１０は、いかなるタイプの仮想化もしくは非仮想化コンピューティングデバイス、またはネットワークで通信可能なコンピューティングデバイスのシステムでもよい。コントローラ１１０は、１つ以上のプロセッサ１４０と、メモリ１３０と、汎用コンピューティングデバイスに典型的に存在する他の構成要素とを含み得る。メモリ１３０は、１つ以上のプロセッサ１４０によって実行可能な命令１３８を含む、１つ以上のプロセッサ１４０によってアクセス可能な情報を格納可能である。

【0036】

メモリ１３０も、プロセッサ１４０によって検索、操作、または格納可能なデータ１３４を含み得る。メモリは、プロセッサによってアクセス可能な情報を格納可能ないかなる非一時的なタイプ、たとえば、ハードドライブ、メモリカード、ＲＡＭ、ＤＶＤ、書き込み可能なタイプなどでもよい。

【0037】

命令１３８は、１つ以上のプロセッサによって直接実行すべき命令のいかなるセット、たとえばマシンコード、または間接的に実行すべき命令のいかなるセット、たとえばスクリプトであり得る。その点に関して、「命令」、「アプリケーション」、「ステップ」および「プログラム」という用語は、ここでは同じ意味で使用可能である。命令は、プロセッサによる直接的な処理に関するオブジェクトコードフォーマットで、または、オンデマンドで解釈される、もしくは事前にコンパイルされるスクリプトまたは独立したソースコードモジュールの集合を含むいかなる他のコンピューティングデバイス言語でも格納可能である。命令の機能、方法およびルーチンは、以下でより詳細に説明される。

【0038】

データ１３４は、命令１３８に従って１つ以上のプロセッサ１４０によって検索、格納、または変更可能である。一例では、データ１３４は、ノード１５２〜１５８に提供される１つ以上のイベントプロファイル１３６を含み得る。イベントプロファイル１３６は、リンク故障の際にすべてのノードに関するルーティング命令を提供するマスターイベントプロファイルであり得る。別の例では、イベントプロファイル１３６は、多くのイベントプロファイル、たとえばネットワーク内の各ノード固有の１つのプロファイルを含み得る。

【0039】

命令１３８に従って、コントローラ１１０は、ネットワーク内のノードにイベントプロファイル１３６を提供し得る。コントローラ１１０はさらに、ノードから情報を、たとえば、ダウンしているリンクまたは切断の可能性のあるリンクを識別する情報を受信し得る。コントローラ１１０は、この情報を使用してイベントプロファイルをアップデート可能である。アップデートされたイベントプロファイルは、再びノードに提供される。

【0040】

ここで説明される主題はいかなる特定のデータ構造によっても制限されないが、データ１３４は、内部メモリまたは外部メモリ、コンピュータレジスタ、関係データベースに多くの異なるフィールドおよびレコードを有するテーブル、またはＸＭＬドキュメントとして保存可能である。また、データ１３４は、２進値、ＡＳＣＩＩまたはＵｎｉｃｏｄｅなどのコンピューティングデバイスが読取り可能ないかなるフォーマットでもフォーマット可能であるが、これらに限定されない。さらに、データは、関連情報の識別に十分ないかなる情報、たとえば、数、説明テキスト、プロプライエタリコード、ポインタ、他のネットワーク位置などの他のメモリに格納されたデータについての記載、または該当するデータを計算するために関数によって使用される情報を含み得る。

【0041】

１つ以上のプロセッサ１４０は、市販のＣＰＵなどのいかなる従来のプロセッサでもあり得る。代替的に、プロセッサは、特定用途向け集積回路（「ＡＳＩＣ」）または他のハードウェアベースのプロセッサなどの専用の構成要素であり得る。必要ではないが、サーバ１３０は、特定のコンピューティングプロセスを行なうために専門ハードウェア構成要素を含み得る。

【0042】

図２は、同じブロック内のコンピューティングデバイス１１０のプロセッサ、メモリ、および他の要素を機能的に示すが、プロセッサ、コンピュータ、コンピューティングデバイス、またはメモリは、実際には、同じ物理的ハウジング内にあってもなくてもよい複数のプロセッサ、コンピュータ、コンピューティングデバイス、またはメモリを含み得る。たとえば、メモリは、コンピューティングデバイス１１０のハウジングとは異なるハウジング内に位置するハードドライブまたは他の格納媒体であり得る。したがって、プロセッサ、コンピュータ、コンピューティングデバイス、またはメモリについての記載は、並列に動作してもしなくてもよいプロセッサ、コンピュータ、コンピューティングデバイス、またはメモリの集合についての言及を含むと理解されよう。たとえば、コンピューティングデバイス１１０は、負荷が分散されたサーバファーム、分散システムなどとして動作するサーバコンピューティングデバイスを含み得る。またさらに、以下で説明される機能のいくつかは１つのプロセッサを有する１つのコンピューティングデバイス上で発生すると示されているが、ここで説明される主題のさまざまな側面は、複数のコンピューティングデバイス、たとえば、ネットワークで情報を通信することによって実現可能である。

【0043】

図３は、ノード３５０の一例をより詳細に示す図である。いくつかの例では、ノード３５０は、コントローラ１１０と同様に構成されてもよく、上述のように、１つ以上のプロセッサ３８０およびメモリ３６０を有してもよく、メモリ３６０はデータ３６２および命令３６８を含む。いくつかの例では、ノード３５０は、サーバ、ルータ、または他のいかなるタイプのコンピューティングデバイスなどのネットワークデバイスでもよい。いくつかの例では、ノード３５０は、通常パーソナルコンピューティングデバイスと接続して使用される構成要素のすべてを有するパーソナルコンピューティングデバイス、たとえば、中央処理装置（ＣＰＵ）、データおよび命令を格納するメモリ（ＲＡＭおよび内部ハードドライブなど）、ディスプレイ（スクリーンを有するモニタ、タッチスクリーン、プロジェクタ、テレビ、または情報を表示するように動作可能な他のデバイスなど）、ユーザインプットデバイス（マウス、キーボード、タッチスクリーン、またはマイクロフォンなど）、およびこれらの要素を互いに接続するために使用される全ての構成要素でもよい。

【0044】

ノード３５０は、ノード３５０上で実行可能な１つ以上のアプリケーション３７０も含み得る。アプリケーション３７０は、さまざまなノード間の通信を容易にするといった、さまざまな機能を行なうように構成され得る。たとえば、アプリケーションは、すべてのインターフェースによってリスニングを行なうソケットを含み得る。アプリケーション３７０は、ブロードキャストされたフレームなどの通知を送るかどうかを判断し得る。アプリケーション３７０はメモリ３６０と離れていると図示されているが、メモリ３６０と統合可能であると理解されるべきである。

【0045】

いくつかの例では、ノード３５０は、ノード間通信に関する他の特徴を含み得る。たとえば、ノード３５０は、Ｌ２／Ｌ３ルーティング用のポートまたはインターフェースを備え得る。

【0046】

ノード３５０は、イベントプロファイル３６４およびルーティングテーブル３６６などのデータ３６２を格納し得る。イベントプロファイル３６４は、リンク故障の際にノード３５０に情報を提供するコントローラ１１０（図２）によってプッシュされるテーブルまたは他のデータ構造でもよい。ノード３５０上に格納されたイベントプロファイル３６４は、図２のイベントプロファイル１３６と同じでもよい。他の例では、イベントプロファイル３６４はノード３５０に特有でもよい。ルーティングテーブル３６６は、ノード３５０およびコントローラ１１０の少なくとも一方によってアップデート可能ないかなるタイプのルーティングテーブルでもよい。

【0047】

ノード３５０上でプログラムされた命令３６８は、ノード３５０に特定のリンクダウンイベントの発生を識別させる。この識別は、隣接ノードからの通知の検出、受信、またはいかなる他の種類の技術を含み得る。ノード３５０は、以前にリンクダウンイベントを処理したかどうかを判断し、処理していない場合、ネットワーク内の他のノードにイベントを伝達する。上述したように、この判断およびそれに続く伝達は、アプリケーション３７０によって行なうことが可能である。

【0048】

ノード３５０はさらに、イベントプロファイル３６４に基づいて、特定のリンクロスイベントに対応するルーティング変更を決定し得る。したがって、ノード３５０は、所定のルーティング変更に基づいてルーティングテーブル３６６をアップデートする。

【0049】

図４は、イベントプロファイル４００の例を示す図である。この例では、イベントプロファイル４００は、複数の列４１０および複数の行４３０を含むテーブルである。各行４３０の第１の列４１２は、特定のリンクロスイベントを示し得る。たとえば、各セルは、「リンク１」がダウンしている、「リンク１」および「リンク３」がダウンしている、といったダウンリンクの多くの可能な組合せのうちの１つを示し得る。いくつかの組合せのみが示されているが、多くの順列を含むことが可能である。たとえば、何百または何千のノードを含む大規模ネットワークの場合、イベントプロファイル４００は、何千ものまたはそれ以上の可能なリンクロスイベントを含み得る。

【0050】

第１のリンクロスイベント列４１２内の各エントリに対応するのは、特定のノードに関して指定された列内のエントリである。たとえば、列４１４はノードＡによってとられるべきアクションを識別可能であり、列４１６はノードＢによってとられるべきアクションを識別可能であり、列４１８はノードｎによってとられるべきアクションを識別可能である。これらのアクションは、特定のノードのルーティングテーブルをアップデートするための命令を含み得る。たとえば、リンク１、５、および７がダウンしていることに対応するセル４３５でのリンクロスイベントの場合、ノードＢは、ルーティングテーブルのうちの１つ以上における１つ以上のエントリを変更するように命令され得る。

【0051】

イベントプロファイルの例がテーブルとして図４で示されているが、他のデータ構造も使用可能である。

【0052】

方法の例
前述の説明に加えて、本開示に係る方法についてここで説明する。方法の動作は特定の順序で説明されるが、動作の順序は変更可能であると理解されるべきである。いくつかの動作は、同時に行なうことができる。さらに、動作は追加または省略可能である。

【0053】

図５は、ネットワークにおけるルーティングおよびアップデートを制御する方法５００の例を示す図である。ブロック５１０で、コントローラは、ネットワーク内のノードにイベントプロファイルを提供し得る。たとえば、コントローラは、ネットワーク内の各ノードに、多数の考えられるリンク故障の組合せの際にさまざまなノードによってとられるべきアクションを示すマスターイベントプロファイルを提供する。

【0054】

ブロック５２０で、コントローラは、ノードのうちの１つ以上から情報を受信する。たとえば、さまざまなノードからの情報は、ハブノードを通じてコントローラに渡すことが可能である。情報は、１つ以上のリンクの状態を示し得る。たとえば、状態は、リンクをダウンしているまたは故障する可能性があると識別可能である。リンクは、たとえば、誤り率が高いまたは信号強度が低いなどといった現在のメトリクスに基づいて、故障する可能性があると判断可能である。他の例では、コントローラによって統計的分析に基づいて判断可能である。たとえば、コントローラは、リンクの履歴を見て影響を受けやすいリンクを決定し、そのようなリンクが影響を受けにくくなるように故障閾値を適応的に変更可能である。

【0055】

ブロック５３０で、コントローラは、受信した情報に基づいてイベントプロファイルをアップデートする。たとえば、受信した情報は集約され、一括して、故障する可能性のあるリンクの組合せを識別可能である。当該組合せがイベントプロファイルにまだリストアップされていない場合、コントローラは、当該可能性のあるリンクロスイベントについてノードに関してルーティング変更を追加可能である。コントローラはさらに、アップデートされたイベントプロファイルをノードにプッシュ可能である。

【0056】

図６は、ルーティングトポロジをアップデートする方法６００の例を示す図である。この方法は、以下ではネットワーク内の所与のノードの視点から説明される。しかしながら、ネットワーク内の各ノードは、方法６００を実行するようにプログラム可能である。

【0057】

ブロック６１０で、ノードは、リンクロスイベントの発生を識別する。この識別は、１つ以上の接続されたリンクがダウンしたと検出すること、または、コントローラおよび別のノードの少なくとも一方から通知を受信することを含み得る。たとえば、ノードは、それ自体の上で実行中のアプリケーションを通じて、アクティブなリンクを介して依然として接続している隣接ノードから通知を受信可能である。リンクロスイベントは、ネットワーク内の１つまたは複数のリンクの故障または非活性化を含み得る。複雑なネットワークでは、ネットワークの異なるノードにわたるリンクの組合せが、所与の時間にダウンする可能性がある。

【0058】

ブロック６２０で、ノードは、以前にリンクロスイベントをネットワーク内の他のノードに伝達したかどうかを判断する。たとえば、所与のノード上のアプリケーションは、別のノードから受信されたフレーム内の特定のクッキーを見てもよい。この特定のクッキーは、所与のノードが以前にフレームを転送したかどうかを示す。他の例では、ノードは、以前の送信イベントのログを調べてもよい。

【0059】

ノードが以前にリンクロスイベントの通知を送信したと判断すると、ブロック６２５で、ノードは、ルーティングおよびコントローラへの情報の送信を継続することが可能である。そのような情報は、図５を参照して説明されたように、イベントプロファイルをアップデートするためにコントローラによって使用可能である。

【0060】

ノードが以前にリンクロスイベントの通知を送信していない場合、ブロック６３０で、ノードは１つ以上の隣接ノードに通知を送る。たとえば、ノード上で実行中のアプリケーションは、受信したフレームをすべてのインターフェース上でブロードキャスト可能である。

【0061】

ブロック６４０で、ノードは、特定のリンクロスイベントに関してルーティング変更を決定する。ルーティング変更の決定は、イベントプロファイルを調べてリンクロスイベントに対応する所定のアクションを識別することを含み得る。いくつかの例では、ノードは、リンクロスイベントの複数の通知を受信可能である。したがって、ノードは、故障したリンクの組合せに関して適切なアップデートを決定可能である。

【0062】

ブロック６５０で、ノードは、決定したルーティング変更を実現する。たとえば、ノードは、ルーティング／転送テーブルにおける１つ以上のエントリを変更可能である。その後、方法６００は、ノードが新しいリンクロスイベントに関してルーティングおよびモニタリングを継続するブロック６２５に戻る。

【0063】

上述のシステムおよび方法は、コントローラへの帯域外アクセスに関する、付加的なロバスト無線技術を用いずに動作可能である。その結果、コストの大幅な削減および電力の節約が実現される。さらに、ルートの再構築に必要なローカルなノード間通信がコントローラ応答よりも待ち時間が少ないと予想されるため、性能が拡張される。

【0064】

特許請求の範囲によって規定される主題の範囲から逸脱することなく上述した特徴のこれらの変形および組合せならびに他の変形および組合せを利用することができるため、実施形態の上述の説明は、特許請求の範囲によって規定される主題を限定するものではなく、その例示として理解すべきである。一例として、上記の動作は、上述した正確な順序で実行される必要はない。むしろ、さまざまなステップは、異なる順序でまたは同時に処理することができる。たとえば、リンク故障の発生を検出し、リンク故障が以前にノードによって処理されていなかったと判断するノードは、他のノードに対するリンク故障の通知のブロードキャストに先立ってルーティングテーブルをアップデート可能である。別段の記載がない限り、ステップを省略することもできる。さらに、本明細書に記載された実施例、ならびに「たとえば」および「含む」などの表現は、特許請求の範囲の主題を特定の実施例に限定するものとして解釈するべきではなく、むしろ、これらの実施例は、多くの可能な実施形態の一部を例示することを意図している。さらに、異なる図面において、同様の参照番号は、同一または類似の要素を指すことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】