JP2014082562A - 通信装置および通信方法 - Google Patents

Abstract

【課題】多様なプロトコル機器やベンダ機器により構成され、また構成が随時変更されるようなネットワーク環境において、効果的に機器を管理・制御する技術を提供する。
【解決手段】ＥＣＨＯＮＥＴ Ｌｉｔｅ処理部と下位通信層に依存した処理部をそれぞれ、独立のバンドルとし、下位通信層に依存しないインタフェースとして定義された送受信用のサービスを登録して利用する。
【選択図】図４

Description

本発明は、通信装置及び通信方法に関する。

特許文献１には、階層化したネットワークの抽象モデルに基づいて、各層におけるネットワーク要素に対する管理・制御のためのネットワーク機器種別に依らない共通インタフェースを提供する機能、共通インタフェースを介して受け付けた特定のネットワーク要素に対する管理・制御要求を、機器種別毎の固有の管理・制御要求方式に変換して該機器を管理・制御し、また、機器からの固有の該要求に対する応答、あるいは通知を、共通の応答、通知方式に変換して共通ＩＦを介して応答、通知する方法が開示されている。

特開2005-252628号公報

特許文献１では、下位通信部とのインタフェースについては個別定義を前提としており、共通化されていない。また、ドメイン（同一の通信規約で接続可能な範囲。）内に機器が追加されたことは検出可能であるが、サブネット自体が追加されることについては、言及されていない。そのため、新たにネットワークが追加された場合に、そこに接続された機器を検出することができない。

本発明は、多様なプロトコル機器やベンダ機器により構成され、また構成が随時変更されるようなネットワーク環境において、効果的に機器を管理・制御する技術に関する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。

上記の手段によれば、ホームネットワーク上の機器を管理・制御するにあたって、下位通信層に依存しない通信規格を実装した機器であっても、容易に管理・制御することができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

システムの構成例を示すブロック図である 通信装置のハードウェア構成例を示すブロック図である 通信装置のソフトウェア構成例を示すブロック図である ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル及び下位通信層バンドルの構成例を示すブロック図である。 電文の構成例を示す図である。 下位通信層抽象化インタフェース１３２３のパラメータ及び機器管理バンドル１４１０が提供する機器を操作するためのサービスの識別情報の構成例である。 ＯＳＧｉフレームワークで管理するサービス情報の一構成例である。 初期化処理の一例を示すシーケンス図である。 電文受信処理の一例を示すシーケンス図である。 電文送信処理の一例を示すシーケンス図である。 ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス登録処理の一例を示すフローチャートである。 ＥＣＨＯＮＥＴ Ｌｉｔｅ機器切断監視処理の一例を示すフローチャートである。 表示端末の画面の一例である。 ＵＳＢデバイス１０のハードウェア及びソフトウェア構成例である。 宅内ネットワーク５３上を流れる電文の構成例である。 本実施例における通信装置１００のソフトウェア構成例を示すブロック図である。 新規ネットワーク追加処理の一例を示すシーケンス図である。 通信ネットワーク離脱処理の一例を示すシーケンス図である。 本実施例においてＯＳＧｉフレームワークで管理するサービス情報の一構成例である。

近年、環境保護のためのＣＯ２の削減や電力料金の削減、電力不足への対策のためのエネルギーマネジメントシステムが注目を集めている。このようなエネルギーマネジメントシステムの一形態として、家庭のエネルギーマネジメントを行うホームエネルギーマネジメントシステム（ＨＥＭＳ）がある。ＨＥＭＳは、制御・状態監視のために宅内の機器同士を接続するホームネットワーク技術をベースとして構成される。

一方で、ネットワークに接続している機器の種類が増え、エネルギーマネジメントのほかにもホームネットワークによるサービスも多様化していることから、より簡単にホームネットワークを構築したいという要求が増えている。このようなホームネットワークを実現する規格として、例えば、ＥＣＨＯＮＥＴコンソーシアムが定めたＥＣＨＯＮＥＴ規格及びＥＣＨＯＮＥＴ Ｌｉｔｅ規格がある。ＥＣＨＯＮＥＴ Ｌｉｔｅ規格では、ＥＣＨＯＮＥＴ規格で定めていたＥＣＨＯＮＥＴアドレス等の機器識別に関わる情報や手順の規定が削除されるとともに、利用可能な下位通信層についても規定が削除されているため、開発者はよりシンプルに、任意の通信を用いて対応機器を実現することが可能になっている。しかし、これによってＥＣＨＯＮＥＴ Ｌｉｔｅ規格では任意の下位通信層が適用可能なため、機器類を制御するコントローラ側では、統一的に機器の識別・管理を行うことが困難になっている。

以下、本発明を実施するための形態について図面を用いて説明する。なお、図面において、同一符号は、同一または相当部分を示す。また、本発明は、図示例に限定されるものではない。

本実施例は、ＥＣＨＯＮＥＴ Ｌｉｔｅにおける機器管理方法について説明する。

＜システム構成＞
図１は、本実施例のシステム構成の例である。

＜各装置の構成ブロック＞
１はユーザ宅、２は通信サービスプロバイダが提供するアクセスネットワーク、３は、アクセスネットワークや拠点をつなぐインターネット、４はインターネット上のサーバである。また、５及び６は電力会社などが運営する無線または有線アクセスネットワーク、７は電力会社の運営するメータリングデータ管理システムＭＤＭＳ（Ｍｅｔｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）である。

ユーザ宅１において、５１はＥｔｈｅｒｎｅｔ（登録商標）で構成された有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続された宅内ネットワーク、５２は無線ＬＡＮ（８０２．１１）で接続された宅内ネットワーク、５３はＩＥＥＥ８０２．１５．４で構成された無線ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続された宅内ネットワークである。

１００は接続されたネットワーク上の機器を管理する通信装置、２００は通信装置またはサーバと接続して機器の状態を表示したり、機器の操作画面を表示する表示端末、３００はネットワーク接続機能付エアコン、３５０はネットワーク接続機能無エアコン、４００は電力量メータ、４５０はガスメータ、５００は温度・湿度などを計測するセンサ、５５０は分電盤、６００は蓄電池、６５０は照明、７００は太陽光発電システムである。

また、１０は通信装置１００に接続して宅内ネットワーク５３への接続機能を提供するＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）アダプタ、２０はエアコン３５０に接続して宅内ネットワーク５１への接続機能を提供するアダプタ、３０は、分電盤５５０における電力量を計測し、その結果を宅内ネットワーク５１を介して通信装置１００に送信する計測装置、４０はガスメータ４５０に接続して宅内ネットワーク５３への接続機能を提供するアダプタである。

宅内ネットワーク５１には、通信装置１００と、デジタルテレビ２５０と、アダプタ２０を介してエアコン３５０と、計測装置３０と、蓄電池６００と、照明６５０と、太陽光発電システム７００が接続され、相互にデータの送受信を行うことにより、情報取得及び操作ができる。

宅内ネットワーク５２には、通信装置１００と、表示端末２００と、エアコン３００が接続され、相互にデータの送受信を行うことにより、情報取得及び操作ができる。

宅内ネットワーク５３には、通信装置１００と、電力メータ４００と、アダプタ４０を介してガスメータ４５０と、センサ５００がＵＳＢアダプタ１０を介して接続され、相互にデータの送受信を行うことにより、ネットワークを介しての情報取得及び操作ができる。

通信装置１００がユーザ宅１の各機器とのデータ送受信により取得した情報は、インターネット３を介してサーバ４に送信され、サーバ４に蓄積される。ユーザは、表示端末２００やデジタルテレビ２５０を利用することで、蓄積された情報を閲覧できる。

ここで、図１では、宅内ネットワーク５１におけるハブや、宅内ネットワーク５２、または５３における中継器については図示していないが、必要に応じて接続されているものとする。また、ここでは、通信装置１００が直接アクセスネットワーク２に接続しているが、ルータなどを介してアクセスネットワークに接続してもよい。

また、図１では電力線は図示していないが、各機器は電力線で分電盤に接続され、分電盤は電力線で電力メータに接続され、電力系統から電力供給を受けているものとする。

本実施例では、ユーザ宅１内の宅内ネットワーク５１、アクセスネットワーク２、インターネット３、宅内ネットワーク５２においては、ネットワークプロトコルとしてＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用し、上位のトランスポートプロトコルにはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）やＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いる。なお、ＩＰにはバージョンの違いとしてＩＰｖ４とＩＰｖ６が有るが、本実施例は、そのどちらかに限定される物ではない。また、宅内ネットワーク５３においてもＵＤＰ／ＩＰｖ６を用いるが、無線区間における伝送効率化のためにヘッダ圧縮などを行う６ＬｏＷＰＡＮ（ＩＰｖ６ ｏｖｅｒ Ｌｏｗ ｐｏｗｅｒ Ｗｉｒｅｌｅｓｓ Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）を使用したＺｉｇｂｅｅ（登録商標）−ＩＰ（以下、ＺｉｇｂｅｅＩＰ）のようなプロトコルを用いる。このような、各ネットワークの物理層等Ｌ４以下の諸元により規定されるネットワークプロトコルスタックを下位通信層と呼ぶ。各種の情報や操作要求の伝送には更に上位のアプリケーションプロトコルとしては、基本的にＥＣＨＯＮＥＴ Ｌｉｔｅが使用されるものとするが、これに限らず、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）や独自のプロトコルを用いてもよいものとする。

図２は、通信装置１００のハードウェア構成例を示すブロック図である。
通信装置１００は、制御部１０１、記憶部１０２、時刻管理部１０３、ＵＳＢインタフェース（Ｉ／Ｆ）１０４、有線ＬＡＮ Ｉ／Ｆ１０５、無線ＬＡＮ Ｉ／Ｆ１０６、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０７から構成する。

制御部１０１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の実行を行い通信装置１００内の他の構成要素を制御する。また、アプリケーションの実行処理を行い、宅内ネットワークで接続された他の機器やアクセスネットワークを介して接続されたサーバへのデータ送受信指示を行うなどして通信装置１００を機能させる。

記憶部１０２は、揮発性メモリおよび不揮発性メモリで構成する。不揮発性メモリにはＯＳやアプリケーションなどの通信装置１００を動作させるためのソフトウェアや固定データを格納する。揮発性メモリにはソフトウェアの動作に必要なデータなどを一時的に格納する。また、制御部１０１の指示に従い、接続された機器の情報など、指示されたデータを保持する。

時刻管理部１０３は、ＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）を備え、アクセスネットワーク１２あるいはインターネット１３上に存在するＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）サーバが提供する時刻情報を利用して、時刻を管理する。ＮＴＰとは、ネットワークに接続される機器において、機器が持つ時計を正しい時刻に同期するためのプロトコルである。

ＵＳＢ Ｉ／Ｆ１０４はＵＳＢＩ／Ｆを備える別のＵＳＢ機器を接続するインタフェースである。ＵＳＢ機器として、特定のネットワークに接続するネットワークインタフェースデバイスが接続された場合には、ＵＳＢ Ｉ／Ｆ１０４は前記特定のネットワークに接続する通信インタフェースとしての機能を提供する。制御部１０１の指示によってＵＳＢ接続された機器との間でデータの送受信を行う。

有線ＬＡＮ Ｉ／Ｆ１０５は、制御部１０１の指示によって宅内ネットワーク５１に接続された機器との間でデータの送受信を行う。

無線ＬＡＮ Ｉ／Ｆ１０６は、制御部１０１の指示によって宅内ネットワーク５２に接続された機器との間でデータの送受信を行う。

ＷＡＮ Ｉ／Ｆ１０７は、制御部１０１の指示によってアクセスネットワーク２を介してインターネットに接続されたサーバなどとの間でデータの送受信を行う。ＷＡＮ Ｉ／Ｆ１０７は、Ｅｔｈｅｒｎｅｔなどの有線通信部、または３Ｇ、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）（登録商標）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などの無線通信部として構成される。

図３は、通信装置１００のソフトウェア構成例を示すブロック図である。
通信装置１００の機能を実現する制御ソフトウェア１０００は、通信装置１００の記憶部１０２に展開され制御部１０１で実行される。図３は、機能的にブロックに分割して記載されており、各ブロックの分割、統合はあり得る。また制御ソフトウェア７０００は、１つのプログラムで実現する必要はなく、２以上のプログラムの組合せによって実現してもよい。

