JP2020024742A - 中継装置及びプログラム - Google Patents

Abstract

【課題】ＩｏＴゲートウェイのような複数の通信デバイスの通信を中継するゲートウェイであって、状況に応じて適切な処理を実行可能なゲートウェイを提供することが望ましい。【解決手段】通信デバイスと通信接続を確立する接続確立部と、接続確立部が通信デバイスと確立した通信接続の通信方式又は通信デバイスのデバイスタイプに基づいて、通信デバイスと通信デバイスの通信相手との通信を中継するときに用いる通信回線として、第１の通信回線又は第１の通信回線よりも通信容量が多い第２の通信回線を選択する回線選択部と、回線選択部によって選択された通信回線を介して、通信デバイスと通信相手との通信を中継する通信中継部とを備える中継装置を提供する。【選択図】図１

Description

本発明は、中継装置及びプログラムに関する。

ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）デバイスと通信接続を確立して、ＩｏＴデバイスの通信を中継するＩｏＴゲートウェイが知られていた（例えば、特許文献１参照）。
［先行技術文献］
［特許文献］
［特許文献１］特開２０１８−０６０３８０号公報

ＩｏＴゲートウェイのような複数の通信デバイスの通信を中継するゲートウェイであって、状況に応じて適切な処理を実行可能なゲートウェイを提供することが望ましい。

本発明の第１の態様によれば、中継装置が提供される。中継装置は、通信デバイスと通信接続を確立する接続確立部を備えてよい。中継装置は、接続確立部が通信デバイスと確立した通信接続の通信方式又は通信デバイスのデバイスタイプに基づいて、通信デバイスと通信デバイスの通信相手との通信を中継するときに用いる通信回線として、第１の通信回線又は第１の通信回線よりも通信容量が多い第２の通信回線を選択する回線選択部を備えてよい。中継装置は、回線選択部によって選択された通信回線を介して、通信デバイスと通信相手との通信を中継する通信中継部を備えてよい。

上記接続確立部は、上記通信デバイスと無線通信接続を確立してよく、上記回線選択部は、上記接続確立部が上記通信デバイスと確立した無線通信接続の通信方式又は上記通信デバイスのデバイスタイプに基づいて、上記通信デバイスと上記通信デバイスの通信相手との通信を中継するときに用いる無線通信回線として、第１の無線通信回線又は上記第１の無線通信回線よりも通信容量が多い第２の無線通信回線を選択してよい。上記第１の通信回線は、ＮＢ−ＩｏＴ、ＬｏＲａ、及びＳｉｇｆｏｘの少なくともいずれかであってよく、上記第２の通信回線は、ＬＴＥであってよい。上記回線選択部は、上記通信方式が第１の通信方式である場合、上記第１の通信回線を選択し、上記通信方式が第２の通信方式である場合、上記第２の通信回線を選択してよい。上記第１の通信方式は、ＷｉＦｉ又はＢｌｕｅｔｏｏｔｈ（登録商標）であってよく、上記第２の通信方式は、Ｚ−Ｗａｖｅ（登録商標）又はＺｉｇｂｅｅ（登録商標）であってよい。

上記回線選択部は、上記通信デバイスのデバイスタイプが第１のデバイスタイプである場合、上記第１の通信回線を選択し、上記通信デバイスのデバイスタイプが第２のデバイスタイプである場合、上記第２の通信回線を選択してよい。上記第１のデバイスタイプのデバイスは、数値データ又はテキストデータを送信するデバイスであってよく、上記第２のデバイスタイプのデバイスは、画像データ又は音声データを送信するデバイスであってよい。上記通信中継部は、上記接続確立部によって通信接続が確立されている全ての通信デバイスに対して、上記第１の通信回線が選択されている場合、上記第２の通信回線をスリープさせてよい。上記通信中継部が、上記第１の通信回線を用いて上記通信デバイスの通信を中継している間に、上記通信デバイスが送受信するデータを監視するデータ監視部と、上記通信デバイスが送受信するデータが予め定められた条件を満たす場合に、上記通信中継部が用いる通信回線を、上記第１の通信回線から上記第２の通信回線に切り替えさせる切替制御部とを備えてよい。上記切替制御部は、上記通信デバイスが受信するデータの種類が予め定められた種類である場合に、上記通信中継部が用いる通信回線を、上記第１の通信回線から上記第２の通信回線に切り替えさせてよい。

本発明の第２の態様によれば、中継装置が提供される。中継装置は、第１の無線通信方式で通信接続をしている第１の無線通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換して送信する第１中継部を備えてよい。中継装置は、第２の無線通信方式で通信接続をしている第２の無線通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換して送信する第２中継部を備えてよい。中継装置は、第１の無線通信方式と第２の無線通信方式との間でプロトコル変換を実行し、第１の無線通信デバイスと第２の無線通信デバイスとの間の通信を中継する第３中継部を備えてよい。

上記第１の無線通信方式は、Ｂｌｕｅｔｏｏｔｈであってよく、上記第２の無線通信方式は、Ｚ−Ｗａｖｅ又はＺｉｇｂｅｅであってよい。上記中継装置は、上記第１の無線通信方式で通信接続をしている上記第１の無線通信デバイスから受信したデータに基づいて、上記中継装置に対する制御を実行する実行部を備えてよい。上記第３中継部は、上記第１の無線通信デバイスから受信したデータを、複数の上記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークに送信してよい。上記第３中継部は、上記第２無線通信デバイスネットワーク内の上記第２の無線通信デバイスを送信元とするＢｌｕｅｔｏｏｔｈビーコンを、上記第１の無線通信デバイスに送信してよい。上記第３中継部は、上記第１の無線通信デバイスから受信したＢｌｕｅｔｏｏｔｈビーコンをプロトコル変換して、上記第２無線通信デバイスネットワーク内の少なくとも１つの上記第２の無線通信デバイスに送信してよい。

上記第３中継部は、上記第２の無線通信デバイスから受信したデータを、複数の第１の無線通信デバイスによって構成される第１無線通信デバイスネットワークに送信してよい。上記第３中継部は、複数の上記第１の無線通信デバイスによって構成される第１無線通信デバイスネットワークと、複数の上記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークとの間の通信を中継してよい。上記第３中継部は、他の中継装置と、上記第１の無線通信方式により通信接続を確立し、当該通信接続を介して、複数の上記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークと、上記他の中継装置に接続された複数の上記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークとの間の通信を中継してよい。

本発明の第３の態様によれば、コンピュータを、上記中継装置として機能させるためのプログラムが提供される。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

