JP6603399B2 - モノのインターネットエンドツーエンドサービス層サービス品質管理 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２００，７５２号（２０１５年８月４日出願、名称「Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

（Ｍ２Ｍ／ＩｏＴ ＳＬ）
Ｍ２Ｍ／ＩｏＴサービス層（ＳＬ）は、Ｍ２Ｍ／ＩｏＴデバイスおよびアプリケーションのための付加価値サービスを提供することを具体的に標的とする技術である。最近、いくつかの産業規格化団体（例えばｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１、および、ＥＴＳＩ ＴＳ １０２ ６９０ Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ （Ｍ２Ｍ） Ｆｕｎｃｔｉｏｎａｌ ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ２．０．１３）が、Ｍ２Ｍ／ＩｏＴデバイスおよびアプリケーションとインターネット／ウェブ、セルラー、企業、およびホームネットワークを用いた展開への統合に関連付けられた課題に対処するために、Ｍ２Ｍ／ＩｏＴ ＳＬを開発している。

マシンツーマシン／モノのインターネット（Ｍ２Ｍ／ＩｏＴ）サービス層（ＳＬ）は、Ｍ２Ｍ／ＩｏＴ指向能力の集合へのアクセスを提供し得る。いくつかの例示的能力は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１（参照することによってその全体として組み込まれる）を参照されたい。能力は、Ｍ２Ｍ／ＩｏＴ ＳＬによってサポートされるメッセージフォーマット、リソース構造、およびリソース表現を利用する、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能になり得る。

図１は、サービス層をサポートし得る例示的プロトコルスタックを図示する。プロトコルスタックの観点から、ＳＬ１０１は、アプリケーションプロトコル層１０２の上方かつアプリケーション層１０３の下方に位置し得、付加価値サービスをサポートされるアプリケーションに提供し得る。ＳＬ１０１は、「ミドルウェア」サービスとして分類され得る。

（セッション）
通信セッションは、典型的には、２つ以上の通信エンティティ（例えば、デバイス、アプリケーション等）間の情報の持続的双方向交換を伴う。通信セッションは、ある時点で確立され、種々の状況に基づいて、後の時点（例えば、セッションがタイムアウトした後、またはエンティティのうちの１つがセッションを終了することを決定するとき）で解除される。通信セッションは、エンティティ間の複数のメッセージの交換を伴い得、ステートフルであり得る。ステートフルとは、通信エンティティのうちの少なくとも１つが、通信セッションを維持することを可能にするために、セッション履歴についての情報（例えば、接続性、登録、セキュリティ、スケジューリング、およびセッション参加者に適用可能なデータ）を保存することを意味し得る。通信セッションは、プロトコルおよびサービスの一部として、ネットワークプロトコルスタック内の種々の層において実装され得る。例として、図２は、ネットワークノード１０４とネットワークノード１０５との間に確立された通信セッションを図示する。前述のネットワークノード１０４および１０５の通信セッションは、トランスポートプロトコル層１１０（例えば、ＴＣＰ接続）、セッションプロトコル層１０９（例えば、ＴＬＳおよびＤＴＬＳセッション）、ウェブトランスポートプロトコル層１０８（例えば、ＨＴＴＰおよびＣｏＡＰセッション）、Ｍ２Ｍ／ＩｏＴ ＳＬ１０７（例えば、ｏｎｅＭ２Ｍセッション）、およびアプリケーション特定のセッション１０６に基づき得る。

従来のアプリケーションセッションは、下層通信プロトコルまたはサービス層によってではなく、アプリケーション自体によって確立および管理される、２つ以上のアプリケーション間の通信セッションである。その結果、アプリケーションセッションは、余分なオーバーヘッドおよび複雑性をアプリケーションに追加し得る。例えば、従来のアプリケーションセッションは、アプリケーションが自らセッションを構成、確立、および管理することを要求し得る。これは、証明情報、識別子、ルーティング情報、発見情報、場所、トランザクション履歴、およびデータ等のセッションコンテキストの作成および管理を伴い得る。

Ｍ２Ｍ／ＩｏＴ ＳＬセッションは、ＳＬによってサポートされる付加価値セッション管理サービスによって促進される通信セッションである。これらのサービスは、ＳＬエンドポイント間のＳＬセッションを確立し、かつＳＬセッションおよびそのエンドポイントに関するコンテキストを収集および維持するための機構等の能力を含むことができる。ＳＬセッションは、２つ以上のＳＬセッションエンドポイント間に確立されることができ、これらのエンドポイントは、アプリケーションまたはＳＬインスタンスであり得る。しかしながら、最低でも、ＳＬの少なくとも１つのインスタンスは、セッションに参加し、ＳＬセッションのファシリテータとして機能しなければならない（例えば、必要ＳＬセッション管理機能性を提供する）。「ＳＬインスタンス」は、サービス層（例えば、デバイス上にホストされるサービス層）の単一のインスタンス化と考えられ得る。「ＳＬセッション」は、ＳＬとアプリケーションとの間の通信セッションである。ＳＬは、複数の同時ＳＬセッションをサポートすることができる。

図３は、Ｍ２Ｍ／ＩｏＴ ＳＬセッションの例を図示する。第１の例では、１１２において、ＳＬセッションが、単一アプリケーションとＳＬインスタンスとの間に確立される。これは、ＳＬインスタンスを横断して及ばないので、０−ホップＳＬセッションの例である。第２の例は、１１３において、２つのＳＬインスタンス間に確立されたＳＬセッションを示す。これは、０−ホップＳＬセッションの別の例である。第３の例は、１１４において、共通ＳＬインスタンス１１７を横断して及ぶ２つのアプリケーション間に確立されたＳＬセッションを示し、故に、これは、１−ホップＳＬセッションの例である。第４の例は、１１５において、２つのＳＬインスタンス（ＳＬインスタンス１１６およびＳＬインスタンス１１７）を横断して及ぶ３つのアプリケーション間に確立されたＭ２ＭＳＬセッションを示し、２−ホップＳＬセッションの例である。

Ｍ２Ｍ／ＩｏＴ ＳＬセッションの１つの利点は、それらが、それら自身のアプリケーションベースのセッションを確立および維持する必要性の負担からアプリケーションをオフロードするために使用されることができることである。これは、セッションの確立および維持に関わるオーバーヘッドの負担の主な部分がＳＬにオフロードされ、アプリケーションがこの責任を負わされないという点において、ＳＬセッションがアプリケーションセッションと異なるからである。ＳＬにオフロードされ得るオーバーヘッドのいくつかの例は、証明情報、識別子、ルーティング情報、発見情報、場所、トランザクション履歴、およびデータ等のセッションコンテキストの作成および管理を含むことができる。

ＳＬセッションは、１つ以上の下層トランスポートまたはアクセスネットワーク通信セッション（本明細書では、接続とも呼ばれ得る）の上部に層にされ得る。いくつかの例は、ウェブトランスポートプロトコルセッション（例えば、ＨＴＴＰセッション）、セッション層セッション（例えば、トランスポート層セッション（ＴＬＳ））、トランスポート層接続（例えば、伝送制御プロトコル（ＴＣＰ））、下層アクセスネットワーク接続（例えば、３ＧＰＰ、ブロードバンドＥｔｈｅｒｎｅｔ（登録商標）、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標））を含み得る。この階層化は、ＳＬセッションがより下層のセッションに関する持続性をサポートすることを可能にし、ＳＬセッションは、より下層のセッションの設定および解除から独立して持続し、維持されることができる。例えば、ＳＬセッションは、（例えば、電力節約方法およびモビリティに起因して）通常のネットワーク通信の過程の間に非常に典型的である、繰り返し設定および解除されているその下層ＴＣＰまたはＴＬＳセッションにかかわらず、持続することができる。

セッション参加者間のＭ２Ｍ／ＩｏＴ ＳＬセッションの確立は、ＳＬ登録プロセスの一部として、またはその後の別個のプロセスとして開始され得る。確立されると、ＳＬセッションは、セッション参加者およびそれらの間で生じる通信に関するＳＬコンテキストを収集および維持するために使用され得る。例えば、セッション参加者の登録状態およびセキュリティ証明情報、セッション参加者のためのサブスクリプション基準およびコンタクト情報、ＳＬリソース内に記憶されるセッション参加者データ、セッション参加者によって行われたトランザクションの履歴等のＳＬセッションコンテキストが、各セッションのために収集および維持され得る。セッション参加者間のＳＬセッションの終了は、ＳＬ登録解除プロセスの一部として、または登録解除が生じる前に行われる別個のプロセスとして開始され得る。

強調すべき着目に値する点は、ＳＬセッションの確立ならびに特定のＳＬセッションの寿命の間のＳＬセッションコンテキストの蓄積が、セッション参加者の代わりに有意な時間量および労力を伴い得ることである。故に、ＳＬセッションの持続的性質は、この持続性を欠くより下層のトランスポートおよびアクセスネットワークセッションと比較したその主要な付加価値差別化要因のうちの１つである。持続的ＳＬセッションは、この情報を自ら維持する必要がないように、アプリケーションの代わりにＳＬセッションコンテキストを維持するために使用され得る。加えて、より下層のセッションが解除され、ＳＬセッションコンテキストは、持続し得、より下層の接続が再確立された場合、このコンテキストは、依然として、アプリケーションに利用可能となるであろう。故に、このコンテキストは、非持続的下層トランスポートセッションまたはアクセスネットワーク接続から独立して維持されることができる。ＳＬセッションコンテキストのいくつかの例は、ＳＬ登録、サブスクリプション、証明情報、識別子、課金記録、ルーティング情報、発見情報、場所、トランザクション履歴、およびアプリケーションに関するデータを含み得る。

（ｏｎｅＭ２Ｍ ＳＬアーキテクチャ）
開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）は、図４に図示されるように、共通サービスエンティティ（ＣＳＥ）と呼ばれるサービス層を定義する。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、ＣＳＥに、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスを提供する。ＣＳＥは、「発見」または「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図５は、ｏｎｅＭ２Ｍのための例示的ＣＳＦを図示する。

ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）を有効にする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのＡＥを含むノードである。物理的マッピングの例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理的マッピングの例は、制約付きＭ２Ｍデバイス内に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＭＮのための物理的マッピングの例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。ＩＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＩＮのための物理的マッピングの例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。ｏｎｅＭ２Ｍエンティティを（ＡＥまたはＣＳＥのいずれも）含まないノードである非ｏｎｅＭ２Ｍノードも存在し得る。そのようなノードは、管理を含むインターワーキング目的のために、ｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。ｏｎｅＭ２Ｍシステム内でサポートされる種々のエンティティを相互接続する可能な構成は、図６に図示される。

ｏｎｅＭ２Ｍ ｉｎ ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ，Ｖｅｒｓｉｏｎ １．１．０（２０１４年８月）は、図５に示されるように、サービス層セッション管理サービス（例えば、ＳＳＭ ＣＳＦ１１９）を定義している。ｏｎｅＭ２Ｍは、ＳＬセッションをＳＳＭ ＣＳＦによって管理されるエンドツーエンドＳＬ接続としても定義している。ｏｎｅＭ２Ｍは、ＳＳＭ ＣＳＦのいくつかの要件も定義しているが、しかしながら、これらの要件を満たすアーキテクチャまたは設計をまだ定義していない。例えば、ｏｎｅＭ２Ｍは、セッション管理サービスが以下の特徴をサポートするものとすると述べている。
１） ＳＳＭ ＣＳＦは、ＡＥ間、ＡＥとＣＳＥとの間、またはＣＳＥ間のＳＬセッションを確立するための要求をサポートするものとする。
２） ＳＳＭ ＣＳＦは、複数の通過ＣＳＥホップに及ぶＳＬセッションをサポートするものとする。
３） ＳＬセッションを確立するための要求が許可される前に、ＳＳＭ ＣＳＦは、最初に、事前に確立された証明情報を使用して、要求側を認証するものとする。
４） ＳＳＭ ＣＳＦは、ＳＥＣ ＣＳＦを使用して、エンドツーエンド認証をサポートするものとする。認証されると、ＳＳＭ ＣＳＦは、要求側と標的セッションエンドポイントとの間のＭ２Ｍ ＳＬを確立するものとする。
５） ＳＳＭ ＣＳＦは、セッションＩＤを要求側に返すものとする。
６） ＳＳＭ ＣＳＦは、セッションポリシ、セッションルーティング情報、セッション記述子等のセッションの管理のための追加のセッション情報も維持するものとする。
７） ＳＳＭ ＣＳＦは、ＡＥ間、ＡＥとＣＳＥとの間、またはＣＳＥ間のＳＬセッションを終了するための要求をサポートするものとする。
８） ＳＳＭ ＣＳＦは、下層ネットワーク（ＵＮ）接続の上部へのＳＬセッションの階層化をサポートするものとし、ＳＳＭ ＣＳＦは、下層ネットワーク接続に関して、ＳＬセッションの持続性をサポートするものとする。
９） ＳＳＭ ＣＳＦは、下層ネットワーク接続の状態から独立して、アクティブＳＬセッションを維持するものとし、動的に解除および再確立されるネットワーク接続にロバストであるものとする。
１０） ＳＳＭ ＣＳＦは、ＳＬセッションアクティビティまたは状態に基づいて、ネットワーク接続が解除／再確立されるべきかどうかについての入力を他のＣＳＦおよび／または下層ネットワークに提供することをサポートするものとする。

ｏｎｅＭ２Ｍは、上記で定義された要件をサポートするためのＳＳＭ ＣＳＦの機能性をこれから定義する必要がある。概して、ｏｎｅＭ２Ｍへの寄稿として提出された提案される実装は、上記の要件１から７をサポートするためのＳＳＭリソース定義およびプロシージャを定義することに焦点を当てている。図７は、ｏｎｅＭ２Ｍ ＳＬセッション管理のための例示的リソース構造を図示する。＜ｓｅｓｓｉｏｎ＞リソースは、個々のＳＬセッションを管理するための属性およびサブリソースを含む。

ｏｎｅＭ２Ｍは、ｓｃｈｅｄｕｌｅ子リソースタイプを定義し、ｓｃｈｅｄｕｌｅ子リソースタイプは、ＣＳＥＢａｓｅ、ｒｅｍｏｔｅＣＳＥ、ｓｕｂｓｃｒｉｐｔｉｏｎ、またはｃｍｄｈＮｗＡｃｃｅｓｓＲｕｌｅｓを含む親リソースタイプの限定された組のためのスケジューリング情報を記憶するために使用され得る。その結果、ｏｎｅＭ２Ｍは、以下のタイプのスケジューリングをサポートする。
１） ＣＳＥは、そのＣＳＥＢａｓｅまたはｒｅｍｏｔｅＣＳＥ親リソース下のｓｃｈｅｄｕｌｅ子リソースをサポートすることによって、その到達可能性スケジュールを定義することができる。そうすることによって、ＣＳＥは、ＳＬ要求を送信または受信するためにそれが利用可能である時間を宣言することができる。
２） ＣＳＥリソースのサブスクライバ（例えば、アプリケーション）は、ＣＳＥがそれに通知を送信するときの時間を制御する通知スケジュールを定義することができる。サブスクライバは、ｓｃｈｅｄｕｌｅ子リソースをｓｕｂｓｃｒｉｐｔｉｏｎリソース下に作成することによって、これを行うことができる。
３） ＣＳＥは、ＣＳＥが特定の下層アクセスネットワークにアクセス可能であるときを定義する、アクセスネットワークスケジュールをサポートすることができる。これは、＜ｓｃｈｅｄｕｌｅ＞子リソースを＜ｃｍｄｈＮｗＡｃｃｅｓｓＲｕｌｅｓ＞リソース下に作成することによって行われる。

ｏｎｅＭ２Ｍ ｓｃｈｅｄｕｌｅリソースは、ｓｃｈｅｄｕｌｅＥｎｔｒｙ属性をサポートする。この属性は、表１に示されるように、６つのコンマで分離されたフィールドから成るストリングを使用してフォーマットされたスケジュールを定義する。各フィールドは、アスタリスク「＊」（それが任意の値に一致することを表す）、数字（それが特定の値に一致することを表す）、またはハイフン「−」によって分離される２つの数字（それがある範囲の値に一致することを表す）のいずれかであることができる。

例えば、「０−３０，３０，１２，１，＊，＊」のストリング値を有するｓｃｈｅｄｕｌｅＥｎｔｒｙは、秒が「０−３０」、分「３０」、時間「１２」、日「１」、月「＊」、および曜日「＊」の値を有するスケジュールに変換される。例えば、このｓｃｈｅｄｕｌｅＥｎｔｒｙが、ｓｕｂｓｃｒｉｐｔｉｏｎスケジュールのために使用される場合、これは、ＣＳＥが、毎月１日に、１２：３０から開始して３０秒の時間枠にわたってのみ、対応する通知をサブスクライバに送信する結果をもたらすであろう。全ての他の時間の間、ＣＳＥは、通知をバッファし、次のサブスクリプションスケジュール時間枠の開始を待つであろう。

