JP2018521589A - サービス層エニキャストおよびサムキャスト - Google Patents

Abstract

サムキャスト／エニキャストサービスは、サービス層において機能し、サービスノード／グループ選択および選択後処理を含み得る。サムキャスト／エニキャスト情報は、サムキャスト／エニキャストの異なるシナリオを識別し、サービスノード選択を促進し、再伝送をハンドリングするために使用され得る。一実施形態において、方法は、サービス層プラットフォーム内でサムキャストすることを示す第１の要求メッセージを受信することと、要求メッセージ内の選択基準に基づいて、標的ノードを決定することと、所望の動作を行うための第２の要求メッセージを標的ノードに送信することとを含む。

Description

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

（Ｍ２Ｍサービス層）
プロトコルスタック観点から、サービス層は、典型的には、アプリケーションプロトコル層の上に層化され、付加価値サービスをクライアントアプリケーションに提供する。故に、サービス層は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図１は、ＩＰネットワークスタック１０２とアプリケーション１０３との間にある例示的サービス層１０１を示す。

ネットワーク内のサービス層インスタンスの例示的展開シナリオが、図２に示される。図２では、サービス層インスタンス１０５は、例えば、種々のネットワークノード（ゲートウェイおよびサーバ）上に展開されて示され、ネットワークアプリケーションドメイン１０６内で見つけられるネットワークアプリケーション、デバイスアプリケーションドメイン１０７内で見つけられるデバイスアプリケーション、およびネットワークサービスドメイン１０８内で見つけられるネットワークノードに付加価値サービスを提供する。サービス層インスタンス１０５は、サービス層の実現である。

Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを特に目標としたサービス層の１つのタイプの例である。産業規格団体（例えば、ｏｎｅＭ２Ｍ−ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｅｔｅｃｔｕｒｅ，ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｅｔｅｃｔｕｒｅ−Ｖ−２．１．０）は、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍ／ＩｏＴサービス層を開発している。Ｍ２Ｍサービス層は、アサービス層によってサポートされるＭ２Ｍ中心能力の集合へのアクセスをプリケーションおよびデバイスに提供することができる。いくつかの例として、セキュリティ、請求、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用する、ＡＰＩを介して、アプリケーションに利用可能になる。

ｏｎｅＭ２Ｍは、共通Ｍ２Ｍサービス層の必要性に対処する、技術仕様を開発しており、共通Ｍ２Ｍサービス層は、種々のハードウェアおよびソフトウェア内に容易に埋め込まれ、実際に使用されている多種多様なデバイスを世界規模でＭ２Ｍアプリケーションサーバに接続するために依拠されることができる。

ｏｎｅＭ２Ｍ共通サービス層は、図３に示されるように、共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）（例えば、ＣＳＥ１１１）と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上にホストされることができる。

ｏｎｅＭ２Ｍは、２つのアーキテクチャアプローチにおいてサービス層を開発しており、それらは、リソース指向アーキテクチャ（ＲｏＡ）（例えば、図４）、サービス指向アーキテクチャ（ＳｏＡ）（例えば、図５）と称される。ｏｎｅＭ２Ｍ ＲｏＡ ＲＥＳＴｆｕｌアーキテクチャによると、ＣＳＦは、「リソース」の組として表される。リソースは、作成、読み出し、更新、および削除（ＣＲＵＤ）等のＲＥＳＴｆｕｌ方法を介して操作され得る表現を有するアーキテクチャ内の一意にアドレス可能な要素である。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能にされる。リソースは、子リソースと、属性とを含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親リソースの寿命によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。

ＳｏＡアーキテクチャは、ＲＥＳＴｆｕｌベースではないレガシー展開を検討するために開発されている。それは、概して、図５に示されるように、同じサービス層アーキテクチャを再使用する。サービス層は、種々のＭ２Ｍサービスを含み、複数のサービスは、サービスコンポーネントにグループ化されることができる。既存の参照点に加えて、それは、サービス間参照点Ｍｓｃを導入している。Ｍｓｃ参照点を経由してパスされるＭ２Ｍサービスコンポーネント間の通信は、ウェブサービスアプローチ、例えば、ウェブサービスメッセージ交換パターン（ＭＥＰ）を利用する。

（ｏｎｅＭ２Ｍにおけるグループ管理）
ｏｎｅＭ２Ｍ内には、グループ関連動作をハンドリングすることに責任があるグループ管理（ＧＭＧ）ＣＳＦが存在する。ＧＭＧは、以下の動作をハンドリングし得る。
・ グループおよび関連付けられたグループメンバの作成、読み出し、更新、および削除するために要求すること。
・ 特定の目的（例えば、アクセス制御、デバイス管理、デバイスのグループに対するファンアウト共通動作等の促進）のために、ｏｎｅＭ２Ｍシステム内のノードにおけるＣＳＥにおいて１つ以上のグループを作成すること。
・ グループメンバシップを管理し、メンバをグループメンバリストに追加こと、およびそこから除去することを行うための要求をハンドリングすること。
・ ＧＭＧ ＣＳＦサービス機能によってサポートされる機能性を充足するために、他のＣＳＦの能力を活用すること。例として、認証および承認のためのセキュリティＣＳＦが挙げられる。
・ 要求をグループ内の全メンバに転送すること。グループが別のグループをメンバとして含む場合、転送プロセスは、反復的に行われる。ＧＭＧ ＣＳＦは、グループメンバからの対応する応答を集約することによって、集約された応答を生成すること。
・ 個々のグループへのサブスクリプションをサポートする。
・ ブロードキャスト／マルチキャストを含む下層ネットワークの既存の能力を活用すること。

図６は、グループ管理のためにｏｎｅＭ２Ｍによって定義された＜ｇｒｏｕｐ＞リソースを図示する。仮想リソース＜ｆａｎＯｕｔＰｏｉｎｔ＞は、特定の要求をグループメンバの各々に配信するように定義される。図７は、＜ｇｒｏｕｐ＞リソースのための例示的方法フローである。図８は、＜ｆａｎＯｕｔＰｏｉｎｔ＞リソースのための例示的方法フローを図示する。

サムキャスト／エニキャストサービスは、サービス層において機能し、サービスノード／グループ選択および選択後処理を含み得る。サムキャスト／エニキャスト情報は、エニキャスト／サムキャストの異なるシナリオを識別し、サービスノード選択を促進し、再伝送をハンドリングするために使用され得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。

より詳細な理解は、付随の図面と併せて、一例として与えられる、以下の説明から得られ得る。
図１は、ＩＰネットワーキングスタックとアプリケーションとの間の例示的サービス層を図示する。 図２は、ネットワーク内のサービス層インスタンスの例示的展開シナリオを図示する。 図３は、共通サービス機能を伴う例示的ｏｎｅＭ２Ｍ共通サービス層を図示する。 図４は、例示的ｏｎｅＭ２Ｍサービス層機能的アーキテクチャを図示する。 図５は、例示的ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャを図示する。 図６は、グループ管理のためにｏｎｅＭ２Ｍによって定義された例示的＜ｇｒｏｕｐ＞リソースを図示する。 図７は、＜ｇｒｏｕｐ＞リソース上の例示的プロシージャ（ＣＲＵＤＮ）を図示する。 図８は、＜ｆａｎＯｕｔＰｏｉｎｔ＞リソース上の例示的プロシージャ（ＣＲＵＤＮ）を図示する。 図９は、インターネットプロトコル層における例示的エニキャストを図示する。 図１０は、インターネットプロトコル層における例示的サムキャストを図示する。 図１１は、例示的グループ動作を図示する。 図１２は、例示的グループ動作を図示する。 図１３は、サムキャスト／エニキャストサービスの例示的アーキテクチャを図示する。 図１４は、メッセージ前処理のための例示的方法を図示する。 図１５は、サービス層における非グループベースのエニキャスト／サムキャストのための例示的方法フローを図示する。 図１６Ａは、グループ選択が行われない例示的方法フローを図示する。 図１６Ｂは、グループ選択が行われる例示的方法フローを図示する。 図１７は、再伝送動作を行うための例示的オプションを図示する。 図１８は、ｏｎｅＭ２Ｍ機能的アーキテクチャに基づくＳＬサムキャスト／エニキャストＣＳＦとしてのサムキャスト／エニキャストサービスの例示的実装を図示する。 図１９は、ｏｎｅＭ２Ｍグループ管理等のための例示的サムキャスト／エニキャスト方法フローを図示する。 図２０は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ内のＳＡＳの例示的実装アーキテクチャを図示する。 図２１は、エニキャスト／サムキャストのための例示的サービス相互作用を図示する。 図２２は、サムキャスト／エニキャストサービスを利用するための例示的ユーザインターフェースを図示する。 図２３Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）の通信システムの系統図である。 図２３Ｂは、図２３Ａに例証されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２３Ｃは、図２３Ａに例証される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２３Ｄは、図２３Ａの通信システムの側面が実施され得る、例示的コンピューティングシステムのブロック図である。

