例示的なシステムアーキテクチャ
図1A乃至1Cは、1つまたは複数の実施形態を実装またはその他の方法で実施することができるシステム10の例を示すブロック図である。そのような実施形態は、例えば、マシンツーマシン(M2M)アプリケーション、M2Mサービス能力(SC)、M2Mエリアネットワーク、M2Mゲートウェイ、およびM2MデバイスなどのM2Mリモートエンティティを管理することを含む、M2M通信および/または動作に関する実施形態を含んでもよい。
システム10は、1つまたは複数のアーキテクチャに従って構成されてもよく、および/または1つまたは複数のアーキテクチャを使用して実装されてもよく、それらのアーキテクチャのいずれかは、様々な標準に基づいていてもよく、および/または様々な標準に従って構成されてもよい。これらの標準は、例えば、「マシンツーマシン(M2M)通信、機能アーキテクチャ」と題され、「ETSI TS 102 690」と呼ばれる欧州電気通信標準化機構(ETSI)により公表された技術仕様(TS)ドラフトなどの、M2M通信および/または動作に関する標準を含んでもよい。他の例は、例えば、「技術仕様グループサービスおよびシステム態様、マシンタイプ通信(MTCに対するサービス要件」と題する第3世代パートナーシッププロジェクト(3GPP) TS 22.368などのマシンタイプ通信(MTC)に関連するものを含む、3GPPおよび/または第3世代パートナーシッププロジェクト2(3GPP2)により公表された標準を含んでもよい。ETSI TS 102 690と3GPP TS 22.368は共に、参照により本明細書に組み込まれる。システム10のアーキテクチャは他の標準に準拠してもよい。
システム10は、デバイスドメイン12、ネットワークドメイン14、およびネットワークアプリケーションドメイン16を含んでもよい。ネットワークアプリケーションドメイン16は、M2Mネットワークアプリケーション18aおよび18bを含んでもよい。M2Mネットワークアプリケーション18aおよび18bは、個々のホスティングデバイス(図示せず)上で記憶され、実行され、および/またはホスティングされてもよい。あるいは、M2Mネットワークアプリケーション18aおよび18bは、同一のホスティングデバイス(同じく図示せず)上で記憶され、実行され、および/またはホスティングされてもよい。ホスティングデバイスは、例えばホスティングアプリケーションサーバを含む1つまたは複数のサーバを含んでもよく、ならびに1つまたは複数の汎用もしくは専用コンピュータ、パーソナルコンピュータ、メインフレーム、ミニコンピュータ、サーバ型コンピュータ、および/または任意の適切なオペレーティングシステムで動作し、ソフトウェアを実行することが可能なプロセッサベースのプラットフォームに配置してもよい。ホスティングデバイスは複数の要素を含んでもよく、それらの要素は1つの単一のデバイスに形成されてもよく、ならびにサービングノード、クライアントノード、ピアノードまたはその他のノードの単一のノードに集中させてもよい。あるいは、ホスティングデバイスの要素は、2つ以上の別個のデバイスから形成されてもよく、したがってサービングノード、クライアントノード、ピアノードまたはその他のノードの複数のノード間で分散されてもよい。
ネットワークドメイン14は、アクセスネットワークおよび/またはコアネットワーク(アクセス/コア)ネットワーク20ならびにトランスポートネットワーク22を含んでもよい。アクセス/コアネットワーク22は、例えば、(i)デジタル加入者回線技術(総称して「xDSL」)、(ii)ハイブリッド光ファイバー/同軸ケーブル(HFC)ネットワーク、(iii)プログラマブルロジックコントローラ(PLC)、(iv)衛星通信およびネットワーク、(v)Global System for Mobile telecommunication(GSM:登録商標)/Enhanced Data GSM Environment(EDGE)radio access networks(GERAN)、(vi)ユニバーサル移動通信システム(UMTS)地上無線アクセスネットワーク(UTRAN)、(vii)発展型UTRAN(eUTRAN)、(viii)Worldwide Interoperability for Microwave Access(WiMAX)についての1つまたは複数のプロトコルに従って、通信のために構成されたネットワークであってもよい。アクセスおよび/またはコアネットワーク20を表すことができる例示的なアクセスおよび/またはコアネットワークの詳細は、下記で図48A〜48Eと関連して説明される。トランスポートネットワーク22を表すことができる例示的なトランスポートネットワークの詳細もまた、下記で図48A乃至48Eと関連して説明される。
アクセス/コアネットワーク20はまた、インターネットプロトコル(IP)スイートに従って接続性を提供してもよい。アクセス/コアネットワーク20は、他の通信プロトコルに従って接続性を提供してもよい。加えて、アクセス/コアネットワーク20は、サービスおよびネットワーク制御機能、他のネットワークとの相互接続、およびローミングサービスを提供してもよい。例として、アクセス/コアネットワーク20は、3GPP、ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking(TISPAN)により公表されたプロトコル、および3GPP2により公表されたプロトコルに従って、通信のために構成されたネットワークであってもよい。
アクセス/コアネットワーク20は、M2Mサーバ24aを含んでもよく、ならびにトランスポートネットワーク22は、M2Mサーバ24bおよび24cを含んでもよい。M2Mサーバ24a乃至24cの各々は、それぞれのサービスプロバイダにより所有、維持、および/または運用されてもよい。例えば、M2Mサーバ24aは、無線(例えばセルラ)電気通信サービスプロバイダにより所有、維持、および/または運用されてもよく、一方、M2Mサーバ24bおよび24cは、他のサービスプロバイダにより所有、維持、および/または運用されてもよい。場合によっては、第1、第2および第3のM2Mサーバ24a乃至24c各々の所有、維持、および/または運用は、2つ以上のプロバイダ間で分割されてもよい。
M2Mサーバ24a乃至24cは、それぞれのネットワークサービス能力レイヤ(N−SCL)26a乃至26cおよびそれぞれのネットワーク通信プロトコルスタック28aおよび28cを含んでもよく、または含むように構成されてもよい(図1B)。N−SCL26a乃至26cは、それぞれのM2M SC(N−SC)30a乃至30cおよびそれに伴うリソース構造32a乃至32cを含んでもよい(図1B)。
デバイスドメイン12は、M2Mデバイス34a乃至34g、M2Mゲートウェイ36aおよび36b、ならびにM2Mエリアネットワーク38aおよび38bを含んでもよい。M2Mデバイス34a乃至34gは、ぞれぞれのM2Mアプリケーション(DA)40a乃至40h、およびそれぞれのネットワーク通信プロトコルスタック42a乃至42gを含んでもよい。M2Mデバイス34a乃至34gの一部、すなわちM2Mデバイス34a乃至34d(以降「D34a乃至34d」または「Dタイプのデバイス34a乃至34d」)は、それぞれのSCL(D−SCL)44a乃至44dを含んでもよく、または含むように構成されてもよい。D−SCL44a乃至44dは、それぞれのSC(D−SC)46a乃至46d、およびそれに伴うリソース構造48a乃至48dを含んでもよく、または含むように構成されてもよい(図1B)。
M2Mデバイス34e乃至34g(以降「D’34e乃至34g」または「D’タイプのデバイス34e乃至34g」)はD−SCLを有さない。D34a乃至34dはその他の方式でD’34e乃至34gと異なってもよい。例えば、D’34e乃至34fは、処理電力およびメモリの制限などのリソース制約を受ける場合があるのに対し、D34a乃至34dはそのようなリソース制約を受けない場合がある。代わりに、および/またはそれに加えて、D’34e乃至34gは、D−SCL44a乃至44dと異なる機能を含んでもよく、含むように構成されてもよい。
M2Mゲートウェイ36aおよび36bは、それぞれのM2Mアプリケーション(GA)50aおよび50b、それぞれのネットワーク通信プロトコルスタック52aおよび52b、ならびにそれぞれのSCL(G−SCL)54aおよび54bを含んでもよく、または含むように構成されてもよい(図1)。G−SCL54aおよび54bは、それぞれのSC(G−SC)56aおよび56b、ならびにそれに伴うリソース構造58a乃至58eを含んでもよく、または含むように構成されてもよい(図1B)。
M2Mエリアネットワーク38aおよび38bは、M2Mゲートウェイ36aおよび36b、ならびに存在する場合には他のM2Mゲートウェイ(図示せず)に通信可能に結合されてもよい。M2Mエリアネットワーク38aおよび38bは、D34dおよびD’34e〜34gに加えてM2Mデバイス(図示せず)を含んでもよい。それらの追加的なM2Mデバイスは、Dタイプのデバイスであってもよく、またはD’タイプのデバイスであってもよい。M2Mエリアネットワーク38aおよび38bの各々は、例えばメッシュアーキテクチャおよび/またはピアツーピアアーキテクチャを使用して構成されてもよい。
D34dとD’34eとをともに通信可能に結合し、ならびに/またはD34d、D’34e間、および/もしくはM2Mエリアネットワーク38aの隣接M2Mデバイス間を通信可能に結合する通信リンクは、有線および/または無線であってもよい。D’34fおよび34gをともに通信可能に結合し、ならびに/またはD’34f、34gおよび/もしくはM2Mエリアネットワーク38bの隣接M2Mデバイス間を通信可能に結合する通信リンクも、有線および/または無線であってもよい。
D34d、D’34eおよびM2Mエリアネットワーク38aの他のM2Mデバイスを、M2Mゲートウェイ36aに通信可能に結合する通信リンクと、D’34f、34gおよびM2Mエリアネットワーク38bの他のM2MデバイスをM2Mゲートウェイ36bに通信可能に結合する通信リンクとは、有線および/または無線であってもよい。これらの通信リンクの各々は、独自インタフェース、標準インタフェースおよび/またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばdIa基準点などの基準点として定義されてもよい。そのようなdIa基準点に相当する例示的なdIa基準点の詳細は、ETSI TS 102 690で見られる。
M2Mゲートウェイ36a、M2Mゲートウェイ36b、D34b乃至34c、およびD34aは、有線および/または無線の通信リンクを介して、それぞれM2Mサーバ24a、24b、および24cに通信可能に結合してもよい。これらの通信リンクは、独自インタフェース、標準インタフェースおよび/またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばmIa基準点などの基準点として定義されてもよい。そのようなmIa基準点に相当する例示的なmIa基準点の詳細は、ETSI TS 102 690で見られる。
M2Mネットワークアプリケーション18aをM2Mサーバ24aと通信可能に結合し、ならびにM2Mネットワークアプリケーション18bをM2Mサーバ24bおよび24cと通信可能に結合する通信リンクは、有線および/または無線であってもよい。これらの通信リンクの各々は、独自インタフェース、標準インタフェースおよび/またはオープンインタフェースに準拠して定義されてもよい。あるいは、これらの通信リンクは、例えばmIa基準点などの基準点として定義されてもよい。そのようなmIa基準点に相当する例示的なmIa基準点の詳細はETSI TS 102 690で見られる。
D34a乃至34dのDA40a乃至40dと、D−SCL44a乃至44dとのそれぞれの間の通信は、mIa基準点を使用して実施されてもよい。dIaおよびmIa基準点は、M2Mネットワークアプリケーション18bとDA40a乃至40eとの間、およびM2Mネットワークアプリケーション18aとDA40f〜40gとの間に統一したインタフェースを提供してもよい。
図1には2つのM2Mゲートウェイと8つのM2Mデバイスが示されるが、デバイスドメイン12は、それよりも多いまたは少ないM2Mゲートウェイ、およびそれよりも多いまたは少ないM2Mデバイスを含んでもよい。実際には、デバイスドメイン12は、多数のM2Mデバイス、および多数のM2Mゲートウェイを有するであろう。加えて、かつ/または代わりに、システム10は、より多いまたは少ないM2Mサーバ、より多いまたは少ないM2Mネットワークアプリケーション、およびより多いまたは少ないM2Mエリアネットワークを含んでもよい。
M2Mエリアネットワーク38aおよび38bの各々は、例えば電気電子技術者学会(IEEE)802.15.x、Zigbee(登録商標)、Bluetooth(登録商標)、Internet Engineering Task Force(IETF)Routing Over Low power and Lossy networks(ROLL)、International Society of Automation(ISA)Wireless Systems for Industrial Automation、およびProcess Cotrol and Related Application(ISA100.11a)などのパーソナルエリアネットワークプロトコルに準拠して、通信のために構成されたネットワークであってもよい。M2Mエリアネットワーク38aおよび38bは、例えば図48A乃至48Eに関連して下記で説明するような他のネットワークプロトコルに準拠して構成されてもよい。
ここで図1Cを参照すると、N−SC30a乃至30cの各々は、アプリケーション実施可能能力(AE:application enablement capability)、汎用通信能力(GC:generic communication capability)、到達可能性(reachability)、アドレス指定・リポジトリ能力(RAR:addressing and repository capability)、通信選択能力(CS:communication selection capability)、リモートエンティティ管理能力(REM:remote entity management capability)、セキュリティ能力(SEC:security capability)、履歴・データ保持能力(HDR:history and data retention capability)、トランザクション管理能力(TM:transaction management capability)、相互動作プロキシ能力(IP:interworking proxy capability)、ならびに電気通信オペレータ公開能力(TOE:telecom operator exposure capability)を含んでもよく、または含むように構成されてもよく、当該能力の各々は、1つの能力から別の能力へ、情報(例えば処理されたメッセージから)を渡すためのルーティング機能に接続されてもよい。N−SC30a乃至30cの各々は、内部ソフトウェアのスケジューリング、オペレーティングシステムインタフェースの管理等を行うマネージャを含んでもよい。
G−SC56aおよび56bの各々、ならびにD−SC46a乃至46dの各々も、マネージャとともにルーティング機能に接続されたAE、GC、RAR、CS、REM、SEC、HDR、TM、およびIPを含んでもよい。便宜上、以下では、AE、GC、RAR、CS、REM、SEC、HDR、TM、ルーティング機能およびマネージャに、プレフィックス「N」、「G」、または「D」を付加して、N−SC、G−SC、およびD−SCを区別する。AE、GC、RAR、CS、REM、SEC、HDR、TM、ルーティング機能およびマネージャに、プレフィックス「x」を付加して、N−SC、G−SCおよびD−SCとまとめて称する。
N−SC30a乃至30c、G−SC56a、56b、およびD−SC46a乃至46dの各々は、SCツーSCの対話能力も含んでもよく、それによりデバイスツーデバイス(D2D)、ゲートウェイツーゲートウェイ(G2G)、およびサービスツーサーバ(S2S)の直接の通信を可能にする。N−SC30a乃至30c、G−SC56a、56b、およびD−SC46a乃至46d(総称して「xSC」)の一部またはすべての一部分は、例えばETSI TS 102 690などのM2M通信および/または動作に関する標準に準拠して定義されてもよい。
一般に、SCは、様々なM2Mアプリケーションにより利用され得る機能を定義し、および/または実装してもよい。それを容易にするために、SC24は、オープンインタフェースのセットを通じてそのような機能を様々なM2Mアプリケーションに公開してもよい。加えて、SCは、アクセス/コアネットワークおよび/またはトランスポートネットワーク20、22の機能(ネットワーク機能)を使用してもよい。ただし、SCは、ネットワークの仕様を様々なM2Mアプリケーションから隠蔽し、代わりにSCを介してそのようなアプリケーションに対し、ネットワーク管理を扱ってもよい。SCはM2M専用としてもよい。あるいは、SCは汎用的であってもよく、例えばM2MアプリケーションとM2Mアプリケーション以外のアプリケーションへのサポートを提供してもよい。下記でより詳細に説明するように、N−SCLリソース構造32a乃至32c、G−SCLリソース構造58a乃至58e、および/またはD−SCL44a乃至44dの各々は、xSCのうち1つまたは複数のアーキテクチャに基づいて、階層として配置される1つまたは複数のリソースおよび/または属性を含んでもよい。
例示的なxREM管理レイヤおよび機能
図2は、xREMを実行するための機能アーキテクチャを定義する論理管理レイヤ200の例示的なセットを示すブロック図である。一般に、管理レイヤ200は、通信モジュール、SCL、およびアプリケーションを管理するための機能を定義することができる。また、管理レイヤ200は、管理機能を区別し、対応する管理オブジェクトおよびリソース構造を定義し、xREMでそれぞれM2Mデバイス(DREM)、M2Mゲートウェイ(GREM)、およびM2Mエリアネットワーク(NREM)に対する管理機能を特定することができる。管理レイヤ200の管理機能の区別は、M2Mリモートエンティティのタイプに基づいていてもよい。管理レイヤ200は、例えば、(i)M2Mアプリケーション(ii)M2M SC(iii)M2MエリアネットワークおよびM2Mゲートウェイ(iv)M2Mデバイス、を管理するための機能を定義する別個のレイヤを含んでもよい。管理レイヤ200の各々は、その管理レイヤに存在するM2Mリモートエンティティの構成管理210、障害管理212、性能管理214などを実行するための機能を含んでもよい。一実施形態では、管理レイヤ200は、アプリケーション管理レイヤ202、サービス管理レイヤ204、ネットワーク管理レイヤ206、およびデバイス管理レイヤ208を含んでもよい。管理レイヤ200はその他のレイヤも含んでもよい。
例示的なM2Mアプリケーション管理レイヤ
M2Mアプリケーション管理レイヤ202は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにM2Mアプリケーションを管理することに関連するxREMにおける管理機能を特定することを含む、M2Mアプリケーションの管理を扱ってもよい。M2Mアプリケーション管理レイヤ202は、M2Mデバイスおよび/またはM2Mゲートウェイ(総称して「D/G」)におけるM2Mアプリケーションのライフサイクル管理を扱ってもよく、それは、D/Gにおけるアプリケーションソフトウェアのインストール、更新、削除、起動、無効化のいずれかを含んでもよい。M2Mアプリケーション管理レイヤ202はまた、D/Gにおけるアプリケーションの構成管理を扱ってもよい。このことは、例えばそのようなアプリケーションの初期設定および/または更新を構成すること、および/またはプロビジョニングすることを含んでもよい。M2Mアプリケーション管理レイヤ202は、例えば障害関連情報を収集すること、および/または読み出すことを含む、D/Gにおけるアプリケーションの障害管理を扱ってもよい。M2Mアプリケーション管理レイヤ202は、例えば性能関連情報を収集すること、および/または読み出すことを含む、D/Gにおけるアプリケーションの性能管理を扱ってもよい。M2Mアプリケーション管理レイヤ202の所有者は、例えばM2Mアプリケーションプロバイダである。
例示的なM2Mサービス管理レイヤ
M2Mサービス管理レイヤ204は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにM2M SCを管理することに関連するxREMにおける管理機能を特定することを含む、M2MのSCの管理を扱ってもよい。M2Mサービス管理レイヤ204は、D/GにおけるSCLのソフトウェア/ファームウェアの更新、SCLの初期設定および/または更新の構成またはプロビジョニングを含む、D/GにおけるSCLの構成管理、例えば障害関連情報を収集すること、および読み出すことを含むD/GにおけるSCLの障害管理、ならびに性能関連情報を収集すること、および読み出すことを含むD/GにおけるSCLの性能管理を扱ってもよい。M2Mサービス管理レイヤ204の所有者は、例えばM2Mサービスプロバイダである。
例示的なM2Mネットワーク管理レイヤ
M2Mネットワーク管理レイヤ206は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにM2Mエリアネットワークを管理することに関連するxREMにおける管理機能を特定することを含む、M2Mエリアネットワークを管理することを扱ってもよい。例えば、このレイヤは、ルーティング管理、トポロジ管理、およびネットワークライフサイクル管理を制御してもよい。M2Mエリアネットワークは多くの場合はM2M GWによって接続されるため、M2M GWはネットワーク管理レイヤ206においての役割を担ってもよい。
M2Mネットワーク管理レイヤ206は、例えば、IPv6アドレスのプレフィクス、動作周波数、WPAN IDなどを構成することを含む、M2Mエリアネットワークの初期動作設定を構成すること、および/またはプロビジョニングすることを含む、M2Mエリアネットワークの設定管理を扱ってもよい。M2Mネットワーク管理レイヤ206はまた、(i)6LoWPAN/ROLL/CoAPにおけるパラメータおよび/または定数の更新を含む、D/Gの構成を更新すること(ii)異常の検出(例えば失効したルーティングまたは誤ったルーティング、ループバックルーティングなど)ならびに/または警告の生成および/もしくは処理を含む、M2Mエリアネットワークの障害管理(iii)M2Mエリアネットワーク(例えば全体)のデューティサイクル管理、トポロジ/ルーティング管理およびQoS管理を含む、M2Mエリアネットワークの性能管理を扱ってもよい。ネットワーク管理レイヤ206の所有者はM2Mエリアネットワークプロバイダであり、これは、M2Mアプリケーションプロバイダ、M2Mサービスプロバイダ、またはM2Mユーザとすることができる。
例示的なM2Mデバイス管理レイヤ
デバイス管理レイヤ208は、管理機能を定義すること、管理オブジェクトおよびリソース構造を定義すること、ならびにM2Mエンドデバイスに関連するxREMにおける管理機能を特定することを含む、D/GなどのM2Mエンドデバイスの管理を扱ってもよい。デバイス管理レイヤ208は、リソースに制約のあるM2Mデバイスに対する管理機能を扱ってもよく、これは例えばデューティサイクル管理および電力管理を含んでもよい。デバイス管理レイヤ208は、(i)D/Gの初期動作を構成すること、および/またはD/Gの構成を更新することを含む、D/Gの構成管理、(ii)異常の検出や警告の生成および処理を含む、D/Gの障害管理、(iii)例えば、制約のあるリソース(センサ、アクチュエータ、電源/バッテリ、メモリ、CPU、通信インタフェースなど)の管理、節電管理(例えばノード全体のデューティサイクル、トランシーバのデューティサイクル)、センサおよびアクチュエータの管理(例えば種々のアプリケーション間で共有すること)を含むことができる、D/Gの性能管理、を扱ってもよい。デバイス管理レイヤ208の所有者は、M2Mアプリケーションプロバイダ、M2Mサービスプロバイダ、M2Mエリアネットワークプロバイダ、またはM2Mユーザであってもよい。
図3Aを参照すると、管理レイヤのセットとそれらの機能に従ってリソース構造を備えるSCLをプロビジョニングするための例示的なリソース構造のフレームワーク300を示すブロック図が示される。そのようなリソース構造をプロビジョニングすることができるSCLは、例えばN−SCL26a乃至26cのいずれかなどのホスティングSCLであってもよい。ホスティングSCL上にプロビジョニングされたリソース構造は、後に、そのホスティングSCL、他のホスティングSCLおよび/またはリモートSCL間の同期を介して、1つまたは複数の他のホスティングSCLおよび/またはG−SCL56a、56bおよび/またはD−SCL44a乃至44dなどの1つまたは複数のリモートSCL上でプロビジョニング(例えばすべてまたは一部を複製)されてもよい。あるいは、そのようなリソースがプロビジョニングされるSCLは、G−SCL56a、56bおよび/またはD−SCL44a乃至44dなどのリモートSCLであってもよい。リモートSCL上でプロビジョニングされたリソース構造は、後に、そのリモートSCL、他のリモートSCLおよび/またはホスティングSCL間の同期を介して、N−SCL26a乃至26cなどの1つまたは複数の他のリモートSCLおよび/または1つまたは複数のホスティングSCL上でプロビジョニング(例えば全体または一部を複製)されてもよい。加えて、かつ/またはこれに替えて、リソース構造フレームワーク300は、複数のホスティングSCLおよび/または複数のリモートSCL上でリソース構造をプロビジョニングするために使用されてもよい。
リソース構造フレームワーク300は、適切なSCLのルートリソース(「<sclBase>」)302、<sclBase>302の下位にある複数のリソース(「下位リソース」)、および、1つまたは複数の属性304(「attribute」)を含んでもよい。attribute304は、<sclBase>302から直下にある下位リソースの一部またはすべてに関連付けられてもよい(例えば共通している)。あるいは、attribute304は、<sclBase>302から直接かつ/または間接的に下位にある下位リソースに関連付けられてもよい。<sclBase>302から直接下位にある下位リソースは、SCL(「scl」)下位リソース306、アプリケーション(「applications」)下位リソース308、コンテナ(「containers」)下位リソース310、グループ(「groups」)下位リソース312、アクセス権(「accessRights」)下位リソース314、サブスクリプション(「subscriptions」)下位リソース316、検出(「discovery」)下位リソース318、アクセスステータス(「accessStatus」)下位リソース320、および管理オブジェクト(「mgmtObjs」)下位リソース322を含んでもよい。
scls下位リソース306は、個々のSCLリソースの集合であってもよく、SCLリソースの各々は、例えばM2Mサービス登録プロシージャを介してホスティングSCLと対話する権限が与えられた、関連付けられた(例えばリモートの)SCLを表してもよい。scls下位リソース306の各SCLリソースは、関連付けられたSCLのそのローカルSCLへの成功した登録、またはその逆の成功した登録に応じて作成されてもよい。scls下位リソース306は、個々の登録されたSCLについてのコンテキスト情報を含み、維持し、かつ/または格納してもよい。scls下位リソース306の各々は、1つまたは複数の下位リソースおよび/または1つまたは複数の属性(図示せず)を含んでもよい。
applications下位リソース308は、個々のアプリケーションリソースの集合であってもよく、リソースの各々は、アプリケーションについての情報を含み、維持し、かつ/または格納してもよい。applications下位リソース308の各アプリケーションリソースは、関連するアプリケーションのローカルSCLへの成功した登録に応じて作成されてもよい。
containers下位リソース310は、個々のコンテナリソースの集合であってもよく、リソースの各々は、アプリケーション間および/またはSCL間で情報を交換するのに使用する汎用的なリソースであってもよい。containers下位リソース310の各コンテナリソースは、対応するコンテナを、情報をバッファリングするための仲介として使用することにより、アプリケーション間および/またはSCL間の情報の交換を容易にしてもよい。
groups下位リソース312は、個々のグループリソースの集合であってもよい。groups下位リソース312の各グループリソースが使用されて、<sclBase>302から直接かつ/または間接的に下位にある下位リソースを含む他の、下位リソースのグループを定義し、および/または下位リソースのグループにアクセスしてもよい。
accessRights下位リソース314は、個々のアクセス権(「accessRight」)リソースの集合であってもよく、リソースの各々は、パーミッションの表現を含み、維持し、かつ/または格納してもよい。accessRights下位リソース314の各accessRightリソースは、ホスティングSCLの外部にあるエンティティにアクセス可能な他の下位リソースの1つまたは複数に関連付けられてもよい。accessRights314の各々のパーミッションの表現は、パーミッション所有者の識別、およびパーミッションの所有者に付与された権利の識別を含んでもよい。パーミッション所有者に付与された権利の識別は、例えば、対応する下位リソースについて付与された権利の1つまたは複数に関連付けられたパーミッションフラグとしてもよい。
subscriptionsの下位リソース316は、個々のサブスクリプションリソースの集合であってもよい。subscriptions316の各サブスクリプションリソースは、その親リソース、すなわち<sclBase>302への(例えばアクティブな)サブスクリプションのステータスを追跡するための情報を含んでもよい。各subscriptions316は、<sclBase>302上の変更の通知についての、発行元からの要求を表してもよい。
discovery318が使用されて、下位リソースの検出を可能にしてもよい。discovery318が使用されて、検出フィルタ基準に一致する下位リソースのユニフォームリソース識別子(URI)のリストを読み出してもよい。accessStatus320は、個々のアクセスステータスリソースの集合であってもよい。
mgmtObjs下位リソース322は、個々の管理オブジェクト(「mgmtObj」)リソースの集合であってもよい。mgmtObjs322の各mgmtObjリソースは、REMを実行するための管理情報および/またはパラメータを含み、維持し、および/または格納してもよい。mgmtObjs下位リソース322は、アプリケーション管理オブジェクト下位リソース(「appMgmtObjects」)下位リソース324、SCL管理オブジェクト下位リソース(「sclMgmtObjects」)下位リソース326、ネットワーク管理オブジェクト下位リソース(「nwkMgmtObjects」)下位リソース328、デバイス管理オブジェクト下位リソース(「devMgmtObjects」)下位リソース330、OMA−DM管理オブジェクト下位リソース(「omaMgmtObjects」)下位リソース332、およびBBF−TR069管理オブジェクト下位リソース(「bbfMgmtObjects」)下位リソース334を含んでもよい。mgmtObjs下位リソース322はまた、その他のmgmtObjリソースおよび/または異なるmgmtObjリソースを含んでもよい。
appMgmtオブジェクト下位リソース324は、個々のアプリケーション管理オブジェクト(「appMgmtObject」)リソースの集合であってもよい。各appMgmtオブジェクトリソースは、アプリケーション管理レイヤ202(図2)などのアプリケーション管理レイヤ、およびその機能に従ってREMを実行するための情報および/またはパラメータを含んでもよい。各appMgmtオブジェクトリソースは、<mgmtObject>インスタンス324−1として、appMgmtObjects下位リソース324の下位に配置されてもよい。
sclMgmtObjects下位リソース326は、個々のSCL管理オブジェクト(「sclMgmtObject」)リソースの集合であってもよい。各sclMgmtオブジェクトリソースは、サービス管理レイヤ204(図2)などのサービス管理レイヤとその機能に従ってREMを実行するための情報、および/またはパラメータを含んでもよい。各sclMgmtオブジェクトリソースは、<mgmtObject>インスタンス326−1として、sclMgmtObjects下位リソース326の下位に配置されてもよい。
nwkMgmtObjects下位リソース328は、個々のネットワーク管理オブジェクト(「nwkMgmtObject」)リソースの集合であってもよい。各nwkMgmtObjectリソースは、ネットワーク管理レイヤ206(図2)などのネットワーク管理レイヤおよびその機能に従ってREMを実行するための情報および/またはパラメータを含んでもよい。各nwkMgmtObjectリソースは、<mgmtObject>インスタンス328−1としてnwkMgmtObjects下位リソース328の下位に配置されてもよい。
devMgmtObjects下位リソース330は、個々のデバイス管理オブジェクト(「devMgmtObject」)リソースの集合であってもよい。各devMgmtObjectリソースは、デバイス管理レイヤ208(図2)などのデバイス管理レイヤおよびその機能に従ってREMを実行するための情報および/またはパラメータを含んでもよい。各devMgmtオブジェクトリソースは、<mgmtObject>インスタンス330−1としてdevMgmtObjects下位リソース330の下位に配置されてもよい。
omaMgmtObjects332は、個々のOMA−DM管理オブジェクト(「omaMgmtObject」)リソースの集合であってもよい。各omaMgmtObjectリソースは、OMA−DMおよび/またはOMA−DMと互換性のある管理機能に従ってREMを実行するための情報および/またはパラメータを含んでもよい。各omaMgmtObjectリソースは、<mgmtObject>インスタンス332−1として、omaMgmtObjects下位リソース332の下位に配置されてもよい。
bbfMgmtObjects下位リソース334は、個々のBBF−TR069管理オブジェクト(「bbfMgmtObject」)リソースの集合であってもよい。各bbfMgmtObjectリソースは、BBF−TR069および/またはBBF−TR069と互換性のある管理機能、例えばBBF−TR069のリモートプロシージャコール(RPC)メソッドに従ってREMを実行するための情報および/またはパラメータを含んでもよい。各bbfMgmtObjectリソースは、<mgmtObject>インスタンス334−1としてbbfMgmtObjects下位リソース334の下位に配置されてもよい。
mgmtObjs下位リソース322は、図3Aに示すように<sclBase−of−Server>/scls/<scl>/mgmtObjsのみに存在するが、他の(例えば複数の)mgmtObjs下位リソースは、<sclBase>302の様々なより下位の枝/位置に配置されてもよい。そのようにすると、そのような他のmgmtObjs下位リソースは、特定の管理機能(アプリケーションやSCLなど)に明示的に対応することができる。
図3Bは、管理レイヤのセットおよびその機能に従ったリソース構造を備えるSCLをプロビジョニングするための例示的なリソース構造フレームワーク340を示すブロック図である。そのようなリソース構造をプロビジョニングすることができるSCLは、例えばG−SCL56a、56bおよび/またはD−SCL44a乃至44dなどのいずれかのローカルSCLである。ローカルSCL上でプロビジョニングされたリソース構造は、後に、そのローカルSCLおよび/またはホスティングSCL間の同期を介して、1つまたは複数の他のホスティングSCLおよび/またはN−SCL26a乃至26cなどの1つまたは複数のリモートSCL上でプロビジョニング(例えば全体または一部を複製)されてもよい。あるいは、そのようなリソース構造をプロビジョニングすることができるSCLは、N−SCL26a乃至26cなどのホスティングSCLであってもよい。ホスティングSCL上でプロビジョニングされたリソース構造は、後に、ホスティングSCLとリモートSCL間の同期を介して、G−SCL56a、56bおよび/またはD−SCL44a乃至44dなどの1つまたは複数の他のリモートSCL上でプロビジョニング(例えば全体または一部を複製)されてもよい。加えて、かつ/またはこれに替えて、リソース構造フレームワーク340は、複数のローカルSCLおよび/または複数のホスティングSCL上でリソース構造をプロビジョニングするために使用されてもよい。
リソース構造フレームワーク340は、<sclBase>342、<sclBase>342への複数の下位リソース、<sclBase>342から直接下位にある下位リソースの一部またはすべてに関連付けられた1つまたは複数の属性344(「attribute」)、ならびに<sclBase>342から間接的に下位にある下位リソースに関連付けられたattribute350およびattributeを含んでもよい。
<sclBase>342から直接下位にある下位リソースは、以下の点を除いては図3Aの<sclBase>302から直接下位にある下位リソースと同様である。<sclBase>342から直接下位にある下位リソースは、applications下位リソース346およびmgmtObjs下位リソース348を含んでもよい。
mgmtObjs下位リソース348(<sclBase>/mgmtObjsにおける)は、個々の管理オブジェクト(「mgmtObj」)リソースの集合であってもよい。mgmtObjs下位リソース348は、(i)サービス管理レイヤおよびその機能、(ii)ネットワーク管理レイヤおよびその機能(iii)デバイス管理レイヤおよびその機能(iv)OMA−DMおよび/またはOMA−DMと互換性のある管理機能(v)BBF−TR069および/またはBBF−TR069と互換性のある管理機能のいずれかに従って、REMを実施するための管理情報および/またはパラメータを含み、維持し、および/または格納してもよい。mgmtObjs下位リソース348は、例えば、sclMgmtObjects下位リソース326、nwkMgmttObjects下位リソース328、devMgmtObjects下位リソース330、omaMgmtObjects下位リソース332、およびbbfMgmttObjects下位リソース334を含んでもよい。mgmtObjs下位リソース348は、他のmgmtObjリソースおよび/または異なるmgmtObjリソースも含んでもよい。
applications下位リソース346は、個々のアプリケーション(「<applciation>」)リソース352、accessStatus下位リソース354、subscriptions下位リソース356、mgmtObjs下位リソース358、およびapplications下位リソース346の下位リソースに関連する属性350の集合を含んでもよい。mgmtObjs下位リソース358(<sclBase>/applications/mgmtObjsにおける)は、<sclBase>342の下に登録されたすべてのアプリケーションのREMを全体として実行するための下位リソースの集合を含んでもよい。
個々のアプリケーションリソース352の各々は、containers下位リソース362、groups下位リソース364、accessRights下位リソース366、accessStatus下位リソース368、subscriptions下位リソース370、mgmtObjs下位リソース372、および対応する個々のアプリケーションリソースの下位リソース352に関連するattribute360を含んでもよい。mgmtObjs下位リソース372(<sclBase>/applications/<application>/mgmtObjsに位置するにおける)は、対応する<application>下位リソース352に関連付けられた特定の<application>のREMを実行するための下位リソースの集合を含んでもよい。
図3Cは、管理レイヤのセットおよびその機能に従ったリソース構造を有するSCLをプロビジョニングするための例示的なリソース構造フレームワーク376を示すブロック図である。そのようなリソース構造をプロビジョニングすることができるSCLは、例えばN−SCL26a乃至26cなどのいずれかのホスティングSCLであってもよい。ホスティングSCL上でプロビジョニングされたリソース構造は、後に、そのホスティングSCL、他のホスティングSCLおよび/またはリモートSCL間の同期を介して、1つまたは複数の他のホスティングSCLおよび/またはG−SCL56a、56bやD−SCL44a乃至44dなどの1つまたは複数のリモートSCL上でプロビジョニングされてもよい(例えば全体または一部を複製する)。あるいは、そのようなリソース構造をプロビジョニングすることができるSCLは、G−SCL56a、56bおよび/またはD−SCL44a乃至44dなどのいずれかのリモートSCLであってもよい。リモートSCL上でプロビジョニングされたリソース構造は、後に、そのリモートSCL、他のリモートSCLおよび/またはホスティングSCL間の同期を介して、1つまたは複数の他のリモートSCLおよび/またはN−SCL26a乃至26cなどの1つまたは複数のホスティングSCL上でプロビジョニングされてもよい(例えば全体または一部を複製する)。加えて、かつ/またはこれに替えて、リソース構造のフレームワーク340を使用して、複数のホスティングSCLおよび/または複数のリモートSCL上でリソース構造をプロビジョニングしてもよい。
リソース構造フレームワーク376は、<sclBase>378、<sclBase>378への複数の下位リソース、<sclBase>378から直接および/または間接的に下位にある下位リソースの一部またはすべてに関連する1つまたは複数の属性を含んでもよい。<sclBase>378から直接下位にある下位リソースは、<sclBase>378から直接下位にmgmtObjs下位リソースがない点を除いて、図3Aの<sclBase>302から直接下位にあるリソースと同様である。代わりに、リソース構造フレームワーク376は、<sclBase>376の様々なさらに下位にある枝/位置に配置することができる複数のmgmtObjs下位リソースを含む。例えば、<sclBase>376は、mgmtObjs下位リソース380(<sclBase>scls/mgmtObjsに位置する)を含んでもよい。mgmtObjs下位リソース380は、M2Mサーバに登録されたすべてのSCLのREMを全体として実行するための下位リソースの集合を含んでもよい。それらの下位リソースは、サービス管理レイヤ204(図2)などのサービス管理レイヤおよびその機能に従って、M2Mサーバに登録されたすべてのSCLのREMを全体として実行するための情報および/またはパラメータを含んでもよい。
<sclBase>376はまた、mgmtObjs下位リソース382(<sclBase>/scls/<scl>/mgmtObjsにおける)も含んでもよい。このmgmtObjs下位リソース382は、M2Mサーバに登録された<scl>のサービス能力および他の管理機能(ネットワーク管理レイヤおよびデバイス管理レイヤ)のREMを実行するための下位リソースの集合を含んでもよい。一実施形態では、当該下位リソースは、(i)ネットワーク管理レイヤ206(図2)などのネットワーク管理レイヤおよびその機能、ならびに(ii)デバイス管理レイヤ208(図2)などのデバイス管理レイヤ、に従ってM2Mサーバに登録された<scl>のサービス能力および他の管理機能のREMを実行するための情報および/またはパラメータを含んでもよい。
<sclBase>376はまた、mgmtObjs下位リソース384(<sclBase>/scls/<scl>/applications//mgmtObjsにおける)も含んでもよい。mgmtObjs下位リソー384は、サーバに通知されたすべてのアプリケーションのREMを全体として実行するための下位リソースの集合を含んでもよい。<sclBase>376はさらに、mgmtObjs下位リソース386(<sclBase>/scls/<scl>/applications/<applicationAnnc>/mgmtObjsにおける)を含んでもよい。このmgmtObjs下位リソース386は、M2Mサーバに通知された特定の<applicationAnnc>のREMを実行するための下位リソースの集合を含んでもよい。
一実施形態では、mgmtObjs下位リソース382(<sclBase>/scls/<scl>/mgmtObjsにおける)は、M2Mサーバに登録する別のD/Gを管理するために、DAおよび/またはGAによって使用されてもよい。M2Mサーバ(すなわち<scl>)は、自身の<mgmtObj>をD/Gに知らせてもよい。次いでDA/GAは、D/Gにおけるそのような通知された<mgmtObj>にアクセスすることができ、それによりM2Mサーバにおけるメッセージングの中継を介して他のD/Gを管理することが可能になる。
図4Aは、mgmtObjsを備えるSCLをプロビジョニングするための例示的なリソース構造フレームワーク400を示すブロック図である。リソース構造フレームワーク(「mgmtObjs構造フレームワーク」)400は、ルートとしてのmgmtObjs402、mgmtObjs402への複数の下位リソース、mgmtObjs402から直接下位にある下位リソースの一部またはすべてに関連する1つまたは複数の属性404(「attribute」)、およびmgmtObjs402から間接的に下位にある下位リソースに関連するattribute416、418、430、および442を含んでもよい。attribute404は、accessRightID、creationTime、lastModifiedTime、mgmtObjs402のテキスト形式の詳細などの詳細、およびallowedMethodを含んでもよい。allowedMethodは、mgmtObjs下位リソース402を処理するための許可されたRESTfulメソッドを指定してもよい。
mgmtObjs402への複数の下位リソースは、mgmtObj(「<mgmtObj>」)下位リソース406、管理オブジェクトアナウンス(「<mgmtObjAnnc>」)下位リソース408、accessRights下位リソース410、accessStatus下位リソース412、およびsubscriptions下位リソース414を含んでもよい。
<mgmtObj>下位リソース406は、特定の管理オブジェクトであってもよく、およびこの<mgmtObj>下位リソース406に対して関連する管理データ/パラメータを格納するためのプレースホルダであってもよい。<mgmtObjAnnc>下位リソース408は、公表された管理オブジェクトに対するプレースホルダであってもよい。<mgmtObjAnnc>下位リソース408は、以下の属性、(i)link、(ii)accessRightID、および(iii)searchStringsを含んでもよい。
<accessRights>下位リソース410は、REMを実行するために使用される下位リソースに対するパーミッションの表現を含み、保持し、かつ/または格納してもよい。<accessRights>下位リソース408は、親がある場合は親から継承されてもよい。
accessStatus下位リソース414は個々のアクセスステータスリソースの集合であってもよい。subscriptions下位リソース414は、サブスクリプションリソースの集合であってもよく、サブスクリプションリソースの各々は、その親リソースへの(例えばアクティブな)サブスクリプションのステータスを追跡するための情報を含んでもよい。subscriptions414の各々は、親リソース上の変更の通知について、発行元からの要求を表してもよい。
<mgmtObj>下位リソース406は、(i)管理目的の複数パラメータの集合に対するプレースホルダとすることができる<parameters>下位リソース420(ii)単一の管理パラメータとすることができる<parameter>下位リソース422(iii)xREM目的の<accessRights>下位リソース424(iv)<accessStatus>下位リソース426、および<subscriptions>下位リソース428、を含んでもよい。<accessRights>下位リソース424は、REMを実行するために使用される下位リソースについてのパーミッションの表現を含み、保持し、かつ/または格納してもよい。<accessRights>下位リソース424は、親がある場合は、親から継承されてもよい。
<mgmtObj>下位リソース406は、以下の属性、(i)accessRightID、creationTime、lastModifiedTime、description(例えば<mgmtObj>下位リソース406のテキスト形式の詳細)、allowedMethod、およびcontentType、を含んでもよい。allowedMethodは、<mgmtObj>下位リソース406を処理するための許可されたRESTfulメソッドを指定してもよい。contentTypeは、<mgmtObj>下位リソース406のタイプを指定してもよい。contentType属性はdataType属性とも称されてもよい。
<parameters>下位リソース420は、<parameters>下位リソース432を含んでもよい。この<parameters>下位リソース432は、管理目的の複数パラメータの集合に対するプレースホルダであってもよい。<parameters>下位リソース432を、<parameters>下位リソース432への下位にすることにより、階層ツリー構造をサポートすることができ、および既存の管理オブジェクトのインポートがフラット構造に比べて容易となり得る。
<parameters>下位リソース420はまた、(i)単一の管理パラメータを保持および/または格納するための<parameter>下位リソース434(ii)xREM目的の<accessRights> 下位リソース436(iii)<accessStatus>下位リソース438、および<subscriptions>下位リソース440、を含んでもよい。<accessRights>下位リソース436は、REMを実行するために使用される下位リソースに対するパーミッションの表現を含み、保持し、かつ/または格納してもよい。<accessRights>下位リソース436は、親がある場合は親から継承されてもよい。
<parameters>下位リソース420は、以下の属性、(i)accessRightID、(ii)creationTime、(iii)lastModifiedTime、(iv)description(例えば<parameters>下位リソース420のテキスト形式の詳細)(v)allowedMethod、および(vi)contentType/dataType、を含んでもよい。allowedMethodは、<mgmtObj>下位リソース436を処理するための許可されたRESTfulメソッドを指定してもよい。contentType/dataTypeは<mgmtObj>下位リソース436のタイプを指定してもよい。
さらに、図4Aの例に示すように、mgmtObjs402は、別の<parameters>下位リソース432を、<parameters>下位リソース420の下位に置くことにより、追加的な階層構造を有する。この下位構造では、<parameters>下位リソース420は、多くの<parameters>下位リソースと個々の<parameter>リソース434の両方を含んでもよい。このような階層構造は、他の管理ツリーをmgmtObjs402にインポートすることを簡素化することができ、および/またはツリー構造のマッピングを実行することを簡素化することができる。1つのコンテナ(またはグループ)リソースが、別のコンテナ(またはグループ)をその下位リソースとして持つcontentInstance(またはメンバ)の作成および使用を可能にするように適合されないかぎり、このような階層構造は<mgmtObj>下位リソース406およびその子(例えば既存のコンテナまたはグループリソースを使用する)なしでは実現できない可能性があることに留意されたい。
<parameter>リソース434は、(i)<parameter>下位リソース434のデフォルト値を含み、保持し、かつ/または格納することができる<defaultValue>下位リソース444(ii)<parameter>下位リソース434の現在の値を含み、保持し、かつ/または格納することができる<currentValue>下位リソース446(iii)xREM目的の<accessRights>下位リソース448(iv)<accessStatus>下位リソース450、および(v)<subscriptions>下位リソース444、を含んでもよい。<accessRights>下位リソース448は、REMを実行するために使用される下位リソースのパーミッションの表現を含み、保持し、かつ/または格納してもよい。<accessRights>下位リソース448は、親がある場合は親から継承されてもよい。
<parameter>リソース434は、以下の属性(i)accessRightID(ii)creationTime、(iii)lastModifiedTime(iv)description(例えば<parameter>リソース434のテキスト形式の詳細)、およびallowedMethod、を含んでもよい。allowedMethodは<parameter>リソース434を処理するための許可されたRESTfulメソッドを指定してもよい。
代替的な実施形態において、mgmtObjsを備えるSCLをプロビジョニングするための2つのレベルのリソース構造フレームワーク458を図4Bに示す。リソース構造フレームワーク458はmgmtObjs460を含んでもよい。mgmtObjs460は、mgmtObjs460が<parameters>下位リソース420を含まない点を除いて、図4AのmgmtObjs402と同様である。
例示的なM2MのxREM管理モデル
一実施形態では、xREMは、クライアント/サーバ(C/S)モデルで実装されてもよい。加えて、かつ/またはこれに替えて、xREMは、プロキシ機能を使用して、D 34dやD’34e乃至34(図1)など、M2M GWの後ろにあるM2Mデバイスを管理してもよい。
一実施形態では、xREMサーバは管理コントローラであってもよい。xREMサーバは、例えば、SNMPマネージャ、OMA DMに準拠したDMサーバ、およびBBF−TR069に準拠したACSのいずれかとして動作してもよく、またはそれらと同様の機能により動作してもよい。xREMサーバは、xREMクライアントおよびxREMプロキシとの対話を制御および管理してもよい。
一実施形態では、xREMクライアントは、xREMサーバによって制御されるソフトウェアエンティティであってもよい。xREMクライアントは、例えば、SNMPエージェント、OMA DMに準拠したDMクライアント、およびBBF TR−069に準拠したCPEのいずれかとして動作してもよく、またはそれらの同様の機能により動作してもよい。xREMサーバおよびxREMクライアントは協働して管理セッションを確立し、および管理機能を実行してもよい。
一実施形態では、xREMプロキシは、xREMクライアントおよびxREMサーバ両方の役割を果たしてもよい。xREMプロキシは、OMA DM、および/もしくはBBF TR−069に準拠して動作するM2Mデバイス、ならびに/またはSCLを有さないM2Mデバイスなど、D’タイプのデバイスを管理するための非xREM管理サーバ機能を有してもよい。xREMプロキシは、REMクライアントとxREMサーバ(または非xREM管理サーバ)との間の変換および/または適合(adaptation)機能を含んでもよい。例示的な機能は、xREMクライアントとxREMサーバとの間の変換、およびxREMクライアントと非xREM管理サーバとの間の変換を含んでもよい。
一実施形態では、xREMは、位置する場所に応じて、xREMサーバ(マネージャ)、xREMクライアント(管理されるエンティティ)、またはxREMプロキシ(マネージャおよび管理されるエンティティの両方として動作する)とすることができる。
図5は、xREMを実行するためのクライアント−サーバモデル500の図を示すブロック図である。xREMは、ETSI TS 102 960に準拠して実行されてもよい。図5を参照すると、NREM502はxREMサーバ502−1を含んでもよく、サーバ502−1は、DREM504およびGREM506のそれぞれxREMクライアント504−1および506−1、またはGREM510のxREMプロキシ510−1などの1つまたは複数のxREMクライアントとの通信対話を実行する。NREM502は、第3者の管理権限512、およびNREM508などの他のNREMとの別個のインタフェースを有してもよい。GREM510は、xREMクライアント510−2またはxREMプロキシ510−1として動作してもよい。M2MゲートウェイがM2Mサーバによって管理されることになるエンドデバイスとして動作するときに、GREM510は、xREMクライアントとして動作してもよい。M2Mゲートウェイが、M2MサーバがM2Mゲートウェイの後ろにあるM2Mデバイス(ETSI準拠または非ETSIのいずれか)を管理するためのプロキシとして動作するときに、GREM510はxREMプロキシとして動作してもよい。xREMプロキシ510−1として、GREM510は、xREMクライアント510−2、xREMサーバ510−3、非xREM管理サーバ510−4、およびプロトコル変換ユニット510−5を含んでもよい。DREM512 はxREMクライアント512−1を含んでもよい。xREMクライアント512−1は、NREM502におけるxREMサーバ502−1と対話してもよく、あるいは、xREMプロキシ510−1におけるxREMサーバ510−3と対話してもよい。
OMA DMが使用されてxREMを実装する場合、xREMサーバ502−1は、DMサーバであってもよく、およびxREMクライアント512−1は、DMクライアントであってもよい。xREMプロキシ510−1は、OMA GwMOであってもよい。BBF TR−069が使用されてxREMを実装する場合、xREMサーバ502−1は、ACSであってもよく、およびxREMクライアント512−1は、CPEであってもよい。SNMPが使用されてxREMを実装する場合、xREMサーバ502−1は、SNMPマネージャであってもよく、xREMクライアント512−1は、SNMPエージェントであってもよい。xREMプロキシ510−1は、SNMPプロキシであってもよい。
複数の管理プロトコルのサポート
一実施形態に従って、システム10などの統合されたM2Mシステムは、複数の垂直(vertical)M2Mアプリケーションを含んでもよく、異なる管理プロトコルが配置されてもよい。例えば、xREmクライアントとしてDMクライアントをサポートするM2Mデバイスは、BBF TR−069のみをサポートするM2M GW、またはBBF TR−069デバイスのみを管理してきたM2Mサーバに移動してもよく、および接続してもよい。代替的な形態では、他の適切なOMA DMデバイスおよびBBF TR−069デバイスが、本発明の実施形態に従った統合されたM2Mシステムにおいて管理されてもよい。
図6は、複数の異なる管理プロトコルを使用するxREMをサポートする、トンネルベースの手法を説明するブロック図である。NREM602および/またはGREM604は、異なるM2M GWおよびデバイスとの管理対話に対して、異なる管理プロトコルを使用してもよい。トンネルモジュールが以下を実行することができる。トンネルモジュールは、D/GREMとNREMとの間、および/またはGREMとDREMとの間のネゴシエーションを実行して、使用する管理プロトコルを判定する。トンネルモジュールはまた、その判定に従ってxREMソフトウェアの更新を実行してもよい。
トンネルモジュールは、データモデル変換を実行して、xREMデータモデルとOMA DMmgmtオブジェクト、BBF TR−069管理パラメータ、および/またはSNMP MIBとの間で変換してもよい。トンネルモジュールはまた、OMA DMコマンドまたはBBF TR069コマンドとxREM RESTfulメソッドとの間の管理コマンドの変換および/またはマッピングを実行してもよい。トンネルモジュールはまた、OMA DM、BBF TR−069またはSNMPプロトコルが、mId基準点上でRESTfulメソッドを使用できるように適合するプロトコル適合を実行してもよい。
管理プロトコルをネゴシエーションまたは指示する方式
例えばmgmtProtocolTypeと称するパラメータが使用されて、管理プロトコルのタイプを表してもよい。mgmtProtocolTypeは、M2Mデバイス、M2Mゲートウェイ、またはM2MサーバのSCLであるリソース<scl>の属性(または下位リソース)であってもよい。加えて、mgmtProtocolTypeは、構成パラメータとしてM2M SCL管理オブジェクト(「SCLMO」と称される)に含まれてもよい。一実施形態では、M2Mデバイスは「mgmtProtocolType」を使用して、M2MデバイスとM2Mサーバとの間、またはM2MデバイスとM2Mゲートウェイとの間で使用する管理プロトコルのタイプを指示してもよい。一実施形態では、M2Mゲートウェイは「mgmtProtocolType」を使用して、M2MゲートウェイとM2Mサーバとの間で使用される管理プロトコルのタイプを表してもよい。このことを容易にするために、M2Mゲートウェイの<scl>は、属性(または下位リソース)「mgmtProtocolType」を含んでもよく、およびM2MゲートウェイのSCLMOは、パラメータ「mgmtProtocolType」を含んでもよい。M2MデバイスがM2Mゲートウェイの後ろに存在する場合は、第2の属性(または下位リソース)「mgmtProtocolTypeExt」が使用されて、M2Mゲートウェイの後ろにあるM2MデバイスとM2Mゲートウェイとの間の管理プロトコルのタイプを表してもよい。
一実施形態では、M2Mサーバは、「mgmtProtocolType」を使用して、M2Mデバイスおよび/またはM2Mゲートウェイを管理するために自身がサポートする管理プロトコルのタイプを表してもよい。このことを容易にするために、M2Mサーバの<scl>は、属性(または下位リソース)「mgmtProtocolType」を含んでもよい。
一実施形態では、N−SCL(および/またはG−SCL)は、対応するNREMおよび/またはGREMがサポートする複数の管理プロトコルのリストを表す属性(または下位リソース)mgmtProtocolTypeを含んでもよい。
代替として、mgmtProtocolTypeを、mgmtObjsリソースの属性および/または各<mgmtObj>インスタンスの属性として追加することができる。以下の方式は、mgmtProtocolTypeを、<scl>の属性、mgmtObjsリソースの属性、または<mgmtObj>リソースの属性として使用して、DREMおよび/またはGREM(「D/GREM」)とNREMとの間、および/またはDREMとGREMとの間の管理プロトコルをネゴシエーションまたは指示するために適用されてもよい。
図7A乃至7Cはそれぞれ、REMに使用する管理プロトコルのタイプを判定するための例示的なフロー700、730、および760を説明するフローチャートである。各フロー700、730、および760は、便宜上図1A乃至1Cのシステム10を参照して説明する。フロー700、730、および760は、他のアーキテクチャを使用して実行されてもよい。
D/GREMとNREMのと間
方式1−mgmtProtocolTypeを「SCL Registration」(SCL登録)および/または「Update SCL Registration」にピギーバック(Piggyback)する
まず図7Aのフロー700を参照すると、D/GREMがSCL Registration処理を開始してもよく(702)、その間にD/GREMは、1つまたは複数の要求(「SCL REGISTRATION REQUEST」(SCL登録要求))メッセージをM2Mサーバ(NREM)に送信してもよい。SCL登録処理開始(702)の一部として、その前、かつ/またはその後に、D/GREMは、D/G−SCLの「mgmtProtocolType」属性/下位リソースから、D/GREMがサポートする管理プロトコルのタイプを示す値(「mgmtProtocolType(値)」)を読み出してもよい。
M2Mデバイス/ゲートウェイ(D/GREM)は次いで、SCL REGISTRATION REQUESTメッセージの1つまたは複数を選択してもよく、および当該メッセージを、パラメータとしてのmgmtProtocolType(値)で埋めてもよく(populate)、ならびにそのSCL REGISTRATION REQUEST[mgmtProtocolType(値)]メッセージを、M2Mサーバ(NREM)に送信してもよい(704)。SCL REGISTRATION REQUEST[mgmtProtocolType(値)]メッセージに応答して、M2Mサーバ(NREM)は、1つまたは複数の応答(「SCL REGISTRATION RESPONSE」(SCL登録応答))メッセージを選択してもよく、および当該メッセージを、パラメータとしてのその受信したmgmtProtocolType(値)で埋めてもよい(populate)。その後、M2Mサーバ(NREM)は、そのSCL REGISTRATION RESPONSE[mgmtProtocolType(値)]メッセージを、M2Mデバイス/ゲートウェイ(D/GREM)に送信して、mgmtProtocolType(値)の受信、および/または受信したmgmtProtocolTypeにより示される管理プロトコルのタイプの受付を確認応答してもよい(706)。SCL REGISTRATION RESPONSE[mgmtProtocolType(値)]メッセージの受信、およびもし存在すれば、SCL登録処理を完了するための他のメッセージ(ある場合)の受信後、D/GREMはSCL登録処理を終了してもよい(708)。フロー700を実行することにより、D/GREMは、mgmtProtocolType属性/下位リソースをSCL登録処理上にピギーバックして、REMを実行する際にM2Mサーバ(NREM)およびM2Mデバイス/ゲートウェイ(D/GREM)が使用することができる管理プロトコルのタイプの通知および/または受付けを容易にしてもよい。
図には示さないが、M2Mサーバ(NREM)は、要求されないで、mgmtProtocolType属性/下位リソースをSCL登録処理上にピギーバックして、N−SCLのmgmtProtocolType属性/下位リソースにより指定され、あるいは指示された管理プロトコルのタイプを使用するようにM2Mデバイス/ゲートウェイ(D/GREM)に指示してもよい。M2Mサーバ(NREM)は、例えば、N−SCLのmgmtProtocolType属性/下位リソースからmgmtProtocolType(値)を読み出し、1つまたは複数のSCL REGISTRATION RESPONSEメッセージを、パラメータとしてのmgmtProtocolType(値)で埋め、および埋められたSCL REGISTRATION RESPONSE[mgmtProtocolType(値)]メッセージをM2Mデバイス/ゲートウェイ(D/GREM)に送信してもよい。
代替として、M2Mサーバ(NREM)およびM2Mデバイス/ゲートウェイ(D/GREM)は、M2Mサーバ(NREM)またはM2Mデバイス/ゲートウェイ(D/GREM)のいずれかが、受信したmgmtProtocolType(値)を他方に送信するまで、それぞれのmgmtProtocolType(値)で埋められたSCL REGISTRATION REQUESTメッセージおよびSCL REGISTRATION RESPONSEメッセージを交換することにより、使用する管理プロトコルのタイプをネゴシエーションしてもよい。
図7B乃至7Cを参照すると、mgmtProtocolTypeをUpdate SCL Registration(SCL登録更新)にピギーバックする処理は以下の通りである。
Update SCL Registrationの処理中に、M2Mサーバ(NREM)は、M2Mデバイス/ゲートウェイ(D/GREM)に送信されるメッセージにそれをピギーバックすることにより、M2Mデバイス/ゲートウェイ(D/GREM)により使用されることになる「mgmtProtocolType」を指定することができる。
あるいは、「Update SCL Registration」の処理中に、M2Mデバイス/ゲートウェイ(D/GREM)は、M2Mサーバ(NREM)に送信されるメッセージに「mgmtProtocolType」をピギーバックすることにより、M2Mサーバ(NREM)に自身の「mgmtProtocolType」をレポートすることができる。
方式2−mgmtProtocolTypeを「mgmtObjリソースの作成」にピギーバックする
ETSI M2M機能アーキテクチャは、管理オブジェクトリソースを作成するための以下のプロシージャを定義している。その結果、mgmtProtocolTypeをそれらのプロシージャに埋め込むことができ、それによりM2Mデバイス/ゲートウェイ(D/GREM)が自身のmgmtProtocolTypeをM2Mサーバ(NREM)に通知することができるようにする。
図8に示すように、mgmtProtocolTypeをmgmtObjリソースの作成にピギーバックする処理は以下の通りである。
この処理がM2Mデバイス/ゲートウェイ(D/GREM)によって開始される場合は、M2Mデバイス/ゲートウェイ(D/GREM)はこの処理中に要求メッセージをM2Mサーバ(NREM)に送信する。M2Mデバイス/ゲートウェイ(D/GREM)は、「mgmtProtocolType」をパラメータとしてその要求メッセージにピギーバックすることができる。
方式3−「mgmtProtocolType」を送信するための新たなプロシージャを作成する
方式2および方式3で説明したように「mgmtProtocolType」を既存のM2Mプロシージャにピギーバック代わりに、以下のプロシージャは、M2Mサーバ(NREM)とM2Mデバイス/ゲートウェイ(D/GREM)との間で「mgmtProtocolType」を送信するための処理を定義する。図9に示すように、本処理は以下の通りである。
「mgmtProtocolType」の更新
M2Mデバイス/ゲートウェイ(D/GREM)は、<scl−of−server>/scls/<scl−dg>/mgmtProtocolTypeにアドレス指定する更新メッセージを送信して、「mgmtProtocolType」を更新する。
<scl−of−server>はM2Mサーバを表す。<scl−dg>は、自身のmgmtProtocolTypeのM2Mサーバを更新するためのM2Mデバイス/ゲートウェイ(D/GREM)を表す。「mgmtProtocolType」は、<scl−dg>の新たな属性であってもよい。その結果、M2Mサーバ(NREM)は、M2Mサーバに登録するM2Mデバイス/ゲートウェイ(D/GREM)の「mgmtProtocolType」を認識する。
NREMはまた、図10に示すように、<scl−dg>/mgmtProtocolTypeにアドレス指定する更新メッセージを能動的に送信して、M2Mデバイス/ゲートウェイの「mgmtProtocolType」を変更してもよい。
代替として、NREMはまた、<scl−dg>/mgmtProtocolTypeにアドレス指定する読出メッセージを送信して、M2Mデバイス/ゲートウェイにおいて使用される現在の管理プロトコルを読み出してもよい。
方式4−mgmtProtocolTypeをSCL検出にピギーバックする
mgmtProtocolTypeを、以下の方式を使用してSCL検出のためのメッセージにピギーバックすることもできる。図11に示すように、M2Mデバイス/ゲートウェイ(D/GREM)がM2Mサーバ(NSCL)を検出する要求メッセージを発行するときに、M2Mデバイス/ゲートウェイは自身のmgmtProtocolTypeをその要求メッセージに含める。ピギーバックされたmgmtProtocolType情報は、mgmtProtocolTypeにより示される管理プロトコルをサポートしないM2Mサーバをフィルタリングすることを支援す ることができる。
M2MサーバのmgmtProtocolTypeは、M2Mデバイス/ゲートウェイへのSCL DISCOVERY RESPONSEメッセージにピギーバックされてもよい。ピギーバックされたmgmtProtocolTypeは、M2Mデバイス/ゲートウェイが適切なM2Mサーバを選択することを支援することができる。M2Mデバイス/ゲートウェイはまた、ピギーバックされたmgmtProtocolTypeにより示される管理プロトコルを使用するように変更することができる。
DREMとGREMとの間
この場合、M2Mデバイスは、プロキシとしてのM2Mゲートウェイの後ろにある。その結果、M2Mデバイスは、各自のmgmtProtocolTypeをM2Mゲートウェイに指示する必要があり、またはM2Mゲートウェイが能動的にM2MデバイスのmgmtProtocolTypeを読み出すことができる。上記の事例1と同様の方式を利用することができる。
方式1−mgmtProtocolTypeを「SCL Registration」および「Update SCL Registration」にピギーバックする
ETSI M2M機能アーキテクチャは、SCL管理のために以下のプロシージャを定義しており、その結果、mgmtProtocolTypeをそれらのプロシージャに埋め込むことができ、それによりDREMが自身のmgmtProtocolTypeをGREMに通知することができる。
SCL Registration
この処理中に、DSCLはNSCLに複数の要求メッセージを送信する。DREMは、それらの要求メッセージのいずれか1つにパラメータとして「mgmtProtocolType」をピギーバックすることができる。加えて、GREMは、DREMへの応答メッセージに「mgmtProtocolType」をピギーバックして、「mgmtProtocolType」により指定される管理プロトコルを使用するようにDREMに指示することができる。
Update SCL Registration
「Update SCL Registration」の処理中に、GREMは、DREMに送信されるメッセージにmgmtProtocolTypeをピギーバックすることにより、DREMにより使用されることになる「mgmtProtocolType」を指定することができる。「Update SCL Registration」の処理中に、DREMは、GREMに送信されるメッセージに「mgmtProtocolType」をピギーバックすることにより、自身の「mgmtProtocolType」をGREMにレポートすることができる。
方式2−mgmtProtocolTypeを「mgmtObjリソースの作成」にピギーバックする
ETSI M2M機能アーキテクチャは、管理オブジェクトリソースを作成するために以下のプロシージャを定義している。その結果、mgmtProtocolTypeをそれらのプロシージャに埋め込むことができ、それによりDREMが自身のmgmtProtocolTypeをGREMに通知することができる。
mgmtObjリソースを作成する
この処理がDSCL(DREM)によって開始される場合、DSCLは、要求メッセージをNGSCLに送信する。この処理中に、DREMは、「mgmtProtocolType」をパラメータとしてその要求メッセージにピギーバックすることができる。
方式3−「mgmtProtocolType」を送信するための新たなプロシージャを作成する
方式2および方式3で説明したように「mgmtProtocolType」を既存のM2Mプロシージャにピギーバックする代わりに、以下のプロシージャを利用してGREMとDREMと間で「mgmtProtocolType」を送信することもできる。
「mgmtProtocolType」を更新する
M2Mデバイス(DREM)は、<scl−of− gw>/scls/<scl−d>/mgmtProtocolTypeにアドレス指定する更新メッセージを送信して「mgmtProtocolType」を更新する。<scl−of−gw>はM2Mゲートウェイを表す。<scl−d>は、M2Mゲートウェイに登録し、そのmgmtProtocolTypeのM2Mゲートウェイを更新しているM2Mデバイスを表す。「mgmtProtocolType」は<scl−d>の属性である。その結果、M2Mゲートウェイ(GREM)は、M2Mゲートウェイに登録するM2Mデバイス(DREM)の「mgmtProtocolType」を認識する。
M2Mゲートウェイ(GREM)はまた、<scl−d>/mgmtProtocolTypeにアドレス指定する更新メッセージを能動的に送信して、M2Mデバイスの「mgmtProtocolType」を変更することができる。
「mgmtProtocolType」を読み出す
M2Mゲートウェイ(GREM)は、<scl−d>/mgmtProtocolTypeにアドレス指定する読出メッセージを送信して、M2Mデバイスで使用されている現在の管理プロトコルを読み出す。
方式4−mgmtProtocolTypeをSCL検出にピギーバックする
mgmtProtocolTypeはまた、以下の手法を使用して、SCL検出のためのメッセージにピギーバックされてもよい。
M2Mデバイス(DREM)が、M2Mゲートウェイ(GSCL)を検出するための要求メッセージを発行するときに、M2Mデバイスは自身のmgmtProtocolTypeを要求メッセージに含める。ピギーバックされたmgmtProtocolType情報は、mgmtProtocolTypeにより示される管理プロトコルをサポートしないM2Mゲートウェイをフィルタリングすることを支援することができる。
M2MゲートウェイのmgmtProtocolTypeを、M2MデバイスへのSCL Discovery Responseメッセージにピギーバックすることができる。ピギーバックされたmgmtProtocolTypeは、M2Mデバイスが適切なM2Mゲートウェイを選択することを支援することができる。M2Mデバイスはまた、ピギーバックされたmgmtProtocolTypeにより示される管理プロトコルを使用するように変更することができる。
すべてのアクセス履歴に対する例示的なリソース定義
リモートエンティティ管理を目的に、要求元/発行元SCLが受信側−SCLのローカルリソース毎に有していたすべてのアクセス履歴を、受信側−SCLが記録(log)しておくことが重要である場合がある。現在のETSI M2M機能アーキテクチャは、リソースaccessStatusを定義しているが、これは、過去におけるリソースに対するすべてのオペレーションではなく、最後のアクセス(読出/更新/サブスクライブ)のみを記録するものである。すべてのアクセス履歴の格納を容易にするために、accessHistoriesと称する新たなリソースが本開示において定義される。accessHistoriesに対する関連するオペレーションも定義される。
リソースaccessHistories
accessStatusに基づいて、図12の例に示すようにaccessHistoriesが定義されてもよい。図12は、リソースaccessHistoriesの例示的な構造を示す。図12を参照すると、accessHistoriesは以下の構成要素を含んでもよい。
・「attribute」はaccessRightIDを有してもよい。
・status:アクセス履歴の記録を開始または停止するかどうかを表すために使用される。
・<accesslnstance>:アクセスインスタンスの数。
各<accesslnstance>は、それについてのアクセスの詳細を記録する以下の下位リソースを有してもよい。
・method:そのアクセスに関連するメソッド、Create、Retrieve、Update、Delete、Subscription、またはAnnounceであってもよい。
・requestorID:そのアクセスを要求しているエンティティのID。
・resourceURI:そのアクセスが動作すべきリソースのURI。
・timeStamp:そのアクセスが発生した時刻。
・sequenceNumber:アクセスの順序を表す、自動的に増分する整数。
・result:その動作の結果。
−メソッドが更新の場合は、resourceURIの新たな値を表す。
−他のメソッドに対するSuccessまたはFailureとすることもできる。障害管理のためにここで種々のタイプのFailureを定義することが可能である。
リソースaccessHistoriesは、M2MデバイスおよびGWに格納されてもよい。デバイス/GWにおいてローカルリソースに対するオペレーションが存在するといつでも、accessInstanceが自動的に作成され、accessHistoriesに追加される。リソースとして、accessHistoriesは多くの場合、管理の目的でNREMによりアクセスされてもよい。言い換えると、NREMはD/GREMに関するaccessHistoriesを作成/読出/更新/削除することができる。以下の機能が実装されてもよい。
・Create:NREMが、特定の時間間隔もしくは恒久的に特定の「method」および/または「resourceURI」についてのaccessHistoriesを作成するようにD/GREMに要求する。
・Retrieve:NREMがD/GREMからすべてのまたは一部の<accessInstance>を読み出す。
・Update:NREMが、「status」の値を変更することによりアクセス履歴機能を無効または再開するようにD/GREMに要求する。
・Delete:NREMがすべてのまたは一部の<accessInstance>を削除するようにG/GREMに要求する。
図12に示す<accessInstance>はフラット構造であり、これを図13に示すように「method」および/または図14に示すよう「requestorID」に基づいて再構成して、それぞれ2レベルおよび3レベルの階層構造を形成することができる。図13は、「メソッド」に基づいて構造化されたリソースaccessHistoriesについての例示的構造を示す。図14は、「method」および「requestorID」に基づいて構造化されたリソースaccessHistoriesについての例示的構造を示す。このような階層構造は、特にリソースに制約があるM2MデバイスにおいてリソースaccessHistoriesへのクエリ/読出オペレーションを迅速化するのに有用である場合がある。
xREMについての管理権限委譲に対する例示的なコールフロー
M2Mデバイスおよび/またはGWの管理権限は、別のM2Mサーバに委譲されてもよい。M2Mデバイスの管理権限を、別のM2M GWに委譲することもできる。本開示の実施形態に従って、M2MデバイスおよびGWについての管理権限の委譲プロシージャが本明細書に記載される。
管理権限委譲
委譲元により開始される委譲
図15は、管理権限委譲(委譲元により開始される)についてのプロシージャのメッセージフローチャートを示す。図15を参照すると、N−SCL−1がD/G−SCLを他のN−SCLに委譲する。N−SCL1は、D/G−SCLがオンラインになった後に「DELEGATION PREPARATION」(委譲の準備)をD/G−SCLに発行する。「DELEGATION PREPARATION」が使用されて、進行中の委譲動作を行える状態になるようにD/G−SCLに指示することができる。D/G−SCLは「DELEGATION RESPONSE」(委譲応答)をN−SCL1に送り返すことができる。D/Gはその後オンライン状態のままでいてもよい。N−SCL1は、D/G SCLに対する新たな管理権限として選択されたN−SCL X に「DELEGATION REQUEST」(委譲要求)を発行してもよい。「DELEGATION REQUEST」は以下の情報を含んでもよい。
・委譲されることになるのD/G−SCLのURIおよび/または認証に関連する情報
・管理委譲を要求する理由
N−SCL Xは、「DELEGATION REQUEST」にYESまたはNOを回答することにより、N−SCL1に「DELEGATION RESPONSE」を送り返してもよい。N−SCL1は、委譲を受け入れることに同意するN−SCLを発見し、または最大回数を試行するまで、他のN−SCLに「DELEGATION REQUEST」を繰り返し送信してもよい。
N−SCL 1は「DELEGATION INFORM」(委譲通知)をD/G−SCLに発行してもよい。同意するN−SCL Xがない場合、N−SCL 1はこのメッセージを使用して、進行中の委譲を取り消すことをD/G−SCLに通知してもよい。そしてD/Gは通常通りに動作することができる。その後スリープ状態に移ることができる。そして、委譲処理全体が停止してもよい。そうでない場合は、「DELEGATION INFORM」は、委譲を受け入れることに同意するN−SCL Xについての情報を含む。D/G−SCLは「DELEGATION RESPONSE」を送り返してもよい。
N−SCL 1は「DELEGATION START」(委譲開始)をN−SCL Xに発行して、委譲動作を実行するようにそれをトリガしてもよい。
N−SCL Xは、D/G−SCL に「DELEGATION EXECUTION」(委譲実行)を発行してもよい。D/G−SCLはN−SCL Xに対する認証を実行してもよい。
D/G−SCLはN−SCL Xに「DELEGATION RESPONSE」を送り返してもよい。D/G SCLは、N−SCL Xをその新たな管理権限に設定することにより、自身の管理オブジェクトを更新してもよい。N−SCL Xは、D/G−SCLを自身の権限下にある管理されるエンティティとして含めることにより、自身の管理オブジェクトを更新してもよい。
N−SCL Xは、N−SCL 1に「DELEGATION FINISH」(委譲終了)を発行してもよい。
N−SCL 1は、N−SCL Xに「DELEGATION ACK」(委譲確認応答)を送り返してもよい。
N−SCL 1は、自身の管理権限からD/G−SCLを除くことにより、自身の管理オブジェクトを更新してもよい。
N−SCL 1は、管理権限を委譲する先のエンティティとしてN−SCL Xを追加することにより、自身の管理オブジェクトを更新してもよい。
N−SCL Xは、管理権限を委譲する元のエンティティとしてN−SCL 1を追加することにより、自身の管理オブジェクトを更新してもよい。
デバイスにより開始される委譲
図16は、管理権限委譲(デバイスにより開始される)の例示的なメッセージフローチャートを示す。このことは、D/Gが能動的に管理権限の委譲を要求するシナリオで適用されてもよい。委譲元により開始される委譲との唯一の相違は、最初の2つのステップである。図16を参照すると、D/G−SCLは「DELEGATION REQUEST」をN−SCL 1に発行する。D/G−SCLは、このメッセージで委譲を要求する理由を指示することができる。N−SCL 1は、委譲を実行する自身の意思をD/G−SCLに通知することにより、「DELEGATION RESPONSE」をD/G−SCLに送り返してもよい。N−SCL 1は委譲を実行することを拒否してもよい。そして、委譲処理全体が停止してよい。
図16と異なり、代替として、D/Gは、委譲先(新たな管理権限)に直接「DELEGATION REQUEST」を送信してもよい。そして、委譲先が委譲元に承認を求める要求をすることができる。例示的な詳細なプロシージャが図17において示され、図17は、管理権限委譲(デバイスにより委譲先に直接開始される)の例示的なメッセージフローチャートを説明する。このシナリオは、委譲元が事前にデバイスへのいくつかの考えられる委譲先を構成する必要があり、およびデバイスと委譲元との間の通信に問題が生じたときに発生する場合がある。
委譲先により開始される委譲
委譲元により開始される委譲およびデバイスにより開始される委譲に加えて、管理権限の委譲を場合によっては委譲先により開始することもできる。例えば、図18は、管理権限の委譲(委譲先により開始される)についての例示的なメッセージフローチャートを示す。図18を参照すると、N−SCL XがN−SCL 1に委譲を要求してもよい。N−SCL 1は、D/G−SCLの管理権限をN−SCL Xに委譲することを承認してもよい。各ステップの意義は図16に関連して説明したステップと同様である。
プロキシとしてのゲートウェイの下での委譲
一部のデバイスがゲートウェイの後ろにあるシナリオでは、管理権限の委譲はプロキシとしてのゲートウェイを介して実行されてもよい。例えば、図19は、管理権限の委譲(プロキシとしてのゲートウェイ)についての例示的なメッセージフローチャートを示す。図19を参照すると、N−SCL−1は、プロキシとしてのG−SCLを介して、D−SCLをN−SCL Xに委譲してもよい。G−SCLが実際には、委譲の集約を実行する。基本的に、G−SCLが、その後ろにあるDまたはD’の代わりに、図16と同様のプロシージャを使用して、N−SCL 1およびN−SCL Xによる管理権限の委譲を実行してもよい。DまたはD’がオンラインになるときに、G−SCLは、委譲の結果、すなわち新たな管理権限N−SCL Xをそれらに通知する。
デバイスツーゲートウェイ委譲
一実施形態では、D−SCLの管理権限はG−SCL 1から別のG−SCL Xに委譲される。例えば、図20は、管理権限委譲(デバイスツーゲートウェイ委譲)についての例示的なメッセージフローチャートを示す。図20を参照すると、D−SCL、G−SCL 1、およびG−SCL X間の委譲処理の後、G−SCL 1は、委譲の結果をN−SCL 1に通知してもよい。
階層的SCL構造
図21は一般的なシナリオの図を示し、このシナリオでは、1)すべてのSCLの管理権限関係が階層構造を形成し、2)SCL4が自身のSCL9に対する管理権限をSCL3に委譲することを要求する。基本的には次の3つのステップに従う。
・ステップ1:SCL4は、SCL2およびSCL1を介して、ホップバイホップ(hop-by-hop)で最終的にSCL3に「DELEGATION REQUEST」を発行する。
・ステップ2:SCL3は、「DELEGATION RESPONSE」をSCL4に送り返す。
・ステップ3:SCL4は、「DELEGATION INFORM」をSCL9に発行する。
・ステップ4:SCL3およびSCL9は、「DELEGATION EXECUTION」に関連する対話を実行する。
・ステップ5:SCL3は、SCL1およびSCL2を介して、ホップバイホップで最終的にSCL4に「DELEGATION INFORM」を送信する。
SCL1、SCL2、およびSCL4は、それらの管理オブジェクトを更新し、それに応じてこの管理権限の変更を反映させてもよい。
例示的なxREM権限委譲
NREMは、DREMおよびGREMを管理する役割を担う。しかし、ETSI xREMは、リモートエンティティ管理(xREM)権限の概念も、xREMの権限委譲の概念も記載していない。M2MデバイスまたはGWのxREM権限は、M2Mサーバの交換、ロードバランス、および移動性等の理由で、M2Mサーバから別のM2Mサーバに委譲される必要がある。M2MデバイスがM2M GWの後ろにある状態になった場合、またはその逆の場合には、M2MデバイスのxREM権限さえもM2MサーバからM2M GWに委譲することができる。
OMA−DMは、クライアントの権限委譲についての高レベルのプロシージャを定義しているが、スリープ状態のデバイスや中間にあるM2M GWについては考慮しない。その結果、ETSI M2M xREMに直接適用することができない。ETSI M2M xREMは、自身のxREM権限委譲を有する必要がある。
M2MデバイスまたはGWがM2Mサーバへの登録に成功すると、M2Mサーバは基本的にM2Mデバイス/GWについてのxREM権限を所有する。M2MデバイスがM2M GWの後ろにあるときに、GWがそれらのM2Mデバイス上のxREM権限を有する。したがって、xREm権限の委譲は以下のようにいくつかの異なるシナリオを意味する場合がある。
ケース1:M2Mサーバが自身のxREM権限を別のM2Mサーバに委譲する。
ケース2:M2Mサーバが自身のxREM権限をM2M GWに委譲する。
ケース3:M2M GWが自身のxREM権限をM2Mサーバに委譲する。
ケース4:M2M GWが自身のxREM権限を別のM2M GWに委譲する。
xREMについての例示的機能
その結果、ETSI M2M xREMは、xREMの権限委譲をサポートするための新たな機能を有する必要がある。ネットワークリモートエンティティ管理(NREM)は以下の機能、xREM権限委譲を支援する機能、を有する必要がある。NREMはM2MデバイスおよびM2MゲートウェイについてのxREM権限を有する。NREMは、xREMの権限委譲をサポートするために以下の機能、M2MデバイスおよびM2MゲートウェイについてのxREM権限を別のM2Mサーバに委譲する機能、またはM2MデバイスについてのxREM権限をM2Mゲートウェイに委譲する機能、別のM2MサーバまたはM2Mゲートウェイから要求されるxREM権限委譲を処理する機能、を有する必要がある。。管理されるM2MエリアネットワークのM2Mデバイスに対してリモート管理プロキシとして機能するときに、ゲートウェイリモートエンティティ管理(GREM)は以下の機能を有する必要がある。
xREM権限委譲をサポートする機能。M2MデバイスがM2Mゲートウェイの後ろにあるときに、M2Mゲートウェイが、それらのM2MデバイスについてのxREM権限を有する。xREM権限の委譲をサポートするために、M2Mゲートウェイは以下の機能、M2Mデバイスについての自身のxREM権限をM2Mサーバまたは別のM2Mゲートウェイに委譲する機能、別のM2MサーバまたはM2MゲートウェイからのxREM権限の委譲メッセージを処理する機能、xREM権限委譲をサポートする機能、を有する必要がある。M2MサーバはM2MゲートウェイについてのxREM権限を有する。
M2Mゲートウェイは以下の機能、M2MゲートウェイについてのxREM権限を別のM2Mサーバに委譲するようにM2Mサーバに能動的に要求する機能、およびM2MサーバからのxREM権限委譲メッセージを受動的に処理する機能、を有する必要がある。
デバイスリモートエンティティ管理(DREM)は、以下の機能、xREM権限委譲をサポートする機能を有する必要がある。M2Mサーバは、M2MデバイスについてのxREM権限を有する。
M2Mデバイスは以下の機能、M2Mデバイスについての自身のxREM権限を別のM2Mサーバに委譲するように能動的にM2Mサーバに要求する機能、およびM2MサーバからのxREM権限委譲メッセージを受動的に処理する機能、を有する必要がある。
例示的な非RESTful管理コマンドサポート
本発明では、非RESTful管理コマンドがRESTfulな方式で表され、および実現される、M2M xREMについてのシステム、装置、および方法の実施形態が提供される。そのような非RESTful管理コマンドの例は、デバイスをリブートするリブートコマンド、ダウンロードコマンドの受信者にファイルのダウンロードを指示するダウンロードコマンド、特定の処理を実行する実行コマンド、1つの場所から別の場所にリソースを複製および/または移動するコピーコマンド、のうちのいずれかを含んでもよい。リブートコマンドおよびダウンロードコマンドはそれぞれ、例えばBBF−TR069に準じて定義されてもよい。実行コマンドおよびコピーコマンドは、例えばOMA−DMの「Exec」コマンドおよびOMA−DMの「Copy」コマンドであってもよい。非RESTful管理コマンドはまた、例えば制御可能要素を備えるM2Mデバイスの制御可能要素(例えばアクチュエータ)の制御に使用される1つまたは複数のコマンドなどの他のコマンドも含んでもよい。
1つまたは複数の実施形態では、リソースコマンドと呼ばれるリソースが使用されて、非RESTful管理コマンドを表し、およびコマンドの1つまたは複数の発行元により指定される異なる方式での非RESTful管理コマンドの実行(「コマンド実行」)をサポートしてもよい。リソースコマンドが使用されて、任意のRESTfulメソッドを使用するデバイスにおいて、非RESTful管理コマンドの発行およびコマンド実行を容易にしてもよい。
さらに、リソースコマンドが使用されて、任意の非RESTful管理コマンドについて、中間コマンド実行、遅延の後の(例えばランダムな)コマンド実行、1回のコマンド実行(例えばワンタイムコマンド実行)、および/または複数の反復されるコマンド実行を容易にしてもよい。
図22Aは、リソースコマンド(「<commandInstance>」)を表すデータ構造のインスタンスを有する<sclbase>の例示的データ構造を示すブロック図である。<commandInstance>は、図22Aに示すものなどのいくつかのデータ構造要素を含んでもよい。示されるそれらのデータ構造要素の中には、属性を表すデータ構造要素(「attribute」)、下位リソースのexecMode、execParameters、execStartTime、execDuration、execResult、execStatus、requestorID、およびactorIDを表すデータ構造要素がある。「attribute」は、上記説明したaccessRightIDをんでもよい。
execModeは、<commandInstance>の非RESTful管理コマンドのコマンド実行の特定のモードを指定するために使用されてもよい。execModeデータ構造要素は、コマンド実行についてのモード(「コマンド実行モード」)を表す1つまたは複数のエントリを含んでもよい。コマンド実行モードの例は、Immediate Onceモード、Immediate and Repeatedlyモード、Random Onceモード、およびRandom and Repeatedlyモードを含んでもよい。
Immediate Onceモードは、コマンド実行を直ちに、一度のみ行うことを指定する。Immediate and Repeatedlyモードは、コマンド実行を直ちに、かつ繰り返し行うことを指定する。任意の2つのコマンド実行間の時間間隔はexecParameterにおいて指定されてもよい。Random Onceモードは、コマンド実行を(例えばランダムな)遅延の後にかつ一度のみ行うことを指定する。遅延はexecParameterにおいて指定されてもよい。Random and Repeatedlyモードは、コマンド実行を(例えばランダムな)遅延の後に繰り返し行うことを指定する。遅延および2つのコマンド実行間の任意の間隔は、execParameterにおいて指定されてもよい。
execParameterはコンテナであってもよく、およびコマンド実行モードに関連付けられた情報を含んでもよい。既に述べた情報に加えて、当該情報は、(i)Random OnceモードおよびRandom Repeatedlyモードにおいてコマンド実行の前にどのように一定時間バックオフ(backoff)するかを指定する情報、および/または(ii)Immediate and RepeatedlyモードおよびRandom and Repeatedlyモードにおいてコマンド実行を繰り返す頻度を指定する情報を含んでもよい。
execStartTimeは、コマンド実行の実際の最後の時間を指定してもよい。execDurationは、継続されるコマンド実行に対して必要な継続時間を指定してもよい。execResultは、最後のコマンド実行に対して返された値を指定してもよい。execStatusは、コマンド実行の現在のステータスを指定してもよい。このステータスは、例えば、終了(成功または失敗)、保留、動作中等であってもよい。requestorIDは、コマンド実行が呼び出されるのを要求する要求者のID(例えばURI)を指定してもよい。actorIDは、コマンド実行を呼び出す受信者のID(例えばURI)を指定してもよい。
図22Bは、コマンドリソースを表す例示的なデータ構造(「コマンドリソース構造」)を示すブロック図である。コマンドリソース構造は、図22Bに示すものなど、いくつかのデータ構造要素を含んでもよい。そして、このコマンドリソース構造のデータ構造要素の多くは、図22Aのコマンドリソース構造と同様である。示されるこれらのデータ構造要素の中には、属性(「コマンドリソース『attribute』」)を定義するデータ構造要素、およびそれぞれのコマンド(「<command>」)の集合を表すデータ構造要素のセットが含まれる。リソースとしての<command>の各インスタンスは、単一のコマンドを表し、ならびに<command>インスタンスの属性および/または下位リソースを表すデータ構造要素を含む。これらの<command>インスタンスの属性および/または下位リソースは、コマンド実行をどのようにトリガし、および実行するかを指定してもよい。<command>インスタンスの属性および/または下位リソースの中には、execEnable下位リソース(「execEnable」)を表すデータ構造要素がある。execEnableは、「execute」属性とも呼ばれ、コマンド実行の状態における変化を呼び出すことを容易にしてもよい。例えば、execEnableはブール変数であり、ならびにその変数の特定の値はコマンド実行、中断コマンド実行、再開コマンド実行、および/または取消しコマンド実行を呼び出してもよい。そのため、コマンド実行、中断コマンド実行、再開コマンド実行、および取消コマンド実行のいずれかは、execEnableの値を変更することによって呼び出されてもよい。execEnableの値はRESTfulメソッドを使用して変更されてもよい。
例えば、RESTfulメソッドUPDATEが使用されて、<command>インスタンスのコマンド実行を呼び出してもよい(例えばトリガ)。../commands/<command>/execEnableへのRESTfulメソッドUPDATE toにおいて第1の値(例えば「1」)を指定することにより、コマンド実行が呼び出されてもよい。
RESTfulメソッドUPDATEおよびDELETEが使用されて、<command>インスタンスのコマンド実行を取消(停止)してもよい。../commands/<command>/execEnableへのRESTfulメソッドUPDATEにおいて第2の値(例えば「0」)を指定することにより、取消コマンドの実行が呼び出されて<command>インスタンスを停止してもよい。加えて、またはその代わりに、../commands/<command>/にRESTfulメソッドDELETEを発行することにより、取消コマンド実行が呼び出されて、そのような<command>インスタンスがRESTfulメソッドDELETEに従って削除される前に、<command>インスタンスのコマンド実行を停止してもよい。
execEnableに加えて、<command>インスタンスの下位リソースは、execBaseDelay、exceAdditionalDelay、execFrequency、execNumber、execResource、execStatus、execResult、execIssuer、およびexecParameterなどの下位リソースを表すデータ構造要素を含んでもよい。
execBaseDelayは、<command>インスタンスのコマンド実行前の最小の遅延を指定してもよい。exceAdditionalDelayは、ランダムな追加的遅延の生成を容易にしてもよい。総遅延は、execBaseDelayとランダムな追加的遅延との和になる。execBaseDelayおよびexecAdditionalDalyは、(i)Random OnceモードおよびRandom Repeatedlyモードにおいてコマンド実行前に一定の時間どのようにバックオフするかを指定する情報、および/または(2)Immediate and RepeatedlyモードおよびRandom and Repeatedlyモードにおいてコマンド実行を繰り返す頻度を指定する情報を含んでもよい。
execFrequencyは、<command>インスタンスの繰り返されるコマンド実行の頻度を指定してもよい。execNumberは、<command>インスタンスのコマンド実行を繰り返すことができる回数を指定してもよい。execResourceは、<command>インスタンスがコマンド実行を受けるリソースURIを指定してもよい。リソースURIは、リソースのグループを含むグループリソースを指す。そのようにして、複数の<command>インスタンスのコマンド実行が、グループリソースを指すリソースURIの機能として呼び出されてもよい。execResourceは任意であってもよい。例えば<command>インスタンスが下位リソースとして<command>インスタンスの下位に置かれる場合は、execResourceは必要でない場合がある。
execStatusは、<command>インスタンスのコマンド実行の現在のステータスを指定してもよい。ステータスは、例えば、保留中、実行中、中断、停止、再開、終了かつ成功、および終了かつ失敗等であってもよい。execResultは、<command>インスタンスのコマンド実行の実行結果を格納してもよい。execResultを、例えばexecResourceがリソースのグループを指す場合に、複数の結果が生成された場合に<command>インスタンスの下位リソースとしてモデル化することができる。
execIssuerは、<command>インスタンスのコマンド実行を呼び出す要求を発行する発行元のIDを指定してもよい。execParameterは、<command>インスタンスに固有のパラメータを格納するコンテナ(例えばプレースホルダ)であってもよい。
ここで図22Cを参照すると、図22Cは、別の例示的なコマンドリソース構造を示すブロック図である。このコマンドリソース構造は、図22Cに示すものなどのいくつかのデータ構造要素を含んでもよい。そしてこのコマンドリソース構造のデータ構造要素の多くは、図22Bのコマンドリソース構造と同様である。図22Cに示すデータ構造要素の中には、いくつかの属性、すなわちcommandID属性、execDisable属性、execPause属性、execResume属性、およびexecResult属性を定義するデータ構造要素が含まれる。
execEnable属性は、「execute」属性とも呼ばれ、<command>インスタンスのコマンド実行の呼び出しを容易にしてもよい。execEnable属性へのRESTfulメソッドUPDATEは、<command>インスタンスのコマンド実行を呼び出してもよい。RESTfulメソッドUPDATEのペイロードは、空であってもよく、または任意の値(例えばexecEnable=1)に設定されてもよい。
execDisable属性は、「cancel」(取消し)属性とも呼ばれ、<command>インスタンスの取消コマンド実行の呼び出しを容易にしてもよい。execDisable属性へのRESTfulメソッドUPDATEは、<command>インスタンスの取消コマンド実行を呼び出してもよい。RESTfulメソッドUPDATEのペイロードは空であってもよく、または任意の値(例えばexecDisable=1)に設定されてもよい。
execPause属性は、<command>インスタンスの取消コマンド実行の呼び出しを容易にしてもよい。execPause属性へのRESTfulメソッドUPDATEは、<command>インスタンスの中断コマンド実行を呼び出してもよい。RESTfulメソッドUPDATEのペイロードは空であってもよく、または任意の値(例えばexecPause=1)に設定されてもよい。
execResume属性は、<command>インスタンスの再開コマンド実行の呼び出しを容易にしてもよい。execResume属性へのRESTfulメソッドUPDATEは、そのような再開コマンド実行を呼び出してもよい。RESTfulメソッドUPDATEのペイロードは空であってもよく、または任意の値(例えばexecResume=1)に設定されてもよい。
上述したことは、図23A、図23Bおよび図23Cのデータ構造が、RESTfulメソッドを使用して非RESTful管理コマンドのコマンド実行を容易にしてもよいことを示す。このことは、BBF−TR069およびOMA−DMの非RESTful管理コマンドのコマンド実行を容易にすることを含む。例えば、BBF−TR069のリブートは、データ構造において.../commands/reboot/として表されてもよい。BBF−TR069のダウンロードは、データ構造において.../commands/download/として表されてもよい。OMA−DMの実行は、データ構造において.../commands/exec/として表されてもよい。OMA−DMの複製は、データ構造において.../commands/copy/として表されてもよい。
<command>インスタンスが使用されて、他の管理用APIまたはリモートプロシージャコール(RPC)をモデル化し、および表してもよい。リソースコマンドは、既存の「リソース」の下に下位リソースの下に配置されてもよく、および既存の「リソース」の下に下位リソースとして配置されてもよく、それにより、各commands/<command>が、トリガされた時に必要であれば、「リソース」上で自動的に実行されるようにされてもよい。加えて、「execResource」を使用して、commands/<command>を実行することができるリソースを指定することができる。この方式では、リソースコマンドを、集中化された点に配置することができ、および「execResource」が参照するリソースの直下にある必要はない。OMA−DM FUMOを例として、以下に2つの方式が説明される。
方式1:「execResource」を使用してFUMOにおける動作を参照する
図23に示すように、OMA FUMOは、ダウンロード、更新、ならびにダウンロード・更新、の3つの動作を有する。OMA−DMでは、その3つの動作はDMサーバによってトリガされて、DMクライアントに非RESTfulのExecコマンドを発行する。それら3つの動作をRESTful方式で呼び出すために、Execは、図23に記載するいくつかの属性を有する<command>execとしてモデル化される。2つの重要な属性はexecEnableとexecResourceである。
ネットワーク領ドメイン(「NA」)のM2Mアプリケーションは、「ダウンロード」の動作を行う必要があるときは、単に.../mgmtObjs/commands/exec/にUPDATEメソッドを発行して
execEnable=1、かつ
execResource=.../mgmtObjs/FUMO/Downloadに設定する。
NAが「更新」動作を行う必要があるときは、単に.../mgmtObjs/commands/exec/にUPDATEメソッドを発行して
execEnable=1、かつ
execResource=.../mgmtObjs/FUMO/Updateに設定する。
NAが「ダウンロード・更新」の動作を行う必要があるときは、単に.../mgmtObjs/commands/exec/にUPDATEメソッドを発行して、
execEnable=1、かつ
execResource=.../mgmtObjs/FUMO/DownloadAndUpdateに設定する。
方式2:コマンドを使用してFUMOにおける動作を再モデル化する
図24A〜24Bに示すように、別の方式は、すべてのFUMO動作を<command>リソースとして直接再モデル化するものである。動作の実行をトリガするには、対応する<command>のexecEnableへの更新のみが必要となる。その結果、追加的なExecコマンドを定義する必要は全くない。この方式では「execResource」は必要でない。
図24Aに示すように、3つのFUMO動作が、それぞれ3つの<command>リソースとして(すなわちダウンロード、更新、ダウンロード・更新)、リソースコマンド下に再モデル化されてもよい。各FUMO動作はいくつかの子/リーフノードを有するので、それらは「execParameter」の下に属性としてモデル化される必要がある。ダウンロード・更新を例として使用すると、「PkgURL」は/commands/downloadAndUpdate/execParametersの属性として追加されてもよい。
NAが「ダウンロード・更新」動作を実行する必要があるときは、単に.../mgmtObjs/FUMO/commands/downloadAndUpdate/にUPDATEメソッドを発行して、
execEnable=1かつ
PkgURL=対応するパッケージのURLに設定する。
旧FUMO動作がそのまま維持される必要がある場合は、図24Bに示すように、再モデル化されたコマンドがノードExtの下に部分ツリーとして配置されてもよい。
1つまたは複数の実施形態では、コマンドリソース構造は、同一の非RESTful管理コマンドの複数回の発行をサポートしてもよい(例えば複数のNAまたは他の発行元が同一の非RESTful管理コマンドのコマンド実行を要求してもよい)。
同一の非RESTfulの管理コマンドの複数回の発行をサポートするコマンドリソース構造の2つの例が図25Aおよび図25Bに示される。図25Aに示すコマンドリソース構造は、図22Aのコマンドリソース構造と同様であり、ならびに<command>を複数のインスタンスの集合、すなわち<commandInstances>として定義することにより、図22Aのコマンドリソース構造を拡張する。上記のプロシージャが使用されて、<command>のコマンド実行を呼び出し、および対応する<commandInstance>を生成してもよい。<commandInstance>は、複数のNAによって発行される対応する<command>インスタンスを維持してもよい。生成された<commandInstance>の各コマンド実行は、上記のようにその属性および/または下位リソースにアクセスすることにより停止または変更されてもよい。例えば、既存の<commandInstance>のコマンド実行は、RESTfulメソッドUPDATEを使用して停止されて、<commandInstance>/execEnableを1から0に変更してもよい。<commandInstance>および/または<commandInstance>のコマンド実行の状態における変化は、他のRESTfulメソッドを使用してアクセス、および操作されてもよい。
図25Bに示すコマンドリソース構造は、図22Bのコマンドリソース構造と同様であり、および<command>/execRequests(<execInstances>とも呼ぶ)を、複数の要求インスタンスの集合、すなわち<requestInstances>(<execInstances>とも呼ぶ)として定義することにより、図22Bのコマンドリソース構造を拡張する。上記のプロシージャが使用されて、コマンド実行、もしくは<command>のコマンド実行の状態の変化を呼び出し、および/または対応する<requestInstance>を生成する。<requestInstance>は、対応する<command>インスタンス(例えばNAによって発行される)を維持してもよい。生成された<requestInstance>の各コマンド実行は、上記のようにその属性にアクセスすることによって停止または変更されてもよい。例えば、既存の<requestInstance>のコマンド実行は、<requestInstance>/execEnableにRESTfulメソッドUPDATEを使用して停止されてもよい。
<requestInstance>および/または<requestInstance>のコマンド実行の状態における変化は、他のRESTfulメソッドを使用してアクセスおよび操作されてもよい。
図26Aはリソースコマンドの例示的構造を示すブロック図である。リソースコマンドは、<command>の下位リソースおよび以下の属性を有してもよい。
accessRightID
creationTime
lastModifiedTime
expirationTime
searchStrings
contentType:FFSフォーマットであってもよい
moID
originalMO、および
description(すなわちコマンドリソースのテキスト形式の詳細)
<command>を属性としてモデル化することもできる。
図26Bは、リソースコマンドの例示的構造を示すブロック図である。リソースコマンドは、以下の属性と共に下位リソースのサブスクリプションおよび<command>の下位リソースを有してもよい。
accessRightID
creationTime
lastModifiedTime
expirationTime
searchStrings
contentType:FFSフォーマットであってもよい
moID
originalMO、および
description(すなわちコマンドリソースのテキスト形式の詳細)
<command>を属性としてモデル化することもできる。
各<command>は、下位リソース(i)subscriptions、および(ii)execRequestsを含んでもよい。execRequestsは、同一の非RESTfulの管理コマンドのコマンド実行を呼び出すための異なる発行元からの要求を格納するプレースホルダであってもよい。1つまたは複数の実施形態では、これらの要求は、<command>インスタンスに対する異なる引数を有してもよい。
各<command>インスタンスは以下の属性を有してもよい。
accessRightID
creationTime
lastModifiedTime
expirationTime
searchStrings
contentType:FFSフォーマットであってもよい
moID
originalMO、および
description(すなわちコマンドリソースのテキスト形式の詳細)
<command>を属性としてモデル化することもできる。
各<command>は例えば図27Aに示すようにいくつかの<commandInstance>を下位リソースとして有する。各<command>は以下の属性を有する。
accessRightID
creationTime
lastModifiedTime
execEnable:コマンドを実行することを呼び出すために使用されるブール変数
execEnableが1から0に変更されると、<commandInstance>は停止されてもよい。execEnableを、中断などのより多くのオプションをサポートするように調整されてもよい。
execMode:どのようにコマンドを実行するかを指定するために使用される。
Immediate Once:受信者はコマンドを直ちに一度のみ実行する。
Immediate and Repeatedly:受信者はコマンドを直ちに、しかし繰り返して実行する。2つの実行間の間隔はコンテナexecParametersによって指定される。
Random Once:受信者はランダムの遅延の後、かつ一度のみコマンドを実行する、ランダムの遅延はexecParametersにおいて指定される
Random and Repeatedly:受信者はランダムの遅延の後、かつ繰り返しコマンドを実行する。ランダムの遅延および2つの実行間の間隔はコンテナexecParametersにより指定される。
execBaseDelay:<commandInstance>を実行することができる前の最小の遅延を指定する。
exceAdditionalDelay:ランダムの追加的な遅延を生成するために使用される。総遅延は、execBaseDelayとランダムの追加的遅延との和であってもよい。
execFrequency:<commandInstance>を繰り返し実行できる頻度を指定する。
execNumber:<commandInstance>を繰り返し実行できる回数を指定する。
execResource:<commandInstance>を実行することができるリソースURIを表してもよい。リソースURIは、リソースのグループを含むグループリソースを指すことができ、そしてコマンドはそれらの各リソース上で実行されてもよい。execResourceは任意であってもよい。<commandInstance>が、その<commandInstance>を実行することができるリソースの下に下位リソースとして配置される場合は、execResourceは必要でない場合がある。
execStatus:<commandInstance>の現在のステータスを表してもよい。ステータスは、保留中、実行中、および終了(成功または失敗)のいずれかであってもよい。
execIssuer:<command>を発行する発行元を表してもよい。
execParameter:各々単一のコマンドに固有のパラメータを格納するプレースホルダである。
execBaseDelayおよびexecAdditionalDelayは、「Random Once」モードおよび「Random Repeatedly」モードにおいて、<commandInstance>を実行する前にどのように一定時間バックオフするかを指定するために使用される。execFrequencyおよびexecNumberは、「Immediate and Repeatedly」および「Random and Repeatedly」下で同一の<commandInstance>を実行する頻度を指定するために使用される。
「exec」で始まる上記の属性を下位リソースとしてモデル化することもできる。「exec」で始まる上記の属性を、通常のRESTful CRUD動作(すなわちCreate、Retrieve、Delete、Update)に適用して、リソースを操作することにさらなる柔軟性を付与することができる。
各<commandInstance>は図27Bに示すように以下の属性を有してもよい。
accessRightID
creationTime
lastModifiedTime
execEnable:コマンドの実行をトリガするために使用されるブール変数。execEnableが1から0に変更されると、<commandInstance>は停止されてもよい。execEnableは、中断などのより多くのオプションをサポートするように適合されてもよい。
execMode:コマンドをどのように実行できるかを指定するために使用される。
Immediate Once:受信者はコマンドを直ちに、かつ一度のみ実行する。
Immediate and Repeatedly:受信者はコマンドを直ちに、しかし繰り返して実行する。2つの実行間の間隔はコンテナexecParametersにより指定される。
Random Once:受信者はランダムの遅延の後に一度のみコマンドを実行する。ランダムの遅延はexecParametersで指定することができる。
Random and Repeatedly:受信者はランダムの遅延の後に、かつ繰り返しコマンドを実行する。ランダムの遅延および2つの実行間の間隔はコンテナexecParametersにより指定されてもよい。
execBaseDelay:<commandInstance>を実行できる前の最小の遅延を指定するために使用される。
exceAdditionalDelay:ランダムな追加的遅延を生成するために使用される。総遅延は、execBaseDelayとランダムな追加的遅延との和であってもよい。
execFrequency:<commandInstance>を繰り返し実行できる頻度を指定するために使用される。
execNumber:<commandInstance>を繰り返し実行できる回数を指定するために使用される。
execResource:<commandInstance>を実行することができるリソースURIを表してもよい。リソースURIは、リソースのグループを含むグループリソースを指してもよく、そしてコマンドはそれらの各リソース上で実行されてもよい。execResourceは任意であってもよい。<commandInstance>が、その<commandInstance>を実行することができるリソースの下に下位リソースとして配置される場合は、execResourceは必要でない場合もある。
execStatus:<commandInstance>の現在のステータスを表してもよい。このステータスは、保留中、実行中、および終了(成功または失敗)のいずれかであってもよい。
execIssuer:<command>を発行する発行元を表してもよい。
execParameters:各々単一のコマンドに固有のパラメータを格納するプレースホルダである。
「exec」で始まる上記の属性を下位リソースとしてモデル化することもできる。
ここで図28Aを参照すると、図28Aは、別の例示的なコマンドリソース構造を示すブロック図である。このコマンドリソース構造は、いくつかのデータ構造要素を含んでもよい。そして、このコマンドリソース構造のデータ構造要素の多くは、図22Cのコマンドリソース構造と同様である。上記述べたように、コマンドリソース構造は、同一の非RESTful管理コマンド(例えば属性commandIDによって識別される)のコマンド実行に対する複数の発行元(例えば、複数のNA)の要求をサポートする。そのようなサポートを容易にするために、一実施形態では、異なる<command>が各要求に対して作成されてもよい。各<command>は異なる名前を有してもよいが、その属性commandIDは互いに同一であってもよい。属性commandID(コマンドのタイプにより分類されてもよい)は、コマンドの状態における変更を呼び出すコマンドを指定する。<command>の下位リソースexecRequestsは使用されなくてもよい。さらに、各発行元はリソースコマンドの下に特定の<command>を作成してもよい。RESTfulメソッドUPDATEが使用されて、作成された<command>のコマンド実行を呼び出してもよい(例えばRESTfulメソッドUPDATEをリソース<command>のexecEnable属性上で使用する)。
あるいは、下位リソースexecRequestsが使用されて、同一の<command>のコマンド実行に対する複数の要求を格納してもよい。発行元は、RESTfulメソッドUPDATEを<command>のexecEnable属性上で使用して、<command>のコマンド実行を呼び出してもよい。したがって、受信者は、その発行元について、.../commands/<command>/execRequests/の下に<requestInstance>を作成してもよい。発行元は、RESTfulメソッドUPDATEを<requestInstance>の属性であるexecDisable、execPause、およびexecResume上でそれぞれ使用して、この生成された<requestInstance>を取り消し、中断し、および再開してもよい。
加えて、発行元は、RESTfulメソッドDELETE動作をコマンドリソース.../commands/<command>/execRequests/<requestInstance>上で使用して、この生成された<requestInstance>を削除することができる。<command>の属性execDisable、execPause、execResumeは使用されなくてもよい。
上記で詳細に述べたように、4つの属性(execEnable、execDisable、execPause、execResume)が構成および使用されて、コマンド(<command>または<requestInstance>)のそれぞれコマンド実行、中断コマンド実行、再開コマンド実行、および取消コマンド実行を呼び出す。
代替として、4つの特殊な<command>リソースがデータ構造、すなわち、.../commands/enable、.../commands/disable、.../commands/pause、および.../commands/resume、において作成されてもよい。この4つの特殊なコマンドは、それぞれの「execResource」属性のみを有してもよい。
.../commands/enableが使用されて、一般的なコマンド実行を呼び出してもよい。例えば、RESTfulメソッドCREATEまたはUPDATEの動作を、属性execResourceがexecResource=「.../commands/<command>」に設定された「.../commands/enable」リソース上で発行して、「.../commands/<command>」のコマンド実行を呼び出す。
.../commands/disableが使用されて、.../commands/<command>(または.../commands/<command>/execRequests/<requestInstance>)の一般的な取消しコマンド実行を呼び出してもよい。例えば、RESTfulメソッドCREATEまたはUPDATEを、属性execResourceがexecResource=.../commands/<command>(または.../commands/<command>/execRequests/<requestInstance>)に設定された.../commands/disableリソース上で発行して、.../commands/<command>(または.../commands/<command>/execRequests/<requestInstance>)の取消しコマンド実行を呼び出す。
.../commands/pauseが使用されて、既存の.../commands/<command>(または.../commands/<command>/execRequests/<requestInstance>)の中断コマンド実行を呼び出してもよい。例えば、RESTfulメソッドCREATEまたはUPDATEを、属性execResourceがexecResource=.../commands/<command>(または.../commands/<command>/execRequests/<request−Instance>)に設定された./commands/pauseリソース上で発行して、.../commands/<command>(または.../commands/<command>/execRequests/<request−Instance>)の中断コマンド実行を呼び出してもよい。
.../commands/resumeが使用されて、既存の.../commands/<command>(または.../commands/<command>/execRequests/<requestInstance>)の再開コマンド実行を呼び出してもよい。例えば、RESTfulメソッドCREATEまたはUPDATEを、属性execResourceがexecResource=.../commands/<command>(または.../commands/<command>/execRequests/<requestInst−ance>)に設定された、./commands/resumeリソース上で発行して、再開コマンド実行を呼び出してもよい。
xREMコマンド管理についての例示的なメッセージフローチャート
図29A乃至29Rは、リソースコマンドのxREMについての例示的なメッセージフローを説明するメッセージフローチャートである。図29A乃至29Rのメッセージフローは、図22C、25Bおよび28A乃至28Dのコマンドリソース構造を参照して説明する。メッセージフローは、リソースコマンドまたは<commands>の他の構造を使用して実行されてもよい。
まず図29Aを参照すると、リソースコマンド構造を作成するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図29Aのメッセージフローを使用して作成されたリソースコマンド構造は、図22C、図25Bおよび図28Aに示すリソースコマンド構造の一部またはすべてを含んでもよい。例えば、リソースコマンド構造は、それらの図に示される<command>の要素のすべてを含んでもよい。あるいは、リソースコマンド構造は、示される<command>の要素のサブセットを含んでもよい。そのようなサブセットは、<command>の属性および/または下位リソースのサブセットを含んでもよい。例として、リソースコマンド構造は、(i)例えば、「attribute」、execEnableおよびcommandIDなどの属性、および(ii)例えば、execParameters、execRequests、subscriptionsなどの下位リソース、を含んでもよい。別の例として、リソースコマンド構造は、(i)例えば「attribute」、execEnable、execDisable、execPause、execResume、およびcommandIDなどの属性、および(ii)例えばexecParameters、execRequests、およびsubscriptionsなどの下位リソース、を含んでもよい。さらに別の例として、リソースコマンド構造は、(i)例えば「attribute」、execEnable、execDisable、およびcommandIDなどの属性、および(ii)例えばexecParameters、execRequests、およびsubscriptionsなどの下位リソースを含んでもよい。リソースコマンド構造は、図22C、25Bおよび28Aに示される<command>の要素(例えば属性および下位リソース)の他の組み合わせを含んでもよい。
リソースコマンド構造はまた、図22C、25Bおよび29Aに示されない<command>の他の要素を含んでもよい。それらの他の要素は、図22C、25Bおよび28Aに示される<command>の要素の任意の組み合わせと組み合わせた、リソースコマンド構造に含まれてもよい。
リソースコマンド構造の作成を開始するために、発行元は、RESTfulメソッドCREATEをM2Mサーバに発行してもよい。発行元は、例えばNA、M2MデバイスおよびM2M GWのいずれかであってもよい。発行元としてのM2MデバイスまたはM2M GWは、M2Mサーバへの登録に応答して、または登録の一部としてRESTfulメソッドUPDATEを発行してもよい。M2Mデバイス、M2M GW、またはNAは、またある時に、RESTfulメソッドCREATEを発行してもよい。
<sclbase>の所与のノードにおいて、リソースコマンド構造の作成を容易にするために、RESTfulメソッドCREATEは、リソースコマンド構造をその下に作成することができるノード(例えばリソース)の識別子を含んでもよい。例えば、RESTfulメソッドCREATEは、リソース<mgmtObjs>の識別子(以降「<mgmtObjs>識別子」)を含んでもよく、それにより、リソースコマンド構造を作成することができるノードとしてリソース<mgmtObjs>を識別することができる。
代替として、RESTfulメソッドCREATEは、リソース<commands>を、リソースコマンド構造をその下に作成することができるノードとして識別するためのリソース<commands>の識別子(以降「<commands>識別子」)を含んでもよい。<mgmtObjs>および<commands>識別子の各々は、上記のように、例えばURI、リンク、アドレスのいずれであってもよい。説明を簡潔にするために、以下では、リソースコマンド構造がリソース<mgmtObjs>の下に作成されてもよいと仮定する。ただし、リソースコマンド構造は<sclbase>の任意のノードの下に作成されてもよい。
RESTfulメソッドCREATEはまた、リソースコマンド構造の任意の属性を埋めるための情報を含んでもよい。例えば、RESTfulメソッドCREATEは、commandID属性を埋める情報を含んでもよく、それにより、実行を要求し、リソースコマンド構造を使用して実行することができる非RESTfulコマンドのタイプを示すことができる。
RESTfulメソッドCREATEはさらに、リソースコマンド構造の下位リソース(例えば、パラメータリソース)の1つまたは複数を埋めるための情報を含んでもよい。例えば、RESTfulメソッドCREATEは、下位リソースexecParametersを埋めるための1つまたは複数のパラメータおよび/または引数を含んでもよい。それらのパラメータおよび/または引数は、リソース<command>および/または非RESTfulコマンドに固有であってもよい。RESTfulメソッドCREATEはまた、非RESTfulコマンドに従って、下位リソースexecMode、execBaseDelay、execAdditionDelay、execFrequency、execNumber、およびexecResourceのいずれかを埋めるための情報も含んでもよい。
RESTfulメソッドCREATEを受信した後に、M2Mサーバは、M2Mサーバのリソース<mgmtObjs>の下にリソースコマンド構造を作成してもよい。作成されたリソースコマンド構造(以降「サーバ<command>」)は、図22C、25Bおよび28Aに示す<command>の要素すべてを含んでもよい。あるいは、サーバ<command>は、例えば<command>の属性および/または下位リソースのサブセットなどの、示される<command>の要素のサブセットを含んでもよい。サーバ<command>は、例えば、「attribute」、execEnableおよびcommandID属性、ならびにexecParameters、execRequestsおよびsubscriptionsの下位リソースを含んでもよい。
あるいは、サーバ<command>は、「attribute」、execEnable、execDisable、execPause、execResumeおよびcommandID属性、ならびにexecParameters、execRequestsおよびsubscriptionsの下位リソースを含んでもよい。さらに別の例として、サーバ<command>は、「attribute」、execEnable、execDisableおよびcommandID属性、ならびにexecParameters、execRequestsおよびsubscriptionsの下位リソースを含んでもよい。サーバ<command>は、<command>の要素(例えば、属性および下位リソース)(図22C、25Bおよび27Aに示されるものおよび示されないもの)の他の組み合わせを含んでもよい。
サーバ<command>の属性および/または下位リソースを埋めるための情報が、RESTfulメソッドCREATEに含まれている場合、M2Mサーバは、そのような対応する属性および/または下位リソースを、提供された情報で埋めてもよい。所与の属性および/または下位リソースを埋めるための情報が提供されない場合、M2Mサーバはそのような属性および/または下位リソースを当初作成された時の状態のままにしてもよい(例えばブランクとするか、あるいはデフォルトの属性および/またはパラメータを有する)。下記でより詳細に説明するように、属性および下位リソースは、属性および/または下位リソースを埋めるための情報を含むRESTfulメソッドUPDATEをM2Mサーバに発行することにより、サーバ<command>の作成後に埋められてもよい。
RESTfulメソッドCREATEに応答して、M2Mサーバは応答メッセージ(「RESPONSE」)を発行元に送信してもよい。M2Mサーバは、示されるようにサーバ<command>を作成した後にRESPONSEを送信してもよい。あるいは、M2Mサーバは、サーバ<command>の作成中にRESPONSEを送信してもよい。M2Mサーバはまた、発行元に確認応答(「ACK/NACK」)メッセージ(図示せず)を送信して、RESTfulメソッドCREATEの受信を確認応答してもよい。発行元に(例えば一定時間内に)よりACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドCREATEの確認応答がされていないことを示してもよい。
レスポンスは、M2Mサーバがサーバ<command>の作成に成功したか、または失敗したかを示すインジケーション(例えばコード)を含んでもよい。インジケーションは、作成の成功を示す1つの値および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mサーバがサーバ<command>の作成に成功したことを示す第1のインジケーション(例えばコード)と、M2Mサーバがサーバ<command>の作成に失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mサーバは、M2Mサーバがサーバ<command>の作成に成功した場合にのみレスポンスを発行してもよい。
RESPONSEは、作成中にサーバ<command>に割り当てられたノードの識別子(「サーバ<command>識別子」)を含んでもよい。このサーバ<command>識別子が使用されて、サーバ<command>にアクセスしてもよい。サーバ<command>コマンド識別子は、例えばノードのURI、リンク、またはアドレスであってもよい。
RESPONSEは、作成中にexecEnable下位リソースに割り当てられたノードの識別子(「execEnable識別子」)も含んでもよい。上記で説明し、および下記でより詳しく説明するように、execEnable識別子が使用されて、コマンド実行の状態における変更を呼び出してもよい(例えばコマンド実行、取消しコマンド実行、中断コマンド実行および再開コマンド実行のいずれかを呼び出す)。
あるいは、RESPONSEはまた、execEnable識別子、作成中にexecDisableに割り当てられたノードの識別子(「execDisable識別子」)(存在する場合)、作成中にexecPauseに割り当てられたノードの識別子(「execPause識別子」)(存在する場合)、作成中にexecResumeに割り当てられたノードの識別子(「execResume識別子」)(存在する場合)、も含んでもよい。上記で説明し、および下記でより詳しく説明するように、execEnable、execDisable、execPause、およびexecResume識別子の各々は、コマンド実行の状態における変更を呼び出すために使用されてもよい。execEnableが使用されて、コマンド実行を呼び出してもよい。execDisableが使用されて、取消しコマンドの実行を呼び出してもよい。execPauseが使用されて、中断コマンドの実行を呼び出してもよい。execResumeが使用されて、再開コマンドの実行を呼び出してもよい。
代替として、M2Mサーバは、存在する場合はexecEnable、execDisable、execPause、およびexecResume識別子を、例えば「attribute」属性など、サーバ<command>の属性または下位リソースに格納してもよい。このようにして、そのように格納されたexecEnable、execDisable、execPauseおよびexecResume識別子のいずれかは、後に読み出されてもよい。
ここで図29Bを参照すると、サーバ<command>などのリソースコマンド構造から情報を読み出すための例示的なメッセージフローを説明するメッセージフローチャートが示される。読み出しを開始するために、NA(すなわち発行元)がRESTfulメソッドRETRIEVEをM2Mサーバに発行してもよい。RESTfulメソッドRETRIEVEはサーバ<command>識別子を含んでもよい。
RESTfulメソッドRETRIEVEを受信した後に、M2Mサーバはサーバ<command>識別子を使用して、サーバ<command>を検索してもよい。いったん検索されると、M2Mサーバは、読出可能な情報(例えば属性、パラメータおよび/または引数)を有するサーバ<command>の属性および/または下位リソースから、そのような読出可能な情報(以降「読出属性情報」および/または「読出下位リソース情報」)をクエリし、ならびに読み出してもよい。読出属性情報および/または読出下位リソース情報は、格納されたexecEnable、execDisable、execPause、およびexecResume識別子のいずれかを含んでもよい。
読出属性情報および/または読出下位リソース情報を取得した後に、M2MサーバはNAにRESPONSEを送信してもよい。このRESPONSEは、サーバ<command>識別子ならびに読出属性情報および/または読出下位リソース情報を含んでもよい。
代替として、RESTfulメソッドRETRIEVEが使用されて、読出可能な情報を有するサーバ<command>の属性および/または下位リソースから、そのような読出可能な情報の1つまたは複数の選択部分を読み出してもよい。このことを容易にするために、RESTfulメソッドRETRIEVEは、読出可能な情報の選択部分を有するサーバ<command>の属性および/または下位リソースに割り当てられた各ノードの識別子を含んでもよい。その識別子(または2つ以上ある場合は複数の識別子)を使用して、M2Mサーバは、読出可能な情報(以降「読出属性情報および/または読出下位リソース情報」)の選択部分を検索し、クエリし、および取得してもよい。そしてM2Mサーバは、選択された読出属性情報および/または読出下位リソース情報を含むRESPONSEをNAに送信してもよい。
図示しないが、M2Mサーバはまた、RESTfulメソッドRETRIEVEの受信を確認応答するために、発行元にACK/NACKメッセージを送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドRETRIEVEの確認応答がされていないことを示してもよい。
ここで図29Cを参照すると、サーバ<command>またはサーバ<command>インスタンスの集合(「サーバ<command>インスタンス」)などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートが示される。削除を開始するために、発行元は、RESTfulメソッドDELETEをM2Mサーバに発行してもよい。発行元は、NA、M2Mデバイス、またはM2M GWであってもよい。M2Mデバイスおよび/またはM2M GWは、リブート、非RESTfulコマンドの取消し、および登録解除等に応答して、RESTfulメソッドDELETEを発行してもよい。
RESTfulメソッドDELETEは、サーバ<command>識別子を含んでもよい。あるいは、RESTfulメソッドDELETEは、サーバ<command>インスタンスの集合が作成されたリソース(例えばサーバ<commands>)に割り当てられたノードの識別子を含んでもよい(以降「サーバ<commands>識別子」)。
RESTfulメソッドDELETEを受信した後、M2Mサーバは、サーバ<command>識別子またはサーバ<commands>識別子を使用して、サーバ<command>またはサーバ<commands>をそれぞれ検索し、および削除してもよい。このことは、サーバ<command>のすべての属性および/または下位リソースを削除すること、またはサーバ<commands>について、かかるサーバ<commands>のサーバ<command>インスタンスの各々を削除することを含んでもよい。
RESTfulメソッドDELETEに応答して、M2Mサーバは発行元にRESPONSEを送信してもよい。M2Mサーバは、示されるようにサーバ<command>またはサーバ<commands>を削除した後にRESPONSEを送信してもよい。あるいは、M2Mサーバは、サーバ<command>またはサーバ<commands>の削除中にRESPONSEを送信してもよい。M2Mサーバは、RESTfulメソッドDELETEの受信を確認応答するために、発行元にACK/NACKメッセージ(図示せず)を送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドDELETEの確認応答がされていないことを示してもよい。
RESPONSEは、M2Mサーバがサーバ<command>またはサーバ<commands>の削除に成功したか、または失敗したかを示すインジケーション(例えばコード)を含んでもよい。インジケーションは、削除の成功を示す1つの値であってもよく、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mサーバがサーバ<command>またはサーバ<commands>の削除に成功したことを示す第1のインジケーション(例えばコード)、およびM2Mサーバがサーバ<command>またはサーバ<commands>の削除に失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mサーバは、M2Mサーバがサーバ<command>またはサーバ<commands>の削除に成功した場合にのみ、RESPONSEを発行してもよい。
図29Dは、サーバ<command>などのリソースコマンド構造を、非RESTfulコマンドを実行する際に使用する情報によって更新するための例示的なメッセージフローを説明するメッセージフローチャートである。図29E乃至29Nは、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行を呼び出すための例示的なメッセージフローを説明するフローチャートである。図29Dのメッセージフローおよび図29E乃至29Nのメッセージフローは、RESTfulメソッドUPDATEを使用してもよいことに対し、図29Dのメッセージフローは、RESTfulメソッドUPDATEを使用して、サーバ<command>などのリソースコマンド構造の要素を、非RESTfulコマンドを実行する際に(すなわちコマンド実行が呼び出された後に)使用することができる情報(例えば属性、パラメータおよび/または引数)で埋めてもよい。ただし、図29E乃至29Nのメッセージフローは、RESTfulメソッドUPDATEを使用して、非RESTfulコマンドのコマンド実行を呼び出させてもよい。
ここで図29Dを参照すると、NA(すなわち発行元)はM2MサーバにRESTfulメソッドUPDATEを発行して、更新を開始してもよい。RESTfulメソッドUPDATEは、サーバ<command>識別子、およびサーバ <command>の属性および/または下位リソースを情報で埋めるためのそのような情報(例えば、属性、パラメータおよび/または引数)を含んでもよい。上記のRESTfulメソッドCREATEと同様に、RESTfulメソッドUPDATEは、commandID属性を埋めるための情報を含んでもよく、それにより実行を要求し、およびリソースコマンド構造を使用して実行することができる非RESTfulコマンドのタイプを示してもよい。
RESTfulメソッドUPDATEはさらに、リソースコマンド構造の下位リソース(例えば、パラメータリソース)の1つまたは複数を埋めるための情報を含んでもよい。例えば、RESTfulメソッドUPDATEは、execParameters下位リソースを埋めるための1つまたは複数のパラメータおよび/または引数を含んでもよい。それらのパラメータおよび/または引数は、リソース<command>および/または非RESTfulコマンドに固有であってもよい。RESTfulメソッドUPDATEはまた、非RESTfulコマンドに従って、下位リソースexecMode、execBaseDelay、execAdditionDelay、execFrequency、execNumber、およびexecResourceのいずれかを埋めるための情報も含んでもよい。
RESTfulメソッドUPDATEの受信後、M2Mサーバは、サーバコマンド識別子を使用してサーバ<command>を検索する。その後、M2Mサーバは、そのサーバ<command>の属性および/または下位リソースを、提供された情報で埋めてもよい。任意の所与の属性および/または下位リソースを埋めるための情報が提供されない場合、M2Mサーバは、そのような属性および/または下位リソースを当初作成された状態(例えばブランク、またはデフォルトの属性および/もしくはパラメータを有する)または最後に変更された状態のままにしてもよい。
RESTfulメソッドUPDATEに応答して、M2Mサーバは発行元にRESPONSEを送信してもよい。M2Mサーバは、示されるように、サーバ<command>を更新した後にRESPONSEを送信してもよい。あるいは、M2Mサーバは、サーバ<commands>の更新中にレスポンスを送信してもよい。M2Mサーバはまた、RESTfulメソッドUPDATEの受信を確認応答するために、発行元にACK/NACKメッセージ(図示せず)を送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
RESPONSEは、M2Mサーバがサーバ<command>の更新に成功したか、または更新に失敗したかを示すインジケーション(例えばコード)を含んでもよい。インジケーションは、更新の成功を示す1つの値、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mサーバがサーバ<command>の更新に成功したことを示す第1のインジケーション(例えばコード)、およびサーバ<command>の更新に失敗したことを示す第2のインジケーション(例えばコード)含んでもよい。別の代替として、M2Mサーバは、M2Mサーバがサーバ<command>の更新に成功した場合にのみRESPONSEを発行してもよい。
RESPONSEはまた、サーバ<command>識別子、ならびに/または更新された属性および/もしくは下位リソースを含んでもよい。RESPONSEはさらに、属性および/または下位リソースを更新するのに使用された情報、または同様のことを示す確認を含んでもよい。
ここで図29Eを参照すると、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行を呼び出すための例示的なメッセージフローを説明するフローチャートが示される。更新を開始するために、NA(すなわち発行元)は、RESTfulメソッドUPDATEをM2Mサーバに発行する。このRESTfulメソッドUPDATEは、サーバ<command>識別子を含むと共に、下位リソースexecEnableを指定してもよい(例えば、.../<command>/execEnable)。あるいは、RESTfulメソッドUPDATEはexecEnable識別子を含んでもよい。
そのRESTfulメソッドUPDATEに応答して、M2Mサーバは、発行元に、RESTfulメソッドUPDATEの受信を確認応答するためのACK/NACKメッセージ(RESPONSE(レスポンス)として示される)を送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
M2Mサーバは、サーバ<command>の属性および/または下位リソースに従って、非RESTfulコマンドのコマンド実行を呼び出してもよい。M2Mサーバは、コマンド実行を呼び出すことの一部として、いくつかの機能を実行してもよい。これらの機能は、例えば、サーバ<command>(例えば、commandID)により識別されるコマンドを、M2MデバイスまたはM2M GWによって解釈または実行することができる非RESTfulコマンドに変換または翻訳することを含んでもよい。上記機能はまた、属性、パラメータおよび/または引数を、サーバ<command>により識別されるコマンドと、M2MデバイスまたはM2M GWにより解釈または実行することができる非RESTfulコマンドとの間でマッピングする(「マッピングされた属性、パラメータおよび/または引数」)ための機能も含んでもよい。
M2Mサーバはまた、execRequests下位リソースの下にリソース<requestInstance>を作成して、呼び出されたサーバ<command>を保持し、および追跡してもよい。リソース<requestInstance>は、サーバ<command>の属性および/または下位リソースの1つまたは複数を含んでもよい。M2Mサーバは、リソース<requestInstance>を作成する時に、そのような属性および/または下位リソースをサーバ<command>から継承またはインポートしてもよい。サーバ<command>が要素の様々な組み合わせを含んでもよいと仮定すると、リソース<requestInstance>はまた、要素の様々な組み合わせを含んでもよい。例えば、リソース<requestInstance>は、図25B、28Cおよび28Dに示すリソース <requestInstance>の要素のすべてを含んでもよく、それらの要素は、例えば図22C、25Bおよび28Aに示すサーバ<command>への必然的結果であってもよい。
あるいは、リソース<requestInstance>は、示されるリソース<requestInstance>の要素のサブセットを含んでもよい。そのようなサブセットは、リソース<requestInstance>の属性および/または下位リソースのサブセットを含んでもよい。例として、リソース<requestInstance>は、「attribute」、execEnable、execStatus、execResult およびexecDisable属性、ならびにsubscriptionsサブスクリプションリソースを含んでもよい。別の例として、リソース<requestInstance>は、「attribute」、execEnable、execStatus、execResult、およびexecDisable、execPause、およびexecResume属性、ならびにsubscriptions下位リソースを含んでもよい。さらに別の例として、リソース<requestInstance>は、「attribute」、execEnable、execStatusおよびexecResult属性、ならびにsubscriptions下位リソースを含んでもよい。下位リソースは、図25B、図28Cおよび図28Dに示すサーバ<command>および/またはリソース<requestInstance>の要素(例えば、属性および下位リソース)の他の組み合わせを含んでもよい。
リソース<requestInstance>は、図25B、図28Cおよび図28Dには示されない<command>の他の要素も含んでもよい。それらの他の要素は、図25B、図28Cおよび図28Dに示すリソース<requestInstance>の要素の任意の組み合わせと組み合わせたリソース<requestInstance>に含まれてもよい。
リソース<requestInstance>をexecRequests下位リソースの下に作成すると、M2Mサーバは、リソース<requestInstance>に、リソース<requestInstance>が作成されたノードの識別子を割り当ててもよい(「<requestInstance>識別子」)。この<requestInstance>識別子は、上記述べたように、例えばURI、リンクおよびアドレスのいずれであってもよい。
M2Mサーバは、リソース<requestInstance>によりインポートされ、または継承されたサーバ<command>の属性および/または下位リソースに埋められた情報の一部またはすべてを、リソース<requestInstance>にインポート(またはリソース <requestInstance>に継承させる)してもよい。そのような情報は、サーバ<command> のexecParameters下位リソースに埋められた1つまたは複数のパラメータおよび/または引数を含んでもよい。情報はまた、例えばexecMode、execBaseDelay、execAdditionDelay、execFrequency、execNumber、およびexecResourceの下位リソースに埋められた情報の一部またはすべてを含んでもよい。
リソース<requestInstance>を作成した後に、M2Mサーバは、要求メッセージ(「REQUEST」(リクエスト))をM2Mデバイスおよび/またはM2M GWに送信してもよく、それによりかかるM2Mデバイスおよび/またはM2M GWにおけるコマンド実行を呼び出してもよい。リクエストは、非RESTfulコマンドを含んでもよい。REQUESTはまた、マッピングされた属性、パラメータ、および引数のいずれかを含んでもよい。
REQUESTに応答して、M2Mデバイスおよび/またはM2M GWは、非RESTfulコマンドを実行してもよい。M2Mデバイスおよび/またはM2M GWは、リクエストへのRESPONSE(「COMMAND EXECUTION RESPONSE」(コマンド実行レスポンス))を送信してもよい。このCOMMAND EXECUTION RESPONSEは、存在する場合は結果を含むことができる(「{}」の記号で表される)。M2Mサーバは、結果を抽出し、および、後の読み出しのために、リソース<requestInstance>のexecResult下位リソースに格納してもよい。代わりに、かつ/またはそれに加えて、M2Mサーバは、結果をNAへのRESPONSE(「NA RESPONSE」(応答))において送信してもよい。結果を取得した後に、NAはそれを処理してもよい。
COMMAND EXECUTION RESPONSEはまた、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのコマンド実行を実行したことに成功したか、または非RESTfulコマンドのコマンド実行を実行したことに失敗したかを示すインジケーション(例えばコード)も含んでもよい。インジケーションは、コマンド実行の成功を示す1つの値および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mデバイスおよび/またはM2M GWがコマンド実行に成功したことを示す第1のインジケーション(例えばコード)、およびM2Mデバイスおよび/またはM2M GWがコマンド実行に失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mデバイスおよび/またはM2M GWは、M2Mデバイスおよび/またはM2M GWがコマンド実行に成功した場合にのみRESPONSEを発行してもよい。
図には示さないが、M2Mサーバは、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのコマンド実行に失敗したときに、リソース<requestInstance>を削除してもよい。M2Mサーバはまた、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのコマンド実行に失敗したことを通知されることに応答して、サーバ<command>および/またはサーバ<commands>の1つもしくは複数を削除してもよい。
ここで図29Fを参照すると、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートが示される。図29Fのメッセージフローは、以下の点を除いて図29Eのメッセージフローと同様である。図29Fのメッセージフローでは、M2Mサーバは、リソース<requestInstance>を作成する前にリクエストを発行してもよい。また、M2Mサーバは、リソース<requestInstance>を作成した後にCOMMAND EXECUTION RESPONSEを受信してもよい。
図29Gは、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートである。図29Gのメッセージフローは、以下の点を除いて図29Eのメッセージフローと同様である。図29Gのメッセージフローでは、execDisable、execPauseおよび/またはexecResume属性(または下位リソース)を含むリソース<requestInstance>を作成した後に、M2Mサーバは、対応するexecDisable識別子、execPause識別子および/またはexecResume識別子を発行元に送信してもよい。
あるいは、M2Mサーバは、execEnable識別子、execDisable識別子、execPause識別子、およびexecResume識別子を、例えば「attribute」属性など、リソース<requestInstance>の属性または下位リソースに格納してもよい。このようにして、そのように格納されたexecEnable識別子、execDisable識別子、execPause識別子、およびexecResume識別子は後に読み出されてもよい。下記で説明するように、発行元(例えばNA)は、execDisable識別子、execPause識別子および/またはexecResume識別子を使用して、取消しコマンド実行、中断コマンド実行および/または再開コマンド実行をそれぞれ呼び出してもよい。
ここで図29Hを参照すると、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行を呼び出すための別の例示的なメッセージフローを説明するフローチャートが示される。図29Hのメッセージフローは、以下の点を除いて図29Gのメッセージフローと同様である。図29Gのメッセージフローでは、M2Mサーバは、リソース<requestInstance>を作成する前にリクエストを発行してもよい。また、M2Mサーバは、リソース<requestInstance>を作成した後にコマンド実行応答を受信してもよい。
図29Iおよび図29Jは、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行の状態の変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、NA(すなわち発行元)は、RESTfulメソッドUPDATEをM2Mサーバに発行してもよい。このRESTfulメソッドUPDATEは、<requestInstance>識別子を含むとともに、下位リソースexecDisableを指定してもよい(例えば、.../<command>/execDisable)。あるいは、RESTfulメソッドUPDATEは、M2Mサーバから送信されるRESPONSEを介して取得されるexecDisable識別子(図29I)または、リソース<requestInstance>の属性からそれを読み出した後のDisable識別子を含んでもよい(図29J)。
そのRESTfulメソッドUPDATEに応答して、M2Mサーバは、ACK/NACKメッセージ(応答として図示する)を発行元に送信して、RESTfulメソッドUPDATEの受信を確認応答してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
M2Mサーバは次いで、サーバ<command>の属性および/または下位リソースに従って、非RESTfulコマンドのCANCEL COMMAND EXECUTION(「取消しコマンド実行」)を呼び出してもよい。M2Mサーバは、CANCEL COMMAND EXECUTIONを呼び出すことの一部としていくつかの機能を実行してもよい。これらの機能は、例えば、リソース<requestInstance>により識別されるCANCEL COMMAND EXECUTIONを、非RESTfulコマンドの実行のCANCEL COMMAND EXECUTIONを呼び出す非RESTfulコマンド(「非RESTful取消しコマンド」)に変換または翻訳することを含んでもよい。上記機能は、リソース<requestInstance>により識別されるコマンドと、非RESTful取消しコマンドとの間でマッピングされた属性、パラメータおよび/または引数を作成する機能も含んでもよい。
CANCEL COMMAND EXECUTIONを呼び出すための機能を実行した後に、M2Mサーバは、M2Mデバイスおよび/またはM2M GWにREQUESTを送信してもよく、それにより、かかるM2Mデバイスおよび/またはM2M GWにおいてCANCEL COMMAND EXECUTIONを呼び出してもよい。REQUESTはまた、非RESTful取消しコマンドを含んでもよい。リクエストはまた、非RESTful取消しコマンドを実行するためのマッピングされた属性、パラメータ、および引数も含んでもよい。
REQUESTに応答して、M2Mデバイスおよび/またはM2M GWは、非RESTful取消しコマンドを実行してもよい。M2Mデバイスおよび/またはM2M GWはCOMMAND EXECUTION RESPONSE(コマンド実行レスポンス)を送信してもよい。このCOMMAND EXECUTION RESPONSEは、存在する場合には結果を含んでもよい。M2Mサーバは、結果を抽出し、および後の呼び出しのために、リソース<requestInstance>のexecResult下位リソースに結果を格納してもよい。代わりに、かつ/またはそれに加えて、M2Mサーバは、結果をNAレスポンスにおいて送信してもよい。結果を取得した後に、NAはそれらを処理してもよい。
COMMAND EXECUTION RESPONSEはまた、M2Mデバイスおよび/またはM2M GWが非RESTful取消しコマンドの取消しコマンド実行を実行したことに成功したか、または非RESTful取消しコマンドの取消しコマンド実行を実行したことに失敗したかを示すインジケーション(例えばコード)も含んでもよい。インジケーションは、CANCEL COMMAND EXECUTIONの成功を示す1つの値および失敗を示す別の値であってもよい。あるいは、レスポンスは、M2Mデバイスおよび/またはM2M GWがCANCEL COMMAND EXECUTIONに成功したことを示す第1のインジケーション(例えばコード)、およびM2Mデバイスおよび/またはM2M GWがCANCEL COMMAND EXECUTIONに失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mデバイスおよび/またはM2M GWは、M2Mデバイスおよび/またはM2M GWが取消しコマンド実行に成功した場合にのみレスポンスを発行してもよい。
図には示さないが、M2Mサーバは、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのCANCEL COMMAND EXECUTIONに失敗したときに、リソース<requestInstance>を削除してもよい。M2Mサーバはまた、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのCANCEL COMMAND EXECUTIONに失敗したことを通知されることに応答して、サーバ<command>および/またはサーバ<commands>の1つもしくは複数を削除してもよい。
図29Kおよび29Lは、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行の状態における変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、NA(すなわち発行元)は、RESTfulメソッドUPDATEをM2Mサーバに発行してもよい。このRESTfulメソッドUPDATEは、<requestInstance>識別子を含むとともに、下位リソースexecPauseを指定してもよい(例えば、.../<command>/execPause)。あるいは、RESTfulメソッドUPDATEは、M2Mサーバから送信される応答を介して取得されるexecPause識別子(図29K)または、リソース<requestInstance>の属性から取得されたそれを読み出した後のexecPause識別子(図29L)を含んでもよい。
そのRESTfulメソッドUPDATEに応答して、M2Mサーバは、ACK/NACKメッセージ(応答として図示する)を発行元に送信して、RESTfulメソッドUPDATEの受信を確認応答してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
M2Mサーバは次いで、サーバ<command>の属性および/または下位リソースに従って、非RESTfulコマンドのPAUSE COMMAND EXECUTION(中断コマンド実行)を呼び出してもよい。M2Mサーバは、PAUSE COMMAND EXECUTIONを呼び出すことの一部としていくつかの機能を実行してもよい。それらの機能は、例えば、リソース<requestInstance>により識別されるPAUSE COMMAND EXECUTIONを、実行している非RESTfulコマンドのPAUSE COMMAND EXECUTIONを呼び出すための非RESTfulコマンド(「非RESTful中断コマンド」)に変換または翻訳することを含んでもよい。機能は、リソース<requestInstance>により識別されるコマンドと、非RESTful中断コマンドとの間でマッピングされる属性、パラメータおよび/または引数を作成する機能も含んでもよい。
PAUSE COMMAND EXECUTIONを呼び出すための機能を実行した後に、M2Mサーバは、M2Mデバイスおよび/またはM2M GWにREQUESTを送信してもよく、それにより、かかるM2Mデバイスおよび/またはM2M GWにおいてPAUSE COMMAND EXECUTIONを呼び出してもよい。リクエストはまた、非RESTful中断コマンドを含んでもよい。リクエストはまた、非RESTful中断コマンドを実行するためのマッピングされた属性、パラメータおよび引数も含んでもよい。
REQUESTに応答して、M2Mデバイスおよび/またはM2M GWは、非RESTful中断コマンドを実行してもよい。M2Mデバイスおよび/またはM2M GWは、COMMAND EXECUTION RESPONSE(コマンド実行レスポンス)を送信してもよい。このCOMMAND EXECUTION RESPONSEは、存在する場合は結果を含んでもよい。M2Mサーバは、結果を抽出し、および後の読み出しのために、当該結果をリソース<requestInstance>のexecResult下位リソースに格納してもよい。代わりに、かつ/または加えて、M2Mサーバは、結果をNA RESPONSE(NAレスポンス)において送信してもよい。存在する場合、結果を取得した後に、NAはそれらを処理してもよい。
COMMAND EXECUTION RESPONSEはまた、M2Mデバイスおよび/またはM2M GWが非RESTful中断コマンドの中断コマンド実行に成功したか、または非RESTful中断コマンドの中断コマンド実行に失敗したかを示すインジケーション(例えばコード)も含んでもよい。インジケーションは、PAUSE COMMAND EXECUTIONの成功を示す1つの値、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mデバイスおよび/またはM2M GWがPAUSE COMMAND EXECUTIONを実行したことに成功したかを示す第1のインジケーション(例えばコード)、およびM2Mデバイスおよび/またはM2M GWがPAUSE COMMAND EXECUTIONを実行したことに失敗したかを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mデバイスおよび/またはM2M GWは、M2Mデバイスおよび/またはM2M GWがPAUSE COMMAND EXECUTIONに成功した場合にのみCOMMAND EXECUTION RESPONSEを発行してもよい。
示されないが、M2Mサーバは、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのPAUSE COMMAND EXECUTIONを実行したことに失敗したときに、リソース<requestInstance>を削除してもよい。M2Mサーバはまた、M2Mデバイスおよび/またはM2M GWが非RESTful中断コマンドのPAUSE COMMAND EXECUTIONを実行したことに失敗したことを通知されることに応答して、サーバ<command>および/またはサーバ<commands>の1つもしくは複数を削除してもよい。
図29Mおよび29Nは、サーバ<command>などのリソースコマンド構造を更新して、非RESTfulコマンドのコマンド実行の状態における変更を呼び出すための例示的なメッセージフローを説明するフローチャートである。更新を開始するために、NA(すなわち発行元)は、RESTfulメソッドUPDATEをM2Mサーバに発行してもよい。このRESTfulメソッドUPDATEは、<requestInstance>識別子を含むとともに、下位リソースexecResumeを指定してもよい(例えば、.../<command>/exec−Resume)。あるいは、RESTfulメソッドUPDATEは、M2Mサーバから送信されるRESPONSEを介して取得されるexecResume識別子(図29M)、または、リソース<requestInstance>(図29N)の属性からそれを読み出した後のexecResume識別子を含んでもよい。
このRESTfulメソッドUPDATEに応答して、M2Mサーバは、ACK/NACKメッセージ(RESPONSEとして示される)を発行元に送信して、RESTfulメソッドUPDATEの受信を確認応答してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
M2Mサーバは次いで、サーバ<command>の属性および/または下位リソースに従って、非RESTfulコマンドのRESUME COMMAND EXECUTION(再開コマンド実行)を呼び出してもよい。M2MサーバはRESUME COMMAND EXECUTIONを呼び出すことの一部としていくつかの機能を実行してもよい。これらの機能は、例えば、リソース<requestInstance>により識別されるRESUME COMMAND EXECUTIONを、中断された非RESTfulコマンドのRESUME COMMAND EXECUTION行を呼び出すための非RESTfulコマンド(「非RESTful再開コマンド」)に変換または翻訳することを含んでもよい。当該機能はまた、リソース<requestInstance>により識別されるコマンドと、非RESTful再開コマンドとの間でマッピングされた属性、パラメータおよび/または引数を作成するための機能を含んでもよい。
RESUME COMMAND EXECUTIONを呼び出す機能を実行した後、M2Mサーバは、M2Mデバイスおよび/またはM2M GWにREQUESTを送信してもよく、それにより、そのM2Mデバイスおよび/またはM2M GWにおいてRESUME COMMAND EXECUTIONを呼び出してもよい。リクエストは非RESTful再開コマンドを含んでもよい。リクエストはまた、非RESTful再開コマンドを実行するためのマッピングされた属性、パラメータおよび引数のいずれかを含んでもよい。
REQUESTに応答して、M2Mデバイスおよび/またはM2M GWは、非RESTful再開コマンドを実行してもよい。M2Mデバイスおよび/またはM2M GWは、COMMAND EXECUTION RESPONSE(コマンド実行レスポンス)を送信してもよい。このCOMMAND EXECUTION RESPONSEは、存在する場合は結果を含んでもよい。M2Mサーバは、結果を抽出し、後の読み出しのために、当該結果をリソース<requestInstance>のexecResult下位リソースに格納してもよい。代わりに、かつ/または加えて、M2Mサーバは、結果をNA RESPONSE(NAレスポンス)において送信してもよい。存在する場合、結果を取得した後に、NAはそれらを処理してもよい。
COMMAND EXECUTION RESPONSEはまた、M2Mデバイスおよび/またはM2M GWが非RESTful再開コマンドの再開コマンド実行の実行に成功したか、または非RESTful再開コマンドの再開コマンド実行の実行に失敗したかを示すインジケーション(例えばコード)も含んでもよい。インジケーションは、RESUME COMMAND EXECUTIONの成功を示す1つの値、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mデバイスおよび/またはM2M GWがRESUME COMMAND EXECUTIONを実行したことに成功したことを示す第1のインジケーション(例えばコード)、およびM2Mデバイスおよび/またはM2M GWがRESUME COMMAND EXECUTIONを実行したことに失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mデバイスおよび/またはM2M GWは、M2Mデバイスおよび/またはM2M GWがRESUME COMMAND EXECUTIONを実行したことに成功した場合にのみCOMMAND EXECUTION RESPONSEを発行してもよい。
図には示されてないが、M2Mサーバは、M2Mデバイスおよび/またはM2M GWが非RESTfulコマンドのRESUME COMMAND EXECUTIONを実行したことに失敗したときに、リソース<requestInstance>を削除してもよい。M2Mサーバはまた、M2Mデバイスおよび/またはM2M GWが非RESTful中断コマンドのRESUME COMMAND EXECUTIONを実行したことに失敗したことを通知されることに応答して、サーバ<command>および/またはサーバ<commands>の1つもしくは複数を削除してもよい。
ここで図29Oを参照すると、<requestInstance>などのリソースコマンド構造を、非RESTfulコマンドを行う際に使用する情報により更新するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図29Dのメッセージフローと同様に、図29Oのメッセージフローは、RESTfulメソッドUPDATEを使用して、<requestInstance>などのリソースコマンド情報の要素を、非RESTfulコマンドを行う際に使用することができる情報(例えば属性、パラメータおよび/または引数のいずれか)で埋めてもよい。
示されるように、NA(すなわち発行元)は、RESTfulメソッドUPDATEをM2Mサーバに発行して、更新を開始してもよい。RESTfulメソッドUPDATEは、<requestInstance>識別子、ならびに<requestInstance>の属性および/または下位リソースを情報で埋めるためのかかる情報(例えば、属性、パラメータおよび/または引数)を含んでもよい。
RESTfulメソッドUPDATEの受信後、M2Mサーバは、<requestInstance>識別子を使用して、<requestInstance>を検索する。その後、M2Mサーバは、その<requestInstance>の属性および/または下位リソースを、提供された情報で埋める。任意の所与の属性および/または下位リソースを埋めるための情報が提供されない場合、M2Mサーバは、そのような属性および/または下位リソースを、当初作成されたように(例えばブランク、またはデフォルトの属性および/もしくはパラメータを有する)、または最後に変更されたままにしてもよい。
RESTfulメソッドUPDATEに応答して、M2Mサーバは発行元にRESPONSEを送信してもよい。M2Mサーバは、示されるように、<requestInstance>を更新した後にRESPONSEを送信してもよい。あるいは、M2Mサーバは、<requestInstance>の更新中にRESPONSEを送信してもよい。M2Mサーバはまた、RESTfulメソッドUPDATEの受信を確認応答するために、発行元にACK/NACKメッセージ(図示せず)を送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドUPDATEの確認応答がされていないことを示してもよい。
RESPONSEは、M2Mサーバが<requestInstance>の更新に成功したか、または失敗したかを示すインジケーション(例えばコード)を含んでもよい。このインジケーションは、更新の成功を示す1つの値、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mサーバが<requestInstance>の更新に成功したことを示す第1のインジケーション(例えばコード)、および<requestInstance>の更新に失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mサーバは、M2Mサーバが<requestInstance>の更新に成功した場合にのみレスポンスを発行してもよい。
RESPONSEはまた、<requestInstance>識別子、ならびに/または更新された属性および/もしくは下位リソースを含んでもよい。RESPONSEはさらに、属性および/または下位リソースの更新に使用された情報、または同様のことを示す確認を含んでもよい。
図29Pは、<requestInstance>などのリソースコマンド構造から情報を読み出すための例示的なメッセージフローを説明するメッセージフローチャートである。読み出しを開始するために、NA(すなわち発行元)はRESTfulメソッドRETRIEVEをM2Mサーバに発行する。このRESTfulメソッドRETRIEVEは、<requestInstance>識別子を含んでもよい。
RESTfulメソッドRETRIEVEの受信後、M2Mサーバは<requestInstance>識別子を使用して<requestInstance>を検索してもよい。検索されると、M2Mサーバは、読出可能な情報(例えば属性、パラメータおよび/または引数)を有する<requestInstance>の属性および/または下位リソースからそのような読出可能な情報(以降「読出属性情報」および/または「読出下位リソース情報」)をクエリし、および取得してもよい。読出属性情報および/または読出下位リソース情報は、例えば、格納されたexecDisable、execPause、およびexecResume識別子のいずれか、ならびに/またはexecStatusおよびexecResultsなどの他の属性および/もしくは下位リソースからの任意の情報を含んでもよい。
読出属性情報および/または読出下位リソース情報を取得した後、M2MサーバはNAにRESPONSEを送信してもよい。このRESPONSEは、<requestInstance>識別子、ならびに読出属性情報および/または読出下位リソース情報を含んでもよい。
代替として、RESTfulメソッドRETRIEVEが使用されて、読出可能な情報を有する<requestInstance>の属性および/または下位リソースから、そのような読出可能な情報の1つまたは複数の選択部分を読み出してもよい。このことを容易にするために、RESTfulメソッドRETRIEVEは、読出可能な情報の選択部分を有するサーバ<command>の属性および/または下位リソースに割り当てられた各ノードの識別子を含んでもよい。その識別子(または2つ以上ある場合は複数の識別子)を使用して、M2Mサーバは、選択された読出属性情報および/または読出下位リソース情報を検索し、クエリし、および取得してもよい。そしてM2Mサーバは、選択された読出属性情報および/または読出下位リソース情報を含むRESPONSEをNAに送信してもよい。
示されないが、M2Mサーバはまた、RESTfulメソッドRETRIEVEの受信を確認応答するために発行元にACK/NACKメッセージを送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドRETRIEVEの確認応答がされていないことを示してもよい。
図29Qは、<requestInstance>などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートである。削除を開始するために、発行元は、RESTfulメソッドDELETEをM2Mサーバに発行してもよい。発行元は、NA、M2Mデバイス、またはM2M GWであってもよい。M2Mデバイスおよび/またはM2M GWは、リブート、非RESTfulコマンドの取消し、登録解除等に応答して、RESTfulメソッドDELETEを発行してもよい。
RESTfulメソッドDELETEは、<requestInstance>識別子を含んでもよい。あるいは、RESTfulメソッドDELETEは、<requestInstance>インスタンスの集合が作成されたリソース(例えば<requestInstances>)に割り当てられたノードの識別子を含んでもよい(以降「<requestInstances>識別子」)。
RESTfulメソッドDELETEの受信後、M2Mサーバは、<requestInstance>識別子または<requestInstances>識別子を使用して、<requestInstance>または<requestInstances>をそれぞれ検索し、および削除してもよい。このことは、<requestInstance>のすべての属性および/または下位リソースを削除すること、あるいは<requestInstances>については、それら<requestInstances>の各<requestInstance>を削除することを含んでもよい。
RESTfulメソッドDELETEに応答して、M2Mサーバは発行元にRESPONSEを送信してもよい。M2Mサーバは、示されるように、<requestInstance>または<requestInstances>を削除した後に、RESPONSEを送信してもよい。あるいは、M2Mサーバは、<requestInstance>または<requestInstances>の削除中に、レスポンスを送信してもよい。M2Mサーバは、RESTfulメソッドDELETEの受信を確認応答するために、発行元にACK/NACKメッセージ(図示せず)を送信してもよい。発行元により(例えば一定時間内に)ACK/NACKメッセージが受信されないことは、M2MサーバによってRESTfulメソッドDELETEの確認応答がされていないことを示してもよい。
レスポンスは、M2Mサーバが<requestInstance>または<requestInstances>の削除に成功したか、または失敗したかを示すインジケーション(例えばコード)を含んでもよい。インジケーションは、削除の成功を示す1つの値、および失敗を示す別の値であってもよい。あるいは、RESPONSEは、M2Mサーバが<requestInstance>または<requestInstances>の削除に成功したことを示す第1のインジケーション(例えばコード)、およびM2Mサーバが<requestInstance>または<requestInstances>の削除に失敗したことを示す第2のインジケーション(例えばコード)を含んでもよい。別の代替として、M2Mサーバは、M2Mサーバが<requestInstance>または<requestInstances>の削除に成功した場合にのみRESPONSEを発行してもよい。
ここで図29Rを参照すると、サーバ <command>、サーバ<commands>および/または<requestInstance>などのリソースコマンド構造を削除するための例示的なメッセージフローを説明するメッセージフローチャートが示される。図29Rのメッセージフローは、図29Cのメッセージフローと図29I(または図29J)のメッセージフローとの組み合わせ、または図29Qのメッセージフローと図29I(または図29J)のメッセージフローとの組み合わせと同様である。示されるように、発行元がRESTfulメソッドDELETEをM2Mサーバに発行するときに、M2Mサーバは、任意の<requestInstance>がコマンド実行または中断コマンド実行に使用されているかを判定し、そしてM2Mサーバは、それを削除する前にそのような<requestInstance>の取消しコマンド実行を実施してもよい。M2Mサーバは、図29Iまたは図29Jのメッセージフローに従って、取消しコマンド実行を実施してもよい。
前述したことに加えて、M2Mサーバは、RESTfulメソッドCREATEまたはRESTfulメソッドDELETEが発行されることなく、サーバ<command>または別のリソースコマンド構造を作成および/または削除してもよい。
例示的なゲートウェイベースのマシンツーマシン(「M2M」)デバイス管理
一実施形態に従って、図30Aは、OMA GwMO「透過」モードを利用することによりM2M GW(G’)を介してDタイプETSI M2Mデバイスを管理するための例示的アーキテクチャを示す。図30Aを参照すると、NREMはGwMO固有のインタフェースおよびコンポーネントを使用して、GREMからデバイス情報を取得し、GREMはそのタスクを実行するためにGwMOインタフェースを介してDREMと順に通信する。次いで、NREMは、メッセージ交換のためにOMA DMプロトコル−クライアントサーバ対話モデルを使用して直接DREMと通信してもよい。「透過」モードでは、GREMはデバイスを管理するためにOMA DMプロトコルをサポートする必要はないことに留意されたい。
一実施形態に従って、図30Bは、ETSI M2M xREMの例示的アーキテクチャを示す。図30Bを参照すると、xREMが機能的な下位モジュールに分割される。例えば、REMサーバは、デバイス管理においてサーバの役割を果たす(OMA DMまたはACSにおけるDMサーバと同様)。REMクライアントは、デバイス管理においてクライアントの役割を果たす(OMA DMまたはCPEにおけるDMクライアントと同様)。REMプロキシコンポーネントは、REMプロキシサーバ(NREMにおける)およびREMプロキシクライアント(DREMにおける)とそれぞれ通信するGREMのみに存在する。REMプロキシサーバは、REMプロキシコンポーネントと通信してGWの後ろにあるデバイスの情報を取得するために使用されるNREMに存在する。REMプロキシクライアントは、DREMに存在し、DREMは、デバイス情報をGWにレポートするようにREMプロキシコンポーネントに応答するために使用される。デバイス情報は最終的にNREMに転送される。
プロキシモードでは、M2M GWは、「中間者」(man-in-the-middle)のように動作してもよい。M2M GWは、図31Aに示すようにGwMO、ならびにDMクライアントおよびDMサーバの両方をサポートすることができ、図31Aは、OMA GwMO 1.0を利用するための例示的アーキテクチャを示す。このモードでは、NREMは直接DREMと通信せず、代わりにGREMにより変換され、および中継される。DREMに対して、GREMはサーバのように見え、NREMに対しては、GREMはクライアントのように振舞う。このモードは、M2M GWにより多くの機能と機能性を追加する。例示的な利益は、コマンドの論理出力数および応答集約などのより付加価値の高いサービス、ならびにM2Mコアにおけるトラフィック負荷の軽減、および制約されたM2Mデバイス、特にスリープ状態のノードの管理の高効率化を含む。図31Bはこのモードに対するxREMの例示的アーキテクチャを示す。
一実施形態に従って、M2Mデバイス(D’)はETSI M2Mサービス能力を有さなくてもよい。それらはOMA DMのクライアント機能は有さないが、他のOMAでないデバイス管理プロトコルを有すると想定されてもよい。その結果、M2M GWは「適合」モードを採用して、OMAプロトコルと他の管理プロトコルとの間で変換してもよい。図32Aは、OMA GwMO 1.0を利用するための例示的アーキテクチャを示す。図32Bは、ETSI M2M xREMの例示的アーキテクチャを示す。「プロキシ」モードと比較して、SNMPなどのいくつかの非OMA管理プロトコルは、dIaインタフェースまたは別のNDM−1インタフェースのいずれかの上でのM2M GWとM2Mデバイスとの間の対話に利用されてもよい。プロトコル変換は、管理コマンドのマッピング/翻訳だけでなく、管理ツリー構造(またはリソース)のマッピング/翻訳等も指すことに留意されたい。D’タイプのデバイスが実際にOMA DMのクライアント機能を有する場合は、「透過」モードおよび「プロキシ」モードも適用することができる。
一実施形態に従って、dタイプの非ETSI M2Mデバイスがいくつかの異なる管理プロトコルを使用することができることが想定されてもよい。その結果、M2M GWは「適合」モードを使用して、それらを管理してもよい。図33Aおよび図33Bに示すアーキテクチャは、図32Aおよび図32Bに示すものと同様である。dタイプのデバイスは、ZigBeeコーディネータなどの非ETSIのM2M GWであり、それを通じて、ETSIのM2Mサービス能力を使用しおよびアクセスして、非ETSI M2Mエリアネットワークをともに接続することができることに留意されたい。
一実施形態では、図34は、OMA GwMOを利用したGWベースのデバイス管理の図を示す。図34に示すように、単一のM2M GWは、複数のM2Mエリアネットワークを異なるタイプのM2Mデバイスに接続することができる。M2M GWは、異なるエリアネットワークに対して、透過モード、プロキシモード、または適合管理モードを課すことができる。
図30乃至図34のすべてにおいて、追加的なOMA GwMOおよびDM論理エンティティ(OMA DMサーバなど)は必ずしもxREMの一部ではなく、代わりにxREMの外部にある独立したエンティティであってもよい。ただし、本明細書に開示されるアーキテクチャが適用されてもよい。例えば、図35は、OMA DMおよびM2M GWを部分的に緊密に統合する場合の例示的アーキテクチャを示す。図36は、OMA DMおよびM2M GWを緩く統合する場合の例示的アーキテクチャを示す。
M2Mゲートウェイの後ろにあるM2MエリアネットワークおよびM2Mデバイスを管理するための例示的なデータモデル
下記でより詳細に説明するように、M2Mゲートウェイの後ろにあるマシンツーマシン通信(M2M)エリアネットワークおよびM2Mデバイスを管理するための管理オブジェクト(MO)。M2Mエリアネットワーク管理は、デバイスリスト(device inventory)および構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、およびデバイスのグループ管理などの機能を提供してもよい。これは、アプリケーション(A)、M2Mダイレクトデバイス(D)、M2Mローカルデバイス(dタイプ、D’タイプ、またはDタイプのデバイス)、およびM2Mゲートウェイ(G)を含んでもよい。
管理オブジェクト(MO)は、M2MゲートウェイによりM2Mエリアネットワークを管理するために定義されてもよい。そのような1つのMOは、etsiAreaNwkInfoリソースであり、当該リソースは、エリアネットワーク情報および構成についての管理オブジェクトであってもよい。別のMOは、M2MローカルデバイスリストについてのMOとすることができるetsiAreaNwkDeviceInventoryリソースであってもよい。M2Mローカルデバイスグループについての管理オブジェクトは、例えばetsiAreaNwkDeviceGroupsリソースであってもよい。M2Mローカルデバイスのグループを操作する管理オブジェクトは、etsiGroupMgmtOperationsおよびetsiAreaNwkGroupOperationsのいずれかであってもよく、ならびにM2Mデバイス内に統合されたセンサについての管理オブジェクトリソースは、etsiSensorsリソースであってもよい。
MOは、異なる従属レベルにおいて編成および/または配置されてもよい。例えば、MOは、M2Mサーバにおける<sclBase−of−Server>/scls/<GSCL>の下のいずれかにある同一のプレースホルダの下位リソースであってもよい。例として、M2Mゲートウェイの後ろにあるアタッチされたデバイスを全体として管理するために、<sclBase−of−server>/scls/<GSCL>/attachedDevicesの下にmgmtObjs下位リソースが作成されてもよい。MOは、例えば、<sclBase−of−Server>/scls/<GSCL>/attachedDevices/mgmtObjsの下に配置されてもよい。MOは、別のMOの下位リソースであってもよい。例えば、etsiSensorsは、<deviceInventory>の下位リソースであってもよく、<deviceInventory>はetsiAreaNwkDeviceInventoryの下位リソースであってもよい。
図37に示すように、エリアネットワーク情報および構成についてのMO、etsiAreaNwkInfoは、サブスクリプションの集合および<areaNwkInstance>などの、1つまたは複数の属性および複数の下位リソースを含んでもよい。<areaNwkInstance>は、M2Mエリアネットワークのインスタンスであってもよい。etsiAreaNwkInfoの属性は、例えば、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、contentType、moID、originalMO、numOfAreaNwks、およびdescriptionを含んでもよい。numOfAreaNwks属性は、M2Mエリアネットワークの数を表してもよい。description属性は、mgmtObjのテキスト形式の詳細であってもよい。属性(および/または変数)は、ETSI M2M TS 102 690に準拠してもよい。代替として、属性および/またはサブスクリプションの集合は、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、contentType、moID、originalMO、numOfAreaNwks、およびdescriptionを含み、保持し、および/または格納してもよい。
図38Aに示すように、etsiAreaNwkInfoリソースの<areaNwkInstance>下位リソースは、1つまたは複数の属性および複数の下位リソースを含んでもよい。<areaNwkInstance>下位リソースは、(i)M2Mエリアネットワークの識別を収容するareaNwkID属性、(ii)例えばBluetooth(登録商標)/6LoWPAN、802.15.4/6LoWPAN、Wi−FiネットワークなどM2Mエリアネットワークのタイプを指定するareaNwkType属性、(iii)M2Mエリアネットワークの動作チャネル周波数を指定するworkmgChannelFrequency属性、および(iv)M2Mエリアネットワークのアドレスモード(例えば、IPv4、IPv6、Short MAC(メディアアクセス制御)、またはLong MAC)を指定するaddressMode属性、を含んでもよい。
<areaNwkInstance>下位リソースの複数の下位リソースは、サブスクリプションの集合、<deviceInstance>下位リソース、attachedDevices下位リソース、グループ下位リソース、6LoWPAN下位リソース、Wi−Fi下位リソース、RFID下位リソース、およびZigBee下位リソースを含んでもよい。
<deviceInstance>下位リソースは、エリアネットワークインスタンスにおける単一のデバイスについての情報を含んでもよい。attachedDevices下位リソースは、エリアネットワークにアタッチされたすべてのデバイスについてのプレースホルダであってもよく、およびグループ下位リソースは、グループ動作または動作の論理出力数に対して定義されたデバイスグループについてのプレースホルダであってもよい。6LoWPAN下位リソースは、6LoWPANネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークが6LoWPANネットワークであるときに使用されてもよい。Wi−Fi下位リソースは、Wi−Fiネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがWi−Fiネットワークであるときに使用されてもよい。RFID下位リソースは、RFIDネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがRFIDネットワークであるときに必要とされる場合があり、およびZigBee下位リソースは、ZigBeeネットワークに関連するパラメータを含むプレースホルダであってもよく、そのような情報は、エリアネットワークがZigBeeネットワークであるときに必要とされる場合がある。拡張が下位リソースとして含まれてもよく、および拡張のためにプレースホルダを提供してもよい。
<areaNwkInstance>下位リソースに関連付けられた属性は、(i)エリアネットワークインスタンスにおけるデバイスの数を表すことができるnumOfDevices(ii)2回のスリープ間の間隔を表すことができるsleepInterval(iii)各スリープの継続時間を表すことができるsleepDuration(iv)そのエリアネットワーク<areaNwkInstance>下位リソースにおける最大の伝送単位を表すことができるMTU、および(v)IETF CoAPブロックサイズ伝送で使用されるブロックサイズを表すことができるblockSize、を含んでもよい。blockSizeは、エリアネットワーク<areaNwkInstance>下位リソースが制約されたアプリケーションプロトコル(CoAPプロトコル)をサポートするときに、有用である場合がある。sleepInterval属性は、一般的な時間間隔として使用されてもよく、これを通じてM2Mサーバは、何らかの報告または応答を、例えばsleepIntervalの時間単位ごと、など周期的に返送するようにM2Mデバイスおよび/またはM2Mゲートウェイに指示することができる。
図38Bに示すように、6LoWPAN下位リソースは、subscriptions下位リソースのサブスクリプション、ならびに6LoWPANにおけるアドレス指定、ルーティング、および近隣の検出のいずれかに関連する複数の属性を有してもよい。複数の属性は、(i)エリアネットワークのIPアドレスプレフィクスを指定するためのipAddrPrefix属性、および(ii)M2Mエリアネットワークのルーティングモードを指定するためのroutingMode属性を含んでもよい。6LoWPANネットワークについて、routingMode属性は、ルーティングモードがメッシュアンダー(mesh-under)またはルートオーバー(route-over)になることを指定してもよい。
複数の属性はまた、(i)変更に備えてヘッダ圧縮コンテキスト情報を発信し続ける最小の時間を指定するためのminContextChangeDelay属性(ii)送信されることになる要求されていないルータアドバタイズ(advertisements)の最大数を格納および/または指定するためのmaxRtrAdvertisements属性(iii)すべてのノードのマルチキャストアドレスに送信される2つの連続したルータアドバタイズ間の最小の間隔を指定するためのminDelayBetweenRas属性(iv)ルータアドバタイズメッセージを、受信されたルータ要請(Solicitation)メッセージへの応答として送信する最大の遅延を指定するためのmaxRaDelayTime属性(v)一時的な隣接キャッシュについてのタイマを格納し、および提供するためのentativeNceLifetime属性(vii)重複したアドレス検出メッセージについてのホップ制限値を格納および/または指定するためのhopLimit属性(viii)第1のmaxRtrSolicationsのルータ要請の最初の再送に対する間隔を格納および/または指定するためのrtrSolicitationInterval属性(ix)rtrSolicitationIntervalにより定義された最初の再送の回数を格納および/または指定するためのmaxRtrSolicitations属性(x)デバイスが最初の再送の後に二進指数バックオフを使用する場合があるため、ルータ要請に対する最大の再送間隔を格納および/または指定するためのmaxRtrSolicitationInterval属性、を含んでもよい。hopLimit、rtrSolicitationInterval、maxRtrSolicitations、およびmaxRtrSolicitationInterval属性は、デバイスに適用可能であってもよい。他のパラメータは、デバイスおよびM2Mゲートウェイの両方に適用可能であってもよい。
図38Cに示すように、etsiAreaNwkInfoリソースの<areaNwkInstance>下位リソースは、1つまたは複数の属性およびsubscriptions下位リソースを含んでもよい。<areaNwkInstance>下位リソースは、(i)M2Mエリアネットワークの識別を収容するareaNwkID属性(ii)例えばBluetooth/6LoWPAN、802.15.4/6LoWPAN、Wi−FiネットワークなどのM2Mエリアネットワークのタイプを指定するareaNwkType属性(iii)M2Mエリアネットワークの動作チャネル周波数を指定するworkmgChannelFrequency属性(iv)M2Mエリアネットワークのアドレスモード(例えば、IPv4、IPv6、Short MAC(メディアアクセス制御)、またはLong MAC)を指定するaddressMode属性(v)6LoWPAN属性、Wi−Fi属性、RFID属性、ZigBee属性、を含んでもよい。
6LoWPAN属性は、6LoWPANネットワークに関連するパラメータ、例えばエリアネットワークが6LoWPANネットワークであるときに使用することができる情報、を含むプレースホルダであってもよい。Wi−Fi属性は、Wi−Fiネットワークに関連するパラメータ、例えばエリアネットワークがWi−Fiネットワークであるときに使用することができる情報、を含むプレースホルダであってもよい。RFID属性は、RFIDネットワークに関連するパラメータを含むプレースホルダであってもよく、およびZigBee属性は、ZigBeeネットワークに関連するパラメータを含むプレースホルダであってもよい。
加えて、<areaNwkInstance>下位リソースは、特定タイプのエリアネットワークに関連するより多くの属性を有してもよい。例えば、M2Mエリアネットワークが6LoWPANネットワークである場合、<areaNwkInstance>下位リソースは、6LoWPANにおけるアドレス指定、ルーティング、および/または隣接検出に関連するいくつかの属性を含んでもよい。複数の属性は、(i)ipAddrPrefix属性、(ii)routingMode属性、(iii)minContextChangeDelay属性、(iv)maxRtrAdvertisements属性、(vi)minDelayBetweenRas属性、(vii)maxRaDelayTime属性、(viii)tentativeNceLifetime属性、(ix)hopLimit属性、(x)rtrSolicitationInterval属性、(xi)rtrSolicitationIntervalにより定義された最初の再送の回数を格納および/または指定するためのmaxRtrSolicitations属性、ならびに(xii)maxRtrSolicitationInterval属性、を含んでもよい。hopLimit、rtrSolicitationInterval、maxRtrSolicitations、およびmaxRtrSolicitationInterval属性はデバイスに適用可能であってもよい。他のパラメータは、デバイスおよびM2Mゲートウェイの両方に適用可能であってもよい。
図39に示すように、etsiAreaNwkDeviceInventory MOは、(i)M2Mゲートウェイにアタッチされた各アクティブなデバイスについての個々の<deviceInstance>情報の集合を含むことができる、<deviceInstance>下位リソース(ii)各エリアネットワークを識別することができる<areaNwkInstance>下位リソース(iii)定義されたデバイスグループに対するプレースホルダを提供することができるgroups下位リソース、および(iv)サブスクリプション集合下位リソース。サブスクリプション集合下位リソースは、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FSSフォーマットに含めることができるcontentType、moID、originalMO、description(例えば、mgmtObjのテキスト形式の詳細)、およびM2Mゲートウェイにアタッチされたデバイスの数、numOfDevicesなどの属性を含んでもよい。
同一のM2Mゲートウェイの下のM2Mエリアネットワークは、単一のetsiAreaNwkDeviceInventory下位リソースに対応してもよく、または各エリアネットワークがその自身のetsiAreaNwkDeviceInventory下位リソースを有してもよい。etsiAreaNwkDeviceInventory下位リソースは、etsiAreaNwkInfo下位リソースの下位にあってもよい。代替として、etsiAreaNwkDeviceInventory MOは、<areaNwkInstance>下位リソースおよび/またはgroups下位リソースを含まなくてもよい。
図40Aに示すように、各<deviceInstance>は、deviceGroupsListなどのデバイスが属するグループの識別のリストと、D’A、またはDAなどの、このデバイス上のすべてのアプリケーションのアプリケーション識別のグループ、deviceApplicationsListと、隣接ノードの識別のリスト、deviceNeighborsListと、バッテリ情報、etsiBatteryと、メモリ情報、etsiMemoryと、センサ/アクチュエータ情報、etsiSensorと、6LoWPANネットワークに関連するパラメータを含むプレースホルダを提供することができる6LoWPANと、Wi−Fiネットワークに関連するパラメータを含むプレースホルダを提供することができるWi−Fiと、RFIDネットワークに関連するパラメータを含むプレースホルダを提供することができるRFIDと、ZigBeeネットワークに関連するパラメータを含むプレースホルダを提供することができるZigBeeと、拡張のためのプレースホルダとすることができるextensionsと、を含んでもよい。
このグループは、例えばETSI TS 102 609に規定されるものなどの標準的なグループリソースを提供してもよい。<deviceInstance>は、デバイスのタイプとすることができるdeviceType、デバイスの識別子とすることができるdeviceID、デバイスのアドレス種別とすることができるaddressType、デバイスが属するM2Mエリアネットワークの識別を含むことができるareaNwkID、M2Mエリアネットワークの内部で使用されるデバイスの内部IPアドレスとすることができるinternaladdress、およびM2Mエリアネットワークの外部で使用されるデバイスの外部IPアドレスとすることができるexternaladdress、などの属性を含んでもよい。このアドレスは、M2Mゲートウェイにおけるアドレス変換でポート番号が使用される場合に、ポート情報を含んでもよい。さらに、2回のスリープ間の間隔、sleepIntervalと、各スリープの継続時間、sleepDuration、スリープもしくはアウェイク(awake)などのデバイス状態、ステータス、エリアネットワークにおける最大伝送単位を含むことができるMTU、およびIETF CoAPのブロックサイズ伝送で使用されるブロックサイズを含むことができるblockSize。
図40Bに示すように、各<deviceInstance>は、deviceGroupListなどのデバイスが属するグループの識別のリスト、例えば、D’A、またはDAなどの、そのデバイス上のすべてのアプリケーションのアプリケーション識別のグループ、deviceApplicationsList、隣接ノードの識別のリスト、deviceNeighborsList、バッテリ情報、etsiBattery、メモリ情報、etsiMemory、センサ/アクチュエータ情報、etsiSensor、を含んでもよい。サブスクリプション集合は、デバイスのタイプとすることができるdeviceType、デバイス識別子とすることができるdeviceID、デバイスのアドレス種別とすることができるaddressType、デバイスが属するM2Mエリアネットワークの識別を含むことができるareaNwkID、M2Mエリアネットワークの内部で使用されるデバイスの内部IPアドレスとすることができるinternaladdress、およびM2Mエリアネットワークの外部で使用されるデバイスの外部IPアドレスとすることができるexternaladdress、などの属性を含んでもよい。このアドレスは、M2Mゲートウェイにおけるアドレス変換でポート番号が使用される場合のポート情報を含んでもよい。さらに、2回のスリープ間の間隔であるsleepInterval、各スリープの継続時間であるsleepDuration、スリープ状態やアウェイク状態などのデバイス状態のステータス、送信されることになる要求されていないルータアドバタイズの最大数であるmaxRtrAdvertisements、すべてのノードのマルチキャストアドレスに送信される2回の連続したルータアドバタイズ間の最小の間隔であるminDelayBetweenRas、ルータアドバタイズメッセージを受信されたルータ要請メッセージへの応答として送信する際の最大の遅延であるmaxRaDelayTime、一時的な隣接キャッシュについてのタイマであるtentativeNceLifetime、重複したアドレス検出メッセージについてのホップの上限値であるhopLimit、第1のmaxRtrSolicationsのルータ要請の最初の再送の間隔であるrtrSolicitationInterval、最初の再送の回数であるmaxRtrSolicitations、および、デバイスが最初の再送の後に二進指数バックオフを使用することができることから、ルータ要請の最大の再送間隔であるmaxRtrSolicitationInterval。
図41Aに示すように、etsiAreaNwkDeviceGroups MOは、デバイスおよびサブスクリプションのグループを定義する<deviceGroupInstance>などの下位リソースを含んでもよい。サブスクリプション集合および属性は、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FFSとして形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescription、を含んでもよい。
図41Bに示すように、etsiAreaNwkDeviceGroups MOは、下位リソースのsubscriptionと、デバイスの複数グループの集合として定義するグループとを含んでもよい。etsiAreaNwkDeviceGroupsは、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FFS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescription、などの属性を含んでもよい。
各下位リソース<group>は、同一グループに属するデバイスの識別のリストを含んでもよい。加えて、デバイスは、複数の<group>インスタンスに属し、および存在してもよい。
図42に示すように、各<deviceGroupInstance>は、サブスクリプション集合を有するsubscriptionなどの下位リソースと、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FFS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionなどの属性とを含んでもよい。さらに、groupIDは、グループ種別を含むことができるグループの識別であるgroupType、グループにおけるデバイスの数などのgroupSize、グループにおけるデバイスの集合として定義されたメンバ、およびデバイスがそのグループのメンバになるための条件を指定する条件、を含んでもよい。
図43Aに示すように、etsiGroupMgmtOperations MOは、グループ上で実行されることになる動作または操作を表すことができる<operationInstance>と、各デバイスがデバイスのリストを含む定義されたデバイスグループのプレースホルダを含むことができ、および1つまたは複数の<operationInstance>によって操作されるgroups等の下位リソースを含んでもよい。サブスクリプション集合と属性は、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、contentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionを含んでもよい。
M2Mゲートウェイの後ろにあるM2Mデバイスのグループを管理/動作させるために使用されることに加えて、etsiGroupMgmtOperationsは、M2Mサーバに直接接続するM2Mデバイスのグループの動作を管理するために使用されてもよい。その場合は、etsiGroupMgmtOperationsは、<sclBase−of−Server>/scls/mgmtObjs/etsiGroupMgmtOperationsの下に配置されてもよい。対応する<operationInstance>は、M2Mデバイスまたはゲートウェイのグループの登録解除、M2Mデバイスまたはゲートウェイのグループのスリープモードへの移行、M2Mデバイスまたはゲートウェイのグループのリブート、およびM2Mデバイスまたはゲートウェイのグループ上での同一のソフトウェア/ファームウェアの更新の実行、を含んでもよい。
また、etsiGroupMgmtOperationsが使用されて、M2MデバイスまたはM2Mゲートウェイ上のアプリケーションのグループを管理してもよい。その場合、etsiGroupMgmtOperationsは、<sclBase−of−Server>/scls/<scl>/applications/mgmtObjs/etsiGroupMgmtOperationsの下に配置されてもよい。対応する<operationInstance>は、M2Mアプリケーションのグループの登録解除、およびM2Mアプリケーションのグループ上での同一のソフトウェア/ファームウェアの更新の実行、を含んでもよい。
図43Bに示すように、etsiAreaNwkDeviceGroupOperations MOは、グループ上で実行されることになる動作または操作を表すことができる<operationInstance>などの下位リソースを含んでもよい。サブスクリプション集合および属性は、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、contentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionを含んでもよい。
図44Aに示すように、各<operationInstance>は、サブスクリプション集合、ならびにexpirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FSS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionなどの属性、を有する下位リソースを含んでもよい。<operationInstance>は、下位リソースとして、<operationInstance>を実行することができるグループの識別のリストとすることができるdeviceGroupsListを含むgroupsと、<operationInstance>の結果の集合とすることができるexecResultsとを含んでもよく、ならびに<resultInstance>を含む下位リソースとそのサブスクリプションおよび属性aggregatedResultを有してもよい。
<resultInstance>は、単一のデバイスから結果を表してもよく、ならびに下位リソースサブスクリプションと、デバイス識別とすることができるdeviceID、deviceIDのデバイスからの結果とすることができるresultValue、deviceIDのデバイス上の<operationInstance>のステータスとすることができるexecStatus、deviceID上の<operationInstance>を開始することになるexecEnable、deviceID上の<operationInstance>を中断することになるexecPause、deviceID上の<operationInstance>を再開することになるexecResume、deviceID上の<operationInstance>を停止することになるexecDisable、集約された結果とすることができるaggregatedResult、<operationInstance>により必要とされる引数を含み、および動作固有とすることができるexecParametersを含む属性と、を含んでもよい。
さらに、operationIDは、<operationInstance>の識別であってもよく、および<operationInstance>何をあらわすかを指定してもよい。groupIDは、<operationInstance>を実行することができるグループの識別を提供してもよく、およびgroupIDは、<operationInstance>を複数の定義されたデバイスグループ上で実行できる場合の、複数の識別を含んでもよい。あるいは、それらの複数のグループ識別は、deviceGroupsListリソースに含まれてもよい。execEnableは、groupIDにおけるデバイス上で<operationInstance>を開始してもよい。execPauseは、groupIDにおけるデバイス上で<operationInstance>を中断してもよい。execResumeは、groupIDにおけるデバイス上で<operationInstance>を再開してもよい。execDisableは、groupIDにおけるデバイス上で<operationInstance>を停止してもよい。execStatusは<operationInstance>のステータスを提供してもよい。ステータスは、保留中、実行中、停止、中断、再開、実行が成功したデバイスの数、成功して終了したデバイスの数、および/または実行が失敗したデバイスの数、を含んでもよい。
図43Bに示すように、各<operationInstance>は、subscriptionsはサブスクリプション集合と、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FSS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionを含む属性とを有する、サブスクリプションなどの下位リソースを含んでもよい。さらに、groupIDは、<operation>を実行することができるグループの識別を提供してもよく、enableは<operation>を開始するために提供されてもよく、disableは<operation>を停止し、resultsは、<operation>の結果の集合を含んでもよく、aggregatedResultは集約された結果を含んでもよい。各<resultInstance>は、デバイスの識別を示すdeviceIDと、deviceIDのデバイスからの結果とすることができるresultなどの2つの属性を有してもよい。
図44に示すように、etsiSensors MOは、センサインスタンスについての<sensorInstance>などの下位リソースと、サブスクリプション集合を含むサブスクリプションと、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FSS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むdescriptionなどの属性と、を含んでもよい。etsiSensorsは、M2Mサービス能力を有するDタイプのM2Mデバイスに適用可能であってもよい。
図45に示すように、<sensorInstance>は、関連するグループを有するgroupsなどの下位リソースを含んでもよい。例えば、1つのgroupsは、<sensorInstance>を使用するデバイス上のD’A、またはDAアプリケーションを表すapplicationListであってもよい。Containersは、センサの測定値を格納してもよい。サブスクリプション集合および属性は、expirationTime、accessRightID、searchStrings、creationTime、lastModifiedTime、FSS形式とすることができるcontentType、moID、originalMO、およびmgmtObjのテキスト形式の詳細を含むことができるdescriptionを含んでもよい。sensorIDは<sensorInstance>の識別を記述してもよい。sensorTypeは、温度、圧力、<sensorInstance>の製造者を定義した製造者、および<sensorInstance>上で実行することが可能な動作を含むことができる動作などの<sensorInstance>の種別を記述してもよい。Enableは、センサの読み取りを可能にすることを含んでもよい。センサがスイッチセンサの場合は、enableはスイッチを入れることを意味してもよい。Enableは、動作の結果を格納する属性としてresultを有してもよい。Disableは、センサの測定値を無効にすることを含んでもよい。センサがスイッチセンサの場合は、disableはスイッチを切ることを意味してもよい。Disableは、動作結果を格納する属性としてresultを有してもよい。他の動作は特定のセンサに対して考えられてもよい。
例示的な動作環境
図46は、DAおよび/またはGAにより使用される管理オブジェクトに従ってREMを実行して、M2Mサーバ(ここでは<scl>)に登録した別のD/Gを管理するためのシステムの例示的アーキテクチャのブロック図である。
M2Mサーバ(すなわち<scl>)は、4702に示すように、自身の管理オブジェクトをD/Gに公表することができ、そして、DA/GAはD/Gにおけるそのような公表された管理オブジェクトにアクセスし、次いでM2Mサーバにおけるメッセージの中継を介して他のD/Gを管理することが可能になる。
図48Aは、1つまたは複数の開示される実施形態を実施することができる例示的な通信システム100の図である。通信システム100は、音声、データ、映像、メッセージング、放送等のコンテンツを複数の無線ユーザに提供する多元接続システムであってもよい。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC−FDMA)等の1つまたは複数のチャネルアクセス方式を採用してもよい。
図48Aに示すように、通信システム100は、無線送信/受信ユニット(WTRU)102a、102b、102cおよび102d、無線アクセスネットワーク(RAN)104、コアネットワーク106、公衆交換電話網(PSTN)108、インターネット110、ならびに他のネットワーク112を含んでもよい。ただし、開示される実施形態では、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図することが理解されよう。WTRU102a、102b、102cおよび102dの各々は、無線環境で動作および/または通信するように構成された任意のタイプのデバイスであってもよい。例として、WTRU102a、102b、102cおよび102dは、無線信号を送信および/または受信するように構成されてもよく、およびユーザデバイス(UE)、移動局、固定型または移動型の加入者ユニット、ページャ、携帯電話、携帯情報端末(PDA)、スマートフォン、ラップトップ機、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、および消費者電子製品などを含んでもよい。
通信システム100はまた、基地局114aおよび基地局114bも含んでもよい。基地局114aおよび114bの各々は、WTRU102a、102b、102cおよび102dの少なくとも1つと無線上でインタフェースをとって、コアネットワーク106、インターネット110、および/またはネットワーク112等の1つまたは複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスであってもよい。例として、基地局114aおよび114bは、ベーストランシーバ局(BTS)、NodeB、eNodeB、ホームNodeB、ホームeNodeB、サイトコントローラ、アクセスポイント(AP)、および無線ルータ等であってもよい。基地局114aおよび114bはそれぞれ単一の要素として示されるが、基地局114aおよび114bは任意の数の相互接続された基地局および/またはネットワーク要素を含んでよいことが理解されよう。
基地局114aは、RAN104の一部であってもよく、RAN104はまた、基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、中継ノード等のほかの基地局および/またはネットワーク要素(図示せず)を含んでもよい。基地局114aおよび/または基地局114bは、セルと呼ばれることもある特定の地理的領域(図示せず)内で無線信号を送信および/または受信するように構成されてもよい。セルはさらにセルセクタに分割されてもよい。例えば、基地局114aに関連付けられたセルは3つのセクタに分割されてもよい。そのため、一実施形態では、基地局114aは、3つの送受信機、すなわちセルの各セクタに1つを含んでもよい。別の実施形態では、基地局114aは、多入力多出力(MIMO)技術を採用してもよく、したがってセルの各セクタに複数の送受信機を利用してもよい。
基地局114aおよび114bは、エアインタフェース116上でWTRU102a、102b、102cおよび102dの1つまたは複数と通信してもよく、エアインタフェース116は、任意の適切な無線通信リンク(例えば無線周波(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光等)であってもよい。エアインタフェース116は、適切な無線アクセス技術(RAT)を使用して確立されてもよい。
より具体的には、上記で述べたように、通信システム100は多元接続システムであってもよく、ならびにCDMA、TDMA、FDMA、OFDMAおよびSC−FDMAなどの1つまたは複数のチャネルアクセス方式を採用してもよい。例えば、RAN104における基地局114a、ならびにWTRU102a、102bおよび102cは、ユニバーサルモバイルテレコミュニケーションズシステム(UMTS)地上波無線アクセス(UTRA)等の無線技術を実装してもよく、当該技術は、広帯域CDMA(WCDMA:登録商標)を使用してエアインタフェース116を確立してもよい。WCDMAは、高速パケットアクセス(HSPA)および/または発展型HSPA(HSPA+)などの通信プロトコルを含んでもよい。HSPAは高速ダウンリンクパケットアクセス(HSDPA)および/または高速アップリンクパケットアクセス(HSUPA)を含んでもよい。
別の実施形態では、基地局114aならびにWTRU102a、102bおよび102cは、発展型UMTS地上波無線アクセス(E−UTRA)などの無線技術を実装してもよく、当該技術は、ロングタームエボリューション(LTE)および/またはLTE−Advanced(LTE−A)を使用してエアインタフェース116を確立してもよい。
他の実施形態では、基地局114aならびにWTRU102a、102bおよび102cは、IEEE802.16(Worldwide Interoperability for Microwave Access(WiMAX))、CDMA2000、CDMA2000 IX、CDMA2000 EV−DO、Interim Standard 2000(IS−2000)、Interim Standard 95(IS−95)、Interim Standard 856(IS−856)、Global System for Mobile communications(GSM:登録商標)、Enhanced Data rates for GSM Evolution(EDGE)、およびGSM EDGE(GERAN)などの無線技術を実装してもよい。
図48Aにおける基地局114bは、例えば無線ルータ、ホームNodeB、ホームeNodeB、またはアクセスポイントであってもよく、ならびに職場、家庭、自動車、キャンパスなどの局所的な領域において無線接続を容易にするための任意の適切なRATを利用してもよい。一実施形態では、基地局114bならびにWTRU102cおよび102dは、IEEE802.11などの無線技術を実装して、無線ローカルエリアネットワーク(WLAN)を確立してもよい。別の実施形態では、基地局114bならびにWTRU102cおよび102dは、IEEE802.15などの無線技術を実装して無線パーソナルエリアネットワーク(WPAN)を確立してもよい。さらに別の実施形態では、基地局114bならびにWTRU102cおよび102dは、セルラベースののRAT(例えばWCDMA、CDMA2000、GSM、LTE、LTE−Aなど)を利用して、ピコセルまたはフェムトセルを確立してもよい。図38Aに示すように、基地局114bは、インターネット110への直接の接続を有してもよい。そのため、基地局114bは、コアネットワーク106を介してインターネット110にアクセスする必要がない場合もある。
RAN104は、コアネットワーク106と通信状態にあってもよく、コアネットワーク106は、WTRU102a、102b、102cおよび102dの1つまたは複数に音声、データ、アプリケーション、および/またはvoice over Internet Protocol(VoIP)サービスを提供するように構成された任意のタイプのネットワークであってもよい。例えば、コアネットワーク106は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続、および映像配布などを提供してもよく、ならびに/またはユーザ認証などの高レベルなセキュリティ機能を実行してもよい。図38Aには示さないが、RAN104および/またはコアネットワーク106は、RAN104と同一のRATまたは異なるRATを採用する他のRANと直接的な通信状態にあってもよく、または間接的な通信状態にあってもよいことが理解されよう。例えば、E−UTRA無線技術を利用することができるRAN104に接続されるのに加えて、コアネットワーク106はまた、GSM無線技術を採用する別のRAN(図示せず)と通信状態にあってもよい。
コアネットワーク106はまた、WTRU102a、102b、102cおよび102dがPSTN108、インターネット110および/または他のネットワーク112にアクセスするためのゲートウェイとしてサービスを提供してもよい。PSTN108は、従来の電話サービス(POTS)を提供する回線交換電話網を含んでもよい。インターネット110は、TCP/IPインターネットプロトコルスイートにおける伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)などの共通通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク112は、他のサービスプロバイダにより所有および/または運営される有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク112は、RAN104と同一のRATまたは異なるRATを採用することができる1つまたは複数のRANに接続された別のコアネットワークを含んでもよい。
通信システム100におけるWTRU102a、102b、102cおよび102dの一部またはすべては、マルチモード機能を含んでもよく、すなわち、WTRU102a、102b、102cおよび102dは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図38Aに示すWTRU102cは、セルラベースの無線技術を採用することができる基地局114a、およびIEEE802無線技術を採用することができる基地局114bと通信するように構成されてもよい。
図48Bは、例示的なWTRU102のシステム図である。図48Bに示すように、WTRU102は、プロセッサ118、送受信機120、送信/受信要素122、スピーカ/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド128、着脱不能メモリ130、着脱可能メモリ132、電源134、全地球測位システム(GPS)チップセット136、および他の周辺機能138を含んでもよい。WTRU102は、実施形態との整合性を保ちながら、上述の要素のサブコンビネーションを含んでよいことが理解されよう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連した1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、および状態機械などであってもよい。プロセッサ118は、シグナルコーディング、データ処理、電力制御、入出力処理、および/またはWTRU102がワイヤレス環境で動作することを可能にする他の機能を実行してもよい。プロセッサ118は送受信機120に結合されてもよく、送受信機120は送信/受信要素122に結合されてもよい。図48Bはプロセッサ118および送受信機120を別個の構成要素として示すが、プロセッサ118および送受信機は電子パッケージや電子チップに共に統合されてもよいことが理解されよう。
送信/受信要素122は、エアインタフェース116上で基地局(例えば基地局114a)に信号を送信し、または当該基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナであってもよい。別の実施形態では、送信/受信要素122は、例えばIR、UV、または可視光信号を送信および/または受信するように構成されたエミッタ/ディテクタであってもよい。さらに別の実施形態では、送信/受信要素122は、RF信号と光信号との両方を送信および受信するように構成されてもよい。送信/受信要素122は、無線信号の任意の組み合わせを送信および/または受信するように構成されてもよいことが理解されよう。
加えて、図48Bでは送信/受信要素122を1つの要素として示されるが、WTRU102は任意の数の送信/受信要素122を含んでもよい。より具体的には、WTRU102はMIMO技術を採用してもよい。そのため、一実施形態では、WTRU102は、エアインタフェース116上で無線信号を送信および受信するための2つ以上の送信/受信要素122(例えば複数のアンテナ)を含んでもよい。
送受信機120は、送信/受信要素122により送信されることになる信号を変調し、および送信/受信要素122により受信されることになる信号を復調するように構成されてもよい。上記のように、WTRU102はマルチモード機能を有してもよい。そのため、送受信機120は、WTRU102が例えばUTRAおよびIEEE802.11などの複数のRATを介して通信することを可能にする複数の送受信機を含んでもよい。
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126および/またはディスプレイ/タッチパッド128(例えば液晶ディスプレイ(LCD)ディスプレイユニットまたは有機発光ダイオード(OLED)ディスプレイユニット)に結合されてもよく、ならびにそれらからユーザ入力データを受信してもよい。プロセッサ118はまた、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力してもよい。加えて、プロセッサ118は、着脱不能メモリ130および/または着脱可能メモリ132などの任意タイプの適切なメモリからの情報にアクセスしてもよく、ならびにそれらにデータを記憶してもよい。着脱不能メモリ130は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、ハードディスク、または他の任意のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、およびセキュアデジタル(SD)メモリカードなどを含んでもよい。他の実施形態では、プロセッサ118は、サーバまたは家庭用コンピュータ(図示せず)などの、WTRU102に物理的に位置しないメモリからの情報にアクセスし、および当該メモリデータを記憶してもよい。
プロセッサ118は、電源134から電力を受け取り、その電力をWTRU102中の他の構成要素に分配および/または制御するように構成することができる。電源134は、WTRU102に電力を供給するのに適した任意の装置でよい。例えば、電源134は、1つまたは複数の乾電池(例えばニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含むことができる。
プロセッサ118はまた、GPSチップセット136にも結合されてもよく、GPSチップセット136は、WTRU102の現在の位置に関する位置情報(例えば経度および緯度)を提供するように構成されてもよい。GPSチップセット136からの情報に加えて、あるいはその代わりに、WTRU102は、基地局(例えば基地局114a、114b)からエアインタフェース116上で位置情報を受信し、および/または、2つ以上の近隣の基地局から信号が受信されることになるタイミングに基づいて自身の位置を判定してもよい。WTRU102は、実施形態との整合性を保ちながら、任意の適切な位置判定方法により位置情報を取得してよいことが理解されよう。
プロセッサ118はさらに、他の周辺機能138に結合されてもよく、それらは、追加的な特徴、機能性、および/または有線もしくは無線接続を提供する1つまたは複数のソフトウェアおよび/またはハードウェアモジュールを含んでもよい。例えば、周辺機器138は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ(写真または映像用)、ユニバーサルシリアルバス(USB)ポート、振動装置、テレビトランシーバ、ハンドフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、デジタルミュージックプレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。
図48Cは、一実施形態に従ったRAN104およびコアネットワーク106のシステム図である。上記のように、RAN104は、UTRA無線技術を採用して、エアインタフェース116上でWTRU102a、102bおよび102cと通信してもよい。RAN104はまた、コアネットワーク106と通信状態にあってもよい。図48Cに示すように、RAN104は、NodeB140a、140b、140cを含んでもよく、それらの各々は、エアインタフェース116上でWTRU102a、102bおよび102cと通信するための1つまたは複数の送受信機を含んでもよい。NodeB140a、140bおよび140cはそれぞれ、RAN104内の特定のセル(図示せず)に関連付けられてもよい。RAN104はまた、RNC142aおよび142bを含んでもよい。RAN104は実施形態との整合性を保ちながら、任意の数のNodeBおよびRNCを含んでもよいことが理解されよう。
図48Cに示すように、NodeB140aおよび140bは、RNC142aと通信状態にあってもよい。加えて、NodeB140cは、RNC142bと通信状態にあってもよい。NodeB140a、140bおよび140cは、Iubインタフェースを介してそれぞれのRNC142a、142bと通信してもよい。RNC142aおよび142bは、Iurインタフェースを介して相互に通信してもよい。RNC142aおよび142bの各々は、それらが接続されたNodeB140a、140bおよび140cを制御するように構成されてもよい。また、RNC142aおよび142bの各々は、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化などの他の機能を実行またはサポートするように構成されてもよい。
図48Cに示すコアネットワーク106は、メディアゲートウェイ(MGW)144、モバイルスイッチングセンター(MSC)146、サービングGPRSサポートノード(SGSN)148および/またはゲートウェイGPRSサポートノード(GGSN)150を含んでもよい。上記の各要素はコアネットワーク106の一部として記述されるが、これらの要素の任意の1つはコアネットワークオペレータ以外のエンティティにより所有および/または運営されてもよいことが理解されよう。
RAN104におけるRNC142aは、IuCSインタフェースを介してコアネットワーク106におけるMSC146に接続されてもよい。MSC146はMGW144に接続されてもよい。MSC146およびMGW144は、WTRU102a、102bおよび102cに、PSTN108等の回線交換ネットワークへのアクセスを提供して、WTRU102a、102bおよび102cと従来の陸線通信デバイスとの間の通信を容易にしてもよい。
RAN104におけるRNC142aはまた、IuPSインタフェースを介してコアネットワーク106におけるSGSN148に接続されてもよい。SGSN148はGGSN150に接続されてもよい。SGSN148およびGGSN150は、WTRU102a、102bおよび102cに、インターネット110等のパケット交換ネットワークへのアクセスを提供して、WTRU102a、102bおよび102cとIP使用可能デバイスとの間の通信を容易にしてもよい。
上述したように、コアネットワーク106はまたネットワーク112にも接続されてもよく、ネットワーク112は、他のサービスプロバイダにより所有および/または運営される有線または無線のネットワークを含んでもよい。
図48Dは、一実施形態に従ったRAN104およびコアネットワーク106のシステム図である。上述したように、RAN104は、E−UTRA無線技術を採用して、エアインタフェース116上でWTRU102a、102bおよび102cと通信してもよい。RAN104はまた、コアネットワーク106と通信状態にあってもよい。
RAN104は、eNodeB140a、140bおよび140cを含んでもよいが、RAN104は実施形態との整合性を保ちながら任意の数のeNodeBを含んでもよいことが理解されよう。eNodeB140a、140bおよび140cは各々、エアインタフェース116上でWTRU102a、102bおよび102cと通信するための1つまたは複数の送受信機を含んでもよい。一実施形態では、eNodeB140a、140bおよび140cはMIMO技術を実装してもよい。したがって、例えばeNodeB140aは、複数のアンテナを使用してWTRU102aに無線信号を送信し、およびWTRU102aから無線信号を受信してもよい。
eNodeB140a、140bおよび140cの各々は、特定のセル(図示せず)に関連付けられてもよく、ならびに無線リソース管理決定、ハンドオーバー決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリング等を処理するように構成されてもよい。図48Dに示すように、eNodeB140a、140bおよび140cは、X2インタフェース上で相互に通信してもよい。
図48Dに示すコアネットワーク106は、モビリティ管理ゲートウェイ(MME)142、サービングゲートウェイ144、およびパケットデータネットワーク(PDN)ゲートウェイ146を含んでもよい。上述した要素の各々はコアネットワーク106の一部として示されるが、それらの要素のいずれか1つは、コアネットワークオペレータ以外のエンティティによって所有および/または運営されてもよいことが理解されよう。
MME142は、S1インタフェースを介してRAN104におけるeNodeB140a、140bおよび140cの各々に接続されてもよく、ならびに制御ノードとしての役割を果たしてもよい。例えば、MME142は、WTRU102a、102bおよび102cのユーザの認証、ベアラのアクティブ化/非アクティブ化、ならびにWTRU102a、102bおよび102cの初期アタッチ中の特定サービングゲートウェイの選択等を担ってもよい。MME142はまた、RAN104と、GSMまたはWCDMAなどの他の無線技術を採用する他のRAN(図示せず)とを切り替えるための制御プレーン機能も提供してもよい。
サービングゲートウェイ144は、S1インタフェースを介してRAN104におけるeNodeB140a、140bおよび140cの各々に接続されてもよい。サービングゲートウェイ144は、一般に、WTRU102a、102bおよび102cにユーザデータパケットを送信してもよく、ならびにそれらからのユーザデータパケットを転送してもよい。サービングゲートウェイ144はまた、eNodeB間のハンドオーバー中のユーザプレーンアンカリング、ダウンリンクデータがWTRU102a、102bおよび102cに利用可能なときのページングのトリガ、ならびにWTRU102a、102bおよび102cのコンテキストを管理および記憶するなどの他の機能を実行してもよい。
サービングゲートウェイ144はまた、PDNゲートウェイ146に接続されてもよく、PDNゲートウェイ146は、WTRU102a、102bおよび102cにインターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102bおよび102cとIP使用可能デバイスとの間の通信を容易にしてもよい。
コアネットワーク106は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク106は、PSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102bおよび102cに提供して、WTRU102a、102bおよび102cと従来の陸線通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク106は、コアネットワーク106とPSTN108との間のインタフェースとしての役割を担うIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含んでもよく、または当該ゲートウェイと通信してもよい。加えて、コアネットワーク106は、WTRU102a、102bおよび102cにネットワーク112へのアクセスを提供してもよく、ネットワーク112は、他のサービスプロバイダにより所有および/または運営される他の有線または無線ネットワークを含んでもよい。
図48Eは、一実施形態に従ったRAN104およびコアネットワーク106のシステム図である。RAN104は、IEEE802.16無線技術を使用してエアインタフェース116上でWTRU102a、102bおよび102cと通信するアクセスサービスネットワーク(ASN)であってもよい。下記でさらに述べるように、WTRU102a、102b、102cおよびRAN104、ならびにコアネットワーク106の異なる機能エンティティ間の通信リンクは、基準点として定義されてもよい。
図48Eに示すように、RAN104は、基地局140a、140bおよび140c、ならびにASNゲートウェイ142を含んでもよいが、RAN104は、実施形態との整合性を保ちながら任意の数の基地局およびASNゲートウェイを含んでもよいことが理解されよう。基地局140a、140bおよび140cはそれぞれRAN104における特定のセル(図示せず)に関連付けられてもよく、ならびにそれぞれエアインタフェース116上でWTRU102a、102bおよび102cと通信するための1つまたは複数の送受信機を含んでもよい。一実施形態では、基地局140a、140bおよび140cは、MIMO技術を実装してもよい。したがって、例えば基地局140aは、複数のアンテナを使用して、WTRU102aに無線信号を送信し、およびWTRU102aから無線信号を受信してもよい。基地局140a、140bおよび140cはまた、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質(QoS)ポリシー施行などのモビリティ管理機能を提供してもよい。ASNゲートウェイ142は、トラフィック集約点としての役割を果たしてもよく、ならびにページング、加入者プロファイルのキャッシュ、およびコアネットワーク106へのルーティングなどを担ってもよい。
WTRU102a、102bおよび102cとRAN104との間のエアインタフェース116は、IEEE802.16仕様を実装するR1基準点として定義されてもよい。加えて、WTRU102a、102bおよび102cの各々は、コアネットワーク106との論理インタフェース(図示せず)を確立してもよい。WTRU102a、102bおよび102cとコアネットワーク106との間の論理インタフェースはR2基準点として定義されてもよく、認証、権限付与、IPホスティング構成管理、および/またはモビリティ管理に使用されてもよい。
基地局140a、140bおよび140cの各々の間の通信リンクは、基地局間のWTRUのハンドオーバーおよびデータの転送を容易にするプロトコルを含む、R8基準点として定義されてもよい。基地局140a、140bおよび140cとASNゲートウェイ215との間の通信リンクは、R6基準点として定義されてもよい。R6基準点は、WTRU102a、102bおよび102cの各々に関連付けられたモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含んでもよい。
図48Eに示すように、RAN104は、コアネットワーク106に接続されてもよい。RAN104とコアネットワーク106との間の通信リンクは、例えばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含む、R3基準点として定義されてもよい。コアネットワーク106は、モバイルIPホームエージェント(MIP−HA)144、認証・認可・課金管理(AAA)サーバ146、およびゲートウェイ148を含んでもよい。上述した要素の各々は、コアネットワーク106の一部として記述されるが、これらの要素のいずれか1つはコアネットワークオペレータ以外のエンティティにより所有および/または運営されてもよいことが理解されよう。
MIP−HAは、IPアドレスの管理を担ってもよく、ならびにWTRU102a、102bおよび102cが異なるASN間および/または異なるコアネットワーク間をローミングすることを可能にさせてもよい。MIP−HA144は、WTRU102a、102bおよび102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102bおよび102cと、IP使用可能デバイスとの間の通信を容易にしてもよい。AAAサーバ146は、ユーザ認証およびユーザサービスをサポートすることを担ってもよい。ゲートウェイ148は、他のネットワークとの相互動作を容易にしてもよい。例えば、ゲートウェイ148は、WTRU102a、102bおよび102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102bおよび102cと、従来の陸線通信デバイスとの間の通信を容易にしてもよい。加えて、ゲートウェイ148は、WTRU102a、102bおよび102cに、他のサービスプロバイダによって所有および/または運営される他の有線または無線ネットワークを含むことができるネットワーク112へのアクセスを提供してもよい。
図48Eには示さないが、RAN104は他のASNに接続されてもよく、およびコアネットワーク106は他のコアネットワークに接続されてもよいことが理解されよう。RAN104と他のASNとの間の通信リンクは、R4基準点として定義されてもよく、R4基準点は、RAN104と他のASNとの間でのWTRU102a、102bおよび102cのモビリティを調整するプロトコルを含んでもよい。コアネットワーク106と他のコアネットワークとの間の通信リンクは、R5基準点として定義されてもよく、R5基準点は、ホームコアネットワークと移動先(visited)コアネットワークとの間の相互動作を容易にするためのプロトコルを含んでもよい。
上記では特定の組み合わせで特徴および要素について説明したが、当業者の1人は、各特徴または要素は単独で、または他の特徴および要素との任意の組み合わせで使用することができることを認識されよう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施されてもよい。コンピュータ可読媒体の例は、電子信号(有線または無線接続上で伝送される)、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、これらに限定されないが、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにCD−ROMディスクおよびデジタル多用途ディスク(DVD)などの光学媒体を含む。ソフトウェアと関連付けられたプロセッサが使用されて、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータで使用するための無線周波送受信機を実装してもよい。
結論
ETSI TS 102 690 V0.12.3(2011−06)ドラフトおよび同標準の先行版(総称して「M2M通信に対するETSI標準ドラフト」)は、M2M通信のためのETSI標準ドラフトのコンテキスト内のかかる用語の意味を定義する、所定の定義を有するいくつかの用語を含む。本明細書には、ETSI TS 102 690 V0.12.3(2011−06)ドラフトおよび同標準の先行版により指定、開示、および/または参照される用語およびそれに関連する定義が、参照により組み込まれる。
実施形態
一実施形態では、方法は、M2M環境においてM2Mエンティティを管理するための1つまたは複数の管理レイヤを実装することを含んでもよい。方法はまた、複数の管理レイヤを使用して、M2Mエリアネットワークを管理することも含んでもよく、M2Mエリアネットワークは1つまたは複数のM2Mエンドデバイスを含んでもよい。M2Mエンドデバイスは、例えばM2Mゲートウェイおよび/またはM2Mデバイスを含んでもよい。管理レイヤは、アプリケーション管理レイヤ、サービス管理レイヤ、ネットワーク管理レイヤ、およびデバイス管理レイヤのいずれかを含んでもよい。管理レイヤは、M2Mエンティティの構成管理、障害管理、および性能管理のいずれかを提供してもよい。
一実施形態では、方法は、リモートエンティティ管理(「REM」)のためのサービス能力(「SC」)と、複数の管理レイヤのうちの1つに従って第2のM2MエンティティのREMを実行するための下位リソース構造を有するリソース構造とによって、第1のM2Mエンティティを構成することを含んでもよい。方法はさらに、下位リソース構造のリソースおよび属性のいずれかを操作することにより、第2のM2MエンティティのREMを実行することを含んでもよい。
上記実施形態における方法であり、第1のM2MエンティティはM2Mサーバであってもよく、第2のM2Mエンティティは、M2Mアプリケーション、M2Mサービス能力、M2Mエリアネットワーク、M2Mゲートウェイ、またはM2Mデバイスであってもよい。
上記実施形態の少なくとも1つにおける方法であり、複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤのうちの少なくとも2つを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、アプリケーション管理レイヤに従ったM2Mアプリケーションのリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態における方法であり、アプリケーション管理レイヤは、アプリケーションのライフサイクル管理を実行するための1つまたは複数の機能を含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、サービス管理レイヤに従ったM2Mサービス能力のリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態における方法であり、サービス管理は、ソフトウェア管理および/またはファームウェア管理を実行するための機能を備える。
上記実施形態の少なくとも1つにおける方法であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、ネットワーク管理レイヤに従ったM2Mエリアネットワークのリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、デバイス管理レイヤに従ったM2Mデバイスのリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、複数の管理レイヤの各々は、第2のM2Mエンティティの構成管理、障害管理、および性能管理のいずれかを実行するための1つまたは複数の機能を定義してもよい。
上記実施形態の少なくとも1つにおける方法は、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを、第1のM2Mエンティティにおいて受信することをさらに含んでもよく、第2のM2MエンティティのREMは、前記コマンドに応答して実行されてもよい。
上記実施形態における方法であり、前記コマンドはRESTfulメソッドを備える。
上記実施形態の少なくとも1つにおける方法は、下位リソース構造のリソースおよび属性のいずれかを操作する第1のコマンドを、第1のM2Mエンティティにおいて受信することをさらに含んでもよい。
上記実施形態における方法であり、第2のM2MエンティティのREMを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作する第2のコマンドを第2のM2Mエンティティに送信することと、受信された第2のコマンドに応答して第2のM2MエンティティのREMを実行することとを含んでもよい。
上記実施形態における方法であり、第1のコマンドおよび第2のコマンドの両方は、RESTfulメソッドを含んでもよい。
上実施形態の少なくとも1つにおける方法であり、第1のコマンドはRESTfulメソッドを含んでもよく、および第2のコマンドは非RESTfulメソッドを備える。
上記実施形態の少なくとも1つにおける方法であり、第2のM2MエンティティのREMを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを、第2のM2Mエンティティに送信することと、受信されたコマンドに応答して第2のM2MエンティティのREMを実行することとを含んでもよい。
上記実施形態における方法であり、コマンドは非RESTfulメソッドまたはRESTfulメソッドのいずれかであってもよい。
上記実施形態の少なくとも1つにおける方法であり、第2のM2Mエンティティは、下位リソース構造の複製を含んでもよく、および第2のM2MエンティティのREMを実行することは、下位リソース構造のリソースおよび属性のいずれかを操作した後に、下位リソース構造の複製を操作して下位リソース構造を複製することを備える。
一実施形態では、装置は、REMのためのSCと、複数の管理レイヤのうちの1つに従って第2のM2MエンティティのREMを実行するための下位リソース構造を有するリソース構造とによって構成された第1のM2Mエンティティを含んでもよい。装置はさらに、下位リソース構造のリソースおよび属性のいずれかを操作することにより、第2のM2MエンティティのREMを実行するように適合されたプロセッサを含んでもよい。
上記実施形態における装置であり、第1のM2MエンティティはM2Mサーバを含んでもよく、および第2のM2Mエンティティは、M2Mアプリケーション、M2Mサービス能力、M2Mエリアネットワーク、M2Mゲートウェイ、またはM2Mデバイスを含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、複数の管理レイヤは、デバイス管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、およびアプリケーション管理レイヤのうちの2つ以上を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、第2のM2MエンティティのREMのための下位リソース構造は、アプリケーション管理レイヤに従ったM2MアプリケーションのREMのためのリソース構造を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、アプリケーション管理レイヤは、アプリケーションのライフサイクル管理を実行するための機能を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、サービス管理レイヤに従ったM2Mサービス能力のリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態における装置であり、サービス管理は、ソフトウェア管理および/またはファームウェア管理を実行するための機能を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、ネットワーク管理レイヤに従ったM2Mエリアネットワークのリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、第2のM2Mエンティティのリモートエンティティ管理のための下位リソース構造は、デバイス管理レイヤに従ったM2Mデバイスのリモートエンティティ管理のためのリソース構造を含んでもよい。
上記実施形態の少なくとも1つにおける装置であり、複数の管理レイヤの各々は、第2のM2Mエンティティの構成管理、障害管理、および性能管理のいずれかを実行するための機能を定義してもよい。
上記実施形態の少なくとも1つにおける装置であり、第1のM2Mエンティティは、下位リソース構造のリソースおよび属性のいずれかを操作するコマンドを受信するSCを含んでもよく、第2のM2MエンティティのREMは、コマンドに応答して実行されてもよい。
上記実施形態の少なくとも1つにおける装置であり、コマンドはRESTfulメソッドであってもよい。
上記実施形態の少なくとも1つにおける装置であり、第1のM2Mエンティティは、(i)下部リソース構造のリソースおよび属性のいずれかを操作する第1のコマンドを受信するSC、および(ii)第2のM2Mエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作する第2のコマンドを、第2のM2Mエンティティと通信するSC、を含んでもよい。
上記実施形態における装置であり、プロセッサは、第2のコマンドに応答して、第2のM2Mエンティティで保持された下部リソース構造のリソースの複製および属性の複製のいずれかを操作させる第2のコマンドを、第2のM2Mエンティティに送信するように適合されてもよい。
上記実施形態の少なくとも1つにおける装置であり、第1のコマンドおよび第2のコマンドの両方はRESTfulメソッドであってもよく、または代わりに、第1のコマンドはRESTfulメソッドであってもよく、ならびに第2のコマンドは非RESTfulメソッドであってもよい。
上記実施形態の少なくとも1つにおける装置であり、第1のM2Mエンティティは、(i)第2のM2Mエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作するコマンドを、第2のM2Mエンティティと通信するSCを含んでもよい。
前記実施形態における装置であり、プロセッサは、第2のコマンドに応答して、第2のM2Mエンティティにおいて保持された下位リソース構造のリソースの複製および属性の複製のいずれかを操作させるコマンドを、第2のM2Mエンティティに送信するように適合されてもよい。
上記実施形態における装置であり、コマンドは非RESTfulメソッドであってもよく、または代わりにRESTfulメソッドであってもよい。
一実施形態では、システムは、REMのためのサービス能力と、複数の管理レイヤの1つに従って第2のM2MエンティティのREMを実行するための下位リソース構造を有するリソース構造とによって構成された第1のM2Mエンティティを有するサーバを含んでもよい。システムはまた、下位リソース構造のリソースおよび属性のいずれかを操作することによって、第2のM2MエンティティのREMを実行するように適合されたプロセッサを含んでもよい。システムはさらに、下位リソース構造の複製により構成された第2のM2Mエンティティと、サーバによる操作の後に下位リソース構造の複製を操作して下位リソース構造を複製するように構成されたプロセッサとを有するデバイスを含んでもよい。
一実施形態では、有形のコンピュータ可読記憶媒体は、(i)REMのためのSCと、複数の管理レイヤのうちの1つに従って第2のM2MエンティティのREMを実行するための下位リソース構造を有するリソース構造とによって、第1のM2Mエンティティを構成し、ならびに(ii)下位リソース構造のリソースおよび属性のいずれかを操作することにより、第2のM2MエンティティのREMを実行するための実行可能命令を記憶してもよい。実行可能命令は、メモリにロード可能であってもよく、およびコンピューティングデバイスにより実行可能であってもよい。
一実施形態では、有形のコンピュータ可読記憶媒体は、(i)REMのためのSCと、複数の管理レイヤのうちの1つに従って第2のM2MエンティティのREMを実行するための下位リソース構造を有するリソース構造とによって、第1のM2Mエンティティを構成し、(ii)下位リソース構造のリソースおよび属性のいずれかを操作することにより、第2のM2MエンティティのREMを実行し、ならびに(iii)第2のM2Mエンティティによって保持された下位リソース構造の複製を操作して、それにより下位リソース構造のリソースおよび属性のいずれかの操作後に、下部リソース構造を複製するための実行可能命令を記憶してもよい。
一実施形態では、方法は、M2M環境において管理機能を実行するためのクライアント/サーバベースのリモートエンティティ管理(xREM)のモデルを実装することを含んでもよい。方法はまた、当該モデルをM2M環境におけるM2Mデバイスに適用することを含んでもよい。
一実施形態では、方法は、トンネルベースの技術を使用して、複数の管理プロトコルを使用してM2M環境におけるxREMを実装することと、当該モデルをM2M環境におけるM2Mデバイスに適用することを含んでもよい。
一実施形態では、方法は、属性コンポーネントを備えるリソースコマンドを提供することと、リソースコマンドをM2Mエンドデバイスと通信することとを含んでもよい。
上記実施形態における方法であり、リソースコマンドは非RESTfulコマンドであってもよい。
一実施形態では、方法は、属性コンポーネントおよび考えられるいくつかのサブパラメータを有するリソースコマンド構造を提供することを含んでもよい。方法はまた、リソースコマンドをM2Mエンドデバイスに通信することを含んでもよい。従来の非RESTful管理コマンドは、RESTfulメソッドを使用してM2Mエンドデバイス上で容易に動作される場合がある。
一実施形態では、方法は、accessHistoriesリソース構造をM2MデバイスまたはM2Mゲートウェイにおいて記憶し、M2MデバイスまたはM2Mゲートウェイにおける動作を検出し、およびaccessHistoriesリソース構造を操作して、その動作に関連付けられた少なくとも1つの詳細を記憶することを含んでもよい。
一実施形態では、方法は、マシンツーマシン(M2M)デバイスまたはゲートウェイ上で権限を委譲する要求を受信し、およびM2Mデバイスまたはゲートウェイ上で権限を付与することを含んでもよい。
一実施形態では、方法はM2Mエンドデバイスにおいて実施されてもよい。方法は、M2Mエンドデバイスを管理するための1つまたは複数の属性コンポーネントを有するリソースコマンドを受信することを含んでもよい。
上記実施形態における方法はまた、リソースコマンドに基づいて1つまたは複数の管理機能を適用することを含んでもよい。
一実施形態では、方法は、1つまたは複数の属性コンポーネントを含むリソースコマンドを提供し、およびリソースコマンドをM2Mエンドデバイスに通信することを含んでもよい。
一実施形態では、第1のシステムにおいてxREMを実行する方法は、例えば、ETSI TS 102 690ドラフトなどのM2M通信用のプロトコル(「M2M通信プロトコル」)に従って通信するように適合された第1、第2および第3のデバイスを含んでもよい。M2M通信プロトコルは、論理レイヤ(「管理レイヤ」)の各々に存在するエンティティを管理するための論理レイヤのスタックまたは集合を定義してもよい。これらの管理レイヤは、例えば、M2Mアプリケーション管理レイヤ、M2Mサービス能力レイヤ、M2Mネットワーク管理レイヤ、およびM2Mデバイス管理レイヤを含んでもよい。第1のデバイスは、管理レイヤのうち第1の論理レイヤ(「第1の管理レイヤ」)に存在するエンティティを定義してもよい。エンティティは、例えばM2Mアプリケーション、M2Mサービス能力、M2Mエリアネットワーク、M2Mゲートウェイ、またはM2Mデバイスであってもよい。第1のデバイスは、第1の管理レイヤに従ってエンティティを管理するためのリソース(「第1の管理レイヤリソース」)を定義する第1のデータ構造を含んでもよい。第2のデバイスも、第1の管理レイヤリソースを定義する第2のデータ構造を含んでもよい。そして第2のデバイスは、第1および第3のデバイスと通信可能に結合してもよい。
方法は、第2のデバイスから第3のデバイスに、第1の管理レイヤリソースを識別する識別子を提供することを含んでもよい。方法はまた、識別子および第1の管理レイヤリソースに適用する情報を第2のデバイスにおいて第3のデバイスから受信し、および情報を第1の管理レイヤリソースに適用することを含んでもよい。
1つまたは複数の例では、情報を第1の管理レイヤリソースに適用することは、第2のデータ構造を操作することを含んでもよい。あるいは、情報を第1の管理レイヤリソースに適用することは、第2のデバイスから第1のデバイスに情報を送信して、第1のデバイスに第1のデータ構造を操作させることを含んでもよい。
識別子は、例えばユニフォームリソース識別子(uniform resource identifier)、リンク、およびアドレスのいずれかを含んでもよく、ならbに/またはそれらのいずれかであってもよい。第1の管理レイヤリソースは、管理オブジェクトを含んでもよく、および/または定義してもよい。さらに、第1、第2および第3のデバイスの各々は、M2M通信プロトコルに従って通信するモジュールを含んでもよい。第3のデバイスはさらに、第1の管理レイヤリソースに適用する情報を提供するように適合されたアプリケーション、例えばM2Mアプリケーションを含んでもよく、およびアプリケーションの実行は、M2M通信プロトコルに従って情報を通信することを含む。第1のデバイスはまた、アプリケーションを含んでもよく、およびそのようなアプリケーションの実行は、M2M通信プロトコルに従って情報を通信することを含む。
1つまたは複数の実施形態において、第1のデバイスは電気器具であってもよく、第3のデバイスは、無線送信/受信ユニット(「WTRU」)であってもよく、および第2のデバイスはサーバを含んでもよい。
別の例として、xREMのための装置が開示される。装置は、M2M通信プロトコルに従って通信するように適合された第1のデバイスを含む。上記のように、M2M通信プロトコルは、管理レイヤのスタックまたは集合を定義する。第1のデバイスは、第1のデータ構造を含んでもよい。第1のデータ構造は、第1の管理レイヤに従って、第1の管理レイヤに存在する第2のデバイスのエンティティを管理するための第1の管理レイヤリソースを定義する。第1のデバイスはまた、第2のデバイスおよび第3のデバイスと通信可能に結合してもよい。第1のデバイスはさらに、実行可能命令を記憶するように適合されたメモリを含んでもよく、実行可能命令は、第1の管理レイヤリソースを識別する識別子を第3のデバイスに提供し、識別子および第1の管理レイヤリソースに適用する情報を第3のデバイスから受信し、ならびに情報を第1の管理レイヤリソースに適用する、ように適合される。第1のデバイスはまた、メモリから実行可能命令を取得し、および実行可能命令を実行するように適合されたプロセッサも含んでもよい。
識別子は、ユニフォームリソース識別子、リンク、およびアドレスのいずれかを含んでもよく、かつ/またはそれらのいずれかであってもよい。第1の管理レイヤリソースは管理オブジェクトを含んでもよい。
第1のデバイスは、M2M通信プロトコルに従って通信するモジュールを含んでもよい。第1の管理レイヤリソースに適用する情報は、第3のデバイスのアプリケーションから受信されてもよい。第1のデバイスは、サーバを含んでもよく、第2のデバイスは電気器具であってもよく、および第3のデバイスはWTRUであってもよい。
第2のシステムにおいてxREMを実行するための方法の別の例が開示される。第2のシステムは、M2M通信プロトコルに従って通信するように適合された第1および第2のデバイスを含んでもよい。M2M通信プロトコルは管理レイヤを定義する。第1のデバイスは、第1の管理レイヤに存在するエンティティを定義し、および第1の管理レイヤリソースを定義する第1のデータ構造を備える。第2のデバイスも、第1の管理レイヤリソースを定義する第2のデータ構造を含む。第1のデバイスは第2のデバイスに通信可能に結合してもよい。
方法は、第1のデバイスが第2のデバイスとネゴシエーションして、第1の管理レイヤに従ってエンティティを管理するための管理プロトコルのタイプを定義することを含んでもよい。第2のデバイスとのネゴシエーションは、例えば、第2のデバイスにおけるサービス能力レイヤ(「SCL」)の登録を要求する第1のメッセージを、第1のデバイスから第2のデバイスに送信することを含んでもよく、第1のメッセージは、管理プロトコルのタイプを定義する属性と、属性に割り当てられた第1の値とを含む。第2のデバイスとのネゴシエーションはまた、第1のメッセージに応答して送信された第2のメッセージを、第1のデバイスにおいて第2のデバイスから受信することを含んでもよい。第2のメッセージは、管理プロトコルのタイプを定義する属性に割り当てられた第2の値を含んでもよい。
1つまたは複数の実施形態において、第2のデバイスとのネゴシエーションは、SCLの登録への更新を要求する第3のメッセージを、第1のデバイスにおいて第2のデバイスから受信することをさらに含んでもよく、第3のメッセージは、管理プロトコルのタイプを定義する属性に割り当てられた第2の値を含む。
代替として、第2のデバイスとのネゴシエーションは、第2のデバイスにおけるSCLにオブジェクトを作成することを要求する第1のメッセージを、第1のデバイスから第2のデバイスに送信することを含んでもよい。このことを容易にするために、第1のメッセージは、管理プロトコルのタイプを定義する属性およびその属性に割り当てられた第1の値を含んでもよい。第2のデバイスとのネゴシエーションはさらに、第1のメッセージに応答して送信された第2のメッセージを、第1のデバイスにおいて第2のデバイスから受信することを含んでもよい。第2のメッセージは、属性に割り当てられた第2の値を含んでもよい。
別の代替として、第2のデバイスとのネゴシエーションは、第2のデバイスにおけるSCLのオブジェクトを更新することを要求する第1のメッセージを、第1のデバイスから第2のデバイスに送信することを含んでもよい。第1のメッセージは、管理プロトコルのタイプを定義する属性を識別するための識別子および属性に割り当てられた第1の値を含んでもよい。第2のデバイスとのネゴシエーションはまた、第1のメッセージに応答して送信された第2のメッセージを、第1のデバイスにおいて第2のデバイスから受信することを含んでもよい。第2のメッセージは、属性に割り当てられた第2の値を含んでもよい。
さらなる別の代替では、第2のデバイスとのネゴシエーションは、第2のデバイスにおいてSCLでオブジェクトを更新することを要求する第1のメッセージを、第1のデバイスにおいて第2のデバイスから受信することを含んでもよい。更新を容易にするために、第1のメッセージは、管理プロトコルのタイプを定義する属性を識別する識別子および当該属性に割り当てられた第1の値を含んでもよい。第2のデバイスとのネゴシエーションは、第1のメッセージに応答して第1のデバイスから第2のデバイスに第2のメッセージを送信することを含んでもよい。第2のメッセージは、属性に割り当てられた第2の値を含んでもよい。
別の代替では、第2のデバイスとのネゴシエーションは、第2のデバイスを検出するための第1のメッセージを、第1のデバイスから第3のデバイスに送信することを含んでもよい。第1のメッセージは、管理プロトコルのタイプを定義する属性を識別するための識別子および当該属性に割り当てられた第1の値を含んでもよい。第2のデバイスとのネゴシエーションは、第1のメッセージに応答して送信された第2のメッセージを、第1のデバイスにおいて第3のデバイスから受信することを含んでもよい。この第2のメッセージは、プロトコルのタイプを定義する属性に割り当てられた第2の値を含んでもよい。属性に割り当てられた第2の値は、第2のデバイスにおけるSCLから取得されてもよい。第2のデバイスとのネゴシエーションは、第1の値と第2の値が等しい場合に、第1のデバイスのSCLの登録のために第2のデバイスを選択することをさらに含んでもよい。
管理プロトコルのタイプは、シンプルネットワーク管理プロトコル(「SNMP」)、ブロードバンドフォーラム(「BBF」)TR−069 CPE WAN管理プロトコル、およびオープンモバイルアライアンス(OMA)デバイス管理(DM)プロトコルのいずれかであってもよい。
第2のシステムにおいてxREMを実行するための方法のさらなる例が開示される。方法は、第1の論理レイヤに従ってエンティティを管理するための管理プロトコルのタイプを、第2のデバイスに通知することを含んでもよい。
xREMを実行するための方法の別の例が開示される。方法は、第3のデバイスのxREMについての権限を第1のデバイスに委譲する要求を、第1のデバイスが第2のデバイスから受信することと、当該要求に応答して、第2のデバイスが権限を第1のデバイスに渡すことを含んでもよい。権限を取得した後に、第1のデバイスは第3のデバイスに対する権限を実行してもよい。
1つまたは複数の実施形態において、方法は、RESTfulメソッドを実行する要求を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第1のエンティティは、コマンドを定義するリソース(「コマンドリソース」)のデータ構造を含んでもよい。要求は、コマンドリソースを識別するための識別子と、コマンドを実行するための情報とを含んでもよい。方法はまた、識別子およびコマンドを実行するための情報に応じてコマンドを実行することを含んでもよい。識別子は、ユニフォームリソース識別子、リンク、およびアドレスのいずれかであってもよい。
1つまたは複数の実施形態において、第1のエンティティは、第1および第2のコマンドリソースのそれぞれ第1および第2のデータ構造を含んでもよく、ならびに識別子は、第2のリソースに対するポインタを含んでもよく、および/またはポインタであってもよい。
1つまたは複数の実施形態において、方法は、RESTfulメソッドを実行する要求を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第1のエンティティは、コマンドを定義するコマンドリソースのデータ構造を含んでもよい。要求は、コマンドリソースを識別するための識別子と、コマンドを実行するための情報とを含んでもよい。方法はまた、要求に応答してリソースの第1のインスタンスを生成し、リソースの第1のインスタンスを識別する識別子を更新し、ならびに識別子およびコマンドを実行するための情報に応じてコマンドを実行することを含んでもよい。
1つまたは複数の実施形態において、方法は、RESTfulメソッドを実行するための第1の要求を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第1のエンティティは、コマンドリソースのデータ構造を含んでもよく、第1の要求は、コマンドリソースを識別するための第1の識別子、およびコマンドを実行するための第1の情報を含んでもよい。方法はまた、第1の要求に応答して、コマンドリソースの第1のインスタンスを生成し、コマンドリソースの第1のインスタンスを識別する第1の識別子を更新し、ならびにRESTfulメソッドを実行するための第2の要求を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第2の要求は、コマンドリソースを識別するための第2の識別子と、コマンドを実行するための第2の情報とを含んでもよい。方法はさらに、第2の要求に応答して、コマンドリソースの第2のインスタンスを生成し、コマンドリソースの第2のインスタンスを識別する第2の識別子を更新し、第1の識別子およびコマンドを実行するための第1の情報に応じてコマンドを実行し、ならびに第2の識別子およびコマンドを実行するための第2の情報に応じてコマンドを実行することを含んでもよい。
一実施形態では、マシンツーマシン通信についてのプロトコルに従ってxREMを実行するための方法が開示される。方法は、RESTfulメソッドを実行するための要求(「RESTfulメソッド要求」)を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第1のエンティティは、そのRESTfulメソッドにより変更することが可能なデータ構造を含んでもよい。このデータ構造は、例えば、本明細書で「sclbase」等と称される任意のデータ構造を含むサービス能力レイヤ(「SCL」)を表すデータ構造であってもよい。RESTfulメソッド要求は、第1のエンティティにより実行可能なコマンド(以降「リソースコマンド」)に関連付けられたリソースを識別してもよい。方法はまた、RESTfulメソッドを実行して、リソースコマンドに従ってデータ構造への変更を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、RESTfulメソッドは、RESTfulメソッドCREATE、RESTfulメソッドRETRIEVE、RESTfulメソッドUPDATE、および/またはRESTfulメソッドDELETEであってもよい。RESTfulメソッドが例えばRESTfulメソッドCREATEである実施形態では、RESTfulメソッドを実行することは、リソースコマンドを表す下位データ構造(以降「コマンドリソース構造」)をデータ構造においてインスタンス化することを含んでもよい。
RESTfulメソッドがRESTfulメソッドDELETEである実施形態では、RESTfulメソッドを実行することは、データ構造からコマンドリソース構造を削除することを含んでもよい。RESTfulメソッドがRESTfulメソッドRETRIEVEである実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造の一部もしくはすべての複製、および/またはコマンドリソース構造の状態(「コマンドリソース状態」)を第2のエンティティに送信することを含んでもよい。
RESTfulメソッドがRESTfulメソッドUPDATEである実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造を変更して、コマンドの状態(「コマンド状態」)における変更を呼び出すことを含んでもよい。1つまたは複数の実施形態において、下位データ構造を変更することは、コマンドリソース構造を変更してコマンドの実行(「コマンド実行」)を呼び出すことを含んでもよい。コマンド実行は、例えばコマンドリソース構造のそのような変更を検出することに応答して第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための下位リソース(「下位リソース」)(「コマンド実行下位リソース」)を定義してもよい。このコマンド実行下位リソースは、例えば、本明細書の以下でexecEnable等と称される下位リソースの1つまたは複数の実施形態であってもよい。コマンドリソース構造の1つまたは複数の要素(「コマンドリソース構造要素」)は、コマンド実行下位リソースを表してもよい。
1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行下位リソースを変更することは、コマンド実行下位リソースを表すコマンドリソース構造要素をその情報によって変更することにより、コマンド実行を呼び出すことを含んでもよい。
コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は、割り当てられ、およびコマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は「0」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「0」によって変更することでコマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための属性を定義してもよい。それらの実施形態では、コマンドリソース構造要素は、その属性を表してもよく、およびそのような要素は、識別子(「属性識別子」)によって識別可能であってもよい。このコマンド実行属性識別子は、例えば、本明細書の以下でexecEnable等と称される属性の1つまたは複数の実施形態であってもよい。
RESTfulメソッド要求は、属性識別子を含んでもよい。さらに、属性を表すコマンドリソース構造要素の選択は、コマンド実行を呼び出してもよい。そして、コマンドリソース構造を変更してコマンドの実行を呼び出すことは、属性識別子を使用して、属性を表すコマンドリソース構造要素を選択し、それによりコマンドの実行を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更するステップは、コマンドリソース構造を変更してコマンド実行の中断を呼び出すステップを含むことができる。コマンド実行の中断は、例えば、コマンドリソース構造のそのような変更を検出するのに応答して第1のエンティティによって呼び出すことができる。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行の中断を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でexecEnable等と称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更してコマンド実行の中断を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更してコマンド実行の中断を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、中断を呼び出すことを含んでもよい。コマンド実行リソース構造を変更するための情報は、割り当られ、およびコマンド実行の中断を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して中断を呼び出すための情報は「1」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「1」により変更することによって、コマンド実行の中断を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行の中断を呼び出すための属性(「実行中断属性」)を定義してもよい。コマンド-リソース構造要素の1つまたは複数は、実行中断属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この実行中断属性は、例えば、本明細書の以下でexecPause等と称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、実行中断属性識別子を含んでもよい。さらに、実行中断属性を表すコマンドリソース構造要素の選択は、コマンド実行の中断を呼び出してもよい。そして、コマンドリソース構造を変更してコマンド実行の中断を呼び出すことは、実行中断属性識別子を使用して、実行中断属性を表すコマンドリソース構造要素を選択し、それによりコマンド実行の中断を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、中断中のコマンドの実行を再開させること(「再開コマンド実行」)を含んでもよい。再開コマンド実行は、例えば、再開コマンド実行をさせるためのコマンドリソース構造への変更を検出することに応答して第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でexecEnable等と称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して再開コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、再開コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および再開コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報は「2」であってもよく、したがって再開コマンド実行下位リソースを表すコマンドリソース構造要素を「2」により変更することによって、再開コマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための属性(「実行再開属性」)を定義してもよい。コマンドリソース構造要素の1つまたは複数が実行再開属性を表してもよく、およびそのような要素は対応する属性識別子によって識別可能であってもよい。この実行再開属性は、例えば、本明細書の以下でexecResume等と称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、実行再開属性識別子を含んでもよい。さらに、実行再開属性を表すコマンドリソース構造要素の選択は、再開コマンド実行を呼び出してもよい。コマンドリソース構造を変更して再開コマンド実行を呼び出すことは、実行再開属性識別子を使用して、実行再開属性を表すコマンドリソース構造要素を選択し、それにより再開コマンド実行を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンド実行の取消し(「取消コマンド実行」)を呼び出すことを含んでもよい。取消コマンド実行は、例えば、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出するのに応答して第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でexecEnableなどと称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して取消コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して取消コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および取消コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して、取消コマンド実行を呼び出すための情報は「3」であってもよく、したがって、取消コマンド実行下位リソースを表すコマンドリソース構造要素を「3」により変更することによって、取消コマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための属性(「取消実行属性」)を定義してもよい。コマンドリソース構造要素の1つまたは複数は、取消実行属性を表してもよく、およびそのような要素は、対応する属性識別子によって識別可能であってもよい。この取消実行属性は、例えば、本明細書の以下でexecDisableなどと称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、取消実行属性識別子を含んでもよい。さらに、取消実行属性を表すコマンドリソース構造要素の選択は、取消コマンド実行を呼び出してもよい。コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。
RESTfulメソッドがRESTfulメソッドDELETEである1つまたは複数の実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造を変更してコマンド実行の状態の変化を呼び出し、およびコマンドリソース構造をデータ構造から削除することを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、取消コマンド実行を呼び出すことを含んでもよい。取消コマンド実行は、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。あるいは、取消コマンド実行は、RESTfulメソッドDELETEに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、上記のように、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。1つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。
マシンツーマシン通信のプロトコルに従ってリモートエンティティ管理を実行するための代替の方法が開示される。この方法は、第1のエンティティにおいて第2のエンティティからRESTfulメソッド要求を受信することを含んでもよい。第1のエンティティは、そのRESTfulメソッドにより変更可能なデータ構造を含んでもよい。データ構造は、第1のリソースを表す下位データ構造を含んでもよく、第1のリソースは、コマンドリソース状態を呼び出す動作を定義する。下位データ構造は識別子により識別可能であってもよく、RESTfulメソッド要求は識別子を含んでもよく、およびリソースコマンドを識別してもよい。方法は、RESTfulメソッドを実行して、識別子およびリソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース状態における変化を呼び出す動作は、コマンド実行を呼び出す動作、コマンド実行への中断を呼び出す動作、再開コマンド実行を呼び出す動作、または取消コマンド実行を呼び出す動作を含んでもよい。
一実施形態では、マシンツーマシン通信のプロトコルに従ってxREMを実行するための方法は、RESTfulメソッドを実行する要求(「RESTfulメソッド要求」)を、第1のエンティティにおいて第2のエンティティから受信することを含んでもよい。第1のエンティティは、RESTfulメソッドにより変更可能なデータ構造を含んでもよい。このデータ構造は、例えば、本明細書で「sclbase」などと称されるデータ構造を含むサービス能力レイヤ(「SCL」)を表すデータ構造であってもよい。RESTfulメソッド要求は、第3のエンティティにより実行可能なコマンド(以降「リソースコマンド」)に関連付けられたリソースを識別してもよい。方法はまた、RESTfulメソッドを実行して、リソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、RESTfulメソッドは、RESTfulメソッドCREATE、RESTfulメソッドRETRIEVE、RESTfulメソッドUPDATE、および/またはRESTfulメソッドDELETEであってもよい。RESTfulメソッドが、例えば、RESTfulメソッドCREATEである実施形態では、RESTfulメソッドを実行することは、リソースコマンドを表す下位データ構造(以降「コマンドリソース構造」)をデータ構造においてインスタンス化することを含んでもよい。
RESTfulメソッドがRESTfulメソッドDELETEである実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造をデータ構造から削除することを含んでもよい。RESTfulメソッドがRESTfulメソッドRETRIEVEである実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造の一部もしくはすべての複製、および/またはコマンドリソース構造の状態(「コマンドリソース状態」)を第2のエンティティに送信することを含んでもよい。
RESTfulメソッドがRESTfulメソッドUPDATEである実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造を変更して、コマンドの状態(「コマンド状態」)における変化を呼び出すことを含んでもよい。1つまたは複数の実施形態において、下位データ構造を変更するステップは、コマンドリソース構造を変更してコマンドの実行(「コマンド実行」)を呼び出すことを含んでもよい。コマンド実行は、例えば、コマンドリソース構造へのそのような変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための下位リソース(「下位リソース」)(「コマンド実行下位リソース」)を定義してもよい。このコマンド実行下位リソースは、本明細書の以下でexecEnableなどと称される下位リソースの1つまたは複数の実施形態であってもよい。コマンドリソース構造の1つまたは複数の要素(「コマンドリソース構造要素」)は、コマンド実行下位リソースを表してもよい。
1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行下位リソースを変更することは、コマンド実行下位リソースを表すコマンドリソース構造要素をその情報により変更することによって、コマンド実行を呼び出すことを含んでもよい。
コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は、割り当てられ、およびコマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更してコマンド実行を呼び出すための情報は「0」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「0」により変更することでコマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行を呼び出すための属性を定義してもよい。これらの実施形態では、コマンドリソース構造要素は属性を表してもよく、およびそのような要素は識別子(「属性識別子」)により識別可能であってもよい。このコマンド実行属性識別子は、例えば、本明細書の以下でexecEnableなどと称される属性の1つまたは複数の実施形態であってもよい。
RESTfulメソッド要求は、属性識別子を含んでもよい。さらに、属性を表すコマンドリソース構造要素の選択は、コマンド実行を呼び出してもよい。そして、コマンドリソース構造を変更してコマンドの実行を呼び出すことは、属性識別子を使用して、属性を表すコマンドリソース構造要素を選択し、それによりコマンドの実行を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更してコマンド実行への中断を呼び出すことを含んでもよい。コマンド実行への中断は、例えば、コマンドリソース構造のそのような変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行への中断を呼び出す下位リソースを定義してもよい。この下位リソースは、本明細書の以下でexecEnableなどと称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して、コマンド実行への中断を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更してコマンド実行への中断を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、中断を呼び出すことを含んでもよい。コマンド実行下位リソースを変更するための情報は、割り当てられ、およびコマンド実行への中断を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して中断を呼び出すための情報は「1」であってもよく、したがって、コマンド実行下位リソースを表すコマンドリソース構造要素を「1」により変更することによって、コマンド実行への中断を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、コマンド実行への中断を呼び出すための属性(「中断実行属性」)を定義してもよい。コマンドリソース構造要素の1つまたは複数は、中断実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この中断実行属性は、本明細書の以下でexecPauseなどと称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、中断実行属性識別子を含んでもよい。さらに、中断実行属性を表すコマンドリソース構造要素の選択は、コマンド実行への中断を呼び出してもよい。そして、コマンドリソース構造を変更してコマンド実行への中断を呼び出すことは、中断実行属性識別子を使用して、中断実行属性を表すコマンドリソース構造要素を選択し、それによりコマンド実行への中断を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンドの中断された実行の実行を再開させることを含んでもよい(「再開コマンド実行」)。再開コマンド実行は、例えば、再開コマンド実行をさせるためのコマンドリソース構造の変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でexecEnableなどと称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報を含んでもよい。これらの実施形態では、コマンド実行リソース構造を変更して再開コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、再開コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および再開コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して再開コマンド実行を呼び出すための情報は「2」であってもよく、したがって再開コマンド実行の下位リソースを表すコマンドリソース構造要素を「2」により変更することによって、再開コマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、再開コマンド実行を呼び出すための属性(「再開実行属性」)を定義してもよい。コマンドリソース構造要素の1つまたは複数は、再開実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この再開実行属性は、例えば、本明細書の以下でexecResumeなどと称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、再開実行属性識別子を含んでもよい。さらに、再開実行属性を表すコマンドリソース構造要素の選択は、再開コマンド実行を呼び出してもよい。コマンドリソース構造を変更して再開コマンド実行を呼び出すことは、再開実行属性識別子を使用して、再開実行属性を表すコマンドリソース構造要素を選択し、それにより再開コマンド実行を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、コマンド実行の取消しを呼び出す(「取消コマンド実行」)ことを含んでもよい。取消コマンド実行は、例えば、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための下位リソースを定義してもよい。この下位リソースは、例えば、本明細書の以下でexecEnableなどと称される下位リソースの1つまたは複数の実施形態であってもよい。1つまたは複数の実施形態において、RESTfulメソッド要求は、コマンド実行下位リソースを変更して、取消コマンド実行を呼び出すための情報を含んでもよい。それらの実施形態では、コマンド実行リソース構造を変更して取消コマンド実行を呼び出すことは、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。この情報は、割り当てられ、および取消コマンド実行を呼び出すために解釈される数、整数、文字、コード等であってもよい。例として、コマンド実行下位リソースを変更して取消コマンド実行を呼び出すための情報は「3」であってもよく、したがって、取消コマンド実行下位リソースを表すコマンドリソース構造要素を「3」により変更することによって、取消コマンド実行を呼び出す。
1つまたは複数の実施形態において、リソースコマンドは、取消コマンド実行を呼び出すための属性(「取消実行属性」)を定義してもよい。コマンドリソース構造要素の1つまたは複数は、取消実行属性を表してもよく、およびそのような要素は、対応する属性識別子により識別可能であってもよい。この取消実行属性は、本明細書の以下でexecDisableなどと称される属性の1つまたは複数の実施形態であってもよい。RESTfulメソッド要求は、取消実行属性識別子を含んでもよい。さらに、取消実行属性を表すコマンドリソース構造要素の選択は、取消コマンド実行を呼び出してもよい。コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。
RESTfulメソッドがRESTfulメソッドDELETEである1つまたは複数の実施形態では、RESTfulメソッドを実行することは、コマンドリソース構造を変更してコマンド実行の状態における変化を呼び出し、およびコマンドリソース構造をデータ構造から削除することを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更することは、コマンドリソース構造を変更して、取消コマンド実行を呼び出すことを含んでもよい。取消コマンド実行は、取消コマンド実行を呼び出すためのコマンドリソース構造の変更を検出することに応答して、第1のエンティティによって呼び出されてもよい。あるいは、取消コマンド実行は、RESTfulメソッドDELETEに応答して、第1のエンティティによって呼び出されてもよい。
1つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、上記のように、コマンド実行下位リソースを表すコマンドリソース構造要素を変更して、取消コマンド実行を呼び出すことを含んでもよい。1つまたは複数の実施形態において、コマンドリソース構造を変更して取消コマンド実行を呼び出すことは、取消実行属性識別子を使用して、取消実行属性を表すコマンドリソース構造要素を選択し、それにより取消コマンド実行を呼び出すことを含んでもよい。
マシンツーマシン通信のプロトコルに従ってリモートエンティティ管理を実行するための代替の方法が開示される。この方法は、第1のエンティティにおいて第2のエンティティからRESTfulメソッド要求を受信することを含んでもよい。第1のエンティティは、そのRESTfulメソッドにより変更可能なデータ構造を含んでもよい。データ構造は、第1のリソースを表す下位データ構造を含んでもよく、第1のリソースは、コマンドリソース状態を呼び出す動作を定義する。下位データ構造は、識別子により識別可能であってもよく、ならびにRESTfulメソッド要求は識別子を含んでもよく、およびリソースコマンドを識別してもよい。方法は、RESTfulメソッドを実行して、識別子およびリソースコマンドに従ってデータ構造の変更を呼び出すことを含んでもよい。
1つまたは複数の実施形態において、コマンドリソース状態における変化を呼び出す動作は、コマンド実行を呼び出す動作、コマンド実行への中断を呼び出す動作、再開コマンド実行を呼び出す動作、または取消コマンド実行を呼び出す動作を含んでもよい。
1つまたは複数の実施形態において、コマンドの状態における変化を呼び出す下位データ構造(例えば、下記で説明するように<command>、<commandInstance>、または<requestInstance>)のうちのいずれかは、その下部データ構造が下位にあるデータ構造からインポートされた属性、下位リソース、パラメータおよび引数のうちのいずれかを含んでもよい。
一実施形態では、方法は、デバイスのアドレスマッピングを保持すること、およびそのアドレスマッピングを使用して、デバイスに通知を送信することを含んでもよい。デバイスは、デバイス管理デバイスであってもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、M2Mデバイスを管理するための透過モードおよびプロキシモードのうちの1つを使用して、サービス能力(D)を有するM2Mデバイスを管理することを含んでもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、M2Mデバイスを管理すること、およびM2Mデバイスを管理するための適合モードを使用することを含んでもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、非ETSI M2Mデバイスを管理すること、および非ETSI M2Mデバイスを管理するための適合モードを使用することを含んでもよい。
一実施形態では、方法は、ゲートウェイにおいて、デバイスのアドレスマッピングを保持すること、およびそのアドレスマッピングを使用してデバイスに通知を送信することを含んでもよい。
上記実施形態における方法であり、デバイスはデバイス管理用デバイスである。
上記実施形態の少なくとも1つにおける方法であり、デバイスは、サービス能力(D)により構成されてもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、サービス能力(D)を有するM2Mデバイスを管理すること、および透過モードおよびプロキシモードのうちの1つを使用してM2Mデバイスを管理することを含んでもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、M2Mデバイスを管理すること、および適合モードを使用してM2Mデバイスを管理することを含んでもよい。
一実施形態では、方法は、デバイス管理ゲートウェイにおいて、非ETSI M2Mデバイスを管理すること、および適合モードを使用して非ETSI M2Mデバイスを管理することを含んでもよい。
一実施形態では、M2MエリアネットワークおよびM2Mデバイスをモデリングするデータについてのデータ構造は、etsiAreaNwkInfoを含む少なくとも1つの管理オブジェクトを含み、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceInventoryを含んでもよく、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceGroupsを含み、少なくとも1つの管理オブジェクトは、etsiAreaNwkGroupOperationsを含み、および少なくとも1つの管理オブジェクトは、etsiSensorsを含む。データ構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも1つを提供してもよい。
一実施形態では、マシンツーマシン(M2M)エリアネットワークおよびM2Mデバイスをデータについてのデータモデリングの方法は、M2Mネットワークおよび少なくとも1つのデバイスについての少なくとも1つの管理オブジェクトを含む、M2Mについてのデータモデルを管理することを含んでもよい。
上記実施形態における方法であり、管理することは、デバイスリストおよび構成管理を提供してもよい。
上記実施形態の少なくとも1つにおける方法であり、管理することは、エリアネットワーク構成管理を提供してもよい。
上記実施形態の少なくとも1つにおける方法であり、管理することは、エリアネットワーク性能管理を提供してもよい。
上記実施形態の少なくとも1つにおける方法であり、管理することは、デバイスのグループ管理を提供してもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkInfoを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceInventoryを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceGroupsを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkGroupOperationsを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiSensorsを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、下位リソースを含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、別の管理オブジェクトの下位リソースを含んでもよい。
上記実施形態における方法であり、etsiAreaNwkInfoは、areaNwkInstanceを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、areaNwkInstanceは、areaNwkID、areaNwkType、workmgChannelFrequency、およびaddressModのうちのいずれかを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkDeviceInventoryは、deviceInstanceおよびdeviceApplicationListのうちのいずれかをグループとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、deviceInstanceは、deviceGroupList、etsiBattery、etsiMemory、およびetsiSensorのうちの少なくとも1つを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、deviceInstanceは、deviceType、deviceID、addressType、areaNwkID、internal address、external address、sleepInterval、sleepDuration、status、maxRtrAdvertisements、minDelayBetweenRas、maxRaDelayTime、tenativeNceLifetime、hopLimit、rtrSolicitationInterval、maxRtrSolicitatios、またはmaxRtrSolicitationIntervalのうちの少なくとも1つを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkDeviceGroupsは、deviceGroupInstanceを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、deviceGroupInstanceは、groupID、groupType、groupSize、member(メンバ)、またはcondition(条件)のうちの少なくとも1つを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkGroupOperationsは、operationInstanceを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、operationInstanceは、groupID、enable、disable、results(結果)、またはdescription(詳細)のうちの少なくとも1つを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、etsiSensorsは、sensorInstanceを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、sensorInstanceは、sensorID、sensorType、manufacturer(製造者)、またはoperations(動作)のうちの少なくとも1つを下位リソースとして含んでもよい。
上記実施形態の少なくとも1つにおける方法であり、operationsは、enable、disable、またはresult(結果)のうちの少なくとも1つを下位リソースとして含んでもよい。
一実施形態では、マシンツーマシン(M2M)エリアネットワークおよびM2Mデバイスをモデリングするデータについてのリソース構造は、etsiAreaNwkInfoを含む少なくとも1つの管理オブジェクトを含んでもよく、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceInventoryを含み、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceGroupsを含み、少なくとも1つの管理オブジェクトは、etsiAreaNwkGroupOperationsを含み、少なくとも1つの管理オブジェクトはetsiSensorsを含み、リソース構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも1つを提供する。
一実施形態では、M2MエリアネットワークおよびM2Mデバイスをモデリングするデータについてのデータ構造は、etsiAreaNwkInfoを含む少なくとも1つの管理オブジェクト、etsiAreaNwkDeviceInventoryを含む少なくとも1つの管理オブジェクト、etsiAreaNwkDeviceGroupsを含む少なくとも1つの管理オブジェクト、etsiGroupMgmtOperationsを含む少なくとも1つの管理オブジェクト、およびetsiSensorsを含む少なくとも1つの管理オブジェクトを含む。データ構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも1つを提供する。
一実施形態では、マシンツーマシン(M2M)エリアネットワークおよびM2Mデバイスについてのデータモデリングの方法は、M2Mネットワークおよび少なくとも1つのデバイスについての少なくとも1つの管理オブジェクトを含む、M2Mについてのデータモデルを管理することを含んでもよい。
上記実施形態における方法であり、管理することは、デバイスリストおよび構成管理を提供する。
上記実施形態の少なくとも1つにおける方法であり、管理することは、エリアネットワーク構成管理を提供する。
上記実施形態の少なくとも1つにおける方法であり、管理することは、エリアネットワーク性能管理を提供する。
上記実施形態の少なくとも1つにおける方法であり、管理することは、デバイスのグループ管理を提供する。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkInfoを含む。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceInventoryを含む。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiAreaNwkDeviceGroupsを含む。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiGroupMgmtOperationsを含む。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、etsiSensorsを含む。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、下位リソースを備える。
上記実施形態の少なくとも1つにおける方法であり、少なくとも1つの管理オブジェクトは、別の管理オブジェクトの下位リソースを備える。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkInfoは、areaNwkInstanceを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、areaNwkInstanceは、areaNwkID、areaNwkType、workingChannelFrequency、addressMode、sleepInterval、sleepDuration、numOfDevices、およびattachedDevicesのうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkDeviceInventoryは、deviceInstanceおよびareaNwkInstanceのうちの少なくとも1つをグループとして含む。
上記実施形態の少なくとも1つにおける方法であり、deviceInstanceは、groups(グループ)、deviceType、deviceID、addressType、areaNwkID、internalAddress、externalAddress、sleepInterval、sleepDuration、status(状態)、etsiBattery、etsiMemory、etsiSensor、blockSize、およびMTUのうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、deviceInstanceは、6LoWPAN、Wi−Fi、RFID、およびZigBeeのうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、etsiAreaNwkDeviceGroupは、deviceGroupInstanceを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、deviceGroupInstanceは、groupID、groupType、groupSize、member(メンバ)、またはstatus(状態)のうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、etsiGroupMgmtOperationsは、groups(グループ)、subscriptions(詳細)、およびoperationInstanceのうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、operationInstanceは、groupID、execEnable、execDisable、execPause、execResume、execStatus、OperationID、execResults、およびexecParametersのうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、etsiSensorsは、sensorInstanceを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、sensorInstanceは、sensorID、sensorType、manufacturer(製造者)、またはoperations(動作)のうちの少なくとも1つを下位リソースとして含む。
上記実施形態の少なくとも1つにおける方法であり、operationsは、enable、disable、またはresult(結果)のうちの少なくとも1つを下位リソースとして含む。
一実施形態では、無線送信/受信ユニットは、上記実施形態のうちのいずれか1つにおける方法を実装するように構成されてもよい。
一実施形態では、基地局は、上記実施形態のうちのいずれか1つにおける方法を実装するように構成されてもよい
一実施形態では、有形コンピュータ可読記憶媒体は、上記実施形態のうちのいずれか1つにおける方法を実行するために、メモリにロード可能であり、およびコンピューティングデバイスにより実行可能な実行可能命令を記憶してもよい。
一実施形態では、マシンツーマシン(M2M)エリアネットワークおよびM2Mデバイスをモデリングするデータについてのリソース構造は、etsiAreaNwkInfoを含む少なくとも1つの管理オブジェクト、etsiAreaNwkDeviceInventoryを含む少なくとも1つの管理オブジェクト、etsiAreaNwkDeviceGroupsを含む少なくとも1つの管理オブジェクト、etsiGroupMgmtOperationsを含む少なくとも1つの管理オブジェクト、およびetsiSensorsを含む少なくとも1つの管理オブジェクトを含んでもよく、ならびにリソース構造は、デバイスリストおよび構成管理、エリアネットワーク構成管理、エリアネットワーク性能管理、またはデバイスのグループ管理のうちの少なくとも1つを提供する。
上述した方法、装置、およびシステムの変形は、本発明の範囲から逸脱しないで可能である。適用することができる種々の実施形態に照らして、説明される実施形態は例示に過ぎず、および下記の特許請求の範囲を限定するものと解釈すべきでないことが理解されよう。例えば、本明細書に記載の例示的実施形態はハンドヘルドデバイスを含み、当該ハンドヘルドデバイスは、任意の適切な電圧を提供するバッテリなどの任意の適切な電圧源を含んでもよく、またはそのような電圧源と共に利用されてもよい。
上記では特定の組み合わせで特徴および要素を説明したが、当業者の一人は、各特徴または要素を単独で、または他の特徴および要素と任意の組み合わせで使用することができることを認識されよう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアに実装されてもよい。コンピュータ可読媒体の例は、電子信号(有線または無線接続上で伝送される)、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにCD−ROMディスクおよびデジタル多用途ディスク(DVD)などの光学媒体を含むが、これらに限定されない。ソフトウェアと関連したプロセッサが使用されて、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータで使用するための無線周波送受信機を実装してもよい。
さらに、上記の実施形態では、処理プラットフォーム、コンピューティングシステム、コントローラ、およびプロセッサを収容する他のデバイスが記述される。これらのデバイスは、少なくとも1つの中央処理装置(「CPU」)およびメモリを収容してもよい。コンピュータプログラミングの分野の当業者の慣行に従って、動作および操作もしくは命令の記号的表現への参照は、各種CPUおよびメモリによって実行されてもよい。そのような動作および操作もしくは命令は、「実行される」「コンピュータにより実行される」、または「CPUにより実行される」等と言及されてもよい。
当業者は、動作および記号的に表現された操作もしくは命令は、CPUによる電気信号の操作を含むことを認識されよう。電子システムは、結果として電子信号の変換または減少を生じさせることができるデータビット、およびメモリシステム内の記憶場所におけるデータビットの保持を表し、それにより、CPUの動作ならびに信号の他の処理を再構成するか、またはその他の形で変化させる。データビットが保持される記憶場所は、データビットに対応し、またはデータビットを表す特定の電気的特性、磁気的特性、光学的特性、または有機的特性を有する物理的な位置である。例示的実施形態は、上記のプラットフォームまたはCPUに限定されず、ならびに他のプラットフォームおよびCPUは本明細書に記載の方法を支援してもよいことを理解されたい。
データビットは、磁気ディスク、光学ディスク、およびCPUにより読み取り可能な任意の他の揮発性(例えば、ランダムアクセスメモリ(「RAM」))または不揮発性(例えば、読み出し専用メモリ(「ROM」))の大容量記憶システムを含むコンピュータ可読媒体に保持することもできる。コンピュータ可読媒体は、協働するまたは相互接続されたコンピュータ可読媒体を含むことができ、そのような媒体は、処理システムに限定的に存在するか、または処理システムにとってローカルもしくはリモートの複数の相互接続された処理システム間に分散される。例示的な実施形態は上記のメモリに限定されず、他のプラットフォームおよびメモリが本明細書に記載の方法を支援できることを理解されたい。
本出願の詳細で使用される要素、動作、または指示はいずれも、明示的にその旨を述べない限り本発明に不可欠または必須であると解釈すべきでない。また、本明細書で使用される場合、冠詞「a」は1つまたは複数の項目を含むことが意図される。1つのみの項目が意図される場合は、用語「1つの」または同様の文言が使用される。さらに、本明細書で使用される複数の項目および/または複数の項目のカテゴリの列挙により従った用語「〜のいずれか(any of)」は、「〜のいずれか」、「〜の任意の組み合わせ」、「任意の複数の〜」、ならびに/あるいは、項目および/または個々の項目のカテゴリもしくは他の項目および/もしくは複数の項目のカテゴリを伴う「複数の任意の組み合わせ」を含むことが意図される。さらに、本明細書で使用される場合、用語「セット(set)」および/または「集合」は、ゼロを含む任意の数の項目を含むことが意図される。さらに、本明細書で使用される場合、用語「数(number)」は、ゼロを含む任意の数を含むことが意図される。
さらに、請求項は、その趣旨の記述がない限り記載された順序または要素に限定されると解釈すべきでない。加えて、請求項における用語「手段(means)」の使用は、米国特許法第112条第6項を援用することが意図され、および用語「手段」を含まない請求項はいずれもそのように意図されない。