（３ＧＰＰサービス能力エクスポージャ機能（ＳＣＥＦ））
図８は、例示的３ＧＰＰサービス能力エクスポージャ機能（ＳＣＥＦ）ベースのシステムアーキテクチャを図示する。３ＧＰＰは、最近、下層３ＧＰＰネットワーク能力をアプリケーション／サービスプロバイダにより良好にエクスポーズするためのフレームワークを定義している。３ＧＰＰ ＴＳ ２３．６８２，Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｆａｃｉｌｉｔａｔｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ，Ｖ１３．０．０（本明細書に組み込まれる）を参照されたい。これを達成するために、３ＧＰＰは、ＳＣＥＦを定義している。ＳＣＥＦ機能は、３ＧＰＰネットワークによって提供されるサービスおよび能力をセキュアにエクスポーズするための手段を提供する。ＳＣＥＦは、エクスポーズされたサービス能力の発見のための手段を提供する。ＳＣＥＦは、ＯＭＡ、ＧＳＭＡ、およびおそらく他の規格化団体によって定義された同種ネットワークアプリケーションプログラミングインターフェース（例えば、ネットワークＡＰＩ）を通したネットワーク能力へのアクセスを提供する。ＳＣＥＦは、下層３ＧＰＰネットワークインターフェースおよびプロトコルからのサービスを抽象化する。

本明細書に開示されるのは、アプリケーションがそのＥ２Ｅ ＱｏＳ要件を満たす様式で標的Ｍ２Ｍ／ＩｏＴデバイスとエンドツーエンド通信を行うことを可能にする、方法、システム、および装置である。例えば、アプリケーションは、アプリケーション規定スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、およびコスト要件に基づいて、標的デバイスと通信することができる。

具体的には、本開示は、以下を定義する。第１に、アプリケーションが、アプリケーション規定ＱｏＳ選好を有し、１つ以上のＳＬアドレス可能標的（例えば、Ｍ２Ｍ／ＩｏＴアプリケーション、デバイス、またはゲートウェイＳＬアドレス可能リソース）を標的とするＭ２Ｍ／ＩｏＴ ＳＬ通信セッションを確立、使用、および解除することを可能にする方法／プロシージャをサポートするＭ２Ｍ／ＩｏＴ Ｅ２Ｅ ＳＬ ＱｏＳ管理のためのシステム。

第２に、Ｍ２Ｍ／ＩｏＴ ＳＬが、下層ネットワークと相互作用し、アプリケーション規定Ｅ２Ｅ ＱｏＳ選好に基づいて、下層ネットワークＱｏＳレベルを構成すること、選択すること、および／またはそれに影響を及ぼすことを可能にするためのＥ２Ｅ ＳＬセッションベースの方法／プロシージャ。下層トランスポートネットワーク（２つのサービス層ノードを互いに相互接続する）は、アプリケーションによって規定されたサービス品質要件を用いて、サービス層によって構成され得る。

第３に、ＵＮが、ＳＬが異なるＥ２Ｅ ＳＬセッションのために使用すべきＵＮに関する情報に基づいた決定を行うことができるように、ＵＮ ＱｏＳおよび接続性関連情報をＭ２Ｍ／ＩｏＴ ＳＬと共有することを可能にする方法／プロシージャ。

第４に、Ｍ２Ｍ／ＩｏＴ ＳＬインスタンスが、複数の下層ネットワーク技術および／またはオペレータを横断して及ぶマルチホップ通信パスのためのＥ２Ｅ ＱｏＳを調整することを可能にするためのＥ２Ｅ ＳＬセッションベースの方法／プロシージャ。これらの方法が、複数のＳＬインスタンスおよびアプリケーションのＥ２Ｅ到達可能性スケジュールの調整を伴う場合、複数の下層ネットワークホップを横断する待ち時間およびジッタのバジェット編成、ならびに最小スループット、標的コスト、および要求されるセキュリティレベルを確実にすることも、達成される。

第５に、互いに通信するために必要なＳＬエンティティ間の接続性スケジュール、スループット、待ち時間、ジッタ、コスト、セキュリティレベル、およびエラー率等のＵＮ ＱｏＳパラメータのＥ２Ｅ整合を可能にするために、ＳＬインスタンス、アプリケーション、およびＵＮ間で交換されることができるＥ２Ｅ ＳＬセッションＱｏＳ情報の定義。

第６に、提案されるＭ２Ｍ／ＩｏＴ Ｅ２Ｅ ＳＬ ＱｏＳ管理システムのシステムレベルのｏｎｅＭ２Ｍおよび３ＧＰＰ例。

第７に、提案されるＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能のＡＰＩレベルの例。
本発明はさらに、例えば、以下を提供する。
（項目１）
装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、プロセッサによって実行されると、
アプリケーションのためのエンドツーエンドサービス品質要件を決定することと、
エンドツーエンドサービス層セッションが確立されるための要求を転送することであって、前記要求は、前記アプリケーションのための決定されたエンドツーエンドサービス品質要件を備えている、ことと、
遠隔装置との前記エンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、
前記遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、前記エンドツーエンドサービス層セッションを使用して通信することと
を含む動作を前記プロセッサに達成させる、装置。
（項目２）
前記メッセージは、前記確立されたエンドツーエンドサービス層セッションのためのサービス層識別を備えている、項目１に記載の装置。
（項目３）
前記アプリケーションは、前記サービス品質要件を下層ネットワークを構成するサービス層に提供し、前記下層ネットワークは、前記装置と別のサービス層装置とを接続する、項目１に記載の装置。
（項目４）
前記アプリケーションは、前記サービス品質要件を前記要求を介してサービス層に提供し、前記サービス層は、下層ネットワークを構成し、前記下層ネットワークは、前記装置と別のサービス層装置とを接続する、項目１に記載の装置。
（項目５）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小スループット閾値を備えている、項目１に記載の装置。
（項目６）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小到達可能性スケジュールを備えている、項目１に記載の装置。
（項目７）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小エラー率閾値を備えている、項目１に記載の装置。
（項目８）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小セキュリティレベル閾値を備えている、項目１に記載の装置。
（項目９）
システムであって、前記システムは、
ディスプレイと、
前記ディスプレイと通信可能に接続されている装置と
を備え、
前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
アプリケーションのためのエンドツーエンドサービス品質要件を決定することと、
エンドツーエンドサービス層セッションが確立されるための要求を送信することであって、前記要求は、前記アプリケーションのための決定されたエンドツーエンドサービス品質要件を備えている、ことと、
遠隔装置との前記エンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、
前記遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、前記エンドツーエンドサービス層セッションを使用して通信することと、
前記エンドツーエンドサービス層セッションのステータスを前記ディスプレイにパブリッシュすることと
を含む動作を前記プロセッサに達成させる、システム。
（項目１０）
前記メッセージは、前記確立されたエンドツーエンドサービス層セッションのためのサービス層識別を備えている、項目９に記載のシステム。
（項目１１）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小待ち時間閾値を備えている、項目９に記載のシステム。
（項目１２）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小ジッタ閾値を備えている、項目９に記載のシステム。
（項目１３）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小スループット閾値を備えている、項目９に記載のシステム。
（項目１４）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小到達可能性スケジュールを備えている、項目９に記載のシステム。
（項目１５）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小エラー率閾値を備えている、項目９に記載のシステム。
（項目１６）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小セキュリティレベル閾値を備えている、項目９に記載のシステム。
（項目１７）
方法であって、前記方法は、
ローカル装置のアプリケーションのためのエンドツーエンドサービス品質要件を決定することと、
エンドツーエンドサービス層セッションが確立されるための要求を送信することであって、前記要求は、前記アプリケーションのための決定されたエンドツーエンドサービス品質要件を備えている、ことと、
前記ローカル装置と遠隔装置との間の前記エンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、
前記遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、前記エンドツーエンドサービス層セッションを使用して通信することと
を含む、方法。
（項目１８）
前記メッセージは、前記確立されたエンドツーエンドサービス層セッションのためのサービス層識別を備えている、項目１７に記載の方法。
（項目１９）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小待ち時間閾値を備えている、項目１７に記載の方法。
（項目２０）
前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小ジッタ閾値を備えている、項目１７に記載の方法。

より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明から得られ得る。
図１は、サービス層をサポートする例示的プロトコルスタックを図示する。 図２は、例示的通信セッションを図示する。 図３は、例示的ＩｏＴ ＳＬセッションを図示する。 図４は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図５は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図６は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる例示的構成を図示する。 図７は、ｏｎｅＭ２Ｍ ＳＬセッション管理のための例示的リソース構造を図示する。 図８は、例示的３ＧＰＰ ＳＣＥＦベースのシステムアーキテクチャを図示する。 図９は、例示的エンドツーエンドＩｏＴデバイス通信使用事例を図示する。 図１０は、異なるアクセスネットワークを伴う例示的エンドツーエンド通信を図示する。 図１１は、Ｅ２Ｅ通信のためにＱｏＳを管理するための例示的ＩｏＴシステムを図示する。 図１２は、例示的ＩｏＴ Ｅ２Ｅ ＱｏＳ管理プロシージャを図示する。 図１３は、例示的Ｅ２Ｅ ＳＬセッションＱｏＳを図示する。 図１４は、Ｅ２Ｅ ＳＬセッション確立中のＵＮ ＱｏＳを管理するための例示的方法を図示する。 図１５は、Ｅ２Ｅ ＳＬセッションメッセージを送信する間のＵＮ接続を管理するための例示的方法を図示する。 図１６は、Ｅ２Ｅ ＳＬセッションメッセージを受信する間のＵＮ ＱｏＳを管理するための例示的方法を図示する。 図１７は、Ｅ２Ｅ ＳＬセッション解除を管理するための例示的方法を図示する。 図１８は、例示的ｏｎｅＭ２Ｍ／３ＧＰＰ Ｅ２Ｅ ＳＬ ＱｏＳ管理システムを図示する。 図１９は、例示的Ｅ２Ｅ ＳＬセッションＱｏＳ要件＜ｓｅｓｓｉｏｎ＞属性を図示する。 図２０は、例示的Ｅ２Ｅ ＳＬセッションＱｏＳ要件＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞属性を図示する。 図２１は、例示的＜ＵＮ＞リソースおよび属性を図示する。 図２２は、例示的Ｅ２Ｅ ＳＬセッションＱｏＳ要件＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞属性を図示する。 図２３は、＜ＡＥ＞リソースのための例示的＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞子リソースを図示する。 図２４は、＜ＡＥ＞リソースのための例示的＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞子リソースを図示する。 図２５は、例示的＜ＵＮＣＭ＞リソースおよび属性を図示する。 図２６は、例示的＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソースを図示する。 図２７は、例示的ＩｏＴサービス層ＯｐｅｎＦｌｏｗを図示する。 図２８は、例示的Ｅ２Ｅ ＱｏＳグラフィカルユーザインターフェースを図示する。 図２９は、ＳＬ ＱｏＳ関連付けられたコンポーネントを使用して生成される例示的ディスプレイを図示する。 図３０Ａは、ＩｏＴ Ｅ２Ｅサービス層ＱｏＳ管理事項が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図３０Ｂは、図３０Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図３０Ｃは、図３０Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図３０Ｄは、図３０Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

本明細書に開示されるのは、サービス層（ＳＬ）セッションの使用を通してエンドツーエンド（Ｅ２Ｅ）サービス品質（ＱｏＳ）をサポートする、方法、システム、および装置である。

図９は、アプリケーションが、広域ネットワークを横断して特定のＭ２Ｍ／ＩｏＴデバイスアプリケーションとのＥ２Ｅ通信を要求し得る、使用事例を図示する。第１の下層ネットワーク１２２および第２の下層ネットワーク１２４を介して、患者監視アプリケーション１２４と通信可能に接続されるセンサ１２１が、存在し得る。アプリケーションのタイプおよびデバイスのタイプに応じて、この通信は、特定のＥ２Ｅ ＱｏＳ要件を有し得る。例は、以下に提供される。第１の例示的シナリオでは、医師が、家庭用患者監視サービスと契約し、その患者のうちの１人を遠隔で監視する。サービスは、患者の身体上に位置するセンサ１２１（例えば、装着可能医療センサ）とエンドツーエンド通信セッションを確立する患者監視アプリケーション１２５を利用する。この患者の状態を適切に監視するために、医師は、患者がその薬剤（例えば、インスリン）を服用しているかどうかと、所望の効果を有するかどうかとを適切に査定するために、サービスが測定値（例えば、患者の血糖値レベル）をセンサ１２１から毎正時に得ることを要求する。異常測定値が検出される場合、サービスは、適宜、医師または家族に通知し得る。

図９を継続して参照すると、第１の例示的シナリオと同様に、第２の例示的シナリオでは、家庭用患者監視サービスが、第２の患者を遠隔で監視するために使用され得る。この第２の患者の状態を適切に監視するために、医師は、サービスが、臨界事象が検出される（例えば、患者のｐｕｌｓｅＯｘが臨界閾値に到達する）と、患者のセンサ１２１から生成され得るアラートを監視することを要求し得る。この特定の患者のために、医師は、任意のアラートに対して、センサ１２１から監視アプリケーション１２５へのエンドツーエンド待ち時間が５秒未満の遅延を有し、そして、サービスが適切な措置を講じることができることをサービスが確実にすることを要求する。適切な措置は、医師または緊急医療サービスに通知することを含み得る。

図９を継続して参照すると、第１の例示的シナリオと同様に、第３の例示的シナリオでは、同一家庭用患者監視サービスが、第３の患者を遠隔で監視するために医師によって使用される。この特定の患者の状態を適切に監視するために、医師は、サービスが、ビデオ監視を介して患者を監視し、患者の物理的活動を検出および追跡することを要求する。第３の患者のために、医師は、５Ｍｂｐｓの最小持続エンドツーエンドスループットを要求する監視がライブビデオフィードを用いて行われることをサービスが確実にすることを要求し得る。

バックエンドアプリケーションであり得るアプリケーションとフィールド内で展開されるデバイス（例えば、センサ１２１）との間の通信を指揮するＭ２Ｍ／ＩｏＴ（Ｍ２ＭまたはＩｏＴとも同義的に称される）展開は、最良実装ではないこともある。センサ１２１は、リソースが制約され得、それら自身の広域ネットワーク接続性を効果的にサポート可能ではないこともある。センサ１２１は、リソース限界（例えば、バッテリ）に負担をかけ得る持続的かつアクティブなネットワーク接続の維持をサポートすることが可能ではないこともあり得る。これらの理由のために、多くのＭ２Ｍ／ＩｏＴデバイスは、デバイスがネットワークへの接続性を喪失している期間中にデータがアクセスされることが可能であるように、デバイスに広域ネットワーク接続性およびデータ記憶サービスを提供する等の付加価値サービスのためのＭ２Ｍ／ＩｏＴゲートウェイおよびサーバを頼りにする。その結果、このＥ２Ｅ通信は、異なるネットワークプロバイダ（例えば、Ｓｐｒｉｎｔ、Ｖｅｒｉｚｏｎ等）によって所有され得る複数の下層アクセスネットワーク技術（例えば、３ＧＰＰ、ブロードバンドイーサネット（登録商標）、Ｗｉ−Ｆｉ等）を横断し得る。本明細書に開示されるのは、サービス層（ＳＬ）セッションの使用を通してエンドツーエンド（Ｅ２Ｅ）サービス品質（ＱｏＳ）をサポートする、方法、システム、および装置である。ｏｎｅＭ２Ｍ仕様の最初のリリースでは、以下のＱｏＳ中心要件が規定されたが、しかしながら、対応するソリューションは、ｏｎｅＭ２Ｍアーキテクチャまたはプロトコル仕様においてまだ定義されていない。
・ ｏｎｅＭ２Ｍシステムは、下層ネットワークへのサービス要求においてＭ２ＭアプリケーションのＱｏＳ選好を含むことをサポートするものとする。
・ ｏｎｅＭ２Ｍシステムは、サービスレベルにおけるＱｏＳ選好を伴うサービス要求を認可可能であるものとするが、サービスＱｏＳ要求の認可および許可、またはネゴシエーションのために、サービス要求内のＭ２ＭアプリケーションのＱｏＳ選好を下層ネットワークに渡すものとする。
・ ｏｎｅＭ２Ｍシステムは、保証ビットレート、遅延、遅延変動、損失比、およびエラー率等のパラメータを規定する異なるＱｏＳ−レベルをサポート可能であるものとする。
・ ｏｎｅＭ２Ｍシステムは、Ｍ２Ｍデバイスが到達されることができるときについての下層ネットワークによって提供される情報を受信し、利用可能であるものとする。
・ 下層ネットワークから利用可能である場合、ｏｎｅＭ２Ｍシステムは、Ｍ２ＭデバイスのＭ２Ｍサービス動作ステータスを維持し、下層ネットワーク接続性サービスステータスが変化した場合、それを更新可能であるものとする。

