Bluetoothメッシュを使用したBluetooth Low Energyスマートアプリケーションの設計 - 第 2 部

編集者メモ：この2部構成シリーズの第1部では、Bluetooth mesh 1.0プロトコルのアーキテクチャと機能について詳しく説明しました。この第2部では、チップと開発キットを使用してBluetoothメッシュをBluetooth Low Energyの設計に統合する方法について説明します。

Bluetoothメッシュは、ネットワークに関するすばらしいメリットを人気の高い短距離プロトコルにもたらします。第1部では、これらのメリットについて詳細に説明しました。しかしながら、この仕様によって設計上、特にモデルの実装に関する新たな課題も生じています。

こうした課題を克服するための鍵は、アップグレードされた開発ツールを活用して、Bluetoothメッシュに十分に精通することです。この記事では、さまざまなBluetoothハードウェアとソフトウェア、開発キット（DK）、ソフトウェア開発キット（SDK）を使用して、Bluetoothメッシュアプリケーションを設定および構築する方法について説明します。

Bluetoothメッシュの開発ツール

Bluetoothメッシュスタックは、BLEホストレイヤと一部の概念を共有するが、互換性のない完全に新しいホストレイヤで構成されています。現在、Bluetoothメッシュスタックの初期バージョンは、一般的にはSDKの一部としてエンジニアリング開発で利用可能になっています。

BluetoothメッシュはBluetooth Core Specificationの補完仕様であるため、ベンダは、BluetoothメッシュをサポートするためにBluetooth Low Energy（BLE）の物理レイヤ（PHY）やソフトウェアスタックを更新する必要はありません。ただし、Bluetoothメッシュを追加するには、ベンダはお客様向けに独自のスタック実装を導入する必要があります。

たとえば、BLEベンダのNordic Semiconductorは、nRF5 SDK for Meshを発表しました。このキットに含まれているBluetoothメッシュスタックには、メッシュアプリケーション用のさまざまなドライバ、ライブラリ、および例が含まれます。SDKは、いくつかの統合開発環境（IDE）、およびSegger Microcontroller Systemsが提供するSEGGER Embedded StudioやCMakeなどのコンパイラで動作します。

BluetoothメッシュはすべてのバージョンのBLE（つまり、4.0、4.1、4.2および5）と互換性があるため、NordicのメッシュSDKは結局のところすべてのBLEチップと連携します。ただし、現在のバージョンが連携するのは、Nordicが提供する最新のnRF52シリーズBLEソリューションのみです（ミッドレンジクラスのBluetooth 5対応nRF52832チップなど）。

BLE PHYやソフトウェアスタックに対する変更はないため、Bluetoothメッシュの開発作業はターゲットデバイスを組み込んだ既存のDKで実行できます。nRF52832に推奨されているDKは、nRF52 DKです（図1）。

図1：Nordic Semiconductorが提供するメッシュSDKは、nRF52832 SoCターゲットデバイスを組み込むnRF52 DKと連携します。（画像提供：Nordic Semiconductor）

メッシュ環境での通信およびシミュレーションを行うために、メッシュ開発には少なくとも3個（できればそれ以上）のデバイスが必要です。複数のDKを使用してメッシュ内のノードを表すことができれば理想的ですが、この方法には開発のハードウェアコストが大幅に増大するという欠点があります。別の方法として、1つのDKを使用して、（ターゲットデバイスに基づいて）テストおよび検証済みのBLEモジュールを購入し、追加のノードを形成することもできます。Nordic nRF52832を使用した開発では、RigadoのBMD-300またはLairdのBL652-SA-01-T/Rが適切なモジュールオプションです。

Cypress SemiconductorはNordicと同様のアプローチを採用しています。この会社は、BCM92073X WICED Smart DK用のBluetoothメッシュSDKを提供しています。これは、CypressのBCM20736S Bluetooth v4.1 PHYに基づいています。このPHYに基づいたメッシュ開発作業に最適なBLEモジュールには、InventekのISM20736Sがあります。

モジュールとは

