特許 7458275 データ配信システム、集約ルータ、通信端末、および、データ配信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-21

(45)【発行日】2024-03-29

(54)【発明の名称】データ配信システム、集約ルータ、通信端末、および、データ配信方法

(51)【国際特許分類】

   H04W 28/04 20090101AFI20240322BHJP

   H04W 72/30 20230101ALI20240322BHJP

   H04W 84/18 20090101ALI20240322BHJP

   H04W 72/0446 20230101ALI20240322BHJP

【ＦＩ】

H04W28/04 110

H04W72/30

H04W84/18 110

H04W72/0446

【請求項の数】 15

(21)【出願番号】P 2020152605

(22)【出願日】2020-09-11

(65)【公開番号】P2022046950

(43)【公開日】2022-03-24

【審査請求日】2023-02-20

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】317015294

【氏名又は名称】東芝エネルギーシステムズ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】小林 崇裕

(72)【発明者】

【氏名】小堺 康之

【審査官】米倉 明日香

(56)【参考文献】

【文献】特開２０１５－０８７８０４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１２／０２２４５７７（ＵＳ，Ａ１）

【文献】特開２００９－１８８９３０（ＪＰ，Ａ）

【文献】特開２００３－００８６４２（ＪＰ，Ａ）

【文献】特開２００９－１７０９８５（ＪＰ，Ａ）

【文献】特開２０１９－１４５８６５（ＪＰ，Ａ）

【文献】特表２０１９－５１３３３２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムであって、
前記管理装置は、複数の前記集約ルータに前記データを配信し、
複数の前記集約ルータは、それぞれ、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知し、
複数の前記通信端末は、それぞれ、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信し、
複数の前記通信端末は、それぞれ、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前回の欠損ブロック要求のタイミングから前記要求送信間隔の経過時とする、データ配信システム。

【請求項2】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムであって、
前記管理装置は、複数の前記集約ルータに前記データを配信し、
複数の前記集約ルータは、それぞれ、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知し、
複数の前記通信端末は、それぞれ、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信し、
複数の前記通信端末は、それぞれ、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前記送信完了時刻から前記要求送信間隔の時間を経過するごとにその経過時を基準に前記要求送信間隔の範囲でランダムに決定する、データ配信システム。

【請求項3】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムであって、
前記管理装置は、複数の前記集約ルータに前記データを配信し、
複数の前記集約ルータは、それぞれ、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知し、
複数の前記通信端末は、それぞれ、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信し、
複数の前記集約ルータは、それぞれ、前記要求送信間隔を、配下の前記通信端末からの欠損ブロック要求の受信頻度に基づいて変更する、データ配信システム。

【請求項4】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムであって、
前記管理装置は、複数の前記集約ルータに前記データを配信し、
複数の前記集約ルータは、それぞれ、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知し、
複数の前記通信端末は、それぞれ、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信し、
前記データ配信システムに新規の通信端末が参入した場合、
前記新規の通信端末は、通信対象の前記集約ルータに自端末が受信すべきデータの有無を問い合わせ、当該データがある場合、
当該データの前記送信完了時刻の前は、前記集約ルータから当該データに対応する前記ブロックを受信し、
当該データの前記送信完了時刻の後は、前記集約ルータから受信した前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する、データ配信システム。

【請求項5】

前記新規の通信端末は、すべての前記ブロックを取得した後に再起動が必要な場合、周囲の通信可能な前記通信端末に対して、前記再起動の完了までは自端末を途中経路の通信端末として選択しないことを要求する情報を通知する、請求項４に記載のデータ配信システム。

【請求項6】

複数の前記集約ルータは、それぞれ、前記要求送信間隔として、予め定められた値を用いるか、あるいは、配下に収容可能な前記通信端末の最大数、および、配下に収容中の前記通信端末の数、のいずれかに基づいて算出した値を用いる、請求項１から請求項４のいずれか一項に記載のデータ配信システム。

【請求項7】

複数の前記集約ルータは、それぞれ、複数の前記ブロックを配下の前記通信端末へ複数回配信する、請求項１から請求項４のいずれか一項に記載のデータ配信システム。

【請求項8】

前記通信端末は、通信対象の前記集約ルータが変更になった場合、変更後の最初の欠損ブロック要求のタイミングを、当該データの送信完了時刻の直後に前記タイミングを決定するときに用いた前記要求送信間隔に基づいて決定する、請求項１から請求項４のいずれか一項に記載のデータ配信システム。

【請求項9】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおける前記集約ルータであって、
前記管理装置から受信した前記データを複数のブロックに分割する分割部と、
複数の前記ブロックを配下の前記通信端末へ前記無線マルチホップ通信で配信する配信部と、
前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する通知部と、
複数の前記通信端末のそれぞれから、当該データの送信完了時刻後に、前記要求送信間隔に基づいて決定したタイミングで送信された欠損ブロック要求を受信した場合に、対応する欠損ブロックを要求元の前記通信端末に配信する欠損ブロック配信部と、
前記要求送信間隔として、予め定められた値を用いるか、あるいは、配下に収容可能な前記通信端末の最大数、および、配下に収容中の前記通信端末の数、のいずれかに基づいて算出した値を用いる要求送信間隔決定部と、を備え、
前記要求送信間隔決定部は、前記要求送信間隔を、配下の前記通信端末からの欠損ブロック要求の受信頻度に基づいて変更する、集約ルータ。

【請求項10】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信し、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおける前記通信端末であって、
無線マルチホップ通信で受信した前記ブロックを取り込んで保存する配信処理部と、
当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する欠損ブロック要求送信部と、を備え、
前記欠損ブロック要求送信部は、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前回の送信要求のタイミングから前記要求送信間隔の時間の経過時とする、通信端末。

【請求項11】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信し、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおける前記通信端末であって、
無線マルチホップ通信で受信した前記ブロックを取り込んで保存する配信処理部と、
当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する欠損ブロック要求送信部と、を備え、
前記欠損ブロック要求送信部は、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前記送信完了時刻から前記要求送信間隔の時間を経過するごとにその経過時を基準に前記要求送信間隔の範囲でランダムに決定する、通信端末。

【請求項12】

前記配信処理部は、前記管理装置にデータ配信の要否の問い合わせを行い、前記管理装置からデータ配信が必要との通知を受けた場合、当該データ配信に対応する前記ブロックを受信したときに取り込んで保存する、請求項１０または請求項１１に記載の通信端末。

