図面 (/)

技術 ゲートウェイ、通信システム及び通信方法

出願人 日本電信電話株式会社
発明者 河野伸也
出願日 2019年2月13日 (1年9ヶ月経過) 出願番号 2019-024005
公開日 2020年8月31日 (2ヶ月経過) 公開番号 2020-136745
状態 未査定
技術分野 広域データ交換 小規模ネットワーク(3)ループ,バス以外
主要キーワード 最大許容数 タイマデータ 最大性能 ドローン ホント 許容数 監視周期 受信予定
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年8月31日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題

IoTデバイススリープ状態である場合にも適切な死活監視を実現するとともに、死活監視によるIoTデバイス収容GWの負荷の軽減を可能にする。

解決手段

IoTデバイス収容GW20は、死活監視時間管理部21、死活監視受信量管理部23及び通信部24を有する。死活監視時間管理部21は、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する。死活監視受信量管理部23は、死活監視時間管理部21による設定内容を基に、単位時間あたりのIoTデバイスによる死活監視メッセージの受信予定数を取得する。死活監視時間管理部21は、取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかのIoTデバイスの死活監視メッセージの送信時間を変更する。通信部24は、死活監視時間管理部21が設定した送信時間または変更した送信時間をIoTデバイスに送信する。

概要

背景

近年、ネットワークカメラテレビ等、ネットワークに接続されるIoT(Internet of Things)デバイス多様化にしたがい、IoTデバイス数も増大している。従来、IoTデバイスを死活監視する方法として、IoTデバイスがIoTデバイス収容ゲートウェイ(GW)に対して定期的に死活監視信号を送信する方法がある(非特許文献1参照)。また、IoTデバイス収容GWがIoTデバイスに対して定期的に死活監視信号を送信する方法がある(非特許文献2参照)。

概要

IoTデバイスがスリープ状態である場合にも適切な死活監視を実現するとともに、死活監視によるIoTデバイス収容GWの負荷の軽減を可能にする。IoTデバイス収容GW20は、死活監視時間管理部21、死活監視受信量管理部23及び通信部24を有する。死活監視時間管理部21は、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する。死活監視受信量管理部23は、死活監視時間管理部21による設定内容を基に、単位時間あたりのIoTデバイスによる死活監視メッセージの受信予定数を取得する。死活監視時間管理部21は、取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかのIoTデバイスの死活監視メッセージの送信時間を変更する。通信部24は、死活監視時間管理部21が設定した送信時間または変更した送信時間をIoTデバイスに送信する。

目的

本発明は、上記に鑑みてなされたものであって、IoTデバイスがスリープ状態である場合にも適切な死活監視を実現するとともに、死活監視によるIoTデバイス収容GWの負荷の軽減を可能にするゲートウェイ、通信システム及び通信方法を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数のIoT(InternetofThings)デバイスを収容するゲートウェイであって、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する第1の設定部と、前記第1の設定部による設定内容を基に、単位時間あたりの前記IoTデバイスによる死活監視メッセージの受信予定数を取得する第1の取得部と、前記取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかの前記IoTデバイスの死活監視メッセージの送信時間を変更する変更部と、前記第1の設定部が設定した送信時間または前記変更部が変更した送信時間を前記IoTデバイスに送信する通信部と、を有することを特徴とするゲートウェイ。

請求項2

前記第1の取得部は、前記取得した受信予定数が前記死活監視メッセージの受信許容数を超えた場合、以降の単位時間ごとに、前記IoTデバイスによる死活監視メッセージの受信予定数を取得し、前記変更部は、前記第1の取得部が取得した受信予定数が、前記死活監視メッセージの受信許容数以下となる単位時間に対応させて、いずれかの前記IoTデバイスの死活監視メッセージの送信時間を変更することを特徴とする請求項1に記載のゲートウェイ。

請求項3

単位時間ごとに前記IoTデバイスのトランザクション数履歴を取得する第2の取得部と、前記トランザクション数の履歴を基に単位時間におけるトランザクション数を予測し、当該ゲートウェイにおける単位時間あたりのトランザクション数の最大許容数と、予測した前記トランザクション数とを基に、前記単位時間における前記死活監視メッセージの受信許容数を設定する第2の設定部と、をさらに有することを特徴とする請求項1または2に記載のゲートウェイ。

請求項4

複数のIoT(InternetofThings)デバイスと、前記複数のIoTデバイスを収容するゲートウェイとを有する通信システムであって、前記ゲートウェイは、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する第1の設定部と、前記第1の設定部による設定内容を基に、単位時間あたりの前記IoTデバイスによる死活監視メッセージの受信予定数を取得する第1の取得部と、前記取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかの前記IoTデバイスの死活監視メッセージの送信時間を変更する変更部と、前記第1の設定部が設定した送信時間または前記変更部が変更した送信時間を前記IoTデバイスに送信する第1の通信部と、を有し、前記IoTデバイスは、前記第1の通信部によって送信された監視周期にしたがって、前記ゲートウェイにメッセージを送信する第2の通信部を有することを特徴とする通信システム。

