シングルホップのBLEタグは屋内で10-30メートルの通信範囲を持ちます。20,000 m2の倉庫では、全面カバーに数十台のゲートウェイが必要です。メッシュネットワーキングはこのモデルを転換させます：タグが互いにパケットをリレーし、ホップごとに範囲を拡張してゲートウェイに到達します。BLE Mesh 1.0（2017）はマネージドフラッドリレーを導入し、Mesh 1.1（2023）はディレクテッドフォワーディングを追加しました。資産追跡において、メッシュは3つの問題を解決します：ゲートウェイコストを比例させずにカバレッジを拡張、冗長パスによるフォールトトレランス、個別タグのオフライン時の段階的劣化です。
本記事では、電池駆動の資産タグの観点からメッシュネットワーキングを解剖します。プロトコル内部構造、リレーノード選択、消費電力計算、レイテンシとスループット、100〜5000+ノードのスケーラビリティ限界、大規模プロビジョニング、セキュリティアーキテクチャ、ベンダースタック比較をカバーします。
1. BLE Meshプロトコルスタック
BLE Meshはアドバタイジングチャネル（37/38/39、2402/2426/2480 MHz）上でコネクションレスPDUを使用して動作します。スタックは5層で構成されます：
| 層 | 機能 | 主要パラメータ |
|---|---|---|
| ベアラー | ADV/GATT上の転送 | ADV: 31バイトPDU, 3ch; GATT: プロキシ, 20バイトMTU |
| ネットワーク | アドレッシング, リレー, TTL | 29バイトPDU, 7ビットTTL, 24ビットSEQ, 15ビットユニキャスト |
| 下位トランスポート | セグメンテーション, 再構築 | 12バイトセグメント, 20秒ACK |
| 上位トランスポート | アプリキー暗号化 | アクセスペイロード暗号化, 4バイトtransMIC |
| アクセス | モデルメッセージ, オペコード | ベンダーモデル3バイト, SIGモデル2バイト |
ネットワークPDUはコンパクトです：1バイトTTL、3バイトSEQ（リプレイ保護用24ビットシーケンス）、2バイトSRC、2バイトDST、最大12バイトのトランスポートペイロード。PDU全体が128ビットネットワークキーで暗号化されます。リレーノードはアプリケーションペイロードを復号せずにパケットを転送します。
資産タグではADVベアラーが唯一の実用的な選択肢です。GATT接続は接続イベント中に3-5 mAを消費し、コインセルタグには持続不可能です。リレーメカニズムはADVベアラー上でのみ動作します。
2.マネージドフラッド：リレーの仕組み
BLE Meshはルーティングテーブルではなくマネージドフラッドリレーを使用します。リレー機能が有効な全ノードが、3つの制御に従って受信メッセージを再送信します：
- TTL（Time To Live）： 7ビットカウンタ、各ホップで減算。TTLが0に達するとメッセージ停止。倉庫では5-7、キャンパスでは10+。
- メッセージキャッシュ： 各ノードが(SRC, SEQ)でキー付けされた最近のメッセージをキャッシュ。最小2エントリ、実装では32-256エントリ。重複メッセージはサイレントドロップでループを防止。
- ネットワークキー一致： 既知のネットワークキーで暗号化されたメッセージのみリレー。
リレー再送タイミング：メッセージ受信後、3.5 ms（固定バックオフ）+ 0-10 msランダム遅延後に3つのアドバタイジングチャネルで再送。ホップあたり総遅延：約4-15 ms。
なぜマネージドフラッドがルーティングより優れているのか？ZigbeeやThreadはルーティングテーブルを使用し、メモリ（エントリあたり8-16バイト）、定期ルート更新（電力消費）、トポロジー変更時の収束時間（秒〜分）が必要です。モバイル資産タグではルーティングテーブル収束は非現実的です。マネージドフラッドは3つすべてを回避します。代償はメッセージ重複とチャネル利用率の上昇です。
3.資産タグのリレーノード選択
全タグがリレーすべきではありません。リレー機能は平均消費電流に200-500 uAを追加し、コインセルタグには致命的です。戦略：インフラノードをリレーに指定し、資産タグは非リレーパブリッシャーとして動作させます。
| 基準 | リレー適格 | 非リレー |
|---|---|---|
| 電源 | 商用電源または大容量バッテリー | CR2032, CR2477 |
| 移動性 | 固定インフラ | モバイル資産タグ |
| 位置 | 天井, 廊下, 入口 | 資産上のランダム |
| 電波環境 | 安定RSSI (> -70 dBm) | 移動による変動 |
実環境では20-30台の商用電源リレーノードでメッシュバックボーンを構成し、500-2000台の資産タグが非リレーノードとしてデータをパブリッシュします。リレー対タグ比はスケールに依存します：
| スケール | リレー | タグ | 比率 |
|---|---|---|---|
| 小（2,000 m2） | 5-8 | 50-100 | ~10% |
| 中（10,000 m2） | 15-25 | 300-500 | ~5% |
| 大（30,000 m2） | 40-60 | 1000-2000 | ~3% |
| キャンパス | 80-150 | 3000-5000 | ~2-3% |
4.消費電力：リレー vs 非リレー
非リレータグ（nRF52840）
| 状態 | 電流 | 間隔 | 平均 |
|---|---|---|---|
| スリープ（RAM保持） | 1.5 uA | – | 1.5 uA |
| RC32K + RTC | 0.2 uA | – | 0.2 uA |
| アドバタイズTX (+4 dBm) | 4.6 mA | 100 ms | 24.3 uA |
| アドバタイズRX | 5.2 mA | 100 ms | 23.4 uA |
| センサー読取（SHT40） | 0.9 mA | 10 s | 0.18 uA |
| 合計 | – | – | ~49.6 uA |
CR2032（175 mAh実効）、100 ms間隔：
寿命 = 175,000 uAh / 49.6 uA = 3,528時間 = 147日1秒間隔（低消費電力モード）：
合計平均 = 6.5 uA
寿命 = 175,000 / 6.5 = 26,923時間 = 3.1年リレータグ（nRF52840、連続スキャン）
| 状態 | 電流 | デューティ | 平均 |
|---|---|---|---|
| スリープ | 1.5 uA | – | 1.5 uA |
| スキャナRX（3ch） | 5.2 mA | 30% | 1,560 uA |
| リレーTX | 4.6 mA | 0.5% | 23 uA |
| 自身のアドバタイズ | 4.6 mA | 0.05% | 2.3 uA |
| 合計 | – | – | ~1,592 uA = 1.59 mA |
CR2032：175,000 / 1,592 = 110時間 = 4.6日（非現実的）
単4 x4（2,500 mAh）：2,500,000 / 1,592 = 1,571時間 = 65日
商用電源：無制限
結論：リレーノードには外部電源が必要です。コインセルタグはリレーを有効にすべきではありません。実環境では商用電源の専用リレーインフラを使用します。
5.メッセージレイテンシとスループット
ホップあたりレイテンシ
各リレーホップ：受信処理（1-3 ms）+ リレーバックオフ（3.5 + 0-10 ms）+ アドバタイズイベント（1.1 ms）= 5-16 ms標準、20 ms最悪。
5ホップ: 25-80 ms標準, 100-150 ms最悪
10ホップ: 50-160 ms標準, 200-300 ms最悪チャネル混雑
| 負荷(msgs/s) | 利用率 | 損失率 | 備考 |
|---|---|---|---|
| 50 | ~1% | <0.1% | クリーン |
| 200 | ~4% | 0.5-1% | 500ノードで正常 |
| 500 | ~10% | 2-5% | 限界接近 |
| 1000 | ~21% | 8-15% | 混雑 |
| 2000 | ~42% | 25-40% | 信頼性低下 |
500ノードメッシュ、5%リレー、TTL=7、1msg/10s：
オリジナル: 500 x 0.1 = 50 msgs/s
リレー増幅: x3.3
合計: 165 msgs/s, 利用率3.4%, 損失<0.5%1msg/s（リアルタイム追跡）：
合計: 1,650 msgs/s, 利用率34%, 損失15-25%（サブネット必須）6.スケーラビリティ分析
| ノード | リレー | TTL | 負荷 | 損失 | P95 | 評価 |
|---|---|---|---|---|---|---|
| 100 | 5 | 5 | 33/s | <0.1% | 40 ms | 優秀 |
| 500 | 25 | 7 | 165/s | 0.5% | 80 ms | 良好 |
| 1000 | 50 | 7 | 330/s | 2-3% | 120 ms | 許容 |
| 2000 | 100 | 10 | 660/s | 5-8% | 200 ms | 限界 |
| 5000 | 250 | 10 | 1650/s | 15-25% | 500 ms | サブネット必須 |
| 5000(5サブネット) | 250 | 7 | 330/サブ | 2-3% | 120 ms | 良好 |
サブネット戦略
- 地理的： 階/建物ごとにサブネット。入口にブリッジノード。
- 機能的： アプリごとにサブネット。クロストラフィック削減。
- 階層型： バックボーンサブネット（リレー専用）でタグサブネット接続。最スケーラブル。
各サブネットは32,767ユニキャストアドレスをサポート。実際の制約はアドレス空間ではなくチャネル利用率です。
7.Mesh 1.1ディレクテッドフォワーディング
Mesh 1.1（2023）はディレクテッドフォワーディングを導入：マネージドフラッドの代わりに事前計算パスでユニキャストメッセージを転送。パス上のノードのみがメッセージを転送します。
利点：ユニキャストトラフィックのチャネル利用率60-80%削減、サブネットなしで5000+ノード、レイテンシ20-30%削減。
トレードオフ：ルーティングテーブルメモリ（0.4-3.2 KB RAM）、パス収束（2-10秒）、Mesh 1.1スタック必要。
推奨：固定インフラリレーノードでディレクテッドフォワーディングを有効化、モバイルタグはマネージドフラッドを維持。
8.大規模プロビジョニング
プロビジョニングはユニキャストアドレス、ネットワークキー、アプリキー、IVインデックスを割り当てます。PB-ADV（3-8秒/デバイス）またはPB-GATT（10-20秒）を使用。
バッチプロビジョニング：
順次: 1000 x 5s = 83分
バッチ(10): 8.3分
バッチ(20): 4.2分実用上限：20並列セッション（チャネル混雑による失敗防止）。
アドレス割り当て
| 範囲 | 目的 | 数 |
|---|---|---|
| 0x0001-0x00FF | プロビジョナー | 255 |
| 0x0100-0x0FFF | リレー/インフラ | 3,840 |
| 0x1000-0x7EFF | 資産タグ | 28,160 |
| 0x7F00-0x7FFF | 予約 | 256 |
9.セキュリティアーキテクチャ
| キー | スコープ | 目的 |
|---|---|---|
| デバイスキー(128bit) | デバイスごと、プロビジョナーのみ | 設定、ノードリセット |
| ネットワークキー(128bit) | サブネットごと、全ノード | ネットワーク層暗号化 |
| アプリキー(128bit) | アプリごと | アクセス層、センサーデータ |
リレーノードはネットワークキーでメッセージを転送しますが、アプリケーションペイロードは復号できません。侵害されたリレーはネットワークアクセスを得るがセンサーデータは読めません。
IV更新
24ビットSEQがリプレイ保護を提供。IVインデックス（32ビット）がSEQ空間をリセットするために増分。最小間隔96時間。1msg/10sでSEQオーバーフローまで1,942日（5.3年）。資産タグではIV更新は稀です。
マルチテナント分離
複数のアプリキーが論理的分離を提供。各テナントが固有のアプリキーを持ち、同じネットワークキーとリレーインフラを共有してもタグは互いのデータを読めません。
10.BLE Mesh vs Thread vs Zigbee
| パラメータ | BLE Mesh | Thread | Zigbee 3.0 |
|---|---|---|---|
| PHY速度 | 1-2 Mbps | 250 kbps | 250 kbps |
| リレー | マネージドフラッド/ディレクテッド | RPLルーティング | ツリー+メッシュ |
| ルーティング状態 | 0 KB | 1-4 KB | 2-8 KB |
| 最大ノード | 1000-5000/サブネット | 250-500 | 250-500 |
| スリープ電流 | 1.5-5 uA | 3-10 uA | 2-5 uA |
| TX電流(+4dBm) | 4.6 mA | 8.0 mA | 8.0 mA |
| モバイルノード | 優秀 | 不良 | 不良 |
BLE Meshは資産タグで3点で優位：最低TX電流（1 Mbps PHY vs 250 kbps）、モバイルノードの即時適応（フラッド vs ルーティング収束）、ネイティブBLE無線互換性。
11.ゲートウェイ統合
メッシュゲートウェイはメッシュに参加し（ネットワークキー保持）、IP接続（Ethernet, Wi-Fi, セルラー）を持ちます。メッシュメッセージを受信しMQTT/HTTPSでクラウドに転送します。
2つの設計：(1) プロキシゲートウェイ（GATTプロキシサービス、アドホック電話アクセス用）；(2) 組み込みゲートウェイ（nRF52840 + Wi-Fi、24/7 MQTTブリッジ）。
ゲートウェイ密度：200-500メッシュノードあたり1台。複数ゲートウェイで冗長性、クラウドは(SRC, SEQ)で重複排除。
タグ --> リレー --> リレー --> ゲートウェイ --> MQTT --> ダッシュボード
エンドツーエンド: 200-800 ms12.ベンダーメッシュスタック比較
| ベンダー | SDK | SoC | Mesh 1.1 | RX電流 | 備考 |
|---|---|---|---|---|---|
| Nordic | NCS 2.5+ | nRF52840/nRF5340 | Yes | 5.2 mA | 最良ドキュメント、Zephyr |
| Silicon Labs | GSDK 4.3+ | EFR32BG22/BG24 | Yes | 4.8 mA | 低RX、BG24 96KB RAM |
| TI | BLE-STACK 5.x | CC2642R/CC2652R | 部分 | 5.9 mA | SimpleLink |
| Espressif | ESP-IDF | ESP32-C3/C6 | No(1.0) | 8-12 mA | Wi-Fi+BLEゲートウェイ |
資産タグではNordic nRF52840がデフォルト：成熟したスタック、最良ドキュメント、最低スリープ+スキャン電流。SiLabs EFR32BG24はディレクテッドフォワーディング用（大RAM）。ESP32-C3/C6はWi-Fiが必要なゲートウェイに最適。
13.コード例
リレー設定（nRF Connect SDK / Zephyr）
#include
static void configure_relay_node(uint16_t addr)
{
int err;
uint8_t count, intvl;
err = bt_mesh_cfg_relay_set(net_key_idx, addr,
BT_MESH_RELAY_ENABLED,
BT_MESH_TRANSMIT(1, 10),
&count, &intvl);
if (err) {
printk("Relay set failed: %d", err);
return;
}
err = bt_mesh_cfg_ttl_set(net_key_idx, addr, 7);
} センサーデータパブリッシュ
#define SENSOR_DATA_OP BT_MESH_MODEL_OP_2(0x12, 0x00)
struct __attribute__((packed)) sensor_payload {
int16_t temperature;
uint16_t humidity;
uint16_t battery_mv;
};
static int publish_sensor(int16_t temp, uint16_t hum, uint16_t batt)
{
struct sensor_payload p = { temp, hum, batt };
struct bt_mesh_msg_ctx ctx = {
.addr = 0xC001,
.send_ttl = 7,
.app_idx = app_key_idx,
};
BT_MESH_MODEL_BUF_DEFINE(buf, SENSOR_DATA_OP, sizeof(p));
bt_mesh_model_msg_init(&buf, SENSOR_DATA_OP);
net_buf_simple_add_mem(&buf, &p, sizeof(p));
return bt_mesh_model_publish(&sensor_model);
}Python: スケーラビリティ推定
class MeshScalability:
def __init__(self, n_nodes, relay_ratio, ttl, msg_interval_s, subnets=1):
self.n = n_nodes
self.relays = int(n_nodes * relay_ratio)
self.ttl = ttl
self.interval = msg_interval_s
self.subnets = subnets
self.capacity = 4800
def relay_amp(self):
return 1 + self.relays * 0.3 * min(self.ttl / 7.0, 1.0)
def total_load(self):
per_subnet = self.n / self.subnets
return (per_subnet / self.interval) * self.relay_amp()
def utilization(self):
return self.total_load() / self.capacity
def loss(self):
u = self.utilization()
if u < 0.04: return u * 0.1
elif u < 0.10: return 0.004 + (u - 0.04) * 0.3
elif u < 0.21: return 0.022 + (u - 0.10) * 0.5
else: return 0.077 + (u - 0.21) * 1.2
m = MeshScalability(500, 0.05, 7, 10)
print(f"Load: {m.total_load():.0f} msgs/s, Loss: {m.loss()*100:.1f}%")14.デバッグと診断
- メッシュスニッファ： Wireshark用nRF SnifferでBLE。TTL減算、リレー再送、キャッシュヒットを確認。
- ハートビート監視： リレーノードからハートビートパブリケーションを設定。TTLとRSSIでネットワーク健全性を可視化。
- リレー統計： ノードごとのリレー数、キャッシュヒット率、再送失敗を追跡。高ヒット率は良好なカバレッジ、低ヒット率はカバレッジギャップを示す。
- 一般的な問題： TTL枯渇（TTL増加かリレー追加）、キャッシュオーバーフロー（サイズ増加）、チャネル混雑（公開レート削減かサブネット）、プロビジョニングタイムアウト（バッチサイズ削減）。
15.生産設計チェックリスト
- [ ] リレー/非リレー比の決定（目標3-10%）
- [ ] 消費電力計算：リレーノードは外部電源必須
- [ ] TTL設定：単一建物5-7、キャンパス10+
- [ ] メッセージキャッシュ設定：最小32エントリ（192バイトRAM）
- [ ] 1000ノード超はサブネットアーキテクチャ計画
- [ ] バッチプロビジョニングワークフロー設計（最大20並列）
- [ ] マルチテナント分離用キー階層設定
- [ ] 公開間隔設定：監視10s、リアルタイム1s（サブネット必要）
- [ ] 混雑ストレステスト：想定トラフィックの2x注入で損失測定
- [ ] ゲートウェイ密度計画：200-500ノードあたり1台、冗長性あり
- [ ] ハートビート監視有効化
- [ ] 2000ノード超はMesh 1.1ディレクテッドフォワーディング検証
- [ ] モバイルタグ動作テスト：ゾーン間移動時のパス適応確認
- [ ] IV更新手順とキーリフレッシュスケジュール文書化
- [ ] ファームウェアOTA：バルクアップデート用メッシュモデル配布
結論
BLEメッシュネットワーキングは資産追跡をシングルホップ・ゲートウェイ飽和モデルからスケーラブルな自己修復ネットワークに変革します。主要な設計決定は：(1) リレーノードに商用電源インフラを使用、コインセルタグは不可；(2) リレーノード対タグ比を3-10%に設定；(3) 1000アクティブノード超はチャネル利用率監視とサブネット；(4) 2000ノード超はMesh 1.1ディレクテッドフォワーディング活用；(5) 生産展開用バッチプロビジョニングとゲートウェイ冗長性計画。
消費電力分析は厳しいものです：リレー有効CR2032タグは4.6日、非リレータグは1秒間隔で3.1年。この2400倍の違いがアーキテクチャを決定づけます：商用電源のインフラリレー、バッテリータグは非リレーパブリッシャー。この分離を正しく行えば、メッシュが残りを処理します。50台の倉庫タグでも5000台の工場キャンパスでも、これらの原則が実環境で動作するBLEタグメッシュネットワークの構築を支援します。