【請求項13】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおけるデータ配信方法であって、
前記管理装置によって、複数の前記集約ルータに前記データを配信する第１のステップと、
複数の前記集約ルータのそれぞれによって、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する第２のステップと、
複数の前記通信端末のそれぞれによって、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、欠損ブロックがある場合、当該データの送信完了時刻後に、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する第３のステップと、を含み、
前記第３のステップにおいて、複数の前記通信端末は、それぞれ、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前回の欠損ブロック要求のタイミングから前記要求送信間隔の経過時とする、データ配信方法。

【請求項14】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおけるデータ配信方法であって、
前記管理装置によって、複数の前記集約ルータに前記データを配信する第１のステップと、
複数の前記集約ルータのそれぞれによって、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する第２のステップと、
複数の前記通信端末のそれぞれによって、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、欠損ブロックがある場合、当該データの送信完了時刻後に、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する第３のステップと、を含み、
前記第３のステップにおいて、複数の前記通信端末は、それぞれ、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、当該データの送信完了時刻を基準に前記要求送信間隔の範囲でランダムに決定し、２回目以降の欠損ブロック要求のタイミングを、前記送信完了時刻から前記要求送信間隔の時間を経過するごとにその経過時を基準に前記要求送信間隔の範囲でランダムに決定する、データ配信方法。

【請求項15】

通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備えるデータ配信システムにおけるデータ配信方法であって、
前記管理装置によって、複数の前記集約ルータに前記データを配信する第１のステップと、
複数の前記集約ルータのそれぞれによって、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する第２のステップと、
複数の前記通信端末のそれぞれによって、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、欠損ブロックがある場合、当該データの送信完了時刻後に、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する第３のステップと、を含み、
前記第２のステップにおいて、複数の前記集約ルータは、それぞれ、前記要求送信間隔を、配下の前記通信端末からの欠損ブロック要求の受信頻度に基づいて変更する、データ配信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、データ配信システム、集約ルータ、通信端末、および、データ配信方法に関する。

【背景技術】

【0002】

従来から、例えば、管理装置と、複数の集約ルータと、複数の通信端末と、を備えるデータ配信システムがある。管理装置は、通信端末への配信対象のデータを管理する。集約ルータは、管理装置および配下の通信端末と通信する。通信端末は、複数の集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う。

【0003】

管理装置から複数の通信端末にデータ配信を行う際は、まず、ブロードキャストまたはマルチキャストによって通信端末にデータ配信を行う。その場合、集約ルータは、例えば、管理装置から受信したデータを複数のブロックに分割して、ブロック単位で通信端末に配信する。そして、通信端末ごとに、欠損ブロックがある場合は、個別にユニキャスト通信で集約ルータに欠損ブロックを要求し、集約ルータから欠損ブロックを受信する。

【先行技術文献】

【特許文献】

【0004】

【文献】特許第４３１５０６３号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上述の従来技術では、欠損ブロックのある通信端末が多数存在する場合、通信端末と集約ルータとの間のユニキャスト通信が短時間に多数発生することで、トラフィックが増加して輻輳状態となる可能性があり、改善の余地がある。

【0006】

そこで、本発明の課題は、トラフィック増加を抑制しながら通信端末に効率的にデータ配信することができるデータ配信システム、集約ルータ、通信端末、および、データ配信方法を提供することである。

【課題を解決するための手段】

【0007】

実施形態のデータ配信システムは、通信端末への配信対象のデータを管理する管理装置と、前記管理装置と通信する複数の集約ルータと、複数の前記集約ルータのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の前記通信端末と、を備える。前記管理装置は、複数の前記集約ルータに前記データを配信する。複数の前記集約ルータは、それぞれ、前記管理装置から受信した前記データを複数のブロックに分割し、複数の前記ブロックを配下の前記通信端末へ配信するとともに、前記通信端末において足りない前記ブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を前記通信端末に通知する。複数の前記通信端末は、それぞれ、無線マルチホップ通信で受信した前記ブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、前記要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を前記集約ルータに送信する。

【図面の簡単な説明】

【0008】

【図1】図１は、第１実施形態のデータ配信システムの全体構成を模式的に示す図である。

【図2】図２は、第１実施形態の管理装置の機能構成を示すブロック図である。

【図3】図３は、第１実施形態の集約ルータの機能構成を示すブロック図である。

【図4】図４は、第１実施形態の通信端末の機能構成を示すブロック図である。

【図5】図５は、第１実施形態のデータ配信システムにおける処理の流れを示すシーケンス図である。

【図6】図６は、第１実施形態の通信端末における欠損ブロック要求の送信タイミングの第１の決定方法の説明図である。

【図7】図７は、第１実施形態の通信端末における欠損ブロック要求の送信タイミングの第２の決定方法の説明図である。

【図8】図８は、第１実施形態の通信端末における処理を示すフローチャートである。

【図9】図９は、第１実施形態の集約ルータにおける要求送信間隔の変更方法の説明図である。

【発明を実施するための形態】

【0009】

以下に添付図面を参照して、本発明の実施形態のデータ配信システム、集約ルータ、通信端末、管理装置、および、データ配信方法について詳細に説明する。

【0010】

実施形態の理解を容易にするために、従来技術についてあらためて説明する。各種デジタル機器はソフトウェアにより各種機能を実現している。特に通信機能を持つ携帯電話やデジタルテレビなどの通信端末に関しては、通信機能を用いて遠隔で通信端末のソフトウェア（データ）を更新することが可能となっている。ソフトウェアを更新する場合、ソフトウェアを保存する管理装置からソフトウェアを必要とする通信端末に対してソフトウェアを配信する。ソフトウェアは、例えば、複数のブロックに分割され、通信ネットワークで配信される。

【0011】

例えば、携帯電話のような通信システムでは、通信端末それぞれが管理装置に対してソフトウェアの配信要求を送り、それに応じて管理装置がソフトウェアを配信する方法を利用する。配信要求は通信端末側の都合（例えば利用者の指示）に応じて実行される。また、通信端末と管理装置にはユニキャストの通信経路が形成され、通信時の伝送誤り等でブロックの欠損が発生した場合、誤りが発生したことを通信端末から管理装置に通知し、欠損ブロックの再送を要求する。

【0012】

また、例えば、デジタルテレビのような放送型の通信ネットワークを使う通信端末では、管理装置が通信ネットワークを通じてソフトウェアをブロードキャストで送信し、通信端末それぞれがソフトウェアを受信する方法を利用する。管理装置はソフトウェアを繰り返し配信することで、通信時の伝送誤り等でブロックの欠損が発生することがあっても、複数回の配信によってソフトウェア全体を配信できる。

