特表 2024-524005 メッセージエネルギ予測を使用する無線デバイス用のバッテリ寿命延長

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-07-05

(54)【発明の名称】メッセージエネルギ予測を使用する無線デバイス用のバッテリ寿命延長

(51)【国際特許分類】

   H04W 52/02 20090101AFI20240628BHJP

   H04W 24/02 20090101ALI20240628BHJP

【ＦＩ】

H04W52/02 110

H04W24/02

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023574397

(86)(22)【出願日】2022-06-28

(85)【翻訳文提出日】2024-01-25

(86)【国際出願番号】 IB2022055970

(87)【国際公開番号】W WO2023275724

(87)【国際公開日】2023-01-05

(31)【優先権主張番号】63/217,304

(32)【優先日】2021-07-01

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】316005926

【氏名又は名称】ソニーセミコンダクタソリューションズ株式会社

(74)【代理人】

【識別番号】110003339

【氏名又は名称】弁理士法人南青山国際特許事務所

(72)【発明者】

【氏名】セメル ラビ

(72)【発明者】

【氏名】ラスキ イタイ

(72)【発明者】

【氏名】コーエン ロイ

(72)【発明者】

【氏名】ベン－ナン スタブ

(72)【発明者】

【氏名】コスティアノフスキ アーロン

(72)【発明者】

【氏名】アビドル タル

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA43

5K067BB27

5K067BB28

5K067CC22

5K067DD27

5K067EE02

5K067EE16

(57)【要約】

通信のための方法は、無線通信ネットワーク上の無線デバイス(24)の通信に少なくとも関する情報を収集することを含む。収集された情報に基づいて、無線通信ネットワークにおいて通信動作を実行するために無線デバイスにおいて必要とされるエネルギ量を予測するエネルギ予測モデルが維持される。無線通信ネットワークにおいて無線デバイスによって実行されるべき通信動作について、通信動作が実行される時間は、エネルギ予測モデルに基づいてスケジューリングされる。通信動作は、スケジュールされた時間に実行される。
【選択図】図１

【特許請求の範囲】

【請求項1】

通信のための方法であって、
無線通信ネットワークを介した無線デバイスの少なくとも通信に関する情報を収集するステップと、
前記収集された情報に基づいて、前記無線通信ネットワークにおいて通信動作を実行するために前記無線デバイスにおいて必要とされるエネルギ量を予測するエネルギ予測モデルを維持するステップと、
前記無線通信ネットワークにおいて前記無線デバイスによって実行されるべき通信動作について、前記エネルギ予測モデルに基づいて、前記通信動作が実行されることになる時間をスケジューリングするステップと、
前記スケジューリングされた時間において前記通信動作を実行するステップと
を含む
方法。

【請求項2】

前記通信動作を実行するステップは、前記無線通信ネットワークを介してメッセージを通信することを含む
請求項１に記載の方法。

【請求項3】

前記通信動作を実行するステップは、前記無線通信ネットワークの可用性について走査することを含む
請求項１に記載の方法。

【請求項4】

前記通信動作を実行するステップは、前記無線デバイスのモデムをウェイクアップし、前記モデムによって信号を受信することを含む
請求項１に記載の方法。

【請求項5】

前記通信動作を実行するステップは、前記無線デバイスのモデムをスリープ期間に設定することを含む
請求項１に記載の方法。

【請求項6】

前記時間をスケジューリングするステップは、少なくとも、前記無線デバイスのバッテリの寿命を最大化することを目的とするスケジューリングポリシーに従って、前記時間を決定することを含む
請求項１に記載の方法。

【請求項7】

前記情報を収集するステップは、前記無線デバイスのバッテリに関する情報を収集することを含み、
前記エネルギ予測モデルを維持するステップは、前記バッテリに関する情報に基づいて、前記通信動作に続いて前記バッテリに残っている有効エネルギ容量を予測することを含み、かつ、
前記時間をスケジューリングするステップは、前記有効エネルギ容量に依存する
請求項１に記載の方法。

【請求項8】

前記時間をスケジューリングするステップは、現在の一期間において前記通信動作を実行するか、または、後の一期間に前記通信動作を実行するかの決定を延期するかを決定することを含む
請求項１～７のいずれか１項に記載の方法。

【請求項9】

前記情報を収集するステップは、前記無線通信ネットワークを介した1つ以上の追加の無線デバイスの通信に関する追加の情報を収集することをさらに含み、かつ、
前記エネルギ予測モデルを維持するステップは、前記無線デバイスに関する情報と前記追加の無線デバイスに関する前記追加の情報との両方に基づくものである
請求項１～７のいずれか１項に記載の方法。

【請求項10】

前記エネルギ予測モデルを維持するステップは、前記無線デバイスにおいて実行される
請求項１～７のいずれか１項に記載の方法。

【請求項11】

前記エネルギ予測モデルを維持するステップは、前記無線通信ネットワークを介して前記無線デバイスと通信するサーバにおいて実行される
請求項１～７のいずれか１項に記載の方法。

【請求項12】

前記エネルギ予測モデルを維持するステップは、前記無線デバイスにおいて部分的に実行され、前記無線通信ネットワークを介して前記無線デバイスと通信するサーバにおいて部分的に実行される
請求項１～７のいずれか１項に記載の方法。

【請求項13】

前記情報を収集するステップは、前記エネルギ予測モデルを維持するための専用である1つ以上の専用ウェイクアップ期間において前記情報を収集するために、前記無線デバイスのモデムおよび/または1つ以上の追加の無線デバイスのモデムをウェイクアップすることを含む
請求項１～７のいずれか１項に記載の方法。

【請求項14】

前記エネルギ予測モデルに基づいて前記時間をスケジューリングするステップは、
前記メッセージを通信する際に超えてはならない総エネルギ予算を受信することと、
前記総エネルギ予算を満たすように前記時間をスケジューリングすることと
を含む
請求項１～７のいずれか１項に記載の方法。

【請求項15】

前記収集された情報の少なくとも一部、または、前記収集された情報から導出される前処理された情報を、前記無線通信ネットワークのオペレータと共有することを含む
請求項１～７のいずれか１項に記載の方法。

【請求項16】

前記収集された情報に基づいて、前記バッテリに関する異常または統計情報を報告することを含む
請求項１～７のいずれか１項に記載の方法。

【請求項17】

無線通信ネットワークを介して通信するように構成された、モデムおよびバッテリを備える無線デバイスと、
前記無線通信ネットワークを介した前記無線デバイスの少なくとも通信に関する情報を収集し、
前記収集された情報に基づいて、前記無線通信ネットワークにおいて通信動作を実行するために前記無線デバイスにおいて必要とされるエネルギ量を予測するエネルギ予測モデルを維持し、かつ、
前記無線通信ネットワークにおいて前記無線デバイスによって実行されるべき通信動作について、前記エネルギ予測モデルに基づいて、前記通信動作が実行されることになる時間をスケジューリングする
ように構成された１つ以上のプロセッサと
を具備する
装置。

【請求項18】

前記通信動作は、前記無線通信ネットワークを介してメッセージを通信することを含む
請求項１７に記載の装置。

【請求項19】

前記通信動作は、前記無線通信ネットワークの可用性について走査することを含む
請求項１７に記載の装置。

【請求項20】

前記通信動作は、前記無線デバイスのモデムをウェイクアップし、前記モデムによって信号を受信することを含む
請求項１７に記載の装置。

【請求項21】

前記通信動作は、前記無線デバイスのモデムをスリープ期間に設定することを含む
請求項１７に記載の装置。

【請求項22】

前記１つ以上のプロセッサは、少なくとも、前記無線デバイスのバッテリの寿命を最大化することを目的とするスケジューリングポリシーに従って、前記時間を決定するように構成されている
請求項１７に記載の装置。

【請求項23】

前記１つ以上のプロセッサは、
前記無線デバイスのバッテリに関する情報を収集し、
前記バッテリに関する情報に基づいて、前記通信動作に続いて前記バッテリに残っている有効エネルギ容量を予測し、かつ、
前記有効エネルギ容量に依存する前記時間をスケジューリングする
ように構成されている
請求項１７に記載の装置。

【請求項24】