請求項5

前記第1の取得部は、前記取得した受信予定数が前記死活監視メッセージの受信許容数を超えた場合、以降の単位時間ごとに、前記IoTデバイスによる死活監視メッセージの受信予定数を取得し、前記変更部は、前記第1の取得部が取得した受信予定数が、前記死活監視メッセージの受信許容数以下となる単位時間に対応させて、いずれかの前記IoTデバイスの死活監視メッセージの送信時間を変更することを特徴とする請求項4に記載の通信システム。

請求項6

前記ゲートウェイは、単位時間ごとに前記IoTデバイスのトランザクション数の履歴を取得する第2の取得部と、前記トランザクション数の履歴を基に単位時間におけるトランザクション数を予測し、当該ゲートウェイにおける単位時間あたりのトランザクション数の最大許容数と、予測した前記トランザクション数とを基に、前記単位時間における前記死活監視メッセージの受信許容数を設定する第2の設定部と、をさらに有することを特徴とする請求項4または5に記載の通信システム。

請求項7

前記IoTデバイスは、前記第1の通信部によって送信された監視周期にしたがって、通信時以外の期間、前記第2の通信部をスリープ状態にする管理部をさらに有することを特徴とする請求項4〜6のいずれか一つに記載の通信システム。

請求項8

IoT(InternetofThings)デバイスを収容するゲートウェイが実行する通信方法であって、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する工程と、前記設定する工程において設定された設定内容を基に、単位時間あたりの前記IoTデバイスによる死活監視メッセージの受信予定数を取得する工程と、前記取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかの前記IoTデバイスの前記死活監視メッセージの送信時間を変更する工程と、前記設定する工程において設定された送信時間または前記変更する工程において変更された送信時間を前記IoTデバイスに送信する工程と、を含んだことを特徴とする通信方法。

技術分野

0001

本発明は、ゲートウェイ通信ステム及び通信方法に関する。

背景技術

0002

近年、ネットワークカメラテレビ等、ネットワークに接続されるIoT(Internet of Things)デバイス多様化にしたがい、IoTデバイス数も増大している。従来、IoTデバイスを死活監視する方法として、IoTデバイスがIoTデバイス収容ゲートウェイ(GW)に対して定期的に死活監視信号を送信する方法がある(非特許文献1参照)。また、IoTデバイス収容GWがIoTデバイスに対して定期的に死活監視信号を送信する方法がある(非特許文献2参照)。

先行技術

0003

特集実験で分かった!LPWAのホントの実力(コラム2),[online],[平成30年12月20日検索],インターネット<URL:https://businessnetwork.jp/Detail/tabid/65/artid/5450/Default.aspx>
AWSIoTデバイス死活監視, [online],[平成30年12月20日検索],インターネット<URL:https://qiita.com/yokobonbon/items/a80952f5ecde3f4ed628>

発明が解決しようとする課題

0004

IoTデバイス数の増加によって、IoTデバイスのデータ信号数が増大するとともに、デバイスの死活監視信号も増大する。これによって、死活監視によるIoTデバイス収容GWの負荷が増大するという問題があった。

0005

例えば、非特許文献1に記載の方法では、IoTデバイスがIoTデバイス収容GWに対して定期的に死活監視信号を送信する。このため、非特許文献1に記載の方法では、IoTデバイス収容GWのシステムが高負荷時である場合にも死活監視信号を送信してしまい、IoTデバイス収容GWの負荷が増大する。

0006

また、非特許文献2に記載の方法では、IoTデバイス収容GWがIoTデバイスに対して定期的に死活監視信号を送信するため、IoTデバイスがスリープ状態省電力機能によるスリープ)で信号受信ができない場合に対応ができない。

0007

本発明は、上記に鑑みてなされたものであって、IoTデバイスがスリープ状態である場合にも適切な死活監視を実現するとともに、死活監視によるIoTデバイス収容GWの負荷の軽減を可能にするゲートウェイ、通信システム及び通信方法を提供することを目的とする。

課題を解決するための手段

0008

上述した課題を解決し、目的を達成するために、本発明に係るゲートウェイは、複数のIoTデバイスを収容するゲートウェイであって、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する第1の設定部と、第1の設定部による設定内容を基に、単位時間あたりのIoTデバイスによる死活監視メッセージの受信予定数を取得する第1の取得部と、取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかのIoTデバイスの死活監視メッセージの送信時間を変更する変更部と、第1の設定部が設定した送信時間または変更部が変更した送信時間をIoTデバイスに送信する通信部と、を有することを特徴とする。

0009

