JP6002642B2 - 通信ノード及びネットワークシステム及び機器制御方法 - Google Patents

通信ノード及びネットワークシステム及び機器制御方法 Download PDF

Info

Publication number
JP6002642B2
JP6002642B2 JP2013176051A JP2013176051A JP6002642B2 JP 6002642 B2 JP6002642 B2 JP 6002642B2 JP 2013176051 A JP2013176051 A JP 2013176051A JP 2013176051 A JP2013176051 A JP 2013176051A JP 6002642 B2 JP6002642 B2 JP 6002642B2
Authority
JP
Japan
Prior art keywords
communication
echonet lite
control
coap
echonet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2013176051A
Other languages
English (en)
Other versions
JP2015046716A (ja
Inventor
亮太 石橋
亮太 石橋
新 小池
新 小池
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2013176051A priority Critical patent/JP6002642B2/ja
Publication of JP2015046716A publication Critical patent/JP2015046716A/ja
Application granted granted Critical
Publication of JP6002642B2 publication Critical patent/JP6002642B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、通信ノード通信ノード及びネットワークシステム及び機器制御方法に係り、特に、多数の機器の電源状態、動作モード、設定等を、通信ネットワークを介して遠隔から制御及び管理するための通信ノード通信ノード及びネットワークシステム及び機器制御方法に関する。
空調機器、照明機器などの機器の電源状態、動作モード、設定等を制御・管理し、またその状態を監視するための通信技術として、機器の種別毎に詳細なデータ構造を定義し、これに対応する機器に対して、所望する制御・管理に対応したデータ構造信号をもつ信号を送信することで、機器の制御・管理を通信ネットワークを介して遠隔から実行する技術がある（例えば、非特許文献１参照）。
また、上記の非特許文献１の技術は、これに対応する機器から送信される信号を定義されたデータ構造に照らして解釈することにより、機器の状態異常等の監視を行うことができる。
当該技術は、特定の通信プロトコルに依存せず幅広い通信ネットワーク上で動作することを意図して、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)等のトランスポート層以下の通信プロトコルについては一切規定せず、トランスポート層以下の任意の通信プロトコルとの組み合わせで動作する。
また、制御・管理、状態監視のための信号を通信ネットワークを介して送受信することを必ずしも主たる目的としない通常の家電機器等に適用することを想定して、信号の通信処理がもたらす消費電力の増加、機器コストの増加を抑えるため、再送制御、認証・認可、セキュリティ保護などのメカニズムを取り除き、通信処理を簡易なものとしている。
ECHONET Lite 規格書Ver1.10, エコ−ネットコンソーシアム
しかしながら、上記の非特許文献１の技術は、送受信するパケットが通信ネットワーク上で喪失したり、廃棄されたりする場合に通信を復元するためのパケット再送メカニズムを持たないため、UDPのような再送制御メカニズムを持たない通信プロトコル上で動作させる場合、パケットの喪失・破棄による通信の不完了を回復することができない。通信ネットワークの規模が小さく、パケットの喪失や廃棄が起こる可能性の低い、家庭内のLAN等のローカルネットワークでは、これが直ちに問題となる可能性は低い。また、仮にパケットが喪失または破棄され通信が正しく完了しなかった場合であっても、機器の制御・管理や監視を行う管理者または管理アプリケーションがそれを検知して、制御・管理や監視の通信処理を再実行することは、機器の数・種類が限定的なローカルネットワークにおいては容易である。
しかしながら、多種多様な機器をインターネット等の広域通信ネットワークを介して大規模に制御・管理・監視する場合、ネットワーク規模が大きくなり、パケットの喪失・破棄の可能性が高まり、制御・管理・監視が正しく実行できなくなる可能性が増大するという問題がある。
また、上記の非特許文献１の技術では、ネットワーク上に存在する制御・管理・監視対象の機器のアドレス、種別、能力を一元管理する方法が提供されていない。非特許文献１の技術では、トランスポート層の通信プロトコルにUDPを用いる場合、IPマルチキャストを用いて各機器が自らのアドレス、種別や能力の情報をネットワーク上に同報し、他の機器がそれを受信することで、ネットワーク上に存在する機器のアドレス、種別、能力の情報を取得することができる。
しかしながら、現状では、IPマルチキャストはインターネットサービスプロバイダあるいはネットワークプロバイダの提供する映像配信サービス等の限られた一部のサービスにのみ利用することができるに留まっており、複数のプロバイダを跨った大規模なネットワークにおいて利用することは困難である。そのため、インターネット等の広域ネットワークを介した大規模なシステムでは、制御・管理・監視の対象となる機器のアドレス、種別、能力の情報が限定的にしか取得・管理できず、目的とする機器の制御・管理・監視が実行できなくなる場合がある。また、マルチキャストにより同報した情報を一元管理する方法はないため、各機器が取得した情報を各自で保持する必要があり、システムの規模が大きくなると、機器が保持する必要のあるデータサイズが大きくなり、機器の実装コストが増大するという問題がある。
本発明は、上記の点に鑑みなされたもので、非特許文献１のECHONET Lite（登録商標）を用いた機器制御・管理・監視サービスを提供するため、ローカル環境に専用の装置を配備することなく、広域ネットワークを用いてサービス提供に掛かるコストを削減することが可能な通信ノード及びネットワークシステム及び機器制御方法を提供することを目的とする。
一態様によれば、 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処理手段と、を有する通信ノードが提供される。
一態様によれば、従来技術（非特許文献１）のECONET Liteを拡張した機器制御・管理・監視サービスを提供するために、ローカルな環境に専用の装置を配備する必要がなくなり、インターネット等の広域ネットワークを介してネットワーク上に管理アプリケーションを配備するだけでよくなるため、サービス提供に掛かるコストが削減できる。
また、拡張されたECHONET Liteを用いた機器制御・管理・監視を、同様に広域ネットワークを介して実施可能とするために、アプリケーション開発者が自らアドレス解決や再送制御、機器情報の登録・取得などのメカニズムを実装する必要がなくなり、開発に掛かるコストが削減できる。
さらに、HTTP等の既存プロトコルを用いて新たに機器制御・管理・監視のためのデータモデルを定義する必要がなく、ECHONET Lite技術をそのまま利用することができるため、開発にかかるコストが削減できる。
本発明の一実施の形態におけるシステム構成例である。 本発明の第１の実施の形態における機器の構成図である。 本発明の第１の実施の形態における管理ノードの構成例である。 本発明の第1の実施の形態における中間ノードの構成例である。 本発明の第１の実施の形態における通信プロトコルの構成である。 本発明の第１の実施の形態における中間ノードの通信プロトコル構成（UDP）である。 本発明の第１の実施の形態における中間ノードの通信プロトコル抗生（非IP通信規格）である。 本発明の第１の実施の形態におけるContent-Formatオプションの設定例である。 本発明の第１の実施の形態における設定するDNSリソースレコードの例である。 本発明の第１の実施の形態における機器によるリソース登録の例（その１）である。 本発明の第１の実施の形態における機器によるリソース登録の例（その２）である。 本発明の第１の実施の形態における処理のシーケンスである。 本発明の第１の実施の形態におけるECHONET Liteサービス（要求用）とCoAPメソッドのマッピング例である。 本発明の第１の実施の形態におけるECHONET Liteサービス（応答用）とCoAPレスポンスのマッピング例である。 本発明の第１の実施の形態におけるECHONET Liteサービス（通知・通知応答用）とCoAPメソッド・レスポンスのマッピングの例である。 本発明の第１の実施の形態におけるECHONET Lite（不可応答用）とCoAPレスポンスのマッピングである。 本発明の第１の実施の形態におけるメッセージ例である。 本発明の第２の実施の形態における機器の構成図である。 本発明の第２の実施の形態における管理ノードの構成図である。 本発明の第２の実施の形態における通信プロトコル構成である。 本発明の第２の実施の形態における機器の動作のフローチャートである。 本発明の第２の実施の形態における機器によるリソース登録の例である。 本発明の第２の実施の形態におけるECHONET Liteサービス（要求用）とHTTPメソッドのマッピングの例である。 本発明の第２の実施の形態におけるECHONET Liteサービス（応答用）とHTTPのマッピングの例である。 本発明の第２の実施の形態におけるECHONET Liteサービス（通知・通知応答用）とHTTPメソッド・レスポンスのマッピング例である。 本発明の第２の実施の形態におけるECHONET Liteサービス（不可応答用）とHTTPレスポンスのマッピング例である。 本発明の第２の実施の形態におけるメッセージ例である。 本発明の第３の実施の形態における通信プロトコル構成である。 本発明の第３の実施の形態における処理のシーケンスチャートである。 本発明の第３の実施の形態における中間ノードの通信プロトコル構成（その１）である。 本発明の第３の実施の形態における中間ノードの通信プロトコル構成（その２）である。 本発明の第３の実施の形態における機器の接続先発見方法の例である。 本発明の第３の実施の形態における機器による機器情報通知の例である。
以下、図面と共に本発明の実施の形態を説明する。
本発明は、既存技術ECHONET Liteを、その他の既存技術の一部と組み合わせた上で、更に不足する部分を、ECHONET Lite及び組み合わせる既存技術の双方に極力影響しない技術によって実現することで、完全な新規技術の開発を必要としない低コストな通信ノード及びネットワークシステム及び通信方法を提供するものである。
図１は、本発明の一実施の形態におけるシステム構成例を示す。
同図に示すシステムは、通信ネットワーク１、機器１０（１０Ａ，１０Ｂ，１０Ｃ）、管理ノード２０、データベース３０、管理端末４０、中間ノード５０を有する。
通信ネットワーク１は、インターネット、家庭内LAN、その他情報通信ネットワーク、あるいはその任意の組み合わせであって、TCP/IP通信が可能なネットワーク、Bluetooth（登録商標）、Zigbee(登録商標）などの非TCP/IP技術に基づく通信ネットワークを含む。
機器１０は、通信ネットワーク１を介して、本発明の技術を用いて互いに通信を行う機器である。複数の同一または異なる機器が、同一の通信ネットワーク（例えば、IPサブネットワーク）に接続していてもよく、複数の異なる通信ネットワーク１に分散して接続していてもよい。この機器１０は、場合によっては後述する「中間ノード」として動作してもよい。本例では、中間ノード５０が機器１０とは個別に配置されるものとして説明する。
データベース３０は、通信ネットワーク１を介して、機器１０との通信を行い、システムに存在する機器の通信アドレス、種別、能力の情報を取得・管理するデータベースである。単一のデータベースであってもよく、複数のデータベースが同一のデータを保持する多重化構成をとってもよく、また、複数のデータベースが異なるデータを持ち補完的に動作する構成をとってもよい。本発明では、例えば、後述のDNS（Domain Name System）サーバ、CoAP(Constrained Application Protocol)リソースディレクトリ、ECHONET Liteディレクトリなどとして振舞う。
管理ノード２０は、本発明の技術を用いて、通信ネットワーク１を介して機器１０及びデータベース３０と通信を行い、機器の電源状態、動作モード、設定等の制御・管理・監視を行うノードである。単一のノードであってもよく、複数の同一ノードを多重的に設置してあってもよく、目的・役割毎に異なるノードを一つずつ、または、複数ずつ設置してあってもよい。管理者が直接管理ノードを操作・設定してもよく、後述の管理端末４０を用いて管理ノード２０と通信を行い、遠隔から管理ノード２０を操作・設定してもよい。また、本発明における機器１０が管理ノードを兼ねてもよい。
管理端末４０は、管理ノード２０を直接操作・設定できない管理者が、通信ネットワーク１を介して遠隔から管理ノード２０と接続及び通信を行い、機器の制御・管理・監視を行うために用いる端末である。通信ネットワーク１を介して、管理ノード２０が提供する通信インタフェースにしたがって通信を行うことのできる任意の端末であり、例えば、パーソナルコンピュータ、タブレット端末、スマートフォン、携帯電話などであってもよい。
以下では、アプリケーション層の通信ネットワークプロトコル毎及びTCPにおける適用例を説明する。
第１の実施の形態では、CoAP(例えば、非特許文献２：ietf-draft-core-coap-17, Constrained Application Protocol(CoAP))の上で非特許文献１の技術を動作させる例を説明する。
第２の実施の形態では、HTTP(Hypertext Transfer Protocol)（例えば、非特許文献３：RFC2616, Hyper Text Transfer Protocol(HTTP)）上で非特許文献１の技術を動作させる例を説明する。
上記の第１、第２の実施の形態では、非特許文献１の技術を、非特許文献１上で規定するようにトランスポート層の通信プロトコルの上で単純に動作させるのではなく、再送制御機能、及び、機器のアドレス、種別、能力の情報の管理・発見機能を持つ特定のアプリケーション層の通信プロトコル（CoAP、HTTP）と複合的に組み合わせて動作することによってインターネット等の広域ネットワークを介した大規模なシステムとして、非特許文献１の技術による機器の制御・管理・監視を可能とする。
第３の実施の形態では、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる例を説明する。
上記の第３の実施の形態では、非特許文献１で規定するようにトランスポート層の通信プロトコルの上で単純に動作させる場合においても、再送制御機能を持つTCPをトランスポートプロトコルとして使用し、TCPが提供しない機器のアドレス、種別、能力の情報の管理・発見機能をマルチキャストに依存しない方法により実現することで、インターネット等の広域ネットワークを介した非特許文献１の技術による機器の制御・管理・監視を可能とする。
第４の実施の形態では、本発明の技術をサポートしないUDP/TCPの上で直接ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を、本発明の技術と相互運用可能にし、かつ、または、それらの機器の間に中間ノードが介在して機器情報の交換やアドレス解決の支援を行う例を説明する。
［第１の実施の形態］
本実施の形態では、アプリケーション層の通信プロトコルとしてCoAPの上で非特許文献１の技術を動作させる場合について説明する。
図２は、本発明の第１の実施の形態における機器の構成例を示す。
同図に示す機器１０Ａは、CPU・メモリ１１、機器インタフェース１２、機器制御部１３、アプリケーション部１４、ECHONET Lite処理部１５、CoAP処理部１６Ａ、通信制御部１７、通信インタフェース１８を有する。
CPU・メモリ１１は、通信処理、機器制御等のための演算を行う演算装置及びデータ格納部である。簡便を期して一体表記しているが、個別に具備してもよい。
機器インタフェース１２及び機器制御部１３は、機器固有の入出力及びそれを制御するインタフェースであり、機器によって異なる。基本や湿度等の値を読み取るセンサ、冷風や温風を送出するファン、LEDを発光させるための回路、それらを制御するためのインタフェースがその例である。
アプリケーション部１４は、本発明におけるECHONET LiteとCoAPの組み合わせによるメッセージを受信して、それに応じた機器の制御を機器制御部１３を介して実行し、また、機器制御部１３からの信号を受け付け、ECHONET Lite処理部１５、CoAP処理部１６Ａを介して、本発明のECHONET LiteとCoAPの組み合わせによるメッセージをECHONET Lite処理部１５に渡す。
ECHONET Lite処理部１５は、非特許文献１のECHONET Liteフレームの解析を行い、処理結果をアプリケーション部１４からの命令に従って非特許文献１のECHONET Liteフレームを構築し、CoAP処理部１６Ａに渡してCoAPメッセージの作成・送信を指示する。
CoAP処理部１６Ａは、非特許文献２のCoAPクライアント機能及びCoAPサーバ機能を備え、通信制御部１７から渡されたCoAPメッセージを処理し、その結果、本発明におけるCoAPとECHONET Liteの組み合わせによるメッセージである場合に、ECHONET Lite処理部１５に処理結果を渡して、機器１０Ａの制御等を指示する。また、ECHONET Lite処理部１５からの命令とECHONET Liteフレームにしたがって、本発明におけるECHONET LiteとCoAPを組み合わせたCoAPメッセージを構築し、通信制御部１７を介して通信ネットワーク上にメッセージを送信する。
通信制御部１７及び通信インタフェース１８は、機器１０Ａが通信ネットワーク１に接続して他の機器と通信するための入出力及びそれを制御するインタフェースである。物理インタフェースの例としてEthernet（登録商標）がある。
図３は、本発明の第１の実施の形態における管理ノードの構成例である。
管理ノード２０は、CPU・メモリ２１、アプリケーション部２４、ECHONET Lite処理部２５、CoAP処理部２６Ａ、通信制御部２７、通信インタフェース２８を有する。
管理ノード２０は、ECHONET LiteとCoAPを組み合わせて機器１０Ａの制御・管理・監視のための通信を行うものの、自らは機器の制御・管理・監視を受け付けることをしない。管理ノード２０は、図２の機器１０Ａとは異なり、機器インタフェース１２、機器制御部１３を持たない場合があり、図３はその例を示している。なお、管理ノード２０が機器１０Ａを兼ねる場合は、図２の機器の構成と同じ機能を有する。
本実施の形態における機器１０Ａ及び管理ノード２０に用いる通信プロトコルは図４に示すとおりである。物理層（PHY）、データリンク層（MAC）は任意である。ネットワーク層は、IPv4またはIPv6のいずれかを用いる。トランスポート層はUDPを用いる。また、DTLS(Datagram TLS)を用いてもよい。
図５は、本発明の第1の実施の形態における中間ノードの構成例である。中間ノード５０は、図２の機器１０と同様の構成であるので、各部の説明は省略する。
本実施の形態において、本発明をサポートしない通常のECHONET Lite機器を収容するための、中間ノード５０の通信プロトコル構成の例を以下に示す。
本発明の技術と通常のUDP上でのECHONET Lite技術の相互運用を行う場合の中間ノード５０の通信プロトコル構成例を図６に示す。この他、CoAPではなく、HTTPを用いる場合、UDPとTCPの相互変換を行う場合、PHY、MAC、IP層の相互変換を行わない場合、及びそれらの組み合わせの場合があり得るが、記載は省略する。
また、本発明の技術と通常のECHONET Lite機器を収容するための中間ノード５０の通信プロトコル構成を図７に示す。図７は、本発明の技術と非IP通信規格上でのECHONET Lite技術の相互運用を行うため、CoAP層以下のIP系プロトコルと、非IP通信規格との相互変換を行う場合の例である。
＜ECHONET Liteの拡張・変更＞
以下に、アプリケーション層の通信プロトコルとして、CoAP上でECHONET Liteの技術を動作させる場合のECHONET Liteに対する拡張・変更を示す。
ECHONET Liteは、OSI(Open System Interconnection)第４層（トランスポート層）の通信プロトコルの上で動作するだけでなく、OSI第５〜７層の通信プロトコルの組み合わせによって動作するものとする。具体的には、OSI第５〜７層の通信プロトコルに位置するCoAPとの複合的な組み合わせによって動作するものとする。
ECHONET LiteをCoAPと組み合わせて用いる場合、トランスポート層の通信プロトコルにはUDPを用いるものとする。UDPを用いる場合には、送信先ポート番号は、"5683"とする。ただし、それ以外のポート番号を用いてもよい。トランスポート層のセキュリティメカニズムにDTLS（Datagram Transport Layer Security）を用いてもよい。DTLSを用いる場合は、送信先のポート番号は、IANA(Internet Assigned Numbers Authority)にサービス名"coaps"で登録されたポート番号を用いるが、それ以外のポート番号を利用してもよい。該ポート番号が未登録である場合は、任意のポートを利用してもよい。
ECHONET LiteをCoAPと組み合わせて用いる場合、ネットワーク層の通信プロトコルにはIPv4もしくはIPv6を用いるものとする。IPアドレスの範囲、取得方法は規定しない。一斉同報に用いるIPマルチキャストアドレスは、非特許文献２で定めるIPv4マルチキャストアドレス及びIPv6マルチキャストアドレスを用いる。ネットワーク層のセキュリティメカニズムにIPSecを用いても良い。
本実施の形態では、CoAPメッセージのペイロード部にECHONET Liteフレームが設定されていることを示すための、Content-Formatオプションに設定するMedia Type及びIDを、非特許文献２及びIANA MIME Media Typeで定義されているMedia Type及びIDと重複しない形で定義する。定義の例は、図８に示す通りである。但し、図８はあくまでも一例であり、これ以外のMedia Type及びIDを排除するものではない。
さらに、CoAP URIで特定されるリソースのうち、どのリソースが本発明におけるECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付けるのかを示すための識別子を定義する。定義の例を以下に示す。
＜例１＞
well-known URI（非特許文献４：RFC5785, Defining Well-known Uniform Resource Identifiers）による共通リソース識別子の定義：
非特許文献４で定義される、ホストの情報を取得するための共通URIプレフィックスである/.well-knownを利用する。
本発明における機器１０Ａが、本発明のECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を、
coap://ホスト:ポート/.well-known/共通リソース識別子
のURIで指定されるリソースで一元的に受け付ける。同じホストが複数のECHONET Liteオブジェクトを持つ場合でも、それぞれ異なるリソースでその制御等を受け付けるのではなく、全てのオブジェクトに対する制御等を全てこのリソースで受け付ける。
上記の"coap"については、DTLS利用時は"coaps"を用いる。ホストはIPアドレスまたはFQDN(Fully Qualified Domain Name)を用いる。ポートは利用するUDPポート番号を用いる（省略可）。リソース識別子はIANAに登録されている他のwell-known URIと重複しない文字列を用いる。定義の一例は、"echnonet-lite"である。識別子を"echnonet-lite"として定義した場合に、ホスト名、ポート番号を仮定したURIの例を以下に示す。
coap://light01.bldg01.example.org:5683/.well-known/echonet-lite
＜例２＞ CoRE link Format（非特許文献５：RFC6690, Core Link Format）によるリソース識別子の定義：
非特許文献５で定義される、rtアトリビュートを用いて、あるCoAP URIで指定されるリソースが、本発明におけるECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付けることを示す識別子を定義する。
識別子は、あるリソースが、本発明のECHONET LiteとCoAPの組み合わせによる機器の制御・管理・監視を受け付ける、という情報のみを示し、そのリソースが実際に対応するECHONET Liteオブジェクトまでは特定できない形で定義してもよい。また、あるリソースが実際に対応するECHONET Liteも同時に特定できる形で定義してもよい。
前者の例を次に示す。
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)形式で記述し、それを参照する場合）
後者の例を次に示す。
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オブジェクトとして、２つの照明機器（0x29001,0x029002）と家庭用エアコン（0x13001）があることをifで示す場合）
次に、リソースディレクトリの発見方法の例を示す。
本実施の形態において、機器１０ＡがCoAPリソースディレクトリ（非特許文献６：Internet-Draft, draft-shelby-core-resource-directory-05, CoRE Resource Directory）をDNS-SD(Service Discovery)を用いて発見する方法の一例を示す。
DNSサーバには、予め、ドメイン（以下の例では、example.com）におけるCoAPリソースディレクトリの情報を、DNS-SD(RFC6763)及び、CoREリソースディレクトリ情報のDNS-SDマッピング技術（draft-lynn-core-discovery-mapping）(非特許文献７：Internet-Draft, draft-lynn-core-discovery-mapping, Core Link-Format to DNS-Based Service Discovery Mapping)に従って設定する。設定は、管理者が手動で実施しても良く、リソースディレクトリまたは代理エージェントプログラムが通信により実施してもよい。
データベース３０内のDNSサーバに設定するDNSリソースレコードの例を図９に示す。
DNSサーバには、予めドメイン（以下の例ではexample.com）におけるCoAPリソースディレクトリの情報を、DNS-SD(RFC6763)、及びCoREリソースディレクトリ情報のDNS-SDマッピング技術（非特許文献７：Internet-Draft, draft-lynn-core-discovery-mapping, Core Link-Format to DNS-Based Service Discovery）に従って設定する。設定は、管理者が手動で実施してもよく、リソースディレクトリまたは代理エージェントプログラムが通信により実施しても良い。
設定するDNSリソースのレコードの例を図９（Ｂ）に示す。
機器１０Ａは、このDNSサーバに対して、ドメインに存在するCoAPリソースディレクトリの情報の検索を実行する。
以下、図９（Ｂ）の設定例においては、ドメインにおいてCoAPリソースディレクトリは、"rd1.example.com"というFQDNをもつホストが、リソース登録（/rd）、グループ登録（rd-group）、リソース検索（rd-lookup）の３つの機能セットとして、共にUDPポート番号"5683"、アプリケーションプロトコルcore(CoAPを意味するDNS Service Typeの定義例である)で提供している、ということを、機器１０ＡからDNSサーバへの通常のDNSクエリによって知ることができる。
機器１０Ａは、このDNSサーバへの検索によって取得したCoAPリソースディレクトリのアドレス及びパス情報を用いて、以降に示す自らのリソース情報の登録を実施する。
次に、機器１０Ａによるリソースの登録の例を２通り説明する。
図１０は、本発明の第１の実施の形態における機器によるリソース登録の例（その１）である。
機器１０Ａは、DHCP(Domestic Host configuration Protocol)オプション、DNS-SDなどの何らかの手段で発見した、ドメイン上のリソースディレクトリ（データベース３０）に対して、自らがホストするECHONET Liteによる機器の制御・管理・監視を受け付けるリソースの情報を、CoAP POSTを送信することで登録する。
リクエストURLパラメータとして、自らをドメイン内で一意に特定する識別子を"ep=node1"として設定し、ECHONET Liteによる機器の制御・管理・監視を全て一括して"/echo"というリソースで受け付けることを示す情報を、POSTメッセージへのペイロード部にRFC6690のCoRE Link Format形式で設定する。このとき、前述の識別子の定義の例の＜例２＞で述べたリソース識別子を設定する（以下の例では、rt=echonet-lite）。
リソースディレクトリへのリソースの登録処理を行い、機器１０Ａへレスポンスを返却する。このレスポンスには、今後、機器１０Ａが登録された該リソースの情報の変更、削除等を行う際にメッセージを送信すべきリソースのURLパスが、Locationオプションで指定される。
なお、以下の例では、機器１０Ａとデータベース３０との間での認証、認可手順は省略しているが、先立って認証、認可の手順が実行されてもよい。
なお、図１０の例では、CoAPメッセージは、可読性向上のためテキストで例示しているが、本来は非特許文献２に従ってバイナリフォーマットで記述される。
機器によるリソース情報の登録は、前述の識別子の定義の例の＜例１＞で述べた共通的リソース識別子を用いる場合は必ずしも実施する必要はないが、実施してもよい。
図１１は、本発明の第１の実施の形態における機器によるリソース登録の例（その２）である。
ここでは、図１０の例とは異なり、ECHONET Liteによる機器の制御・管理・監視を、全て１つのリソースで一括して受け付けるのではなく、いくつかのリソースに分けて受け付ける場合の例を示す。
リソースを登録するためのCoAP POSTメッセージのペイロードに、ECHONET Liteによる機器の制御・管理・監視を受け付ける自らの全てのリソースの一覧を、RRC6690 Core Link Formatの形式で設定する。それぞれのリソースには、前述の識別子の定義の例の＜例２＞で述べたリソース識別子を、rtアトリビュートとして設定する。以下の例では、照明（rt=echonet-lite.0x0290）の制御・管理・監視をリソース"/echo/light"で、エアコンの制御・管理・監視をリソース"/echo/aircon"で受け付けることを示している。それ以外は前述（図１０）の例と同様である。
次に、機器の制御・管理・監視のための管理ノード２０の処理について図１２に沿って説明する。
ステップ１０１）機器１０Ａの制御・管理・監視を行う管理ノード２０は、データベース３０から図９の説明で記載したCoAPリソースディレクトリの発見を行い、CoAPリソースディレクトリの情報を取得する。その後、同リソースディレクトリに対して通信を行い、自らが、制御・管理・監視を行うことのできる機器及びそのアドレス、種別、能力の情報を取得する。管理ノード２０は、この手順を定期的に実行してもよく、ユーザ、または管理端末からの指示に応じて実行してもよい。
ステップ１０２）管理ノード２０のアプリケーション部２４は、この情報をメモリ２１内に格納した上で、管理ノード２０を操作するユーザに対してグラフィカルユーザインタフェースを用いて一覧表示する。または、通信により管理ノード２０のアプリケーションを操作する管理端末４０のアプリケーションに対して一覧の情報を送信する。
ステップ１０３）管理ノード２０のアプリケーション部２４は、ユーザないしは管理端末のアプリケーションからの指示に従って、ECHONET Lite処理部２５に処理を渡す。
ステップ１０４）ECHONET Lite処理部２５は、制御対象の機器の種別、及び、制御内容に応じて適切なECHONET Liteフレームを生成し、CoAP処理部２６Ａに処理を渡す。
ステップ１０５）CoAP処理部２６Ａは、当該ECHONET Liteフレームをペイロード部に設定した適切なCoAPメッセージを生成し、制御対象の機器１０Ａを、必要に応じてDNSサーバ(データベース３０)へのDNSクエリを用いて、制御・管理対象の機器１０のアドレスを解決した上で、通信制御部２７に処理を渡す。
ステップ１０６）通信制御部２７は、UDP/DTLSの通信を開始し、当該CoAPメッセージを通信相手のIPアドレス・ポート番号へ送信する。
次に、機器１０Ａが管理ノード２０から上記のCoAPメッセージを受信した場合の処理を図１２に沿って説明する。
ステップ１０７）管理ノード２０から機器１０Ａの通信インタフェース１８を介して受信したメッセージを受け取った通信制御部１７は、メッセージのトランスポートプロトコル、宛先IPアドレス、宛先ポート番号から受信したCoAPメッセージであると判断した場合、CoAP処理部１６Ａに処理を渡す。それ以外のメッセージ（例えば、ICMP(Internet Control Message Protocol)など）の場合は、そのメッセージを処理する上位の処理部へ処理を渡す。
ステップ１０８）CoAP処理部１６Ａは、受け取ったCoAPメッセージを解析し、非特許文献２に従って処理する。但し、受け取ったメッセージがCoAPリスクエストである場合は、Content-Typeオプションの値をチェックし、図８に示した、CoAPペイロードとしてのECHONET Liteフレームであることを示す識別子が設定されている場合は、ペイロード部のECHONET Liteフレームを取り出し、ECHONET Lite処理部１５に渡す。それ以外のペイロードが設定されている場合は、非特許文献２に従って通常のCoAPサーバとして処理を行う。
ステップ１０９）ECHONET Lite処理部１５は、受け取ったECHONET Liteフレームを、非特許文献１に従って処理し、必要に応じて機器の制御・管理・監視を実行する。非特許文献１に従って、応答を返却する場合は、応答のためのECHONET Liteフレームを生成して、CoAP処理部１６Ａに返す。
ステップ１１０）CoAP処理部１６Ａは、ECHONET Lite処理部１５から直ちに応答処理を受け取った場合は、応答ECHONET Liteフレームをペイロードとして設定した適切なCoAPメッセージを生成して、応答先へ送信するよう通信制御部１７に処理を渡す。
ステップ１１１）ECHONET Lite処理部１５から直ちに応答処理がない場合は、非特許文献２に従って非同期応答を実行する。
上記で用いられる非特許文献１で定義されるECHONET Liteサービス（要求用）と非特許文献２で定義されるCoAPメソッドのマッピングについて説明する。
図１３は、本発明の第１の実施の形態におけるECHONET Liteサービス（要求用）とCoAPメソッドのマッピングの例を示す。
プロパティ値の書き込み要求及び書き込み・読み出し要求については、CoAP PUTメソッドを用いる。
プロパティ値の読み出し要求については、CoAP GETメソッドを用いる。
プロパティ値書き込み要求（応答不要）については、CoAPメッセージタイプに"NON"を用いるが、それ以外については"CON"を用いる。但し、それ以外のものについても、一斉同報によって送信する場合、あるいは、メッセージを送信するアプリケーションが自ら再送タイマを起動するなどによって、応答がない場合の再送制御を実行することができる場合は、"NON"を用いるようにすることもできる。
次に、ECHONET Liteサービス（応答用）とCoAPレスポンスのマッピングについて説明する。
図１４は、本発明の第１の実施の形態におけるECHONET Liteサービス（応答用）とCoAPレスポンスのマッピングの例を示す。
上記で利用される、非特許文献１で定義されるECHONET Liteサービス（ESV）（応答用）と、非特許文献２で定義されるCoAPレスポンスのマッピングについて説明する。
CoAPメッセージタイプは、受信した要求のCoAPメッセージタイプが"CON"であり、かつ応答を即時返却できる場合は、"ACK"を用いる。受信した要求のCoAPメッセージタイプが"CON"であるが、応答を遅延して返却する場合は、"CON"を用いる（但し、非特許文献２に従い、遅延して応答を返却する前に、受信した要求に対して空のCoAPメッセージを返却する）。受信した要求のCoAPメッセージタイプが"NON"である場合は、"NON"を用いる。
次に、非特許文献１で定義されるECHONET Liteサービス（通知・通知応答）と非特許文献２で定義されるCoAPメソッド・レスポンスのマッピングについて説明する。
図１５は、本発明の第１の実施の形態におけるECHONET Liteサービス（通知・通知応答）とCoAPメソッド・レスポンスのマッピングの例を示す。
プロパティ値要求は、ECHONET Lite通知要求フレームをペイロード部に格納したCoAP POSTリクエストを送信することで実施する。CoAPメッセージタイプは"CON"を用いる。
プロパティ値の通知は、応答の要・不要を問わず、ECHONET Lite通知フレームをペイロード部に格納したCoAP POSTリクエストを送信することで実施する。CoAPメッセージタイプは、応答の要・不要いずれかの場合も"CON"を用いる。但し、プロパティ値通知（0x73）を一斉同報で送信する場合には、"NON"を用いる。
プロパティ値通知応答は、2.04Changedを用いる。プロパティ値通知不可応答は、ECHONET Lite処理部１５において、要求を受け付けない場合、あるいは指定された送信先オブジェクト（DEOJ）は存在するが、指定されたアクセス先プロパティ（EPC）が存在しない場合は、"4.03Forbidden"を用いる。ECHONET Lite処理部１５において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合、あるいは、読み出し要求される全プロパティ値を返そうとしたが許されるECHONET Lite電文長を超える場合には、"5.00Server Internal Error"を用いる。
次に、非特許文献１で定義されるECHONET Liteサービス（不可応答用）とCoAPレスポンスのマッピングについて説明する。
図１６は、本発明の第１の実施の形態におけるECHONET Liteサービス（不可応答用）とCoAPレスポンスのマッピング例を示す。
ECHONET Lite処理部１５において、要求を受け付けない場合、あるいは指定されたDEOJは存在するが、指定されたEPCが存在しない場合は、"4.03 Forbiden"を用いる。
ECHONET Lite処理部１５において、指定されたEDOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合は、"5.00Server Internal Error"を用いる。
CoAPメッセージタイプについては、図１４で説明したルールに従う。
次に、上記の機器の制御・管理・監視のためのECHONET Liteフレームを含むCoAPメッセージについて説明する。
管理ノード２０のCoAP処理部２６Ａは、CoAPメッセージのペイロード部に、非特許文献１で定義されるECHONET Liteフレームをそのまま格納する。このとき、CoAPオプションとして、Content-Formatオプションに、図８に示すECHONET Liteフレームを表すMedia Typeを設定する。
例えば、非特許文献１で定義される住宅・設備関連機器クラスグループ・一般照明クラスに属する照明装置（DEOJ=0x29001）の動作状態（EPC=0x80をON（EDT=0x30）にする。つまり、電源を入れる場合には図１７に示すようなメッセージを生成する。図１７の例では、照明装置を具備する機器１０Ａが、coap://light01.bldg01.example.org/と指定されるリソースで、当該照明装置の制御・管理・監視を受け付ける。照明装置に対応するECHONET Liteオブジェクトはインスタンス番号"0x01"でインスタンス化されている。
制御メッセージの送信元の管理ノード２０は、非特許文献１で定義される管理・操作関連機器クラスグループ・コントローラクラスに属するコントローラ装置（SEOJ=0x05FF01）である。
当該CoAPメッセージのContent-Formatオプションには、図８の例で示した"application/echonet-light"を設定している（実際には、オプションIDである"100"が設定される）。
なお、図１７の例は、可読性のためにCoAPメッセージ、ECHONET Liteフレームともにテキスト形式で記しているが、それぞれ非特許文献２及び非特許文献１でそれぞれ定義されるメッセージフォーマットに従ってバイナリエンコードされる。
次に、中間ノード５０について説明する。なお、図１では、中間ノード５０として通信ネットワーク１に接続される構成としているが、前述したように、機器１０が中間ノードとして動作するようにしてもよい。なお、中間ノード５０は、機器１０と同様の構成として説明する。
中間ノード５０は、本発明の技術をサポートしないUDP/TCP上で直接ECHONET Liteを動作させる機器、及び非IP通信規格の上でECHONET Liteを動作させる機器を、本発明の技術と相互運用可能にするため、かつ／または、それらの機器の間に介在して機器情報の交換やアドレス解決の支援を行うためのノードである。
システム全体において、中間ノード５０は唯一存在してもよく、複数存在してもよい。
本発明において、アプリケーション層の通信プロトコルとして、CoAP上で非特許文献１の技術を動作させる場合の中間ノード５０の処理のリソース管理処理の例を以下に示す。
中間ノード５０は、起動後、図９の説明と同様に、データベース３０からCoAPリソースディレクトリの情報を取得する。
中間ノード５０が自らも本発明の技術をサポートする機器として振る舞い、機器１０Ａの制御・管理・監視を直接受け付ける場合には、図１１で説明したように、該リソースディレクトリに対して自らのリソース情報を登録する。
中間ノード５０は、通信ネットワーク１上で非特許文献１の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、その機器のアドレス、種別、能力の情報を記憶し、その機器に対する本発明の制御・管理・監視メッセージを受け取るためのCoAP URLで特定されるリソースを生成し、該リソースと該機器のアドレス情報（IPアドレス、ポート番号の組、もしくは、当該機器が非IP通信規格を用いている場合は、当該通信規格における通信アドレス）の対応関係を記憶し、生成した当該リソースの情報をリソースディレクトリ（データベース３０）へ登録する。既に一つ以上のリソースの対応関係を持つ機器から新たな機器情報を受信した場合は、既にリソースに対応付けられたものである機器情報については、それが対応するリソースの情報を更新した上で、リソースディレクトリに対しても更新処理を行う。既に一つ以上のリソースの対応関係を持つ機器からの機器情報ではあるが、対応するリソースがまだ生成されていない機器情報については、当該機器と対応するリソースのうちのいずれかに、新たに受信した当該機器情報を追加する形で更新し、リソースディレクトリに更新処理を行っていってもよく、また、新規にリソースを生成して該機器のアドレスとの関係を記憶し、生成した当該リソースの情報をリソースディレクトリに登録してもよい。
なお、中間ノード５０は、リソースディレクトリを兼ねてもよい。
次に、中間ノード５０の機器の制御・管理・監視メッセージ受信処理を説明する。
中間ノード５０は、前述の機器１０Ａによるメッセージ受信処理と同様に、CoAP処理部において、CoAPペイロードがECHONET Liteフレームであること識別すると、自らがホストとするリソースと、そのリソースが対応する機器アドレスの対応関係のリストを検索し、当該CoAPメッセージの宛先リソースが、自らが直接制御・管理・監視を受ける機器１０の対応するリソースである場合は、当該ECHONET LiteフレームをECHONET Lite処理部５５に渡す。当該CoAPメッセージの宛先リソースが、自らが直接制御・管理・監視を受ける機器ではなく、上記の本発明の技術をサポートしない通常のECHONET Lite機器に対応するリソースである場合には、ECHONET Lite処理部５５に処理を渡さず、アプリケーションへ処理を渡す。アプリケーションは、当該リソースが対応する機器の用いている通信規格を処理する処理部（当該機器がTCP/IPを用いている場合は、通信処理部、非IP通信規格を用いている場合は、非IP通信規格の通信処理部）へ、当該ECHONET Liteフレームを渡し、当該機器へ各通信規格の通信手順によってECHONET Liteフレームを送信させる。例えば、当該機器１０がUDP/IPを用いている場合は、取り出したECHONET Liteフレーム及び当該フレームを送信すべき機器のアドレス情報を通信処理部に渡して、非特許文献１に従う通常のUDP上で動作するECHONET Liteフレームを持つIPパケットとして、当該機器１０へ送信する。
［第２の実施の形態］
本実施の形態では、アプリケーション層の通信プロトコルとして、HTTP上のECHONET Liteを動作させる場合の例を示す。
まず、機器１０Ｂの構成を図１８に示す。同図に示す機器１０Ｂは、図２のCoAP処理部１６Ａに代わりに、HTTP処理部１６Ｂを備えた点において異なる。
次に、管理ノード２０Ｂの構成を図１９に示す。同図に示す管理ノード２０Ｂは、図３のCoAP処理部２６Ａの代わりに、HTTP処理部２６Ｂを備えた点において異なる。なお、図１９に示す構成の他、通常考え得るこの他の構成をとってもよい。なお、管理ノード２０Ｂが機器の機能を兼ねる場合は、図１８の機器１０Ｂの例と同じ構成を有する。また、中間ノード５０も同様に、機器の機能を兼ねる場合には、図１８の機器と同様の構成を有する。
以下に、本発明を実現するための非特許文献１の技術（ECHONET Lite）に対する拡張・変更を以下に示す。
本実施の形態では、通信プロトコルとして、HTTP上で非特許文献１の技術を動作させるための機器１０Ｂ，管理ノード２０Ｂを動作させるための通信プロトコルとして、図２０に示す通信プロトコル構成を用いる。
なお、物理層（PHY）、データリンク層（MAC）は任意である。ネットワーク層は、IPv4またはIPv6のいずれかである。トランスポート層は、TCPを用いる。TLS(Datagram TLS)を用いてもよい。
OSI第４層（トランスポート層）の通信プロトコルの上で動作するだけでなく、OSI第５〜７層の通信プロトコルとの組み合わせによっても動作するものとする。具体的には、OSI第５〜７層の通信プロトコルに位置付けられるHTTPとの複合的な組み合わせによっても動作するものとする。
HTTPと組み合わせて用いる場合、トランスポート層の通信プロトコルにはTCPを用いるものとする。TCPを用いる場合には、送信先のポート番号は"80"とする。但し、それ以外のポート番号を用いても良い。トランスポート層のセキュリティメカニズムにTLS(Transport Layer Security)を用いても良い。TLSを用いる場合は、送信先のポート番号は"443"を用いるが、それ以外のポート番号を利用してもよい。
HTTPと組み合わせて用いる場合、ネットワーク層の通信プロトコルにはIPv4もしくはIPv6を用いるものとする。IPアドレスの範囲、取得方法は特に指定しない。ネットワーク層のセキュリティメカニズムには、IPSecを用いても良い。
HTTPメッセージのペイロード部に非特許文献１のECHONET Liteフレームが設定されていることを示すための、Content-Typeヘッダに設定するMedia Typeを、既にIANA MIME Media Typeで定義されているMedia Typeと重複しない形で定義する。定義の例は、"application/echonet-lite"であるが、これ以外の定義を排除しない。
本実施の形態において、HTTP URIで特定されるリソースのうち、どのリソースが本発明におけるECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付けるのかを示すための識別子を定義する。定義の例は以下の通りである。但し、これ以外の定義を排除しない。
＜例１＞
well-known URI（非特許文献４）による共通リソース識別子の定義：
非特許文献４で定義される、ホストの情報を取得するための共通URIプレフィックスである"/.well-known"を利用する。
本発明における機器１０Ｂが、本発明のECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を、
http://ホスト:ポート/.well-known/共通リソース識別子
のURIで指定されるリソースで一元的に受け付ける。同じホストが複数のECHONET Liteオブジェクトを持つ場合でも、それぞれ異なるリソースでその制御等を受け付けるのではなく、全てのオブジェクトに対する制御等を全てこのリソースで受け付ける。
httpは、TLS利用時はhttpsを用いる。ホストはIPアドレスまたはFQDNを用いる。ポートは利用するTCPポート番号を用いる（省略可）。リソース識別子はIANAに登録されている他のwell-known URIと重複しない文字列を用いる。定義の一例は、"echnonet-lite"である。識別子を"echnonet-lite"として定義した場合に、ホスト名、ポート番号を仮定したURIの例を以下に示す。
http://light01.bldg01.example.org:8080/.well-known/echonet-lite
＜例２＞ CoRE link Format（非特許文献５によるリソース識別子の定義：
非特許文献５で定義される、rtアトリビュートを用いて、あるHTP URIで指定されるリソースが、本発明におけるECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付けることを示す識別子を定義する。
識別子は、あるリソースが、本発明のECHONET LiteとHTTPの組み合わせによる機器の制御・管理・監視を受け付ける、という情報のみを示し、そのリソースが実際に対応するECHONET Liteオブジェクトまでは特定できない形で定義してもよい。また、あるリソースが実際に対応するECHONET Liteも同時に特定できる形で定義してもよい。
前者の例を次に示す。
rt="echonet-lite" （rtのみを使用し、ifは使用しない場合）
rt="echonet-lite",if=http://www.example.org/echonet-lite.wadl （本発明におけるECHONET LiteとHTTPの組み合わせで用いるCoAPインタフェース仕様をWADL形式で記述し、それを参照する場合）
後者の例を次に示す。
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オブジェクトとして、２つの照明機器（0x29001,0x029002）と家庭用エアコン（0x13001）が有ることをifで示す場合）
次に、機器１０Ｂの動作を説明する。
図２１は、本発明の第２の実施の形態における機器の動作のフローチャートである。
ステップ２０１） 機器１０Ｂを起動する。
ステップ２０２） 通信制御部１７は、上記に示した通信インタフェース１８を開始する。
ステップ２０３） 通信制御部１７は、通信インタフェース１８を介してIPアドレスを取得し、CPU・メモリ１１に設定する。このときのプロトコルはDHCP(Dynamic Host configuration Protocol)、IPv6ND(Neighbor Discovery)などのメカニズムを用いても良いし、静的に設定してあってもよい。
ステップ２０４） 通信制御部１７は、通信ネットワーク１を介してデータベース３０からリソースディレクトリの探索を行う。このとき、DHCPオプションを用いても良いし、静的に設定してあってもよい。
ステップ２０５） ステップ２０４により発見したリソースディレクトリに自己リソースの登録を行う。
以下に、詳細に説明する。機器１０Ｂによるリソース登録の例を図２２に示す。
機器１０Ｂは、上記のステップ２０４において、DHCPオプション、DNS-SDなどの何らかの手段で発見したドメイン上のリソースディレクトリ（データベース３０）に対して、自らがホストするECHONET Liteによる機器の制御・管理・監視を受け付けるリソースの情報を、HTTP POSTメッセージを送信することで登録する。
リクエストURLパラメータとして、自らをドメイン内で一意に特定する識別子"ep=node1"として設定し、ECHONET Liteによる機器の制御・管理・監視を全て一括して"/ech o"というリソースで受け付けることを示す情報を、POSTメッセージのペイロード部に、RFC6690のCore Link Format形式で設定する。このとき、上記の＜例１＞、＜例２＞で述べたリソース識別子を設定する（以下の例では、rt=echonet-lite）。
複数のリソースでECHONET Liteによる機器の制御・管理・監視を受け付ける場合は、第１の実施の形態におけるCoAPの場合と同様のペイロードをHTTP POSTメッセージに設定する。
なお、図２２の例では、機器１０Ｂとデータベース３０との間で認証、認可手段は省略しているが、先立って認証、認可の手順が実行されてもよい。
次に、本実施の形態におけるECHONET Liteサービス（要求用）とHTTPメソッドのマッピングの例を示す。
本実施の形態において、アプリケーション層の通信プロトコルとして、HTTP上で非特許文献１の行う際に、ECHONET Liteサービス(ESV)と、HTTPメソッドのマッピングの例は図２３に示ように、プロパティ値の書き込み要求及び書き込み・読み出し要求については、HTTP PUTメソッドを用いる。プロパティ値の読み出し要求については、HTTP GETメソッドを用いる。
また、図２４に、非特許文献１で定義されるECHONET Lite（ESV）（応答用）とHTTPレスポンスのマッピングの例を示す。プロパティ値書き込み応答、プロパティ値読出し応答、プロパティ値書き込み・読み出し応答に"200OK"を用いる。
さらに、ECHONET Liteサービス（通知・通知応答用）とHTTPメソッド・レスポンスのマッピングを図２５に示す。
プロパティ値通知要求は、管理ノード２０Ｂにおいて、ECHONET Lite処理部２５が生成したECHONET Lite通知要求フレームをHTTP処理部２６ＢがHTTP POSTリクエストのペイロードに設定して通信制御部２７を介して送信される。HTTPメッセージタイプは"CON"を用いる。
プロパティ値の通知は、応答の要・不要を問わず、ECHONET Lite通知フレームをペイロード部に格納したHTTP POSTリクエストを送信することで実施する。
プロパティ値通知不可応答は、ECHONET Lite処理部１５において、要求を受け付けない場合、あるいは指定されたDEOJは存在するが、指定されたEPCが存在しない場合は、403 Forbiddenを用いる。ECHONET Lite処理部１５において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合、あるいは、読み出し要求される全プロパティ値を返そうとしたが、許されるECHONET Lite電文長を超える場合には、500 Server Internal Errorを用いる。
次に、非特許文献１で定義されるECHONET Liteサービス(ESV)（不可応答用）とHTTPレスポンスのマッピングの例を図２６に示す。
機器１０ＢのECHONET Lite処理部１５において、要求を受け付けない場合、あるいは、指定されたDEOJは存在するが指定されたEPCが存在しない場合は、403 Forbiddenを用いる。
ECHONET Lite処理部１５において、指定されたDEOJは存在するが、制御要求対象となるプロパティ数が多く全てを処理できない場合は、500 Server Internal Errorを用いる。
次に、アプリケーション層の通信プロトコルHTTP上で非特許文献１の技術を動作させる場合の、機器の制御・管理・監視のためのECHONET Liteフレームを含むHTTPメッセージの例を以下に示す。
管理ノード２０は、HTTPメッセージのペイロード部に非特許文献１で定義されるECHONET Liteフレームをそのまま格納する。このとき、HTTPヘッダとして、Content-Typeヘッダに、IANA MIME Media Typeで定義されているECHONET Liteフレームを表すMedia Typeを設定する。
例えば、非特許文献１で定義される住宅・設備関連機器クラスグループ・一般照明クラスに属する照明装置(DEOJ=0x029001)の動作状態(EPC=0x80)をON(EDT=0x30)にする。つまり、電源を入れる場合のメッセージを図２７に示す。
この例では、照明装置を具備する機器が、
http://light01.bldg01.example.org/
というURIで指定されるリソースで、同照明装置の制御・管理・監視を受け付ける。照明装置に対応するECHONET Liteオブジェクトは、インスタンス番号"0x01"でインスタンス化されている。
制御メッセージの送信元の管理ノード２０Ｂは、非特許文献１で定義される管理・操作関連機器クラスグループ・コントローラクラスに属するコントローラ装置(SEOJ=0x05FF01)である。
HTTPメッセージのContent-Formatオプションには、"application/echonet-lite"を設定している。なお、図２７の例は、可読性のためECHONET Liteフレームをテキスト形式で記しているが、実際には、非特許文献１で定義されるメッセージフォーマットに従ってバイナリエンコードされる。
［第３の実施の形態］
本実施の形態では、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる場合について説明する。
図２９は、本発明の第３の実施の形態における処理のシーケンスチャートである。
以下では、機器１０Ｃと中間ノード５０がローカルネットワークで接続され、また、中間ノード５０が通信ネットワーク1に接続されているものとして説明する。
ステップ３０１） UDP上でECHONET Liteを動作させる通常の機器１０Ｃは、ローカルネットワーク上に自らの機器情報（アドレス、種別、能力等）を示すECHONET Liteフレームを広告する。
ステップ３０２） 中間ノード５０は、上記のECHONET Liteフレームを受信し、通信ネットワーク１に対して、自身があたかも機器１０Ｃであるかのように見せるため、通信ネットワーク１からアクセス可能なECHONET Liteディレクトリ（データベース３０）へ機器１０Ｃの機器情報を代理登録する。
ステップ３０３） TCP上でECHONET Liteを動作させる管理ノード２０は、通信ネットワーク１からECHONET Liteディレクトリ（データベース３０）を検索して、中間ノード５０が代理登録した機器１０Ｃの情報を取得する。
ステップ３０４） 管理ノード２０は、取得した情報に従って、中間ノード５０に対して制御のためのECHONET Liteメッセージを送信する。
ステップ３０５） 中間ノード５０は、上記ステップ３０４のECHONET Liteメッセージを受信し、当該メッセージ内容に準じたECHONET LiteフレームをUDP上で機器１０Ｃに対して送信し、機器１０Ｃを制御する。
ステップ３０６） 機器１０Ｃからの応答メッセージを中間ノード５０において、TCPに載せ換えて管理ノード２０に送信する。
以上のように動作することで、UDPとTCPの相互変換を行いつつ、通信ネットワーク１とローカルネットワークの間でECHONET Liteを用いて機器制御が可能となる。
TCP上でECHONET Liteを動作させる場合の機器１０Ｃ及び管理ノード２０の用いる通信プロトコル構成は図２８に示す通りである。また、中間ノードは図３０または、図３１に示す通信プロトコルを用いる。
物理層（PHY）、データリンク層(MAC)は任意である。
ネットワーク層は、IPv4またはIPv6のいずれかである。また、トランスポート層はTCPを用いる。TLSを用いてもよい。
次に、機器の接続先発見方法について説明する。
図３２は、本発明の第３の実施の形態における接続機器の接続先発見方法の例を示す。
本発明において、アプリケーション層の通信プロトコルではなく、TCPの上でECHONET Liteを動作させる場合の、機器１０Ｃの用いる接続先の発見方法の例を示す。
機器１０Ｃは、第１の実施の形態と同様の構成を有し、図９のDNS-SDを用いたCoAPリソースディレクトリの発見の同様の手順で、TCP上でECHONET Liteを動作させる際に接続するECHONET Liteディレクトリの情報を取得することができる。これ以外に、DHCPオプションで取得したり、静的に設定してある値を読み込む等の他の手順で取得してもよい。
次に、機器３０Ｃによる機器情報通知の例を説明する。
図３３は、本発明の第３の実施の形態における機器による機器情報通知の例であり、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを動作させる場合の、ECHONET Lite機器情報の通知の例を示す。なお、図３３では、機器１０Ｃとデータベース３０との間で認証、認可手順は省略しているが、先立って認証、許可の手順が実行されてもよい。
機器１０Ｃは、DHCPオプション、DNS-SDなど何らかの手段で発見した、ドメイン上のECHONET Liteリソースディレクトリ（データベース３０）に対して、自らのECHONET Lite機器情報を、非特許文献１に記載されたマルチキャストパケットとしてではなく、該リソースディレクトリに対するTCPコネクションを確立した上でユニキャストパケットとして、TCPペイロードとしてECHONET Lite通知フレームを設定して送信する。
機器１０Ｃの制御・管理・監視のための管理ノード２０の処理の例を説明する。当該管理ノード２０は、第１または第２の実施の形態と同様の構成を有するが、異なる処理を行うため、管理ノード２０Ｃとして説明する。
なお、当該管理ノード２０Ｃは、図３に示す通信制御部２７を、TCP通信を制御するための通信制御部２７Ｃとして動作するものとして説明する。
制御・管理・監視を行う管理ノード２０Ｃは、図３２に示したECHONET Liteリソースディレクトリの発見を行い、リソースディレクトリの情報を取得する。その後、同リソースディレクトリに対してECHONET Lite通知要求フレームを送信して、自らが制御・管理・監視を行うことのできる機器及びそのアドレス、種別、能力の情報の一覧を取得する。管理ノード２０Ｃは、この手順を定期的に実行してもよく、ユーザまたは管理端末４０からの指示に応じて実行してもよい。
管理ノード２０Ｃのアプリケーション部２４Ｃは、この情報をメモリ２１Ｃ内に格納した上で、管理ノード２０Ｃを操作するユーザに対してグラフィカルユーザインタフェースを用いて一覧表示する、または、通信により管理ノード２０Ｃのアプリケーション部２４Ｃを操作する管理端末４０のアプリケーションに対して一覧の情報を送信する。
管理ノード２０Ｃのアプリケーション部２４Ｃは、ユーザないしは管理端末４０のアプリケーションからの指示に従って、ECHONET Lite処理部２５Ｃに処理を渡す。
ECHONET Lite処理部２５Ｃは、制御対象の機器１０Ｃの種別、及び制御内容に応じて適切なECHONET Liteフレームを生成し、TCPの通信制御部２７に処理を渡す。TCPの通信制御部２７Ｃは、当該ECHONET Liteフレームの送信先アドレス・ポート番号に対して、TCPコネクションを確立し、確立したTCPコネクション上で、当該ECHONET Liteフレームをペイロードに設定した適切なTCPメッセージを生成し、機器１０Ｃに送信する。
次に、アプリケーション層の通信プロトコルではなく、TCP上でECHONET Liteを得動作させる場合の中間ノード５０におけるリソース管理処理について説明する。中間ノード５０は、機器１０Ｃと同様の構成であるので、その説明を省略する。中間ノード５０の通信プロトコル構成は図３０，３１に示す通りである。
本発明の技術をサポートしない通常のECHONET Lite機器を収容するための中間ノード５０Ｃの通信プロトコルを図３０に示す。図３０は、本発明の技術と、通常のUDP上でのECHONET Lite技術の相互運用を行うため、PHY、MAC、IP層、TCP/UDP層のプロトコルの変換を行う場合の例である。この他、UDP/TCP層の相互変換を行わず、TCPのままでよい場合、PHY、MAC、IP層の相互変換を行わない場合、及び、それらの組み合わせの場合があり得るが、その記載は省略する。
また、本発明と非IP通信規格の上でのECHONET Lite技術の相互運用を行うため、中間ノード５０Ｃにおいて、TCP層以下のIP系プロトコルと、非IP通信規格との相互変換を行う場合の例を図３１に示す。
中間ノード５０は、起動後、図３２に示す機器１０Ｃと処理と同様の処理を行うことによりECHONET Liteリソースディレクトリの情報を取得する。
中間ノード５０が、自らも本発明の技術をサポートする機器として振る舞い、機器の制御・管理・監視を直接受け付ける場合には、図３３に示すように機器１０Ｃの処理と同様に、リソースディレクトリ（データベース３０）に対して自らの機器情報を登録する。
中間ノード５０は、通信ネットワーク１上で、非特許文献１の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、該機器のアドレス、種別、能力の情報を記憶し、自らが通信に利用可能な（他の通信で利用されていない）IPアドレス・ポート番号の組から、当該機器に対する本発明の制御・管理・監視メッセージを以後受け取るためのIPアドレス・ポート番号の組を選び出し、選び出した当該IPアドレス・ポート番号の組と該機器のアドレス情報（IPアドレス、ポート番号の組、もしくは、当該機器が非IP通信規格を用いている場合は、当該通信規格における通信アドレス)の対応関係を記憶し、選び出した当該IPアドレス・ポート番号を用いてリソースディレクトリ(データベース３０)へのTCPコネクションを確立し、当該TCPコネクション上で、先に受け取った機器情報の広告通知ECHONET Liteフレームをリソースディレクトリへ送信して登録する。既に一つ以上のIPアドレス・ポート番号の組を選び出して対応関係を持っている機器から新たな機器情報を受信した場合は、当該IPアドレス・ポート番号の組でリソースディレクトリ(データベース３０)に対してTCPコネクションを確立して（確立済みの場合はそのコネクションを使用して）当該機器情報の通知ECHONET Liteフレームを送信して更新処理を行う。
次に、中間ノード５０が、機器制御・管理・監視メッセージを受信する際の例を説明する。
中間ノード５０は、TCPの通信処理部において、受信したTCPメッセージのペイロードがECHONET Liteである場合、処理をECHONET Lite処理部５５へ渡す。ECHONET Lite処理部５５は、当該TCPメッセージを受信したIPアドレス及びポート番号の組と、その組が対応する機器アドレスの対応関係のリストを検索し、当該IPアドレス・ポート番号の組が、自らが直接制御・管理・監視を受け付ける機器に対応するリソースである場合は、非特許文献１に従ってECHONET Liteフレームを処理し、機器の制御・管理・監視を実行する。
一方、中間ノード５０がIPアドレス・ポート番号の組が、自らが直接制御・管理・監視を受け付ける機器ではなく、他の機器に対応する場合には、ECHONET Lite処理部５５に処理を渡さず、アプリケーション部５４へ処理を渡す。アプリケーション部５４は、当該IPアドレス・ポート番号の組が対応する機器が用いている通信規格を処理する処理部（当該機器がTCP/IPを用いている場合はTCPの通信処理部、非IP通信規格を用いている場合は、非IP通信規格の通信処理部）へ、該ECHONET Liteフレームを渡し、該機器へ各通信規格の通信手順によってECHONET Liteフレームを送信させる。例えば、該機器がUDP/IPを用いている場合は、取り出したECHONET Liteフレーム及び該フレームを送信すべき機器のアドレス情報を通信処理部を介して、非特許文献１に従う通常のUDP上で動作するECHONET Liteを持つIPパケットとして、該機器に送信する。
[第４の実施の形態]
本実施の形態では、本発明の技術をサポートしないUDP/TCP上で直接ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を本発明の技術と相互運用を可能にするため、かつ／または、それらの機器の間に介在して機器情報の交換やアドレス解決の支援を行うための中間ノード５０について説明する。
当該中間ノード５０は、システム全体において唯一存在してもよく、複数存在してもよい。なお、中間ノード５０は、前述の機器１０と同様の構成であるので各部の説明は省略する。
アプリケーション層の通信プロトコルとして、CoAP上で非特許文献１の技術を動作させる場合の、中間ノード５０の処理のリソース管理処理について説明する。
中間ノード５０は、起動後、図９と同様の方法でデータベース３０のCoAPリソースディレクトリに情報を登録する。
中間ノード５０が、自らも本発明の技術をサポートする機器として振る舞い、機器の制御・管理・監視を直接受け付ける場合は、図１０と同様の方法でデータベース３０のリソースディレクトリに対して自らのリソース情報を登録する。
中間ノード５０は、通信ネットワーク上で、非特許文献１の技術に従ったECHONET Lite機器からの機器情報の広告通知を受け取った場合、その機器のアドレス、種別、能力の情報を記憶して、その機器に対する本発明の制御・管理・監視メッセージを受け取るためのCoAPURLで特定されるリソースを生成し、該リソースと該機器のアドレス情報（IPアドレス、ポート番号の組、もしくは、該機器が非IP通信規格を用いている場合は、該通信規格における通信アドレス）の対応関係をメモリに記憶し、生成した該リソースの情報をデータベース３０のリソースディレクトリへ登録する。既に一つ以上のリソースとの対応関係を持つ機器から新たな機器情報を受信した場合は、既にリソースに対応付けられたものである機器情報については、それが対応するリソースの情報を更新した上で、リソースディレクトリに対しても更新処理を行う。
既に、一つ以上のリソースとの対応関係を持つ機器から機器情報ではあるが、対応するリソースがまだ生成されていない機器情報については、該機器と対応するリソースのうちのいずれかに、新たに受信した該機器情報を追加する形で更新し、リソースディレクトリに更新処理を行ってもよく、また、新規にリソースを生成して該機器のアドレスとの対応関係を記憶し、生成した該リソースの情報をリソースディレクトリに登録してもよい。
なお、上記では、リソース情報をデータベース３０のリソースディレクトリに登録・更新する例を示したが、中間ノードがリソースディレクトリを兼ねてもよい。
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
１ 通信ネットワーク
１０ 機器
１１ CPU・メモリ
１２ 機器インタフェース
１３ 機器制御部
１４ アプリケーション部
１５ ECHONET Lite処理部
１６Ａ CoAP処理部
１６Ｂ HTTP処理部
１７ 通信制御部
１８ 通信インタフェース
２０ 管理ノード
２１ CPU・メモリ
２４ アプリケーション部
２５ ECHONET Lite処理部
２６Ａ CoAP処理部
２６Ｂ HTTP処理部
２７ 通信制御部
２８ 通信インタフェース
３０ データベース
４０ 管理端末
５０ 中間ノード
５１ CPU・メモリ
５２ 機器インタフェース
５３ 機器制御部
５４ アプリケーション部
５５ ECHONET Lite処理部
５６ CoAP処理部
５７ 通信制御部
５８ 通信インタフェース

