JP6405416B2 - データ送信システム、及びデータ送信方法 - Google Patents

Description

本発明は、データ送信システム、及びデータ送信方法に関する。

クラウド計算機、又は送信装置からのネットワークを介してネットワーク計算機に定期的にデータを送信する、ある種のデバイスがある。ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の出現とともに、ネットワーク計算機への従来のデータ送信モデルは不十分なものとなっている。特に、大量のＩｏＴデバイスが、従来のアプリケーションやデバイスが生成するデータよりも、著しく大容量の、高速で、かつ多種のデータを同時に生成する可能性がある。例えば、これら全てのデータを、ネットワークを介して１以上の他のネットワーク計算機へ中央処理のために送信しようとする場合、アプリケーション及び／又はネットワークに、遅延やエラー等が発生するおそれがある。

従来、例えば米国特許出願公開第２０１２／０１７２６７２号明細書（特許文献１）に記載されているように、各パケットのペイロードに対する個別制御が上記問題を解決している。

米国特許出願公開第２０１２／０１７２６７２号明細書

しかし、モバイル通信及びセルラー通信の分野においては、ネットワーク接続の信頼性が下がることがあり、これがデータ送信におけるパケットロスや遅延等を引き起こしたり、ネットワーク計算機へのデータ送信が複雑化したりする。

上記課題を解決するために、本発明の一態様は以下の構成を採用する。１以上のプロセッサと、コンピュータ読み取り可能な１以上の非一時的媒体と、を含むシステムであって、前記１以上の非一時的媒体は、前記１以上のプロセッサに実行された場合に、前記１以上のプロセッサに処理を実行させるようプログラムする実行可能指示を保持し、前記処理は、ネットワークの障害の発生予測を決定する第１決定処理と、前記障害の発生中に受信すると予想される１以上のデータ種別の優先度を決定し、前記１以上のデータ種別の遅延カテゴリを決定する第２決定処理と、前記優先度及び前記遅延カテゴリに基づいて、前記１以上のデータ種別のためのデータ送信ルールを格納する格納処理と、前記ネットワークに送信するためのデータを、前記障害の発生中に、１以上のデータ生成器から受信する受信処理と、前記データ送信ルールに基づいて、前記受信したデータの少なくとも一部を前記ネットワークに送信する送信処理と、を含む、システム。

本発明の一態様によれば、ネットワーク接続の信頼性に応じた適切なデータ送信を行うことができる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本実施例におけるシステムの構成例を示す。 本実施例におけるデータ送信のタイムラインの一例を示す。 本実施例における、ネットワーク障害の観点から示されるデータ送信の一例を示す。 本実施例における送信ルール決定及び送信ルール適用の一例を示す。 本実施例におけるデータプロファイルデータ構造体の一例を示す。 本実施例におけるルール決定及び適用のタイミングの一例を示す。 本実施例における相対的チャネル容量の一例を示す。 本実施例における圧縮を含むルール決定の一例を示す。 本実施例におけるデータ圧縮階層の一例を示す。 本実施例におけるルール決定処理の一例を示すフローチャートである。 本実施例におけるルールデータ構造体の一例を示す。 本実施例におけるデータ送信ルール適用モジュールの動作例を示す。 本実施例におけるデータ送信のためのデータ選択及び生成の一例を示す。 本実施例におけるデータ送信のためのデータ選択及び生成の一例を示す。 本実施例におけるデータ送信のためのデータ選択及び生成の一例を示す。 本実施例におけるデータ送受信処理の一例を示すフローチャートである。

以下の詳細な説明は、添付の図面を参照して記述されている。図面において、参照符号の最も左の桁によって、当該参照符号の初出の図面を識別することができる。同様又は同一の項目又は特徴については、異なる図面においても同一の参照符号が用いられる。

ネットワークの特徴及び送信されるデータの特徴に従った、ネットワークを介したデータ送信を管理するための構成及び技術を含む実装がある。例えば、計算機は、例えばまもなく、ネットワーク障害が発生すると予測してもよい。当該計算機は、ネットワーク障害中に受信すると予測された１以上のデータ種別に関連付けられた優先度を決定してもよい。さらに、計算機は、ネットワーク障害中に受信すると予測された１以上のデータ種別の遅延カテゴリを決定してもよい。計算機は、当該１以上のデータ種別のためのデータ送信ルールを、少なくとも部分的には各々の優先度及び遅延カテゴリに基づいて、決定してもよい。障害発生前又は障害発生中において、計算機は、１以上のデータ生成器から、ネットワークに送信するためのデータを受信してもよい。ネットワークが利用可能になったとき、計算機は、少なくとも部分的にはデータ送信ルールに基づいて、受信したデータの少なくとも一部をネットワークに送信してもよい。

計算機が、ネットワーク状態履歴情報及び計算機の現在の地理的位置の示唆に基づいて、ネットワーク障害の発生を予測してもよい例がある。さらに、計算機は、障害発生前及び／又は障害発生中に、第１センサからの第１データと、第２センサからの第２データと、を受信してもよい。障害が終わった後、計算機は、第１データに関連付けられた第１優先度と第１遅延カテゴリに基づいて、第１データの少なくとも一部を送信してもよく、第２データに関連付けられた第２優先度と第２遅延カテゴリに基づいて、第２データの少なくとも一部を送信してもよい。

本実施形態に記載の実施例は、送信ネットワークの特徴及び送信されるデータの特徴に従う、データ送信の管理を含むデータのエッジ処理のための技術及び手順のために用意されている。例えば、本実施形態中のデータ送信技術は、データ量、データ速度、及びデータの種類を減少させるための、及び実施例においてクラウド計算機とも呼ばれることがある１以上の計算機にネットワークを介してデータを送信するための、生成済みデータに対する意思決定の分散を含んでもよい。従って、本実施形態中の例は、ネットワーク計算機に送信されるデータのフィルタリング及び／又は圧縮のための意思決定の分散を可能にする。

計算機が、送信に優先して、無線ネットワークの現在の示唆された信号品質及び／又は無線ネットワークの予測された信号品質に基づいて、アプリケーションレベルでのデータの解像度を減少させる（例えばデータ圧縮）実装がある。例えば、計算機の現在位置、信号品質履歴及び他のネットワーク状態履歴、又は信号品質データベース等に基づいて、計算機は近い将来における無線ネットワークの信号品質を予測する。計算機は、無線ネットワークの信号品質の未来の予測値を、次回の１以上の時間間隔において用いてもよいし、現在の時間間隔において送信するデータ及び未来の時間間隔において送信するデータを決定するために、リソースの割り当てと、受信したＩｏＴデータの圧縮と、を実行してもよい。

本議論の目的のために、無線ネットワークを介してデータを送信する計算機の環境における実装例が記述されており、また、計算機は携帯可能であってもよい例もある。しかし、本実施形態は、当業者にとって明白となるように、以下に記載する特定の例に限定されず、本実施形態の観点に照らして、他種の計算機、他種のデータ、他種の環境、他のシステム構成等に拡張されてもよい。

図１は、本実施例におけるシステム１００の構成例を示す。システム１００は、例えば、１以上のネットワーク１０６を介して少なくとも１つのネットワーク計算機１０４と通信可能な、少なくとも１つの計算機１０２を含む。計算機１０２は、例えば、デスクトップ、ワークステーション、サーバ、ラップトップ、タブレット計算機、携帯デバイス、スマートフォン、携帯電話、ウェアラブル計算機、ビークルエレクトロニックコントロールユニット（ＥＣＵ）等、又は埋め込み計算機等のような、ネットワークを介してデータを送信可能な種々の計算機のいずれであってもよい。

いくつかの例において、計算機１０２は、ＩｏＴデータ１０８を１以上のデータ生成器１１０から受信してもよく、さらに、ネットワーク１０６を介してデータ１０８の少なくとも一部を、データ送信１１２として送信してもよい。例えば、データ生成器１１０は、カメラ、マイク、グローバルポジショニングシステム（ＧＰＳ）装置、身体状態センサ、輸送機器センサ、他の機器のためのセンサ、並びに人間、動物、及び局所的状態のためのセンサ等のような種々のセンサ、を含むＩｏＴデバイスのいずれであってもよい。さらに、データ１０８は、センサデータに加え、データ生成器１１０及び／又は計算機１０２によって生成された他の種別のデータ等を含んでもよい。

計算機１０２は、様々な環境におかれてもよい。一例として、計算機１０２は、自動車、トラック、列車、ボート、飛行機、ドローン、又はオートバイ等の輸送機器１１４−１に埋め込まれていてもよいし、含まれていてもよい。例えば、データ生成器１１０は、位置情報、速度情報、機械状態情報、燃料情報、運転者情報、及び自律航法情報等の、ネットワーク計算機１０４に送信される当該輸送機器についての情報を供給してもよい。

他の例として、計算機１０２は、人１１４−２によって着用されてもよいし、運搬されてもよい。また、計算機１０２は、スマートフォン、携帯電話、ウェアラブル計算機、フィットネストラッカー、又は他の携帯可能なデバイス等の、持ち運び可能な計算機を含んでもよい。例えば、データ生成器１１０が、心拍計、血糖計、又はフィットネストラッキングセンサ等の身体状態センサを含むと仮定する。歩行中、走行中、又は輸送機器による移動中のような、移動時において、人１１４−２が計算機１０２を持ち運びしてもよい例がある。

また、他の例として、計算機１０２が設置される環境は、家屋１１４−３、職場１１４−４、又は移動体でない他の場所であってもよい。さらに、通信能力及びデータ処理能力を有する、サーモスタット、アラームシステム、又はアプライアンス等のように、計算機１０２とデータ生成器１１０とは統合されていてもよい例がある。本開示の受益者である当業者にとって、多くのバリエーションが明らかになるであろう。