また、本発明に係る通信システムは、複数のIoTデバイスと、複数のIoTデバイスを収容するゲートウェイとを有する通信システムであって、ゲートウェイは、各IoTデバイスに対して、死活監視メッセージの当該ゲートウェイに対する送信時間を設定する第1の設定部と、第1の設定部による設定内容を基に、単位時間あたりのIoTデバイスによる死活監視メッセージの受信予定数を取得する第1の取得部と、取得した受信予定数が死活監視メッセージの受信許容数を超えた場合、いずれかのIoTデバイスの死活監視メッセージの送信時間を変更する変更部と、第1の設定部が設定した送信時間または変更部が変更した送信時間をIoTデバイスに送信する第1の通信部と、を有し、IoTデバイスは、第1の通信部によって送信された監視周期にしたがって、ゲートウェイにメッセージを送信する第2の通信部を有することを特徴とする。

発明の効果

0010

本発明によれば、IoTデバイスがスリープ状態である場合にも適切な死活監視を実現するとともに、死活監視によるIoTデバイス収容GWの負荷の軽減を可能にする。

図面の簡単な説明

0011

図1は、実施の形態1における通信システムの構成の一例を示す図である。
図2は、図1に示すIoTデバイスの構成の一例を示す図である。
図3は、図1に示すIoTデバイス収容GWの構成の一例を示す図である。
図4は、死活監視受信タイマ時間管理を説明する図である。
図5は、死活監視受信量管理部による死活監視メッセージの受信予定数の管理を説明する図である。
図6は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。
図7は、図6に示す死活監視メッセージの送信時間設定処理の処理手順を示すフローチャートである。
図8は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。
図9は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。
図10は、実施の形態2に係るIoTデバイス収容GWの構成の一例を示す図である。
図11は、トランザクション管理部が取得するトランザクション数履歴を説明する図である。
図12は、許容数設定部が求めた単位時間における死活監視メッセージの受信許容数を示す図である。
図13は、実施の形態2に係る死活監視処理の処理手順の一例を示すシーケンス図である。
図14は、図13に示す許容数設定処理の処理手順を示すフローチャートである。
図15は、プログラムが実行されることにより、実施の形態1,2の通信システムを構成する装置が実現されるコンピュータの一例を示す図である。

実施例

0012

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

0013

[実施の形態1]
システム構成
図1は、実施の形態1に係る通信システムの概略構成を示す図である。図1に示すように、実施の形態1に係る通信システムは、複数のIoTデバイス10と、IoTデバイス収容GW20とを有する。

0014

IoTデバイス10は、例えば、各種センサカメラ家電自動車ドローン等に設けられた通信可能な通信装置である。IoTデバイス10は、IoTデバイス収容GW20に収容される。IoTデバイス10は、IoTデバイス収容GW20に設定された監視周期にしたがって、死活監視メッセージをIoTデバイス収容GW20に送信する。

0015

IoTデバイス収容GW20は、複数のIoTデバイス10を収容する。IoTデバイス収容GW20は、IoTデバイス10に対し、監視周期を設定して、IoTデバイス10に、設定した監視周期で死活監視メッセージを送信させることによって、IoTデバイス10の死活監視を行う。具体的には、IoTデバイス収容GW20は、データまたは死活監視メッセージをIoTデバイスから受信した場合に、死活監視メッセージの送信時間をIoTデバイス10に通知する。IoTデバイス収容GW20は、ネットワークを介して、上位のサーバ、例えば、サービス事業者が有するサーバと通信を行う。

0016

[IoTデバイスの構成]
次に、IoTデバイス10の構成について説明する。図2は、図1に示すIoTデバイス10の構成の一例を示す図である。図2に示すように、IoTデバイス10は、センサ11、再送タイマ12、死活監視タイマ13、通信部14(第2の通信部)、データ送信トリ監視部15及びスリープ管理部16(管理部)を有する。IoTデバイス10は、例えば、センサ、メモリ及びCPU等によって実現される。

0017

センサ11は、例えば、温度センサである。センサ11は、検出したデータをデータ送信トリガ監視部15に出力する。

0018

再送タイマ12は、IoTデバイス10がIoTデバイス収容GW20に送信したメッセージに対する、IoTデバイス収容GW20からの確認応答がない場合に再送を行うためのタイマである。

0019

死活監視タイマ13は、死活監視メッセージのタイマデータを管理する。タイマデータは、IoTデバイス収容GW20から受信した死活監視メッセージの送信時間を示すデータである。IoTデバイス収容GW20によって設定された死活監視メッセージの送信時間に達した際に、通信部14に、死活監視メッセージを送信させる。

0020

通信部14は、IoTデバイス収容GW20との間で通信を行う。通信部14は、IoTデバイス収容GW20から確認応答を受信する。確認応答は、死活監視メッセージの送信時間を含む。通信部14は、センサ11が検出したデータまたは死活監視メッセージを、IoTデバイス収容GW20に送信する。

0021

