JP6495381B2 - サーバ装置、サーバ装置がＩｏＴデバイスと通信する方法、コンピュータプログラム、通信システムおよびＩｏＴデバイス - Google Patents

Description

本発明は、サーバ装置がＩｏＴデバイスと通信する技術に関する。

近年、移動通信ネットワークの普及に伴い、従来の携帯電話機に代表される携帯端末に加え、自動車やスマートメータ等の様々なＩｏＴデバイスをネットワークに接続して、新しいサービスの提供を行うことが期待されている（例えば、特許文献１）。

特開２０１７−０９２７５９号公報

ところで、ＩｏＴデバイスによるネットワーク接続に適した新たな通信技術として、ＬＰＷＡ（Low Power Wide Area）が注目されている。ＬＰＷＡは、従来広く使用されている通信技術（例えば、Ｗｉ−Ｆｉ、ＬＴＥ（Long Term Evolution）等）と比較して、低消費電力かつ低コストという特徴を持つ。また、ＬＰＷＡは、従来の通信技術（例えば、無線ＬＡＮ）と比較して、広範囲の通信が可能であるという特徴を持つ。一方で、ＬＰＷＡは、これら低消費電力や広域通信の実現のため、従来の通信技術と比較して、データ転送速度（スループット）の最大値が小さく制限されている。

図１１は、デバイスへのサービス提供の流れを示すシーケンス図である。図示のように、デバイスは、ユーザに指定されたホスト名を持つアプリケーションサーバに接続するために、ネットワーク上にあるＤＮＳ（Domain Name System）サーバとの間で名前解決処理を実行する（ステップＳ１０〜Ｓ１４）。この名前解決処理により、デバイスは、指定されたホスト名に対応するアプリケーションサーバの宛先アドレス（例えば、グローバルＩＰアドレス）を取得することができる（ステップＳ１４）。その後、デバイスは、取得した宛先アドレスを用いてアプリケーションサーバとの間で通信を行い、アプリケーションサーバが提供するサービスの提供を受ける（ステップＳ２０〜Ｓ２４）。

一般に、取得されたホスト名と宛先アドレスとの対応付けはデバイス内に記憶されるため、同一ホストに対して毎回、名前解決処理を実行することは回避される。しかし、主としてセキュリティ上の観点から、デバイス内のホスト名と宛先アドレスとの対応付けは、所定の有効期間経過後に破棄される。破棄された後、デバイスは、再び名前解決処理（ステップＳ１０〜Ｓ１４）を実行する。

ここで、従来の通信技術では、高速なデータ転送速度（例えば、最大数Ｍｂｐｓ）を有することから、上述の名前解決処理を問題なく実行することができた。しかし、ＬＰＷＡは、データ転送速度の最大値が小さく制限（例えば、数１００ｂｐｓ〜１００ｋｂｐｓ）されている。このため、ネットワークに接続されている複数のデバイスにおいて、上述した名前解決処理が実行された場合、帯域の圧迫に繋がり、各デバイスの通信に支障をきたすという課題があった。なお、このような課題は、宛先アドレスとしてローカルＩＰアドレスを用いる場合にも共通する課題であり、ＬＰＷＡに分類される種々の通信規格（例えば、ＮＢ−ＩｏＴ、ｅＭＴＣ、ＬｏＲａＷＡＮ（登録商標）、ＩＥＥＥ８０２．１１ａｈ、Ｗｉ−ＳＵＮ等）にも共通する課題であった。

本発明は、上記問題に鑑みてなされたものであり、ＩｏＴデバイスとの通信に関し、名前解決処理による帯域の圧迫を抑制する技術を提供することを目的とする。

（１）本発明の一形態によれば、ＩｏＴデバイスと通信するサーバ装置が提供される。このサーバ装置は、前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する取得部と、前記動作情報を記憶装置に記憶させる制御部と、前記動作情報の取得に対する応答として、前記サーバ装置のＤＮＳ情報を含む応答を生成し、前記ＩｏＴデバイスに送信する応答部と、を備える。

（２）上記形態のサーバ装置において、前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、前記応答部は、前記付加情報の種類に応じて、前記ＤＮＳ情報の内容を変更してもよい。

（３）上記形態のサーバ装置において、前記応答部は、前記付加情報が前記ＩｏＴデバイスの無線信号に関する情報である場合、前記ＤＮＳ情報としてＴＴＬの更新情報を採用してもよい。

（４）上記形態のサーバ装置において、前記応答部は、前記付加情報が前記ＩｏＴデバイスによる前記動作情報の送信頻度を示す情報である場合、前記ＤＮＳ情報として前記サーバ装置の最新の宛先アドレスを採用してもよい。

（５）上記形態のサーバ装置において、前記応答部は、前記付加情報が前記ＩｏＴデバイスのスリープ動作に関する情報である場合、前記ＤＮＳ情報としてＴＴＬの更新情報を採用してもよい。

（６）本発明の一形態によれば、サーバ装置がＩｏＴデバイスと通信する方法が提供される。この方法は、前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する工程と、前記動作情報を記憶装置に記憶させる工程と、前記動作情報の取得に対する応答として、前記サーバ装置のＤＮＳ情報を含む応答を生成し、前記ＩｏＴデバイスに送信する工程と、を備える。

