Bluetooth 5メッシュネットワークの迅速な実現

Bluetooth 5のメッシュネットワーク機能を利用することで、開発者は IoTデバイスなどのワイヤレス接続システムの範囲とネットワークの可用性を拡張できます。一方で、メッシュネットワークの低電力ワイヤレスハードウェア設計とメッシュネットワークソフトウェア開発の間に存在する何層もの複雑さは、開発者をたちまち混乱に陥れ、プロジェクトのスケジュールを台無しにする可能性があります。

Bluetooth 5対応のスマートフォンやその他のモバイルプラットフォームの出現によって、開発者はほぼすべての業界やアプリケーションで予測されるBluetoothメッシュネットワーク機能の急速な需要の高まりに迅速に対応しなければならないため、時間は重要な要素となっています。この状況に応じるために、チップベンダおよびソフトウェアベンダは、開発プロセスの簡素化と迅速化を図るソリューションを導入しています。

この記事では、Bluetoothメッシュネットワークの原理を概説した後、Silicon Labsのメッシュ対応 Bluetooth 5モジュールラインの特定のデバイスを使用して開発プロセスの手順を段階的に説明していきます。このような統合型Bluetooth 5ソリューションを使用すると、開発者は接続されたデバイスやアプリケーションをすばやく展開し、Bluetoothメッシュネットワークを完全に活用できます。

この記事の最後に、Silicon Labs Bluetoothメッシュソフトウェア開発パッケージについて説明し、サンプルのメッシュアプリケーションコードを使ったイベント駆動型モデルのデモなどを詳しく見ていきます。

Bluetoothメッシュの必要性

Bluetoothメッシュは従来のBluetooth技術の2点間接続機能を超えるものです。近隣の接続されているデバイスを通じてメッセージをリレーすることで、Bluetoothメッシュは、低電力デバイスの有効範囲をトランスミッタ電力出力とレシーバ感度で提供される実際の範囲を超えて拡張します。最も重要なことは、Buetoothメッシュがスマートフォンやその他のモバイル機器のBluetooth対応アプリで普及していることを受け、より高度なメッシュ接続型アプリケーションが自然に発展していることです。

メッシュのサポートにより、Bluetoothを使用している開発者はホームオートメーション、ビルディング管理、さまざまなIoTアプリケーションで多くのデバイスを容易に接続できるようになりました。

Bluetoothメッシュのしくみ

Bluetoothメッシュはネットワーク内のノード間で概念上シンプルな相互作用モデルを使用しています（図1）。特殊なノードタイプがメッセージをノード間でリレーするために必要な追加の機能を提供し、Bluetooth対応モバイル機器とプロキシノードを通じて相互動作するネットワークの有効範囲を拡張します。

図1：基本のエッジノードとともに、Bluetoothメッシュネットワークは特殊なノードタイプを使用して他のノードのメッセージを渡したり（リレー）、低電力ノードのキャッシュとして動作したり（フレンド）、Bluetooth対応モバイル機器にネットワークを接続（プロキシ）することができます。（画像提供：Silicon Labs）

低電力ノードがより長いスリープ状態の間に定期的にポーリングするメッセージをフレンドノードを使用してキャッシュすることで、電力削減の要件に対応する特殊なノードタイプもあります。この追加機能を提供しながらも、Bluetoothメッシュデバイスは汎用属性プロファイル（GATT）サービスを使用して、前のバージョンのBluetoothを使用している従来のデバイスと接続できます。このように、メッシュデバイスは、スマートフォンに対するエリア固有のメッセージを生成したり、資産管理アプリケーションで自身を識別したりするためのビーコンなど、既存のBluetooth Low Energy（BLE）機能を十分に活用できます。

Bluetoothメッシュは、ビルオートメーションやその他のIoTアプリケーションに必要な保護されたネットワークのセキュリティに対して増大している懸念にも対応します。単一デバイスを保護するセキュリティがオプションになっているBLEとは異なり、Bluetoothメッシュはメッシュネットワーク全体の保護を試みてセキュリティを強化しています。

