JP6435057B2 - サービス層における交渉サービスをサポートする方法 - Google Patents

サービス層における交渉サービスをサポートする方法 Download PDF

Info

Publication number
JP6435057B2
JP6435057B2 JP2017547928A JP2017547928A JP6435057B2 JP 6435057 B2 JP6435057 B2 JP 6435057B2 JP 2017547928 A JP2017547928 A JP 2017547928A JP 2017547928 A JP2017547928 A JP 2017547928A JP 6435057 B2 JP6435057 B2 JP 6435057B2
Authority
JP
Japan
Prior art keywords
negotiation
negotiated
proposal
party
service
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.)
Expired - Fee Related
Application number
JP2017547928A
Other languages
English (en)
Other versions
JP2017537422A (ja
Inventor
チョンガン ワン,
チョンガン ワン,
リージュン ドン,
リージュン ドン,
デール エヌ. シード,
デール エヌ. シード,
ウィリアム ロバード ザ フォース フリン,
ウィリアム ロバード ザ フォース フリン,
グアン ルー,
グアン ルー,
ホンクン リ,
ホンクン リ,
チン リ,
チン リ,
シュウ リ,
シュウ リ,
カタリーナ エム. ムラディン,
カタリーナ エム. ムラディン,
ビノッド クマー チョイ,
ビノッド クマー チョイ,
Original Assignee
コンヴィーダ ワイヤレス, エルエルシー
コンヴィーダ ワイヤレス, エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コンヴィーダ ワイヤレス, エルエルシー, コンヴィーダ ワイヤレス, エルエルシー filed Critical コンヴィーダ ワイヤレス, エルエルシー
Publication of JP2017537422A publication Critical patent/JP2017537422A/ja
Application granted granted Critical
Publication of JP6435057B2 publication Critical patent/JP6435057B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/14Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1485Tariff-related aspects
    • H04L12/1492Tariff-related aspects negotiation of tariff
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5006Creating or negotiating SLA contracts, guarantees or penalties
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/562Brokering proxy services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Description

(関連出願の引用)
本願は、米国仮出願第62/986,102号(2014年12月1日出願)に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。
マシンツーマシン(M2M)技術は、有線および無線通信システムを使用して、デバイスが互いにより直接通信することを可能にする。M2M技術は、モノのインターネット(IoT)、固有に識別可能なオブジェクトのシステム、およびインターネット等のネットワークを経由して互いに通信するそのようなオブジェクトの仮想表現のさらなる実現を可能にする。IoTは、食料品店内の商品または家庭の電化製品等のありふれた毎日のオブジェクトとさえも通信を促進し、それによって、そのようなオブジェクトの知識を向上させることによって費用および無駄を削減し得る。例えば、店は、在庫にあり得るか、または販売された場合があり得るオブジェクトと通信するか、もしくはそこからデータを取得することができることによって、非常に精密な在庫データを維持し得る。
M2Mサービスノードおよびアプリケーションは、現在、M2Mサービス層からサービスを提供する/アクセスするために、静的構成または事前プロビジョニングに依拠する。すなわち、異なる時に特定のサービスの種々の特徴または機能性を動的に要求するため、非効率的なサポートしかない。例えば、既存のoneM2Mは、ミドルノード(MN)共通サービスエンティティ(CSE)がインフラストラクチャノード(IN)−CSEから記憶容量を動的に要求するための機構を提供しない。さらに、IN−CSEは、IN−アプリケーションエンティティ(AE)が管理することができるデバイスの数および/またはIN−AEが要求をIN−CSEに発行することができる頻度を管理するためのサービスを有していない。
静的構成は、スループットに直接影響を及ぼす。すなわち、サービスをM2Mアプリケーションに提供することにおけるM2Mサーバの柔軟性が、非常に限定される。したがって、事前構成されたサービスは、M2Mサーバおよび/またはM2Mデバイスのための最適な選択ではない場合がある。例えば、必要とされるサービスは、要件変更またはコンテキスト変更に起因して変化し得る(例えば、M2Mサーバが、より多くの登録されたデバイスを有すること、または、M2Mデバイスがより多くの通信制約を伴う新しい場所に移動すること)。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態における概要の選択を導入するように提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述の必要性は、M2Mサービス層における交渉サービスを向上させ、サービスを動的に要求するための能力を提供するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。
本願の一側面では、コンピュータ実装方法が説明される。方法は、被交渉側から受信される交渉可能なサービス層属性を精査するステップを含む。方法は、精査された属性に基づいて、交渉要求を被交渉側に送信するステップも含む。方法は、被交渉側から提示された提案を受信するステップも含む。一実施形態では、方法は、所定の交渉ポリシをチェックすることに応じて、提示された提案を選択するステップを含む。別の実施形態では、方法は、受信される提示された提案が、被交渉側の所定の交渉ポリシに対してチェックされるステップを含む。別の実施形態では、交渉要求のステップは、サービスid、提案を行うための入力、提案される提案、およびそれらの組み合わせから選択される情報を含む。別の実施形態によると、提示された提案は、提案、別の被交渉側との交渉推奨、およびそれらの組み合わせから選択される情報を含む。別の実施形態によると、交渉要求を送信するステップは、ブローカを介して被交渉側に送信される。さらなる実施形態によると、提示された提案を受信するステップは、ブローカを介して被交渉側から受信される。
本願の別の側面では、被交渉側から交渉可能なサービス層属性について交渉するためのポリシを受信するステップを含むコンピュータ実装方法が説明される。方法は、属性について交渉するための要求を交渉側から受信するステップも含む。方法は、要求が被交渉側ポリシの所定の基準に適合するかどうかを決定するステップも含む。さらに、方法は、提示された提案を交渉側に送信するステップを含む。一実施形態では、方法は、交渉側から交渉確認を受信するステップと、交渉確認の確認応答を被交渉側に送信するステップとを含む。
本願のさらに別の側面では、交渉側から交渉可能なサービス層属性に対する交渉要求を受信するステップを含むコンピュータ実装方法が説明されている。方法は、属性を有する被交渉側の場所を特定するステップも含む。方法は、交渉要求を被交渉側に送信するステップも含む。さらに、方法は、被交渉側から交渉可能なサービスに対する提示された提案を受信するステップを含む。ある実施形態によると、方法は、提示された提案を交渉側に送信するステップと、交渉側から交渉確認を受信するステップと、交渉確認の確認応答を被交渉側に送信するステップとを含む。
別の側面によると、コンピュータ実装装置が開示される。装置は、サービス属性について交渉するためのその上に記憶された命令を有する交渉サービス層を含む不揮発性メモリを含む。装置は、不揮発性メモリに動作可能に結合されるプロセッサも含む。プロセッサは、被交渉側から受信される属性を精査する命令を実施するように構成される。プロセッサは、精査された属性に基づいて、交渉要求を被交渉側に送信するようにも構成される。ある実施形態によると、プロセッサは、被交渉側から提示された提案を受信する命令を実施するようにさらに構成される。一実施形態では、コンピュータ実装装置は、不揮発性メモリおよびプロセッサに動作可能に接続されるユーザインターフェースを有するディスプレイを含む。
本願のさらに別の側面では、サービス属性の交渉のためのその上に記憶された命令を有する、交渉サービス層を含む不揮発性メモリを有するコンピュータ実装装置が説明される。装置は、不揮発性メモリに動作可能に結合され、(i)被交渉側から属性について交渉するためのポリシを受信し、(ii)属性について交渉するための要求を交渉側から受信し、(iii)要求が被交渉側ポリシの基準に適合するかどうかを決定する命令を実施するように構成されているプロセッサも含む。ある実施形態によると、プロセッサは、提示された提案を交渉側に送信する命令を実施するようにさらに構成される。一実施形態では、不揮発性メモリは、共通属性、作成、読み出し、削除、更新、実行、標識、ブローカ、タイプ、提案を行うための入力、提案を選択するための入力、開始、ステータス、標的、参照、提示された提案、選択された提案、出力パラメータ、サブスクリプション、およびそれらの組み合わせから選択される交渉リソースを記憶する。別の実施形態では、プロセッサは、属性について交渉するために交渉リソースを使用する。別の実施形態では、メモリは、共通属性、標識、交渉タイプ、交渉側、被交渉側、条件、結果、規則の選択、サブスクリプション、およびそれらの組み合わせから選択されるポリシリソースを記憶する。さらなる実施形態では、プロセッサは、属性について交渉するためにポリシリソースを使用する。一段とさらなる実施形態では、メモリは、共通属性、標識、クライアント、現在の交渉ブローカ、新しい交渉ブローカ、委託有効化、開始時間、持続時間、結果、サブスクリプション、およびそれらの組み合わせから選択される委託リソースを記憶する。その上さらなる実施形態では、プロセッサは、属性について交渉するために委託リソースを使用する。
本願のさらなる側面は、コンピュータ実装ネットワークを説明する。ネットワークは、交渉側と、被交渉側とを含む。交渉側および被交渉側の各々は、データを送信ならびに受信するための送受信機を含む。交渉側および被交渉側の各々は、サービス層属性について交渉するためのその上に記憶された命令とともに交渉サービス層を有する不揮発性メモリも含む。交渉側および被交渉側の各々は、サービス層属性の交渉を行うように構成されている、不揮発性メモリに動作可能に結合されるプロセッサも含む。ある実施形態によると、交渉側および被交渉側のメモリは、交渉リソース、ポリシリソース、委託リソース、およびそれらの組み合わせから選択されるリソースを含む。
その詳細な説明がより深く理解され得るために、かつ当該技術に対する本願の寄与がより明確に認識され得るために、本発明のある実施形態が、かなり大まかに上記で概説されている。
例えば本願は以下の項目を提供する。
(項目1)
コンピュータ実装装置であって、前記装置は、
不揮発性メモリであって、前記不揮発性メモリは、その上に記憶された命令を含み、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されたプロセッサと
を備え、
前記プロセッサは、
被交渉側から受信される前記属性を精査することと、
前記精査された属性に基づいて、交渉要求を前記被交渉側に送信することと、
前記被交渉側から提示された提案を受信することと
を行う命令を実施するように構成されている、コンピュータ実装装置。
(項目2)
前記プロセッサは、前記提示された提案を選択するようにさらに構成されている、項目1に記載のコンピュータ実装装置。
(項目3)
前記選択は、前記被交渉側の所定の交渉ポリシに対してチェックされる、項目2に記載のコンピュータ実装装置。
(項目4)
前記交渉要求を送信するステップは、ブローカを介して前記被交渉側に送信される、項目1に記載のコンピュータ実装装置。
(項目5)
前記提示された提案を受信するステップは、前記ブローカを介して前記被交渉側から受信される、項目4に記載のコンピュータ実装装置。
(項目6)
前記メモリおよび前記プロセッサに動作可能に接続されたグラフィカルユーザインターフェースを含むディスプレイをさらに備え、前記グラフィカルユーザインターフェース、は、前記提示された提案を表示するように構成されている、項目1に記載のコンピュータ実装装置。
(項目7)
前記ディスプレイ上の前記提示された提案は、提案、別の被交渉側との交渉推奨、およびそれらの組み合わせから選択される情報を含む、項目1に記載のコンピュータ実装装置。
(項目8)
コンピュータ実装装置であって、前記装置は、
不揮発性メモリであって、前記不揮発性メモリは、その上に記憶された命令を含み、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されたプロセッサと
を備え、
前記プロセッサは、
被交渉側から前記属性について交渉するためのポリシを受信することと、
前記属性について交渉するための要求を交渉側から受信することと、
前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと
を行う命令を実施するように構成されている、コンピュータ実装装置。
(項目9)
前記プロセッサは、提示された提案を前記交渉側に送信するようにさらに構成されている、項目8に記載のコンピュータ実装装置。
(項目10)
前記不揮発性メモリは、共通属性、作成、読み出し、削除、更新、実行、標識、ブローカ、タイプ、提案を行うための入力、提案を選択するための入力、開始、ステータス、標的、参照、提示された提案、選択された提案、出力パラメータ、サブスクリプション、およびそれらの組み合わせから選択される交渉リソースを記憶し、
前記プロセッサは、前記属性について交渉するために前記交渉リソースを用いる、
項目8に記載のコンピュータ実装装置。
(項目11)
前記メモリは、共通属性、標識、交渉タイプ、交渉側、被交渉側、条件、結果、規則の選択、サブスクリプション、およびそれらの組み合わせから選択されるポリシリソースを記憶し、
前記プロセッサは、前記属性について交渉するために前記ポリシリソースを用いる、
項目8に記載のコンピュータ実装装置。
(項目12)
前記メモリは、共通属性、標識、クライアント、現在の交渉ブローカ、新しい交渉ブローカ、委託有効化、開始時間、持続時間、結果、サブスクリプション、およびそれらの組み合わせから選択される委託リソースを記憶し、
前記プロセッサは、前記属性について交渉するために前記委託リソースを用いる、
項目8に記載のコンピュータ実装装置。
(項目13)
コンピュータ実装交渉側およびコンピュータ実装被交渉側を備えているネットワーク化システムであって、前記交渉側および前記被交渉側の各々は、
データを送信および受信するための送受信機と、
交渉サービス層を有する不揮発性メモリであって、前記不揮発性メモリは、その上に記憶されたサービス層属性について交渉するための命令を有する、不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されたプロセッサと
を含み、
前記プロセッサは、前記サービス層属性の交渉を行うように構成されている、
ネットワーク化システム。
(項目14)
前記プロセッサは、
被交渉側から前記属性について交渉するためのポリシを受信することと、
前記属性について交渉するための要求を交渉側から受信することと、
前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと
を行う命令を実施するように構成されている、項目13に記載のネットワーク化システム。
(項目15)
前記不揮発性メモリは、交渉リソース、ポリシリソース、委託リソース、およびそれらの組み合わせから選択されるリソースを含む、項目13に記載のネットワーク化システム。
(項目16)
コンピュータ実装方法であって、前記方法は、
被交渉側から受信される交渉可能なサービス層属性を精査することと、
前記精査された属性に基づいて、交渉要求を前記被交渉側に送信することと、
前記被交渉側から提示された提案を受信することと、
前記提示された提案を選択することと
含む、コンピュータ実装方法。
(項目17)
前記受信される提示された提案は、前記被交渉側の所定の交渉ポリシに対してチェックされる、項目16に記載の方法。
(項目18)
前記交渉要求は、サービスid、提案を行うための入力、提案される提案、およびそれらの組み合わせから選択される情報を含む、項目16に記載の方法。
(項目19)
コンピュータ実装方法であって、前記方法は、
被交渉側から交渉可能なサービス層属性について交渉するためのポリシを受信することと、
前記属性について交渉するための要求を交渉側から受信することと、
前記要求が前記被交渉側ポリシの所定の基準に適合するかどうかを決定することと、
提示された提案を前記交渉側に送信することと
を含む、コンピュータ実装方法。
(項目20)
前記交渉側から交渉確認を受信することと、
前記交渉確認の確認応答を前記被交渉側に送信することと
をさらに含む、項目19に記載の方法。
(項目21)
コンピュータ実装方法であって、前記方法は、
交渉側から交渉可能なサービス層属性に対する交渉要求を受信することと、
前記属性を有する被交渉側の場所を特定することと、
前記交渉要求を前記被交渉側に送信することと、
前記被交渉側から前記交渉可能なサービスに対する提示された提案を受信することと
を含む、コンピュータ実装方法。
(項目22)
前記提示された提案を前記交渉側に送信することと、
前記交渉側から交渉確認を受信することと、
前記交渉確認の確認応答を前記被交渉側に送信することと
をさらに含む、項目21に記載の方法。
本願のより確実な理解を促進するために、ここで、類似要素が類似数字で参照される、付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。
図1は、サービス層をサポートするプロトコルスタックを図示する。 図2は、共通サービスエンティティ(CSE)および共通サービス機能(CSF)を図示する。 図3Aは、oneM2Mサービス層アーキテクチャを図示する。 図3Bは、M2Mサービスコンポーネントアーキテクチャを図示する。 図4Aは、マシンツーマシン(M2M)またはIoT通信システムの実施形態を図示する。 図4Bは、M2Mサービスプラットフォームの本願の実施形態を図示する。 図4Cは、例示的M2Mデバイスの系統図の本願の実施形態を図示する。 図4Dは、例示的コンピュータシステムのブロック図の本願の実施形態を図示する。 図5Aは、本願のある側面による、交渉サービスを用いる動的サービスのアーキテクチャの図を図示する。 図5Bは、本願のある側面による、交渉ポリシを構成および表示するためのグラフィカルユーザインターフェースを図示する。 図6は、本願のある側面による、個々の交渉要求のためのサービス交渉プロトコルを図示する。 図7は、本願のある側面による、被交渉側において提案を行うための決定クエリを図示する。 図8は、本願のある側面による、交渉側において提案を選択するための決定クエリを図示する。 図9は、本願のある側面による、複数の交渉要求のためのサービス交渉のフローチャートを図示する。 図10は、本願のある側面による、透過モードにおけるブローカベースのサービス交渉のフローチャートを図示する。 図11は、本願の別の側面による、交渉の代理としてのブローカベースのサービス交渉のフローチャートを図示する。 図12は、本願の別の側面による、認証および承認プロトコルを用いたブローカベースのサービス交渉のフローチャートを図示する。 図13は、本願の別の側面による、交渉要求の組み合わせを用いるブローカベースのサービス交渉のフローチャートを図示する。 図14は、本願の別の側面による、ブローカベースのサービス委託のフローチャートを図示する。 図15は、CSFビットマップの例示的実施形態を図示する。 図16は、CSF特徴ビットマップの例示的実施形態を図示する。 図17は、本願のある側面による、交渉サービス(NGS)を含むoneM2Mアーキテクチャを図示する。 図18は、本願のある側面による、oneM2Mリソース指向アーキテクチャ(ROA)におけるNGS CSFを図示する。 図19は、本願の別の側面による、oneM2M ROAにおけるNGS CSFを図示する。 図20は、本願のある側面による、oneM2M<ngtn>リソースの構造を図示する。 図21は、本願のある側面による、oneM2M<ngtnPolicy>リソースの構造を図示する。 図22は、本願のある側面による、oneM2M<ngtnDelegation>リソースの構造を図示する。 図23は、本願のある側面による、MN−CSEとIN−CSEとの間のサービス交渉の例示的実施形態を図示する。 図24は、oneM2Mサービス指向アーキテクチャ(SOA)の中へ追加された交渉サービスの例示的実施形態を図示する。
発明を実施するための形態が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な実施例を提供するが、詳細は、実施例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。
本明細書における「一実施形態」、「ある実施形態」、「1つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも1つの実施形態に含まれることを意味する。本明細書内の種々の場所における「実施形態」という用語は、必ずしも同一の実施形態を指しているわけでもない。つまり、いくつかの実施形態によって提案され得るが、他の実施形態によって提案されない、種々の特徴が説明される。
本願は、サービスノードおよびアプリケーションが他のサービスノードまたはアプリケーションからサービスを動的に要求すること、およびそれを調節することに役立つ、サービス層における交渉サービス(NGS)等の新しい機能を用いるための技法を説明する。一実施形態では、交渉サービスによると、交渉側は、交渉要求を発行するM2Mエンティティであり、被交渉側は、交渉要求を受信し、提案を提供するM2Mエンティティである。被交渉側は、提案を行い、交渉側は、事前構成された交渉ポリシに基づいて、提案を選択する。これらのポリシベースの交渉プロセスは、M2Mシステムによく適しており、種々のサービスは、そのようなポリシベースの共通サービス機能を使用して、交渉されることができる。そのような機能は、提案を行うことと、異なるサービスについて交渉するために好適な提案を選択することとを含む。
一側面では、交渉側は、交渉プロセスを促進し、制約付きM2Mデバイスにとって特に有益である交渉オーバーヘッドを削減することに役立つ、ある提案を能動的に提案することができる。加えて、被交渉側は、交渉プロセス中、他の被交渉側を推奨することができ、それは、交渉成功率を向上させ、それはまた、全体的な交渉信号伝達オーバーヘッドを削減し得る。被交渉側は、全ての交渉側を満たすためのより知的な提案を行うために、複数の交渉側からの要求を組み合わせることもできる。
別の側面では、交渉ブローカは、交渉側および/または被交渉側の代理の役割を果たすことができるM2Mエンティティである。交渉ブローカは、交渉側と被交渉側との間で交渉関連メッセージを転送することもできる。これは、交渉タスクを交渉ブローカにオフロードすることによって、制約付きデバイスにおける交渉オーバーヘッドを軽減することに役立つ。一実施形態によると、交渉ブローカが対応する被交渉側を自動的に選定し得る、透過モードが説明される。透過モードにおいて、交渉ブローカは、制約付きM2Mデバイス(すなわち、交渉側)が被交渉側を自動的に選定することに役立ち得る。したがって、制約付きM2Mデバイスは、被交渉側の識別を把握する必要がない。透過モードでは、交渉ブローカは、制約付きM2Mデバイス(すなわち、交渉側)が被交渉側を自動的に選定することに役立つことができる。したがって、制約付きM2Mデバイスは、被交渉側を把握する必要がない。
代理モードにおいて、交渉ブローカは、交渉タスクを行う(例えば、提案を行う、提案を選択する)制約付きM2Mデバイスの代理の役割を果たすことができる。制約付きM2Mデバイスは、交渉結果を受信することのみを必要とする。提案されるブローカベースの交渉アプローチは、制約付きM2Mデバイスがより容易な様式で交渉を行うことに役立つ。このアプローチは、制約付きデバイスへ/からの通信オーバーヘッドを軽減することができる。
別の実施形態では、交渉ブローカが被交渉側の代わりに提案を行う、被交渉側のための代理が説明される。代理モードでは、交渉ブローカは、交渉タスクを行う(例えば、提案を行う、提案を選択する)制約付きM2Mデバイスの代理の役割を果たすことができる。
別の実施形態では、交渉ブローカ委託が、1つの交渉ブローカから別の交渉ブローカに交渉機能を委託するために提案される。被交渉側を推奨するための提案されるアイデアは、交渉成功率を向上させ、それにしたがってオーバーヘッドを削減することに役立つことができる。ある側面によると、複数の交渉要求を組み合わせて処理するための提案されるアイデアは、種々のM2Mアプリケーションからの交渉要求を共同で処理することができ、ひいては、交渉成功率を向上させ、交渉オーバーヘッドを低減させることに役立つ。
(サービス層)
プロトコルスタックの観点から、サービス層は、典型的には、アプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。したがって、サービス層は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図1は、IPネットワークスタックとアプリケーションとの間の例示的サービス層を示す。
M2Mサービス層は、M2M型デバイスおよびアプリケーションのための付加価値サービスを提供することに向けて特に標的化された1つのタイプのサービス層の実施例である。近年、いくつかの業界規格団体、例えば、oneM2Mは、インターネット/ウェブ、セルラー、企業、ならびにホームネットワーク等の展開へのM2Mタイプのデバイスおよびアプリケーションの統合に関連付けられる課題に対処するためのM2Mサービス層を開発している。
M2Mサービス層は、サービス層によってサポートされるM2M指向能力の集合へのアクセスをアプリケーションおよびデバイスに提供することができる。いくつかの実施例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含むが、それらに限定されない。これらの能力は、M2Mサービス層によって定義されるメッセージ形式、リソース構造、およびリソース表現を利用するAPIを介して、アプリケーションに利用可能にされる。
(OneM2Mサービス層アーキテクチャ)
OneM2Mは、共通M2Mサービス層に対する必要性に対処する技術仕様を開発するための新しい規格であり、共通M2Mサービス層は、種々のハードウェアおよびソフトウェア内に容易に組み込まれ、現場の多種多様なデバイスを世界中のM2Mアプリケーションサーバと接続するために依拠されることができる。
oneM2M共通サービス層は、図2に示されるように、共通サービス機能(CSF)、すなわち、サービス能力の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード、例えば、インフラストラクチャノード、中間ノード、特定用途向けノード上にホストされることができる共通サービスエンティティ(CSE)と称される。OneM2Mは、図3Aに示されるリソース指向アーキテクチャ(ROA)および図3Bに示されるサービス指向アーキテクチャ(SOA)と呼ばれる2つのアーキテクチャのアプローチでサービス層を開発している。
図3Aに示されるように、リソースは、アーキテクチャ内の固有にアドレス可能な要素であり、Create、Retrieve、Update、およびDelete等のRESTful方法を介して操作されることができる表現を有する。これらのリソースは、ユニフォームリソース識別子(URI)を使用して、アドレス可能にされる。リソースは、子リソースと、属性とを含み得る。子リソースは、親リソースと包含関係を有するリソースである。親リソース表現は、その子リソースの参照を含む。子リソースの存続期間は、親リソースの存続期間によって限定される。各リソースは、リソースの情報を記憶する、「属性」の組をサポートする。
SOAアーキテクチャは、RESTfulベースでない旧来の展開を考慮するように開発されている。図3Bに示されるように、それは、大部分は同一のサービス層機能アーキテクチャを再利用する。サービス層は、種々のM2Mサービスを含み、複数のサービスが、サービスコンポーネントにグループ化されることができる。既存の参照点に加えて、それは、サービス間参照点Mscを導入する。Msc参照点を経由してパスされるM2Mサービスコンポーネント間の通信は、ウェブサービスアプローチ、例えば、ウェブサービスメッセージ交換パターン(MEP)を利用する。
(OneM2M CSF)
M2MサーバまたはエンドポイントM2Mデバイス等のCSEによって、他のCSEもしくはAEに提供されることができる、以下の12個のCSFが、現在、oneM2Mで定義されている。これらは、図2に示されている。
アプリケーションおよびサービス層管理(ASM):CSEならびにAEの機能を構成、トラブルシュート、およびアップグレードする管理能力を提供する。
通信管理および配信取扱(CMDH):通信、例えば、CSE間通信を配信するための具体的通信接続を使用すべきとき、必要かつ許可される場合、後に転送されることができるように通信要求をバッファリングするときを決定する。
データ管理およびリポジトリ(DMR):データ記憶および仲介機能を提供する責任がある。それは、大量のデータを集約し、このデータを規定形式に変換し、分析およびセマンティック処理のためにそれを記憶する目的で、データを収集する能力を含む。
デバイス管理(DMG):MN(例えば、M2Mゲートウェイ)、ASNおよびAND(例えば、M2Mデバイス)、ならびにM2Mエリアネットワーク内に常駐するデバイスについてのデバイス能力の管理を提供する。
発見(DIS):属性およびリソースに含まれるようなアプリケーションならびにサービスについての情報を検索する。
グループ管理(GMG):グループ関連要求を取り扱う責任がある。要求は、グループおよびそのメンバシップを管理するために、ならびにグループによってサポートされる一括動作のために送信される。
場所(LOC):AEが場所ベースのサービスのためのノード(例えば、ASN、MN)の地理的場所情報を取得することを可能にする。
ネットワークサービスエクスポージャ、サービス実行、およびトリガ(NSSE):Mcn参照点を経由してネットワークサービス機能にアクセスするための下層ネットワークとの通信を管理する。
登録(REG):登録されたエンティティがレジストラCSEによって提供されるサービスを使用することを可能にするために、AEまたは別のCSEからのレジストラCSEに登録する要求を処理する。
セキュリティ(SEC):極秘データ取扱、セキュリティ管理、セキュリティ関連付け確立、識別/認証/承認を含むアクセス制御、および識別管理等の機能性を備えている。
サービス課金および会計(SCA):サービス層のための課金機能を提供する。これは、オンラインリアルタイムクレジット制御も含む、異なる課金モデルをサポートする。
サブスクリプションおよび通知(SUB):リソース上の変更、例えば、リソースの委託を追跡する、サブスクリプションに関する通知を提供する。
(サービス層交渉)
以下の既存サービスおよび/またはプロトコルが、サービス層交渉で使用されることができる:
交渉要求承認:交渉サービスは、関連コンテキスト、ならびに過去の要求および交渉結果の履歴に基づいて、要求側からの交渉要求を受理すべきかどうかを決定することができる。交渉サービスは、交渉の緊急性に基づいて、要求の優先順位を設定することもできる。
交渉関係者制御:交渉サービスは、交渉を行うべき相手を決定することができる。交渉関係者は、要求側によって知らされるか、または利用可能なIoTサービスプロバイダ等における発見結果に基づいて認知能力によって決定されることができる。
交渉計画制御:交渉サービスは、要求側の代わりに交渉計画を選定することができる。交渉サービスは、常に、要求側の入力交渉目標に基づいて、要求側の最善の利益を考慮する。
交渉適合:交渉サービスは、ポリシ変更またはコンテキスト変更に起因して適合され得る。交渉サービスポリシは、コンテキスト、ソフトウェア定義設定、および他のサービスからの入力等のものに基づいて、動的に適合されることができる。ポリシの動的適合を介して、順に、決定が動的に適合されることができる。コンテキスト認識サービスは、交渉適合のために交渉サービスに関連コンテキストを動的に更新し得るか、または交渉サービスは、コンテキスト認識サービスから関連コンテキストを先を見越して読み出すことができる。
交渉一般化:交渉サービスは、過去の交渉プロセスから要約される一般化された共通交渉計画を作成することができ、それは、後に交渉要求側によって使用され、各要求側のための交渉計画を決定することにおける認知能力のオーバーロードを減少させ得る。
交渉サブスクリプション:任意の適合が加入者に通知されることができるように、交渉結果へのサブスクリプションが提供される。このサブスクリプション機構は、自律適合を可能にする。加入者が、加入するものの同一交渉結果を使用している場合、加入交渉結果への任意の変更が、それを自動的に適合するように加入者をトリガすることができる。交渉サブスクリプションがないと、他のエンティティは、交渉結果を再利用し、それに従うことができない。本開示はまた、提案される知的交渉サービスのコンポーネント、ならびに他のIoTサービス、IoTエンティティ、およびIoTアプリケーションへのインターフェースも説明する。
(一般アーキテクチャ)
図4Aは、1つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための基礎的要素を提供し、任意のM2Mデバイス、ゲートウェイ、またはサービスプラットフォームは、IoT/WoTのコンポーネントならびにIoT/WoTサービス層等であり得る。
図4Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク、例えば、Ethernet(登録商標)、Fiber、PLC、ISDN等、もしくは無線ネットワーク、例えば、WLAN、セルラー等、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークからなり得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図4Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインは、通常はM2Mゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインは、プロキシを伴うSCS等のM2Mゲートウェイ14と、UEデバイス等の端末デバイス18とを含む。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じて、M2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイデバイス14は、無線M2Mデバイス、例えば、セルラーおよび非セルラーならびに固定ネットワークM2Mデバイス、例えば、PLCが、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20もしくはM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2M層22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。一実施形態では、サービス層22は、PCEであり得る。M2Mデバイス18およびゲートウェイ14は、セルラー、WLAN、WPAN、例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標)、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図4Bを参照すると、フィールドドメイン内の図示されるM2Mサービス層22は、M2Mアプリケーション20、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12のためのサービスを提供する。M2Mサービス層22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、1つ以上のサーバ、コンピュータ等によって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用される、サービス能力を提供する。M2Mサービス層22の機能は、種々の方法で実装され得る。例えば、M2Mサービス層22は、ウェブサーバ、セルラーコアネットワーク、クラウド等で、実装されることができる。一実施形態では、交渉サービスが、M2Mサービス層22に含まれ得る。
図示されるM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’が存在する。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および下層通信ネットワーク12’のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイデバイス14およびM2M端末デバイス18のためのサービスも提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス、およびM2M端末デバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによるサービス層と相互作用し得る。M2Mサービス層22’は、1つ以上のサーバ、コンピュータ、仮想マシン、例えば、クラウド/計算/記憶ファーム等によって実装され得る。
図4Bも参照すると、M2Mサービス層22および22’は、多様なアプリケーションならびにバーティカルが活用することができる、サービス配布能力のコアの組を提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見、サービスの交渉等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
M2Mアプリケーション20および20’は、限定ではないが、輸送、保険および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の産業での用途を含み得る。上記のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡/ジオフェンシング、デバイス/サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能に、M2Mアプリケーション20および20’を提供する。また、M2Mサービス層はまた、本願で議論され、図に図示されるように、UE、SCS、およびMME等の他のデバイスとインターフェースをとるように構成され得る。
本願で議論されるようにサービスを動的に要求する方法は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ETSI M2MおよびoneM2Mは両方とも、UE PSMモードを制御および協調する方法を含み得る、サービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。ETSI M2MおよびoneM2Mは両方とも、トラックを確保する方法を含み得る、サービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内に実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)、例えば、サービス能力の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード、例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード等の上にホストされ得る、SCS等の共通サービスエンティティ(CSE)と称される。さらに、本願で説明されるような交渉側と被交渉側との間でサービスについて交渉する方法は、本願による、サービスを動的に要求するためにサービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装されることができる。
図4Cは、例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14等の例示的M2Mデバイス30の系統図である。図4Cに示されるように、M2Mデバイス30は、プロセッサ32と、送受信機34と、伝送/受信要素36と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ/タッチパッド/インジケータ42と、非取り外し可能メモリ44と、取り外し可能メモリ46と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。M2Mデバイス40は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。デバイスは、感覚データの組み込みセマンティック命名のための開示されるシステムおよび方法を使用する、デバイスであり得る。M2Mデバイス30はまた、本願に説明され、図に図示されるように、例えば、LLNデバイス、バックボーンルータ、およびPCEを含む、他のデバイスとともに、採用され得る。
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態マシン等であり得る。プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mデバイス30が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ32は、伝送/受信要素36に結合され得る、送受信機34に結合され得る。図4Cは、プロセッサ32および送受信機34を別個のコンポーネントとして描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ32は、アプリケーション層プログラム、例えば、ブラウザ、および/または無線アクセス層(RAN)プログラムならびに/もしくは通信を行い得る。プロセッサ32は、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー一致、ならびに/もしくは暗号化動作等のセキュリティ動作を行い得る。
伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送するか、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送/受信要素36は、例えば、IR、UV、もしくは可視光信号を伝送および/または受信するように構成されるエミッタ/検出器であり得る。さらに別の実施形態では、伝送/受信要素36は、RFおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送/受信要素36は、無線もしくは有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図4Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、実施形態では、M2Mデバイス30は、無線信号を伝送および受信するための2つまたはそれを上回る伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、加入者識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の実施形態では、プロセッサ32は、サーバまたはホームコンピュータ上等のM2Mデバイス30上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。
プロセッサ32は、電源48から電力を受電し得、M2Mデバイス30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に給電するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ、例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)、太陽電池、燃料電池等を含み得る。
プロセッサ32はまた、M2Mデバイス30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成されている、GPSチップセット50に結合され得る。M2Mデバイス30は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ32はさらに、追加の特徴、機能性、および/または有線もしくは無線コネクティビティを提供する、1つ以上のソフトウェアならびに/もしくはハードウェアモジュールを含み得る、他の周辺機器52に結合され得る。例えば、周辺機器52は、加速度計、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
図4Dは、例えば、図4Aおよび4BのM2Mサービスプラットフォーム22が実装され得る、例示的コンピュータシステム90のブロック図である。コンピュータシステム90は、コンピュータまたはサーバを備え得、主に、ソフトウェア(そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず)の形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム90を稼働させるように、中央処理装置(CPU)91内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンでは、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たす、またはCPU91を支援する、主要CPU91とは明確に異なる、随意のプロセッサである。CPU91および/またはコプロセッサ81は、組み込みセマンティック名を伴う感覚データのクエリ等の組み込みセマンティック命名のための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス80を介して、情報を他のリソースへ、ならびにそこから転送する。そのようなシステムバスは、コンピュータシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作するための制御ラインとを含む。そのようなシステムバス80の実施例は、PCI(周辺コンポーネント相互接続)バスである。
システムバス80に結合されるメモリデバイスは、ランダムアクセスメモリ(RAM)82と、読み取り専用メモリ(ROM)93とを含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ROM93は、概して、容易に修正されることができない、記憶されたデータを含む。RAM82に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られるか、または変更されることができる。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離する、メモリ保護機能を提供し得る。したがって、第1のモードで作動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。
加えて、コンピュータシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピュータシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。ディスプレイ86は、組み込みセマンティック名を使用して、ファイルまたはフォルダ内の感覚データを表示し得る。さらに、コンピュータシステム90は、図4Aおよび4Bのネットワーク12等の外部通信ネットワークにコンピュータシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。
本願のある側面によると、NGSは、M2Mエンティティが、さらなる柔軟性で動的かつ効率的にサービスを要求することを可能にする。例えば、図5Aは、どのようにしてNGSが3つのシナリオをサポートすることができるかを図示する。NGSは、それらのサービス層の新しい機能として、M2MデバイスおよびM2Mサーバの両方の中に常駐する。「シナリオ1」として示される、例示的実施形態では、M2MデバイスのNGSは、それらの間にあるようなサービス交渉を果たすように、M2MサーバのNGSと相互作用する。「シナリオ2」として示される、別の例示的実施形態では、M2M App A(またはApp B)は、M2M App A(またはApp B)による要求に応じて、サービスについて交渉するようにM2MサーバのNGSと通信する。「シナリオ3」として示される、さらなる例示的実施形態では、M2M App AおよびM2M App Bは、M2Mサーバを介して互いにサービスについて交渉する。すなわち、両方のアプリケーションが、M2MサーバのNGSと通信し、それは、ひいては、両方のアプリケーションがサービス交渉を行うことに役立つ。
一実施形態では、例えば、図5Bに示されるようなグラフィカルユーザインターフェース(GUI)が、M2Mデバイス、ゲートウェイ、またはサーバにおいて交渉ポリシを構成/表示するために使用されることができる。例えば、GUIは、交渉ポリシの構成を表示するためのテキストボックスを含む、領域を含み得る。GUIはまた、交渉ポリシおよび結果を表示するためのテキストボックスを含む、領域を含み得る。例示的実施形態では、ユーザは、タッチスクリーンインターフェースを介してGUIと相互作用することができる。
(個々の交渉要求のためのプロシージャ)
ある実施形態によると、図6は、個々の交渉要求のためのサービス交渉プロセスを図示する。図6のステップの各々は、ローマ数字によって表される。被交渉側Aは、交渉側に交渉可能なサービスを示すか、または通知する。ここでは、交渉可能なサービスは、その特徴または構成が動的に交渉され、異なるM2Mエンティティに提供されることができる場合の任意のサービスとして定義される。例えば、M2Mサーバによって提供されるデータ管理サービスは、異なるM2Mデバイスの記憶サイズおよび課金率が動的に交渉されて割り付けられることができる場合、交渉可能である。しかしながら、M2Mサーバによって提供される登録サービスは、各M2Mデバイスが常に、M2Mサーバに関連付けるために同一の登録サービスを使用する必要がある場合、交渉可能ではないであろう。
交渉側は、被交渉側Aと提案される交渉プロセスを行う。交渉側は、一実施形態では、サービスの組について交渉し得る。別の実施形態では、交渉側は、特定のサービスの特徴について交渉し得る。この交渉プロセスから2つの結果が生じる:1)交渉側および被交渉側Aが、合意に達する、または、2)被交渉側Aが、交渉側の要件を満たすことができず、別の被交渉側、例えば、被交渉側Bを推奨する。交渉プロセスの一部として、交渉側は、随意に、被交渉側Aによって認証され得、随意に、被交渉側Aは、交渉側によって認証され得る。認証プロセスの一部として、交渉側および被交渉側Aは、事前構成された証明書を使用して認証され得る。追加の証明書、例えば、メッセージ認証/完全性保護のためのキーが提供され得、それは、交渉側と被交渉側Aとの間の将来のメッセージ交換中に認証目的で使用され得る。交渉側および/または被交渉側のいずれか一方によるキーの保有を確実にすることは、1つの形態の暗示的認証であり得る。随意に、交渉されたサービスにアクセスするために使用されることができる承認証明書が、交渉側にプロビジョンされ得る。
上で議論される代替実施形態によると、被交渉側Aと合意を有していない場合、交渉側は、被交渉側Aによって推奨されるような別の被交渉側Bと交渉を行い得る。交渉側と被交渉側Aとの間の認証プロセスまたは随意の相互認証プロセスと同様に、認証および承認プロセスが、交渉側と被交渉側Bとの間で実行され得る。
図7のステップの各々は、ローマ数字によって表される。例えば、ステップ0−1では、交渉側が、「交渉可能なサービスへのサブスクリプション」を被交渉側Aに発行する。結果として、交渉側は、サービスが交渉可能になる場合、ステップ0−2で被交渉側Aから自動通知を受信するであろう。これは、その部分的または全体的特徴/機能性が、動的に要求、変更、および/または構成され得ることを意味する。交渉側は、このステップで、標的サービスのリスト等の種々のサブスクリプション基準を備え得る。サブスクリプション基準はまた、現在交渉可能ではない場合がある特徴を含み得る。代替として、交渉側は、例えば、RESTful RETRIEVE動作を使用して、被交渉側Aにおいて交渉可能なサービスのリストを発見するか、または読み出すために、具体的メッセージを被交渉側に送信することができる。したがって、被交渉側Aは、それが提供する交渉可能なサービスのリストで交渉側に応答するであろう。
ある後の段階で、そのサービスのうちのいずれかが交渉可能になり、変更が0−1におけるサブスクリプション基準を満たす場合、被交渉側Aは、「交渉可能なサービスについての通知」メッセージを交渉側に送信する。このメッセージの目的は、被交渉側Aにおける交渉可能なサービスのリストを交渉側に知らせることである。このメッセージは、以下の情報を含み得る:
ListOfNegotiableService:各交渉可能なサービスの名称、識別子、および/または説明、例えば、ServiceIDを含む。各交渉可能なサービスに対して、被交渉側Aは、サービスのうちのどの特徴が交渉可能であるかと、サービスおよびその特徴が利用可能になるであろう期間とを示し得る。被交渉側Aはまた、各交渉可能なサービスのための交渉側からの予期される入力を規定し得る。
次に、ステップ1では、交渉側が、交渉を開始するための「交渉要求」メッセージを被交渉側Aに送信する。このメッセージは、以下の情報を含み得る:
ServiceID:被交渉側Aと交渉されるべきサービスの名称、識別子、および/または説明。交渉されるべき各サービスに対して、交渉側は、このサービスの1つ以上の特徴について交渉することを明示的に要求し得る。交渉側は、ステップ0−2からこの情報を把握することができるであろう。例えば、サービスIDは、交渉側がより多くまたは高速の記憶容量を獲得したいことを示し得る:
InputForMakeSuggestion:交渉側が、必要な入力を提供し、それは、ステップ2で提案を行うために被交渉側Aによって活用されるであろう。基本的に、このステップでは、被交渉側Aは、各交渉ポリシの適用可能性をチェックするために、このパラメータを使用して、各交渉ポリシの中の「条件」パラメータに対して比較する。交渉側は、ステップ0−2からどんな入力情報が提供されるべきかを把握することができるであろう。例えば、サービスIDが、交渉側がより多くおよび/または高速の記憶容量を獲得したいことを示す場合、InputForMakeSuggestionIDは、どれだけの記憶が必要とされるか、またはどのような記憶のアクセス速度が必要とされるかを示し得る:
ProposedSuggestions:交渉側は、ある提案を被交渉側Aに提案し得、これは、被交渉側Aにおける動作を単純化し、交渉プロセスを促進することに役立ち得る。基本的に、ProposedSuggestionsパラメータは、被交渉側Aで維持される各交渉ポリシの中の「結果」パラメータの同一の意味を有する。ProposedSuggestionsは、交渉側が容認可能と見出すであろう、サービスの実施例を表す。
次いで、ステップ2では、被交渉側Aが、そのローカルポリシに基づいて提案を行うための入力として、ステップ1からの情報をとる。このステップの出力は、ステップ3で交渉側に送信されるOfferedSuggestionsである。図7は、どのようにして被交渉側がこれらの提案を行うことに取り掛かり得るかについてのプロシージャを提供する。被交渉側Aは、そのポリシをチェックすることなく、またはいかなる適用可能なポリシもない場合、単純に交渉側からProposedSuggestionsを受理し得ることに留意されたい。
次に、ステップ3では、被交渉側Aが、「交渉応答」メッセージを交渉側に送信する。このメッセージは、OfferedSuggestionsを含む。このパラメータは、交渉側への複数の提案を含み得るか、または現在行われている交渉ラウンドの数が被交渉側Aにおける事前構成された閾値を超える場合、単純に別の被交渉側Bを示し得る。被交渉側AおよびBが、同一のサービスドメイン内に常駐し得ることに留意されたい。被交渉側Aはまた、把握している場合、被交渉側BにおけるListOfNegotiableServicesを示し得、例えば、被交渉側Aおよび被交渉側Bは、前もってステップ0−1およびステップ0−2を行い、互いの交渉可能なサービスを把握し得る。OfferedSuggestionsが別の被交渉側Bのみを含む場合、交渉側は、現在の交渉を中止し、直接、被交渉側Bと新しい交渉プロセスを開始するであろう。この場合、ステップ4、ステップ5、およびステップ6は、省略されるであろう。
「交渉応答」メッセージを受信した後、交渉側は、OfferedSuggestionsに満足していない場合、別の交渉ラウンドを開始するためにステップ1を繰り返し得る。そうでなければ、交渉側は、OfferedSuggestionsに含まれる、ある提案に満足している場合、ステップ4を行う。繰り返されるステップ1では、交渉側は、ServiceID、InputForMakeSuggestion、およびProposedSuggestionsの新しいパラメータ値を提出し得る。
ステップ4では、交渉側が、それが維持する交渉ポリシに基づいて、OfferedSuggestionsから適切な提案を選択する。交渉側は、そのポリシをチェックすることなく、またはいかなる適用可能なポリシもない場合、単純に受信されたOfferedSuggestionsを選定し得ることに留意されたい。ステップ5では、交渉側が、「交渉確認」メッセージを被交渉側Aに送信する。このメッセージは、ステップ4からのSelectedSuggestionsおよびServiceIDを含む。ServiceIDは、ステップ1におけるものと同一またはその一部であり得る。ステップ6では、被交渉側Aが、「確認応答」メッセージを交渉側に送信し得る。結果として、交渉側および被交渉側Aは、交渉されているサービスについて合意に達する。交渉側は、繰り返される交渉ラウンド、すなわち、繰り返されるステップ1、2、および3の最大数の閾値を設定し得る。代替として、被交渉側Aは、繰り返される要求、すなわち、ステップ1の数が、事前構成された閾値より大きい場合、交渉側の要求を拒否し得る。行われた交渉ラウンドの数がこの閾値を超える場合、および交渉側と被交渉側A(またはB)との間に依然としていかなる合意もない場合、交渉側は、交渉プロセスを停止し得るか、またはその交渉ポリシを変更し得る。別の実施形態によると、ユーザが決定を行っている場合、いかなるポリシも採用されないことが想定される。
図7は、どのようにして被交渉側が提案を行い得るか、例えば、図6のステップ2を図示する。被交渉側は、提案を行うためにポリシベースのアプローチを使用する。つまり、被交渉側は、全ての交渉可能なサービスのためのある交渉ポリシを維持する。各交渉ポリシは、以下の情報またはパラメータを有し得る:
ServiceID:この交渉ポリシが適用可能であるサービスの名称、識別子、および/または説明を示す
Condition:この交渉ポリシが適用されることができる状況を示す
Results:「条件」が満たされた場合に作成される提案を示す
Negotiator:この交渉ポリシが適用可能である交渉側のリストを示す。ポリシ実施例が、表1で挙げられる。例として、被交渉側としての機能を果たすM2Mサーバは、より柔軟なデバイス管理サービスを提供するために、これらのポリシを維持し得る。これらのポリシは、M2Mサーバ自体によって、または特殊な管理者アプリケーションによって作成され得る。
以下のステップは、被交渉側が提案を行うために必要とされる。被交渉側は、全ての潜在的提案を取得するように、受信された「交渉要求」の中のパラメータ値を、そのローカル交渉ポリシと比較するための入力としてとる。ポリシが適用可能である場合、例えば、「InputForMakeSuggestion」がポリシの中の「条件」に一致する場合、ポリシの「結果」は、潜在的提案であろう。ポリシ候補が図7でチェックされるが、被交渉側は、随意に、ある数のポリシ候補をチェックし得ることが想定される。図7のステップの各々は、ローマ数字によって表される。
ステップ1では、被交渉側が、受信された「交渉要求」メッセージを入力としてとる。このメッセージは、3つのパラメータ、すなわち、ServiceID、InputForMakeSuggestion、およびProposedSuggestionsを含むことに留意されたい。ステップ2では、被交渉側が、現在の「交渉要求」のためにそのローカル交渉ポリシデータベースからポリシ候補を見つけるために、「ServiceID」を使用する。ローカルポリシは、「ServiceID」が「交渉要求」に含まれる「ServiceID」を対象にする場合、ポリシ候補になる。被交渉側は、ポリシをフィルタ処理するために、およびポリシ候補リストをより正確にするために、「交渉側」情報を使用し得る。このステップの出力は、受信された「交渉要求」に潜在的に適用可能なあるポリシを含むポリシ候補の組である。ポリシは、事前プロビジョンされた証明書に基づいて、被交渉側が交渉側を認証するかどうかを決定付け得る。交渉側は、随意に、同様に被交渉側を認証し得る。
ステップ3によると、被交渉側は、ステップ2で見出される任意のポリシ候補があるかどうかをチェックする。「はい」である場合、ステップ4に移動することができ、そうでなければ、ステップ13に進む。ステップ4では、被交渉側は、ステップ2で発見されるようなポリシ候補の組の中の第1のポリシとして、CurrentPolicyを設定する。そして、OfferedSuggestionsを空に設定する。ステップ5では、被交渉側は、CurrentPolicyが現在の「交渉要求」へのその適用可能性について決定を行うことをチェックする。ステップ6では、CurrentPolicyが適用可能であるかどうか、チェックが行われる。もしそうであれば、被交渉側は、提案を行うためにステップ7に進む。そうでなければ、被交渉側は、いずれかが利用可能である場合、次のポリシをチェックするためにステップ9に移動する。例えば、候補ポリシは、期限切れになるか、または交渉側のために許可されない。
ステップ7によると、被交渉側が、CurrentPolicyに基づいて提案を行う。ステップ7.1では、NGSが、InputForMakeSuggestionをCurrentPolicyの「条件」と比較する。両方が互いに一致する場合、CurrentPolicyが適用されるであろう。そうでなければ、CurrentPolicyは、提案を行うことに影響を及ぼさない。「条件」は、被交渉側のローカルコンテキスト情報に関連するある情報を含み得る。この場合、被交渉側はまた、「条件」に対してその現在のコンテキスト情報をチェックし得る。
ステップ7.2では、CurrentPolicyの「結果」が、newSuggestionsとして選ばれるであろう。ステップ7.3では、OfferedSuggestionsが、単純に、OfferedSuggestions上にnewSuggestionsを追加することであり得る関数f(OfferedSuggestions,newSuggestion)に従って更新されるであろう。ステップ7.4では、OfferedSuggestionsへの変更がない。
次に、ステップ8では、被交渉側は、OfferedSuggestionsが交渉側からの「ProposedSuggestions」を含むかどうかをチェックする。「はい」である場合、ProposedSuggestionsは、「OfferedSuggestions」として設定されるであろう(ステップ13)。OfferedSuggestionsとProposedSuggestionsとの共通部分は、交渉側のための最終OfferedSuggestionsとして選定されるであろう。
提案を行うプロセスが終了する。「いいえ」である場合、ステップ9は、他のポリシ候補をチェックする。被交渉側は、単純に、交渉側のProposedSuggestionsを無視し得る。
ステップ9では、被交渉側が、CurrenttPolicyがポリシ候補の組の中の最後のポリシであるかどうかをチェックする。「いいえ」である場合には、ポリシ候補の組の中の次のポリシが、CurrenttPolicyとして選定されるであろう(ステップ10)。そして、プロセスは、ステップ5に戻る。
「はい」である場合、OfferedSuggestionsが空であるかどうか、チェックが行われる。「いいえ」である場合、出力は、提示された提案(ステップ12)である。「はい」である場合、被交渉側は、ポリシのうちのどれも受信された「交渉要求」に適用可能ではないことを見出し、別の被交渉側を交渉側に推奨し得る(ステップ14)。
(交渉側において提案を選択する)
図8は、交渉側によって行われる提案を選択することの詳細を図示する。これは、図6のステップ4に関連する。本開示では、交渉側が提案を選択するためにポリシベースのアプローチを使用することが提案される。基本的に、交渉側は、ある交渉ポリシを維持する。各交渉ポリシは、以下の情報またはパラメータを有し得る:
ServiceID:この交渉ポリシが適用可能である、サービスの名称、識別子、および/または説明を示す
Condition:この交渉ポリシが適用されることができる状況を示す。例えば、条件は、交渉されているサービスがどのようなプロトコルを使用するかを含み得るか、または示し得る
Results:「条件」が満たされる場合に選択されるべき提案を示す
Negotiatee:この交渉ポリシが適用可能である被交渉側のリストを示す。
いくつかのポリシ実施例が、表2で挙げられる。例として、交渉側としてのM2Mデバイスが、より柔軟なデバイス管理サービスを要求するために、これらのポリシを維持し得る。これらのポリシは、M2Mデバイス上のアプリケーションによって、または特殊管理者アプリケーションによって作成されることができる。交渉側は、上で議論される類似プロシージャに従うことによって、ProposedSuggestionsを取得するために、これらのポリシを使用することもできる。
以下のステップは、交渉側が図8の提案を選択するために必要とされる。交渉側は、適切な提案を選択するために、受信された「交渉応答」の中のパラメータ値を、そのローカル交渉ポリシと比較するための入力としてとる。ポリシが適用可能である場合、例えば、「InputForSelectSuggestion」がポリシの中の「条件」に一致する場合、ポリシの「結果」は、SelectedSuggetionsであろう。全てのポリシ候補が図8でチェックされるが、交渉側は、随意に、ある数のポリシ候補のみをチェックし得る。
ステップ1では、交渉側が、以下のパラメータを入力としてとる:
被交渉側からの「交渉応答」メッセージの中で受信されたServiceID
被交渉側からの「交渉応答」メッセージの中で受信されたOfferedSuggetions
交渉側によって決定および維持されるローカルパラメータであるInputForSelectSuggetion。このパラメータは、ポリシ依存性であることに留意されたい。表2のポリシに対して、InputForSelectSuggetionは、「管理されるデバイスの数」であろう。交渉側は、適切な提案を決定して選択するために、このパラメータを各ポリシ候補の「条件」に対して比較する。
次に、ステップ2では、交渉側が、そのローカル交渉ポリシデータベースからポリシ候補を見つけるために、「ServiceID」を使用する。ローカルポリシは、「ServiceID」がステップ1における「ServiceID」を対象にする場合、ポリシ候補になる。交渉側はさらに、より無関係のポリシを除外するために、「被交渉側」情報を使用し得る。このステップの出力は、受信された「交渉応答」に潜在的に適用可能なあるポリシを含む、ポリシ候補の組である。
ステップ3では、交渉側が、ステップ2で見出される任意のポリシ候補があるかどうかをチェックする。「はい」である場合、プロシージャは、交渉側が、ステップ2で見出されるようなポリシ候補の組の中の第1のポリシとしてCurrentPolicyを設定するステップ4に移動する。そして、SelectedSuggestionsを空の組に設定する。そうでなければ、ステップ11に進む。
ステップ5では、交渉側が、現在の「交渉応答」へのその適用可能性についてCurrentPolicyをチェックする。ステップ6では、CurrentPolicyが適用可能である場合、交渉側は、CurrentPolicyに基づいて提案を選択するためにステップ7に進む。
ステップ7.1では、NGSが、InputForSelectSuggestionをCurrentPolicyの「条件」と比較する。両方が互いに一致する場合、CurrentPolicyが適用されるであろう。そうでなければ、CurrentPolicyは、提案を選択することに影響を及ぼさない。「条件」は、交渉側のローカルコンテキスト情報に関連するある情報を含み得る。この場合、交渉側はまた、「条件」に対してその現在のコンテキスト情報をチェックし得る。ステップ7.2では、CurrentPolicyの「結果」が、NewSelectionsとして選定されるであろう。ステップ7.3では、SelectedSuggestionsが、単純に、NewSelectionsおよびOfferedSuggestionsの共通部分を現在のSelectedSuggestionsに追加することであり得る、関数f(NewSelections,SelectedSuggestions,OfferedSuggestions)に従って更新されるであろう。ステップ7.4では、SelectedSuggestionsへの変更がない。
ステップ6からの返答が「いいえ」である場合、交渉側は、該当する場合、次のポリシをチェックするためにステップ8に移動する。例えば、候補ポリシは、期限切れになり得るか、または「交渉応答」を送信した被交渉側のために許可されない。ステップ8では、交渉側が、CurrenttPolicyがポリシ候補の組の中の最後のポリシであるかどうかをチェックする。「いいえ」である場合、プロシージャは、ポリシ候補の組の中の次のポリシが、CurrenttPolicyとして選定されるであろう、ステップ9に移動する。次いで、プロセスは、CurrenttPolicyをチェックするために、ステップ5に戻る。
ステップ8からの返答が「はい」である場合、交渉側が、SelectedSuggestionsが空であるかどうかをチェックするステップ10に進む。「はい」である場合、プロシージャは、ステップ12に移動し、交渉側は、ポリシのうちのいずれも受信された「交渉応答」に適用可能ではないことを見出す。SelectedSuggestionsは、空であろう。交渉側は、新しい交渉ラウンドを開始し得る。そうでなければ、ステップ10からの返答が「いいえ」である場合、ステップ11に進む。ここで、交渉側は、全てのポリシ候補をチェックした後にこのステップに至り、SelectedSuggestionsを出力する。交渉側によって選定されるSelectedSuggestionsは、OfferedSuggestionの一部でないこともあり、すなわち、SelectedSuggestionsとOfferedSuggestionとの間にいかなる共通部分もない。この場合、交渉側は、新しい「交渉要求」を再送すること、すなわち、図6のステップ1を再開し、SelectedSuggestionsは、ProposedSuggestionsとして新しい「交渉要求」に含まれ得る。
(複数の交渉要求のためのプロシージャ)
図6に図示されるように、被交渉側(AまたはBのいずれか一方)は、各交渉要求もしくは交渉側を独立して扱う。実際に、異なる交渉側からの複数の要求を合同で考慮することによって、特に、複数の交渉側が互いに論理的に関連付けられ得る場合(例えば、同一場所から)、同一タイプのサービスを要求し得る場合、同一タイプのデバイスを有し得る場合、過去に類似交渉履歴および挙動を有し得る場合等のシナリオに対して、被交渉側は、交渉側により良好な提案を行い得る。一実施例では、同一のServiceIDを伴う交渉要求は、合同で考慮され得る。被交渉側は、そのような組み合わせを行うために、受信された交渉要求をバッファリングし得る。被交渉側は、複数の要求が合同で考慮されるときにのみ適用可能である特殊ポリシを構成し得る。この目的のために、基本的サービス交渉のための代替的プロシージャが図9で開発され、被交渉側は、2つの交渉側AおよびBからの交渉要求を合同で考慮することによって提案を行う。図9のステップの各々は、ローマ数字によって表される。
ステップ1Aでは、交渉側Aが、「交渉要求」を被交渉側に送信する。ステップ1Bでは、交渉側Bが、「交渉要求」を被交渉側に送信する。ステップ2では、被交渉側が、交渉側AおよびBからの両方の要求を考慮して、提案を行う。被交渉側は、最初に、OfferedSuggestionsの2つの値を得るために、交渉側Aおよび交渉側Bについて図7のプロシージャを独立して行い得る。次いで、最終的なOfferedSuggestionsは、これら2つの値の共通部分であろう。共通部分がない場合、被交渉側は、ただ単純に、2つのOfferedSuggestions値(交渉側Aに1つ、交渉側Bにもう1つ)を提案し得る。
共通部分がない場合、被交渉側は、これら2つのOfferedSuggestionsのうちの1つをとり、それを両方の交渉側に送信し得る。共通部分がない場合、被交渉側は、次回、2つのOfferedSuggestionsの共通部分に潜在的に到達し得るように、それらの次回の交渉要求を変更するように両方の交渉側に通知し得る。
代替として、被交渉側は、最初に、交渉側Aおよび交渉側Bの両方のために適用可能であるポリシを見つけ得る。そして、被交渉側は、図7の同一のプロシージャに従って、これらのポリシに基づいて提案を行う。交渉側Aおよび交渉側BのためのOfferedSuggestionsは、被交渉側がOfferedSuggestionsを決定するために使用するポリシに応じて、異なり得る可能性が高い。
ステップ3Aでは、被交渉側が、「交渉応答」を交渉側Aに送信する。ステップ3Bでは、被交渉側が、「交渉応答」を交渉側Bに送信する。
ステップ4Aでは、交渉側Aが、ステップ3AにおけるOfferedSuggestionsから提案を選択する。ステップ4Bでは、交渉側Bが、ステップ3BにおけるOfferedSuggestionsから提案を選択する。ステップ5Aでは、交渉側Aが、「交渉確認」を被交渉側に送信する。ステップ5Bでは、交渉側Bが、「交渉確認」を被交渉側に送信する。ステップ6Aでは、被交渉側が、「確認応答」を交渉側Aに送信する。ステップ6Bでは、被交渉側が、「確認応答」を交渉側Bに送信する。
(ブローカベースのサービス交渉)
提案を行う、または提案を選択するプロセスは、制約付きM2Mデバイスにとって過剰に重くなり得る。この問題を解決するために、交渉ブローカが被交渉側の代わりに提案を行うこと、および/または交渉側の代わりに提案を選択することに役立つブローカベースのサービス交渉が説明される。交渉ブローカは、一方のブローカから他方のブローカに委託されることもできる。図10および11によると、交渉側が、交渉ブローカが取り扱うことができる交渉可能なサービスのリストについて自動通知を入手し得るように、図6に示されるようなステップ0−1およびステップ0−2が、交渉側と交渉ブローカとの間で使用されることができる。
透過モードでは、交渉ブローカは、提案を行うことも、提案を選択することもしないが、交渉側が適切な被交渉側を見出すこと、例えば(要求を、リストが要求に適合する被交渉側に転送すること、または軽い負荷を伴う被交渉側に転送すること、および、単純に、交渉関連メッセージを交渉側と被交渉側との間で転送すること)に役立つ。以下のステップが、図10に示されるように導入される。
ステップ1では、被交渉側が、「交渉要求のためのサブスクリプション」を交渉ブローカに送信する。メッセージは、基本的に、被交渉側がServiceIDによって表されるサービスについて交渉できることを交渉側ブローカに伝える。ステップ2では、交渉ブローカが、「応答」を被交渉側に送信する。各サービスに対して、交渉ブローカは、サービスに関心があり、それのための交渉を提供することができる被交渉側のリストを維持するであろう。そして、ステップ3では、交渉側が、「交渉要求」を交渉ブローカに送信する。ステップは、図6のステップ1と同一である。ステップ4では、交渉ブローカが、受信された「交渉要求」のための適切な被交渉側を見出すために、「交渉要求」に含まれる「ServiceID」を使用する。
ステップ5によると、交渉ブローカは、ステップ1におけるサブスクリプションへの応答として、「通知」を対応する被交渉側に送信する。この通知は、実際に、「交渉要求」を転送することである。ステップ6では、被交渉側は、提案を行う。さらに、ステップ7では、被交渉側が、交渉ブローカを介して「交渉応答」を交渉側に送信する。一実施形態では、交渉ブローカは、交渉側によって設定される事前構成されたポリシに対して、提示された提案をチェックする。
交渉側は、ステップ8で提案を選択する。ステップ9では、交渉側が、交渉ブローカを介して「交渉確認」を被交渉側に送信する。ステップ10では、被交渉側が、交渉ブローカを介して「確認応答」を交渉側に送信する。
ステップ1およびステップ2は、複数の被交渉側があり得るので、1回以上の回数で起こり得る。ステップ1および2の各組は、個々の被交渉側のためのものである。ステップ5、ステップ6、およびステップ7は、複数の被交渉側があり得るため、1回以上の回数で起こり得る。ステップ5、ステップ6、およびステップ7の各組は、個々の被交渉側のためのものである。
別の実施形態によると、図11は、交渉ブローカが被交渉側の代理の役割を果たすシナリオを図示する。ステップ1では、被交渉側が、「交渉代理要求」を交渉ブローカに送信する。被交渉側は、このステップで、その交渉ポリシを交渉ブローカにパスし得る。被交渉側は、その交渉ブローカにおいてその交渉ポリシを作成するために、別個のプロシージャを使用し得る。
ステップ2では、交渉ブローカが、「交渉代理応答」を被交渉側に送信する。このステップは、省略され得、ステップ9が、被交渉側への最終応答であろうことに留意されたい。ステップ1および2は、被交渉側が交渉ブローカにすでに登録されているか、または関連付けられている場合、必要とされないこともあり、デフォルトで、交渉ブローカは、被交渉側のための代理機能を果たすであろう。ステップ1および2は、被交渉側と交渉ブローカとの間の発見ならびにアソシエーション段階に先行され得る。アソシエーション段階の一部として、交渉ブローカおよび被交渉側は、以降の段階で認証に使用され得る、認証証明書をプロビジョンされ得るか、または導出し得る。
次に、ステップ3では、交渉側が、「交渉要求」を交渉ブローカに送信する。このステップは、図6のステップ1と同一である。「交渉要求」メッセージを送信することに先立って、交渉側は、交渉ブローカによって認証され得るか、または代替として、交渉側および被交渉側は、確立された証明書に基づいて、互いに認証し得る。代替として、認証/相互認証は、「交渉要求」段階中に実行され得、正しい証明書の保有は、暗号プロシージャを使用して、「交渉要求」メッセージの一部として検証される。
ステップ4では、交渉ブローカが、ステップ1で送信される交渉ポリシに従って、被交渉側の代わりに提案を行う。このステップは、図6のステップ2と同一である。ステップ5では、交渉ブローカが、「交渉応答」を交渉側に送信する。このステップは、図6のステップ3と同一である。交渉側がステップ5に含まれるOfferedSuggestionsに満足していない場合、ステップ3、ステップ4、およびステップ5が繰り返され得る。
ステップ6によると、交渉側が、適切な提案を選択する。このステップは、図6のステップ4と同一である。ステップ7では、交渉側が、「交渉確認」を交渉ブローカに送信する。このステップは、図6のステップ5と同一である。ステップ8では、交渉ブローカが、「確認応答」を交渉側に送信する。このステップは、図6のステップ6と同一である。次に、ステップ9では、交渉ブローカが、「交渉通知」を被交渉側に送信する。このメッセージは、以下の情報、すなわち、(i)交渉側の名称または識別子、(ii)交渉されているサービスの名称、識別子、および/または説明、ならびに(iii)交渉側による選択された提案を含み得る。さらに、ステップ10では、被交渉側が、「確認応答」を交渉ブローカに送信する。
ステップ1およびステップ2は、複数の被交渉側があり得るため、複数回起こり得ることに留意されたい。ステップ1および2の各組は、個々の被交渉側のためのものである。ステップ9およびステップ10も、複数の被交渉側があり得るので、複数回起こり得る。ステップ9および10の各組は、個々の被交渉側のためのものである。
別の実施形態によると、図12は、交渉ブローカが交渉側の代理の役割を果たすシナリオを図示し、認証および承認機能が、関与するエンティティに追加される。ステップ1では、交渉側が、「交渉代理要求」を交渉ブローカに送信する。交渉側は、このステップで、その交渉ポリシを交渉ブローカにパスし得る。交渉側は、その交渉ブローカにおいてその交渉ポリシを作成するために、別個のプロシージャを使用し得る。交渉側は、認証、承認、および安全な通信を可能にするために、あるセキュリティ機構ならびに機能を要求し得る。代替として、セキュリティ機能の設定の要求は、ステップ2で交渉ブローカによって行われ得る。交渉要求は、安全な通信チャネルを経由して送信され得る。
ステップ2では、交渉ブローカが、「交渉代理応答」を交渉側に送信する。このステップは、省略され得、ステップ10が、交渉側への最終応答であろうことに留意されたい。ステップ1および2は、交渉側が交渉ブローカにすでに登録されているか、または関連付けられている場合、必要とされないこともあり、デフォルトで、交渉ブローカは、交渉側のための代理機能を果たすであろう。
ステップ3では、交渉側が、「交渉要求」を交渉ブローカに送信する。このステップは、図6のステップ1と同一である。加えて、交渉側および交渉ブローカは、互いに認証し得る。随意に、交渉要求メッセージの一部として、交渉側は、被交渉側または第三者エンティティによって交渉側にプロビジョンされた、セッションベースの承認パラメータを送信し得る。
ステップ4では、交渉ブローカが、承認パラメータとともに、交渉要求を被交渉側に転送する。被交渉側の観点から、被交渉側は、このメッセージが交渉ブローカからであると考える。ステップ5では、被交渉側が承認パラメータを検証することに基づいて、次いで、被交渉側が、提案を行う。このステップは、図6のステップ2に類似する。ステップ6は、図6のステップ3に類似する。交渉側ブローカがステップ6に含まれるOfferedSuggestionsに満足していない場合、ステップ4、ステップ5、およびステップ6が繰り返され得る。
ステップ7によると、交渉側ブローカが、適切な提案を選択する。このステップは、図6のステップ4に類似する。ステップ8では、交渉ブローカが、「交渉確認」を被交渉側に送信する。このステップは、図6のステップ5に類似する。その後、ステップ9では、被交渉側が、「確認応答」を交渉ブローカに送信する。このステップは、図6のステップ6と同一である。次に、ステップ10では、交渉ブローカが、「交渉応答」を交渉側に送信する。このメッセージは、図6のステップ3に類似する。さらに、ステップ11では、交渉側が、「確認応答」を交渉ブローカに送信する。上で説明されるセキュリティ機構(認証、承認、および安全な通信)ならびに機能は、第三者信頼が必要とされ得る、他の実施形態に使用され、適用可能であり得る。
図13に図示される、さらなる実施形態によると、交渉ブローカは、複数の交渉要求を組み合わせ得、交渉効率を向上させるために、複合交渉要求を被交渉側に送信する。図13は、2つの交渉側を示すが、交渉ブローカは、2つより多くの交渉側からの交渉要求を組み合わせることができる。図13は、実際に図12と同一である、交渉側と交渉ブローカとの間の「交渉代理要求および応答」を示さないことに留意されたい。以下のステップが、図13について説明される。
ステップ1では、交渉側AおよびBが、それぞれ、交渉要求を交渉ブローカに送信する。ステップ2では、交渉ブローカが、被交渉側に送信される新しい複合交渉要求の中に、これら2つの交渉要求を入れることによって、両方を組み合わせる。ステップ3では、被交渉側が、提案を行う。このステップは、図6のステップ2に類似する。ステップ4では、被交渉側が、「交渉応答」を交渉ブローカに送信する。このステップは、図6のステップ3に類似する。次に、ステップ5では、交渉ブローカが、両方の交渉側の代わりに提案を選択する。このステップは、図6のステップ4と同一である。後に、ステップ6では、交渉ブローカが、「交渉確認」を被交渉側に送信する。このステップは、図6のステップ5に類似する。
ステップ7では、被交渉側が、「確認応答」を交渉ブローカに送信する。このステップは、図6のステップ6と同一である。ステップ8によると、交渉ブローカは、2つの「交渉応答」を、それぞれ、交渉側AおよびBに送信する。このステップは、図6のステップ10と同一である。次いで、ステップ9では、交渉側AおよびBは、それぞれ、「確認応答」を交渉ブローカに送信する。このステップは、図6のステップ11に類似する。図13は、複数の被交渉側を示さないが、ステップ2からステップ7は、交渉ブローカと別の被交渉側との間の相互作用に適用されることができる。
別の実施形態によると、交渉ブローカは、過負荷になり得、ひいては、それは、その機能を別の交渉ブローカに委託することができる。そのようなブローカ委託は、(交渉側/被交渉側が、現在の交渉ブローカが委託される必要があることを把握することができる場合、および/または新しい交渉ブローカを決定することができる場合に)交渉側/被交渉側によって、もしくは現在の交渉ブローカによって能動的に開始され得る。図14は、現在の交渉ブローカAから新しい交渉ブローカBへのブローカ委託のためのプロシージャを図示する。
ステップ1によると、交渉側(または被交渉側)が、「ブローカ委託要求」を現在の交渉ブローカAに送信する。このメッセージは、新しい交渉ブローカBのアドレス、名称、および/または識別子を含み得るが、それらに限定されない。代替として、現在の交渉ブローカAは、交渉側/被交渉側のための新しい交渉ブローカを選定し得る。このステップは、ブローカ委託が現在の交渉ブローカAによって能動的にトリガされる場合、随意である。
ステップ2では、現在の交渉ブローカAが、「ブローカ委託要求」を新しい交渉ブローカBに送信する。このメッセージは、以下の情報、すなわち、交渉側/被交渉側のアドレス、名称、および識別子、現在の交渉ブローカAが交渉側/被交渉側のための合法ブローカであるかどうかを検証するために使用されることができる、認証情報、新しい交渉ブローカBが交渉側/被交渉側のために有効になる開始時間、新しい交渉ブローカBが交渉側/被交渉側のためのブローカの役割を果たすための持続時間を含み得るが、それらに限定されない。
ステップ3では、新しい交渉ブローカBが、「ブローカ委託応答」を現在の交渉ブローカAに送信する。新しい交渉ブローカBが委託要求を拒否する場合、以下のステップ4および5は、省略され、ブローカ委託は、成功しない。ステップ4によると、現在の交渉ブローカAが、「交渉コンテキスト転送」を新しい交渉ブローカBに送信する。このメッセージは、交渉側/被交渉側のための交渉ポリシ等の必要なコンテキスト情報を新しい交渉ブローカBに転送するために使用される。ステップ5によると、新しい交渉ブローカBが、「交渉コンテキスト応答」を現在の交渉ブローカAに送信する。
次に、ステップ6では、現在の交渉ブローカAが、「ブローカ委託応答」を交渉側/被交渉側に送信する。このメッセージは、以下の情報、すなわち、新しい交渉ブローカBのアドレス、名称、および/または識別子、新しい交渉ブローカBが交渉側/被交渉側の代理の役割を果たすであろう、開始時間ならびに持続時間を含み得る。さらに、ステップ7では、交渉側/被交渉側が、新しい交渉ブローカBとサービス交渉を行うために、説明されるような類似プロシージャを使用する。
さらに別の実施形態によると、交渉側がサービス交渉プロセスを開始するための種々のトリガが説明される。例えば、M2Mデバイスが、全てのデータをローカルに記憶することができない場合がある、増加したデータ量を生成し始めるとき、より多くの記憶容量を得るように、そのM2Mサーバと交渉プロセスを開始し得る。M2Mデバイスが、データをアップロードする速度を増加させなければならないことを見出す場合、記憶されたデータへのより頻繁な動作を要求するために、再度、M2Mサーバと交渉し得る。
デバイス管理のためのM2Mアプリケーションは、新しいM2Mデバイスがシステムの中へ追加されるとき、より多くのM2Mデバイスを管理することを要求するために、そのM2Mサーバと交渉し始め得る。M2Mアプリケーションは、それ自体と別のM2Mアプリケーションとの間のエンドツーエンド遅延が増加したことを見出す。例示的実施形態では、通信は、M2Mサーバによって中継される。M2Mアプリケーションは、M2Mサーバにおいてその要求メッセージをバッファリングするための時間を短縮するために、M2Mサーバとサービス交渉を開始することを希望し得る。
(交渉可能なサービス)
oneM2Mアーキテクチャとの関連で、どのM2Mサービスがどんな方法で交渉されることができるかを説明する実施例が開示される。基本的に、2つのレベルのサービス交渉がある。
レベル1では、M2Mデバイスは、それが使用する必要がある所望のCSFについてM2Mサーバと交渉する。換言すると、M2Mデバイスは、M2Mサーバによって提供されるCSFの一部を使用することを要求し得る。レベル1サービス交渉に対して、図15に示されるような16ビットCSFビットマップが、その選好を示すためにM2Mデバイスによって、および承認されたCSFを示すためにM2Mサーバによって活用され得る。各ビットは、CSFを表し、最後の4つのビットは、将来の使用のために保留される。REG CSFは、他のCSFを使用するためにM2Mデバイスが選定する必要がある、デフォルトCSFであることに留意されたい。
レベル2では、M2Mデバイスはまた、各個々のCSFの特徴または機能性についてM2Mサーバと交渉し得る。レベル2サービス交渉に対して、各CSFは、交渉されることができる、異なる特徴および機能性を有する。例えば、M2Mデバイスは、M2Mサーバによって提供される全てのDM機能性を使用する必要がないこともあるので、所望のDMG機能性についてM2Mサーバと交渉することができる。さらなる実施例および詳細が、表3に挙げられる。CSFビットマップの実施例と同様に、図16は、CSFがM個の特徴を有し、Mビットを必要とすると、各特徴、例えば、CSFのF1、F2が、1ビットによって表される、CSF特徴ビットマップの実施例を図示する。
シナリオ1では、M2Mデバイスがより多くのデータを生成するとき、より多くの記憶容量を得るように、M2Mサーバとの交渉プロセスを開始し得る。以降で、M2Mデバイスが、データが過剰に速く変化し、より頻繁なデータ更新を必要とすることを決定する場合、記憶されたデータへのより頻繁な動作を要求するために、再度、M2Mサーバと交渉し得る。
(新しいCSF:交渉サービス(NGS))
図17は、現在のoneM2M機能アーキテクチャに基づいて、提案される交渉サービスを新しいCSFとして実装するための例示的実施形態を示す。代替として、いくつかのNGS機能が、デバイスブートストラップ、デバイスファームウェアアップロード等の間に起こり得るか、または必要とされ得る、デバイス管理関連交渉を行うために、DMG CSFの一部として追加されることができる。
一実施形態では、このNGS機能は、M2Mサーバ、M2Mゲートウェイ、またはM2Mデバイス等のM2Mノードによってホストされる、M2Mサービス層インスタンス内でホストされ得る。例えば、NGSは、M2Mサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。
図18の実施形態に示されるように、提案されるNGS CSFは、MN−CSE、ASN−CSE、またはIN−CSEの中に常駐することができる。NGS CSFは、上で説明されるように、交渉側、交渉ブローカ、および/または被交渉側の機能性を有するであろう。サービス交渉は、以下の方法で行われることができる。
MN−CSEが、サービスについてIN−CSEと直接交渉する場合、MN−CSEのNGSは、提案を選択する交渉側であり、IN−CSEのNGSは、提案を行う被交渉側であろう。MN−CSEが、サービスについてIN−CSEを介してASN−CSEと間接的に交渉する場合、MN−CSEのNGSは、提案を選択する交渉側であろう。さらに、IN−CSEのNGSは、透過モードでは交渉ブローカであろう。さらに、ASN−CSEのNGSは、提案を行う被交渉側であろう。
IN−AE1が、サービスについてIN−CSEを介してASN−CSEと間接的に交渉する場合、IN−AE1は、交渉側であり、IN−CSEのNGSは、提案を選択するIN−AE1の交渉ブローカであり、ASN−CSEのNGSは、提案を行う被交渉側であろう。
IN−AE2が、サービスについてIN−CSEを介してIN−AE1と間接的に交渉する場合、IN−AE2は、交渉側であり、IN−CSEのNGSは、提案を行い、提案を選択する、IN−AE1およびIN−AE1の両方のための交渉ブローカであり、IN−AE1は、被交渉側であろう。
図19は、ASN−CSEが、中間のMN−CSEを介してサービスについてIN−CSEと交渉する、別の例示的実施形態を示す。ASN−CSEのNGSは、交渉側であり、MN−CSEのNGSは、交渉ブローカであり、IN−CSEのNGSは、被交渉側であろう。
(NGS CSFをサポートする新しいリソース/属性)
別の実施形態では、NGS CSFサービスをサポートするためのoneM2Mリソース構造強化が提案される。リソース構造を説明するためのoneM2M定義図式表現は、以下である:i)四角いボックスが、リソースおよび子リソースに使用され、(ii)丸い角を伴う四角いボックスが、属性に使用され、(iii)新しいリソース<ngtn>。
<ngtn>リソースは、M2Mエンティティが交渉要求を発行し、交渉応答を受信する/読み出すために定義される。各<ngtn>リソースは、2つのM2Mエンティティの間の特定の交渉要求または応答に対応する。それは、図6に図示されるように、交渉要求および交渉応答メッセージに含まれるような情報またはパラメータを維持する。
<ngtn>は、図20および表4に示されるようないくつかの属性およびサブリソースを有する。<ngtn>の親リソースは、<AE>、<CSEBase>、および/または<remoteCSE>であり得る。例えば、IN−AEは、そのホスティングCSEと交渉を開始するために、そのホスティングCSE(例えば、M2Mサーバ)上のその<AE>の下に<ngtn>リソースを作成する。
例えば、MN−CSEは、そのホスティングCSEと交渉を開始するために、そのホスティングCSE(例えば、M2Mサーバ)上のその<remoteCSE>の下に<ngtn>リソースを作成する。
代替として、IN−CSEおよびIN−AEからの交渉要求は全て、それらのホスティングCSEの直下で作成されることができる。この場合、<ngtn>は、ホスティングCSEの<CSEBase>のサブリソースとして作成されるであろう。
さらに別の実施形態によると、<ngtnPolicy>と呼ばれる新しいリソース、例えば、交渉ポリシが、1)被交渉側(またはそのブローカ)が、ポリシに基づいて提案を行う方法を特定するために、または、2)交渉側(またはそのブローカ)が、ポリシに基づいて提案を選択する方法を特定するために使用される。換言すると、2つのタイプのポリシ、すなわち、1)提案を行うためのポリシ、および、2)提案を選択するためのポリシがある。各交渉ポリシは、少なくとも2つの情報、すなわち、条件および結果を含む必要がある。すなわち、「条件」が満たされる場合、「結果」は、ポリシの出力であろう。2つのタイプのポリシがあるので、「結果」は、1)被交渉側またはそのブローカによって行われる提案、または、2)交渉側またはそのブローカによって選択される提案であり得る。
<ngtnPolicy>リソースは、図21および以下の表5に示されるようないくつかの属性およびサブリソースを有する。<ngtnPolicy>の親リソースは、<AE>、<CSEBase>、および/または<remoteCSE>であり得る。<AE>、<CSEBase>、および<remoteCSE>は、参照することによってその全体として組み込まれる、oneM2M−TS−0001,oneM2M Functional Architecture−V1.1.0(August 2014)で説明されるように定義されることに留意されたい。
図22および以下の表6に示されるようなさらなる実施形態によると、「交渉リソース」と呼ばれる新しいリソース、例えば、<ngtnDelegation>が、本願で上に説明されるような交渉委託ブローカ機能をサポートするために提案される。各<ngtnDelegation>は、交渉ブローカ委託要求に対応する。これは、<AE>、<remoteCSE>、または<CSEBase>リソースのサブリソースであり得る。
新しい属性「ngtnBroker」が、<AE>または<remoteCSE>リソースの新しい属性として提案される。<AE>、<CSEBase>、および<remoteCSE>は、参照することによってその全体として組み込まれる、oneM2M−TS−0001,oneM2M Functional Architecture−V1.1.0(August 2014)で説明されるように定義されることに留意されたい。ngtnBrokerが<AE>リソースの属性である場合、それは、<AE>の交渉ブローカを示す。ngtnBrokerが<remoteCSE>リソースの属性である場合、それは、<remoteCSE>の交渉ブローカを示す。
CsfBitMapが、<AE>、<CSEBase>、または<remoteCSE>リソースの新しい属性として提案される。<AE>、<CSEBase>、および<remoteCSE>は、参照することによってその全体として組み込まれる、oneM2M−TS−0001,oneM2M Functional Architecture−V1.1.0(August 2014)で説明されることに留意されたい。csfBitMapが<AE>リソースの属性である場合、それは、<AE>が使用することを要求するCSFのリスト、および/または<AE>のホスティングCSEによって承認されるCSFのリストを意味する。AEが、それ自体をそのホスティングCSEに登録するとき、AEは、その所望のCSFを示すために、アプリケーション登録要求メッセージにcsfBitMapを含み得、順に、ホスティングCSEは、AEに割り付けられている、承認されたCSFを示すために、承認されたcsfBitMapを返し得る。
csfBitMapが<remoteCSE>リソースの属性である場合、それは、<remoteCSE>が使用することを要求するCSFのリスト、および/または<remoteCSE>のホスティングCSEによって承認されるCSFのリストを意味する。CSEが、それ自体をそのホスティングCSEに登録するとき、CSEは、その所望のCSFを示すために、CSE登録要求メッセージにcsfBitMapを含み得、順に、ホスティングCSEは、CSEに割り付けられている、承認されたCSFを示すために、承認されたcsfBitMapを返し得る。csfBitMapが<CSEBase>の属性である場合、それは、このCSEが保有するCSFのリストを意味する。
(NGS CSFをサポートするリソースプロシージャ)
以下の表9で提供されるプロトコルは、<ngtn>リソースを作成するために採用される。具体的には、このプロシージャは、ホスティングCSEの中で特定の<ngtn>リソースを作成するために使用されるものとする。
さらに、表10の中のプロトコルは、既存の<ngtn>リソースから情報を読み出すために使用されるものとする。
表11の中の以下のプロトコルは、既存の<ngtn>リソースの情報を更新するために採用される。
表12で提供されるプロトコルは、既存の<ngtn>リソースを削除するために使用されるものとする。
表13で以下に提供されるプロトコルは、ホスティングCSE上で保留交渉要求<ngtn>を実行するために使用されるものとする。
以下の表14で提供されるプロトコルは、ホスティングCSEの中で特定の<ngtnPolicy>リソースを作成するために使用されるものとする。
以下の表15で提供されるプロシージャは、既存の<ngtnPolicy>リソースから情報を受信するために使用されるものとする。
以下の表16で提供されるプロシージャは、既存の<ngtnPolicy>リソースの情報を更新するために使用されるものとする。
以下の表17の中のプロトコルは、既存の<ngtnPolicy>リソースを削除するために使用されるものとする。
以下の表18の中のプロシージャは、ホスティングCSEの中で特定の<ngtnDelegation>リソースを作成するために使用されるものとする。
以下の表19の中のプロトコルは、既存の<ngtnDelegation>リソースから情報を読み出すために使用されるものとする。
以下の表20の中のプロトコルは、既存の<ngtnDelegation>リソースの情報を更新するために使用されるものとする。
以下の表21の中のプロトコルは、既存の<ngtnDelegation>リソースを削除するために使用されるものとする。
以下の表22の中のプロトコルは、ホスティングCSE上で保留交渉ブローカ委託要求<ngtnDelegation>を実行するために使用されるものとする。
図23は、上で説明される提案されるプロシージャを使用して、サービス交渉の実施例を図示する。ステップの各々は、ローマ数字形態、例えば、001、002等で提供される。ここで、MN−CSEは、交渉側であり、IN−CSEは、被交渉側である。ステップ1によると、MN−CSEが、CREATE要求を発行する。これは、図6のステップ1に類似する。次に、ステップ2では、IN−CSEが、CREATE要求を処理する。次いで、ステップ3では、IN−CSEが、CREATE応答をMN−CSEに送信する。その後、ステップ4では、MN−CSEが、上で説明されるように、作成された<ngtn>を実行するために、特別なUPDATE要求を発行する。これは、図6のステップ1に類似する。後に、ステップ5では、IN−CSEが、提案を行うためにUPDATE要求を処理する。これは、図6のステップ2に類似する。
IN−CSEは、ステップ6でUPDATE応答をMN−CSEに送信する。これは、図6のステップ3に類似する。ステップ7では、MN−CSEが、適切な提案を選択するためにUPDATE応答を処理する。これは、図6のステップ4に類似する。次いで、ステップ8では、MN−CSEが、上で説明されるように<ngtn>/selectedSuggestionsを更新するために、通常のUPDATE要求を発行する。これは、図6のステップ5に類似する。次いで、ステップ9では、IN−CSEが、選択された提案を確認するためにUPDATE要求を処理する。さらに、ステップ10では、IN−CSEが、UPDATE応答をMN−CSEに送信する。これは、図6のステップ6に類似する。
図24は、交渉サービスが新しいサービスコンポーネントとして挿入される、参照することによってその全体として組み込まれる、oneM2M−TS−0007,oneM2MService Component Architecture−V−0.4.0で提供されるようなoneM2M SoAアーキテクチャにおいて、提案される交渉サービスの実施形態を図示する。他のサービスコンポーネントは、Msc参照点を通して交渉サービスと通信し得る。NGSは、Mca参照点に適用されることができ、本開示における提案されるデータ構造およびメッセージも、SOAアーキテクチャに適用されることができることに留意されたい。
本願による適用可能な使用事例では、M2Mサービスオペレータ、例えば、AT&Tが、種々のM2Mサーバから成るスマート交通M2Mサービスプラットフォームを展開する。各M2Mサーバは、デバイス管理用のDMG等のサービスの一式を提供する。自動車レンタル会社、例えば、Hertzは、その車両を管理するために、このプラットフォームを使用してきた。現在、自動車会社は、より多くの新しいハイブリッド自動車を市場に出したい。新しいハイブリッド自動車は、デバイス管理の観点から、さらなる診断および監視機能を必要とする。この新しい要件および管理される新しい自動車の数に起因して、自動車会社のM2Mアプリケーションは、所望のDMG機能性、例えば、より高度な診断機能、グループデバイス管理、これらの新しい自動車のより頻繁な場所更新等についてオペレータと交渉する。
別の使用事例では、M2Mサービスオペレータ、例えば、Googleが、顧客の家庭で、クラウド内のM2MサーバおよびM2Mゲートウェイから成るスマートホームM2Mサービスプラットフォームを展開する(例えば、Google’s NEST)。M2MサーバおよびM2Mゲートウェイは両方とも、データ管理用のDMR等のサービスの一式を提供する。顧客は、ローカルで、例えば、家庭にインストールされたカメラから、センサデータを記憶するために、M2Mゲートウェイを使用していた。現在、夏期であり、顧客は、旅行をする計画であり、1ヶ月間家を留守にするであろう。顧客は、スマートフォンを介して、以前よりも頻繁にカメラデータにアクセスする必要がある。顧客はまた、カメラが任意の異常を検出する場合、オペレータのサービスプラットフォームから自動通知を受信したい。スマートフォン上の顧客のM2Mアプリケーションは、新しい必要性を満たすために、家庭のM2Mゲートウェイの代わりにクラウドの中にカメラデータを記憶/分析するかどうか、およびその方法について、オペレータのサービスプラットフォームと交渉する。NGSの機能性は、M2Mネットワークのノード(例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム)のメモリに記憶され、そのプロセッサ上で実行する、ソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得ることが理解される。
本願によると、本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等のマシンによって実行されると、本明細書に説明されるシステム、方法、ならびにプロセスを実施および/または実装する、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令、例えば、プログラムコードの形態で具現化され得ることが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されることができ、コンピュータによってアクセスされることができる任意の他の物理的媒体を含むが、それらに限定されない。
本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能記命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図6−14および23による、複数のコールフローにおいて上記で開示されるような1つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、上記の図4Cおよび4Dで開示される、メモリ内に記憶され、プロセッサによって実行され、M2Mデバイスならびにサーバを含むデバイス内で採用され得る。一実施形態では、図4Cおよび4Dで上記に説明されるように、不揮発性メモリおよびそこに動作可能に結合されるプロセッサを有する、コンピュータ実装UEが、開示される。具体的には、装置は、サービス属性について交渉するためのその上に記憶された命令を有する、交渉サービス層を有する、不揮発性メモリを含む。
本願のさらなる側面は、コンピュータ実装ネットワーク化システムを説明する。ネットワークは、交渉側と、被交渉側とを含む。交渉側および被交渉側のそれぞれは、データを送信ならびに受信するための送受信機を含む。交渉側および被交渉側のそれぞれはまた、サービス層属性について交渉するためのその上に記憶された命令とともに交渉サービス層を有する、不揮発性メモリを含む。交渉側および被交渉側のそれぞれはまた、サービス層属性の交渉を行うように構成されている、非一過性メモリに動作可能に結合されたプロセッサも含む。ある実施形態によると、交渉側および被交渉側のメモリは、交渉リソース、ポリシリソース、委託リソース、ならびにそれらの組み合わせから選択されるリソースを含む。
システムおよび方法が、現在、具体的側面と見なされるものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正および類似配列を対象にすることが意図され、その範囲は、全てのそのような修正および類似構造を包含するよう、最も広い解釈を与えられるはずである。本開示は、以下の請求項のありとあらゆる側面を含む。