制御ソフトウェア１０００は、ユーザ空間１１００内のＪａｖａ（登録商標） ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）１１１０、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ） フレームワーク１１２０、下位通信層バンドル１２１０、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００、機器管理バンドル１４１０、エアコン制御用の機器制御バンドル１４２０、カーネル空間１５００内のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０、ブリッジ１５２０、Ｅｔｈｅｒｎｅｔ Ｄｒｉｖｅｒ１６００ａ、無線ＬＡＮ Ｄｒｉｖｅｒ１６００ｂから構成する。

ＯＳＧｉフレームワーク１１２０は様々なソフトウェア部品（バンドル）のダウンロード、インストール、実行といったライフサイクルの管理やバンドルが提供する機能インタフェース（サービス）の管理機能を提供する。ＯＳＧｉフレームワーク１１２０は、Ｊａｖａベースのソフトウェアコンポーネント化技術であり、ＯＳＧｉフレームワーク１１２０上で動作するソフトウェアはバンドルともいう。ＯＳＧｉフレームワーク１１２０上で動作するバンドルにはＨＴＴＰサーバ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂによる情報送信機能を持ったコンピュータ。Ｗｅｂサーバともいう。）やＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙの略。家庭内のパソコンや周辺機器、ＡＶ機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様。）に対応した機器の管理・制御といった、ＯＳＧｉサービス基盤に含まれる標準バンドルと、ＯＳＧｉサービス基盤の手法にのっとって実装されたユーザバンドルとがある。

下位通信バンドル１２１０は、Ｊａｖａ ＶＭ１１１０及びカーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０を介して、Ｅｔｈｅｒｎｅｔで構成された宅内ネットワーク５１に接続された機器との間で、データ送受信を行う。また、ネットワークにデータを創出するためのサービスとして、下位通信層インタフェースサービスをＯＳＧｉフレームワーク１１２０に登録し、他のバンドルに提供する。ここでは、下位通信層バンドル１２１０はブリッジ１５２０上でＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔまたは無線ＬＡＮネットワークにデータ送受信を行うが、別の下位通信層を利用する場合は、別途当該下位通信層に対応した下位通信バンドル１２１０を用意すればよい。同じハードウェアを利用する場合でも、異なるプロトコルでデータを送受信する場合は、別の下位通信バンドル１２１０を用意すればよい。このように、下位通信バンドル１２１０を準備することによってＥＣＨＯＮＥＴ Ｌｉｔｅバンドルは下位通信層を意識することなく、それぞれのネットワークに接続された機器とＥＣＨＯＮＥＴ Ｌｉｔｅによる通信ができる。

また、例えば異なるプロトコルで受信した電文を下位通信バンドル１２１０でＥＣＨＯＮＥＴ Ｌｉｔｅ電文に変換することで前記異なるプロトコルで接続された機器も同様に操作することができる。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、ＥＣＨＯＥＮＴ Ｌｉｔｅ電文の解析及び生成を行い、通信装置１００とネットワークを介して接続されたＥＣＨＯＮＥＴ Ｌｉｔｅ機器の検出・切断、制御、イベント通知を行い、当該機能を機器制御バンドル１４２０ａのようなアプリケーションバンドルに提供する。また、ネットワークから受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文を受け付けるためのサービスとして、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスをＯＳＧｉフレームワーク１１２０に登録し、他のバンドルに提供する。また、機器を操作するためのサービスとして、新しく検出した機器に対応するＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスをＯＳＧｉフレームワーク１１２０に登録し、他のバンドルに提供する。

機器管理バンドル１４１０は、通信装置１００のネットワーク状態及びネットワークで新規に検出した機器の監視を行い、必要に応じてサーバから対応する機器制御バンドル１４２０または下位通信層バンドル１２１０をダウンロードし、ダウンロードしたバンドルをＯＳＧｉフレームワーク１１２０に登録する。

機器制御バンドル１４２０は、ユーザまたは他のアプリケーションの指示に従い、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを利用してＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００を介して、ネットワークで接続されたエアコン３００または３５０の制御を行う。機器制御バンドル１４２０は、制御対象の機器毎に準備してもよいし、一つの機器制御バンドルが、複数の機器を制御できてもよい。

ＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０は、ユーザ空間１１００の任意アプリケーションの指示に従って、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰのパケットを解析・構成する機能を有し、Ｅｔｈｅｒｎｅｔ Ｄｒｉｖｅｒ１６００のようなネットワークドライバを介してネットワーク上の機器と前記パケットの送受信を行う。

ブリッジ１５２０は、Ｅｔｈｅｒｎｅｔ Ｄｒｉｖｅｒ１６００ａと無線ＬＡＮ Ｄｒｉｖｅｒ１６００ｂを接続し、上位のアプリケーション等にＬＡＮ Ｉ／Ｆ１０５と無線ＬＡＮ Ｉ／Ｆ１０６を一つのネットワークデバイスとするインタフェースを提供する。

Ｅｔｈｅｒｎｅｔ Ｄｒｉｖｅｒ１６００ａは、ブリッジ１５２０を介してＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０からの指示に従い、有線ＬＡＮ Ｉ／Ｆ１０５を操作して宅内ネットワーク５１へのデータ送受信を行う。

無線ＬＡＮ Ｄｒｉｖｅｒ１６００ｂは、ブリッジ１５２０を介してＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０からの指示に従い、無線ＬＡＮ Ｉ／Ｆ１０６を操作して宅内ネットワーク５１へのデータ送受信を行う。

図４は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル及び下位通信層バンドルの構成例を示すブロック図である。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器管理部１３１０とＥＣＨＯＮＥＴ Ｌｉｔｅ通信処理部１３２０から構成する。

ＥＣＨＯＮＥＴ Ｌｉｔｅ機器管理部１３１０は、ネットワークに接続されたＥＣＨＯＮＥＴ Ｌｉｔｅ機器の検出・管理等を行う機能ブロックであり、機器操作インタフェース１３１１、他機器操作・管理部１３１２、自機器操作・管理部１３１３から構成する。

機器操作インタフェース１３１１は、ネットワークに接続されたＥＣＨＯＮＥＴ Ｌｉｔｅ機器への情報取得・制御指示などの操作を行うためにアプリケーションが利用する操作用インタフェースであり、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器であればエアコン、照明などの機器の種類に関わらず共通の形式でアクセスできるように定義する。

他機器操作・管理部１３１２は、機器操作インタフェース１３１１の他機器の操作を実行する部分であり、電文生成・送信部１３２１を呼び出して他機器との間でＥＣＨＯＮＥＴ Ｌｉｔｅ電文送受信を行うよう指示する。電文送信においては、目的のネットワークにデータ送信が可能な下位通信層バンドルのサービスをＯＳＧｉフレームワーク１１２０から取得する。また、受信した電文を基に識別情報を生成し、機器を操作するためのサービスをＯＳＧｉフレームワーク１１２０に登録する。

自機器操作・管理部１３１３は、通信装置１００自身がＥＣＨＯＮＥＴ Ｌｉｔｅ機器として動作するための各種設定情報等を管理し、アプリケーションからの指示に応じて前記設定情報等の変更・提示を行う。また、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の自機器操作・管理部１３１３が、下位通信層バンドル１２１０から電文を受信するために電文受信・解析部１３２２のオブジェクトをノードオブジェクトとして生成するとともに、自機器がコントローラとして動作するためにコントローラオブジェクトを生成し、前記電文受信・解析部１３２２に登録する。また、下位通信層バンドル１２１０がネットワークから受信した電文を受け取るため機能を提供するため、電文受信・解析部１３２２をＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスとしてＯＳＧｉフレームワーク１１２０に登録する。また、ネットワークで接続された機器からの通信装置１００自身に対する要求を受信し、必要に応じて各種設定情報の変更や、下位通信層バンドル１２１０を介して前記ネットワークで接続された機器への応答を行う。

ＥＣＨＯＮＥＴ Ｌｉｔｅ通信処理部１３２０はＥＣＨＯＮＥＴ Ｌｉｔｅ電文の生成・解析等を行う機能ブロックであり、電文生成・送信部１３２１、電文受信・解析部１３２２、下位通信層抽象化インタフェース１３２３から構成する。

電文生成・送信部１３２１は他機器操作・管理部１３１２の指示によりＥＣＨＯＮＥＴ Ｌｉｔｅ電文を構成し、所望のネットワークに前記生成した電文を送信するために、下位通信層抽象化インタフェース１３２３で定義されたインタフェースに従って、下位通信層バンドル１２１０へのデータ送信を行う。

電文受信・解析部１３２２は、下位通信層バンドル１２１０を介して他機器から受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文を解析し、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器管理部１３１０に送信する。

下位通信層抽象化インタフェース１３２３は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００と下位通信層バンドル１２１０がネットワークに送受信するＥＣＨＯＮＥＴ Ｌｉｔｅ電文をやり取りするためのデータ送受信用インタフェースであり、各宅内ネットワークの下位通信層に関わらず共通の形式でアクセスできるように定義する。下位通信層抽象化インタフェース１３２３は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００を通信路に関わらず利用可能にするための仕組みであり、下位通信層に依存しない抽象的なネットワークインタフェースを規定するものである。ここでは、通信用リソース（ソケットやＣＯＭポート）の確保、各種プロトコルやデバイス実装に依存したパケット化などは、前記下位通信層抽象化インタフェース１３２３を実装したバンドル（本実施例では、下位通信層バンドル１２１０）にて対応するものとし、Ｌ４層以下とＥＣＨＯＮＥＴ Ｌｉｔｅバンドルを切り離し、異なる下位通信層のネットワークインタフェースが複数存在する場合も対応可能にする。また、前記下位通信バンドルをＯＳＧｉサービスとして提供することで、下位通信層そのものの動的な着脱にも対応するものとする。例えば、ＵＤＰ／ＺｉｇｂｅｅＩＰに対応したＵＳＢデバイスを挿入した際、それに対応した下位通信ソフトウェアバンドルをダウンロードして実行する仕組みを作りこむことで、以降、当該インタフェース（ＵＳＢ−ＵＤＰ／ＺｉｇｂｅｅＩＰ）を経由した機器の操作が可能になる。

下位通信層バンドル１２１０は、受信部１２１１、送信部１２１３、プロトコル変換部１２２０から構成する。
受信部１２１１は、Ｊａｖａ ＶＭ１１１０及びカーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０を介して、ネットワークからＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔパケットを受信し、前記ＵＤＰパケットから取り出したＥＣＨＯＮＥＴ Ｌｉｔｅ電文をＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の下位通信層抽象化インタフェース１３２３を介して電文受信・解析部１３２２に送信する。本実施例では、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０が下位通信層におけるヘッダ類の除去を行うが、受信部１２１１は、必要に応じて下位通信層におけるヘッダの除去などを行ってもよい。
また、受信部１２１１はアドレス取得部１２１２を備え、受信したＵＤＰパケットの送信元アドレス情報を取得し、ＥＣＨＯＮＥＴ Ｌｉｔｅ電文と一緒に電文受信・解析部１３２２に送信する。ここでのアドレス情報とは、ＩＰアドレスとＭＡＣアドレスのいずれか１つ、または両方である。ＭＡＣアドレスの取得については、例えばＩＰｖ４であればカーネル空間１５００で管理されるＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）テーブルを参照して取得することができる。また、ＩＰｖ６でも同様に、カーネル空間１５００で管理される近隣キャッシュ（ｎｅｉｇｈｂｏｒ ｃｈａｃｈｅ）を参照して取得することができる。

送信部１２１３は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の下位通信層抽象化インタフェース１３２３を介して受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文を、Ｊａｖａ ＶＭ１１１０及びカーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０を介してＵＤＰ／ＩＰ／Ｅｔｈｅｒｎｅｔパケットとしてネットワークに送信する。また、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００がＥＣＨＯＮＥＴ Ｌｉｔｅ電文をネットワークへ送信する機能を提供するため、送信部１２１３を下位通信層インタフェースサービスとしてＯＳＧｉフレームワーク１１２０に登録する。