本明細書に開示されるのは、サービス層エニキャストおよびサムキャストのための概念である。サムキャスト／エニキャストサービス（ＳＡＳ）は、とりわけ、サービスノード／グループ選択および選択後処理を提供する。本明細書に開示されるようなＳＡＳは、下層トランスポートネットワークまたは下層ルーティングプロトコルによって提供されるエニキャストおよび／またはサムキャストを使用せずに、サービス層におけるグループ管理を伴って、または伴わずに、エニキャストおよび／またはサムキャスト通信を可能にし、サポートすることに役立ち得る。

図９は、ＩＰ層におけるエニキャスト通信を図示する。ＩＰ層におけるエニキャストは、全て同一宛先アドレスによって識別されるいくつかのノードに送信され得るネットワークアドレス指定およびルーティング方法論であり、単一送信側からのデータグラムが、潜在的受信側のグループ内のトポグラフィ上最近傍ノードにルーティングされる。インターネットにおいて、エニキャストは、通常、境界ゲートウェイプロトコル（ＢＧＰ）を使用して、単一サービスアドレスにおける複数のノードの到達可能性をアナウンスすることによって実装される。この範囲内の宛先アドレスにアドレス指定されるパケットは、所与の宛先ＩＰアドレスをアナウンスするネット上の「最近傍」ポイントにルーティングされ得る。インターネットの成長に伴って、ネットワークサービスは、エニキャストの高利用可能性要件をますます有する。ＩＥＴＦ ＲＦＣ４７８６「Ｏｐｅｒａｔｉｏｎ ｏｆ ａｎｙｃａｓｔ ｓｅｒｖｉｃｅｓ」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４７８６）は、ネットワークオペレータのためにエニキャストを使用して分散型サービスを展開または動作させるための現在の実践として動作している。エニキャストは、サービスをネットワーク内で分散させることによって、あるレベルの負荷バランシングを提供し得る。

図１０は、ＩＰ層におけるサムキャストを図示する。サムキャスト（例えば、ＩＥＴＦ Ｄｒａｆｔ，ＩＰｖ４ ｏｐｔｉｏｎ ｆｏｒ ｓｏｍｅｃａｓｔ，２０００）は、パケットが宛先の組に送信されることを可能にするマルチポイント配信技術である。サムキャスト配信では、ネットワークは、パケットの１つのコピーをパケット内にリストアップされた各宛先に配信する。サムキャストは、マルチメディア会議およびマルチプレーヤゲーム等の小規模マルチユーザセッションにおいて使用されるか、またはより大きい規模のセッションのためのエンドホストマルチキャストと共に使用され得る。

ＩＰサムキャストは、アドレス指定スキームの観点からのマルチキャストの手段である。ＩＰマルチキャストは、インターネットプロトコル（ＩＰ）データグラムを関心受信側のグループに単一伝送において送信する方法である。ＩＰマルチキャストは、ネットワーク内のＩＰインフラストラクチャを経由した１対多および多対多のリアルタイム通信のための技法である。ＩＰマルチキャストにおける重要な概念として、ＩＰマルチキャストグループアドレス、マルチキャスト分散ツリー、および受信側駆動ツリー作成が挙げられる。ＩＰマルチキャストグループアドレスは、ソースおよび受信側によって、マルチキャストメッセージを送信および受信するために使用される。

図１１は、サービス層エニキャストを使用するグループ動作から利益を享受し得る、例示的使用例を図示する。サービスプロバイダは、温度センサ１１５および温度センサ１１７等の多くの温度センサを分散させ、リアルタイム温度読み取りをサービスとして提供し得る。容易な管理および構成、例えば、ソフトウェア更新およびセキュリティ構成のために、グループが、形成され得、図１１のセンサ（例えば、とりわけ、温度センサ１１５、温度センサ１１７）は、サービスプロバイダによってグループとして管理され得る。例示的従来のシナリオでは、ステップ１２１では、サービス層クライアント１１８は、温度センサの中でもとりわけ、温度センサ１１５、温度センサ１１７が展開される、エリア１１６に関する温度読み取り値を読み出す要求を送信し得る。従来のサービス層グループ管理機構に基づいて、ステップ１２２では、グループホスティングノード１１９は、ステップ１２１の要求を、とりわけ、各温度センサ１１５、温度センサ１１７（すなわち、個々に、各グループメンバ）に転送する。ステップ１２３では、各温度センサは、ステップ１２２の要求に応答して、それぞれ、温度読み取り値で応答を返す。ステップ１２４では、各応答は、サービス層クライアント１１８に返される。

図１１の議論を継続して参照すると、サービス層エニキャストを伴わない従来のグループ動作は、不必要データフロー（例えば、各センサにおける通信オーバーヘッドおよび動作オーバーヘッド）ならびに冗長温度読み取りにつながり得る。加えて、必要以上のメッセージ（要求／応答）が存在し得る。１つのセンサから報告される最も可能性が高い温度データで十分であり、サービス層クライアント１１８は、エリア１１６内の任意の温度センサ（例えば、温度センサ１１５または温度センサ１１７）を容認可能と判断し得る。このシナリオでは、温度センサは、互いに近くに位置し得、全センサが似た感知能力を有すると仮定すると、同一または非常に似た温度読み取り値を提供し得る。

サービス層エニキャストは、本明細書に議論されるように、サービス層動作（例えば、ＣＲＵＤ）を行うためのサービス層通信である。要約すると、発信元（例えば、サービス層クライアント１１８）は、サービス層ノード（例えば、エリア１１６内の温度センサ）のグループを標的にして、または標的にせずに、要求メッセージをレジストラノード（例えば、グループホスティングノード１１９）に送信する。動作は、複数の資格要件を満たしたサービスノードのうちの１つによって行われ、発信元は、どのサービスノードが動作を行うかを気にしないか、またはそれを認知しないこともある。例示的タイプのサービス層エニキャストは、グループベースのエニキャストおよび非グループベースのエニキャストを含む。グループベースのエニキャストでは、発信元は、レジストラノードが所望の動作を行うための規定されたグループ（例えば、エリア１１６）のメンバから１つのサービスノードを選択し得るように、グループ情報（例えば、グループＩＤ、＜ｇｒｏｕｐ＞リソースのＵＲＩ）を明示的に規定し得る。非グループベースのエニキャストでは、発信元は、任意のグループ情報を明示的に規定しないこともあり、代わりに、いくつかの条件をメッセージ内に提供し得る（例えば、場所情報、アクセス権要件）。レジストラノードは、サービスノードの範囲を決定し、条件に基づいて、サービスノードを選択し得る。

図１２は、照明の従来のグループ動作がサービス層サムキャストを使用することによって利益を享受し得る使用例の例を図示する。ここでは、携帯電話は、居間１３６内のｎ個の照明（例えば、とりわけ、照明１３３および照明１３４）を遠隔で制御するアプリケーション１３１を含む。居間１３６のｎ個の照明は、サービス層における管理のために一緒にグループ化され得る。居間１３６内の照明のグループは、アプリケーション１３１を介して、居間１３６内の照明のオン／オフおよび居間１３６内の照明の輝度の調節等の動作を行うように制御され得る。あるシナリオでは、居間１３６内の全照明をオンにする必要はない場合があり、居間１３６内の照明の一部をオンにするだけで十分に良好である。光度計等によって検出され得る所望のレベルの輝度を提供する限り、居間１３６内のどの照明がオンにされるかは問題ではないこともある。

図１２を継続して参照すると、アプリケーションは、要求をグループホスティングノード１３２（例えば、ＩＮ−ＣＳＥ）に送信し、グループ内の３つの照明をオンにする（ステップ１３７）。しかしながら、既存のサービス層グループ管理機構に基づいて、グループホスティングノード１３２は、ステップ１３７の要求メッセージをグループ内の各照明に転送する（ステップ１３８）。居間１３６内の各照明は、オンにされ、応答を動作結果とともにグループホスティングノードに個々に返し得る（ステップ１３９）。従来のグループ動作は、その他をオフに保ったままで３つの照明をオンにせず、それは、とりわけ、不必要なエネルギー消費および冗長メッセージ交換につながり得る。本明細書に開示されるようなＳＡＳは、下層トランスポートネットワークまたは下層ルーティングプロトコルによって提供されるエニキャストおよび／またはサムキャストを使用せずに、サービス層におけるグループ管理を伴って、または伴わずに、エニキャストおよび／もしくはサムキャスト通信を可能にし、サポートすることに役立ち得る。