中継装置１００の通信環境の一例を概略的に示す。 中継装置１００による処理の流れの一例を概略的に示す。 中継装置１００による処理の流れの一例を概略的に示す。 中継装置１００による処理の流れの一例を概略的に示す。 中継装置１００の機能構成の一例を概略的に示す。 中継装置１００の通信環境の他の一例を概略的に示す。 中継装置１００の構成の一例を概略的に示す。 中継装置１００の通信環境の一例を概略的に示す。 中継装置１００の通信環境の一例を概略的に示す。 中継装置１００の構成の一例を概略的に示す。 中継装置１００の通信環境の一例を概略的に示す。 中継装置１００の通信環境の一例を概略的に示す。 中継装置１００の通信環境の一例を概略的に示す。 中継装置１００として機能するコンピュータ１０００のハードウェア構成の一例を概略的に示す。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、中継装置１００の通信環境の一例を概略的に示す。本実施形態に係る中継装置１００は、通信デバイスと通信接続を確立し、通信回線３０と、通信回線３０よりも通信容量が多い通信回線４０とのいずれかを用いて、通信デバイスとクラウド２０との通信を中継する。

図１では、中継装置１００がいわゆるＩｏＴゲートウェイであって、ＩｏＴデバイス２００の通信を中継する場合を例に挙げて説明する。なお、これに限らず、中継装置１００は、任意の通信デバイスと無線通信接続を確立して、当該通信デバイスの通信を中継するゲートウェイであってもよい。また、中継装置１００は、任意の通信デバイスと有線通信接続を確立して、当該通信デバイスの通信を中継するゲートウェイであってもよい。通信回線３０及び通信回線４０は、無線通信回線であってよい。また、通信回線３０及び通信回線４０は、有線通信回線であってもよい。ここでは、通信回線３０及び通信回線４０が無線通信回線である場合を主に例に挙げて説明する。

ＩｏＴデバイス２００の例としては、温度センサ、ドアセンサ、照明ＬＥＤ、体組成計、リストバンド、スピーカ、セキュリティカメラ、スマートメータ、気象観測機器、及び農業機器等が挙げられる。通信回線３０は、例えば、ＩｏＴ向け通信方式に準拠した通信回線であってよい。通信回線３０の例としては、ＮＢ−ＩｏＴ（Ｎａｒｒｏｗ Ｂａｎｄ−ＩｏＴ）、ＬｏＲａ（Ｌｏｎｇ Ｒａｎｇｅ）、及びＳｉｇｆｏｘ等が挙げられる。通信回線４０は、例えば、いわゆる移動体通信回線であってよい。通信回線４０の例としては、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）回線が挙げられる。

ＩｏＴ向け通信方式では、通信速度が低速度で、送受信データのデータ容量も限られる。一方、例えば、ＬＴＥ回線は、通信速度も高速で、大容量通信も可能だが、温度センサ及びドアセンサ等によるセンシングデータのような非常に小さなデータでは、ＬＴＥ回線の能力を活かせておらず、通信設備のリソースに無駄が発生し、回線リソースを有効に活用できない場合がある。ＩｏＴ向けには、ＩＰ通信の環境（ＷｉＦｉ（登録商標）（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）経由でインターネットに接続するような環境）を必ずしも利用できるわけではなく、移動体通信回線を利用したクラウド接続は有効な手段の一つである。

本実施形態に係る中継装置１００は、小容量向けの通信回線３０と、大容量向けの通信回線４０とをサポートし、状況に応じて適切に回線を切り替える機能を有する。中継装置１００は、例えば、ＩｏＴデバイス２００との通信の通信方式に基づいて、通信回線３０又は通信回線４０を選択し、選択した通信回線を介してＩｏＴデバイス２００の通信を中継する。例えば、中継装置１００は、通信方式がＺ−Ｗａｖｅ又はＺｉｇｂｅｅである場合、通信回線３０を選択する。また、例えば、中継装置１００は、通信方式がＷｉＦｉ又はＢｌｕｅｔｏｏｔｈである場合、通信回線４０を選択する。これにより、ＩｏＴデバイス２００と中継装置１００との間の通信の通信容量が小さい場合には、小容量向けの通信回線３０を選択し、ＩｏＴデバイス２００と中継装置１００との間の通信の通信容量が大きい場合には、大容量向けの通信回線３０を選択することができる。

また、中継装置１００は、例えば、ＩｏＴデバイス２００のデバイスタイプに基づいて、通信回線３０又は通信回線４０を選択し、選択した通信回線を介してＩｏＴデバイス２００の通信を中継する。例えば、中継装置１００は、ＩｏＴデバイス２００が、温度センサ及びドアセンサ等のセンサのように、通常送信するデータが比較的小容量のデバイスである場合、通信回線３０を選択する。また、例えば、中継装置１００は、ＩｏＴデバイス２００が、セキュリティカメラのように、通常送信するデータが比較的大容量のデバイスである場合、通信回線４０を選択する。これにより、ＩｏＴデバイス２００が送信するデータに適した通信回線を用いて、ＩｏＴデバイス２００の通信を中継することができる。

また、本実施形態に係る中継装置１００は、通信回線３０を用いてＩｏＴデバイス２００の通信を中継している間に、ＩｏＴデバイス２００が送受信するデータを監視して、当該データが予め定められた条件を満たす場合に、使用する通信回線を通信回線３０から通信回線４０に切り替えてよい。例えば、中継装置１００は、ＩｏＴデバイス２００が送受信するデータの種類が、ＦＯＴＡ（Ｆｉｒｍｗａｒｅ Ｏｎ−Ｔｈｅ−Ａｉｒ）データ等の予め定められた種類である場合に、使用する通信回線を通信回線３０から通信回線４０に切り替える。

例えば、ＩｏＴデバイス２００が温度センサである場合、温度センサが通常送信するデータは、検知した温度を示すセンシングデータであり、データ容量が少ないため、通信回線３０を使用していても問題ない。しかし、温度センサがＦＯＴＡデータを受信する場合、ＦＯＴＡデータは比較的容量が大きいので、通信回線３０を使用していた場合、多くの時間を要してしまう場合がある。これに対して、本実施形態に係る中継装置１００によれば、ＦＯＴＡデータのように比較的容量が大きいデータを送受信する場合には、使用する通信回線が通信回線３０から通信回線４０に切り替わるので、このような事態の発生を防止することができる。

中継装置１００は、例えば、常時利用しない通信回線については、利用しない時間帯はスリープしてよい。具体例として、中継装置１００は、原則としては通信回線３０をアクティブにしておき、必要に応じて通信回線４０をアクティブにし、通信回線４０を使用する必要がなくなった場合、通信回線４０をスリープさせる。これにより、電波の無駄を避けることができる。