プロトコル変換部１２２０は、ＥＣＨＯＮＥＴ Ｌｉｔｅとは異なるＬ５以上のプロトコルで受信した電文をＥＣＨＯＮＥＴ Ｌｉｔｅ電文に変換する。これにより、前記異なるプロトコルで接続された機器も同様にＥＣＨＯＮＥＴ Ｌｉｔｅバンドルの提供するサービスを使って操作することができるようになる。このとき、プロトコル変換部１２２０にて、前記異なるプロトコルで接続している機器の機器オブジェクトを生成し、管理する構成とし、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の指示とは独立して独自に前記機器と通信し、機器オブジェクトのプロパティ情報を更新してもよい。これにより、前記異なるプロトコルで接続された機器も同様にＥＣＨＯＮＥＴ Ｌｉｔｅバンドルの提供するサービスを使って操作することができるようになる。ＥＣＨＯＮＥＴ Ｌｉｔｅとは異なるＬ５以上のプロトコルとしては、ＡＶ（Ａｕｄｉｏ Ｖｉｓｕａｌ）機器などで広く搭載されているＵＰｎＰやガスメータなどのテレメータリングシステムで利用されているＵバス、ＳＥＰ（Ｓｍａｒｔ Ｅｎｅｒｇｙ Ｐｒｏｆｉｌｅ）２、ＥＣＨＯＮＥＴなどがある。

図５は、電文の構成例を示す図である。
ＥＣＨＯＮＥＴ Ｌｉｔｅ電文Ｄ１００は、ヘッダ部Ｄ１１０とデータ部Ｄ１２０から構成される。

ヘッダ部Ｄ１１０は、ＥＨＤ１Ｄ１１１、ＥＨＤ２Ｄ１１２、ＴＩＤＤ１１３から構成される。
データ部Ｄ１２０は、ＳＥＯＪＤ１２１、ＤＥＯＪＤ１２２、ＥＳＶＤ１２３、ＯＰＣＤ１２４、プロパティＤ１３０から構成される。
プロパティＤ１３０は、１つ以上のＥＰＣＤ１３１、ＰＤＣＤ１３２、ＥＤＴＤ１３３から構成される。

ＥＨＤ１Ｄ１１１は、ＥＣＨＯＮＥＴ Ｌｉｔｅヘッダ１であり、ＥＣＨＯＮＥＴのプロトコル種別を指定する。
ＥＨＤ２Ｄ１１２は、ＥＣＨＯＮＥＴ Ｌｉｔｅヘッダ２であり、データ部の電文形式を指定する。
ＴＩＤＤ１１３は、Ｔｒａｎｓａｃｔｉｏｎ ＩＤであり、ＥＣＨＯＮＥＴ Ｌｉｔｅ通信において、要求送信側が応答受信時に発行した要求と応答を紐付けするために用いる。

ＳＥＯＪＤ１２１は、ＥＣＨＯＮＥＴ Ｌｉｔｅにおいて送信元オブジェクトを示す識別情報である。
ＤＥＯＪＤ１２２は、ＥＣＨＯＮＥＴ Ｌｉｔｅにおいて宛先オブジェクトを示す識別情報である。
ＥＳＶＤ１２３は、ＥＰＣＤ１３１で指定されるプロパティに対する操作内容を指定する。
ＯＰＣＤ１２４は、処理対象プロパティカウンタであり、操作対象となるプロパティの数を指定する。

ＥＰＣＤ１３１は、ＥＣＨＯＮＥＴプロパティコードであり、サービス対象機能を指定する。サービス対象機能とは、電源状態、温度設定などの設定、読み出しなどである。
ＰＤＣＤ１３２は、プロパティデータカウンタであり、ＥＤＴＤ１３３のバイト数を指定する。
ＥＤＴＤ１３３は、ＥＣＨＯＮＥＴプロパティ値データであり、各プロパティの具体的設定内容を示す。

ＥＣＨＯＮＥＴ Ｌｉｔｅ電文を含むＥｔｈｅｒｎｅｔパケットは下位通信層ヘッダＤ２００と、ＥＣＨＯＮＥＴ Ｌｉｔｅ電文Ｄ１００から構成される。

下位通信層ヘッダＤ２００は、ＥｔｈｅｎｅｔヘッダＤ２１０と、ＩＰヘッダＤ２２０と、ＵＤＰヘッダＤ２３０から構成される。

ＥｔｈｅｒｎｅｔヘッダＤ２１０はＥｔｈｅｒｎｅｔにおける自機器の識別情報としてＳＲＣ ＭＡＣＤ２１１と宛先の識別情報としてＤＳＴ ＭＡＣＤ２１２を含む。

ＩＰヘッダＤ２２０はＩＰにおける自機器の識別情報としてＳＲＣ ＩＰＤ２２１と宛先の識別情報としてＤＳＴ ＩＰＤ２２２を含む。

ＵＤＰヘッダＤ２３０はＵＤＰにおける自機器の識別情報としてＳＲＣポートＤ２３１と宛先の識別情報としてＤＳＴポートＤ２３２を含む。

図６は、下位通信層抽象化インタフェース１３２３のパラメータ及び機器管理バンドル１４１０が提供する機器を操作するためのサービスの識別情報の構成例である。
下位通信層抽象化インタフェース１３２３のパラメータは、ＥＨＣＯＮＥＴ Ｌｉｔｅ電文Ｄ３０１と識別情報Ｄ３１０から構成される。

識別情報Ｄ３１０は、ＥＣＨＯＮＥＴ Ｌｉｔｅ電文を送受信する相手のＥＣＨＯＮＥＴ Ｌｉｔｅ機器を識別するための識別情報であり、ｓｕｂｎｅｔＩｄＤ３１１、ｉｄｅｎｔｉｆｉｅｒＤ３１２、ｉｓＣｏｎｓｔＤ３１３、ｉｓＭｕｌｔｉｃａｓｔＤ３１４、ｉｐＡｄｄｒｅｓｓＤ３１５、ｍａｃＡｄｄｒｅｓｓＤ３１６から構成される。

ｓｕｂｎｅｔＩｄＤ３１１は、下位通信層バンドル１２１０の識別情報である。これは、相手機器がどのサブネットに存在する機器かを示す識別情報でもある。ここで、サブネットとは、通信装置１００が複数のネットワークに接続されている場合に、それぞれのネットワークで到達可能な範囲を示す。

ｉｄｅｎｔｉｆｉｅｒＤ３１２は、下位通信層において、相手機器を識別する識別情報であり、ＩＰアドレス、ＭＡＣアドレスなどが利用できる。ｉｄｅｎｔｉｆｉｅｒＤ３１２を文字列とすれば下位通信層における識別情報の型に依存せずに識別情報を構成でき、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルやアプリケーションは識別情報の型を意識せずに利用できる。

ｉｓＣｏｎｓｔＤ３１３は、ｉｄｅｎｔｉｆｉｅｒＤ３１２が可変の情報か、不変の情報かを示すフラグである。例えば、ｉｄｅｎｔｉｆｉｅｒＤ３１２としてＩＰアドレスを使用する場合はｆａｌｓｅに、ＭＡＣアドレスを使用する場合はｔｒｕｅにする。これにより、アプリケーションはｉｄｅｎｔｉｆｉｅｒＤ３１２が可変なものかどうかを把握でき、ユーザにその旨を提示するなど、利用する識別情報に応じた機器管理が可能になる。

ｉｓＭｕｌｔｉｃａｓｔＤ３１４は、ネットワークに送信する際に当該サブネット内のすべての機器への同報とするかどうかを指定するマルチキャストフラグである。同報を指定する場合はｔｒｕｅに設定する。本フラグにより、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は下位通信層における同報用アドレス（例えば、ＥＣＨＯＮＥＴ ＬｉｔｅではＩＰｖ４では）を意識することなく、同報によるＥＣＨＯＮＥＴ Ｌｉｔｅ電文の送信ができる。

ｉｐＡｄｄｒｅｓｓＤ３１５は、相手機器のＩＰアドレスである。

ｍａｃＡｄｄｒｅｓｓＤ３１６は、相手機器のＭＡＣアドレスである。

ｓｅｃｕｒｅＤ３１７は、下位通信層のセキュリティ情報である。セキュリティ機能を利用する場合はｔｒｕｅを、使わない場合はｆａｌｓｅを設定する。ここではセキュリティ機能として、ＵＤＰ／ＩＰｖ４の場合には、Ｌａｙｅｒ４（ＵＤＰ）での暗号化及び改ざん防止機能としてＤＴＬＳ（Ｄａｔａｇｒａｍ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）、Ｌａｙｅｒ３（ＩＰ）での暗号化及び改ざん防止機能としてＩＰＳｅｃ（Ｓｅｃｕｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などがあるが、ここではどのセキュリティ機能を利用するかは下位通信バンドルが決定し、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルはセキュリティ機能の有効、無効のみを設定することで、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルが下位通信バンドルで対応可能なセキュリティ方式を知らなくても、セキュリティ機能を有効にすることができる。ｓｅｃｕｒｅＤ３１７に加え、セキュア方式も併せて受け渡しする情報に加えることで、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルが選択できるようにしてもよい。

以上のような抽象化したインタフェースとすることで、下位通信層に依存せずＥＣＨＯＮＥＴ Ｌｉｔｅ電文を送受信することができる。また、現在規定されていない下位通信層を追加する場合も、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルに変更を加えることなく、下位通信層バンドルの追加だけで新しい下位通信層を追加することができる。また、ＩＰアドレス、ＭＡＣアドレスではなく、文字列としてｉｄｅｎｔｉｆｉｅｒという文字列領域を識別情報とすることで、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルやアプリケーションは識別情報の型を意識せず下位通信層に依存しない形で、ネットワークで接続された機器を共通的に識別することができる。

ＥＣＨＯＮＥＴ Ｌｉｔｅ機器の識別情報Ｄ４００は、下位通信層の識別情報であるｓｕｂｎｅｔＩｄＤ３１１と、下位通信層における相手機器の識別情報であるｉｄｅｎｔｉｆｉｅｒＤ３１２と相手機器内におけるＥＣＨＯＮＥＴ Ｌｉｔｅオブジェクトの識別情報であるＳＥＯＪＤ１２１から構成する。機器を操作するためのサービスをＯＳＧｉフレームワーク１１２０に登録する際には、本識別情報をサービスプロパティ（ＯＳＧｉフレームワーク１１２０に登録するサービスに対して付与されるサービスに関する情報）として設定する。このように識別情報を構成することにより、機器制御バンドル１４２０のようなアプリケーションは、操作対象のＥＣＨＯＮＥＴ Ｌｉｔｅ機器を一意に特定することが可能になる。ここで、ｓｕｂｎｅｔＩｄＤ３１１と、ｉｄｅｎｔｉｆｉｅｒＤ３１２とＳＥＯＪＤ１２１は、別々のプロパティとしてサービスプロパティに登録してもよい。

図７は、ＯＳＧｉフレームワーク１１２０で管理するサービス情報の一構成例である。
サービス情報は下位通信層インタフェースサービス管理テーブルＴ７００、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービス管理テーブルＴ７５０、及びデバイスサービス管理テーブルＴ８００、ＥＣＨＯＮＥＴ Ｌｉｔｅイベントリスナーサービス管理テーブルＴ９００から構成される。

下位通信層インタフェースサービス管理テーブルＴ７００は、アドレスＴ７０１とサービスプロパティＴ７１０から構成される。サービスプロパティＴ７１０は、ｓｕｂｎｅｔＩｄＴ７１１から構成される。ｓｕｂｎｅｔＩｄＴ７１１は、下位通信層インタフェースサービスの識別情報であり、検索Ｋｅｙとなる文字列として”ＥＮＬＬｏｗＩｎｔｅｒｆａｃｅ．ｓｕｂｎｅｔＩＤ”のような文字列を用いる。本実施例では、下位通信層インタフェースサービスとして、レコードＴ７２１に”ｕｄｐｉｐ：ｂｒ０”というｓｕｂｎｅｔＩｄのサービスが登録されている。ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、下位通信層インタフェースサービスが複数存在する場合、”ＥＮＬＬｏｗＩｎｔｅｒｆａｃｅ．ｓｕｂｎｅｔＩＤ＝ｕｄｐｉｐ：ｂｒ０”のようなフィルタを作成してＯＳＧｉフレームワーク１１２０から目的のサービスを取得し、所望のネットワークにデータを送信することができる。

ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービス管理テーブルＴ７５０は、アドレスＴ７５１とサービスプロパティＴ７６０から構成される。サービスプロパティＴ７６０は、ｓｕｂｎｅｔＩｄＴ７６１から構成される。ｓｕｂｎｅｔＩｄＴ７６１は、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスの識別情報であり、検索Ｋｅｙとなる文字列として”ＥＮＬＦｒａｍｅＬｉｓｔｅｎｅｒ．ｓｕｂｎｅｔＩＤ”のような文字列を用いる。本実施例では、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスとして、レコードＴ７７１に”ｕｄｐｉｐ：ｂｒ０”というｓｕｂｎｅｔＩｄのサービスが登録されている。下位通信層バンドル１２１０は、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスが複数存在する場合、”ＥＮＬＦｒａｍｅＬｉｓｔｅｎｅｒ．ｓｕｂｎｅｔＩＤ＝ｕｄｐｉｐ：ｂｒ０”のようなフィルタを作成してＯＳＧｉフレームワーク１１２０からサービスを取得することができる。

ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス管理テーブルＴ８００は、アドレスＴ８０１とサービスプロパティＴ８１０から構成される。サービスプロパティＴ８１０は、ｏｂｊｅｃｔ．ｉｄＴ８１１、ＤＥＶＩＣＥ＿ＣＡＴＥＧＯＲＹＴ８１２、ｃｌａｓｓｃｏｄｅＴ８１３、メーカコードＴ８１４、識別番号Ｔ８１５、設置場所Ｔ８１６、自機器フラグＴ８１７、機器種別（ｔｙｐｅ）Ｔ８１８から構成される。

