JP2021536606A - フォグベースのデータ処理を有効にするためのデータサンプルテンプレート（Ｄａｔａ Ｓａｍｐｌｅ Ｔｅｍｐｌａｔｅ：ＤＳＴ）管理 - Google Patents

フォグベースのデータ処理を有効にするためのデータサンプルテンプレート（Ｄａｔａ Ｓａｍｐｌｅ Ｔｅｍｐｌａｔｅ：ＤＳＴ）管理 Download PDF

Info

Publication number
JP2021536606A
JP2021536606A JP2021510347A JP2021510347A JP2021536606A JP 2021536606 A JP2021536606 A JP 2021536606A JP 2021510347 A JP2021510347 A JP 2021510347A JP 2021510347 A JP2021510347 A JP 2021510347A JP 2021536606 A JP2021536606 A JP 2021536606A
Authority
JP
Japan
Prior art keywords
data
dst
data sample
agent
dscs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021510347A
Other languages
English (en)
Other versions
JP7458377B2 (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 JP2021536606A publication Critical patent/JP2021536606A/ja
Application granted granted Critical
Publication of JP7458377B2 publication Critical patent/JP7458377B2/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
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/022—Capturing of monitoring data by sampling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • 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/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
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • 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
    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • 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]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Automation & Control Theory (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【解決手段】データサンプル収集サービス（Data Sample Collection Service：ＤＳＣＳ）は、ユーザから種々のデータサンプル収集要求を受信し、ユーザの代わりに、１つ以上の要求を処理するように構成され得る。ユーザが必要とする使用準備済のデータサンプル（Ready-to-Use Data Sample：ＲＤＳ）の種類を適切に説明するために、ＤＳＣＳは、データサンプルテンプレート（Data Sample Template：ＤＳＴ）を採用し得る。ＤＳＴを使用することによって、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプルがどのようなものかを明確に表し得る。ＤＳＣＳは、さらに、ＤＳＴ管理機能をユーザに提供し得る。一般に、ＤＳＴ管理は、ＤＳＴ作成、ＤＳＴ更新、ＤＳＴ削除、およびＤＳＴ有効化／無効化のプロセスを含む。例えば、ユーザは、ＤＳＴを、そのデータサンプル収集の必要性に基づいて作成し得る。後に、作成されたＤＳＴはまた、ユーザの必要性に対する動的な変更に基づいて更新および／または削除され得る。

Description

近年、世界中のデータ量は、種々の分野で急増しつつある。例えば、ウェブ検索エンジンは、数百ペタバイト（Petabyte：ＰＢ）の検索データを処理し、ソーシャルネットワークアプリケーションは、１ヶ月あたり１０ＰＢを上回るログデータを生成し得る。急増するグローバルデータの結果、用語「ビッグデータ」が、莫大なデータセットを説明するために造り出された。従来のデータセットと比較して、ビッグデータは、典型的には、顧客の買物履歴記録から潜在的購入をどのように発見するかなどの、このデータからの徹底的洞察を得るために分析する必要がある膨大な非構造化データを含む。
データサンプル収集サービス（Data Sample Collection Service：ＤＳＣＳ）を実装するための方法およびシステムが開示される。ＤＳＣＳは、ユーザから種々のデータサンプル収集要求を受信し、ユーザの代わりに、１つ以上の要求を処理するように構成され得る。ユーザが必要とする使用準備済のデータサンプル（Ready-to-Use Data Sample：ＲＤＳ）の種類を適切に説明するために、ＤＳＣＳは、データサンプルテンプレート（ＤＳＴ）を採用し得る。ＤＳＴを使用することによって、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプルがどのようなものかを明確に表し得る。
ＤＳＣＳは、さらに、ＤＳＴ管理機能をユーザに提供し得る。一般に、ＤＳＴ管理は、ＤＳＴ作成、ＤＳＴ更新、ＤＳＴ削除、およびＤＳＴ有効化／無効化のプロセスを含む。例えば、ユーザは、ＤＳＴを、そのデータサンプル収集の必要性に基づいて作成し得る。後に、作成されたＤＳＴはまた、ユーザの必要性に対する動的な変更に基づいて更新および／または削除され得る。ＤＳＴに対して行われる変更はまた、対応するＤＳＴの対応するデータサンプルに対する変更につながり得る。
協働的なデータソース（Data Source：ＤＳ）識別およびフォグベースのサービス層（Service Layer：ＳＬ）についての使用準備済のデータサンプル（ＲＤＳ）生成のための方法およびシステムがさらに開示される。協働的なＤＳ識別プロシージャの間、データサンプル収集要求（Data Sample Collection Request：ＤＳＣＲ）に対応するＲＤＳでのデータ要素（Data Element：ＤＥ）の各々について、ローカルフォグエリア（Local Fog Area：ＬＦＡ）で数千の潜在的ＤＳがあり得、それは、それがこのＤＳＣＲを供給するための所望のＤＳであるかどうかを判定するために発見および／または評価される必要がある。データソースディスカバー（Data Source Discover：ＤＳＤ）として機能し得る、ＬＦＡ内の異なるローカルフォグノード（Local Fog Node：ＬＦＮ）は、異なるＤＳ識別および発見能力を有し得る。故に、１つ以上のＬＦＡ内の（ＤＳＤとしての）複数のＬＦＮが、所与のＤＳＣＲのための所望のＤＳを識別するために一緒に協働的に機能することを可能にする、方法およびシステムが提供される。
所与のＬＦＮは、ＤＳ識別能力を有し得るが、所望の／識別されたＤＳからのデータの収集などのデータ収集能力、または、ＲＤＳを生成するための未加工データの処理などの特定のデータ処理能力を有しない場合がある。したがって、本明細書に開示されるＤＳ識別プロセスは、所与のＤＳＣＲによって要求されるようなＲＤＳでのＤＥの各々について、所望のＤＳを識別することを指すだけでなく、ＲＤＳを生成するために未加工データを処理するための未加工データプロセッサ（Raw Data Processor：ＲＤＰ）として機能し得る適切なＬＦＮを見出すだけでなく、それらの識別されたＤＳから未加工データを収集するための未加工データコレクタ（Raw Data Collector：ＲＤＣ）として機能し得る適切なＬＦＮを見出すことを指す。本明細書に開示される協働的なＤＳ識別のための方法およびシステムは、ＲＤＣ発見を伴うＤＳ識別、ＤＳ識別結果統合、およびＲＤＣ／ＲＤＰジョブ割り当てを含むが、それらに限定されない。
ＲＤＳ生成プロシージャの間、ＤＳから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理はまた、協働的に行われる必要があり得る。所与のＤＳＣＲについて、異なるＬＦＮが、このＤＳＣＲのためにＲＤＳを生成するために要求される種々のデータ処理能力を有し得るため、そのデータ処理は、複数のＲＤＰをクロスさせ得る。本明細書に開示される協働的なＲＤＳ生成のための主なソリューションは、所与のＤＳＣＲのためのＲＤＳ生成、所与のＤＥのためのＲＤＳ生成、および所与のＤＳＣＲのためのＲＤＳアセンブリングのトリガを含むが、それらに限定されない。
本概要は、詳細な説明で以下にさらに説明される、単純化された形態でのコンセプトの選択を導入するために提供される。本概要は、請求された主題の主要な機構または必須の機構を識別するのを意図したものでもなく、請求された主題の範囲を限定するために使用されるのを意図したものでもない。さらに、請求された主題は、本開示の任意の部分で記されるいずれかまたはすべての欠点を解決する限定に限定されない。
本出願のよりしっかりとした理解を促進するために、ここで、添付図面に対する参照が行われ、ここで、同様の要素は、同様の数字で参照される。これらの図面は、本出願を限定するように解釈されるべきでなく、例示的であることだけが意図される。
例示的フォグコンピューティングシステムアーキテクチャのブロック図を示す。 例示的ｏｎｅマシンツーマシン（Machine-to-Machine：Ｍ２Ｍ）アーキテクチャのブロック図を示す。 例示的ｏｎｅＭ２Ｍ共通サービス機能（Common Service Function：ＣＳＦ）のブロック図を示す。 例示的スマートシティ分析ユースケースのフローチャートを示す。 データサンプルテンプレート（ＤＳＴ）を使用する、データサンプル収集サービス（ＤＳＣＳ）のための例示的ハイレベルアーキテクチャのフローチャートを示す。 ＬＦＡで反応ＤＳ識別を伴うＤＳＴ作成のための例示的プロシージャのフローチャートを示す。 ＬＦＡでの事前対応ＤＳ識別でのＤＳＴ作成のための例示的プロシージャのフローチャートを示す。 再使用を介したＤＳＴ作成のための例示的プロシージャのフローチャートを示す。 ルートＤＳＴ（Root DST：Ｒ−ＤＳＴ）分割を使用するＤＳＴ作成のための例示的プロシージャのフローチャートを示す。 ＲＤＳ生成のための第１の例示的構成を示す。 ＲＤＳ生成のための第２の例示的構成を示す。 １つ以上の新しいデータ要素（ＤＥ）を既存のＤＳＴに追加するためのＤＳＴ更新のための例示的プロシージャのフローチャートを示す。 ＤＳＴ更新または１つ以上のＤＳＴの削除もしくは全ＤＳＴの削除のための例示的プロシージャのフローチャートを示す。 ＤＳＴステータスの例示的状態マシンモデルのブロック図を示す。 ｏｎｅＭ２Ｍサービス層のための例示的新しいＤＳＣＳ ＣＳＦのブロック図を示す。 新しいｏｎｅＭ２Ｍリソース＜ｄｓｃｓ＞の例を示す。 例示的ユーザインターフェースを示す。 例示的データサンプル収集サービスのアーキテクチャ図を示す。 ローカルフォグノードリーダーへのローカルフォグノード能力登録のための例示的方法のフローチャートを示す。 未加工データコレクタ発見を伴うデータサンプル識別のための例示的方法のフローチャートを示す。 データソース識別結果統合のための例示的方法のフローチャートを示す。 ローカルフォグエリアで使用準備済のデータサンプル生成プロシージャを開始するための例示的方法のフローチャートを示す。 所与のデータ要素のための使用準備済のデータサンプル生成のための例示的方法のフローチャートを示す。 所与のデータサンプル収集要求のための使用準備済のデータサンプル生成のための例示的方法のフローチャートを示す。 例示的ユーザインターフェースを示す。 １つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（Internet of Things：ＩｏＴ）通信システムの例示的システム図を示す。 図２６Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る例示的アーキテクチャの例示的システム図を示す。 図２６Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの例示的システム図を示す。 図２６Ａの通信システムの態様が具現化され得る例示的コンピューティングシステムの例示的ブロック図を示す。
従来のデータセットと比較して、ビッグデータは、典型的には、顧客の買物履歴記録から潜在的購入をどのように発見するかなどの、このデータからの徹底的洞察を得るために分析する必要がある膨大な非構造化データを含む。一般に、いくつかの「Ｖｓ」を指す、ビッグデータの一般的定義が存在する。
Ｖｏｌｕｍｅ（量）について、大量のデータの生成および収集に伴って、データスケールが、ますます大きくなる（例えば、インターネット企業によって生成されるデータが、１日あたり数十のＰＢに容易に到達し得る）。
Ｖａｒｉｅｔｙ（多様性）は、オーディオ、ビデオ、ウェブページ、およびテキストなどの半構造化および非構造化データ、ならびにデータベーステーブルのような従来の明確に定義された構造化データを含む、種々のタイプのデータを示す。
Ｖｅｌｏｃｉｔｙ（速度）について、ビッグデータの時系列（例えば、データ収集および分析）が、ビッグデータの商業的価値を最大化するように、タイムリーな様式で処理されなければならない。
Ｖａｌｕｅ（価値）について、データ内に隠蔽される有用な知識および洞察が存在するが、それらは、非常に低密度であり得る。
典型的には、例えば、物理的世界に組み込まれ、ネットワークによってコンピューティングリソースに接続される、センサおよびデバイスを指す、マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）通信の出現が、ビッグデータにおける成長を駆動する主要な傾向であることは、着目に値する。例えば、世界中に展開される接続されたＩｏＴノードの数が、年間３０パーセントを超える率で成長することが予期される。それらの膨大なＩｏＴノードは、大量のデータを生成することが予期され、それは、ＩｏＴデータ処理のためにコスト効率のソリューションを要求する。
エッジコンピューティングにより、ＩｏＴデバイスによって生成されるデータが、長いルートにわたってそれをデータセンターまたはクラウドに送信する代わりに、それが作成される場所のより近くで処理されることが可能になる。
エッジコンピューティング展開は、種々の状況で理想的であり得る。一例示的シナリオは、ＩｏＴデバイスが乏しいコネクティビティを有し、ＩｏＴデバイスが中央クラウドに常に接続されるのが効率的でない場合である。他のシナリオは、情報の待ち時間感知処理との関係があり得る。データが、処理のためのデータセンターまたはクラウドにネットワークを介して横断する必要がないため、エッジコンピューティングは、待ち時間を低減する。
フォグコンピューティングは、エッジデバイスとクラウドとの間のネットワーク接続を指す。他方では、エッジコンピューティングは、より具体的には、エッジデバイスの近くで行われる計算プロセスを指す。したがって、フォグコンピューティングは、エッジコンピューティングを含み得るが、フォグコンピューティングはまた、処理されたデータをその最終目的地に送り出すために必要とされるネットワークを組み込み得る。正式には、フォグコンピューティング（または簡潔には、フォグ）は、エンドユーザにより近いコンピューティング、記憶装置、制御、およびネットワーキングなどのリソースおよびサービスをクラウドからモノへの連続体に沿って移動させるシステムレベルアーキテクチャである。例示的フォグ有効連続体が、図１に示される。
一般に、「データ分析」は、広い用語である。したがって、市場において多くのタイプのデータ分析製品（例えば、グーグルアナリティクス、ＩＢＭワトソン、分散されたデータ処理のためのオープンソースＡｐａｃｈｅ Ｈａｄｏｏｐエコシステムなど）が存在する。
Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ ＩｏＴ Ｅｄｇｅは、クラウド分析およびカスタムビジネスロジックをエッジでのデバイスに移動させる例示的製品である。一般に、Ａｚｕｒｅ ＩｏＴ Ｅｄｇｅは、３つのコンポーネントで構成されている。
ＩｏＴ Ｅｄｇｅモジュールは、Ａｚｕｒｅサービス、第三者サービス、または開発者自身のコードを実行するコンテナである。それらは、ＩｏＴ Ｅｄｇｅデバイスに展開され、それらのデバイス上でローカルに実行され得る。ＩｏＴ Ｅｄｇｅモジュールは、現在、Ｄｏｃｋｅｒ互換性コンテナとして実装され、エッジでユーザのビジネスロジックを実行する、実行のユニットである。複数のモジュールは、相互に通信し、データ処理のパイプラインを作成するように構成され得る。
ＩｏＴ Ｅｄｇｅ実行時間は、各ＩｏＴ Ｅｄｇｅデバイス上で実行し、各デバイスに展開されるモジュールを管理する。
クラウドベースのインターフェースは、ユーザが、ＩｏＴ Ｅｄｇｅデバイスを遠隔で監視および管理することを可能にする。
ＡＷＳ Ｇｒｅｅｎｇｒａｓｓは、ローカル計算、メッセージング、および接続されたデバイスについてのデータキャッシング能力をユーザに実行させるソフトウェアである。ＡＷＳ Ｇｒｅｅｎｇｒａｓｓを用いて、接続されたデバイスは、ＡＷＳ Ｌａｍｂｄａ機能（イベント処理サービス）を実行し、デバイスデータを同期した状態に維持し、インターネットに接続されていないときでさえ、セキュアに他のデバイスと通信し得る。
ＡＷＳ Ｇｒｅｅｎｇｒａｓｓは、異なるタイプのデバイスをクラウドと相互に接続するＩｏＴソリューションをユーザに構築させる。ＡＷＳ Ｇｒｅｅｎｇｒａｓｓ Ｃｏｒｅを実行するデバイスは、Ａｍａｚｏｎ ＦｒｅｅＲＴＯＳを実行しているか、またはＡＷＳ ＩｏＴ Ｄｅｖｉｃｅ ＳＤＫがインストールされた、他のデバイスと通信し得るハブとして機能する。
ＡＷＳ Ｇｒｅｅｎｇｒａｓｓ Ｃｏｒｅデバイス、ＡＷＳ ＩｏＴ Ｄｅｖｉｃｅ ＳＤＫ有効デバイス、およびＡｍａｚｏｎ ＦｒｅｅＲＴＯＳデバイスは、エッジでＧｒｅｅｎｇｒａｓｓ Ｇｒｏｕｐ内で相互に通信するように構成され得る。Ｇｒｅｅｎｇｒａｓｓ Ｃｏｒｅデバイスが、クラウドへのコネクティビティを失う場合、Ｇｒｅｅｎｇｒａｓｓ Ｇｒｏｕｐ内のデバイスは、ローカルネットワークを介して相互に通信し続け得る。Ｇｒｅｅｎｇｒａｓｓ Ｇｒｏｕｐは、例えば、ビルの１つのフロア、１つのトラック、または全マイニングサイトを表し得る。
開発下のｏｎｅＭ２Ｍ規格は、「共通サービスエンティティ（Common Service Entity：ＣＳＥ）」と呼ばれるサービス層を定義する（oneM2M-TS-0001 oneM2M Functional Architecture -V3.8.0を参照）。サービス層の目的は、異なる「バーティカル」Ｍ２Ｍシステムおよびアプリケーションによって利用され得る「ホリゾンタル」サービスを提供することである。ＣＳＥは、図２に示されるように、４つの参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（Application Entity：ＡＥ）とインターフェース接続する。Ｍｃｃ参照点は、同じサービスプロバイダドメイン内の別のＣＳＥとインターフェース接続し、Ｍｃｃ’参照点は、異なるサービスプロバイダドメインでの別のＣＳＥとインターフェース接続する。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェース接続する。ＮＳＥは、デバイス管理、ロケーションサービス、およびデバイストリガなどの仮想ネットワークサービスをＣＳＥに提供する。
ＣＳＥは、「発見」および「データ管理＆リポジトリ」などの「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。図３は、ｏｎｅＭ２Ｍによって定義されるＣＳＦのいくつかを図示する。
ｏｎｅＭ２Ｍアーキテクチャは、以下の例示的タイプのノードを有効にする。
アプリケーションサービスノード（Application Service Node：ＡＳＮ）について、ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含む、ノードである。物理的マッピングの例について、ＡＳＮは、Ｍ２Ｍデバイス内に常駐し得る。
アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）について、ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まない、ノードである。ｏｎｅＭ２Ｍシステムのフィールドドメイン内に０個以上のＡＤＮが存在し得る。物理的マッピングの例について、アプリケーション専用ノードは、制約Ｍ２Ｍデバイス内に常駐し得る。
中間ノード（Middle Node：ＭＮ）について、ＭＮは、１つのＣＳＥを含み、０個以上のＡＥを含む、ノードである。ｏｎｅＭ２Ｍシステムのフィールドドメイン内に０個以上のＭＮが存在し得る。物理的マッピングの例について、ＭＮは、Ｍ２Ｍゲートウェイ内に常駐し得る。
インフラストラクチャノード（Infrastructure Node：ＩＮ）について、ＩＮは、１つのＣＳＥを含み、０個以上のＡＥを含む、ノードである。インフラストラクチャドメイン内に、ｏｎｅＭ２Ｍサービスプロバイダにつき、ちょうど１つのＩＮが存在する。ＩＮ内のＣＳＥは、他のノードタイプに適用可能でないＣＳＥ機能を含み得る。物理的マッピングの例について、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ内に常駐し得る。
非ｏｎｅＭ２Ｍノード（Non-oneM2M Node：ＮｏＤＮ）について、非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを（ＡＥもＣＳＥも）含まないノードである。そのようなノードは、管理を含む、相互作用の目的のためのｏｎｅＭ２Ｍシステムに取り付けられたデバイスを表す。
例示的スマートシティ分析ユースケースが図４に示される。スマートシティを構築するために、市当局は、（ｏｎｅＭ２Ｍなどの）規格ベースのサービス層（ＳＬ）プラットフォームを採用し、（道路およびストリート、公共ビル、バスおよび地下鉄などの）市の公共インフラストラクチャ上に多くのＩｏＴセンサおよびデバイスを展開している。その一方で、制限された予算に起因して、市当局はまた、このスマートシティのイニシャティブのために、私的な組織および個人の関与を要求する。故に、（私的な車、携帯電話などの）私的な財産上にインストールされたそれらのＩｏＴデバイスはまた、システム内に統合され、それは、シティのリアルタイム実行ステータスを反映する大量の広範なＩｏＴデータを生成し得る。
シティは、中心業務地区（Central Business District：ＣＢＤ）、郊外住宅エリアなどの多くの地理的領域を有し得、それは、ローカルフォグエリア（ＬＦＡ）と称され得る。膨大な量のＩｏＴデバイスが、それらのＬＦＡで展開され得、大量のＩｏＴデータが、それらのＬＦＡから生成され得る。通信ネットワーク観点から、異なるシティ領域が、複数のＬＦＡを構成する（例えば、図４に示されるように、ＣＢＤが、ＬＦＡ−１に対応し、郊外住宅エリアが、ＬＦＡ−２に対応する）。
スマートシティ制御コンソールは、ユーザが、必要性に基づいて種々のデータ分析要求を呈することを可能にするクラウドで展開される。例えば、組織Ａからのユーザは、所与のエリアについての現在の気象および環境汚染ステータス（例えば、大規模道路工事およびビル建設下のエリアである、図４に示されるようなＬＦＡ−Ｘ）を評価することを意図する、（要求１として示される）要求を有し得る。実際には、データ分析結果は、通常は、種々のチャート（例えば、ラインチャートまたはバーチャート）を介して表される。ユーザが見ることを意図する分析チャートのタイプに加え、それらはまた、データサンプルがあるべき姿、チャートを描くための入力がどれかを規定し得る。チャートを描くためのそれらのデータサンプルを準備するために、関連する未加工データが、（温度センサ、湿度センサ、汚染センサ、騒音センサなどの）ＬＦＡでの種々のＩｏＴデバイスから収集される必要がある。特に、それらのセンサまたはデバイスは、（ユーザが入っている）組織Ａ以外の異なる組織によってインストールされ得る。異なる組織の間で相互作用を処理するとき、種々の制約（例えば、異なる組織の間での相互作用の複雑性）、ならびに膨大なＩｏＴデータの潜在的に被る、通信および処理コストを考慮することによって、効率的な方法でこれを行うことが、主要な課題である。
一例では、要求１で、ユーザがＬＦＡ−Ｘについてのラインチャートを見ることを意図し、それは、３分毎に１つのデータサンプルを要求することを想定する。特に、各データサンプルは、以下の２つのデータ要素によって構成され得、データ要素の各々は、品質要件に対応付けられ得る。
データ要素（ＤＥ）−１について、最後の３分におけるＬＦＡ−Ｘの平均温度。
ＤＥ−１の品質要件について、温度読み取り値は、精度を保証するために、ＬＦＡ−Ｘで展開される、少なくとも１００個の異なる温度センサから収集される必要がある。
ＤＥ−２について、最後の３分におけるＬＦＡ−Ｘの平均騒音レベル。
ＤＥ−２の品質要件について、騒音読み取り値は、ＬＦＡ−Ｘでの３０個の主要な交差点で展開される騒音センサから収集される必要がある。
クラウドで展開されるスマートシティ制御コンソール上でラインチャートを描くために、（ＤＥ−１、ＤＥ−２、タイムスタンプ）のフォーマットを有するデータサンプルは、３分毎に必要とされる。
以下の技術的課題は、上記のユースケースに関連して識別され得る。
問題１について、スマートシティ分析ユースケースが、ＬＦＡからすべての必要なＩｏＴデータを収集し、クラウドで中央データ処理を行うことであるのを実現するための直接のソリューション。例えば、初期の例でのＤＥ−１を考慮し、１００個の温度読み取り値が、３分毎にＬＦＡから収集され、次いで、データ処理（例えば、それらの１００個の読み取り値の平均値の計算）が行われるクラウドに転送される。見られ得るように、中央データ処理は、ＬＦＡからクラウドへの大量のデータ移動に起因する多量の通信オーバーヘッドにつながる。
問題２について、ユーザは、ＬＦＡでの利用可能なＩｏＴデータソースについての知識を有しない場合がある。例えば、スマートシティユースケースでは、展開されたＳＬプラットフォームはまた、異なる組織および個人から多くのＩｏＴデバイスを統合する。故に、クラウド側からのユーザは、それらのＩｏＴデバイスを展開した同じグループでない場合がある。その結果、ユーザは、所望のデータサンプルのためのデータソースとして使用され得る所望のＩｏＴデバイスを識別するためにＬＦＡを自身で探索しなければならない。そのような要件は、特に、ＬＦＡで適切な発見能力を有しない場合に、ユーザに余分な負荷を呈する。
問題３について、既存のＩｏＴエッジ製品は、ユーザが「エッジツークラウド」構成能力を有しない場合があるという事実に起因して有用でない場合がある。例えば、（Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ ＩｏＴ ＥｄｇｅまたはＡｍａｚｏｎ Ｇｒｅｅｎｇｒａｓｓなどの）既存の製品の大部分は、ユーザが、通常、ＬＦＡでのデバイス／ノード（例えば、エッジでのセンサ、ゲートウェイなど）についての知識および構成能力を有する、比較的単純なケースをサポートするように構成されている。言い換えると、ユーザは、自身の使用のためにエッジ分析アプリケーションを構築したいと思うとき、何のエッジデバイスが接続されるべきかを知り得、また、エッジ側で直接、データ処理を行うための分析処理コード／ユニットを実行するために、それらのノード（例えば、ゲートウェイ）を構成するための能力を有し得る。しかしながら、これは、ユーザが、ＬＦＡでの多くのＩｏＴデバイスの所有者でないか、または他の異なるグループまたは組織によって所有され得るＬＦＡでの任意のノードを構成するための任意の能力を有しない例でのケースではない。その結果、既存のＩｏＴエッジ製品は、そのような異種シナリオで機能しない場合がある。
全体としてサービス層観点から、ＳＬベースのプラットフォームは、多くの場合、異なるドメインの間でアプリケーションを有効にするホリゾンタルプラットフォームであることが想定される。言い換えると、そのようなホリゾンタルプラットフォームは、異種アプリケーションシナリオについての所望の特性である、異なるグループおよび／または組織からのリソースを統合するのに優れているべきである。そうするために、（ｏｎｅＭ２Ｍなどの）ＳＬベースのプラットフォームは、多くの場合、多くのタイプの共通サービスを提供し、それは、ユーザが詳細に関与することを可能にすることなく、またはそうすることを要求することなく、（発見、デバイス管理などの）異なるタイプの動作をユーザが行うことを可能にし得る。しかしながら、既存のＳＬベースのプラットフォームソリューションは、現在、フォグコンピューティングパラダイムを活用することによって効率的なデータサンプル収集および処理をサポートするための共通サービスまたは能力を提供しない。
フォグベースのサービス層（ＳＬ）のためのデータサンプル収集サービス（ＤＳＣＳ）が本明細書に開示される。ＤＳＣＳは、フォグコンピューティングパラダイムに基づくＳＬでのサービスである。ＤＳＣＳを用いて、ＤＳＣＳのユーザは、受信することを意図するＲＤＳのタイプについてその必要性を規定し得、ＤＳＣＳは、ＬＦＡですべてのことを処理し、所望のＲＤＳを生成するように構成され得る。
データサンプルテンプレート（ＤＳＴ）もまた開示される。ＤＳＴは、ユーザが受信することを意図するＲＤＳのタイプについてのすべての詳細を記載し、それは、ＬＦＡでＩｏＴ未加工データ収集および未加工データ処理を行うためのＤＳＣＳのためのガイドラインである。
以下の態様のうちの１つ以上を含み得る、「ＤＳＴ管理」のための方法およびシステムもまた開示される。
いくつかの例示的ソリューションが、異なるアプリケーションシナリオで使用され得る、「ＤＳＴ作成プロセス」のために本明細書に開示され、以下のことを含むが、それらに限定されない。
シナリオ１についてのＬＦＡでの反応ＤＳ識別を伴うＤＳＴ作成、
シナリオ２についてのＬＦＡでの事前対応ＤＳ識別を伴うＤＳＴ作成、
シナリオ３についてのＤＥ再使用を介したＤＳＴ作成、および
シナリオ４についてのＤＳＴ分割を伴うＤＳＴ作成。
いくつかのソリューションが、「ＤＳＴ更新／削除プロセス」のために開示され、以下のことを含むが、それらに限定されない。
新しいＤＥを既存のＤＳＴに追加するか、または既存のＤＳＴでいくつかの情報を単に更新するためのＤＳＴ更新プロセス、および
既存のＤＳＴで１つ以上のＤＥを削除するか、または全ＤＳＴを削除するためのＤＳＴ更新プロセス。
いくつかのソリューションが、「ＤＳＴ有効化プロセス」のために開示され、以下のことを含むが、それらに限定されない。
所与のＤＳＴが、ＤＳＴ内の「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータで示されるパラメータに基づいて有効にされ得る。
所与のＤＳＴが、ユーザ自体からの信号に基づいて有効にされ得る。
所与のＤＳＴが、ＬＦＡで発生したイベントに基づいて有効にされ得る。
本開示全体を通して使用される用語のうちのいくつかについての例示的定義が以下に説明される。
クラウドノード（Cloud Node：ＣＮ）について、展開階層でより下の他のフォグノードの動作を管理するクラウド能力を有するノード。用語「クラウド」は、クラウドノードを指すために使用され得ることに留意されたい。さらに、クラウドは、アプリケーションのためのフォグサービス層を一緒に有効にする、異なるフォグノード間の相互作用を監視および管理する。
ローカルフォグエリア（ＬＦＡ）について、地理的領域（例えば、シティ）は、異なるアプリケーションシナリオに応じて複数のＬＦＡに分割され得る。例えば、スマートシティシナリオでは、特定の住宅エリアが、ＬＦＡであり得るか、またはダウンタウンエリア内のＣＢＤが、ＬＦＡであり得る。
ローカルフォグノード（ＬＦＮ）について、ＬＦＮは、計算、記憶、および通信能力を有するＬＦＡ内のノードであり得る。ＬＦＮは、その対応するＬＦＡ内のＬＦＮリーダー（LFN Leader：ＬＦＮＬ）と通信および相互作用し得る。例えば、ＬＦＮは、人の携帯電話、移動バス、または家のホームゲートウェイなどであり得る。ＬＦＮは、ネットワークの最も低いレベルであるフォグノード（Fog Node：ＦＮ）のタイプである。ＬＦＮは、ＬＦＡ内の他のＬＦＮと相互作用および協働し得、ＤＳからのデータの発見、取得、および処理を行い得る。
データソース（ＤＳ）について、ノードは、それがＩｏＴデータのソースの場合、ＤＳであり得る。例えば、ＤＳは、センサ、カメラ、交通灯、またはデータを生成する任意のＩｏＴデバイスであり得る。ロードサイドユニットはまた、それが道路表面に関連するセンサデータを生成するため、ＤＳであり得る。その一方で、ロードサイドユニットはまた、それが、あるデータ処理能力を行い得、および／またはＬＦＮＬと通信し得るため、ＬＦＮであり得る。センシングを有するだけでなく、コンピューティング、記憶、および通信能力を有する、ＬＦＡ内のノードは、ＬＦＮおよびＤＳであり得る。
ＬＦＮリーダー（ＬＦＮＬ）について、所与のＬＦＡは、フォグエリア内のＬＦＮリーダーを有し得る。ＬＦＮＬは、そのＬＦＡ内のすべてのＬＦＮを管理し、また、より高いレベルにあるＦＮに接続されている。例えば、スマートシティの例では、ＬＦＮＬは、特定の住宅エリアの主要ゲートウェイであり得る。
フォグノード（ＦＮ）について、計算、記憶、通信、分析などの任意のフォグリソースを有するノード。フォグノードは、これらのリソースのうちの少なくとも１つを有し得、また、フォグノード上で実行している他のソフトウェアまたはサービスを有し得る。ＦＮは、ＬＦＮのレベルよりも高いあるレベルで展開されることが想定される。ＣＮが最も高いレベルにある状態でＦＮ展開のいくつかのレベルが存在し得る。例えば、スマートシティユースケースでは、ＦＮは、ネットワーク内のより高いレベルでのルーターであり得る。
本開示で提案されるアイディアが、フォグ関連用語を使用して説明されるが、本開示で提案されるアイディアがまた、エッジシナリオに適用され得ることは、着目に値する。例えば、ＬＦＡはまた、エッジでの特定のエリアとして解釈され得、ＬＦＮは、エッジ側でのノードであり得、ＬＦＮＬは、エッジでのゲートウェイまたはエッジでのロードサイドユニットなどであり得る。
データサンプル収集サービス（ＤＳＣＳ）と称され得る、サービス層のための新しい共通サービスが本明細書に開示される。ＤＳＣＳのハイレベルアーキテクチャが図５に示される。開示されたＤＳＣＳは、以下の能力のうちの１つ以上を有し得る。
ＤＳＣＳは、ユーザから種々のデータサンプル収集要求を受信し、そのユーザの代わりに、すべての詳細を処理し得る。
（例えば、制御コンソール上でラインチャートを描くために）ユーザが必要とする使用準備済のデータサンプル（ＲＤＳ）の種類を適切に説明するために、ＤＳＣＳは、データサンプルテンプレート（ＤＳＴ）と呼ばれる新しいコンセプトを採用する。ＤＳＴを使用することによって、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプルがどのようなものかを明確に表し得る。
ＤＳＣＳは、ＤＳＴ管理機能をユーザに提供し得る。一般に、ＤＳＴ管理は、ＤＳＴ作成、ＤＳＴ更新、ＤＳＴ削除、およびＤＳＴ有効化／無効化のプロセスを含む。例えば、ユーザは、ＤＳＴを、そのデータサンプル収集の必要性に基づいて作成し得る。後に、作成されたＤＳＴはまた、必要性に対する動的な変更に基づいて更新および／または削除され得る。ＤＳＴに対して行われる変更はまた、このＤＳＴの対応するデータサンプルに対する変更につながり得る。
ＤＳＣＳは、作成されたＤＳＴを有効または無効にするためにインターフェースをユーザに提供し得る。一例では、ＤＳＴの実際のＲＤＳ生成は、このＤＳＴが有効なステータスにあるまで開始されない場合があることに留意されたい。
例示的方法は、データサンプルテンプレートを作成するための要求を受信することであって、データサンプルテンプレートを作成するための要求が、１つ以上のデータ要素に対応付けられる情報を含む、受信することと、１つ以上のデータ要素に対応付けられる情報に基づいて、データサンプルテンプレートを作成することと、データサンプル収集サービスの第２のエージェントに、１つ以上のデータ要素に対応付けられる１つ以上のデータソースを識別するための要求を送信することであって、データサンプル収集サービスの第２のエージェントが、ローカルフォグノード上に配置される、送信することと、データサンプル収集サービスの第２のエージェントから、１つ以上のデータソースに対応付けられる情報を受信することと、１つ以上のデータソースに対応付けられる情報に基づいて、データサンプルテンプレートを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第１のエージェントを含み得る。
データサンプルテンプレートを作成するための要求は、作成されるデータサンプルのタイプのインジケーションを含み得る。データサンプルテンプレートを作成するための要求は、１つ以上のパラメータのインジケーションをさらに含み得、１つ以上のパラメータは、データサンプルに対応付けられる標的領域と、データサンプルに対応付けられる頻度と、データサンプルに対応付けられる生成スケジュールと、データサンプルに対応付けられる状況と、を含む。方法は、１つ以上のパラメータに基づいて、複数のローカルフォグノードのうちのどれを標的とするかを判定することをさらに含み得る。１つ以上のデータ要素に対応付けられる情報は、未加工データタイプのデータ要素、データ要素のユニット、データ要素のデータ処理動作、データ要素の１つ以上のカスタマイズされた処理詳細、およびデータ要素の１つ以上の品質要件のうちの１つ以上を含み得る。方法は、データサンプル収集サービスの第２のエージェントに、構成されたデータサンプルテンプレートを送信することをさらに含み得る。データサンプル収集サービスの第２のエージェントは、構成されたデータサンプルテンプレートに基づいて、使用準備済のデータサンプルを生成するように構成され得る。
例示的方法は、第１のデータサンプルテンプレート、第２のデータサンプルテンプレート、および第３のデータサンプルテンプレートに基づいて生成することであって、第２のデータサンプルテンプレートが、データ要素の第１のセットに対応付けられ、第３のデータサンプルテンプレートが、データ要素の第２のセットに対応付けられる、生成することと、データサンプル収集サービスの第２のエージェントに、データ要素の第１のセットに対応付けられるデータソースの第１のセットを識別するための要求を送信することであって、データサンプル収集サービスの第２のエージェントが、第１のローカルフォグノードに配置される、送信することと、データサンプル収集サービスの第３のエージェントに、データ要素の第２のセットに対応付けられるデータソースの第２のセットを識別するための要求を送信することであって、データサンプル収集サービスの第３のエージェントが、第２のローカルフォグノードに配置される、送信することと、データサンプル収集サービスの第２のエージェントから、データソースの第１のセットに対応付けられる情報を受信することと、データサンプル収集サービスの第３のエージェントから、データソースの第２のセットに対応付けられる情報を受信することと、データソースの第１のセットに対応付けられる情報、およびデータソースの第２のセットに対応付けられる情報のうちの１つ以上に基づいて、第２のデータサンプルテンプレートおよび第３のデータサンプルテンプレートのうちの少なくとも１つを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第１のエージェントを含み得る。
方法は、データサンプルテンプレートを作成するための要求を受信することであって、データサンプルテンプレートを作成するための要求が、１つ以上のデータ要素に対応付けられる情報を含む、受信することと、１つ以上の受信されたデータ要素に対応付けられる情報に基づいて、第２のデータサンプルテンプレートおよび第３のデータサンプルテンプレートを作成することと、をさらに含み得る。１つ以上の受信されたデータ要素に対応付けられる情報は、データ要素の第１のセットに対応付けられる情報と、データ要素の第２のセットに対応付けられる情報と、を含み得る。方法は、１つ以上の受信されたデータ要素に対応付けられる情報に基づいて、複数のローカルフォグノードのうちの１つ以上を標的とすることを判定することをさらに含み得る。第２のデータサンプルテンプレートおよび第３のデータサンプルテンプレートの各々は、以下のパラメータ、すなわち、データサンプルのそれぞれのセットに対応付けられる標的領域、データサンプルのそれぞれのセットに対応付けられる頻度、データサンプルのそれぞれのセットに対応付けられる生成スケジュール、およびデータサンプルのそれぞれのセットに対応付けられる状況のうちの１つ以上を含み得る。方法は、データサンプル収集サービスの第２のエージェントに、構成された第２のデータサンプルテンプレートを送信することと、データサンプル収集サービスの第３のエージェントに、構成された第３のデータサンプルテンプレートを送信することと、をさらに含み得る。データサンプル収集サービスの第２のエージェントは、構成された第２のデータサンプルテンプレートに基づいて、第１の使用準備済のデータサンプルを生成するように構成され得る。データサンプル収集サービスの第３のエージェントは、構成された第３のデータサンプルテンプレートに基づいて、第２の使用準備済のデータサンプルを生成するように構成され得る。
例示的方法は、新しいデータ要素を既存のデータサンプルテンプレートに追加する要求を受信することであって、既存のデータサンプルテンプレートが、複数のデータ要素を含む、使用準備済のデータサンプルに対応付けられる、受信することと、新しいデータ要素に基づいて、既存のサンプルテンプレートを更新することと、データサンプル収集サービスの第２のエージェントに、新しいデータ要素に対応付けられる１つ以上のデータソースを識別するための要求を送信することであって、データサンプル収集サービスの第２のエージェントが、ローカルフォグノード上に配置される、送信することと、データサンプル収集サービスの第２のエージェントから、１つ以上のデータソースに対応付けられる情報を受信することと、１つ以上のデータソースに対応付けられる情報に基づいて、更新されたデータサンプルテンプレートを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第１のエージェントを含み得る。
新しいデータ要素を追加するための要求は、既存のデータサンプルテンプレートの識別子、および新しいデータ要素のための標的領域のうちの１つ以上を含み得る。新しいデータ要素に対応付けられる情報は、未加工データタイプのデータ要素、データ要素のユニット、データ要素のデータ処理動作、データ要素の１つ以上のカスタマイズされた処理詳細、およびデータ要素の１つ以上の品質要件のうちの１つ以上を含み得る。新しいデータ要素を追加するための要求は、既存のデータ要素を更新するための要求を含み得る。データ要素を更新するための要求は、既存のデータサンプルテンプレートの識別子、および更新されるデータ要素の１つ以上のパラメータのうちの１つ以上を含み得る。方法は、データサンプルテンプレートを更新する前に、データサンプルテンプレートを無効にすることをさらに含み得る。
上記のようなＤＳＣＳの能力を実装するために、以下の詳細が説明される。
一般に、（ＬＦＮ、ＦＮ、またはＣＮ上で実装されるものなどの）サービス層ノードは、このノードがデータサンプル収集関連サービスを提供することを意図する場合、ＤＳＣＳエージェントを有し得る。ＳＬノード上のＤＳＣＳエージェントは、ユーザによって呈される種々のデータサンプル収集タスクを行うために、ＤＳＣＳユーザと相互作用するだけでなく、他のＤＳＣＳエージェントと協働し得る、ソフトウェアのピースである。
ＤＳＣＳエージェントとＤＳＣＳユーザとの間の相互作用に関して、ＤＳＣＳエージェントは、ＤＳＴ作成、ＤＳＴ更新、およびＤＳＴ削除の観点でＤＳＴ管理をサポートするために、インターフェースをＤＳＣＳユーザに提供し得る。例えば、図５に示されるように、ＤＳＣＳエージェント（例えば、ＤＳＣＳエージェント１）は、ＣＮで展開され、それは、ＣＮで、異なるユーザからの分析要求を受け入れ得る。
ＤＳＣＳエージェント間で相互作用および協働もまた存在し得る。例えば、ＤＳＣＳエージェントはまた、（そのＬＦＡで、すべての未加工データ収集および処理を処理し得る）ＬＦＡのＬＦＮＬで展開される必要があり得る。典型的には、ＣＮでのＤＳＣＳエージェント１は、ユーザの必要性に基づいてＤＳＴを作成し、このＤＳＴが展開されるべきＬＦＡがどれかを見出し得る。例えば、ユーザが、単に、特定のＬＦＡからデータサンプルを収集したいと思う場合、ＤＳＴは、そのＬＦＡ内のＤＳＣＳエージェント（例えば、ＤＳＣＳエージェント２）に展開され得る。展開の間、あるワークスレッド（例えば、コードスニペット）が、ＤＳＣＳエージェント２上に設定され得る。特に、ＤＳＣＳエージェント２は、このＬＦＡで所望のＤＳを識別し、要求されたデータ処理動作を行い、ＲＤＳを生成し、単にＣＮでＲＤＳをユーザに送信し返すことを担い得る。全体として、それらのＤＳＣＳエージェントは、種々のデータサンプル収集要求を満たすために一緒に機能し得る。
ＳＬ内の共通サービスとして、ＤＳＣＳは、システムが異なるグループまたは組織から（デバイス、ノードなどの観点で）リソースを統合する場合でさえ、フォグコンピューティングパラダイムを実現し得る。より重要なのは、ＤＳＣＳが、ユーザが、ＬＦＡで未加工データを収集し、ＬＦＡで展開されるＤＳＣＳエージェント上で直接、未加工データを分析／処理するのに役立ち得ることである。言い換えると、このプロセス全体を通して、ユーザは、ＬＦＡで適格なＤＳをどのように識別するか、および未加工データ処理のためにそれらのＬＦＡでＬＦＮをどのように構成するかに関する任意の詳細において関与する必要がない場合がある。その結果、ユーザは単に、ＤＳＴを作成することによって、所望のＲＤＳについての必要性を規定する必要があり得る。すべての他の残りの処理は、開示されたＤＳＣＳによって処理され得る。
ＤＳＣＳユーザは、ＬＦＡからデータサンプルを収集する必要性を有するとき、ＤＳＣＳエージェントに送信され得るデータサンプル収集要求でその必要性を記載し得る。故に、ＤＳＴが作成され得、それは、このＤＳＴについてのＲＤＳ生成をどのように行うかについてのすべての詳細を含む。以下に示されるように、表１（表１−１〜表１−７）は、ＤＳＴについての詳細な定義を与える。
Figure 2021536606
Figure 2021536606
Figure 2021536606
Figure 2021536606
Figure 2021536606
Figure 2021536606
Figure 2021536606
本開示の第１の態様では、ＤＳＴ作成プロセスのための方法およびシステムが開示される。
作成される所与のＤＳＴについて、このＤＳＴについての所望のＤＳであるかどうかを判定するために発見および評価される必要がある（そのようなプロセスは、ＤＳ識別プロセスと称され得る）、ＬＦＡ内の多数（例えば、数千）の潜在的ＤＳが存在し得る。その一方で、それらのＤＳから収集される未加工データはまた、多数であり得、ＲＤＳを生成するための膨大な未加工データに対するデータ処理は、ＲＤＳ生成プロセスと称され得る。（制御プレーン問題としての）ＤＳＴ管理と比較して、ＤＳ識別およびＲＤＳ生成は、実際のＲＤＳ生成についての「データプレーン」問題と同様である。
第１の例では、ＬＦＡで反応ＤＳ識別を伴うＤＳＴ作成プロセスが論じられる。この例では、識別されるＬＦＡで所望のＤＳを必要とするＤＳＴ作成要求が存在するまで、ＤＳ識別が行われない場合がある。これは、ＬＦＡ内のＤＳＣＳエージェントが単に、制限されたエネルギーもしくは処理能力を有するか、またはＬＦＡ内のＤＳの利用可能性が頻繁に変化する（例えば、ＤＳが移動車両上に備わる場合、それらのＤＳは、異なる時間間隔で異なるＬＦＡで利用可能であり得るという意味において、異なるＬＦＡの間で移動し得る）、シナリオに適用可能であり得る。
図６は、ＬＦＡで反応ＤＳ識別を伴うＤＳＴ作成プロセスのための例示的プロシージャを図示する。
ステップ１で、この例示的システムでは、ＣＮ上にＤＳＣＳエージェントが存在する。ユーザ１は、データサンプル収集の必要性を有し、ＳＬによって提供されるＤＳＣＳを使用することを意図する。故に、ユーザ１は、ＣＮ上でＤＳＣＳエージェント１にコンタクトすることを決定する。
ステップ２で、ユーザ１は、受信したいと思うデータサンプルのタイプについての情報とともに、ＤＳＴ作成要求をＤＳＣＳエージェント１に送信する。特に、メッセージは、（表１でさらに説明されるような）以下のパラメータのうちの１つ以上を含み得る。
Ｔａｒｇｅｔｅｄ＿Ｒｅｇｉｏｎ、
Ｄａｔａ＿Ｓａｍｐｌｅ＿Ｆｒｅｑｕｅｎｃｙ、
ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ、および
ＲＤＳ＿Ｃｏｎｔｅｘｔ。
所望のＲＤＳに含まれるＤＥの各々について、要求は、このＤＥについての詳細を説明する以下のパラメータを有し得る。
Ｒａｗ＿Ｄａｔａ＿Ｔｙｐｅ、
Ｕｎｉｔ、
Ｄａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎ、
Ｃｕｓｔｏｍｉｚｅｄ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｄｅｔａｉｌｓ、および
Ｑｕａｌｉｔｙ＿Ｒｅｑｕｉｒｅｍｅｎｔｓ。
ステップ３で、ユーザ１からの情報に基づいて、ＤＳＣＳエージェント１は、ＤＳＴ−１を作成する。ＤＳＣＳエージェント１はまた、ユーザ１によって提供されないＤＳＴ−１での他の情報を構成する必要があり、「ＤＳＴ＿Ｕｓｅｒｓ」（例えば、ユーザ１）と、「ＤＳＴ＿Ｉｎｉｔｉａｔｏｒ」（例えば、ユーザ１）と、「Ｃｒｅａｔｉｎｇ＿ＤＳＣＳ＿Ａｇｅｎｔ＿ＩＤ」（例えば、ＤＳＣＳエージェント１）と、を含む。しかしながら、ＤＳＴ−１のステータスは、これまでＤＳがＤＳＴ−１について識別されていないため、「ＤＳＴ＿Ｓｔａｔｕｓ」パラメータで「実行不可能」に設定され得る。故に、ＤＳＣＳエージェント１は、どのＬＦＡがこのＤＳＴ−１に関与するかを決定する。例えば、「Ｔａｒｇｅｔｅｄ＿Ｒｅｇｉｏｎ」パラメータに含まれる詳細に基づいて、ＤＳＣＳエージェント１は、ユーザ１が関心のある地理的領域が、通信ネットワークスタンドポイントからのどのＬＦＡに対応するかを見出し得る。この例では、１つのＬＦＡのみが関与する（例えば、ＬＦＡ−１）。加えて、Ｔｙｐｅ＿ｏｆ＿ＤＳＴは、ＤＳＴ−１が分割されないため、Ｒ−ＤＳＴの値で設定され得る。次に、ＤＳＣＳエージェント１は、ＤＳＴ−１についてのＤＳ識別プロセスをトリガするために、ＬＦＡ−１内のＬＦＮＬ上のＤＳＣＳエージェント（例えば、ＤＳＣＳエージェント２）にコンタクトする必要がある。
ステップ４で、所望のＤＥの各々についてのユーザ１からの情報に基づいて、ＤＳＣＳエージェント１は、未加工データ上で実行されるデータ処理動作のタイプ、および関連する品質要件などの他の詳細な情報とともに、ＤＳＴ−１についてのＤＳ識別をトリガするために要求をＤＳＣＳエージェント２に送信する。言い換えると、この場合のＤＳＣＳエージェント２は、ＤＳＴ−１の「インフィールドマネージャ」である。（シナリオ１で考慮されるような）分割される予定のない所与のＤＳＴについて、そのインフィールドマネージャは、対応するＬＦＡでＤＳ識別およびＲＤＳ生成を行うための中央コントローラであり得ることに留意されたい。特に、ＤＳＴが（この場合、ＤＳＴ−１などの）Ｒ−ＤＳＴである場合、そのインフィールドマネージャは、このＤＳＴでの対応するＤＥの未加工データが（ＤＳＴ−１でのそれらのＤＥの各々についてのＤａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎパラメータで示されるようなデータ処理動作を使用して）処理され、それが、この全体のＤＳＴ−１についてのＲＤＳの生成につながる場所であり得る。
ステップ５で、ＤＳＣＳエージェント１から要求を受信した後、ＬＦＡ−１内のＤＳＣＳエージェント２は、所望のＤＳが、ＤＳＴ−１でのＤＥのすべてについて識別され得るかどうかを見るためのＤＳ識別を行う（例えば、ＤＳＣＳエージェント２は、ＤＳ識別を行うためにＬＦＡ−１内の他のＬＦＮをコーディネート／管理し得る）。
ステップ６で、ＤＳＣＳエージェント２は、ＤＳ識別結果をＤＳＣＳエージェント１に返す。この例では、所望のＤＳが、ＤＳＴ−１でのＤＥのすべてについて識別されていることが想定される。ＤＳ識別が失敗した（例えば、所望のＤＳがＤＳＴ−１でのＤＥのすべてについて識別されていない）場合、ＤＳＴ作成プロセスは終了し得、ＤＳＣＳエージェント１は、ＤＳＴ作成は成功でなかったことを（例えば、ステップ１１で）ユーザ１に通知し得る。
ステップ７で、ＤＳＣＳエージェント１はまた、ＤＳＴ−１で他の情報を構成する必要があり得、「Ｉｎ＿Ｆｉｅｌｄ＿Ｍａｎａｇｅｒ＿ＩＤ」（例えば、この例では、ＤＳＣＳエージェント２）を含む。ＤＳＣＳはまた、「ＤＳＴ＿Ｓｔａｔｕｓ」パラメータで「実行可能な」ＤＳＴとしてＤＳＴ−１をマークする。
ステップ８で、一旦、ＤＳＴ−１が完全に構成されると、ＤＳＣＳエージェント１は、フィールド展開のためにＤＳＴ−１をＤＳＣＳエージェント２に送信する。
ステップ９で、ＤＳＣＳエージェント２は、次のＲＤＳ生成動作のためにＤＳＴ−１についてワークスレッドを開始するために、ある設定または構成を行う。例えば、ユーザ１が、特定のＤＥについての未加工データを処理するためのコードスニペットを提供した場合、そのようなコードスニペットは、ＤＳＣＳエージェント２、またはＬＦＡ−１内のＬＦＮＬによって管理される別のＬＦＮ上でインストールされ得る。
ステップ１０で、ＤＳＣＳエージェント２は、ＤＳＴ−１のフィールド展開が完了したことを確認する。
代替として、ステップ５で、ＤＳＣＳエージェント１はまた、所望のＤＳがステップ６の間にＤＳＴ−１でのＤＥのすべてについて識別された場合、ＤＳＴ−１のワークスレッドが（ステップ９のように）直接設定され得るかどうかを示し得る。この場合、ステップ８およびステップ１０は、必要とされない場合がある。
ステップ１１で、ＤＳＣＳエージェント１は、ＤＳＴ−１が成功して作成され、また、ここで実行可能であることを、ある情報（例えば、ＤＳＴ＿ＩＤ）とともにユーザ１に通知する。
第２の例では、ＬＦＡで事前対応ＤＳ識別を伴うＤＳＴ作成プロセスが論じられる。この例では、ＬＦＡ内のＤＳＣＳエージェントは、ＤＳＴ作成要求が存在しない場合でさえ、ＤＳ識別を事前に行い得る。このソリューションは、ＬＦＡ内のＤＳＣＳエージェントが十分なエネルギーおよび強力な処理能力を有するか、またはＤＳの利用可能性が、それが予め識別され得るように頻繁に変化しないシナリオに適用可能であり得る。
図７は、ＬＦＡで事前対応ＤＳ識別を伴うＤＳＴ作成プロセスのための例示的プロシージャを図示する。
前提条件として、ＤＳＣＳエージェント２は、ＬＦＡ−１のリアルタイムＤＳカタログをＤＳＣＳエージェント１に定期的に送信し得る。
ステップ１は、図６のステップ１と同じであり得る。
ステップ２は、図６のステップ２と同じであり得る。
ステップ３で、ユーザ１からの情報に基づいて、ＤＳＣＳエージェント１は、ＤＳＴ−１を作成する。ＤＳＣＳエージェント１はまた、ユーザ１によって提供されないＤＳＴ−１でのいくつかの他の情報を構成する必要があり得、「ＤＳＴ＿Ｕｓｅｒｓ」（例えば、ユーザ１）と、「ＤＳＴ＿Ｉｎｉｔｉａｔｏｒ」（例えば、ユーザ１）と、「Ｃｒｅａｔｉｎｇ＿ＤＳＣＳ＿Ａｇｅｎｔ＿ＩＤ」と、を含む。ＤＳＣＳエージェント１はまた、どのＬＦＡ（例えば、この例では、ＬＦＡ−１）がＤＳＴ−１で関与するかを決定し得、次いで、ＤＳＣＳエージェント１は、関与するＬＦＡのＬＦＮＬ（例えば、この例では、ＤＳＣＳエージェント２）から送信される最新のＤＳカタログをチェックし得る。このカタログに基づいて、所望のＤＳがＤＳＴ−１でのＤＥのすべてについて識別され得る場合、ＤＳＴ−１は、「実行可能な」ＤＳＴとしてマークされ得る。ＤＳＴ−１が完全に構成された後、それは、フィールド展開のために、（この例では、ＤＳＴ−１のフィールドマネージャである）ＤＳＣＳエージェント２に送信され得る。
ステップ４は、図６のステップ８と同じであり得る。
ステップ５は、図６のステップ９と同じであり得る。
ステップ６は、図６のステップ１０と同じであり得る。
ステップ７は、図６のステップ１１と同じであり得る。
第３の例では、ＤＥ再使用を介したＤＳＴ作成が論じられる。この例では、異なるＤＳＴがすでにＤＳＣＳエージェント上で作成されているとき、それは、ＤＳＴリポジトリでそれらのＤＳＴをホストまたは記憶し得る。故に、作成される新しいＤＳＴ（例えば、ＤＳＴ−１００）について、それが、リポジトリで記憶される１つ以上の既存のＤＳＴにすでに含まれるＤＥと重複し得ることが可能である。その結果、それらのＤＥは、ＤＳＴ−１００を作成するために再使用され得、それは、再使用され得るＤＳＴ−１００でのそれらのＤＥのためにＤＳ識別プロセスを行うためのかなりの労力を省き得る。
図８は、ＤＥ再使用を介したＤＳＴ作成プロセスのための例示的プロシージャを図示する。
前提条件として、ＤＳＣＳエージェント１は、すでに作成されたすべての既存のＤＳＴを記憶する、ＤＳＴリポジトリを維持する。
ステップ１は、図６のステップ１と同じであり得る。
ステップ２は、図６のステップ２と同じであり得る。代替として、ＤＳＣＳエージェント１は、リポジトリで記憶される既存のＤＳＴをＤＳＣＳユーザがチェックおよび照会するために、アクセスインターフェースをＤＳＣＳユーザに直接提供し得る。この場合、ユーザ１は最初に、リポジトリを照会し、既存のＤＳＴでのどのＤＥが再使用され得るかを整理し得る。次いで、このステップで、ユーザ１が受信したいと思う所望のＲＤＳが何かを説明するとき、それは、既存のＤＳＴでのどのＤＥが再使用されるべきかを直接示し得る。
ステップ３で、ユーザ１からの情報に基づいて、ＤＳＣＳエージェント１は、ＤＳＴ−１００を作成する。ユーザ１が、ステップ２でどのＤＥが再使用されるべきかを示さなかった場合、ＤＳＣＳエージェント１はさらに、リポジトリを検索し、既存のＤＳＴでのどのＤＥが、ＤＳＴ−１００での必要とされたＤＥについて再使用され得るかを整理する。特に、各ＤＥが、それがＤＳＴで定義されるときに、いくつかの特性および品質要件を有するため、既存のＤＳＴでの１つのＤＥが、別の新しく作成されたＤＳＴでさらに再使用され得るかどうかを評価するときに、この情報を評価することが必要であり得る。例えば、ユーザ１について作成されるＤＳＴ−１００が３つのＤＥを有する（例えば、ＤＳＴ−１のＲＤＳが以下のフォーマット、すなわち、（ＤＥ−１、ＤＥ−２、ＤＥ−３、ＲＤＳ＿Ｃｏｎｔｅｘｔ）を有する）ことを想定して、ＤＳＴリポジトリでは、すべての特性および品質要件が一致しているため、既存のＤＳＴ−１でのＤＥ−６は、ＤＳＴ−１００でのＤＥ−２として再使用され得、一方、ＤＳＴ−３でのＤＥ−２７は、ＤＳＴ−１００でのＤＥ−３として使用され得ることが可能である。既存のＤＳＴでのそれらの再使用されたＤＥのすべての詳細の説明は、ＤＳＴ−１００に複製され得る。加えて、対応するパラメータは、ＤＳＴ−１００でのそれらのＤＥの各々について構成され得る。例えば、「Ｒｅｕｓｅｄ」パラメータは、ＤＳＴ−１００のＤＥ−２およびＤＥ−３について「真」で設定され得、「Ｒｅｕｓｅｄ＿Ｉｎｆｏ」パラメータは、ＤＳＴ−１００でのＤＥ−２およびＤＥ−３についてそれぞれ、「ＤＳＴ−１でのＤＥ−６」および「ＤＳＴ−３でのＤＥ−２７」で設定され得る。
ステップ４で、ＤＳＣＳエージェント１は、既存のＤＳＴでの利用可能でないＤＥが再使用され得るＤＥ（例えば、ＤＳＴ−１００でのＤＥ−１）についてのみ、ＤＳ識別プロセスをさらに行い得る。このステップは、図６のステップ４〜６を含む。その一方で、「Ｒｅｕｓｅｄ」パラメータは、ＤＳＴ−１００でのＤＥ−１について「偽」で設定されるべきである。図８に示されるこの例では、１つのＬＦＡのみが関与するが、一般に、ＤＳ識別プロセスはまた、以下に説明されるソリューションを使用することによって、複数のＬＦＡで関与し得ることに留意されたい。
ステップ５は、図６のステップ７と同じであり得る。
ステップ６は、図６のステップ８〜１０と同じであり得る。特に、ＤＳＴ−１００についてのワークスレッドは、他のものによって作成され、ＤＳＴ−１００でのそれらの再使用されたＤＥについてのＲＤＳデータを生成することを担う、既存のワークスレッドを活用することによって構築され得る。
ステップ７は、図６のステップ１１と同じであり得る。
第４の例では、Ｒ−ＤＳＴを介したＤＳＴ作成が論じられる。前の３つの例では、ＤＳＴ−１の未加工データは、単一のＬＦＡ−１から生じることが想定された。この例では、ＤＳＴ−１の未加工データが複数のＬＦＡから生じ得る、より高度なシナリオが考慮される。この場合、ＤＳＴ−１は、複数のＳ−ＤＳＴに分割され得るＲ−ＤＳＴであり得る。特に、ＤＳＴ−１が（例えば、図６〜図８のステップ３で）作成された後、ＤＳＣＳエージェント１は、どのＬＦＡが関与するかを見出し得、Ｓ−ＤＳＴは、関与するＬＦＡの各々についてさらに作成され得る。各Ｓ−ＤＳＴでは、それは、それらのＤＥの未加工データがこのＳ−ＤＳＴの対応するＬＦＡから収集される場合にのみＤＥを含む。
図９は、Ｒ−ＤＳＴ分割を伴うＤＳＴ作成プロセスのための例示的プロシージャを図示する。
ステップ１で、ＤＳＣＳエージェント１は、ユーザ１からＤＳＴ作成要求を受信し、ＤＳＴ−１が作成された。このステップは、図６〜図８のステップ３に対応する。次に、ＤＳＣＳエージェント１はまた、どのＬＦＡ（例えば、この例では、ＬＦＡ−１およびＬＦＡ−２）がこのＤＳＴ−１に関与するかを決定する。
ステップ２で、ＤＳＴ−１は、２つのＳ−ＤＳＴ（例えば、ＬＦＡ−１についてのＳ−ＤＳＴ−１およびＬＦＡ−２についてのＳ−ＤＳＴ−２）を作成することによって、さらに分割されている。ＤＳＣＳエージェント１は、ＤＳＴ−１、Ｓ−ＤＳＴ−１、およびＳ−ＤＳＴ−２で関連パラメータを構成する。例えば、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２のパラメータは、以下の例示的設定を有し得る。
ＤＳＴ＿Ｉｎｉｔｉａｔｏｒについて、２つのＳ−ＤＳＴが、イニシエータがユーザ１であった、それらの親Ｒ−ＤＳＴ（例えば、ＤＳＴ−１）に基づいて作成されるため、それらの２つのＳ−ＤＳＴのＤＳＴイニシエータもまた、ユーザ１であり得る。
ＤＳＴ＿Ｕｓｅｒｓについて、同じ理由で、それらの２つのＳ−ＤＳＴのＤＳＴユーザもまた、この例では、ユーザ１であり得る。
Ｔｙｐｅ＿ｏｆ＿ＤＳＴについて、Ｓ−ＤＳＴ
Ｔａｒｇｅｔｅｄ＿Ｒｅｇｉｏｎについて、Ｓ−ＤＳＴ−１について、その標的領域は、ＬＦＡ−１であり得、一方、Ｓ−ＤＳＴ−２の標的領域は、ＬＦＡ−２であり得る。
Ｐａｒｅｎｔ＿ＤＳＴ＿ＩＤについて、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２の両方の親ＤＳＴ ＩＤは、ＤＳＴ−１であり得る。
Ｃｒｅａｔｉｎｇ＿ＤＳＣＳ＿Ａｇｅｎｔ＿ＩＤについて、この例では、ＤＳＣＳエージェント１。
Ｄａｔａ＿Ｓａｍｐｌｅ＿Ｆｒｅｑｕｅｎｃｙについて、ＤＳＴ−１での対応する設定と同じである。
ＤＳＴ＿Ｓｔａｔｕｓについて、ＤＳＴ−１での対応する設定と同じである。
ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅについて、ＤＳＴ−１での対応する設定と同じである。
ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｔｒｉｇｇｅｒについて、ＤＳＴ−１での対応する設定と同じである。
ＲＤＳ＿Ｃｏｎｔｅｘｔについて、ＤＳＴ−１での対応する設定と同じである。
ステップ３ａおよび３ｂで、各Ｓ−ＤＳＴについて、ＤＳ識別プロセスは、対応するＬＦＡ（Ｓ−ＤＳＴ−１についてのステップ３ａおよびＳ−ＤＳＴ−２についてのステップ３ｂ）で行われ得る。このステップについて、図６〜図８に関連して開示される方法は、完全に再使用され得る。例えば、ＤＳＣＳエージェント１は、ＤＳ識別要求をＬＦＡ−１内のＤＳＣＳエージェント２に送信し得るか、またはＤＳＣＳエージェント１は、ＤＳＴリポジトリで記憶される既存のＤＳＴでＤＥを再使用し得る。一旦、ＤＳ識別プロセスが行われると、ＤＳＣＳエージェント１は、（例えば、実行可能としてそれらのＤＳＴのステータスをマークするために）ＤＳＴ−１、Ｓ−ＤＳＴ−１、およびＳ−ＤＳＴ−２で関連パラメータをさらに構成し得、それらをフィールドに展開する準備ができている。
以下のステップ（例えば、ＬＦＡ−１についてのステップ４〜６、およびＬＦＡ−２についてのステップ７〜９）は、いくつかのさらなる構成の追加を伴って、前の図でのＤＳＴフィールド展開関連ステップ（例えば、図６のステップ８〜１０）と同様である。代替として、ＬＦＡ−１についてのステップ４〜６は、ＬＦＡ−２についてのステップ７〜９と同時またはその後に行われ得る。
ステップ４で、ＤＳＣＳエージェント１は、フィールド展開のために、Ｓ−ＤＳＴ−１をＬＦＡ−１内のＤＳＣＳエージェント２に送信する。
ステップ５で、ＤＳＣＳエージェント２は、Ｓ−ＤＳＴ−１についてのワークスレッドを設定するための構成を行う。データがどこで処理されるかに関するいくつかのさらなる構成はまた、ステップ１０で説明されるような詳細に基づいて行われる。
ステップ６で、ＤＳＣＳエージェント２は、Ｓ−ＤＳＴ−１のフィールド展開が設定されることを通知する。
ステップ７で、ＤＳＣＳエージェント１は、展開のために、Ｓ−ＤＳＴ−２をＬＦＡ−２内のＤＳＣＳエージェント３に送信する。
ステップ８で、ＤＳＣＳエージェント３は、Ｓ−ＤＳＴ−２についてのワークスレッドを設定するための構成を行う。データがどこで処理されるかに関するいくつかのさらなる構成は、ステップ１０で説明されるような詳細に基づいて実行され得る。
ステップ９で、ＤＳＣＳエージェント３は、Ｓ−ＤＳＴ−２のフィールド展開が完了したことを通知する。
ステップ１０で、ＤＳＣＳエージェント１は、展開のために、ＤＳＴ−１をＦＮ上のＤＳＣＳエージェント４に送信する。ＤＳＴ−１が複数のＳ−ＤＳＴに分割されたとき、それは、ＲＤＳ生成の間に、データ処理がどのように行われるべきかを決定される必要があり得る。
一例では、ＤＳＴ−１は、Ｒ−ＤＳＴであり得、そのインフィールドマネージャは、ＦＮ上のＤＳＣＳエージェント４であり得る。特に、ＤＳＴ−１が、２つのＳ−ＤＳＴにすでに分割され、ＤＳ識別が、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２について行われ得るため、ＤＳＴ−１について開始されるＤＳ識別プロセスは存在しない場合がある。ＤＳＣＳエージェント４は、単に、あるデータ処理動作で関与し得、ＤＳＴ−１の最後のＲＤＳは、ＤＳＣＳエージェント４で生成され得る。
別の例では、インフィールドマネージャは、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２についてそれぞれ、ＤＳＣＳエージェント２およびＤＳＣＳエージェント３であり得る。それらのインフィールドマネージャは、対応するＬＦＡ（例えば、ＬＦＡ−１およびＬＦＡ−２）でそれぞれ、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２についてのＤＳ識別プロセスを担い得る。しかしながら、Ｓ−ＤＳＴでの特定のＤＥについて、ＤＥ−１についてのＲＤＳ生成プロセスを行うことは、以下の３つのケース（例えば、ケース１、ケース２、およびケース３）のうちの１つ以上を含み得る。
ケース１では、ＤＥのＤａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎパラメータは、Ｓ−ＤＳＴで設定されており、このＳ−ＤＳＴ−１のインフィールドマネージャはまた、このＤＥの未加工データが「完全に処理」される場所であり得る。これは、インフィールドマネージャが、単にこのＤＥを含む不完全なＲＤＳを生成し得ることを意味する。その後、このＳ−ＤＳＴのインフィールドマネージャは、それらの不完全なＲＤＳを、その親Ｒ−ＤＳＴのインフィールドマネージャに送信し得、ここで、Ｒ−ＤＳＴの最後のＲＤＳが、異なるＬＦＡから収集されるそれらの不完全なＲＤＳのアセンブリングによって生成され得る。
図１０は、ケース１についての例示的実装を示す。この例では、ＤＳＴ−１は、２つのＤＥ（例えば、ＤＥ−１およびＤＥ−２）を有する。例えば、ＤＳＴ−１のＲＤＳは、（ＤＥ−１、ＤＥ−２、ＲＤＳ＿Ｃｏｎｔｅｘｔ）の形態を有する。特に、ＤＥ−１およびＤＥ−２はそれぞれ、最後の３分でのＬＦＡ−１およびＬＦＡ−２の最大温度である。故に、ＤＳＴ−１は、２つのＳ−ＤＳＴ（例えば、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２）に分割されている。それらの２つのＳ−ＤＳＴは、ＬＦＡ−１内のＤＳＣＳエージェント２およびＬＦＡ−２内のＤＳＣＳエージェント３上で展開されている。Ｒ−ＤＳＴ（例えば、ＤＳＴ−１自体）は、よりハイレベルのＦＮ上のＤＳＣＳエージェント４上で展開される。ＤＥ−１およびＤＥ−２は、単に、それぞれのＬＦＡで最大温度を計算するために使用され得るため、ＬＦＡ−１およびＬＦＡ−２から収集される未加工データはそれぞれ、ＤＳＣＳエージェント２およびＤＳＣＳエージェント３によって完全に処理され得る。言い換えると、それぞれのＬＦＡでの最大温度は、ＤＳＣＳエージェント２またはＤＳＣＳエージェント３で直接計算され得る。次いで、ＤＳＣＳエージェント２は、不完全なＲＤＳ（例えば、ＤＥ−１パートについての完全に処理されたデータ）を（ＤＳＣＳエージェント３と同じ）ＤＳＣＳエージェント４に送信し得る。最後に、ＤＳＣＳエージェント４は、ＲＤＳ＿Ｃｏｎｔｅｘｔでの情報に基づいて、ＤＳＣＳエージェント２からの１つのピースのデータおよびＤＳＣＳエージェント３からの１つのピースのデータのアセンブリングによって、ＤＳＴ−１の各単一のＲＤＳを生成し得る。
ケース２では、ＤＥのＤａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎパラメータは、Ｓ−ＤＳＴで設定されており、そのインフィールドマネージャは、未加工データ上で、あるデータ処理を行い得る。しかしながら、未加工データは、単に、「部分的に処理」され得る。その後、このＳ−ＤＳＴのインフィールドマネージャは、部分的に処理されたデータを、その親Ｒ−ＤＳＴのインフィールドマネージャに送信し得、そこから、最後のＲＤＳが、異なるＬＦＡから収集される、部分的に処理されたデータをさらに処理することによって生成され得る。
図１１は、ケース２についての例示的実装を示す。この例では、ＤＳＴ−１は単に、１つのＤＥ（例えば、ＤＥ−１）を有し、ＤＳＴ−１のＲＤＳは、（ＤＥ−１）の形態を有する。特に、ＤＥ−１は、最後の３分での（ＬＦＡ−１およびＬＦＡ−２によってカバーされる）全体のダウンタウンエリアの最大温度である。この場合、ＤＳＴ−１はまた、２つのＳ−ＤＳＴ（例えば、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２）に分割されている。それらの２つのＳ−ＤＳＴは、ＬＦＡ−１内のＤＳＣＳエージェント２およびＬＦＡ−２内のＤＳＣＳエージェント３上で展開されている。Ｒ−ＤＳＴ（例えば、ＤＳＴ−１自体）は、よりハイレベルのＦＮ上のＤＳＣＳエージェント４上で展開される。ＤＥ−１は、ＬＦＡ−１およびＬＦＡ−２の両方をカバーする全体のエリアについて最大温度を計算するため、ＬＦＡ−１およびＬＦＡ−２から収集される未加工データはそれぞれ、単に、ＤＳＣＳエージェント２およびＤＳＣＳエージェント３によって部分的に処理され得る。例えば、ＤＳＣＳエージェント２は、単にＬＦＡ−１の最大温度を計算し得る、ＬＦＡ−１から収集される未加工データを処理し得、当該最大温度は、これが（ＤＳＣＳエージェント３と同じ）全体のエリアについての最大温度でないため、部分的に処理されたデータである。ＤＳＣＳエージェント４で、さらなるデータ処理が、収集された、部分的に処理されたデータに基づいて必要とされ得る。例えば、同じ時間間隔でＬＦＡ−１およびＬＦＡ−２から収集される２つの最大温度データを考慮すると、それらの２つの値の間の最大のものは、ＤＥ−１についての完全に処理されたデータであり得る、全体のエリアについての最終の最大温度であり得る。
ケース３では、ＤＥのＤａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎパラメータは、Ｓ−ＤＳＴで設定されておらず、そのインフィールドマネージャは単に、このＤＥのすべての未加工データを、例えば、よりハイレベルのフォグノード上でのＤＳＣＳエージェントであり得る、その親Ｒ−ＤＳＴのインフィールドマネージャに転送し得る。言い換えると、すべての未加工データは、Ｒ−ＤＳＴのインフィールドマネージャで処理され得る。
図１１に示されるようなケース２と同じ例を依然として使用する。このとき、ＤＳＣＳエージェント２およびエージェント３は、十分なデータ処理能力を有しない場合がある。故に、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２でのＤＥのＤａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎパラメータは設定されない場合がある。そのような構成を介して、ＤＳＣＳエージェント２およびエージェント３は、任意のデータ処理に関与しない場合がある。その代わり、それらは、すべての未加工データをＤＳＣＳエージェント４に直接転送し得る。ＤＳＣＳエージェント４は、すべてのデータ処理を行うものであり得、ＤＳＴ−１についてのＲＤＳを生成し得る。
一般に、ＤＳＣＳエージェント４は、フォグ階層でＬＦＮよりも高い任意のノード上でホストされ得る。一例では、ＤＳＣＳエージェント４は、ルートＣＮノードで同等であり得る（この場合、ＤＳＣＳエージェント４は、ＤＳＣＳエージェント１と同じである）。全体として、ＤＳＣＳエージェント４を可能な限り多くエッジに展開する利点は、潜在的処理および通信オーバーヘッドを省くためにローカル／分散されたデータ処理を可能にすることである。
図９に戻る。
ステップ１１で、ＦＮ上のＤＳＣＳエージェント４は、ＤＳＴ−１についてのワークスレッドを設定するための構成を行う。
ステップ１２で、ＤＳＣＳエージェント４は、ＤＳＴ−１のフィールド展開が完了したことを通知する。このステップの後、ＤＳＣＳエージェント１は、ＤＳＴ−１が成功して作成され実行可能であることをＤＳＴ−１のユーザに通知し得る。
図９〜図１１は、ＤＳＣＳユーザがクラウド側からであり、一方、ＩｏＴ未加工データ収集および処理がＬＦＡで行われる、例示的シナリオを使用したことに留意されたい。ユーザがＬＦＡと直接相互作用し得る、追加のまたは代替のシナリオが使用され得ることが理解される。例えば、移動車両内で座っているユーザは、いくつかのリアルタイムのシティの気象および汚染分析／監視チャートを見たいと思う場合がある。この場合、それは、所望のＲＤＳを収集するために、ロードサイドユニット上でホストされるＤＳＣＳエージェントに要求を直接送信し得る。ユーザは、それらのＲＤＳデータサンプル収集要求をＬＦＡ内のＤＳＣＳエージェントに直接送信し得る。
どのＤＳＴ作成アプローチが採用されても、ＤＳ識別は、ＤＳＴについて所望のＤＳを識別し得る重要なプロセスであることが理解される。ＤＳＴは、所望のＤＳがこのＤＳＴでのすべてのＤＥについて識別され得る場合にのみ、実行可能なステータスにあり得る。特に、所与の実行可能なＤＳＴについて、ＤＳＣＳエージェントは、フィールドでのＤＳの利用可能性に対する動的な変化が存在し得るという事実を考慮して、すべての識別されたＤＳが依然として、利用可能であり、および／または所望の品質要件を満たすかどうかを追跡することを維持する必要があり得る。そうでない場合、実行可能なＤＳＴが実行不可能なＤＳＴになり得、新しいＤＳ識別が行われる必要があり得る。
ＤＳＴ更新および削除プロセスのためのいくつかのソリューションが開示される。ＤＳＴ（およびその関連Ｓ−ＤＳＴ）が更新／削除される場合、このＤＳＴは最初に、「実行可能な」ステータスにあり、「有効な」ステータスにないようにする必要があり得ることに留意されたい。言い換えると、有効なＤＳＴは最初に、このＤＳＴ上で任意のＤＳＴ更新／削除プロセスを行う前に無効にされる必要があり得る。
図１２は、１つ以上の新しいＤＥを既存のＤＳＴ（例えば、ＤＳＴ−１）に追加するために、ＤＳＴ更新プロセスのための例示的プロシージャを図示する。この例はまた、既存のＤＳＴでのいくつかの情報を更新するために使用され得ることに留意されたい。
前提条件として、ＤＳＴ−１は、ユーザ１によって作成されており、ＤＳＴ−１のＲＤＳは、２つのＤＥ（例えば、ＤＥ−１およびＤＥ−２）を有する。ＤＳＴ−１は、２つのＳ−ＤＳＴ（例えば、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２）に分割されており、それは、（図１２に図示しない）ＬＦＡ−１内のＤＳＣＳエージェント２およびＬＦＡ−２内のＤＳＣＳエージェント３上で展開された。特に、Ｓ−ＤＳＴ−１は、ＤＥ−１パートに関連するＲＤＳを生成することを担い、一方、Ｓ−ＤＳＴ−２は、ＤＥ−２パートに関連するＲＤＳを生成することを担う。
ステップ１で、新しい必要性に起因して、ユーザ１は、１つ以上の新しいＤＥを既存のＤＳＴ−１に追加することを意図する。例えば、既存のＤＥ−１およびＤＥ−２に加え、ユーザ１はまた、ＤＥ−３およびＤＥ−４をＤＳＴ−１に追加したいと思う。言い換えると、更新されたＤＳＴ−１のＲＤＳは、（ＤＥ−１、ＤＥ−２、ＤＥ−３、ＤＥ−４、ＲＤＳ＿Ｃｏｎｔｅｘｔ）の形態を有し得る。
ステップ２で、ユーザ１は、必要な情報とともに、ＤＳＴ更新要求をＤＳＣＳエージェント１に送信する。特に、メッセージは、（例えば、表１に示されるような）以下の関連パラメータを含み得る。
ＤＳＴ＿ＩＤについて、このパラメータは、どの既存のＤＳＴが更新されるかを示す。
Ｔａｒｇｅｔｅｄ＿Ｒｅｇｉｏｎについて、追加される新しいＤＥが標的領域の変化につながる場合、このパラメータはまた、更新される必要があり得る。例えば、ＤＳＴ−１でのこのパラメータにすでに含まれたＬＦＡ−１およびＬＦＡ−２に加え、追加される新しいＤＥのパートがＬＦＡ−３から収集され得るため、新しいＬＦＡ−３が関与し得る。
追加されるＤＥの各々は、このＤＥについての詳細を定義する以下のパラメータを有し得る。
Ｒａｗ＿Ｄａｔａ＿Ｔｙｐｅ、
Ｕｎｉｔ、
Ｄａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎ、
Ｃｕｓｔｏｍｉｚｅｄ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｄｅｔａｉｌｓ、および
Ｑｕａｌｉｔｙ＿Ｒｅｑｕｉｒｅｍｅｎｔｓ。
新しいＤＥを追加する代わりに、ユーザ１は、単に、（例えば、新しいＤＥを追加するのではなく、）既存のＤＳＴでのいくつかの情報を更新したいと思い得る。この場合、メッセージは、以下の関連パラメータを含み得る。
ＤＳＴ＿ＩＤについて、このパラメータは、どの既存のＤＳＴが更新されるかを示す。
Ｎｅｗ＿Ｐａｒａｍｅｔｅｒ＿Ｖａｌｕｅｓについて、これは、更新されるパラメータおよびそれらの新しい値を含む。
ステップ３で、ＤＳＣＳエージェント１は最初に、ＤＳＴ−１（およびその関連Ｓ−ＤＳＴ）が「有効な」ステータスにあるかどうかをチェックする。そうである場合、ＤＳＣＳエージェント１は最初に、ＤＳＴ−１（およびその関連Ｓ−ＤＳＴ）を無効にする必要があり得る。次いで、異なるアプリケーションシナリオに基づいて、ＤＳＣＳエージェント１は、それらの新しいＤＥを追加するために適切な動作をさらに行い得る。一般に、以下に詳述されるような２つの例示的ケースが存在し得る。
ケース１では、ＤＳＴ−１は、以下のシナリオについて更新され得る。
ＤＳＴ−１は、ＬＦＡ内のＤＳＣＳエージェントが単に、ＤＳＴ作成要求が存在するときにＤＳ識別を行い始める、上述のようなシナリオ１の下作成された。この場合、ＤＳ識別のための図６に示されるプロシージャのステップ３〜６は、追加される新しいＤＥについて行われ得る。
ＤＳＴ−１は、ＤＳＴ作成要求が存在しない場合でさえ、ＬＦＡ内のＤＳＣＳエージェントが事前にＤＳ識別を行い得る、上述のようなシナリオ２の下作成された。この場合、ＤＳ識別のための図７に示されるプロシージャのステップ３は、追加される新しいＤＥについて行われ得る。
ＤＳＴ−１は、ＤＳＴリポジトリが存在し、既存のＤＳＴでの１つ以上のＤＥが潜在的に再使用され得る、上述のようなシナリオ３の下作成された。この場合、ＤＳ識別のための図８に示されるプロシージャのステップ３〜５は、追加される新しいＤＥについて行われ得る。
ＤＳＴ−１は、ＤＳＴが複数のＳ−ＤＳＴに分割され得る、上述のようなシナリオ４の下作成された。この場合、ＤＳ識別のための図９に示されるプロシージャのステップ３は、追加される新しいＤＳについて行われ得る。図１２に示されるステップ３の後の残りのステップが主に、このシナリオに基づくことに留意されたい。例として、ＤＥ−３についての未加工データがＬＦＡ−２から収集され得ることが想定される。故に、既存のＳ−ＤＳＴ−２は、新しく追加されたＤＥ−３を組み込むことによって更新され得、更新されたＳ−ＤＳＴ−２はまた、Ｓ−ＤＳＴ−２のインフィールドマネージャに展開される必要があり得る。その一方で、ＤＥ−４についての未加工データが新しいＬＦＡ−３から収集され得るため、新しいＳ−ＤＳＴ−３が作成され得る。故に、Ｓ−ＤＳＴ−３は、フィールド展開のために、ＬＦＡ−３でＤＳＣＳエージェント５に送信され得る。加えて、現在、ＤＳＴ−１は、３つのＳ−ＤＳＴに分割されているため、ＤＳＴ−１自体もまた更新される必要があり得、更新されたＤＳＴ−１もまた、フィールド展開のために、ＤＳＣＳエージェント４に送信される必要があり得る。
ケース２では、ＤＳＴ−１は、更新されない場合がある。ＤＳＴ−１が、ユーザ１からのＤＳＴ更新要求に起因して更新されない場合があることは、着目に値する。ＤＳＴ−１は、現在、複数のユーザによって（例えば、ユーザ１によってだけでなく）使用されている場合があることが可能であり得る。故に、ＤＳＴ−１が、他のものが認識することなく修正される場合、更新されたＤＳＴ−１によって生成されるＲＤＳは、ユーザ１以外のユーザによって理解されない場合がある。この場合、ケース１に示されるような任意の動作を行う前に、以下の動作が最初に実行される必要があり得る。
ＤＳＣＳエージェント１は、ＤＳＴ−１のＤＳＴ＿Ｕｓｅｒｓパラメータで示されるようなＤＳＴ−１のすべてのユーザでチェックする必要があり得る。ＤＳＴ−１は、すべてのユーザがＤＳＴ−１を更新することに同意する場合にのみ更新され得る。
ＤＳＴ−１のユーザのすべてがＤＳＴ−１を更新することに同意しているわけではない場合、この更新要求は拒絶され得る。代替として、別の高度なソリューションは、新しいＤＳＴ−２を作成することであり、それは、ＤＳＴ−２のＤＳＴ＿Ｕｓｅｒｓパラメータが単にユーザ１を含み得る（ユーザ１はまた、ＤＳＴ−１のユーザリストから削除され得る）ことを除いて、ＤＳＴ−１の正確なクローンであり得る。次いで、新しいＤＥは、ＤＳＴ−２に追加され得る。この新しく作成されたＤＳＴ−２で、ＤＳＣＳエージェント１は、ＤＳＴ−２を複数のＳ−ＤＳＴにさらに分割し得る。故に、ＤＳＴ−２のそれらのＳ−ＤＳＴを展開するとき、それらの対応するワークスレッドは、関連ＬＦＡのインフィールドマネージャによって設定され得る。ＤＳＴ−２での所与のＳ−ＤＳＴ−Ｘについて、特定の実装に応じて、ＤＳＴ−１でのＳ−ＤＳＴ−Ｘのワークスレッドは、完全に再使用され得、（それらの２つのＳ−ＤＳＴは正確に同じであるため）必要とされる新しいワークスレッドがない場合がある。しかしながら、ＤＳＴ−２でのＳ−ＤＳＴ−Ｘが、ＤＳＴ−１でのＳ−ＤＳＴ−Ｘと比較して、新しいＤＥを有する場合、新しいワークスレッドは、ＤＳＴ−１でのＳ−ＤＳＴ−Ｘの既存のワークスレッドに基づいて構築され得る。
新しいＤＥを追加する代わりに、ユーザ１は、単に、（例えば、１つ以上のＤＥを追加するのではなく、）既存のＤＳＴでのいくつかの情報を更新したいと思い得る。この場合、上記のソリューションもまた再使用され得る。例えば、ユーザ１が、ＤＳＴ−１のＤａｔａ＿Ｓａｍｐｌｅ＿ＦｒｅｑｕｅｎｃｙパラメータまたはＤＳＴ−１でのＤＥ−１のＱｕａｌｉｔｙ＿Ｒｅｑｕｉｒｅｍｅｎｔｓを更新することを意図する場合、それはまた、それらのパラメータの新しい値に準拠するために、行われる新しいＤＳ識別プロセスをトリガし得る。一旦、それらのパラメータが更新された状態になると、更新されたＤＳＴ−１は、再び展開され得、その結果、ＤＳＴ−１の対応するワークスレッドは、最新の／更新されたＤＳＴ−１に従って機能し始め得る。しかしながら、それらのパラメータに対する更新を、ＤＳＴ−１が現在、他のユーザによって共有されているという事実に起因して行うことができない場合、更新要求が拒絶され得るか、または新しいＤＳＴが作成され得、それは、上述のようなそれらのパラメータの新しい値を含む。
ケース１に関連して１つ以上の新しいＤＥを追加するとき、ステップ４〜６は、ＤＳＴ−１が、ステップ３の間に１つ以上のＤＥを追加することによって更新された状態になったことを想定するステップを図示する。
ステップ４で、ＤＳＣＳエージェント１は、更新されたＳ−ＤＳＴ−２を、１つ以上の新しく追加されたＤＥが含まれたＬＦＡ−２内のＤＳＣＳエージェント３に展開する。図９でのステップ７〜９は、再使用され得る。
ステップ５で、ＤＳＣＳエージェント１は、新しいＳ−ＤＳＴ−３をＬＦＡ−３内のＤＳＣＳエージェント５に展開する。
ステップ６で、ＤＳＣＳエージェント１は、更新されたＤＳＴ−１を、新しく追加されたＤＥのすべてが含まれたＦＮ上のＤＳＣＳエージェント４に展開する。同様に、図９でのステップ１０〜１２は、再使用され得る。
ケース２について、ＤＳＴ−１を更新することができず、新しいＤＳＴ−２がステップ３の間に作成される場合、行われる必要があり得るのは、新しく作成されたＤＳＴ−２およびその関連Ｓ−ＤＳＴを適切なＬＦＡまたはＦＮに展開することである。この場合、ＤＳＴ更新プロセスは、ＤＳＴ作成プロセスに変えられる。
ステップ７で、ＤＳＣＳエージェント１は、ＤＳＴ−１が更新されたことを通知する。または、新しいＤＳＴ−２がステップ３の間に作成される場合、ＤＳＣＳエージェント１は、新しいＤＳＴがその新しい必要性を供給するために作成されることをユーザ１に知らせ得る。前にＤＳＴ−１がステップ３の前に「有効な」ステータスにあった場合、ＤＳＴ−１は、再び有効にされ得る。
既存のＤＳＴで１つ以上のＤＥを削除するか、または全体のＤＳＴを削除するためのＤＳＴ更新プロセスが開示される。開示されるソリューションは、ＤＳＴ作成プロセスの間に、論じられるような異なるシナリオに適用され得ることに留意されたい。
図１３は、既存のＤＳＴで１つ以上のＤＥを削除するために、ＤＳＴ削除プロセスのための例示的プロシージャを図示し（このプロシージャはまた、全体のＤＳＴを削除するために使用され得る）、詳細な説明は、以下のように論じられる。
前提条件として、ＤＳＴ−１は、ユーザ１によって作成されており、ＤＳＴ−１のＲＤＳは、４つのＤＥ（例えば、ＤＥ−１、ＤＥ−２、ＤＥ−３、およびＤＥ−４）を有することが想定される。ＤＳＴ−１は、２つのＳ−ＤＳＴ（Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２）に分割されており、それは、ＬＦＡ−１内のＤＳＣＳエージェント２およびＬＦＡ−２内のＤＳＣＳエージェント３上で展開された。特に、Ｓ−ＤＳＴ−１は、ＤＥ−１についてのＲＤＳを生成することを担い、一方、Ｓ−ＤＳＴ−２は、ＤＥ−２、ＤＥ−３、およびＤＥ−４についてのＲＤＳを生成することを担う（完全なＲＤＳは、ＦＮ上のＤＳＣＳエージェント１によってアセンブルされ得る）。ＤＳＴ−１およびＳ−ＤＳＴ−２は、図１３に示される例での主要な焦点である。
ステップ１で、新しい必要性に起因して、ユーザ１は、既存のＤＳＴ−１から１つ以上のＤＥを削除することを意図する。例えば、ユーザ１は、ＤＳＴ−１からＤＥ−３およびＤＥ−４を削除したいと思う。
ステップ２で、ユーザ１は、必要な情報とともに、ＤＳＴ削除要求をＤＳＣＳエージェント１に送信する。特に、メッセージは、（例えば、表１に示されるような）以下の関連パラメータを含み得る。
ＤＳＴ＿ＩＤについて、このパラメータは、どの既存のＤＳＴが更新されるかを示す。
Ｄｅｌｅｔｉｏｎ＿Ｌｉｓｔについて、これは、削除されるＤＥのリストである。全体のＤＳＴが削除される場合、このパラメータは、「すべて」に設定され得る。
ステップ３で、ＤＳＣＳエージェント１は最初に、ＤＳＴ−１（およびその関連Ｓ−ＤＳＴ）が「有効な」ステータスにあるかどうかをチェックする。そうである場合、ＤＳＣＳエージェント１は最初に、ＤＳＴ−１（およびその関連Ｓ−ＤＳＴ）を無効にする必要があり得る。異なるアプリケーションシナリオに基づいて、ＤＳＣＳエージェント１は、それらのＤＥを削除するために適切な動作をさらに行い得る。一般に、削除リスト内の所与のＤＥについて、それは、以下の３つのケースを有し得る。
ケース１について、ＤＳＴ−１でのＤＥ（例えば、ＤＥ−３）は削除され得、対応する動作は対応するＬＦＡで行われる必要がある。これは、以下の可能性のあるシナリオで発生する。
１．ユーザ１は、ＤＳＴ−１の唯一のユーザであり、その一方で、ＤＥ−３は、任意の他のＤＳＴで再使用されることはない。または、
２．ユーザ１は、ＤＳＴ−１の唯一のユーザであり、このＤＥ−３は、別のＤＳＴで最初に作成された、再使用されたＤＥである。この場合、ＤＥ−３を削除することによって、ＤＳＴ−１およびＳ−ＤＳＴ−２を更新し、更新されたＳ−ＤＳＴ−２をＬＦＡ−２内のＤＳＣＳエージェント３に展開することが必要であり得る。
ケース２について、ＤＳＴ−１でのＤＥ（例えば、ＤＥ−４）を削除することはできず、新しいＤＳＴが作成される。これは、ＤＳＴ−１が、現在、複数のユーザによって（例えば、ユーザ１によってだけでなく）使用され得るシナリオで発生する。故に、ＤＳＴ−１が、他のものが認識することなく修正される場合、更新されたＤＳＴ−１によって生成されるＲＤＳは、ユーザ１以外のユーザによって理解されない場合がある。この場合、上記に示されるような任意の動作を行う前に、以下の動作が最初に実行される必要がある。
ＤＳＣＳエージェント１は、ＤＳＴ−１のＤＳＴ＿Ｕｓｅｒｓパラメータで示されるようなＤＳＴ−１のすべてのユーザでチェックする必要がある。ＤＳＴ−１は、すべてのユーザがＤＳＴ−１を更新することに同意する場合にのみ、それらのＤＥを削除するために更新され得る。
ＤＳＴ−１のユーザのすべてがＤＳＴ−１からＤＥを削除することに同意しているわけではない場合、削除要求は拒絶され得る。代わって、別のソリューションは、新しいＤＳＴ−２を作成することであり、それは、ＤＳＴ−２のＤＳＴ＿Ｕｓｅｒｓパラメータが単にユーザ１を含み得る（ユーザ１はまた、ＤＳＴ−１のユーザリストから削除され得る）ことを除いて、ＤＳＴ−１の正確なクローンであり得る。次いで、関連ＤＥは、ＤＳＴ−２から削除され得る。この新しく作成されたＤＳＴ−２で、ＤＳＣＳエージェント１は、さらに、ＤＳＴ−２を複数のＳ−ＤＳＴに分割し、フィールド展開のためにそれらを送信し得る。
ケース３について、ＤＳＴ−１でのＤＥを削除することはできない。これは、ユーザ１がＤＳＴ−１の唯一のユーザであるが、このＤＥが他のＤＳＴで再使用されているシナリオで発生する。この場合、特にこのＤＥについて行われる必要がある動作はない。
全体として、ＤＳＣＳエージェント１は、削除されるＤＥの各々をチェックし得る。それらのいずれか１つが上述のようなケース２となる場合、新しいＤＳＴが作成され得る。そうでない場合、削除されるすべてのＤＥがケース１またはケース３となる場合、オリジナルＳ−ＤＳＴ−２は、削除されるそれらのＤＥの各々について適切な動作を行うことによって、それに応じて修正され得る。
ユーザ１が全体のＤＳＴ−１を削除（例えば、すべてのＤＥを削除）したいと思うケースについて、全体のＤＳＴ（および対応するワークスレッド）は、すべてのＤＥがケース１となる場合に実際に削除され得る。そうでない場合、それは、上記のケース２およびケース３で言及されるようなソリューションに従い得る。
ステップ４〜５は、ＤＳＴ−１（およびＳ−ＤＳＴ−２）がステップ３の間に更新されたことを想定するステップを図示する。
ステップ４で、ＤＳＣＳエージェント１は、フィールド展開のために、更新されたＳ−ＤＳＴ−２をＬＦＡ−２内のＤＳＣＳエージェント３に送信し、Ｓ−ＤＳＴ−２の既存のワークスレッドはまた修正され得、その結果、Ｓ−ＤＳＴ−２について作成されるＲＤＳデータは、削除されたＤＥを含まない場合がある。
ステップ５で、ＤＳＣＳエージェント１は、フィールド展開のために、更新されたＤＳＴ−１をＦＮ上のＤＳＣＳエージェント４に送信する。
新しいＤＳＴ−２がステップ３の間に作成された場合、ＤＳＴ−２およびその関連Ｓ−ＤＳＴを適切なＬＦＡに展開することが必要であり得、ＤＳＴ作成プロセスのためにすべての前のプロシージャは再使用され得る。言い換えると、この場合、ＤＳＴ削除プロセスは、ＤＳＴ作成プロセスに内部で変えられる。
ステップ６で、ＤＳＣＳエージェント１は、ＤＳＴ−１でのＤＥのうちの１つ以上が削除されたことを通知する。または、新しいＤＳＴ−２がステップ３の間に作成される場合、ＤＳＣＳエージェント１は、新しいＤＳＴがその必要性に基づいて作成されることをユーザ１に知らせ得る。
所与のＤＳＴ−１について、ユーザ１が、同時に１つ以上の既存のＤＥを削除しながら、１つ以上の新しいＤＥを追加したいと思い得ることは、着目に値する。そのようなケースについて、図１２および図１３で開示されるようなプロシージャは、一緒に統合され得る。例えば、図１２および図１３でのステップ２について、ユーザ１は、それが、１つ以上のＤＥをＤＳＴ−１に追加するだけでなく、ＤＳＴ−１から１つ以上のＤＥを削除する必要があることを直接示し得る。そのようなＤＳＴ更新要求を受信した後、ＤＳＣＳエージェント１は、ＤＥの追加およびＤＥの削除の両方のために、図１２および図１３で行われる動作を組み合わせ得る。このようにして、ユーザ１は、単に、１つのＤＳＴ更新要求を送り出し得、ＤＳＣＳエージェント１は、図１２および図１３で導入されるようなすべての必要とされる動作を完了し得る。
作成されたＤＳＴについて、それが、そのインフィールドマネージャに展開された後、それは依然として、有効なＤＳＴではない場合がある。特に、ＤＳＴのＲＤＳ生成プロセスは、このＤＳＴが有効にされるまで開始されない。図１４は、ＤＳＴステータスの状態マシンモデルを示す。例えば、ＤＳＴが作成されたとき、それは、「実行不可能な」ステータスにあり得る。ＤＳ識別がこのＤＳＴについて成功して行われ得る場合、それは、「実行可能な」ステータスに変更され得る。同様に、実行可能なＤＳＴについて、その所望のＤＳのいずれかが失われた状態になるか、またはもはや利用可能でない場合、このＤＳＴは、「実行不可能な」ステータスに戻り得、さらなるＤＳ識別が行われる必要があり得る。その一方で、ＤＳＴ有効化動作を介して、実行可能なＤＳＴは、実際のＲＤＳ生成が開始することを意味する「有効な」ステータスにあり得る。
一般に、以下のようにリストされる（網羅的なリストではない）、ＤＳＴを有効にするためのいくつかの方法が存在する。
（１）所与のＤＳＴが、「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータで示されるようなパラメータに基づいて有効にされ得る。図６に示される例として、一旦、ＤＳＴ−１がＬＦＡ−１内のＤＳＣＳエージェント２に展開されると、このエージェントは、ＤＳＴ−１についてＲＤＳ生成スケジュールを知っている状態になり得、故に、ＤＳＣＳエージェント２は、このスケジュールに基づいて、ＤＳＴ−１の対応するワークスレッドを有効にし得る。その一方で、ＤＳＴが有効または無効にされる度に、Ｃｒｅａｔｉｎｇ＿ＤＳＣＳ＿Ａｇｅｎｔ（例えば、図６に示されるようなＣＮでのＤＳＣＳエージェント１）上でホストされるＤＳＴ−１のＤＳＴ＿Ｓｔａｔｕｓパラメータはまた、その最新のステータスを反映するために更新される必要があり得る。
その一方で、所与のＤＳＴが分割された場合、上記のプロセスはまた、それに従って行われ得る。図１０に示される別の例として、ＤＳＴ−１は、２つのＳ−ＤＳＴ（例えば、Ｓ−ＤＳＴ−１およびＳ−ＤＳＴ−２）に分割されている。故に、すべての対応するワークスレッド（ＦＮ上のＤＳＴ−１、ＬＦＡ−１内のＬＦＮＬ上のＳ−ＤＳＴ−１、およびＬＦＡ−２内のＬＦＮＬ上のＳ−ＤＳＴ−２についてのそれ）はまた、親Ｒ−ＤＳＴ（例えば、ＤＳＴ−１）での「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータに基づいて有効または無効にされ得る。
この場合、ユーザがＤＳＴを作成しているとき、それは、ＤＳＴ作成要求を送信するときにそのＲＤＳ送信アドレスを直接提供し得る（次いで、それは、「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに含まれ得る）。後に、別のユーザもまたこの全体のＤＳＴを再使用したいと思う場合、この新しいユーザは、単に、そのＩＤをこのＤＳＴの「ＤＳＴ＿Ｕｓｅｒｓ」に追加することによって、要求をＤＳＣＳエージェントに送信し、また、それ自体のＲＤＳ送信アドレスを「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに追加し得る。
（２）所与のＤＳＴが、ユーザ自体からの信号に基づいて有効にされ得る。図６に示される例として、「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータが任意の値で設定されなくてもよいことが可能である。故に、ユーザ１は、トリガ要求をＤＳＣＳエージェント１に送信し得、それは、ＤＳＴ−１のワークスレッドを有効にするために、トリガ要求をＬＦＡ−１内のＤＳＣＳエージェント２にさらに転送し得る。代替として、ＤＳＣＳエージェント１自体は、ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｔｒｉｇｇｅｒパラメータで規定されるような、あるイベントに基づいて、トリガ要求をＤＳＣＳエージェント２に送信し得る。例えば、１つのトリガは、ＤＳＴ−１の任意のユーザがシステム内にログインしている限り、ＤＳＴ−１が有効にされ得ることであり得る。無効化は、逆の方法で行われ得る。
ＤＳＴが、ＤＳＴ＿Ｕｓｅｒｓパラメータで示されるような複数のユーザによって共有されるケースでは、それは、ＤＳＴを有効または無効にするための以下の機構を有し得る。
（表１に含まれるような「ＤＳＴ＿Ｓｔａｔｕｓ」パラメータによって示されるように）現在有効にされていない所与のＤＳＴ−１について、ユーザ１は、上述のようなトリガを送信することによって、このＤＳＴ−１を直接有効にし得る。特に、このユーザは、そのＲＤＳ送信アドレスを、表１に示されるような「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに追加し得る。
後で、ＤＳＴ−１の別のユーザ２もまた、ＤＳＴ−１についてのＲＤＳを受信したいと思う場合、ＤＳＴ−１がすでに「有効な」ステータスにあるため、ユーザ２は、単に、そのＩＤをこのＤＳＴの「ＤＳＴ＿Ｕｓｅｒｓ」に追加し、そのＲＤＳ送信アドレスを、表１に示されるような「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに追加し得る。
後で、ユーザ１が、今のところＤＳＴ−１についてのＲＤＳを受信したいと思わない場合、それは、どれくらい多くのユーザが、現在、「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータを調べることによって、ＤＳＴ−１のＲＤＳを受信しているかをチェックし得る。ユーザ１が、現在ＲＤＳを受信している唯一のユーザではない場合、ユーザ１は、単に、表１に示されるような「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータからそのＲＤＳ送信アドレスを除去し得る。ユーザ１が、ＤＳＴ−１についてのＲＤＳを受信したいと永久に思わない場合、ユーザ１は、「ＤＳＴ＿Ｕｓｅｒｓ」パラメータからそのＩＤをさらに除去し得る。
ユーザ２が、今のところＤＳＴ−１についてのＲＤＳを受信したいと思わない場合、それは、どれくらい多くのユーザが、現在、「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータを調べることによって、ＤＳＴ−１のＲＤＳを受信しているかをチェックし得る。それは、ここで、ＤＳＴ−１のＲＤＳを現在受信している唯一のユーザであることを見出すため、ユーザ２は、表１に示されるような「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータからそのＲＤＳ送信アドレスを除去するだけでなく、このＤＳＴ−１を実際に無効にし得る（言い換えると、ＤＳＴ−１は、このときに実際に無効にされ得る）。ユーザ２が、ＤＳＴ−１についてのＲＤＳを受信したいと永久に思わない場合、ユーザ２は、「ＤＳＴ＿Ｕｓｅｒｓ」パラメータからそのＩＤをさらに除去し得る（特に、「ＤＳＴ＿Ｕｓｅｒｓ」に含まれるユーザが存在しない場合、一旦ユーザ２が除去されると、ＤＳＴ−１は無効にされるだけでなく、その代わり、このＤＳＴ−１は削除され得る）。
（３）所与のＤＳＴもまた、（ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｔｒｉｇｇｅｒパラメータで示されるような）ＬＦＡで発生するイベントに基づいて有効にされ得る。図６に示される例として、ＤＳＴ−１が、ＬＦＡ−１でのリアルタイムの騒音レベル監視に関連するＲＤＳを生成する場合、交通渋滞がＬＦＡ−１で検出されるときにＤＳＴ−１がそのインフィールドマネージャ（例えば、ＤＳＣＳエージェント２）によって有効にされ得ることが可能である。一旦、ＤＳＴ−１が有効にされると、ＤＳＣＳエージェント２は、ＤＳＴ−１のＤＳＴ＿Ｓｔａｔｕｓパラメータを更新するために、ＣＮでのＤＳＣＳエージェント１に知らせ得る。
この場合、ユーザがＤＳＴを作成しているとき、それは、ＤＳＴ作成要求を送信するときにそのＲＤＳ送信アドレスを直接提供し得る（次いで、それは、「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに含まれ得る）。後に、別のユーザもまたこの全体のＤＳＴを再使用したいと思う場合、この新しいユーザは、単に、そのＩＤをこのＤＳＴの「ＤＳＴ＿Ｕｓｅｒｓ」に追加することによって、要求をＤＳＣＳエージェントに送信し、また、それ自体のＲＤＳ送信アドレスを「ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ」パラメータに追加し得る。
ＤＳＴステータスが変更される度に、その最新のステータスは、ＤＳＴでの「ＤＳＴ＿Ｓｔａｔｕｓ」パラメータで反映され得、フィールドマネージャはまた、ある動作を行う（例えば、それらのステータスに基づいて、それらのＤＳＴについての対応するワークスレッドを中止／再開する）必要があり得る。
本明細書に開示される方法およびシステムは、以下に論じられるように、ｏｎｅＭ２Ｍ機能アーキテクチャ実施形態で実装され得る。
開示されたＤＳＣＳソリューションは、図１５に示されるように、ｏｎｅＭ２Ｍサービス層での新しいＣＳＦと見なされ得る。異なるタイプのＭ２Ｍノードは、ＩｏＴデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、（車両、携帯電話などの）モバイルノードなどのＤＳＣＳサービスを実装し得ることを理解されたい。特に、それらのノードのための種々の／異なるハードウェア／ソフトウェア能力に応じて、それらのノードによって実装されるＤＳＣＳサービスの能力もまた、異なり得る。
定義される関連エンティティについてのｏｎｅＭ２Ｍ実施形態は、以下のようである。
データソース（ＤＳ）は、ｏｎｅＭ２Ｍ ＡＥまたはＣＳＥであり得る。故に、ＡＥまたはＣＳＥによって生成される未加工データは、ＤＳ識別プロセスの間にｏｎｅＭ２Ｍリソース発見を介して識別され得る、＜ｃｏｎｔａｉｎｅｒ＞、＜ｔｉｍｅＳｅｒｉｅｓ＞、または＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞リソースで記憶され得る。
ローカルフォグノード（ＬＦＮ）は、ｏｎｅＭ２Ｍ ＣＳＥ（例えば、ＡＳＮ−ＣＳＥ）であり得る。
ＬＦＮリーダー（ＬＦＮＬ）およびフォグノード（ＦＮ）は、（ＭＮ−ＣＳＥなどの）ｏｎｅＭ２Ｍ ＣＳＥであり得る。
クラウドノード（ＣＮ）は、（ＩＮ−ＣＳＥなどの）ｏｎｅＭ２Ｍ ＣＳＥであり得る。
ＤＳＣＳユーザは、ｏｎｅＭ２Ｍ ＡＥ（例えば、ＩＮ−ＡＥ）であり得る。
図１６に示される＜ｄｓｃｓ＞と呼ばれる新しいリソースが開示される。＜ｄｓｃｓ＞は、図１６に図示されない、サービス層リソースのための共通属性を含む。ＣＳＥがＤＳＣＳ能力を有する（例えば、ＤＳＣＳエージェントがこのＣＳＥ上で実行している）場合、それは＜ｄｓｃｓ＞子リソースを有し得る。すべてのＤＳＣＳ関連要求は、このリソースに向けられ得る。例えば、ユーザは、ＤＳＴ作成要求を、ＣＳＥ−１上でホストされる＜ｄｓｃｓ＞リソースに送信し得る。同様に、ＣＳＥ−１が、作成されたＤＳＴ−１を展開することを意図するとき、それはまた、エッジで別のＣＳＥ−２によってホストされる＜ｄｓｃｓ＞リソースにＤＳＴ展開要求を送信し得る。
ＤＳＣＳを曝すための追加のまたは代替の方法は、＜ＣＳＥ＞リソースについて定義される「ｄｓｃｓ＿ｃａｐａｂｉｌｉｔｙ」と呼ばれる新しい属性を使用することであり、それは、このＣＳＥがＤＳＣＳ能力を有するかどうかを示し得る。故に、すべてのＤＳＣＳ関連要求は、＜ＣＳＥＢａｓｅ＞リソースに向けて送信され得る。
新しい＜ｄｓｔ＞リソースは、ＤＳＴを表すために開示され、ここで、すべてのリソース属性は、ＤＳＴで定義されるパラメータに対応している（ＤＳＴについての詳細な定義について表１を参照）。
＜ｄｓｔ＞リソースは、表２で規定される子リソースを含み得る。
Figure 2021536606
上記の＜ｄｓｔ＞リソースは、表３−１〜表３−３で規定される属性を含む。
Figure 2021536606
Figure 2021536606
Figure 2021536606
以下のプロシージャは、＜ｄｓｔ＞リソースを作成するために使用され得る。
Figure 2021536606
以下のプロシージャは、＜ｄｓｔ＞リソースの属性を読み出すために使用され得る。
Figure 2021536606
以下のプロシージャは、＜ｄｓｔ＞リソースの属性を更新するために使用され得る。
Figure 2021536606
以下のプロシージャは、＜ｄｓｔ＞リソースを削除するために使用され得る。
Figure 2021536606
＜ｄｓｔＴｒｉｇｇｅｒｉｎｇ＞は、それが表現を有しないため、仮想リソースである。それは、＜ｄｓｔ＞リソースの子リソースである。このｒｅｓｏｕｒｃｅは、親＜ｄｓｔ＞リソースを有効または無効にするために使用される。ＤＳＴの最新のステータスが、＜ｄｓｔ＞リソースの「ＤＳＴ＿ｓｔａｔｕｓ」属性で反映されるべきであることに留意されたい。
＜ｄｓｔＴｒｉｇｇｅｒｉｎｇ＞リソースは、親＜ｄｓｔ＞リソースが作成されるときに作成される。
読み出し動作は、＜ｄｓｔＴｒｉｇｇｅｒｉｎｇ＞について適用可能でない場合がある。更新動作は、親＜ｄｓｔ＞リソースを有効または無効にするために使用され得る。
Figure 2021536606
＜ｄｓｔＴｒｉｇｇｅｒｉｎｇ＞リソースは、親＜ｄｓｔ＞リソースがホストＣＳＥによって削除されるときに削除される。削除動作は、Ｍｃａ、Ｍｃｃ、またはＭｃｃ’を介して適用可能でない。
ＧＵＩインターフェースは図１７で開示され、それは、人間ユーザのために自らの使用に基づいてＤＳＴを作成するために使用され得る。一般に、それらのパラメータは、（Ｃｒｅａｔｉｎｇ＿ＤＳＣＳ＿Ａｇｅｎｔであり得る）ＤＳＣＳエージェントに伝送され得、ここで、ＤＳＴは、それに従って作成され得る。言い換えると、このユーザインターフェースでのパラメータは、図６のステップ２での要求メッセージで搬送されるパラメータであり得る。見られ得るように、ユーザは、標的領域、ＲＤＳ生成頻度、ＲＤＳ状況などの、全体のＤＳＴについてのいくつかの一般的な情報を規定し得る。その一方で、ユーザはまた、ＤＳＴでのＤＥの各々についての詳細な定義を入力し得る。ユーザが、ＤＳＴで複数のＤＥを有したいと思う場合、より多くの入力エリアがそれらのＤＥについてこのパネル上に現れ得るように、「より多くのＤＥを追加」ボタンをクリックし得る。
図４に示されるスマートシティユースケース例に戻って参照すると、スマートシティを構築するために、市当局は、（ｏｎｅＭ２Ｍなどの）規格ベースのサービス層（ＳＬ）プラットフォームを採用し、道路／ストリート、公共ビル、バス／地下鉄などの市の公共インフラストラクチャ上に多くのＩｏＴセンサおよびデバイスを展開している。制限された予算に起因して、市当局はまた、このスマートシティのイニシャティブのために、私的な組織および個人の関与を要求する。故に、（私的な車、携帯電話などの）私的な財産上にインストールされたそれらのＩｏＴデバイスはまた、システム内に統合され、それは、シティのリアルタイム実行ステータスを反映する大量の広範なＩｏＴデータを生成し得る。
シティは、中心業務地区（ＣＢＤ）、郊外住宅エリアなどの多くの地理的領域を有し得、それは、ローカルフォグエリア（ＬＦＡ）と称され得る。膨大なＩｏＴデバイスが、それらのＬＦＡで展開され得、大量のＩｏＴデータが、それらのＬＦＡから生成され得る。通信ネットワーク観点から、異なるシティ領域が、複数のＬＦＡを構成する（例えば、図４に示されるように、ＣＢＤが、ＬＦＡ−１に対応し、郊外住宅エリアが、ＬＦＡ−２に対応する）。
スマートシティ制御コンソールは、ユーザが、必要性に基づいて種々のデータ分析要求を呈することを可能にするクラウドで展開される。例えば、組織Ａからのユーザは、所与のエリアについての現在の気象および環境汚染ステータス（例えば、大規模道路工事およびビル建設下のエリアである、図４に示されるようなＬＦＡ−Ｘ）を評価することを意図する、（ＤＳＣＲ−１として示される）データサンプル収集要求を有する。実際には、データ分析結果は、通常は、種々のチャート（例えば、ラインチャートまたはバーチャート）を介して表される。ユーザが見ることを意図する分析チャートのタイプ（例えば、ラインチャート）に加え、ユーザはまた、データサンプルがあるべき姿、チャートを描くためにどの入力があるべきかなどを規定し得る。チャートを描くためのそれらのデータサンプルを準備するために、関連する未加工データが、データソース（ＤＳ）とも称される種々のＩｏＴデバイスから収集される必要がある。スマートシティユースケースでは、ＤＳ例は、温度センサ、湿度センサ、汚染センサ、騒音センサなどを含む。特に、それらのセンサまたはデバイスは、（ユーザが入っている）組織Ａ以外の異なる組織によってインストールされ得る。
ＤＳＣＲ−１で、ユーザがＬＦＡ−Ｘについてのラインチャートを見ることを意図し、それは、３分毎に１つのデータサンプルを要求することが想定され得る。特に、各データサンプルは、以下の２つのデータ要素によって構成され得、それは各々、品質要件に対応付けられる。
データ要素（ＤＥ）−１について、３分毎にサンプリングされるＬＦＡ−Ｘの平均温度。
ＤＥ−１の品質要件について、温度読み取り値は、精度を保証するために、ＬＦＡ−Ｘで展開される、少なくとも１００個の異なる温度センサから収集される必要がある。
ＤＥ−２について、３分毎にサンプリングされるＬＦＡ−Ｘの平均騒音レベル。
ＤＥ−２の品質要件について、騒音読み取り値は、ＬＦＡ−Ｘでの３０個の主要な交差点で展開される騒音センサから収集される必要がある。
クラウドで展開されるスマートシティ制御コンソール上でラインチャートを描くために、（ＤＥ−１、ＤＥ−２、タイムスタンプ）のフォーマットを有するデータサンプルは、３分毎に必要とされ得る。そのようなデータサンプルは、ＤＳＣＲ−１についての使用準備済のデータサンプル（ＲＤＳ）と称され得る。
上記のユースケースで示されるようなＲＤＳを生成するために、膨大なＩｏＴ未加工データが、ＬＦＡで収集され、処理される必要がある。フォグコンピューティングパラダイムは、膨大な未加工データが、中央処理のためにクラウド側に移動される必要がなく、その代わり、ＲＤＳを生成するためにＬＦＡで処理され得るという意味において、そのようなアプリケーションをサポートするのに素晴らしく適している。
ユーザは、ＬＦＡでの利用可能なＩｏＴ ＤＳについての知識を有しない場合がある。例えば、スマートシティユースケースでは、展開されたＳＬプラットフォームはまた、異なる組織および個人から多くのＩｏＴ ＤＳを統合し得る。クラウド側からのユーザは、それらのＩｏＴ ＤＳを展開した同じグループでない場合がある。ユーザは、多くの場合、（ゲートウェイ、ロードサイドユニットなどの）データ処理能力を有するＬＦＡ内の多くのＬＦＮの所有者でなく、ユーザは、通常は、それらのＬＦＮが異なるグループまたは組織によって所有され得るため、所望のデータ処理動作のためにＬＦＡ内の任意のＬＦＮを構成するための任意の能力を有しない。（Ｍｉｃｒｏｓｏｆｔ ＩｏＴ ＥｄｇｅまたはＡｍａｚｏｎ Ｇｒｅｅｎｇｒａｓｓなどの）いくつかの既存のＩｏＴエッジ製品は、そのような異種シナリオで効率的に機能することができないことは、着目に値する。例えば、それらの製品は、ユーザが、通常、利用可能なＤＳの完全な知識、およびＬＦＡ内の処理ノードのための完全な構成能力の両方を有する、比較的単純なケースをサポートする。
そのような異種シナリオをサポートするために、一般的なソリューションは、ＩｏＴシステムが、ユーザから種々のＤＳＣＲを受信し得る、共通データサンプル収集サービスを提供し得ることである。所与のＤＳＣＲは、ユーザが受信することを意図するＲＤＳのタイプについてのすべての詳細を記載する。しかしながら、ユーザは、このＤＳＣＲを供給するためにＬＦＡ内で発生する任意のアクティビティに関与しない場合がある。言い換えると、ユーザは、単に、ＤＳＣＲをＩｏＴシステムに提出し得、システムは、ＲＤＳをユーザに配信するためにすべてのことを処理する。
特定のＤＳＣＲを供給するとき、２つの特定の技術的問題が考慮される必要があり得る。
ＤＳ識別プロセスについて、所与のＤＳＣＲに対応するＲＤＳでのＤＥの各々について、この所与のＤＳＣＲについての所望のＤＳであるかどうかを判定するために発見および／または評価される必要がある（そのようなプロセスは、ＤＳ識別プロセスと呼ばれる）、ＬＦＡ内の数千の潜在的ＤＳが存在し得る。それらのＤＳを識別するために、発見能力を有する、あるＬＦＮが利用され得、それは、ＤＳディスカバラー（ＤＳＤ）として機能し得る。例えば、ｏｎｅＭ２Ｍシナリオでは、リソース発見能力を有する任意のＡＥまたはＣＳＥは、ＤＳＤとして機能し得る。しかしながら、効率的な方法でＤＳ識別プロセスを行うことが不可欠である。主要な課題は、ＤＳＤとして機能し得るＬＦＡ内の複数のＬＦＮが存在し得るが、それらのＬＦＮの各々は、異なる／制限されたＤＳ識別能力または異なるアクセス特権を有し得ることである。例として、あるＬＦＮは、特定の組織Ａに属する、あるＤＳを識別し得、一方、別のＬＦＮは単に、別の組織Ｂに属する、あるＤＳを識別し得る。それらのＬＦＮの両方は、ＤＳＤとして機能して、特定のＤＳＣＲを援助し得、それは、２つの組織の両方から所望のＤＳを識別することが要求され得る。したがって、ＬＦＡ内の複数のＬＦＮは、所与のＤＳＣＲについて所望のＤＳを識別するために、それらそれぞれの発見能力を完全に利用および統合するように、一緒に「協働的に」機能することが必要であることが分かり得る。しかしながら、現在、異なるＤＳＤの種々のＤＳ識別能力を、ＬＦＡで協働的なＤＳ識別を実現するための全体的な方法で活用することができない。
ＲＤＳ生成プロセスについて、ＤＳ識別プロセスの後、（ＲＤＳ生成プロセスと呼ばれる）次のステップは、所望のＤＳから、収集された未加工データを処理し、ＲＤＳを生成し、それらをユーザに配信する方法に向けられる。特に、ＤＳから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理は、協働的に行われる必要があり得る。ＬＦＮは、ＩｏＴ未加工データを処理し得る場合、未加工データプロセッサ（ＲＤＰ）として機能し得る。しかしながら、主要な課題は、ＲＤＰとして機能し得るＬＦＡ内の複数のＬＦＮが存在し得、それらのＬＦＮは、異なる組織に属し得、それらのＬＦＮの各々は、異なるおよび／または制限されたデータ処理能力を有し得る（例えば、あるものは、データ事前処理を行うだけであり得、あるものは、基本データアグリゲーション処理を行い得、一方、あるものは、高度なデータ分析処理を行い得る）ことである。したがって、ＬＦＡ内の複数のＬＦＮは、所与のＤＳＣＲについてＲＤＳを生成するために、それらそれぞれのデータ処理能力を完全に利用／統合するために、一緒に協働的に機能することが必要であることが分かり得る。しかしながら、現在、ＤＳＣＲを供給するためにＬＦＡで協働的なＲＤＳ生成を行うためのソリューションが存在しない。
フォグベースのサービス層（ＳＬ）のための協働的なＤＳ識別およびＲＤＳ生成のための方法およびシステムが本明細書に開始される。方法およびシステムは、以下のことを含み得るが、それらに限定されない。
協働的なデータソース（ＤＳ）識別について、ＤＳＣＲに対応するＲＤＳでのＤＥの各々について、このＤＳＣＲを供給するための所望のＤＳであるかどうかを判定するために発見および／または評価される必要がある、ＬＦＡ内の数千の潜在的ＤＳが存在し得る。データソースディスカバー（ＤＳＤ）として機能し得る、ＬＦＡ内の異なるローカルフォグノード（ＬＦＮ）は、異なるＤＳ識別および発見能力を有し得る。故に、１つ以上のＬＦＡ内の（ＤＳＤとしての）複数のＬＦＮが、所与のＤＳＣＲのための所望のＤＳを識別するために一緒に協働的に機能することを可能にする、方法およびシステムが提供される。
所与のＬＦＮは、ＤＳ識別能力を有し得るが、（例えば、所望の／識別されたＤＳからデータを収集するための）データ収集能力、または、（例えば、ＲＤＳを生成するための未加工データを処理するための）特定のデータ処理能力を有しない場合がある。したがって、本明細書に開示されるＤＳ識別プロセスは、所与のＤＳＣＲによって要求されるようなＲＤＳでのＤＥの各々について、所望のＤＳを識別することを指すだけでなく、ＲＤＳを生成するために未加工データを処理するための未加工データプロセッサ（ＲＤＰ）として機能し得る適切なＬＦＮを見出すことに加え、それらの識別されたＤＳから未加工データを収集するための未加工データコレクタ（ＲＤＣ）として機能し得る適切なＬＦＮを見出すことを指す。本明細書に開示される協働的なＤＳ識別のためのソリューションは、ＲＤＣ発見を伴うＤＳ識別およびＤＳ識別結果統合、ならびにＲＤＣ／ＲＤＰジョブ割り当てを含むが、それらに限定されない。
協働的なＲＤＳ生成について、ＲＤＳ生成プロシージャの間、主要な作業は、収集された未加工データを処理し、ＲＤＳを生成する方法に関連する。ＤＳから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理はまた、協働的に行われる必要があり得る。所与のＤＳＣＲについて、異なるＬＦＮが、このＤＳＣＲのためにＲＤＳを生成するために要求される種々のデータ処理能力を有し得るため、そのデータ処理は、複数のＲＤＰをクロスさせ得る。本明細書に開示される協働的なＲＤＳ生成のための主なソリューションは、所与のＤＳＣＲのためのＲＤＳ生成、所与のＤＥのためのＲＤＳ生成、および所与のＤＳＣＲのためのＲＤＳアセンブリングのトリガを含むが、それらに限定されない。
本開示全体を通して使用されるいくつかの用語についての例示的定義が以下に説明される。
クラウドノード（ＣＮ）について、展開階層でより下の他のフォグノードの動作を管理するクラウド能力を有するノード。本開示において、用語「クラウド」は、クラウドノードを指すために使用され得ることに留意されたい。クラウドは、アプリケーションのためのフォグサービス層を一緒に有効にする、異なるフォグノード間の相互作用を監視および管理する。
データサンプル収集要求（ＤＳＣＲ）について、ＤＳＣＳのユーザは、ＤＳＣＲでその必要性を規定し得、それは、受信することを意図するＲＤＳのタイプについての詳細を含み得る。
使用準備済のデータサンプル（ＲＤＳ）について、所与のＤＳＣＲについて、その対応するＲＤＳは、ユーザが使うために（例えば、分析チャートを描くために）すでに使用準備済段階にあるデータサンプルを指す。ＲＤＳは、ＬＦＡ内のＬＦＮによって行われるＲＤＳ生成プロセスを介して取得され得る。例えば、所与のＤＳＣＲについて、ＤＳＣＳは、フォグコンピューティングパラダイムを活用することによってＲＤＳを生成するために、効率的なＩｏＴ未加工データ収集およびデータ処理を行い得る。スマートシティユースケース例を使用して、（最後の３分でのＬＦＡ−１の平均温度である）ＤＳＣＲ−１でのＤＥ−１について、ＬＦＡ−１で展開されるＤＳＣＳは、ＬＦＡ−１内の関与する温度センサから未加工データを収集し、未加工データに対する平均アグリゲーション動作を行い、ＤＳＣＲ−１のすべてのＲＤＳについてのＤＥ−１パートを生成する必要がある。ＤＳＣＲ−１のすべてのＲＤＳについてのＤＥ−２パートはまた、同様の方法で生成され得る。状況整合を介して、ＤＥ−１パートについてのデータおよびＤＥ−２パートについてのデータは、ＲＤＳを生成するために、それに従ってアセンブルされ得る。例えば、ＤＥ−１パートについての１つのピースのデータおよびＤＥ−２パートについての１つのピースのデータは、同じ３分の時間間隔であり、これらの２つのピースのデータは、この特定の３分の時間間隔で単一の／完全なＲＤＳを形成するように一緒にアセンブルされ得る。
データ要素（ＤＥ）について、ＤＳＣＲは、何のＤＥがこのＤＳＣＲに対応する単一のＲＤＳに含まれ得るか（例えば、それは、その対応するＲＤＳがどのようなものかを説明し得る）を定義する。言い換えると、ＲＤＳは、その対応するＤＳＣＲの実際のデータサンプルインスタンスである。例として、以下の２つのＤＥを有するＤＳＣＲ−１を考慮する。ＤＥ−１（最後の３分でのＬＦＡ−１の平均温度）およびＤＥ−２（最後の３分でのＬＦＡ−１の平均騒音レベル）。ＤＳＣＲ−１のすべてのＲＤＳは、それらの２つのＤＥ（ＤＥ−１、ＤＥ−２、ＲＤＳ＿Ｃｏｎｔｅｘｔｓ）を有し得、ここで、ＲＤＳ＿Ｃｏｎｔｅｘｔｓは、このＲＤＳについての詳細な状況情報（例えば、この特定のＲＤＳがどの３分の時間間隔に関連するか）を与える。
フォグノード（ＦＮ）について、計算、記憶、通信、分析などの任意のフォグリソースを有するノード。フォグノードは、これらのリソースのうちの少なくとも１つを有し得、また、フォグノード上で実行している他のソフトウェアまたはサービスを有し得る。ＦＮは、ＬＦＮのレベルよりも高いあるレベルで展開されることが想定される。クラウドノード（ＣＮ）が最も高いレベルにある状態で、ＦＮ展開のいくつかのレベルが存在し得る。スマートシティユースケース例では、ＦＮは、ネットワーク内のより高いレベルでのルーターであり得る。
ローカルフォグエリア（ＬＦＡ）について、地理的領域（例えば、シティ）は、異なるアプリケーションシナリオに応じて複数のＬＦＡに分割され得る。スマートシティユースケースシナリオでは、特定の住宅エリアが、ＬＦＡであり得るか、またはダウンタウンエリア内の中心業務地区（ＣＢＤ）が、ＬＦＡであり得る。
ローカルフォグノード（ＬＦＮ）について、ＬＦＮは、計算、記憶、および通信能力を有するＬＦＡ内のノードであり得る。ＬＦＮは、その対応するＬＦＡ内のＬＦＮリーダー（ＬＦＮＬ）と通信および／または相互作用し得る。例示的ＬＦＮは、人の携帯電話、移動バス、家のホームゲートウェイなどであり得る。ＬＦＮは、ネットワークの最も低いレベルであるＦＮのタイプである。ＬＦＮは、同じＬＦＡ内の他のＬＦＮと相互作用／協働し得、種々のＤＳからのＩｏＴデータの発見、収集、および処理を行い得る。
ＬＦＮリーダー（ＬＦＮＬ）について、所与のＬＦＡは、そのエリアでＬＦＮリーダーを有する。ＬＦＮＬは、そのＬＦＡ内のすべてのＬＦＮのアクティビティを管理し、制御し、および／またはコーディネートするＬＦＮであり、より高いレベルにあるＦＮに接続され得る。スマートシティユースケース例では、ＬＦＮＬは、特定の住宅エリアの主要ゲートウェイであり得る。
ＤＳ識別プロセスについて、所与のＤＳＣＲに対応するＲＤＳでのＤＥの各々について、このＤＳＣＲのための所望のＤＳであるかどうかを判定するために発見および／または評価される必要がある、ＬＦＡ内の数千の潜在的ＤＳが存在し得る。そのようなプロセスは、ＤＳ識別プロセスと称され得る。
ＲＤＳ生成プロセスについて、ＲＤＳ生成プロセスは、所望のＤＳから収集される未加工データを処理し、ＲＤＳを生成する方法を指す。
データソース（ＤＳ）について、ノードは、それがＩｏＴデータのソースの場合、ＤＳであり得る。例えば、ノードは、センサ、カメラ、交通灯、またはデータを生成する任意のＩｏＴデバイスであり得る。ロードサイドユニットはまた、それが道路表面に関連するセンサデータを生成するため、ＤＳであり得る。ロードサイドユニットはまた、それが、あるデータ処理能力を実行し得、および／またはＬＦＮＬと通信し得るため、ＬＦＮであり得る。一般に、センシングを有するだけでなく、コンピューティング、記憶、および通信能力を有する、ＬＦＡ内のノードは、ＬＦＮおよびＤＳであり得る。
データソースディスカバラー（ＤＳＤ）について、これは、論理的役割である。所与のＬＦＮが、ＤＳ識別プロセスの間に所与のＤＳＣＲについてＤＳを発見することに関与する場合、それは、このＤＳＣＲについてのＤＳＤと見なされ得る。
未加工データコレクタ（ＲＤＣ）について、これは、論理的役割である。所与のＬＦＮが、所与のＤＳＣＲを供給するためにいくつかのＤＳから未加工データを収集することに関与する場合、それは、このＤＳＣＲについてのＲＤＣと見なされ得る。
未加工データプロセッサ（ＲＤＰ）について、これは、論理的役割である。所与のＬＦＮが、ＲＤＳ生成プロセスの間に所与のＤＳＣＲについて収集された未加工データを処理することに関与する場合、それは、このＤＳＣＲについてのＲＤＰと見なされ得る。一般に、ＬＦＮは、同時にＲＤＣ、ＤＳＤ、およびＲＤＰの複数の論理的役割を引き受け得るか、またはそれらの論理的役割は、所与のＤＳＣＲを供給するときに異なるＬＦＮによって引き受けられ得ることに留意されたい。特に、３つの異なる論理的役割を定義することによって、異なるタスクが分離され、異なる役割によって行われ得るため、作業の協働が促進され得る。
本開示で提案されるアイディアが、フォグ関連用語を使用して説明されるが、本開示で提案されるアイディアがまた、エッジシナリオに適用され得ることは、着目に値する。例えば、ＬＦＡはまた、エッジでの特定のエリアとして解釈され得、ＬＦＮは、エッジ側でのノードであり得、ＬＦＮＬは、エッジでのゲートウェイまたはエッジでのロードサイドユニットなどであり得る。
データサンプル収集サービス（ＤＳＣＳ）と呼ばれるサービス層のための共通サービスの２つの重要な特徴が本明細書に開示される。ＤＳＣＳのハイレベルアーキテクチャが図１８に示される。ＤＳＣＳは、ユーザから種々のＤＳＣＲを受信し、そのユーザの代わりに、すべての詳細を処理し得る。ＤＳＣＲでは、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプル（例えば、ＲＤＳ）がどのようなものかを明確に表し得る。（ＬＦＮ、ＬＦＮＬ、ＦＮ、またはＣＮ上などの）サービス層ノードは、このノードがデータサンプル収集関連サービスを提供することを意図する場合、ＤＳＣＳエージェントを有し得る。ＳＬノード上のＤＳＣＳエージェントは、ユーザによって呈されるＤＳＣＲを供給するために、ＤＳＣＳユーザと相互作用するだけでなく、他のＤＳＣＳエージェントと協働し得る、ソフトウェアのピースである。ＤＳＣＳで、一旦ユーザがそのＤＳＣＲを呈すると、ユーザは、ＬＦＡで適格なＤＳをどのように識別するか、および未加工データ処理およびＲＤＳ生成のためにそれらのＬＦＡでＬＦＮをどのように構成するかに関する任意の詳細において関与する必要がない。図１８に示される例として、ＣＮでのＤＳＣＳエージェントがユーザからＤＳＣＲを受信した後、それは、どのＬＦＡが関与するかを見出し得る。ユーザが、単に、特定のＬＦＡ（例えば、図１８の左側に示されるもの）からデータサンプルを収集したいと思う場合、このＤＳＣＲの対応するタスクは、そのＬＦＡ内のＬＦＮＬ上のＤＳＣＳエージェントに割り当てられ得る。このＬＦＮＬは、このＬＦＡ内のすべてのＬＦＮによって行われるアクティビティのための中央コントローラ、マネージャ、および／またはコーディネータとして機能し得、それは、本明細書に開示される２つの特定の技術的問題（例えば、ＤＳ識別およびＲＤＳ生成）を含み得る。
協働的なデータソース（ＤＳ）識別について、ＤＳＣＲに対応するＲＤＳでの各々のＤＥについて、このＤＳＣＲのための所望のＤＳであるかどうかを判定するために発見および／または評価される必要がある、ＬＦＡ内の数千の潜在的ＤＳが存在し得る。ＬＦＡ内のＬＦＮは、異なるＤＳ識別能力を有し得る。故に、ＬＦＡ内の複数のＬＦＮが、所与のＤＳＣＲのための所望のＤＳを識別するために一緒に協働的に機能し得ることが本明細書に開示される。ＬＦＮ−１が、ＤＳ識別タスクに関与しており、所与のＤＳＣＲ−１のための所望のＤＳを識別していることが想定され得る。この場合、ＬＦＮ−１は、ＤＳディスカバラー（ＤＳＤ）として機能した。しかしながら、ＬＦＮ−１は、その制限されたワークロード能力に起因して、このＤＳについて未加工データコレクタ（ＲＤＣ）としてさらに機能しない場合がある。したがって、別のＬＦＮ−２がＲＤＣとして機能する必要があり得、それは、このＤＳから未加工データをさらに収集することを担う。同様に、ＬＦＮ−２は、このＤＳについて未加工データプロセッサ（ＲＤＰ）としてさらに機能しない場合がある。したがって、別のＬＦＮ−３がＲＤＰとして機能する必要があり得、それは、このＤＳから収集される未加工データのさらなる処理を担う。したがって、本開示で考慮されるＤＳ識別プロセスは、所与のＤＳＣＲによって要求されるようなＲＤＳでのＤＥの各々についての所望のＤＳの識別を指すだけでなく、それらの識別されたＤＳについてのＲＤＣおよびＲＤＰとして機能し得る適切なＬＦＮを見出すことを指す。
協働的なＲＤＳ生成について、ＲＤＳ生成プロセスの間、主要な作業は、収集された未加工データを処理し、ＲＤＳを生成し、それらをユーザに配信する方法に関連する。ＤＳから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理は、協働的に行われる必要があり得る（例えば、ＩｏＴデータ処理は、所与のＲＤＳ生成プロセスの間に複数のＲＤＰをクロスさせ得る）。例えば、ＲＤＰとして機能するＬＦＮ−１が、予期しないおよび／または大きい未加工データの到達に起因して、一時的に過負荷状態になる場合、それは、非常に軽いワークロードを現在有し、またＲＤＰとして機能し得る、別のＬＦＮ−２にそのデータ処理のいくつかをオフロードし得る。別の例として、ＬＦＮ−１が、単に、その制限されたデータ処理能力に起因して、ある単純なデータ処理を行うことができる場合、それは、深層データ処理のために、その事前処理されたデータを別のより強力なＲＤＰ（例えば、ＬＦＮ−２）に送信し得る。
本明細書に開示される方法およびシステムを使用して、異なるＬＦＮが、ＤＳ識別プロセスまたはＲＤＳ生成プロセスに関与する異なる役割を行い得る。例えば、ＤＳＤとして機能するＬＦＮは、所望のＤＳを発見するために一緒に機能し得る。他のノードは、（ＤＳ識別プロセスの間に識別される）所望のＤＳから未加工データを収集し、未加工データを処理し、ＲＤＳを生成するために、ＲＤＣおよび／またはＲＤＰとしてさらに機能し得る。
開示された方法はまた、異種フォグシナリオでのダイナミクスおよび不確実性を説明することは、着目に値する。例えば、異なるＬＦＮは、異なる組織に属し、異なる主な使用目的を有し得るため、ＬＦＮがＤＳ識別またはＲＤＳ生成に関連する特定のタスクに関与し、それに寄与し続けるための厳しい要件は存在しない。したがって、所与のタスクで、異なるＬＦＮからの能力は、協働的な方法でそれらのＬＦＮ作業をするように一緒に統合される必要があり得る。
図１８（さらに本開示の他の図）は、クラウドでのユーザが、ＤＳＣＲを、ＣＮでのＤＳＣＳエージェントに送信することを示す。追加でまたは代替で、ユーザがＬＦＡから生じ得、そのような場合、ユーザが、ＤＳＣＲを、それらのＬＦＡ内の対応するＬＦＮＬ上でＤＳＣＳエージェントに送信し得ることが理解される。本開示での提案されたプロシージャおよびソリューションはまた、このケースをサポートする。
ＬＦＮ能力登録プロシージャでは、所与のＬＦＡ内のＬＦＮＬは、ＬＦＡ内のＬＦＮのすべてのアクティビティを管理またはコーディネートすることを担い得る。故に、ＬＦＮＬの管理作業を促進するために、ＬＦＮの各々は、それらが、ＤＳ識別およびＲＤＳ生成に関連する任意のタスクに関与し得る前に、最初に、その潜在的能力をＬＦＮＬに報告および／または登録する必要があり得る。異なるＬＦＮの能力／機能性の利用は、それらの能力が異なるＤＳＣＲを供給するときに共有され得るため最大化され得る。追加でまたは代替で、同じ能力を有する複数のＬＦＮが統合され得、それは、ＤＳ識別およびＲＤＳ生成プロシージャを行うときにスケーラビリティを向上させ得る。
ＬＦＮリーダーへのＬＦＮ能力登録のための例示的プロシージャは、図１９に示され、以下に論じられる。
前提条件として、ＬＦＮ−１が、ＬＦＮＬ−１であるＬＦＡ−１内のＬＦＮＬを識別し得、それは、任意の既存の技術に基づき得ることが理解される。例えば、ＬＦＮＬ−１は、それがこのＬＦＡ内のＬＦＮＬとして選択されていることを請求するために、ＬＦＡ−１内のすべてのＬＦＮにブロードキャストし得る。
ステップ１で、ＬＦＮ−１上のＤＳＣＳエージェント２は、ＤＳ識別およびＲＤＳ生成に関連する将来のタスクに関与するために、ＬＦＮ−１の能力を、ＬＦＮＬ−１上のＤＳＣＳエージェント１に登録することを意図する。
ステップ２で、ＤＳＣＳエージェント２は、登録要求をＤＳＣＳエージェント１に送信し、それは、ＬＦＮ−１の潜在的能力および識別子についての詳細な情報を含む。ＬＦＮＬに報告される情報は、ＬＦＮ−１がＤＳＤ、ＲＤＣ、およびＲＤＰに関連する役割のいずれかを供給し得るかどうかを説明し得る（所与のＬＦＮが、複数の論理的役割を供給し得ることが可能である）。以下の例示的な３つのパラメータは、ＬＦＮ−１が潜在的ＤＳＤであり得るかどうかを説明する。
ＤＳＤ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔについて、このパラメータは、それをＤＳＤとして有効にし得るＬＦＮ−１のすべての能力をリストし得る。例えば、ｏｎｅＭ２Ｍシステムでは、所与のＣＳＥは、それがｏｎｅＭ２Ｍ基本リソース発見能力を有する場合にＤＳＤであり得る。追加でまたは代替で、リソース発見能力は、このパラメータに含まれ得る。このＣＳＥが、高度なセマンティックリソース発見能力を有する場合、これらの能力は、このパラメータに含まれ得る。
ＤＳＤ＿Ｗｏｒｋ＿Ｓｃｈｅｄｕｌｅ＿Ａｖａｉｌａｂｉｌｉｔｙ＿Ｌｉｓｔについて、「ＤＳＤ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔ」でリストされるような能力の各々について、対応する作業スケジュールは、このパラメータに含まれ得る。例えば、ＬＦＮ−１は、午前１０時〜午後２時の間に、協働的なＤＳ識別のために、その高度なセマンティックリソース発見能力を提供したいと思わない場合がある。これは、ＬＦＮ−１が、通常、このときくらいに、それ自体の組織からの重いワークロードを有する（それは、第１の優先度を有する）ためである。
ＤＳＤ＿Ｃａｐａｂｉｌｉｔｙ＿Ｓｃｏｐｅについて、このパラメータは、「ＤＳＤ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔ」でリストされるようなＤＳＤ能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、ＬＦＮ−１が単に、あるノード上でまたはある場所で、ＤＳ識別を行い得ることを示し得る。ＬＦＮ−１は単に、ＬＦＮ−１と同じ組織に属するＤＳを識別し得ることが可能である。言い換えると、ＬＦＮ−１は単に、それ自体の組織内でＤＳを識別し得る。別の例では、ＬＦＮ−１は単に、ある地理的エリア内で（例えば、ＬＦＡ−１に位置する単一のビルで）ＤＳ識別を行い得ることが可能であり得る。このパラメータで示される、そのような制限および／または制約は単に、よりきめの細かい制限および／または制約がさらに考慮される必要があり得るという意味において、きめが粗いことに留意されたい。例えば、ＬＦＮ−１は、単一のビルでＤＳ識別を行い得ることが可能であるが、このビルでの所与のＤＳ−１について、それは、ＬＦＮ−１がそのビルでそのような特定のＤＳ−１を発見することが可能になるかどうかを定義する、さらなる発見ルールまたはポリシーを有し得る。
同様に、以下の３つのパラメータは、ＬＦＮ−１が潜在的ＲＤＣであり得るかどうかを説明する。
ＲＤＣ＿Ｃａｐａｂｉｌｉｔｙについて、このパラメータは、ＬＦＮ−１がＩｏＴ未加工データ収集能力を有するかどうかを伝えるものである。
ＲＤＣ＿Ｗｏｒｋ＿Ａｖａｉｌａｂｉｌｉｔｙ＿Ｓｃｈｅｄｕｌｅについて、このパラメータは、ＬＦＮ−１についてのＲＤＣ能力の作業スケジュールを示す。例えば、ＬＦＮ−１は、午前１０時〜午後２時の間に、その未加工データ収集能力に寄与したいと思わない場合がある。これは、ＬＦＮ−１が、通常、このときくらいに、それ自体の組織からの重いワークロードを有する（それは、第１の優先度を有する）ためである。
ＲＤＣ＿Ｃａｐａｂｉｌｉｔｙ＿Ｓｃｏｐｅについて、このパラメータは、ＲＤＣ能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、ＬＦＮ−１が単に、あるノード上でまたはある場所で、未加工データを収集し得ることを示し得る。ＬＦＮ−１は単に、それ自体の組織内でＤＳから未加工データを収集し得ることが可能である。別の例として、ＬＦＮ−１は単に、ある地理的エリアで（例えば、ＬＦＡ−１に位置する単一のビルで）展開されるＤＳから未加工データを収集し得ることもまた可能である。
同様に、以下の３つのパラメータは、ＬＦＮ−１が潜在的ＲＤＰであり得るかどうかを説明する。
ＲＤＰ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔについて、このパラメータは、それをＲＤＰとして有効にし得るＬＦＮ−１のすべての能力をリストするものである。例えば、ＬＦＮ−１は、（ＡＶＥＲＡＧＥ、ＭＡＸ、ＭＩＮ動作を行うことなどの）単純なデータアグリゲーション能力をサポートし得る。故に、単純なデータアグリゲーション能力は、このパラメータに含まれ得る。ＬＦＮ−１がまた、（分類、回帰、または他のマシン学習ベースのアプローチなどの）高度なデータ処理能力を有する場合、この能力はまた、このパラメータに含まれ得る。
ＲＤＰ＿Ｗｏｒｋ＿Ｓｃｈｅｄｕｌｅ＿Ａｖａｉｌａｂｉｌｉｔｙ＿Ｌｉｓｔについて、「ＲＤＰ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔ」でリストされるような能力の各々について、１つ以上の対応する作業スケジュールはまた、このパラメータに含まれ得る。
ＲＤＰ＿Ｃａｐａｂｉｌｉｔｙ＿Ｓｃｏｐｅについて、このパラメータは、「ＲＤＰ＿Ｃａｐａｂｉｌｉｔｙ＿Ｌｉｓｔ」でリストされるようなＲＤＰ能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、処理のためにデータをＬＦＮ−１に送信または入力するときに特定のデータフォーマットが使用されるべきであることを示し得る。故に、入力データ（例えば、ＤＳから収集される未加工データ）が、このパラメータに示されるような要求されたデータフォーマットに対して互換性がない場合、（例えば、ＬＦＮ−２によって機能される）別のＲＤＰは、ＬＦＮ−１の前に必要とされ得、それは、最初に、オリジナル入力データを、ＬＦＮ−１によって要求されるような所望のデータフォーマットに変え得る。
追加でまたは代替で、各ＬＦＮは、その地理的場所、それが入っている組織などのそれ自体についての、いくつかの他の状況情報を登録し得る。
ステップ３で、ＤＳＣＳエージェント１は、将来の使用のためのＬＦＮ−１の能力を記録する。能力登録の表は、表９に示されるすべての情報の記録のためにＤＳＣＳエージェント１で利用可能であり得る。
Figure 2021536606
ステップ４で、ＤＳＣＳエージェント１は、成功の登録を通知する。言い換えると、ＤＳＣＳエージェント１は、ここで、どのＬＦＮがＤＳＤ、ＲＤＣ、およびＲＤＰとして機能し得るかの観点でリソースのプールを有する。故に、将来のＤＳＣＲを受信するとき、ＤＳＣＳエージェント１は、それらのＤＳＣＲを供給するためにプール内のそれらのリソースを使用し得る。
ＬＦＮは、表９に示される能力登録の表についての更新にもつながり得るその能力を動的に更新（例えば、新しい能力の追加、既存の能力についての作業スケジュールの更新、能力の削除など）し得ることが可能である。更新プロシージャは、図１９に示されるプロシージャと同様であり得る。
例示的な協働的なＤＳ識別プロシージャでは、ＬＦＮＬがＤＳＣＲを受信するとき（例えば、ユーザは、ＤＳＣＲをＣＮに呈し、ＣＮはさらに、このＤＳＣＲを関連ＬＦＮＬに割り当てた）、ＬＦＮＬは、このＬＦＮＬによって管理される複数のＬＦＮによって、提供および／または登録されるＤＳ識別能力を利用することによって、協働的なＤＳ識別プロセスを開始し始め得る。一般に、特定の協働的なＤＳ識別プロセスは、より詳細に以下に論じられるように、２つの段階を含む。
段階１は、ＲＤＣ発見を伴うＤＳ識別を含み得る。段階１で、主要なタスクは、特定の受信されたＤＳＣＲを供給し得る、すべての所望のＤＳを識別することである。所望のＤＳは、この特定のＤＳＣＲの対応するＲＤＳで、未加工データを特定のＤＥに提供するエンティティであり得る。そうするために、ＬＦＮＬは最初に、ＬＦＮ能力登録の表で説明されるような情報に基づいて、ＤＳＤとして機能し得るＬＦＮのリストを選択する必要があり得る。次いで、ＬＦＮＬは、ＤＳ識別動作を協働的に行うように、それらの選択されたＤＳＤを指定する。多くの場合、ＬＦＮ−１は、ＤＳＤとして機能し、受信されたＤＳＣＲについて所望のＤＳを識別し得る。しかしながら、実際のＲＤＳ生成プロセスが後で開始され得るため、ＬＦＮ−１は、そのときくらいにはもはや利用可能でない場合があり、したがって、別のＬＦＮ−２が、後の未加工データ収集のためにＲＤＣとして機能することが必要とされ得る。別の可能性は、ＬＦＮ−１が、その作業専門がＤＳ識別だけであるという意味において、洗練されたＤＳ識別能力を備える専門ノードであることである。言い換えると、ＬＦＮ物理的ノード実装を促進するために、異なるＬＦＮがそれらそれぞれの作業専門を有し得ることが可能である。故に、ＤＳＤ（例えば、ＬＦＮ−１）が所望のＤＳを識別するとき、それはまた、誰がこのＤＳから未加工データを読み出すことが可能であるかに関する関連情報を収集する必要があり得、そのような情報は、後の段階でこのＤＳについて適切なＲＤＣを見出すのに必要とされ得る。ｏｎｅＭ２Ｍを例に取ると、＜ｃｏｎｔａｉｎｅｒ−１＞リソースは、（所望のＤＳとしての）温度センサのすべての読み取り値を記憶する（ＤＳＤとしての）ＣＳＥによって発見されている。ＣＳＥは、この＜ｃｏｎｔａｉｎｅｒ−１＞リソースに関連するアクセス制御ポリシー（Access Control Policy：ＡＣＰ）をチェックし得る。例えば、＜ｃｏｎｔａｉｎｅｒ−１＞リソースが＜ＡＣＰ−１＞リソースで説明されるアクセス制御ポリシーを使用している場合、ＣＳＥは、どのエンティティが＜ｃｏｎｔａｉｎｅｒ−１＞リソースについて「読み出し」特権を有するかを識別するために、＜ＡＣＰ−１＞リソースをさらにチェックし得る。ＬＦＮ−１は、そのＤＳ識別結果およびＲＤＣ候補をＬＦＮＬに送信し返し得る。
一例では、データサンプル収集サービスは、データサンプルに対応付けられる１つ以上のデータ要素を識別するデータサンプル収集要求を受信することと、データ要素のうちの少なくとも１つについて、少なくとも１つのデータ要素についての１つ以上のデータソースを識別するように構成された１つ以上のデータソースディスカバラーを判定することと、１つ以上のデータソースディスカバラーに、データ要素のうちの少なくとも１つについての１つ以上のデータソースを識別するための要求を送信することと、１つ以上のデータソースディスカバラーから、データ要素のうちの少なくとも１つについての１つ以上のデータソースを識別するデータソース識別結果を受信することと、データソース識別結果に基づいて、データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも１つを実行するように構成されたローカルフォグノードを選択することと、選択されたローカルフォグノードに、データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも１つを実行するためのインジケーションを送信することと、を含む、動作を実行するように構成され得る。
データサンプル収集要求は、データサンプルに対応付けられる情報を含み得、情報は、どのくらいの頻度でデータサンプルが生成されるべきか、データサンプル収集要求がいつ実装されるべきかについてのスケジュール、データサンプルがどこで送信されるべきかについての識別子、およびデータサンプルに対応付けられる状況情報のうちの１つ以上を含む。１つ以上のデータ要素のうちのデータ要素は、データ要素の識別子、データ要素についての収集される未加工データのタイプ、データ要素についての未加工データに対応付けられるユニット、およびデータ要素についてのデータ処理動作のうちの少なくとも１つを含み得る。１つ以上のデータソースを識別するための要求は、識別するためのデータソースのタイプ、およびデータソース識別を実行するための作業範囲のうちの少なくとも１つを含み得る。データソース識別結果は、データソースのデータレート、データソースのデータユニット、データソースの地理的場所、データソースの利用可能スケジュール、およびデータソースにアクセスするように構成された１つ以上のローカルフォグノードのうちの少なくとも１つを含み得る。データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも１つを実行するためのインジケーションは、タスク説明およびタスク識別子のうちの少なくとも１つを含み得る。データサンプル収集サービスは、ローカルフォグノード、ローカルフォグノードリーダー、フォグノード、またはクラウドノードのうちの１つで実装され得る。動作は、複数のデータソースディスカバラーから受信される１つ以上のデータソース識別結果を統合することと、統合されたデータソース識別結果に基づいて、データを収集する１つ以上のデータソースのリストを判定することと、をさらに含み得る。
ＲＤＳ発見を伴うＤＳ識別のための例示的プロシージャは、図２０に示され、以下にさらに論じられる。
ステップ１で、ＬＦＡ−１内のＬＦＮＬ−１上のＤＳＣＳエージェント１は、ＤＳＣＲ−１を受信する。ユーザは、ＬＦＡ−１に存在する場合、ＬＦＮＬ−１上のＤＳＣＳエージェント１にＤＳＣＲ−１を直接呈し得るか、またはクラウドにある場合、ＣＮでの別のＤＳＣＳエージェントにＤＳＣＲ−１を呈し得、次いで、それは、処理のためにＬＦＮＬ−１上のＤＳＣＳエージェント１にＤＳＣＲ−１を転送する。一般に、ＤＳＣＲ−１は、ユーザが受信することを意図するＲＤＳの種類についてのすべての詳細を記載する。以下に示されるように、ＤＳＣＲは、以下の情報を含み得る。
パラメータの第１のパートは、特定のＤＳＣＲ−１のＲＤＳについての全体の情報および要件についてである。
Ｄａｔａ＿Ｓａｍｐｌｅ＿Ｆｒｅｑｕｅｎｃｙについて、「Ｄａｔａ＿Ｓａｍｐｌｅ＿Ｆｒｅｑｕｅｎｃｙ」は、どのくらいの頻度でＲＤＳが生成されるべきかを示す。例えば、ユーザは、１分毎にＲＤＳを必要とし得る。スマートシティ分析ユースケースで使用される別の例では、２つのＤＥが、平均温度および湿度を３分毎にそれぞれ計算するため、ＲＤＳは、３分毎に作成されるべきである。
ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅについて、これは、任意選択的なパラメータである。「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」は、このＤＳＣＲ−１についてのＲＤＳ生成がいつ行われるべきかを示す。言い換えると、ＤＳＣＲ−１のＲＤＳ生成プロセスは、ＬＦＮＬ−１がＤＳＣＲ−１を処理した直後に開始される必要はない。実際、これは、ＤＳＣＲ−１のＲＤＳ生成をどのように制御するかに関するアプローチのうちの１つである。例えば、このパラメータは、ＲＤＳ生成が単に毎日午前８時〜午前１０時および午後５時〜午後８時の間で行われるべきであることを示し得る。代替として、ＲＤＳ生成を制御するための別のアプローチは、あるトリガに基づき得る（例えば、ＲＤＳ生成プロセスは、特定のトリガ要求に基づいてか、またはあるイベントに基づいて始動され得る）。
ＲＤＳ＿Ｃｏｎｔｅｘｔｓについて、このパラメータは、このＤＳＣＲのすべての単一のＲＤＳについて、含まれるすべてのＤＥに加え、他の何の状況情報がまた、ＲＤＳに含まれるべきかを示す。例えば、このＲＤＳがどのＤＳＣＲに準拠するか、およびどの時間間隔でこのＲＤＳが生成されるかを他のものが知り得るように、タイムスタンプおよびＤＳＣＲ＿ＩＤ情報をＲＤＳに組み込むことが必要であり得る。一般に、任意の有用な状況情報が、後の使用のために必要とされる場合に、ＲＤＳで搬送されるべきである。したがって、所与のＲＤＳ−１は、以下の形態を有し得る。ＲＤＳ−１＝（ＤＥ−１、ＤＥ−２、…、ＤＥ−Ｎ、ＲＤＳ−ｃｏｎｔｅｘｔ−１、ＲＤＳ−Ｃｏｎｔｅｘｔ−２、…）。
ＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔについて、この属性は、このＤＳＣＲ−１のＲＤＳが送信され得るアドレスのリストを示す。例えば、以下の２つのケースが存在し得る。
ＤＳＣＲ−１のＲＤＳは、ＤＳＣＲ−１がユーザから直接送信された場合にユーザに送信され得ることが可能である。これは、ＤＳＣＲ−１が処理の間に分割されないという意味において、最も単純なケースである。
より高度なシナリオでは、ＤＳＣＲ−１は、ＤＳＣＲ−１について収集されるデータが異なるＬＦＡから生じ得るという事実に起因して、複数のＬＦＡと相互作用し得るため、処理の間に分割され得る。以下の例を考慮する。ＤＳＣＲ−１は、親ＤＳＣＲを２つのＤＳＣＲ（例えば、ＤＳＣＲ−１ａおよびＤＳＣＲ−１ｂ）に分割することによって作成された。言い換えると、ユーザは、当初、２つのＬＦＡ（例えば、ＬＦＡ−１およびＬＦＡ−２）をカバーする大きい地理的エリアを含む親ＤＳＣＲ−１を呈した。故に、この親ＤＳＣＲ−１は、適切に処理された状態になるために分割された状態になった。例えば、ＤＳＣＲ−１ａは、サブＤＳＣＲのうちの１つであり、それは、ＤＳＣＲ−１ａのタスクがＬＦＡ−１内でＤＳ識別およびＲＤＳ生成を処理することであるため、ＬＦＡ−１内のＬＦＮＬ−１に送信された。同様に、ＤＳＣＲ−１ｂは、別のＬＦＡ−２に関連する、ＤＳ識別およびＲＤＳ生成を処理し得る。その結果、ＤＳＣＲ−１ａのＲＤＳ（親ＤＳＣＲ−１観点から、ＤＳＣＲ−１ａのＲＤＳは単に、親ＤＳＣＲ−１についての部分的なＲＤＳであり得る）およびＤＳＣＲ−１ｂは、さらに、親ＤＳＣＲ−１についてのＲＤＳを生成するために、ＲＤＰによって、一緒に組み合わされおよび／またはアセンブルされる必要があり得る。ＤＳＣＲ−１のＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔは、ＤＳＣＲ−１のユーザによって提供されるＲＤＳ受信アドレスであり得る。ＤＳＣＲ−１ａおよびＤＳＣＲ−１ｂのＲＤＳ＿Ｓｅｎｄｉｎｇ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔは、親ＤＳＣＲ−１についてのＲＤＳアセンブリングのためのＲＤＰであり得る。
ＤＳＣＲ−１の各ＲＤＳは、ＤＥのリストを有し得る。ＲＤＳでのＤＥの各々は、このＤＥについてのすべての詳細を定義する以下の項目を有し得る。
ＤＥ＿ＩＤについて、「ＤＥ＿ＩＤ」は、このＤＳＣＲ−１でのＤＥの識別子である。スマートシティ分析ユースケースで使用される例として、ＤＳＣＲの各ＲＤＳで２つのＤＥが存在し、ＤＥ−１およびＤＥ−２がそれぞれ、それらのＤＥ＿ＩＤである。
Ｒａｗ＿Ｄａｔａ＿Ｔｙｐｅについて、これは、どのタイプの未加工データが、このＤＥのために収集されるべきかを示すものである。スマートシティ分析ユースケースで使用される例として、ＤＥ−１の未加工データタイプは、温度であり得る。
Ｕｎｉｔについて、これは、このＤＥのユニットがあるべき姿を示すものである。スマートシティ分析ユースケースで使用される例によれば、ＤＥ−１の未加工データタイプは、温度である。特に、ＤＥ−１の未加工データは、摂氏または華氏のいずれかであり得るが、ＲＤＳでは、ＤＥ−１パートは、摂氏であるべき（それは、ＤＥ−１のユニットである）ことが要求され得る。
Ｄａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎについて、これは、ＲＤＳでの所与のＤＥについて、どのタイプのデータ処理動作が、このＤＥについて収集される未加工データ上で行われるべきかを示すものである。共通動作は、平均、最大、最小などを含むが、それらに限定されない。スマートシティ分析ユースケースで使用される例として、ＤＥ−１のデータ処理タイプは、「平均アグリゲーション動作の実行」であるべきである。ユーザはまた、カスタマイズされたデータ処理動作を使用し得る。この場合、このパラメータは、「カスタマイズされた」値を有し得る。
Ｃｕｓｔｏｍｉｚｅｄ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｄｅｔａｉｌｓについて、「Ｄａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎ」が、「カスタマイズされた」値を有する場合、このパラメータは、そのようなカスタマイズされたデータ処理動作をどのように行うかを示し得る。例えば、それは、以下の動作を有し得る。
ユーザは、マシン学習プロセスを介して取得される、数学の式またはモデルを解き、このモデルは、このＤＥについて収集される未加工データを処理するために使用され得る。この場合、式は、このパラメータに直接組み込まれ得る。
ユーザは、それ自体のデータ処理コードスニペットを有し、それは、このＤＥについて収集される未加工データを処理するために、ＬＦＡ内のＲＤＰによって実行され得る。この場合、このパラメータは、データ処理コードスニペットの（ＵＲＩなどの）記憶場所を示し得る。
Ｑｕａｌｉｔｙ＿Ｒｅｑｕｉｒｅｍｅｎｔｓについて、これは、このＤＥについての任意の品質要件を示すものである。スマートシティ分析ユースケースで使用される例として、単一のＲＤＳでのＤＥ−１について、温度読み取り値が、精度を保証するために、ＬＦＡ−Ｘで展開される、少なくとも１００個の異なる温度センサから収集される必要があることが要求される。
ステップ２で、ＤＳＣＳエージェント１は、（表９に示されるような）ＬＦＮ能力の表をチェックし、ＤＳＣＲ−１についてのＤＳＤとして、適切なＬＦＮ（例えば、ＬＦＮ−１）を選択する。スマートシティ分析ユースケースで使用される例として、２つのＤＥ（例えば、ＤＥ−１およびＤＥ−２）はそれぞれ、平均温度および湿度を３分毎に計算し得る。故に、各ＤＥ−１およびＤＥ−２について、ＤＳＣＳエージェント１は、１つ以上のＤＳＤのリストを選択し得る。そうするために、ＤＳＣＳエージェント１は、その能力、作業スケジュール、および表９に示されるようなＤＳＤ範囲などの潜在的ＤＳＤ候補についての詳細な情報をチェックする必要があり得る。複数のＤＳＤは、ＬＦＡ−Ｘに展開される温度センサが、異なる組織に属し、選択されたＤＳＤの各々がまた、ある能力制限を有する（例えば、各ＤＳＤが、単に、同じ組織に属する特定のＤＳに対してＤＳ識別を行い得る）場合に、ＤＥ−１のために必要とされるＤＳを識別するために必要とされ得る。別の例として、ＬＦＡ−Ｘは、非常に大きい地理的エリアをカバーし得る。故に、複数のＤＳＤが必要とされ得、それらの各々が、ＬＦＡ−Ｘ内のより小さいエリアについてＤＳ識別を行い得る。一般に、所与のＤＥについてＤＳ識別を行うために複数のＤＳＤを必要とする多くの他のケースが存在し得、本明細書に開示される方法およびシステムは、それらのケースのすべてに適用され得る。
全体として、ＤＳＣＳエージェント１は、各ＤＥについてＤＳＤのリストを選択し、以下の情報を含み得る詳細なＤＳ識別プランで、選択されたＤＳＤの各々を割り当て得る。
何のタイプのＤＳが識別されるか。例えば、所与のＤＥについて、ステップ１で導入されるような「Ｒａｗ＿Ｄａｔａ＿Ｔｙｐｅ」は、識別されるＤＳのタイプを示す。所与のＤＳＤは、複数のＤＥについて潜在的ＤＳを識別するために使用され得ることが可能である。そのような場合、所与のＤＳＤは、複数のＤＳ識別プランを有し得、それらの各々は、所与のＤＥに対応する。
ＤＳ識別動作を行うための作業範囲が何か（例えば、どの組織内か、またはどの地理的エリア内かなど）。
ＤＳにおける任意の他の要件。スマートシティ分析ユースケースで使用される例によれば、ＤＥ−１は、３分毎に平均温度を計算するものである。故に、ＤＥ−１について、ＤＥ−１の潜在的ＤＳについての要件のうちの１つは、（ＤＳとしての）温度センサが、屋内温度センサではなく屋外温度センサであるべきであるということであり得る。
ステップ３で、各ＤＥについて、ＤＳＣＳエージェント１は、それらの選択されたＤＳＤの各々について作成される詳細なＤＳ識別プランとともに、そのＤＥについてＤＳ識別動作を行うために、選択されたＤＳＤの各々（例えば、ＬＦＮ−１上のＤＳＣＳエージェント２）に要求を送信する。言い換えると、各ＤＥについて、選択されたＤＳＤの各々についてのＤＳ識別プランは、このＤＥについてＤＳ識別タスクを協働的に達成するためにそれらが一緒に機能し得るように異なっている。選択されたＤＳＤが、複数のＤＥについてＤＳ識別タスクに関与する場合、ＤＳＣＳエージェント１は、異なるＤＥについてのすべてのＤＳ識別タスクが含まれる、この選択されたＤＳＤに単一の要求を送信し得る。
ステップ４で、選択されたＤＳＤの各々でのＤＳＣＳエージェントは、そのそれぞれのＤＳ識別プランに従ってＤＳ識別を行い得る。例えば、ＬＦＮ−１上のＤＳＣＳエージェント２は、ＤＳ−１が所望のＤＳかどうかを評価するために（例えば、ＤＳ−１が温度センサかどうか、およびそれが屋外に位置しているかどうかを評価するために）、ＤＳ−１上でＤＳ識別を行うことを担う。ＬＦＮ−１は、ＤＳ識別を行うためにＤＳ−１にアクセスする必要があり得る。ｏｎｅＭ２Ｍを例に取ると、（ＤＳＤとしての）セマンティック対応ＣＳＥ−１が、温度データソースを発見することを意図する場合、それは、ＣＳＥ−２上にホストされる（ＤＳ−１としての）＜ｃｏｎｔａｉｎｅｒ−１＞リソースを識別し、温度読み取り値を記憶するために、セマンティック発見機構を使用し得る。追加でまたは代替で、ＤＳ−１は、ＣＳＥ−１で登録され得（例えば、＜ｃｏｎｔａｉｎｅｒ−１＞リソースは、ＣＳＥ−１によってホストされ）、ＣＳＥ−１は、ＤＳＤとして機能し得る。そのような場合、ＣＳＥ−１は、ＤＳ識別についてＤＳ−１の登録情報を直接チェックし得、ＤＳ−１にトークする必要がない場合がある。ＤＳＤの各々でのＤＳＣＳエージェントはまた、各識別された／候補ＤＳについての有用な情報をさらに収集する必要があり得る。関連情報は、（ＤＳ−１を例に取る）以下の態様を含み得るが、それらに限定されない。
ＤＳ−１のデータレート、
ＤＳ−１のデータユニット、
ＤＳ−１の地理的場所、
ＤＳ−１から未加工データを読み出すためのアクセス権を有するＬＦＮ（すなわち、ＲＤＣ候補としてのもの）、および
ＤＳ−１の利用可能スケジュール。
ステップ５で、選択されたＤＳＤの各々でのＤＳＣＳエージェント（例えば、ＬＦＮ−１上のＤＳＣＳエージェント２）は、ステップ４で導入されるような識別されたＤＳについての関連情報とともに、そのＤＳ識別結果を送信し返す。
段階２は、ＤＳ識別結果統合およびＲＤＣ／ＲＤＰタスク割り当てを含み得る。段階２で、ＬＦＮＬの主要なタスクは、段階１の間にＤＳＤからのすべてのＤＳ識別結果を統合し、ＤＥの各々について所望のＤＳのリストを判定することである。言い換えると、未加工データは、それらの選択されたＤＳから収集され得る。選択されたＤＳの各々について、ＬＦＮＬは、段階１の間に識別されるようなこのＤＳについての関連情報に基づいて、適切なＲＤＣをそれに割り当てる必要があり得る。ＬＦＮＬはまた、選択されたＤＳの各々について適切なＲＤＰを割り当てる必要があり得、それらのＲＤＰは、それらの選択されたＤＳの未加工データの処理およびＲＤＳの生成を担い得る。ＤＳ識別結果統合およびＲＤＣ／ＲＤＰタスク割り当てのための例示的プロシージャは、図２１に示され、以下に論じられる。
ステップ１で、ＤＳＣＳエージェント１は、ＤＳＣＲ−１についての複数のＤＳＤからＤＳ識別結果を受信した（これは、図２０のステップ５の結果である）。例えば、ＤＳＣＲ−１のＲＤＳでの各ＤＥについて、異なるＤＳＤによって識別されている複数のＤＳが存在し得る。故に、ＤＳＣＳエージェント１は、ＤＥの各々について、すべての識別されたＤＳを評価し得る。すべての識別されたＤＳは、それらのすべてがＤＳＣＲ−１について所望のＤＳとして選択されるわけではない場合でさえ、ＤＳＣＳエージェント１によって記録され得ることに留意されたい。その理由は、そのようなＤＳ識別結果が、他の／将来のＤＳＣＲを供給するときに再使用され得ることである。故に、段階１についての追加の改善の１つは、特定のＤＳＣＲについてのＤＳＤとして適切なＬＦＮを選択する前に、図２０のステップ２の間に、ＤＳＣＳエージェント１が、最初に、ＤＳ識別結果履歴記録をチェックし得、前のＤＳＣＲについて識別される任意の既存のＤＳがこの新しいＤＳＣＲを供給するために再利用され得るかどうかを見ることである。このようにして、ＤＳ識別動作のオーバーヘッドが低減され得る。
ステップ２で、ＤＳＣＳエージェント１は、ＤＥの各々について所望のＤＳのリストを選択する。このステップは、未加工データがこのＤＥについてのすべての識別されたＤＳの間から収集されるのがどのＤＳかを選択するために実行され得る。
所与のＤＳについて、考慮され、含まれる関連情報は、ＤＳ識別プロセスの間に（例えば、図２０のステップ４で）取得され得る以下のことを含み得る。
ＤＳのデータレート、
ＤＳのデータユニット、
ＤＳの地理的場所、
ＤＳから未加工データを読み出すためのアクセス権を有するＬＦＮ、および
ＤＳの利用可能スケジュール。
スマートシティ分析ユースケースで使用される例として、（３分毎の平均温度である）ＤＥ−１について、（ＤＥ−１についてのＤＳ候補としての）２００個の温度センサがステージ１の間で複数のＤＳＤによって識別されており、それらの温度がＬＦＡ−Ｘによってカバーされる全体の地理的エリア上で分散されることが想定される。
ＤＥ自体についてのある情報もまた考慮される必要があり得、それは、図２０のステップ１（例えば、「Ｑｕａｌｉｔｙ＿Ｒｅｑｕｉｒｅｍｅｎｔｓ」パラメータで）で導入されるようにＤＳＣＲ−１で説明された。スマートシティ分析ユースケースで使用される例によれば、ＤＥ−１について、温度読み取り値が、精度を保証するために、ＬＦＡ−Ｘで展開される、少なくとも１００個の異なる温度センサから収集される必要があることが要求される。
所与のＤＥおよびその対応する識別されたＤＳの両方についての情報を考慮することによって、ＤＳＣＳエージェント１は、どのＤＳが、未加工データが収集される所望のＤＳかを決定し得る。スマートシティ分析ユースケースで使用される例によれば、（３分毎の平均温度である）ＤＥ−１について、１００個の温度センサが、（ＤＳ候補としての）ＬＦＡ−Ｘ内の全体で２００個の温度センサの間でＤＥ−１について所望のＤＳとして選択され得る。
ステップ３で、各所望のＤＳについて、ＤＳＣＳエージェント１は、それについてＲＤＣをさらに選択する。一般に、ＲＤＣは、選択されたＤＳの各々について必要とされ、そのようなＲＤＣは、ＤＳから未加工データを収集し、処理のために未加工データを対応するＲＤＰに送信するものである。提案されたソリューションをより一般的にするために、ＲＤＣおよびＲＤＰは単に論理的役割であり、したがって、ＬＦＮが、所与のＤＳについてのＲＤＣおよびこのＤＳについてのＲＤＰであり得ることもまた可能であることは、着目に値する。ＲＤＣが、所望のＤＳの各々について選択され得るが、所与のＬＦＮが、複数のＤＳについてＲＤＣとして機能し得る。言い換えると、所与のＬＦＮは、複数のＤＳからデータを収集することを担い得る。例証を容易にするための以下の説明では、所与のＤＳについて、そのＲＤＣおよびＲＤＰが異なるＬＦＮによって行われ得ることが想定される。
各所望のＤＳについてＲＤＣをさらに選択するために、以下の情報が評価される必要があり得る。
ＤＳＣＳエージェント１は、どのＬＦＮが（段階１の間に取得され得る）このＤＳからの未加工データを読み出すためのアクセス権を有するかに関するＤＳについての関連情報をチェックする必要があり得る。そのような情報は、きめが粗いかまたはきめが細かいものとして説明され得る。例として、所与のＤＳ−１は、ＤＳ−１と同じ組織に属する任意のＬＦＮがＤＳ−１からデータを読み出し得るような、きめの粗いアクセス制御情報を有し得る。別の例として、それは、ＤＳ−１から２００メートル以内にある任意のＬＦＮがＤＳ−１からデータを読み出し得るような、別のきめの粗いアクセス制御情報を有し得る。きめの細かいアクセス制御情報について、例は、特定のＬＦＮ（例えば、ＬＦＮ−１およびＬＦＮ−２７）のみがＤＳ−１からデータを読み出し得ることであり得る。別の例は、（ＤＳとしての）特定の＜ｃｏｎｔａｉｎｅｒ＞リソースのＡＣＰルールがこのリソースに対する「読み出し」特権を有する（ＲＤＣ候補としての）特定のＣＳＥ／ＡＥのリストを示すｏｎｅＭ２Ｍの例であり得る。
ＤＳＣＳエージェント１は、どのＬＦＮがＲＤＣとして機能し得、機能することを望んでいるかを識別するために、ＬＦＮ能力の表をチェックする必要があり得る。所与のＬＦＮが、洗練されたＤＳ識別能力を有し得るが、それは寄与することを望まないことが可能である。そのような場合、それが、（ＬＦＮ能力登録プロセスで導入されるように）対応するＬＦＮＬにその能力を登録するとき、それがＲＤＣとして機能することを望むことを示さない場合がある。「Ｏｔｈｅｒ＿Ｃｏｎｔｅｘｔ＿Ｉｎｆｏｒｍａｔｉｏｎ」パラメータは、それが入っている組織およびその地理的場所などの特定のＬＦＮの一般的な状況を説明する。
特定のＤＳについてのアクセス制御情報は、このＤＥについてＲＤＣとして適切なＬＦＮを選択するために、特定のＬＦＮに関連するアクセス特権情報と比較され得る。前の例を続けて、所与のＬＦＮ−１について、それが、ＤＳ−１と同じ組織に入っている場合、ＤＳ−１のアクセス制御ルールが、ＤＳ−１と同じ組織に属する任意のＬＦＮがＤＳ−１からデータを読み出し得ることを定義する（例えば、ＤＳ−１のアクセス制御ポリシーがＬＦＮ−１のアクセス特権と一致する）とき、ＬＦＮ−１は、ＤＳ−１についてＲＤＣとして選択され得る。信頼性を向上させるために、１つのＲＤＣがこのＤＳについてマスターＲＤＣとして指定され得、一方、他のものが副次的／バックアップＲＤＣであるように、複数のＲＤＣが所与のＤＳについて選択され得ることに留意されたい。その結果、マスターＲＤＣは、このＤＳから未加工データを収集するための主なまたは「マスター」ＲＤＣであるが、それは、マスターＲＤＣが未加工データ収集を行うことができない場合、副次的ＲＤＣによって置き換えられ得る。
ステップ４で、ＤＳＣＳエージェント１は、各ＤＥについてＲＤＰタスク割り当てプランを作成する。所与のＤＥ−１についての例示的ワークフローは、以下のようであり得る。
ＤＥ−１について、ＤＳＣＳエージェント１は、最初に、どのくらい多くのデータ処理段階が、ＤＥ−１のＤＳからＲＤＳでのＤＥ−１の最終の形態に収集される未加工データの間で必要とされるかを見出す。スマートシティ分析ユースケースで使用される例によれば、ＤＥ−１は、３分毎の平均温度である。言い換えると、単一のＲＤＳで、ＤＥ−１の最終の形態は、「所与の３分の時間間隔の間のＬＦＡ−Ｘについての平均温度」であり、一方、ＤＥ−１についての未加工データは、その３分の時間間隔の間に複数の温度センサから収集される温度読み取り値である。故に、この例は、２つのデータ処理段階を有し得る。
データ処理段階１について、１つのピースの温度読み取り値について、第１の処理は、温度センサから収集されるオリジナル未加工データから、データ読み取り値および（タイムスタンプなどの）他の有用な状況情報を抽出することである。他の事前処理がさらに必要とされ得る。例えば、ＤＥ−１の最終の形態が、データが摂氏であるように要求する場合、未加工データが華氏であるとき、単位変換が必要とされる。故に、ＲＤＰは、この段階で決定され得、それは、ＲＤＣによって収集される未加工データを受信するための第１のレベルＲＤＰノードのようである。
データ処理段階２について、ＤＥ−１のすべての所望のＤＳから収集される未加工データは、３分毎に平均温度を計算するために一緒に処理される必要があり得、それは、ＲＤＳの各々でのＤＥ−１の最終の形態である。故に、ＲＤＰはまた、この段階で決定され得、それは、データ処理段階１でＲＤＰによって出力される処理されたデータを受信するための第２のレベルＲＤＰノードである。より特定のデータ処理動作を使用してデータがさらに処理される必要がある場合、この段階の後にさらなる段階が存在し得ることに留意されたい。
次のステップは、上記の定義された段階の各々について適切なＬＦＮを選択することである。例えば、段階１について、あるカスタマイズされたデータ処理コードスニペットは、未加工データから有用なデータピースを抽出するために必要とされ得る。故に、ＲＤＰ候補としてのＬＦＮは、カスタマイズされたコードまたはソフトウェアが実行され得るそれらのＬＦＮである。別の例では、単純なデータアグリゲーション能力を有するＬＦＮは、段階２についてＲＤＰとして必要とされ得る。ＤＳＣＳエージェント１は、どのＬＦＮが上記の段階の各々についてＲＤＰとして機能し得るかを識別するために、ＬＦＮ能力の表をさらにチェックし得る。収集および／または処理される未加工データが大量にあり得るため、複数のＬＦＮは、特定のデータ処理段階の各々についてＲＤＰとして必要とされ選択され得る。スマートシティ分析ユースケースで使用される例によれば、（３分毎の平均温度である）ＤＥ−１について、１００個の温度読み取り値が、１００個の所望のＤＳ（例えば、温度センサ）から収集され得る。２つのＬＦＮが段階１について２つのＲＤＰとして選択されることが可能である。各ＲＤＰは、段階１の間に半分のＤＳ（例えば、５０個の温度センサ）から未加工データを処理することを担い得る。所与の段階について複数のＲＤＰが存在するとき、１つのＲＤＰがこの段階についてマスターＲＤＰとして指定され得、一方、他のものが副次的／バックアップＲＤＰである。その結果、マスターＲＤＰは、この段階の間のデータ処理のための主要なＲＤＰであるが、それは、マスターＲＤＰが要求されたデータ処理動作を行うことができない場合、副次的ＲＤＰによって置き換えられ得る。マスターＲＤＰが過負荷状態である場合、それはまた、そのワークロードをそれらの副次的ＲＤＰにオフロードし得る。段階２について、それは、（段階１の後の処理された１００個の温度読み取り値である）１００個の温度読み取り値の平均値を計算することであるため、平均動作は、単一のＬＦＮで実行される必要があり得る。故に、強力なＬＦＮが、段階２についてＲＤＰとして選択され得る。
最後のステップは、完全なデータ処理フロープランを構築するために、異なるデータ処理段階で、選択されたＲＤＰを一緒に接続するかまたはリンクさせることである。複数のＲＤＰが第１の段階（例えば、スマートシティ分析ユースケースでの段階１）について選択されるとき、ＤＳＣＳエージェント１は、ＤＳの各々を第１の段階で特定のＲＤＰに割り当てる必要があり得る。言い換えると、所与のＤＳからの未加工データは、第１の段階での処理のために、その割り当てられたＲＤＰに送信されるべきである。１つのＲＤＰだけが第１の段階（例えば、段階１）について選択された場合、すべてのＤＳの未加工データは、第１の段階でこの単一のＲＤＰに送信され得る。ＲＤＣが、所望のＤＳから未加工データを収集することを担うため、所与のＤＳについて、その対応するＲＤＣは、ＲＤＣが処理のために未加工データを送信する場所（例えば、どのＲＤＰか）を知り得るように、そのようなＲＤＰ割り当て決定で知らされる必要があり得る。
同様に、最後の段階（例えば、スマートシティ分析ユースケースでの段階２）でのＲＤＰについて、ＤＳＣＳエージェント１はまた、この段階の後に、処理されたデータがどこに送信されるべきかを決定する必要があり得る。スマートシティ分析ユースケースによれば、特定の３分の平均温度読み取り値が段階２の間に生成されるとき、それは、このデータがＤＥ−１のためだけであるため、依然として完全なＲＤＳではない。完全なＲＤＳは、２つのＤＥ（例えば、ＤＥ−１およびＤＥ−２）を含み得る。したがって、次のステップは、（ＲＤＳアセンブリングＲＤＰと呼ばれる別のＲＤＰによって行われ得る）ＤＥ−１およびＤＥ−２の最終形態のデータのアセンブリングによって完全なＲＤＳを生成することであり得る。２つの異なる／隣接する段階でのＲＤＰについて、ＤＳＣＳエージェント１はまた、段階ｉでのＲＤＰによって処理されたどのデータが、次の段階ｉ＋１でのどのＲＤＰに送信されるべきかを決定する必要があり得る。
最後に、ＤＳＣＳエージェント１は、ＬＦＮをＲＤＳアセンブリングＲＤＰとして選択し、それは、ＤＥの各々について最後のデータ処理段階でＲＤＰによって処理されたデータを受信し、ＲＤＳを構築するために異なるＤＥのデータを一緒にアセンブルする。スマートシティユースケースを例に取ると、ＤＥ−１について、その最後のデータ処理段階の出力／処理されたデータは、特定の３分の時間間隔での平均温度であり得る。そのようなデータは、ＤＥ−２についての他のデータ（例えば、同じ３分の時間間隔の平均湿度）とアセンブルされ得る。２つのピースのデータは、この例でのＲＤＳ定義に従って、各ＲＤＳが（ＤＥ−１、ＤＥ−２、タイムスタンプ）のフォーマットを有するため、完全なＲＤＳとして一緒にアセンブルされ得る。
ステップ５で、（ステップ３で判定されるような）所与の／所望のＤＳについての（ＲＤＣとしての）選択されたＬＦＮの各々について、ＤＳＣＳエージェント１は、データ収集タスクを割り当てるためにそれらのＬＦＮにコンタクトし得る。例えば、ＤＳＣＳエージェント１が、ＲＤＣタスク割り当て要求を特定のＬＦＮ−１に送信するとき、以下の情報は、特定のＤＳについて例示的未加工データ収集タスクを説明する（言い換えると、特定のＬＦＮに対するＲＤＣタスク割り当ては、複数のＤＳについてのデータ収集タスクのリストを含み得る）。
タスクＩＤ。これは、このタスクについての特定のタスクＩＤである。ＲＤＣが第１のデータ処理段階で未加工データをＲＤＰに送信するとき、それは、この未加工データが関連するタスクがどれかを示す必要があり得、（このタスクがどのＤＳＣＲおよびどのＤＥに関連するかをさらに示し得る）。
ＤＳのＩＤ（例えば、ＵＲＬ）について、
データ収集スケジュール（例えば、このＤＳからデータをいつ収集するか）。このスケジュールは、ＤＳＣＲ−１についてのＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅパラメータで整合され得る。
ＲＤＰのＩＤ。これは、ＤＳの未加工データがどこに送信されるべきかを示す。言い換えると、ＲＤＣは、ＤＳから未加工データを収集し、未加工データをこのパラメータに示されるようなＲＤＰに送信し得る。
いくつかのＬＦＮは、ＤＳＣＳエージェント１によって要求されるようなタスク割り当てを受け入れることができなくてもよいことが可能である。故に、このステップの間に複数のネゴシエーションプロセスが存在し得る。
ステップ６で、ＤＳＣＳエージェント１は、ＤＳＣＲ−１に関連する特定のＤＥについてＲＤＣとしてＬＦＮ−１を選択し、ＬＦＮ−１上のＤＳＣＳエージェント２は、ＲＤＣ割り当てを通知する。
ステップ７で、（ステップ４で判定されるような）（ＲＤＰとしての）選択されたＬＦＮの各々について、ＤＳＣＳエージェント１は、データ処理タスクを割り当てるためにそれらのＬＦＮにコンタクトし得る。例えば、ＤＳＣＳエージェント１は、ＲＤＰタスク割り当て要求を特定のＬＦＮ−２に送信し得、それはまた、ＬＦＮ−２に割り当てられる複数のタスクを含み得る。例えば、所与のＬＦＮは、特定のＤＥについて、異なるデータ処理段階でＲＤＰとして機能し得る。より一般的には、所与のＬＦＮは、異なるＤＥについてのデータ処理のためのＲＤＰとして機能し得る。例えば、ＬＦＮ−２は、ＤＥ−１についてのＲＤＰとして機能し得、その間に、ＬＦＮ−２は、ＤＥ−１のデータ処理段階１についての要求されたデータ処理を行う。ＬＦＮ−２はまた、ＤＥ−２についてのＲＤＰとして機能し得、その間に、ＬＦＮ−２は、ＤＥ−２のデータ処理段階２についての要求されたデータ処理を行う。それらの関与するタスクの各々についてＬＦＮ（例えば、ＬＦＮ−２）が行う必要があることを説明するために、以下の情報が含まれ得る。
タスクＩＤについて、これは、このタスクについての特定のタスクＩＤである。上流のデータ送信元が、処理されたデータを下流のデータレシーバに送信するとき、それは、この処理されたデータがどのタスクについてかを示す必要があり得る。
上流のデータ送信元のＩＤおよび関連タスクＩＤについて、これは、処理されたデータを処理のためにＬＦＮ−２に誰が送信するかを示すものである。上流の送信元から送信されるデータはまた、（上流のデータ送信元によって行われるタスクのＩＤである）別のタスクＩＤに対応付けられ得る。例えば、ＬＦＮ−２が、ＤＥ−１についての第１のデータ処理段階についてのＲＤＰである場合、ＤＥ−１のＲＤＣは、ＤＥ−１の所望のＤＳから未加工データを収集し、処理のためにそれらをＬＦＮ−２に送信する、上流のデータ送信元であり得る。別の例では、ＬＦＮ−２が、ＤＥ−１についての第２のデータ処理段階についての選択されたＲＤＰである場合、ＬＦＮ−２の上流のデータ送信元は、ＤＥ−１についての第１のデータ処理段階でのＲＤＰであり得、それは、第２の段階についての処理を行うために、それらの処理されたデータをＬＦＮ−２に送信する。ＲＤＣの役割はまた、ＲＤＰとして機能するＬＦＮによって行われ得ることは、着目に値する。例えば、ＬＦＮ−２は、特定のＤＥ−１について未加工データを収集するためのＲＤＣとして選択されることが可能である。ＬＦＮ−２はまた、データ処理能力を有し得、それはまた、ＤＥ−１についての第１のデータ処理段階についてのＲＤＰとして選択される。この場合、ＬＦＮ−２は、ＲＤＣおよびＲＤＰの両方としての組み合わされた役割を行っている。
Ｒｅｑｕｉｒｅｄ＿Ｄａｔａ＿Ｐｒｏｃｅｓｓｉｎｇ＿Ｏｐｅｒａｔｉｏｎについて、これは、何の特定のデータ処理動作が行われるかを示す。カスタマイズされたコードがダウンロードされる必要がある場合、このパラメータはまた、データ処理コードをダウンロードする場所を示す。
下流のデータレシーバのＩＤについて、これは、一旦ＬＦＮ−２がこの特定のタスクについて処理を完了すると、処理されたデータを送信する場所を示すものである。例えば、ＬＦＮ−２が、ＤＥ−１についての第１のデータ処理段階についての選択されたＲＤＰである場合、ＤＥ−１についての第２のデータ処理段階についてのＲＤＰは、ＬＦＮ−２によって処理されたデータに基づいて、さらなるデータ処理動作を行う下流のデータレシーバであり得る。ＬＦＮ−２が、その処理されたデータをその下流のデータレシーバに送信するとき、それはまた、処理されたデータをタスクＩＤに対応付ける必要があり得、それは、（例えば、タスクＩＤで定義されるような）ＬＦＮ−２自体によって行われるタスクのＩＤである。
いくつかのＬＦＮは、ＤＳＣＳエージェント１によって要求されるようなタスク割り当てを受け入れることができなくてもよいこともまた可能である。故に、このプロセスの間に複数のネゴシエーションステップが存在し得る。
加えて、所与のＬＦＮについて、それが、所与のＤＳＣＲを供給するためにＲＤＣおよびＲＤＰとして選択される場合、ＤＳＣＳエージェント１は、単に、ＲＤＣおよびＲＤＰタスク割り当てのために１つのメッセージをこのＬＦＮに送信し得る。そのような場合、ステップ５およびステップ７が組み合わされ得る。
ステップ８で、ＬＦＮ−２上のＤＳＣＳエージェント３は、ＲＤＰ割り当てを通知する。
最後に、ＤＳＣＳエージェント１は、ＤＳＣＲ−１についてのジョブ割り当てプロファイルを生成し得、それは、どのＬＦＮが、ＤＥの各々についてＲＤＣとして選択されるか、またはどのＬＦＮが、ＤＳＣＲ−１についてのＲＤＳを生成するために要求されるデータ処理動作についてのＲＤＰとして選択されるかについてのすべての詳細を含み得る。
協働的なＲＤＳ生成および配信のための方法およびシステムが本明細書に開示される。以下の例では、ＬＦＡでＲＤＳ生成プロセスを始動するためのプロセスが開示される。
所与のＤＳＣＲについて、ＤＳ識別およびＲＤＣ／ＲＤＰ割り当てが完了した後、このＤＳＣＲについてＲＤＳをすぐに生成し始めることが必要でない場合がある。言い換えると、ＲＤＳ生成は、後で（例えば、トリガに基づいて）、またはあるスケジュール（例えば、図２１のステップ１に含まれる「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータに示されるような情報）に基づいて、始動され得る。一般に、ＲＤＳ生成有効化は、ユーザによって開始され得る（例えば、ＲＤＳ生成トリガは、ＣＮからＬＦＡに送信され得る）。所与のＤＳＣＲについて、ＬＦＮＬは、このＤＳＣＲのＲＤＳの各ＤＥについて、どのＤＳが所望のまたは選択されたＤＳかを判定する必要があり得る。追加でまたは代替で、ＬＦＮＬは、所望のＤＳの各々について、どのＬＦＮが選択されたＲＤＣか、および／またはＤＥの各々について、どのＬＦＮがこのＤＥの所望のＤＳから収集されるデータを処理するための選択されたＲＤＰであるかを判定する必要があり得る（それらのタスク割り当てのすべてが、協働的なＤＳ識別プロセスの段階１および段階２の間で決定され得る）。次いで、ＬＦＮＬは、どの特定のタスクがここで実行される必要があるかについてのガイドラインとともに、関与するＬＦＮの各々にトリガを送信し得る。
一例では、データサンプル収集サービスは、特定のデータサンプル収集要求に対応付けられるデータサンプルの生成を開始するためのインジケーションを含むトリガを受信することと、未加工データ収集を実行するように構成された少なくとも１つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも１つのローカルフォグノードを判定することと、未加工データ収集を実行するように構成された少なくとも１つのローカルフォグノードに、未加工データ収集を開始するためのインジケーションを送信することと、未加工データ収集を実行するように構成された少なくとも１つのローカルフォグノードから、未加工データ収集が開始されたというインジケーションを受信することと、未加工データ処理を実行するように構成された少なくとも１つのローカルフォグノードに、未加工データ処理を開始するためのインジケーションを送信することと、未加工データ処理を実行するように構成された少なくとも１つのローカルフォグノードから、未加工データ処理が開始されたというインジケーションを受信することと、を含む、動作を実行するように構成され得る。
未加工データ収集を開始するためのインジケーションおよび未加工データ処理を開始するためのインジケーションの各々は、タスク識別子を含み得る。トリガは、クラウドノードから受信され得る。未加工データ収集を実行するように構成された少なくとも１つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも１つのローカルフォグノードを判定することは、データサンプル収集サービスで記憶されるジョブ割り当てプロファイルにアクセスすることを含む。未加工データ収集を実行するように構成された少なくとも１つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも１つのローカルフォグノードは、同じローカルフォグノードで実装され得る。データサンプル収集サービスは、ローカルフォグノードリーダーで実装され得る。
別の例では、ローカルフォグノードは、データサンプル収集サービスから、未加工データ収集および未加工データ処理動作のうちの少なくとも１つを実行するための要求を受信することであって、データサンプル収集サービスが、ローカルフォグノードリーダーで実装される、受信することと、未加工データ収集および未加工データ処理動作のうちの少なくとも１つを開始することと、データサンプル収集サービスに、未加工データ収集および未加工データ処理動作のうちの少なくとも１つが開始されたというインジケーションを送信することと、を含む、動作を実行するように構成され得る。
未加工データ収集および未加工データ処理動作のうちの少なくとも１つを実行するための要求は、タスク識別子を含み得る。未加工データ収集および未加工データ処理動作のうちの少なくとも１つを実行するための要求を受信することは、未加工データ収集を実行するための第１の要求を受信することであって、第１の要求が、第１のタスク識別子を含む、受信することと、未加工データ処理を実行するための第２の要求を受信することであって、第２の要求が、第２のタスク識別子を含む、受信することと、を含み得る。未加工データ収集および未加工データ処理動作のうちの少なくとも１つを実行するための要求は、データサンプル収集サービスで記憶されるジョブ割り当てプロファイルに基づき得る。データ処理動作は、データ収集動作の少なくとも部分的な完了に基づいて自動的に実行され得る。未加工データ収集および未加工データ処理動作のうちの少なくとも１つを実行するための要求は、データサンプル収集サービスで記憶されるスケジュールに基づき得る。
ＬＦＡでＲＤＳ生成をトリガするための例示的プロシージャは、図２２に示され、以下に論じられる。
ステップ１で、ＤＳＣＳエージェント１は、ＤＳＣＲ−１についてＲＤＳ生成を開始するためのトリガを受信する。例えば、ＤＳＣＲ−１を開始したユーザは、トリガ要求をＣＮに送信することによって、このＤＳＣＲ−１を直接有効にし得る。ＣＮは、このトリガ要求を、ＬＦＡ−１内のＬＦＮＬにさらに転送し得る。
ステップ２で、ＤＳＣＳエージェント１は、どのＬＦＮがＤＳＣＲ−１についてのＲＤＣ／ＲＤＰとして関与するかを見出す。特に、ＤＳＣＳエージェント１は、どのＬＦＮがＲＤＣ／ＲＤＰタスク割り当ての間にＲＤＣまたはＲＤＰとして選択されるかについてのすべての詳細を含む、（図２１に示されるプロシージャの終わりで作成されるような）ＤＳＣＲ−１のジョブ割り当てプロファイルをチェックし得る。
ステップ３で、ＤＳＣＳエージェント１は、所望のＤＳからのデータ収集を開始するために、（ＤＳＣＲ−１を供給するためにＲＤＣとして選択された）関与するＬＦＮにコンタクトする。ＤＳＣＲ−１の対応するＲＤＳのＤＥの各々について、ＤＳＣＳエージェント１は、各ＤＥについて、どのＤＳが所望のＤＳかをチェックし得る。追加でまたは代替で、ＤＳＣＳエージェント１は、ＤＳＣＲ−１のジョブ割り当てプロファイルに含まれるような情報に基づいて、どのＬＦＮがＤＳの各々についてＲＤＣとして割り当てられているかをチェックし得る。所与のＬＦＮは、複数のＤＳについてのＲＤＣであり得ることが可能であり得ることに留意されたい。したがって、ＤＳＣＳエージェント１が、すべての関与するタスクＩＤも含み得る、（ＲＤＣとしての）特定のＬＦＮに活性化トリガを送信するとき、このＬＦＮに割り当てられたＤＳＣＲ−１に関連するデータ収集タスクのすべてが開始され得る。
ステップ４で、ＲＤＣ（例えば、ＬＦＮ−１）は、データ収集が開始されることを通知する。所与のＬＦＮ（例えば、ＬＦＮ−１）について、ＲＤＣは、ステップ３に示されるようなタスクリストに従って、未加工データ収集アクティビティを開始し得る。
ステップ５で、ＤＳＣＳエージェント１は、（図２１に示されるプロシージャの終わりに作成されたジョブ割り当てプロファイルで説明されるような）ＲＤＣ／ＲＤＰタスク割り当ての間に構成されるようなデータ処理タスクを開始するために、（ＤＳＣＲ−１を供給するためにＲＤＰとして選択された）関与するＬＦＮにコンタクトする。ＤＳＣＳエージェント１は、ＤＳＣＲ−１のジョブ割り当てプロファイルに含まれるような情報に基づいて、どのＬＦＮがＤＳＣＲ−１のＤＥの各々についての割り当てられたＲＤＰであるかをチェックし得る。所与のＤＥについて、特定のＬＦＮは、このＤＥの複数のデータ処理段階の間にＲＤＰであり得ることが可能であることに留意されたい。特定のＬＦＮは、異なるＤＥについてのＲＤＰであり得る。したがって、ＤＳＣＳエージェント１が、すべての関与するタスクＩＤも含む、（ＲＤＰとしての）特定のＬＦＮに活性化トリガを送信するとき、このＬＦＮに割り当てられたＤＳＣＲ−１に関連するすべてのデータ処理タスクが、ここで開始され得る。
ステップ６で、ＲＤＰ（例えば、ＬＦＮ−２）は、ＤＳＣＲ−１を供給するためのデータ処理が開始した（例えば、それは、処理のためにＲＤＣからデータを受信する準備ができている）ことを通知する。所与のＬＦＮ（例えば、ＬＦＮ−２）について、ＲＤＰは、ステップ５に示されるようなタスクリストに従って、データ処理アクティビティを開始し得る。代替として、ステップ５およびステップ６は、ステップ３および／またはステップ４の前に実行され得る。
代替のソリューションとして、ステップ５および／またはステップ６は、トリガをＲＤＣに送信することのみが必要であるという意味において必要とされない場合があることに留意されたい。その理由は、ＲＤＣが、ＤＳからデータを収集するものであり、処理のためにデータを送信する場所を知り得ることである。故に、ＲＤＰは、初めてＲＤＣから送信されるデータを受信するときにトリガされ得る。例えば、ＲＤＣがデータの第１のバッチをＲＤＰに送信しているとき、ＲＤＣは、受信されたデータを処理するためにＲＤＰがその対応するタスクを開始し得るように、タスクＩＤを含み得る。
ＤＳＣＲ−１のＲＤＳ生成が、図２１のステップ１に含まれる「ＲＤＳ＿Ｐｒｏｄｕｃｔｉｏｎ＿Ｓｃｈｅｄｕｌｅ」パラメータに示されるような、あるスケジュールに基づく場合、ＤＳＣＲ−１を供給するためにＲＤＣまたはＲＤＰとして選択された、１つ以上の関与するＬＦＮは、ワークスケジュールに従うことによって自動的に機能し始め得る。
一旦、ＲＤＳ生成が所与のＤＳＣＲについて始動されると、関与するＲＤＣ／ＲＤＰが機能し始め得る。特定のＤＥについての実際のＲＤＳ生成のための例示的プロシージャは、図２３に示され、以下に論じられる。プロシージャは、スマートシティ分析ユースケースを例に取り、ここで、単一のＲＤＳでのＤＥ−１は、３分毎の平均温度である。特に、１００個の温度センサは、ＤＥ−１についての所望のＤＳとして、すでに識別されている。
ステップ１で、ＲＤＣタスク割り当てに従って、（ＲＤＣとしての）ＬＦＮ−２上のＤＳＣＳエージェント３は、ＤＳ−１からＤＳ−５０まで未加工データを収集することを担うことが想定される。ＤＳＣＳエージェント３は、生成されている新しいデータが存在するかどうかを見るために、ＤＳ−１およびＤＳ−５０に定期的にアクセスし得る。追加でまたは代替で、読み出し動作を行うことによって所望のＤＳから未加工データを収集する代わりに、ＲＤＣは、所望のＤＳにおいてサブスクリプションを行い得、その結果、それらのＤＳが通知を介してそれらの新しいデータをＲＤＣに送信し得る。
ステップ２で、ＲＤＣタスク割り当てに従って、（ＲＤＣとしての）ＬＦＮ−１上のＤＳＣＳエージェント２は、ＤＳ−５１からＤＳ−１００まで未加工データを収集することを担うことが想定される。
ステップ３で、ＤＳＣＳエージェント３は、（ＤＳ−１からＤＳ−５０まで収集される）未加工データをＬＦＮ−３に送信し、それは、ＤＥ−１の第１のデータ処理段階についてのＲＤＰとして機能している。特に、ＤＳＣＳエージェント３がデータの第１のバッチをＬＦＮ−３に送信しているとき、それは、受信されたデータをどのように処理するかをＬＦＮ−３が知るようにタスクＩＤを含み得る。
ステップ４で、ＬＦＮ−２上のＤＳＣＳエージェント３と同様に、ＤＳＣＳエージェント２は、（ＤＳ−５１からＤＳ−１００まで収集される）未加工データをＬＦＮ−３に送信し、それは、ＤＥ−１の第１のデータ処理段階についてのＲＤＰとして機能している。
ステップ５で、ＬＦＮ−３上のＤＳＣＳエージェント４は、ＤＥ−１の第１のデータ処理段階について未加工データを処理する。例えば、第１の段階の間の主要なデータ処理動作は、未加工温度読み取り値で構成される１つのピースについてである。ＲＤＰは、オリジナル未加工データから、データ読み取り値および（タイムスタンプなどの）他の有用な状況情報を抽出する。ＤＥ−１の最終の形態が、データが摂氏であるように要求する場合、未加工データが当初、華氏であるとき、単位変換が行われ得る。
ステップ６で、一旦、ＬＦＮ−３上のＤＳＣＳエージェント４が第１のデータ処理段階についてそのデータ処理を完了すると、処理されたデータをＬＦＮ−４に送信し得、それは、ＤＥ−１の第２のデータ処理段階についてのＲＤＰとして機能している。同様に、ＬＦＮ−３上のＤＳＣＳエージェント４がその処理されたデータをＬＦＮ−４に送信しているとき、それは、受信されたデータをどのように処理するかをＬＦＮ−４が知るようにタスクＩＤを含み得る。
ステップ７で、ＬＦＮ−４上のＤＳＣＳエージェント５は、第２のデータ処理段階についてデータを処理し、最終の形態であり得るＤＥ−１についてのデータを生成する。ＤＥ−１についてのデータは、特定の３分の時間間隔での平均温度値であり、それは、ＤＥ−１の最終の形態である。故に、ＬＦＮ−４の出力は、３分毎のＬＦＡ−１の平均温度値であり得、それは、第１のデータ処理段階での２つのＲＤＰから（例えば、ＬＦＮ−２およびＬＦＮ−３）から送信される、処理されたデータに基づいて計算される。その後、ＬＦＮ−４上のＤＳＣＳエージェント５は、処理されたデータをＤＳＣＲ−１の対応するＲＤＳアセンブリングＲＤＰに送信し得、それは、ＤＳＣＲ−１について最終のＲＤＳを生成する最後のＲＤＰである。（ＲＤＣまたはＲＤＰのいずれかとして機能する）ＬＦＮについて、それは、それぞれ、副次的ＲＤＣまたはＲＤＰであるいくつかのピアＬＦＮに対応付けられ得る。故に、当初選択されたＲＤＣまたはＲＤＰが、予期されるように所望のタスクを行うことができない（例えば、過負荷状態になるか、または機能を停止させる）場合、ワークロードは、対応する副次的ＲＤＣまたはＲＤＰにオフロードされ得る。
ＲＤＣ／ＲＤＰは単に、「論理」エンティティであり得る。特に、図２３に示される例では、異なる役割は、例証を容易にするために（それは、提案されたアイディアの一般性を限定すべきでない）、異なるＬＦＮによって行われ得る。ＬＦＮは、第１のデータ処理段階についてデータ処理を行うためにＲＤＣおよびＲＤＰの両方としてであり得ることが可能であるということが理解される。例えば、ＤＳＣＳエージェント３は、ＲＤＣおよび第１の段階ＲＤＰの両方として機能し得る。異なる例示的構成として、ここで、ＤＳＣＳエージェント３がすべての１００個のＤＳからデータを収集し得ることを想定すると、それは、それらの１００個のＤＳからデータを収集し、未加工データに対してＡＶＥＲＡＧＥ動作を直接行い、第２の段階ＲＤＰであるさらなる処理のために、処理されたデータをＤＳＣＳエージェント５に送信し得る。
一旦、データが所与のＤＥについて完全に処理されると、それは、その最終の形態であり得、アセンブルされる準備ができ得る。所与のＤＳＣＲについてのＲＤＳアセンブリングのための例示的プロシージャは、図２４に示され、以下にさらに論じられる。図２４のプロシージャは、スマートシティ分析ユースケースを例に取り、ここで、単一のＲＤＳでのＤＥ−１は、所与のＬＦＡ−１についての３分毎の平均温度であり、単一のＲＤＳでのＤＥ−２は、同じ所与のＬＦＡ−１についての３分毎の平均湿度である。故に、図２４でのステップ７の出力は、ＤＥ−１の最終の形態である。
（図２４のステップ７から続いて）ステップ１で、ＬＦＮ−４上のＤＳＣＳエージェント５は、第２のデータ処理段階についてデータを処理し、ＤＥ−１について最終形態のデータを生成した。ＤＳＣＳエージェント５は、アセンブリングのために、処理されたデータをＬＦＮ−６に送信する。特に、ＬＦＮ−４上のＤＳＣＳエージェント５からのＤＥ−１の出力データの各々は、後のＲＤＳアセンブリングの間に使用され得る、ある状況情報に対応付けられ得る。図２３でのステップ７の間に生成されるＤＥ−１の所与のピースのデータについて、対応付けられた情報は、計算された平均温度が特定の３分の時間間隔に対応することを示し得る。
ステップ２で、ＬＦＮ−５上のＤＳＣＳエージェント６は、ＤＥ−２について最終形態のデータを生成した、ＤＥ−２の最後のデータ処理段階でのＲＤＰであることが想定される。ここで、ＤＥ−２は、３分毎の平均湿度である。同様に、ＤＥ−２の最終形態のデータの各々はまた、後のＲＤＳアセンブリングの間に使用され得る、ある状況情報に対応付けられ得る。ＤＳＣＳエージェント６は、最終のＲＤＳアセンブリングのために、ＤＥ−２に関連する処理されたデータをＬＦＮ−６に送信し得る。
ステップ３で、ＬＦＮ−６上のＤＳＣＳエージェント７は、ＤＥ−１およびＤＥ−２の最終形態のデータをアセンブルし、ＤＳＣＲ−１についてＲＤＳを生成する。ＤＥ−１についての１つのピースのデータおよびＤＥ−２についての１つのピースのデータは、それらが同じ特定の３分の時間間隔に関連する場合、一緒にアセンブルされ得る。その結果、ＲＤＳは、ＤＳＣＲ−１で記載されるようなＲＤＳ定義に準拠する（ＤＥ−１、ＤＥ−２、ｃｏｎｔｅｘｔ＿ｉｎｆｏｒｍａｔｉｏｎ）のフォーマットで生成され得る。
ステップ４で、生成されたＲＤＳは、指定されたアドレスに配信される。典型的には、ＲＤＳ配信は、以下のオプションを有し得る。
オプション１について、ＲＤＳアセンブリングＲＤＰは、ＲＤＳデータサンプルをＤＳＣＲ−１のユーザに１つずつ送信し得る。
オプション２について、ＲＤＳアセンブリングＲＤＰは、バッチで（例えば、１００個のＲＤＳサンプル毎に）ＲＤＳを送信し得る。
オプション３について、ＲＤＳアセンブリングＲＤＰは、ＤＳＣＲ−１のユーザによって要求されるような特定のタイムポイントでＲＤＳデータサンプルを送信し得る。
さらに／または、オプション４について、ＲＤＳアセンブリングＲＤＰは、ＲＤＳをローカルに記憶し、ＤＳＣＲ−１のユーザがデータを引き戻すことを可能にし得る。
提案されたＤＳＣＳソリューションは、図１５に示されるように、ｏｎｅＭ２Ｍサービス層での新しいＣＳＦと見なされ得る。異なるタイプのＭ２Ｍノードは、ＩｏＴデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、（車両、携帯電話などの）モバイルノードなどのＤＳＣＳサービスを実装し得ることを理解されたい。特に、それらのノードのための種々の／異なるハードウェア／ソフトウェア能力に応じて、それらのノードによって実装されるＤＳＣＳサービスの能力もまた、異なり得る。
定義される関連エンティティについてのｏｎｅＭ２Ｍ実施形態は、以下のようである。
データソース（ＤＳ）は、ｏｎｅＭ２Ｍ ＡＥまたはＣＳＥであり得る。故に、ＡＥまたはＣＳＥによって生成される未加工データは、ＤＳ識別プロセスの間にｏｎｅＭ２Ｍリソース発見を介して識別され得る、＜ｃｏｎｔａｉｎｅｒ＞、＜ｔｉｍｅＳｅｒｉｅｓ＞、または＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞リソースで記憶され得る。
ローカルフォグノード（ＬＦＮ）は、ｏｎｅＭ２Ｍ ＣＳＥ（例えば、ＡＳＮ−ＣＳＥ）であり得る。
ＬＦＮリーダー（ＬＦＮＬ）およびフォグノード（ＦＮ）は、（ＭＮ−ＣＳＥなどの）ｏｎｅＭ２Ｍ ＣＳＥであり得る。
クラウドノード（ＣＮ）は、（ＩＮ−ＣＳＥなどの）ｏｎｅＭ２Ｍ ＣＳＥであり得る。
ＤＳＣＳユーザは、ｏｎｅＭ２Ｍ ＡＥ（例えば、ＩＮ−ＡＥ）またはＣＳＥであり得る。
＜ｄｓｃｓ＞と呼ばれる新しい仮想リソースが図１６に示される。ＣＳＥがＤＳＣＳ能力を有する（例えば、ＤＳＣＳエージェントがこのＣＳＥ上で実行している）場合、それは＜ｄｓｃｓ＞子リソースを有し得る。すべてのＤＳＣＳ関連要求は、このリソースに向けて行われ得る。例えば、ユーザは、ＤＳＣＲ作成要求を、ＣＳＥ−１上でホストされる＜ｄｓｃｓ＞リソースに送信し得る。同様に、ＣＳＥ−１が、ＤＳＣＲ−１についてＤＳ識別を行うことを意図するとき、それは、ＤＳＣＲ−１を、ＬＦＡ内の別のＣＳＥ−２によってホストされる＜ｄｓｃｓ＞リソースに送信し得、それは、ＬＦＮＬとして機能し、このＬＦＡ内のＬＦＮによって行われる、すべてのＤＳ識別およびＲＤＳ生成アクティビティを管理およびコーディネートする。（ＬＦＮとしての）ＣＳＥが、その能力を、ＬＦＮＬとして機能する別のＣＳＥに登録するとき、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、ＬＦＮＬ上で機能するＣＳＥ上で作成され得る。このリソースは、所与のＬＦＮが提供し得る能力（例えば、ＤＳＤ、ＲＤＣ、および／またはＲＤＰとして機能し得るかどうか）についてのすべての情報を説明し得る。加えて、ＬＦＮＬとＬＦＮとの間のすべての通信について（例えば、ＬＦＮＬが、ＲＤＣもしくはＲＤＰ関連タスクをＬＦＮに割り当てるか、またはＬＦＮＬが、割り当てられたＲＤＣもしくはＲＤＰ関連タスクを開始するために、トリガをＬＦＮに送信するとき）、要求オリジネータ（例えばＬＦＮＬとして機能するＣＳＥ）は、それらの要求をレシーバの＜ｄｓｃｓ＞リソース（例えば、ＬＦＮＬによって管理される、ＬＦＮとして機能するＣＳＥ）に向けて送信し得る。
ＤＳＣＳを曝すための代替の方法は、「ｄｓｃｓ＿ｃａｐａｂｉｌｉｔｙ」と呼ばれる新しい属性が、＜ＣＳＥ＞リソースについて定義されることであり、それは、このＣＳＥがＤＳＣＳ能力を有するかどうかを示し得る。故に、すべてのＤＳＣＳ関連要求は、＜ＣＳＥＢａｓｅ＞リソースに向けて送信され得る。
新しい＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、ＬＦＮの能力を記録する（例えば、ＬＦＮがその能力を対応するＬＦＮＬに登録するとき、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースが作成され得る）ように提案される。リソース属性は、表９で定義されるパラメータに対応し得る。
通常、ＬＦＮ（例えば、ＣＳＥ−１）が、その能力を、ＬＦＮＬとして機能する別のＣＳＥ−２に登録するとき、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、ＬＦＮＬ上で機能するＣＳＥ−２上で作成され得る。例えば、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、ＣＳＥ−２の＜ＣＳＥＢａｓｅ＞リソースの子リソースとして機能し得る。追加でまたは代替で、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、ＬＦＮとして機能するＣＳＥ−１の＜ｒｅｍｏｔｅＣＳＥ＞リソースの子リソースとして機能し得る。
「ｌｆｎＣａｐａｂｉｌｉｔｙ」と呼ばれる新しい属性はまた、ＣＳＥ−１のＬＦＮ能力を示すために使用され得る、ＬＦＮとして機能するＣＳＥ−１の＜ｒｅｍｏｔｅＣＳＥ＞リソースについて定義され得る。＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、表１０で規定される子リソースを含み得る。
Figure 2021536606
＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースは、表１１（表１１−１〜表１１−２）で規定される属性を含み得る。
Figure 2021536606
Figure 2021536606
表１２に示されるプロシージャは、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースを作成するために使用され得る。
Figure 2021536606
表１３に示されるプロシージャは、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースの属性を読み出すために使用され得る。
Figure 2021536606
表１４に示されるプロシージャは、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースの属性を更新するために使用され得る。
Figure 2021536606
表１５に示されるプロシージャは、＜ｌｆｎＣａｐａｂｉｌｉｔｙ＞リソースを削除するために使用され得る。
Figure 2021536606
例示的ＧＵＩインターフェースは図２５で開示され、それは、人間ユーザのためにＤＳ識別およびＲＤＳ生成プロセスを監視するために使用され得る。インターフェースを使用するユーザは、どの特定のＬＦＡをチェックしたいと思うかについてのいくつかの一般的な情報を規定し得る。一例では、ユーザは、このユーザインターフェースを使用するための２つの方法を有し得る。第１に、ユーザは、特定の役割（例えば、ＲＤＣまたはＲＤＰ）として機能するＬＦＮをチェックし得る。故に、選択された役割として機能するすべてのＬＦＮは、ユーザがレビューするために表示され得る。第２に、ユーザは、特定のＬＦＮのＩＤを直接入力し得る。故に、このＬＦＮのすべての登録された能力（例えば、そのＲＤＣ能力、ＤＳＤ能力、またはＲＤＰ能力）は、レビューのためにユーザに表示され得る。
サービス層、サービス層デバイス、サービス層アプリケーション、アプリケーションエンティティなどの、図１、図４〜図１４、および図１８〜図２４に図示されるステップを実行する、任意のエンティティは、無線および／もしくはネットワーク通信のために構成された装置、または図２６Ｃもしくは図２６Ｄに図示されるものなどのコンピュータシステムのメモリで記憶され、それらのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得る。すなわち、図１、図４〜図１４、および図１８〜図２４に図示される方法は、図２６Ｃまたは図２６Ｄに図示される装置またはコンピュータシステムなどの装置のメモリで記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１、図４〜図１４、および図１８〜図２４に図示されるステップを実行する。図１、図４〜図１４、および図１８〜図２４に図示される任意の伝送および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、装置／エンティティの通信回路によって実行され得ることもまた理解される。
図２６Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（Web of Things：ＷｏＴ）通信システム１０の図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたは装置、およびＩｏＴ／ＷｏＴサービス層などであり得る。図１〜図２５のいずれかに図示されるエンティティのいずれかは、図２６Ａ〜図２６Ｄに図示されるものなどの通信システムのネットワーク装置を備え得る。
サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴなどのアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、例えば、制御層およびトランスポート／アクセス層などの下位リソース層におけるコアネットワークへのインターフェースを提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシー管理、アクセス制御、およびサービスクラスタ化を含む、（サービス）能力または機能性の複数のカテゴリをサポートする。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワークなどの展開へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に伴う課題に対処するように、Ｍ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはサービス能力層（Service Capability Layer：ＳＣＬ）と称され得る、サービス層によってサポートされる上記の能力または機能性の集合またはセットへのアクセスをアプリケーションおよび／または種々のデバイスに提供し得る。いくつかの例は、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含むが、それらに限定されない。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義される、メッセージフォーマット、リソース構造、およびリソース表現を利用するアプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）を介して、そのような種々のアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装され得、それらがそのような能力または機能性を使用するために、種々のアプリケーションおよび／またはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）に曝される（サービス）能力または機能性を提供する、機能エンティティである。
図２６Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット、ファイバ、ＩＳＤＮ、ＰＬＣなど）もしくは無線ネットワーク（例えば、ＷＬＡＮ、セルラーなど）、または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のユーザに提供する、多重アクセスネットワークで構成され得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（Code Division Multiple Access：ＣＤＭＡ）、時分割多重アクセス（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多重アクセス（Frequency Division Multiple Access：ＦＤＭＡ）、直交ＦＤＭＡ（Orthogonal FDMA：ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（Single-Carrier FDMA：ＳＣ−ＦＤＭＡ）などの１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを備え得る。
図２６Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインと、を含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常は、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの種々の異なるネットワーク装置（例えば、サーバ、ゲートウェイ、デバイスなど）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、デバイス１８と、を含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成されている。
Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２などのオペレータネットワークを介して、または直接無線リンクを介してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ）、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。例示的Ｍ２Ｍデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。
図２６Ｂを参照すると、フィールドドメイン内の図示されたＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍデバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを備え得る、ネットワークの１つ以上のネットワーク装置によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドでなど、種々の方法で実装され得る。
図示されたＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８のためのサービスを提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファームなど）などを備え得る、ネットワークの１つ以上のネットワーク装置によって実装され得る。
また、図２６Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用し得る、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見などの機能を実行することを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を低減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、ネットワーク１２などの種々のネットワークを介して通信することを可能にする。
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視などの種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、サーバ、および他のネットワーク装置の間で実行するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。
概して、図２６Ｂに図示されるサービス層２２および２２’などのサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを介して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（Device SCL：ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）はまた、マシンタイプ通信（Machine-Type Communication：ＭＴＣ）のためのアーキテクチャを定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥで、またはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイス、もしくはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、または１つ以上の既存のノードの一部としてのいずれかで実行する、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２６Ｃまたは図２６Ｄで図示される一般アーキテクチャを有する、ネットワーク装置（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）上で実行するソフトウェアの形態で実装され得る。
さらに、本明細書で説明される方法および機能性は、サービスにアクセスするために、サービス指向アーキテクチャ（Service Oriented Architecture：ＳＯＡ）および／またはリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。
展開の観点から、サービス層は、本明細書の種々の図に示されるような、サーバ、ゲートウェイ、およびデバイスを含む、種々のタイプのネットワークノード上で展開され得る。サービス層機能性を実装するか、またはそうでない場合、サービス層のインスタンスを組み込む、通信ネットワークの任意のそのようなノード、サーバ、ゲートウェイ、デバイス、装置、または他の論理エンティティは、本明細書でサービス層エンティティと称され得る。
図２６Ｃは、図１〜図２５に図示されるエンティティのうちの１つなどの、ネットワークの装置の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図であり、それは、図２６Ａおよび図２６Ｂに図示されるものなどのＭ２Ｍネットワーク内の、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のネットワーク装置として動作し得る。図２６Ｃに示されるように、ネットワーク装置３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０と、他の周辺機器５２と、を含み得る。ネットワーク装置３０はまた、送受信機３４および伝送／受信要素３６などの通信回路を含み得る。ネットワーク装置３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このネットワーク装置は、図１〜図２５と関連して図示および説明される方法および動作などの、フォグベースのデータ保護を有効にするためのデータサンプルテンプレート（ＤＳＴ）管理のための方法を実装する装置であり得る。
プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに対応付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、任意の他のタイプの集積回路（Integrated Circuit：ＩＣ）、状態マシンなどであり得る。一般に、プロセッサ３２は、ネットワーク装置の種々の要求された機能を実行するために、ネットワーク装置のメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはネットワーク装置３０が無線もしくは有線環境内で動作することを可能にする、任意の他の機能性を実行し得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／もしくは無線アクセス層（Radio Access-Layer：ＲＡＮ）プログラムならびに／または他の通信プログラムを実行し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層などで、認証、セキュリティキー一致、および／または暗号化動作などのセキュリティ動作を実行し得る。
図２６Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に接続されている。プロセッサ３２は、コンピュータ実行可能命令の実行を介して、それが接続されるネットワークを介してネットワーク装置３０を他のネットワーク装置と通信させるために、通信回路を制御し得る。特に、プロセッサ３２は、本明細書（例えば、図１〜図２５）および請求項で説明される伝送および受信ステップを実行するために、通信回路を制御し得る。図２６Ｃは、個別のコンポーネントとしてプロセッサ３２および送受信機３４を描写しているが、プロセッサ３２および送受信機３４が、電子パッケージまたはチップ内に一緒に統合され得ることを理解されるであろう。
伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む、他のネットワーク装置に信号を伝送するか、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されたアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラーなどの種々のネットワークおよびエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されたエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
加えて、伝送／受信要素３６は、単一の要素として図２６Ｃで描写されているが、ネットワーク装置３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、ネットワーク装置３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、ネットワーク装置３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
送受信機３４は、伝送／受信要素３６によって伝送されることになる信号を変調し、伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、ネットワーク装置３０は、マルチモード能力を有し得る。したがって、送受信機３４は、ネットワーク装置３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６などの任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上で説明されるように、セッションコンテキストをそのメモリに記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、読み取り専用メモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上などのネットワーク装置３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、装置のステータスを反映するため、または装置、特に、下層ネットワーク、アプリケーション、もしくはネットワーク装置と通信する他のサービスを構成するために、ディスプレイまたはインジケータ４２上で点灯パターン、画像、または色を制御するように構成され得る。一実施形態では、ディスプレイ／インジケータ４２は、図２６Ｄに図示され本明細書で説明されるグラフィカルユーザインターフェースを提示し得る。
プロセッサ３２は、電源４８から電力を受信し得、ネットワーク装置３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、ネットワーク装置３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。
プロセッサ３２はまた、ネットワーク装置３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成された、ＧＰＳチップセット５０に接続され得る。ネットワーク装置３０は、実施形態と一致したままで、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線コネクティビティを提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に接続され得る。例えば、周辺機器５２は、加速度計、バイオメトリック（例えば、指紋）センサなどの種々のセンサ、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
ネットワーク装置３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機などの車両などの他の装置またはデバイスで具現化され得る。ネットワーク装置３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェースなどの１つ以上の相互接続インターフェースを介して、そのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。
図２６Ｄは、図１〜図２５に図示され本明細書で説明されるエンティティなどの、ネットワークの１つ以上のネットワーク装置を実装するために使用され得る、例示的コンピューティングシステム９０のブロック図であり、それは、図２６Ａおよび図２６Ｂに図示されるものなどのＭ２Ｍネットワーク内の、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のネットワーク装置として動作し得る。
コンピューティングシステム９０は、コンピュータまたはサーバを備え得、ソフトウェアの形態（そのようなソフトウェアが記憶されるかまたはアクセスされる場所または手段がいかなるものであっても）であり得るコンピュータ可読命令によって主に制御され得る。そのようなコンピュータ可読命令は、コンピューティングシステム９０を機能させるように、中央処理装置（Central Processing Unit：ＣＰＵ）９１などのプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を実行するか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、任意選択的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証などのＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されたシステムおよび方法に関連するデータを受信、生成、および処理し得る。
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネント同士を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインと、を含む。そのようなシステムバス８０の例は、周辺コンポーネント相互接続（Peripheral Component Interconnect：ＰＣＩ）バスである。
システムバス８０に接続されたメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３と、を含む。このようなメモリは、情報が記憶され、かつ読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２内に記憶されるデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第１のモードで実行するプログラムは、それ自体のプロセス仮想アドレス空間によってマップされているメモリのみにアクセスし得、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を通信することを担う、周辺機器コントローラ８３を含み得る。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。ディスプレイ８６は、ＣＰＵ９１によって実行されるコンピュータ実行可能命令と組み合わせて、図２６Ｄおよびその付随の説明で図示および説明されるグラフィカルユーザインターフェースを生成し動作させ得る。
さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他の装置と通信することを可能にするように、図２６Ａ〜図２６Ｄのネットワーク１２などの外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７などの通信回路を含み得る。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、本明細書（例えば、図１〜図２５）および請求項で説明される、伝送および受信ステップを実行するために使用され得る。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたはすべては、コンピュータ可読記憶媒体上に記憶されるコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む、Ｍ２Ｍネットワークの装置などのマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを実行および／または実装することが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ可読記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（Digital Versatile Disks：ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、かつコンピュータによってアクセスされ得る任意の他の有形もしくは物理媒体を含むが、それらに限定されない。
以下の表１６は、上記の説明で現れ得るサービス層技術に関連する頭字語のリストである。特に規定されない限り、本明細書で使用される頭字語は、以下でリストされる対応する用語を指す。
Figure 2021536606
以下の表１７−１〜表１７−３は、上記の説明で現れ得るサービス層技術に関連する用語および定義のリストである。特に規定されない限り、本明細書で使用される用語および定義は、以下でリストされる対応する用語を指す。
Figure 2021536606
Figure 2021536606
Figure 2021536606
ここで記載された説明は、例を使用して、ベストモードを含む本発明を開示し、当業者が、任意のデバイスまたはシステムを製造および使用し、任意の組み込まれた方法を実施することを含む本発明を実施することを可能にもする。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る。そのような他の例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (20)

  1. データサンプル収集サービスの第１のエージェントで実行される方法であって、
    データサンプルテンプレートを作成するための要求を受信することであって、前記データサンプルテンプレートを作成するための前記要求は、１つ以上のデータ要素に対応付けられる情報を含む、受信することと、
    前記１つ以上のデータ要素に対応付けられる前記情報に基づいて、前記データサンプルテンプレートを作成することと、
    前記データサンプル収集サービスの第２のエージェントに、前記１つ以上のデータ要素に対応付けられる１つ以上のデータソースを識別するための要求を送信することであって、前記データサンプル収集サービスの前記第２のエージェントは、ローカルフォグノード上に配置される、送信することと、
    前記データサンプル収集サービスの前記第２のエージェントから、前記１つ以上のデータソースに対応付けられる情報を受信することと、
    前記１つ以上のデータソースに対応付けられる前記情報に基づいて、前記データサンプルテンプレートを構成することと、
    を含む、方法。
  2. 前記データサンプルテンプレートを作成するための前記要求は、作成されるデータサンプルのタイプのインジケーションを含む、請求項１に記載の方法。
  3. 前記データサンプルテンプレートを作成するための前記要求は、１つ以上のパラメータのインジケーションをさらに含み、前記１つ以上のパラメータは、
    前記データサンプルに対応付けられる標的領域と、
    前記データサンプルに対応付けられる頻度と、
    前記データサンプルに対応付けられる生成スケジュールと、
    前記データサンプルに対応付けられる状況と、
    を含む、請求項２に記載の方法。
  4. 前記１つ以上のパラメータに基づいて、複数のローカルフォグノードのうちのどれを標的とするかを判定することをさらに含む、請求項３に記載の方法。
  5. 前記１つ以上のデータ要素に対応付けられる前記情報は、
    未加工データタイプの前記データ要素、
    前記データ要素のユニット、
    前記データ要素のデータ処理動作、
    前記データ要素の１つ以上のカスタマイズされた処理詳細、および
    前記データ要素の１つ以上の品質要件
    のうちの１つ以上を含む、請求項１に記載の方法。
  6. 前記データサンプル収集サービスの前記第２のエージェントに、前記構成されたデータサンプルテンプレートを送信することをさらに含む、請求項１に記載の方法。
  7. 前記データサンプル収集サービスの前記第２のエージェントは、前記構成されたデータサンプルテンプレートに基づいて、使用準備済のデータサンプルを生成するように構成されている、請求項６に記載の方法。
  8. プロセッサと、メモリと、を備える装置であって、前記メモリは、前記プロセッサによって実行されると、データサンプル収集サービスの第１のエージェントを前記装置に実装させる、コンピュータ実行可能命令を記憶し、前記データサンプル収集サービスの前記第１のエージェントは、
    データサンプルテンプレートを作成するための要求を受信することであって、前記データサンプルテンプレートを作成するための前記要求は、１つ以上のデータ要素に対応付けられる情報を含む、受信することと、
    前記１つ以上のデータ要素に対応付けられる前記情報に基づいて、前記データサンプルテンプレートを作成することと、
    前記データサンプル収集サービスの第２のエージェントに、前記１つ以上のデータ要素に対応付けられる１つ以上のデータソースを識別するための要求を送信することであって、前記データサンプル収集サービスの前記第２のエージェントは、ローカルフォグノード上に配置される、送信することと、
    前記データサンプル収集サービスの前記第２のエージェントから、前記１つ以上のデータソースに対応付けられる情報を受信することと、
    前記１つ以上のデータソースに対応付けられる前記情報に基づいて、前記データサンプルテンプレートを構成することと、
    を含む、動作を実行するように構成されている、装置。
  9. 前記データサンプルテンプレートを作成するための前記要求は、作成されるデータサンプルのタイプのインジケーションを含む、請求項８に記載の装置。
  10. 前記データサンプルテンプレートを作成するための前記要求は、１つ以上のパラメータのインジケーションをさらに含み、前記１つ以上のパラメータは、
    前記データサンプルに対応付けられる標的領域と、
    前記データサンプルに対応付けられる頻度と、
    前記データサンプルに対応付けられる生成スケジュールと、
    前記データサンプルに対応付けられる状況と、
    を含む、請求項９に記載の装置。
  11. 前記命令は、実行されるとさらに、前記データサンプル収集サービスの前記第１のエージェントに、前記１つ以上のパラメータに基づいて、複数のローカルフォグノードのうちのどれを標的とするかを判定することを含む動作を実行させる、請求項１０に記載の装置。
  12. 前記１つ以上のデータ要素に対応付けられる前記情報は、
    未加工データタイプの前記データ要素、
    前記データ要素のユニット、
    前記データ要素のデータ処理動作、
    前記データ要素の１つ以上のカスタマイズされた処理詳細、および
    前記データ要素の１つ以上の品質要件
    のうちの１つ以上を含む、請求項８に記載の装置。
  13. 前記命令は、実行されるとさらに、前記データサンプル収集サービスの前記第１のエージェントに、前記データサンプル収集サービスの前記第２のエージェントに、前記構成されたデータサンプルテンプレートを送信することを含む動作を実行させる、請求項８に記載の装置。
  14. 前記データサンプル収集サービスの前記第２のエージェントは、前記構成されたデータサンプルテンプレートに基づいて、使用準備済のデータサンプルを生成するように構成されている、請求項１３に記載の装置。
  15. プロセッサによって実行されると、データサンプル収集サービスの第１のエージェントに動作を実行させる命令を記憶する、コンピュータ可読記憶媒体であって、前記動作は、
    データサンプルテンプレートを作成するための要求を受信することであって、前記データサンプルテンプレートを作成するための前記要求は、１つ以上のデータ要素に対応付けられる情報を含む、受信することと、
    前記１つ以上のデータ要素に対応付けられる前記情報に基づいて、前記データサンプルテンプレートを作成することと、
    前記データサンプル収集サービスの第２のエージェントに、前記１つ以上のデータ要素に対応付けられる１つ以上のデータソースを識別するための要求を送信することであって、前記データサンプル収集サービスの前記第２のエージェントは、ローカルフォグノード上に配置される、送信することと、
    前記データサンプル収集サービスの前記第２のエージェントから、前記１つ以上のデータソースに対応付けられる情報を受信することと、
    前記１つ以上のデータソースに対応付けられる前記情報に基づいて、前記データサンプルテンプレートを構成することと、
    を含む、コンピュータ可読記憶媒体。
  16. 前記データサンプルテンプレートを作成するための前記要求は、作成されるデータサンプルのタイプのインジケーションを含む、請求項１５に記載のコンピュータ可読記憶媒体。
  17. 前記データサンプルテンプレートを作成するための前記要求は、１つ以上のパラメータのインジケーションをさらに含み、前記１つ以上のパラメータは、
    前記データサンプルに対応付けられる標的領域と、
    前記データサンプルに対応付けられる頻度と、
    前記データサンプルに対応付けられる生成スケジュールと、
    前記データサンプルに対応付けられる状況と、
    を含む、請求項１６に記載のコンピュータ可読記憶媒体。
  18. 前記命令は、実行されるとさらに、前記データサンプル収集サービスの前記第１のエージェントに、前記１つ以上のパラメータに基づいて、複数のローカルフォグノードのうちのどれを標的とするかを判定することを含む動作を実行させる、請求項１７に記載のコンピュータ可読記憶媒体。
  19. 前記１つ以上のデータ要素に対応付けられる前記情報は、
    未加工データタイプの前記データ要素、
    前記データ要素のユニット、
    前記データ要素のデータ処理動作、
    前記データ要素の１つ以上のカスタマイズされた処理詳細、および
    前記データ要素の１つ以上の品質要件
    のうちの１つ以上を含む、請求項１５に記載のコンピュータ可読記憶媒体。
  20. 前記命令は、実行されるとさらに、前記データサンプル収集サービスの前記第１のエージェントに、前記データサンプル収集サービスの前記第２のエージェントに、前記構成されたデータサンプルテンプレートを送信することを含む動作を実行させる、請求項１５に記載のコンピュータ可読記憶媒体。
JP2021510347A 2018-08-27 2019-08-21 フォグベースのデータ処理を有効にするためのデータサンプルテンプレート（Ｄａｔａ Ｓａｍｐｌｅ Ｔｅｍｐｌａｔｅ：ＤＳＴ）管理 Active JP7458377B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862723219P 2018-08-27 2018-08-27
US62/723,219 2018-08-27
US201862754872P 2018-11-02 2018-11-02
US62/754,872 2018-11-02
PCT/US2019/047442 WO2020046667A1 (en) 2018-08-27 2019-08-21 Data sample template (dst) management for enabling fog-based data processing

Publications (2)

Publication Number Publication Date
JP2021536606A true JP2021536606A (ja) 2021-12-27
JP7458377B2 JP7458377B2 (ja) 2024-03-29

Family

ID=67847791

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021510347A Active JP7458377B2 (ja) 2018-08-27 2019-08-21 フォグベースのデータ処理を有効にするためのデータサンプルテンプレート（Ｄａｔａ Ｓａｍｐｌｅ Ｔｅｍｐｌａｔｅ：ＤＳＴ）管理

Country Status (6)

Country Link
US (1) US20210336862A1 (ja)
EP (1) EP3804232A1 (ja)
JP (1) JP7458377B2 (ja)
KR (1) KR20210049812A (ja)
CN (1) CN112236979B (ja)
WO (1) WO2020046667A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11902385B2 (en) * 2021-02-25 2024-02-13 Insight Direct Usa, Inc. IoT device reading transformations
CN113873024B (zh) * 2021-09-23 2022-09-23 中国科学院上海微系统与信息技术研究所 一种边缘雾网络中数据差分化下载方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7428699B1 (en) * 2003-01-15 2008-09-23 Adobe Systems Incorporated Configurable representation of structured data
CN103986743A (zh) * 2013-02-07 2014-08-13 伊姆西公司 用于在物联网中采集数据的方法、装置和系统
US10380105B2 (en) 2013-06-06 2019-08-13 International Business Machines Corporation QA based on context aware, real-time information from mobile devices
US9843617B2 (en) * 2014-03-26 2017-12-12 Rockwell Automation Technologies, Inc. Cloud manifest configuration management system
US10319469B2 (en) * 2014-04-22 2019-06-11 Cerner Innovation, Inc. Rule-based low-latency delivery of healthcare data
US10362113B2 (en) * 2015-07-02 2019-07-23 Prasenjit Bhadra Cognitive intelligence platform for distributed M2M/ IoT systems
US10007513B2 (en) * 2015-08-27 2018-06-26 FogHorn Systems, Inc. Edge intelligence platform, and internet of things sensor streams system
US9948522B2 (en) * 2016-01-11 2018-04-17 Equinix, Inc. Associating infrastructure assets in a data center
US20190114293A1 (en) * 2016-04-25 2019-04-18 Convida Wireless, Llc Methods for enabling data analytics service at service layer
JP2018010421A (ja) 2016-07-12 2018-01-18 株式会社日立製作所 計算機システム、計算機及びデータフィルタリング方法
KR102304309B1 (ko) * 2017-02-02 2021-09-23 삼성전자주식회사 전자 장치에게 센싱 데이터를 제공하는 시스템 및 방법
US10317888B2 (en) 2017-03-01 2019-06-11 PLETHORA IloT, S.L. Device and system including multiple devices for supervision and control of machines in industrial installation

Also Published As

Publication number Publication date
WO2020046667A1 (en) 2020-03-05
EP3804232A1 (en) 2021-04-14
JP7458377B2 (ja) 2024-03-29
CN112236979A (zh) 2021-01-15
KR20210049812A (ko) 2021-05-06
US20210336862A1 (en) 2021-10-28
CN112236979B (zh) 2023-10-13

Similar Documents

Publication Publication Date Title
CN107079050B (zh) 服务层会话迁移和共享
KR101977441B1 (ko) 가상화 브로커 및 콘텍스트 정보를 이용한 자원들의 가상화를 위한 방법 및 장치
KR102091069B1 (ko) 향상된 RESTful 동작들
US11689584B2 (en) Establishing communication links using routing protocols
US20230208780A1 (en) Enhanced real-time linking methods and systems
CN106797392A (zh) M2m‑iot服务的发布和发现
Loke Supporting ubiquitous sensor-cloudlets and context-cloudlets: Programming compositions of context-aware systems for mobile users
JP7458377B2 (ja) フォグベースのデータ処理を有効にするためのデータサンプルテンプレート（Ｄａｔａ Ｓａｍｐｌｅ Ｔｅｍｐｌａｔｅ：ＤＳＴ）管理
Aversa et al. A simulation model for localization of pervasive objects using heterogeneous wireless networks
CN107950005B (zh) 服务元素主机选择
CN112243579A (zh) 通信网络中的服务层实体的自动化关系管理
US20200220919A1 (en) Overlay resource trees in a communication network
US11134365B2 (en) Resource link management at service layer
US20240147404A1 (en) Multi-access edge computing (mec) application registry in mec federation
Girau Architectural and application solutions for the cloud Internet of Things
US20230283682A1 (en) Location-based task execution for enhanced data access
Takatsuka et al. KULOCS: unified locating service for efficient development of location-based applications

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220809

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230926

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231221

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240318

R150 Certificate of patent or registration of utility model

Ref document number: 7458377

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150