前記１つ以上のプロセッサは、現在の一期間において前記通信動作を実行するか、または、後の一期間に前記通信動作を実行するかの決定を延期するかを決定することによって、前記時間をスケジュールするように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項25】

前記１つ以上のプロセッサは、前記無線通信ネットワークを介した1つ以上の追加の無線デバイスの通信に関する追加の情報を収集し、かつ、
前記無線デバイスに関する情報と前記追加の無線デバイスに関する前記追加の情報との両方に基づくものである前記エネルギ予測モデルを維持する
ように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項26】

前記１つ以上のプロセッサは、前記無線デバイスにおいて前記エネルギ予測モデルを維持するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項27】

前記１つ以上のプロセッサは、前記無線通信ネットワークを介して前記無線デバイスと通信するサーバにおいて前記エネルギ予測モデルを維持するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項28】

前記１つ以上のプロセッサは、前記無線デバイスにおいて部分的に前記エネルギ予測モデルを維持し、前記無線通信ネットワークを介して前記無線デバイスと通信するサーバにおいて部分的に前記エネルギ予測モデルを維持するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項29】

前記１つ以上のプロセッサは、前記エネルギ予測モデルを維持するための専用である1つ以上の専用ウェイクアップ期間において前記情報を収集するために、前記無線デバイスのモデムおよび/または1つ以上の追加の無線デバイスのモデムをウェイクアップすることによって前記情報を収集するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項30】

前記１つ以上のプロセッサは、
前記メッセージを通信する際に超えてはならない総エネルギ予算を受信し、かつ、
前記総エネルギ予算を満たすように前記時間をスケジューリングする
ように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項31】

前記１つ以上のプロセッサは、前記収集された情報の少なくとも一部、または、前記収集された情報から導出される前処理された情報を、前記無線通信ネットワークのオペレータと共有するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【請求項32】

前記１つ以上のプロセッサは、前記収集された情報に基づいて、前記バッテリに関する異常または統計情報を報告するように構成されている
請求項１７～２３のいずれか１項に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2021年7月1日に出願された米国仮特許出願第63/217,304号の利益を主張し、その開示は、参照により本明細書に組み込まれる。

【0002】

本発明は、一般に、無線通信に関し、特に、無線デバイスのエネルギ消費を低減するための方法およびシステムに関する。

【背景技術】

【0003】

エネルギ消費は、多くのワイヤレスデバイスの設計および動作における主要な要因であり、1つの典型的な例は、モノのインターネット(IoT)デバイスである。一部のIoTデバイスは、数年間非充電式バッテリで動作する必要があり、過酷な通信条件を指示する場所に設置される場合がある。さらに、IoTデバイスは、典型的には、極めて低コストの設計に制約され、それによって、それらの通信能力を制限する。これらの全ての要因は、IoTデバイスが可能な限り少ないエネルギを消費することを重要にする。

【発明の概要】

【0004】

本明細書で説明される本発明の実施形態は、無線通信ネットワークを介した無線デバイスの通信に関する情報を少なくとも収集するステップを含む、通信のための方法を提供する。収集された情報に基づいて、無線通信ネットワークにおいて通信動作を実行するために無線デバイスにおいて必要とされるエネルギ量を予測するエネルギ予測モデルが維持される。無線通信ネットワークにおいて無線デバイスによって実行されるべき通信動作について、通信動作が実行される時間は、エネルギ予測モデルに基づいてスケジューリングされる。通信動作は、スケジュールされた時刻に実行される。

【0005】

種々の実施形態において、通信動作を実行することは、無線通信ネットワークを介してメッセージを通信すること、無線通信ネットワークの可用性のために走査すること、無線デバイスのモデムをウェイクアップさせ、モデムによって信号を受信すること、および/または、無線デバイスのモデムをスリープ期間に設定することを含む。典型的には、時間をスケジューリングすることは、少なくとも無線デバイスのバッテリの寿命を最大化することを目的とするスケジューリングポリシーに従った時間を決定することを含む。

【0006】

いくつかの実施形態では、情報を収集することは、無線デバイスのバッテリに関する情報を収集することを含み、エネルギ予測モデルを維持することは、バッテリに関する情報に基づいて、通信動作に続いてバッテリに残っている有効エネルギ容量を予測することを含み、時間のスケジューリングは、有効エネルギ容量に依存する。

【0007】

一実施形態では、時間をスケジューリングすることは、現在の期間において通信動作を実行するか、または、後の期間に通信動作を実行するかの決定を延期するかを決定することを含む。別の実施形態では、情報を収集することは、無線通信ネットワークを介した1つ以上の追加の無線デバイスの通信に関する追加情報を収集することをさらに含み、エネルギ予測モデルを維持することは、無線デバイスに関する情報と追加の無線デバイスに関する追加情報との両方に基づく。

【0008】

種々の実施形態では、エネルギ予測モデルを維持することは、無線通信ネットワークを介して無線デバイスと通信するサーバにおいて、または、無線デバイスにおいて部分的に、および無線通信ネットワークを介して無線デバイスと通信するサーバにおいて部分的に、無線デバイスにおいて実行される。

【0009】

開示される一実施形態では、情報を収集することは、エネルギ予測モデルを維持するために専用である、1つ以上の専用ウェイクアップ期間において情報を収集するために、無線デバイスのモデム、および/または1つ以上の追加の無線デバイスのモデムをウェイクアップすることを含む。開示される一実施形態では、エネルギ予測モデルに基づいて時間をスケジューリングすることは、メッセージを通信する際に超えてはならない総エネルギ予算を受信することと、総エネルギ予算を満たすように時間をスケジューリングすることとを含む。

【0010】

一実施形態では、本方法はさらに、収集された情報の少なくとも一部、または、収集された情報から導出された前処理された情報を、無線通信ネットワークのオペレータと共有することを含む。加えて、または代替的に、本方法は、収集された情報に基づいて、バッテリに関する異常または統計情報を報告することをさらに含み得る。

【0011】

本発明の一実施形態によれば、無線デバイスと1つ以上のプロセッサとを含む通信デバイスがさらに提供される。無線デバイスは、無線通信ネットワークを介して通信するように構成され、モデムとバッテリとを含む。1つ以上のプロセッサは、無線通信ネットワークを介した無線デバイスの通信に関連する情報を収集し、収集された情報に基づいて、無線通信ネットワークにおいて通信動作を実行するために無線デバイスにおいて必要とされるエネルギの量を予測するエネルギ予測モデルを維持し、エネルギ予測モデルに基づいて、通信動作が実行されることになる時間を、無線通信ネットワークにおいて無線デバイスによって実行されるべき通信動作のためにスケジューリングするように構成されている。

【図面の簡単な説明】

【0012】

本発明は、図面と併せて、その実施形態の以下の詳細な説明からより完全に理解される。

【図1】本発明の実施形態による無線IoT通信システムを概略的に示すブロック図である。

【図2】本発明の実施形態による無線IoT通信システムを概略的に示すブロック図である。

【図3】A～Cは、本発明の一実施形態による、バッテリ寿命延長のためのメッセージ送信のスケジューリングを概略的に示すグラフである。

【図4】本発明の一実施形態による、バッテリ寿命延長のためのメッセージ送信をスケジューリングする方法を概略的に示すフローチャートである。

【図5】本発明の実施形態に従って、バッテリ有効容量予測を含むエネルギ予測方式を概略的に示す図である。

【図6】本発明の実施形態に従って、バッテリ有効容量予測を含むエネルギ予測方式を概略的に示す図である。

【発明を実施するための形態】

【0013】

（バッテリについての紹介）
様々なタイプのIoTデバイスおよび他のワイヤレス通信デバイスは、バッテリ動作である。バッテリの種類が異なると、化学、電圧、ピーク電流、容量、フォームファクタ、その他の特性が異なる。所与の用途のための適切なバッテリを選択するための考慮事項は、コスト、安全性、容量、ピーク電流要件、および他の要因に関係し得る。

【0014】

バッテリ内に蓄積される電荷Cは、通常、ミリアンペアアワー(mAh)で測定される。バッテリの電荷およびピーク電流は通常関連している。すなわち、バッテリは通常1Cの大きさの電流を供給することができ、例えば、C=100 mAhを有するバッテリは100mAのピーク電流を供給することができる。特定の用途に合わせてバッテリを選択する場合、容量とピーク電流の両方の要件を考慮する必要がある。