ｏｂｊｅｃｔ．ｉｄＴ８１１は、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの識別情報であり、受信した電文等の情報から生成したＥＣＨＯＮＥＴ Ｌｉｔｅ機器の識別情報Ｄ４００が設定される。

ＤＥＶＩＣＥ＿ＣＡＴＥＧＯＲＹＴ８１２は、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスがサポートする機器の種別を示す識別情報であり、設定値は”ＥＣＨＯＮＥＴ Ｌｉｔｅ”固定である。本情報をサービスプロパティとして設定することにより、ＯＳＧｉ標準サービスであるＤｅｖｉｃｅ Ａｃｃｅｓｓサービスに準拠した機器としてもＥＣＨＯＮＥＴ Ｌｉｔｅ機器を利用できる。Ｄｅｖｉｃｅ Ａｃｃｅｓｓに準拠したサービスが登録されると、Ｄｅｖｉｃｅ Ａｃｃｅｓｓサービスは対応する機器制御バンドルに対し、該当するデバイスが追加されたということを通知する。機器制御バンドルは、それが制御可能な機器であれば、ユーザや他のアプリケーション向けのインタフェースを提供する、といったことも可能になる。のＤＥＶＩＣＥ＿ＣＡＴＥＧＯＲＹＴ８１２は本実施例では固定値のため、以下の説明では設定内容の説明を省略する。

ｃｌａｓｓｃｏｄｅＴ８１３は、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器の機器種別を表す情報であり、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれるＳＥＯＪの上位２バイトを設定する。

メーカコードＴ８１４は、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器のメーカを表す情報であり、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれるメーカコードを設定する。

識別番号Ｔ８１５は、ＥＣＨＯＮＥＴ Ｌｉｔｅにおける機器の識別情報であり、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる識別情報を設定する。ただし、識別情報は、未設定の場合もあるが、受信した値をそのまま設定する。

設置場所（ｌｏｃａｔｉｏｎ）Ｔ８１６は、機器の接地場所であり、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる情報を設定する。ただし、設置場所は、未設定の場合もあるが、受信した値を基に設定を行う。

自機器フラグＴ８１７は、当該ＥＣＨＯＮＥＴ Ｌｉｔｅ機器が自機器か、ネットワークで接続された他機器かを識別するフラグであり、自機器の場合にはＹＥＳを、他機器の場合にはＮＯを設定する。

機器種別Ｔ８１８は、ＥＣＨＯＮＥＴ Ｌｉｔｅにおける機器の種別を示す情報であり、”一般機器”、”送信専用機器”、”不明”のいずれかを設定する。機器種別Ｔ８１８を登録することにより、機器制御バンドルは、当該機器が操作可能な機器か、通知のみの機器判断することができ、ユーザにその旨を通知することができる。

レコードＴ８２１はエアコン３００の操作用サービスをＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスとして登録する例である。エアコン３００は、無線ＬＡＮ上のＵＤＰ／ＩＰで接続しているため、ｏｂｊｅｃｔ．ｉｄＴ８１１には、ｓｕｂｎｅｔＩｄとして”ｕｄｐｉｐ：ｂｒ０”、ｉｄｅｎｔｉｆｅｒとしてエアコン３００のＭＡＣアドレス”００：００：００：００：００：０１”、ＳＥＯＪとして”０１３００１”を組み合わせて生成した識別情報”ｕｄｐｉｐ：ｂｒ０−００：００：００：００：００：０１−０１３００１”を設定する。
ＣｌａｓｓＣｏｄｅＴ８１３には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文のＳＥＯＪに含まれるクラスコードを設定する。
メーカコードＴ８１４には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれるメーカコード（ＥＰＣ＝０ｘ８Ａ）を設定する。
識別番号Ｔ８１５には、該当する機器を搭載したノードプロファイルオブジェクトから受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる識別番号（ＥＰＣ＝０ｘ８３）を設定する。
設置場所Ｔ８１６には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる設置場所（ＥＰＣ＝０ｘ８１）を設定する。ここでは、受信した電文に含まれる設置場所の値から、下位３ビットを０としてＥＣＨＯＮＥＴ Ｌｉｔｅで規定された場所を示す”０８”を設定する（下位３ビットは当該規定された場所内での識別情報のため）。これにより、設置場所をフィルタ条件としたＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス検索が容易になる。以下、別のレコードでも同様の手順で設置場所を設定する。
自機器フラグＴ８１７には、他機器であることを示すＮＯを設定する。
機器種別Ｔ８１８には、通常の応答可能なＥＣＨＯＮＥＴ Ｌｉｔｅノードであることを示す”一般”を設定する。

レコードＴ８２２は分電盤５５０に接続された計測装置３０の操作用サービスをＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスとして登録する例である。
計測装置３０は、有線ＬＡＮ上のＵＤＰ／ＩＰで接続しているため、ｏｂｊｅｃｔ．ｉｄＴ８１１には、ｓｕｂｎｅｔＩｄとして”ｕｄｐｉｐ：ｂｒ０”、ｉｄｅｎｔｉｆｅｒとして計測装置３０のＭＡＣアドレス”００：００：００：００：００：０３”、ＳＥＯＪとして”０２８７０１”を組み合わせて生成した識別情報”ｕｄｐｉｐ：ｂｒ０−００：００：００：００：００：０３−０２８７０１”を設定する。
ＣｌａｓｓＣｏｄｅＴ８１３には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文のＳＥＯＪに含まれるクラスコードを設定する。
メーカコードＴ８１４には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれるメーカコード（ＥＰＣ＝０ｘ８Ａ）を設定する。
識別番号Ｔ８１５、設置場所Ｔ８１６は、前記レコード８２１と同様の手順で設定する。
自機器フラグＴ８１７には、他機器であることを示すＮＯを設定する。
機器種別Ｔ８１８には、通常の送信専用のＥＣＨＯＮＥＴ Ｌｉｔｅノードであることを示す”送信専用”を設定する。ここで、送信専用のＥＣＨＯＮＥＴ Ｌｉｔｅノードとは、コントローラからの要求は受け付けず、自発的な通知のみを行う機器のことである。

レコードＴ８２３は通信装置１００自身の操作用サービスをＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスとして登録する例である。
通信装置１００は、有線ＬＡＮ上のＵＤＰ／ＩＰで接続しているものとし、ｏｂｊｅｃｔ．ｉｄＴ８１１には、ｓｕｂｎｅｔＩｄとして”ｕｄｐｉｐ：ｂｒ０”、ｉｄｅｎｔｉｆｅｒとして通信装置１００のＭＡＣアドレス”００：００：００：００：００：１０”、ＳＥＯＪとして”０５ｆｆ０１”を組み合わせて生成した識別情報”ｕｄｐｉｐ：ｂｒ０−００：００：００：００：００：１０−０５ｆｆ０１”を設定する。
ＣｌａｓｓＣｏｄｅＴ８１３には、”０５ｆｆ”を設定する。
メーカコードＴ８１４には、他機器への送信用に保持しているメーカコードを設定する。
識別番号Ｔ８１５には、他機器への送信用に保持している識別番号（ＥＰＣ＝０ｘ８３）を設定する。
設置場所Ｔ８１６には、他機器への送信用に保持している識別番号（ＥＰＣ＝０ｘ８１）を設定する。自機器フラグＴ８１７には、自機器であることを示すＹＥＳを設定する。
機器種別Ｔ８１８には、通常の応答可能なＥＣＨＯＮＥＴ Ｌｉｔｅノードであることを示す”一般”を設定する。

ここでは、ｉｄｅｎｔｉｆｅｒとしてＭＡＣアドレスを利用する例を示したが、ＩＰアドレスや他の識別情報を利用してもよい。

ここでは、各レコードの機器について、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されるノードプロファイルに関するレコードは省略しているが、同様に登録されているものとする。また、ここで例示されている機器以外の機器ついても、同様に登録される。

ＥＣＨＯＮＥＴ Ｌｉｔｅイベントリスナー管理テーブルＴ９００は、アドレスＴ９０１と、サービスプロパティＴ９１０から構成される。サービスプロパティＴ９１０は、フィルタＴ９１１から構成される。フィルタＴ９１１は、どのようなイベントを受信するかをフィルタリングする識別情報であり、検索Ｋｅｙとなる文字列として” （Ｏｂｊｅｃｔ．Ｉｄ＝Ｕｄｐｉｐ：Ｂｒ０−００：００：００：００：００：１０−０５Ｆｆ０１）”のような文字列を用いる。本実施例では、下位通信層インタフェースサービスとして、レコードＴ９１２に” （Ｏｂｊｅｃｔ．Ｉｄ＝Ｕｄｐｉｐ：Ｂｒ０−００：００：００：００：００：１０−０５Ｆｆ０１）”というフィルタのサービスが登録されている。ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、登録されたフィルタに合致するＥＣＨＯＮＥＴ ＬｉｔｅイベントリスナーをＯＳＧｉフレームワーク１１２０から取得し、イベントを通知することができる。また、アプリケーションは、フィルタ登録をすることで、所望の条件を満たすイベントのみ受信することができる。

図８は、初期化処理の一例を示すシーケンス図である。
システムの起動後、最初に、ＯＳＧｉフレームワーク１１２０は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００を登録し（Ｓ８０１）、下位通信層バンドル１２１０を登録する（Ｓ８０２）。

次に、ＯＳＧｉフレームワーク１１２０は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００に開始要求を行う（Ｓ８０３）。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は開始要求を受けると、下位通信サービス追跡準備を行う（Ｓ８０４）。下位通信サービス追跡準備とは、下位通信層インタフェースサービスがＯＳＧｉフレームワーク１１２０に登録されたことや削除されたことを追跡するために、サービス追跡用オブジェクトを生成し、サービス追跡用オブジェクトの追跡処理を開始することである。

次に、ＯＳＧｉフレームワーク１１２０は、下位通信バンドル１２１０に開始要求を行う（Ｓ８０５）。

下位通信層バンドル１２１０は開始要求を受けると、電文を送信する送信部１２１３のオブジェクトを生成し（Ｓ８０７）、生成した送信部オブジェクトを下位通信層インタフェースサービスとしてＯＳＧｉフレームワーク１１２０に登録する（Ｓ８０８）。

下位通信層インタフェースサービスが登録されるとＯＳＧｉフレームワーク１１２０は、予めＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００が生成したサービス追跡用オブジェクトに対して、下位通信層インタフェースサービスが登録されたことを通知する（Ｓ８０９）。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は下位通信層インタフェースサービスが登録されたことを検知すると、自機器がＥＣＨＯＮＥＴ Ｌｉｔｅデバイスとして動作するために必要な立ち上げ準備（Ｓ８１１）を行う。ここで、立ち上げ準備Ｓ８１１では、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の自機器操作・管理部１３１３が、下位通信層バンドル１２１０から電文を受信するために電文受信・解析部１３２２のオブジェクトをノードオブジェクトとして生成するとともに自機器がコントローラとして動作するためにコントローラオブジェクトを生成し、前記電文受信・解析部１３２２に登録する。

次に、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、前記電文受信・解析部１３２２のオブジェクトをＥＣＨＯＮＥＴ Ｌｉｔｅ電文受信・解析サービスとしてＯＳＧｉフレームワーク１１２０に登録し（Ｓ８１２）、前記登録通知Ｓ８０９で登録を通知された下位通信層インタフェースサービスを利用して下位通信層バンドル１２１０に対してＥＣＨＯＮＥＴ Ｌｉｔｅ電文の受信開始要求を行う（Ｓ８１３）。