図２は、中継装置１００による処理の流れの一例を概略的に示す。ここでは、ＩｏＴデバイス２００との間で確立した通信接続の通信方式に基づいて通信回線を選択する処理の流れを説明する。図２に示す各処理は、中継装置１００が備える制御部が主体となって実行される。

ステップ（ステップをＳと省略して記載する場合がある。）１０２では、ＩｏＴデバイス２００とのペアリングを確立する。Ｓ１０４では、Ｓ１０２において確立した通信接続の通信方式を取得する。

Ｓ１０６では、Ｓ１０４において取得した通信方式が、第１の通信方式であるか否かを判定する。第１の通信方式の例としては、Ｚ−Ｗａｖｅ及びＺｉｇｂｅｅ等が挙げられる。第１の通信方式であると判定した場合、Ｓ１０８に進む。通信方式が、第１の通信方式ではなく、例えば、ＷｉＦｉ及びＢｌｕｅｔｏｏｔｈ等である場合、Ｓ１１０に進む。ＷｉＦｉ及びＢｌｕｅｔｏｏｔｈは、第２の通信方式の一例であってよい。Ｓ１０８では、通信回線３０を選択する。Ｓ１１０では、通信回線４０を選択する。そして処理を終了する。

図３は、中継装置１００による処理の流れの一例を概略的に示す。ここでは、デバイスタイプの取得が可能な通信方式によって通信接続を確立したＩｏＴデバイス２００のデバイスタイプに基づいて、通信回線を選択する処理の流れを説明する。デバイスタイプの取得が可能な通信方式の例としては、Ｚ−Ｗａｖｅ、Ｚｉｇｂｅｅ、及びＢｌｕｅｔｏｏｔｈ等が挙げられる図３に示す各処理は、中継装置１００が備える制御部が主体となって実行される。

Ｓ２０２では、ＩｏＴデバイス２００と通信接続を確立する。Ｓ２０４では、Ｓ２０２において通信接続を確立したＩｏＴデバイス２００のデバイスタイプを取得する。ＩｏＴデバイス２００は、例えば、ペアリング時にＩｏＴデバイス２００から受信するデータを参照することによって、ＩｏＴデバイス２００のデバイスタイプを取得する。具体例として、中継装置１００は、ペアリングＩＤとデバイスタイプとを対応付けた対応付けデータを予め格納しておき、当該対応付けデータを参照することによって、ＩｏＴデバイス２００のデバイスタイプを取得してよい。

Ｓ２０６では、Ｓ２０４において取得したデバイスタイプが、第１のデバイスタイプであるか否かを判定する。第１のデバイスタイプの例としては、センシングデータを送信する温度センサ及びドアセンサ等のセンサが挙げられる。第１のデバイスタイプであると判定した場合、Ｓ２０８に進む。第１のデバイスタイプではなく、例えば、セキュリティカメラ等の画像データ及び音声データを送信するデバイスである場合、Ｓ２１０に進む。セキュリティカメラ等の画像データ及び音声データを送信するデバイスは、第２のデバイスタイプの一例であってよい。Ｓ２０８では、通信回線３０を選択する。Ｓ２１０では、通信回線４０を選択する。そして処理を終了する。

図４は、中継装置１００による処理の流れの一例を概略的に示す。ここでは、通信回線３０を用いてＩｏＴデバイス２００の通信を中継している場合に、中継装置１００が実行する処理について説明する。図４に示す各処理は、中継装置１００が備える制御部が主体となって実行される。

Ｓ３０２では、中継データを参照する。中継装置１００は、例えば、ＩｏＴデバイス２００から受信して、プロトコル変換をして、通信回線３０を介してクラウド２０に奏しするデータ、及び、クラウド２０側から通信回線３０を介して受信して、プロトコル変換をしてＩｏＴデバイスに送信するデータを参照する。なお、中継装置１００は、ＩｏＴデバイス２００から受信するデータ及びＩｏＴデバイス２００に対して送信するデータをミラーリングして取得した中継データを参照してもよい。

Ｓ３０４では、Ｓ３０２において取得した中継データから、ＩｏＴデバイス２００が送受信しているデータが大容量データであるか否かを判定する。中継装置１００は、例えば、中継データを解析することによって、ＩｏＴデバイス２００が送受信しているデータが、ＦＯＴＡデータ、画像データ、及び音声データのような大容量データであるか、数値データ及びテキストデータ等のセンシングデータのような小容量データであるかを判定してよい。また、例えば、ＩｏＴデバイス２００との通信方式がＺ−Ｗａｖｅ及びＺｉｇｂｅｅである場合、データに含まれる、何のデータを送信しているのかを示すＩＤを参照して、当該ＩＤが、例えば、ＦＯＴＡデータのような大容量データを示す場合には、大容量データであると判定する。

大容量データであると判定した場合、Ｓ３０６に進む。Ｓ３０６では、通信回線を通信回線３０から通信回線４０に切り替える。切替を実行しなかった場合（Ｓ３０８でＮＯ）、Ｓ３０２に戻り、切替を実行した場合（Ｓ３０８でＹＥＳ）、処理を終了する。

図５は、中継装置１００の機能構成の一例を概略的に示す。中継装置１００は、格納部１０２、接続確立部１０４、回線選択部１０６、通信中継部１０８、データ監視部１１０、及び切替制御部１１２を備える。なお、中継装置１００がこれらのすべての構成を備えることは必須とは限らない。

格納部１０２は、各種データを格納する。格納部１０２は、第１の通信方式及び第２の通信方式の情報を格納してよい。格納部１０２は、例えば、複数の通信方式のそれぞれが第１の通信方式であるか第２の通信方式であるかを示すデータを格納する。当該データは、例えば、中継装置１００のオペレータ等によって生成される。

また、格納部１０２は、第１のデバイスタイプ及び第２のデバイスタイプの情報を格納してよい。格納部１０２は、例えば、複数のデバイスタイプのそれぞれが第１のデバイスタイプであるか第２のデバイスタイプであるかを示すデータを格納する。当該データは、例えば、中継装置１００のオペレータ等によって生成される。また、格納部１０２は、ペアリングＩＤとデバイスタイプとを対応付けた対応付けデータを格納してよい。

接続確立部１０４は、通信デバイスと通信接続を確立する。接続確立部１０４は、例えば、ＩｏＴデバイス２００と通信接続を確立する。