計算機１０２は少なくとも１つのプロセッサ１１６、１以上のコンピュータ読み取り可能媒体１１８、及び１以上の通信インタフェース（Ｉ／Ｆ）を含む。プロセッサ１１６それぞれは単一又は複数のプロセッシングユニットであってもよいし、単一若しくは複数のプロセッシングユニット又はマルチ処理コアを含んでもよい。プロセッサ１１６は、１以上のＣＰＵ、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、ＤＳＰ、ステートマシン、論理回路、及び／又は操作指示に基づいて信号を操作する装置として、実装され得る。例えば、プロセッサ１１６は、本実施形態中のアルゴリズム及びプロセスを実行するよう具体的にプログラムされた又は構成された適切な種別の１以上のハードウェアプロセッサ及び／又は論理回路であってもよい。プロセッサ１１６に本実施形態中の機能を実行させるようプログラムすることができる、コンピュータ読み取り可能媒体１１８に格納されたコンピュータ読み取り可能な指示、を取得し実行するように、プロセッサ１１６が構成されてもよい。

コンピュータ読み取り可能媒体１１８は、コンピュータ読み取り可能な指示、データ構造体、プログラムモジュール、又は他のデータのような情報、を格納するためのあらゆる種類のテクノロジーに実装された揮発性メモリ及び不揮発性メモリ、並びに／又はリムーバブルメディア及びノンリムーバブルメディアを含んでもよい。例えば、コンピュータ読み取り可能媒体１１８は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ若しくは他のメモリ技術、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワークアタッチトストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報を保持するために利用可能で計算機によってアクセス可能な他の媒体を含んでもよいが、これらに限定されるものではない。コンピュータ読み取り可能な非一時的媒体について言及するときに、エネルギー、搬送波信号、電磁波、及び／又は信号それ自体のような媒体を除外する限り、ネットワーク計算機１０４の構成次第でコンピュータ読み取り可能媒体１１８は、有形の非一時的媒体であってもよい。いくつかの場合において、コンピュータ読み取り可能媒体１１８は、計算機１０２と同一の場所にあってもよい。また、他の例において、コンピュータ読み取り可能媒体１１８は、例えばネットワーク１０６を介してアクセス可能である場合のように、一部は計算機１０２の遠隔地にあってもよい。

コンピュータ読み取り可能媒体１１８はプロセッサ１１６によって実行可能な多数の機能部を格納するために利用されてもよい。多くの実装において、これらの機能部は、プロセッサ１１６によって実行可能な指示又はプログラムを含み、これらの指示又はプログラムが実行された場合、計算機１０２に起因する動作をプロセッサ１１６に具体的に実行させる。コンピュータ読み取り可能媒体１１８に格納された機能部は、データ管理アプリケーション１２２を含んでもよい。データ管理アプリケーション１２２は、１以上のコンピュータプログラム、コンピュータ読み取り可能な指示、実行可能コード、又は実行可能モジュール、又はこれらの一部を含んでもよい。当該一部は、データ１０８の受信及びネットワーク計算機１０４へのデータ送信１１２の送信等の様々なタスクをプロセッサ１１６に実行させることができる。加えて、計算機１０２は、計算機１０２の様々な機能を制御及び管理するオペレーティングシステム（図１において不図示）を含んでもよい例がある。機能部はコンピュータ読み取り可能媒体１１８の記憶部に格納され、コンピュータ読み取り可能媒体１１８のローカルメモリ部にロードされ、１以上のプロセッサ１１６によって実行されてもよい例がある。多くの他のソフトウェア構成及び／又はハードウェア構成は、本開示の受益者である当業者にとって明らかになるであろう。

加えて、コンピュータ読み取り可能媒体１１８は、本実施形態中の機能及びサービスを実行するために用いられるデータ及びデータ構造体を格納してもよい。例えば、コンピュータ読み取り可能媒体１１８は、データ１０８を対応するデータ送信１１２がネットワーク計算機１０４に送信されるまで少なくとも一時的に格納するために、データバッファ及び／又はデータストレージ１２４を含む。また、計算機１０２は、プログラム、ドライバ等、及び機能部に利用又は生成される他のデータを含む、他の機能部、データ、及びデータ構造体を含んでもよい又は保持してもよい。さらに、計算機１０２は、多くの他の論理的構成、プログラム的構成、及び物理的構成を含んでもよく、上述した構成は、本実施形態における議論に関連する単なる例でしかない。

通信インタフェース１２０は、例えば１以上のネットワーク１０６を介して様々な他の機器との通信を可能にするために、１以上のインタフェース及びハードウェアコンポーネントを含んでもよい。従って、通信インタフェース１２０は、ネットワーク計算機１０４と通信するためのネットワーク１０６への接続を提供する１以上のポートを含んでもよい、又は当該ポートに接続されていてもよい。例えば、通信インタフェース１２０は、ＢｌｕｅＴｏｏｔｈ（登録商標、以下同）及びＺｉｇＢｅｅ（登録商標、以下同）等のような近距離通信だけでなく、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えばＷｉ−Ｆｉ（登録商標、以下同））及び有線ネットワーク（例えば光ファイバ、イーサネット（登録商標、以下同）、ファイバチャネル）、並びに直接接続、のうちの１以上を介した通信を可能にしてもよい。但し、本実施形態において、必要な通信を他の箇所に追加的に列挙することもある。さらに、データ生成器１１０が通信インタフェース１２０を介して計算機１０２と通信してもよい例があり、データ生成器１１０が計算機１０２に直接接続又は統合されている例もある。

ネットワーク計算機１０４は、１以上のサーバ、パーソナルコンピュータ、又は多くの方法で具現化され得る他種の計算機を含んでもよい例がある。例えば、サーバの場合、モジュール、他の機能部、及び少なくとも一部のデータストレージは、例えば、サーバ群、サーバファーム又はデータセンタ、及びクラウドホスティングサービス等のうちの少なくとも１つのサーバに実装されてもよいが、他の計算機構成を追加してもよいし、他の計算機構成に代替されてもよい。図示された例において、ネットワーク計算機１０４は、１以上のプロセッサ１２６、１以上の通信インタフェース１３０、及び１以上のコンピュータ読み取り可能媒体１２８を含む、又はこれらと関連付けられている。

プロセッサ１２６それぞれは単一又は複数のプロセッシングユニットであってもよいし、単一若しくは複数のプロセッシングユニット又はマルチ処理コアを含んでもよい。プロセッサ１２６は、１以上のＣＰＵ、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、ＤＳＰ、ステートマシン、論理回路、及び／又は操作指示に基づいて信号を操作する装置として、実装され得る。例えば、プロセッサ１２６は、本実施形態中のアルゴリズム及びプロセスを実行するよう具体的にプログラムされた又は構成された適切な種別の１以上のハードウェアプロセッサ及び／又は論理回路であってもよい。プロセッサ１２６は、プロセッサ１２６に本実施形態中の機能を実行させることができる、コンピュータ読み取り可能媒体１２８に格納されたコンピュータ読み取り可能な指示、を取得し実行するよう構成されてもよい。

コンピュータ読み取り可能媒体１２８は、コンピュータ読み取り可能な指示、データ構造体、プログラムモジュール、又は他のデータのような情報、を格納するためのあらゆる種類のテクノロジーに実装された揮発性メモリ及び不揮発性メモリ、並びに／又はリムーバブルメディア及びノンリムーバブルメディアを含んでもよい。例えば、コンピュータ読み取り可能媒体１２８は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ若しくは他のメモリ技術、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワークアタッチトストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報を保持するために利用可能で計算機によってアクセス可能な他の媒体を含んでもよいが、これらに限定されるものではない。コンピュータ読み取り可能な非一時的媒体について言及するときに、エネルギー、搬送波信号、電磁波、及び／又は信号それ自体のような媒体を除外する限り、ネットワーク計算機１０４の構成次第でコンピュータ読み取り可能媒体１１８は、有形の非一時的媒体であってもよい。いくつかの場合において、コンピュータ読み取り可能媒体１２８は、ネットワーク計算機１０４と同一の場所にあってもよい。また、他の例において、コンピュータ読み取り可能媒体１２８は、例えばネットワーク１０６を介してアクセス可能である場合のように、一部はネットワーク計算機１０４の遠隔地にあってもよい。

コンピュータ読み取り可能媒体１２８はプロセッサ１２６によって実行可能な多数の機能部を格納するために利用されてもよい。多くの実装において、これらの機能部は、プロセッサ１２６によって実行可能な指示又はプログラムを含み、これらの指示又はプログラムが実行された場合、計算機１０２に起因する動作をプロセッサ１２６に具体的に実行させる。コンピュータ読み取り可能媒体１２８に格納された機能部は、データ格納・処理アプリケーション１３２を含んでもよい。データ格納・処理アプリケーション１３２は、１以上のコンピュータプログラム、コンピュータ読み取り可能な指示、実行可能コード、又は実行可能モジュール、又はこれらの一部を含んでもよい。当該一部は、計算機１０２が送信したデータの受信及び処理等のための様々なタスクをプロセッサ１２６に実行させることができる。加えて、オペレーティングシステム（図１において不図示）がネットワーク計算機１０４の様々な機能を制御及び管理してもよい例がある。機能部はコンピュータ読み取り可能媒体１２８の記憶部に格納され、コンピュータ読み取り可能媒体１２８のローカルメモリ部にロードされ、１以上のプロセッサ１２６によって実行されてもよい例がある。多くの他のソフトウェア構成及び／又はハードウェア構成は、本開示の受益者である当業者にとって明らかになるであろう。