サービス層サムキャストは、本明細書に議論される場合、サービス層動作（例えば、ＣＲＵＤ）を行うためのサービス層通信である。要約すると、発信元（例えば、アプリケーション１３１）は、要求メッセージをレジストラノード（例えば、グループホスティングノード１３２）に送信し、レジストラノードは、所望の動作を行うための複数の資格要件を満たしたサービスノード（例えば、照明１３３または照明１３４）を選択し、要求を転送する。発信元は、概して、最終機能（例えば、居間１３６内の照明の量）が行われる限り、複数のサービスノードのうちのどれが動作を行うかを気にしない。例示的タイプのサービス層サムキャストは、グループベースのサムキャストおよび非グループベースのサムキャストを含む。グループベースのサムキャストでは、発信元は、１つ以上のグループのグループ情報（例えば、居間１３６）を明示的に規定し得る。レジストラノードは、グループから決定された数のサービスノードを選択し、要求を選択されたサービスノードに転送し得、選択されたサービスノードは、グループ内または異なるグループ内にあり得る。特別な例は、発信元が、サービスノードのリストのアドレス（例えば、ＵＲＩ、ＩＰアドレス）を提供し、したがって、レジストラノードが、サービスノードを選択せず、要求を転送することのみ必要とするものである。非グループベースのサムキャストでは、発信元は、任意のグループ情報を明示的に規定しないこともあり、代わりに、発信元は、いくつかの条件（例えば、居間１３６内の照明の量）をレジストラノードに提供する。レジストラノードは、条件に基づいて、サービスノードの範囲を決定し、要求を転送する。

サービスノードの範囲は、レジストラノードがエニキャストおよびサムキャスト要求のために選択するときに候補サービスノードと考えられる、サービスノードの組の範囲を規定する。グループベースのシナリオに対して、発信元は、グループＩＤを示すことによって、範囲を規定し得、したがって、レジストラノードは、範囲を決定する必要はない一方、非グループベースのシナリオに対して、レジストラノードは、グループＩＤ情報が与えられないので、範囲を決定する必要がある。本明細書で議論されるのは、サービス層におけるグループベースおよび非グループベースのエニキャスト／サムキャストをサポートする方法、システム、およびデバイスである。

図１３−１７および図１９に図示されるステップを行うエンティティは、図１３−１７および図２３Ｃまたは図２３Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理的エンティティであることを理解されたい。すなわち、図１３−１７および図１９に図示される方法は、図２３Ｃまたは図２３Ｄに図示されるデバイスまたはコンピュータシステム等のコンピューティングデバイスのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、コンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図１３−１７および図１９に図示されるステップを行う。ある例では、Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴うが、図１５の発信元１６１は、図２３ＡのＭ２Ｍ端末デバイス１８上に常駐し得る。図１５の発信元１６１、レジストラノード１６４、およびサービスノード１６５は、図２３ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

本明細書では、サービス層エニキャスト／サムキャストをサポートするためのサービスは、サムキャスト／エニキャストサービス（ＳＡＳ）と称され得る。図１３は、ＳＡＳのアーキテクチャ１４１の例示的例証であり、それは、サブ機能および他のサービス層エンティティとの相互作用を示す。サブ機能は、図１３に示され、以下にさらに議論されるように、メッセージ前処理１４２（図１４参照）、サービスノード／グループ選択１４３、および選択後処理１４４を含む。

図１４は、メッセージ前処理のための例示的方法を図示する。ブロック１５４では、パラメータが、正当性を検査される。例えば、メッセージ内のパラメータは、メッセージによって要求される値および動作が有効であるかどうかを決定するためにチェックされる。ＳＡＳを可能にするための情報およびパラメータは、本明細書により詳細に議論される。例えば、＜ｃｏｎｔａｉｎｅｒ＞リソースがサムキャストのための読み出し動作のみをサポートする場合、このリソース上の任意の他の動作は、エニキャスト／サムキャストのために無効と考えられるであろう。レジストラノードが、サムキャスト／エニキャストが要求内に設定されていることを識別する場合、ＳＡＳは、要求メッセージの処理を開始するであろう。

図１４を継続して参照すると、ブロック１５５では、エニキャスト／サムキャストシナリオが、識別される。エニキャスト／サムキャストの適切なシナリオは、受信されたメッセージ内の情報に基づき得る。例えば、とりわけ、シナリオがエニキャストであるか、またはサムキャストであるか、それがグループベースであるか、または非グループベースであるか、もしくは複数のグループがサムキャストのために関わるかどうか決定され得る。

ブロック１５６では、サービスノードの範囲が、決定される。これは、発信元が、通常、範囲をグループベースのシナリオのための要求メッセージ内に定義するため、主に、非グループベースのシナリオのためのものである。レジストラノードは、非グループベースの例に対して、要求メッセージ内の情報に基づいて、どのサービスノードがどの範囲／エリアから選択されるべきかを決定する。シナリオの識別および範囲の決定は、本明細書で議論されるコールフロー内に導入される。

ここで図１３を参照すると、メッセージ前処理１４２は、他の機能またはサービス層エンティティとの以下の相互作用を有し得る。１４５では、メッセージ前処理１４２は、エニキャストまたはサムキャストのための要求を発信元から受信し得る。本明細書に議論されるように、発信元は、図２３Ａ−図２３Ｄに関して議論されるように、Ｍ２Ｍデバイス１８であり得る。１４６では、メッセージ前処理１４２は、エニキャストまたはサムキャストのために他のサービス層ノードから転送された要求を受信し得る。この場合、グループホスティングノードが、選択され、転送された要求を受信し、エニキャストまたはサムキャストのための１つ以上のグループメンバを選択し得る。１４７では、メッセージ前処理１４２は、識別されたエニキャスト／サムキャストシナリオ、サービスノード／グループの範囲、またはエニキャスト／サムキャストパラメータをサービスノード／グループ選択１４３に送信し得る。

図１３を継続して参照すると、サービスノード／グループ選択１４３が存在し得、それは、メッセージ前処理１４２によって決定される範囲に基づいてサービスノードまたはグループを選択する。加えて、サービスノード／グループ選択１４３は元の選択サービスノードが失敗応答を返す場合、または任意のメッセージ損失が存在する場合、再選択を行うためにトリガされ得る。選択プロセスは、通常、メッセージ前処理１４２の出力と他のパラメータ（選択方法および基準または予期されるサービスノードの数等）とに基づいて行われる。単一グループのみが複数のグループから選択され、グループホスティングノードがサービスノードを選択することも可能である。サービスノード選択は、本明細書で議論されるコールフローに導入される。サービスノードまたはグループを選択後、選択されたノードまたはグループの情報は、１４８において、選択後処理１４４にパスされ得る。選択されたサービスノードまたはグループが所望の動作を行うことに失敗した場合、選択プロセスが再選択１４９によってトリガされることも可能である。

図１３を継続して参照すると、選択後処理１４４が存在し得、それは、エニキャスト／サムキャストのためのサービスノードまたはグループの選択後、タスクをハンドリングすることに責任がある。タスクは、１５２においてメッセージを選択されたサービスノードまたはグループに転送することと、１５１において返されたメッセージを処理することと、エラーまたはメッセージ損失が存在する場合、再伝送を開始することと、１５０において他のサービス層機能（例えば、グループ管理）をトリガすることとを含み得る。再伝送の開始に対して、選択されたサービスノードが失敗しているか、または要求を拒否しているので、再選択プロセスをトリガする可能性が高い。再伝送のための異なる方法が、本明細書により詳細に議論される。グループ管理等の他のサービス層動作のトリガに対して、これは、発信元要求およびサービス層構成に応じて随意である。

従来のサービス層は、エニキャストおよびサムキャストサービスをサポートするための情報および機構を定義しない。以下により詳細に議論されるのは、サービス層におけるエニキャストおよびサムキャスト通信を可能にすることに役立ち得る情報である。サービス層エニキャストおよびサムキャストを可能にするための発信元（例えば、図１５の発信元１６１）からの要求メッセージ内に含まれる情報は、とりわけ、以下の情報のうちの１つ以上のものを含み得る：エニキャスト／サムキャスト指示、サービスノードの数、グループ関連タイプ、グループＩＤ、グループ選択有効化、再伝送オプション、グループ管理トリガ、サービスノードＩＤ要件、および選択基準／方法。

エニキャスト／サムキャスト指示は、エニキャスト／サムキャスト通信が要求メッセージ内に含まれる動作のために所望されることを示し得る。サービスノードの数の指示が、エニキャスト／サムキャスト通信のためのメッセージ内で使用され得る。エニキャストに対して、要求される数は、１である。２つ以上の任意の数は、サムキャストを意味する。グループ関連タイプに関して、それは、エニキャスト／サムキャスト動作がグループベースまたは非グループベースであるかどうかを示し得る。２つ以上のグループが、エニキャスト／サムキャストプロセスのために関わり得る。グループベースのエニキャスト／サムキャストが存在する場合、グループＩＤは、グループ識別子（例えば、＜ｇｒｏｕｐ＞リソースのＵＲＩ）を示す。

