リリース：	1.0.0
文書バージョン：	1.0
最終更新日：	2023年9月19日
著者：	マーティン・ウーリーBluetooth SIG ハンヌ・マラット、シリコン研究所オムカー・クルカルニ、ノルディック・セミコンダクター

改訂履歴

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor	Initial version

注

Bluetooth Mesh プロファイル仕様は名称が変更され、現在は次のように呼ばれている。Bluetooth Mesh プロトコル仕様と呼ばれるようになった。本書と関連論文でバージョン1.1仕様を参照する場合はこの名称を使用するが，バージョン1.0仕様を参照する場合は引き続きBluetooth Mesh プロファイル仕様書仕様と呼ぶことにする。

1.背景

Bluetooth^® Mesh 1.1 は、デバイス上で実行されているファームウェアをネットワーク上で更新することを可能にする、一連の新しい機能を導入した。この機能の機能、利点、技術的なハイライトをレビューする前に、関連する背景を示します。

1.1 ファームウェアとBluetooth Mesh デバイス

デバイスのハードウェアを制御する低レベルのソフトウェアは、通常次のように呼ばれる。 ファームウェアBluetooth Mesh デバイスは、Bluetooth Mesh プロトコルと、Bluetooth LEホストとコントローラの基礎となるレイヤーを実装するファームウェアを実行する。ファームウェアのmesh モデルファームウェアは、Bluetooth LE ホストとコントローラのプロトコルと基本レイヤーを実装している。デバイス上のファームウェアは、デバイスをそれらしくする上で、重要な役割を果たす。

1.2 ファームウェアを最新に保つ

ファームウェアは常に最新の状態に保つ必要があり、メーカーはしばしばファームウェア・アップデートをリリースする。新しいファームウェアは、問題の修正、新機能の追加、セキュリティの向上、パフォーマンスの向上、あるいはその他のメリットを提供するかもしれません。ソフトウェアがデバイスのファームウェアであれ、アプリケーション・ソフトウェアであれ、あるいはオペレーティング・システムのアップデートであれ、ソフトウェアを常に最新の状態に保つことは、一般的にグッドプラクティスとして認められています。

ソフトウェアのアップデート方法は、ソフトウェアの種類やプラットフォームによって異なります。最近のスマートフォンやデスクトップOSでは、ユーザーの関与をほとんど必要としない自動ソフトウェアアップデートが主流となっている。.

Bluetooth^® Mesh 1.0 は、新しいファームウェアがデバイスで利用可能であることを検知し、それを取得し、インストールするための、自動化された、あるいは標準化されたメカニズムを提供しない。これらのタスクは、手動で実行され、ファームウェア・アップデートのインストールは、この目的のために提供される、いかなる独自のインタフェースを使用しても、デバイスに直接行われなければならない。複数のベンダーのデバイスで構成されるmesh ネットワークでは、そのプロセスは、複数の専売ツールを含み、非常に複雑になる可能性がある。

1.3 バイナリ画像

ファームウェアのアップデートは通常、イメージファイルとして知られる単一のバイナリファイルに収められます。 イメージ.イメージ・ファイルの形式は様々で、ターゲット・プラットフォームとその製造元に依存します。ファームウェアの解凍、検証、インストールには、メーカー独自の手順が必要です。

1.4 ファームウェアの更新とセキュリティ

新しいファームウェアのインストールには、セキュリティ上のリスクが伴う。インストールされるソフトウェアが、謳い文句どおり製造元から提供されたものであることを、どうやって確認するのか？それが改ざんされておらず、おそらく悪意のあるコードが組み込まれていないことを、どうやって確認するのか？

このような事柄は、Bluetooth^{® の}仕様から外れる。しかし一般的には、ファームウェア・イメージが改ざんされていないことを保証するために、オリジネーターによってデジタル署名されたファイルのみを使用することが推奨されます。デジタル署名は、ファイルが検知されずに改ざんされるのを防ぎ、ファイルのオリジネーターを検証します。同様に、ファームウェア・アップデートがダウンロードされる可能性のあるサーバーを 信頼できるソース通常、デジタル証明書の使用によって達成される。