加えて、コンピュータ読み取り可能媒体１２８は、本実施形態中の機能及びサービスを実行するために用いられるデータ及びデータ構造体を格納してもよい。例えば、コンピュータ読み取り可能媒体１２８は、データ送信１１２を経由して計算機１０２から受信したデータ１３４を格納してもよい。データ１３４がデータ１０８と比較してフィルタリング、圧縮、又は修正されてもよい例がある。また、ネットワーク計算機１０４は、プログラム、ドライバ等、及び機能部に利用又は生成される他のデータを含む、他の機能部、データ、及びデータ構造体を含んでもよい又は保持してもよい。さらに、ネットワーク計算機１０４は、多くの他の論理的構成、プログラム的構成、及び物理的構成を含んでもよく、上述した構成は、本実施形態における議論に関連する単なる例でしかない。

通信インタフェース１３０は、例えば１以上のネットワーク１０６を介して様々な他の機器との通信を可能にするために、１以上のインタフェース及びハードウェアコンポーネントを含んでもよい。従って、通信インタフェース１２０は、計算機１０２と通信するためのネットワーク１０６への接続を提供する１以上のポートを含んでもよい、又は当該ポートに接続されていてもよい。例えば、通信インタフェース１３０は、ＢｌｕｅＴｏｏｔｈ（登録商標、以下同）及びＺｉｇＢｅｅ（登録商標、以下同）等のような近距離通信だけでなく、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えばＷｉ−Ｆｉ（登録商標、以下同））及び有線ネットワーク（例えば光ファイバ、イーサネット（登録商標、以下同）、ファイバチャネル）、並びに直接接続、のうちの１以上を介した通信を可能にしてもよい。但し、本実施形態において、必要な通信を他の箇所に追加的に列挙することもある。

１以上のネットワーク１０６は、イントラネット等のＬＡＮ、インターネット等のＷＡＮ、セルラーネットワーク等の無線ネットワーク、Ｗｉ−Ｆｉのようなローカル無線ネットワーク、及び／又はＢｌｕｅＴｏｏｔｈやＺｉｇＢｅｅ等の近距離無線通信、光ファイバ、イーサネット、及びファイバチャネル等の有線ネットワーク、若しくは他のいかなるネットワーク、又はこれらのネットワークのいかなる組み合わせを含んでもよい。従って、１以上のネットワーク１０６は有線通信技術及び／又は無線通信技術を含んでもよい。このような通信に用いられるための構成は、ネットワーク種別、及び選択された環境の少なくとも一方に部分的に依存し得る。このようなネットワークを介した通信のためのプロトコルは公知であり、ここでは詳細について議論しない。図示された例においては、ネットワーク１０６は、いくつかの例において計算機１０２がデータ送信１１２を送信する際に通信することができる複数の通信塔１３６−１、１３６−２、・・・、を含む。例えば、計算機は、データ送信１１２を送信する通信塔１３６と無線通信をしてもよい。従って、いくつかの例において、ネットワーク計算機１０４及び計算機１０２は、部分的に有線で、部分的に無線で、１以上のネットワーク１０６を介して通信を行うことができる。

図１の例において、データ管理アプリケーション１２２は、ネットワーク１０６を介してデータ１０８の少なくとも一部をネットワーク計算機１０４に送信するために、実行される。しかし、いくつかの場合において、計算機１０２とネットワーク１０６の接続は、不安定又は長く続かないおそれがある。例えば、計算機が移動している（例えば、輸送機器内にある又は人が徒歩によって持ち運んでいる）場合において、計算機１０２は、一時的な信号の損失、干渉、サービスの中断、又は他の障害を引き起こす可能性がある通信塔１３６の範囲に出入りする可能性がある。従って、いくつかの例において、データ管理アプリケーション１２２は、これらの障害を予想する又はこれらの障害に反応してもよく、データ１０８のどの断片が、例えば、障害発生前、障害発生中、又は障害終了後に、ネットワーク計算機１０４に送られたかを管理してもよい。

通常のＩｏＴデバイスのようないくつかの場合において、データ生成器１１０によって生成されたデータ１０８の大半は、決定論的なパターンを有していてもよい。例えば、センサは、固定された間隔で測定結果を報告するようプログラムされていてもよい。従って、データ生成周期及びデータ生成量は、計算機１０２によるデータ１０８の受信に先立って、実質的に認識されている、又は予測可能である可能性がある。受信が予想されるデータに関するこの情報は、計算機１０２によってどのデータ片がどの送信機会の最中に送信されるべきかを決定する処理の一部として、用いられる。例えば、どのデータ片を現在の時間間隔において送信するか、どのデータ片を未来の時間間隔において送信するために保存するか、及びどのデータ片を送信することなく破棄してもよいか、を決定するための、ネットワークについての障害履歴情報又は予測可能な障害情報と、該データの優先度情報及び遅延情報と、とともにデータ１０８の決定論的な又は予測可能なパターンが用いられてもよい。

図２は、本実施例におけるデータ送信のためのタイムライン２００の一例を示す。図２のタイムライン２００の例は、時刻ｔ_０からｔ_３までの無線ネットワークにおける信号品質変化の概要を示す。従って、直線２０２は時間の経過を示す。この場合、ΔＴ_ＰＲＥは、ネットワーク障害発生前の時間間隔２０４を示す。従って、時刻ｔ_０からｔ_１までの期間においてネットワークは利用可能である。加えて、ΔＴ_{ｏｕｔａｇｅ}は時刻ｔ_１からｔ_２までのネットワーク障害中の時間間隔２０６を示す。一例として、セルラーネットワーク内の混雑により当該ネットワークによるサービスが提供されない場所が発生し、当該場所に計算機１０２が位置することに起因する障害がある。当該ネットワーク上のデータ送信速度（例えば最大送信速度等）及びデータ送信の信頼性は、少なくとも部分的にはネットワーク品質及びネットワークの可用性に依存する。さらに、ΔＴ_ｐｏｓｔは、時刻ｔ_２からｔ_３までの、信頼可能なデータ送信のための許容可能な閾値レベルにネットワークサービスが復旧している間における、時間間隔２０８を示す。

図３は、本実施例における、ネットワーク障害の観点から示されるデータ送信の例３００を示す。この例において、破線は、ネットワークを介したデータ送信が可能な複数の送信時点３０２を代表する。一例として、送信時点３０２それぞれは、ＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線通信基準又は他の基準における１ミリ秒のサブフレームに対応してもよいし、送信時点３０２は、ネットワークが利用可能な場合、送信機会と呼ばれてもよい。この例において、送信時点５〜１３は、送信のためのネットワーク利用ができない、又は信頼可能な送信を実行不可能にする超過混雑が発生している可能性がある、時間間隔２０６の間に発生している。上述したようにこの時間間隔はＴ_{ｏｕｔａｇｅ}と呼ばれ、ネットワークサービスが利用できない及び／又はネットワークが信頼できないゆえに、この時間においてデータ送信を試みることは望ましくない。

障害発生前の最初の時間間隔２０４に受信したデータＤ１は、送信時点１〜３の間において送信されてもよい。さらに、障害発生中である２番目の時間間隔２０６に受信したデータＤ２は、バッファに保存されてもよいし、時刻ｔ_２からｔ_３までの時間間隔である３番目の時間間隔２０８、即ち送信機会１４〜２０において、３番目の時間間隔２０８において受信した新しいいかなるデータＤ３とともに送信されてもよい。加えて、障害発生時刻ｔ１の直前、例えば送信機会３の後、に受信したデータＤ１の一部は、さらにバッファされ、かつ時刻ｔ２の後、即ちネットワークサービス復旧後である３番目の時間間隔２０８、において送信されてもよい。

図４は、本実施例における送信ルールの決定及び送信ルールの適用の例４００を示す。図４は、本実施例におけるデータ送信例を示し、障害発生前に行われるルール決定フェーズ４０２と、障害発生中及び／又は終了後に行われる適用フェーズ４０４と、を含む。ルール決定フェーズ４０２は、リソース割り当ての１以上のルールの導出を含んでもよい。例えば、ルール決定フェーズ４０２において、計算機１０２は、どのデータサンプル又は他のデータ片を、例えば次回の時間間隔の送信機会において送信されるかを決定してもよい。従って、ルール決定フェーズ４０２は、決定されたルールに基づいて送信される予定のデータ１０８の一部又は全部を受信する前に実行されてもよい。

本例では、データプロファイルモジュール４０６は、対応するデータ生成器から受信した選択されたデータ種別についてのデータプロファイル４０８を、ルール決定モジュール４１０に入力する。例えば、各Ｉｏｔアプリケーション、各ＩｏＴデバイス、又は他の各データ生成器１１０は、データプロファイルデータ構造体４１２に格納される、対応するデータプロファイル４０８を有してもよい。いくつかの例において、データプロファイルモジュール４０６は、各データ生成器１１０についてのデータプロファイル４０８の少なくとも一部を、経時的に受信したデータ１０８の観察結果に基づいて、決定してもよい。これに加え又は代えて、各データ種別、例えば各データ生成器のためのデータプロファイル４０８は、管理者等によって、少なくとも一部が予め設定されていてもよい。データプロファイルデータ構造体４１２の一例は、図５を用いて以下で説明される。

