JP2019036841A - 配信制御方法および通信システム - Google Patents

配信制御方法および通信システム Download PDF

Info

Publication number
JP2019036841A
JP2019036841A JP2017156855A JP2017156855A JP2019036841A JP 2019036841 A JP2019036841 A JP 2019036841A JP 2017156855 A JP2017156855 A JP 2017156855A JP 2017156855 A JP2017156855 A JP 2017156855A JP 2019036841 A JP2019036841 A JP 2019036841A
Authority
JP
Japan
Prior art keywords
frame
update
slave
gateway
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017156855A
Other languages
English (en)
Inventor
富由太 佐藤
Fuyuta Sato
富由太 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2017156855A priority Critical patent/JP2019036841A/ja
Priority to US16/058,182 priority patent/US10445087B2/en
Publication of JP2019036841A publication Critical patent/JP2019036841A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/654Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H04W84/20Master-slave selection or change arrangements
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

【課題】運用に支障を与えることなく更新用フレームの配信を実行する。【解決手段】通信システム1は、マスタノード1aとスレーブノード1bを備える。マスタノード1aは、スレーブノード1bにフレームを送信した場合のフレーム到達可否状態を検出し、フレーム到達可否状態と、フレームの送信数とにもとづいて、フレーム配信方法の候補を生成して候補をスレーブノードへ送信し、スレーブノードから送信された更新可否情報にもとづいて、候補の中からフレーム配信方法を選択するマスタ側処理を行う。スレーブノード1bは、選択されたフレーム配信方法で配信されたフレームによる内部動作の更新可否を判定して更新可否情報を生成して送信するスレーブ側処理を行う。【選択図】図1

Description

