【文献】
サービスゲートウェイ向けECHONET Liteバンドルの開発 Development of ECHONET Lite Bundle for Service Gateway,情報処理学会 論文誌(トランザクション) コンシューマ・デバイス&システム(CDS) Vol.3 No.3 [online],2013年 7月31日,第20-29頁
【文献】
暮らしを支えるネットワーク技術 Network Technologies for Life and Society,三菱電機技報 第87巻 第5号,2013年 5月25日,第13(271)−18(276)頁
(58)【調査した分野】(Int.Cl.,DB名)
ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
アプリケーション層の通信プロトコルとしてCoAP(Constrained Application Protocol)上でECHONET Liteを動作させる場合に、
通信処理及び前記機器の制御のための演算を行う演算手段と、
データを格納するデータ格納手段、
前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
ECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリから、前記通信ノードが制御・管理・監視する機器の機器情報を取得し、前記データ格納手段に格納する手段と、
ECHONET LiteとCoAPの組み合わせによるメッセージを受信して、該メッセージに応じた機器の制御を前記通信制御手段を介して実行し、また、該通信制御手段からの信号を受け付け、該ECHONET LiteとCoAPの組み合わせによるメッセージを送信するアプリケーション手段と、
前記アプリケーション手段から取得した前記ECHONET Liteフレームの解析を行い、処理結果を該アプリケーション手段に解析結果を渡すことにより前記機器の制御を指示し、該アプリケーション手段からの命令に基づいてECHONET Liteフレームを構築するECHONET Lite処理手段と、
CoAPクライアント機能(ietf-draft-core-coap-17, Constrained Application Protocol(CoAP))及びCoAPサーバ機能を備え、前記通信制御手段を介して取得したCoAPメッセージを処理し、該メッセージがECHONET LiteとCoAPの組み合わせのメッセージである場合に、前記ECHONET Lite処理手段に処理結果を渡して機器の制御を指示し、また、該ECHONET Lite処理手段からの命令と前記ECHONET Liteフレームに従って、該ECHONET LiteとCoAPを組み合わせたCoAPメッセージを生成し、前記通信制御手段を介して、該制御対象の機器に送信するCoAP処理手段と、
を有することを特徴とする通信ノード。
アプリケーション層の通信プロトコルとして、前記CoAP上で、前記ECHONET Liteを動作させる場合に、OSI第4層(トランスポート層)の通信プロトコルのみならず、OSI第5〜第7層の通信プロトコルに位置するCoAPとの複合的な組み合わせを用いる手段を含む
請求項1記載の通信ノード。
ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
アプリケーション層の通信プロトコルとしてHTTP(Hypertext Transfer Protocol)上でECHONET Liteを動作させる場合に、
通信処理及び前記機器の制御のための演算を行う演算手段と、
データを格納するデータ格納手段、
前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
ECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリから、前記通信ノードが制御・管理・監視する機器の機器情報を取得し、前記データ格納手段に格納する手段と、
ECHONET LiteとHTTPの組み合わせによるメッセージを受信して、該メッセージに応じた機器の制御を前記通信制御手段を介して実行し、また、該通信制御手段からの信号を受け付け、該ECHONET LiteとHTTPの組み合わせによるメッセージを送信するアプリケーション手段と、
前記アプリケーション手段から取得した前記ECHONET Liteフレームの解析を行い、処理結果を該アプリケーション手段に解析結果を渡すことにより前記機器の制御を指示し、該アプリケーション手段からの命令に基づいてECHONET Liteフレームを構築するECHONET Lite処理手段と、
HTTPクライアント機能(ietf-draft-core-coap-17, Constrained Application Protocol(CoAP))及びHTTPサーバ機能を備え、前記通信制御手段を介して取得したHTTPメッセージを処理し、該メッセージがECHONET LiteとHTTPの組み合わせのメッセージである場合に、前記ECHONET Lite処理手段に処理結果を渡して機器の制御を指示し、また、該ECHONET Lite処理手段からの命令と前記ECHONET Liteフレームに従って、該ECHONET LiteとHTTPを組み合わせたHTTPメッセージを生成し、前記通信制御手段と前記広域ネットワークを介して、該制御対象の機器に送信するHTTP処理手段と、
を有することを特徴とする通信ノード。
ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
アプリケーション層の通信プロトコルとしてTCP(Transmission Control Protocol)上でECHONET Liteを動作させる場合に、
通信処理及び前記機器の制御のための演算を行う演算手段と、
データを格納するデータ格納手段、
前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
ECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリに対してECHONET Lite通知要求フレームを送信することにより、前記通信ノードが制御・管理・監視する機器の機器情報の一覧を取得し、管理端末に送信する機器情報取得手段と、
前記管理端末からの指示に従って、制御対象の機器情報及び制御内容に応じてECHONET Liteフレームを生成するECHONET Lite処理手段と、
前記ECHONET LiteフレームからTCPメッセージを生成し、前記通信制御手段と前記広域ネットワークを介して、該制御対象の機器に送信するTCP処理手段と、
を有することを特徴とする通信ノード。
ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
アプリケーション層の通信プロトコルとしてTCP(Transmission Control Protocol)上でECHONET Liteを動作させる場合に、
通信処理及び前記機器の制御のための演算を行う演算手段と、
データを格納するデータ格納手段、
前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
機器から機器情報を取得すると、該機器のアドレス情報、種別、能力を記憶手段に格納し、自ノードが通信に利用可能なIPアドレス・ポート番号の組の中から該機器に対する制御、管理、監視のメッセージを受け取るためのIPアドレス・ポート番号の組を選び出し、該IPアドレス、ポート番号の組と、該機器のアドレス情報の対応関係を記憶し、該IPアドレス・ポート番号を用いてリソースディレクトリへのTCPコネクションを確立し、該機器情報を該リソースディレクトリに登録する機器情報登録手段と、
機器に対する制御、管理、監視を行うための管理ノードから受信したTCPメッセージがECHONET Liteフレームを含む場合、該TCPメッセージを受信したIPアドレス及びポート番号の組と、該組が対応する機器のアドレスの対応関係のリストを検索し、検索されたIPアドレス・ポート番号の組が自ノードで直接制御、管理、監視を受け付ける機器に対応するリソースである場合には、該ECHONET Liteフレームを処理するECHONET Lite処理手段と、
検索されたIPアドレス・ポート番号の組が自ノードで直接制御、管理、監視を受け付ける機器に対応するリソースでない場合には、該IPアドレス・ポート番号の組が対応する機器が用いている通信規格を処理する通信処理手段に前記ECHONET Liteフレームを送信するアプリケーション手段と、
を有し、
前記通信処理手段は、
前記アプリケーション手段から前記ECHONET Liteフレームを取得すると、前記機器へ各通信規格の通信手順に従って該ECHONET Liteフレームを送信する手段を含む
ことを特徴とする通信ノード。
ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
UDP/TCPの上で直接、ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を相互運用する場合に、
通信処理及び前記機器の制御のための演算を行う演算手段と、
データを格納するデータ格納手段、
前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
アプリケーション層のプロトコルに対応するリソースディレクトリの情報を取得するリソースディレクトリ情報取得手段と、
機器の制御、管理、監視を直接受け付ける場合に、前記リソースディレクトリに対して自ノードのリソース情報を登録するリソース情報登録手段と、
前記機器から機器情報を受け取ると、該機器のアドレス情報を記憶手段に格納し、該機器に対する制御、管理、監視メッセージを受け取るためのリソースを生成し、該リソースと該機器のアドレス情報の対応関係を該記憶手段に格納し、該リソースを前記リソースディレクトリに登録する機器情報登録手段と、
既に前記リソースディレクトリに前記リソースと機器のアドレス情報の対応関係が登録されていて、新たな機器情報を受信した場合には、該新たな機器情報で、該リソースディレクトリを更新する更新手段と、
を有することを特徴とする通信ノード。
【発明を実施するための形態】
【0017】
以下、図面と共に本発明の実施の形態を説明する。
【0018】
本発明は、既存技術ECHONET Liteを、その他の既存技術の一部と組み合わせた上で、更に不足する部分を、ECHONET Lite及び組み合わせる既存技術の双方に極力影響しない技術によって実現することで、完全な新規技術の開発を必要としない低コストな通信ノード及びネットワークシステム及び通信方法を提供するものである。
【0019】
図1は、本発明の一実施の形態におけるシステム構成例を示す。
【0020】
同図に示すシステムは、通信ネットワーク1、機器10(10A,10B,10C)、管理ノード20、データベース30、管理端末40、中間ノード50を有する。
【0021】
通信ネットワーク1は、インターネット、家庭内LAN、その他情報通信ネットワーク、あるいはその任意の組み合わせであって、TCP/IP通信が可能なネットワーク、Bluetooth(登録商標)、Zigbee(登録商標)などの非TCP/IP技術に基づく通信ネットワークを含む。
【0022】
機器10は、通信ネットワーク1を介して、本発明の技術を用いて互いに通信を行う機器である。複数の同一または異なる機器が、同一の通信ネットワーク(例えば、IPサブネットワーク)に接続していてもよく、複数の異なる通信ネットワーク1に分散して接続していてもよい。この機器10は、場合によっては後述する「中間ノード」として動作してもよい。本例では、中間ノード50が機器10とは個別に配置されるものとして説明する。
【0023】
データベース30は、通信ネットワーク1を介して、機器10との通信を行い、システムに存在する機器の通信アドレス、種別、能力の情報を取得・管理するデータベースである。単一のデータベースであってもよく、複数のデータベースが同一のデータを保持する多重化構成をとってもよく、また、複数のデータベースが異なるデータを持ち補完的に動作する構成をとってもよい。本発明では、例えば、後述のDNS(Domain Name System)サーバ、CoAP(Constrained Application Protocol)リソースディレクトリ、ECHONET Liteディレクトリなどとして振舞う。
【0024】
管理ノード20は、本発明の技術を用いて、通信ネットワーク1を介して機器10及びデータベース30と通信を行い、機器の電源状態、動作モード、設定等の制御・管理・監視を行うノードである。単一のノードであってもよく、複数の同一ノードを多重的に設置してあってもよく、目的・役割毎に異なるノードを一つずつ、または、複数ずつ設置してあってもよい。管理者が直接管理ノードを操作・設定してもよく、後述の管理端末40を用いて管理ノード20と通信を行い、遠隔から管理ノード20を操作・設定してもよい。また、本発明における機器10が管理ノードを兼ねてもよい。
【0025】
管理端末40は、管理ノード20を直接操作・設定できない管理者が、通信ネットワーク1を介して遠隔から管理ノード20と接続及び通信を行い、機器の制御・管理・監視を行うために用いる端末である。通信ネットワーク1を介して、管理ノード20が提供する通信インタフェースにしたがって通信を行うことのできる任意の端末であり、例えば、パーソナルコンピュータ、タブレット端末、スマートフォン、携帯電話などであってもよい。
【0026】
以下では、アプリケーション層の通信ネットワークプロトコル毎及びTCPにおける適用例を説明する。
【0027】
第1の実施の形態では、CoAP(例えば、非特許文献2:ietf-draft-core-coap-17, Constrained Application Protocol(CoAP))の上で非特許文献1の技術を動作させる例を説明する。
【0028】
第2の実施の形態では、HTTP(Hypertext Transfer Protocol)(例えば、非特許文献3:RFC2616, Hyper Text Transfer Protocol(HTTP))上で非特許文献1の技術を動作させる例を説明する。
【0029】
上記の第1、第2の実施の形態では、非特許文献1の技術を、非特許文献1上で規定するようにトランスポート層の通信プロトコルの上で単純に動作させるのではなく、再送制御機能、及び、機器のアドレス、種別、能力の情報の管理・発見機能を持つ特定のアプリケーション層の通信プロトコル(CoAP、HTTP)と複合的に組み合わせて動作することによってインターネット等の広域ネットワークを介した大規模なシステムとして、非特許文献1の技術による機器の制御・管理・監視を可能とする。
【0030】
第3の実施の形態では、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる例を説明する。
【0031】
上記の第3の実施の形態では、非特許文献1で規定するようにトランスポート層の通信プロトコルの上で単純に動作させる場合においても、再送制御機能を持つTCPをトランスポートプロトコルとして使用し、TCPが提供しない機器のアドレス、種別、能力の情報の管理・発見機能をマルチキャストに依存しない方法により実現することで、インターネット等の広域ネットワークを介した非特許文献1の技術による機器の制御・管理・監視を可能とする。
【0032】
第4の実施の形態では、本発明の技術をサポートしないUDP/TCPの上で直接ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を、本発明の技術と相互運用可能にし、かつ、または、それらの機器の間に中間ノードが介在して機器情報の交換やアドレス解決の支援を行う例を説明する。
【0033】
[第1の実施の形態]
本実施の形態では、アプリケーション層の通信プロトコルとしてCoAPの上で非特許文献1の技術を動作させる場合について説明する。
【0034】
図2は、本発明の第1の実施の形態における機器の構成例を示す。
【0035】
同図に示す機器10Aは、CPU・メモリ11、機器インタフェース12、機器制御部13、アプリケーション部14、ECHONET Lite処理部15、CoAP処理部16A、通信制御部17、通信インタフェース18を有する。
【0036】
CPU・メモリ11は、通信処理、機器制御等のための演算を行う演算装置及びデータ格納部である。簡便を期して一体表記しているが、個別に具備してもよい。
【0037】
機器インタフェース12及び機器制御部13は、機器固有の入出力及びそれを制御するインタフェースであり、機器によって異なる。基本や湿度等の値を読み取るセンサ、冷風や温風を送出するファン、LEDを発光させるための回路、それらを制御するためのインタフェースがその例である。
【0038】
アプリケーション部14は、本発明におけるECHONET LiteとCoAPの組み合わせによるメッセージを受信して、それに応じた機器の制御を機器制御部13を介して実行し、また、機器制御部13からの信号を受け付け、ECHONET Lite処理部15、CoAP処理部16Aを介して、本発明のECHONET LiteとCoAPの組み合わせによるメッセージをECHONET Lite処理部15に渡す。
【0039】
ECHONET Lite処理部15は、非特許文献1のECHONET Liteフレームの解析を行い、処理結果をアプリケーション部14からの命令に従って非特許文献1のECHONET Liteフレームを構築し、CoAP処理部16Aに渡してCoAPメッセージの作成・送信を指示する。
【0040】
CoAP処理部16Aは、非特許文献2のCoAPクライアント機能及びCoAPサーバ機能を備え、通信制御部17から渡されたCoAPメッセージを処理し、その結果、本発明におけるCoAPとECHONET Liteの組み合わせによるメッセージである場合に、ECHONET Lite処理部15に処理結果を渡して、機器10Aの制御等を指示する。また、ECHONET Lite処理部15からの命令とECHONET Liteフレームにしたがって、本発明におけるECHONET LiteとCoAPを組み合わせたCoAPメッセージを構築し、通信制御部17を介して通信ネットワーク上にメッセージを送信する。
【0041】
通信制御部17及び通信インタフェース18は、機器10Aが通信ネットワーク1に接続して他の機器と通信するための入出力及びそれを制御するインタフェースである。物理インタフェースの例としてEthernet(登録商標)がある。
【0042】
図3は、本発明の第1の実施の形態における管理ノードの構成例である。
【0043】
管理ノード20は、CPU・メモリ21、アプリケーション部24、ECHONET Lite処理部25、CoAP処理部26A、通信制御部27、通信インタフェース28を有する。
【0044】
管理ノード20は、ECHONET LiteとCoAPを組み合わせて機器10Aの制御・管理・監視のための通信を行うものの、自らは機器の制御・管理・監視を受け付けることをしない。管理ノード20は、
図2の機器10Aとは異なり、機器インタフェース12、機器制御部13を持たない場合があり、
図3はその例を示している。なお、管理ノード20が機器10Aを兼ねる場合は、
図2の機器の構成と同じ機能を有する。
【0045】
本実施の形態における機器10A及び管理ノード20に用いる通信プロトコルは
図4に示すとおりである。物理層(PHY)、データリンク層(MAC)は任意である。ネットワーク層は、IPv4またはIPv6のいずれかを用いる。トランスポート層はUDPを用いる。また、DTLS(Datagram TLS)を用いてもよい。
【0046】
図5は、本発明の第1の実施の形態における中間ノードの構成例である。中間ノード50は、
図2の機器10と同様の構成であるので、各部の説明は省略する。
【0047】
本実施の形態において、本発明をサポートしない通常のECHONET Lite機器を収容するための、中間ノード50の通信プロトコル構成の例を以下に示す。
【0048】
本発明の技術と通常のUDP上でのECHONET Lite技術の相互運用を行う場合の中間ノード50の通信プロトコル構成例を
図6に示す。この他、CoAPではなく、HTTPを用いる場合、UDPとTCPの相互変換を行う場合、PHY、MAC、IP層の相互変換を行わない場合、及びそれらの組み合わせの場合があり得るが、記載は省略する。
【0049】
また、本発明の技術と通常のECHONET Lite機器を収容するための中間ノード50の通信プロトコル構成を
図7に示す。
図7は、本発明の技術と非IP通信規格上でのECHONET Lite技術の相互運用を行うため、CoAP層以下のIP系プロトコルと、非IP通信規格との相互変換を行う場合の例である。
【0050】
<ECHONET Liteの拡張・変更>
以下に、アプリケーション層の通信プロトコルとして、CoAP上でECHONET Liteの技術を動作させる場合のECHONET Liteに対する拡張・変更を示す。
【0051】
ECHONET Liteは、OSI(Open System Interconnection)第4層(トランスポート層)の通信プロトコルの上で動作するだけでなく、OSI第5〜7層の通信プロトコルの組み合わせによって動作するものとする。具体的には、OSI第5〜7層の通信プロトコルに位置するCoAPとの複合的な組み合わせによって動作するものとする。
【0052】
ECHONET LiteをCoAPと組み合わせて用いる場合、トランスポート層の通信プロトコルにはUDPを用いるものとする。UDPを用いる場合には、送信先ポート番号は、"5683"とする。ただし、それ以外のポート番号を用いてもよい。トランスポート層のセキュリティメカニズムにDTLS(Datagram Transport Layer Security)を用いてもよい。DTLSを用いる場合は、送信先のポート番号は、IANA(Internet Assigned Numbers Authority)にサービス名"coaps"で登録されたポート番号を用いるが、それ以外のポート番号を利用してもよい。該ポート番号が未登録である場合は、任意のポートを利用してもよい。
【0053】
ECHONET LiteをCoAPと組み合わせて用いる場合、ネットワーク層の通信プロトコルにはIPv4もしくはIPv6を用いるものとする。IPアドレスの範囲、取得方法は規定しない。一斉同報に用いるIPマルチキャストアドレスは、非特許文献2で定めるIPv4マルチキャストアドレス及びIPv6マルチキャストアドレスを用いる。ネットワーク層のセキュリティメカニズムにIPSecを用いても良い。
【0054】
本実施の形態では、CoAPメッセージのペイロード部にECHONET Liteフレームが設定されていることを示すための、Content-Formatオプションに設定するMedia Type及びIDを、非特許文献2及びIANA MIME Media Typeで定義されているMedia Type及びIDと重複しない形で定義する。定義の例は、
図8に示す通りである。但し、
図8はあくまでも一例であり、これ以外のMedia Type及びIDを排除するものではない。
【0055】
さらに、CoAP URIで特定されるリソースのうち、どのリソースが本発明におけるECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付けるのかを示すための識別子を定義する。定義の例を以下に示す。
【0056】
<例1>
well-known URI(非特許文献4:RFC5785, Defining Well-known Uniform Resource Identifiers)による共通リソース識別子の定義:
非特許文献4で定義される、ホストの情報を取得するための共通URIプレフィックスである/.well-knownを利用する。
【0057】
本発明における機器10Aが、本発明のECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を、
coap://ホスト:ポート/.well-known/共通リソース識別子
のURIで指定されるリソースで一元的に受け付ける。同じホストが複数のECHONET Liteオブジェクトを持つ場合でも、それぞれ異なるリソースでその制御等を受け付けるのではなく、全てのオブジェクトに対する制御等を全てこのリソースで受け付ける。
【0058】
上記の"coap"については、DTLS利用時は"coaps"を用いる。ホストはIPアドレスまたはFQDN(Fully Qualified Domain Name)を用いる。ポートは利用するUDPポート番号を用いる(省略可)。リソース識別子はIANAに登録されている他のwell-known URIと重複しない文字列を用いる。定義の一例は、"echnonet-lite"である。識別子を"echnonet-lite"として定義した場合に、ホスト名、ポート番号を仮定したURIの例を以下に示す。
【0059】
coap://light01.bldg01.example.org:5683/.well-known/echonet-lite
<例2> CoRE link Format(非特許文献5:RFC6690, Core Link Format)によるリソース識別子の定義:
非特許文献5で定義される、rtアトリビュートを用いて、あるCoAP URIで指定されるリソースが、本発明におけるECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付けることを示す識別子を定義する。
【0060】
識別子は、あるリソースが、本発明のECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付ける、という情報のみを示し、そのリソースが実際に対応するECHONET Liteオブジェクトまでは特定できない形で定義してもよい。また、あるリソースが実際に対応するECHONET Liteも同時に特定できる形で定義してもよい。
【0062】
rt="echonet-lite" (rtのみを使用し、ifは使用しない場合)
rt="echonet-lite",if=http://www.example.org/echonet-lite.wadl (本発明におけるECHONET LiteとCoAPの組み合わせで用いるCoAPインタフェース仕様をWADL(Web Application Description Language)形式で記述し、それを参照する場合)
後者の例を次に示す。
【0063】
rt="echonet-lite.0x029001" (リソースが対応するECHONET Liteオブジェクトが照明装置(0x029001)であり、ifは使用しない場合)
rt="light",if="echonet-lite.0x029001"(種別が照明であることをrtで示し、その制御が本発明の技術で可能であることをifで示す場合)
rt="echonet-lit",if="echonet-lite.0x029001&0x029002&0x013001" (本発明のECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付けるリソースであることをrtで示し、対応するECHONET Liteオブジェクトとして、2つの照明機器(0x29001,0x029002)と家庭用エアコン(0x13001)があることをifで示す場合)
次に、リソースディレクトリの発見方法の例を示す。
【0064】
本実施の形態において、機器10AがCoAPリソースディレクトリ(非特許文献6:Internet-Draft, draft-shelby-core-resource-directory-05, CoRE Resource Directory)をDNS-SD(Service Discovery)を用いて発見する方法の一例を示す。
【0065】
DNSサーバには、予め、ドメイン(以下の例では、example.com)におけるCoAPリソースディレクトリの情報を、DNS-SD(RFC6763)及び、CoREリソースディレクトリ情報のDNS-SDマッピング技術(draft-lynn-core-discovery-mapping)(非特許文献7:Internet-Draft, draft-lynn-core-discovery-mapping, Core Link-Format to DNS-Based Service Discovery Mapping)に従って設定する。設定は、管理者が手動で実施しても良く、リソースディレクトリまたは代理エージェントプログラムが通信により実施してもよい。
【0066】
データベース30内のDNSサーバに設定するDNSリソースレコードの例を
図9に示す。
【0067】
DNSサーバには、予めドメイン(以下の例ではexample.com)におけるCoAPリソースディレクトリの情報を、DNS-SD(RFC6763)、及びCoREリソースディレクトリ情報のDNS-SDマッピング技術(非特許文献7:Internet-Draft, draft-lynn-core-discovery-mapping, Core Link-Format to DNS-Based Service Discovery)に従って設定する。設定は、管理者が手動で実施してもよく、リソースディレクトリまたは代理エージェントプログラムが通信により実施しても良い。
【0068】
設定するDNSリソースのレコードの例を
図9(B)に示す。
【0069】
機器10Aは、このDNSサーバに対して、ドメインに存在するCoAPリソースディレクトリの情報の検索を実行する。
【0070】
以下、
図9(B)の設定例においては、ドメインにおいてCoAPリソースディレクトリは、"rd1.example.com"というFQDNをもつホストが、リソース登録(/rd)、グループ登録(rd-group)、リソース検索(rd-lookup)の3つの機能セットとして、共にUDPポート番号"5683"、アプリケーションプロトコルcore(CoAPを意味するDNS Service Typeの定義例である)で提供している、ということを、機器10AからDNSサーバへの通常のDNSクエリによって知ることができる。
【0071】
機器10Aは、このDNSサーバへの検索によって取得したCoAPリソースディレクトリのアドレス及びパス情報を用いて、以降に示す自らのリソース情報の登録を実施する。
【0072】
次に、機器10Aによるリソースの登録の例を2通り説明する。
【0073】
図10は、本発明の第1の実施の形態における機器によるリソース登録の例(その1)である。
【0074】
機器10Aは、DHCP(Domestic Host configuration Protocol)オプション、DNS-SDなどの何らかの手段で発見した、ドメイン上のリソースディレクトリ(データベース30)に対して、自らがホストするECHONET Liteによる機器の制御・管理・監視を受け付けるリソースの情報を、CoAP POSTを送信することで登録する。
【0075】
リクエストURLパラメータとして、自らをドメイン内で一意に特定する識別子を"ep=node1"として設定し、ECHONET Liteによる機器の制御・管理・監視を全て一括して"/echo"というリソースで受け付けることを示す情報を、POSTメッセージへのペイロード部にRFC6690のCoRE Link Format形式で設定する。このとき、前述の識別子の定義の例の<例2>で述べたリソース識別子を設定する(以下の例では、rt=echonet-lite)。
【0076】
リソースディレクトリへのリソースの登録処理を行い、機器10Aへレスポンスを返却する。このレスポンスには、今後、機器10Aが登録された該リソースの情報の変更、削除等を行う際にメッセージを送信すべきリソースのURLパスが、Locationオプションで指定される。
【0077】
なお、以下の例では、機器10Aとデータベース30との間での認証、認可手順は省略しているが、先立って認証、認可の手順が実行されてもよい。
【0078】
なお、
図10の例では、CoAPメッセージは、可読性向上のためテキストで例示しているが、本来は非特許文献2に従ってバイナリフォーマットで記述される。
機器によるリソース情報の登録は、前述の識別子の定義の例の<例1>で述べた共通的リソース識別子を用いる場合は必ずしも実施する必要はないが、実施してもよい。
【0079】
図11は、本発明の第1の実施の形態における機器によるリソース登録の例(その2)である。
【0080】
ここでは、
図10の例とは異なり、ECHONET Liteによる機器の制御・管理・監視を、全て1つのリソースで一括して受け付けるのではなく、いくつかのリソースに分けて受け付ける場合の例を示す。
【0081】
リソースを登録するためのCoAP POSTメッセージのペイロードに、ECHONET Liteによる機器の制御・管理・監視を受け付ける自らの全てのリソースの一覧を、RRC6690 Core Link Formatの形式で設定する。それぞれのリソースには、前述の識別子の定義の例の<例2>で述べたリソース識別子を、rtアトリビュートとして設定する。以下の例では、照明(rt=echonet-lite.0x0290)の制御・管理・監視をリソース"/echo/light"で、エアコンの制御・管理・監視をリソース"/echo/aircon"で受け付けることを示している。それ以外は前述(
図10)の例と同様である。
【0082】
次に、機器の制御・管理・監視のための管理ノード20の処理について
図12に沿って説明する。
【0083】
ステップ101)機器10Aの制御・管理・監視を行う管理ノード20は、データベース30から
図9の説明で記載したCoAPリソースディレクトリの発見を行い、CoAPリソースディレクトリの情報を取得する。その後、同リソースディレクトリに対して通信を行い、自らが、制御・管理・監視を行うことのできる機器及びそのアドレス、種別、能力の情報を取得する。管理ノード20は、この手順を定期的に実行してもよく、ユーザ、または管理端末からの指示に応じて実行してもよい。
【0084】
ステップ102)管理ノード20のアプリケーション部24は、この情報をメモリ21内に格納した上で、管理ノード20を操作するユーザに対してグラフィカルユーザインタフェースを用いて一覧表示する。または、通信により管理ノード20のアプリケーションを操作する管理端末40のアプリケーションに対して一覧の情報を送信する。
【0085】
ステップ103)管理ノード20のアプリケーション部24は、ユーザないしは管理端末のアプリケーションからの指示に従って、ECHONET Lite処理部25に処理を渡す。
【0086】
ステップ104)ECHONET Lite処理部25は、制御対象の機器の種別、及び、制御内容に応じて適切なECHONET Liteフレームを生成し、CoAP処理部26Aに処理を渡す。
【0087】
ステップ105)CoAP処理部26Aは、当該ECHONET Liteフレームをペイロード部に設定した適切なCoAPメッセージを生成し、制御対象の機器10Aを、必要に応じてDNSサーバ(データベース30)へのDNSクエリを用いて、制御・管理対象の機器10のアドレスを解決した上で、通信制御部27に処理を渡す。
【0088】
ステップ106)通信制御部27は、UDP/DTLSの通信を開始し、当該CoAPメッセージを通信相手のIPアドレス・ポート番号へ送信する。
【0089】
次に、機器10Aが管理ノード20から上記のCoAPメッセージを受信した場合の処理を
図12に沿って説明する。
【0090】
ステップ107)管理ノード20から機器10Aの通信インタフェース18を介して受信したメッセージを受け取った通信制御部17は、メッセージのトランスポートプロトコル、宛先IPアドレス、宛先ポート番号から受信したCoAPメッセージであると判断した場合、CoAP処理部16Aに処理を渡す。それ以外のメッセージ(例えば、ICMP(Internet Control Message Protocol)など)の場合は、そのメッセージを処理する上位の処理部へ処理を渡す。
【0091】
ステップ108)CoAP処理部16Aは、受け取ったCoAPメッセージを解析し、非特許文献2に従って処理する。但し、受け取ったメッセージがCoAPリスクエストである場合は、Content-Typeオプションの値をチェックし、
図8に示した、CoAPペイロードとしてのECHONET Liteフレームであることを示す識別子が設定されている場合は、ペイロード部のECHONET Liteフレームを取り出し、ECHONET Lite処理部15に渡す。それ以外のペイロードが設定されている場合は、非特許文献2に従って通常のCoAPサーバとして処理を行う。
【0092】
ステップ109)ECHONET Lite処理部15は、受け取ったECHONET Liteフレームを、非特許文献1に従って処理し、必要に応じて機器の制御・管理・監視を実行する。非特許文献1に従って、応答を返却する場合は、応答のためのECHONET Liteフレームを生成して、CoAP処理部16Aに返す。
【0093】
ステップ110)CoAP処理部16Aは、ECHONET Lite処理部15から直ちに応答処理を受け取った場合は、応答ECHONET Liteフレームをペイロードとして設定した適切なCoAPメッセージを生成して、応答先へ送信するよう通信制御部17に処理を渡す。
【0094】
ステップ111)ECHONET Lite処理部15から直ちに応答処理がない場合は、非特許文献2に従って非同期応答を実行する。
【0095】
上記で用いられる非特許文献1で定義されるECHONET Liteサービス(要求用)と非特許文献2で定義されるCoAPメソッドのマッピングについて説明する。
【0096】
図13は、本発明の第1の実施の形態におけるECHONET Liteサービス(要求用)とCoAPメソッドのマッピングの例を示す。
【0097】
プロパティ値の書き込み要求及び書き込み・読み出し要求については、CoAP PUTメソッドを用いる。
【0098】
プロパティ値の読み出し要求については、CoAP GETメソッドを用いる。
【0099】
プロパティ値書き込み要求(応答不要)については、CoAPメッセージタイプに"NON"を用いるが、それ以外については"CON"を用いる。但し、それ以外のものについても、一斉同報によって送信する場合、あるいは、メッセージを送信するアプリケーションが自ら再送タイマを起動するなどによって、応答がない場合の再送制御を実行することができる場合は、"NON"を用いるようにすることもできる。
【0100】
次に、ECHONET Liteサービス(応答用)とCoAPレスポンスのマッピングについて説明する。
【0101】
図14は、本発明の第1の実施の形態におけるECHONET Liteサービス(応答用)とCoAPレスポンスのマッピングの例を示す。
【0102】
上記で利用される、非特許文献1で定義されるECHONET Liteサービス(ESV)(応答用)と、非特許文献2で定義されるCoAPレスポンスのマッピングについて説明する。
【0103】
CoAPメッセージタイプは、受信した要求のCoAPメッセージタイプが"CON"であり、かつ応答を即時返却できる場合は、"ACK"を用いる。受信した要求のCoAPメッセージタイプが"CON"であるが、応答を遅延して返却する場合は、"CON"を用いる(但し、非特許文献2に従い、遅延して応答を返却する前に、受信した要求に対して空のCoAPメッセージを返却する)。受信した要求のCoAPメッセージタイプが"NON"である場合は、"NON"を用いる。
【0104】
次に、非特許文献1で定義されるECHONET Liteサービス(通知・通知応答)と非特許文献2で定義されるCoAPメソッド・レスポンスのマッピングについて説明する。
【0105】
図15は、本発明の第1の実施の形態におけるECHONET Liteサービス(通知・通知応答)とCoAPメソッド・レスポンスのマッピングの例を示す。
【0106】
プロパティ値要求は、ECHONET Lite通知要求フレームをペイロード部に格納したCoAP POSTリクエストを送信することで実施する。CoAPメッセージタイプは"CON"を用いる。
【0107】
プロパティ値の通知は、応答の要・不要を問わず、ECHONET Lite通知フレームをペイロード部に格納したCoAP POSTリクエストを送信することで実施する。CoAPメッセージタイプは、応答の要・不要いずれかの場合も"CON"を用いる。但し、プロパティ値通知(0x73)を一斉同報で送信する場合には、"NON"を用いる。
【0108】
プロパティ値通知応答は、2.04Changedを用いる。プロパティ値通知不可応答は、ECHONET Lite処理部15において、要求を受け付けない場合、あるいは指定された送信先オブジェクト(DEOJ)は存在するが、指定されたアクセス先プロパティ(EPC)が存在しない場合は、"4.03Forbidden"を用いる。ECHONET Lite処理部15において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合、あるいは、読み出し要求される全プロパティ値を返そうとしたが許されるECHONET Lite電文長を超える場合には、"5.00Server Internal Error"を用いる。
【0109】
次に、非特許文献1で定義されるECHONET Liteサービス(不可応答用)とCoAPレスポンスのマッピングについて説明する。
【0110】
図16は、本発明の第1の実施の形態におけるECHONET Liteサービス(不可応答用)とCoAPレスポンスのマッピング例を示す。
【0111】
ECHONET Lite処理部15において、要求を受け付けない場合、あるいは指定されたDEOJは存在するが、指定されたEPCが存在しない場合は、"4.03 Forbiden"を用いる。
【0112】
ECHONET Lite処理部15において、指定されたEDOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合は、"5.00Server Internal Error"を用いる。
【0113】
CoAPメッセージタイプについては、
図14で説明したルールに従う。
【0114】
次に、上記の機器の制御・管理・監視のためのECHONET Liteフレームを含むCoAPメッセージについて説明する。
【0115】
管理ノード20のCoAP処理部26Aは、CoAPメッセージのペイロード部に、非特許文献1で定義されるECHONET Liteフレームをそのまま格納する。このとき、CoAPオプションとして、Content-Formatオプションに、
図8に示すECHONET Liteフレームを表すMedia Typeを設定する。
【0116】
例えば、非特許文献1で定義される住宅・設備関連機器クラスグループ・一般照明クラスに属する照明装置(DEOJ=0x29001)の動作状態(EPC=0x80をON(EDT=0x30)にする。つまり、電源を入れる場合には
図17に示すようなメッセージを生成する。
図17の例では、照明装置を具備する機器10Aが、coap://light01.bldg01.example.org/と指定されるリソースで、当該照明装置の制御・管理・監視を受け付ける。照明装置に対応するECHONET Liteオブジェクトはインスタンス番号"0x01"でインスタンス化されている。
【0117】
制御メッセージの送信元の管理ノード20は、非特許文献1で定義される管理・操作関連機器クラスグループ・コントローラクラスに属するコントローラ装置(SEOJ=0x05FF01)である。
【0118】
当該CoAPメッセージのContent-Formatオプションには、
図8の例で示した"application/echonet-light"を設定している(実際には、オプションIDである"100"が設定される)。
【0119】
なお、
図17の例は、可読性のためにCoAPメッセージ、ECHONET Liteフレームともにテキスト形式で記しているが、それぞれ非特許文献2及び非特許文献1でそれぞれ定義されるメッセージフォーマットに従ってバイナリエンコードされる。
【0120】
次に、中間ノード50について説明する。なお、
図1では、中間ノード50として通信ネットワーク1に接続される構成としているが、前述したように、機器10が中間ノードとして動作するようにしてもよい。なお、中間ノード50は、機器10と同様の構成として説明する。
【0121】
中間ノード50は、本発明の技術をサポートしないUDP/TCP上で直接ECHONET Liteを動作させる機器、及び非IP通信規格の上でECHONET Liteを動作させる機器を、本発明の技術と相互運用可能にするため、かつ/または、それらの機器の間に介在して機器情報の交換やアドレス解決の支援を行うためのノードである。
【0122】
システム全体において、中間ノード50は唯一存在してもよく、複数存在してもよい。
【0123】
本発明において、アプリケーション層の通信プロトコルとして、CoAP上で非特許文献1の技術を動作させる場合の中間ノード50の処理のリソース管理処理の例を以下に示す。
【0124】
中間ノード50は、起動後、
図9の説明と同様に、データベース30からCoAPリソースディレクトリの情報を取得する。
【0125】
中間ノード50が自らも本発明の技術をサポートする機器として振る舞い、機器10Aの制御・管理・監視を直接受け付ける場合には、
図11で説明したように、該リソースディレクトリに対して自らのリソース情報を登録する。
【0126】
中間ノード50は、通信ネットワーク1上で非特許文献1の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、その機器のアドレス、種別、能力の情報を記憶し、その機器に対する本発明の制御・管理・監視メッセージを受け取るためのCoAP URLで特定されるリソースを生成し、該リソースと該機器のアドレス情報(IPアドレス、ポート番号の組、もしくは、当該機器が非IP通信規格を用いている場合は、当該通信規格における通信アドレス)の対応関係を記憶し、生成した当該リソースの情報をリソースディレクトリ(データベース30)へ登録する。既に一つ以上のリソースの対応関係を持つ機器から新たな機器情報を受信した場合は、既にリソースに対応付けられたものである機器情報については、それが対応するリソースの情報を更新した上で、リソースディレクトリに対しても更新処理を行う。既に一つ以上のリソースの対応関係を持つ機器からの機器情報ではあるが、対応するリソースがまだ生成されていない機器情報については、当該機器と対応するリソースのうちのいずれかに、新たに受信した当該機器情報を追加する形で更新し、リソースディレクトリに更新処理を行っていってもよく、また、新規にリソースを生成して該機器のアドレスとの関係を記憶し、生成した当該リソースの情報をリソースディレクトリに登録してもよい。
【0127】
なお、中間ノード50は、リソースディレクトリを兼ねてもよい。
【0128】
次に、中間ノード50の機器の制御・管理・監視メッセージ受信処理を説明する。
【0129】
中間ノード50は、前述の機器10Aによるメッセージ受信処理と同様に、CoAP処理部において、CoAPペイロードがECHONET Liteフレームであること識別すると、自らがホストとするリソースと、そのリソースが対応する機器アドレスの対応関係のリストを検索し、当該CoAPメッセージの宛先リソースが、自らが直接制御・管理・監視を受ける機器10の対応するリソースである場合は、当該ECHONET LiteフレームをECHONET Lite処理部55に渡す。当該CoAPメッセージの宛先リソースが、自らが直接制御・管理・監視を受ける機器ではなく、上記の本発明の技術をサポートしない通常のECHONET Lite機器に対応するリソースである場合には、ECHONET Lite処理部55に処理を渡さず、アプリケーションへ処理を渡す。アプリケーションは、当該リソースが対応する機器の用いている通信規格を処理する処理部(当該機器がTCP/IPを用いている場合は、通信処理部、非IP通信規格を用いている場合は、非IP通信規格の通信処理部)へ、当該ECHONET Liteフレームを渡し、当該機器へ各通信規格の通信手順によってECHONET Liteフレームを送信させる。例えば、当該機器10がUDP/IPを用いている場合は、取り出したECHONET Liteフレーム及び当該フレームを送信すべき機器のアドレス情報を通信処理部に渡して、非特許文献1に従う通常のUDP上で動作するECHONET Liteフレームを持つIPパケットとして、当該機器10へ送信する。
【0130】
[第2の実施の形態]
本実施の形態では、アプリケーション層の通信プロトコルとして、HTTP上のECHONET Liteを動作させる場合の例を示す。
【0131】
まず、機器10Bの構成を
図18に示す。同図に示す機器10Bは、
図2のCoAP処理部16Aに代わりに、HTTP処理部16Bを備えた点において異なる。
【0132】
次に、管理ノード20Bの構成を
図19に示す。同図に示す管理ノード20Bは、
図3のCoAP処理部26Aの代わりに、HTTP処理部26Bを備えた点において異なる。なお、
図19に示す構成の他、通常考え得るこの他の構成をとってもよい。なお、管理ノード20Bが機器の機能を兼ねる場合は、
図18の機器10Bの例と同じ構成を有する。また、中間ノード50も同様に、機器の機能を兼ねる場合には、
図18の機器と同様の構成を有する。
【0133】
以下に、本発明を実現するための非特許文献1の技術(ECHONET Lite)に対する拡張・変更を以下に示す。
【0134】
本実施の形態では、通信プロトコルとして、HTTP上で非特許文献1の技術を動作させるための機器10B,管理ノード20Bを動作させるための通信プロトコルとして、
図20に示す通信プロトコル構成を用いる。
【0135】
なお、物理層(PHY)、データリンク層(MAC)は任意である。ネットワーク層は、IPv4またはIPv6のいずれかである。トランスポート層は、TCPを用いる。TLS(Datagram TLS)を用いてもよい。
【0136】
OSI第4層(トランスポート層)の通信プロトコルの上で動作するだけでなく、OSI第5〜7層の通信プロトコルとの組み合わせによっても動作するものとする。具体的には、OSI第5〜7層の通信プロトコルに位置付けられるHTTPとの複合的な組み合わせによっても動作するものとする。
【0137】
HTTPと組み合わせて用いる場合、トランスポート層の通信プロトコルにはTCPを用いるものとする。TCPを用いる場合には、送信先のポート番号は"80"とする。但し、それ以外のポート番号を用いても良い。トランスポート層のセキュリティメカニズムにTLS(Transport Layer Security)を用いても良い。TLSを用いる場合は、送信先のポート番号は"443"を用いるが、それ以外のポート番号を利用してもよい。
【0138】
HTTPと組み合わせて用いる場合、ネットワーク層の通信プロトコルにはIPv4もしくはIPv6を用いるものとする。IPアドレスの範囲、取得方法は特に指定しない。ネットワーク層のセキュリティメカニズムには、IPSecを用いても良い。
【0139】
HTTPメッセージのペイロード部に非特許文献1のECHONET Liteフレームが設定されていることを示すための、Content-Typeヘッダに設定するMedia Typeを、既にIANA MIME Media Typeで定義されているMedia Typeと重複しない形で定義する。定義の例は、"application/echonet-lite"であるが、これ以外の定義を排除しない。
【0140】
本実施の形態において、HTTP URIで特定されるリソースのうち、どのリソースが本発明におけるECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付けるのかを示すための識別子を定義する。定義の例は以下の通りである。但し、これ以外の定義を排除しない。
【0141】
<例1>
well-known URI(非特許文献4)による共通リソース識別子の定義:
非特許文献4で定義される、ホストの情報を取得するための共通URIプレフィックスである"/.well-known"を利用する。
【0142】
本発明における機器10Bが、本発明のECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を、
http://ホスト:ポート/.well-known/共通リソース識別子
のURIで指定されるリソースで一元的に受け付ける。同じホストが複数のECHONET Liteオブジェクトを持つ場合でも、それぞれ異なるリソースでその制御等を受け付けるのではなく、全てのオブジェクトに対する制御等を全てこのリソースで受け付ける。
【0143】
httpは、TLS利用時はhttpsを用いる。ホストはIPアドレスまたはFQDNを用いる。ポートは利用するTCPポート番号を用いる(省略可)。リソース識別子はIANAに登録されている他のwell-known URIと重複しない文字列を用いる。定義の一例は、"echnonet-lite"である。識別子を"echnonet-lite"として定義した場合に、ホスト名、ポート番号を仮定したURIの例を以下に示す。
【0144】
http://light01.bldg01.example.org:8080/.well-known/echonet-lite
<例2> CoRE link Format(非特許文献5によるリソース識別子の定義:
非特許文献5で定義される、rtアトリビュートを用いて、あるHTP URIで指定されるリソースが、本発明におけるECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付けることを示す識別子を定義する。
【0145】
識別子は、あるリソースが、本発明のECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付ける、という情報のみを示し、そのリソースが実際に対応するECHONET Liteオブジェクトまでは特定できない形で定義してもよい。また、あるリソースが実際に対応するECHONET Liteも同時に特定できる形で定義してもよい。
【0147】
rt="echonet-lite" (rtのみを使用し、ifは使用しない場合)
rt="echonet-lite",if=http://www.example.org/echonet-lite.wadl (本発明におけるECHONET LiteとHTTPの組み合わせで用いるCoAPインタフェース仕様をWADL形式で記述し、それを参照する場合)
後者の例を次に示す。
【0148】
rt="echonet-lite.0x029001" (リソースが対応するECHONET Liteオブジェクトが照明装置(0x029001)であり、ifは使用しない場合)
rt="light",if="echonet-lite.0x029001"(種別が照明であることをrtで示し、その制御が本発明の技術で可能であることをifで示す場合)
rt="echonet-lit",if="echonet-lite.0x029001&0x029002&0x013001" (本発明のECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付けるリソースであることをrtで示し、対応するECHONET Liteオブジェクトとして、2つの照明機器(0x29001,0x029002)と家庭用エアコン(0x13001)が有ることをifで示す場合)
次に、機器10Bの動作を説明する。
【0149】
図21は、本発明の第2の実施の形態における機器の動作のフローチャートである。
【0150】
ステップ201) 機器10Bを起動する。
【0151】
ステップ202) 通信制御部17は、上記に示した通信インタフェース18を開始する。
【0152】
ステップ203) 通信制御部17は、通信インタフェース18を介してIPアドレスを取得し、CPU・メモリ11に設定する。このときのプロトコルはDHCP(Dynamic Host configuration Protocol)、IPv6ND(Neighbor Discovery)などのメカニズムを用いても良いし、静的に設定してあってもよい。
【0153】
ステップ204) 通信制御部17は、通信ネットワーク1を介してデータベース30からリソースディレクトリの探索を行う。このとき、DHCPオプションを用いても良いし、静的に設定してあってもよい。
【0154】
ステップ205) ステップ204により発見したリソースディレクトリに自己リソースの登録を行う。
【0155】
以下に、詳細に説明する。機器10Bによるリソース登録の例を
図22に示す。
【0156】
機器10Bは、上記のステップ204において、DHCPオプション、DNS-SDなどの何らかの手段で発見したドメイン上のリソースディレクトリ(データベース30)に対して、自らがホストするECHONET Liteによる機器の制御・管理・監視を受け付けるリソースの情報を、HTTP POSTメッセージを送信することで登録する。
【0157】
リクエストURLパラメータとして、自らをドメイン内で一意に特定する識別子"ep=node1"として設定し、ECHONET Liteによる機器の制御・管理・監視を全て一括して"/ech o"というリソースで受け付けることを示す情報を、POSTメッセージのペイロード部に、RFC6690のCore Link Format形式で設定する。このとき、上記の<例1>、<例2>で述べたリソース識別子を設定する(以下の例では、rt=echonet-lite)。
【0158】
複数のリソースでECHONET Liteによる機器の制御・管理・監視を受け付ける場合は、第1の実施の形態におけるCoAPの場合と同様のペイロードをHTTP POSTメッセージに設定する。
【0159】
なお、
図22の例では、機器10Bとデータベース30との間で認証、認可手段は省略しているが、先立って認証、認可の手順が実行されてもよい。
【0160】
次に、本実施の形態におけるECHONET Liteサービス(要求用)とHTTPメソッドのマッピングの例を示す。
【0161】
本実施の形態において、アプリケーション層の通信プロトコルとして、HTTP上で非特許文献1の行う際に、ECHONET Liteサービス(ESV)と、HTTPメソッドのマッピングの例は
図23に示ように、プロパティ値の書き込み要求及び書き込み・読み出し要求については、HTTP PUTメソッドを用いる。プロパティ値の読み出し要求については、HTTP GETメソッドを用いる。
【0162】
また、
図24に、非特許文献1で定義されるECHONET Lite(ESV)(応答用)とHTTPレスポンスのマッピングの例を示す。プロパティ値書き込み応答、プロパティ値読出し応答、プロパティ値書き込み・読み出し応答に"200OK"を用いる。
【0163】
さらに、ECHONET Liteサービス(通知・通知応答用)とHTTPメソッド・レスポンスのマッピングを
図25に示す。
【0164】
プロパティ値通知要求は、管理ノード20Bにおいて、ECHONET Lite処理部25が生成したECHONET Lite通知要求フレームをHTTP処理部26BがHTTP POSTリクエストのペイロードに設定して通信制御部27を介して送信される。HTTPメッセージタイプは"CON"を用いる。
【0165】
プロパティ値の通知は、応答の要・不要を問わず、ECHONET Lite通知フレームをペイロード部に格納したHTTP POSTリクエストを送信することで実施する。
【0166】
プロパティ値通知不可応答は、ECHONET Lite処理部15において、要求を受け付けない場合、あるいは指定されたDEOJは存在するが、指定されたEPCが存在しない場合は、403 Forbiddenを用いる。ECHONET Lite処理部15において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合、あるいは、読み出し要求される全プロパティ値を返そうとしたが、許されるECHONET Lite電文長を超える場合には、500 Server Internal Errorを用いる。
【0167】
次に、非特許文献1で定義されるECHONET Liteサービス(ESV)(不可応答用)とHTTPレスポンスのマッピングの例を
図26に示す。
【0168】
機器10BのECHONET Lite処理部15において、要求を受け付けない場合、あるいは、指定されたDEOJは存在するが指定されたEPCが存在しない場合は、403 Forbiddenを用いる。
【0169】
ECHONET Lite処理部15において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合は、500 Server Internal Errorを用いる。
【0170】
次に、アプリケーション層の通信プロトコルHTTP上で非特許文献1の技術を動作させる場合の、機器の制御・管理・監視のためのECHONET Liteフレームを含むHTTPメッセージの例を以下に示す。
【0171】
管理ノード20は、HTTPメッセージのペイロード部に非特許文献1で定義されるECHONET Liteフレームをそのまま格納する。このとき、HTTPヘッダとして、Content-Typeヘッダに、IANA MIME Media Typeで定義されているECHONET Liteフレームを表すMedia Typeを設定する。
【0172】
例えば、非特許文献1で定義される住宅・設備関連機器クラスグループ・一般照明クラスに属する照明装置(DEOJ=0x029001)の動作状態(EPC=0x80)をON(EDT=0x30)にする。つまり、電源を入れる場合のメッセージを
図27に示す。
【0173】
この例では、照明装置を具備する機器が、
http://light01.bldg01.example.org/
というURIで指定されるリソースで、同照明装置の制御・管理・監視を受け付ける。照明装置に対応するECHONET Liteオブジェクトは、インスタンス番号"0x01"でインスタンス化されている。
【0174】
制御メッセージの送信元の管理ノード20Bは、非特許文献1で定義される管理・操作関連機器クラスグループ・コントローラクラスに属するコントローラ装置(SEOJ=0x05FF01)である。
【0175】
HTTPメッセージのContent-Formatオプションには、"application/echonet-lite"を設定している。なお、
図27の例は、可読性のためECHONET Liteフレームをテキスト形式で記しているが、実際には、非特許文献1で定義されるメッセージフォーマットに従ってバイナリエンコードされる。
【0176】
[第3の実施の形態]
本実施の形態では、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる場合について説明する。
【0177】
図29は、本発明の第3の実施の形態における処理のシーケンスチャートである。
【0178】
以下では、機器10Cと中間ノード50がローカルネットワークで接続され、また、中間ノード50が通信ネットワーク1に接続されているものとして説明する。
【0179】
ステップ301) UDP上でECHONET Liteを動作させる通常の機器10Cは、ローカルネットワーク上に自らの機器情報(アドレス、種別、能力等)を示すECHONET Liteフレームを広告する。
【0180】
ステップ302) 中間ノード50は、上記のECHONET Liteフレームを受信し、通信ネットワーク1に対して、自身があたかも機器10Cであるかのように見せるため、通信ネットワーク1からアクセス可能なECHONET Liteディレクトリ(データベース30)へ機器10Cの機器情報を代理登録する。
【0181】
ステップ303) TCP上でECHONET Liteを動作させる管理ノード20は、通信ネットワーク1からECHONET Liteディレクトリ(データベース30)を検索して、中間ノード50が代理登録した機器10Cの情報を取得する。
【0182】
ステップ304) 管理ノード20は、取得した情報に従って、中間ノード50に対して制御のためのECHONET Liteメッセージを送信する。
【0183】
ステップ305) 中間ノード50は、上記ステップ304のECHONET Liteメッセージを受信し、当該メッセージ内容に準じたECHONET LiteフレームをUDP上で機器10Cに対して送信し、機器10Cを制御する。
【0184】
ステップ306) 機器10Cからの応答メッセージを中間ノード50において、TCPに載せ換えて管理ノード20に送信する。
【0185】
以上のように動作することで、UDPとTCPの相互変換を行いつつ、通信ネットワーク1とローカルネットワークの間でECHONET Liteを用いて機器制御が可能となる。
【0186】
TCP上でECHONET Liteを動作させる場合の機器10C及び管理ノード20の用いる通信プロトコル構成は
図28に示す通りである。また、中間ノードは
図30または、
図31に示す通信プロトコルを用いる。
【0187】
物理層(PHY)、データリンク層(MAC)は任意である。
【0188】
ネットワーク層は、IPv4またはIPv6のいずれかである。また、トランスポート層はTCPを用いる。TLSを用いてもよい。
【0189】
次に、機器の接続先発見方法について説明する。
【0190】
図32は、本発明の第3の実施の形態における接続機器の接続先発見方法の例を示す。
【0191】
本発明において、アプリケーション層の通信プロトコルではなく、TCPの上でECHONET Liteを動作させる場合の、機器10Cの用いる接続先の発見方法の例を示す。
【0192】
機器10Cは、第1の実施の形態と同様の構成を有し、
図9のDNS-SDを用いたCoAPリソースディレクトリの発見の同様の手順で、TCP上でECHONET Liteを動作させる際に接続するECHONET Liteディレクトリの情報を取得することができる。これ以外に、DHCPオプションで取得したり、静的に設定してある値を読み込む等の他の手順で取得してもよい。
【0193】
次に、機器30Cによる機器情報通知の例を説明する。
【0194】
図33は、本発明の第3の実施の形態における機器による機器情報通知の例であり、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる場合の、ECHONET Lite機器情報の通知の例を示す。なお、
図33では、機器10Cとデータベース30との間で認証、認可手順は省略しているが、先立って認証、許可の手順が実行されてもよい。
【0195】
機器10Cは、DHCPオプション、DNS-SDなど何らかの手段で発見した、ドメイン上のECHONET Liteリソースディレクトリ(データベース30)に対して、自らのECHONET Lite機器情報を、非特許文献1に記載されたマルチキャストパケットとしてではなく、該リソースディレクトリに対するTCPコネクションを確立した上でユニキャストパケットとして、TCPペイロードとしてECHONET Lite通知フレームを設定して送信する。
【0196】
機器10Cの制御・管理・監視のための管理ノード20の処理の例を説明する。当該管理ノード20は、第1または第2の実施の形態と同様の構成を有するが、異なる処理を行うため、管理ノード20Cとして説明する。
【0197】
なお、当該管理ノード20Cは、
図3に示す通信制御部27を、TCP通信を制御するための通信制御部27Cとして動作するものとして説明する。
【0198】
制御・管理・監視を行う管理ノード20Cは、
図32に示したECHONET Liteリソースディレクトリの発見を行い、リソースディレクトリの情報を取得する。その後、同リソースディレクトリに対してECHONET Lite通知要求フレームを送信して、自らが制御・管理・監視を行うことのできる機器及びそのアドレス、種別、能力の情報の一覧を取得する。管理ノード20Cは、この手順を定期的に実行してもよく、ユーザまたは管理端末40からの指示に応じて実行してもよい。
【0199】
管理ノード20Cのアプリケーション部24Cは、この情報をメモリ21C内に格納した上で、管理ノード20Cを操作するユーザに対してグラフィカルユーザインタフェースを用いて一覧表示する、または、通信により管理ノード20Cのアプリケーション部24Cを操作する管理端末40のアプリケーションに対して一覧の情報を送信する。
【0200】
管理ノード20Cのアプリケーション部24Cは、ユーザないしは管理端末40のアプリケーションからの指示に従って、ECHONET Lite処理部25Cに処理を渡す。
【0201】
ECHONET Lite処理部25Cは、制御対象の機器10Cの種別、及び制御内容に応じて適切なECHONET Liteフレームを生成し、TCPの通信制御部27に処理を渡す。TCPの通信制御部27Cは、当該ECHONET Liteフレームの送信先アドレス・ポート番号に対して、TCPコネクションを確立し、確立したTCPコネクション上で、当該ECHONET Liteフレームをペイロードに設定した適切なTCPメッセージを生成し、機器10Cに送信する。
【0202】
次に、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを得動作させる場合の中間ノード50におけるリソース管理処理について説明する。中間ノード50は、機器10Cと同様の構成であるので、その説明を省略する。中間ノード50の通信プロトコル構成は
図30,31に示す通りである。
【0203】
本発明の技術をサポートしない通常のECHONET Lite機器を収容するための中間ノード50Cの通信プロトコルを
図30に示す。
図30は、本発明の技術と、通常のUDP上でのECHONET Lite技術の相互運用を行うため、PHY、MAC、IP層、TCP/UDP層のプロトコルの変換を行う場合の例である。この他、UDP/TCP層の相互変換を行わず、TCPのままでよい場合、PHY、MAC、IP層の相互変換を行わない場合、及び、それらの組み合わせの場合があり得るが、その記載は省略する。
【0204】
また、本発明と非IP通信規格の上でのECHONET Lite技術の相互運用を行うため、中間ノード50Cにおいて、TCP層以下のIP系プロトコルと、非IP通信規格との相互変換を行う場合の例を
図31に示す。
【0205】
中間ノード50は、起動後、
図32に示す機器10Cと処理と同様の処理を行うことによりECHONET Liteリソースディレクトリの情報を取得する。
【0206】
中間ノード50が、自らも本発明の技術をサポートする機器として振る舞い、機器の制御・管理・監視を直接受け付ける場合には、
図33に示すように機器10Cの処理と同様に、リソースディレクトリ(データベース30)に対して自らの機器情報を登録する。
【0207】
中間ノード50は、通信ネットワーク1上で、非特許文献1の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、該機器のアドレス、種別、能力の情報を記憶し、自らが通信に利用可能な(他の通信で利用されていない)IPアドレス・ポート番号の組から、当該機器に対する本発明の制御・管理・監視メッセージを以後受け取るためのIPアドレス・ポート番号の組を選び出し、選び出した当該IPアドレス・ポート番号の組と該機器のアドレス情報(IPアドレス、ポート番号の組、もしくは、当該機器が非IP通信規格を用いている場合は、当該通信規格における通信アドレス)の対応関係を記憶し、選び出した当該IPアドレス・ポート番号を用いてリソースディレクトリ(データベース30)へのTCPコネクションを確立し、当該TCPコネクション上で、先に受け取った機器情報の広告通知ECHONET Liteフレームをリソースディレクトリへ送信して登録する。既に一つ以上のIPアドレス・ポート番号の組を選び出して対応関係を持っている機器から新たな機器情報を受信した場合は、当該IPアドレス・ポート番号の組でリソースディレクトリ(データベース30)に対してTCPコネクションを確立して(確立済みの場合はそのコネクションを使用して)当該機器情報の通知ECHONET Liteフレームを送信して更新処理を行う。
【0208】
次に、中間ノード50が、機器制御・管理・監視メッセージを受信する際の例を説明する。
【0209】
中間ノード50は、TCPの通信処理部において、受信したTCPメッセージのペイロードがECHONET Liteである場合、処理をECHONET Lite処理部55へ渡す。ECHONET Lite処理部55は、当該TCPメッセージを受信したIPアドレス及びポート番号の組と、その組が対応する機器アドレスの対応関係のリストを検索し、当該IPアドレス・ポート番号の組が、自らが直接制御・管理・監視を受け付ける機器に対応するリソースである場合は、非特許文献1に従ってECHONET Liteフレームを処理し、機器の制御・管理・監視を実行する。
【0210】
一方、中間ノード50がIPアドレス・ポート番号の組が、自らが直接制御・管理・監視を受け付ける機器ではなく、他の機器に対応する場合には、ECHONET Lite処理部55に処理を渡さず、アプリケーション部54へ処理を渡す。アプリケーション部54は、当該IPアドレス・ポート番号の組が対応する機器が用いている通信規格を処理する処理部(当該機器がTCP/IPを用いている場合はTCPの通信処理部、非IP通信規格を用いている場合は、非IP通信規格の通信処理部)へ、該ECHONET Liteフレームを渡し、該機器へ各通信規格の通信手順によってECHONET Liteフレームを送信させる。例えば、該機器がUDP/IPを用いている場合は、取り出したECHONET Liteフレーム及び該フレームを送信すべき機器のアドレス情報を通信処理部を介して、非特許文献1に従う通常のUDP上で動作するECHONET Liteを持つIPパケットとして、該機器に送信する。
[第4の実施の形態]
本実施の形態では、本発明の技術をサポートしないUDP/TCP上で直接ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を本発明の技術と相互運用を可能にするため、かつ/または、それらの機器の間に介在して機器情報の交換やアドレス解決の支援を行うための中間ノード50について説明する。
【0211】
当該中間ノード50は、システム全体において唯一存在してもよく、複数存在してもよい。なお、中間ノード50は、前述の機器10と同様の構成であるので各部の説明は省略する。
【0212】
アプリケーション層の通信プロトコルとして、CoAP上で非特許文献1の技術を動作させる場合の、中間ノード50の処理のリソース管理処理について説明する。
【0213】
中間ノード50は、起動後、
図9と同様の方法でデータベース30のCoAPリソースディレクトリに情報を登録する。
【0214】
中間ノード50が、自らも本発明の技術をサポートする機器として振る舞い、機器の制御・管理・監視を直接受け付ける場合は、
図10と同様の方法でデータベース30のリソースディレクトリに対して自らのリソース情報を登録する。
【0215】
中間ノード50は、通信ネットワーク上で、非特許文献1の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、その機器のアドレス、種別、能力の情報を記憶して、その機器に対する本発明の制御・管理・監視メッセージを受け取るためのCoAPURLで特定されるリソースを生成し、該リソースと該機器のアドレス情報(IPアドレス、ポート番号の組、もしくは、該機器が非IP通信規格を用いている場合は、該通信規格における通信アドレス)の対応関係をメモリに記憶し、生成した該リソースの情報をデータベース30のリソースディレクトリへ登録する。既に一つ以上のリソースとの対応関係を持つ機器から新たな機器情報を受信した場合は、既にリソースに対応付けられたものである機器情報については、それが対応するリソースの情報を更新した上で、リソースディレクトリに対しても更新処理を行う。
【0216】
既に、一つ以上のリソースとの対応関係を持つ機器から機器情報ではあるが、対応するリソースがまだ生成されていない機器情報については、該機器と対応するリソースのうちのいずれかに、新たに受信した該機器情報を追加する形で更新し、リソースディレクトリに更新処理を行ってもよく、また、新規にリソースを生成して該機器のアドレスとの対応関係を記憶し、生成した該リソースの情報をリソースディレクトリに登録してもよい。
【0217】
なお、上記では、リソース情報をデータベース30のリソースディレクトリに登録・更新する例を示したが、中間ノードがリソースディレクトリを兼ねてもよい。
【0218】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。