データ送信トリガ監視部15は、センサ11が検出したデータを送信するためのトリガ管理を行う。データ送信トリガ監視部15は、例えばタイマであり、前回のデータ送信時から所定時間経過時に、通信部14にデータを送信させる。また、データ送信トリガ監視部15は、センサ11が検出したデータに対して閾値監視を行い、データの値が閾値を超えた場合に、通信部14に検出データを送信させる。

0022

スリープ管理部16は、データ通信がない期間、通信機能等をスリープさせる。スリープ管理部16は、IoTデバイス収容GW20から確認応答を受信後、確認応答で指示された死活監視メッセージの送信時間までの間、通信機能等をスリープさせて、省電力化を図る。

0023

[IoTデバイス収容GWの構成]
図3は、図1に示すIoTデバイス収容GW20の構成の一例を示す図である。図2に示すように、IoTデバイス収容GW20は、死活監視時間管理部21(第1の設定部、変更部)、死活監視受信タイマ22、死活監視受信量管理部23(第1の取得部)及び通信部24(第1の通信部)を有する。

0024

死活監視時間管理部21は、IoTデバイス10毎に死活監視周期を管理する。死活監視時間管理部21は、IoTデバイス10毎に、あらかじめ、デフォルト値の死活監視時間が登録される。例えば、あるIoTデバイス10については、デフォルト値として、監視周期として、1日が設定される。当該監視周期は、システム管理者があらかじめ設定してもよいし、デバイスをシステムに登録する際にユーザが設定してもよい。そして、死活監視時間管理部21は、IoTデバイス10に対して、死活監視メッセージのIoTデバイス収容GW20に対する送信時間を設定する。具体的には、死活監視時間管理部21は、データまたは死活監視メッセージをIoTデバイス10から受信した場合に、死活監視メッセージの送信時間を含めた確認応答を、このIoTデバイス10に送信する。

0025

死活監視受信タイマ22は、IoTデバイス10毎に、IoTデバイス10によるデータ受信時からの経過時間を管理するためのタイマである。図4は、死活監視受信タイマ22の時間管理を説明する図である。

0026

図4の表T1に示すように、死活監視受信タイマ22は、IoTデバイス10のIPアドレスと、タイマ値とを対応付けて管理する。死活監視時間管理部21は、あらかじめIoTデバイス10毎に登録された死活監視時間にしたがって、各IoTデバイス10のタイマの値を設定する。例えば、「IP addr 1」のIPアドレスを有するIoTデバイス10には、タイマ値「T1」が設定される。死活監視受信タイマ22は、IoTデバイス10からのデータ受信時に、このIoTデバイス10に対応するタイマをリセットし、時間経過デクリメントを行う。或いは、死活監視受信タイマ22は、IoTデバイス10からのデータ受信時に、このIoTデバイス10に対応するタイマを0リセットし、インクリメントする。

0027

死活監視受信量管理部23は、死活監視時間管理部21による設定内容を基に、単位時間あたりのIoTデバイス10による死活監視メッセージの受信予定数を取得し、管理する。死活監視時間管理部21が、各IoTデバイスに対して、死活監視メッセージのIoTデバイス収容GW20に対する送信時間を設定するため、死活監視受信量管理部23は、この設定内容を基に、単位時間ごとの死活監視メッセージの受信予定数を管理する。

0028

図5は、死活監視受信量管理部23による死活監視メッセージの受信予定数の管理を説明する図である。図5の表T2に示すように、死活監視受信量管理部23は、単位時間(例えば10分)と、受信予定の死活監視メッセージ数とを対応付けて管理する。死活監視受信量管理部23は、時刻A、時刻B、時刻Cのそれぞれの単位時間ごとに、受信予定の死活監視メッセージ数「5」、「1」、「22」を求めて、各時刻に対応付ける。

0029

そして、死活監視時間管理部21は、死活監視受信量管理部23が取得した単位時間あたりの死活監視メッセージの受信予定数が、所定の受信許容数を超えた場合、いずれかのIoTデバイス10の死活監視メッセージの送信時間を変更する。所定の受信許容数は、IoTデバイス収容GW20において死活監視用に振り分けられたリソース等に対応させて、あらかじめ設定されている。所定の受信許容数は、例えば1000である。

0030

例えば、単位時間は、IoTデバイス10によらず、あらかじめ定義されており、10分などである。単位時間が10分である場合であって、次の単位時間が「9:00」から「9:10」である場合を例に説明する。「9:00」から「9:10」までに受信する予定の死活監視メッセージ数が受信許容数を超えた場合、死活監視受信量管理部23は、さらに次の単位時間である「9:10」から「9:20」までに受信する予定の死活監視メッセージ数を求める。「9:10」から「9:20」までに受信する予定の死活監視メッセージ数が受信許容数以下となる場合には、死活監視時間管理部21は、受信許容数を超えたIoTデバイス10について、次の死活監視メッセージの送信時刻を「9:10」から「9:20」に変更する。

