独自Mesh・SIG Mesh・Xiaomi Meshはどう違う？組網とエコシステムの関係

Bluetooth機器やゲートウェイを開発していると、いずれ「どのMeshを選ぶのか」という話になります。

半導体メーカーはMesh SDKを提供し、モジュールメーカーはSIG Mesh対応をうたい、企画側はXiaomi Homeに接続したいと言う。一方、開発チームには何年も運用してきた独自の広告パケット方式があるかもしれません。同じMeshという言葉でも、解決したい問題が違います。

以前のMatterゲートウェイの記事では、デバイス接続の観点から独自方式とSIG Meshを比較しました。このシリーズではBluetooth側を掘り下げます。最初に押さえたいのは、独自Mesh、SIG Mesh、Xiaomi Meshは、完全に横並びの三つのプロトコルではないということです。

独自Meshは組網方式を誰が設計・管理するか、SIG Meshは公開されたBluetoothのネットワーク標準を指します。Xiaomi Meshにはさらに、製品をXiaomi Homeに登録し、識別し、ゲートウェイやプラットフォームを通じて利用する仕組みが含まれます。この階層を分けると、選択が整理できます。

まず、その「Mesh」は何ができるのか

リビングのコントローラーから寝室の照明を操作するとします。近距離なら直接送信すれば済みますが、壁を何枚も挟むと届かない場合があります。そこで廊下の機器に中継してもらう。Meshでは、このようなノード間の協力に加え、アドレス、転送、ネットワーク管理を扱います。

一度のブロードキャストを多数の機器が受信できても、それだけでMeshになるわけではありません。 マルチホップ転送のない独自BLE広告方式は、あくまでブロードキャスト制御です。一部屋には適していても、電波の届かない場所まで自動的に範囲を広げることはできません。

逆に、製品にMeshと書かれていても、すべての機器が中継するとは限りません。役割、電源、ファームウェア設定によって異なります。比較の前に、直接接続なのか、ブロードキャストなのか、マルチホップなのかを確認しましょう。中継するなら、誰が担当し、同じメッセージの無限転送をどう防ぐのでしょうか。

独自Mesh：自由度と責任はセットになる

「独自Mesh」に統一仕様はありません。メーカーごとにパケット、アドレス、転送規則、参加手順が違っていても不思議ではありません。一つの実装の成績を、独自Mesh全体の評価にはできません。

機器、コントローラー、アプリを自社で管理するなら、用途に合わせた設計ができます。照明だけを扱う製品なら、初めから幅広い汎用モデルを実装する必要はないでしょう。既存製品との互換性を維持したい場合もあります。

ただし、中継を加えると考慮事項が増えます。

同じメッセージが複数の経路から届いたとき、どう重複を判定し、二重実行を防ぐか。
いつ転送を止め、どの機器を中継役にするか。
新しい機器をどう認証し、鍵を渡すか。削除した機器に操作権限が残らないか。
電源断と再起動の後も、リプレイ攻撃への防御をどう維持するか。
多数の機器が一斉に報告・応答するとき、無線トラフィックをどう抑えるか。

自分たちで実装することも、モジュールメーカーの完成した独自方式を採用することもできます。後者は開発量を減らしますが、依存先が増えます。ゲートウェイの交換、ファームウェア保守、プロトコル資料の入手が可能かを、先に確認する必要があります。

独自Meshだから必ず高速・低価格になるわけでも、必ず安全性が低いわけでもありません。実装、製品の範囲、保守能力次第です。「最初の一灯を何日で点灯できるか」だけを比べると、その後の数年を見落とします。

SIG Mesh：組網、安全性、機器の動作を共通化する

一般にSIG Meshとは、Bluetooth SIGが標準化したBluetooth Meshを指します。Bluetooth LEを基盤としますが、通常のBluetooth接続を数珠つなぎにしたものではありません。

標準はプロビジョニング、アドレス、メッセージ配送、セキュリティ、アプリケーション層の動作まで扱います。詳しくは公式のBluetooth Mesh Networking primerが参考になります。まず三点を押さえましょう。

ネットワーク参加の後に設定が必要

