Bluetooth Meshゲートウェイのチップ選び：Telink、Silicon Labs、Nordicを比較
Telink mesh_gw、Nordic Zephyr、Silicon Labs NCP/BGAPIを比較。ゲートウェイファームウェア、シリアルプロトコル、ノード数、コストと、Silicon Labsを選んだ理由をまとめました。
前回の記事で、2つのことを決めました。デバイスとゲートウェイの間は SIG Mesh で通信すること。そしてゲートウェイ側では、Mesh プロトコルスタックを独立した Bluetooth モジュールに載せ、Linux のメインプログラムからシリアル経由で操作することです。
次はかなり具体的な話になります。この Bluetooth チップを、どこのものにするか？
Telink、Silicon Labs、Nordic の3社を比較しました。途中で一度、結論をひっくり返したこともあります。最終的にはゲートウェイに Silicon Labs、デバイスは引き続き Telink になりました。この記事では、比較の過程と理由を包み隠さず書いていきます。
まず整理：ゲートウェイ上のチップは何をするのか
ゲートウェイ内の Bluetooth モジュールは、普通の Mesh ノードではありません。いくつもの役割を担います。
- プロビジョナー：新しいデバイスのプロビジョニング、アドレス割り当て、鍵の配布とバインド
- コントローラー：オンオフ、調光、調色のコマンド送信と、デバイスから上がってくる状態の受信
- 常時給電ノード：ついでにリレーも担当し、遠くのデバイスへメッセージを転送
- コプロセッサー：UART 越しに Linux ホストの指示を受け取り、受信したメッセージをそのまま上位へ報告
つまりチップ選びで比べるべきは、チップ単体のスペックだけではありません。もっと大事なのは、ベンダーが出来合いの「ゲートウェイ用ファームウェア」を用意しているか、そしてホストとモジュールの間のシリアルプロトコルが使いやすいかです。ここで、ゲートウェイのプログラムをどれだけ書く必要があるか、あとで問題が起きたときに調べられる人がいるかが決まります。
Telink：コスト最安、ファームウェアも既製。ただしプロトコルは独自仕様
Telink は中国国内の照明・スイッチ市場で最も使われていて、うちのデバイスももともと Telink のチップです。SIG Mesh SDK は GitHub で公開されていて、ビルド済みのゲートウェイ用ファームウェア mesh_gw が最初から入っています。
mesh_gw の構成はだいたい次のとおりです。
| 層 | 内容 | 変更できるか |
|---|---|---|
| Bluetooth 下位層、Mesh プロトコルスタック | 暗号化、ネットワーク層、トランスポート層 | クローズドソース、ライブラリのみ提供 |
| ゲートウェイのアプリケーション層 | シリアルコマンド処理、プロビジョニングの流れ、状態報告 | オープンソース、変更可能 |
| ホストとのインターフェース | UART（新チップの TL321X はシリアルのみ対応） | Telink 独自プロトコル |
良い点ははっきりしています。
- チップが安い。量産時の単価は数元程度
- ゲートウェイ用ファームウェアが既製で、書き込めばすぐ使えます。Windows 用のデバッグツールもあります
- デバイスと同じベンダーなので、デバイス側で使っている Telink 独自拡張のモデルも、ゲートウェイがそのまま認識できます
問題はシリアルプロトコルです。Telink が独自に定義したもので、ドキュメントが少なく、細かい部分は SDK のソースを読まないとわかりません。たとえばコマンド名は HCI_CMD_GATEWAY_... で、Bluetooth 標準の HCI に見えますが、実際はまったくの別物で、フレーム形式も違います。ホストから送るフレームには長さヘッダがなく、シリアルのアイドルでフレームを区切ります。逆にモジュールから返ってくるフレームには長さヘッダが付きます。
容量の問題もあります。mesh_gw はデフォルトで最大 200 ノードしか保存できず、リモートプロビジョニングを有効にすると 110 ノードになります。ノード情報を Flash の1セクターにしか置いていないためです。家庭用なら十分ですが、商用では SDK のストレージレイアウトを変更する必要があります。
最初のプロトタイプは、まさにこの Telink のプロトコルで書きました。ソフトウェアで模擬したモジュールまで作ってテストしています。動くことは動くのですが、機能を足すたびにソースを読み返すことになり、どうにも落ち着きませんでした。
Nordic：ツールとドキュメントは最高。ただしゲートウェイ用ファームは自作
Nordic の nRF52840 や nRF5340 は、Bluetooth 開発界隈での評判がとても良く、ドキュメント、パケットキャプチャツール、スマホのデバッグアプリのどれも業界最高クラスです。nRF52840 Dongle は10ドル前後で、PC の USB に挿せばすぐ開発できます。
ただし Nordic には決定的な弱点があります。新世代の nRF Connect SDK には、公式の「シリアルゲートウェイ用ファームウェア」がありません。 昔の nRF5 SDK for Mesh にはありましたが、すでにメンテナンスが終了しています。そのため、ゲートウェイ側のやり方は3通りあります。
| やり方 | モジュールで動かすもの | ホストの仕事 | 評価 |
|---|---|---|---|
| ゲートウェイ用ファームを自作 | Zephyr の Mesh プロビジョナーとクライアントモデル、その上に独自のシリアルプロトコル | 翻訳だけ | 構成は最もきれいだが、C で1,000〜2,000行ほど書く必要がある |
| モジュールは Bluetooth コントローラーとしてのみ使う | Zephyr 標準の HCI ファームウェア | Linux で BlueZ の Mesh デーモンを動かすか、プロトコルスタックを自前で実装 | ファームは既製だが、Windows では開発できない |
| Zephyr Mesh Shell | 標準のコマンドライン | テキストコマンドを送る | デバッグ専用 |
容量面では、Zephyr のプロトコルスタックは最大 4096 ノードまで設定でき、メモリから見積もると実際には1,000〜2,000台ほど扱えます。ただしデフォルトの設定はわずか 8 ノードで、リプレイ防止リストも 10 エントリしかありません。変更しないと、11台目のデバイスのメッセージで問題が出ます。Zephyr でゲートウェイを作るときに、とても踏みやすい落とし穴です。
Nordic が向いているのは、ゲートウェイの Mesh 部分を完全に自分で握りたい場合や、1台のゲートウェイで数百台以上のデバイスを管理したい場合の2つです。うちはどちらにも当てはまらず、モジュールの価格も明らかに高いので、選びませんでした。
Silicon Labs：シリアルプロトコルに正式なドキュメントがある。これが決め手
Silicon Labs の考え方は Telink と同じで、「モジュールがプロトコルスタックを動かし、ホストがコマンドを送る」方式です。公式には NCP（Network Co-Processor）モードと呼ばれています。違うのはシリアルプロトコルで、BGAPI と呼ばれるこのインターフェースには正式なドキュメントがあります。
- コマンド、レスポンス、イベントのすべてにドキュメントがあり、C と Python の公式ホスト側ライブラリもあります
- カバーしている機能は、ほぼ Mesh API の全部です。プロビジョニング、設定、各種標準モデル、鍵の更新、ファームウェアのアップデートまで
- SDK に出来合いのホスト側プロビジョニングのサンプル（公式アプリケーションノート AN1371）があり、うちの Rust 実装はその流れに沿って書けばよいだけです
- デバッグツールの NCP Commander には GUI があり、コードを書かなくてもプロビジョニングや点灯ができます。Telink のデバッグツールに相当します
BGAPI のフレーム形式はとてもシンプルで、4バイトのヘッダに最大 255 バイトのデータが続きます。
[hdr0][len_lo][class][cmd][payload 0–255 字节]
hdr0 のbit7でコマンド/イベントを区別し、bit6–3がデバイスタイプ、bit2–0が長さの上位3ビットです。注意点が1つあります。BGAPI はシリアル上にチェックサムがなく、フレームの区切りを完全に長さに頼っています。そのため、バイト落ちを防ぐために RTS/CTS のハードウェアフロー制御を有効にする必要があります。メインコントローラーのチップを選ぶときは、そのシリアルがフロー制御に対応しているか確認してください。
価格面では、Silicon Labs のゲートウェイ向けには EFR32BG24 を使います。公式サイトの1,000個時の価格はおよそ 2.7〜3.7 ドルで、Telink より高めです。ゲートウェイ1台あたりでは、約2ドルのコスト増になります。
3社を並べて比べる
| Telink | Nordic | Silicon Labs | |
|---|---|---|---|
| ゲートウェイ用ファーム | 既製（mesh_gw） |
自作、または標準 HCI を使う | 既製（NCP サンプル） |
| シリアルプロトコル | 独自仕様、ドキュメント少なめ | 自分で定義、または標準 HCI | BGAPI、正式なドキュメントとホスト側ライブラリあり |
| デバッグツール | あり | 最高 | 良い |
| デフォルトのノード容量 | 200（リモートプロビジョニング時は 110） | 8、要拡張、最大 4096 | NCP ファームの設定次第 |
| チップコスト | 最安 | やや高い | 中程度 |
| 中国国内のサプライチェーン | 最も成熟 | 普通 | 比較的良好 |
私たちの選択：ゲートウェイは Silicon Labs、デバイスは Telink
最終的な組み合わせはこうなりました。
- ゲートウェイ：Silicon Labs の BG24 シリーズのモジュールで、NCP ファームウェアを動かす
- デバイス：引き続き Telink で、Telink の SIG Mesh SDK を動かす
ゲートウェイは1台につきモジュール1個だけです。約2ドル高くなる代わりに、ドキュメントのあるシリアルプロトコル、完全な Mesh API、公式サンプルが手に入り、あとの保守がずっと楽になります。デバイスは事情が違います。スイッチや照明は出荷数が多く、1個あたりの差額が積み重なると大きな金額になるので、Telink のコストと中国国内のソリューションベンダーのリソースのほうが向いています。
2社のチップを1つのネットワークに同居させられるのは、前回書いた SIG 標準モデルのおかげです。デバイスが Generic OnOff、Light Lightness、CTL といった標準モデルしか使っていなければ、ゲートウェイがどこの製品でも関係ありません。デバイスが Telink 独自の拡張モデルを使っている場合は、標準モデルに置き換えるか、ゲートウェイ側で対応するベンダーモデルを実装する必要があります。
Telink のプロトコルをやめても、ゲートウェイプログラムで書き直すのはシリアルプロトコルの層だけです。Matter、デバイステーブル、変換レイヤーは触らずに済みます。第1回で書いた、レイヤー分割した設計のメリットが、ここでも裏づけられました。
まだ検証していないこと
ここまでの結論は、いまのところ机上のものです。開発ボードが届いたら、まず次の3点を確認します。
- Silicon Labs のゲートウェイと Telink のデバイスが、実際に相互接続できるか。 コードを書く前に、Silicon Labs の NCP Commander で、Telink の照明用ファームを書き込んだ開発ボードをプロビジョニングして点灯させてみます。
- メインコントローラーのシリアルでハードウェアフロー制御が使えるか。 長時間のストレステストを回して、フレーム落ちが起きないかを見ます。
- 1台のゲートウェイで、安定して何台のデバイスを扱えるか。 NCP ファームのノード数やリプレイ防止リストなどのパラメータを、実際の要件に合わせて調整する必要があります。
検証結果は別の記事にまとめます。
おわりに
ゲートウェイの Bluetooth チップを選ぶとき、チップの価格やスペックばかりに目が行きがちです。でも開発や保守に本当に効いてくるのは、目に見えないシリアルプロトコルのほうだったりします。ドキュメントがあるか、デバッグできるか、問題が起きたときに原因を追えるか、という点です。
Bluetooth Mesh ゲートウェイのチップ選びで悩んでいる方や、Silicon Labs の BGAPI、Telink の mesh_gw との連携に取り組んでいる方は、ぜひ気軽に話しかけてください：linktr.ee/weiyii