0031

一方、「9:10」から「9:20」までに受信する予定の死活監視メッセージ数が、受信許容数を超えた場合には、死活監視受信量管理部23は、さらに次の単位時間である「9:20」から「9:30」までに受信する予定の死活監視メッセージ数を求める。この「9:20」から「9:30」までに受信する予定の死活監視メッセージ数が許容数以下となる場合には、死活監視時間管理部21は、受信許容数を超えたIoTデバイス10について、次の死活監視メッセージの送信時刻を「9:10」から「9:20」に変更する。

0032

このように、単位時間あたりの死活監視メッセージの受信予定数が所定の受信許容数を超えた場合、死活監視受信量管理部23は、以降の単位時間ごとに、IoTデバイス10による死活監視メッセージの受信予定数を取得する。そして、死活監視時間管理部21は、死活監視受信量管理部23が取得した死活監視メッセージの受信予定数が、受信許容数以下となる単位時間に対応させて、いずれかのIoTデバイスの死活監視メッセージの送信時間を変更する。

0033

通信部24は、IoTデバイス10との間で通信を行う。通信部24は、IoTデバイス10から、センサ11が検出したデータまたは死活監視メッセージを受信する。通信部24は、IoTデバイス10に確認応答を送信する。確認応答は、死活監視時間管理部21が設定または変更した死活監視メッセージの送信時間を含む。

0034

[死活監視処理の処理手順]
次に、図1に示す通信システムにおける通信処理のうち、死活監視処理の処理手順について説明する。図6は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。

0035

IoTデバイス10は、データまたは死活監視メッセージをIoTデバイス収容GW20に送信する(ステップS1)。IoTデバイス10は、データ送信トリガ監視部15によるトリガ管理にしたがって、データをIoTデバイス収容GW20に送信する。または、IoTデバイス10は、死活監視タイマ13のタイムアップ時に、死活監視データをIoTデバイス収容GW20に送信する。

0036

IoTデバイス収容GW20は、データまたは死活監視メッセージを受信すると、このIoTデバイス10に対し、死活監視メッセージの送信時間を設定する死活監視メッセージの送信時間設定処理を行う(ステップS2)。IoTデバイス収容GW20は、設定した死活監視メッセージの送信時間を含めた確認応答を、IoTデバイス10に送信する(ステップS3)。IoTデバイス収容GW20は、死活監視メッセージの送信時間として、死活監視メッセージの前回送信時から次の送信までの期間(監視周期)Taを送信してもよいし、次の死活監視メッセージの送信時刻を送信してもよい。

0037

IoTデバイス10は、確認応答を受信すると、期間Ta経過時に死活監視メッセージをIoTデバイス収容GW20に送信する(ステップS4)。なお、IoTデバイス10は、死活監視メッセージの前回送信時から期間Taが経過する前に、データを送信する場合には、このデータ送信を死活監視としてもよい。

0038

[死活監視メッセージの送信時間設定処理の処理手順]
次に、図6に示す死活監視メッセージの送信時間設定処理(ステップS2)の処理手順について説明する。図7は、図6に示す死活監視メッセージの送信時間設定処理の処理手順を示すフローチャートである。

0039

まず、IoTデバイス収容GW20では、死活監視時間管理部21が、IoTデバイス10毎にあらかじめ設定された監視周期後の時刻を死活監視メッセージの送信時刻に設定する(ステップS10)。死活監視受信量管理部23が、死活監視メッセージの送信時刻における死活監視メッセージの受信予定数を取得する(ステップS11)。そして、死活監視時間管理部21は、ステップS11において取得した受信予定数が所定の受信許容数を超えているか否かを判定する(ステップS12)。

0040

死活監視時間管理部21は、ステップS11において取得した受信予定数が所定の受信許容数以下であると判定した場合(ステップS12:No)について説明する。この場合、死活監視時間管理部21は、死活監視メッセージの送信時間を、この死活監視受信量管理部23が取得した死活監視メッセージの受信予定数が受信許容数以下となる単位時間に対応する時間に設定する(ステップS14)。そして、死活監視受信量管理部23は、この単位時間の死活監視メッセージの受信予定数をインクリメントする。

0041

一方、死活監視時間管理部21が、ステップS11において取得した受信予定数が所定の受信許容数を超えていると判定した場合(ステップS12:Yes)について説明する。この場合、死活監視受信量管理部23は、死活監視メッセージの送信時刻にTを加えたものを死活監視メッセージの送信時刻とする(ステップS13)。そして、ステップS11に戻り、活監視受信量管理部23が、死活監視メッセージの送信時刻における死活監視メッセージの受信予定数を取得する。そして、死活監視時間管理部21は、ステップS13において取得した受信予定数が所定の許容数以下であると判定した場合(ステップS12:No)、死活監視メッセージの送信時間を、この死活監視受信量管理部23が取得した死活監視メッセージの受信予定数が受信許容数以下となる時間に設定する(ステップS14)。そして、死活監視受信量管理部23は、この単位時間の死活監視メッセージの受信予定数をインクリメントする。