Bluetoothではメッシュセキュリティに特に興味深いアプローチを採用しています。そのセキュリティスキームでは、各デバイス、ネットワーク、アプリケーション全体に個別のセキュリティ対策を使って、メッシュ ネットワークに懸念の分離という概念を導入しています。各デバイスに関連付けられたプライベートデバイスキー（DevKey）は、そのノードのみに関連する構成やプロビジョニングなどの操作に対するセキュリティを提供します。各デバイスには、ネットワークまたはサブネット内の他のノードと通信するためにネットワークキー（NetKey）が必要です。最後に、照明をつけるためのメッセージの送信など、アプリケーションレベルの相互作用にはアプリケーションキー（AppKey）が必要です。中間者攻撃やリプレイアタックなどの一般的な脅威を防ぐセキュリティ対策もあります。これらの対策が組み合わされたBluetoothメッシュのセキュリティ対策は、より高度なIoTアプリケーションに必要な信頼性の重要な基盤を提供します。

Bluetoothメッシュ接続型アプリケーションを実装するのは、開発者にとって非常に難しい作業です。メッシュネットワークを使用するほとんどのアプリケーションは電力が制限されたデバイス上で構築されており、低電力無線サブシステムの有効範囲を拡張するためにメッシュネットワークに依存しています。適切なメッシュ対応低電力ハードウェアデバイスの作成に関する課題は、経験豊富なハードウェア開発者でも対応できない可能性があります。特定仕様のBluetooth設計が完成した後も、開発者は国の認定要件を満たすための多大なコストと遅延の長期化に直面することがあります。ソフトウェア開発者は、独自のアプリケーションをサポートできるソフトウェアレイヤを構築する際に、互換性のあるBluetoothメッシュスタックを見つけて使用するために作業が遅れることがあります。Silicon LaboratoriesのBluetoothハードウェアとソフトウェアを使用すると、開発者は独自のアプリケーションに適した低電力デバイスにBluetoothメッシュ機能を迅速に導入できます。

Bluetoothモジュール

Silicon LabsのBluetoothメッシュソリューションは低電力Bluetooth BGM13Pハードウェアモジュールに基づいて構築されています。このモジュールではワイヤレスプロセッサと完全なBluetoothスタックが統合され、完璧な認定済みBluetoothシステムを12.9 × 15.0 × 2.2mmのパッケージで提供します。モジュールの中心である EFR32BG13 Blue Geckoワイヤレスシステムオンチップ（SoC）が中核機能を提供します。EFR32BG13 SoCには、32ビットのArm® Cortex®-M4コア、2.4GHzの無線サブシステム、512KBのフラッシュ、64KBのRAM、アナログおよびデジタルペリフェラルによる広範囲な補完が統合されています。SoCは、オンチップハードウェアの暗号アクセラレータとともに、メモリ保護ユニットでメモリに提供しているものと同じ種類のきめ細かなアクセス制御をペリフェラルに提供するセキュリティ管理ユニットによって、増大する厳格なセキュリティへの需要に対応しています。

EFR32BG13 SoCは、カスタムのBluetoothハードウェア設計の基盤として機能できます。SoCを使用する際に、開発者はSoCサポート回路などの設計要件だけでなく、完成した設計に必要な認定についても責任があります。このモジュールは、複数の発振源、2つの水晶、およびポートドライバを含む必要なサポート回路を備え、EFR32BG13を含む完全な認証済み設計を提供します。同時に、低電力デバイスの絶え間ない需要に開発者が対応できるよう、幅広い節電機能も備えています。