NordicとCypressが提供するハードウェア、ソフトウェア、および開発ツールには、シンプルなBluetoothメッシュアプリケーションの構築手順を開発者に紹介する例やチュートリアルが完備されています。ただし、設計プロセスに大きく関係しているため、初めての設計に着手する前に、関連するチュートリアルに一通り目を通して、Bluetoothメッシュのアーキテクチャに固有の特徴を理解しておくことが役に立ちます。

こうしたチュートリアルでは、Bluetoothメッシュノードには汎用的な4種類がありますが（この2部構成シリーズの第1部を参照）、それぞれの機能はモデルによって決定されるということを強調しています。モデルを理解することは、Bluetoothメッシュの機能を最大限に活用するために重要です。

開発者が多くのカスタム動作を備えたデバイスを有効にするモデルを構築できるように、Bluetoothメッシュは新しいメッシュアプリケーションを構築するために必要な柔軟性を提供しています。モデルは必要な状態、その状態で動作するメッセージ、および関連する動作を定義します。メッシュネットワークでの通信はすべてメッセージによって促進されます。

状態とは、要素の状況を表す値です。要素とは、デバイスまたはノードのアドレス可能なエンティティです。各デバイスには少なくとも1つの（プライマリ）要素があります。また、1つ以上のセカンダリ要素がある場合があります。要素の数や構造はノードの寿命が続く限り変わりません。状態を「公開する」要素はサーバと呼ばれます。状態に「アクセスする」要素はクライアントと呼ばれます。

重要なのは、モデルにはサーバ、クライアント、コントロールの3種類があることです。サーバモデルは1つ以上の要素にまたがる1つ以上の状態で構成されています。サーバモデルは、送信または受信できる一連の必須メッセージ、メッセージを送信および受信したときの要素の動作、メッセージが送信または受信された後に発生する追加の動作を定義します。

クライアントモデルは、サーバモデルによって定義されたように、対応するサーバの状態を要求、変更、または「消費」するためにクライアントが使用する一連のメッセージを定義します。クライアントモデルには状態がありません。

コントロールモデルは、クライアントモデルの機能（他のサーバモデルと通信するため）とサーバモデルの機能（他のクライアントモデルと通信するため）を組み合わせることができます。コントロールモデルには制御ロジックを含めることもできます。制御ロジックとは、コントロールモデルの接続先である他のモデルとの間で、コントロールモデルのやり取りを調整する一連のルールや動作です（図2）。