【0015】

アプリケーションが、バッテリのピーク電流能力を超えるピーク電流を消費するとき、バッテリの出力電圧は、典型的には、公称電圧を下回る。さらに、過剰な電流引き込みは、バッテリ能力の過剰な摩耗により、バッテリ容量の加速された劣化を引き起こす。

【0016】

従って、バッテリの通常の使用(すなわち、バッテリの定格ピーク電流を下回る電流を引き出す使用)の場合、バッテリの容量低下は、バッテリから排出されるエネルギ量と等しくなる(例えば、100mAhの容量を有するバッテリは、10時間の間、10mAを送達し得る;同様に、10mAhを消費した後、残りの容量は、90mAhとなる)。

【0017】

ただし、(上記のように)バッテリの規定ピーク電流以上を消費するデバイスでは、上記の例は成り立たない。例えば、容量が100mAhのバッテリの場合、600mAの電流を引き出すデバイスは、10分間はホールドしないが、はるかに少ない。容量の劣化は、引き込まれている過度の電流の大きさと、このような高電流消費の継続時間に依存する。

【0018】

この連続した持続時間を、時間的に互いに離間しているより短い期間に分けることができる場合、バッテリの劣化はそれほど顕著ではない(全持続時間が同じままである場合であっても)。つまり、過大な電流引き込みがバッテリの寿命に与える影響は、バッテリの定格容量だけでなく、バッテリの実際の使用プロファイルにも左右される。

【0019】

アプリケーションの観点から、より重要な性能指数は、バッテリの有効容量、すなわち、消費され得る実際のエネルギ量(例えば、バッテリから消費されるエネルギのパルス)である。有効容量は、例えば、各々が一定量のエネルギを有し、バッテリがその終止電圧(デバイスがまだ作動できる最小電圧)に達する前にバッテリから消耗され得るパルス数で表すことができる。

【0020】

電池を定期的に使用する場合、電池の定格容量に近い実用的な有効エネルギ量が得られる。過度の使用では、定格ピーク電流を超えると、バッテリ有効容量が定格容量より大幅に低下する可能性がある。

【0021】

以下に説明される本発明のいくつかの実施形態は、特定の活動プロファイルを仮定して、所与の状態において、どのくらいの活動がバッテリによって依然としてサポートされ得るかを理解するという課題に対処する。開示された実施形態は、バッテリの通常の使用(バッテリの定格ピーク電流を下回る)およびバッテリの過剰な使用(定格ピーク電流を上回る)の両方を扱う。後者の場合、バッテリおよびデバイス活動のより精巧なモデリングが行われる。次のセクションでは、エネルギ予測モデルの一部として、バッテリ有効容量の予測を検討する。

【0022】

（概要）
本明細書で説明される本発明の実施形態は、無線デバイスのエネルギ消費を低減し、それによってデバイスのバッテリ寿命を延ばすための方法およびシステムを提供する。本明細書で説明する実施形態は、一例として主にIoTデバイスを参照するが、開示する技法は、概して、様々な他のタイプの通信デバイスに適用可能である。

【0023】

いくつかの実施形態では、1つ以上のIoTデバイス(本明細書では「デバイス」と呼ばれる)は、無線ネットワーク、例えば、セルラネットワークを介してアプリケーションサーバ(本明細書では「サーバ」と呼ばれる)と通信する。実際には、所与のメッセージを通信する(メッセージを送信または受信する)ためにデバイスにおいて必要とされるエネルギの量は一定ではない。必要なエネルギ量は、経時的に変化し得る。さらに、必要なエネルギ量は、デバイスが設置される場所、ワイヤレスネットワークの構成、ワイヤレスチャネル条件、セルラネットワーク条件(例えば、ネットワークの利用レベル)、周囲条件(例えば、温度)、現在の時刻、およびアプリケーション挙動などの要因に依存し得る。
一方、多くのIoTアプリケーションは、メッセージ転送のかなりの遅延を許容することができる。この許容は、メッセージの送信時間をスケジュールする際にある程度の自由度を可能にする。

【0024】

本発明のいくつかの実施形態では、システム内、デバイス内、および/またはサーバ内の1つ以上のプロセッサが、デバイスバッテリ寿命を延ばすことを目的とするアルゴリズムを使用してメッセージの通信をスケジューリングするソフトウェアを実行する。簡単にするために、以下の説明は、開示された技法を実行するものとして「プロセッサ」を指す。一般に、これらの技術は、デバイス内(例えば、デバイスのモデムまたはホストプロセッサ内)の任意の数のプロセッサを使用して、サーバ内で、または、サーバ側とデバイス側のプロセッサ間の任意の適切な「分業」を使用して実行することができる。

【0025】

いくつかの実施形態において、プロセッサは、無線通信ネットワーク、および可能であれば他の要因を介した通信に関する情報を収集する。関連情報は、例えば、チャネル品質パラメータ、ネットワークの(例えば、デバイスが通信する基地局の)構成パラメータ、周囲条件(例えば、温度)に関する情報、バッテリ条件に関する情報、およびIoTアプリケーションのメタデータを含むことができる。また、情報は、これらに限定されないが、近くの無線デバイスを含む、外部ソースから収集され得る。収集された情報に基づいて、プロセッサは、無線通信ネットワークを介してメッセージを通信するために必要とされるエネルギの量を予測するエネルギ予測モデルを維持する。

【0026】

次いで、デバイスと(例えば、デバイスとクラウドとの間で)通信されるべき特定のメッセージについて、プロセッサは、エネルギ予測モデルに基づいて、メッセージが通信されることになる時間をスケジューリングする。このスケジューリングアルゴリズムは、より低いエネルギを必要とする予定時刻(「送信機会」)でメッセージを通信し、高いエネルギ消費を特徴とする時間を回避することを目的とする。また、スケジューリングアルゴリズムは、例えば、アプリケーションによって定義される待ちレイテンシ制限に関連する制約を考慮してもよい。ある実施形態では、プロセッサは、モデルに基づいて、現在の送信機会(例えば、タイムスロット)においてメッセージを通信するか、または、将来の送信機会に決定を延期するかを決定する。

【0027】

いくつかの実施形態では、エネルギ予測モデルはまた、デバイスバッテリの複雑なモデルも含む。上記で説明したように、いくつかのバッテリでは、有効なバッテリ残容量は、ロード(例えば、モデムおよびホストプロセッサ)に送達されるエネルギの総量だけでなく、環境条件、使用プロファイル、および使用履歴(上記で説明した加速劣化による)などの要因にも依存する。いくつかの実施形態では、メッセージの通信をスケジューリングするとき、エネルギ予測モデルは、これらの要因を使用して、メッセージの通信に続いて、バッテリの将来の状態(バッテリ有効容量とも呼ばれる)を予測する。

【0028】

より一般的には、いくつかの実施形態では、エネルギ予測モデルは、メッセージの送信および受信だけでなく、IoTデバイスによって実行される様々なタイプの通信動作のエネルギ消費を予測するために使用される。他の種類の通信動作は、例えば、ネットワークの利用可能性についてのスキャン、モデルを改善するための信号を感知するためのデバイスモデムのウェイクアップ、スリープ期間などを備え得る。エネルギ予測モデルの任意の要素、例えば、残りの有効バッテリ容量を予測すること、およびスケジューリング決定を行うことは、そのような通信動作に適用され得る。

【0029】

いくつかの実施形態では、エネルギ予測モデルの開発および更新は、専らデバイス側で行われる。他の実施形態では、モデルは、サーバ側で開発され、維持され、デバイスにダウンロードされる。さらに他の実施形態では、モデルは、デバイスおよびサーバによって共同で開発され、更新される。様々なハイブリッド方式が本明細書で説明される。また、個々のデバイスのエネルギ予測モデルを改善するための複数のデバイス間で情報を共有するための方式、および、センサなどの外部ソースから受信した情報を用いてモデルを改善するための方式についても述べられる。

【0030】

開示される技術の様々なシステム構成および実装例が、本明細書で説明される。

【0031】