本発明は、配信制御方法および通信システムに関する。
近年、通信機能を備えたセンサ機器を遠隔で監視・制御し、センサ機器で測定されたデータをサーバが収集して活用するIoT(Internet of Things)サービスが普及拡大している。
IoTサービスの代表的なものにスマートグリッドがある。スマートグリッドは、各地点に配置されたスマートメータが地点毎の電気使用量を測定し、スマートメータから送信された電気使用量をサーバが収集することで、電力消費を一元管理するシステムである。
一方、センサ機器の保守では、センサ機器を動作させるためのファームウェア(またはソフトウェア)の更新が行われる。この場合、サーバからセンサ機器にファームウェアが送信され、ファームウェアを受信したセンサ機器によって個々にファームウェアの更新が行われる。
国際公開第2011/121671号 特開2008−306314号公報
センサ機器のファームウェア更新では、ファームウェアのデータを分割してフレームを生成し、フレームをフラッディング(flooding)制御により転送している。フラッディング制御は、フレームを受信したセンサ機器が同じフレームを1回送信することで、フレーム中継転送を行うもので、これにより、センサ機器に対するフレームの受信率を上げることができる。しかし、従来のフラッディング制御では、無線通信量が増えるため、無線干渉が増大し、センサ機器の通常の運用に支障を与える。
1つの側面では、本発明は、運用に支障を与えることなく、更新用フレームの配信を可能にした配信制御方法および通信システムを提供することを目的とする。
上記課題を解決するために、配信制御方法が提供される。配信制御方法は、マスタノード内のマスタコンピュータが、スレーブノードにフレームを送信した場合のフレーム到達可否状態を検出し、フレーム到達可否状態と、フレームの送信数とにもとづいて、フレーム配信方法の候補を生成して候補をスレーブノードへ送信し、スレーブノードから送信された更新可否情報にもとづいて、候補の中からフレーム配信方法を選択するマスタ側処理を行う。また、スレーブノード内のスレーブコンピュータが、選択されたフレーム配信方法で配信されたフレームによる内部動作の更新可否を判定して更新可否情報を生成して送信するスレーブ側処理を行う。
また、上記課題を解決するために、上記配信制御方法を実行する通信システムが提供される。
1側面によれば、運用に支障を与えることなく、更新用フレームの配信が可能になる。
配信制御方法の動作の一例を示す図である。 フラッディング制御によるファームウェア更新を説明するための図である。 通信システムの構成の一例を示す図である。 ゲートウェイのハードウェア構成の一例を示す図である。 ゲートウェイの機能ブロックの一例を示す図である。 センサノードの機能ブロックの一例を示す図である。 通信システムの動作シーケンスの一例を示す図である。 無線動作レベルの一例を示す図である。 保守モードフレームのフォーマットの一例を示す図である。 到達性検出の動作シーケンスの一例を示す図である。 到達性検出の動作シーケンスの一例を示す図である。 到達性情報テーブルの登録例を示す図である。 要求事項情報の一例を示す図である。 管理装置の動作を示すフローチャートである。 マスタ側リソース情報テーブルの一例を示す図である。 配信方法候補の一例を示す図である。 配信方法候補の生成動作を示すフローチャートである。 更新可否問合せ要求のフォーマットの一例を示す図である。 スレーブ側リソース情報テーブルの一例を示す図である。 更新可否問合せ応答の一例を示す図である。 更新可否問合せ応答テーブルの一例を示す図である。 ゲートウェイからのブロードキャスト範囲を示す図である。 更新可否問合せ応答テーブルの一例を示す図である。 更新効果値にもとづく配信方法の選択動作を示す図である。
以下、本実施の形態について図面を参照して説明する。
[第1の実施の形態]
第1の実施の形態について図1を用いて説明する。図1は配信制御方法の動作の一例を示す図である。配信制御方法は、通信システム1によって実行され、通信システム1は、マスタノード1aと、スレーブノード1bとを含む。マスタノード1aとスレーブノード1bは無線通信を行う。
〔ステップS1〕マスタノード1aは、スレーブノード1bにフレームを送信した場合のフレーム到達可否状態を検出する。
〔ステップS2〕マスタノード1aは、フレーム到達可否状態と、フレームの送信数とにもとづいて、フレーム配信方法の候補を生成する。
〔ステップS3〕マスタノード1aは、配信方法候補をスレーブノード1bへ送信する。
〔ステップS4〕スレーブノード1bは、配信方法候補で配信されたフレームによって、スレーブノード1bの内部動作の更新が可能か否かを判定し、更新可否情報を生成する。
〔ステップS5〕スレーブノード1bは、更新可否情報を送信する。
〔ステップS6〕マスタノード1aは、スレーブノード1bから送信された更新可否情報にもとづいて、配信方法候補の中からフレーム配信方法を選択し、選択したフレーム配信方法でフレーム配信を実行する。
〔ステップS7〕スレーブノード1bは、選択されたフレーム配信方法で配信されたフレームを受信して内部動作の更新を行う。
このように、通信システム1では、スレーブノード1bの内部動作の更新時、マスタノード1aからスレーブノード1bへのフレーム到達性と、フレーム送信数とにもとづき、フレーム配信方法の候補を作成する。そして、通信システム1は、スレーブノード1bが更新可能なフレーム配信方法を該候補から選択する。
このような通信システム1の配信制御方法でフレーム配信が行われることにより、マスタノード1aは、運用に支障なく更新用フレームをスレーブノード1bに配信することが可能になる。
[第2の実施の形態]
次に第2の実施の形態について説明する。第2の実施の形態は、LPWAN(Low Power Wide Area Network)のLoRa(Long Range)の通信機能を有するノードに本発明の機能を適用したものである。
LPWANは、携帯電話機回線や無線LAN(Local Area Network)等の無線通信と比べて少ない消費電力で長距離(最大20km程度)の無線通信を可能とする。LPWANによるデータ通信が行われることで、電力消費量を抑えたネットワークの構築が可能になる。また、LoRaは、米国のLoRaAllianceが推進するLPWANの通信規格であり、上り下りの双方向通信が可能である。LoRaは、低消費電力のため電池駆動型のノードに適しており、リピータ等の中継器を用いずに長距離無線通信を行う等の特徴を有している。
最初に、フラッディング制御によるファームウェア更新の課題について図2を用いて説明する。図2はフラッディング制御によるファームウェア更新を説明するための図である。通信ネットワーク3は、センサノードsn1、・・・、sn15(総称する場合はセンサノードsn)およびゲートウェイGW0を備える。なお、図2中の点線円は、各センサノードの通信エリアを示し、太実線円は、ゲートウェイGW0の通信エリアを示す。
センサノードsn1、・・・、sn15に対するファームウェアの更新時、ゲートウェイGW0から更新すべきファームウェアが配信される。ファームウェアサイズは、一般に数百byteから数Mbyteあるため、1フレーム(例えば、無線LANでは約1400byte)だけに収容することは困難である。このため、複数のフレーム(例えば、数千のフレーム)に分割して配信が行われる。
また、フラッディング制御では、ゲートウェイGW0によって分割されたフレームがブロードキャストフレームとして送信され、フレームを受信したセンサノードsnは、受信した同じフレームを1回だけ送信するという動作が行われる。
このような動作では、センサノードsnが、あるフレームをフレームロス等により受信できなくても、センサノードsnには受信機会が他にもあるため、受信到達確率が向上する。例えば、図2の場合、センサノードsn13がセンサノードsn9から送信されたフレームを受信できなかったとしても、近隣のセンサノードsn8やセンサノードsn15等からフレームを受信する機会がある。
一方、このようなマルチホップのフラッディング制御では、フレームの1回の送信に対して、(受信したセンサノード数)×(フレームサイズ)のデータ量が無線ネットワーク上に現れる。例えば、図2の例では、センサノードsnのブロードキャスト数は、15フレーム/1送信回数となる。
このため、フレームの送信回数、およびフレームを受信するセンサノード数が多くなるにつれて、ブロードキャストフレーム数が増え、無線干渉やフレームロスが生じて、フレーム受信を失敗する可能性が増加する。
また、無線ネットワーク上に大量のデータが長時間存在する状況(ブロードキャストストーム)になると、無線干渉によるフレームロスがさらに多発し、長時間運用ができなくなるため、人手でのファームウェア更新作業が余儀なくされる。
さらに、センサノードsnの駆動は、給電式から環境発電型等の電池式が多く使用されてきているので、ブロードキャスト数(送受信回数)の増加は、無線干渉やフレームロスだけでなく、センサノードsnの電力を消費させて寿命低下の要因にもなる。
本発明はこのような点に鑑み、運用に支障を与えることなく、またセンサノードの電力消費量を低減させて、ファームウェア更新のためのフレーム配信を行う配信制御方法および通信システムを提供するものである。
以下、第2の実施の形態について詳しく説明する。図3は通信システムの構成の一例を示す図である。第2の実施の形態の通信システム1−1は、ゲートウェイ10と、複数のセンサノード20−1、・・・、20−n(総称する場合はセンサノード20)とを備える。
ゲートウェイ10は、図1に示したマスタノード1aの機能を有し、センサノード20−1、・・・、20−nは、図1に示したスレーブノード1bの機能を有する。また、管理装置30がゲートウェイ10に接続される。管理装置30の動作については図14で後述する。
<ハードウェア構成>
図4はゲートウェイのハードウェア構成の一例を示す図である。ゲートウェイ10は、プロセッサ100によって装置全体が制御されている。すなわち、プロセッサ100は、ゲートウェイ10の制御部として機能する。
プロセッサ100には、バス103を介して、メモリ101および複数の周辺機器が接続されている。プロセッサ100は、マルチプロセッサであってもよい。プロセッサ100は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、DSP(Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、またはPLD(Programmable Logic Device)である。またプロセッサ100は、CPU、MPU、DSP、ASIC、PLDのうちの2以上の要素の組み合わせであってもよい。
メモリ101は、ゲートウェイ10の主記憶装置として使用される。メモリ101には、プロセッサ100に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ101には、プロセッサ100による処理に要する各種データが格納される。
また、メモリ101は、ゲートウェイ10の補助記憶装置としても使用され、OSのプログラム、アプリケーションプログラム、および各種データが格納される。メモリ101は、補助記憶装置として、フラッシュメモリやSSD(Solid State Drive)等の半導体記憶装置やHDD(Hard Disk Drive)等の磁気記録媒体を含んでもよい。
バス103に接続されている周辺機器としては、入出力インタフェース102およびネットワークインタフェース104がある。入出力インタフェース102は、プロセッサ100からの命令にしたがってゲートウェイ10の状態を表示する表示装置として機能するモニタ(例えば、LED(Light Emitting Diode)やLCD(Liquid Crystal Display)等)が接続されている。
また、入出力インタフェース102は、キーボードやマウス等の情報入力装置を接続可能であって、情報入力装置から送られてくる信号をプロセッサ100に送信する。
さらにまた、入出力インタフェース102は、周辺機器を接続するための通信インタフェースとしても機能する。例えば、入出力インタフェース102は、レーザ光等を利用して、光ディスクに記録されたデータの読み取りを行う光学ドライブ装置を接続することができる。光ディスクは、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM(Random Access Memory)、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(Rewritable)等がある。
また、入出力インタフェース102は、メモリ装置やメモリリーダライタを接続することができる。メモリ装置は、入出力インタフェース102との通信機能を搭載した記録媒体である。メモリリーダライタは、メモリカードへのデータの書き込み、またはメモリカードからのデータの読み出しを行う装置である。メモリカードは、カード型の記録媒体である。
ネットワークインタフェース104は、ネットワークとのインタフェース制御を行い、例えば、NIC(Network Interface Card)、無線LANカード等が使用できる。ネットワークインタフェース104で受信されたデータは、メモリ101やプロセッサ100に出力される。
以上のようなハードウェア構成によって、ゲートウェイ10の処理機能を実現することができる。例えば、ゲートウェイ10は、プロセッサ100がそれぞれ所定のプログラムを実行することで本発明の制御を行うことができる。
ゲートウェイ10は、例えば、コンピュータで読み取り可能な記録媒体に記録されたプログラムを実行することにより、本発明の処理機能を実現する。ゲートウェイ10に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。
例えば、ゲートウェイ10に実行させるプログラムを補助記憶装置に格納しておくことができる。プロセッサ100は、補助記憶装置内のプログラムの少なくとも一部を主記憶装置にロードし、プログラムを実行する。
また、光ディスク、メモリ装置、メモリカード等の可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えば、プロセッサ100からの制御により、補助記憶装置にインストールされた後、実行可能となる。またプロセッサ100が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
なお、上記では、ゲートウェイ10のハードウェア構成について説明したが、センサノード20についても図4と同様のハードウェア構成が適用される。
<機能ブロック>
次にゲートウェイ10およびセンサノード20の機能ブロックについて図5、図6を用いて説明する。図5はゲートウェイの機能ブロックの一例を示す図である。ゲートウェイ10は、マスタ制御部10aとマスタ記憶部10bを備える。
マスタ制御部10aは、マスタ側到達性検出部11、ファームウェア受信処理部12、配信方法候補生成部13、更新可否問合せ部14、配信方法選択部15およびマスタ側通信部16を含む。マスタ記憶部10bは、マスタ側到達性情報テーブル17、マスタ側リソース情報テーブル18および更新可否問合せ応答テーブル19を含む。
マスタ側到達性検出部11は、ファームウェアを受信するセンサノード20に対して無線動作レベルを制御してフレームの到達性を検出する。そして、マスタ側到達性検出部11は、検出した到達性情報(ゲートウェイ10におけるフレーム到達可否状態の情報)をマスタ側到達性情報テーブル17に登録する。
ファームウェア受信処理部12は、管理装置30から送信されたファームウェアのファイルを受信し、ファームウェアサイズからフレーム送信数の算出等を行う。
配信方法候補生成部13は、到達性情報、フレーム送信数およびマスタ側リソース情報テーブル18に格納されるリソース情報の少なくとも1つにもとづいて、ファームウェア更新のためのフレーム配信方法の候補を生成する。
更新可否問合せ部14は、生成された配信方法候補でセンサノード20がファームウェアを更新可能か否かの問合せを行う。また、更新可否問合せ部14は、センサノード20から送信された更新可否問合せ応答の結果を更新可否問合せ応答テーブル19に登録する。
配信方法選択部15は、更新可否問合せ応答の結果にもとづいて、配信方法候補の中からフレーム配信方法を選択する。マスタ側通信部16は、ゲートウェイ10における通信インタフェース処理を行う。例えば、マスタ側通信部16は、選択された配信方法でファームウェアを配信し、また、選択した配信方法や配信状況を配信結果として管理装置30へ送信する。
なお、マスタ側到達性情報テーブル17の登録内容については図12で、マスタ側リソース情報テーブル18の登録内容については図15で、更新可否問合せ応答テーブル19の登録内容については図21で後述する。
図6はセンサノードの機能ブロックの一例を示す図である。センサノード20は、スレーブ制御部20aおよびスレーブ記憶部20bを備える。スレーブ制御部20aは、スレーブ側到達性検出部21、更新可否判定応答部22およびスレーブ側通信部23を含む。スレーブ記憶部20bは、スレーブ側到達性情報テーブル24およびスレーブ側リソース情報テーブル25を含む。
スレーブ側到達性検出部21は、無線動作レベル毎のフレームの到達性を検出し、検出した到達性情報(センサノード20におけるフレーム到達可否状態の情報)をスレーブ側到達性情報テーブル24に登録する。
更新可否判定応答部22は、到達性情報およびスレーブ側リソース情報テーブル25に格納されるリソース情報の少なくとも1つにもとづいて、ゲートウェイ10から送信された配信方法候補で、内部動作を制御するファームウェアの更新が可能か否かを判定する。スレーブ側通信部23は、センサノード20における通信インタフェース処理を行う。例えば、スレーブ側通信部23は、更新可否判定結果の送信処理や、配信されたフレームの受信処理を行う。
なお、スレーブ側到達性情報テーブル24の登録内容については図12で、スレーブ側リソース情報テーブル25の登録内容については図19で後述する。
ここで、図5のマスタ制御部10aおよび図6のスレーブ制御部20aは、図4に示したプロセッサ100で実現される。また、図5のマスタ記憶部10bおよび図6のスレーブ記憶部20bは、図4に示したメモリ101で実現される。または各構成部を論理回路等によってハードウェア回路で構成することもできる。
<通信システムの動作シーケンス>
図7は通信システムの動作シーケンスの一例を示す図である。通信システム1−1における全体動作のシーケンスを示している。
〔ステップS11〕ゲートウェイ10は、通常運用時、定期的にセンサノード20にアクセスして、無線動作レベル毎の到達性情報を収集する。
〔ステップS12〕ゲートウェイ10は、収集した到達性情報にもとづいて、センサノード20の到達可否を判定する。
〔ステップS13〕管理装置30は、ファームウェアを送信し、ゲートウェイ10で受信される。
〔ステップS14〕管理装置30は、要求事項情報をゲートウェイ10に送信する。
〔ステップS15〕ゲートウェイ10は、ファームウェアのサイズから算出されたフレーム送信数と、収集した各無線動作レベルの到達性情報とにもとづいて、配信にかかる消費リソースを予測し、要求事項情報に応じた、フレーム配信方法の候補を複数生成する。
〔ステップS16a〕ゲートウェイ10は、生成した配信方法候補でセンサノード20に更新可否の問合せを行う。
〔ステップS16b〕センサノード20は、電池残量を含めた予測消費電力量にもとづいて、更新可否の判定をして(ファームウェアを受信可能か否かの判定をして)、判定結果を応答する。この場合、センサノード20は、すべてのフレームを受信できない場合は、受信可能となるための条件を付与して応答を返す(後述)。
〔ステップS17〕ゲートウェイ10は、更新可否判定結果にもとづいて、フレーム配信方法を配信方法候補の中から選択する。
〔ステップS18〕ゲートウェイ10は、選択した配信方法で、フレームをセンサノード20に配信する。
〔ステップS19〕ゲートウェイ10は、選択した配信方法や配信状況を配信結果として管理装置30へ送信する。
<到達性検出>
次に到達性検出の動作について図8から図12を用いて説明する。図8は無線動作レベルの一例を示す図である。ゲートウェイ10およびセンサノード20は、テーブルT1に示すような例えば、3段階の無線動作レベル(LoRa無線動作レベル)を有するとする。ゲートウェイ10およびセンサノード20は、無線動作レベルに応じた強度の電波を発出する。
例えば、無線動作レベルNを基準動作レベルとすると、無線動作レベルN+1で動作する場合は、無線動作レベルNよりも通信範囲(到達範囲)を広くでき、無線動作レベルN−1で動作する場合は、無線動作レベルNよりも通信範囲が狭くなる。
図9は保守モードフレームのフォーマットの一例を示す図である。ゲートウェイ10は、到達性検出を行う場合、通常運用時において、保守モードフレームf0をセンサノード20へ定期的に送信して、センサノード20との通信を保守モードにする。
保守モードフレームf0は、切替え時間、期間、開始レベルおよび終了レベルが設定される。切替え時間は、保守モードフレームf0がセンサノード20で受信されてから無線動作レベルが切替わるまでの時間を示す。
期間は、切替え後の無線動作レベルで動作する期間を示す。開始レベルは、切替え開始時の無線動作レベルを示す。終了レベルは、切替え終了時の無線動作レベルを示す。
例えば、切替え時間=60sec、期間=30sec、開始レベル=N+1、終了レベル=N−1と設定された保守モードフレームf0をセンサノード20が受信したとする。この場合、センサノード20は、保守モードフレームf0を受信してから60秒後に無線動作レベルを開始レベルのN+1に切替える。そして、センサノード20は、N+1に切替えてから30秒経過すると無線動作レベルをNに切替え、さらにNに切替えてから30秒経過すると無線動作レベルを終了レベルのN−1に切替える。
図10、図11は到達性検出の動作シーケンスの一例を示す図である。ゲートウェイ10およびセンサノード20−1、20−2、20−3で到達性検出が行われるとする。また、無線動作レベルは、N+1、N、N−1の順に切替えられるとする。
(保守モードフレーム送受信)
〔ステップS20a〕ゲートウェイ10は、保守モードフレームf0をブロードキャストで送信する。
〔ステップS20b−1、S20b−2、S20−3〕保守モードフレームf0を受信したセンサノード20−1、20−2、20−3は、保守モードフレームf0の設定内容を認識する。そして、センサノード20−1、20−2、20−3は、保守モードフレームf0に設定されている切替え時間に無線動作レベルを切替える。
(無線動作レベルN+1における到達性検出)
〔ステップS30a〕ゲートウェイ10は、LoRAによる無線動作レベルで制御した要求信号を送信する。例えば、無線動作レベルN+1で1ホップ以内におけるブロードキャストの到達確認要求を行う。この場合、ゲートウェイ10は、ゲートウェイ10の識別子(識別子GWとする)を要求信号として、無線動作レベルN+1で1ホップ以内におけるブロードキャストで送信する。
〔ステップS30b−1、S30b−2、S30b−3〕センサノード20−1、20−2、20−3は、識別子GWを受信し、各自のスレーブ側到達性情報テーブル24に識別子GWを登録する。
〔ステップS31a〕センサノード20−1は、到達確認応答として、センサノード20−1の識別子(識別子n1とする)を応答信号として送信する。この場合、センサノード20−1は、無線動作レベルN+1で1ホップ以内におけるブロードキャストで識別子n1を送信する。
〔ステップS31b〕ゲートウェイ10は、識別子n1を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS31c−2、S31c−3〕センサノード20−2、20−3は、識別子n1を受信し、各自のスレーブ側到達性情報テーブル24に識別子n1を登録する。
〔ステップS32a〕センサノード20−2は、到達確認応答として、センサノード20−2の識別子(識別子n2とする)を送信する。この場合、センサノード20−2は、無線動作レベルN+1で1ホップ以内におけるブロードキャストで識別子n2を送信する。
〔ステップS32b〕ゲートウェイ10は、識別子n2を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS32c−1、S32c−3〕センサノード20−1、20−3は、識別子n2を受信し、各自のスレーブ側到達性情報テーブル24に識別子n2を登録する。
〔ステップS33a〕センサノード20−3は、到達確認応答として、センサノード20−3の識別子(識別子n3とする)を送信する。この場合、センサノード20−3は、無線動作レベルN+1で1ホップ以内におけるブロードキャストで識別子n3を送信する。
〔ステップS33b〕ゲートウェイ10は、識別子n3を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS33c−1、S33c−2〕センサノード20−1、20−2は、識別子n3を受信し、各自のスレーブ側到達性情報テーブル24に識別子n3を登録する。
(無線動作レベルNにおける到達性検出)
〔ステップS40a〕ゲートウェイ10は、無線動作レベルNで2ホップ以内におけるブロードキャストの到達確認要求を行う。この場合、ゲートウェイ10は、識別子GWを無線動作レベルNで2ホップ以内におけるブロードキャストで送信する。
〔ステップS40b−1、S40b−2〕センサノード20−1、20−2は、識別子GWを受信し、各自のスレーブ側到達性情報テーブル24に識別子GWを登録する。
〔ステップS40c〕センサノード20−3は、識別子GWを受信できないとする。
〔ステップS41a〕センサノード20−1は、到達確認応答として、識別子n1を無線動作レベルNで2ホップ以内におけるブロードキャストで送信する。
〔ステップS41b〕ゲートウェイ10は、識別子n1を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS41c−2、S41c−3〕センサノード20−2、20−3は、識別子n1を受信し、各自のスレーブ側到達性情報テーブル24に識別子n1を登録する。
〔ステップS42a〕センサノード20−2は、到達確認応答として、識別子n2を無線動作レベルNで2ホップ以内におけるブロードキャストで送信する。
〔ステップS42b〕ゲートウェイ10は、識別子n2を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS42c−1、S42c−3〕センサノード20−1、20−3は、識別子n2を受信し、各自のスレーブ側到達性情報テーブル24に識別子n2を登録する。
〔ステップS43a〕センサノード20−3は、到達確認応答として、識別子n3を無線動作レベルNで2ホップ以内におけるブロードキャストで送信する。
〔ステップS43b〕ゲートウェイ10は、識別子n3を受信できないとする。
〔ステップS43c−1、S43c−2〕センサノード20−1、20−2は、識別子n3を受信し、各自のスレーブ側到達性情報テーブル24に識別子n3を登録する。
(無線動作レベルN−1における到達性検出)
〔ステップS50a〕ゲートウェイ10は、無線動作レベルN−1で3ホップ以内におけるブロードキャストの到達確認要求を行う。この場合、ゲートウェイ10は、識別子GWを無線動作レベルN−1で3ホップ以内におけるブロードキャストで送信する。
〔ステップS50b〕センサノード20−1は、識別子GWを受信し、スレーブ側到達性情報テーブル24に識別子GWを登録する。
〔ステップS50c〕センサノード20−2、20−3は、識別子GWを受信できないとする。
〔ステップS51a〕センサノード20−1は、到達確認応答として、識別子n1を無線動作レベルN−1で3ホップ以内におけるブロードキャストで送信する。
〔ステップS51b〕ゲートウェイ10は、識別子n1を受信し、マスタ側到達性情報テーブル17に登録する。
〔ステップS51c〕センサノード20−2は、識別子n1を受信し、スレーブ側到達性情報テーブル24に識別子n1を登録する。
〔ステップS51d〕センサノード20−3は、識別子n1を受信できないとする。
〔ステップS52a〕センサノード20−2は、到達確認応答として、識別子n2を無線動作レベルN−1で3ホップ以内におけるブロードキャストで送信する。
〔ステップS52b〕ゲートウェイ10は、識別子n2を受信できないとする。
〔ステップS52c−1、S52c−3〕センサノード20−1、20−3は、識別子n2を受信し、各自のスレーブ側到達性情報テーブル24に識別子n2を登録する。
〔ステップS53a〕センサノード20−3は、到達確認応答として、識別子n3を無線動作レベルN−1で3ホップ以内におけるブロードキャストで送信する。
〔ステップS53b〕ゲートウェイ10およびセンサノード20−1は、識別子n3を受信できないとする。
〔ステップS53c〕センサノード20−2は、識別子n3を受信し、スレーブ側到達性情報テーブル24に識別子n3を登録する。
図12は到達性情報テーブルの登録例を示す図である。図10、図11に示したシーケンスによって登録されるテーブル状態を示している。
ゲートウェイ10が有するマスタ側到達性情報テーブル17において、ゲートウェイ10は、無線動作レベルN+1では、識別子n1、n2、n3を受信している(図10のS31b、S32b、S33b)。したがって、到達数=3であり、到達可能ノードとして、センサノード20−1、20−2、20−3の識別子n1、n2、n3が登録される。
また、ゲートウェイ10は、無線動作レベルNでは、識別子n1、n2を受信している(図11のS41b、S42b)。したがって、到達数=2であり、到達可能ノードとしてセンサノード20−1、20−2の識別子n1、n2が登録される。
さらに、ゲートウェイ10は、無線動作レベルN−1では、識別子n1を受信している(図11のS51b)。したがって、到達数=1であり、到達可能ノードとしてセンサノード20−1の識別子n1が登録される。
センサノード20−1が有するスレーブ側到達性情報テーブル24−1において、センサノード20−1は、無線動作レベルN+1では、識別子GW、n2、n3を受信している(図10のS30b−1、S32c−1、S33c−1)。したがって、到達数=3であり、到達可能ノードとしてゲートウェイ10、センサノード20−1、20−2の識別子GW、n2、n3が登録される。
また、センサノード20−1は、無線動作レベルNでは、識別子GW、n2、n3を受信している(図11のS40b−1、S42c−1、S43c−1)。したがって、到達数=3であり、到達可能ノードとしてゲートウェイ10、センサノード20−2、20−3の識別子GW、n2、n3が登録される。
さらに、センサノード20−1は、無線動作レベルN−1では、識別子GW、n2を受信している(図11のS50b、S52c−1)。したがって、到達数=2であり、到達可能ノードとしてゲートウェイ10、センサノードn2の識別子GW、n2が登録される。
センサノード20−2が有するスレーブ側到達性情報テーブル24−2において、センサノード20−2は、無線動作レベルN+1では、識別子GW、n1、n3を受信している(図10のS30b−2、S31c−2、S33c−2)。したがって、到達数=3であり、到達可能ノードとしてゲートウェイ10、センサノードn1、n3の識別子GW、n1、n3が登録される。
また、センサノード20−2は、無線動作レベルNでは、識別子GW、n1、n3を受信している(図11のS40b−2、S41c−2、S43c−2)。したがって、到達数=3であり、到達可能ノードとしてゲートウェイ10、センサノードn1、n3の識別子GW、n1、n3が登録される。
さらに、センサノード20−2は、無線動作レベルN−1では、識別子n1、n3を受信している(図11のS51c、S53c)。したがって、到達数=2であり、到達可能ノードとしてセンサノード20−1、20−3の識別子n1、n3が登録される。
センサノード20−3が有するスレーブ側到達性情報テーブル24−3において、センサノード20−3は、無線動作レベルN+1では、識別子GW、n1、n2を受信している(図10のS30b−3、S31c−3、S32c−3)。したがって、到達数=3であり、到達可能ノードとしてゲートウェイ10、センサノードn1、n2の識別子GW、n1、n2が登録される。
また、センサノード20−3は、無線動作レベルNでは、識別子n1、n2を受信している(図11のS41c−3、S42c−3)。したがって、到達数=2であり、到達可能ノードとしてセンサノード20−1、20−2の識別子n1、n2が登録される。
さらに、センサノード20−3は、無線動作レベルN−1では、識別子n2を受信している(図11のS52c−3)。したがって、到達数=1であり、到達可能ノードとしてセンサノード20−2の識別子n2が登録される。
上記のように、ゲートウェイ10とセンサノード20間での到達性検出が定期的に行われることで、各ノードにおいて、効率よくフレーム到達性の可否を検出することが可能になる。
なお、上記の到達性検出の制御では、センサノード20のスレーブ制御部20aは、LoRaの通信デバイスの機能を有する。したがって、ソフトウェアの変更のみで到達性検出を行う場合、無線動作レベルの代わりにホップ数にもとづいて到達性検出を行うことができる。例えば、ホップ数を所定値に設定しておき、全センサノードで応答できる最小ホップ数の値を探索して到達性検出を行うといった制御が可能である。
<配信方法候補の生成>
次に配信方法候補の生成動作について図13から図17を用いて説明する。ゲートウェイ10でのフレーム配信方法の候補生成時、管理装置30から、更新すべきファームウェアと、要求事項情報とがゲートウェイ10に送信される。
要求事項情報は、例えば、優先度、緊急度および制約に関する情報が含まれる。優先度に関する要求事項情報は、ファームウェア更新の優先度を示す情報である。例えば、ある地域に位置するセンサノードのファームウェア更新を優先的に行いたい場合、該当地域に位置するセンサノードの優先度は、他の地域に位置するセンサノードよりも優先度が高く設定される。
また、緊急度に関する要求事項情報は、ファームウェア更新の緊急度を示す情報である。例えば、障害回復のためのファームウェア更新を要するセンサノードに対しては、緊急度は高く設定され、通常のファームウェアのバージョン更新でよいセンサノードに対しては、緊急度は低く設定される。
さらに、制約に関する要求事項情報は、ファームウェア更新の時間制約を示す情報である。例えば、ある期間内にファームウェア更新を要するセンサノードに対しては、時間制約が設定される。
図13は要求事項情報の一例を示す図である。テーブルT2は、要求事項情報の具体例を示している。要求事項情報には、例えば、L時間以内に配信を完了、ゲートウェイの消費電力をMwh/h以内に抑える、更新網羅率をP%以上にする、特定のセンサノードA、B、Cの更新を優先させる、無線干渉率を最小限に抑える、配信時間を最小限に抑える等がある。
管理装置30では、ゲートウェイ10で生成されたマスタ側到達性情報テーブル17に登録されている到達性情報を参照して、要求事項情報を決定し、ゲートウェイ10に送信する。
図14は管理装置の動作を示すフローチャートである。
〔ステップS61〕管理装置30は、更新すべきファームウェアのデータをゲートウェイ10に送信する。
〔ステップS62〕管理装置30は、ゲートウェイ10で生成されたマスタ側到達性情報テーブル17に登録されている到達性情報を参照して、要求事項情報を決定する。
〔ステップS63〕管理装置30は、決定した要求事項情報をゲートウェイ10に送信する。
一方、ゲートウェイ10は、ファームウェアを受信すると、ファームウェアのデータを複数に分割し、フレームとして送信する際のフレーム送信数を算出する。そして、ゲートウェイ10は、フレーム送信数に対応する、自己の消費電力ペースおよび配信時間を算出する。ゲートウェイ10は、算出したフレーム送信数、消費電力ペースおよび配信時間をリソース情報テーブルに登録する。
図15はマスタ側リソース情報テーブルの一例を示す図である。マスタ側リソース情報テーブル18は、項目として、無線動作レベル、フレーム長、フレーム送信数、配信間隔、ホップ数、消費電力ペースおよび配信時間を有する。
フレーム長は、無線動作レベル毎にあらかじめ決められている。したがって、ゲートウェイ10は、フレーム長にもとづき、無線動作レベル毎のフレーム送信数を算出して(ファームウェアデータ長/フレーム長)、マスタ側リソース情報テーブル18に登録する。
また、ゲートウェイ10は、フレーム送信数、配信間隔およびホップ数にもとづいて、無線動作レベル毎の消費電力ペースおよび配信時間を算出して、マスタ側リソース情報テーブル18に登録する。なお、無線動作レベル毎に、配信間隔とホップ数もあらかじめ決められているとする。
そして、ゲートウェイ10は、マスタ側リソース情報テーブル18の登録内容と、管理装置30から送信された要求事項情報とから、フレーム配信方法の候補を生成する。
ここでは、管理装置30から送信された要求事項情報の内容が、10時間以内に配信完了とする。この場合、マスタ側リソース情報テーブル18の登録から、項番1の配信時間は6H、項番2の配信時間は3H、項番3の配信時間は1.5Hであり、すべて10時間以内で配信が完了するから、項番1、2、3が配信方法候補となる。
また、ゲートウェイ10は、マスタ側リソース情報テーブル18の消費電力ペースと配信時間とから、消費リソース量を予測し、配信方法候補それぞれでファームウェアを配信した際に要する消費リソース量を配信方法候補に対応づけて管理する。なお、消費リソース量は、(消費電力ペース)×(配信時間)で算出される。
図16は配信方法候補の一例を示す図である。テーブルT3は、上記の例でゲートウェイ10によって生成される配信方法候補を示している。ゲートウェイ10は、無線動作レベルN+1の1ホップのブロードキャスト、無線動作レベルNの2ホップのブロードキャスト、無線動作レベルN−1の3ホップのブロードキャストの3つの配信方法候補を生成する。
図17は配信方法候補の生成動作を示すフローチャートである。
〔ステップS71〕ゲートウェイ10は、ファームウェアのデータを受信する。
〔ステップS72〕ゲートウェイ10は、ファームウェアのデータ長をフレーム長で除算して、無線動作レベル毎のフレーム送信数を算出し、マスタ側リソース情報テーブル18に登録する。
〔ステップS73〕ゲートウェイ10は、フレーム送信数、配信間隔およびホップ数にもとづいて、無線動作レベル毎の消費電力ペースおよび配信時間を算出し、マスタ側リソース情報テーブル18に登録する。
〔ステップS74〕ゲートウェイ10は、マスタ側リソース情報テーブル18の登録内容にもとづいて、要求事項情報を満たす配信方法候補を生成する。また、ゲートウェイ10は、配信方法候補毎の消費リソース量を予測して、配信方法候補に対応づけて管理する。
なお、ソフトウェアの変更のみで配信方法候補を生成する場合、ホップ数にもとづく生成が行われる。この場合、現無線動作レベルで探し当てたホップ数のブロードキャストが配信方法候補として生成される。
<更新可否判定>
次に更新可否判定の動作について図18から図20を用いて説明する。ゲートウェイ10は、配信方法候補を生成すると、配信方法候補の情報を含む更新可否問合せ要求をセンサノード20に通知して、センサノード20が該配信方法候補で更新が可能か否かの問合せを行う。
図18は更新可否問合せ要求のフォーマットの一例を示す図である。更新可否問合せ要求14aは、項目として、更新版数、更新サイズ、無線動作レベル、フレーム長、フレーム送信数、配信間隔、ホップ数、消費電力ペースおよび配信時間を有する。
図18の例では、図15に示す項番1の配信方法候補に対する更新可否問合せ要求を示している。この場合、更新可否問合せ要求は、更新版数=02、更新サイズ=6000byte、無線動作レベル=N+1、フレーム長=30byte、フレーム送信数=200、配信間隔=10sec、ホップ数=1、消費電力ペース=20mW/h、配信時間=6Hと設定されている。
一方、更新可否問合せ要求14aを受信したセンサノード20は、スレーブ側到達性情報テーブル24の登録内容と、スレーブ側リソース情報テーブル25の登録内容との少なくとも一方にもとづいて、通知された配信方法候補でファームウェア更新が可能か否かを判定する。
図19はスレーブ側リソース情報テーブルの一例を示す図である。センサノード20は、自身のリソースに関する情報を図6に示したスレーブ側リソース情報テーブル25で管理する。図19の例では、センサノード20−1、20−2、20−3それぞれで管理される、スレーブ側リソース情報テーブル25−1、25−2、25−3の登録内容を示している。
スレーブ側リソース情報テーブル25は、項目として、電池残量、運用消費電力、無線動作レベル、および無線動作レベルに対応する発電ペースを有する。
ここで、センサノード20は、例えば、以下に示すような式(1)から更新可否を判定する。
(消費リソース量)<((電池残量)+((発電ペース)−(運用消費電力))×(配信時間))・・・式(1)
センサノード20は、式(1)を満たす場合、ゲートウェイ10から通知された配信方法候補でファームウェアの更新が可能と判定し、式(1)を満たさない場合は更新不可と判定する。センサノード20は、式(1)を用いた更新可否判定を行うことで、自身の消費電力に適したファームウェア更新を行うことが可能になる。
なお、式(1)中の消費リソース量(=消費電力ペース×配信時間)および配信時間のパラメータは、更新可否問合せ要求14aに設定されている値が使用される。
また、式(1)中の電池残量、発電ペースおよび運用消費電力のパラメータは、スレーブ側リソース情報テーブル25に登録されている値が使用される。なお、式(1)の右辺は、センサノード20の電池残量を含めた予測消費電力量になる。
図20は更新可否問合せ応答の一例を示す図である。更新可否問合せ要求14aを受信したセンサノード20は、更新可否の判定後、判定結果を更新可否問合せ応答22aに含めてゲートウェイ10に送信する。
更新可否問合せ応答22aは、項目として更新可否および条件事項を含む。更新可否は、更新可能な場合は可、更新不可能な場合は否が設定される。また、更新可否結果が否の場合、条件事項には、更新可とするための条件があればその条件の内容が設定される。
例えば、t時間後に更新可能であれば、t時間後と設定される。または配信間隔がM分以上で更新可能であれば、配信間隔がM分以上と設定される。なお、センサノード20が自動的にファームウェア更新できない場合、条件事項には、作業員によって更新すべきことが設定されてもよい。
<配信方法の選択>
次に配信方法の選択動作について説明する。ゲートウェイ10は、センサノード20から送信された更新可否問合せ応答22aを集計して、図5に示した更新可否問合せ応答テーブル19を生成する。
図21は更新可否問合せ応答テーブルの一例を示す図である。更新可否問合せ応答テーブル19は、センサノード20から送信された更新可否問合せ応答22aを配信方法候補毎に集計したものである。
図21の例において、テーブル19aでは、センサノード20−1は、配信方法候補#1で更新可、センサノード20−2、20−3は、配信方法候補#1で更新不可になっている。なお、センサノード20−2は、1時間後であれば配信方法候補#1で更新可であることが示されている。
テーブル19bでは、センサノード20−1、20−3は、配信方法候補#2で更新可、センサノード20−2は、配信方法候補#2で更新不可になっている。なお、センサノード20−2は、2時間後であれば配信方法候補#2で更新可であることが示されている。
テーブル19cでは、センサノード20−1、20−3は、配信方法候補#3で更新可、センサノード20−2は、配信方法候補#3で更新不可になっている。なお、センサノード20−2は、3時間後であれば配信方法候補#3で更新可であることが示されている。
ゲートウェイ10は、上記のように、各センサノードから送信された更新可否問合せ応答22aを集計して、更新可否問合せ応答テーブル19を生成すると、管理装置30に送信する。管理装置30は、集計結果である更新可否問合せ応答テーブル19の内容にもとづいて、最新の要求事項情報があればゲートウェイ10に最新の要求事項を送信する。
ゲートウェイ10は、更新可否問合せ応答テーブル19と、管理装置30から送信された最新の要求事項情報とにもとづいて、配信方法候補の中から配信方法を選択し、選択した配信方法でフレームを配信する。この場合、ゲートウェイ10は、可への条件を満たす指示を実行後、選択した配信方法でフレーム配信を行う。
例えば、ゲートウェイ10は、配信方法候補#1、#2、#3の中から配信方法候補#2を選択した場合、2時間後に配信方法候補#2の方法(無線動作レベルNの2ホップブロードキャスト)でフレームを配信することになる。
なお、配信方法選択の際、要求事項を満たす配信方法候補が複数存在する場合、ホップ数が大きいと干渉の発生確率が高くなるため、干渉低減のためホップ数が小さい配信方法候補を優先的に選択する。また、ゲートウェイ10は、可への条件が反映できない場合、更新対象センサノードから該当センサノードを除外してフレーム配信を実行し、該当センサノードは開始時、自律で期限付きスリープ状態に入る。
<未更新のセンサノードが存在する場合の対処>
フレーム配信を実行後、フレームロス等の要因で更新できないセンサノードが存在するケースがある。この場合、ゲートウェイ10は、定期的にセンサノードからゲートウェイ10へ通知されるファーム版数情報等にもとづいて、未更新のセンサノードを検知する。
そして、ゲートウェイ10は、未更新センサノードの近隣の更新済みセンサノードに対して、未更新センサノードへの更新要求(更新指示)を行う。更新要求を受けた更新済みセンサノードは、未更新分のフレームを送信して未更新センサノードに対して更新を行う。
または、未更新センサノード自身が近隣の更新済みセンサノードへ更新依頼の要求を行うことで、更新要求を受けた更新済みセンサノードが、未更新センサノードに対して未更新分のフレームを送信して更新を行うこともできる。
このように、未更新センサノードが存在するケースが生じた場合、未更新センサノードの近隣に位置する更新完了済みのセンサノードを使用して、未更新センサノードに対して未更新分のフレームが配信される。これにより、未更新センサノードに対して、ファームウェアの未更新分を補完することが可能になる。
<更新可とするための条件が付与されたセンサノードの更新>
次に更新可とするための条件が付与されたセンサノードの更新について図22、図23を用いて説明する(以降の説明ではセンサノードの識別子をセンサノードの符号として使用する)。
図22はゲートウェイからのブロードキャスト範囲を示す図である。ゲートウェイ10は、無線動作レベルNでセンサノードn1、・・・、n9、nAに対して、フレームを配信してファームウェアを更新できたとする。また、センサノードnB、nC、nD、nE、nFはファームウェアの更新ができなかったとする。
図23は更新可否問合せ応答テーブルの一例を示す図である。更新可否問合せ応答テーブル19−1では、センサノードn1、・・・、n9、nAは、無線動作レベルNの1ホップブロードキャストで更新可になっている。一方、センサノードnB、nC、nD、nE、nFは、条件付きで更新可になっている。
すなわち、センサノードnBは、ゲートウェイ10による無線動作レベルNの1ホップブロードキャストで更新不可であるが、近隣のセンサノードnA、n1、n2、n7、n9、nC、nDからフレームが送信されれば更新可としている。
センサノードnCは、ゲートウェイ10による無線動作レベルNの1ホップブロードキャストで更新不可であるが、近隣のセンサノードnA、n1、n2、n9、nB、nDからフレームが送信されれば更新可としている。
センサノードnDは、ゲートウェイ10による無線動作レベルNの1ホップブロードキャストで更新不可であるが、近隣のセンサノードnA、n1、n2、n9、nB、nCからフレームが送信されれば更新可としている。
センサノードnEは、ゲートウェイ10による無線動作レベルNの1ホップブロードキャストで更新不可であるが、近隣のセンサノードnA、n3、n9、nD、nFからフレームが送信されれば更新可としている。
センサノードnFは、ゲートウェイ10による無線動作レベルNの1ホップブロードキャストで更新不可であるが、近隣のセンサノードnA、n1、n3、n4、n8、nEからフレームが送信されれば更新可としている。
上記のような条件付きで更新可となるセンサノードnB、nC、nD、nE、nFに対して、以下のような制御で更新が行われる。
(更新制御例1)
ゲートウェイ10は、無線動作レベルNの1ホップのブロードキャストの実施後、更新可否問合せ応答テーブル19−1の条件事項に現れるセンサノードの中から共通するセンサノードnAを検出する。そして、ゲートウェイ10は、センサノードnAに無線動作レベルNの1ホップのブロードキャストの指示を送り、センサノードnAがフレーム配信を実行する。
(更新制御例2)
ゲートウェイ10は、無線動作レベルN+1、またはN+2の1ホップのブロードキャストにて更新が完了したセンサノードの識別子を、センサノードnB、nC、nD、nE、nFに通知する。そして、センサノードnB、nC、nD、nE、nFが、自律で更新完了したセンサノードへ更新依頼を送信し、更新完了したセンサノードから配信されるフレームで更新を行う。
<更新効果値にもとづくフレーム配信>
次に更新効果値にもとづくフレーム配信動作について説明する。更新効果値は、フレーム配信方法を選択する際の指標であり、更新効果値がより高いフレーム配信方法が選択される。
(手順1)センサノードは、ゲートウェイ10から送信された保守モードフレームを受信すると、無線動作レベルを切り替えて保守モード通信を行う。また、ゲートウェイ10は、センサノードに対して、更新可否問合せを行って、更新可能なセンサノードを検出する。
なお、ゲートウェイ10は、運用時の空き時間に定期的に、到達性検出を実施する。また、ゲートウェイ10は、更新バージョン、サイズ、配信方法候補等を含む更新可否問合せ要求をブロードキャストで送信する。
(手順2)センサノードは、自身の電池残量と、過去の需要/供給量を計算し、受信した配信方法候補でファームウェアの更新が可能か否かを判定し、判定結果をゲートウェイ10へ送信する。なお、電池残量は、ファームサイズ、フレームサイズ、無線動作レベル、配信方法から、送受信に必要なバッテリー量を算出する。
例えば、送受信に要する電池残量の算出方法について、ファームサイズ=1000byte、1フレームサイズ=10byte、無線動作レベル=N+5、配信方法=1ホップ以内ブロードキャスト、1送受信の消費電力=10mWhとする。この場合、以下の式(2)で算出される。
(送受信に要する電池残量)=1000byte÷10byte×10mWh×(1回)=1000mWh・・・(2)
なお、式(2)中の1回とは、1ホップ以内ブロードキャストの場合では中継送信しないため、受信にかかる電池残量について考慮したものである。
(手順3)ゲートウェイ10は、各配信方法候補でフレーム配信した場合の配信完了見込時間を算出する。配信完了見込み時間は例えば、以下の式(3)で算出される。
(配信完了見込み時間)=(フレーム送信数)×(フレーム送信間隔)+(フレーム配信開始時間)・・・(3)
(手順4)管理装置30は、ファームウェア更新の効果基準(例えば、期間内、消費電力、コスト、時間および確実性を含む)を設定し、ゲートウェイ10は、配信方法候補に対する更新効果値を算出して、効果値が高い配信方法を選択して実行する。
更新効果値の算出としては、例えば100を最良値として、期間内と消費電力の小ささという点で各無線動作レベルの比較を行い、最良のものが選択される。
図24は更新効果値にもとづく配信方法の選択動作を示す図である。通信システム1−2は、ゲートウェイ10、センサノードn1、・・・、n17を備える。なお、無線動作レベルはLoRaによる通信を行った場合のレベルとする。
センサノードn1、・・・、n4は、ゲートウェイ10から無線動作レベルがFSK(frequency shifting keying)の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがFSKまでの範囲で更新可能ノード数は4である。
また、ゲートウェイ10は、センサノードn1、・・・、n4に対して、ファームウェアの配信完了見込み時間をtと算出し、更新効果値を55と算出している。
センサノードn5、n6、n7は、ゲートウェイ10から無線動作レベルがNの範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがNまでの範囲で更新可能ノード数は、センサノードn1、・・・、n4も含めて7である。
また、ゲートウェイ10は、センサノードn1、・・・、n7に対して、ファームウェアの配信完了見込み時間を2t+mと算出し、更新効果値を68と算出している。
センサノードn8、n9は、ゲートウェイ10から無線動作レベルがN+1の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがN+1のまでの範囲で更新可能ノード数は、センサノードn1、・・・、n7も含めて9である。
また、ゲートウェイ10は、センサノードn1、・・・、n9に対して、ファームウェアの配信完了見込み時間を3t+nと算出し、更新効果値を74と算出している。
センサノードn10、n11は、ゲートウェイ10から無線動作レベルがN+2の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがN+2までの範囲で更新可能ノード数は、センサノードn1、・・・、n9も含めて11である。
また、ゲートウェイ10は、センサノードn1、・・・、n11に対して、ファームウェアの配信完了見込み時間を4t+oと算出し、更新効果値を80と算出している。
センサノードn12、n13は、ゲートウェイ10から無線動作レベルがN+3の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがN+3までの範囲で更新可能ノード数は、センサノードn1、・・・、n11も含めて13である。
また、ゲートウェイ10は、センサノードn1、・・・、n13に対して、ファームウェアの配信完了見込み時間を5t+pと算出し、更新効果値を86と算出している。
センサノードn14、n15は、ゲートウェイ10から無線動作レベルがN+4の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがN+4までの範囲で更新可能ノード数は、センサノードn1、・・・、n13も含めて15である。
また、ゲートウェイ10は、センサノードn1、・・・、n15に対して、ファームウェアの配信完了見込み時間を6t+qと算出し、更新効果値を92と算出している。
センサノードn16、n17は、ゲートウェイ10から無線動作レベルがN+5の範囲内に位置する。よって、ゲートウェイ10において、無線動作レベルがN+5までの範囲で更新可能ノード数は、センサノードn1、・・・、n15も含めて17である。
また、ゲートウェイ10は、センサノードn1、・・・、n17に対して、ファームウェアの配信完了見込み時間を7t+rと算出し、更新効果値を98と算出している。
したがって、通信システム1−2において、更新効果値=98が最も高いので、無線動作レベルN+5のフレーム配信が選択されて実行されることになる。
以上説明したように、本発明によれば、ゲートウェイからセンサノードへの到達性とフレーム送信数とにもとづき、フレーム配信方法の候補を作成し、ノードが更新可能な配信方法を該候補から選択するので、運用に支障なく更新用フレームを配信することができる。また、送信、受信側双方の状況に応じたフレーム配信により長期運用が可能になる。マルチホップのフラッディングが減少するので無線干渉が減り、到達性を向上させることが可能になる。さらに、管理装置の要求に沿ったファームウェア更新を行うことが可能になる。
上記で説明した本発明のマスタノード/スレーブノードおよびゲートウェイ/センサノードの処理機能は、コンピュータによって実現することができる。この場合、マスタノード/スレーブノードおよびゲートウェイ/センサノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。
処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープ等がある。光ディスクには、DVD、DVD−RAM、CD−ROM/RW等がある。光磁気記録媒体には、MO(Magneto Optical disk)等がある。
プログラムを流通させる場合、例えば、そのプログラムが記録されたDVD、CD−ROM等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。
また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。また、上記の処理機能の少なくとも一部を、DSP、ASIC、PLD等の電子回路で実現することもできる。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の2以上の構成(特徴)を組み合わせたものであってもよい。
1 通信システム
1a マスタノード
1b スレーブノード

Claims (10)

  1. マスタノード内のマスタコンピュータが、
    スレーブノードにフレームを送信した場合のフレーム到達可否状態を検出し、
    前記フレーム到達可否状態と、前記フレームの送信数とにもとづいて、フレーム配信方法の候補を生成して前記候補を前記スレーブノードへ送信し、
    前記スレーブノードから送信された更新可否情報にもとづいて、前記候補の中から前記フレーム配信方法を選択するマスタ側処理を行い、
    前記スレーブノード内のスレーブコンピュータが、
    選択された前記フレーム配信方法で配信された前記フレームによる内部動作の更新可否を判定して前記更新可否情報を生成して送信するスレーブ側処理を行う、
    配信制御方法。
  2. 前記マスタ側処理は、無線動作レベル毎に要求信号を送信し、前記スレーブ側処理は、前記要求信号を受信した場合、応答信号を送信し、前記マスタ側処理は、前記応答信号の取得結果に応じて、前記無線動作レベル毎の前記フレーム到達可否状態を検出する請求項1記載の配信制御方法。
  3. 前記マスタ側処理は、LoRa(Long Range)による前記無線動作レベルで制御した前記要求信号を送信する請求項2記載の配信制御方法。
  4. 前記マスタ側処理は、前記フレーム到達可否状態および前記フレームの送信数から、前記フレームの配信に要するリソースを予測し、システム管理側で要求された要求事項を満たす前記リソースで配信可能な前記フレーム配信方法の前記候補を生成し、前記候補および前記リソースを含む更新可否問合せ要求を送信する請求項1記載の配信制御方法。
  5. 前記要求事項には、前記スレーブノードの更新網羅性、更新すべき前記スレーブノードの優先度、またはフレーム配信の時間制約の少なくとも1つが含まれる請求項4記載の配信制御方法。
  6. 前記スレーブ側処理は、更新可否問合せ要求を受信した場合、前記スレーブノードの電池残量を含めた予測消費電力量が、リソースで消費される電力量よりも大きい場合は更新可と判定し、前記予測消費電力量が前記電力量よりも小さい場合は更新不可と判定して前記更新可否情報を生成する請求項1記載の配信制御方法。
  7. 前記スレーブ側処理は、更新不可と判定した場合、配信された前記フレームの受信をスリープモードに移行して停止する請求項6記載の配信制御方法。
  8. 前記マスタ側処理は、更新が完了しない未更新スレーブノードを検出した場合、前記未更新スレーブノードの近隣に位置して、更新が完了している近隣スレーブノードに対して更新指示を出力し、前記更新指示を受けた前記近隣スレーブノード内の前記スレーブ側処理は、未更新分の前記フレームを前記未更新スレーブノードに送信する請求項1記載の配信制御方法。
  9. 前記スレーブ側処理は、更新が完了せず、自身が未更新スレーブノードになっていることを検出した場合、前記未更新スレーブノードの近隣に位置して、更新が完了している近隣スレーブノードに対して更新指示を出力し、前記更新指示を受けた前記近隣スレーブノードから送信される未更新分の前記フレームを受信する請求項1記載の配信制御方法。
  10. スレーブ側にフレームを送信した場合のフレーム到達可否状態を検出し、前記フレーム到達可否状態と、前記フレームの送信数とにもとづいて、フレーム配信方法の候補を生成して前記候補を前記スレーブ側へ送信し、前記スレーブ側から送信された更新可否情報にもとづいて、前記候補の中から前記フレーム配信方法を選択するマスタノードと、
    選択された前記フレーム配信方法で配信された前記フレームによる内部動作の更新可否を判定して前記更新可否情報を生成して送信するスレーブノードと、
    を有する通信システム。
JP2017156855A 2017-08-15 2017-08-15 配信制御方法および通信システム Pending JP2019036841A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017156855A JP2019036841A (ja) 2017-08-15 2017-08-15 配信制御方法および通信システム
US16/058,182 US10445087B2 (en) 2017-08-15 2018-08-08 Communication system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017156855A JP2019036841A (ja) 2017-08-15 2017-08-15 配信制御方法および通信システム

Publications (1)

Publication Number Publication Date
JP2019036841A true JP2019036841A (ja) 2019-03-07

Family

ID=65361503

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017156855A Pending JP2019036841A (ja) 2017-08-15 2017-08-15 配信制御方法および通信システム

Country Status (2)

Country Link
US (1) US10445087B2 (ja)
JP (1) JP2019036841A (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110659043B (zh) * 2019-08-27 2022-09-30 中国第一汽车股份有限公司 固件升级方法、装置、设备和存储介质
EP4162363A1 (en) 2020-07-30 2023-04-12 Accenture Global Solutions Limited Green cloud computing recommendation system

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8223783B2 (en) * 2006-01-31 2012-07-17 Sigma Designs, Inc. Using battery-powered nodes in a mesh network
US7680041B2 (en) * 2006-01-31 2010-03-16 Zensys A/S Node repair in a mesh network
JP4720794B2 (ja) 2007-06-05 2011-07-13 パナソニック電工株式会社 マルチホップ通信ネットワークにおける隣接ノード確認方法、マルチホップ通信ネットワークのノード
US8279870B2 (en) * 2007-08-01 2012-10-02 Silver Spring Networks, Inc. Method and system of routing in a utility smart-grid network
JP5452145B2 (ja) 2009-09-14 2014-03-26 富士電機株式会社 無線端末装置、無線通信システム、無線通信方法
JP5299561B2 (ja) 2010-03-31 2013-09-25 富士通株式会社 ファームウェア更新方法、通信ユニット、およびプログラム
JP5447681B2 (ja) * 2010-09-29 2014-03-19 富士通株式会社 通信システム、制御装置、およびノード装置
US9288066B2 (en) * 2011-11-10 2016-03-15 Cisco Technology, Inc. Dynamic multicast mode selection in a communication network
WO2013088498A1 (ja) * 2011-12-12 2013-06-20 富士通株式会社 送信制御方法、ノードおよび送信制御プログラム
EP2663089A1 (en) * 2012-05-07 2013-11-13 Kamstrup A/S Consumption meter with remote control program update
JP2013059125A (ja) 2012-12-20 2013-03-28 Tokyo Gas Co Ltd センサネットワークシステム、および、通信経路設定方法
US9172613B2 (en) * 2013-08-06 2015-10-27 Cisco Technology, Inc. Multiple topology routing architecture in computer networks
US8891588B1 (en) * 2013-08-06 2014-11-18 Cisco Technology, Inc. On-demand medium to low transmission power channel switching in computer networks
WO2019113308A1 (en) * 2017-12-05 2019-06-13 Franchitti Jean Claude Active adaptation of networked compute devices using vetted reusable software components

Also Published As

Publication number Publication date
US20190056927A1 (en) 2019-02-21
US10445087B2 (en) 2019-10-15

Similar Documents

Publication Publication Date Title
JP5683755B2 (ja) パケットのループフリールーティングのためのスマートメーターネットワークにおける破損したリンクを回避する方法
US20120310599A1 (en) Sensor data collection system
JP5338567B2 (ja) 無線端末及び無線システム
US20130070671A1 (en) Path control method for multihop wireless network
WO2016036475A1 (en) Dynamic routing in a mesh network
JP5397052B2 (ja) Sleepモード制御を行う情報処理装置、Sleepモード制御プログラム、およびSleepモード制御方法
JP2017152855A (ja) 無線通信装置、無線通信方法およびプログラム
JP2009094896A (ja) 無線装置
KR101168357B1 (ko) 센서 네트워크
US11010271B2 (en) Information processing device, status monitoring system, and recording medium
JP2014216796A (ja) 無線通信装置および方法、ならびにプログラム
JP2019036841A (ja) 配信制御方法および通信システム
JP6111908B2 (ja) 通信装置と電池残容量導出方法
JP6448414B2 (ja) 無線テレメータシステム及び無線通信装置
WO2014068665A1 (ja) 通信システムおよび端末の所属先ネットワーク切替方法
JP6617713B2 (ja) 通信装置、通信方法、及びプログラム
JP6738855B2 (ja) 情報処理装置、情報処理装置の制御方法、情報処理装置の制御プログラム、無線通信装置、無線通信装置の制御方法、及び、無線通信装置の制御プログラム
KR20090099636A (ko) 센서 네트워크에서의 패킷 라우팅 방법
JP6408648B2 (ja) 無線通信装置および方法、ならびにプログラム
JP5951530B2 (ja) 通信ネットワークシステム、及び通信ネットワークシステムの制御方法
JP2016201654A (ja) 通信装置及びパケットの中継方法
TWI727519B (zh) 終端裝置、通信系統及通信方法
JP6858456B2 (ja) 無線通信装置及び通信方法
JP2014068286A (ja) 通信ネットワークシステム、通信媒体の切替え方法、及びネットワーク構築支援方法
US11452037B2 (en) Optimized parent and path selection for battery powered devices within a wireless network