(57)【要約】  送信機に結合されたプロセッサを有するリモートコントローラによってネットワーク要素を制御する方法であって、プロセッサが、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングすることと、送信機が、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードすることであって、サブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む、ことと、プロセッサが、遷移のサブセットにない他の遷移をプロセッサによってリモート制御することとを含む、方法。
2020502880.tif 000002
【特許請求の範囲】
【請求項１】
送信機に結合されたプロセッサを有するリモートコントローラによってネットワーク要素を制御する方法であって、
前記プロセッサが、前記ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングすることと、
前記送信機が、前記遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードすることであって、前記サブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む、ことと、
前記プロセッサが、前記遷移のサブセットにない他の遷移をリモート制御することとを含む、
方法。
【請求項２】
前記遷移のサブセット中の遷移のうちの１つを実行する指定順序で取られる複数の動作を含む少なくとも１つのレシピを準備することと、
前記少なくとも１つのレシピを前記ネットワーク要素に送信することとを含む、
請求項１に記載の方法。
【請求項３】
前記ネットワーク要素が、前記遷移のサブセット中の遷移のうちの１つを実行する理由の決定に応じて、前記遷移のサブセット中の遷移のうちの１つに関連するレシピ中の動作を実行する命令を、前記ネットワーク要素に送信することをさらに含む、
請求項２に記載の方法。
【請求項４】
前記遷移のサブセット中の遷移のうちの１つに関連する前記レシピ中の動作を実行する際に、前記ネットワーク要素によって使用される少なくとも１つのイベント条件動作（ＥＣＡ）ルールおよび少なくとも１つの有限状態マシン（ＦＳＭ）ルールを前記ネットワーク要素に送信することをさらに含む、
請求項３に記載の方法。
【請求項５】
送信コンポーネントと、
命令を含む非一時的なメモリと、
前記送信コンポーネントおよび前記メモリと通信する１つ以上のプロセッサであって、
ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化する命令を実行し、
前記送信コンポーネントは、前記遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするように構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含み、
前記１つ以上のプロセッサは、遷移のサブセット中にない他の遷移をリモート制御するように構成される、
リモートコントローラ。
【請求項６】
前記リモートコントローラは、前記遷移のサブセット中の遷移のうちの１つを実行する指定順序で取る複数の動作を含む少なくとも１つのレシピを準備し、前記少なくとも１つのレシピを前記ネットワーク要素に送信する、
請求項５に記載のリモートコントローラ。
【請求項７】
前記ネットワーク要素が、前記遷移のサブセット中の遷移のうちの１つを実行する理由の決定に応じて、前記リモートコントローラは、前記遷移のサブセット中の遷移のうちの１つに関連するレシピ中の動作を実行する命令を、前記ネットワーク要素に送信する、
請求項６に記載のリモートコントローラ。
【請求項８】
前記リモートコントローラは、前記遷移のサブセット中の遷移のうちの１つに関連する前記レシピ中の動作を実行する際に、前記ネットワーク要素によって使用される少なくとも１つのイベント条件動作（ＥＣＡ）ルールおよび少なくとも１つの有限状態マシン（ＦＳＭ）ルールを前記ネットワーク要素に送信する、
請求項７に記載のリモートコントローラ。
【請求項９】
ネットワーク要素をステートフル制御するシステムであって、
ネットワーク要素と、
ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化するように構成され、
前記遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするようにさらに構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含み、
前記遷移のサブセットにない他の遷移をプロセッサによってリモート制御するようさらに構成される、リモートコントローラとを有する、
システム。
【請求項１０】
前記リモートコントローラは、前記遷移のサブセット中の遷移のうちの１つを実行する指定順序で取る複数の動作を含む少なくとも１つのレシピを準備するようにさらに構成され、前記少なくとも１つのレシピを前記ネットワーク要素に送信するようにさらに構成される、
請求項９に記載のシステム。
【請求項１１】
前記ネットワーク要素が、前記遷移のサブセット中の遷移のうちの１つを実行する理由の決定に応じて、前記リモートコントローラは、前記遷移のサブセット中の遷移のうちの１つに関連するレシピ中の動作を実行する命令を、前記ネットワーク要素に送信するようにさらに構成される、
請求項１０に記載のシステム。
【請求項１２】
前記ネットワーク要素は、前記遷移のサブセット中の遷移のうちの１つに関連するレシピを受信し、前記リモートコントローラから少なくとも１つのイベント条件動作（ＥＣＡ）ルールおよび少なくとも１つの有限状態マシン（ＦＳＭ）ルールを受信するように構成されるメッセージルータを有する、
請求項１１に記載のシステム。
【請求項１３】
前記少なくとも１つのＥＣＡルールは、イベントタイプと、条件と、前記イベントタイプおよび条件が現在当てはまる場合に取られる動作とを含む、
請求項１２に記載のシステム。
【請求項１４】
前記少なくとも１つのＦＳＭルールは、前記ネットワーク要素中のリソースの識別子と、前記リソースの現在の状態にマッチされる第１の状態と、前記リソースのターゲット状態にマッチされる第２の状態と、前記リソースを前記第１の状態から前記第２の状態に移動するレシピの識別子とを含む、
請求項１２に記載のシステム。
【請求項１５】
前記メッセージルータは、さらに、受信したレシピを、前記ネットワーク要素のクックブックテーブルに記憶するクックブックエンジンに送信するように構成され、さらに、前記少なくとも１つのＥＣＡルールを、前記ネットワーク要素のＥＣＡテーブルに記憶するＥＣＡエンジンに送信するように構成され、さらに、前記少なくとも１つのＦＳＭルールを、前記ネットワーク要素のＦＳＭテーブルに記憶するＦＳＭエンジンに送信するように構成される、
請求項１２に記載のシステム。
【請求項１６】
前記ＥＣＡエンジンは、状態がモニターされる前記ネットワーク要素のエンティティを決定し、前記エンティティのコントローラに、前記エンティティをモニターし、前記エンティティの変化を前記ＥＣＡエンジンに通知するように命令する、
請求項１５に記載のシステム。
【請求項１７】
前記ＥＣＡエンジンは、前記エンティティのコントローラに、前記エンティティのすべての変化を前記ＥＣＡエンジンに通知するように命令する、
請求項１６に記載のシステム。
【請求項１８】
前記ＥＣＡエンジンは、前記ＥＣＡエンジンが通知されるために前記ＥＣＡエンジンがサブスクライブしているエンティティの変化を前記ＥＣＡエンジンに通知するように、前記エンティティのコントローラに命令する、
請求項１６に記載のシステム。
【請求項１９】
前記ＥＣＡエンジンは、前記エンティティの変化が通知されることに応じて、前記変化に関する情報で状態テーブルを更新し、前記変化に関連するルールが前記ＥＣＡテーブルに存在するか決定する、
請求項１６に記載のシステム。
【請求項２０】
前記変化に関するルールが前記ＥＣＡテーブルに存在する場合、前記ＥＣＡエンジンは、前記ルールに関連する条件が満たされるかを判定し、前記ルールに関連する条件が満たされると、前記ＥＣＡエンジンは、前記ルールに関連するレシピの識別子を前記ＦＳＭテーブルから読み出し、前記クックブックテーブルから識別子に関連するレシピを読み出し、前記識別子に関連するレシピに指定される動作を実行する、
請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願との相互参照］
本出願は、２０１６年１１月３日に出願された米国非仮特許出願第１５／３４２，９６２号、発明の名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｓｔａｔｅｆｕｌ  Ｃｏｎｔｒｏｌ  ｏｆ  Ｆｏｒｗａｒｄｉｎｇ  Ｅｌｅｍｅｎｔｓ」の優先権および利益を主張し、当該出願は本明細書に参照援用する。
［技術分野］
本発明は、概して、ソフトウェアデファインドネットワークおよびネットワーク機能仮想化の分野に関し、および転送要素のステートフル制御に関する。
【背景技術】
【０００２】
ソフトウェアデファインドネットワーク（ＳＤＮ）は、ネットワークの制御プレーンとユーザプレーンとを切り離す。ネットワーク機能仮想化は、制御プレーン機能とユーザプレーン機能をハードウェアから分離する。また、ネットワーク機能の仮想化により、電気通信クラウド内のどこでも、特定のサービスニーズに基づいてネットワーク機能を展開することができる。レガシーネットワークと比較して、ソフトウェアデファインドネットワークは、制御プレーンおよびユーザプレーンのより良いスケーリング、ネットワーク機能のより迅速な導入、より動的なネットワークカスタム化、およびリモート状態収集およびモニタリングを提供する。
【発明の概要】
【０００３】
本発明の一実施形態によると、送信機に結合されたプロセッサを有するリモートコントローラによってネットワーク要素を制御する方法は、前記プロセッサが、前記ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングすることと、前記送信機が、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードすることであって、前記サブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む、ことと、前記プロセッサが、前記遷移のサブセットにない他の遷移をリモート制御することとを含む。
【０００４】
本発明の他の一実施形態によると、リモートコントローラは、送信コンポーネントと、命令を含む非一時的なメモリと、前記送信コンポーネントおよび前記メモリと通信する１つ以上のプロセッサとを有する。１つ以上のプロセッサは、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化する命令を実行する。前記送信コンポーネントは、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするように構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む。前記１つ以上のプロセッサは、遷移のサブセット中にない他の遷移をリモート制御するように構成される。
【０００５】
本発明の他の一実施形態によると、ネットワーク要素のステートフル制御のためのシステムは、ネットワーク要素とリモートコントローラとを含む。リモートコントローラは、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化するように構成され、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするようにさらに構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含み、トランジションのサブセットにない他のトランジションをプロセッサによってリモート制御するようさらに構成される。
【０００６】
１つ以上の実施形態は、スイッチのローカル状態に基づく制御決定を、リモートコントローラからプログラム的な方法でスイッチ側にオフロードする。１つ以上の実施形態は、ポリシードリブンの分散制御プレーンをインプリメントする技術を提供する。制御論理は、主制御論理のクラウド化によるボトルネックを回避することにより、低レイテンシおよび高スループット性能を達成するために、高速制御を行うように、プログラム可能な方法で、トランスポートリソースにより近くに移動されてもよい。リモート・コントローラ・アプリケーションは依然としてエンドツーエンド・ポリシーを決定するが、ポリシー施行はローカル・レベルで実現される。複雑な制御プレーン決定論理がネットワークの任意の点でプログラムされ得るので、１つ以上の実施形態は、第３世代パートナーシッププロジェクト（３ＧＰＰ）標準におけるポリシー・課金ルール機能（ＰＣＲＦ）／ポリシー・課金実施機能（ＰＣＥＦ）アプローチよりも汎用性が高い。
【図面の簡単な説明】
【０００７】
本発明及びその優位性をより良く理解してもらうため、ここで、添付した図面を参照しつつ以下に説明する。
【図１】すべての制御機能がプッシュされたネットワーク要素を示す図である。
【図２】ステートフルネットワークプログラミングのための一実施形態による装置を示す図である。
【図３】イベント・条件・動作ルールを用いてネットワーク要素をプログラミングするための一実施形態による制御フローの図である。
【図４】一実施形態によるイベント・条件・動作テーブルを示す図である。
【図５】プログラマブルネットワーク要素にレシピをポストする一実施形態による制御フローを示す図である。
【図６】ポストされたレシピを含む一実施形態によるクックブックデータベースを示す図である。
【図７】有限状態マシンルールをポストする一実施形態による制御フローを示す図である。
【図８】ポストされた有限状態マシンルールを含む一実施形態による有限状態マシンテーブルを示す図である。
【図９】モニターされた状態変化に基づく一実施形態による制御フローを示す図である。
【図１０】ネットワーク要素の一実施形態によるステートフル制御方法のステップを示す図である。
【図１１】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１２】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１３】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１４】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１５】本明細書に説明する方法を実行する一実施形態による処理システムを示すブロック図である。
【図１６】電気通信ネットワークを介して信号を送受信するように構成されたトランシーバを示すブロック図である。
【発明を実施するための形態】
【０００８】
現在の好ましい実施形態の構造、製造および使用を以下に詳細に説明する。しかし、言うまでもなく、本発明は幅広い様々な状況で実施できる多くの応用可能な発明概念を提供するものである。本明細書で説明する実施形態は、本発明を生産し使用する方法の単なる例示であり、本発明の範囲を限定するものではない。
【０００９】
主要なワークロードがインターネットに束縛される移動ネットワークでは、いくつかの機能は、その機能がセッションレベル、フローレベルまたはパケットレベルの処理を提供するかに関わらず、少数の中央オフィスに集中されることがある。このように集中され得る機能には、認証、承認および会計（ＡＡＡ）、ポリシーエンフォースメント、サービス品質（ＱｏＳ）管理、セッション制御、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）アクセス、公衆インターネットアクセス、ディープパケット検査（ＤＰＩ）、およびファイアウォール機能などがある。ワークロードが進化し、ネットワークのエッジで新しいユースケースが現れるにつれて、この南北トラフィックパターンにより、東西トラフィック（すなわち、エッジ間通信サービス）およびエッジコンピューティングおよびストレージの形態における変化を見ることがある。すべてのセッション、ＵＥ、ネットワーク、およびトラフィックの状態を集中的に収集し、これらの状態に基づいてクローズドループでネットワーク要素を制御すると、スケーリング問題およびパフォーマンス低下をもたらす可能性がある。
【００１０】
図１は、すべての制御機能が制御プレーンオーケストレータ１２０からプッシュされたネットワーク要素１１０を示す。特に、制御機能は、ネットワーク要素１１０においてインスタンス化された複数の制御アプリケーション１３０にオフロードされている。制御アプリケーション１３０の各々は、１つ以上の転送パイプライン要素１４０を制御することができる。転送パイプライン要素１４０はプログラマブル転送パイプライン１５０の一部である。制御は、相互接続スイッチ／バス１６０および／またはコンテナ／モジュールマネージャ１７０によって媒介されてもよい。
【００１１】
全ての制御機能が図１のようにネットワーク要素１１０にオフロードされると、いくつかの問題が生じることがある。例えば、ネットワーク要素１１０はそのような場合に膨張することがある。さらに、複数の制御アプリケーション１３０が、同じ転送モジュールまたはパイプライン１５０をプログラムまたは構成するように動作する場合、競合をどう解決するかが不明であり得る。また、制御機能のポリシーをどう分離する方法も不明な場合がある。また、状態維持およびポリシー管理などの機能に関して、制御アプリケーション１３０にわたる繰り返しがあるかも知れない。また、制御機能の動的変更は困難な場合がある。例えば、少数のステートメントまたはポリシーのみを変更する必要がある場合でも、完全な新しい実行可能ロジック・セットをネットワーク要素１１０に移動する必要がある。そのような論理更新は、非効率であることに加えて、ステートフルでない可能性もある。
【００１２】
次世代のネットワークでは、異なるワークロードのニーズをレイテンシとスループットに関して対処し、一方、グローバルネットワークビューを持つ運用サポートシステム及びビジネスサポートシステム（ＯＳＳ／ＢＳＳ）の、エンドツーエンドのサービス要件を満たすというニーズを満たす必要があり得る。柔軟かつプログラム可能な方法でローカル状態を生成または集約する、ネットワーク要素に近い制御機能を展開することができる分散型および階層的制御プレーンは、ＯＳＳ／ＢＳＳニーズと性能ニーズの両方に対処することができる。本明細書に開示する実施形態は、このような分散型および階層的制御プレーンを可能にするソリューションを提供する。
【００１３】
一実施形態では、ネットワーク要素に対し軽量ステートフル制御機能を実行する装置および方法が提供される。装置は、２つの層から成り、１つの層は、１つ以上のリモート制御アプリケーションを備え、もう１つの層は、ＮＥローカルプログラマブルエンティティのための状態マシンをホストする制御エージェントと、レシピのクックブックと、状態マシンテーブルと、イベント条件動作（ＥＣＡ）テーブルと、テーブルによって指定される動作をロード、アンロード、及び実行する対応するエンジンとを有するネットワーク要素（ＮＥ）を備える。本明細書で使用される場合、用語「ネットワーク要素」または「ＮＥ」は、基地局、ユーザ装置（ＵＥ）、スイッチ、ゲートウェイ、または任意の同様なコンポーネントを指し得る。ネットワーク要素は、本明細書では、転送要素とも呼び得る。
【００１４】
ＮＥは、リモート制御可能であると仮定してもよい。ＮＥ上のエンティティを制御することができるリモート制御アプリケーションは、最初に、そのエンティティの所望の動作状態をモデリングし、次いで、得られた状態マシンをＮＥにプッシュすることができる。あるいは、プログラマブルエンティティは、ＮＥ上の制御エージェントによってすでにホストされたデフォルト状態マシンを有していてもよい。後者の場合、リモート制御アプリケーションは、エンティティに対して有限状態マシン（ＦＳＭ）を問い合わせることができる。各制御可能エンティティは、リモートコントローラによってＦＳＭとしてモデリングされてもよい。
【００１５】
あるエンティティの状態マシンがＮＥに記憶されると、リモート制御アプリケーションは、エンティティの状態をある状態から別の状態に変更する命令をＮＥの制御エージェントに送ることができる。各状態遷移は、ある順序でローカルに実行される一連の制御動作を伴う。このようにある順序で実行される制御動作のセットはレシピと呼ぶことができる。
【００１６】
現在、複数の命令は、制御アプリケーションによって直接送られてもよいが、このような手順は複数回の往復を結果としてもたらす可能性があり、その数は、順次的に完了すべき命令の数と共に増加する可能性がある。他方、開示の実施形態では、リモートコントローラは、１つのハイレベル命令でＮＥ上のエンティティをプログラムすることができる。ＮＥ上には複数のプログラマブルエンティティがあってもよく、各プログラマブルエンティティの複数のインスタンスがあってもよい。さらに、各エンティティは、多くの状態および状態遷移から構成されていてもよい。従って、ＮＥは、複数の状態マシンおよび複数のレシピをホストしていてもよい。レシピの集まりは、ＮＥのプログラマビリティのクックブックと呼ぶことができる。以下でより詳細に説明するように、ＮＥはまた、ＥＣＡベースのポリシーエンジンをホストしてもよい。
【００１７】
リモート制御アプリケーション（すなわち、コントローラ）は、あるＮＥ上のプログラマブルエンティティに問い合わせることができる。リモートコントローラはまた、１つ以上のイベント、１つ以上の条件、およびイベントが発生し、条件が保持される場合に実行される１つ以上の動作を画定することによって、ポリシーをプッシュしてもよい。動作は、あるレシピを実行する、または制御されるエンティティをある状態から他の状態に移動させる形式であってもよい。例えば、コントローラは、「イベントＸが発生し、条件Ｙが満たされた場合、レシピＺを実行する」という形式の命令をプッシュすることができる。イベントは、ＮＥ上のモニターされる１つ以上の状態（例えば、フローカウンタ、フローバッファ、またはリンクアップ／ダウンイベント）の変化に対応する。条件ステートメントは、１次元（例えば、バッファＡが空）であってもよく、または多次元（たとえば、フローＦ１に対してＢバイトが送信され、リンクＹが輻輳している）であってもよい。コントローラは、ＥＣＡ命令が送られる前、またはＥＣＡ命令が送られると同時に、レシピをプッシュすることができる。コントローラは、ＥＣＡルールを削除し、ＥＣＡルールを変更し、レシピを更新することができる。実施形態は、単純な命令または状態遷移命令が、レシピを特定するよりもむしろ、動作として画定することを可能にする。また、実施形態では、ＥＣＡルールを１回または繰り返し実行することも可能である。ＥＣＡベースのアプローチは、コントローラがローカル状態の変化に素早く反応することを可能にする。
【００１８】
図２は、制御アプリケーション２１２と通信することができる一実施形態によるＮＥ２１０の内部コンポーネントを示す。制御アプリケーション２１２またはリモートコントローラは、単一コンポーネントに存在する離散的エンティティであっても、または複数のコンポーネントにわたって分散されているエンティティであってもよいソフトウェアデファインドネットワークに基づく外部エンティティである。制御アプリケーション２１２は、ＮＥ２１０のメッセージルータ２１４に命令を送ることによってＮＥ２１０をプログラムする。メッセージルータ２１４は、制御アプリケーション２１２から来る命令を３つのエンジン、すなわちＥＣＡエンジン２１６、ＦＳＭエンジン２１８、およびクックブック（ＣＢ）エンジン２２０のうちの少なくとも１つに転送する。これらのエンジンの各々は、ポリシールールと、状態遷移ルールと、状態遷移要求および観測されたイベントに応答して実行される命令セットとを記憶する対応テーブル（すなわち、ＥＣＡテーブル２２２、ＦＳＭテーブル２２４、およびクックブック２２６）を有する。ＥＣＡエンジン２１６およびＦＳＭエンジン２１８は、エンティティコントローラ２２８（例えば、ＥＣ−１からＥＣ−ｋ）に対するローカル命令を呼び出し、エンティティコントローラ２２８は、１つ以上の制御エンティティ２３０（例えば、Ｅ−１１からＥ−１ｉ、Ｅ２からＥ−ｋ）をプログラム、制御、および／または観測する。制御されるエンティティ２３０の状態は、状態テーブル２３２に記憶されてもよい。
【００１９】
ＥＣＡエンジン２１６は、ＮＥ２１０によって観測、モニター、または測定されるイベントを指定するポリシールールと、満たされるべき条件ステートメントと、イベントが観測されたときに条件ステートメントが満たされた場合に取られるべき動作または一連の動作とを受け取ることができる。イベントは、一般的には、ローカル仮想リソース（例えば、仮想ポートまたはコンテナ）、物理リソース（例えば、三値コンテンツアドレス可能メモリ（ＴＣＡＭ）またはインターフェースカード）、または論理リソース（例えば、フローテーブル、パケットカウンタ、トンネル、またはパス）の状態変化に対応する。イベントは、２つ以上のリソースの状態変化が観測、モニター、または測定される複合イベントであってもよい。同様に、条件ステートメントは、２つ以上の条件が満たされる複合ステートメントであってもよい。
【００２０】
一実施形態では、ＥＣＡルールをＮＥにポストすることが、図３に示すフローチャート３００のステップに続く。制御アプリケーション３１０は、「ポストＥＣＡルール」メッセージ３２０または同様のメッセージを介して、１つ以上のＥＣＡルールをＮＥにポストする。メッセージルータ３３０は、ＥＣＡルールに対するＮＥの受信端である。メッセージルータ３３０は、「ＥＣＡルールをルーティング」メッセージ３４０または同様のメッセージを介してＥＣＡルールをＥＣＡエンジン３５０に転送する。ＥＣＡエンジン３５０は、「状態を観測」メッセージ３６０または同様のメッセージを介して、状態をモニターすべきＮＥ上のエンティティを抽出し、対応するエンティティコントローラ３７０に、エンティティをモニターし、エンティティの状態変化をＥＣＡエンジン３５０に渡すよう指示する。別の実施形態では、パブリッシュ／サブスクライブサブシステムまたはメッセージパッシングサブシステムがあり、すべてのイベントはエンティティコントローラ３７０によってブロードキャストされる。このような実施形態では、ＥＣＡエンジン３５０は、受信されたＥＣＡルールにリストされたイベントを聞くように、そのフィルタをプログラムすることができる。ＥＣＡエンジン３５０は、「ルールを保存」メッセージ３８０または同様のメッセージを介して、受信した各ＥＣＡルールをＥＣＡテーブル３９０に保存することができる。
【００２１】
図４は、各行が１つのＥＣＡルールに対応する一実施形態によるＥＣＡテーブル４００を示す。図４のＥＣＡテーブル４００は、図３のＥＣＡテーブル３９０と実質的に同様であってもよい。第１列４１０の項目は、２タプル＜ｒｅｓｏｕｒｃｅ  ＩＤ，  ｅｖｅｎｔ  ｎａｍｅ＞によってコード化されるイベントタイプを指定する。ｒｅｓｏｕｒｃｅ  ＩＤは、インターフェース、フローバッファ、またはフローテーブルなどのローカルリソースインスタンスのローカルで一意的な識別子に対応する。第２の列４２０内の項目は、ヌル、単純条件、または複合条件であり得る条件ステートメントに対応する。条件ステートメントは、１つ以上のリソースの観測可能なプロパティまたは状態に対する算術演算および論理演算を含むことができる。第３列４３０内の項目は、３つの形式のうちの１つを取り得る動作ステートメントに対応する。第１の形式では、動作ステートメントは、３つのパラメータ、すなわちローカルで一意的なリソース識別子、現在の状態、および次の状態を取る一般的な「移動」命令または同様の命令であってもよい。第２の形式では、動作ステートメントは、「実行」ステートメントまたは同様のステートメントであってもよく、パラメータは、ローカルで制御可能なエンティティ（例えば、フローテーブル、フローバッファ、メーター、カウンター、またはポート）上で実行可能な一連の個別命令であるレシピのリストとして提供される。第３の形式では、動作ステートメントはより単純な「実行」ステートメントであり、個別の命令をパラメータとして取る。
【００２２】
図５は、レシピをプログラマブルＮＥにポストするための一実施形態によるメッセージシーケンス５００を示す。メッセージルータ５３０は、制御アプリケーション５１０から「レシピをポスト」メッセージ５２０または同様のメッセージを受信すると、「レシピをルーティング」メッセージ５４０または同様のメッセージの一部として、受信したレシピをクックブックエンジン５５０に転送する。クックブックエンジン５５０は、「レシピを保存」メッセージ５６０または同様のメッセージを介してクックブックデータベース５７０にレシピをローカルで記憶する。
【００２３】
図６は、各行が一意的なレシピである、一実施形態によるクックブックデータベース６００を示す。図６のクックブックデータベース６００は、図５のクックブックデータベース５７０と実質的に同様であってもよい。第１列６１０の項目は、ローカルで一意的なレシピ識別子を指定する。第２列６２０の項目は、レシピに関連付けられ、ＮＥ上の特定の制御可能なエンティティ上で実行され得る命令のリストを指定する。
【００２４】
図７は、ＦＳＭルールをポストする一実施形態による制御フロー７００を示す。メッセージルータ７３０は、「ＦＳＭルールをポスト」メッセージ７２０または同様のメッセージを介して、制御アプリケーション７１０からＦＳＭルールのセットを受け取る。メッセージルータ７３０は、「ＦＳＭルールをルーティング」メッセージ７４０または同様のメッセージを介してそのルールをＦＳＭエンジン７５０にルーティングする。ＦＳＭエンジン７５０は、「ＦＳＭルールを保存」メッセージ７６０または同様のメッセージを介してルールをＦＳＭテーブル７７０に保存する。ＦＳＭルールは、ローカルで一意的なリソース識別子と、そのリソースの現在の状態にマッチされた第１の状態と、そのリソースのターゲット状態にマッチされた第２の状態と、識別されたリソースを第１の状態から第２の状態に移動するために実行されるレシピを指すレシピ識別子とを指定することができる。ＦＳＭルールが意味を持つためには、指定されたレシピＩＤを有するレシピをすでにクックブックに記憶してある必要があるかも知れない。
【００２５】
図８は、４つの列を含む一実施形態によるＦＳＭテーブル８００を示す。図８のＦＳＭテーブル８００は、図７のＦＳＭテーブル７７０と実質的に同様であってもよい。第１の列８１０は、ＮＥのローカルスコープにおいて一意的なリソース識別子をリストする。リソース識別子によって識別されるリソースは、いくつかの例では、図２の制御されたエンティティ２３０のうちの１つと同等であり得る。リソース識別子は、一般的には、ストリングタイプを有してもよいが、整数に基づく番号付けまたは命名を使用してもよい。第２の列８２０は、現在時間にリソースが存在し得る個別の状態をリストする現在の状態列である。全ての可能な状態が現在の状態列８２０に含まれる必要はない。すなわち、制御目的に使用されない状態を含める必要はない。第３の列８３０は、リモート制御アプリケーションがリソースの移動を要求することができるそのリソースの個別の状態をリストする次の状態列である。ここでも、コントローラがリソースを幾つかの可能な状態に移動しない場合、すべての可能な状態が次の状態列８３０に含まれる必要はない。これらの状態は、一般的には、ストリングタイプを有してもよいが、数字タイプを有してもよい。第４列８４０は、所与の行で指定された状態遷移に使用されるレシピを識別するレシピＩＤ列である。レシピＩＤは、一般的には、数字タイプを有してもよいが、ストリングタイプを有してもよい。タイプの慣習は、クックブックのタイプと整合性がとれる必要があるかもしれない。
【００２６】
ＦＳＭルール、ＥＣＡルールおよびレシピが、本明細書に開示されるように、ＦＳＭテーブル、ＥＣＡテーブルおよびクックブックに記憶されると、ＥＣＡエンジンは、イベントおよび条件に基づく動作を実行するため、それらのピースを所定の位置に有する。図９は、イベントおよび条件に基づく動作のための一実施形態による制御フロー９００を示す。１つ以上のエンティティコントローラ９１０は、それらのローカル・コントローラ・エンティティの状態変化を観測する。モニターされたエンティティの状態変化が検出された場合、検出エンティティコントローラ９１０は、ＥＣＡエンジン９２０に通知する。一実施形態では、エンティティコントローラ９１０は、ＥＣＡエンジン９２０に、それらの制御されたエンティティの全ての状態変化を通知する。別の実施形態では、ＥＣＡエンジン９２０は、一定の状態遷移の通知をサブスクライブし、従って、エンティティコントローラ９１０は、サブスクライブされたイベント（すなわち、状態遷移）のみをＥＣＡエンジン９２０に通知する。ＥＣＡエンジン９２０は、状態テーブル９３０を更新することにより、モニターされる状態を追跡し続ける。一実施形態では、ＥＣＡエンジン９２０は、制御されるエンティティの最後の状態のみを保持する。別の実施形態では、ＥＣＡエンジン９２０は、ｉ番目の制御エンティティの最後のＮｉ個の状態を追跡する。観測されたエンティティの状態が保存されると、ＥＣＡエンジン９２０は、ＥＣＡテーブル９４０に指定された関連ポリシールールが存在するかどうかをチェックする。マッチするポリシーが存在する場合、ＥＣＡエンジン９２０は、ＥＣＡテーブル９４０から、満たされるべき追加条件および実行される動作をロードする。状態テーブル９３０と、場合によっては他のローカルにキャッシュされたパラメータ値とを用いて、ＥＣＡエンジン９２０は、全ての条件が満たされるか否かを決定する。
【００２７】
全ての条件が満たされる場合、ＥＣＡエンジン９２０は、ＥＣＡルールで提供される動作のタイプに応じて、いくつかの方法のうちの１つで動作を実行することができる。ポリシールールの一部としてすでに記憶されている単純な命令セットの場合、ＥＣＡエンジン９２０は、動作がルールにリストされている順序で動作を実行する。動作がレシピのリストである場合、ＥＣＡエンジン９２０は、レシピＩＤを使用して、クックブック９５０から各レシピを順にロードし、ＥＣＡルールによって提示される順序で各レシピを実行する。レシピＩＤは、ＦＳＭテーブル９６０から取り出すことができる。レシピ内の各命令は、命令がレシピに列挙されている順序で実行される。動作が「移動」ステートメントまたは同様のステートメント（すなわち、現在の状態から次の状態にリソースを移動する）である場合、ＥＣＡエンジン９２０は、リソースの現在の状態が「移動」命令に指定された現在の状態と一致するかどうかを判定し、もしそうであれば、命令がＥＣＡルールに記載されている順序で、ポリシールールの「移動」命令の各々のレシピＩＤをロードする。各レシピは、レシピＩＤに基づいて、クックブック９５０からロードされ、ロードされたレシピ内の命令は、命令がクックブック９５０からロードされる順序で実行される。ＥＣＡルールで指定される動作は、上記のカテゴリの１つにのみ属しているか、動作タイプの組み合わせであってもよい。
【００２８】
図２ないし図９の同名のコンポーネントは、たとえそのコンポーネントが異なる参照番号によって参照されていても、実質的に互いに同様であり得る。
【００２９】
図１０ないし図１４は、ネットワーク要素のステートフル制御の一実施形態による方法１０００におけるステップを示す。本方法１０００は、状態マシンがモデリングされるステップ１０１０、状態遷移のレシピが準備されるステップ１１１０、レシピがポストされるステップ１２１０、ＦＳＭルールがポストされるステップ１３１０、ＥＣＡルールがポストされるステップ１４１０を含む。各ステップは後でより詳しく説明する。ステップは、必ずしも示されたシーケンスで実行される必要はなく、いくつかのステップは、他のステップと同時に実行されてもよい。
【００３０】
図１０は、状態マシンがモデリングされるステップ１０１０を示す。この例では、モデルは、第１の状態１０２０から第２の状態１０３０への遷移、第２の状態１０３０から第３の状態１０４０への遷移、第３の状態１０４０から第４の状態１０５０への遷移、第４の状態１０５０から第２の状態１０３０への遷移、および第３の状態１０４０から第１の状態１０２０への遷移を含む。
【００３１】
図１１は、状態遷移のためのレシピが準備されるステップ１１１０を示し、各レシピは、順次的に呼び出される命令のセットである。一実施形態では、レシピは、ネットワーク要素上でローカルに制御される遷移に対してのみ作成される。リモートコントローラによってリモートで制御される遷移のレシピは作成されない。リモートコントローラまたはいくつかの他のコンポーネントは、どの遷移がリモートコントローラによるリモート制御よりも、ネットワーク要素によるローカル制御により適しているかを決定することができる。
【００３２】
図１１の例では、第１の状態１０２０から第２の状態１０３０への遷移、第４の状態１０５０から第２の状態１０３０への遷移、および第３の状態１０４０から第１の状態１０２０への遷移は、ネットワーク要素にオフロードされる。従って、第１のレシピ１１２０が準備され、第１の状態１０２０から第２の状態１０３０に遷移するための命令を含む。第２のレシピ１１３０が準備され、第４の状態１０５０から第２の状態１０３０に遷移するための命令を含む。第３のレシピ１１４０が準備され、第３の状態１０４０から第１の状態１０２０に遷移するための命令を含む。第２の状態１０３０から第３の状態１０４０への遷移と、第３の状態１０４０から第４の状態１０５０への遷移とは、リモートコントローラによってリモート制御されるため、これらの遷移のためのレシピは作成されない。このようにして、プログラマブルネットワーク要素は、ネットワーク要素に記憶されたレシピによって部分的にローカルで制御され、リモートコントローラによって部分的にリモートで制御される。
【００３３】
図１０および１１の各状態１０２０ないし１０５０は、ＦＳＭテーブルの対応する行を有してもよい。どの現在状態からどの次状態に遷移が起こるかを示す有向矢印は、クックブックに記憶された１つのレシピのみに対応していてもよい。対照的に、異なる状態遷移は、同じレシピＩＤにマップされてもよく、従って同じレシピにマップされてもよい。同じリソース・タイプの異なるインスタンスが同じ状態マシンを共有してもよく、ＦＳＭテーブルに重複するエントリーが存在してはならない。対照的に、同じリソース・タイプの異なるインスタンスは、それらの状態遷移のために異なるレシピを利用することもできる。
【００３４】
図１２は、レシピがポストされるステップ１２１０を示す。すなわち、図１１において準備されたレシピは、そのレシピが適用されるネットワーク要素上のテーブル１２２０に記憶される。テーブル１２２０は、図６のクックブックデータベース６００と実質的に同様であってもよい。
【００３５】
図１３は、ＦＳＭルールがポストされるステップ１３１０を示す。すなわち、図７を参照して上に説明したように、１つ以上のＦＳＭルールが受信され、ＦＳＭテーブル１３２０に記憶される。ＦＳＭテーブル１３２０は、図８のＦＳＭテーブル８００と実質的に同様であってもよい。
【００３６】
図１４は、ＥＣＡルールがポストされるステップ１４１０を示す。すなわち、図３を参照して上に説明したように、１つ以上のＥＣＡルールが受信され、ＥＣＡテーブル１４２０に記憶される。ＥＣＡテーブル１４２０は、図４のＥＣＡテーブル４００と実質的に同様であってもよい。
【００３７】
本明細書で開示するように、制御プレーン機能をネットワーク要素にオフロードすることは、種々の方法で行うことができる。一実施形態では、ステートフルデータプレーンおよび制御プレーンアプリケーションは、共通の実行環境を使用して（例えば、オープン・サービス・ゲートウェイ・イニシアティブ（ＯＳＧＩ）フレームワークを使用するバンドルとして）、転送要素にプッシュされてもよい。バークレー拡張ソフトウェアスイッチ（ＢＥＳＳ）またはベクトル・パケット・プロセッシング（ＶＰＰ）を用いて、パケット・パイプラインにステートフル・モジュールを挿入することもできる。これらの実施形態のすべては、入力パケットがバンドルによって選択的に処理されるように、機能をチェーン化する能力を提供する。制御機能は、チェーンの一部であってもよく、エンティティコントローラにバンドルされた制御されたエンティティとして露出されてもよい。そのような実装は、限定された用途しか有していないかも知れない。かかる機能は入ってくるフローパケットによって駆動されるからである。リンクアップ／ダウンイベントや制御信号のような、データプレーントラフィックフローにより変更されない状態が、ネットワーク要素上に存在してもよい。
【００３８】
同様の機能性は、ネットワーク要素の制御ファブリック（例えば、コンテナとして）で実行されるように実際のコードをプッシュすることによって得ることができる。リモートコントローラは、（パケット処理パイプラインへのモジュールのロードまたはアンロードとは対照的に）コードをネットワーク要素にロードまたはアンロードして制御プレーンを変更することができる。このような実施形態は、各機能が、機能を超えて露出されないそれ自身の有限状態マシンを維持し得るので、グローバル管理目標に関して管理がより困難であり得る。たとえば、２つの関数がトリガとして同じイベントを受け取り、そのトリガに基づいてローカル制御動作を実行すると、レース状態となり得る。逆に、異なるイベントトリガを受け取る２つの関数は、一貫性のない方法で転送パイプラインをプログラムしようとし得る。このような問題を管理するために、ネットワーク要素上のポリシー競合メカニズムを考案するよりも、リモートネットワークコントローラにそのような競合を検出して回避させ、各ネットワーク要素を一貫したポリシーでプログラムすることが好ましい場合がある。開示の実施形態は、リモートコントローラがポリシールールおよびＦＳＭルールを明示的にプログラムすることを可能にするので、これらの目的を達成する直接的な方法を提供する。開示の実施形態は、ポリシールールの更新がバイナリコードの更新よりも速いため、ダイナミックプログラミングにも適している。
【００３９】
１つ以上の実施形態は、フロールールの変更、フローメーターの読み取り、またはフロー優先度の変更などの制御プレーン命令の実行を可能にする。１つ以上の実施形態では、リモート制御プレーンは、ネットワーク要素の制御プレーンにオフロードされる。さらに、１つ以上の実施形態では、ＦＳＭは、データプレーンパケットのみによって駆動されるのではなく、ネットワーク要素上の実質的に任意の観測可能な状態によって駆動される。ローカルに記憶されたレシピを使用して、ある状態から別の状態へリソースを移動することに基づいている開示の命令セットは、既存のシステムには存在しない。
【００４０】
図１５は、ホスト装置内にインストールされ得る、本明細書に説明の方法を実行する一実施形態による処理システム１５００のブロック図を示す。図示のように、処理システム１５００は、プロセッサ１５０４、メモリ１５０６、およびインターフェース１５１０ないし１５１４を含み、これらは、図示のように構成されても（構成されていなくても）よい。プロセッサ１５０４は、計算および／または他の処理関連タスクを実行するように構成された任意のコンポーネントまたはコンポーネントの集まりであってもよく、メモリ１５０６は、プロセッサ１５０４による実行のためのプログラミングおよび／または命令を記憶するように構成された任意のコンポーネントまたはコンポーネントの集まりであってもよい。一実施形態では、メモリ１５０６は、命令１５２５を記憶する非一時的コンピュータ読取り可能媒体を含む。命令１５２５は、プロセッサ１５０４によって実行され得る。インターフェース１５１０、１５１２、１５１４は、処理システム１５００が他の装置／コンポーネントおよび／またはユーザと通信することを可能にする任意のコンポーネントまたはコンポーネントの集まりであってもよい。例えば、１つ以上のインターフェース１５１０、１５１２、１５１４は、プロセッサ１５０４からのデータ、制御、または管理メッセージをホスト装置および／またはリモート装置にインストールされたアプリケーションに通信するように構成されてもよい。別の例として、インターフェース１５１０、１５１２、１５１４のうちの１つ以上は、ユーザまたはユーザ装置（例えば、パーソナルコンピュータ（ＰＣ）など）が処理システム１５００と対話／通信することを可能にするように構成されてもよい。処理システム１５００は、長期記憶（例えば、不揮発性メモリなど）のような、図に示されていない追加のコンポーネントを含んでもよい。
【００４１】
いくつかの実施形態では、処理システム１５００は、電気通信ネットワークにアクセスしているか、またはその一部であるネットワーク装置に含まれる。一例において、処理システム１５００は、基地局、中継局、スケジューラ、コントローラ、ゲートウェイ、ルータ、アプリケーションサーバ、または電気通信ネットワーク内のその他の任意の装置のような、無線または有線電気通信ネットワーク内のネットワーク装置にある。他の実施形態では、処理システム１５００は、移動局、ユーザ機器（ＵＥ）、パーソナルコンピュータ（ＰＣ）、タブレット、ウェアラブル通信装置（例えば、スマートウォッチなど）、または電気通信ネットワークにアクセスするように構成されたその他の装置のような、無線または有線電気通信ネットワークにアクセスするユーザ装置内にある。
【００４２】
一実施形態では、処理システム１５００は、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングするモデルモジュールと、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするオフロードモジュールであって、そのサブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御に適した、選択された遷移を含むオフロードモジュールと、遷移のサブセット内にない他の遷移をリモート制御する遷移モジュールとを含む。いくつかの実施形態において、処理システム１５００は、実施形態で説明するステップのいずれか１つまたはステップの組み合わせを実行する、他のまたは追加のモジュールを含んでもよい。さらに、本方法の追加または代替の実施形態または態様のいずれも、図面のどれかに示されるか、または請求項のどれかに記載されるように、同様のモジュールを含むことが想定される。
【００４３】
いくつかの実施形態では、インターフェース１５１０、１５１２、１５１４のうちの１つ以上は、通信ネットワークを介して信号を送受信するように構成されたトランシーバに処理システム１５００を接続する。図１６は、電気通信ネットワークを介して信号を送受信するように構成されたトランシーバ１６００を示すブロック図である。トランシーバ１６００は、ホスト装置にインストールされてもよい。図示のように、トランシーバ１６００は、ネットワーク側インターフェース１６０２、カップラー１６０４、送信機１６０６、受信機１６０８、信号プロセッサ１６１０、および装置側インターフェース１６１２を含む。ネットワーク側インターフェース１６０２は、無線または有線電気通信ネットワークを介して信号を送信または受信するように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。カップラー１６０４は、ネットワーク側インターフェース１６０２を介して双方向通信を容易にするように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。送信機１６０６は、ベースバンド信号をネットワーク側インターフェース１６０２を介して送信するのに適した変調搬送波信号に変換するように構成された任意のコンポーネントまたはコンポーネントの集まり（例えば、アップコンバータ、電力増幅器など）を含んでもよい。受信機１６０８は、ネットワーク側インターフェース１６０２を介して受信した搬送波信号をベースバンド信号に変換するように構成された任意のコンポーネントまたはコンポーネントの集まり（例えば、ダウンコンバータ、低ノイズ増幅器など）を含んでもよい。信号プロセッサ１６１０は、ベースバンド信号を装置側インターフェース１６１２を介しての通信に適したデータ信号に、またはその逆に変換するように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。装置側インターフェース１６１２は、信号プロセッサ１１１０とホスト装置内のコンポーネント（例えば、処理システム１５００、ローカルエリアネットワーク（ＬＡＮ）ポートなど）との間でデータ信号を通信するように構成された任意のコンポーネントまたはコンポーネントの集合を含んでもよい。
【００４４】
いくつかの実施形態では、処理システム１５００は、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングし、その遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードし、そのサブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御に適した選択された遷移を含み、その遷移のサブセット内にない他の遷移をリモート制御する。
【００４５】
トランシーバ１６００は、任意のタイプの通信媒体を介して信号を送受信することができる。いくつかの実施形態では、トランシーバ１６００は、無線媒体を介して信号を送受信する。例えば、トランシーバ１６００は、セルラプロトコル（例えば、ロングタームエボリューション（ＬＴＥ）など）、無線ローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、Ｗｉ−Ｆｉなど）、または任意の他のタイプの無線プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、近接場通信（ＮＦＣ）など）などの無線電気通信プロトコルに従って通信するように構成された無線トランシーバであってもよい。このような実施形態では、ネットワーク側インターフェース１６０２は、１つ以上のアンテナ／放射素子を含む。例えば、ネットワーク側インターフェース１６０２は、単一のアンテナ、複数の別個のアンテナ、または多層通信、例えば、単一入力多重出力（ＳＩＭＯ）、多重入力単一出力（ＭＩＳＯ）、多重入力多重出力（ＭＩＭＯ）などに構成されたマルチアンテナアレイを含んでいてもよい。他の実施形態では、トランシーバ１６００は、有線媒体、例えば、ツイストペアケーブル、同軸ケーブル、光ファイバなどを介して信号を送受信する。処理システム及び／又はトランシーバによっては、図示したすべてのコンポーネントを利用してもよいし、コンポーネントの一部のみを利用してもよく、集積レベルは装置ごとに変わっても良い。
【００４６】
言うまでもなく、本明細書に提供される実施形態による方法の１つ以上のステップは、対応するユニットまたはモジュールによって実施可能である。例えば、信号は、送信ユニットまたは送信モジュールによって送信されてもよい。信号は、受信ユニットまたは受信モジュールによって受信されてもよい。信号は、処理ユニットまたは処理モジュールによって処理されてもよい。他のステップは、モデリングユニット／モジュール、オフローディングユニット／モジュール、制御ユニット／モジュール、および／または準備ユニット／モジュールによって実行されてもよい。各ユニット／モジュールは、ハードウェア、ソフトウェア、またはそれらの組み合わせであってもよい。例えば、ユニット／モジュールのうちの１つ以上は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）などの集積回路であってもよい。
【００４７】
本発明を例示の実施形態を参照して説明したが、この説明は限定を意図したものではない。例示の実施形態のさまざまな修正や組み合わせ、及び本発明のその他の実施形態は、当業者にはこの説明を参照すれば明らかになるだろう。それゆえ、添付した特許請求の範囲はかかる修正や実施形態を含むことを意図したものである。
【図１】
2020502880.tif 000003
【図２】
2020502880.tif 000004
【図３】
2020502880.tif 000005
【図４】
2020502880.tif 000006
【図５】
2020502880.tif 000007
【図６】
2020502880.tif 000008
【図７】
2020502880.tif 000009
【図８】
2020502880.tif 000010
【図９】
2020502880.tif 000011
【図１０】
2020502880.tif 000012
【図１１】
2020502880.tif 000013
【図１２】
2020502880.tif 000014
【図１３】
2020502880.tif 000015
【図１４】
2020502880.tif 000016
【図１５】
2020502880.tif 000017
【図１６】
2020502880.tif 000018
【手続補正書】
【提出日】令和1年7月3日(2019.7.3)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ソフトウェアデファインドネットワークおよびネットワーク機能仮想化の分野に関し、および転送要素のステートフル制御に関する。
【背景技術】
【０００２】
ソフトウェアデファインドネットワーク（ＳＤＮ）は、ネットワークの制御プレーンとユーザプレーンとを切り離す。ネットワーク機能仮想化は、制御プレーン機能とユーザプレーン機能をハードウェアから分離する。また、ネットワーク機能の仮想化により、電気通信クラウド内のどこでも、特定のサービスニーズに基づいてネットワーク機能を展開することができる。レガシーネットワークと比較して、ソフトウェアデファインドネットワークは、制御プレーンおよびユーザプレーンのより良いスケーリング、ネットワーク機能のより迅速な導入、より動的なネットワークカスタム化、およびリモート状態収集およびモニタリングを提供する。
【発明の概要】
【０００３】
本発明の一実施形態によると、送信機に結合されたプロセッサを有するリモートコントローラによってネットワーク要素を制御する方法は、前記プロセッサが、前記ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングすることと、前記送信機が、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードすることであって、前記サブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む、ことと、前記プロセッサが、前記遷移のサブセットにない他の遷移をリモート制御することとを含む。
【０００４】
本発明の他の一実施形態によると、リモートコントローラは、送信コンポーネントと、命令を含む非一時的なメモリと、前記送信コンポーネントおよび前記メモリと通信する１つ以上のプロセッサとを有する。１つ以上のプロセッサは、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化する命令を実行する。前記送信コンポーネントは、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするように構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含む。前記１つ以上のプロセッサは、遷移のサブセット中にない他の遷移をリモート制御するように構成される。
【０００５】
本発明の他の一実施形態によると、ネットワーク要素のステートフル制御のためのシステムは、ネットワーク要素とリモートコントローラとを含む。リモートコントローラは、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデル化するように構成され、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするようにさらに構成され、前記サブセットは、リモートコントローラによるリモート制御よりもネットワーク要素によるローカル制御により適した選択された遷移を含み、トランジションのサブセットにない他のトランジションをプロセッサによってリモート制御するようさらに構成される。
【０００６】
１つ以上の実施形態は、スイッチのローカル状態に基づく制御決定を、リモートコントローラからプログラム的な方法でスイッチ側にオフロードする。１つ以上の実施形態は、ポリシードリブンの分散制御プレーンをインプリメントする技術を提供する。制御論理は、主制御論理のクラウド化によるボトルネックを回避することにより、低レイテンシおよび高スループット性能を達成するために、高速制御を行うように、プログラム可能な方法で、トランスポートリソースにより近くに移動されてもよい。リモート・コントローラ・アプリケーションは依然としてエンドツーエンド・ポリシーを決定するが、ポリシー施行はローカル・レベルで実現される。複雑な制御プレーン決定論理がネットワークの任意の点でプログラムされ得るので、１つ以上の実施形態は、第３世代パートナーシッププロジェクト（３ＧＰＰ）標準におけるポリシー・課金ルール機能（ＰＣＲＦ）／ポリシー・課金実施機能（ＰＣＥＦ）アプローチよりも汎用性が高い。
【図面の簡単な説明】
【０００７】
本発明及びその優位性をより良く理解してもらうため、ここで、添付した図面を参照しつつ以下に説明する。
【図１】すべての制御機能がプッシュされたネットワーク要素を示す図である。
【図２】ステートフルネットワークプログラミングのための一実施形態による装置を示す図である。
【図３】イベント・条件・動作ルールを用いてネットワーク要素をプログラミングするための一実施形態による制御フローの図である。
【図４】一実施形態によるイベント・条件・動作テーブルを示す図である。
【図５】プログラマブルネットワーク要素にレシピをポストする一実施形態による制御フローを示す図である。
【図６】ポストされたレシピを含む一実施形態によるクックブックデータベースを示す図である。
【図７】有限状態マシンルールをポストする一実施形態による制御フローを示す図である。
【図８】ポストされた有限状態マシンルールを含む一実施形態による有限状態マシンテーブルを示す図である。
【図９】モニターされた状態変化に基づく一実施形態による制御フローを示す図である。
【図１０】ネットワーク要素の一実施形態によるステートフル制御方法のステップを示す図である。
【図１１】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１２】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１３】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１４】ネットワーク要素の一実施形態によるステートフル制御方法の他のステップを示す図である。
【図１５】本明細書に説明する方法を実行する一実施形態による処理システムを示すブロック図である。
【図１６】電気通信ネットワークを介して信号を送受信するように構成されたトランシーバを示すブロック図である。
【発明を実施するための形態】
【０００８】
現在の好ましい実施形態の構造、製造および使用を以下に詳細に説明する。しかし、言うまでもなく、本発明は幅広い様々な状況で実施できる多くの応用可能な発明概念を提供するものである。本明細書で説明する実施形態は、本発明を生産し使用する方法の単なる例示であり、本発明の範囲を限定するものではない。
【０００９】
主要なワークロードがインターネットに束縛される移動ネットワークでは、いくつかの機能は、その機能がセッションレベル、フローレベルまたはパケットレベルの処理を提供するかに関わらず、少数の中央オフィスに集中されることがある。このように集中され得る機能には、認証、承認および会計（ＡＡＡ）、ポリシーエンフォースメント、サービス品質（ＱｏＳ）管理、セッション制御、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）アクセス、公衆インターネットアクセス、ディープパケット検査（ＤＰＩ）、およびファイアウォール機能などがある。ワークロードが進化し、ネットワークのエッジで新しいユースケースが現れるにつれて、この南北トラフィックパターンにより、東西トラフィック（すなわち、エッジ間通信サービス）およびエッジコンピューティングおよびストレージの形態における変化を見ることがある。すべてのセッション、ＵＥ、ネットワーク、およびトラフィックの状態を集中的に収集し、これらの状態に基づいてクローズドループでネットワーク要素を制御すると、スケーリング問題およびパフォーマンス低下をもたらす可能性がある。
【００１０】
図１は、すべての制御機能が制御プレーンオーケストレータ１２０からプッシュされたネットワーク要素１１０を示す。特に、制御機能は、ネットワーク要素１１０においてインスタンス化された複数の制御アプリケーション１３０にオフロードされている。制御アプリケーション１３０の各々は、１つ以上の転送パイプライン要素１４０を制御することができる。転送パイプライン要素１４０はプログラマブル転送パイプライン１５０の一部である。制御は、相互接続／スイッチ／バス１６０および／またはコンテナ／モジュールマネージャ１７０によって媒介されてもよい。
【００１１】
全ての制御機能が図１のようにネットワーク要素１１０にオフロードされると、いくつかの問題が生じることがある。例えば、ネットワーク要素１１０はそのような場合に膨張することがある。さらに、複数の制御アプリケーション１３０が、同じ転送モジュールまたはパイプライン１５０をプログラムまたは構成するように動作する場合、競合をどう解決するかが不明であり得る。また、制御機能のポリシーをどう分離する方法も不明な場合がある。また、状態維持およびポリシー管理などの機能に関して、制御アプリケーション１３０にわたる繰り返しがあるかも知れない。また、制御機能の動的変更は困難な場合がある。例えば、少数のステートメントまたはポリシーのみを変更する必要がある場合でも、完全な新しい実行可能ロジック・セットをネットワーク要素１１０に移動する必要がある。そのような論理更新は、非効率であることに加えて、ステートフルでない可能性もある。
【００１２】
次世代のネットワークでは、異なるワークロードのニーズをレイテンシとスループットに関して対処し、一方、グローバルネットワークビューを持つ運用サポートシステム及びビジネスサポートシステム（ＯＳＳ／ＢＳＳ）の、エンドツーエンドのサービス要件を満たすというニーズを満たす必要があり得る。柔軟かつプログラム可能な方法でローカル状態を生成または集約する、ネットワーク要素に近い制御機能を展開することができる分散型および階層的制御プレーンは、ＯＳＳ／ＢＳＳニーズと性能ニーズの両方に対処することができる。本明細書に開示する実施形態は、このような分散型および階層的制御プレーンを可能にするソリューションを提供する。
【００１３】
一実施形態では、ネットワーク要素に対し軽量ステートフル制御機能を実行する装置および方法が提供される。装置は、２つの層から成り、１つの層は、１つ以上のリモート制御アプリケーションを備え、もう１つの層は、ＮＥローカルプログラマブルエンティティのための状態マシンをホストする制御エージェントと、レシピのクックブックと、状態マシンテーブルと、イベント条件動作（ＥＣＡ）テーブルと、テーブルによって指定される動作をロード、アンロード、及び実行する対応するエンジンとを有するネットワーク要素（ＮＥ）を備える。本明細書で使用される場合、用語「ネットワーク要素」または「ＮＥ」は、基地局、ユーザ装置（ＵＥ）、スイッチ、ゲートウェイ、または任意の同様なコンポーネントを指し得る。ネットワーク要素は、本明細書では、転送要素とも呼び得る。
【００１４】
ＮＥは、リモート制御可能であると仮定してもよい。ＮＥ上のエンティティを制御することができるリモート制御アプリケーションは、最初に、そのエンティティの所望の動作状態をモデリングし、次いで、得られた状態マシンをＮＥにプッシュすることができる。あるいは、プログラマブルエンティティは、ＮＥ上の制御エージェントによってすでにホストされたデフォルト状態マシンを有していてもよい。後者の場合、リモート制御アプリケーションは、エンティティに対して有限状態マシン（ＦＳＭ）を問い合わせることができる。各制御可能エンティティは、リモートコントローラによってＦＳＭとしてモデリングされてもよい。
【００１５】
あるエンティティの状態マシンがＮＥに記憶されると、リモート制御アプリケーションは、エンティティの状態をある状態から別の状態に変更する命令をＮＥの制御エージェントに送ることができる。各状態遷移は、ある順序でローカルに実行される一連の制御動作を伴う。このようにある順序で実行される制御動作のセットはレシピと呼ぶことができる。
【００１６】
現在、複数の命令は、制御アプリケーションによって直接送られてもよいが、このような手順は複数回の往復を結果としてもたらす可能性があり、その数は、順次的に完了すべき命令の数と共に増加する可能性がある。他方、開示の実施形態では、リモートコントローラは、１つのハイレベル命令でＮＥ上のエンティティをプログラムすることができる。ＮＥ上には複数のプログラマブルエンティティがあってもよく、各プログラマブルエンティティの複数のインスタンスがあってもよい。さらに、各エンティティは、多くの状態および状態遷移から構成されていてもよい。従って、ＮＥは、複数の状態マシンおよび複数のレシピをホストしていてもよい。レシピの集まりは、ＮＥのプログラマビリティのクックブックと呼ぶことができる。以下でより詳細に説明するように、ＮＥはまた、ＥＣＡベースのポリシーエンジンをホストしてもよい。
【００１７】
リモート制御アプリケーション（すなわち、コントローラ）は、あるＮＥ上のプログラマブルエンティティに問い合わせることができる。リモートコントローラはまた、１つ以上のイベント、１つ以上の条件、およびイベントが発生し、条件が保持される場合に実行される１つ以上の動作を画定することによって、ポリシーをプッシュしてもよい。動作は、あるレシピを実行する、または制御されるエンティティをある状態から他の状態に移動させる形式であってもよい。例えば、コントローラは、「イベントＸが発生し、条件Ｙが満たされた場合、レシピＺを実行する」という形式の命令をプッシュすることができる。イベントは、ＮＥ上のモニターされる１つ以上の状態（例えば、フローカウンタ、フローバッファ、またはリンクアップ／ダウンイベント）の変化に対応する。条件ステートメントは、１次元（例えば、バッファＡが空）であってもよく、または多次元（たとえば、フローＦ１に対してＢバイトが送信され、リンクＹが輻輳している）であってもよい。コントローラは、ＥＣＡ命令が送られる前、またはＥＣＡ命令が送られると同時に、レシピをプッシュすることができる。コントローラは、ＥＣＡルールを削除し、ＥＣＡルールを変更し、レシピを更新することができる。実施形態は、単純な命令または状態遷移命令が、レシピを特定するよりもむしろ、動作として画定することを可能にする。また、実施形態では、ＥＣＡルールを１回または繰り返し実行することも可能である。ＥＣＡベースのアプローチは、コントローラがローカル状態の変化に素早く反応することを可能にする。
【００１８】
図２は、制御アプリケーション２１２と通信することができる一実施形態によるＮＥ２１０の内部コンポーネントを示す。制御アプリケーション２１２またはリモートコントローラは、単一コンポーネントに存在する離散的エンティティであっても、または複数のコンポーネントにわたって分散されているエンティティであってもよいソフトウェアデファインドネットワークに基づく外部エンティティである。制御アプリケーション２１２は、ＮＥ２１０のメッセージルータ２１４に命令を送ることによってＮＥ２１０をプログラムする。メッセージルータ２１４は、制御アプリケーション２１２から来る命令を３つのエンジン、すなわちＥＣＡエンジン２１６、ＦＳＭエンジン２１８、およびクックブック（ＣＢ）エンジン２２０のうちの少なくとも１つに転送する。これらのエンジンの各々は、ポリシールールと、状態遷移ルールと、状態遷移要求および観測されたイベントに応答して実行される命令セットとを記憶する対応テーブル（すなわち、ＥＣＡテーブル２２２、ＦＳＭテーブル２２４、およびクックブック２２６）を有する。ＥＣＡエンジン２１６およびＦＳＭエンジン２１８は、エンティティコントローラ２２８（例えば、ＥＣ−１からＥＣ−ｋ）に対するローカル命令を呼び出し、エンティティコントローラ２２８は、１つ以上の制御エンティティ２３０（例えば、Ｅ−１１からＥ−１ｉ、Ｅ２からＥ−ｋ）をプログラム、制御、および／または観測する。制御されるエンティティ２３０の状態は、状態テーブル２３２に記憶されてもよい。
【００１９】
ＥＣＡエンジン２１６は、ＮＥ２１０によって観測、モニター、または測定されるイベントを指定するポリシールールと、満たされるべき条件ステートメントと、イベントが観測されたときに条件ステートメントが満たされた場合に取られるべき動作または一連の動作とを受け取ることができる。イベントは、一般的には、ローカル仮想リソース（例えば、仮想ポートまたはコンテナ）、物理リソース（例えば、三値コンテンツアドレス可能メモリ（ＴＣＡＭ）またはインターフェースカード）、または論理リソース（例えば、フローテーブル、パケットカウンタ、トンネル、またはパス）の状態変化に対応する。イベントは、２つ以上のリソースの状態変化が観測、モニター、または測定される複合イベントであってもよい。同様に、条件ステートメントは、２つ以上の条件が満たされる複合ステートメントであってもよい。
【００２０】
一実施形態では、ＥＣＡルールをＮＥにポストすることが、図３に示すフローチャート３００のステップに続く。制御アプリケーション３１０は、「ポストＥＣＡルール」メッセージ３２０または同様のメッセージを介して、１つ以上のＥＣＡルールをＮＥにポストする。メッセージルータ３３０は、ＥＣＡルールに対するＮＥの受信端である。メッセージルータ３３０は、「ＥＣＡルールをルーティング」メッセージ３４０または同様のメッセージを介してＥＣＡルールをＥＣＡエンジン３５０に転送する。ＥＣＡエンジン３５０は、「状態を観測」メッセージ３６０または同様のメッセージを介して、状態をモニターすべきＮＥ上のエンティティを抽出し、対応するエンティティコントローラ３７０に、エンティティをモニターし、エンティティの状態変化をＥＣＡエンジン３５０に渡すよう指示する。別の実施形態では、パブリッシュ／サブスクライブサブシステムまたはメッセージパッシングサブシステムがあり、すべてのイベントはエンティティコントローラ３７０によってブロードキャストされる。このような実施形態では、ＥＣＡエンジン３５０は、受信されたＥＣＡルールにリストされたイベントを聞くように、そのフィルタをプログラムすることができる。ＥＣＡエンジン３５０は、「ルールを保存」メッセージ３８０または同様のメッセージを介して、受信した各ＥＣＡルールをＥＣＡテーブル３９０に保存することができる。
【００２１】
図４は、各行が１つのＥＣＡルールに対応する一実施形態によるＥＣＡテーブル４００を示す。図４のＥＣＡテーブル４００は、図３のＥＣＡテーブル３９０と実質的に同様であってもよい。第１列４１０の項目は、２タプル＜ｒｅｓｏｕｒｃｅ  ＩＤ，  ｅｖｅｎｔ  ｎａｍｅ＞によってコード化されるイベントタイプを指定する。ｒｅｓｏｕｒｃｅ  ＩＤは、インターフェース、フローバッファ、またはフローテーブルなどのローカルリソースインスタンスのローカルで一意的な識別子に対応する。第２の列４２０内の項目は、ヌル、単純条件、または複合条件であり得る条件ステートメントに対応する。条件ステートメントは、１つ以上のリソースの観測可能なプロパティまたは状態に対する算術演算および論理演算を含むことができる。第３列４３０内の項目は、３つの形式のうちの１つを取り得る動作ステートメントに対応する。第１の形式では、動作ステートメントは、３つのパラメータ、すなわちローカルで一意的なリソース識別子、現在の状態、および次の状態を取る一般的な「移動」命令または同様の命令であってもよい。第２の形式では、動作ステートメントは、「実行」ステートメントまたは同様のステートメントであってもよく、パラメータは、ローカルで制御可能なエンティティ（例えば、フローテーブル、フローバッファ、メーター、カウンター、またはポート）上で実行可能な一連の個別命令であるレシピのリストとして提供される。第３の形式では、動作ステートメントはより単純な「実行」ステートメントであり、個別の命令をパラメータとして取る。
【００２２】
図５は、レシピをプログラマブルＮＥにポストするための一実施形態によるメッセージシーケンス５００を示す。メッセージルータ５３０は、制御アプリケーション５１０から「レシピをポスト」メッセージ５２０または同様のメッセージを受信すると、「レシピをルーティング」メッセージ５４０または同様のメッセージの一部として、受信したレシピをクックブックエンジン５５０に転送する。クックブックエンジン５５０は、「レシピを保存」メッセージ５６０または同様のメッセージを介してクックブックデータベース５７０にレシピをローカルで記憶する。
【００２３】
図６は、各行が一意的なレシピである、一実施形態によるクックブックデータベース６００を示す。図６のクックブックデータベース６００は、図５のクックブックデータベース５７０と実質的に同様であってもよい。第１列６１０の項目は、ローカルで一意的なレシピ識別子を指定する。第２列６２０の項目は、レシピに関連付けられ、ＮＥ上の特定の制御可能なエンティティ上で実行され得る命令のリストを指定する。
【００２４】
図７は、ＦＳＭルールをポストする一実施形態による制御フロー７００を示す。メッセージルータ７３０は、「ＦＳＭルールをポスト」メッセージ７２０または同様のメッセージを介して、制御アプリケーション７１０からＦＳＭルールのセットを受け取る。メッセージルータ７３０は、「ＦＳＭルールをルーティング」メッセージ７４０または同様のメッセージを介してそのルールをＦＳＭエンジン７５０にルーティングする。ＦＳＭエンジン７５０は、「ＦＳＭルールを保存」メッセージ７６０または同様のメッセージを介してルールをＦＳＭテーブル７７０に保存する。ＦＳＭルールは、ローカルで一意的なリソース識別子と、そのリソースの現在の状態にマッチされた第１の状態と、そのリソースのターゲット状態にマッチされた第２の状態と、識別されたリソースを第１の状態から第２の状態に移動するために実行されるレシピを指すレシピ識別子とを指定することができる。ＦＳＭルールが意味を持つためには、指定されたレシピＩＤを有するレシピをすでにクックブックに記憶してある必要があるかも知れない。
【００２５】
図８は、４つの列を含む一実施形態によるＦＳＭテーブル８００を示す。図８のＦＳＭテーブル８００は、図７のＦＳＭテーブル７７０と実質的に同様であってもよい。第１の列８１０は、ＮＥのローカルスコープにおいて一意的なリソース識別子をリストする。リソース識別子によって識別されるリソースは、いくつかの例では、図２の制御されたエンティティ２３０のうちの１つと同等であり得る。リソース識別子は、一般的には、ストリングタイプを有してもよいが、整数に基づく番号付けまたは命名を使用してもよい。第２の列８２０は、現在時間にリソースが存在し得る個別の状態をリストする現在の状態列である。全ての可能な状態が現在の状態列８２０に含まれる必要はない。すなわち、制御目的に使用されない状態を含める必要はない。第３の列８３０は、リモート制御アプリケーションがリソースの移動を要求することができるそのリソースの個別の状態をリストする次の状態列である。ここでも、コントローラがリソースを幾つかの可能な状態に移動しない場合、すべての可能な状態が次の状態列８３０に含まれる必要はない。これらの状態は、一般的には、ストリングタイプを有してもよいが、数字タイプを有してもよい。第４列８４０は、所与の行で指定された状態遷移に使用されるレシピを識別するレシピＩＤ列である。レシピＩＤは、一般的には、数字タイプを有してもよいが、ストリングタイプを有してもよい。タイプの慣習は、クックブックのタイプと整合性がとれる必要があるかもしれない。
【００２６】
ＦＳＭルール、ＥＣＡルールおよびレシピが、本明細書に開示されるように、ＦＳＭテーブル、ＥＣＡテーブルおよびクックブックに記憶されると、ＥＣＡエンジンは、イベントおよび条件に基づく動作を実行するため、それらのピースを所定の位置に有する。図９は、イベントおよび条件に基づく動作のための一実施形態による制御フロー９００を示す。１つ以上のエンティティコントローラ９１０は、それらのローカル・コントローラ・エンティティの状態変化を観測する。モニターされたエンティティの状態変化が検出された場合、検出エンティティコントローラ９１０は、ＥＣＡエンジン９２０に通知する。一実施形態では、エンティティコントローラ９１０は、ＥＣＡエンジン９２０に、それらの制御されたエンティティの全ての状態変化を通知する。別の実施形態では、ＥＣＡエンジン９２０は、一定の状態遷移の通知をサブスクライブし、従って、エンティティコントローラ９１０は、サブスクライブされたイベント（すなわち、状態遷移）のみをＥＣＡエンジン９２０に通知する。ＥＣＡエンジン９２０は、状態テーブル９３０を更新することにより、モニターされる状態を追跡し続ける。一実施形態では、ＥＣＡエンジン９２０は、制御されるエンティティの最後の状態のみを保持する。別の実施形態では、ＥＣＡエンジン９２０は、ｉ番目の制御エンティティの最後のＮｉ個の状態を追跡する。観測されたエンティティの状態が保存されると、ＥＣＡエンジン９２０は、ＥＣＡテーブル９４０に指定された関連ポリシールールが存在するかどうかをチェックする。マッチするポリシーが存在する場合、ＥＣＡエンジン９２０は、ＥＣＡテーブル９４０から、満たされるべき追加条件および実行される動作をロードする。状態テーブル９３０と、場合によっては他のローカルにキャッシュされたパラメータ値とを用いて、ＥＣＡエンジン９２０は、全ての条件が満たされるか否かを決定する。
【００２７】
全ての条件が満たされる場合、ＥＣＡエンジン９２０は、ＥＣＡルールで提供される動作のタイプに応じて、いくつかの方法のうちの１つで動作を実行することができる。ポリシールールの一部としてすでに記憶されている単純な命令セットの場合、ＥＣＡエンジン９２０は、動作がルールにリストされている順序で動作を実行する。動作がレシピのリストである場合、ＥＣＡエンジン９２０は、レシピＩＤを使用して、クックブック９５０から各レシピを順にロードし、ＥＣＡルールによって提示される順序で各レシピを実行する。レシピＩＤは、ＦＳＭテーブル９６０から取り出すことができる。レシピ内の各命令は、命令がレシピに列挙されている順序で実行される。動作が「移動」ステートメントまたは同様のステートメント（すなわち、現在の状態から次の状態にリソースを移動する）である場合、ＥＣＡエンジン９２０は、リソースの現在の状態が「移動」命令に指定された現在の状態と一致するかどうかを判定し、もしそうであれば、命令がＥＣＡルールに記載されている順序で、ポリシールールの「移動」命令の各々のレシピＩＤをロードする。各レシピは、レシピＩＤに基づいて、クックブック９５０からロードされ、ロードされたレシピ内の命令は、命令がクックブック９５０からロードされる順序で実行される。ＥＣＡルールで指定される動作は、上記のカテゴリの１つにのみ属しているか、動作タイプの組み合わせであってもよい。
【００２８】
図２ないし図９の同名のコンポーネントは、たとえそのコンポーネントが異なる参照番号によって参照されていても、実質的に互いに同様であり得る。
【００２９】
図１０ないし図１４は、ネットワーク要素のステートフル制御の一実施形態による方法１０００におけるステップを示す。本方法１０００は、状態マシンがモデリングされるステップ１０１０、状態遷移のレシピが準備されるステップ１１１０、レシピがポストされるステップ１２１０、ＦＳＭルールがポストされるステップ１３１０、ＥＣＡルールがポストされるステップ１４１０を含む。各ステップは後でより詳しく説明する。ステップは、必ずしも示されたシーケンスで実行される必要はなく、いくつかのステップは、他のステップと同時に実行されてもよい。
【００３０】
図１０は、状態マシンがモデリングされるステップ１０１０を示す。この例では、モデルは、第１の状態１０２０から第２の状態１０３０への遷移、第２の状態１０３０から第３の状態１０４０への遷移、第３の状態１０４０から第４の状態１０５０への遷移、第４の状態１０５０から第２の状態１０３０への遷移、および第３の状態１０４０から第１の状態１０２０への遷移を含む。
【００３１】
図１１は、状態遷移のためのレシピが準備されるステップ１１１０を示し、各レシピは、順次的に呼び出される命令のセットである。一実施形態では、レシピは、ネットワーク要素上でローカルに制御される遷移に対してのみ作成される。リモートコントローラによってリモートで制御される遷移のレシピは作成されない。リモートコントローラまたはいくつかの他のコンポーネントは、どの遷移がリモートコントローラによるリモート制御よりも、ネットワーク要素によるローカル制御により適しているかを決定することができる。
【００３２】
図１１の例では、第１の状態１０２０から第２の状態１０３０への遷移、第４の状態１０５０から第２の状態１０３０への遷移、および第３の状態１０４０から第１の状態１０２０への遷移は、ネットワーク要素にオフロードされる。従って、第１のレシピ１１２０が準備され、第１の状態１０２０から第２の状態１０３０に遷移するための命令を含む。第２のレシピ１１３０が準備され、第４の状態１０５０から第２の状態１０３０に遷移するための命令を含む。第３のレシピ１１４０が準備され、第３の状態１０４０から第１の状態１０２０に遷移するための命令を含む。第２の状態１０３０から第３の状態１０４０への遷移と、第３の状態１０４０から第４の状態１０５０への遷移とは、リモートコントローラによってリモート制御されるため、これらの遷移のためのレシピは作成されない。このようにして、プログラマブルネットワーク要素は、ネットワーク要素に記憶されたレシピによって部分的にローカルで制御され、リモートコントローラによって部分的にリモートで制御される。
【００３３】
図１０および１１の各状態１０２０ないし１０５０は、ＦＳＭテーブルの対応する行を有してもよい。どの現在状態からどの次状態に遷移が起こるかを示す有向矢印は、クックブックに記憶された１つのレシピのみに対応していてもよい。対照的に、異なる状態遷移は、同じレシピＩＤにマップされてもよく、従って同じレシピにマップされてもよい。同じリソース・タイプの異なるインスタンスが同じ状態マシンを共有してもよく、ＦＳＭテーブルに重複するエントリーが存在してはならない。対照的に、同じリソース・タイプの異なるインスタンスは、それらの状態遷移のために異なるレシピを利用することもできる。
【００３４】
図１２は、レシピがポストされるステップ１２１０を示す。すなわち、図１１において準備されたレシピは、そのレシピが適用されるネットワーク要素上のテーブル１２２０に記憶される。テーブル１２２０は、図６のクックブックデータベース６００と実質的に同様であってもよい。
【００３５】
図１３は、ＦＳＭルールがポストされるステップ１３１０を示す。すなわち、図７を参照して上に説明したように、１つ以上のＦＳＭルールが受信され、ＦＳＭテーブル１３２０に記憶される。ＦＳＭテーブル１３２０は、図８のＦＳＭテーブル８００と実質的に同様であってもよい。
【００３６】
図１４は、ＥＣＡルールがポストされるステップ１４１０を示す。すなわち、図３を参照して上に説明したように、１つ以上のＥＣＡルールが受信され、ＥＣＡテーブル１４２０に記憶される。ＥＣＡテーブル１４２０は、図４のＥＣＡテーブル４００と実質的に同様であってもよい。
【００３７】
本明細書で開示するように、制御プレーン機能をネットワーク要素にオフロードすることは、種々の方法で行うことができる。一実施形態では、ステートフルデータプレーンおよび制御プレーンアプリケーションは、共通の実行環境を使用して（例えば、オープン・サービス・ゲートウェイ・イニシアティブ（ＯＳＧＩ）フレームワークを使用するバンドルとして）、転送要素にプッシュされてもよい。バークレー拡張ソフトウェアスイッチ（ＢＥＳＳ）またはベクトル・パケット・プロセッシング（ＶＰＰ）を用いて、パケット・パイプラインにステートフル・モジュールを挿入することもできる。これらの実施形態のすべては、入力パケットがバンドルによって選択的に処理されるように、機能をチェーン化する能力を提供する。制御機能は、チェーンの一部であってもよく、エンティティコントローラにバンドルされた制御されたエンティティとして露出されてもよい。そのような実装は、限定された用途しか有していないかも知れない。かかる機能は入ってくるフローパケットによって駆動されるからである。リンクアップ／ダウンイベントや制御信号のような、データプレーントラフィックフローにより変更されない状態が、ネットワーク要素上に存在してもよい。
【００３８】
同様の機能性は、ネットワーク要素の制御ファブリック（例えば、コンテナとして）で実行されるように実際のコードをプッシュすることによって得ることができる。リモートコントローラは、（パケット処理パイプラインへのモジュールのロードまたはアンロードとは対照的に）コードをネットワーク要素にロードまたはアンロードして制御プレーンを変更することができる。このような実施形態は、各機能が、機能を超えて露出されないそれ自身の有限状態マシンを維持し得るので、グローバル管理目標に関して管理がより困難であり得る。たとえば、２つの関数がトリガとして同じイベントを受け取り、そのトリガに基づいてローカル制御動作を実行すると、レース状態となり得る。逆に、異なるイベントトリガを受け取る２つの関数は、一貫性のない方法で転送パイプラインをプログラムしようとし得る。このような問題を管理するために、ネットワーク要素上のポリシー競合メカニズムを考案するよりも、リモートネットワークコントローラにそのような競合を検出して回避させ、各ネットワーク要素を一貫したポリシーでプログラムすることが好ましい場合がある。開示の実施形態は、リモートコントローラがポリシールールおよびＦＳＭルールを明示的にプログラムすることを可能にするので、これらの目的を達成する直接的な方法を提供する。開示の実施形態は、ポリシールールの更新がバイナリコードの更新よりも速いため、ダイナミックプログラミングにも適している。
【００３９】
１つ以上の実施形態は、フロールールの変更、フローメーターの読み取り、またはフロー優先度の変更などの制御プレーン命令の実行を可能にする。１つ以上の実施形態では、リモート制御プレーンは、ネットワーク要素の制御プレーンにオフロードされる。さらに、１つ以上の実施形態では、ＦＳＭは、データプレーンパケットのみによって駆動されるのではなく、ネットワーク要素上の実質的に任意の観測可能な状態によって駆動される。ローカルに記憶されたレシピを使用して、ある状態から別の状態へリソースを移動することに基づいている開示の命令セットは、既存のシステムには存在しない。
【００４０】
図１５は、ホスト装置内にインストールされ得る、本明細書に説明の方法を実行する一実施形態による処理システム１５００のブロック図を示す。図示のように、処理システム１５００は、プロセッサ１５０４、メモリ１５０６、およびインターフェース１５１０ないし１５１４を含み、これらは、図示のように構成されても（構成されていなくても）よい。プロセッサ１５０４は、計算および／または他の処理関連タスクを実行するように構成された任意のコンポーネントまたはコンポーネントの集まりであってもよく、メモリ１５０６は、プロセッサ１５０４による実行のためのプログラミングおよび／または命令を記憶するように構成された任意のコンポーネントまたはコンポーネントの集まりであってもよい。一実施形態では、メモリ１５０６は、命令１５２５を記憶する非一時的コンピュータ読取り可能媒体を含む。命令１５２５は、プロセッサ１５０４によって実行され得る。インターフェース１５１０、１５１２、１５１４は、処理システム１５００が他の装置／コンポーネントおよび／またはユーザと通信することを可能にする任意のコンポーネントまたはコンポーネントの集まりであってもよい。例えば、１つ以上のインターフェース１５１０、１５１２、１５１４は、プロセッサ１５０４からのデータ、制御、または管理メッセージをホスト装置および／またはリモート装置にインストールされたアプリケーションに通信するように構成されてもよい。別の例として、インターフェース１５１０、１５１２、１５１４のうちの１つ以上は、ユーザまたはユーザ装置（例えば、パーソナルコンピュータ（ＰＣ）など）が処理システム１５００と対話／通信することを可能にするように構成されてもよい。処理システム１５００は、長期記憶（例えば、不揮発性メモリなど）のような、図に示されていない追加のコンポーネントを含んでもよい。
【００４１】
いくつかの実施形態では、処理システム１５００は、電気通信ネットワークにアクセスしているか、またはその一部であるネットワーク装置に含まれる。一例において、処理システム１５００は、基地局、中継局、スケジューラ、コントローラ、ゲートウェイ、ルータ、アプリケーションサーバ、または電気通信ネットワーク内のその他の任意の装置のような、無線または有線電気通信ネットワーク内のネットワーク装置にある。他の実施形態では、処理システム１５００は、移動局、ユーザ機器（ＵＥ）、パーソナルコンピュータ（ＰＣ）、タブレット、ウェアラブル通信装置（例えば、スマートウォッチなど）、または電気通信ネットワークにアクセスするように構成されたその他の装置のような、無線または有線電気通信ネットワークにアクセスするユーザ装置内にある。
【００４２】
一実施形態では、処理システム１５００は、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングするモデルモジュールと、遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードするオフロードモジュールであって、そのサブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御に適した、選択された遷移を含むオフロードモジュールと、遷移のサブセット内にない他の遷移をリモート制御する遷移モジュールとを含む。いくつかの実施形態において、処理システム１５００は、実施形態で説明するステップのいずれか１つまたはステップの組み合わせを実行する、他のまたは追加のモジュールを含んでもよい。さらに、本方法の追加または代替の実施形態または態様のいずれも、図面のどれかに示されるか、または請求項のどれかに記載されるように、同様のモジュールを含むことが想定される。
【００４３】
いくつかの実施形態では、インターフェース１５１０、１５１２、１５１４のうちの１つ以上は、通信ネットワークを介して信号を送受信するように構成されたトランシーバに処理システム１５００を接続する。図１６は、電気通信ネットワークを介して信号を送受信するように構成されたトランシーバ１６００を示すブロック図である。トランシーバ１６００は、ホスト装置にインストールされてもよい。図示のように、トランシーバ１６００は、ネットワーク側インターフェース１６０２、カップラー１６０４、送信機１６０６、受信機１６０８、信号プロセッサ１６１０、および装置側インターフェース１６１２を含む。ネットワーク側インターフェース１６０２は、無線または有線電気通信ネットワークを介して信号を送信または受信するように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。カップラー１６０４は、ネットワーク側インターフェース１６０２を介して双方向通信を容易にするように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。送信機１６０６は、ベースバンド信号をネットワーク側インターフェース１６０２を介して送信するのに適した変調搬送波信号に変換するように構成された任意のコンポーネントまたはコンポーネントの集まり（例えば、アップコンバータ、電力増幅器など）を含んでもよい。受信機１６０８は、ネットワーク側インターフェース１６０２を介して受信した搬送波信号をベースバンド信号に変換するように構成された任意のコンポーネントまたはコンポーネントの集まり（例えば、ダウンコンバータ、低ノイズ増幅器など）を含んでもよい。信号プロセッサ１６１０は、ベースバンド信号を装置側インターフェース１６１２を介しての通信に適したデータ信号に、またはその逆に変換するように構成された任意のコンポーネントまたはコンポーネントの集まりを含んでもよい。装置側インターフェース１６１２は、信号プロセッサ１１１０とホスト装置内のコンポーネント（例えば、処理システム１５００、ローカルエリアネットワーク（ＬＡＮ）ポートなど）との間でデータ信号を通信するように構成された任意のコンポーネントまたはコンポーネントの集合を含んでもよい。
【００４４】
いくつかの実施形態では、処理システム１５００は、ネットワーク要素の動作状態間の遷移を制御する状態マシンをモデリングし、その遷移のサブセットを制御する状態マシンの一部をネットワーク要素にオフロードし、そのサブセットは、リモート制御アプリケーションによるリモート制御よりもネットワーク要素によるローカル制御に適した選択された遷移を含み、その遷移のサブセット内にない他の遷移をリモート制御する。
【００４５】
トランシーバ１６００は、任意のタイプの通信媒体を介して信号を送受信することができる。いくつかの実施形態では、トランシーバ１６００は、無線媒体を介して信号を送受信する。例えば、トランシーバ１６００は、セルラプロトコル（例えば、ロングタームエボリューション（ＬＴＥ）など）、無線ローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、Ｗｉ−Ｆｉなど）、または任意の他のタイプの無線プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、近接場通信（ＮＦＣ）など）などの無線電気通信プロトコルに従って通信するように構成された無線トランシーバであってもよい。このような実施形態では、ネットワーク側インターフェース１６０２は、１つ以上のアンテナ／放射素子を含む。例えば、ネットワーク側インターフェース１６０２は、単一のアンテナ、複数の別個のアンテナ、または多層通信、例えば、単一入力多重出力（ＳＩＭＯ）、多重入力単一出力（ＭＩＳＯ）、多重入力多重出力（ＭＩＭＯ）などに構成されたマルチアンテナアレイを含んでいてもよい。他の実施形態では、トランシーバ１６００は、有線媒体、例えば、ツイストペアケーブル、同軸ケーブル、光ファイバなどを介して信号を送受信する。処理システム及び／又はトランシーバによっては、図示したすべてのコンポーネントを利用してもよいし、コンポーネントの一部のみを利用してもよく、集積レベルは装置ごとに変わっても良い。
【００４６】
言うまでもなく、本明細書に提供される実施形態による方法の１つ以上のステップは、対応するユニットまたはモジュールによって実施可能である。例えば、信号は、送信ユニットまたは送信モジュールによって送信されてもよい。信号は、受信ユニットまたは受信モジュールによって受信されてもよい。信号は、処理ユニットまたは処理モジュールによって処理されてもよい。他のステップは、モデリングユニット／モジュール、オフローディングユニット／モジュール、制御ユニット／モジュール、および／または準備ユニット／モジュールによって実行されてもよい。各ユニット／モジュールは、ハードウェア、ソフトウェア、またはそれらの組み合わせであってもよい。例えば、ユニット／モジュールのうちの１つ以上は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）などの集積回路であってもよい。
【００４７】
本発明を例示の実施形態を参照して説明したが、この説明は限定を意図したものではない。例示の実施形態のさまざまな修正や組み合わせ、及び本発明のその他の実施形態は、当業者にはこの説明を参照すれば明らかになるだろう。それゆえ、添付した特許請求の範囲はかかる修正や実施形態を含むことを意図したものである。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図１
【補正方法】変更
【補正の内容】
【図１】
2020502880.tif 000019
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】変更
【補正の内容】
【図３】
2020502880.tif 000020
【国際調査報告】
2020502880.tif 000021
2020502880.tif 000022