(57)【特許請求の範囲】
【請求項１】
ネットワークの同一サブネット上にある目的ノードを探索する制御装置であって、
前記制御装置は、
サブネット上のパケットを送受信する通信部と、
前記通信部を介して探索要求パケットを送信し、探索応答パケットを受信することによって前記目的ノードを探索する探索部と、
サブネット上にある起動ノードのノード情報を管理するノード情報管理部と、を備え、
前記通信部を介してＡＲＰ（Address Resolution Protocol）パケットを受信すると、受信したＡＲＰパケットの送信元ＭＡＣ（Media Access Control）アドレスを含むノード情報を前記ノード情報管理部に登録又は更新し、
前記通信部を介してＩＰ（Internet Protocol）パケットを受信すると、受信したＩＰパケットの送信元ＭＡＣアドレスが前記ノード情報管理部に登録されていない場合は、受信したＩＰパケットの送信元ＩＰアドレスを探索ＩＰアドレスとするＡＲＰリクエストを送信し、
前記探索部により探索要求パケットを送信する際に、前記ノード情報管理部にあるノード情報のＩＰアドレスを宛先にしてユニキャストで送信する、制御装置。
【請求項２】
前記探索部は、探索要求パケットを送信する際に、マルチキャストで送信するとともに、前記ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する、請求項１に記載の制御装置。
【請求項３】
前記探索部は、探索要求パケットを送信する際に、ブロードキャストで送信するとともに、前記ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する、請求項１に記載の制御装置。
【請求項４】
前記ノード情報管理部は、
ノード情報が所定の時間更新されなければ、当該ノードが離脱されているかどうかを確認するパケットを、前記通信部を介して送信し、
前記確認するパケットに呼応する応答の受信がなければノード情報を削除する、請求項１から３のいずれか１項に記載の制御装置。
【請求項５】
前記制御装置は、
マルチキャスト・グループに参加しているノードの存在確認のために、前記通信部を介
して、マルチキャスト・ノード問合せパケットを送信する、マルチキャスト・ノード問合
せ送信部、をさらに備える、請求項１から４のいずれか１項に記載の制御装置。
【請求項６】
ネットワークの同一サブネット上にある複数のノードと、前記複数のノードから目的ノードを探索する制御装置とを備えるシステムであって、
前記制御装置は、
サブネット上のパケットを送受信する通信部と、
前記通信部を介して探索要求パケットを送信し、探索応答パケットを受信することによって前記目的ノードを探索する探索部と、
サブネット上にある起動ノードのノード情報を管理するノード情報管理部と、を備え、
前記通信部を介してＡＲＰパケットを受信すると、受信したＡＲＰパケットの送信元ＭＡＣアドレスを含むノード情報を前記ノード情報管理部に登録又は更新し、
前記通信部を介してＩＰパケットを受信すると、受信したＩＰパケットの送信元ＭＡＣアドレスが前記ノード情報管理部に登録されていない場合は、受信したＩＰパケットの送信元ＩＰアドレスを探索ＩＰアドレスとするＡＲＰリクエストを送信し、
前記探索部により探索要求パケットを送信する際に、前記ノード情報管理部にあるノード情報のＩＰアドレスを宛先にしてユニキャストで送信する、システム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、制御装置およびシステムに関し、ネットワーク上の目的機器を探索するための制御装置およびシステムに関する。
【背景技術】
【０００２】
従来、探索機器が、ネットワーク上の目的機器（以下、被探索機器ともいう）を探索するには、一般的に探索のためのパケットを用いる。具体的には、探索機器は、予め定められたマルチキャスト・アドレスを宛先アドレスに、予め定められたポートを宛先ポートにした、特定の形式の「探索要求パケット」を送信し、それに対する「探索応答パケット」を受信することによって、目的機器を見つける。あるいは、マルチキャスト・アドレスの代わりに、ブロードキャスト・アドレスが用いられることもある。
【０００３】
しかし、ネットワーク環境によっては、マルチキャスト・パケットやブロードキャスト・パケットが転送されない場合がある。マルチキャスト・パケットを転送するのはルーターの役割であり、ルーターに依存する。
つまり、ネットワーク内のルーターがマルチキャスト転送機能を備えていない場合には、マルチキャスト・パケットは転送されない。また、ルーターがマルチキャスト転送機能を備えていたとしても、しばしばマルチキャスト・パケットが転送されないことがある。その例としては、ルーターのマルチキャストSnooping機能がオンに設定されていると、マルチキャスト・パケットが転送されないことがある。マルチキャストSnooping機能自体は、マルチキャスト・グループに参加しているノードにだけマルチキャスト・パケットを転送するという機能であり、適切に実装されていれば問題はない。
【０００４】
しかし、あるルーターでは、どちらも同じマルチキャスト・グループに参加している機器Ａと機器Ｂがある状況で、機器Ａから送出されるマルチキャスト・パケットは機器Ｂには届くが、機器Ｂから送出されるマルチキャスト・パケットは機器Ａには届かない、といったことが実際に起こっている。
【０００５】
また、ルーターと機器とを起動する順序に依存して、マルチキャスト・パケットが届かなくなる場合がある。マルチキャストSnooping機能をオフにすると、そのような症状は起こらないので、マルチキャストSnooping機能による影響と考えられる。
【０００６】
また、ルーターだけではなく、ネットワークの経路途中にスイッチングハブ等があれば、それらのマルチキャストSnooping機能の影響によって、マルチキャスト・パケットが転送されないこともある。
【０００７】
また、ルーターの一部には、（ＩＰレベルの）ブロードキャスト・パケットを転送しないものがある。例えば、あるルーターでは、ＩＰ（Internet Protocol）ヘッダに含まれるDon't fragmentフラグが1を示すブロードキャスト・パケットを、有線ＬＡＮ（Local Area Network）側から無線ＬＡＮ側へ転送しない、ということが実際に起こっている。
【０００８】
また、無線ＬＡＮ環境では、マルチキャスト・パケットまたはブロードキャスト・パケットはしばしばドロップされる。これらのパケットは、ＭＡＣ（Media Access Control）レベルにおいて再送されないため、通信の信頼性が低いからである。
【０００９】
このようなネットワーク環境においては、被探索機器に「探索要求パケット」が届かないので、被探索機器は「探索応答パケット」を返信することもない。従って、探索機器は被探索機器を見つけることができない。
【００１０】
そこで、マルチキャストまたはブロードキャストによる送信に加えて、宛先アドレスを特定のＩＰアドレスにした「探索要求パケット」をユニキャストで送信する方法が考えられる。この方法では、どのＩＰアドレスに対して「探索要求パケット」を送信するかが問題となる。
【００１１】
例えば、特許文献１(特開２０１１−１９３２２３号公報）は、『自己のＩＰアドレスとサブネットマスクに基づいて特定のサブネット内に存在し得る各端末装置の対象ＩＰアドレスを生成するリクエスト生成部と、リクエスト生成部で生成した対象ＩＰアドレスのＭＡＣアドレスを問うＡＲＰ(Address Resolution Protocol)リクエストを特定のサブネットに送信するリクエスト送信部と、特定のサブネットから送信されてくるＡＲＰリプライを受信し、ＡＲＰリプライに格納されたソースＩＰアドレスならびにソースＭＡＣアドレスを確認する学習部を備えたネットワーク接続装置』を開示する。
【００１２】
また、特許文献２（特開２００４−２２８８７８号公報）は、『ローカルエリアネットワークを構成する各ノードと定期的に所定のパケット通信を行うことにより各ノードの状態を監視し、起動しているノードが存在しないと判断した場合には、広域ネットワークとのコネクションを終了する、ネットワーク接続装置』、『所定のパケット通信とは、各ノードへのＡＲＰ要求パケットの送信と、当該ＡＲＰ要求パケットに対応したＡＲＰ応答パケットの受信とである』、および『所定のパケット通信は、各ノードへのＩＣＭＰ  Ｎｅｉｇｈｂｏｒ  Ｓｏｌｉｃｉｔａｔｉｏｎパケットの送信と、当該ＩＣＭＰ  Ｎｅｉｇｈｂｏｒ  Ｓｏｌｉｃｉｔａｔｉｏｎパケットに対応したＩＣＭＰ  Ｎｅｉｇｈｂｏｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔパケットの受信とである』ことを開示している。特許文献２に開示された技術によれば、所定のパケット通信により、起動しているノードが存在するか否かが確認される。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１１−１９３２２３号公報
【特許文献２】特開２００４−２２８８７８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかし、特許文献１は、ネットワークに存在するかどうかも分からない端末のＩＰアドレスを対象にして、ＡＲＰリクエストを送信することは、無駄なネットワークトラフィックを発生させることになる。望ましくは、無駄なネットワークトラフィックを発生させずに（受動的に）起動しているノードを検出することが望ましい。
【００１５】
また、サブネットマスクが２５５．２５５．２５５．０である場合（ホスト部が８ビット）は、生成される対象ＩＰアドレスは２５６個＝２１６個程度であるが、サブネットマスクが２５５．２５５．０．０のような場合（ホスト部が１６ビット）は、生成される対象ＩＰアドレスは６５５３６個＝２３２個程度となり、大量のＩＰアドレスが生成されてしまう。これら大量のＩＰアドレスに対してＡＲＰリクエストを送信することは無駄なネットワークトラフィックを発生させるだけでなく、時間がかかり過ぎて効率的とは言えない。
【００１６】
また、特許文献２は、上記に述べた起動しているノードを確認するために、段落００３０で『次に探索器２０２は、定期的に、先に取得したサブネットに属する全てのＩＰアドレスに対してＡＲＰ要求のパケットをブロードキャストで送信する。』と記載する。したがって、特許文献２においても、特許文献１と同様に、サブネットマスクの設定によっては、ＡＲＰ要求のパケットが大量に送信されて無駄なトラフィックが発生することになる。
【００１７】
本開示は、かかる実情に鑑み考え出されたものであり、ある局面における目的は、無駄なトラフィックを発生させずにサブネット上にある起動ノードの存在を受動的に検出し、目的ノードを確実に探索する制御装置およびシステムを提供することである。
【課題を解決するための手段】
【００１８】
一実施の形態に従うと、ネットワークの同一サブネット上にある目的ノードを探索する制御装置は、サブネット上のパケットを送受信する通信部と、通信部を介して探索要求パケットを送信し、探索応答パケットを受信することによって目的ノードを探索する探索部と、通信部を介してパケットを受信する毎に、サブネット上にある起動ノードの存在を受動的に検出して、ノード情報として管理するノード情報管理部と、を備える。探索部は、探索要求パケットを送信する際に、ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する。
【００１９】
好ましくは、探索部は、探索要求パケットを送信する際に、マルチキャストで送信するとともに、ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する。
【００２０】
好ましくは、探索部は、探索要求パケットを送信する際に、ブロードキャストで送信するとともに、ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する。
【００２１】
好ましくは、ノード情報管理部は、ノード情報が所定の時間更新されなければ、当該ノードが離脱されているかどうかを確認するパケットを、通信部を介して送信し、確認するパケットに呼応する応答の受信がなければノード情報を削除する。
【００２２】
好ましくは、制御装置は、マルチキャスト・グループに参加しているノードの存在確認のために、通信部を介して、マルチキャスト・ノード問合せパケットを送信する、マルチキャスト・ノード問合せ送信部、をさらに備える。
【００２３】
他の実施の形態に従うと、ネットワークの同一サブネット上にある複数のノードと、複数のノードから目的ノードを探索する制御装置とを備えるシステムが提供される。制御装置は、サブネット上のパケットを送受信する通信部と、通信部を介して探索要求パケットを送信し、探索応答パケットを受信することによって目的ノードを探索する探索部と、通信部を介してパケットを受信する毎に、サブネット上にある起動ノードの存在を受動的に検出して、ノード情報として管理するノード情報管理部と、を含む。
【００２４】
探索部は、探索要求パケットを送信する際に、ノード情報管理部にあるノード情報のアドレスを宛先にしてユニキャストで送信する。
【発明の効果】
【００２５】
本開示のある局面によれば、無駄なトラフィックを発生させずに、サブネット上にある起動ノードの存在を受動的に検出し、起動ノードに関する情報をノード情報としてノード情報管理部に管理し、ノード情報管理部にあるノード情報を宛先アドレスとして探索要求パケットを送信することによって、目的ノードを確実に探索することができる。
【図面の簡単な説明】
【００２６】
【図１】実施の形態１に係る通信ネットワーク１の概略構成を説明するための図である。
【図２】図１のＨＥＭＳ（Home Energy Management System）コントローラ１００のブロック図である。
【図３】図１のＨＥＭＳコントローラ１００のソフトウェア構成を説明するための図である。
【図４】実施の形態１に係るノードリスト１２３の構成の一例を示す図である。
【図５】実施の形態１に係るノード情報の構成の一例を示す図である。
【図６】ＡＲＰパケットの構成を示す図である。
【図７】任意のＩＰパケットの構成を示す図である。
【図８】実施の形態１に係るＨＥＭＳコントローラ１００の機能的構成を説明するための機能ブロック図である。
【図９】実施の形態１に係るノード情報の削除処理を示すフローチャートである。
【図１０】実施の形態１に係るＡＲＰリクエストまたはＡＲＰリプライを受信した時のノードリストの情報更新の処理を示すフローチャートである。
【図１１】実施の形態１に係るＩＰパケットを受信した時のノードリスト１２３の情報更新の処理を示すフローチャートである。
【図１２】本実施の形態１に係る目的ノードを探索する処理を示すフローチャートである。
【図１３】本実施の形態２に係る目的ノードを探索する処理を示すフローチャートである。
【図１４】実施の形態３に係るＩＧＭＰｖ２(Internet Group Management Protocol version 2） General Queryの送信処理を示すフローチャートである。
【発明を実施するための形態】
【００２７】
以下、図面を参照しつつ、本開示の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
【００２８】
［実施の形態１］
＜通信ネットワーク１の概略構成＞
図１は、実施の形態１に係る通信ネットワーク１の概略構成を説明するための図である。図１を参照して、通信ネットワーク１は、無線ＬＡＮルーター３０２およびサブネット１０を備える。無線ＬＡＮルーター３０２は、インターネット等の外部のネットワーク９００と接続する。
【００２９】
サブネット１０は、ＨＥＭＳコントローラ１００、複数のノード２０１，２０２，２０３…、およびスイッチングハブ３００を備える。「ノード」とは、ＩＰアドレスを持つ通信機器（ＩＰ対応機器）である。一般的に、ノードは、パーソナルコンピュータ、プリンタ、ＮＡＳ（Network Attached Storage、ネットワークストレージともいう）、タブレット端末、ＡＶ（Audio Visual）機器、および白物家電等を含む。図１では、無線ＬＡＮルーター３０２は、有線ＬＡＮ８０３を介してＨＥＭＳコントローラ１００、ノード２０２、およびスイッチングハブ３００に接続され、また、無線ＬＡＮ８０２を介してノード２０３に接続される。ノード２０１は、スイッチングハブ３００に接続され、さらに、スイッチングハブ３００を経由して無線ＬＡＮルーター３０２に接続される。
【００３０】
無線ＬＡＮルーター３０２に接続される複数のノード２０１，２０２，２０３，…のうちいくつかが、ＥＣＨＯＮＥＴ Ｌｉｔｅ機器に相当する「ＥＣＨＯＮＥＴ Ｌｉｔｅノード」である。本実施の形態では、例えば、ノード２０２と２０３がＥＣＨＯＮＥＴ Ｌｉｔｅノードである。ノード２０１は電力モニタである。
【００３１】
ＨＥＭＳコントローラ１００は、通信ネットワーク１において制御装置として機能する。具体的には、ＨＥＭＳコントローラ１００は、複数のノード２０１，２０２，２０３，…と通信することにより、複数のノード２０１，２０２，２０３，…を制御する。
【００３２】
本実施の形態では、新規ノード２０９がサブネット１０に参加し、またサブネット１０に参加しているノード（以下、「既存ノード」とも称する）がサブネット１０から離脱することがある。なお、新規ノード２０９がネットワークに参加した場合には、新規ノード２０９は既存ノードとして扱われる。
【００３３】
図１を参照して、無線ＬＡＮルーター３０２、ＨＥＭＳコントローラ１００、および各ノードに関連して示される括弧内の数字（たとえば、192.168.11.1）は、当該機器またはノードのＩＰアドレスを表している。無線ＬＡＮルーター３０２は、ＤＨＣＰ（Dynamic Host Configuration Protocol）機能を有する。無線ＬＡＮルーター３０２は、ＤＨＣＰ機能により、ＨＥＭＳコントローラ１００、および複数のノード２０１，２０２，２０３，…に対して、図示されるようなＩＰアドレスを自動的に付与する。付与されたＩＰアドレスは、各ノードが有する記憶部に格納されるとともに、ＨＥＭＳコントローラ１００では、後述する記憶部１６０に格納される。また、ＨＥＭＳコントローラ１００および各ノードは、固有の番号を示すＭＡＣアドレスが予め設定（記憶）されたＬＡＮカード等のネットワークアダプタ（図示せず）を有する。ここでは、ＭＡＣアドレスは、ノードまたはＨＥＭＳコントローラ１００に「固有の識別情報」の一実施例であり、また、ＩＰアドレスはノードまたはＨＥＭＳコントローラ１００に割当てられる「可変の識別情報」の一実施例である。
【００３４】
図１を参照して、無線ＬＡＮルーター３０２のサブネットマスクが255.255.255.0に設定されていたとする。無線ＬＡＮルーター３０２によって付与されたＩＰアドレスから分かるように、ＩＰアドレスのうちのネットワークアドレスとして使用される部分（たとえば“192.168.11.5”であれば“192.168.11”の部分）が共通であるノードの集合が１つのサブネット（分割されたネットワーク）を構成している。
【００３５】
なお、本実施の形態では、ＨＥＭＳコントローラ１００は、サブネット１０に存在する目的ノードを探索する主体である探索機器の一例であり、ノード２０１，２０２，２０３，…それぞれは、探索の対象となり得る被探索機器の一例である。探索機器による探索処理については、後述する。
【００３６】
＜ＨＥＭＳコントローラの構成＞
図２は、図１のＨＥＭＳコントローラ１００のブロック図である。図２を参照して、ＨＥＭＳコントローラ１００は、ＣＰＵ（Central Processing Unit）１１０１を備える。ＨＥＭＳコントローラ１００は、さらに、ＣＰＵ１１０１に接続されたＲＯＭ（Read Only Memory）１１０７、発光素子１１０３、高速通信インターフェイス１１０４、電源１１０５、時間（時刻）を測定するタイマ１１０６、ＲＡＭ（Random Access Memory）１１０２、プッシュボタン１１０８、スライドスイッチ１１０９、およびリセットスイッチ（図示しない）を備える。
【００３７】
ＣＰＵ１１０１は、ＨＥＭＳコントローラ１００の全体的な動作を制御する。ＣＰＵ１１０１は、プッシュボタン１１０８およびスライドスイッチ１１０９からの入力を受け付ける。また、ＣＰＵ１１０１は、発光素子１１０３に発光指示を出力する。
【００３８】
ＲＯＭ１１０７はプログラムや変更不可なデータ等が格納される不揮発性のメモリデバイスである。ＲＡＭ１１０２はプログラムがロードされ、プログラムのワークエリアやファイルシステム、変更可能なデータ等が格納される揮発性のメモリデバイスである。高速通信インターフェイス１１０４は、無線ＬＡＮルーター３０２との間でＥｔｈｅｒｎｅｔ（登録商標）を用いた通信を行なうインターフェイスである。電源１１０５は、ＨＥＭＳコントローラ１００の各部に電力を供給する。
【００３９】
＜ＨＥＭＳコントローラ１００のソフトウェア構成＞
図３は、図１のＨＥＭＳコントローラ１００のソフトウェア構成を説明するための図である。図３を参照して、ＨＥＭＳコントローラ１００は、デバイス側アプリケーション１１０、ホスト側アプリケーション１２０、および上位層１３０を少なくとも備える。デバイス側アプリケーション１１０はＵＤＰ（User Datagram Protocol）ソケット１１１を含む。ＵＤＰソケット１１１は送信用と受信用に使用される。また、ホスト側アプリケーション１２０は、送信用のＵＤＰソケット１２１、および送受信用のＲＡＷソケット１２２を含む。また、ホスト側アプリケーション１２０は、ＲＡＭ１１０２にノードリスト１２３（後述する）を記憶する。
【００４０】
デバイス側アプリケーション１１０は、ＨＥＭＳコントローラ１００自身が、ＥＣＨＯＮＥＴ Ｌｉｔｅにおけるコントローラとして振る舞うためのアプリケーションである。デバイス側アプリケーション１１０は、ノード２０１，２０２，２０３，…からの要求を受信して、当該要求に対して応答または通知を送信する。デバイス側アプリケーション１１０は、本発明にとって必要ではない。
【００４１】
ホスト側アプリケーション１２０は、ＲＡＷソケット１２２を通じて、サブネット１０に接続された起動ノードからパケットを受信する。本実施の形態において「起動ノード」とは、電源が入り起動中のノードをいう。ホスト側アプリケーション１２０は、ノードリスト１２３の情報を最新の状態に維持する。
【００４２】
ホスト側アプリケーション１２０は、さらに、上位層１３０（家電制御アプリケーション等）にＡＰＩ（Application Programming Interface）を提供する。ホスト側アプリケーション１２０は、上位層１３０からの指示を受けて、最新のＥＣＨＯＮＥＴ Ｌｉｔｅ機器のリストなどを上位層１３０に返す。また、ホスト側アプリケーション１２０は、上位層１３０からの指示を受けて、ノードへ要求を送信する。また、ホスト側アプリケーション１２０は、通知または当該要求に対する応答を当該ノードから受信し、上位層１３０へ返す。
【００４３】
なお、上位層１３０としては、家電制御アプリケーション、家電制御ＣＧＩ（Common Gateway Interface）、家電管理情報取得ＣＧＩ（図示せず）がある。これらは互いに独立である。各々が独立して、ホスト側アプリケーション１２０と通信する。
【００４４】
デバイス側アプリケーション１１０およびホスト側アプリケーション１２０の各々は、パケットを送信するときは送信先ＵＤＰポート番号を３６１０にする。送信元ＵＤＰポート番号は任意で良い。デバイス側アプリケーション１１０およびホスト側アプリケーション１２０の各々は、パケットを受信するときは、送信先ＵＤＰポート番号３６１０を処理する。
【００４５】
ホスト側アプリケーション１２０は、送信用にＵＤＰソケット１２１を開く。なお、上述したように、ホスト側アプリケーション１２０は、ＵＤＰソケット１２１の送信元ポート番号を任意に設定する。
【００４６】
ホスト側アプリケーション１２０は、送受信用にＲＡＷソケット１２２を開く。ＲＡＷソケット１２２を開くのは、パケットを受信すると同時に送信元ＭＡＣアドレスも得るためである。ＲＡＷソケット１２２は、サブネット１０上を伝送されるデータのうち、ネットワークインターフェイス“eth0”で受信できるデータをすべて受信する。ホスト側アプリケーション１２０は、受信した全てのデータの中から、ＵＤＰ／ＩＰかつ宛先ＵＤＰポート番号が３６１０であるデータを利用する。あるいは、後述するＡＲＰパケットまたは任意のＩＰパケットなどを利用する。
【００４７】
上記の構成を有したＨＥＭＳコントローラ１００は、サブネット１０上の目的ノードを制御するために、目的ノードを探索する。より詳しくは、ＨＥＭＳコントローラ１００は、探索要求パケットをマルチキャストあるいはブロードキャストでサブネット１０に送信する。それに加えて、探索要求パケットをユニキャストでも送信する。
【００４８】
本実施の形態では、ＨＥＭＳコントローラ１００は、サブネット１０における起動ノードの最新の情報（後述するノード情報）を、ノードリスト１２３（詳細は後述する）によって管理する。ＨＥＭＳコントローラ１００は、探索要求パケットを送信する場合は、マルチキャストあるいはブロードキャストで送信するとともに、サブネット１０上に起動しているノードのノード情報に基づき、当該ノード情報のＩＰアドレスを宛先アドレスとする探索要求パケットをユニキャストで送信する。これにより、マルチキャストあるいはブロードキャストが転送されないようなネットワーク環境であっても、ＨＥＭＳコントローラ１００は、目的ノードを見つけることができる。
【００４９】
（ノードリストの構成）
ＨＥＭＳコントローラ１００が有するノードリスト１２３には、サブネット１０における「起動ノード」の情報を管理するためのノード情報が登録される。
【００５０】
図４は、ノードリスト１２３の構成を説明するための図である。ノードリスト１２３は複数のノード情報を含むコンテナである。サブネット１０で見つかった１つのノードにつき１つのノード情報がある。ノードリスト１２３の構成方法は、いろいろ考えられるが、目的とするノード情報を高速に検索できるようにハッシュテーブルの構成とするのが良い。可変長の配列（図４の例では、[0]から[22]まで23個の配列要素がある）と、配列要素のそれぞれはリンクリストで構成される。配列の長さは、ノード情報の個数が増えるに従って動的に拡張される。図４の構成は、ハッシュテーブルの構成としては一般的なものである。ノード情報は、当該ノードのＭＡＣアドレスとＩＰアドレスを少なくとも含む。
【００５１】
ノードリスト１２３からノード情報を読み出す時には、パケットを受信した送信元ＭＡＣアドレスに基づき検索される。具体的には、当該ＭＡＣアドレスから所定ハッシュ演算により算出されたハッシュ値が、ノードリスト１２３の配列の長さ（図４の例では、値２３）で除算される。そして、ノードリスト１２３において、当該余りを示す値に対応した要素のリンクリストをたどっていき、当該ＭＡＣアドレスに一致するＭＡＣアドレスを有したノード情報が読み出される。
【００５２】
ノード情報の書き込み時には、先ほどと同様に、パケットを受信した送信元のＭＡＣアドレスから算出されたハッシュ値が、ノードリスト１２３の配列の長さ（図４の例では、値２３）で除算される。そして、ノードリスト１２３において、当該余りを示す値に対応した要素のリンクリストの先頭または最後に、当該ノード情報が登録される。
【００５３】
図５は、本実施の形態１に係るノード情報の構成の一例を示す図である。図５を参照して、ノード情報は、当該ノードのＭＡＣアドレス、ＩＰアドレス、当該ノード情報をノードリスト１２３から削除すべき時刻、削除前ＡＲＰ（Address Resolution Protocol）リクエスト送信済みフラグ、および探索要求パケット送信カウンタを少なくとも含む。
【００５４】
サブネット１０においては、上述したようにノードが参加または離脱する可能性がある等、サブネット１０の状態は変化する。この変化に追従するために、ノードリスト１２３からは起動が確認されないノード情報は削除されなければならない。ノード情報には、削除すべき時刻が含まれており、削除すべき時刻に到達すれば削除される。例えば、削除すべき時刻は、ＨＥＭＳコントローラ１００が、当該ノード情報のパケットを最後に（最近に）受信したときから、所定時間後（例えば１５分経過後の）時刻とする。ＨＥＭＳコントローラ１００は、削除すべき時刻を、当該ノードからパケットを受信する毎に更新する。削除すべき時刻の設定方法の詳細は後述する。
【００５５】
削除前ＡＲＰリクエスト送信済みフラグは、ＨＥＭＳコントローラ１００がノード情報を削除する直前にＡＲＰリクエスト送信済みであるか否かを判断するために使われる。削除前ＡＲＰリクエスト送信済みフラグが０であれば、当該ノードのＩＰアドレスを探索ＩＰアドレスにしてＡＲＰリクエストを送信する。その応答があれば、ノード情報は削除されない。削除前ＡＲＰリクエスト送信済みフラグの初期値は０とする。
【００５６】
探索要求パケット送信カウンタは、ＨＥＭＳコントローラ１００が、当該ノードが目的とするノードであるかどうかを調べるために探索要求パケットを送信した回数をカウントしたものである。探索要求パケットが届かない可能性もあるので、同一ノードに対して探索要求パケットを何度も送信することとする。探索要求パケット送信カウンタの初期値は０である。
【００５７】
＜パケットの構成＞
サブネット１０上を伝送されるデータを説明する。本実施の形態では、伝送データはパケットの構成を有する。
【００５８】
図６は、ＡＲＰパケットの構成を示す図である。ＡＲＰリクエストまたはＡＲＰリプライは、図６のＡＲＰパケットの構成を有する。
【００５９】
図６を参照して、ＡＲＰパケットは、Ethernetヘッダ部と、ＡＲＰプロトコル部を含む。Ethernetヘッダ部は、宛先ノードのＭＡＣアドレス、送信元ノードのＭＡＣアドレス、および上位層プロトコルのタイプを含む。上位層がＡＲＰパケットである場合は、このプロトコルのタイプは“ＡＲＰ”を示す。
【００６０】
ＡＲＰプロトコル部は、ネットワークの物理的な媒体（本実施の形態ではEthernet）の種類、ＡＲＰプロトコルで取り扱う上位のプロトコルの種類（本実施の形態ではＩＰ）、物理層で利用されるアドレスの長さを示すハードウェアサイズ、および上位プロトコルで利用されるアドレスの長さを示すプロトコルサイズを含む。さらに、ＡＲＰの動作の種類を表すためのＯＰコード、送信者ＭＡＣアドレス、送信者ＩＰアドレス、探索ＭＡＣアドレス、および探索ＩＰアドレスを含む。ＯＰコードには、ＡＲＰ要求を表す“request”およびＡＲＰ要求に対する応答を表す“reply”のいずれかがセットされる。
【００６１】
送信者ＭＡＣアドレスおよび送信者ＩＰアドレスは、ＡＲＰリクエストまたはＡＲＰリプライを送信したノード自身のＭＡＣアドレスおよびＩＰアドレスをそれぞれ示す。
【００６２】
ＡＲＰパケットがＡＲＰリクエストを示す場合には、探索ＭＡＣアドレスには０にセットされ、探索ＩＰアドレスには探索したいＩＰアドレスがセットされる。ＡＲＰパケットがＡＲＰリプライを示す場合には、探索ＭＡＣアドレスおよび探索ＩＰアドレスには、対応するＡＲＰリクエストの送信ノードのＭＡＣアドレスおよびＩＰアドレスがそれぞれセットされる。
【００６３】
図７は、任意のＩＰパケットの構成示す図である。図７を参照して、任意のＩＰパケットは、Ethernetヘッダ部と、ＩＰヘッダ部とペイロード部（図示しない）を含む。Ethernetヘッダ部は、宛先ノードのＭＡＣアドレス、送信元ノードのＭＡＣアドレス、および上位層プロトコルのタイプを含む。上位層がＩＰパケットである場合は、このプロトコルのタイプは“ＩＰ”を示す。
【００６４】
ＩＰヘッダ部は、ＩＰプロトコルのバージョンとＩＰヘッダ部分のサイズとを示すヘッダ長、サービスタイプ、パケット長、ＩＰパケットに識別子、フラグとフラグメントオフセット、ＴＴＬ（time to live）、上位層のプロトコル番号、および整合性検査のためのヘッダチェックサムを含む。上位層のプロトコル番号には、例えば、上位層がＵＤＰパケットまたはＤＨＣＰパケットならば“１７”が入る。ＩＧＭＰパケットならば“２”が入る。
【００６５】
さらに、ＩＰヘッダ部は、当該ＩＰパケットの送信元ノードのＩＰアドレスを示す送信元ＩＰアドレス、および当該ＩＰパケットの宛先ノードのＩＰアドレスを含む。さらにペイロード部には、上位層の具体的なデータが含まれる。例えば、上位層がＵＤＰパケットの場合ならばＵＤＰヘッダ部が続く。
【００６６】
本実施の形態では、ＨＥＭＳコントローラ１００および各ノードは、パケットを受信した場合には、当該パケットのタイプに基づき、当該パケットはＡＲＰパケットであるかＩＰパケットであるかを判断することができる。
【００６７】
＜ＭＡＣアドレスとＩＰアドレスとの組が正しくない場合＞
ＨＥＭＳコントローラ１００が、任意のＩＰパケットを受信したとき、その送信元ＭＡＣアドレスと送信元ＩＰアドレスとの組が正しくない可能性がある。
【００６８】
例えば、任意のＩＰパケットが、無線ＬＡＮルーター３０２を超えたネットワーク（すなわち、サブネット１０とは異なるネットワーク）から送信されたものである場合には、当該ＩＰパケットの送信元ＩＰアドレスには真の送信者のＩＰアドレスがセットされているが、送信元ＭＡＣアドレスには、無線ＬＡＮルーター３０２のＭＡＣアドレスがセットされている。
【００６９】
また、ＩＰパケットがＤＨＣＰパケットである場合は、送信元ＩＰアドレスは、一律に０．０．０．０にセットされている。このような場合は、送信元ＭＡＣアドレスと送信元ＩＰアドレスとの組が正しくないと言える。
【００７０】
＜ノードリスト１２３の管理＞
次に、ＨＥＭＳコントローラ１００によるノードリスト１２３の管理について説明する。ノードリスト１２３は初期状態で空であるが、ノードリスト１２３の管理処理によって、サブネット１０における「起動ノード」の情報の追加または削除が行われる。
【００７１】
図９は、実施の形態１に係るノードリスト１２３からノード情報を削除するための処理を示すフローチャートである。
【００７２】
図１０は、本実施の形態１に係るＡＲＰリクエストまたはＡＲＰリプライを受信した時のノードリスト１２３の情報更新の処理を示すフローチャートである。
【００７３】
図１１は、本実施の形態１に係る任意のＩＰパケットを受信した時のノードリスト１２３の情報更新の処理を示すフローチャートである。
【００７４】
（ノード情報の削除処理）
図９を参照して、ノードリスト１２３からノード情報を削除する処理を説明する。図９の処理は定期的に（例えば２５０ｍｓ毎に）実行される。
【００７５】
まず、ＨＥＭＳコントローラ１００は、ノードリスト１２３から次のノード情報を取り出す（ステップＳ３）。次のノード情報がなければ（ステップＳ５でＮＯ）、処理を終了する。次のノード情報があれば（ステップＳ５でＹＥＳ）、ＨＥＭＳコントローラ１００は、当該ノードがタイムアウトされたか（削除すべき時刻になったか）否かを判断する（ステップＳ７）。
【００７６】
当該ノードがタイムアウトされていなければ（ステップＳ７でＮＯ）、ステップＳ３に戻る。ノードリスト１２３から次のノード情報を取り出して、ステップＳ５以降の処理が同様に実行される。
【００７７】
当該ノードがタイムアウトされていれば（ステップＳ７でＹＥＳ）、ＨＥＭＳコントローラ１００は、当該ノードの削除前ＡＲＰリクエスト送信済みフラグが“０”であるか否かを判断する（ステップＳ９）。
【００７８】
削除前ＡＲＰリクエスト送信済みフラグが“０”であるならば（ステップＳ９でＹＥＳ）、ＨＥＭＳコントローラ１００は、当該ノードのＩＰアドレスを探索ＩＰアドレスとするＡＲＰリクエストを送信する。ただし、当該ノードのＩＰアドレスが０．０．０．０のときは（一時的なＩＰアドレスなので）ＡＲＰリクエストを送信せずすぐに当該ノードのノード情報を削除する（ステップＳ１１）。
【００７９】
ＨＥＭＳコントローラ１００は、上記のＡＲＰリクエストを送信した場合に、ノード情報のリクエスト送信済みフラグを“１”にセットし（ステップＳ１３）、当該ノードの削除すべき時刻を１０秒間だけ延長する（ステップＳ１５）。その後、ステップＳ３に戻る。
【００８０】
ステップＳ９において、削除前ＡＲＰリクエスト送信済みフラグが“０”でないならば（ステップＳ９でＮＯ）、ＨＥＭＳコントローラ１００は、ノードリスト１２３から当該ノードのノード情報を削除する（ステップＳ１７）。その後、ステップＳ３に戻る。
【００８１】
このように、ＨＥＭＳコントローラ１００は、基本的には、各ノード情報の削除すべき時刻になれば当該ノード情報をノードリスト１２３から削除するが、削除する直前に当該ノードがまだ起動しているかどうかを確認するために（ＲＡＷソケット１２２を通じて）ＡＲＰリクエストを送信する。当該ノードからＡＲＰレスポンス（または任意のＩＰパケット）を１０秒以内に受信できなければ当該ノード情報は削除される。当該ノードからＡＲＰレスポンス（または任意のＩＰパケット）を受信できれば当該ノード情報は削除されない。
【００８２】
（ノード情報の登録処理）
ＨＥＭＳコントローラ１００は、ＲＡＷソケット１２２を通じてパケットを受信したときに、送信元ＭＡＣアドレスに基づきノードリスト１２３へノード情報を登録する。この対象となるパケットは、ＡＲＰリプライまたはＡＲＰリクエストのパケット、および任意のＩＰパケットである。
【００８３】
−ＡＲＰリプライ／ＡＲＰリクエスト受信時の登録処理−
まず、図１０を参照してＡＲＰリプライまたはＡＲＰリクエストのパケットを受信した場合の登録処理を説明する。図１０の処理は、ＡＲＰリクエストまたはＡＲＰリプライを受信する毎に実行される。
【００８４】
ただし、送信元ＭＡＣアドレスと送信者ＭＡＣアドレスとが一致しない場合もあるが、その場合は、ＨＥＭＳコントローラ１００は図１０の処理を実施しない（重複ＩＰアドレスを検出したときに、ルーターからもＡＲＰリプライが来ることがある）。従って、図１０に記載された送信者ＭＡＣアドレスは、送信元ＭＡＣアドレスと同一の値である。
【００８５】
まず、ＨＥＭＳコントローラ１００は、受信したパケット（ＡＲＰリクエストまたはＡＲＰリプライ）の送信者ＭＡＣアドレスをキーに、ノードリスト１２３からノード情報を取り出す（ステップＳ２０）。当該送信者ＭＡＣアドレスに一致するノード情報があるか否かを判断する（ステップＳ２１）。
【００８６】
当該送信者ＭＡＣアドレスに一致するノード情報がなければ（ステップＳ２１でＮＯ）、ＨＥＭＳコントローラ１００は、ノード情報を新規作成する（ステップＳ２２）。このノード情報のＭＡＣアドレスおよびＩＰアドレスとして、受信されたパケットの送信者ＭＡＣアドレスと送信者ＩＰアドレスがそれぞれセットされる。また、当該ノード情報のパケット送信カウンタは０（初期値）にセットされる。
【００８７】
ＨＥＭＳコントローラ１００は、新規作成されたノード情報を、ノードリスト１２３に追加して登録する（ステップＳ２３）。また、ＨＥＭＳコントローラ１００は、受信した当該ノード情報の削除すべき時刻５３に、現在時間よりも１５分経過後の時刻をセットする。また、削除前ＡＲＰリクエスト送信済みフラグを０（初期値）にセットする（ステップＳ２６）。
【００８８】
ステップＳ２１において、当該送信者ＭＡＣアドレスに一致するノード情報があれば（ステップＳ２１でＹＥＳ）、ＨＥＭＳコントローラ１００は、当該ノード情報のＩＰアドレスが、受信されたパケットの送信者ＩＰアドレスと一致するか否かを判断する（ステップＳ２４）。一致すると判断すると（ステップＳ２４でＹＥＳ）、ステップＳ２６において、当該ノード情報について前述（ステップＳ２６）と同様の処理が実行される。
【００８９】
当該ノード情報のＩＰアドレスが、受信されたパケットの送信者ＩＰアドレスと一致しないならば（ステップＳ２４でＮＯ）、ＨＥＭＳコントローラ１００は、当該ノード情報のＩＰアドレスを送信者ＩＰアドレスに更新する（ステップＳ２５）。その後、ステップＳ２６の処理が上述と同様に実行される。
【００９０】
図１０の処理によって、ＨＥＭＳコントローラ１００は、ＡＲＰリクエストまたはＡＲＰリプライを受信する毎に当該ノードのノード情報の削除すべき時刻を、パケットを受信した時の時刻から１５分後を示すように更新（時間を延長）する。
【００９１】
−任意のＩＰパケット受信時の登録処理−
次に、図１１を参照して、任意のＩＰパケットを受信した場合の登録処理を説明する。ＨＥＭＳコントローラ１００は、任意のＩＰパケットを受信する毎に図１１の処理を実行する。任意のＩＰパケットには、ＩＧＭＰパケット、ＩＣＭＰ（Internet Control Message Protocolの略）パケット、ＤＨＣＰパケット、ＵＤＰパケットおよびＴＣＰ（Transmission Control Protocolの略）パケットなどが含まれる。
【００９２】
図１１を参照して、ＨＥＭＳコントローラ１００は、受信したＩＰパケットの送信元ＭＡＣアドレスをキーに、ノードリスト１２３からノード情報を取り出す（ステップＳ３０）。ＨＥＭＳコントローラ１００は、送信元ＭＡＣアドレスに一致するノード情報があるか否かを判断する（ステップＳ３１）。送信元ＭＡＣアドレスに一致するノード情報があれば（ステップＳ３１でＹＥＳ）、ＨＥＭＳコントローラ１００は、図１０のステップＳ２６の処理と同様に、当該ノード情報の削除すべき時刻に、現在時刻よりも１５分経過後の時刻をセットし、また、リクエスト送信済みフラグを０にセットする（ステップＳ３５）。
【００９３】
送信元ＭＡＣアドレスに一致するノード情報がなければ（ステップＳ３１でＮＯ）、ＨＥＭＳコントローラ１００は、ノード情報を新規に作成する（ステップＳ３２）。ＨＥＭＳコントローラ１００は、このノード情報に、受信されたパケットの送信元ＭＡＣアドレスをＭＡＣアドレスとしてセットするとともに、ＩＰアドレスには０．０．０．０をセットする。また、パケット送信カウンタには０をセットする。
【００９４】
本実施の形態では、上記の“（ＭＡＣアドレスとＩＰアドレスとの組が正しくない場合）”で説明したように、受信されたＩＰパケットの送信元ＭＡＣアドレスと送信元ＩＰアドレスとの組は常に正しいとは限らない。したがって、ＨＥＭＳコントローラ１００は、新規に作成したノード情報のＩＰアドレスに、上述のように ０．０．０．０を一時的にセットする。
【００９５】
ＨＥＭＳコントローラ１００は、新規作成されたノード情報を、ノードリスト１２３に追加する（ステップＳ３３）。
【００９６】
また、ＨＥＭＳコントローラ１００は、受信したＩＰパケットの送信元ＩＰアドレスを、探索ＩＰアドレスにセットしたＡＲＰリクエストを送信する（ステップＳ３４）。なお、このとき、受信ＩＰパケットの送信元ＩＰアドレスが０．０．０．０を示す場合には、ＡＲＰリクエストを送信しない。その後、新規作成されたノード情報について、ステップＳ３５の処理が実行される。
【００９７】
ＨＥＭＳコントローラ１００は、上記のステップＳ３４においてＡＲＰリクエストを送信した後に、これに対するＡＲＰリプライを受信した場合には、図１０のフローに従って、ステップＳ２５の処理を実行することになる。これにより、当初０．０．０．０とセットされていたノード情報のＩＰアドレスが正しいＩＰアドレスに更新される。
【００９８】
このように、図１１の場合も、図１０と同様に、ＨＥＭＳコントローラ１００は、ノードから任意のＩＰパケットを受信する毎に、当該ノードのノード情報の削除すべき時刻を、パケットを受信した時刻の１５分後を示すように更新（時間を延長）する。
【００９９】
上述の削除処理（図９参照）は、図１０と図１１で更新される削除すべき時刻に基づき実行されるから、起動ノードについては、起動が確認される間は、ノード情報は削除されることはない。したがって、図９〜図１１の処理によって、サブネット１０上の「起動ノード」に関する情報を最新の状態に維持することができる。図９〜図１１の処理は、基本的には、パケットを受信したときに実行される処理である。「サブネット１０上にある起動ノードの存在を受動的に検出する」というのはそれゆえのことである。
【０１００】
＜目的ノードの探索処理＞
次に、ＨＥＭＳコントローラ１００が目的ノードをサブネット１０上で探索する処理を説明する。
【０１０１】
本実施の形態では、ＨＥＭＳコントローラ１００は、サブネット１０に探索要求パケットを送信し、それに対する探索応答パケットを受信することにより、当該目的ノードを見つける。ここでは、目的ノードを見つけることを「探索に成功する」ともいう。
【０１０２】
図１２は、本実施の形態１に係る目的ノードを探索する処理のフローチャートである。ＨＥＭＳコントローラ１００は、図１２の処理を一定間隔で（例えば、３分毎に）実行する。
【０１０３】
図１２を参照して、ＨＥＭＳコントローラ１００は、宛先ＩＰアドレスをマルチキャスト・アドレスにセットした探索要求パケットを送信する（ステップＳ４０）。
マルチキャスト・アドレスとポート番号については、探索機器と被探索機器との間で予め定められている。
【０１０４】
例えば、被探索機器がＥＣＨＯＮＥＴ  Ｌｉｔｅ（登録商標）機器である場合、マルチキャスト・アドレスは２２４．０．２３．０に、また、ポート番号は３６１０とする。
【０１０５】
他の例として、被探索機器がＵＰｎＰ（Universal Plug and Play- Simple Service Discovery Protocol）デバイスである場合、マルチキャスト・アドレスは２３９．２５５．２５５．２５０に、また、ポート番号は１９００とする。
【０１０６】
本実施の形態では、サブネット１０上の目的ノードを確実に探索するために、ＨＥＭＳコントローラ１００は、ノードリスト１２３の各ノード情報に基づいて探索要求パケットを生成して、ユニキャストで送信する（ステップＳ４１とＳ４２）。
【０１０７】
具体的には、ＨＥＭＳコントローラ１００は、探索要求パケットの宛先ＩＰアドレスを、ノードリスト１２３のノード情報から１つ選択する。この選択においては、ノードリスト１２３の各ノード情報から、探索要求パケット送信カウンタの値が最小であるノード情報を選択するのがよい。そのように選択したノード情報のＭＡＣアドレスおよびＩＰアドレスを、宛先ＭＡＣアドレスおよび宛先ＩＰアドレスにそれぞれセットして探索要求パケットを生成し、ユニキャストで送信する。
【０１０８】
本実施の形態では、上述のステップＳ４１におけるノード情報選択時に、ＩＰアドレスが０．０．０．０であるノード情報を選択の対象から外す。これは、ステップＳ３２（図１１）でノード情報を新規作成した後、ＩＰアドレスが更新されていない場合があるからである。
【０１０９】
また、ＨＥＭＳコントローラ１００は、探索応答パケットを既に受信しているノードについても選択の対象から外す。これは、当該ノードについては既に探索に成功しているからであり、再度探索する必要はないからである。さらに、ＨＥＭＳコントローラ１００は、パケット送信カウンタが上限値（例えば、３０回）に達しているノード情報も選択の対象から外す。これは、当該ノードに対して探索要求パケットを何度も繰り返し送信しているにもかかわらず、探索応答パケットを受信していないということは、当該ノードは目的とするノードではないと判断できるからである。ステップＳ４１において、ノードリスト１２３で管理しているすべてのノード情報が、対象外である場合には、ステップＳ４１にてユニキャストで送信する必要はない。
【０１１０】
ＨＥＭＳコントローラ１００は、選択されたノード情報のＩＰアドレスに基づいた探索要求パケットをユニキャストで送信したとき、当該ノード情報の探索要求パケット送信カウンタの値をインクリメントする（ステップＳ４３）。
【０１１１】
なお、上記の探索要求パケットの送信元ＭＡＣアドレスおよび送信元ＩＰアドレスには、ＨＥＭＳコントローラ１００が有するＭＡＣアドレスおよびＩＰアドレスがセットされる。
【０１１２】
ＨＥＭＳコントローラ１００は、探索要求パケットに対する探索応答パケットを受信するために所定期間（例えば、５秒間）経過するまで待つ（ステップＳ４４）。
【０１１３】
探索応答パケットは、ＩＰパケット（図７参照）の構成を有する。具体的には、探索応答パケットの送信元ＭＡＣアドレスおよび送信元ＩＰアドレスには、送信元ノードが有するＭＡＣアドレスおよびＩＰアドレスがそれぞれセットされている。
【０１１４】
ステップＳ４４で、ＨＥＭＳコントローラ１００は、複数個の探索応答パケットを受信する場合があり得る。（探索要求パケットをマルチキャストで送信しているため）したがって、探索要求パケットを送信してから所定期間（例えば、５秒間）は必ず待つようにする。この所定期間内に探索応答パケットを受信し、その内容が先に送信した探索要求パケットに対する応答であることを確認できれば、目的ノードを見つけることができたと判断する。この場合には、ＨＥＭＳコントローラは、目的ノードのノード情報を別途管理する。この管理方法は、本発明の範囲ではないので説明を省略する。
【０１１５】
[実施の形態２］
実施の形態２は、実施の形態１の変形例である。実施の形態１では、ＨＥＭＳコントローラ１００は、目的ノードの探索時に、マルチキャストで探索要求パケットを送信する（図１２のステップＳ４０参照）。一方、実施の形態２では、ＨＥＭＳコントローラ１００は、ブロードキャストで探索要求パケットを送信する。
【０１１６】
なお、マルチキャストで送信するか、ブロードキャストで送信するかは、被探索機器によって使い分ける。探索機器と被探索機器との間で発見プロトコルが予め定められている。
【０１１７】
なお、実施の形態２でも、探索要求パケットがブロードキャストで送信される点を除いた構成および機能については、実施の形態１と同様の構成および機能が実現されるので、それらの詳細説明は繰返さない。
【０１１８】
図１３は、本実施の形態２に係る目的ノードを探索する処理を示すフローチャートである。ＨＥＭＳコントローラ１００は、図１３の処理を一定間隔（例えば、３分毎）で実行する。
【０１１９】
図１３を参照して、ＨＥＭＳコントローラ１００は、宛先ＩＰアドレスをブロードキャスト・アドレスにセットして探索要求パケットを送信する（ステップＳ４０ａ）。
【０１２０】
ブロードキャスト・アドレスについてはマルチキャスト・アドレスとは異なり特に取り決めはなくてもよいが、ポート番号については、探索機器と被探索機器との間で予め定められている。
【０１２１】
例えば、被探索機器がシャープ株式会社製の電力モニタのノードである場合、ＨＥＭＳコントローラ１００は、宛先ＩＰアドレスをブロードキャスト・アドレスに、宛先ポート番号を１２１３２にセットした探索要求パケットをブロードキャストで送信する。
【０１２２】
なお、ブロードキャスト・アドレスについては、ＩＰアドレスの全ビットを１にした、リミテッド・ブロードキャスト・アドレス（２５５．２５５．２５５．２５５）と、ＩＰアドレスのホスト部だけをすべて１にしたディレクティッド・ブロードキャスト・アドレスとがある。例えば、サブネット１０の各ノードのＩＰアドレスが１９２．１６８．１１．Ｘで、サブネットマスクが２５５．２５５．２５５．０であるとき、１９２．１６８．１１．２５５となる。いずれにせよサブネット１０の各ノードに届くことが期待できるので、どちらを使ってもよい。
【０１２３】
実施の形態２でも、サブネット１０上の目的ノードを確実に探索するために、ＨＥＭＳコントローラ１００は、ノードリスト１２３の各ノード情報のＩＰアドレスに基づいて探索要求パケットを生成して、ユニキャストで送信する（ステップＳ４１とＳ４２）。
【０１２４】
図１３のステップＳ４１以降の処理は、図１２で説明した処理と同様であるから、詳細説明は繰返さない。
【０１２５】
[実施の形態３]
実施の形態３では、実施の形態１と２の変形例を説明する。図１４は、実施の形態３に係るＩＧＭＰｖ２(Internet Group Management Protocol version2） General Queryの送信処理を示すフローチャートである。ＨＥＭＳコントローラ１００は、図１４の処理を一定間隔（例えば、２５０秒）で実行する。
【０１２６】
実施の形態１で説明した図１０と図１１の処理では、ＨＥＭＳコントローラ１００は、ＲＡＷソケット１２２を通じて受信可能なパケットを受信し、当該受信されたパケットの送信元ＭＡＣアドレスに基づきノードリスト１２３へノード情報を登録する。この方法によれば、長い期間にわたって、ＲＡＷソケット１２２を通じて受信可能なパケットを受信し続ければ、サブネット１０上で起動されているノードのほぼ全てを検出できる。
【０１２７】
例えば、ＷＡＮ側にある外部サーバー（図示せず）と通信するようなノードであれば、定期的に（デフォルトゲートウェイである）無線ＬＡＮルーター３０２を探索ＩＰアドレスとするＡＲＰリクエストを送信するはずである。したがって、ＨＥＭＳコントローラ１００は、当該ＡＲＰリクエストのパケットを、ＲＡＷソケット１２２を通じて受信することで、当該ノードの存在を検出することができる。ＡＲＰリクエストは、ＭＡＣレベルのブロードキャストで送出されるので、ルーターに依存することなく、サブネット１０上のすべてのノードに届けられる。ＨＥＭＳコントローラ１００は、サブネット１０上の各ノードから送出されるＡＲＰリクエストを受信できる。
【０１２８】
しかし、サブネット１０上の起動ノードであっても、自発的に送信動作を実行しないようなノードについては、実施の形態１の方法では、そのノードの存在を検出できないおそれがある。
【０１２９】
そこで、実施の形態３では、図１４に示すように、ＨＥＭＳコントローラ１００は、ＩＧＭＰｖ２General Query（以下、ＩＧＭＰ General Queryという）のパケットを一定間隔（例えば、２５０秒）で送信する（ステップＳ５０）。
【０１３０】
このＩＧＭＰ General Queryは、図７のＩＰパケットの構成を有する。ＩＧＭＰGeneral Queryの宛先ＩＰアドレスはマルチキャスト・アドレス（２２４．０．０．１）がセットされている。
【０１３１】
任意のマルチキャスト・グループに参加しているノードは、ＩＧＭＰ General Queryを受信する。当該ノードは、その応答としてＩＧＭＰ  Ｒｅｐｏｒｔを送信する。当該ＩＰパケットには、送信元ＭＡＣアドレスと送信元ＩＰアドレスとが当該ノードのＭＡＣアドレスとＩＰアドレスにそれぞれセットされている。
【０１３２】
ＨＥＭＳコントローラ１００は、ＩＧＭＰ  Ｒｅｐｏｒｔのパケット（図示しない）を受信する場合がある。ＩＧＭＰ  Ｒｅｐｏｒｔのパケットも図７のＩＰパケットの構成を有する。
【０１３３】
ＨＥＭＳコントローラ１００は、ＩＧＭＰ  Ｒｅｐｏｒｔを受信すれば（任意のＩＰパケットの１つであるので）、図１１の処理を実行する。
【０１３４】
送信元ＭＡＣアドレスに一致するノードがなければ、ＨＥＭＳコントローラ１００は、ノード情報を新規作成してノードリスト１２３に追加する。この処理は、上述したように図１１の処理（任意のＩＰパケットを受信したときの処理）と同じであるので、詳細な説明は繰返さない。
【０１３５】
実施の形態３によれば、サブネット１０上の起動ノードのうち自発的にパケットを送信しないようなノードであっても、当該ノードがマルチキャスト・グループに参加しているのであれば、ＨＥＭＳコントローラ１００は当該ノードのノード情報をノードリスト１２３に登録し管理することができる。
【０１３６】
＜ＨＥＭＳコントローラの機能構成＞
図８は、実施の形態１に係るＨＥＭＳコントローラ１００の機能的構成を表す機能ブロック図である。図８を参照して、ＨＥＭＳコントローラ１００は、サブネット１０上のパケットを送受信する通信部１４０、ノード情報管理部１５０、記憶部１６０、および探索部１７０を含む。通信部１４０は、高速通信インターフェイス１１０４を介して通信するＲＡＷソケット１２２およびＵＤＰソケット１２１の機能を含む。実施の形態３に係るＨＥＭＳコントローラ１００は、マルチキャスト・ノード問合せ送信部１８０をさらに含む。
【０１３７】
ノード情報管理部１５０は、サブネット１０上にある起動ノードの存在を受動的に検出する。具体的には、通信部１４０を介してパケットを受信する毎に、図１０と図１１に示すように、パケット送信元のノードに関する情報をノード情報としてノードリスト１２３により管理する。
【０１３８】
探索部１７０は、通信部１４０を介して探索要求パケットを送信し、探索応答パケットを受信することによって目的ノードを探索する。探索部１７０は、図１２に示すように、探索要求パケットを送信する際に、マルチキャストで送信するとともに、ノード情報管理部１５０により管理されるノード情報のアドレスを宛先にして、当該探索要求パケットをユニキャストで送信する。
【０１３９】
また、探索部１７０は、探索要求パケットを送信する際に、上記のマルチキャストでの送信に代えて、図１３に示すように、ブロードキャストで送信してもよい。
【０１４０】
ノード情報管理部１５０は、図９に示すように、ノード情報が所定の時間更新されなければ、当該ノードが起動されているかどうかを確認するパケットを、通信部１４０を介して送信し、確認するパケットに呼応する応答の受信がなければノード情報を削除する。
【０１４１】
マルチキャスト・ノード問合せ送信部１８０は、図１４に示すように、マルチキャスト・グループに参加しているノードの存在確認のために、通信部１４０を介して、マルチキャスト・ノード問合せパケットを送信する。マルチキャスト・グループに参加しているノードは、当該問合せパケットに呼応して、通知パケットを送信する。ノード情報管理部１５０は、通信部１４０を介して当該通知パケットを受信すると、図１１に示すように、当該通知パケット送信元のノードに関する情報をノード情報としてノードリスト１２３により管理する。
【０１４２】
＜実施の形態の効果＞
このように各実施の形態では、通信部１４０にてパケットを受信する毎に、パケット送信元のノードに関する情報をノード情報としてノードリスト１２３により管理する。これにより、無駄なトラフィックを発生させずに、サブネット１０上に起動しているノードを受動的に検出できる。
【０１４３】
また、ＨＥＭＳコントローラ１００がサブネット１０上の目的ノードを探索する場合には、マルチキャストまたはブロードキャストの送信に加え、ノードリスト１２３のノード情報に基づく探索要求パケットをユニキャストで送信する。その結果、マルチキャスト・パケットまたはブロードキャスト・パケットが目的ノードに届かないようなネットワーク環境であっても、ＨＥＭＳコントローラ１００は、目的ノードを確実に見つけ出すことができる。
【０１４４】
また、探索要求パケットは、ノードリスト１２３のノード情報に基づき生成されてサブネット１０に送信されるから、ＨＥＭＳコントローラ１００は、当該探索要求パケットを起動しているノードに限定して送信することができる。従って、ＨＥＭＳコントローラ１００が目的ノード探索のために無駄なトラフィックを発生させることはない。
【０１４５】
今回開示された実施の形態およびその変形例はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１４６】
１  通信ネットワーク、３０２  無線ＬＡＮルーター、１０  サブネット、１００  ＨＥＭＳコントローラ、１１０  デバイス側アプリケーション、１２０  ホスト側アプリケーション、１４０  通信部、１５０  ノード情報管理部、１６０  記憶部、１７０  探索部、１８０  マルチキャスト・ノード問合せ送信部。
【図１】
0006489837.tif 000002
【図２】
0006489837.tif 000003
【図３】
0006489837.tif 000004
【図４】
0006489837.tif 000005
【図５】
0006489837.tif 000006
【図６】
0006489837.tif 000007
【図７】
0006489837.tif 000008
【図８】
0006489837.tif 000009
【図９】
0006489837.tif 000010
【図１０】
0006489837.tif 000011
【図１１】
0006489837.tif 000012
【図１２】
0006489837.tif 000013
【図１３】
0006489837.tif 000014
【図１４】
0006489837.tif 000015