回線選択部１０６は、接続確立部１０４が通信接続を確立した通信デバイスと、当該通信デバイスの通信相手との間の通信を中継するときに用いる通信回線として、通信回線３０又は通信回線４０を選択する。回線選択部１０６は、例えば、接続確立部１０４が通信デバイスと確立した通信接続の通信方式に基づいて、通信回線３０又は通信回線４０を選択する。具体例として、回線選択部１０６は、通信方式が第１の通信方式である場合、通信回線３０を選択し、通信方式が第１の通信方式でなく第２の通信方式である場合、通信回線４０を選択する。

また、回線選択部１０６は、例えば、接続確立部１０４が通信接続を確立した中継装置１００のデバイスタイプに基づいて、通信回線３０又は通信回線４０を選択する。具体例として、回線選択部１０６は、デバイスタイプが第１のデバイスタイプである場合、通信回線３０を選択し、デバイスタイプが第１のデバイスタイプでなく第２のデバイスタイプである場合、通信回線４０を選択する。

通信中継部１０８は、回線選択部１０６によって選択された通信回線を介して、通信デバイスと通信相手との通信を中継する。通信中継部１０８は、接続確立部１０４が通信接続を確立している全ての通信デバイスについて、通信回線３０が選択されていて、通信回線４０が選択されていない場合、通信回線４０をスリープさせてよい。

回線選択部１０６は、予め定められた条件に従って、通信回線４０をスリープさせるタイミングを制御してよい。例えば、回線選択部１０６は、夜間として予め定められた時間帯では、接続確立部１０４が通信接続を確立している全ての通信デバイスについて通信回線３０が選択されてから、予め定められた第１の時間が経過した後で、通信回線４０をスリープさせ、それ以外の時間帯では、第１の時間よりも長い第２の時間が経過した後で、通信回線４０をスリープさせる。これにより、夜間よりも通信頻度が高い昼間では、すぐに通信回線４０をスリープさせずに、適切な時間待機した後で、通信回線４０をスリープさせることができる。

データ監視部１１０は、回線選択部１０６によって通信回線３０が選択され、通信中継部１０８が通信回線３０を用いて通信デバイスの通信を中継している間に、通信デバイスが送受信するデータを監視する。データ監視部１１０は、常時データを監視してよく、また、予め定められたタイミングに従ってデータを監視してもよい。

切替制御部１１２は、通信デバイスが送受信するデータが予め定められた条件を満たす場合に、通信中継部１０８が用いる通信回線を、通信回線３０から通信回線４０に切り替えさせる。切替制御部１１２は、例えば、通信デバイスが送受信するデータの種類が予め定められた種類である場合に、通信中継部１０８が用いる通信回線を、通信回線３０から通信回線４０に切り替えさせる。

図６は、中継装置１００の通信環境の他の一例を概略的に示す。本例における中継装置１００は、第１の無線通信方式で通信接続をしている第１の通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換してクラウド２０に送信する中継部１２２と、第２の無線通信方式で通信接続をしている第２の通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換してクラウド２０に送信する中継部１２４とを備える。中継部１２２は、第１中継部の一例であり、中継部１２４は、第２中継部の一例である。第１の無線通信方式の例としては、Ｂｌｕｅｔｏｏｔｈが挙げられる。第２の無線通信方式の例としては、Ｚ−Ｗａｖｅ及びＺｉｇｂｅｅ等が挙げられる。

本例における中継装置１００は、さらに、第１の無線通信方式と第２の無線通信方式との間でプロトコル変換を実行し、第１の通信デバイスと第２の通信デバイスとの間の通信を中継する中継部１２６を備える。中継部１２６は、第３中継部の一例である。図６では、第１の無線通信方式がＢｌｕｅｔｏｏｔｈであり、第２の無線通信方式がＺ−Ｗａｖｅである場合を例に挙げて説明する。ＢＴ（ＢｌｕｅＴｏｏｔｈ）デバイス３００は、第１の通信デバイスの一例であり、Ｚ−Ｗａｖｅデバイス４００は、第２の通信デバイスの一例である。

既存のＩｏＴゲートウェイでは、ＢｌｕｅｔｏｏｔｈからＩＰ通信へのプロトコル変換、Ｚ−ＷａｖｅからＩＰ通信へのプロトコル変換、及びＺｉｇｂｅｅからＩＰ通信へのプロトコル変換をサポートしていたが、Ｚ−ＷａｖｅからＢｌｕｅｔｏｏｔｈへのプロトコル変換、及びＺｉｇｂｅｅからＢｌｕｅｔｏｏｔｈへのプロトコル変換はサポートされていなかった。本例における中継装置１００は、中継部１２６を備えることによってこれらをサポートすることができ、通信デバイスの新たな活用方法を可能にすることができる。

例えば、現状、Ｚｉｇｂｅｅ及びＺ−Ｗａｖｅ等のＩｏＴ無線通信規格は、スマートフォン、タブレット、及びＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）ではサポートされていないため、それらの機器とは直接やりとりはできない。現状はＩＰ通信に変換してからデータ変換することになる。Ｂｌｕｅｔｏｏｔｈは、２．４ＧＨｚ帯の周波数を主に利用する規格であるが、２．４ＧＨｚ帯の電波は、電波干渉が強く回り込み性が弱い（障害物に弱い）という特性がある。一方、Ｚ−Ｗａｖｅ等のＩｏＴ向け無線通信規格では、９００ＭＨｚ帯の周波数帯がよく利用され、電波干渉が少なく回り込み性が強いという電波特性をもっている。ＺｉｇｂｅｅやＺ−Ｗａｖｅ、Ｂｌｕｅｔｏｏｔｈは、それぞれの通信規格の特性に合わせたデバイスが市場には存在している。

本例の中継装置１００によれば、中継部１２６を備えることにより、複数の無線通信規格を共存させることで、新たなＩｏＴの有効な使い道を作り出すことができる。例えば、中継装置１００は、Ｚ−Ｗａｖｅ等のデバイスを中継装置１００内で仮想化し、バーチャルなＢｌｕｅｔｏｏｔｈデバイスを中継装置１００内で管理する。そして、このような仮想化デバイスをスマートフォン等のＢｌｕｅｔｏｏｔｈ対応デバイスとペアリングすることによって、Ｚ−Ｗａｖｅネットワーク内のＺ−Ｗａｖｅデバイスをスマートフォンから直接制御可能にできる。