エニキャスト／サムキャストに関連付けられたメッセージは、失敗が発生したときに使用されるであろう再伝送アプローチを示す再伝送オプションを含み得る。再伝送オプションパラメータは、異なる優先度を割り当てられた２つ以上のオプションを含み得る。例えば、再伝送オプションパラメータ下、「再選択」オプションまたは「再伝送」オプションが設定され得る。再選択に関して、それは、選択されたサービスノードが失敗した応答を返す場合、レジストラノードが、最初に、別のサービスノードの再選択を試みることを意味し得る。レジストラノードが別の資格要件を満たしたサービスノードを見つけることができない場合のみ、メッセージを選択されたサービスノードに再伝送するであろう。再伝送アプローチは、本明細書で取り上げられる。明確にするために、再選択オプションは、例えば、第１のサービスノードが失敗する場合、または要求を拒否する場合、別のサービスノード（または同等物）を選択し、要求を送信するためのものであり得る。再伝送オプションは、例えば、選択されたノードへの要求の再伝送であり得る。

エニキャスト／サムキャストに関連付けられたメッセージは、グループ管理トリガを含み得、それは、所望の動作がエニキャスト／サムキャストを介して成功裏に行われると、グループ管理動作（例えば、新しいグループを作成する、２つのグループをマージする）がトリガされることを示す。グループ管理動作はまた、あるグループ管理ポリシおよびルールによってもトリガされ得る。例えば、サービスプロバイダは、同一アプリケーションによって作成される全＜ｃｏｎｔａｉｎｅｒ＞リソースが容易な管理のために一緒にグループ化されるべきであるというルールを設定し得る。

エニキャスト／サムキャストに関連付けられたメッセージは、選択されたサービスノードのＩＤが発信元１６１への応答内で要求されるかどうかを示す、サービスノードＩＤパラメータを含み得る。通常、発信元１６１は、どのサービスノードがエニキャストおよびサムキャストのために選択され、所望の動作を行うかを気にせず、それを認知しない。ある場合には、サービスノードＩＤまたはアドレスが提供される場合、有益であろう。例えば、発信元１６１が、３つの＜ｃｏｎｔａｉｎｅｒ＞リソースを作成し、あるデータを記憶することを要求する。発信元１６１が、リソースを作成したサービスノードのＩＤを把握する場合、発信元１６１は、将来、新しいリソースを管理するためにそのサービスノードに直接アクセスすることができるであろう。

エニキャスト／サムキャストに関連付けられたメッセージは、エニキャストおよびサムキャスト通信のためにサービスノードを選択するための基準の組または方法を含み得る。サービスノードを選択するための基準または方法に対する第１の例では、サービスノードまたはグループが範囲内でランダムに選択され得ることを示す、ランダム選択の有効化が存在し得る。サービスノードを選択するための基準または方法に対する第２の例では、サービスノードは、場所（論理的場所または物理的場所のいずれかであり得る）に基づいて選択され得、例えば、選択されたサービスノードは、サービスプロバイダ１のネットワーク内にあるべきである。場所基準は、発信元によって構成され得る。サービスノードを選択するための基準または方法に対する第３の例では、サービスノードは、負荷バランシングに基づいて選択され得る。例えば、サービスノードは、他の潜在的サービスノードより少ないトラフィック負荷を有する。例えば、グループホスティングノードは、要求をアイドル中、または温度読み取り値を読み出すためにより少ない数の要求をサービスしているセンサに転送する。サービスノードを選択するための基準または方法に対する第４の例では、サービスノードは、ルーティングに基づいて選択され得る。例えば、発信元から最も少ないホップの数を有するサービスノードに基づく選択。サービスノードを選択するための基準または方法に対する第５の例では、下層ネットワーキングプロトコルに基づき得る。例えば、サービスノードは、発信元１６１と同一下層トランスポート層（例えば、ＣｏＡＰ）をサポートすることに基づいて選択され得る。最後に、他のコンテキスト情報も、サービスノードを選択するための基準または方法に考慮され得る。例えば、発信元は、感知の正確度、計算能力、時間認知、およびスリープスケジュール等のコンテキスト情報も規定し得る。

表１は、図１１に関連付けられ得る、要求メッセージの例を示す。サムキャスト／エニキャストに関連付けられた属性／パラメータは、表１に提供される。

加えて、エニキャストおよびサムキャストについてのある情報は、サービス層が、エニキャストまたはサムキャストのための要求を受信するとき、要求メッセージ内のパラメータの正当性を検査し得るように、サービス層に維持され得る。明確にするために、ＳＡＳは、サービス、例えば、ＣＳＥ内のＣＳＦであり得る。しかし、ＳＡＳは、他のサービスの中に統合され得るか、または別様にそれとともに提供され得る。サムキャスト／エニキャスト情報は、サービス層所有者／プロバイダによって、サービス層に構成および維持され得る。実装するために、サービス層のために定義された新しい属性またはパラメータが存在し得る。第１の例示的属性は、エニキャスト／サムキャスト通信がサービスノードまたは特定のリソース上で有効にされるかどうかを示すａｎｙｃａｓｔＳｏｍｅｃａｓｔＥｎａｂｌｅであり得る。第２の例示的属性は、エニキャスト／サムキャストのために可能にされる動作のタイプを示すｓｕｐｐｏｒｔＯｐＡｎｙｃａｓｔＳｏｍｅｃａｓｔであり得る。例えば、温度読み取り値を記憶するいくつかの＜ｃｏｎｔａｉｎｅｒ＞リソースに対して、読み出し動作のみが、エニキャスト／サムキャストのために可能にされ得る。言い換えると、この例では、発信元１６１は、エニキャストまたはサムキャストを介して、＜ｃｏｎｔａｉｎｅｒ＞リソースの一部の更新または削除を要求することができない。第３の例示的属性は、動作がサムキャストを通してサービスノードまたはリソースの混合タイプに対して行われ得るかどうかを示すｍｉｘｅｄＴｙｐｅｓＥｎａｂｌｅであり得る。これは、メンバリソースのグループを含むグループに関連する。メンバリソースのタイプは、同一または異なり得る。ｍｉｘｅｄＴｙｐｅｓＥｎａｂｌｅは、発信元がサムキャストを介して異なるタイプのメンバリソースに対して動作を行うことを要求できるかどうかを意味する。

図１５は、サービス層における非グループベースのエニキャスト／サムキャストのための例示的方法フローを図示する。以下に議論されるのは、サービス層における非グループベースのエニキャスト／サムキャストをサポートするためのプロシージャである。非グループベースのエニキャスト／サムキャストは、発信元が任意のグループ情報を明示的に規定しないが、発信元がサービスノードの範囲を決定することに役立てるためのいくつかの条件を提供し得ることを特徴とする。作成動作が、例として使用され、サービスノード１６６は、サービスノード１６５によってのみ到達可能である。以下に導入されるプロシージャは、エニキャストが、要求されるサービスノードの数が１であるサムキャストの特別な例と考えられ得るので、例としてサムキャストを使用する。

図１５を継続して参照すると、ステップ１６８では、発信元１６１（例えば、ｏｎｅＭ２Ｍ内のアプリケーションエンティティ）が、いくつかの＜ｃｏｎｔａｉｎｅｒ＞リソースを作成するための要求をレジストラノード１６４に送信する。ステップ１６８の要求メッセージでは、サムキャストに関連付けられたパラメータは、要求メッセージ内に規定され得る。例えば、サムキャストパラメータは、表２に示されるように設定され得る。コールフローに示されないが、サービスノードの数を示すための代替方法が存在する。１つの代替例では、ステップ１６８の要求メッセージは、サービスノードの数の範囲、例えば、（２、５）を含み、それは、最小数が２であり、最大数が５であることを示す。これは、レジストラノード１６４に、ノードを選択するためのある程度の柔軟性を与える。別の方法は、ステップ１６８の要求メッセージが、「ｎｕｍｂｅｒｆｌｅｘｉｂｉｌｉｔｙＩｎｄｉｃａｔｏｒ」フラグを設定しており、レジストラノード１６４が柔軟な数のサービスノードを選択することを可能にすることである。レジストラノード１６４がエニキャスト／サムキャストをサポートしない場合、ステップ１６８の要求メッセージは、無効メッセージとして処理される。なぜなら、いくつかのパラメータがサポートされない、要求メッセージがエニキャスト／サムキャストが有効にされないことを含む応答を返すからである。