【0013】

また、例えば、スマートメーターシステムやセンサーネットワークなどのＩｏＴ（Internet of Things）ネットワークでは、マルチホップ方式と呼ばれる通信方式を適用する場合がある。マルチホップネットワークは、相互に通信可能な通信端末と集約ルータを備え、集約ルータと直接通信できない通信端末は、他の通信端末を経由するバケツリレー方式でデータの転送を行う。

【0014】

集約ルータは、管理装置と広域網（例えば携帯電話網）を介して通信が可能となっている。代表的なマルチホップネットワーク規格の１つとしてＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１５．４規格がある。この規格では、９００ＭＨｚ帯（日本では９２０ＭＨｚ帯）の周波数帯を適用し数百ｋｂｐｓの通信帯域となっている。

【0015】

ＩｏＴネットワークでは、１つのネットワークに多数の通信端末（例えばスマートメーター）が存在する。数百ｋｂｐｓの通信帯域を多数の通信端末で共用するため、共用する台数を勘案して通信端末１台当たりの単位時間当たりの送信データ量が調整されている。また、ソフトウェアのデータサイズは、ＩｏＴ通信端末が通常送信するデータサイズより大きいため、効率的な配信方法が求められる。

【0016】

マルチホップネットワークでも、ソフトウェアの配信方法として、通信端末と管理装置の間でユニキャスト通信、および、ブロードキャスト／マルチキャスト通信のいずれも適用可能である。ユニキャスト通信でソフトウェアを配信すると、通信対象の通信端末との通信の中継を行っている通信端末は、同じソフトウェアのブロックを転送するときにそのブロックを自身には取り込めず効率が悪く、少数の通信端末へのソフトウェア配信に適している。

【0017】

また、ブロードキャスト／マルチキャスト通信でソフトウェアを配信すると、中継を行っている通信端末はソフトウェアのブロックを転送するとともにそのブロックを自身に取り込むことも可能であり、多数の通信端末への配信に適している。ただし、伝送誤り等でソフトウェアの一部が欠損することが考えられるが、欠損する部分（ブロック）は通信端末ごとに異なるため、ソフトウェア配信を複数回繰り返すことや、各通信端末が欠損ブロックを管理装置に通知し、欠損したブロックを再送する手段が適用される。また、例えば、上述の特許文献１では、まずブロードキャストによるソフトウェア配信を行い、部分的に欠損したソフトウェアの一部のみユニキャストにより配信する方法が開示されている。

【0018】

同一のデータを多数の通信端末へ配信する際の通信効率の良いブロードキャスト／マルチキャストによるソフトウェアの配信において、ソフトウェア配信を複数回繰り返す手法を採用すると、すべての通信端末にソフトウェア全体が届くまで繰り返し配信を行うため、配信完了まで時間がかかる。

【0019】

また、通信端末から欠損ブロックの通知を行う手法を採用すると、管理装置ですべての通信端末からの通知を受け取り、欠損のある共通のブロックを選択して再送するなど、管理装置の通信負荷および処理負荷が増える問題がある。

【0020】

また、特許文献１の技術では、ブロードキャストによるソフトウェアの配信の終了をタイマーで検出し、配信終了後に欠損ブロックのある通信端末がユニキャスト通信を開始する。しかし、欠損ブロックのある通信端末が多数存在する場合、ユニキャスト通信が短時間に多数発生することで、トラフィックが増加して輻輳状態となる可能性がある。そして、輻輳状態となると、欠損ブロックの要求／欠損ブロックの配信の成功率が下がるのと同時に、通常発生するトラフィック（例えばセンサデータの定期的な伝送）の伝送誤りが増えるなどの影響を与えることになる。そこで、以下では、トラフィック増加を抑制しながら通信端末に効率的にデータ配信することができる技術について説明する。

【0021】

（第１実施形態）
図１は、第１実施形態のデータ配信システムＳの全体構成を模式的に示す図である。データ配信システムＳは、通信端末Ｃへの配信対象のデータを管理する管理装置Ａと、管理装置Ａと通信する複数の集約ルータＢと、複数の集約ルータＢのいずれかの配下でブロードキャストまたはマルチキャストによる無線マルチホップ通信を行う複数の通信端末Ｃと、を備える。以下では、ブロードキャストとマルチキャストのうち、主にブロードキャストを例にとって説明するが、マルチキャストも同様に適用できる。

【0022】

図１では、集約ルータＢとして、集約ルータ１～３を示している。以下、集約ルータ１～３を区別しない場合は「集約ルータＢ」と称し、集約ルータ１～３を区別する場合は「集約ルータ１」等と称する。

【0023】

また、集約ルータ１の配下の通信端末Ｃとして、通信端末１～５を示している。以下、通信端末１～５を区別しない場合は「通信端末Ｃ」と称し、通信端末１～５を区別する場合は「通信端末１」等と称する。

【0024】

管理装置Ａと集約ルータＢとの接続には、例えば、携帯電話網や光回線網などの広域通信網（ＷＡＮ（Wide Area Network））が適用される。集約ルータＢと配下の複数の通信端末Ｃは、無線マルチホップ通信で相互に通信する。無線マルチホップ通信としては、例えば、公知の通信方法を用いればよい。

【0025】

なお、個別の通信端末Ｃは、親ノードである集約ルータＢを変更することも可能である。図１では、通信端末２の親ノードは集約ルータ１であるが、例えば、両者の間に通信状態を悪化させる遮蔽物が入った場合などに、通信端末２は、親ノードを集約ルータ１から集約ルータ２や集約ルータ３に変更することができる。また、以下において、記載を簡潔にするために、「親ノードの集約ルータＢ」を単に「集約ルータＢ」と称したり、「配下の通信端末Ｃ」を単に「通信端末Ｃ」と称したりする場合がある。

【0026】

通信端末Ｃは、所定のアルゴリズムに従ってマルチホップの通信経路を形成する。図１はある時点での通信経路のトポロジーを示したものであり、例えば、通信端末３の無線信号が集約ルータ１まで届かないことなどは意味していない。

【0027】

管理装置Ａは、複数の集約ルータＢにデータ（ソフトウェア）を配信する。それぞれの集約ルータＢは、管理装置Ａから受信したデータを複数のブロックに分割し、複数のブロックを配下の通信端末Ｃへ配信する。また、それぞれの集約ルータＢは、通信端末Ｃにおいて足りないブロックである欠損ブロックの送信を要求する欠損ブロック要求を送信するタイミングを決定するために用いられる所定の時間幅である要求送信間隔を通信端末Ｃに通知する。

