JP7394198B1 - 配信サーバ、配信サーバの制御方法、及び配信サーバの制御プログラム - Google Patents

Abstract

【課題】ＮＢ－ＩｏＴにおけるＦＯＴＡを効率的に行うこと
【解決手段】基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバは、通信装置から受信した、通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、通信装置が接続する基地局を識別するための第２識別情報を取得する取得部と、基地局ごとに、更新用ソフトウェアを配信する通信装置の上限台数を設定する設定部と、第１識別情報及び第２識別情報に基づいて、基地局ごとに、当該基地局ごとに設定された上限台数以下の通信装置に対して、基地局を介して更新用ソフトウェアを配信する配信部とを備える。
【選択図】図２

Description

本発明は、配信サーバ、配信サーバの制御方法、及び配信サーバの制御プログラム関する。

ＩｏＴ（Internet of Things）デバイス向けの通信規格として、ＩｏＴデバイスにＩＰ（Internet Protocol）アドレスを割り当てることなくデータ通信を行う、ＮＩＤＤ（Non-IP Data Delivery）が知られている。インターネットプロトコルを用いない非ＩＰ通信方式であるＮＩＤＤは、データ通信時のヘッダー情報等を削減でき、通信に必要な電力を抑えて、ＩｏＴデバイスのバッテリーを長持ちさせるという優れた利点を有する。

なお、従来、無線通信装置には、不具合の修正や機能の追加のために自装置のファームウェア（ソフトウェアプログラム）の更新を無線経由で行う、ＦＯＴＡ（Firmware Over The Air）と呼ばれる技術が知られている。ＮＩＤＤは、ＩｏＴデバイス向けの無線通信技術として標準化されたＬＰＷＡ（Low Power Wide Area）に分類される通信規格のうち、ＮＢ－ＩｏＴ（Narrow Band-IoT）に最適な通信方式であり、例えば特許文献１には、ＮＢ－ＩｏＴに準拠するＩｏＴデバイスに対してＦＯＴＡを行う技術が開示されている。

特開２０２０－１４１８３号公報

ＮＢ－ＩｏＴは、携帯電話や無線ＬＡＮの通信規格であるＬＴＥ（登録商標）（Long Term Evolution）やＷｉ－Ｆｉ（登録商標）と比較して、低消費電力で長距離通信が可能であるものの、通信帯域が狭く、通信速度が低いとの特徴がある。そのため、ファームウェアの更新用ソフトウェアのような、ＩｏＴデバイスが通常の動作で送受信するデータと比較して容量の大きいデータを、基地局のセル内に存在する大量のＩｏＴデバイスに対して配信すると、処理が遅延し、ファームウェアの更新に失敗する確率が高くなる。更新用ソフトウェアを配信するＩｏＴデバイスの数を制限する手法もとられるが、この場合、更新の成功率は高まるものの、大量のＩｏＴデバイスに対してファームウェアの更新を完了させるまでには、やはり時間がかかる。

ＮＢ－ＩｏＴにおけるＦＯＴＡを効率的に行うことが求められていた。

本発明の一実施形態に係る、基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバは、通信装置から受信した、通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、通信装置が接続する基地局を識別するための第２識別情報を取得する取得部と、基地局ごとに、更新用ソフトウェアを配信する通信装置の上限台数を設定する設定部と、第１識別情報及び第２識別情報に基づいて、基地局ごとに、当該基地局ごとに設定された上限台数以下の通信装置に対して、基地局を介して更新用ソフトウェアを配信する配信部と、を備える。

本発明の一実施形態に係る配信サーバにおいて、配信部は、通信装置へ更新用ソフトウェアを配信してから所定期間以内に、通信装置から、更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信しない場合、更新が失敗したと判定してよい。

本発明の一実施形態に係る配信サーバにおいて、配信部は、上限台数に基づいて、更新用ソフトウェアを未配信の通信装置に対して、逐次に更新用ソフトウェアを配信してよい。

本発明の一実施形態に係る配信サーバにおいて、配信部は、更新用ソフトウェアを配信した通信装置から、更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信したことに応じて、更新用ソフトウェアを未配信の通信装置であって、更新用ソフトウェアを配信中の通信装置が上限台数を超過しない台数の通信装置に対し、更新用ソフトウェアを配信してよい。

本発明の一実施形態に係る配信サーバにおいて、取得部は、通信装置から、当該通信装置と基地局との間の通信品質に関する通信品質情報をさらに取得し、設定部は、基地局に接続する複数の通信装置から取得した通信品質情報に基づき、基地局に対する上限台数を設定してよい。

本発明の一実施形態に係る配信サーバにおいて、取得部は、第２識別情報に基づいて、基地局の設置地域に関する地域情報をさらに取得し、配信部は、地域情報に基づいて、複数の基地局のうち、更新用ソフトウェアを配信する対象となる通信装置を選択してよい。

本発明の一実施形態に係る配信サーバにおいて、通信装置と基地局との間の通信は、ＮＢ－ＩｏＴ（Narrow Band Internet of Things）による通信方式に基づいてよい。

