従来のデータセットと比較して、ビッグデータは、典型的には、顧客の買物履歴記録から潜在的購入をどのように発見するかなどの、このデータからの徹底的洞察を得るために分析する必要がある膨大な非構造化データを含む。一般に、いくつかの「Vs」を指す、ビッグデータの一般的定義が存在する。
Volume(量)について、大量のデータの生成および収集に伴って、データスケールが、ますます大きくなる(例えば、インターネット企業によって生成されるデータが、1日あたり数十のPBに容易に到達し得る)。
Variety(多様性)は、オーディオ、ビデオ、ウェブページ、およびテキストなどの半構造化および非構造化データ、ならびにデータベーステーブルのような従来の明確に定義された構造化データを含む、種々のタイプのデータを示す。
Velocity(速度)について、ビッグデータの時系列(例えば、データ収集および分析)が、ビッグデータの商業的価値を最大化するように、タイムリーな様式で処理されなければならない。
Value(価値)について、データ内に隠蔽される有用な知識および洞察が存在するが、それらは、非常に低密度であり得る。
典型的には、例えば、物理的世界に組み込まれ、ネットワークによってコンピューティングリソースに接続される、センサおよびデバイスを指す、マシンツーマシン(M2M)およびモノのインターネット(IoT)通信の出現が、ビッグデータにおける成長を駆動する主要な傾向であることは、着目に値する。例えば、世界中に展開される接続されたIoTノードの数が、年間30パーセントを超える率で成長することが予期される。それらの膨大なIoTノードは、大量のデータを生成することが予期され、それは、IoTデータ処理のためにコスト効率のソリューションを要求する。
エッジコンピューティングにより、IoTデバイスによって生成されるデータが、長いルートにわたってそれをデータセンターまたはクラウドに送信する代わりに、それが作成される場所のより近くで処理されることが可能になる。
エッジコンピューティング展開は、種々の状況で理想的であり得る。一例示的シナリオは、IoTデバイスが乏しいコネクティビティを有し、IoTデバイスが中央クラウドに常に接続されるのが効率的でない場合である。他のシナリオは、情報の待ち時間感知処理との関係があり得る。データが、処理のためのデータセンターまたはクラウドにネットワークを介して横断する必要がないため、エッジコンピューティングは、待ち時間を低減する。
フォグコンピューティングは、エッジデバイスとクラウドとの間のネットワーク接続を指す。他方では、エッジコンピューティングは、より具体的には、エッジデバイスの近くで行われる計算プロセスを指す。したがって、フォグコンピューティングは、エッジコンピューティングを含み得るが、フォグコンピューティングはまた、処理されたデータをその最終目的地に送り出すために必要とされるネットワークを組み込み得る。正式には、フォグコンピューティング(または簡潔には、フォグ)は、エンドユーザにより近いコンピューティング、記憶装置、制御、およびネットワーキングなどのリソースおよびサービスをクラウドからモノへの連続体に沿って移動させるシステムレベルアーキテクチャである。例示的フォグ有効連続体が、図1に示される。
一般に、「データ分析」は、広い用語である。したがって、市場において多くのタイプのデータ分析製品(例えば、グーグルアナリティクス、IBMワトソン、分散されたデータ処理のためのオープンソースApache Hadoopエコシステムなど)が存在する。
Microsoft Azure IoT Edgeは、クラウド分析およびカスタムビジネスロジックをエッジでのデバイスに移動させる例示的製品である。一般に、Azure IoT Edgeは、3つのコンポーネントで構成されている。
IoT Edgeモジュールは、Azureサービス、第三者サービス、または開発者自身のコードを実行するコンテナである。それらは、IoT Edgeデバイスに展開され、それらのデバイス上でローカルに実行され得る。IoT Edgeモジュールは、現在、Docker互換性コンテナとして実装され、エッジでユーザのビジネスロジックを実行する、実行のユニットである。複数のモジュールは、相互に通信し、データ処理のパイプラインを作成するように構成され得る。
IoT Edge実行時間は、各IoT Edgeデバイス上で実行し、各デバイスに展開されるモジュールを管理する。
クラウドベースのインターフェースは、ユーザが、IoT Edgeデバイスを遠隔で監視および管理することを可能にする。
AWS Greengrassは、ローカル計算、メッセージング、および接続されたデバイスについてのデータキャッシング能力をユーザに実行させるソフトウェアである。AWS Greengrassを用いて、接続されたデバイスは、AWS Lambda機能(イベント処理サービス)を実行し、デバイスデータを同期した状態に維持し、インターネットに接続されていないときでさえ、セキュアに他のデバイスと通信し得る。
AWS Greengrassは、異なるタイプのデバイスをクラウドと相互に接続するIoTソリューションをユーザに構築させる。AWS Greengrass Coreを実行するデバイスは、Amazon FreeRTOSを実行しているか、またはAWS IoT Device SDKがインストールされた、他のデバイスと通信し得るハブとして機能する。
AWS Greengrass Coreデバイス、AWS IoT Device SDK有効デバイス、およびAmazon FreeRTOSデバイスは、エッジでGreengrass Group内で相互に通信するように構成され得る。Greengrass Coreデバイスが、クラウドへのコネクティビティを失う場合、Greengrass Group内のデバイスは、ローカルネットワークを介して相互に通信し続け得る。Greengrass Groupは、例えば、ビルの1つのフロア、1つのトラック、または全マイニングサイトを表し得る。
開発下のoneM2M規格は、「共通サービスエンティティ(Common Service Entity:CSE)」と呼ばれるサービス層を定義する(oneM2M-TS-0001 oneM2M Functional Architecture -V3.8.0を参照)。サービス層の目的は、異なる「バーティカル」M2Mシステムおよびアプリケーションによって利用され得る「ホリゾンタル」サービスを提供することである。CSEは、図2に示されるように、4つの参照点をサポートする。Mca参照点は、アプリケーションエンティティ(Application Entity:AE)とインターフェース接続する。Mcc参照点は、同じサービスプロバイダドメイン内の別のCSEとインターフェース接続し、Mcc’参照点は、異なるサービスプロバイダドメインでの別のCSEとインターフェース接続する。Mcn参照点は、下層ネットワークサービスエンティティ(Network Service Entity:NSE)とインターフェース接続する。NSEは、デバイス管理、ロケーションサービス、およびデバイストリガなどの仮想ネットワークサービスをCSEに提供する。
CSEは、「発見」および「データ管理&リポジトリ」などの「共通サービス機能(CSF)」と呼ばれる複数の論理機能を含む。図3は、oneM2Mによって定義されるCSFのいくつかを図示する。
oneM2Mアーキテクチャは、以下の例示的タイプのノードを有効にする。
アプリケーションサービスノード(Application Service Node:ASN)について、ASNは、1つのCSEを含み、少なくとも1つのアプリケーションエンティティ(AE)を含む、ノードである。物理的マッピングの例について、ASNは、M2Mデバイス内に常駐し得る。
アプリケーション専用ノード(Application Dedicated Node:ADN)について、ADNは、少なくとも1つのAEを含み、CSEを含まない、ノードである。oneM2Mシステムのフィールドドメイン内に0個以上のADNが存在し得る。物理的マッピングの例について、アプリケーション専用ノードは、制約M2Mデバイス内に常駐し得る。
中間ノード(Middle Node:MN)について、MNは、1つのCSEを含み、0個以上のAEを含む、ノードである。oneM2Mシステムのフィールドドメイン内に0個以上のMNが存在し得る。物理的マッピングの例について、MNは、M2Mゲートウェイ内に常駐し得る。
インフラストラクチャノード(Infrastructure Node:IN)について、INは、1つのCSEを含み、0個以上のAEを含む、ノードである。インフラストラクチャドメイン内に、oneM2Mサービスプロバイダにつき、ちょうど1つのINが存在する。IN内のCSEは、他のノードタイプに適用可能でないCSE機能を含み得る。物理的マッピングの例について、INは、M2Mサービスインフラストラクチャ内に常駐し得る。
非oneM2Mノード(Non-oneM2M Node:NoDN)について、非oneM2Mノードは、oneM2Mエンティティを(AEもCSEも)含まないノードである。そのようなノードは、管理を含む、相互作用の目的のためのoneM2Mシステムに取り付けられたデバイスを表す。
例示的スマートシティ分析ユースケースが図4に示される。スマートシティを構築するために、市当局は、(oneM2Mなどの)規格ベースのサービス層(SL)プラットフォームを採用し、(道路およびストリート、公共ビル、バスおよび地下鉄などの)市の公共インフラストラクチャ上に多くのIoTセンサおよびデバイスを展開している。その一方で、制限された予算に起因して、市当局はまた、このスマートシティのイニシャティブのために、私的な組織および個人の関与を要求する。故に、(私的な車、携帯電話などの)私的な財産上にインストールされたそれらのIoTデバイスはまた、システム内に統合され、それは、シティのリアルタイム実行ステータスを反映する大量の広範なIoTデータを生成し得る。
シティは、中心業務地区(Central Business District:CBD)、郊外住宅エリアなどの多くの地理的領域を有し得、それは、ローカルフォグエリア(LFA)と称され得る。膨大な量のIoTデバイスが、それらのLFAで展開され得、大量のIoTデータが、それらのLFAから生成され得る。通信ネットワーク観点から、異なるシティ領域が、複数のLFAを構成する(例えば、図4に示されるように、CBDが、LFA−1に対応し、郊外住宅エリアが、LFA−2に対応する)。
スマートシティ制御コンソールは、ユーザが、必要性に基づいて種々のデータ分析要求を呈することを可能にするクラウドで展開される。例えば、組織Aからのユーザは、所与のエリアについての現在の気象および環境汚染ステータス(例えば、大規模道路工事およびビル建設下のエリアである、図4に示されるようなLFA−X)を評価することを意図する、(要求1として示される)要求を有し得る。実際には、データ分析結果は、通常は、種々のチャート(例えば、ラインチャートまたはバーチャート)を介して表される。ユーザが見ることを意図する分析チャートのタイプに加え、それらはまた、データサンプルがあるべき姿、チャートを描くための入力がどれかを規定し得る。チャートを描くためのそれらのデータサンプルを準備するために、関連する未加工データが、(温度センサ、湿度センサ、汚染センサ、騒音センサなどの)LFAでの種々のIoTデバイスから収集される必要がある。特に、それらのセンサまたはデバイスは、(ユーザが入っている)組織A以外の異なる組織によってインストールされ得る。異なる組織の間で相互作用を処理するとき、種々の制約(例えば、異なる組織の間での相互作用の複雑性)、ならびに膨大なIoTデータの潜在的に被る、通信および処理コストを考慮することによって、効率的な方法でこれを行うことが、主要な課題である。
一例では、要求1で、ユーザがLFA−Xについてのラインチャートを見ることを意図し、それは、3分毎に1つのデータサンプルを要求することを想定する。特に、各データサンプルは、以下の2つのデータ要素によって構成され得、データ要素の各々は、品質要件に対応付けられ得る。
データ要素(DE)−1について、最後の3分におけるLFA−Xの平均温度。
DE−1の品質要件について、温度読み取り値は、精度を保証するために、LFA−Xで展開される、少なくとも100個の異なる温度センサから収集される必要がある。
DE−2について、最後の3分におけるLFA−Xの平均騒音レベル。
DE−2の品質要件について、騒音読み取り値は、LFA−Xでの30個の主要な交差点で展開される騒音センサから収集される必要がある。
クラウドで展開されるスマートシティ制御コンソール上でラインチャートを描くために、(DE−1、DE−2、タイムスタンプ)のフォーマットを有するデータサンプルは、3分毎に必要とされる。
以下の技術的課題は、上記のユースケースに関連して識別され得る。
問題1について、スマートシティ分析ユースケースが、LFAからすべての必要なIoTデータを収集し、クラウドで中央データ処理を行うことであるのを実現するための直接のソリューション。例えば、初期の例でのDE−1を考慮し、100個の温度読み取り値が、3分毎にLFAから収集され、次いで、データ処理(例えば、それらの100個の読み取り値の平均値の計算)が行われるクラウドに転送される。見られ得るように、中央データ処理は、LFAからクラウドへの大量のデータ移動に起因する多量の通信オーバーヘッドにつながる。
問題2について、ユーザは、LFAでの利用可能なIoTデータソースについての知識を有しない場合がある。例えば、スマートシティユースケースでは、展開されたSLプラットフォームはまた、異なる組織および個人から多くのIoTデバイスを統合する。故に、クラウド側からのユーザは、それらのIoTデバイスを展開した同じグループでない場合がある。その結果、ユーザは、所望のデータサンプルのためのデータソースとして使用され得る所望のIoTデバイスを識別するためにLFAを自身で探索しなければならない。そのような要件は、特に、LFAで適切な発見能力を有しない場合に、ユーザに余分な負荷を呈する。
問題3について、既存のIoTエッジ製品は、ユーザが「エッジツークラウド」構成能力を有しない場合があるという事実に起因して有用でない場合がある。例えば、(Microsoft Azure IoT EdgeまたはAmazon Greengrassなどの)既存の製品の大部分は、ユーザが、通常、LFAでのデバイス/ノード(例えば、エッジでのセンサ、ゲートウェイなど)についての知識および構成能力を有する、比較的単純なケースをサポートするように構成されている。言い換えると、ユーザは、自身の使用のためにエッジ分析アプリケーションを構築したいと思うとき、何のエッジデバイスが接続されるべきかを知り得、また、エッジ側で直接、データ処理を行うための分析処理コード/ユニットを実行するために、それらのノード(例えば、ゲートウェイ)を構成するための能力を有し得る。しかしながら、これは、ユーザが、LFAでの多くのIoTデバイスの所有者でないか、または他の異なるグループまたは組織によって所有され得るLFAでの任意のノードを構成するための任意の能力を有しない例でのケースではない。その結果、既存のIoTエッジ製品は、そのような異種シナリオで機能しない場合がある。
全体としてサービス層観点から、SLベースのプラットフォームは、多くの場合、異なるドメインの間でアプリケーションを有効にするホリゾンタルプラットフォームであることが想定される。言い換えると、そのようなホリゾンタルプラットフォームは、異種アプリケーションシナリオについての所望の特性である、異なるグループおよび/または組織からのリソースを統合するのに優れているべきである。そうするために、(oneM2Mなどの)SLベースのプラットフォームは、多くの場合、多くのタイプの共通サービスを提供し、それは、ユーザが詳細に関与することを可能にすることなく、またはそうすることを要求することなく、(発見、デバイス管理などの)異なるタイプの動作をユーザが行うことを可能にし得る。しかしながら、既存のSLベースのプラットフォームソリューションは、現在、フォグコンピューティングパラダイムを活用することによって効率的なデータサンプル収集および処理をサポートするための共通サービスまたは能力を提供しない。
フォグベースのサービス層(SL)のためのデータサンプル収集サービス(DSCS)が本明細書に開示される。DSCSは、フォグコンピューティングパラダイムに基づくSLでのサービスである。DSCSを用いて、DSCSのユーザは、受信することを意図するRDSのタイプについてその必要性を規定し得、DSCSは、LFAですべてのことを処理し、所望のRDSを生成するように構成され得る。
データサンプルテンプレート(DST)もまた開示される。DSTは、ユーザが受信することを意図するRDSのタイプについてのすべての詳細を記載し、それは、LFAでIoT未加工データ収集および未加工データ処理を行うためのDSCSのためのガイドラインである。
以下の態様のうちの1つ以上を含み得る、「DST管理」のための方法およびシステムもまた開示される。
いくつかの例示的ソリューションが、異なるアプリケーションシナリオで使用され得る、「DST作成プロセス」のために本明細書に開示され、以下のことを含むが、それらに限定されない。
シナリオ1についてのLFAでの反応DS識別を伴うDST作成、
シナリオ2についてのLFAでの事前対応DS識別を伴うDST作成、
シナリオ3についてのDE再使用を介したDST作成、および
シナリオ4についてのDST分割を伴うDST作成。
いくつかのソリューションが、「DST更新/削除プロセス」のために開示され、以下のことを含むが、それらに限定されない。
新しいDEを既存のDSTに追加するか、または既存のDSTでいくつかの情報を単に更新するためのDST更新プロセス、および
既存のDSTで1つ以上のDEを削除するか、または全DSTを削除するためのDST更新プロセス。
いくつかのソリューションが、「DST有効化プロセス」のために開示され、以下のことを含むが、それらに限定されない。
所与のDSTが、DST内の「RDS_Production_Schedule」パラメータで示されるパラメータに基づいて有効にされ得る。
所与のDSTが、ユーザ自体からの信号に基づいて有効にされ得る。
所与のDSTが、LFAで発生したイベントに基づいて有効にされ得る。
本開示全体を通して使用される用語のうちのいくつかについての例示的定義が以下に説明される。
クラウドノード(Cloud Node:CN)について、展開階層でより下の他のフォグノードの動作を管理するクラウド能力を有するノード。用語「クラウド」は、クラウドノードを指すために使用され得ることに留意されたい。さらに、クラウドは、アプリケーションのためのフォグサービス層を一緒に有効にする、異なるフォグノード間の相互作用を監視および管理する。
ローカルフォグエリア(LFA)について、地理的領域(例えば、シティ)は、異なるアプリケーションシナリオに応じて複数のLFAに分割され得る。例えば、スマートシティシナリオでは、特定の住宅エリアが、LFAであり得るか、またはダウンタウンエリア内のCBDが、LFAであり得る。
ローカルフォグノード(LFN)について、LFNは、計算、記憶、および通信能力を有するLFA内のノードであり得る。LFNは、その対応するLFA内のLFNリーダー(LFN Leader:LFNL)と通信および相互作用し得る。例えば、LFNは、人の携帯電話、移動バス、または家のホームゲートウェイなどであり得る。LFNは、ネットワークの最も低いレベルであるフォグノード(Fog Node:FN)のタイプである。LFNは、LFA内の他のLFNと相互作用および協働し得、DSからのデータの発見、取得、および処理を行い得る。
データソース(DS)について、ノードは、それがIoTデータのソースの場合、DSであり得る。例えば、DSは、センサ、カメラ、交通灯、またはデータを生成する任意のIoTデバイスであり得る。ロードサイドユニットはまた、それが道路表面に関連するセンサデータを生成するため、DSであり得る。その一方で、ロードサイドユニットはまた、それが、あるデータ処理能力を行い得、および/またはLFNLと通信し得るため、LFNであり得る。センシングを有するだけでなく、コンピューティング、記憶、および通信能力を有する、LFA内のノードは、LFNおよびDSであり得る。
LFNリーダー(LFNL)について、所与のLFAは、フォグエリア内のLFNリーダーを有し得る。LFNLは、そのLFA内のすべてのLFNを管理し、また、より高いレベルにあるFNに接続されている。例えば、スマートシティの例では、LFNLは、特定の住宅エリアの主要ゲートウェイであり得る。
フォグノード(FN)について、計算、記憶、通信、分析などの任意のフォグリソースを有するノード。フォグノードは、これらのリソースのうちの少なくとも1つを有し得、また、フォグノード上で実行している他のソフトウェアまたはサービスを有し得る。FNは、LFNのレベルよりも高いあるレベルで展開されることが想定される。CNが最も高いレベルにある状態でFN展開のいくつかのレベルが存在し得る。例えば、スマートシティユースケースでは、FNは、ネットワーク内のより高いレベルでのルーターであり得る。
本開示で提案されるアイディアが、フォグ関連用語を使用して説明されるが、本開示で提案されるアイディアがまた、エッジシナリオに適用され得ることは、着目に値する。例えば、LFAはまた、エッジでの特定のエリアとして解釈され得、LFNは、エッジ側でのノードであり得、LFNLは、エッジでのゲートウェイまたはエッジでのロードサイドユニットなどであり得る。
データサンプル収集サービス(DSCS)と称され得る、サービス層のための新しい共通サービスが本明細書に開示される。DSCSのハイレベルアーキテクチャが図5に示される。開示されたDSCSは、以下の能力のうちの1つ以上を有し得る。
DSCSは、ユーザから種々のデータサンプル収集要求を受信し、そのユーザの代わりに、すべての詳細を処理し得る。
(例えば、制御コンソール上でラインチャートを描くために)ユーザが必要とする使用準備済のデータサンプル(RDS)の種類を適切に説明するために、DSCSは、データサンプルテンプレート(DST)と呼ばれる新しいコンセプトを採用する。DSTを使用することによって、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプルがどのようなものかを明確に表し得る。
DSCSは、DST管理機能をユーザに提供し得る。一般に、DST管理は、DST作成、DST更新、DST削除、およびDST有効化/無効化のプロセスを含む。例えば、ユーザは、DSTを、そのデータサンプル収集の必要性に基づいて作成し得る。後に、作成されたDSTはまた、必要性に対する動的な変更に基づいて更新および/または削除され得る。DSTに対して行われる変更はまた、このDSTの対応するデータサンプルに対する変更につながり得る。
DSCSは、作成されたDSTを有効または無効にするためにインターフェースをユーザに提供し得る。一例では、DSTの実際のRDS生成は、このDSTが有効なステータスにあるまで開始されない場合があることに留意されたい。
例示的方法は、データサンプルテンプレートを作成するための要求を受信することであって、データサンプルテンプレートを作成するための要求が、1つ以上のデータ要素に対応付けられる情報を含む、受信することと、1つ以上のデータ要素に対応付けられる情報に基づいて、データサンプルテンプレートを作成することと、データサンプル収集サービスの第2のエージェントに、1つ以上のデータ要素に対応付けられる1つ以上のデータソースを識別するための要求を送信することであって、データサンプル収集サービスの第2のエージェントが、ローカルフォグノード上に配置される、送信することと、データサンプル収集サービスの第2のエージェントから、1つ以上のデータソースに対応付けられる情報を受信することと、1つ以上のデータソースに対応付けられる情報に基づいて、データサンプルテンプレートを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第1のエージェントを含み得る。
データサンプルテンプレートを作成するための要求は、作成されるデータサンプルのタイプのインジケーションを含み得る。データサンプルテンプレートを作成するための要求は、1つ以上のパラメータのインジケーションをさらに含み得、1つ以上のパラメータは、データサンプルに対応付けられる標的領域と、データサンプルに対応付けられる頻度と、データサンプルに対応付けられる生成スケジュールと、データサンプルに対応付けられる状況と、を含む。方法は、1つ以上のパラメータに基づいて、複数のローカルフォグノードのうちのどれを標的とするかを判定することをさらに含み得る。1つ以上のデータ要素に対応付けられる情報は、未加工データタイプのデータ要素、データ要素のユニット、データ要素のデータ処理動作、データ要素の1つ以上のカスタマイズされた処理詳細、およびデータ要素の1つ以上の品質要件のうちの1つ以上を含み得る。方法は、データサンプル収集サービスの第2のエージェントに、構成されたデータサンプルテンプレートを送信することをさらに含み得る。データサンプル収集サービスの第2のエージェントは、構成されたデータサンプルテンプレートに基づいて、使用準備済のデータサンプルを生成するように構成され得る。
例示的方法は、第1のデータサンプルテンプレート、第2のデータサンプルテンプレート、および第3のデータサンプルテンプレートに基づいて生成することであって、第2のデータサンプルテンプレートが、データ要素の第1のセットに対応付けられ、第3のデータサンプルテンプレートが、データ要素の第2のセットに対応付けられる、生成することと、データサンプル収集サービスの第2のエージェントに、データ要素の第1のセットに対応付けられるデータソースの第1のセットを識別するための要求を送信することであって、データサンプル収集サービスの第2のエージェントが、第1のローカルフォグノードに配置される、送信することと、データサンプル収集サービスの第3のエージェントに、データ要素の第2のセットに対応付けられるデータソースの第2のセットを識別するための要求を送信することであって、データサンプル収集サービスの第3のエージェントが、第2のローカルフォグノードに配置される、送信することと、データサンプル収集サービスの第2のエージェントから、データソースの第1のセットに対応付けられる情報を受信することと、データサンプル収集サービスの第3のエージェントから、データソースの第2のセットに対応付けられる情報を受信することと、データソースの第1のセットに対応付けられる情報、およびデータソースの第2のセットに対応付けられる情報のうちの1つ以上に基づいて、第2のデータサンプルテンプレートおよび第3のデータサンプルテンプレートのうちの少なくとも1つを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第1のエージェントを含み得る。
方法は、データサンプルテンプレートを作成するための要求を受信することであって、データサンプルテンプレートを作成するための要求が、1つ以上のデータ要素に対応付けられる情報を含む、受信することと、1つ以上の受信されたデータ要素に対応付けられる情報に基づいて、第2のデータサンプルテンプレートおよび第3のデータサンプルテンプレートを作成することと、をさらに含み得る。1つ以上の受信されたデータ要素に対応付けられる情報は、データ要素の第1のセットに対応付けられる情報と、データ要素の第2のセットに対応付けられる情報と、を含み得る。方法は、1つ以上の受信されたデータ要素に対応付けられる情報に基づいて、複数のローカルフォグノードのうちの1つ以上を標的とすることを判定することをさらに含み得る。第2のデータサンプルテンプレートおよび第3のデータサンプルテンプレートの各々は、以下のパラメータ、すなわち、データサンプルのそれぞれのセットに対応付けられる標的領域、データサンプルのそれぞれのセットに対応付けられる頻度、データサンプルのそれぞれのセットに対応付けられる生成スケジュール、およびデータサンプルのそれぞれのセットに対応付けられる状況のうちの1つ以上を含み得る。方法は、データサンプル収集サービスの第2のエージェントに、構成された第2のデータサンプルテンプレートを送信することと、データサンプル収集サービスの第3のエージェントに、構成された第3のデータサンプルテンプレートを送信することと、をさらに含み得る。データサンプル収集サービスの第2のエージェントは、構成された第2のデータサンプルテンプレートに基づいて、第1の使用準備済のデータサンプルを生成するように構成され得る。データサンプル収集サービスの第3のエージェントは、構成された第3のデータサンプルテンプレートに基づいて、第2の使用準備済のデータサンプルを生成するように構成され得る。
例示的方法は、新しいデータ要素を既存のデータサンプルテンプレートに追加する要求を受信することであって、既存のデータサンプルテンプレートが、複数のデータ要素を含む、使用準備済のデータサンプルに対応付けられる、受信することと、新しいデータ要素に基づいて、既存のサンプルテンプレートを更新することと、データサンプル収集サービスの第2のエージェントに、新しいデータ要素に対応付けられる1つ以上のデータソースを識別するための要求を送信することであって、データサンプル収集サービスの第2のエージェントが、ローカルフォグノード上に配置される、送信することと、データサンプル収集サービスの第2のエージェントから、1つ以上のデータソースに対応付けられる情報を受信することと、1つ以上のデータソースに対応付けられる情報に基づいて、更新されたデータサンプルテンプレートを構成することと、を含む、動作を実行するように構成されたデータサンプル収集サービスの第1のエージェントを含み得る。
新しいデータ要素を追加するための要求は、既存のデータサンプルテンプレートの識別子、および新しいデータ要素のための標的領域のうちの1つ以上を含み得る。新しいデータ要素に対応付けられる情報は、未加工データタイプのデータ要素、データ要素のユニット、データ要素のデータ処理動作、データ要素の1つ以上のカスタマイズされた処理詳細、およびデータ要素の1つ以上の品質要件のうちの1つ以上を含み得る。新しいデータ要素を追加するための要求は、既存のデータ要素を更新するための要求を含み得る。データ要素を更新するための要求は、既存のデータサンプルテンプレートの識別子、および更新されるデータ要素の1つ以上のパラメータのうちの1つ以上を含み得る。方法は、データサンプルテンプレートを更新する前に、データサンプルテンプレートを無効にすることをさらに含み得る。
上記のようなDSCSの能力を実装するために、以下の詳細が説明される。
一般に、(LFN、FN、またはCN上で実装されるものなどの)サービス層ノードは、このノードがデータサンプル収集関連サービスを提供することを意図する場合、DSCSエージェントを有し得る。SLノード上のDSCSエージェントは、ユーザによって呈される種々のデータサンプル収集タスクを行うために、DSCSユーザと相互作用するだけでなく、他のDSCSエージェントと協働し得る、ソフトウェアのピースである。
DSCSエージェントとDSCSユーザとの間の相互作用に関して、DSCSエージェントは、DST作成、DST更新、およびDST削除の観点でDST管理をサポートするために、インターフェースをDSCSユーザに提供し得る。例えば、図5に示されるように、DSCSエージェント(例えば、DSCSエージェント1)は、CNで展開され、それは、CNで、異なるユーザからの分析要求を受け入れ得る。
DSCSエージェント間で相互作用および協働もまた存在し得る。例えば、DSCSエージェントはまた、(そのLFAで、すべての未加工データ収集および処理を処理し得る)LFAのLFNLで展開される必要があり得る。典型的には、CNでのDSCSエージェント1は、ユーザの必要性に基づいてDSTを作成し、このDSTが展開されるべきLFAがどれかを見出し得る。例えば、ユーザが、単に、特定のLFAからデータサンプルを収集したいと思う場合、DSTは、そのLFA内のDSCSエージェント(例えば、DSCSエージェント2)に展開され得る。展開の間、あるワークスレッド(例えば、コードスニペット)が、DSCSエージェント2上に設定され得る。特に、DSCSエージェント2は、このLFAで所望のDSを識別し、要求されたデータ処理動作を行い、RDSを生成し、単にCNでRDSをユーザに送信し返すことを担い得る。全体として、それらのDSCSエージェントは、種々のデータサンプル収集要求を満たすために一緒に機能し得る。
SL内の共通サービスとして、DSCSは、システムが異なるグループまたは組織から(デバイス、ノードなどの観点で)リソースを統合する場合でさえ、フォグコンピューティングパラダイムを実現し得る。より重要なのは、DSCSが、ユーザが、LFAで未加工データを収集し、LFAで展開されるDSCSエージェント上で直接、未加工データを分析/処理するのに役立ち得ることである。言い換えると、このプロセス全体を通して、ユーザは、LFAで適格なDSをどのように識別するか、および未加工データ処理のためにそれらのLFAでLFNをどのように構成するかに関する任意の詳細において関与する必要がない場合がある。その結果、ユーザは単に、DSTを作成することによって、所望のRDSについての必要性を規定する必要があり得る。すべての他の残りの処理は、開示されたDSCSによって処理され得る。
DSCSユーザは、LFAからデータサンプルを収集する必要性を有するとき、DSCSエージェントに送信され得るデータサンプル収集要求でその必要性を記載し得る。故に、DSTが作成され得、それは、このDSTについてのRDS生成をどのように行うかについてのすべての詳細を含む。以下に示されるように、表1(表1−1〜表1−7)は、DSTについての詳細な定義を与える。
本開示の第1の態様では、DST作成プロセスのための方法およびシステムが開示される。
作成される所与のDSTについて、このDSTについての所望のDSであるかどうかを判定するために発見および評価される必要がある(そのようなプロセスは、DS識別プロセスと称され得る)、LFA内の多数(例えば、数千)の潜在的DSが存在し得る。その一方で、それらのDSから収集される未加工データはまた、多数であり得、RDSを生成するための膨大な未加工データに対するデータ処理は、RDS生成プロセスと称され得る。(制御プレーン問題としての)DST管理と比較して、DS識別およびRDS生成は、実際のRDS生成についての「データプレーン」問題と同様である。
第1の例では、LFAで反応DS識別を伴うDST作成プロセスが論じられる。この例では、識別されるLFAで所望のDSを必要とするDST作成要求が存在するまで、DS識別が行われない場合がある。これは、LFA内のDSCSエージェントが単に、制限されたエネルギーもしくは処理能力を有するか、またはLFA内のDSの利用可能性が頻繁に変化する(例えば、DSが移動車両上に備わる場合、それらのDSは、異なる時間間隔で異なるLFAで利用可能であり得るという意味において、異なるLFAの間で移動し得る)、シナリオに適用可能であり得る。
図6は、LFAで反応DS識別を伴うDST作成プロセスのための例示的プロシージャを図示する。
ステップ1で、この例示的システムでは、CN上にDSCSエージェントが存在する。ユーザ1は、データサンプル収集の必要性を有し、SLによって提供されるDSCSを使用することを意図する。故に、ユーザ1は、CN上でDSCSエージェント1にコンタクトすることを決定する。
ステップ2で、ユーザ1は、受信したいと思うデータサンプルのタイプについての情報とともに、DST作成要求をDSCSエージェント1に送信する。特に、メッセージは、(表1でさらに説明されるような)以下のパラメータのうちの1つ以上を含み得る。
Targeted_Region、
Data_Sample_Frequency、
RDS_Production_Schedule、および
RDS_Context。
所望のRDSに含まれるDEの各々について、要求は、このDEについての詳細を説明する以下のパラメータを有し得る。
Raw_Data_Type、
Unit、
Data_Processing_Operation、
Customized_Processing_Details、および
Quality_Requirements。
ステップ3で、ユーザ1からの情報に基づいて、DSCSエージェント1は、DST−1を作成する。DSCSエージェント1はまた、ユーザ1によって提供されないDST−1での他の情報を構成する必要があり、「DST_Users」(例えば、ユーザ1)と、「DST_Initiator」(例えば、ユーザ1)と、「Creating_DSCS_Agent_ID」(例えば、DSCSエージェント1)と、を含む。しかしながら、DST−1のステータスは、これまでDSがDST−1について識別されていないため、「DST_Status」パラメータで「実行不可能」に設定され得る。故に、DSCSエージェント1は、どのLFAがこのDST−1に関与するかを決定する。例えば、「Targeted_Region」パラメータに含まれる詳細に基づいて、DSCSエージェント1は、ユーザ1が関心のある地理的領域が、通信ネットワークスタンドポイントからのどのLFAに対応するかを見出し得る。この例では、1つのLFAのみが関与する(例えば、LFA−1)。加えて、Type_of_DSTは、DST−1が分割されないため、R−DSTの値で設定され得る。次に、DSCSエージェント1は、DST−1についてのDS識別プロセスをトリガするために、LFA−1内のLFNL上のDSCSエージェント(例えば、DSCSエージェント2)にコンタクトする必要がある。
ステップ4で、所望のDEの各々についてのユーザ1からの情報に基づいて、DSCSエージェント1は、未加工データ上で実行されるデータ処理動作のタイプ、および関連する品質要件などの他の詳細な情報とともに、DST−1についてのDS識別をトリガするために要求をDSCSエージェント2に送信する。言い換えると、この場合のDSCSエージェント2は、DST−1の「インフィールドマネージャ」である。(シナリオ1で考慮されるような)分割される予定のない所与のDSTについて、そのインフィールドマネージャは、対応するLFAでDS識別およびRDS生成を行うための中央コントローラであり得ることに留意されたい。特に、DSTが(この場合、DST−1などの)R−DSTである場合、そのインフィールドマネージャは、このDSTでの対応するDEの未加工データが(DST−1でのそれらのDEの各々についてのData_Processing_Operationパラメータで示されるようなデータ処理動作を使用して)処理され、それが、この全体のDST−1についてのRDSの生成につながる場所であり得る。
ステップ5で、DSCSエージェント1から要求を受信した後、LFA−1内のDSCSエージェント2は、所望のDSが、DST−1でのDEのすべてについて識別され得るかどうかを見るためのDS識別を行う(例えば、DSCSエージェント2は、DS識別を行うためにLFA−1内の他のLFNをコーディネート/管理し得る)。
ステップ6で、DSCSエージェント2は、DS識別結果をDSCSエージェント1に返す。この例では、所望のDSが、DST−1でのDEのすべてについて識別されていることが想定される。DS識別が失敗した(例えば、所望のDSがDST−1でのDEのすべてについて識別されていない)場合、DST作成プロセスは終了し得、DSCSエージェント1は、DST作成は成功でなかったことを(例えば、ステップ11で)ユーザ1に通知し得る。
ステップ7で、DSCSエージェント1はまた、DST−1で他の情報を構成する必要があり得、「In_Field_Manager_ID」(例えば、この例では、DSCSエージェント2)を含む。DSCSはまた、「DST_Status」パラメータで「実行可能な」DSTとしてDST−1をマークする。
ステップ8で、一旦、DST−1が完全に構成されると、DSCSエージェント1は、フィールド展開のためにDST−1をDSCSエージェント2に送信する。
ステップ9で、DSCSエージェント2は、次のRDS生成動作のためにDST−1についてワークスレッドを開始するために、ある設定または構成を行う。例えば、ユーザ1が、特定のDEについての未加工データを処理するためのコードスニペットを提供した場合、そのようなコードスニペットは、DSCSエージェント2、またはLFA−1内のLFNLによって管理される別のLFN上でインストールされ得る。
ステップ10で、DSCSエージェント2は、DST−1のフィールド展開が完了したことを確認する。
代替として、ステップ5で、DSCSエージェント1はまた、所望のDSがステップ6の間にDST−1でのDEのすべてについて識別された場合、DST−1のワークスレッドが(ステップ9のように)直接設定され得るかどうかを示し得る。この場合、ステップ8およびステップ10は、必要とされない場合がある。
ステップ11で、DSCSエージェント1は、DST−1が成功して作成され、また、ここで実行可能であることを、ある情報(例えば、DST_ID)とともにユーザ1に通知する。
第2の例では、LFAで事前対応DS識別を伴うDST作成プロセスが論じられる。この例では、LFA内のDSCSエージェントは、DST作成要求が存在しない場合でさえ、DS識別を事前に行い得る。このソリューションは、LFA内のDSCSエージェントが十分なエネルギーおよび強力な処理能力を有するか、またはDSの利用可能性が、それが予め識別され得るように頻繁に変化しないシナリオに適用可能であり得る。
図7は、LFAで事前対応DS識別を伴うDST作成プロセスのための例示的プロシージャを図示する。
前提条件として、DSCSエージェント2は、LFA−1のリアルタイムDSカタログをDSCSエージェント1に定期的に送信し得る。
ステップ1は、図6のステップ1と同じであり得る。
ステップ2は、図6のステップ2と同じであり得る。
ステップ3で、ユーザ1からの情報に基づいて、DSCSエージェント1は、DST−1を作成する。DSCSエージェント1はまた、ユーザ1によって提供されないDST−1でのいくつかの他の情報を構成する必要があり得、「DST_Users」(例えば、ユーザ1)と、「DST_Initiator」(例えば、ユーザ1)と、「Creating_DSCS_Agent_ID」と、を含む。DSCSエージェント1はまた、どのLFA(例えば、この例では、LFA−1)がDST−1で関与するかを決定し得、次いで、DSCSエージェント1は、関与するLFAのLFNL(例えば、この例では、DSCSエージェント2)から送信される最新のDSカタログをチェックし得る。このカタログに基づいて、所望のDSがDST−1でのDEのすべてについて識別され得る場合、DST−1は、「実行可能な」DSTとしてマークされ得る。DST−1が完全に構成された後、それは、フィールド展開のために、(この例では、DST−1のフィールドマネージャである)DSCSエージェント2に送信され得る。
ステップ4は、図6のステップ8と同じであり得る。
ステップ5は、図6のステップ9と同じであり得る。
ステップ6は、図6のステップ10と同じであり得る。
ステップ7は、図6のステップ11と同じであり得る。
第3の例では、DE再使用を介したDST作成が論じられる。この例では、異なるDSTがすでにDSCSエージェント上で作成されているとき、それは、DSTリポジトリでそれらのDSTをホストまたは記憶し得る。故に、作成される新しいDST(例えば、DST−100)について、それが、リポジトリで記憶される1つ以上の既存のDSTにすでに含まれるDEと重複し得ることが可能である。その結果、それらのDEは、DST−100を作成するために再使用され得、それは、再使用され得るDST−100でのそれらのDEのためにDS識別プロセスを行うためのかなりの労力を省き得る。
図8は、DE再使用を介したDST作成プロセスのための例示的プロシージャを図示する。
前提条件として、DSCSエージェント1は、すでに作成されたすべての既存のDSTを記憶する、DSTリポジトリを維持する。
ステップ1は、図6のステップ1と同じであり得る。
ステップ2は、図6のステップ2と同じであり得る。代替として、DSCSエージェント1は、リポジトリで記憶される既存のDSTをDSCSユーザがチェックおよび照会するために、アクセスインターフェースをDSCSユーザに直接提供し得る。この場合、ユーザ1は最初に、リポジトリを照会し、既存のDSTでのどのDEが再使用され得るかを整理し得る。次いで、このステップで、ユーザ1が受信したいと思う所望のRDSが何かを説明するとき、それは、既存のDSTでのどのDEが再使用されるべきかを直接示し得る。
ステップ3で、ユーザ1からの情報に基づいて、DSCSエージェント1は、DST−100を作成する。ユーザ1が、ステップ2でどのDEが再使用されるべきかを示さなかった場合、DSCSエージェント1はさらに、リポジトリを検索し、既存のDSTでのどのDEが、DST−100での必要とされたDEについて再使用され得るかを整理する。特に、各DEが、それがDSTで定義されるときに、いくつかの特性および品質要件を有するため、既存のDSTでの1つのDEが、別の新しく作成されたDSTでさらに再使用され得るかどうかを評価するときに、この情報を評価することが必要であり得る。例えば、ユーザ1について作成されるDST−100が3つのDEを有する(例えば、DST−1のRDSが以下のフォーマット、すなわち、(DE−1、DE−2、DE−3、RDS_Context)を有する)ことを想定して、DSTリポジトリでは、すべての特性および品質要件が一致しているため、既存のDST−1でのDE−6は、DST−100でのDE−2として再使用され得、一方、DST−3でのDE−27は、DST−100でのDE−3として使用され得ることが可能である。既存のDSTでのそれらの再使用されたDEのすべての詳細の説明は、DST−100に複製され得る。加えて、対応するパラメータは、DST−100でのそれらのDEの各々について構成され得る。例えば、「Reused」パラメータは、DST−100のDE−2およびDE−3について「真」で設定され得、「Reused_Info」パラメータは、DST−100でのDE−2およびDE−3についてそれぞれ、「DST−1でのDE−6」および「DST−3でのDE−27」で設定され得る。
ステップ4で、DSCSエージェント1は、既存のDSTでの利用可能でないDEが再使用され得るDE(例えば、DST−100でのDE−1)についてのみ、DS識別プロセスをさらに行い得る。このステップは、図6のステップ4〜6を含む。その一方で、「Reused」パラメータは、DST−100でのDE−1について「偽」で設定されるべきである。図8に示されるこの例では、1つのLFAのみが関与するが、一般に、DS識別プロセスはまた、以下に説明されるソリューションを使用することによって、複数のLFAで関与し得ることに留意されたい。
ステップ5は、図6のステップ7と同じであり得る。
ステップ6は、図6のステップ8〜10と同じであり得る。特に、DST−100についてのワークスレッドは、他のものによって作成され、DST−100でのそれらの再使用されたDEについてのRDSデータを生成することを担う、既存のワークスレッドを活用することによって構築され得る。
ステップ7は、図6のステップ11と同じであり得る。
第4の例では、R−DSTを介したDST作成が論じられる。前の3つの例では、DST−1の未加工データは、単一のLFA−1から生じることが想定された。この例では、DST−1の未加工データが複数のLFAから生じ得る、より高度なシナリオが考慮される。この場合、DST−1は、複数のS−DSTに分割され得るR−DSTであり得る。特に、DST−1が(例えば、図6〜図8のステップ3で)作成された後、DSCSエージェント1は、どのLFAが関与するかを見出し得、S−DSTは、関与するLFAの各々についてさらに作成され得る。各S−DSTでは、それは、それらのDEの未加工データがこのS−DSTの対応するLFAから収集される場合にのみDEを含む。
図9は、R−DST分割を伴うDST作成プロセスのための例示的プロシージャを図示する。
ステップ1で、DSCSエージェント1は、ユーザ1からDST作成要求を受信し、DST−1が作成された。このステップは、図6〜図8のステップ3に対応する。次に、DSCSエージェント1はまた、どのLFA(例えば、この例では、LFA−1およびLFA−2)がこのDST−1に関与するかを決定する。
ステップ2で、DST−1は、2つのS−DST(例えば、LFA−1についてのS−DST−1およびLFA−2についてのS−DST−2)を作成することによって、さらに分割されている。DSCSエージェント1は、DST−1、S−DST−1、およびS−DST−2で関連パラメータを構成する。例えば、S−DST−1およびS−DST−2のパラメータは、以下の例示的設定を有し得る。
DST_Initiatorについて、2つのS−DSTが、イニシエータがユーザ1であった、それらの親R−DST(例えば、DST−1)に基づいて作成されるため、それらの2つのS−DSTのDSTイニシエータもまた、ユーザ1であり得る。
DST_Usersについて、同じ理由で、それらの2つのS−DSTのDSTユーザもまた、この例では、ユーザ1であり得る。
Type_of_DSTについて、S−DST
Targeted_Regionについて、S−DST−1について、その標的領域は、LFA−1であり得、一方、S−DST−2の標的領域は、LFA−2であり得る。
Parent_DST_IDについて、S−DST−1およびS−DST−2の両方の親DST IDは、DST−1であり得る。
Creating_DSCS_Agent_IDについて、この例では、DSCSエージェント1。
Data_Sample_Frequencyについて、DST−1での対応する設定と同じである。
DST_Statusについて、DST−1での対応する設定と同じである。
RDS_Production_Scheduleについて、DST−1での対応する設定と同じである。
RDS_Production_Triggerについて、DST−1での対応する設定と同じである。
RDS_Contextについて、DST−1での対応する設定と同じである。
ステップ3aおよび3bで、各S−DSTについて、DS識別プロセスは、対応するLFA(S−DST−1についてのステップ3aおよびS−DST−2についてのステップ3b)で行われ得る。このステップについて、図6〜図8に関連して開示される方法は、完全に再使用され得る。例えば、DSCSエージェント1は、DS識別要求をLFA−1内のDSCSエージェント2に送信し得るか、またはDSCSエージェント1は、DSTリポジトリで記憶される既存のDSTでDEを再使用し得る。一旦、DS識別プロセスが行われると、DSCSエージェント1は、(例えば、実行可能としてそれらのDSTのステータスをマークするために)DST−1、S−DST−1、およびS−DST−2で関連パラメータをさらに構成し得、それらをフィールドに展開する準備ができている。
以下のステップ(例えば、LFA−1についてのステップ4〜6、およびLFA−2についてのステップ7〜9)は、いくつかのさらなる構成の追加を伴って、前の図でのDSTフィールド展開関連ステップ(例えば、図6のステップ8〜10)と同様である。代替として、LFA−1についてのステップ4〜6は、LFA−2についてのステップ7〜9と同時またはその後に行われ得る。
ステップ4で、DSCSエージェント1は、フィールド展開のために、S−DST−1をLFA−1内のDSCSエージェント2に送信する。
ステップ5で、DSCSエージェント2は、S−DST−1についてのワークスレッドを設定するための構成を行う。データがどこで処理されるかに関するいくつかのさらなる構成はまた、ステップ10で説明されるような詳細に基づいて行われる。
ステップ6で、DSCSエージェント2は、S−DST−1のフィールド展開が設定されることを通知する。
ステップ7で、DSCSエージェント1は、展開のために、S−DST−2をLFA−2内のDSCSエージェント3に送信する。
ステップ8で、DSCSエージェント3は、S−DST−2についてのワークスレッドを設定するための構成を行う。データがどこで処理されるかに関するいくつかのさらなる構成は、ステップ10で説明されるような詳細に基づいて実行され得る。
ステップ9で、DSCSエージェント3は、S−DST−2のフィールド展開が完了したことを通知する。
ステップ10で、DSCSエージェント1は、展開のために、DST−1をFN上のDSCSエージェント4に送信する。DST−1が複数のS−DSTに分割されたとき、それは、RDS生成の間に、データ処理がどのように行われるべきかを決定される必要があり得る。
一例では、DST−1は、R−DSTであり得、そのインフィールドマネージャは、FN上のDSCSエージェント4であり得る。特に、DST−1が、2つのS−DSTにすでに分割され、DS識別が、S−DST−1およびS−DST−2について行われ得るため、DST−1について開始されるDS識別プロセスは存在しない場合がある。DSCSエージェント4は、単に、あるデータ処理動作で関与し得、DST−1の最後のRDSは、DSCSエージェント4で生成され得る。
別の例では、インフィールドマネージャは、S−DST−1およびS−DST−2についてそれぞれ、DSCSエージェント2およびDSCSエージェント3であり得る。それらのインフィールドマネージャは、対応するLFA(例えば、LFA−1およびLFA−2)でそれぞれ、S−DST−1およびS−DST−2についてのDS識別プロセスを担い得る。しかしながら、S−DSTでの特定のDEについて、DE−1についてのRDS生成プロセスを行うことは、以下の3つのケース(例えば、ケース1、ケース2、およびケース3)のうちの1つ以上を含み得る。
ケース1では、DEのData_Processing_Operationパラメータは、S−DSTで設定されており、このS−DST−1のインフィールドマネージャはまた、このDEの未加工データが「完全に処理」される場所であり得る。これは、インフィールドマネージャが、単にこのDEを含む不完全なRDSを生成し得ることを意味する。その後、このS−DSTのインフィールドマネージャは、それらの不完全なRDSを、その親R−DSTのインフィールドマネージャに送信し得、ここで、R−DSTの最後のRDSが、異なるLFAから収集されるそれらの不完全なRDSのアセンブリングによって生成され得る。
図10は、ケース1についての例示的実装を示す。この例では、DST−1は、2つのDE(例えば、DE−1およびDE−2)を有する。例えば、DST−1のRDSは、(DE−1、DE−2、RDS_Context)の形態を有する。特に、DE−1およびDE−2はそれぞれ、最後の3分でのLFA−1およびLFA−2の最大温度である。故に、DST−1は、2つのS−DST(例えば、S−DST−1およびS−DST−2)に分割されている。それらの2つのS−DSTは、LFA−1内のDSCSエージェント2およびLFA−2内のDSCSエージェント3上で展開されている。R−DST(例えば、DST−1自体)は、よりハイレベルのFN上のDSCSエージェント4上で展開される。DE−1およびDE−2は、単に、それぞれのLFAで最大温度を計算するために使用され得るため、LFA−1およびLFA−2から収集される未加工データはそれぞれ、DSCSエージェント2およびDSCSエージェント3によって完全に処理され得る。言い換えると、それぞれのLFAでの最大温度は、DSCSエージェント2またはDSCSエージェント3で直接計算され得る。次いで、DSCSエージェント2は、不完全なRDS(例えば、DE−1パートについての完全に処理されたデータ)を(DSCSエージェント3と同じ)DSCSエージェント4に送信し得る。最後に、DSCSエージェント4は、RDS_Contextでの情報に基づいて、DSCSエージェント2からの1つのピースのデータおよびDSCSエージェント3からの1つのピースのデータのアセンブリングによって、DST−1の各単一のRDSを生成し得る。
ケース2では、DEのData_Processing_Operationパラメータは、S−DSTで設定されており、そのインフィールドマネージャは、未加工データ上で、あるデータ処理を行い得る。しかしながら、未加工データは、単に、「部分的に処理」され得る。その後、このS−DSTのインフィールドマネージャは、部分的に処理されたデータを、その親R−DSTのインフィールドマネージャに送信し得、そこから、最後のRDSが、異なるLFAから収集される、部分的に処理されたデータをさらに処理することによって生成され得る。
図11は、ケース2についての例示的実装を示す。この例では、DST−1は単に、1つのDE(例えば、DE−1)を有し、DST−1のRDSは、(DE−1)の形態を有する。特に、DE−1は、最後の3分での(LFA−1およびLFA−2によってカバーされる)全体のダウンタウンエリアの最大温度である。この場合、DST−1はまた、2つのS−DST(例えば、S−DST−1およびS−DST−2)に分割されている。それらの2つのS−DSTは、LFA−1内のDSCSエージェント2およびLFA−2内のDSCSエージェント3上で展開されている。R−DST(例えば、DST−1自体)は、よりハイレベルのFN上のDSCSエージェント4上で展開される。DE−1は、LFA−1およびLFA−2の両方をカバーする全体のエリアについて最大温度を計算するため、LFA−1およびLFA−2から収集される未加工データはそれぞれ、単に、DSCSエージェント2およびDSCSエージェント3によって部分的に処理され得る。例えば、DSCSエージェント2は、単にLFA−1の最大温度を計算し得る、LFA−1から収集される未加工データを処理し得、当該最大温度は、これが(DSCSエージェント3と同じ)全体のエリアについての最大温度でないため、部分的に処理されたデータである。DSCSエージェント4で、さらなるデータ処理が、収集された、部分的に処理されたデータに基づいて必要とされ得る。例えば、同じ時間間隔でLFA−1およびLFA−2から収集される2つの最大温度データを考慮すると、それらの2つの値の間の最大のものは、DE−1についての完全に処理されたデータであり得る、全体のエリアについての最終の最大温度であり得る。
ケース3では、DEのData_Processing_Operationパラメータは、S−DSTで設定されておらず、そのインフィールドマネージャは単に、このDEのすべての未加工データを、例えば、よりハイレベルのフォグノード上でのDSCSエージェントであり得る、その親R−DSTのインフィールドマネージャに転送し得る。言い換えると、すべての未加工データは、R−DSTのインフィールドマネージャで処理され得る。
図11に示されるようなケース2と同じ例を依然として使用する。このとき、DSCSエージェント2およびエージェント3は、十分なデータ処理能力を有しない場合がある。故に、S−DST−1およびS−DST−2でのDEのData_Processing_Operationパラメータは設定されない場合がある。そのような構成を介して、DSCSエージェント2およびエージェント3は、任意のデータ処理に関与しない場合がある。その代わり、それらは、すべての未加工データをDSCSエージェント4に直接転送し得る。DSCSエージェント4は、すべてのデータ処理を行うものであり得、DST−1についてのRDSを生成し得る。
一般に、DSCSエージェント4は、フォグ階層でLFNよりも高い任意のノード上でホストされ得る。一例では、DSCSエージェント4は、ルートCNノードで同等であり得る(この場合、DSCSエージェント4は、DSCSエージェント1と同じである)。全体として、DSCSエージェント4を可能な限り多くエッジに展開する利点は、潜在的処理および通信オーバーヘッドを省くためにローカル/分散されたデータ処理を可能にすることである。
図9に戻る。
ステップ11で、FN上のDSCSエージェント4は、DST−1についてのワークスレッドを設定するための構成を行う。
ステップ12で、DSCSエージェント4は、DST−1のフィールド展開が完了したことを通知する。このステップの後、DSCSエージェント1は、DST−1が成功して作成され実行可能であることをDST−1のユーザに通知し得る。
図9〜図11は、DSCSユーザがクラウド側からであり、一方、IoT未加工データ収集および処理がLFAで行われる、例示的シナリオを使用したことに留意されたい。ユーザがLFAと直接相互作用し得る、追加のまたは代替のシナリオが使用され得ることが理解される。例えば、移動車両内で座っているユーザは、いくつかのリアルタイムのシティの気象および汚染分析/監視チャートを見たいと思う場合がある。この場合、それは、所望のRDSを収集するために、ロードサイドユニット上でホストされるDSCSエージェントに要求を直接送信し得る。ユーザは、それらのRDSデータサンプル収集要求をLFA内のDSCSエージェントに直接送信し得る。
どのDST作成アプローチが採用されても、DS識別は、DSTについて所望のDSを識別し得る重要なプロセスであることが理解される。DSTは、所望のDSがこのDSTでのすべてのDEについて識別され得る場合にのみ、実行可能なステータスにあり得る。特に、所与の実行可能なDSTについて、DSCSエージェントは、フィールドでのDSの利用可能性に対する動的な変化が存在し得るという事実を考慮して、すべての識別されたDSが依然として、利用可能であり、および/または所望の品質要件を満たすかどうかを追跡することを維持する必要があり得る。そうでない場合、実行可能なDSTが実行不可能なDSTになり得、新しいDS識別が行われる必要があり得る。
DST更新および削除プロセスのためのいくつかのソリューションが開示される。DST(およびその関連S−DST)が更新/削除される場合、このDSTは最初に、「実行可能な」ステータスにあり、「有効な」ステータスにないようにする必要があり得ることに留意されたい。言い換えると、有効なDSTは最初に、このDST上で任意のDST更新/削除プロセスを行う前に無効にされる必要があり得る。
図12は、1つ以上の新しいDEを既存のDST(例えば、DST−1)に追加するために、DST更新プロセスのための例示的プロシージャを図示する。この例はまた、既存のDSTでのいくつかの情報を更新するために使用され得ることに留意されたい。
前提条件として、DST−1は、ユーザ1によって作成されており、DST−1のRDSは、2つのDE(例えば、DE−1およびDE−2)を有する。DST−1は、2つのS−DST(例えば、S−DST−1およびS−DST−2)に分割されており、それは、(図12に図示しない)LFA−1内のDSCSエージェント2およびLFA−2内のDSCSエージェント3上で展開された。特に、S−DST−1は、DE−1パートに関連するRDSを生成することを担い、一方、S−DST−2は、DE−2パートに関連するRDSを生成することを担う。
ステップ1で、新しい必要性に起因して、ユーザ1は、1つ以上の新しいDEを既存のDST−1に追加することを意図する。例えば、既存のDE−1およびDE−2に加え、ユーザ1はまた、DE−3およびDE−4をDST−1に追加したいと思う。言い換えると、更新されたDST−1のRDSは、(DE−1、DE−2、DE−3、DE−4、RDS_Context)の形態を有し得る。
ステップ2で、ユーザ1は、必要な情報とともに、DST更新要求をDSCSエージェント1に送信する。特に、メッセージは、(例えば、表1に示されるような)以下の関連パラメータを含み得る。
DST_IDについて、このパラメータは、どの既存のDSTが更新されるかを示す。
Targeted_Regionについて、追加される新しいDEが標的領域の変化につながる場合、このパラメータはまた、更新される必要があり得る。例えば、DST−1でのこのパラメータにすでに含まれたLFA−1およびLFA−2に加え、追加される新しいDEのパートがLFA−3から収集され得るため、新しいLFA−3が関与し得る。
追加されるDEの各々は、このDEについての詳細を定義する以下のパラメータを有し得る。
Raw_Data_Type、
Unit、
Data_Processing_Operation、
Customized_Processing_Details、および
Quality_Requirements。
新しいDEを追加する代わりに、ユーザ1は、単に、(例えば、新しいDEを追加するのではなく、)既存のDSTでのいくつかの情報を更新したいと思い得る。この場合、メッセージは、以下の関連パラメータを含み得る。
DST_IDについて、このパラメータは、どの既存のDSTが更新されるかを示す。
New_Parameter_Valuesについて、これは、更新されるパラメータおよびそれらの新しい値を含む。
ステップ3で、DSCSエージェント1は最初に、DST−1(およびその関連S−DST)が「有効な」ステータスにあるかどうかをチェックする。そうである場合、DSCSエージェント1は最初に、DST−1(およびその関連S−DST)を無効にする必要があり得る。次いで、異なるアプリケーションシナリオに基づいて、DSCSエージェント1は、それらの新しいDEを追加するために適切な動作をさらに行い得る。一般に、以下に詳述されるような2つの例示的ケースが存在し得る。
ケース1では、DST−1は、以下のシナリオについて更新され得る。
DST−1は、LFA内のDSCSエージェントが単に、DST作成要求が存在するときにDS識別を行い始める、上述のようなシナリオ1の下作成された。この場合、DS識別のための図6に示されるプロシージャのステップ3〜6は、追加される新しいDEについて行われ得る。
DST−1は、DST作成要求が存在しない場合でさえ、LFA内のDSCSエージェントが事前にDS識別を行い得る、上述のようなシナリオ2の下作成された。この場合、DS識別のための図7に示されるプロシージャのステップ3は、追加される新しいDEについて行われ得る。
DST−1は、DSTリポジトリが存在し、既存のDSTでの1つ以上のDEが潜在的に再使用され得る、上述のようなシナリオ3の下作成された。この場合、DS識別のための図8に示されるプロシージャのステップ3〜5は、追加される新しいDEについて行われ得る。
DST−1は、DSTが複数のS−DSTに分割され得る、上述のようなシナリオ4の下作成された。この場合、DS識別のための図9に示されるプロシージャのステップ3は、追加される新しいDSについて行われ得る。図12に示されるステップ3の後の残りのステップが主に、このシナリオに基づくことに留意されたい。例として、DE−3についての未加工データがLFA−2から収集され得ることが想定される。故に、既存のS−DST−2は、新しく追加されたDE−3を組み込むことによって更新され得、更新されたS−DST−2はまた、S−DST−2のインフィールドマネージャに展開される必要があり得る。その一方で、DE−4についての未加工データが新しいLFA−3から収集され得るため、新しいS−DST−3が作成され得る。故に、S−DST−3は、フィールド展開のために、LFA−3でDSCSエージェント5に送信され得る。加えて、現在、DST−1は、3つのS−DSTに分割されているため、DST−1自体もまた更新される必要があり得、更新されたDST−1もまた、フィールド展開のために、DSCSエージェント4に送信される必要があり得る。
ケース2では、DST−1は、更新されない場合がある。DST−1が、ユーザ1からのDST更新要求に起因して更新されない場合があることは、着目に値する。DST−1は、現在、複数のユーザによって(例えば、ユーザ1によってだけでなく)使用されている場合があることが可能であり得る。故に、DST−1が、他のものが認識することなく修正される場合、更新されたDST−1によって生成されるRDSは、ユーザ1以外のユーザによって理解されない場合がある。この場合、ケース1に示されるような任意の動作を行う前に、以下の動作が最初に実行される必要があり得る。
DSCSエージェント1は、DST−1のDST_Usersパラメータで示されるようなDST−1のすべてのユーザでチェックする必要があり得る。DST−1は、すべてのユーザがDST−1を更新することに同意する場合にのみ更新され得る。
DST−1のユーザのすべてがDST−1を更新することに同意しているわけではない場合、この更新要求は拒絶され得る。代替として、別の高度なソリューションは、新しいDST−2を作成することであり、それは、DST−2のDST_Usersパラメータが単にユーザ1を含み得る(ユーザ1はまた、DST−1のユーザリストから削除され得る)ことを除いて、DST−1の正確なクローンであり得る。次いで、新しいDEは、DST−2に追加され得る。この新しく作成されたDST−2で、DSCSエージェント1は、DST−2を複数のS−DSTにさらに分割し得る。故に、DST−2のそれらのS−DSTを展開するとき、それらの対応するワークスレッドは、関連LFAのインフィールドマネージャによって設定され得る。DST−2での所与のS−DST−Xについて、特定の実装に応じて、DST−1でのS−DST−Xのワークスレッドは、完全に再使用され得、(それらの2つのS−DSTは正確に同じであるため)必要とされる新しいワークスレッドがない場合がある。しかしながら、DST−2でのS−DST−Xが、DST−1でのS−DST−Xと比較して、新しいDEを有する場合、新しいワークスレッドは、DST−1でのS−DST−Xの既存のワークスレッドに基づいて構築され得る。
新しいDEを追加する代わりに、ユーザ1は、単に、(例えば、1つ以上のDEを追加するのではなく、)既存のDSTでのいくつかの情報を更新したいと思い得る。この場合、上記のソリューションもまた再使用され得る。例えば、ユーザ1が、DST−1のData_Sample_FrequencyパラメータまたはDST−1でのDE−1のQuality_Requirementsを更新することを意図する場合、それはまた、それらのパラメータの新しい値に準拠するために、行われる新しいDS識別プロセスをトリガし得る。一旦、それらのパラメータが更新された状態になると、更新されたDST−1は、再び展開され得、その結果、DST−1の対応するワークスレッドは、最新の/更新されたDST−1に従って機能し始め得る。しかしながら、それらのパラメータに対する更新を、DST−1が現在、他のユーザによって共有されているという事実に起因して行うことができない場合、更新要求が拒絶され得るか、または新しいDSTが作成され得、それは、上述のようなそれらのパラメータの新しい値を含む。
ケース1に関連して1つ以上の新しいDEを追加するとき、ステップ4〜6は、DST−1が、ステップ3の間に1つ以上のDEを追加することによって更新された状態になったことを想定するステップを図示する。
ステップ4で、DSCSエージェント1は、更新されたS−DST−2を、1つ以上の新しく追加されたDEが含まれたLFA−2内のDSCSエージェント3に展開する。図9でのステップ7〜9は、再使用され得る。
ステップ5で、DSCSエージェント1は、新しいS−DST−3をLFA−3内のDSCSエージェント5に展開する。
ステップ6で、DSCSエージェント1は、更新されたDST−1を、新しく追加されたDEのすべてが含まれたFN上のDSCSエージェント4に展開する。同様に、図9でのステップ10〜12は、再使用され得る。
ケース2について、DST−1を更新することができず、新しいDST−2がステップ3の間に作成される場合、行われる必要があり得るのは、新しく作成されたDST−2およびその関連S−DSTを適切なLFAまたはFNに展開することである。この場合、DST更新プロセスは、DST作成プロセスに変えられる。
ステップ7で、DSCSエージェント1は、DST−1が更新されたことを通知する。または、新しいDST−2がステップ3の間に作成される場合、DSCSエージェント1は、新しいDSTがその新しい必要性を供給するために作成されることをユーザ1に知らせ得る。前にDST−1がステップ3の前に「有効な」ステータスにあった場合、DST−1は、再び有効にされ得る。
既存のDSTで1つ以上のDEを削除するか、または全体のDSTを削除するためのDST更新プロセスが開示される。開示されるソリューションは、DST作成プロセスの間に、論じられるような異なるシナリオに適用され得ることに留意されたい。
図13は、既存のDSTで1つ以上のDEを削除するために、DST削除プロセスのための例示的プロシージャを図示し(このプロシージャはまた、全体のDSTを削除するために使用され得る)、詳細な説明は、以下のように論じられる。
前提条件として、DST−1は、ユーザ1によって作成されており、DST−1のRDSは、4つのDE(例えば、DE−1、DE−2、DE−3、およびDE−4)を有することが想定される。DST−1は、2つのS−DST(S−DST−1およびS−DST−2)に分割されており、それは、LFA−1内のDSCSエージェント2およびLFA−2内のDSCSエージェント3上で展開された。特に、S−DST−1は、DE−1についてのRDSを生成することを担い、一方、S−DST−2は、DE−2、DE−3、およびDE−4についてのRDSを生成することを担う(完全なRDSは、FN上のDSCSエージェント1によってアセンブルされ得る)。DST−1およびS−DST−2は、図13に示される例での主要な焦点である。
ステップ1で、新しい必要性に起因して、ユーザ1は、既存のDST−1から1つ以上のDEを削除することを意図する。例えば、ユーザ1は、DST−1からDE−3およびDE−4を削除したいと思う。
ステップ2で、ユーザ1は、必要な情報とともに、DST削除要求をDSCSエージェント1に送信する。特に、メッセージは、(例えば、表1に示されるような)以下の関連パラメータを含み得る。
DST_IDについて、このパラメータは、どの既存のDSTが更新されるかを示す。
Deletion_Listについて、これは、削除されるDEのリストである。全体のDSTが削除される場合、このパラメータは、「すべて」に設定され得る。
ステップ3で、DSCSエージェント1は最初に、DST−1(およびその関連S−DST)が「有効な」ステータスにあるかどうかをチェックする。そうである場合、DSCSエージェント1は最初に、DST−1(およびその関連S−DST)を無効にする必要があり得る。異なるアプリケーションシナリオに基づいて、DSCSエージェント1は、それらのDEを削除するために適切な動作をさらに行い得る。一般に、削除リスト内の所与のDEについて、それは、以下の3つのケースを有し得る。
ケース1について、DST−1でのDE(例えば、DE−3)は削除され得、対応する動作は対応するLFAで行われる必要がある。これは、以下の可能性のあるシナリオで発生する。
1.ユーザ1は、DST−1の唯一のユーザであり、その一方で、DE−3は、任意の他のDSTで再使用されることはない。または、
2.ユーザ1は、DST−1の唯一のユーザであり、このDE−3は、別のDSTで最初に作成された、再使用されたDEである。この場合、DE−3を削除することによって、DST−1およびS−DST−2を更新し、更新されたS−DST−2をLFA−2内のDSCSエージェント3に展開することが必要であり得る。
ケース2について、DST−1でのDE(例えば、DE−4)を削除することはできず、新しいDSTが作成される。これは、DST−1が、現在、複数のユーザによって(例えば、ユーザ1によってだけでなく)使用され得るシナリオで発生する。故に、DST−1が、他のものが認識することなく修正される場合、更新されたDST−1によって生成されるRDSは、ユーザ1以外のユーザによって理解されない場合がある。この場合、上記に示されるような任意の動作を行う前に、以下の動作が最初に実行される必要がある。
DSCSエージェント1は、DST−1のDST_Usersパラメータで示されるようなDST−1のすべてのユーザでチェックする必要がある。DST−1は、すべてのユーザがDST−1を更新することに同意する場合にのみ、それらのDEを削除するために更新され得る。
DST−1のユーザのすべてがDST−1からDEを削除することに同意しているわけではない場合、削除要求は拒絶され得る。代わって、別のソリューションは、新しいDST−2を作成することであり、それは、DST−2のDST_Usersパラメータが単にユーザ1を含み得る(ユーザ1はまた、DST−1のユーザリストから削除され得る)ことを除いて、DST−1の正確なクローンであり得る。次いで、関連DEは、DST−2から削除され得る。この新しく作成されたDST−2で、DSCSエージェント1は、さらに、DST−2を複数のS−DSTに分割し、フィールド展開のためにそれらを送信し得る。
ケース3について、DST−1でのDEを削除することはできない。これは、ユーザ1がDST−1の唯一のユーザであるが、このDEが他のDSTで再使用されているシナリオで発生する。この場合、特にこのDEについて行われる必要がある動作はない。
全体として、DSCSエージェント1は、削除されるDEの各々をチェックし得る。それらのいずれか1つが上述のようなケース2となる場合、新しいDSTが作成され得る。そうでない場合、削除されるすべてのDEがケース1またはケース3となる場合、オリジナルS−DST−2は、削除されるそれらのDEの各々について適切な動作を行うことによって、それに応じて修正され得る。
ユーザ1が全体のDST−1を削除(例えば、すべてのDEを削除)したいと思うケースについて、全体のDST(および対応するワークスレッド)は、すべてのDEがケース1となる場合に実際に削除され得る。そうでない場合、それは、上記のケース2およびケース3で言及されるようなソリューションに従い得る。
ステップ4〜5は、DST−1(およびS−DST−2)がステップ3の間に更新されたことを想定するステップを図示する。
ステップ4で、DSCSエージェント1は、フィールド展開のために、更新されたS−DST−2をLFA−2内のDSCSエージェント3に送信し、S−DST−2の既存のワークスレッドはまた修正され得、その結果、S−DST−2について作成されるRDSデータは、削除されたDEを含まない場合がある。
ステップ5で、DSCSエージェント1は、フィールド展開のために、更新されたDST−1をFN上のDSCSエージェント4に送信する。
新しいDST−2がステップ3の間に作成された場合、DST−2およびその関連S−DSTを適切なLFAに展開することが必要であり得、DST作成プロセスのためにすべての前のプロシージャは再使用され得る。言い換えると、この場合、DST削除プロセスは、DST作成プロセスに内部で変えられる。
ステップ6で、DSCSエージェント1は、DST−1でのDEのうちの1つ以上が削除されたことを通知する。または、新しいDST−2がステップ3の間に作成される場合、DSCSエージェント1は、新しいDSTがその必要性に基づいて作成されることをユーザ1に知らせ得る。
所与のDST−1について、ユーザ1が、同時に1つ以上の既存のDEを削除しながら、1つ以上の新しいDEを追加したいと思い得ることは、着目に値する。そのようなケースについて、図12および図13で開示されるようなプロシージャは、一緒に統合され得る。例えば、図12および図13でのステップ2について、ユーザ1は、それが、1つ以上のDEをDST−1に追加するだけでなく、DST−1から1つ以上のDEを削除する必要があることを直接示し得る。そのようなDST更新要求を受信した後、DSCSエージェント1は、DEの追加およびDEの削除の両方のために、図12および図13で行われる動作を組み合わせ得る。このようにして、ユーザ1は、単に、1つのDST更新要求を送り出し得、DSCSエージェント1は、図12および図13で導入されるようなすべての必要とされる動作を完了し得る。
作成されたDSTについて、それが、そのインフィールドマネージャに展開された後、それは依然として、有効なDSTではない場合がある。特に、DSTのRDS生成プロセスは、このDSTが有効にされるまで開始されない。図14は、DSTステータスの状態マシンモデルを示す。例えば、DSTが作成されたとき、それは、「実行不可能な」ステータスにあり得る。DS識別がこのDSTについて成功して行われ得る場合、それは、「実行可能な」ステータスに変更され得る。同様に、実行可能なDSTについて、その所望のDSのいずれかが失われた状態になるか、またはもはや利用可能でない場合、このDSTは、「実行不可能な」ステータスに戻り得、さらなるDS識別が行われる必要があり得る。その一方で、DST有効化動作を介して、実行可能なDSTは、実際のRDS生成が開始することを意味する「有効な」ステータスにあり得る。
一般に、以下のようにリストされる(網羅的なリストではない)、DSTを有効にするためのいくつかの方法が存在する。
(1)所与のDSTが、「RDS_Production_Schedule」パラメータで示されるようなパラメータに基づいて有効にされ得る。図6に示される例として、一旦、DST−1がLFA−1内のDSCSエージェント2に展開されると、このエージェントは、DST−1についてRDS生成スケジュールを知っている状態になり得、故に、DSCSエージェント2は、このスケジュールに基づいて、DST−1の対応するワークスレッドを有効にし得る。その一方で、DSTが有効または無効にされる度に、Creating_DSCS_Agent(例えば、図6に示されるようなCNでのDSCSエージェント1)上でホストされるDST−1のDST_Statusパラメータはまた、その最新のステータスを反映するために更新される必要があり得る。
その一方で、所与のDSTが分割された場合、上記のプロセスはまた、それに従って行われ得る。図10に示される別の例として、DST−1は、2つのS−DST(例えば、S−DST−1およびS−DST−2)に分割されている。故に、すべての対応するワークスレッド(FN上のDST−1、LFA−1内のLFNL上のS−DST−1、およびLFA−2内のLFNL上のS−DST−2についてのそれ)はまた、親R−DST(例えば、DST−1)での「RDS_Production_Schedule」パラメータに基づいて有効または無効にされ得る。
この場合、ユーザがDSTを作成しているとき、それは、DST作成要求を送信するときにそのRDS送信アドレスを直接提供し得る(次いで、それは、「RDS_Sending_Address_List」パラメータに含まれ得る)。後に、別のユーザもまたこの全体のDSTを再使用したいと思う場合、この新しいユーザは、単に、そのIDをこのDSTの「DST_Users」に追加することによって、要求をDSCSエージェントに送信し、また、それ自体のRDS送信アドレスを「RDS_Sending_Address_List」パラメータに追加し得る。
(2)所与のDSTが、ユーザ自体からの信号に基づいて有効にされ得る。図6に示される例として、「RDS_Production_Schedule」パラメータが任意の値で設定されなくてもよいことが可能である。故に、ユーザ1は、トリガ要求をDSCSエージェント1に送信し得、それは、DST−1のワークスレッドを有効にするために、トリガ要求をLFA−1内のDSCSエージェント2にさらに転送し得る。代替として、DSCSエージェント1自体は、RDS_Production_Triggerパラメータで規定されるような、あるイベントに基づいて、トリガ要求をDSCSエージェント2に送信し得る。例えば、1つのトリガは、DST−1の任意のユーザがシステム内にログインしている限り、DST−1が有効にされ得ることであり得る。無効化は、逆の方法で行われ得る。
DSTが、DST_Usersパラメータで示されるような複数のユーザによって共有されるケースでは、それは、DSTを有効または無効にするための以下の機構を有し得る。
(表1に含まれるような「DST_Status」パラメータによって示されるように)現在有効にされていない所与のDST−1について、ユーザ1は、上述のようなトリガを送信することによって、このDST−1を直接有効にし得る。特に、このユーザは、そのRDS送信アドレスを、表1に示されるような「RDS_Sending_Address_List」パラメータに追加し得る。
後で、DST−1の別のユーザ2もまた、DST−1についてのRDSを受信したいと思う場合、DST−1がすでに「有効な」ステータスにあるため、ユーザ2は、単に、そのIDをこのDSTの「DST_Users」に追加し、そのRDS送信アドレスを、表1に示されるような「RDS_Sending_Address_List」パラメータに追加し得る。
後で、ユーザ1が、今のところDST−1についてのRDSを受信したいと思わない場合、それは、どれくらい多くのユーザが、現在、「RDS_Sending_Address_List」パラメータを調べることによって、DST−1のRDSを受信しているかをチェックし得る。ユーザ1が、現在RDSを受信している唯一のユーザではない場合、ユーザ1は、単に、表1に示されるような「RDS_Sending_Address_List」パラメータからそのRDS送信アドレスを除去し得る。ユーザ1が、DST−1についてのRDSを受信したいと永久に思わない場合、ユーザ1は、「DST_Users」パラメータからそのIDをさらに除去し得る。
ユーザ2が、今のところDST−1についてのRDSを受信したいと思わない場合、それは、どれくらい多くのユーザが、現在、「RDS_Sending_Address_List」パラメータを調べることによって、DST−1のRDSを受信しているかをチェックし得る。それは、ここで、DST−1のRDSを現在受信している唯一のユーザであることを見出すため、ユーザ2は、表1に示されるような「RDS_Sending_Address_List」パラメータからそのRDS送信アドレスを除去するだけでなく、このDST−1を実際に無効にし得る(言い換えると、DST−1は、このときに実際に無効にされ得る)。ユーザ2が、DST−1についてのRDSを受信したいと永久に思わない場合、ユーザ2は、「DST_Users」パラメータからそのIDをさらに除去し得る(特に、「DST_Users」に含まれるユーザが存在しない場合、一旦ユーザ2が除去されると、DST−1は無効にされるだけでなく、その代わり、このDST−1は削除され得る)。
(3)所与のDSTもまた、(RDS_Production_Triggerパラメータで示されるような)LFAで発生するイベントに基づいて有効にされ得る。図6に示される例として、DST−1が、LFA−1でのリアルタイムの騒音レベル監視に関連するRDSを生成する場合、交通渋滞がLFA−1で検出されるときにDST−1がそのインフィールドマネージャ(例えば、DSCSエージェント2)によって有効にされ得ることが可能である。一旦、DST−1が有効にされると、DSCSエージェント2は、DST−1のDST_Statusパラメータを更新するために、CNでのDSCSエージェント1に知らせ得る。
この場合、ユーザがDSTを作成しているとき、それは、DST作成要求を送信するときにそのRDS送信アドレスを直接提供し得る(次いで、それは、「RDS_Sending_Address_List」パラメータに含まれ得る)。後に、別のユーザもまたこの全体のDSTを再使用したいと思う場合、この新しいユーザは、単に、そのIDをこのDSTの「DST_Users」に追加することによって、要求をDSCSエージェントに送信し、また、それ自体のRDS送信アドレスを「RDS_Sending_Address_List」パラメータに追加し得る。
DSTステータスが変更される度に、その最新のステータスは、DSTでの「DST_Status」パラメータで反映され得、フィールドマネージャはまた、ある動作を行う(例えば、それらのステータスに基づいて、それらのDSTについての対応するワークスレッドを中止/再開する)必要があり得る。
本明細書に開示される方法およびシステムは、以下に論じられるように、oneM2M機能アーキテクチャ実施形態で実装され得る。
開示されたDSCSソリューションは、図15に示されるように、oneM2Mサービス層での新しいCSFと見なされ得る。異なるタイプのM2Mノードは、IoTデバイス、M2Mゲートウェイ、M2Mサーバ、(車両、携帯電話などの)モバイルノードなどのDSCSサービスを実装し得ることを理解されたい。特に、それらのノードのための種々の/異なるハードウェア/ソフトウェア能力に応じて、それらのノードによって実装されるDSCSサービスの能力もまた、異なり得る。
定義される関連エンティティについてのoneM2M実施形態は、以下のようである。
データソース(DS)は、oneM2M AEまたはCSEであり得る。故に、AEまたはCSEによって生成される未加工データは、DS識別プロセスの間にoneM2Mリソース発見を介して識別され得る、<container>、<timeSeries>、または<flexContainer>リソースで記憶され得る。
ローカルフォグノード(LFN)は、oneM2M CSE(例えば、ASN−CSE)であり得る。
LFNリーダー(LFNL)およびフォグノード(FN)は、(MN−CSEなどの)oneM2M CSEであり得る。
クラウドノード(CN)は、(IN−CSEなどの)oneM2M CSEであり得る。
DSCSユーザは、oneM2M AE(例えば、IN−AE)であり得る。
図16に示される<dscs>と呼ばれる新しいリソースが開示される。<dscs>は、図16に図示されない、サービス層リソースのための共通属性を含む。CSEがDSCS能力を有する(例えば、DSCSエージェントがこのCSE上で実行している)場合、それは<dscs>子リソースを有し得る。すべてのDSCS関連要求は、このリソースに向けられ得る。例えば、ユーザは、DST作成要求を、CSE−1上でホストされる<dscs>リソースに送信し得る。同様に、CSE−1が、作成されたDST−1を展開することを意図するとき、それはまた、エッジで別のCSE−2によってホストされる<dscs>リソースにDST展開要求を送信し得る。
DSCSを曝すための追加のまたは代替の方法は、<CSE>リソースについて定義される「dscs_capability」と呼ばれる新しい属性を使用することであり、それは、このCSEがDSCS能力を有するかどうかを示し得る。故に、すべてのDSCS関連要求は、<CSEBase>リソースに向けて送信され得る。
新しい<dst>リソースは、DSTを表すために開示され、ここで、すべてのリソース属性は、DSTで定義されるパラメータに対応している(DSTについての詳細な定義について表1を参照)。
<dst>リソースは、表2で規定される子リソースを含み得る。
上記の<dst>リソースは、表3−1〜表3−3で規定される属性を含む。
以下のプロシージャは、<dst>リソースを作成するために使用され得る。
以下のプロシージャは、<dst>リソースの属性を読み出すために使用され得る。
以下のプロシージャは、<dst>リソースの属性を更新するために使用され得る。
以下のプロシージャは、<dst>リソースを削除するために使用され得る。
<dstTriggering>は、それが表現を有しないため、仮想リソースである。それは、<dst>リソースの子リソースである。このresourceは、親<dst>リソースを有効または無効にするために使用される。DSTの最新のステータスが、<dst>リソースの「DST_status」属性で反映されるべきであることに留意されたい。
<dstTriggering>リソースは、親<dst>リソースが作成されるときに作成される。
読み出し動作は、<dstTriggering>について適用可能でない場合がある。更新動作は、親<dst>リソースを有効または無効にするために使用され得る。
<dstTriggering>リソースは、親<dst>リソースがホストCSEによって削除されるときに削除される。削除動作は、Mca、Mcc、またはMcc’を介して適用可能でない。
GUIインターフェースは図17で開示され、それは、人間ユーザのために自らの使用に基づいてDSTを作成するために使用され得る。一般に、それらのパラメータは、(Creating_DSCS_Agentであり得る)DSCSエージェントに伝送され得、ここで、DSTは、それに従って作成され得る。言い換えると、このユーザインターフェースでのパラメータは、図6のステップ2での要求メッセージで搬送されるパラメータであり得る。見られ得るように、ユーザは、標的領域、RDS生成頻度、RDS状況などの、全体のDSTについてのいくつかの一般的な情報を規定し得る。その一方で、ユーザはまた、DSTでのDEの各々についての詳細な定義を入力し得る。ユーザが、DSTで複数のDEを有したいと思う場合、より多くの入力エリアがそれらのDEについてこのパネル上に現れ得るように、「より多くのDEを追加」ボタンをクリックし得る。
図4に示されるスマートシティユースケース例に戻って参照すると、スマートシティを構築するために、市当局は、(oneM2Mなどの)規格ベースのサービス層(SL)プラットフォームを採用し、道路/ストリート、公共ビル、バス/地下鉄などの市の公共インフラストラクチャ上に多くのIoTセンサおよびデバイスを展開している。制限された予算に起因して、市当局はまた、このスマートシティのイニシャティブのために、私的な組織および個人の関与を要求する。故に、(私的な車、携帯電話などの)私的な財産上にインストールされたそれらのIoTデバイスはまた、システム内に統合され、それは、シティのリアルタイム実行ステータスを反映する大量の広範なIoTデータを生成し得る。
シティは、中心業務地区(CBD)、郊外住宅エリアなどの多くの地理的領域を有し得、それは、ローカルフォグエリア(LFA)と称され得る。膨大なIoTデバイスが、それらのLFAで展開され得、大量のIoTデータが、それらのLFAから生成され得る。通信ネットワーク観点から、異なるシティ領域が、複数のLFAを構成する(例えば、図4に示されるように、CBDが、LFA−1に対応し、郊外住宅エリアが、LFA−2に対応する)。
スマートシティ制御コンソールは、ユーザが、必要性に基づいて種々のデータ分析要求を呈することを可能にするクラウドで展開される。例えば、組織Aからのユーザは、所与のエリアについての現在の気象および環境汚染ステータス(例えば、大規模道路工事およびビル建設下のエリアである、図4に示されるようなLFA−X)を評価することを意図する、(DSCR−1として示される)データサンプル収集要求を有する。実際には、データ分析結果は、通常は、種々のチャート(例えば、ラインチャートまたはバーチャート)を介して表される。ユーザが見ることを意図する分析チャートのタイプ(例えば、ラインチャート)に加え、ユーザはまた、データサンプルがあるべき姿、チャートを描くためにどの入力があるべきかなどを規定し得る。チャートを描くためのそれらのデータサンプルを準備するために、関連する未加工データが、データソース(DS)とも称される種々のIoTデバイスから収集される必要がある。スマートシティユースケースでは、DS例は、温度センサ、湿度センサ、汚染センサ、騒音センサなどを含む。特に、それらのセンサまたはデバイスは、(ユーザが入っている)組織A以外の異なる組織によってインストールされ得る。
DSCR−1で、ユーザがLFA−Xについてのラインチャートを見ることを意図し、それは、3分毎に1つのデータサンプルを要求することが想定され得る。特に、各データサンプルは、以下の2つのデータ要素によって構成され得、それは各々、品質要件に対応付けられる。
データ要素(DE)−1について、3分毎にサンプリングされるLFA−Xの平均温度。
DE−1の品質要件について、温度読み取り値は、精度を保証するために、LFA−Xで展開される、少なくとも100個の異なる温度センサから収集される必要がある。
DE−2について、3分毎にサンプリングされるLFA−Xの平均騒音レベル。
DE−2の品質要件について、騒音読み取り値は、LFA−Xでの30個の主要な交差点で展開される騒音センサから収集される必要がある。
クラウドで展開されるスマートシティ制御コンソール上でラインチャートを描くために、(DE−1、DE−2、タイムスタンプ)のフォーマットを有するデータサンプルは、3分毎に必要とされ得る。そのようなデータサンプルは、DSCR−1についての使用準備済のデータサンプル(RDS)と称され得る。
上記のユースケースで示されるようなRDSを生成するために、膨大なIoT未加工データが、LFAで収集され、処理される必要がある。フォグコンピューティングパラダイムは、膨大な未加工データが、中央処理のためにクラウド側に移動される必要がなく、その代わり、RDSを生成するためにLFAで処理され得るという意味において、そのようなアプリケーションをサポートするのに素晴らしく適している。
ユーザは、LFAでの利用可能なIoT DSについての知識を有しない場合がある。例えば、スマートシティユースケースでは、展開されたSLプラットフォームはまた、異なる組織および個人から多くのIoT DSを統合し得る。クラウド側からのユーザは、それらのIoT DSを展開した同じグループでない場合がある。ユーザは、多くの場合、(ゲートウェイ、ロードサイドユニットなどの)データ処理能力を有するLFA内の多くのLFNの所有者でなく、ユーザは、通常は、それらのLFNが異なるグループまたは組織によって所有され得るため、所望のデータ処理動作のためにLFA内の任意のLFNを構成するための任意の能力を有しない。(Microsoft IoT EdgeまたはAmazon Greengrassなどの)いくつかの既存のIoTエッジ製品は、そのような異種シナリオで効率的に機能することができないことは、着目に値する。例えば、それらの製品は、ユーザが、通常、利用可能なDSの完全な知識、およびLFA内の処理ノードのための完全な構成能力の両方を有する、比較的単純なケースをサポートする。
そのような異種シナリオをサポートするために、一般的なソリューションは、IoTシステムが、ユーザから種々のDSCRを受信し得る、共通データサンプル収集サービスを提供し得ることである。所与のDSCRは、ユーザが受信することを意図するRDSのタイプについてのすべての詳細を記載する。しかしながら、ユーザは、このDSCRを供給するためにLFA内で発生する任意のアクティビティに関与しない場合がある。言い換えると、ユーザは、単に、DSCRをIoTシステムに提出し得、システムは、RDSをユーザに配信するためにすべてのことを処理する。
特定のDSCRを供給するとき、2つの特定の技術的問題が考慮される必要があり得る。
DS識別プロセスについて、所与のDSCRに対応するRDSでのDEの各々について、この所与のDSCRについての所望のDSであるかどうかを判定するために発見および/または評価される必要がある(そのようなプロセスは、DS識別プロセスと呼ばれる)、LFA内の数千の潜在的DSが存在し得る。それらのDSを識別するために、発見能力を有する、あるLFNが利用され得、それは、DSディスカバラー(DSD)として機能し得る。例えば、oneM2Mシナリオでは、リソース発見能力を有する任意のAEまたはCSEは、DSDとして機能し得る。しかしながら、効率的な方法でDS識別プロセスを行うことが不可欠である。主要な課題は、DSDとして機能し得るLFA内の複数のLFNが存在し得るが、それらのLFNの各々は、異なる/制限されたDS識別能力または異なるアクセス特権を有し得ることである。例として、あるLFNは、特定の組織Aに属する、あるDSを識別し得、一方、別のLFNは単に、別の組織Bに属する、あるDSを識別し得る。それらのLFNの両方は、DSDとして機能して、特定のDSCRを援助し得、それは、2つの組織の両方から所望のDSを識別することが要求され得る。したがって、LFA内の複数のLFNは、所与のDSCRについて所望のDSを識別するために、それらそれぞれの発見能力を完全に利用および統合するように、一緒に「協働的に」機能することが必要であることが分かり得る。しかしながら、現在、異なるDSDの種々のDS識別能力を、LFAで協働的なDS識別を実現するための全体的な方法で活用することができない。
RDS生成プロセスについて、DS識別プロセスの後、(RDS生成プロセスと呼ばれる)次のステップは、所望のDSから、収集された未加工データを処理し、RDSを生成し、それらをユーザに配信する方法に向けられる。特に、DSから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理は、協働的に行われる必要があり得る。LFNは、IoT未加工データを処理し得る場合、未加工データプロセッサ(RDP)として機能し得る。しかしながら、主要な課題は、RDPとして機能し得るLFA内の複数のLFNが存在し得、それらのLFNは、異なる組織に属し得、それらのLFNの各々は、異なるおよび/または制限されたデータ処理能力を有し得る(例えば、あるものは、データ事前処理を行うだけであり得、あるものは、基本データアグリゲーション処理を行い得、一方、あるものは、高度なデータ分析処理を行い得る)ことである。したがって、LFA内の複数のLFNは、所与のDSCRについてRDSを生成するために、それらそれぞれのデータ処理能力を完全に利用/統合するために、一緒に協働的に機能することが必要であることが分かり得る。しかしながら、現在、DSCRを供給するためにLFAで協働的なRDS生成を行うためのソリューションが存在しない。
フォグベースのサービス層(SL)のための協働的なDS識別およびRDS生成のための方法およびシステムが本明細書に開始される。方法およびシステムは、以下のことを含み得るが、それらに限定されない。
協働的なデータソース(DS)識別について、DSCRに対応するRDSでのDEの各々について、このDSCRを供給するための所望のDSであるかどうかを判定するために発見および/または評価される必要がある、LFA内の数千の潜在的DSが存在し得る。データソースディスカバー(DSD)として機能し得る、LFA内の異なるローカルフォグノード(LFN)は、異なるDS識別および発見能力を有し得る。故に、1つ以上のLFA内の(DSDとしての)複数のLFNが、所与のDSCRのための所望のDSを識別するために一緒に協働的に機能することを可能にする、方法およびシステムが提供される。
所与のLFNは、DS識別能力を有し得るが、(例えば、所望の/識別されたDSからデータを収集するための)データ収集能力、または、(例えば、RDSを生成するための未加工データを処理するための)特定のデータ処理能力を有しない場合がある。したがって、本明細書に開示されるDS識別プロセスは、所与のDSCRによって要求されるようなRDSでのDEの各々について、所望のDSを識別することを指すだけでなく、RDSを生成するために未加工データを処理するための未加工データプロセッサ(RDP)として機能し得る適切なLFNを見出すことに加え、それらの識別されたDSから未加工データを収集するための未加工データコレクタ(RDC)として機能し得る適切なLFNを見出すことを指す。本明細書に開示される協働的なDS識別のためのソリューションは、RDC発見を伴うDS識別およびDS識別結果統合、ならびにRDC/RDPジョブ割り当てを含むが、それらに限定されない。
協働的なRDS生成について、RDS生成プロシージャの間、主要な作業は、収集された未加工データを処理し、RDSを生成する方法に関連する。DSから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理はまた、協働的に行われる必要があり得る。所与のDSCRについて、異なるLFNが、このDSCRのためにRDSを生成するために要求される種々のデータ処理能力を有し得るため、そのデータ処理は、複数のRDPをクロスさせ得る。本明細書に開示される協働的なRDS生成のための主なソリューションは、所与のDSCRのためのRDS生成、所与のDEのためのRDS生成、および所与のDSCRのためのRDSアセンブリングのトリガを含むが、それらに限定されない。
本開示全体を通して使用されるいくつかの用語についての例示的定義が以下に説明される。
クラウドノード(CN)について、展開階層でより下の他のフォグノードの動作を管理するクラウド能力を有するノード。本開示において、用語「クラウド」は、クラウドノードを指すために使用され得ることに留意されたい。クラウドは、アプリケーションのためのフォグサービス層を一緒に有効にする、異なるフォグノード間の相互作用を監視および管理する。
データサンプル収集要求(DSCR)について、DSCSのユーザは、DSCRでその必要性を規定し得、それは、受信することを意図するRDSのタイプについての詳細を含み得る。
使用準備済のデータサンプル(RDS)について、所与のDSCRについて、その対応するRDSは、ユーザが使うために(例えば、分析チャートを描くために)すでに使用準備済段階にあるデータサンプルを指す。RDSは、LFA内のLFNによって行われるRDS生成プロセスを介して取得され得る。例えば、所与のDSCRについて、DSCSは、フォグコンピューティングパラダイムを活用することによってRDSを生成するために、効率的なIoT未加工データ収集およびデータ処理を行い得る。スマートシティユースケース例を使用して、(最後の3分でのLFA−1の平均温度である)DSCR−1でのDE−1について、LFA−1で展開されるDSCSは、LFA−1内の関与する温度センサから未加工データを収集し、未加工データに対する平均アグリゲーション動作を行い、DSCR−1のすべてのRDSについてのDE−1パートを生成する必要がある。DSCR−1のすべてのRDSについてのDE−2パートはまた、同様の方法で生成され得る。状況整合を介して、DE−1パートについてのデータおよびDE−2パートについてのデータは、RDSを生成するために、それに従ってアセンブルされ得る。例えば、DE−1パートについての1つのピースのデータおよびDE−2パートについての1つのピースのデータは、同じ3分の時間間隔であり、これらの2つのピースのデータは、この特定の3分の時間間隔で単一の/完全なRDSを形成するように一緒にアセンブルされ得る。
データ要素(DE)について、DSCRは、何のDEがこのDSCRに対応する単一のRDSに含まれ得るか(例えば、それは、その対応するRDSがどのようなものかを説明し得る)を定義する。言い換えると、RDSは、その対応するDSCRの実際のデータサンプルインスタンスである。例として、以下の2つのDEを有するDSCR−1を考慮する。DE−1(最後の3分でのLFA−1の平均温度)およびDE−2(最後の3分でのLFA−1の平均騒音レベル)。DSCR−1のすべてのRDSは、それらの2つのDE(DE−1、DE−2、RDS_Contexts)を有し得、ここで、RDS_Contextsは、このRDSについての詳細な状況情報(例えば、この特定のRDSがどの3分の時間間隔に関連するか)を与える。
フォグノード(FN)について、計算、記憶、通信、分析などの任意のフォグリソースを有するノード。フォグノードは、これらのリソースのうちの少なくとも1つを有し得、また、フォグノード上で実行している他のソフトウェアまたはサービスを有し得る。FNは、LFNのレベルよりも高いあるレベルで展開されることが想定される。クラウドノード(CN)が最も高いレベルにある状態で、FN展開のいくつかのレベルが存在し得る。スマートシティユースケース例では、FNは、ネットワーク内のより高いレベルでのルーターであり得る。
ローカルフォグエリア(LFA)について、地理的領域(例えば、シティ)は、異なるアプリケーションシナリオに応じて複数のLFAに分割され得る。スマートシティユースケースシナリオでは、特定の住宅エリアが、LFAであり得るか、またはダウンタウンエリア内の中心業務地区(CBD)が、LFAであり得る。
ローカルフォグノード(LFN)について、LFNは、計算、記憶、および通信能力を有するLFA内のノードであり得る。LFNは、その対応するLFA内のLFNリーダー(LFNL)と通信および/または相互作用し得る。例示的LFNは、人の携帯電話、移動バス、家のホームゲートウェイなどであり得る。LFNは、ネットワークの最も低いレベルであるFNのタイプである。LFNは、同じLFA内の他のLFNと相互作用/協働し得、種々のDSからのIoTデータの発見、収集、および処理を行い得る。
LFNリーダー(LFNL)について、所与のLFAは、そのエリアでLFNリーダーを有する。LFNLは、そのLFA内のすべてのLFNのアクティビティを管理し、制御し、および/またはコーディネートするLFNであり、より高いレベルにあるFNに接続され得る。スマートシティユースケース例では、LFNLは、特定の住宅エリアの主要ゲートウェイであり得る。
DS識別プロセスについて、所与のDSCRに対応するRDSでのDEの各々について、このDSCRのための所望のDSであるかどうかを判定するために発見および/または評価される必要がある、LFA内の数千の潜在的DSが存在し得る。そのようなプロセスは、DS識別プロセスと称され得る。
RDS生成プロセスについて、RDS生成プロセスは、所望のDSから収集される未加工データを処理し、RDSを生成する方法を指す。
データソース(DS)について、ノードは、それがIoTデータのソースの場合、DSであり得る。例えば、ノードは、センサ、カメラ、交通灯、またはデータを生成する任意のIoTデバイスであり得る。ロードサイドユニットはまた、それが道路表面に関連するセンサデータを生成するため、DSであり得る。ロードサイドユニットはまた、それが、あるデータ処理能力を実行し得、および/またはLFNLと通信し得るため、LFNであり得る。一般に、センシングを有するだけでなく、コンピューティング、記憶、および通信能力を有する、LFA内のノードは、LFNおよびDSであり得る。
データソースディスカバラー(DSD)について、これは、論理的役割である。所与のLFNが、DS識別プロセスの間に所与のDSCRについてDSを発見することに関与する場合、それは、このDSCRについてのDSDと見なされ得る。
未加工データコレクタ(RDC)について、これは、論理的役割である。所与のLFNが、所与のDSCRを供給するためにいくつかのDSから未加工データを収集することに関与する場合、それは、このDSCRについてのRDCと見なされ得る。
未加工データプロセッサ(RDP)について、これは、論理的役割である。所与のLFNが、RDS生成プロセスの間に所与のDSCRについて収集された未加工データを処理することに関与する場合、それは、このDSCRについてのRDPと見なされ得る。一般に、LFNは、同時にRDC、DSD、およびRDPの複数の論理的役割を引き受け得るか、またはそれらの論理的役割は、所与のDSCRを供給するときに異なるLFNによって引き受けられ得ることに留意されたい。特に、3つの異なる論理的役割を定義することによって、異なるタスクが分離され、異なる役割によって行われ得るため、作業の協働が促進され得る。
本開示で提案されるアイディアが、フォグ関連用語を使用して説明されるが、本開示で提案されるアイディアがまた、エッジシナリオに適用され得ることは、着目に値する。例えば、LFAはまた、エッジでの特定のエリアとして解釈され得、LFNは、エッジ側でのノードであり得、LFNLは、エッジでのゲートウェイまたはエッジでのロードサイドユニットなどであり得る。
データサンプル収集サービス(DSCS)と呼ばれるサービス層のための共通サービスの2つの重要な特徴が本明細書に開示される。DSCSのハイレベルアーキテクチャが図18に示される。DSCSは、ユーザから種々のDSCRを受信し、そのユーザの代わりに、すべての詳細を処理し得る。DSCRでは、ユーザは、データサンプルに関する種々の品質要件とともに、その所望のデータサンプル(例えば、RDS)がどのようなものかを明確に表し得る。(LFN、LFNL、FN、またはCN上などの)サービス層ノードは、このノードがデータサンプル収集関連サービスを提供することを意図する場合、DSCSエージェントを有し得る。SLノード上のDSCSエージェントは、ユーザによって呈されるDSCRを供給するために、DSCSユーザと相互作用するだけでなく、他のDSCSエージェントと協働し得る、ソフトウェアのピースである。DSCSで、一旦ユーザがそのDSCRを呈すると、ユーザは、LFAで適格なDSをどのように識別するか、および未加工データ処理およびRDS生成のためにそれらのLFAでLFNをどのように構成するかに関する任意の詳細において関与する必要がない。図18に示される例として、CNでのDSCSエージェントがユーザからDSCRを受信した後、それは、どのLFAが関与するかを見出し得る。ユーザが、単に、特定のLFA(例えば、図18の左側に示されるもの)からデータサンプルを収集したいと思う場合、このDSCRの対応するタスクは、そのLFA内のLFNL上のDSCSエージェントに割り当てられ得る。このLFNLは、このLFA内のすべてのLFNによって行われるアクティビティのための中央コントローラ、マネージャ、および/またはコーディネータとして機能し得、それは、本明細書に開示される2つの特定の技術的問題(例えば、DS識別およびRDS生成)を含み得る。
協働的なデータソース(DS)識別について、DSCRに対応するRDSでの各々のDEについて、このDSCRのための所望のDSであるかどうかを判定するために発見および/または評価される必要がある、LFA内の数千の潜在的DSが存在し得る。LFA内のLFNは、異なるDS識別能力を有し得る。故に、LFA内の複数のLFNが、所与のDSCRのための所望のDSを識別するために一緒に協働的に機能し得ることが本明細書に開示される。LFN−1が、DS識別タスクに関与しており、所与のDSCR−1のための所望のDSを識別していることが想定され得る。この場合、LFN−1は、DSディスカバラー(DSD)として機能した。しかしながら、LFN−1は、その制限されたワークロード能力に起因して、このDSについて未加工データコレクタ(RDC)としてさらに機能しない場合がある。したがって、別のLFN−2がRDCとして機能する必要があり得、それは、このDSから未加工データをさらに収集することを担う。同様に、LFN−2は、このDSについて未加工データプロセッサ(RDP)としてさらに機能しない場合がある。したがって、別のLFN−3がRDPとして機能する必要があり得、それは、このDSから収集される未加工データのさらなる処理を担う。したがって、本開示で考慮されるDS識別プロセスは、所与のDSCRによって要求されるようなRDSでのDEの各々についての所望のDSの識別を指すだけでなく、それらの識別されたDSについてのRDCおよびRDPとして機能し得る適切なLFNを見出すことを指す。
協働的なRDS生成について、RDS生成プロセスの間、主要な作業は、収集された未加工データを処理し、RDSを生成し、それらをユーザに配信する方法に関連する。DSから収集される未加工データは、大量にあり得、膨大な未加工データに対するデータ処理は、協働的に行われる必要があり得る(例えば、IoTデータ処理は、所与のRDS生成プロセスの間に複数のRDPをクロスさせ得る)。例えば、RDPとして機能するLFN−1が、予期しないおよび/または大きい未加工データの到達に起因して、一時的に過負荷状態になる場合、それは、非常に軽いワークロードを現在有し、またRDPとして機能し得る、別のLFN−2にそのデータ処理のいくつかをオフロードし得る。別の例として、LFN−1が、単に、その制限されたデータ処理能力に起因して、ある単純なデータ処理を行うことができる場合、それは、深層データ処理のために、その事前処理されたデータを別のより強力なRDP(例えば、LFN−2)に送信し得る。
本明細書に開示される方法およびシステムを使用して、異なるLFNが、DS識別プロセスまたはRDS生成プロセスに関与する異なる役割を行い得る。例えば、DSDとして機能するLFNは、所望のDSを発見するために一緒に機能し得る。他のノードは、(DS識別プロセスの間に識別される)所望のDSから未加工データを収集し、未加工データを処理し、RDSを生成するために、RDCおよび/またはRDPとしてさらに機能し得る。
開示された方法はまた、異種フォグシナリオでのダイナミクスおよび不確実性を説明することは、着目に値する。例えば、異なるLFNは、異なる組織に属し、異なる主な使用目的を有し得るため、LFNがDS識別またはRDS生成に関連する特定のタスクに関与し、それに寄与し続けるための厳しい要件は存在しない。したがって、所与のタスクで、異なるLFNからの能力は、協働的な方法でそれらのLFN作業をするように一緒に統合される必要があり得る。
図18(さらに本開示の他の図)は、クラウドでのユーザが、DSCRを、CNでのDSCSエージェントに送信することを示す。追加でまたは代替で、ユーザがLFAから生じ得、そのような場合、ユーザが、DSCRを、それらのLFA内の対応するLFNL上でDSCSエージェントに送信し得ることが理解される。本開示での提案されたプロシージャおよびソリューションはまた、このケースをサポートする。
LFN能力登録プロシージャでは、所与のLFA内のLFNLは、LFA内のLFNのすべてのアクティビティを管理またはコーディネートすることを担い得る。故に、LFNLの管理作業を促進するために、LFNの各々は、それらが、DS識別およびRDS生成に関連する任意のタスクに関与し得る前に、最初に、その潜在的能力をLFNLに報告および/または登録する必要があり得る。異なるLFNの能力/機能性の利用は、それらの能力が異なるDSCRを供給するときに共有され得るため最大化され得る。追加でまたは代替で、同じ能力を有する複数のLFNが統合され得、それは、DS識別およびRDS生成プロシージャを行うときにスケーラビリティを向上させ得る。
LFNリーダーへのLFN能力登録のための例示的プロシージャは、図19に示され、以下に論じられる。
前提条件として、LFN−1が、LFNL−1であるLFA−1内のLFNLを識別し得、それは、任意の既存の技術に基づき得ることが理解される。例えば、LFNL−1は、それがこのLFA内のLFNLとして選択されていることを請求するために、LFA−1内のすべてのLFNにブロードキャストし得る。
ステップ1で、LFN−1上のDSCSエージェント2は、DS識別およびRDS生成に関連する将来のタスクに関与するために、LFN−1の能力を、LFNL−1上のDSCSエージェント1に登録することを意図する。
ステップ2で、DSCSエージェント2は、登録要求をDSCSエージェント1に送信し、それは、LFN−1の潜在的能力および識別子についての詳細な情報を含む。LFNLに報告される情報は、LFN−1がDSD、RDC、およびRDPに関連する役割のいずれかを供給し得るかどうかを説明し得る(所与のLFNが、複数の論理的役割を供給し得ることが可能である)。以下の例示的な3つのパラメータは、LFN−1が潜在的DSDであり得るかどうかを説明する。
DSD_Capability_Listについて、このパラメータは、それをDSDとして有効にし得るLFN−1のすべての能力をリストし得る。例えば、oneM2Mシステムでは、所与のCSEは、それがoneM2M基本リソース発見能力を有する場合にDSDであり得る。追加でまたは代替で、リソース発見能力は、このパラメータに含まれ得る。このCSEが、高度なセマンティックリソース発見能力を有する場合、これらの能力は、このパラメータに含まれ得る。
DSD_Work_Schedule_Availability_Listについて、「DSD_Capability_List」でリストされるような能力の各々について、対応する作業スケジュールは、このパラメータに含まれ得る。例えば、LFN−1は、午前10時〜午後2時の間に、協働的なDS識別のために、その高度なセマンティックリソース発見能力を提供したいと思わない場合がある。これは、LFN−1が、通常、このときくらいに、それ自体の組織からの重いワークロードを有する(それは、第1の優先度を有する)ためである。
DSD_Capability_Scopeについて、このパラメータは、「DSD_Capability_List」でリストされるようなDSD能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、LFN−1が単に、あるノード上でまたはある場所で、DS識別を行い得ることを示し得る。LFN−1は単に、LFN−1と同じ組織に属するDSを識別し得ることが可能である。言い換えると、LFN−1は単に、それ自体の組織内でDSを識別し得る。別の例では、LFN−1は単に、ある地理的エリア内で(例えば、LFA−1に位置する単一のビルで)DS識別を行い得ることが可能であり得る。このパラメータで示される、そのような制限および/または制約は単に、よりきめの細かい制限および/または制約がさらに考慮される必要があり得るという意味において、きめが粗いことに留意されたい。例えば、LFN−1は、単一のビルでDS識別を行い得ることが可能であるが、このビルでの所与のDS−1について、それは、LFN−1がそのビルでそのような特定のDS−1を発見することが可能になるかどうかを定義する、さらなる発見ルールまたはポリシーを有し得る。
同様に、以下の3つのパラメータは、LFN−1が潜在的RDCであり得るかどうかを説明する。
RDC_Capabilityについて、このパラメータは、LFN−1がIoT未加工データ収集能力を有するかどうかを伝えるものである。
RDC_Work_Availability_Scheduleについて、このパラメータは、LFN−1についてのRDC能力の作業スケジュールを示す。例えば、LFN−1は、午前10時〜午後2時の間に、その未加工データ収集能力に寄与したいと思わない場合がある。これは、LFN−1が、通常、このときくらいに、それ自体の組織からの重いワークロードを有する(それは、第1の優先度を有する)ためである。
RDC_Capability_Scopeについて、このパラメータは、RDC能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、LFN−1が単に、あるノード上でまたはある場所で、未加工データを収集し得ることを示し得る。LFN−1は単に、それ自体の組織内でDSから未加工データを収集し得ることが可能である。別の例として、LFN−1は単に、ある地理的エリアで(例えば、LFA−1に位置する単一のビルで)展開されるDSから未加工データを収集し得ることもまた可能である。
同様に、以下の3つのパラメータは、LFN−1が潜在的RDPであり得るかどうかを説明する。
RDP_Capability_Listについて、このパラメータは、それをRDPとして有効にし得るLFN−1のすべての能力をリストするものである。例えば、LFN−1は、(AVERAGE、MAX、MIN動作を行うことなどの)単純なデータアグリゲーション能力をサポートし得る。故に、単純なデータアグリゲーション能力は、このパラメータに含まれ得る。LFN−1がまた、(分類、回帰、または他のマシン学習ベースのアプローチなどの)高度なデータ処理能力を有する場合、この能力はまた、このパラメータに含まれ得る。
RDP_Work_Schedule_Availability_Listについて、「RDP_Capability_List」でリストされるような能力の各々について、1つ以上の対応する作業スケジュールはまた、このパラメータに含まれ得る。
RDP_Capability_Scopeについて、このパラメータは、「RDP_Capability_List」でリストされるようなRDP能力についての任意の制限、制約、または範囲を示すために使用され得る。例えば、このパラメータは、処理のためにデータをLFN−1に送信または入力するときに特定のデータフォーマットが使用されるべきであることを示し得る。故に、入力データ(例えば、DSから収集される未加工データ)が、このパラメータに示されるような要求されたデータフォーマットに対して互換性がない場合、(例えば、LFN−2によって機能される)別のRDPは、LFN−1の前に必要とされ得、それは、最初に、オリジナル入力データを、LFN−1によって要求されるような所望のデータフォーマットに変え得る。
追加でまたは代替で、各LFNは、その地理的場所、それが入っている組織などのそれ自体についての、いくつかの他の状況情報を登録し得る。
ステップ3で、DSCSエージェント1は、将来の使用のためのLFN−1の能力を記録する。能力登録の表は、表9に示されるすべての情報の記録のためにDSCSエージェント1で利用可能であり得る。
ステップ4で、DSCSエージェント1は、成功の登録を通知する。言い換えると、DSCSエージェント1は、ここで、どのLFNがDSD、RDC、およびRDPとして機能し得るかの観点でリソースのプールを有する。故に、将来のDSCRを受信するとき、DSCSエージェント1は、それらのDSCRを供給するためにプール内のそれらのリソースを使用し得る。
LFNは、表9に示される能力登録の表についての更新にもつながり得るその能力を動的に更新(例えば、新しい能力の追加、既存の能力についての作業スケジュールの更新、能力の削除など)し得ることが可能である。更新プロシージャは、図19に示されるプロシージャと同様であり得る。
例示的な協働的なDS識別プロシージャでは、LFNLがDSCRを受信するとき(例えば、ユーザは、DSCRをCNに呈し、CNはさらに、このDSCRを関連LFNLに割り当てた)、LFNLは、このLFNLによって管理される複数のLFNによって、提供および/または登録されるDS識別能力を利用することによって、協働的なDS識別プロセスを開始し始め得る。一般に、特定の協働的なDS識別プロセスは、より詳細に以下に論じられるように、2つの段階を含む。
段階1は、RDC発見を伴うDS識別を含み得る。段階1で、主要なタスクは、特定の受信されたDSCRを供給し得る、すべての所望のDSを識別することである。所望のDSは、この特定のDSCRの対応するRDSで、未加工データを特定のDEに提供するエンティティであり得る。そうするために、LFNLは最初に、LFN能力登録の表で説明されるような情報に基づいて、DSDとして機能し得るLFNのリストを選択する必要があり得る。次いで、LFNLは、DS識別動作を協働的に行うように、それらの選択されたDSDを指定する。多くの場合、LFN−1は、DSDとして機能し、受信されたDSCRについて所望のDSを識別し得る。しかしながら、実際のRDS生成プロセスが後で開始され得るため、LFN−1は、そのときくらいにはもはや利用可能でない場合があり、したがって、別のLFN−2が、後の未加工データ収集のためにRDCとして機能することが必要とされ得る。別の可能性は、LFN−1が、その作業専門がDS識別だけであるという意味において、洗練されたDS識別能力を備える専門ノードであることである。言い換えると、LFN物理的ノード実装を促進するために、異なるLFNがそれらそれぞれの作業専門を有し得ることが可能である。故に、DSD(例えば、LFN−1)が所望のDSを識別するとき、それはまた、誰がこのDSから未加工データを読み出すことが可能であるかに関する関連情報を収集する必要があり得、そのような情報は、後の段階でこのDSについて適切なRDCを見出すのに必要とされ得る。oneM2Mを例に取ると、<container−1>リソースは、(所望のDSとしての)温度センサのすべての読み取り値を記憶する(DSDとしての)CSEによって発見されている。CSEは、この<container−1>リソースに関連するアクセス制御ポリシー(Access Control Policy:ACP)をチェックし得る。例えば、<container−1>リソースが<ACP−1>リソースで説明されるアクセス制御ポリシーを使用している場合、CSEは、どのエンティティが<container−1>リソースについて「読み出し」特権を有するかを識別するために、<ACP−1>リソースをさらにチェックし得る。LFN−1は、そのDS識別結果およびRDC候補をLFNLに送信し返し得る。
一例では、データサンプル収集サービスは、データサンプルに対応付けられる1つ以上のデータ要素を識別するデータサンプル収集要求を受信することと、データ要素のうちの少なくとも1つについて、少なくとも1つのデータ要素についての1つ以上のデータソースを識別するように構成された1つ以上のデータソースディスカバラーを判定することと、1つ以上のデータソースディスカバラーに、データ要素のうちの少なくとも1つについての1つ以上のデータソースを識別するための要求を送信することと、1つ以上のデータソースディスカバラーから、データ要素のうちの少なくとも1つについての1つ以上のデータソースを識別するデータソース識別結果を受信することと、データソース識別結果に基づいて、データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも1つを実行するように構成されたローカルフォグノードを選択することと、選択されたローカルフォグノードに、データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも1つを実行するためのインジケーションを送信することと、を含む、動作を実行するように構成され得る。
データサンプル収集要求は、データサンプルに対応付けられる情報を含み得、情報は、どのくらいの頻度でデータサンプルが生成されるべきか、データサンプル収集要求がいつ実装されるべきかについてのスケジュール、データサンプルがどこで送信されるべきかについての識別子、およびデータサンプルに対応付けられる状況情報のうちの1つ以上を含む。1つ以上のデータ要素のうちのデータ要素は、データ要素の識別子、データ要素についての収集される未加工データのタイプ、データ要素についての未加工データに対応付けられるユニット、およびデータ要素についてのデータ処理動作のうちの少なくとも1つを含み得る。1つ以上のデータソースを識別するための要求は、識別するためのデータソースのタイプ、およびデータソース識別を実行するための作業範囲のうちの少なくとも1つを含み得る。データソース識別結果は、データソースのデータレート、データソースのデータユニット、データソースの地理的場所、データソースの利用可能スケジュール、およびデータソースにアクセスするように構成された1つ以上のローカルフォグノードのうちの少なくとも1つを含み得る。データソースから未加工データを収集すること、およびデータソースから収集される未加工データを処理することのうちの少なくとも1つを実行するためのインジケーションは、タスク説明およびタスク識別子のうちの少なくとも1つを含み得る。データサンプル収集サービスは、ローカルフォグノード、ローカルフォグノードリーダー、フォグノード、またはクラウドノードのうちの1つで実装され得る。動作は、複数のデータソースディスカバラーから受信される1つ以上のデータソース識別結果を統合することと、統合されたデータソース識別結果に基づいて、データを収集する1つ以上のデータソースのリストを判定することと、をさらに含み得る。
RDS発見を伴うDS識別のための例示的プロシージャは、図20に示され、以下にさらに論じられる。
ステップ1で、LFA−1内のLFNL−1上のDSCSエージェント1は、DSCR−1を受信する。ユーザは、LFA−1に存在する場合、LFNL−1上のDSCSエージェント1にDSCR−1を直接呈し得るか、またはクラウドにある場合、CNでの別のDSCSエージェントにDSCR−1を呈し得、次いで、それは、処理のためにLFNL−1上のDSCSエージェント1にDSCR−1を転送する。一般に、DSCR−1は、ユーザが受信することを意図するRDSの種類についてのすべての詳細を記載する。以下に示されるように、DSCRは、以下の情報を含み得る。
パラメータの第1のパートは、特定のDSCR−1のRDSについての全体の情報および要件についてである。
Data_Sample_Frequencyについて、「Data_Sample_Frequency」は、どのくらいの頻度でRDSが生成されるべきかを示す。例えば、ユーザは、1分毎にRDSを必要とし得る。スマートシティ分析ユースケースで使用される別の例では、2つのDEが、平均温度および湿度を3分毎にそれぞれ計算するため、RDSは、3分毎に作成されるべきである。
RDS_Production_Scheduleについて、これは、任意選択的なパラメータである。「RDS_Production_Schedule」は、このDSCR−1についてのRDS生成がいつ行われるべきかを示す。言い換えると、DSCR−1のRDS生成プロセスは、LFNL−1がDSCR−1を処理した直後に開始される必要はない。実際、これは、DSCR−1のRDS生成をどのように制御するかに関するアプローチのうちの1つである。例えば、このパラメータは、RDS生成が単に毎日午前8時〜午前10時および午後5時〜午後8時の間で行われるべきであることを示し得る。代替として、RDS生成を制御するための別のアプローチは、あるトリガに基づき得る(例えば、RDS生成プロセスは、特定のトリガ要求に基づいてか、またはあるイベントに基づいて始動され得る)。
RDS_Contextsについて、このパラメータは、このDSCRのすべての単一のRDSについて、含まれるすべてのDEに加え、他の何の状況情報がまた、RDSに含まれるべきかを示す。例えば、このRDSがどのDSCRに準拠するか、およびどの時間間隔でこのRDSが生成されるかを他のものが知り得るように、タイムスタンプおよびDSCR_ID情報をRDSに組み込むことが必要であり得る。一般に、任意の有用な状況情報が、後の使用のために必要とされる場合に、RDSで搬送されるべきである。したがって、所与のRDS−1は、以下の形態を有し得る。RDS−1=(DE−1、DE−2、…、DE−N、RDS−context−1、RDS−Context−2、…)。
RDS_Sending_Address_Listについて、この属性は、このDSCR−1のRDSが送信され得るアドレスのリストを示す。例えば、以下の2つのケースが存在し得る。
DSCR−1のRDSは、DSCR−1がユーザから直接送信された場合にユーザに送信され得ることが可能である。これは、DSCR−1が処理の間に分割されないという意味において、最も単純なケースである。
より高度なシナリオでは、DSCR−1は、DSCR−1について収集されるデータが異なるLFAから生じ得るという事実に起因して、複数のLFAと相互作用し得るため、処理の間に分割され得る。以下の例を考慮する。DSCR−1は、親DSCRを2つのDSCR(例えば、DSCR−1aおよびDSCR−1b)に分割することによって作成された。言い換えると、ユーザは、当初、2つのLFA(例えば、LFA−1およびLFA−2)をカバーする大きい地理的エリアを含む親DSCR−1を呈した。故に、この親DSCR−1は、適切に処理された状態になるために分割された状態になった。例えば、DSCR−1aは、サブDSCRのうちの1つであり、それは、DSCR−1aのタスクがLFA−1内でDS識別およびRDS生成を処理することであるため、LFA−1内のLFNL−1に送信された。同様に、DSCR−1bは、別のLFA−2に関連する、DS識別およびRDS生成を処理し得る。その結果、DSCR−1aのRDS(親DSCR−1観点から、DSCR−1aのRDSは単に、親DSCR−1についての部分的なRDSであり得る)およびDSCR−1bは、さらに、親DSCR−1についてのRDSを生成するために、RDPによって、一緒に組み合わされおよび/またはアセンブルされる必要があり得る。DSCR−1のRDS_Sending_Address_Listは、DSCR−1のユーザによって提供されるRDS受信アドレスであり得る。DSCR−1aおよびDSCR−1bのRDS_Sending_Address_Listは、親DSCR−1についてのRDSアセンブリングのためのRDPであり得る。
DSCR−1の各RDSは、DEのリストを有し得る。RDSでのDEの各々は、このDEについてのすべての詳細を定義する以下の項目を有し得る。
DE_IDについて、「DE_ID」は、このDSCR−1でのDEの識別子である。スマートシティ分析ユースケースで使用される例として、DSCRの各RDSで2つのDEが存在し、DE−1およびDE−2がそれぞれ、それらのDE_IDである。
Raw_Data_Typeについて、これは、どのタイプの未加工データが、このDEのために収集されるべきかを示すものである。スマートシティ分析ユースケースで使用される例として、DE−1の未加工データタイプは、温度であり得る。
Unitについて、これは、このDEのユニットがあるべき姿を示すものである。スマートシティ分析ユースケースで使用される例によれば、DE−1の未加工データタイプは、温度である。特に、DE−1の未加工データは、摂氏または華氏のいずれかであり得るが、RDSでは、DE−1パートは、摂氏であるべき(それは、DE−1のユニットである)ことが要求され得る。
Data_Processing_Operationについて、これは、RDSでの所与のDEについて、どのタイプのデータ処理動作が、このDEについて収集される未加工データ上で行われるべきかを示すものである。共通動作は、平均、最大、最小などを含むが、それらに限定されない。スマートシティ分析ユースケースで使用される例として、DE−1のデータ処理タイプは、「平均アグリゲーション動作の実行」であるべきである。ユーザはまた、カスタマイズされたデータ処理動作を使用し得る。この場合、このパラメータは、「カスタマイズされた」値を有し得る。
Customized_Processing_Detailsについて、「Data_Processing_Operation」が、「カスタマイズされた」値を有する場合、このパラメータは、そのようなカスタマイズされたデータ処理動作をどのように行うかを示し得る。例えば、それは、以下の動作を有し得る。
ユーザは、マシン学習プロセスを介して取得される、数学の式またはモデルを解き、このモデルは、このDEについて収集される未加工データを処理するために使用され得る。この場合、式は、このパラメータに直接組み込まれ得る。
ユーザは、それ自体のデータ処理コードスニペットを有し、それは、このDEについて収集される未加工データを処理するために、LFA内のRDPによって実行され得る。この場合、このパラメータは、データ処理コードスニペットの(URIなどの)記憶場所を示し得る。
Quality_Requirementsについて、これは、このDEについての任意の品質要件を示すものである。スマートシティ分析ユースケースで使用される例として、単一のRDSでのDE−1について、温度読み取り値が、精度を保証するために、LFA−Xで展開される、少なくとも100個の異なる温度センサから収集される必要があることが要求される。
ステップ2で、DSCSエージェント1は、(表9に示されるような)LFN能力の表をチェックし、DSCR−1についてのDSDとして、適切なLFN(例えば、LFN−1)を選択する。スマートシティ分析ユースケースで使用される例として、2つのDE(例えば、DE−1およびDE−2)はそれぞれ、平均温度および湿度を3分毎に計算し得る。故に、各DE−1およびDE−2について、DSCSエージェント1は、1つ以上のDSDのリストを選択し得る。そうするために、DSCSエージェント1は、その能力、作業スケジュール、および表9に示されるようなDSD範囲などの潜在的DSD候補についての詳細な情報をチェックする必要があり得る。複数のDSDは、LFA−Xに展開される温度センサが、異なる組織に属し、選択されたDSDの各々がまた、ある能力制限を有する(例えば、各DSDが、単に、同じ組織に属する特定のDSに対してDS識別を行い得る)場合に、DE−1のために必要とされるDSを識別するために必要とされ得る。別の例として、LFA−Xは、非常に大きい地理的エリアをカバーし得る。故に、複数のDSDが必要とされ得、それらの各々が、LFA−X内のより小さいエリアについてDS識別を行い得る。一般に、所与のDEについてDS識別を行うために複数のDSDを必要とする多くの他のケースが存在し得、本明細書に開示される方法およびシステムは、それらのケースのすべてに適用され得る。
全体として、DSCSエージェント1は、各DEについてDSDのリストを選択し、以下の情報を含み得る詳細なDS識別プランで、選択されたDSDの各々を割り当て得る。
何のタイプのDSが識別されるか。例えば、所与のDEについて、ステップ1で導入されるような「Raw_Data_Type」は、識別されるDSのタイプを示す。所与のDSDは、複数のDEについて潜在的DSを識別するために使用され得ることが可能である。そのような場合、所与のDSDは、複数のDS識別プランを有し得、それらの各々は、所与のDEに対応する。
DS識別動作を行うための作業範囲が何か(例えば、どの組織内か、またはどの地理的エリア内かなど)。
DSにおける任意の他の要件。スマートシティ分析ユースケースで使用される例によれば、DE−1は、3分毎に平均温度を計算するものである。故に、DE−1について、DE−1の潜在的DSについての要件のうちの1つは、(DSとしての)温度センサが、屋内温度センサではなく屋外温度センサであるべきであるということであり得る。
ステップ3で、各DEについて、DSCSエージェント1は、それらの選択されたDSDの各々について作成される詳細なDS識別プランとともに、そのDEについてDS識別動作を行うために、選択されたDSDの各々(例えば、LFN−1上のDSCSエージェント2)に要求を送信する。言い換えると、各DEについて、選択されたDSDの各々についてのDS識別プランは、このDEについてDS識別タスクを協働的に達成するためにそれらが一緒に機能し得るように異なっている。選択されたDSDが、複数のDEについてDS識別タスクに関与する場合、DSCSエージェント1は、異なるDEについてのすべてのDS識別タスクが含まれる、この選択されたDSDに単一の要求を送信し得る。
ステップ4で、選択されたDSDの各々でのDSCSエージェントは、そのそれぞれのDS識別プランに従ってDS識別を行い得る。例えば、LFN−1上のDSCSエージェント2は、DS−1が所望のDSかどうかを評価するために(例えば、DS−1が温度センサかどうか、およびそれが屋外に位置しているかどうかを評価するために)、DS−1上でDS識別を行うことを担う。LFN−1は、DS識別を行うためにDS−1にアクセスする必要があり得る。oneM2Mを例に取ると、(DSDとしての)セマンティック対応CSE−1が、温度データソースを発見することを意図する場合、それは、CSE−2上にホストされる(DS−1としての)<container−1>リソースを識別し、温度読み取り値を記憶するために、セマンティック発見機構を使用し得る。追加でまたは代替で、DS−1は、CSE−1で登録され得(例えば、<container−1>リソースは、CSE−1によってホストされ)、CSE−1は、DSDとして機能し得る。そのような場合、CSE−1は、DS識別についてDS−1の登録情報を直接チェックし得、DS−1にトークする必要がない場合がある。DSDの各々でのDSCSエージェントはまた、各識別された/候補DSについての有用な情報をさらに収集する必要があり得る。関連情報は、(DS−1を例に取る)以下の態様を含み得るが、それらに限定されない。
DS−1のデータレート、
DS−1のデータユニット、
DS−1の地理的場所、
DS−1から未加工データを読み出すためのアクセス権を有するLFN(すなわち、RDC候補としてのもの)、および
DS−1の利用可能スケジュール。
ステップ5で、選択されたDSDの各々でのDSCSエージェント(例えば、LFN−1上のDSCSエージェント2)は、ステップ4で導入されるような識別されたDSについての関連情報とともに、そのDS識別結果を送信し返す。
段階2は、DS識別結果統合およびRDC/RDPタスク割り当てを含み得る。段階2で、LFNLの主要なタスクは、段階1の間にDSDからのすべてのDS識別結果を統合し、DEの各々について所望のDSのリストを判定することである。言い換えると、未加工データは、それらの選択されたDSから収集され得る。選択されたDSの各々について、LFNLは、段階1の間に識別されるようなこのDSについての関連情報に基づいて、適切なRDCをそれに割り当てる必要があり得る。LFNLはまた、選択されたDSの各々について適切なRDPを割り当てる必要があり得、それらのRDPは、それらの選択されたDSの未加工データの処理およびRDSの生成を担い得る。DS識別結果統合およびRDC/RDPタスク割り当てのための例示的プロシージャは、図21に示され、以下に論じられる。
ステップ1で、DSCSエージェント1は、DSCR−1についての複数のDSDからDS識別結果を受信した(これは、図20のステップ5の結果である)。例えば、DSCR−1のRDSでの各DEについて、異なるDSDによって識別されている複数のDSが存在し得る。故に、DSCSエージェント1は、DEの各々について、すべての識別されたDSを評価し得る。すべての識別されたDSは、それらのすべてがDSCR−1について所望のDSとして選択されるわけではない場合でさえ、DSCSエージェント1によって記録され得ることに留意されたい。その理由は、そのようなDS識別結果が、他の/将来のDSCRを供給するときに再使用され得ることである。故に、段階1についての追加の改善の1つは、特定のDSCRについてのDSDとして適切なLFNを選択する前に、図20のステップ2の間に、DSCSエージェント1が、最初に、DS識別結果履歴記録をチェックし得、前のDSCRについて識別される任意の既存のDSがこの新しいDSCRを供給するために再利用され得るかどうかを見ることである。このようにして、DS識別動作のオーバーヘッドが低減され得る。
ステップ2で、DSCSエージェント1は、DEの各々について所望のDSのリストを選択する。このステップは、未加工データがこのDEについてのすべての識別されたDSの間から収集されるのがどのDSかを選択するために実行され得る。
所与のDSについて、考慮され、含まれる関連情報は、DS識別プロセスの間に(例えば、図20のステップ4で)取得され得る以下のことを含み得る。
DSのデータレート、
DSのデータユニット、
DSの地理的場所、
DSから未加工データを読み出すためのアクセス権を有するLFN、および
DSの利用可能スケジュール。
スマートシティ分析ユースケースで使用される例として、(3分毎の平均温度である)DE−1について、(DE−1についてのDS候補としての)200個の温度センサがステージ1の間で複数のDSDによって識別されており、それらの温度がLFA−Xによってカバーされる全体の地理的エリア上で分散されることが想定される。
DE自体についてのある情報もまた考慮される必要があり得、それは、図20のステップ1(例えば、「Quality_Requirements」パラメータで)で導入されるようにDSCR−1で説明された。スマートシティ分析ユースケースで使用される例によれば、DE−1について、温度読み取り値が、精度を保証するために、LFA−Xで展開される、少なくとも100個の異なる温度センサから収集される必要があることが要求される。
所与のDEおよびその対応する識別されたDSの両方についての情報を考慮することによって、DSCSエージェント1は、どのDSが、未加工データが収集される所望のDSかを決定し得る。スマートシティ分析ユースケースで使用される例によれば、(3分毎の平均温度である)DE−1について、100個の温度センサが、(DS候補としての)LFA−X内の全体で200個の温度センサの間でDE−1について所望のDSとして選択され得る。
ステップ3で、各所望のDSについて、DSCSエージェント1は、それについてRDCをさらに選択する。一般に、RDCは、選択されたDSの各々について必要とされ、そのようなRDCは、DSから未加工データを収集し、処理のために未加工データを対応するRDPに送信するものである。提案されたソリューションをより一般的にするために、RDCおよびRDPは単に論理的役割であり、したがって、LFNが、所与のDSについてのRDCおよびこのDSについてのRDPであり得ることもまた可能であることは、着目に値する。RDCが、所望のDSの各々について選択され得るが、所与のLFNが、複数のDSについてRDCとして機能し得る。言い換えると、所与のLFNは、複数のDSからデータを収集することを担い得る。例証を容易にするための以下の説明では、所与のDSについて、そのRDCおよびRDPが異なるLFNによって行われ得ることが想定される。
各所望のDSについてRDCをさらに選択するために、以下の情報が評価される必要があり得る。
DSCSエージェント1は、どのLFNが(段階1の間に取得され得る)このDSからの未加工データを読み出すためのアクセス権を有するかに関するDSについての関連情報をチェックする必要があり得る。そのような情報は、きめが粗いかまたはきめが細かいものとして説明され得る。例として、所与のDS−1は、DS−1と同じ組織に属する任意のLFNがDS−1からデータを読み出し得るような、きめの粗いアクセス制御情報を有し得る。別の例として、それは、DS−1から200メートル以内にある任意のLFNがDS−1からデータを読み出し得るような、別のきめの粗いアクセス制御情報を有し得る。きめの細かいアクセス制御情報について、例は、特定のLFN(例えば、LFN−1およびLFN−27)のみがDS−1からデータを読み出し得ることであり得る。別の例は、(DSとしての)特定の<container>リソースのACPルールがこのリソースに対する「読み出し」特権を有する(RDC候補としての)特定のCSE/AEのリストを示すoneM2Mの例であり得る。
DSCSエージェント1は、どのLFNがRDCとして機能し得、機能することを望んでいるかを識別するために、LFN能力の表をチェックする必要があり得る。所与のLFNが、洗練されたDS識別能力を有し得るが、それは寄与することを望まないことが可能である。そのような場合、それが、(LFN能力登録プロセスで導入されるように)対応するLFNLにその能力を登録するとき、それがRDCとして機能することを望むことを示さない場合がある。「Other_Context_Information」パラメータは、それが入っている組織およびその地理的場所などの特定のLFNの一般的な状況を説明する。
特定のDSについてのアクセス制御情報は、このDEについてRDCとして適切なLFNを選択するために、特定のLFNに関連するアクセス特権情報と比較され得る。前の例を続けて、所与のLFN−1について、それが、DS−1と同じ組織に入っている場合、DS−1のアクセス制御ルールが、DS−1と同じ組織に属する任意のLFNがDS−1からデータを読み出し得ることを定義する(例えば、DS−1のアクセス制御ポリシーがLFN−1のアクセス特権と一致する)とき、LFN−1は、DS−1についてRDCとして選択され得る。信頼性を向上させるために、1つのRDCがこのDSについてマスターRDCとして指定され得、一方、他のものが副次的/バックアップRDCであるように、複数のRDCが所与のDSについて選択され得ることに留意されたい。その結果、マスターRDCは、このDSから未加工データを収集するための主なまたは「マスター」RDCであるが、それは、マスターRDCが未加工データ収集を行うことができない場合、副次的RDCによって置き換えられ得る。
ステップ4で、DSCSエージェント1は、各DEについてRDPタスク割り当てプランを作成する。所与のDE−1についての例示的ワークフローは、以下のようであり得る。
DE−1について、DSCSエージェント1は、最初に、どのくらい多くのデータ処理段階が、DE−1のDSからRDSでのDE−1の最終の形態に収集される未加工データの間で必要とされるかを見出す。スマートシティ分析ユースケースで使用される例によれば、DE−1は、3分毎の平均温度である。言い換えると、単一のRDSで、DE−1の最終の形態は、「所与の3分の時間間隔の間のLFA−Xについての平均温度」であり、一方、DE−1についての未加工データは、その3分の時間間隔の間に複数の温度センサから収集される温度読み取り値である。故に、この例は、2つのデータ処理段階を有し得る。
データ処理段階1について、1つのピースの温度読み取り値について、第1の処理は、温度センサから収集されるオリジナル未加工データから、データ読み取り値および(タイムスタンプなどの)他の有用な状況情報を抽出することである。他の事前処理がさらに必要とされ得る。例えば、DE−1の最終の形態が、データが摂氏であるように要求する場合、未加工データが華氏であるとき、単位変換が必要とされる。故に、RDPは、この段階で決定され得、それは、RDCによって収集される未加工データを受信するための第1のレベルRDPノードのようである。
データ処理段階2について、DE−1のすべての所望のDSから収集される未加工データは、3分毎に平均温度を計算するために一緒に処理される必要があり得、それは、RDSの各々でのDE−1の最終の形態である。故に、RDPはまた、この段階で決定され得、それは、データ処理段階1でRDPによって出力される処理されたデータを受信するための第2のレベルRDPノードである。より特定のデータ処理動作を使用してデータがさらに処理される必要がある場合、この段階の後にさらなる段階が存在し得ることに留意されたい。
次のステップは、上記の定義された段階の各々について適切なLFNを選択することである。例えば、段階1について、あるカスタマイズされたデータ処理コードスニペットは、未加工データから有用なデータピースを抽出するために必要とされ得る。故に、RDP候補としてのLFNは、カスタマイズされたコードまたはソフトウェアが実行され得るそれらのLFNである。別の例では、単純なデータアグリゲーション能力を有するLFNは、段階2についてRDPとして必要とされ得る。DSCSエージェント1は、どのLFNが上記の段階の各々についてRDPとして機能し得るかを識別するために、LFN能力の表をさらにチェックし得る。収集および/または処理される未加工データが大量にあり得るため、複数のLFNは、特定のデータ処理段階の各々についてRDPとして必要とされ選択され得る。スマートシティ分析ユースケースで使用される例によれば、(3分毎の平均温度である)DE−1について、100個の温度読み取り値が、100個の所望のDS(例えば、温度センサ)から収集され得る。2つのLFNが段階1について2つのRDPとして選択されることが可能である。各RDPは、段階1の間に半分のDS(例えば、50個の温度センサ)から未加工データを処理することを担い得る。所与の段階について複数のRDPが存在するとき、1つのRDPがこの段階についてマスターRDPとして指定され得、一方、他のものが副次的/バックアップRDPである。その結果、マスターRDPは、この段階の間のデータ処理のための主要なRDPであるが、それは、マスターRDPが要求されたデータ処理動作を行うことができない場合、副次的RDPによって置き換えられ得る。マスターRDPが過負荷状態である場合、それはまた、そのワークロードをそれらの副次的RDPにオフロードし得る。段階2について、それは、(段階1の後の処理された100個の温度読み取り値である)100個の温度読み取り値の平均値を計算することであるため、平均動作は、単一のLFNで実行される必要があり得る。故に、強力なLFNが、段階2についてRDPとして選択され得る。
最後のステップは、完全なデータ処理フロープランを構築するために、異なるデータ処理段階で、選択されたRDPを一緒に接続するかまたはリンクさせることである。複数のRDPが第1の段階(例えば、スマートシティ分析ユースケースでの段階1)について選択されるとき、DSCSエージェント1は、DSの各々を第1の段階で特定のRDPに割り当てる必要があり得る。言い換えると、所与のDSからの未加工データは、第1の段階での処理のために、その割り当てられたRDPに送信されるべきである。1つのRDPだけが第1の段階(例えば、段階1)について選択された場合、すべてのDSの未加工データは、第1の段階でこの単一のRDPに送信され得る。RDCが、所望のDSから未加工データを収集することを担うため、所与のDSについて、その対応するRDCは、RDCが処理のために未加工データを送信する場所(例えば、どのRDPか)を知り得るように、そのようなRDP割り当て決定で知らされる必要があり得る。
同様に、最後の段階(例えば、スマートシティ分析ユースケースでの段階2)でのRDPについて、DSCSエージェント1はまた、この段階の後に、処理されたデータがどこに送信されるべきかを決定する必要があり得る。スマートシティ分析ユースケースによれば、特定の3分の平均温度読み取り値が段階2の間に生成されるとき、それは、このデータがDE−1のためだけであるため、依然として完全なRDSではない。完全なRDSは、2つのDE(例えば、DE−1およびDE−2)を含み得る。したがって、次のステップは、(RDSアセンブリングRDPと呼ばれる別のRDPによって行われ得る)DE−1およびDE−2の最終形態のデータのアセンブリングによって完全なRDSを生成することであり得る。2つの異なる/隣接する段階でのRDPについて、DSCSエージェント1はまた、段階iでのRDPによって処理されたどのデータが、次の段階i+1でのどのRDPに送信されるべきかを決定する必要があり得る。
最後に、DSCSエージェント1は、LFNをRDSアセンブリングRDPとして選択し、それは、DEの各々について最後のデータ処理段階でRDPによって処理されたデータを受信し、RDSを構築するために異なるDEのデータを一緒にアセンブルする。スマートシティユースケースを例に取ると、DE−1について、その最後のデータ処理段階の出力/処理されたデータは、特定の3分の時間間隔での平均温度であり得る。そのようなデータは、DE−2についての他のデータ(例えば、同じ3分の時間間隔の平均湿度)とアセンブルされ得る。2つのピースのデータは、この例でのRDS定義に従って、各RDSが(DE−1、DE−2、タイムスタンプ)のフォーマットを有するため、完全なRDSとして一緒にアセンブルされ得る。
ステップ5で、(ステップ3で判定されるような)所与の/所望のDSについての(RDCとしての)選択されたLFNの各々について、DSCSエージェント1は、データ収集タスクを割り当てるためにそれらのLFNにコンタクトし得る。例えば、DSCSエージェント1が、RDCタスク割り当て要求を特定のLFN−1に送信するとき、以下の情報は、特定のDSについて例示的未加工データ収集タスクを説明する(言い換えると、特定のLFNに対するRDCタスク割り当ては、複数のDSについてのデータ収集タスクのリストを含み得る)。
タスクID。これは、このタスクについての特定のタスクIDである。RDCが第1のデータ処理段階で未加工データをRDPに送信するとき、それは、この未加工データが関連するタスクがどれかを示す必要があり得、(このタスクがどのDSCRおよびどのDEに関連するかをさらに示し得る)。
DSのID(例えば、URL)について、
データ収集スケジュール(例えば、このDSからデータをいつ収集するか)。このスケジュールは、DSCR−1についてのRDS_Production_Scheduleパラメータで整合され得る。
RDPのID。これは、DSの未加工データがどこに送信されるべきかを示す。言い換えると、RDCは、DSから未加工データを収集し、未加工データをこのパラメータに示されるようなRDPに送信し得る。
いくつかのLFNは、DSCSエージェント1によって要求されるようなタスク割り当てを受け入れることができなくてもよいことが可能である。故に、このステップの間に複数のネゴシエーションプロセスが存在し得る。
ステップ6で、DSCSエージェント1は、DSCR−1に関連する特定のDEについてRDCとしてLFN−1を選択し、LFN−1上のDSCSエージェント2は、RDC割り当てを通知する。
ステップ7で、(ステップ4で判定されるような)(RDPとしての)選択されたLFNの各々について、DSCSエージェント1は、データ処理タスクを割り当てるためにそれらのLFNにコンタクトし得る。例えば、DSCSエージェント1は、RDPタスク割り当て要求を特定のLFN−2に送信し得、それはまた、LFN−2に割り当てられる複数のタスクを含み得る。例えば、所与のLFNは、特定のDEについて、異なるデータ処理段階でRDPとして機能し得る。より一般的には、所与のLFNは、異なるDEについてのデータ処理のためのRDPとして機能し得る。例えば、LFN−2は、DE−1についてのRDPとして機能し得、その間に、LFN−2は、DE−1のデータ処理段階1についての要求されたデータ処理を行う。LFN−2はまた、DE−2についてのRDPとして機能し得、その間に、LFN−2は、DE−2のデータ処理段階2についての要求されたデータ処理を行う。それらの関与するタスクの各々についてLFN(例えば、LFN−2)が行う必要があることを説明するために、以下の情報が含まれ得る。
タスクIDについて、これは、このタスクについての特定のタスクIDである。上流のデータ送信元が、処理されたデータを下流のデータレシーバに送信するとき、それは、この処理されたデータがどのタスクについてかを示す必要があり得る。
上流のデータ送信元のIDおよび関連タスクIDについて、これは、処理されたデータを処理のためにLFN−2に誰が送信するかを示すものである。上流の送信元から送信されるデータはまた、(上流のデータ送信元によって行われるタスクのIDである)別のタスクIDに対応付けられ得る。例えば、LFN−2が、DE−1についての第1のデータ処理段階についてのRDPである場合、DE−1のRDCは、DE−1の所望のDSから未加工データを収集し、処理のためにそれらをLFN−2に送信する、上流のデータ送信元であり得る。別の例では、LFN−2が、DE−1についての第2のデータ処理段階についての選択されたRDPである場合、LFN−2の上流のデータ送信元は、DE−1についての第1のデータ処理段階でのRDPであり得、それは、第2の段階についての処理を行うために、それらの処理されたデータをLFN−2に送信する。RDCの役割はまた、RDPとして機能するLFNによって行われ得ることは、着目に値する。例えば、LFN−2は、特定のDE−1について未加工データを収集するためのRDCとして選択されることが可能である。LFN−2はまた、データ処理能力を有し得、それはまた、DE−1についての第1のデータ処理段階についてのRDPとして選択される。この場合、LFN−2は、RDCおよびRDPの両方としての組み合わされた役割を行っている。
Required_Data_Processing_Operationについて、これは、何の特定のデータ処理動作が行われるかを示す。カスタマイズされたコードがダウンロードされる必要がある場合、このパラメータはまた、データ処理コードをダウンロードする場所を示す。
下流のデータレシーバのIDについて、これは、一旦LFN−2がこの特定のタスクについて処理を完了すると、処理されたデータを送信する場所を示すものである。例えば、LFN−2が、DE−1についての第1のデータ処理段階についての選択されたRDPである場合、DE−1についての第2のデータ処理段階についてのRDPは、LFN−2によって処理されたデータに基づいて、さらなるデータ処理動作を行う下流のデータレシーバであり得る。LFN−2が、その処理されたデータをその下流のデータレシーバに送信するとき、それはまた、処理されたデータをタスクIDに対応付ける必要があり得、それは、(例えば、タスクIDで定義されるような)LFN−2自体によって行われるタスクのIDである。
いくつかのLFNは、DSCSエージェント1によって要求されるようなタスク割り当てを受け入れることができなくてもよいこともまた可能である。故に、このプロセスの間に複数のネゴシエーションステップが存在し得る。
加えて、所与のLFNについて、それが、所与のDSCRを供給するためにRDCおよびRDPとして選択される場合、DSCSエージェント1は、単に、RDCおよびRDPタスク割り当てのために1つのメッセージをこのLFNに送信し得る。そのような場合、ステップ5およびステップ7が組み合わされ得る。
ステップ8で、LFN−2上のDSCSエージェント3は、RDP割り当てを通知する。
最後に、DSCSエージェント1は、DSCR−1についてのジョブ割り当てプロファイルを生成し得、それは、どのLFNが、DEの各々についてRDCとして選択されるか、またはどのLFNが、DSCR−1についてのRDSを生成するために要求されるデータ処理動作についてのRDPとして選択されるかについてのすべての詳細を含み得る。
協働的なRDS生成および配信のための方法およびシステムが本明細書に開示される。以下の例では、LFAでRDS生成プロセスを始動するためのプロセスが開示される。
所与のDSCRについて、DS識別およびRDC/RDP割り当てが完了した後、このDSCRについてRDSをすぐに生成し始めることが必要でない場合がある。言い換えると、RDS生成は、後で(例えば、トリガに基づいて)、またはあるスケジュール(例えば、図21のステップ1に含まれる「RDS_Production_Schedule」パラメータに示されるような情報)に基づいて、始動され得る。一般に、RDS生成有効化は、ユーザによって開始され得る(例えば、RDS生成トリガは、CNからLFAに送信され得る)。所与のDSCRについて、LFNLは、このDSCRのRDSの各DEについて、どのDSが所望のまたは選択されたDSかを判定する必要があり得る。追加でまたは代替で、LFNLは、所望のDSの各々について、どのLFNが選択されたRDCか、および/またはDEの各々について、どのLFNがこのDEの所望のDSから収集されるデータを処理するための選択されたRDPであるかを判定する必要があり得る(それらのタスク割り当てのすべてが、協働的なDS識別プロセスの段階1および段階2の間で決定され得る)。次いで、LFNLは、どの特定のタスクがここで実行される必要があるかについてのガイドラインとともに、関与するLFNの各々にトリガを送信し得る。
一例では、データサンプル収集サービスは、特定のデータサンプル収集要求に対応付けられるデータサンプルの生成を開始するためのインジケーションを含むトリガを受信することと、未加工データ収集を実行するように構成された少なくとも1つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも1つのローカルフォグノードを判定することと、未加工データ収集を実行するように構成された少なくとも1つのローカルフォグノードに、未加工データ収集を開始するためのインジケーションを送信することと、未加工データ収集を実行するように構成された少なくとも1つのローカルフォグノードから、未加工データ収集が開始されたというインジケーションを受信することと、未加工データ処理を実行するように構成された少なくとも1つのローカルフォグノードに、未加工データ処理を開始するためのインジケーションを送信することと、未加工データ処理を実行するように構成された少なくとも1つのローカルフォグノードから、未加工データ処理が開始されたというインジケーションを受信することと、を含む、動作を実行するように構成され得る。
未加工データ収集を開始するためのインジケーションおよび未加工データ処理を開始するためのインジケーションの各々は、タスク識別子を含み得る。トリガは、クラウドノードから受信され得る。未加工データ収集を実行するように構成された少なくとも1つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも1つのローカルフォグノードを判定することは、データサンプル収集サービスで記憶されるジョブ割り当てプロファイルにアクセスすることを含む。未加工データ収集を実行するように構成された少なくとも1つのローカルフォグノード、および未加工データ処理を実行するように構成された少なくとも1つのローカルフォグノードは、同じローカルフォグノードで実装され得る。データサンプル収集サービスは、ローカルフォグノードリーダーで実装され得る。
別の例では、ローカルフォグノードは、データサンプル収集サービスから、未加工データ収集および未加工データ処理動作のうちの少なくとも1つを実行するための要求を受信することであって、データサンプル収集サービスが、ローカルフォグノードリーダーで実装される、受信することと、未加工データ収集および未加工データ処理動作のうちの少なくとも1つを開始することと、データサンプル収集サービスに、未加工データ収集および未加工データ処理動作のうちの少なくとも1つが開始されたというインジケーションを送信することと、を含む、動作を実行するように構成され得る。
未加工データ収集および未加工データ処理動作のうちの少なくとも1つを実行するための要求は、タスク識別子を含み得る。未加工データ収集および未加工データ処理動作のうちの少なくとも1つを実行するための要求を受信することは、未加工データ収集を実行するための第1の要求を受信することであって、第1の要求が、第1のタスク識別子を含む、受信することと、未加工データ処理を実行するための第2の要求を受信することであって、第2の要求が、第2のタスク識別子を含む、受信することと、を含み得る。未加工データ収集および未加工データ処理動作のうちの少なくとも1つを実行するための要求は、データサンプル収集サービスで記憶されるジョブ割り当てプロファイルに基づき得る。データ処理動作は、データ収集動作の少なくとも部分的な完了に基づいて自動的に実行され得る。未加工データ収集および未加工データ処理動作のうちの少なくとも1つを実行するための要求は、データサンプル収集サービスで記憶されるスケジュールに基づき得る。
LFAでRDS生成をトリガするための例示的プロシージャは、図22に示され、以下に論じられる。
ステップ1で、DSCSエージェント1は、DSCR−1についてRDS生成を開始するためのトリガを受信する。例えば、DSCR−1を開始したユーザは、トリガ要求をCNに送信することによって、このDSCR−1を直接有効にし得る。CNは、このトリガ要求を、LFA−1内のLFNLにさらに転送し得る。
ステップ2で、DSCSエージェント1は、どのLFNがDSCR−1についてのRDC/RDPとして関与するかを見出す。特に、DSCSエージェント1は、どのLFNがRDC/RDPタスク割り当ての間にRDCまたはRDPとして選択されるかについてのすべての詳細を含む、(図21に示されるプロシージャの終わりで作成されるような)DSCR−1のジョブ割り当てプロファイルをチェックし得る。
ステップ3で、DSCSエージェント1は、所望のDSからのデータ収集を開始するために、(DSCR−1を供給するためにRDCとして選択された)関与するLFNにコンタクトする。DSCR−1の対応するRDSのDEの各々について、DSCSエージェント1は、各DEについて、どのDSが所望のDSかをチェックし得る。追加でまたは代替で、DSCSエージェント1は、DSCR−1のジョブ割り当てプロファイルに含まれるような情報に基づいて、どのLFNがDSの各々についてRDCとして割り当てられているかをチェックし得る。所与のLFNは、複数のDSについてのRDCであり得ることが可能であり得ることに留意されたい。したがって、DSCSエージェント1が、すべての関与するタスクIDも含み得る、(RDCとしての)特定のLFNに活性化トリガを送信するとき、このLFNに割り当てられたDSCR−1に関連するデータ収集タスクのすべてが開始され得る。
ステップ4で、RDC(例えば、LFN−1)は、データ収集が開始されることを通知する。所与のLFN(例えば、LFN−1)について、RDCは、ステップ3に示されるようなタスクリストに従って、未加工データ収集アクティビティを開始し得る。
ステップ5で、DSCSエージェント1は、(図21に示されるプロシージャの終わりに作成されたジョブ割り当てプロファイルで説明されるような)RDC/RDPタスク割り当ての間に構成されるようなデータ処理タスクを開始するために、(DSCR−1を供給するためにRDPとして選択された)関与するLFNにコンタクトする。DSCSエージェント1は、DSCR−1のジョブ割り当てプロファイルに含まれるような情報に基づいて、どのLFNがDSCR−1のDEの各々についての割り当てられたRDPであるかをチェックし得る。所与のDEについて、特定のLFNは、このDEの複数のデータ処理段階の間にRDPであり得ることが可能であることに留意されたい。特定のLFNは、異なるDEについてのRDPであり得る。したがって、DSCSエージェント1が、すべての関与するタスクIDも含む、(RDPとしての)特定のLFNに活性化トリガを送信するとき、このLFNに割り当てられたDSCR−1に関連するすべてのデータ処理タスクが、ここで開始され得る。
ステップ6で、RDP(例えば、LFN−2)は、DSCR−1を供給するためのデータ処理が開始した(例えば、それは、処理のためにRDCからデータを受信する準備ができている)ことを通知する。所与のLFN(例えば、LFN−2)について、RDPは、ステップ5に示されるようなタスクリストに従って、データ処理アクティビティを開始し得る。代替として、ステップ5およびステップ6は、ステップ3および/またはステップ4の前に実行され得る。
代替のソリューションとして、ステップ5および/またはステップ6は、トリガをRDCに送信することのみが必要であるという意味において必要とされない場合があることに留意されたい。その理由は、RDCが、DSからデータを収集するものであり、処理のためにデータを送信する場所を知り得ることである。故に、RDPは、初めてRDCから送信されるデータを受信するときにトリガされ得る。例えば、RDCがデータの第1のバッチをRDPに送信しているとき、RDCは、受信されたデータを処理するためにRDPがその対応するタスクを開始し得るように、タスクIDを含み得る。
DSCR−1のRDS生成が、図21のステップ1に含まれる「RDS_Production_Schedule」パラメータに示されるような、あるスケジュールに基づく場合、DSCR−1を供給するためにRDCまたはRDPとして選択された、1つ以上の関与するLFNは、ワークスケジュールに従うことによって自動的に機能し始め得る。
一旦、RDS生成が所与のDSCRについて始動されると、関与するRDC/RDPが機能し始め得る。特定のDEについての実際のRDS生成のための例示的プロシージャは、図23に示され、以下に論じられる。プロシージャは、スマートシティ分析ユースケースを例に取り、ここで、単一のRDSでのDE−1は、3分毎の平均温度である。特に、100個の温度センサは、DE−1についての所望のDSとして、すでに識別されている。
ステップ1で、RDCタスク割り当てに従って、(RDCとしての)LFN−2上のDSCSエージェント3は、DS−1からDS−50まで未加工データを収集することを担うことが想定される。DSCSエージェント3は、生成されている新しいデータが存在するかどうかを見るために、DS−1およびDS−50に定期的にアクセスし得る。追加でまたは代替で、読み出し動作を行うことによって所望のDSから未加工データを収集する代わりに、RDCは、所望のDSにおいてサブスクリプションを行い得、その結果、それらのDSが通知を介してそれらの新しいデータをRDCに送信し得る。
ステップ2で、RDCタスク割り当てに従って、(RDCとしての)LFN−1上のDSCSエージェント2は、DS−51からDS−100まで未加工データを収集することを担うことが想定される。
ステップ3で、DSCSエージェント3は、(DS−1からDS−50まで収集される)未加工データをLFN−3に送信し、それは、DE−1の第1のデータ処理段階についてのRDPとして機能している。特に、DSCSエージェント3がデータの第1のバッチをLFN−3に送信しているとき、それは、受信されたデータをどのように処理するかをLFN−3が知るようにタスクIDを含み得る。
ステップ4で、LFN−2上のDSCSエージェント3と同様に、DSCSエージェント2は、(DS−51からDS−100まで収集される)未加工データをLFN−3に送信し、それは、DE−1の第1のデータ処理段階についてのRDPとして機能している。
ステップ5で、LFN−3上のDSCSエージェント4は、DE−1の第1のデータ処理段階について未加工データを処理する。例えば、第1の段階の間の主要なデータ処理動作は、未加工温度読み取り値で構成される1つのピースについてである。RDPは、オリジナル未加工データから、データ読み取り値および(タイムスタンプなどの)他の有用な状況情報を抽出する。DE−1の最終の形態が、データが摂氏であるように要求する場合、未加工データが当初、華氏であるとき、単位変換が行われ得る。
ステップ6で、一旦、LFN−3上のDSCSエージェント4が第1のデータ処理段階についてそのデータ処理を完了すると、処理されたデータをLFN−4に送信し得、それは、DE−1の第2のデータ処理段階についてのRDPとして機能している。同様に、LFN−3上のDSCSエージェント4がその処理されたデータをLFN−4に送信しているとき、それは、受信されたデータをどのように処理するかをLFN−4が知るようにタスクIDを含み得る。
ステップ7で、LFN−4上のDSCSエージェント5は、第2のデータ処理段階についてデータを処理し、最終の形態であり得るDE−1についてのデータを生成する。DE−1についてのデータは、特定の3分の時間間隔での平均温度値であり、それは、DE−1の最終の形態である。故に、LFN−4の出力は、3分毎のLFA−1の平均温度値であり得、それは、第1のデータ処理段階での2つのRDPから(例えば、LFN−2およびLFN−3)から送信される、処理されたデータに基づいて計算される。その後、LFN−4上のDSCSエージェント5は、処理されたデータをDSCR−1の対応するRDSアセンブリングRDPに送信し得、それは、DSCR−1について最終のRDSを生成する最後のRDPである。(RDCまたはRDPのいずれかとして機能する)LFNについて、それは、それぞれ、副次的RDCまたはRDPであるいくつかのピアLFNに対応付けられ得る。故に、当初選択されたRDCまたはRDPが、予期されるように所望のタスクを行うことができない(例えば、過負荷状態になるか、または機能を停止させる)場合、ワークロードは、対応する副次的RDCまたはRDPにオフロードされ得る。
RDC/RDPは単に、「論理」エンティティであり得る。特に、図23に示される例では、異なる役割は、例証を容易にするために(それは、提案されたアイディアの一般性を限定すべきでない)、異なるLFNによって行われ得る。LFNは、第1のデータ処理段階についてデータ処理を行うためにRDCおよびRDPの両方としてであり得ることが可能であるということが理解される。例えば、DSCSエージェント3は、RDCおよび第1の段階RDPの両方として機能し得る。異なる例示的構成として、ここで、DSCSエージェント3がすべての100個のDSからデータを収集し得ることを想定すると、それは、それらの100個のDSからデータを収集し、未加工データに対してAVERAGE動作を直接行い、第2の段階RDPであるさらなる処理のために、処理されたデータをDSCSエージェント5に送信し得る。
一旦、データが所与のDEについて完全に処理されると、それは、その最終の形態であり得、アセンブルされる準備ができ得る。所与のDSCRについてのRDSアセンブリングのための例示的プロシージャは、図24に示され、以下にさらに論じられる。図24のプロシージャは、スマートシティ分析ユースケースを例に取り、ここで、単一のRDSでのDE−1は、所与のLFA−1についての3分毎の平均温度であり、単一のRDSでのDE−2は、同じ所与のLFA−1についての3分毎の平均湿度である。故に、図24でのステップ7の出力は、DE−1の最終の形態である。
(図24のステップ7から続いて)ステップ1で、LFN−4上のDSCSエージェント5は、第2のデータ処理段階についてデータを処理し、DE−1について最終形態のデータを生成した。DSCSエージェント5は、アセンブリングのために、処理されたデータをLFN−6に送信する。特に、LFN−4上のDSCSエージェント5からのDE−1の出力データの各々は、後のRDSアセンブリングの間に使用され得る、ある状況情報に対応付けられ得る。図23でのステップ7の間に生成されるDE−1の所与のピースのデータについて、対応付けられた情報は、計算された平均温度が特定の3分の時間間隔に対応することを示し得る。
ステップ2で、LFN−5上のDSCSエージェント6は、DE−2について最終形態のデータを生成した、DE−2の最後のデータ処理段階でのRDPであることが想定される。ここで、DE−2は、3分毎の平均湿度である。同様に、DE−2の最終形態のデータの各々はまた、後のRDSアセンブリングの間に使用され得る、ある状況情報に対応付けられ得る。DSCSエージェント6は、最終のRDSアセンブリングのために、DE−2に関連する処理されたデータをLFN−6に送信し得る。
ステップ3で、LFN−6上のDSCSエージェント7は、DE−1およびDE−2の最終形態のデータをアセンブルし、DSCR−1についてRDSを生成する。DE−1についての1つのピースのデータおよびDE−2についての1つのピースのデータは、それらが同じ特定の3分の時間間隔に関連する場合、一緒にアセンブルされ得る。その結果、RDSは、DSCR−1で記載されるようなRDS定義に準拠する(DE−1、DE−2、context_information)のフォーマットで生成され得る。
ステップ4で、生成されたRDSは、指定されたアドレスに配信される。典型的には、RDS配信は、以下のオプションを有し得る。
オプション1について、RDSアセンブリングRDPは、RDSデータサンプルをDSCR−1のユーザに1つずつ送信し得る。
オプション2について、RDSアセンブリングRDPは、バッチで(例えば、100個のRDSサンプル毎に)RDSを送信し得る。
オプション3について、RDSアセンブリングRDPは、DSCR−1のユーザによって要求されるような特定のタイムポイントでRDSデータサンプルを送信し得る。
さらに/または、オプション4について、RDSアセンブリングRDPは、RDSをローカルに記憶し、DSCR−1のユーザがデータを引き戻すことを可能にし得る。
提案されたDSCSソリューションは、図15に示されるように、oneM2Mサービス層での新しいCSFと見なされ得る。異なるタイプのM2Mノードは、IoTデバイス、M2Mゲートウェイ、M2Mサーバ、(車両、携帯電話などの)モバイルノードなどのDSCSサービスを実装し得ることを理解されたい。特に、それらのノードのための種々の/異なるハードウェア/ソフトウェア能力に応じて、それらのノードによって実装されるDSCSサービスの能力もまた、異なり得る。
定義される関連エンティティについてのoneM2M実施形態は、以下のようである。
データソース(DS)は、oneM2M AEまたはCSEであり得る。故に、AEまたはCSEによって生成される未加工データは、DS識別プロセスの間にoneM2Mリソース発見を介して識別され得る、<container>、<timeSeries>、または<flexContainer>リソースで記憶され得る。
ローカルフォグノード(LFN)は、oneM2M CSE(例えば、ASN−CSE)であり得る。
LFNリーダー(LFNL)およびフォグノード(FN)は、(MN−CSEなどの)oneM2M CSEであり得る。
クラウドノード(CN)は、(IN−CSEなどの)oneM2M CSEであり得る。
DSCSユーザは、oneM2M AE(例えば、IN−AE)またはCSEであり得る。
<dscs>と呼ばれる新しい仮想リソースが図16に示される。CSEがDSCS能力を有する(例えば、DSCSエージェントがこのCSE上で実行している)場合、それは<dscs>子リソースを有し得る。すべてのDSCS関連要求は、このリソースに向けて行われ得る。例えば、ユーザは、DSCR作成要求を、CSE−1上でホストされる<dscs>リソースに送信し得る。同様に、CSE−1が、DSCR−1についてDS識別を行うことを意図するとき、それは、DSCR−1を、LFA内の別のCSE−2によってホストされる<dscs>リソースに送信し得、それは、LFNLとして機能し、このLFA内のLFNによって行われる、すべてのDS識別およびRDS生成アクティビティを管理およびコーディネートする。(LFNとしての)CSEが、その能力を、LFNLとして機能する別のCSEに登録するとき、<lfnCapability>リソースは、LFNL上で機能するCSE上で作成され得る。このリソースは、所与のLFNが提供し得る能力(例えば、DSD、RDC、および/またはRDPとして機能し得るかどうか)についてのすべての情報を説明し得る。加えて、LFNLとLFNとの間のすべての通信について(例えば、LFNLが、RDCもしくはRDP関連タスクをLFNに割り当てるか、またはLFNLが、割り当てられたRDCもしくはRDP関連タスクを開始するために、トリガをLFNに送信するとき)、要求オリジネータ(例えばLFNLとして機能するCSE)は、それらの要求をレシーバの<dscs>リソース(例えば、LFNLによって管理される、LFNとして機能するCSE)に向けて送信し得る。
DSCSを曝すための代替の方法は、「dscs_capability」と呼ばれる新しい属性が、<CSE>リソースについて定義されることであり、それは、このCSEがDSCS能力を有するかどうかを示し得る。故に、すべてのDSCS関連要求は、<CSEBase>リソースに向けて送信され得る。
新しい<lfnCapability>リソースは、LFNの能力を記録する(例えば、LFNがその能力を対応するLFNLに登録するとき、<lfnCapability>リソースが作成され得る)ように提案される。リソース属性は、表9で定義されるパラメータに対応し得る。
通常、LFN(例えば、CSE−1)が、その能力を、LFNLとして機能する別のCSE−2に登録するとき、<lfnCapability>リソースは、LFNL上で機能するCSE−2上で作成され得る。例えば、<lfnCapability>リソースは、CSE−2の<CSEBase>リソースの子リソースとして機能し得る。追加でまたは代替で、<lfnCapability>リソースは、LFNとして機能するCSE−1の<remoteCSE>リソースの子リソースとして機能し得る。
「lfnCapability」と呼ばれる新しい属性はまた、CSE−1のLFN能力を示すために使用され得る、LFNとして機能するCSE−1の<remoteCSE>リソースについて定義され得る。<lfnCapability>リソースは、表10で規定される子リソースを含み得る。
<lfnCapability>リソースは、表11(表11−1〜表11−2)で規定される属性を含み得る。
表12に示されるプロシージャは、<lfnCapability>リソースを作成するために使用され得る。
表13に示されるプロシージャは、<lfnCapability>リソースの属性を読み出すために使用され得る。
表14に示されるプロシージャは、<lfnCapability>リソースの属性を更新するために使用され得る。
表15に示されるプロシージャは、<lfnCapability>リソースを削除するために使用され得る。
例示的GUIインターフェースは図25で開示され、それは、人間ユーザのためにDS識別およびRDS生成プロセスを監視するために使用され得る。インターフェースを使用するユーザは、どの特定のLFAをチェックしたいと思うかについてのいくつかの一般的な情報を規定し得る。一例では、ユーザは、このユーザインターフェースを使用するための2つの方法を有し得る。第1に、ユーザは、特定の役割(例えば、RDCまたはRDP)として機能するLFNをチェックし得る。故に、選択された役割として機能するすべてのLFNは、ユーザがレビューするために表示され得る。第2に、ユーザは、特定のLFNのIDを直接入力し得る。故に、このLFNのすべての登録された能力(例えば、そのRDC能力、DSD能力、またはRDP能力)は、レビューのためにユーザに表示され得る。
サービス層、サービス層デバイス、サービス層アプリケーション、アプリケーションエンティティなどの、図1、図4〜図14、および図18〜図24に図示されるステップを実行する、任意のエンティティは、無線および/もしくはネットワーク通信のために構成された装置、または図26Cもしくは図26Dに図示されるものなどのコンピュータシステムのメモリで記憶され、それらのプロセッサ上で実行する、ソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであり得る。すなわち、図1、図4〜図14、および図18〜図24に図示される方法は、図26Cまたは図26Dに図示される装置またはコンピュータシステムなどの装置のメモリで記憶されるソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図1、図4〜図14、および図18〜図24に図示されるステップを実行する。図1、図4〜図14、および図18〜図24に図示される任意の伝送および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令(例えば、ソフトウェア)の制御下で、装置/エンティティの通信回路によって実行され得ることもまた理解される。
図26Aは、1つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(Web of Things:WoT)通信システム10の図である。概して、M2M技術は、IoT/WoTのための構築ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、M2Mサーバ、またはM2Mサービスプラットフォームは、IoT/WoTのコンポーネントまたは装置、およびIoT/WoTサービス層などであり得る。図1〜図25のいずれかに図示されるエンティティのいずれかは、図26A〜図26Dに図示されるものなどの通信システムのネットワーク装置を備え得る。
サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、HTTP、CoAP、またはMQTTなどのアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、例えば、制御層およびトランスポート/アクセス層などの下位リソース層におけるコアネットワークへのインターフェースを提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシー管理、アクセス制御、およびサービスクラスタ化を含む、(サービス)能力または機能性の複数のカテゴリをサポートする。近年、いくつかの業界規格団体、例えば、oneM2Mが、インターネット/ウェブ、セルラー、企業、およびホームネットワークなどの展開へのM2Mタイプのデバイスおよびアプリケーションの統合に伴う課題に対処するように、M2Mサービス層を開発している。M2Mサービス層は、CSEまたはサービス能力層(Service Capability Layer:SCL)と称され得る、サービス層によってサポートされる上記の能力または機能性の集合またはセットへのアクセスをアプリケーションおよび/または種々のデバイスに提供し得る。いくつかの例は、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含むが、それらに限定されない。これらの能力または機能性は、M2Mサービス層によって定義される、メッセージフォーマット、リソース構造、およびリソース表現を利用するアプリケーションプログラミングインターフェース(Application Programming Interface:API)を介して、そのような種々のアプリケーションに利用可能にされる。CSEまたはSCLは、ハードウェアおよび/またはソフトウェアによって実装され得、それらがそのような能力または機能性を使用するために、種々のアプリケーションおよび/またはデバイス(すなわち、そのような機能エンティティ間の機能インターフェース)に曝される(サービス)能力または機能性を提供する、機能エンティティである。
図26Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、イーサネット、ファイバ、ISDN、PLCなど)もしくは無線ネットワーク(例えば、WLAN、セルラーなど)、または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のユーザに提供する、多重アクセスネットワークで構成され得る。例えば、通信ネットワーク12は、符号分割多重アクセス(Code Division Multiple Access:CDMA)、時分割多重アクセス(Time Division Multiple Access:TDMA)、周波数分割多重アクセス(Frequency Division Multiple Access:FDMA)、直交FDMA(Orthogonal FDMA:OFDMA)、単一キャリアFDMA(Single-Carrier FDMA:SC−FDMA)などの1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを備え得る。
図26Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインと、を含み得る。インフラストラクチャドメインは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインは、通常は、M2Mゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの種々の異なるネットワーク装置(例えば、サーバ、ゲートウェイ、デバイスなど)を備え得る。例えば、フィールドドメインは、M2Mゲートウェイ14と、デバイス18と、を含み得る。任意の数のM2Mゲートウェイデバイス14およびM2Mデバイス18が、所望に応じてM2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2Mデバイス18の各々は、通信回路を使用して、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成されている。
M2Mゲートウェイ14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12などのオペレータネットワークを介して、または直接無線リンクを介してのいずれかで、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20または他のM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービス層22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2Mデバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee、6LoWPAN、Bluetooth)、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。例示的M2Mデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。
図26Bを参照すると、フィールドドメイン内の図示されたM2Mサービス層22は、M2Mアプリケーション20、M2Mゲートウェイ14、およびM2Mデバイス18、ならびに通信ネットワーク12のためのサービスを提供する。M2Mサービス層22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイ14、M2Mデバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、サーバ、コンピュータ、デバイスなどを備え得る、ネットワークの1つ以上のネットワーク装置によって実装され得る。M2Mサービス層22は、M2Mデバイス18、M2Mゲートウェイ14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドでなど、種々の方法で実装され得る。
図示されたM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’がある。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および下層通信ネットワーク12のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイ14およびM2Mデバイス18のためのサービスを提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイ、およびM2Mデバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによるサービス層と相互作用し得る。M2Mサービス層22’は、サーバ、コンピュータ、デバイス、仮想マシン(例えば、クラウドコンピューティング/記憶ファームなど)などを備え得る、ネットワークの1つ以上のネットワーク装置によって実装され得る。
また、図26Bも参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよびバーティカルが活用し得る、サービス配信能力のコアセットを提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス/デバイス発見などの機能を実行することを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を低減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、ネットワーク12などの種々のネットワークを介して通信することを可能にする。
M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視などの種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、サーバ、および他のネットワーク装置の間で実行するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合などの機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
概して、図26Bに図示されるサービス層22および22’などのサービス層は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースのセットを介して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ETSI M2MおよびoneM2Mアーキテクチャは両方とも、サービス層を定義する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、ETSI M2Mアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、M2Mデバイス(デバイスSCL(Device SCL:DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(Gateway SCL:GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(Network SCL:NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)のセットをサポートする。1つ以上の特定のタイプのCSFのセットのインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上にホストされ得る、共通サービスエンティティ(CSE)と称される。第3世代パートナーシッププロジェクト(Third Generation Partnership Project:3GPP)はまた、マシンタイプ通信(Machine-Type Communication:MTC)のためのアーキテクチャを定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ(Service Capability Server:SCS)の一部として実装される。ETSI M2MアーキテクチャのDSCL、GSCL、またはNSCLで、3GPP MTCアーキテクチャのサービス能力サーバ(SCS)で、oneM2MアーキテクチャのCSFもしくはCSEで、またはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイス、もしくはノードを含む、ネットワーク内の1つ以上の独立型ノード上で、または1つ以上の既存のノードの一部としてのいずれかで実行する、論理エンティティ(例えば、ソフトウェア、コンピュータ実行可能命令など)として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図26Cまたは図26Dで図示される一般アーキテクチャを有する、ネットワーク装置(例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど)上で実行するソフトウェアの形態で実装され得る。
さらに、本明細書で説明される方法および機能性は、サービスにアクセスするために、サービス指向アーキテクチャ(Service Oriented Architecture:SOA)および/またはリソース指向アーキテクチャ(Resource-Oriented Architecture:ROA)を使用する、M2Mネットワークの一部として実装され得る。
展開の観点から、サービス層は、本明細書の種々の図に示されるような、サーバ、ゲートウェイ、およびデバイスを含む、種々のタイプのネットワークノード上で展開され得る。サービス層機能性を実装するか、またはそうでない場合、サービス層のインスタンスを組み込む、通信ネットワークの任意のそのようなノード、サーバ、ゲートウェイ、デバイス、装置、または他の論理エンティティは、本明細書でサービス層エンティティと称され得る。
図26Cは、図1〜図25に図示されるエンティティのうちの1つなどの、ネットワークの装置の例示的ハードウェア/ソフトウェアアーキテクチャのブロック図であり、それは、図26Aおよび図26Bに図示されるものなどのM2Mネットワーク内の、M2Mサーバ、ゲートウェイ、デバイス、または他のネットワーク装置として動作し得る。図26Cに示されるように、ネットワーク装置30は、プロセッサ32と、非取り外し可能メモリ44と、取り外し可能メモリ46と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ、タッチパッド、および/またはインジケータ42と、電源48と、全地球測位システム(Global Positioning System:GPS)チップセット50と、他の周辺機器52と、を含み得る。ネットワーク装置30はまた、送受信機34および伝送/受信要素36などの通信回路を含み得る。ネットワーク装置30は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このネットワーク装置は、図1〜図25と関連して図示および説明される方法および動作などの、フォグベースのデータ保護を有効にするためのデータサンプルテンプレート(DST)管理のための方法を実装する装置であり得る。
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(Digital Signal Processor:DSP)、複数のマイクロプロセッサ、DSPコアに対応付けられた1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(Application Specific Integrated Circuit:ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA)回路、任意の他のタイプの集積回路(Integrated Circuit:IC)、状態マシンなどであり得る。一般に、プロセッサ32は、ネットワーク装置の種々の要求された機能を実行するために、ネットワーク装置のメモリ(例えば、メモリ44および/またはメモリ46)内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ32は、信号符号化、データ処理、電力制御、入力/出力処理、および/またはネットワーク装置30が無線もしくは有線環境内で動作することを可能にする、任意の他の機能性を実行し得る。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/もしくは無線アクセス層(Radio Access-Layer:RAN)プログラムならびに/または他の通信プログラムを実行し得る。プロセッサ32はまた、例えば、アクセス層および/またはアプリケーション層などで、認証、セキュリティキー一致、および/または暗号化動作などのセキュリティ動作を実行し得る。
図26Cに示されるように、プロセッサ32は、その通信回路(例えば、送受信機34および伝送/受信要素36)に接続されている。プロセッサ32は、コンピュータ実行可能命令の実行を介して、それが接続されるネットワークを介してネットワーク装置30を他のネットワーク装置と通信させるために、通信回路を制御し得る。特に、プロセッサ32は、本明細書(例えば、図1〜図25)および請求項で説明される伝送および受信ステップを実行するために、通信回路を制御し得る。図26Cは、個別のコンポーネントとしてプロセッサ32および送受信機34を描写しているが、プロセッサ32および送受信機34が、電子パッケージまたはチップ内に一緒に統合され得ることを理解されるであろう。
伝送/受信要素36は、M2Mサーバ、ゲートウェイ、デバイスなどを含む、他のネットワーク装置に信号を伝送するか、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されたアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラーなどの種々のネットワークおよびエアインターフェースをサポートし得る。実施形態では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送および/または受信するように構成されたエミッタ/検出器であり得る。さらに別の実施形態では、伝送/受信要素36は、RFおよび光信号の両方を伝送および受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図26Cで描写されているが、ネットワーク装置30は、任意の数の伝送/受信要素36を含み得る。より具体的には、ネットワーク装置30は、MIMO技術を採用し得る。したがって、実施形態では、ネットワーク装置30は、無線信号を伝送および受信するための2つ以上の伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送されることになる信号を変調し、伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、ネットワーク装置30は、マルチモード能力を有し得る。したがって、送受信機34は、ネットワーク装置30が、例えば、UTRAおよびIEEE802.11などの複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46などの任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ32は、上で説明されるように、セッションコンテキストをそのメモリに記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(Random-Access Memory:RAM)、読み取り専用メモリ(Read-Only Memory:ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、加入者識別モジュール(Subscriber Identity Module:SIM)カード、メモリスティック、セキュアデジタル(Secure Digital:SD)メモリカードなどを含み得る。他の実施形態では、プロセッサ32は、サーバまたはホームコンピュータ上などのネットワーク装置30上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ32は、装置のステータスを反映するため、または装置、特に、下層ネットワーク、アプリケーション、もしくはネットワーク装置と通信する他のサービスを構成するために、ディスプレイまたはインジケータ42上で点灯パターン、画像、または色を制御するように構成され得る。一実施形態では、ディスプレイ/インジケータ42は、図26Dに図示され本明細書で説明されるグラフィカルユーザインターフェースを提示し得る。
プロセッサ32は、電源48から電力を受信し得、ネットワーク装置30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、ネットワーク装置30に給電するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル金属水素(NiMH)、リチウムイオン(Li−ion)など)、太陽電池、燃料電池などを含み得る。
プロセッサ32はまた、ネットワーク装置30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成された、GPSチップセット50に接続され得る。ネットワーク装置30は、実施形態と一致したままで、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ32はさらに、追加の特徴、機能性、および/または有線もしくは無線コネクティビティを提供する、1つ以上のソフトウェアおよび/またはハードウェアモジュールを含み得る、他の周辺機器52に接続され得る。例えば、周辺機器52は、加速度計、バイオメトリック(例えば、指紋)センサなどの種々のセンサ、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(Universal Serial Bus:USB)ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(Frequency Modulated:FM)無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
ネットワーク装置30は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはe−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機などの車両などの他の装置またはデバイスで具現化され得る。ネットワーク装置30は、周辺機器52のうちの1つを備え得る相互接続インターフェースなどの1つ以上の相互接続インターフェースを介して、そのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。
図26Dは、図1〜図25に図示され本明細書で説明されるエンティティなどの、ネットワークの1つ以上のネットワーク装置を実装するために使用され得る、例示的コンピューティングシステム90のブロック図であり、それは、図26Aおよび図26Bに図示されるものなどのM2Mネットワーク内の、M2Mサーバ、ゲートウェイ、デバイス、または他のネットワーク装置として動作し得る。
コンピューティングシステム90は、コンピュータまたはサーバを備え得、ソフトウェアの形態(そのようなソフトウェアが記憶されるかまたはアクセスされる場所または手段がいかなるものであっても)であり得るコンピュータ可読命令によって主に制御され得る。そのようなコンピュータ可読命令は、コンピューティングシステム90を機能させるように、中央処理装置(Central Processing Unit:CPU)91などのプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンでは、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を実行するか、またはCPU91を支援する、主要CPU91とは明確に異なる、任意選択的なプロセッサである。CPU91および/またはコプロセッサ81は、セッション証明書の受信またはセッション証明書に基づく認証などのE2E M2Mサービス層セッションのための開示されたシステムおよび方法に関連するデータを受信、生成、および処理し得る。
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム90内のコンポーネント同士を接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインと、を含む。そのようなシステムバス80の例は、周辺コンポーネント相互接続(Peripheral Component Interconnect:PCI)バスである。
システムバス80に接続されたメモリは、ランダムアクセスメモリ(RAM)82と、読み取り専用メモリ(ROM)93と、を含む。このようなメモリは、情報が記憶され、かつ読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正することができない記憶されたデータを含む。RAM82内に記憶されるデータは、CPU91または他のハードウェアデバイスによって読み取られるか、または変更され得る。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第1のモードで実行するプログラムは、それ自体のプロセス仮想アドレス空間によってマップされているメモリのみにアクセスし得、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピューティングシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85などの周辺機器に命令を通信することを担う、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピューティングシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。ディスプレイ86は、CPU91によって実行されるコンピュータ実行可能命令と組み合わせて、図26Dおよびその付随の説明で図示および説明されるグラフィカルユーザインターフェースを生成し動作させ得る。
さらに、コンピューティングシステム90は、コンピューティングシステム90がネットワークの他の装置と通信することを可能にするように、図26A〜図26Dのネットワーク12などの外部通信ネットワークにコンピューティングシステム90を接続するために使用され得る、例えば、ネットワークアダプタ97などの通信回路を含み得る。通信回路は、単独で、またはCPU91と組み合わせて、本明細書(例えば、図1〜図25)および請求項で説明される、伝送および受信ステップを実行するために使用され得る。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたはすべては、コンピュータ可読記憶媒体上に記憶されるコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得、その命令は、例えば、M2Mサーバ、ゲートウェイ、デバイスなどを含む、M2Mネットワークの装置などのマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを実行および/または実装することが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ可読記憶媒体は、情報の記憶のための任意の非一過性(すなわち、有形または物理)方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD−ROM、デジタル多用途ディスク(Digital Versatile Disks:DVD)もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、かつコンピュータによってアクセスされ得る任意の他の有形もしくは物理媒体を含むが、それらに限定されない。
以下の表16は、上記の説明で現れ得るサービス層技術に関連する頭字語のリストである。特に規定されない限り、本明細書で使用される頭字語は、以下でリストされる対応する用語を指す。
以下の表17−1〜表17−3は、上記の説明で現れ得るサービス層技術に関連する用語および定義のリストである。特に規定されない限り、本明細書で使用される用語および定義は、以下でリストされる対応する用語を指す。
ここで記載された説明は、例を使用して、ベストモードを含む本発明を開示し、当業者が、任意のデバイスまたはシステムを製造および使用し、任意の組み込まれた方法を実施することを含む本発明を実施することを可能にもする。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る。そのような他の例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。