また、ネットワーク状態予測モジュール４１４は、ネットワーク品質が低いと予測された時間間隔に少なくとも部分的には基づいて、送信機会を予測してもよい。一例として、ネットワーク状態予測モジュール４１４は、時刻や計算機の地理的位置によってネットワーク状態がどのように異なるかを示すネットワーク状態履歴情報４１６、を考慮してもよい。例えば、ネットワーク状態予測モジュール４１４は、計算機１０２が経時的に経験したネットワーク障害についての情報であるネットワーク情報を収集してもよいし、さらにネットワーク情報をネットワーク状態履歴情報４１６として、データベース等に格納してもよい。例えば、ネットワーク状態履歴情報４１６は、障害が最初に発生した地理的位置、障害発生時間の長さ、サービスが復旧した地理的位置、障害発生前、障害発生中、及び障害終了後の計算機の移動経路等を含んでもよい。これに加えて又は代えて、ネットワーク状態履歴情報４１６は、サービスプロバイダ、又は、例えば、信号品質が悪かったり他のネットワーク障害が発生したりする地理的位置、ネットワークがひどく混雑したり利用不可能である時刻等を示す他の情報源、から受信した情報を含んでもよい。

また、ネットワーク状態予測モジュール４１４は、時刻や曜日等を示す現在時刻４１８、混雑レベル及び予測混雑レベル等を示す現在ネットワーク状態４２０、並びに計算機の移動速度及び計算機の移動経路等を示す、現在及び最近の地理的位置等の地理的位置情報４２２、等の追加情報を受信してもよい。ネットワーク状態予測モジュール４１４は、これらの情報の一部又は全部及び／又は他の情報を、ルール決定モジュール４１０に提供するネットワーク状態予測情報４２４を決定するために用いてもよい。ルール決定モジュール４１０は、ネットワーク状態予測情報４２４及びデータプロファイル４０８を入力として受信してもよく、さらに、図６及び図１０を用いて後述するが、どのデータ片をどの送信機会において送信するかを決定してもよい。従って、ルール決定モジュール４１０は、送信ルール適用モジュール４２８に提供される１以上のデータ送信ルール４２６を決定してもよい。

適用フェーズ４０４は、データ生成器１１０からのＩｏＴデータ１０８の受信中及び／又は受信後において実行される、ネットワーク１０６への送信処理のための、動作を含む。特に、データ１０８はデータ生成器１１０から受信すると、ルール決定フェーズ４０２において定められた１以上のデータ送信ルールは、受信したデータ１０８に対して送信ルール適用モジュール４２８によって適用される。

適用フェーズ４０４において、データ採集モジュール４３０は、データ生成器１１０からデータ１０８を受信する。例えば、データ採集モジュール４３０は、センサ及び／又は多くの異種のデータ生成器１１０、並びにＷｉ−Ｆｉ、ＢｌｕｅＴｏｏｔｈ、及びＺｉｇＢｅｅ等だけでなくイーサネット、光ファイバ、若しくは他の直接有線接続のような送信技術、とインタフェースで接続可能であってもよい。データ採集モジュール４３０はデータ１０８を受信し、データ１０８を１以上のデータバッファ４３２に格納してもよい。例えば、データ種別ごと、ＩｏＴデバイスごと、又はデータ生成器１１０ごと等の、計算機１０２から受信したデータ種別に依存する単位ごとに、１つずつバッファが存在してもよい。例えば、計算機１０２が輸送機器に埋め込まれたシステムであり、データ生成器１１０がＧＰＳデータを提供するＧＰＳデバイス、現在の移動速度を提供するスピードメータ、輸送機器の現在の向きを提供するコンパス、及び現在の燃料残量を示す燃料測定機器等を含むと仮定する。これらの異なる各種別のデータは、定期的に受信され、別箇のデータバッファ４３２に保管されてもよい。

送信ルール適用モジュール４２８は、１以上のデータサンプル又は他のデータ片を１以上のデータバッファ４３２から選択するために、データ送信ルール４２６を用いてもよい。当該データバッファ４３２は、当該選択されたデータを利用可能な送信機会中に送信するためのバッファである。例えば、送信ルール適用モジュール４２８は、１以上のデータ送信ルール４２６をルール決定モジュール４１０から受信し、当該１以上のデータ送信ルール４２６を適用する。例えば、送信ルール適用モジュール４２８は、１以上のデータ送信ルール４２６に基づいて、データ送信１１２としてネットワーク１０６に送信するために、データバッファ４３２から１以上のデータ片を選択してもよい。

送信ルール適用モジュール４２８は、１以上の送信技術を用いてデータ送信１１２として選択されたデータをネットワーク１０６に送信する送信モジュール４３４に、選択されたデータを提供してもよい。例えば、送信モジュール４３４は、セルラーＬＴＥの場合におけるＬＴＥトランシーバ、又はネットワーク１０６への送信が可能ないかなる他種若しくは他の通信インタフェース等のような他の通信ハードウェアトランシーバを操作する送信ソフトウェアを含んでもよい。送信モジュール４３４は、１以上のデータバッファ４３２から選択されたデータを取得してもよいし、パケット化してもよいし、通信インタフェースに当該データパケットを送信させてもよい。従って、送信ルール適用モジュール４２８は、ネットワーク１０６に送信するために、データ送信ルール４２６、並びにネットワーク及び／又は計算機１０２の状態に基づいてデータを選択してもよい。また、送信ルール適用モジュール４２８は、送信モジュール４３４に、選択したデータをデータ送信１１２として、ネットワーク１０６に送信させてもよい。

いくつかの例において、点線で示されているように、モジュール４０６、４１０、４１４，４２８、４３０、及び４３４の一部又は全部は、図１を用いて上述したデータ管理アプリケーション１２２に含まれていてもよい。例えば、モジュール４０６、４１０、４１４，４２８、４３０、及び４３４のそれぞれは、上述したステップ及びアルゴリズムをプロセッサに実行させるための実行可能なコードの一部であってもよい。他の例において、モジュール４０６、４１０、４１４，４２８、４３０、及び４３４の一部は、データ管理アプリケーション１２２と独立して実行可能であってもよい。加えて、いくつかの例において、より多くの若しくはより少ないモジュールが存在する、及び／又はいくつかのモジュールが結合されていてもよい。多くの他のバリエーションは、本開示の受益者である当業者にとって明らかになるであろう。

図５は、本実施例における、データプロファイルデータ構造体４１２の一例を示す。データプロファイルデータ構造体４１２は、図１を用いて上述したデータ生成器１１０によって生成されたデータについての情報を含んでもよい。従って、データプロファイルデータ構造体４１２は、対応するデータ生成器の識別子を示すデータ生成器ＩＤ５０２（即ち、アプリケーション及び／又はデバイスのＩＤ）と、データ生成器によって生成されたデータの種別を示すデータ種別５０４と、データが生成される頻度を示すデータ生成周期５０６と、データ生成周期５０６によって示される各周期中において生成されるデータのサイズを示すデータサイズ５０８と、他のデータ生成器によって生成された他のデータとの相対的な優先度を示すデータ優先度５１０と、計算機１０２が受信時間閾値内にデータを送信することの重要性を示す遅延カテゴリ５１２と、を含む。例えば、いくつかのデータ種別については、各データサンプルを送信する必要はない可能性がある。従って、いくつかの例において、受信時間閾値内にデータが送信されるべき「ＣＲＩＴＩＣＡＬ」と、当該データが後になって送信されてもよい「ＮＯＴ ＣＲＩＴＩＣＡＬ」と、の２つの遅延カテゴリが存在してもよい。データプロファイルデータ構造体４１２の各行は、別箇のアプリケーション及びセンサ機器のような別箇のデータ生成機又はデータ種別のための別箇のデータプロファイル４０８を示してもよい。いくつかの例において、管理者又は他のユーザが、データ優先度５１０及び遅延カテゴリ５１２のような情報の一部又は全部を、システムの初期セットアップ時に提供してもよい。

図６は、本実施例における、ルール決定及び適用のタイミング６００の一例を示す。本例において、ネットワーク状態予測モジュール４１４は、ネットワークの状態を予測してもよい。例えば、「ネットワーク利用可能」は、データが送信可能であることを示す。一例として、送信可能なデータのサイズが、大、中、小からなる３つのカテゴリのうちの１つに決定可能であるとしてもよい。但し、「ゼロ」はネットワーク障害が起きていることを示すため、当該送信データ可能なサイズに含まれない。従って、ネットワークが利用可能という示唆は、必ずしもネットワーク状態が良いことを示していないが、少なくともデータ送信可能であることを示している。

一方、「障害」は、送信可能データ量が閾値を下回っていることを意味してもよいし、いくつかの場合において送信可能データ量がゼロであることを意味してもよい。例えば、障害状態は、ネットワーク利用不可能性（例えば、セルラー方式のカバレッジがない等）、又はデータ送信ができない可能性があるほどのネットワークの激しい混雑、によって引き起こされる。

ネットワーク状態予測モジュール４１４が、まもなく障害が発生すると判定した場合、ネットワークがまだ利用可能な状態のうちに、図４を用いて上述したルール決定フェーズ４０２が開始されてもよい。ルール決定フェーズが開始する時刻は、ルール決定フェーズ４０２の全てのアルゴリズム及び機能を実行するために必要な通常の時間に、少なくとも部分的に依存する。一例として、ルール決定フェーズ４０２は、障害発生予測を開始する少なくとも３〜５ｍｓｅｃ前に開始されていてもよい。ルール決定フェーズ４０２が完了すると、図４の適用フェーズ４０４が開始し、これはΔＴ_ｐｒｅ＋ΔＴ_ｐｏｓｔに対応する可能性がある。適用フェーズ４０４の期間は、データＤ２（ネットワーク障害時に生成されたデータ、図３を参照）の全体を送信するために必要とされる時間量として選択される可能性があるΔＴ_ｐｏｓｔの期間に、少なくとも部分的には依存する。

図示された例において、期間６０２は、ネットワークが利用可能であるが、障害が発生すると予測済みである期間を示す。期間６０４は、当該障害が発生している期間を、期間６０６は、再度ネットワークが利用可能である期間を示す。ネットワーク状態予測モジュール４１４が、期間６０４における障害がまもなく、例えばおよそ数ｓｅｃ又は数ｍｓｅｃ等の間に、発生すると判定した、と仮定する。図４を用いて上述したように、ネットワーク状態予測モジュール４１４は、当該障害が発生する前に、ネットワーク予測状態を示す情報をルール決定モジュール４１０に提供してもよい。ルール決定モジュール４１０は、予測された障害発生時より前に、ルール決定フェーズ４０２を開始してもよい。期間６０８が示すように、ルール決定フェーズ４０２は３〜５ｍｓｅｃを要してもよく、その後、期間６１０、６１２が示すように、適用フェーズ４０４が行われる。従って、ルール決定モジュール４１０が決定したデータ送信ルール４２６が、時間間隔２０４、２０６、２０８の間において、図４の送信ルール適用モジュール４２８によって適用される。例えば、適用フェーズ４０４は、時刻ｔ_０から時刻ｔ_３まで、即ち、障害中に受信したデータでありデータ送信ルールに基づいて送信対象に選択されたデータであるデータＤ２、の送信が完了するまで継続してもよい。

図７は、本実施例における相対的チャネル容量７００の一例を示す。図６の例において、ネットワークが「利用可能」に分類されている場合、データを送信するためのチャネル容量がある。「利用可能」という分類は、ネットワーク状態が、チャネル容量大７０２、チャネル容量中７０４、又はチャネル容量小７０６のいずれかであることを示してもよい。これは必ずしも、ネットワーク状態又はチャネル状態が良いことを示す必要はないが、その代わりに確実に送信可能なデータ量が、大、中、又は小であるかを示す必要がある（但し、ゼロを用いて示すことはない）。一方、ネットワークが「障害」に分類されている場合、送信されるデータ量はゼロ、そうでなければ、データを確実には送信できない場合のように、閾値７０８が示す閾値容量を下回っている。セルラー方式のサービスが提供されていない等のネットワーク利用不可能性、又は確実なデータ送信が不可能である等のネットワークの高混雑に起因して、障害が発生している可能性がある。

図８は、本実施例における圧縮を含むルール決定の例８００を示す。本例では、ルール決定モジュール４１０は、図４を用いて上述したように、１以上のデータプロファイル４０８をデータプロファイルモジュール４０６から受信してもよい。例えば、Ｌ個のデータ生成器によって生成されたＬ種類のデータ種別があり、Ｓ_１〜Ｓ_Ｌは、それぞれデータプロファイル４０８−１〜４０８−Ｌを意味するものと仮定する。

いくつかの例において、ルール決定モジュール４１０は、例えば各データ種別について階層データ圧縮が推奨されるか否かを決定するために、各データについてデータ圧縮階層情報８０２−１〜８０２−Ｌを決定してもよい。さらにルール決定モジュール４１０は、選択されたデータ種別に対して実行される可能性がある圧縮についての異なる複数の起こり得るレベルを、データ圧縮階層情報８０２の一部として、リストアップしてもよい。一例として、データ種別が、カメラ（例えばＩｏＴセンサが、ビデオ監視フィードを収集するため等のビデオカメラであってもよい。）であるデータ生成器から受信したビデオコンテンツデータであると仮定する。ビデオコンテンツデータは、様々な異なる圧縮レベル（例えば、低精細度、標準精細度、又は高精細度のビデオフォーマット）に対応して、異なる解像度で符号化されてもよい。各々の場合において圧縮レベルが異なり、これによりネットワークを介して送信されるデータサイズの違いが発生する可能性がある。

データ圧縮階層情報８０２は、所与のデータ種別についての各圧縮可能レベルの圧縮詳細のリストを含んでもよい。例えば、圧縮詳細は、圧縮レベル、圧縮の結果生じるペイロード、圧縮が可逆であるか非可逆であるか、及び非可逆圧縮の場合に失われるデータの範囲等を含んでもよい。本実施形態では、データ８０４が示すように、所与のデータ種別「ｋ」はデータＳ_ｋに関連付けられており、ベクトルとしてのＳ_ｋは、圧縮レベルの値であるｎｋを用いて、取り得る全ての圧縮レベルを示す。例えば、ｎｋ＝３の場合、圧縮レベルは、低精細度、標準精細度、及び高精細度のビデオ解像度からなり、さらにビデオのローデータ即ち圧縮が行われていないことを示す圧縮レベル０がある。

データプロファイル４０８についてのデータ圧縮階層情報の詳細は、ルール決定モジュール４１０によって、データ送信ルール４２６が決定されるときに適用されてもよい。例えば、ルール決定モジュール４１０は、図５を用いて上述したデータ優先度及び遅延カテゴリ等のデータプロファイル４０８からの追加データプロファイル情報８０６だけでなく、データ圧縮階層情報８０２−１〜８０２−Ｌ、及びネットワーク状態予測モジュール４１４からのネットワーク状態予測情報４２４を、入力として受信する。ルール決定モジュール４１０は、送信予定の全てのＩｏＴデータを、次の送信期間においてネットワークを介した信頼可能な送信が行われる１以上の送信パケットに収めること、を含むリソース割り当てを実行してもよい。ネットワーク状態が異なる可能性があるため、また信頼可能な送信が可能なＩｏＴデータのサイズ及びデータ量のような、結果として得られるネットワーク容量（例えばチャネル容量）、が大きかったり（大容量）小さかったり（低容量）する可能性があるため、例えば、リソース割り当てが利用されてもよい。従って、ルール決定モジュール４１０のリソース割り当て機能は、受信したデータのどの程度の量を（さらに、どの圧縮レベルで）、割り当てられた送信機会においてチャネルを介して信頼可能な送信が可能なチャネル送信パケットに収めることができるかを決定する。

図９は、本実施例におけるデータ圧縮階層の例９００を示す。上述したように、アプリケーションデータに対して実行される異なるレベルの圧縮を可能にする圧縮階層、を含む実装がある。例えば、圧縮モジュールは所与のデータに対して実行可能な各圧縮レベルの詳細をリストアップしてもよいし、圧縮レベル、圧縮の結果生じるペイロード、圧縮が可逆であるか非可逆であるか、及び非可逆圧縮の場合に失われるデータの範囲等のような圧縮詳細を含んでもよい。図９は、例えば無圧縮９０２、最小限圧縮９０４、中程度圧縮９０６、及び最大限圧縮９０８等を含む、異なる圧縮レベルを例示する。上述したように、所与のデータ種別「ｋ」はデータＳ_ｋに関連付けられており、ベクトルとしてのＳ_ｋは、圧縮レベルの値であるｎｋを用いて、取り得る全ての圧縮レベルを示す。例えば、ｎｋ＝３の場合、圧縮レベルは、低精細度、標準精細度、及び高精細度のビデオ解像度からなり、さらにビデオのローデータ即ち圧縮が行われていないことを示す圧縮レベル０がある。

図１０及び図１６は、本実施例における処理の例を示すフローチャートである。一部又は全部がハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせにおいて実行される一連の動作、を代表する論理フローチャートにおいて、処理はステップの集合として記載されている。ソフトウェアのコンテキストにおいて、ステップは、１以上のコンピュータ読み取り可能媒体に格納されたコンピュータが実行可能な指示を代表してもよく、当該指示は、１以上のプロセッサによって実行された場合、列挙された処理を当該プロセッサに実行させるようプログラムする。通常は、コンピュータが実行可能な指示は、特定の機能を実行したり特定のデータ種別を実装したりする、ルーチン、プログラム、オブジェクト、コンポーネント、及びデータ構造体等を含む。ステップの記載順序は、限定的に解釈されるべきではない。なお、記載されたいかなるステップが結合されてもよいし、各ステップの実行順序が変更されてもよいし、各ステップが並行して実行されてもよいし、必ずしも全てのステップが実行されなくてもよい。本議論の目的のために、本実施形態の環境、フレームワーク、及びシステムに関連する処理が記載されているが、他の多様な環境、フレームワーク、及びシステムにおいて、本実施形態の処理が実行されてもよい。

図１０は、本実施例におけるルール決定のための処理１０００の一例を示す。処理１０００は、計算機１０２に実行されてもよいし、他の適切な計算機によって実行されてもよい。上述したように、データ管理アプリケーション１２２は、選択したデータを、ネットワークを介してネットワーク計算機に送信するための、エッジコンピューティング及び受信したデータについての他の処理を実行してもよい。データ管理アプリケーション１２２は、所与の送信時点においてデータを最適化する従来のオプティマイザとは異なり、複数の送信時点に跨ったリソース割り当てを実行してもよい。従って、データ管理アプリケーション１２２は、未来のデータパターン及び未来の送信機会を考察してもよく、データトラフィックが軽い見通しであると判定した場合、データ管理アプリケーション１２２は、いくつかのデータサンプルの送信を、未来の送信機会へと延期してもよい。例えば、データトラフィックパターンが少なくとも部分的には決定論的であってもよく、従って、どのデータがどの時点で送信されるかを決定するためにルールが適用されてもよい。図１０は、データ管理アプリケーション１２２のルール決定モジュール４１０の処理の一例を提供する。いくつかの動作が省略されたり、動作順序が変更されたり、他の処理が含まれたりする、他の例があってもよい。

ステップ１００２において、計算機は、ネットワーク障害予測の兆候を受信してもよい。例えば、図４及び図６を用いて上述したように、ネットワーク状態予測モジュールが、まもなく障害が発生するかもしれないことを示す予測ネットワーク状態を、ルール決定モジュール４１０に送信することに基づいて、ルール決定フェーズが開始されてもよい。

ステップ１００４において、計算機は、優先度をｐ＝１（最高優先度）に設定してもよい。例えば、計算機は、まず最高優先度のデータを、ネットワークに送信するデータに選択するか否かを決定するために、精査する。当該データをネットワークに送信するためのデータに選択するか否かを決定するためである。本例においては、データ優先度は、最高優先度である１から、数字が大きくなるほど連続的に優先度が下がるものとする。他の例において、他の相対的な値が、データ優先度に用いられてもよいことは言うまでもない。

ステップ１００６において、計算機は、障害中に、優先度がｐであるデータをバッファが受信すると予期されるかどうかを判定してもよい。例えば、計算機は、最初に、障害中にデータ生成器１１０からデータを受信済み又は受信予定のあらゆるバッファ内の、最高優先度のデータについて検討する。

ステップ１００８において、計算機は、次の送信機会に送信される場合には超過するであろう遅延カテゴリ時間閾値を有するデータサンプル又は他のデータ片が存在するかどうかを判定してもよい。例えば、計算機は、各バッファに格納されたデータのパターンを決定してもよいし、当該データの遅延カテゴリを決定してもよい。遅延カテゴリは、ネットワークへ送信予定のデータのための、計算機による受信後の制限時間閾値を含んでもよい。従って、遅延カテゴリに基づいて、計算機は、送信するには遅すぎることになるデータサンプル又はデータ片を識別することができる。例えば、仮にこれらのデータサンプルが次回の送信機会中に送信されるとすると、これらのデータサンプルの遅延カテゴリ時間閾値（例えば、送信のための時間閾値）が満たされない。従って、これらのデータサンプルが存在する場合、計算機は、これらのデータサンプルを送信することなく、バッファから破棄、上書き、又は削除してもよい。遅延カテゴリ時間閾値を既に逸しているため、これらのデータサンプルを送信することは無意味だからである。

次回の送信機会において送信された場合に遅延カテゴリが満たされないデータサンプルが存在する場合、ステップ１０１０において、計算機は、これらのデータサンプルをバッファから破棄してもよい。例えば、上述したように、たとえこれらのデータサンプルが次の送信機会に送信されるとしても、これらのデータサンプルの遅延カテゴリは満たされない。従って、これらのデータサンプルは、各バッファから取り出されて破棄されてもよい。

ステップ１０１２において、ステップ１００８及びステップ１０１０において破棄されなかったデータサンプルの中から、計算機は、遅延カテゴリが最高（例えば「ＣＲＩＴＩＣＡＬ」かつクリティカル時間閾値以内にいまだ送信可能である）の１以上のデータサンプルを選択してもよい。従って、１以上のバッファに残っているデータサンプルから、計算機は最高の遅延カテゴリ（例えば、送信のための残り時間が最も短い）を有するデータサンプルを選択してもよい。例えば、同一のセンサ又は他の同一のデータ生成器から受信した複数のデータサンプルが存在する場合、最も早く受信したデータサンプルは、当該センサ又は当該データ生成器から当該データサンプルよりも遅く受信したデータサンプルよりも、よりクリティカルな遅延カテゴリを有してもよい。

ステップ１０１４において計算機は、１以上の選択されたデータサンプルのデータ種別に要求されるデータ圧縮レベルを選択してもよい。例えば、計算機は、選択されたデータサンプルに対して取り得る圧縮レベルを、データ優先度情報に基づいて決定してもよい。一例として、優先度がより高いデータは圧縮されなくてもよく、相対的により重要でなく、優先度が低い種別のデータは圧縮されてもよい。

ステップ１０１６において、予測されたネットワーク状態に基づいて、計算機は、現在の選択されたデータ及び既に選択された可能性がある全てのデータが送信可能かどうかを判定してもよい。例えば、圧縮が許可される場合、計算機は、データを圧縮した場合に、ネットワークが、選択済みの他のいかなる高優先度のデータとともに当該データを信頼可能に送信できるかどうかを判定してもよい。一例として、計算機は、図４を用いて上述したネットワーク状態予測情報４２４から得られるネットワーク容量（例えばｂｐｓを単位として）の推定、に基づいて当該判定を行ってもよい。例えば、ネットワーク容量が、次回の送信機会において信頼可能な送信のためのデータを送るために必要な１ＭＢであると仮定する。これに基づいて、送信対象として選択された全てのデータの合計容量が１ＭＢ未満であるとよい。ネットワーク容量についての記載は図７に記載されている。

ステップ１０１８において、計算機は決定した情報をルール、例えば｛データ優先度、遅延カテゴリ、圧縮レベル｝として、保存してもよい。例えば、ネットワーク容量が十分にある場合、現在の対象としている送信可能なデータサンプル及び当該データサンプルの圧縮レベルが、ルールとしてルールデータ構造体に書き込まれてもよい。ルールを保持するルールデータ構造体の一例が図１１に示されている。

ステップ１０２０において、計算機は、次に高い優先度を有するデータ種別へと移行するために優先度ｐを例えばｐ＝ｐ＋１へとインクリメントする。ステップ１０１６における結果が「ＮＯ」となると図１０の処理が終了する。

ステップ１０２２において、計算機は、データ送信ルールに従うデータ送信のために、データ送信ルールを送信ルール適用モジュールに提供してもよい。図１２を用いて一例を後述する。

図１１は、本実施例におけるルールデータ構造体１１００の一例を示す。ルールデータ構造体１１００は、図４及び図１０を用いて上述したルール決定モジュール４１０によって生成された１以上のデータ送信ルールを含んでもよい。本例では、ルールデータ構造体１１００は、ルールＩＤ（識別子）１１０２、ルール適用状況１１０４、ルール適用送信時点１１０６、送信予定データ生成器ＩＤ１１０８、データサンプル送信数１１１０、及びデータサンプル向け圧縮レベル１１０２を含む。

例えば、ルールＩＤ１１０２は、各ルールを他のルールと識別可能なように割り当てられていてもよい。さらに、ルール適用状況は、ネットワーク障害中又は通常のネットワーク状態においてルールが適用されるべきか否かを示してもよい。ルール適用送信時点１１０６は、当該ルールに従ってどの送信時点の間にデータが送信される可能性があるかを示してもよい。送信予定データ生成器ＩＤ１１０８は、データ送信を受信するネットワーク計算機への送信データのデータ種別を識別する生成済みデータの識別子を示してもよい。データサンプル送信数１１１０は、特定のバッファから送信予定のサンプル数を示してもよい。さらに、データサンプル向け圧縮レベル１１１２は、送信される予定のデータの圧縮レベルを示してもよい。

図１２は、本実施例における、送信ルール適用モジュール４２８の動作の例１２００を示す。本例では、データ生成器１１０はデータ１０８をデータバッファ４３２それぞれに提供してもよい。例えば、データ種別それぞれに対してデータバッファが存在してもよい、つまりデータ種別それぞれは異なるデータ生成器からのデータに対応する。従って第１データ生成器１１０−１は、第１データバッファ４３２−１に第１種データ１０８−１を提供してもよく、同様に第Ｌデータ生成器１１０−Ｌは、第Ｌデータバッファ４３２−Ｌに第Ｌ種データ１０８−Ｌを提供してもよい。データバッファ４３２にデータが取り込まれ格納されると、送信ルール適用モジュール４２８は、ネットワーク１０６に送信するために選択するデータをデータバッファ４３２から決定するために、データ送信ルール４２６を参照してもよい。

本例では、ステップ１２０２において、データ送信ルール４２６に基づいて、送信ルール適用モジュール４２８は、１以上の選択されたデータサンプルＳ１〜ＳＬを、所与の送信時点における送信のために圧縮してもよい。上述したように、優先度がより高いデータの場合のように、当該１以上のデータサンプルＳ_１〜Ｓ_Ｌが、圧縮されない可能性がある場合もある。

送信ルール適用モジュール４２８は、選択したデータサンプルＳ_１〜Ｓ_Ｌと、これらに対応するメタデータ１２０４と、を１以上のデータ送信パケットを生成可能な送信モジュール４３４に提供してもよい。例えば、データパケット１２０６は、圧縮データサンプル（圧縮されていない例もある）を含んでもよい。さらに、データパケット１２０６は、どのデータがどのデータ生成器から送信されたかについての情報、データパケット１２０６内のデータの圧縮レベルについての情報等を含む、メタデータ１２０４を含んでもよく、メタデータ１２０４は、ネットワーク計算機１０４によってデータパケットが受信されたときに復号化するための制御情報として利用されてもよい。従って、１以上のデータパケットが生成された後、送信モジュールは、図１を用いて上述したネットワーク計算機１０４が受信するデータ送信として、ネットワークを介したこれらのデータパケット１２０６の送信をもたらす。

図１３は、本実施例における、データ送信のためのデータ選択及び生成の例１３００を示す。図示された例において、データ生成器は、第一センサＧ及び第二センサＥからなる２つのセンサを含むと仮定する。また、本例において、データバッファ４３２−１及びデータバッファ４３２−２それぞれの、各センサに対して２つのデータサンプルが存在すると仮定する。仮定１３０２に示すように、当該データサンプルの遅延カテゴリはともに「ＣＲＩＴＩＣＡＬ」であり、かつ当該データサンプルは次回の送信機会において送信可能であると仮定する。さらに、仮定１３０４に示すように、センサＧからのデータの優先度はセンサＥからのデータの優先度より高いと仮定する。さらに、仮定１３０６が示すように、ネットワーク状態が良好であり、それゆえネットワーク容量が大きいものの、４つのデータサンプルの１つも圧縮することなく当該４つのデータサンプルを送信できるほどネットワーク容量が高くはない可能性がある、と仮定する。従って、データ送信ルールはセンサＥからのデータを圧縮することを推奨してもよい。

データバッファ４３２−１は、センサＧからのデータであるセンサＧデータ１３０８を保持する。センサＧデータ１３０８のうち、最新のデータサンプルが最新データサンプルＧ_ｔ１３１０であり、古いデータサンプルが前データサンプルＧ_ｔ−１１３１２である。なお、前データサンプルＧ_ｔ−１１３１２は、最新データサンプルＧ_ｔ１３１０の１つ前に受信したデータサンプルであってもよい。さらに、データバッファ４３２−２は、センサＥからのデータであるセンサＥデータ１３１４を保持する。センサＥデータ１３１４のうち、最新のデータサンプルが最新データサンプルＥ_ｔ１３１６であり、古いデータサンプルが前データサンプルＥ_ｔ−１１３１８である。ステップ１３２０に示すように、データ量、ネットワーク状態についての仮定１３０６、及びデータ送信ルールに基づいて、センサＥデータ１３１４を圧縮することにより、圧縮センサＥデータＥ_ｔ１３２６及び圧縮センサＥデータＥ_ｔ−１１３２８が得られる。さらに、パケット１３４０が示すように、センサＧデータ及び圧縮センサＥデータは、パケット化されてもよい。

図１４は、本実施例における、データ送信のためのデータ選択及び生成の例１４００を示す。本例において、データバッファ４３２−１及びデータバッファ４３２−２それぞれの各センサに対して、２つのデータサンプルが存在すると仮定する。仮定１４０２に示すように、当該データサンプルの遅延カテゴリはともに「ＣＲＩＴＩＣＡＬ」であり、かつ当該データサンプルは次回の送信機会において送信可能であると仮定する。さらに、仮定１４０４に示すようにセンサＧからのデータの優先度はセンサＥからのデータの優先度より高いと仮定する。さらに、仮定１４０６が示すように、ネットワーク状態が不良であり、それゆえネットワーク容量が小さいと仮定する。従って、この場合、データ送信ルールは、センサＧからのデータの優先度がセンサＥからのデータの優先度より高いものの、センサＧ及びセンサＥの双方からのデータをからのデータを圧縮することを推奨してもよい。

データバッファ４３２−１は、センサＧからのデータであるセンサＧデータ１４０８を保持する。センサＧデータ１４０８のうち、最新のデータサンプルが最新データサンプルＧ_ｔ１４１０であり、古いデータサンプルが前データサンプルＧ_ｔ−１１４１２である。なお、前データサンプルＧ_ｔ−１１４１２は、最新データサンプルＧ_ｔ１４１０の１つ前に受信したデータサンプルであってもよい。さらに、データバッファ４３２−２は、センサＥからのデータであるセンサＥデータ１３１４を保持する。センサＥデータ１４１４のうち、最新のデータサンプルが最新データサンプルＥ_ｔ１４１６であり、古いデータサンプルが前データサンプルＥ_ｔ−１１４１８である。ステップ１４２０に示すように、データ量、ネットワーク状態についての仮定１４０６、及びデータ送信ルールに基づいて、センサＧデータ１４０８及びセンサＥデータ１４１４を圧縮することにより、圧縮センサＧデータ１４３０Ｇ_ｔ、圧縮センサＧデータＧ_ｔ−１１４３２、圧縮センサＥデータＥ_ｔ１４３６、及び圧縮センサＥデータＥ_ｔ−１１４３８が得られる。さらに、パケット１４４２が示すように、圧縮センサＧデータ及び圧縮センサＥデータは、パケット化されてもよい。

図１５は、本実施例における、データ送信のためのデータ選択及び生成の例１５００を示す。本例において、データバッファ４３２−１及びデータバッファ４３２−２それぞれの、各センサに対して２つのデータサンプルが存在すると仮定する。仮定１５０２に示すように、センサＥからのデータサンプルの遅延カテゴリは「ＣＲＩＴＩＣＡＬ」であり、センサＧからのデータサンプルの遅延カテゴリは「ＮＯＴ ＣＲＩＴＩＣＡＬ」であると仮定する。さらに、仮定１５０４に示すように、センサＧからのデータサンプルの遅延カテゴリが「ＮＯＴ ＣＲＩＴＩＣＡＬ」であるため、センサＧからの最新データは次回の送信機会中に送信される必要がない。例えば、より早く受信したデータサンプルが、遅延カテゴリの要求を満たすために、送信されてもよい。さらに、仮定１５０６に示すように、ネットワーク状態が不良であり、それゆえネットワーク容量が小さいと仮定する。さらに、センサＧデータ１５０８の優先度は、センサＥデータ１５１４の優先度より高くてもよい。

データバッファ４３２−１は、センサＧからのデータであるセンサＧデータ１５０８を保持する。センサＧデータ１５０８のうち、最新のデータサンプルが最新データサンプルＧ_ｔ１５１０であり、古いデータサンプルが前データサンプルＧ_ｔ−１１５１２である。なお、前データサンプルＧ_ｔ−１１５１２は、最新データサンプルＧ_ｔ１５１０の１つ前に受信したデータサンプルであってもよい。さらに、データバッファ４３２−２は、センサＥからのデータであるセンサＥデータ１５１４を保持する。センサＥデータ１５１４のうち、最新のデータサンプルが最新データサンプルＥ_ｔ１５１６であり、古いデータサンプルが前データサンプルＥ_ｔ−１１５１８である。しかし、当該遅延カテゴリは最新データサンプルＧ_ｔ１５１０の送信を要求していないため、データ送信ルールは圧縮をしないこと又は最小限の圧縮をすることを推奨してもよく、さらにセンサＧからの１つのデータサンプル（例えば、前データサンプルＧ_ｔ−１１５１２等）及びセンサＥからの双方のデータサンプルの送信を推奨してもよい。ステップ１５２０に示すように、データ量、ネットワーク状態についての仮定１５０６、及びデータ送信ルールに基づいて、前データサンプルＧ_ｔ−１１５１２、最新データサンプルＥ_ｔ１５１６、及び前データサンプルＥ_ｔ−１１５１８が、圧縮されることなく又は最小限の圧縮を経て、パケット化される。

図１６は、本実施例におけるデータ受信及び送信のための処理例１６００を示すフローチャートである。本例において、処理例１６００は、計算機１０２に実行されてもよいし、他の適切な計算機によって実行されてもよい。

ステップ１６０２において、計算機は、現在の地理的位置、現在のネットワーク状態、ネットワーク状態履歴情報、サービスプロバイダからの情報、及び／又は現在時刻に基づいて、ネットワーク障害の発生が予測されるかを判断してもよい。例えば、図４を用いて上述したように、ネットワーク状態予測モジュールは、ネットワーク予測状態を決定するために種々の情報を考慮してもよい。

ステップ１６０４において、計算機は、障害発生前及び発生中に受信が予想されるデータ種別の、データ優先度及び遅延カテゴリの少なくとも一方を決定してもよい。例えば、計算機は、どの種別のデータを障害発生中に受信するかを認識していてもよく、かつ対応するデータプロファイルから得られるデータ優先度、遅延カテゴリ、及び圧縮情報等を決定してもよい。

ステップ１６０６において、計算機は、受信が予想されるデータ種別のデータ優先度及び遅延カテゴリの少なくとも一方に基づいて、データを送信するための１以上のデータ送信ルールを、障害終了後に決定してもよい。データ送信ルールを決定する例は図４及び図１０を用いて上述されており、データ送信ルールは、予想データ、遅延カテゴリ、データ優先度、及び圧縮情報に基づいて決定される。

ステップ１６０８において、計算機は、障害発生前及び障害発生中の少なくとも一方において、第一データ種別の第一データを第一センサから受信してもよいし、第二データ種別の第二データを第二センサから受信してもよい。例えば、データ種別ごとに、異なるデータバッファに格納されてもよく、データ種別ごとに別箇のデータプロファイルに関連付けられていてもよく、データプロファイルは、データ生成周期、データサイズ、当該データの優先度、及び／又は当該データの遅延カテゴリを示す。

ステップ１６１０において、障害終了の後、計算機は、例えば少なくとも１つのデータ送信ルールに規定されているように、第一データに関連付けられた第一優先度及び第一遅延カテゴリの少なくとも一方に基づいて、第一データの少なくとも第一データ片を送信してもよく、さらに第二データに関連付けられた第二優先度及び第二遅延カテゴリの少なくとも一方に基づいて、第二データの少なくとも第一データ片を送信してもよい。さらに、計算機が、第一データに関連付けられた第一遅延カテゴリに基づいて、次回の送信機会に送信が行われた場合に第一データの第二データ片の第一遅延カテゴリに対応する時間閾値を超過すると判定する例があってもよい。これに基づいて、計算機は、第一データから第にデータ片を削除したデータをネットワークに送信してもよいし、第一データから第二データ片を削除してもよい。

本実施形態に記載の処理の例は、本議論の目的のための単なる処理の例として記載されたものである。本実施形態の観点に照らして、多くの他のバリエーションが当業者にとって明白である。さらに、本実施形態において処理を実行するための適切なフレームワーク、構成、及び環境のいくつかの例が明らかにされている一方、実装は本実施形態において開示された又は議論された特定の例に限られない。さらに、本実施形態は、上述したように、また図面に記載されているように、種々の実装例を提供している。しかし、本開示は、上述された実装及び図面に記載された実装に限定されず、当業者にとって既知である他の実装又は当業者が知ることになる他の実装に拡張することができる。