本発明の一実施形態に係る配信サーバにおいて、基地局を介した通信装置と配信サーバとの間の通信は、ＩＰ（Internet Protocol）を用いずにデータ通信を行う非ＩＰ通信方式であるＮＩＤＤ（Non-IP Data Deliver）による通信方式を含んでよい。

本発明の一実施形態に係る、基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバの制御方法は、配信サーバが、通信装置から受信した、通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、通信装置が接続する基地局を識別するための第２識別情報を取得するステップと、基地局ごとに、更新用ソフトウェアを配信する通信装置の上限台数を設定するステップと、第１識別情報及び第２識別情報に基づいて、基地局ごとに、当該基地局ごとに設定された上限台数以下の通信装置に対して、基地局を介して更新用ソフトウェアを配信するステップと、を含む。

本発明の一実施形態に係る、基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバの制御プログラムは、配信サーバに、通信装置から受信した、通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、通信装置が接続する基地局を識別するための第２識別情報を取得する機能と、基地局ごとに、更新用ソフトウェアを配信する通信装置の上限台数を設定する機能と、第１識別情報及び第２識別情報に基づいて、基地局ごとに、当該基地局ごとに設定された上限台数以下の通信装置に対して、基地局を介して更新用ソフトウェアを配信する機能と、を実現させる。

図１は、本発明の一実施形態に係る配信システムの構成を示す概略図である。 図２は、本発明の一実施形態に係る配信サーバおよび通信装置の概略構成図である。 図３は、本発明の一実施形態に係る通信装置及び配信サーバ間のシーケンス図の一例である。 図４は、本発明の一実施形態で用いられるデータセットの一例である。 図５は、本発明の一実施形態で用いられるデータセットの一例である。 図６は、本発明の一実施形態で用いられるデータセットの一例である。

以降、図を用いて、本開示に係る発明（本発明ともいう）の一実施形態を説明する。なお、図は一例であって、本発明は図に示すものに限定されない。例えば、図示した配信サーバ（情報処理装置）、管理サーバ、データベースサーバ、基地局、通信装置（ＩｏＴデバイス）の数、データセット（テーブル）、シーケンス図は一例であって、本発明はこれらに限定されるものではない。

＜システム構成＞
図１は、本発明の一実施形態に係る配信システムの構成例を示す図である。配信システム６００は、通信装置２００に対し、ファームウェアを更新するための更新用ソフトウェアを配信するシステムであってよい。

配信システム６００は、配信サーバ１００と、管理サーバ１０１と、データベースサーバ４００と、基地局３００（３００Ａ，３００Ｂ）と、複数の通信装置２００（２００Ａａ，２００Ａｂ，…，２００Ｂａ，２００Ｂｂ，…）と、移動通信ネットワーク５００とを含んでよい。ここで、移動通信ネットワーク５００は、基地局３００と通信装置２００とがデータをやり取りする無線アクセスネットワークと、コアネットワーク５０とを含んでよい。なお、図１において、それぞれ基地局３００Ａ，３００Ｂに接続する通信装置２００には、それぞれ同一の大文字の英字Ａ，Ｂを付与し、通信装置間を区別する場合、小文字の英字ａ，ｂ…を付与する。しかしながら、特に区別する必要がない場合、単に基地局３００、通信装置２００として説明する。

通信装置２００は、基地局３００に接続され、各基地局３００のセル内に存在（在圏）する各種ＩｏＴデバイスであってよい。なお、これ以降、通信装置２００を、ガス（都市ガス、ＬＰガス）、水道、電気等のスマートメータに設置され、メータの検針データ等を送信するＩｏＴデバイスとして説明する。しかしながら、本発明はこれに限定されず、通信装置２００としては、橋や道路等のインフラ監視に用いられるＩｏＴセンサや、ウェアラブルデバイスなどであってよい。

また、ここでは、通信装置２００を、ＮＩＤＤによるデータ通信が可能なＩｏＴデバイスとして説明する。すなわち、通信装置２００と基地局３００とは、ＮＢ－ＩｏＴに準拠した通信方式で通信を行ってよい。ＮＩＤＤは、上述のように、通信に必要な電力を抑えて、ＩｏＴデバイスのバッテリーを長持ちさせるとともに、ＩｏＴデバイスを狙った悪意のある攻撃を受けるリスクが低く、高セキュリティーなネットワークを構築することができる。また、ＮＢ－ＩｏＴは、狭帯域かつ低速のため消費電力が少なく電池による長時間駆動を可能にするほか、運用コストを抑えられるという利点がある。

なお、本発明はこれに限定されず、通信装置２００は、ＬＰＷＡに分類されるＩｏＴ向けの通信規格であって、例えば、カテゴリーＭ（Category M）、カテゴリーＭ１（Category M1）、ＬｏＲａＷＡＮ（登録商標）、Ｓｉｇｆｏｘ（登録商標）等に準拠するデバイスであってもよい。また、通信装置２００は、移動通信ネットワーク５００における通信ベアラを、複数の通信規格間で切り替え可能であってよい。例えば、通信装置２００は、通信ベアラ（通信経路）を、ＮＢ－ＩｏＴとCategory M1とで切り替え可能であってよい。

