JP6514315B2 - マシン対マシンネットワークにおけるリソースおよび属性管理 - Google Patents

マシン対マシンネットワークにおけるリソースおよび属性管理 Download PDF

Info

Publication number
JP6514315B2
JP6514315B2 JP2017501103A JP2017501103A JP6514315B2 JP 6514315 B2 JP6514315 B2 JP 6514315B2 JP 2017501103 A JP2017501103 A JP 2017501103A JP 2017501103 A JP2017501103 A JP 2017501103A JP 6514315 B2 JP6514315 B2 JP 6514315B2
Authority
JP
Japan
Prior art keywords
attribute
request
generated
attributes
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017501103A
Other languages
English (en)
Other versions
JP2017515430A (ja
Inventor
ブハラ，ラジェシュ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of JP2017515430A publication Critical patent/JP2017515430A/ja
Application granted granted Critical
Publication of JP6514315B2 publication Critical patent/JP6514315B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Description

＜関連出願に対する相互参照＞
本特許文書は、２０１４年３月１８日出願の米国仮特許出願６１／９５５，１８０号、２０１４年４月３日出願の米国仮特許出願６１／９７４，９２３号、２０１４年４月２３日出願の米国仮特許出願６１／９８３，４１１号、および２０１４年５月３０日出願の米国仮特許出願６２／００５，９６１号の優先権を主張する。これら特許出願の全体は、参照により本文書の開示の一部として組み込まれる。
＜技術分野＞
本特許文書は、マシンタイプ通信（ＭＴＣ）とマシン対マシン（Ｍ２Ｍ）通信を含む通信に関するものである。
多くのアプリケーションにおいて、無線ネットワーク内で動作する無線デバイスは、当該無線ネットワークにおいては動作していないが通信可能な他のデバイスおよびサーバと通信する。様々な標準規格を用いて、そのような無線デバイスに対する接続を提供することができる。例えばインターネットプロトコル（ＩＰ）は、無線デバイスに対して割り当てられたＩＰアドレスに基づいて、無線デバイスが他デバイスと接続することができるフレームワークの１つである。
例えばマシンタイプ通信（ＭＴＣ）やマシン対マシン通信の無線デバイスを含むシステムの場合においては、ＩＰ接続のフレームワークがないことがある。
本文書は、Ｍ２Ｍデバイス間の通信を促進する技術を記載している。開示する技術を用いて、実施形態において、Ｍ２Ｍデバイスがリソースを生成し、他のＭ２Ｍデバイスがこれを知ることができるようにし、Ｍ２Ｍデバイスがこれを削除することができる。
１側面において、Ｍ２Ｍ通信システムにおいてアナウンスされた属性から情報を取得する技術は、前記アナウンスされた属性のアドレスを指定するとともに前記アナウンスされた属性のＩＤを含めることにより情報取得リクエストを発行するステップ；前記情報取得リクエストに応じて情報応答を受信するステップ；前記受信した情報応答をローカルで処理するかまたは他のＭ２Ｍデバイスへ転送して処理させるかを選択するステップ；を有する。
他側面において、Ｍ２Ｍ通信システムにおいてアナウンスされた属性を削除する技術は、削除すべき属性が省略されたリソースの属性リストを生成するステップ；前記削除すべき属性をホストしているＭ２Ｍノードに対して前記リストを送信するステップ；を有する。
他側面において、Ｍ２Ｍ通信システムにおいてアナウンスされたリソースを生成する技術は、生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するステップ；前記発行された生成リクエストに対する許可応答を受信するステップ；を有する。
これらおよびその他側面、その実装および変形例は、図面、明細書、および特許請求範囲に記載されている。
無線ネットワークアーキテクチャの例を示す。
無線ネットワークで動作する無線デバイスの例のブロック図である。
Ｍ２Ｍ通信システムのアーキテクチャ例を示す。
ＣＳＥＢａｓｅリソースの例を示す。
ｒｅｍｏｔｅＣＳＥリソースの例を示す。
Ｍ２Ｍシステムにおける情報フローの例を示す。
属性取得手順におけるメッセージ交換の例を示す。
属性更新手順におけるメッセージ交換の例を示す。
属性削除手順におけるメッセージ交換の例を示す。
Ｍ２Ｍ通信方法の例フローチャートである。
Ｍ２Ｍ通信装置の例のブロック図である。
Ｍ２Ｍ通信方法の例のフローチャートである。
Ｍ２Ｍ通信装置の例のブロック図である。
Ｍ２Ｍ通信方法の例のフローチャートである。
Ｍ２Ｍ通信装置の例のブロック図である。
マシン対マシン通信（Ｍ２Ｍ）において、２つのデバイス間の通信は自動的にトリガされる。すなわち、人間ユーザが積極的に参加することはない。例えばＭ２Ｍ通信は、時間的境界において開始する場合がある。例えば週１回、または特定イベント発生時（例：雨の後にマシンが記録した降雨測定）である。Ｍ２Ｍ通信に参加するデバイスは、長期間（例：数時間から数か月）パワーダウンまたはスリープモード（他デバイスと通信しない）になる場合がある。Ｍ２Ｍデバイスによる長時間のスリープサイクルの結果、通信エンドポイントにおけるリソースなどの動作パラメータは、２つのデバイス起動サイクル間で変化する場合がある。さらにＭ２Ｍデバイスはバッテリ動作する場合があり、バッテリ寿命を節約してこれらデバイスがバッテリ交換しなくて済むようにすることは有用である。
Ｍ２Ｍデバイスは、特定のリソースを搭載する場合がある。リソースの例としては、メモリ、演算パワー、センサ、別ネットワークへの接続、エネルギー貯蔵能力、ディスプレイリソース、などが挙げられる。各リソースは、当該リソースを記述するために用いる、対応する属性セットを有する。通信メッセージの観点において、リソースはＭ２Ｍデバイスを記述するために用いるデータ構造を表す。データ構造の各要素は、属性とみなすことができる。Ｍ２Ｍデバイスにとってローカルで利用可能なリソースは、経時変化する場合がある。例えばＭ２Ｍデバイスがスリープモードであって他のＭ２Ｍデバイスと通信していない間である。例えばオフライン中にストレージ機能をビデオ監視カメラに対して追加することができる。他例として、ｏｎ／ｏｆｆタイプの光バルブは、薄暗くなるタイプの光バルブと交換することにより、証明を調整するリソースを提供することができる。同様にＭ２Ｍデバイスからリソースを剥奪または削除することができる。
他のＭ２Ｍデバイスに対して利用可能リソースの最新スナップショットを提供することは、Ｍ２Ｍデバイスによっては厄介なことである場合がある。リソース管理はバッテリパワーを消費するからである（例：計算および／または通信のため）。さらにＭ２Ｍデバイスのなかには、人間が到達することが困難なものがあり、あるいはローカルユーザインターフェースを備えておらず遠隔管理するものがある。アプリケーションサーバは、Ｍ２Ｍデバイス上で利用可能なリソースの属性を知ることを望む場合がある。現在通信していないＭ２Ｍデバイスにとって、この情報は以下によって収集することができる：（１）アプリケーションサーバがＭ２Ｍデバイスを起動してその属性を照会する、または（２）ネットワークにおいて他デバイス（例：ゲートウェイデバイス）が保持しているＭ２Ｍデバイスの属性のシャドーコピーまたはクローンコピーを読み取る。このデバイスは通信可能なものである。
後者の方法は、Ｍ２Ｍ通信に対してある種の利点を提供する。アプリケーションサーバからのクエリは、複数のサービスプロバイダの制御下におくことができ、個々のＭ２Ｍデバイスを起動する必要はなく、したがってバッテリパワーとネットワークの通信帯域幅を節約できるからである。個々のＭ２Ｍデバイスの属性の総数は、数百エントリに達する場合があり、したがって数キロバイトまたは数メガバイト（例：８Ｋｂｙｔｅから４Ｍｂｙｔｅ）の帯域幅と、全属性のクローンコピーまたはシャドーコピーを保存する記憶領域とを使用する。アプリケーションサーバは、Ｍ２Ｍデバイスの全属性値を必要としない場合もある。したがって、Ｍ２Ｍデバイスの属性をそのシャドーコピーと同期することは、通信時間、パワー、帯域幅を不必要に消費する場合がある。
現在のＭ２Ｍ通信システムおよびプロトコルは、Ｍ２Ｍ通信システムにおいて生じる動作状況に対して適切に対処することができていない。本文書が開示する技術を用いて、Ｍ２Ｍ通信システムにおけるリソースの属性の効率的な生成、広告、および削除を提供することができる。これは複数のサービスプロバイダにとって有用である。
Ｍ２Ｍエコシステムをエンドトゥエンド（Ｅ２Ｅ）の観点から見ると、Ｍ２Ｍアプリケーションサーバ（ＡＳ）がホストするＭ２Ｍアプリケーションと、Ｍ２Ｍデバイス／ゲートウェイとが存在する。このＥ２Ｅビューにおいて、Ｍ２Ｍサービスプラットフォームは、データ管理、デバイス管理、サービス有効化機能、などを提供する。基盤送信ネットワークは、Ｍ２Ｍデバイス／ゲートウェイがホストするＭ２Ｍアプリケーションとアプリケーションサーバとの間のデータフローの送受信サービスを提供する。
以下の定義セットは、ｏｎｅＭ２Ｍが開発している仕様からのものである。
アプリケーション機能（ＡＦ）：エンドトゥエンドＭ２Ｍソリューションのアプリケーションロジックを提供する。アプリケーション機能の例は、艦隊トラッキングアプリケーション、遠隔血糖監視アプリケーション、遠隔パワー計測制御アプリケーションである。
アプリケーションレイヤ：Ｍ２Ｍアプリケーションと関連するビジネスおよび動作ロジックを備える。
共通サービスエンティティ（ＣＳＥ）：共通サービスエンティティは、共通サービス機能の集合である。Ｍ２Ｍノードにおける共通サービスエンティティは、当該Ｍ２ＭノードにおけるＭ２Ｍアプリケーションが使用するサービスセット、または他のＭ２Ｍノードがアクセスするサービスを提供する。共通サービスエンティティは、基盤ネットワーク機能を利用し、相互通信してサービスを充足することができる。
共通サービス機能（ＣＳＦ）：Ｍ２ＭノードがＭ２Ｍシステムにおける他のエンティティに対して提供するサービス／機能のセットである。このサービス／機能は、ｏｎｅＭ２Ｍ規格に基づき、Ｍ２Ｍシステムにおける参照ポイントＸおよびＹを通じて、他の共通サービス機能（ＣＳＦ）に対して公開される。共通サービス機能は、参照ポイントＺを使用して基盤ネットワークサービスにアクセスする。ＣＳＦの例は以下の通りである：データ管理＆リポジトリ、デバイス管理、Ｍ２Ｍセッション管理、など。
共通サービスレイヤ：Ｍ２Ｍアプリケーションを有効化するＭ２Ｍサービス機能を備える（例えば管理、ディスカバリ、およびポリシ監視を通じて）。
ネットワークサービスレイヤ：送信、接続、およびサービス機能を提供する。
Ｍ２Ｍアプリケーション：サービスロジックを実施し、ｏｎｅＭ２Ｍ規格のオープンインターフェースセットを介してアクセスできるＭ２Ｍ共通サービスを使用する、アプリケーションである。
Ｍ２Ｍアプリケーションサービスプロバイダ：ユーザに対してＭ２Ｍアプリケーションサービスを提供するエンティティ（例：企業）である。
Ｍ２Ｍデバイス：検出および／または起動サービスを提供する機器である。Ｍ２Ｍデバイスは、１以上のＭ２Ｍアプリケーションをホストし、１以上のＣＳＥを収容する。Ｍ２Ｍデバイスは、検出＆起動機器と同じ場所に配置できるが、必ずしもそうしなくともよい。
Ｍ２Ｍゲートウェイ：１以上のＣＳＥを収容し、Ｍ２Ｍアプリケーションを収容する場合もある機器である。Ｍ２Ｍゲートウェイは、Ｍ２Ｍサービスインフラおよび１以上のＭ２Ｍデバイスと通信する。
Ｍ２Ｍノード：ＣＳＥおよび／またはＭ２Ｍアプリケーションを備え、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２ＭサービスインフラなどのＭ２Ｍ物理エンティティを表す、論理エンティティである。
Ｍ２Ｍサービスインフラ：Ｍ２Ｍサービスプロバイダのデータ管理と協調機能を提供し、Ｍ２Ｍデバイスおよび／またはＭ２Ｍゲートウェイと通信する機器である。Ｍ２Ｍサービスインフラは、１以上のＣＳＥを収容する。
Ｍ２Ｍサービスプロバイダ：Ｍ２Ｍアプリケーションサービスプロバイダに対してまたはユーザに対してＭ２Ｍサービスを提供するエンティティ（例：企業）である。
基盤ネットワークサービス機能（ＮＳＦ）：基盤ネットワークサービス機能は、ＣＳＥに対してＭ２Ｍノード外のエンティティからのサービスを提供する。このサービスの例は、デバイス管理、位置サービス、デバイス到達可能性状態、デバイストリガリング、などである。
検出および起動（Ｓ＆Ａ）機器：１以上のＭ２Ｍアプリケーションサービスと通信することにより物理環境の検出および／または有効化機能を提供する機器である。検出および起動機器は、Ｍ２Ｍシステムと通信するが、Ｍ２Ｍアプリケーションをホストしない。Ｓ＆Ａ機器は、Ｍ２Ｍデバイスと同じ位置に配置できるが、必ずしもそうでなくともよい。
Ｘ参照ポイント
Ｍ２ＭアプリケーションとＣＳＥとの間の参照ポイントである。Ｘ参照ポイントにより、Ｍ２ＭアプリケーションはＣＳＥが提供するサービスを使用することができ、ＣＳＥはＭ２Ｍアプリケーションと通信することができる。
Ｙ参照ポイント
２つのＣＳＥ間の参照ポイントである。Ｙ参照ポイントにより、ＣＳＥは他のＣＳＥのサービスを使用して、必要な機能を充足することができる。
Ｚ参照ポイント
ＣＳＥと基盤ネットワークとの間の参照ポイントである。Ｚ参照ポイントにより、ＣＳＥは基盤ネットワークが提供するサービス（送信および接続サービスを除く）を用いて、必要な機能を充足することができる。
Ｍ２ＭサービスのＥ２Ｅビューによれば、Ｍ２Ｍアプリケーションサーバ、Ｍ２Ｍデバイス／ゲートウェイ、Ｍ２Ｍサービスプラットフォーム、および送信ネットワークは、Ｅ２Ｅ Ｍ２Ｍサービスフレームワークにおける別のエンティティとみなすことができる。これらエンティティそれぞれは、異なるビジネスエンティティを表しているとみなすこともできる。例えばＭ２Ｍアプリケーションサービスプロバイダは、Ｍ２Ｍアプリケーションサービスをエンドユーザに対して提供するビジネスエンティティ（例：企業）である。Ｍ２Ｍサービスプロバイダ（ＳＰ）は、Ｍ２Ｍアプリケーションサービスプロバイダが使用してＭ２Ｍデバイス／ゲートウェイからのサービスを実現するＭ２Ｍサービスプラットフォームを提供する他のビジネスエンティティ（例：企業）である。これは検出および起動（Ｓ＆Ａ）機器と統合することができる。基盤ネットワークサービスプロバイダは、有線および／無線技術に基づく基盤送信ネットワークを提供する。例えばＩＥＥＥ、ＩＥＴＦ、３ＧＰＰ、３ＧＰＰ２、ＢＢＦなどが規定するものである。
Ｍ２Ｍサービスフレームワーク内において、Ｍ２Ｍデバイス／ゲートウェイは、異なるＭ２Ｍサービスプロバイダ（ＳＰ）固有のアプリケーションをホストすることができる。例えば、エネルギー管理、ホームセキュリティ、健康監視などのサービスをサポートするＳ＆Ａ機器を有するスマートホームの場合を考える。これらサービス（エネルギー管理、ホームセキュリティ、健康監視など）は、異なるＭ２Ｍサービスプロバイダによって提供される。これら全てのサービスは、単一のホームゲートウェイ上でスマートホーム内においてホストされる。これは、異なるサービスについてＳ＆Ａ機器を用いることによる。このサービスシナリオにおいて、ホームゲートウェイは通常、家屋所有者が所有しており、Ｓ＆Ａ機器はサービス固有である（Ｓ＆Ａ機器を誰が所有しているかはこの文書の主題ではない）。例えばエネルギー管理サービスと健康監視サービスのためのＳ＆Ａ機器は、提供されるサービス固有のものであり、それぞれのＭ２Ｍサービスプロバイダが管理する必要がある（この場合はエネルギー管理サービスプロバイダと健康監視サービスプロバイダ）。同様にＭ２Ｍサービスプロバイダは、他のＭ２Ｍサービスプロバイダから独立したホームゲートウェイ上のそれぞれの動作環境セットを管理したい場合がある。例えばエネルギー管理サービスプロバイダは、ホームゲートウェイにインストールされているエネルギー監視ソフトウェア／ファームウェアを更新したい場合がある。ただしこの更新は、健康監視サービスプロバイダが提供するサービスに対して影響を与えるべきではない。このような様々なサービスセットを提供していると、ホームゲートウェイは、異なるＭ２Ｍサービスプロバイダが提供するサービスを分離するセキュア環境を提供する必要があることになりがちである。
図１は、無線通信ネットワークまたはシステムの例を示す。この無線通信ネットワークは、１以上のベースステーション（ＢＳ）１０５と１０７、１以上の無線デバイス１１０を含む。ベースステーション１０５と１０７は、１以上の無線デバイス１１０に対して、フォワードリンク（ＦＬ）上でシグナル（ダウンリンク（ＤＬ）シグナルとして知られている）を送信することができる。無線デバイス１１０は、１以上のベースステーション１０５と１０７に対して、リバースリンク（ＲＬ）上でシグナル（アップリンク（ＵＬ）シグナルとして知られている）を送信することができる。無線通信システムは、１以上のネットワーク１２５を備え、１以上のベースステーション１０５と１０７を制御することができる。１以上のベースステーションは、無線アクセスネットワークを形成する。ベースステーションは、単独でまたは他のベースステーションとの組み合わせにより無線デバイスに無線アクセスを提供するという性質上、アクセスポイント（ＡＰ）、アクセスネットワーク（ＡＮ）、またはｅＮｏｄｅＢと呼ばれる場合がある。本技術とシステムを実装することができる無線通信システムの例としては、ＣＤＭＡ２０００ １ｘなどのＣｏｄｅ ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＣＤＭＡ）、Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ＨＲＰＤ）、Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、 Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）などに基づく無線通信システムが挙げられる。
図２は、無線デバイス、ベースステーション、その他無線通信モジュールを実装する無線トランシーバステーションの例を示す。無線ステーションの例として、図１のベースステーションや無線デバイスが挙げられる。ベースステーションや無線デバイスなどの無線ステーション２０５は、プロセッサ電子部品２１０を備える。プロセッサ電子部品２１０は、例えば本文書が提示する技術のうち１以上の方法を実装するマイクロプロセッサである。無線ステーション２０５は、トランシーバ電子部品２１５を備え、例えば１以上のアンテナ２２０などの１以上の通信インターフェースを介して無線シグナルを送受信することができる。無線ステーション２０５は、データを送受信するためのその他通信インターフェースを備えることもできる。実装例において無線ステーション２０５は、１以上の有線通信インターフェースを備え、有線ネットワークと通信することができる。無線ステーション２０５は、データおよび／または命令などの情報を格納するように構成された１以上のメモリ２２５を備える。実装例においてプロセッサ電子部品２１０は、トランシーバ電子部品２１５とメモリ２２５のうち少なくとも一部を備えることができる。
実装例において無線ステーション２０５は、ＣＤＭＡまたはＧＳＭ(登録商標)ベース無線インターフェースに基づき相互通信することができる。実装例において無線ステーション２０５は、直交周波数分割多重（ＯＦＤＭ）インターフェースに基づき相互通信することができる。このインターフェースは、例えば直交周波数分割多重アクセス（ＯＦＤＭＡ）インターフェースを含む。実装例において無線ステーション２０５は、１以上の無線技術を用いて通信することができる。例えばＣＤＭＡ２０００ １ｘ、ＨＲＰＤ、ＷｉＭＡＸ、ＧＳＭ、ＬＴＥ、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）である。
実装例において無線ステーション２０５は、例えば８０２．１１（ａ／ｂ／ｇ／ｎ）インターフェースなどのローカルエリアネットワーク接続を用いて構成することができる。このようなインターフェースを利用することにより、ローカルエリア接続を介してインターネットに対して無線ステーション２０５を接続することができる。例えばユーザは、ケーブルモデムネットワークやＤＳＬネットワークなどの固定ブロードバンドネットワーク経由で無線ローカルエリアネットワーク接続（例えばホームＷｉ−Ｆｉアクセス）を通じてサービスに接続することにより、自身の装置（ＵＥ）を介してサービスにアクセスすることができる。上記無線ステーション２０５を用いて、本文書が開示する技術を実装することができる。同様に、アクセスネットワーク１２５（例：コアまたはバックボーンネットワークまたはこれに接続されたアプリケーションサーバ）と接続された他のエンティティまたはモジュールは、本技術を実装することができる。
ｏｎｅＭ２Ｍシステムに対する配置の第１実施形態
本文書が記載する技術は、ｏｎｅＭ２Ｍ規格に準拠したデバイスと共同するように配置された実装において実施することができる。その現行バージョンを１例として以下に説明する。
本文書において以下の略語を用いる。
ＡＮＤ：アプリケーション専用ノード
ＡＤＮ−ＡＥ：アプリケーション専用ノード上のＡＥ
ＡＥ：アプリケーションエンティティ
Ａｐｐ：アプリケーション
ＡＳＮ：アプリケーションサービスノード
ＡＳＥ−ＡＥ：アプリケーションサービスノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ
ＡＳＮ−ＣＳＥ：アプリケーションサービスノード上のＣＳＥ
ＢＢＦ：ブロードバンドフォーラム
ＣＳＥ：共通サービスエンティティ
ＣＳＦ：共通サービス機能
ＥＦ：イネーブラ機能
ＩＥＥＥ：Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ
ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ
ＩＮ：インフラノード
ＩＮ−ＡＥ：インフラノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ
ＩＮ−ＣＳＥ：インフラノード上のＣＳＥ
ＪＮＩ：Ｊａｖａ(登録商標) Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ
ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ
ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ
Ｍ２Ｍ：マシンツーマシン
ＭＮ：ミドルノード
ＭＮ−ＣＳＥ：ミドルノード上のＣＳＥ
ＮＳＥ：ネットワークサービスエンティティ
ＳＤＯ：規格開発団体
ＳＰ：サービスプロバイダ
ＵＮｅｔ：基盤ネットワーク（Ｍ２Ｍデバイスが存在するネットワーク）
マシンツーマシン（Ｍ２Ｍ）通信において、２つのデバイス（例えばアプリケーションサーバとＭ２Ｍデバイス）は、人間のユーザが明示的に通信を開始することなく、互いに通信することができる。Ｍ２Ｍ通信において、通信が発生する２つのエンドポイントは、異なるネットワーク上に存在する場合がある。一般的なアプリケーションシナリオにおいて、１つのエンドポイントはある期間オフラインになるセンサまたはユーティリティボックスであり、他のエンドポイントはユーティリティ請求サーバやＭ２Ｍサーバなどのような管理ネットワーク上に配置されるアプリケーションサーバである。これら２つのエンドポイント間を行き交うデータパケットは、様々なルーティングオプションによってルーティングすることができる。例えば１つのエンドポイントは、ライセンスされたスペクトル上で（例えばＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）またはライセンスされていないスペクトル上で（例えばＷｉ−Ｆｉ）、通信することができる。１つのエンドポイントがある期間オフラインになると（例えば数日あるいは数週間）、最後の通信セッションの間においてパケットがそのエンドポイントへルーティングされた方法は、パケットを現在の通信セッションにおいてルーティングすることができる方法とは、必ずしも一致しない。さらに様々なルーティングオプションを用いると、様々なコストが生じる（例えば帯域幅チャージや通信中のパワー散逸）。
電力その他リソースを節約するため、Ｍ２Ｍデバイスやこれらデバイス上で動作するアプリケーションエンティティのなかには、時間経過にともなって“オフライン”になるものがある。アプリケーションレイヤ通信を再確立するため、これらＭ２Ｍエンティティを通信の前に起動する必要がある。トリガリングを実施する態様や起動されるモジュールもしくはエンティティは、個々のＭ２Ｍデバイスの設定や性能に依拠する。
ｏｎｅＭ２Ｍ、ＥＴＳＩ ＴＣ Ｍ２Ｍ、ＴＩＡ ＴＲ−５０などの団体（Ｍ２Ｍ ＳＤＯ）が開発しているサービスレイヤ仕様は、広範な市場（垂直）組織によるＭ２Ｍソリューションの効率的な配置をサポートする必要がある。サービスレイヤにフォーカスすると、これら組織は送信ネットワークから独立してエンドツーエンドサービスを把握している。ただし、異なるタイプの送信ネットワークとインターフェースをとるため、サービスレイヤ仕様が確実に効率的に使われるようにする必要がある。送信ネットワークの例としては、３ＧＰＰ、３ＧＰＰ２、ＩＥＥＥ、ＩＥＴＦ、ＢＢＦが規定する無線および有線ネットワークが挙げられるが、これに限らない。
サービスレイヤ仕様において、現在、共通サービスリソースを保持するエンティティに関連付けられた特定のＭ２Ｍデバイスをサービスリクエストが識別してＭ２Ｍリクエストを充足する手段はない。さらに、スリープ中のＭ２Ｍデバイスをトリガリング起動してＭ２Ｍ通信リクエストを充足する必要がある場合、リクエストをルーティングすべきトリガリングデバイスを現行システムが特定する方法は、限られている。本文書が提示する技術は、これらおよびその他課題を解決する。
図３は、ｏｎｅＭ２Ｍシステムがサポートする構成３００の例を示す。図３は、ｏｎｅＭ２Ｍが開発している機能アーキテクチャ仕様の抜粋である。
この例３００において、ＡＤＮ（ＡＤＮ−ＡＥ）上のアプリケーションエンティティ（ＡＥ）は、ＩＮ−ＣＳＥに登録する。同様に非ノードＡＥも、ＩＮ−ＣＳＥに登録する。ＡＤＮ−ＡＥは、ＭＮ−ＣＳＥにも登録する。これら登録は、リモートエンティティ／ノードにおけるＡＥとＣＳＥとの間の登録である。
ＣＳＥは、１以上のＣＳＦのインスタンスである。ＣＳＥは、Ｍ２Ｍアプリケーションが使用し共有することができるＣＳＦのサブセットを提供する。ＣＳＥは、ＵＮｅｔ機能を利用することができ、他のＣＳＥと通信してサービスを充足することができる。ＣＳＥは、Ｍ２Ｍ環境において共通の“サービス機能”セットを備える。このサービス機能は、ｏｎｅＭ２Ｍが規定するＭｃａ参照ポイントやＭｃｃ参照ポイントなどの参照ポイント（図３参照）を介して、他のエンティティに対して公開される。Ｍｃｃ参照ポイントは、ＣＳＥ間の通信フローを定義する。参照ポイントＭｃｎは、基盤ネットワークサービスエンティティにアクセスするために用いられる。ＣＳＥが提供するサービス機能の例は以下である：データ管理、デバイス管理、Ｍ２Ｍサブスクリプション管理、位置サービス、など。ＣＳＥが提供するこれら“サブ機能”は、論理的に共通サービス機能（ＣＳＦ）として把握することができる。共通サービスエンティティ（ＣＳＥ）内部において、ＣＳＦのうちいくつかは固定であり、その他はオプションである。ＣＳＦ内部において、サブ機能のうちいくつかは固定またはオプションである（例えば“デバイス管理”ＣＳＦ内部において、“アプリケーションソフトウェアインストール”、“ファームウェアアップデート”、“ログ”、“監視”などのサブ機能のうちいくつかは、固定またはオプションである）。
ＣＳＦは、Ｍ２Ｍ環境において共通のサービス機能セットであり、ｏｎｅＭ２Ｍなどの相互仕様によって規定される。
図３において、以下の略語を用いる：
非ノードＡＥ：このエンティティは、ＩＮ−ＡＥがアプリケーションサービスプロバイダによってホストされていることを示す。
ノード：少なくとも１つの共通サービスエンティティ（ＣＳＥ）および／またはアプリケーションエンティティ（ＡＥ）を保持する機能エンティティ。ノードは、例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備などの物理装置内に保持することができる。異なるノード上のＣＳＥは一般に同一ではなく、当該ノードのＣＳＥがサポートするサービスに依拠する。実施形態において、２つのタイプのノードが定義される。１つのノードタイプは、少なくとも１つの共通サービスエンティティおよび／または１以上のｏｎｅＭ２Ｍアプリケーションエンティティを保持する機能エンティティである。このノードをＣＳＥ機能ノードと呼ぶ。もう１つのノードタイプは、１以上のアプリケーションエンティティを保持し共通サービスエンティティを保持しない機能エンティティである。このノードを非ＣＳＥ機能ノードと呼ぶ。ｏｎｅＭ２Ｍアーキテクチャにおいて、ＣＳＥ機能ｏｎｅＭ２Ｍノードは、物理オブジェクト内に保持することができる。例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備である。非ＣＳＥ機能ｏｎｅＭ２Ｍノードは、例えばセンサ、アクチュエータなどの物理オブジェクト内に保持することができる。ＣＳＥ機能ノードと非ＣＳＥ機能ノードは、Ｍｃａ参照ポイントを介して通信する。
Ｍｃｃ’参照ポイントは、可能な限りＭｃｃ参照ポイントと同様のものであることを意図している。ただしＭ２Ｍ間サービスプロバイダ通信の性質により、いくつかの違いが存在する。
構成２００において、様々なタイプのノードが存在し得る。ノードは実際の物理オブジェクトにマッピングされる場合があるが、必ずしも単一の実際の物理オブジェクトに対してマッピングされる必要はない。以下のノードが存在する：
アプリケーションサービスノード（ＡＳＮ）：アプリケーションサービスノードは、１つの共通サービスエンティティと少なくとも１つのアプリケーションエンティティを保持するノードである。アプリケーションサービスノードは、Ｍｃｃ参照ポイントを介して、１つのミドルノードまたは１つのインフラノードと通信することができる。物理マッピングの例としては、アプリケーションサービスノードがＭ２Ｍデバイス上に配置される場合が挙げられる。
アプリケーション専用ノード（ＡＤＮ）：アプリケーション専用ノードは、少なくとも１つのアプリケーションエンティティを保持し、共通サービスエンティティを保持しない。アプリケーション専用ノードは、Ｍｃａ参照ポイントを通じてミドルノードまたはインフラノードと通信する。物理マッピングの例としては、アプリケーション専用ノードが制約Ｍ２Ｍデバイス上に配置される場合が挙げられる。
ミドルノード（ＭＮ）：ミドルノードは、１つの共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。ミドルノードは、Ｍｃｃを介してＩＮまたは他のＭＮと通信し、さらにＭｃｃを介してＩＮ／ＭＮ／ＡＳＮの少なくともいずれかと通信し、またはＭｃａを介してＡＤＮと通信する。物理マッピングの例としては、ミドルノードがＭ２Ｍゲートウェイ上に配置される場合が挙げられる。
インフラノード（ＩＮ）：インフラノードは、共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。インフラノードは、Ｍｃｃ参照ポイントを介して１以上のミドルノードと通信し、および／または１以上のアプリケーションサービスノードと通信する。インフラノードは、Ｍｃａ参照ポイントを介して１以上のアプリケーション専用ノードと通信する。物理マッピングの例としては、インフラノードがＭ２Ｍサーバ設備上に配置される場合が挙げられる。
Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）
Ｍ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ−ＩＤによって識別されるＣＳＥ向けのサービスが基盤ネットワークからリクエストされたとき、Ｍ２Ｍ ＳＰによって用いられる。
Ｍ２Ｍ外部ＩＤにより、基盤ネットワークはサービスリクエストについてＣＳＥ−ＩＤと関連付けられたＭ２Ｍデバイスを識別することができる。その意味において、基盤ネットワークはＭ２Ｍ−Ｅｘｔ−ＩＤをターゲットＭ２Ｍデバイスに割り当てられたＵＮｅｔ固有ＩＤにマッピングする。Ｍ２Ｍ ＳＰは、ＣＳＥ−ＩＤ、Ｍ２Ｍ−Ｅｘｔ−ＩＤ、およびＵＮｅｔ ＩＤの間の対応関係を維持することができる。
様々な実施形態において、ＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤとの間の事前準備した対応関係と動的対応関係をともに実装することができる。
各ＣＳＥ−ＩＤについて、特定の基盤ネットワークＩＤまたはＵＮｅｔｗｏｒｋ−ＩＤについてＭ２Ｍ−Ｅｘｔ−ＩＤが１つのみ存在すべきである。したがって、複数の基盤ネットワークと相互作用するＭ２Ｍ ＳＰは、同一のＣＳＥ−ＩＤに対応付けられた異なるＭ２Ｍ−Ｅｘｔ−ＩＤを基盤ネットワークごとに有し、基盤ネットワークに対して発するサービスリクエストに対して適切なＭ２Ｍ−Ｅｘｔ−ＩＤを選択する。
一般に、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＭ２ＭデバイスのＵＮｅｔによるマッピングは、ＵＮｅｔ固有のものである。
構成例において、ＵＮｅｔプロバイダとＭ２Ｍサービスプロバイダは、ＣＳＥ−ＩＤによって識別される各ＣＳＥに対してＭ２Ｍ−Ｅｘｔ−ＩＤを割り当てるに際して、協調することができる。同時にＵＮｅｔプロバイダは、ＣＳＥをホストするＭ２Ｍデバイスに対して割り当てられた、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＵＮｅｔ固有ＩＤとの間の対応関係を維持する。
事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、対応付けられたＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤは、インフラノードにおいて準備することができる。Ｍ２ＭデバイスにおけるＣＳＥは、割り当てられたＭ２Ｍ−Ｅｘｔ−ＩＤを知っておく必要はない。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＭ２Ｍ−Ｅｘｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備することができる。このＭ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。
トリガ受信者ＩＤ（Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤ）
Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＵＮｅｔからデバイストリガリングサービスがリクエストされたとき、実行環境上のトリガをルーティングすべきＡＳＮ／ＭＮ−ＣＳＥインスタンスを識別するために用いられる。例えば３ＧＰＰデバイストリガリングを用いる場合、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤはＡｐｐｌｉｃａｔｉｏｎ−Ｐｏｒｔ−Ｉｄｅｎｔｉｆｉｅｒにマッピングされる。例えば３ＧＰＰ ２３．６８２規格で規定されているものである。
事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、Ｍ２Ｍ−Ｅｘｔ−ＩＤおよび関連するＣＳＥ−ＩＤとともにインフラノードにおいて準備される。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備される。Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。
表１は、Ｍ２Ｍ ＩＤとその使用属性を例示するリストである。具体的には、表１にリストするように、外部ＩＤはＵＮｅｔプロバイダとＭ２Ｍ ＳＰとの間で連結して割り当てられ、ＵＮｅｔサービスを利用することを望むＣＳＥに属するＭ２Ｍノードに対して割り当てられ、２つの準備モードを有する。すなわち事前準備モードと動的モードであり、外部ＩＤは対応するＣＳＥの登録プロセスにおいて搬送される。
Ｍ２Ｍ ＩＤ ライフサイクルおよび特徴
Figure 0006514315
Figure 0006514315
Figure 0006514315
リソースタイプＣＳＥＢａｓｅ
＜ＣＳＥＢａｓｅ＞リソースを用いて、ＣＳＥを表すことができる。この＜ＣＳＥＢａｓｅ＞リソースは、ＣＳＥ上の全てのリソースのルートである。
図４Ａは、ＣＳＥＢａｓｅリソースに含まれる属性を例示するリストを示す。
＜ＣＳＥＢａｓｅ＞リソースは、表２に示す子リソースを含む。
Figure 0006514315
＜ＣＳＥＢａｓｅ＞リソースは、表３に示す属性を含む。
Figure 0006514315
リソースタイプｒｅｍｏｔｅＣＳＥ
＜ｒｅｍｏｔｅＣＳＥ＞リソースは、登録ＣＳＥに登録されたリモートＣＳＥを表す。＜ｒｅｍｏｔｅＣＳＥ＞リソースは、＜ＣＳＥＢａｓｅ＞の下に直接配置される。反対に登録された各ＣＳＥは、登録ＣＳＥの＜ＣＳＥＢａｓｅ＞における＜ｒｅｍｏｔｅＣＳＥ＞リソースのサブセットとして表すことができる。例えば、ＣＳＥ１がＣＳＥ２を登録するとき、２つの＜ｒｅｍｏｔｅＣＳＥ＞リソースが生成される：１つはＣＳＥ１における＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞であり、もう１つはＣＳＥ２における＜ＣＳＥＢａｓｅ２＞／＜ｒｅｍｏｔｅＣＳＥ１＞である。２つのリソースの生成は、必ずしも相互登録を示すものではない。＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞は、上記例においてＣＳＥ２がＣＳＥ１に登録されることを自動的に意味するものではない。
＜ｒｅｍｏｔｅＣＳＥ＞リソースは、例えば表４に示すような子リソースを含む。
図４Ｂは、＜ｒｅｍｏｔｅＣＳＥ＞リソースに含まれる子リソースを例示するリストである。
Figure 0006514315
実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞リソースは表５にリストする属性を含む。
Figure 0006514315
実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞とアナウンスされた＜ｒｅｍｏｔｅＣＳＥ＞は、２つのリソース間で識別できるようにするため、異なるｒｅｓｏｕｒｃｅＴｙｐｅコードを有する。
ｏｎｅＭ２Ｍシステムにおける実施形態
変形例を提供して、現行のｏｎｅＭ２Ｍ仕様を実施形態においてどのように変更して本文書の技術を実装できるかを説明する。本例は、アプリケーションエンティティまたは共通サービスエンティティ（ＣＳＥ）からのアナウンスされた属性を生成または削除するためｏｎｅＭ２Ｍが既定する現行手順に対する変更を開示する。さらに、元リソースをホストするＣＳＥが属性をアナウンスまたはアナウンス失効させるための新たな技術を開示する。
変形例は、属性をアナウンスまたはアナウンス失効させることをサポートする方法を提案する。属性アナウンス／アナウンス失効は、ＵＰＤＡＴＥ動作とＤＥＬＥＴＥ動作を用いることによりサポートされる。
例１
１０．２．１８．６ ＡＥとＣＳＥがアナウンス属性を生成開始する手順
本節は、ＡＥとＣＳＥがアナウンスする属性を生成（属性アナウンス）する手順を記載している。
オリジネータ：リクエストのオリジネータは、属性アナウンスを開始し、これはＡＥでもＣＳＥでもよい。オリジネータは、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することにより、属性アナウンスをリクエストする：
オリジネータは、ＵＰＤＡＴＥリクエストを用いることによってアナウンスする必要がある属性を追加することにより、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することができる。ＯＡとマークされた属性のみが、遠隔アナウンスリソースに対してアナウンスすることができる。
レシーバ：オリジネータが認証されると、レシーバ（例えば元リソースをホストしているＣＳＥ）はリクエストを検証した後にリクエストを許可する。
リクエストにおいて受信した属性は、ＯＡとマークされていなければ、不正である。
リクエストにおいて受信した属性は、元リソース構造において存在しなければ、不正である。
リクエストにおいて受信した属性がａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において既に存在している場合、レシーバはａｎｎｏｕｎｃｅＴｏ属性にリストされている全てのアナウンス先リソースに対してその属性をアナウンスすることができる。これは１０．２．１８．８節の手順にしたがったものである。
１０．２．１８．８節の手順にしたがって属性のアナウンスが成功すると、レシーバは以下を実施することができる：
レシーバは、１０．１．３節が規定するように、リクエストを発行したＡＥ／ＣＳＥに対してＵＰＤＡＴＥ応答で応答することができる。アナウンスされた属性の名称は、その応答で提供することができる。
Figure 0006514315
例２
１０．２．１８．７ ＡＥとＣＳＥがアナウンスする属性を削除開始する手順
本節は、ＡＥとＣＳＥがアナウンスする属性を削除（属性アナウンス失効）する手順を記載している。
オリジネータ：リクエストのオリジネータは、属性アナウンス失効を開始し、これはＡＥでもＣＳＥでもよい。オリジネータは、以下のように元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することにより、属性アナウンス失効をリクエストする：
オリジネータは、ＵＰＤＡＴＥリクエストを用いることによってアナウンス失効する必要がある属性を削除することにより、元リソースにおけるａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新することができる。ＯＡとマークされた属性のみが、遠隔アナウンスリソースに対してアナウンス失効させることができる。
レシーバ：オリジネータが認証されると、レシーバ（例えば元リソースをホストしているＣＳＥ）はリクエストを検証した後にリクエストを許可する。
リクエストにおいて受信した属性は、ＯＡとマークされていなければ、不正である。
ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において既に存在している属性がリクエストにおいて受信されなかった場合、レシーバはａｎｎｏｕｎｃｅＴｏ属性にリストされている全てのアナウンス先リソースに対してその属性をアナウンス失効させることができる。これは１０．２．１８．９節の手順にしたがったものである。
１０．２．１８．９節の手順にしたがって全属性のアナウンス失効が成功すると、レシーバは以下を実施することができる：
レシーバは、１０．１．３節が規定するように、リクエストを発行したＡＥ／ＣＳＥに対してＵＰＤＡＴＥ応答で応答することができる。アナウンス失効する属性の名称は、その応答で提供することができる。
Figure 0006514315
例３
１０．２．１８．８ 元リソースをホストするＣＳＥが属性をアナウンスする手順
本節は、元リソースをホストするＣＳＥが遠隔アナウンスリソース（すなわち属性アナウンス）においてアナウンスする属性を生成する手順を記載している。
オリジネータ：このリクエストのオリジネータは、元リソースをホストしているＣＳＥである。オリジネータは、１０．１．３節が規定するように、ＵＰＤＡＴＥリクエストを用いることにより、アナウンスリソースにおいてアナウンスする属性を生成するようリクエストすることができる。
レシーバ：オリジネータが認証されると、レシーバ（アナウンスするリソースをホストするＣＳＥ）は、リクエストを検証した後、リクエストを許可することができる。レシーバは以下を実施することができる：
１０．１．３節の部分アドレシング手順にしたがって、アナウンスリソースにおいてアナウンスする属性を生成する。
１０．１．３節にしたがって、ＵＰＤＡＴＥ応答でオリジネータに対して応答する。
オリジネータは、レシーバから応答を受け取った後、以下のステップを実施することができる：アナウンスされた属性が生成された場合、ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性が更新され、アナウンスされた属性の属性名が含まれるようになる。
ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性において新たにアナウンスする属性について、オリジネータはその値がアナウンスリソースにおいて同期されることにつき責任を有する。これは、１０．１．３節のＵＰＤＡＴＥ動作を用いることによる。
Figure 0006514315
例４
１０．２．１８．９ 元リソースホストＣＳＥが属性をアナウンス失効する手順
本節は、元リソースをホストしているＣＳＥが遠隔アナウンスリソースにおいてアナウンスされた属性を削除する手順を記載している（すなわち属性アナウンス失効）。
オリジネータ：このリクエストのオリジネータは、元リソースをホストしているＣＳＥである。オリジネータは、１０．１．４節が規定するＤＥＬＥＴＥリクエストを用いることにより、アナウンスされた属性を削除することを要求できる。
レシーバ：オリジネータが認証されると、レシーバ（アナウンスされたリソースをホストしているＣＳＥ）はリクエストを検証した後、リクエストを許可することができる。レシーバは以下を実施することができる：
１０．１．４節の部分アドレシング手順にしたがってアナウンス失効された属性を削除する。
１０．１．４節の適切なＤＥＬＥＴＥ応答でオリジネータに対して応答する。
オリジネータはレシーバから応答を受け取った後、以下のステップを実施することができる：アナウンス失効された属性が削除された場合、ａｎｎｏｕｎｃｅｄＡｔｔｒｉｂｕｔｅ属性を更新して、アナウンス失効した属性の属性名を削除することができる。
Figure 0006514315
現行ｏｎｅＭ２Ｍ規格に対する変形
ｏｎｅＭ２Ｍにおける部分アドレシングのサポートを提案する。部分アドレシングを提案して、ＵＰＤＡＴＥおよびＤＥＬＥＴＥ動作を用いることによりサポートする。
例５
８．１．１ 説明
図５は、手順内の情報交換をカバーする通信の一般的フローを示す図である。これはリクエストと応答の方式を用いることに基づいている。この方式は以下のような通信に適用される：
ＡＥとＣＳＥとの間（Ｍｃａ参照ポイント）；および
ＣＳＥ間（Ｍｃｃ参照ポイント）
通信は、リクエストメッセージの動作にしたがって、ＡＥまたはＣＳＥいずれかによって開始される。
８．１．２ 応答
オリジネータからのリクエストは、以下の情報を含む：
ｔｏ：動作のターゲットリソースまたはターゲット属性のＵＲＩ。ｔｏ情報は９．３．１節に合致する。
ｔｏターゲットリソースまたはターゲット属性は、オリジネータが知る必要がある。これは事前準備によってまたはディスカバリによって知ることができる。
用語ターゲットリソースは、特定の動作が対処するリソースのことを指す。例えばリソース“ｅｘａｍｐｌｅ”に対するＣｒｅａｔｅ動作のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ”となる。同じリソース“ｅｘａｍｐｌｅ”に対するＲｅｔｒｉｅｖｅ動作のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ／ｅｘａｍｐｌｅ”となる。ＲＥＴＲＩＥＶＥ動作で特定の属性を対処する際に用いるとき、上述の例における“ｃｏｎｔａｉｎｅｒ”属性のパラメータは、“／ｍ２ｍ．ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｅｘａｍｐｌｅＢａｓｅ／ｅｘａｍｐｌｅ／ｃｏｎｔａｉｎｅｒ”となる。
ｆｒ：オリジネータを表すＩＤ
レシーバはｆｒ情報を用いて、オリジネータＩＤが特権アクセスできるかチェックすることができる。
ｃｎ：送信するリソースコンテンツ
ｏｐ：実行すべき動作：Ｃｒｅａｔｅ（Ｃ）、Ｒｅｔｒｉｅｖｅ（Ｒ）、Ｕｐｄａｔｅ（Ｕ）、Ｄｅｌｅｔｅ（Ｄ）。
ｏｐ情報は、レシーバにおいて実行すべき動作を示すことができる。
Ｃｒｅａｔｅ（Ｃ）：ｔｏパラメータで処理できる新しいリソースが生成される。
Ｒｅｔｒｉｅｖｅ（Ｒ）：既存のｔｏ処理可能リソースが読み取られ、オリジネータに対して提供される。
Ｕｐｄａｔｅ（Ｕ）：既存のｔｏ処理可能リソースのコンテンツがｃｎパラメータの新たなコンテンツで置き換えられる。ｃｎパラメータの属性がターゲットリソースにおいて存在しない場合、その属性は割り当てられた属性で生成される。
Ｄｅｌｅｔｅ（Ｄ）：既存のｔｏ処理可能リソースとその全てのサブリソースが、リソースストレージから削除される。特定の属性を処理するｔｏパラメータについて、その属性はリソースストレージから削除される。
Ｎｏｔｉｆｙ（Ｎ）：レシーバに対する情報、レシーバにおける処理はオリジネータによって示されない。
以下の動作について、ｔｙ情報をリクエスト内に含めることができる：
Ｃｒｅａｔｅ：ｔｙは生成するリソースのタイプである。
ｃｎ：送信するリソースコンテンツ。
以下の動作について、ｃｎ情報をリクエスト内に含めることができる：
Ｃｒｅａｔｅ：ｃｎは新しいリソースのコンテンツである。リソースタイプタグは表９．２−１のものである。
Ｕｐｄａｔｅ：ｃｎは既存リソースにおいて置き換えるコンテンツである。ｃｎは、ｔｏパラメータが指定するリソースにおいて生成する属性について、対応する値とともに新たな属性を含むこともできる。
Ｒｅｔｒｉｅｖｅ：ｃｎは、ディスカバリ目的で適用されるフィルタである。
Ｎｏｔｉｆｙ：ｃｎは通知情報である。
ｃｎ情報は空であってもよい。
その他用いることができる情報は以下の通りである：
ｎｍ：生成するリソースのオプション名。
名称の使用例としては、新たに生成するリソースのＩＤとしてＣｒｅａｔｅリソースのオリジネータが使用希望する名称が挙げられる。名称“ｍｙＣｏｎｔａｉｎｅｒ”を有するｃｏｎｔａｉｎｅｒを生成する際に、リクエストはパラメータｎｍの値を“ｍｙＣｏｎｔａｉｎｅｒ”とし、生成されるリソースは：／＜ＳＣＥＢａｓｅ＞／ｍｙＣｏｎｔａｉｎｅｒである。
ｏｔ：メッセージが構築されたときのオプション送信元タイムスタンプ。
送信元タイムスタンプの使用例としては以下が挙げられる：動作を測定および有効化する（例：メッセージログ、相関、メッセージ優先順位付け／スケジューリング、パフォーマンス受諾リクエスト、変更、など）、パフォーマンスを測定する（配信および処理レイテンシ、閉ループレイテンシ、ＳＬＡ、分析、など）。
ｒｑｅｔ：オプションリクエストメッセージ期限タイムスタンプ。
リクエスト期限タイムスタンプの使用例は以下を含む：リクエストが古くなって値の意味をなさず期限切れになるとき（遅延耐性を含む）を示す、メッセージスケジューリング／優先順位付けを通知する。リクエストが特定時刻にリクエスト期限タイムスタンプをセットし、リクエストを現在処理しているＣＳＥではないホストＣＳＥにおける動作をリクエストが要求する場合、現在のＣＳＥはリクエスト期限タイムスタンプまでリクエストをホストＣＳＥに対して配信し続けようとする。これは準備したポリシにしたがってなされる。
ｒｓｅｔ：オプション結果メッセージ期限タイムスタンプ。
結果期限タイムスタンプの使用例は以下を含む：結果が古くなって値の意味をなさず結果メッセージが期限切れになるとき（遅延耐性を含む）を示す、メッセージスケジューリング／優先順位付けを通知する。最大許可総リクエスト／結果メッセージシーケンスラウンドトリップ期限をセットするために用いることができる。
ｒｔ：オプション応答メッセージタイプ：発行したリクエストに対する応答内容と、いつ応答をオリジネータに対して送信したかを示す。
Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：ローカルＣＳＥが応答を受け取った場合、ローカルＣＳＥはＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔで受け取った後に応答する。これは、ローカルＣＳＥがさらにリクエストを処理することを確認するものである。
Ｒｅｓｕｌｔ：ローカルＣＳＥが応答を受け取った場合、ローカルＣＳＥは要求された動作が完了すると要求された動作の結果を応答する。
Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔにセットする応答タイプの使用例：通信時間とエネルギー消費を最小化するように最適化されたオリジネータは、ローカルＣＳＥに対して応答を通知しようとし、リクエストが受け取られたか否かの確認応答を取得する。その後、オリジネータは低パワー消費モードへスイッチし、後時刻において要求した動作の結果を取得する。
ｒｄ：オプション結果メッセージ宛先。
ローカルＣＳＥ：ローカルＣＳＥは、受け取ったリクエストに対する応答において、リクエストのステータスと要求した動作の結果にアクセスするために後時刻において用いることができる参照情報を含む。
オリジネータ：要求した動作の結果は、オリジネータに対する通知として送信する必要がある。
ローカルＣＳＥに対してセットする結果宛先の使用例は以下を含む：結果コンテンツが非常に大きい場合、または結果が非同期で集約されたターゲットグループからの複数のコンテンツ部分を含む場合。
ｒｃ：オプション結果メッセージコンテンツ：要求した動作の結果の期待されるコンポーネントを示す。リクエストのオリジネータは、動作の結果を全く必要としない場合がある。これはｒｃ情報に示すことができる。ｒｃを正確にセットすることができるかは、ｏｐが指定する要求動作に依拠する。ｒｃの値として取り得るものは以下である：
“ｒｅｓｏｕｒｃｅ”：要求したリソース表現のみがコンテンツとして戻される。要求したリソースの他リソースに対するリンクは言及されない。これはデフォルト値である。
“ｒｅｓｏｕｒｃｅ；ｌｉｎｋｓ”：他リソースに対する全てのリンクとともに（取得したリンクの最大数によって制限され得る）、要求したリソースの表現が、コンテンツとして戻される。
“ｌｉｎｋｓ”：要求されたリソースの他リソースに対するリンクのみが（取得したリンクの最大数によって制限され得る）、要求したリソースの実物なしで、コンテンツとして戻される。
“ｎｏｔｈｉｎｇ”：応答のコンテンツとして何も戻されない。
“ｒｅｓｕｌｔ−ｎｏｔｉｆｉｃａｔｉｏｎ”：動作が完了すると通知が戻される。
注：ｒｃについてどのような設定が可能かについての詳細は、後に要求可能な特定の動作が定義されたとき、追加することができる（例：ＡＥを登録する、ｃｏｎｔａｉｎｅｒのコンテンツを変更する、など）。
ｒｐ：オプション応答持続性：応答を含むアドレスが持続する期間を示す。
応答持続の使用例は以下を含む：非同期で集約した応答コンテンツを分析処理するのに十分な持続期間を要求する。結果期限タイムスタンプが指定された場合、応答持続は応答期限を超えて存続すべきである。
ｒｉ：リクエストＩＤ
リクエストＩＤの使用例は、リクエストと多数の受信した応答との間の相関を可能にすることを含む。
ｏｅｔ：オプション動作実行時間：ターゲットＣＳＥによって特定の動作ｏｐが実行される時間を示す。ターゲットＣＳＥは、動作実行時間から開始する動作実行時間がセットされたリクエストの特定の動作を実行する。実行時間が既に過ぎるかまたはセットされていない場合、指定された動作は、セットされたリクエスト期限に達していない限り、即時実行される。
動作実行時間の使用例は、フローの非同期分散を含む。これは動作実行時刻において同期実行される。
ＮＯＴＥ４：時刻ベースフローは、ＣＳＥにおいて利用可能な時刻サービスによってはサポートできない場合がある。
ｅｃ：オプションイベントカテゴリ：このリクエストを取り扱うために用いるべきイベントカテゴリを示す。イベントカテゴリは、遠隔ホストされているリソースに対してアクセスするリクエストがＣＭＤＨ ＣＳＦにおいてどのように処理されるかに影響する。ＣＭＤＨを介する接続の選択とスケジューリングは、イベントカテゴリを区別するポリシによって制御される。
特定値Ｘにセットされた“イベントカテゴリ”の使用例は以下を含む：リクエストがローカルＣＳＥとは異なるホストＣＳＥ上で実行する動作を要求しているとき、リクエストはホストＣＳＥへの途中で現在リクエストを処理しているＣＳＥに格納される。これは、そのイベントカテゴリＸについて準備したポリシによって通信リンクを使用してホストＣＳＥに至る過程の次のＣＳＥに到達することが許可されるまで、またはリクエスト期限タイムスタンプが超過するまでである。
ｄａ：オプション配信集約ｏｎ／ｏｆｆ：＜ｄｅｌｉｖｅｒｙ＞リソースのＣＲＵＤ動作を用いて、１以上の元リクエストを同じターゲットＣＳＥへ転送することを表す。
ｄａはオプションであるので、リクエスト内に存在しない場合のデフォルト値が存在する。このパラメータは、Ｍｃａを介してＡＥに公開されない場合がある。
配信集約をｏｎにセットする使用例は以下を含む：リクエストを処理するＣＳＥは、ターゲットＣＳＥへの途中の次のＣＳＥ上で＜ｄｅｌｉｖｅｒｙ＞リソースのＣＲＥＡＴＥを要求することにより、同じターゲットＣＳＥに対するリクエストの集約を用いることができる。
ｇｉｄ：オプショングループリクエストＩＤ：グループメンバそれぞれに対して広がるグループリクエストに対して追加されるＩＤである。
ｆｃ：オプションフィルタ条件：フィルタリングした取得動作の条件を表８．１．２−１に示す。
Figure 0006514315
ＨＴＴＰクエリにおけるフィルタ条件の使用例は以下を含む：ＨＴＴＰ ＧＥＴ動作をリクエストし、リクエスト自身のクエリ部分のフィルタを適用することができる：
GET /root?label=one&label=two&createdBefore=2014-01-01T00:00:00&limit=128
例えば以下の論理条件に合致する最大１２８個のリソースを発見できる：ｃｒｅａｔｅｄＢｅｆｏｒｅ＜２０１４−０１−０１Ｔ００：００：００ ＡＮＤ （ｌａｂｅｌ＝ｏｎｅ ＯＲ ｌａｂｅｌ＝ｔｗｏ）
リクエストが配信されると、レシーバはリクエストを分析してターゲットリソースを判定する。
ターゲットリソースが他のＭ２Ｍモジュールによって処理されている場合、レシーバはリクエストを適切にルーティングする。
ターゲットリソースがレシーバによって処理されている場合、以下を実施できる：
ｔｏアドレスリソースの存在をチェックする。
表９．２−１のタグ値でリソースタイプを識別する。
ｆｒオリジネータが要求された動作を実施する権限をチェックする。
上述のように提供されたリクエストパラメータにしたがって要求された動作（ｃｎコンテンツが提供される場合はこれを用いて）を実施する。
リクエスト結果コンテンツに応じて、動作結果が成功または失敗したことを示して、オリジネータに対して応答する。特定の場合において（例：バインディングプロトコルの制約またはアプリケーション指示に基づき）、応答を回避できる。
オリジネータリクエストから開始したメッセージフロー手順は、以下の場合に完了したとみなすことができる：
ｒｑｅｔ（リクエスト期限タイムスタンプ）にしたがってリクエストメッセージが期限切れになった。
応答メッセージがオリジネータに配信された。
８．１．２．１ リクエストメッセージパラメータの概要
表８．１．２．１−１は、８．１．２節のリクエストメッセージのパラメータの概要である。Ｃ、Ｒ、Ｕ、Ｄ、Ｎ動作の違いを示す。“Ｍ”は固定を示す。“Ｏ”はオプションであることを示す。“Ｎ／Ａ”は“適用しない”を示す。
Figure 0006514315
Figure 0006514315
例６
８．１．３ 成功動作
要求した動作が成功した場合、そのリクエストのレシーバからオリジネータに対する応答は以下の情報を含む：
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによりトリガされた動作の結果を応答する場合、“ｒｄ”情報を用いることができる。
ｆｒ：オプション。レシーバのＩＤ。
ｒｓ：動作結果：例：Ｏｋａｙ、Ｏｋａｙ ａｎｄ Ｄｏｎｅ；Ｏｋａｙ ａｎｄ Ｓｃｈｅｄｕｌｅｄ；Ｏｋａｙ ａｎｄ Ｉｎ Ｐｒｏｇｒｅｓｓ、など。
ｃｎ：送信または生成するオプションリソースコンテンツ（オプション）。
メタ情報は以下を含む：
ｏｔ：メッセージが構築されたときのオプション元タイムスタンプ。
ｒｓｅｔ：オプション結果期限タイムスタンプ。レシーバは、リクエストメッセージにセットされている場合は結果期限タイムスタンプを繰り返し、あるいは結果期限タイムスタンプそのものをセットする。
レシーバが結果期限タイムスタンプをセットする例：配信時刻の値が変化するレシーバコンテキストに依拠する場合。例：速度に基づく航空機位置の結果メッセージデッドライン。
ｒｉ：リクエストＩＤ
レスポンスのｒｉは、対応するリクエストのｒｉと合致する。
ｃｓ：オプション、状態コード（例：認証タイムアウトなど）。
ｒａ：オプション、エンドノード応答の一時ストレージのアドレス。
ｃｎ情報は、以下の場合において応答内に含まれる：
Ｃｒｅａｔｅ：ｃｎは、生成したリソースのアドレスおよび／またはコンテンツである。
Ｕｐｄａｔｅ：ｃｎは、既存リソースにおいて置き換えるコンテンツである。ｃｎは、新たに生成した属性とその値である。
Ｄｅｌｅｔｅ：ｃｎは、実際に削除するコンテンツである。
ｃｎ情報は、以下の場合において応答内に含まれる：
Ｒｅｔｒｉｅｖｅ：ｃｎは、取得したリソースコンテンツまたは発見したリソースの集約したコンテンツである。
８．１．４ 失敗動作
リクエストのレシーバからリクエストのリジネータに対する応答は、要求した動作が失敗した場合、以下の情報を含む：
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによりトリガされた動作の結果を応答する場合、“ｒｄ”情報を用いることができる。
ｆｒ：オプション。レシーバのＩＤ。
ｒｓ：動作結果：例：Ｎｏｔ Ｏｋａｙ。
ｃｎ：オプション、状態コード（例：認証、タイムアウト、など）。
メタ情報は以下を含む：
ｏｔ：メッセージが構築されたときのオプション元タイムスタンプ。
ｒｓｅｔ：オプション結果期限タイムスタンプ。
ｒｉ：リクエストＩＤ
レスポンスのｒｉは、対応するリクエストのｒｉと合致する。
ｃｓ：オプション、状態コード（例：認証タイムアウトなど）。
８．１．５ 応答メッセージパラメータの概要
表８．１．５−１は、応答メッセージについての８．１．１節と８．１．３節が規定するパラメータの概要である。成功したＣ、Ｒ、Ｕ、Ｄ、Ｎ動作、および失敗動作の違いを示す。“Ｍ”は固定を示す。“Ｏ”はオプションであることを示す。“Ｎ／Ａ”は“適用しない”を示す。
Figure 0006514315
例７
１０．１．３ ＵＰＤＡＴＥ（Ｕ）
ＵＰＤＡＴＥ動作は、ターゲットリソースにおいて格納している任意の属性の情報を更新するために用いることができる。更新はタイミングよく実施する必要がある。例えば“ＥｘｐｉｒａｔｉｏｎＴｉｍｅ”情報更新に失敗すると、リソースを削除することになる。オリジネータＣＳＥまたはＡＥは、リクエストメッセージ内に属性とその値を含めることにより、ターゲットリソースにおいて特定の属性の更新または生成をリクエストすることができる。
オリジネータは、ＵＰＤＡＴＥリクエストメッセージを用いることにより、ターゲットリソースにおける任意属性の更新をリクエストする。オリジネータは、更新する必要がある属性の新たな（提案する）値を送信する。ＵＰＤＡＴＥ動作により、特定のリソースタイプについて、“ＲＷ”（Ｒｅａｄ Ｗｒｉｔｅ）指定されている属性（９．６節に規定）を変更することができる。
オリジネータは、ＵＰＤＡＴＥリクエストメッセージを用いることにより、ターゲットリソースにおいて属性を生成するようリクエストする。オリジネータは、特定のリソースタイプについて、“ＲＷ”（Ｒｅａｄ Ｗｒｉｔｅ）指定されている生成すべき属性（９．６節に規定）の名称および関連する値を、リクエストメッセージで送信することができる。
リクエストメッセージに含まれる情報について８．１．２節 参照
レシーバは、オリジネータが認証されると、アドレスリソースの存在を検証し（提供される属性とこれを変更する権限の妥当性）、提供される属性を更新し、８．１．３節にしたがってオリジネータに対して動作結果の応答メッセージを返信する。提供された属性が存在しない場合、アドレスリソースの存在を検証した後、レシーバは提供された属性とこれを生成する権限を検証する。検証成功した場合、レシーバは提供された属性を関連する値とともに生成し、８．１．３節にしたがって動作結果をオリジネータに対して応答メッセージを返信する。
図６は、リソースを取得する手順の例を示す。ステップ００１において、オリジネータはリソースの取得をリクエストする。ステップ００２において、レシーバはリクエストを処理する。ステップ００３において、レシーバは取得リクエストに対して応答メッセージで応答する。
図７は、リソースを更新する手順の例である。ステップ００１において、オリジネータはＵＰＤＡＴＥリクエストメッセージ内で以下の情報を送信する。
ｏｐ：Ｕ（Ｕｐｄａｔｅ）
ｔｏ：ターゲットリソースのＵＲＩ
ｆｒ：オリジネータのＩＤ（ＡＥまたはＣＳＥ）
ｃｎ：ターゲットリソースにおいて更新または生成する属性に関する情報。ｃｎパラメータにおける属性の名称と関連する更新値または割当値。
ステップ００２において、レシーバはオリジネータがターゲットリソースを変更する適切な権限を有しているかを検証する。検証成功すると、レシーバはリソースを要求されたように更新する。提供された属性が存在しない場合、レシーバはオリジネータがターゲットリソースにおいて属性を生成する適切な権限を有しているかを検証する。検証成功した場合、レシーバは当該リソースにおいて関連する値で属性を生成する。
ステップ００３において、レシーバは以下の情報を含む応答メッセージを返信する：
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによってトリガされた動作の結果を応答する場合、ｒｄ情報を用いることができる。
ｆｒ：オプション。レシーバのＩＤ。
ｒｓ：動作結果
ｃｎ：オプション。置換または生成するコンテンツ。
一般例外：
ｔｏ情報におけるターゲットリソースが存在しない。レシーバはエラーを応答する。
オリジネータは、レシーバにおいてリソースを変更しまたは属性を生成する権限を有していない。レシーバはエラーを応答する。
ｃｎにおいて提供された情報がレシーバによって受け取られなかった。レシーバはエラーを応答する。
例８
１０．１．４ ＤＥＬＥＴＥ（Ｄ）
オリジネータＣＳＥまたはＡＥは、ＤＥＬＥＴＥ動作を用いて、レシーバＣＳＥにおけるリソースを削除することができる。
オリジネータＣＳＥまたはＡＥは、ＤＥＬＥＴＥ動作を用いて、レシーバＣＳＥにおけるターゲットリソースから特定の属性を削除することができる。
ＤＥＬＥＴＥ手順は、ターゲットリソースの関連する全情報を削除することを含む。
オリジネータは、ＤＥＬＥＴＥリクエストメッセージを用いることにより、リソースまたは属性を削除するようリクエストする。
レシーバは、オリジネータが認証されると、要求されたリソースまたは属性の存在と、そのリソースまたは属性を削除する権限を、検証する。
図８は、リソースまたは属性を削除する手順の例を示す。ステップ００１において：オリジネータはレシーバに対してＤＥＬＥＴＥリクエストメッセージを送信する。
ｏｐ：Ｄ（Ｄｅｌｅｔｅ）
ｔｏ： ターゲットリソースまたは属性のＵＲＩ
ｆｒ：オリジネータのＩＤ（ＡＥまたはＣＳＥ）
ステップ００２において、レシーバは要求されたリソースまたは属性の存在、およびオリジネータがリソース／属性を削除する適切な権限を有しているかを、検証する。リソースの削除について、検証成功すると、レシーバは子リソースをチェックし、全ての子リソースと親リソースの関連する関連する参照を削除し、リソース自身を削除する。属性の削除について、検証成功すると、レシーバはアドレス属性を削除する。
ステップ００３において、レシーバは以下の情報を含む応答メッセージを返信する：
ｔｏ：オプション。オリジネータのＩＤ。非ブロックリクエストによってトリガされた動作の結果を応答する場合、ｒｄ情報を用いることができる。
ｆｒ：オプション。レシーバのＩＤ。
ｒｓ：動作結果
一般例外：
ｔｏ情報のターゲットリソース／属性が存在しない。レシーバはエラーを応答する。
オリジネータは、レシーバにおけるリソース／属性を削除する権限を有していない。レシーバはエラーを応答する。
上述の変形例は、現行のｏｎｅＭ２Ｍ規格の特定セクションをどのように変更できるかの例を提供した。実施形態において、本文書が開示する技術の実装を示した。上述の変形例は、ｏｎｅＭ２Ｍが既定するリソースまたは属性メッセージを交換する現行手順に対する変更を開示している。これはＲｅｑｕｅｓｔ、Ｒｅｔｒｉｅｖｅ、Ｒｅｓｐｏｎｓｅ、Ｄｅｌｅｔｅ、Ｕｐｄａｔｅメッセージを含む。上述の変形例は、デバイスに対して送信しこれを受信したデバイスが解釈実行することにより、メッセージパラメータおよびパラメータを使用する方法に対する変更を提供している。
上記において参照するｏｎｅＭ２Ｍ規格は、実施形態を説明するための例として用いたものであり、本技術の範囲を限定するものではない。
図９に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースから情報を取得する方法６００は、アナウンスするリソースのアドレスを指定するとともにアナウンスするリソースのＩＤを含めることにより、情報取得リクエストを発行するステップ（６０２）；前記情報取得リクエストに応じて情報応答を受信するステップ（６０４）；前記受信した情報応答をローカルで処理するかまたは他Ｍ２Ｍデバイスに処理させるため転送するかを選択するステップ（６０６）；を有する。
図１０に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースから情報を取得する装置７００は、アナウンスするリソースのアドレスを指定するとともにアナウンスするリソースのＩＤを含めることにより、情報取得リクエストを発行するモジュール７０２；前記情報取得リクエストに応じて情報応答を受信するモジュール７０４；前記受信した情報応答をローカルで処理するかまたは他Ｍ２Ｍデバイスに処理させるため転送するかを選択するモジュール７０６；を備える。
図１１に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを削除する方法８００は、削除する属性が省略されたリソースの属性のリストを生成するステップ（８０２）；前記削除する属性をホストするＭ２Ｍノードに対して前記リストを送信するステップ（８０４）；を有する。方法８００は、図１〜図１０で説明した技術を用いることができる。
図１２に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを削除する装置９００は、削除する属性が省略されたリソースの属性のリストを生成するモジュール９０２；前記削除する属性をホストするＭ２Ｍノードに対して前記リストを送信するモジュール９０４；を備える。
図１３に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを生成する方法１０００は、元Ｍ２Ｍノードが生成した属性がリストされた生成リクエストを発行するステップ（１００２）；前記発行された生成リクエストに対する許可応答を受信するステップ（１００４）；を有する。方法１０００は、図１〜図１０で説明した技術を用いることができる。
図１４に示すように、実施形態において、Ｍ２Ｍ通信システムにおけるアナウンスされたリソースを生成するシステム１１００は、元Ｍ２Ｍノードが生成した属性がリストされた生成リクエストを発行するモジュール１１０２；前記発行された生成リクエストに対する許可応答を受信するモジュール１１０４；を備える。
Ｍ２Ｍ通信システムにおけるリソースを管理する技術を開示したことを理解されたい。
本文書が開示したものその他の実施形態、モジュール、および機能動作は、デジタル電子回路内、またはコンピュータソフトウェア、ファームウェア、ハードウェア内に実装することができる。これらは本文書が開示する構造およびその等価構造、さらにはこれらの１以上の組み合わせを含む。開示する実施形態およびその他の実施形態は、１以上のコンピュータプログラム製品として実装することができる。すなわち、コンピュータ読取可能媒体に記録され、データ処理装置が実行しまたはその動作を制御する、１以上のコンピュータプログラム命令のモジュールである。コンピュータ読取可能媒体は、機械読取可能記憶装置、機械読取可能記憶基板、メモリデバイス、機械読取可能伝搬信号を生成する合成物、またはこれらの１以上の組み合わせである。データ処理装置という用語は、全ての装置、デバイス、データ処理機械を包含する。これらは例えばプログラム可能プロセッサ、コンピュータ、マルチプロセッサまたはコンピュータを含む。装置は、ハードウェアに加えて、コンピュータプログラムの命令環境を生成するコードを含む。例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１以上の組み合わせを構成するコードである。伝搬信号は、人工生成された信号である。例えば、適当な受信装置に対して送信するために情報をコード化するように生成された、機械生成による電気的、光学的、または電磁的信号である。
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている）は、任意形態のプログラム言語で記述することができる。これはコンパイル言語またはインタプリタ言語を含み、任意形態で配布することができる。これはスタンドアロンプログラムまたはモジュール、コンポーネント、サブルーチン、その他のコンピュータ環境において使用するのに適したユニットを含む。コンピュータプログラムは、ファイルシステムに対応している必要はない。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語文書内に格納された１以上のスクリプト）を保持する、当該プログラム専用の単一ファイル内または複数協調ファイル（例えば、１以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）内におけるファイルの一部に格納することができる。コンピュータプログラムを配布して、１サイトに配置されまたは複数サイトをまたがって通信ネットワークによって相互接続配置された１以上のコンピュータによって実行することができる。
本文書において開示するプロセスとロジックフローは、１以上のコンピュータプログラムを実行する１以上のプログラム可能プロセッサによって実施して、入力データ上で動作し出力を生成することにより機能を実施することができる。プロセスとロジックフローは例えばＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）やＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）のような特定用途論理回路によって実施することもできる。装置はこれら回路として実装することもできる。
コンピュータプログラムを実行するのに適したプロセッサは、例えば汎用および特定用途マイクロプロセッサ、または任意タイプのデジタルコンピュータの１以上のプロセッサを含む。一般にプロセッサは、読取専用メモリまたはランダムアクセスメモリまたはこれら双方から命令とデータを受信する。コンピュータの必須要素は、命令を実施するプロセッサと、命令およびデータを格納する１以上のメモリデバイスである。一般にコンピュータはさらに、データを格納する１以上の大規模記憶デバイスを備え、またはこれらと動作可能に連結されデータを受信または送信する。例えば磁気ディスク、光磁気ディスク、または光ディスクである。しかしコンピュータはこれらデバイスを必ずしも備えなくともよい。コンピュータプログラム命令とデータを格納するのに適したコンピュータ読取可能媒体は、不揮発性メモリ、媒体、およびメモリデバイスの全ての形態を含む。これは例えば、ＥＰＲＯＭやＥＥＰＲＯＭのような半導体メモリデバイス、フラッシュメモリデバイス、例えば内部ハードディスクやリムーバブルディスクのような磁気ディスク、光磁気ディスク、ＣＤＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む。プロセッサとメモリは、特定用途論理回路内によって補充され、またはその内部に設けることができる。
本文書は詳細記述を含むが、これらは特許請求しまたはする可能性のある本発明の範囲に対する制約として解釈すべきではない。むしろ特定実施形態に固有の構成の記述として解釈すべきである。個々の実施形態の文脈において本文書が開示する特定要素は、単一実施形態の組み合わせにおいて実装することができる。これとは反対に、単一実施形態の文脈において開示する様々な要素は、複数の実施形態またはその任意の組み合わせにおいて個別に実装することができる。さらに、要素は特定の組み合わせにおいて動作することを説明し、そのように特許請求しているが、特許請求する組み合わせからの１以上の要素は場合によっては組み合わせから除去することができる。特許請求する組み合わせは、サブ組み合わせまたはサブ組み合わせの変形物とすることができる。同様に、図面内の動作は特定順序で示したが、所望結果を実現するために、そのような動作を図示する特定順序で実施することが必要であり、また全動作を実施することが必要であると解釈すべきではない。
数個の例と実装のみを開示した。開示内容に基づき、説明した例および実装に対する変形、修正、拡張、その他の実装をすることも可能である。

Claims (14)

  1. マシン対マシン（Ｍ２Ｍ）通信システムにおいてアナウンスされたリソースを生成する方法であって、
    生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するステップ、
    前記発行された生成リクエストに対する許可応答を受信するステップ、
    前記生成した属性に対する更新リクエストを発行するとともに、ターゲットリソース上に存在しない１以上の属性に対する更新リクエストを発行するステップであって、前記１以上の属性は前記更新リクエストのリソースコンテンツパラメータに含まれている、ステップ、
    前記発行した更新リクエストに対する許可応答を受信するステップであって、前記発行した更新リクエストに対する許可応答は、前記更新リクエストを発行したオリジネータにおいて前記生成した属性を更新することを許可する応答であり、前記発行した更新リクエストに対する前記許可応答は、前記１以上の属性を生成したことを示す応答メッセージを含む、ステップ、
    を有することを特徴とする方法。
  2. 前記更新リクエストは、前記ターゲットリソースのＵＲＩ、前記更新リクエストを発行したオリジネータのＩＤ、更新すべき前記生成した属性に関連する情報、または生成すべき前記１以上の属性に関する情報を含む
    ことを特徴とする請求項１記載の方法。
  3. 前記方法はさらに、前記発行した更新リクエストに対する前記許可応答を受信しなかった場合は前記ターゲットリソースにおける属性について別の生成リクエストを発行するステップを有する
    ことを特徴とする請求項１記載の方法。
  4. Ｍ２Ｍ通信システムにおいてアナウンスされたリソースを生成する装置であって、
    生成元Ｍ２Ｍノードが生成した属性がリストされている生成リクエストを発行するモジュール、
    前記発行された生成リクエストに対する許可応答を受信するモジュール、
    前記生成した属性に対する更新リクエストを発行するとともに、ターゲットリソース上に存在しない１以上の属性に対する更新リクエストを発行するモジュールであって、前記１以上の属性は前記更新リクエストのリソースコンテンツパラメータに含まれている、モジュール、
    前記発行した更新リクエストに対する許可応答を受信するモジュールであって、前記発行された更新リクエストに対する前記許可応答は、前記更新リクエストを発行したオリジネータにおいて前記生成した属性を更新することを許可する応答であり、前記発行した更新リクエストに対する前記許可応答は、前記１以上の属性を生成したことを示す応答メッセージを含む、モジュール、
    を備えることを特徴とする装置。
  5. 前記更新リクエストは、前記ターゲットリソースのＵＲＩ、前記オリジネータのＩＤ、更新すべき前記生成した属性に関連する情報、または生成すべき前記１以上の属性に関する情報を含む
    ことを特徴とする請求項４記載の装置。
  6. 前記装置はさらに、前記発行した更新リクエストに対する前記許可応答が受信されなかった場合は前記ターゲットリソースにおける属性について別の生成リクエストを発行するモジュールを備える
    ことを特徴とする請求項４記載の装置。
  7. 前記オリジネータは、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）を含む
    ことを特徴とする請求項１記載の方法。
  8. 前記オリジネータは、アプリケーションエンティティ（ＡＥ）または共通サービスエンティティ（ＣＳＥ）を含む
    ことを特徴とする請求項４記載の装置。
  9. 前記生成した属性は、前記更新リクエストのＯｐｔｉｏｎａｌ Ａｎｎｏｕｎｃｅｄ（ＯＡ）の属性と対応している
    ことを特徴とする請求項１記載の方法。
  10. 前記生成した属性は、前記更新リクエストのＯｐｔｉｏｎａｌ Ａｎｎｏｕｎｃｅｄ（ＯＡ）の属性と対応している
    ことを特徴とする請求項４記載の装置。
  11. 前記生成した属性に関する情報または前記生成すべき前記１以上の属性に関する情報は、前記生成した属性の名称と新たに提案する値を含む
    ことを特徴とする請求項２記載の方法。
  12. 前記生成した属性に関する情報または前記生成すべき前記１以上の属性に関する情報は、前記生成した属性の名称と新たに提案する値を含む
    ことを特徴とする請求項５記載の装置。
  13. 各前記生成した属性または各前記１以上の属性は、特定のリソースタイプについて読み書きアクセスできるように示されている
    ことを特徴とする請求項１記載の方法。
  14. 各前記生成した属性または各前記１以上の属性は、特定のリソースタイプについて読み書きアクセスできるように示されている
    ことを特徴とする請求項４記載の装置。
JP2017501103A 2014-03-18 2015-03-18 マシン対マシンネットワークにおけるリソースおよび属性管理 Active JP6514315B2 (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201461955180P 2014-03-18 2014-03-18
US61/955,180 2014-03-18
US201461974923P 2014-04-03 2014-04-03
US61/974,923 2014-04-03
US201461983411P 2014-04-23 2014-04-23
US61/983,411 2014-04-23
US201462005961P 2014-05-30 2014-05-30
US62/005,961 2014-05-30
PCT/US2015/021336 WO2015143086A1 (en) 2014-03-18 2015-03-18 Resource and attribute management in machine to machine networks

Publications (2)

Publication Number Publication Date
JP2017515430A JP2017515430A (ja) 2017-06-08
JP6514315B2 true JP6514315B2 (ja) 2019-05-15

Family

ID=54145292

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017501103A Active JP6514315B2 (ja) 2014-03-18 2015-03-18 マシン対マシンネットワークにおけるリソースおよび属性管理

Country Status (6)

Country Link
US (1) US10616048B2 (ja)
EP (1) EP3120499B1 (ja)
JP (1) JP6514315B2 (ja)
KR (1) KR101793204B1 (ja)
CN (1) CN106537841B (ja)
WO (1) WO2015143086A1 (ja)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104683289A (zh) * 2013-11-26 2015-06-03 中兴通讯股份有限公司 公共业务实体注册方法和系统
US10015684B2 (en) * 2013-12-01 2018-07-03 Lg Electronics Inc. Method and apparatus for managing specific resource in wireless communication system
CN104796922B (zh) * 2014-01-22 2019-07-09 中兴通讯股份有限公司 Cse的触发管理方法及装置、cse、承载网网元
CN105100002B (zh) * 2014-05-05 2019-05-07 中兴通讯股份有限公司 属性的操作方法及装置
CN107211006B (zh) * 2015-01-07 2020-06-02 华为技术有限公司 响应消息处理方法、装置及系统
WO2016141590A1 (zh) * 2015-03-12 2016-09-15 华为技术有限公司 时序数据处理方法及装置
KR101931858B1 (ko) * 2015-07-09 2018-12-24 주식회사 케이티 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
CN107852408A (zh) * 2015-07-17 2018-03-27 Lg 电子株式会社 在无线通信系统中保持资源同步的方法及其装置
KR20180048845A (ko) 2015-09-01 2018-05-10 콘비다 와이어리스, 엘엘씨 서비스 계층 등록
CN113434780A (zh) * 2015-09-23 2021-09-24 康维达无线有限责任公司 增强的restful操作
CN106658348A (zh) * 2015-10-28 2017-05-10 西安中兴新软件有限责任公司 监控资源管理的方法、装置和cse
CN109155789B (zh) * 2016-03-04 2022-01-14 康维达无线有限责任公司 用于服务层中的请求处理的方法、装置和存储介质
WO2017155162A1 (ko) * 2016-03-07 2017-09-14 엘지전자 주식회사 무선 통신 시스템에서 접근 제어 정책 자원을 어나운스하기 위한 방법 및 이를 위한 장치
CN107317785B (zh) 2016-04-26 2021-04-23 京东方科技集团股份有限公司 应用实体创建资源和注册方法、通信节点设备及终端设备
US10270815B1 (en) * 2016-06-07 2019-04-23 Amazon Technologies, Inc. Enabling communications between a controlling device and a network-controlled device via a network-connected device service over a mobile communications network
CN107567006A (zh) * 2016-06-30 2018-01-09 中兴通讯股份有限公司 M2m应用的信息方法、cse及ae
KR102224379B1 (ko) 2016-10-07 2021-03-08 콘비다 와이어리스, 엘엘씨 일반적 상호연동 및 확장성을 위한 서비스 계층 리소스 관리
WO2018066917A1 (ko) * 2016-10-07 2018-04-12 주식회사 케이티 M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치
US10791443B2 (en) * 2017-03-03 2020-09-29 Verizon Patent And Licensing Inc. System and method for enhanced messaging using external identifiers
WO2018236137A1 (ko) * 2017-06-20 2018-12-27 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR101852727B1 (ko) 2017-07-28 2018-04-27 전자부품연구원 크로스-리소스 구독 관리 방법
CN108206856B (zh) * 2017-09-30 2021-11-30 中兴通讯股份有限公司 信息反馈方法及装置
KR20190054653A (ko) * 2017-11-14 2019-05-22 전자부품연구원 M2m 시스템에서의 액션 트리거링 방법
CN109819006B (zh) * 2017-11-22 2022-08-09 京东方科技集团股份有限公司 对目标资源进行操作的方法、节点设备和终端装置
WO2019231020A1 (ko) * 2018-05-31 2019-12-05 전자부품연구원 M2M 플랫폼에서 Request Reachability 관리 방법
WO2020009797A1 (en) * 2018-07-06 2020-01-09 Convida Wireless, Llc Efficient resource representation exchange between service layers
US20220164239A1 (en) * 2019-05-13 2022-05-26 Hyundai Motor Company Method and device for deleting resource in m2m system
KR20210139154A (ko) * 2020-05-13 2021-11-22 현대자동차주식회사 M2m 시스템에서 자원 오프로딩을 위해 동기화하기 위한 방법 및 장치
US11792165B2 (en) 2021-06-04 2023-10-17 Bank Of America Corporation Supporting data processing transactions using machine to machine (M2M) data transfer
US11784981B2 (en) 2021-06-04 2023-10-10 Bank Of America Corporation Data processing transactions using machine to machine (M2M) data transfer
US11265370B1 (en) * 2021-07-27 2022-03-01 Bank Of America Corporation Machine to machine (M2M) data transfer between data servers

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003575B2 (en) * 2001-10-15 2006-02-21 First Hop Oy Method for assisting load balancing in a server cluster by rerouting IP traffic, and a server cluster and a client, operating according to same
US7568219B2 (en) * 2002-01-08 2009-07-28 Bottomline Technologies (De), Inc. Transfer server of a secure system for unattended remote file and message transfer
US20120044865A1 (en) 2010-08-20 2012-02-23 Industrial Technology Research Institute Apparatus And Method For Coupling An M2M Device To A Wireless Network
WO2012068465A1 (en) 2010-11-19 2012-05-24 Interdigital Patent Holdings, Inc. Machine-to-machine (m2m) interface procedures for announce and de-announce of resources
US20120131168A1 (en) * 2010-11-22 2012-05-24 Telefonaktiebolaget L M Ericsson (Publ) Xdms for resource management in m2m
JP5894193B2 (ja) * 2011-02-11 2016-03-23 インターデイジタル パテント ホールディングス インコーポレイテッド マシンツーマシン（ｍ２ｍ）エンティティを管理するシステム、方法、および装置
CN102186164B (zh) 2011-02-18 2014-04-02 华为技术有限公司 操作设备资源的方法和管理装置
EP3761683A1 (en) 2012-01-13 2021-01-06 IOT Holdings, Inc. Method and apparatus for supporting machine-to-machine communications
TWI613897B (zh) * 2012-02-03 2018-02-01 內數位專利控股公司 支援m2m內容及上下文為基礎服務的方法及裝置
WO2013176425A1 (ko) 2012-05-21 2013-11-28 주식회사 케이티 스케줄 폴링 방법 및 그 m2m 장치
WO2013179557A1 (ja) 2012-05-30 2013-12-05 パナソニック株式会社 無線装置
WO2014037054A1 (en) * 2012-09-10 2014-03-13 Telefonaktiebolaget L M Ericsson (Publ) Method and system for communication between machine to machine (m2m) service provider networks
EP2893720A1 (en) * 2012-09-10 2015-07-15 Telefonaktiebolaget L M Ericsson (PUBL) Method and system for communication between machine to machine m2m service provider networks
US10015684B2 (en) * 2013-12-01 2018-07-03 Lg Electronics Inc. Method and apparatus for managing specific resource in wireless communication system

Also Published As

Publication number Publication date
CN106537841A (zh) 2017-03-22
EP3120499A4 (en) 2017-11-15
CN106537841B (zh) 2019-11-15
KR101793204B1 (ko) 2017-11-02
KR20160130306A (ko) 2016-11-10
US10616048B2 (en) 2020-04-07
EP3120499A1 (en) 2017-01-25
WO2015143086A1 (en) 2015-09-24
EP3120499B1 (en) 2021-12-22
US20170099562A1 (en) 2017-04-06
JP2017515430A (ja) 2017-06-08

Similar Documents

Publication Publication Date Title
JP6514315B2 (ja) マシン対マシンネットワークにおけるリソースおよび属性管理
CN110383790B (zh) 无需会话连续性的网络服务连续性
US11297660B2 (en) Session management with relaying and charging for indirect connection for internet of things applications in 3GPP network
JP5805873B2 (ja) Ｍ２ｍデバイスサブスクリプションのための方法及び装置
JP6240312B2 (ja) Ｍ２ｍ通信システムにおいて購読及び通知のための方法及びそのための装置
KR101740449B1 (ko) M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
JP6456472B2 (ja) 複数のデバイス上での複数のコマンドの実行を可能にすることによるｍ２ｍシステムにおけるサービス層と管理層との間の拡張型動作
US10567925B2 (en) Enabling multicast for service layer group operation
KR101689614B1 (ko) M2m 시스템에서 위치 측정 방법 및 이를 위한 장치
US9883400B2 (en) Method for subscription and notification in M2M communication system and device therefor
EP3005659B1 (en) Load balancing in the internet of things
JP2018520598A (ja) モノのインターネットのための広域サービス発見
JP6453242B2 (ja) 機械対機械サービスレイヤ間の通信および送信ネットワーク
KR20170096632A (ko) 장치들에의 테넌시의 할당
JP7246379B2 (ja) 通信ネットワークにおけるサービス層メッセージテンプレート
EP3332513B1 (en) Service element host selection
CN111164951B (zh) 基于服务能力要求和偏好的服务注册
KR20180110456A (ko) oneM2M기반 서비스 연계를 위한 연동 시스템

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171128

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180524

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181214

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190312

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190411

R150 Certificate of patent or registration of utility model

Ref document number: 6514315

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250