本例のおける中継装置１００は、さらに、第１の無線通信方式で通信接続している第１の通信デバイスから受信したデータに基づいて、中継装置１００に対する制御を実行する実行部１２８をさらに備えてよい。既存のＩｏＴゲートウェイは、限られたボタン及びＬＥＤ等しか有しておらず、ＩｏＴゲートウェイに対するコンフィギュレーション等の操作においては、必ずしも直観的でわかりやすい操作性が提供されているわけではない。また、外部デバイスからＩｏＴゲートウェイを操作したり、データを登録したりすることを希望する場合には、Ｗｅｂ（クラウド）経由でＩＰ通信を利用して行うことができる機器は存在するが、ローカルエリアにＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷｉＦｉ等のＩＰ通信環境が求められることになる。ＩｏＴゲートウェイを利用する環境では、必ずしもＩＰ通信が可能な環境とは限らない。それに対して、本例における中継装置１００は実行部１２８を備えるので、例えば、Ｂｌｕｅｔｏｏｔｈを利用して、スマートフォン及びタブレット等から直接中継装置１００に対するコンフィギュレーションや、ＦＯＴＡ制御、及びＩｏＴデバイスのペアリング操作等を可能とすることで、直観的なＧＵＩを利用した形で、各種操作を可能とすることができる。

図７は、中継装置１００の構成の一例を概略的に示す。ここでは、中継装置１００がＺ−ＷａｖｅとＢｌｕｅｔｏｏｔｈとの間の通信を中継する例を主に挙げて説明するが、これに限らず、例えば、ＺｉｇｂｅｅとＢｌｕｅｔｏｏｔｈ等、他の組み合わせの通信を中継してもよい。

図７に示す例における中継装置１００は、Ｚ−Ｗａｖｅゲートウェイ１３２及びプロトコル変換部１３４を備える。Ｚ−Ｗａｖｅゲートウェイ１３２は、Ｚ−Ｗａｖｅネットワーク７０内の複数のＺ−Ｗａｖｅデバイスの通信を中継する。図７では、複数のＺ−Ｗａｖｅデバイスの例として、Ｚ−Ｗａｖｅデバイス４００、Ｚ−Ｗａｖｅデバイス４０１、Ｚ−Ｗａｖｅデバイス４０２、及びＺ−Ｗａｖｅデバイス４０３を挙げている。Ｚ−Ｗａｖｅデバイス４００、Ｚ−Ｗａｖｅデバイス４０１、Ｚ−Ｗａｖｅデバイス４０２、及びＺ−Ｗａｖｅデバイス４０３を区別せずに説明する場合、単にＺ−Ｗａｖｅデバイスと記載する場合がある。

プロトコル変換部１３４は、Ｚ−Ｗａｖｅデバイスから送信されたデータを、ＩＰ通信の通信方式にプロトコル変換して、クラウド２０に向けて送信してよい。また、プロトコル変換部１３４は、クラウド２０から送信されたデータを、Ｚ−Ｗａｖｅにプロトコル変換して、Ｚ−Ｗａｖｅデバイスに向けて送信する。Ｚ−Ｗａｖｅゲートウェイ１３２及びプロトコル変換部１３４は、中継部１２２として機能してよい。

また、中継装置１００は、中継装置１００内に、仮想的なＢＴデバイスを生成する。図７では、仮想的なＢＴデバイスの例として、仮想デバイス１４０、仮想デバイス１４１、仮想デバイス１４２、仮想デバイス１４３、及び仮想デバイス１４４を挙げている。仮想デバイス１４０、仮想デバイス１４１、仮想デバイス１４２、及び仮想デバイス１４４を区別せずに説明する場合、単に仮想デバイスと記載する場合がある。

中継装置１００は、生成した仮想デバイスによって、ＢＴデバイス３００との通信接続を確立する。図７では、ＢＴデバイス３００の例としてスマートフォン３１０を挙げ、スマートフォン３１０のＢｌｕｅｔｏｏｔｈアプリである、アプリ３２０、アプリ３２１、アプリ３２２、アプリ３２３、及びアプリ３２４と、仮想デバイス１４０、仮想デバイス１４１、仮想デバイス１４２、仮想デバイス１４３、及び仮想デバイス１４４とが通信接続している場合を例示している。

プロトコル変換部１３４は、スマートフォン３１０から送信されたデータを、ＩＰ通信の通信方式にプロトコル変換して、クラウド２０に向けて送信してよい。また、プロトコル変換部１３４は、クラウド２０から送信されたデータを、Ｂｌｕｅｔｏｏｔｈにプロトコル変換して、スマートフォン３１０に向けて送信する。仮想デバイス及びプロトコル変換部１３４は、中継部１２４として機能してよい。

本例におけるプロトコル変換部１３４は、Ｚ−ＷａｖｅとＢｌｕｅｔｏｏｔｈとの間でプロトコル変換する。中継装置１００は、Ｚ−Ｗａｖｅゲートウェイ１３２、プロトコル変換部１３４、及び仮想デバイスによって、Ｚ−Ｗａｖｅデバイスとスマートフォン３１０との間の通信を中継する。

図７に示す例では、Ｚ−Ｗａｖｅゲートウェイ１３２、プロトコル変換部１３４、及び仮想デバイス１４１によって、Ｚ−Ｗａｖｅデバイス４００とアプリ３２１との間の通信が中継される。また、Ｚ−Ｗａｖｅゲートウェイ１３２、プロトコル変換部１３４、及び仮想デバイス１４２によって、Ｚ−Ｗａｖｅデバイス４０１とアプリ３２２との間の通信が中継される。また、Ｚ−Ｗａｖｅゲートウェイ１３２、プロトコル変換部１３４、及び仮想デバイス１４３によって、Ｚ−Ｗａｖｅデバイス４０２とアプリ３２３との間の通信が中継される。また、Ｚ−Ｗａｖｅゲートウェイ１３２、プロトコル変換部１３４、及び仮想デバイス１４４によって、Ｚ−Ｗａｖｅデバイス４０３とアプリ３２４との間の通信が中継される。

図７に示す例において、仮想デバイス１４０は、アプリ３２０から受信したデータに基づいて、中継装置１００に対する制御を実行してよい。中継装置１００に対する制御の例としては、中継装置１００のコンフィギュレーション制御、ＦＯＴＡ制御、及び通信デバイスとのペアリング操作等が挙げられる。このように、仮想デバイス１４０は、実行部１２８として機能してよい。

図８は、中継装置１００の通信環境の一例を概略的に示す。ここでは、中継装置１００の仮想デバイス１４０とスマートフォン３１０とが通信接続を確立しており、Ｚ−Ｗａｖｅゲートウェイ１３２が、Ｚ−Ｗａｖｅメッシュネットワーク７２内のＺ−Ｗａｖｅデバイス４００と通信接続を確立している場合を例示している。