0042

IoTデバイス収容GW20は、単位時間ずつ時間をずらし、死活監視メッセージの受信予定数を取得し、取得した受信予定数が所定の受信許容数以下となる時間に対応させて、IoTデバイス10の死活監視メッセージの送信時間を変更する。死活監視メッセージ送信時間の変更対象となるIoTデバイス10は、ステップS11で取得した死活監視メッセージの受信予定数のうち、受信許容数を超えたメッセージの送信元のIoTデバイス10である。

0043

[実施の形態1の効果]
このように、本実施の形態1では、IoTデバイス10は、指示された死活監視メッセージの送信時までの期間Tの間、信号受信がないため、通信機能をスリープ状態にすることができる。言い換えると、IoTデバイス10は、死活監視メッセージの送信タイミングを保持するため、常にIoTデバイス収容GW20からのメッセージを受信できる状態にしておく必要がなく、スリープが可能になる。

0044

また、本実施の形態1では、IoTデバイス収容GW20が、IoTデバイス10毎に監視周期を設定する。すなわち、IoTデバイス収容GW20は、IoTデバイス10それぞれについて、死活監視メッセージの送信時間を、自由に設定することができる。言い換えると、IoTデバイス収容GW20は、死活監視メッセージの受信タイミング重複しないように、IoTデバイス10それぞれについて、死活監視メッセージの送信タイミングを分散させることができる。

0045

さらに、本実施の形態1では、IoTデバイス収容GW20は、単位時間ごとの死活監視メッセージの受信予定数を確認する。そして、IoTデバイス収容GW20は、IoTデバイス収容GW20が許容可能である数を超過した場合には、超過したメッセージの送信元のIoTデバイス10について、死活監視メッセージの送信時間を後の時間に変更する。

0046

このため、本実施の形態1では、IoTデバイス収容GW20の許容量を超えて死活監視メッセージが送信されることがないため、IoTデバイス収容GW20への死活監視メッセージの集中を防ぐことができる。したがって、本実施の形態1によれば、死活監視によるIoTデバイス収容GW20の負荷を分散させることができ、死活監視によるIoTデバイス収容GW20の負荷の軽減を可能にする。

0047

なお、本実施の形態1では、IoTデバイス収容GW20は、IoTデバイス収容GW20が許容可能である数を超過した場合には、超過したメッセージの送信元のIoTデバイス10について、死活監視メッセージの送信時間を前の時間に変更してもよい。

0048

[死活監視処理の処理手順の一例]
次に、図1に示す通信システムにおける死活監視処理の一例について説明する。図8は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。図8では、IoTデバイス10がデータメッセージをIoTデバイス収容GW20に送信した場合の処理について説明する。

0049

IoTデバイス10は、データ送信トリガ監視部15によるトリガ管理にしたがって、スリープを解除し(ステップS21)、データメッセージをIoTデバイス収容GW20に送信する(ステップS22)。

0050

IoTデバイス収容GW20は、データメッセージを受信すると、ステップS2と同様に、このIoTデバイス10に対し、死活監視メッセージの送信時間を設定する(ステップS23)。IoTデバイス収容GW20は、設定した死活監視メッセージの送信時間を含めた確認応答を、IoTデバイス10に送信する(ステップS24)。

0051

IoTデバイス10は、確認応答を受信するとスリープし(ステップS25)、期間Ta経過時に、スリープを解除し(ステップS26)、死活監視メッセージをIoTデバイス収容GW20に送信する(ステップS27)。

0052

IoTデバイス収容GW20は、死活監視メッセージを受信すると、ステップS2と同様に、このIoTデバイス10に対し、死活監視メッセージの送信時間を設定する(ステップS28)。IoTデバイス収容GW20は、設定した死活監視メッセージの送信時間を含めた確認応答を、IoTデバイス10に送信する(ステップS29)。

0053

IoTデバイス10は、確認応答を受信するとスリープする(ステップS30)。IoTデバイス10は、死活監視メッセージの前回送信時から設定期間が経過する前に、データを送信する場合には、スリープを解除して(ステップS31)、データメッセージを死活監視として送信する(ステップS32)。

0054

IoTデバイス収容GW20は、データメッセージを受信すると、ステップS2と同様に、このIoTデバイス10に対し、死活監視メッセージの送信時間を設定する(ステップS33)。IoTデバイス収容GW20は、設定した死活監視メッセージの送信時間を含めた確認応答を、IoTデバイス10に送信する(ステップS34)。IoTデバイス10は、確認応答を受信するとスリープする(ステップS35)。

0055