Claims (22)

  1. コンピュータ実装された装置であって、前記コンピュータに実装された装置は、
    不揮発性メモリであって、前記不揮発性メモリには、命令が記憶されており、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
    前記不揮発性メモリに動作可能に結合されたプロセッサと
    を備え、
    前記プロセッサは、
    被交渉側から受信される前記サービス属性を精査することと、
    前記精査されたサービス属性に基づいて、交渉要求を前記被交渉側に送信することと、
    前記被交渉側から提示された提案を受信することと
    を行う命令を実行するように構成されており、
    前記交渉要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、前記被交渉側の所定の交渉ポリシの基準に適合する、コンピュータ実装された装置。
  2. 前記プロセッサは、前記提示された提案を選択するようにさらに構成されている、請求項1に記載のコンピュータ実装された装置。
  3. 前記選択は、前記被交渉側の所定の交渉ポリシに対してチェックされる、請求項2に記載のコンピュータ実装された装置。
  4. 前記交渉要求を送信するステップは、ブローカを介して前記被交渉側に送信される、請求項1に記載のコンピュータ実装された装置。
  5. 前記提示された提案を受信するステップは、前記ブローカを介して前記被交渉側から受信される、請求項4に記載のコンピュータ実装された装置。
  6. 前記メモリおよび前記プロセッサに動作可能に接続されたグラフィカルユーザインターフェースを含むディスプレイをさらに備え、前記グラフィカルユーザインターフェースは、前記提示された提案を表示するように構成されている、請求項1に記載のコンピュータ実装された装置。
  7. 前記ディスプレイ上の前記提示された提案は、提案、別の被交渉側との交渉推奨、れらの組み合わせから選択される情報を含む、請求項に記載のコンピュータ実装された装置。
  8. コンピュータ実装された装置であって、前記コンピュータに実装された装置は、
    不揮発性メモリであって、前記不揮発性メモリには、命令が記憶されており、前記命令は、交渉サービス層がサービス属性について交渉するためのものである、不揮発性メモリと、
    前記不揮発性メモリに動作可能に結合されたプロセッサと
    を備え、
    前記プロセッサは、
    被交渉側から前記サービス属性について交渉するための交渉ポリシを受信することと、
    前記サービス属性について交渉するための要求を交渉側から受信することと、
    前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと、
    提示された提案を前記被交渉側から受信することと
    を行う命令を実行するように構成されており、
    前記要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、前記被交渉側ポリシの基準に適合する、コンピュータ実装された装置。
  9. 前記プロセッサは、提示された提案を前記交渉側に送信するようにさらに構成されている、請求項8に記載のコンピュータ実装された装置。
  10. 前記不揮発性メモリは、共通属性、作成、読み出し、削除、更新、実行、標識、ブローカ、タイプ、提案を行うための入力、提案を選択するための入力、開始、ステータス、標的、参照、提示された提案、選択された提案、出力パラメータ、サブスクリプション、れらの組み合わせから選択される交渉リソースを記憶し、
    前記プロセッサは、前記サービス属性について交渉するために前記交渉リソースを用いる請求項8に記載のコンピュータ実装された装置。
  11. 前記不揮発性メモリは、共通属性、標識、交渉タイプ、交渉側、被交渉側、条件、結果、規則の選択、サブスクリプション、れらの組み合わせから選択されるポリシリソースを記憶し、
    前記プロセッサは、前記サービス属性について交渉するために前記ポリシリソースを用いる請求項8に記載のコンピュータ実装された装置。
  12. 前記不揮発性メモリは、共通属性、標識、クライアント、現在の交渉ブローカ、新しい交渉ブローカ、委託有効化、開始時間、持続時間、結果、サブスクリプション、れらの組み合わせから選択される委託リソースを記憶し、
    前記プロセッサは、前記サービス属性について交渉するために前記委託リソースを用いる請求項8に記載のコンピュータ実装された装置。
  13. コンピュータ実装された交渉側およびコンピュータ実装された被交渉側を備えているネットワーク化システムであって、前記交渉側および前記被交渉側の各々は、
    データを送信および受信するための送受信機と、
    交渉サービス層を有する不揮発性メモリであって、前記不揮発性メモリには、命令が記憶されており、前記命令は、サービス層属性について交渉するためのものである、不揮発性メモリと、
    前記不揮発性メモリに動作可能に結合されたプロセッサと
    を含み、
    前記プロセッサは、前記サービス層属性の交渉を行うように構成されており、
    前記サービス層属性の前記交渉は、要求および提示された提案を含み、
    前記要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、被交渉側ポリシの基準に適合する、ネットワーク化システム。
  14. 前記プロセッサは、
    被交渉側から前記サービス層属性について交渉するための前記交渉ポリシを受信することと、
    前記サービス層属性について交渉するための前記要求を交渉側から受信することと、
    前記要求が前記被交渉側ポリシの基準に適合するかどうかを決定することと
    を行う命令を実行するように構成されている、請求項13に記載のネットワーク化システム。
  15. 前記不揮発性メモリは、交渉リソース、ポリシリソース、委託リソース、れらの組み合わせから選択されるリソースを含む、請求項13に記載のネットワーク化システム。
  16. コンピュータ実装された方法であって、前記方法は、
    被交渉側から受信される交渉可能なサービス層属性を精査することと、
    前記精査された交渉可能なサービス層属性に基づいて、交渉要求を前記被交渉側に送信することと、
    前記被交渉側から提示された提案を受信することと、
    前記提示された提案を選択することと
    み、
    前記交渉要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、前記被交渉側の所定の交渉ポリシの基準に適合する、方法。
  17. 前記受信される提示された提案は、前記被交渉側の所定の交渉ポリシに対してチェックされる、請求項16に記載の方法。
  18. 前記交渉要求は、サービスid、提案を行うための入力、提案される提案、れらの組み合わせから選択される情報を含む、請求項16に記載の方法。
  19. コンピュータ実装された方法であって、前記方法は、
    被交渉側から交渉可能なサービス層属性について交渉するための交渉ポリシを受信することと、
    前記交渉可能なサービス層属性について交渉するための要求を交渉側から受信することと、
    前記要求が前記被交渉側ポリシの所定の基準に適合するかどうかを決定することと、
    提示された提案を前記交渉側に送信することと
    を含み、
    前記要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、前記被交渉側ポリシの所定の基準に適合する、方法。
  20. 前記交渉側から交渉確認を受信することと、
    前記交渉確認の確認応答を前記被交渉側に送信することと
    をさらに含む、請求項19に記載の方法。
  21. コンピュータ実装された方法であって、前記方法は、
    交渉側から交渉可能なサービス層属性に対する交渉要求を受信することと、
    前記交渉可能なサービス層属性を有する被交渉側の場所を特定することと、
    前記交渉要求を前記被交渉側に送信することと、
    前記被交渉側から前記交渉可能なサービス層属性に対する提示された提案を受信することと
    を含み、
    前記交渉要求は、複数の提案される提案を含み、
    前記提示された提案は、前記複数の提案される提案から選択された提案を含み、前記複数の提案される提案は、前記被交渉側の所定の交渉ポリシの基準に適合する、方法。
  22. 前記提示された提案を前記交渉側に送信することと、
    前記交渉側から交渉確認を受信することと、
    前記交渉確認の確認応答を前記被交渉側に送信することと
    をさらに含む、請求項21に記載の方法。