配信サーバ１００は、基地局３００に接続する各通信装置２００のファームウェアのバージョンを管理し、必要に応じて、各通信装置２００のファームウェアを更新するための更新用ソフトウェアを送信する機能（ＦＯＴＡを実行するための機能）を有してよい。なお、更新用ソフトウェアを提供する事業者と、配信する事業者とは異なっていてもよい。例えば、更新用ソフトウェアは、各通信装置２００の製造業者によって提供され、基地局３００を管理する通信事業者によって、配信サーバ１００を介して各通信装置２００へ配信されてもよい。

管理サーバ１０１は、各通信装置２００から送信された各スマートメータの検針値等を処理し、スマートメータの管理者へ必要なデータを受け渡す、ＩｏＴ－ＰＦ（プラットフォーム）として機能してよい。管理サーバ１０１は、移動通信ネットワーク５００を介して、通信装置２００を遠隔制御してもよく、管理サーバ１０１は、管理者が待機する図示しない集中監視センタに接続されてよい。なお、管理サーバ１０１と配信サーバ１００とは、同一のサーバとして設けられてもよいし、さらに複数のサーバにその機能が分散されてもよい。なお、管理サーバ１０１、配信サーバ１００は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよく、例えば、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレット等）、コミュニケーションプラットホーム等を含んでもよい。

コアネットワーク５０は、ＮＢ－ＩｏＴによる無線通信をサポートし、図示しないＭＭＥ（Mobility Management Entity：モビリティ管理エンティティ）、Ｓ－ＧＷ（Serving Gateway：サービング・ゲートウェイ）、Ｐ－ＧＷ（Packet Data Network Gateway：パケット・データ・ネットワーク・ゲートウェイ）、ＳＣＥＦ（Service Capability Exposure Function）等のノードを含んでよい。ＭＭＥは、通信装置２００の位置管理、認証管理や、各ノード間のセッションの管理（すなわち、通信ベアラの管理）等を行う機能を有する。また、ＭＭＥは、通信装置２００を呼び出す際に、基地局３００へページングを送信する機能も有する。Ｓ－ＧＷは、基地局３００とコアネットワーク５０との間で、ユーザパケットのルーティングや転送を行うゲートウェイとしての機能を有する。Ｐ－ＧＷは、コアネットワーク５０以降のＩＰ通信網で使用可能な通信装置２００のＩＰ（Internet Protocol）アドレスを割り当て、そのＩＰアドレスによって、通信装置２００と移動通信ネットワーク５００の外部ネットワークとの通信を可能とするゲートウェイとしての機能を有する。なお、Ｓ－ＧＷとＰ－ＧＷとは、統合して１つのノードとして実現される場合もある。

ＮＢ－ＩｏＴでは、ＬＴＥと同様に、コアネットワーク５０において、制御信号を伝送する機能を有する制御プレーン（ＣＰｌａｎｅ：Control Plane）と、通信装置２００との間で送受信されるデータ（ユーザデータ）を伝送する機能を有するユーザプレーン（ＵＰｌａｎｅ：User Plane）とが分離されたシステムとなっている。すなわち、ユーザデータは、通信装置２００、Ｓ－ＧＷ、Ｐ－ＧＷを経由するユーザプレーンを介して、転送されてよい。また、制御信号は、通信装置２００、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷ、配信サーバ１００を経由する制御プレーンを介して転送されてよい。なお、ＮＩＤＤによる通信方式の場合、通信装置２００から送信された各種データは、制御プレーンを介して、ＭＭＥ、ＳＣＥＦを経由して送受信されてよい。また、コアネットワーク５０は、さらに、図示しないＳＣＳ（Service Capability Server）を含んでもよい。

また、配信システム６００は、データベースサーバ４００をさらに備えてよい。詳細は後述するが、データベースサーバ４００には、各通信装置２００と基地局３００とを関連付けるための各種データが格納されてよい。なお、図１では、データベースサーバ４００を配信サーバ１００とは別個に示してあるが、本発明はこれに限定されず、データベースサーバ４００に格納されるデータは、例えば配信サーバ１００の記憶部１７０に記憶されてもよい。

＜通信装置＞
図２に、本発明の一実施形態による通信装置２００のブロック図の一例を示す。通信装置２００は、制御部２１０、通信部２２０、入出力部２３０、及び記憶部２７０を備えてよい。通信装置２００を構成する制御部２１０や通信部２２０は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信装置２００を構成する制御部２１０や通信部２２０は、回路もしくはチップ等のハードウェアであってもよい。

通信部２２０は、所定の通信方式で基地局３００との間で通信を行い、移動通信ネットワーク５００を介して、配信サーバ１００や管理サーバ１０１との間で各種データの送受信を行ってよい。所定の通信方式は、ＮＢ－ＩｏＴ、Category M, Category M1等であってよい。なお、本発明の一実施形態による通信装置２００は、ＮＩＤＤ通信方式によるデータの送受信が可能であって、ＮＩＤＤ通信方式によってデータの送受信を行うものとして説明する。