【0028】

また、それぞれの通信端末Ｃは、無線マルチホップ通信で受信したブロックを取り込んで保存し、当該データの送信完了時刻後に、欠損ブロックがある場合、要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を集約ルータに送信する。

【0029】

なお、それぞれの集約ルータＢは、複数のブロックを配下の通信端末Ｃへ複数回配信してもよい。そうすれば、１回の送信の場合に比べて、通信端末Ｃで発生する欠損ブロックの数を減らすことができる。

【0030】

図２は、第１実施形態の管理装置Ａの機能構成を示すブロック図である。管理装置Ａは、コンピュータ装置であり、記憶部１１と、処理部１２と、ＷＡＮ通信部１３と、を備える。記憶部１１は、各種情報（各種プログラム、各種データ）を記憶し、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）等によって実現される。記憶部１１は、配信データ記憶部１１１と、配信要否条件記憶部１１２と、を備える。

【0031】

配信データ記憶部１１１は、通信端末Ｃへの配信対象のデータを記憶する。配信要否条件記憶部１１２は、配信データ記憶部１１１に記憶されているデータごとに、それぞれの通信端末Ｃごとの配信の要否の条件を記憶する。

【0032】

処理部１２は、各種演算処理を実行し、例えば、ＣＰＵ（Central Processing Unit）によって実現される。処理部１２は、機能部として、配信処理部１２１と、配信要否通知部１２２と、を備える。

【0033】

配信処理部１２１は、集約ルータＢに対して、データの配信開始を通知したり、配信データ記憶部１１１に記憶されているデータを配信したりする。

【0034】

配信要否通知部１２２は、任意の通信端末Ｃからデータ配信の要否の問い合わせがあったとき、配信要否条件記憶部１１２を参照して、送信元の通信端末Ｃに対してデータ配信の要否について通知する。なお、配信要否条件記憶部１１２と配信要否通知部１２２については第５実施形態で詳細に説明する。

【0035】

ＷＡＮ通信部１３は、集約ルータＢとの間でＷＡＮ通信を行う。

【0036】

図３は、第１実施形態の集約ルータＢの機能構成を示すブロック図である。集約ルータＢは、コンピュータ装置であり、記憶部２１と、処理部２２と、ＷＡＮ通信部２３と、無線通信部２４と、を備える。

【0037】

記憶部２１は、各種情報（各種プログラム、各種データ）を記憶し、例えば、ＲＡＭ、ＲＯＭ、ＨＤＤ等によって実現される。記憶部２１は、配信データ記憶部２１１を備える。配信データ記憶部２１１は、管理装置Ａから受信したデータを記憶する。

【0038】

処理部２２は、各種演算処理を実行し、例えば、ＣＰＵによって実現される。処理部２２は、機能部として、配信データ分割処理部２２１（分割部）と、ブロードキャスト配信処理部２２２（配信部：通知部）と、欠損ブロック配信処理部２２３（欠損ブロック配信部）と、要求送信間隔決定部２２４と、配信データ処理制御部２２５と、を備える。

【0039】

配信データ分割処理部２２１は、配信データ記憶部２１１に記憶されているデータを複数のブロックに分割する。

【0040】

ブロードキャスト配信処理部２２２は、複数のブロックを配下の通信端末Ｃへブロードキャストによる無線マルチホップ通信で配信する。また、ブロードキャスト配信処理部２２２は、要求送信間隔決定部２２４によって決定された要求送信間隔を配下の通信端末Ｃへブロードキャストで配信する。

【0041】

欠損ブロック配信処理部２２３は、任意の配下の通信端末Ｃから欠損ブロック要求があった場合に、送信元の通信端末Ｃに対して該当する欠損ブロックをユニキャストで送信する。

【0042】

要求送信間隔決定部２２４は、要求送信間隔を決定する。要求送信間隔決定部２２４は、例えば、要求送信間隔として、予め定められた値を用いるか、あるいは、配下に収容可能な通信端末Ｃの最大数、および、配下に収容中の通信端末Ｃの数、のいずれかに基づいて算出した値を用いる。また、要求送信間隔決定部２２４は、要求送信間隔を、配下の通信端末Ｃからの欠損ブロック要求の受信頻度に基づいて変更してもよい。

【0043】

具体的には、要求送信間隔決定部２２４は、例えば、欠損ブロックを要求する通信端末Ｃの台数（Ｍ台）と、欠損ブロック要求の送信時間とそれに対する欠損ブロックの送信時間（合計Ｔ秒）から要求送信間隔を決定する。これにより、欠損ブロックの送信を含めて無線リソースの過度な集中利用を避けることができる。例えば、欠損ブロック配信のための無線リソース利用を全体のＲ％とする場合、Ｍ台×Ｔ秒／Ｒ％を要求送信間隔とすればよい。なお、各通信端末Ｃから親ノードの集約ルータＢまでの通信時のホップ数は複数種類あるが、そういった通信事情をすべて踏まえてＲを決定すればよい。

【0044】

無線を利用した通信ネットワークであるため、集約ルータＢから各通信端末Ｃへのブロックの到達は１００％では保証できない。そのため、ブロードキャストによるデータ配信終了時においては、集約ルータＢ配下の通信端末Ｃの多数で１つ以上の欠損ブロックがあると考えることが妥当である。そのため、上述のＭ台として、配信開始時あるいは配信終了時の集約ルータＢ配下の通信端末Ｃの台数とすることが考えられる。あるいは、上述のＭ台として、集約ルータＢで収容可能な通信端末Ｃの最大数を採用することも考えられる。台数が多い場合、要求送信間隔もそれに比例して大きくする。

【0045】

また、すべての配下の通信端末Ｃの欠損ブロックの総数は、欠損ブロック送信の実施により減少していく。したがって、配信終了時に決めた要求送信間隔をずっと継続使用するのは好ましくない。集約ルータＢにおいて、例えば、欠損ブロック要求の到着頻度、あるいは、欠損ブロック要求を送る通信端末Ｃの数の減少に合わせて、要求送信間隔を減少させるのがよい。そうすれば、欠損ブロックの配信時間を短縮することができる。

【0046】