1.5 モデル

モデルは、アプリケーション・レイヤーBluetooth^® Mesh デバイス動作のビルディング・ブロックである。モデルとは、特定のビヘイビアセットを実装し、定義されたメッセージとステートのセットに関連付けられているソフトウェア・コンポーネントのことです。メッセージの送受信のみを行うクライアント・モデルと、メッセージの送受信と、モデルのメッセージによって動作する状態値を含むサーバー・モデルがあります。

2.機器ファームウェアのアップデートについて

2.1 能力とメリット

2.1.1 デバイス・ファームウェアのアップデート

Bluetooth^® Mesh の新しいデバイス・ファームウェア・アップデート（DFU）機能は、ネットワーク内のノードがファームウェアを最新に保つための標準的な方法を追加します。その機能には、新しいファームウェア・アップデートが利用可能かどうかの監視、バイナリ・イメージの取得、ネットワーク内での配布、および選択されたノードのアップデートが含まれます。

一般的なネットワークには、通常、同じメーカーの同じタイプの製品が多数含まれています。DFU機能は マルチキャストこれは、Bluetooth Mesh で使われているブロードキャスト通信を活用したファームウェア配布機能で、最小限の無線通信回数で、単一のファームウェア・アップデート・イメージを複数のデバイスに一度に配布することができます。

DFUは、ネットワークのデバイスで実行されているファームウェアを最新の状態に保つために、ビルの保守チームが必要とする手作業を大幅に削減します。

2.1.2 プラグ＆プレイ

DFU機能は、それぞれが独自のファームウェアを持つ多くのサブシステムで構成されるデバイスのアップデートを可能にします。そのようなファームウェア・インスタンスはそれぞれ、デバイスのファームウェア情報リストにリストされています。

ファームウェア情報リストは動的です。つまり、プラグアンドプレイ・コンポーネントが追加または削除されると、サブシステムの変更がデバイスのファームウェア情報リストに反映されます。

新しいプラグアンドプレイ機能に関連して、Bluetooth Mesh プロトコル仕様1.1では、デバイスのライフサイクルとその構造と構成に新しい正式名称が導入されている。これは用語の概念は、仕様の中で次のように説明されている：

A 期間とは、ノードの構造（フィーチャー、エレメント、モデル）およびノードのエレメントのユニキャストアドレスが変更されない、ノードのライフタイム内の期間である。

新しいタームの開始は、補助センサの取り付けなど、物理デバイスのハードウェア構成の変更をサポートするため、または照明器具内ネットワークなど、ノード上のサブシステム構成の変更をサポートするために必要な場合がある。この変更は、ノードによって構成データページ 128 に入力されることによって示され、新しい期間が開始するときに有効になります。

最初の期間ネットワーク上のノードの初期期間は、そのノードがネットワーク上にプロビジョニングされた時点から始まります。

A 期間が終了し、新しい タームが開始する。ノードアドレス更新プロシージャまたはノード構成更新プロシージャが実行されると、期間が終了し、新しい期間が開始する。

前期項ネットワーク上のノードの最後の項は、そのノードがネットワークから取り除かれた時点で終了する。

2.2 テクニカル・ハイライト

2.2.1 DFUの役割

DFUシステムはいくつかのノードの役割を定義している。その役割とは

Role	Description
Initiator	The Initiator identifies available firmware updates for a given list of nodes in the network. It executes procedures defined in the DFU specification under the control of an application. The Initiator typically runs on a device which supports both Bluetooth^® Mesh and has internet connectivity, such as a smartphone or gateway device, and periodically checks manufacturers’ websites for new firmware releases. Having identified relevant updates, it acquires them and sends the new firmware images to a Distributor node.
Distributor	The Distributor receives new firmware images from an Initiator and is responsible for sending them to appropriate nodes in the network for installation. The Distributor is typically a physically separate device to the Initiator so that the Initiator (which will often be a smartphone application) does not need to be in range of the network during the entire process. The Distributor can be thought of as acting an intermediary for the Initiator.
Target	Target is the name given to a node which can receive a firmware image from a Distributor and install it.
Stand-alone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Target nodes without the need for an intermediate Distributor.