（システムの説明）
図1は、本発明の一実施形態による無線IoT通信システム20を概略的に示すブロック図である。システム20は、バッテリ26によって電力供給されるIoTデバイス24を備える。デバイス24は、例えばセルラネットワークなどの無線ネットワーク(同図には示されていない)を介してサーバ28と通信する。サーバ28はクラウドベースのサーバであってもよく、従って、サーバ28およびサーバ側ユーザアプリケーション36は単に「クラウド」と呼ばれることもある。

【0032】

デバイス24は、適切なユーザアプリケーションを実行するホストプロセッサを含む。デバイス側のユーザアプリケーションは、サーバ側のユーザアプリケーション36と通信する。この通信には、デバイス24からサーバ28へ、およびサーバ28からデバイス24へ、メッセージ(例えばパケット)の送信が含まれる。「メッセージ」および「パケット」という用語は、ここでは同じ意味で使用される。

【0033】

デバイス24はさらに、無線ネットワークを介してサーバ28との間でメッセージを送受信する無線モデム40を備える。モデム40によって使用されるプロトコル、例えば物理層(PHY)および媒体アクセス制御(MAC)プロトコルは、無線(例えば、セルラ)ネットワークのプロトコルに依存する。モデム40は、モデムの物理層タスクを実行するPHYモジュール48と、上位層タスク、典型的にはMAC層以上を実行する上位層モジュール52を含む。

【0034】

本実施形態では、モデム40は、以下で詳述するように、エネルギ予測に使用される情報の一部を収集するために使用されるスペクトル感知モジュール56をさらに備える。他の実施形態では、モジュール56は省略される。

【0035】

図1の例では、IoTデバイス24は、デバイス内のエネルギ消費を低減し、デバイスのバッテリ寿命を延ばすために、デバイス24との間のメッセージの通信をスケジュール設定するバッテリ寿命延長モジュール44を備える。バッテリ延長モジュール44は、簡潔にするために、本明細書では「延長モジュール」とも呼ばれる。延長モジュール44は、データ収集モジュール60と、エネルギ推定モジュール64(エネルギ予測モジュールとも呼ばれる)と、決定モジュール68(スケジューリングアルゴリズムを実行するスケジューリングモジュールとも呼ばれる)と、スケジューラ/コントローラ72とを備える。

【0036】

同図では別個のモジュールとして描かれているが、いくつかの実施形態では、モジュール44はモデム40の一部として埋め込まれている。例えば、モデム40は、モジュール44のタスクを実行する適切なプロセッサを含むことができる。代替実施形態では、モジュール44は、別の適切なプロセッサ、例えば、ユーザアプリケーションも実行するホストプロセッサ32上で実行することができる。モジュール44は、典型的には、例えば、モジュール60によって収集された情報およびモジュール68によって行われた部分決定を記憶する適切なメモリ(同図には示されていない)に結合される。

【0037】

データ収集モジュール60は、エネルギ消費推定およびメッセージ転送スケジューリングに関連する関連情報(メタデータとも呼ばれる)を収集かつ集約する役割を果たす。通常、必ずしもそうではないが、情報はモデム40の種々のモジュールから収集される。収集される情報の非限定的な例は、以下を含む。
■ PHYモジュール48から収集される現在および過去の情報: 受信信号強度インジケータ(RSSI)、信号対干渉および雑音比(SINR)基準信号受信電力(RSRP)、3GPP（登録商標）チャンネル品質インジケータ、隣接チャネルの測定などのようなチャンネル品質インジケータ(CQI)。
■ 上位層モジュール52から収集される情報、主にネットワーク構成およびパラメータ。この情報は、例えば、ブロードキャストまたはユニキャストのいずれかのネットワーク信号メッセージをデコードすることによって取得することができる。ネットワークパラメータは、例えば、基地局によって構成されたアップリンクおよび/またはダウンリンクの繰り返しの数の設定を含んでもよい。
■ スペクトルセンシングモジュール56から収集された情報:例えば、無線ネットワークによって使用される他の周波数帯域を走査することによって、無線スペクトルをセンシングすることによって収集されたメタデータ。

【0038】

収集モジュール60によって収集されたデータは、モデム40の通常の活動中、すなわち、モデムがメッセージを送信かつ/または受信するためにウェイクアップする期間中に収集され得る。加えて、または代替として、スケジューラ/コントローラ72は、エネルギ予測およびメッセージスケジューリングアルゴリズムの改善のための情報の収集のために専用の専用ウェイクアップ期間中にモデム40をウェイクアップし得る。専用のウェイクアップ期間中、モデムまたはホストプロセッサは、例えば、モジュール56を使用してスペクトルを感知し、基地局から、または近隣の基地局からメッセージを受信し、デコードし、ネットワークへの接続を試み、温度測定値を収集し、または任意の他の適切な動作を実行し得る。
専用のウェイクアップ期間をスケジュールするかどうか、いつ、およびどのくらいの頻度でスケジュールするかを決定する際に、スケジューラ/コントローラ72は、通常、これらのウェイクアップ期間によって被るエネルギ消費を考慮する。

【0039】

いくつかの実施形態では、スケジューラ/コントローラ72は、専用のウェイクアップ期間をスケジューリングする際に自律的である。他の実施形態では、専用ウェイクアップ期間のスケジューリングは、半自律的のみである。これらの実施形態では、スケジューラ/コントローラ72は、サーバ28またはホストプロセッサ32にスケジューリングポリシーを推奨するが、ポリシーに関する最終決定は、サーバまたはホストプロセッサによってなされる。さらに他の実施形態では、スケジューラ/コントローラ72は非自律型であり、すなわち、専用のウェイクアップ期間のスケジューリングのためのポリシーは、サーバ28またはホストプロセッサ32によって排他的に作られる。

【0040】

エネルギ予測モジュール64は、所与のメッセージを送信または受信するためにデバイス24において必要とされるエネルギの量を予測することを担う。モジュール64は、通常、この目的のために「エネルギ予測モデル」と呼ばれるアルゴリズムモデルを維持する。モジュール64は、典型的には、通信されるメッセージに関する情報、例えば、メッセージ長、および可能であれば、プロトコルのタイプ(例えば、プロトコルがUDPであるかTCPであるか、セキュリティプロトコルが使用されているかどうか、メッセージサイズ転送に大きな影響を与える可能性があるかなど)のような追加情報をユーザアプリケーション32から受け取る。

【0041】

また、モジュール64は、モジュール60によってモデム40から収集された関連情報を受信し、温度センサ30からの温度読取り値などの追加のソース(デバイスの外部および/または内部)から情報を収集することもできる。また、モジュール64は、処理時間および電力状態情報、ならびにバッテリ26に関する情報などの情報をホストプロセッサ32から受信することができる。実施形態では、モジュール44は、バッテリパラメータを直接読み取ることができる。

【0042】

利用可能な情報に基づいて、モジュール64のエネルギ予測モデルは、所与のメッセージを通信する(必要に応じて、送信または受信する)ためにデバイス24において必要とされるエネルギの量を推定する。実際には、必要とされるエネルギのほとんどは、モデム40の動作によるものであるが、他の構成要件(例えば、ホストプロセッサ32)もまた、エネルギ消費に無視できない寄与を有し得る。いくつかの実施形態では、必ずしもそうではないが、モジュール64は、最初に、メッセージを通信するために必要とされる総持続時間(例えば、総TX持続時間または総RX持続時間)を推定し、次いで、総持続時間を必要とされるエネルギ量に変換する。

【0043】

いくつかの実施形態において、特定のメッセージに必要なエネルギを予測することに加えて、エネルギ予測モデルはまた、アプリケーションに応じて、追加の論理および有効バッテリ容量管理をより効果的に使用することを可能にしてもよい。一例では、スケジューリングアルゴリズムは、少なくとも1つの緊急メッセージに対して十分なエネルギがバッテリ寿命の終わりに保たれることを保証するために、モデルを使用することができる。

【0044】

いくつかの実施形態では、エネルギ予測モデルは、以下のものを推定および融合することによって、所与のメッセージを通信するために必要とされるエネルギ量を予測する。
■ メッセージを送信する際のデバイス24の期待される活動プロファイル、および全体的な活動プロファイル(例えば、スリープ持続時間)。
■ デバイス24の消費電力推定。
■ バッテリ容量の推定。