ここで、図９の（ａ）、（ｂ）は、第１実施形態の集約ルータＢにおける要求送信間隔の変更方法の説明図である。集約ルータＢは、ブロードキャストによるデータ配信終了時（ｔ０）に、要求送信間隔を初期値（Ｄ１＝Ｗ１）とする。この要求送信間隔の初期値をブロードキャストによるデータ配信の中で通信端末Ｃに通知する。ただし、集約ルータＢで決めた要求送信間隔の初期値と、通信端末Ｃの持つ要求送信間隔の初期値は必ずしも同じでなくてもよい。例えば、集約ルータＢの要求送信間隔の初期値は、その時点の通信端末Ｃの接続台数から算出し、通信端末Ｃの要求送信間隔の初期値は、集約ルータＢにおける通信端末Ｃの最大収容数から算出する、など通信端末Ｃの要求送信間隔の初期値が集約ルータＢの要求送信間隔の初期値より大きければよい。

【0047】

また、Ｆは、すべての通信端末Ｃからの欠損ブロック要求の総受信頻度である。集約ルータＢは、欠損ブロック要求の総受信頻度を算出し、所定のアルゴリズムにより、総受信頻度の低下に応じて要求送信間隔を短くする。そして、集約ルータＢは、算出した要求送信間隔を、要求された欠損ブロックの送信のときに最新の要求送信間隔として通信端末Ｃに通知する。

【0048】

例えば、集約ルータＢは、時刻ｔ１までは、要求送信間隔Ｗ１を通信端末Ｃに通知する（Ｅ１など）。その後、時刻ｔ２に、欠損ブロック要求の総受信頻度の低下に応じて要求送信間隔をＤ１からＤ２（＝Ｗ２）に変更すると、それ以降（時刻ｔ３など）は、要求送信間隔Ｗ２を通信端末Ｃに通知する（Ｅ２など）。

【0049】

その後、集約ルータＢは、時刻ｔ４に、欠損ブロック要求の総受信頻度の低下に応じて要求送信間隔をＤ２からＤ３（＝Ｗ３）に変更すると、それ以降（時刻ｔ５など）は、要求送信間隔Ｗ３を通信端末Ｃに通知する（Ｅ３など）。

【0050】

図３に戻って、配信データ処理制御部２２５は、例えば、管理装置Ａからの配信開始指示を受け取ったり、通信端末Ｃに配信開始指示を送ったり、ブロードキャスト配信処理部２２２、欠損ブロック配信処理部２２３、要求送信間隔決定部２２４の処理の切り替え制御を実行したりする。

【0051】

ＷＡＮ通信部２３は、管理装置Ａとの間でＷＡＮ通信を行う。無線通信部２４は、配下の通信端末Ｃとの間で無線通信（無線マルチホップ通信）を行う。

【0052】

図４は、第１実施形態の通信端末Ｃの機能構成を示すブロック図である。通信端末Ｃは、例えば、スマートメータであり、記憶部３１と、処理部３２と、無線通信部３３と、を備える。

【0053】

記憶部３１は、各種情報（各種プログラム、各種データ）を記憶し、例えば、ＲＡＭ、ＲＯＭ等によって実現される。記憶部３１は、配信データ記憶部３１１を備える。配信データ記憶部３１１は、親ノードの集約ルータＢから受信したブロックを記憶する。

【0054】

処理部３２は、各種演算処理を実行し、例えば、ＣＰＵによって実現される。処理部３２は、機能部として、欠損ブロック管理部３２１と、ブロードキャスト配信処理部３２２（配信処理部）と、ユニキャスト配信処理部３２３と、要求送信間隔抽出部３２４と、欠損ブロック要求送信部３２５と、を備える。

【0055】

欠損ブロック管理部３２１は、配信データ記憶部３１１を参照して欠損ブロックの有無を管理し、欠損ブロックがある場合はその欠損ブロックの識別情報を認識する。

【0056】

ブロードキャスト配信処理部３２２は、無線マルチホップ通信で受信したブロックを取り込んで配信データ記憶部３１１に保存する。

【0057】

要求送信間隔抽出部３２４は、無線マルチホップ通信で受信したデータから要求送信間隔を抽出する。

【0058】

欠損ブロック要求送信部３２５は、データの送信完了時刻後に、欠損ブロック管理部３２１を参照し、欠損ブロックがある場合、要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を集約ルータＢに送信する。

【0059】

ユニキャスト配信処理部３２３は、集約ルータＢからユニキャストで欠損ブロックを受信し、配信データ記憶部３１１に保存する。

【0060】

ここで、図６は、第１実施形態の通信端末Ｃにおける欠損ブロック要求の送信タイミングの第１の決定方法の説明図である。この第１の決定方法では、前回送信タイミングを基準として欠損ブロック要求の送信タイミングを決定する。

【0061】

具体的には、通信端末Ｃの欠損ブロック要求送信部３２５は、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、データの送信完了時刻（Ｔ１１）を基準に要求送信間隔（Ｔ１１～Ｔ１２）の範囲でランダムに（例えば一様分布乱数を用いて）決定し（（１１））、決定した送信タイミング（（１２））で欠損ブロック要求を集約ルータＢに送信する。

【0062】

また、欠損ブロック要求送信部３２５は、２回目の欠損ブロック要求のタイミングを、前回の送信要求のタイミング（（１２））から要求送信間隔（（１３）：Ｔ１）の時間の経過時（（１４））とする。３回目以降の欠損ブロック要求のタイミングも同様にして決定する。

【0063】

このような手順で欠損ブロック要求の送信タイミングを決定することにより、多数の通信端末Ｃからの欠損ブロック要求が短時間に集中する可能性が有意に低減する。

【0064】

図７は、第１実施形態の通信端末Ｃにおける欠損ブロック要求の送信タイミングの第２の決定方法の説明図である。この第２の決定方法では、データの送信完了時刻と要求送信間隔を基準に欠損ブロック要求の送信タイミングを決定する。

【0065】

具体的には、通信端末Ｃの欠損ブロック要求送信部３２５は、欠損ブロックがある場合、１回目の欠損ブロック要求のタイミングを、データの送信完了時刻（Ｔ１１：（２１））を基準に要求送信間隔（Ｔ１１～Ｔ１２）の範囲でランダムに決定し（（２２））、決定した送信タイミング（（２３））で欠損ブロック要求を送信する。

【0066】

また、欠損ブロック要求送信部３２５は、２回目の欠損ブロック要求のタイミングを、送信完了時刻から要求送信間隔の経過（（２２）＋（２４））時（Ｔ１２：（２５））を基準に要求送信間隔（Ｔ１２～Ｔ１３）の範囲でランダムに決定する。３回目以降の欠損ブロック要求のタイミングも同様にして決定する。

【0067】

このような手順で欠損ブロック要求の送信タイミングを決定することにより、多数の通信端末Ｃからの欠損ブロック要求が短時間に集中する可能性が有意に低減する。なお、（２２）と（２６）の時間幅は同じにしてもよい。