中継装置１００は、スマートフォン３１０からＢＴ接続を介して直接、ＤＳＫ（デバイス識別番号）等のデータを受信可能であり、これにより、ＷｉＦｉのような通信環境がなくとも、いわゆるＺ−Ｗａｖｅスマートスタートを実施することができる。また、中継装置１００が、Ｚ−Ｗａｖｅメッシュネットワーク７２とスマートフォン３１０との間の通信を中継することによって、スマートフォン３１０による、Ｚ−Ｗａｖｅメッシュネットワーク７２内のデバイス接続状況の可視化を容易に実現することができる。

中継装置１００は、Ｚ−Ｗａｖｅメッシュネットワーク７２内のＺ−Ｗａｖｅデバイス４００を送信元として、スマートフォン３１０に対してＢｌｕｅｔｏｏｔｈビーコンを送信してよい。これにより、中継装置１００は、Ｚ−Ｗａｖｅメッシュネットワーク７２をＢｌｕｅｔｏｏｔｈビーコンデバイス化することができる。

Ｚ−Ｗａｖｅの無線通信規格では、Ｚ−Ｗａｖｅデバイス４００は、ビーコンデバイスとして利用されず、スマートフォン３１０等に対して、ビーコンとしてＺ−Ｗａｖｅデバイス４００を連携する利用方法が現状は存在しない。それに対して、本例における中継装置１００は、Ｚ−ＷａｖｅからＢｌｕｅｔｏｏｔｈの方向では、Ｚ−Ｗａｖｅネットワーク７０内の各種Ｚ−Ｗａｖｅデバイス４００からセンシングした情報をベースに、Ｚ−Ｗａｖｅネットワーク７０全体を一つのＢｌｕｅｔｏｏｔｈ用のビーコンデバイスとして活用することを可能とし、複数のＺ−Ｗａｖｅデバイス４００の機能を複合した独自のビーコンデバイスとすることが可能となる。また、本例における中継装置１００は、ＢｌｕｅｔｏｏｔｈからＺ−Ｗａｖｅの方向では、既存のＢＴデバイスを、中継装置１００内でＺ−Ｗａｖｅデバイスに仮想化することで、Ｚ−Ｗａｖｅメッシュネットワーク７２内の一つのＺ−Ｗａｖｅデバイス４００として利用することを可能とする。

図９は、中継装置１００の通信環境の一例を概略的に示す。図９に示す例では、Ｚ−Ｗａｖｅメッシュネットワーク７２とＢＴネットワーク８０との間と、Ｚ−Ｗａｖｅメッシュネットワーク７２とクラウド２０との間とに、中継装置１００が配置されている。

図９に示すＢＴネットワーク８０内のＢＴデバイス３００は、ビーコンデバイスであってよい。ＢＴデバイス３００が送信したビーコンデバイスは、ＢＴネットワーク８０とＺ−Ｗａｖｅメッシュネットワーク７２の間の中継装置１００を介して、Ｚ−Ｗａｖｅメッシュネットワーク７２内のＺ−Ｗａｖｅデバイス４００に送信されてよく、また、Ｚ−Ｗａｖｅメッシュネットワーク７２とクラウド２０との間の中継装置１００を介してクラウド２０に送信されてよい。

図１０は、中継装置１００の構成の一例を概略的に示す。ここでは、図７と異なる点を主に説明する。図１０に示す例では、仮想デバイス１４０、仮想デバイス１４１、仮想デバイス１４２、仮想デバイス１４３、仮想デバイス１４４が、ＢＴメッシュネットワーク８２内のＢＴデバイス３００と通信接続を確立している場合を例示している。

Ｚ−ＷａｖｅとＢｌｕｅｔｏｏｔｈは、それぞれメッシュネットワークを構築することが可能だが、異なる規格を統合するような形でのネットワーク形成は、基本的に実施されていない。Ｚ−ＷａｖｅとＢｌｕｅｔｏｏｔｈは、利用する周波数帯等も異なり、それぞれ異なる特性を有しているため、排他的な扱いをするのではなく、共有することで、ＩｏＴネットワークとして新たな価値を見出す可能性がある。

本例における中継装置１００によれば、Ｚ−Ｗａｖｅデバイスを、中継装置１００内でＢｌｕｅｔｏｏｔｈメッシュ用デバイスに仮想化することで、ＢＴメッシュネットワーク８２にＺ−Ｗａｖｅデバイスを組み込む形でメッシュネットワークを形成することができる。中継装置１００が、Ｚ−ＷａｖｅデバイスとＢＴメッシュネットワーク８２との間の通信を中継することにより、ＢＴメッシュネットワーク８２に組み込まれたＺ−Ｗａｖｅデバイスに対しては、Ｂｌｕｅｔｏｏｔｈメッシュ対応のスマートフォンアプリ等から直接操作が可能になる。Ｚ−ＷａｖｅデバイスがＢＴメッシュネットワーク８２に組み込まれることによって、ＢＴメッシュネットワーク８２内の各デバイスと連携したソリューション開発が可能になる。

図１１は、中継装置１００の通信環境の一例を概略的に示す。図１１は、中継装置１００が、Ｚ−Ｗａｖｅメッシュネットワーク７２、ＢＴメッシュネットワーク８２、及びクラウド２０の間に配置された場合を例示している。本例における中継装置１００によれば、Ｚ−Ｗａｖｅデバイス４００を、中継装置１００内でＢｌｕｅｔｏｏｔｈメッシュ用デバイスに仮想化することで、ＢＴメッシュネットワーク８２にＺ−Ｗａｖｅデバイス４００を組み込み、かつ、ＢＴデバイス３００を、中継装置１００内でＺ−Ｗａｖｅメッシュ用デバイスに仮想化することで、Ｚ−Ｗａｖｅメッシュネットワーク７２にＢＴデバイス３００を組み込むことができ、Ｚ−Ｗａｖｅメッシュネットワーク７２及びＢＴメッシュネットワーク８２を統合したメッシュネットワークを構築することができる。

図１２は、中継装置１００の通信環境の一例を概略的に示す。図１２は、２つの中継装置１００が、それぞれＺ−Ｗａｖｅメッシュネットワーク７２内のＺ−Ｗａｖｅデバイス４００と通信接続し、当該２つの中継装置１００同士がＢＴ接続している場合を例示している。これら２つの中継装置１００は、他の中継装置１００とＢＴ接続をして、当該ＢＴ接続を介して、クラウド２０との通信をも可能としている。