その後で、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスの立ち上げ処理として、ＥＣＨＯＮＥＴ Ｌｉｔｅ規格に定められたインスタンスリスト通知の同報送信処理を行う（Ｓ８１４）。

以上の手順により、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００と下位通信層バンドル１２１０を分離して実装し、ＯＳＧｉフレームワーク１１２０に登録することにより、ＥＣＨＯＮＥＴ Ｌｉｔｅ処理部と下位通信層処理部の独立性を高めるとともに、１つのＥＣＨＯＮＥＴ Ｌｉｔｅ処理部と複数の下位通信層処理部の連携が容易になる。

図９は、電文受信処理の一例を示すシーケンス図である。
機器制御バンドル１４２０は予め、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文をイベントとして受信するために、所望のイベントを受信するためのフィルタを生成し、フィルタとともに通知先オブジェクトを生成してＥＣＨＯＮＥＴ ＬｉｔｅイベントリスナーサービスとしてＯＳＧｉフレームワーク１１２０に登録する（Ｓ９０１）。ＯＳＧｉサービス基盤はＪａｖａ（登録商標）ベースであるため、具体的に説明すると、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルの機器操作インタフェース１３１１でイベントリスナのインタフェースのみを規定する。機器制御バンドルは前記ＥＣＨＯＮＥＴ Ｌｉｔｅイベントリスナーインタフェースをインプリメント（実装）して実際の処理を記述することで、イベントリスナ実装クラスを作成する。そして、通知先オブジェクトとしてイベントリスナ実装クラスのオブジェクトを生成することがＳ９０１の具体的な内容である。

最初に、エアコン３００が電文を送信する（Ｓ９０２）と、通信装置１００のカーネル空間１５００の、無線ＬＡＮ Ｉ／Ｆ１０６、無線ＬＡＮ Ｄｒｉｖｅｒ１６００ｂ、ブリッジ１５２０、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０によってデータの受信及びＩＥＥＥ８０２．１１ヘッダ、ＩＰヘッダ、ＵＤＰヘッダの受信処理がされた後、下位通信バンドル１２１０に受信通知が行われる（Ｓ９０３）。

下位通信層バンドル１２１０はＵＤＰパケットを受信すると、アドレス取得部１２１２が送信元の識別情報を取得する（Ｓ９０４）。送信元の識別情報としては、カーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０が提供するソケットＡＰＩなどを利用して取得できるＩＰアドレスなどがある。他にも、ＩＰｖ４であれば取得したＩＰアドレスからカーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部で管理されるＡＲＰテーブルを参照してＭＡＣアドレスを取得してもよい。また、ＩＰｖ６の場合は、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０が管理する近隣キャッシュ（ｎｅｉｇｈｂｏｒ ｃｈａｃｈｅ）を参照してＭＡＣアドレスを取得してもよい。また、下位通信層とのやり取りがＴＣＰ（ＵＤＰ）／ＩＰ処理部が提供するソケットＡＰＩのような汎用的なインタフェースではなく、独自に規定されている場合は、独自に規定された取得方法を利用してネットワーク機器の識別情報を取得すればよい。

下位通信層バンドル１２１０は送信元の識別情報を取得した後、ＯＳＧｉフレームワーク１１２０に対してＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスの取得要求を行い（Ｓ９０５）、ＯＳＧｉフレームワーク１１２０はＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスが登録されている場合は、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスの取得応答として該当するサービスを返す（Ｓ９０６）。

下位通信層バンドル１２１０はＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスを取得すると、取得したサービスを利用して、前記受信した電文から下位通信層ヘッダを除いた電文、すなわちＥＣＨＯＮＥ Ｌｉｔｅ電文Ｄ３０１と、電文送信元のＥＣＨＯＮＥＴ Ｌｉｔｅ機器（ここではエアコン３００）の識別情報Ｄ３１０とを合わせ、電文受信通知としてＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００に通知する（Ｓ９０７）。

通知にあたっては、識別情報Ｄ３１０の、ｓｕｂｎｅｔＩｄＤ３１１は”ｕｄｐｉｐ：ｂｒ０”、ｉｄｅｎｔｉｆｉｅｒＤ３１２は”００：００：００：００：００：０１”、ｉｓＣｏｎｓｔＤ３１３はｔｒｕｅ、ｉｓＭｕｌｔｉｃａｓｔＤ３１４はｆａｌｓｅ、ｉｐＡｄｄｒｅｓｓＤ３１５は１９２．１６８．０．３、ｍａｃＡｄｄｒｅｓｓＤ３１６は００：００：００：００：００：０１に設定する。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は電文受信通知を受け取ると、電文解析処理Ｓ９０８を実施する。
電文解析処理Ｓ９０８では、ＥＣＨＯＮＥＴ Ｌｉｔｅ電文を解析し、不正な電文の破棄、不要な電文（電文に含まれるＤＥＯＪが通信装置１００に搭載されたＥＯＪではない電文）の破棄などを行とともに、必要に応じてＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの登録処理を行う。ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの登録処理については後述する。

応答の要否を判断して、必要な場合は応答用のＥＣＨＯＮＥＴ Ｌｉｔｅ電文を生成して下位通信層バンドルに送信要求を行う（Ｓ９０９）。

また、機器制御バンドルへの通知要否を判断して、通知が必要な場合はＯＳＧｉフレームワーク１１２０から登録された通知先のイベントリスナーサービスのうち、受信した電文と予め登録されたフィルタ条件が一致するサービスを取得し（Ｓ９１０及びＳ９１１）、取得したサービスを利用して機器制御バンドル１４２０に通知を行う（Ｓ９１２）。

以上の手順により、機器制御バンドル１４２０とＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００と下位通信層バンドル１２１０を分離して実装し、それぞれのイベントまたは電文受信用のサービスをＯＳＧｉフレームワーク１１２０に登録し、電文の送受信に際してＯＳＧｉフレームワーク１１２０を介して送信先を取得することにより、機能間の独立性を高めるとともに、１つのＥＣＨＯＮＥＴ Ｌｉｔｅ処理部と複数の機器制御アプリケーション（機器制御バンドル）及び下位通信層処理部（下位通信層バンドル）の連携が容易になる。

図１０は、電文送信処理の一例を示すシーケンス図である。
機器制御バンドル１４２０は最初に、ＯＳＧｉフレームワーク１１２０から操作を行う対象となる機器に相当するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを取得する（Ｓ１００１及びＳ１００２）。例えば、エアコン３００のサービスを取得する場合は、”ｏｂｊｅｃｔ．ｉｄ＝ｕｄｐｉｐ：ｂｒ０−００：００：００：００：００：０１−０１３００１”というフィルタを作成し、これに該当するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを取得すればよい。あるいは、設置場所が「居間、リビング」の機器を検索するという意味を持つ”ｌｏｃａｔｉｏｎ＝０８”というフィルタを作成し、これに該当するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを取得すればよい。あるいは、設置場所が「居間、リビング」の「エアコン」を操作したい場合は、”（ｌｏｃａｔｉｏｎ＝０８）＆（ｃｌａｓｓｃｏｄｅ＝０１３０）”というフィルタを利用すればよい。

機器制御バンドル１４２０は、取得したサービスのＡＰＩ（機器操作インタフェース）を利用して、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００に操作要求を行う（Ｓ１００３）。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は操作要求を受信すると、ＥＣＨＯＮＥＴ Ｌｉｔｅ電文を生成する電文生成処理（Ｓ１００４）を行う。

電文生成後、ＯＳＧｉフレームワーク１１２０から捜査対象機器が接続されたサブネットの下位通信層インタフェースサービスを取得する（Ｓ１００５、Ｓ１００６）。

次に、取得したサービスを利用して下位通信層バンドル１２１０に送信サイズ取得要求を行い、下位通信バンドル１２１０がネットワークに送信できるＥＣＨＯＮＥＴ Ｌｉｔｅ電文の最大サイズ取得する（Ｓ１００７、Ｓ１００８）。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、構成した電文が前記取得した最大送信サイズ以下の場合はそのまま、電文送信要求Ｓ１０１０に進み、構成した電文が前記取得した最大送信サイズより大きい場合は電文の分割を行って再度ＥＣＨＯＮＥＴ Ｌｉｔｅ電文を再構成する（Ｓ１００９）。

取得したサービスを利用して下位通信層バンドル１２１０に電文送信要求を行い、生成したＥＣＨＯＮＥＴ Ｌｉｔｅ電文及び他機器操作・管理部が管理している操作対象機器の識別情報Ｄ３１０を渡す（Ｓ１０１０）。下位通信層インタフェースサービス取得にあたっては、予めＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスで管理されている識別情報に登録されたｓｕｂｎｅｔＩｄを利用して検索用のフィルタを生成する。例えば、エアコン３００が接続されたサブネットの場合、”ＥＮＬＬｏｗＩｎｔｅｒｆａｃｅ．ｓｕｂｎｅｔＩＤ＝ｕｄｐｉｐ：ｂｒ０”というフィルタを利用すればよい。

下位通信層バンドル１２１０は、電文送信要求を受信すると、受信した別情報から捜査対象機器のＩＰアドレスを取得してソケットを生成するなどの電文送信準備を行う（Ｓ１０１１）。

その後、カーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０に送信要求を行う（Ｓ１０１２）。

カーネル空間１５００のＴＣＰ（ＵＤＰ）／ＩＰ処理部１５１０は、送信要求に従って、無線ＬＡＮ Ｄｒｉｖｅｒ１６００ｂに送信指示を行い、無線ＬＡＮ Ｉ／Ｆ１０６を介してネットワークに接続されたエアコン３００に電文を送信する（Ｓ１０１３）。

以上の手順により、機器制御バンドル１４２０とＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００と下位通信層バンドル１２１０を分離して実装し、それぞれのイベントまたは電文受信用のサービスをＯＳＧｉフレームワーク１１２０に登録し、電文の送受信に際してＯＳＧｉフレームワーク１１２０を介して送信先を取得することにより、機能間の独立性を高めるとともに、１つのＥＣＨＯＮＥＴ Ｌｉｔｅ処理部と複数の機器制御アプリケーション（機器制御バンドル）及び下位通信層処理部（下位通信層バンドル）の連携が容易になる。

以上の手順において、当該下位通信層バンドルを利用して通信可能なネットワーク上のエアコンに同報通信を実施したい場合は、前記識別情報Ｄ３１０に含まれるｉｓＭｕｌｔｉｃａｓｔ（マルチキャストフラグ）Ｄ３１４をｔｒｕｅにしておけばよい。これにより、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は下位通信層における同報用アドレスを意識することなく、同報によるＥＣＨＯＮＥＴ Ｌｉｔｅ電文の送信ができる。

また、下位通信バンドルがサポートするセキュリティ機能を有効にして通信を行いたい場合には、前記識別情報Ｄ３１７に含まれるｓｅｃｕｒｅＤ３１７に“ＤＴＬＳ”または“ＩＰＳｅｃ”を設定すればよい。

図１１は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の他機器操作・管理部１３１２におけるＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス登録処理の一例を示すフローチャートである。
ＥＣＨＯＮＥＴ Ｌｉｔｅ電文（イベント）を受信する（Ｓ１１０２）と、受信した電文の送信元を示す識別情報を含むフィルタを生成しＯＳＧｉフレームワーク１１２０に登録されたＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを検索し、当該機器が登録済みかどうかを確認する（Ｓ１１０３）。

Ｓ１１０３において検索の結果、該当するサービスが取得できずに未登録の機器であると判断した場合（Ｓ１１０３のＮＯ）には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文が応答であるか通知であるかを確認する（Ｓ１１１０）。確認には、受信した電文に含まれるＥＳＶを用いればよい。

イベントが応答でない場合（Ｓ１１１０のＮＯ）には、機器種別を”不明”とするとともに、受信した識別情報からＥＣＨＯＮＥＴ Ｌｉｔｅ機器の識別情報を構成する（Ｓ１１１１）。

イベントが応答である場合（Ｓ１１１０のＹＥＳ）には、機器種別を”一般”とするとともに、受信した識別情報からＥＣＨＯＮＥＴ Ｌｉｔｅ機器の識別情報を構成する（Ｓ１１１２）。ここで識別情報とは、前記図６のＤ４００の識別情報のことである。