ＱｏＳプロトコルおよびＩｏＴ ＳＬ技術は、ｏｎｅＭ２Ｍ仕様のＱｏＳ中心要件に照らして図９に関して議論されたもののような使用事例のサポートに関して、以下の可能な欠点を有する。第１の可能な欠点は、区別されたサービス（ＤｉｆｆＳｅｒｖ）および統合されたサービス（ＩｎｔＳｅｒｖ）等のＱｏＳプロトコルが、多くのＩｏＴネットワーク展開内でＥ２Ｅ ＱｏＳ管理をサポートするために好適ではないことである。ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖは両方とも、ネットワークルータが各通信フローのための状態を維持することを要求する。この状態は、多くのＩｏＴルータが通常有していないリソース（例えば、メモリ、ＭＩＰＳ等）が利用可能であることを要求する。ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖは両方とも、ＱｏＳ関連制御情報を共有および維持するために、ルータ間の周期的通信を要求する。この余分なメッセージングオーバーヘッドは、多くのＩｏＴネットワークにとって好適ではない。多くのＩｏＴネットワークは、異なるタイプの下層アクセスネットワーク（例えば、３ＧＰＰ、ブロードバンドイーサネット（登録商標）、Ｗｉ−Ｆｉ、６ＬｏＷＰＡＮ等）を横断して及び、異なるネットワークプロバイダによって運営される、Ｅ２Ｅ通信パスを伴う。本明細書に述べられた理由から、ネットワークのいくつかは、ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖをサポートするために良好に装備されていない。ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖ展開は、多くの場合、オペレータのネットワーク毎に異なり得る（例えば、異なるルータポリシ、ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖのプロトコルおよび特徴のための異なるレベルのサポート）。したがって、ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖは、オペレータネットワークを横断してではなく、個々のオペレータのネットワーク内でのみ使用されることが一般的である。最後に、ＤｉｆｆＳｅｒｖおよびＩｎｔＳｅｒｖプロトコルは、デバイスが持続的ネットワーク接続性を維持しないので多くのＩｏＴネットワークにおいて重要である到達可能性スケジューリング等の特徴をサポートしない。

第２の可能な欠点は、従来のＩｏＴ ＳＬ技術が、アプリケーション使用事例のニーズを満たすＥ２Ｅ ＱｏＳ要件（例えば、スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、およびコスト）をアプリケーションが定義することを可能にする方法を欠いていることである。

第３の可能な欠点は、従来のＩｏＴ ＳＬ技術が、異なる技術タイプ（例えば、３ＧＰＰおよびブロードバンドイーサネット（登録商標））であるか、または異なるネットワークオペレータ（例えば、ＳｐｒｉｎｔおよびＶｅｒｉｚｏｎ）によって所有および運営され得る複数の下層ネットワークにわたって及ぶＥ２Ｅ通信を適切に管理する方法も潜在的に欠いていることである。

前述の欠点を参照して、図１０は、デバイスをバックエンドアプリケーションと一緒に相互接続する複数の下層アクセスネットワーク技術ホップを横断して及ぶＥ２Ｅ通信パスから成る典型的ＩｏＴネットワークを図示する。例えば、アプリケーション１３１とデバイス１３２との間のＥ２Ｅ通信は、セルラー１４１、ブロードバンドイーサネット（登録商標）１４２、およびＷｉ−Ｆｉ１４３等の３つの異なるアクセスネットワーク技術ホップを横断する通信を伴う。類似例も、アプリケーション１３４とデバイス１３５との間の通信、およびアプリケーション１３７とデバイス１３８との間の通信等、Ｅ２Ｅ通信のための複数のネットワークにわたる通信に関して示される。

以下は、図１０に取り込まれた展開のようなネットワーク展開に関連する可能な問題の例である。第１の例では、従来のＩｏＴ ＳＬ技術は、アプリケーションによって定義されたＥ２Ｅ到達可能性スケジュールが満たされることを可能にするために、ＳＬインスタンスの到達可能性スケジュールおよびそれらの下層ネットワーク（ＵＮ）への接続性スケジュールを調節することによって、それらがホップ毎様式でも、Ｅ２Ｅ様式でも互いに整合させられるための能力を欠いている。その結果、ＳＬインスタンス間の到達可能性スケジュールの不一致が生じ得る。これが発生すると、メッセージの「記憶そして転送」等のアクションが、それらが通信パス内の次のホップが到達可能になるまで待つ間、ホップ毎に（例えば、ＩｏＴゲートウェイおよびサーバ上で）ＳＬインスタンスにおいて生じ得る。原則として、「記憶そして転送」遅延は、アプリケーションがその要求される到達可能性スケジュールに従ってＥ２Ｅ方式でＩｏＴデバイスと通信することをそれらが妨げる場合の問題にすぎない。

第２の例では、従来のＩｏＴ ＳＬ技術は、ホップ毎相互接続のためにそれらが使用するＵＮの通信待ち時間を管理および調節するための能力を欠いている。加えて、それらは、アプリケーションによって定義されたＥ２Ｅ待ち時間バジェットが満たされることができるように、それらのホップ毎待ち時間を整合させる能力も欠いている。その結果、Ｅ２Ｅ待ち時間の管理は、現在のＩｏＴ ＳＬ技術によってサポートされていない能力である。これは、アプリケーションが要求される待ち時間バジェットに従ってＥ２Ｅ方式でＩｏＴデバイスと通信することを妨げる。

第３の例では、従来のＩｏＴ ＳＬ技術は、互いのホップ毎相互接続のためにそれらが使用するＵＮの通信スループットを管理および調節するための能力を欠いている。加えて、それらは、アプリケーションによって定義されたＥ２Ｅスループットが満たされることができるように、それらのホップ毎スループットを整合させる能力も欠いている。その結果、Ｅ２Ｅスループットの管理は、現在のＭ２Ｍ／ＩｏＴ ＳＬ技術によってサポートされていない能力である。これは、アプリケーションが要求されるスループットに従ってＥ２Ｅ方式でＭ２Ｍ／ＩｏＴデバイスと通信することを妨げる。

第４の例では、従来のＩｏＴ ＳＬ技術は、アプリケーションによって定義されたＥ２Ｅジッタバジェットが満たされることができるように、ＳＬメッセージ間の遅延（例えば、ジッタ）におけるＥ２Ｅ変動を管理するための能力、ひいては、それらのホップ毎ジッタを整合させるための能力を欠いている。その結果、Ｅ２Ｅジッタの管理は、現在のＩｏＴ ＳＬ技術によってサポートされていない能力である。これは、アプリケーションが要求されるジッタバジェットに従ってＥ２Ｅ方式でＭ２Ｍ／ＩｏＴデバイスと通信することを妨げる。

第５の例では、従来のＩｏＴ ＳＬ技術は、Ｅ２Ｅメッセージングエラー率を管理するための能力を欠いている。加えて、アプリケーションによって定義されたＥ２Ｅエラー率が満たされることができるように、それらのホップ毎メッセージングエラー率を管理するための能力も欠いている。その結果、Ｅ２Ｅメッセージングエラー率の管理は、現在のＭ２Ｍ／ＩｏＴ ＳＬ技術によってサポートされていない能力である。これは、アプリケーションがメッセージングエラー率に従って要求されるＥ２Ｅ方式でＭ２Ｍ／ＩｏＴデバイスと通信することを妨げる。

上で述べられた問題は、アプリケーションとＭ２Ｍ／ＩｏＴデバイスとの間のＥ２Ｅ通信パスが異なるタイプのＵＮを伴う複数のＳＬホップに及ぶとき、ならびにこれらのＵＮが異なるネットワークオペレータによって所有／運営されるとき、より可能性が高く、かつ複雑となる。これは、異なるＵＮを横断したＥ２Ｅ様式でのＱｏＳの管理が、管理することが困難であり得る異なるネットワーク技術を横断した調整を要求するという事実に起因する。同様に、異なるオペレータネットワークを横断したＥ２Ｅ様式でのＱｏＳの管理も、これらのオペレータを横断した調整を要求する。ＳＬホップ、ＵＮ、または異なるオペレータの数が増加するにつれて、問題の可能性も増加する。

図１１は、エンドツーエンド方式でＱｏＳを管理するための機構をサポートする、例示的システム１５０を図示する。システム１５０は、アプリケーション１５６がオンデマンドＥ２Ｅ ＱｏＳ要件を規定することを要求する使用事例等の使用事例をサポートするために使用され得る。オンデマンドＥ２Ｅ ＱｏＳ要件は、とりわけ、通信の到達可能性スケジュール、Ｅ２Ｅ待ち時間、Ｅ２Ｅスループット、Ｅ２Ｅジッタ、Ｅ２Ｅエラー率、Ｅ２Ｅセキュリティレベル、またはＥ２Ｅコストを含み得る。システム１５０は、ローカルエリアおよび広域ＵＮ（例えば、３ＧＰＰ１６１、ブロードバンドイーサネット（登録商標）１６２、Ｗｉ−Ｆｉ１６３、または６ＬｏＷＰＡＮ１６４）の多様な組み合わせを介して互いに相互接続されるＩｏＴサーバ（例えば、ＩｏＴサーバ１５２）と、ＩｏＴゲートウェイ（例えば、ＩｏＴゲートウェイ１５１）と、デバイス（例えば、ＩｏＴフィールドデバイス１５３またはＩｏＴデバイス１５４）とを含む。サーバおよびゲートウェイ上にホストされるのは、ＩｏＴ ＳＬ（例えば、ＩｏＴ ＳＬ１６６またはＩｏＴ ＳＬ１６５）のインスタンスである。フィールド内のデバイスならびにバックエンド内のデバイス上にホストされるのは、互いに通信するＩｏＴアプリケーション（例えば、ＩｏＴデバイスアプリケーション１５５およびＩｏＴアプリケーション１５６）である。例えば、患者のＩｏＴセンサまたはアクチュエータとバックエンド患者監視アプリケーションとの間のＥ２Ｅ通信である。

図１１を継続して参照すると、システム１５０は、サービス層接続マネージャ（ＳＬＣＭ）機能（例えば、ＳＬＣＭ１５７またはＳＬＣＭ１５８）と、アプリケーション接続マネージャ（ＡＣＭ）機能（例えば、ＡＣＭ１５９またはＡＣＭ１６０）と、下層ネットワーク接続マネージャ（ＵＮＣＭ）機能（例えば、ＵＮＣＭ１６７、ＵＮＣＭ１６８、またはＵＮＣＭ１６９）とを含む。一緒に、ＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能は、互いに相互作用し、Ｅ２Ｅ ＱｏＳのサポートにおいて、ＩｏＴデバイス、ゲートウェイ、サーバ、およびアプリケーションのエンドツーエンドＵＮ ＱｏＳおよび接続性をより知的に管理および構成し得る。代替として、システムは、これらの機能の一部のみをサポートし得る。例えば、システムは、ＳＬＣＭおよびＵＮＣＭ機能のみをサポートし得、ＡＣＭ機能をサポートしない。

ＳＬＣＭ機能は、ＩｏＴゲートウェイまたはサーバプラットフォーム上にホストされるｏｎｅＭ２Ｍ ＳＬ等のＩｏＴ ＳＬ内に内蔵され得る。別の例では、ＵＮＣＭ機能は、３ＧＰＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ、またはブロードバンドイーサネット（登録商標）等の種々のタイプの下層アクセスネットワーク技術内の機能としてサポートされ得る。

ＳＬＣＭ１５７は、ＩｏＴデバイスアプリケーション１５５が、例えば、ＩｏＴ ＳＬ１５２に対するＥ２Ｅ ＳＬセッションＱｏＳ要件を規定することを可能にし得る。これは、１つ以上の標的エンドポイントのための要求される到達可能性スケジュールを規定するアプリケーションを含み得る（例えば、そのアプリケーションが、標的Ｍ２Ｍ／ＩｏＴデバイスがそのＳＬ要求をサービスするために到達可能であることを要求するとき）。それは、その要求されるＥ２Ｅ待ち時間バジェット（例えば、ＳＬ要求および応答がアプリケーションと標的Ｍ２Ｍ／ＩｏＴデバイスとの間で進行する全体的往復待ち時間）を規定するアプリケーションを含むこともできる。それは、そのＥ２Ｅジッタバジェット（例えば、アプリケーションと標的Ｍ２Ｍ／ＩｏＴデバイスとの間で進行する連続ＳＬメッセージ間の遅延の容認可能変動）を規定するアプリケーションを含むこともできる。それは、そのＥ２Ｅエラー率（例えば、アプリケーションと標的Ｍ２Ｍ／ＩｏＴデバイスとの間でＥ２Ｅを通信するときの容認可能なエラーの率）を規定するアプリケーションを含むこともできる。ＳＬＣＭ１５７は、その要求されるＥ２Ｅスループット（例えば、アプリケーションと標的Ｍ２Ｍ／ＩｏＴデバイスとの間のスループット）を規定するアプリケーションも含み得る。

この情報を使用して、ＳＬＣＭ１５７は、全てのその登録者のためのＥ２Ｅ ＱｏＳ要件が充足されるように、その集合的なＳＬ登録者（例えば、アプリケーション）のＱｏＳ要件の組を分析し、そのＳＬインスタンスの構成をオンザフライで行うことをサポートし得る。これを行うために、ＳＬＣＭ１５７は、Ｅ２Ｅ ＳＬセッションの通信パス内のＳＬホップの各々のための到達可能性スケジュール、通信待ち時間、通信ジッタ、エラー率、通信スループット、セキュリティのレベル、およびコストの調節をオンザフライで行い得る。例示的Ｅ２Ｅ ＳＬセッション１４７は、ＳＬＣＭ１５７およびＵＮＣＭ１６７を介して有効にされる通信に基づき得る。これを達成するために、ＳＬＣＭ１５７は、そのＳＬインスタンスを他のＳＬインスタンスと相互接続する、ＵＮのうちの１つ以上のもの内にホストされるＵＮＣＭ機能と協働し得る。この協働は、ＳＬＣＭ１５７がＳＬ中心コンテキスト情報をＵＮＣＭ１６７に提供することを含み得、それは、ＵＮＣＭ１６７がその対応する下層アクセスネットワークに関連付けられた接続を管理することを可能にし得る。コンテキストは、アプリケーション（例えば、ＩｏＴデバイスアプリケーション１５５）またはＳＬ（例えば、ＩｏＴ ＳＬ１６６）規定の到達可能性スケジュール、アプリケーションまたはＳＬ規定の最大通信待ち時間（シングルホップおよび／またはエンドツーエンド）、アプリケーションまたはＳＬ規定のスループット（シングルホップおよび／またはエンドツーエンド）、アプリケーションまたはＳＬ規定のジッタ、アプリケーションまたはＳＬ規定のエラー率、セキュリティのレベル、およびコストを含み得る。

ＡＣＭ１６０が、例えば、ＩｏＴデバイスアプリケーション１５５のＥ２Ｅ ＳＬセッションＱｏＳ要件を決定するためにＩｏＴデバイスアプリケーション１５５によって使用され得る。そして、ＩｏＴデバイスアプリケーション１５５は、これらの要件をそのローカルＩｏＴ ＳＬ１６６によってホストされるＳＬＣＭ１５７に通信し得る。ＡＣＭ１６０は、Ｅ２Ｅ ＳＬセッションを設定するときにこれを行い得る。これらの要件は、１つ以上の標的エンドポイントのためのＩｏＴデバイスアプリケーション１５５特定の到達可能性スケジュール、要求されるＥ２Ｅ待ち時間バジェット、および要求されるＥ２Ｅスループット、ＩｏＴデバイスアプリケーション１５５規定されたジッタ、コストレベル、セキュリティレベル、ならびにＩｏＴデバイスアプリケーション１５５規定エラー率を含み得る。ＡＣＭ１６０は、類似要件を共有するためにブロードバンドイーサネット（登録商標）１６７（下層ネットワーク）によってホストされるＵＮＣＭ１６７とも通信し得る。

ＵＮＣＭ１６７は、例えば、ＳＬインスタンスが、対応するＵＮ（例えば、ブロードバンドイーサネット（登録商標）１６２）に対する接続性スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、およびコスト等のそのＵＮ ＱｏＳ要件を規定することを可能にする機能性をサポートし得る。そして、この情報は、例えば、指定されたＳＬインスタンスまたはＳＬセッションに関連付けられたＳＬメッセージが、ＳＬが定義した要件を満たす様式でブロードバンドイーサネット（登録商標）１６２によって処理され得るように、ＵＮ構成を調節するために、ブロードバンドイーサネット（登録商標）１６２によって使用され得る。