制御部２１０は、例えばＭＰＵ（Micro Processing Unit）等で構成され、記憶部２７０に記憶されているプログラムを実行することにより、通信装置２００をＮＢ－ＩｏＴやＮＩＤＤに準拠して動作させるための処理を実現してよい。また、制御部２１０は、自装置の再起動を実行したり、移動通信ネットワーク５００への接続や、移動通信ネットワーク５００との接続を解除するための各種処理を実行してよい。さらに、制御部２１０は、通信部２２０を介して、後述する自装置に固有の装置識別情報（第１識別情報：ＵＵＩＤ（Universally Unique Identifier）、ＩＭＳＩ（International Mobile Subscriber Identity）等）を送信したり、ＦＯＴＡの更新用ソフトウェアをダウンロードしたりしてよい。また、制御部２１０は、ダウンロードした更新用ソフトウェアを用いて、自装置のファームウェアの更新を実行してよい。

記憶部２７０は、通信装置２００が動作するうえで必要とする各種プログラムや各種データを記憶する。記憶部２７０は、例えば、半導体メモリ（磁気メモリ、フラッシュメモリ等）を含んでよい。また、記憶部２７０は、制御部２１０に対する作業領域を提供するメモリ（ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等）を含んでよい。また、記憶部２７０は、通信装置２００に固有の装置識別情報２７１を記憶してよい。

入出力部２３０は、センサ等の外部装置とのインタフェースであって、例えば、Ｕバスインタフェース、ＵＡＲＴ（Universal Asynchronous Receiver/Transmitter）インタフェース、ＳＰＩ（Serial Peripheral Interface）インタフェース、Ｉ２Ｃインタフェース等を含んでよい。通信装置２００は、入出力部２３０を介して接続されたセンサが検知したデータを、管理サーバ１０１等に送信してよい。

＜配信サーバ＞
次に、図２を用いて、本発明の一実施形態に係る配信サーバ１００のハードウェア構成、機能構成について説明する。

（１）配信サーバのハードウェア構成
配信サーバ１００は、制御部１１０、通信部１２０、入出力部１３０及び記憶部１７０を備えてよい。

記憶部１７０は、典型的には、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等各種の記録媒体により実現され、配信サーバ１００が動作するうえで必要とする各種プログラム及びデータを記憶する機能を有してよい。

制御部１１０は、典型的にはプロセッサであって、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）等によって実現されてよい。制御部１１０は、記憶部１７０に記憶されるプログラムを読み出し、読み出したプログラムに含まれるコード又は命令を実行することによって、各実施形態に示す機能、方法を実行してよい。制御部１１０は、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。

通信部１２０は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、外部装置と各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。例えば、配信サーバ１００と通信装置２００とは、ＯＭＡ（Open Mobile Alliance）によって策定されたＩｏＴ向けのプロトコルであるＬｗＭ２Ｍ（Lightweight M2M）、ＭＱＴＴ（Message Queue Telemetry Transport）、及びＣｏＡＰ（Constrained Application Protocol）等を用いて、データの送受信を行ってよい。通信部１２０は、配信サーバ１００と各通信装置２００の間で確立された通信ベアラを用いて、各種データの送受信を行ってよい。

入出力部１３０は、配信サーバ１００に対する各種操作を入力する入力装置、及び、配信サーバ１００で処理された処理結果を出力する出力装置を含んでよい。入力装置は、例えば、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）を含む。出力装置は、制御部１１０で処理された処理結果を出力し、例えば、タッチパネル、スピーカ等を含む。入力装置、出力装置は、図示しない集中監視センタに設置されて、監視者（管理者）からの操作を受け付けたり、監視者に対して各種情報を出力したりしてよい。

（２）配信サーバの機能構成
配信サーバ１００は、制御部１１０によって実現される機能として、取得部１１１、設定部１１２、配信部１１３、および生成部１１４を備えてよい。なお、図２に記載の各機能部のうち、これ以降に説明する各実施形態において、必須でない機能部はなくともよい。また、各機能部の機能又は処理は、実現可能な範囲において、機械学習又はＡＩにより実現されてもよい。

＜更新用ソフトウェアの配信処理＞
これ以降、配信サーバ１００の各機能部の説明とともに、本発明の一実施形態による更新用ソフトウェアの配信処理について、図３～６も用いて説明する。ここで、図３は、配信サーバ１００と通信装置２００との間のシーケンス図である。また、図４～６は、配信処理に用いられる各種データテーブルである。

取得部１１１は、通信装置２００から、当該通信装置を識別するための第１識別情報を取得してよい（図３のステップＴ１１）。通信装置を識別するための第１識別情報とは、例えば、ＩＭＳＩ、ＩＭＥＩ（International Mobile Equipment Identifier）、ＵＵＩＤ等であってよいが、これらに限定されない。なお、配信サーバ１００は、ＦＯＴＡを実行するにあたり、ステップＴ１１の前に、通信装置２００に対し第１識別情報の送信を要求してよい。