モジュールの消費電力は、アクティブモードで87マイクロアンペア(µA)/MHz、完全なRAMリテンションのディープスリープモードで1.4μAのみです。低電力ディープスリープモードの時間を最大化するために、エンジニアは低エネルギーセンサインターフェースと低エネルギータイマーなどの機能を利用できます。低エネルギーセンサインターフェースを使用して、エンジニアはモジュールの統合された有限状態マシンとアナログ周辺機器をプログラミングし、センサ信号を取得および処理すると同時に、プロセッサをディープスリープモードの状態に維持できます。同様に、低エネルギータイマを使ってエンジニアはシンプルな波形を出力し、リアルタイムクロック/カウンタを監視してプロセッサが関わることなく指定された期間にアクションを実行できます。

もちろん、ワイヤレスデバイスの消費電力は一般的に無線サブシステムの効率性によって異なります。この場合、モジュールの2.4GHzの無線サブシステムは、受信モードの場合は9.9ミリアンペア（mA）、0dBm出力電力での送信モードの場合は8.5mAしか消費しません。さらに、RFコントロールによって節電を行う追加機能があります。開発者は、広帯域RFエネルギーが検出されたときにプロセッサがウェイクするようモジュールでRF検知機能をプログラミングできます。このアプローチを使用すると、通信を失うことなく非アクティビティ期間中にモジュールをディープスリープ状態にしておくことができます。ただし、前述したように、単純にディープスリープから定期的にウェイクしてキャッシュされたメッセージについてフレンドノードをポーリングするBluetooth 5低電力ノードとして機能するようデバイスを設定することもできます。

システム開発

モジュールのすべての機能は簡単に実装できます。開発者は、既存のプロセッサを含む設計にモジュールをドロップするだけで、Bluetoothネットワークコプロセッサとして使用できます（図2A）。または、モジュールを完全なシステムソリューションとして使用できます（図2B）。このスタンドアロンモードでは、開発者はモジュールのEFR32BG13プロセッサでアプリケーションコードを実行し、EFR32BG13の統合されたアナログおよびデジタル周辺機器をシンプルなIoT設計での信号収集に使用します。

図2：開発者は、BGM13PモジュールをホストCPUのBluetoothコプロセッサとして使用するか（A）、単独で 使用して（B）、モジュールの統合されたEFR32BG13 SoCをアプリケーションプログラムの実行およびセンサデータの収集にも利用できます。（画像提供：Silicon Labs）

開発者は、 BGM13P22F512GA-V2（モジュールの統合されたアンテナが含まれるバージョン）を使用してBluetoothの設計をさらに簡素化できます。より困難なRF環境を対象としている設計の場合、開発者はBGM13P22F512GE-V2に変更できます。このバージョンは、TaoglasのFXP74.07.0100AなどBluetooth互換のフラットパッチアンテナを接続するためのU.FLコネクタを備えています。

Silicon Labsは、 SLWSTK6101C開発キットにより、そのレベルのハードウェア実装も排除します。さまざまなBluetoothデバイスのプラグインボードと連携するように設計されているSLWSTK6101Cは、MacronixのMX25R8035F 8Mビットフラッシュ、Sharp MicroelectronicsのLS013B7DH03 128 x 128 LCD、およびSilicon Labsの Si7021温度および湿気センサを含む代表的なIoT設計を提供します。この場合、開発者は、BGM13Pモジュールが組み込まれているSLWRB4306A無線ボードをSLWSTK6101C ボードに挿します。

すぐに生産が可能な設計であることに加え、完成したボードセットは、エンジニアがフラッシュ、LCD、センサなどのデバイスとのインターフェースのさまざまなアプローチを調べるために使用できる実証済みのリファレンス設計を提供します。

たとえば、8MビットフラッシュとLCDはそのSPIバスを通じてモジュールに接続しますが、Si7021センサのI²Cインターフェースはバスを開発ボード上の外部ヘッダと共有します。Silicon Labsは、センサを通常は無効の状態にしておき、その共有バスから電気的に絶縁するシンプルなインターフェ―スを設計する方法を示しています。モジュールのPD15入力が高くなると、SENSOR_ENABLE出力が高くなり、センサを3.3V VMCU電源レールとI²Cバスに接続します（図3）。