【0068】

図４に戻って、無線通信部３３は、親ノードの集約ルータＢとの間で無線通信（無線マルチホップ通信）を行う。

【0069】

図５は、第１実施形態のデータ配信システムＳにおける処理の流れを示すシーケンス図である。まず、ステップＳ１において、管理装置Ａの配信処理部１２１は、管理者の操作等により、集約ルータＢに対して、データを配信するとともに、通信端末Ｃへの配信の開始の指示を通知する。

【0070】

次に、ステップＳ２～Ｓ３において、以下の処理を行う。まず、集約ルータＢは、通信端末Ｃに対して、ブロードキャストによる無線マルチホップ通信によって、データ（ＳＷ：Software）配信開始を通知する。例えば、ステップＳ２１では、集約ルータ１は、通信端末１、２にデータ配信開始を通知する。また、ステップＳ２２では、通信端末１は、通信端末３、４にデータ配信開始を通知する。また、ステップＳ２３では、通信端末２は、通信端末５にデータ配信開始を通知する。ステップＳ２４～Ｓ２６においても同様に無線マルチホップ通信によるデータ配信開始の通知が行われる。

【0071】

その後、集約ルータＢは、データをＮ個のブロックに分割し、ブロックごとにブロードキャストによる無線マルチホップ通信によって通信端末Ｃに配信する。以下、ブロックをＳＷブロックとも称する。例えば、データ配信開始通知のときと同様の経路にて、ＳＷブロック＃１、ＳＷブロック＃２、・・・、ＳＷブロック＃Ｎがそれぞれの通信端末Ｃに配信される。

【0072】

なお、ブロードキャストの転送において、経路上の上流（集約ルータＢ側）の送信したブロックのみを転送する、同じブロックの再転送は行わない、転送までの時間を調整する、などの輻輳を抑制する手法が適用される。

【0073】

また、データ配信開始の通知の受信に失敗した通信端末Ｃは、ブロックを受信することでもデータ配信を認識できるため、データ配信開始の通知を省略してもよい。

【0074】

また、ブロードキャストによるデータ配信の間、通信端末Ｃは受信したブロックを転送するとともに、自身が取り込むべきソフトウェア（ブロック）であった場合にのみ、自身宛のソフトウェアとしてブロックを保存する。これは、例えば、１つの集約ルータＢの配下の複数の通信端末Ｃが複数の機種で構成されている状況を考慮したもので、ブロックに付加するヘッダ情報に機種等の情報を入れることで容易に実現できる。

【0075】

次に、Ｎ個のブロックの配信の終了後（ステップＳ３の後）、各通信端末Ｃは、欠損ブロックの要求を開始する。なお、配信の終了時刻の情報は、例えば、データ配信開始の通知もしくはブロックのヘッダ情報に含めて送信される。あるいは、ブロック数とブロックの送信間隔の情報を通知し、各通信端末Ｃで終了時刻を算出する方法でも良い。また、通信端末Ｃにおいて、ブロックの欠損は、例えば各ブロックにブロック番号を付加しておくなどの方法で容易に検出が可能である。

【0076】

通信端末Ｃは、親ノードの集約ルータＢから通知される欠損ブロック要求の要求送信間隔に１回の欠損ブロック要求をユニキャストで集約ルータＢに送信する。要求を受けた集約ルータＢは、要求された欠損ブロックをユニキャストで要求元の通信端末Ｃに送信する。

【0077】

例えば、ステップＳ３１において、通信端末４がユニキャストで通信端末１を経由して集約ルータ１に欠損ブロック１の要求を送信する。そして、ステップＳ３２において、集約ルータ１はユニキャストで通信端末１を経由して通信端末４に欠損ブロック１を送信する。

【0078】

また、ステップＳ３３において、通信端末５がユニキャストで通信端末２を経由して集約ルータ１に欠損ブロック１の要求を送信する。そして、ステップＳ３４において、集約ルータ１はユニキャストで通信端末２を経由して通信端末５に欠損ブロック１を送信する。このように、１回目の要求送信間隔Ｔ１の中で、１つの通信端末Ｃについての欠損ブロックに関する送受信は、１回だけ行われる。

【0079】

また、ステップＳ３５において、通信端末４がユニキャストで通信端末１を経由して集約ルータ１に欠損ブロック２の要求を送信する。そして、ステップＳ３６において、集約ルータ１はユニキャストで通信端末１を経由して通信端末４に欠損ブロック２を送信する。

【0080】

また、ステップＳ３７において、通信端末５がユニキャストで通信端末２を経由して集約ルータ１に欠損ブロック２の要求を送信する。そして、ステップＳ３８において、集約ルータ１はユニキャストで通信端末２を経由して通信端末５に欠損ブロック２を送信する。このように、２回目の要求送信間隔Ｔ１の中で、１つの通信端末Ｃについての欠損ブロックに関する送受信は、１回だけ行われる。

【0081】

ブロードキャストによるデータ配信の終了後は、多数の通信端末Ｃからの欠損ブロック要求が発生する可能性がある。このように、要求送信間隔ごとに各通信端末Ｃで１回だけ欠損ブロック要求を送信するようにすることで、輻輳の可能性を有意に低減できる。

【0082】

図８は、第１実施形態の通信端末Ｃにおける処理を示すフローチャートである。ステップＳ１０１において、ブロードキャスト配信処理部３２２は、集約ルータＢからブロードキャストでＳＷ配信開始通知を受信する。

【0083】

次に、ステップＳ１０２において、ブロードキャスト配信処理部３２２は、ＳＷブロックを受信し、配信データ記憶部３１１に記憶させるとともに、他の通信端末Ｃに転送する。

【0084】

次に、ステップＳ１０３において、ブロードキャスト配信処理部３２２は、ブロードキャストでのブロックの配信が終了か否かを判定し、Ｙｅｓの場合はステップＳ１０４に進み、Ｎｏの場合はステップＳ１０２に戻る。

【0085】

ステップＳ１０４において、欠損ブロック要求送信部３２５は、欠損ブロック管理部３２１を参照して欠損ブロックを決定する。

【0086】

次に、ステップＳ１０５において、欠損ブロック要求送信部３２５は、欠損ブロックがあるか否かを判定し、Ｙｅｓの場合はステップＳ１０６に進み、Ｎｏの場合は処理を終了する。

【0087】

ステップＳ１０６において、欠損ブロック要求送信部３２５は、欠損ブロック要求の送信タイミングを決定する（図６、図７参照）。