図2：コントロールモデルを実装するBluetoothメッシュデバイスの要素モデルの構造を示しています。デバイスCはクライアントとして（デバイスAとB内にある）サーバモデルと通信できます（それぞれメッセージX、Y、ZとメッセージR、S、T）。また、サーバとして(デバイスD内にある）クライアントモデルと通信できます（メッセージA、B、Cをサポート）。（画像提供：Bluetooth SIG）

モデルの使用を実例で示すために、2つの独立した電源ソケットから成る電源タップについて考えてみます。各電源ソケットで電力出力を制御することができ、BLE無線機が統合されているため、電源タップをBluetoothメッシュに接続することができます。

デバイス（電源タップ）は、2つの電源ソケットのそれぞれを表す2つの要素を備えています。各要素の機能は、サーバでの一連の状態と、その状態で動作する一連のメッセージを定義するGeneric Power Level Serverモデルによって定義されます。Generic Power Level Setメッセージは、出力電力を制御するためにデバイスに送信される場合があります。メッセージはソケットの要素のうちの1つにアドレス指定されます。

ソケットは、Generic Level Clientモデルを実装する調光器などの汎用デバイスで制御することもできます。このモデルは、目的のレベルをゼロ、最大値、またはその間の値に設定します。ソケットへの電力は状態をバインドすることで制御します。各電源ソケットにおいて、Generic Power Actualの状態がGeneric Levelの状態にバインドされます。Generic Level ClientはGeneric Level Serverに対してGeneric Levelメッセージを送信します。Generic Levelの状態が変更されると、次に（定義済みのバインドを介して）電力出力を制御するGeneric Power Actualの状態が変更されます。

要素は状態をレポートできるため、各ソケットは電力レベル、およびソケットに差し込まれたデバイスのエネルギー消費をレポートできます。エネルギー消費は、センササーバモデルによって定義されるメッセージを使用してレポートされます。

Bluetoothメッシュネットワークの構築

開発者がBluetoothメッシュのアーキテクチャとBLE開発の両方にある程度精通していること（一般的なBLE設計の詳細については、DigiKeyの記事「IoTの要件を満たすBluetooth 4.1、4.2、および5対応Bluetooth Low Energy SoCおよびツール」を参照）、そしてネットワークを設定するためにBluetoothメッシュSDK、ホストSDK、DKと追加モジュールまたはDKを装備していると仮定すると、開発者は比較的簡単にBluetoothメッシュの実装を構成することができます。

最初の手順はメッシュスタックを構築することです。Nordicの場合、スタックは選択したIDEを使用して構築されます。たとえば、SEGGER Embedded Studioを使用すると、スタックはBluetoothメッシュSDK（「照明スイッチ」の例など）に含まれるいずれかの例を使用し、IDEによってコンパイルすることで構築されます。

その後、DK上のターゲットPHYは消去され、コンパイル済みのBluetoothメッシュスタックとBLEスタックの両方を使用して再プログラミングされます。スタックのプログラミングと検証が行なわれると、SDKを使用してメッシュネットワークを設定および構築することができます。

プロビジョニング：Nordicが提供する開発ツールには、メッシュネットワークに新しいデバイスを追加するために使用されるプロビジョニングアプリケーションプログラミングインターフェース（API）が含まれています。プロビジョニングは、メッシュネットワークに参加するために必要な情報を新しいデバイスに提供するために使用されるプロビジョナ（すでにネットワークに接続され、プロビジョニングタスク用に前もって構成済みのデバイス）によって処理されます。最初に、プロビジョニング後の構成用に安全なチャンネルを確立するためのネットワークキー、アドレス、およびデバイスキーがデバイスに提供されます。

APIを使用することで、開発者は、BLEの3つのアドバタイジングチャンネルで送信される、プロビジョニングされていない（またはプロビジョニ - ネットワークに追加されるデバイス）ノードのブロードキャストビーコンのリッスンを開始できます。Bluetoothメッシュは、37の全帯域幅データチャンネルではなく、BLEのアドバタイジングチャンネルを使用してメッセージの送受信を行います。チャンネルで着信したリンク要求は、プロビジョナによって自動的に受け入れられます。

リンクが確立されると、ネットワークに参加するデバイスが指定されたターゲットであることを確認するために、帯域外（OOB）方式を使用して認証が行われます。OOB方式を使用することで、BLEのスペクトラム割り当てをリッスンしているデバイスからの「中間者」攻撃の可能性が軽減されます。その後、APIイベントによってデバイスのプロビジョニングデータとデバイスキーが提供されます。

構成：（SDKに含まれる）Nordicの「照明スイッチ」アプリケーションは、プロビジョナとプロビジョニ両方のロールを使用してアプリケーションを開発する方法を示しています。このデモでは、照明スイッチクライアントモデル（スイッチ）がプロビジョナであり、照明スイッチサーバモデル（電球）がプロビジョニです。

Nordicの例では、Bluetoothメッシュ仕様で最もシンプルなサーバはGeneric OnOff Serverであり、サーバはオンまたはオフのいずれかであるという事実を最大限に活用しています。たとえば、最もシンプルなクライアントは、Generic OnOff Modelによって定義されるメッセージを介してGeneric OnOff Serverを制御することができるGeneric OnOff Clientです。

このサーバモデルがクライアントモデルからGETまたは（信頼できる）SETメッセージを受信すると、サーバモデルはOnOff状態の現在の値を応答として送信します。これにより、サーバの状態に関してクライアントを最新の状態に保つことができます（図3）。

図3：Generic OnOff ModelによってサポートされるメッセージとATTオペコード（画像提供：Nordic Semiconductor）

構成サーバはデバイスのメッシュネットワーク構成を表すために使用され、Bluetoothメッシュノードの必須要件です。構成サーバは、（プロビジョナによって制御される）構成クライアントとの通信や構成クライアントからの命令を処理します。

構成はプロビジョニングの完了後に開始されます。プロビジョナは、プロビジョニの構成データを読み取って、デバイスのメタデータと、どのモデルがデバイス内のどの要素にバインドされているかを特定します。次に、アプリケーションやネットワークキーが追加され、異なるモデルにバインドされます（図]4）。