ＵＮＣＭ１６７は、ＵＮ中心情報バックアップをＳＬインスタンス（例えば、ＩｏＴ ＳＬ１６６）に通信するためにもブロードバンドイーサネット（登録商標）１６２によって使用され得る。例えば、ＵＮＣＭ１６７は、特定のＳＬセッション（例えば、ＳＬセッション１４７）に関する情報をＳＬＣＭ１５７に提供し得る。ＳＬＣＭ１５７とのこの情報の共有は、ＵＮＣＭ１６７が、アプリケーションおよびＳＬならびにエンドツーエンド通信の到達可能性スケジュールをより知的に管理することを可能にし得る。この情報は、ピアＳＬインスタンスまたはアプリケーションのためのＵＮ接続性におけるネットワーク輻輳または変化を含み得る。例えば、ＳＬＣＭ１５７は、ＵＮＣＭ１６７によってそれに提供されるブロードバンドイーサネット（登録商標）１６７の輻輳情報に基づいて、ＳＬセッション１４７のために１つのＵＮ（例えば、ブロードバンドイーサネット（登録商標）１６２）から別のＵＮ（例えば、３ＧＰＰ１６１）に切り替える決定を行い得る。

とりわけ、図１２−図１７に図示されるステップを行うエンティティは、図３０Ｃまたは図３０Ｄに図示されるもの等のデバイス、サーバ、またはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、とりわけ、図１２−図１７に図示される方法は、図３０Ｃまたは図３０Ｄに図示されるデバイスまたはコンピューティングシステム等のコンピューティングデバイスのメモリ内に記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、本明細書の中でもとりわけ、図１２−図１７に図示されるステップを行う。例では、Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴うが、図１１のＩｏＴデバイスアプリケーション１５５は、図３０ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１１のＳＬＣＭ１５７およびＳＬＣＭ１５８は、図３０ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図１２は、調整されたＥ２Ｅ方式でＩｏＴデバイス、ゲートウェイ、およびサーバ間のＵＮ ＱｏＳを管理するために使用され得るＳＬＣＭ機能およびＵＮＣＭ機能のための例示的メッセージフローを図示する。ステップ１７０では、前もって必要なアクションが存在する。例えば、ＵＮ接続性が、各デバイス、ゲートウェイ、およびサーバ間に確立される。各個々のホップ（Ｅ２Ｅではない）のためのエンティティ間の証明情報および認証の確立等の適切なＳＬセキュリティプロシージャが、行われる。ＳＬ登録が、ＳＬインスタンス間ならびにアプリケーションとそのローカルＳＬとの間で行われる。デバイス、リソース、およびサービスの発見が、アプリケーションによって行われる。ステップ１７１では、アプリケーション１５６は、それが１つ以上のデバイスアプリケーションと通信することを欲することを決定する。使用事例要件に基づいて、アプリケーション１５６は、それ自体と標的デバイスアプリケーション（例えば、ＩｏＴデバイスアプリケーション１５５）との間のＥ２Ｅ ＱｏＳ要件を決定する。例えば、とりわけ、Ｅ２Ｅ通信スケジュール（例えば、時刻）、Ｅ２Ｅ通信待ち時間（例えば、往復待ち時間は、定義された閾値を超えてはならない）、Ｅ２Ｅジッタ（例えば、センサ読み取り間の遅延の変動は、定義された閾値を超えるべきではない）、Ｅ２Ｅエラー率（例えば、センサ読み取りメッセージ内のＥ２Ｅエラーの率は、定義された閾値を超えるべきではない）、またはＥ２Ｅスループット（例えば、センサ読み取り／秒）。

図１２を継続して参照すると、ステップ１７２では、アプリケーション１５６は、それ自体とＩｏＴデバイスアプリケーション１５５との間のＥ２Ｅ ＳＬセッションを確立するための要求をＩｏＴ ＳＬ１６５（ＩｏＴサーバ１５１上にホストされ得る）に送信する。ステップ１７２の要求は、アプリケーション１５６がステップ１７１において定義したＥ２Ｅ ＱｏＳ要件を含む。ステップ１７３では、ＳＬＣＭ１５８は、ＵＮがＥ２Ｅ ＳＬセッションのために規定されたＱｏＳ要件を満たすための構成を必要とするかどうかをチェックする。ＳＬＣＭ１５８は、Ｅ２Ｅ ＳＬセッションＩＤを割り当て、さらに、次のＳＬホップを決定する。ＩｏＴサーバ１５１上にホストされるＩｏＴ ＳＬ１６５と関連のあるＳＬＣＭ１５８は、その現在の構成およびそのＵＮ（例えば、３ＧＰＰ１６１、Ｗｉ−Ｆｉ１６３、またはブロードバンドイーサネット（登録商標）１６２）の構成が、とりわけ、到達可能性スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、またはコストのために定義されたＥ２Ｅ ＳＬセッション定義ＱｏＳ要件を満たすことができるかどうかを決定する。ＳＬＣＭ１５８はまた、一意のＳＬセッションＩＤを導出する。ステップ１７４ａおよびステップ１７４ｂでは、ＳＬＣＭ１５８は、ＳＬＣＭ１５８をその次のホップＥ２Ｅ ＳＬセッションパートナに接続し得るＵＮの各々においけるＵＮＣＭ１６８またはＵＮＣＭ１６７と協働し、３ＧＰＰ１６１またはブロードバンドイーサネット（登録商標）１６２（または他のＵＮ）がステップ１７２において要求されるＥ２Ｅ ＳＬセッションのＱｏＳ要件を満たすために再構成され得る（またはすでに構成されている）かどうかを決定し得る。

図１２を継続して参照すると、ステップ１７５ａおよびステップ１７５ｂでは、３ＧＰＰ１６１のＵＮＣＭ１６８およびブロードバンドイーサネット（登録商標）１６２のＵＮＣＭ１６７は、とりわけ、スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、またはコスト管理を制御することに責任がある他のＵＮ機能と調整する。そうすることによって、各ＵＮＣＭは、ＵＮがＥ２Ｅ ＳＬセッションによって定義された規定されたＱｏＳ設定を用いてＥ２Ｅ ＳＬセッションと関連のあるメッセージを処理可能であるかどうかを決定する。ステップ１７６では、ＩｏＴサーバ１５１上にホストされるＳＬインスタンス（ＩｏＴ ＳＬ１６５）が、セッション要件を満たし得るＵＮ（例えば、ブロードバンドイーサネット（登録商標）１６２）を選択し、Ｅ２Ｅ ＳＬセッション確立要求をＩｏＴゲートウェイ１５２上にホストされるＳＬインスタンス（ＩｏＴ ＳＬ１６６）である次のＳＬホップに転送する。ＳＬセッションＩＤは、ステップ１７６のこの要求に含まれる。

図１２を継続して参照すると、ステップ１７７では、ＳＬＣＭ１５７は、ＵＮがＥ２Ｅ ＳＬセッションのために規定されたＱｏＳ要件を満たすための構成を必要とするかどうかをチェックする。ＳＬＣＭ１５７はまた、次のＳＬホップを決定する。ＩｏＴゲートウェイ１５２上にホストされるＩｏＴ ＳＬ１６６と関連のあるＳＬＣＭ１５７は、その現在の構成およびそのゲートウェイデバイスＵＮの構成がＥ２Ｅ ＳＬセッションＱｏＳ要件を満たし得るかどうかを決定する。この例では、要件が満たされ得る。ステップ１７４ａおよびステップ１７４ｂと同様に、ステップ１７８ａまたはステップ１７８ｂでは、ＳＬＣＭ１５７は、ＳＬＣＭ１５７をその次のホップＥ２Ｅ ＳＬセッションパートナに接続し得る６ＬｏＷＰＡＮ１６４のＵＮＣＭ１４９と協働し、６ＬｏＷＰＡＮ１６４がステップ１７２において要求されるＥ２Ｅ ＳＬセッションのＱｏＳ要件を満たすために再構成され（またはまた構成され）得るかどうかを決定し得る。ステップ１７５ａまたはステップ１７４と同様に、ステップ１７９ａまたはステップ１７９ｂでは、３ＧＰＰ１６１のＵＮＣＭ１６８およびブロードバンドイーサネット（登録商標）１６２のＵＮＣＭ１６７は、とりわけ、スケジュール、待ち時間、ジッタ、エラー率、スループット、セキュリティのレベル、またはコスト管理を制御することに責任がある他のＵＮ機能と調整する。そうすることによって、各ＵＮＣＭは、ＵＮが、Ｅ２Ｅ ＳＬセッションによって定義された規定されたＱｏＳ設定を用いて、Ｅ２Ｅ ＳＬセッションと関連のあるメッセージを処理可能であるかどうかを決定する。ステップ１８０では、ＩｏＴゲートウェイ１５２上にホストされるＩｏＴ ＳＬ１６６は、セッション要件を満たし得る６ＬｏＷＰＡＮ１６４を選択し、Ｅ２Ｅ ＳＬセッション確立要求を標的Ｅ２Ｅ ＳＬセッションエンドポイント（例えば、ＩｏＴデバイスアプリケーション１５５）に向かって次のＳＬホップに転送する。ステップ１８０の要求は、Ｅ２Ｅ ＳＬセッションＩＤを含み得る。代替として、ＩｏＴゲートウェイ１５２上にホストされるＳＬインスタンスは、ＩｏＴデバイスアプリケーションの代わりにプロキシし、ＩｏＴデバイスアプリケーション１５５の代わりにこの要求のサービス提供をハンドリングし得る。

図１２を継続して参照すると、ステップ１８１では、ＩｏＴデバイスアプリケーション１５５は、Ｅ２Ｅ ＳＬセッション確立要求を受信し、処理する。ＩｏＴデバイスアプリケーション１５５は、要求の発信側（例えば、ＩｏＴアプリケーション１５６）とのＥ２Ｅ ＳＬセッションに加わることに合意し、次いで、ＩｏＴデバイスアプリケーション１５５は、要求を承認することによって応答する。そうでなければ、それは、要求を否認するエラーを返す。応答は、対応する要求内で規定されたＳＬセッションＩＤを含む。ＩｏＴアプリケーション１５５は、ＩｏＴデバイスアプリケーション１５５がＥ２Ｅ ＳＬセッション確立要求を承認したことを示す応答を受信する。ステップ１８２では、ＩｏＴアプリケーション１５６は、次いで、ＩｏＴデバイスアプリケーション１５５と通信するためのＥ２Ｅ ＳＬセッション要求を生成する。ステップ１８２の要求を生成するとき、ＩｏＴアプリケーション１５６は、Ｅ２ＥセッションＩＤを含み得る。このＥ２ＥセッションＩＤは、Ｅ２Ｅ ＳＬセッション確立中に構成されたＥ２Ｅ ＱｏＳ設定が満たされるように要求を適切に処理するために、Ｅ２Ｅ通信パスにおいてＵＮおよびＳＬインスタンスによって使用され得る。例えば、ＵＮは、メッセージ内のＥ２Ｅ ＳＬセッションＩＤマーカを検出し（例えば、ディープパケットインスペクション技法を使用して）、このＳＬセッションＩＤを使用して、それが維持するＥ２Ｅ ＳＬセッションＱｏＳ要件に基づいて、メッセージを処理する。ステップ１８３では、ＩｏＴデバイスアプリケーション１５５は、ステップ１８２の要求を受信し、次いで、ＩｏＴアプリケーション１５６に返すＥ２Ｅ ＳＬセッション応答を生成する。ステップ１８３の応答を作成するとき、ＩｏＴデバイスアプリケーションは、Ｅ２ＥセッションＩＤを含み得る。このＥ２ＥセッションＩＤは、Ｅ２Ｅ ＳＬセッション確立中にセッションのために構成されたＥ２Ｅ ＱｏＳ設定が満たされるように応答を適切に処理するために、Ｅ２Ｅ通信パスにおいてＵＮおよびＳＬインスタンスによって使用される。

表２は、Ｅ２Ｅ ＳＬセッションの処理を補助するために提供され得る（例えば、ＳＬセッション確立要求内に含まれる）いくつかの例示的タイプのＳＬ中心情報要素を開示する。各Ｅ２Ｅ ＳＬセッションは、ＳＬ ＱｏＳ情報ならびにそれに関連付けられたＵＮ ＱｏＳ関連情報の両方を有し得る。この情報は、ＳＬセッションエンドポイント間のエンドツーエンドＳＬ ＱｏＳならびにＳＬセッションの各ホップ間のＵＮ ＱｏＳを管理するために使用されることができる。この情報は、ＳＬ（例えば、ＳＬＣＭ機能を使用して）、ＵＮ（例えば、ＵＮＣＭ機能を使用して）、ならびにＳＬセッションエンドポイントによって収集、維持、または共有されることができる。

表２の情報要素は、ＳＬセッション発信側（例えば、ＩｏＴデバイスアプリケーション１５６）がそれ自体と１つ以上の他の標的ＳＬセッションエンドポイントとの間のＥ２Ｅ ＱｏＳ要件を定義することを可能にし得る。同様に、ＳＬは、この情報を使用して、ＳＬセッション発信側のＥ２Ｅ ＱｏＳ要件を決定し、ひいては、本明細書に開示される方法を使用してそれらの充足を試みることができる。

表３は、Ｅ２Ｅ ＳＬ ＱｏＳのサポートにおいて使用され得るいくつかのタイプのＵＮ中心情報要素を提案する。例えば、Ｅ２Ｅ ＳＬセッションにおける各通信ホップのために、ＳＬ確立要求を開始または転送するエンティティは、この情報を利用し得る（例えば、それを要求自体に含めることによって）。この情報は、ＳＬ自体またはＵＮのいずれかによって、収集、追跡、および維持され得る。さらに、ある場合には、ＳＬおよびＵＮは、互いに協働し、この情報を交換し得る（例えば、ＳＬＣＭまたはＵＮＣＭを介して）。本開示は、これをサポートする方法を提案する。

図１３は、ＩｏＴフィールドデバイス１５３（例えば、ＩｏＴセンサ上にホストされるアプリケーション）、ＩｏＴゲートウェイ１５２、ＩｏＴサーバ１５１、およびＩｏＴアプリケーション１５６間に確立されている０−ホップ１８６、１−ホップ１８７、および２−ホップ１８８ Ｅ２Ｅ ＳＬセッションの使用事例の例を図示する。これらの場合の各々では、ＩｏＴアプリケーション１５６が、Ｅ２Ｅ ＳＬセッションの確立を開始する。０−ホップ１８６では、ＩｏＴアプリケーション１５６は、ＩｏＴサーバ１５１とＥ２Ｅ ＳＬセッションを確立する。１−ホップ１８７では、ＩｏＴアプリケーション１５６は、ＩｏＴゲートウェイ１５２とＥ２Ｅ ＳＬセッションを確立する。２−ホップ１８８では、ＩｏＴアプリケーション１５６は、ＩｏＴフィールドデバイス１５３上にホストされるアプリケーションとＥ２Ｅ ＳＬセッションを確立する。

示される使用事例の確立されている３つのＥ２Ｅ ＳＬセッションでは、ＩｏＴサーバ１５１およびＩｏＴゲートウェイ１５２上にホストされるＳＬによってサポートされる各ＳＬＣＭ機能は、ＵＮによってサポートされる各ＵＮＣＭ機能と通信し得る。そうすることによって、ＳＬＣＭおよびＵＮＣＭは、Ｅ２Ｅ ＳＬセッションのＥ２Ｅ ＱｏＳ要件が満たされることができるように、Ｅ２Ｅ ＳＬセッションの各ホップのために使用されるＵＮ ＱｏＳの適切な選択および構成を調整する。

ＵＮ ＱｏＳを管理し、Ｅ２Ｅ ＳＬ ＱｏＳ要件を充足する方法が、本明細書に開示される。具体的には、これらの方法は、Ｅ２Ｅ ＳＬセッション確立中、Ｅ２Ｅ ＳＬセッション通信中、およびＥ２Ｅ ＳＬセッション解除中のＵＮ ＱｏＳの管理を伴う。

図１４は、Ｅ２Ｅ ＳＬセッション確立中のＵＮ ＱｏＳを管理するための例示的方法を図示する。図１４に示されるプロシージャに前もって必要なものは、ＳＬ登録者（例えば、ＩｏＴアプリケーション１５６）が、それ自体と標的ＳＬセッションエンドポイント（例えば、ＩｏＴデバイスアプリケーション１５５）との間のＳＬセッションの確立のための要求を生成することである。この要求では、ＩｏＴアプリケーション１５６は、要求内に、表２に規定されたＳＬ中心情報と、おそらく、適用可能である場合、表３に規定されたアクセスネットワーク中心情報と等の情報を含むことによって、Ｅ２Ｅ ＳＬセッションのためのそのＱｏＳ要件を規定し得る。Ｅ２Ｅ ＳＬセッション確立要求がＳＬ登録者のローカルＳＬによって受信された時点が、図１４に定義されたプロシージャが開始する時点である。このプロシージャは、それが標的ＳＬセッションエンドポイントに向かって伝搬させられているときのＥ２Ｅ ＳＬセッション確立要求、ならびに、それが要求を発信したＳＬ登録者に向かって戻るときの対応する応答を処理するために使用される。提案されるプロシージャの詳細なステップは、以下に定義される。ステップ２０１では、受信側（例えば、ＩｏＴサーバ１６５、ＩｏＴゲートウェイ１５２、またはＩｏＴデバイスアプリケーション１５５等の中間ＳＬインスタンスまたは標的ＳＬセッションエンドポイント）が、着信要求を検出し、それがＳＬセッション確立要求または応答であるかどうかをチェックする。このチェックは、ＳＬメッセージ内のヘッダ情報を分析することによって行われ得る。ヘッダ情報は、ＳＬメッセージのＳＬメッセージタイプを示し得る。ステップ２０１の受信されたＳＬメッセージが、ＳＬセッション確立要求である場合、ステップ２０２に進む。ステップ２０１において受信されたＳＬメッセージが、ＳＬセッション確立応答である場合、ステップ２１１に進む。