なお、通信装置２００は、ＬｗＭ２Ｍプロトコルを用いて、配信サーバ１００との間でデータの送受信を行ってよい。ＬｗＭ２Ｍでは、データの管理にリソースモデルという形式を用いているが、リソースモデルは、オブジェクト、オブジェクトインスタンス、リソースのツリー構造であり、各要素には番号が割り当てられる。本発明の一実施形態において、通信装置２００の第１識別情報（ＩＭＳＩ）は、デバイスオブジェクト「３」のリソース「１７」に格納されてよい。したがって、配信サーバ１００の生成部１１４は、第１識別情報の送信を要求する際に、リソース「／３／０／１７」を指定する命令を生成してよい。通信装置２００は、配信サーバ１００からリソース「／３／０／１７」を指定する要求を受信すると、当該リソースに格納されている情報（第１識別情報）を読み出し、配信サーバ１００へ送信してよい。

また、取得部１１１は、通信装置２００から取得した第１識別情報に基づいて、複数の基地局３００のうち、当該通信装置２００が接続する基地局を識別するための第２識別情報をさらに取得してよい（図３のステップＴ１２）。第２識別情報は、これに限定されるものではないが、例えば、セルを一意に識別するＥＣＧＩ（E-UTRAN (Evolved Universal Terrestrial Radio Access Network) Cell Global Identifier）であってよい。

なお、取得部１１１は、第２識別情報を、データベースサーバ４００から取得してよい。データベースサーバ４００は、各通信装置２００の接続先の基地局３００に関する情報を、あらかじめ記憶してよい。図４（ａ）は、データベースサーバ４００に記憶される、通信装置２００の接続先の基地局３００に関する基地局情報テーブルの一例である。基地局情報テーブルＴＢ１０には、通信装置２００の第１識別情報と、当該第１識別情報で識別される通信装置２００が接続する基地局３００の第２識別情報とが関連付けられて記憶されてよい。なお、図４（ａ）では、分かりやすさのため、第１識別情報を、図１における通信装置の符号（２００Ａａ，２００Ｂｄ等）で示し、第２識別情報を、基地局の符号（３００Ａ，３００Ｂ等）で示してある。配信サーバ１００の取得部１１１は、通信装置２００から第１識別情報を取得すると、データベースサーバ４００の基地局情報テーブルＴＢ１０を参照して、通信装置２００の接続先である基地局３００の第２識別情報を取得してよい。

設定部１１２は、基地局３００ごとに、更新用ソフトウェアを配信する通信装置２００の上限台数を設定してよい（図３のステップＴ１３）。ここで、上限台数とは、複数の通信装置２００のうち、通信により配信サーバ１００から更新用ソフトウェアを同時に配信できる通信装置２００の上限の台数を意味してよい。なお、上限台数の設定方法については後述する。あるいは、上限台数は、例えば通信事業者によってあらかじめ設定されていてもよい。基地局３００に設定された上限台数に関する情報は、データベースサーバ４００に記憶されてよい。図４（ｂ）は、基地局３００ごとの上限台数を記憶する上限台数テーブルの一例である。なお、上限台数テーブルＴＢ１１には、各基地局３００に接続している通信装置２００の情報（第１識別情報）がさらに記憶されてもよい。図４（ｂ）の上限台数テーブルＴＢ１１の例では、基地局３００Ａの上限台数は「６台」、基地局３００Ｂの上限台数は「５台」であってよい。

配信部１１３は、第１識別情報及び第２識別情報に基づいて、基地局３００ごとに、当該基地局３００に接続された複数の通信装置２００のうち、上限台数以下の通信装置２００に対して、基地局３００を介して更新用ソフトウェアを配信してよい。なお、更新用ソフトウェアの配信は、ＦＯＴＡを実行する旨を示すＦＯＴＡ指令が通信装置２００に送信されることによって行われてよい（図３のステップＴ１４）。生成部１１４は、更新用ソフトウェアのダウンロードにかかるリソースを生成してよい。ＦＯＴＡ指令には、更新用ソフトウェアのダウンロード先に関する情報（ＵＲＬ）が含まれてよく、通信装置２００は、ＦＯＴＡ指令に対して応答し（ステップＴ１５）、その後、ダウンロード先に接続して、更新用ソフトウェアのダウンロードを行ってよい（ステップＴ１６）。

ここで、図３のシーケンス図のように、通信装置２００Ａａへの更新用ソフトウェアの配信を考える。この場合、図４（ａ）の上限台数テーブルＴＢ１１を参照すると、基地局３００Ａに設定された上限台数は「６台」であるため、配信部１１３は、通信装置２００Ａａのほか、例えば通信装置２００Ａｂ～Ａｆの「６台」に対して、ＦＯＴＡ指令を送信してよい。なお、ＦＯＴＡ指令を送信する通信装置２００の順序については特に限定されず、例えば、配信サーバ１００が第１識別情報を受信した順でもよい。

このように、本発明の一実施形態によれば、更新用ソフトウェアを配信する通信装置２００の上限台数が設定され、上限台数以下の通信装置２００に対してのみ、更新用ソフトウェアが配信されてよい。したがって、ＮＩＤＤのように、ＮＢ－ＩｏＴの通信方式のうち通信速度が比較的に低い通信方式でも、容量の大きいソフトウェアのダウンロードの成功率を高めることが可能となる。