図3：ハードウェア評価プラットフォームの提供に加え、Silicon Labs SLWSTK6101C開発キットはリファレンス設計として機能し、ここに示すSilicon Labs Si7021センサなどの外部デバイスとインターフェースする方法を示しています（画像提供：Silicon Labs）

共有されたI²Cバスヘッダは、このプラットフォームでの開発をサポートするために設計された複数ある機能の1つにすぎません（図4）。オンボードJ-Linkデバッガとともに、ボードはエンジニアがパケットを詳細に分析できるパケットトレースインターフェース（PTI）を提供します。PTIはEFR32BG13 SoCに組み込まれたパケットと状態トレースユニットがベースとなっており、システムで送受信されるすべてのパケットの非侵襲性キャプチャを提供します。Bluetoothメッシュなどの複雑なプロトコルを分析するために、このパケットトレース機能には、低レベルのネットワーク通信の最適化とチューニングに欠かせないツールがあります。

図4：Silicon LabsのSLWSTK6101Cキットは、パケットトレース、エネルギーの監視、および低レベルのArm Embedded Trace Macrocell（ETM）トレース用に複数のインターフェースを備え、エンジニア向けに設計の動作とパフォーマンスの詳細な分析を行うための優れたツールのセットを提供します。（画像提供：Silicon Labs）

ネットワーク専門家にはネットワーク最適化のためにPTIなどの機能が必要ですが、システム開発者には、過度な消費電力につながる可能性のあるアプリケーションの非効率性を特定できるツールが必要です。この種のアプリケーションレベルの電力最適化のために、Silicon LabsのSimplicity Studioエネルギープロファイラは、電力消費のコードレベル分析を提供します。

パケットトレースツールと同様に、エネルギープロファイラは基になっているハードウェアを活用します。この場合、ボードには、電流センサレジスタ、電流検出アンプ、および開発ホストシステムでアクセスされるボードのコントローラに出力を提供するゲインの各段階で構成される専用のエネルギーモニタ回路が含まれています（図5）。並列のゲイン段階により、エネルギーモニタでは、 0.1μA～95mAの電流を2つの異なる分解能レベル（250μAを超える場合は0.1mAの分解能、および250μAのしきい値を下回る場合は1μA分解能）で測定できます。

図5：BGM13P Bluetoothモジュールに組み込まれている専用のエネルギーモニタ回路および処理コントローラは、 0.1μA～95mAの非侵襲性の電流測定値を提供できます。（画像提供：Silicon Labs）

エネルギーモニタ回路は電流測定値を生成しますが、EFR32BG13に組み込まれている低レベルのトレースメカニズムではプロセッサのプログラムカウンタを定期的にサンプリングし、結果をデバイスのシリアルワイヤ出力ピンに出力します。エネルギーモニタの結果とこのプログラムのトレース出力を組み合わせることで、エネルギープロファイラは、デバイスで実行中のコードにリンクされているエネルギー消費量をリアルタイムで表示できます（図 6）。

図6：Simplicity Studioエネルギープロファイラでは、エネルギーモニタ出力をプログラムのトレースデータと組み合わせて、実際のコードにリンクされた電流消費をリアルタイムで表示します。（画像提供：Silicon Labs）

メッシュアプリケーション開発

ハードウェアエンジニアは開発キットを使用してハードウェア設計を最適化でき、ソフトウェア開発者はSilicon Labsの包括的なソフトウェア開発環境を利用してメッシュネットワーク化されたアプリケーションを迅速に作成できます。Simplicity Studioで提供されるSilicon LabsのBluetooth 5メッシュスタックにより、基本のBluetoothスタックが特定のメッシュリソースで拡張されます。その結果、開発者は、ビーコンまたは2点間通信など従来型のBluetoothプロトコルから完全なメッシュトポロジに簡単に移動できます（図7）。