Claims (15)

  1. 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処理手段と、
    を有することを特徴とする通信ノード。
  2. アプリケーション層の通信プロトコルとして、前記CoAP上で、前記ECHONET Liteを動作させる場合に、OSI第４層(トランスポート層)の通信プロトコルのみならず、OSI第５〜第７層の通信プロトコルに位置するCoAPとの複合的な組み合わせを用いる手段を含む
    請求項１記載の通信ノード。
  3. 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処理手段と、
    を有することを特徴とする通信ノード。
  4. アプリケーション層の通信プロトコルとして、前記HTTP上で、前記ECHONET Liteを動作させる場合に、OSI第４層(トランスポート層)の通信プロトコルのみならず、OSI第５〜第７層の通信プロトコルに位置するHTTPとの複合的な組み合わせを用いる手段を含む
    請求項３記載の通信ノード。
  5. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
    アプリケーション層の通信プロトコルとしてTCP(Transmission Control Protocol)上でECHONET Liteを動作させる場合に、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
    ECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリに対してECHONET Lite通知要求フレームを送信することにより、前記通信ノードが制御・管理・監視する機器の機器情報の一覧を取得し、管理端末に送信する機器情報取得手段と、
    前記管理端末からの指示に従って、制御対象の機器情報及び制御内容に応じてECHONET Liteフレームを生成するECHONET Lite処理手段と、
    前記ECHONET LiteフレームからTCPメッセージを生成し、前記通信制御手段と前記広域ネットワークを介して、該制御対象の機器に送信するTCP処理手段と、
    を有することを特徴とする通信ノード。
  6. 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フレームを送信する手段を含む
    ことを特徴とする通信ノード。
  7. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いて、広域ネットワークを介して機器の制御、管理、監視を行う通信ノードであって、
    UDP/TCPの上で直接、ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を相互運用する場合に、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記広域ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
    アプリケーション層のプロトコルに対応するリソースディレクトリの情報を取得するリソースディレクトリ情報取得手段と、
    機器の制御、管理、監視を直接受け付ける場合に、前記リソースディレクトリに対して自ノードのリソース情報を登録するリソース情報登録手段と、
    前記機器から機器情報を受け取ると、該機器のアドレス情報を記憶手段に格納し、該機器に対する制御、管理、監視メッセージを受け取るためのリソースを生成し、該リソースと該機器のアドレス情報の対応関係を該記憶手段に格納し、該リソースを前記リソースディレクトリに登録する機器情報登録手段と、
    既に前記リソースディレクトリに前記リソースと機器のアドレス情報の対応関係が登録されていて、新たな機器情報を受信した場合には、該新たな機器情報で、該リソースディレクトリを更新する更新手段と、
    を有することを特徴とする通信ノード。
  8. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムであって、
    アプリケーション層の通信プロトコルとしてCoAP(Constrained Application Protocol)上でECHONET Liteを動作させる場合に、
    通信ネットワークと、
    前記通信ネットワークを介して機器を制御、管理、監視する管理ノードと、
    前記通信ネットワークを介して、前記管理ノードからのECHONET LiteとCoAPの組み合わせによるメッセージを受信した場合には、該メッセージに基づいて当該機器の制御を行い、ECHONET LiteとCoAPの組み合わせによるCoAPメッセージを生成し、該管理ノードに送信する機器と、
    前記通信ネットワークを介して前記機器の通信アドレス、種別、能力の情報を管理すると共に、サーバ、リソースディレクトリとして振舞うデータベースと、
    を、有し、
    前記管理ノードは、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記通信ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
    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メッセージを処理し、該CoAPメッセージがECHONET LiteとCoAPの組み合わせのメッセージである場合に、前記ECHONET Lite処理手段に処理結果を渡して前記機器の制御を指示し、該ECHONET Lite処理手段からの命令と前記ECHONET Liteフレームに従って、該ECHONET LiteとCoAPを組み合わせたCoAPメッセージを生成し、前記通信制御手段を介して、該機器に送信するCoAP処理手段と、
    を有することを特徴とするネットワークシステム。
  9. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムであって、
    アプリケーション層の通信プロトコルとしてHTTP(Hypertext Transfer Protocol)上でECHONET Liteを動作させる場合に、
    通信ネットワークと、
    前記通信ネットワークを介して機器を制御、管理、監視する管理ノードと、
    前記通信ネットワークを介して、前記管理ノードからのECHONET LiteとCoAPの組み合わせによるメッセージを受信した場合には、該メッセージに基づいて当該機器の制御を行い、ECHONET LiteとCoAPの組み合わせによるCoAPメッセージを生成し、該管理ノードに送信する機器と、
    前記通信ネットワークを介して前記機器の通信アドレス、種別、能力の情報を管理すると共に、サーバ、リソースディレクトリとして振舞うデータベースと、
    を、有し、
    前記管理ノードは、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記通信ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
    ECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリから、前記管理ノードが制御・管理・監視する機器の機器情報を取得し、前記データ格納手段に格納する手段と、
    前記機器からECHONET LiteとHTTPの組み合わせによる前記CoAPメッセージを受信して、該CoAPメッセージに応じた機器の制御を前記通信制御手段を介して実行し、該通信制御手段からの信号を受け付け、該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処理手段と、
    を有することを特徴とするネットワークシステム。
  10. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムであって、
    アプリケーション層の通信プロトコルとしてTCP(Transmission Control Protocol)上でECHONET Liteを動作させる場合に、
    通信ネットワークと、
    前記通信ネットワークを介して機器を制御、管理、監視する管理ノードと、
    前記通信ネットワークを介して前記機器の通信アドレス、種別、能力の情報を管理すると共に、サーバ、リソースディレクトリとして振舞うデータベースと、
    前記機器と前記データベースのリソースディレクトリとのTCPコネクションを確立する中間ノードと、
    前記通信ネットワークを介して、前記データベースのリソースディレクトリに対して自らのECHONET Lite機器情報を該リソースディレクトリに対するTCPコネクションを確立した上でのユニキャストパケットとして、ECHONET Liteフレームを送信する機器と、
    前記管理ノードに指示を出す管理端末と、
    を、有し、
    前記管理ノードは、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記通信ネットワークを介して、前記機器に対する通信の制御を行う通信制御手段と、
    前記データベースからECHONET Liteのリソースディレクトリの情報を取得し、前記データ格納手段に格納し、該リソースディレクトリに対してECHONET Lite通知要求フレームを送信することにより、前記管理ノードが制御・管理・監視する機器の機器情報の一覧を取得し、前記管理端末に送信する機器情報取得手段と、
    前記管理端末からの指示に従って、制御対象の機器情報及び制御内容に応じてECHONET Liteフレームを生成するECHONET Lite処理手段と、
    前記ECHONET LiteフレームからTCPメッセージを生成し、前記通信制御手段を介して、該制御対象の機器または、前記中間ノードに送信するTCP処理手段と、
    を有し、
    前記中間ノードは、
    通信処理及び前記機器の制御のための演算を行う中間−演算手段と、
    データを格納する中間−データ格納手段、
    前記通信ネットワークを介して、前記機器が他の機器と通信するための入出力及び制御を行う中間−通信制御手段と、
    前記機器から機器情報を取得すると、該機器のアドレス情報、種別、能力を記憶手段に格納し、自ノードが通信に利用可能なIPアドレス・ポート番号の組の中から該機器に対する制御、管理、監視のメッセージを受け取るためのIPアドレス・ポート番号の組を選び出し、該IPアドレス、ポート番号の組と、該機器のアドレス情報の対応関係を前記中間−データ格納手段記憶し、該IPアドレス・ポート番号を用いてリソースディレクトリへのTCPコネクションを確立し、該機器情報を該リソースディレクトリに登録する機器情報登録手段と、
    前記管理ノードから受信した前記TCPメッセージがECHONET Liteフレームを含む場合、該TCPメッセージを受信したIPアドレス及びポート番号の組と、該組が対応する機器のアドレスの対応関係のリストを前記中間−データ格納手段から検索し、検索されたIPアドレス・ポート番号の組が自ノードで直接制御、管理、監視を受け付ける機器に対応するリソースである場合には、該ECHONET Liteフレームを処理する中間−ECHONET Lite処理手段と、
    検索されたIPアドレス・ポート番号の組が自ノードで直接制御、管理、監視を受け付ける機器に対応するリソースでない場合には、該IPアドレス・ポート番号の組が対応する機器が用いている通信規格を処理する通信処理手段に前記ECHONET Liteフレームを渡す中間−アプリケーション手段と、
    を有し、
    前記通信処理手段は、
    前記アプリケーション手段から前記ECHONET Liteフレームを取得すると、前記機器へ各通信規格の通信手順に従って該ECHONET Liteフレームを送信する手段を含む
    ことを特徴とするネットワーク通信システム。
  11. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムであって、
    UDP/TCPの上で直接、ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を相互運用する場合に、
    通信ネットワークと、
    前記通信ネットワークを介して前記機器を制御、管理、監視する管理ノードと、
    前記通信ネットワークを介して前記機器の通信アドレス、種別、能力の情報を管理すると共に、サーバ、リソースディレクトリとして振舞うデータベースと、
    前記機器と前記データベースのリソースディレクトリとのTCPコネクションを確立する中間ノードと、
    UDP/TCP上で直接ECHONET Liteを動作させる、または、非IP通信規格の上でECHONET Liteを動作させる機器と、
    を、有し、
    前記中間ノードは、
    通信処理及び前記機器の制御のための演算を行う演算手段と、
    データを格納するデータ格納手段、
    前記通信ネットワークを介して、前記機器が他の機器と通信するための入出力及び制御を行う通信制御手段と、
    前記データベースから、アプリケーション層のプロトコルに対応するリソースディレクトリの情報を取得するリソースディレクトリ情報取得手段と、
    機器の制御、管理、監視を直接受け付ける場合に、前記リソースディレクトリに対して自ノードのリソース情報を登録するリソース情報登録手段と、
    前記機器から機器情報を受け取ると、該機器のアドレス情報を前記データ格納手段に格納し、該機器に対する制御、管理、監視メッセージを受け取るためのリソースを生成し、該リソースと該機器のアドレス情報の対応関係を該データ格納手段に格納し、該リソースを前記リソースディレクトリに登録する機器情報登録手段と、
    既に前記リソースディレクトリに前記リソースと機器のアドレス情報の対応関係が登録されていて、新たな機器情報を受信した場合には、該新たな機器情報で、該リソースディレクトリを更新する更新手段と、
    を有することを特徴とするネットワークシステム。
  12. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムにおける機器制御方法であって、
    機器、管理ノード、リソースディレクトリを有するシステムにおいて、
    アプリケーション層の通信プロトコルとしてCoAP(Constrained Application Protocol)上でECHONET Liteを動作させる場合に、
    前記管理ノードが、前記リソースディレクトリを検索して機器情報を取得し、制御対象の機器の種別及び制御内容に応じてECHONET Liteフレームを生成し、該ECHONET Liteフレームに従って、ECHONET LiteフレームとCoAPを組み合わせたCoAPメッセージを生成し、該機器のアドレスを解決して、前記機器に送信し、
    前記機器は、前記CoAPメッセージを受信し、該CoAPメッセージにECHONET Liteフレームが含まれている場合には、ECHONET Lite処理を行う
    ことを特徴とする機器制御方法。
  13. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムにおける機器制御方法であって、
    機器、管理ノード、リソースディレクトリを有するシステムにおいて、
    アプリケーション層の通信プロトコルとしてHTTP上でECHONET Liteを動作させる場合に、
    前記管理ノードが、前記リソースディレクトリを検索して機器情報を取得し、制御対象の機器の種別及び制御内容に応じてECHONET Liteフレームを生成し、該ECHONET Liteフレームに従って、ECHONET LiteフレームとHTTPを組み合わせたHTTPメッセージを生成し、該機器のアドレスを解決して、前記機器に送信し、
    前記機器は、前記HTTPメッセージを受信し、該HTTPメッセージにECHONET Liteフレームが含まれている場合には、ECHONET Lite処理を行う
    ことを特徴とする機器制御方法。
  14. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムにおける機器制御方法であって、
    機器、管理ノード、リソースディレクトリ、中間ノードを有するシステムにおいて、
    アプリケーション層の通信プロトコルとしてTCP(Transmission Control Protocol)上でECHONET Liteを動作させる場合に、
    前記機器が自身の機器情報を示すECHONET Liteフレームを広告し、
    前記中間ノードが、前記ECHONET Liteフレームを受信し、前記機器の代わりに、該機器の機器情報を前記リソースディレクトリに登録し、
    前記管理ノードが、前記リソースディレクトリを検索して、前記中間ノードが登録した機器情報を取得し、該機器情報に従って機器を制御するためのECHONET Liteフレームを生成し、該ECHONET Liteフレームの送信先アドレス・ポート番号に対してTCPコネクションを確立し、該ECHONET Liteフレームをペイロードに設定したTCPメッセージを生成し、前記中間ノードを介して機器に送信する
    ことを特徴とする機器制御方法。
  15. ECHONET Lite規格書Ver1.10,エコーネットコンソーシアムを用いたネットワークシステムにおける機器制御方法であって、
    機器、管理ノード、中間ノード、リソースディレクトリを有するシステムにおいて、
    UDP/TCPの上で直接、ECHONET Liteを動作させる機器、及び、非IP通信規格の上でECHONET Liteを動作させる機器を相互運用する場合に、
    前記中間ノードは、
    前記リソースディレクトリからアプリケーション層のプロトコルに対応するリソースディレクトリの情報を取得し、
    前記機器から機器情報を受け取ると、該機器のアドレス情報を記憶手段に格納し、該機器に対する制御、管理、監視メッセージを受け取るためのリソースを生成し、該リソースと該機器のアドレス情報の対応関係を該記憶手段に格納し、該リソースを前記リソースディレクトリに登録し、
    前記管理ノードから機器の制御、管理、監視を直接受け付ける場合には、前記リソースディレクトリに対して自ノードのリソース情報を登録し、
    既に前記リソースディレクトリに前記リソースと機器のアドレス情報の対応関係が登録されていて、新たな機器情報を受信した場合には、該新たな機器情報で、該リソースディレクトリを更新する
    ことを特徴とする機器制御方法。