[死活監視処理の処理手順の他の例]
次に、図1に示す通信システムにおける死活監視処理の他の例について説明する。図9は、実施の形態1に係る死活監視処理の処理手順の一例を示すシーケンス図である。図9では、IoTデバイス10が死活監視メッセージをIoTデバイス収容GW20に送信した場合の処理について説明する。

0056

IoTデバイス10は、死活監視タイマ13のタイマアップに応じてスリープを解除し(ステップS41)、死活監視メッセージをIoTデバイス収容GW20に送信する(ステップS42)。

0057

IoTデバイス収容GW20は、データメッセージを受信すると、ステップS2と同様に、このIoTデバイス10に対し、死活監視メッセージの送信時間を設定し(ステップS43)、設定した死活監視メッセージの送信時間を含めた確認応答を、IoTデバイス10に送信する(ステップS44)。図8に示すステップS45〜ステップS55は、図7に示すステップS25〜ステップS35と同じ処理である。

0058

[実施の形態2]
次に、実施の形態2について説明する。図10は、実施の形態2に係るIoTデバイス収容GWの構成の一例を示す図である。実施の形態2に係る通信システムは、IoTデバイス収容GW20に代えて、図10に示すIoTデバイス収容GW220を有する。

0059

[IoTデバイス収容GWの構成]
図10に示すように、IoTデバイス収容GW220は、IoTデバイス収容GW20と比して、トランザクション管理部225(第2の取得部)及び許容数設定部226(第2の設定部)をさらに有する。

0060

トランザクション管理部225は、単位時間ごとに、IoTデバイス10のトランザクション数の履歴を取得する。トランザクション数の履歴は、単位時間ごとのIoTデバイス収容GW220における送受信メッセージ数の履歴である。

0061

図11は、トランザクション管理部225が取得するトランザクション数の履歴を説明する図である。図11の表T3に示すように、トランザクション管理部225は、単位時間(例えば10分)毎に、単位時間とトランザクション数とを管理する。トランザクション管理部225は、時刻X、時刻Y、時刻Zのそれぞれの単位時間に対応する時刻ごとに、トランザクション数「1345」、「5123」、「2123」を取得し、各時刻に対応付ける。

0062

許容数設定部226は、トランザクション管理部225が取得したトランザクション数の履歴を基に、次の単位時間におけるトランザクション数を予測する。許容数設定部226は、日ごと或いは週ごとのトランザクション数の履歴から、受信許容数の設定対象となる次の単位時間におけるトランザクション数を予測する。

0063

そして、許容数設定部226は、IoTデバイス収容GW220における単位時間あたりのトランザクション数の最大許容数と、予測したトランザクション数とを基に、次の単位時間における死活監視メッセージの受信許容数を設定する。許容数設定部226は、例えば、(1)式を用いて、次の単位時間における死活監視メッセージの受信許容数を求める。

0064

P=(Dm−Df)×Rt ・・・(1)

0065

Pは、次の単位時間における死活監視メッセージの受信許容数である。Dmは、IoTデバイス収容GW220における単位時間あたりのトランザクション数の最大許容数である。Dfは、許容数設定部226が予測したトランザクション数である。Rtは、IoTデバイス収容GW220において、死活監視に割り当てられるリソースの割合である。Dm及びRtの値は、あらかじめ設定され、変更も可能である。例えば、Dmが10000であり、Dfが8000であり、Rtが0.1である場合、Pは、200となる。

0066

許容数設定部226は、以降の単位時間における死活監視メッセージの受信許容数を、単位時間ごとに求めてもよい。図12は、許容数設定部226が求めた単位時間における死活監視メッセージの受信許容数を示す図である。図12の表T6に示すように、許容数設定部226は、単位時間(例えば10分)毎に、単位時間における死活監視メッセージの受信許容数を求める。許容数設定部226は、時刻A、時刻B、時刻Cのそれぞれの単位時間に対応する時刻ごとに、死活監視メッセージの受信許容数「200」、「100」、「100」を求める。

0067

許容数設定部226は、各単位時間の死活監視メッセージの受信許容数を、死活監視時間管理部21に出力する。死活監視時間管理部21は、許容数設定部226から入力された各単位時間の死活監視メッセージの受信許容数を用いて、IoTデバイス10の死活監視メッセージの送信時間の設定または変更を行う。言い換えると、死活監視時間管理部21は、受信予定の死活監視メッセージ数(テーブルT6中列参照)と、許容数設定部226が設定した各単位時間の死活監視メッセージの受信許容数(テーブルT6左列参照)とを比較して、IoTデバイス10の死活監視メッセージの送信時間の設定または変更を行う。

0068

[死活監視処理の処理手順]
次に、実施の形態2に係る通信システムにおける死活監視処理の処理手順について説明する。図13は、実施の形態2に係る死活監視処理の処理手順の一例を示すシーケンス図である。

0069