図１５を継続して参照すると、ステップ１６９では、レジストラノード１６４が、ステップ１６８の要求メッセージを受信し、要求メッセージ内のパラメータの正当性を検査する。例えば、レジストラノード１６４は、エニキャスト／サムキャストが新しいリソースを作成するために可能にされるかどうかをチェックする。次いで、レジストラノード１６４は、エニキャスト／サムキャストのためのシナリオを識別する。この例では、非グループベースのサムキャストが規定され、したがって、レジストラノード１６４は、サービスノードの範囲を決定する。範囲を決定するために、レジストラノード１６４は、ステップ１６８の要求メッセージ内の選択基準およびそれが登録するサービス層ネットワークを参照し得る。ステップ１７０では、レジストラノード１６４は、選択基準および決定された範囲に基づいて、サービスノードを選択する。図１５の方法フローでは、レジストラノード１６４に登録するサービスノード１６３およびサービスノード１６２が、選択される。レジストラノード１６４は、次いで、選択された各サービスノードのための要求メッセージを生成する。ステップ１７１では、レジストラノード１６４は、作成要求を、それぞれ、選択されたノード（例えば、サービスノード１６３およびサービスノード１６２）に送信する。ステップ１７２では、応答メッセージが、レジストラノード１６４によって受信される。応答メッセージは、サービスノード１６３およびサービスノード１６２が作成動作を成功裏に完了したとき、それらによって送信され得る。ここでは、選択されたノード（例えば、サービスノード１６３およびサービスノード１６２）は、成功裏に動作を行うと仮定される。失敗例に対処する方法および対応する再伝送プロセスは、本明細書で議論される。

図１５を継続して参照すると、レジストラノード１６４は、この場合、候補である３つのサービスノードのみを把握するが、１つは、資格要件を満たしていないＩＮ−ＣＳＥである。資格要件を満たしたサービスノードは、サービスノードがステップ１６８の要求メッセージ内の条件に一致することを意味する。レジストラノード１６４は、さらなる選択のために要求を他のサービスノードに転送する必要があるかどうかを決定する。一般に、レジストラノード１６４は、要求されたほど多くの数のサービスノードを選択することができないことが可能である。なぜならば、レジストラノード１６４がその数のサービスノードに接続していないか、またはその数の資格要件を満たしたノードに接続していないか、またはいくつかの資格要件を満たしたノードが要求を拒否するからである。この場合、ステップ１７３では、レジストラノード１６４は、エニキャスト要求をサービスノード１６５に転送し得、それは、要求を完了するためのもう１つのサービスノードを選択するであろう。残りのエニキャストは、要求されるサービスノードの数が１であるサムキャストの特別な例と考えられ得る。したがって、ステップ１７２が成功する場合、ステップ１７３からステップ１７９は、エニキャストのために必要とされない。

図１５を継続して参照すると、ステップ１７４では、レジストラノード１６４は、サムキャスト要求メッセージをサービスノード１６５に転送する。このメッセージ内のコンテンツは、エニキャストが期待されることを示すサービスノードの数が１であることを除き、ステップ１６８の要求メッセージのコンテンツと実質的に同一であり得る。レジストラノード１６４によって選択された２つのサービスノードは、リソースをすでに作成しており、したがって、もう１つのみが、必要とされる。ステップ１７５では、サービスノード１６５は、ステップ１６９およびステップ１７０に類似する動作に従う。ステップ１７９では、ステップ１７１およびステップ１７２に類似する動作が、続く。ステップ１７７では、レジストラノード１６４は、ステップ１７４の要求メッセージに関連付けられた応答メッセージを受信する。応答メッセージは、とりわけ、パラメータを示すか、または要求が完了したことを示し得る。

図１５を継続して参照すると、ステップ１７８では、ステップ１６８の要求が遂行される（例えば、この場合、３つのサービスノードが＜ｃｏｎｔａｉｎｅｒ＞リソースを成功裏に作成する）と、レジストラノード１６４は、新しく作成されたリソースを管理するためのグループを作成する必要があるかどうかを決定し得る。これを行うことは、いくつかの利点を有し得る。この場合、３つの新しい＜ｃｏｎｔａｉｎｅｒ＞リソースが、より効率的であるグループ管理方法を通して、管理、発見、およびアクセスされ得る。別の可能な例は、発信元１６１が、３つの新しいリソースを発信元１６４によって作成および管理されているリソースのリストを含む既存のグループに追加することを要求し得ることである。任意のグループ関連動作を行うかどうかは、異なる要因に依存し得る。例えば、１つの要因は、発信元１６４が特定のグループ管理関連動作を要求メッセージ内で明示的に要求するかどうかであり得る。別の要因は、特定のグループ管理動作がサービス層構成に基づいて行われるべきかどうかの決定に基づき得る。例えば、サービス層プラットフォームが、サムキャストを通して作成されたリソースが、リソースが同一タイプである限り、効率的管理のために一緒にグループ化されることを要求するように構成され得る。加えて、ステップ１７８のためのグループ関連動作は、このプロセスにおける例にすぎない。この随意のステップは、アクセス制御および請求等の他の側面に関連し得る。ステップ１７９では、レジストラノード１６４は、応答を発信元１６４に送信し、応答は、ステップ１６８の要求に関連付けられた要求されるリソースを作成するそれらのサービスノードのＩＤを含み得る。

図１５のシナリオを継続して参照すると、レジストラノード１６４が要求されるものと同じ数のサービスノードを選択することに失敗する場合、もう１回選択を行うためにサムキャスト要求を別のサービスノードに転送する代わりに、代替方法は、レジストラノードが発見プロセスを行い、検討され得るある他の資格要件を満たしたサービスノードについてのさらなる情報を得ることである。この発見ステップは、図１５に示されるように、ステップ１７３から開始され得る。レジストラノード１６４における発見を可能にするために、発信元１６１は、「ｏｐｔｉｏｎａｌＡｃｔｉｏｎ」と呼ばれる、随意のフラグを要求メッセージ内に設定し得、それは、レジストラノードが要求されるサービスノードの数を見つけることに失敗した場合に行うべきものを示す。「ｏｐｔｉｏｎａｌＡｃｔｉｏｎ」の可能な値は、無し、発見、転送等であり得る。

図１６Ａおよび図１６Ｂは、サービス層におけるグループベースのエニキャスト／サムキャストのための例示的方法フローを図示する。非グループベースのシナリオとは対照的に、発信元１６１は、グループＩＤ、＜ｇｒｏｕｐ＞リソースのＵＲＩ、またはサービスノードのアドレスのリスト等のグループ情報を提供する。２つ以上のグループが、グループベースのエニキャストおよびサムキャストに関わり得る。例えば、エリアの温度読み取り値に関心があるアプリケーションは、異なるオペレータによって管理されるセンサのいくつかのグループがデータを提供し得ることを見出し得、したがって、アプリケーションは、そのレジストラノード１６１に、エニキャストまたはサムキャストを介して温度データを読み出すための全てのこれらのグループを知らせ得る。したがって、レジストラノードは、要求メッセージをグループホスティングノードのいずれかに転送する前に、グループを選択することが要求され得る。マルチグループシナリオは、１グループシナリオの一般的例であり、グループ選択動作は、スキップされる。

図１６Ａは、グループ選択が行われない、例示的方法フローを図示する一方、図１６Ｂは、グループ選択が行われる例示的方法フローを図示する。図１６Ａおよび図１６Ｂの両方に対して、読み出し動作が、例として使用される。

図１６Ａを参照すると、ステップ１９１では、レジストラノード１８４は、コンテンツを読み出すための要求を受信する。ステップ１９１の要求メッセージでは、表３に提供されるエニキャスト／サムキャストに関連するパラメータを含む。無グループ選択は、レジストラノードが要求メッセージを転送する前にグループを選択する必要がないことを意味する。発信元１８１は、２つのグループを標的にするので、サービスノードは、グループ１のみ、グループ２のみ、または両グループから選択され得る。図１６Ａは、グループ選択を伴わないプロシージャを示す。

図１６Ａを継続して参照すると、ステップ１９２では、レジストラノード１８４は、ステップ１９１の要求メッセージ内のパラメータの正当性を検査する。レジストラノード１８４は、２つのグループがサムキャストのために関わり、グループ選択が要求されないことを識別する。ステップ１９３では、レジストラノード１８４は、要求メッセージを、グループホスティングノードであるグループ１ホスティングノード１８３およびグループ２ホスティングノード１８５に送信する。レジストラノード１８４は、サービスノードの数およびグループＩＤをそれが転送する各要求内に提供する。要求を転送する前に、レジストラノード１８４は、所望のノードの数をグループ１に対して１に、所望のノードの数をグループ２に対して２に設定するための決定を行う。ステップ１９４ａでは、グループ１ホスティングノード１８３は、ステップ１９３の要求メッセージを処理し、グループベースのエニキャストであることを識別する。したがって、グループ１ホスティングノード１８３は、そのグループメンバのうちの１つを選択し、要求される動作を行う。ステップ１９３の要求は、以下、すなわち、ａｎｙｃａｓｔ／ｓｏｍｅｃａｓｔ，ｔｙｐｅ：ｇｒｏｕｐ，ｒｅｑｕｉｒｅｄ ｎｕｍｂｅｒ：１（２），ｔａｒｇｅｔ：／ｇｒｏｕｐ１（／ｇｒｏｕｐ２），Ｃｏｎｔｅｎｔ ｔｏ ｒｅｔｒｉｅｖｅ，ｓｅｌｅｃｔｉｏｎＣｒｉｔｅｒｉａを含み得る。ステップ１９４ｂでは、グループ２ホスティングノード１８５内のＳＡＳは、ステップ１９４ａと同様のプロセスに従う。しかしながら、グループ２ホスティングノード１８５は、レジストラノードからの要求がグループベースのサムキャストが２つのサービスノードに要求されることを示すので、２つのグループメンバを選択し、要求される動作を行う。

