以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
図1は、中継装置100の通信環境の一例を概略的に示す。本実施形態に係る中継装置100は、通信デバイスと通信接続を確立し、通信回線30と、通信回線30よりも通信容量が多い通信回線40とのいずれかを用いて、通信デバイスとクラウド20との通信を中継する。
図1では、中継装置100がいわゆるIoTゲートウェイであって、IoTデバイス200の通信を中継する場合を例に挙げて説明する。なお、これに限らず、中継装置100は、任意の通信デバイスと無線通信接続を確立して、当該通信デバイスの通信を中継するゲートウェイであってもよい。また、中継装置100は、任意の通信デバイスと有線通信接続を確立して、当該通信デバイスの通信を中継するゲートウェイであってもよい。通信回線30及び通信回線40は、無線通信回線であってよい。また、通信回線30及び通信回線40は、有線通信回線であってもよい。ここでは、通信回線30及び通信回線40が無線通信回線である場合を主に例に挙げて説明する。
IoTデバイス200の例としては、温度センサ、ドアセンサ、照明LED、体組成計、リストバンド、スピーカ、セキュリティカメラ、スマートメータ、気象観測機器、及び農業機器等が挙げられる。通信回線30は、例えば、IoT向け通信方式に準拠した通信回線であってよい。通信回線30の例としては、NB−IoT(Narrow Band−IoT)、LoRa(Long Range)、及びSigfox等が挙げられる。通信回線40は、例えば、いわゆる移動体通信回線であってよい。通信回線40の例としては、LTE(Long Term Evolution)回線が挙げられる。
IoT向け通信方式では、通信速度が低速度で、送受信データのデータ容量も限られる。一方、例えば、LTE回線は、通信速度も高速で、大容量通信も可能だが、温度センサ及びドアセンサ等によるセンシングデータのような非常に小さなデータでは、LTE回線の能力を活かせておらず、通信設備のリソースに無駄が発生し、回線リソースを有効に活用できない場合がある。IoT向けには、IP通信の環境(WiFi(登録商標)(Wireless Fidelity)経由でインターネットに接続するような環境)を必ずしも利用できるわけではなく、移動体通信回線を利用したクラウド接続は有効な手段の一つである。
本実施形態に係る中継装置100は、小容量向けの通信回線30と、大容量向けの通信回線40とをサポートし、状況に応じて適切に回線を切り替える機能を有する。中継装置100は、例えば、IoTデバイス200との通信の通信方式に基づいて、通信回線30又は通信回線40を選択し、選択した通信回線を介してIoTデバイス200の通信を中継する。例えば、中継装置100は、通信方式がZ−Wave又はZigbeeである場合、通信回線30を選択する。また、例えば、中継装置100は、通信方式がWiFi又はBluetoothである場合、通信回線40を選択する。これにより、IoTデバイス200と中継装置100との間の通信の通信容量が小さい場合には、小容量向けの通信回線30を選択し、IoTデバイス200と中継装置100との間の通信の通信容量が大きい場合には、大容量向けの通信回線30を選択することができる。
また、中継装置100は、例えば、IoTデバイス200のデバイスタイプに基づいて、通信回線30又は通信回線40を選択し、選択した通信回線を介してIoTデバイス200の通信を中継する。例えば、中継装置100は、IoTデバイス200が、温度センサ及びドアセンサ等のセンサのように、通常送信するデータが比較的小容量のデバイスである場合、通信回線30を選択する。また、例えば、中継装置100は、IoTデバイス200が、セキュリティカメラのように、通常送信するデータが比較的大容量のデバイスである場合、通信回線40を選択する。これにより、IoTデバイス200が送信するデータに適した通信回線を用いて、IoTデバイス200の通信を中継することができる。
また、本実施形態に係る中継装置100は、通信回線30を用いてIoTデバイス200の通信を中継している間に、IoTデバイス200が送受信するデータを監視して、当該データが予め定められた条件を満たす場合に、使用する通信回線を通信回線30から通信回線40に切り替えてよい。例えば、中継装置100は、IoTデバイス200が送受信するデータの種類が、FOTA(Firmware On−The−Air)データ等の予め定められた種類である場合に、使用する通信回線を通信回線30から通信回線40に切り替える。
例えば、IoTデバイス200が温度センサである場合、温度センサが通常送信するデータは、検知した温度を示すセンシングデータであり、データ容量が少ないため、通信回線30を使用していても問題ない。しかし、温度センサがFOTAデータを受信する場合、FOTAデータは比較的容量が大きいので、通信回線30を使用していた場合、多くの時間を要してしまう場合がある。これに対して、本実施形態に係る中継装置100によれば、FOTAデータのように比較的容量が大きいデータを送受信する場合には、使用する通信回線が通信回線30から通信回線40に切り替わるので、このような事態の発生を防止することができる。
中継装置100は、例えば、常時利用しない通信回線については、利用しない時間帯はスリープしてよい。具体例として、中継装置100は、原則としては通信回線30をアクティブにしておき、必要に応じて通信回線40をアクティブにし、通信回線40を使用する必要がなくなった場合、通信回線40をスリープさせる。これにより、電波の無駄を避けることができる。
図2は、中継装置100による処理の流れの一例を概略的に示す。ここでは、IoTデバイス200との間で確立した通信接続の通信方式に基づいて通信回線を選択する処理の流れを説明する。図2に示す各処理は、中継装置100が備える制御部が主体となって実行される。
ステップ(ステップをSと省略して記載する場合がある。)102では、IoTデバイス200とのペアリングを確立する。S104では、S102において確立した通信接続の通信方式を取得する。
S106では、S104において取得した通信方式が、第1の通信方式であるか否かを判定する。第1の通信方式の例としては、Z−Wave及びZigbee等が挙げられる。第1の通信方式であると判定した場合、S108に進む。通信方式が、第1の通信方式ではなく、例えば、WiFi及びBluetooth等である場合、S110に進む。WiFi及びBluetoothは、第2の通信方式の一例であってよい。S108では、通信回線30を選択する。S110では、通信回線40を選択する。そして処理を終了する。
図3は、中継装置100による処理の流れの一例を概略的に示す。ここでは、デバイスタイプの取得が可能な通信方式によって通信接続を確立したIoTデバイス200のデバイスタイプに基づいて、通信回線を選択する処理の流れを説明する。デバイスタイプの取得が可能な通信方式の例としては、Z−Wave、Zigbee、及びBluetooth等が挙げられる図3に示す各処理は、中継装置100が備える制御部が主体となって実行される。
S202では、IoTデバイス200と通信接続を確立する。S204では、S202において通信接続を確立したIoTデバイス200のデバイスタイプを取得する。IoTデバイス200は、例えば、ペアリング時にIoTデバイス200から受信するデータを参照することによって、IoTデバイス200のデバイスタイプを取得する。具体例として、中継装置100は、ペアリングIDとデバイスタイプとを対応付けた対応付けデータを予め格納しておき、当該対応付けデータを参照することによって、IoTデバイス200のデバイスタイプを取得してよい。
S206では、S204において取得したデバイスタイプが、第1のデバイスタイプであるか否かを判定する。第1のデバイスタイプの例としては、センシングデータを送信する温度センサ及びドアセンサ等のセンサが挙げられる。第1のデバイスタイプであると判定した場合、S208に進む。第1のデバイスタイプではなく、例えば、セキュリティカメラ等の画像データ及び音声データを送信するデバイスである場合、S210に進む。セキュリティカメラ等の画像データ及び音声データを送信するデバイスは、第2のデバイスタイプの一例であってよい。S208では、通信回線30を選択する。S210では、通信回線40を選択する。そして処理を終了する。
図4は、中継装置100による処理の流れの一例を概略的に示す。ここでは、通信回線30を用いてIoTデバイス200の通信を中継している場合に、中継装置100が実行する処理について説明する。図4に示す各処理は、中継装置100が備える制御部が主体となって実行される。
S302では、中継データを参照する。中継装置100は、例えば、IoTデバイス200から受信して、プロトコル変換をして、通信回線30を介してクラウド20に奏しするデータ、及び、クラウド20側から通信回線30を介して受信して、プロトコル変換をしてIoTデバイスに送信するデータを参照する。なお、中継装置100は、IoTデバイス200から受信するデータ及びIoTデバイス200に対して送信するデータをミラーリングして取得した中継データを参照してもよい。
S304では、S302において取得した中継データから、IoTデバイス200が送受信しているデータが大容量データであるか否かを判定する。中継装置100は、例えば、中継データを解析することによって、IoTデバイス200が送受信しているデータが、FOTAデータ、画像データ、及び音声データのような大容量データであるか、数値データ及びテキストデータ等のセンシングデータのような小容量データであるかを判定してよい。また、例えば、IoTデバイス200との通信方式がZ−Wave及びZigbeeである場合、データに含まれる、何のデータを送信しているのかを示すIDを参照して、当該IDが、例えば、FOTAデータのような大容量データを示す場合には、大容量データであると判定する。
大容量データであると判定した場合、S306に進む。S306では、通信回線を通信回線30から通信回線40に切り替える。切替を実行しなかった場合(S308でNO)、S302に戻り、切替を実行した場合(S308でYES)、処理を終了する。
図5は、中継装置100の機能構成の一例を概略的に示す。中継装置100は、格納部102、接続確立部104、回線選択部106、通信中継部108、データ監視部110、及び切替制御部112を備える。なお、中継装置100がこれらのすべての構成を備えることは必須とは限らない。
格納部102は、各種データを格納する。格納部102は、第1の通信方式及び第2の通信方式の情報を格納してよい。格納部102は、例えば、複数の通信方式のそれぞれが第1の通信方式であるか第2の通信方式であるかを示すデータを格納する。当該データは、例えば、中継装置100のオペレータ等によって生成される。
また、格納部102は、第1のデバイスタイプ及び第2のデバイスタイプの情報を格納してよい。格納部102は、例えば、複数のデバイスタイプのそれぞれが第1のデバイスタイプであるか第2のデバイスタイプであるかを示すデータを格納する。当該データは、例えば、中継装置100のオペレータ等によって生成される。また、格納部102は、ペアリングIDとデバイスタイプとを対応付けた対応付けデータを格納してよい。
接続確立部104は、通信デバイスと通信接続を確立する。接続確立部104は、例えば、IoTデバイス200と通信接続を確立する。
回線選択部106は、接続確立部104が通信接続を確立した通信デバイスと、当該通信デバイスの通信相手との間の通信を中継するときに用いる通信回線として、通信回線30又は通信回線40を選択する。回線選択部106は、例えば、接続確立部104が通信デバイスと確立した通信接続の通信方式に基づいて、通信回線30又は通信回線40を選択する。具体例として、回線選択部106は、通信方式が第1の通信方式である場合、通信回線30を選択し、通信方式が第1の通信方式でなく第2の通信方式である場合、通信回線40を選択する。
また、回線選択部106は、例えば、接続確立部104が通信接続を確立した中継装置100のデバイスタイプに基づいて、通信回線30又は通信回線40を選択する。具体例として、回線選択部106は、デバイスタイプが第1のデバイスタイプである場合、通信回線30を選択し、デバイスタイプが第1のデバイスタイプでなく第2のデバイスタイプである場合、通信回線40を選択する。
通信中継部108は、回線選択部106によって選択された通信回線を介して、通信デバイスと通信相手との通信を中継する。通信中継部108は、接続確立部104が通信接続を確立している全ての通信デバイスについて、通信回線30が選択されていて、通信回線40が選択されていない場合、通信回線40をスリープさせてよい。
回線選択部106は、予め定められた条件に従って、通信回線40をスリープさせるタイミングを制御してよい。例えば、回線選択部106は、夜間として予め定められた時間帯では、接続確立部104が通信接続を確立している全ての通信デバイスについて通信回線30が選択されてから、予め定められた第1の時間が経過した後で、通信回線40をスリープさせ、それ以外の時間帯では、第1の時間よりも長い第2の時間が経過した後で、通信回線40をスリープさせる。これにより、夜間よりも通信頻度が高い昼間では、すぐに通信回線40をスリープさせずに、適切な時間待機した後で、通信回線40をスリープさせることができる。
データ監視部110は、回線選択部106によって通信回線30が選択され、通信中継部108が通信回線30を用いて通信デバイスの通信を中継している間に、通信デバイスが送受信するデータを監視する。データ監視部110は、常時データを監視してよく、また、予め定められたタイミングに従ってデータを監視してもよい。
切替制御部112は、通信デバイスが送受信するデータが予め定められた条件を満たす場合に、通信中継部108が用いる通信回線を、通信回線30から通信回線40に切り替えさせる。切替制御部112は、例えば、通信デバイスが送受信するデータの種類が予め定められた種類である場合に、通信中継部108が用いる通信回線を、通信回線30から通信回線40に切り替えさせる。
図6は、中継装置100の通信環境の他の一例を概略的に示す。本例における中継装置100は、第1の無線通信方式で通信接続をしている第1の通信デバイスから受信したデータをIP通信の通信方式にプロトコル変換してクラウド20に送信する中継部122と、第2の無線通信方式で通信接続をしている第2の通信デバイスから受信したデータをIP通信の通信方式にプロトコル変換してクラウド20に送信する中継部124とを備える。中継部122は、第1中継部の一例であり、中継部124は、第2中継部の一例である。第1の無線通信方式の例としては、Bluetoothが挙げられる。第2の無線通信方式の例としては、Z−Wave及びZigbee等が挙げられる。
本例における中継装置100は、さらに、第1の無線通信方式と第2の無線通信方式との間でプロトコル変換を実行し、第1の通信デバイスと第2の通信デバイスとの間の通信を中継する中継部126を備える。中継部126は、第3中継部の一例である。図6では、第1の無線通信方式がBluetoothであり、第2の無線通信方式がZ−Waveである場合を例に挙げて説明する。BT(BlueTooth)デバイス300は、第1の通信デバイスの一例であり、Z−Waveデバイス400は、第2の通信デバイスの一例である。
既存のIoTゲートウェイでは、BluetoothからIP通信へのプロトコル変換、Z−WaveからIP通信へのプロトコル変換、及びZigbeeからIP通信へのプロトコル変換をサポートしていたが、Z−WaveからBluetoothへのプロトコル変換、及びZigbeeからBluetoothへのプロトコル変換はサポートされていなかった。本例における中継装置100は、中継部126を備えることによってこれらをサポートすることができ、通信デバイスの新たな活用方法を可能にすることができる。
例えば、現状、Zigbee及びZ−Wave等のIoT無線通信規格は、スマートフォン、タブレット、及びPC(Personal Computer)ではサポートされていないため、それらの機器とは直接やりとりはできない。現状はIP通信に変換してからデータ変換することになる。Bluetoothは、2.4GHz帯の周波数を主に利用する規格であるが、2.4GHz帯の電波は、電波干渉が強く回り込み性が弱い(障害物に弱い)という特性がある。一方、Z−Wave等のIoT向け無線通信規格では、900MHz帯の周波数帯がよく利用され、電波干渉が少なく回り込み性が強いという電波特性をもっている。ZigbeeやZ−Wave、Bluetoothは、それぞれの通信規格の特性に合わせたデバイスが市場には存在している。
本例の中継装置100によれば、中継部126を備えることにより、複数の無線通信規格を共存させることで、新たなIoTの有効な使い道を作り出すことができる。例えば、中継装置100は、Z−Wave等のデバイスを中継装置100内で仮想化し、バーチャルなBluetoothデバイスを中継装置100内で管理する。そして、このような仮想化デバイスをスマートフォン等のBluetooth対応デバイスとペアリングすることによって、Z−Waveネットワーク内のZ−Waveデバイスをスマートフォンから直接制御可能にできる。
本例のおける中継装置100は、さらに、第1の無線通信方式で通信接続している第1の通信デバイスから受信したデータに基づいて、中継装置100に対する制御を実行する実行部128をさらに備えてよい。既存のIoTゲートウェイは、限られたボタン及びLED等しか有しておらず、IoTゲートウェイに対するコンフィギュレーション等の操作においては、必ずしも直観的でわかりやすい操作性が提供されているわけではない。また、外部デバイスからIoTゲートウェイを操作したり、データを登録したりすることを希望する場合には、Web(クラウド)経由でIP通信を利用して行うことができる機器は存在するが、ローカルエリアにLAN(Local Area Network)やWiFi等のIP通信環境が求められることになる。IoTゲートウェイを利用する環境では、必ずしもIP通信が可能な環境とは限らない。それに対して、本例における中継装置100は実行部128を備えるので、例えば、Bluetoothを利用して、スマートフォン及びタブレット等から直接中継装置100に対するコンフィギュレーションや、FOTA制御、及びIoTデバイスのペアリング操作等を可能とすることで、直観的なGUIを利用した形で、各種操作を可能とすることができる。
図7は、中継装置100の構成の一例を概略的に示す。ここでは、中継装置100がZ−WaveとBluetoothとの間の通信を中継する例を主に挙げて説明するが、これに限らず、例えば、ZigbeeとBluetooth等、他の組み合わせの通信を中継してもよい。
図7に示す例における中継装置100は、Z−Waveゲートウェイ132及びプロトコル変換部134を備える。Z−Waveゲートウェイ132は、Z−Waveネットワーク70内の複数のZ−Waveデバイスの通信を中継する。図7では、複数のZ−Waveデバイスの例として、Z−Waveデバイス400、Z−Waveデバイス401、Z−Waveデバイス402、及びZ−Waveデバイス403を挙げている。Z−Waveデバイス400、Z−Waveデバイス401、Z−Waveデバイス402、及びZ−Waveデバイス403を区別せずに説明する場合、単にZ−Waveデバイスと記載する場合がある。
プロトコル変換部134は、Z−Waveデバイスから送信されたデータを、IP通信の通信方式にプロトコル変換して、クラウド20に向けて送信してよい。また、プロトコル変換部134は、クラウド20から送信されたデータを、Z−Waveにプロトコル変換して、Z−Waveデバイスに向けて送信する。Z−Waveゲートウェイ132及びプロトコル変換部134は、中継部122として機能してよい。
また、中継装置100は、中継装置100内に、仮想的なBTデバイスを生成する。図7では、仮想的なBTデバイスの例として、仮想デバイス140、仮想デバイス141、仮想デバイス142、仮想デバイス143、及び仮想デバイス144を挙げている。仮想デバイス140、仮想デバイス141、仮想デバイス142、及び仮想デバイス144を区別せずに説明する場合、単に仮想デバイスと記載する場合がある。
中継装置100は、生成した仮想デバイスによって、BTデバイス300との通信接続を確立する。図7では、BTデバイス300の例としてスマートフォン310を挙げ、スマートフォン310のBluetoothアプリである、アプリ320、アプリ321、アプリ322、アプリ323、及びアプリ324と、仮想デバイス140、仮想デバイス141、仮想デバイス142、仮想デバイス143、及び仮想デバイス144とが通信接続している場合を例示している。
プロトコル変換部134は、スマートフォン310から送信されたデータを、IP通信の通信方式にプロトコル変換して、クラウド20に向けて送信してよい。また、プロトコル変換部134は、クラウド20から送信されたデータを、Bluetoothにプロトコル変換して、スマートフォン310に向けて送信する。仮想デバイス及びプロトコル変換部134は、中継部124として機能してよい。
本例におけるプロトコル変換部134は、Z−WaveとBluetoothとの間でプロトコル変換する。中継装置100は、Z−Waveゲートウェイ132、プロトコル変換部134、及び仮想デバイスによって、Z−Waveデバイスとスマートフォン310との間の通信を中継する。
図7に示す例では、Z−Waveゲートウェイ132、プロトコル変換部134、及び仮想デバイス141によって、Z−Waveデバイス400とアプリ321との間の通信が中継される。また、Z−Waveゲートウェイ132、プロトコル変換部134、及び仮想デバイス142によって、Z−Waveデバイス401とアプリ322との間の通信が中継される。また、Z−Waveゲートウェイ132、プロトコル変換部134、及び仮想デバイス143によって、Z−Waveデバイス402とアプリ323との間の通信が中継される。また、Z−Waveゲートウェイ132、プロトコル変換部134、及び仮想デバイス144によって、Z−Waveデバイス403とアプリ324との間の通信が中継される。
図7に示す例において、仮想デバイス140は、アプリ320から受信したデータに基づいて、中継装置100に対する制御を実行してよい。中継装置100に対する制御の例としては、中継装置100のコンフィギュレーション制御、FOTA制御、及び通信デバイスとのペアリング操作等が挙げられる。このように、仮想デバイス140は、実行部128として機能してよい。
図8は、中継装置100の通信環境の一例を概略的に示す。ここでは、中継装置100の仮想デバイス140とスマートフォン310とが通信接続を確立しており、Z−Waveゲートウェイ132が、Z−Waveメッシュネットワーク72内のZ−Waveデバイス400と通信接続を確立している場合を例示している。
中継装置100は、スマートフォン310からBT接続を介して直接、DSK(デバイス識別番号)等のデータを受信可能であり、これにより、WiFiのような通信環境がなくとも、いわゆるZ−Waveスマートスタートを実施することができる。また、中継装置100が、Z−Waveメッシュネットワーク72とスマートフォン310との間の通信を中継することによって、スマートフォン310による、Z−Waveメッシュネットワーク72内のデバイス接続状況の可視化を容易に実現することができる。
中継装置100は、Z−Waveメッシュネットワーク72内のZ−Waveデバイス400を送信元として、スマートフォン310に対してBluetoothビーコンを送信してよい。これにより、中継装置100は、Z−Waveメッシュネットワーク72をBluetoothビーコンデバイス化することができる。
Z−Waveの無線通信規格では、Z−Waveデバイス400は、ビーコンデバイスとして利用されず、スマートフォン310等に対して、ビーコンとしてZ−Waveデバイス400を連携する利用方法が現状は存在しない。それに対して、本例における中継装置100は、Z−WaveからBluetoothの方向では、Z−Waveネットワーク70内の各種Z−Waveデバイス400からセンシングした情報をベースに、Z−Waveネットワーク70全体を一つのBluetooth用のビーコンデバイスとして活用することを可能とし、複数のZ−Waveデバイス400の機能を複合した独自のビーコンデバイスとすることが可能となる。また、本例における中継装置100は、BluetoothからZ−Waveの方向では、既存のBTデバイスを、中継装置100内でZ−Waveデバイスに仮想化することで、Z−Waveメッシュネットワーク72内の一つのZ−Waveデバイス400として利用することを可能とする。
図9は、中継装置100の通信環境の一例を概略的に示す。図9に示す例では、Z−Waveメッシュネットワーク72とBTネットワーク80との間と、Z−Waveメッシュネットワーク72とクラウド20との間とに、中継装置100が配置されている。
図9に示すBTネットワーク80内のBTデバイス300は、ビーコンデバイスであってよい。BTデバイス300が送信したビーコンデバイスは、BTネットワーク80とZ−Waveメッシュネットワーク72の間の中継装置100を介して、Z−Waveメッシュネットワーク72内のZ−Waveデバイス400に送信されてよく、また、Z−Waveメッシュネットワーク72とクラウド20との間の中継装置100を介してクラウド20に送信されてよい。
図10は、中継装置100の構成の一例を概略的に示す。ここでは、図7と異なる点を主に説明する。図10に示す例では、仮想デバイス140、仮想デバイス141、仮想デバイス142、仮想デバイス143、仮想デバイス144が、BTメッシュネットワーク82内のBTデバイス300と通信接続を確立している場合を例示している。
Z−WaveとBluetoothは、それぞれメッシュネットワークを構築することが可能だが、異なる規格を統合するような形でのネットワーク形成は、基本的に実施されていない。Z−WaveとBluetoothは、利用する周波数帯等も異なり、それぞれ異なる特性を有しているため、排他的な扱いをするのではなく、共有することで、IoTネットワークとして新たな価値を見出す可能性がある。
本例における中継装置100によれば、Z−Waveデバイスを、中継装置100内でBluetoothメッシュ用デバイスに仮想化することで、BTメッシュネットワーク82にZ−Waveデバイスを組み込む形でメッシュネットワークを形成することができる。中継装置100が、Z−WaveデバイスとBTメッシュネットワーク82との間の通信を中継することにより、BTメッシュネットワーク82に組み込まれたZ−Waveデバイスに対しては、Bluetoothメッシュ対応のスマートフォンアプリ等から直接操作が可能になる。Z−WaveデバイスがBTメッシュネットワーク82に組み込まれることによって、BTメッシュネットワーク82内の各デバイスと連携したソリューション開発が可能になる。
図11は、中継装置100の通信環境の一例を概略的に示す。図11は、中継装置100が、Z−Waveメッシュネットワーク72、BTメッシュネットワーク82、及びクラウド20の間に配置された場合を例示している。本例における中継装置100によれば、Z−Waveデバイス400を、中継装置100内でBluetoothメッシュ用デバイスに仮想化することで、BTメッシュネットワーク82にZ−Waveデバイス400を組み込み、かつ、BTデバイス300を、中継装置100内でZ−Waveメッシュ用デバイスに仮想化することで、Z−Waveメッシュネットワーク72にBTデバイス300を組み込むことができ、Z−Waveメッシュネットワーク72及びBTメッシュネットワーク82を統合したメッシュネットワークを構築することができる。
図12は、中継装置100の通信環境の一例を概略的に示す。図12は、2つの中継装置100が、それぞれZ−Waveメッシュネットワーク72内のZ−Waveデバイス400と通信接続し、当該2つの中継装置100同士がBT接続している場合を例示している。これら2つの中継装置100は、他の中継装置100とBT接続をして、当該BT接続を介して、クラウド20との通信をも可能としている。
Z−Waveの通信規格では、同一メッシュネットワーク内に接続可能なZ−Waveデバイスの数が232台に制限されていたり、マルチホップのホップ数が4回までに制限されていたりする等の、各種制限が存在する。本例における中継装置100によれば、複数のZ−Waveメッシュネットワーク72を、BT接続を介して接続することで、サービス提供エリアの拡大や、接続台数の増加等に柔軟に対応可能なネットワークを形成することができる。また、他の中継装置100とのBT接続を介してクラウド20と接続する構成を採用することにより、クラウド20との切り離しなどが簡単に実施可能となり、セキュリティ対策としての利用等も実現し得る。また、通常はIP通信で構成するネットワークを、LAN及びWiFi等のIP通信を利用できない環境において、ネットワーク構成を柔軟に変更する用途での活用が見込める。
図13は、中継装置100の構成の一例を概略的に示す。図13は、仮想デバイス141によって、Z−Waveデバイス400の機能410と、スマートフォン310のアプリ321とを中継し、仮想デバイス142によって、Z−Waveデバイス400の機能411とクラウド20とを中継し、仮想デバイス143によって、Z−Waveデバイス400の機能412及び機能413とクラウド20とを中継する場合を例示している。このように、中継装置100は、1つのZ−Waveデバイス400の複数の機能を、複数の仮想デバイスに分割して異なる接続先と通信させてよい。Z−Waveデバイス400の機能は、任意の機能であってよいが、例えば、温度センサ、照度センサ、LED、及びボタン等が例示できる。
一般的に、複数のセンシング機能を有するようなIoTデバイスであっても、ゲートウェイではデバイス単位でクラウド接続が管理されるので、同一IoTデバイス内の複数の機能から収集したデータは、同じ接続先に送信されることになる。これに対して、本例における中継装置100によれば、同一デバイス内に複数の機能を有している場合に、中継装置100内で機能毎に細分化して仮想デバイス化することができ、これにより、細分化した機能毎に異なる接続先とデータの送受信が可能となる。
上記実施形態では、格納部102、接続確立部104、回線選択部106、通信中継部108、データ監視部110、及び切替制御部112を備える中継装置100と、中継部122、中継部124、中継部126、及び実行部128を備える中継装置100とを別々に説明したが、中継装置100は、これらのすべての構成を備えてもよい。
図14は、中継装置100として機能するコンピュータ1000のハードウェア構成の一例を概略的に示す。本実施形態に係るコンピュータ1000は、ホストコントローラ1092により相互に接続されるCPU1010及びRAM1030を有するCPU周辺部と、入出力コントローラ1094によりホストコントローラ1092に接続されるROM1020、通信I/F1040、ハードディスクドライブ1050、及び入出力チップ1080を有する入出力部を備える。
CPU1010は、ROM1020及びRAM1030に格納されたプログラムに基づいて動作し、各部の制御を行う。通信I/F1040は、有線又は無線によりネットワークを介して他の装置と通信する。また、通信I/F1040は、通信を行うハードウェアとして機能する。ハードディスクドライブ1050は、CPU1010が使用するプログラム及びデータを格納する。
ROM1020は、コンピュータ1000が起動時に実行するブート・プログラム及びコンピュータ1000のハードウェアに依存するプログラムなどを格納する。入出力チップ1080は、例えばパラレル・ポート、シリアル・ポート、キーボード・ポート、マウス・ポートなどを介して各種の入出力装置を入出力コントローラ1094へと接続する。
RAM1030を介してハードディスクドライブ1050に提供されるプログラムは、ICカードなどの記録媒体に格納されて利用者によって提供される。プログラムは、記録媒体から読み出され、RAM1030を介してハードディスクドライブ1050にインストールされ、CPU1010において実行される。
コンピュータ1000にインストールされ、コンピュータ1000を中継装置100として機能させるプログラムは、CPU1010などに働きかけて、コンピュータ1000を、中継装置100の各部としてそれぞれ機能させてよい。これらのプログラムに記述された情報処理は、コンピュータ1000に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である格納部102、接続確立部104、回線選択部106、通信中継部108、データ監視部110、及び切替制御部112として機能する。また、これらのプログラムに記述された情報処理は、コンピュータ1000に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である中継部122、中継部124、中継部126、及び実行部128として機能する。また、これらのプログラムに記述された情報処理は、コンピュータ1000に読込まれることにより、ソフトウエアと上述した各種のハードウェア資源とが協働した具体的手段である格納部102、接続確立部104、回線選択部106、通信中継部108、データ監視部110、切替制御部112、中継部122、中継部124、中継部126、及び実行部128として機能する。そして、これらの具体的手段によって、本実施形態におけるコンピュータ1000の使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の中継装置100が構築される。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階などの各処理の実行順序は、特段「より前に」、「先立って」などと明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」などを用いて説明したとしても、この順で実施することが必須であることを意味するものではない。