図１４を継続して参照すると、ステップ２０２およびステップ２０３では、ステップ２０１のＳＬメッセージが、ＳＬセッション確立要求である場合、受信側のＳＬＣＭは、以下に議論されるように、とりわけ、ＳＬ到達可能性スケジュールチェック、ＵＮ接続性チェック、ＳＬホップ待ち時間チェック、ＳＬホップスループットチェック、ＳＬホップジッタチェック、ＳＬホップエラー率チェック、ＳＬホップコストレベルチェック、またはＳＬホップセキュリティレベルチェック等のＱｏＳチェックおよびそれ自体とその近隣ＳＬセッションホップパートナとの間の可能な整合を行い得る。チェックを行う前、ＳＬＣＭは、Ｅ２Ｅ ＳＬセッションがすでに存在するかどうかを検証するためのチェックを行い得ることに留意されたい。ＳＬ到達可能性スケジュールチェックでは、ＳＬ到達可能性スケジュールをチェックし、整合させるために、受信側のＳＬＣＭまたはＡＣＭは、その現在のＳＬ到達可能性スケジュールを要求内に規定されたＥ２Ｅ ＳＬセッション到達可能性スケジュールと比較する。このチェックは、受信側のＳＬがアクティブであり、確立されている新しいＳＬセッションのために要求される時間の間にＳＬメッセージを処理するために到達可能であるかどうかを検証する。これを行うために、受信側のＳＬＣＭまたはＡＣＭは、現在の到達可能性スケジュール時間枠が要求内に規定されたものと整合させられている（または整合させられていない）かどうかをチェックする。これは、要求内に規定された各到達可能性時間枠の開始および終了時間を受信側の現在の到達可能性時間枠の開始および終了時間と比較することによって行われ得る。ＵＮ接続性チェックでは、ＵＮ接続性スケジュールをチェックし、整合させるために、受信側のＳＬＣＭまたはＡＣＭは、その到達可能性時間枠の各々に対して、それがサポートする異なるタイプのＵＮを新しいＳＬセッションによって要求されるものと比較し得る。これらは、要求内に規定され得るか、または要求側が、事前にこの情報を受信側に利用可能にし得るかのいずれかである。そのように事前にこの情報を受信側に利用可能にすることにおいて、受信側のＳＬＣＭまたはＡＣＭは、ＳＬセッションのための要求される到達可能性時間枠の各々に対して、少なくとも１つの共通ＵＮがアクティブであり、受信側とその近隣ＳＬセッションホップパートナとの間の必要接続性を提供しているかどうかをチェックし得る。

図１４のステップ２０２−２０３を継続して参照すると、ＳＬホップ待ち時間チェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、この特定のＳＬホップのための待ち時間情報をＵＮＣＭから取得し得る。ＵＮＣＭから利用不可能である場合、ＳＬＣＭまたはＡＣＭは、それ自体とその近隣ＳＬセッションホップパートナとの間の通信待ち時間を比較し、着信要求内に規定された要求されるＥ２Ｅ ＳＬセッション待ち時間未満であるかどうかを決定することによって、待ち時間チェックを行い得る。このチェックを行うために、受信側のＳＬＣＭまたはＡＣＭは、１つ以上の別個のＳＬ ｐｉｎｇ要求（または同等物）を自動生成し、ＳＬＣＭまたはＡＣＭは、それをその近隣ＳＬセッションホップパートナに向かって標的とし、返される対応する応答を受信し得る。待ち時間を測定するために、ＳＬＣＭまたはＡＣＭは、各ＳＬ ｐｉｎｇが送信される時間および応答が受信される時間を測定し得る。ＳＬＣＭまたはＡＣＭは、次いで、減算および平均し、待ち時間を算出し得る。２つ以上のＵＮが受信側およびその近隣ＳＬセッションホップパートナに接続している場合、ＳＬＣＭまたはＡＣＭは、各ＵＮに対してこの待ち時間チェックを行い、それらを比較し、ＳＬセッション待ち時間要件を満たす最良ＵＮを選択し得る。ＳＬＣＭまたはＡＣＭは、待ち時間測定を頻繁に繰り返す必要がないように、これらの待ち時間測定を維持し、将来のＳＬセッション要求のためにそれらを再使用し得る。ＳＬＣＭまたはＡＣＭはまた、周期的に、この待ち時間チェックを再び行い、待ち時間がＳＬセッション待ち時間要件を継続して満たすかどうかを監視し得る。該当しない場合、ＳＬＣＭまたはＡＣＭは、エラーまたはイベントを発信側ＳＬセッションエンドポイントに信号伝達し、これを示し得る。ＳＬホップスループットチェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、スループット情報をＵＮＣＭから取得し得る。利用不可能である場合、ＳＬＣＭまたはＡＣＭは、それ自体とその近隣ＳＬセッションホップパートナとの間の通信スループットを比較し、着信ＳＬセッション確立要求内に規定された要求されるＥ２Ｅ ＳＬセッションスループットを満たすか、またはそれを超えるかどうかを決定することによって、スループットチェックを行い得る。このチェックを行うために、受信側のＳＬＣＭは、繰り返される一連のＳＬ ｐｉｎｇ要求を自動生成し、ＳＬＣＭは、それらをその近隣ＳＬセッションホップパートナに向かって標的にし、返される対応する応答を受信し得る。ＳＬＣＭは、ＳＬセッション確立要求内に規定された最大ＳＬメッセージサイズに一致するように各ｐｉｎｇの長さを構成し得る。スループットを測定するために、ＳＬＣＭは、それが応答を受信するレートを測定し得る。２つ以上のＵＮが受信側およびその近隣ＳＬセッションホップパートナと接続する場合、ＳＬＣＭは、各ＵＮに対してこのスループットチェックを行い、それらを比較し得る。ＳＬＣＭは、頻繁に測定を繰り返す必要がないように、これらのスループット測定を維持し、将来のＳＬセッション要求のためにそれらを再使用し得る。ＳＬＣＭまたはＡＣＭは、周期的に、このスループットチェックを再び行い、スループットがＳＬセッション要件を継続して満たすかどうかを監視し得る。該当しない場合、ＳＬＣＭまたはＡＣＭは、エラーまたはイベントを発信側ＳＬセッションエンドポイントに信号伝達し、これを示し得る。

図１４のステップ２０２−２０３を継続して参照すると、ＳＬホップジッタチェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、ＵＮＣＭからジッタ情報を取得し得る。利用不可能である場合、ＳＬＣＭまたはＡＣＭは、スループットチェックにおいて上で述べたような類似プロシージャを使用して、ジッタチェックを行い得る。スループットを測定する代わりに、ＳＬＣＭまたはＡＣＭは、連続したｐｉｎｇ応答間の遅延の変動を測定し得る。ＳＬホップエラー率チェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、ＵＮＣＭからエラー率情報を取得し得る。利用不可能である場合、ＳＬＣＭまたはＡＣＭは、スループットチェックに関して本明細書に説明されるような類似プロシージャを使用して、エラー率チェックを行い得る。スループットを測定する代わりに、ＳＬＣＭまたはＡＣＭは、一連の要求および応答に対するエラー率を測定し得る。ＳＬホップコストレベルチェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、ＵＮＣＭからコスト情報を得て、それを要求内に規定されたコスト要件（例えば、バジェット）と比較し、ＵＮを使用するコストがＥ２Ｅ ＳＬセッション要件と整合させられるかどうかを決定し得る。ＳＬホップセキュリティレベルチェックでは、受信側のＳＬＣＭまたはＡＣＭは、利用可能である場合、ＵＮＣＭからセキュリティ情報を得て、それを要求内に規定されたセキュリティ要件と比較し、ＵＮ内でサポートされるセキュリティのレベルのいずれかがＥ２Ｅ ＳＬセッション要件と整合させられるかどうかを決定し得る。

図１４を継続して参照すると、ステップ２０４では、受信側のＳＬＣＭまたはＡＣＭは、ステップ２０３においてチェックで失格になったＱｏＳパラメータ（該当する場合）の調節を試行する。ＳＬＣＭまたはＡＣＭは、各それぞれのＵＮ（サポートされる場合）内のＵＮＣＭと協働することによって、受信側とその近隣ＳＬセッションホップパートナとの間のＵＮにおけるＱｏＳパラメータの調節を試みる。これを行うために、ＳＬＣＭまたはＡＣＭは、それが１つ以上のＵＮＣＭに送信する要求を作成し得る。この要求では、ＳＬＣＭまたはＡＣＭは、Ｅ２Ｅ ＳＬセッションＩＤ、受信側およびその近隣ＳＬセッションホップパートナのＵＮアドレス、ならびに受信側とその近隣ＳＬセッションホップパートナとの間の要求されるＵＮ ＱｏＳパラメータ（表２および表３毎の定義参照）等の情報のタイプを含み得る。

図１４のステップ２０４を継続して参照すると、この情報を使用して、ＵＮＣＭは、受信側とその近隣ＳＬセッションホップパートナとの間のＱｏＳ要件（例えば、スケジュール、待ち時間、ジッタ、エラー率、スループット、コスト、セキュリティ）を決定し得る。ＵＮＣＭは、次いで、ＵＮ内の他の機能と調整し、ＳＬセッションＱｏＳ要件を満たすようにＵＮを構成することが可能であるかどうかを決定し得る。これは、このＵＮを経由して受信側とその近隣ＳＬセッションホップパートナとの間に生じる全ＳＬ通信に対して行われ得るか、または代替として、それは、この特定のＳＬセッションに関連付けられ、この特定のＥ２Ｅ ＳＬセッションＩＤでマークされたメッセージに対してのみＵＮによって選択的に行われ得るかのいずれかである。以下に議論されるのは、ＳＬ到達可能性スケジュール調節またはＵＮ接続性スケジュール調節等のいくつかのＱｏＳパラメータ特定の調節プロシージャである。ＳＬ到達可能性スケジュール調節では、ＳＬ到達可能性スケジュールが互いに整合させられない場合、受信側のＳＬＣＭまたはＡＣＭは、受信側のＳＬ到達可能性時間枠を調節することを試み、それらを整合させることを試み得る。これを行うために、受信側のＳＬＣＭまたはＡＣＭは、任意の他の既存のＳＬセッションに影響を及ぼさないように配慮しなければならない。これは、ＳＬＣＭまたはＡＣＭがその現在のＳＬセッションのために要求される受信側の既存のＳＬ到達可能性時間枠を確立されている新しいＳＬセッションによって要求される到達可能性時間枠と集約することによって、達成され得る。そうすることによって、ＳＬＣＭまたはＡＣＭは、全ＳＬセッションが別のものと共存し得ることを確実にし得る（例えば、セッションスケジュールを互いに整合させること、または整合させないことによって）。ＵＮ接続性スケジュール調節では、適正なＵＮ接続性が存在しない場合、ＳＬＣＭまたはＡＣＭは、各それぞれのＵＮにおけるＵＮＣＭと通信し、それらをＥ２Ｅ ＳＬセッション要件と整合させるために、ＵＮ接続性スケジュールを修正することを試み得る。これを行うために、ＳＬＣＭまたはＡＣＭは、それがＵＮＣＭに送信する要求を作成し得る。この要求では、ＳＬＣＭまたはＡＣＭは、受信側および／またはその近隣ＳＬセッションホップパートナのためのＳＬセッションＩＤおよび接続性スケジュール等の情報を含み得る。ＵＮＣＭは、次いで、ＳＬセッション通信のために要求される時間中、それらが互いに整合するように、この情報を使用して、他のＵＮ機能と調整し、接続性スケジュールを修正することを試み得る。前述の接続性スケジュールチェックおよび整合アクションが成功する場合、プロシージャは、待ち時間チェックを行うことに進み、そうでなければ、それは、ステップ２１０に進み、受信側は、適切な接続性が受信側とその近隣ＳＬセッションホップパートナとの間に確立され得ないことを示すエラー応答を準備および送信する。有用であり得る追加の情報を提供するために、達成可能スケジュールが、このエラー応答内で返され得る。

図１４を継続して参照すると、ステップ２０５では、要求されるＱｏＳパラメータ調節が成功する場合、プロシージャは、ステップ２０６に進み、標的ＳＬセッションエンドポイントが遠隔でホストされているかどうかをチェックし、そうでなければ、ステップ２１０に進み、そこで受信側は、要求されるＱｏＳが満たされ得ないことを示すエラー応答を準備および送信する。有用であり得る追加の情報を提供するために、達成可能ＱｏＳパラメータ値が、このエラー応答内で返され得る。ステップ２０６では、受信側のＳＬＣＭまたはＡＣＭは、ＳＬセッションを確立するために要求内に規定された標的ＳＬセッションエンドポイントがローカルでホストされているかどうか、または別のホップに転送されなければならないかどうかをチェックする。これは、受信側アドレスと標的ＳＬセッションエンドポイントのアドレスを比較することによって行われ得る。要求が別のＳＬホップに転送されなければならない場合、プロシージャは、ステップ２０７に進み、転送されるべき要求を準備する。そうでなければ、プロシージャは、ステップ２０９に進み、ＳＬセッション確立応答を準備する。要求は、エンドツーエンドサービス層セッションが確立されるまで、１つのサービス層ノードから別のサービス層ノードに転送され得る。ステップ２０７では、ＳＬセッション確立要求は、標的ＳＬセッションエンドポイントが受信側によってホストされていないので、次のホップに転送される。要求を転送する前、受信側のＳＬＣＭまたはＡＣＭは、要求を更新し、後続ホップが消費するための待ち時間、ジッタ、およびエラー率等のあるＱｏＳパラメータのために残っているＥ２Ｅ ＱｏＳバジェットの量を示し得る。これを行うために、受信側のＳＬＣＭまたはＡＣＭは、そのホップによって消費された測定ＱｏＳパラメータを要求内で搬送されるＥ２Ｅ ＳＬセッション値から減算し得る。そうすることによって、次のホップが要求を受信するとき、各ＱｏＳパラメータのための残りのバジェットが、Ｅ２Ｅ通信パスにおける前のホップを考慮するために調節されているであろう。

図１４を継続して参照すると、ステップ２０８では、Ｅ２Ｅ ＳＬセッション確立要求は、次のホップに転送される。ステップ２０９では、標的ＳＬセッションエンドポイントは、受信側によってホストされている。この要求を受信すると、受信側は、標的が存在することを検証すること、および発信側ＳＬセッションエンドポイントが標的とＥ２Ｅ ＳＬセッションを確立するための適切な許可を有することを検証すること等のアクションを行い得る。受信側は、正常ＳＬセッション確立応答をまとめ得る。応答は、Ｅ２Ｅ ＳＬセッションＩＤ、成功応答コード、またはホップ毎Ｅ２Ｅ ＳＬ層セッション確立中に測定された測定Ｅ２Ｅ ＱｏＳパラメータ等の情報を含み得る。測定されたＥ２Ｅ ＱｏＳパラメータは、ホップ毎Ｅ２Ｅ ＳＬ層セッション中に測定された残りの待ち時間、ジッタ、コスト、およびエラー率バジェット、ならびに最小限のスループット等の測定値を含み得る。この応答は、次いで、それが要求を受信した、受信側の同一近隣ＳＬセッションホップパートナに返信され得る。この応答を受信すると、近隣ＳＬセッションホップパートナは、この同一プロシージャ（ステップ２１１参照）を使用して応答を処理し得る。ステップ２１０では、受信側は、Ｅ２Ｅ ＳＬセッション確立要求を成功裏に処理することができなかった。受信側は、エラー応答をそれが要求を受信したその同一近隣ＳＬセッションホップパートナに返し得る。この応答を受信すると、近隣ＳＬセッションホップパートナは、この同一プロシージャ（ステップ２１１参照）を使用して応答を処理し得る。