通信装置２００は、ダウンロードした更新用ソフトウェアを用いて、自装置のファームウェアを更新してよい（ステップＴ１７）。通信装置２００は、ファームウェアの更新が完了すると、ＦＯＴＡが完了した旨を示す通知を配信サーバ１００へ送信してよい（ステップＴ１８）。

なお、配信部１１３は、通信装置２００へ更新用ソフトウェアを配信してから所定期間以内に、通信装置２００から、更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信しない場合、更新が失敗したと判定してよい。所定期間は、例えば３０分間であってよいが、これに限定されない。配信部１１３は、更新に失敗したと判定された通信装置２００に関する情報を、記憶部１７０やデータベースサーバ４００に記憶させてよい。

このように、本発明の一実施形態によれば、ＦＯＴＡに失敗した通信装置２００が判定される。したがって、不必要に通信帯域を占有させることなく、効率的なＦＯＴＡを実行させることができる。

配信部１１３は、上限台数に基づいて、更新用ソフトウェアを未配信の通信装置２００に対して、逐次にＦＯＴＡ指令を送信してよい。すなわち、配信部１１３は、上限台数に基づいて、更新用ソフトウェアを未配信の通信装置２００に対して、逐次に更新用ソフトウェアを配信してよい。なお、「逐次に更新用ソフトウェアを配信」とは、ある通信装置への更新用ソフトウェアの配信が完了次第、順次、他の通信装置へ更新用ソフトウェアが配信されることを指してよい。例えば、配信部１１３は、更新用ソフトウェアを配信した通信装置２００から、更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信したことに応じて、更新用ソフトウェアを未配信の通信装置２００であって、更新用ソフトウェアを配信中の通信装置２００が上限台数を超過しない台数の通信装置２００に対し、更新用ソフトウェアを配信してよい（図３のステップＴ１９）。具体的には、例えば、配信部１１３は、通信装置２００Ａａ～Ａｆに対してＦＯＴＡ指令を送信し、そのうち通信装置２００ＡａからＦＯＴＡ完了通知を受信し、更新用ソフトウェアをダウンロードする通信装置が通信装置２００Ａｂ～Ａｆの「５台」となった場合、上限台数「６台」を超えないよう、ＦＯＴＡ指令を未送信の通信装置の「１台」（例えば通信装置２００Ａｇ）に対して、ＦＯＴＡ指令を送信してよい（ステップＴ１９）。すなわち、配信部１１３は、ＦＯＴＡ指令を未送信の通信装置が上限台数以上存在する場合は、更新用ソフトウェアをダウンロードする通信装置２００の台数と上限台数とが、同じ数となるように維持させてよい。

このように、本発明の一実施形態によれば、更新用ソフトウェアをダウンロードする通信装置２００の数が、上限台数と同じ数で維持されるようにＦＯＴＡ指令が送信されてよい。したがって、通信帯域を無駄にすることなく、効率的なＦＯＴＡを実行させることができる。

＜上限台数の設定＞
ここで、上限台数の設定について説明する。取得部１１１は、通信装置２００から、当該通信装置２００と基地局３００との間の通信品質に関する通信品質情報をさらに取得してよい。通信品質情報は、例えば、ＲＳＲＰ（Reference Signal Received Power）、ＲＳＲＱ（Reference Signal Received Quality）、ＲＳＳＩ（Received Signal Strength Indicator）、ＳＩＮＲ（Signal to Interference plus Noise Ratio）等であってよいが、これらに限定されない。なお、通信装置２００の制御部２１０は、通信部２２０が受信した電波の受信強度といった無線通信の状態に基づいて、通信品質情報を測定してよい。また、本発明の一実施形態において、通信装置２００の通信品質情報は、ＬｗＭ２Ｍのデータフレームにおいて、BinaryAppDataContainerオブジェクト「１９」のリソース「０」に格納されてよい。したがって、配信サーバ１００は、通信装置２００に通信品質情報の送信を要求する際に、リソース「／１９／０／０」を指定してよい。通信装置２００は、配信サーバ１００からリソース「／１９／０／０」を指定する要求を受信すると、当該リソースに格納されている情報（通信品質情報）を読み出し、配信サーバ１００へ送信してよい。

なお、各通信装置２００の通信品質情報は、データベースサーバ４００に記憶されてよい。図５（ａ）は、通信装置２００ごとの通信品質情報を記憶する通信品質情報テーブルの一例である。なお、通信品質情報テーブルＴＢ２０には、各通信装置２００が接続している基地局３００の情報（第２識別情報）がさらに記憶されてもよい。図５（ｂ）の通信品質情報テーブルＴＢ２０の例では、通信品質として、ＲＳＳＩを示してある。