2.2.2 モデル

DFU機能は、多くの新しいmesh モデルと、それらに関連する一連の手続きに基づいている。

輸送 トランスポートモデルは、ノード間でバイナリラージオブジェクト（BLOB）を転送するための一般化されたメカニズムを提供する。
ファームウェア ファームウェア配布モデルは、ファームウェア・アップデートをターゲット・ノードに配布する手順をサポートしています。

ファームウェア ファームウェア・アップデートモデルは、デバイスのファームウェアを更新する手順をサポートしています。

各モデルは、利用可能なファームウェア・アップデートが特定され、入手され、関連するノードに配布され、検証され、インストールされることを可能にする一連の手順に関与する。

2.2.3 役割とモデル

以下の表はDFUの仕様書から抜粋したもので、DFUの役割と新モデルの関係を示している。

役割	ファームウェア配布クライアント	ファームウェア配布サーバー	ファームウェアアップデートクライアント	ファームウェア・アップデート・サーバー	BLOB転送クライアント	BLOB転送サーバー
ターゲット	-	-	-	M	-	M
イニシエーター	M	-	M	-	M	-
ディストリビューター	-	M	M	-	M	M
スタンドアロン・アップデータ	-	-	M	-	M	-

M：この役割によるこのモデルのサポートは必須だ。

mesh ノードは、それぞれの役割に関連するモデルをインスタンス化することで、複数の役割をサポートすることができる。

2.2.4 ファームウェア更新手順の概要

ファームウェア・アップデートの取得、配布、インストールを行う方法には、多くのバリエーションがある。たとえば

ファームウェアは、ディストリビューターがベンダーのウェブサイトから標準の ファームウェア・チェック・オーバー HTTPS 手順で、または実装固有の手順で、ベンダー・ウェブサイトからファームウェアを入手することができます。
Initiator ノードは、ファームウェアイメージを取得し、更新ノードに配布するために Distributor に送信してもよいし、Distributor がファームウェアイメージを取得するための情報を送信してもよい。

Initiator ノード、Distributor ノード、および 1 つ以上の Target ノードが、ファームウェアのアップデートを取得、配布、およびインストールするために、どのように協働するかの代表的な例を図 1 に示す。に示す。

2.2.4.1 ファームウェアアップデートの検索と配布

図1 - ファームウェア・アップデートの取得と配布

図 1 は、ベンダーの Web サイトからファームウェア・アップデートを取得し、アップデート・ノード・セットに配布してインストールする、一連の手順を示している。様々な DFU の役割を果たすノード間の相互作用が示され、適切な場合には、関係する特定のモデルが示されている。

要約すると、次のようになる：

Initiator は、上位レイヤのアプリケーションによって指定されたノードのリスト上で現在実行されているファームウェアに関する情報を取得する。
Initiator は、このファームウェアに関連するアップデートがないか、この場合、ベンダーの Web サイトに送信される HTTPS リクエストを使用してチェックする。利用可能なアップデートがあれば、それがダウンロードされる。そうでない場合、プロセスはこの時点で終了する。
Initiator は、次に、更新ノードのリストの詳細を、以下のディストリビューション受信者リストに追加する。 ディストリビューション・レシーバ・リストの状態を追加する。簡略化のため、リスト内の各ノードは、同じファームウェアイメージを受け入れることができる必要があることに注意。
Initiator は ファームウェアのアップロードと BLOB の転送プロシージャを使用して、ファームウェアイメージをディストリビュータに転送します。
その後、イニシエータはディストリビューターに対し、ディストリビューションの開始を指示する。
ディストリビューターのファームウェア・アップデート・クライアントは、ファームウェア・アップデート手順が開始されることを、各アップデート・ノードの対応するサーバー・モデルに通知し、応答としてステータス・メッセージを受信することを期待する。
7.ディストリビュータは、BLOB 転送手順を使用して、ファームウェアイメージを各アップデート n に転送する。