Ｚ−Ｗａｖｅの通信規格では、同一メッシュネットワーク内に接続可能なＺ−Ｗａｖｅデバイスの数が２３２台に制限されていたり、マルチホップのホップ数が４回までに制限されていたりする等の、各種制限が存在する。本例における中継装置１００によれば、複数のＺ−Ｗａｖｅメッシュネットワーク７２を、ＢＴ接続を介して接続することで、サービス提供エリアの拡大や、接続台数の増加等に柔軟に対応可能なネットワークを形成することができる。また、他の中継装置１００とのＢＴ接続を介してクラウド２０と接続する構成を採用することにより、クラウド２０との切り離しなどが簡単に実施可能となり、セキュリティ対策としての利用等も実現し得る。また、通常はＩＰ通信で構成するネットワークを、ＬＡＮ及びＷｉＦｉ等のＩＰ通信を利用できない環境において、ネットワーク構成を柔軟に変更する用途での活用が見込める。

図１３は、中継装置１００の構成の一例を概略的に示す。図１３は、仮想デバイス１４１によって、Ｚ−Ｗａｖｅデバイス４００の機能４１０と、スマートフォン３１０のアプリ３２１とを中継し、仮想デバイス１４２によって、Ｚ−Ｗａｖｅデバイス４００の機能４１１とクラウド２０とを中継し、仮想デバイス１４３によって、Ｚ−Ｗａｖｅデバイス４００の機能４１２及び機能４１３とクラウド２０とを中継する場合を例示している。このように、中継装置１００は、１つのＺ−Ｗａｖｅデバイス４００の複数の機能を、複数の仮想デバイスに分割して異なる接続先と通信させてよい。Ｚ−Ｗａｖｅデバイス４００の機能は、任意の機能であってよいが、例えば、温度センサ、照度センサ、ＬＥＤ、及びボタン等が例示できる。

一般的に、複数のセンシング機能を有するようなＩｏＴデバイスであっても、ゲートウェイではデバイス単位でクラウド接続が管理されるので、同一ＩｏＴデバイス内の複数の機能から収集したデータは、同じ接続先に送信されることになる。これに対して、本例における中継装置１００によれば、同一デバイス内に複数の機能を有している場合に、中継装置１００内で機能毎に細分化して仮想デバイス化することができ、これにより、細分化した機能毎に異なる接続先とデータの送受信が可能となる。

上記実施形態では、格納部１０２、接続確立部１０４、回線選択部１０６、通信中継部１０８、データ監視部１１０、及び切替制御部１１２を備える中継装置１００と、中継部１２２、中継部１２４、中継部１２６、及び実行部１２８を備える中継装置１００とを別々に説明したが、中継装置１００は、これらのすべての構成を備えてもよい。

図１４は、中継装置１００として機能するコンピュータ１０００のハードウェア構成の一例を概略的に示す。本実施形態に係るコンピュータ１０００は、ホストコントローラ１０９２により相互に接続されるＣＰＵ１０１０及びＲＡＭ１０３０を有するＣＰＵ周辺部と、入出力コントローラ１０９４によりホストコントローラ１０９２に接続されるＲＯＭ１０２０、通信Ｉ／Ｆ１０４０、ハードディスクドライブ１０５０、及び入出力チップ１０８０を有する入出力部を備える。

ＣＰＵ１０１０は、ＲＯＭ１０２０及びＲＡＭ１０３０に格納されたプログラムに基づいて動作し、各部の制御を行う。通信Ｉ／Ｆ１０４０は、有線又は無線によりネットワークを介して他の装置と通信する。また、通信Ｉ／Ｆ１０４０は、通信を行うハードウェアとして機能する。ハードディスクドライブ１０５０は、ＣＰＵ１０１０が使用するプログラム及びデータを格納する。

ＲＯＭ１０２０は、コンピュータ１０００が起動時に実行するブート・プログラム及びコンピュータ１０００のハードウェアに依存するプログラムなどを格納する。入出力チップ１０８０は、例えばパラレル・ポート、シリアル・ポート、キーボード・ポート、マウス・ポートなどを介して各種の入出力装置を入出力コントローラ１０９４へと接続する。

ＲＡＭ１０３０を介してハードディスクドライブ１０５０に提供されるプログラムは、ＩＣカードなどの記録媒体に格納されて利用者によって提供される。プログラムは、記録媒体から読み出され、ＲＡＭ１０３０を介してハードディスクドライブ１０５０にインストールされ、ＣＰＵ１０１０において実行される。

コンピュータ１０００にインストールされ、コンピュータ１０００を中継装置１００として機能させるプログラムは、ＣＰＵ１０１０などに働きかけて、コンピュータ１０００を、中継装置１００の各部としてそれぞれ機能させてよい。これらのプログラムに記述された情報処理は、コンピュータ１０００に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である格納部１０２、接続確立部１０４、回線選択部１０６、通信中継部１０８、データ監視部１１０、及び切替制御部１１２として機能する。また、これらのプログラムに記述された情報処理は、コンピュータ１０００に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である中継部１２２、中継部１２４、中継部１２６、及び実行部１２８として機能する。また、これらのプログラムに記述された情報処理は、コンピュータ１０００に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である格納部１０２、接続確立部１０４、回線選択部１０６、通信中継部１０８、データ監視部１１０、切替制御部１１２、中継部１２２、中継部１２４、中継部１２６、及び実行部１２８として機能する。そして、これらの具体的手段によって、本実施形態におけるコンピュータ１０００の使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の中継装置１００が構築される。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階などの各処理の実行順序は、特段「より前に」、「先立って」などと明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」などを用いて説明したとしても、この順で実施することが必須であることを意味するものではない。

２０ クラウド、３０ 通信回線、４０ 通信回線、７０ Ｚ−Ｗａｖｅネットワーク、７２ Ｚ−Ｗａｖｅメッシュネットワーク、８０ ＢＴネットワーク、８２ ＢＴメッシュネットワーク、１００ 中継装置、１０２ 格納部、１０４ 接続確立部、１０６ 回線選択部、１０８ 通信中継部、１１０ データ監視部、１１２ 切替制御部、１２２ 中継部、１２４ 中継部、１２６ 中継部、１２８ 実行部、１３２ Ｚ−Ｗａｖｅゲートウェイ、１３４ プロトコル変換部、１４０、１４１、１４２、１４３、１４４、 仮想デバイス、２００ ＩｏＴデバイス、３００ ＢＴデバイス、３１０ スマートフォン、３２０、３２１、３２２、３２３、３２４ アプリ、４００、４０１、４０２、４０３ Ｚ−Ｗａｖｅデバイス、４１０、４１１、４１２、４１３ 機能、１０００ コンピュータ、１０１０ ＣＰＵ、１０２０ ＲＯＭ、１０３０ ＲＡＭ、１０４０ 通信Ｉ／Ｆ、１０５０ ハードディスクドライブ、１０８０ 入出力チップ、１０９２ ホストコントローラ、１０９４ 入出力コントローラ