設定部１１２は、基地局３００に接続する複数の通信装置２００から取得した通信品質情報に基づき、基地局３００ごとに、基地局３００に対する上限台数を設定してよい。基地局３００に設定された上限台数に関する情報は、データベースサーバ４００に記憶されてよい。図５（ｂ）は、通信品質情報に基づく、基地局３００ごとの上限台数を記憶する上限台数テーブルの一例である。図５（ｂ）の上限台数テーブルＴＢ２１の例では、基地局３００Ａの平均ＲＳＳＩは「－５０ｄＢｍ」であって、上限台数は「４台」であってよい。また、基地局３００Ｂの平均ＲＳＳＩは「－３０ｄＢｍ」であって、上限台数は「８台」であってよい。なお、上限台数は、例えば、平均ＲＳＳＩが－４９～－３０ｄＢｍであれば「８台」など、上限台数ごとに通信品質の範囲をあらかじめ設定しておき、基地局３００の通信品質の実測値に応じて、上限台数が設定されてよい。

このように、本発明の一実施形態によれば、基地局３００と通信装置２００との間の通信品質に応じて、上限台数が設定されてよい。したがって、電波環境のよいセルにおいてはより多くの通信装置２００に対して更新用ファームウェアが配信され、電波環境の悪いセルにおいては、より少ない通信装置２００に対して更新用ファームウェアが配信される。これにより、電波環境に応じた効率のよいＦＯＴＡの実行が可能となる。

また、取得部１１１は、基地局３００の第２識別情報に基づいて、基地局３００の設置地域に関する地域情報をさらに取得してよい。本発明の一実施形態において、データベースサーバ４００には、基地局３００の設置地域に関する地域情報を記憶した地域情報テーブルＴＢ３０が格納されてよい。図６は、地域情報テーブルＴＢ３０の一例である。地域情報テーブルＴＢ３０は、基地局３００が設置されている地域が、基地局３００の第２識別情報に関連付けて記憶してよい。図６の例では、基地局３００Ａは、「東京都」に設置され、基地局３００Ｂは、「神奈川県」に設置されていることがわかる。

配信部１１３は、地域情報テーブルＴＢ３０を参照し、地域情報に基づいて、複数の基地局３００のうち、更新用ソフトウェアを配信する対象となる通信装置２００を選択してよい。例えば、通信装置２００の製造業者から、所定の地域（例えば、神奈川県）に設置した通信装置２００に対して、優先的にＦＯＴＡを実行したい要求があった場合を考える。この場合、まず、配信部１１３は、地域情報テーブルＴＢ３０を参照し、神奈川県に設置された基地局３００Ｂを特定してよい。さらに、基地局情報テーブルＴＢ１０を参照し、基地局３００Ｂに接続された通信装置２００を特定してよい。そして、配信部１１３は、基地局３００Ｂに接続された通信装置２００に対し、上限台数以下で、更新用ソフトウェアを配信してよい。なお、複数の地域から要求があった場合、配信部１１３は、要求のあった複数の地域で無作為に配信順序を決定し、更新用ソフトウェアを配信してよい。

このように、本発明の一実施形態によれば、基地局３００の設置地域に応じて、優先的にＦＯＴＡを実行することが可能となる。したがって、通信装置２００の製造業者の要求に応じて、また、地域を限定した実証実験等に合わせて、通信装置２００のファームウェアを更新することができ、ユーザビリティの高いＦＯＴＡを実行することができる。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、上記実施の形態に示す構成を適宜組み合わせることとしてもよい。例えば、配信サーバ１００が備えるとして説明した各構成部は、複数のサーバによって分散されて実現されてもよい。また、配信サーバ１００の機能として説明した処理は、通信装置２００によって行われても良い。逆に、通信装置２００によって行われるとした処理が、サーバ１００によって行われてもよい。

例えば、上述では、各データテーブルがデータベースサーバ４００に記憶される態様について説明したが、それら各種情報は、配信サーバ１００や管理サーバ１０１の記憶部に記憶されてもよい。

サーバ１００又は通信装置２００の各機能部は、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。また、各機能部は、１又は複数の集積回路により実現されてよく、複数の機能部の機能を１つの集積回路により実現されることとしてもよい。

本開示の各実施形態のプログラムは、情報処理装置に読み取り可能な記憶媒体に記憶された状態で提供されてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、例えば、ソフトウェアプログラムや情報処理装置プログラムを含む。情報処理装置としての配信サーバ１００の各機能部をソフトウェアにより実現する場合、配信サーバ１００は、プロセッサがメモリ上にロードされたプログラムを実行することにより、取得部１１１、設定部１１２、配信部１１３、および生成部１１４として機能する。

記憶媒体は適切な場合、１つ又は複数の半導体ベースの、又は他の集積回路（ＩＣ）（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向けＩＣ（ＡＳＩＣ）等）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カードもしくはドライブ、任意の他の適切な記憶媒体、又はこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、又は揮発性と不揮発性の組合せでよい。

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、配信サーバ１００に提供されてもよい。

また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。なお、本開示のプログラムは、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎ等のスクリプト言語、Ｃ言語、Ｇｏ言語、Ｓｗｉｆｔ，Ｋｏｌｔｉｎ、Ｊａｖａ（登録商標）等を用いて実装されてよい。

以上説明した本開示の各態様によれば、５Ｇ以降のネットワーク技術に向けたＩｏＴデバイスの監視や保守に係る技術を提供することにより、持続可能な開発目標（ＳＤＧs）の目標９「産業と技術革新の基盤をつくろう」の達成に貢献できる。

