配信方法及び配信システム
【課題】データの配信を効率化すること。
【解決手段】データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法は、前記配信元装置が、探索範囲を複数の段階に分けて拡張して配信先装置を探索し、前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、前記配信先装置が、当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する。
【解決手段】データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法は、前記配信元装置が、探索範囲を複数の段階に分けて拡張して配信先装置を探索し、前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、前記配信先装置が、当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信方法及び配信システムに関する。
【背景技術】
【０００２】
スマートメータに関して、欧米においては導入が始まっており、日本においても実証実験が開始されている。スマートメータとは、通信機能付きの電力量計をいう。スマートメータは、ネットワークを介して電力利用量等を電力事業者へ報告することができる。スマートメータが各家庭に設置されれば、人手による検針作業を不要とすることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２４２０６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
無線通信機能を有するスマートメータの導入も検討されている。このようなスマートメータに関して、無線通信を利用してファームウェアの配信が可能となれば便利である。例えば、特許文献１に記載された技術を用いて、スマートメータのファームウェアを配信することが考えられる。
【０００５】
しかしながら、特許文献１に記載されている技術では、配信順序を指示したテーブルが予め各サーバに設定される必要がある。したがって、スマートメータのように、随時設置又は撤去が行われる可能性の有るノードを含むネットワーク環境に関して、斯かるテーブルが設定されるのは非効率である。
【０００６】
そこで、ブロードキャストの多重ホップによって、各スマートメータにファームウェアを配信することが考えられる。ブロードキャストであれば、配信先は特定のノードに限定されず、多重ホップによれば、広範囲のノードにファームウェアを配信可能であると考えられるからである。
【０００７】
しかしながら、ＩＥＥＥ８０２．１５．４等の、無線周波数帯域が小さい方式によって、ファームウェアのような比較的大きなサイズのデータをブロードキャストの多重ホップによって転送すると、一時的にネットワークの擾乱が発生する可能性がある。すなわち、通常、大きなサイズのデータは、複数ブロックに分割されて転送される。ブロックごとにブロードキャストの多重ホップが行われる場合、或るブロックに関してネットワークの擾乱が発生すると、該擾乱がおさまるまで次のブロックの配信を待機する必要がある。その待機時間が積み重なることにより、全てのブロックの転送が終了するまでに、長い時間を必要とする可能性がある。
【０００８】
そこで、データの配信を効率化することのできる配信方法及び配信システムの提供を目的とする。
【課題を解決するための手段】
【０００９】
そこで上記課題を解決するため、データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法は、前記配信元装置が、探索範囲を複数の段階に分けて拡張して配信先装置を探索し、前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、前記配信先装置が、当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する。
【発明の効果】
【００１０】
データの配信を効率化することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態における配信システムの構成例を示す図である。
【図２】第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。
【図３】第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。
【図４】１ホップ区間限定の配信先確認メッセージの送信例を示す図である。
【図５】配信先応答メッセージの送信例を示す図である。
【図６】ダウンロード許可メッセージの第一の送信例を示す図である。
【図７】ダウンロード開始要求メッセージ送信例を示す図である。
【図８】ファームウェアファイルの送信例を示す図である。
【図９】ダウンロード要求待ち通知メッセージの第一の送信例を示す図である。
【図１０】受信通知メッセージの第一の送信例を示す図である。
【図１１】ダウンロード許可メッセージの第二の送信例を示す図である。
【図１２】隣接ノードへのダウンロード開始要求メッセージの送信例を示す図である。
【図１３】隣接ノードからのファームウェアファイルの送信例を示す図である。
【図１４】ダウンロード要求待ち通知メッセージの第二の送信例を示す図である。
【図１５】受信通知メッセージの第二の送信例を示す図である。
【図１６】２ホップ区間限定の配信先確認メッセージの送信例を示す図である。
【図１７】本発明の実施の形態における配信元装置のハードウェア構成例を示す図である。
【図１８】第一の実施の形態の配信元装置の機能構成例を示す図である。
【図１９】第一の実施の形態のノードの機能構成例を示す図である。
【図２０】第一の実施の形態の配信元装置の処理手順の一例を説明するためのフローチャートである。
【図２１】配信先確認メッセージの構成例を示す図である。
【図２２】ダウンロード許可メッセージのデータ部の構成例を示す図である。
【図２３】第一の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。
【図２４】第一の実施の形態のノードが実行するダウンロード処理の処理手順の一例を説明するためのフローチャートである。
【図２５】ダウンロード要求待ちメッセージのデータ部の構成例を示す図である。
【図２６】第一の実施の形態のノードが実行する配信処理の処理手順の一例を説明するためのフローチャートである。
【図２７】第一の実施の形態においてダウンロード要求待ちメッセージを受信したノードが実行する処理手順の一例を説明するためのフローチャートである。
【図２８】リセット日時の到来に応じて各ノードが実行する処理を説明するためのフローチャートである。
【図２９】第二の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。
【図３０】第二の実施の形態においてダウンロード許可メッセージを受信していないノードがブロードキャストによるファームウェアファイルを受信した際の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における配信システムの構成例を示す図である。同図の配信システム１において、配信元装置１０は、各ノードへのファームウェアの配信元となる通信装置である。配信元装置１０は、配信対象のファームウェアを、ネットワーク４０を介してダウンロードサーバ３０よりダウンロードする。配信元装置１０は、ダウンロードしたファームウェアを、無線通信を利用してノードＮに配信する。
【００１３】
ダウンロードサーバ３０は、ファームウェアを記憶し、複数の配信システム１に対してファームウェアのダウンロード元となるコンピュータである。
【００１４】
各ノードＮは、無線通信機能を有する通信機器である。本実施の形態において、ノードＮは、配信先装置の一例である。ノードＮの具体例として、スマートメータが挙げられる。この場合、各ノードＮの設置位置は、各家庭である。各家庭の間隔は一様ではないため、スマートメータのみによって配信システム１を構成した場合、いずれのノードＮからも電波が届かないノードＮが存在する可能性がある。したがって、単に無線通信を中継するための中継装置がノードＮとして配置されてもよい。
【００１５】
なお、本実施の形態の配信方法は、各ノードＮの機能には依存しない。したがって、スマートメータ以外の通信機器に、本実施の形態の配信方法が適用されてもよい。
【００１６】
本実施の形態において、各ノードＮの参照番号は、Ｎ［０〜４］［ａ〜ｈ］という形式を有する。［０〜４］は、配信元装置１０からのホップ数を示す。ホップ数とは、配信元装置１０より送信されたメッセージが当該ノードＮに到達するまでに経由する他のノードＮの数である。［ａ〜ｈ］は、同一ホップ数の圏内（同一ホップ区間内）に位置する各ノードＮを識別するための符号である。全てのノードＮを区別しない場合、上記の通り、単に、「ノードＮ」という。また、特定のホップ区間内のノードＮの集合を限定して説明の対象とする場合、例えば、「ノードＮ１」のように、Ｎの後にホップ数が付与される。
【００１７】
第一の実施の形態の配信システム１が実行する、ファームウェアの配信処理の基本的な手順について説明する。図２及び図３は、第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。なお、各シーケンス図には、便宜上、一部のノードＮのみが示されている。
【００１８】
ステップＳ１０１において、ダウンロードサーバ３０は、ＦＴＰ（File Transfer Protocol）等を利用して配信対象のファームウェアを格納したファイル（ファームウェアファイル）を配信元装置１０に転送する。例えば、新しいバージョンのファームウェアの一部又は全部を含むファームウェアファイルがダウンロードされる。続いて、ダウンロードサーバ３０は、ファームウェアの更新開始要求を配信元装置１０に送信する（Ｓ１０２）。更新開始要求には、配信開始日時等が指定されている。続いて、配信元装置１０は、ダウンロードサーバ３０に対して、更新開始要求に対する応答を返信する（Ｓ１０３）。
【００１９】
配信開始日時が到来すると、配信元装置１０は、ファームウェアファイル配信先を探索するために、配信先確認メッセージを、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１０４ａ、Ｓ１０４ｂ）。すなわち、探索範囲が１ホップ区間に限定されて、配信先の探索が行われる。
【００２０】
図４は、１ホップ区間限定の配信先確認メッセージの送信例を示す図である。同図に示されるように、配信先確認メッセージｍ１は、１ホップ区間限定であるため、１ホップ区間内の各ノードＮ０によって受信され、２ホップ区間以上のノードＮにはホップされない。なお、配信先確認メッセージｍ１には、例えば、配信対象のファームウェアの識別情報（バージョン等）が含まれている。
【００２１】
配信先確認メッセージｍ１を受信したノードＮ０群の中で、配信対象のファームウェアを適用する必要のある各ノードＮ０は、配信先確認メッセージｍ１の送信元に、配信先応答メッセージをユニキャストで返信する（Ｓ１０５ａ、Ｓ１０５ｂ）。配信先確認メッセージｍ１の送信元とは、配信元装置１０である。また、配信先応答メッセージは、自らがファームウェアの配信先であることを示すメッセージである。
【００２２】
図５は、配信先応答メッセージの送信例を示す図である。同図では、全てのノードＮ０より、配信先応答メッセージｍ２が返信されている例が示されている。
【００２３】
配信元装置１０は、各配信先応答メッセージｍ２の受信順に、当該配信先応答メッセージｍ２の送信元の各ノードＮ０の識別情報を、配信先リストに追加する。配信先リストとは、配信先として予定されるノードＮの一覧情報である。配信元装置１０は例えば、最初に受信された配信先応答メッセージｍ１の送信元のノードＮ０を最初の配信先（ダウンロード先）として決定する。但し、配信先の順番は、他の方法によって決定されてもよい。
【００２４】
図２では、ノードＮ０ａからの配信先応答メッセージｍ２が最初に受信されている（Ｓ１０５ａ）。したがって、配信元装置１０は、ノードＮ０ａに対して、ダウンロード許可メッセージをユニキャストで送信する（Ｓ１０６）。ダウンロード許可メッセージは、ファームウェアのダウンロードの実行の許可を示すメッセージである。
【００２５】
図６は、ダウンロード許可メッセージの第一の送信例を示す図である。同図には、ノードＮ０ａに対して、ダウンロード許可メッセージｍ３ａが送信されている例が示されている。
【００２６】
ダウンロード許可メッセージｍ３ａを受信したノードＮ０ａは、ダウンロード開始要求メッセージを配信元装置１０にユニキャストで送信する（Ｓ１０７）。ダウンロード開始要求メッセージは、ダウンロードの開始要求を示すメッセージである。
【００２７】
図７は、ダウンロード開始要求メッセージ送信例を示す図である。同図には、ノードＮ０ａが、ダウンロード開始要求メッセージｍ４ａを送信している例が示されている。
【００２８】
ダウンロード開始要求メッセージｍ４ａを受信した配信元装置１０は、メッセージｍ４ａの送信元のノードＮ０ａに、ファームウェアファイルをユニキャストで送信する（Ｓ１０８−１〜Ｓ１０８−ｎ）。図２では、ファームウェアファイルがｎ個のブロックに分割されて、ブロックごとに送信される例が示されている。
【００２９】
図８は、ファームウェアファイルの送信例を示す図である。同図には、配信元装置１０からノードＮ０ａに対してファームウェアファイルｆ１が送信されている例が示されている。
【００３０】
このように、ダウンロード許可メッセージｍ３を受信したノードＮのみが、ダウンロードを実行することができる。すなわち、ダウンロード許可メッセージｍ３によって、配信装置１０は、ファームウェアファイルｆ１のダウンロード（配信）に関して、排他制御を行うことができる。なお、本実施の形態において、配信とは、送信元から見た用語であり、ダウンロードとは、配信先から見た用語である。したがって、配信とダウンロードとは、処理内容としては同じことを意味する。
【００３１】
なお、配信元装置１０は、ファームウェアファイルｆ１の送信中に、ダウンロード開始要求メッセージｍ４ａを予想外に重複して受信したとしても、重複受信したダウンロード開始要求メッセージｍ４ａについては無視する。
【００３２】
ノードＮ０ａは、ファームウェアファイルダウンロードが完了すると、ダウンロード要求待ち通知メッセージを１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１０９）。ダウンロード要求待ち通知メッセージとは、以降において自らがファームウェアファイルの送信元となりうることを隣接ノードに通知するためのメッセージである。なお、本実施の形態において、隣接ノードとは、１ホップ区間内のノードをいう。
【００３３】
図９は、ダウンロード要求待ち通知メッセージの第一の送信例を示す図である。同図に示されるように、ダウンロード要求待ち通知メッセージｍ５ａは、１ホップ区間限定であるため、１ホップ区間内のノードＮ０ｂ、Ｎ１ｈ、Ｎ２ａ、及び配信元装置１０によって受信され、２ホップ区間以上にはホップされない。
【００３４】
ダウンロード要求待ち通知メッセージｍ５ａを受信した各ノードＮは、隣接ノードにファームウェアファイルの配信元が存在することを検知し、メッセージｍ５ａの送信元の宛先情報を記憶する。一方、配信元装置１０は、ダウンロード要求待ち通知メッセージｍ５ａを受信しても無視する。すなわち、宛先情報を記憶するのは、ノードＮのみである。なお、各ノードＮにおいて、保持される宛先情報の数に上限が設けられてもよい。例えば、上限が３である場合、各ノードＮは、３回目以内のダウンロード要求待ち通知メッセージｍ５に関しては宛先情報を保持し、４回目以降のダウンロード要求待ち通知メッセージｍ５については無視する。または、４回目以降のダウンロード要求待ち通知メッセージｍ５が受信された場合は、古い宛先情報から順に破棄され、新たに受信されたダウンロード要求待ち通知メッセージｍ５ａの送信元の宛先情報が保持されてもよい。
【００３５】
ダウンロード要求待ち通知メッセージｍ５ａの送信の成功により、ノードＮ０ａへのファームウェアファイルｆ１のダウンロード（配信）は終了する。そこで、ノードＮ０ａは、受信通知メッセージを、配信元装置１０にユニキャストで送信する（Ｓ１１０）。
【００３６】
図１０は、受信通知メッセージの第一の送信例を示す図である。同図には、ノードＮ０ａから配信元装置１０に対して受信通知メッセージｍ６ａが送信されている例が示されている。
【００３７】
受信通知メッセージｍ６ａを受信した配信元装置１０は、受信通知メッセージｍ６ａの送信元（ノードＮ０ａ）の識別情報を配信先リストより削除する。すなわち、ノードＮ０ａについては、ファームウェアファイルｆ１を送信済みであることが記録される。
【００３８】
続いて、配信元装置１０は、配信先リストにおいてノードＮ０ａの次にエントリされているノードＮ０ｂに対して、ダウンロード許可メッセージｍ３ｂをユニキャストで送信する（図３：Ｓ１１１）。
【００３９】
図１１は、ダウンロード許可メッセージの第二の送信例を示す図である。同図には、ノードＮ０ｂに対して、ダウンロード許可メッセージｍ３ｂが送信されている例が示されている。
【００４０】
ダウンロード許可メッセージｍ３ｂを受信したノードＮ０ｂは、ファームウェアファイルｆ１を保有しているノードＮ０ａの宛先情報を保持している。すなわち、ノードＮ０ｂの隣接ノードの中には、配信対象のファームウェアファイルを保有しているノードＮが存在する。そこで、ノードＮ０ｂは、配信元装置１０に対してではなく、当該宛先情報に係るノードＮ０ａに対してダウンロード開始要求メッセージｍ４ｂをユニキャストで送信する（Ｓ１１２）。また、ノードＮ０ｂは、配信元装置１０に対しては、ダウンロード開始通知メッセージをユニキャストで送信する（Ｓ１１３）。ダウンロード開始通知メッセージは、ダウンロード許可メッセージｍ３ｂの受信が成功して、隣接ノードからのダウンロードを開始することを示すメッセージである。
【００４１】
図１２は、隣接ノードへのダウンロード開始要求メッセージの送信例を示す図である。同図には、ノードＮ０ｂからノードＮ０ａに対してダウンロード開始要求メッセージｍ４ｂが送信されている例が示されている。また、ノードＮ０ｂから配信元装置１０に対してダウンロード開始通知メッセージｍ７ｂが送信されている例が示されている。
【００４２】
配信元装置１０は、ダウンロード開始通知メッセージｍ７を受信した場合、隣接ノードからダウンロードが行われるものと判断し、ファームウェアファイルの送信は行わない。なお、仮に、ノードＮ０ｂが、ファームウェアファイルを保有している隣接ノードの宛先情報を保持していない場合、ノードＮ０ｂは、配信元装置１０に対して、ダウンロード開始要求メッセージを送信する。この場合、ノードＮ０ｂに関して、ステップＳ１０８〜Ｓ１１０と同様の処理が実行される。
続いて、ダウンロード開始要求メッセージｍｂ４を受信したノードＮ０ａは、ダウンロード開始要求メッセージｍｂ４の送信元のノードＮ０ｂに、ファームウェアファイルｆ１をユニキャストで送信する（Ｓ１１４−１〜Ｓ１１４−ｎ）。
【００４３】
図１３は、隣接ノードからのファームウェアファイルの送信例を示す図である。同図には、ノードＮ０ａからノードＮ０ｂに対してファームウェアファイルｆ１が送信されている例が示されている。ファームウェアファイルｆ１は、ノードＮ０ａが、配信元装置１０よりダウンロードしたものである。
【００４４】
ノードＮ０ｂは、ファームウェアファイルｆ１のダウンロードが完了すると、ダウンロード要求待ち通知メッセージｍ５ｂを１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１１５）。すなわち、ノードＮ０ｂがファームウェアファイルの送信元となりうることが隣接ノードに通知される。
【００４５】
図１４は、ダウンロード要求待ち通知メッセージの第二の送信例を示す図である。同図に示されるように、ダウンロード要求待ち通知メッセージｍ５ｂは、１ホップ区間限定であるため、１ホップ区間内のノードＮ０ａ、Ｎ１ｃ、Ｎ２ｂ、Ｎ２ａ、Ｎ２ｃ及び配信元装置１０によって受信され、２ホップ区間以上にはホップされない。ダウンロード要求待ち通知メッセージｍ５ｂを受信した各ノードＮは、隣接ノードにファームウェアファイルｆ１の配信元が存在することを検知し、ダウンロード要求待ち通知メッセージｍ５ｂの送信元の宛先情報を上限の範囲内で記憶する。一方、配信元装置１０は、ダウンロード要求待ち通知メッセージｍ５ｂを受信しても無視する。
【００４６】
ダウンロード要求待ち通知メッセージｍ５ｂの送信の成功により、ノードＮ０ｂへのファームウェアファイルｆ１のダウンロード（配信）は終了する。そこで、ノードＮ０ｂは、受信通知メッセージｍ６ｂを、ファームウェアファイルｆ１のダウンロード元であるノードＮ０ａと配信元装置１０との双方にユニキャストで送信する（Ｓ１１８ａ、Ｓ１１８ｂ）。
【００４７】
図１５は、受信通知メッセージの第二の送信例を示す図である。同図には、ノードＮ０ａ及び配信元装置１０の双方に対してノードＮ０ｂから受信通知メッセージｍ６ｂが送信されている例が示されている。
【００４８】
受信通知メッセージｍ６ｂを受信した配信元装置１０は、受信通知メッセージｍ６ｂの送信元（ノードＮ０ｂ）の識別情報を配信先リストより削除する。すなわち、ノードＮ０ｂについては、ファームウェアファイルｆ１を送信済みであることが記録される。
【００４９】
なお、ファームウェアファイルｆ１を隣接ノードからダウンロードした場合に、受信通知メッセージｍ６ｂを配信元装置１０にも送信するのは、配信元装置１０に配信済みのノードＮを知らせるためである。すなわち、配信元装置１０が、未配信又は配信済みのノードＮを把握し、配信システム１における配信が、排他的又は選択的に行われるようにするためである。その結果、輻輳による周辺の無線帯域の枯渇を防止することができる。
【００５０】
その後、配信元装置１０の配信先リストに登録されている、ノードＮ０ｃ〜Ｎ０ｈに関しても、１ノードＮずつ順番に、上記した手順によって配信元装置１０又は隣接ノードからファームウェアファイルｆ１がユニキャストで配信される。
【００５１】
配信元装置１０は、配信先リストに登録されている全てのノードＮに対してファームウェアファイルの配信が終了すると、再確認のために、配信先確認メッセージｍ１を、１ホップ区間限定のブロードキャストで送信する（Ｓ１１８ａ、Ｓ１１８ｂ）。既にファームウェアファイルｆ１を受信している各ノードＮ０は、配信先確認メッセージｍ１に対して応答は行わない。なお、配信元装置１０は、この後に予想外の受信通知メッセージｍ６を受信したとしても、当該受信通知メッセージｍ６を無視して、処理を継続する。
【００５２】
配信先確認メッセージｍ１の送信後、所定時間（例えば、３０秒等）が経過すると、配信元装置１０は、１ホップ区間内のノードＮ０群については、ファームウェアファイルｆ１の配信は完了したと判断する。そこで、配信元装置１０は、探索範囲を１段階（すなわち、１ホップ）拡張する。具体的には、配信元装置１０は、２ホップ区間限定（すなわち、ホップ数＝１）の配信先確認メッセージｍ１をブロードキャストで送信する（Ｓ１１９ａ、Ｓ１１９ｂ）。例えば、ステップＳ１１９ａでは、ノードＮ０ａからのホップによってノードＮ１ａに配信先確認メッセージｍ１が到達する。また、ステップＳ１１９ｂでは、ノードＮ０ｂからのホップによってノードＮ１ｂに配信先確認メッセージｍ１が到達する。
【００５３】
図１６は、２ホップ区間限定の配信先確認メッセージの送信例を示す図である。同図には、各ノードＮ０からのホップによって、各ノードＮ１に対して配信先確認メッセージｍ１が送信されている例が示されている。但し、２ホップ区間限定であるため、３ホップ区間以上にはホップされない。なお、配信元装置１０は、この後に予想外の受信通知メッセージを受信しても、当該メッセージを無視して、処理を継続する。
【００５４】
配信先確認メッセージｍ１を受信したノードＮ１群の中で、配信対象のファームウェアを適用する必要のある各ノードＮ１は、配信先確認メッセージｍ１の送信元に、配信先応答メッセージｍ２をユニキャストで返信する（Ｓ１２０ａ、Ｓ１２０ｂ）。
【００５５】
以降、ノードＮ１群に関して、ノードＮ０群と同様に、ファームウェアファイルの配信が行われる。その後、探索範囲が３ホップ区間内、４ホップ区間内、５ホップ区間内と１ホップずつ拡張され、全ノードＮへのファームウェアファイルｆ１の配信が完了する。探索範囲が拡張されても、配信先確認メッセージｍ１及びダウンロード許可メッセージｍ３は配信元装置１０から送信される。また、ダウンロード開始通知メッセージｍ７及び受信通知メッセージｍ６は、配信元装置１０に送信される。
【００５６】
なお、探索範囲のホップ数の上限は、例えば、配信元装置１０に対する設定によって変更可能とされてもよい。既定値として、例えば、３０ホップが設定されていてもよい。
【００５７】
上述したように、本実施の形態によれば、配信先のノードＮの探索範囲は、段階的に拡張されて、段階ごとに、探索されたノードＮに対して配信が行われる。そして、既に配信を受けたノードＮは、配信元になることができる。したがって、隣接ノード間でのファームウェアファイルｆ１の転送（又はダウンロード）を実現することができる。
【００５８】
探索範囲の段階的な拡張と隣接ノード間（特に、前の段階の探索範囲に含まれるノードＮと次の段階の探索範囲に含まれるノードＮとの間）での転送とにより、多重ホップによってファームウェアファイルｆ１が転送される可能性を低減させることができる。換言すれば、ファームウェアファイルｆ１の転送に関して、多重度の増加を抑制することができる。
【００５９】
また、或る時点において配信元及び配信先となるノードＮは、配信元装置１０によって排他的に管理される。したがって、複数のノードＮに対するダウンロード元が、同時期に一つのノードＮに集中することによる、局所的なネットワーク負荷の増加を回避することができる。その結果、無線周波数帯域が小さい通信方式であっても、効率的にファームウェアｆ１の配信を行うことができる。
【００６０】
上記の結果、ネットワークの擾乱の発生を抑制することができ、その結果として、多重ホップのブロードキャストによってファームウェアファイルｆ１を配信する場合に比べて、短時間での配信の完了が期待できる。
【００６１】
続いて、上記した配信方法を実現するための配信元装置１０及びノードＮに関して更に具体的に説明する。
【００６２】
図１７は、本発明の実施の形態における配信元装置のハードウェア構成例を示す図である。図１７の配信元装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、不揮発性メモリ１０２、揮発性メモリ１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００６３】
配信元装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して不揮発性メモリ１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。不揮発性メモリ１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００６４】
揮発性メモリ１０３は、プログラムの起動指示があった場合に、不揮発性メモリ１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、揮発性メモリ１０３に格納されたプログラムに従って配信元装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００６５】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、不揮発性メモリ１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び不揮発性メモリ１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。但し、配信元装置１０は、必ずしもドライブ装置１０１を有していなくてもよい。
【００６６】
なお、各ノードＮは、配信元装置１０と同様のハードウェアを有していればよい。
【００６７】
図１８は、第一の実施の形態の配信元装置の機能構成例を示す図である。同図において、配信元装置１０は、ファームウェア受信部１１、配信先探索部１２、ダウンロード許可部１３、配信部１４、及び終了検知部１５等を有する。これら各部は、配信元装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理により実現される。また、配信元装置１０は、配信先リスト記憶部１６を有する。配信先リスト記憶部１６は、例えば、揮発性メモリ１０３又は不揮発性メモリ１０２を用いて実現可能である。
【００６８】
ファームウェア受信部１１は、ダウンロードサーバ３０よりファームウェアファイルｆ１を受信する。
【００６９】
配信先探索部１２は、ファームウェアファイルｆ１の配信先となるノードＮを探索する。配信先探索部１２は、探索されたノードＮの識別情報を配信先リスト記憶部１６に記録する。上記したように、配信先探索部１２は、探索範囲を複数段階に拡張させ、各段階においてノードＮを探索する。本実施の形態において、探索範囲は、ホップ数によって規定される。但し、探索範囲の基準又は単位は通信方式に応じて適宜変更されてもよい。
【００７０】
ダウンロード許可部１３は、配信先探索部１２によって探索された各ノードＮに対して、順番に又は排他的に配信の許可（すなわち、ダウンロード許可メッセージｍ３）を通知する。配信部１４は、ダウンロードファイルｆ１をノードＮに送信する。終了検知部１５は、ノードＮごとに、ファームウェアファイルｆ１の送信の終了を検知する。
【００７１】
図１９は、第一の実施の形態のノードの機能構成例を示す図である。同図において、ノードＮは、配信元検知部２０１、配信要求部２０２、ダウンロード部２０３、配信元通知部２０４、受信通知部２０５、リセット部２０６、開始要求受信部２０７、配信部２０８、及び終了検知部２０９等を有する。これら各部は、ノードＮにインストールされたプログラム（例えば、ファームウェア）がノードＮのＣＰＵに実行させる処理により実現される。また、ノードＮは、宛先情報記憶部２１０を有する。宛先情報記憶部２１０は、ノードＮの揮発性メモリ又は不揮発性メモリを用いて実現可能である。
【００７２】
配信元検知部２０１は、配信先確認メッセージｍ１又はダウンロード要求待ち通知メッセージｍ６等の受信に基づいて、ファームウェアファイルｆ１の配信先の存在を検知する。配信元検知部２０１は、ダウンロード要求待ち通知メッセージｍ６が受信された場合は、ダウンロード要求待ち通知メッセージｍ６の送信元の宛先情報を宛先情報記憶部２１０に記録する。
【００７３】
配信要求部２０２は、配信対象のファームウェアファイルｆ１の配信を受けたい場合に、配信確認応答メッセージｍ２を、配信先確認メッセージｍ１の送信元に送信する。
【００７４】
ダウンロード部２０３は、配信先確認メッセージｍ１又はダウンロード要求待ち通知メッセージｍ６の送信元からファームウェアファイルｆ１をダウンロードする。宛先情報記憶部２１０に少なくとも一つの宛先情報が記録されている場合、ダウンロード部２０３は、当該宛先情報に係るノードＮからファームウェアファイルｆ１をダウンロードする。
【００７５】
配信元通知部２０４は、ファームウェアファイルｆ１のダウンロードが完了した後、自ノードＮが配信元となりうることを隣接ノードに通知するため、ダウンロード要求待ち通知メッセージｍ６を送信する。
【００７６】
受信通知部２０５は、ファームウェアファイルｆ１の配信元及び配信元装置１０に対して、ファームウェアファイルｆ１の受信が完了したことを示す受信通知メッセージｍ６を送信する。
【００７７】
リセット部２０６は、ファームウェアファイルｆ１に格納されているファームウェアによる更新を有効とするために、ノードＮのリセットを実行する。リセットとは、例えば、ノードＮの再起動をいう。
【００７８】
開始要求受信部２０７は、他のノードＮから、ダウンロード開始要求メッセージｍ４を受信する。配信部２０８は、ダウンロード開始要求メッセージｍ４の送信元に対して、ファームウェアファイルｆ１を送信する。終了検知部１５は、ファームウェアファイルｆ１の送信の終了を検知する。
【００７９】
以下、配信元装置１０及びノードＮのそれぞれの処理手順について説明する。図２０は、第一の実施の形態の配信元装置の処理手順の一例を説明するためのフローチャートである。なお、同図において、配信元装置１０は、既にダウンロードサーバ３０よりファームウェアファイルｆ１をダウンロード済みであるとする。すなわち、図２のステップＳ１０１〜Ｓ１０３は実行済みの状態であるとする。
【００８０】
配信開始日時が到来すると、配信先探索部１２は、配信先確認メッセージｍ１のホップ数Ｈは、上限値以下であるか否かを判定する（Ｓ２０１）。図２０の開始時点にいて、ホップ数Ｈの初期値は「０」である。また、上限値は、例えば、不揮発性メモリ１０２に記録されている。
【００８１】
ホップ数Ｈが上限値以下である場合（Ｓ２０１でＹｅｓ）、配信先探索部１２は、配信先確認メッセージｍ１（図４参照）を、ホップ数Ｈのホップ区間限定のブロードキャストで送信する（Ｓ２０２）。
【００８２】
図２１は、配信先確認メッセージの構成例を示す図である。同図において、配信先確認メッセージｍ３は、ヘッダ部とデータ部とを含む。ヘッダ部は、各メッセージに共通の部分であり、メッセージ種別、データ長、送信元ＭＡＣアドレス、及び送信先ＭＡＣアドレス等を含む。
【００８３】
メッセージ種別は、メッセージの種別である。配信先確認メッセージｍ１に関しては、配信先確認メッセージｍ１であることがメッセージ種別に指定される。データ長は、データ部のデータ長である。送信元ＭＡＣアドレスは、メッセージの送信元のＭＡＣアドレスである。送信先ＭＡＣアドレスは、メッセージの送信元のＭＡＣアドレスである。送信先ＭＡＣアドレスは、メッセージの送信先のＭＡＣアドレスである。配信先確認メッセージｍ１は、ブロードキャストであるため、送信先ＭＡＣアドレスには、ブロードキャストアドレスが指定される。
【００８４】
一方、データ部は、メーカＩＤ、対象ノード識別子、ファーム形式、ファームバージョン、及び対象外ファーム保持要否等を含む。メーカＩＤは、配信対象のファームウェアの適用対象となるノードＮのメーカの識別子である。本実施の形態の配信システム１には、相互に異なるメーカによって製造された装置がノードＮとして含まれている場合も想定している。配信対象のファームウェアの適用対象のメーカと異なるメーカのノードＮは、当該ファームウェアの適用対象とはならない。
【００８５】
対象ノード識別子は、配信対象のファームウェアの適用対象となるノードＮの種別の識別子である。ノードＮの種別とは、ノードＮの機能に基づく種別である。例えば、スマートメータと中継装置とでは、種別が異なる。
【００８６】
ファーム形式は、ファームウェアファイルｆ１の形式を示す情報である。例えば、ファームウェアファイルｆ１に含まれているデータが、ファームウェア全体であるのか、更新部分のみであるのか、圧縮されているのか、暗号化されているのか等を示す情報である。
【００８７】
ファームウェアバージョンとは、ファームウェアファイルｆ１に含まれているファームウェアのバージョンである。
【００８８】
対象外ファーム保持要否は、各ノードＮが、当該ノードＮにとって適用対象外のファームウェアに係るファームウェアファイルｆ１を保持する必要が有るか否かを示す情報である。各ノードＮにとって適用対象であるか否かは、メーカＩＤ、対象ノード識別子、及びファームバージョンによって判定される。なお、ファームウェアファイルｆ１を保持する必要が有るか否かは、当該ファームウェアファイルｆ１の配信の中継を行う必要が有るか否かと同義である。
【００８９】
なお、ヘッダ部は、各メッセージで共通であるため、以降で説明するメッセージについては、便宜上、データ部のみを示す。また、ホップ数については、より下位のレベル（配信元装置１０及び各ノードＮが利用する通信プロトコルのレベル）において管理されているため、図２１には含まれていない。
【００９０】
続いて、配信先探索部１２は、配信先応答メッセージｍ２の受信待ちのタイマを設定する（Ｓ２０３）。例えば、３０秒後にタイマが設定される。配信先応答メッセージｍ２の受信待ちの間（Ｓ２０４でＹｅｓ）、配信先探索部１２は、配信先確認メッセージｍ１に応じて返信される配信先応答メッセージｍ２（図５参照）を受信する（Ｓ２０５）。
【００９１】
受信された配信先応答メッセージｍ２の数が、配信先リスト記憶部１６の上限以内である場合（Ｓ２０６でＹｅｓ）、配信先探索部１２は、受信された配信先応答メッセージｍ２に含まれている、送信元ＭＡＣアドレスを配信先リストのエントリ（配信先情報）として配信先リスト記憶部１６に記録する（Ｓ２０７）。一方、受信された配信先応答メッセージｍ２の数が、配信先リスト記憶部１６の上限を超えた場合（Ｓ２０６でＮｏ）、配信先探索部１２は、配信先応答メッセージｍ２の受信待ちタイマを解除して（Ｓ２０８）、ステップＳ２１１に進む。
【００９２】
配信先応答メッセージの受信待ちの期限が到来すると（Ｓ２０４でＮｏ）、配信先探索部１２は、配信先リスト記憶部１６に配信先情報が記録されているか否かを判定する（Ｓ２０９）。配信先情報が記録されていない場合（Ｓ２０９でＮｏ）、配信先探索部１２は、ホップ数Ｈに１を加算し（Ｓ２１０）、ステップＳ２０１以降を繰り返す。すなわち、配信先となるノードＮの探索範囲が拡張される。
【００９３】
一方、配信先リスト記憶部１６に配信先情報が記録されている場合（Ｓ２０９でＹｅｓ）、ステップＳ２１１に進む。
【００９４】
以上で、ホップ数Ｈ＋１区間内において、配信先となるノードＮの探索は終了する。続いて、探索された各ノードＮに順番に配信するための処理が行われる。
【００９５】
ステップＳ２１１において、ダウンロード許可部１３は、配信先リスト記憶部１６に記録されている配信先情報の中から一つの配信先情報を選択し、当該配信先情報を送信先ＭＡＣアドレスとするダウンロード許可メッセージｍ３を送信する。例えば、配信先リスト記憶部１６への記録順に一つの配信先情報が選択される。但し、複数の配信先情報が選択され、各配信先情報を送信先ＭＡアドレスとする、複数のダウンロード許可メッセージｍ３がほぼ同時に送信されてもよい。例えば、配信先リスト記憶部１６に記憶されている全ての配信先情報のそれぞれに関して、ダウンロード許可メッセージｍ３がほぼ同時に送信されてもよい。
【００９６】
図２２は、ダウンロード許可メッセージのデータ部の構成例を示す図である。同図において、ダウンロード許可メッセージｍ３は、リセット日時、分割数、ブロック長、ファーム形式、及び対象外ファーム保持要否等を含む。
【００９７】
リセット日時は、配信対象のファームウェアを有効にする日時である。例えば、当該ファームウェアを適用したノードＮがリセット（又は再起動）する日時である。すなわち、リセット日時は、ファームウェアファイルｆ１の配信を受けた各ノードＮにおいて、新しいファームウェアが有効となる日時を一致させ、ノードＮ間における不整合の発生を回避するためのパラメータである。
【００９８】
分割数は、ファームウェアファイルｆ１を複数ブロックに分割して配信する際の分割数である。ブロック長は、一ブロックのデータ長（サイズ）である。ファーム形式及び対象外ファーム保持要否の意味は、配信先確認メッセージｍ１における同一名のパラメータと同じである。
【００９９】
続いて、配信部１４は、ダウンロード許可メッセージｍ３を受信したノードＮから、ダウンロード開始要求メッセージｍ４（図７参照）又はダウンロード開始通知メッセージｍ７（図１２参照）を受信する（Ｓ２１２）。ダウンロード開始要求メッセージｍ４又はダウンロード開始通知メッセージｍ７のいずれが受信されるかは、ダウンロード許可メッセージｍ３を受信したノードＮ（配信先のノードＮ）のファームウェアファイルｆ１のダウンロード元（配信元）に応じて異なる。
【０１００】
すなわち、ダウンロード開始要求メッセージｍ４が受信された場合（Ｓ２１３でＹｅｓ）、当該ダウンロード元は配信元装置１０である。そこで、配信部１４は、ファームウェアファイルｆ１（図８参照）を配信先のノードＮに送信する（Ｓ２１４）。
【０１０１】
図２３は、第一の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。同図に示されるように、当該データ部は、ブロック番号、ブロック長、及びブロック等を含む。
【０１０２】
ブロック番号は、ファームウェアファイルｆ１がブロック単位に分割された場合の各ブロックの順番を示す。ブロック長は、一ブロックのデータ長である。ブロックは、ブロックの実体である。
【０１０３】
ステップＳ２１４では、ファームウェアファイルｆ１は、ダウンロード許可メッセージｍ３に指定されている分割数分のブロックに分割される。そして、分割数分だけ図２３に示されるデータ部を有するメッセージが、配信元装置１０から配信先のノードＮに繰り返し送信される。
【０１０４】
なお、ダウンロード許可メッセージｍ３が、複数のノードＮに対してほぼ同時に送信されている場合、配信部１４は、複数のノードＮからダウンロード開始要求メッセージｍ４を受信する可能性がある。但し、配信部１４は、例えば、最初に受信されたダウンロード開始要求メッセージｍ４の送信元であるノードＮにファームウェアファイルｆ１の送信を行い、他のノードＮからのダウンロード開始要求メッセージｍ４は無視する。すなわち、第一の実施の形態では、一つの配信元（配信元装置１０又は配信済みのノードＮ）から同時に配信先とされるノードＮの数は、１である。
【０１０５】
なお、ダウンロード開始要求メッセージｍ４を無視されたノードＮは、ダウンロード開始要求メッセージｍ４の送信時から所定時間経過してもファームウェファイルｆ１が受信されないことに基づいて、タイムアウトを検知する。タイムアウトを検知したノードＮは、次回のダウンロード許可メッセージｍ３の受信を待機する。
【０１０６】
一方、ダウンロード開始通知メッセージｍ７が受信された場合（Ｓ２１３でＮｏ）、当該ダウンロード元は、配信元装置１０ではない。したがって、配信部１４はファームウェアファイルｆ１の送信は行わない。
【０１０７】
この場合、複数のノードＮに対してダウンロード許可メッセージｍ３が送信されているときは、複数のノードＮのそれぞれが、各ノードの宛先情報記憶部２１０に記憶している宛先情報に係る他のノードに対してダウンロード開始要求メッセージｍ３を送信している。並行して送信されたダウンロード開始要求メッセージｍ３の送信先が相互に重複しない場合、各ノードＮ間で並列的にファームウェアファイルｆ１の配信（ダウンロード）が行われる。一方、ダウンロード開始要求メッセージｍ３を重複して受信したノードＮは、例えば、最初に受信されたダウンロード開始要求メッセージｍ４の送信元であるノードＮにファームウェアファイルｆ１の送信を行い、他のノードＮからのダウンロード開始要求メッセージｍ４は無視する。ダウンロード開始要求メッセージｍ４を無視されたノードＮは、ダウンロード開始要求メッセージｍ４の送信時から所定時間経過してもファームウェファイルｆ１が受信されないことに基づいて、タイムアウトを検知する。タイムアウトを検知したノードＮの宛先情報記憶部２１０において、別の宛先情報が記憶されている場合、当該ノードＮは、当該別の宛先情報に係るノードＮに対して、ダウンロード開始要求メッセージｍ４を送信する。
【０１０８】
このように、ダウンロード許可メッセージｍ３がほぼ同時に複数のノードＮに送信されることで、ノードＮ間におけるファームウェアファイルｆ１の配信の並列化を可能とすることができる。その結果、ダウンロード許可メッセージｍ３が一つのノードＮにしか送信されない場合に比べて、ファームウェアファイルｆ１の配信効率を向上させることができる。
【０１０９】
ステップＳ２１４又はＳ２１３でＮｏの場合に続いて、終了検知部１５は、受信通知メッセージｍ６の受信を待機する。受信通知メッセージｍ６（図１０及び図１５参照）が受信されると（Ｓ２１５）、終了検知部１５は、受信通知メッセージｍ６の送信元であるノードＮに係る配信先情報を配信リスト記憶部より削除する（Ｓ２１６）。
【０１１０】
続いて、ダウンロード許可部１３は、配信先リスト記憶部１６に配信先情報が残っているか否かを判定する（Ｓ２１７）。配信先情報が残っている場合（Ｓ２１７でＹｅｓ）、ステップＳ２１１以降が繰り返される。すなわち、ホップ数Ｈのホップ区間内で探索された他のノードＮに対してファームウェアファイルｆ１の配信が行われる。
【０１１１】
一方、配信先情報が残っていない場合（Ｓ２１７でＮｏ）、配信先探索部１２は、ホップ数Ｈに１を加算し（Ｓ２１８）、ステップＳ２０１以降を繰り返す。すなわち、配信先となるノードＮの探索範囲が拡張される。
【０１１２】
続いて、各ノードＮが実行する処理手順について説明する。図２４は、第一の実施の形態のノードが実行するダウンロード処理の処理手順の一例を説明するためのフローチャートである。同図では、或る一つのノードＮに注目して説明する。
【０１１３】
配信元検知部２０１が、配信先確認メッセージｍ１を受信すると（Ｓ３０１）、配信要求部２０２は、配信対象のファームウェアが自ノードの適用対象であるか否かを判定する（Ｓ３０２）。すなわち、配信先確認メッセージｍ１（図２１）に含まれている、メーカＩＤ及び対象ノード識別子に自ノードが合致するか判定される。合致する場合、配信先確認メッセージｍ１（図２１）に含まれているファームバージョンが、自ノードに適用されているファームウェアのバージョンより新しいかが判定される。
【０１１４】
配信対象のファームウェアが自ノードの適用対象である場合（Ｓ３０２でＹｅｓ）、配信要求部２０２は、既に当該ファームウェアのファームウェアファイルｆ１を受信済み（ダウンロード済み）であるか否かを判定する（Ｓ３０３）。ファームウェアファイルｆ１を受信済みである場合（Ｓ３０３でＮｏ）、図２４の処理は終了する。一方、ファームウェアファイルｆ１を受信済みでない場合（Ｓ３０３でＹｅｓ）、ステップＳ３０５に進む。
【０１１５】
また、配信対象のファームウェアが自ノードの適用対象でない場合（Ｓ３０２でＮｏ）、配信要求部２０２は、配信先確認メッセージｍ１に含まれている、対象外ファーム保持要否の値が「要」であるか否かを判定する（Ｓ３０４）。対象外ファーム保持要否の値が「否」である場合（Ｓ３０４でＮｏ）、ファームウェアファイルｆ１の保持の必要は無いため、図２４の処理は終了する。一方、対象外ファーム保持要否の値が「要」である場合（Ｓ３０４でＹｅｓ）、ステップＳ３０５に進む。
【０１１６】
ステップＳ３０５において、配信要求部２０２は、配信先応答メッセージｍ２（図５参照）をユニキャストで配信元装置１０に送信する（Ｓ３０５）。続いて、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の受信を待機する。ダウンロード許可メッセージｍ３が受信されると（Ｓ３０６）、ダウンロード部２０３は、宛先情報記憶部２１０に宛先情報が記録されているか否かを判定する（Ｓ３０７）。すなわち、ファームウェアファイルｆ１を既にダウンロード済みの隣接ノードの存否が確認される。
【０１１７】
宛先情報記憶部２１０に宛先情報が記録されてない場合（Ｓ３０７でＮｏ）、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の送信元（すなわち、配信元装置１０）に、ダウンロード開始要求メッセージｍ４（図７参照）をユニキャストで送信する（Ｓ３０８）。
【０１１８】
一方、宛先情報記憶部２１０に宛先情報が記録されている場合（Ｓ３０７でＹｅｓ）、ダウンロード部２０３は、いずれかの宛先情報に係るノードＮに対してダウンロード開始要求メッセージｍ４（図１２参照）をユニキャストで送信する（Ｓ３０９）。続いて、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の送信元（すなわち、配信元装置１０）に、ダウンロード開始通知メッセージｍ７（図１２参照）をユニキャストで送信する（Ｓ３１０）。
【０１１９】
ステップＳ３０８又はＳ３１０に続いて、ダウンロード部２０３は、配信元装置１０又は隣接ノードから送信されるファームウェアファイルｆ１を受信する（Ｓ３１１）。上記したように、ファームウェアファイルｆ１は、ブロック単位に分割されて複数回にわたって送信される。なお、受信されたファームウェアファイルｆ１は、例えば、揮発性のメモリに保持される。
【０１２０】
なお、ダウンロード部２０３は、ステップＳ３０９において、宛先情報に係るノードＮに対してダウンロード開始要求メッセージｍ４を送信した場合、所定時間待機しても当該送信先からファームウェアファイルｆ１が送信されてこないときは、タイムアウトを検知する。タイムアウトの検知に応じ、ダウンロード部２０３は、宛先情報記憶部２１０に別の宛先情報が記憶されている場合は、当該別の宛先情報に基づいてステップＳ３０９以降を繰り返す。ステップＳ３０９以降を繰り返した結果、全ての宛先情報に関してタイムアウトを検知した場合、ダウンロード部２０３は、次回のダウンロード許可メッセージｍ３の受信を待機する。タイムアウトが検知されるような状況は、例えば、ダウンロード開始要求メッセージｍ４の送信先のノードＮが、他のノードＮに対して、ファームウェアファイルｆ１を送信中である場合に発生する。
【０１２１】
続いて、ダウンロード部２０３は、ファームウェアファイルｆ１に係るファームウェアが自ノードへの適用対象であるか否かを判定する（Ｓ３１２）。当該判定は、ステップＳ３０６において受信されたダウンロード許可メッセージｍ３に含まれている、メーカＩＤ、対象ノード識別子、及びファームバージョンに基づいて、ステップＳ３０２と同様の処理内容で実行される。
【０１２２】
当該ファームウェアが適用対象である場合（Ｓ３１２でＹｅｓ）、ダウンロード部２０３は、不揮発性メモリにおいて、既にインストールされているファームウェアに対して、ファームウェアファイルｆ１に格納されているファームウェアを上書き（反映）する（Ｓ３１３）。すなわち、ファームウェアの更新が行われる。上書きは、例えば、ダウンロード許可メッセージｍ３に含まれていたファーム形式に基づいて行われる。ダウンロード部２０３は、また、ファームウェアが更新されたことを示す情報（以下、「更新フラグ」という。）を、例えば、揮発性メモリに記録しておく。更新フラグの内容は、例えば、ダウンロード許可メッセージｍ３に含まれているリセット日時でもよい。
【０１２３】
なお、揮発性メモリにインストールされているファームウェアは、ノードＮの起動時に揮発性メモリにロードされるため、この時点では、上書き前の状態のファームウェアが有効である。したがって、当該ノードＮの動作は、直ちに上書き後のファームウェアに応じたものとはならない。
【０１２４】
続いて、配信元通知部２０４は、ダウンロード要求待ちメッセージｍ６（図９又は図１４参照）を、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ３１４）。
【０１２５】
図２５は、ダウンロード要求待ちメッセージのデータ部の構成例を示す図である。同図において、ダウンロード要求待ちメッセージｍ６のデータ部は、メーカＩＤ、対象ノード識別子、ファーム形式、ファームバージョン、及び対象外ファーム保持要否等を含む。すなわち、ダウンロード要求待ちメッセージｍ６のデータ部の構成は、配信先確認メッセージｍ３のデータ部の構成と同様である。また、ダウンロード要求待ちメッセージｍ６のデータ部の各項目には、配信先確認メッセージｍ３のデータ部の各項目の値が引き継がれる。
【０１２６】
続いて、受信通知部２０５は、配信元装置１０がファームウェアファイルｆ１のダウンロード元であったか否かを判定する（Ｓ３１５）。隣接ノードがダウンロード元であった場合（Ｓ３１５でＮｏ）、受信通知部２０５は、当該隣接ノードに対して、受信通知メッセージｍ６（図１５参照）をユニキャストで送信する（Ｓ３１６）。
【０１２７】
ステップＳ３１５でＹｅｓの場合又はステップＳ３１６に続いて、受信通知部２０５は、配信元装置１０に対して、受信通知メッセージｍ６（図１０又は図１５参照）をユニキャストで送信する（Ｓ３１７）。
【０１２８】
続いて、既にダウンロード済みのノードＮが、他のノードに対してファームウェアファイルｆ１の配信を行う際の処理手順について説明する。
【０１２９】
図２６は、第一の実施の形態のノードが実行する配信処理の処理手順の一例を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。
【０１３０】
開始要求受信部２０７が、他のノードＮから送信されたダウンロード開始要求メッセージｍ４を受信すると（Ｓ３２１）、配信部２０８は、揮発性メモリに記録されているダウンロードファイルｆ１を、当該他のノードＮに送信する（Ｓ３２２）。ファームウェアファイルｆ１は、ブロック単位に分割されて複数回にわたって送信される。ファームウェアファイルｆ１の送信が完了すると、終了検知部２０９は、受信通知メッセージｍ６（図１５参照）を受信する（Ｓ３２３）。
【０１３１】
なお、複数のノードＮに対してダウンロード許可メッセージｍ３がほぼ同時に送信される場合、開始要求受信部２０７は、複数のノードＮからダウンロード開始要求メッセージｍ４を受信する可能性がある。この場合、開始要求受信部２０７は、例えば、最初に受信されたダウンロード開始要求メッセージｍ４以外は無視する。
【０１３２】
続いて、各ノードＮが、既にダウンロード済みのノードＮによるダウンロード要求待ちメッセージｍ６を受信した際に実行する処理手順について説明する。
【０１３３】
図２７は、第一の実施の形態においてダウンロード要求待ちメッセージを受信したノードが実行する処理手順の一例を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。
【０１３４】
配信元検知部２０１は、ダウンロード要求待ちメッセージｍ６を受信すると（Ｓ３３１）、自ノードＮにおいてファームウェアファイルｆ１はダウンロード済みであるか否かを判定する（Ｓ３３２）。すなわち、揮発性メモリにファームウェアファイルｆ１が記録されているか否かが判定される。また、揮発性メモリに記録されているファームウェアファイルｆ１に関するメーカＩＤ、対象ノード識別子、及びファームバージョンと、ダウンロード要求待ちメッセージｍ６に含まれているメーカＩＤ、対象ノード識別子、及びファームバージョンとが一致するか否かが判定されてもよい。
【０１３５】
ダウンロード済みである場合（Ｓ３３２でＮｏ）、図２７の処理は終了する。ダウンロード済みでない場合（Ｓ３３２でＹｅｓ）、配信元検知部２０１は、宛先情報記憶部２１０に既に記録されているエントリ（宛先情報）の数が、上限値未満であるか否か判定する（Ｓ３３３）。当該エントリ数が上限値に達している場合（Ｓ３３３でＮｏ）、図２７の処理は終了する。
【０１３６】
一方、当該エントリ数が上限値未満である場合（Ｓ３３３でＹｅｓ）、配信元検知部２０１は、ダウンロード要求待ちメッセージｍ６に含まれている、送信元ＭＡＣアドレスを宛先情報として宛先情報記憶部２１０に記録する（Ｓ３３４）。
【０１３７】
続いて、ファームウェアファイルｆ１を受信した各ノードＮが、リセット日時の到来に応じて実行する処理について説明する。
【０１３８】
図２８は、リセット日時の到来に応じて各ノードが実行する処理を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。但し、揮発性メモリに更新フラグが記録されていないノードＮは、同図の処理手順は実行しない。更新フラグとは、図２４のステップＳ３１３において記録される、ファームウェアが更新されたことを示す情報である。
【０１３９】
リセット部２０６は、リセット日時の到来を検知すると（Ｓ３５１でＹｅｓ）、当該ノードＮのリセットを実行する（Ｓ３５２）。リセットによって、不揮発性メモリにおいて更新されたファームウェアが揮発性メモリにロードされる。その結果、更新後のファームウェアの制御に基づいて、ノードＮは動作する。
【０１４０】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、第二の実施の形態において特に言及しない点については、第一の実施の形態と同様でよい。
【０１４１】
第二の実施の形態では、図８や図１３に示される状態（すなわち、ファームウェアファイルｆ１の送信時）において、送信元（配信元装置１０又はノードＮ）は、ファームウェアファイルｆ１をブロードキャストで送信する。但し、多重ホップを抑制するため、当該ブロードキャストは、例えば、１ホップ区間限定とされる。その結果、ダウンロード許可メッセージｍ３を受信したノードＮ以外のノードも、ファームウェアファイルｆ１を並行して受信することができる。例えば、図８の状態においては、ノードＮ０ａのみでなく、他のノードＮ０群もファームウェアファイルｆ１を並行して受信する。
【０１４２】
すなわち、そもそもファームウェアファイルｆ１の送信メッセージは、ユニキャストであろうとブロードキャストであろうと、送信先以外の他のノードＮにも到達しているのであるから、他のノードＮにも受信させてしまおうという趣旨である。
【０１４３】
具体的には、第二の実施の形態では、図２０のステップＳ２０５及び図２６のステップＳ３３２において、配信元装置１０の配信部１４又は送信元のノードＮの配信部２０８は、１ホップ区間限定のブロードキャストでファームウェアファイルｆ１を送信する。
【０１４４】
図２９は、第二の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。同図に示されるように、当該データ部は、リセット日時、ファーム形式、対象外ファーム保持要否、ブロック番号、ブロック長、及びブロック等を含む。
【０１４５】
なお、各パラメータの意味は、ダウンロード許可メッセージ（図２２）又はユニキャストによるファームウェアファイルの送信メッセージ（図２３）において同一名のパラメータの意味と同じである。
【０１４６】
ダウンロード許可メッセージｍ３を受信しているノードＮ（例えば、図８のノードＮ０ａ）は、図２４のステップＳ３１０において、１ホップ区間限定のブロードキャストで送信されたファームウェアファイルｆ１を受信する。
【０１４７】
一方、ダウンロード許可メッセージｍ３を受信していないノードＮ（例えば、図８のノードＮ０ｂ〜Ｎ０ｈ）は、当該ブロードキャストが受信された際に、図３０に示される処理を実行する。
【０１４８】
図３０は、第二の実施の形態においてダウンロード許可メッセージを受信していないノードがブロードキャストによるファームウェアファイルを受信した際の処理手順の一例を説明するためのフローチャートである。同図では、ダウンロード許可メッセージを受信していない或るノードＮに注目して説明する。
【０１４９】
ステップＳ４０１において、ダウンロード部２０３は、ファームウェアファイルｆ１に係るブロードキャスト検知する。続いて、ダウンロード部２０３は、ファームウェアファイルｆ１はダウンロード済みであるか否かを判定する（Ｓ４０２）。判定方法は、図２７のステップＳ３３２と同様でよい。
【０１５０】
ダウンロード済みである場合（Ｓ４０２でＮｏ）、図３０の処理は終了する。ダウンロード済みでない場合（Ｓ４０２でＹｅｓ）、ダウンロード部２０３は、ブロック単位で送信されるファームウェアファイルｆ１の受信を継続する（Ｓ４０３）。
【０１５１】
ファームウェアファイルｆ１の受信が終了すると、ダウンロード部２０３は、ファームウェアファイルｆ１に格納されているファームウェアが自ノードの適用対象であるか否かを判定する（Ｓ４０４）。当該判定方法は、図２４のステップＳ３０２と同様でよい。但し、当該ファームウェアのメーカＩＤ、対象ノード識別子、及びファームバージョンは、ファームウェアファイルｆ１内より取得される。または、ブロードキャスト時のファームウェアファイルｆ１の送信メッセージのデータ部に、メーカＩＤ、対象ノード識別子、及びファームバージョンが含まれていてもよい。この場合、ダウンロード部２０３は、ファームウェアファイルｆ１の全ブロックを受信せずとも、一つのブロックを受信することによって、ファームウェアファイルｆ１に格納されているファームウェアが自ノードの適用対象であるか否かを判定することができる。但し、メーカＩＤ、対象ノード識別子、及びファームバージョンの分だけ、各ブロックのデータ量が増加するという不利益はある。
【０１５２】
当該ファームウェアが自ノードの適用対象である場合（Ｓ４０４でＹｅｓ）、ダウンロード部２０３は、不揮発性メモリに既にインストールされているファームウェアを更新する（Ｓ４０５）。すなわち、不揮発性メモリに既にインストールされているファームウェアが、ファームウェアファイルｆ１に格納されているファームウェアによって上書きされる。ダウンロード部２０３は、また、更新フラグを、例えば、揮発性メモリに記録しておく。
【０１５３】
ステップＳ４０４でＮｏの場合又はステップＳ４０５に続いて、配信元通知部２０４は、ダウンロード要求待ちメッセージｍ６（図９又は図１４参照）を、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ４０６）。
【０１５４】
続いて、受信通知部２０５は、配信元装置１０に対して、受信通知メッセージｍ６（図１０又は図１５参照）をユニキャストで送信する（Ｓ４０７）。
【０１５５】
上述したように、第二の実施の形態によれば、ブロードキャストによって、一つのノードＮから複数のノードＮに対して同時にファームウェアファイルｆ１を配信することができる。したがって、第一の実施の形態に比べて、配信システム１全体の配信時間の短縮化を期待することができる。
【０１５６】
また、ファームウェアファイルｆ１の送信時のブロードキャストのホップ数は限定されているため、ファームウェアファイルｆ１が、多重ホップによって転送されるのを回避することができる。
【０１５７】
なお、各実施の形態において、配信先確認メッセージｆ１やダウンロード要求待ち通知メッセージｍ５のホップ数は、１以上であってもよい。ホップ数が増加された場合、ファームウェアファイルｆ１の配信に関して多重ホップが発生する可能性がある。したがって、各実施の形態が適用されるネットワーク環境において、配信処理の効率性に鑑みて、適切なホップ数が選択されればよい。
【０１５８】
また、ダウンロード済みの隣接ノードの存在の検知は、必ずしも当該隣接ノードにより送信されるダウンロード要求待ち通知メッセージｍ５の受信に基づいて行われなくてもよい。例えば、ダウンロード許可メッセージｍ３を受信したノードが、ダウンロード済みの隣接ノードを探索するために、ホップ数が限定されたブロードキャストを送信してもよい。ダウンロード済みの隣接ノードは、当該ブロードキャストに対して応答を行えばよい。当該応答に基づいて、当該ブロードキャストの送信元のノードＮは、ダウンロード済みの隣接ノードの存在を検知することができる。
【０１５９】
また、配信対象とされるデータは、特定の装置のファームウェアでなくてもよい。電子データであれば、あらゆるデータが配信対象となりうる。
【０１６０】
また、各実施の形態は、有線のネットワーク環境に対して適用されてもよい。
【０１６１】
なお、本実施の形態において、配信先探索部１２は、探索部の一例である。ダウンロード許可部１３は、許可部の一例である。配信元検知部２０１は、検知部の一例である。ダウンロード部２０２は、取得部の一例である。
【０１６２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１６３】
以上の説明に関し、更に以下の項を開示する。
（付記１）
データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法であって、
前記配信元装置が、
探索範囲を複数の段階に分けて拡張して配信先装置を探索し、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、
前記配信先装置が、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、
配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する配信方法。
（付記２）
前記他の配信先装置が、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得する処理は、前記ブロードキャストによって送信される前記データを取得する付記１記載の配信方法。
（付記３）
前記検知する処理は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する付記１又は２記載の配信方法。
（付記４）
前記検知する処理は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する付記１乃至３いずれか一項記載の配信方法。
（付記５）
データの配信元装置と複数の配信先装置とを有する配信システムであって、
前記配信元装置は、
探索範囲を複数の段階に分けて拡張して配信先装置を探索する探索部と、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する許可部とを有し、
前記配信先装置は、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知する検知部と、
配信の許可に応じ、前記他の配信先装置より前記データを取得する取得部とを有する配信システム。
（付記６）
前記他の配信先装置は、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得部は、前記ブロードキャストによって送信される前記データを取得する付記５記載の配信システム。
（付記７）
前記検知部は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する付記５又は６記載の配信システム。
（付記８）
前記検知部は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する付記５乃至７いずれか一項記載の配信システム。
【符号の説明】
【０１６４】
１ 配信システム
１１ ファームウェア受信部
１２ 配信先探索部
１３ ダウンロード許可部
１４ 配信部
１５ 終了検知部
１６ 配信先リスト記憶部
１００ ドライブ装置
１０１ 記録媒体
１０２ 不揮発性メモリ
１０３ 揮発性メモリ
１０４ ＣＰＵ
１０５ インタフェース装置
２０１ 配信元検知部
２０２ 配信要求部
２０３ ダウンロード部
２０４ 配信元通知部
２０５ 受信通知部
２０６ リセット部
２０７ 開始要求受信部
２０８ 配信部
２０９ 終了検知部
２１０ 宛先情報記憶部
Ｂ バス
Ｎ ノード
【技術分野】
【０００１】
本発明は、配信方法及び配信システムに関する。
【背景技術】
【０００２】
スマートメータに関して、欧米においては導入が始まっており、日本においても実証実験が開始されている。スマートメータとは、通信機能付きの電力量計をいう。スマートメータは、ネットワークを介して電力利用量等を電力事業者へ報告することができる。スマートメータが各家庭に設置されれば、人手による検針作業を不要とすることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２４２０６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
無線通信機能を有するスマートメータの導入も検討されている。このようなスマートメータに関して、無線通信を利用してファームウェアの配信が可能となれば便利である。例えば、特許文献１に記載された技術を用いて、スマートメータのファームウェアを配信することが考えられる。
【０００５】
しかしながら、特許文献１に記載されている技術では、配信順序を指示したテーブルが予め各サーバに設定される必要がある。したがって、スマートメータのように、随時設置又は撤去が行われる可能性の有るノードを含むネットワーク環境に関して、斯かるテーブルが設定されるのは非効率である。
【０００６】
そこで、ブロードキャストの多重ホップによって、各スマートメータにファームウェアを配信することが考えられる。ブロードキャストであれば、配信先は特定のノードに限定されず、多重ホップによれば、広範囲のノードにファームウェアを配信可能であると考えられるからである。
【０００７】
しかしながら、ＩＥＥＥ８０２．１５．４等の、無線周波数帯域が小さい方式によって、ファームウェアのような比較的大きなサイズのデータをブロードキャストの多重ホップによって転送すると、一時的にネットワークの擾乱が発生する可能性がある。すなわち、通常、大きなサイズのデータは、複数ブロックに分割されて転送される。ブロックごとにブロードキャストの多重ホップが行われる場合、或るブロックに関してネットワークの擾乱が発生すると、該擾乱がおさまるまで次のブロックの配信を待機する必要がある。その待機時間が積み重なることにより、全てのブロックの転送が終了するまでに、長い時間を必要とする可能性がある。
【０００８】
そこで、データの配信を効率化することのできる配信方法及び配信システムの提供を目的とする。
【課題を解決するための手段】
【０００９】
そこで上記課題を解決するため、データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法は、前記配信元装置が、探索範囲を複数の段階に分けて拡張して配信先装置を探索し、前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、前記配信先装置が、当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する。
【発明の効果】
【００１０】
データの配信を効率化することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態における配信システムの構成例を示す図である。
【図２】第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。
【図３】第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。
【図４】１ホップ区間限定の配信先確認メッセージの送信例を示す図である。
【図５】配信先応答メッセージの送信例を示す図である。
【図６】ダウンロード許可メッセージの第一の送信例を示す図である。
【図７】ダウンロード開始要求メッセージ送信例を示す図である。
【図８】ファームウェアファイルの送信例を示す図である。
【図９】ダウンロード要求待ち通知メッセージの第一の送信例を示す図である。
【図１０】受信通知メッセージの第一の送信例を示す図である。
【図１１】ダウンロード許可メッセージの第二の送信例を示す図である。
【図１２】隣接ノードへのダウンロード開始要求メッセージの送信例を示す図である。
【図１３】隣接ノードからのファームウェアファイルの送信例を示す図である。
【図１４】ダウンロード要求待ち通知メッセージの第二の送信例を示す図である。
【図１５】受信通知メッセージの第二の送信例を示す図である。
【図１６】２ホップ区間限定の配信先確認メッセージの送信例を示す図である。
【図１７】本発明の実施の形態における配信元装置のハードウェア構成例を示す図である。
【図１８】第一の実施の形態の配信元装置の機能構成例を示す図である。
【図１９】第一の実施の形態のノードの機能構成例を示す図である。
【図２０】第一の実施の形態の配信元装置の処理手順の一例を説明するためのフローチャートである。
【図２１】配信先確認メッセージの構成例を示す図である。
【図２２】ダウンロード許可メッセージのデータ部の構成例を示す図である。
【図２３】第一の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。
【図２４】第一の実施の形態のノードが実行するダウンロード処理の処理手順の一例を説明するためのフローチャートである。
【図２５】ダウンロード要求待ちメッセージのデータ部の構成例を示す図である。
【図２６】第一の実施の形態のノードが実行する配信処理の処理手順の一例を説明するためのフローチャートである。
【図２７】第一の実施の形態においてダウンロード要求待ちメッセージを受信したノードが実行する処理手順の一例を説明するためのフローチャートである。
【図２８】リセット日時の到来に応じて各ノードが実行する処理を説明するためのフローチャートである。
【図２９】第二の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。
【図３０】第二の実施の形態においてダウンロード許可メッセージを受信していないノードがブロードキャストによるファームウェアファイルを受信した際の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における配信システムの構成例を示す図である。同図の配信システム１において、配信元装置１０は、各ノードへのファームウェアの配信元となる通信装置である。配信元装置１０は、配信対象のファームウェアを、ネットワーク４０を介してダウンロードサーバ３０よりダウンロードする。配信元装置１０は、ダウンロードしたファームウェアを、無線通信を利用してノードＮに配信する。
【００１３】
ダウンロードサーバ３０は、ファームウェアを記憶し、複数の配信システム１に対してファームウェアのダウンロード元となるコンピュータである。
【００１４】
各ノードＮは、無線通信機能を有する通信機器である。本実施の形態において、ノードＮは、配信先装置の一例である。ノードＮの具体例として、スマートメータが挙げられる。この場合、各ノードＮの設置位置は、各家庭である。各家庭の間隔は一様ではないため、スマートメータのみによって配信システム１を構成した場合、いずれのノードＮからも電波が届かないノードＮが存在する可能性がある。したがって、単に無線通信を中継するための中継装置がノードＮとして配置されてもよい。
【００１５】
なお、本実施の形態の配信方法は、各ノードＮの機能には依存しない。したがって、スマートメータ以外の通信機器に、本実施の形態の配信方法が適用されてもよい。
【００１６】
本実施の形態において、各ノードＮの参照番号は、Ｎ［０〜４］［ａ〜ｈ］という形式を有する。［０〜４］は、配信元装置１０からのホップ数を示す。ホップ数とは、配信元装置１０より送信されたメッセージが当該ノードＮに到達するまでに経由する他のノードＮの数である。［ａ〜ｈ］は、同一ホップ数の圏内（同一ホップ区間内）に位置する各ノードＮを識別するための符号である。全てのノードＮを区別しない場合、上記の通り、単に、「ノードＮ」という。また、特定のホップ区間内のノードＮの集合を限定して説明の対象とする場合、例えば、「ノードＮ１」のように、Ｎの後にホップ数が付与される。
【００１７】
第一の実施の形態の配信システム１が実行する、ファームウェアの配信処理の基本的な手順について説明する。図２及び図３は、第一の実施の形態におけるファームウェアの配信処理の基本的な手順の一例を説明するためのシーケンス図である。なお、各シーケンス図には、便宜上、一部のノードＮのみが示されている。
【００１８】
ステップＳ１０１において、ダウンロードサーバ３０は、ＦＴＰ（File Transfer Protocol）等を利用して配信対象のファームウェアを格納したファイル（ファームウェアファイル）を配信元装置１０に転送する。例えば、新しいバージョンのファームウェアの一部又は全部を含むファームウェアファイルがダウンロードされる。続いて、ダウンロードサーバ３０は、ファームウェアの更新開始要求を配信元装置１０に送信する（Ｓ１０２）。更新開始要求には、配信開始日時等が指定されている。続いて、配信元装置１０は、ダウンロードサーバ３０に対して、更新開始要求に対する応答を返信する（Ｓ１０３）。
【００１９】
配信開始日時が到来すると、配信元装置１０は、ファームウェアファイル配信先を探索するために、配信先確認メッセージを、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１０４ａ、Ｓ１０４ｂ）。すなわち、探索範囲が１ホップ区間に限定されて、配信先の探索が行われる。
【００２０】
図４は、１ホップ区間限定の配信先確認メッセージの送信例を示す図である。同図に示されるように、配信先確認メッセージｍ１は、１ホップ区間限定であるため、１ホップ区間内の各ノードＮ０によって受信され、２ホップ区間以上のノードＮにはホップされない。なお、配信先確認メッセージｍ１には、例えば、配信対象のファームウェアの識別情報（バージョン等）が含まれている。
【００２１】
配信先確認メッセージｍ１を受信したノードＮ０群の中で、配信対象のファームウェアを適用する必要のある各ノードＮ０は、配信先確認メッセージｍ１の送信元に、配信先応答メッセージをユニキャストで返信する（Ｓ１０５ａ、Ｓ１０５ｂ）。配信先確認メッセージｍ１の送信元とは、配信元装置１０である。また、配信先応答メッセージは、自らがファームウェアの配信先であることを示すメッセージである。
【００２２】
図５は、配信先応答メッセージの送信例を示す図である。同図では、全てのノードＮ０より、配信先応答メッセージｍ２が返信されている例が示されている。
【００２３】
配信元装置１０は、各配信先応答メッセージｍ２の受信順に、当該配信先応答メッセージｍ２の送信元の各ノードＮ０の識別情報を、配信先リストに追加する。配信先リストとは、配信先として予定されるノードＮの一覧情報である。配信元装置１０は例えば、最初に受信された配信先応答メッセージｍ１の送信元のノードＮ０を最初の配信先（ダウンロード先）として決定する。但し、配信先の順番は、他の方法によって決定されてもよい。
【００２４】
図２では、ノードＮ０ａからの配信先応答メッセージｍ２が最初に受信されている（Ｓ１０５ａ）。したがって、配信元装置１０は、ノードＮ０ａに対して、ダウンロード許可メッセージをユニキャストで送信する（Ｓ１０６）。ダウンロード許可メッセージは、ファームウェアのダウンロードの実行の許可を示すメッセージである。
【００２５】
図６は、ダウンロード許可メッセージの第一の送信例を示す図である。同図には、ノードＮ０ａに対して、ダウンロード許可メッセージｍ３ａが送信されている例が示されている。
【００２６】
ダウンロード許可メッセージｍ３ａを受信したノードＮ０ａは、ダウンロード開始要求メッセージを配信元装置１０にユニキャストで送信する（Ｓ１０７）。ダウンロード開始要求メッセージは、ダウンロードの開始要求を示すメッセージである。
【００２７】
図７は、ダウンロード開始要求メッセージ送信例を示す図である。同図には、ノードＮ０ａが、ダウンロード開始要求メッセージｍ４ａを送信している例が示されている。
【００２８】
ダウンロード開始要求メッセージｍ４ａを受信した配信元装置１０は、メッセージｍ４ａの送信元のノードＮ０ａに、ファームウェアファイルをユニキャストで送信する（Ｓ１０８−１〜Ｓ１０８−ｎ）。図２では、ファームウェアファイルがｎ個のブロックに分割されて、ブロックごとに送信される例が示されている。
【００２９】
図８は、ファームウェアファイルの送信例を示す図である。同図には、配信元装置１０からノードＮ０ａに対してファームウェアファイルｆ１が送信されている例が示されている。
【００３０】
このように、ダウンロード許可メッセージｍ３を受信したノードＮのみが、ダウンロードを実行することができる。すなわち、ダウンロード許可メッセージｍ３によって、配信装置１０は、ファームウェアファイルｆ１のダウンロード（配信）に関して、排他制御を行うことができる。なお、本実施の形態において、配信とは、送信元から見た用語であり、ダウンロードとは、配信先から見た用語である。したがって、配信とダウンロードとは、処理内容としては同じことを意味する。
【００３１】
なお、配信元装置１０は、ファームウェアファイルｆ１の送信中に、ダウンロード開始要求メッセージｍ４ａを予想外に重複して受信したとしても、重複受信したダウンロード開始要求メッセージｍ４ａについては無視する。
【００３２】
ノードＮ０ａは、ファームウェアファイルダウンロードが完了すると、ダウンロード要求待ち通知メッセージを１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１０９）。ダウンロード要求待ち通知メッセージとは、以降において自らがファームウェアファイルの送信元となりうることを隣接ノードに通知するためのメッセージである。なお、本実施の形態において、隣接ノードとは、１ホップ区間内のノードをいう。
【００３３】
図９は、ダウンロード要求待ち通知メッセージの第一の送信例を示す図である。同図に示されるように、ダウンロード要求待ち通知メッセージｍ５ａは、１ホップ区間限定であるため、１ホップ区間内のノードＮ０ｂ、Ｎ１ｈ、Ｎ２ａ、及び配信元装置１０によって受信され、２ホップ区間以上にはホップされない。
【００３４】
ダウンロード要求待ち通知メッセージｍ５ａを受信した各ノードＮは、隣接ノードにファームウェアファイルの配信元が存在することを検知し、メッセージｍ５ａの送信元の宛先情報を記憶する。一方、配信元装置１０は、ダウンロード要求待ち通知メッセージｍ５ａを受信しても無視する。すなわち、宛先情報を記憶するのは、ノードＮのみである。なお、各ノードＮにおいて、保持される宛先情報の数に上限が設けられてもよい。例えば、上限が３である場合、各ノードＮは、３回目以内のダウンロード要求待ち通知メッセージｍ５に関しては宛先情報を保持し、４回目以降のダウンロード要求待ち通知メッセージｍ５については無視する。または、４回目以降のダウンロード要求待ち通知メッセージｍ５が受信された場合は、古い宛先情報から順に破棄され、新たに受信されたダウンロード要求待ち通知メッセージｍ５ａの送信元の宛先情報が保持されてもよい。
【００３５】
ダウンロード要求待ち通知メッセージｍ５ａの送信の成功により、ノードＮ０ａへのファームウェアファイルｆ１のダウンロード（配信）は終了する。そこで、ノードＮ０ａは、受信通知メッセージを、配信元装置１０にユニキャストで送信する（Ｓ１１０）。
【００３６】
図１０は、受信通知メッセージの第一の送信例を示す図である。同図には、ノードＮ０ａから配信元装置１０に対して受信通知メッセージｍ６ａが送信されている例が示されている。
【００３７】
受信通知メッセージｍ６ａを受信した配信元装置１０は、受信通知メッセージｍ６ａの送信元（ノードＮ０ａ）の識別情報を配信先リストより削除する。すなわち、ノードＮ０ａについては、ファームウェアファイルｆ１を送信済みであることが記録される。
【００３８】
続いて、配信元装置１０は、配信先リストにおいてノードＮ０ａの次にエントリされているノードＮ０ｂに対して、ダウンロード許可メッセージｍ３ｂをユニキャストで送信する（図３：Ｓ１１１）。
【００３９】
図１１は、ダウンロード許可メッセージの第二の送信例を示す図である。同図には、ノードＮ０ｂに対して、ダウンロード許可メッセージｍ３ｂが送信されている例が示されている。
【００４０】
ダウンロード許可メッセージｍ３ｂを受信したノードＮ０ｂは、ファームウェアファイルｆ１を保有しているノードＮ０ａの宛先情報を保持している。すなわち、ノードＮ０ｂの隣接ノードの中には、配信対象のファームウェアファイルを保有しているノードＮが存在する。そこで、ノードＮ０ｂは、配信元装置１０に対してではなく、当該宛先情報に係るノードＮ０ａに対してダウンロード開始要求メッセージｍ４ｂをユニキャストで送信する（Ｓ１１２）。また、ノードＮ０ｂは、配信元装置１０に対しては、ダウンロード開始通知メッセージをユニキャストで送信する（Ｓ１１３）。ダウンロード開始通知メッセージは、ダウンロード許可メッセージｍ３ｂの受信が成功して、隣接ノードからのダウンロードを開始することを示すメッセージである。
【００４１】
図１２は、隣接ノードへのダウンロード開始要求メッセージの送信例を示す図である。同図には、ノードＮ０ｂからノードＮ０ａに対してダウンロード開始要求メッセージｍ４ｂが送信されている例が示されている。また、ノードＮ０ｂから配信元装置１０に対してダウンロード開始通知メッセージｍ７ｂが送信されている例が示されている。
【００４２】
配信元装置１０は、ダウンロード開始通知メッセージｍ７を受信した場合、隣接ノードからダウンロードが行われるものと判断し、ファームウェアファイルの送信は行わない。なお、仮に、ノードＮ０ｂが、ファームウェアファイルを保有している隣接ノードの宛先情報を保持していない場合、ノードＮ０ｂは、配信元装置１０に対して、ダウンロード開始要求メッセージを送信する。この場合、ノードＮ０ｂに関して、ステップＳ１０８〜Ｓ１１０と同様の処理が実行される。
続いて、ダウンロード開始要求メッセージｍｂ４を受信したノードＮ０ａは、ダウンロード開始要求メッセージｍｂ４の送信元のノードＮ０ｂに、ファームウェアファイルｆ１をユニキャストで送信する（Ｓ１１４−１〜Ｓ１１４−ｎ）。
【００４３】
図１３は、隣接ノードからのファームウェアファイルの送信例を示す図である。同図には、ノードＮ０ａからノードＮ０ｂに対してファームウェアファイルｆ１が送信されている例が示されている。ファームウェアファイルｆ１は、ノードＮ０ａが、配信元装置１０よりダウンロードしたものである。
【００４４】
ノードＮ０ｂは、ファームウェアファイルｆ１のダウンロードが完了すると、ダウンロード要求待ち通知メッセージｍ５ｂを１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ１１５）。すなわち、ノードＮ０ｂがファームウェアファイルの送信元となりうることが隣接ノードに通知される。
【００４５】
図１４は、ダウンロード要求待ち通知メッセージの第二の送信例を示す図である。同図に示されるように、ダウンロード要求待ち通知メッセージｍ５ｂは、１ホップ区間限定であるため、１ホップ区間内のノードＮ０ａ、Ｎ１ｃ、Ｎ２ｂ、Ｎ２ａ、Ｎ２ｃ及び配信元装置１０によって受信され、２ホップ区間以上にはホップされない。ダウンロード要求待ち通知メッセージｍ５ｂを受信した各ノードＮは、隣接ノードにファームウェアファイルｆ１の配信元が存在することを検知し、ダウンロード要求待ち通知メッセージｍ５ｂの送信元の宛先情報を上限の範囲内で記憶する。一方、配信元装置１０は、ダウンロード要求待ち通知メッセージｍ５ｂを受信しても無視する。
【００４６】
ダウンロード要求待ち通知メッセージｍ５ｂの送信の成功により、ノードＮ０ｂへのファームウェアファイルｆ１のダウンロード（配信）は終了する。そこで、ノードＮ０ｂは、受信通知メッセージｍ６ｂを、ファームウェアファイルｆ１のダウンロード元であるノードＮ０ａと配信元装置１０との双方にユニキャストで送信する（Ｓ１１８ａ、Ｓ１１８ｂ）。
【００４７】
図１５は、受信通知メッセージの第二の送信例を示す図である。同図には、ノードＮ０ａ及び配信元装置１０の双方に対してノードＮ０ｂから受信通知メッセージｍ６ｂが送信されている例が示されている。
【００４８】
受信通知メッセージｍ６ｂを受信した配信元装置１０は、受信通知メッセージｍ６ｂの送信元（ノードＮ０ｂ）の識別情報を配信先リストより削除する。すなわち、ノードＮ０ｂについては、ファームウェアファイルｆ１を送信済みであることが記録される。
【００４９】
なお、ファームウェアファイルｆ１を隣接ノードからダウンロードした場合に、受信通知メッセージｍ６ｂを配信元装置１０にも送信するのは、配信元装置１０に配信済みのノードＮを知らせるためである。すなわち、配信元装置１０が、未配信又は配信済みのノードＮを把握し、配信システム１における配信が、排他的又は選択的に行われるようにするためである。その結果、輻輳による周辺の無線帯域の枯渇を防止することができる。
【００５０】
その後、配信元装置１０の配信先リストに登録されている、ノードＮ０ｃ〜Ｎ０ｈに関しても、１ノードＮずつ順番に、上記した手順によって配信元装置１０又は隣接ノードからファームウェアファイルｆ１がユニキャストで配信される。
【００５１】
配信元装置１０は、配信先リストに登録されている全てのノードＮに対してファームウェアファイルの配信が終了すると、再確認のために、配信先確認メッセージｍ１を、１ホップ区間限定のブロードキャストで送信する（Ｓ１１８ａ、Ｓ１１８ｂ）。既にファームウェアファイルｆ１を受信している各ノードＮ０は、配信先確認メッセージｍ１に対して応答は行わない。なお、配信元装置１０は、この後に予想外の受信通知メッセージｍ６を受信したとしても、当該受信通知メッセージｍ６を無視して、処理を継続する。
【００５２】
配信先確認メッセージｍ１の送信後、所定時間（例えば、３０秒等）が経過すると、配信元装置１０は、１ホップ区間内のノードＮ０群については、ファームウェアファイルｆ１の配信は完了したと判断する。そこで、配信元装置１０は、探索範囲を１段階（すなわち、１ホップ）拡張する。具体的には、配信元装置１０は、２ホップ区間限定（すなわち、ホップ数＝１）の配信先確認メッセージｍ１をブロードキャストで送信する（Ｓ１１９ａ、Ｓ１１９ｂ）。例えば、ステップＳ１１９ａでは、ノードＮ０ａからのホップによってノードＮ１ａに配信先確認メッセージｍ１が到達する。また、ステップＳ１１９ｂでは、ノードＮ０ｂからのホップによってノードＮ１ｂに配信先確認メッセージｍ１が到達する。
【００５３】
図１６は、２ホップ区間限定の配信先確認メッセージの送信例を示す図である。同図には、各ノードＮ０からのホップによって、各ノードＮ１に対して配信先確認メッセージｍ１が送信されている例が示されている。但し、２ホップ区間限定であるため、３ホップ区間以上にはホップされない。なお、配信元装置１０は、この後に予想外の受信通知メッセージを受信しても、当該メッセージを無視して、処理を継続する。
【００５４】
配信先確認メッセージｍ１を受信したノードＮ１群の中で、配信対象のファームウェアを適用する必要のある各ノードＮ１は、配信先確認メッセージｍ１の送信元に、配信先応答メッセージｍ２をユニキャストで返信する（Ｓ１２０ａ、Ｓ１２０ｂ）。
【００５５】
以降、ノードＮ１群に関して、ノードＮ０群と同様に、ファームウェアファイルの配信が行われる。その後、探索範囲が３ホップ区間内、４ホップ区間内、５ホップ区間内と１ホップずつ拡張され、全ノードＮへのファームウェアファイルｆ１の配信が完了する。探索範囲が拡張されても、配信先確認メッセージｍ１及びダウンロード許可メッセージｍ３は配信元装置１０から送信される。また、ダウンロード開始通知メッセージｍ７及び受信通知メッセージｍ６は、配信元装置１０に送信される。
【００５６】
なお、探索範囲のホップ数の上限は、例えば、配信元装置１０に対する設定によって変更可能とされてもよい。既定値として、例えば、３０ホップが設定されていてもよい。
【００５７】
上述したように、本実施の形態によれば、配信先のノードＮの探索範囲は、段階的に拡張されて、段階ごとに、探索されたノードＮに対して配信が行われる。そして、既に配信を受けたノードＮは、配信元になることができる。したがって、隣接ノード間でのファームウェアファイルｆ１の転送（又はダウンロード）を実現することができる。
【００５８】
探索範囲の段階的な拡張と隣接ノード間（特に、前の段階の探索範囲に含まれるノードＮと次の段階の探索範囲に含まれるノードＮとの間）での転送とにより、多重ホップによってファームウェアファイルｆ１が転送される可能性を低減させることができる。換言すれば、ファームウェアファイルｆ１の転送に関して、多重度の増加を抑制することができる。
【００５９】
また、或る時点において配信元及び配信先となるノードＮは、配信元装置１０によって排他的に管理される。したがって、複数のノードＮに対するダウンロード元が、同時期に一つのノードＮに集中することによる、局所的なネットワーク負荷の増加を回避することができる。その結果、無線周波数帯域が小さい通信方式であっても、効率的にファームウェアｆ１の配信を行うことができる。
【００６０】
上記の結果、ネットワークの擾乱の発生を抑制することができ、その結果として、多重ホップのブロードキャストによってファームウェアファイルｆ１を配信する場合に比べて、短時間での配信の完了が期待できる。
【００６１】
続いて、上記した配信方法を実現するための配信元装置１０及びノードＮに関して更に具体的に説明する。
【００６２】
図１７は、本発明の実施の形態における配信元装置のハードウェア構成例を示す図である。図１７の配信元装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、不揮発性メモリ１０２、揮発性メモリ１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００６３】
配信元装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して不揮発性メモリ１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。不揮発性メモリ１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００６４】
揮発性メモリ１０３は、プログラムの起動指示があった場合に、不揮発性メモリ１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、揮発性メモリ１０３に格納されたプログラムに従って配信元装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００６５】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、不揮発性メモリ１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び不揮発性メモリ１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。但し、配信元装置１０は、必ずしもドライブ装置１０１を有していなくてもよい。
【００６６】
なお、各ノードＮは、配信元装置１０と同様のハードウェアを有していればよい。
【００６７】
図１８は、第一の実施の形態の配信元装置の機能構成例を示す図である。同図において、配信元装置１０は、ファームウェア受信部１１、配信先探索部１２、ダウンロード許可部１３、配信部１４、及び終了検知部１５等を有する。これら各部は、配信元装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理により実現される。また、配信元装置１０は、配信先リスト記憶部１６を有する。配信先リスト記憶部１６は、例えば、揮発性メモリ１０３又は不揮発性メモリ１０２を用いて実現可能である。
【００６８】
ファームウェア受信部１１は、ダウンロードサーバ３０よりファームウェアファイルｆ１を受信する。
【００６９】
配信先探索部１２は、ファームウェアファイルｆ１の配信先となるノードＮを探索する。配信先探索部１２は、探索されたノードＮの識別情報を配信先リスト記憶部１６に記録する。上記したように、配信先探索部１２は、探索範囲を複数段階に拡張させ、各段階においてノードＮを探索する。本実施の形態において、探索範囲は、ホップ数によって規定される。但し、探索範囲の基準又は単位は通信方式に応じて適宜変更されてもよい。
【００７０】
ダウンロード許可部１３は、配信先探索部１２によって探索された各ノードＮに対して、順番に又は排他的に配信の許可（すなわち、ダウンロード許可メッセージｍ３）を通知する。配信部１４は、ダウンロードファイルｆ１をノードＮに送信する。終了検知部１５は、ノードＮごとに、ファームウェアファイルｆ１の送信の終了を検知する。
【００７１】
図１９は、第一の実施の形態のノードの機能構成例を示す図である。同図において、ノードＮは、配信元検知部２０１、配信要求部２０２、ダウンロード部２０３、配信元通知部２０４、受信通知部２０５、リセット部２０６、開始要求受信部２０７、配信部２０８、及び終了検知部２０９等を有する。これら各部は、ノードＮにインストールされたプログラム（例えば、ファームウェア）がノードＮのＣＰＵに実行させる処理により実現される。また、ノードＮは、宛先情報記憶部２１０を有する。宛先情報記憶部２１０は、ノードＮの揮発性メモリ又は不揮発性メモリを用いて実現可能である。
【００７２】
配信元検知部２０１は、配信先確認メッセージｍ１又はダウンロード要求待ち通知メッセージｍ６等の受信に基づいて、ファームウェアファイルｆ１の配信先の存在を検知する。配信元検知部２０１は、ダウンロード要求待ち通知メッセージｍ６が受信された場合は、ダウンロード要求待ち通知メッセージｍ６の送信元の宛先情報を宛先情報記憶部２１０に記録する。
【００７３】
配信要求部２０２は、配信対象のファームウェアファイルｆ１の配信を受けたい場合に、配信確認応答メッセージｍ２を、配信先確認メッセージｍ１の送信元に送信する。
【００７４】
ダウンロード部２０３は、配信先確認メッセージｍ１又はダウンロード要求待ち通知メッセージｍ６の送信元からファームウェアファイルｆ１をダウンロードする。宛先情報記憶部２１０に少なくとも一つの宛先情報が記録されている場合、ダウンロード部２０３は、当該宛先情報に係るノードＮからファームウェアファイルｆ１をダウンロードする。
【００７５】
配信元通知部２０４は、ファームウェアファイルｆ１のダウンロードが完了した後、自ノードＮが配信元となりうることを隣接ノードに通知するため、ダウンロード要求待ち通知メッセージｍ６を送信する。
【００７６】
受信通知部２０５は、ファームウェアファイルｆ１の配信元及び配信元装置１０に対して、ファームウェアファイルｆ１の受信が完了したことを示す受信通知メッセージｍ６を送信する。
【００７７】
リセット部２０６は、ファームウェアファイルｆ１に格納されているファームウェアによる更新を有効とするために、ノードＮのリセットを実行する。リセットとは、例えば、ノードＮの再起動をいう。
【００７８】
開始要求受信部２０７は、他のノードＮから、ダウンロード開始要求メッセージｍ４を受信する。配信部２０８は、ダウンロード開始要求メッセージｍ４の送信元に対して、ファームウェアファイルｆ１を送信する。終了検知部１５は、ファームウェアファイルｆ１の送信の終了を検知する。
【００７９】
以下、配信元装置１０及びノードＮのそれぞれの処理手順について説明する。図２０は、第一の実施の形態の配信元装置の処理手順の一例を説明するためのフローチャートである。なお、同図において、配信元装置１０は、既にダウンロードサーバ３０よりファームウェアファイルｆ１をダウンロード済みであるとする。すなわち、図２のステップＳ１０１〜Ｓ１０３は実行済みの状態であるとする。
【００８０】
配信開始日時が到来すると、配信先探索部１２は、配信先確認メッセージｍ１のホップ数Ｈは、上限値以下であるか否かを判定する（Ｓ２０１）。図２０の開始時点にいて、ホップ数Ｈの初期値は「０」である。また、上限値は、例えば、不揮発性メモリ１０２に記録されている。
【００８１】
ホップ数Ｈが上限値以下である場合（Ｓ２０１でＹｅｓ）、配信先探索部１２は、配信先確認メッセージｍ１（図４参照）を、ホップ数Ｈのホップ区間限定のブロードキャストで送信する（Ｓ２０２）。
【００８２】
図２１は、配信先確認メッセージの構成例を示す図である。同図において、配信先確認メッセージｍ３は、ヘッダ部とデータ部とを含む。ヘッダ部は、各メッセージに共通の部分であり、メッセージ種別、データ長、送信元ＭＡＣアドレス、及び送信先ＭＡＣアドレス等を含む。
【００８３】
メッセージ種別は、メッセージの種別である。配信先確認メッセージｍ１に関しては、配信先確認メッセージｍ１であることがメッセージ種別に指定される。データ長は、データ部のデータ長である。送信元ＭＡＣアドレスは、メッセージの送信元のＭＡＣアドレスである。送信先ＭＡＣアドレスは、メッセージの送信元のＭＡＣアドレスである。送信先ＭＡＣアドレスは、メッセージの送信先のＭＡＣアドレスである。配信先確認メッセージｍ１は、ブロードキャストであるため、送信先ＭＡＣアドレスには、ブロードキャストアドレスが指定される。
【００８４】
一方、データ部は、メーカＩＤ、対象ノード識別子、ファーム形式、ファームバージョン、及び対象外ファーム保持要否等を含む。メーカＩＤは、配信対象のファームウェアの適用対象となるノードＮのメーカの識別子である。本実施の形態の配信システム１には、相互に異なるメーカによって製造された装置がノードＮとして含まれている場合も想定している。配信対象のファームウェアの適用対象のメーカと異なるメーカのノードＮは、当該ファームウェアの適用対象とはならない。
【００８５】
対象ノード識別子は、配信対象のファームウェアの適用対象となるノードＮの種別の識別子である。ノードＮの種別とは、ノードＮの機能に基づく種別である。例えば、スマートメータと中継装置とでは、種別が異なる。
【００８６】
ファーム形式は、ファームウェアファイルｆ１の形式を示す情報である。例えば、ファームウェアファイルｆ１に含まれているデータが、ファームウェア全体であるのか、更新部分のみであるのか、圧縮されているのか、暗号化されているのか等を示す情報である。
【００８７】
ファームウェアバージョンとは、ファームウェアファイルｆ１に含まれているファームウェアのバージョンである。
【００８８】
対象外ファーム保持要否は、各ノードＮが、当該ノードＮにとって適用対象外のファームウェアに係るファームウェアファイルｆ１を保持する必要が有るか否かを示す情報である。各ノードＮにとって適用対象であるか否かは、メーカＩＤ、対象ノード識別子、及びファームバージョンによって判定される。なお、ファームウェアファイルｆ１を保持する必要が有るか否かは、当該ファームウェアファイルｆ１の配信の中継を行う必要が有るか否かと同義である。
【００８９】
なお、ヘッダ部は、各メッセージで共通であるため、以降で説明するメッセージについては、便宜上、データ部のみを示す。また、ホップ数については、より下位のレベル（配信元装置１０及び各ノードＮが利用する通信プロトコルのレベル）において管理されているため、図２１には含まれていない。
【００９０】
続いて、配信先探索部１２は、配信先応答メッセージｍ２の受信待ちのタイマを設定する（Ｓ２０３）。例えば、３０秒後にタイマが設定される。配信先応答メッセージｍ２の受信待ちの間（Ｓ２０４でＹｅｓ）、配信先探索部１２は、配信先確認メッセージｍ１に応じて返信される配信先応答メッセージｍ２（図５参照）を受信する（Ｓ２０５）。
【００９１】
受信された配信先応答メッセージｍ２の数が、配信先リスト記憶部１６の上限以内である場合（Ｓ２０６でＹｅｓ）、配信先探索部１２は、受信された配信先応答メッセージｍ２に含まれている、送信元ＭＡＣアドレスを配信先リストのエントリ（配信先情報）として配信先リスト記憶部１６に記録する（Ｓ２０７）。一方、受信された配信先応答メッセージｍ２の数が、配信先リスト記憶部１６の上限を超えた場合（Ｓ２０６でＮｏ）、配信先探索部１２は、配信先応答メッセージｍ２の受信待ちタイマを解除して（Ｓ２０８）、ステップＳ２１１に進む。
【００９２】
配信先応答メッセージの受信待ちの期限が到来すると（Ｓ２０４でＮｏ）、配信先探索部１２は、配信先リスト記憶部１６に配信先情報が記録されているか否かを判定する（Ｓ２０９）。配信先情報が記録されていない場合（Ｓ２０９でＮｏ）、配信先探索部１２は、ホップ数Ｈに１を加算し（Ｓ２１０）、ステップＳ２０１以降を繰り返す。すなわち、配信先となるノードＮの探索範囲が拡張される。
【００９３】
一方、配信先リスト記憶部１６に配信先情報が記録されている場合（Ｓ２０９でＹｅｓ）、ステップＳ２１１に進む。
【００９４】
以上で、ホップ数Ｈ＋１区間内において、配信先となるノードＮの探索は終了する。続いて、探索された各ノードＮに順番に配信するための処理が行われる。
【００９５】
ステップＳ２１１において、ダウンロード許可部１３は、配信先リスト記憶部１６に記録されている配信先情報の中から一つの配信先情報を選択し、当該配信先情報を送信先ＭＡＣアドレスとするダウンロード許可メッセージｍ３を送信する。例えば、配信先リスト記憶部１６への記録順に一つの配信先情報が選択される。但し、複数の配信先情報が選択され、各配信先情報を送信先ＭＡアドレスとする、複数のダウンロード許可メッセージｍ３がほぼ同時に送信されてもよい。例えば、配信先リスト記憶部１６に記憶されている全ての配信先情報のそれぞれに関して、ダウンロード許可メッセージｍ３がほぼ同時に送信されてもよい。
【００９６】
図２２は、ダウンロード許可メッセージのデータ部の構成例を示す図である。同図において、ダウンロード許可メッセージｍ３は、リセット日時、分割数、ブロック長、ファーム形式、及び対象外ファーム保持要否等を含む。
【００９７】
リセット日時は、配信対象のファームウェアを有効にする日時である。例えば、当該ファームウェアを適用したノードＮがリセット（又は再起動）する日時である。すなわち、リセット日時は、ファームウェアファイルｆ１の配信を受けた各ノードＮにおいて、新しいファームウェアが有効となる日時を一致させ、ノードＮ間における不整合の発生を回避するためのパラメータである。
【００９８】
分割数は、ファームウェアファイルｆ１を複数ブロックに分割して配信する際の分割数である。ブロック長は、一ブロックのデータ長（サイズ）である。ファーム形式及び対象外ファーム保持要否の意味は、配信先確認メッセージｍ１における同一名のパラメータと同じである。
【００９９】
続いて、配信部１４は、ダウンロード許可メッセージｍ３を受信したノードＮから、ダウンロード開始要求メッセージｍ４（図７参照）又はダウンロード開始通知メッセージｍ７（図１２参照）を受信する（Ｓ２１２）。ダウンロード開始要求メッセージｍ４又はダウンロード開始通知メッセージｍ７のいずれが受信されるかは、ダウンロード許可メッセージｍ３を受信したノードＮ（配信先のノードＮ）のファームウェアファイルｆ１のダウンロード元（配信元）に応じて異なる。
【０１００】
すなわち、ダウンロード開始要求メッセージｍ４が受信された場合（Ｓ２１３でＹｅｓ）、当該ダウンロード元は配信元装置１０である。そこで、配信部１４は、ファームウェアファイルｆ１（図８参照）を配信先のノードＮに送信する（Ｓ２１４）。
【０１０１】
図２３は、第一の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。同図に示されるように、当該データ部は、ブロック番号、ブロック長、及びブロック等を含む。
【０１０２】
ブロック番号は、ファームウェアファイルｆ１がブロック単位に分割された場合の各ブロックの順番を示す。ブロック長は、一ブロックのデータ長である。ブロックは、ブロックの実体である。
【０１０３】
ステップＳ２１４では、ファームウェアファイルｆ１は、ダウンロード許可メッセージｍ３に指定されている分割数分のブロックに分割される。そして、分割数分だけ図２３に示されるデータ部を有するメッセージが、配信元装置１０から配信先のノードＮに繰り返し送信される。
【０１０４】
なお、ダウンロード許可メッセージｍ３が、複数のノードＮに対してほぼ同時に送信されている場合、配信部１４は、複数のノードＮからダウンロード開始要求メッセージｍ４を受信する可能性がある。但し、配信部１４は、例えば、最初に受信されたダウンロード開始要求メッセージｍ４の送信元であるノードＮにファームウェアファイルｆ１の送信を行い、他のノードＮからのダウンロード開始要求メッセージｍ４は無視する。すなわち、第一の実施の形態では、一つの配信元（配信元装置１０又は配信済みのノードＮ）から同時に配信先とされるノードＮの数は、１である。
【０１０５】
なお、ダウンロード開始要求メッセージｍ４を無視されたノードＮは、ダウンロード開始要求メッセージｍ４の送信時から所定時間経過してもファームウェファイルｆ１が受信されないことに基づいて、タイムアウトを検知する。タイムアウトを検知したノードＮは、次回のダウンロード許可メッセージｍ３の受信を待機する。
【０１０６】
一方、ダウンロード開始通知メッセージｍ７が受信された場合（Ｓ２１３でＮｏ）、当該ダウンロード元は、配信元装置１０ではない。したがって、配信部１４はファームウェアファイルｆ１の送信は行わない。
【０１０７】
この場合、複数のノードＮに対してダウンロード許可メッセージｍ３が送信されているときは、複数のノードＮのそれぞれが、各ノードの宛先情報記憶部２１０に記憶している宛先情報に係る他のノードに対してダウンロード開始要求メッセージｍ３を送信している。並行して送信されたダウンロード開始要求メッセージｍ３の送信先が相互に重複しない場合、各ノードＮ間で並列的にファームウェアファイルｆ１の配信（ダウンロード）が行われる。一方、ダウンロード開始要求メッセージｍ３を重複して受信したノードＮは、例えば、最初に受信されたダウンロード開始要求メッセージｍ４の送信元であるノードＮにファームウェアファイルｆ１の送信を行い、他のノードＮからのダウンロード開始要求メッセージｍ４は無視する。ダウンロード開始要求メッセージｍ４を無視されたノードＮは、ダウンロード開始要求メッセージｍ４の送信時から所定時間経過してもファームウェファイルｆ１が受信されないことに基づいて、タイムアウトを検知する。タイムアウトを検知したノードＮの宛先情報記憶部２１０において、別の宛先情報が記憶されている場合、当該ノードＮは、当該別の宛先情報に係るノードＮに対して、ダウンロード開始要求メッセージｍ４を送信する。
【０１０８】
このように、ダウンロード許可メッセージｍ３がほぼ同時に複数のノードＮに送信されることで、ノードＮ間におけるファームウェアファイルｆ１の配信の並列化を可能とすることができる。その結果、ダウンロード許可メッセージｍ３が一つのノードＮにしか送信されない場合に比べて、ファームウェアファイルｆ１の配信効率を向上させることができる。
【０１０９】
ステップＳ２１４又はＳ２１３でＮｏの場合に続いて、終了検知部１５は、受信通知メッセージｍ６の受信を待機する。受信通知メッセージｍ６（図１０及び図１５参照）が受信されると（Ｓ２１５）、終了検知部１５は、受信通知メッセージｍ６の送信元であるノードＮに係る配信先情報を配信リスト記憶部より削除する（Ｓ２１６）。
【０１１０】
続いて、ダウンロード許可部１３は、配信先リスト記憶部１６に配信先情報が残っているか否かを判定する（Ｓ２１７）。配信先情報が残っている場合（Ｓ２１７でＹｅｓ）、ステップＳ２１１以降が繰り返される。すなわち、ホップ数Ｈのホップ区間内で探索された他のノードＮに対してファームウェアファイルｆ１の配信が行われる。
【０１１１】
一方、配信先情報が残っていない場合（Ｓ２１７でＮｏ）、配信先探索部１２は、ホップ数Ｈに１を加算し（Ｓ２１８）、ステップＳ２０１以降を繰り返す。すなわち、配信先となるノードＮの探索範囲が拡張される。
【０１１２】
続いて、各ノードＮが実行する処理手順について説明する。図２４は、第一の実施の形態のノードが実行するダウンロード処理の処理手順の一例を説明するためのフローチャートである。同図では、或る一つのノードＮに注目して説明する。
【０１１３】
配信元検知部２０１が、配信先確認メッセージｍ１を受信すると（Ｓ３０１）、配信要求部２０２は、配信対象のファームウェアが自ノードの適用対象であるか否かを判定する（Ｓ３０２）。すなわち、配信先確認メッセージｍ１（図２１）に含まれている、メーカＩＤ及び対象ノード識別子に自ノードが合致するか判定される。合致する場合、配信先確認メッセージｍ１（図２１）に含まれているファームバージョンが、自ノードに適用されているファームウェアのバージョンより新しいかが判定される。
【０１１４】
配信対象のファームウェアが自ノードの適用対象である場合（Ｓ３０２でＹｅｓ）、配信要求部２０２は、既に当該ファームウェアのファームウェアファイルｆ１を受信済み（ダウンロード済み）であるか否かを判定する（Ｓ３０３）。ファームウェアファイルｆ１を受信済みである場合（Ｓ３０３でＮｏ）、図２４の処理は終了する。一方、ファームウェアファイルｆ１を受信済みでない場合（Ｓ３０３でＹｅｓ）、ステップＳ３０５に進む。
【０１１５】
また、配信対象のファームウェアが自ノードの適用対象でない場合（Ｓ３０２でＮｏ）、配信要求部２０２は、配信先確認メッセージｍ１に含まれている、対象外ファーム保持要否の値が「要」であるか否かを判定する（Ｓ３０４）。対象外ファーム保持要否の値が「否」である場合（Ｓ３０４でＮｏ）、ファームウェアファイルｆ１の保持の必要は無いため、図２４の処理は終了する。一方、対象外ファーム保持要否の値が「要」である場合（Ｓ３０４でＹｅｓ）、ステップＳ３０５に進む。
【０１１６】
ステップＳ３０５において、配信要求部２０２は、配信先応答メッセージｍ２（図５参照）をユニキャストで配信元装置１０に送信する（Ｓ３０５）。続いて、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の受信を待機する。ダウンロード許可メッセージｍ３が受信されると（Ｓ３０６）、ダウンロード部２０３は、宛先情報記憶部２１０に宛先情報が記録されているか否かを判定する（Ｓ３０７）。すなわち、ファームウェアファイルｆ１を既にダウンロード済みの隣接ノードの存否が確認される。
【０１１７】
宛先情報記憶部２１０に宛先情報が記録されてない場合（Ｓ３０７でＮｏ）、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の送信元（すなわち、配信元装置１０）に、ダウンロード開始要求メッセージｍ４（図７参照）をユニキャストで送信する（Ｓ３０８）。
【０１１８】
一方、宛先情報記憶部２１０に宛先情報が記録されている場合（Ｓ３０７でＹｅｓ）、ダウンロード部２０３は、いずれかの宛先情報に係るノードＮに対してダウンロード開始要求メッセージｍ４（図１２参照）をユニキャストで送信する（Ｓ３０９）。続いて、ダウンロード部２０３は、ダウンロード許可メッセージｍ３の送信元（すなわち、配信元装置１０）に、ダウンロード開始通知メッセージｍ７（図１２参照）をユニキャストで送信する（Ｓ３１０）。
【０１１９】
ステップＳ３０８又はＳ３１０に続いて、ダウンロード部２０３は、配信元装置１０又は隣接ノードから送信されるファームウェアファイルｆ１を受信する（Ｓ３１１）。上記したように、ファームウェアファイルｆ１は、ブロック単位に分割されて複数回にわたって送信される。なお、受信されたファームウェアファイルｆ１は、例えば、揮発性のメモリに保持される。
【０１２０】
なお、ダウンロード部２０３は、ステップＳ３０９において、宛先情報に係るノードＮに対してダウンロード開始要求メッセージｍ４を送信した場合、所定時間待機しても当該送信先からファームウェアファイルｆ１が送信されてこないときは、タイムアウトを検知する。タイムアウトの検知に応じ、ダウンロード部２０３は、宛先情報記憶部２１０に別の宛先情報が記憶されている場合は、当該別の宛先情報に基づいてステップＳ３０９以降を繰り返す。ステップＳ３０９以降を繰り返した結果、全ての宛先情報に関してタイムアウトを検知した場合、ダウンロード部２０３は、次回のダウンロード許可メッセージｍ３の受信を待機する。タイムアウトが検知されるような状況は、例えば、ダウンロード開始要求メッセージｍ４の送信先のノードＮが、他のノードＮに対して、ファームウェアファイルｆ１を送信中である場合に発生する。
【０１２１】
続いて、ダウンロード部２０３は、ファームウェアファイルｆ１に係るファームウェアが自ノードへの適用対象であるか否かを判定する（Ｓ３１２）。当該判定は、ステップＳ３０６において受信されたダウンロード許可メッセージｍ３に含まれている、メーカＩＤ、対象ノード識別子、及びファームバージョンに基づいて、ステップＳ３０２と同様の処理内容で実行される。
【０１２２】
当該ファームウェアが適用対象である場合（Ｓ３１２でＹｅｓ）、ダウンロード部２０３は、不揮発性メモリにおいて、既にインストールされているファームウェアに対して、ファームウェアファイルｆ１に格納されているファームウェアを上書き（反映）する（Ｓ３１３）。すなわち、ファームウェアの更新が行われる。上書きは、例えば、ダウンロード許可メッセージｍ３に含まれていたファーム形式に基づいて行われる。ダウンロード部２０３は、また、ファームウェアが更新されたことを示す情報（以下、「更新フラグ」という。）を、例えば、揮発性メモリに記録しておく。更新フラグの内容は、例えば、ダウンロード許可メッセージｍ３に含まれているリセット日時でもよい。
【０１２３】
なお、揮発性メモリにインストールされているファームウェアは、ノードＮの起動時に揮発性メモリにロードされるため、この時点では、上書き前の状態のファームウェアが有効である。したがって、当該ノードＮの動作は、直ちに上書き後のファームウェアに応じたものとはならない。
【０１２４】
続いて、配信元通知部２０４は、ダウンロード要求待ちメッセージｍ６（図９又は図１４参照）を、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ３１４）。
【０１２５】
図２５は、ダウンロード要求待ちメッセージのデータ部の構成例を示す図である。同図において、ダウンロード要求待ちメッセージｍ６のデータ部は、メーカＩＤ、対象ノード識別子、ファーム形式、ファームバージョン、及び対象外ファーム保持要否等を含む。すなわち、ダウンロード要求待ちメッセージｍ６のデータ部の構成は、配信先確認メッセージｍ３のデータ部の構成と同様である。また、ダウンロード要求待ちメッセージｍ６のデータ部の各項目には、配信先確認メッセージｍ３のデータ部の各項目の値が引き継がれる。
【０１２６】
続いて、受信通知部２０５は、配信元装置１０がファームウェアファイルｆ１のダウンロード元であったか否かを判定する（Ｓ３１５）。隣接ノードがダウンロード元であった場合（Ｓ３１５でＮｏ）、受信通知部２０５は、当該隣接ノードに対して、受信通知メッセージｍ６（図１５参照）をユニキャストで送信する（Ｓ３１６）。
【０１２７】
ステップＳ３１５でＹｅｓの場合又はステップＳ３１６に続いて、受信通知部２０５は、配信元装置１０に対して、受信通知メッセージｍ６（図１０又は図１５参照）をユニキャストで送信する（Ｓ３１７）。
【０１２８】
続いて、既にダウンロード済みのノードＮが、他のノードに対してファームウェアファイルｆ１の配信を行う際の処理手順について説明する。
【０１２９】
図２６は、第一の実施の形態のノードが実行する配信処理の処理手順の一例を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。
【０１３０】
開始要求受信部２０７が、他のノードＮから送信されたダウンロード開始要求メッセージｍ４を受信すると（Ｓ３２１）、配信部２０８は、揮発性メモリに記録されているダウンロードファイルｆ１を、当該他のノードＮに送信する（Ｓ３２２）。ファームウェアファイルｆ１は、ブロック単位に分割されて複数回にわたって送信される。ファームウェアファイルｆ１の送信が完了すると、終了検知部２０９は、受信通知メッセージｍ６（図１５参照）を受信する（Ｓ３２３）。
【０１３１】
なお、複数のノードＮに対してダウンロード許可メッセージｍ３がほぼ同時に送信される場合、開始要求受信部２０７は、複数のノードＮからダウンロード開始要求メッセージｍ４を受信する可能性がある。この場合、開始要求受信部２０７は、例えば、最初に受信されたダウンロード開始要求メッセージｍ４以外は無視する。
【０１３２】
続いて、各ノードＮが、既にダウンロード済みのノードＮによるダウンロード要求待ちメッセージｍ６を受信した際に実行する処理手順について説明する。
【０１３３】
図２７は、第一の実施の形態においてダウンロード要求待ちメッセージを受信したノードが実行する処理手順の一例を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。
【０１３４】
配信元検知部２０１は、ダウンロード要求待ちメッセージｍ６を受信すると（Ｓ３３１）、自ノードＮにおいてファームウェアファイルｆ１はダウンロード済みであるか否かを判定する（Ｓ３３２）。すなわち、揮発性メモリにファームウェアファイルｆ１が記録されているか否かが判定される。また、揮発性メモリに記録されているファームウェアファイルｆ１に関するメーカＩＤ、対象ノード識別子、及びファームバージョンと、ダウンロード要求待ちメッセージｍ６に含まれているメーカＩＤ、対象ノード識別子、及びファームバージョンとが一致するか否かが判定されてもよい。
【０１３５】
ダウンロード済みである場合（Ｓ３３２でＮｏ）、図２７の処理は終了する。ダウンロード済みでない場合（Ｓ３３２でＹｅｓ）、配信元検知部２０１は、宛先情報記憶部２１０に既に記録されているエントリ（宛先情報）の数が、上限値未満であるか否か判定する（Ｓ３３３）。当該エントリ数が上限値に達している場合（Ｓ３３３でＮｏ）、図２７の処理は終了する。
【０１３６】
一方、当該エントリ数が上限値未満である場合（Ｓ３３３でＹｅｓ）、配信元検知部２０１は、ダウンロード要求待ちメッセージｍ６に含まれている、送信元ＭＡＣアドレスを宛先情報として宛先情報記憶部２１０に記録する（Ｓ３３４）。
【０１３７】
続いて、ファームウェアファイルｆ１を受信した各ノードＮが、リセット日時の到来に応じて実行する処理について説明する。
【０１３８】
図２８は、リセット日時の到来に応じて各ノードが実行する処理を説明するためのフローチャートである。同図においても、或る一つのノードＮに注目して説明する。但し、揮発性メモリに更新フラグが記録されていないノードＮは、同図の処理手順は実行しない。更新フラグとは、図２４のステップＳ３１３において記録される、ファームウェアが更新されたことを示す情報である。
【０１３９】
リセット部２０６は、リセット日時の到来を検知すると（Ｓ３５１でＹｅｓ）、当該ノードＮのリセットを実行する（Ｓ３５２）。リセットによって、不揮発性メモリにおいて更新されたファームウェアが揮発性メモリにロードされる。その結果、更新後のファームウェアの制御に基づいて、ノードＮは動作する。
【０１４０】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、第二の実施の形態において特に言及しない点については、第一の実施の形態と同様でよい。
【０１４１】
第二の実施の形態では、図８や図１３に示される状態（すなわち、ファームウェアファイルｆ１の送信時）において、送信元（配信元装置１０又はノードＮ）は、ファームウェアファイルｆ１をブロードキャストで送信する。但し、多重ホップを抑制するため、当該ブロードキャストは、例えば、１ホップ区間限定とされる。その結果、ダウンロード許可メッセージｍ３を受信したノードＮ以外のノードも、ファームウェアファイルｆ１を並行して受信することができる。例えば、図８の状態においては、ノードＮ０ａのみでなく、他のノードＮ０群もファームウェアファイルｆ１を並行して受信する。
【０１４２】
すなわち、そもそもファームウェアファイルｆ１の送信メッセージは、ユニキャストであろうとブロードキャストであろうと、送信先以外の他のノードＮにも到達しているのであるから、他のノードＮにも受信させてしまおうという趣旨である。
【０１４３】
具体的には、第二の実施の形態では、図２０のステップＳ２０５及び図２６のステップＳ３３２において、配信元装置１０の配信部１４又は送信元のノードＮの配信部２０８は、１ホップ区間限定のブロードキャストでファームウェアファイルｆ１を送信する。
【０１４４】
図２９は、第二の実施の形態のファームウェアファイルの送信メッセージのデータ部の構成例を示す図である。同図に示されるように、当該データ部は、リセット日時、ファーム形式、対象外ファーム保持要否、ブロック番号、ブロック長、及びブロック等を含む。
【０１４５】
なお、各パラメータの意味は、ダウンロード許可メッセージ（図２２）又はユニキャストによるファームウェアファイルの送信メッセージ（図２３）において同一名のパラメータの意味と同じである。
【０１４６】
ダウンロード許可メッセージｍ３を受信しているノードＮ（例えば、図８のノードＮ０ａ）は、図２４のステップＳ３１０において、１ホップ区間限定のブロードキャストで送信されたファームウェアファイルｆ１を受信する。
【０１４７】
一方、ダウンロード許可メッセージｍ３を受信していないノードＮ（例えば、図８のノードＮ０ｂ〜Ｎ０ｈ）は、当該ブロードキャストが受信された際に、図３０に示される処理を実行する。
【０１４８】
図３０は、第二の実施の形態においてダウンロード許可メッセージを受信していないノードがブロードキャストによるファームウェアファイルを受信した際の処理手順の一例を説明するためのフローチャートである。同図では、ダウンロード許可メッセージを受信していない或るノードＮに注目して説明する。
【０１４９】
ステップＳ４０１において、ダウンロード部２０３は、ファームウェアファイルｆ１に係るブロードキャスト検知する。続いて、ダウンロード部２０３は、ファームウェアファイルｆ１はダウンロード済みであるか否かを判定する（Ｓ４０２）。判定方法は、図２７のステップＳ３３２と同様でよい。
【０１５０】
ダウンロード済みである場合（Ｓ４０２でＮｏ）、図３０の処理は終了する。ダウンロード済みでない場合（Ｓ４０２でＹｅｓ）、ダウンロード部２０３は、ブロック単位で送信されるファームウェアファイルｆ１の受信を継続する（Ｓ４０３）。
【０１５１】
ファームウェアファイルｆ１の受信が終了すると、ダウンロード部２０３は、ファームウェアファイルｆ１に格納されているファームウェアが自ノードの適用対象であるか否かを判定する（Ｓ４０４）。当該判定方法は、図２４のステップＳ３０２と同様でよい。但し、当該ファームウェアのメーカＩＤ、対象ノード識別子、及びファームバージョンは、ファームウェアファイルｆ１内より取得される。または、ブロードキャスト時のファームウェアファイルｆ１の送信メッセージのデータ部に、メーカＩＤ、対象ノード識別子、及びファームバージョンが含まれていてもよい。この場合、ダウンロード部２０３は、ファームウェアファイルｆ１の全ブロックを受信せずとも、一つのブロックを受信することによって、ファームウェアファイルｆ１に格納されているファームウェアが自ノードの適用対象であるか否かを判定することができる。但し、メーカＩＤ、対象ノード識別子、及びファームバージョンの分だけ、各ブロックのデータ量が増加するという不利益はある。
【０１５２】
当該ファームウェアが自ノードの適用対象である場合（Ｓ４０４でＹｅｓ）、ダウンロード部２０３は、不揮発性メモリに既にインストールされているファームウェアを更新する（Ｓ４０５）。すなわち、不揮発性メモリに既にインストールされているファームウェアが、ファームウェアファイルｆ１に格納されているファームウェアによって上書きされる。ダウンロード部２０３は、また、更新フラグを、例えば、揮発性メモリに記録しておく。
【０１５３】
ステップＳ４０４でＮｏの場合又はステップＳ４０５に続いて、配信元通知部２０４は、ダウンロード要求待ちメッセージｍ６（図９又は図１４参照）を、１ホップ区間限定（すなわち、ホップ数＝０）のブロードキャストで送信する（Ｓ４０６）。
【０１５４】
続いて、受信通知部２０５は、配信元装置１０に対して、受信通知メッセージｍ６（図１０又は図１５参照）をユニキャストで送信する（Ｓ４０７）。
【０１５５】
上述したように、第二の実施の形態によれば、ブロードキャストによって、一つのノードＮから複数のノードＮに対して同時にファームウェアファイルｆ１を配信することができる。したがって、第一の実施の形態に比べて、配信システム１全体の配信時間の短縮化を期待することができる。
【０１５６】
また、ファームウェアファイルｆ１の送信時のブロードキャストのホップ数は限定されているため、ファームウェアファイルｆ１が、多重ホップによって転送されるのを回避することができる。
【０１５７】
なお、各実施の形態において、配信先確認メッセージｆ１やダウンロード要求待ち通知メッセージｍ５のホップ数は、１以上であってもよい。ホップ数が増加された場合、ファームウェアファイルｆ１の配信に関して多重ホップが発生する可能性がある。したがって、各実施の形態が適用されるネットワーク環境において、配信処理の効率性に鑑みて、適切なホップ数が選択されればよい。
【０１５８】
また、ダウンロード済みの隣接ノードの存在の検知は、必ずしも当該隣接ノードにより送信されるダウンロード要求待ち通知メッセージｍ５の受信に基づいて行われなくてもよい。例えば、ダウンロード許可メッセージｍ３を受信したノードが、ダウンロード済みの隣接ノードを探索するために、ホップ数が限定されたブロードキャストを送信してもよい。ダウンロード済みの隣接ノードは、当該ブロードキャストに対して応答を行えばよい。当該応答に基づいて、当該ブロードキャストの送信元のノードＮは、ダウンロード済みの隣接ノードの存在を検知することができる。
【０１５９】
また、配信対象とされるデータは、特定の装置のファームウェアでなくてもよい。電子データであれば、あらゆるデータが配信対象となりうる。
【０１６０】
また、各実施の形態は、有線のネットワーク環境に対して適用されてもよい。
【０１６１】
なお、本実施の形態において、配信先探索部１２は、探索部の一例である。ダウンロード許可部１３は、許可部の一例である。配信元検知部２０１は、検知部の一例である。ダウンロード部２０２は、取得部の一例である。
【０１６２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１６３】
以上の説明に関し、更に以下の項を開示する。
（付記１）
データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法であって、
前記配信元装置が、
探索範囲を複数の段階に分けて拡張して配信先装置を探索し、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、
前記配信先装置が、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、
配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する配信方法。
（付記２）
前記他の配信先装置が、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得する処理は、前記ブロードキャストによって送信される前記データを取得する付記１記載の配信方法。
（付記３）
前記検知する処理は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する付記１又は２記載の配信方法。
（付記４）
前記検知する処理は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する付記１乃至３いずれか一項記載の配信方法。
（付記５）
データの配信元装置と複数の配信先装置とを有する配信システムであって、
前記配信元装置は、
探索範囲を複数の段階に分けて拡張して配信先装置を探索する探索部と、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する許可部とを有し、
前記配信先装置は、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知する検知部と、
配信の許可に応じ、前記他の配信先装置より前記データを取得する取得部とを有する配信システム。
（付記６）
前記他の配信先装置は、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得部は、前記ブロードキャストによって送信される前記データを取得する付記５記載の配信システム。
（付記７）
前記検知部は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する付記５又は６記載の配信システム。
（付記８）
前記検知部は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する付記５乃至７いずれか一項記載の配信システム。
【符号の説明】
【０１６４】
１ 配信システム
１１ ファームウェア受信部
１２ 配信先探索部
１３ ダウンロード許可部
１４ 配信部
１５ 終了検知部
１６ 配信先リスト記憶部
１００ ドライブ装置
１０１ 記録媒体
１０２ 不揮発性メモリ
１０３ 揮発性メモリ
１０４ ＣＰＵ
１０５ インタフェース装置
２０１ 配信元検知部
２０２ 配信要求部
２０３ ダウンロード部
２０４ 配信元通知部
２０５ 受信通知部
２０６ リセット部
２０７ 開始要求受信部
２０８ 配信部
２０９ 終了検知部
２１０ 宛先情報記憶部
Ｂ バス
Ｎ ノード
【特許請求の範囲】
【請求項１】
データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法であって、
前記配信元装置が、
探索範囲を複数の段階に分けて拡張して配信先装置を探索し、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、
前記配信先装置が、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、
配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する配信方法。
【請求項２】
前記他の配信先装置が、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得する処理は、前記ブロードキャストによって送信される前記データを取得する請求項１記載の配信方法。
【請求項３】
前記検知する処理は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する請求項１又は２記載の配信方法。
【請求項４】
前記検知する処理は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する請求項１乃至３いずれか一項記載の配信方法。
【請求項５】
データの配信元装置と複数の配信先装置とを有する配信システムであって、
前記配信元装置は、
探索範囲を複数の段階に分けて拡張して配信先装置を探索する探索部と、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する許可部とを有し、
前記配信先装置は、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知する検知部と、
配信の許可に応じ、前記他の配信先装置より前記データを取得する取得部とを有する配信システム。
【請求項１】
データの配信元装置と複数の配信先装置とを有する配信システムにおける配信方法であって、
前記配信元装置が、
探索範囲を複数の段階に分けて拡張して配信先装置を探索し、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する処理を実行し、
前記配信先装置が、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知し、
配信の許可に応じ、前記他の配信先装置より前記データを取得する処理を実行する配信方法。
【請求項２】
前記他の配信先装置が、ホップ数が限定されたブロードキャストによって前記データを送信し、
前記取得する処理は、前記ブロードキャストによって送信される前記データを取得する請求項１記載の配信方法。
【請求項３】
前記検知する処理は、当該配信先装置が探索された前記段階よりも前の前記段階において前記データを取得した前記他の配信先装置の存在を所定の範囲内において検知する請求項１又は２記載の配信方法。
【請求項４】
前記検知する処理は、前記他の配信先装置が前記データの取得に応じて送信する、前記所定の範囲内にホップ数が限定されたブロードキャストの受信に基づいて、前記他の配信先装置の存在を検知する請求項１乃至３いずれか一項記載の配信方法。
【請求項５】
データの配信元装置と複数の配信先装置とを有する配信システムであって、
前記配信元装置は、
探索範囲を複数の段階に分けて拡張して配信先装置を探索する探索部と、
前記段階ごとに、当該段階において探索された前記各配信先装置に配信を許可する許可部とを有し、
前記配信先装置は、
当該配信先装置よりも前に前記データを取得した他の配信先装置の存在を所定の範囲内において検知する検知部と、
配信の許可に応じ、前記他の配信先装置より前記データを取得する取得部とを有する配信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【公開番号】特開２０１２−２５２５５２（Ｐ２０１２−２５２５５２Ａ）
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願番号】特願２０１１−１２４９９３（Ｐ２０１１−１２４９９３）
【出願日】平成２３年６月３日（２０１１．６．３）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【出願人】（０００００３６８７）東京電力株式会社 (2,580)
【Ｆターム（参考）】
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願日】平成２３年６月３日（２０１１．６．３）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【出願人】（０００００３６８７）東京電力株式会社 (2,580)
【Ｆターム（参考）】
[ Back to top ]