ホームゲートウェイ装置におけるファームウェア管理方法
【課題】ホームゲートウェイ装置におけるホームゲートウェイ装置同士のP2Pネットワークの構築に際して、ホームゲートウェイ装置の出荷時にグループIDを設定することなくP2Pネットワークを構築可能にしてファームウェアの配信を行うファームウェア管理方法を得る。
【解決手段】ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てる（処理Ｘ）ことでホームゲートウェイ装置１同士のP2Pオーバレイネットワーク５を構築し、配信サーバ３から複数のホームゲートウェイ装置にファームウェア配信（配信処理Ａ）が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信（配信処理Ｂ）が行われる。
【解決手段】ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てる（処理Ｘ）ことでホームゲートウェイ装置１同士のP2Pオーバレイネットワーク５を構築し、配信サーバ３から複数のホームゲートウェイ装置にファームウェア配信（配信処理Ａ）が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信（配信処理Ｂ）が行われる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホームゲートウェイ装置におけるファームウェア管理方法に関し、特に、ホームゲートウェイ装置のファームウェアを更新する場合に、複数のホームゲートウェイ同士のP2P通信によりファームウェアの配信を行うファームウェア管理方法に関する。
【背景技術】
【０００２】
近年、ネットワークにおけるブロードバンド市場が拡大し、モデム経由、ルータ経由、セットトップ・ボックス経由、IP電話経由など、さまざまなインターネットアクセスの可能性が広がっている。それと同時に、これらの機器の設定が複雑化し、エンドユーザにとっては、機器の設定操作が煩雑になる現象が生じている。
このような問題に対処するため、機器における様々な種類のアクセスに関する設定が統一的に実現できるプロトコルとして、TR-069(Technical Report 069)が開発されている。
【０００３】
TR-069は、非特許文献１に示されるように、DSLフォーラムで策定された技術仕様（CWMP： Customer premises equipment WAN Management Protocol）であり、エンドユーザ機器の遠隔管理のためのアプリケーション層のプロトコルを定義している。TR-069は、SOAP／HTTP に基づく双方向のプロトコルであり、ホームゲートウェイ装置としてのCPE（広域ネットワーク(WAN) と顧客のネットワークとを接続する機器）と自動設定サーバとしてのACS（ Auto Configuration Servers）との間の通信を規定している。統合的なフレームワークに基づいて、セキュアな自動設定と他のCPE管理機能の制御を規定している。
【０００４】
以下、ホームゲートウェイ装置CPEと自動設定サーバACSとの間でのTR-069によるファームウェア管理機能について説明する。
ホームゲートウェイ装置CPEは任意のタイミングで自動設定サーバACSにアクセスし、ファームウェアの更新要求を出し、ファームウェアのダウンロードを実行する。自動設定サーバACSはホームゲートウェイ装置CPEからのダウンロード要求メッセージを受けて、ファームウェアを転送する処理を実行する。TR-069プロトコルのファームウェアの転送における動作手順を図８の(R1)〜(R13)に示す。
【０００５】
（R1）先ず、ホームゲートウェイ装置CPEと自動設定サーバACSとの間でTCPセッションが確立される。
（R2）次に、SSL接続が開始される。
（R3）HTTP postにより、ファームウェアのダウンロード要求を自動設定サーバACSに送信する。
（R4）自動設定サーバACSはホームゲートウェイ装置CPEに対して、以降リクエスト要求を出さないように、HoldRequestsをtrueにするように命令する。
（R5）ホームゲートウェイ装置CPEはこれ以上、要求メッセージがないことを知らせるempty HTTP postを自動設定サーバACSに送信する。
（R6）そのメッセージを受けて、自動設定サーバACSは新しいファームウェアの送信をホームゲートウェイ装置CPEに対して送信する。
（R7）ホームゲートウェイ装置CPEはファームウェアのダウンロードが終了すると、その事をHTTP postにより通知する。
（R8）自動設定サーバACSはホームゲートウェイ装置CPEに、以後リクエスト要求を出してもいいように、empty HTTP response をホームゲートウェイ装置CPEに対して送信する。
（R9）ホームゲートウェイ装置CPEはファームウェアのダウンロードが成功したかどうかをACSに通知する。
（R10）自動設定サーバACSは、ホームゲートウェイ装置CPEがファームウェアを完全なダウンロードに成功かどうかの有無を認識したことを、ホームゲートウェイ装置CPEに送信する。
（R11）ホームゲートウェイ装置CPEは、これ以上自動設定サーバACSに要求メッセージがないことを知らせるempty HTTP postを自動設定サーバACSに送信する。
（R12）自動設定サーバACSも同様に、ホームゲートウェイ装置CPEに対して送信メッセージがないことを知らせるempty HTTP response を送信する。
（R13）最後にホームゲートウェイ装置CPEのほうから、TCPセッションを終了させる。
【０００６】
上述したTR-069によるファームウェア管理によれば、ホームゲートウェイ装置CPEがファームウェアの更新を定期的に行う際、ホームゲートウェイ装置CPEの方から自動設定サーバACS（センタ側）に対して、ファームウェアの更新の有無を確認することが行われる。
しかしながら、TR-069ではホームゲートウェイ装置CPEからの要求が任意のタイミングで行われるために、図７に示すように、ユーザ側における多数のホームゲートウェイ装置１からインターネット２を介してファームウェアの更新要求がある場合、ホームゲートウェイ装置１の数が膨大であるために、センタ側の配信サーバ３にアクセスが集中して多大な負荷がかかるという問題がある。
【０００７】
今後益々インターネットサービスを利用するユーザが増加するにあたり、その分だけホームゲートウェイ装置からのアクセス数に対応できるように回線を高帯域にするという対策も可能であるが、回線構築コストが高くなるという問題がある。
例えば、一般的に使用されているサーバ製品では同時に接続できる最大のセッション数は３０万セッションである。このとき、ブロードバンド契約者が３００万と仮定すると、その全てのユーザが所有するホームゲートウェイ装置からファームウェアの更新要求が来た場合には、センタサーバ側に大きな負荷がかかることが懸念される。
【０００８】
この問題を解決するため、ホームゲートウェイ装置同士のピュアP2Pによる構造化オーバレイを利用して、ビデオストリーミングを分散配信する方法が例えば非特許文献２に開示されている。
【０００９】
P2P通信とは、多数の端末間で通信を行う際のアーキテクチャのひとつで、対等の装置（ピア）同士が通信をする通信方式である。
P2P通信を行う場合、IPアドレスさえ分かっていれば相手方のピアに到達でき、ピア同士の通信が可能となる。したがってP2Pでは、どのように相手方のIPアドレスを入手するかが重要となり、実際のP2Pでは、コンテンツのタイトルや検索キーワード、放送局のチャンネル名等、何らかの意味のある文言である「キー」を使用することで通信相手を特定して、通信ができるようになっている。
【００１０】
すなわち、P2P通信を行う場合、一般化には「キー」を手かがりにし、「キーに対応するデータを持つ者」を検索し、その相手（装置）と通信をすることが行われる。「キー」と「データ」のペアは、インデックス情報として「データ」を持つ装置のIPアドレスとして記憶されている。
【００１１】
非特許文献２に記載の技術によれば、マルチキャストツリーを識別子で管理することによって、一つのホームゲートウェイ装置で複数の構造化ツリーを持つことができ、それぞれの構造化ツリーに識別子を付与し、ツリー毎にQoS設定を持たせることができる。P2P通信によれば、各装置（ピア）がクライアント機能とサーバ機能を併せ持つよう動作するので、端末数が膨大になっても回線帯域などに余裕がある限り通信が可能となり、端末数の増加による通信品質の劣化を防止できる。
P2Pネットワークを構築する場合、ホームゲートウェイ装置は、出荷時においてP2Pネットワークを構成するグループIDの情報を予め設定しておく。ホームゲートウェイ装置は初めてネットワークに参加する際、そのグループIDを利用して、P2Pネットワークを探索するように構成されている。
【００１２】
非特許文献２で構造化オーバレイを利用している理由としては、データがオーバレイを流れる前に流路（配信木）が定まっているため、データがあるノードに到達するまでの時間（遅延）と、遅延の揺らぎ（ジッタ）を低く抑えやすいという利点と、配信木の形状がデータの流路となるので、配信木の構築を通してデータの流路を厳密に制御できるという利点が考えられる。また、帯域幅の狭い経路、不安定な経路を明示的に避けるといったことも容易に行うことができる。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】Bernstein, J. and Spets. T. ,ed. , "DSL Forum TR-069: CPE WAN Management Protocol", Technical Report, DSL Forum, May 2004.
【非特許文献２】J Garcia-Reinoso, A Bikfalvi, I Vidal, F Valera "FLaCoSt: A Novel Peer to Peer Architecture for Video Streaming in a Next Generation Network" The First International Conference on Advances in P2P Systems. AP2PS 2009. 11-16 October 2009, (Sliema, Malta)
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかしながら、非特許文献２に記載の技術では、ホームゲートウェイ装置にP2P通信を導入するにあたり、ホームゲートウェイ装置がグループIDを認識することでP2Pネットワークを探索するので、P2Pを構成するグループIDを管理し，各ホームゲートウェイ装置をお客様宅へ出荷する際に予め設定しておく必要があった。このグループIDは、固有の値であり動的に変化するものでない。そのため、運用者はIPアドレスに加えグループIDを別途管理する必要があり、管理対象が増加するという問題があった。
【００１５】
また、上述したホームゲートウェイ装置同士のピュアP2Pは、構造化オーバレイなので、親のノードに障害が発生した時や、日常的に起こる突然の離脱などには、ツリー構造を再度構成し直す機構を盛り込む必要があり、ノードに問題が生じると配信の失敗に繋がる現象が生じる。故障や離脱したノードが配信木の根に近かった場合、その影響は大きいものとなる。そのため、ホームゲートウェイ装置を構成する要素は複雑になり、必然と高価になってしまうという問題があった。
【００１６】
本発明は上記事情に鑑みて提案されたもので、ホームネットワーク内のホームデバイスのネットワーク接続設定やインターネットサービス中継の役割を有するホームゲートウェイ装置におけるホームゲートウェイ装置同士のP2Pネットワークの構築に際して、ホームゲートウェイ装置の出荷時にグループIDを設定することなくP2Pネットワークを構築可能にしてホームゲートウェイのファームウェア配信を行うファームウェア管理方法を提供することを目的としている。
【課題を解決するための手段】
【００１７】
上記目的を達成するため本発明のホームゲートウェイ装置におけるファームウェア管理方法は、ホームネットワーク内のホームデバイスのネットワーク接続設定やインターネットサービス中継の役割を有するホームゲートウェイ装置において、地域毎に分割されたサブネット内でホームゲートウェイ装置同士がP2Pネットワークを構成することによりファームウェア配信を行うことを特徴としている。
【００１８】
すなわち、請求項１は、複数のホームゲートウェイ装置に対して配信サーバからファームウェア配信を行うホームゲートウェイ装置におけるファームウェア管理方法において、
前記ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てることでホームゲートウェイ装置同士のP2Pネットワークを構築し、
前記配信サーバから全てのサブネットにおいて、少なくとも１つ以上は最新のファームウェアを持つようにホームゲートウェイ装置にファームウェア配信が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信が行われることを特徴としている。
【００１９】
請求項２は、請求項１のホームゲートウェイ装置におけるファームウェア管理方法において、前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIP アドレスを検索する際に、ファームウェア配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索することで配信元のIPアドレスを決定することを特徴としている。
【００２０】
請求項３は、請求項１のホームゲートウェイ装置におけるファームウェア管理方法において、前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIP アドレスを検索する際に、ファームウェア配信先のホームゲートウェイ装置のIPアドレスからブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせることで配信元のIPアドレスを決定することを特徴としている。
【発明の効果】
【００２１】
本発明方法によれば、ホームゲートウェイ装置同士のP2Pネットワークを構築するに際して、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てるようにしたので、ホームゲートウェイ装置の出荷時に予め独自に識別子（グループID）を設ける必要がなく、配信サーバがファームウェア配信を行う場合にグループIDを管理する必要がないので、運用者の負担軽減を図ることができる。
【００２２】
また、ファームウェア配信元のホームゲートウェイ装置のIPアドレスを配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索、若しくは、ブロードキャストにより問い合わせるので、P2Pネットワークを構築する他のホームゲートウェイ装置のIPアドレスを知らなくとも接続先（配信元）を決定することができる。
【００２３】
また、ファームウェア配信が行われた複数のホームゲートウェイ装置以外のホームゲートウェイ装置については、P2Pネットワークを介してファームウェア配信が行わるので、配信サーバが自らファームウェア配信を行うホームゲートウェイ装置の数を指定でき、セッション数を制限することで配信サーバ側の負荷軽減を図ることができる。
【図面の簡単な説明】
【００２４】
【図１】本発明のファームウェア管理方法が適用される一般的なインターネットサービスの接続環境を示すモデル図である。
【図２】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワーク構成例を示すモデル図である。
【図３】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークによるファームウェア配信を説明するためのモデル図である。
【図４】本発明のファームウェア管理方法が適用されるホームゲートウェイ装置の機能構成を示すブロック図である。
【図５】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークを利用したファームウェア配信動作を示すシーケンス図である。
【図６】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークを利用したファームウェア配信動作の他の例を示すシーケンス図である。
【図７】従来例におけるホームゲートウェイ装置によるファームウェア更新動作を示すモデル図である。
【図８】TR-069プロトコルのファームウェアの転送動作を説明するシーケンス図である。
【発明を実施するための形態】
【００２５】
本発明のホームゲートウェイ装置におけるファームウェア管理方法の実施形態の一例について、図面を参照しながら説明する。
本発明のホームゲートウェイ装置におけるファームウェア管理方法は、ホームゲートウェイ装置同士のP2Pネットワークを利用したファームウェア配信によりファームウェア管理を行うものである。
【００２６】
先ず、本発明方法が適用される複数のホームゲートウェイ装置が設置される接続環境について説明する。ホームゲートウェイ装置が設置される接続環境は、図１に示すような一般的なインターネットサービス環境を想定している。すなわち、ユーザは、ホームゲートウェイ装置１を介してインターネット２に接続し各種サービスを利用する。
ユーザの利用端末の管理を行うセンタ側では、インターネット２に接続され新しいファームウェアを配信するための配信サーバ（センタサーバ）３が設置されている。ユーザのホームゲートウェイ装置１に対しては、ハードウェアの基本的な制御を行なう場合の初期設定や機能更新を行うに際して、インターネット２を介して配信サーバ３からファームウェアが配信することが行われる。
【００２７】
本発明方法が適用される複数のホームゲートウェイ装置は、図２に示すように、各ルータ４に接続された複数のホームゲートウェイ装置１から構成される複数のホームゲートウェイ装置群において、ホームゲートウェイ装置１同士の間でP2Pオーバレイネットワーク５が構成されている。すなわち、通常のIPネットワークの上に、P2P方式での通信網としてもう一層別のネットワーク(Overlay Network)が構築されている。
ルータ４は、複数のホームゲートウェイ装置１に接続され，複数のルータ４と網目状に接続しているとともに、各ホームゲートウェイ装置１と配信サーバ３との接続を管理するものである。
【００２８】
また、図３に示されるように、P2Pオーバレイネットワーク５を構成する各ホームゲートウェイ装置１へは、JPNIC(日本ネットワークインフォメーションセンタ)からある程度まとまった単位で与えられたIPアドレス(例えば「10.10.10.0」〜「10.10.20.254」)を自分たち(ISP：Internet Service Provider)が管理するネットワーク機器であるDHCPサーバ６から各ホームゲートウェイ装置１に割り当てるに際して、日本の地域を分割し各地域でサブネットを構成し、それぞれのサブネット内の配下に、ある連続したIPアドレスを割り当てる（図３中に点線で示す処理Ｘ）ことでサブネット毎にP2Pオーバレイネットワーク５を構成する。また、各サブネットは、サブネットマスク（例えば「255.255.255.0」）を利用することで区別され、ＤＨＣＰサーバ６により管理される。各ホームゲートウェイ装置１は、ＤＨＣＰサーバ６によりＩＰアドレス（例えば「10.10.10.1」）とサブネットマスク（例えば「255.255.255.0」）が設定され、各サブネット（例えば、「10.10.10.0/24」）に所属する。
例えば、図３の例では、サブネットに分割されたネットワークアドレスグループＣ（関東）に設置された複数のホームゲートウェイ装置１が存在する場合、ネットワークアドレスグループＣを構成する一つのサブネット（例えば、「10.10.10.0/24」）に属する各ホームゲートウェイ装置１はネットワークに参加する設定を行うに際して、ルータ４のIPアドレスが「10.10.10.0」である場合には、DHCPサーバ６からその配下の連続したIPアドレス「10.10.10.1」、「10.10.10.2」…「10.10.10.253」、「10.10.10.254」が割り当てられる。
【００２９】
上述のようにサブネット内に存在する各ホームゲートウェイ装置１に対して、連続するIPアドレスを割り振ると、インターネットサービスを提供する上で，経路をまとめることができる。例えば、あるルータ４の傘下にある地域が「10.10.0.0」〜「10.10.255.255」までのアドレスを持っているとすると、この地域内のホームゲートウェイ装置１にアクセスしたかった場合，インターネット上の他のルータは「10.10.0.0/16」の情報だけを基にルーティングを実施すればよい。このように、サブネットごとにある程度連続したアドレスを割り当てたほうが、コアネットワーク部分のルーティングにおいて，各ルータのルーティングテーブルが少なくて済むので，ルータの負担を抑えることができる。
【００３０】
P2Pオーバレイネットワーク５（P2P方式での通信網）を介して各ホームゲートウェイ装置１に送信したファームウェア更新データは、P2Pオーバレイネットワーク５の全てのサブネットの少なくとも１つ以上のホームゲートウェイ装置１に同じ更新データが分散して配置されている。この更新データは、ファームウェアデータが更新された際に、配信サーバ３が選択した複数のホームゲートウェイ装置１にサーバブッシュによるファームウェア配信が行われる（例えば、図３におけるルータ４を介したホームゲートウェイ装置１ａへの配信処理Ａ）。
そして、配信サーバ３に選択されなかった各ホームゲートウェイ装置１には、サブネット内に構築されたP2Pオーバレイネットワーク５を利用することで、例えばホームゲートウェイ装置１ａからホームゲートウェイ装置１ｂに、ホームゲートウェイ装置１ｂからホームゲートウェイ装置１ｃにそれぞれP2P通信により配信される（図３における配信処理Ｂ）。
【００３１】
続いて、ファームウェア管理が行われるホームゲートウェイ装置１の構成について、図４を参照しながら説明する。
ホームゲートウェイ装置１は、ホームネットワークに対するLAN側通信インターフェース１０と、広域ネットワークに対するWAN側通信インターフェース１１と、ファームウェア部１２と、ファームウェアのバージョンを管理するバージョン管理部１３と、自身のIPアドレスを記憶するIPアドレス部１４と、P2P通信の宛先を管理する宛先管理部１５と、ファームウェアの更新要求を送信する更新要求送信部１６と、ファームウェアの更新処理を管理する更新処理管理部１７と、ファームウェアの更新間隔を管理する更新タイマー部１８と、データを中継するデータ中継部１９を備えて構成されている。
【００３２】
LAN側通信インターフェース１０は、利用者端末側のホームネットワークに対して接続を行うためのインターフェースである。WAN側通信インターフェース１１は、配信サーバ側の広域ネットワークに対して接続を行うためのインターフェースである。
【００３３】
ファームウェア部１２は、ハードウェアの基本的な制御を行うためのソフトウェア(ファームウェアそのもの)が保持される部分である。ファームウェア部１２のファームウェア情報は、新しいバージョンのファームウェアが配信された場合は、書き換えられる。
バージョン管理部１３は、ファームウェア部１２に保持されているファームウェアのバージョン情報を管理するもので、ファームウェアの更新要求送信部１６からの更新要求バージョン情報の送信要求信号、及び、更新処理管理部１７からの更新処理完了後のバージョン情報信号を受信するように構成されている。
【００３４】
IPアドレス部１４は、サブネットに設定されているサブネットマスクとともに自身のIPアドレスを格納するもので、インターネットに接続した際に、DHCPサーバ６から割り当てられて記録される。
宛先管理部１５は、IPアドレス部１４に接続されるとともに、更新要求送信部１６からファームウェアの更新要求を受信することでP2P通信の宛先を管理している。
【００３５】
更新要求送信部１６は、WAN側通信インターフェース１１を介して配信サーバ側にファームウェアの更新要求を送信する。
更新処理管理部１７は、WAN側通信インターフェース１１を介して受信した配信サーバからのファームウェアをホームゲートウェイに適用させる更新処理を管理する(ファームウェア部１２を新しいファームウェアに書き換える)。また、バージョン管理部１３へ更新ファームウェア情報のバージョン情報を送信する。バージョン管理部１３は、次回更新要求を出すべきバージョン情報として、受け取ったバージョン情報にプラス１し保持しておく。
【００３６】
更新タイマー部１８は、ファームウェアの更新間隔を管理し、一定時間経過毎に更新要求送信部１６に対して配信サーバへファームウェアの更新要求を行うように管理する。
データ中継部１９は、LAN側通信インターフェース１０とWAN側通信インターフェース１１との間でホームネットワーク側からの通信要求信号とそれに対するWAN側からの応答信号を中継するものである。
【００３７】
次に、本発明のファームウェア管理方法により、各ホームゲートウェイ装置１におけるファームウェアを更新する手順（動作例１）について、図５を参照しながら説明する。図５の動作例１は、P2P通信によるファームウェアの配信に際して、P2Pネットワークを構成するIPアドレスを検索する時、自身のIPアドレスからシーケンシャルに宛先を決定する方法である。
【００３８】
先ず、ホームゲートウェイ装置１がインターネット２を介してサービスに参加すると、DHCPサーバ６からホームゲートウェイ装置１に対して上述したサブネット内において順次IPアドレスが割り当てられる（Ｓ１）。割り当てられたIPアドレスは、IPアドレス部４に記憶される。
ファームウェア配信サーバ３は、ファームウェアの更新があると、全てのサブネットにおいて、現在ネットワーク上に割り当てているホームゲートウェイ装置１のIPアドレスから１つ以上選択し、そのIPアドレスのホームゲートウェイ装置１に対してファームウェアの更新情報をマルチキャストして送信する（Ｓ２）。
【００３９】
ファームウェアの更新情報を受け取ったホームゲートウェイ装置は、自身でファームウェアの更新要求を出すことなく、ファームウェアの更新が完了する（Ｓ３）。
その他のホームゲートウェイ装置１（Ｓ２で選択されなかったホームゲートウェイ装置）は、更新要求送信部１６により任意のタイミングでファームウェアの更新確認動作が実行される（Ｓ４）。
続いてホームゲートウェイ装置１は、自身に設定されているIPアドレスとサブネットマスクを確認する（Ｓ５）。これは、次述するファームウェアの配信要求を求める相手先を決定する際に必要な情報となる。
【００４０】
ホームゲートウェイ装置はそのIPアドレスとサブネットマスクから、自身が所属するネットワークの範囲（サブネット）において、自身に割り当てられているIPアドレスから後ろに一つずつホスト部の数値をずらしたIP アドレスに対して、P2Pを利用してファームウェアの新しいバージョン情報をキーに更新要求を送信する。
例えば、自身のIPアドレスが「10.10.10.253」だった場合には、ホスト部からプラス「１」をしたアドレス「10.10.10.254」を宛先となる配信元のIPアドレスとしてファームウェア更新要求を送信する（Ｓ６）。
【００４１】
ファームウェア更新要求を受け取ったホームゲートウェイ装置は、要求があった新しいファームウェアのバージョンを所持していれば、配信元のIPアドレスが決定され、このIPアドレスから要求があったIPアドレスに対してファームウェアを配信する（Ｓ７）。
要求を出したホームゲートウェイ装置は、新しいファームウェアを受け取り、更新動作を実行する（Ｓ８）。
要求を受けたホームゲートウェイ装置が、新しいファームウェアのバージョンを所持していなければ、所持していないことを知らせるメッセージを逆送信する。P2Pによるネットワークの輻輳を避けるために、ファームウェア更新要求は他へ転送しないこととする（Ｓ９）。
【００４２】
要求を出したホームゲートウェイ装置から、「ファームウェア更新情報無し」のメッセージを受け取ったホームゲートウェイ装置は、一定時間後に自身のIPアドレスのホスト部からさらにプラス「１」をしたアドレス（図５の例では「10.10.10.1」）に要求を送信する（Ｓ１０）。すなわち、自身が所属するサブネットのネットワークの限界値の範囲に達した場合は、最初のIPアドレスに戻る。
例えば、自身が所属するサブネットのサブネットマスクが「255.255.255.0」だった場合には、「10.10.10.1」〜「10.10.10.254」のIPアドレス範囲内で、ファームウェアの更新確認要求を送信する相手を一つずつプラスしていく。この例の場合、自身のIPアドレス「10.10.10.253」から「１」ずつプラスしていき、「255」に達した場合は、また、最初の「10.10.10.1」からプラスしていくことになる。新しいファームウェアを所持するホームゲートウェイ装置に当たるまでこれを繰り返す（Ｓ１１）。
新しいバージョンのファームウェアを受信し、更新を終了したホームゲートウェイ装置は、バージョン管理部における問い合わせバージョン番号を現在のバージョン番号のプラス「１」とする（Ｓ１２）。
【００４３】
ファームウェアの更新を完了したホームゲートウェイは、そのことを知らせる通知をファームウェア配信サーバへ送信する。通知内容は、IPアドレスと、ホームゲートウェイ装置を一意に認識するためのMACアドレス、ファームウェアのバージョン情報、完了日時等が含まれる（Ｓ１３）。
【００４４】
一定期間後に再び（Ｓ６）から繰り返すものとする（Ｓ１４）。
更新要求を送信するためのIPアドレスがネットワーク上に存在しなかった場合には、何の応答も返信されないので、そのときのために更新要求の応答が返ってくるまでのタイムアウト時間を設定する。タイムアウト時間が経過した場合は、次の宛先IPアドレスに更新要求を出すこととする（Ｓ１４）。
【００４５】
自身が所属するサブネット内の宛先IPアドレスに更新されたファームウェアが見つからなかった場合（宛先IPアドレスが一周した場合）には、ファームウェアの更新自体がないか、もしくは、ファームウェア配信サーバが最初にファームウェアを配信する相手の数を制限しているため、そのサブネット内のホームゲートウェイ装置には更新されたファームウェアが配信されなかった可能性のどちらかが考えられる。そのために、自身が所属するサブネット内に更新ファームウェアが見当たらなかった場合には、IPアドレス体系で隣接している他のサブネットに更新要求を送信することとする。
【００４６】
例えば上述の例では、「10.10.11.1」に更新要求を送信し、その後同様にシーケンシャルに「10.10.11.2」、「10.10.11.3」…と問い合わせを繰り返していく。そのサブネットにおいても、見つからなかった場合には、さらに隣接のサブネットに問い合わせの要求を出す。すなわち、「10.10.12.1」に問い合わせを出すこととなる。そのサブネット内で更にシーケンシャルに問い合わせを実施する。複数のサブネットに問い合わせても見つからなければ、初めてファームウェアの更新がないことと判断する。
【００４７】
また、IPアドレス体系で隣接するサブネット自体が存在しない場合には、いくら要求を出しても全く応答が返ってこないことが予想されるので、その場合にはサブネットに該当するIPアドレスの半分の数だけ応答がなければ、そのサブネットは存在しないと判断し、逆のシーケンシャル方向に問い合わせを出すようにする。
例えば、「10.10.11.1」から始めて「10.10.11.148」のIPアドレスに達しても応答が返ってこなかった場合には、「10.10.9.254」に対して要求を出し、逆の方向に宛先の問い合わせを進めるようにする。
【００４８】
続いて、本発明のファームウェア管理方法により、各ホームゲートウェイ装置１におけるファームウェアを更新する他の手順について、図６を参照しながら説明する。
図５の動作例１では、基本的にシーケンシャルに問い合わせ先を変化させる方法であるため、更新されたファームウェアを所持するホームゲートウェイ装置に到達するまでに時間がかかることが予想される。
そこで図６の動作例２では、ブロードキャストによるファームウェアの更新要求を送信する。動作例２では、ファームウェアの更新要求を送信する宛先を決める際に、動作例１によるシーケンシャルな検索ではなく、ブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせを行うようにする。
【００４９】
ホームゲートウェイ装置がインターネットサービスに参加すると、DHCPサーバ６からIPアドレスが割り当てられる（Ｔ１）。
ファームウェア配信サーバは、ファームウェアの更新があると、全てのサブネットにおいて、現在ネットワーク上に割り当てているIPアドレスから１つ以上選択し、そのIPアドレスに対してファームウェアをマルチキャストする（Ｔ２）。
ファームウェアの更新情報を受け取ったホームゲートウェイ装置は、自身でファームウェアの更新要求を出すことなく、ファームウェアの更新が完了する（Ｔ３）。
以上は図５の動作例１と同じである。
【００５０】
その他のホームゲートウェイ装置は任意のタイミングで、ファームウェアの更新確認動作が実行される。本動作例では、ブロードキャストを利用して自身のサブネット内に更新要求を送信する。例えば、自身のIPアドレスが「10.10.10.253」で、サブネットマスクが「255.255.255.0」だった場合には、「10.10.10.255」に対して、ファームウェアの更新要求を送信する（Ｔ４）。
新しいファームウェアの更新情報を持たないホームゲートウェイ装置は、更新要求メッセージを受けると、何も返信しない（Ｔ５）。
【００５１】
新しいファームウェアを持ったホームゲートウェイ装置が、更新要求メッセージを受け取ると、配信元のIPアドレスが決定され、このIPアドレスから要求があったIPアドレスのホームゲートウェイ装置に新しいファームウェアを配信する（Ｔ６）。
新しいファームウェアを受信した当該ホームゲートウェイ装置は、自身のファームウェアを更新する（Ｔ７）。
【００５２】
次回の問い合わせ時に利用されるファームウェアのバージョン情報をプラス「１」にし、保持しておく（Ｔ８）。
ファームウェアの更新を完了したホームゲートウェイ装置は、ファームウェア配信サーバに対して、更新完了のメッセージを送信する（Ｔ９）。
その後、ある一定期間経過したのちに、再び（Ｔ４）から繰り返す（Ｔ１０）。
【００５３】
動作例２においても、自身が所属するサブネット内のどのホームゲートウェイ装置からも応答がない場合が考えられる。そのときには、動作例１と同様に、応答時間の制限を設けて、一定時間待っても応答がなかった場合には、そのサブネット内には新しいファームウェアを持ったホームゲートウェイ装置がないと判断し、別のサブネットに対してブロードキャストを行う。そのサブネットからも返ってこなかった場合には、さらに別のサブネットにブロードキャスト送信というように複数回繰り返し、それでも応答がなかった場合には、初めてファームウェアの更新がないことを判断する。その後、一定期間待った後に、再度自身が所属するサブネット内に対してファームウェア装置の更新要求メッセージをブロードキャストする（Ｔ１０）。
【００５４】
上述したホームゲートウェイ装置におけるファームウェア管理方法によれば、ホームゲートウェイ装置が設置される地域に基づいてP2Pオーバレイネットワーク５を構成するグループ（サブネット）内で、ホームゲートウェイ装置１のIPアドレスを順次割り当てるようにしたので、グループ内に独自に識別子を設ける必要がない。そのため、運用側ではDHCP程度のIPアドレス管理機能があれば、サブネット内のホームゲートウェイ装置１に対してIPアドレスの割り当てを行うことが可能であるので、運用側の負担軽減を図ることができる。
【００５５】
また、P2Pオーバレイネットワーク５において、更新ファームウェア情報を取得するホームゲートウェイ装置１は任意の数が存在するので、基本的に非構造化オーバレイを構成することになり、あるホームゲートウェイ装置１に故障が発生したり、電源をOFFにしたりした場合であっても、複雑な処理を施す必要なく更新ファームウェア情報が配信可能となるので、ホームゲートウェイ装置自体を安価に構成することができる。
【００５６】
また、ファームウェア配信元のホームゲートウェイ装置のIPアドレスを配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索（動作例１）、若しくは、ブロードキャストにより問い合わせる（動作例２）ので、P2Pネットワークを構築する他のホームゲートウェイ装置のIPアドレスを知らなくとも接続先（配信元）を決定し、更新ファームウェア情報を配信可能とすることができる。
【００５７】
また、ファームウェア配信サーバ３が自らファームウェアを配信させるホームゲートウェイ装置１の数を指定できるので、ファームウェア配信サーバ側において、ネットワークの負荷及びサーバの負荷を軽減することができる。
その結果、サーバの低スペック化を実現し、更には回線容量の低減化を図ることで、全体的なネットワークコスト削減を実現することができる。
【符号の説明】
【００５８】
１…ホームゲートウェイ装置、 ２…インターネット、 ３…配信サーバ、 ４…ルータ、 ５…P2Pオーバレイネットワーク、 ６…DHCPサーバ、 １０…LAN側通信インターフェース、 １１…WAN側通信インターフェース、 １２…ファームウェア部、 １３…バージョン管理部、 １４…IPアドレス部 １５…宛先管理部、 １６…更新要求送信部、 １７…更新処理管理部、 １８…更新タイマー部、１９…データ中継部。
【技術分野】
【０００１】
本発明は、ホームゲートウェイ装置におけるファームウェア管理方法に関し、特に、ホームゲートウェイ装置のファームウェアを更新する場合に、複数のホームゲートウェイ同士のP2P通信によりファームウェアの配信を行うファームウェア管理方法に関する。
【背景技術】
【０００２】
近年、ネットワークにおけるブロードバンド市場が拡大し、モデム経由、ルータ経由、セットトップ・ボックス経由、IP電話経由など、さまざまなインターネットアクセスの可能性が広がっている。それと同時に、これらの機器の設定が複雑化し、エンドユーザにとっては、機器の設定操作が煩雑になる現象が生じている。
このような問題に対処するため、機器における様々な種類のアクセスに関する設定が統一的に実現できるプロトコルとして、TR-069(Technical Report 069)が開発されている。
【０００３】
TR-069は、非特許文献１に示されるように、DSLフォーラムで策定された技術仕様（CWMP： Customer premises equipment WAN Management Protocol）であり、エンドユーザ機器の遠隔管理のためのアプリケーション層のプロトコルを定義している。TR-069は、SOAP／HTTP に基づく双方向のプロトコルであり、ホームゲートウェイ装置としてのCPE（広域ネットワーク(WAN) と顧客のネットワークとを接続する機器）と自動設定サーバとしてのACS（ Auto Configuration Servers）との間の通信を規定している。統合的なフレームワークに基づいて、セキュアな自動設定と他のCPE管理機能の制御を規定している。
【０００４】
以下、ホームゲートウェイ装置CPEと自動設定サーバACSとの間でのTR-069によるファームウェア管理機能について説明する。
ホームゲートウェイ装置CPEは任意のタイミングで自動設定サーバACSにアクセスし、ファームウェアの更新要求を出し、ファームウェアのダウンロードを実行する。自動設定サーバACSはホームゲートウェイ装置CPEからのダウンロード要求メッセージを受けて、ファームウェアを転送する処理を実行する。TR-069プロトコルのファームウェアの転送における動作手順を図８の(R1)〜(R13)に示す。
【０００５】
（R1）先ず、ホームゲートウェイ装置CPEと自動設定サーバACSとの間でTCPセッションが確立される。
（R2）次に、SSL接続が開始される。
（R3）HTTP postにより、ファームウェアのダウンロード要求を自動設定サーバACSに送信する。
（R4）自動設定サーバACSはホームゲートウェイ装置CPEに対して、以降リクエスト要求を出さないように、HoldRequestsをtrueにするように命令する。
（R5）ホームゲートウェイ装置CPEはこれ以上、要求メッセージがないことを知らせるempty HTTP postを自動設定サーバACSに送信する。
（R6）そのメッセージを受けて、自動設定サーバACSは新しいファームウェアの送信をホームゲートウェイ装置CPEに対して送信する。
（R7）ホームゲートウェイ装置CPEはファームウェアのダウンロードが終了すると、その事をHTTP postにより通知する。
（R8）自動設定サーバACSはホームゲートウェイ装置CPEに、以後リクエスト要求を出してもいいように、empty HTTP response をホームゲートウェイ装置CPEに対して送信する。
（R9）ホームゲートウェイ装置CPEはファームウェアのダウンロードが成功したかどうかをACSに通知する。
（R10）自動設定サーバACSは、ホームゲートウェイ装置CPEがファームウェアを完全なダウンロードに成功かどうかの有無を認識したことを、ホームゲートウェイ装置CPEに送信する。
（R11）ホームゲートウェイ装置CPEは、これ以上自動設定サーバACSに要求メッセージがないことを知らせるempty HTTP postを自動設定サーバACSに送信する。
（R12）自動設定サーバACSも同様に、ホームゲートウェイ装置CPEに対して送信メッセージがないことを知らせるempty HTTP response を送信する。
（R13）最後にホームゲートウェイ装置CPEのほうから、TCPセッションを終了させる。
【０００６】
上述したTR-069によるファームウェア管理によれば、ホームゲートウェイ装置CPEがファームウェアの更新を定期的に行う際、ホームゲートウェイ装置CPEの方から自動設定サーバACS（センタ側）に対して、ファームウェアの更新の有無を確認することが行われる。
しかしながら、TR-069ではホームゲートウェイ装置CPEからの要求が任意のタイミングで行われるために、図７に示すように、ユーザ側における多数のホームゲートウェイ装置１からインターネット２を介してファームウェアの更新要求がある場合、ホームゲートウェイ装置１の数が膨大であるために、センタ側の配信サーバ３にアクセスが集中して多大な負荷がかかるという問題がある。
【０００７】
今後益々インターネットサービスを利用するユーザが増加するにあたり、その分だけホームゲートウェイ装置からのアクセス数に対応できるように回線を高帯域にするという対策も可能であるが、回線構築コストが高くなるという問題がある。
例えば、一般的に使用されているサーバ製品では同時に接続できる最大のセッション数は３０万セッションである。このとき、ブロードバンド契約者が３００万と仮定すると、その全てのユーザが所有するホームゲートウェイ装置からファームウェアの更新要求が来た場合には、センタサーバ側に大きな負荷がかかることが懸念される。
【０００８】
この問題を解決するため、ホームゲートウェイ装置同士のピュアP2Pによる構造化オーバレイを利用して、ビデオストリーミングを分散配信する方法が例えば非特許文献２に開示されている。
【０００９】
P2P通信とは、多数の端末間で通信を行う際のアーキテクチャのひとつで、対等の装置（ピア）同士が通信をする通信方式である。
P2P通信を行う場合、IPアドレスさえ分かっていれば相手方のピアに到達でき、ピア同士の通信が可能となる。したがってP2Pでは、どのように相手方のIPアドレスを入手するかが重要となり、実際のP2Pでは、コンテンツのタイトルや検索キーワード、放送局のチャンネル名等、何らかの意味のある文言である「キー」を使用することで通信相手を特定して、通信ができるようになっている。
【００１０】
すなわち、P2P通信を行う場合、一般化には「キー」を手かがりにし、「キーに対応するデータを持つ者」を検索し、その相手（装置）と通信をすることが行われる。「キー」と「データ」のペアは、インデックス情報として「データ」を持つ装置のIPアドレスとして記憶されている。
【００１１】
非特許文献２に記載の技術によれば、マルチキャストツリーを識別子で管理することによって、一つのホームゲートウェイ装置で複数の構造化ツリーを持つことができ、それぞれの構造化ツリーに識別子を付与し、ツリー毎にQoS設定を持たせることができる。P2P通信によれば、各装置（ピア）がクライアント機能とサーバ機能を併せ持つよう動作するので、端末数が膨大になっても回線帯域などに余裕がある限り通信が可能となり、端末数の増加による通信品質の劣化を防止できる。
P2Pネットワークを構築する場合、ホームゲートウェイ装置は、出荷時においてP2Pネットワークを構成するグループIDの情報を予め設定しておく。ホームゲートウェイ装置は初めてネットワークに参加する際、そのグループIDを利用して、P2Pネットワークを探索するように構成されている。
【００１２】
非特許文献２で構造化オーバレイを利用している理由としては、データがオーバレイを流れる前に流路（配信木）が定まっているため、データがあるノードに到達するまでの時間（遅延）と、遅延の揺らぎ（ジッタ）を低く抑えやすいという利点と、配信木の形状がデータの流路となるので、配信木の構築を通してデータの流路を厳密に制御できるという利点が考えられる。また、帯域幅の狭い経路、不安定な経路を明示的に避けるといったことも容易に行うことができる。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】Bernstein, J. and Spets. T. ,ed. , "DSL Forum TR-069: CPE WAN Management Protocol", Technical Report, DSL Forum, May 2004.
【非特許文献２】J Garcia-Reinoso, A Bikfalvi, I Vidal, F Valera "FLaCoSt: A Novel Peer to Peer Architecture for Video Streaming in a Next Generation Network" The First International Conference on Advances in P2P Systems. AP2PS 2009. 11-16 October 2009, (Sliema, Malta)
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかしながら、非特許文献２に記載の技術では、ホームゲートウェイ装置にP2P通信を導入するにあたり、ホームゲートウェイ装置がグループIDを認識することでP2Pネットワークを探索するので、P2Pを構成するグループIDを管理し，各ホームゲートウェイ装置をお客様宅へ出荷する際に予め設定しておく必要があった。このグループIDは、固有の値であり動的に変化するものでない。そのため、運用者はIPアドレスに加えグループIDを別途管理する必要があり、管理対象が増加するという問題があった。
【００１５】
また、上述したホームゲートウェイ装置同士のピュアP2Pは、構造化オーバレイなので、親のノードに障害が発生した時や、日常的に起こる突然の離脱などには、ツリー構造を再度構成し直す機構を盛り込む必要があり、ノードに問題が生じると配信の失敗に繋がる現象が生じる。故障や離脱したノードが配信木の根に近かった場合、その影響は大きいものとなる。そのため、ホームゲートウェイ装置を構成する要素は複雑になり、必然と高価になってしまうという問題があった。
【００１６】
本発明は上記事情に鑑みて提案されたもので、ホームネットワーク内のホームデバイスのネットワーク接続設定やインターネットサービス中継の役割を有するホームゲートウェイ装置におけるホームゲートウェイ装置同士のP2Pネットワークの構築に際して、ホームゲートウェイ装置の出荷時にグループIDを設定することなくP2Pネットワークを構築可能にしてホームゲートウェイのファームウェア配信を行うファームウェア管理方法を提供することを目的としている。
【課題を解決するための手段】
【００１７】
上記目的を達成するため本発明のホームゲートウェイ装置におけるファームウェア管理方法は、ホームネットワーク内のホームデバイスのネットワーク接続設定やインターネットサービス中継の役割を有するホームゲートウェイ装置において、地域毎に分割されたサブネット内でホームゲートウェイ装置同士がP2Pネットワークを構成することによりファームウェア配信を行うことを特徴としている。
【００１８】
すなわち、請求項１は、複数のホームゲートウェイ装置に対して配信サーバからファームウェア配信を行うホームゲートウェイ装置におけるファームウェア管理方法において、
前記ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てることでホームゲートウェイ装置同士のP2Pネットワークを構築し、
前記配信サーバから全てのサブネットにおいて、少なくとも１つ以上は最新のファームウェアを持つようにホームゲートウェイ装置にファームウェア配信が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信が行われることを特徴としている。
【００１９】
請求項２は、請求項１のホームゲートウェイ装置におけるファームウェア管理方法において、前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIP アドレスを検索する際に、ファームウェア配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索することで配信元のIPアドレスを決定することを特徴としている。
【００２０】
請求項３は、請求項１のホームゲートウェイ装置におけるファームウェア管理方法において、前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIP アドレスを検索する際に、ファームウェア配信先のホームゲートウェイ装置のIPアドレスからブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせることで配信元のIPアドレスを決定することを特徴としている。
【発明の効果】
【００２１】
本発明方法によれば、ホームゲートウェイ装置同士のP2Pネットワークを構築するに際して、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てるようにしたので、ホームゲートウェイ装置の出荷時に予め独自に識別子（グループID）を設ける必要がなく、配信サーバがファームウェア配信を行う場合にグループIDを管理する必要がないので、運用者の負担軽減を図ることができる。
【００２２】
また、ファームウェア配信元のホームゲートウェイ装置のIPアドレスを配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索、若しくは、ブロードキャストにより問い合わせるので、P2Pネットワークを構築する他のホームゲートウェイ装置のIPアドレスを知らなくとも接続先（配信元）を決定することができる。
【００２３】
また、ファームウェア配信が行われた複数のホームゲートウェイ装置以外のホームゲートウェイ装置については、P2Pネットワークを介してファームウェア配信が行わるので、配信サーバが自らファームウェア配信を行うホームゲートウェイ装置の数を指定でき、セッション数を制限することで配信サーバ側の負荷軽減を図ることができる。
【図面の簡単な説明】
【００２４】
【図１】本発明のファームウェア管理方法が適用される一般的なインターネットサービスの接続環境を示すモデル図である。
【図２】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワーク構成例を示すモデル図である。
【図３】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークによるファームウェア配信を説明するためのモデル図である。
【図４】本発明のファームウェア管理方法が適用されるホームゲートウェイ装置の機能構成を示すブロック図である。
【図５】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークを利用したファームウェア配信動作を示すシーケンス図である。
【図６】本発明のファームウェア管理方法が適用されるP2Pオーバレイネットワークを利用したファームウェア配信動作の他の例を示すシーケンス図である。
【図７】従来例におけるホームゲートウェイ装置によるファームウェア更新動作を示すモデル図である。
【図８】TR-069プロトコルのファームウェアの転送動作を説明するシーケンス図である。
【発明を実施するための形態】
【００２５】
本発明のホームゲートウェイ装置におけるファームウェア管理方法の実施形態の一例について、図面を参照しながら説明する。
本発明のホームゲートウェイ装置におけるファームウェア管理方法は、ホームゲートウェイ装置同士のP2Pネットワークを利用したファームウェア配信によりファームウェア管理を行うものである。
【００２６】
先ず、本発明方法が適用される複数のホームゲートウェイ装置が設置される接続環境について説明する。ホームゲートウェイ装置が設置される接続環境は、図１に示すような一般的なインターネットサービス環境を想定している。すなわち、ユーザは、ホームゲートウェイ装置１を介してインターネット２に接続し各種サービスを利用する。
ユーザの利用端末の管理を行うセンタ側では、インターネット２に接続され新しいファームウェアを配信するための配信サーバ（センタサーバ）３が設置されている。ユーザのホームゲートウェイ装置１に対しては、ハードウェアの基本的な制御を行なう場合の初期設定や機能更新を行うに際して、インターネット２を介して配信サーバ３からファームウェアが配信することが行われる。
【００２７】
本発明方法が適用される複数のホームゲートウェイ装置は、図２に示すように、各ルータ４に接続された複数のホームゲートウェイ装置１から構成される複数のホームゲートウェイ装置群において、ホームゲートウェイ装置１同士の間でP2Pオーバレイネットワーク５が構成されている。すなわち、通常のIPネットワークの上に、P2P方式での通信網としてもう一層別のネットワーク(Overlay Network)が構築されている。
ルータ４は、複数のホームゲートウェイ装置１に接続され，複数のルータ４と網目状に接続しているとともに、各ホームゲートウェイ装置１と配信サーバ３との接続を管理するものである。
【００２８】
また、図３に示されるように、P2Pオーバレイネットワーク５を構成する各ホームゲートウェイ装置１へは、JPNIC(日本ネットワークインフォメーションセンタ)からある程度まとまった単位で与えられたIPアドレス(例えば「10.10.10.0」〜「10.10.20.254」)を自分たち(ISP：Internet Service Provider)が管理するネットワーク機器であるDHCPサーバ６から各ホームゲートウェイ装置１に割り当てるに際して、日本の地域を分割し各地域でサブネットを構成し、それぞれのサブネット内の配下に、ある連続したIPアドレスを割り当てる（図３中に点線で示す処理Ｘ）ことでサブネット毎にP2Pオーバレイネットワーク５を構成する。また、各サブネットは、サブネットマスク（例えば「255.255.255.0」）を利用することで区別され、ＤＨＣＰサーバ６により管理される。各ホームゲートウェイ装置１は、ＤＨＣＰサーバ６によりＩＰアドレス（例えば「10.10.10.1」）とサブネットマスク（例えば「255.255.255.0」）が設定され、各サブネット（例えば、「10.10.10.0/24」）に所属する。
例えば、図３の例では、サブネットに分割されたネットワークアドレスグループＣ（関東）に設置された複数のホームゲートウェイ装置１が存在する場合、ネットワークアドレスグループＣを構成する一つのサブネット（例えば、「10.10.10.0/24」）に属する各ホームゲートウェイ装置１はネットワークに参加する設定を行うに際して、ルータ４のIPアドレスが「10.10.10.0」である場合には、DHCPサーバ６からその配下の連続したIPアドレス「10.10.10.1」、「10.10.10.2」…「10.10.10.253」、「10.10.10.254」が割り当てられる。
【００２９】
上述のようにサブネット内に存在する各ホームゲートウェイ装置１に対して、連続するIPアドレスを割り振ると、インターネットサービスを提供する上で，経路をまとめることができる。例えば、あるルータ４の傘下にある地域が「10.10.0.0」〜「10.10.255.255」までのアドレスを持っているとすると、この地域内のホームゲートウェイ装置１にアクセスしたかった場合，インターネット上の他のルータは「10.10.0.0/16」の情報だけを基にルーティングを実施すればよい。このように、サブネットごとにある程度連続したアドレスを割り当てたほうが、コアネットワーク部分のルーティングにおいて，各ルータのルーティングテーブルが少なくて済むので，ルータの負担を抑えることができる。
【００３０】
P2Pオーバレイネットワーク５（P2P方式での通信網）を介して各ホームゲートウェイ装置１に送信したファームウェア更新データは、P2Pオーバレイネットワーク５の全てのサブネットの少なくとも１つ以上のホームゲートウェイ装置１に同じ更新データが分散して配置されている。この更新データは、ファームウェアデータが更新された際に、配信サーバ３が選択した複数のホームゲートウェイ装置１にサーバブッシュによるファームウェア配信が行われる（例えば、図３におけるルータ４を介したホームゲートウェイ装置１ａへの配信処理Ａ）。
そして、配信サーバ３に選択されなかった各ホームゲートウェイ装置１には、サブネット内に構築されたP2Pオーバレイネットワーク５を利用することで、例えばホームゲートウェイ装置１ａからホームゲートウェイ装置１ｂに、ホームゲートウェイ装置１ｂからホームゲートウェイ装置１ｃにそれぞれP2P通信により配信される（図３における配信処理Ｂ）。
【００３１】
続いて、ファームウェア管理が行われるホームゲートウェイ装置１の構成について、図４を参照しながら説明する。
ホームゲートウェイ装置１は、ホームネットワークに対するLAN側通信インターフェース１０と、広域ネットワークに対するWAN側通信インターフェース１１と、ファームウェア部１２と、ファームウェアのバージョンを管理するバージョン管理部１３と、自身のIPアドレスを記憶するIPアドレス部１４と、P2P通信の宛先を管理する宛先管理部１５と、ファームウェアの更新要求を送信する更新要求送信部１６と、ファームウェアの更新処理を管理する更新処理管理部１７と、ファームウェアの更新間隔を管理する更新タイマー部１８と、データを中継するデータ中継部１９を備えて構成されている。
【００３２】
LAN側通信インターフェース１０は、利用者端末側のホームネットワークに対して接続を行うためのインターフェースである。WAN側通信インターフェース１１は、配信サーバ側の広域ネットワークに対して接続を行うためのインターフェースである。
【００３３】
ファームウェア部１２は、ハードウェアの基本的な制御を行うためのソフトウェア(ファームウェアそのもの)が保持される部分である。ファームウェア部１２のファームウェア情報は、新しいバージョンのファームウェアが配信された場合は、書き換えられる。
バージョン管理部１３は、ファームウェア部１２に保持されているファームウェアのバージョン情報を管理するもので、ファームウェアの更新要求送信部１６からの更新要求バージョン情報の送信要求信号、及び、更新処理管理部１７からの更新処理完了後のバージョン情報信号を受信するように構成されている。
【００３４】
IPアドレス部１４は、サブネットに設定されているサブネットマスクとともに自身のIPアドレスを格納するもので、インターネットに接続した際に、DHCPサーバ６から割り当てられて記録される。
宛先管理部１５は、IPアドレス部１４に接続されるとともに、更新要求送信部１６からファームウェアの更新要求を受信することでP2P通信の宛先を管理している。
【００３５】
更新要求送信部１６は、WAN側通信インターフェース１１を介して配信サーバ側にファームウェアの更新要求を送信する。
更新処理管理部１７は、WAN側通信インターフェース１１を介して受信した配信サーバからのファームウェアをホームゲートウェイに適用させる更新処理を管理する(ファームウェア部１２を新しいファームウェアに書き換える)。また、バージョン管理部１３へ更新ファームウェア情報のバージョン情報を送信する。バージョン管理部１３は、次回更新要求を出すべきバージョン情報として、受け取ったバージョン情報にプラス１し保持しておく。
【００３６】
更新タイマー部１８は、ファームウェアの更新間隔を管理し、一定時間経過毎に更新要求送信部１６に対して配信サーバへファームウェアの更新要求を行うように管理する。
データ中継部１９は、LAN側通信インターフェース１０とWAN側通信インターフェース１１との間でホームネットワーク側からの通信要求信号とそれに対するWAN側からの応答信号を中継するものである。
【００３７】
次に、本発明のファームウェア管理方法により、各ホームゲートウェイ装置１におけるファームウェアを更新する手順（動作例１）について、図５を参照しながら説明する。図５の動作例１は、P2P通信によるファームウェアの配信に際して、P2Pネットワークを構成するIPアドレスを検索する時、自身のIPアドレスからシーケンシャルに宛先を決定する方法である。
【００３８】
先ず、ホームゲートウェイ装置１がインターネット２を介してサービスに参加すると、DHCPサーバ６からホームゲートウェイ装置１に対して上述したサブネット内において順次IPアドレスが割り当てられる（Ｓ１）。割り当てられたIPアドレスは、IPアドレス部４に記憶される。
ファームウェア配信サーバ３は、ファームウェアの更新があると、全てのサブネットにおいて、現在ネットワーク上に割り当てているホームゲートウェイ装置１のIPアドレスから１つ以上選択し、そのIPアドレスのホームゲートウェイ装置１に対してファームウェアの更新情報をマルチキャストして送信する（Ｓ２）。
【００３９】
ファームウェアの更新情報を受け取ったホームゲートウェイ装置は、自身でファームウェアの更新要求を出すことなく、ファームウェアの更新が完了する（Ｓ３）。
その他のホームゲートウェイ装置１（Ｓ２で選択されなかったホームゲートウェイ装置）は、更新要求送信部１６により任意のタイミングでファームウェアの更新確認動作が実行される（Ｓ４）。
続いてホームゲートウェイ装置１は、自身に設定されているIPアドレスとサブネットマスクを確認する（Ｓ５）。これは、次述するファームウェアの配信要求を求める相手先を決定する際に必要な情報となる。
【００４０】
ホームゲートウェイ装置はそのIPアドレスとサブネットマスクから、自身が所属するネットワークの範囲（サブネット）において、自身に割り当てられているIPアドレスから後ろに一つずつホスト部の数値をずらしたIP アドレスに対して、P2Pを利用してファームウェアの新しいバージョン情報をキーに更新要求を送信する。
例えば、自身のIPアドレスが「10.10.10.253」だった場合には、ホスト部からプラス「１」をしたアドレス「10.10.10.254」を宛先となる配信元のIPアドレスとしてファームウェア更新要求を送信する（Ｓ６）。
【００４１】
ファームウェア更新要求を受け取ったホームゲートウェイ装置は、要求があった新しいファームウェアのバージョンを所持していれば、配信元のIPアドレスが決定され、このIPアドレスから要求があったIPアドレスに対してファームウェアを配信する（Ｓ７）。
要求を出したホームゲートウェイ装置は、新しいファームウェアを受け取り、更新動作を実行する（Ｓ８）。
要求を受けたホームゲートウェイ装置が、新しいファームウェアのバージョンを所持していなければ、所持していないことを知らせるメッセージを逆送信する。P2Pによるネットワークの輻輳を避けるために、ファームウェア更新要求は他へ転送しないこととする（Ｓ９）。
【００４２】
要求を出したホームゲートウェイ装置から、「ファームウェア更新情報無し」のメッセージを受け取ったホームゲートウェイ装置は、一定時間後に自身のIPアドレスのホスト部からさらにプラス「１」をしたアドレス（図５の例では「10.10.10.1」）に要求を送信する（Ｓ１０）。すなわち、自身が所属するサブネットのネットワークの限界値の範囲に達した場合は、最初のIPアドレスに戻る。
例えば、自身が所属するサブネットのサブネットマスクが「255.255.255.0」だった場合には、「10.10.10.1」〜「10.10.10.254」のIPアドレス範囲内で、ファームウェアの更新確認要求を送信する相手を一つずつプラスしていく。この例の場合、自身のIPアドレス「10.10.10.253」から「１」ずつプラスしていき、「255」に達した場合は、また、最初の「10.10.10.1」からプラスしていくことになる。新しいファームウェアを所持するホームゲートウェイ装置に当たるまでこれを繰り返す（Ｓ１１）。
新しいバージョンのファームウェアを受信し、更新を終了したホームゲートウェイ装置は、バージョン管理部における問い合わせバージョン番号を現在のバージョン番号のプラス「１」とする（Ｓ１２）。
【００４３】
ファームウェアの更新を完了したホームゲートウェイは、そのことを知らせる通知をファームウェア配信サーバへ送信する。通知内容は、IPアドレスと、ホームゲートウェイ装置を一意に認識するためのMACアドレス、ファームウェアのバージョン情報、完了日時等が含まれる（Ｓ１３）。
【００４４】
一定期間後に再び（Ｓ６）から繰り返すものとする（Ｓ１４）。
更新要求を送信するためのIPアドレスがネットワーク上に存在しなかった場合には、何の応答も返信されないので、そのときのために更新要求の応答が返ってくるまでのタイムアウト時間を設定する。タイムアウト時間が経過した場合は、次の宛先IPアドレスに更新要求を出すこととする（Ｓ１４）。
【００４５】
自身が所属するサブネット内の宛先IPアドレスに更新されたファームウェアが見つからなかった場合（宛先IPアドレスが一周した場合）には、ファームウェアの更新自体がないか、もしくは、ファームウェア配信サーバが最初にファームウェアを配信する相手の数を制限しているため、そのサブネット内のホームゲートウェイ装置には更新されたファームウェアが配信されなかった可能性のどちらかが考えられる。そのために、自身が所属するサブネット内に更新ファームウェアが見当たらなかった場合には、IPアドレス体系で隣接している他のサブネットに更新要求を送信することとする。
【００４６】
例えば上述の例では、「10.10.11.1」に更新要求を送信し、その後同様にシーケンシャルに「10.10.11.2」、「10.10.11.3」…と問い合わせを繰り返していく。そのサブネットにおいても、見つからなかった場合には、さらに隣接のサブネットに問い合わせの要求を出す。すなわち、「10.10.12.1」に問い合わせを出すこととなる。そのサブネット内で更にシーケンシャルに問い合わせを実施する。複数のサブネットに問い合わせても見つからなければ、初めてファームウェアの更新がないことと判断する。
【００４７】
また、IPアドレス体系で隣接するサブネット自体が存在しない場合には、いくら要求を出しても全く応答が返ってこないことが予想されるので、その場合にはサブネットに該当するIPアドレスの半分の数だけ応答がなければ、そのサブネットは存在しないと判断し、逆のシーケンシャル方向に問い合わせを出すようにする。
例えば、「10.10.11.1」から始めて「10.10.11.148」のIPアドレスに達しても応答が返ってこなかった場合には、「10.10.9.254」に対して要求を出し、逆の方向に宛先の問い合わせを進めるようにする。
【００４８】
続いて、本発明のファームウェア管理方法により、各ホームゲートウェイ装置１におけるファームウェアを更新する他の手順について、図６を参照しながら説明する。
図５の動作例１では、基本的にシーケンシャルに問い合わせ先を変化させる方法であるため、更新されたファームウェアを所持するホームゲートウェイ装置に到達するまでに時間がかかることが予想される。
そこで図６の動作例２では、ブロードキャストによるファームウェアの更新要求を送信する。動作例２では、ファームウェアの更新要求を送信する宛先を決める際に、動作例１によるシーケンシャルな検索ではなく、ブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせを行うようにする。
【００４９】
ホームゲートウェイ装置がインターネットサービスに参加すると、DHCPサーバ６からIPアドレスが割り当てられる（Ｔ１）。
ファームウェア配信サーバは、ファームウェアの更新があると、全てのサブネットにおいて、現在ネットワーク上に割り当てているIPアドレスから１つ以上選択し、そのIPアドレスに対してファームウェアをマルチキャストする（Ｔ２）。
ファームウェアの更新情報を受け取ったホームゲートウェイ装置は、自身でファームウェアの更新要求を出すことなく、ファームウェアの更新が完了する（Ｔ３）。
以上は図５の動作例１と同じである。
【００５０】
その他のホームゲートウェイ装置は任意のタイミングで、ファームウェアの更新確認動作が実行される。本動作例では、ブロードキャストを利用して自身のサブネット内に更新要求を送信する。例えば、自身のIPアドレスが「10.10.10.253」で、サブネットマスクが「255.255.255.0」だった場合には、「10.10.10.255」に対して、ファームウェアの更新要求を送信する（Ｔ４）。
新しいファームウェアの更新情報を持たないホームゲートウェイ装置は、更新要求メッセージを受けると、何も返信しない（Ｔ５）。
【００５１】
新しいファームウェアを持ったホームゲートウェイ装置が、更新要求メッセージを受け取ると、配信元のIPアドレスが決定され、このIPアドレスから要求があったIPアドレスのホームゲートウェイ装置に新しいファームウェアを配信する（Ｔ６）。
新しいファームウェアを受信した当該ホームゲートウェイ装置は、自身のファームウェアを更新する（Ｔ７）。
【００５２】
次回の問い合わせ時に利用されるファームウェアのバージョン情報をプラス「１」にし、保持しておく（Ｔ８）。
ファームウェアの更新を完了したホームゲートウェイ装置は、ファームウェア配信サーバに対して、更新完了のメッセージを送信する（Ｔ９）。
その後、ある一定期間経過したのちに、再び（Ｔ４）から繰り返す（Ｔ１０）。
【００５３】
動作例２においても、自身が所属するサブネット内のどのホームゲートウェイ装置からも応答がない場合が考えられる。そのときには、動作例１と同様に、応答時間の制限を設けて、一定時間待っても応答がなかった場合には、そのサブネット内には新しいファームウェアを持ったホームゲートウェイ装置がないと判断し、別のサブネットに対してブロードキャストを行う。そのサブネットからも返ってこなかった場合には、さらに別のサブネットにブロードキャスト送信というように複数回繰り返し、それでも応答がなかった場合には、初めてファームウェアの更新がないことを判断する。その後、一定期間待った後に、再度自身が所属するサブネット内に対してファームウェア装置の更新要求メッセージをブロードキャストする（Ｔ１０）。
【００５４】
上述したホームゲートウェイ装置におけるファームウェア管理方法によれば、ホームゲートウェイ装置が設置される地域に基づいてP2Pオーバレイネットワーク５を構成するグループ（サブネット）内で、ホームゲートウェイ装置１のIPアドレスを順次割り当てるようにしたので、グループ内に独自に識別子を設ける必要がない。そのため、運用側ではDHCP程度のIPアドレス管理機能があれば、サブネット内のホームゲートウェイ装置１に対してIPアドレスの割り当てを行うことが可能であるので、運用側の負担軽減を図ることができる。
【００５５】
また、P2Pオーバレイネットワーク５において、更新ファームウェア情報を取得するホームゲートウェイ装置１は任意の数が存在するので、基本的に非構造化オーバレイを構成することになり、あるホームゲートウェイ装置１に故障が発生したり、電源をOFFにしたりした場合であっても、複雑な処理を施す必要なく更新ファームウェア情報が配信可能となるので、ホームゲートウェイ装置自体を安価に構成することができる。
【００５６】
また、ファームウェア配信元のホームゲートウェイ装置のIPアドレスを配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索（動作例１）、若しくは、ブロードキャストにより問い合わせる（動作例２）ので、P2Pネットワークを構築する他のホームゲートウェイ装置のIPアドレスを知らなくとも接続先（配信元）を決定し、更新ファームウェア情報を配信可能とすることができる。
【００５７】
また、ファームウェア配信サーバ３が自らファームウェアを配信させるホームゲートウェイ装置１の数を指定できるので、ファームウェア配信サーバ側において、ネットワークの負荷及びサーバの負荷を軽減することができる。
その結果、サーバの低スペック化を実現し、更には回線容量の低減化を図ることで、全体的なネットワークコスト削減を実現することができる。
【符号の説明】
【００５８】
１…ホームゲートウェイ装置、 ２…インターネット、 ３…配信サーバ、 ４…ルータ、 ５…P2Pオーバレイネットワーク、 ６…DHCPサーバ、 １０…LAN側通信インターフェース、 １１…WAN側通信インターフェース、 １２…ファームウェア部、 １３…バージョン管理部、 １４…IPアドレス部 １５…宛先管理部、 １６…更新要求送信部、 １７…更新処理管理部、 １８…更新タイマー部、１９…データ中継部。
【特許請求の範囲】
【請求項１】
複数のホームゲートウェイ装置に対して配信サーバからファームウェア配信を行うホームゲートウェイ装置におけるファームウェア管理方法において、
前記ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てることでホームゲートウェイ装置同士のP2Pネットワークを構築し、
前記配信サーバから全てのサブネットにおいて、少なくとも１つ以上は最新のファームウェアを持つようにホームゲートウェイ装置にファームウェア配信が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信が行われる
ことを特徴とするホームゲートウェイ装置におけるファームウェア管理方法。
【請求項２】
前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIPアドレスを検索する際に、
ファームウェア配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索することで配信元のIPアドレスを決定する
請求項１に記載のホームゲートウェイ装置におけるファームウェア管理方法。
【請求項３】
前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIPアドレスを検索する際に、
ファームウェア配信先のホームゲートウェイ装置のIPアドレスからブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせることで配信元のIPアドレスを決定する
請求項１に記載のホームゲートウェイ装置におけるファームウェア管理方法。
【請求項１】
複数のホームゲートウェイ装置に対して配信サーバからファームウェア配信を行うホームゲートウェイ装置におけるファームウェア管理方法において、
前記ホームゲートウェイ装置が設置される地域を複数のサブネットに分割し、前記サブネット内において各ホームゲートウェイ装置に連続したIPアドレスを割り当てることでホームゲートウェイ装置同士のP2Pネットワークを構築し、
前記配信サーバから全てのサブネットにおいて、少なくとも１つ以上は最新のファームウェアを持つようにホームゲートウェイ装置にファームウェア配信が行われるとともに、他のホームゲートウェイ装置は、前記サブネット内で構築されたP2Pネットワークを介してファームウェア配信が行われる
ことを特徴とするホームゲートウェイ装置におけるファームウェア管理方法。
【請求項２】
前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIPアドレスを検索する際に、
ファームウェア配信先のホームゲートウェイ装置のIPアドレスからシーケンシャルに検索することで配信元のIPアドレスを決定する
請求項１に記載のホームゲートウェイ装置におけるファームウェア管理方法。
【請求項３】
前記サブネット内で構築されたP2Pネットワークを介したファームウェア配信は、ファームウェア配信元となるホームゲートウェイ装置のIPアドレスを検索する際に、
ファームウェア配信先のホームゲートウェイ装置のIPアドレスからブロードキャストでサブネット内の各ホームゲートウェイ装置に問い合わせることで配信元のIPアドレスを決定する
請求項１に記載のホームゲートウェイ装置におけるファームウェア管理方法。
【図１】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図３】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図３】
【公開番号】特開２０１１−１７５４２５（Ｐ２０１１−１７５４２５Ａ）
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願番号】特願２０１０−３８５９８（Ｐ２０１０−３８５９８）
【出願日】平成２２年２月２４日（２０１０．２．２４）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願日】平成２２年２月２４日（２０１０．２．２４）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]