図１４を継続して参照すると、ステップ２１１では、受信側のＳＬＣＭは、Ｅ２Ｅ ＳＬセッション確立応答をチェックし、それが成功応答であるか、エラーであるかを決定する。それが成功応答である場合、プロシージャは、ステップ２１３に進む。そうでなければ、プロシージャは、ステップ２１２に進む。スエラー応答の場合のステップ２１２では、ＳＬセッション状態は、削除される。受信側ＳＬＣＭは、それが維持するＳＬセッション状態を除去し、さらに、それがサポートする下層ネットワーク内の各ＵＮＣＭと通信し、それらにＳＬセッション状態および構成を解体させる。これは、Ｅ２Ｅ ＳＬセッション確立処理中に構成されたＳＬセッションに基づくＵＮ接続性、待ち時間、ジッタ、エラー率、およびスループット構成を除去することを含み得る。ステップ２１３では、受信側は、ＳＬセッションＩＤをチェックすることに基づいて、それがＥ２Ｅ ＳＬ発信側エンドポイントであるかどうかをチェックし、受信側が有し得る任意の未処理のＥ２Ｅ ＳＬセッション確立要求に一致するかどうかを決定する。一致する場合、次いで、受信側は、応答を処理し、Ｅ２Ｅ ＳＬセッション確立要求が成功したかどうかを決定する。該当しない場合、次いで、プロシージャは、ステップ２１５に進み、応答を次のホップに転送する。ステップ２１４では、Ｅ２Ｅ ＳＬセッションは、Ｅ２Ｅ ＳＬ発信側エンドポイントによって成功裏に確立されたと考えられる。ステップ２１５では、受信側のＳＬＣＭまたはＡＣＭは、応答がＥ２Ｅ ＳＬセッション発信側エンドポイントに向かって進むように、このセッションのためのＥ２Ｅ ＳＬセッション応答をその対応する近隣ＳＬセッションホップパートナに転送する。

図１５は、Ｅ２Ｅ ＳＬセッションメッセージを送信する間のＵＮ接続を管理するための例示的方法を図示する。確立されると、Ｅ２Ｅ ＳＬセッションは、Ｅ２Ｅ ＳＬセッション通信要求および応答を送信および受信するために使用され得る。ステップ２２１では、Ｅ２Ｅ ＳＬセッション参加者（例えば、ＳＬセッションエンドポイントまたは中間ＳＬインスタンス）は、すでに確立されている特定のＥ２Ｅ ＳＬセッションを介して、Ｅ２Ｅ ＳＬセッション通信要求またはＥ２Ｅ ＳＬセッション通信応答メッセージを送信する必要があることを決定する。ステップ２２２では、Ｅ２Ｅ ＳＬセッションを介して応答を送信するために、参加者は、応答を作成し、要求内に規定されたＥ２ＥセッションＩＤに一致するように、Ｅ２ＥセッションＩＤを構成する。応答は、アプリケーション特定の応答情報等の他の情報も同様に含み得る。応答のための標的宛先は、ＳＬＣＭによって決定される。これを行うために、ＳＬＣＭまたはＡＣＭは、それが開始または再標的化する一つ一つのＥ２Ｅ ＳＬセッション要求のために維持するローカル状態を使用する（以下のステップ２２３に説明されるように）。Ｅ２Ｅ ＳＬセッションＩＤを使用して、ＳＬＣＭまたはＡＣＭは、応答を送信すべき場所をルックアップする。ステップ２２３では、Ｅ２Ｅ ＳＬセッションを介して要求を送信するために、参加者は、要求を作成し、標的とするＥ２Ｅ ＳＬセッションエンドポイントへの宛先アドレスを構成する。それは、この標的エンドポイントと通信するために使用することを欲するＳＬセッションに対応するＥ２ＥセッションＩＤも含む。要求は、アプリケーション特定の要求情報等の他の情報も同様に含み得る。要求を送信すると、ＳＬＣＭまたはＡＣＭは、要求のためのＳＬセッション状態を維持する。ＳＬＣＭまたはＡＣＭは、それが要求を発信したかどうか、またはそれが要求を再標的化したかどうかを維持する。要求を再標的化した場合に対して、ＳＬＣＭは、それが再標的化した要求を受信したＳＬエンティティを記録する。この情報は、Ｅ２Ｅ ＳＬセッションＩＤを使用して記録される。

図１５を継続して参照すると、ステップ２２４では、Ｅ２Ｅ ＳＬセッション通信要求／応答は、標的（要求の場合）または発信側（応答の場合）Ｅ２Ｅ ＳＬセッションエンドポイントに向かってルーティングされる必要がある。したがって、ＳＬＣＭまたはＡＣＭのためのこのプロセスに関わるアクションのうちの１つは、Ｅ２Ｅ ＳＬセッション通信要求／応答内に規定された宛先アドレスを分析し、それをルーティングするための次のＳＬホップを決定することであり得る。これは、ＳＬＣＭまたはＡＣＭが、要求／応答内に含まれるＥ２Ｅ ＳＬセッションＩＤをＳＬルーティング状態と比較し、次のＳＬホップを決定することを伴い得る。これは、次のホップＳＬのＩＰアドレス等のルーティング可能アドレスをもたらし得る。このルーティング可能アドレスは、次いで、ＵＮアドレスに分解され得る。ステップ２２５では、メッセージは、次いで、ＳＬＣＭまたはＡＣＭからＥ２Ｅ ＳＬセッション確立中に割り当てられた対応するＵＮにハンドオフされる。ＵＮがこのメッセージを受信すると、ＵＮは、そのＵＮＣＭ機能を使用して、メッセージを分析し、ＵＮが認識するＥ２Ｅ ＳＬセッションＩＤマーカを含むかどうかを決定し得る。例えば、ＵＮＣＭは、ディープパケットインスペクション（ＤＰＩ）技法を使用して、メッセージを分析し、Ｅ２Ｅ ＳＬセッション確立中にそれを用いてＵＮＣＭが構成されたＥ２Ｅ ＳＬセッションＩＤを検索し得る。ステップ２２６では、ＵＮがＳＬセッション認識様式でメッセージの処理をサポートしない場合、または現在のメッセージがＵＮによって認識可能なＥ２Ｅ ＳＬセッションＩＤを含む場合、ＵＮは、メッセージを非ＳＬセッション認識様式で処理し得る。この場合、ＳＬは、Ｅ２Ｅ ＱｏＳが達成されることを確実にすることに責任がある。それは、ＵＮがＳＬに利用可能にするＵＮ ＱｏＳ情報を使用してこれを行い得る。ＳＬは、ひいては、調節を行い（例えば、ＵＮを変更し）、Ｅ２Ｅ ＱｏＳが維持されることを確実にし得る。

ステップ２２７では、ＵＮがＳＬセッション認識様式でメッセージの処理をサポートし、現在のメッセージがそれが認識するＥ２Ｅ ＳＬセッションＩＤを含むことを検出する場合、ＵＮＣＭ機能は、メッセージをＳＬセッション認識方式で処理し得る。これを行うことにおいて、ＵＮＣＭは、ＵＮ内の他の機能にこのメッセージに関連付けられたＥ２Ｅ ＳＬセッションＩＤを知らせ得る。この情報を使用して、他の機能は、Ｅ２Ｅ ＳＬセッションＱｏＳ要件が満たされることができるように、メッセージを処理し得る。例えば、ＵＮは、ネットワークに接続するように宛先をトリガするときを制御することによって、したがって、そこにメッセージを送信し得るときを制御することによって、メッセージのスケジューリングを制御し得る。同様に、ＵＮは、種々のＵＮ機能を通してトラバースする間にメッセージが被る遅延を制御することによって、メッセージの待ち時間、ジッタ、およびスループットを制御し得る。ステップ２２８では、ＵＮのＵＮＣＭ（サポートされる場合）は、Ｅ２Ｅ ＳＬセッション通信要求／応答メッセージの処理に関するフィードバック（例えば、通知）をＳＬＣＭに提供し得る。このフィードバックは、ＵＮがＥ２Ｅ ＳＬセッション確立中に報告した同一ＱｏＳレベルを満たすことができたかどうかと、そうでなかった場合、この所与のメッセージに対する新しい測定とを含み得る。このフィードバックは、規定されたエラー率閾値を超えたかどうかも含み得る。例えば、ＵＮが輻輳状態になり、もはやＳＬセッション確立中に構成されたＳＬセッション要件を満たすことが不可能である場合、ＵＮＣＭは、ＳＬＣＭまたはＡＣＭに通知し得る。ステップ２２９では、メッセージ毎、周期的ベース、またはイベントベース（例えば、メッセージを処理するとき、ＳＬセッションの要件を満たさない待ち時間またはスループットをもたらす）でＵＮ情報をＳＬＣＭまたはＡＣＭと共有することは、ＳＬＣＭまたはＡＣＭが、この特定のＵＮがＥ２Ｅ ＳＬセッションのＱｏＳ要件を維持し、満たし続けているかどうかを追跡することを可能にし得る。ＳＬＣＭまたはＡＣＭがこれが該当しないことを検出する場合、ＳＬＣＭまたはＡＣＭは、ＵＮが、この問題に対処することを試み、ＵＮネットワーク機能を再構成する（例えば、ＳＬセッションメッセージの優先順位を増加させる）ことの要求等、是正措置を講じ得る。代替として、ＳＬＣＭまたはＡＣＭは、使用のために利用可能な別の利用可能なＵＮが存在するかどうかを決定するためにチェックし得、該当する場合、Ｅ２Ｅ ＳＬセッションをこの新しいＵＮに移行させ得る。これを行うために、ＳＬＣＭまたはＡＣＭは、Ｅ２Ｅ ＳＬセッション確立プロシージャにおいてオリジナルＵＮに行ったように、同一タイプの要求を新しいＵＮ内の新しいＵＮＣＭに送信し得る。同様に、Ｅ２Ｅ ＳＬセッション解除プロシージャに説明されるように、要求を古いＵＮ内の古いＵＮＣＭにも送信し、このセッションを解除し得る。成功する場合、ＳＬＣＭまたはＡＣＭは、新しいＵＮを使用して、この特定のＥ２Ｅ ＳＬセッションのためにそれが受信する将来のＥ２Ｅ ＳＬセッション通信要求／応答メッセージの処理を開始し得る。

図１６は、Ｅ２Ｅ ＳＬセッションメッセージを受信する間のＵＮ ＱｏＳを管理するための例示的方法を図示する。ステップ２３１では、受信側のＳＬＣＭまたはＡＣＭ（例えば、発信側ＳＬセッションエンドポイント、中間ＳＬインスタンス、または標的ＳＬセッションエンドポイント）が、着信ＳＬメッセージを検出し、ＳＬセッション通信要求または応答であるかどうかをチェックする。このチェックは、そのＳＬメッセージタイプを示すＳＬメッセージ内のヘッダ情報を分析することによって行われる。それがＳＬセッション通信要求または応答である場合、ステップ２３２に進む。いずれでもない場合、プロシージャは、終了する。ステップ２３２では、受信側のＳＬＣＭまたはＡＣＭは、それがＳＬセッション通信要求であるか、応答であるかをチェックする。ステップ２３３では、受信側のＳＬＣＭまたはＡＣＭは、ＳＬセッション通信要求内に規定された標的エンドポイントがローカルでホストされているかどうか、または要求が別のホップに転送されなければならないかどうかをチェックする。これは、受信側アドレスを標的ＳＬセッションエンドポイントのアドレスと比較することによって行われ得る。ステップ２３４では、要求が別のＳＬホップに再標的化されなければならない場合、受信側のＳＬＣＭは、図１５に定義されたプロシージャを使用して、そのように行い得る。ステップ２３５では、ＳＬセッション通信要求が受信側を標的としていることを検出後、受信側は、要求を処理し得る（例えば、受信側によってホストされるリソースにＣＲＵＤ動作を行う、または受信側によってホストされる標的機能を呼び出す等）。受信側は、次いで、アプリケーション特定の応答情報を含み得る、応答を算出し得る（適用可能な場合）。ステップ２３６では、受信側のＳＬＣＭまたはＡＣＭは、ＳＬセッション通信応答メッセージを生成する。この応答では、受信側のＳＬＣＭまたはＡＣＭは、応答が、発信側にルーティングバックされるとき、中間ＳＬおよびＵＮによってＥ２Ｅ ＳＬセッションメッセージとしてハンドリングされ得るように、ＳＬセッション通信要求からの同一Ｅ２Ｅ ＳＬセッションＩＤを含むことを確実にする。応答を送信するために、受信側のＳＬＣＭまたはＡＣＭは、図１５に定義されたプロシージャを使用し得る。

図１６を継続して参照すると、ステップ２３７では、受信側のＳＬＣＭまたはＡＣＭは、ＳＬセッション通信応答をチェックし、受信側がこの応答に対応する要求の発信側であるかどうかを決定する。これを行うために、受信側は、応答内のＥ２Ｅ ＳＬセッションＩＤを、それが発信または再標的化する各ＳＬセッション通信要求のために維持するそのローカルで記憶される状態と比較する。受信側が、ＳＬセッションＩＤが受信側が開始した要求に一致することを検出する場合、受信側は、応答を再標的化する必要がなく、受信側が応答自体を処理すべきであることを把握する。受信側が、Ｅ２Ｅ ＳＬセッションＩＤがそれが再標的化した要求に一致することを検出する場合、受信側は、それが要求を受信した同一ＳＬエンティティ（例えば、中間ＳＬインスタンスまたはＳＬセッション発信側エンドポイント）に返すように応答を再標的化する必要があることを把握する。受信側が、Ｅ２Ｅ ＳＬセッションＩＤを認識しない場合、応答をドロップし、プロシージャは、終了する。ステップ２１８では、受信側は、受信された応答と対応するＳＬセッション通信要求の発信側である。受信側は、応答を処理し、アプリケーション特定の応答情報をそこから抽出する。ステップ２１９では、受信側は、受信された応答と対応するＳＬセッション通信要求の発信側ではなく、したがって、受信側のＳＬＣＭは、応答を次のホップに転送する。これを行うために、受信側のＳＬＣＭは、図１５において上記で定義されたプロシージャを使用して、そのように行い得る。

図１７は、Ｅ２Ｅ ＳＬセッション解除の間のＵＮ接続を管理するための例示的方法を図示する。図１７に示されるプロシージャに前もって必要なものは、ＳＬ登録者（例えば、バックエンドアプリケーション）がそれ自体と標的ＳＬセッションエンドポイント（例えば、デバイスアプリケーション）との間のＥ２Ｅ ＳＬセッションを解除するための要求を生成することであり得る。この要求では、ＳＬ登録者は、Ｅ２Ｅ ＳＬセッションＩＤならびに標的セッションエンドポイントを規定する。この要求は、次いで、処理のために、ＳＬ登録者のローカルＳＬに転送される。Ｅ２Ｅ ＳＬセッション解除要求がＳＬ登録者のローカルＳＬによって受信される時点は、図１７に定義されたプロシージャが開始する時点である。このプロシージャは、Ｅ２Ｅ ＳＬセッション解除要求が標的ＳＬセッションエンドポイントに向かってホップ毎に伝搬させられるにつれて、Ｅ２Ｅ ＳＬセッション解除要求を処理するために使用され得る。このプロシージャはまた、要求を発信したＳＬ登録者に向かって戻るようにフローするにつれて、対応するＥ２Ｅ ＳＬセッション解除応答を処理するためのものであり得る。ステップ２４１では、受信側のＳＬＣＭまたはＡＣＭ（例えば、発信側ＳＬセッションエンドポイント、中間ＳＬインスタンス、または標的ＳＬセッションエンドポイント）は、着信ＳＬメッセージを検出し、ＳＬセッション解除要求または応答であるかどうかをチェックする。このチェックは、そのＳＬメッセージタイプを示すＳＬメッセージ内のヘッダ情報を分析することによって行われる。いずれでもない場合、プロシージャは、終了する。ステップ２４２では、受信側のＳＬＣＭまたはＡＣＭは、Ｅ２Ｅ ＳＬ解除要求の標的であるかどうかをチェックする。ステップ２４３では、要求が受信側を標的化しない場合、受信側は、Ｅ２Ｅ ＳＬ解除要求を次のホップに再標的化する。これを行うとき、受信側のＳＬＣＭは、要求を再標的化したことの状態を維持し、それが再標的化されるために要求を受信したＳＬエンティティを記録する。この情報は、Ｅ２Ｅ ＳＬセッションＩＤを使用して記録される。

図１７を継続して参照すると、ステップ２４４では、要求が受信側を標的化する場合、ＳＬＣＭまたはＡＣＭは、最初に、ＳＬＣＭまたはＡＣＭが応答を受信し、セッションを解除することに合意することを示すＥ２Ｅ ＳＬセッション解除応答を生成することによって、要求を処理する。ステップ２４５では、応答を送信するために、参加者は、応答を作成し、要求内に規定されたＥ２ＥセッションＩＤに一致するようにＥ２ＥセッションＩＤを構成する。応答は、アプリケーション特定の応答情報等の他の情報を含み得る。標的宛先は、要求内に規定されたＥ２Ｅ ＳＬセッション発信側である。ステップ２４６では、受信側のＳＬＣＭまたはＡＣＭは、Ｅ２Ｅ ＳＬセッション確立中またはＥ２Ｅ ＳＬセッション通信中に作成された任意の状態を削除する。ＳＣＬＭまたはＡＣＭはまた、適用可能なＵＮの各々内に常駐するＵＮＣＭと通信し、ＵＮ内に維持される状態を削除し、この特定のホップのためのＥ２Ｅ ＳＬセッションをサービス提供するために必要とされる保持されたリソースを解放する。これは、解除されているセッションに一致するＥ２Ｅ ＳＬセッションＩＤを有する関連のあるメッセージのＥ２Ｅ ＳＬセッション認識処理のために使用されるＵＮ機能のいずれか上の構成を含む。ステップ２４７では、着信メッセージがＥ２Ｅ ＳＬセッション解除応答である場合、受信側のＳＬＣＭまたはＡＣＭは、応答が受信側が発信したＥ２Ｅ ＳＬセッション解除要求と相関するかどうかをチェックする。ステップ２４８では、該当しない場合、受信側のＳＬＣＭは、応答を転送するための次のホップを決定する。これを行うために、ＳＬＣＭは、それが再標的化するＥ２Ｅ ＳＬセッション解除要求のために維持するローカル状態を使用する。Ｅ２Ｅ ＳＬセッションＩＤを使用して、ＳＬＣＭは、このＥ２Ｅ ＳＬセッションＩＤに一致する対応するＥ２Ｅ ＳＬセッション解除要求を受信した場所をルックアップする。

ステップ２４９では、応答は、次いで、ＳＬＣＭまたはＡＣＭからＥ２Ｅ ＳＬセッション確立中に割り当てられた対応するＵＮにハンドオフされる。ＵＮは、次いで、メッセージを次のホップに転送する。ステップ２５０では、受信側のＳＬＣＭまたはＡＣＭは、Ｅ２Ｅ ＳＬセッション確立中またはＥ２Ｅ ＳＬセッション通信中に作成された状態を削除する。ＳＣＬＭまたはＡＣＭは、適用可能なＵＮの各々内に常駐するＵＮＣＭと通信し、この特定のホップのためのＥ２Ｅ ＳＬセッションをサービス提供するために必要とされるＵＮに維持される状態を削除する。これは、解除されているセッションに一致するＥ２Ｅ ＳＬセッションＩＤを有する関連のあるメッセージのＥ２Ｅ ＳＬセッション認識処理のために使用されるＵＮ機能のいずれか上の構成を含む。ステップ２５１では、応答が、受信側が発信したＥ２Ｅ ＳＬセッション解除要求に相関する場合、受信側は、応答を処理し、セッション解除が標的Ｅ２Ｅ ＳＬセッションエンドポイントによって成功裏に処理されたことを検証する。ステップ２５２では、受信側のＳＬＣＭまたはＡＣＭ（サポートされる場合）は、次いで、Ｅ２Ｅ ＳＬセッション確立中またはＥ２Ｅ ＳＬセッション通信中に作成された状態を削除する。ＳＣＬＭまたはＡＣＭは、適用可能なＵＮの各々内に常駐するＵＮＣＭと通信し、この特定のホップのためにＥ２Ｅ ＳＬセッションをサービス提供するために必要とされるＵＮに維持される任意の状態を削除する。これは、解除されているセッションに一致するＥ２Ｅ ＳＬセッションＩＤを有する関連のあるメッセージのＥ２Ｅ ＳＬセッション認識処理のために使用されるＵＮ機能のいずれか上の構成を含む。

図１８は、ＳＬＣＭがｏｎｅＭ２Ｍ定義サービスセッション管理（ＳＳＭ）ＣＳＦのサポートされる機能として実現される例を図示する。このＳＬＣＭ対応ＳＳＭ ＣＳＦ２７２は、ＩｏＴデバイス（例えば、ＡＳＮ−ＣＳＥ２７１）、ＩｏＴゲートウェイ（例えば、ＭＮ−ＣＳＥ２７３）、またはＩｏＴサーバ（ＩＮ−ＣＳＥ２７５）上にホストされるｏｎｅＭ２Ｍ ＣＳＥによってサポートされる。

このＳＬＣＭ対応ＳＳＭ ＣＳＦ２７２は、次に、ｏｎｅＭ２Ｍ定義ネットワークサービスエクスポージャ、サービス実行、およびトリガ（ＮＳＳＥ）ＣＳＦ（例えば、ＮＳＳＥ ＣＳＦ２７８）を介して、ＵＮＣＭとインターフェースをとる。ＵＮＣＭ機能（例えば、ＵＮＣＭ２７６）は、３ＧＰＰ定義サービス能力エクスポージャ機能（ＳＣＥＦ）、例えば、ＳＣＥＦ２７７の機能として実現される。ＳＣＥＦ２７７は、次に、３ＧＰＰネットワーク（例えば、３ＧＰＰネットワーク２７４）内の種々の他の機能とインターフェースをとる。ｏｎｅＭ２Ｍの定義によると、ＳＣＥＦ２７７は、下層ネットワークサービスエンティティ（ＮＳＥ）である。図１８では、Ｅ２Ｅ ｏｎｅＭ２Ｍ ＳＬセッションが、２つの異なるネットワークオペレータによって所有される３ＧＰＰネットワークを横断して及ぶ複数のＣＳＥホップによって分離される２つのｏｎｅＭ２Ｍ ＡＥ（例えば、ＡＥ２７０およびＡＥ２７９）間に確立される。各ｏｎｅＭ２Ｍ ＡＥは、ＡＣＭ機能をサポートする。一緒に、ＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能は、ｏｎｅＭ２Ｍ ＡＥが、アプリケーション特定のＱｏＳ要件を用いて、Ｅ２Ｅ ｏｎｅＭ２Ｍ ＳＬセッションを互いに確立することを可能にする。ＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能の補助を通して、ｏｎｅＭ２Ｍ ＣＳＥは、互いに、ならびに異なるオペレータによって所有される２つの下層３ＧＰＰネットワークと調整することが可能である。この調整を通して、ＱｏＳパラメータの適切な調節および整合が、ｏｎｅＭ２Ｍサービス層および下層３ＧＰＰネットワークの両方において達成され得る。そうすることによって、ＡＥのＥ２Ｅ ＱｏＳ要件は、本開示に取り込まれる提案される方法を使用して、調整されたホップ毎に、最終的には、Ｅ２ＥベースでＣＳＥによって管理され得る。その結果、ｏｎｅＭ２Ｍ ＡＥは、その規定されたＥ２Ｅ ＱｏＳ要件を満たす様式で、Ｅ２Ｅ ｏｎｅＭ２Ｍ ＳＬセッションを使用して互いに通信することが可能である。

ＡＰＩが、ＡＥがＥ２Ｅ ｏｎｅＭ２Ｍ ＳＬセッションを確立することを可能にするためのｏｎｅＭ２Ｍ ＳＳＭ ＣＳＦのために定義され得る。ＡＰＩは、リソース定義（例えば、ＲＥＳＴｆｕｌ ＡＰＩ）に基づき得る。従来のリソースは、＜ｓｅｓｓｉｏｎ＞、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞、および＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞を含み得る。拡張が、＜ｓｅｓｓｉｏｎ＞および＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースに行われ、ＡＥが、Ｅ２Ｅ ＳＬセッションの確立中、アプリケーション特定のＥ２Ｅ ＱｏＳ要件を定義することを可能にし得る。本明細書に開示されるＡＰＩ拡張は、ｏｎｅＭ２Ｍ ＳＬＣＭまたはＡＣＭ ＡＰＩを実現するために使用され得る。以下に議論されるのは、Ｅ２Ｅ ＳＬセッション発信側（例えば、ＡＥ２７０またはＩｏＴデバイスアプリケーション１５５）がこれらのリソースをそのローカルＣＳＥ内に作成または削除することを可能にすることによってＥ２Ｅ ＳＬセッションの確立または解除を要求するために使用され得るいくつかの拡張である。加えて、これらのリソースは、ホップ毎様式でＥ２Ｅ ＳＬセッションを確立または解除するために中間ＣＳＥによって使用され得る。これは、中間ＣＳＥが、Ｅ２Ｅ ＳＬセッションの確立または解除中、これらのリソースを次のホップＣＳＥ上で作成または削除することによって行われ得る。したがって、そうすることによって、マルチホップＥ２Ｅ ＳＬセッション構成における各ＣＳＥは、各Ｅ２Ｅ ＳＬセッションのためのこれらのリソースの対応する組を維持し得る。これらのリソースは、ＣＳＥに、サポートに役立つ、認識および各Ｅ２Ｅ ＳＬセッションのための状態を維持するための能力を提供する。

図１９は、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎ＞リソースの例示的拡張を図示する。これは、ＡＥが特定のｏｎｅＭ２Ｍ Ｅ２Ｅ ＳＬセッションに関連付けられたアプリケーション特定のＥ２Ｅ ＱｏＳ要件を定義することを可能にするための複数の属性を含む。属性は、ｓｃｈｅｄｕｌｅ、ｌａｔｅｎｃｙ、ｊｉｔｔｅｒ、ｅｒｒｏｒＲａｔｅ、ｔｈｒｏｕｇｈｐｕｔ、ｃｏｓｔＬｅｖｅｌ、およびｓｅｃｕｒｉｔｙＬｅｖｅｌ属性であり得、それは、表４に定義され、図１９に示される。別の例では、＜ｓｅｓｓｉｏｎ＞リソース内に定義されたＥ２Ｅ ＳＬセッションＱｏＳ要件の代わりに、それらは、代わりに、図２０に示されるように、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソース内に定義され得る。

従来、ｏｎｅＭ２Ｍは、それに登録されるＣＳＥとＡＥまたは他のＣＳＥとの間の接続性を提供するＵＮに関するＱｏＳ中心情報を維持するためのリソースを定義しない。本明細書に開示されるのは、例えば、図２１に図示されるような＜ＵＮ＞ｏｎｅＭ２Ｍリソースである。このリソースは、個々のＵＮからパブリッシュされるか、または読み出され得る情報を追跡および維持するための属性の組をサポートする。ＣＳＥは、各サポートされるＵＮのために別個の＜ＵＮ＞リソースをサポートし、このリソースを使用して、ＵＮについての情報を維持し得る。このタイプの情報をサポートすることは、ＵＮ認識決定を行うことを可能にし得るＵＮコンテキスト（例えば、このＵＮを経由したＡＥまたはＣＳＥの現在の到達可能性、通信待ち時間、および通信スループット）の可視性をＣＳＥに提供する。例えば、ＣＳＥは、この情報に基づいて、近隣ＣＳＥまたはＡＥとの通信のために利用可能なＵＮの組をランク付けし、最適な使用を決定し得る。リソース内に維持される情報は、とりわけ、ＵＮを介して（例えば、３ＧＰＰネットワークと関連のあるＳＣＥＦによってサポートされるＵＮＣＭ機能を介して）パブリッシュされるか、またはＵＮから読み出され得る（例えば、ＣＳＥによってサポートされるＳＬＣＭを介して）。表５は、例示的属性を提供する。

従来、ｏｎｅＭ２Ｍは、＜ＡＥ＞および＜ｒｅｍｏｔｅＣＳＥ＞リソースの両方のために単一のｐｏｉｎｔＯｆＡｃｃｅｓｓ属性を定義する。従来の属性は、対応するＡＥまたはＣＳＥのためのＵＮアドレスのリストを取り込むために使用される。ＡＥまたはＣＳＥが別のレジストラＣＳＥに登録すると、それは、この情報を提供し得る。この情報は、レジストラＣＳＥがメッセージをＡＥまたはＣＳＥに送信する必要があるとき、ＡＥまたはＣＳＥにコンタクトするためにレジストラＣＳＥによって使用され得る。従来、ｏｎｅＭ２Ｍは、ＩＰアドレスまたはＦＱＤＮおよびポートのリストとしてｐｏｉｎｔＯｆＡｃｃｅｓｓ属性内に記憶される情報を定義する。ＡＥまたはＣＳＥによってサポートされる各対応するＵＮは、このリスト内にエントリを有する。定義されるようなｐｏｉｎｔＯｆＡｃｃｅｓｓ属性は、どんな他のＵＮ情報もサポートしない。

以下に定義されるのは、追加のＵＮ情報のための可視性をＣＳＥに提供するためのｏｎｅＭ２Ｍ ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性機能性の提案される拡張である。図２２は、例示的Ｅ２Ｅ ＳＬセッションＱｏＳ要件＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞属性を図示する。第１の例示的拡張では、ｐｏｉｎｔＯｆＡｃｃｅｓｓ属性は、それ自身の個々の属性を有するリソースに変換され得る。これを行うことは、ＣＳＥとその登録者との間のより伝導力のあるＡＰＩを作成し、それらが追加のＵＮ情報を規定することを可能にする。

第２の例示的拡張では、表３に開示される情報等の追加のＵＮ ＱｏＳ関連情報のサポートが、追加され得る。ＣＳＥに登録された所与のＡＥまたはＣＳＥのためのこの情報をサポートすることは、レジストラＣＳＥに、所与のＡＥまたはＣＳＥのためのＵＮ特定の構成および要件に対する可視性を提供する。これは、レジストラＣＳＥに、その登録者の各々に関するＵＮ特定の情報を与え得る。例えば、ＣＳＥは、それに登録された各ＡＥまたはＣＳＥのために、そのＡＥまたはＣＳＥと通信するために利用可能なＵＮの組を決定し得る。別個に、ＣＳＥは、各ＡＥまたはＣＳＥのためのＵＮ要件を有する。そして、この情報は、特定のＡＥまたはＣＳＥと通信するときに使用すべきＵＮについてより情報に基づいた決定を行うために使用され得る。表６は、図２２に関連付けられた例示的属性を提供する。

図２３および図２４は、＜ＡＥ＞リソースおよび＜ｒｅｍｏｔｅＣＳＥ＞リソースのための例示的＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞子リソースを図示する。本明細書では、＜ＡＥ＞または＜ｒｅｍｏｔｅＣＳＥ＞ｏｎｅＭ２Ｍリソースは、例えば、図２３または図２４に示されるように、開示される＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞リソースの別個のインスタンスをサポートすることを可能にされ得る。＜ｐｏｉｎｔＯｆＡｃｃｅｓｓ＞の別個のインスタンスは、ＡＥまたはＣＳＥによって作成され、それ自体とそのレジストラＣＳＥとの間の接続性を提供する各ＵＮのためその接続性情報を維持し得る。

本明細書に開示されるのは、３ＧＰＰ定義ＳＣＥＦによってサポートされ得る、ＵＮＣＭ機能のためのＡＰＩである。本開示されるＡＰＩは、性質上、ＲＥＳＴｆｕｌであり、信頼されたアプリケーションまたは第三者サービスによって（例えば、ｏｎｅＭ２Ｍ ＣＳＥによってサポートされるＳＬＣＭ機能によって）アクセスされ得るリソースおよび属性の組を定義する。

図２５は、３ＧＰＰ ＵＮＣＭ／ＳＣＥＦのための例示的＜ＵＮＣＭ＞リソースを図示する。このリソースは、ＵＮ情報を追跡および維持するための属性の組をサポートする。ＵＮＣＭは、それがサポートする各ＵＮのために別個の＜ＵＮＣＭ＞リソースをサポートし得る。＜ＵＮＣＭ＞は、各それぞれのＵＮ内の対応するＵＮノード／機能との情報を収集するための通信をサポートし、そして、ＵＮノード／機能は、このリソースを介して、その情報を利用可能にする。ＵＮＣＭは、このリソースに対する読み出し要求ならびにサブスクリプション機構をサポートし、信頼されたアプリケーションまたはサービスプロバイダがＵＮ情報をＵＮＣＭから受信することを可能にし得る。例えば、ＳＬＣＭ機能は、＜ＵＮＣＭ＞リソースを読み出し得るか、または＜ＵＮＣＭ＞属性のいずれかが更新される場合、通知を受信するためのサブスクリプションを作成し得る。表７は、例示的＜ＵＮＣＭ＞リソース属性および子リソースを提供する。

図２６は、３ＧＰＰ ＵＮＣＭ／ＳＣＥＦのための例示的＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソースを図示する。このリソースは、信頼されたアプリケーションまたはサービスプロバイダがＳＬセッションと対応するＵＮＣＭによって管理されるＵＮ内で通信セッションを作成することを可能にするための属性の組をサポートする。例えば、ｏｎｅＭ２Ｍ ＣＳＥ内のＳＬＣＭ機能は、＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソースを作成し、それ自体と近隣ＣＳＥとの間の単一ホップＵＮセッションを確立し得る。本開示に提案されるＥ２Ｅ ＳＬセッションＩＤを用いて＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソースのｓｅｓｓｉｏｎＩＤ属性を構成することによって、ＳＬＣＭは、Ｅ２Ｅセッションの１つのホップを確立し得る。このプロセスは、Ｅ２Ｅ ＳＬセッション内の各ホップのために繰り返され、複数のＵＮセッションから成るＥ２Ｅ ＳＬセッションを形成し得る。ｓｅｓｓｉｏｎＩＤの構成に加え、ＳＬＣＭは、Ｅ２Ｅ ＳＬセッションＱｏＳ要件（スケジュール、待ち時間、およびスループット）と整合するための他の属性も構成し得る。ＵＮＣＭは、次に、ＵＮがセッションを作成し得るかどうかに基づいて、成功または失敗応答で応答し得る。成功する場合、ＵＮＣＭは、ｓｅｓｓｉｏｎＩＤおよびＱｏＳ要件を用いてそれぞれのノードを構成し得る。これは、ＵＮが、ＱｏＳ要件と整合させられる様式でｓｅｓｓｉｏｎＩＤを含む任意のメッセージを検出および処理することを可能にする。ＳＬＣＭは、さらに、ＱｏＳ要件を変更するために＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソースを更新し、＜ＵＮＣＭＳｅｓｓｉｏｎ＞を削除し、セッションを解除し得る。表８は、例示的＜ＵＮＣＭＳｅｓｓｉｏｎ＞リソース属性および子リソースを提供する。

図２７は、ＯｐｅｎＦｌｏｗ対応スイッチまたはルータが、ＩｏＴデバイス、ゲートウェイ、サーバ、およびバックエンドアプリケーションを相互接続する、ＯｐｅｎＦｌｏｗに基づくソフトウェア定義ネットワーキング（ＳＤＮ）システムの例を図示する。ＯｐｅｎＦｌｏｗＳｗｉｔｃｈＳｐｅｃｉｆｉｃａｔｉｏｎ１．３．４（２０１４年３月２４日）ｈｔｔｐｓ：／／ｗｗｗ．ｏｐｅｎｎｅｔｗｏｒｋｉｎｇ．ｏｒｇ／ｊａ／ｓｄｎ−ｒｅｓｏｕｒｃｅｓ−ｊａ／ｏｎｆ−ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ｏｐｅｎｆｌｏｗおよびＯｐｅｎＦｌｏｗＣｏｎｔｒｏｌｌｅｒ−Ｓｗｉｔｃｈ１．０（２０１４年８月１５日）ｈｔｔｐｓ：／／ｗｗｗ．ｏｐｅｎｎｅｔｗｏｒｋｉｎｇ．ｏｒｇ／ｊａ／ｓｄｎ−ｒｅｓｏｕｒｃｅｓ−ｊａ／ｏｎｆ−ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ｏｐｅｎｆｌｏｗを参照されたい（両方とも、参照することによってその全体として組み込まれる）を参照されたい。

図２７を継続して参照すると、各ＯｐｅｎＦｌｏｗ対応スイッチまたはルータは、ＵＮＣＭ機能を用いて有効にされる。このＵＮＣＭ機能は、Ｍ２Ｍ／ＩｏＴゲートウェイおよびサーバの両方によってホストされるＭ２Ｍ／ＩｏＴ ＳＬによってサポートされるＳＬＣＭ機能とインターフェースをとる。ＳＬＣＭ機能は、ＯｐｅｎＦｌｏｗ対応スイッチまたはルータ上に実装されるＵＮＣＭと通信するためにＯｐｅｎＦｌｏｗコントローラ機能を読み出し得る。

この例では、Ｅ２Ｅ ｏｎｅＭ２Ｍ ＳＬセッションは、複数の下層ＯｐｅｎＦｌｏｗ対応スイッチまたはルータを横断して及ぶ複数のＭ２Ｍ／ＩｏＴサービス層ホップによって分離される２つのアプリケーション間に確立される。

一緒に、ＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能は、アプリケーションが、Ｅ２Ｅ到達可能性スケジュール、Ｅ２Ｅ待ち時間、およびＥ２Ｅスループット等のアプリケーション特定のＱｏＳ要件が定義され得る、Ｅ２Ｅ ＳＬセッションを互いに確立することを可能にする。ＳＬＣＭ、ＡＣＭ、およびＵＮＣＭ機能の補助を通して、ＳＬは、互いに、ならびに下層ＯｐｅｎＦｌｏｗ対応スイッチ／ルータと調整することが可能である。この調整を通して、到達可能性スケジュール、待ち時間、およびスループットの適切な調節および整合が、サービス層および下層ルータの両方において達成され得る。そうすることによって、ＡＥのＥ２Ｅ ＱｏＳ要件は、本開示に取り込まれる提案される方法を使用して、調整されたホップ毎に、最終的には、Ｅ２ＥベースでＳＬによって管理され得る。その結果、アプリケーションは、その規定されたＥ２Ｅ ＱｏＳ要件を満たす様式でＥ２Ｅ ＳＬセッションを使用して、互いに通信することが可能である。

図２８は、Ｅ２Ｅ ＱｏＳを構成するために使用され得る、グラフィカルユーザインターフェースの例を図示する。示されるようなグラフィカルユーザインターフェースは、例として表２に提供されるような選択用語を提供する。このＧＵＩは、本開示に定義されたＡＣＭまたはＳＬＣＭ機能のネイティブ特徴としてサポートされ得る。代替として、このＧＵＩは、ＡＣＭまたはＳＬＣＭ機能がインターフェースをとり得る、それ自身の機能として実装され得る。このＧＵＩは、ユーザが、それ自体（またはその制御下のアプリケーション）と１つ以上の標的Ｍ２Ｍ／ＩｏＴデバイス（またはこれらのデバイス上にホストされるアプリケーション）との間の所望のレベルのＥ２Ｅ ＱｏＳを構成することを可能にし得る。ＧＵＩは、表２に定義されたＱｏＳパラメータのうちの１つ以上のものをサポートし得る。ＧＵＩは、高、中、低等のＱｏＳパラメータのためのユーザが使いやすい設定／オプションをサポートし得る。ＧＵＩおよび／またはＡＣＭ、またはＳＬＣＭは、ひいては、これらのＧＵＩ設定を下層ネットワークによってより良好に解釈されるより詳細な値／具体的ＱｏＳ設定に変換し得る。例えば、高、中、低スループットは、それぞれ、＞１０Ｍビット／秒、＜１０Ｍビット／秒であるが＞１Ｍビット／秒、および＜１ＭＢｉｔｓ／秒に変換され得る。代替として、ＧＵＩは、より具体的オプションおよび／または値をサポートし得る。

図２９は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース２０１（例えば、タッチスクリーンディスプレイ）は、表１から表８のパラメータ等のサービス管理のサービス層品質に関連付けられたテキストをブロック２０２内に提供し得る。別の例では、本明細書で議論されるステップのいずれかの進捗度（例えば、送信されるメッセージまたはステップの成功）は、ブロック２０２に表示され得る。加えて、グラフィカル出力２０３が、ディスプレイインターフェース２０１上に表示され得る。グラフィカル出力２０３は、複数のネットワークに及ぶようなデバイスのトポロジ、明細書で議論される任意の方法またはシステムの進捗度のグラフィカル出力等であり得る。

図３０Ａは、ＩｏＴ Ｅ２Ｅサービス層ＱｏＳ管理に関連付けられた１つ以上の開示される概念が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の概略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

図３０Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図３０Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービスプラットフォーム２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

図３０Ｂを参照すると、フィールドドメイン内に例証されるＭ２Ｍサービス層２２（例えば、本明細書に説明されるようなＩｏＴサービス層１６６）は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

図３０Ｂをさらに参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

いくつかの例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に議論されるようなＳＬ ＱｏＳを使用して通信する所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

本願のＳＬ ＱｏＳ管理は、サービス層の一部として実装され得る。サービス層（例えば、ＩｏＴ ＳＬ１６６）は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得るデバイス、ゲートウェイ、またはサービス／プラットフォーム等のＭ２Ｍ機能エンティティ）は、アプリケーションまたはサービスを提供し得る。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願のＳＬ ＱｏＳ管理を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストすることができる共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願のＳＬ ＱｏＳ管理は、本願のＳＬ ＱｏＳ管理等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

本明細書に議論されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能的層と考えられ得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む、（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションまたは種々のデバイスに、ＣＳＥもしくはサービス能力層（ＳＣＬ）と称され得るサービス層によってサポートされる前述の能力または機能性の集合もしくは組へのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得るセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（例えば、そのような機能エンティティ間の機能インターフェース）である。

図３０Ｃは、例えば、Ｍ２Ｍ端末デバイス１８（例えば、ＩｏＴデバイス１５３）またはＭ２Ｍゲートウェイデバイス１４（例えば、ＩｏＴゲートウェイ１５２）等の例示的Ｍ２Ｍデバイス３０の系統図である。図３０Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、ＩｏＴデバイス１３０、ＩｏＴゲートウェイ１５２、ＩｏＴサーバ１５１、ＩｏＴデバイス１５４、およびその他）は、ＳＬ ＱｏＳ管理のための開示されるシステムおよび方法を行う例示的実装であり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る送受信機３４に結合され得る。図３０Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を実施し得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を実施し得る。

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークおよびエアインターフェースをサポートし得る。例では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の例では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図３０Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、例では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される例のうちのいくつかにおけるＬＭＳが成功もしくは不成功である（例えば、ＳＬ ＱｏＳ要求または応答等）であるかどうかに応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するか、または別様にＳＬ ＱｏＳ管理および関連付けられたコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色の制御は、図に図示されるか、もしくは本明細書で論じられる方法フローもしくはコンポーネントのいずれかのステータス（例えば、図９−図２９等）を反映し得る。本明細書に開示されるのは、ＳＬ ＱｏＳ管理ならびにＳＬ ＱｏＳ管理のためのリソースのメッセージおよびプロシージャである。メッセージおよびプロシージャは、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、リソース関連リソースを要求し、とりわけ、ディスプレイ４２上に表示され得る、リソースのＳＬ ＱｏＳを要求、構成、またはクエリするためのインターフェース／ＡＰＩを提供するように拡張され得る。

プロセッサ３２は、電源４８から電力を受容し得、Ｍ２Ｍデバイス３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍデバイス３０は、本明細書に開示される情報と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、種々のセンサ、例えば、加速度計、バイオメトリック（例えば、指紋）センサ、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

伝送／受信要素３６は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。

図３０Ｄは、例えば、図３０Ａおよび図３０ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４）は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、ＳＬ ＱｏＳ要求または応答の受信等、ＳＬ ＱｏＳ管理のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、ならびに処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割込を送信し、システムバスを動作させるための制御ラインを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に結合されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、図３０Ａおよび３０Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含み得る。

図に例証されるように、本開示の主題（ＩｏＴ Ｅ２Ｅ ＳＬ ＱｏＳ管理）の好ましい方法、システム、または装置を説明する上で、明確にするために、具体的用語が採用される。例えば、要求される用語（例えば、表２）は、要件だけではなく、選好も達成するために使用され得る。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する全ての技術的均等物を含むことを理解されたい。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いと組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」等は、同義的に使用され得る。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る（例えば、本明細書に開示される例示的方法間のステップのスキップ、組み合わせステップ、または追加ステップ）。そのような他の例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。

とりわけ、本明細書に説明されるような方法、システム、および装置は、ＩｏＴＥ２Ｅ ＳＬ ＱｏＳ管理のための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、アプリケーションのためのエンドツーエンドサービス品質要件を決定することと、エンドツーエンドサービス層セッションが確立されるための要求を転送することであって、要求は、アプリケーションのための決定されたエンドツーエンドサービス品質要件を含む、ことと、遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、エンドツーエンドサービス層セッションを使用して通信することとを行う手段を有する。メッセージは、確立されたエンドツーエンドサービス層セッションのためのサービス層識別を含み得る。アプリケーションは、サービス品質要件を下層ネットワークを構成するサービス層に提供し得、下層ネットワークは、装置および別のサービス層装置を接続する。アプリケーションは、サービス品質要件を要求を介してサービス層に提供し得、サービス層は、下層ネットワークを構成し、下層ネットワークは、装置および別のサービス層装置を接続する。サービス品質要件は、エンドツーエンドサービス層セッションのための最小スループット閾値を含み得る。サービス品質要件は、エンドツーエンドサービス層セッションのための最小到達可能性スケジュールまたはエンドツーエンドサービス層セッションのための最小ジッタ閾値を含み得る。サービス品質要件は、エンドツーエンドサービス層セッションのための最小エラー率閾値またはエンドツーエンドサービス層セッションのための最小待ち時間閾値を含み得る。サービス品質要件は、エンドツーエンドサービス層セッションのための最小セキュリティレベル閾値を含み得る。本段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で想定される。

Claims (14)

1. サービス層装置であって、前記サービス層装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、プロセッサによって実行されると、
   アプリケーションのためのエンドツーエンドサービス品質要件を決定することと、
   エンドツーエンドサービス層セッションが確立されるための要求を転送することであって、前記要求は、前記アプリケーションのための決定されたエンドツーエンドサービス品質要件を備え、前記アプリケーションは、前記サービス品質要件を一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークを構成するサービス層に提供し、前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークは、前記サービス層装置と別のサービス層装置とを接続する、ことと、
   遠隔装置との前記エンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、
   前記遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、前記エンドツーエンドサービス層セッションを使用して通信することと
   を含む動作を前記プロセッサに達成させ、
   前記メッセージは、前記確立されたエンドツーエンドサービス層セッションを識別するサービスセッションＩＤを含み、前記サービスセッションＩＤは前記エンドツーエンドサービス層セッションが確立されるための要求の受信に応じて割り当てられた前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークに共通のＩＤである、装置。
2. 前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小スループット閾値を備えている、請求項１に記載の装置。
3. 前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小到達可能性スケジュールを備えている、請求項１に記載の装置。
4. 前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小エラー率閾値を備えている、請求項１に記載の装置。
5. 前記サービス品質要件は、前記エンドツーエンドサービス層セッションのための最小セキュリティレベル閾値を備えている、請求項１に記載の装置。
6. 前記一又は複数の下層ネットワークは、少なくとも二種類の下層ネットワークを含み、前記エンドツーエンドサービス層セッションをマルチホップに構成する、請求項１に記載の装置。
7. 前記少なくとも二種類の下層ネットワークは、３ＧＰＰ及びＷｉ−Ｆｉを含む、請求項６に記載の装置。
8. 方法であって、前記方法は、
   サービス層装置のアプリケーションのためのエンドツーエンドサービス品質要件を決定することと、
   エンドツーエンドサービス層セッションが確立されるための要求を送信することであって、前記要求は、前記アプリケーションのための決定されたエンドツーエンドサービス品質要件を備え、前記アプリケーションは、前記サービス品質要件を一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークを構成するサービス層に提供し、前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークは、サービス層装置と遠隔装置とを接続する、ことと、
   前記サービス層装置と遠隔装置との間の前記エンドツーエンドサービス層セッションの確立を確認するメッセージを受信することと、
   前記遠隔装置とのエンドツーエンドサービス層セッションの確立を確認するメッセージを受信することに応答して、前記エンドツーエンドサービス層セッションを使用して通信することと
   を含み、
   前記メッセージは、前記確立されたエンドツーエンドサービス層セッションを識別するサービスセッションＩＤを含み、前記サービスセッションＩＤは前記エンドツーエンドサービス層セッションが確立されるための要求の受信に応じて割り当てられた前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークに共通のＩＤである、方法。
9. 前記一又は複数の下層ネットワークは、少なくとも二種類の下層ネットワークを含み、前記エンドツーエンドサービス層セッションをマルチホップに構成する、請求項８に記載の方法。
10. 前記少なくとも二種類の下層ネットワークは、３ＧＰＰ及びＷｉ−Ｆｉを含む、請求項９に記載の方法。
11. コンピュータプログラムを記憶しているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、前記コンピュータプログラムは、前記データ処理ユニットによって起動されると、請求項８〜１０のいずれか１項に記載の方法のステップを前記データ処理ユニットに実行させるように適合されている、コンピュータ読み取り可能な記憶媒体。
12. サービス層装置であって、前記サービス層装置は、
    プロセッサと、
    前記プロセッサと結合されているメモリと
    を備え、
    前記メモリは、実行可能命令を備え、前記命令は、プロセッサによって実行されると、
    アプリケーションのためのエンドツーエンドサービス層セッションが確立されるための要求を受信することであって、前記要求は、前記アプリケーションのためのエンドツーエンドサービス品質要件を備え、前記アプリケーションは、前記サービス品質要件を一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークを構成するサービス層に提供し、前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークは、前記サービス層装置と別のサービス層装置とを接続する、ことと、
    遠隔装置との前記エンドツーエンドサービス層セッションの確立を確認するメッセージを送信することと、
    前記エンドツーエンドサービス層セッションの確立を確認するメッセージを送信した後に、前記エンドツーエンドサービス層セッションを使用して通信することと
    を含む動作を前記プロセッサに達成させ、
    前記メッセージは、前記確立されたエンドツーエンドサービス層セッションを識別するサービスセッションＩＤを含み、前記サービスセッションＩＤは前記エンドツーエンドサービス層セッションが確立されるための要求の受信に応じて割り当てられた前記一又は複数の下層アプリケーションプロトコル及び一又は複数の下層ネットワークに共通のＩＤである、装置。
13. 前記一又は複数の下層ネットワークは、少なくとも二種類の下層ネットワークを含み、前記エンドツーエンドサービス層セッションをマルチホップに構成する、請求項１２に記載の装置。
14. 前記少なくとも二種類の下層ネットワークは、３ＧＰＰ及びＷｉ−Ｆｉを含む、請求項１３に記載の装置。