プロビジョニングは、未参加のデバイスを安全にネットワークへ追加し、アドレスと必要なセキュリティ情報を設定する手順です。その後、アプリケーション鍵、モデルとのバインド、Publish/Subscribeの関係などを設定します。

発見できた、追加できた、制御できた、は別の状態です。無線で見えていても、特定の命令を受け取る権限があるとは限りません。

中継できても、アプリケーションの内容が読めるとは限らない

SIG Meshはネットワーク鍵NetKeyとアプリケーション鍵AppKeyを分けています。NetKeyは対応するサブネットのネットワーク層処理への参加に使い、AppKeyはアプリケーションメッセージを保護します。

そのため、すべての用途の操作権限を持たなくても中継を担当できます。照明メッセージを運べることと、その照明を操作できることは別です。ただし、鍵の設定、保存、更新は製品側で正しく実装・運用する必要があります。標準の採用が実装ミスまで消すわけではありません。

モデルが「点灯」の意味を共有する

Generic OnOff、Light Lightness、Light CTLなどは、オン・オフ、明るさ、色温度に関係する共通の動作を定義します。単にバイト列が届くだけでなく、双方が共通の規則でメッセージや状態を理解できます。

標準外の機能にはVendor Modelも使えます。アプリケーションに独自命令があるからといって、下位のMeshネットワークまで独自方式とは限りません。 標準のネットワークとセキュリティを使いながら、メーカー固有機能を追加できます。「独自」がどの層を指すのかを確認してください。

SIG Meshなら購入後すぐ相互接続できるとは限らない

以前の記事では、標準モデルがメーカーをまたぐ接続に役立つと説明しました。その価値を実現するには、具体的な製品能力と設定が必要です。

SIG Mesh対応の照明が二つあっても、一方は標準モデルでオン・オフを提供し、もう一方はVendor Modelで特殊効果も提供しているかもしれません。汎用コントローラーで基本操作ができても、すべての効果を理解できるとは限りません。

また、自分が管理するネットワークへ参加させ、鍵、モデル、購読先を設定するための対応手段が必要です。標準を使うことは、任意の第三者へ全管理機能を開放する義務を意味しません。

確認したいこと	確認する内容
ネットワークに参加できるか	プロビジョニング方式、管理権限、鍵、必要なノード機能
目的の操作を実行できるか	モデル、メッセージ、状態、設定の一致
目的のプラットフォームで長期利用できるか	接続手順、機器ID、機能変換、ファームウェア保守、対応範囲

SIGの入門文書も、任意機能や設定の自由度と相互運用性の関係を説明し、動作をさらに規定するBluetooth NLCデバイスプロファイルを紹介しています。標準は共通基盤であり、製品の互換性は目的の機能ごとに検証します。

Xiaomi MeshにはXiaomi Homeへの接続体系も含まれる

Xiaomi MeshをSIG Meshと無関係な無線プロトコルと考えると、関係を見誤ります。小米の公開Bluetooth Mesh接続開発ガイドは、SIGのモデル・メッセージと、サービス・属性・操作を記述するMIoT Specを区別し、ゲートウェイが変換すると説明しています。

色温度照明の例には、Generic OnOff ServerやLight Lightness Serverと、小米固有のモデルが同居しています。標準Meshとエコシステムの拡張は、一つの製品に共存できます。

ただしこれは古いガイドです。掲載されたチップ一覧や操作手順を現在の開発条件として扱うべきではありません。現行のBLE Mesh基礎知識でもSpecとMeshの変換が説明され、製品テンプレート、ファームウェア設定、属性報告の要件が示されています。

SIG Meshを使うこととXiaomi Homeへ接続することは、別々に達成する目標です。前者は技術基盤、後者は製品ID、プラットフォーム上の定義、プロビジョニングとバインド、ゲートウェイ対応、機能表示まで含みます。

普通のSIG Mesh機器の名前を変えても、Xiaomi Homeに自動表示されるわけではありません。 Xiaomi Home対応照明を買っただけで、自作の汎用ゲートウェイから全機能を引き継げるとも限りません。

Xiaomi Home版を作るなら、チップ選定やアプリケーション実装より先に、対象カテゴリの現行対応方式、SDKの入手条件、対象ゲートウェイの機能を確認しましょう。製品設計を左右する条件であり、発売直前にインターフェースを一つ追加すれば済む話とは限りません。