図7：Slicon Labs Bluetoothメッシュスタックは以前のBluetooth機能（青）をメッシュレイヤ（緑）で拡張し、開発者はビーコンから完全なメッシュ構成まであらゆる種類のBluetooth機能を利用できます。（画像提供：Silicon Labs）

Silicon Labs BGM13PベースのSLWRB4306AおよびSLWSTK6101C開発ボードとSimplicity Studioを併用すると、開発者は適切なソフトウェア開発キット（SDK）で環境を構成できます。Bluetooth環境では、Studioはあらかじめ作成されているデモバイナリとソースコードとともにSilicon LabsのBluetoothメッシュSDKを提供します。この環境内で、開発者は完全なBluetoothメッシュアプリケーションを実装するサンプルコードを使用できます。

Bluetoothメッシュネットワークでの動作を示すよう設計されているサンプルアプリケーションは開発ボードやモバイルアプリと連携して、プロビジョニング、構成、アプリケーション関連の使用など、メッシュの特徴的な動作を開発者に示します。サンプルアプリケーションを展開するには、エンジニアは、接続されている照明アプリケーションの照明やスイッチとして機能するよう個別に構成された開発ボードのセットに対してSimplicity Studioを実行します。サンプルコードとハードウェアを使うことで、エンジニアはデバイスの電源投入から始まる通常のメッシュアプリケーションの各動作段階をより的確に理解できるようになります。

Silicon Labsのソフトウェアアーキテクチャにより、Bluetoothの動作はイベントの性質を伝える事前定義されたイベントを使い、一連のイベントとして処理されます。サンプルのソフトウェアパッケージでは、電源投入時またはリセット時に実行されるmain()ルーチンが、（この例では2行コードのみで構成されている）そのmainループに入る前に一連の初期化ルーチンを呼び出します（リスト1）。