図１６Ａを継続して参照すると、ステップ１９５ａでは、グループ１ホスティングノード１８３は、要求をグループ１メンバノード１８２の選択されたグループメンバに送信し、適宜、応答を受信する。ステップ１９５ｂでは、それは、要求および応答メッセージを選択されたグループメンバ（例えば、グループ２メンバノード１８６）と交換するためのステップ１９５ａと同様のプロセスである。ステップ１９６ａおよびステップ１９６ｂでは、グループ１ホスティングノード１８３およびグループ２ホスティングノード１８５は、応答メッセージを、それぞれ、レジストラノード１８４に送信し、要求された動作がグループ１メンバノード１８２およびグループ２メンバノード１８６の選択されたグループメンバによって成功裏に行われたことを示す。ステップ１９７では、レジストラノード１８４は、サービスノードの数が要求される動作を行うために十分であることを検証する。ステップ１９８では、レジストラノード１８４は、発信元１８１に、ステップ１９１の要求メッセージに関連付けられた応答メッセージを送信する。

グループ選択に関連付けられた図１６Ｂは、以下に議論される。ステップ２０１およびステップ２０２は、図１６Ａのステップ１９１およびステップ１９２に類似する。ステップ２０３では、ステップ２０１の要求メッセージにおいて、グループ選択が要求に応じて示され、レジストラノードは、サムキャスト要求を転送するために、他より優先するグループを選択することに責任がある。この場合、グループ２が、選択される。レジストラノード１８４は、ステップ２０１の要求メッセージ内の選択基準、ローカルで維持されるサービス層構成等に基づいて、選択を行い得る。例えば、レジストラノード１８４は、より大きい選択ベースを意味するより多いグループメンバを伴うグループを選択し得る。レジストラノード１８４は、より多いクライアントまたは加入者が、サムキャストを介して、所望の動作を行うことによって、新しい特徴／サービスが通知され得るように、より多いサービス層クライアントまたは加入者を有するグループを選択し得る。ステップ２０４では、レジストラノード１８４は、ステップ２０１の要求からグループＩＤを更新することによって、サムキャスト要求をグループ２ホスティングノード１８５に送信する。ステップ２０４の要求は、以下、すなわち、ａｎｙｃａｓｔ／ｓｏｍｅｃａｓｔ，ｔｙｐｅ：ｇｒｏｕｐ，ｔａｒｇｅｔ：／ｇｒｏｕｐ２ ｒｅｑｕｉｒｅｄ ｎｕｍｂｅｒ：３，Ｃｏｎｔｅｎｔ ｔｏ ｒｅｔｒｉｅｖｅ，ｓｅｌｅｃｔｉｏｎＣｒｉｔｅｒｉａを含み得る。ステップ２０５からステップ２０７は、図１５のステップ１７５からステップ１７７と同様の動作に従う。ステップ２０８では、レジストラノード１８４は、要求される成功動作の数が十分であることを検証する。ステップ２０９では、レジストラノード１８４は、応答を発信元１８１に送信する。代替では、ステップ２０２は、グループホスティングノード１８５がエニキャスト／サムキャスト要求をレジストラノード１８４から受信したとき、グループ２ホスティングノード１８５によっても行われ得る。この意味では、レジストラノード１８４が、直接、グループを選択し、各グループのために要求される数を決定していると考えられ得る。

以下に議論されるのは、再伝送アプローチである。図１５、図１６Ａ、および図１６Ｂは、プロセス中、処理エラーまたはメッセージ損失のいずれも存在せず、再伝送が要求されないと仮定した非グループベースおよびグループベースのエニキャスト／サムキャストの両方のプロシージャを示す。メッセージ損失（例えば、下層プロトコル層におけるパケット損失）または処理エラー（例えば、拒否された要求）のための再伝送が存在し得る。図１７に図示される再伝送動作を行うための複数のオプションが存在する。オプション２１９に対して、要約すると、以下により詳細に議論されるように、非グループベースのシナリオのために、レジストラノード１８４が別のサービスノードを選択するか、または、グループベースのシナリオのために、グループホスティングノードが同じグループから異なるグループメンバノードを選択する。オプション２２０に対して、要約すると、以下により詳細に議論されるように、非グループベースのシナリオのために、レジストラノード１８４が要求を選択されたサービスノードに再伝送するか、またはグループホスティングノードが要求を選択されたグループメンバノードに再伝送する。いくつかの状況下では、このオプションは、使用されるべきではない。例えば、選択されたサービスノードが、あるアクセス制御問題により要求を拒否するか、または、選択されたサービスノードが、単にリソースを削除しており、エニキャスト要求がデータを削除されたリソースから読み出すことである。オプション２３０に対して、要約すると、以下により詳細に議論されるように、グループホスティングノードは、成功応答を選択されたグループメンバから得ることに失敗すると、レジストラノードに戻る。レジストラノードは、新しいサービスノードを選択するために、異なるグループに行く。このオプションは、通常、複数のグループが関わるときのグループベースのシナリオのためのものである。

図１７を参照すると、ステップ２１０は、事前構成のための一連のステップを含み、一連のステップは、発信元１８１が１つのみのサービスノードが動作（例えば、エニキャスト）を行うことを要求する以外、図１６Ｂに示されるようなステップ２０１からステップ２０５に従う。この例におけるエニキャストの使用は、主に、再伝送アプローチの例証を容易にするためのものである。発信元１８１は、２つのグループが関わるエニキャスト要求を開始する。レジストラノード１８４は、グループ選択要求を行い、サムキャスト要求をグループ２ホスティングノード１８５に送信する。次いで、グループ２ホスティングノード１８５は、１つのグループメンバを選択する。ステップ２１１では、グループ２ホスティングノード１８５は、ステップ２１０において提供される要求される動作を行うために、要求メッセージを選択されたグループメンバに送信する。ステップ２１２では、再伝送を例証するために、グループ２メンバノード１８７からであることを示すグループ２ホスティングノード１８５によって受信された失敗した応答が存在する。ステップ２１３では、グループ２ホスティングノード１８５は、エニキャスト要求メッセージをチェックし、該当する場合、どの再伝送が要求されるかを決定する。発信元１８１が、どんな再伝送方法も規定しない場合、デフォルト方法が、使用されるであろう。グループ２ホスティングノード１８５がメッセージ損失に起因して応答を得ることができないことも可能である。この場合、グループ２ホスティングノード１８５は、応答がタイムアウトすると、再伝送プロセスを開始し得る。

図１７のオプション２１９を参照すると、ステップ２１４では、グループ２ホスティングノードは、別のグループメンバを選択することを決定し、グループ２メンバノード１８８を選択する。グループ２ホスティングノード１８５が、発信元１８１によって設定された要件に一致する任意の資格要件を満たしたグループメンバを見つけることができないことも可能である。このシナリオでは、グループ２ホスティングノード１８５は、代わりに、代替再伝送方法を利用し得る。複数の再伝送方法が、発信元１８１によって規定され得、したがって、第１のオプションが機能しない（例えば、この場合、資格要件を満たしたグループメンバが存在しない）場合、グループ２ホスティングノード１８５は、第２のオプションに移行し得る。ステップ２１５およびステップ２１６では、要求および成功応答交換が、それぞれ、グループ２ホスティングノード１８５とグループ２メンバノード１８８との間で生じる。ステップ２１７では、レジストラノード１８４は、ステップ２１０の要求に関連付けられた応答を受信する。ステップ２１８では、レジストラノード１８４は、ステップ２１０の要求に関連付けられた応答を発信元１８１に送信する。

図１７のオプション２２０を参照すると、ステップ２２１では、このオプションに対して、グループ２ホスティングノード１８５は、要求を選択されたグループメンバ（例えば、グループ２メンバノード１８７）に再伝送することを決定する。この決定を行う前、グループ２ホスティングノード１８５は、グループ２メンバノード１８７が要求される動作を成功裏に行うことが可能であることを検証し得る。例えば、グループ２メンバノード１８７が読み出し動作のためのコンテンツを記憶するリソースをすでに削除している場合、グループ２ホスティングノード１８５は、再伝送のためのオプション２２０を使用せず、代替オプションに移行すべきである。グループ２ホスティングノード１８５は、ステップ２１２の応答内の応答コードをチェックし、失敗理由を識別し得る。ステップ２２２およびステップ２２３では、要求および成功応答交換が、それぞれ、グループ２ホスティングノード１８５とグループ２メンバノード１８７との間で生じる。ステップ２２４では、レジストラノード１８４は、ステップ２１０の要求に関連付けられた応答を受信する。ステップ２２５では、レジストラノード１８４は、ステップ２１０の要求に関連付けられた応答を発信元１８１に送信する。