「ゲートウェイ不要」と「インターネット不要」は別の質問

適切に設定されたSIG Meshノードは、すべてのスイッチ操作をクラウドへ送らなくてもローカル通信できます。ただし、その機能がノードとローカル設定に実装されていることが前提です。

製品では制御経路を確認します。小米の現行文書は、遠隔操作にはMeshゲートウェイが必要で、ゲートウェイなしの利用に向けてBluetooth直接制御を開発できると説明しています。「開発できる」は、販売済みの全機種が同じ直接制御を備えるという意味ではありません。

同じ文書には、低消費電力機器以外は中継できるが、説明対象の方式では機器同士で制御できないともあります。中継は配送の機能であり、制御にはアプリケーション機能が必要です。 これを小米の全製品・全バージョンに永続的な制約として広げるべきではありません。

私は次の三つを別々に試します。

ルーター、ゲートウェイ、機器の電源を保ったままインターネットだけ切る。ローカル操作や自動化は続くか。
ゲートウェイを停止する。物理スイッチ、機器間連携、近距離のスマートフォン操作はどこまで残るか。
機器とゲートウェイを再起動する。状態と制御関係は正常に復元されるか。

それぞれ別の障害です。一度オフラインで点灯できても、システム全体がゲートウェイやクラウドに依存しない証明にはなりません。

ノード数と遅延だけで順位を付けない

収容数と応答速度は重要ですが、Meshという名称だけでは判断できません。

SIG Meshの代表的な転送方式はManaged Floodingです。全機器が無条件で繰り返すのではなく、中継設定、TTL、メッセージキャッシュなどで制御します。Mesh 1.1には、経路に関する仕組みで効率を改善するDirected Forwardingが加わりました。実際の対応と有効化はスタックや設定次第です。

電池駆動機器を常時使える中継器と考えるのも適切ではありません。Low PowerとFriendの仕組みでは、Friendがメッセージを一時保存し、低消費電力ノードの連続受信を減らせます。省電力化は到着タイミングにも影響するため、電池寿命と操作要件を一緒に考えます。

孤立した最大ノード数より、配置、報告頻度、中継数、再送設定、業務負荷が重要です。少数の機器による高頻度報告と、多数の照明への時折のグループ指令では、ネットワークへの負荷が違います。

今後は配置、メッセージ、評価指標を具体化して性能を扱います。共通の試験条件なしに、どれが速い、安定しているとは順位付けしません。

選定では、何を自分で管理したいかを決める

方向	主な目的	責任・確認事項
独自Mesh	製品に合わせた通信と組網	品質、安全性、保守、供給元への依存、他方式との接続費用
SIG Mesh	共通のネットワーク、安全性、機器モデル	SDKの能力、モデル一致、参加管理、設定、相互運用試験
Xiaomi Mesh接続方式	対応機器をXiaomi Homeで利用する	現行手順、製品定義、SDK、識別とバインド、ゲートウェイ対応

三者択一とは限りません。SIG Meshを使って米家の条件を実装する製品も、SIG Meshでゲートウェイとアプリを独自管理する製品も、既存互換性のため私有方式を維持する製品もあります。

私たちのMesh→Matterゲートウェイでは、標準モデルでBluetooth側の動作を明確にし、Matterの機器と状態へ変換できる点を重視しています。ただし、機能範囲、状態変化、異常復旧の実装は必要です。似たモデル名を見つけただけではブリッジは完成しません。

既製のXiaomi Home機器を接続するなら、まず許可された接続方法と機能を確認します。機器側ファームウェアも作るなら、モデル、鍵管理、ゲートウェイAPIをまとめて設計できます。この出発点の違いは、作業量を大きく変えます。

次回は、独自のBluetooth広告から本当のマルチホップMeshへ進むには何を追加するのか。重複、転送範囲、確認応答、安全性を整理してから、自作する価値を考えます。

Bluetooth機器、照明、ゲートウェイに取り組んでいる方は、こちらからご連絡ください。機器数、給電方式、接続先のプラットフォームが分かると、具体的に議論できます。