Copy int main() { #ifdef FEATURE_SPI_FLASH /* SPIフラッシュを対応する無線ボードでディープ電源ダウンモードにする*/ MX25_init(); MX25_DP(); /* SPI通信を無効にする必要がある */ USART_Reset(USART1); #endif /* FEATURE_SPI_FLASH */ enter_DefaultMode_from_RESET(); #if (EMBER_AF_BOARD_TYPE == BRD4304A) LNA_init(); #endif gecko_init(&config); #ifdef FEATURE_PTI_SUPPORT APP_ConfigEnablePti(); #endif // FEATURE_PTI_SUPPORT RETARGET_SerialInit(); /* LEDとボタンを初期化する。メモ：いくつかの無線ボードがボタンとLEDに同じGPIOを共有している。* 初期化はこの順序で実行されて、デフォルトの構成はピンが共有されている * 無線ボードのボタンになる。led_init()は、LEDの初期化に必要な場合に後で呼び出される * */ led_init(); button_init(); LCD_init(); while (1) { struct gecko_cmd_packet *evt = gecko_wait_event(); handle_gecko_event(BGLIB_MSG_ID(evt->header), evt); } } 

リスト1：Simplicity Studioは、初期化とイベント処理のループを示すこのメッシュ照明のmainルーチンのようなサンプルコードを含む、包括的な開発環境を提供しています。（コード提供元：Silicon Labs）

mainループの最初の行で、関数gecko_wait_event()は、下位レベルで追加されたイベントキューにイベントが表示されるのを待機している間ブロックします。開発者はブロッキング関数を避けることがよくありますが、Bluetoothスタックでは低電力スリープ状態がこのブロックされたモードで自動的に管理されるため、このアプローチは特に有効です。ブロッキング待機に耐えることができない特定のアプリケーション要件の場合、SDKは次のイベントまたはキューが空の場合はNULLを返す非ブロッキング関数も提供します。ただし、この関数を使用する場合、開発者は、独自に低電力スリープ管理を処理しなければなりません。

mainループの2行目では、ハンドラ関数handle_gecko_event()が、そのイベントID（リスト2）に基づいて最新のイベント（evt）を処理しています。デバイスに電源を入れると、スタックがシステムブートイベント（gecko_evt_system_boot_id）を発行します。次に、イベントハンドラがBluetoothメッシュスタックを初期化するgecko_cmd_mesh_node_init()を含む一連の初期化関数を呼び出します。後で、ハンドラが他の関数を呼び出して、その関連付けられたイベントIDで表されるイベントタイプに関連する機能を提供します。

Copy /** * スタックイベントの処理。Bluetooth LEおよびBluetoothメッシュイベントはここで処理されます。*/ static void handle_gecko_event(uint32_t evt_id, struct gecko_cmd_packet *evt) { struct gecko_bgapi_mesh_node_cmd_packet *node_evt; struct gecko_bgapi_mesh_generic_server_cmd_packet *server_evt; struct gecko_msg_mesh_node_provisioning_failed_evt_t *prov_fail_evt; if (NULL == evt) { return; } switch (evt_id) { case gecko_evt_system_boot_id: // 起動時のpushbutton状態を確認する。PB0またはPB1が押されたままの場合は、工場出荷時にリセット if (GPIO_PinInGet(BSP_GPIO_PB0_PORT, BSP_GPIO_PB0_PIN) == 0 || GPIO_PinInGet(BSP_GPIO_PB1_PORT, BSP_GPIO_PB1_PIN) == 0) { initiate_factory_reset(); } else { struct gecko_msg_system_get_bt_address_rsp_t *pAddr = gecko_cmd_system_get_bt_address(); set_device_name(&pAddr->address); // ノード動作モードでメッシュスタックを初期化し、初期化されたイベントを待機 gecko_cmd_mesh_node_init(); // LEDを再初期化（ボタン/LEDに同じGPIOを共有している無線ボードに必要） led_init(); } break; ...case gecko_evt_mesh_node_initialized_id: printf(node initialized\r\n); struct gecko_msg_mesh_node_initialized_evt_t *pData = (struct gecko_msg_mesh_node_initialized_evt_t *)&(evt->data); if (pData->provisioned) { ...} else { printf(node is unprovisioned\r\n); LCD_write(unprovisioned, LCD_ROW_STATUS); printf(starting unprovisioned beaconing...\r\n); gecko_cmd_mesh_node_start_unprov_beaconing(0x3); // enable ADV and GATT provisioning bearer } break; case gecko_evt_mesh_node_provisioning_started_id: printf(Started provisioning\r\n); LCD_write(provisioning..., LCD_ROW_STATUS); // プロビジョニング中のノードを示すために点滅しているLEDのタイマの開始 gecko_cmd_hardware_set_soft_timer(32768 / 4, TIMER_ID_PROVISIONING, 0); break; case gecko_evt_mesh_node_provisioned_id: _my_index = 0; // この例ではプライマリ要素のインデックスがゼロにハードコーディングされている lightbulb_state_init(); printf(node provisioned, got index=%x\r\n, _my_index); // プロビジョニングが完了するとLEDの点滅が停止する gecko_cmd_hardware_set_soft_timer(0, TIMER_ID_PROVISIONING, 0); LED_set_state(LED_STATE_OFF); LCD_write(provisioned, LCD_ROW_STATUS); break; case gecko_evt_mesh_node_provisioning_failed_id: prov_fail_evt = (struct gecko_msg_mesh_node_provisioning_failed_evt_t *)&(evt->data); printf(provisioning failed, code %x\r\n, prov_fail_evt->result); LCD_write(prov failed, LCD_ROW_STATUS); /* 短い遅延後にソフトリセットをトリガするワンショットタイマを開始 */ gecko_cmd_hardware_set_soft_timer(2 * 32768, TIMER_ID_RESTART, 1); break; ...} } 

リスト2：開発者は、メッシュ照明のmainルーチンで呼び出されるhandle_gecko_event()イベントハンドラルーチンから抜粋したこのスニペットに示される、イベント処理のプロビジョニングなどの主要な設計パターンをSilicon Labsのメッシュサンプルコードで調べることができます。（コード提供元：Silicon Labs）

Bluetoothメッシュネットワークにおける重要な一連のイベントの1つはプロビジョニングプロセスに関連します。デバイスに電源投入してその初期化シーケンスが完了した後、デバイスはビーコンモードになり、デバイス自体をプロビジョニングのためにネットワークに通知します。プロビジョニングが完了（または失敗）するまでの間、サンプルコードでは開発キットのLCDとLEDを使用してステータスを示します。プロビジョニング状態ごとにイベントハンドラのコードブロックを調べることで、開発者はこのプロビジョニングシーケンスとオプションをすばやく理解できます。

同様に、ソフトウェアエンジニアは、アプリケーションレベルの機能を作成するためのガイドとしてサンプルのハンドラコードを使用できます。たとえば、Bluetoothメッシュネットワークの重要な概念として、いくつかの機能の関係を共有するノードを関連付けるためのパブリッシュ/サブスクライブモデルの使用があります（図8）。

図8：アプリケーション開発者はBluetoothのパブリッシュ/サブスクライブモデルを使用して、デバイスを、1つ以上のスイッチでコントロールされる照明のグループなど機能上のグループに結合します。（画像提供：Silicon Labs）

このアプローチでは、複数のスマートバルブが1つのスイッチパブリッシャにサブスクライブできます。エンドユーザーがスイッチをアクティブにすると、スイッチでON/OFFイベントがパブリッシュされます。イベントはメッシュネットワーク経由でサブスクライブされたスマートバルブにカスケードされて、スマートバルブのイベントハンドラで適切なアクションが実行されます。Silicon Labsのサンプルコードはこのプロセスを示しています。最初にメッシュ接続されたスイッチでオン/オフ要求がパブリッシュされた後、接続された照明で対応する応答が行われます（リスト4）。

Copy /** *この関数は1つのオン/オフ要求をパブリッシュしてグループ内の照明の状態を変更する。* グローバル変数switch_posは必要な最新の照明状態を保持する。可能な値は次のとおり。 * switch_pos = 1 -> PB1が押された場合、照明はオンになる * switch_pos = 0 -> PB0が押された場合、照明はオフになる * * このアプリケーションはボタンが押されるたびに複数の要求を送信して信頼性を上げる。* パラメータretransはこれが最初の要求か、再送信かを示す。* 再送信の場合、トランザクションID は増分されない。*/ void send_onoff_request(int retrans) { uint16 resp; uint16 delay; struct mesh_generic_request req; req.kind = mesh_generic_request_on_off; req.on_off = switch_pos ?MESH_GENERIC_ON_OFF_STATE_ON : MESH_GENERIC_ON_OFF_STATE_OFF; // 再送信でない場合、要求ごとにトランザクションIDが増分する if (retrans == 0) { trid++; } /* 最後の要求はゼロ遅延となるように要求の遅延が計算され、前の各要求の遅延は * 50msずつ増える。たとえば、ボタンが押されるたびに * 3つのオン/オフ要求を使用すると、遅延は100、50、0msとして設定されます */ delay = (request_count - 1) * 50; resp = gecko_cmd_mesh_generic_client_publish( MESH_GENERIC_ON_OFF_CLIENT_MODEL_ID, _my_index, trid, 0, // transition delay, 0, // flags mesh_generic_request_on_off, // type 1, // param len &req.on_off /// parameters data )->result; if (resp) { printf(gecko_cmd_mesh_generic_client_publish failed,code %x\r\n, resp); } else { printf(request sent, trid = %u, delay = %d\r\n, trid, delay); } } 

リスト3：Silicon Labsのメッシュサンプルアプリケーションから抜粋したこのスニペットは、このイベントストリームにサブスクライブされた照明の状態（onまたはoff）の変更を要求するBluetooth 5パブリッシュプロセス（gecko_cmd_mesh_generic_client_publish）の使用例を示しています。（コード提供元：Silicon Labs）

Copy static void onoff_request(uint16_t model_id, uint16_t element_index, uint16_t client_addr, uint16_t server_addr, uint16_t appkey_index, const struct mesh_generic_request *request, uint32_t transition_ms, uint16_t delay_ms, uint8_t request_flags) { printf(ON/OFF request: requested state=<%s>, transition=%u, delay=%u\r\n, request->on_off ?ON : OFF, transition_ms, delay_ms); if (lightbulb_state.onoff_current == request->on_off) { printf(Request for current state received; no op\n); } else { printf(Turning lightbulb <%s>\r\n, request->on_off ?ON : OFF); if (transition_ms == 0 && delay_ms == 0) { // Immediate change lightbulb_state.onoff_current = request->on_off; lightbulb_state.onoff_target = request->on_off; if (lightbulb_state.onoff_current == MESH_GENERIC_ON_OFF_STATE_OFF) { LED_set_state(LED_STATE_OFF); } else { LED_set_state(LED_STATE_ON); } } else { // 電流の状態は今のところそのまま維持 lightbulb_state.onoff_target = request->on_off; LED_set_state(LED_STATE_TRANS); // set LEDs to transition mode gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(delay_ms + transition_ms), TIMER_ID_TRANSITION, 1); } lightbulb_state_store(); } if (request_flags & MESH_REQUEST_FLAG_RESPONSE_REQUIRED) { onoff_response(element_index, client_addr, appkey_index); } else { onoff_update(element_index); } } 

リスト4：Silicon Labsメッシュ照明サンプルには、スイッチからパブリッシュされた要求に応じてLEDをオンまたはオフにするこの関数のように特定のアプリケーションレベルのイベントのルーチンが含まれます（リスト3を参照）。（コード提供元：Silicon Labs）

ノード開発用のBluetoothスタックおよびSDKとともに、Silicon Labsは、Bluetoothメッシュパズルの最後のピースとなる、モバイル機器への接続も提供しています。ほとんどのモバイル機器はBluetooth 4をサポートし、その無線はBluetooth 5要件をサポートできますが、Bluetooth 5メッシュレイヤのスタックサポートは提供していません。Silicon Labsは、モバイルアプリ開発者にメッシュ機能を提供する追加のソフトウェアスタックを提供してこの制限を解決しています。

図9：開発者はSilicon Labsのモバイル機器用メッシュスタックをモバイルアプリに追加して、Bluetooth 5メッシュネットワークでのBluetooth 4モバイル機器の使用を可能にします。（画像提供：Silicon Labs）

結論

Bluetooth 5メッシュネットワークは、スマートフォンや他の2点間通信用モバイル機器をすでに利用しているさまざまなアプリケーションの自然な移行をもたらします。しかし、Bluetooth 5メッシュネットワークの導入によって、特にIoTなど電力が制限されているアプリケーションではハードウェアとソフトウェア両方の設計に大きな課題が生じています。さらに、ハードウェアエンジニアは、最小の設置面積と低電力要件を満たす必要があり、ソフトウェアエンジニアは、最小のリソースで複雑な通信プロトコルを実行するソフトウェアを構築する必要があります。エンジニアは、ノードとモバイル機器両方でBGM13Pモジュール、SLWSTK6101C開発ボード、Bluetoothスタックを組み合わせて、Bluetoothメッシュネットワークを使った迅速なアプリケーション開発を可能にする包括的なプラットフォームを利用できます。