（７）本発明の一形態によれば、ＩｏＴデバイスと通信するサーバ装置において実行されるコンピュータプログラムが提供される。このコンピュータプログラムは、前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する機能と、前記動作情報を記憶装置に記憶させる機能と、前記動作情報の取得に対する応答として、前記サーバ装置のＤＮＳ情報を含む応答を生成し、前記ＩｏＴデバイスに送信する機能と、を備える。

（８）本発明の一形態によれば、ＩｏＴデバイスと通信する通信システムが提供される。この通信システムは、移動体通信網と、前記移動体通信網内に収容されているサーバ装置と、を備える。前記サーバ装置は、前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する取得部と、前記動作情報を記憶装置に記憶させる制御部と、前記動作情報の取得に対する応答として、前記サーバ装置のＤＮＳ情報を含む応答を生成し、前記ＩｏＴデバイスに送信する応答部と、を備える。

（９）本発明の一形態によれば、サーバ装置と通信するＩｏＴデバイスが提供される。このＩｏＴデバイスは、前記サーバ装置のＤＮＳ情報を記憶するＤＮＳ情報記憶部と、前記ＤＮＳ情報に従って、前記サーバ装置に対して、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を送信する送信制御部と、前記サーバ装置から送信された応答を取得し、前記応答に含まれる前記サーバ装置のＤＮＳ情報に基づき、前記ＤＮＳ情報記憶部内に保持されている前記ＤＮＳ情報を更新する受信制御部と、を備える。

なお、本発明は、種々の態様で実現することが可能であり、例えば、ＩｏＴデバイスと通信するサーバ装置、サーバ装置がＩｏＴデバイスと通信する方法、サーバ装置と通信するＩｏＴデバイス、ＩｏＴデバイスがサーバ装置と通信する方法、サーバ装置とＩｏＴデバイスとのうちの少なくとも一方を含む通信システム、これら装置やシステムの機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを配布するためのサーバ装置、そのコンピュータプログラムを記憶した一時的でない記憶媒体等の形態で実現することができる。

本発明によれば、サーバ装置は、ＩｏＴデバイスからの動作情報の取得に対する応答として、サーバ装置のＤＮＳ情報を含む応答を生成し、ＩｏＴデバイスに送信する。応答を受信したＩｏＴデバイスでは、応答に含まれるＤＮＳ情報を利用して、ＩｏＴデバイス内に記憶されているＤＮＳ情報を更新することができる。このため、ＩｏＴデバイス内のＤＮＳ情報が古くなる（有効期限が切れる）事象の発生を抑制することができ、ＩｏＴデバイスにおける名前解決処理の発生頻度を低減させることができる。この結果、ＩｏＴデバイスとの通信に関し、名前解決処理による帯域の圧迫を抑制することができる。

本発明の一実施形態に係るＩｏＴシステムの概略構成を示す図である。 通信サーバの概略構成を示す図である。 センサの概略構成を示す図である。 動作情報取得処理の手順を示すシーケンス図である。 応答処理テーブルの一例を示す図である。 無線信号テーブルの一例を示す図である。 頻度テーブルの一例を示す図である。 時間テーブルの一例を示す図である。 変形例における応答処理テーブルの一例を示す図である。 変形例におけるＩｏＴシステムの概略構成を示す図である。 デバイスへのサービス提供の流れを示すシーケンス図である。

以下、図面を参照して本発明の一実施形態について説明する。

Ａ．実施形態：
（ＩｏＴシステムの構成）
図１は、本発明の一実施形態に係るＩｏＴシステムの概略構成を示す図である。ＩｏＴシステム１は、ＩｏＴデバイスより得られたデータを蓄積し、蓄積されたデータを分析し、フィードバックするシステムである。

本実施形態では、ＩｏＴシステム１は、エアコン６０の管理システムとして構成される場合を例示する。具体的には、センサ３０は、気温、湿度、気圧等を測定し、測定データを通信サーバ１０に送信する（ステップＳ１）。通信サーバ１０は、受信した測定データをデータベースに蓄積する。アプリケーションサーバ５０は、通信サーバ１０から蓄積された測定データを取得する（ステップＳ２）。その後、アプリケーションサーバ５０は、取得した測定データを人工知能等によって解析し（ステップＳ３）、解析結果に応じた温度、湿度、動作モード設定でエアコン６０を駆動させる（ステップＳ４）。なお、図１で例示したシステムの構成はあくまで一例であり、本発明は種々の構成で利用できる。

本実施形態のＩｏＴシステム１は、移動体通信網２に収容されている通信サーバ１０および基地局２０と、センサ３０と、ＤＮＳ（Domain Name System）サーバ４０と、アプリケーションサーバ５０と、エアコン６０とを備える。

通信サーバ１０の構成は後述する。基地局２０は、ＬＰＷＡ（Low Power Wide Area）ネットワークの端に位置して、ＩｏＴデバイス（センサ３０、エアコン６０等）との間で、無線信号の送受信を行う。ＬＰＷＡは、従来の通信技術（例えば、Ｗｉ−Ｆｉ、ＬＴＥ（Long Term Evolution）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等）と比較して、低消費電力、低コストという特徴を持つ。また、ＬＰＷＡは、従来の通信技術（例えば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ等）と比較して、広域通信が可能であるという特徴を持つ。一方で、ＬＰＷＡは、従来の通信技術（例えば、Ｗｉ−Ｆｉ、ＬＴＥ、Ｂｌｕｅｔｏｏｔｈ等）と比較して、データ転送速度（スループット）の最大値が小さく制限されているという特徴を持つ。

