<第1実施形態>
[ソフトウェアの配信方法の概要]
図1は、第1実施形態に係るソフトウェアの配信方法の概要を説明するための図である。図1に示す配信装置3は、基地局2を介して通信装置1とデータを送受信する。
通信装置1は、ネットワークを介して、サーバ又は他の通信装置1に対してデータを送受信する機器であり、例えば、IoT機器又は人の手を介さずに複数の機器が相互に通信する機器間通信であるM2M(Machine to Machine)に対応した機器である。通信装置1は、例えば、通信モジュールを組み込んだ電力使用量を計測するスマートメータ、又はインターネットを介して操作することができる家電製品等である。本実施形態において通信装置1は、設置した場所から移動しない装置であるとして説明する。
基地局2は、無線通信網において、通信装置1と配信装置3との通信を中継する役割を有する。無線通信網は、例えば、携帯電話網、又はIoT機器の通信で利用されるLPWA(Low Power Wide Area)であり、具体的にはNB−IoT(Narrow Band-IoT)、LoRaWAN(登録商標)、SIGFOX(登録商標)等である。
配信装置3は、ソフトウェアの配信を制御するFOTAサーバである。配信装置3は、例えば、PC(Personal Computer)である。ここで、配信装置3が配信するソフトウェアは、通信装置1にインストールされているソフトウェアを更新する更新用ソフトウェア及び通信装置1に実行させる機能を追加する追加用ソフトウェアを含む。本明細書においては、配信装置3が配信するソフトウェアが更新用ソフトウェアである場合について主に説明する。
配信装置3は、更新用ソフトウェアを提供する提供サーバと、更新用ソフトウェアの配信を制御するFOTAサーバとで分けてもよい。この場合、FOTAサーバは、通信事業者によって設置され、提供サーバは、通信装置1の製造業者ごと又は通信事業者によって設置される。本明細書における配信装置3は、通信事業者が管理するサーバであって、提供サーバ及びFOTAサーバの機能を備えたサーバであるとして説明する。
図1に示す配信装置3が更新用ソフトウェアを配信する場合において、配信装置3は、予め記憶している配信対象である複数の通信装置1それぞれに応答要求を送信する。通信装置1は、応答要求を受信すると、通信装置1の装置識別情報である通信装置IDと、無線通信網の複数の基地局2のうち通信装置1が属する基地局2の識別情報である基地局IDとを配信装置3に送信する。
ところで、基地局2においては、無線通信回線の種類ごとに同時接続数が設定されている。そのため、更新用ソフトウェアの配信により、基地局2の無線通信回線の1つであるLPWAの同時接続数が上限に達すると、通常動作として通信を行う通信装置1がLPWAに接続することができなくなる。そこで、配信装置3は、通信装置1から通信装置ID及び基地局IDを取得すると、通信装置ID及び基地局IDに基づいて、基地局2ごとに、通信装置1に更新用ソフトウェアを配信する順序を決定し、閾値台数以下の台数の通信装置1に対して基地局2から更新用ソフトウェアを配信する。
ここで、1つの基地局2から更新用ソフトウェアを配信できる閾値台数が「5台」であり、順序が通信装置1のIDの昇順であるとする。更新用ソフトウェアを配信できる閾値台数は、基地局2がLPWAを用いて同時に更新用ソフトウェアを配信可能な台数である。LPDWにおいては、限られた無線帯域を多数の機器が共有して使用するために、データを伝送する間だけ基地局2と通信装置1との間で無線接続される。閾値台数は、更新用ソフトウェアを配信するために基地局2が使用可能な無線チャネルの数に等しい。
閾値台数が5台の場合、図1に示す配信装置3は、基地局ID「1001」に対応する基地局2に属する通信装置1のうち、例えば、まず通信装置ID「0001」から「0007」に対応する5台の通信装置1に対して、基地局2から同時に更新用ソフトウェアの配信を開始するか、またはその順序に従って配信開始時刻を変えて配信する。通信装置1は、更新用ソフトウェアの受信が完了すると、受信が完了したことを示す結果情報を配信装置3に通知する。配信装置3は、更新用ソフトウェアの受信が完了したことを示す結果情報を通信装置1から受信すると、当該通信装置1への更新用ソフトウェアの配信が完了したと判定する。
配信装置3は、通信装置1から更新用ソフトウェアの受信が完了したことを示す結果情報を受信すると、まだ更新用ソフトウェアを配信していない通信装置1に更新用ソフトウェアを配信する。配信装置3は、例えば、1台の通信装置1から更新用ソフトウェアの受信が完了したことを示す結果情報を受信した場合、まだ更新用ソフトウェアを配信していない通信装置1のうち、次の優先順位である通信装置ID「0008」に対応する通信装置1に対して、基地局2から更新用ソフトウェアを配信する。配信装置3は、基地局ID「1001」に対応する基地局2と同様に、基地局ID「1002」に対応する基地局2をはじめとする他の基地局2に対して、閾値台数を超えないように更新用ソフトウェアの配信を制御する。
以上のとおり、配信装置3は、基地局2ごとに、更新用ソフトウェアを配信する通信装置1の台数を制御することにより、基地局2に接続する他の通信装置1に影響を与えずに、更新対象である大量の通信装置1にソフトウェアを更新させることができる。
以下、配信装置3の詳細について説明する。
[配信装置3の構成]
図2は、第1実施形態に係る配信装置3の構成を示す図である。配信装置3は、通信部31、記憶部32、及び制御部33を備える。
通信部31は、基地局2を介して、通信装置1にデータを送受信するための無線通信コントローラを含んでいる。
記憶部32は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)及びハードディスク等の記憶媒体である。記憶部32は、制御部33が実行する各種のプログラムを記憶する。記憶部32は、更新用ソフトウェアを配信する対象である通信装置1を識別するための通信装置IDの一覧である配信対象一覧及び配信する更新用ソフトウェアを記憶する。また、記憶部32は、更新用ソフトウェアを配信する通信装置1の通信装置IDを配信状況データベース(以下、配信状況DB(Database)という)に記憶し、更新用ソフトウェアをまだ配信していない通信装置1の通信装置IDを配信待ちデータベース(以下、配信待ちDBという)に記憶する。
図3は、第1実施形態に係る配信状況DBの構成を示す図である。図3に示すように、配信状況DBは、基地局IDと、当該基地局IDに属する通信装置1の通信装置IDと、更新用ソフトウェアの配信状況を示す配信状況とを関連付けて記憶している。配信状況DBにレコードが含まれている通信装置1は、更新用ソフトウェアの配信が可能であること、又は配信中であることを示す。レコードは、図3における基地局IDと、通信装置IDと、配信状況とを組み合わせたデータ、又は後述する図4における通信装置IDと、基地局IDとを組み合わせたデータである。
配信状況には、例えば、「未実行」と、「成功」と、「失敗」とがある。「未実行」は、更新用ソフトウェアの配信が可能であること、又は更新用ソフトウェアが配信中であることを示す。「成功」は、更新用ソフトウェアの配信が完了したこと、すなわち、通信装置1において更新用ソフトウェアの受信が完了したことを示す。「失敗」は、更新用ソフトウェアの配信が完了しなかったこと、すなわち、通信装置1において更新用ソフトウェアの受信が完了しなかったことを示す。配信状況DBにおいては、1つのDBに複数の基地局IDを混在させた構成としてもよいし、基地局IDごとにDBを設けた構成としてもよい。本実施形態においては、1つの配信状況DBに複数の基地局IDを混在させた構成として説明する。
図4は、第1実施形態に係る配信待ちDBの構成を示す図である。図4に示すように、配信待ちDBは、通信装置IDと、当該通信装置IDに対応する通信装置1が属する基地局2の基地局IDとを関連付けて記憶している。配信待ちDBにレコードが含まれている通信装置1は、更新用ソフトウェアがまだ配信されていないことを示す。初期の配信待ちDBにおいては、配信対象一覧に含まれる通信装置IDが格納され、基地局IDが空白となっており、後述する情報取得部331が通信装置1から基地局IDを取得することにより、基地局IDが格納される。
図2に戻り、制御部33は、例えばCPU(Central Processing Unit)である。制御部33は、記憶部32に記憶されているプログラムを実行することにより、配信装置3に係る機能を制御する。制御部33は、プログラムを実行することにより、情報取得部331、決定部332、及び配信部333として機能する。
情報取得部331は、通信部31を介して、通信装置1との間でデータを送受信する。具体的には、情報取得部331は、記憶部32に格納されている通信装置IDの一覧情報に基づいて、通信部31を介して通信装置1に応答要求を送信する。また、情報取得部331は、通信部31を介して、通信装置1から、通信装置IDと、無線通信網の複数の基地局2のうち通信装置1が属する基地局2を識別するための基地局IDとを取得する。
情報取得部331は、更新用ソフトウェアを配信した通信装置1から受信が完了したか否かを示す結果情報を取得する。情報取得部331は、通信装置1から取得した通信装置ID及び基地局ID、又は結果情報を決定部332に入力する。
決定部332は、通信装置ID及び基地局IDに基づいて、基地局2ごとに、基地局2に属する複数の通信装置1のソフトウェアを配信する順序を決定する。例えば、決定部332は、情報取得部331から入力された通信装置ID及び基地局IDに基づいて、基地局2ごとに、更新用ソフトウェアを配信する通信装置1の順序を決定し、決定した順序に基づいて配信待ちDBに格納されているレコードの順序を並び替える。ソフトウェアを配信する順序は、通信装置IDに基づく順序でもよいし、通信装置1からデータを取得した日時に基づく順序でもよい。本実施形態においては、通信装置IDの昇順に順序が決定されるとする。
決定部332は、情報取得部331から入力された結果情報に基づいて、配信状況DBを更新する。具体的には、決定部332は、情報取得部331から入力された結果情報に基づいて、配信状況DBに格納されているレコードのうち、結果情報に含まれる通信装置IDに対応する配信状況を更新する。決定部332は、結果情報が、更新用ソフトウェアの受信が完了したことを示している場合、配信状況を「成功」とし、更新用ソフトウェアの受信が完了していないことを示している場合、配信状況を「失敗」とする。
配信部333は、決定部332が決定した順序に基づいて、閾値台数以下の台数の通信装置1に対して基地局2から更新用ソフトウェアを配信する。具体的には、配信部333は、まず、決定部332が決定した順序で格納された配信待ちDBから複数の基地局2それぞれにおける閾値台数以下の数のレコードを抽出し、決定部332が決定した順序で配信状況DBに格納する。そして、配信部333は、記憶部32に格納されている更新用ソフトウェアを、配信状況DBに格納したレコードの順番に、通信装置1に対して基地局2から配信する。
例えば、1つの基地局2における閾値台数が5台である場合、配信部333は、決定部332が決定した順序で配信待ちDBに格納されているレコードのうち、複数の基地局2それぞれにおける上位5つのレコードを抽出し、配信状況DBに格納する。そして、配信部333は、配信状況DBに格納したレコードの順番に、通信装置1に対して、基地局2から更新用ソフトウェアを配信する。
配信部333は、更新用ソフトウェアのサイズに基づいて閾値台数を決定してもよい。例えば、1つの基地局2における閾値台数が、更新用ソフトウェアのサイズが100キロバイトを超える場合は1台減らした4台となり、200キロバイトを超える場合は2台減らした3台となるように、100キロバイト単位に閾値台数が少なくなるとする。この場合において、更新用ソフトウェアのサイズが200キロバイトである場合、配信部333は、決定部332が決定した順序のうち、複数の基地局2それぞれにおける上位3台の通信装置1に対して基地局2から更新用ソフトウェアを配信する。このようにすることで、更新用ソフトウェアのサイズが大きい場合であっても、基地局2の通信容量が逼迫することを防ぐことができる。
配信部333は、更新用ソフトウェアを配信する時刻に基づいて閾値台数を決定してもよい。例えば、配信部333は、LPWAの通信量が多くなる時間帯においては、更新用ソフトウェアを配信する閾値台数を少なくし、通信量が少なくなる時間帯においては、閾値台数を多くする。このようにすることで、更新用ソフトウェアの配信によって基地局2の通信に影響を与えることを防ぐことができる。
配信部333は、基地局2の種別に基づいて閾値台数を決定してもよい。例えば、基地局2の種別によって同時接続数が異なる場合、配信部333は、基地局2の種別に応じて閾値台数を決定する。このようにすることで、更新用ソフトウェアの配信によって基地局2それぞれの通信に影響を与えることを防ぐことができる。
配信部333は、通信装置1が所定のアプリケーションを実行していないタイミングで更新用ソフトウェアを配信してもよい。例えば、深夜時間帯においては通信装置1が所定のアプリケーションを実行していない場合、配信部333は、通信装置1が所定のアプリケーションを実行していないタイミングである深夜時間帯に更新用ソフトウェアを配信する。
配信部333は、例えば、アプリケーションの動作時間を示す動作時間情報を、通信装置1を管理する不図示のアプリケーションサーバから取得することにより、通信装置1が所定のアプリケーションを実行しているか否かを判定する。この場合、配信部333は、情報取得部331がアプリケーションサーバから取得した動作時間情報が示す動作時間以外のタイミングで更新用ソフトウェアを配信する。また、配信部333は、通信装置1に応答要求を送信し、応答要求に対して通信装置1から受信した、アプリケーションを実行中であるか否かを示す動作情報を含む応答情報に基づいて、通信装置1がアプリケーションを実行しているか否かを判定してもよい。この場合、配信部333は、応答情報に含まれる動作情報が、アプリケーションを実行中であることを示している場合、更新用ソフトウェアを配信しない。配信部333は、動作情報が、アプリケーションを実行中でないことを示している場合、更新用ソフトウェアを配信する。このようにすることで、更新用ソフトウェアの配信によって通信装置1が行う通常動作に影響を与えることを防ぐことができる。
配信部333は、閾値台数と等しい台数の通信装置1に対して更新用ソフトウェアを配信中に、複数の通信装置1のうち一以上の通信装置1への更新用ソフトウェアの配信が終了すると、決定部332が決定した順序に基づいて複数の通信装置1から選択した一以上の通信装置1への更新用ソフトウェアの配信を開始する。例えば、1つの基地局2における閾値台数が5台である場合において、ある基地局2に属する2台の通信装置1における更新用ソフトウェアの配信が終了したとする。
この場合において、配信部333は、まず、決定部332が決定した順序で格納された配信待ちDBから当該基地局2に属する上位2つのレコードを抽出し、配信状況DBに格納する。そして、配信部333は、配信状況DBに格納したレコードの順に、レコードに対応する2台の通信装置1に対して、基地局2から更新用ソフトウェアを配信する。このようにすることで、更新対象である通信装置1が大量にあっても、基地局2における他の通信に影響を与えずに、順次、全ての通信装置1に更新用ソフトウェアを更新させることができる。
配信部333は、配信状況DBの配信状況に基づいて、配信状況DB及び配信待ちDBを更新する。具体的には、配信部333は、配信状況が「成功」である場合、すなわち、情報取得部331が通信装置1から取得した結果情報が、更新用ソフトウェアの受信が完了したことを示す場合、当該通信装置1のレコードを配信状況DBから削除する。一方、配信部333は、配信状況が「失敗」である場合、すなわち、情報取得部331が通信装置1から取得した結果情報が、更新用ソフトウェアの受信が完了しなかったことを示す場合、当該通信装置1のレコードを配信状況DBから抽出し、配信待ちDBに格納する。配信部333は、配信状況が「失敗」である場合、配信状況DBから抽出したレコードを配信待ちDBの最後尾に格納してもよいし、通信装置IDの昇順に合わせて格納してもよい。配信部333は、配信状況DBにレコードがない場合、すなわち、配信対象の通信装置1がない場合、配信対象の通信装置1全てに更新用ソフトウェアの配信が終了したと判定する。
[配信装置3の処理]
続いて、配信装置3が行う処理の流れを説明する。図5は、第1実施形態に係る配信装置3が行う処理の流れを示すフローチャートである。本フローチャートは、配信装置3の管理者が記憶部32に更新用ソフトウェアを格納したことを契機として開始する。
情報取得部331は、記憶部32に格納されている通信装置IDの一覧情報に基づいて、通信部31を介して通信装置1に応答要求を送信する(S1)。応答要求を受信した通信装置1それぞれから応答情報が送信されると、情報取得部331は、通信部31を介して、応答情報に含まれる基地局IDを取得する(S2)。具体的には、情報取得部331は、通信装置1から、通信装置ID及び基地局IDを取得する。情報取得部331は、取得した通信装置ID及び基地局IDを決定部332に入力する。
決定部332は、情報取得部331から入力された通信装置ID及び基地局IDに基づいて、更新用ソフトウェアを配信する通信装置1の順序を決定する(S3)。図6は、第1実施形態に係る配信処理の流れを説明するための図である。決定部332は、図6に示すバージョン1の配信待ちDBに、順序を通信装置IDの昇順にした上で、通信装置IDと基地局IDとを対応付けて格納する。
図5に戻り、配信部333は、決定部332が決定した順序に基づいて、閾値台数以下の台数の通信装置1に対して基地局2から更新用ソフトウェアを配信する(S4)。例えば、1つの基地局2における閾値台数が5台である場合、配信部333は、まず、図6に示すバージョン1の配信待ちDBから基地局ID「1001」に属する上位5つのレコードを抽出し、バージョン1の配信状況DBに格納する。配信部333は、抽出したレコードをバージョン1の配信状況DBから削除し、閾値台数を超えた通信装置ID「0008」に対応するレコードをバージョン2の配信待ちDBに示すように最後尾に格納する。そして、配信部333は、バージョン1の配信状況DBに格納したレコードに対応する通信装置1に対して、基地局2から更新用ソフトウェアの配信を開始する。配信部333は、他の基地局2に属する通信装置1に対しても同様の処理を行う。
図5に戻り、更新用ソフトウェアの配信が終了した通信装置1から、受信が完了したか否かを示す結果情報が送信されると、決定部332は、結果情報に基づいて、更新用ソフトウェアの配信が成功したか否かを判定する(S5)。具体的には、まず、情報取得部331は、通信装置1から結果情報を取得し、取得した結果情報を決定部332に入力する。そして、決定部332は、情報取得部331から入力された結果情報に基づいて、配信状況DBを更新する。
図7は、第1実施形態に係る配信処理の流れを説明するための図である。例えば、通信装置ID「0001」に対応する通信装置1から、受信が完了したことを示す結果情報が送信された場合、決定部332は、バージョン2の配信状況DBに示すように、通信装置ID「0001」に対応する配信状況を「成功」に更新する。
一方、通信装置ID「0007」に対応する通信装置1から、受信が完了しなかったことを示す結果情報が送信された場合、決定部332は、バージョン2の配信状況DBに示すように、通信装置ID「0007」に対応する配信状況を「失敗」に更新する。図5に戻り、決定部332は、配信が成功したと判定した場合、処理をS6に進め、配信が失敗したと判定した場合、処理をS8に進める。
配信部333は、配信が成功したと判定した場合、配信が成功した通信装置1に対応するレコードを配信状況DBから削除する(S6)。具体的には、配信部333は、図7に示す配信状況が「成功」であるレコードを配信状況DBから削除する。続いて、配信部333は、配信待ちDBにレコードがあるか否かを判定する(S7)。配信部333は、配信待ちDBにレコードがあると判定した場合、処理をS10に進め、配信待ちDBにレコードがないと判定した場合、処理をS11に進める。
配信部333は、S5において決定部332が更新用ソフトウェアの配信が失敗したと判定した場合、配信待ちDBにレコードがあるか否かを判定する(S8)。配信部333は、配信待ちDBにレコードがあると判定した場合、処理をS9に進める。一方、配信部333は、配信待ちDBにレコードがないと判定した場合、すなわち、更新用ソフトウェアをまだ配信していない通信装置1がない場合、処理をS4に戻し、更新用ソフトウェアの配信が失敗した通信装置1に更新用ソフトウェアを再配信する。
配信部333は、S8において配信待ちDBにレコードがあると判定した場合、更新用ソフトウェアの配信が失敗した通信装置1に対応するレコードを配信状況DBから抽出し、配信待ちDBの最後尾に格納する(S9)。具体的には、配信部333は、図7に示す配信状況が「失敗」であるレコードを配信状況DBから抽出し、バージョン3の配信待ちDBの最後尾に格納する。配信部333は、抽出したレコードを配信状況DBから削除する。
配信部333は、S9に続いて、又はS7において配信待ちDBにレコードがあると判定した場合、配信状況DBの更新処理を行う(S10)。具体的には、配信部333は、閾値台数と等しい台数の通信装置1に対して更新用ソフトウェアを配信中に、複数の通信装置1のうち一以上の通信装置1への更新用ソフトウェアの配信が終了すると、決定部332が決定した順序に基づいて複数の通信装置1から選択した一以上の通信装置1への更新用ソフトウェアの配信を開始する。
図7に示すバージョン2の配信状況DBにおいて、通信装置ID「0001」及び「0007」に対応する2台の通信装置1への更新用ソフトウェアの配信が終了しているとする。この場合において、配信部333は、バージョン3の配信待ちDBから基地局ID「1001」に対応するレコードのうち、上位2つのレコードを抽出し、バージョン3の配信状況DBに示すように2つのレコードを配信状況DBに格納する。そして、配信部333は、処理をS4に戻し、配信状況DBに格納したレコードに対応する2台の通信装置1に対して、基地局2から更新用ソフトウェアの配信を開始する。
配信部333は、S7において配信待ちDBにレコードがないと判定した場合、配信状況DBにレコードがあるか否かを判定する(S11)。配信部333は、配信状況DBにレコードがあると判定した場合、処理をS5に戻す。配信部333は、配信状況DBにレコードがないと判定した場合、すなわち、配信対象の全ての通信装置1から、受信が完了したことを示す結果情報を受信し、配信対象の全ての通信装置1への更新用ソフトウェアの配信が完了したと判定した場合、処理を終了する。
[第1実施形態における効果]
以上説明した通り、第1実施形態に係る配信装置3は、基地局2ごとに、更新用ソフトウェアの配信順序を決定し、閾値台数以下の台数の通信装置1に対して基地局2から更新用ソフトウェアを配信する。また、配信装置3は、更新用ソフトウェアを配信中の通信装置1のうち、一以上の通信装置1から受信が完了したことを示す結果情報を受信したことにより更新用ソフトウェアの配信が終了したと判定した場合に、配信順序に基づいて、配信が終了した通信装置1の台数と同じ台数の通信装置1に更新用ソフトウェアを配信する。このようにすることで、配信装置3は、更新対象である通信装置1が大量にあっても、更新用ソフトウェアの同時配信数を制御しながら、全ての通信装置1に更新用ソフトウェアを配信することができる。その結果、配信装置3は、基地局2に接続する他の通信装置1に影響を与えずに、更新対象である大量の通信装置1にソフトウェアを更新させることができる。
<第2実施形態>
[移動可能な通信装置1に更新用ソフトウェアを配信する]
続いて、第2実施形態について説明する。第1実施形態に係る配信装置3は、通常の使用において移動しない通信装置1に更新用ソフトウェアを配信した。これに対して、第2実施形態に係る配信装置3は、移動しない通信装置1と移動する通信装置1(例えば、無線通信網を介して位置情報をサーバに送信するGPSトラッカー等)とに対して更新用ソフトウェアを配信する点で第1実施形態と異なる。以下に、第1実施形態と異なる部分について説明を行う。第1実施形態と同じ部分については適宜説明を省略する。また、本実施形態における更新対象のソフトウェアは、通信事業者が自身のネットワークに接続するために提供された通信モジュールを制御するソフトウェアであるとして説明する。
図8は、第2実施形態に係る配信待ちDBの構成を示す図である。図8に示すように、配信待ちDBは、通信装置IDと基地局IDとに加えて、通信装置1が移動するか否かを示す装置種別と、通信装置1から応答情報を取得した日時を示す取得日時とを関連付けて記憶している。装置種別は、例えば、移動可能な通信装置1であることを示す「移動」と、固定して設置される通信装置1であることを示す「固定」とがある。装置種別は、例えば、予め通信装置IDに関連付けて一覧情報に記憶されている。配信装置3は、更新用ソフトウェアの配信履歴を記憶部32に記憶させておき、配信履歴において属していた基地局2と、最新の時点で属している基地局2とが異なる場合に「移動」であると判定してもよい。本実施形態においては、装置種別が予め通信装置IDに関連付けて一覧情報に記憶されている場合について説明する。
第2実施形態に係る情報取得部331は、通信装置1から基地局IDを取得した後に所定の時間が経過する前に配信部333が通信装置1に更新用ソフトウェアの配信を開始できない場合に、通信装置1が属する基地局2の基地局IDを再び取得する。例えば、所定の時間が「10分」である場合において、情報取得部331は、まず、配信待ちDBに格納されているレコードに対応する通信装置1に対して更新用ソフトウェアの配信が可能となった場合に、取得日時から10分を経過した通信装置1に対して応答要求を再び送信する。そして、情報取得部331は、応答要求を受信した通信装置1から応答情報が送信されると、応答情報を取得し、応答情報に含まれる通信装置ID、基地局ID、及び応答情報を取得した日時を決定部332に入力する。
情報取得部331は、基地局2に属している移動可能な通信装置1の数に基づいて、通信装置1が属する基地局2の基地局IDを再び取得する前に待機する所定の時間を決定してもよい。例えば、情報取得部331は、固定して設置された通信装置1より移動可能な通信装置1の方が多い場合、移動可能な通信装置1より固定して設置された通信装置1の方が多い場合に比べて、待機する時間を短い時間に決定する。一方、情報取得部331は、移動可能な通信装置1より固定して設置された通信装置1の方が多い場合、固定して設置された通信装置1より移動可能な通信装置1の方が多い場合に比べて、待機する時間を長い時間に決定する。このようにすることで、情報取得部331は、移動可能な通信装置1の数が多い基地局2に属する通信装置1の通信装置IDを更新する頻度を高くすることができるので、配信部333が、通信装置1が属していない基地局2に対して更新用ソフトウェアを配信する確率を下げることができる。
情報取得部331は、装置種別に基づいて、通信装置1が属する基地局2の基地局IDを再び取得する前に待機する所定の時間を決定してもよい。例えば、情報取得部331は、移動可能な通信装置1が待機する時間を、固定して設置された通信装置1が待機する時間に比べて短い時間に決定する。一方、情報取得部331は、固定して設置された通信装置1が待機する時間を、移動可能な通信装置1が待機する時間に比べて長い時間に決定する。
また、移動可能な通信装置1が加速度センサを備えている場合、情報取得部331は、通信装置1から加速度センサで計測された加速度の情報を含む応答情報を取得し、当該加速度の情報に基づいて、通信装置1が移動中であるか否かを判断してもよい。この場合、情報取得部331は、移動可能な通信装置1が移動中であると判断した場合、移動していないと判断した場合に比べて、待機する時間をより短い時間に決定する。このようにすることで、情報取得部331は、移動している通信装置1に対して、属する基地局2の基地局IDを更新する頻度を高くすることができるので、配信部333が、通信装置1が属していない基地局2に対して更新用ソフトウェアを配信する確率をより下げることができる。
情報取得部331は、通信装置1が移動可能であることを条件として、通信装置1が属する基地局2の基地局IDを、配信部333が更新用ソフトウェアを再び配信するタイミングの所定時間前に再び取得してもよい。具体的には、情報取得部331は、配信待ちDBに格納されているレコードに対応する通信装置1に対して更新用ソフトウェアの配信が可能となった場合において、当該通信装置1の装置種別が「移動」である場合に、通信装置1が属する基地局2の基地局IDを再び取得する。情報取得部331は、通信装置1が移動中であることを条件として、通信装置1が属する基地局2の基地局IDを再び取得してもよい。このようにすることで、情報取得部331は、固定して設置される通信装置1、すなわち、属する基地局2が変わらない通信装置1に対して、基地局IDを再び取得することを防ぐことができる。
第2実施形態に係る決定部332は、情報取得部331が先に取得していた第1基地局IDと、情報取得部331が再び取得した第2基地局IDとが異なっている場合に、第1基地局IDを情報取得部331が取得した時点で通信装置1が属していた第1基地局2、及び第2基地局IDを情報取得部331が取得した時点で通信装置1が属する第2基地局2のそれぞれに対応する順序を再決定する。
図9は、第2実施形態に係る配信順序を決定する処理の流れを説明するための図である。バージョン1の配信状況DBに示すように、3台の通信装置1が更新用ソフトウェアの受信に成功したことにより更新用ソフトウェアの配信が成功し、通信装置1それぞれが属する基地局2から1台の通信装置1に対して更新用ソフトウェアの配信が可能となった状況であるとする。また、バージョン1の配信待ちDBに示すように、情報取得部331が、閾値台数を下回った基地局2に属する通信装置1それぞれから基地局IDを再び取得したところ、通信装置ID「0008」に対応する通信装置1が属する基地局2が変わったとする。
この場合において、決定部332は、通信装置ID「0008」に対応するレコードにおける基地局IDを、基地局ID「1002」から基地局ID「1003」に変更する。その結果、基地局ID「1002」の基地局2が更新用ソフトウェアを配信する対象となる通信装置1から通信装置ID「0008」の通信装置1が削除され、配信する順序が更新される。また、基地局ID「1003」の基地局2が更新用ソフトウェアを配信する対象となる通信装置1として通信装置ID「0008」の通信装置1が追加され、配信する順序が更新される。
なお、決定部332は、通信装置ID「0008」の通信装置1の移動に伴って、配信待ちDBにおける順番を変更し、例えばバージョン2の配信待ちDBに示すように最後尾に格納してもよい。決定部332が再決定する順序においては、属する基地局2が変わった通信装置1を、このように最後尾にしてもよいし、同じ基地局2に属する通信装置1の先頭にしてもよい。
また、決定部332は、取得日時に基づいて順序を決定する場合、第1基地局IDと異なる第2基地局IDを取得した日時に基づいて、配信待ちDBに格納されているレコードの順序を並び替えてもよい。例えば、決定部332は、第2基地局IDを取得した日時が古い順に順序を決定する。
このように決定部332は、第1基地局IDに基づいて決定した順序を、ある通信装置1が属する基地局2が、第1基地局IDとは異なる第2基地局IDに変わったことに応じて更新することにより、基地局2ごとに、通信装置1に更新用ソフトウェアを配信する順序を再決定する。その後、配信部333は、配信待ちDBに格納されているレコードのうち、基地局ID「1001」、「1002」、及び「1003」の基地局2に属するそれぞれの通信装置1に対応するレコードを抽出し、バージョン2の配信状況DBに示すように格納する。そして、配信部333は、配信状況DBに格納した通信装置ID「0007」、「0009」、及び「0011」に対応する通信装置1それぞれに対して、属する基地局2ごとに更新用ソフトウェアの配信を開始する。
このようにすることで、決定部332は、配信部333が、通信装置1が属していない基地局2に対して更新用ソフトウェアを配信する確率を下げつつ、基地局2ごとに、変動する通信装置1の台数に基づいて決定された順序に基づいて、更新用ソフトウェアを配信することができる。
決定部332は、基地局2に属する複数の通信装置1のうち移動可能な通信装置1の割合が閾値未満である場合に、移動可能な通信装置1の割合が閾値以上である場合よりも早いタイミングで順序を決定してもよい。例えば、決定部332は、固定して設置される通信装置1が多数を占めて、移動可能な通信装置1がほとんどない場合に、情報取得部331が通信装置1から基地局IDを取得する前のタイミングで順序を決定する。一方、決定部332は、移動可能な通信装置1が多数を占めて、固定して設置される通信装置1がほとんどない場合に、情報取得部331が通信装置1から基地局IDを取得する前においては順序を決定せずに、取得した後のタイミングで順序を決定する。このように決定部332が予め順序を決定することで、配信装置3の管理者は、更新用ソフトウェアの配信にかかる期間の見通しを立てることができる。
決定部332は、基地局2に属する複数の通信装置1のうち移動可能な通信装置1の割合が閾値以上である場合に、更新用ソフトウェアが配信可能な状態になった後に順序を決定してもよい。例えば、決定部332は、移動可能な通信装置1が多数を占めて、固定して設置される通信装置1がほとんどない場合に、予め順序を決定せず、情報取得部331が通信装置1から取得した基地局IDに基づいて順序を決定する。このようにすることで、決定部332は、配信部333が、通信装置1が属していない基地局2に対して更新用ソフトウェアを配信する確率を下げることができる。
[配信状況DB更新処理]
続いて、配信装置3が行う処理の流れを説明する。第2実施形態に係る配信装置3が行う処理においては、図5の配信状況DB更新処理(S10)のみ異なるため、当該処理のみについて説明する。図10は、第2実施形態に係る配信装置3が行う配信状況DB更新処理の流れを示すフローチャートである。本フローチャートは、図5のS9に続いて、又はS7において配信部333が配信待ちDBにレコードがあると判定した場合を契機として開始する。
情報取得部331は、配信部333が閾値台数と等しい台数の通信装置1に対して更新用ソフトウェアを配信中に、複数の通信装置1のうち一以上の通信装置1への更新用ソフトウェアの配信が終了すると、順序に基づいて複数の通信装置1から選択した一以上の通信装置1が移動可能な通信装置1であるか否かを判定する(S101)。具体的には、情報取得部331は、配信待ちDBに格納されているレコードのうち、配信部333が選択した一以上のレコードの装置種別が「移動」であるか「固定」であるかを判定する。
また、配信待ちDBに格納されているレコードに加速度の状態が関連付けて記憶されている場合に、情報取得部331は、配信待ちDBに格納されているレコードのうち、配信部333が選択した一以上のレコードの加速度の状態が移動中であることを示しているか否かに基づいて、装置種別が「移動」であるか「固定」であるかを判定してもよい。また、更新用ソフトウェアの配信履歴が記憶部32に記憶されている場合に、情報取得部331は、配信待ちDBに格納されているレコードのうち、配信履歴が示している過去に属していた基地局2と、現時点で属している基地局2とが異なるか否かに基づいて、装置種別が「移動」であるか「固定」であるかを判定してもよい。
情報取得部331は、装置種別が「固定」であると判定した場合、処理をS105に進める。一方、情報取得部331は、装置種別が「移動」であると判定した場合、基地局IDを取得してから所定の時間が経過したか否かを判定する(S102)。
情報取得部331は、所定の時間が経過していないと判定した場合、処理をS105に進める。一方、情報取得部331は、所定の時間が経過したと判定した場合、通信装置1から基地局IDを再び取得する(S103)。具体的には、情報取得部331は、まず、配信待ちDBに格納されているレコードのうち、取得日時から所定の時間が経過したレコードに対応する通信装置1に応答要求を送信する。そして、情報取得部331は、応答要求を受信した通信装置1から送信された応答情報に含まれる基地局IDを取得する。情報取得部331は、取得した通信装置ID、基地局ID、及び応答情報を取得した日時を決定部332に入力する。
決定部332は、情報取得部331から入力された通信装置ID、基地局ID、及び取得日時に基づいて、配信順序を再決定する(S104)。具体的には、決定部332は、第1基地局IDに基づいて決定した順序を、通信装置1が属する基地局2が、第1基地局IDとは異なる第2基地局IDに変わったことに応じて更新することにより、基地局2ごとに、通信装置1に更新用ソフトウェアを配信する順序を再決定する。
配信部333は、S101において情報取得部331が、装置種別が「固定」であると判定した場合、又はS102において情報取得部331が、所定の時間が経過していないと判定した場合に、閾値台数を超えない範囲において、配信待ちDBから更新用ソフトウェアを配信する対象となった通信装置1に対応するレコードを抽出し、配信状況DBに格納する(S105)。
[第2実施形態における効果]
以上説明した通り、第2実施形態に係る配信装置3は、通信装置1から基地局IDを取得した後に所定の時間が経過する前に更新用ソフトウェアの配信を開始することができない場合に、通信装置1から属する基地局IDを再び取得する。そして、配信装置3は、再び取得した基地局IDと先に取得した基地局IDとが異なる場合に、更新用ソフトウェアを配信する順序を再決定する。このようにすることで、配信装置3は、更新用ソフトウェアの配信を開始するまでに時間がかかった場合であっても、移動可能な通信装置1が属する基地局2が変わったことを配信順序に反映させることができる。その結果、配信装置3は、通信装置1が属していない基地局2に対して更新用ソフトウェアを配信する確率を下げることができる。
[変形例]
以上の説明においては、配信部333が、決定部332が決定した順序に基づいてソフトウェアを配信することが想定されていた。これに対して、配信部333は、複数の基地局2を含む所定のエリア内でソフトウェアを配信する対象となる通信装置1の台数が所定の台数以上であることを条件として、決定部332が決定した順序に基づいて、閾値台数以下の台数の通信装置1に対して複数の基地局2からソフトウェアを配信してもよい。
例えば、ソフトウェアを配信する必要があるエリアに存在する通信装置1の台数が、1台の基地局2が同時にソフトウェアを配信可能な通信装置1の数以下である場合に、配信部333は、決定部332が決定した順序によらず、ソフトウェアを配信する対象である全ての通信装置1にソフトウェアを配信する。一方、ソフトウェアを配信する必要があるエリアに存在する通信装置1の台数が、1台の基地局2が同時にソフトウェアを配信可能な通信装置1の数よりも多い場合に、配信部333は、決定部332が決定した順序に基づいて、順次ソフトウェアを配信する。このようにすることで、ソフトウェアを配信する対象となる通信装置1の数が少ないエリアの通信装置1にソフトウェアを配信する際の配信装置3の処理の負荷を軽減することができる。
なお、エリアの決定方法は任意であるが、例えば、全国に網羅的に通信装置1が存在する場合、通信装置1の台数に基づいてエリアを決定することが考えられる。1つの配信装置3が全国の通信装置1にソフトウェアを配信する場合、配信装置3の負荷が重くなり過ぎないように、決定部332は、ソフトウェアを配信するエリアの順序を決定し、配信部333は決定された順序に基づいて、ソフトウェアを配信してもよい。
また、特定エリア(例えば関東地方)に多数の通信装置1が集中している場合、基地局2のリソースがソフトウェアの配信のために占有されるおそれがある。そこで、配信装置3は、特定エリアにおいてソフトウェアを配信する対象とする通信装置1の台数を複数のグループに分割し、分割したグループごとに、順次ソフトウェアを配信してもよい。この場合、決定部332は、各グループ内の配信順序を決定する。このようにすることで、配信装置3及び基地局2の両方の負荷を軽減することができる。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されず、その要旨の範囲内で種々の変形及び変更が可能である。例えば、装置の分散・統合の具体的な実施の形態は、以上の実施の形態に限られず、その全部又は一部について、任意の単位で機能的又は物理的に分散・統合して構成することができる。また、複数の実施の形態の任意の組み合わせによって生じる新たな実施の形態も、本発明の実施の形態に含まれる。組み合わせによって生じる新たな実施の形態の効果は、もとの実施の形態の効果を合わせ持つ。