SIG Meshは必要か？Bluetooth機器をゲートウェイにつなぐ方法の比較
独自アドバタイズ、BLE直接接続、独自メッシュ、SIG Meshをどう選ぶか。プロトコルと認証を分けて考え、標準モデルがMatterゲートウェイにもたらす価値と制約を整理します。
前回の記事では、PC とスマホだけで Matter 側の半分を動かせるところまで進めました。今回はゲートウェイのもう半分、ゲートウェイと Bluetooth デバイスのあいだで、いったいどんなプロトコルを使って通信するのかという話です。
うちのデバイスはもともと、自社で定義した Bluetooth のアドバタイズ（広告）プロトコルを使っていて、自社アプリから操作する作りでした。長いこと運用してきて、大きなトラブルもありません。そのせいか、プロジェクトの序盤にチームの誰かがこう聞いてきました。「SIG Mesh って、やらなくてもいいんじゃない？」
この問いは単独の記事にする価値があります。というのも、「やらない」には中身がまったく違う二つの意味があり、結果もまるで変わってくるからです。
まず整理：「やらない」とは何のことか
一つ目は、SIG Mesh プロトコルを使わないこと。 デバイスは独自のアドバタイズプロトコルのまま、ゲートウェイもそれに合わせて送受信します。
二つ目は、SIG Mesh プロトコルは使うけれど、Bluetooth SIG の認証（Qualification）は取らないこと。 技術的には標準に沿うものの、SIG への登録や費用の支払いはしない、というパターンです。
前者は技術選定の話、後者はコンプライアンスの話です。議論がかみ合わないのは、たいていこの二つがごちゃ混ぜになっているからです。ここではまず技術面を見て、認証は後半で扱います。
デバイスをゲートウェイにつなぐ方法は、だいたい四通り
| 方式 | カバー範囲 | デバイス数 | 相互運用性 | セキュリティ | 開発量 |
|---|---|---|---|---|---|
| 独自アドバタイズプロトコル | ゲートウェイの周囲のみ、中継不可 | 理論上は無制限 | 自社製品同士のみ | すべて自前 | 小 |
| BLE 直結（各デバイスがゲートウェイと接続を張る） | ゲートウェイの周囲のみ | ゲートウェイの同時接続数に制限され、通常は十数台 | まあまあ | 標準の暗号化あり | 中 |
| 自社開発の独自 Mesh | 中継可能 | 実装次第 | 自社製品同士のみ | すべて自前 | 非常に大きい |
| SIG Mesh | 中継可能、家全体をカバー | 数百ノードでも問題なし | ベンダーをまたいで相互運用可能 | 標準の暗号化とリプレイ対策 | 中、大半はチップの SDK 側 |
独自アドバタイズプロトコルは一番シンプルです。ゲートウェイが照明をつけたいときにコマンドをブロードキャストし、デバイスが聞き取って実行するだけ。ただし中継ができないので、ゲートウェイがリビングにあると、寝室の照明には届かないことがあります。ペアリング（プロビジョニング）も暗号化もリプレイ対策も、設計から後始末まで全部自分でやることになります。
BLE 直結は、スマホとワイヤレスイヤホンをつなぐのと同じ方式です。標準の暗号化が使えるのは利点ですが、ゲートウェイが同時に保持できる接続数には限りがあり、一般家庭にある数十個のスイッチや照明をさばくのはとても無理です。
自社開発の独自 Meshは、SIG Mesh を一から作り直すのと同じです。中継ストームの抑制、メッセージの重複排除、鍵の更新、シーケンス番号によるリプレイ防止と、どれも落とし穴だらけ。初期にはいくつものメーカーが独自 Mesh を作りましたが、その後ほとんどが SIG Mesh に移っています。
SIG Mesh は Bluetooth SIG が定めた標準規格です。デバイス同士が互いに中継して家じゅうをカバーでき、セキュリティの仕組みも最初から揃っています。そして何より大きいのは、標準の「デバイスモデル」が定義されていることです。
SIG Mesh の本当の価値：標準モデル
SIG Mesh では、スイッチや照明といったよくあるデバイスの記述方法と制御方法が決められています。
| SIG Mesh モデル | 対応するデバイス | Matter での対応 |
|---|---|---|
| Generic OnOff | スイッチ、プラグ | On/Off Light |
| Light Lightness | 調光ライト | Dimmable Light |
| Light CTL | 色温度ライト | Color Temperature Light |
| Light HSL | カラーライト | Extended Color Light |
この表は、ゲートウェイにとってものすごく重要です。Matter にもほぼ一対一で対応するデバイスタイプがあるので、変換がとても素直にできます。独自プロトコルだと、この変換ルールを自分で定義しなければならず、デバイスの種類を増やすたびに手直しが発生します。
標準モデルには、ほかにも二つ利点があります。
- ゲートウェイとデバイスで、別ベンダーのチップを使える。 うちのゲートウェイは Silicon Labs のモジュール、デバイスは Telink のチップです。両方が標準モデルに従っていればちゃんとつながるので、特定のチップメーカーに縛られません。
- ほかのエコシステムにも対応しやすい。 たとえば Xiaomi の Bluetooth Mesh は SIG Mesh がベースで、照明やスイッチの製品テンプレートも同じ標準モデルを使っています。将来 Xiaomi（米家）向けのバージョンを出すことになっても、アプリケーション側のコードの大部分は流用でき、入れ替えるのは主にプロビジョニングと認証の層だけで済みます。
SIG Mesh を選ぶと、何を払うことになるか
SIG Mesh にコストがないわけではありません。ただ、そのコストの大半はすでに誰かが肩代わりしてくれています。
プロトコル自体が複雑です。 プロビジョニングでは ECDH による鍵交換を行い、メッセージはネットワーク層とトランスポート層の二段階で暗号化され、さらにセグメント分割と再構築、シーケンス番号、IV Index もあります。ただしこれらはチップメーカーの SDK に入っていて、SIG のテストにも通過済みです。デバイス側は SDK をそのまま使い、自分で書かないでください。
ネットワークの規模には上限があります。 SIG Mesh は中継によるフラッディングでメッセージを転送するため、同じエリアのノードが増えるほど電波が混み合います。経験則では、一つのネットワークは数百ノード以内に収めたほうが安定します。業務用の照明は数千点になることもざらなので、フロアやエリアごとに分けて、複数のネットワークと複数のゲートウェイを用意する必要があります。
ゲートウェイが保持できるノード数にも限りがあります。 ここは見落としやすいポイントです。
- Telink 公式のゲートウェイファームウェアは、デフォルトで最大 200 ノードまで、リモートプロビジョニングを有効にすると 110 ノードです。4 連スイッチは 4 ではなく 1 ノードと数えます。
- Nordic の Zephyr スタックでゲートウェイを自作する場合、設定のデフォルトでは 8 ノードまでしか許可されず、リプレイ防止リストも 10 エントリしかありません。変更せずに使うと、11 台目のデバイスからのメッセージで問題が起きます。
家庭用途なら 200 ノードで十分ですが、こうした数字は設計の段階で必ず確認しておいてください。
一つのデバイスが属せるネットワークは一つだけです。 同じ照明を、うちのゲートウェイと Xiaomi のゲートウェイの両方で管理することはできません。両方のエコシステムに対応するなら、バージョンを二つ作って、それぞれプロビジョニングすることになります。
SIG 認証を取らなくても大丈夫？
冒頭の問いの二つ目の意味、つまり SIG Mesh は使うけれど SIG 認証は取らない場合に戻ります。
技術面ではまったく影響ありません。 デバイスは普通に動きますし、他社の SIG Mesh デバイスとも相互運用できます。リスクは別のところにあります。
| リスク | 説明 |
|---|---|
| 特許ライセンス | SIG の特許ライセンスは、認証を受けた製品だけが対象 |
| 販売チャネル | Amazon などのプラットフォームや大手小売店、海外ディストリビューターは、Bluetooth の認証番号の提示を求めてくることが多い |
| SIG による取り締まり | SIG は未認証の製品に通知を出し、認証の取得か販売停止を求める |
| 商標 | パッケージや宣伝に「Bluetooth」の文字やロゴを使えない |
よくある誤解がもう一つあります。独自プロトコルに戻しても、SIG 認証は省けません。 Bluetooth を使っている製品は、Mesh を使うかどうかにかかわらず、販売には認証が必要です。Mesh を使わなければ、Mesh 部分のテストが減るだけです。
朗報なのは、認証のたびにテストをやり直す必要はないという点です。チップメーカーがすでに認証を取っているプロトコルスタックをそのまま使い、認証済みの部分に手を加えなければ、相手の認証番号を引用して、宣言書の提出と費用の支払いだけで済みます。スイッチ、照明、ワイヤレススイッチの Bluetooth 部分がまったく同じなら、一つの設計にまとめて、費用も一回分で済ませられます。
もう一点、SRRC、CE、FCC といった無線認証は法規で義務づけられているもので、SIG 認証とは別物です。これを取らないと合法的に販売できません。認証の費用と順序については、別の記事で改めて書きます。
ゲートウェイ側では、Mesh をどこに置くか
デバイス側でチップの SDK を使うことに異論はないでしょう。ではゲートウェイ側の Mesh プロトコルスタックはどこに置くのか。これも実は三つのやり方があります。
| やり方 | 説明 | 長所と短所 |
|---|---|---|
| ゲートウェイのメインプログラムで Mesh を実装 | Linux ボード内蔵の Bluetooth で Mesh のアドバタイズを送受信 | チップが一つ減る。ただし数千行のプロトコルスタックを自作し、認証テストも自前でやる必要がある |
| Bluetooth モジュールをコプロセッサにする | Mesh スタックはモジュール内で動かし、メインプログラムはシリアル（UART）経由でコマンドを送る | スタックが完成品で、ベンダーの認証を引用できる。モジュールが一つ増える |
| モジュールは Bluetooth コントローラとしてだけ使う | モジュールは標準の HCI を動かし、Mesh は Linux 上（たとえば BlueZ）で動かす | モジュールのファームウェアは既製品で済む。ただし Windows では開発できない |
私たちが選んだのは二つ目、Bluetooth モジュールをコプロセッサにする方式です。Mesh のなかでも一番難しく、認証の裏づけが欲しい部分はチップメーカーに任せ、こちらはシリアルコマンドと Matter への変換だけを担当します。どのメーカーのモジュールがコプロセッサに向いているかは、次回の記事でじっくり書きます。
おわりに
最初の「SIG Mesh はやらなくていい？」に戻ると、こうなります。
- SIG Mesh プロトコルを使わない：できなくはないけれど、中継、標準のセキュリティ、ベンダー間の相互運用性を失います。しかも Bluetooth 認証は省けません。
- SIG Mesh は使うが認証は取らない：機能面には影響しませんが、輸出、EC モール、大手チャネルへの展開はほぼ避けて通れません。
私たちにとって SIG Mesh の一番の価値は、「標準」という言葉そのものではなく、Matter とほぼ一対一で対応するデバイスモデルがあることです。おかげでゲートウェイ層の変換がシンプルになり、チップも自由に選べます。
もしお手元のデバイスがまだ独自プロトコルで、SIG Mesh への移行を迷っているなら、あるいはすでに Bluetooth Mesh ゲートウェイを作っているなら、ぜひ気軽に話しかけてください：linktr.ee/weiyii