図１７のオプション２３０を参照すると、ステップ２２１では、グループ２ホスティングノード１８５は、再伝送のために、レジストラノード１８４に戻る。加えて、グループ２ホスティングノード１８５は、前の２つのオプションが機能しなかった（例えば、資格要件を満たしたグループメンバが存在せず、選択されたグループメンバが要求される動作を行うことができない）ので、このオプションを使用し得る。ステップ２３２では、グループ２ホスティングノード１８５は、応答をレジストラノード１８４に送信し、失敗理由を示す。ステップ２３３では、レジストラノード１８４は、失敗理由および再伝送オプションを識別し、エニキャスト要求のために、グループ１に行くことを決定する。ステップ２３４からステップ２３９では、レジストラノードは、エニキャスト要求をグループ１ホスティングノード１８３に送信し、それは、エニキャストのためのステップに従う。これらのステップは、図１６Ｂに示されるようなステップ２０４からステップ２０９に類似する。

図１８は、従来のｏｎｅＭ２Ｍ機能的アーキテクチャに基づく新しいＳＬサムキャスト／エニキャストＣＳＦ２４４として開示されるＳＡＳを実装するための例を図示する。代替として、開示されるＳＡＳはまた、従来のグループ管理ＣＳＦの一部として実装および追加され得る。

以下の表４に示される共通属性が、リソースがエニキャストおよびサムキャストを可能にするために開示される。

ＭｃａおよびＭｃｃ参照点を経由した発信元（例えば、発信元１８１）から受信側（例えば、レジストラノード１８４）への要求は、表５に示されるようなパラメータを含み得る。

従来のｏｎｅＭ２Ｍグループ管理を通してグループベースのエニキャスト／サムキャストをサポートすることが可能である。いくつかの属性が、表６にリストアップされるように、＜ｇｒｏｕｐ＞リソースに関して開示される。

図１９は、ｏｎｅＭ２Ｍグループ管理等のための例示的サムキャスト／エニキャスト方法フローを図示する。要約すると、第１のアプローチ（例えば、図１９のケース２７１）では、グループホスティングＣＳＥ２５２は、ＡＥ２５１（例えば、発信元）からの要求に基づいて、グループメンバの要求される数を選択し、要求を各選択されたメンバホスティングＣＳＥ（例えば、メンバホスティングＣＳＥ２５４またはメンバホスティングＣＳＥ２５５）に転送する。第２のアプローチ（例えば、図１９のケース２７２）では、グループホスティングＣＳＥ２５２は、ＡＥ２５１によって要求される数より多いグループメンバの数を選択する。グループホスティングＣＳＥ２５２は、応答を集約し、十分な数の応答を収集後、集約された応答をＡＥ２５１に送信する。グループホスティングＣＳＥ２５２は、十分な数の応答に達した後、応答を無視し得る。これは、時間的制約のあるいくつかのアプリケーション／サービスにとって有用であり得る。例えば、監視サービスは、原子力発電所からのリアルタイム温度読み取り値を提供し、動作を調節する。緊急事態が発生する場合、温度読み取り値を確実かつ迅速に返すことが要求され得る。いくつかのセンサは故障している潜在性があり、グループホスティングＣＳＥ２５２は、それを認知していないこともある。このアプローチは、選択されたグループメンバがエラーを有する場合、エニキャスト／サムキャストのためのあるレベルの信頼性を提供し得る。

図１９は、以下により詳細に議論される。ステップ２６１では、ＡＥ２５１は、仮想リソース＜ｆａｎＯｕｔＰｏｉｎｔ＞を標的とする要求を送信し、２つのグループメンバが動作を行うことを要求する。要求は、以下、すなわち、（＜ｇｒｏｕｐ＞／＜ＦａｎＯｕｔＰｏｉｎｔ＞，ａｎｙｃａｓｔＳｏｍｅｃａｓｔＩｎｄｉｃａｔｏｒ：ｓｅｔ，ｎｕｍｂｅｒＯｆＡｎｙｃａｓｔＳｏｍｅｃａｓｔＮｏｄｅ：２，ｇｒｏｕｐＢａｓｅｄＩｎｄｉｃａｔｉｏｎ：ｇｒｏｕｐ ｂａｓｅｄ，ｓｅｒｖｉｃｅＮｏｄｅＳｅｌｅｃｔｉｏｎＣｒｉｔｅｒｉａ：ｒａｎｄｏｍ ｓｅｌｅｃｔｉｏｎ，ｒｅｔｒａｎｓＯｐｔｉｏｎ：ｒｅｓｅｌｅｃｔ ｇｒｏｕｐ ｍｅｍｂｅｒ，ｒｅｌｉａｂｌｅＲｅｑｕｉｒｅｍｅｎｔ：ｒｅｌｉａｂｉｌｉｔｙ ｒｅｑｕｉｒｅｄ）を含み得る。ステップ２６２では、グループホスティングＣＳＥ２６２は、ステップ２６１の要求メッセージ内に見出された受信されたパラメータの正当性を検査し得る。例えば、正当性検査は、とりわけ、のうちの１つ以上のものを決定することを含み得る：要求動作がエニキャスト／サムキャストのためにサポートされているかどうか、グループメンバの要求される数がグループメンバの総数を超えていないかどうか、または、要求されるサムキャストが混合タイプのグループメンバ上での動作につながるかどうか、およびこれが可能にされるかどうか。さらに、ステップ２６２では、グループメンバの数が、選択され得る。これは、ステップ２６１の要求メッセージ内で要求される数またはいくつかのアプリケーション／サービス具体的パラメータに基づき得る。例えば、緊急監視および報告サービスは、任意の緊急状況を報告するためのあるレベルの「信頼性」を要求し得、したがって、グループホスティングＣＳＥは、エニキャスト／サムキャストを通してこのサービスをサブスクライブするアプリケーションのためのサブスクリプションを作成するために、実際の必要とされるものより多いメンバホスティングＣＳＥを選択し得る。要求されるものより多く選択するためのこのアプローチは、いくつかの選択されたノードが要求を拒否する場合、またはエラー／メッセージ損失が存在する場合、ある程度の余裕を提供し得る。主要概念は、グループホスティングＣＳＥが発信元によって要求されるものより多くの数のノードを選択するというものである。例えば、発信元が３つのメンバを選択することを要求するが、グループホスティングＣＳＥは、５つのメンバを選択し得、したがって、２つの選択されたメンバが拒否する場合、もしくは切断される場合、または２つのメッセージが喪失される場合でも、発信元は、依然として、３つの応答を受信し得、それは、再伝送によるあまりに長い待ち時間を回避し得る。ステップ２６２では、グループメンバは、要求における方法および基準に基づいて、またはサービス層内に維持されるデフォルト方法に基づいて選択され得る。

図１９を継続して参照すると、ステップ２６３では、グループホスティングＣＳＥ２５２は、要求を各選択されたメンバホスティングＣＳＥ（例えば、とりわけ、メンバホスティングＣＳＥ２５３、メンバホスティングＣＳＥ２５４、およびメンバホスティングＣＳＥ２５５）に送信する。この例示的場合では、３つのメンバが、選択され、それは、要求される２つのメンバより多い。ＡＥ２５１は、ランダム選択を規定するので、グループホスティングＣＳＥ２５２は、３つのグループメンバをランダムに選択する。

以下に議論されるのは、図１９のケース２７１であり、それは、全応答を受信する前に、成功応答の要求される数を収集するための例示的フローである。ステップ２６４では、最初の２つの戻り応答が、受信され、要求動作が成功裏に行われたことを示す。ステップ２６５では、グループホスティングＣＳＥ２５２は、成功応答の要求される数を受信したので、ＡＥ２５１への応答を集約することを決定する。ステップ２６６では、グループホスティングＣＳＥ２５２は、集約された応答メッセージをＡＥ２５１に送信する。２６７では、グループホスティングＣＳＥ２５２によってその後受信された応答は、ステップ２６１の要求のためである場合、無視されるであろう。