図4：プロビジョニングとnRF5 SDK for Meshからの構成フローチャート。「nrf_mesh…」のコールアウトはAPI関数です。（画像提供：Nordic Semiconductor）

ネットワークへのさらなるデバイスの追加は、単に、新しい各ノードに対してプロビジョニングと構成のプロセスを繰り返すことです。

パブリッシュとサブスクライブ：最初のアプリケーションを設定および構築する最終段階は、モデルのパブリケーション状態を設定することです。たとえば、状態イベントのパブリッシュに使用されるアドレス、使用するキー、使用する「Time-To-Live」（TTL）値を設定し、サブスクリプションを設定します。

各モデルのパブリッシュアドレスからパブリッシュされると、メッセージが送信されます。たとえば、パブリケーションは定期的にデータをレポートするセンサノードによって使用されます。メッセージは1回だけパブリッシュすることも、繰り返しパブリッシュすることもできます。また、ユニキャスト、グループ、または仮想アドレスのいずれかに送信されます（この記事の第1部を参照）。パブリケーションは、サーバモデルにメッセージを送信するために、クライアントモデルによっても使用されます。

パブリケーション関連の状態の設定は、一般的に、構成モデルを介してプロビジョナによって制御されます。

Nordic SDKを使用している場合、メッセージはAPI関数の「access_model_publish()」を使用してパブリッシュされます。このAPI関数は、パブリッシングモデルのパブリケーション設定（間隔、宛先）に従ってメッセージをパブリッシュします。

サブスクリプションによって、モデルは特定のアドレスからの着信メッセージをリッスンできます。たとえば、センサノードからパブリッシュされた定期メッセージをリッスンするために使用できます。Nordic SDKを使用すると、モデルは、API関数「access_model_subscription_list_alloc()」を使用してサブスクリプションリストを割り当てることで、アドレスをサブスクライブできます。

クライアントモデルを使用している場合は、メッセージへの応答を受信するためにメッセージの送信元アドレスをサブスクライブする必要はないことに注意してください。サブスクリプションは、ノードから一方的に送られてくるメッセージを受信するためだけに使用されます。

開発プロセス中は、Bluetoothメッシュに対応していないデバイスをBluetoothメッシュに接続する方が都合がよい場合があります。例として、プロトタイプのスマート照明メッシュアプリケーションを制御するために開発者が使用を希望するスマートフォンが挙げられます。モバイルとメッシュ間のやり取りは、Bluetoothメッシュスタックではなく、BluetoothスタックにあるスマートフォンとノードデバイスのGeneric Attribute Profile（GATT）インターフェースを介して実行されます。

結論

BluetoothメッシュはBLEアプリケーションに新しい機能を追加します。しかし、Bluetoothメッシュは元のコア仕様に含まれていなかったため、メッシュの追加によって多少の妥協点が生じてしまい、設計プロセスが複雑になりました。Bluetoothプロトコルスタックを使用した設計に慣れている開発者は、知識のない開発者よりも有利な立場にありますが、経験豊富なエンジニアであっても、Bluetoothメッシュを実装するには新しいアーキテクチャについて学習し、状態、要素、モデルなどの意味合いを理解する必要があります。

設計上の課題は、Nordic SemiconductorやCypress Semiconductorといったベンダと連携することで解消できます。これらのベンダは、成熟したBLEソリューションを補完するためにBluetoothメッシュスタックをリリースしました。スタックには目的に合うように設計されたSDKが付属しています。このSDKによって、開発者は使い慣れているチップ、ファームウェア、設計ツールを使用して、Bluetoothメッシュアプリケーションの設計について学習するプロセスを加速させることができます。

リファレンス

1. 「メッシュプロファイル」Bluetooth Specification v1.0、Bluetooth SIG、2017年7月