【0045】

これらの要因を考慮する例示的な予測スキームは、以下の図5および6に記載される。

【0046】

決定モジュール68は、メッセージの通信をスケジュールする方法を決定する責任を負う。この決定は、モジュール64によって提供されるエネルギ予測に基づいており、レイテンシ、メッセージ重要度、残存バッテリ容量、対象バッテリ寿命、及びその他のような付加的な要因を考慮することができる。モジュール68が取り得る決定の非限定的な例は、以下の通りである。
■ メッセージをそのまま通信(適宜送信または受信)する(すなわち、ホストアプリケーションがモデム40を介してサーバ28へ/からデータを通信できるようにする)。
■ メッセージの通信を遅らせる。遅延は、固定遅延または動的遅延であってもよく、この場合、決定は、特定の期間の後に再検査される。データ遅延は、後続のメッセージのアグリゲーションと組み合わせることもできる。
■ スケジューリングに関する推奨事項をサーバ側に照会する。

【0047】

ある実施形態では、決定モジュール68は、メッセージを送信するためにモデムを即座に起動する決定を含むスケジューリング決定を行う際に自律的である。他の実施形態では、決定モジュール68のスケジューリングアルゴリズムは、半自律的に過ぎない。これらの実施形態では、決定モジュールは、サーバ28またはホストプロセッサ32へのスケジューリング決定を推奨するが、最終決定は、サーバまたはホストプロセッサによって行われる。サーバ28はまた、決定モジュールが考慮する必要があるスケジューリング制限/制限を提供することができる。さらに他の実施形態では、決定モジュール68は非自律的である。
すなわち、スケジューリング決定は、サーバ28またはホストプロセッサ32によって行われる。別の実施形態では、モジュール68は、緊急メッセージを(例えば、バッテリの寿命の終わりに向かって)送るのに十分なエネルギを維持するように構成することもできる。

【0048】

モジュール68で実行されるスケジューリングアルゴリズムは、特定のアプリケーション要件、バッテリ有効容量モデルの変化、ならびに環境条件の変化(または変化の予測)に従って、一時点にその決定を変更し得ることに留意することが重要である。

【0049】

スケジューラ/コントローラ72は、データ収集モジュール60、予測モジュール64および決定モジュール68の間の管理および統合を担当する。スケジューラ/コントローラ72のタスクの一例は、いくつかの実施形態では、スペクトルセンシングを実行するため、および/またはチャネル条件およびネットワーク構成の推定を更新するためにモデム40をいつウェイクアップするかを決定し、それに応じてモデムを制御することである。

【0050】

いくつかの実施形態では、開示された技法を実行するために、ホストプロセッサ32とバッテリ寿命延長モジュール44との間に適切なインターフェースが定義される。例えば、ホストプロセッサ32が送信のためにメッセージのモデム40データ(「ペイロード」)を送るとき、ホストプロセッサはまた、モジュール44にこのメッセージのためのスケジューリング制約を提供する。制約は、例えば、メッセージに対して許可される最大レイテンシ、バッテリ制約などを備え得る。バッテリ制約の1つのタイプは、メッセージを送信する際に超えてはならない総エネルギ予算(例えば、ジュール単位)である。
モジュール44は、制約を様々な方法で使用することができ、例えば、それらを自律的に使用してスケジューリング決定を行うか、または、承認のための推奨スケジューリング決定とともにホストプロセッサに戻る。

【0051】

いくつかの実施形態では、データ収集、予測、および決定タスクの一部は、サーバ28によって実行され得る。この目的のために、デバイス24内のモジュール44は、通常、モデム40および/またはホストプロセッサ32との適切なインターフェースを有し、モジュール44とサーバ28との間の通信を可能にする。サーバ28は、データ収集、予測および/または決定タスクの様々な部分を実行することができる。

【0052】

一実施例では、デバイス24内のモジュール44からの問合せに応答して、サーバ28はスケジューリング決定(例えば、今メッセージを通信するか、または後の時間まで通信を延期するかの決定)を行い、デバイス24に決定を実行するように指示することができる。サーバとの対話には時間がかかり、電力が発生するため、この方式は通常、長いメッセージや、送信を待機しているバッファされたメッセージに適用される。別の例として、サーバ28は、サーバ側のユーザアプリケーション36に、デバイス側の通信条件を通知してもよい。

【0053】

さらに別の例として、サーバ28は、(サーバ側および/またはデバイス側の)ユーザアプリケーション、および/またはネットワーク側で見出された問題に関するネットワーク事業者を更新することができる。このような問題の非限定的な例には、無線状態の劣化があり、その結果、カバー範囲が悪くなる、特定のデバイス24のバッテリ寿命に影響を及ぼすネットワークパラメータの変化などがある。

【0054】

更に、またはこれに代えて、サーバ28は、ユーザアプリケーションを(サーバ側および/またはデバイス側で)更新し、ならびに/もしくはネットワーク事業者をデバイス側で見いだす問題に関して更新することができる。このような問題は、例えば、バッテリ26に関する異常または統計量、例えば、観測された性能が予想または予測された性能からかなり逸脱したバッテリ、またはデバイス自体に関する異常、例えば予測された消費とは異なるエネルギ消費を含み得る。

【0055】

いくつかの実施形態では、サーバ28は、エネルギ予測モデルの少なくとも一部をデバイス24にダウンロードし、必要に応じてパラメータでモデルを更新することを担う。

【0056】

いくつかの実施形態では、モジュール64内のエネルギ予測モデルは、メッセージの送受信に関連するエネルギを予測することに限定されない。より一般的には、エネルギ予測モデルは、他の種類の通信動作を実行するためにデバイス24内で必要とされるであろうエネルギの量を予測することができる。例示的な動作は、例えば、ネットワークのスキャン、メッセージを受信するための、または信号を感知するためのモデルのウェイクアップ、(通信メッセージ間の)スリープ期間などを備え得る。同じトークンによって、決定モジュール68内のスケジューリングアルゴリズムは、任意のそのような通信動作をスケジューリングするために使用され得る。
なお、ここでは、「スリープする」、すなわち、モデムを所定のスリープ期間に設定することも、通信動作の一種とみなす。メッセージ送信/受信(例えば、残存有効バッテリ容量の推定)のコンテキストにおいて本明細書で説明する技術のいずれも、他の通信動作のコンテキストにおいて同様に使用され得る。

【0057】

（複数のデバイス間での情報共有）
図2は、本発明の別の実施形態による無線IoT通信システム80を概略的に示すブロック図である。本実施形態では、複数のIoTデバイス24によって収集された情報は融合され、所与のデバイス24におけるエネルギ予測およびスケジューリングアルゴリズムおよび決定を改善するために使用される。

【0058】

同図に見られるように、サーバ28は、複数デバイス24と通信し、各デバイスは、アルゴリズム的エネルギ再検出モデルを実行するそれぞれのバッテリ寿命延長モジュール44を備える。サーバ28は、サーバ側データ収集モジュール84(デバイス24内のデータ収集モジュール60と混同しないようにする)および解析モジュール88を含む。

【0059】

サーバ側データ収集モジュール84は、複数デバイス24のデータ収集モジュール60によって収集された情報を取得する。分析モジュール88は、エネルギ予測モデルおよびスケジューリングアルゴリズムおよび/または決定を洗練するために、複数のデバイス24によって収集された情報を使用する。分析モジュール84は、モデル更新および更新されたパラメータをデバイス24にダウンロードし、デバイス内のモジュール44による予測およびスケジューリングのためにローカルに使用される。

【0060】

サーバ28はまた、追加の外部ソースからの情報をその決定に考慮することができる。外部情報は、例えば、デバイス24の位置、(ネットワーク側から受信された)ネットワーク構成に関する知識などを含むことができる。

【0061】

図2の構成の背後にある理論的根拠は、同じ領域に位置するデバイス24のグループが、同様のワイヤレス状態を経験し、かつ/または同じ基地局にキャンプし、したがって同様のネットワークパラメータを経験し得ることである。そのような場合、所与のデバイス24におけるエネルギ予測モデルおよびスケジューリング決定/アルゴリズムは、デバイスのグループから収集された情報に基づいて更新される場合、改善され得る。