【0088】

次に、ステップＳ１０７において、欠損ブロック要求送信部３２５は、欠損ブロック要求をユニキャストで親ノードの集約ルータＢに送信する。

【0089】

次に、ユニキャスト配信処理部３２３は、集約ルータＢからユニキャストでＳＷブロック（欠損ブロック）を受信し、配信データ記憶部３１１に記憶する。

【0090】

次に、欠損ブロック要求送信部３２５は、規定時間の経過を待つ。つまり、次の欠損ブロック要求の送信タイミングまで待つ。ステップＳ１０９の後、ステップＳ１０４に戻る。

【0091】

このように、第１実施形態のデータ配信システムＳによれば、通信端末Ｃは、それぞれ、無線マルチホップ通信で受信したブロックを取り込んで保存し、データの送信完了時刻後に、欠損ブロックがある場合、要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を集約ルータＢに送信することで、トラフィック増加を抑制しながら通信端末に効率的にデータ配信することができる。

【0092】

つまり、集約ルータＢが要求送信間隔を通信端末Ｃに通知し、通信端末Ｃが要求送信間隔の範囲で分散して欠損ブロック要求の送信を１回だけ行うことで、欠損ブロック要求の集中による欠損ブロック要求の衝突多発による再送回数の増加や、他のトラフィックへの影響を回避することができる。

【0093】

また、集約ルータＢから通知する要求送信間隔を調整することで（図９参照）、欠損ブロックの総数あるいは欠損ブロックを持つ通信端末Ｃの数に応じた適切な要求送信間隔を用いることができる。

【0094】

（第２実施形態）
次に、第２実施形態について説明する。これまでに説明した事項と同様の事項については、説明を適宜省略する（第３実施形態以降も同様）。

【0095】

通信端末Ｃは、データ配信プロセスと無関係に、無線マルチホップ通信の経路制御を実施する。無線マルチホップ通信の経路を、同じ集約ルータＢ（例えば集約ルータ１）に属する通信端末Ｃから、別の集約ルータＢ（例えば集約ルータ２）に属する通信端末Ｃに切り替えることもある。欠損ブロック要求と欠損ブロックの受信を行っている状態で、他の集約ルータＢに属するよう経路変更した場合、移動先の無線マルチホップ通信における要求送信間隔が、移動前の要求送信間隔よりも大きい場合も考えられる。

【0096】

要求送信間隔が大きいということは、移動先のネットワークにおける欠損ブロック要求の頻度が高いことを意味する。そのため、通信端末Ｃが移動前の要求送信間隔で欠損ブロック要求を送信することは、トラフィック増に繋がるため好ましくない。そのため、通信端末Ｃは、通信対象（親ノード）の集約ルータＢが変更になった場合、変更後の最初の欠損ブロック要求のタイミングを、当該データの送信完了時刻の直後にタイミングを決定するときに用いた要求送信間隔（例えば、集約ルータＢにおける通信端末Ｃの最大収容数等から計算された値で、製造時に通信端末Ｃに設定される。）に基づいて決定する。その後、通信端末Ｃは、新たな親ノードの集約ルータＢから欠損ブロックを受信したときに新たな要求送信間隔も併せて受信し、以降の欠損ブロック要求の送信タイミングはその新たな要求送信間隔に基づいて算出する。

【0097】

このように、第２実施形態によれば、通信端末Ｃが親ノードとする集約ルータＢを変更しても、移動先のネットワークで欠損ブロック要求の送信タイミングを適切なタイミングに設定することができ、移動先のネットワークのトラフィックに悪影響を与えることを回避できる。

【0098】

（第３実施形態）
次に、第３実施形態について説明する。特にデータ配信システムＳが大規模な場合は、多数の通信端末Ｃがあり、設置待ちの在庫となる通信端末Ｃも存在し、データ配信期間の後で現場に設置される場合もある。

【0099】

また、設置後、周辺に接続可能な通信端末Ｃが無いなどの理由でデータ配信システムＳのネットワークに接続できず、データ配信期間の後に周囲に通信端末Ｃが設置されてネットワークに接続可能になる通信端末Ｃも存在する。このようにデータ配信システムＳに新規に参入する通信端末Ｃに対するデータ配信手順は次のように実現できる。

【0100】

新規の通信端末Ｃは、通信対象の集約ルータＢに自端末が受信すべきデータの有無を問い合わせる。集約ルータＢは、送信元の通信端末Ｃに対して当該データの有無（データ配信の要否）について通知する。

【0101】

当該データがある場合、新規の通信端末Ｃは、当該データの送信完了時刻の前であれば、集約ルータＢから当該データに対応するブロックを受信する。また、新規の通信端末Ｃは、当該データの送信完了時刻の後であれば、集約ルータＢから受信した要求送信間隔に基づいて決定したタイミングで欠損ブロック要求を集約ルータＢに送信する。

【0102】

つまり、ブロードキャストによるデータ配信期間に新規参入となった通信端末Ｃは、配信データが有ることの通知を受けた後は、他の通信端末Ｃと同様に、ブロードキャストによるデータ配信手順を実施する。

【0103】

また、欠損ブロック要求と配信を繰り返している期間（欠損ブロック送信期間）に新規参入となった通信端末Ｃは、配信データが有ることと最新の要求送信間隔の情報を集約ルータＢから得て、欠損ブロック要求の送信タイミングを算出し、その後は他の通信端末Ｃと同様に欠損ブロック要求／受信の手順を実施する。

【0104】

また、欠損ブロック送信期間後に新規参入となった通信端末Ｃは、配信データが有ることと最新の要求送信間隔の情報を集約ルータＢから得て、欠損ブロック要求の送信タイミングを算出し、欠損ブロック要求／受信の手順を実施する。

【0105】

また、集約ルータＢは、上述のいずれの期間でも、欠損ブロック要求に応じて要求送信間隔を決定する。この際、欠損ブロック要求が新規参入の通信端末Ｃからの要求か、既設の通信端末Ｃからの要求かを区別する必要はない。

【0106】

このように、第３実施形態によれば、通信端末Ｃの新規参入時の配信データの有無を集約ルータＢに問い合わせる手順以外は、既設の通信端末Ｃに対するデータ配信プロセスを適用することができ、新規参入時専用の手順を新たに規定することなく、データ配信が可能となる。また、新規参入の通信端末Ｃからのデータ配信の要否の問い合わせに対応するのは集約ルータＢなので、管理装置Ａの通信負荷やデータ配信のための処理負荷は増えずに済む。