2.2.4.2 配信の進行状況を確認する

更新ノードへのファームウェアの配布が行われている間、「Initiator」は「Distributor」に進捗状況を問い合わせることができる。

図 2- ディストリビューターの進捗を確認するイニシエータ

2.2.4.3 ファームウェアの確認とインストール

完全なバイナリイメージを受信すると、更新ノードは、例えば BLOB 上のデジタル署名をチェックするなど、実装固有の検証チェックを実行する。ディストリビューターは、アップデーティング・ノードにおけるプロシーディングのステータスを監視し、適切な場合、アップデーティング・ノードに対してファームウェア・アップデートをインストールするよう指示する。

図 3- ファームウェア・イメージのアップデートと検証、そして指示があればそれをインストールするノード

2.2.5 ファイル形式

定義された ファームウェア・アップデート・ファイルは、Bluetooth Mesh プロトコル仕様で定義されているアーカイブファイル形式を使用する。このフォーマットには、ファイルの内容を記述するマニフェスト・ファイル、バイナリー・ファームウェア・イメージ・ファイルそのもの、およびファームウェア・イメージに関する追加情報を含むオプションのメタデータ・ファイルが含まれる。マニフェスト・ファイルとメタデータ・ファイルは、定義された JSON フォーマットを使用します。

2.2.6 ファームウェアサブシステム

ノードは、そのファームウェアをいくつかの部分に分割することができる。それぞれの独立した部分は、ファームウェア・サブシステムと呼ばれる。例えば、ノードのmesh ネットワーキング・スタックは、独立したファームウェア・サブシステムであるかもしれない。

2.2.7 URIの更新

ファームウェア・アップデート・サーバー・モデルは、ファームウェア情報リスト状態と呼ばれる状態を含む。これは、Update URI と関連する Firmware ID から構成される。ファームウェア ID は、ノード上のファームウェア・サブシステムを識別し、Update URI 状態の値は、このファームウェアのアップデートの場所を示す。mesh DFU 仕様は、この情報をどのように使用し、ダウンロード URI を構築するかを示している。 ファームウェア・チェック・オーバー HTTPプロシージャで使用するためのダウンロード URI を構築するために、この情報がどのように使用されるかを示している：

https://mesh.example.com/check-for-updates/check?cfwid=02FF10000203

2.2.8 輸送コンセプト

BLOB 転送モデルは、あらゆるタイプのバイナリ・ラージ・オブジェクトの転送を可能にするように設計されている。Bluetooth^® Mesh プロトコル仕様のバージョン 1.1 では、BLOB 転送モデルは、ファームウェア・イメージをアップデート・ノードに配布する際にのみ使用される。BLOB Transfer モデルの一般化された機能を理解することは、デバイスのファームウェア・アップデート機能を理解する上で重要である。

図4：BLOB転送モデル。画像をブロックに分割し、ブロックをチャンクに分割する様子を示す。

2.2.8.1 blob id

すべてのBLOBには、BLOB転送手続き中に使用する一意の8オクテットの識別子が割り当てられている。

2.2.8.2 ブロックとチャンク

BLOBは一連の ブロックに分割される。ブロックのサイズは、クライアントが問い合わせる宛先BLOB転送サーバーの能力を参照して決定される。

ブロックは チャンクブロックは同じ大きさのチャンクに分割される（最後のチャンクは別で、ブロックサイズがチャンクサイズの正確な倍数でない場合、他のチャンクより小さくなることがある）。

各BLOB転送サーバーは、扱える最大のチャンクサイズを含む多くのパラメータを計算する。最大チャンクサイズの計算には、クライアントとサーバーの最大送信単位（MTU）が関係する。転送が初期化されるとき、クライアントはこの転送で使用されるチャンクサイズを計算し、すべてのレシーバーが対応できるようにする。

各チャンクには16ビットの チャンク番号が割り当てられる。

2.2.8.3 転送モード