JP2013176051A 2013-08-27 2013-08-27 通信ノード及びネットワークシステム及び機器制御方法 Expired - Fee Related JP6002642B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013176051A JP6002642B2 (ja) 2013-08-27 2013-08-27 通信ノード及びネットワークシステム及び機器制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013176051A JP6002642B2 (ja) 2013-08-27 2013-08-27 通信ノード及びネットワークシステム及び機器制御方法

Publications (2)

Publication Number Publication Date
JP2015046716A JP2015046716A (ja) 2015-03-12
JP6002642B2 true JP6002642B2 (ja) 2016-10-05

Family

ID=52671916

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013176051A Expired - Fee Related JP6002642B2 (ja) 2013-08-27 2013-08-27 通信ノード及びネットワークシステム及び機器制御方法

Country Status (1)

Country Link
JP (1) JP6002642B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10715482B2 (en) 2015-07-06 2020-07-14 Convida Wireless, Llc Wide area service discovery for internet of things
JP7206947B2 (ja) * 2019-01-24 2023-01-18 株式会社富士通ゼネラル 空気調和システム

Also Published As

Publication number Publication date
JP2015046716A (ja) 2015-03-12

Similar Documents

Publication Publication Date Title
US10404601B2 (en) Load balancing in the internet of things
US11303697B2 (en) Method, apparatus and system for web service management
Liu et al. Efficient naming, addressing and profile services in Internet-of-Things sensory environments
US8898268B2 (en) Method and apparatus for network management
US11044593B2 (en) Method and devices for managing constrained devices
Sleman et al. Integration of wireless sensor network services into other home and industrial networks; using device profile for web services (DPWS)
Villaverde et al. Service discovery protocols for constrained machine-to-machine communications
EP2922321B1 (en) 6lowpan network-based service discovery
JP2019530376A (ja) ＩｏＴデバイスコネクティビティ、ディスカバリ、ネットワーキング
US10798779B2 (en) Enhanced CoAP group communications with selective responses
WO2014118622A1 (en) Method of managing zigbee network in the internet of things
JP2009246449A (ja) 制御中継プログラム、制御中継装置および制御中継方法
US11283668B2 (en) Method and apparatus in a web service system
US9203704B2 (en) Discovering a server device, by a non-DLNA device, within a home network
KR20030055766A (ko) 공중망에서 사설망 내의 디바이스를 제어하기 위한 장치및 방법
JP6002642B2 (ja) 通信ノード及びネットワークシステム及び機器制御方法
JP2011103626A (ja) ホーム機器情報収集装置及びホーム機器情報収集方法
JP2008072519A (ja) 機器検索装置、機器検索方法及びプログラム
JP5135422B2 (ja) ゲートウェイ装置
Stolikj et al. Nomadic service discovery in smart cities
Weqar et al. Autonomous Device Discovery for IoT: Challenges and Future Research Directions
KR101303030B1 (ko) ⅠＰｖ６를 지원하는 프로토콜을 이용한 호스트 동작상태 및 탐색 방법
JP4945793B2 (ja) 電子装置、名前解決方法および名前解決制御プログラム
Herrero et al. Resource Identification and Management
JP2019024161A (ja) 通信装置及びデータ転送方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150629

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160614

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160812

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160830

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160905

R150 Certificate of patent or registration of utility model

Ref document number: 6002642

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees