JP2017535838A - サービス層セッション移転および共有 - Google Patents

サービス層セッション移転および共有 Download PDF

Info

Publication number
JP2017535838A
JP2017535838A JP2017515070A JP2017515070A JP2017535838A JP 2017535838 A JP2017535838 A JP 2017535838A JP 2017515070 A JP2017515070 A JP 2017515070A JP 2017515070 A JP2017515070 A JP 2017515070A JP 2017535838 A JP2017535838 A JP 2017535838A
Authority
JP
Japan
Prior art keywords
session
node
service layer
communication session
context
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017515070A
Other languages
English (en)
Other versions
JP6335388B2 (ja
Inventor
デール エヌ． シード，
デール エヌ． シード，
グアン ルー，
グアン ルー，
リージュン ドン，
リージュン ドン，
ホンクン リ，
ホンクン リ，
シュウ リ，
シュウ リ，
ウィリアム ロバード ザ フォース フリン，
ウィリアム ロバード ザ フォース フリン，
カタリーナ エム． ムラディン，
カタリーナ エム． ムラディン，
フィリップ ブラウン，
フィリップ ブラウン，
Original Assignee
コンヴィーダ ワイヤレス， エルエルシー
コンヴィーダ ワイヤレス， エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コンヴィーダ ワイヤレス， エルエルシー, コンヴィーダ ワイヤレス， エルエルシー filed Critical コンヴィーダ ワイヤレス， エルエルシー
Publication of JP2017535838A publication Critical patent/JP2017535838A/ja
Application granted granted Critical
Publication of JP6335388B2 publication Critical patent/JP6335388B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/148—Migration or transfer of sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

既存のＭ２Ｍサービス層セッションの移転または共有のための方法、デバイス、およびシステムが、開示される。一実施形態では、セッション移転および共有機能（ＳＭＳＦ）は、Ｍ２Ｍサービス層セッションの移転または共有を行う。種々の形態のサービス層セッションコンテキストは、Ｍ２Ｍサービス層セッションの移転または共有を可能にするために使用され得る。一実施形態によると、セッションコンテキストは、ノードのサービス層インスタンスによって作成および維持されている１つ以上のリソース内に記憶されている。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０５２，５３５号（２０１４年９月１９日出願）に対する優先権およびその利益を主張し、上記出願の開示は、その全体が記載されているかのように参照により本明細書に引用される。
通信セッションは、２つ以上の通信エンティティ（例えば、デバイス、アプリケーション等）間に持続的双方向情報交換を伴い得る。通信セッションは、ある時点で確立され、種々の状況に基づいて、後の時点で切断される（例えば、セッションタイムアウト後またはエンティティのうちの１つがセッションを終了することを決定するとき）。通信セッションは、エンティティ間に複数のメッセージの交換を伴い得、ステートフルであり得、ステートフルとは、通信エンティティのうちの少なくとも１つが、通信セッションを維持可能であるために、セッション履歴についての情報を保存することを意味し、例えば、コネクティビティ、登録、セキュリティ、スケジュール、およびセッションパーティシパントに適用可能であるデータ等のセッションコンテキストを維持することを意味する。
通信セッションは、ネットワークプロトコルスタック内の種々の層において、プロトコルおよびサービスの一部として実装され得る。例えば、通信接続／セッションは、トランスポートプロトコル層（例えば、ＴＣＰ接続）、セッションプロトコル層（例えば、ＴＬＳおよびＤＴＬＳセッション）、ウェブトランスポートプロトコル層（例えば、ＨＴＴＰおよびＣｏＡＰセッション）、マシンツーマシン（Ｍ２Ｍ）／モノのインターネット（ＩｏＴ）サービス層、およびアプリケーション層（例えば、アプリケーション特定のセッション）において、ネットワークノード間に確立され得る。本願は、主に、Ｍ２Ｍ／ＩｏＴサービス層セッションを標的化する特徴に関する。
従来のアプリケーションセッションは、下層通信プロトコルまたはサービス層によってではなく、アプリケーション自身によって確立および管理される、２つ以上のアプリケーション間の通信セッションである。その結果、アプリケーションセッションは、余分なオーバーヘッドおよび複雑性をアプリケーションに加え得る。
マシンツーマシン（Ｍ２Ｍ）サービス層は、Ｍ２Ｍタイプデバイスおよびアプリケーションのための付加価値サービスを提供する。例えば、Ｍ２Ｍサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）をサポートし、アプリケーションおよびデバイスにサービス層によってサポートされるＭ２Ｍ中心能力の集団へのアクセスを提供することができる。いくつかの例として、セキュリティ、請求、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージ形式、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。
Ｍ２Ｍサービス層セッションは、Ｍ２Ｍサービス層によってサポートされる付加価値セッション管理サービスによって促進される通信セッションである。これらのサービスは、パーティシパント間のサービス層セッションを確立し、サービス層セッションおよびそのパーティシパントに関するコンテキストを収集および維持するための機構等の能力を含むことができる。サービス層セッションは、２つ以上のＭ２Ｍサービス層セッションパーティシパント間に確立されることができ、これらのパーティシパントは、Ｍ２Ｍアプリケーションおよび／またはＭ２Ｍサービス層インスタンスであることができる。しかしながら、最低でも、Ｍ２Ｍサービス層の少なくとも１つのインスタンスが、セッションに参加し、サービス層セッションのファシリテータとして機能しなければならない（すなわち、必要サービス層セッション管理機能性を提供しなければならない）。
Ｍ２Ｍサービス層セッションの利点の１つは、Ｍ２Ｍサービス層セッションが、アプリケーションを、それ自身のアプリケーションベースのセッションを確立および維持する必要があるという負担からオフロードするために使用されることができることである。これは、セッションの確立および維持に関わるオーバーヘッドの負担が、Ｍ２Ｍサービス層にオフロードされ、Ｍ２Ｍアプリケーションがこの責任を負わせられないという点において、Ｍ２Ｍサービス層セッションがアプリケーションセッションと異なるからである。サービス層にオフロードされ得るオーバーヘッドのいくつかの例は、証明書、識別子、ルーティング情報、発見情報、場所、トランザクション履歴、およびデータ等のセッションコンテキストの作成および管理を含むことができる。別の利点は、Ｍ２Ｍサービス層セッションが、１つ以上の下層トランスポートまたはアクセスネットワーク通信セッションの上部に層化されることができることである。いくつかの例は、限定ではないが、ウェブトランスポートプロトコルセッション（例えば、ＨＴＴＰセッション）、セッション層セッション（例えば、ＴＬＳセッション）、またはトランスポート層接続（例えば、ＴＣＰ）を含む。この層化は、Ｍ２Ｍサービス層セッションが、下層セッションの設定および切断から独立して持続し、維持され得るように、Ｍ２Ｍサービス層セッションが、下層セッションに関して、持続性をサポートすることを可能にする。例えば、Ｍ２Ｍサービス層セッションは、繰り返し設定および切断されるその下層ＴＣＰ／ＴＬＳセッション（それは、通常ネットワーク通信の過程の間、非常に典型的であり、例えば、電力節約方法およびモビリティに起因して）にかかわらず、持続することができる。
セッションパーティシパント間のＭ２Ｍサービス層セッションの確立は、サービス層登録プロセスの一部またはその後の別個のプロセスのいずれかとして開始され得る。確立されると、サービス層セッションは、セッションパーティシパント、およびそれらの間で生じる通信に関するサービス層コンテキストを収集および維持するために使用されることができる。例えば、セッションパーティシパントの登録状態およびセキュリティ証明書、セッションパーティシパントに対するサブスクリプション基準およびコンタクト情報、サービス層リソース内に記憶されるセッションパーティシパントデータ、ならびにセッションパーティシパントによって行われるトランザクションの履歴等のサービス層セッションコンテキストが、各セッションに対して収集および維持され得る。セッションパーティシパント間のＭ２Ｍサービス層セッションの終了は、サービス層登録解除プロセスの一部または登録解除が生じる前に行われる別個のプロセスのいずれかとして開始されることができる。
サービス層セッションの確立ならびに特定のサービス層セッションの有効期間の間のサービス層セッションコンテキストの蓄積は、セッションパーティシパントの代わりに、有意な量の時間および努力を伴い得る。故に、サービス層セッションの持続的性質は、この持続性を欠いた下層トランスポートおよびアクセスネットワークセッションと比較して、その主要な付加価値差別化要因のうちの１つである。持続的サービス層セッションは、アプリケーションがこの情報を自身で維持する必要がないように、アプリケーションの代わりに、サービス層セッションコンテキストを維持するために使用されることができる。加えて、下層接続／セッションが切断された場合、サービス層セッションコンテキストは、持続することができ、下層接続が再確立された場合、このコンテキストは、依然として、アプリケーションに利用可能となるであろう。故に、このコンテキストは、非持続的下層トランスポートセッションから独立して維持されることができる。サービス層セッションコンテキストのいくつかの例は、サービス層登録、サブスクリプション、証明書、識別子、課金記録、ルーティング情報、発見情報、場所、トランザクション履歴、およびアプリケーションのためのデータを含み得る。
既存のＭ２Ｍサービス層は、Ｍ２Ｍサービス層セッションコンテキストをあるサービス層インスタンスから別のサービス層インスタンスに移転または共有するためのサポートを欠いている。同様に、Ｍ２Ｍアプリケーションインスタンス間でＭ２Ｍサービス層セッションコンテキストを移転または共有するためのサポートも欠いている。この機能性の欠如は、Ｍ２Ｍサービス層が、モバイルセッションパーティシパントを伴う使用例、割り当てられた新しいＩＰアドレスを得る等のセッションパーティシパントアドレスの変更、または新しいセッションパーティシパントとのサービス層セッションの共有を伴う使用例のためのサービス層セッションの持続性をサポートすることを妨げる。
本明細書に開示されるのは、既存のＭ２Ｍサービス層セッションの移転または１つ以上のセッションパーティシパントとの共有のための方法、デバイス、およびシステムである。一実施形態では、セッション移転および共有機能（ＳＭＳＦ）は、Ｍ２Ｍサービス層セッションの移転または共有を行う。加えて、種々の形態のサービス層セッションコンテキストは、Ｍ２Ｍサービス層セッションの移転または共有を可能にするために使用され得る。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
より詳細な理解は、付随の図面と併せて、一例として与えられる、以下の説明から得られ得る。
図１Ａは、ネットワークプロトコルスタック内の種々の層の実施例を図示する。 図１Ｂは、例示的エンドツーエンド（Ｅ２Ｅ）マシンツーマシン（Ｍ２Ｍ）サービス層セッションを図示する。 図２は、追加の詳細とともに、図１ＢのＥ２Ｅ Ｍ２Ｍサービス層セッションを図示する。 図３は、なおもさらなる詳細とともに、図１ＢのＥ２Ｅ Ｍ２Ｍサービス層セッションを図示する。 図４は、セッション証明書機能ブートストラッピングの例示的方法を図示する。 図５は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャのための機能的アーキテクチャを図示する。 図６は、例示的Ｅ２Ｅ Ｍ２Ｍサービス層セッション確立コールフローを図示する。 図７は、複数のルートを伴う、２つのセッションエンドポイント間の例示的サービス層セッションを図示する。 図８は、セッションエンドポイントのための機能的アーキテクチャを図示する。 図９は、セッションマネージャのｏｎｅＭ２Ｍ実施形態を図示する。 図１０Ａは、ｏｎｅＭ２Ｍセッション管理（ＳＭＧ）サービスのためのＥ２Ｅ Ｍ２Ｍサービス層セッション確立プロシージャを図示する。 図１０Ｂは、図１０Ａからの続きのｏｎｅＭ２Ｍセッション管理（ＳＭＧ）サービスのためのＥ２Ｅ Ｍ２Ｍサービス層セッション確立プロシージャを図示する。 図１１Ａは、ｏｎｅＭ２Ｍ ＳＭＧサービスのためのセッション使用プロシージャを図示する。 図１１Ｂは、図１１Ａからの続きのｏｎｅＭ２Ｍ ＳＭＧサービスのためのセッション使用プロシージャを図示する。 図１２は、ｏｎｅＭ２Ｍ ＳＭＧサービスのための例示的Ｍ２Ｍセッション終了プロシージャを図示する。 図１３は、リソース「セッション」を図示する。 図１４は、ＣＳＥベースＵＲＩ下のセッションリソースインスタンス化を図示する。 図１５は、アプリケーションリソース下のセッションリソースインスタンス化を図示する。 図１６は、リソース＜ｓｅｓｓｉｏｎ＞を図示する。 図１７は、リソースセッションエンドポイントを図示する。 図１８は、リソース＜ｓｅｓｓｉｏｎＥｎｄｐｏｉｎｔ＞を図示する。 図１９は、リソースｎｅｘｔＨｏｐｓを図示する。 図２０は、リソース＜ｎｅｘｔＨｏｐ＞を図示する。 図２１は、リソースｓｅｓｓｉｏｎＰｏｌｉｃｉｅｓを図示する。 図２２は、リソース＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞を図示する。 図２３は、リソースｓｅｓｓｉｏｎＣｏｎｔｅｘｔを図示する。 図２４は、リソース＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔＩｎｓｔａｎｃｅ＞を図示する。 図２５は、Ｍ２Ｍセッション移転または共有の例示的使用例を図示する。 図２６は、Ｍ２Ｍセッション移転または共有のための別の例示的使用例を図示する。 図２７は、Ｍ２Ｍサービス層セッション移転の一実施例を示す。 図２８は、Ｍ２Ｍサービス層セッション共有の一実施例を示す。 図２９は、ネットワークのノードのサービス層インスタンスの一部として実装されるセッション移転および共有機能（ＳＭＳＦ）の一実施形態を図示する。 図３０は、既存のＭ２Ｍサービス層セッションの移転または１つ以上の将来のセッションパーティシパントとの共有のための方法の一実施形態を図示する。 図３１は、ｏｎｅＭ２Ｍアーキテクチャによる、能力サービスエンティティ（ＣＳＥ）内のサービスセッション管理（ＳＳＭ）能力サービス機能（ＣＳＦ）の一部として実装されるＳＭＳＦの一実施形態を図示する。 図３２は、一実施形態による、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎ＞リソース構造の修正を示す。 図３３は、一実施形態による、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソース構造の修正を示す。 図３４は、一実施形態による、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソース構造の修正を示す。 図３５は、一実施形態による、＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞リソース構造にリンクされる＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソース構造を図示する。 図３６Ａ−Ｃは、ｏｎｅＭ２Ｍサービス層セッションを移転させる方法の一例示的実施形態を図示する。 図３６Ａ−Ｃは、ｏｎｅＭ２Ｍサービス層セッションを移転させる方法の一例示的実施形態を図示する。 図３６Ａ−Ｃは、ｏｎｅＭ２Ｍサービス層セッションを移転させる方法の一例示的実施形態を図示する。 図３７Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムの系統図である。 図３７Ｂは、図３７Ａに図示されるＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図３７Ｃは、図３７Ａに例証される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ端末またはゲートウェイデバイスの系統図である。 図３７Ｄは、図３７Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。 図３８は、ユーザがエンドツーエンドセッション移転ポリシを双方向に構成および管理することを可能にするように実装され得る、グラフィカルユーザインターフェースの一実施形態を図示する。
前述のように、通信セッションは、ネットワークプロトコルスタック内の種々の層においてプロトコルおよびサービスの一部として実装され得る。例えば、図１Ａに図示されるように、通信接続／セッションは、トランスポートプロトコル層５０（例えば、ＴＣＰ接続）、セッションプロトコル層５２（例えば、ＴＬＳおよびＤＴＬＳセッション）、ウェブトランスポートプロトコル層５４（例えば、ＨＴＴＰおよびＣｏＡＰセッション）、マシンツーマシン（Ｍ２Ｍ）／モノのインターネット（ＩｏＴ）サービス層５６、およびアプリケーション層５８（例えば、アプリケーション特定のセッション）においてネットワークノード間に確立され得る。本願は、主に、Ｍ２Ｍ／ＩｏＴサービス層５６におけるセッションを標的化する特徴に関する。
例えば、ＥＴＳＩ ＴＳ１０２６９０１．１．１（２０１１−１０）に説明される欧州電気通信標準化機構（ＥＴＳＩ）Ｍ２Ｍアーキテクチャ、ｏｎｅＭ２Ｍ−ＴＳ−０００１ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−０．１．２に説明されるｏｎｅＭ２Ｍアーキテクチャ、第３世代パートナーシップ（３ＧＰＰ）によって開発されたマシン型通信（ＭＴＣ）アーキテクチャ、およびオープンモバイルアライアンス（ＯＭＡ）によって開発された軽量Ｍ２Ｍアーキテクチャ（ＬＷＭ２Ｍ）を含むいくつかのマシンツーマシン（Ｍ２Ｍ）通信アーキテクチャが、提案されている。これらのアーキテクチャの各々は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下層ネットワーキングインターフェースとの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層であるサービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス内に実装され得（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ内に実装され得（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ内に実装され得る（ＮＳＣＬ）と称される）。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、それは、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション特定のノード）上にホストされ得る。３ＧＰＰ ＭＴＣアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬ、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥ、または別のＭ２Ｍアーキテクチャのある他のコンポーネントもしくはモジュール内に具現化されるかどうかにかかわらず、サービス層は、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得、それは、サーバ、コンピュータ、もしくは他のコンピューティングデバイスもしくはノード等のネットワークの１つ以上の独立型ノード上、またはそのようなネットワークの１つ以上の既存のノードの一部としてのいずれかで実行する。例として、サービス層またはそのコンポーネントは、下に説明される図３７Ｃまたは図３７Ｄに図示される一般的アーキテクチャを有するノードまたはコンピューティングシステム上で起動するソフトウェアの形態で実装され得る。
既存のＭ２Ｍサービス層は、あるサービス層インスタンスから別のサービス層インスタンスへのＭ２Ｍサービス層セッションコンテキストの移転または共有のためのサポートを欠いている。同様に、Ｍ２Ｍアプリケーションインスタンス間のＭ２Ｍサービス層セッションコンテキストの移転または共有のためのサポートも欠いている。この機能性の欠如は、モバイルセッションパーティシパント、新しいＩＰアドレスが割り当てられた場合等のセッションパーティシパントアドレスにおける変化を伴う使用例、または新しいセッションパーティシパントとサービス層セッションを共有することを伴う使用例に対して、Ｍ２Ｍサービス層がサービス層セッションの持続性をサポートすることを妨げる。
Ｍ２Ｍサービスセッションコンテキストを移転させるためのサポートの欠如は、Ｍ２Ｍセンサに対する限界またはオーバーヘッドももたらし得る。例えば、Ｍ２Ｍサービス層セッションを最初から確立することは、有意な数のＭ２Ｍサービス層要求を伴い得、それは、限定ではないが、サービス層に登録すること、そのセンサ読み取り値を記憶するためのコンテナリソースを作成すること、関心がある通知を受信するためのサービス層へのサブスクリプションを作成すること、サービス層内のイベント発生条件を構成すること、ならびにサービス層内のメッセージ送達およびハンドリングポリシを構成することを行うための要求を含み得る。サービス層インスタンス間のサービス層セッションコンテキストの移転および共有をサポートすることによって、Ｍ２Ｍセンサへのこのオーバーヘッドは、最小化されることができる。
Ｍ２Ｍサービスセッションコンテキストを移転させるためのサポートの欠如はまた、Ｍ２Ｍアプリケーションに対する限界またはオーバーヘッドをもたらし得、Ｍ２Ｍサービスセッションコンテキストを移転させるためのサポートの欠如は、Ｍ２Ｍサービス層が、データにアクセスし、それを使用しているアプリケーションにより近いサービス層インスタンスへのサービス層データ（例えば、リソース表現）の移転／それの共有等の付加価値サービスを提供することも妨げ得る。
既存のＭ２Ｍサービス層セッションの移転または１つ以上のセッションパーティシパントとのそれの共有のための方法、デバイス、およびシステムが、本明細書に開示される。
（例示的サービス層セッション管理機構）
サービス層セッション移転および共有を以下で論じる前に、Ｍ２Ｍサービス層内でエンドツーエンド（Ｅ２Ｅ）セッションサポートを提供するための例示的機構が、図１−２４を参照して以下に提供される。しかしながら、本明細書に後述されるサービス層セッション移転および共有概念は、本節に開示されるサービス層セッション機構にいかようにも限定されないことを理解されたい。むしろ、これらの機構は、単に、サービス層セッションが実装され得る方法の一実施例として提供される。
Ｅ２Ｅ Ｍ２Ｍサービス層セッション（サービス層セッション）は、Ｍ２Ｍサービス層が、データ集約およびデータ分析等の他の付加価値セッション機能性の中でもとりわけ、エンドツーエンドセキュリティサービス、エンドツーエンドサービスの質機能性、設定または構成のエンドツーエンドネゴシエーションに関与することを可能にするセッションである。本明細書で論じられる方法および機能的アーキテクチャ（例えば、図４、図５、および全体を通して）は、ソフトウェアおよびハードウェアの組み合わせによって実装され得る。機能的アーキテクチャは、単一デバイス上に実装されるか、または複数のデバイス間に分散され得る。デバイスは、図３７Ａから図３７Ｄに関して以下に説明されるようなデバイスのうちの１つ以上のものであり得る。
追加の視点のために、図１Ｂは、複数のホップに及ぶ例示的Ｅ２Ｅ Ｍ２Ｍサービス層セッションを図示する。図１Ｂに図示されるように、Ｍ２Ｍデバイス１１０は、Ｍ２Ｍアプリケーション１１１を含み得る。Ｍ２Ｍアプリケーション１１１は、Ｍ２Ｍネットワークアプリケーション１１５（タブレット、サーバ、パーソナルコンピュータ、またはスマートフォン等のデバイス上にあり得る、エンドポイントＭ２Ｍアプリケーション）とのＥ２Ｅ Ｍ２Ｍサービス層セッションに関与し得る。Ｍ２Ｍアプリケーション１１１のＭ２Ｍサービス層セッションは、複数のホップ（ホップ１３０およびホップ１３１）を含み、Ｍ２Ｍサーバ１１８上に位置するＭ２Ｍサービス層インスタンス１２３によって促進される。
図１Ｂはまた、２つのＭ２Ｍサービス層インスタンス（１つは、Ｍ２Ｍサーバ上にホストされ、１つは、Ｍ２Ｍゲートウェイ上にホストされる）によって促進されるサービス層セッションの実施例を示す。図１Ｂに示されるように、Ｍ２Ｍデバイス１１２のＭ２Ｍアプリケーション１１３は、Ｍ２Ｍネットワークアプリケーション１１５とのＥ２Ｅ Ｍ２Ｍサービス層セッションに関与し得る。Ｍ２Ｍアプリケーション１１３のＭ２Ｍサービス層セッションは、複数のホップ（ホップ１３２、１３３、およびホップ１３４）を含み、複数のＭ２Ｍサービス層インスタンス（Ｍ２Ｍゲートウェイ１１４のＭ２Ｍサービス層インスタンス１２１、および、Ｍ２Ｍサーバ１１８のＭ２Ｍサービス層インスタンス１２３）によって促進される。Ｍ２Ｍサービス層インスタンス１２１およびＭ２Ｍサービス層インスタンス１２３は、互いに通信し、Ｅ２Ｅ Ｍ２Ｍサービス層セッションを管理し得る（例えば、セッションを確立するか、またはセッションを切断する）。
図１Ｂはまた、２つのＭ２Ｍゲートウェイ間のセッションに関与するサービス層セッションを示す。図１Ｂに示されるように、Ｍ２Ｍゲートウェイ１１６のＭ２Ｍサービス層インスタンス１２５は、Ｍ２Ｍゲートウェイ１１４のＭ２Ｍサービス層インスタンス１２１とのＭ２Ｍサービス層セッション内にある。Ｍ２Ｍサービス層インスタンス１２５のＭ２Ｍサービス層セッションは、複数のホップ（ホップ１３６およびホップ１３５）を含み、Ｍ２Ｍサーバ１１８のＭ２Ｍサービス層インスタンス１２３によって促進される。追加の例（図示せず）も、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのために可能である。例えば、Ｅ２Ｅ Ｍ２Ｍサービス層セッションは、互いから複数のサービス層ホップ離れた２つのＭ２Ｍサーバ間にあり得る。別の例は、Ｍ２Ｍサービス層を通してフローしないが、Ｍ２Ｍサービス層によって促進される、２つのエンドポイントアプリケーション間の直接Ｅ２Ｅセッションを伴い得る。言い換えると、サービス層は、アプリケーションが、互いに発見し、証明書を動的にプロビジョニングするために使用し得るアプリケーション発見およびＥ２Ｅセッション証明書確立サービスを提供し得る。さらに別の例として、Ｍ２Ｍサービス層セッションは、デバイス上のＭ２ＭアプリケーションとＭ２Ｍゲートウェイ上のＭ２Ｍサービス層インスタンスとの間に直接確立され得る。別の例として、Ｍ２Ｍサービス層セッションは、Ｍ２Ｍゲートウェイ上のＭ２Ｍサービス層インスタンスとＭ２Ｍサーバ上のサービス層インスタンスとの間に直接確立され得る。さらに別の例として、Ｍ２Ｍサービス層セッションは、複数のデバイス上の３つ以上のＭ２Ｍアプリケーション間に確立され得、それは、例えば、１つ以上のＭ２Ｍゲートウェイまたはサーバ上の１つ、２つ、またはそれを上回るＭ２Ｍサービス層インスタンスに及び得る。
以下により詳細に説明されるように、サービス層セッションをサポートするために、以下のＭ２Ｍサービス層アーキテクチャ要素のうちの１つ以上のものが、存在し得る：Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャ機能（セッションマネージャ機能）、Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイント機能（セッションエンドポイント機能）、Ｅ２Ｅ Ｍ２Ｍサービス層セッション証明書ブートストラッピング機能（セッション証明書機能）、Ｍ２Ｍサービス層セッション状態（セッション状態）、およびＥ２Ｅ Ｍ２Ｍサービス層セッションインターフェース（セッションインターフェース）。図２は、前述のＭ２Ｍサービス層アーキテクチャ要素を含む、図１ＢにおけるＭ２Ｍセッションの例証である。セッションエンドポイント機能１４０、セッションエンドポイント機能１４９、およびセッションエンドポイント機能１４８等のＭ２Ｍセッションエンドポイント機能は、それぞれ、Ｍ２Ｍデバイス１１０、Ｍ２Ｍサーバ１１８、およびＭ２Ｍネットワークアプリケーション１１５とともにあり得る。本明細書により詳細に論じられるように、セッションエンドポイント機能は、Ｍ２ＭアプリケーションまたはＭ２Ｍサービス層インスタンスが、サービス層セッションに参加することを可能にする。セッションエンドポイント機能は、セッションマネージャと相互作用する。
図２を継続して参照すると、Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャ（例えば、セッションマネージャ１４５）は、Ｍ２Ｍサーバ（例えば、Ｍ２Ｍサーバ１１８）またはＭ２Ｍゲートウェイとともにあり得る。図２に図示されないが、Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャは、デバイス自体がサービス層をホストする場合、Ｍ２Ｍデバイス上にも常駐し得る。以下により詳細に論じられるように、セッションマネージャは、サービス層セッションの確立、切断、および管理をサポートする。セッションマネージャは、セッションアドレスまたは識別子アドレスの変換を行ない得る（例えば、公開セッション識別子とプライベートセッション識別子との間の変換）。加えて、セッションマネージャは、サービス層メッセージを、これらのメッセージがそれに直接接続されていないセッションエンドポイントに送達され得るように、他のセッションマネージャにルーティングするための能力をサポートする。
図２をさらに参照すると、Ｍ２Ｍサービス層セッションは、セッション証明書機能１４７等のセッション証明書機能を伴い得る。セッション証明書機能１４７は、サービス層セッション関連証明書および構成情報のプロビジョニングまたはブートストラッピングをサポートし得る。セッションマネージャまたはセッションエンドポイントは、これらのセッション証明書を使用し得る。セッション証明書機能は、ＡＡＡサーバ上に常駐し、ダイアメータプロトコルを使用する、ＩＣｒｅｄｅｎｔｉａｌインターフェース（例えば、ＩＣｒｅｄｅｎｔｉａｌ１５７）を有し得る。加えて、サービス層セッションは、Ｍ２Ｍデバイス１１０、Ｍ２Ｍサーバ１１８、およびＭ２Ｍネットワーク１１５等のＭ２Ｍデバイスの任意のものが有し得るセッション状態を含み得る。セッション状態は、セッションマネージャまたはセッションエンドポイントによって維持され得、セッション管理目的のために使用され得る情報である。
図３は、前述のＭ２Ｍサービス層アーキテクチャ要素を含む、図１Ｂのサービス層セッションの複数の実施例を図示する。図３に示されるように、セッションマネージャ間のＩＭａｎａｇｅｒ−Ｍａｎａｇｅｒインターフェース（例えば、ＩＭａｎａｇｅｒ−Ｍａｎａｇｅｒ１５４）、およびセッションエンドポイントとセッションマネージャとの間のＩＥｎｄｐｏｉｎｔ−Ｍａｎａｇｅｒインターフェース（例えば、ＩＥｎｄｐｏｉｎｔ−Ｍａｎａｇｅｒ１５３、ＩＥｎｄｐｏｉｎｔ−Ｍａｎａｇｅｒ１５５、ＩＥｎｄｐｏｉｎｔ−Ｍａｎａｇｅｒ１５６）が存在し得る。図３に示されるように、セッションマネージャ１４５は、複数のノード間の複数のＭ２Ｍサービス層セッションを管理する。
以下は、とりわけ、セッション証明書機能、セッションマネージャ、およびセッション状態情報等、図３の機能のうちのいくつかに関するより詳細な方法およびシステム説明である。
セッション証明書機能は、複数のサービス層ホップに及ぶサービス層セッションを作り上げる個々のセッションエンドポイントおよびセッションマネージャへのセッションセキュリティ証明書（「セキュリティ証明書」または「セッション証明書」）のブートストラッピングをサポートし、サービス層ホップは、サービス層インスタンスまたはアプリケーションのうちの２つ以上のものの間の直接サービス層通信リンクとして定義され得る。本明細書に論じられるように、セッションをセキュアにするためのセッション証明書およびセキュリティ証明書は、同じ意味で使用される。セッション証明書をプロビジョニングする方法（図示せず）は、セッション証明書機能のマネージャまたは所有者によって行われる事前プロビジョニングステップであり得る。例えば、サービス層インスタンス毎に、セッション証明書のプールが、セッション証明書機能の中に事前プロビジョニングされ得る。その後、セッションマネージャは、必要なとき、セッション証明書を配分するため要求をセッション証明書機能に行ない得る。
図４は、Ｍ２Ｍデバイス、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ等上に常駐し得る異なるセッションパーティシパント間にセッション証明書を構成するセッション証明書機能ブートストラッピングの例示的方法を図示する。図４に対して、セッションエンドポイント１４０は、開始アプリケーションの一部である一方、セッションエンドポイント１４８は、標的アプリケーションの一部であると仮定され得る。
ステップ２０１、ステップ２０２、およびステップ２０３において、セキュアなシングルホップセッションが、確立され得る。ステップ２０１では、セキュアなシングルホップセッションが、セッションマネージャ１４５とセッション証明書機能１４７との間にある。ステップ２０２では、セキュアなシングルホップセッションは、セッションマネージャ１４５とセッションエンドポイント１４０との間にある。ステップ２０３では、セキュアなシングルホップセッションは、セッションマネージャ１４５とセッションエンドポイント１４８との間にある。ステップ２０１、ステップ２０２、およびステップ２０３のセキュアなシングルホップセッションは、ＥＴＳＩ Ｍ２ＭおよびＯＭＡ ＬＷＭ２Ｍ等のアーキテクチャ内にサポートされる従来のサービス層ブートストラップおよび登録プロシージャによって確立され得る。
ステップ２０４において、セッションエンドポイント１４０は、セッションマネージャ１４５に、クエリを行い（例えば、セッション証明書ブートストラップ要求を提供し）、利用可能な他のセッションエンドポイントおよびその対応する属性を発見するか、または特定のセッションエンドポイントを要求し得る。他のセッションエンドポイントを明示的に発見することの代替は、セッションエンドポイント１４０が、ステップ２０４のブートストラップ要求内でセッションを確立することを望むセッションエンドポイントのタイプ等の情報を提供し、セッションマネージャに最良セッションエンドポイントを決定させることである。セッション証明書ブートストラップ要求は、サービス層セッションを確立することを欲するアプリケーション、ゲートウェイ、サーバ等に関連付けられたセッションエンドポイントによって開始され得る。セッション証明書ブートストラップ要求は、開始セッションエンドポイントがサービス層セッションを確立しようとしている、１つ以上の標的セッションエンドポイント等の情報を含み得る。加えて、セッション証明書ブートストラップ要求は、セッションエンドポイントの所望のタイプに関する情報を含み得、セッションマネージャが、１つ以上の標的セッションエンドポイントを選択し、サービス層セッション証明書を配布するためにその情報を使用し得る。セッション証明書ブートストラップ要求は、とりわけ、セッションの要求されるＱｏＳ、標的セッションエンドポイントの場所、および開始アプリケーションが支払いたい額等の情報も含み得る。
ステップ２０５において、セッションマネージャ１４５は、ステップ２０４のセッション証明書ブートストラップ要求を解析し、セッション証明書を配布することが許可される標的セッションエンドポイント、または代替として、それがセッション証明書機能１４７とブートストラップすることを求め得るセッションエンドポイントを決定する。加えて、セッションマネージャ１４５は、サービス層セッションに関与し得る任意の中間サービス層インスタンス（例えば、サービス層インスタンスを伴うＭ２ＭゲートウェイまたはＭ２Ｍサーバ）を決定する。標的セッションエンドポイントおよび中間サービス層インスタンスの決定は、異なる方法で行われ得る。例えば、セッションマネージャ１４５は、標的セッションエンドポイントのリスト等、ステップ２０４におけるセッション証明書ブートストラップ要求とともに含まれる情報を使用し得る。代替として、要求側セッションエンドポイント（例えば、セッションエンドポイント１４０）またはセッションポリシによってセッション状態として維持される履歴またはコンテキスト情報も、使用され得る。セッション状態を使用して、セッションマネージャ１４５は、セッション証明書を配布するために選択する標的セッションエンドポイントをさらに絞り込み得る。
図４を継続して参照すると、ステップ２０６において、セッションマネージャ１４５は、Ｅ２Ｅ Ｍ２Ｍセッション証明書要求をセッション証明書機能１４７に送信し得る。ステップ２０６の証明書要求は、ステップ２０５の決定された標的セッションエンドポイントおよび決定されたサービス層インスタンスのためのセッション証明書の組を配分するための要求を含み得る。ステップ２０７において、セッション証明書機能１４７は、セッションマネージャ１４５、セッションエンドポイント１４８、およびセッションエンドポイント１４０のためのセッション証明書の組を作成する。加えて、ステップ２０７において、証明書機能１４７は、セッション証明書の状態を維持する。証明書状態は、すでに作成されたサービス層セッションのセッション証明書を所望し得る任意のアプリケーション、インスタンス等に送信され得る。ステップ２０８において、セッション証明書機能１４７は、セッションマネージャ１４５に、Ｅ２Ｅ Ｍ２Ｍセッション証明書応答を送信する。セッション証明書応答は、任意の数のアプリケーションまたはサービス層インスタンスに配分され得るセッション証明書を含み得る。代替として、証明書応答は、セッション証明書の組を含み得、セッション証明書の組内の各セッション証明書は、特に、作成されることが所望されるサービス層セッションに関与するサービス層インスタンスまたはアプリケーションに割り当てられ得る。
ステップ２０９において、ステップ２０８のセッション証明書を受信すると、セッションマネージャ１４５は、セッションマネージャ１４５も、セッション証明書を使用し得るように、セッション証明書をローカルに記憶し得る。例えば、セッションマネージャ１４５は、サービス層インスタンス（例えば、サービス層インスタンス１２３）を通してフローするアプリケーションデータを暗号化または復号化し、付加価値データサービスを提供し得る。ステップ２１０において、セッションマネージャ１４５は、セッションエンドポイント１４８に、ステップ２０８のセッション証明書を含み得るＥ２Ｅセッション証明書構成要求を送信する。Ｅ２Ｅセッション証明書構成要求はまた、セッションエンドポイント１４８がセッションエンドポイント１４０とのサービス層セッションに参加するための能力に対する要求を含み得る。例えば、セッションエンドポイント１４８は、サービス層セッションがその時間において可能にしないこともあるポリシを有し得る。ステップ２１１において、セッションエンドポイント１４８は、提案されるセッションの間、セッション証明書状態を維持する。ステップ２１２において、セッションエンドポイント１４８は、セッションマネージャ１４５に、送信されたセッション証明書を受信および実装した確認を含み得るＥ２Ｅセッション証明書構成応答を送信する。
図４をさらに参照すると、ステップ２１３において、セッションマネージャ１４５は、セッションエンドポイント１４０に、Ｅ２Ｅセキュリティ証明書ブートストラップ応答を送信し得る。ステップ２１３のＥ２Ｅセキュリティ証明書ブートストラップ応答は、最終的には、ステップ２０４の要求に応答し得、セッション証明書と、サービス層セッションのためのセッション証明書を伴う標的セッションエンドポイントのリストとを含み得る。ステップ２１４において、セッション証明書を受信すると、セッションエンドポイント１４０は、受信された証明書の状態情報を維持し得る。
図４を継続して参照すると、セッションエンドポイント（例えば、セッションエンドポイント１４０およびセッションエンドポイント１４８）は、セッション証明書をリフレッシュするために、ブートストラッピング動作を周期的に繰り返す必要があり得る。この周期的リフレッシュは、セッション証明書に関連付けられた有効期間に基づき得る。共通セッション証明書をセキュアにブートストラップすることは、開始セッションエンドポイント１４０、ローカルセッションマネージャ１４５（セッションエンドポイント１４０のために直接登録されたセッションマネージャ）、任意の中間サービス層セッションマネージャ（ここには示されないが、随時、適用可能であり得る）、および１つ以上の標的Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイント（例えば、セッションエンドポイント１４８）間にセキュアな信頼チェーンを確立し得る。このセキュアなＥ２Ｅ信頼チェーンは、セキュア化された下層の従来のシングルホップＭ２Ｍサービス層セッション、ならびに存在し得るセキュア化された下層トランスポート層およびアクセスネットワーク接続上に層化され得る。代替として、前述のセキュアなＥ２Ｅ信頼チェーンは、ホップ毎方式において互いにではなく、セッション証明書機能を用いて各セッションエンドポイントおよびセッションマネージャに認証させることによって、確立され得る。
図４に図示されるステップを行うエンティティは、図３７Ｃまたは図３７Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理的エンティティであることを理解されたい。すなわち、図４に図示される方法は、ノードのプロセッサによって実行されると、図４に図示されるステップを行うコンピュータ実行可能命令である、図３７Ｃまたは図３７Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。
セッション証明書は、開始Ｍ２Ｍアプリケーション、ならびにそれが登録されるＭ２Ｍサービス層インスタンス、ならびに１つ以上の標的Ｍ２Ｍアプリケーションにブートストラップされ得る。証明書はまた、サービス層ルートポリシ、コンテキスト情報、または履歴情報に基づいて、他のＭ２Ｍサービス層インスタンスにもブートストラップされ得る（例えば、他のＭ２Ｍサービス層インスタンスが、開始Ｍ２Ｍアプリケーションと標的Ｍ２Ｍアプリケーションとの間のマルチホップパス内に存在する場合）。
図５は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャ（例えば、セッションマネージャ１４５）のための機能的アーキテクチャを図示する。図５に示されるように、セッションマネージャ１４５は、セッション証明書機能１４７と、Ｅ２Ｅ Ｍ２Ｍセッションコンテキストおよび履歴機能１６１（セッションコンテキスト機能）と、Ｅ２Ｅ Ｍ２Ｍセッションルート機能１６２（セッションルート機能）と、Ｅ２Ｅ Ｍ２Ｍセッション確立および切断機能１６３（セッション確立機能）と、Ｅ２Ｅ Ｍ２Ｍセッションポリシ機能１６４（セッションポリシ機能）と、Ｅ２Ｅ Ｍ２Ｍセッション構成および発見機能１６５（セッション構成機能）と、Ｅ２Ｅ Ｍ２Ｍセッションデータ管理機能１６６（セッションデータ管理機能）と、セッション状態１５１とを含み得る。ある実施形態では、セッションマネージャ１４５は、Ｍ２Ｍサービス層インスタンス（例えば、サービス層インスタンス１２３）の能力としてサポートされ得る。別の実施形態では、セッションマネージャ１４５は、Ｍ２Ｍサービス層インスタンスがインターフェースをとり得る別個のサービス（例えば、独立型ウェブサービス）としてサポートされ得る。本明細書により詳細に論じられるのは、セッションマネージャの機能の各々の説明である。
Ｅ２Ｅ Ｍ２Ｍセッション確立および切断機能１６３（セッション確立機能）は、サービス層セッションを確立することまたは切断することに対する要求を処理する。セッションエンドポイントは、要求をセッション確立機能に送信し、１つ以上の標的セッションエンドポイントとサービス層セッションを確立し得る。証明書が正常にブートストラップまたはプロビジョニングされる場合、もしくはセキュリティが要求されない場合、セッション確立機能は、要求されると、サービス層セッションを確立することまたは切断することを続行し得る。Ｅ２Ｅ Ｍ２Ｍサービス層セッションは、既存のシングルホップＭ２Ｍサービス層セッションまたはトランスポート層セッションの上にサービス層セッションを層化することによって確立されることができる。これは、各セッションエンドポイント、ならびにサービス層セッションパスに沿う各中間セッションマネージャのためにセッション状態を維持および／または分配することによって達成されることができる。このセッション状態は、セッションセキュリティ証明書、セッションルート情報、セッションコンテキスト、およびセッションポリシ等の情報を含み得る。各セッションエンドポイントおよびセッションマネージャにおけるセッション状態の構成は、指定されたセッションマネージャ（例えば、サービス層セッション確立要求を開始するセッションエンドポイントに最も近いセッションマネージャ）によって管理され得る。
図６は、例示的Ｅ２Ｅ Ｍ２Ｍサービス層セッション確立コールフローを図示する。この例では、セッションエンドポイント１４０は、３つのサービス層ホップ離れた（すなわち、２つのＭ２Ｍサービス層インスタンスによって分離される）、セッションエンドポイント１４８とのサービス層セッションを開始する。ステップ２２０では、セッションエンドポイント１４０、セッションエンドポイント１４８、およびセッションマネージャ（例えば、セッションマネージャ１４１およびセッションマネージャ１４５）は、本明細書に説明されるように、Ｅ２Ｅ Ｍ２Ｍサービス層セッション証明書をブートストラップまたはプロビジョニングされている（図４に関する実施例参照）。ステップ２２１において、セッションエンドポイント１４０は、セッションマネージャ１４１に、サービス層セッションを認証および確立するための要求を送信する。ステップ２２１の要求は、ステップ２２０において受信されたセッション証明書を含み得る。ある実施形態では（図示せず）、セッションエンドポイント１４０は、複数の要求を１つ以上のセッションマネージャに送信し、複数の標的セッションエンドポイントとＥ２Ｅ Ｍ２Ｍサービス層セッションを確立し得る（例えば、グループセッション）。
ステップ２２２において、セッションマネージャ１４１は、セッションエンドポイント１４０のセッション証明書に基づいて、セッションエンドポイント１４０を認証する。加えて、ステップ２２２において、セッションマネージャ１４１は、サービス層セッションを認証および確立するための要求を転送すべき次のホップを決定する。セッションマネージャ１４１は、要求内に含まれる情報、ローカルに記憶されたコンテキストおよびポリシに基づいて、ネットワーク内の他のセッションマネージャと協働することによって、次のホップを決定する。この例では、次のホップは、別のセッションマネージャ（例えば、セッションマネージャ１４５）である。図６に示されるように、ステップ２２３において、セッションマネージャ１４１は、セッションマネージャ１４５に、サービス層セッションを認証および確立するための要求を送信する。ステップ２２３の要求は、ステップ２２０において受信されたセッション証明書を含み得る。ステップ２２４において、セッションマネージャ１４５は、セッションマネージャ１４１のセッション証明書に基づいて、セッションマネージャ１４１を認証し、サービス層セッションを認証および確立するための要求を転送すべき次のホップを決定する。ステップ２２５において、セッションマネージャ１４５は、ステップ２２１と同様に、セッションエンドポイント１４８に、サービス層セッションを認証および確立するための要求を送信する。ステップ２２６において、セッションエンドポイント１４８は、セッション証明書に基づいて、セッションマネージャ１４５を認証し、セッションエンドポイント１４０がそれと通信することを所望していることを決定し、セッション証明書に基づいて、セッションエンドポイント１４０を認証する。さらに、ステップ２２６において、セッションエンドポイント１４８は、以下により詳細に説明される、セッション状態情報を記憶し得る。
ステップ２２７において、セッションエンドポイント１４８は、セッションマネージャ１４５に、Ｅ２Ｅセッション応答を送信する。ステップ２２７のＥ２Ｅセッション応答は、セッションエンドポイント１４０とのサービス層セッションの確立を確認する応答ならびに他のサービス層セッション状態情報を含み得る。ステップ２２７のＥ２Ｅセッション応答は、ステップ２２９およびステップ２３１において、セッションエンドポイント１４０に継続的に転送される。ステップ２２５の応答が、各ホップに対して逆転送されるにつれて、サービス層セッション状態情報は、ステップ２２８およびステップ２３０において、各セッションマネージャによって、ならびにステップ２３２において、開始セッションエンドポイント（セッションエンドポイント１４０）によって記憶される。このサービス層セッション状態情報は、サービス層セッションが、セッションマネージャを介して、セッションエンドポイント間でメッセージＥ２Ｅを交換するために使用され得るように、サービス層セッションを維持するために使用される。
図６を継続して参照すると、セッションマネージャ（例えば、セッションマネージャ１４１またはセッションマネージャ１４５）は、サービス層セッションメッセージのルートパスを動的に変更し得る。例えば、セッションマネージャ１４１とセッションマネージャ１４５との間のシングルホップセッションが切断する場合、上流セッションマネージャ（この場合、セッションマネージャ１４１）は、標的セッションエンドポイント（例えば、セッションエンドポイント１４８）と確立されたシングルホップセッションを偶然有する別の近隣セッションマネージャと新しいシングルホップサービス層セッションを確立することによって（利用可能な場合）、回復し得る。Ｅ２Ｅ Ｍ２Ｍサービス層セッションルートに関するさらなる詳細のために、以下を参照されたい。加えて、図６には図示されないが（図３参照）、セッションエンドポイントとセッションマネージャとが互いに認証することの代替は、それらが、代わりに、ネットワーク内のセッション証明書機能と直接認証を行うことである。信頼されたセッション証明書機能は、セッションエンドポイントおよびセッションマネージャが認証することができるネットワーク内の中心ノードであり得る。これを行うことによって、それらは、互いにではなく、この機能によって認証されることができる。
サービス層セッションの切断は、セッションエンドポイントおよびセッションマネージャにおけるサービス層セッション状態情報を除去することによって、類似方式で機能し得る。サービス層セッションの切断の間、サービス層セッション状態情報は、標的セッションエンドポイントにおいて開始し、開始セッションエンドポイントに向かって削除され得、それは、各セッションマネージャにおけるサービス層セッション状態情報も除去する。図６に図示されるステップを行うエンティティは、図３７Ｃまたは図３７Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理的エンティティであることを理解されたい。すなわち、図６に図示される方法は、ノードのプロセッサによって実行されると、図６に図示されるステップを行うコンピュータ実行可能命令である、図３７Ｃまたは図３７Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。
ここに論じられるのは、図５の機能的アーキテクチャにも示されるようなＥ２Ｅ Ｍ２Ｍサービス層セッションルート（セッションルート）に関するさらなる詳細である。図７は、サービス層セッションエンドポイント間に複数のサービス層セッションルートを有する、２つのセッションエンドポイント間の例示的単一サービス層セッションを図示する。
各Ｅ２Ｅ Ｍ２Ｍサービス層セッションルートは、Ｍ２ＭセッションエンドポイントおよびＭ２Ｍセッションマネージャを互いに相互接続する異なる一連のシングルホップＭ２Ｍサービス層セッションから成り得る。図７は、ルート２５７（すなわち、実線）またはルート２５９（すなわち、点線）等の複数のルートをとり得る、１つのサービス層セッションを図示する。セッションエンドポイント２５０とセッションエンドポイント２５２との間の複数のサービス層セッションルートは、冗長性、故障保護、およびさらに異なるレベルのサービスの質を提供し得る。セッションマネージャ２５１、セッションマネージャ２５３、およびセッションマネージャ２５５は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションルート機能（セッションルート機能）をサポートし、指定されたサービス層セッションに関連付けられたメッセージを複数のサポートされるセッションルートのうちの１つにルーティングし得る。セッションルート機能は、コンテキスト認識ならびにポリシベースのルートをサポートし得る。例えば、セッションマネージャ２５５のセッションルート機能は、過去のメッセージおよびこれらのメッセージのために選定されたルートの履歴を保つことによって、異なるセッションパスを横断して指定されるサービス層セッションを負荷分散し得る。セッションマネージャ２５５のセッションルート機能は、負荷状態または故障に基づいて、サービス層ルートを適応させ得、これは、より優れた回復力およびＱｏＳを提供し得る。セッションルート機能は、情報がサービス層ルート決定ならびに下層アクセスネットワークルート決定に考慮され得るように、下層アクセスネットワークとインターフェースをとり、情報を共有することをサポートをし得る。
サポートされ得る別の形態のセッションルートは、サービス層セッションに関連付けられ得る複数の下層トランスポートセッションまたはアクセスネットワーク接続間のルートである。これをサポートするために、サービス層セッションマネージャ２５５は、下層トランスポート／アクセスネットワークルート機能とインターフェースを有し得る。例えば、Ｍ２ＭデバイスまたはＭ２Ｍゲートウェイは、複数の無線アクセス技術（例えば、Ｗｉ−Ｆｉ、セルラー等）をサポートし得る。Ｅ２Ｅサービス層セッションは、複数のシングルホップＭ２Ｍサービス層セッションの上に層化され得る。各シングルホップサービス層セッションは、それに関連付けられた複数の下層トランスポートまたはアクセスネットワーク接続を有し得る。サービス層セッションマネージャ２５５は、下層トランスポートまたはアクセスネットワークルート機能と協働し、シングルホップごとベースで使用するために、下層トランスポートまたはアクセスネットワーク接続のルートおよび選択を管理し得る。
図７を継続して参照すると、代替として、サービス層は、下層ネットワークルート機能と協働し、Ｅ２Ｅベースで使用するために、下層トランスポートまたはアクセスネットワーク接続のルートおよび選択を管理し得る。そうすることによって、セキュリティおよびＱｏＳは、単にホップごとベースではなく、Ｅ２Ｅ方式で管理され得る。例えば、このＥ２Ｅ管理は、ルートポリシを、サービス層セッションの確立に関わるセッションマネージャ（例えば、セッションマネージャ２５５）から、指定されたサービス層セッションに関連付けられたセッションマネージャの残り（例えば、セッションマネージャ２５１およびセッションマネージャ２５３）に配信することによって行われ得る。Ｅ２Ｅ管理は、シングルホップルートを用いてサポートすることが困難であり得るルート最適化を可能にする。例えば、セッションエンドポイント２５０をホストするデバイスが、セッションエンドポイント２５２をホストするデバイスに接近する場合、Ｅ２Ｅルート最適化は、動的に行われ得る。別の例では、Ｍ２ＭサーバおよびＭ２Ｍゲートウェイの両方を通した１つのアプリケーションから別のアプリケーションへのルートサービス層セッションメッセージの代わりに、Ｅ２Ｅルート最適化は、両方のアプリケーションに近接する共有Ｍ２Ｍゲートウェイを通してサービス層セッションメッセージをルーティングすることによって、またはアプリケーション間に直接ピアツーピアルートを確立することによって、Ｅ２Ｅルートを最適化するために行われ得る。
以下は、図５に示されるような機能的アーキテクチャに関するさらなる詳細である。機能的アーキテクチャは、単一デバイス上に実装されるか、または複数のデバイスを横断して分散され得る。図５に示される、Ｅ２Ｅ Ｍ２Ｍサービス層セッションコンテキストおよび履歴機能（セッションコンテキスト機能）１６１は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションコンテキストおよび履歴情報を収集、解釈、共有、および処理し得る。セッションマネージャおよびセッションエンドポイントは、セッションコンテキスト情報を利用し、サービス層セッションの使用および管理に関するコンテキスト認識決定を行ない得る。加えて、セッションコンテキスト情報は、課金および請求ならびに履歴および追跡等の目的のために利用され得る。セッションコンテキスト機能１６１はまた、セッションマネージャおよび／またはエンドポイント間のセッションコンテキスト情報の共有をサポートする。
いくつかの形態のＥ２Ｅ Ｍ２Ｍサービス層セッションコンテキスト情報は、以下のうちの１つ以上のものを含み得る。１）過去のサービス層セッションルート決定、２）サービス層セッションに関連する動的に変化するコストまたは価格情報、ならびに利用される下層トランスポートおよびアクセスネットワーク接続、３）サービス層セッションに関連付けられたＭ２Ｍデバイスおよびゲートウェイの場所、４）サービス層セッションに関連付けられたアクセスネットワーク接続のためのアクセスネットワーク輻輳情報および利用可能な帯域幅、および、５）指定されたサービス層セッションに関連付けられたＭ２Ｍデバイスおよびゲートウェイの可用性（例えば、Ｍ２Ｍデバイスまたはゲートウェイがスリープ状態であるかどうか）
いくつかのコンテキスト認識サービス層セッション関連決定は、以下のうちの１つ以上のものを含み得る。１）コンテキスト認識セッションルート、２）コンテキスト認識サービス層セッション負荷分散、３）メッセージのコンテキスト認識サービス層セッション記憶および転送（例えば、セッションエンドポイントが利用不可能である間）、および、４）セッションエンドポイントからのデータのコンテキスト認識サービス層セッション積極的プリフェッチングおよびキャッシュ、ならびにより効率的アクセスのためのそのデータのサービス層内へのキャッシュ。
図５は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションポリシ機能（セッションポリシ機能）１６４も示す。セッションポリシ機能１６４は、セッションポリシ構成、管理、および共有をサポートする。サービス層セッションポリシを使用して、セッションマネージャは、セッションエンドポイント間のサービス層セッション通信をより知的に管理し得る。加えて、セッションポリシ機能１６４は、セッションマネージャまたはセッションエンドポイント間のサービス層セッションポリシの共有をサポートする。いくつかのサービス層セッションポリシは、以下のうちの１つ以上のものを含み得る。１）セッションルートポリシ、２）Ｅ２Ｅ Ｍ２Ｍサービス層セッション記憶および転送ポリシ、３）サービス層セッションプリフェッチングポリシ、４）サービス層セッション確立ポリシ、５）サービス層セッション切断ポリシ、６）収集すべきコンテキスト、コンテキストの解釈方法、意思決定等へのコンテキストの組み入れ方法を決定する、セッションコンテキストポリシ、および、７）認証およびセッションに関連付けられた情報へのアクセス制御を制御し得るサービス層セッションセキュリティポリシ。
図５は、Ｅ２Ｅ Ｍ２Ｍサービス層セッション属性およびパラメータのための構成および発見能力をサポートする、Ｅ２Ｅ Ｍ２Ｍサービス層セッション構成および発見機能１６５（セッション構成）も示す。サービス層セッション属性およびパラメータの構成は、確立中ならびに通常のサービス層セッション動作中、サービス層セッションを制御およびカスタマイズするために使用され得る。サービス層セッション状態情報の発見は、所望の基準の組に基づいて、利用可能なサービス層セッションを見つけるために使用され得る。これは、Ｍ２ＭアプリケーションおよびＭ２Ｍサービス層インスタンスが、すでに進行中の既存のサービス層セッションまたはサービス層セッションをサポートする候補を、対応するセッション基準もしくは属性とともに見つけることを支援し得る。いくつかのタイプのＥ２Ｅ Ｍ２Ｍサービス層セッション構成および発見は、以下のうちの１つ以上のものを含み得る。１）セッションマネージャによる、セッションエンドポイント上にホストされたサービス層セッション状態の構成、およびその逆、２）別のセッションマネージャによる、セッションマネージャ上にホストされたサービス層セッション状態の構成、３）セッションエンドポイントによる、セッションマネージャ上にホストされたサービス層セッション状態の発見、およびその逆、および、４）別のセッションマネージャによる、セッションマネージャ上にホストされたサービス層セッション状態の発見。
図５は、サービス層インスタンスによって処理されるサービス層セッションメッセージ内に含まれるデータの管理をサポートし得るＥ２Ｅ Ｍ２Ｍセッションデータ管理機能１６６（セッションデータ管理機能）も示す。サービス層インスタンスの中にブートストラップされたセッション証明書を利用して、この機能は、受信されたサービス層セッションメッセージ内に含まれるデータの復号化、ならびにサービス層インスタンスおよびアプリケーションに転送されるサービス層セッションメッセージ内に含まれるサービス層セッションデータの暗号化をサポートする。データが復号化されると、この機能は、サービス層インスタンスにおける他の機能（とりわけ、データ分析機能、データ集約機能、またはデータマッシュアップ等）にこのデータをインターフェースおよびパスすることをサポートする。中間Ｍ２Ｍサービス層インスタンス上においてこれらのタイプの機能をサポートすることは、これらのサービス層インスタンスが、ネットワークを通してフローするメッセージへの付加価値データサービスをサポートすることを可能にし、それは、ネットワークをより効率的にし、セッションエンドポイントアプリケーションの複雑性も同様に低減させるために役立ち得る。
図５は、以下のうちの１つ以上のものを含み得る、Ｅ２Ｅ Ｍ２Ｍセッション状態１５１（セッション状態）も示す：Ｅ２Ｅ Ｍ２Ｍサービス層セッション識別子（セッション識別子）、Ｅ２Ｅ Ｍ２Ｍサービス層セッションセキュリティ証明書（セッションセキュリティ証明書）、Ｅ２Ｅ Ｍ２Ｍサービス層セッション記述子（セッション記述子）、Ｅ２Ｅ Ｍ２Ｍサービス層セッションルート情報（セッションルート情報）、Ｅ２Ｅ Ｍ２Ｍサービス層セッションコンテキストまたは履歴（セッションコンテキスト）、およびＥ２Ｅ Ｍ２Ｍサービス層セッションポリシ（セッションポリシ）。セッション識別子は、セッションマネージャおよびセッションクライアント（例えば、セッションアプリケーションまたはサービス層インスタンス）によって、サービス層セッションを識別するために使用され得る。セッション識別子は、随意に、その対応するセッションマネージャ、セッションエンドポイント、およびセッション証明書機能によってのみ暗号化／復号化され得るように、セッション証明書を使用してハッシュされ得る任意かつ固有の英数字文字列であり得る。
セッション識別子は、セッションに関連付けられた対応するセッションタイプおよび／または機能性を示す記述的英数字文字列であり得る。この記述的セッション識別子は、セッション発見目的のために使用され、セッション情報（例えば、センサ１２３−測定、照明ＡＢＣ−制御等）の共有を促進し得る。記述的セッション識別子は、グループセッションの動的形成をサポートするためにも同様に役立ち得る。記述的セッション識別子は、随意に、記述的セッション識別子がその対応するセッションマネージャ、セッションエンドポイント、およびセッション証明書機能によってのみ暗号化／復号化され得るように、セッション証明書を使用してハッシュされ得る。
セッション識別子は、他の識別子の一部をリサイクルし得る。セッションエンドポイントは、典型的には、それらに割り当てられた固有の識別子をサポートする。例えば、Ｍ２Ｍアプリケーションは、Ｍ２Ｍサービス層インスタンスに登録するとき、固有のアプリケーション識別子を配分される。同様に、Ｍ２Ｍサービス層インスタンスは、固有の識別子をプロビジョニングされるか、またはブートストラッピングプロシージャ中にそれで動的に構成されるかのいずれかである。これらの固有の識別子は、Ｅ２Ｅ Ｍ２Ｍサービス層セッション識別子を作成するために使用され得る。セッションエンドポイントは、セッション確立中、固有の識別子を互いに交換し得、これらの固有の識別子は、連結され、２つのセッションエンドポイント間に固有のセッション識別子を形成し得る。
セッション状態は、サービス層セッションに関連付けられたセキュリティ証明書（例えば、Ｅ２Ｅセキュリティ証明、公開キー等）を含み得る。サービス層セッションは、独立した証明書の組（例えば、Ｅ２Ｅ Ｍ２Ｍサービス層セッション証明書機能によって確立および配信される）をサポートし得るか、または、それは、随意に、下層セッションまたは接続からのセキュリティ証明書を利用し得る。例えば、下層シングルホップＭ２Ｍサービス層セッション、トランスポート層セッション、および／またはアクセスネットワーク接続からのセキュリティ証明書が、利用され得る。
セッション状態は、セッションを記述する情報であるセッション記述子を含み得、それは、既存のセッションパーティシパント（例えば、セッションエンドポイント、セッションマネージャ、またはセッション証明書機能）によって、または、既存のサービス層セッションを発見するために将来のセッションパーティシパントによって使用され得る。セッション記述子は、各セッションパーティシパントに対する説明（例えば、デバイス識別子、パーティシパントのタイプ、パーティシパントがサポートするサービス、パーティシパントのインターフェース要件、使用される圧縮のタイプ等）であり得る。セッション記述子は、サービス層セッションを構築するために使用される、各下層シングルホップセッションの説明（例えば、マルチホップＥ２Ｅ Ｍ２Ｍサービス層セッションを構成する個々のシングルホップＭ２Ｍサービス層セッションに関する情報、下層トランスポートまたはアクセスネットワーク接続に関する情報等）であり得る。
セッション状態は、ルート情報を含み得る。セッションルート情報は、着信セッションメッセージをルーティングすべき次のホップのＥ２Ｅ Ｍ２Ｍサービス層セッションエンドポイントまたはセッションマネージャを説明し得る。以下は、セッション状態として記憶され得るルート情報の形態である：Ｍ２ＭアプリケーションまたはＭ２Ｍサービス層インスタンスのセッション識別子、シングルホップＭ２Ｍサービス層セッション識別子、アプリケーションプロトコル識別子（例えば、ユニフォームリソース識別子（ＵＲＩ）、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソース名（ＵＲＮ）等）、トランスポート層セッション識別子（ＴＬＳセッション識別子）、ネットワーク層アドレス（例えば、ＩＰアドレス）、アクセスネットワーク識別子（例えば、国際モバイル加入者識別（ＩＭＳＩ）、モバイル加入者統合サービスデジタルネットワーク番号（ＭＳＩＳＤＮ）、媒体アクセス制御（ＭＡＣ）アドレス等）、または利用可能な下層ネットワークインターフェース、アクセスネットワーク接続／ベアラ、トランスポート層接続等のリスト。
セッション状態は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションコンテキスト／履歴を含み得、それは、サービス層セッションを使用して行われた過去のサービス層トランザクションに関連するコンテキスト情報および／またはその履歴であり得る。例として、セッションエンドポイントによって標的にされたリソースのタイプ、数、レート、サイズ等を記録すること、またはアプリケーションが確立する異なるサービス層セッションを記録すること（例えば、レート、タイプ等）が挙げられる。
セッション状態は、Ｅ２Ｅ Ｍ２Ｍサービス層セッションマネージャまたはエンドポイントがＥ２Ｅ Ｍ２Ｍサービス層セッションメッセージを生成または処理する方法に関するルールを定義するセッションポリシも含み得る。例えば、ポリシは、サービス層ＱｏＳポリシルートポリシ、サービス層記憶および転送ポリシ、サービス層アクセス制御ポリシ等を含み得る。ポリシは、セッションマネージャがメッセージに関連付けられたデータを処理する方法を定義するためにも使用され得る（例えば、データが読み取り専用である場合、またはデータが他のデータと集約され得る場合等）。ポリシは、セッションマネージャのためのサービス層ルートルールを定義するためにも使用され得る（例えば、いくつかのセッションは、セッションマネージャが、請求、セキュリティ、追跡／検査等の機能を行うことができるように、規定されたセッションマネージャを通してルーティングされなければならない）。
セッションマネージャ、セッションエンドポイント、またはセッション証明書機能のうちの１つ以上のものは、開示されるセッション状態を維持することができる。セッション状態は、サービス層セッションの設定、管理、および切断のために使用され得る。セッション状態は、動的に作成され得る。例えば、セッション識別子は、メッセージと特定のサービス層セッションを相関させるために、各メッセージ内に含まれ得る。セッションエンドポイントまたはセッションマネージャは、それらが送信または受信するメッセージに基づいて、セッション状態を作成および記憶し、セッション識別子に基づいて、この状態をインデックス化し得る。例えば、サービス層セッションマネージャは、この状態を記憶し、それが行う将来の積極的または自律的サービス層決定（セッションルート決定、セッション記憶および転送決定、または以前の履歴、パターン、もしくは傾向に基づいたデータのプリフェッチング等の自律的サービス層アクション等）に組み込み得る。
セッションエンドポイントは、セッションマネージャとのサービス層セッションを維持するために、セッション状態を記憶し得る。セッション状態はまた、セッションマネージャおよび／またはエンドポイント間で共有され得る。このセッション状態は、セッションエンドポイント自体によって維持されるか、またはウェブクッキーと同様の様式において、セッションマネージャによって維持され得る。例えば、セッション状態は、エンドポイントがサービス層セッションを使用している間、セッションマネージャによって、セッションエンドポイント上で更新／維持され得る。そうすることによって、セッションマネージャは、セッションエンドポイント上にセッション状態をＭ２Ｍセッションクッキーとして記憶し得る。セッションエンドポイントが、将来、セッションを使用するとき、この記憶されたＭ２Ｍセッションクッキーは、セッションマネージャに送信されるか、または、それによって読み出され、エンドポイントの以前のアクティビティを知るためにセッションマネージャによって使用されることができる。Ｍ２Ｍセッションクッキーは、エンドポイントが過去に標的化した特定のリソース、リソースが目標にさせられたレート等のセッション状態を含むことができる。このＭ２Ｍセッションクッキーを使用して、セッションマネージャは、エンドポイントの以前のセッションアクティビティに基づいて、より効率的かつ積極的に、現在のセッショントランザクションを管理することができる。例えば、セッションマネージャは、アウェークであることを確実にするために、事前にデバイスを積極的にトリガすること、事前にアクセスネットワークリソースを積極的に確保すること、事前にサービス層内にキャッシュ／バッファされるように、事前に標的リソースのプリフェッチングを行うこと等を行うことができる。開示されるＭ２Ｍセッションクッキー概念は、シングルホップＭ２Ｍサービス層セッションならびにＥ２Ｅ Ｍ２Ｍサービス層セッションにも適用可能であり得ることに留意されたい。
図８は、セッションエンドポイント２６０のための機能的アーキテクチャを図示する。図８に示されるように、セッションエンドポイント２６０は、以下のうちの１つ以上のものを含み得る：Ｅ２Ｅ Ｍ２Ｍセッション証明書ブートストラッピング機能２６１、Ｅ２Ｅ Ｍ２Ｍセッションコンテキストおよび履歴機能２６２、Ｅ２Ｅ Ｍ２Ｍセッション確立および切断機能２６４、Ｅ２Ｅ Ｍ２Ｍセッションポリシ機能２６５、Ｅ２Ｅ Ｍ２Ｍセッション構成および発見機能２６６、Ｅ２Ｅ Ｍ２Ｍセッションデータ管理機能２６３、およびＥ２Ｅ Ｍ２Ｍセッション状態２６７。セッションエンドポイント２６０は、Ｅ２Ｅ Ｍ２Ｍサービス層セッション通信（サービス層セッション通信）のソースまたはシンクであり得る論理的エンティティと見なされ得る。一般に、セッションエンドポイント２６０は、図５に示されるサービス層セッションマネージャの同一機能の多くを有する。しかしながら、図８のセッションエンドポイント２６０の場合、これらの機能は、特に、サーモスタット等のリソース制約デバイス上に常駐するセッションエンドポイントのために、効率化され、より限定された機能性の組をサポートし得る。
図８を継続して参照すると、Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイント証明書ブートストラッピング機能２６１（セッションエンドポイント証明書ブートストラッピング機能）は、セッションマネージャへのＥ２Ｅ Ｍ２Ｍサービス層セッションブートストラップ要求を開始すること、およびセッション証明書を含む対応する応答を受信することをサポートする。この機能性は、１つ以上の標的セッションエンドポイントとのサービス層セッションを確立しようとしているサービス層セッションエンドポイントによって使用される。本開示される機能はまた、セッションエンドポイント２６０が別のエンドポイントによって開始されたセッションの標的であるとき、セッションマネージャからセッション証明書を含むブートストラップ構成要求を受信することをサポートする。
Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイント確立および切断機能２６４（セッションエンドポイント確立機能）は、セッションマネージャへのセッションエンドポイント確立要求の開始をサポートする。この機能はまた、セッションエンドポイント２６０がセッション確立または切断の標的であるとき、セッションマネージャからのセッション確立要求を受信することをサポートする。
Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイントコンテキストおよび履歴機能２６２（セッションエンドポイントコンテキスト機能）は、前述のように、セッションマネージャによってサポートされる対応する機能と同様に、Ｅ２Ｅ Ｍ２Ｍサービス層セッションコンテキストおよび履歴情報の収集、解釈、および処理をサポートする。ここでは、セッションエンドポイント２６０は、ルートおよびアクセスネットワークコネクティビティに関するコンテキストをサポートしないこともある。これらのタイプのコンテキストは、セッションマネージャにより好適であり得る。
図８のＥ２Ｅ Ｍ２Ｍサービス層セッションエンドポイントポリシ機能２６５（セッションエンドポイントポリシ機能）は、本明細書でセッションマネージャに関して説明されるように、セッションマネージャによってサポートされる対応する機能と同様に、Ｅ２Ｅ Ｍ２Ｍサービス層セッションポリシの読み出し、解釈、および処理をサポートする。ここでは、セッションエンドポイント２６０は、ルート、記憶および転送、プリフェッチング、およびアクセスネットワークコネクティビティに関するポリシをサポートしないこともある。これらのタイプのコンテキストは、セッションマネージャにより好適であり得る。Ｅ２Ｅ Ｍ２Ｍサービス層セッションエンドポイント構成および発見機能２６６（セッションエンドポイント構成）は、本明細書に説明されるように、セッションマネージャによってサポートされる対応する機能と同様に、サービス層セッション属性およびパラメータのための構成および発見能力をサポートする。Ｅ２Ｅ Ｍ２Ｍセッションエンドポイントデータ管理機能２６３（セッションエンドポイントデータ管理機能）は、セッションエンドポイント２６０によって処理される、Ｅ２Ｅ Ｍ２Ｍサービス層セッションメッセージ内に含まれるデータの管理をサポートする。特に、この機能は、セッション証明書を使用して、サービス層セッションデータの暗号化または復号化をサポートし得る。
本明細書に定義されるＥ２Ｅ Ｍ２Ｍサービス層セッションインターフェースメッセージは、伝送制御プロトコル（ＴＣＰ）および／またはトランスポート層セキュリティ（ＴＬＳ）セッション、ユーザデータグラムプロトコル（ＵＤＰ）／データグラムＴＬＳ（ＤＴＬＳ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、制約アプリケーションプロトコル（ＣｏＡＰ）等のいくつかの下層既存プロトコルの上に結合または層化（すなわち、その中にカプセル化）され得る。そうすることによって、セッション状態は、異なるセッション間で共有および利用されることができる（例えば、セキュリティ証明書、輻輳情報等）。加えて、サービス層セッションは、サービス層セッションが、持続し、より下層のセッションが設定および切断されることから独立して維持され得るように、より下層のセッションに関して、持続性をサポートすることができる。一例示的実施形態として、Ｅ２Ｅ Ｍ２Ｍサービス層セッション制御メッセージは、ＪＳＯＮまたはＸＭＬ表現としてエンコードされ、ＨＴＴＰまたはＣｏＡＰメッセージのペイロード内で搬送されることができる。次に、これらのＨＴＴＰおよびＣｏＡＰメッセージは、それぞれ、下層ＴＣＰ／ＴＬＳおよびＵＤＰ／ＤＴＬＳメッセージによってカプセル化および搬送されることができる。
以下の図９−図２４は、ｏｎｅＭ２Ｍおよび他のアーキテクチャに適用され得る、Ｅ２Ｅ Ｍ２Ｍサービス層セッションに関する詳細を提供する。追加のコンテキストのために、ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャに従って、能力サービス機能（ＣＳＦ）は、「リソース」の組として表される。リソースは、アーキテクチャ内の固有のアドレス可能エンティティである。リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作され、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス指定され得る表現を有する。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの有効期間は、親リソースの有効期間によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。
図９は、セッションマネージャのｏｎｅＭ２Ｍ実施形態を図示する。ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力の定義を有する。これらの能力は、ＣＳＦ２７０等の能力サービス機能（ＣＳＦ）と称され得る。ｏｎｅＭ２Ｍサービス層は、ＣＳＥ２７１等の能力サービスエンティティ（ＣＳＥ）と称される。ＣＳＥの現在のバージョンは、セッション管理（ＳＭＧ）ＣＳＦのためのプレースホルダを有する。しかしながら、この機能の詳細は、まだ定義されていない。ある実施形態では、セッションマネージャは、ｏｎｅＭ２Ｍ ＳＭＧ ＣＳＦ２７２としての役割を果たし得る。ＳＭＧ ＣＳＦ２７２は、Ｍ２Ｍアプリケーション間、Ｍ２ＭアプリケーションとＣＳＥとの間、またはＣＳＥ間のサービス層セッションを管理し得る。ＡＥは、参照点Ｘを介して、ＣＳＥに接続する一方、ＣＳＥは、参照点Ｙを介して、他のＣＳＥに接続する。
図１０Ａおよび図１０Ｂは、以下により詳細に定義される、リソースをサポートするｏｎｅＭ２Ｍセッション管理（ＳＭＧ）サービスのためのＥ２Ｅ Ｍ２Ｍサービス層セッション確立プロシージャを図示する。プロシージャは、以下であり得る（必ずしも、順番通り示されない）。図１０Ａに示されるように、ステップ３１０において、ＣＳＥ３０６およびＣＳＥ３０４は、互いに登録し、Ｅ２Ｅ Ｍ２Ｍサービスセッション管理（セッション管理またはＳＭＧ）能力を互いに交換する。ステップ３１１において、ＡＥ３０８およびＡＥ３０２は、それぞれ、ＣＳＥ３０６およびＣＳＥ３０４に登録し、Ｅ２Ｅ Ｍ２Ｍセッションベースの通信（すなわち、Ｅ２Ｅ Ｍ２Ｍサービス層セッション）をサポートすることをアドバタイズする。ｏｎｅＭ２Ｍは、アプリケーションエンティティ（ＡＥ）をＭ２Ｍアプリケーション機能をホストするネットワークノード（例えば、Ｍ２Ｍデバイス）として定義する。ステップ３１２において、ＡＥ３０２は、ＣＳＥ３０４上にホストされるセッション集合リソースにサブスクライブする。サブスクリプション要求内に含まれるのは、通知が送信され得るコールバックユニフォームリソース識別子（ＵＲＩ）であり得る。これは、Ｍ２Ｍサービスセッション確立要求がＣＳＥ３０４によって受信されたとき、通知を受信すべきＡＥ３０２のために行ない得る。これは、作成要求を介して行われ得る。
図１０Ａを継続して参照すると、ステップ３１３において、ＣＳＥ３０４は、ＡＥ３０２のためにセッションリソースに対するサブスクリプションを作成する。ステップ３１４において、ＣＳＥ３０４は、サブスクリプション作成要求への正の応答を返す。ステップ３１５において、ＡＥ３０８は、ＡＥ３０２およびＥ２Ｅ Ｍ２Ｍセッションベースの通信（すなわち、Ｅ２Ｅ Ｍ２Ｍサービス層セッション）をサポートするためのＡＥ３０２の能力を発見する。ステップ３１５は、ＣＳＥ３０６またはＣＳＥ３０４によってサービス提供されるリソース発見要求に基づき得る。発見結果は、ＡＥ３０８がＡＥ３０２とのＥ２Ｅ Ｍ２Ｍセッションを確立するために使用し得る、ＡＥ３０２のためのＭ２Ｍ識別子（例えば、アプリケーションＩＤ、ノードＩＤ等）等の情報を含み得る。ステップ３１６において、ＡＥ３０８は、ＡＥ３０２識別子情報ならびにセッションを確立するためにＳＭＧ ＣＳＦによって使用されるＡＥ３０８情報を含む、＜ｓｅｓｓｉｏｎ＞リソース作成要求をＣＳＥ３０６に送信することによって、ＡＥ３０２とＥ２Ｅ Ｍ２Ｍセッションを確立することを要求する。ステップ３１７において、ＣＳＥ３０６は、固有のＥ２Ｅセッション識別子およびセッション証明書を配分する。セッション識別子は、セッションを識別する一方、セッション証明書は、識別されたセッションを認証し、それに参加するための権限を与えるために使用される。ステップ３１８において、ＣＳＥ３０６は、ステップ３１６のセッション確立要求を次のホップ（この例では、ＣＳＥ３０４である）に転送する。セッション識別子およびセッション証明書は、この転送された要求内に含まれ得る。ステップ３１９において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、ＡＥ３０２を標的にするＭ２Ｍサービスセッション確立要求を受信および処理する。
図１０Ｂに継続されるように、ステップ３２０において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、Ｍ２Ｍサービスセッション確立要求の通知をＡＥ３０２に送信する。ＣＳＥ３０４は、とりわけ、セッション識別子および証明書、ならびに、ＡＥ３０８のＭ２Ｍ識別子等の通知内のＡＥ３０８セッション情報を含む。この情報は、ＣＳＥ３０４およびＣＳＥ３０６上のＳＭＧ ＣＳＦを介して、ＡＥ３０８へまたはそこからセッションベースのメッセージを送信または受信するために、ＡＥ３０２によって後に使用され得る。ステップ３２１において、ＡＥ３０２は、ＡＥ３０８とのＭ２Ｍサービスセッション（すなわち、前述のＥ２Ｅ Ｍ２Ｍサービス層セッション）に入ることに関心があり、その意向があることを示す正の応答を通知要求に対して返す。応答内に含まれるのは、ＡＥ３０２によって規定されたセッション確立情報（例えば、ＡＥ３０２のＭ２Ｍ識別子、セッションを介してアクセス可能にすることを欲するリソース等）であり得る。ステップ３２２において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、ＡＥ３０８およびＡＥ３０２の両方のために、セッション情報（例えば、ｓｅｓｓｉｏｎＩＤ、エンドポイント識別子等）を記憶する、Ｍ２Ｍサービス＜ｓｅｓｓｉｏｎ＞リソースおよび＜ｓｅｓｓｉｏｎＥｎｄｐｏｉｎｔ＞リソースを作成する。加えて、＜ｎｅｘｔＨｏｐ＞リソースも、ＣＳＥ３０６のために作成される。
図１０Ｂを継続して参照すると、ステップ３２３において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、Ｍ２Ｍサービスセッション確立作成要求への正の応答をＣＳＥ３０６上のＳＭＧ ＣＳＦに返す。ステップ３２４において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、ＡＥ３０８およびＡＥ３０２の両方のために、セッション情報（例えば、ｓｅｓｓｉｏｎＩＤ、エンドポイント識別子等）を記憶する、Ｍ２Ｍ＜ｓｅｓｓｉｏｎ＞リソースおよび＜ｓｅｓｓｉｏｎＥｎｄｐｏｉｎｔ＞リソースを作成する。加えて、＜ｎｅｘｔＨｏｐ＞リソースも、ＣＳＥ３０４のために作成される。ステップ３２５において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、ステップ３１６のＭ２Ｍサービスセッション確立作成要求への正の応答をＡＥ３０８に返す。応答は、とりわけ、ｓｅｓｓｉｏｎＩＤおよび証明書等のセッション情報を含み得る。ステップ３２６において、ＡＥ３０８は、セッションポリシを作成し、セッションのために要求する所望のレベルのＱｏＳをサポートするための要求をＣＳＥ３０６に送信する（例えば、ＱｏＳは、メッセージが記憶・転送式であるべきでないことであり得る）。ステップ３２７において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、要求を次のホップのＣＳＥ３０４上のＳＭＧ ＣＳＦに転送する。ステップ３２８において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースを作成する。ステップ３２９において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、正の応答をＣＳＥ３０６上のＳＭＧ ＣＳＦに返す。ステップ３３０において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースを作成する。ステップ３３１において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、正の応答をＡＥ３０８に返す。
図１１Ａおよび図１１Ｂは、以下により詳細に定義されるリソースをサポートするｏｎｅＭ２Ｍ ＳＭＧサービスのためのセッション使用プロシージャを図示する。ステップ３４０において、ＡＥ３０８は、ＣＳＥ３０４上にホストされるＡＥ３０２コンテナリソースを更新するためのサービスセッションベースの要求をＣＳＥ３０６に送信する。ステップ３４１において、ＣＳＥ３０６は、ステップ３４０の要求がサービスセッションベースであることを検出し、それをＳＭＧ ＣＳＦにパスし、処理する。ステップ３４２において、ｓｅｓｓｉｏｎＩＤに基づいて、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、受信されたＵＲＩが有効なセッションエンドポイント（ＡＥ３０２のコンテナ１リソース）を標的にすることを確認する。ステップ３４３において、標的セッションエンドポイント（すなわち、ＡＥ３０２）に基づいて、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、次のホップがＣＳＥ３０４であることを決定する。ステップ３４４において、ｓｅｓｓｉｏｎＩＤおよび標的セッションエンドポイント（すなわち、ＡＥ３０２）に基づいて、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、記憶・転送式スケジューリングポリシを定義するセッションポリシを見つける。ステップ３４５において、ポリシに基づいて、ＣＳＥ３０６は、オフピーク時間まで要求を記憶し、次いで、オフピーク時間中にそれをＣＳＥ３０４に転送する。ステップ３４６において、ＣＳＥ３０６は、要求をＣＳＥ３０４に転送する。ステップ３４７において、ＣＳＥ３０４は、要求がセッションベースであることを検出し、それをＳＭＧ ＣＳＦにパスし、処理する。ステップ３４８において、ｓｅｓｓｉｏｎＩＤに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、受信されたＵＲＩが有効なセッションエンドポイント（ＡＥ３０２のコンテナ１リソース）を標的にすることを確認する。ステップ３４９において、標的セッションエンドポイントに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、要求がローカルＡＥ３０２コンテナリソースを標的にすることを決定する。ステップ３５０において、ｓｅｓｓｉｏｎＩＤおよび標的セッションエンドポイントに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、即時応答を要求するセッションポリシを見つける。ステップ３５１において、ポリシに基づいて、ＣＳＥ３０４は、要求にサービス提供し、応答を返す。ステップ３５２において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、セッションコンテキストを作成し、セッション要求／応答履歴を記録する。
図１１Ｂに継続されるように、ステップ３５３において、ＣＳＥ３０４は、応答をＣＳＥ３０６に送信する。ステップ３５４において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、セッションコンテキストを作成し、セッション要求／応答履歴を記録する。ステップ３５５において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、応答をＡＥ３０８に送信する。ステップ３５６において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、コンテナが更新されたことのセッションエンドポイント（ＡＥ３０２）への通知を準備する。ステップ３５７において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、コンテナ１リソースがセッションの一部として更新されたことの通知をＡＥ３０２に送信する。ステップ３５８において、ＡＥ３０２は、通知を受信したことの正の応答で応答する。ステップ３５９において、ＡＥ３０２は、更新されたコンテナリソースを読み出すためのセッションベースの読み出し要求をＣＳＥ３０４に送信する。ステップ３６０において、ＣＳＥ３０４は、ステップ３５９の要求がセッションベースであることを検出し、それをＳＭＧ ＣＳＦに送信し、処理する。ステップ３６１において、ｓｅｓｓｉｏｎＩＤに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、ＵＲＩが有効なセッションエンドポイント（ＡＥ３０２のコンテナ１リソース）を標的にすることを確認する。ステップ３６２において、標的セッションエンドポイントに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、要求がローカルＡＥ３０２コンテナ１リソースを標的にすることを決定する。ステップ３６３において、ｓｅｓｓｉｏｎＩＤおよび標的セッションエンドポイントに基づいて、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、即時応答を要求するセッションポリシを見つける。ステップ３６４において、ポリシに基づいて、ＣＳＥは、要求にサービス提供し、即時応答を返す。ステップ３６５において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、セッションコンテキストを作成し、セッション要求または応答履歴を記録する。ステップ３６６において、ＣＳＥ３０４は、応答をＡＥ３０２に返す。
図１２は、以下に定義されるリソースをサポートするｏｎｅＭ２Ｍ ＳＭＧサービスのための例示的Ｅ２Ｅ Ｍ２Ｍセッション終了プロシージャを図示する。この例では、セッション終了は、セッションイニシエータ（ＡＥ３０８）によって呼び出される。図１２には図示されないが、セッション終了は、他のセッションエンドポイント、ＳＭＧ ＣＳＦ自体、およびそれを行うための適切な管理権利を有する他のＣＳＦによっても呼び出され得る。ステップ３７０において、ＡＥ３０８は、ＤＥＬＥＴＥを使用して、Ｅ２Ｅ Ｍ２Ｍセッション終了要求をＣＳＥ３０６に送信する。
ステップ３７１において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、要求を処理し、これらのＣＳＥ上のセッション状態が切断され得るように、セッション終了要求を転送する必要がある次のホップの他のＣＳＥ上のＳＭＧ ＣＳＦを決定する。この例では、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、検出される次のホップである。ステップ３７２において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、セッション終了要求をＣＳＥ３０４上のＳＭＧ ＣＳＦに転送する。ステップ３７３において、ＣＳＥ３０４上のＣＳＦは、セッションエンドポイント（すなわち、ＡＥ３０２）にセッションが終了されていることを通知する。ステップ３７４において、ＡＥ３０２は、通知を処理し、ローカルに記憶されたＭ２Ｍセッション状態を削除する。ステップ３７５において、ＡＥ３０２は、通知要求へのそのローカルＭ２Ｍセッション状態を除去したことを示す正の応答を返す。ステップ３７６において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、そのローカルにホストされた＜ｓｅｓｓｉｏｎ＞リソースおよび全ての子リソースを削除する。ＳＭＧ ＣＳＦはまた、セッションに配分されたセキュリティ証明書および識別子等の任意のローカルセッション状態を削除する。ステップ３７７において、ＣＳＥ３０４上のＳＭＧ ＣＳＦは、セッション終了ＤＥＬＥＴＥ要求への正の応答をＣＳＥ３０６上のＳＭＧ ＣＳＦに返す。ステップ３７８において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、そのローカルにホストされた＜ｓｅｓｓｉｏｎ＞リソースおよび全ての子リソースを削除する。ＳＭＧ ＣＳＦはまた、セッションに配分されたセキュリティ証明書および識別子等の任意のローカルセッション状態を削除する。ステップ３７９において、ＣＳＥ３０６上のＳＭＧ ＣＳＦは、Ｍ２Ｍサービスセッション終了ＤＥＬＥＴＥ要求への正の応答をＡＥ３０８に返す。ステップ３８０において、ＡＥ３０８は、記憶されたＭ２Ｍセッション状態を削除する。
図１０Ａ、図１０Ｂ、図１１Ａ、図１１Ｂ、および図１２に図示されるステップを行うエンティティは、図３７Ｃまたは図３７Ｄに図示されるもの等のネットワークノード、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理的エンティティであることを理解されたい。すなわち、図１０Ａ、図１０Ｂ、図１１Ａ、図１１Ｂ、および図１２に図示される方法は、ノードのプロセッサによって実行されると、図１０Ａ、図１０Ｂ、図１１Ａ、図１１Ｂ、および図１２に図示されるステップを行うコンピュータ実行可能命令である、図３７Ｃまたは図３７Ｄに図示されるノードまたはコンピュータシステム等のメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。
以下に開示されるのは、本明細書で論じられるプロシージャにおいて使用され得る、ＳＭＧ ＣＳＦのためのリソース構造（例えば、図１４）である。リソース図の理解を補助するために、リソース構造を説明するためのｏｎｅＭ２Ｍ定義グラフィカル表現は、以下である。１）正方形ボックスは、リソースおよび子リソースのために使用され得、２）丸角を伴う正方形ボックスは、属性のために使用され得、３）直角を伴わない平行四辺形（例えば、菱形）は、リソースの集合のために使用され得、４）各属性および子リソースの多重度が、定義され、５）「＜」および「＞」で区切られたリソース名は、リソースの作成中に割り当てられる名称を示す。
「セッション」リソースは、図１３に示されるように、１つ以上の＜ｓｅｓｓｉｏｎ＞リソースの集合を表すことができる。代替として、＜ｓｅｓｓｉｏｎ＞リソースは、独立して（すなわち、セッション集合リソース外で）インスタンス化されることができる。このセッションリソースは、ｏｎｅＭ２Ｍ ＣＳＥリソースツリー階層内の種々のレベルでインスタンス化されることができる。インスタンス化のレベルは、Ｍ２Ｍセッションのタイプを示すことができる。同様に、Ｍ２Ｍアプリケーション間またはＭ２ＭアプリケーションとＣＳＥとの間のＭ２Ｍセッションは、図１４に示されるように、アプリケーションリソース下でインスタンス化されることができる。例えば、複数のＣＳＥ間の、Ｍ２Ｍセッションは、図１５に示されるように、ＣＳＥのベースＵＲＩ下でインスタンス化され得る。セッションリソースは、表１におけるその多重度に従って、子リソースを含み得る。このリソースは、表２におけるその多重度に従って、属性を含むことができる。
＜ｓｅｓｓｉｏｎ＞リソースは、図１６に示されるように、特定のＭ２Ｍサービスセッションを管理するために、ＳＭＧ ＣＳＦによって使用される情報を含むことができる。このリソースは、表３におけるその多重度に従って、子リソースを含むことができる。このリソースは、表４におけるその多重度に従って、属性を含むことができる。
セッションエンドポイントリソースは、図１７に示されるように、＜ｓｅｓｓｉｏｎＥｎｄｐｏｉｎｔ＞リソースの集合を表すことができる。このリソースは、表５におけるその多重度に従って、子リソースを含むことができる。このリソースは、表６におけるその多重度に従って、属性を含むことができる。
＜ｓｅｓｓｉｏｎＥｎｄｐｏｉｎｔ＞リソースは、図１８に示されるように、特定のＭ２Ｍサービスセッションエンドポイントに適用可能である属性および子リソースを含むことができる。このリソースは、表７におけるその多重度に従って、子リソースを含むことができる。このリソースは、表８におけるその多重度に従って、属性を含むことができる。
ｎｅｘｔＨｏｐｓリソースは、図１９に示されるように、＜ｎｅｘｔＨｏｐ＞リソースの集合を表すことができる。このリソースは、表９におけるその多重度に従って、子リソースを含むことができる。このリソースは、表１０におけるその多重度に従って、属性を含むことができる。
＜ｎｅｘｔＨｏｐ＞リソースは、図２０に示されるように、Ｍ２Ｍセッションがセッションエンドポイント間の複数のＣＳＥホップから成るとき、ＳＭＧ ＣＳＦが特定のセッションエンドポイントのためのメッセージを転送する、次のホップＣＳＥに関する情報を含むことができる。このリソースは、所与のセッションおよび／またはセッションエンドポイントのために、セッションベースの要求が転送される次のホップＣＳＥの状態を維持するためにＳＭＧ ＣＳＦによって使用されることができる。この情報の維持は、複数のＣＳＥを横断して及ぶマルチホップＭ２Ｍセッションの切断、ならびに異なるＣＳＥ上にホストされたＳＭＧ ＣＳＦ間の協働のような動作のために有用であり得る。このリソースは、表１１におけるその多重度に従って、属性を含むことができる。
セッションポリシリソースは、図２１に示されるように、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースの集合を表すことができる。このリソースは、表１２におけるその多重度に従って、子リソースを含むことができる。このリソースは、表１３におけるその多重度に従って、属性を含むことができる。
＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースは、図２２に示されるように、特定のＭ２Ｍサービスセッションポリシに適用可能である属性を含むことができる。このリソースは、表１４におけるその多重度に従って、属性を含むことができる。
セッションコンテキストリソースは、図２３に示されるように、＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔＩｎｓｔａｎｃｅ＞リソースの集合を表すことができる。このリソースは、表１５におけるその多重度に従って、子リソースを含むことができる。このリソースは、表１６におけるその多重度に従って、属性を含むことができる。
＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔＩｎｓｔａｎｃｅ＞リソースは、図２４に示されるように、特定のタイプのＭ２Ｍサービスセッションコンテキストに適用可能である属性を含むことができる。このリソースは、表１７におけるその多重度に従って、属性を含むことができる。
（サービス層セッション移転および共有）
サービス層セッション移転および共有の必要性および利点を例証するために、２つの使用例が、本明細書に説明される。１つ目は、図２５に図示され、２つ目は、図２６に図示される。
図２５を参照すると、第１の使用例では、青果物（例えば、バナナ）を世界中に出荷するある企業を考える。その目的地に応じて、その企業の生産物の典型的旅程は、距離が著しく変動し得、それは、それが契約する飛行機、列車（例えば、列車４１０）、トラック（例えば、トラック４１４）、および船を含む異なる形態の輸送機関のいくつかの行程から成り得る。これらの行程の各々は、著しく異なる出荷時間を有し得る。加えて、その目的地に応じて、生産物は、配送センタ、倉庫（例えば、倉庫４０２および４０４）、トラックヤード等で何回か停止し得る。これらの理由から、適切に熟成した生産物がその最終目的地に到達することを確実にすることは、企業にとって非常に困難であり得る。
成長および収穫された畑からそれが購入され得るスーパーマーケットまで、生産物の品質および鮮度を確実にするために、企業は、Ｍ２Ｍセンサ技術を使用して、輸送の間の生産物の熟成ならびに環境条件を監視し得る。例えば、センサ４１２ａ、４１２ｂ、４１２ｃ、および４１２ｄ等のＭ２Ｍセンサが、企業が出荷する生産物の各ボックス内に提供され得る。各Ｍ２Ｍセンサ上にホストされるのは、ボックス内に含まれる生産物の周期的測定を行うアプリケーションであり得る。例えば、バナナの場合、ボックス内のバナナが経時的に放出するエチレンガスの量を測定することによって、Ｍ２Ｍセンサは、バナナが熟成プロセスのどの段階にあるかを予測することを支援するために使用され得る。これは、バナナが熟成するにつれて、そのエチレンガス放出レベルを増加させるからである。加えて、ボックス内の温度も、バナナの熟成が、その温度を低下させることによって減速され、逆に、その温度を上昇させることによって加速され得るので、注意深く監視され得る。
生産物のボックスが、例えば、第１の倉庫４０２から第２の倉庫４０４へその目的地に進むにつれて、企業は、そのルートに沿った停車地から停車地に進行するにつれて、配送ルート（例えば、倉庫、配送センタ、トラックヤード等）に沿ってインストールされたＭ２Ｍゲートウェイ（例えば、Ｍ２Ｍゲートウェイ４０７および４０９）のネットワークと通信するＭ２Ｍサーバ４００から成るＭ２Ｍサービス層プラットフォームを使用して、生産物の各ボックスから測定値を収集し得る。生産物のボックスがそのルートに沿った新しい場所に到達すると、ボックス内のＭ２Ｍセンサ（例えば、センサ４１２ａ−ｄ）は、その新しい場所において、サービス層セッションをＭ２Ｍゲートウェイ（例えば、Ｍ２Ｍゲートウェイ４０７または４０９）と確立し得る。
Ｍ２Ｍゲートウェイ内のＭ２Ｍゲートウェイサービス層インスタンスは、生産物の所与のボックス、原産地、その進行履歴、ならびにそのルートに沿った前の停車地においてＭ２Ｍゲートウェイサービス層インスタンスによって収集された測定値を自動的に識別し得る。これは全て、サービス層セッションコンテキストおよび構成情報が、Ｍ２Ｍセンサのルートに沿ったＭ２Ｍゲートウェイサービス層インスタンス間で移転および共有されることを可能にする（Ｍ２Ｍサーバから補助を受けて）、Ｍ２Ｍサービス層プラットフォームによってサポートされるセッション移転特徴（以下でさらに説明される）によって促進され得る。例えば、第１の倉庫４０２においてセンサ４１２ａ−ｄ上のＭ２ＭアプリケーションとＭ２Ｍゲートウェイ４０７上のＭ２Ｍサービス層インスタンスとの間に確立される、サービス層セッションのためのサービス層セッションコンテキスト４０６は、図２５における線４１８によって表されるように、第２の倉庫４０４において、Ｍ２Ｍゲートウェイ４０９上のＭ２Ｍサービス層インスタンスに移転させられ得る（Ｍ２Ｍサーバ４００の補助を受けて）。移転させられたサービス層セッションコンテキストは、Ｍ２Ｍゲートウェイ４０７から、Ｍ２Ｍサーバ４００に、およびそこからＭ２Ｍゲートウェイ４０９に伝送されるにつれて、４０６、４０６’、および４０６’’で示される。そうすることによって、このセッション移転特徴は、生産物の各ボックス内の各Ｍ２Ｍセンサ上で起動するＭ２Ｍアプリケーションを、新しいＭ２Ｍサービス層セッションをそのルートに沿った各Ｍ２Ｍゲートウェイサービス層インスタンスと確立する必要から救う。代わりに、移転させられたセッションコンテキストは、既存のセッションを再確立するために使用され得、それは、Ｍ２Ｍセンサを、セッションを最初から構成する必要から救う。加えて、ルートに沿った各Ｍ２Ｍゲートウェイサービス層インスタンスによって収集されるサービス層セッションコンテキストは、よりセキュアかつ効率的に、ルートに沿った他のＭ２Ｍゲートウェイサービス層インスタンスと共有され得る。これは、Ｍ２Ｍセンサが新しい場所に移動し、新しいＭ２Ｍゲートウェイサービス層インスタンスに登録されたことを検出すると、サービスプラットフォームによって自動的に行われ、コンテキストをＭ２Ｍゲートウェイサービス層インスタンス間で移転させ得る。これは、ローカルアプリケーションが、新しいＭ２Ｍゲートウェイサービス層インスタンス（例えば、企業の管理アプリケーションのインスタンス（図示せず））に接続され、この情報をより効率的かつ容易に発見し、それにアクセスすることを可能にし得る。例として、このセッション移転機能性を活用して、生産物の各ボックスの熟成率が、より効率的かつ正確に追跡され得、ひいては、企業は、より情報に基づいた出荷決定を行い得る。
図２６は、別の例示的使用例を図示する。この使用例では、軽度の認知症に悩まされ、かつタイプＢ型糖尿病でもあり得る人物４２３を考える。人物は、家４２７に一人暮らしであり得、家族および介護提供者からの何らかの遠隔補助を要求し得る。人物に適切な介護を提供するために、家４２７は、種々のセンサ（例えば、ベッドマットレス、床、浴室、台所等用のセンサ）を装備し、家内のその人物の場所ならびに人物の活動レベルを追跡している。加えて、人物は、人物の血糖値を監視するために装着されるスマート血糖値測定器デバイス４２２を装備し得る。この例では、センサ（例えば、センサ４２２）は、読み取り値を人物の医療介護提供者によって管理されるＭ２Ｍ対応ウェブサービスプラットフォームに定期的に報告するように構成され得る。このＭ２Ｍサービス層プラットフォームは、人物の家族および介護提供者が、家内のセンサによって提供される情報を使用して人物を遠隔で監視することを可能にするサービスを提供し得る。
Ｍ２Ｍサービス層プラットフォームは、人物の家族の一員および介護提供者の各々が、Ｍ２Ｍサービス層プラットフォームを介して、人物の家内のセンサとセキュアな通信セッションを確立し、そのウェブ対応デバイス（例えば、スマートフォン、タブレット、ラップトップ等）のうちの１つ上にホストされる遠隔アプリを使用して、人物の活動を監視することを可能にし得る。プラットフォームは、人物のセンサと人物の家族の一員および介護提供者デバイス上にホストされるアプリの各々との間のセキュアな通信を協調させ得る。サービス層プラットフォームを介して、各家族の一員および介護提供者は、家内の場所等の人物についてのリアルタイム情報にアクセス可能であり得る。加えて、彼らは、センサによって収集され、例えば、その日に家全体を通して追跡された移動、人物が浴室を訪れたかどうか、人物が冷蔵庫を空けたか、もしくはコンロを点けたかどうか、または過去１２時間にわたる血糖値測定器読み取り値の収集等、Ｍ２Ｍサービス層プラットフォーム内に記憶される情報にアクセスすることもできる。Ｍ２Ｍサービス層プラットフォームはまた、人物の家族の一員が、サブスクライブし、コンロがある時間にわたって放置されたとき、または血糖値測定器読み取り値がある閾値を超えたとき等の特定のイベントの発生に基づいて、アラートを受信することを可能にすることも可能であり得る。
依然として、家族の一員が自身の自由時間の一部を享受しながら、人物の家族の一員および介護提供者が、互いにより良好に協調することを可能にし、人物が常時適正に監視されていることを確実にするために、サービスプラットフォームは、ある追加の特徴をサポートし得る。そのような特徴の１つは、家族の一員および介護提供者が、人物の介護をスケジュールされたシフトに分割することを可能にするためのサービス層プラットフォームの能力である。各シフトの開始／終了時、サービス層は、人物の監視をある家族の一員または介護提供者から別の者にシームレスに切り替えることをサポートし得る。これは、サービス層プラットフォームが、家内のセンサに接続するサービス層セッションをある指定された家族の一員または介護提供者から別の者に動的に移転させることができるによって達成され得る。
例えば、図２６を参照すると、血糖値測定器等の遠隔監視デバイス４２２上で起動するＭ２Ｍアプリケーションは、サービス層セッションを人物の家族の一員のうちの１つのスマートフォン４２８上で起動するｅＨｅａｌｔｈアプリケーションと確立し得、セッションは、示されるように、Ｍ２Ｍゲートウェイ４２０およびＭ２Ｍサーバ４２１上のサービス層インスタンスによって促進され得る。Ｍ２Ｍゲートウェイ４２０は、セッションに関連するサービス層セッションコンテキスト４２４を記憶し得、Ｍ２Ｍサーバ４２６およびスマートフォン４２８上で起動するサービス層インスタンスも、それぞれ、４２６および４３０において、セッションに関連するコンテキストを記憶し得る。所定のまたはスケジュールされた時間に、サービス層プラットフォームは、監視デバイス４２２とスマートフォン４２８を接続するサービス層セッションのそのスマートフォン４２８からｅＨｅａｌｔｈアプリケーションのそれ自身のインスタンスを起動する別の家族の一員または介護提供者のラップトップ４３０への移転を促進し得る。この移転は、破線４３６によって図示される。示されるように、移転させられたサービス層セッションコンテキスト４３０’は、ラップトップ４３２において、既存のセッションを再確立し、他の家族の一員または介護提供者が、人物の監視を引き継ぐことを可能にするために使用され得る。この移転を行うと、サービス層は、各シフトの開始／終了時に、指定された家族の一員または介護提供者が、そのデバイスを人物のセンサに接続するセキュアなサービス層セッションを介して、これらのアラートを受信するように構成されるように、人物のアラートが送信されるコンタクト情報を自動的に更新し得る。
サービスプラットフォームがサポートし得る別の特徴は、人物の家族の一員および介護提供者が、そのデバイスを人物のセンサに接続するそのサービス層セッションを同一家族の一員または介護提供者によって所有される別の指定されるデバイスにシームレスに移転させることを可能にするための能力である。例えば、その家族の一員または介護者のシフト中、彼らは、アラートを受信するために、その電話の使用をそのタブレットまたはＰＣの使用に移行したい場合、彼らは、オンザフライで切り替わることができ、サービス層は、アラートのいずれも喪失されず、センサによって収集された任意の過去のコンテキストも、新しいデバイスからも同様にセキュアかつ完全にアクセス可能であるように、サービス層セッションが移転させられることを確実にするであろう。
図２５および２６に図示される実施例のもの等の使用例をサポートするために、本明細書に以下で開示されるのは、既存のＭ２Ｍサービス層セッションの移転または１つ以上の将来のセッションパーティシパントとの共有のための方法である。本明細書で使用される場合、用語「サービス層セッション」およびその変形例は、Ｍ２Ｍサービス層セッションパーティシパント間の情報のステートフルおよび半恒久的交換を意味する。用語「Ｍ２Ｍサービス層セッションパーティシパント」およびその変形例は、特定のＭ２Ｍサービス層セッションに参加するＭ２Ｍサービス層インスタンスまたはＭ２Ｍアプリケーションインスタンスを指す。さらに、本明細書で使用される場合、用語「Ｍ２Ｍサービス層セッションコンテキスト」およびその変形例は、１つ以上のＭ２Ｍサービス層セッションパーティシパントによって維持されるＭ２Ｍサービス層セッションに関連する情報を意味する。さらに、本明細書で使用される場合、用語「Ｍ２Ｍサービス層セッション移転」、「サービス層セッション移転」、「セッション移転」、「移転」等は、Ｍ２Ｍサービス層セッションパーティシパント間のＭ２Ｍサービス層セッションコンテキストの転送行行為を意味する。本明細書で使用される場合、用語「Ｍ２Ｍサービス層セッション共有」、「サービス層セッション共有」、「セッション共有」、「共有」等は、Ｍ２Ｍサービス層セッションパーティシパント間でＭ２Ｍサービス層セッションコンテキストを複製し、パーティシパントが同じ単一セッションを共有し得るように、これらの複製されたバージョンの互いに同期させられたセッションコンテキストを保つ行為を意味する。「Ｍ２Ｍアプリケーション」は、特定のＭ２Ｍ使用例（例えば、ｅＨｅａｌｔｈ、スマートエネルギー、ホームオートメーション等）を標的にするアプリケーションを指す。
開示される方法は、サービス層セッションが確立されているかどうか、およびセッション移転または共有機能性を可能にされているかどうかを決定することと、セッションパーティシパント（既存のまたは将来の）がセッション移転および共有サービスを構成し、このサービスを明示的にトリガし、サービス層セッション移転または共有を開始することを可能にすることと、セッション移転および共有サービスが、セッション移転／共有スケジュールおよび／またはポリシに基づいて、サービス層セッション移転または共有の開始を自律的にトリガすることを可能にすることと、サービス層セッションを移転または共有するために使用されることが可能なサービス層セッションコンテキストを収集および維持することと、セッション移転または共有を行うとき、標的化されるであろう将来のセッションパーティシパントを決定することと、将来のセッションパーティシパントがサービス層セッションをサポート可能であるかどうかを決定することと、既存のセッションパーティシパントがそのサービス層セッションの移転または共有に関心がある／それを所望するかどうかを決定することと、サービス層セッションコンテキストを既存のセッションパーティシパントから将来のセッションパーティシパントに転送することによって、サービス層セッションを移転させることと、既存のセッションパーティシパントからのサービス層セッションコンテキストを将来のセッションパーティシパントに利用可能にすることによって、サービス層セッションを共有することと、サービス層セッション移転および共有情報を下層アクセスネットワークと共有することによって、サービス層セッションの移転および共有を下層アクセスネットワーク接続と連携することとを含む。
方法は、Ｍ２Ｍサービス層セッションの移転または共有を行うために使用され得るセッション移転および共有機能（ＳＭＳＦ）によって行われ、および／またはその形態で実装され得る。Ｍ２Ｍサービス層セッションの移転または共有を可能にするために使用され得る種々の形態のサービス層セッションコンテキストも、説明される。加えて、ＳＭＳＦのｏｎｅＭ２Ｍ実施形態も、開示される。
図２７は、Ｍ２Ｍサービス層セッション移転の一実施例を示す。この例では、Ｍ２Ｍサービス層セッションがＭ２Ｍデバイス４４２（例えば、センサ）のＭ２Ｍアプリケーション４４０と第１のＭ２Ｍゲートウェイ４４４（Ｍ２ＭＧＷ＃１）のサービス層インスタンス４４６との間に確立されている。示されるように、Ｍ２Ｍゲートウェイ４４４のサービス層インスタンス４４８は、セッションに関連するサービス層セッションコンテキスト情報４４８を維持するであろう。しかしながら、ステップ１では、Ｍ２Ｍデバイス４４２は、移動し、第２のＭ２Ｍゲートウェイ４５４（Ｍ２ＭＧＷ＃２）に登録すると仮定する。Ｍ２Ｍアプリケーション４４０は、新しいＭ２Ｍゲートウェイ４５４とのサービス層セッションの再確立をトリガし得る。その結果、セッションは、第１のＭ２Ｍゲートウェイ４４４上にホストされるサービス層インスタンス４４６から、Ｍ２Ｍサーバ４５０上にホストされるサービス層インスタンス４５２に、次いで、第２のＭ２Ｍゲートウェイ４５４上にホストされるサービス層インスタンス４５６に移転させられ得る。移転が完了すると、サービス層セッションコンテキスト４４８は、第１のＭ２Ｍゲートウェイ４４４でもＭ２Ｍサーバ４５０でもなく、第２のＭ２Ｍゲートウェイ４５４上に常駐する。代替として、セッションコンテキストは、Ｍ２Ｍサーバ４５０上に保たれ、他の潜在的セッションパーティシパントからの将来的移転要求を支援し得る。他の潜在的Ｍ２Ｍサービス層セッション移転実施形態のいくつかの実施例（図２７には図示せず）は、直接、Ｍ２Ｍゲートウェイ上にホストされるサービス層インスタンス間ならびにＭ２Ｍサーバ上にホストされるサービス層インスタンス間およびＭ２Ｍデバイス上にホストされるサービス層インスタンス間におけるサービス層セッションの移転を含む。加えて、サービス層セッション移転はまた、Ｍ２Ｍアプリケーションインスタンス間のセッションコンテキストの移転も同様に伴い得る。
図２８は、Ｍ２Ｍサービス層セッション共有の一実施例を示す。この例では、Ｍ２Ｍサーバ＃１およびＭ２Ｍサーバ＃２上にホストされるサービス層インスタンスは、それら自身の間でサービス層セッションコンテキストを複製し、Ｍ２Ｍウェブアプリケーション＃１および＃２の両方が、単一サービス層セッションをＭ２Ｍデバイス上にホストされるＭ２Ｍアプリケーションと共有することを可能にする。そうすることによって、両方とも、協調および同期された方式において、デバイスのアプリケーションとセキュアに通信する（例えば、そのセンサ読み取り値にアクセスする、および／またはデバイスを制御する）ことができる。そのような共有は、Ｍ２Ｍアプリケーションが互いの間に大きな分離の程度（例えば、地理的におよび／またはネットワークホップ数に関して）を有するサービス層セッションを伴うシナリオに非常に好適であり得る。これらの場合、サービス層インスタンスに各アプリケーションの近くに位置させることは、アプリケーションに距離が離れて位置するサービス層インスタンスと通信させるよりも有益であり得る。このタイプの共有は、負荷分散等の目的のために、Ｍ２Ｍアプリケーションが、複数のサービス層インスタンスにわたって分散されるシナリオにも非常に好適であり得る。これらのシナリオでは、サービス層セッションをサービス層インスタンスにわたって共有することは、アプリケーションが、互いに同一セッションにより効率的に参加することを可能にすることができる。なぜなら、サービス層が、アプリケーションのためのサービス層セッションコンテキストを管理し、それを同期させ、それらが遠隔サービス層インスタンスと通信する必要なく、そのローカルサービス層インスタンスと通信することを可能にできるからである。他の潜在的Ｍ２Ｍサービス層セッション共有実施形態のいくつかの例（図２８には図示せず）は、Ｍ２Ｍゲートウェイおよび／またはＭ２Ｍデバイス上にホストされるサービス層インスタンス間の共有サービス層セッションを含む。加えて、サービス層セッション共有は、Ｍ２Ｍアプリケーションインスタンス間のセッションコンテキストの共有も同様に伴うこともできる。
サービス層セッション移転および共有を可能にするために、限定ではないが、以下のタイプの機能性をサポートするセッション移転および共有機能（ＳＭＳＦ）が、提供され得る：（ｉ）Ｍ２Ｍサービス層セッション移転または共有が行われるべきとき、トリガを生成するか、またはトリガを承認すること、（ｉｉ）トリガを評価し、Ｍ２Ｍサービス層セッション移転または共有を開始すべきかどうか／すべきときと、移転または共有を行うための適用可能セッションパーティシパントとを決定すること、（ｉｉｉ）セッションコンテキストをセッションパーティシパント間で転送することによって、サービス層セッション移転を行うこと、および（ｉｖ）セッションコンテキストをセッションパーティシパント間で複製し、コンテキストの複製されたコピーを互いに最新に保つことによって、サービス層セッション共有を行うこと。一実施形態では、このＳＭＳＦ機能は、図２９に示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内にホストされ得る。例えば、ＳＭＳＦは、Ｍ２Ｍサービス層インスタンス内の個々のサービス能力、または既存のサービス能力内のサブ機能としての個々のサービス能力を備え得る。
Ｍ２Ｍサービス層セッションの移転または共有を促進するために限定ではないが、表１８に定義されるような以下のタイプのコンテキスト（すなわち、情報）のうちの１つ以上のものを含むサービス層セッション移転および共有コンテキストが、採用され得る。このタイプのコンテキストは、サービス層セッション移転または共有を行うべきかどうか、それを行うべきとき、それを行うべきセッションの決定（すなわち、トリガ決定）を行うために、ＳＭＳＦによって使用されることができる。
加えて、第２のタイプのサービス層セッションコンテキストも、採用され得る。このタイプのコンテキストは、セッションパーティシパント（例えば、サービス層インスタンス）によって構成され、収集され、メモリ内に記憶され、および／または維持され得る。次に、このセッションコンテキストは、ＳＭＳＦを介して、セッションパーティシパント間で移転または共有され得る。このように、サービス層セッションの移転または共有は、調整および達成されることができる。この第２のタイプのコンテキストのいくつかの例は、限定ではないが、以下の表１９に定義されたコンテキストを含む。表１９にリスト化されたサービス層セッションコンテキストは、個々のセッションパーティシパントに特定であり得るか、または所与のサービス層セッションの全パーティシパントに適用可能であることができることに留意されたい。
図３０は、既存のＭ２Ｍサービス層セッションの移転または１つ以上の将来のセッションパーティシパントとの共有のための方法の一実施形態を図示する。一実施形態では、方法は、例えば、図２７に示されるように、Ｍ２Ｍアプリケーションインスタンスによって使用され、Ｍ２Ｍアプリケーションインスタンスは、それ自身と規定されたサービス層インスタンスとの間に存在するサービス層がＳＭＳＦによって別のサービス層インスタンスに移転させられることを要求し得る。第２の実施形態では、方法は、例えば、図２８に示されるように、既存のサービス層セッションがＳＭＳＦによって別のサービス層インスタンスおよびそれに登録されるＭ２Ｍアプリケーションのうちの１つ以上のものと共有されることを要求するために、Ｍ２ＭアプリケーションインスタンスまたはＭ２Ｍサービス層インスタンスのいずれかによって使用され得る。第３の実施形態では、方法は、Ｍ２Ｍアプリケーションインスタンスによって使用され、Ｍ２Ｍアプリケーションインスタンスは、ＳＭＳＦが別のＭ２Ｍアプリケーションインスタンスに関連付けられた既存のＭ２Ｍサービス層セッションをそれと共有することを要求し得る。第４の実施形態では、方法は、Ｍ２Ｍサービス層インスタンスによって使用され、Ｍ２Ｍサービス層インスタンスは、ＳＭＳＦがＭ２Ｍアプリケーションインスタンスと別のＭ２Ｍサービス層インスタンスとの間に存在する既存のＭ２Ｍサービス層セッションをそれに移転させることを要求し得る。
図３０を参照すると、ステップ１において、Ｍ２Ｍサービス層セッションが、２つ以上のセッションパーティシパント間に確立される。例えば、Ｍ２Ｍサービス層セッションが、図１−２４に図示され、前述の例示的機構に従って確立され得る。
ステップ２において、確立されているセッションがセッション移転または共有機能性を可能にされているかどうかを決定するためのチェックが、行われ得る。一実施形態では、このチェックは、Ｍ２Ｍサービス層セッションの確立に責任があるＭ２Ｍサービス層内の機能によって行われ得る。このチェックの結果が、セッション移転または共有が可能にされていることを決定する場合、ステップ３への移行が生じ得、そうでなければ、セッション移転または共有のためのさらなる処理は、このサービス層セッションのために行われない。
ステップ３は、セッション確立方法の拡張である。このステップでは、サービス層セッション確立中、ＳＭＳＦ（前述のように、Ｍ２Ｍサービス層内のサービスとして機能し、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードのサービス層インスタンス内に常駐し得る）は、限定ではないが、以下のうちの１つ以上のものを含み得る情報で構成され得る。
１．セッション移転または共有スケジュール−このスケジュールは、ＳＭＳＦがセッション移転または共有を行うべきときの設定時間等の情報を規定し得る。スケジュールは、ＳＭＳＦが規定されたスケジュール時間においてセッション移転または共有を行うときに標的にすべきセッションパーティシパントのリストも含み得る。
２．セッション移転または共有ポリシ−これらのポリシは、セッション移転または共有を行うときにＳＭＳＦによって使用されるルールを規定し得る。ポリシは、移転、またはあるセッションパーティシパントと共有されることが可能なセッションコンテキストのタイプ、互いに通信することが許可されるセッションパーティシパント、およびＳＭＳＦが自律的に行うことをトリガする具体的条件等のルールを規定し得る。
３．下層アクセスネットワーク／トランスポート層セッション情報−これは、サービス層セッションがその上に層化されることが可能な１つ以上の下層アクセスネットワーク／トランスポート層セッションに関するセッション識別子、ポリシ、コンテキスト、および証明書等の情報を含み得る。ＳＭＳＦは、この情報を使用して、サービス層セッション共有および移転を調整し得る。例えば、サービス層セッションを移転または共有するとき、ＳＭＳＦは、下層アクセスネットワークノードと連携し、対応する下層セッションも同様に移転または共有し得る。そうすることによって、ＳＭＳＦは、サービス層セッション移転および共有だけではなく、下層アクセスネットワークセッション移転および共有も互いに連動して調整し得る。この構成は、ＳＭＳＦの静的もしくは帯域外事前プロビジョニング（例えば、ＳＭＳＦが展開されるときに構成される）を介して、またはＳＭＳＦの動的構成（例えば、ネットワーク内の管理エンティティによって）を介して、行われることができることに留意されたい。
ステップ４において、ＳＭＳＦは、上記の表１８または表１９に説明されるコンテキスト等のサービス層セッションコンテキストを収集および維持し得る。ＳＭＳＦは、限定ではないが、以下のうちの１つ以上のものを含み得る方法を使用して、サービス層セッションコンテキストを収集および維持し得る。
１．Ｍ２Ｍサービス層セッションパーティシパントは、ＳＭＳＦサポートインターフェースを介して、セッションコンテキストをＳＭＳＦに明示的にパスし得る。例えば、ＲｏＡ実施形態では、ＳＭＳＦは、セッションパーティシパントがＣＲＵＤ動作を行い得るセッションコンテキストリソースをサポートすることができる。ＳｏＡ実施形態では、ＳＭＳＦは、セッションコンテキスト内でパスするためにセッションパーティシパントによってコールされることができるセッションコンテキスト機能をサポートすることができる。
２．ＳＭＳＦは、サービス層セッションコンテキストをＭ２Ｍサービス層セッションパーティシパントから先を見越して収集するための機構をサポートし得る。例えば、一実施形態では、ＳＭＳＦは、サービス層インスタンスにクエリし、セッション関連コンテキストをサービス層によってサポートされる個々のサービス能力から収集し得る（例えば、表１８または１９に定義されるもの等のセッションコンテキストを収集する）。
ステップ５において、ＳＭＳＦは、それがＭ２Ｍサービス層セッション移転または共有を行う必要があるトリガ条件を検出し得る。このトリガ条件は、自律的に生成されるか、または既存のもしくは将来のサービス層セッションパーティシパントからの明示的要求の受信の結果であるかのいずれかであり得る。ＳＭＳＦは、限定ではないが、以下のうちの１つ以上のものを含み得る方法を使用して、サービス層セッション移転または共有トリガを検出し得る。
１．ＳＭＳＦは、それが１つ以上の既存のセッションパーティシパントから１つ以上の将来のセッションパーティシパントへの特定のＭ２Ｍサービス層セッションの移転または共有をトリガする必要があることを自律的に決定し得る。この決定は、限定ではないが、以下のうちの１つ以上のものを含み得る条件に基づき得る。
ａ．ＳＭＳＦは、セッション移転または共有を調整するために、スケジュールを使用し得る。この提案されるスケジュールは、上記ステップ１に説明される。
ｂ．ＳＭＳＦは、サービス層セッションポリシ（ステップ１参照）およびコンテキスト（ステップ２参照）の組み合わせを使用して、セッション移転または共有が要求されるかどうか／そのときを決定し得る。
２．代替として、既存のＭ２Ｍサービス層セッションパーティシパントは、それがそのＭ２Ｍサービス層セッションを移転させるか、または１つ以上の他の将来のセッションパーティシパントと共有する必要があることを決定し得、その結果、それが明示的トリガをＳＭＳＦに生成し得る。この決定は、限定ではないが、以下のうちの１つ以上のものを含み得る条件に基づくことができる。
ａ．セッションパーティシパントは、それ自身もしくは他の既存のセッションパーティシパントのうちの１つのいずれかが場所を変更したこと、または場所の変更を計画中であることを検出し得る。場所は、限定ではないが、絶対場所（例えば、地理的場所）または相対的場所（例えば、ネットワークドメイン）の観点からであることができる。
ｂ．セッションパーティシパントは、サービス層セッションに参加する意思を有し得るその近傍における新しい候補セッションパーティシパント（すなわち、他のＭ２Ｍサービス層インスタンスまたはアプリケーションインスタンス）の存在を検出し得る。
ｃ．セッションパーティシパントは、現在通信中のセッションパーティシパントより好適な候補セッションパーティシパントの存在を検出し得る。例えば、セッションパーティシパントは、それ自身または他の既存のセッションパーティシパントのうちの１つのいずれかが別のサービス層インスタンスに登録しており、この新しいサービス層インスタンスが、優れたセッションパートナーとしての役割を果たし得ることを検出することができる（例えば、新しいサービス層インスタンスが、より近いか、もしくはより多くのセッションベースの特徴をサポートするか、または新しいサービス層インスタンスが、セッションパーティシパントが通信することに関心がある、それに登録されたアプリケーションを有する等）。
ｄ．セッションパーティシパントは、それ自身または他の既存のセッションパーティシパントのうちの１つのいずれかが、オーバーロードされており、もはや事実上セッションに参加可能ではないことを検出し得る。
ｅ．セッションパーティシパントは、他の既存のセッションパーティシパントのうちの１つがもはや利用可能ではないことを検出することができる（例えば、ネットワークを離れた、コネクティビティを喪失した、スリープになった等）。
ｆ．セッションパーティシパントは、近い将来に利用不可能になることを検出することができる（例えば、オフラインになる、またはスリープになる等）。
３．代替として、将来のＭ２Ｍサービス層セッションパーティシパントは、Ｍ２Ｍサービス層セッションを移転してもらいたい、またはそれと共有したいことを決定し得、その結果、ＳＭＳＦをトリガし、この移転／共有を行うことができる。この決定は、将来のセッションパーティシパントが、ＳＭＳＦにクエリし、それらのサービス層セッションを移転またはそれと共有する意思を有し得るその近傍におけるサービス層セッションの存在を検出することによって行われ得る。加えて、ＳＭＳＦは、将来のパーティシパントが、それが関心があるセッション、または適合性のあるセッションを決定できるように、各セッションの記述も提供し得る。この情報に基づいて、将来のセッションパーティシパントは、ＳＭＳＦが規定されたサービス層セッションの移転または将来のパーティシパントとの共有を開始することを要求することができる。
ステップ６において、ＳＭＳＦは、それがセッション移転または共有を行うときに標的とするであろうセッションパーティシパントを決定する。これは、ＳＭＳＦが移転／共有を開始するための明示的要求にサービスを提供する場合のために明示的に定義されるか、または、それがＳＭＳＦによって自律的に導出されるか（例えば、スケジュール、ポリシ情報、またはセッションパーティシパントに関する情報に基づいて）のいずれかであり得る。例えば、一実施形態では、既存のセッションパーティシパント（例えば、Ｍ２Ｍアプリケーション）は、移動を計画中の新しい場所を提供し得、この場所情報を使用して、ＳＭＳＦは、アプリケーションのサービス層セッションを移転させることができる利用可能かつ適合性のあるサービス層インスタンスを見つけ得る。
第２の実施形態では、既存のセッションに加わり、それを共有することを求める、将来のセッションパーティシパントは、それが加わり、共有することを求めるセッションの記述を提供し得る。このセッション記述を使用して、ＳＭＳＦは、この記述に一致する利用可能なセッションを見つけ得、次いで、ＳＭＳＦは、それを将来のセッションパーティシパントと共有し得る。
第３の実施形態では、セッションパーティシパント（例えば、Ｍ２Ｍアプリケーション）は、訪れた以前の場所のリストを提供し得、この情報を使用して、ＳＭＳＦは、これらの場所におけるサービス層インスタンスにクエリし、セッションパーティシパントが現在常駐する新しい場所におけるサービス層インスタンスに共有または移転させられることが可能なセッションパーティシパントに適用可能である既存のサービス層セッションを見つけ得る。
ステップ７において、ＳＭＳＦは、任意の将来のセッションパーティシパントが、それらの各々にクエリすることによって、サービス層セッションをサポート可能であるかどうかをチェックし得る（すなわち、それらがＭ２Ｍサービス層セッション通信をサポートするかどうか）。例えば、ＲｏＡベースの実装に対して、ＳＭＳＦは、将来のセッションパーティシパントが、そのセッション能力をアドバタイズするために使用し得る対応するリソースにクエリし得る。ＳｏＡベースの実装に対して、ＳＭＳＦは、将来のセッションパーティシパントによってサポートされる１つ以上の機能をコールし得、それらは、それらのセッション能力をＳＭＳＦに返し得る。
ステップ８において、ＳＭＳＦは、任意の既存のセッションパーティシパントが、ＳＭＳＦが移転またはそれらと共有することを試みている特定のサービス層セッションに参加することに関心があるかどうかをチェックし得る。既存のセッションパーティシパントが、セッションが移転または新しい将来のセッションパーティシパントと共有されることを要求している場合、セッション識別子および／またはセッション記述子（表１９に定義）が、新しいパーティシパントと共有され、新しいパーティシパントが関心があるかどうかを決定する機会を与え得る。同様に、新しい将来のパーティシパントが、既存のセッションが移転またはそれと共有されることを要求している場合、ＳＭＳＦは、新しい将来のパーティシパントについての情報を既存のセッションパーティシパントと共有し、それらがそれらのセッションの新しい将来のパーティシパントとの共有／移転に関心があるかどうかを決定する機会を与え得る。
ステップ９において、ＳＭＳＦは、セッション移転を行うか、または将来のセッションパーティシパントとのセッション共有を行うかを決定し得る。これは、要求側セッションパーティシパントが移転／共有を開始している場合のために明示的に定義されるか、またはＳＭＳＦがそれらにクエリするときに発見する、将来のセッションパーティシパントのポリシ情報および／または選好に基づいて、ＳＭＳＦによって自律的に導出されるかのいずれかであり得る。
ステップ１０ａにおいて、ＳＭＳＦは、サービス層セッションコンテキストをあるセッションパーティシパントから別のセッションパーティシパントに転送することによって、サービス層セッション移転を行い得る。この転送は、ＳＭＳＦが、最初に、セッションパーティシパントにクエリし、特定のセッションに適用可能である全コンテキストを見つけることによって行われ得る。このクエリは、セッションパーティシパントがセッション識別子（すなわち、タグ）をそれらがサポートするセッションコンテキストの各インスタンスとともに維持することによって可能にされ得る。例えば、ＲｏＡベースのサービス層では、セッション識別子は、セッションに関連付けられた各リソースインスタンス内に含まれ得る。ＳＭＳＦは、次いで、特定のセッションにクエリし、このセッション識別子に基づいて、適用可能であるリソースを見つけ得る。
適用可能であるセッションコンテキストを見つけた後、ＳＭＳＦはセッション移転元であるセッションパーティシパントからセッション移転先であるセッションパーティシパントにこのコンテキストをコピーし得る。このコピープロセス中、ＳＭＳＦはまた、それが移転させられると使用されることができるように、セッションコンテキストのある部分を検査および更新し得る。例えば、セッションパーティシパントアドレスまたは識別子に依存する、セッションコンテキストの部分は、チェックされ、潜在的に、更新されることができる。アドレス／識別子が、セッション移転元であるセッションパーティシパントのものに一致する場合、このアドレスは、セッション移転先であるセッションパーティシパントのアドレスで更新されることができる。コピーされると、セッション移転元であるセッションパーティシパントからのサービス層セッションコンテキストは、削除され得る（他のセッションパーティシパントがそれを使用していない場合）。サービス層セッションコンテキストのこの移転は、限定ではないが、以下のうちの１つ以上のものを含むことができる。（ｉ）サービス層サブスクリプション情報の移転、（ｉｉ）グループメンバーシップ情報の移転、（ｉｉｉ）サービス層連絡先情報の移転、（ｉｖ）サービス層ポリシ（例えば、メッセージ送達およびハンドリングポリシ）の移転、（ｖ）サービス層セキュリティ証明書の移転、（ｖｉ）サービス層デバイス／アプリケーション管理コンテキストの移転、（ｖｉｉ）発見メタデータの移転、（ｖｉｉｉ）場所メタデータの移転、（ｉｘ）課金および会計メタデータの移転、（ｘ）データ（例えば、サービス層コンテナリソース内のアプリケーション規定コンテンツ）の移転、および／または（ｘｉ）サービス層セッションがその上にオーバーレイされる、下層アクセスネットワーク接続および／またはセッションの移転。
セッション移転／共有を行うとき、ＳＭＳＦは、セッションパーティシパントとその対応するコンテキストとを区別し得る。例えば、あるセッションパーティシパントが別のサービス層インスタンスに移転するとき、そのセッションコンテキストは、この新しいサービス層インスタンスに移転させられることができる。加えて、他のセッションパーティシパントも、この移転を認知するように、適宜、ＳＭＳＦによって更新されることができる。ＳＭＳＦは、各セッションパーティシパントのセッションコンテキストを更新することによってこれを行い得る。同様に、セッション共有に対して、セッションが新しいセッションパーティシパントと共有されると、他のセッションパーティシパントは、ＳＭＳＦがそれらのセッションコンテキストも同様に更新することによって、これを通知されることができる。
いくつかの使用例展開では（例えば、ＳＭＳＦがＭ２Ｍサービス層内に埋め込まれた能力であるとき）、移転は、その最終目的地に到達する前に、複数のサービス層インスタンスを横断して、サービス層セッションコンテキストを転送することを伴い得ることに留意されたい。例えば、図２７は、サービス層セッションコンテキスト４４８が、最初に、Ｍ２Ｍゲートウェイ４４４上にホストされるサービス層インスタンス４４６から、Ｍ２Ｍサーバ４５０上にホストされるサービス層インスタンス４５２に移転させられた後、Ｍ２Ｍサーバ４５０上のサービス層インスタンス４５２が、それをＭ２Ｍゲートウェイ４５４上にホストされるサービス層インスタンス４５６に移転する場合を示す。故にこの使用例は、２つのホップを伴う。これらの種類の使用例では、各サービス層インスタンス内にホストされるＳＭＳＦインスタンス間の協働が、サービス層セッションを適切に移転させるために使用され得る。この協働は、ＳＭＳＦインスタンスが、互いに通信を開始し、サービス層セッションコンテキストをそれらの間でパスすることを伴い得る。
ＲｏＡベースのサービス層アーキテクチャに対して、前述の移転動作は、以下のＳＭＳＦ動作によって実現され得る。
１．ＳＭＳＦは、最初に、セッション移転元であるセッションパーティシパントによってホストされるサービス層セッションコンテキストを含むリソースに対してＲＥＴＲＩＥＶＥ動作を行う。これらの読み出し動作は、セッション識別子等のパラメータにクエリし、特定のセッションに適用可能であるコンテキストを見つけることを含むことができる。
２．ＳＭＳＦは、読み出されたリソース表現を検査し、コンテキストが更新されなければならない場合を検出する（例えば、セッションパーティシパントの更新アドレス）。
３．ＳＭＳＦは、ＰＯＳＴ動作をセッション移転先であるセッションパーティシパントに行い、サービス層セッションコンテキストを含むリソースを作成する。
４．ＳＭＳＦは、ＤＥＬＥＴＥ動作を行い、セッション移転元であるセッションパーティシパントによってホストされるサービス層セッションコンテキストを含むリソースを除去する（他のセッションパーティシパントがそれを使用していない場合）。
ＳｏＡベースのサービス層アーキテクチャに対して、前述の移転動作は、以下のＳＭＳＦ動作によって実現され得る。
１．ＳＭＳＦは、最初に、セッション移転元であるセッションパーティシパントによってホストされる機能をコールする。これらの機能を介して、ＳＭＳＦは、サービス層セッションコンテキストを得ることができる。これらの機能は、特定のセッションに適用可能であるコンテキストを見つけるためのクエリパラメータ（セッション識別子等）をサポートすることができる。
２．ＳＭＳＦは、サービスパーティシパントによって返されたサービス層セッションコンテキストを検査し、コンテキストが更新されなければならない場合を検出する（例えば、セッションパーティシパントの更新アドレス）。
３．ＳＭＳＦは、セッション移転先であるセッションパーティシパントによってホストされる機能をコールする。これらの機能を介して、ＳＭＳＦは、サービス層セッションのコピーを作成することができる。
４．ＳＭＳＦは、セッション移転元であるセッションパーティシパントによってホストされる機能をコールする。これらの機能を介して、ＳＭＳＦは、サービス層セッションコンテキストを削除することができる。
ステップ１０ｂにおいて、ＳＭＳＦは、サービス層セッション共有を行い得る。セッション移転のための上記ステップ１０ａに説明されるものと類似した方法が、使用され得る。しかしながら、サービス層セッションコンテキストを新しいセッションパーティシパントにコピー後、それがコピーされたセッションパーティシパントから削除される必要はない。これは、セッションパーティシパントにセッションコンテキストを共有させる結果をもたらす。加えて、１つ以上のＳＭＳＦが、セッションコンテキストをセッションパーティシパント間で更新および同期されたままにするために使用されることができる。例えば、ＳＭＳＦは、ＳＭＳＦ間通信／協働を行い、セッションパーティシパントによってホストされるサービス層セッションコンテキストのコピーが互いに同期したままであることを確実にすることができる。そうすることによって、セッションパーティシパントは、サービス層セッションを共有することができる。
ステップ１１において、ＳＭＳＦは、サービス層セッションがその上にオーバーレイされる下層アクセスネットワークノードと連携し、下層アクセスネットワーク接続を管理し得る。これは、以下を含むことができる。
１．もはやセッションパーティシパントによって要求されない下層アクセスネットワーク接続の切断および／または解除（例えば、セッション移転元であるセッションパーティシパントによって使用されるアクセスネットワーク接続の切断）を調整すること。
２．サービス層セッションが移転または共有されたセッションパーティシパントに関する新しい情報での既存の下層アクセスネットワーク接続の更新（例えば、下層アクセスネットワークが、新しい場所に基づいて、既存の接続を移転させるか、または新しい接続を確立し得るように、セッションパーティシパントの新しい場所で）を調整すること。
３．サービス層セッションが移転または共有された新しいセッションパーティシパントをサポートするための新しい下層アクセスネットワーク接続の確立を調整すること（例えば、新しいアクセスネットワーク接続をより効率的かつ効果的に構成および確立し得るように、サービス層セッション情報を下層アクセスネットワークに提供する）。例えば、サービス層セッション移転または共有スケジュールが、下層アクセスネットワークに提供されることができ、このスケジュールは、アクセスネットワークによって使用され、この共有または移転スケジュールの周囲で下層アクセスネットワーク接続を先を見越して確立および切断することができる。
ステップ１２において、ＳＭＳＦは、サービス層セッション移転または共有トリガ／要求の処理を完了し得る。完了時、ＳＭＳＦは、ステップ４に戻り、セッションコンテキストの収集および維持を継続し、次のトリガが生じるのを待機し得る。
図３０に図示されるようなＳＭＳＦの機能性は、以下に説明される図３７Ｃまたは３７Ｄに図示されるもの等、Ｍ２Ｍネットワーク（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のノードのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。すなわち、図３０に図示される方法は、例えば、図３７Ｃまたは３７Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３０に図示されるステップを行う。図３０に図示されるステップの任意の伝送および受信は、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下において、ノードの通信回路によって行われ得ることも理解されたい。
本明細書に以下で開示されるのは、Ｍ２Ｍサービス層セッション移転および共有のための前述のＳＭＳＦおよび方法が、ｏｎｅＭ２Ｍアーキテクチャに従って動作するネットワーク内に実装される、実施形態である。前述のように、ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。これらの能力は、能力サービス機能（ＣＳＦ）と称される。ｏｎｅＭ２Ｍサービス層は、能力サービスエンティティ（ＣＳＥ）と称される。図３１に示されるように、ＣＳＥ２７１’は、ＣＳＦ２７０’の組をサポートする。一実施形態では、ＣＳＥ２７１’は、図９に図示され、上で説明されたＣＳＥ２７２の修正バージョンであり得、ＣＳＦ２７１’の組も同様に、図９に図示され、上で説明されたＣＳＦ２７１の修正バージョンであり得る。
ＣＳＥのためのｏｎｅＭ２Ｍ仕様のあるバージョンは、サービスセッション管理（ＳＳＭ）ＣＳＦの予備定義を含む。この初期定義は、セッションパーティシパント（例えば、Ｍ２ＭアプリケーションおよびＭ２Ｍサービス層インスタンス）間のサービス層セッション確立をサポートするが、しかしながら、サービス層セッション移転または共有をサポートしない。このギャップに対処するために、前述および後述のＳＭＳＦ機能性が、ｏｎｅＭ２Ｍ ＳＳＭ ＣＳＦの現在のバージョン内に組み込まれ得る。これは、図３１に図示され、ＳＭＳＦ（前述および後述のような）が、サービスセッション管理（ＳＳＭ）ＣＳＦ２７２’の一部として組み込まれる。一実施形態では、ＳＳＭ ＣＳＦ２７２’は、図９に図示され、上で説明されたＳＳＭ ＣＳＦ２７２の修正バージョンであり得る。ＳＭＳＦ（例えば、ＳＭＳＦ４６０）をＳＳＭ ＣＳＦ（例えば、ＳＳＭ ＣＳＦ２７２’）の中に組み込むことによって、本明細書に説明されるサービス層セッション移転および共有機能性は、ＳＳＭ ＣＳＦによってサポートされることができる。
例えば、ＯｎｅＭ２Ｍ機能アーキテクチャ、ｏｎｅＭ２Ｍ−ＴＳ−０００１バージョン０．４．３で説明されるようなｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲｏＡ）によると、個々のＣＳＦは、それらのそれぞれのインターフェースとしての役割を果たす「リソース」の組をサポートし、リソースは、アーキテクチャ内で固有にアドレス可能なエンティティである。リソースは、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ等のＲＥＳＴｆｕｌ方法を介して操作され、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレスされ得る表現を有する。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの有効期間は、親のリソース有効期間によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。
本明細書で以下に説明されるのは、現在定義されているｏｎｅＭ２Ｍ ＳＳＭ ＣＳＦのためのセッション移転および共有機能性をサポートするためのｏｎｅＭ２Ｍリソース構造拡張である。リソース構造を記述するためのｏｎｅＭ２Ｍ定義グラフィカル表現は、以下であることに留意されたい。（ｉ）正方形ボックスは、リソースおよび子リソースのために使用され、（ｉｉ）丸みを帯びた角を伴う正方形ボックスは、属性のために使用され、（ｉｉｉ）平行四辺形は、リソースの集合のために使用され、（ｉｖ）各属性および子リソースの多重度が、定義され、（ｖ）「＜」および「＞」で区切られたリソース名は、リソースの作成の間に割り当てられた名称を示す。
図３２は、＜ｓｅｓｓｉｏｎ＞リソース属性の組から成るｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎ＞リソース構造の修正を示す。示されるように、リソース構造は、属性を＜ｓｅｓｓｉｏｎ＞リソースに追加し、セッション移転および共有機能性をサポートすることによって修正され得る。これらの属性は、以下の表２０にリスト化および説明される。
ｍｉｇｒａｔｉｏｎＯｋおよびｓｈａｒｉｎｇＯＫ属性は、ＳＭＳＦが所与のセッションのためのセッション移転または共有を行うことをイネーブルまたはディスエーブルにするために使用され得る。これらの属性は、必ずしも、互いに相互排他的である必要はないことに留意されたい。同一セッションが、共有および／または移転させられ得る。ＳＭＳＦスケジュール属性は、ＳＭＳＦがセッション移転または共有を行うときをスケジュールするために使用され得る。
ＳＭＳＦスケジュール属性をエンコードするための一例示的実施形態は、ＳＭＳＦがセッションの移転または共有をスケジュールするために使用し得る時間窓を提供することである。この時間窓は、いくつかの異なる形式で表され得る。以下は、いくつかの例である。
一実施形態では、時間窓は、例えば、以下のように、コンマで分離された開始および終了時間として表され得る。
２０１４−１２−２４Ｔ１７：００：００＋１：００
２０１４−１２−２４Ｔ２１：００：００＋１：００
別の実施形態では、時間窓は、例えば、以下のように、ＸＭＬでエンコードされた開始および終了時間として表され得る。
＜ｓｍｓｆＳｃｈｅｄｕｌｅ＞
＜ｓｔａｒｔ＞ ２０１４−１２−２４Ｔ１７：００：００＋１：００ ＜／ｓｔａｒｔ＞
＜ｅｎｄ＞ ２０１４−１２−２４Ｔ２１：００：００＋１：００ ＜／ｅｎｄ＞
＜／ｓｍｓｆＳｃｈｅｄｕｌｅ＞
さらに別の実施例として、時間窓は、例えば、以下のように、ＪＳＯＮでエンコードされた開始および終了時間として規定され得る。
“ｓｍｓｆＳｃｈｅｄｕｌｅ”： ｛
“ｓｔａｒｔ”： “２０１４−１２−２４Ｔ１７：００：００＋１：００”，
“ｅｎｄ”： “２０１４−１２−２４Ｔ２１：００：００＋１：００”
｝
ＳＭＳＦｔａｒｇｅｔｓは、セッションが移転または共有されるべき、将来のセッションパーティシパントを規定するために使用され得る。一実施形態では、ＳＭＳＦｔａｒｇｅｔｓ属性は、ＵＲＩのリストとしてエンコードされ得、各ＵＲＩは、アクティブまたは将来のセッションパーティシパントに参照される。このリストは、いくつかの異なる形式で表され得る。
第１の例として、リストは、例えば、以下のように、ＵＲＩのコンマで分離されたリストとして表され得る。
ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ，
ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ，
ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ３＠ｅｘａｍｐｌｅ．ｃｏｍ
別の例として、リストは、例えば、以下のように、ＵＲＩのＸＭＬでエンコードされたリストとしてエンコードされ得る。
＜ｓｍｓｆＴａｒｇｅｔｓ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ３＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜／ｓｍｓｆＴａｒｇｅｔｓ＞
さらに別の例として、リストは、例えば、以下のように、ＵＲＩのＪＳＯＮでエンコードされるリストとしてエンコードされ得る。
“ｓｍｓｆＴａｒｇｅｔｓ”： ［
｛ｓｍｓｆＴａｒｇｅｔ： “ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ”｝，
｛ｓｍｓｆＴａｒｇｅｔ： “ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”｝，
｛ｓｍｓｆＴａｒｇｅｔ： “ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”｝
］
ＳＭＳＦｔｒｉｇｇｅｒ属性は、ＳＭＳＦを明示的にトリガし、セッション移転または共有を行うために使用され得る。
ＳＭＳＦｔｒｉｇｇｅｒ属性をエンコードするための一例示的実施形態は、条件のリストを使用することであり、各条件は、ＳＭＳＦがセッション移転または共有を開始するための基準である。一実施形態では、ＳＭＳＦは、基準シンタックスをサポートし得る。リスト内の１つ以上の基準がＳＭＳＦによって真であると評価される場合、セッション移転または共有をトリガし得る。前のリストのように、このリストは、いくつかの異なる形式で表され得る。例えば、以下のように、条件のコンマで分離されたリストとしてエンコードされ得る。
ｌｏｃａｔｉｏｎ ｏｆ ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ ｉｓ ５７．６４９１１，１０．４０７４４”
ｓｔａｔｕｓ ｏｆ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ ｉｓ ｕｎａｖａｉｌａｂｌｅ
代替として、例えば、以下のように、条件のＸＭＬでエンコードされたリストとしてエンコードされ得る。
＜ｓｍｓｆＴｒｉｇｇｅｒｓ＞
＜ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ”＜／ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞
＜ｌｏｃａｔｉｏｎ＞５７．６４９１１，１０．４０７４４＜／ｌｏｃａｔｉｏｎ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”＜／ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞
＜ｓｔａｔｕｓ＞ｕｎａｖａｉｌａｂｌｅ＜／ｓｔａｔｕｓ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒｓ＞
また、例えば、以下のように、条件のＪＳＯＮでエンコードされたリストとしてエンコードされ得る。
“ｓｍｓｆＴｒｉｇｇｅｒｓ”： ［
｛ｓｍｓｆＴｒｉｇｇｅｒ：
“ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ”： ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ，
“ｌｏｃａｔｉｏｎ”： “５７．６４９１１，１０．４０７４４”
｝
｛ｓｍｓＴｒｉｇｇｅｒ：
“ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ”： ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ，
“ｓｔａｔｕｓ”： “ｕｎａｖａｉｌａｂｌｅ”
｝
］
図３３は、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソース構造の修正を示す。特に、サービス層セッション移転および共有具体的ポリシ属性は、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースに追加され得る。一実施形態では、これらの属性は、ポリシタイプ属性およびポリシ属性を含む。各々は、表２１により詳細に説明される。
ｐｏｌｉｃｙＴｙｐｅ属性は、セッションポリシがセッション移転ポリシまたはセッション共有ポリシであるかどうかを規定するために使用され得る。ｐｏｌｉｃｙ属性は、ＳＭＳＦによって使用されるセッション移転または共有具体的ポリシを規定するために使用され得る。
一実施形態では、セッションポリシ定義は、ＳＭＳＦがセッション移転または共有を行うときに使用し得るトリガ条件、スケジュール情報、およびセッションパーティシパント等の情報を構成する、セッション移転および共有ルールから成るデータ構造を定義することによってエンコードされ得る。このデータ構造は、その中に埋め込まれたこの情報を含むか、またはこの情報を含む他のリソースへのリンク（例えば、Ｓｃｈｅｄｕｌｅ、ｓｍｓｆＴａｒｇｅｔｓ、およびｓｍｓｆＴＲｉｇｇｅｒｓ属性をサポートする、上記に定義された＜ｓｅｓｓｉｏｎ＞リソースへのリンク）を含むかのいずれかであり得る。
以下は、ＸＭＬでエンコードされたポリシ定義の実施例である。
＜ｓｍｓｆＲｕｌｅ＞
＜ｓｍｓｆＳｃｈｅｄｕｌｅ＞
＜ｓｔａｒｔ＞ ２０１４−１２−２４Ｔ１７：００：００＋１：００ ＜／ｓｔａｒｔ＞
＜ｅｎｄ＞ ２０１４−１２−２４Ｔ２１：００：００＋１：００ ＜／ｅｎｄ＞
＜／ｓｍｓｆＳｃｈｅｄｕｌｅ＞
＜ｓｍｓｆＴｒｉｇｇｅｒｓ＞
＜ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ”＜／ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞
＜ｌｏｃａｔｉｏｎ＞５７．６４９１１，１０．４０７４４＜／ｌｏｃａｔｉｏｎ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｍｓｆＴｒｉｇｇｅｒ＞
＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”＜／ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞
＜ｓｔａｔｕｓ＞ｕｎａｖａｉｌａｂｌｅ＜／ｓｔａｔｕｓ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒ＞
＜／ｓｍｓｆＴｒｉｇｇｅｒｓ＞
＜ｓｍｓｆＴａｒｇｅｔｓ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜ｓｍｓｆＴａｒｇｅｔ＞ ｐａｒｔｉｃｉｐａｎｔ３＠ｅｘａｍｐｌｅ．ｃｏｍ ＜／ｓｍｓｆＴａｒｇｅｔ＞
＜／ｓｍｓｆＴａｒｇｅｔｓ＞
＜／ｓｍｓｆＲｕｌｅ＞
例示的ＪＳＯＮでエンコードされたポリシ定義は、以下であり得る。
“ｓｍｓｆＲｕｌｅ”： ｛
“ｓｍｓｆＳｃｈｅｄｕｌｅ”： ｛
“ｓｔａｒｔ”： “２０１４−１２−２４Ｔ１７：００：００＋１：００”，
“ｅｎｄ”： “２０１４−１２−２４Ｔ２１：００：００＋１：００”
｝
“ｓｍｓｆＴａｒｇｅｔｓ”： ［
｛ｓｍｓｆＴａｒｇｅｔ： “ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ”｝，
｛ｓｍｓｆＴａｒｇｅｔ： “ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”｝，
｛ｓｍｓｆＴａｒｇｅｔ： “ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”｝
］
“ｓｍｓｆＴｒｉｇｇｅｒｓ”： ［
｛ｓｍｓｆＴｒｉｇｇｅｒ：
“ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ”： ｐａｒｔｉｃｉｐａｎｔ１＠ｅｘａｍｐｌｅ．ｃｏｍ，
“ｌｏｃａｔｉｏｎ”： “５７．６４９１１，１０．４０７４４”
｝
｛ｓｍｓＴｒｉｇｇｅｒ：
“ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ”： ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ，
“ｓｔａｔｕｓ”： “ｕｎａｖａｉｌａｂｌｅ”
｝
］
｝
図３４は、ｏｎｅＭ２Ｍ＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソース構造の修正を示す。示されるように、サービス層セッション移転および共有コンテキストタイプは、＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソースに追加され得る。特に、表２２に定義されたセッションコンテキスト属性が、追加され得る。このコンテキストは、所与のセッションの全パーティシパントに適用可能であり得る、または個々のセッションパーティシパントに特有であり得ることに留意されたい。例えば、個々のセッションパーティシパントに特有のコンテキストに関して、図３５に示されるように、＜ｓｅｓｓｉｏｎＰａｒｔｉｃｉｐａｎｔ＞リソース下でインスタンス化（またはそれにリンク）され得る。
一実施形態では、セッションコンテキスト定義は、ＳＭＳＦがセッション移転または共有を行うときに使用し得るセッション移転および共有コンテキストから成るデータ構造を定義することによってエンコードされ得る。このデータ構造は、その中に埋め込まれたこの情報を含むか、またはこの情報を含む他のリソースへのリンク（例えば、ｓｍｓｆＴａｒｇｅｔｓ属性等の属性をサポートする、上記に定義された＜ｓｅｓｓｉｏｎ＞リソースへのリンク）を含むかのいずれかであり得る。
以下は、ＸＭＬでエンコードされるコンテキスト定義の実施例である。
＜ｓｍｓｆＣｏｎｔｅｘｔ＞
＜ｓｍｓｆＰａｒｔｉｃｉｐａｎｔ＞
＜ｉｄ＞ ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ＜／ｉｄ＞
＜ｃｕｒｒｅｎｔＬｏｃａｔｉｏｎ＞ ５７．６４９１１，１０．４０７４４＜／ｌｏｃａｔｉｏｎ＞＜／ｃｕｒｒｅｎｔＬｏｃａｔｉｏｎ＞
＜ｓｅｓｓｉｏｎＩｄ＞ｓｅｓｓｉｏｎ１２３＜／ｓｅｓｓｉｏｎＩｄ＞
＜ｓｅｓｓｉｏｎＣｒｅｄｅｎｔｉａｌ＞ＸＹＺ３６７＜／ｓｅｓｓｉｏｎＣｒｅｄｅｎｔｉａｌ＞
＜ｃｈａｒｇｉｎｇＲｅｃｏｒｄ＞ｌｉｎｋ ｔｏ ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄ ｒｅｓｏｕｒｃｅ＜／ｃｈａｒｇｉｎｇＲｅｃｏｒｄ＞
＜ｓｅｓｓｉｏｎＤａｔａ＞ｌｉｎｋ ｔｏ ｃｏｎｔａｉｎｅｒ ｒｅｓｏｕｒｃｅ＜／ｓｅｓｓｉｏｎＤａｔａ＞
＜ｒｏｕｔｉｎｇＩｎｆｏ＞ＩＰ ａｄｄｒｅｓｓ ａｎｄ ｐｏｒｔ＜／ｒｏｕｔｉｎｇＩｎｆｏ＞
＜ｄｉｓｃｏｖｅｒｙＩｎｆｏ＞ｓｅｍａｎｔｉｃ ｔａｇｓ ｏｒ ｌｉｎｋｓ ｔｏ ｏｎｔｏｌｏｇｉｅｓ＜／ｄｉｓｃｏｖｅｒｙＩｎｆｏｒ＞
＜ｈｉｓｔｏｒｙ＞ｌｉｎｋ ｔｏ ｔｒａｎｓａｃｔｉｏｎ ｈｉｓｔｏｒｙ ｒｅｓｏｕｒｃｅ＜／ｈｉｓｔｏｒｙ＞
＜ａｃｃｅｓｓＮＷＩｎｆｏ＞Ａｃｃｅｓｓ ＮＷ ＩＤｓ ａｎｄ ｒｏｕｔｉｎｇ ｉｎｆｏ＜／ａｃｃｅｓｓＮＷＩｎｆｏ＞
＜／ｓｍｓｆＰａｒｉｃｉｐａｎｔ＞
＜／ｓｍｓｆＣｏｎｔｅｘｔ＞
以下は、ＪＳＯＮでエンコードされるコンテキスト定義の実施例である。
“ｓｍｓｆＣｏｎｔｅｘｔ”： ｛
“ｓｍｓｆＰａｒｔｉｃｉｐａｎｔ”： ｛
“ｉｄ”： “ｐａｒｔｉｃｉｐａｎｔ２＠ｅｘａｍｐｌｅ．ｃｏｍ”，
“ｃｕｒｒｅｎｔＬｏｃａｔｉｏｎ”： “５７．６４９１１，１０．４０７４４”，
“ｓｅｓｓｉｏｎＩｄ”： “ｓｅｓｓｉｏｎ１２３”，
“ｓｅｓｓｉｏｎＣｒｅｄｅｎｔｉａｌ”： “ＸＹＺ３６７”，
“ｃｈａｒｇｉｎｇＲｅｃｏｒｄ”： “ｌｉｎｋ ｔｏ ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄ ｒｅｓｏｕｒｃｅ”，
“ｓｅｓｓｉｏｎＤａｔａ”： “ｌｉｎｋ ｔｏ ｃｏｎｔａｉｎｅｒ ｒｅｓｏｕｒｃｅ”，
“ｒｏｕｔｉｎｇＩｎｆｏ”： “ＩＰ ａｄｄｒｅｓｓ ａｎｄ ｐｏｒｔ”，
“ｄｉｓｃｏｖｅｒｙＩｎｆｏ”： “ｓｅｍａｎｔｉｃ ｔａｇｓ ｏｒ ｌｉｎｋｓ ｔｏ ｏｎｔｏｌｏｇｉｅｓ”，
“ｈｉｓｔｏｒｙ”： “ｌｉｎｋ ｔｏ ｔｒａｎｓａｃｔｉｏｎ ｈｉｓｔｏｒｙ ｒｅｓｏｕｒｃｅ”，
“＜ａｃｃｅｓｓＮＷＩｎｆｏ”： “Ａｃｃｅｓｓ ＮＷ ＩＤｓ ａｎｄ ｒｏｕｔｉｎｇ ｉｎｆｏ”
｝
｝
図３６Ａ−３６Ｃは、ｏｎｅＭ２Ｍサービス層セッションが移転する方法の一例示的実施形態を図示し、上で説明されたｏｎｅＭ２ＭＳＭＳＦリソース拡張が移転プロセスにおいて使用され得る方法を実証する。この例では、Ｍ２Ｍデバイス４７０上にホストされるＭ２Ｍアプリケーション４７２と第１のＭ２Ｍゲートウェイ４７６（Ｍ２Ｍ ＧＷ＃１）のサービス層インスタンス４７４との間のＭ２Ｍサービス層セッションは、Ｍ２Ｍサーバ４８２上にホストされるサービス層インスタンス４８０を介して、その第１のＭ２Ｍゲートウェイ４７６上にホストされるサービス層インスタンスから第２のＭ２Ｍゲートウェイ４８８（Ｍ２Ｍ ＧＷ＃２）上にホストされるサービス層インスタンス４８６に移転させられている。示されるように、本実施形態では、サービス層インスタンス４７４、４８０、および４８６の各々は、サービスセッション管理（ＳＳＭ）ＣＳＦ４７８、４８４、および４９０を含み、それぞれ、例えば、図３０に図示され、上で説明されたセッション移転および共有機能（ＳＭＳＦ）機能性を含む。この例では、移転は、第１の場所（図３６Ａの左に示される）から新しい場所（図３６Ａの右に示される）に移動したモバイルＭ２Ｍデバイス（例えば、デバイス４７０）をサポートするために行われている。
本実施形態では、移転は、Ｍ２Ｍ ＧＷ＃１ ４７６、Ｍ２Ｍサーバ４８２、およびＭ２Ｍ ＧＷ＃２ ４８８上にインスタンス化されたＳＭＳＦ（４７８、４８４、４９０）間の協働を介して行われる。故に、サービス層セッションコンテキストの移転経路は、Ｍ２ＭＧＷ＃１ ４７６からＭ２Ｍサーバ４８２への後、Ｍ２Ｍサーバ４８２からＭ２Ｍ ＧＷ＃２ ４８８に続く。他の実施形態では（図示せず）、サービス層セッションコンテキストの移転経路は、直接、Ｍ２ＭＧＷ＃１ ４７６からＭ２ＭＧＷ＃２ ４８８へであり得、その場合、Ｍ２Ｍサーバ４８２は、役割を果たさないであろうことにも留意されたい。サービス層移転が、この例では具体的に示されるが、移転動作を前述のような対応する共有動作で置き換えた類似ステップを代わりに使用して、サービス層セッション共有が行われ得ることにも留意されたい。
図３６Ａを参照すると、ステップ００１ａおよび００１ｂにおいて、Ｍ２Ｍデバイス４７０上にホストされるＭ２Ｍアプリケーション４７２が、Ｍ２Ｍ ＧＷ＃１ ４７６上にホストされるＭ２Ｍサービス層インスタンス４７４に登録する。この登録は、４９２に図示されるように、ｏｎｅＭ２Ｍ定義＜ａｐｐｌｉｃａｔｉｏｎ＞リソースをＭ２Ｍ ＧＷ＃１ ４７６上に作成することによって行われる。
次に、Ｍ２Ｍデバイス４７０上にホストされるＭ２Ｍアプリケーション４７２は、Ｍ２Ｍサービス層セッションをそれ自身とＭ２ＭＧＷ＃１ ４７６上にホストされるサービス層インスタンス４７４との間に確立する。これは、Ｍ２Ｍアプリケーションが、ステップ００２ａに示されるように、ｏｎｅＭ２Ｍ定義＜ｓｅｓｓｉｏｎ＞リソースを作成することによって開始される。これを行うと、アプリケーション４７２は、ｍｉｇｒａｔｉｏｎＯＫ属性を「真の」に構成することによって、それがセッションが移転可能であること望むことを示す。アプリケーションはまた、その固有のアプリケーションインスタンス識別子（‘ａｐｐＸＹＺ１２３’）をこの要求に含む。
ステップ００３ａおよび００３ｂにおいて、Ｍ２ＭＧＷ＃１ ４７６上にホストされるＳＳＭ／ＳＭＳＦ４７８は、Ｍ２Ｍアプリケーション「ａｐｐＸＹＺ１２３」のためにすでに利用可能な移転可能なセッションがあるかどうかをチェックする。これは、Ｍ２Ｍサーバ４８２上のサービス層インスタンス４８０にクエリし、「ａｐｐＸＹＺ１２３」に関連付けられた任意のセッションリソースが作成されるか、またはサーバにアナウンスされているかを確認することによって行われ得る。この例では、何も存在しない。その結果、４９４に示されるように、Ｍ２Ｍ ＧＷ＃１ ４７６上にホストされるＳＳＭ／ＳＭＳＦ４７８は、Ｍ２Ｍアプリケーション４７２のための新しい＜ｓｅｓｓｉｏｎ＞リソースを作成する。この＜ｓｅｓｓｉｏｎ＞リソースを作成すると、固有の「ｓｅｓｓｉｏｎＩＤ」（例えば、「ＸＹＺ１２３」）が、ＳＳＭ／ＳＭＳＦによって、セッションに配分され、割り当てられる。この「ｓｅｓｓｉｏｎＩＤ」は、ステップ００２ｂにおいて、Ｍ２Ｍアプリケーションに返される。
ステップ００４ａおよび００４ｂにおいて、新しい＜ｓｅｓｓｉｏｎ＞リソースを作成後、Ｍ２ＭＧＷ＃１ ４７６上のＳＳＭ／ＳＭＳＦ４７８は、このリソースをＭ２Ｍサーバ４８０上にホストされるサービス層インスタンス４８０にアナウンスする。これは、Ｍ２Ｍアプリケーション４７２が、＜ｓｅｓｓｉｏｎ＞作成要求（ステップ００２ａ）において、「ｍｉｇｒａｔｉｏｎＯＫ」フラグを「真の」に設定したので行われる。＜ｓｅｓｓｉｏｎ＞リソースをアナウンスすることによって、ＳＳＭ／ＳＭＳＦ４７８は、セッションが、ネットワーク内の他のサービス層インスタンス上にホストされるＳＳＭ／ＳＭＳＦ（例えば、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるＳＳＭ／ＳＭＳＦ４９０）によって発見可能であることを可能にする。Ｍ２Ｍサーバ４８２にアナウンスするとき、アナウンスされたリソースは、「ｓｅｓｓｉｏｎＩＤ」およびＭ２Ｍ ＧＷ＃１ ４７６上のサービス層４７４内にホストされる＜ｓｅｓｓｉｏｎ＞リソースに戻るリンクを含む。
次に、ステップ００５ａおよび００５ｂにおいて、Ｍ２Ｍアプリケーション４７２は、セッションがアクティブである間にＳＳＭ／ＳＭＳＦによって収集および維持されるべきセッションコンテキストのタイプ、ならびにセッションが別のサービス層に移転させられる場合／ときに移転させられるべきコンテキストを定義するサービス層セッションポリシリソースを作成する。セッションポリシリソースの作成は、４９６に描写される。
この例を継続する、図３６Ｂを参照すると、ステップ６は、Ｍ２Ｍアプリケーション４７２とＭ２ＭＧＷ＃１４７６上にホストされるサービス層インスタンス４７４との間に生じる通常のセッションベースの通信を描写する。
セッションベースの通信が生じると、Ｍ２Ｍ ＧＷ＃１ ４７６上にホストされるＳＳＭ／ＳＭＳＦ４７８は、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞ルールに基づいて、サービス層セッションに関するコンテキスト（表１９に定義されたコンテキスト等）を収集し得る。このコンテキストは、ＳＳＭ／ＳＭＳＦ４７８によって、Ｍ２Ｍ ＧＷ＃１ ４７６上に作成される＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソース内に記憶され得る。ＳＳＭ／ＳＭＳＦ４７８は、これらのリソースとこのセッションのｓｅｓｓｉｏｎＩＤ（例えば、「ＸＹＺ１２３」）をタグ付けし得る。
この例では、ステップ００８ａおよび００８ｂに描写されるように、Ｍ２Ｍデバイス４７０は、その第１の場所から第２の場所に移動する。この例では、移動後、デバイス４７０は、もはやＭ２Ｍ ＧＷ＃１ ４７６の近傍にない。代わりに、Ｍ２Ｍ ＧＷ＃２ ４８８の近傍にある。
ステップ００９ａおよび００９ｂにおいて、Ｍ２Ｍデバイスは、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるサービス層インスタンス４８６に登録する。
再び、この例を継続する、図３６Ｃを参照すると、ステップ０１０ａにおいて、Ｍ２Ｍデバイス４７０上にホストされるＭ２Ｍアプリケーション４７２は、それ自身とＭ２Ｍ ＧＷ＃２ ４８８上にホストされるサービス層インスタンス４８６との間にＭ２Ｍサービス層セッションの確立を試みる。これは、Ｍ２Ｍアプリケーション４７２がＭ２Ｍ ＧＷ＃２ ４８８上にホストされるサービス層インスタンス４８６に登録し、それにＭ２Ｍ ＧＷ＃１ ４７６上にホストされるサービス層と確立したセッションのｓｅｓｓｉｏｎＩＤ（例えば、「ＸＹＺ１２３」）を提供することによって開始される。
ステップ０１１ａにおいて、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるＳＳＭ／ＳＭＳＦ４９０は、Ｍ２Ｍアプリケーション登録がｓｅｓｓｉｏｎＩＤを含むので、Ｍ２Ｍアプリケーション登録によってトリガされる。ＳＳＭ／ＳＭＳＦ４９０は、Ｍ２Ｍアプリケーション「ａｐｐＸＹＺ１２３」のためにすでに利用可能な移転可能セッションが存在するかどうかをチェックする。これは、ステップ０１１ｂにおいて、その親サービス層（すなわち、Ｍ２Ｍサーバ４８２）上のサービス層４８０にクエリし、「ａｐｐＸＹＺ１２３」に関連付けられた任意のセッションリソースが作成されているか、またはそれにアナウンスされているかどうかを確認することによって行われる。この特定の場合、１つ存在し、Ｍ２Ｍ ＧＷ＃１ ４７６上にホストされる対応する＜ｓｅｓｓｉｏｎ＞リソースへのリンクが、ステップ０１１ｃに示されるように、Ｍ２Ｍ ＧＷ＃２ ４８８上のＳＳＭ／ＳＭＳＦ４９０に返される。
ステップ１２において、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるＳＳＭ／ＳＭＳＦ４９０は、サービス層セッションをＭ２Ｍ ＧＷ＃１上のサービス層４７４から移転させる。これを行うために、ＳＳＭ／ＳＭＳＦ４９０は、最初に、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞リソースを読み出し、順守する必要がある任意のセッション移転ポリシが存在するかどうかを決定する。これらのポリシを使用して、ＳＳＭ／ＳＭＳＦ４９０は、セッションをＭ２Ｍ ＧＷ＃２ ４８８に移転させることができるかどうかを決定し得る。該当する場合、ＳＳＭ／ＳＭＳＦ４９０は、＜ｓｅｓｓｉｏｎ＞、＜ｓｅｓｓｉｏｎＰｏｌｉｃｙ＞、および＜ｓｅｓｓｉｏｎＣｏｎｔｅｘｔ＞リソースを選択的に読み出し、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるサービス層４８６のリソースツリー内に対応するバージョンを作成し得る。読み出しを行うとき、ＳＳＭ／ＳＭＳＦ４９０は、ｓｅｓｓｉｏｎＩＤを含むクエリストリングパラメータを含み得る。これは、ＳＳＭ／ＳＭＳＦ４９０が、移転させようとするセッションに適用可能なセッションリソースを見つけることを可能にする。これらの読み出しに対する応答を受信すると、ＳＳＭ／ＳＭＳＦ４９０は、読み出されたリソース表現を検査し、コンテキストが更新されなければならない場合を検出し得る（例えば、移転に起因してもはや有効ではないセッションパーティシパントの変更を考慮するため）。ＳＳＭ／ＳＭＳＦ４９０がプロセスの読み出しおよび作成を完了すると、次いで、セッションをＭ２Ｍ ＧＷ＃１ ４７６上にホストされるサービス層から削除することができる。ステップ０１０ａにおいて、送信されたセッション作成要求への応答は、次いで、ステップ０１０ｂにおいて、Ｍ２Ｍアプリケーション４７２に送信され得る。
ステップ０１３において、Ｍ２Ｍ ＧＷ＃２ ４８８上にホストされるＳＳＭ／ＳＭＳＦ４９０は、下層アクセスネットワークと連携し、サービス層セッション情報をそれにパスし得る。この情報を使用して、下層アクセスネットワークは、Ｍ２Ｍデバイス４７０に対応するアクセスネットワーク接続をサービス層セッションと調整し得る。例えば、Ｍ２Ｍ ＧＷ＃１ ４７６に接続するためにＭ２Ｍデバイス４７０によってもはや要求されない下層アクセスネットワーク接続の切断および／または解除、もしくはサービス層セッションスケジュール情報（例えば、サービス層セッションがアクティブ／非アクティブである時間、セッション移転スケジュール等）の共有を調整し得る。これは、アクセスネットワークによって、この情報を活用して、下層アクセスネットワーク接続を先を見越して確立および切断するために使用され得る。
図３６Ａ−Ｃに図示されるステップを行うエンティティは、以下に説明される図３７Ｃまたは３７Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。すなわち、図３６Ａ−３６Ｃに図示される方法は、例えば、図３７Ｃまたは３７Ｄに図示されるノードまたはコンピュータシステム等、ネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令、ノードのプロセッサによって実行されると、図３６Ａ−Ｃに図示されるステップを行う。また、図３６Ａ−Ｃに図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることを理解されたい。
本明細書に記載される実施形態は、表象状態転送（ＲＥＳＴ）アーキテクチャの観点から説明され、説明されるコンポーネントおよびエンティティは、ＲＥＳＴアーキテクチャ（ＲＥＳＴｆｕｌアーキテクチャ）の制約に準拠する。ＲＥＳＴｆｕｌアーキテクチャは、使用される物理的コンポーネント実装または通信プロトコルの観点からではなく、アーキテクチャにおいて使用されるコンポーネント、エンティティ、コネクタ、およびデータ要素に適用される制約の観点から説明される。したがって、コンポーネント、エンティティ、コネクタ、およびデータ要素の役割および機能が、説明されるであろう。ＲＥＳＴｆｕｌアーキテクチャでは、固有のアドレス可能リソースの表現が、エンティティ間において転送される。ＲＥＳＴｆｕｌアーキテクチャにおいてリソースを取り扱うとき、Ｃｒｅａｔｅ（子リソースを作成する）、Ｒｅｔｒｉｅｖｅ（リソースのコンテンツを読み取る）、Ｕｐｄａｔｅ（リソースのコンテンツを書き込む）、またはＤｅｌｅｔｅ（リソースを削除する）等、リソースに適用され得る基本方法が存在する。当業者は、本実施形態の実装が、本開示の範囲内に留まりながら、変動し得ることを認識するであろう。当業者はまた、開示される実施形態が、例示的実施形態を説明するために本明細書で使用されるｏｎｅＭ２Ｍアーキテクチャを使用する実装に限定されないことを認識するであろう。開示される実施形態は、ＥＴＳＩ Ｍ２Ｍ、３ＧＰＰ ＭＴＣ，ＯＭＡ ＬＷＭ２Ｍ、ならびに他のＭ２Ｍシステムおよびアーキテクチャ等のアーキテクチャおよびシステム内に実装され得る。
（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図３７Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的構成要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ，またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等のコンポーネントまたはノードであり得る。
図３７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、あるいは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図３７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４および端末デバイス１８を含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、通信回路を使用して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図３７Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、ゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、１つ以上のネットワークのノードによって実装され得る。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用される、サービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。
さらに、図３７Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカル が活用することができる、サービス配布能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、サーバ、および他のシステムの他のノードを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能に、Ｍ２Ｍアプリケーション２０および２０’を提供する。
前述のように、本明細書に説明されるセッション移転および共有機能（ＳＭＳＦ）は、Ｍ２Ｍシステムのサービス層の一部として実装され得る。概して、図３７Ａおよび３７Ｂに図示されるサービス層２２および２２’’等のサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション特定のノード）上にホストされることができる。第３世代パートナーシッププロジェクト（３ＧＰＰ）も、マシン型通信（ＭＴＣ）のためのアーキテクチャを定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬ、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥ、またはネットワークのある他のノード内に具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイスもしくはノードを含む、ネットワーク内の１つ以上の独立型ノード上、または１つ以上の既存のノードの一部としてのいずれかで実行する、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下に説明される図３７Ｃまたは図３７Ｄに図示される一般的アーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。
さらに、ＳＭＳＦならびに本明細書に説明される他の方法および機能性は、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用して、本願のＳＭＳＦ等のサービスにアクセスする、Ｍ２Ｍネットワークの一部として実装され得る。
図３７Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。図３７Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２、非取り外し可能メモリ４４、取り外し可能メモリ４６、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２、電源４８、全地球測位システム（ＧＰＳ）チップセット５０、ならびに他の周辺機器５２を含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。
プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を行うために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行い得る。
図３７Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して、他のノードと通信させるために、コンピュータ実行可能命令の実行を通して通信回路を制御し得る。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図３７Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内に一緒に統合され得ることを理解されたい。
伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、他のＭ２Ｍノードから信号を伝送または受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークおよびエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
加えて、伝送／受信要素３６は、単一の要素として図３７Ｃで描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移転もしくは共有のステータスを反映させること、またはユーザからの入力を得るかまたはノードのセッション移転もしくは共有能力もしくは設定についての情報をユーザに表示することを行うように構成され得る。別の例では、ディスプレイはセッション状態に関する情報を示し得る。加えて、ディスプレイ４２は、グラフィカルユーザインターフェースをユーザに提示するために使用され得、例えば、ｏｎｅＭ２Ｍ実施形態に関して前述のＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩの上に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移転もしくは共有を双方向に確立および管理することを可能にし得る。そのようなグラフィカルユーザインターフェースの実施例は、図３８に図示され、以下に説明される。
プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を配信および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。
プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に連結され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の公的な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線あるいは無線コネクティビティを提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
図３７Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。
システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。ディスプレイ８６は、例えば、図３８に図示され、以下に説明される、例示的グラフィカルユーザインターフェースを表示するために使用され得る。
さらに、コンピュータシステム９０は、例えば、図３７Ａおよび図３７Ｂのネットワーク１２等、外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にし得る。
（例示的グラフィカルユーザインターフェース）
図３８はユーザがエンドツーエンドセッション移転ポリシを双方向に構成および管理することを可能にするために実装され得るグラフィカルユーザインターフェース５００の一実施形態を図示する。一実施形態では、このグラフィカルユーザインターフェースは、エンドツーエンドセッションを確立、管理、移転、および共有するための前述の方法の上に層化され得る。図示される実施形態では、グラフィカルユーザインターフェースは、ユーザによって、ポリシを作成（または削除）し、Ｅ２Ｅ Ｍ２Ｍサービス層セッションの移転を統制するために使用され得る。ウィンドウ５０２に示されるように、ユーザは、移転させられるべきセッションコンテキストを選択し得る。ウィンドウ５０４は、移転スケジュールを確立するために使用され得る。窓５０６は、現在のセッションに関連付けられたイベントについての情報を表示するために使用され得る。ウィンドウ５０８は、時間／スケジュールベースの移転またはイベントベースの移転を行うかどうかについて、サービス編成ポリシを設定するために使用され得る。ウィンドウ５１０および５１２は、行われるべき移転の移転元および移転先を識別するために使用され得る。ウィンドウ５１４は、構成ポリシが確立されているＥ２Ｅ Ｍ２Ｍサービス層セッションの識別子ならびにセッションに関連付けられた証明書を入力および／または表示するために使用され得る。ボタン５１６および５１８は、それぞれ、ポリシを作成または削除させるために使用され得る。
種々の実施形態では、グラフィカルユーザインターフェース５００は、例えば、図３７Ａ−３７Ｄの例示的ネットワークのデバイス１８、ゲートウェイ１４、およびサーバ２２、または他の図に図示されるデバイス、ゲートウェイ、もしくはサーバのいずれか等のネットワークのエンドユーザデバイス、端末、ゲートウェイ、またはサーバを含む、Ｍ２Ｍ、ＩｏＴ、またはＷｏＴネットワークの任意の１つ以上のノード上に実装され得る。例えば、グラフィカルユーザインターフェース５００は、図３７Ｃに図示される例示的ネットワークノード３０のディスプレイ４２または図３７Ｄの例示的コンピュータシステム９０のディスプレイ８６上に実装および表示され得る。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイデバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装することを理解されたい。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理的）方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の有形または物理的媒体を含むが、それらに限定されない。
図で図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを目的としている。

Claims (26)

  1. プロセッサ、メモリ、および通信回路を備えているノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ネットワーク内のゲートウェイまたはサーバとして動作し、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、前記ネットワークのサービス層のインスタンスの機能を実施し、
    前記ノードの前記メモリ内にコンテキストを記憶することであって、前記コンテキストは、前記ノードの前記サービス層インスタンスと前記ネットワークに接続されている第２のノード上で実行するアプリケーションとの間で確立されている通信セッションに関する情報を備えている、ことと、
    前記ノードの前記サービス層インスタンスと前記第２のノードの前記アプリケーションとの間の前記通信セッションが第３のノードに移転させられるべきこと、または前記通信セッションが前記第３のノードと共有されるべきことを示すトリガ条件に応答して、前記通信セッションのために記憶されたコンテキストを前記ノードから前記第３のノード上で実行するサービス層インスタンスに伝送することと
    を前記ノードに行わせる、ノード。
  2. 前記トリガ条件は、前記通信セッションが移転させられるべきことを示し、前記記憶されたセッションコンテキストが前記第３のノード上で実行する前記サービス層インスタンスに伝送された後、前記ノードの前記サービス層インスタンスは、前記セッションコンテキストを前記ノードの前記メモリから削除する、請求項１に記載のノード。
  3. 前記通信セッションのために記憶された前記セッションコンテキストは、（ｉ）前記通信セッションの移転または共有が行われるべきスケジュールを規定する情報と、（ｉｉ）前記通信セッションの移転または共有が行われるべきポリシを定義する情報と、（ｉｉｉ）前記通信セッションが移転または共有されるべきことを示す前記トリガ条件をもたらし得るイベントを規定する情報とのうちの１つ以上のものを備えている、請求項１に記載のノード。
  4. 前記通信セッションのために記憶された前記セッションコンテキストは、（ｉ）前記通信セッションに関する通知が伝送されるべき他の通信セッションパーティシパントを識別する情報と、（ｉｉ）前記通信セッションの識別子と、（ｉｉｉ）前記通信セッションのパーティシパントによって使用されるべきセキュリティ証明書と、（ｉｖ）セッションアクティビティに関する情報と、（ｖ）前記通信セッションのパーティシパントへのメッセージのルーティングに関する情報と、（ｖｉ）前記通信セッションへのパーティシパントの場所に関する情報と、（ｖｉｉ）前記通信セッションのパーティシパントの代わりに収集および記憶されるデータと、（ｖｉｉｉ）他のパーティシパントによって前記通信セッションの発見を促進するための情報と、（ｉｘ）前記通信セッションを使用して行われるトランザクションに関連する情報と、（ｘ）前記通信セッションの下にあるアクセスネットワークセッションまたはトランスポート層セッションに関する情報とのうちの１つ以上のものをさらに備えている、請求項３に記載のノード。
  5. 前記セッションコンテキストは、前記ノードの前記サービス層インスタンスによって作成および維持されている１つ以上のリソース内に記憶されている、請求項１に記載のノード。
  6. 前記通信セッションのために記憶された前記コンテキストを前記ノードから前記第３のノード上で実行するサービス層インスタンスに伝送することは、前記通信セッションのために記憶された前記コンテキストを前記ノードから中間ノード上で実行するサービス層インスタンスに伝送することを含み、前記中間ノードは、次いで、前記通信セッションコンテキストを前記第３のノードに転送する、請求項１に記載のノード。
  7. 前記トリガ条件は、前記ノードの前記サービス層インスタンスによって自律的に生成される、請求項１に記載のノード。
  8. 前記トリガ条件は、前記通信セッションのパーティシパントによって生じさせられる、請求項１に記載のノード。
  9. プロセッサ、メモリ、および通信回路を備えているノードであって、前記ノードは、その通信回路を介して通信ネットワークに接続され、前記ネットワーク内のゲートウェイまたはサーバとして動作し、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、前記ネットワークのサービス層のインスタンスの機能を実施し、
    前記ネットワークに接続されている第２のノード上で実行し、第３のノードのサービス層インスタンスとの通信セッションを以前に確立し、前記以前に確立されたセッションに関連付けられた通信セッション識別子が前記第２のノードから受信されているアプリケーションが前記ノードのサービス層インスタンスに登録することに応答して、前記セッション識別子によって識別された前記以前に確立されたセッションが、前記第３のノードの前記サービス層インスタンスから前記ノードの前記サービス層インスタンスに移転させられることができるかどうかを決定することと、
    前記セッション識別子によって識別された前記セッションが前記第３のノードから移転させられることができることが決定された場合、前記ネットワークを介して前記セッションのためのセッションコンテキストを前記第３のノードの前記サービス層インスタンスから読み出すことと、
    前記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストに基づいて、前記第２のノードの前記アプリケーションと前記ノードの前記サービス層インスタンスとの間に前記セッションを再確立することと
    を前記ノードに行わせる、ノード。
  10. 前記第２のノードから受信された前記セッション識別子によって識別された前記セッションが移転させられることができるかどうかを決定することは、前記第２のノードの前記アプリケーションと前記第３のノードの前記サービス層インスタンスとの間の前記以前のセッションについての情報を維持している別のノードのサービス層インスタンスにクエリすることを含む、請求項９に記載のノード。
  11. 前記第２のノードから受信された前記セッション識別子によって識別された前記セッションが移転させられることができるかどうかの決定は、前記第３のノードから読み出される前記セッションコンテキストによって規定されたポリシに基づく、請求項９に記載のノード。
  12. 前記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストは、（ｉ）前記通信セッションの移転または共有が行われるべきスケジュールを規定する情報と、（ｉｉ）前記通信セッションの移転または共有が行われるべきポリシを定義する情報と、（ｉｉｉ）前記通信セッションが移転または共有されることをトリガし得るイベントを規定する情報とのうちの１つ以上のものを備えている、請求項９に記載のノード。
  13. 前記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストは、（ｉ）前記通信セッションに関する通知が伝送されるべき他の通信セッションパーティシパントを識別する情報と、（ｉｉ）前記通信セッションの識別子と、（ｉｉｉ）前記通信セッションのパーティシパントによって使用されるべきセキュリティ証明書と、（ｉｖ）セッションアクティビティに関する情報と、（ｖ）前記通信セッションのパーティシパントへのメッセージのルーティングに関する情報と、（ｖｉ）前記通信セッションへのパーティシパントの場所に関する情報と、（ｖｉｉ）前記通信セッションのパーティシパントの代わりに収集および記憶されるデータと、（ｖｉｉｉ）他のパーティシパントによって前記通信セッションの発見を促進するための情報と、（ｉｘ）前記通信セッションを使用して行われるトランザクションに関連する情報と、（ｘ）前記通信セッションの下にあるアクセスネットワークセッションまたはトランスポート層セッションに関する情報とのうちの１つ以上のものをさらに備えている、請求項１２に記載のノード。
  14. ネットワーク内のゲートウェイまたはサーバとして動作するノードによる使用のための方法であって、前記ノードは、プロセッサ、メモリ、および通信回路を備え、前記ノードは、その通信回路を介して前記ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、前記ネットワークのサービス層のインスタンスの機能を実施し、前記方法は、
    前記ノードの前記メモリ内にコンテキストを記憶することであって、前記コンテキストは、前記ノードの前記サービス層インスタンスと前記ネットワークに接続されている第２のノード上で実行するアプリケーションとの間で確立されている通信セッションに関する情報を備えている、ことと、
    前記ノードの前記サービス層インスタンスと前記第２のノードの前記アプリケーションとの間の前記通信セッションが第３のノードに移転させられるべきこと、または前記通信セッションが前記第３のノードと共有されるべきことを示すトリガ条件に応答して、前記通信セッションのために記憶された前記コンテキストを前記ノードから前記第３のノード上で実行するサービス層インスタンスに伝送することと、
    を含む、方法。
  15. 前記トリガ条件は、前記通信セッションが移転させられるべきことを示し、前記方法は、
    前記記憶されたセッションコンテキストを前記第３のノード上で実行する前記サービス層インスタンスに伝送後、前記セッションコンテキストを前記ノードの前記メモリから削除することをさらに含む、請求項１４に記載の方法。
  16. 前記通信セッションのために記憶された前記セッションコンテキストは、（ｉ）前記通信セッションの移転または共有が行われるべきスケジュールを規定する情報と、（ｉｉ）前記通信セッションの移転または共有が行われるべきポリシを定義する情報と、（ｉｉｉ）前記通信セッションが移転または共有されるべきことを示す前記トリガ条件をもたらし得るイベントを規定する情報とのうちの１つ以上のものを備えている、請求項１４に記載の方法。
  17. 前記通信セッションのために記憶されたセッションコンテキストは、（ｉ）前記通信セッションに関する通知が伝送されるべき他の通信セッションパーティシパントを識別する情報と、（ｉｉ）前記通信セッションの識別子と、（ｉｉｉ）前記通信セッションのパーティシパントによって使用されるべきセキュリティ証明書と、（ｉｖ）セッションアクティビティに関する情報と、（ｖ）前記通信セッションのパーティシパントへのメッセージのルーティングに関する情報と、（ｖｉ）前記通信セッションへのパーティシパントの場所に関する情報と、（ｖｉｉ）前記通信セッションのパーティシパントの代わりに収集および記憶されるデータと、（ｖｉｉｉ）他のパーティシパントによって前記通信セッションの発見を促進するための情報と、（ｉｘ）前記通信セッションを使用して行われるトランザクションに関連する情報と、（ｘ）前記通信セッションの下にあるアクセスネットワークセッションまたはトランスポート層セッションに関する情報とのうちの１つ以上のものをさらに備えている、請求項１６に記載の方法。
  18. 前記セッションコンテキストは、前記ノードの前記サービス層インスタンスによって作成および維持されている１つ以上のリソース内に記憶されている、請求項１４に記載の方法。
  19. 前記通信セッションのために記憶された前記コンテキストを前記ノードから前記第３のノード上で実行するサービス層インスタンスに伝送することは、前記通信セッションのために記憶された前記コンテキストを前記ノードから中間ノード上で実行するサービス層インスタンスに伝送することを含み、前記中間ノードは、次いで、前記通信セッションコンテキストを前記第３のノードに転送する、請求項１４に記載の方法。
  20. 前記トリガ条件は、前記ノードの前記サービス層インスタンスによって自律的に生成される、請求項１４に記載の方法。
  21. 前記トリガ条件は、前記通信セッションのパーティシパントによって生じさせられる、請求項１４に記載の方法。
  22. ネットワーク内のゲートウェイまたはサーバとして動作するノードによる使用のための方法であって、前記ノードは、プロセッサ、メモリ、および通信回路を備え、前記ノードは、その通信回路を介して前記ネットワークに接続され、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、前記ネットワークのサービス層のインスタンスの機能を実施し、前記方法は、
    前記ネットワークに接続されている第２のノード上で実行し、第３のノードのサービス層インスタンスとの通信セッションを以前に確立し、前記以前に確立されたセッションに関連付けられた通信セッション識別子が前記第２のノードから受信されているアプリケーションが前記ノードのサービス層インスタンスに登録することに応答して、前記セッション識別子によって識別された前記以前に確立されたセッションが、前記第３のノードの前記サービス層インスタンスから前記ノードの前記サービス層インスタンスに移転させられることができるかどうかを決定することと、
    前記セッション識別子によって識別された前記セッションが前記第３のノードから移転させられることができることが決定された場合、前記ネットワークを介して前記セッションのためのセッションコンテキストを前記第３のノードの前記サービス層インスタンスから読み出すことと、
    記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストに基づいて、前記第２のノードの前記アプリケーションと前記ノードの前記サービス層インスタンスとの間に前記セッションを再確立することと
    を含む、方法。
  23. 前記第２のノードから受信された前記セッション識別子によって識別された前記セッションが移転させられることができるかどうかを決定することは、前記第２のノードの前記アプリケーションと前記第３のノードの前記サービス層インスタンスとの間の前記以前のセッションについての情報を維持している別のノードのサービス層インスタンスにクエリすることを含む、請求項２２に記載の方法。
  24. 前記第２のノードから受信された前記セッション識別子によって識別された前記セッションが移転させられることができるかどうかの決定は、前記第３のノードから読み出される前記セッションコンテキストによって規定されたポリシに基づく、請求項２２に記載の方法。
  25. 前記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストは、（ｉ）前記通信セッションの移転または共有が行われるべきスケジュールを規定する情報と、（ｉｉ）前記通信セッションの移転または共有が行われるべきポリシを定義する情報と、（ｉｉｉ）前記通信セッションが移転または共有されることをトリガし得るイベントを規定する情報とのうちの１つ以上のものを備えている、請求項２２に記載の方法。
  26. 前記第３のノードの前記サービス層インスタンスから読み出される前記セッションコンテキストは、（ｉ）前記通信セッションに関する通知が伝送されるべき他の通信セッションパーティシパントを識別する情報と、（ｉｉ）前記通信セッションの識別子と、（ｉｉｉ）前記通信セッションのパーティシパントによって使用されるべきセキュリティ証明書と、（ｉｖ）セッションアクティビティに関する情報と、（ｖ）前記通信セッションのパーティシパントへのメッセージのルーティングに関する情報と、（ｖｉ）前記通信セッションへのパーティシパントの場所に関する情報と、（ｖｉｉ）前記通信セッションのパーティシパントの代わりに収集および記憶されるデータと、（ｖｉｉｉ）他のパーティシパントによって前記通信セッションの発見を促進するための情報と、（ｉｘ）前記通信セッションを使用して行われるトランザクションに関連する情報と、（ｘ）前記通信セッションの下にあるアクセスネットワークセッションまたはトランスポート層セッションに関する情報とのうちの１つ以上のものをさらに備えている、請求項２５に記載の方法。
JP2017515070A 2014-09-19 2015-09-18 サービス層セッション移転および共有 Active JP6335388B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462052535P 2014-09-19 2014-09-19
US62/052,535 2014-09-19
PCT/US2015/050929 WO2016044718A1 (en) 2014-09-19 2015-09-18 Service layer session migration and sharing

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018086874A Division JP6563555B2 (ja) 2014-09-19 2018-04-27 サービス層セッション移転および共有

Publications (2)

Publication Number Publication Date
JP2017535838A true JP2017535838A (ja) 2017-11-30
JP6335388B2 JP6335388B2 (ja) 2018-05-30

Family

ID=54238615

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2017515070A Active JP6335388B2 (ja) 2014-09-19 2015-09-18 サービス層セッション移転および共有
JP2018086874A Active JP6563555B2 (ja) 2014-09-19 2018-04-27 サービス層セッション移転および共有

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2018086874A Active JP6563555B2 (ja) 2014-09-19 2018-04-27 サービス層セッション移転および共有

Country Status (6)

Country Link
US (5) US10367896B2 (ja)
EP (2) EP3195571B1 (ja)
JP (2) JP6335388B2 (ja)
KR (4) KR102360767B1 (ja)
CN (2) CN107079050B (ja)
WO (1) WO2016044718A1 (ja)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10649424B2 (en) * 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
KR102360767B1 (ko) * 2014-09-19 2022-02-14 콘비다 와이어리스, 엘엘씨 서비스 레이어 세션 마이그레이션 및 공유
EP3289476B1 (en) 2015-04-30 2022-01-26 Fortinet, Inc. Computer network security system
US10419540B2 (en) * 2015-10-05 2019-09-17 Microsoft Technology Licensing, Llc Architecture for internet of things
US10306016B2 (en) 2016-02-01 2019-05-28 General Electric Company System and method for scoped attributes
US10534746B2 (en) * 2016-05-09 2020-01-14 Droplit, Inc. System and method for defining machine-to-machine communicating devices and defining and distributing computational tasks among same
CN111884827B (zh) * 2016-08-26 2021-10-15 华为技术有限公司 一种sfc网络中同步拓扑信息的方法及路由网元
CN109792457B (zh) * 2016-09-29 2021-11-26 康维达无线有限责任公司 存储和检索设备的网络上下文
WO2018072851A1 (en) * 2016-10-21 2018-04-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for facilitating real time multimedia communications
US10942907B2 (en) 2016-11-04 2021-03-09 Oracle International Corporation Safe release of database sessions for planned maintenance operations
EP3515031B1 (en) * 2016-11-14 2021-04-07 Huawei Technologies Co., Ltd. Session processing method, apparatus and system
US20180139090A1 (en) * 2016-11-15 2018-05-17 John Geiger Method for secure enrollment of devices in the industrial internet of things
CN108112007B (zh) * 2016-11-25 2020-08-11 京东方科技集团股份有限公司 信息通知方法、装置及***
JP2020031247A (ja) * 2016-12-19 2020-02-27 シャープ株式会社 通信システムおよび通信装置
US12007941B2 (en) * 2017-09-29 2024-06-11 Oracle International Corporation Session state tracking
KR102071315B1 (ko) * 2017-12-05 2020-01-30 서울대학교산학협력단 서비스 지향 사물 인터넷 플랫폼 및 그 제어 방법
CN110049070B (zh) * 2018-01-15 2021-09-14 华为技术有限公司 事件通知方法及相关设备
EP3750073B1 (en) * 2018-02-08 2023-04-05 Telefonaktiebolaget LM Ericsson (publ) A method for seamless migration of session authentication to a different stateful diameter authenticating peer
US10826941B2 (en) 2018-05-10 2020-11-03 Fortinet, Inc. Systems and methods for centrally managed host and network firewall services
WO2019246402A1 (en) * 2018-06-20 2019-12-26 Convida Wireless, Llc Automated iot device configuration using user profile
WO2020149963A1 (en) * 2019-01-16 2020-07-23 Convida Wireless, Llc Automated service layer message flow management in a communications network
US11971896B2 (en) * 2019-08-15 2024-04-30 Telepathy Labs, Inc. System and method for querying multiple data sources
US11637745B2 (en) 2019-09-11 2023-04-25 Hand Held Products, Inc. Configuring a remote electronic device by a peer electronic device in a networked environment
US11936739B2 (en) 2019-09-12 2024-03-19 Oracle International Corporation Automated reset of session state
US11687507B2 (en) 2019-09-12 2023-06-27 Oracle International Corporation Termination of database sessions for planned failover
EP4025012A4 (en) * 2019-11-07 2022-09-07 Samsung Electronics Co., Ltd. METHOD AND APPARATUS FOR PROVIDING SERVICE IN A WIRELESS COMMUNICATION SYSTEM
KR20210128096A (ko) * 2020-04-16 2021-10-26 세종대학교산학협력단 사물인터넷 플랫폼 간 연동 방법 및 장치
WO2022019816A1 (en) * 2020-07-23 2022-01-27 Telefonaktiebolaget Lm Ericsson (Publ) Procedure for transferring an active group communication session between group communication servers
WO2022226446A1 (en) * 2021-04-23 2022-10-27 Citrix Systems, Inc. Computing system and related methods providing multiple endpoint connections based upon connection leases
US20230108145A1 (en) * 2021-10-04 2023-04-06 UiPath, Inc. Cloud migration
WO2023150721A1 (en) * 2022-02-04 2023-08-10 Intel Corporation Sixth generation (6g) mutual transport layer security (mtls) based security architecture between user equipment (ue) and 6g network
CN116319949B (zh) * 2022-12-19 2023-11-14 北京开科唯识技术股份有限公司 会话迁移方法、装置、终端设备及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001127772A (ja) * 1999-10-28 2001-05-11 Yrp Mobile Telecommunications Key Tech Res Lab Co Ltd Ａｔｍネットワークシステム、その集中制御局およびａｔｍスイッチ
JP2004235883A (ja) * 2003-01-29 2004-08-19 Ntt Docomo Inc ハンドオーバー方法、無線通信システム及び基地局
JP2006042001A (ja) * 2004-07-28 2006-02-09 Mitsubishi Electric Corp 移動端末、アクセス集線装置およびサーバ
JP2009212892A (ja) * 2008-03-05 2009-09-17 Panasonic Corp 移動端末及び接続局装置
US20100015980A1 (en) * 2006-05-31 2010-01-21 Softbank Bb Corp. Mobile Terminal and Communication Method
WO2010109547A1 (ja) * 2009-03-27 2010-09-30 富士通株式会社 マルチキャストデータ通信方法及び通信システム
JP2011524685A (ja) * 2008-06-13 2011-09-01 クゥアルコム・インコーポレイテッド ハンドオフ中のパーソナリティ修正のための装置および方法
JP2012504354A (ja) * 2008-09-29 2012-02-16 ノーテル・ネットワークス・リミテッド ギガビット無線送信
JP2012524424A (ja) * 2009-04-17 2012-10-11 パナソニック株式会社 移動通信システムにおけるローカルデバイスアクセスの管理装置
JP2013172407A (ja) * 2012-02-22 2013-09-02 Fujitsu Ltd リソース管理装置およびリソース管理方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2345661A1 (en) * 1998-10-02 2000-04-13 International Business Machines Corporation Conversational browser and conversational systems
US6714987B1 (en) * 1999-11-05 2004-03-30 Nortel Networks Limited Architecture for an IP centric distributed network
US6684251B1 (en) * 2000-05-25 2004-01-27 Sprint Communications Company, L.P. Dynamic connection set-up in a communication network
GB2368225B (en) * 2000-10-17 2003-12-10 Hewlett Packard Co Inviting assistant entity into a network communication session
US8244864B1 (en) * 2001-03-20 2012-08-14 Microsoft Corporation Transparent migration of TCP based connections within a network load balancing system
CN100456247C (zh) * 2002-12-26 2009-01-28 捷讯研究有限公司 用于建立无线组件应用的方法、移动通信装置和服务器
US7441000B2 (en) * 2003-12-22 2008-10-21 International Business Machines Corporation Method for session sharing
US8166176B2 (en) * 2006-05-31 2012-04-24 Alcatel Lucent Context-aware migration of communication session
US7856226B2 (en) * 2007-04-17 2010-12-21 Aylus Networks, Inc. Systems and methods for IMS user sessions with dynamic service selection
EP2045959B1 (en) * 2007-10-03 2011-07-20 Accenture Global Services Limited Technology agnostic universally appliable data model for a telecommunication service provider archtitecture
EP2232414A4 (en) * 2007-12-19 2011-05-04 Linda Seah INLAYS WITHOUT CONTACT AND WITH DOUBLE INTERFACE AND METHOD OF MANUFACTURING THE SAME
US8401022B2 (en) 2008-02-08 2013-03-19 Oracle International Corporation Pragmatic approaches to IMS
US20110029999A1 (en) * 2009-07-29 2011-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Policies transfer for session transfer
US9246953B2 (en) * 2009-11-19 2016-01-26 Oracle International Corporation Protocol level communications for protocol level composition with session sharing
KR20120117996A (ko) * 2009-12-09 2012-10-25 인터디지탈 패튼 홀딩스, 인크 세션 복제 및 세션 공유를 위한 방법 및 장치
US8966094B2 (en) * 2009-12-31 2015-02-24 Telefonaktiebolaget L M Ericsson (Publ) Managing session data of a composite service session in a communication network
US8990413B2 (en) * 2010-02-05 2015-03-24 Oracle International Corporation Service level cross network coordinated interaction
US8856317B2 (en) * 2010-07-15 2014-10-07 Cisco Technology, Inc. Secure data transfer in a virtual environment
US9699274B2 (en) * 2011-07-25 2017-07-04 Alcatel Lucent Method and apparatus for reliable session migration
US9497102B2 (en) * 2011-12-06 2016-11-15 Qualcomm Incorporated Systems and methods for machine to machine device control and triggering
US20130219043A1 (en) * 2012-02-20 2013-08-22 Moritz M. Steiner Method and apparatus for automatic migration of application service
JP5680006B2 (ja) * 2012-02-24 2015-03-04 株式会社日立製作所 無線通信システム及び方法、ゲートウェイ
US9106481B2 (en) * 2012-03-29 2015-08-11 Intel Corporation Device-to-device tapping service layer
US8948001B2 (en) * 2012-06-26 2015-02-03 Juniper Networks, Inc. Service plane triggered fast reroute protection
US9100236B1 (en) * 2012-09-30 2015-08-04 Juniper Networks, Inc. TCP proxying of network sessions mid-flow
CN103841142B (zh) * 2012-11-23 2017-06-20 华为技术有限公司 一种会话迁移的方法、装置及***
WO2015084230A1 (en) * 2013-12-03 2015-06-11 Telefonaktiebolaget L M Ericsson (Publ) A first service network node, a second service network node and methods relating to handling of a service session
US9661027B2 (en) * 2014-09-11 2017-05-23 At&T Intellectual Property I, L.P. Informational enrichment for interactive systems
KR102360767B1 (ko) * 2014-09-19 2022-02-14 콘비다 와이어리스, 엘엘씨 서비스 레이어 세션 마이그레이션 및 공유

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001127772A (ja) * 1999-10-28 2001-05-11 Yrp Mobile Telecommunications Key Tech Res Lab Co Ltd Ａｔｍネットワークシステム、その集中制御局およびａｔｍスイッチ
JP2004235883A (ja) * 2003-01-29 2004-08-19 Ntt Docomo Inc ハンドオーバー方法、無線通信システム及び基地局
JP2006042001A (ja) * 2004-07-28 2006-02-09 Mitsubishi Electric Corp 移動端末、アクセス集線装置およびサーバ
US20100015980A1 (en) * 2006-05-31 2010-01-21 Softbank Bb Corp. Mobile Terminal and Communication Method
JP2009212892A (ja) * 2008-03-05 2009-09-17 Panasonic Corp 移動端末及び接続局装置
JP2011524685A (ja) * 2008-06-13 2011-09-01 クゥアルコム・インコーポレイテッド ハンドオフ中のパーソナリティ修正のための装置および方法
JP2012504354A (ja) * 2008-09-29 2012-02-16 ノーテル・ネットワークス・リミテッド ギガビット無線送信
WO2010109547A1 (ja) * 2009-03-27 2010-09-30 富士通株式会社 マルチキャストデータ通信方法及び通信システム
JP2012524424A (ja) * 2009-04-17 2012-10-11 パナソニック株式会社 移動通信システムにおけるローカルデバイスアクセスの管理装置
JP2013172407A (ja) * 2012-02-22 2013-09-02 Fujitsu Ltd リソース管理装置およびリソース管理方法

Also Published As

Publication number Publication date
JP2018147507A (ja) 2018-09-20
US20240121312A1 (en) 2024-04-11
EP3195571B1 (en) 2021-05-05
EP3913896A2 (en) 2021-11-24
KR102360767B1 (ko) 2022-02-14
US20210297493A1 (en) 2021-09-23
EP3195571A1 (en) 2017-07-26
KR20210124533A (ko) 2021-10-14
KR20210002132A (ko) 2021-01-06
JP6563555B2 (ja) 2019-08-21
JP6335388B2 (ja) 2018-05-30
US20220337667A1 (en) 2022-10-20
US10367896B2 (en) 2019-07-30
EP3913896B1 (en) 2024-07-03
CN107079050A (zh) 2017-08-18
KR20170056013A (ko) 2017-05-22
CN107079050B (zh) 2020-11-03
KR101984120B1 (ko) 2019-09-03
KR102198229B1 (ko) 2021-01-04
KR20190060010A (ko) 2019-05-31
US11888942B2 (en) 2024-01-30
CN112217905A (zh) 2021-01-12
US20190297149A1 (en) 2019-09-26
WO2016044718A1 (en) 2016-03-24
EP3913896A3 (en) 2022-02-09
US11064033B2 (en) 2021-07-13
KR102311627B1 (ko) 2021-10-13
US20170289271A1 (en) 2017-10-05
US11418602B2 (en) 2022-08-16
CN112217905B (zh) 2024-03-29

Similar Documents

Publication Publication Date Title
JP6563555B2 (ja) サービス層セッション移転および共有
US11765150B2 (en) End-to-end M2M service layer sessions

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180320

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180329

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180427

R150 Certificate of patent or registration of utility model

Ref document number: 6335388

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250