次に、前記Ｓ１１１１またはＳ１１１２の識別情報及び機器種別をサービスプロパティとして、ＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスをＯＳＧｉフレームワーク１１２０に登録する（Ｓ１１１３）。また、ここでは、前記ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス管理テーブルＴ８００のサービスプロパティＴ８１０で管理するほかの情報も併せてサービスプロパティとして登録してもよい。ここでは必ずしも全部の情報を登録する必要はなく、受信した電文に含まれる情報または電文から生成できる情報のみを登録すればよい。

次に、電文送信元機器に対して、同報ではなく個別送信でＥＣＨＯＮＥＴ Ｌｉｔｅにおける必須プロパティの送信要求を行い（Ｓ１１１４）、応答の有無を確認する（Ｓ１１１５）。

必須プロパティ取得要求に対して応答がある場合（Ｓ１１１５のＹＥＳ）は、機器種別を”一般”に更新し、応答に含まれる必須プロパティを基に、前記ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスのサービスプロパティを更新する（Ｓ１１１６）。

必須プロパティ取得要求に対して応答がない場合（Ｓ１１１５のＮＯ）は、以降何もしない。

ここでは、ＯＳＧｉフレームワーク１１２０へのＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス登録を必須プロパティの取得要求を行う前に登録したが、この手順を必須プロパティ取得要求の応答受信後に行ってもよい（Ｓ１１１６と同時）。これにより、アプリケーションは前記ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス取得時に確実に必須プロパティの情報を取得できる。また、前記ＡＲＰテーブルを利用してMACアドレスを取得する場合に必ず取得できる。

また、このとき、プロパティの情報を取得できない送信専用機器は登録せず、登録されたいＥＣＨＯＮＥＴ Ｌｉｔｅイベントリスナーに対してイベント送信のみを行う構成としてもよい。これにより、アプリケーションは機器種別を確認する前に、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスとして登録されているかどうかだけで、当該機器が送信専用機器ではないことを判断できる。

また、ここでは必須プロパティの取得要求を行う例を示したが、必須プロパティではなくＧｅｔプロパティマップを取得し、取得可能なプロパティ情報すべてを取得してもよい。これにより、アプリケーションは、必須プロパティ以外のプロパティ情報も前記ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス取得時に取得することができる。

Ｓ１１０３において検索の結果、該当するサービスが取得できて登録済みの機器であると判断した場合（Ｓ１１０３のＹＥＳ）には、次に登録されたサービスプロパティの機器種別が”不明”かどうかを確認する（Ｓ１１２０）。

機器種別が”不明”ではない場合（Ｓ１１２０のＮＯ）には、以降何もしない。

機器種別が”不明”の場合（Ｓ１１２０のＹＥＳ）の場合は、次に受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文が応答であるか通知であるかを確認する（Ｓ１１２１）。

イベントが応答である場合（Ｓ１１１０のＹＥＳ）には、機器種別を”一般”として前記ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスのサービスプロパティを更新し、次のステップに進む。

イベントが応答でない場合（Ｓ１１１０のＮＯ）は、受信した電文に含まれる情報で必須プロパティに更新があるかどうかを確認し（Ｓ１１２３）、更新がある場合（Ｓ１１２３のＹＥＳ）は、更新のある必須プロパティに関するサービスプロパティを更新し（Ｓ１１２４）、処理を終了する。

必須プロパティに更新がない場合（Ｓ１１２３のＮＯ）には、以降何もしない。

以上の手順により受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文を基に、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器の操作用インタフェースを機器の識別情報とＥＣＨＯＮＥＴ Ｌｉｔｅの必須プロパティを含むサービスプロパティとともにＯＳＧｉサービスとしてフレームワークに登録することで、機器制御バンドル１４２０などのアプリケーションは、容易に機器の接続を検出したり、接続されている機器操作するサービスを所望の条件で検索したりすることができる。

図１２は、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００の他機器操作・管理部１３１２におけるＥＣＨＯＮＥＴ Ｌｉｔｅ機器切断監視処理の一例を示すフローチャートである。
他機器操作・管理部１３１２は、最初にＯＳＧｉフレームワーク１１２０に登録された機器のノードオブジェクトに該当するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスのリストを取得し（Ｓ１２０２）、対象機器の有無を確認する（Ｓ１２０３）。

処理機器がない場合（Ｓ１２０３のＮＯ）、処理を終了する。

処理機器がある場合（Ｓ１２０３のＹＥＳ）、当該サービスのサービスプロパティのうち、機器種別が”送信専用”以外であることを確認する（Ｓ１２０４）。

機器種別が”送信専用”の場合（Ｓ１２０４のＮＯ）は、以降の処理を中断し、リストの次のＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスに対する処理を行うため、Ｓ１２０３に戻る。

機器種別が”送信専用”以外の場合（Ｓ１２０４のＹＥＳ）は、下位通信層バンドルを介して、機器の動作状態プロパティの取得要求を行い（Ｓ１２０５）、応答有無を確認する（Ｓ１２０６）。

動作状態プロパティの取得要求に対する応答があった場合（Ｓ１２０６のＹＥＳ）は、当該機器は現在もネットワークに接続されているものと判断して削除処理を中断し、リストの次のＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスに対する処理を行うため、Ｓ１２０３に戻る。

動作状態プロパティの取得要求に対する応答がない場合（Ｓ１２０６のＮＯ）は、当該機器がネットワークから離脱したと判断し、処理対象のＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスをＯＳＧｉフレームワーク１１２０から削除する（Ｓ１２０７）。

次に、識別情報のうち、同じｓｕｂｎｅｔＩｄとｉｄｅｎｔｉｆｅｒを持つＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの取得を行い（Ｓ１２０８）、サービスの登録有無を確認する（Ｓ１２０９）。

サービスの登録がある場合（Ｓ１２０９のＹＥＳ）は、当該サービスに対応する機器も同様にネットワークから離脱したと判断し、ＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスをＯＳＧｉフレームワーク１１２０から削除する（Ｓ１２１０）。

サービスの登録が無い場合（Ｓ１２０９のＮＯ）は、以降の処理を中断し、リストの次のＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスに対する処理を行うため、Ｓ１２０３に戻る。

以上の処理を一定周期で繰り返して、ＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスとしてＯＳＧｉフレームワーク１１２０に登録しているネットワーク上の機器がネットワークから離脱したかどうかを確認し、必要に応じてサービスを削除することにより機器制御バンドル１４２０などのアプリケーションは、容易にＥＣＨＯＮＥＴ Ｌｉｔｅ機器のネットワークから離脱を知ることができる。

また、切断監視のために動作状態プロパティの取得要求を送信するにあたって、予め登録してある機器種別を基に送信専用機器かどうかを判断することで、不要な要求送信を防ぎ、効率的に監視を行うことができる。ここでは、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス取得後に、サービスプロパティの機器種別を用いて送信専用機器かどうかを判断したが、Ｓ１２０２のＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスのリストを取得処理において、例えば”（ｏｂｊｅｃｔ．ｐｉｄ＝＊−０ｅｆ０＊）＆！（ｔｙｐｅ＝送信専用））”のような検索フィルタを用いて予め送信専用機器以外のリストを取得してもよい。

図１３は、表示端末の画面の一例である。
ここで、画面の表示は表示端末２００のブラウザで通信装置１００やＪａｖａ Ｓｃｒｉｐｔ（登録商標）で生成されたＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を表示する形式とする。即ち、表示端末２００側では特別な処理は行わず、通信装置１００で生成された画面情報の内容を表示するのみとする。通信装置１００において、画面情報の生成は、機器管理バンドル１４１０が行う。

Ｇ１３００は、通信装置１００がネットワーク上に新しいＥＣＨＯＮＥＴ Ｌｉｔｅ機器を検出した際に、表示端末２００を介してユーザに提示する画面の一例である。具体的には、機器管理バンドル１４１０がＯＳＧｉフレームワーク１１２０にＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスが登録されたことを検出すると、それを表示端末で表示するＨＴＭＬに反映させる。本画面は、検出した機器に関する情報をユーザが追加または更新するために情報設定を行うかどうかを問い合わせるために表示する。
ここで、「はい」が選択された場合は、Ｇ１３２０の機器情報の登録画面を表示する。
また、「いいえ」が選択された場合は、何もせずに終了する。

以上のような表示を行うことで、ユーザは通信装置１００がネットワークに接続された機器を検出したことを知ることができる。

Ｇ１３１０は、通信装置１００がネットワーク上に新しいＥＣＨＯＮＥＴ Ｌｉｔｅ機器を検出し、その機器種別が”不明”であった場合に表示端末２００を介してユーザに提示する画面の一例である。具体的には、機器管理バンドル１４１０がＯＳＧｉフレームワーク１１２０にＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスが登録されたことを検出すると、サービスプロパティの機器種別を確認し、それが”不明”である場合には、その旨を「送信専用機器の可能性がある」として表示端末で表示するＨＴＭＬに反映させる。

以上のような表示を行うことで、ユーザは通信装置１００が新たに検出した機器が、応答しない送信専用機器の可能性があることを知ることができるとともに、ユーザの「はい」「いいえ」の情報をサービスプロパティに反映させることで、当該機器の機器種別を確定し、効率的に管理することができる。

Ｇ１３２０は、機器情報の登録画面であり、機器の名称を示す「名前」とその入力フィールドＧ１３２１、機器の識別情報とその入力フィールドＧ１３２２、機器の設置場所とその入力フィールドＧ１３２３、機器が送信専用機器であるかどうかを示す「送信専用」とその入力フィールドＧ１３２４から構成される。本画面で入力された情報は、機器管理バンドル１４１０が、ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスと対応付けて管理する。例えば、「設置場所」が別途ＥＣＨＯＮＥＴ Ｌｉｔｅ電文で受信した内容と異なる場合には、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルを介して変更要求を行い、ユーザの設定内容を機器に反映させる。また、「送信専用」の入力フィールドＧ１３２４については、サービスプロパティの機器種別を確認し、機器種別が”送信専用”の場合には予めＹＥＳを入力しておく。その他の情報についても同様である。

以上のような表示を行うことで、ユーザは通信装置１００が新たに検出した機器に関する情報を更新することができるとともに、予め電文等から取得してサービスプロパティに設定されている情報を入力フィールドに設定しておくことで、ユーザ入力を効率化することができる。

Ｇ１３３０は、機器情報一覧の表示画面であり、名前Ｇ１３３１、識別情報Ｇ１３３２、設置場所Ｇ１３３３、送信専用フラグＧ１３３４及び各機器のレコードから構成される。機器管理バンドル１４１０は、本表示を行うためにＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスが登録、削除される毎にその状況を更新する独自のテーブルを管理する。これによって、一度ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスとして登録されたが、ＯＳＧｉフレームワーク１１２０から削除された機器は、網掛けして表示するなどして、現在は接続されていないことがわかるようにできる。

以上のようにサービスの登録状態を表示に反映することで、ユーザは機器の接続状態を把握することができる。

実施例１では、有線ＬＡＮ及び無線ＬＡＮに接続されたＥＣＨＯＮＥＴ Ｌｉｔｅ機器を検出・管理する方法について示した。本実施例では、前述に加えてＵＳＢデバイス１０経由でＩＥＥＥ８０２．１５．４無線ネットワーク上にＺｉｇｂｅｅＩＰプロトコルでデータを送受信する宅内ネットワーク５３に接続されたＥＣＨＯＮＥＴ Ｌｉｔｅ機器も管理する場合について説明する。

図１４は、ＵＳＢデバイス１０のハードウェア及びソフトウェア構成例である。
ＵＳＢデバイス１０は、制御部１１、記憶部１２、ＵＳＢ Ｉ／Ｆ１３、無線Ｉ／Ｆ１４から構成される。

制御部１１は、ソフトウェアの実行を行い通信装置１００内の他の構成要素を制御し、ＵＳＢデバイス１０を機能させる。

記憶部１２は、揮発性メモリおよび不揮発性メモリで構成する。不揮発性メモリにはＯＳやアプリケーションなどのＵＳＢデバイス１０を動作させるためのソフトウェアや固定データを格納する。揮発性メモリにはソフトウェアの動作に必要なデータなどを一時的に格納する。

ＵＳＢ Ｉ／Ｆ１３はＵＳＢＩ／Ｆを備える別の機器（ＵＳＢ機器）を接続するインタフェースである。制御部１１の指示によって、接続されたＵＳＢ機器との間でデータの送受信を行う。

無線Ｉ／Ｆ１４は、制御部１１の指示によって宅内ネットワーク５３に接続された機器との間でデータの送受信を行う。

ＵＳＢデバイス１０のソフトウェアは、アプリケーションインタフェース１５、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１６、６ＬｏＷＰＡＮ処理部１７、８０２．１５．４無線処理部１８から構成される。