このように、ＬＰＷＡネットワークは、ＩｏＴデバイスとの通信に適したネットワークである。本実施形態では、ＬＰＷＡネットワークを実現する通信規格として、ＮＢ−ＩｏＴ（Narrow Band IoT）を例示する。しかし、ＬＰＷＡネットワークを実現する通信規格は、ｅＭＴＣ（enhanced Machine-Type Communications）、ＬｏＲａＷＡＮ（登録商標）、ＩＥＥＥ８０２．１１ａｈ、Ｗｉ−ＳＵＮ（Wireless Smart Utility Network）等、任意の規格を採用でき、これらの組み合わせであってもよい。

センサ３０は、ＩｏＴデバイスとして機能し、温度センサ、湿度センサ、気圧センサ等を含む。センサ３０は、送信制御部（後述）を内蔵し、ＬＰＷＡネットワーク（図１：破線）によって、移動体通信網２の基地局２０と通信する。センサ３０の送信制御部は、以下の動作ａ１〜ａ３を実行する。
（ａ１）ＬＰＷＡネットワークの無線信号強度（ＲＳＲＰ、ＲＳＳＩ等）と、無線信号品質（ＳＮＲ）とを取得する。
（ａ２）所定の送信頻度ＴＦ（回/分）で、定期的に、通信サーバ１０に対してセンシング結果を送信する。なお、動作ａ２のセンシング結果は、「ＩｏＴデバイスが動作した結果得られた情報（動作情報）」に相当する。
（ａ３）動作ａ２の後、所定のスリープ時間ＳＴの間、スリープ状態となる。なお、スリープ時間ＳＴは、ＰＳＭ（Power Saving Mode）Ｔｉｍｅｒ：ｅｘｔｅｎｄｅｄ Ｔ３４１２、ｅＤＲＸ（Extended idle-mode Discontinuous Reception）周期等で表現される。
なお、上述した動作ａ１，ａ３は、後述する動作情報取得処理（図４）において使用しない場合、省略してもよい。図１では１つのセンサ３０のみを図示したが、ＩｏＴシステム１には、多くのセンサが含まれる。各センサは同種のセンサであってもよく、異種のセンサであってもよい。

エアコン６０は、ＩｏＴデバイスとして機能する。エアコン６０は、センサ３０と同様に、図示しない送信制御部を内蔵し、ＬＰＷＡネットワークによって移動体通信網２の基地局２０と通信する。エアコン６０の送信制御部は、以下の動作ｂ１，ｂ２を実行する。
（ｂ１）ＬＰＷＡネットワークの無線信号強度（ＲＳＲＰ、ＲＳＳＩ等）と、無線信号品質（ＳＮＲ）とを取得する。
（ｂ２）所定の送信頻度ＴＦ（回/分）で、定期的に、通信サーバ１０に対して、温度、湿度、動作モード設定等の問い合わせを行う。なお、動作ｂ２の問い合わせは、「ＩｏＴデバイスの動作許可を求める情報（動作情報）」に相当する。
なお、上述した動作ｂ１は、後述する動作情報取得処理（図４）において使用しない場合、省略してもよい。図１では１つのエアコン６０のみを図示したが、ＩｏＴシステム１には多くのデバイスが含まれる。各デバイスは同種のデバイスであってもよく、異種のデバイスであってもよい。

なお、センサ３０は、ＩｏＴシステム１の構成によって（換言すれば、アプリケーションサーバ５０が提供するサービスによって）、種々のＩｏＴデバイスで代替し得る。例えば、加速度センサ、人感センサ、音声を取得するマイク、静止画や動画を取得するカメラ、スマートフォン等が採用されてもよい。同様に、エアコン６０は、ＩｏＴシステム１の構成によって、種々のＩｏＴデバイスで代替し得る。例えば、冷蔵庫、テレビ、ゲーム機、インターフォン、扉のアクチュエータ、電動キー、スマートフォン等が採用されてもよい。また、センサ３０とエアコン６０とは、いずれか一方が省略されてもよく、一方に他方の機能を併合してもよい。

ＤＮＳサーバ４０は、インターネットＩＮＴ上に存在し、ホスト名（またはドメイン名）から宛先アドレスを導き出す名前解決処理（図１１：ステップＳ１０〜Ｓ１４）を行うサーバである。ＤＮＳサーバ４０は、名前解決処理のために、ホスト名（またはドメイン名）と、宛先アドレスとしてのグローバルＩＰアドレスとを対応付けて記憶するデータベースを有している。ＤＮＳサーバ４０は、このデータベースを参照することで、ＤＮＳ名前解決（図１１：ステップＳ１２）を行うことができる。なお、本実施形態のＩｏＴシステム１はオープンネットワークであるため、宛先アドレスとしてグローバルＩＰアドレスを用いる。しかし、ＩｏＴシステム１が閉域ネットワーク内に構築される場合、宛先アドレスとしてローカルＩＰアドレスを利用することができる。

アプリケーションサーバ５０は、インターネットＩＮＴ上に存在し、エアコン６０の管理システムとしての基幹機能を実現するサーバである。上述の通り、アプリケーションサーバ５０は、通信サーバ１０内に蓄積されたセンサ３０の測定データを取得する（ステップＳ２）。その後、アプリケーションサーバ５０は、取得した測定データを人工知能等によって解析して、エアコン６０を動作させる温度、湿度、動作モード等を導きだす。アプリケーションサーバ５０は、エアコン６０からの問い合わせ（エアコン６０：動作ｂ２）への応答として、導きだした温度、湿度、動作モード等を送信する。このようにして、アプリケーションサーバ５０は、通信サーバ１０内に蓄積された膨大な測定データを利用して、エアコン６０を自動制御するサービスを提供することができる。

（通信サーバの構成）
図２は、通信サーバ１０の概略構成を示す図である。本実施形態の通信サーバ１０は、後述の動作情報取得処理を通じて、ＩｏＴデバイス（センサ３０、エアコン６０）内に記憶されているＤＮＳ情報の更新を可能とする。すなわち、本実施形態では、通信サーバ１０が「サーバ装置」として機能する。

通信サーバ１０は、記憶部１１０と、ＣＰＵ１２０と、通信部１３０と、ＲＯＭ／ＲＡＭ１４０とを備えており、各部は図示しないバスにより相互に接続されている。記憶部１１０は、ハードディスク、フラッシュメモリ、メモリカードなどで構成される。記憶部１１０は、応答処理テーブル１１１と、無線信号テーブル１１２と、頻度テーブル１１３と、時間テーブル１１４と、動作情報ＤＢ１１５とが含まれている。詳細は後述する。

ＣＰＵ１２０は、ＲＯＭに格納されているコンピュータプログラムをＲＡＭに展開して実行することにより、通信サーバ１０の各部を制御する。そのほか、ＣＰＵ１２０は、取得部１２１、制御部１２２、応答部１２３としても機能する。これら各部は協働して、後述の動作情報取得処理を実行する。通信部１３０は、他の装置との間における、図示しない通信インターフェースを介した通信を制御する。他の装置には、センサ３０、エアコン６０、ＤＮＳサーバ４０、アプリケーションサーバ５０のほか、図示しない他の装置（スマートフォン、サーバ等）が含まれてもよい。

（ＩｏＴデバイスの構成）
図３は、センサ３０の概略構成を示す図である。本実施形態のセンサ３０は、後述の動作情報取得処理を通じて、自身に記憶されているＤＮＳ情報の更新を行うＩｏＴデバイスである。

センサ３０は、検出部３１０と、ＣＰＵ３２０と、通信部３３０と、記憶部３４０と、を備えており、各部は図示しないバスにより相互に接続されている。検出部３１０は、温度、湿度、気圧等を検出する。通信部３３０は、図示しない通信インターフェースを介して、通信サーバ１０との間における通信を制御する。

ＣＰＵ３２０は、センサ３０の各部を制御するほか、送信制御部３２１、受信制御部３２２、ＤＮＳ処理部３２３として機能する。送信制御部３２１は、上述したセンサ３０の動作ａ１〜ａ３を実行する。受信制御部３２２の詳細は、動作情報取得処理にて後述する。ＤＮＳ処理部３２３は、上述した名前解決処理（図１１：ステップＳ１０〜Ｓ１４）を実行する。名前解決処理の結果得られた通信サーバ１０のＤＮＳ情報は、記憶部３４０のＤＮＳ情報記憶部３４１に格納される。

なお、上記では、ＩｏＴデバイスの一例としてセンサ３０の構成を説明したが、本発明に係るエアコン６０の構成についても、アクチュエータをさらに備える点を除いて、図３と同様である。

（動作情報取得処理）
図４は、動作情報取得処理の手順を示すシーケンス図である。動作情報取得処理は、ＩｏＴデバイスと、通信サーバ１０との間で実行される。図４では、ＩｏＴデバイスの例としてセンサ３０を示すが、エアコン６０と通信サーバ１０との間でも同様の処理が実行される。

ステップＳ１００においてセンサ３０は、ＤＮＳサーバ４０との間で名前解決処理を行う（図１１：ステップＳ１０〜Ｓ１４を参照）。名前解決処理のステップS１０においてセンサ３０は、通信サーバ１０のホスト名を含むＤＮＳ名前解決要求を送信する。その結果、ステップＳ１４においてセンサ３０は、通信サーバ１０の宛先アドレスを取得することができる。

ステップＳ１０２においてセンサ３０は、通信サーバ１０に対して、動作情報と付加情報とを送信する。動作情報は、ＩｏＴデバイスが動作した結果得られた情報であり、センサ３０の場合は、センシング結果である。また、付加情報としては、以下のｃ１〜ｃ３のうちいずれか１つが選択される。
（ｃ１）ＩｏＴデバイスの無線信号に関する情報：センサ３０の場合は上述した手順ａ１（エアコン６０の場合は手順ｂ１）において取得した無線信号強度（ＲＳＲＰ、ＲＳＳＩ等）、無線信号品質（ＳＮＲ）のうちの少なくともいずれか一方。なお、以降の例では、付加情報ｃ１として無線信号強度（ＲＳＲＰ）を用いて説明する。
（ｃ２）ＩｏＴデバイスによる動作情報の送信頻度を示す情報：センサ３０の場合は上述した手順ａ２（エアコン６０の場合は手順ｂ２）における送信頻度ＴＦ（回/分）。
（ｃ３）ＩｏＴデバイスのスリープ動作に関する情報：上述した手順ａ３におけるスリープ時間ＳＴ。なお、以下の例では、付加情報ｃ３として、ＰＳＭ Ｔｉｍｅｒ：ｅｘｔｅｎｄｅｄ Ｔ３４１２を用いて説明する。

ステップＳ１０４において、通信サーバ１０の取得部１２１は、センサ３０から送信された動作情報（センシング結果）と付加情報（付加情報ｃ１〜ｃ３のいずれか１つ）とを取得する。また、ステップＳ１０４において、通信サーバ１０の制御部１２２は、取得された動作情報を、動作情報ＤＢ１１５に格納する。すなわち、動作情報ＤＢ１１５は「記憶装置」として機能する。

ステップＳ１０６〜Ｓ１０８において、通信サーバ１０の応答部１２３は、動作情報の取得（ステップＳ１０４）に対する応答として、通信サーバ１０のＤＮＳ情報を含む応答を生成し、センサ３０へと送信する。具体的には、ステップＳ１０６において応答部１２３は、応答処理テーブル１１１を参照し、ステップＳ１０４で取得した付加情報に応じたＤＮＳ情報を取得する。

図５は、応答処理テーブル１１１の一例を示す図である。本実施形態の応答処理テーブル１１１は、付加情報と、ＤＮＳ情報の内容と、参照テーブルとを対応付けたテーブルである。付加情報には、動作情報取得処理（図４：ステップＳ１０４）において、通信サーバ１０がセンサ３０から取得し得る、全ての付加情報が予め格納されている。ＤＮＳ情報の内容には、各付加情報に対応させて、通信サーバ１０が生成する応答に含めるべきＤＮＳ情報の内容（種類）が予め格納されている。参照テーブルには、通信サーバ１０が応答を生成する際に参照するテーブルの名称が予め格納されている。

エントリＥ１には、付加情報として無線信号強度（ＲＳＲＰ、付加情報ｃ１）を取得した場合、通信サーバ１０の応答部１２３はＴＴＬ（Time To Live）を含む応答を生成すること、応答生成の際には無線信号テーブル１１２を参照することが規定されている。エントリＥ２には、付加情報として送信頻度（回/分、付加情報ｃ２）を取得した場合、応答部１２３は通信サーバ１０の宛先アドレスを含む応答を生成すること、応答生成の際には頻度テーブル１１３を参照することが規定されている。エントリＥ３には、付加情報としてスリープ時間（PSM Timer: extended T3412、付加情報ｃ３）を取得した場合、応答部１２３はＴＴＬを含む応答を生成すること、応答生成の際には時間テーブル１１４を参照することが規定されている。このように通信サーバ１０は、付加情報の種類ｃ１〜ｃ３に応じて、異なるＤＮＳ情報を応答に含めることができる。

図６は、無線信号テーブル１１２の一例を示す図である。本実施形態の無線信号テーブル１１２は、無線信号強度（ＲＳＲＰ）と、ＴＴＬの更新情報とを対応付けたテーブルである。通信サーバ１０の応答部１２３は、無線信号テーブル１１２を検索することで、動作情報取得処理（図４）のステップＳ１０４において取得した無線信号強度（付加情報ｃ１）に応じたＴＴＬの更新情報を取得する。ここで取得したＴＴＬの更新情報は「付加情報に応じたＤＮＳ情報」となる。その後、ステップＳ１０８において応答部１２３は、無線信号テーブル１１２から取得したＴＴＬの更新情報を含む応答を生成し、センサ３０へと送信する。ステップＳ１１０においてセンサ３０の受信制御部３２２は、通信サーバ１０から受信したＴＴＬの更新情報を用いて、センサ３０の内部（ＤＮＳ情報記憶部３４１）に記憶されているＤＮＳ情報のＴＴＬ値を更新する。

センサ３０内部（ＤＮＳ情報記憶部３４１）のＴＴＬ値の更新により、センサ３０内に記憶されている、通信サーバ１０のホスト名と宛先アドレスとの対応付けが破棄されるまでの時間が延長される。このため、センサ３０（ＩｏＴデバイス）が通信サーバ１０へと通信するために行う、再度の名前解決処理（図１１：ステップＳ１０〜Ｓ１４）の実行が抑制され、結果として、名前解決処理の実行に伴う帯域の圧迫を抑制することができる。

なお、無線信号テーブル１１２では、無線信号強度が「−８０ｄＢｍ」、「−９０ｄＢｍ」、「−１００ｄＢｍ」と弱くなっていく（無線信号が不安定になっていく）につれて、ＴＴＬの更新情報が「１０００秒」、「２０００秒」、「３０００秒」と大きく（ＤＮＳ情報の有効期間が長く）設定されている。このため、センサ３０の無線環境に応じて通信回数をコントロールすることができる。具体的には、センサ３０が無線信号の不安定な環境にある場合（ＲＳＲＰ：−１００）は、ＤＮＳ情報の有効期間を長くして通信回数の伸びを抑制することができる。一方、センサ３０が無線信号の比較的安定した環境にある場合（ＲＳＲＰ：−８０）は、ＤＮＳ情報の有効期間を短くしてセキュリティを向上させることができる。

図７は、頻度テーブル１１３の一例を示す図である。本実施形態の頻度テーブル１１３は、送信頻度（回/分）と、宛先アドレスとを対応付けたテーブルである。通信サーバ１０の宛先アドレスは、主としてセキュリティ上の理由から時間経過に伴い変更されることがある。頻度テーブル１１３の宛先アドレスには、通信サーバ１０の最新の宛先アドレスが格納されている。なお、図７の例では、通信サーバ１０が複数の宛先アドレスを持つ構成、すなわち、通信サーバ１０が複数のサーバから構成され負荷分散が可能な構成について挙げている。通信サーバ１０が負荷分散を行わない場合、宛先アドレスには同一の宛先アドレスが格納される。

通信サーバ１０の応答部１２３は、頻度テーブル１１３を検索することで、動作情報取得処理（図４）のステップＳ１０４において取得した送信頻度（付加情報ｃ２）に応じた宛先アドレスを取得する。ここで取得した宛先アドレスは「付加情報に応じたＤＮＳ情報」となる。その後、ステップＳ１０８において応答部１２３は、頻度テーブル１１３から取得した宛先アドレスを含む応答を生成し、センサ３０へと送信する。ステップＳ１１０においてセンサ３０の受信制御部３２２は、通信サーバ１０から受信した宛先アドレスを用いて、センサ３０の内部（ＤＮＳ情報記憶部３４１）に記憶されているＤＮＳ情報の宛先アドレスを更新する。

センサ３０内部（ＤＮＳ情報記憶部３４１）の宛先アドレスの更新により、センサ３０内に記憶されている通信サーバ１０のホスト名と宛先アドレスとの対応付けが更新される。このため、センサ３０（ＩｏＴデバイス）が通信サーバ１０へと通信するために行う、再度の名前解決処理（図１１：ステップＳ１０〜Ｓ１４）の実行が抑制され、結果として、名前解決処理の実行に伴う帯域の圧迫を抑制することができる。

なお、頻度テーブル１１３では、送信頻度の値に応じて、異なる通信サーバ１０の宛先アドレスが設定されている。このため、センサ３０による動作情報の送信頻度に応じて、接続先となる通信サーバ１０をコントロールすることができる。

図８は、時間テーブル１１４の一例を示す図である。本実施形態の時間テーブル１１４は、スリープ時間（PSM Timer: extended T3412）と、ＴＴＬの更新情報とを対応付けたテーブルである。通信サーバ１０の応答部１２３は、時間テーブル１１４を検索することで、動作情報取得処理（図４）のステップＳ１０４において取得したスリープ時間（付加情報ｃ３）に応じたＴＴＬの更新情報を取得する。ここで取得したＴＴＬの更新情報は、「付加情報に応じたＤＮＳ情報」となる。その後、ステップＳ１０８およびＳ１１０における、通信サーバ１０およびセンサ３０の動作、ＴＴＬ値の更新により得られる効果は、図６で説明した通りである。

なお、時間テーブル１１４では、スリープ時間が「１０分」、「３０分」、「６０分」と長くなっていくにつれて、ＴＴＬの更新情報が「１０００秒」、「２０００秒」、「３０００秒」と大きく（ＤＮＳ情報の有効期間が長く）設定されている。このように、センサ３０のスリープ時間に合わせてＤＮＳの有効期間を設定することで、センサ３０のスリープ中にＤＮＳの有効期間が切れてしまう事象の発生を抑制することができる。

以上説明した通り、本発明によれば、サーバ装置（通信サーバ１０）は、ＩｏＴデバイス（センサ３０、エアコン６０）からの動作情報の取得（図４：ステップＳ１０４）に対する応答として、サーバ装置のＤＮＳ情報（ＴＴＬの更新情報、宛先アドレス）を含む応答を生成（図４：ステップＳ１０６）し、ＩｏＴデバイスに送信する（図４：ステップＳ１０８）。応答を受信したＩｏＴデバイスでは、応答に含まれるＤＮＳ情報を利用して、ＩｏＴデバイス内に記憶されているＤＮＳ情報（ＤＮＳ情報記憶部３４１）を更新することができる。このため、ＩｏＴデバイス内のＤＮＳ情報が古くなる（有効期限が切れる）事象の発生を抑制することができ、ＩｏＴデバイスにおける名前解決処理（図４：ステップＳ１００、図１１：ステップＳ１０〜Ｓ１４）の発生頻度を低減させることができる。この結果、ＩｏＴデバイスとの通信に関し、名前解決処理に起因する、ＬＰＷＡネットワークの帯域の圧迫を抑制することができる。

Ｂ．変形例：
上述した各実施態様において、ハードウェアによって実現されるとした構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されるとした構成の一部をハードウェアに置き換えるようにしてもよい。その他、以下のような変形も可能である。