JP2017547928A 2014-12-01 2015-12-01 サービス層における交渉サービスをサポートする方法 Expired - Fee Related JP6435057B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462086102P 2014-12-01 2014-12-01
US62/086,102 2014-12-01
PCT/US2015/063164 WO2016089854A1 (en) 2014-12-01 2015-12-01 Method for supporting negotiation service at a service layer

Publications (2)

Publication Number Publication Date
JP2017537422A JP2017537422A (ja) 2017-12-14
JP6435057B2 true JP6435057B2 (ja) 2018-12-05

Family

ID=54851390

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017547928A Expired - Fee Related JP6435057B2 (ja) 2014-12-01 2015-12-01 サービス層における交渉サービスをサポートする方法

Country Status (6)

Country Link
US (1) US10555151B2 (ja)
EP (1) EP3227842A1 (ja)
JP (1) JP6435057B2 (ja)
KR (1) KR101985118B1 (ja)
CN (1) CN107113182B (ja)
WO (1) WO2016089854A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11095533B1 (en) * 2018-03-07 2021-08-17 Amdocs Development Limited System, method, and computer program for implementing a marketplace for edge computing
KR20180048845A (ko) * 2015-09-01 2018-05-10 콘비다 와이어리스, 엘엘씨 서비스 계층 등록
KR102169930B1 (ko) * 2016-05-05 2020-10-26 한국전자기술연구원 M2M/IoT 플랫폼에서의 시맨틱 정보 관리 방법
WO2018057601A1 (en) * 2016-09-20 2018-03-29 Convida Wireless, Llc Service layer support for multiple interface nodes
KR20180086044A (ko) * 2017-01-20 2018-07-30 삼성전자주식회사 지능 협상을 수행하는 반도체 장치의 동작 방법
EP3692441A1 (en) 2017-10-06 2020-08-12 Convida Wireless, LLC Enabling a fog service layer with application to smart transport systems
EP4240035A1 (en) 2017-10-23 2023-09-06 Convida Wireless, LLC Methods to enable data continuity service
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
CN112398662B9 (zh) * 2017-11-16 2021-12-03 华为技术有限公司 一种计费方法、装置及系统
CN109474544A (zh) * 2018-11-20 2019-03-15 郑州云海信息技术有限公司 一种互联云资源的分配方法及系统
EP3667579A1 (en) * 2018-12-13 2020-06-17 Siemens Aktiengesellschaft Negotiation-based method and system for coordinating distributed mes order management
EP3907672A1 (en) * 2020-05-04 2021-11-10 Siemens Aktiengesellschaft Distributing order execution in a mom system
US12058193B2 (en) * 2021-06-30 2024-08-06 Tencent America LLC Bidirectional presentation datastream

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490058B2 (en) * 2001-03-29 2009-02-10 International Business Machines Corporation Automated dynamic negotiation of electronic service contracts
US10445795B2 (en) * 2003-07-31 2019-10-15 Swiss Reinsurance Company Ltd. Systems and methods for multi-level business processing
US8543686B2 (en) 2009-07-23 2013-09-24 University-Industry Cooperation Group Of Kyung Hee University Dynamic resource collaboration between network service providers
JP5443625B2 (ja) * 2010-03-01 2014-03-19 インターデイジタル パテント ホールディングス インコーポレイテッド マシンツーマシンゲートウェイのアーキテクチャおよび機能性
CN102395209B (zh) * 2010-11-08 2015-07-29 开曼群岛威睿电通股份有限公司 机器对机器应用的类别识别方法及其移动装置与服务网络
TWI610552B (zh) * 2011-02-11 2018-01-01 內數位專利控股公司 管理機器對機器(m2m)實體系統、方法及裝置
CN103068005B (zh) * 2011-07-14 2016-09-14 华为终端有限公司 实现机器对机器业务的方法、m2m终端、ap和系统
US9800999B2 (en) * 2013-02-19 2017-10-24 Lg Electronics Inc. Method for modifying M2M service setting and apparatus therefor
JP2016526207A (ja) 2013-05-06 2016-09-01 コンヴィーダ ワイヤレス, エルエルシー モノのインターネットのための知的交渉サービス