【0062】

例示的な例として、サーバ28が、特定の時間(例えば、毎日正午前後)の間、特定の地理的エリアにおける高レベルの干渉を示す統計量を収集するシナリオを考える。そして、サーバは、この時間フレームでは通信しないようにこの領域内のデバイス24に通知し、代わりに夜間に通信することができる。あるいは、サーバは、このグローバルメタデータをエリア内のデバイス24にダウンロードすることができ、それによってデバイスがそれらのモデルを更新することを引き起こす。

【0063】

実際には、収集されたメタデータをデバイス24からサーバ28に生の収集されたメタデータで送信することは、かなりの量のエネルギを必要とし得る。従って、いくつかの実施形態では、デバイス24は、それをサーバに送る前に収集された情報をダウンサイジング(例えば、圧縮またはダイジェスト)するか、またはデータ上で部分的な前処理を行い、サーバによってさらなる処理のために使用され得る関連情報のみを送ることを可能にする。

【0064】

上記の説明では、デバイス24は、サーバ28を介して情報を共有することによって、それらのエネルギ予測モデルを改善する。他の実施形態では、デバイス24は、デバイス間通信を使用して、収集された情報を互いに直接共有することができる。

【0065】

種々の実施では、デバイス24にダウンロードされる1つ以上のモデルは、デバイス固有(すなわち、個々のデバイス24ごとに最適化される)、デバイスグループ固有(すなわち、デバイス24のグループに最適化される)、または汎用であり得る。ダウンロードされた情報(予測および/またはスケジューリングに関する)は、デバイス24上で動作するアルゴリズムと融合することができる。あるいは、ダウンロードされた情報は、サーバによって完全に定義される可能性がある。サーバ側におけるモデルまたはモデルの生成は、デバイス24によってアップロードされ、場合によっては前処理される情報に基づいて行われてもよい。

【0066】

収集された情報を、典型的には同様の条件を共有する近くのデバイスである複数のデバイス24間で共有することにより、各個々のデバイスは、そのエネルギ予測モデルおよびスケジューリング/決定アルゴリズムの性能を改善することができる。例えば、近くのデバイスは、リンク品質情報を共有することができ、それによって、各デバイスがより少ないノイズ予測を達成することを可能にする。別の例として、近くのデバイスは、スケジューリング決定の履歴に関する情報(例えば、過去のある時間にメッセージを送信するために必要とされたエネルギ量の統計)を共有することができ、デバイスがそれらの将来のスケジューリングポリシーを改善することを可能にする。
さらに別の例として、近くのデバイスは、それらの統計量を強化するために、それらのスケジューリングポリシーを同期させることができる。例えば、異なるデバイスが異なる時刻に送信する場合、ジョイント情報は、送信機会のジョイント全体ビューを提供する。

【0067】

種々の実施では、システム(例えば、サーバ28)は、情報共有のためにデバイスを基にどのように分割するかを決定するための様々な方式を使用することができる。一実施形態では、所与の基地局によって機能するデバイスは、近くにあると見なされ、したがって、情報共有およびモデル改善のために一緒にグループ化される。

【0068】

いくつかの実施形態では、サーバ28は、例えば、ネットワークのKPI(Key Performance Indicator)を改善するために、分析された情報をネットワーク事業者システム92と共有することができる。複数のデバイス24から収集されたメタデータの分析は、より良い結論がネットワーク事業者に送られることを導くことができる。例えば、いくつかのデバイス24についてセルラカバレッジが劣化するシナリオ、ネットワークパラメータの変化がデバイス24の性能に悪影響を及ぼすシナリオ(例えば、待ち時間、メッセージ成功率またはバッテリ寿命)、またはいくつかのデバイス24がネットワークによって(例えば、基地局によって)感知されない干渉を被るシナリオを考える。
これらのシナリオのいずれにおいても、サーバ28は、観測された性能の異常をネットワーク事業者システム92に報告することができる。サーバ28はまた、異常の可能性のある原因(例えば、可能性のある原因がワイヤレス状態の変化であるかどうか、スペクトルセンシングを使用して検知された干渉、またはネットワークパラメータの変化の識別)を示し得る。この種の識別情報および報告は、図2のシステム80に限定されず、図1のシステム20でも使用され得ることに留意されたい。

【0069】

ネットワークKPIを改善するために、任意のデバイス24は、(自律的に、またはサーバからの要求に応じて)無線スペクトルを感知し、リンク品質(例えば、干渉レベル)に関する情報を収集し、情報を処理し、処理された情報をサーバに送り得る。そのような処理された情報は、全体的な性能を改善するリンクパラメータ更新のための推薦を含むことができる。

【0070】

自律的に動作するとき、デバイスは、スペクトルを感知するためにいつウェイクアップすべきか、収集された情報をどのように処理すべきか、かつ/もしくは任意の他の適切なアクションまたは決定を実行すべきかを決定し得る。一例では、デバイス24が無線スペクトルの規則的な走査を実行する間、デバイスは、特定の周波数上の干渉を感知し、干渉を被る周波数のリストをサーバに送信し得る。

【0071】

図1および図2に示されるシステム、デバイス、およびサーバ構成は、単に概念を明確にするために選択される例示的な構成である。代替の実施形態では、任意の他の適切な構成を使用することができる。開示された技術の理解のために必須ではないシステム、デバイス、およびサーバ要素は、明確にするために図面から省略されている。

【0072】

システム20(図1)および80(図2)、デバイス24、およびサーバ28の様々な要素は、1つ以上のマイクロプロセッサ、特定用途向け集積回路(ASIC)、またはフィールドプログラマブルゲートアレイ(FPGA)などの適切なハードウェアを使用して実装され得る。いくつかの実施形態では、いくつかのシステム要素、例えば、ホストプロセッサ32、サーバ28、および/またはバッテリ寿命延長モジュール44の一部または全部は、ソフトウェアを使用して、またはハードウェア要素とソフトウェア要素との組合せを使用して実装され得る。

【0073】

いくつかの実施形態では、いくつかのシステム要素、例えば、ホストプロセッサ32、サーバ28、および/またはバッテリ寿命延長モジュール44のいくつかまたはすべては、本明細書で説明する機能を実行するようにソフトウェアでプログラムされる1つ以上のプログラマブルプロセッサで実装され得る。ソフトウェアは、例えば、ネットワークを介して、電子形式でプロセッサのいずれかにダウンロードされてもよく、あるいは、代替的または追加的に、磁性、光学、または電子メモリなどの非一時的有形媒体上に提供および/または記憶されてもよい。

【0074】

種々の実施では、デバイス24内(バッテリ寿命延長モジュール44の予測モジュール64内)および/またはサーバ28内で実行されるエネルギ予測モデルは、デバイスバッテリのモデルも含む。一部のバッテリでは、バッテリから消耗するエネルギ量は、メッセージの通信に費やすエネルギ量だけでなく、環境条件(温度や湿度など)や過去の使用パターンなどの要因によっても異なる。例えば、一部のバッテリでは、同じ量のエネルギを必要とする同じ送信タスクに対して、最近の過去において密な使用パターンにさらされた場合、バッテリはより厳しく消耗されることになる。
一部の実施形態では、メッセージの通信をスケジューリングするとき、エネルギ予測モデルは、バッテリモデルを使用して、メッセージの通信に続くバッテリの将来の状態(例えば、メッセージの通信に続くバッテリに残っている有効エネルギ容量)を予測する。バッテリモデルは、デバイス側、サーバ(クラウド)側、またはその両方で学習および/または更新することができる。

【0075】

種々の実施形態では、デバイス24(バッテリ寿命延長モジュール44の予測モジュール64内)および/またはサーバ28内で実行されるエネルギ予測モデルは、任意の適切なタイプのモデル、例えば適切なルールベースモデルまたは適切な機械学習(ML)モデルを含んでもよい。いくつかの実施形態では、すべてのデバイス24が同じ汎用モデルを使用する。他の実施形態では、各デバイスは、それ自体の専用モデル(予備汎用モデルから適合されていてもよい)を使用する。他の実施形態では、いくつかのモデルがデバイスのグループに割り当てられる。

【0076】