Claims (18)

1. 無線通信デバイスと無線通信接続を確立する接続確立部と、
   前記無線通信デバイスのデバイスタイプに基づいて、前記無線通信デバイスとクラウドとの通信を中継するときに用いる無線通信回線として、第１の無線通信回線又は前記第１の無線通信回線よりも通信容量が多い第２の無線通信回線を選択する回線選択部と、
   前記回線選択部によって選択された無線通信回線を介して、前記無線通信デバイスと前記クラウドとの通信を中継する通信中継部と、
   第１の無線通信方式で無線通信接続をしている第１の無線通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換して前記通信中継部を介して前記クラウドに送信する第１中継部と、
   第２の無線通信方式で無線通信接続をしている第２の無線通信デバイスから受信したデータをＩＰ通信の通信方式にプロトコル変換して前記通信中継部を介して前記クラウドに送信する第２中継部と、
   前記第１の無線通信方式と前記第２の無線通信方式との間でプロトコル変換を実行し、前記第１の無線通信デバイスと前記第２の無線通信デバイスとの間の通信を中継する第３中継部と
   を備える、中継装置。
2. 前記回線選択部は、前記第１の無線通信デバイスのデバイスタイプが、数値データ又はテキストデータを送信するデバイスである第１のデバイスタイプである場合、前記第１の無線通信回線を選択し、前記第１の無線通信デバイスのデバイスタイプが画像データ又は音声データを送信するデバイスである第２のデバイスタイプである場合、前記第２の無線通信回線を選択し、前記第２の無線通信デバイスのデバイスタイプが前記第１のデバイスタイプである場合、前記第１の無線通信回線を選択し、前記第２の無線通信デバイスのデバイスタイプが前記第２のデバイスタイプである場合、前記第２の無線通信回線を選択する、請求項１に記載の中継装置。
3. 前記第１の無線通信方式は、Ｂｌｕｅｔｏｏｔｈである、請求項１又は２に記載の中継装置。
4. 前記第３中継部は、前記第１の無線通信デバイスと無線通信接続を確立した仮想デバイスが前記第１の無線通信デバイスから受信したデータを、前記第２の無線通信方式にプロトコル変換し、前記第２の無線通信デバイスと無線通信接続を確立したゲートウェイが前記第２の無線通信デバイスから受信したデータを、前記第１の無線通信方式にプロトコル変換するプロトコル変換部を有する、請求項３に記載の中継装置。
5. 前記第２の無線通信方式は、Ｚ−Ｗａｖｅ又はＺｉｇｂｅｅである、請求項３又は４に記載の中継装置。
6. 前記第１の無線通信回線は、ＮＢ−ＩｏＴ、ＬｏＲａ、及びＳｉｇｆｏｘの少なくともいずれかであり、
   前記第２の無線通信回線は、ＬＴＥである、請求項１から５のいずれか一項に記載の中継装置。
7. 前記通信中継部は、前記接続確立部によって無線通信接続が確立されている全ての無線通信デバイスに対して、前記第１の無線通信回線が選択されている場合、前記第２の無線通信回線をスリープさせる、請求項１から６のいずれか一項に記載の中継装置。
8. 前記通信中継部は、夜間として予め定められた時間帯では、前記接続確立部が無線通信接続を確立している全ての無線通信デバイスについて前記第１の無線通信回線が選択されてから、予め定められた第１の時間が経過した後で、前記第２の無線通信回線をスリープさせ、夜間として予め定められた前記時間帯以外の時間帯では、前記第１の時間よりも長い第２の時間が経過した後で、前記第２の無線通信回線をスリープさせる、請求項７に記載の中継装置。
9. 前記通信中継部が、前記第１の無線通信回線を用いて前記無線通信デバイスの通信を中継している間に、前記無線通信デバイスが送受信するデータを監視するデータ監視部と、
   前記無線通信デバイスが送受信するデータが予め定められた条件を満たす場合に、前記通信中継部が用いる無線通信回線を、前記第１の無線通信回線から前記第２の無線通信回線に切り替えさせる切替制御部と
   を備える、請求項１から８のいずれか一項に記載の中継装置。
10. 前記切替制御部は、前記無線通信デバイスが受信するデータの種類が予め定められた種類である場合に、前記通信中継部が用いる無線通信回線を、前記第１の無線通信回線から前記第２の無線通信回線に切り替えさせる、請求項９に記載の中継装置。
11. 前記第１の無線通信方式で無線通信接続をしている前記第１の無線通信デバイスから受信したデータに基づいて、前記中継装置に対する制御を実行する実行部
    を備える、請求項１から１０のいずれか一項に記載の中継装置。
12. 前記第３中継部は、前記第１の無線通信デバイスから受信したデータを、複数の前記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークに送信する、請求項１から１１のいずれか一項に記載の中継装置。
13. 前記第３中継部は、前記第２無線通信デバイスネットワーク内の前記第２の無線通信デバイスを送信元とするＢｌｕｅｔｏｏｔｈビーコンを、前記第１の無線通信デバイスに送信する、請求項１２に記載の中継装置。
14. 前記第３中継部は、前記第１の無線通信デバイスから受信したＢｌｕｅｔｏｏｔｈビーコンをプロトコル変換して、前記第２無線通信デバイスネットワーク内の少なくとも１つの前記第２の無線通信デバイスに送信する、請求項１２又は１３に記載の中継装置。
15. 前記第３中継部は、前記第２の無線通信デバイスから受信したデータを、複数の第１の無線通信デバイスによって構成される第１無線通信デバイスネットワークに送信する、請求項１から１４のいずれか一項に記載の中継装置。
16. 前記第３中継部は、複数の前記第１の無線通信デバイスによって構成される第１無線通信デバイスネットワークと、複数の前記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークとの間の通信を中継する、請求項１から１１のいずれか一項に記載の中継装置。
17. 前記第３中継部は、他の中継装置と、前記第１の無線通信方式により無線通信接続を確立し、当該無線通信接続を介して、複数の前記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークと、前記他の中継装置に接続された複数の前記第２の無線通信デバイスによって構成される第２無線通信デバイスネットワークとの間の通信を中継する、請求項１から１１のいずれか一項に記載の中継装置。
18. コンピュータを、請求項１から１７のいずれか一項に記載の中継装置として機能させるためのプログラム。

Images