アプリケーションインタフェース１５は、ＵＳＢ Ｉ／Ｆ１３を操作してＵＳＢ Ｉ／Ｆ１３で接続された機器へのデータ送受信を行う。すなわち、ＵＳＢ Ｉ／Ｆ１３から受信したデータをＴＣＰ（ＵＤＰ）／ＩＰ処理部１６に送信し、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１６から受信したデータをＵＳＢ Ｉ／Ｆ１３に送信する。ＵＳＢ Ｉ／Ｆ１３を介しての通信装置１００とのデータにあたっては、独自の送受信コマンドを利用してもよいし、ＵＤＰ／ＩＰのような標準化された通信規約を利用してもよい。

ＴＣＰ（ＵＤＰ）／ＩＰ処理部１６は、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰのパケットを解析・構成する機能を有し、６ＬｏＷＰＡＮ処理部１７を介してネットワーク上の機器と前記パケットの送受信を行う。すなわち、アプリケーションインタフェース１５から受信したデータに基づいてＴＣＰ／ＩＰまたはＵＤＰ／ＩＰパケットを構成し、６ＬｏＷＰＡＮ処理部１７に送信し、６ＬｏＷＰＡＮ処理部１７から受信したデータからＴＣＰ／ＩＰまたはＵＤＰ／ＩＰヘッダを取り除いたデータをアプリケーションインタフェース１５に送信する。

６ＬｏＷＰＡＮ処理部１７は、６ＬｏＷＰＡＮで規定されたフォーマットの電文を構成・解析する機能を有し、８０２．１５．４無線処理部１８を介してネットワーク上の機器と前記電文の送受信を行う。すなわち、ＴＣＰ（ＵＤＰ）／ＩＰ処理部１６から受信したパケットに基づいてＴＣＰ（ＵＤＰ）／ＩＰヘッダの圧縮、データの分割を行って６ＬｏＷＰＡＮで規定された電文を構成し、８０２．１５．４無線処理部１８に送信し、８０２．１５．４無線処理部１８から受信したデータに基づいて、ＴＣＰ（ＵＤＰ）／ＩＰヘッダの復元、データの結合を行ってＴＣＰ（ＵＤＰ）／ＩＰ処理部１６に送信する。

このようなＵＳＢデバイス１０を用いることによって、通信装置１００は、８０２．１５．４無線上の６ＬｏＷＰＡＮで構成されたネットワークに接続するためのハードウェアを備えていなくても、宅内ネットワーク５３に接続された機器に接続できるようになる。

図１５は、宅内ネットワーク５３上を流れる電文の構成例である。
簡単のため、フッタ等は省略している。
電文Ｄ１５００は、下位通信層ヘッダＤ４００と、ＥＣＨＯＮＥＴ ＬｉｔｅフレームＤ１００ａから構成される。下位通信層ヘッダＤ４００は、ＩＥＥＥ８０２．１５．４ヘッダＤ４１０及び６ＬｏＷＰＡＮヘッダ（圧縮されたＵＤＰ／ＩＰヘッダ）Ｄ４２０から構成される。

ＩＥＥＥ８０２．１５．４ヘッダＤ４１０はＩＥＥＥ８０２．１５．４無線における自機器の識別情報としてＳＲＣ ＭＡＣＤ４１１と宛先の識別情報としてＤＳＴ ＭＡＣＤ４１２を含む。

６ＬｏＷＰＡＮヘッダＤ４２０は、ＩＰヘッダＤ２２０及びＵＤＰヘッダＤ２３０を所定の手続きにより圧縮することで構成される。

図１６は、本実施例における通信装置１００のソフトウェア構成例を示すブロック図である。
通信装置１００のソフトウェア１０００ａは、前記ソフトウェア１０００に加えて、電力メータ用の機器制御バンドル１４３０と、下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０と、ＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００を有する。

電力メータ用の機器制御バンドル１４３０は、ユーザまたは他のアプリケーションの指示に従い、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００を介して、ネットワーク５３に接続された電力メータの制御または状態取得を行う。

下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０は、Ｊａｖａ ＶＭ及びカーネル空間１５００のＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００を介して、ＵＳＢ Ｉ／Ｆ１０４で接続されたＵＳＢデバイス１００を介して、ＩＥＥＥ８０２．１５．４無線で構成された宅内ネットワーク５３に接続された機器との間で、データ送受信を行う。すなわち、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００から受信したデータに基づいてＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００にデータを送信し、ＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００から受信したデータに基づいて、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００にデータを送信する。ＥＣＨＯＮＥＴ Ｌｉｔｅバンドルとのデータ送受信にあたっては、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００が規定する通信手段（通信規約）によって通信を行う。また、ＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００とのデータ送受信にあたっては、ＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００により規定された通信手段（通信規約）によって通信を行う。

ＵＳＢ−ＺｉｇｂｅｅＩＰ Ｄｒｉｖｅｒ１７００は、下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０からの指示に従い、ＵＳＢ Ｉ／Ｆ１０４を操作してＵＳＢデバイス１０へのデータ送受信を行う。ＵＳＢデバイス１０とのデータ送受信にあたっては、ＵＳＢデバイス１０により規定された通信手段（通信規約）によって通信を行う。また、ネットワークにデータを創出するためのサービスとして、下位通信層インタフェースサービスをＯＳＧｉフレームワーク１１２０に登録し、他のバンドルに提供する。

以上のような構成とすることで、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００を変更することなく、複数の宅内ネットワークに接続された機器との通信を行うことができる。また、下位通信層のデバイスに依存する部分を独立したＯＳＧｉバンドルとして構成することで、通信装置１００を再起動などしてすべてのネットワークとの接続を切断する必要なく、他のネットワーク接続に影響を与えることなく、当該バンドルに関するネットワークのみを通信装置１００から動的に着脱することができる。

図１７は、新規ネットワーク追加処理の一例を示すシーケンス図である。
新規ネットワーク追加とは、例えば通信装置１００のＵＳＢ Ｉ／Ｆ１０４に宅内ネットワーク５３に接続する機能を持つＵＳＢデバイス１０を挿入することによって、通信装置１００が新しく宅内ネットワーク５３の機器と通信できるようになることをいう。

最初に機器管理バンドル１４２０は、ＵＳＢ Ｉ／Ｆ１０４にＵＳＢデバイス１０が接続されたことを検出する（Ｓ１７０１）。デバイス検出には、ｈｏｔｐｌｕｇやｕｄｅｖ、Ｄ−Ｂｕｓ（Ｄｅｓｋｔｏｐ−Ｂｕｓ）を利用すればよい。

機器管理バンドル１４２０は、ＵＳＢデバイス１０が接続されたことを検出すると、通信装置１００の記憶部１０２に、前記ＵＳＢデバイス１０を介して接続可能なネットワーク用の下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０が保持されているかどうかを確認する（Ｓ１７０２）。

確認の結果、保持されている場合（Ｓ１７０２のＹＥＳ）は、前記下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０をＯＳＧｉフレームワーク１１２０に登録し（Ｓ１７０７）、ＯＳＧｉフレームワーク１１２０を介して（Ｓ１７０７）下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０に開始要求を行う（Ｓ１７０８）。

確認の結果、保持されていない場合（Ｓ１７０２のＮＯ）は、機器管理バンドル１４２０は、サーバ４に下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０の取得要求を行う（Ｓ１７０３）。

サーバは、前記取得要求を受信すると、取得応答を送信し（Ｓ１７０４）、機器管理バンドル１４２０は、サーバからの応答を確認し、下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０含まれるかどうかを確認する（Ｓ１７０５）。

サーバからの応答に下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０が含まれない場合（Ｓ１７０５のＮＯ）は、処理を終了する。

サーバからの応答に下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０が含まれない場合（Ｓ１７０５のＹＥＳ）は、前記下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０をＯＳＧｉフレームワーク１１２０に登録し（Ｓ１７０７）、ＯＳＧｉフレームワーク１１２０を介して（Ｓ１７０７）下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０に開始要求を行う（Ｓ１７０８）。

下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０が開始すると、前記図８の初期化処理Ｓ８００における、Ｓ８０７からＳ８１４と同様の初期化処理を行う（Ｓ１７０９）。

以上のような手順とすることで、新しく通信デバイスを追加した際に、通信装置１００を再起動などしてすべてのネットワークとの接続を切断する必要なく、他のネットワーク接続に影響を与えることなく、当該バンドルに関するネットワークのみを通信装置１００から動的に着脱することができる。

図１８は、通信ネットワーク離脱処理の一例を示すシーケンス図である。
通信ネットワーク離脱とは、例えば通信装置１００から接続されたＵＳＢデバイス１０を外すことで、宅内ネットワーク５３から離脱することをいう。

最初に機器管理バンドル１４２０は、ＵＳＢ Ｉ／Ｆ１０４にＵＳＢデバイス１０がはずされたことを検出する（Ｓ１８０１）。デバイス検出には、ｈｏｔｐｌｕｇやｕｄｅｖ、Ｄ−Ｂｕｓ（Ｄｅｓｋｔｏｐ−Ｂｕｓ）を利用すればよい。

機器管理バンドル１４２０は、ＵＳＢデバイス１０が接続されたことを検出すると、位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０がＯＳＧｉフレームワーク１１２０に登録され、開始済みかどうかを確認する（Ｓ１８０２）。

確認の結果、開始済みの位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０がない場合（Ｓ１８０２のＮＯ）は、何もしない。

確認の結果、開始済みの下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０がある場合（Ｓ１８０２のＹＥＳ）は、下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０に停止要求を行い、停止し（Ｓ１８０３）、下位通信バンドル（ＵＤＰ／ＺｉｇｂｅｅＩＰ）１２２０はＯＳＧｉフレームワーク１１２０に登録済みの下位通信層インタフェースサービスの削除要求を行う（Ｓ１８０４）。

ＯＳＧＩフレームワーク１１２０は、要求に従って下位通信層インタフェースサービスを削除し（Ｓ１８０５）、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００に下位通信層インタフェースサービスが削除されたことを通知する（Ｓ１８０６）。

ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル１３００は、削除通知を受信すると、宅内ネットワーク５３に接続された機器に対応するＥＣＨＯＮＥＴ ＬｉｔｅデバイスサービスをＯＳＧｉフレームワーク１１２０から削除する（Ｓ１８０７）。

ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの削除（Ｓ１８０７）に当たっては、削除された下位通信層インタフェースサービスの識別情報であるｓｕｂｎｅｔＩｄを利用し、ｓｕｂｎｅｔＩｄが一致するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを削除する。

なお、ここでは、下位通信インタフェースサービスを削除してから、関連するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを削除したが、順番を逆にしてもよい。

以上のような手順でネットワークからの切断とともに、関連するＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスを削除することで、例えば機器制御バンドルから、通信ができない機器に対する要求を受け付けないようにし、処理の効率化を図れる。また、ＯＳＧｉフレームワーク１１２０を利用してＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービスの状態を追跡することで、機器制御バンドルは当該ネットワークに接続されている機器が操作できない状態になったことを知ることができる。

図１９は、本実施例においてＯＳＧｉフレームワーク１１２０で管理するサービス情報の一構成例である。
下位通信層インタフェースサービス管理テーブルＴ７００には、下位通信層インタフェースサービスとして、ｓｕｂｎｅｔＩｄが”ｕｄｐｉｐ：ｂｒ０”というレコードＴ７２１に加え、ｓｕｂｎｅｔＩｄが”ｚｉｇｂｅｅＩＰ：ｕｓｂ”というサービスに対応するレコードＴ７２２が登録されている。

ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービス管理テーブルＴ７１０には、ＥＣＨＯＮＥＴ Ｌｉｔｅ受信・解析サービスとして、ｓｕｂｎｅｔＩｄが”ｕｄｐｉｐ：ｂｒ０”というレコードＴ７７１に加え、ｓｕｂｎｅｔＩｄが”ｚｉｇｂｅｅＩＰ：ｕｓｂ”というサービスに対応するレコードＴ７７２が登録されている。

ＥＣＨＯＮＥＴ Ｌｉｔｅデバイスサービス管理テーブルＴ８００には、宅内ネットワーク５３に接続された電力メータ４００に相当するレコードＴ８２４が登録されている。