図９は、変形例における応答処理テーブル１１１ａの一例を示す図である。上記実施形態では、付加情報の種類ｃ１〜ｃ３に応じて、異なる１つのＤＮＳ情報（ＴＴＬの更新情報と、宛先アドレスとの一方）を応答に含めることとした。しかし、図９に示すように、応答に含めるＤＮＳ情報は、複数（ＴＴＬの更新情報と宛先アドレスの両方）であってもよい。この場合、応答に含めるＤＮＳ情報に応じて、参照テーブルの内容も変更する。

上記実施形態では、応答処理テーブル１１１を利用して、付加情報の種類ｃ１〜ｃ３に応じて、異なるＤＮＳ情報を応答した。具体的には、付加情報ｃ１（無線信号強度）の場合はＴＴＬを応答し、付加情報ｃ２（送信頻度）の場合は宛先アドレスを応答し、付加情報ｃ３（スリープ時間）の場合はＴＴＬを応答することとした。しかし、これらの組み合わせは適宜変更することができる。

上記実施形態では、付加情報の種類ｃ１〜ｃ３に応じて、応答処理テーブル１１１を利用し、異なるＤＮＳ情報を応答した。しかし、動作情報取得処理（図４）における付加情報の送信および取得と、応答処理テーブル１１１とは省略してもよい。この場合、通信サーバ１０は、動作情報取得処理（図４）のステップＳ１０４における動作情報の取得を契機として、付加情報の種類に関係なく、特定のＤＮＳ情報を応答に含めることができる。特定のＤＮＳ情報とは、ＴＴＬの更新情報であってもよく、宛先アドレスであってもよく、これらの組み合わせであってもよい。

上記実施形態では、ＤＮＳ情報として、ＴＴＬの更新情報と、宛先アドレスとを例示した。しかし、ＤＮＳ情報としては、その他の種々の情報（例えば、ＳＯＡの更新間隔、転送再試行時間、レコード有効時間等、ホスト名、ホスト名のエイリアス等）が採用され得る。

上記実施形態では、無線信号テーブル１１２、頻度テーブル１１３、時間テーブル１１４の内容の一例を挙げた。しかし、各テーブル内のデータは、求められる性能や仕様に応じて、適宜変更することができる。例えば、ＩｏＴデバイス（センサ３０、エアコン６０）からの動作情報の重要度に応じて、ＴＴＬの更新情報に設定される時間を決定してもよい。この場合、重要度が高い場合はＴＴＬの更新情報を短くしてセキュリティを向上させ、重要度が低い場合はＴＴＬの更新情報を長くして送受信頻度を低減させることが好ましい。例えば、ＬＰＷＡネットワークが混雑する時間帯を避けた時間帯（例えば、深夜や早朝）にＩｏＴデバイス（センサ３０、エアコン６０）と通信サーバ１０との通信が発生するように、ＴＴＬの更新情報に設定される時間を決定してもよい。

上記実施形態では、付加情報ｃ１〜ｃ３の一例を挙げた。しかし、付加情報としては、無線信号強度、送信頻度、スリープ時間以外の情報を利用することができる。例えば、ＩｏＴデバイスの重要度（優先度）、動作情報の重要度（優先度）、ＩｏＴデバイスの種類、ＬＰＷＡネットワークの種類、繰り返し送信回数（Ｒｅｐｅｔｉｔｉｏｎ数）などＣｏｖｅｒａｇｅ Ｅｎｈａｎｃｅｍｅｎｔに係る通信制御パラメータ情報等が利用できる。

上記実施形態では、動作情報取得処理（図４）の一例を挙げた。しかし、動作情報取得処理は、種々の変形が可能であり、実行するステップの順序を変更してもよく、一部のステップを省略してもよく、説明にない他のステップを追加してもよい。例えば、通信サーバ１０からＩｏＴデバイス（センサ３０、エアコン６０）に対して送信する応答に、ＤＮＳ情報以外の他の情報を含めてもよい。他の情報としては、例えば、次にＩｏＴデバイスから通信サーバ１０への通信を行うタイミングを指定する情報、通信サーバ１０の状態（正常、異常、混雑度等）を表す情報等を採用できる。

図１０は、変形例におけるＩｏＴシステム１ａの概略構成を示す図である。上記実施形態では、通信サーバ１０は、移動体通信網２に収容されているとした。しかし、図１０に示すように、通信サーバ１０ａは、インターネットＩＮＴ上に位置してもよい。また、図１０に示すように、通信サーバ１０ａは、上述したアプリケーションサーバ５０の機能を兼ね備えたサーバとして構成されてもよい。また、通信サーバ１０ａは、インターネットＩＮＴ上にあって、かつ、アプリケーションサーバ５０とは別のサーバとして構成されてもよい。

上記実施形態では、移動体通信網２には、通信サーバ１０と基地局２０とが収容されているとした。しかし、移動体通信網２には、他の装置が収容されていてもよい。例えば、ＤＨＣＰサーバが収容された場合、通信サーバ１０は、ＤＨＣＰサーバと協働して、ＩｏＴデバイスに対するＤＨＣＰリース時間を、ＩｏＴデバイス以外のデバイスに対するＤＨＣＰリース時間と比較して長くするよう動作してもよい。この場合、通信サーバ１０は、動作情報の取得に対する応答に、ＤＮＳ情報と、ＤＨＣＰリース時間に関する情報と、を含める。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、上記実施の形態に示す構成を適宜組み合わせることとしてもよい。