Also Published As

Publication number Publication date
WO2016089854A1 (en) 2016-06-09
CN107113182A (zh) 2017-08-29
US10555151B2 (en) 2020-02-04
CN107113182B (zh) 2020-05-01
US20170272894A1 (en) 2017-09-21
KR20170091126A (ko) 2017-08-08
JP2017537422A (ja) 2017-12-14
KR101985118B1 (ko) 2019-05-31
EP3227842A1 (en) 2017-10-11

Similar Documents

Publication Publication Date Title
JP6435057B2 (ja) サービス層における交渉サービスをサポートする方法
US11765150B2 (en) End-to-end M2M service layer sessions
JP6560442B2 (ja) サービス層動的承認
TWI623205B (zh) 在虛擬網路中端對端架構、api框架、發現及存取
KR102492203B1 (ko) 기기간 통신 네트워크에서의 자동화된 서비스 등록
JP6612437B2 (ja) サービス層登録
JP7246379B2 (ja) 通信ネットワークにおけるサービス層メッセージテンプレート
JP6462134B2 (ja) サービス層におけるリソースリンク管理
EP3320650B1 (en) Service layer anycast and somecast
CN111989941A (zh) 用于分流IoT应用消息生成和响应处理的服务层方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170728

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180516

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180601

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180830

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: 20181022

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181109

R150 Certificate of patent or registration of utility model

Ref document number: 6435057

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

LAPS Cancellation because of no payment of annual fees