１００ 配信サーバ（情報処理装置）
１１０ 制御部
１１１ 取得部
１１２ 設定部
１１３ 配信部
１１４ 生成部
１２０ 通信部
１３０ 入出力部
１７０ 記憶部
１０１ 管理サーバ
１０２ データベースサーバ
２００ 通信装置（ＩｏＴデバイス）
２１０ 制御部
２２０ 通信部
２３０ 入出力部
２７０ 記憶部
３００ 基地局
５００ 移動通信ネットワーク
５０ コアネットワーク
６００ 配信システム

Claims (9)

1. 基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバであって、
   通信装置から受信した、前記通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、前記通信装置が接続する基地局を識別するための第２識別情報を取得する取得部と、
   前記基地局ごとに、前記更新用ソフトウェアを配信する前記通信装置の上限台数を設定する設定部と、
   前記第１識別情報及び前記第２識別情報に基づいて、前記基地局ごとに、当該基地局に接続された前記上限台数以下の前記通信装置に対して、前記基地局を介して前記更新用ソフトウェアを配信する配信部と、を備え、
   前記取得部は、前記通信装置から、当該通信装置によって測定された、前記通信装置と前記基地局との間の通信品質に関する通信品質情報をさらに取得し、
   前記設定部は、前記基地局に接続する複数の前記通信装置から取得した実測値の前記通信品質情報に基づき、前記基地局に対する前記上限台数を設定する配信サーバ。
2. 前記配信部は、前記通信装置へ前記更新用ソフトウェアを配信してから所定期間以内に、前記通信装置から、前記更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信しない場合、前記更新が失敗したと判定する、請求項１に記載の配信サーバ。
3. 前記配信部は、前記上限台数に基づいて、前記更新用ソフトウェアを未配信の通信装置に対して、逐次に前記更新用ソフトウェアを配信する、
   請求項１または２に記載の配信サーバ。
4. 前記配信部は、前記更新用ソフトウェアを配信した前記通信装置から、前記更新用ソフトウェアによる更新が完了した旨を示す完了報告を受信したことに応じて、前記更新用ソフトウェアを未配信の通信装置であって、前記更新用ソフトウェアを配信中の通信装置が前記上限台数を超過しない台数の通信装置に対し、前記更新用ソフトウェアを配信する、請求項１または２に記載の配信サーバ。
5. 前記取得部は、前記第２識別情報に基づいて、前記基地局の設置地域に関する地域情報をさらに取得し、
   前記配信部は、前記地域情報に基づいて、前記複数の基地局のうち、前記更新用ソフトウェアを配信する対象となる通信装置を選択する、請求項１に記載の配信サーバ。
6. 前記通信装置と前記基地局との間の通信は、ＮＢ－ＩｏＴ（Narrow Band Internet of Things）による通信方式に基づく、請求項１に記載の配信サーバ。
7. 前記基地局を介した前記通信装置と前記配信サーバとの間の通信は、ＩＰ（Internet Protocol）を用いずにデータ通信を行う非ＩＰ通信方式であるＮＩＤＤ（Non-IP Data Deliver）による通信方式を含む、請求項６に記載の配信サーバ。
8. 基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバの制御方法であって、
   配信サーバが、
   通信装置から受信した、前記通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、前記通信装置が接続する基地局を識別するための第２識別情報を取得するステップと、
   前記基地局ごとに、前記更新用ソフトウェアを配信する前記通信装置の上限台数を設定するステップと、
   前記第１識別情報及び前記第２識別情報に基づいて、前記基地局ごとに、当該基地局ごとに設定された前記上限台数以下の前記通信装置に対して、前記基地局を介して前記更新用ソフトウェアを配信するステップと、を含み、
   前記取得するステップは、前記通信装置から、当該通信装置によって測定された、前記通信装置と前記基地局との間の通信品質に関する通信品質情報をさらに取得し、
   前記設定するステップは、前記基地局に接続する複数の前記通信装置から取得した実測値の前記通信品質情報に基づき、前記基地局に対する前記上限台数を設定する、配信サーバの制御方法。
9. 基地局に接続する通信装置に更新用ソフトウェアを配信する配信サーバの制御プログラムであって、
   配信サーバに、
   通信装置から受信した、前記通信装置を識別するための第１識別情報に基づいて、複数の基地局のうち、前記通信装置が接続する基地局を識別するための第２識別情報を取得する機能と、
   前記基地局ごとに、前記更新用ソフトウェアを配信する前記通信装置の上限台数を設定する機能と、
   前記第１識別情報及び前記第２識別情報に基づいて、前記基地局ごとに、当該基地局ごとに設定された前記上限台数以下の前記通信装置に対して、前記基地局を介して前記更新用ソフトウェアを配信する機能と、を実現させ、
   前記取得する機能は、前記通信装置から、当該通信装置によって測定された、前記通信装置と前記基地局との間の通信品質に関する通信品質情報をさらに取得し、
   前記設定する機能は、前記基地局に接続する複数の前記通信装置から取得した実測値の前記通信品質情報に基づき、前記基地局に対する前記上限台数を設定する、配信サーバの制御プログラム。

Images