電力メータ４００は、ＩＥＥＥ８０２．１５．４無線上のＺｉｇｂｅｅＩＰで接続しているため、ｏｂｊｅｃｔ．ｉｄＴ８１１には、ｓｕｂｎｅｔＩｄとして” ｚｉｇｂｅｅＩＰ：ｕｓｂ”、ｉｄｅｎｔｉｆｅｒとして電力メータ４００のＭＡＣアドレス”００：００：００：００：００：０２”、ＳＥＯＪとして”０２８８０１”を組み合わせて生成した識別情報”ｚｉｇｂｅｅＩＰ：ｕｓｂ−００：００：００：００：００：０２−００２８８０１”を設定する。

ＣｌａｓｓＣｏｄｅＴ８１３には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文のＳＥＯＪに含まれるクラスコードを設定する。

メーカコードＴ８１４には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれるメーカコード（ＥＰＣ＝０ｘ８Ａ）を設定する。

識別番号Ｔ８１５には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる識別番号（ＥＰＣ＝０ｘ８３）を設定する。

設置場所Ｔ８１６には、受信したＥＣＨＯＮＥＴ Ｌｉｔｅ電文に含まれる設置場所（ＥＰＣ＝０ｘ８１）から、下位３ビットをマスクしたもの（６０）を設定する。

自機器フラグＴ８１７には、他機器であることを示すＮＯを設定する。

機器種別Ｔ８１８には、通常のＥＣＨＯＮＥＴ Ｌｉｔｅノードであることを示す”一般”を設定する。

上記以外のテーブル構成は、図８と同様である。また、ここでは、各レコードの機器について、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されるノードプロファイルに関するレコードは省略しているが、同様に登録されているものとする。また、ここで例示されている機器以外の機器ついても、同様に登録される。

ＥＣＨＯＮＥＴ Ｌｉｔｅイベントリスナー管理テーブルＴ９００については、図７と同様のため、記載を省略する。

以上のように、ＯＳＧｉフレームワーク１１２０がサービスを管理することで、ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル、下位通信層バンドル、機器制御バンドルの独立性を高めることができる。また、機器制御バンドルは下位通信層の構成に関わらず、同じ手順で異なるネットワークに接続する機器を操作することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることや各処理における処理の順番を入れ替えることも可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ ユーザ宅
２、５ アクセスネットワーク
３ インターネット
４ サーバ
６ ユーティリティネットワーク
７ ＭＤＭＳ
１０ ＵＳＢアダプタ
２０ エアコンアダプタ
３０ 計測装置
４０ ガスメータアダプタ
１００ 通信装置
２００ 表示端末
２５０ デジタルテレビ
３００、３５０ エアコン
４００ 電力メータ
４５０ ガスメータ
５００ センサ
５５０ 分電盤
６００ 蓄電池
６５０ 照明
７００ 太陽光発電システム
１０１ 制御部
１０２ 記憶部
１０３ 時刻管理部
１０４ ＵＳＢ Ｉ／Ｆ
１０５ 有線ＬＡＮ Ｉ／Ｆ
１０６ 無線ＬＡＮ Ｉ／Ｆ
１０７ ＷＡＮ Ｉ／Ｆ
１１００ ユーザ空間
１１１０ Ｊａｖａ ＶＭ
１１２０ ＯＳＧｉフレームワーク
１２１０ 下位通信層バンドル
１３００ ＥＣＨＯＮＥＴ Ｌｉｔｅバンドル
１４１０ 機器管理バンドル
１４２０ 機器制御バンドル
１５００ カーネル空間
１５１０ ＴＣＰ（ＵＤＰ）／ＩＰ処理部
１５２０ ブリッジ
１６００ ネットワークドライバ
１３１０ ＥＣＨＯＮＥＴ Ｌｉｔｅ機器管理部
１３１１ 機器操作インタフェース
１３１２ 他機器操作・管理部
１３１３ 自機器操作・管理部
１３２０ ＥＣＨＯＮＥＴ Ｌｉｔｅ通信処理部
１３２１ 電文生成・送信部
１３２２ 電文受信・解析部
１３２３ 下位通信層抽象化インタフェース
１２１１ 受信部
１２１２ アドレス取得部
１２１３ 送信部

Claims (14)

1. サービス管理手段と、第１の送受信手段と、第２の送受信手段と、を有する通信装置であって、
   前記サービス管理手段は、
   操作対象機器への制御内容を含むプロパティ情報と、前記第１の送受信手段を識別する第１の識別情報と、第１の通信規約において前記操作対象機器を識別する第２の識別情報と、第２の通信規約において前記操作対象機器を識別する第３の識別情報と、を前記第２の送受信手段に出力する制御用サービスと、
   前記第２の送受信手段から出力された前記第１の識別情報と、前記第２の識別情報と、第２の電文と、を前記第１の送受信手段に送信する送信用サービスと、を提供し、
   前記第２の送受信手段は、前記プロパティ情報と前記第３の識別情報とに基づいて、前記第２の電文を作成し、前記制御用サービスから受信した前記第１の識別情報により識別される前記第１の送受信手段に、前記サービス管理手段から提供される前記送信用サービスを用いて、作成した前記第２の電文と、前記第１識別情報と前記第２識別情報と、を含む送信要求を受信し、
   前記第１の送受信手段は、前記第２の電文を含む第１の電文を作成し、前記第２の識別情報で識別される前記操作対象機器に対して、前記第１の電文を送信する、
   ことを特徴とする通信装置。
2. 請求項１に記載の通信装置であって
   前記サービス管理手段は、前記第２の電文と、前記第１の識別情報と、前記第２の識別情報と、を前記第２の送受信手段に受信させる受信用サービスを提供し、
   前記第１の送受信手段は、ネットワークで接続された機器から前記第１の電文を受信した場合に、前記サービス管理手段から提供される前記受信用サービスを用いて、前記第１の識別情報と、前記第１の電文に含まれる前記第２の電文と前記第２の識別情報と、を含む受信通知を第２の送受信手段に出力し、
   前記第２の送受信手段は、受信した前記第２の電文に基づいて、前記制御用サービスを生成し、前記第１の識別情報と前記第２の識別情報と前記第３の識別情報を組み合わせた第４の識別情報をサービスの識別情報として、サービス管理手段に登録する
   ことを特徴とする通信装置。
3. 請求項２に記載の通信装置であって
   前記通信インタフェースや前記ネットワークに接続された機器の追加・削除を監視する管理手段
   を備え、
   前記管理手段は、新しく通信インタフェースが有効になったら、前記通信インタフェースに対応する第１の送受信手段を前記フレームワークに登録する
   ことを特徴とする通信装置。
4. 請求項３に記載の通信装置であって
   前記管理手段は、新しく通信インタフェースが有効になった場合に、通信装置内に当該通信インタフェースに対応する第１の送受信手段が存在する場合は、前記通信装置内の第１の送受信手段を前記フレームワークに登録し、通信装置内に当該通信インタフェースに対応する第１の送受信手段が存在しない場合は、サーバから前記第１の送受信手段を取得して、前記フレームワークに登録する
   ことを特徴とする通信装置
5. 請求項２に記載の通信装置であって、
   前記第２の送受信手段は、前記第２の電文を受信した際に、前記第１の送受信手段を介してネットワークで接続された機器に要求を送信し、前記要求に対する応答がある場合は、前記機器を非送信専用機器と判断し、前記生成した制御用サービスに、非送信専用機器器であることがわかる識別情報を付加する
   ことを特徴とする通信装置。
6. 請求項５に記載の通信装置であって、
   ユーザに機器を制御するための画面などのユーザインタフェース用の情報を生成する機器制御手段を備え、
   前記機器制御手段は、前記フレームワークに新しい制御用サービスが登録されたことを検出し、前記制御用サービスの付加情報から対応する機器が非送信専用機器かどうかを判断し、非送信専用機器である場合には新しい機器が登録されたことを画面に表示するための情報を生成し、非送信専用機器でない場合には、新しい機器が登録され、前記新しい機器が送信専用機器である可能性があることを画面に表示するための情報を生成する
   ことを特徴とする通信装置。
7. 請求項５に記載の通信装置であって
   ユーザに機器を制御するための画面などのユーザインタフェース用の情報を生成する機器制御手段を備え、
   ユーザからの指示によりネットワークに接続された機器の情報を変更する画面情報を生成する場合に、前記機器が送信専用機器であるかどうかを入力するフィールドを含む画面情報を生成する
   ことを特徴とする通信装置。
8. サービス管理手段と、第１の送受信手段と、第２の送受信手段と、を有する通信方法であって、
   前記サービス管理手段は、
   操作対象機器への制御内容を含むプロパティ情報と、第１の送受信手段を識別する第１の識別情報と、第１の通信規約において操作対象機器を識別する第２の識別情報と、第２の通信規約において操作対象機器を識別する第３の識別情報と、を第２の送受信手段に出力する制御用サービスと、
   前記第２の送受信手段から出力された第１の識別情報と、第２の識別情報と、第２の電文と、を第１の送受信手段に出力する送信用サービスと、を提供し、
   前記第２の送受信手段は、前記プロパティ情報と前記第３の識別情報とに基づいて、第２の電文を作成し、前記制御用サービスから受信した前記第１の識別情報に基づき、前記サービス管理手段から前記送信用サービスを取得し、前記送信用サービスを使って、前記作成した第２の電文と、第１識別情報と第２識別情報と、を含む送信要求を第１の送受信手段に出力し、
   前記第１の送受信手段は、前記第２の電文を含む第１の電文を作成し、前記第２の識別情報で特定される操作対象機器に対して、前記第１の電文を送信する、
   ことを特徴とする通信方法。
9. 請求項１に記載の通信方法であって
   前記サービス管理手段は、
   第２の電文と、前記第１の識別情報と、前記第２の識別情報と、を前記第２の送受信手段に出力する受信用サービスを提供し、
   前記第１の送受信手段は、ネットワークで接続された機器から第１の電文を受信すると、前記サービス管理手段から前記受信用サービスを取得し、前記受信用サービスを使って、前記第１の識別情報と、前記第１の電文から取り出した前記第２の電文と前記第２の識別情報と、を含む受信通知を第２の送受信手段に出力し、
   前記第２の送受信手段は、受信した前記第２の電文に基づいて、前記制御用サービスを生成し、前記第１の識別情報と前記第２の識別情報と前記第３の識別情報を組み合わせた第４の識別情報をサービスの識別情報として、サービス管理手段に登録する
   ことを特徴とする通信方法。
10. 請求項８に記載の通信方法であって
    前記通信インタフェースや前記ネットワークに接続された機器の追加・削除を監視する管理手段
    を備え、
    前記管理手段は、新しく通信インタフェースが有効になったら、前記通信インタフェースに対応する第１の送受信手段を前記フレームワークに登録する
    ことを特徴とする通信方法。
11. 請求項１０に記載の通信方法であって
    前記管理手段は、新しく通信インタフェースが有効になった場合に、通信装置内に当該通信インタフェースに対応する第１の送受信手段が存在する場合は、前記通信装置内の第１の送受信手段を前記フレームワークに登録し、通信装置内に当該通信インタフェースに対応する第１の送受信手段が存在しない場合は、サーバから前記第１の送受信手段を取得して、前記フレームワークに登録する
    ことを特徴とする通信方法
12. 請求項８に記載の通信方法であって、
    前記第２の送受信手段は、前記第２の電文を受信した際に、前記第１の送受信手段を介してネットワークで接続された機器に要求を送信し、前記要求に対する応答がある場合は、前記機器を非送信専用機器と判断し、前記生成した制御用サービスに、非送信専用機器器であることがわかる識別情報を付加する
    ことを特徴とする通信方法。
13. 請求項１２に記載の通信方法であって、
    ユーザに機器を制御するための画面などのユーザインタフェース用の情報を生成する機器制御手段を備え、
    前記機器制御手段は、前記フレームワークに新しい制御用サービスが登録されたことを検出し、前記制御用サービスの付加情報から対応する機器が非送信専用機器かどうかを判断し、非送信専用機器である場合には新しい機器が登録されたことを画面に表示するための情報を生成し、非送信専用機器でない場合には、新しい機器が登録され、前記新しい機器が送信専用機器である可能性があることを画面に表示するための情報を生成する
    ことを特徴とする通信方法。
14. 請求項１２に記載の通信方法であって
    ユーザに機器を制御するための画面などのユーザインタフェース用の情報を生成する機器制御手段を備え、
    ユーザからの指示によりネットワークに接続された機器の情報を変更する画面情報を生成する場合に、前記機器が送信専用機器であるかどうかを入力するフィールドを含む画面情報を生成する
    ことを特徴とする通信方法。

Images