いくつかの実施形態では、モデルのトレーニングは、デバイスにおいて実行され、これは、各デバイスが、そのデバイスにおいてローカルに収集された情報に基づいて、そのそれぞれのモデルを更新することを意味する。他の実施形態では、モデルのトレーニングは、典型的には、複数デバイスによって収集され、デバイスにダウンロードされた情報に基づいて、サーバにおいて実行される。

【0077】

いくつかの実施形態では、モデルは、デバイスによって部分的にトレーニングされ、サーバによって部分的にトレーニングされる。例えば、デバイスは、モデルを開発かつ/または更新し、そのモデルをサーバに送ることができる。次に、サーバは、他のソースからの追加情報(例えば、他のデバイスからの)の融合によってモデルを更新し、次に、更新されたモデル(モデル全体またはモデルへの漸進的変化のみ)をデバイスにダウンロードする。そのようなハイブリッド構成は、トレーニング品質と通信(ひいてはエネルギ)オーバーヘッドとの間の良好なバランスを提供し得る。

【0078】

いくつかの実施形態では、エネルギ予測モデルは、デバイス24のグループごとに、例えば、コロケートされたデバイスのグループごとに別々に最適化され得る。そのような実施形態では、サーバは、複数のデバイスからの(および場合によっては他のソースからの)情報を集約して、所与の領域内のデバイスのための最適化されたスケジューリングプロファイルを生成することができる。例えば、夜間に干渉が低いと予想される領域では、サーバは、この領域内のデバイスに、昼間よりも夜間により頻繁に送信するように命令することができる。

【0079】

追加または代替として、モデルは、特定の顧客またはユーザアプリケーションのニーズ(例えば、メッセージ間の所要平均時間、順次メッセージ間の最小および/または最大許容時間など)に適合するように適合され得る。

【0080】

（使用例）
図3A~3Cは、本発明の一実施形態による、バッテリ寿命延長のためのメッセージ送信のスケジューリングを概略的に示すグラフである。この例は、消費エネルギを減らし、ひいてはデバイス24のバッテリ寿命を延ばすことにおける開示された技術の有効性を実証する。

【0081】

図3Aは、24時間の期間にわたる時間の関数として、所与のメッセージを送信するための特定の現実の静止IoTデバイス24において必要とされるエネルギを示す。見られるように、デバイスのエネルギ消費は、時間とともにかなり変化する。

【0082】

図3Bは、従来のIoTデバイスの動作を示す(開示された技術を用いたスケジューリングなし)。本例では、デバイスは、エネルギ消費を考慮することなく、規則的に離間されたインスタンス100でメッセージを送信する。見られるように、いくつかのインスタンス100は、必要とされるエネルギ消費が高いときに発生し、それによってデバイスのバッテリ寿命が短くなる。

【0083】

図3Cは、本発明の一実施形態による、メッセージの送信をスケジューリングするデバイス24の動作を示す。この実施形態では、デバイス24は、高エネルギインスタンスを回避し、代わりに、代替の低エネルギインスタンス104でメッセージを送信することができる。従って、全平均エネルギ消費はかなり低減され、バッテリ寿命は増加する。

【0084】

（例示的な方法の説明）
図4は、本発明の一実施形態による、バッテリ寿命延長のためのメッセージ送信をスケジューリングする一方法を概略的に示すフローチャートである。この方法は、デバイス24からサーバ28への送信のために保留されているメッセージで始まる。

【0085】

データ収集ステージ110で、デバイス24内のデータ収集モジュール60は、メッセージの送信をスケジュールするための関連情報を収集する。情報は、(i)モデム40から収集されたネットワーク関連情報、例えば、更新されたRSSI、SINRおよび/またはRSRP値の測定、ならびに、(ii)デバイス24のバッテリに関するバッテリ状態情報を含むことができる。

【0086】

モデル更新段階114において、デバイス24内の予測モジュール64は、新しく収集された情報を用いてエネルギ予測モデルを更新する。予測段階118において、予測モジュール64は、現在の送信(TX)機会においてメッセージを送信するために必要とされるであろうエネルギの量を推定するためにエネルギ予測モデルを使用する。

【0087】

閾値チェック段階122で、デバイス24内の決定モジュール68は、必要な量のエネルギを閾値と比較する。閾値は、固定されても、適応的(例えば、観測されるチャネル条件に応じて可変)であってもよい。固定閾値と適応閾値の両方を使用するハイブリッド解決も使用することができる。必要なエネルギ量が閾値を下回る場合、決定モジュール68は、現在のTX機会においてメッセージを送信することを決定し、送信段階126において、そのようにするようモデム40に指示する。必要なエネルギ量が閾値を超える場合、決定モジュール68は、現在のTX機会においてメッセージを送信しないことを決定し、方法は、上記のステージ110にループバックする。
上記で説明したように、決定モジュール68内のスケジューリングアルゴリズムの一部は、典型的には、次のTX機会のためにいつウェイクアップすべきかを決定する。

【0088】

図4の方法フローは、単に概念を明確にするために選択された例示的なフローである。代替の実施形態では、任意の他の適切な流れを使用することができる。

【0089】

（バッテリ有効容量予測を含むエネルギ予測方式の例）
図5は、本発明の一実施形態による、バッテリ有効容量予測を含むエネルギ予測方式を概略的に示す図である。この方式は、例えば、図1のIoTデバイス24のバッテリ寿命延長モジュール44内にエネルギ予測モジュール64を実装するために使用することができる。図5のスキームは、バッテリ26の通常の使用、すなわち、バッテリのピーク定格電流より多くの電流を引き込まない使用パターンに最も適している。下の図6は、代替スキームを示しており、バッテリの複雑なモデルを使用し、バッテリーピーク定格電流をかなり超える使用パターンに最も適している。

【0090】

図5のスキームでは、アクティビティプロファイル予測モジュール142は、所与のメッセージをサーバ側に接続して送信しようと試みている間に、IoTデバイス24が各モードで費やすアクティブ時間を推定する。モジュール142は、以下に基づいてアクティブ時間を推定する。
■ 無線状態測定150。例えば、デバイス24の現在および/または過去のウェイクアップ中に収集されるRSRP、SINR、CQI、ドップラ、およびその他。
■ タイマ、アップリンクおよびダウンリンク繰り返し、不連続受信(DRX)構成などのネットワーク構成読取154。
■ メッセージ長、使用されるプロトコルなどのアプリケーションパラメータ158。

【0091】

種々の実施形態では、ワイヤレス状態測定値150およびネットワーク構成読取値154は、モデム40の過去のウェイクアップに基づいて、ならびに/またはワイヤレス状態およびネットワーク状態についてのより信頼できる入力を取得するためにメッセージを送信しようとする試みの直前にスケジュールされた現在のウェイクアップに基づいて収集され得る。これらの入力は、アプリケーションパラメータ158と一緒に融合されて、メッセージが今送信される場合にモデムが経験するアクティビティプロファイルを予測する。

【0092】

一例では、所与のメッセージを送信する際に、モデム40は次の一連のモードを経る。

【表1】

【0093】

上記の情報は、例えば、モデム40内の適切なタイマまたはカウンタを使用して収集することができる。アクティビティプロファイル予測モジュール142は、そのような活動プロファイルを出力として提供することができる。テーブルはまた、単一のエントリ(例えば、T3+T6の合計持続時間を有する「受信」モードのための単一のエントリ、およびT5+T8の合計持続時間を有する「送信@0dBm」モードのための単一のエントリ)によって各モードを表すように折り畳まれ得る。

【0094】

デバイス/モデム電力推定モジュール146は、各電力状態において、デバイス24(またはモデム40のみ)の予想される電力消費を推定する。モジュール146は、以下の入力を融合することによってこの推定を実行する。
■ デバイス/モデム仕様162。例えば、デバイスの電力管理方式、ネットワーク構成(例えば、モデムが動作する周波数)、および/または（例えば、低RSRP RF電力においてより高くなり得る)無線状態。
■ 温度の読み取り166(アクティブ/スリープ中の電力消費に直接影響する)および場合によっては他の周囲条件。
■ 燃料計170 - デバイスの消費電流の測定値。デバイス内の適切な回路によって測定される。

【0095】

