(57)【要約】本明細書では、Ｍ２Ｍ／ＩｏＴネットワークへの既存のアプローチはネットワーク機能仮想化（ＮＦＶ）を実現しないことが認識される。特に、既存のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）は、ＮＦＶ実践に従って構築、管理、または動作させられない。例示的実施形態では、Ｍ２Ｍ装置は、共通サービス機能が互いに一緒にプールされることができるように、種々の役割を種々の共通サービスエンティティに割り当てる。役割は、プールが効率的に管理および制御されることを確実にするように、共通サービスエンティティの間で移行されることができる。さらに、プールメンバは、１つ以上のプールから脱退および加入することができる。
2019514118.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介してマシンツーマシン（Ｍ２Ｍ）ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
要求を複数の共通サービスエンティティに送信することと、
前記要求に応答して、前記複数の共通サービスエンティティから複数の応答を受信することであって、各応答は、それぞれの共通サービスエンティティ（ＣＳＥ）が共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）であることが可能かどうかに関連する情報を含む、ことと、
各応答からの前記情報を評価し、前記複数の共通サービスエンティティから少なくとも１つのＣＰＣを選択することと
を含む動作を前記装置に実施させる、装置。
【請求項２】
前記要求は、各ＣＳＥの現在の容量および各ＣＳＥが自発的に前記ＣＰＣになるかどうかについてクエリを行う、請求項１に記載の装置。
【請求項３】
前記装置は、命令をさらに備え、前記命令は、
前記少なくとも１つのＣＰＣのための役割プロファイルを生成することを含むさらなる動作をノードに実施させ、
前記役割プロファイルは、前記ＣＰＣの仮想マシンのための最小性能要件、前記ＣＰＣの前記仮想マシンのための好ましい実施時間、役割移行計画、および役割ソフトウェア更新スケジュールのうちの少なくとも１つを備えている、請求項１−２のいずれか１項に記載の装置。
【請求項４】
前記装置は、複数のＣＳＦプールコントローラを選択し、前記役割プロファイルは、前記ＣＳＦプールコントローラの各々に関連付けられた稼働時間をさらに備えている、請求項３に記載の装置。
【請求項５】
前記装置は、命令をさらに備え、前記命令は、
前記役割プロファイルを前記複数の共通サービスエンティティのうちの少なくとも１つのＣＳＥに送信することを含むさらなる動作を前記装置に実施させる、請求項３および４のいずれか１項に記載の装置。
【請求項６】
前記装置は、命令をさらに備え、前記命令は、
前記役割プロファイルに応答して、前記少なくとも１つのＣＳＥから確認応答を受信することを含むさらなる動作を前記装置に実施させ、
前記確認応答は、前記少なくとも１つのＣＳＥが、前記役割プロファイルで示されるように、その仮想マシンリソースを取っておき始めるであろうことを示す、請求項５に記載の装置。
【請求項７】
前記装置は、命令をさらに備え、前記命令は、
ソフトウェアパッケージを前記少なくとも１つのＣＳＥに展開することを含むさらなる動作を前記装置に実施させ、
前記パッケージは、前記少なくとも１つのＣＳＥが、前記ＣＰＣであるようにそれ自体を構成することを可能にする、請求項６に記載の装置。
【請求項８】
前記装置は、命令をさらに備え、前記命令は、
指示を前記少なくとも１つのＣＳＥに送信することを含むさらなる動作を前記装置に実施させ、
前記指示は、前記少なくとも１つのＣＳＥが、前記ＣＰＣであるようにそれ自体を構成することを可能にする、請求項６に記載の装置。
【請求項９】
前記役割プロファイルは、バックアップＣＳＥとして前記共通サービスエンティティのうちの１つを識別し、それによって、前記少なくとも１つのＣＰＣは、前記ＣＰＣの役割を前記バックアップＣＳＥに移行させることができる、請求項７および８のいずれか１項に記載の装置。
【請求項１０】
前記装置は、命令をさらに備え、前記命令は、
前記少なくとも１つのＣＰＣからメッセージを受信することであって、前記メッセージは、前記ＣＳＥがもはや前記ＣＰＣであることが可能でないことを示す、ことと、
前記メッセージに応答して、請求項１−８のいずれか１項に記載の動作を繰り返すことと
を含むさらなる動作を前記装置に実施させる、請求項７および８のいずれか１項に記載の装置。
【請求項１１】
プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介してマシンツーマシン（Ｍ２Ｍ）ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
要求を複数の共通サービスエンティティに送信することと、
前記要求に応答して、前記複数の共通サービスエンティティから複数の応答を受信することであって、各応答は、それぞれの共通サービスエンティティ（ＣＳＥ）が共通サービス機能（ＣＳＦ）プールマネージャ（ＣＰＭ）であることが可能かどうかに関連する情報を含む、ことと、
各応答からの前記情報を評価し、前記複数の共通サービスエンティティから少なくとも１つのＣＰＭを選択することと
を含む動作を前記装置に実施させる、装置。
【請求項１２】
前記要求は、各ＣＳＥの現在の容量および各ＣＳＥが自発的に前記ＣＰＭになるかどうかについてクエリを行う、請求項１１に記載の装置。
【請求項１３】
前記装置は、命令をさらに備え、前記命令は、
前記少なくとも１つのＣＰＭのための役割プロファイルを生成することを含むさらなる動作を前記装置に実施させ、
前記役割プロファイルは、前記ＣＰＭの仮想マシンのための最小性能要件、前記ＣＰＭの前記仮想マシンのための好ましい実施時間、役割移行計画、および役割ソフトウェア更新スケジュールのうちの少なくとも１つを備えている、請求項１１および１２のいずれか１項に記載の装置。
【請求項１４】
前記装置は、複数のＣＳＦプールマネージャを選択し、前記役割プロファイルは、前記ＣＳＦプールマネージャの各々に関連付けられた稼働時間をさらに備えている、請求項１３に記載の装置。
【請求項１５】
前記装置は、命令をさらに備え、前記命令は、
前記役割プロファイルを前記複数の共通サービスエンティティのうちの少なくとも１つのＣＳＥに送信することを含むさらなる動作を前記装置に実施させる、請求項１３および１４のいずれか１項に記載の装置。
【請求項１６】
前記装置は、命令をさらに備え、前記命令は、
前記役割プロファイルに応答して、前記少なくとも１つのＣＳＥから確認応答を受信することを含むさらなる動作を前記装置に実施させ、
前記確認応答は、前記少なくとも１つのＣＳＥが、前記役割プロファイルで示されるように、その仮想マシンリソースを取っておき始めるであろうことを示す、請求項１５に記載の装置。
【請求項１７】
前記装置は、命令をさらに備え、前記命令は、
ソフトウェアパッケージを前記少なくとも１つのＣＳＥに展開することを含むさらなる動作を前記装置に実施させ、
前記パッケージは、前記少なくとも１つのＣＳＥが、前記ＣＰＭであるようにそれ自体を構成することを可能にする、請求項１６に記載の装置。
【請求項１８】
前記装置は、命令をさらに備え、前記命令は、
指示を前記少なくとも１つのＣＳＥに送信することを含むさらなる動作を前記装置に実施させ、
前記指示は、前記少なくとも１つのＣＳＥが、前記ＣＰＭであるようにそれ自体を構成することを可能にする、請求項１６に記載の装置。
【請求項１９】
前記装置は、命令をさらに備え、前記命令は、
ＣＳＦプールコントローラ（ＣＰＣ）である別のＣＳＥの識別を前記少なくとも１つのＣＳＥに知らせることを含むさらなる動作を前記装置に実施させ、
それによって、前記少なくとも１つのＣＳＥは、前記ＣＰＣである前記ＣＳＥにコンタクトすることができる、請求項１７および１８のいずれか１項に記載の装置。
【請求項２０】
前記装置は、命令をさらに備え、前記命令は、
ＣＳＦプールマネージャ（ＣＰＭ）である別のＣＳＥの識別を前記少なくとも１つのＣＳＥに知らせることを含むさらなる動作を前記装置に実施させ、
それによって、前記少なくとも１つのＣＳＥは、前記ＣＰＭである前記ＣＳＥにコンタクトすることができる、請求項７および８のいずれか１項に記載の装置。
【請求項２１】
プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介してマシンツーマシン（Ｍ２Ｍ）ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
共通サービスエンティティ（ＣＳＥ）から要求を受信することであって、前記要求は、前記ＣＳＥが、自発的にあるタイプのプールに加入する前記あるタイプの１つ以上の共通サービス機能（ＣＳＦ）インスタンスを含むことを示す、ことと、
レジストリリストから、前記要求を知らされるべき１つ以上のＣＳＦプールマネージャを決定することであって、前記１つ以上のＣＳＦプールマネージャは、前記あるタイプのそれぞれのプールに関連付けられている、ことと、
通知を前記１つ以上のＣＳＦプールマネージャのうちの少なくとも１つに送信することであって、前記通知は、前記ＣＳＥの前記１つ以上のＣＳＦインスタンスが、前記少なくとも１つのＣＳＦプールマネージャによって管理されている前記それぞれのプールに加入することを申請していることを示す、ことと
を含む動作を前記装置に実施させる、装置。
【請求項２２】
プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介してマシンツーマシン（Ｍ２Ｍ）ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
要求を共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）に送信することであって、前記要求は、前記装置が、自発的にあるタイプのプールに加入する前記あるタイプの１つ以上のＣＳＦインスタンスを含むことを示す、ことと、
前記要求に基づいて、ＣＳＦプールマネージャ（ＣＰＭ）からメッセージを受信することであって、前記メッセージは、前記１つ以上のＣＳＦインスタンスが前記ＣＰＭによって管理されることを示す、ことと
を含む動作を前記装置に実施させる、装置。
【請求項２３】
前記装置は、命令をさらに備え、前記命令は、
前記メッセージに応答して、前記装置に関連付けられた性能データを備えている確認応答メッセージを送信することを含むさらなる動作を前記装置に実施させる、請求項２２に記載の装置。
【請求項２４】
プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介してマシンツーマシン（Ｍ２Ｍ）ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）から通知を受信することであって、前記通知は、共通サービスエンティティ（ＣＳＥ）の１つ以上のＣＳＦインスタンスが、前記装置によって管理されているプールに加入することを申請していることを示す、ことと、
前記１つ以上のＣＳＦインスタンスが前記プールに加入することを承認されると、将来の使用のために、前記１つ以上のＣＳＦインスタンスを在庫リストに追加することと
を含む動作を前記装置に実施させる、装置。
【請求項２５】
前記装置は、命令をさらに備え、前記命令は、
メッセージを前記ＣＳＥに送信することを含むさらなる動作を前記装置に実施させ、
前記メッセージは、前記１つ以上のＣＳＦインスタンスが前記装置によって管理されることを示す、請求項２４に記載の装置。
【請求項２６】
前記装置は、命令をさらに備え、前記命令は、
前記ＣＳＥに送信される前記メッセージに応答して、前記ＣＳＥから確認応答メッセージを受信することを含むさらなる動作を前記装置に実施させ、
前記確認応答メッセージは、前記ＣＳＥに関連付けられた性能データを備えている、請求項２５に記載の装置。
【請求項２７】
前記装置は、命令をさらに備え、前記命令は、
前記在庫リストを更新し、前記ＣＳＥに関連付けられる前記性能データを含むことを含むさらなる動作を前記装置に実施させ、
それによって、前記性能データは、前記装置がサービス層要求を処理するために前記１つ以上のＣＳＦインスタンスを割り当てること、またはそれらを呼び出すことを意図するとき、参照されることができる、請求項２６に記載の装置。
【請求項２８】
前記装置は、命令をさらに備え、前記命令は、
削除通知を前記ＣＳＥに送信することを含むさらなる動作を前記装置に実施させ、
前記削除通知は、前記１つ以上のＣＳＦインスタンスが前記プールから削除されることを示す、請求項２４−２７のいずれか１項に記載の装置。
【請求項２９】
前記削除通知は、前記ＣＳＥの１つ以上の履歴性能統計に基づいて送信される、請求項２８に記載の装置。
【請求項３０】
前記装置は、命令をさらに備え、前記命令は、
前記ＣＳＥから削除確認応答を受信することを含むさらなる動作を前記装置に実施させ、
前記削除確認応答は、前記ＣＳＥが、前記１つ以上のＣＳＦインスタンスが前記プールから削除されることを認識していることを示す、請求項２８および２９のいずれか１項に記載の装置。
【請求項３１】
前記装置は、命令をさらに備え、前記命令は、
前記ＣＳＥから削除通知を受信することを含むさらなる動作を前記装置に実施させ、
前記削除通知は、前記１つ以上のＣＳＦインスタンスが前記プールから離脱することを要求していることを示す、請求項２４−２７のいずれか１項に記載の装置。
【請求項３２】
前記削除通知は、前記１つ以上のＣＳＦインスタンスがそれに割り当てられた処理をサポートすることができないという前記ＣＳＥの決定に基づいて送信される、請求項３１に記載の装置。
【請求項３３】
前記装置は、命令をさらに備え、前記命令は、
前記プールから前記１つ以上のＣＳＦインスタンスを削除することを含むさらなる動作を前記装置に実施させる、請求項３１−３２のいずれかに記載の装置。
【発明の詳細な説明】
【背景技術】
【０００１】
（関連出願の引用）
本願は、米国仮特許出願第６２／３１８，４０１号（２０１６年４月５日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により引用される。
【０００２】
（背景）
一般に、ネットワーク機能仮想化（ＮＦＶ）は、ネットワークオペレータが、進化しつつある標準ＩＴ仮想化技術を介してネットワークを設計する方法を変換することを目指す。ＮＦＶは、データセンタ、ネットワークノード、およびエンドユーザ敷地に位置することができる、業界標準大容量サーバ、スイッチ、ならびに記憶装置上への種々のタイプのネットワーク機器の統合を可能にし得る。図１は、例示的典型的（非仮想化）ネットワークと比較して、ＮＦＶの実施例を示す。典型的には、ＮＦＶは、一連の業界標準サーバハードウェア上で起動することができ、新しい機器のインストールの必要なく、要求に応じて、ネットワーク内の種々の場所に移動される、またはそこでインスタンス化されることができる、ソフトウェアにおけるネットワーク機能の実装を伴う。
【０００３】
従来、非仮想化ネットワーク内で、ネットワーク機能（ＮＦ）は、概して、ネットワークノードまたはネットワーク要素と称されることができる、ベンダ特有のソフトウェアおよびハードウェアの組み合わせとして実装される。ＮＦＶでは、ＮＦは、以下に詳細に説明される仮想化技術を通して実現されることができる。典型的には、ＮＦＶは、仮想化ネットワーク機能（ＶＮＦ）と呼ばれる、ソフトウェアのみのインスタンスとしてのＮＦの実装を構想する。ＶＮＦは、同等ネットワーク機能と同一の機能的挙動およびインターフェースを提供することができるが、これは、例えば、仮想マシン（ＶＭ）の上にソフトウェアインスタンスとして展開され得る。
【０００４】
ＶＮＦは、ＮＦＶインフラストラクチャ（例えば、物理的コンピューティングリソース、ネットワークリソース、および記憶リソース）にわたって起動する。図２は、種々のＮＦが複数の仮想化マシン（ＶＭ）上に展開され、ＶＭがハイパーバイザの上で起動する、ＮＦＶの例示的実装図を示す。ハイパーバイザは、複数のＶＭが単一のハードウェアインフラストラクチャを共有することを可能にするプログラムであり得る、ＶＭマネージャであり得る。例えば、所与のハイパーバイザは、複数のＶＭとしての下層単一物理マシンを抽象化することに役立ち得る。したがって、ＮＦＶは、ハードウェアからソフトウェアを分断し、ネットワーク機能の柔軟な展開を達成し、概して、動的な動作を促進することに役立ち得る。
【０００５】
ハードウェアからソフトウェアを分断することに関して、ネットワーク要素が、もはや統合ハードウェアおよびソフトウェアエンティティの集合ではないため、ハードウェアおよびソフトウェアの進化は、相互から独立し得る。本独立性は、ソフトウェアがハードウェアとは別個に進歩すること、および逆も同様に可能にし得る。さらに、例えば、ハードウェアからのソフトウェアの脱離は、インフラストラクチャリソース（例えば、物理的コンピューティングおよび記憶リソース）を再び割り当て、共有することに役立つ。したがって、ハードウェアおよびソフトウェアは、種々の時間に異なる機能を果たすことができる。さらなる実施例として、インスタンス化可能なソフトウェアコンポーネントの中へのネットワーク機能の機能性の分断は、より動的な方法において、より細かい粒度で、例えば、ネットワークオペレータが容量をプロビジョニングする必要がある実際のトラフィックに従って、実際のＶＮＦ性能をスケーリングするためのさらなる融通性を提供する。
【０００６】
したがって、ネットワーク機能仮想化（ＮＦＶ）は、ネットワークオペレータ（ＮＯ）によって直面される、少なくとも２つの問題、すなわち、１）費用を収益成長期待と一致させること、および２）サービス速度を向上させることを明示的に標的とする。ＮＦＶは、歴史的なネットワークアプローチと比較して、より効果的にリソースを利用し、運営支出（ＯｐＥＸ）および資本支出（ＣａｐＥＸ）の削減を達成することができる。例えば、ＮＯは、技術者を各現場に送る必要なく、ネットワーク機能を展開することができる。その間にも、ＮＦＶは、例えば、従来の機能性特有のネットワークアプライアンスを使用する代わりに、サービスが任意の業界標準サーバハードウェア上のソフトウェアを介して配信されることを可能にすることによって、革新をサポートすることに役立つことができる。ＮＦＶ技術は、例えば、ＮＯが（仮想化を通して）異なるサービスを迅速に拡大または縮小し、種々の変化する需要に対処し得るため、ネットワークアジリティ、プログラム可能性、および融通性を達成することに役立ち得る。ＮＦＶは、市場化時間を加速し得る。例えば、ＮＯは、新しいネットワーキングサービスを展開して、変化するビジネス要件をサポートする時間を短縮し、新しい市場機会を捉え、新しいサービスの投資利益率を向上させることができる。また、ＮＯは、新しいサービスを公開することに関連付けられるリスクを減らし、プロバイダが、サービスを容易に試験し、進化させ、顧客の必要性を最良に満たすものを決定することを可能にし得る。なおもさらに、ＮＦＶを通して、サービスプロバイダ（ＳＰ）は、ハードウェアおよびソフトウェア故障に対する適切なレベルの回復力を向上させ、確実にし得る。
【０００７】
ここでシステム実装を参照すると、ＶＮＦの使用は、提供されたサービスの信頼性に追加の課題を提起し得る。例えば、ＶＮＦインスタンスは、典型的には、そのホスト（例えば、汎用サーバ）上に内蔵信頼性機構を有していない。結果として、ハイパーバイザ、仮想マシン、ＶＮＦインスタンス、ハードウェア故障等を含む、種々のレベルにおけるソフトウェア故障等のリスク因子が存在し得る。
【０００８】
より高い信頼性を達成するために、ＶＮＦプールアーキテクチャと称され得るアーキテクチャは、それらの機能を提供するプールとしてグループ化される、同一の機能を有する複数のＶＮＦインスタンスを含むことができる。概念的に、プールマネージャ（ＰＭ）は、あるタイプのＮＦのためのＶＮＦプールを管理し得る。例えば、ＰＭは、アクティブである、またはスタンバイしているＶＮＦインスタンス（プールメンバ）を選択し得、ＰＭは、サービス制御エンティティ（ＳＣＥ）と相互作用し得る。ＳＣＥは、ネットワーク機能（例えば、ＶＮＦ）のセットを組み合わせ、編成して種々のネットワークサービスを構築する、エンティティを指す。ＶＮＦプールを使用することの利益は、冗長性管理等の信頼性機構が、ＶＮＦプールによって達成され、したがって、ＳＣＥおよびそれらのＶＮＦインスタンスの外部ユーザに透過的であることである。
【０００９】
図３を参照すると、例示的ＶＮＦプールアーキテクチャ３００が、示される。ＶＮＦプールアーキテクチャ３００は、ネットワーク機能を組み合わせ、編成してネットワークサービスを構築する方法を決定する、サービスプロバイダの論理エンティティである、例示的サービス制御エンティティ３０２を含む。ＶＮＦプールアーキテクチャ３００はさらに、第１の例示的ＶＮＦ（ネットワーク機能「Ａ」に関するＶＮＦ  Ａ）と、第２の例示的ＶＮＦ（ネットワーク機能「Ｂ」に関するＶＮＦ  Ｂ）とを含む。論理エンティティであり得る、所与のＶＮＦは、同等ネットワーク機能と同一である、具体的な機能的挙動およびインターフェースを提供し得る。各ＶＮＦは、ソフトウェアインスタンスとして実装され得る。さらに、図示される実施例によると、ＶＮＦ  ＡおよびＶＮＦ  Ｂは、相互と比較して、異なる機能を有し得る。示されるように、ＶＮＦ  Ａは、プール（ＶＮＦ−Ａプール）を含み、ＶＮＦ  Ｂは、プール（ＶＮＦ−Ｂプール）を含む。いくつかの場合では、各タイプのＶＮＦは、プールメンバがＶＮＦを実装するソフトウェアインスタンスである、対応するプールを有する。例えば、示されるように、ＶＮＦ−Ａプールは、ＶＮＦ−Ａ（例えば、ＶＮＦ−Ａ＃１等）を実装する種々のインスタンスを含み、ＶＮＦ−Ｂプールは、ＶＮＦ−Ｂ（ＶＮＦ−Ｂ＃１等）を実装する種々のインスタンスを含む。ＶＮＦプールマネージャは、ＶＮＦプールを管理するエンティティであり得る。管理するステップは、プールメンバを呼び出し、スケジューリングするステップを含み得る（以下に説明される）。管理するステップはまた、ＳＣＥ３０２と相互作用し、所与のネットワーク機能を提供するステップを含み得る。示されるように、実施例として、第１のＰＭ３０６ａは、ＶＮＦプール３０４ａ（ＶＮＦ  Ａに対応する）を管理し、第２のＰＭ３０６ｂは、ＶＮＦプール３０４ｂ（ＶＮＦ  Ｂに対応する）を管理する。プールメンバは、対応するＶＮＦプールに加入し、ＰＭによって管理される、物理的ＮＦインスタンスを指し得る。実施例として、プールメンバは、ＣＳＥ上でホストされる、または起動する、ＣＳＦもしくはサービス能力ソフトウェアインスタンスであり得る。さらなる実施例として、図３に示されるように、ＶＮＦ−ＡおよびＶＮＦ−Ｂを実装するソフトウェアインスタンスは、それぞれ、ＶＮＦ−ＡプールおよびＶＮＦ−Ｂプールのプールメンバである。
【００１０】
ここで、概して、データセンタおよびクラウドコンピューティングに目を向けると、仮想化技術は、多くの場合、特に、データセンタおよびクラウドコンピューティングについて、他の概念ならびにトピックに関連する。一般に、データセンタは、電気通信および記憶システム等のコンピュータシステムならびに関連付けられるコンポーネントを収納するために使用される設備である。データセンタは、概して、冗長またはバックアップ電力供給源、冗長データ通信接続、環境制御（例えば、空調、火災鎮圧）、および種々のセキュリティデバイスを含む。データセンタと対照的に、クラウドコンピューティングは、急速にプロビジョニングされ、最小限の管理努力またはサービスプロバイダ相互作用を伴ってリリースされることができる、構成可能コンピューティングリソース（例えば、ネットワーク、サーバ、記憶装置、アプリケーション、およびサービス）の共有プールへのユビキタス、便宜的、オンデマンドネットワークアクセスを可能にするためのモデルである。クラウドコンピューティングは、多くの場合、以下の特性、すなわち、１）オンデマンドセルフサービス、２）広いネットワークアクセス、３）リソースプーリング、４）急速弾性、および５）測定されたサービス等を有する。主要なサービスモデルは、サービスとしてのソフトウェア（ＳａａＳ）、サービスとしてのプラットフォーム（ＰａａＳ）、サービスとしてのインフラストラクチャ（ＩａａＳ）等を含む。
【００１１】
上で説明されるように、両方のタイプのコンピューティングシステム（データセンタおよびクラウドコンピューティング）が、物理的単位としてデータを格納することができ、データセンタのみが、サーバおよび他の機器を格納する。したがって、クラウドサービスプロバイダ（例えば、Ｇｏｏｇｌｅ、Ａｍａｚｏｎ等）は、多くの場合、データセンタを使用し、クラウドサービスおよびクラウドベースのリソースを収納する。クラウドとデータセンタとの間の差異は、クラウドが、典型的には、（プライベートクラウドが敷地内または敷地外のいずれかで展開され得ることが提案されているが）インターネット上の敷地外形態のコンピューティングである一方で、組織が、多くの場合、組織のローカルネットワーク内に敷地内データセンタを有することである。例えば、企業がサードパーティ（例えば、Ｇｏｏｇｌｅ、Ａｍａｚｏｎ等）によって提供されるクラウドサービスを追求するとき、それらのサービスは、サードパーティによって構築されるデータセンタ内で起動されるサービスインスタンスによってプロビジョニングされる（そのような場合は、敷地外サービスプロビジョニングと称される）。したがって、企業は、「利用時払い」、融通性、および拡張性等の利益を伴うサービスを十分に利用し得る。比較すると、企業はまた、それら独自のデータセンタを購入し、それをローカルで運営することを選定し得る。言い換えると、クラウドコンピューティングは、サービスプロビジョニングの形態と考えられ得、データセンタは、クラウドベースのサービスを実現するために使用されることができる、物理的施設を指し得る。現在、クラウドサービスは、通常、全ての更新および進行中の保守を実施するサードパーティクラウドプロバイダに外部委託され、企業はまた、多くの場合、典型的には、自社内のＩＴ部門によって運営される、それらの独自のデータセンタに投資する。データセンタは、企業がオンデマンドでそれらのデータセンタインフラストラクチャを投資することができない限り、サービス拡張性または融通性特徴を有していない。
【００１２】
クラウドコンピューティングパラダイムは、以前の反復と比較して、異なる必要性に基づくさらなる変形例を含むように進化してきた。例えば、現在、エンドユーザおよび事業は、歴史的な要求と比較して、より良好なユーザ体験のために、電気通信業界からより多くを要求している。主要な変換は、（コアネットワーク内でサービスをプロビジョニングする代わりに）ネットワークエッジにおいて直接、サービスを運営および提供し、ＥＴＳＩによって初期化されるようなモバイルエッジコンピューティング（ＭＥＣ）と呼ばれる、クラウドコンピューティングの概念を適用する能力となっている。いくつかの場合では、ＭＥＣは、モバイルネットワークのエッジにおいて起動し、従来の集中型クラウド展開では達成され得ない具体的タスク（例えば、制御機能）を実施する、クラウドサーバ（例えば、Ｍ２Ｍゲートウェイ）と見なされることができる。図４は、ＭＥＣの実施例を描写する。ＭＥＣは、種々の特徴、例えば、１）敷地内コンピューティング、２）近接性、３）より少ない待ち時間、および４）場所認識を含み得る。
【００１３】
仮想化は、クラウドコンピューティングを実現するための主要なイネーブリング技術である。仮想化技術は、異なるカテゴリにカテゴリ化され得る。例えば、コンピューティング仮想化は、ユーザの必要性に基づいて、仮想マシンへの物理的コンピューティングおよび記憶リソース（例えば、サーバファーム）を仮想化する方法に焦点を当てるカテゴリである。ネットワーク仮想化は、物理的ネットワーク基板を複数の仮想ネットワークにスライスする方法、または複数のデータセンタネットワークを横断してネットワークを伸張する方法に焦点を当てるカテゴリである。実施例として、テナントがプライベート仮想化ネットワークを構築する必要があるとき、ネットワーク仮想化は、物理的基板ネットワークインフラストラクチャの上に本ネットワークの仮想リンクを構築することに関与し得る。具体的には、本仮想化ネットワーク内のノードまたはＶＭが（例えば、データセンタを横断して）異なる場所に移行もしくは移動される必要があるとき、ネットワーク仮想化は、どのように下層基板ネットワーク（例えば、物理的リンクまたはパス）が変更されたとしても、仮想化ネットワークの保守を担当する。ＮＦＶは、ソフトウェアアプライアンスを使用し、専用ハードウェアネットワークアプライアンスを置換する方法に焦点を当て得る、仮想化の別のカテゴリと見なされ得る。具体的には、ＮＦＶは、ＶＮＦインスタンスが上記で示されるようにＶＭの上に展開されることができるため、コンピューティング仮想化に関する。その間にも、ＮＦＶの焦点は、物理的ネットワークインフラストラクチャ上に、またはネットワーキング仮想化を通して仮想化ネットワーク上に適用されるであろうかどうかにかかわらず、より良好なネットワークサービスを提供するために、ネットワークを、より機敏、プログラム可能、柔軟、および拡張可能にすることである。
【００１４】
ここで図５を参照すると、例示的Ｍ２Ｍシステムアーキテクチャ５００が、示される。示されるように、Ｍ２Ｍシステム５００は、Ｍ２Ｍエンドデバイス５０４とＭ２Ｍゲートウェイ（ＧＷ）５０６との間のコネクティビティを提供する、Ｍ２Ｍエリアネットワーク５０２を含む。Ｍ２Ｍエリアネットワークの実施例は、ＩＥＥＥ  ８０２．１５、Ｚｉｇｂｅｅ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の技術に基づく、パーソナルエリアネットワークを含む。Ｍ２Ｍエンドデバイス５０４は、Ｍ２Ｍ  ＧＷ５０６およびアクセスネットワークまたはコアネットワーク５１２を介して、Ｍ２Ｍ  ＧＷ５０６ならびにＭ２Ｍサーバ５０８と通信することができ、これは、例えば、インターネット上にある、外部ネットワークならびにアプリケーションシステム５１０との相互作用および／またはインターフェースを可能にすることができる。多くのＭ２Ｍデバイス５０４は、例えば、感覚情報（例えば、湿度、温度等）を報告すること等のサービスを提供する、またはコントローラ（例えば、光スイッチ）として機能する、リソース制約されたエンティティである。Ｍ２Ｍデバイス５０４はまた、リソースが豊富なアプライアンスのタイプ（例えば、電力供給源を伴う家庭電化製品、携帯電話、車両、他の工業機器等）であり得る。
【００１５】
ここで図６を参照すると、典型的である、サービス層６０２がアプリケーションプロトコル層６０４の上方にある、例示的プロトコルスタック６００が、示される。サービス層６０２は、付加価値サービス（例えば、デバイス管理、データ管理等）をアプリケーション６０１または別のサービス層に提供し得る。したがって、サービス層は、多くの場合、「ミドルウェア」サービスとしてカテゴリ化される。
【００１６】
サービス層に関して、背景として、Ｍ２Ｍ／ＩｏＴノードに向けて標的とされたサービス層は、Ｍ２Ｍ／ＩｏＴサービス層と称されることができる。ネットワーク内のＭ２Ｍ／ＩｏＴサービス層インスタンスの例示的展開が、図７に示される。図示される実施例では、サービス層インスタンス７０２は、サービス層の実現である。複数のサービス層インスタンスは、付加価値サービスを、ネットワークアプリケーション、デバイスアプリケーション、およびネットワークノード自体に提供するための種々のネットワークノード（例えば、ゲートウェイおよびサーバ）上に展開され得る。業界標準団体（例えば、ｏｎｅＭ２Ｍ）は、Ｍ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションを既存のネットワークに統合することに関連付けられる種々の課題に対処するために、Ｍ２Ｍ／ＩｏＴサービス層を開発してきた。Ｍ２Ｍサービス層は、アプリケーションおよびデバイスに、サービス層によってサポートされるＭ２Ｍ指向サービス能力の集合へのアクセスを提供することができる。そのような能力の実施例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含む。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージプリミティブを利用し得る、アプリケーションプログラムインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能にされることができる。
【００１７】
ここでｏｎｅＭ２Ｍに目を向けると、背景として、ｏｎｅＭ２Ｍの目標は、分野内の多種多様なデバイスをサポートするようにハードウェア装置およびソフトウェアモジュール内に容易に埋設されることができる、共通サービス層の必要性に対処する、技術仕様を開発することである。ｏｎｅＭ２Ｍ共通サービス層は、図８で描写される例示的ｏｎｅＭ２Ｍアーキテクチャ８００によって示されるように、共通サービス機能（ＣＳＦ）（サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、および特定用途向けノード）上にホストされることができる、共通サービスエンティティ（ＣＳＥ）と称される。ＣＳＥは、ｏｎｅＭ２Ｍ  Ｆｕｎｃｔｉｏｎａｌ  Ａｒｃｈｉｔｅｃｔｕｒｅで定義されるように、それぞれ、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、およびＡＳＮ−ＣＳＥと称される。
【００１８】
標準団体ｏｎｅＭ２Ｍは、最初に、図９に示されるｏｎｅＭ２Ｍ  ＲＯＡ  ＲＥＳＴｆｕｌアーキテクチャ内で、異なるリソースが定義されるという意味で、リソース指向アーキテクチャ（ＲＯＡ）設計原理に準拠するサービス層を開発していた。リソースは、アーキテクチャ内の一意にアドレス指定可能な要素である。リソースは、作成、読出、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる。リソースは、ユニフォームリソース識別子（ＵＲＩ）を使用してアドレス指定可能である。リソースは、子リソースおよび属性を含み得る。
【００１９】
近年、ｏｎｅＭ２Ｍは、ＲＥＳＴｆｕｌベースではないレガシー展開を考慮するために、Ｍ２Ｍサービスコンポーネントアーキテクチャ（図１０に示される）を開発し始めた。本アーキテクチャは、主に、ＣＳＥがサービスコンポーネントのセットと見なされる、インフラストラクチャドメインに好適である。図１０に示されるアーキテクチャは、図９に示される既存のサービス層アーキテクチャを再利用するが、サービス層内では、これは、種々のＭ２Ｍサービスを含み、複数のサービスは、サービスコンポーネントにグループ化されることができる。既存の参照点に加えて、図１０に示されるアーキテクチャは、サービス間参照点Ｍｓｃを導入する。（Ｍｓｃ参照点を通り過ぎる）Ｍ２Ｍサービスコンポーネントの間の通信は、サービス指向アーキテクチャ（ＳＯＡ）ベースのソフトウェアシステムを構築するための最も頻用されている技術であり得る、ウェブサービスアプローチを利用する。
【００２０】
上記で議論されるように、ＮＦＶは、より良好なネットワークサービスを提供するための種々の利益を有する。しかしながら、Ｍ２Ｍ／ＩｏＴネットワークへの既存のアプローチは、ＮＦＶを実現しない。
【発明の概要】
【発明が解決しようとする課題】
【００２１】
（要約）
本概要は、発明を実施するための形態において以下にさらに説明される、簡略化された形態で一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することも、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
【００２２】
本明細書では、Ｍ２Ｍ／ＩｏＴネットワークへの既存のアプローチはネットワーク機能仮想化（ＮＦＶ）を実現しないことを認識されたい。具体的には、既存のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）は、ＮＦＶ実践に従って構築、管理、または動作されない。したがって、ＮＦＶの利益は、既存のサービス層では実現されない。
【課題を解決するための手段】
【００２３】
例示的実施形態では、Ｍ２Ｍノードは、要求を複数の共通サービスエンティティに送信する。要求は、各共通サービスエンティティ（ＣＳＥ）の現在の容量および各ＣＳＥが自発的に共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）またはＣＳＦプールマネージャ（ＣＰＭ）になるかどうかについてクエリを行い得る。要求に応答して、ノードは、複数の共通サービスエンティティから複数の応答を受信し、各応答は、それぞれのＣＳＥがＣＰＣまたはＣＰＭであることが可能かどうかに関連する情報を含む。サービスプロバイダであり得るノードは、各応答からの情報を評価し、複数の共通サービスエンティティから少なくとも１つのＣＰＣおよび少なくとも１つのＣＰＭを選択する。ノードは、少なくとも１つのＣＰＣのための役割プロファイルを生成し、役割プロファイルは、ＣＰＣの仮想マシンのための最小性能要件、ＣＰＣの仮想マシンのための好ましい実施時間、役割移行計画、および役割ソフトウェア更新スケジュールのうちの少なくとも１つを備えている。ノードは、同様に、ＣＰＭのための役割プロファイルを生成し得る。それぞれの役割プロファイルは、ＣＰＭであるように選択されるＣＳＥおよびＣＰＣであるように選択されるＣＳＥに送信され得る。ノードはさらに、それぞれのソフトウェアパッケージを、ＣＰＭであるように選択されるＣＳＥおよびＣＰＣであるように選択されるＣＳＥに展開し得、それぞれのパッケージは、各ＣＳＥが、ＣＰＣまたはＣＰＭであるようにそれ自体を構成することを可能にする。別の実施例では、ノードは、それぞれの指示を、ＣＰＭであるように選択されるＣＳＥおよびＣＰＣであるように選択されるＣＳＥに送信し得、それぞれの指示は、各ＣＳＥが、ＣＰＣまたはＣＰＭであるようにそれ自体を構成することを可能にする。
【００２４】
別の例示的実施形態では、プールは、プールメンバがプールに加入し、プールから削除されることができるように、ＣＰＭによって管理される。プールメンバは、異なる共通サービスエンティティ上で起動する、ＣＳＦソフトウェアインスタンスであり得る。例えば、Ｍ２Ｍノードは、共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）から通知を受信し得る。通知は、共通サービスエンティティ（ＣＳＥ）の１つ以上のＣＳＦインスタンスが、ノードによって管理されるプールに加入することを申請していることを示し得る。１つ以上のＣＳＦインスタンスがプールに加入することを承認されると、ノードは、将来の使用のために、１つ以上のＣＳＦインスタンスを在庫リストに追加し得る。ノードは、メッセージをＣＳＥに送信し得、メッセージは、１つ以上のＣＳＦインスタンスがノードによって管理されていることを示し得る。ＣＳＥに送信されるメッセージに応答して、ノードは、ＣＳＥから確認応答メッセージを受信し得、確認応答メッセージは、ＣＳＥに関連付けられた性能データを備えている。ノードは、ノードがサービス層要求を処理するために１つ以上のＣＳＦインスタンスを割り当てる、もしくは呼び出すことを意図するときに、性能データが参照されることができるように、在庫リストを更新し、ＣＳＥに関連付けられた性能データを含み得る。さらに、実施例では、ノードは、削除通知をＣＳＥに送信し得る。削除通知は、１つ以上のＣＳＦインスタンスがプールから削除されていることを示し得る。削除通知は、ＣＳＥの１つ以上の履歴性能統計に基づいて送信され得る。ノードは、ＣＳＥから削除確認応答を受信し得、削除確認応答は、ＣＳＥが、１つ以上のＣＳＦインスタンスがプールから削除されていることを認識していることを示し得る。代替として、または加えて、ノードは、ＣＳＥから削除通知を受信し得る。削除通知は、１つ以上のＣＳＦインスタンスがプールから離脱することを要求していることを示し得る。削除通知は、１つ以上のＣＳＦインスタンスがそれに割り当てられた処理をサポートすることができないというＣＳＥの決定に基づいて送信され得る。故に、ノードは、プールから１つ以上のＣＳＦインスタンスを削除し得る。
【００２５】
本願のより堅調な理解を促進するために、ここで、同様の要素が同様の数字で参照される、付随の図面を参照する。これらの図面は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。
【図面の簡単な説明】
【００２６】
【図１】図１は、ネットワーク機能仮想化（ＮＦＶ）に関連付けられる概念を図示する略図である。
【図２】図２は、ＮＦＶの例示的実装図である。
【図３】図３は、仮想化ネットワーク機能（ＶＮＦ）アーキテクチャの実施例を描写する、ブロック図である。
【図４】図４は、モバイルエッジコンピューティング（ＭＥＣ）の実施例を図示する略図である。
【図５】図５は、例示的マシンツーマシン（Ｍ２Ｍ）ネットワークアーキテクチャおよびサービスを描写する系統図である。
【図６】図６は、サービス層をサポートする例示的プロトコルスタックを示す。
【図７】図７は、ネットワーク内で展開されるＭ２Ｍまたはモノのインターネット（ＩｏＴ）サービス層の実施例を描写する系統図である。
【図８】図８は、ｏｎｅＭ２Ｍサービス層内の共通サービス機能（ＣＳＦ）を示す。
【図９】図９は、ｏｎｅＭ２Ｍサービス層リソース指向アーキテクチャを描写するブロック図である。
【図１０】図１０は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャを描写するブロック図である。
【図１１】図１１は、ｏｎｅＭ２Ｍで定義される例示的メッセージフローを描写する。
【図１２】図１２は、サービス層がＮＦＶを適用しない、例示的ユースケースを図示する。
【図１３】図１３は、例示的実施形態による、例示的メッセージ交換を描写するコールフローである。
【図１４】図１４は、例示的実施形態による、プールベースのＭ２Ｍサービス層のための例示的機能アーキテクチャを描写する。
【図１５】図１５は、例示的実施形態による、プールベースのサービス層を実現するための例示的タスクを描写する。
【図１６】図１６は、例示的実施形態による、例示的候補選択プロセスを描写するコールフローである。
【図１７】図１７は、例示的実施形態による、例示的役割選択プロセスを描写するコールフローである。
【図１８】図１８は、例示的実施形態による、例示的役割移行プロセスを描写するコールフローである。
【図１９】図１９は、例示的実施形態による、例示的役割リンキングプロセスを描写するコールフローである。
【図２０】図２０は、例示的実施形態による、ＶＮＦプールに加入する共通サービス機能（ＣＳＦ）のインスタンスを描写するコールフローである。
【図２１】図２１は、例示的実施形態による、ＶＮＦプールから退出するＣＳＦのインスタンスを描写するコールフローである。
【図２２】図２２は、例示的実施形態による、ｏｎｅＭ２Ｍサービス層内のＶＮＦプールイネーブラサービス（ＶＰＥＳ）を示す。
【図２３】図２３は、例示的実施形態による、ＣＳＦプールコントローラ（ＣＰＣ）のための例示的ｏｎｅＭ２Ｍリソースを示す。
【図２４】図２４は、例示的実施形態による、ＣＳＦプールマネージャ（ＣＰＭ）のための例示的ｏｎｅＭ２Ｍリソースを示す。
【図２５】図２５は、例示的実施形態による、ｏｎｅＭ２Ｍプーリングを示すコールフローである。
【図２６】図２６は、例示的実施形態による、システムに関連付けられる例示的グラフィカルユーザインターフェースを示す。
【図２７】図２７は、例示的実施形態による、例示的ＣＳＦプールに関連付けられる例示的グラフィカルユーザインターフェースを示す。
【図２８Ａ】図２８Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）もしくはモノのインターネット（ＩｏＴ）通信システムの系統図である。
【図２８Ｂ】図２８Ｂは、図２８Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。
【図２８Ｃ】図２８Ｃは、図２８Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。
【図２８Ｄ】図２８Ｄは、図２８Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。
【発明を実施するための形態】
【００２７】
（例示的実施形態の詳細な説明）
本明細書では、Ｍ２Ｍ／ＩｏＴネットワークへの既存のアプローチは、ネットワーク機能仮想化（ＮＦＶ）を実現しないことを認識されたい。具体的には、既存のＭ２Ｍサービス層（例えば、ｏｎｅＭ２Ｍ）は、ＮＦＶ実践に従って構築、管理、または動作されない。したがって、ＮＦＶの利益は、既存のサービス層では実現されない。
【００２８】
上で言及されるように、ｏｎｅＭ２Ｍ共通サービス層は、共通サービス機能（ＣＳＦ）のセットをサポートし、１つ以上の特定のタイプのＣＳＦのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称される。図１１を参照すると、共通サービスエンティティ（ＣＳＥ）およびアプリケーションエンティティ（ＡＥ）を伴うプロシージャは、要求および応答メッセージの使用に基づく、参照点を横断するメッセージの交換によって駆動される。具体的には、発信側１１０１から要求メッセージ１１０２を受信することに応じて、要求１１０２の受信側１１０３は、要求１１９２を処理し、応答メッセージ１１０４を発信側１１０１に返信するように、受信側１１０３上で実装される、または起動している、あるサービスもしくはＣＳＦインスタンスを呼び出す。
【００２９】
ここで、具体的な例示的ユースケースに目を向け、図１２を参照すると、空調制御のためのアクチュエータである、アプリケーションエンティティ（ＡＥ−１）は、（１２０２において）要求をＭＮ−ＣＳＥ１２０３のために標的とされたＵＲＩを伴う中間ノードＣＳＥ（ＭＮ−ＣＳＥ）１２０３に送信する。実施例によると、１２０２における要求は、本来、温度予測を得るために、ＭＮ−ＣＳＥ１２０３上で起動するデータ分析サービスによって処理されるはずである。当分の間、例示的ユースケースによると、ＭＮ−ＣＳＥ１２０３の能力は、動的に拡大または縮小されることができないと仮定される。例えば、ＭＮ−ＣＳＥ１２０３が、Ｍ２Ｍエリアネットワークから受信される過剰に多くの要求に起因してオーバーロードされた、またはＭＮ−ＣＳＥ１２０３上のデータ分析サービスが、無反応もしくは別様に利用不可能である場合、ＡＥ−１からの要求は、時間内に処理されない場合がある。本明細書では、ＣＳＥ上で余剰容量を常時過剰にプロビジョニングするというソリューションは、不良な融通性およびエネルギー効率に起因して、うまく機能しない場合があることに留意されたい。図１２で描写される例示的ユースケースを継続すると、ＭＮ−ＣＳＥ１２０３上で起動している同一のデータ分析サービスインスタンスは、他のノード、例えば、インフラストラクチャノードＣＳＥ（ＩＮ−ＣＳＥ）ノード１２０５上で起動している。しかしながら、例示的ユースケースによると、ＭＮ−ＣＳＥ１２０３は、ＩＮ−ＣＳＥ１２０５（または任意の他のノード）上のサービスインスタンスを動的に呼び出し、１２０２において受信される要求を処理することが可能ではない。
【００３０】
図１２に対するユースケースは、ＭＮ−ＣＳＥ１２０３が単純に要求をＩＮ−ＣＳＥ１２０５に転送するケースと異なる。転送する場合では、ＡＥ−１は、図１２を参照して説明される例示的ユースケースのようにＭＮ−ＣＳＥ１２０３ではなく、ＩＮ−ＣＳＥ１２０５のための標的ＵＲＩを具体的に設定する。以下に説明される能力共有シナリオに関して、ＡＥ−１は、ＩＮ−ＣＳＥ１２０５がその要求をハンドリングするであろうことを認識する必要がない。
【００３１】
図１２で描写されるユースケースは、サービス層を構築することへの現在のアプローチの限定を実証する、複数のうちの一実施例である。例えば、（ＣＳＦの観点から）サービス層能力は、Ｍ２Ｍ／ＩｏＴネットワークを横断して異なるＣＳＥ間で効率的に利用されないように妨げられ得る。以下に説明される例示的実施形態によると、ＮＦＶ技術を利用する、Ｍ２Ｍサービス層を構築および管理するためのパラダイムが、説明される。例えば、ＮＦＶを通してプールベースのサービス層を構築するためのパラダイムが、以下に開示される。以下の説明の大部分は、種々の実施形態を例証するためにｏｎｅＭ２Ｍの文脈における説明的実施例を含むが、実施形態は、ｏｎｅＭ２Ｍに限定されないことを理解されたい。例えば、説明される実施形態は、所望に応じて他のサービス層を伴って実装されることができる。
【００３２】
ここで図１３を参照すると、例示的ｏｎｅＭ２Ｍシステムが、示される。図１３に示されるように、ｏｎｅＭ２Ｍ共通サービス層に関して、ＣＳＥおよびＡＥを伴うプロシージャは、参照点を横断するメッセージの交換によって駆動され、一般的フローは、図１１を参照して説明されるような要求および応答メッセージの使用に基づく。具体的には、図１３に示されるように、発信側１１０１から要求を受信することに応じて、受信側１１０３は、１３０２において要求処理段階を実施する。１３０２における要求プロセス段階は、要求を処理し、処理された結果を取得するステップを含み得る。処理された結果は、１１０４において応答メッセージの中で発信側に返信され得る。
【００３３】
以下にさらに説明されるように、１３０２における要求処理段階中に、１つ以上の異なるサービス能力もしくはＣＳＦソフトウェアインスタンスが、要求を処理するために呼び出され得る。現在のｏｎｅＭ２Ｍ実践によると、１３０２における要求処理は、ＣＳＥ内にある。ＣＳＥは、例えば、ロードバランシング等のある内部最適化がサポートされる、集中型クラスタを使用することによって実現され得る。しかしながら、以下に説明される実施形態では、ＣＳＦまたはサービス能力は、異なるＣＳＥを横断して共有され得る。図１３を参照すると、所与のＣＳＥ（例えば、受信側１１０３）によって受信される（１１０２における）サービス層要求が、ＮＦＶがサービス層を構築するために使用され、ＣＳＦまたはサービス能力がＣＳＥの間で共有される実装で、１３０２において処理され得る方法が、以下に説明される。実施形態では、異なるＣＳＥ上でホストされる、または起動している、ＣＦＳもしくはサービス能力（例えば、ソフトウェアインスタンス）は、１３０２において要求を処理するために動的かつ協調的に活用される。
【００３４】
ここで図１４を参照すると、例示的アーキテクチャ１４００は、ＮＦＶを介して実装されるプールベースのサービス層を含む。ＮＦＶを使用して、Ｍ２Ｍ／ＩｏＴノードの物理的リソースは、ハイパーバイザによって仮想マシン（ＶＭ）として仮想化され得る。故に、Ｍ２Ｍノード上で起動する、異なるネットワーク機能ソフトウェアインスタンス（例えば、ＣＳＦまたはサービス能力）は、必要性に基づいて、動的に展開される／起動される／Ｍ２Ｍノードからアンインストールされることによって、所与のＣＳＥ（例えば、ＡＳＮ−ＣＳＥ１４０２、ＭＮ−ＣＳＥ１４０４、またはＩＮ−ＣＳＥ１４０６）を構築することができる。ＡＳＮ−ＣＳＥ１４０２、ＭＮ−ＣＳＥ１４０４、およびＩＮ−ＣＳＥ１４０６は、それぞれ、概して、Ｍ２Ｍノードと称され得ることを理解されたい。具体的には、例えば、以下に説明されるように、異なるＣＳＥ上でホストされるＣＳＦまたはサービス能力ソフトウェアインスタンスは、対応するＶＮＦプールに加入することができ、本明細書ではＣＳＦプールとも称され得る、それらのＶＮＦプールのＣＳＦプールマネージャ（ＣＰＭ）によって管理されることができる。ＣＳＦプールは、概して、同一のネットワーク機能を提供する複数のＣＳＦインスタンスを指す。ＣＳＦプールメンバは、概して、ＣＳＦプールに加入し、プールのＣＰＭによって管理される、物理的ＣＳＦインスタンスを指す。ＣＰＭは、概して、ＣＳＦプールコントローラ（ＣＰＣ）を管理し（例えば、プールメンバを管理する／呼び出す／スケジューリングする）、それと相互作用してＣＳＦインスタンスを提供する、論理エンティティを指す。
【００３５】
本明細書に説明される実施形態を設計する際に、本明細書では、Ｍ２Ｍ／ＩｏＴシステム内のノードは、サービス層要求が、例えば、受信側ＣＳＥの限定された処理能力に起因して、適時に処理されない場合があるように、リソース制約され得ることを認識されたい。したがって、受信側ＣＳＥは、ピアからの助けを求め得る。具体的には、本明細書に説明されるプーリング機構は、ＣＳＦインスタンスが、オンデマンド様式で共有および動的にプロビジョニングされることを可能にし得る。さらに、本明細書では、Ｍ２Ｍノードは、多くの場合、エネルギー効率目的のためにスリープするスケジュールを有することを認識されたい。したがって、所与のＣＳＦインスタンスが、例えば、周期的スリープに起因して、利用不可能になるとき、例示的実施形態によるプーリング機構によってサポートされる、即時バックアップＣＳＦインスタンスが、プロビジョニングされることができる。
【００３６】
再び図１４を参照すると、アーキテクチャ１４００は、１つ以上のＣＳＦプールコントローラ（ＣＰＣ）、例えば、ＣＳＦプールコントローラ（ＣＰＣ）１４０８と、１つ以上のＣＳＦプールマネージャ（ＣＰＭ）、例えば、第１のＣＰＭ１４１０ａおよび第２のＣＰＭ１４１０ｂとを含むことができる。２つのプール（ＶＮＦプールＡおよびＶＮＦプールＢ）が例示を目的として示されているが、ＣＰＣ１４０８は、所望に応じて任意の数のプールを制御し得ることを理解されたい。図１４に示されるように、ＣＰＣ１４０８ならびにＣＰＭ１４１０ａおよび１４１０ｂは、論理機能であり得る。故に、ＣＰＣおよびＣＰＭ機能は、ネットワーク内のあるＣＳＥによって実施され得る。別様に規定されない限り、用語ＣＳＥノードおよびＭ２Ｍノードは、本明細書では同義的に使用され得ることを理解されたい。プール（ＶＮＦプールＡおよびＶＮＦプールＢ）は、それらのプールの中のＣＳＦソフトウェアインスタンスがＭ２Ｍネットワークを横断して物理的に分配され得るという意味で、論理プールであり得る。実施例として、示されるように、ＶＮＦプールＡ（ＣＳＦ−Ａプールとも称され得る）は、Ｍ２Ｍエリアネットワーク内でＡＳＮ−ＣＳＥ１４０２上にホストされる、物理的ソフトウェアインスタンスＣＳＦ−Ａ＃１を含む。ＣＳＦ−Ａプールはさらに、ＩＮ−ＣＳＥ１４０６側にホストされる、物理的ソフトウェアインスタンスＣＳＦ−Ａ＃２を含む。本明細書で使用されるように、ＣＰＣは、概して、種々のＣＳＦを組み合わせて編成する方法を決定する、サービスプロバイダの論理エンティティを指し得る。
【００３７】
例示的実施形態では、受信側ＣＳＥによって受信される所与のサービス層要求は、ローカルで処理されることができる、または受信側ＣＳＥは、ＣＰＣ（現在ＣＰＣの役割を担っている別のＣＳＥであり得る）にコンタクトし得、ＣＰＣは、（例えば、プールから異なるＣＳＦインスタンスを呼び出すことによって）要求を処理するように適切なＣＰＭに求め得る。ＣＰＣは、処理された結果を受信側ＣＳＥに返し得、ＣＳＥは、応答メッセージを要求の発信側に返信し得る。要求処理詳細は、透過的であり得る、または要求の発信側から隠され得る。
【００３８】
本明細書に説明されるように、所与のＣＳＥは、相互を除外しない場合がある、種々の役割を果たし得る。例えば、ＣＳＥは、ｏｎｅＭ２Ｍサービス層の文脈において説明されるように、サービス層要求発信側であり得る。ＣＳＥは、ＣＳＥがＶＮＦプールによって提供されるＣＳＦインスタンスを使用することによって、その受信された要求を処理するためにＣＰＣにコンタクトする場合に、ＶＮＦプール「ＣＳＦリソース消費側」でもあり得る、サービス層要求受信側であり得る。所与のＣＳＥは、例えば、ＣＳＥが１つ以上のＣＳＦインスタンスを起動している場合、およびＣＳＥが自発的にそれらのＣＳＦインスタンスをＣＰＭによって管理される対応するＶＮＦプールに加入させる場合に、ＶＮＦプール「ＣＳＦリソースプロバイダ」であり得る。
【００３９】
例示的実施形態では、以下に詳細に説明されるように、サービスプロバイダ（ＳＰ）は、複数のＣＳＥが、図１４を参照して説明されるプールベースのアーキテクチャを実現するように展開されている、所与のＭ２Ｍネットワークを構成することができる。例えば、ＳＰは、論理役割（例えば、ＣＰＣ、ＣＰＭ等）をあるＣＳＥに割り当てることができる。さらに、異なるタイプのＣＳＦインスタンスがＶＮＦプールに加入することができ、かつ対応するＣＰＭによって管理されることができるため、プール管理をサポートする具体的プロシージャまたは機構が、以下に説明される。
【００４０】
具体的には、例えば、ＶＮＦプールイネーブラサービス（ＶＰＥＳ）と称されるＣＳＥの新しいサービスが、本明細書に開示される。ＶＰＥＳは、本明細書に説明されるＶＮＦプールベースのサービス層を構築することに役立ち得る。ＶＰＥＳを使用して、サービス層設定、展開、およびプール管理に関連するタスクが、図１５に図示されるように、実施される。
【００４１】
図１５を参照すると、ＣＰＣ役割が、割り当てられる。図示される実施例によると、ＳＰは、ＶＰＥＳのサポートを伴うＣＰＣの役割を担うようにＣＳＥ−１を割り当てる。いくつかの場合では、ＣＰＣは、受信側ＣＳＥが１つ以上のＶＮＦプールの中のＣＳＦソフトウェアインスタンスを使用することによってサービス層要求を処理することを意図する場合、受信側ＣＳＥが最初にＣＰＣにコンタクトするであろうという意味で、ＶＮＦプールベースのシステムのポータルである。示されるように、ＳＰは、（ＶＰＥＳのサポートを伴う）ＣＰＭの役割を担うようにＣＳＥ（ＣＳＥ−２）を割り当て、ＣＰＣの役割を果たすように割り当てられたＣＳＥ−１とＣＰＭをリンクし得る。ＣＰＭ割当のためのそのようなタスクは、複数のタイプのＣＳＦが存在し得、それぞれのタイプのＣＳＦが、その対応するプールを管理するためにＣＰＭを要求し得るため、複数回実行され得る。ここでプール管理のための図示されるタスクを参照すると、ＣＰＭは、ある機構を実施し、ＣＳＦインスタンスがプールに加入またはそこから退出することを可能にし得る。図示されるタスクが実行されると、プールベースのサービス層が、システム全体の動的ＣＳＦリソースプーリングおよび共有の観点から実装されることができる。
【００４２】
代替実施例では、ＳＰは、図１５に図示されるタスクが実施されないように、展開前にある役割を伴ってＣＳＥを事前構成することができる。そのような実装は、事前構成が展開前に実施されることであり得る。しかしながら、上で言及されるように、多くの場合、Ｍ２Ｍ／ＩｏＴシステムに種々の動的変更が存在し得る。例えば、Ｍ２Ｍノードは、それらがスリープするときに利用不可能になり得る。故に、あるタスクが、展開後にネットワークを動的に設定または構成するために、ＳＰによって実施される必要があり得る。加えて、それらのタスクは、以下に説明されるように、高度分散型Ｍ２Ｍ／ＩｏＴネットワークに合わせられる必要があり得る。
【００４３】
ここで、ＣＰＣ割当のためにタスクが、さらに詳細に議論されるであろう。Ｍ２Ｍ／ＩｏＴネットワークまたはシステムは、多くの場合、クラウドもしくはデータセンタ内のアプリケーションシナリオと異なる種々の動的変更を被る。例えば、Ｍ２Ｍノードは、エネルギーを節約する周期的スリープに起因して利用不可能になり得る。さらに、Ｍ２Ｍノードは、クラウドまたはデータセンタ内のコンピューティングノードの静的展開と比較して、より多くのモビリティ特性を有し得る。加えて、多くの場合において、Ｍ２Ｍ／ＩｏＴノードは、役割をあるＣＳＥに割り当てるときに、リソース消費側面を考慮する必要があるように、リソース制約される。したがって、本明細書では、サービス制御エンティティ（ＳＣＥ）役割をＭ２Ｍ／ＩｏＴネットワーク内の適格ＣＳＥに割り当てることが些細なタスクではない場合があることを認識されたい。
【００４４】
いくつかの場合では、Ｍ２Ｍ／ＩｏＴシステムに関連する種々の要件に対処するために、候補選択プロセス（ＣＳＰ）、役割割当プロセス（ＲＡＰ）、および役割移行プロセス（ＲＭＰ）が、ＣＰＣ割当のためのタスクを遂行するように実施され得る。例示的ＣＳＰに関して、分散型Ｍ２Ｍネットワーク内で、Ｍ２Ｍノードは、種々のリアルタイム処理に起因する動的容量ステータスを有し得る。したがって、ＣＳＰは、それらの現在の容量に基づいて、いくつかの候補ＣＳＥを評価し得、最良のＣＳＥが、ＣＰＣ役割を果たすように選択され得る。例示的ＲＡＰに関して、いくつかの場合では、あるＣＳＥがＣＳＰプロセス中に選択されると、ＳＰは、ある動作を行い、役割を選択されたＣＳＥに割り当て得る。例示的ＲＭＰに関して、いくつかの場合では、Ｍ２Ｍ／ＩｏＴネットワーク内で起こる変化またはイベントに照らして、選択されたＣＳＥは、ある時点で、もはやＣＰＣとしての役割を果たすことが可能ではなくなり得る。したがって、ＣＰＣ役割は、異なるＣＳＥの間で動的に移行され得る。
【００４５】
ここで、概して、図１６−２１を参照すると、例示的方法が、ＳＰと、複数のＣＳＥとを含む、システム（またはネットワーク）内で実施される。例えば、ＣＳＥは、ＶＰＥＳを含むＣＳＥ−１と、ＶＰＥＳを含むＣＳＥ−２と、ＶＰＥＳを含むＣＳＥ−３とを含み得る。例示的システムは、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図していないことを理解されたい。他のデバイス、システム、および構成も、図１６−２１に示されるネットワーク等のシステムに加えて、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として想定される。
【００４６】
具体的に図１６を参照すると、例示的候補選択プロセス（ＣＳＰ）が、示される。１では、図示される実施例によると、ＳＰはすでに、システム内でＣＰＣとしての役割を果たすＣＳＥがないことをチェックしていると仮定される。１では、ＳＰは、ＣＰＣの役割を果たすことができるネットワーク内の適切なＣＳＥを見出すことを所望する。故に、ＳＰ、例えば、ＳＰによって起動される管理アプリケーションは、要求群を１つ以上のＣＳＥに送信し得る。したがって、ＳＰは、要求を複数の共通サービスエンティティに送信し得る。示されるように、ＣＳＥ−１は、要求を受信し、要求に関連付けられる動作を実施する、ＣＳＥのうちの１つの実施例である。いくつかの場合では、ＣＳＣが本明細書に説明されるアーキテクチャにおいて重要な役割を果たし得るため、ＳＰは、要求を信頼されるＣＳＥに送信するのみである。そうする際に、ＳＰは、厳選した信頼されるＣＳＥから種々の情報を収集し得る。情報は、例えば、限定ではないが、ノードの性能に関連付けられる情報、ノードの可用性に関連付けられる情報、およびセキュリティ関連情報を含み得る。例えば、性能に関して、ＳＰは、強力なノードがＣＰＣとしての役割を果たすことを要求し得る。したがって、ＳＰは、強力なエッジコンピューティング能力を有する、Ｍ２Ｍサーバまたはゲートウェイを選択し得る。ノードの可用性に関して、ＳＰは、概して、ＣＰＣ役割のために利用可能であるＣＳＥを選択し得る。実施例として、ＳＰは、Ｍ２Ｍサーバまたはゲートウェイが利用可能である可能性が最も高いことを決定し得、したがって、Ｍ２Ｍサーバまたはゲートウェイは、デフォルトで第１のオプションであり得る。Ｍ２Ｍサーバまたはゲートウェイ以外の他のノードが、代替として、ＣＰＣとして選択され得ることを理解されたい。セキュリティ情報に関して、ＳＰは、適切なセキュリティ機構を有するＣＳＥを選択し、システムがセキュリティ問題および脅威なしで起動し得ることを確実にし得る。要求を送信するために、ＳＰは、既存のｏｎｅＭ２Ｍグループ動作を使用し、信頼されるＣＳＥを含むグループを最初に定義し得る。したがって、ＳＰがＣＰＣとなる適切なＣＳＥを見出す必要があると、ＳＰは、定義された＜ｇｒｏｕｐ＞リソースを通してグループ通信動作を行い、要求をそれらのＣＳＥに送信することができる。
【００４７】
依然として図１６を参照すると、２では、図示される実施例によると、ＳＰは、ＣＳＥ−１の現在の性能容量についてクエリを行い、ＣＳＥ−１が自発的にＣＰＣになるかどうかについてクエリを行う。実施例では、要求は、各ＣＳＥの現在の容量および各ＣＳＥが自発的にＣＰＭになるかどうかについてクエリを行い得る。具体的には、ＣＳＥ−１のＶＰＥＳが、クエリに回答し得る。いくつかの場合では、ＮＦＶ技術が、利用され、したがって、使用可能なコンピューティング／記憶リソースは、利用可能なＶＭリソースの観点から説明されることができる。２において送信されるメッセージは、実施例として、限定ではないが、以下等の種々のデータフィールドを含むことができる。
●  受信側が、メッセージがＳＰから送信されたことを知らされるように、送信側の識別を識別する、送信側ＩＤ（ｓ＿ｉｄ）。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、要求の目的を示し得る。例えば、受信側ＣＳＥは、メッセージタイプから、それが自発的にＣＰＣになるかどうかをＳＰが尋ねていることを把握し得る。
●  持続時間（ｔ＿ｄ）：いくつかの場合では、ＳＰは、持続時間パラメータによって示され得る、所与の時間周期にわたってＣＰＣを所望する。
●  クエリを行われる性能データのタイプ（ｐ＿ｌｉｓｔ）：ＳＰは、受信側ＣＳＥが、ＳＰによって必要とされない場合がある過剰に多くの性能データを返す必要がないように、ＳＰが関心を持つ性能データのタイプを受信側に示し得る。実施例として、データフィールドのリストは、ＣＰＵ、ＲＡＭ、記憶装置等の性能タイプを規定し得る。
●  コネクティビティ（ｃｏｎ）：ＳＰはまた、例えば、それがＣＰＣとなる良好な候補であるかどうかを決定するために、受信側ＣＳＥのコネクティビティ情報にも関心を持ち得る。例えば、ＣＳＥは、ＣＰＣがネットワーク内の複数のノードの間で調整および協調動作を行い得るため、ネットワーク内の他のノードとの不良なコネクティビティを有する場合、ＣＰＣとしての役割を果たすべきではない。
【００４８】
３では、図示される実施例によると、ＣＳＥ−１のＶＰＥＳは、そのＯＳまたはハイパーバイザ（例えば、利用可能なＶＭリソース）と相互作用することによって、その実行時容量データを収集する。ＣＳＥ−１のＶＰＥＳはまた、そのローカルシステムポリシに基づいて、ＣＰＣとして作用し得るかどうかを決定し得る。いくつかの場合では、あるＣＳＥがＣＰＣとしての役割を果たすために十分なＶＭリソースを有する場合、ローカルシステムポリシがそうすることを可能にすることを確認する必要があり得る。例えば、いくつかのノードは、所与のノード上のＶＭリソースが具体的アプリケーションまたはユーザのみによって利用されることができるように、ユーザによって構成され得る。故に、それらのノードは、それらが自発的にＣＰＣとしての役割を果たすことをＳＰに示すことが可能ではない場合がある。同様に、いくつかのセキュリティ関連ポリシはまた、ノードがＣＰＣとしての役割を果たすことができない、同一の状況にもつながり得る。４では、示されるように、ＣＳＥ−１は、応答の中でＳＰによって要求される上で言及される情報を返信する。４におけるメッセージは、例えば、限定ではないが、以下等の種々のデータフィールドを含み得る。
●  受信側ＩＤ（ｒ＿ｉｄ）：メッセージ受信側の識別は、応答が候補ＣＳＥからであることをＳＰに知らせる。
●  応答タイプ（ｒ＿ｔ）：このデータフィールドは、受信側ＣＳＥが自発的にＣＰＣになるかどうかをＳＰに知らせ得る。
●  詳細性能データ（ｄｐ＿ｌｉｓｔ）：受信側ＣＳＥは、例えば、要求メッセージの中で規定されるようなＳＰの関心に基づいて、性能データのリストをＳＰに返し得る。例えば、性能データは、限定ではないが、ＶＭによってサポートされるＣＰＵ、本ＶＭによってサポートされるＲＡＭ、本ＶＭによってサポートされる記憶装置、本ＶＭによってサポートされるＳＬＡ（サービスレベル合意）、本ＶＭによって起動されるオペレーティングシステム、スリープスケジュールまたはＣＰＣとして存在する利用可能な時間周期、および同等物を含み得る。１においてＣＰＣにエクスポーズされる先の情報と比較して、ここでのデータは、現在の利用可能なＶＭを説明する、より多くの実行時データを含む。
●  トポロジ情報（ｔ＿ｉ）：受信側ＣＳＥは、そのコネクティビティステータスを示し得る、そのトポロジ情報をＳＰに知らせ得る。
上で説明されるように、ネットワーク内に（ＣＳＥ−１に加えて）複数の候補ＣＳＥが存在し得るため、ステップ２−４が、ＳＰと他の候補ＣＳＥとの間で行われ得る。したがって、要求に応答して、ＳＰは、複数の共通サービスエンティティから複数の応答を受信し得、各応答は、それぞれのＣＳＥが共通サービス機能（ＣＳＦ）プールコントローラ（ＣＰＣ）であることが可能かどうかに関連する情報を含み得る。
【００４９】
依然として図１６を参照して、図示される実施例によると、５において、ＳＰが候補ＣＳＥから情報を収集すると、ＳＰは、種々の基準を使用して候補ＣＳＥを評価し、ＣＰＣとしての役割を果たすために最良であるＣＳＥを決定する。例えば、ＳＰは、ＣＰＣ役割のための最良のＣＳＥが、使用のために利用可能である最も強力なＶＭを有するＣＳＥであることを決定し得る。したがって、ＳＰは、各応答からの情報を評価し、複数の共通サービスエンティティから少なくとも１つのＣＰＣを選択し得る。６では、候補ＣＳＥ（図示される実施例ではＣＳＥ−１）がＣＰＣ役割を担うようにＳＰによって選択されると、ＳＰは、基準または好ましい性能要件を規定することによって、ＣＳＥ−１のための役割プロファイルを正式にカスタマイズし得る。したがって、ＳＰは、少なくとも１つのＣＰＣのための役割プロファイルを生成し得る。役割プロファイルは、ＣＰＣの仮想マシンのための最小性能要件、ＣＰＣの仮想マシンのための好ましい実施時間、役割移行計画、および役割ソフトウェア更新スケジュールのうちの少なくとも１つを備え得る。実施例では、役割プロファイルは、少なくとも１つのＣＰＣがＣＰＣの役割をバックアップＣＳＥに移行させることができるように、バックアップＣＳＥとして共通サービスエンティティのうちの１つを識別する。別の実施例では、Ｍ２Ｍノードが、周期的スリープに起因して、随時、利用不可能になり得ることを考慮して、ＳＰは、複数のＣＳＥを選択し、それらがＣＰＣとしてそれぞれ作用するための稼働スケジュールを考案し得る。したがって、ＳＰは、複数のＣＳＦプールコントローラを選択し得、役割プロファイルはさらに、ＣＳＦプールコントローラの各々に関連付けられた稼働時間を備え得る。いくつかの場合では、候補が選択されると、ＳＰは、図１７を参照して以下に詳細に説明される役割割当プロセスを行い始め得る。
【００５０】
役割プロファイル生成に関して、ある役割プロファイルテンプレートが、役割プロファイルを生成するために定義され得る。例えば、表１は、例示的役割プロファイルに列挙され得る実施例データ項目を図示する。例えば、関係者がデータ項目の意味を明確にする合意を有すると仮定して、他のデータ項目も、所望に応じて含まれ得ることを理解されたい。例えば、ＳＰは、以降の自己構成のためのＣＳＥ−１のガイドラインである、基準／好ましい性能要件および除外処理規則（例えば、任意の除外が起こる場合にＣＰＣ役割を引き継ぐことができるバックアップＣＳＥ）に基づいて、ＣＳＥ−１のための役割プロファイルをカスタマイズすることができる。
【表１】
2019514118.tif 000003
【００５１】
ここで図１７を参照すると、役割割当のための例示的前提条件として、ＣＳＥ−１は、ＣＰＣとして選択されており（図１６参照）、ここで、ＳＰは、ＣＰＣの役割を担うようにＣＳＥ−１を指定することを意図する。１において、図示される実施例によると、ＳＰは、役割プロファイルをＣＳＥ−１に配信することによって、ＣＰＣ役割を選択された候補ＣＳＥ（ＣＳＥ−１）に与える。したがって、実施例では、役割プロファイルは、複数の共通サービスエンティティのうちの少なくとも１つのＣＳＥに送信され得る。役割プロファイルは、ＳＰがＣＰＣ役割をＣＳＥ−１に割り当てたことをＣＳＥ−１に知らせ得る。１におけるメッセージは、種々のデータフィールドを含み得、そのうちの少なくともいくつかは、表１で描写される例示的役割プロファイルに由来し得る。データフィールドは、限定ではないが、実施例として提示される、以下を含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＳＰからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、メッセージの目的を示し得る。例えば、受信側ＣＳＥは、メッセージタイプから、ＳＰがＣＰＣ役割をそれに割り当てていることを知らされ得る。
●  プロファイル識別子（ｐ＿ｉ）
●  役割名（受信側ＣＳＥがｍ＿ｔ  ｍｅｓｓａｇｅから本情報を把握することができる場合、随意）
●  バックアップＣＳＥ（ｂｋ＿ｃｓｅ）
●  役割のためのソフトウェアソース（ｓｗ＿ｓｏｕｒｃｅ）
●  最小ＶＭ性能要件（ｍｉｎ＿ｐｅｒｆ）
●  好ましいＶＭ性能要件（ｐｅｒｆｅｒｅｄ＿ｐｅｒｆ）
●  稼働時間（ｄｕｔｙ）
●  役割移行計画（ｍｉｇ）
●  役割ソフトウェア更新スケジュール（ｓｗ＿ｕｐｄ＿ｔｉｍｅ）
【００５２】
依然として図１７を参照すると、２では、図示される実施形態によると、ＣＳＥ−１のＶＰＥＳは、役割プロファイルで示されるように、必要なＶＭリソースを留保しようとすることによってこの役割を受け入れるかどうかを示す応答を送信する。したがって、役割プロファイルに応答して、ＳＰは、少なくとも１つのＣＳＥから確認応答（ａｃｋ）を受信し得、ａｃｋは、少なくとも１つのＣＳＥが、役割プロファイルで示されるように、その仮想マシンリソースを取っておき始めるであろうことを示し得る。いくつかの場合では、たとえＣＳＥ−１が、自発的にＣＰＣとしての役割を果たすことを以前にＳＰに示していたとしても、どうにかしてそうしない場合がある。例えば、あるソフトウェア設定および構成が、以下に説明されるように実施される必要があり得る。それらの動作は時間がかかり得るため、２において、ＣＳＥ−１は、ＳＰが新しいＣＳＰを初期化しないように、役割プロファイルで示されるような性能要件を満たすことに合意することを迅速にＳＰに示し得、ＣＳＥ−１はさらに、非同期方式で上で言及されるような必要動作を行い得る。
【００５３】
２におけるａｃｋメッセージは、例えば、受信側ＣＳＥが役割プロファイルで示されるような性能要件を満たすことに合意するかどうかを示す、応答タイプ（ｒ＿ｔ）等の種々のデータフィールドを含み得る。３では、ＣＳＥ−１から肯定的なａｃｋを得ると、ＳＰは、ＣＰＣソフトウェアパッケージをＣＳＥ−１に展開し始め得る。ソフトウェアパッケージは、ＣＳＥがＣＰＣであるようにそれ自体を構成することを可能にし得る。いくつかの場合では、ＣＰＣ（またはＣＰＭ）としての役割を果たすために、ＣＳＥは、対応するソフトウェアを起動する必要があり得る。ＶＰＥＳは、ソフトウェア起動を担当し得る。同様に、仮想化技術がＭ２Ｍノード上で利用され、したがって、そのようなＣＰＣソフトウェアが設定され、役割プロファイルで示されるような性能仕様を伴うＶＭ上で起動し得ると仮定され得る。代替として、ＳＰは、ＣＳＥ−１のＶＰＥＳが、例えば、ソフトウェアリポジトリからソフトウェアパッケージを読み出し得るように、例えば、具体的ＵＲＩを使用することによって、ＣＰＣソフトウェアをダウンロードする場所をＣＳＥ−１に知らせ得る。したがって、ＳＰは、指示を少なくとも１つのＣＳＥに送信し得、指示は、少なくとも１つのＣＳＥが、ＣＰＣであるようにそれ自体を構成することを可能にする。例えば、ＳＰは、随意に、デジタル証明書を生成し、それをＣＳＥ−１に割り当て得る。証明書は、ＣＳＥ−１がＣＰＣとして機能するという指示（例えば、形態の識別：ｃｐｃ１．ＳＰ．ｃｏｍ）を含み得る。証明書は、ポリシに基づいて決定され得る、有限存続期間を有する一時的証明書であり得る。証明書の請求およびプロビジョニングは、公開キー規格等を使用して実施され得る。
【００５４】
３におけるメッセージは、リンクデータフィールドを含み得る。例えば、役割プロファイルが、ステップ１に示されるようなダウンロードＵＲＬをすでに含んでいる場合、ＳＰは、ＣＳＥが役割プロファイルに含まれるＵＲＬを使用し、ソフトウェアをダウンロードすることができるように、リンク＝ヌルを設定し得る。代替として、ＳＰは、このデータフィールドを使用し、（異なるソフトウェアリポジトリの中のソフトウェアをダウンロードするように受信側ＣＳＥに動的にダイレクトするために使用され得る）受信側ＣＳＥに送信するＵＲＩリンクを含み得る。４では、図示される実施例によると、ＣＳＥ−１は、ＣＰＣソフトウェアを入手し、ＣＳＥ−１のＶＰＥＳは、ＣＰＣソフトウェアをインストールし、役割プロファイルで示されるパラメータに基づいてＣＰＣソフトウェアインスタンスを構成することを担当する。ＶＰＥＳは、ソフトウェアをインストールする前に、その完全性および真正性を検証し得る。５では、ステップ４が実施された後に、ＣＰＣは、ＣＳＥ−１がＣＰＣとして作用しているように、正常にＣＳＥ−１上に展開される。故に、ＣＳＥ−１は、役割割当プロセスが完了したことを示す確認をＳＰに送信し得る。５におけるメッセージは、受信側ＣＳＥがＣＰＣの役割を正常に果たしたかどうかを示す、応答タイプ（ｒ＿ｔ）データフィールドを含有するａｃｋメッセージであり得る。
【００５５】
ここで、図１８によって描写される例示的役割移行プロセス（ＲＭＰ）に目を向けると、図示されるコールフローは、ＣＳＥ−１が、現在、システム内でＣＰＣとして作用していると仮定する。示されるように、実施例によると、ＣＳＥ−１は、もはやＣＰＣとしての役割を果たすことができないように、システム問題に遭遇する。一実施例では、役割プロファイルで示されるバックアップＣＳＥが存在する場合、ＣＳＥ−１のＶＰＥＳは、直接、ステップ１−４に示されるように、ＣＰＣ役割をバックアップＣＳＥ（例えば、本場合ではＣＳＥ−２）に移行させ始め得る。ＣＳＥ−１およびＣＳＥ−２は、証明書（例えば、ＳＰによって発行された証明書）に基づいて、相互を相互認証し得、また、移行プロセスの承認をチェック得る。
【００５６】
１では、図示される実施例によると、ＶＰＥＳは、役割プロファイルをＣＳＥ−２に配信することによって、ＣＰＣ役割をバックアップＣＳＥ（例えば、本場合ではＣＳＥ−２）に移行させることを担当する。前述のように、ＳＰがＣＳＥ−１のための役割プロファイルを定義するとき、これは、ＣＳＥ−１のためのバックアップＣＳＥをすでに選択している場合がある。本場合では、ＣＳＥ−１のＶＰＥＳは、ＣＳＥ−２がすでに、ＣＳＰ中に、自発的にＣＰＣの役割も果たすことをＳＰに示している場合があるため、役割移行のためにＣＳＥ−２のＶＰＥＳに直接トークすることができる。図１７に図示されるステップ１（両方のメッセージが役割プロファイルを転送している）と同様に、図１８の１におけるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、それが現在ＣＰＣとして作用しているＣＳＥからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、本メッセージの目的を示す。言い換えると、メッセージタイプから、受信側ＣＳＥは、送信側ＣＳＥがＣＰＣ役割をそれに移行させていることを把握するであろう。
●  プロファイル識別子（ｐ＿ｉ）
●  役割名（例えば、受信側ＣＳＥがｍ＿ｔ  ｆｉｅｌｄから本情報を決定することができる場合、随意）
●  バックアップＣＳＥ（ｂｋ＿ｃｓ）は、例えば、オリジナル役割プロファイルの中に１つだけのバックアップＣＳＥが存在する場合、現時点でヌルに設定し得る。
●  役割のためのソフトウェアソース（ｓｗ＿ｓｏｕｒｃｅ）
●  最小ＶＭ性能要件（ｍｉｎ＿ｐｅｒｆ）
●  好ましいＶＭ性能要件（ｐｅｒｆｅｒｅｄ＿ｐｅｒｆ）
●  稼働時間（ｄｕｔｙ）
●  役割移行計画（ｍｉｇ）
●  役割ソフトウェア更新スケジュール（ｓｗ＿ｕｐｄ＿ｔｉｍｅ）
【００５７】
２では、図示される実施例によると、ＣＳＥ−２は、必ずしもこの役割移行を完了するために実際にＣＰＣとしての役割を果たすことが可能であるわけではない。具体的には、ＣＳＥ−２のＶＰＥＳが、現在、ＣＰＣとして機能することが可能ではないと決定する場合、これは、役割移行要求を直接拒否し得る。代替として、ＣＳＥ−２のＶＰＥＳは、ＳＰにコンタクトし、現在、ＣＰＣソフトウェアパッケージを有していない場合、それをダウンロードし得る、または代替として、依然としてＣＳＥ−１は、（例えば、具体的ＵＲＩを介して）ＣＰＣソフトウェアをダウンロードする場所をＣＳＥ−２に知らせ得る。加えて、ＣＳＥ−２がＣＰＣソフトウェアを入手すると、これはまた、図１７を参照して説明されるステップ３および４と同様に、それをインストールし、役割プロファイルで示されるパラメータに基づいてＣＰＣソフトウェアを構成し得る。
【００５８】
役割移行中に、具体的実装に応じて、異なる特徴が、サポートされることができる。一実施例では、ＣＳＥ−１は、ＣＰＣ役割をＣＳＥ−２に移行させ、ＣＳＥ−１によって管理されるライブＣＰＣ関連タスクは、終了される。代替として、ライブＣＰＣ関連タスクはまた、終了することなくＣＳＥ−２に移行されることもできる。
【００５９】
３では、図示される実施例によると、ＣＳＥ−２は、応答をＣＳＥ−１に送信する（２を参照して議論されるように成功または失敗のいずれか）。図１７で描写されるようなステップ５と同様に、３におけるａｃｋメッセージは、受信側ＣＳＥがＣＰＣ役割を正常に引き継ぐかどうかを示し得る、応答タイプ（ｒ＿ｔ）データフィールドを含み得る。４では、ＣＳＥ−２から受信される応答に関して、応答が、移行が成功したことを示す場合、ＣＳＥ−２はここで、ＣＰＣとして作用し得る。具体的には、ＣＳＥ−１は、それがもはやＣＰＣ役割を果たしておらず、ＣＰＣ役割に関連する全ての将来の着信トラフィックがＣＳＥ−２に転送されるはずであることをシステム内の他のＣＳＥ（例えば、ＣＰＣ関連処理または動作のために過去にＣＳＥ−１にコンタクトしたもの）に宣言し得る。代替として、ＣＳＥ−１がＣＳＥ−２から否定的応答を得た場合、否定的応答は、役割移行が失敗したことを示す。したがって、ＣＳＥ−１は、ＳＰが新しいＣＳＰプロセスを初期化するように、失敗をＳＰに知らせ得、これは、ここで詳細に説明されるケース２に図示される実施例と同一であり得る。
【００６０】
例示的ケース２では、役割プロファイルで示されるいかなるバックアップＣＳＥも存在しない場合、ＣＳＥ−１は、以下のステップ５−６に説明されるように、この問題を直接報告し得る。いくつかの場合では、セキュリティの観点から、ＳＰは、さらなる権限および信頼性を有し得る。５では、ＣＳＥ−１は、それがもはやＣＰＣとしての役割を果たすことができず、いかなる役割移行も行われることができないことをＳＰに知らせる。したがって、ＳＰは、少なくとも１つのＣＰＣからメッセージを受信し得、メッセージは、ＣＳＥがもはやＣＰＣであることが可能でないことを示す。メッセージに応答して、図１６および図１７を参照して上で説明される役割割当ステップのうちのいずれかまたは全てが、繰り返され得る。５におけるメッセージは、ＣＳＥがもはやＣＰＣであることが可能でないことをＳＰに知らせる値を含み得る、メッセージタイプ（ｍ＿ｔ）データフィールドを含み得る。６では、ＳＰは、この通知に関してＣＳＥ−１を確認し、新しいＣＳＰを初期化する。故に、応答メッセージは、本指示のための応答タイプフィールド（ｒ＿ｔ）を含み得る。ＣＰＣ役割が代替的な様式で（例えば、事前定義された稼働スケジュールに基づいて）いくつかの異なるＣＳＥによって担われる場合において、本明細書に説明される例示的役割移行はまた、複数のＣＳＥの間でＣＰＣを変更するために適用されることもできる。
【００６１】
ここでＣＰＭ割当に目を向けると、ＣＰＣとしてＣＳＥを割り当てることに関して上で説明される例示的方法が、利用されることができる。本再利用は、特に、多くのＭ２Ｍノードが容量制約されることを考慮して、開発サイクルを削減するため、およびＭ２Ｍノード上に展開されることができる軽量コードを開発するために有用である。しかしながら、いくつかの場合では、ＣＰＣ役割を割り当てることとＣＰＭ役割を割り当てることとの間に変形例が存在する。例えば、いくつかの場合では、ＣＰＭ役割をＣＳＥに割り当てるだけではなく、また、ＶＮＦプールアーキテクチャで定義されるような役割が、系統的な方法で作動するためにともにフックされることができるように、ＣＰＭをＣＰＣとリンクすることも必要であり得る。したがって、図１５−１８を参照して説明される例示的方法は、ＣＰＭ割当のために再利用され得、役割リンキングプロセス（ＲＬＰ）もまた、関連役割をともにリンクすることによって、ＶＮＦプールアーキテクチャを構築するように実施され得る。
【００６２】
したがって、実施例によると、ＳＰ（または概して、ノードもしくは装置）は、要求を複数の共通サービスエンティティに送信し得る。要求に応答して、ＳＰは、複数の共通サービスエンティティから複数の応答を受信し得る。各応答は、それぞれの共通サービスエンティティ（ＣＳＥ）が共通サービス機能（ＣＳＦ）プールマネージャ（ＣＰＭ）であることが可能かどうかに関連する情報を含み得る。ＳＰは、各応答からの情報を評価し、複数の共通サービスエンティティから少なくとも１つのＣＰＭを選択し得る。実施例では、要求は、各ＣＳＥの現在の容量および各ＣＳＥが自発的にＣＰＭになるかどうかについてクエリを行う。ＳＰは、少なくとも１つのＣＰＭのための役割プロファイルを生成し得る。役割プロファイルは、ＣＰＭの仮想マシンのための最小性能要件、ＣＰＭの仮想マシンのための好ましい実施時間、役割移行計画、および役割ソフトウェア更新スケジュールのうちの少なくとも１つを含み得る。実施例では、ＳＰは、複数のＣＳＦプールマネージャを選択し得、役割プロファイルはさらに、ＣＳＦプールマネージャの各々に関連付けられる稼働時間を含み得る。ＳＰは、役割プロファイルを複数の共通サービスエンティティのうちの少なくとも１つのＣＳＥに送信し得る。役割プロファイルに応答して、ＳＰは、少なくとも１つのＣＳＥから確認応答を受信し得、確認応答は、少なくとも１つのＣＳＥが、役割プロファイルで示されるように、その仮想マシンリソースを取っておき始めるであろうことを示し得る。実施例では、ＳＰは、ソフトウェアパッケージを少なくとも１つのＣＳＥに展開し得、パッケージは、少なくとも１つのＣＳＥが、ＣＰＭであるようにそれ自体を構成することを可能にする。別の実施例では、ＳＰは、指示を少なくとも１つのＣＳＥに送信し得、指示は、少なくとも１つのＣＳＥが、ＣＰＭであるようにそれ自体を構成することを可能にする。
【００６３】
図１９を参照すると、図示されるＲＬＰによると、ＳＰはすでに、上で説明されるプロシージャを使用することによって、ＣＰＣ役割をＣＳＥ−１に割り当てている。実施例では、ＳＰは、タイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭ役割を割り当てることを意図する。これを行うために、前述のように、先のＣＳＰおよびＲＡＰが、再利用されることができ、実施例の目的のために、ＣＳＥ−２がタイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭの役割を担っていると仮定される。
【００６４】
一実施例（ケース１）では、ＣＰＭは、ＲＬＰを完了するためにＣＰＣに積極的にコンタクトする。示されるように、１では、役割割当後に、ＳＰは、現在ＣＰＣの役割を担っているＣＳＥ（例えば、本場合ではＣＳＥ−１）についてＣＳＥ−２に直接知らせ得る。故に、ＣＳＥ−２のＶＰＥＳは、ＣＰＣ（例えば、本場合ではＣＳＥ−１）に積極的にコンタクトし、役割リンキングを遂行し得る。１において送信されるメッセージは、例えば、限定ではないが、以下等の種々のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＳＰからであることを受信側に知らせ得る。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、メッセージの目的を示す。例えば、メッセージタイプに基づいて、受信側ＣＳＥは、ＳＰがＣＰＣの識別を受信側ＣＳＥに知らせていることを把握するであろう。
●  ＣＳＥ−ＣＰＣ−ＩＤ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、現在ＣＰＣとして作用しているＣＳＥ−ＩＤを記憶し得る。
【００６５】
依然として図１９を参照すると、２では、図示される実施例によると、ＣＳＥ−２のＶＰＥＳは、ＣＳＥ−１のＶＰＥＳにコンタクトし、ＣＳＥ−２が、現在、タイプ−Ｘ  ＣＳＦインスタンスのための新しいＣＰＭとして作用しており、本タイプ（タイプ−Ｘ）のＣＳＦに関連する将来の要求を処理する準備ができていることをＣＳＥ−１に知らせる。いくつかの場合では、本プロセスは、両方のノードが相互を把握することができるように、登録のようなものである。３では、ＣＳＥ−１のＶＰＥＳは、通知を受信し、ファイル上にレジストリエントリを記録する、またはＣＰＣソフトウェアがＣＳＥ−２上で起動するＣＰＭソフトウェアにトークすることができるように、ＣＳＥ−１上でＣＰＣソフトウェアを構成する。例えば、ＣＰＣとＣＰＭとの間で送信されるメッセージ、およびＣＰＣとＣＰＭとの間でサポートされるビジネス論理は、ＣＰＣまたはＣＰＭソフトウェアパッケージで実装され得る。したがって、いくつかの場合では、残っている行うべきことは、それらの役割を現在担っているものと、（例えば、通信のためのそれらのＩＰアドレスまたはポート番号および任意の他のポイントオブコンタクト情報を交換することによって）相互と通信する方法とに関する、欠落している情報を記入することである。４では、ＣＳＥ−１のＶＰＥＳは、それが現在、役割リンキングを完了するようにＣＳＥ−２に接続していることを確認する（ａｃｋｓ）。本時点で、ＣＳＦ−ｘタイプインスタンスのためのＣＰＣの役割で作用するＣＳＥ−１および役割ＣＰＭで作用するＣＳＥ−２がここで、相互とリンクされ、ＶＮＦプールアーキテクチャで定義されるように、協働することができる。先のａｃｋｓと同様に、４におけるａｃｋメッセージは、ＲＬＰプロセスがＣＰＣにおいて完了したかどうかを示す、応答タイプ（ｒ＿ｔ）データフィールドを含み得る。５では、図示される実施例によると、ＣＳＥ−２のＶＰＥＳもまた、ＣＰＭソフトウェアがここで、ＣＳＥ−１上で起動するＣＰＣソフトウェアにトークすることができるように、ＣＳＥ−２上で起動するＣＰＭソフトウェアを構成する必要があり得る。
【００６６】
ここで、図１９で描写される別の実施例（ケース２）に目を向けると、ＣＰＣにコンタクトするようにＣＰＭをトリガする代わりに、ＳＰはまた、ＣＰＣが役割リンキングのために新たに割り当てられた／構成されたＣＰＭに積極的にコンタクトし得るように、ＣＰＣに知らせることもできる。６では、ＳＰは、タイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭの役割を担うであろうＣＳＥ（例えば、本場合ではＣＳＥ−２）が存在することをＣＳＥ−１に直接知らせ得、故に、ＣＳＥ−１のＶＰＥＳは、ＣＳＥ−２に積極的にコンタクトし、ＲＬＰを遂行し得る。したがって、ＳＰは、少なくとも１つのＣＳＥが、ＣＰＭであるＣＳＥにコンタクトすることができるように、ＣＳＦプールマネージャである別のＣＳＥの識別を少なくとも１つのＣＳＥに知らせ得る。同様に、ＳＰは、少なくとも１つのＣＳＥが、ＣＰＣであるＣＳＥにコンタクトすることができるように、ＣＳＦプールコントローラ（ＣＰＣ）である別のＣＳＥの識別を少なくとも１つのＣＳＥに知らせ得る。６において送信されるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＳＰからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、メッセージの目的を示す。例えば、メッセージタイプデータフィールドに基づいて、受信側ＣＳＥは、ＳＰが新しいＣＰＭとして現在作用しているものを受信側ＣＳＥに伝えていることを把握するであろう。
●  ＣＳＥ−ＣＰＭ−ＩＤ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、現在ＣＰＣとして作用しているＣＳＥ−ＩＤを記憶し得る。
●  ＣＳＦ−Ｔｙｐｅ−ＩＤ（ｃｓｆ−ｔｙ−ｉｄ）：本フィールドは、新しいＣＰＭによって管理されるであろう、対応するタイプのＣＳＦインスタンスを記憶し得る。
７では、３と同様に、ＣＰＣのＶＰＥＳは、ＳＰから直接、通知を受信し、ファイル上にレジストリエントリを記録する、またはＣＰＣソフトウェアを構成し、次いで、ＣＳＥ−２のＶＰＥＳに積極的にコンタクトする。８では、４と同様に、ＣＳＥ−１は、そのＣＳＥ−２にコンタクトし、それが現在ＣＰＣとして作用していることをＣＳＥ−２に知らせる。９では、５と同様に、ＣＳＥ−２のＶＰＥＳは、ＣＰＭソフトウェアがここで、ＲＬＰを完了するために、ＣＳＥ−１上で起動するＣＰＣソフトウェアにトークすることができるように、ＣＳＥ−２上で起動するＣＰＭソフトウェアを構成する。１０では、図示される実施例によると、ＣＳＥ−２は、ＲＬＰが完了したことを確認する。
【００６７】
ここでプール管理に目を向けると、ＣＰＭは、プール管理を行い得る。具体的には、異なるＣＳＥ上のＣＳＦソフトウェアインスタンスは、論理ＶＮＦプールに加入または退出することができ、かつ対応するＣＰＭによって管理されることができる。
【００６８】
図２０を参照すると、図示される実施例によると、ＣＳＦソフトウェアインスタンスは、ＣＰＭによって管理される、対応するＶＮＦプールに加入する。図２０に示されるように、ＣＳＥ−１は、ＣＰＣとして作用しており、ＣＳＥ−２は、タイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭとして作用しており、ＣＳＥ−３は、そのＶＭ上で起動するタイプ−Ｘ  ＣＳＦソフトウェアインスタンスを有する。したがって、実施例によると、ＶＮＦプールベースのサービス層が、作成されており、ある役割が、ネットワーク内のＣＳＥに割り当てられている。図２０に図示される実施例の目的のために、ＣＰＣが、ＶＮＦプールベースのシステムのポータルであるため、ネットワーク内のＣＳＥがＣＰＣの存在を認識していると仮定される。さらに、ＣＳＥ−３上で起動するタイプ−Ｘ  ＣＳＦインスタンスが存在し、そのビジネス論理によると、本ＣＳＦインスタンスが自発的にＶＮＦプールに参加し、ＣＰＭによって管理されると仮定される。そうするために、ＣＳＥ−３は、現在、ＣＳＥ−１である、ＣＰＣにコンタクトしようとする。代替として、ＣＰＭは、異なるＣＳＥにコンタクトし、対応するＣＳＦインスタンスをホストまたは起動しているかどうかを尋ね、かつそれらが自発的に対応するＶＮＦプールに加入するかどうかを尋ね得る。
【００６９】
依然として図２０を参照すると、１では、図示される実施形態によると、ＣＳＥ−３は、自発的に１つ以上のＶＮＦプールに加入する、ＣＳＥ−３上で起動するＣＳＦインスタンス（例えば、示されるようにＣＳＥ−３上で起動するタイプ−Ｘ  ＣＳＦインスタンス）を含む、ＣＳＦインスタンスリストとともに、要求をＣＳＥ−１に送信する。要求は、ＣＳＥ−３が、自発的にあるタイプのプールに加入する、あるタイプの１つ以上のＣＳＦインスタンスを含むことを示し得る。１におけるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＣＳＥからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、メッセージの目的を示す。例えば、メッセージタイプから、ＣＰＣは、送信側が自発的にＶＮＦプールに加入するＣＳＦインスタンス群を送信していることを把握するであろう。
●  ＣＳＦ−ｉｎｓｔａｎｃｅ−ｌｉｓｔ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、自発的にＶＮＦプールに加入する各ＣＳＦインスタンスについての詳細な情報を記憶する。情報は、そのＣＳＦタイプ、アクセスのポイント等を含み得る。
したがって、ＣＰＣは、共通サービスエンティティ（ＣＳＥ）から要求を受信し得、要求は、ＣＳＥが、自発的にあるタイプのプールに加入する、あるタイプの１つ以上の共通サービス機能（ＣＳＦ）インスタンスを含むことを示し得る。
【００７０】
２では、ＣＰＣは、そのレジストリリストをチェックし、知らされるべきであるＣＰＭ（例えば、示されるようにＣＳＥ−２によってとられるタイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭ）を確認する。したがって、ＣＰＣは、レジストリリストから、要求を知らされるべき１つ以上のＣＳＦプールマネージャを決定し得、１つ以上のマネージャは、あるタイプのそれぞれのプールに関連付けられる。加えて、いくつかの場合では、所与のタイプのＣＳＦに関して、ＣＳＥに割り当てられているいかなるＣＰＭ役割も存在しない場合がある。本場合では、ＣＰＣは、本プール加入要求を直接拒否し得る。３では、図示される実施例によると、ＣＰＣは、ＣＳＥ−３上で起動するタイプ−Ｘ  ＣＳＦインスタンスが、現在、タイプ−Ｘ  ＣＳＦのためのＶＮＦプールに加入することを申請しているという通知をＣＳＥ−２に送信する。３におけるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＣＰＣからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、本メッセージの目的を示す。例えば、メッセージタイプに基づいて、ＣＰＭは、そのプールに加入することを所望する新しいＣＳＦインスタンスが存在することを把握するであろう。
●  ＣＳＦ−ｉｎｓｔａｎｃｅ−ｌｉｓｔ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、現在のＣＰＭによって管理されるＶＮＦプールに自発的に加入する各ＣＳＦインスタンスについての詳細な情報を記憶する。情報は、例えば、そのＣＳＦタイプ、アクセスのポイント等を含み得る。
したがって、ＣＰＣは、通知を１つ以上のＣＳＦプールマネージャのうちの少なくとも１つに送信し得、通知は、ＣＳＥの１つ以上のＣＳＦインスタンスが、少なくとも１つのＣＳＦプールマネージャによって管理されているそれぞれのプールに加入することを申請していることを示し得る。
【００７１】
依然として図２０を参照すると、４では、図示される実施例によると、ＣＳＥ−２は、現在、タイプ−Ｘ  ＣＳＦのためのＶＮＦプールのためのＣＰＭとして作用しており、ＣＳＥ−２は、本ＣＳＦインスタンスがプールに加入し得ることを承認する。ＣＳＥ−２はさらに、将来の使用のために（例えば、インスタンスプロビジョニングのために）、在庫リストまたはスケジューリング計画の中に本インスタンスを追加する。したがって、ＣＳＦインスタンスがプールに加入することを承認されると、ＣＳＦインスタンスは、将来の使用のために在庫リストに追加され得る。５では、ＣＳＥ−２はさらに、そのタイプ−Ｘ  ＣＳＦインスタンスが、現在、ＣＰＭであるＣＳＥ−２によって管理されていることをＣＳＥ−３に知らせる。したがって、それが送信した要求に基づいて、ＣＳＥ−３は、ＣＰＭから送信されるメッセージを受信し得、メッセージは、１つ以上のＣＳＦインスタンスがＣＰＭによって管理されていることを示し得る。６では、ＣＳＥ−３は、本承認通知を確認し、また、その能力仕様としてＣＳＥ−３に関連付けられた性能データをＣＳＥ−２に送信する。ＣＳＥ−３は、ＣＳＥ−３に関連付けられた性能データを含む、ａｃｋメッセージを送信し得る。５におけるａｃｋメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  応答タイプ（ｒ＿ｔ）：このデータフィールドは、送信側ＣＳＥ上で起動するＣＳＦインスタンスが、ＣＰＭによって管理される準備ができていることを示す。
●  性能データ（ｐ＿ｄ）：このデータフィールドはまた、ＣＰＭが以降でＣＳＦインスタンスを選択するためにデータを使用することができるように、ある基本的性能データを含み得る。
７では、ＣＳＥ−２は、在庫リストを更新し、基本的性能データを追加し得る。このデータは、例えば、ＣＰＭがあるサービス層要求を処理するために本ＣＳＦインスタンスを割り当てる、または呼び出すことを意図するときに、参照として使用され得る。
【００７２】
ここで図２１を参照すると、ＣＳＦソフトウェアインスタンスは、例示的実施形態によると、プールから退出する。図２１に示されるように、ＣＳＥ−２は、タイプ−Ｘ  ＣＳＦインスタンスのためのＣＰＭとして作用しており、ＣＳＥ−３は、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスを有し、ＣＳＥ−３は、ＣＰＭによって管理されるＶＮＦプール（本場合ではＣＳＥ−２）の中にある。
【００７３】
第１の例示的ケース（ケース１）では、ＣＰＭは、プールからプールインスタンスを削除し始める。例えば、ＣＳＥ−２は、履歴性能統計（または任意の他の理由）に基づいて、タイプ−Ｘ  ＣＳＦインスタンス起動ＣＳＥ−３が、常に、望ましい性能を実現することができるわけではないことを決定し得る。したがって、ＣＳＥ−２は、プールから本メンバを削除することを決定し得、また、将来、プールメンバとしてそれを選択しない場合もある。他の原因が、プールインスタンスを削除するようにＣＰＭをトリガし得ることを理解されたい。
【００７４】
１では、図示される実施例によると、ＣＳＥ−２は、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスがプールから削除されるであろうという通知をＣＳＥ−３に直接送信する。１におけるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＣＰＭからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、本メッセージの目的を示す。例えば、メッセージタイプに基づいて、受信側ＣＳＥは、これがその上で起動するＣＳＦインスタンスの削除に関する通知であることを把握するであろう。
●  ＣＳＦ−ｉｎｓｔａｎｃｅ−ｌｉｓｔ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、プールから削除されるものである、受信側ＣＳＥ上で起動するＣＳＦインスタンスを記憶する。
したがって、ＣＳＥ−２は、削除通知をＣＳＥ−３に送信し得、削除通知は、１つ以上のＣＳＦインスタンスがプールから削除されていることを示し得る。実施例では、削除通知は、ＣＳＥ−３の１つ以上の履歴性能統計に基づいて送信され得る。２では、ＣＳＥ−３は、通知を受信し、（必要とされる場合）関連構成を行い得る。３では、ＣＳＥ−３は、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスがＣＰＭによって管理されないであろうことをＣＳＥ−２に確認する。３における確認応答（ａｃｋ）メッセージは、その上で起動するＣＳＦインスタンスのうちの１つ以上のものがプールから削除されるものであるという事実を受信側ＣＳＥがすでに認識していることを示し得る、応答タイプ（ｒ＿ｔ）データフィールドを含み得る。したがって、ＣＳＥ−２は、ＣＳＥ−３から削除確認応答を受信し得、削除確認応答は、ＣＳＥ−３が、１つ以上のＣＳＦインスタンスがプールから削除されていることを認識していることを示し得る。いくつかの場合では、ＣＳＦインスタンスがプールから退出するとき、ＣＳＦインスタンスによって処理されている継続中のタスクが存在し得る。一実施例では、ＣＳＦインスタンスは、全ての継続中のタスクを完了するまで、プールから退出することができない。別の実施例では、移行が、実施される。
【００７５】
依然として図２１を参照すると、第２の例示的ケース（ケース２）では、あるＣＳＦインスタンスは、ＶＮＦプールから離脱することを積極的に提案する。例えば、示されるように、ＣＳＥ−３は、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスが、そのＣＰＭによって割り当てられた要求処理をサポートすることができないことを決定する。したがって、削除通知は、ＣＳＦインスタンスがそれに割り当てられた処理をサポートすることができないというＣＳＥ−２の決定に基づいて送信され得る。本決定は、種々の理由、例えば、ソフトウェア問題または利用可能である低電力に基づき得る。故に、ＣＳＥ−３は、ＣＳＥ−２によって管理される対応するＶＮＦプールから離脱することを決定する。４では、図示される実施例によると、ＣＳＥ−３は、通知をＣＳＥ−２に直接送信し、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスがプールから離脱することを要求していることを示す。４において送信されるメッセージは、限定ではないが、実施例として提示される、以下のデータフィールドを含み得る。
●  送信側ＩＤ（ｓ＿ｉｄ）：メッセージ送信側の識別は、メッセージがＣＳＥからであることを受信側に知らせる。
●  メッセージタイプ（ｍ＿ｔ）：メッセージタイプは、メッセージの目的を示す。例えば、メッセージタイプに基づいて、ＣＰＭは、送信側ＣＳＥ上で起動するＣＳＦインスタンスがプールから離脱することを要求していることを把握するであろう。
●  ＣＳＦ−ｉｎｓｔａｎｃｅ−ｌｉｓｔ（ｃｓｅ−ｃｐｃ−ｉｄ）：本フィールドは、プールから離脱するであろう、受信側ＣＳＥ上で起動するＣＳＦインスタンスを記憶する。
【００７６】
５では、図示される実施例によると、ＣＳＥ−２は、通知を受信し、（必要とされる場合）関連構成を行い得る。ＣＳＥ−２はまた、本ＣＰＭのメンバ在庫から本ＣＳＦインスタンスを削除し得る。６では、ＣＳＥ−２は、その上で起動するタイプ−Ｘ  ＣＳＦインスタンスがもはやプールの中にないことをＣＳＥ−３に確認する。６におけるａｃｋメッセージは、それらのＣＳＦインスタンスが対応するＣＰＭによってプールから正常に削除されるかどうかを示し得る、応答タイプ（ｒ＿ｔ）データフィールドを含み得る。
【００７７】
上で説明されるように、本明細書に開示される実施形態は、ｏｎｅＭ２Ｍ機能アーキテクチャで実装されることができるが、また、Ｍ２Ｍサービス層を超えて適用されることもできる。例えば、上で説明されるように、ＮＦＶ技術は、サービス層を超えるタスクを含む（例えば、図１５参照）、ＶＮＦプールベースのサービス層を構築するように実装されることができる。例えば、ＣＳＦインスタンスは、ＮＦＶで考慮されるようなネットワーク機能ソフトウェアインスタンスであり得る。具体的には、ｏｎｅＭ２Ｍによって定義される既存のＣＳＦは、Ｍ２ＭノードのＶＭ上で起動するソフトウェアインスタンスとして実装されると仮定される。したがって、本明細書では、上で説明される方法は、Ｍ２Ｍサービス層の範囲を超えると見なされ得る、ＳＰによるシステム設定に関連し得ることを認識されたい。
【００７８】
実施例では、本明細書に説明される方法を実装することによって、ＣＰＣまたはＣＰＭソフトウェアは、それらがＣＰＣまたはＣＰＭとしての役割を果たすことができるように、ＣＳＥ上に展開され得る。故に、ＣＳＥによって受信されるサービス層要求メッセージはさらに、受信側ＣＳＥ自体によって処理される必要がある代わりに、処理のためにＣＰＣまたはＣＰＭに送信されることができる。したがって、本明細書に説明される実施形態は、受信側ＣＳＥが、受信されたサービス層要求メッセージを処理するために（ＣＰＣとしての役割を果たす）別のＣＳＥにコンタクトし得るため、既存のｍｃａおよびｍｃｃ参照点に影響を及ぼし得る。さらに、上で説明されるように、ＶＰＥＳが、使用されることができ、したがって、ＶＰＥＳは、図２２に示される例示的実施形態によると、サービス層内の新しいＣＳＦとして定義される。
【００７９】
ここで図２３および２４を参照すると、上で説明されるように、ＶＮＦプールベースの要求処理をサポートする、新しいｏｎｅＭ２Ｍリソースが、定義される。具体的には、ＶＮＦプールアーキテクチャで定義される、異なる役割と、これらの役割を担うことができる、異なるＣＳＥとが存在するため、例示的実施形態によると、＜ＣＰＣ＞リソース（図２３参照）および＜ＣＰＭ＞リソース（図２４参照）が、定義される。ＣＰＣおよびＣＰＭのリソース属性の説明は、それぞれ、表２および表３で以下に示される。
【００８０】
本明細書で定義されるｏｎｅＭ２Ｍリソース（図２３および２４参照）は、上で説明されるプールベースのサービス層によってサポートされる、新しい要求処理パラダイムを実現することができる。例えば、ＣＳＥが発信側から要求を受信する場合、これは、本要求をＣＳＥ（例えば、現在ＣＰＣとして作用しているもの）上でホストされる＜ＣＰＣ＞リソースのＵＲＩに直接転送することによって、ＶＮＦプールの中のＣＳＦインスタンスを使用することによって本要求を処理することができる。したがって、いくつかの場合では、要求が＜ＣＰＣ＞リソースに標的とされると、ＣＰＣとしての役割を果たすホスティングＣＳＥは、本要求がＶＮＦプールパラダイムに従って処理されるであろうことを把握するであろう。次に、ＣＰＣは、本要求を処理するためにコンタクトされる必要があるＣＰＭを決定し得、かつ対応する＜ＣＰＭ＞リソースを標的とする要求を転送し得る。同様に、ＣＰＭとしての役割を果たすＣＳＥが要求メッセージを受信すると、これは、その＜ＰｏｏｌＭｅｍｂｅｒＬｉｓｔ＞から適切なＣＳＦインスタンスを見出し、プールの中のあるＣＳＦインスタンスが要求を処理し、結果を返すことを可能にし得る。
【表２】
2019514118.tif 000004
【表３】
2019514118.tif 000005
【００８１】
ここで図２５を参照すると、図２３および２４に示されるｏｎｅＭ２Ｍリソースが、開示されるプールベースのサービス層を実現するために使用される方法の実施例が示されている。例示的方法は、Ｍ２Ｍ  ＳＰと、Ｍ２Ｍサーバと、複数のＭ２Ｍゲートウェイ（ＧＷ）と、複数のＭ２Ｍデバイスとを含む、システム（またはネットワーク）内で実施される。Ｍ２Ｍゲートウェイは、サービス層（ＳＬ）およびＳＬ上のＶＰＥＳをホストする、Ｍ２Ｍ  ＧＷ＃１と、ＳＬおよびＳＬ上のＶＰＥＳをホストする、Ｍ２Ｍ  ＧＷ＃２とを含む。Ｍ２Ｍデバイスは、ＳＬおよびＳＬ上のＶＰＥＳをホストする、Ｍ２Ｍデバイス＃１と、ＳＬをホストする、Ｍ２Ｍデバイス＃２とを含む。図２５の例示的システムは、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図していないことが理解されるであろう。他のデバイス、システム、および構成も、図２５に示されるネットワーク等のシステムに加えて、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として考慮される。
【００８２】
本実施例では、第１の段階は、ＳＰがＣＰＣ役割をＭ２Ｍサーバに割り当てるステップを含む。００１では、図示される実施例によると、ＣＰＣ割当のためのタスクが行われ、Ｍ２Ｍサーバが、ＣＰＣとしての役割を果たすように選択される。００２ａでは、ＳＰは、Ｍ２Ｍサーバ上で＜ＣＰＣ＞リソースを作成することを決定し、要求メッセージは、ＣＲＥＡＴＥ＜ｓｖｒＣＳＥＢａｓｅ＞／＜ＣＰＣ１＞として記述される。Ｍ２Ｍサーバが要求を受信した後、＜ＣＰＣ１＞リソースを作成し得る。いくつかの場合では、あるＣＰＭ役割がシステム内の他のＣＳＥ（例えば、Ｍ２Ｍ  ＧＷ＃１）に割り当てられる以降の時間に、それらは、上記のＲＬＰを使用してＣＰＣとリンクされるであろう。加えて、Ｍ２ＭサーバがＣＰＣとしての役割を果たし始めると、＜ＣＰＣ１＞リソースが既存のＩＥＴＦ  ＶＮＦプール参照アーキテクチャで定義されるようなサービスポータルと見なされ得るように、そのような情報（例えば、＜ＣＰＣ１＞リソースの存在）をネットワーク内の他のＣＳＥにいずれにしても積極的にブロードキャストし得る。代替として、他のＣＳＥは、ｏｎｅＭ２Ｍで定義されるような既存のリソース発見アプローチを使用して、＜ＣＰＣ１＞リソースを発見することを選定し得る。
【００８３】
依然として図２５を参照して、００２ｂでは、図示される実施例によると、Ｍ２Ｍサーバは、ＣＲＥＡＴＥ  Ｒｅｓｐｏｎｓｅ（ｌｏｃａｔｉｏｎ＝＜ｓｖｃＣＳＥＢａｓｅ／＜ＣＰＣ１＞）として記述される、応答を返信する。示されるように、ＣＰＭ役割がＧＷ＃１に割り当てられるときに、００３では、ＣＰＭ割当のためのタスクが行われ、ＧＷ＃１が、データ圧縮ＣＳＦのためのＣＰＭとしての役割を果たすように選択される。００４ａでは、ＳＰは、ＧＷ＃１上で＜ＣＰＭ＞リソースを作成することを決定し、要求メッセージは、ＣＲＥＡＴＥ＜ｇｗ１ＣＳＥＢａｓｅ＞／＜ＣＰＭ１＞として記述される。Ｍ２Ｍ  ＧＷ＃１が要求を受信した後、＜ＣＰＣ１＞リソースを作成し得る。００４ｂでは、ＣＲＥＡＴＥ  Ｒｅｓｐｏｎｓｅ（ｌｏｃａｔｉｏｎ＝＜ｇｗ１ＣＳＥＢａｓｅ／＜ＣＰＭ１＞）メッセージが、ＳＰに設定される。ＧＷ＃１がＣＰＭの役割を果たした後、プール管理を行い始めるであろう。例えば、００５では、示されるように、ＧＷ＃１は、データ圧縮ＣＳＦのためのプール管理を行い、デバイス＃１およびその他（ここでは示されていない）の上のそのようなＣＳＦインスタンスは、自発的にプールに加入する。００６では、ステップ００１において上記のようにｏｎｅＭ２Ｍで定義される既存のリソース発見アプローチを使用して、＜ＣＰＣ１＞リソースをすでに発見している場合がある、ＧＷ＃２は、種々のＣＳＦプールの中で提供されることができるＣＳＦインスタンスを調べることによって、ＣＰＣにコンタクトする。ＣＰＣが、データ圧縮が利用可能であることをＧＷ＃２に示した場合、これは、データ圧縮ＣＳＦに対応する、＜ｄａｔａｃｏｍｐｒｅｓｓｉｎｇ１＞と呼ばれるリソースを作成するようにＧＷ＃２にトリガし得る。いくつかの場合では、そのようなリソースは、いかなるリソース表現も含まないという意味で、仮想リソースであり得る。図示される実施例では、本リソースのＵＲＩは、＜ｇｗ２ＣＳＥＢａｓｅ＞／＜ｄａｔａｃｏｍｐｒｅｓｓｉｎｇ１＞である。
【００８４】
依然として図２５を参照すると、図示される実施例によると、００７では、デバイス＃２は現在、感知された画像を有しており、それを圧縮することを所望するため、アクセス要求をＭ２Ｍ  ＧＷ＃２上の＜ｄａｔａｃｏｍｐｒｅｓｓｉｎｇ１＞リソースに送信する。実施例として、ＵＰＤＡＴＥ動作が実施され得る。００８ａでは、要求メッセージは、ＵＰＤＡＴＥ＜ｇｗ２ＣＳＥＢａｓｅ＞／＜ｄａｔａｃｏｍｐｒｅｓｓｉｎｇ１＞として記述され、画像データもペイロードの中に含まれる。００９では、図示される実施例によると、ＧＷ＃２は、本要求を処理する能力を有していない。その間にも、要求が仮想リソース＜ｄａｔａｃｏｍｐｒｅｓｓｉｎｇ１＞に標的とするため、ＧＷ＃２は、本要求が本明細書に説明されるようなプーリング方式で処理される必要があることを認識し得る。故に、サービス要求を現在ＣＰＣとして作用しているＣＳＥ（示されるようなＭ２Ｍサーバ）に送信することによって、上記のプールベースのサービス層機構を使用し始めるであろう。いくつかの場合では、アドレス指定されたＵＲＩは、本要求がプールベースのサービス層パラダイムによって処理されるであろうことをＭ２Ｍサーバが把握するように、ＣＰＣリソースであろう。０１０ａでは、要求メッセージは、ＵＰＤＡＴＥ＜ｓｖｃＣＳＥＢａｓｅ／＜ＣＰＣ１＞として記述される。本メッセージはまた、ペイロードの中の画像データと、本要求を処理するために必要とされるＣＳＦインスタンスとを含み得る。０１１では、Ｍ２Ｍサーバは、要求を、図示される実施例ではＭ２Ｍ  ＧＷ＃１である、対応するＣＰＭに転送する。０１２ａでは、対応するメッセージは、ＵＰＤＡＴＥ＜ｇｗ１ＣＳＥＢａｓｅ／＜ＣＰＭ１＞として記述され、画像データが、ペイロードの中に含まれる。ＧＷ＃１が要求を受信すると、デバイス＃１上のＣＳＦインスタンスを選定し、要求を処理し得る。０１２ｂでは、図示される実施例によると、応答メッセージは、送信され、圧縮データは、ペイロードの中に含まれる。０１０ｂでは、ＵＰＤＡＴＥ応答が（例えば、ステップ０１０ａにおいて要求メッセージを繰り返すために）送信され得る。同様に、００８ｂでは、ＵＰＤＡＴＥ応答が（例えば、ステップ００８ａにおいて要求メッセージを繰り返すために）送信される。
【００８５】
ここで図２６を参照すると、例示的グラフィカルユーザインターフェース（ＧＵＩ）が示されている。上で説明されるように、ＳＰが本明細書で定義される役割を割り当てることに関与し得るため、ＧＵＩは、ＳＰが異なる役割を果たすにつれて異なるＣＳＥのリアルタイムステータスを監視することを可能にし得る。図２６は、システム像全体のための例示的ＧＵＩを描写し、それを通して、ＳＰは、異なる役割のリアルタイムステータスについてクエリを行うことができる。例えば、ＳＰは、その基本的性能を決定するためにＣＰＣとして現在作用しているＣＳＥ、システムの中で利用可能であるＣＰＭの数、所与のＣＰＭが現在管理しているＣＳＦインスタンスの数等についてクエリを行ってもよい。ＧＵＩは、所望に応じて代替的パラメータを監視し、クエリを行うために使用され得ることが理解されるであろう。いくつかの場合では、クエリは、ＳＰがネットワークのためのシステム像を有し得るように、文字列としてＧＵＩに入力されることができる。
【００８６】
ここで図２７を参照すると、例示的ＧＵＩが、単一のＣＳＦプールを監視するために示されている。示されるように、本ＧＵＩを使用して、ＳＰは、現在プールの中にあるＣＳＦインスタンスの数、これらのＣＳＦインスタンスを使用しているもの、およびこれらのＣＳＦプールインスタンスが由来している場所（例えば、ＣＳＥに由来する）をチェックまたは決定し得る。監視の上記の実施例は、包括的ではなく、ＳＰは、所望に応じて、ＧＵＩを使用して他の決定または検証を行い得ることが理解されるであろう。したがって、ＧＵＩは、種々のチャートまたは代替的視覚描写を介して、ユーザが関心を持つ種々の情報をユーザに提供し得ることが、さらに理解されるであろう。
【００８７】
図１３−２７およびそれに関連する説明は、プールベースのサービス層を構築するための方法および装置の種々の実施形態を図示する。これらの図、具体的には図１５−２１および２５では、１つ以上のノード、デバイス、機能、もしくはネットワークによって実施されている、種々のステップまたは動作が示されている。これらの図に図示されるノード、デバイス、機能、またはネットワークは、通信ネットワーク内の論理エンティティを表し得、以下に説明される図２８Ａまたは図２８Ｂに図示される一般的アーキテクチャのうちの１つを備え得る、そのようなネットワークのノードのメモリの中に記憶され、そのプロセッサ上で実行する、ソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得ることが理解される。すなわち、図１５−２１および２５に図示される方法は、図２８Ｃまたは２８Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードまたは装置のメモリの中に記憶されたソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図に図示されるステップを実施する。また、これらの図に図示される任意の伝送および受信するステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路（例えば、それぞれ、図２８Ｃおよび２８Ｄの回路３４または９７）によって実施され得ることも理解される。
【００８８】
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。本装置は、本明細書に説明される方法を達成するように、単独で、または相互と組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は、同義的に使用され得る。
【００８９】
図２８Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得、図１３−２７のうちのいずれかに図示されるデバイス、機能、またはノードのうちのいずれかは、図２８Ａ−Ｄに図示されるもの等の通信システムのノードまたは装置を備え得る。
【００９０】
図２８Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）、または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、および同等物等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
【００９１】
図２８Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常は、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの種々の異なるノード（例えば、サーバ、ゲートウェイ、デバイス）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下に説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。例示的Ｍ２Ｍデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。
【００９２】
図２８Ｂを参照すると、フィールドドメイン内に例証のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
【００９３】
図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。
【００９４】
依然として図２８Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。
【００９５】
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。
【００９６】
概して、図２８Ａならびに２８Ｂに図示されるサービス層２２および２２’等のサービス層（ＳＬ）は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ  Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ  Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ  Ｍ２Ｍアーキテクチャの種々の異なるノードで実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ  Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬで、３ＧＰＰ  ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥで、またはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスが、サーバ、コンピュータ、および他のコンピューティングデバイスもしくはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、もしくは１つ以上の既存のノードの一部としてのいずれかで実行する、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令、および同等物）で実装され得る。実施例として、サービス層またはそのコンポーネントのインスタンスは、以下に説明される図２８Ｃまたは２８Ｄに図示される一般的アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。
【００９７】
さらに、本明細書に説明される方法および機能性は、例えば、上記のネットワークおよびアプリケーション管理サービス等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。
【００９８】
図２８Ｃは、図１４、２２、２８Ａ、または２８Ｂに図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図１３、１５−２１、および２５に図示されるノード、デバイス、機能、またはネットワークのうちの１つ等のネットワークのノードの例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。図２８Ｃに示されるように、ノード３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。ノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本ノードは、例えば、図１３、１５−２１、および２５に説明される方法、または図２３および２４、表１−３、もしくは請求項の中のデータ構造に関連して、プールベースのＭ２Ｍサービス層を構築するステップを実装するノードであり得る。
【００９９】
プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および同等物であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはノード３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に組み込まれ得る、送受信機３４に結合され得る。図２８Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに統合され得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を実施し得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を実施し得る。
【０１００】
図２８Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、（例えば、図１５−２２および２５で）本明細書ならびに請求項に説明される、伝送および受信するステップを行うために、通信回路を制御し得る。図２８Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに統合され得ることが理解されるであろう。
【０１０１】
伝送／受信要素３６は、信号をＭ２Ｍサーバ、ゲートウェイ、デバイス、および同等物を含む、他のノードに信号を伝送し、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー、および同等物等の種々のネットワークおよびエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
【０１０２】
加えて、伝送／受信要素３６は、単一の要素として図２８Ｃで描写されているが、ノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、ノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、ノード３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
【０１０３】
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、ノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、ノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
【０１０４】
プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ＵＥ（例えば、図２６および２７）、具体的には、ＵＥと通信する下層ネットワーク、アプリケーション、または他のサービスのノードのステータスまたはノードの構成を反映するために、ディスプレイもしくはインジケータ４２上の照明パターン、画像、もしくは色を制御するように構成され得る。プロセッサ３２は、電源４８から電力を受容してもよく、ノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含み得る。
【０１０５】
プロセッサ３２はまた、ノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に結合され得る。ノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
【０１０６】
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る、他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）(R)モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および同等物を含み得る。
【０１０７】
図２８Ｄは、図１４、２２、２８Ａ、または２８Ｂに図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図１３、１５−２１、および２５に図示されるノード、デバイス等のネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。
【０１０８】
コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セキュリティ保護のための開示されたシステムおよび方法に関連付けられるデータを受信、生成、ならびに処理し得る。
【０１０９】
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、インタラプトを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。
【０１１０】
システムバス８０に結合されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読取専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含有する。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
【０１１１】
加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。
【０１１２】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子コンポーネントを含む。  
【０１１３】
さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図２８Ａおよび図２８Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含み得る。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、（例えば、図１５−２１および２５で）本明細書ならびに請求項に説明される、伝送および受信するステップを行うために使用され得る。
【０１１４】
本明細書に説明される方法およびプロセスのうちのいずれかは、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解されるであろう。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる、任意の他の物理媒体を含む。
【０１１５】
以下は、上記の説明に出現し得るサービス技術に関する頭字語のリストである。別様に規定されない限り、本明細書で使用される頭字語は、以下に列挙される対応する用語を指す。
【表４】
2019514118.tif 000006
【０１１６】
図に例証されるように、本開示の主題の好ましい実施形態を説明する際に、明確にするために特有の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
【図１】
2019514118.tif 000007
【図２】
2019514118.tif 000008
【図３】
2019514118.tif 000009
【図４】
2019514118.tif 000010
【図５】
2019514118.tif 000011
【図６】
2019514118.tif 000012
【図７】
2019514118.tif 000013
【図８】
2019514118.tif 000014
【図９】
2019514118.tif 000015
【図１０】
2019514118.tif 000016
【図１１】
2019514118.tif 000017
【図１２】
2019514118.tif 000018
【図１３】
2019514118.tif 000019
【図１４】
2019514118.tif 000020
【図１５】
2019514118.tif 000021
【図１６】
2019514118.tif 000022
【図１７】
2019514118.tif 000023
【図１８】
2019514118.tif 000024
【図１９】
2019514118.tif 000025
【図２０】
2019514118.tif 000026
【図２１】
2019514118.tif 000027
【図２２】
2019514118.tif 000028
【図２３】
2019514118.tif 000029
【図２４】
2019514118.tif 000030
【図２５】
2019514118.tif 000031
【図２６】
2019514118.tif 000032
【図２７】
2019514118.tif 000033
【図２８Ａ】
2019514118.tif 000034
【図２８Ｂ】
2019514118.tif 000035
【図２８Ｃ】
2019514118.tif 000036
【図２８Ｄ】
2019514118.tif 000037
【国際調査報告】
2019514118.tif 000038
2019514118.tif 000039
2019514118.tif 000040
2019514118.tif 000041
2019514118.tif 000042