本実施形態の様々な指示、処理、及び手法は、コンピュータ読み取り可能な媒体に格納されたプログラムモジュールのような、コンピュータ読み取り可能な指示の通常のコンテキストと考えられてもよく、上述したプロセッサによって実行されてもよい。一般的に、プログラムモジュールは、特定のタスクを実行するための又は特定の抽象データ型を実装するための、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体、実行可能コード等を含む。これらのプログラムモジュール等は、ネイティブコードとして実行されてもよいし、例えば仮想マシン又は他の実行時コンパイル環境等において、ダウンロードされて実行されてもよい。一般的には、プログラムモジュールの機能は、様々な実装の要求に応じて結合又は分散されてもよい。これらのモジュール及び技術の実装は、コンピュータストレージ媒体に格納されていてもよいし、通信媒体を介して送信されてもよい。

本発明の対象が構造上の特徴及び／又は方法論的な動作に特有の言葉を用いて記載されているが、添付の特許請求の範囲で定義される本発明の対象が必ずしも上述した特定の特徴又は動作に限定される必要はないこと、が理解されるべきである。むしろ、当該特定の特徴及び動作は、特許請求の範囲に記載の発明を実行するための一例として記載されているにすぎない。

＜補足＞
＜１５＞
１以上のプロセッサと、実行可能指示を保持するコンピュータ読み取り可能な１以上の非一時的媒体と、を含むシステムであって、
前記実行可能指示が前記１以上のプロセッサに実行された場合、前記１以上のプロセッサは、
ネットワーク状態予測情報と、前記１以上のプロセッサの現在位置情報に基づいて、ネットワークの障害の発生予測を決定し、
前記障害の発生前及び発生中の少なくとも一方において、第１センサから第１データ種別の第１データと、第２センサから第２データ種別の第２データと、を受信し、
前記障害の終了後に、前記第１データに関連付けられた第１優先度及び第１遅延カテゴリの少なくとも一方に基づいて、前記第１データの少なくとも第１データ片を送信し、前記第２データに関連付けられた第２優先度及び第２遅延カテゴリの少なくとも一方に基づいて、前記第２データの少なくとも第２データ片を送信する、ようプログラムされる、システム。

＜１６＞
上記１５に記載のシステムであって、
前記実行可能指示が前記１以上のプロセッサに実行された場合、前記１以上のプロセッサは、
前記発生予測に基づいて、前記障害の発生前又は発生中に受信すると予想されるデータ種別のデータ優先度及び遅延カテゴリの少なくとも一方を決定するよう、プログラムされる、システム。

＜１７＞
上記１６に記載のシステムであって、
前記実行可能指示が前記１以上のプロセッサに実行された場合、前記１以上のプロセッサは、前記少なくとも一方に基づいて、データ送信のための少なくとも１つの送信ルールを、前記障害の終了後に、決定するようプログラムされ、
前記少なくとも１つの送信ルールに基づいて、前記第１データの少なくとも第１データ片と、前記第２データの少なくとも第２データ片と、の送信が行われる、システム。

＜１８＞
上記１５に記載のシステムであって、
前記実行可能指示が前記１以上のプロセッサに実行された場合、前記１以上のプロセッサは、
前記障害の発生中に受信した前記第１データの遅延カテゴリを決定し、
前記第１データの第３データ片が次回の送信機会において送信される場合に、前記第３データ片に対応する遅延カテゴリの時間閾値を超過すると判定し、
前記ネットワークに送信される前記第１データから、前記第１データ片を除外する、ようプログラムされる、システム。

＜１９＞
上記１５に記載のシステムであって、
前記第１データ種別の前記第１データは、第１データプロファイルに関連付けられた第１データバッファに格納され、
前記第２データ種別の前記第２データは、第２データプロファイルに関連付けられた第２データバッファに格納され、
前記第１データプロファイル及び前記第２データプロファイルのそれぞれは、データ生成周期、データサイズ、データ優先度、及び遅延カテゴリの少なくとも１つを示す、システム。

＜２０＞
上記１５に記載のシステムであって、
前記ネットワークは無線ネットワークであり、
前記発生予測は、前記１以上のプロセッサが近付いている地理的領域が、制限された無線カバレッジを含むことの判断に基づき、
前記判断は、前記１以上のプロセッサが過去に収集したネットワーク履歴情報、及びセルラーサービスプロバイダから受信した地理的な通信カバレッジを示唆する情報の少なくとも一方に基づいて、前記地理的領域を決定する、システム。

１０２ 計算機、１０４ ネットワーク計算機、１１０ データ生成器、１１６ プロセッサ、１１８ コンピュータ読み取り可能媒体、１２２ データ管理アプリケーション、１２４ データバッファ／データストレージ、１２６ プロセッサ、１２８ コンピュータ読み取り可能媒体、１３２ データ格納・処理アプリケーション、４０６ データプロファイルモジュール、４０８ データプロファイル、４１０ ルール決定モジュール、４１２ データプロファイルデータ構造体、４１４ ネットワーク状態予測モジュール、４１６ ネットワーク状態履歴情報、４２４ ネットワーク状態予測情報、４２６ データ送信ルール、４２８ 送信ルール適用モジュール、４３０ データ採集モジュール、４３２ データバッファ、４３４ 送信モジュール

Claims (9)

1. １以上のプロセッサと、コンピュータ読み取り可能な１以上の非一時的媒体と、を含むシステムであって、
   前記１以上の非一時的媒体は、前記１以上のプロセッサに実行された場合に、前記１以上のプロセッサに処理を実行させるようプログラムする実行可能指示を保持し、
   前記処理は、
   ネットワークの障害の発生予測を決定する第１決定処理と、
   前記障害の発生中に受信すると予想される１以上のデータ種別の優先度を決定し、前記１以上のデータ種別の遅延カテゴリを決定する第２決定処理と、
   前記優先度及び前記遅延カテゴリに基づいて、前記１以上のデータ種別のためのデータ送信ルールを格納する格納処理と、
   前記ネットワークに送信するためのデータを、前記障害の発生中に、１以上のデータ生成器から受信する受信処理と、
   前記データ送信ルールに基づいて、前記受信したデータの少なくとも一部を前記ネットワークに送信する送信処理と、を含む、システム。
2. 請求項１に記載のシステムであって、
   前記受信処理は、
   前記障害の発生中に、前記データ送信ルールに基づいて、前記受信したデータの複数のデータ片を選択する選択処理と、
   ネットワーク障害終了後の最初の送信機会において、前記選択したデータ片を前記ネットワークに送信する送信処理と、を含む、システム。
3. 請求項２に記載のシステムであって、
   前記選択処理は、
   第１データ種別の第１データを第１データ生成器から、第１データバッファに格納するために受信し、
   第２データ種別の第２データを第２データ生成器から、第２データバッファに格納するために受信し、
   前記第１データ種別は前記第２データ種別より高い優先度を有すると決定し、
   前記第１データの第１データ片と、前記第２データの第２データ片と、を送信するために選択する、ことを含み、
   前記第１データ片は圧縮されず、
   前記第２データ片は、送信される前に、前記優先度に基づいて圧縮される、システム。
4. 請求項１に記載のシステムであって、
   前記処理は、
   前記障害の発生中に受信したデータの遅延カテゴリを決定し、
   当該データの第１データ片が次回の送信機会において送信された場合に、前記第１データ片に対応する遅延カテゴリの時間閾値を超過すると判定し、
   前記ネットワークに送信されるデータから、前記第１データ片を除外する、ことを含むシステム。
5. 請求項１に記載のシステムであって、
   前記１以上のデータ生成器は、データサンプル、規則的な周期及び規則的なデータ量のデータサンプルを提供する１以上のセンサを含む、システム。
6. プロセッサによって実行される方法であって、
   前記方法は、
   前記プロセッサが、
   ネットワークの障害の発生予測を決定する第１決定処理と、
   前記障害の発生中に受信すると予想される１以上のデータ種別の優先度を決定し、前記１以上のデータ種別の遅延カテゴリを決定する第２決定処理と、
   前記優先度及び前記遅延カテゴリに基づいて、前記１以上のデータ種別のためのデータ送信ルールを格納する格納処理と、
   前記ネットワークに送信するためのデータを、前記障害の発生中に、１以上のデータ生成器から受信する受信処理と、
   前記データ送信ルールに基づいて、前記受信したデータの少なくとも一部を前記ネットワークに送信する送信処理と、を実行することを含む、方法。
7. 請求項６に記載の方法であって、
   前記受信処理は、
   前記障害の発生中に、前記データ送信ルールに基づいて、前記受信したデータの複数のデータ片を選択する選択処理と、
   ネットワーク障害終了後の最初の送信機会において、前記選択したデータ片を前記ネットワークに送信する送信処理と、を含む、方法。
8. 請求項７に記載の方法であって、
   前記選択処理は、
   第１データ種別の第１データを第１データ生成器から、第１データバッファに格納するために受信し、
   第２データ種別の第２データを第２データ生成器から、第２データバッファに格納するために受信し、
   前記第１データ種別は前記第２データ種別より高い優先度を有すると決定し、
   前記第１データの第１データ片と、前記第２データの第２データ片と、を送信するために選択する、ことを含み、
   前記第１データ片は圧縮されず、
   前記第２データ片は、送信される前に、前記優先度に基づいて圧縮される、方法。
9. 請求項６に記載の方法であって、
   前記プロセッサが、
   前記障害の発生中に受信したデータの遅延カテゴリを決定し、
   当該データの第１データ片が次回の送信機会において送信された場合に、前記第１データ片に対応する遅延カテゴリの時間閾値を超過すると判定し、
   前記ネットワークに送信されるデータから、前記第１データ片を除外する、ことをさらに含む、方法。

Images