【0107】

（第４実施形態）
次に、第４実施形態について説明する。データ配信の必要な通信端末Ｃが新規に設置され、データ配信を行う場合、データ配信の完了後すぐに、新たなデータで動作するために再起動を行う運用が考えられる。この場合、この通信端末Ｃは、一旦ネットワークから離脱し、再参入を実施する。データ配信にはある程度の時間がかかるため、新規設置から再起動までの間に、周辺の通信端末Ｃが新設の通信端末Ｃを通信経路に設定することも考えられる。

【0108】

また、この通信端末Ｃの再起動からネットワークへの再参入までにはある程度の時間がかかるため、この新設の通信端末Ｃを通信経路とした周辺の通信端末Ｃは通信ができない状態になる。また、単に通信エラーとなるだけでなく、周辺の通信端末Ｃ自体が再参入処理を開始するなどネットワークが不安定になる可能性もある。

【0109】

そこで、新規の通信端末Ｃは、すべてのブロックを取得した後に再起動が必要な場合、周囲の通信可能な通信端末Ｃに対して、再起動の完了までは自端末を途中経路の通信端末として選択しないことを要求する情報を通知する。つまり、通信端末Ｃは、新規参入時にデータ配信を受け、直後にデータで動作するために再起動を実施する場合は、データ配信が必要と認識した後、周辺の通信端末Ｃに、自身を通信経路に指定しないよう通知する。

【0110】

このように、第４実施形態によれば、新規参入の通信端末Ｃの周辺にある通信端末Ｃが、データ配信を受けて短時間で再起動を行う新規参入の通信端末Ｃを自身の通信経路に選択することを回避でき、ネットワークの安定性を確保することができる。

【0111】

（第５実施形態）
次に、第５実施形態について説明する。通信端末Ｃのソフトウェア開発時に、無条件あるいは端末種別やソフトウェアバージョンなど、ソフトウェア配信に関係のある条件で、通信端末Ｃが配信されているソフトウェア（データ）を取り込むべきかどうかが決定される。

【0112】

例えば、運用中に設定可能なパラメータが特定条件（例えば、シリアルナンバーが所定範囲など）の場合といった、データ配信に直接関係の無い条件によってデータ配信対象となる通信端末Ｃを限定したいという運用が考えられる。しかしながら、そのような条件をソフトウェア開発時に埋め込むことは容易ではない。このような特定条件を満たす通信端末Ｃのみにデータを配信する場合について、以下に説明する。

【0113】

データ配信プロセスの開始時に、管理装置Ａまたは集約ルータＢから通信端末Ｃに対し、管理装置Ａにデータ配信の条件を確認するかどうかの情報を通知する。確認要となった場合には、通信端末Ｃが管理装置Ａに条件に合致するかどうか問い合わせを行う。管理装置Ａは通信端末Ｃを識別して、データ配信が必要かどうかの判定結果を通信端末Ｃに通知する。

【0114】

つまり、管理装置Ａにおいて、配信要否条件記憶部１１２は、配信データ記憶部１１１に記憶されているデータごとに、それぞれの通信端末Ｃごとの配信の要否の条件を記憶している。そして、配信要否通知部１２２は、任意の通信端末Ｃからデータ配信の要否の問い合わせがあったとき、配信要否条件記憶部１１２を参照して、送信元の通信端末Ｃに対してデータ配信の要否について通知する。

【0115】

データ配信が必要との通知を受けた通信端末Ｃは、配信中のデータを自身のデータとして格納する。データ配信が不要との通知を受けた通信端末Ｃは、必要に応じてデータ（ブロック）の転送を実施するが、自身には取り込まない。

【0116】

このように、第５実施形態によれば、データ配信の要否の条件判定を管理装置Ａで実行し、通信端末Ｃはその結果のみを受け取ることで、通信端末Ｃのソフトウェア開発時に、将来必要となる具体的な条件判定を埋め込む必要は無く、ソフトウェア開発が容易となる。

【0117】

また、無条件にすべての通信端末Ｃにデータを配信したい場合には、通信端末Ｃから管理装置Ａへの確認が不要なことを通信端末Ｃに通知することで、確認のために必要な通信端末Ｃと管理装置Ａとの間のトラフィックや、管理装置Ａの処理負荷を無くすことができる。この確認プロセスは、ブロードキャストによるデータ配信にも適用でき、また通信端末Ｃの新設時のデータ配信にも適用できる。

【0118】

なお、上述した実施の形態における、上記処理を実行するためのプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）、ＵＳＢ（Universal Serial Bus）メモリ等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよいし、インターネット等のネットワーク経由で提供または配布するように構成してもよい。また、各種プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

【0119】

また、上述した実施の形態における、上記処理を実行するめのプログラムは、各機能部を含むモジュール構成となっており、実際のハードウェアとしては、例えば、ＣＰＵ（プロセッサ回路）がＲＯＭまたはＨＤＤから上記プログラムを読み出して実行することにより、上述した各機能部がＲＡＭ（主記憶）上にロードされ、上述した各機能部がＲＡＭ（主記憶）上に生成されるようになっている。なお、上述した各機能部の一部または全部を、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field-Programmable Gate Array）などの専用のハードウェアを用いて実現することも可能である。

【0120】

なお、上記には、実施の形態を説明したが、上記実施の形態は、例として提示したものであり、発明の範囲を限定することは意図していない。上記新規な実施の形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。上記実施の形態は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【0121】

例えば、上述の実施形態では、主にソフトウェア配信について説明したが、これに限定されず、多数の通信端末Ｃに対し大きなデータを配信する場合にも適用可能である。

【符号の説明】

【0122】

Ａ…管理装置、Ｂ…集約ルータ、Ｃ…通信端末、１１…記憶部、１２…処理部、１３…ＷＡＮ通信部、２１…記憶部、２２…処理部、２３…ＷＡＮ通信部、２４…無線通信部、３１…記憶部、３２…処理部、３３…無線通信部、１１１…配信データ記憶部、１１２…配信要否条件記憶部、１２１…配信処理部、１２２…配信要否通知部、２２１…配信データ分割処理部、２２２…ブロードキャスト配信処理部、２２３…欠損ブロック配信処理部、２２４…要求送信間隔決定部、２２５…配信データ処理制御部、３１１…配信データ記憶部、３２１…欠損ブロック管理部、３２２…ブロードキャスト配信処理部、３２３…ユニキャスト配信処理部、３２４…要求送信間隔抽出部、３２５…欠損ブロック要求送信部、Ｓ…データ配信システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】