つのBLOB転送モードが定義されている。

プッシュBLOB転送モード プッシュBLOB転送モードでは、クライアントがフローを制御する。一度に一つのブロックが、一連のチャンクとしてユニキャストアドレスかマルチキャストアドレスに転送される。その後、クライアントはサーバーに問い合わせて、どのチャンクを受信したかを判断し、欠落しているチャンクは再送される。

このモードでは プルBLOB転送モードでは、サーバーがフローを制御する。このモードは主に低電力ノード用に設計されており、クライアントから一度に1つのサーバーにのみBLOBを転送するために使用されます。

2.2.8.4 転送ステータスの追跡

Bluetooth^® Mesh ネットワークの性質は、マルチパス、マルチホップのメッセージングと、信頼性を高めるための再送信システムにより、メッセージの配信順序はいかなる方法でも保証できないことを意味する。そのため、BLOBが分割されたブロックのチャンクを伝達するBLOB転送メッセージも、特定の順序で到着することは保証できません。そのため、BLOB転送クライアントは、ブロックをどのような順番で選択してもよく、ブロックを選択した後、そのチャンクをどのような順番で送信してもよい。

BLOB転送サーバーモデルに属するMissing Chunksと呼ばれるステートは、アクティブブロック内の各チャンクのステータスを追跡できる手段を提供する。ステート値の各ビット位置は、そのチャンク番号に対応するチャンクのステータスを示す。つまり、例えばビット位置7は、現在のブロックのチャンク番号7のステータスを示す。値1はそのチャンクが受信されていないことを意味し、値0は受信されていることを意味する。

BLOB転送クライアントは、転送先のサーバーからMissing Chunksステートの値を取得し、受信されなかったチャンクのうち、まだ送信する必要があるチャンクや再送信する必要があるチャンクを特定するために使用する。

2.2.9 セキュリティ

ソフトウェアを最新の状態に維持することは、あらゆる種類のコンピューティング・デバイスを安全に保つ上で、一般的に受け入れられているベスト・プラクティスである。しかし、ソフトウェアの入手やインストールには、それなりのセキュリティ・リスクが伴います。重要なのは、信頼できるソースからソフトウェアを入手していること、ダウンロードしたコードが何らかの形で改ざんされていないこと、ダウンロード中に改ざんできないことを確認することです。HTTPS を使用することで、パッシブ・スヌーパーが、あなたが現在ネットワークで実行しているファームウェアのバージョンや、どのバージョンにアップデートしているかを発見することを防ぐことができることにも注意されたい。攻撃者が、特定のファームウェア・バージョンにおける特定の脆弱性を知っている場合、これは貴重な情報となりうる。

DFU仕様では、この2つの問題にどう対処するかを実装者が決める必要がある。

その ファームウェアの更新チェックプロシージャは、実装者に、指定された ファームウェア・チェック・オーバー HTTPS と HTTPS によるファームウェア取得プロシージャを使用するか、実装固有のプロシージャを使用するかを選択できます。

HTTPS でのファームウェアチェック ファームウェアチェックおよび/または HTTPS によるファームウェア取得手順では、安全な HTTPS プロトコルのみが使用できます。HTTPS プロトコルは、飛行中のデータが暗号化されることを保証し、HTTP クライアントがサーバーの主張する身元を認証できるように、サーバーにデジタル証明書を要求します。データは暗号化され、2つのエンドポイント間で送信されるデータを改ざんしようとする試みはすべて検出される。

実装者は、ファームウェア・アップデートのチェックと取得に、可能な限り最も安全なオプションを使用することを推奨する。

3.閉じる

Bluetooth^® Mesh デバイス・ファームウェア・アップデートは、ベスト・プラクティスに従い、ネットワークのノードとして機能するデバイスのファームウェアを最新に保つことを容易にする。これは、ベンダーからの新しいリリースの可用性を自動的に監視し、シンプルで可能な限り控えめなユーザー・エクスペリエンスをサポートするように設計されています。

Bluetooth Mesh デバイス・ファームウェアのアップデート