上記の例に従うと、モジュール146の出力は、以下のような各モードにおけるデバイスまたはモデムの電力レベルを与えるリストまたはテーブルである。

【表2】

【0096】

モジュール142および146の出力は、メッセージエネルギ予測モジュール134およびバッテリ有効容量予測モジュール138を含むエネルギ予測モデル130に供給される。

【0097】

モジュール134は、現在のTX機会においてメッセージを送信するために必要とされるであろうエネルギを予測する。一実施形態において、モジュール134は、各モードで費やされた総持続時間(秒)にそのモードの消費電力(mW)を乗算し、メッセージを送信するために必要な総エネルギ(mWs)を得る。上記の事例に従うと、トータルのメッセージエネルギはP1・T1+P2・(T3+T6)+P3・T2+R4・(T5+T8)+P5・T4+P6・T7によって与えられる。

【0098】

予測されたメッセージエネルギは、バッテリ有効容量予測モジュール138に供給され、このモジュールは、メッセージが送信されたと仮定して残りのバッテリ容量を推定する。予測メッセージエネルギに加えて、モジュール138は、以下を考慮に入れることができる。
■ 消費電流測定値(燃料計170)。
■ バッテリ仕様174。例えば、バッテリ状態の以前の測定値(例えば、バッテリ内部抵抗および/または電圧レベルの測定値、および/または履歴使用に基づく計算値)。
■ 温度の読み取り178。

【0099】

上記の要因に基づいて、モジュール138は、メッセージが現在のTX機会に送信されると仮定して、バッテリ残量を推定する。1つの単純な実装では、バッテリ容量(mAh)は、総予測メッセージエネルギ(モジュール134の出力、またmAh)によって低減される。

【0100】

図5の実施形態において、バッテリ残容量(モジュール138の出力、および全体としてのモジュール130の出力)は、予測されたバッテリ状態182を更新するために使用される。決定モジュール194は、予測されたバッテリ状態182を、以前のバッテリ状態186およびアプリケーションパラメータ190と組み合わせて使用して、メッセージを現在のTX機会に送信するか、または決定を後のTX機会に延期するかを決定する。

【0101】

送信決定である場合、決定モジュール194はモデム40にメッセージを送信するよう指示する。モジュール194は、エネルギ予測モデル130および/またはその様々な入力および構成要件(例えば、アクティビティプロファイルおよびデバイス/モデム電力消費)を更新し得る。送信を延期することを決定する場合、モジュール194は、モデム40に対して、指定された期間(スケジューリングアルゴリズムによって決定される)スリープモードに移行するように指示する。いずれの場合も、モジュール194はバッテリ状態を更新することができる。

【0102】

図6は、本発明の別の実施形態による、バッテリ有効容量予測を含む代替エネルギ予測方式を概略的に示す図である。この方式も、図1のIoTデバイス24のバッテリ寿命延長モジュール44内にエネルギ予測モジュール64を実装するために使用することができる。図6のスキームは、バッテリのピーク定格電流をかなり超える使用パターンに最も適している。

【0103】

上述したように、過剰な電流がバッテリから引き出されると、バッテリ容量は、比較的高電力消費の動作の長期間にわたって、より厳しく劣化する。したがって、平均電力消費による合計アクティブ時間の単純な乗算は、メッセージ送信に続く予想される容量の良好な指標を提供しないことがある。代わりに、電力消費バーストに関する情報を含む、アクティビティプロファイルに関するいくつかの低レベル情報が必要とされる。有効なバッテリ容量を予測するための他の有用な情報は、バッテリ寿命に沿った過去の使用状況および環境条件(例えば、温度、湿度、空気圧など)を含んでもよい。

【0104】

図6の実施形態は、バッテリ有効容量予測モジュール200と、メッセージエネルギ予測モジュール204と、決定モジュール208(スケジューリングモジュールとも呼ばれる)とを備える。

【0105】

上記で詳細に説明したように、メッセージエネルギ予測モジュール204は、ネットワークおよびチャネル条件232ならびにアプリケーションデータ236に基づいて、デバイス24の予測アクティビティプロファイル228を維持する。予測アクティビティプロファイル228の例は、図の上部に見られる。この例では、プロファイルは、モデム40の動作モード、従って、電流消費において異なる、1から7までの番号が付されたサーバ期間で構成される。期間4は、例えば、非常に低い電流消費を特徴とするスリープ期間である。この期間は、過度の電流引き込みのバーストからバッテリを回復させるのにも役立つ。

【0106】

バッテリ有効容量予測モジュール200は、バッテリのアルゴリズムモデルによって定義されるバッテリ状態パラメータ値を含むバッテリ状態212を維持する。バッテリ状態予測器216は、特定の使用状況および条件が与えられたとき、デバイスのバッテリの予期状態を予測するためにバッテリ状態パラメータ値を使用する。一例では、予測は、温度測定224に依存する。特に、バッテリ状態を予測することは、バッテリ有効残容量を予測することを含む。状態更新モジュール220は、予測器216の予測に基づいてバッテリ状態212を更新する。

【0107】

決定モジュール208は、バッテリ有効容量予測モジュール200にクエリを送信し、モジュール200に、可能な様々なアクティビティがバッテリ状態に及ぼす影響を評価するように要求する。評価されるアクティビティは、例えば、メッセージを送信するためのウェイクアップ、アルゴリズムを改善するための専用ウェイクアップ、またはスリープ期間であり得る。所与のアクティビティに対するクエリは、(i)潜在的な活動プロファイル、および(ii)そのアクティビティに対する期待されるエネルギ消費を指定する。モジュール200は、典型的には、バッテリ有効容量に対する予想される変化でクエリに応答する。この応答を受信した後、決定モジュール208は、通常、アクションをとり、モジュール200内の更新モジュール220に、バッテリ状態212を更新するように指示する。

【0108】

図5および図6のエネルギ予測方式は、明確にするために純粋に選択された例示的な方式である。代替の実施形態では、任意の他の適切なスキームを使用することができる。上述のように、開示された方式はまた、バッテリ26またはデバイス24の他の場所で起こり得る故障を識別し、それに応じてサーバ28に報告することができる。サーバは、次に、この誤動作をユーザアプリケーションに報告することができる。故障は、例えば、実際のバッテリモデル状態と予想されるバッテリモデル状態との間の大きな偏差を識別することによって検出することができる。

【0109】

さらに、デバイス24毎に記憶された、アクティビティプロフィールおよび/またはバッテリ状態ならびにバッテリモデルに関する収集された前処理済みデータを、サーバ28にアップロードすることができる。このデータは、現場に配備された複数デバイス24からバッテリ特性に関する貴重な情報を収集することを可能にする。この情報は、バッテリの設計を改善することによって、および/またはデバイスの特定の使用およびアクティビティプロファイルのためのバッテリを設計することによって、バッテリの性能を改善するために使用することができる。

【0110】

種々の実施では、システム内の(例えば、デバイス24内の、サーバ28内の、または両方の)プロセッサは、オンザフライでエネルギ予測モデル(バッテリ状態モデルおよびスケジューリングモデルを含む)を更新する。更新は、メッセージの送信前、送信中、および/または送信後に取られた測定値に基づくものであり得る。

【0111】

本明細書で説明する実施形態は主にIoTデバイスなどの無線デバイスに対処するが、本明細書で説明する方法およびシステムは、(i)バッテリによって電力供給される、(ii)困難なエネルギ制約を受ける、および(ii)自律的にそれらのアクティビティプロファイルを維持することができる、様々な他の電子機器などの他の用途で使用することもできる。

【0112】

したがって、上記の実施形態は、例として引用されており、本発明は、上記で特に示され、記載されたものに限定されないことが理解される。むしろ、本発明の範囲は、上述の様々な特徴の組み合わせおよびサブコンビネーションの両方、ならびに、前述の説明を読んだときに当業者に想起されるであろう、先行技術に開示されていない、その変形および修正を含む。参照により本特許出願に組み込まれる明細書は、本明細書において明示的または暗示的に行われる定義と矛盾する方法で、これらの組み込まれる明細書において任意の用語が定義される範囲において、本明細書における定義のみが考慮されるべきであることを除いて、本出願の不可欠な部分とみなされるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】