以下に議論されるのは、図１９のケース２７２であり、それは、成功応答の要求される数の収集失敗のための例示的フローである。ステップ２８１およびステップ２８２では、２つの選択されたグループメンバが、プロセスエラーおよびメッセージ損失により、成功応答をグループホスティングＣＳＥ２５２に返せない。ステップ２８３では、グループホスティングＣＳＥ２５２は、ステップ２８１およびステップ２８２に関連付けられた応答に基づいて、異なるグループメンバを再選択する。グループホスティングＣＳＥ２５２は、要求動作のための成功応答の要求される数を収集することに失敗したことを決定する。それは、２つののうちの１つを収集している。ステップ２８４では、グループホスティングＣＳＥ２８４は、要求メッセージを新しく選択されたグループメンバ（例えば、ステップ２８３において選択されたメンバホスティングＣＳＥ２５５）に送信する。ステップ２８５では、グループホスティングＣＳＥ２５２は、ステップ２８４の要求メッセージに関連付けられた成功応答を受信する。ステップ２８６では、グループホスティングＣＳＥ２５２は、受信された応答を集約する。ステップ２８７では、グループホスティングＣＳＥ２５２は、集約された応答をＡＥ２５１に送信する。

図２０は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（ｏｎｅＭ２Ｍ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ，ｏｎｅＭ２Ｍ−ＴＳ−０００７ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．７．０）におけるＳＡＳの例示的実装アーキテクチャを図示する。示されるように、ＳＡＳコンポーネント２７５がＣＳＥ２７６内に存在する。このサービス能力は、要求内のパラメータの正当性を調査し、エニキャスト／サムキャストシナリオを識別し、選択のためのサービスノードの範囲を決定する能力を提供する。

以下は、サービス能力に関するさらなる議論である。ｐｒｏｃｅｓｓｉｎｇＡｎｙｃａｓｔＳｏｍｅｃａｓｔＭｅｓｓａｇｅサービス能力は、要求内のパラメータの正当性を調査し、エニキャスト／サムキャストシナリオを識別し、選択のためのサービスノードの範囲を決定する能力を提供する。前提条件は、発信元（例えば、ＡＥまたはＣＳＥ）がサービスノードの１つまたは組にエニキャスト／サムキャストを開始することを欲することを含む。Ｓｉｇｎａｔｕｒｅ−ｐｒｏｃｅｓｓｉｎｇＡｎｙｃａｓｔＳｏｍｅｃａｓｔＭｅｓｓａｇｅは、前の１つ以上の表に類似する。

図２１は、エニキャスト／サムキャストのための例示的サービス相互作用を図示し、それは、ＳＯＡのためのフローを有する。ｏｎｅＭ２Ｍリソースインタワーキングサービス能力は、サービス層近隣へのサービス層リンクにおける重み読み出すために使用され得る。サービス能力は、＜ｇｒｏｕｐ＞リソースと整列し、リソースのためのＣＲＵＤプロシージャにマップする。

図２２は、ＳＡＳに関連付けられた例示的グラフィカルユーザインターフェース上に表示され得るものを図示する。ディスプレイは、任意のコンピューティングベースのデバイスと通信可能に接続され得る。アイコン２９１は、ＳＡＳのためのものであり、選択されると、ブロック２９２において、グループベースまたは非グループベースのオプションを表示し得る。グループベースのオプションが選択される場合、ブロック２９３内の情報は、本明細書に議論されるように、サムキャスト／エニキャストパラメータとともに表示され得る。ブロック２９３内のパラメータのうちの１つ以上のものは、追加の情報をもたらすように選択され得る。例えば、ｓｅｒｖｉｃｅＮｏｄｅＳｅｌｅｃｔｉｏｎＣｒｉｔｅｒｉａが、選択され、ブロック２９４内の情報を提供し得る。別の例では、本明細書で議論されるステップのいずれかの進捗度（例えば、送信されたメッセージまたはステップの成功）が、表示され得る。とりわけ、図１５−図１７の方法フローが、本明細書に議論されるように表示され得る。ユーザインターフェースは、デフォルト値を伴うそれらのパラメータを構成またはプログラムするために、エニキャスト／サムキャストサービスのためのある特徴の有効化または無効化のための制御スイッチとともに実装され得る。

本明細書に現れる請求項の範囲、解釈、または用途をいかようにも過度に限定することなく、本明細書に開示される例ののうちの１つ以上のものの技術的効果はデバイスおよびアプリケーションがサービス層を経由して通信する方法の調節を提供することである。ＳＡＳは、通信がサービス層に関連付けられるとき、いくつかのインスタンスにおいてより効率的通信を提供し得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図で図示されるような本開示の主題（ＳＡＳ）の好ましい方法、システム、または装置を説明する上で、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、同様の目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

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

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

方法、システム、および装置は、とりわけ、本明細書に説明されるように、ＳＡＳのための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、サービス層を使用してサムキャストするための命令を含む、第１の要求メッセージを受信することと、要求メッセージ内の選択基準に基づいて、標的ノードを決定することと、第２の要求メッセージを所望の動作を行い得る標的ノードに送信することとを行う手段を有する。第１の要求メッセージは、サムキャストに関連付けられた第１の要求を完了するために要求されるサービスノードの数の指示を含み得る。第１の要求メッセージは、グループベースまたは非グループベースのサムキャストの指示を含み得る。第１の要求メッセージは、グループベースのサムキャストのためのグループ識別子を含み得る。選択基準は、サービスノードのタイプを含み得る。第１の要求メッセージは、第１の要求を満たすために使用されることができるサービスノードの量の数範囲の指示を含み得る。第１の要求メッセージは、エニキャスト（例えば、サービスノード上でのみ示す）の指示または再伝送オプションを含み得る。第１の要求メッセージは、再伝送オプションを含み得る。この段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で検討される。

方法、システム、および装置は、とりわけ、本明細書に説明されるように、ＳＡＳのための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、所望される第１のタイプの情報を決定することであって、第１のタイプの情報は、複数の通信可能に接続されるノードによって取得可能であり、第１のタイプの情報は、物理的世界を感知することに基づく、ことと、複数のノードの代表的サブセットを決定することであって、代表的サブセットは、第１の基準に基づく、ことと、第１のタイプの情報のための要求メッセージを複数のノードの代表的サブセットに送信することとを行う手段を有する。

Claims (20)

1. 装置であって、前記装置は、
   プロセッサと、
   前記プロセッサと結合されているメモリと
   を備え、
   前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
   サービス層を使用してサムキャストするための命令を含む第１の要求メッセージを受信することと、
   前記要求メッセージ内の選択基準に基づいて、標的ノードを決定することと、
   所望の動作を行うための第２の要求メッセージを前記標的ノードに送信することと
   を含む動作を前記プロセッサに達成させる、装置。
2. 前記第１の要求メッセージは、サービスノードの数を含む、請求項１に記載の装置。
3. 前記第１の要求メッセージは、グループベースまたは非グループベースのサムキャストの指示を含む、請求項１に記載の装置。
4. 前記第１の要求メッセージは、グループベースのサムキャストのためのグループ識別子を含む、請求項１に記載の装置。
5. 前記選択基準は、サービスノードのタイプを含む、請求項１に記載の装置。
6. 前記選択基準は、サービスノードと共に使用されるネットワーキングプロトコルのタイプを含む、請求項１に記載の装置。
7. 前記第１の要求メッセージは、前記第１の要求を満たすために使用されることができるサービスノードの量の数範囲の指示を含む、請求項１に記載の装置。
8. 前記第１の要求メッセージは、エニキャストの指示を含む、請求項１に記載の装置。
9. 前記第１の要求メッセージは、再伝送オプションを含む、請求項１に記載の装置。
10. コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピューティングデバイスによって実行されると、
    サービス層プラットフォーム内でサムキャストするための命令を含む第１の要求メッセージを受信することと、
    前記要求メッセージ内の選択基準に基づいて、標的ノードを決定することと、
    所望の動作を行うための第２の要求メッセージを前記標的ノードに送信することと
    を含む動作を前記コンピューティングデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
11. 前記第１の要求メッセージは、サービスノードの数を含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
12. 前記第１の要求メッセージは、グループベースまたは非グループベースのサムキャストの指示を含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
13. 前記第１の要求メッセージは、グループベースのサムキャストのためのグループ識別子を含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
14. 前記選択基準は、サービスノードのタイプを含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
15. 前記選択基準は、サービスノードと共に使用されるネットワーキングプロトコルのタイプを含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
16. 前記第１の要求メッセージは、前記第１の要求を満たすために使用されることができるサービスノードの量の数範囲の指示を含む、請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
17. 方法であって、前記方法は、
    サービス層プラットフォーム内でサムキャストすることを示す第１の要求メッセージを受信することと、
    前記要求メッセージ内の選択基準に基づいて、標的ノードを決定することと、
    所望の動作を行うための第２の要求メッセージを前記標的ノードに送信することと
    を含む、方法。
18. 前記第１の要求メッセージは、サービスノードの数を含む、請求項１７に記載の方法。
19. 前記第１の要求メッセージは、グループベースまたは非グループベースのサムキャストの指示を含む、請求項１７に記載の方法。
20. 前記第１の要求メッセージは、グループベースのサムキャストのためのグループ識別子を含む、請求項１７に記載の方法。