１…ＩｏＴシステム
２…移動体通信網
１０…通信サーバ
２０…基地局
３０…センサ
４０…ＤＮＳサーバ
５０…アプリケーションサーバ
６０…エアコン
１１０…記憶部
１１１…応答処理テーブル
１１２…無線信号テーブル
１１３…頻度テーブル
１１４…時間テーブル
１２０…ＣＰＵ
１２１…取得部
１２２…制御部
１２３…応答部
１３０…通信部
１４０…ＲＯＭ／ＲＡＭ
１１５…動作情報ＤＢ
３１０…検出部
３２０…ＣＰＵ
３２１…送信制御部
３２２…受信制御部
３２３…ＤＮＳ処理部
３３０…通信部
３４０…記憶部
３４１…ＤＮＳ情報記憶部

Claims (8)

1. サーバ装置と通信するための当該サーバ装置のＤＮＳ情報を記憶するＩｏＴデバイスと通信するサーバ装置であって、
   前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する取得部と、
   前記動作情報を記憶装置に記憶させる制御部と、
   前記動作情報の取得に対する応答として、前記サーバ装置の前記ＤＮＳ情報を更新させる更新情報を含む応答を生成し、前記ＩｏＴデバイスに送信する応答部と、
   を備え、
   前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、
   前記応答部は、前記付加情報の種類に応じて、前記更新情報における前記ＤＮＳ情報の内容を変更する、サーバ装置。
2. 請求項１に記載のサーバ装置であって、
   前記応答部は、前記付加情報が前記ＩｏＴデバイスの無線信号に関する情報である場合、前記ＤＮＳ情報としてＴＴＬの更新情報を採用する、サーバ装置。
3. 請求項１または請求項２に記載のサーバ装置であって、
   前記応答部は、前記付加情報が前記ＩｏＴデバイスによる前記動作情報の送信頻度を示す情報である場合、前記ＤＮＳ情報として前記サーバ装置の最新の宛先アドレスを採用する、サーバ装置。
4. 請求項１から請求項３のいずれか一項に記載のサーバ装置であって、
   前記応答部は、前記付加情報が前記ＩｏＴデバイスのスリープ動作に関する情報である場合、前記ＤＮＳ情報としてＴＴＬの更新情報を採用する、サーバ装置。
5. サーバ装置が、当該サーバ装置と通信するための当該サーバ装置のＤＮＳ情報を記憶するＩｏＴデバイスと通信する方法であって、
   前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する工程と、
   前記動作情報を記憶装置に記憶させる工程と、
   前記動作情報の取得に対する応答として、前記サーバ装置の前記ＤＮＳ情報を更新させる更新情報を含む応答を生成し、前記ＩｏＴデバイスに送信する工程と、
   を備え、
   前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、前記付加情報の種類に応じて、前記更新情報における前記ＤＮＳ情報の内容が変更される、方法。
6. サーバ装置と通信するための当該サーバ装置のＤＮＳ情報を記憶するＩｏＴデバイスと通信する当該サーバ装置において実行されるコンピュータプログラムであって、
   前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する機能と、
   前記動作情報を記憶装置に記憶させる機能と、
   前記動作情報の取得に対する応答として、前記サーバ装置の前記ＤＮＳ情報を更新させる更新情報を含む応答を生成し、前記ＩｏＴデバイスに送信する機能と、
   を備え、
   前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、前記付加情報の種類に応じて、前記更新情報における前記ＤＮＳ情報の内容が変更される、コンピュータプログラム。
7. サーバ装置と通信するための当該サーバ装置のＤＮＳ情報を記憶するＩｏＴデバイスと通信する通信システムであって、
   移動体通信網と、
   前記移動体通信網内に収容されている前記サーバ装置と、
   を備え、
   前記サーバ装置は、
   前記ＩｏＴデバイスから送信された動作情報であって、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を取得する取得部と、
   前記動作情報を記憶装置に記憶させる制御部と、
   前記動作情報の取得に対する応答として、前記サーバ装置の前記ＤＮＳ情報を更新させる更新情報を含む応答を生成し、前記ＩｏＴデバイスに送信する応答部と、
   を備え、
   前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、前記付加情報の種類に応じて、前記更新情報における前記ＤＮＳ情報の内容が変更される、通信システム。
8. サーバ装置と通信するための当該サーバ装置のＤＮＳ情報を記憶するＩｏＴデバイスであって、
   前記サーバ装置のＤＮＳ情報を記憶するＤＮＳ情報記憶部と、
   前記ＤＮＳ情報に従って、前記サーバ装置に対して、前記ＩｏＴデバイスが動作した結果得られた情報と、前記ＩｏＴデバイスの動作許可を求める情報とのうちの少なくとも一方を含む動作情報を送信する送信制御部と、
   前記サーバ装置から送信された応答を取得し、前記応答に含まれる前記サーバ装置の前記ＤＮＳ情報を更新させる更新情報に基づき、前記ＤＮＳ情報記憶部内に保持されている前記ＤＮＳ情報を更新する受信制御部と、
   を備え、
   前記動作情報には、さらに、前記ＩｏＴデバイスに関する情報である付加情報が含まれ、前記付加情報の種類に応じて、前記更新情報における前記ＤＮＳ情報の内容を変更する、ＩｏＴデバイス。
   

Images