IoTデバイス10は、データまたは死活監視メッセージをIoTデバイス収容GW20に送信する(ステップS61)。IoTデバイス収容GW220は、単位時間における死活監視メッセージの受信許容数を設定する許容数設定処理を行う(ステップS62)。

0070

IoTデバイス収容GW20は、ステップS2と同様の処理を行い、IoTデバイス10に対し、死活監視メッセージの送信時間を設定する死活監視メッセージの送信時間設定処理を行う(ステップS63)。死活監視メッセージの送信時間設定処理では、許容数設定処理において設定された死活監視メッセージの受信許容数を用いる。図13に示すステップS64及びステップS65は、図6に示すステップS3及びステップS4と同じ処理である。

0071

[許容数設定処理の処理手順]
次に、図13に示す許容数設定処理(ステップS62)の処理手順について説明する。図14は、図13に示す許容数設定処理の処理手順を示すフローチャートである。

0072

図14に示すように、IoTデバイス収容GW220では、許容数設定部226が、トランザクション管理部225からトランザクション数の履歴を取得する(ステップS71)。そして、許容数設定部226は、取得したトランザクション数の履歴を基に、次の単位時間に対応する時間T経過時のトランザクション数を予測する(ステップS72)。そして、許容数設定部226は、IoTデバイス収容GW220における単位時間あたりの最大性能、すなわち、単位時間あたりのトランザクション数の最大許容数を取得する(ステップS73)。そして、許容数設定部226は、例えば(1)式を用いて、次の単位時間における死活監視メッセージの受信許容数を計算し(ステップS74)、計算した受信許容数を設定する(ステップS75)。

0073

[実施の形態2の効果]
このように、実施の形態2では、IoTデバイス収容GW220が、トランザクション数の履歴を基に、許容数設定対象の単位時間におけるトランザクション数を予測し、単位時間における死活監視メッセージの受信許容数を設定する。言い換えると、IoTデバイス収容GW220は、日ごと或いは週ごとのトランザクション数の履歴から、単位時間あたりのシステムの負荷状況を予測し、この負荷状況に応じて、死活監視メッセージの受信許容数を調整する。したがって、実施の形態2ではよれば、システムの負荷状況に応じて、死活監視メッセージの受信許容数を増減することによって、死活監視によるIoTデバイス収容GW20の負荷を分散させ、死活監視によるIoTデバイス収容GW20の負荷の軽減を可能にする。

0074

[システム構成等]
図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部又は任意の一部が、CPU(Central Processing Unit)及び当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

0075

また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行なうこともでき、あるいは、手動的に行なわれるものとして説明した処理の全部又は一部を公知の方法で自動的に行なうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

0076

[プログラム]
図15は、プログラムが実行されることにより、実施の形態1,2の通信システムを構成する装置が実現されるコンピュータの一例を示す図である。コンピュータ1000は、例えば、メモリ1010、CPU1020を有する。また、コンピュータ1000は、ハードディスクドライブインタフェース1030、ディスクドライブインタフェース1040、シリアルポートインタフェース1050、ビデオアダプタ1060、ネットワークインタフェース1070を有する。これらの各部は、バス1080によって接続される。

0077

メモリ1010は、ROM(Read Only Memory)1011及びRAM(Random Access Memory)1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。例えば磁気ディスク光ディスク等の着脱可能な記憶媒体が、ディスクドライブ1100に挿入される。シリアルポートインタフェース1050は、例えばマウス1110、キーボード1120に接続される。ビデオアダプタ1060は、例えばディスプレイ1130に接続される。

0078

ハードディスクドライブ1090は、例えば、OS(Operating System)1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、実施の形態1,2の通信システムを構成する装置の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール1093として実装される。プログラムモジュール1093は、例えばハードディスクドライブ1090に記憶される。例えば、実施の形態1,2の通信システムを構成する装置における機能構成と同様の処理を実行するためのプログラムモジュール1093が、ハードディスクドライブ1090に記憶される。なお、ハードディスクドライブ1090は、SSD(Solid State Drive)により代替されてもよい。

0079

また、上述した実施形態の処理で用いられる設定データは、プログラムデータ1094として、例えばメモリ1010やハードディスクドライブ1090に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1090に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出して実行する。

0080

なお、プログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1090に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ1100等を介してCPU1020によって読み出されてもよい。あるいは、プログラムモジュール1093及びプログラムデータ1094は、ネットワーク(LAN、WAN(Wide Area Network)等)を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール1093及びプログラムデータ1094は、他のコンピュータから、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。

0081

以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例及び運用技術等は全て本発明の範疇に含まれる。

0082

10IoTデバイス
11センサ
12再送タイマ
13死活監視タイマ
14,24通信部
15データ送信トリガ監視部
16スリープ管理部
23 死活監視受信量管理部
20,220 IoTデバイス収容GW
21 死活監視時間管理部
225トランザクション管理部
226許容数設定部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