SmartMesh IPアプリケーションノート

SmartMesh IP アプリケーション
ノート
SmartMesh IP アプリケーションノート
1/140
目次
1 改訂履歴 ............................................................................................................................................................ 7
2 アプリケーションノートの一覧 .............................................................................................................................. 8
3 アプリケーションノート：ネットワーク性能とデバイス性能の評価方法 ...................................................................... 9
3.1
はじめに .................................................................................................................................................. 9
3.2
参加動作.................................................................................................................................................. 9
3.3
3.4
3.2.1
探索時間と平均電流の間のトレードオフ....................................................................................... 10
3.2.2
参加時間の測定 ......................................................................................................................... 11
3.2.3
参加時の下り帯域幅の影響 ......................................................................................................... 12
3.2.4
ネットワーク形成と単一モートの参加 ........................................................................................... 15
3.2.5
失ったモートからの回復時間の測定............................................................................................. 15
待ち時間 ................................................................................................................................................ 17
3.3.1
待ち時間の測定 ......................................................................................................................... 17
3.3.2
スター型トポロジとの比較 .......................................................................................................... 18
3.3.3
消費電力と待ち時間の間のトレードオフ ....................................................................................... 19
3.3.4
往復の待ち時間 ......................................................................................................................... 20
チャネル・ホッピングと範囲..................................................................................................................... 21
3.4.1
単一チャネル測定での無線テスト（radiotest）の使用 .................................................................... 21
3.4.2
到達距離テスト .......................................................................................................................... 22
3.4.3
ブラックリスト登録 ..................................................................................................................... 23
3.5
電力 ...................................................................................................................................................... 24
3.6
メッシュの動作 ....................................................................................................................................... 25
3.7
3.6.1
メッシュのテスト ........................................................................................................................ 25
3.6.2
メッシュ・ポリシーの変更............................................................................................................ 26
データ・レート........................................................................................................................................ 26
4 アプリケーションノート：サブスクライブ API でのフィルタの使用法 ........................................................................ 27
4.1
サブスクライブ・フィルタ......................................................................................................................... 27
4.2
アクノリッジ制御か非アクノリッジ制御か ? ................................................................................................ 27
5 アプリケーションノート：SmartMesh IP ネットワークの健全性のモニタ................................................................. 28
5.1
5.2
健全性レポート ...................................................................................................................................... 28
5.1.1
NeighborsHR ........................................................................................................................... 28
5.1.2
DeviceHR ................................................................................................................................. 29
周期的な API 呼び出し ............................................................................................................................ 29
5.2.1
5.3
5.4
getMoteConfig ......................................................................................................................... 29
5.2.2
getMoteInfo ............................................................................................................................. 29
5.2.3
getNextPathInfo ....................................................................................................................... 30
テスト.................................................................................................................................................... 30
5.3.1
AP のみの場合 ........................................................................................................................... 30
5.3.2
全モートにわたる繰り返し........................................................................................................... 30
5.3.3
全経路にわたる繰り返し ............................................................................................................. 31
5.3.4
ネットワークの検査 .................................................................................................................... 32
グラフ化 ................................................................................................................................................ 32
6 アプリケーションノート：SmartMesh IP のデータ発行 ......................................................................................... 33
6.1
要求パケットと応答パケットの書式 ........................................................................................................... 33
6.1.1
ヘッダ ....................................................................................................................................... 33
SmartMesh IP アプリケーションノート
2/140
6.1.2
フラグ・バイト............................................................................................................................ 34
6.2
基本手順................................................................................................................................................ 34
6.3
次の段階................................................................................................................................................ 39
7 アプリケーションノート：LTC5800-IPR ベースのネットワークでの通知の管理 ........................................................ 40
7.1
状態マシンの通知................................................................................................................................... 40
8 アプリケーションノート：短期のデータ・バーストに備えたネットワークの構成 ........................................................ 41
8.1
はじめに ................................................................................................................................................ 41
8.1.1
ネットワーク要件とサービス要求 ................................................................................................. 41
8.2
ネットワーク 1：基本構成 ......................................................................................................................... 41
8.3
ネットワーク 2：より長い下りスロットフレーム ........................................................................................... 43
8.4
ネットワーク 3：高い消費電力、短い待ち時間 ............................................................................................ 44
8.5
ネットワーク 4：バックボーンの例............................................................................................................. 45
8.6
ネットワーク 5：スター型ネットワーク ....................................................................................................... 46
8.7
通知の管理 ............................................................................................................................................ 47
9 アプリケーションノート：IP ネットワークでの冗長性確保の方法 ............................................................................. 48
10 アプリケーションノート：通電バックボーンを使用した待ち時間の改善 ................................................................... 49
10.1
はじめに ................................................................................................................................................ 49
10.1.1 全般的な目的 ............................................................................................................................ 49
10.1.2 上りバックボーンで RX を有効化する設定 ..................................................................................... 50
10.2
アプリケーション 1：低待ち時間アラーム................................................................................................... 50
10.3
アプリケーション 2：呼び出しと応答 ......................................................................................................... 51
10.4
アプリケーション 3：すべての低トラフィック・ネットワークでの短い待ち時間 ................................................ 52
10.5
バックボーンの不適切な使用 1：専用リンクの置き換え .............................................................................. 52
10.6
バックボーンの不適切な使用 2：トラフィックの多いネットワーク ................................................................. 53
11 アプリケーションノート：メッシュ内メッシュの構築 ............................................................................................... 54
11.1
はじめに ................................................................................................................................................ 54
11.1.1 トンネリング .............................................................................................................................. 56
11.1.2 バックホール・ブリッジ ............................................................................................................... 56
11.1.3 バックホール・アプリケーションとホスト・アプリケーション ............................................................ 57
11.2
トンネリング・プロトコル......................................................................................................................... 58
11.2.1 下りデータ ................................................................................................................................. 59
11.2.2 上りデータ ................................................................................................................................. 60
11.2.3 要求 .......................................................................................................................................... 60
11.2.4 応答 .......................................................................................................................................... 61
11.3
リモート・プロシージャのインタフェース ................................................................................................... 62
11.3.1 getOperationalMotes プロシージャ............................................................................................ 63
11.4
帯域幅に関する検討事項......................................................................................................................... 64
11.5
その他 ................................................................................................................................................... 64
12 アプリケーションノート：深い IP ネットワークの構築 ............................................................................................. 65
12.1
はじめに ................................................................................................................................................ 65
12.2
配置のガイドライン ................................................................................................................................ 65
12.3
範囲の割り出し....................................................................................................................................... 66
12.4
モートとマネージャのバージョンおよび設定 .............................................................................................. 66
12.5
リンクの計算 .......................................................................................................................................... 66
12.6
待ち時間の推定 ...................................................................................................................................... 67
12.7
無線通信プログラミング .......................................................................................................................... 68
SmartMesh IP アプリケーションノート
3/140
13 アプリケーションノート：重複ネットワーク ........................................................................................................... 69
13.1
はじめに ................................................................................................................................................ 69
13.2
方法 ...................................................................................................................................................... 69
13.3
結果 ...................................................................................................................................................... 69
13.4
結論 ...................................................................................................................................................... 72
14 アプリケーションノート：配置の計画 ................................................................................................................... 73
14.1
範囲の推定 ............................................................................................................................................ 73
14.2
配置の綿密な計画策定 ........................................................................................................................... 73
14.3
電力と待ち時間の推定 ............................................................................................................................ 74
15 アプリケーションノート：ネットワーク健全性の予測 .............................................................................................. 75
15.1
目的 ...................................................................................................................................................... 75
15.2
概要 ...................................................................................................................................................... 75
15.3
ネットワークの構成要素は順調に機能しているか？ .................................................................................... 75
15.4
ネットワークの構成要素は順調に機能しているか？ .................................................................................... 76
16 アプリケーションノート：よくある問題と解決策..................................................................................................... 77
16.1
はじめに ................................................................................................................................................ 77
16.2
参加モートなし ....................................................................................................................................... 78
16.3
まとまった数のモートが参加しない .......................................................................................................... 78
16.4
1 つのモートが参加しない ....................................................................................................................... 78
16.5
1 つのモートによる離脱と再参加の繰り返し .............................................................................................. 78
16.6
動作範囲内のデバイスの経路安定性が低い .............................................................................................. 79
16.7
中継器を設置する必要があるが、すでにモートが最大数に達している ......................................................... 79
16.8
データ待ち時間が予想より長い ................................................................................................................ 79
16.9
ネットワークが最適に見えない経路を使用している .................................................................................... 79
17 アプリケーションノート：プロビジョニング係数の変更によるマネージャ・スループットの増加 .................................. 80
17.1
はじめに ................................................................................................................................................ 80
17.2
プロビジョニングの変更：IP .................................................................................................................... 80
17.3
プロビジョニングの変更：WirelessHART................................................................................................. 81
18 アプリケーションノート：輻輳したネットワークのデバッグ ..................................................................................... 82
18.1
はじめに ................................................................................................................................................ 82
18.2
サービスの順守 ...................................................................................................................................... 82
18.3
可用性の推定 ......................................................................................................................................... 82
18.4
輻輳の識別 ............................................................................................................................................ 83
18.5
帯域幅モデル ......................................................................................................................................... 84
18.6
輻輳の緩和 ............................................................................................................................................ 85
19 アプリケーションノート：干渉の影響の特定および軽減 ......................................................................................... 86
19.1
はじめに ................................................................................................................................................ 86
19.2
RSSI と経路安定性の確認 ....................................................................................................................... 87
19.3
モートの待ち時間、キューの長さ、および信頼性の確認 ............................................................................. 88
19.4
軽減 ...................................................................................................................................................... 89
20 アプリケーションノート：正確なタイムスタンプの取得 .......................................................................................... 90
20.1
時間 ...................................................................................................................................................... 90
20.2
参考文献................................................................................................................................................ 90
20.3
IP Eterna ベース・システム ..................................................................................................................... 90
20.4
緩いタイミング ....................................................................................................................................... 92
20.5
正確なタイミング .................................................................................................................................... 92
SmartMesh IP アプリケーションノート
4/140
20.6
最も高精度なタイミング .......................................................................................................................... 92
20.7
IP 不確実性の定量化 .............................................................................................................................. 93
20.8
WirelessHART（Linux SBC ベース）システム ........................................................................................... 93
20.9
WirelessHART 不確実性の定量化 ........................................................................................................... 94
20.10 同期イベント .......................................................................................................................................... 94
21 アプリケーションノート：複数のマネージャを使用した大規模ネットワークの構築 .................................................... 95
21.1
大規模な配置 ......................................................................................................................................... 95
21.2
RF の制限事項 ....................................................................................................................................... 95
21.3
理想的な配置のガイドライン ................................................................................................................... 96
21.4
大規模 IP ネットワーク - さまざまなネットワーク ID と共通の参加鍵 ............................................................. 97
21.5
大規模 WirelessHART ネットワーク - さまざまな ID と共有 ACL ................................................................. 97
21.6
複数マネージャの配置に関する危険 ......................................................................................................... 98
21.7
ネットワーク ID と参加鍵の無線による設定 ................................................................................................ 99
22 アプリケーションノート：SmartMesh Power and Performance Estimator の使用 .............................................. 100
22.1
はじめに .............................................................................................................................................. 100
22.2
問題：バッテリ寿命はどれくらいか？....................................................................................................... 100
22.3
Power and Performance Estimator .................................................................................................... 100
22.4
Q1：報告率が電力に及ぼす影響は？...................................................................................................... 101
22.5
Q2：ルーティング・コストはどれくらいか？.............................................................................................. 102
22.6
Q3：リトライにかかるコストはどれくらいか？ .......................................................................................... 103
22.7
Q4：パケット集約で電力を節減できるか？ .............................................................................................. 104
22.8
Q5：ネットワークの深さが電力に及ぼす影響は？ .................................................................................... 105
22.9
Q6：IP ネットワークでの通知を停止して電力を節減？ .............................................................................. 106
23 アプリケーションノート：移動するモートに予想されること................................................................................... 107
23.1
1 モートの移動 ..................................................................................................................................... 107
23.2
SmartMesh WirelessHART ................................................................................................................. 107
23.3
SmartMesh IP .................................................................................................................................... 107
23.4
SmartMesh WirelessHART と SmartMesh IP との違いのまとめ ............................................................. 108
24 アプリケーションノート：ネットワーク間でのモートの移行 ................................................................................... 109
24.1
モートの移行 ........................................................................................................................................ 109
24.2
手順 .................................................................................................................................................... 109
24.3
セキュリティ ......................................................................................................................................... 110
25 アプリケーションノート：境界内データ待ち時間に関するネットワークの構成 ........................................................ 111
25.1
プロビジョニングの増加 ........................................................................................................................ 111
25.2
制限事項.............................................................................................................................................. 111
25.3
プロビジョニング .................................................................................................................................. 111
25.4
プロビジョニングの変更 ........................................................................................................................ 112
25.5
電力の増加 .......................................................................................................................................... 112
26 アプリケーションノート：ネットワークの共存 ...................................................................................................... 113
26.1
重複ネットワーク .................................................................................................................................. 113
26.2
単一ネットワークでの衝突 ..................................................................................................................... 113
26.3
周期的な衝突の回避 ............................................................................................................................. 113
26.3.1 SmartMesh WirelessHART .................................................................................................... 114
26.3.2 SmartMesh IP ........................................................................................................................ 115
26.3.3 WirelessHART の混在環境....................................................................................................... 115
26.4
クリア・チャネル評価 ............................................................................................................................ 115
SmartMesh IP アプリケーションノート
5/140
26.5
実験結果.............................................................................................................................................. 115
27 アプリケーションノート：ジョイン・デューティ・サイクルの選択方法..................................................................... 116
27.1
背景 - ジョイン・デューティ・サイクルとは？............................................................................................ 116
27.2
使用すべきジョイン・デューティ・サイクルは？ ........................................................................................ 116
27.3
センサ・アプリケーションの状態マシン ................................................................................................... 117
27.4
まとめ.................................................................................................................................................. 118
28 アプリケーションノート：SmartMesh のセキュリティ .......................................................................................... 119
28.1
はじめに .............................................................................................................................................. 119
28.2
目標 .................................................................................................................................................... 119
28.3
SmartMesh のセキュリティ機能 ............................................................................................................ 119
28.4
暗号化と認証 ....................................................................................................................................... 120
28.4.1 キーイング・モデル .................................................................................................................. 120
28.4.2 参加に関するマネージャのセキュリティ・ポリシー ....................................................................... 121
28.4.3 鍵管理 .................................................................................................................................... 121
28.4.4 A CCM* に関する注意 .............................................................................................................. 122
29 アプリケーションノート：TestRadio コマンドの使用 ........................................................................................... 123
29.1
testRadio コマンド ............................................................................................................................... 123
29.2
セットアップ ......................................................................................................................................... 123
29.3
実験の実施 .......................................................................................................................................... 123
29.4
結果の解釈 .......................................................................................................................................... 124
30 アプリケーションノート：ピーク時の平均電流を制限するための最良実施例 ......................................................... 125
31 アプリケーションノート：パイロット・ネットワーク評価の方法.............................................................................. 126
31.1
まとめ.................................................................................................................................................. 126
31.2
SmartMesh スタータ・キットと SDK ...................................................................................................... 126
31.3
評価方法.............................................................................................................................................. 126
31.4
ステップ 1：SDK の PC へのインストール ................................................................................................ 127
31.5
ステップ 2：SDK のモートおよびマネージャのパイロット・ネットワークの配置 ........................................... 127
31.6
ステップ 3：特定のデータ・レートに対応したモートの構成 ....................................................................... 128
31.7
ステップ 4：統計情報の収集 .................................................................................................................. 130
31.8
ステップ 5：データの分析 ...................................................................................................................... 132
31.8.1 WirelessHart スナップショット・ログ.......................................................................................... 132
31.8.2 ログ・ファイルの解釈と分析 ...................................................................................................... 134
31.8.3 隣接モートの安定性分析 .......................................................................................................... 135
32 アプリケーションノート：パケット ID の概要と必要な理由 .................................................................................... 136
32.1
適用範囲.............................................................................................................................................. 136
32.2
パケット ID とは？ .................................................................................................................................. 136
32.3
2 つのパケット ID の存在........................................................................................................................ 137
32.4
同期ビット ........................................................................................................................................... 137
32.5
パケット ID の無視 ................................................................................................................................. 138
SmartMesh IP アプリケーションノート
6/140
1 改訂履歴
リビジョン
日付
概要
1
2013/03/18
最初のリリース
2
2013/07/18 「パケット ID の概要と必要な理由」アプリケーションノートを追加
3
2013/10/22
4
2014/01/30 「重複ネットワーク」アプリケーションノートを追加
小幅な修正
「メッシュ内メッシュの構築」アプリケーションノートを修正してサンプル実装を反映
SmartMesh IP アプリケーションノート
7/140
2 アプリケーションノートの一覧
本書では、SmartMesh IP 製品ファミリに関する一連のアプリケーションノートについて記載しています。
• ネットワーク性能とデバイス性能の評価方法 - 性能測定基準についてホストを測定する方法。
• サブスクライブ API でのフィルタの使用法 - マネージャ通知をモニタする方法。
• SmartMesh IP ネットワークの健全性のモニタ - ネットワークが良好に機能していることを確認する自動検査。
• SmartMesh IP のデータ発行 - モートの API を使用してデータを送信する方法の具体的な説明。
• LTC5800-IPR ベースのネットワークでの通知の管理 - 通知をオフにすることによって電力を節約する状態マシン。
• 短期のデータ・バーストに備えたネットワークの構成 - モートが突然いくつかのパケットをキューに入れる可能性が
ある場合の低消費電力の解決策の方針。
• IP ネットワークでの冗長性確保の方法 - 使用するデバイス数の増加によるさまざまなレベルの冗長性の確保。
• 通電バックボーンを使用した待ち時間の改善 - いくつかのバックボーンの使用事例の説明。
• メッシュ内メッシュの構築 - 階層モデルを使用して構築した超大規模ネットワーク。
• 深い IP ネットワークの構築 - 最大 32 ホップの深さのネットワークを使用するための設定。
• 重複ネットワーク - 同じ無線空間に安全に共存できるモート数の計算。
以下のアプリケーションノートは、SmartMesh IP ファミリと WirelessHART ファミリの両方に当てはまります。製品間の違
いがある場合は、違いが強調されます。
• 配置の計画 - ネットワークを配置する前の概略の検討。
• ネットワーク健全性の予測 - 初期の配置後の評価のヒント。
• よくある問題と解決策 - トラブルシューティングに関する一般的なアドバイス。
• プロビジョニング係数の変更によるマネージャ・スループットの増加 - 帯域幅をモートごとに低くすることにより、安
定性の高い状態での総トラフィック増加をサポート。
• 輻輳したネットワークのデバッグ - モート・キューが満杯の場合のネットワーク動作に対する影響の理解と、そのよう
な状況の改善に関するヒント。
• 干渉の影響の特定および軽減 - 干渉に関係がある問題を見つけるためのネットワーク統計情報のグラフ表現。
• 正確なタイムスタンプの取得 - ネットワーク時刻の同期を使用してパケットに正しいタイムスタンプをする方法。
• 複数のマネージャを使用した大規模ネットワークの構築 - 1 つのマネージャのモート限度を超える配置に関する検討
事項。
• SmartMesh Power and Performance Estimator の使用 - さまざまなネットワークで電力および待ち時間を予測す
るのにスプレッドシートを使用する場合の例。
• 移動するモートに予想されること - 同じネットワーク内の異なる場所へ移動するモートの動作に関する詳細。
• ネットワーク間でのモートの移行 - さまざまなネットワーク間でモートを移動する方法に関する詳細。
• 境界内データ待ち時間に関するネットワークの構成 - ネットワークへの帯域幅の追加によるパケット待ち時間の短縮。
• ネットワークの共存 - ネットワークの共存 - 複数のネットワークが同じ無線空間で動作できる機能。
• ジョイン・デューティ・サイクルの選択方法 - 電力と参加速度とのトレードオフに関する検討。
• SmartMesh のセキュリティ - すべての SmartMesh ネットワークで使用されるセキュリティ機能の説明。
• TestRadio コマンドの使用 - API を使用して無線性能のテストまたは認証を行う方法の説明。
• ピーク時の平均電流を制限するための最良実施例 - フラッシュの起動または書き込み時に平均電流を少量に維持す
るために従うガイドライン。
• パイロット・ネットワーク評価の方法 - パイロット・ネットワークの配置および統計情報収集の概要。
• パケット ID の概要と必要な理由 - センサ・プロセッサによる信頼性の高い呼び出しと応答を実現するために使用さ
れる単一ビットに関する詳細。
SmartMesh IP アプリケーションノート
8/140
3 アプリケーションノート：ネットワーク性能とデバイス性能の
評価方法
3.1
はじめに
SmartMesh IP スタータ・キットを入手したら、まず最初に何をすればいいでしょうか？このアプリケーションノートでは、
SmartMesh ネットワークの特定の性能を評価するために実行できるいくつかのテストについて説明します。マネージャおよ
びモートと通信するために、事前に、SmartMesh IP SDK Python ツールと必要な FTDIドライバをインストールしておいて
ください。また、
「Manager and Mote CLI and API」の資料もお手元にご用意ください。
最 初 に することは、
「SmartMesh IP Manager CLI Guide」の「Introduction」に 説 明されているように、 マ ネ ージャ
（DC9001）に接続し、マネージャの CLI にログインすることです。
> login user
モートの CLI にアクセスして構成するために、 DC9006 Eterna インタフェース・カードを 1 つ以上の DC9003A-B モートに
接続することも必要になります。
3.2
参加動作
モートが参加する速さはどのくらいでしょうか。モートの参加速度は、以下の 6 つの条件の関数です。
• 通知送信率 - ネットワーク内のモートが通知を送信する割合。ユーザーはモートの数を変える以外にこれを制御する
方法はありません。あるいは、マネージャで明示的にオフにします。
• ジョイン・デューティ・サイクル - 探索モートがネットワークの検出に費やす時間とスリープ状態の時間との比
• モート加入ステートマシンのタイムアウト - SmartMesh IP ではユーザーはこれらのタイムアウトを変更できません。
• 下り帯域幅 - モートがネットワークに同期された状態から稼働状態（つまり、データを送信可能な状態）にどの程度
素早く移行できるかに影響します。
• モートの数 - 限られたリソースを求めて多くのモートが同時に参加しようとすると、衝突により参加の速度が低下し
ます。
• 経路安定性 - ユーザーがほとんどあるいはまったく制御できないもの。経路安定性は、1組のモート間での送信パケッ
ト数に対する（アクノリッジを返された）成功パケット数の比率です。
参加処理は、探索、同期、メッセージ交換という 3 つの段階に分れます。
• 探索時間は、通知送信率、経路安定性、およびモートジョイン・デューティ・サイクルによって決まります。この時間
はジョイン・デューティ・サイクルに大きく依存し、数十秒から数十分になることがあります。
• 同期はモートステートマシンのタイムアウトによって決まります。この時間は SmartMesh IP ではわずか数秒です。
• メッセージ交換は下り帯域幅と（下り帯域幅を求めて競合する）モートの数によって決まります。これはモート当たり
最小で約 10 秒で、さらに低速化する可能性があります。
SmartMesh IP アプリケーションノート
9/140
したがって、たとえばネットワークに素早く参加するには、ジョイン・デューティ・サイクルを最大に設定したほうが良いよう
に思えます。しかし、そうすると多くのモートが下り帯域幅を求めて競合することになる可能性があり、ネットワークはより低
めの設定値にすることで素早く形成できます。以下の実験では、探索段階およびメッセージ交換段階を制御するための「調
整つまみ」を調べます。
3.2.1
探索時間と平均電流の間のトレードオフ
同期していないモートはマネージャやその他のモートからの通知を受信して、ネットワークと同期しようとします。受信に
費やす時間とスリープ状態の時間との比をジョイン・デューティ・サイクルと呼びます。ジョイン・デューティ・サイクルは、0
（0.2%）∼ 255（ほぼ 100%）に設定できる 1 バイトのフィールドです。スタータ・キットのデフォルト値は 100% つまり255
に設定されています。設定値を低めにすると探索時間が長く平均電流が少なくなる一方で、設定値を高めにすると探索時間
は短くなるものの平均電流は増加します。少なくとも 1 つのモートがそのモートの近くに通知を送信しているとすると、参加
のために使うエネルギーは同じです。ジョイン・デューティ・サイクルは平均電流だけに影響します。モートが遠く離れてい
る場合、マネージャがオンでない場合、または通知がオフになっていた場合には、モートはネットワークを探してバッテリを
使い果たす可能性があります。ユーザーはジョイン・デューティ・サイクルによって、ネットワークが存在する場合の参加速度
とネットワークが存在しない場合のエネルギー使用量とのトレードオフを制御できます。
モートが同期と参加要求送信を行う時間は、ネットワークに参加するモートの最初の明らかな動きです。次のような trace
CLI コマンドを使用してマネージャのモート状態トレースを起動できます。
> trace motest on
マネージャは、モートの参加要求を確認すると、Negotiation1（Negot1）状態であるとモートにマークを付けます。
ジョイン・デューティ・サイクルの効果を確認するには、次のようにします。
• マネージャ CLI に接続し、前述したようにモート状態トレースをオンします。
• Eterna インタフェース・カード（DC9006）を使用してモート CLI に接続します。
• モートをリセットします。モートはリセット・メッセージを出力します。
> reset
SmartMesh IP mote, ver 1.1.0.32 (0x0)
これにより、モートはデフォルトのデューティ・サイクルでネットワークの探索を開始します。モートの状態が変わると、ms 単
位のタイムスタンプの後に状態という形式で一連の通知が表示されます。
52727 : Joining
56227 : Connected
60121 : Active
SmartMesh IP アプリケーションノート
10/140
モートが同期してその参加要求を送信するのにかかる時間は、平均で 10 秒未満です。これを数回繰り返して（毎回リセット
して）、同期時間の分布を調べることもできます。
• モートをリセットし、モート CLI を使用してジョイン・デューティ・サイクルを 5%（0.05 * 255 = 13）に設定します。こ
れはモートの mset joindc CLIコマンドによって制御します。ジョイン・デューティ・サイクルは SmartMesh IP モー
トでは不揮発性です。リセットや電源の入れ直しをしても持続するので、この手順を実行する必要があるのは、ジョイ
ン・デューティ・サイクルを変更するたびに 1 回だけです。モートが Negotiating1 状態に遷移する所要時間を測定し、
前述したようにこの測定を繰り返します。所用時間は平均で約 3 分になります。
> mset joindc 13
• モートをリセットし、モート CLI を使用してジョイン・デューティ・サイクルを 25%（64）に設定します。モートが
Negotiating1 状態に遷移する所要時間を測定します。所用時間は平均で約 30 秒になります。
> mset joindc 64
注記：マネージャは、以前は稼働状態だったモートからの参加要求を認識すると、そのモートにまず Lost とマーク
を付けてから connected（接続）となるように進めます。これは以下のように表示されます。
264504 : Mote #2 State: Lost
-> Negot1
266178 : Mote #2 State: Negot1 -> Negot2
3.2.2
参加時間の測定
マネージャがいくつかのパケットを送信し、モートがアクノリッジを返すことにより、モートはデータの送信を開始できる
Operational（Oper、稼働）状態に遷移します。マネージャのモート状態トレース CLI コマンド（このトレースは前述のテス
トから引き続きオンのまま）を使用して、これらの状態遷移を確認し、その所要時間を測定できます。タイムスタンプの単位
は ms です。モートをリセットして、モートが Operational に遷移するまで待ちます。以下のトレースの各行は、モートとマネー
ジャの間の 1 回のハンドシェークを表します。
117757 : Created mote 2
117765 : Mote #2 State:
Idle -> Negot1
119853 : Mote #2 State: Negot1 -> Negot2
122366 : Mote #2 State: Negot2 -> Conn1
125222 : Mote #2 State:
Conn1 -> Conn2
127127 : Mote #2 State:
Conn2 -> Conn3
129185 : Mote #2 State:
Conn3 -> Oper
この場合は遷移に約 11.5 秒かかっています。
SmartMesh IP アプリケーションノート
11/140
3.2.3
参加時の下り帯域幅の影響
マネージャがパケットを送信できる速度は、下りスロットフレーム・サイズの関数です。マネージャはスロットフレーム・サイ
ズに関係なく、同じ数の下りリンクを割り当てるので、長さが 4 倍のスロットフレームは、帯域幅が 1/4 になります。これを図
1に示します。100スロットのスロットフレームでのスロット1は、200スロットのスロットフレームでの同じスロット
（スロット1）
より2 倍の頻度で繰り返されます。デフォルトでは、マネージャが「高速」256 スロットのスロットフレームでネットワークを
構築し、1 時間後に「低速」スロットフレームに遷移します。低速スロットフレームのスロット数は、256（デフォルト）、512、
1024 のいずれでもかまいません。この値は dnfr_mult（下りスロットフレーム乗数）パラメータを介して設定されます。より
長いフレームは単位時間当たりの下り受信回数が少ないことを意味するので、フレームが長いとすべてのモートの平均電流
が低下しますが、後で追加されるモートの参加処理（やその他の下りデータ）も低速になります。これはネットワークに同期
するための所要時間（Negotiating1 状態までの時間）には影響しませんが、その他の状態遷移の間隔が広がるからです。
図 1 - 200 スロットフレームの場合より100 スロットフレームの場合の方がスロット 1 が頻繁に繰り返される
これらは公称サイズであることに注意してください。実際のスロットフレーム・サイズは、複数のネットワークが部分
的に重なっている場合の共存の状態を改善するために、多少ランダム化されております。本書では全体を通じて公
称サイズを指します。
SmartMesh IP アプリケーションノート
12/140
より長い下りスロットフレームの影響を調べるには、以下のようにします。
• マネージャ CLI により、通常の「高速」スロットフレームが使用されていることを確認します。下りスロットフレーム乗
数（dnfr_mult）を示す行を探します。
> show config
netid = 1229
txpower = 8
frprofile = 1
maxmotes = 17
basebw = 9000
dnfr_mult = 1
numparents = 2
cca = 0
channellist = 00:00:7f:ff
autostart = 1
locmode = 0
bbmode = 0
bbsize = 1
license = 00:00:00:00:00:00:00:00:00:00:00:00:00
ip6prefix = fe:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
ip6mask = ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00
radiotest = 0
bwmult = 300
• ここで下りスロットフレーム乗数を調整して、 1024 スロットのスロットフレームが得られるようにします。乗数を 4 に
設定すれば、4*256 スロットのスロットフレームが得られます。以下に示す config パラメータは不揮発性です。
> set config dnfr_mult 4
• より長いスロットフレームの使用を指定します。
> exec setDnframe normal
Start Global Unicast Command setDnFrame
SmartMesh IP アプリケーションノート
13/140
これが有効になるのに数分かかることがあります。
• マネージャがより長い下りスロットフレームを使用していることを確認します。
> show status
S/N: 00-17-0D-00-00-38-0C-8C
MAC: 00-17-0D-00-00-38-0C-8C
IP6: FE:80:00:00:00:00:00:00:00:17:0D:00:00:38:0C:8C
HW ver: 1.2
NetworkID: 293
Base bandwidth (min links): 9000 (1)
Frame size Up/Down 277/1052. Number of working timeslots 256.
Available channels 15.
Base timeslot(TS0) 20
Network mode is Steady State
Downstream frame 1052 timeslots
Optimization is On
Advertisement is On
AP output CTS is Ready
Backbone is off
Location is off
API is Not Connected
License 00:00:00:00:00:00:00:00:00:00:00:00:00
Network Regular Mode
Total saved links 3
マネージャの CLI コマンドでは、より形式的な用語である「slotframe」の代わりに、
「frame」がよく使われます。こ
こでの「Frame」は、802.15.4 パケットを示しているわけではありません。
• ここで、一つのモートの電源を入れ直し、そのモートが Negotiating1 から Operational に遷移するのにかかる時間
に注目します。この時間は、以前に確認した「高速」参加時間の約 4 倍になるはずです。
経路安定性が悪いと再試行が増すことを意味するので、経路安定性も参加時間に影響します。メッシュ・アーキテク
チャがあると、いかなる個々の経路の影響も最小限に抑えられることになります。
SmartMesh IP アプリケーションノート
14/140
3.2.4
ネットワーク形成と単一モートの参加
同時に参加するモートの数もネットワーク形成時間に影響します。これらのモートは限られた参加リンクおよび下り帯域幅を
求めて競合するからです。この影響を調べるには、以下のようにします（ここでは、先ほど設定した長い下りフレームを使用
しています）。
1. （前述したように）ジョイン・デューティ・サイクルが 100% となるようにすべてのモートを構成します。ここでは平均
電流は気にしないことにします。
2. 一つのモートをリセットして、参加させます。これを 10 回繰り返して平均参加時間を算出します。
3. すべてのモートをリセットし、ネットワークが完全に形成されるのに要する時間、つまり、参加トレースがオンのとき、
すべてのモートが Operational に遷移するのに要する時間を確認します。この実験を数回繰り返して、ばらつきの
感触をつかむこともできます。
5 つのモートがあると、平均的に、単一モート・ネットワーク内で 1 つのモートが通知を受信するより早く通知を受信するモー
トが存在するので、5 つのモートの場合の方が最初のモートの参加を認識するのが早くなることがあります。ただし、同時に
同期するモートの数が多すぎると、同じ共有アクセス・ポイント（AP）リンクへの競合が生じるので、ネットワーク全体の参加
時間が長くなる可能性があります。
マネージャを「高速」の下りフレームに戻して先へ進みます。
> set config dnfr_mult 1
• マネージャをリセットし、再ログインします。
3.2.5
失ったモートからの回復時間の測定
メッシュが重要な理由の 1 つは、経路障害に対する耐性です。スター構造やツリー構造では、1 つの RF 経路が障害を起こすと、
1 つまたは多くのデバイス・データが失われてしまうことになります。メッシュを評価する場合、経路障害からのメッシュの回
復がどのように行われるかを調べることが重要です。経路障害を発生させる最も確かな方法は、デバイスの電源を切ること
です。また、デバイスを見失った後の回復時間も非常に重要なので、
このテストはその両方を調べることを目的にしています。
まず、
「回復」の意味を決める必要があります。ユーザーが 10 デバイスで構成されたメッシュに近づいて 1 つのデバイスの電
源を切断したときに、電源を切断されたノードだけがデータの送信を停止し、これがデータ配信の唯一の変化である場合、
ネットワークは回復したとみなします。該当ノード以外のすべてのノードが設定レートで間断なくデータを送信し続けること
ができた場合は、回復時間をゼロとみなします。失われたノードが、ネットワークの他の部分に影響を与えることなく、運用
を続けることができたからです。もう１つの調査方法は、データ待ち時間のように、サービス品質（QoS）の一定の測定基準
を設定することです。ノードの電源を切る前はその QoS 測定基準を満たし、次にその QoS 測定基準が低下する原因となる
ノードの離脱を探し、電源の再投入後 QoS 測定基準が以前の状態に戻ることを確認します。この場合、観測者の判断が入
る余地があり、報告レートによっては厳密な時間を決めることが難しいかもしれません。回復を識別する第 3 の方法は、1 つ
以上のノードの親であるノードの電源を切断し、その親ノードの離脱をネットワークが検出して新しい親ノードを確立するの
に要する時間を測定する方法です。3 つの異なる「回復時間」テストの目的をまとめると、以下のようになります。
1. データ配信の継続。ある 1 つのモートの電源を切断してもそれ以外のモートからのデータ配信が中断しない場合、
回復時間は 0 です。データ配信が中断した場合、回復時間はすべてのノードからのデータ配信が回復するまでの時
間です。
SmartMesh IP アプリケーションノート
15/140
2. QoS データ配信。データ分析により、ネットワークの QoS の基準を決定します。ある 1 つのノードの電源を切断し、
一部またはすべてのノードについて QoS 測定基準の低下に注目します。回復時間は、以前の QoS 測定基準を再度
満たすまでの時間です。
3. メッシュの修復時間。メッシュを調べます。あるノードの電源を切断し、それによって他のノードの親が 1 つだけに
なるようにします。回復時間は、ネットワークが離脱を検出してから完全なメッシュを再確立するまでに要する時間
です。
テスト 1 と 2 は基本的には同じです。ネットワークを設定して（以下のヒントを参照）、CLI に接続し、trace stat on を実
行します。マネージャが受信した各パケットについて、モート ID とそのパケットの待ち時間が出力されます。このテキストを
一定時間取り込み、その後にモートの電源を切断します。電源を切断するモートはランダムに選択できますが、メッシュ内
に多くの子モートがあるモートを選ぶこともできます。ノードの電源を切断したとき、取り込みテキストにあるタイムスタン
プをメモします。ネットワークを引き続き数分間動作させます。そうすると、この取り込みテキストからのデータをプロットし
て、電源が切断されたモートから最後のパケットを受信した瞬間を見つけることができるので、それ以降は他のノードから
のデータ配信時に隔たり（差）や遅延があるかどうかを調べることができます。ここでは解析ツールとデータ分析ツールを用
意する必要があります（MATLAB、Excel、Python はすべて適しています）。
最初の数モートが参加するのを待ってから残りのモートの電源を入れることにより、すべてのモートに同時に電源を
入れる場合よりメッシュを迅速に形成できます。モートは、モートの参加時に通知を受信したモートを報告します。
すべてのモートの電源を同時に入れた場合には AP だけが通知を送っているので、AP だけを隣接モートとして報告
します。モートはエネルギーを最小限に抑えるために、ゆっくりと他の隣接モートの検出と報告をおこないます。そ
のため、マネージャがネットワークの「メッシュ化」を開始するのに最大で 5 分かかります。実際の用途では、隣接モー
トを検出する際の時間はあまり重要ではありませんが、デモや評価の場合には、いくつかのモートの参加を待って
から他のモートを起動することによって、直ちにメッシュ化することができます。
テスト 3 では、マネージャの別のトレース機能を使います。初めにネットワークを構築し、メッシュが確立されていることを確
認します（つまり、 numparents=2 の場合は、親を一つしか持たないただ一つのモートを除き、すべてのモートに 2 つの親
が存在します）。マネージャのテキスト取り込みを開始します（trace link on）。モートを 1 つ選択して、電源を切ります。
モートの電源を切った瞬間のタイムスタンプの概略値をメモして、障害が発生した経路の検出に関連したイベントと、新し
い経路の確立に関連した動作に注意します。数分後にトレースを停止し、
メッシュが完全に復元されていることを確認します。
「回復時間」は、モートの電源を切ったときから、取り込みテキストに記録された最終リンク追加イベントのタイムスタンプ
までの時間です。予想される結果は以下のとおりです。
1. ネットワークが良くできたメッシュだった場合は、 1 つのデバイスの取り外しが原因でデータが消失したりモートが
新たに失われたりすることはないでしょう。
2. 普通の報告レート（5 秒以上につき 1 パケット）では、QoS に影響はないと予想されます。もっと高い報告レートの
場合は、1 つのデバイスの離脱に関連した待ち時間の遅延が見受けられることがあります。待ち時間が約 200ms の
モートでは、少しの間、待ち時間が約 500ms になることがあります。回復時間は 1 ∼ 2 分になります。
3. モートの電源切断は 1 ∼ 2 分の間に検出されて修復されます。
評価キットに標準的にインストールされている Stargazer GUI ツールにより、メッシュの形成を確認できます。
SmartMesh IP アプリケーションノート
16/140
3.3
3.3.1
待ち時間
待ち時間の測定
マネージャ CLI 統計情報トレース機能を作動させると、マネージャ側で受信した上りパケットごとに待ち時間の測定が行わ
れます。
> trace stats on
281098 : STAT: #2: ASN Rx/Tx = 38694/38570, latency = 899, hops = 1
281100 : STAT: new average hops10=10 latency/10=56
このトレースは、上りパケットごとに 2 行のレポートになっています。1 行目は、パケットをマネージャ側で受信した時刻（Rx）
とパケットをモート側で発生した時刻（Tx）を絶対スロット番号（ASN）で示しています。ASN は、ネットワークが起動してか
らか、マネージャの UTC 時刻を設定してある場合は 2002 年 7 月 2 日 20:00:00 UTC 以降に経過したタイムスロットの数で
す。これら 2 つの数の差に 7.25ms/ スロットを掛けると、ここで報告されている 899ms という値になります。キューに入る遅
延が存在する場合があるので、データを生成するセンサとマネージャ側での通知との間の時間は若干長くなります。また、1
行目はこのパケットの上流に何ホップあるかも示しています。
2 行目は、マネージャがこのパケットを受信した後に統計情報を平均化していることを示しています。示している内容は、
このモートの平均ホップ数（0.1 ホップ単位）と平均待ち時間（10ms 単位）です。したがって、この場合の平均待ち時間は
56*10 ms = 560 ms です。
大量の待ち時間トレース出力結果を集めて分布図をプロットすることができます。分布図はこのようになります。
経路安定性が非常に低いわけではない限り、平均すると、1 ホップ当たりの上り待ち時間は、上りスロットフレームの長さの
1/2 より短くなると予想されます。
SmartMesh IP アプリケーションノート
17/140
3.3.2
スター型トポロジとの比較
ZigBee ネットワークでは、センサ・ノードの通常の報告先は電源の入った常時オンのルータです。そのため、データ待ち時
間が非常に短くて済みます。但しそれもリンクに障害が発生するまでのことですが。
Dust のネットワークは、短いデータ待ち時間を実現するいくつかの手段を備えています。それは、ネットワーク全体に影響
する通電バックボーン（下記の注を参照）、ネットワーク全体の基本帯域幅設定、または 1 モート当たりのサービスです。
以下の実験を試してください。
• モートを互いに数メートル以内に配置し、メッシュ型ネットワーク（デフォルト）を形成します。
• 前のセクションで説明したように、平均待ち時間を測定します。デフォルトでは、各モートが温度データを 30 秒
に 1 回送信するので、10 分より長くデータをとる必要があります。
• モートを強制的に非ルーティングにすることにより、スター型ネットワークを形成します。これは次のようにモート CLI
を使用して実行します。
> mset rtmode 1
> mset maxStCur 20
• rtmode と maxStCur は不揮発性です。リセットしても電源を入れ直しても機能は持続しますが、モートがネットワー
クに参加する前に変更する必要があります。参加後に設定を変更した場合は、モートをネットワークに再参加させる
必要があります。DC9006 ボードに接続し、CLI を使用してルーティング・モードを変更し、その後 DC9006 を切断して、
別のモートでこれを繰り返す必要があります。
• ここで maxStCur 設定を使用して、モートが実現可能な最も消費電力が低いモードに確実に入るようにします。
• 平均待ち時間を測定します。この時点ではモートの親は AP だけなので、平均待ち時間はわずかに減少しているはず
です。このスター構成では、モートがリンク障害に対して無防備になる割には、それほど待ち時間が改善されないの
で、正しい解決策とは言えません。
• モートの設定をルーティング対応に戻し、上流のバックボーンをオンにします。これはマネージャの CLI コマンド set
config で行います。バックボーンは、
（他のフレームで使用される通常の専用スロットとは違って）
アクセス競合スロッ
トを持つ短いスロットフレームで、これを使用すると待ち時間の短い、多数のモートが共有する帯域を実現できます。
最も消費電力が低いモート構成を得るため、nummlinks を 0 に設定して、マネージャの下りマルチキャスト・リンク
も除去します。この変更を行う前にスーパーユーザー・パスワードを入力する必要があることに注意してください。
>
>
>
>
set config bbsize 1
set config bbmode 1
su becareful
seti ini nummlinks 0
• この後、バックボーンが作動し始めるには、マネージャ・リセットが必要です。バックボーン・モードは不揮発性で、
リセット中も保持されます。
• マネージャに再接続してすべてのモートを参加させたら、マネージャの CLI 待ち時間トレースをオンに戻します。
> trace stats on
SmartMesh IP アプリケーションノート
18/140
• 平均待ち時間を測定します。モートはそれらの間でときどきルーティングするにもかかわらず、待ち時間は劇的に短く
なります。
• バックボーンをオフにします。
> set config bbmode 0
• マネージャをリセットし、統計情報トレースをオンに戻します。
• ネットワーク内の基本帯域幅を広げます。デフォルトは9000ms（つまり、9000msにつき1パケット、または0.11パケッ
ト / 秒）です。1000ms に設定します。これも次の set config コマンドを使用して実行します。
> set config basebw 1000
• この後は、マネージャのリセットが必要です。
• マネージャに再接続してすべてのモートを参加させたら、CLI 待ち時間トレースをオンに戻します。
• 平均待ち時間を測定します。値は低下しているはずです。モートの発行速度が変わったわけではありませんが、より
多くのリンクを受け取ったので、待ち時間は減少します。
• 基本帯域幅の設定値を 9000ms に戻します。
> set config basebw 9000
• 1 つのモートでサービスを要求します。
• 平均待ち時間を測定します。サービスを持つモートでは待ち時間が短くなり、そのモートを親モートとして持つ他の
モートでも待ち時間が少し短くなる場合があることが分ります。
デフォルトでは、モートの送信リンクは上流の通電バックボーンへのリンクだけです。これがモートの消費電力に及
ぼす影響はごくわずかです。他のモートからのパケットを受信して、それをバックボーンに転送するには、そのモー
「アプリケーションノート：通
トで setParameter<pwrSource> API を呼び出す必要があります。これについては、
電バックボーンを使用した待ち時間の改善」で説明します。これにより、ネットワーク全体の待ち時間を（上り方向ま
たは双方向で）改善できますが、モートの電流が大幅に増加します。ただし、双方向のバックボーンをオンにした場
合でも、Dust のモートは標準的な ZigBee ルータよりも電流が 10 倍少なくなります。
3.3.3
消費電力と待ち時間の間のトレードオフ
一般に、消費電力と待ち時間はトレードオフの関係にあります。スロットフレーム全体を通じてリンクの間隔を比較的均等に
する傾向があるので、モートのリンク数が多ければ多いほど、どのパケットの待ち時間も短くなります。これは、モートが同じ
割合でパケットを生成する場合でも、トラフィックを転送するモートの方が転送しないモートより待ち時間が短いという意味
です。また、平均待ち時間を目標にしてサービスを要求することにより、データ生成速度が低い場合であっても、モートが待
ち時間を改善できることも意味します。
「電力」セクションでの一部の電力測定実験では、消費電力と待ち時間との間に相関があることを示しています。
SmartMesh IP アプリケーションノート
19/140
3.3.4
往復の待ち時間
Dust のネットワークは、主にデータ収集ネットワークとして機能するよう設計されているので、ほとんどの帯域幅は上り方向
のトラフィックで費やされます。サービスを使用することで上り方向の占める割合を改善できますが、高速（メッセージ当た
り2 秒未満）の呼び出し応答が必要な場合は、双方向のバックボーンを使用できます。以下の実験を試してください。
• マネージャ CLI を介して ioトレースと iodataトレースをオンにします。
• マネージャ・モードで APIExplorer を使用して、アクノリッジ付のアプリケーション・パケットをモートへ送信し
ます。これ は sendData API を使 用して実 行します。送 信 元 / 宛 先 ポ ート = 61625（0xF0B9）、 ペイロード =
050002FF020302000100 に設定します。これにより、モートのインジケータ LED が点灯し、LED が設定されたこ
とをモートが認識します。マネージャ CLI に次のように表示されます。
442887 : TX ie=32:2c mesh=1222 ttl=127 asn=59614 gr=2 dst=2 rt=r4 r=1:2 tr=u:req:8; sec=s nc=0
ie=fe:00 IP=7d77 UDP=f7 sP=f0b9 dP=f0b9;
443503 : TxDone
444269 : RX ie=32:1c mesh=4002 ttl=127 asn=59699 gr=1 src=2 rt=g tr=u:req:0; sec=s nc=11 ie=fe:00
IP=7d77 UDP=f7 sP=f0b9 dP=f0b9;
これを数回繰り返し、往復の待ち時間（TX の時刻と RX の時刻との差、ここでは 1382ms）を測定します。
• 双方向のバックボーンをオンにします。
> set config bbsize 2
> set config bbmode 2
この後、バックボーンが作動し始めるには、マネージャ・リセットが必要です。
• マネージャに再接続してすべてのモートを参加させたら、CLI 待ち時間トレースをオンに戻します。
> trace stats on
• 手順 1 の sendData テストを繰り返します。往復待ち時間が劇的に改善されていることが分ります。
通電バックボーンは、非アクティブ状態になってネットワークが再度リセットされるまではリセットしても電源を入れ
直しても状態を持続します。この結果、モートの平均消費電流は 1 ∼ 2mA になります
SmartMesh IP アプリケーションノート
20/140
3.4
チャネル・ホッピングと範囲
他の大半の 15.4 ベースのシステムとは異なり、 Dust の製品は Time Slotted Channel Hopping MAC を採用しています。
これは、伝送が 2.4 GHz 帯のすべてのチャネル（または一部のチャネル：下記の「ブラックリスト登録」参照）にわたって広がっ
ているという意味です。これには、システムの性能が 1 つのチャネルの安定性ではなく、平均的なチャネル安定性に依存す
るという利点があります。以下のテストでは、1 つのチャネルの安定性を測定する方法を示し、チャネル・ホッピングの影響
を調べます。このテストでは、802.11g Wi-Fi ルータを、ある特定のチャネルに設定できることが必要です。ルータは（モート・
チャネル 4 ∼ 7 をカバーする）802.11 チャネル 6 に設定します。また、無線テストに備えてマネージャとモートを構成する必
要もあります。
以下の各種 API では、チャネルに 0 ∼ 15 の番号が付けられています。これらは IEEE チャネル番号付与方式でのチャ
ネル 11 ∼ 26 に対応します。
3.4.1
単一チャネル測定での無線テスト（radiotest）の使用
この説明では、マネージャの役割をトランスミッタ、モートの役割をレシーバと位置付けていますが、役割を交換しても同じ
ようにテストできます。
• マネージャの CLI で、ログインしてマネージャを無線テスト・モードにします。
> login user
> radiotest on
> reset system
System reset by CLI
SmartMesh IP Manager ver 1.1.0.30.
658 : **** AP connected. Network started
• マネージャがリセットしたら、マネージャがトランスミッタになるよう構成し、チャネル 0 において、電力 +8dBm、
1000 パケット、80 バイトのペイロードの条件でパケット・テストをマネージャに設定し、モートをレシーバとして構
成するまで待ってから Return キーを押します。無線テスト・モードではログインは任意です。
> radiotest tx reg 0 8 1000 80
• モートの CLI で、無線テスト・モードに入り、リセットします。その後、チャネル 0 で 2 分間受信するようモートを構成
します。
> radiotest on
> reset
SmartMesh IP mote, version 1.1.0.41 (0x0)
> radiotest rx 0 120
SmartMesh IP アプリケーションノート
21/140
• この時点で、マネージャの Return キーを押し、テストを開始します。マネージャが送信を終了したら、受信したパケッ
ト数をモートの CLI で記録します。
> radiotest stat
Radio Test Statistics
OkCnt : 998
FailCnt : 2
受信パケット数と送信パケット数の比は、このチャネルの経路安定性（またはパケット成功比）です。1000 - OkCnt が
FailCnt に等しくならないことがありますが、これはマネージャが自動追跡可能なパケットだけを数えるからです。
すべてのチャネルについて繰り返します。Wi-Fi ルータが使用しているチャネルの近辺に経路安定性の落ち込みがあること
が分ります。この落ち込みが思ったほど大きくないことに気が付かれるでしょう。ルータにもデューティ・サイクルがあり、全
ての時間で送信しているわけではないので、思ったほど悪くない結果が得られるのです。
3.4.2
到達距離テスト
radiotest コマンドは到達距離テストに使用することもできます。到達距離とは 2 つのデバイスが確実にパケットを交換でき
る距離のことですが、あいまいなものでもあります。2 つのデバイスがある距離を置いて通信する能力には、以下のすべて
の条件が影響するからです。
• 反射物 - 無線信号が跳ね返るもの。地表を含む
• 障害物 - 無線信号が通り抜ける必要があるもの
• 干渉電波の存在
• アンテナのデザイン
• 無線電力の設定値
最も簡単なテストは、前述した単一チャネル測定を繰り返す方法ですが、実際のネットワークではすべてのチャネルを使用
するので、それをすべてのチャネルに対して繰り返します。パケット・エラー率は、見通し経路と跳ね返り経路の間の自己干
渉により、地表からのアンテナの高さに大きく影響されることが分ります。モートを標高 1m に置いた場合、間隔が 50m に近
づくとパケット成功率が低下し、それを改善するにはさらに遠くに置くしかないことがわかります。何もない空き地の数メー
トル上空に置かれたモートは、数百メートルの距離で通信できるはずです。
このテストの終了後は、マネージャとモートを通常動作に戻します。
> radiotest off
OK
> reset
DC9003 ボード には、ダイポール・アンテナと比べて利得がきわめて低い（+2dBi に対して平均 -2.3dBi）組み込
みのチップアンテナが付属しています。到達距離の測定では、この差を考慮に入れる必要があります。
SmartMesh IP アプリケーションノート
22/140
3.4.3
ブラックリスト登録
マネージャは、既知の干渉電波が存在する場合、特定のチャネルをブラックリストに登録する API を備えています。通常は、
きわめて通信頻度の高い WiFi ルータなどの強い干渉電波があることが分っていない限り、ブラックリスト登録はしないでく
ださい。
• 5 モートのネットワークを形成します。すべてのモートが参加したら、統計情報を消去します。
> exec clearstat
• 1 時間動作させます。マネージャ CLI を使用して、ネットワーク全体としての経路安定性を調べます。干渉電波による
パケットの消失は発生していないはずです。
> show stat
Manager Statistics -------------------------------established connections: 1
dropped connections
: 0
transmit OK
: 1907
transmit error
: 0
transmit repeat
: 0
receive OK
: 35
receive error
: 0
acknowledge delay avrg : 15 msec
acknowledge delay max : 35 msec
Network Statistics -------------------------------reliability: 100% (Arrived/Lost:
stability:
latency:
1931/0)
98% (Transmit/Fails: 983/25)
200 msec
Motes Statistics ----------------------------------Mote
Received
Lost
Reliability Latency Hops
#2
1019
0
100%
120
1.0
#3
19
0
100%
1050
1.0
SmartMesh IP アプリケーションノート
23/140
• マネージャをリセットし、チャネル 4 ∼ 7 をブラックリストに登録して、マネージャをリセットします。ブラックリストの
機能はリセットしても電源を入れ直しても持続します。
> login user
> set config channellist 00007f0f
> reset system
System reset by CLI
SmartMesh IP Manager ver 1.1.0.30.
658 : **** AP connected. Network started
• ネットワークが形成されたら、統計情報を消去し、もう 1 時間動作させて、経路安定性が改善されたことを確認します。
マネージャを 15 チャネルに戻してから先に進みます。
> login user
> set config channellist 00007fff
> reset system
System reset by CLI
SmartMesh IP Manager ver 1.1.0.30.
658 : **** AP connected. Network started
3.5
電力
このセクションでは、評価 / 開発用ボードで電力を測定する方法について詳しく説明します。モートの電流を測定するには、
DC9003 A-B/DC9006 の組み合わせを使用します。DC9006 の VSENSE と記されたジャンパの両端にオシロスコープを
接続して、10 Ωの直列抵抗両端の電圧降下を測定するか、CURRENT ジャンパ（黒）とその裏側にある赤のジャンパを両方
とも取り外して、CURRENT ジャンパ・ピン間に平均電流メータを接続します。
DC9003A-B ボードの LED_EN ジャンパは取り外しておく必要があります。そうしないと、電流測定が不正確になり
ます。
SmartMesh IP アプリケーションノート
24/140
お勧めの測定方法を以下に示します。
• アイドル電流 - モートはリセットされているが、join API コマンドは発行されていない場合。モートはスレーブ・モー
ドに構成して自動参加を止めておく必要があります。アイドル電流の測定後は、モートをマスタ・モードに戻します。
• 探索 - デューティ・サイクル 5% のときとデューティ・サイクル 100% のときに測定します。電流が約 250µA 平均から
5mA 平均に変わることが分ります。
• 参加モート - dnfr_mult を 4 に、setDnframe を fast に設定して、マネージャをリセットしてからモートを参加させます。
1 時間後、マネージャはより長い下りフレームに遷移するので、平均電流を比較できるようになります。遷移前は約
29µA で遷移後は 24µA になります。CLI で「exec setAdv off」コマンドを使用して通知を停止し、平均電流が 10µA
まで減少するのを確認します。
• バックボーン - bbmode を 2 に、bbsize を 2 に設定して、マネージャをリセットします。平均電流を測定します。約
500µA になります。
Dust は SmartMesh Power and Performance Estimator を用意しており、さまざまな使用例でモートの平均電流を推定
するのに役立ちます。テスト結果をスプレッドシートの結果と比較します。
3.6
メッシュの動作
Dust のネットワークは、自動的にメッシュを形成します。各モートには複数の隣接モートが存在し、それらを介してデータを
送信または転送できます。この設定はマネージャのポリシーであり、マネージャ CLI コマンド >show config（上記参照）に
よって表示できます。このポリシーを設定する config 要素は numparents であり、上記から分るように、デフォルト値は 2 で
す。マネージャは、メッシュ内にループがないことを前提として、すべてのモートの親の数が、numparents で示された親の
数以上であるように設定します。この略図をホワイトボードで作成してみてください。1 モートのネットワークでは、その 1 モー
トの親は AP モートだけになることがわかるでしょう。2 つ目のモートを追加すると一方のモートの親は 2 つになりますが、ルー
「片親のモート」が常に 1 つ
プの発生を防ぐため、もう一方のモートの親は 1 つのままです。追加するモートの数に関係なく、
存在します。
3.6.1
メッシュのテスト
Stargazer GUI アプリケーションを使用すると、形成されているメッシュを確認できます。まだインストールしていない場合
は、今すぐインストールしてください。また、このアプリケーションを使用するには、シリアル・マルチプレクサをインストー
ルする必要もあります。
親が 2 つのモートは、ほとんどの動作条件で堅牢性と電力消費の最適なバランスを示します。堅牢性は複数の親を持つこと
で実現されます。これを確認するためには、1 以上のモートの親であるモートをまず見つけて下さい。該当モートの電源を
切ります。該当モートからのデータ配信は停止しますが、子モートは引き続きデータを送信します。前述したように「trace
stats on」を使用して、すべての子モートから、他の親を通じて送信されているライブのデータ・ストリームを見ることができ
ます。数分の間、待ち時間が一時的に長くなる可能性があります。また、このトレースをファイルに取り込むと、トレースを図
示できます。マネージャは、システム内の親とリンクを再度割り当てて、電源を切ったモートの離脱を補うのに数分かかります。
SmartMesh IP アプリケーションノート
25/140
3.6.2
メッシュ・ポリシーの変更
パラメータ「numparents」には、4 つの値（1、2、3、または 4）のいずれかを指定できます。numparents に 1 を設定すると、
ネットワークはメッシュ型ではなくツリー型になります。各モートの親は 1 つになり、その 1 つの親は APとは限りません。ツリー
型はマルチホッピングをサポートするという点でスター型より優れています。しかし、スター型と同様、ツリー型ネットワーク
には多くの「単一障害点」が存在します。ツリー内のある 1 つのモートの親の電源を切ると、子モートは他のどのデバイスと
も接続していないので、ネットワークから脱落します。この子モートはリセットし、ネットワークに再参加する必要があるので、
データを失う可能性が高くなります。ツリー構造の消費電力はわずかに低くすることができます。それは、各デバイスが受信
する必要があるのは 1 つの親からの下り方向のメッセージだけであり、維持しなければならないのは 1 つの親との同期だけ
だからです。それに加えて、個々のパケットはメッシュ内を「迂回する」ことができないので、データ待ち時間はツリーにより
依存すると考えられます。当社では、ネットワークの崩壊やデータ消失の危険性の方が消費電力と待ち時間の小さな利点よ
りもはるかに深刻であると考えています。
2はデフォルトの値であり、堅牢性と電力のバランスが取れています。numparentsを3さらに4に設定すると、システムの「メッ
シュ性」が増し、ネットワークの堅牢性が高まりますが、いくぶん消費電力が高くなるという代償を払うことになります。経路
が頻繁に遮断されることが分っているネットワークでは、親の数を増やすことを推奨します。アプリケーションノート：干渉の
影響の特定および軽減を参照してください。numparents = 4に設定することで、いくつかのノードがある程度移動してもネッ
トワークがうまくサポートされます。
3.7
データ・レート
SmartMesh SDK に は、 次 の 2 つ の サ ン プ ル・ アプリケ ー ション が 収 録 さ れ て い ま す。1 つ は TempMonitor で、
SmartMesh IP ネットワーク内の 1 つ以上のモートで温度計測の周期を設定できます。もう 1 つは PkGen で、特定のサイズ
のパケットを特定の周期で生成できます。これら 2 つのアプリケーションを同時に使用して、温度データとシミュレーション・
データの両方を異なる周期で同時に生成することができます。また、Stargazer アプリケーションを使用して、温度だけでな
くアナログ・データやデジタル・データを収集することもできます。
これらのアプリケーションにより、以下の質問に答えることができます。
• ネットワーク内でのデータの実際の流れはどう見えますか？
• 単一モートはどのくらい速く移動できますか？
• すべてのモートはどのくらい速く移動できますか？上流のバックボーンがオンのときはどうですか ?
最終的なデータ・レートは、モートの数、各モートが要求するサービス（またはサービスに加えて基本帯域幅あるいはサー
ビスの代わりに基本帯域幅）、トポロジ、および経路安定性により異なりますが、このツールにより、どれくらいの柔軟性が期
待できるのかが判ります。
SmartMesh IP アプリケーションノート
26/140
4 アプリケーションノート：サブスクライブ API でのフィルタの
使用法
4.1
サブスクライブ・フィルタ
サブスクライブ API は、マネージャがどの通知をホスト・アプリケーションに送信するかを構成するために使用します。通知
のリストは、以下の 2 つのビットマップのいずれかで指定します。
• filter ビットマップは、どの通知を送信の対象とするかを指定します。
• unackFilter ビットマップは、非アクノリッジ制御（ベストエフォート）通信を使用して送信する通知を指定します。マ
ネージャは、ホストの動作に関係なく、生成された時点で各通知を送信します。デフォルトの動作は、アクノリッジ制
御通信を使用して送信する方式で、ホストが各通知にアクノリッジを返すのを待つ間、後続の通知パケットはキュー
に入ります。
unackFilter ビットマップのビットは、対応するビットが filter ビットマップに設定されていない限り意味はありません。
4.2
アクノリッジ制御か非アクノリッジ制御か ?
リンクに誤りがある可能性が低い場合、ホスト UART が常に使用可能な状態であり、十分なバッファがある場合（たとえば、
ホストが PC である場合）、あるいは、アプリケーションがある程度の量のデータ消失を許容できる（たとえば、レポートがな
くても警戒状態にならない）場合には、非アクノリッジ制御通信を data 通知および ipData 通知に使用できます。その他の
通知は頻度が非常に低く、欠落しないことがより重要なので、常にアクノリッジ制御通信を使用するべきです。非アクノリッ
ジ制御通信はアクノリッジ制御通信より高速です。パケット間の遅延を最小で 1 ビット時間（約 10 µs）にすることが可能であ
り、アクノリッジの送信に時間がかからないからです。現在のシリアル・ポート速度（115200bps）では、非アクノリッジ制御
通信を使用してマネージャのデータ・スループットを最大限に高めることが必要な場合があり、パケット生成速度が 10 パケッ
ト / 秒より速い場合は非アクノリッジ制御通信の使用を検討する必要があります。
アクノリッジ制御の伝送方式により、ホストは以下のような多少のエラーがあった場合でも各パケットを確実に受信します。
• フレーミング・エラー（通常はパケット送信開始時にホストがスリープ状態の場合に発生）
• ビット・エラー（SNR が不十分なリンク（例：遮蔽が不十分なケーブル）によって発生）
• ホストに Rx バッファがないか、別の理由でホストの受信準備が完了していない
マネージャは 200ms 待ってから各パケット受信の再試行を行います。パケット受信が 3 回再試行されてもアクノリッジが返
されない場合、マネージャはそのセッションが途切れたとみなし、保留中のパケット（とキューに入っているその他の通知）
を破棄して通信を切断します。
「SmartMesh IP Manager API Guide」に説明されているように、ホストはセッションを再確
立して、通知を再サブスクライブする必要があります。
マネージャは少数のパケットをキューに入れてから、 AP からのパケットを拒否します。生成速度と経路安定性によっては、
最大の通知再試行回数を行う前にも、モートのキューがいっぱいになり、モートがパケットを拒否し始める可能性があります。
これにより、パケットの消失や陳腐化が発生することがあります。全体のパケット率が 1 パケット / 秒より低い場合、通知の再
試行が原因でネットワークがパケットを廃棄することはありません。
SmartMesh IP アプリケーションノート
27/140
5 アプリケーションノート：SmartMesh IP ネットワークの
健全性のモニタ
LTC5800 ベースの IP ネットワークは、ネットワークを管理して最適化するのに必要な最小限の統計情報を維持します。ここ
では、傾向を継時的に追跡する目的で情報を集計している訳でも、モートごとの情報を全て残している訳でもありません。
ただし、この統計情報の多くの情報源（すなわち、モートの加工されてない健全性レポートおよび状態レポート）は、ネット
ワークの健全性情報とデバッグための情報をユーザーに提供するために、クライアント・アプリケーションがサブスクライブ
できる通知の形式で利用できます。いくつかの例を以下に示します。
• 状態の変化を監視することにより、リセットしているモートがあるかどうかをアプリケーションが知ることができます。
• 隣接モートの健全性レポートを監視することにより、経路に障害が発生した場合に回復に適した十分な数の隣接モー
トがすべてのモートに存在することをアプリケーションが確認できます。
さらに、
アプリケーションはマネージャのAPIを使用してネットワークに関する詳細情報を入手できます。本書では、ネットワー
クの健全性をモニタするために、正常に機能するネットワーク上で継続的に実行できるいくつかのテストについて詳しく説
明します。
この処理は 2 つの部分に分れます。1 つ目は、マネージャからの通知の出力に関してアプリケーションが継続的にモニタする
必要がある一連の通知です。2 つ目は、必要な残りの情報を収集するためにアプリケーションが定期的に行う必要がある一
連の API 呼び出しです。アプリケーションはネットワークと同時に起動して、ネットワークの稼働期間の全体にわたり、健全
性をモニタするのが理想です。
すべての通知データを保管することを推奨します（おそらく毎日のログに分割することになるでしょう）。記憶容量が心配な
場合は、項目（例：経路 x RSSI）ごとに最大値、最小値、FIR フィルタ処理済み平均値を保管すれば、ユーザーにフィードバッ
クするには十分と考えられます。
5.1
健全性レポート
ネットワークの各モートが送信する健全性レポート（HR）は 3 種類あり、それぞれ 15 分に 1 回送信されます。モニタする必
要があるのは、 NeighborsHR と DeviceHR だけです。3 種類目の NeighborsDiscovery が示す情報には、マネージャ API
を介する方がより容易にアクセスできます。HR の通知はマネージャから非同期で到着するので、アプリケーションはそれを
モニタする必要があります。
5.1.1
NeighborsHR
この HR は、特定のモートが関与しているすべての使用された経路に関する情報を示します。この HR から取り込む情報は、
time、nbrId、nbrFlag、rsl、numTxPk、numTxFail です。
経路の安定性を計算する場合、子モートの観点から HR に関係があります。nbrFlag=1 である場合、モートは子の経路を報
告しています。この場合、安定性をパーセントで表すと 100*(1-numTxFail/numTxPk) になります。この安定性をこの経路の
RSSI（ここでは rsl と呼ばれる）と一緒に記録することが必要です。これらの 2 項目を経路ごとに 1 つの組として記録します。
SmartMesh IP アプリケーションノート
28/140
5.1.2
DeviceHR
この HR は、モートの内部動作に関する情報を示します。ここでは、アプリケーションからメッセージを受信したときにモート
がどの程度正常に動作していたかを知らせる値を抜き出します。これは、後でネットワーク全体の可用性を計算するときに
考慮に入れます。この HR から取り込む情報は、numTxOk および numTxFail です。
モートの可用性をパーセントで表すと、100*(1-numTxFail/(numTxFail+numTxOk)) となります。
ネットワーク全体の可用性を計算するには、新しい変数を 2 つ定義して、その初期値をゼロにします。これらの変数を
appTxPk および appTxFail と呼びます。
変数の数値を各 DeviceHR と一致させ続けるには、次のようにします。
• appTxPk += numTxOk + numTxFail
• appTxFail += numTxFail
5.2
周期的な API 呼び出し
以下の API 呼び出しを使用して 15 分ごとにマネージャをポーリングし、 HR の周期と一致させることを推奨します。モートご
とに 0 から始めて getNextPathInfo まで繰り返します。
5.2.1
getMoteConfig
Store：macAddress、moteId、isAP
このコマンドは、ネットワーク内に存在するすべてのモートの MAC アドレスを取得する便利な方法です。これを順に繰り返
し、次のフラグを使用して MAC アドレス / モート ID のすべての対を取得して、macAddress=0 から作業を開始します。この
アドレス対応関係を保管すると、アプリケーションは、報告可能な残りの健全性情報を MAC アドレスまたはモート ID で解読
できます。通常、この API によって返される情報が変わることはありませんが、それはネットワークに新しいモートが追加さ
れないことが前提です。
5.2.2
getMoteInfo
Store：numGoodNbrs、requestedBw、totalNeededBw、assignedBw、packetsReceived、packetsLost
この API によって返される情報は、マネージャがモートからパケットを受信したときに、マネージャによって継続的に更新さ
れます。いったんネットワークが完全に検出されるとnumGoodNbrs の値は同じ値を維持しますが、最適化により、ネットワー
ク全体を通じて帯域幅分布の要件が変更される可能性があります。
ネットワーク全体の信頼性を計算するには、新しい変数を 2 つ定義して、その初期値をゼロにします。これらの変数を
networkRX および networkLost と呼びます。
変数の数値を各 getMoteInfo 呼び出しと一致させ続けるには、次のようにします。
• networkRX += packetsReceived
• networkLost += packetsLost
SmartMesh IP アプリケーションノート
29/140
5.2.3
getNextPathInfo
Store：source、dest、direction、numLinks、quality、rssiSrcDest、rssiDestSrc
マネージャはすべての経路情報を維持しますが、粗く平均的な形式のみとなります。HR の動作を注視することにより、この
すべての情報をより精細な分解能で取得できます。
5.3
テスト
以下に示すのは、収集したすべてのデータに対して実行し、ネットワークの健全性についての警告を示すことができるテスト
です。
上流のリンクの数を計算するには、各経路で報告された方向を調べます。
• TX リンクの合計は、direction=2 の numLinks を合計した値です。
• RX リンクの合計は、direction=3 の numLinks を合計した値です。
• 親の総数は direction=2 の経路の数です。
5.3.1
AP のみの場合
以下のテストは AP に対してのみ実行します。このデバイスは isAP フラグが設定されていることによって識別します。
リンクが飽和状態に近い AP
前述したように、direction=3 のすべての経路について numLinks を合計します。AP が外付け RAM なしでサポートできる
RXリンクの数は 150 なので、RXリンク数が 140を超えた場合は、
どんな追加サービスも受け入れられない危険性があります。
外付け RAM のある AP がサポートできる RX リンク数は 250 なので、230 という RX リンク数は、警告を出すのに適したしき
い値です。
5.3.2
全モートにわたる繰り返し
以下のテストは、各モートで個別に実行されます。
numGoodNbrs < 3
ネットワーク内のすべてのモートには、品質スコアが 0.5 を超える良質の隣接モートが 3 つ必要です。マネージャは良質な隣
接モートの数を常に把握しているので、各モートに 3 つ以上の良質な隣接モートがあることをマネージャが報告していれば
済みます。
リンクが飽和状態に近いモート
前述したように、すべての経路について numLinks を合計して、上流の TX リンク数と RX リンク数を合計します。Eterna モー
トが格納できるのは合計 200 リンクなので、保有リンク数が 150 を超えるモートはボトルネックが生じる危険性を示す可能
性があります。
SmartMesh IP アプリケーションノート
30/140
AP より多い参加回数
モートが稼働状態に遷移した回数を数え、AP についても同じ回数を数えます。モートの参加回数が AP より多い場合、モー
トはリセットして再参加していることを意味します。モートのリセットは、特にそれが集団で発生した場合は、ネットワークに
何らかの異常があるという最大の兆候です。
複数の片親モート
片親のモートがちょうど 1 つ存在する必要があり、このモートは AP を親としている必要があります。そうでない場合は、ネッ
トワーク内のいくつかのモートに不十分な接続が存在します。他の片親のモートの親の近くに中継モートを追加することを
検討してください。
不十分な帯域幅
マネージャは要求帯域幅と割り当て帯域幅をモートごとに把握しています。ここで報告された帯域幅はモートのリンク間での
平均時間なので、数値が低いと 1 秒当たりのリンク数が増えることになります。totalNeededBw > assignedBW であること
を確認してください。
その他のテスト
• モートはモートのキューの占有状況に関する詳細も報告します。このデータを使用して、より多くの健全性チェックを
実行できます。
• getMoteInfo API は平均待ち時間に関する情報を返します。これを継続的にモニタし、待ち時間が予想外に長くなっ
た場合はフラグを立てます。
5.3.3
全経路にわたる繰り返し
ネットワークの経路ごとに収集した HR 情報の 15 分のスナップショットを格納しました。これらの全経路のスナップショット
を繰り返して、疑わしい経路データの有無を確認します。
安定性の低い RSSI
• RSSI が -80dBm を超え、かつ安定性が 50% 未満
• RSSI が -70dBm を超え、かつ安定性が 70% 未満
これらの経路は開発中の「RSSI- 安定性」滝型曲線の下に位置します。ここにいくつか孤立値がある場合、あまり心配する必
要はありません。継続してしきい値より低い値を示す場合には、ハードウェアの問題か、周囲に干渉電波があることを示して
いる可能性があります。詳細については、アプリケーションノート：
「干渉の影響の特定および軽減」を参照してください。
「RSSI- 安定性」ペアごとに HR の時間を得られたら、孤立点の時間をプリントアウトして、孤立点が一時的に集まったかどう
かを確認するのは簡単です。
SmartMesh IP アプリケーションノート
31/140
5.3.4
ネットワークの検査
以下はネットワーク全体として検査できる特性です。
信頼性 < 99.9%
マネージャは全体的な信頼性の粗い基準を、最も近いパーセント値に丸めて、 getNetworkInfo API が返す netReliability
として維持します。信頼性は「9 の桁数」
という尺度で表されることが多いので、高精度な値が要求されます。SmartMesh ネッ
トワークは、9 が 3 桁以上並ぶ信頼性を目標に設計されています。
上記の変数から計算される総合的な信頼性は、100.0*(1-networkLost/(networkLost + networkRX)) です。
可用性 < 99%
ネットワークの平均可用性を得るには、以前に測定したモートごとの可用性の平均値をとります。
5.4
グラフ化
アプリケーションを継続的に実行する場合、上記の量はそれぞれ 15 分の分解能でプロットできます。昼間と夜間の間で干渉
電波や動いている機械類の状況が大きく異なる産業環境に配置されたネットワークでは、ネットワークの安定性および待ち
時間に日々のリズムがあることがこれまでに分っています。これらの測定結果を長時間追跡すると、たいていの場合は 1 つの
スナップショットよりも多くのことが判明します。
SmartMesh IP アプリケーションノート
32/140
6 アプリケーションノート：SmartMesh IP のデータ発行
このノートでは、OEM マイクロプロセッサのファームウェア・アプリケーションがネットワーク内のモートに接続し、ワイヤ
レス・ネットワークを介してモートにデータを送信させるために必要な具体的な手順について説明します。
「SmartMesh IP
ユーザー・ガイド」と「SmartMesh IP Mote API Guide」からの主要な概念はここに集約されています。ユーザー・ガイドで
は、モートと OEM マイクロプロセッサがどのようにやりとりし、一緒になってシステムを形成するかの詳細を説明しています。
6.1
要求パケットと応答パケットの書式
「SmartMesh IP Mote API Guide」で説明されているように、すべてのパケットは HDLC カプセル化を使用する必要があり
ます。これは、パケットの前後にフレーミング・バイト0x7E があることを意味します。対象のパケットについて2 バイトのフレー
「Mote API Guide」
ム・チェック・シーケンス（FCS）を計算し、末尾のフレーミング・バイトの前に付加する必要があります。
の「Protocol」セクションにある「Packet Format」で説明されているように、ペイロードまたは FCS の 0x7D および 0x7E
の値にはエスケープ処理が必要です。
フラグ
ペイロード
FCS
フラグ
7E
パケット・ペイロード
2 バイト
7E
6.1.1
ヘッダ
要求パケットと応答パケットのペイロードは、どちらも 3 バイトのヘッダで始まります。先頭バイトは送信または応答の際の
コマンドまたは通知のタイプを示します。次のバイトは残りのペイロードの長さです（ヘッダまたは応答コードは数えませ
「Mote API Guide」の「Protocol」セクショ
ん）。3番目のバイトは一連のフラグです。ヘッダとフラグの詳しい説明については、
ンにある「Packet Format」を参照してください。
要求
ヘッダ
ペイロード
3 バイト
要求ペイロード
応答
ヘッダ
応答コード
ペイロード
3 バイト
1 バイトの応答
応答ペイロード
長さバイトには 3 バイトのヘッダまたは応答コードは含まれていません。
SmartMesh IP アプリケーションノート
33/140
6.1.2
フラグ・バイト
3 バイトのヘッダの 3 番目のバイトはフラグ・バイトです。現在、フラグ・バイトで使用できるのは以下の 3 ビットだけです。
ビット 0 - 要求 / 応答：ビット 0 はパケットが要求の場合はクリア（0）され、パケットが応答の場合はセット（1）されます。アク
ノリッジ（ACK）パケットは応答パケットなのでこのビットをセットしておく必要があります。
ビット 1 - パケット ID：OEM マイクロプロセッサによる新しい要求パケットごとに、パケット ID ビットを ON/OFF する必要が
あります。
ビット 3 - SYNC ビットの設定ルール：SYNC ビットは、OEM マイクロプロセッサがモートに送信する先頭の要求パケットで
セット（1）する必要があります。それに続く要求に対しては、このビットをクリア（0）する必要があります。SYNC ビットは起
動イベント・パケットにセット（1）されます。このパケットは、モートから OEM マイクロプロセッサに送信される最初の要求
パケットです。
6.2
基本手順
モートをネットワークに参加させ、データの発行を開始するために、OEM マイクロプロセッサが実行する必要がある手順は
全部で 6 つあります。OEM マイクロプロセッサのシリアル・ポートのセットアップは、その後の通信を正常にするためには非
常に重要な第 1 段階です。単純な発行アプリケーションのサンプル・ファームウェアを生成するために必要なのは、以下の
処理をコード化し、マイクロプロセッサとモートのシステムを構築してデータの発行を開始することだけです。手順は以下の
とおりです。
1. シリアル・インタフェースをセットアップする
2. モートの起動イベントにアクノリッジを返す
3. 参加前のモートの構成を実行する
4. join コマンドを発行する
5. 参加の進行をモニタする
6. データを発行する
1. シリアル・インタフェースをセットアップする：OEM マイクロプロセッサとモートとの通信は、デフォルトでは 4 線式プロトコ
ル（UART モード 4：TX、RX、UART_TX_CTSn、UART_TX_RTSn の各線）を使用して API シリアル・ポート上で行われます。
デフォルトでは、API ポートの設定は、ボーレートが 115.2Kbps、8 データ・ビット、パリティなし、1 ストップ・ビットです。
LTC5800-IPM のボーレートは、ヒューズ・テーブルのプログラミングをモート上で更新することにより、必要に応
じて 9600 に変更できます。
2. モートの起動イベントにアクノリッジを返す：モートは、電源投入（またはリセット）時に必ず起動イベント・パケットを API
ポートに送信します。起動イベント・パケットの内容は次のとおりです。
7E 0F 09 08 00 00 00 01 01 00 00 00 00 D7 67 7E
SmartMesh IP アプリケーションノート
34/140
モートは、OEM マイクロプロセッサによって明示的にアクノリッジが返されるまで、
このパケットを送信し続けます。シリアル・
ポートの設定が正しい場合、マイクロプロセッサは受信バッファにこのパケットが現れるのを認識できるはずです。マイクロ
プロセッサのシリアル・ポートが正しく構成されていない場合は、オシロスコープまたはロジック・アナライザを使用してこ
のパケットをモートの Tx ピンで観察できます。電源投入後、このパケットを受信するまで、通常は約 1 秒かかります。
このイベントへの ACK パケットの内容は次のとおりです。
7E 0F 00 01 00 FF 57 7E
OEM マイクロプロセッサは、モートによる起動イベント・パケットの送信を停止するため、このパケットに応答する必要があ
ります。この ACK に応答すると、モートは状態 0（Init）から状態 1（Idle）に移ります。
3. 参加前のモートの構成を実行する：モートの起動イベントに対してアクノリッジが返され、モートが Idle 状態である場合、
そのモートはネットワークへの参加準備が完了しています。join コマンドを発行する前に、 1 つまたは複数の参加前構成設
定を変更したい場合があります。これらの設定は、最初は工場出荷時の設定のままになっていることがありますが、動作が
最適になるように後で調整してください。これらの構成パラメータの一部を以下に示します。
• setParameter <networkId>：デフォルトのネットワーク ID は 0x04CD（1229）です。
• setParameter <joinKey>：デフォルトの参加鍵は 0x 445553544E4554574F524B53524F434B です。最高レベ
ルのセキュリティを確保するため、各モートには固有の参加鍵が必要です。
• setParameter <joinDutyCycle>：デフォルトは 0xFF つまり100%（全部で 255）です。
「Commands」セクションでは各 API の詳細を説明しており、
「Definitions」セクショ
「Mote API Guide」を参照してください。
ンでは引数の符号化について説明しています。
以前は別の値に設定されていたと仮定して、 joinDutyCycle パラメータを 0xFF つまり100%（255）に変更するパケットの
内容は次のとおりです。
7E 01 02 08 06 FF 2F 60 7E
ヘッダ = 01 02 08 なので、これは setParameter コマンド（0x01）、ペイロードの長さ = 2 バイト（0x02）、およびビット 3
を設定したフラグ・バイト（SYNC、要求、パケット ID = 0）です。
ペイロード = 06 FF なので、これは変更される joinDutyCycle（0x06）で、値は 100%、つまり255（0xFF）です。
ここでは、
これをモートに送信する最初のコマンドとしているので、SYNCビットは H です。
これが最初の要求パケッ
トではない場合、OEM マイクロプロセッサはモートに送信し、SYNC フラグの設定解除（ビット 3 = 0）を確認します。
その後、モートは次の応答内容で応答します。
7E 01 01 09 00 06 A0 21 7E
ヘッダ = 01 01 09 なので、これは setParameter コマンド（0x01）、ペイロードの長さ = 1 バイト（0x01）、およびビット 3 と
0 を設定したフラグ・バイト（SYNC、応答、パケット ID = 0）です。
SmartMesh IP アプリケーションノート
35/140
応答コード = 00 なので、コマンドにエラーはありません（0x00）。
ペイロード = 06 ですが、これは変更される前の joinDutyCycle です（0x06）。
4.join コマンドを発行する：これで参加前構成が完了したので、 OEM マイクロプロセッサは、ネットワークへの参加処理を
開始するよう促す join コマンドをモートに発行する準備が整いました。これがモートへの最初のパケットではないので（この
場合は SYNC=0）、参加パケットは次のようになります。
7E 06 00 02 07 33 7E
モートはアクノリッジを返して次のように応答します。
7E 06 00 03 00 2C 9D 7E
5. 参加の進行をモニタする：参加の進行中に、モートはアクノリッジが必要ないくつかのイベント通知を OEM マイクロプロ
セッサに送信します。これらの通知は次のとおりです。
モートの joinStarted 通知：
7E 0F 09 02 00 00 01 00 03 00 00 00 00 C6 DB 7E
OEM マイクロプロセッサのアクノリッジ：
7E 0F 00 03 00 4F 64 7E
モートの operational 通知：
7E 0F 09 00 00 00 00 20 05 00 00 00 00 A5 A2 7E
OEM マイクロプロセッサのアクノリッジ：
7E 0F 00 01 00 FF 57 7E
モートの svcChange 通知：
7E 0F 09 02 00 00 00 80 05 00 00 00 00 29 7A 7E
OEM マイクロプロセッサのアクノリッジ：
7E 0F 00 03 00 4F 64 7E
SmartMesh IP アプリケーションノート
36/140
「SmartMesh IP Mote API Guide」で説明されているように、
6. データを発行する：独自のパケットを送信するには、
sendTo コマンドを使用する必要があります。特定の宛先にデータを送信するには、その前にソケットを開いて宛先にバイン
ドする必要があります。パケットのデフォルトの宛先はマネージャです。この処理については、
「SmartMesh IP ユーザー・ガ
イド」の「通信」セクションで説明されています。
手順は以下のとおりです。
1. openSocket コマンドを呼び出して、通信ソケットを開きます。これにより、ソケットの socketID が分ります。現時
点では UDP ソケットだけがサポートされています。
2. bindSocket コマンドを呼び出して、ソケットをポートにバインドします。ポートは、 sendTo コマンドで使用する
destPort です。
3. sendTo コマンドを使用してデータを送信します。serviceType、priority、packetId の他に、ペイロードとソケット
の情報も指定する必要があります。これらについては「Mote API Guide」の sendTo の記述で説明されています。
現在は（待ち時間とは異なり）帯域幅サービスだけがサポートされています。開通しているソケットでは、 sendTo
を繰り返し呼び出すことができます。
4. 特定の宛先にデータを送信する必要がなくなった場合は、closeSocket コマンドを呼び出します。これにより、ポー
トのバインディングが除去され、ソケットに関連付けられていたメモリが解放されます。ソケットは各パケットの送
信後に毎回閉じる必要はありません。
各手順では、マイクロプロセッサがパケットをモートに送信し、その後アクノリッジを受信することが必要になります。
1.openSocket を呼び出す - これにより、UDP ソケットが開きます。
7E 15 01 00 00 F4 0B 7E
モートのアクノリッジは次のとおりです。ソケット ID 22（0x16）を返します。
7E 15 01 01 00 16 B3 6E 7E
2.bindSocket を呼び出す - 任意のポートを使用できますが、0xF0B8 ∼ 0xF0BF の範囲内のポートを使用した場合、ペイ
ロードは最大になります。この例では、以前に取得した UDP ソケットがポート 0xF0B8 にバインドされます。
7E 17 03 02 16 F0 B8 D3 9B 7E
モートのアクノリッジは次のとおりです。
7E 17 00 03 00 26 42 7E
3.sendTo を呼び出す - このパケットでは、サンプル・データ 0xAABBCCDDEE が、パケット ID 0（0x0000）とともにマネー
ジャ（destAddr = 0xFF020000000000000000000000000002）に送信されるペイロードです。その他のフィールドにつ
いては、
「Mote API Guide」を参照してください。ペイロードが異なる場合は FCS も異なることに注意してください。
7E 18 1C 00 16 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 F0 B8 00 00 00 00 AA BB CC DD EE AF
B2 7E
SmartMesh IP アプリケーションノート
37/140
モートのアクノリッジは次のとおりです。
7E 18 00 01 00 7F C3 7E
パケットを Tx キューに送信すると、モートは送信が終了した時刻を示す通知を送信します。これにも同様に応答する必要が
あります。
パケット ID が 0（0x0000）のモート txDone 通知は次のとおりです。
7E 25 03 00 00 00 00 A4 7B 7E
マイクロプロセッサのアクノリッジは次のとおりです。
7E 25 00 01 00 02 04 7E
sendTo コマンドでパケット ID を 0xFFFF に設定すると、txDone 通知は生成されなくなります。
4.closeSocket を呼び出す - メッセージをこの宛先に送信するのが完了したら、使用していたソケットを閉じることを推奨
します。よくあるのは、通信がインターネット・ホストからのメッセージによる応答である場合で、有限の「トランザクション」
が行われている場合です。周期的な発行が設定されているセンサでは、ソケットが閉じられるのは、マイクロプロセッサがリ
セットする必要がある場合だけです。
これは closeSocket コマンドにより、次のように行うことができます。
7E 16 01 02 16 3E 68 7E
モートのアクノリッジは次のとおりです。
7E 16 00 03 00 8D 5E 7E
SmartMesh IP アプリケーションノート
38/140
6.3
次の段階
データ・ペイロードをマネージャに正常に送信したので、
「Mote API Guide」で他のコマンドやカスタマイズ・オプションの
詳細を調べることができます。
• 無線テスト・コマンド - これらのコマンドは製造検査に使用して、最上位の組み立て（例：アンテナが正しく接続され
ていること）を検査することができます。
「SmartMesh IP Mote API Guide」で詳しく説明され
無線テスト・コマンド（testRadioTx および testRadioRx）は、
ています。
• 帯域幅サービス
いったん稼働状態になると、モートはワイヤレス・ネットワークを介してデータを送信可能になります。デフォルトで
は、すべてのモートが、サービスを要求しなくても 9 秒間隔（IP ネットワークの基本帯域幅）でデータを発行できるよ
うに IP ネットワークは構成されています。これで常に十分である場合は、OEM マイクロプロセッサがマネージャに
サービスを要求する必要はありません。すべてのモートが同じレートでデータを発行する状況で、
（温度、湿度、電
圧、電流のような）センサ・データをアプリケーションが 9 秒より短い間隔で要求する場合、これは同種帯域幅ネット
ワークであり、基本帯域幅を上げる方法が適しています。アプリケーションが、さまざまなデバイスに対してさまざま
なレートでデータ発行を呼び出す場合、これは異種帯域幅ネットワークであり、すべてのデバイスがサービスを要求
する方法が適しています。サービスは実装が容易で最も柔軟性が高いので、 OEM インテグレータは常にサービス
を使用することを推奨します。サービスについては、
「SmartMesh IP ユーザー・ガイド」の「サービス」セクションと、
「SmartMesh IP ユーザー・ガイド」の「帯域幅のレイテンシ」セクションで説明されています。
• ソケットと UDP ポート
これらについては、
「SmartMesh IP ユーザー・ガイド」の「通信」セクションで詳しく説明されています。
SmartMesh IP アプリケーションノート
39/140
7 アプリケーションノート：LTC5800-IPR ベースのネットワーク
での通知の管理
WirelessHART マネージャとは異なり、LTC5800-IPR ベースのマネージャはネットワーク状態に応じて通知を制御しま
せん。通知は、各モートで約 14µA の平均電流を消費するので、低トラフィックのモートにとっては大きな値になります。
LTC5800-IPR は setAdvertising API によって通知の有効化 / 無効化が可能なので、このオーバヘッドを容認できない場合
には、ホスト・アプリケーションがロジックを実装して通知を制御できます。このアプリケーションノートでは、この目的で状
態マシンの例を示します。
通知をオフにすると、新しいモート、または離脱したモートは、ネットワークの検出および参加ができません。その
ため、通知はオンのままにしておくことを推奨します。
7.1
状態マシンの通知
マネージャが起動すると、通知は自動的にオンになります。autoStartNetwork が有効化された場合、これはマネージャがリ
セットしたか起動したときです。autoStartNetwork がディスエーブルされた場合、これはホスト・アプリケーションによって
startNetwork コマンドが発行されたときです。
状態マシンには以下のロジックが必要です。
• モートが存在しない場合は通知をオンのままにしておきます。AP 以外のデバイスに対する moteOperational イベン
トが発生するまでは、通知をオンのままにしておきます。
（moteJoin ではなく）moteOperational 通知を待つことに
より、起動した後で参加を完了できないモートも引き続きネットワークを検出できることが保証されます。
• 「最後」のモートが参加した後に非アクティブ化します。最後の moteOperational イベント後に適したタイムアウト値
（例：1 時間）があるはずです。
• モートが離脱したら再度アクティブ化します。moteLost イベントまたは moteReset イベントが発生したら、通知を
再開します。
• タイムアウト時間内にモートの離脱またはモート参加のリセットがなかった場合は非アクティブ化します。動作時の消
費電力を最小限に抑えるため、最後の moteLost イベントまたは moteReset イベント後に適したタイムアウト値（例：
1 時間）があるはずです。離脱したデバイスがタイムアウト時間内に再参加しないと、通知が別の理由で再開される
まで再参加できなくなるので注意してください。
• ユーザーが新しくモートをシステムに追加する場合は、通知を再開します。
SmartMesh IP アプリケーションノート
40/140
8 アプリケーションノート：短期のデータ・バーストに備えた
ネットワークの構成
8.1
はじめに
すべての SmartMesh マネージャにはさまざまな構成用「調整つまみ」があり、
これを使用して、モートの平均消費電力やメッ
セージ待ち時間などの主要なネットワーク性能を調整できます。ネットワークを調整して特定の問題を解決するには、いくつ
かの異なる方法があると考えられます。本書では、ネットワークの例を示し、構成の変更が性能に与える影響について調べ
ます。まず、ネットワークの要件を提示し、次にネットワークを調整できる 5 つの異なる方法について、アプリケーションに対
する各方法の長所と短所を示しながら詳しく説明します。
電力の計算は、 SmartMesh Power and Performance Estimator の「32 mote small cloud network」の設定を使用して
行います。このネットワークには 3 種類のホップがあり、16 個の第 1 ホップ・モート、10 個の第 2 ホップ・モート、6 個の第 3 ホッ
プ・モートで構成されます。残りのパラメータはデフォルトのままです（安定性は 80%、ペイロードは 80 バイト）。
8.1.1
ネットワーク要件とサービス要求
検討中のネットワークは 32 モートの SmartMesh IP ネットワークです。すべての要件の説明を以下に示します。
• モートの半数はマネージャの無線範囲内にあります（「1 ホップ」のモート）。
• すべてのモートは 5 秒ごとに 1 パケットを報告します。
• 時により、モートはデータの「バースト」を 1 秒間隔で生成することがあります。
• 設定は 80% の安定性で機能する必要があります。この値は、干渉やマルチパス・フェージングが中程度の屋内配置
では標準的です。
• 顧客が電力節減のために通知をオフしました。通知管理については、分析の最後に説明します。
トレードオフについて説明します。
以下の 5 種類のネットワーク構成では、設定を少し調整してわずかに異なる性能を実現し、
この分析に固有の要素であるデータ・バーストに対する応答に注目します。各構成では、マネージャは少なくとも十分な帯
域幅を確保して、 5 秒間隔の報告による規則的なネットワーク動作に対応しますが、ネットワークがデータ・バーストに対し
て動的に応答する様子は各構成で異なります。
8.2
ネットワーク 1：基本構成
ネットワーク
• 上りスロットフレーム・サイズ：256（公称）
• 下りスロットフレーム・サイズ：256（公称）
• 基本帯域幅：5000（ms）- この値は、5 秒という発行レートに対応するため、デフォルトの 9000ms から変更しました。
この変更は、CLI での set config basebw か、setNetworkConfig API を使用して実行できます。
SmartMesh IP アプリケーションノート
41/140
顧客のセンサ・プロセッサ
• 発行間隔：5 秒 - これは基本帯域幅で確保されているので、デバイスは特にサービスを要求する必要はありません。
• バースト間隔：1 秒
予想平均性能
• ホップごとの待ち時間（秒）
：[0.3、0.8、1.5]
• ホップごとの電力消費（µA）
：[62、47、29]
• ホップごとの上りTX/ 秒：[2.5、1.5、1.0] リンク / 秒
• ホップごとの上りトラフィック / 秒（安定性により調整）
：[0.65、0.40、0.25] パケット / 秒
• 下りトラフィック（安定性により調整）
：0.4 パケット / 秒
5 パケット / 秒ではなく1 パケット / 秒で所定のモートから送信を開始する場合は、割り当てられている基本帯域幅リンクがそ
のモートをサポートできるかどうかを判断する必要があります。リンク / 秒の数値がパケット / 秒の数値より大きい限り、モー
トを短期間サポートできますが、ネットワーク上の使用経路が安定していることが前提です。
• 1 ホップのモートでは、通常のプロビジョニングによって可能になります。上りトラフィックは 1.65 パケット / 秒になり、
2.5 リンク / 秒のしきい値より低い値です。待ち時間は 0.3 秒のままです。
• 2ホップのモートでは、通常のプロビジョニングによって可能になります。上りトラフィックは1.4パケット/秒になり、1.5
リンク / 秒のしきい値より低い値です。待ち時間は 0.8 秒のままです。
• 3 ホップのモートでは、安定性の影響で上りトラフィックが 1.25 パケット / 秒に増加するので、モートをサポートする
には TX リンク / 秒の数値（すなわち 1.0）では不十分です。アプリケーションは実際の出力の 0.8 パケット / 秒に抑えら
れ、待ち時間はパケットの渋滞に応じて増加します。
経路安定性が変化すると、最初のホップと 2 番目のホップのモートがプロビジョニング不足の状態になる可能性があります。
この例では、安定性が 60% に低下すると 2 ホップ・モートが危険にさらされます。センサ・プロセッサは前出のレートで発
行する前に、1 秒のサービスを要求し、終了したらサービスを削除することを推奨します。
アルゴリズムは以下のとおりです。
1. センサ・プロセッサは、可能な場合、バースト開始の約 10 秒前に 1 秒のサービスを要求します。
2. センサ・プロセッサは、バースト・レートで直ちに発行を開始します。
3. センサはモートによって阻止されるまでバースト・レートで送信します。その時点では、センサ・プロセッサは推奨
のバックオフ・ガイドラインに従います（詳細については、
「サービス」を参照）。
4. サービス要求が許可されると、センサ・プロセッサは最高速度で再開できます。
5. バーストが完了したら、1 秒のサービスを削除します。
これらの条件では、サービスの要求があってから 7.5 秒以内に必要なリンクが追加されることが期待できます。場合によって
は、モートがリンクを追加されるより前にバースト・トラフィックが終了することがあり得ます。この場合、モートはとにかくサー
ビス削除コマンドを送信します。
SmartMesh IP アプリケーションノート
42/140
時間の経過に伴って処理がどのように進むかを以下に示します。
図 1 - モートのバースト期間中の一連のパケット
バーストに入る前には、モートは、アプリケーションがパケットを引き渡すと、速やかにパケットを送信できます。バースト・
モードが始まると、モートは NACK を返し始め、それに応じてアプリケーションはパケットの送信を抑えます。モートがサー
ビス要求に応じて新しいリンクを獲得すると、アプリケーションはバースト・パケットを生成すると同時にそれを送信すること
ができます。
8.3
ネットワーク 2：より長い下りスロットフレーム
消費電力を節減するため、ユーザーは下りスロットフレームのサイズを制御できます。こうすると下りのアイドル・リスニン
グが減少するので平均電流は減少しますが、リンク / 秒の数値も小さいので、下りの帯域幅も減少します。
ネットワーク
• 上りスロットフレーム・サイズ：256（公称）
• 下りスロットフレーム・サイズ：1024（最長）- これを実行するには、set config dnfr_mult という CLI コマ
ンドを使用する（有効にするにはリセットが必要）か、 setNetworkConfig API を使用してリセットを実行するか、
setDownstreamFrameMode API を使用します。
• 基本帯域幅：5000 - ネットワーク 1 の構成と同じ
顧客のセンサ・プロセッサ
• 発行間隔：5 秒
• バースト間隔：1 秒
予想平均性能
• ホップごとの待ち時間（秒）
：[0.3、0.8、1.5]
• ホップごとの電力消費（µA）
：[54、39、21]
上りの待ち時間および定常状態の動作は基本構成と同じですが、下りに送ることができるパケットが 0.1 パケット / 秒と少な
くなる点が異なります。バースト・モードでリンクを追加するには、 30 秒かかります。バースト・パケットの渋滞はホップに
より変わってきますが、下りのスロットフレームがより長いときは、バーストが発生することが事前にわかれば、なるべく早く
サービス要求する必要があります。
SmartMesh IP アプリケーションノート
43/140
8.4
ネットワーク 3：高い消費電力、短い待ち時間
これまではバースト間に相関関係がない、つまり、一度に 1 つのモートだけがバーストを発生すると考えてもいいほど発生
頻度が低い場合を考えていました。
今回、ネットワークを変更し、すべてのモートが同時にバーストを発生しても、それをサポートすることを考えます。
ネットワーク
• 上りスロットフレーム・サイズ：256（公称）
• 下りスロットフレーム・サイズ：256（公称）
• 基本帯域幅：1500 - すべてのモートが同時にバーストを発生できるように基本帯域幅を広げました。
顧客のセンサ・プロセッサ
• 発行間隔：5 秒
• バースト間隔：1 秒
予想平均性能
• ホップごとの待ち時間（秒）
：[0.3、0.6、1.2]
• ホップごとの電力消費（µA）
：[68、51、29]
ここでは、すべてのモートが 1 秒ごとに同時にパケットを送信できるようにネットワークを準備しましたが、消費電力の計算
では、すべてのモートが 5 秒間隔で発行していると仮定しています。これは、バースト時間が十分短いので、平均消費電力に
はあまり影響しないと仮定しています。ここでの利点は、バースト時間中にサービスの承認とリンクの追加を待つ期間がなく、
任意の数のバーストが安全に並行して発生可能であることです。
3 番目のホップのモートは TX リンクを追加するだけなので、これらのモートでは電力が増加しないことに注意してください。
TX に割り当てられたリンクは、実際にパケットを送信するために使用されない限りエネルギーを消費しません。また、これ
らのモートでは送信するパケットが増えず、パケットを送信することができる機会が多くなるだけです。RX に割り当てられた
リンクはパケットを受信してもしなくてもエネルギーを消費するので、最初のホップと 2 番目のホップのモートの両方で消費
電力が増加することが分ります。
このセットアップは AP の RX リンクの限界に近づくので、あまり多くの帯域幅をネットワークに割り当てることはできません。
SmartMesh IP アプリケーションノート
44/140
8.5
ネットワーク 4：バックボーンの例
ネットワーク
• 上りスロットフレーム・サイズ：256（公称）
• 下りスロットフレーム・サイズ：256（公称）
• 基本帯域幅：5000
• 上りの 64 スロットのバックボーン・スロットフレーム（0.464 秒）- これを構成するには、set config bbmode およ
び set config bbsize CLI コマンドを使用する（有効にするにはリセットが必要）か、setNetworkConfig API を
使用した後にリセットを実行します。
予想平均性能
• 64 スロットの上りバックボーンには 15µA が流れますが、流れる場所は親だけです。
• ホップごとの待ち時間（秒）
：[0.2、0.4、0.6]
• ホップごとの電力消費（µA）
：[77、62、29]
バックボーンは、 ZigBee ネットワークのスロット化バージョンと同様に、モートが送信機会を共有する競合ベースのフレー
ムです。弊社のネットワークでは、バックボーンはネットワークに割り当てられた専用帯域幅と並行して動作します。バック
ボーンのマイナス面は、すべての親モートが同じ量を受信することです。これは弊社の通常のリンクのカスケード接続とは異
なる状況です。カスケード接続内では、AP に近いモートがより下位のモートのトラフィックを転送するので、AP に近いモー
トの受信量が多くなります。すべての親が有線で電源を供給されていて、パケット・バースト時またはアラーム時の待ち時間
を非常に短くしたい場合、バックボーンはとても優れたオプションです。この場合は、親モートに電力の制約がないので、1
または 2 スロット長の非常に短いバックボーン・フレームを挿入できます。ただし、消費電力がネットワーク 3 に匹敵するほ
ど低いネットワークに使用できるような省電力のバックボーンも設計することができます。
弊社の 64 スロットの上りバックボーンでは、任意の 1 モートが予告なくバーストを開始した場合に必要なトラフィックを伝送
するための十分な予備帯域幅が確保されます。さらに、バックボーンはすべてのモートの通常動作時の平均待ち時間を短縮
します。通常の上りTX リンクと同様に、バックボーンはリーフ・モートに余分な電力を必要としません。バックボーンはサー
ビス要求モデルと併用することを引き続き推奨します。この場合、バックボーン・リンクは、アプリケーションを抑制する必要
なく、一度に約 1 モートの割合でパケットを即座にバースト送信できるブリッジを実現します。これらのバースト・イベントが、
256 スロットの下りフレームでは 7.5 秒、スロットの下りフレームでは 30 秒で区切られる限り、バックボーンにサービス・リン
クを追加した組み合わせでは、妨害を受けない発行が可能です。
待ち時間と電力の結果をネットワーク 3 と比較した場合、バックボーン・リンクを使用して、専用帯域幅単独で得られる値よ
り待ち時間を多少短くすることができますが、その代償として消費電力が多少増加します。ただし、ネットワーク 3 では、全て
のモートが同時にバースト送信する場合にも、追加サービスを要求する必要がありませんでした。
SmartMesh IP アプリケーションノート
45/140
8.6
ネットワーク 5：スター型ネットワーク
ネットワーク
• 上りスロットフレーム・サイズ：256（公称）
• 下りスロットフレーム・サイズ：1024（最長）
• 基本帯域幅：5000
• すべてのモートには非ルーティングを指定 - これは setParameter<routingMode> API を使用してモート上で構成
されます。
顧客のセンサ・プロセッサ
• 発行間隔：5 秒
• バースト間隔：1 秒
予想平均性能
• ホップごとの待ち時間（秒）
：[0.7]
• ホップごとの電力消費（µA）
：[19]
絶対的に最も低い消費電力のネットワークを得るため、すべてのモートを「非ルーティング」にすることができます。これは、
すべてのモートは子モートを持てないという意味であり、ネットワークは AP をすべてのモートの唯一の親とするスター型ト
ポロジとして構築されます。マルチホップ・ネットワークは不可であり、すべてのモートは AP の無線範囲内に配置されてと
メッシュ型ネットワーク2 のリー
どまっている必要があります。この設定では、すべてのモートは約 19µA を消費します。これは、
フ・ノードよりわずか 2µA 少ない値です。存続期間の観点から調べるには、 Power and Performance Estimator をもう一
度使用できますが、今回は「Battery Life」タブを使用します。CR2450 コイン電池を使用する例として、非ルーティング・モー
トは 3.1 年持続するのに対して、ネットワーク 2 のより信頼性の高い解決策での持続期間は 2.8 年です。
この制約を設けることにより、モートは単一の経路に障害が発生したときにリセットしてしまいます。また、モートにはこの親
経路に対して選択肢が１つしかないので、こうした状況の発生頻度はメッシュの場合よりも大幅に高くなります。単一障害点
がモートごとに存在するので、ネットワーク全体をこの構成にすることは推奨しません。大半のモートのバッテリ容量がルー
ティング・レベルで、少数のモートは環境エネルギー源を使用するため消費電力が厳しく制限されている異種のネットワー
クでは、モートを非ルーティングに設定することを推奨します。こうしたネットワークでは、ルーティング対応モートがマルチ
ホップ・メッシュを実現し、環境エネルギー源の非ルーティング・モートは可能な限り低消費電力にすることができます。
SmartMesh IP アプリケーションノート
46/140
8.7
通知の管理
アプリケーションは IP ネットワークでの通知制御を担当します。ネットワーク構築中にモートを最初から参加させる場合や、
定常動作時に離脱したモートを再参加させる場合は、通知しているモートの無線範囲内に存在する必要があります。すべて
のモートが安全にネットワーク内に存在する期間中（大部分の時間）は、通知を非アクティブ化して消費電力を低減できます。
これを制御できる方法の簡単なアルゴリズムを以下に示します。
• 通知をオンにした状態でネットワークを起動し、モートが参加しない場合はオン状態を維持します。
• 以下のいずれかの状態になったら、通知をオフにします。
• すべてのモートが参加した
• 最後のモートが参加してから 1 時間が経過した
• 以下のいずれかの状態になったら、通知をオンにします。
• いずれかのモートが離脱した
• このモートが再参加したら再度オフにします。
• 新しいモートが参加することが手動で示された
• 新しいモートが参加したら再度オフにします。
このアプリケーションノートでの電力の数値については、通知が動作停止状態になっていると仮定します。通知が動作状
態のときは、モートは余分に 14µA を消費します。多くの顧客にとっては、この割増電力では、アプリケーションでの通知制
御にロジックの追加を必要とするほど大きくはありません。通知をオフにしているときの消費電流が 54µA で通知をオンに
しているときの消費電流が 68µA であるネットワーク 2 の 1 ホップ・モートを例にとってみましょう。もう一度、 Power and
Performance Estimator の「Battery Life」タブを使用します。このモートに Tadiran 社の AA（単 3）電池を使用する場合、
これは稼働期間にして 4.6 年と 3.6 年の差になります。
SmartMesh IP アプリケーションノート
47/140
9 アプリケーションノート：IP ネットワークでの冗長性確保の
方法
メッシュ型ネットワークでのモートは、あるモートに障害が発生すると、別のモートがそのトラフィック負荷を自動的に引き継
ぐという点で、本質的に冗長性があります。各検出点が重要な箇所では、複数のモートを使用して同じ点を測定します。しか
し、デバイス・マネージャや AP がダウンしたらどうなるでしょう。
一部の SmartMesh WirelessHART マネージャは、コールド・フェイルオーバ機能を備えています。スレーブ・マネージャが
専用のハートビート・シリアル・ポートを介して通信し、マスタに障害が発生した場合にネットワークを引き継ぐよう待機しま
す。この手法では、スレーブ・マネージャが管理してネットワークを改造することと、マネージャを大まかに配置することが求
められます。残念ながら、コールド・フェイルオーバはシングル・チップの SmartMesh IP マネージャでは利用できません。
マネージャを 2 つに分離すると、両方が同時に損傷する危険性が減少するので、火災警報器などのアプリケーションでは利
点となります。これを SmartMesh IP ネットワークまたは SmartMesh WirelessHART ネットワークで行うには、2 つのマネー
ジャを物理的に分離し、モートを 2 つのネットワークに均等に分散させることによって冗長性を確保します。
コスト重視のアプリケーションでは、単一モートが各検出点をモニタします。両方のマネージャを同じネットワーク ID で構成
し、各マネージャのアクセス制御リストにすべてのモートを登録します。このシナリオでの条件は、モートの最終的な参加先
がどのネットワークになるかに関係なく、各モートが適切に接続されるように十分な密度が必要になるということです。一方
のマネージャに参加するモートもあれば、もう一方のマネージャに参加するモートもあります。両方のデータの流れを合成
することと、ある特定のモートとの通信にどちらのマネージャを使用するかを常に把握するのはホスト・アプリケーションの
役割です。
コストは高いが最大の冗長性を得るには、各検出点に 1 対のモートを割り当てます。2 つのマネージャはそれぞれが異なる
ネットワーク ID を取得し、各モート対にはネットワークごとに 1 つのモートが存在します。一方のマネージャに障害が発生す
ると、このマネージャに属するすべてのモートが離脱しますが、各モート対の片方が残ったマネージャに引き続きデータを
報告します。このシナリオでは、両方のマネージャが機能している間は、アプリケーションがすべての検出点で 2 つのレポー
トを処理できることが要求されます。
SmartMesh IP アプリケーションノート
48/140
10 アプリケーションノート：通電バックボーンを使用した待ち
時間の改善
10.1 はじめに
すべての SmartMesh マネージャにはさまざまな構成用「調整つまみ」があり、
これを使用して、モートの平均消費電力やメッ
セージ待ち時間などの主要なネットワーク性能を調整できます。ネットワークを調整して特定の問題を解決する方法は数種
類あります。本書では、SmartMesh IP での通電バックボーン機能を示し、この機能をネットワーク内で使用するべき場合と
そうでない場合について詳しく説明します。通常は略して単にバックボーンと呼ばれますが、このスロットフレームにより、上
り方向または双方向で待ち時間の短い通信が可能になります。上り方向の通信では非通電デバイスで余計なエネルギーを
消費しませんが、双方向のバックボーンを有効化すると、すべてのデバイスで電力の増加が強いられます。
制限事項：
• SmartMesh IP 製品の現行バージョンでは、バックボーンを下り専用にする方法はありません。
• バックボーンのモードおよびサイズはマネージャの起動前に選択されるので、マネージャをリセットせずに変更する
ことはできません。
• バックボーンの動作は、モート参加時に提示される電源設定によって決まります。いったん割り当てられると、参加後
に電源設定を変更してもバックボーンの動作には影響しません。
本書での電力計算例は、SmartMesh Power and Performance Estimator の値を使用して行っています。
10.1.1 全般的な目的
バックボーンは ZigBee のような待ち時間の短い上り通信を実現するために開発されました。ZigBee ネットワークではルー
タが通電されており、すべてのデバイスが 1 つのルータの範囲内に存在する必要があります。上りバックボーンをアクティブ
にした SmartMesh IP ネットワーク（bbmode= 1 を使用して設定）では、モートが通電ノードを親に持つことを前提に、任
意のモートが任意のスロットで送信可能です。
通電ノードは、それ自体がスロットで送信しない場合、子ノードからのパケットを受信します。結果として、非通電デバイス
にはアイドル状態の TX イベントが大量に存在することになりますが、Eterna モートを使用する場合はエネルギーを消費し
ません。通電デバイスにはアイドル状態の RX イベントが大量に存在し、エネルギーを消費します。パケットが到着する場合
に備えて無線を受信モードで動作状態にしておく必要があるからです。上りのバックボーンをより長いスロットフレーム長で
設定できますが、ほとんどのアプリケーションで上手く動作するのは、バックボーンのスロットフレーム長が最短の 1 スロッ
トのときであることがこの後、分ります。長さは bbsize パラメータによって設定され、設定できる値は 1、2、4、および 8 スロッ
トです。
下りバックボーンも同様に機能しますが、今度はすべてのデバイスが受信してエネルギーを消費する必要があることが異な
ります。双方向のバックボーンがアクティブな場合（bbmode = 2 を使用して設定）は、偶数スロットが上りバックボーンに使
用され、奇数スロットが下りバックボーンに使用されます。このように偶数 / 奇数で分けると、2 方向間でトラフィックが衝突
しなくなります。これは不完全な RF 環境での呼び出し応答トラフィックでは非常に重要です。Dust コマンドのトラフィックで
は下りバックボーンを使用せず、ユーザー・トラフィック用の予備にしています。サポートされている唯一の双方向バックボー
ン長は 2 スロット長です。
SmartMesh IP アプリケーションノート
49/140
すべてのバックボーン動作は共有リンク上で行われます。同時に、残りのネットワークは優先度の高い専用リンク上で引き続
き動作します。バックボーン・リンクはそれ以外のすべての動作とはチャネル・オフセットが異なるので、バックボーン上のト
ラフィックが他のバックボーン・トラフィックと衝突する可能性がある場合でも、引き続き専用リンクで行われる信頼性の高
い通信には影響しません。どのような状況であっても、バックボーンが全体の信頼性を低下させることや、ネットワークの待
ち時間を増加させることはありません。
10.1.2 上りバックボーンで RX を有効化する設定
SmartMesh IP モートは、その最大定常状態電流を powerSrcInfo 構造体の maxStCur フィールドの参加要求パケットで
報告します。マネージャは、モートが上りバックボーンで RX リンクを張ることができるようにするためのフラグとして最大
の設定値（0xFFFF）を使用します。この最大の設定値はセンサ・アプリケーションが指定する必要があり、モートが本当に
通電されているか、またはモートに大容量のバッテリ電源がある場合にのみ使用します。これは、バックボーン内に受信リ
ンクがあるモートは 1mA を超える電流を流すことがあるからです。簡単のため、通電モートとして maxStCur = 0xFFFF が
設定されているモートを調べます。すべてのモートは上りバックボーンに TX リンクを張ることができますが、RX リンクは通
電モートにのみ与えられます。setParameter<powerSrcInfo> API の maxStCurrent フィールドを 0xFFFF に設定すると、
ノードは「通電状態」とみなされますが、それ以外の設定では非通電となります。デフォルトでは、ノードの出荷時の設定
は maxStCurrent = 0xFFFE なので、マネージャはバックボーンを呼び出さずに必要に応じてリンクを追加できます。こう
したデバイスは、最も混雑しているネットワークで平均電流が 500µA 未満になると思われます。通電ノードの際立った動作
は、上りバックボーン・スロットフレームで受信リンクを取得することであり、それ以外には通電ノードと非通電ノードのスケ
ジュール間に差はありません。
10.2 アプリケーション 1：低待ち時間アラーム
ネットワーク
• バックボーン・モード bbmode：1
• バックボーン・スロットフレーム・サイズ bbsize：1
予想平均性能
• 待ち時間：約 15ms/ ホップ
• リーフ・ノードでの割増電力：なし
• ルーティング・デバイスでの割増電力：925µA（1 スロットのバックボーン）
• 全トラフィック限度：約 45 パケット / 秒
低待ち時間アラームのネットワークでは、各非通電モートが通電モートの無線到達範囲にあることを確認する必要がありま
す。その後、通電モートは通電バックボーンを形成し、どのモートもこのバックボーンから最大で 1 ホップの距離になります。
そのため、すべてのモートは任意のスロットで送信できます。送信が失敗した場合、バックボーン・スロットが共有されてい
るので、送信側のモートは失敗の原因がパケットの衝突であったとみなします。モートには、この競合ベースの一連のリン
クを正しく使用するために、指数関数的に増加するランダムなバックオフがあります。バックボーンが AP から複数ホップの
位置に広がっても全く構いません。平均的な安定性とバックオフの仕組みを考慮すると、ホップ当たりの平均待ち時間は約
15ms、つまり2 スロットになります。ただし、バックボーンは衝突する可能性があるので、最悪の場合に並列の専用リンクに
よって実現される待ち時間をアプリケーションが許容できる必要があります。
SmartMesh IP アプリケーションノート
50/140
ルーティング目的の場合は、専用の上りリンクとバックボーン・リンクが均等に扱われます。あるモートに上りパケットがあり、
次のスロット内にあるこのモートの親への専用上りリンクもこのモートに存在する場合、このモートはパケットを共有バック
ボーン・リンクではなく専用リンクで送信し、親も専用リンクで受信します。こうなると必然的にチャネル・オフセットが異な
るので、バックボーン・リンク上で送信しようとする同じ親の別の子が最初の送信と衝突することはありません。同様に、モー
トに別のリンク（参加通知受信リンクや下りRX リンク）がある場合、モートによる処理は、上りバックボーン・リンクに対して
ではなく、この別リンクに対して実行されます。また、複数のホップを進むパケットは最終的に専用リンクのいくつかのホッ
プとバックボーン・リンクのいくつかのホップを進むことになります。こうしたことはすべて、モートにとってどちらのリンクが
先に使用できるかと、バックオフが発生するかどうかのランダムな結果として行われます。
これは上り方向の親（通常は 2 つ）のうちの 1 つになります。バックボー
モートのバックボーンの親は一度に 1 つだけですが、
ン・リンクは経路障害を調べる目的には使用されませんが、経路障害がバックボーンの親への専用リンク上で検出された場
合、モートは 2 番目の親へのバックボーンの使用を自動的に開始します。専用リンクはこの 2 番目の親までずっと使用されて
いましたが、この場合もアプリケーションは経路障害中に長い待ち時間に耐えられる必要があります。
上りバックボーンは、あまり多くのデータは送信しないがパケットの生成時は待ち時間を短くする必要があるネットワークに
とって最も有効です。平均待ち時間の要件が 100ms 未満で 30 モートのネットワークでは、専用リンクだけでこれを実現する
のに十分なスロットが AP に存在しません。電力が心配な場合は、長めの bbsize 設定である 2、4、または 8 スロットを使用
できます。これにより、それ相応にルーティング・デバイスの消費電力が減少し、待ち時間が長くなります。
10.3 アプリケーション 2：呼び出しと応答
ネットワーク
• バックボーン・モード bbmode：2
• バックボーン・スロットフレーム・サイズ bbsize：2
予想平均性能
• 往復の待ち時間：約 60ms/ ホップ
• リーフ・ノードによる割増電力：462µA
• ルーティング・デバイスでの割増電力：925µA
• 全トラフィック限度：約 20 パケット / 秒
パケットを単一の宛先に送信する場合、デフォルトの SmartMesh IP ネットワークはパケットの進入（下り）をスロットフレー
ムにつき 1 つに制限します。安定性が不十分な場合、これは 2 秒当たり1 パケットに満たない値です。高速な下りが要求され
るアプリケーションでは、双方向のバックボーンを使用できます。上りバックボーンとは反対に、下りバックボーンはルーティ
ング相当ではありません。内部コマンドのトラフィックは下りバックボーン・リンクを使用せず、下りバックボーンがアクティ
ブのとき、ユーザー・トラフィックは下りバックボーンだけを使用するよう制限されます。
アプリケーション層のタイムアウトを非バックボーン・ネットワークと一致させるため、2 スロットの双方向バックボーンだけ
が使用可能です。
この双方向バックボーンはすべてのデバイスで462µA以上を消費し、デバイスがたまたま上りルータであっ
た場合はさらに 462µA を追加で消費します。経験則から、パケットは AP からモートまで進むことが可能なはずであり、応答
は約 60ms/ ホップ以内に戻るはずです。前と同様、この場合も平均時間であり、より深いホップにあるモートにとってより厳
しい孤立値をアプリケーションが許容できる必要があります。パケットはネットワーク内を並行して進むことができるので、ア
プリケーションがあるモートからの応答を待っている間に別のモートへの呼び出しを開始しても安全です。並列化されてい
る場合、最も高速の双方向バックボーンは 1 秒間に約 20 対の呼び出しと応答をサポートできます。
SmartMesh IP アプリケーションノート
51/140
10.4 アプリケーション 3：すべての低トラフィック・ネットワークでの
短い待ち時間
ネットワーク
• バックボーン・モード bbmode：1
• バックボーン・スロットフレーム・サイズ bbsize：1
予想平均性能
• 1 ホップのモートからの待ち時間：約 15ms
• モートでの割増電力：なし
AP が電力制限デバイスでない場合は、上りバックボーンを使用して、モートでの消費電力を増加させずにネットワーク全体
の待ち時間を短縮できます。このためには、上りバックボーンを起動して、AP に唯一の通電デバイスとしてマークを付けます。
その結果、AP の 1 ホップの子モートだけがバックボーン TX リンクを張ります。これらのリンクが使用されない場合には、モー
トではエネルギーが消費されないことに留意してください。パケットを生成するか子モートからパケットを受信する任意の
1 ホップ・モートは、後続のスロットの AP にパケットを転送できます。マルチホップ・ネットワークでの待ち時間は、ネットワー
クの最初のホップまでは同じ時間のままですが、すべてのパケットが 1 ホップのリングを通過する必要があるので、上りバッ
クボーンがアクティブになった場合は、すべてのモートで平均待ち時間が減少します。
ネットワークに大量のトラフィック（> 合計 15 パケット / 秒）がある場合は、バックボーン・リンクに競合が発生し、伝送は衝突
します。これらの衝突に起因する再試行数の増加は、1 ホップ・モートでの消費電力に影響しますが、これによってスループッ
トが減少することはなく、待ち時間は増加しません。電力の影響を受けやすいアプリケーションの場合は、この 1 ホップ・バッ
クボーンの使用を、トラフィックが少ないと分っている場合に限定することを推奨します。
10.5 バックボーンの不適切な使用 1：専用リンクの置き換え
ネットワーク
• バックボーン・モード bbmode：1
• バックボーン・スロットフレーム・サイズ bbsize：8
予想平均性能
• リーフ・ノードによる割増電力：なし
• ルーティング・デバイスでの割増電力：116µA
上記アプリケーションをすべて読むと、あらゆるものにバックボーンを使いたくなるかもしれません。ただし、バックボーン
が一連の等価な専用リンクより消費電力が多く待ち時間が長い場合がいくつかあります。たとえば、ネットワークには本当に
通電されているモートが存在しないが、上りの待ち時間を、専用リンクだけを使用するネットワークでの結果より少し短縮し
たい場合を考えます。そこで、子モートを持つすべてのモートで消費される余分な 116µA を許容できると考えて、すべての
モートが実際に「通電状態」であると報告し、上りバックボーンのサイズを 8 スロットに増やすことにします。
この場合の上りバックボーンについて効率が悪い部分は、子モートを持つモートが、バックボーン・リンクまで AP と同じ回数
（厳密には 8 スロットに 1 回）を受信する必要があることです。カスケード接続された専用リンクを割り当てると、リンク数が
SmartMesh IP アプリケーションノート
52/140
AP と同数になるモートはなくなります。これはアイドル RX リンクではなくアイドル TX リンクなので、高効率のネットワーク
はできるだけ多くの負担を AP に負わせます。消費電流が 116µA の場合は、より高速な基本帯域幅で同じネットワークを構
築することが可能で、全体の待ち時間が短くなります。また、さらにいいことには、アプリケーション 3 で説明したやり方でこ
のネットワークでの待ち時間を追加コストなしでさらに短縮できます。
実際に、長さが最短ではない上りバックボーンを使用しようとする場合は、オプションを慎重に検討してください。
10.6 バックボーンの不適切な使用 2：トラフィックの多いネットワーク
ネットワーク
• バックボーン・モード bbmode：1
• バックボーン・スロットフレーム・サイズ bbsize：1
• アクセス・ポイントまでの全トラフィック：30 パケット / 秒
• 100 モート
予想平均性能
• ノードでの割増電力：最大 120µA
専用リンクはバックボーン・リンクより優先順位が高いことを思い出してください。ネットワークが混雑している場合、アクセ
ス・ポイントはほとんどのスロットに専用リンクを張って上りトラフィックを受信します。モートはアクセス・ポイントの全スケ
ジュールを知らないので、アクセス・ポイントが専用リンク上での受信で混雑しているバックボーン・リンク上でモートは送
信して失敗をすることが多くなります。このようにバックボーンの帯域幅で競合しているいくつかのモートがある場合は、バッ
クオフがある場合でも、ほとんどのバックボーン送信が失敗します。モートがフルサイズのパケットを送信している場合は、
これらのすべての障害によって、余計な送信試行で最大 120µA を消費することになります。これはルーティング・デバイスに
とっては大きな問題にはなりませんが、全消費電流が 30µA と予想される低消費電力デバイスにとっては重大になることが
あります。このシナリオはネットワークが大きくなるにつれて現れる可能性があります。報告頻度の低い少数のモートから始
めるネットワークでは、バックボーンによって待ち時間が大幅に改善されますが、高速報告モートが追加されるので、これら
元のモートに対する待ち時間のメリットは減少し、元は空きだったバックボーン・リンクは繰り返し失敗するので、多大な犠
牲を強いられるようになる可能性があります。こうしたシナリオでバックボーンを非アクティブ状態にするために、ネットワー
クをリセットする必要があることにも注意してください。
アプリケーション 3 で説明したように、15 パケット / 秒というしきい値は、バックボーンが有益であるか問題となるかを判断
する良い目安です。この場合も、バックボーンをアクティブにすることでパケット待ち時間が増加したり、この混雑したネット
ワークで信頼性が低下したりすることはなく、影響を受けるモートの消費電力が増加するだけです。
バックボーンの障害はパケット障害として数えられるので、過剰に使用されたバックボーン・ネットワーク内のモートによっ
て報告された経路安定性の値は非常に低くなります。安定性の値が 50% より低くなるかどうか注意して、この問題を診断す
るのに役立ててください。これらの対象経路は、
「RSSI- 安定性」滝型曲線を引くと最も明確になります。
SmartMesh IP アプリケーションノート
53/140
11 アプリケーションノート：メッシュ内メッシュの構築
11.1 はじめに
LTC5800-IPR ベースのネットワークは、サブネットの集合として構成して、ネットワークごとに 32 モートまたは 100 モート
の制限がある場合でも非常に大規模な配置を構築できます。低コストのチップ規模マネージャにより、このメッシュ内メッ
シュ配置に手が届くようになります。
「正常」な配置とは、各ネットワークは独立して配置され、各マネージャはホスト・アプリケーションに接続されるというもの
です。これらのホスト・アプリケーションは、WiFi またはイーサネット構内ネットワークに接続した個々のコンピュータで実行
できます。これを図 1 に示します。
凡例
WiFi またはイーサネット
シリアル接続
ワイヤレス・リンク
ホスト・
アプリケーション
ホスト・
アプリケーション
（データ）
マネージャ
（データ）
マネージャ
（データ）
マネージャ
（データ）
モート
（データ）
モート
A
A
A1
B
C
B
B1
C
（データ）
モート
C1
（データ）
モート
C2
（データ）
モート
C3
ワイヤレス・データ・ネットワーク
ホスト・
アプリケーション
インフラ
構内ネットワーク
図 1 - いくつかの独立したワイヤレス・データ・ネットワークがある配置
SmartMesh IP アプリケーションノート
54/140
アプリケーションのシナリオによっては、いくつかのマネージャを広い範囲に配置することで問題が生じる場合があります。
メッシュ内メッシュでは、1 つのワイヤレス・ネットワークがその他のいくつかのワイヤレス・ネットワークのバックホールとし
て機能します。これを図 2 に示します。この図では、標準の SmartMesh IP マネージャと SmartMesh IP モート・ファームウェ
アを実行するデバイス、およびカスタムのファームウェアを実行するデバイスを示しています。
凡例
WiFi またはイーサネット
ホスト・
アプリケーション
シリアル接続
ブリッジ A
ブリッジ B
（バックホール）
モート A2
（バックホール）
モート A3
（データ）
マネージャ B
（データ）
マネージャ C
（データ）
モート B1
（データ）
モート C1
（データ）
モート C2
（データ）
モート C3
ワイヤレス・データ・ネットワーク
カスタム・ソフトウェア /
ファームウェア
ワイヤレス・バックホール・ネットワーク
ワイヤレス・リンク
変更されないコード
（バックホール）
マネージャ A
（データ）
モート A1
インフラ
構内ネットワーク
図 2 - メッシュ内メッシュの配置
このアプリケーションノートでは、メッシュ内メッシュの構築に関する利点と制限事項について詳しく説明し、こうしたネット
ワークを構築する場合の重要な検討事項について説明します。
メッシュ内メッシュのセットアップを使用した場合の利点は、以下のとおりです。
• 必要なホスト・アプリケーションが 1 つで済みます。
• ホスト・アプリケーションがすべてのデータ・モートからデータを受信します。
• ホスト・アプリケーションがすべてのデータ・モートにデータを送信できます。
• ホスト・アプリケーションは、ワイヤレス・バックホール・ネットワークおよびワイヤレス・データ・ネットワークから健
全性レポートと統計情報を受信します。
SmartMesh IP アプリケーションノート
55/140
ただし、トレードオフがいくつかあります。
• データ・モートからの最大ペイロード長が 8 バイト減少します。
• データ・パケットの送信元と宛先の UDP ポートを同じにする必要があります。
• UDP ポート 0xf0bf をアプリケーションが使用することはできません。
• 上りのデータと下りのデータに対して 2 つの異なるセキュリティ・セッションが使用されます。1 つはバックホール・マ
ネージャとバックホール・モートの間であり、もう 1 つはデータ・マネージャとデータ・モートの間です。これは、バッ
クホール・マネージャとデータ・モートの間にエンド・ツー・エンドのセキュリティ・セッションが存在しないことを意
味します。
• ブリッジ・デバイス上でのバックホール・モートとデータ・マネージャ間の通信は、シリアル接続を介して平文で行わ
れます。ブリッジ・デバイスに物理的にアクセスすると、介入者攻撃が可能になります。
• データ・モートは、上りおよび下りのデータがワイヤレス・バックホール・ネットワークをトンネリングすることを認識
しません。
• ユニキャスト伝送だけがサポートされています。ブロードキャストおよび高信頼性ブロードキャストはサポートされて
いません。
• トンネリング・プロトコルの設計上の理由で、ホスト・アプリケーションは、ワイヤレス・データ・ネットワークから受
信したデータのネットワーク層タイムスタンプを失います。
11.1.1 トンネリング
図 2 はメッシュ内メッシュの例です。バックホール・マネージャに接続された 1 つのホスト・アプリケーションで構成されてい
ます。ホスト・アプリケーションは、
メッシュ内メッシュとの間で送受信されるデータの単一の出入口点です。ホスト・アプリケー
ションは上りのデータを受信し、データを下り方向へ送信する役目を果たします。ワイヤレス・バックホール・ネットワークは、
データ・マネージャのシリアル API に接続されているバックホール・モートからなる「ブリッジ」デバイスを内蔵しています。
下流のデータ・モートへのデータの送信は、2 段階で行われます。図 2 のホスト・アプリケーションは、データをデータ・モー
ト B1 に送信する場合、パケットをバックホール・モート A2 に送信します。これは、パケットの内部では、このデータが実際
にはデータ・モート B1 用であることを示しています。このためには、バックホール・モート A2 が、このデータが A2 用のデー
タではないことを理解して、パケットをデータ・モート B1 に中継することが必要です。この処理はネットワーク処理では一般
的であり、
「トンネリング」として知られています。
11.1.2 バックホール・ブリッジ
ブリッジ・デバイスは、データ・マネージャに接続されているバックホール・モートを内蔵しています。図 3 に示すように、2
つの構成が可能です。
SmartMesh IP アプリケーションノート
56/140
凡例
シリアル接続
（バックホール）
モート
（バックホール）
モート
変更されないファームウェア
カスタム・ファームウェア
マイクロ
コントローラ
（データ）
マネージャ
（データ）
マネージャ
（1）
（2）
図 3 - バックホール・ブリッジの構成
1. バックホール・モートはカスタムのファームウェアを実行するので、データ・マネージャのシリアル API を介してデー
タ・マネージャと通信できます。
2. バックホール・モートとデータ・マネージャの両方のシリアル API にマイクロコントローラを外付けします。両方とも
未変更のファームウェアを実行しています。
このアプリケーションノートでは、
（1）の場合について説明します。このアプリケーションノートでは詳しく説明しませんが、説
明および技術的解決策は一般化して（2）の場合にあてはめることができます。
11.1.3 バックホール・アプリケーションとホスト・アプリケーション
バックホール・モートはカスタム・ファームウェアを実行して、データ・マネージャとの間でのパケットのトンネリングをサポー
トします。これをバックホール・アプリケーションと呼びます。バックホール・アプリケーションの機能は以下のとおりです。
• データ・マネージャのシリアル API を介してデータ・マネージャとやりとりします。
• データ・マネージャからのすべての通知をサブスクライブします。また、
「非アクノリッジ」フィルタを使用してサブスク
ライブし、バックホール・マネージャのシリアル API でのタイムアウト問題を防止します。
• データ・マネージャのサブネット内にあるモートのリストを収集し、その情報をホスト・アプリケーションに送信します
（下記の検出メカニズムの説明を参照）。
• トンネリングで通過した下りデータをデータ・マネージャのシリアル API を介して該当の宛先データ・モートに中継し
ます。データ・マネージャのシリアル APIを介して受信した上りデータをトンネリング・プロトコルを使用してバックホー
ル・マネージャに中継します。
• データ・マネージャのシリアル API を介して受信した健全性レポートをトンネリング・プロトコルを使用してバックホー
ル・マネージャに中継します。
• データ・モートによって要求されたサービスの全体を代表するバックホール・マネージャへのサービスを接続先の
データ・マネージャに要求します。
SmartMesh IP アプリケーションノート
57/140
ホスト・アプリケーションの機能は以下のとおりです。
• 検出パケットを受信して、接続先のデータ・マネージャをデータ・モートごとに示すルーティング・テーブルを維持し
ます。
• トンネリング・プロトコルを使用して、適切なデータ・マネージャを介して下りデータのデータ・モートへのルートを
決めます。
• データ・モートからの上りデータのカプセル化を解除します。
11.2 トンネリング・プロトコル
このセクションで説明するトンネリング・プロトコルでは、図 4 に示すように、以下の流れが可能です。
• 下りデータ：ホスト・アプリケーションはワイヤレス・バックホール・ネットワークを介してデータ・モートにデータを
送信します。
• 上りデータ：データ・モートはワイヤレス・バックホール・ネットワークを介してホスト・アプリケーションにデータを
送信します。
• 要求：ホスト・アプリケーションはバックホール・モートに要求を送信します。さまざまなタイプの要求が存在します。
• 応答：バックホール・モートはホスト・アプリケーションに応答を送信します。さまざまなタイプの応答が存在します。
下り
下りデータ
要求
上りデータ
構内ネットワーク
送信元ポート : P
宛先ポート : P
宛先 MAC: B1
ペイロード
データ
応答
送信元ポート : P
宛先ポート : P
送信元 MAC: B1
データ
ペイロード
ホスト・
アプリケーション
送信元ポート : P
宛先ポート : 0xf0bf
宛先 MAC: A2
MAC B1
8 バイト
上り
データ
（バックホール）
マネージャ A
送信元ポート : 0xf0bf
宛先ポート : 0xf0bf
ディスパッチ
1 バイト
ペイロード
送信元ポート : 0xf0bf
宛先ポート : P
ブリッジ A
MAC B1
8 バイト
データ
送信元ポート : 0xf0bf
宛先ポート : 0xf0bf
ディスパッチ
1 バイト
ペイロード
（バックホール）
モート A2
（データ）
マネージャ B
送信元ポート : P
宛先ポート : P
宛先 MAC: B1
送信元ポート : P
宛先ポート : P
データ
データ
（データ）
モート B1
図 4 - トンネリング・プロトコルによって処理されるさまざまな流れ
SmartMesh IP アプリケーションノート
58/140
トンネリング・プロトコルは以下の 2 つの仕組みを使用します。
• UDP ポート（0xf0bf）はトンネリング動作に備えて使用せずに残します。送信元または宛先の UDP ポートが
0xf0bf に設定され、ワイヤレス・バックホール・ネットワークを介して送信されたパケットは、そのパケットがトン
ネリング・プロトコルの一部であることを示しています。
• データ伝送では、データはデータ・モートの 8 バイトの MAC アドレスと一緒に先頭に追加されます。
• 要求 / 応答のやりとりでは、ディスパッチ・バイトはパケット・タイプを示します。
11.2.1 下りデータ
下りデータは、ホスト・アプリケーションによって特定のデータ・モートに送信されます。このデータ・フローを図 4 を使用し
て示します。ホスト・アプリケーションは UDP ポート P のデータ・モート B1 に何らかのデータを送信するよう要求されてい
ると仮定します。
• ホスト・アプリケーションでの処理は以下のとおりです。
• 以下の状態の少なくとも 1 つが当てはまる場合、伝送は中止され、該当のエラー・メッセージが返されます。
• 送信元と宛先の UDP ポートが異なる。
• 宛先の MAC アドレスがルーティング・テーブルに存在しない。
• データの長さに 8 を加えた値が最大データ長より大きい。
• ホスト・アプリケーションは、宛先データ・モートが属しているバックホール・マネージャの MAC アドレスを検
索します（A2 の場合）。
• ホスト・アプリケーションは、以下のパラメータを使用してバックホール・マネージャに sendData コマンドを
発行します。
• macAddress を A2 に設定する。
• priority を L に設定する。
• srcPort を P に設定する。
• dstPort を 0xf0bf に設定する。
• options を 0 に設定する。
• data を宛先データ・モートの MAC アドレス（8 バイト）とデータを連結したものに設定する。
• バックホール・モートでの処理は以下のとおりです。
• バックホール・モートはあらかじめ開いてあり、ソケットをポート 0xf0bf にバインドしています。このポートで
受信したパケットは、どれもトンネリング・プロトコルの一部です。
• 長さが 8 以下のパケットは暗黙的に破棄されます。
• 受信したペイロードは 2 つの部分に分割されます。
• 最初の 8 バイトは、宛先データ・モートの MAC アドレスです。
• 残りは不透明なバイト列とみなされ、以下に示す「データ」と呼ばれます。
• バックホール・モートは、以下のパラメータを使用してデータ・マネージャに sendData コマンドを発行します。
• macAddress を宛先データ・モートの MAC アドレス（ここでは B1）に設定する。
• priority を L に設定する。
• srcPort を受信パケットの送信元ポート（ここでは P）に設定する。
• dstPort を受信パケットの送信元ポート（ここでは P）に設定する。
• options を 0 に設定する。
• data を受信パケットの「データ」部分に設定する。
• データ・モートでの処理は以下のとおりです。
• データ・モートはあらかじめ開いてあり、ソケットをポート P にバインドしています。
• データ・モートはデータ・マネージャからパケットを受信し、そのパケットがワイヤレス・バックホール・ネットワー
クをトンネリングしたという事実を認識していません。
SmartMesh IP アプリケーションノート
59/140
11.2.2 上りデータ
上りデータは、データ・モートによってホスト・アプリケーションに送信されます。このデータ・フローを図 4 を使用して示し
ます。データ・モート B1 はホスト・アプリケーション上で UDP ポート P にデータを送信すると仮定します。
• データ・モートでの処理は以下のとおりです。
• データ・モートはあらかじめ開いてあり、ソケットをポート P にバインドしています。
• データ・モートは、以下のパラメータを使用して sendTo コマンドを発行します。
• destIP を ff02::2 に設定する。
• destPort を P に設定する。
• serviceType を帯域幅に設定する。
• priority を L に設定する。
• payload には送信するデータが含まれている。
• データ・モートの観点からは、これはデータ・マネージャへの送信データであり、ワイヤレス・バックホール・ネッ
トワークを通り抜けてホスト・アプリケーションに届くことは認識していません。
• バックホール・モートでの処理は以下のとおりです。
• バックホール・モートは、データ・マネージャからのすべての通知を受信するようあらかじめ登録しています。
• バックホール・モートはあらかじめ開いてあり、ソケットをポート 0xf0bf にバインドしています。
• データ・モートによって送信されたデータ・パケットはシリアル API 上にデータ通知として現れます。
• 以下の状態の少なくとも 1 つが当てはまる場合、データ・モートは受信パケットを暗黙的に破棄します。
• 送信元と宛先の UDP ポートが異なる。
• データの長さに 8 を加えた値が最大データ長より大きい。
• バックホール・モートは、以下のパラメータを使用して sendTo コマンドを発行します。
• destIP を ff02::2 に設定する。
• destPort を受信データの送信元ポート（ここでは P）に設定する。
• serviceType を帯域幅に設定する。
• priority を L に設定する。
• payload には、送信元データ・モートの MAC アドレス（8 バイト）とデータを連結したものが入っている。
• このパケットはあらかじめ開かれているソケットを介して送信されるので、送信元 UDP ポートを 0xf0bf とし
て送信されます。
• ホスト・アプリケーションでの処理は以下のとおりです。
• ホスト・アプリケーションは送信元 UDP ポート 0xf0bf からデータを受信しますが、これはデータがトンネリン
グ・プロトコルの一部であることを示しています。
• 受信データが宛先 UDP ポート 0xf0bf に送信された場合、
これは転送通知か、
またはモート検出パケットです。
パケット処理の説明については、下記を参照してください。
• ホスト・アプリケーションは、ペイロード長が 8 以下の場合、受信パケットを暗黙的に破棄します。
• ホスト・アプリケーションは、受信したペイロードを以下の 2 つの部分に分割します。
• 最初の 8 バイトは、送信元データ・モートの MAC アドレス（ここでは B1）です。
• 残りは、送信元データ・モートが送信した「データ」です。
• ホスト・アプリケーションは受信データを処理します。
11.2.3 要求
ホスト・アプリケーションは、UDP の送信元と宛先の両方のポートを 0xf0bf に設定したパケットを送信することによって、
特定のバックホール・モートに要求を出すことができます。
ディスパッチ・バイトと呼ばれる、要求の最初のバイトは、要求のタイプを識別するバイトです。
SmartMesh IP アプリケーションノート
60/140
要求ディスパッチ・バイト
意味
0x00
シリアル API コマンド
0x01
リモート・プロシージャ・コール
シリアル API コマンド
この要求タイプの使用は、アプリケーションノートのこのバージョンでは定義されていません。ここに示したのは、
将来拡張される可能性があるためです。
リモート・プロシージャ・コール
この要求タイプでは、ホスト・アプリケーションによってバックホール・モートにプロシ−ジャを開始させることができます。
このプロシージャが完了すると、リモート・プロシージャ応答が返される可能性があります。サポートされているリモート・プ
ロシージャは、下記の「リモート・プロシージャのインタフェース」セクションに示します。
11.2.4 応答
バックホール・モートは、 UDP の送信元と宛先の両方のポートを 0xf0bf に設定したパケットを送信することによって、特
定のバックホール・マネージャに応答を返すことができます。
ディスパッチ・バイトと呼ばれる、応答の最初のバイトは、応答のタイプを識別するバイトです。
応答ディスパッチ・バイト
意味
0x00
シリアル API 応答
0x01
リモート・プロシージャ応答
0x02
シリアル API 通知
シリアル API 応答
この応答タイプの使用は、アプリケーションノートのこのバージョンでは定義されていません。ここに示したのは、
将来拡張される可能性があるためです。
リモート・プロシージャ応答
この要求タイプでは、ホスト・アプリケーションによってバックホール・モートにプロシ−ジャを開始させることができます。
このプロシージャが完了すると、リモート・プロシージャ応答が返される可能性があります。サポートされているリモート・プ
ロシージャは、下記の「リモート・プロシージャのインタフェース」セクションに示します。
SmartMesh IP アプリケーションノート
61/140
シリアル API 通知
バックホール・モートは、データ・マネージャのシリアル API を介してすべての通知に対して登録します。すべてのデータ通
知は、前述した「上りデータ」の手順で処理されます。その他のすべての通知は、このセクションで説明する手順に従って、
ホスト・アプリケーションに転送されます。
• バックホール・モートでの処理は以下のとおりです。
• バックホール・モートは、データ・マネージャからのすべての通知にあらかじめ登録しています。
• バックホール・モートはあらかじめ開いてあり、ソケットをポート 0xf0bf にバインドしています。
• 通知タイプのデータは、前述した「上りデータ」の手順で処理されます。
• 通知の長さに 1 を加えた値が最大ペイロード長を超えると、通知は暗黙的に破棄されます。
• バックホール・モートは、以下のパラメータを使用して sendTo コマンドを発行します。
• destIP を ff02::2 に設定する。
• destPort を 0xf0bf に設定する。
• serviceType を帯域幅に設定する。
• priority を H に設定する。
• payload には、
（シリアル API 通知を示す）バイト 0x02 に続いて、シリアル・ポートを介して受信した通
知の正確なバイト数が入っている。
• このパケットはあらかじめ開かれているソケットを介して送信されるので、送信元 UDP ポートを 0xf0bf とし
て送信されます。
• ホスト・アプリケーションでの処理は以下のとおりです。
• ホスト・アプリケーションは送信元 UDP ポート 0xf0bf からデータを受信しますが、これはデータがトンネリン
グ・プロトコルの一部であることを示しています。
• 受信データが 0xf0bf とは異なる宛先 UDP ポートに送信された場合、これは上りデータ・パケットであり、前
述した「上りデータ」の手順で処理されます。
• ペイロードの最初のバイトが 0x02 である場合、これはシリアル API 通知です。
• ホスト・アプリケーションは、通知をマネージャのシリアル・ポートから直接受信したかのように解析します。
11.3 リモート・プロシージャのインタフェース
トンネリング・プロトコルでは、ホスト・アプリケーションがバックホール・モートでプロシージャを開始して、その結果をリモー
ト・プロシージャ・コール・パケットとリモート・プロシージャ応答パケットの交換によって取得することができます。リモート・
プロシージャ・コールの後に続くリモート・プロシージャ応答パケットの数は、0、1、または複数です。リモート・プロシージャ・
コール・パケットの書式設定は以下のとおりです。
要求ディスパッチ・バイト
プロシージャ ID
プロシージャ固有のパラメータ
0x01
下記参照
プロシージャ固有
1 バイト
1 バイト
可変
SmartMesh IP アプリケーションノート
62/140
リモート・プロシージャ応答パケットの書式設定は以下のとおりです。
応答ディスパッチ・バイト
プロシージャ ID
プロシージャ固有の戻り値
0x01
下記参照
プロシージャ固有
1 バイト
1 バイト
可変
有効なプロシージャ ID は以下のとおりです。
プロシージャ ID の値
対応するプロシージャ
0x00
getOperationalMotes
このセクションでは、サポートされているさまざまなプロシージャを示します。
11.3.1 getOperationalMotes プロシージャ
このプロシージャでは、特定のデータ・マネージャが管理している稼働モートの一覧をホスト・アプリケーションが取得でき
ます。
リモート・プロシージャ・コール・パケットの書式
リモート・プロシージャ・コール・パケットでは、プロシージャ固有のパラメータは通過しません。
プロシージャの説明
このプロシージャが起動すると、バックホール・モートはデータ・マネージャのシリアル API を介して一連の getMoteConfig
コマンドを発行し、現在稼働中のモートの MAC アドレスの一覧を取得します。
リモート・プロシージャ応答パケットの書式
1 つ以上のリモート・プロシージャ応答パケットがバックホール・モートによって使用され、このデータ・マネージャに参加し
た稼働データ・モートの数と MAC アドレスが返されます。
各リモート・プロシージャ応答パケットの書式は以下のとおりです。
モートの総数
この一覧での最初のモートの索引（0==最初のモート） MAC アドレスの差分符号化一覧
1 バイト
1 バイト
可変
MAC アドレスの一覧は、リモート・プロシージャ応答のペイロード・サイズに差分符号化されます。一覧の各項目は、1 バイ
ト長のフィールドと、後続の MAC アドレス（場合によっては一部切り捨て）で構成されます。2 つの MAC アドレスが互いに
続く場合、左端の共通バイトは 2 番目の MAC アドレス符号化から削除されます。
SmartMesh IP アプリケーションノート
63/140
つまり、以下の MAC アドレスの一覧を符号化した場合、
• 00-17-0d-00-00-11-22-33
• 00-17-0d-00-00-11-33-44
• 00-17-0d-00-00-11-33-55
• 00-17-0d-00-00-22-22-33
これは次のように符号化されます（下線のバイトは長さバイトを強調しています）。
08 00 17 0d 00 00 11 22 33 02 33 44 01 55 03 22 22 33この例では、データの符号化によってペイロー
ドが 32 バイトから 18 バイトに縮小しています。モートの一覧が長すぎて 1 パケットに収まらない場合、一覧は複数のパケッ
トに分割され、各パケットの先頭の索引バイトが一覧の最初のモートの索引を表します。
11.4 帯域幅に関する検討事項
ネットワークは、各レベルで全スループットを超えないように構成する必要があります。すべてのバックホール・モートの合
計がバックホール・マネージャのスループットを超えないようにします。各データ・マネージャのスループットは、そのバック
ホール・モートのスループットと一致するようにします。
一例として、均一なサービス・レベルを使用してみましょう。ただし、帯域幅の分布を不均質にすることは可能です。バックホー
ル・マネージャは 32 個のバックホール・モートに接続されており、各データ・マネージャは 32 個のモートに接続されている
と仮定します。デフォルトでは、バックホール・マネージャの基本帯域幅は 0.11 パケット / 秒です。つまり、バックホール・モー
トは 9 秒ごとに 1 パケットを送信すると予想されます。
バックホール・マネージャの基本帯域幅を 1 パケット / 秒に変更します。こうするには、配置の前に set config basebw とい
う CLI コマンドを使用します。各データ・マネージャは、その 32 個のモートから 1 パケット / 秒の全トラフィックをサポートで
きます。これは、各モートからで換算すると約 1 パケット/30 秒になります。基本帯域幅は既に 9 秒に設定されているので、デー
タ・マネージャでその値を変更する必要はありません。この構成では、全部で 1024 個のモートがある 32 のサブネットから
30 秒に 1 回の均質なレポートをサポートします。データ・モートの API を駆動するアプリケーションは、サービスをこの速度
で送信できるよう要求する必要はありませんが、それでもなお推奨される実践的手法です。サービスを使用する場合は、30
秒に 1 回より高速のサービスをモートが要求しないようにします。
RAM を外付けした SmartMesh IP マネージャを使用することにより、システムを 10000 モート（それぞれが 100 個のモート
まで拡張することも可能です。この場合には、バッ
をサポートするデータ・マネージャを備えた 100 個のバックホール・モート）
クホール・マネージャの基本帯域幅を 3 秒に 1 回に縮小する必要があり、データ・マネージャの基本帯域幅を 100 秒に 1 回
に縮小する必要があります。モートの発行頻度は 100 秒に 1 回より多くならないようにしてください。
バックホール・モートとデータ・モートの数のその他の組み合わせは可能ですが、基本帯域幅を各レベルで適宜調整する必
要があります。
11.5 その他
• 望ましい実装形態としては、各ワイヤレス・データ・ネットワークを異なるネットワーク ID で構成し、さらにワイヤレス・
ワイヤレス・データ・ネットワー
バックホール・ネットワークには別のネットワークID を付けるようにします。こうすると、
クの間にデータ・モートを均等に分配することができます。
• あるいは、ACL を使用すれば、すべてのワイヤレス・データ・ネットワークにわたって単一のネットワーク ID と参加鍵
を共有することが可能です。
SmartMesh IP アプリケーションノート
64/140
12 アプリケーションノート：深い IP ネットワークの構築
12.1 はじめに
SmartMesh IP ファミリは、長い直線距離に及ぶネットワークを構築するのに適しています。これには、センサが出口点から
同じ方向に離れて配置される傾向がある、坑道内での環境のモニタや伝送線モニタなどのアプリケーションが含まれます。
1 次元の配置を考慮すると、マネージャから離れた場所にあるワイヤレス・センサ・ノード（「モート」）からのパケットは、宛
先に到達するのにより多くのホップが必要になります。これらのモートは、マルチホップ・ネットワーク内で「深い」状態にあ
ると呼びます。密度の高いメッシュ・ネットワークと比較して、こうした深いマルチホップ・ネットワークに特有の性能特性が
いくつか存在します。
1. ネットワークに完全に参加するのに時間がかかります。
2. マネージャは全トラフィックの下限値をサポートできます。10.5 パケット / 秒という転送レートの最大値を考慮する
必要があります。
3. 配置の場所と接続性にはより注意が必要です。
4. パケットの待ち時間はネットワークの深さに応じて長くなります。
12.2 配置のガイドライン
SmartMesh のすべての配置と同様に、モートは他の 3 つの潜在的な親の範囲内にすべて配置して、ネットワークの信頼性
を確保する必要があります。線形配置の場合、これはすべてのセンサ・モートについて、範囲内でマネージャに近い方に 3
つのモートが存在する必要があるという意味です。さらに、この性質をマネージャの近くで保存するため、マネージャの近く
にいくつかの中継器モート（センサを内蔵するモートまたは内蔵しないモート）を配置することを推奨します。目的の環境で
の無線範囲を R とすると、配置は図 1 に従って実行する必要があります。
図 1 - 各センサ・モート（濃青色の円）には、マネージャ（三角）の近くに 3 つの上り隣接モートがあります。中継器（淡青色の円）
は、トラフィック処理と空間的冗長性を実現します。
実際の配置での検出点がこれより少ない場合は、中継器を追加して、デバイスごとに 3 つの潜在的な親という要求を満たす
必要があります。有効範囲内にすることができる総距離は、範囲に影響する配置環境に大きく影響されます。図 1 に示すよう
に、たとえば R=100m である場合、 100 モートのネットワークは外側に 3km を超える距離までモニタできます。デバイスを
地表から 20 ∼ 30 メートルの高さで見通し線内に配置すると、この範囲を 5 倍（つまり15km 超）に延ばすことが可能であり、
デバイスを地表から 1 メートルの坑道に配置すると、範囲は半分（1.5km）に縮まる可能性があります。
SmartMesh IP アプリケーションノート
65/140
12.3 範囲の割り出し
坑道と伝送線という 2 つの配置例は、これらの非常に異なる環境での無線伝播特性のため、対照的なデバイス範囲に位置
すると予想されます。これらの設定のいずれの場合も、ワイヤレス・センサの実際の完成品または試作品を使用し、使用す
る予定のアンテナを付けた完全一体型の 1 対のモートによってデバイス間の範囲を直接測定する以外に方法はありません。
この測定範囲は、中継器の数とネットワークの最大距離の両方を規定します。この理由から、OEM 供給先は開発サイクルの
できるだけ早い段階に範囲測定を実施することを推奨します。
範囲の推定の詳細については、アプリケーションノート「配置の計画」を参照してください。
12.4 モートとマネージャのバージョンおよび設定
深いネットワークを構築するには、SmartMesh IP Managerバージョン1.2.1以降およびSmartMesh IP Moteバージョン1.3
以降が必要です。アップグレード処理が必要な場合は、配置の前に実行しておく必要があります。
バージョン要件の他に、マネージャは従来の配置と異なる構成変更をいくつか行う必要があります。これらの設定もネット
ワークの構築前に行って、持続させる必要があります。マネージャの CLI インタフェースで、以下のコマンドを入力します。
• su becareful
• set config numparents 3
• seti ini rlblbcto_f 240
• seti ini rlblskto_f 240
• seti ini rlblmaxto_f 240
• seti ini rlblskto_s 240
• seti ini minlinks 8（「リンクの計算」セクションでの L の計算を参照）
• seti ini iscascading 0
• seti ini nummlinks 0
モートでは構成変更の必要はありません。
12.5 リンクの計算
割り当てられるリンクの数は（上記で詳述した設定の場合と同様に）、最小でも 8 に設定する必要があります。ネットワークで
の報告率を高くしたり待ち時間を短くしたりするには、リンク数を増やすことが必要な場合があります。リンク数は次式を使
用して計算できます。
L = [1.8M/T]
ここで、リンクの数は L、ネットワーク内でのモートの数（中継器を含む）は M、レポート間隔は T です。
角かっこは、ここでは端数の切り上げが必要であることを示しています。全ネットワーク放出を 10.5 パケット / 秒に制限して、
100モートで最大限のスループットが得られるようにすることを推奨します。
これは1モート当たり10秒につき1パケットであり、
健全性レポートのパケットを伝送するには若干の追加となります。この場合のリンク要件を計算すると、L=18 となります。
SmartMesh IP アプリケーションノート
66/140
メモリに制限があるので、積 LM の最大値は 1800 に制限します。たとえば、100 モートの深いネットワークの場合は、L=18
という値が許容最大値です。50 モートの小規模ネットワークでは、パケットの待ち時間を最小限にする場合、L=36 と設定で
きます。すべての SmartMesh ネットワークと同様に、リンク数の追加と平均エネルギー消費量とのトレードオフに留意する
ことが必要です。
12.6 待ち時間の推定
ネットワーク内の各モートの待ち時間分布は、正確に予測するのが困難です。デフォルトの設定で 100 個のモートをテストし
て得られた図 2 に示すモート別待ち時間の例について考えます。待ち時間は一般的にモートの深さに応じて長くなりますが、
待ち時間の測定値には大きなばらつきがあり、特に最大の測定値で顕著です。グラフから得られた一例として、最も深いモー
トの場合、待ち時間の中央値は 10.2 秒であり、待ち時間の 99 パーセンタイル値は 20.6 秒です。
図 2 - モート ID の関数としての待ち時間。デフォルトの設定で 1 時間にわたってデータを収集した場合。最大値を赤の点、
中央値を青の点、最小値を緑の点で示します。このネットワークでは、平均経路安定性の測定値は 85% でした。
このデータを使用して、ネットワーク内で最も深いモートの待ち時間を推定できます。この状況では、平均経路安定性 S が重
要なパラメータです。S が示していることは、さまざまな RF 関連の要因が原因で、すべての送信が最初の試行で宛先に到
達するとは限らないという考え方です。たとえば、 100% の経路安定性とは、すべてのパケットが最初の試行で宛先に到達
するという意味であり、80% の経路安定性とは、パケットの 8/10 は最初の試行で宛先に到達し、2/10 は自動的に再送信さ
れるという意味です。
SmartMesh IP アプリケーションノート
67/140
<median(latency)> = 0.75M/LS
図 2 の赤い点は、待ち時間の予想できる 99 パーセンタイル概算値です。したがって、待ち時間の 99 パーセンタイル値は、
中央値の 2 倍から 3 倍の間になると予想できます。経路安定性が低い場合は、パケットがモートのキューで作成されるので、
待ち時間分布の裾がさらに長くなる可能性があります。満杯になったキューの影響の特定および軽減について詳しくは、ア
プリケーションノート：
「混雑したネットワークのデバッグ」を参照してください。
12.7 無線通信プログラミング
SmartMesh IP モートは、OTAP Communicator と呼ばれる外部アプリケーションを使用して、無線通信プログラミン
グ（Over-the-Air Programming：OTAP）をサポートしています。深いネットワークのモートをアップグレードする場合、
OTAP Communicator のデフォルトのモードではネットワーク内での輻輳がひどくなるので、低速モードで動作させる必要
があります。100 モートの深いネットワークでは、標準的な OTAP アップグレードに約 12 時間かかります。
SmartMesh IP アプリケーションノート
68/140
13 アプリケーションノート：重複ネットワーク
13.1 はじめに
配置では、1 つの SmartMesh IP ネットワークに収容できるより数が多い数百または数千のモートが小さな領域内で必要に
なることがあります。SmartMesh プロトコルは信頼性の要件として時間同期を重視するので、重複する空間に置かれている
複数のネットワークでこれらのモートを配置するのは危険を伴うと考えられます。このアプリケーションノートで示すように、
基本経路安定性は十分高いと仮定すると、重複ネットワークを配置する大きな危険はありません。最大の影響、つまりすべ
ての重複ネットワークにわたる有効な経路安定性の低下を数値化します。
実際の例として、Dust Networks では、10 ∼ 30 のネットワーク内で 1000 モートが同時に稼働し、すべてが完全に非同期
状態で、すべてが同じ無線空間内にある環境ですべてのテストを実施します。
13.2 方法
SmartMesh IP ネットワークにそれぞれ 100 モートの全容量が与えられる配置について検討します。こうした 10 のネットワー
クがすべて同じ無線空間内にあり、そのうち 1 つのネットワークから 1 つのモートを選ぶとします。帯域幅割り当てアルゴリ
ズムを使用しているので、このモートからの伝送が、同じネットワーク内にある他の 99 モートからの伝送と衝突することはあ
りません。ただし、重複するネットワークの 1 つからの伝送とは衝突する可能性があります。復号が関係しているので、どち
らかより早い段階で開始した伝送が成功する可能性が高く、どちらか途中で開始した伝送は失敗する可能性があります。
各ネットワークでのモートのレポート頻度に基づいて、そのネットワークの単位時間当たりの伝送の総数を計算できます。ま
た、この伝送の総数に基づいて、選び出した 1 つのモートと衝突する確率を計算できます。衝突によってモートがその伝送
に失敗した場合、モートは次の割り当てリンクで伝送を自動的に再試行します。再試行のたびにモートの経路安定性測定値
は低下しますが、データは次の割り当てリンクでとにかく伝送されるので、データの信頼性は維持されます。
100 モートの単一ネットワークを配置して経路安定性を測定した場合、結果は 80% になることがあります。これがいわゆる
基本経路安定性です。重複ネットワークの数が 10 になると、安定性は低下していきます。重複ネットワーク内のトラフィック
が増えると、安定性はさらに低下します。この最終値を実効経路安定性と呼びます。次のセクションでは、さまざまな数の重
複ネットワーク、さまざまな報告率、さまざまな基本安定性を想定して、実効安定性を計算します。
一般に、実効経路安定性が 50% 未満のとき、ネットワークを稼働させることは推奨しません。
13.3 結果
この計算では、配置のワーストケースを想定しています。第 1 に、すべてのモートおよびマネージャは同じ無線空間にあるも
のとします。第 2 に、すべての伝送はペイロードができる限り長く続く最大ペイロードであるとします。第 3 に、各ネットワー
クには最大の 100 モートがあります。また、重複ネットワーク内にあるすべてのモートが同じ速度でデータを報告していると
します。低速帯では、モートは 60 秒間隔でデータを報告します。高速帯（SmartMesh IP ネットワークのパケット / 秒制限値
近く）では、モートは 3 秒間隔でデータを報告します。
80% の基本安定性から始めて、安定性が損なわれ始めるまで同じ空間に多くのネットワークを許容できることが分ります。
SmartMesh IP アプリケーションノート
69/140
このグラフから、80% の基本安定性を確保している場合は、15 の重複ネットワークをその全容量で稼働（つまり、各モート
が 3 秒おきに 1 パケットを報告）しても、機能を損なうことはありません。実効安定性の低下に見合った量の消費電力と待ち
時間の増加が生じますが、信頼性は確保されます。
基本安定性が 70% の場合に同じ分析を繰り返すと、12 以上の重複ネットワークで何らかの報告限界が示されます。
これらの限界に達するには、種々の曲線が 50% の実効安定性の軸と交差する場所を調べます。各モートが 3 秒ごとに 1 パケッ
トを報告する場合は、9 つのネットワークを同じ無線空間で稼働しても安全です。
SmartMesh IP アプリケーションノート
70/140
次に、同じ軸にプロットされた 60% の基本安定性を考察すると、安全性に対するマージンが大幅に少なくなっています。
この場合、3 つのネットワーク以外のすべてのネットワークの実効安定性が 50% を切る可能性があります。
こうした結果を得ることができる方法がもう 1 つあります。報告回数が最小限で 60 秒間隔のモートがある場合、同じ無線空
間に安全に配置できるモートの数はいくつでしょうか。
SmartMesh IP アプリケーションノート
71/140
基本安定性が 60%、70%、および 80% の曲線群を上の図に示します。高い基本安定性から始めた場合は、1 つの無線空
間で数千のモートをサポートすることが可能です。こうした高モート密度では、存在するネットワーク数は実際のところ問題
ではありません。たとえば、5,000 モートを配置できる場合は、50 モートのネットワーク数が 100 であっても、100 モートのネッ
トワーク数が 50 であっても変わりません。存在するトラフィックの量、したがって干渉の量は同じです。
13.4 結論
前のセクションのグラフから、いくつかの結論を出すことができます。
• 最大 1,800 のモートが 18 のネットワークにわたって広がっている、平均発行間隔が 15 秒につき 1 パケットの実装形
態は、どれも規格の範囲内で機能します。実効経路安定性は 5% ∼ 10% 低下すると予想されます。
• 100 モートの単一ネットワークを試験的に配置して基本安定性を測定し、ネットワークの信頼性を維持する上で安全
な重複の程度およびトラフィック・レベルを調べることを推奨します。
干渉の影響をさらに軽減するには、以下の手順を実行できます。
• ペイロードが満杯にならない状態のパケットを送信している場合は、センサ・プロセッサで満杯のペイロードが待つ
ようになるまでデータを蓄積してからデータをモートに送信します。こうすると待ち時間は長くなりますが、衝突を発
生させる可能性がある無線オン時間は全体的に短くなります。待ち時間を許容できる場合、これはモートの消費電力
をとにかく抑えるのに優れたポリシーです。
• モート当たりの親の数を 2 から 3 に増やします。こうするとモートの経路多様性が広がり、いくつかの経路に障害が発
生した場合、モートがリセットされる可能性が低くなります。ただし、親モートで消費電力の増加が必要になります。
• ネットワークが低トラフィックのネットワークである場合は、モート当たりの最小リンク数を増やします。こうすると、
モートの伝送スケジュールがランダム化され、永続的な衝突が防止される一方、上記と同様に親の増加によって消費
電力が増えます。
• 異なるネットワークのアクセス・ポイント・デバイスをまとめて配置する場合は、常時 1 メートル以上離す必要があり
ます。
伝送電力を低くして重複ネットワークの性能を向上させることは推奨しません。こうすると、必要な信号を含めてすべての信
号が同じ大きさだけ小さくなるからです。さらに、環境に周囲 RF ノイズがあると、基本安定性も低下することになります。
SmartMesh IP アプリケーションノート
72/140
14 アプリケーションノート：配置の計画
14.1 範囲の推定
ある距離でのデバイス相互の通信を良好にするには、ハードウェアの集積化をどう選択するかが影響し、中でもアンテナ
の選択が最も明らかに影響します。集積化後、デバイスの配置によって有効範囲が数桁変わることがあります。有効範囲
の一方の端では、高所の柱や塔に設置され、ネットワーク内の他のモートへの見通し線に障害物がないデバイスの範囲は
1000m 以上です。もう一方の端では、地表や大きな金属物に隣接して置かれたデバイスの有効範囲は 10m 以下になること
があります。したがって、
「貴社製品の無線の範囲はどのくらいか」と顧客から尋ねられた場合、ある意味その質問には意味
がないか、答えることができません。伝送電力や受信感度、得られるリンク・バジェットについてはデータシートを参照でき
ますが、顧客は顧客の製品の開発時と、顧客が予想した配置に似た実際の環境での評価時に行う選択によって範囲を決め
ます。
開発の初期にはデバイスが 50m の間隔で動作するという計画を顧客が立てることを推奨します。最初の数回の「標準的な」
配置を分析すると、範囲の標準的な数値の増減を導き出すことができます。配置計画が要求することは、単純に既存の 3 つ
以上のデバイスのこの範囲内に各モートを配置することです。信頼できるメッシュを形成するため、各デバイスには複数の
隣接デバイスと、したがって非常に多くの接続機会が必要です。範囲内にある唯一の他デバイスと最大限の間隔で一列に
モートを配置すると、モートがリセットされやすくデータが消失しやすい脆弱なネットワークになります。
14.2 配置の綿密な計画策定
環境での範囲が決まったら、縮尺図を使用して、ネットワークで求められるすべての検出点にモートを配置することができま
す。可能な場合は、モートの分布の中央付近に AP を配置して、待ち時間およびモートの消費電力を低減してください。AP
の位置に印をつけます。上記で推定した範囲を 50m と想定して、マネージャを中心に半径 50m の円を描きます。この円内
にあるすべてのモートが AP と直接通信できるとは限りませんが、円の外側にある一部のモートは直接通信できるので、平
均すると釣り合います。この円の内側にあるモートの数は、この配置での 1 ホップ・モートの数に近い値です。
次に、AP を中心に半径 100m の円を描きます。50m と 100m の間のリングの中にあるモートの数は、2 ホップ・モートの数
に近い値です。半径を延ばしてこの手順を繰り返し、すべてのモートが囲まれるまで続けて、各ホップにモートがいくつある
かをメモします。これらのホップ・カウントはすぐに使います。
確認することがさらに 2 つあります。
• AP を含む各モートは、他の 3 つのデバイスの推定範囲内に存在する必要があります。
• ネットワークは 8 ホップ以内である必要があります。これより深いネットワークは確かに可能でとにかく機能はします
が、モデル化するのが困難です。
SmartMesh IP アプリケーションノート
73/140
14.3 電力と待ち時間の推定
Dust は、両製品ファミリのネットワーク性能を推定する SmartMesh Power and Performance Estimator を提供していま
す。このツールを使用することにより、所定のトポロジ、パケット・レート、ホップ当たりの待ち時間、および目的の存続期間
に対応するバッテリ・サイズを推定できます。
入力項目は以下のとおりです。
• 各ホップでのモートの数
• 報告間隔およびパケット・サイズ
• ネットワーク構成
• 経路安定性
これらを入力することにより、Estimator（推定プログラム）は、まずネットワークが形成されるかどうかを評価し、形成される
場合は以下の項目を示します。
• ホップごとのモートの平均電流
• ホップごとの平均待ち時間
• ネットワークの参加時間
• 参加しているモートの電流
顧客に電力量計算の検討を案内するという前提で、構成例の使用を推奨します。
実際の配置で消費電力と待ち時間に影響する要因は多数存在し、配置した時点でのネットワークの経路安定性（経
時変化あり）や接続性（深さ方向のホップ数）などがあります。Estimator は、所定のホップでのモートの妥当な平
均電力を示します（平均の 3 倍のホップがあるモートが存在する場合があります）。これらの推定値は予想設定値に
対応するものです。実際のネットワーク内性能は異なります。
SmartMesh IP アプリケーションノート
74/140
15 アプリケーションノート：ネットワーク健全性の予測
配置済みで稼働中のネットワークの健全性を評価することは、長期的な性能目標が達成可能であることを保証するために重
要です。ネットワーク健全性の検証はシンプルであり、すぐに入手できる情報の解釈に基づいています。ネットワークがこの
ネットワーク健全性検証テストを不合格になった場合、通常は重要な位置にモートを追加することで問題が改善されます。
15.1 目的
ネットワークが配置されて稼働状態になったら、重要な一歩はネットワークが健全であることの検証であり、さらに重要なこ
とは将来も健全であり続けることの検証です。ネットワーク自体は必要なすべての診断データを収集します。このデータはマ
ネージャのソフトウェア・インタフェースで供給されます。製品の開発の早い段階で、ソフトウェアをマネージャに統合する
開発者は、診断が重要であることを認識していることが重要です。ネットワークの健全性検証を自動化するツールを作成する
ことは、特に無線に関して懐疑的なエンドユーザーの脳裏に信頼感を植え付けるきわめて良い投資となります。
以下に説明する作業によって、ユーザーはネットワークから立ち去っても大丈夫（「ゴーサイン」）かどうかが分ります。またこ
れは、適切に設置されたネットワークに問題が生じるというまれな事例で問題の原因を特定するのに役立ちます。
15.2 概要
ネットワークの検証では、2 つの複合的な質問に答えることが必要です。
1. ネットワークは正常に見えますか？
2. ネットワークの構成要素は順調に機能していますか？
これら両方の質問に対して求められる答えは「はい」です。これら両方の質問に対する答えが「はい」の場合、テストは合格し
ており、該当のネットワークは当分の間順調に稼働すると予想されます。
15.3 ネットワークの構成要素は順調に機能しているか？
ネットワーク評価テストのこの部分では、ネットワークに関する非常に単純な 3 つの観測上の質問に答えることが必要です。
質問は以下のとおりです。
データの信頼性は高いですか？優れた配置では、ネットワークのデータ配信率が 100% 近くになります。Dust のネットワー
クはデータを消失する仕組みがほとんどない方法で構築されているので、 99.99% を超えるデータ信頼性が期待されます。
これが事実であることを確認してください。
参加動作は正しいですか？この質問の前半部分は、
「デバイスはすべて参加しましたか？」です。配置されたデバイスの数を
確実に知ることができるのは設置作業者だけです。設置作業者は 100 デバイスを外に置いた場合、100 デバイスが参加した
ことを確認する必要があります。この質問の後半部分は、すべてのデバイスが厳密に 1 回参加したことを確かめるものです。
あるデバイスが 2 回以上参加した場合、そのデバイスのネットワーク内での活動時間は、デバイスが絶え間なく脱落して再
参加しているわけではないと確信するのに十分なほど長時間ですか？ネットワークの構築中に脱落して 1 回再参加したデバ
イスは、構築完了後、長い時間が経ってからリセットされたデバイスほど悪い兆候はありません。
SmartMesh IP アプリケーションノート
75/140
ネットワークはメッシュ型に見えますか？ネットワークを視覚化する GUI があれば、この質問はひと目見ただけで答えること
ができます。GUI がない場合は、メッシュ内のすべてのモートに 2 つの親が存在することを単純に確認します。1 ホップのリ
ングの中には、親が 1 つだけのモートが１つだけ存在するはずです。それで OK であり、期待どおりです。
15.4 ネットワークの構成要素は順調に機能しているか？
この部分のネットワーク評価テストでは、メッシュ内の接続性の詳細に関する 3 つの定量的な質問に答えることが必要です。
3 つの質問は以下のとおりです。
1 ホップのリングの中には十分な数のモートがありますか？ネットワーク内のすべてのトラフィックは、ネットワーク・マネー
ジャに接続されているモートである AP モートに集まります。この単一モートは、送出されるすべてのデータにとって非常に
重要です。さらには、AP と直接通信するすべての 1 ホップ・モートも同様に重要です。メッシュ内で最も激しく動作している
モートは、1 ホップのリングの中にあります。これらはその子孫モートからのトラフィックを転送しているモートです。1 ホップ・
モートの数が増えるほど、トラフィックのバランスを調整することができるし、単一モートのリセットを切り抜ける機会が増え
るので、ネットワークにとっては好都合です。1 モートを除去すると多くのモートのデータが失われるシステムは決して作りた
くありません。おおよその目安として、1 ホップのリングの中には、少なくとも 5 モートまたは全体の 10% のいずれか多い方
このネットワー
の数のモートが必要です。ネットワーク内に 120 モートが存在し、そのうち 1 ホップ・モートが 10 個である場合、
クが崩壊すると保証されるわけではありません。ただし、専門家でなくとも 2 択（はい / いいえ）の質問に答えることができる
ように、答えが「いいえ」の場合に何をしたらよいかについてすぐに実施可能な手順を示し、定量化可能な優れたガイドライ
ンがここには必要です。
すべてのモートには十分な数の優れた隣接モートがありますか？この手順では、最後のモートが参加後 15 分経過するまで
待機し、ネットワーク内の検出済み経路をすべて調べて、すべてのモートに良質の隣接モートが十分存在することを確認す
る必要があります。最低でも、すべてのモートに良質の隣接モートが 3 つ以上存在することが必要です。良質の隣接モートと
は、このモートが -75dBm を超える性能で受信できるか、50% を超える経路安定性を備えた隣接モートのことです。これら
の経路は必ずしも現在使用中である必要はなく、必要なのはネットワークによる検出と報告が行われることだけです。
リンクの限界に達しているか限界に近いモートはありますか？現在の全製品では、90 以上のリンクがあるモートはネットワー
クに帯域幅問題の危険性を示しています。
SmartMesh IP アプリケーションノート
76/140
16 アプリケーションノート：よくある問題と解決策
16.1 はじめに
ネットワークを構築するときの目標は、信頼できるサービスを提供すると同時にワイヤレス・デバイスでの消費電力をできる
だけ低く抑えることです。リンクはエネルギーを消費するので、ネットワーク存続期間の参加段階および定常状態段階では、
モートに与えられるリンク数が、モートを通過する予想トラフィック量を転送できる最小限に設定されます。マネージャは、
サービス要求を正確に報告するモートと、平均の安定性が 50% より高い各経路に依存します。ボトルネックがある場合、つ
まり消費電力またはメモリの制約によっていずれかのモートがリンクを使い果たすと、このモートの子孫モートからすべての
トラフィックを伝送するための帯域幅が不足する可能性があります。
性能が低下しているネットワークの症状を以下に示します。
• 形成時間が長い
• モートがリセットする
• パケットの遅延に大きなばらつきがある
• マネージャがいずれかのモートからの消失パケットを報告する
これらの性能問題は、通常は以下のいずれか 1 つ以上が原因です。
• 不十分な接続性 - 良質の経路を持つ隣接モートが不足している
• 干渉 - 帯域内 WiFi または Bluetooth が存在するか、または強力な帯域外干渉物が近くにあり、経路安定性が低下し
ている
• 申し込み超過 - 許容数を超えたサービス要求をモートが報告しているため、輻輳が生じている
モートはその内部統計情報と経路統計情報を健全性レポート・パケットで報告します。これらの統計情報は 2 または 3 パケッ
トに分割され、15 分おきに生成されます。特に、現在モートが使用中の経路について、報告された経路安定性の値を確認
してください。モートはその内部パケット・キューの最大サイズと平均サイズを報告します。Dust のネットワークは、どの時
点のどのモートにも複数のパケットが存在することはめったにないように準備されているので、キューの長さの平均値がゼ
ロ以外の場合、通常は問題があることを示しています。
また、マネージャもネットワーク内のすべてのモートについて、ネットワークのトポロジとリンクの割り当てを常時監視してい
ます。この観点から、リンクの限界に達しているモートや、連続番号の一部を飛ばしてパケット消失を示しているモートがあ
るかどうかをすぐに識別できます。さらに、マネージャはモートがリセットしたらアラームを出します。
干渉も、多くの Dust ネットワークをまとめて配置している結果かもしれません。現在の製品ラインでは、ネットワークは時間
または帯域幅の割り当ての点で同期しないので、あるネットワークからの伝送が別のネットワークと同時に同じチャネルで
行われることがあります。このネットワーク間干渉によって深刻な性能問題が発生する可能性を低くするために対策を実施し
てきましたが、複数の共同設置ネットワーク環境では全体的な経路安定性が低めに見える可能性があり、経路安定性は全ト
ラフィックの関数です。経路安定性が低くても、データ信頼性が必ずしも低くなるとは限らないので注意してください。デー
タの信頼性が低くなるには、厳しい干渉が発生する必要があります。
SmartMesh IP アプリケーションノート
77/140
16.2 参加モートなし
モートがマネージャにまったく参加しない理由は以下のとおりです。
• マネージャが動作していない。
• マネージャに AP モートが接続されていない。
• AP モートにアンテナが接続されていない。
• マネージャのネットワーク ID または参加鍵（あるいはその両方）がモートのセキュリティ資格情報と一致しない。
• マネージャのアクセス制御リストにモートが含まれていない。
• モートがすべて AP から遠く離れて配置されている。モートに電源が入っていない。
• モートのセンサ・ファームウェアが join コマンドを正しく送信していない。
16.3 まとまった数のモートが参加しない
参加するモートもあれば参加しないモートもある場合は、少なくともマネージャと AP が機能している状態を確立しています。
一部のモートが参加しない理由として、以下のことが考えられます。
• 一部のモートの配置場所が離れすぎている。
• マネージャの最大モート数に達している。
• 一部のモートには、マネージャに参加するための正しいセキュリティ資格情報（ネットワーク ID、参加鍵、ACL 項目）
がない。
• 範囲内のモートがリーフ・ノードとして構成されている。
16.4 1 つのモートが参加しない
参加に失敗するモートの数がネットワーク・サイズと比較して小さい（つまり100 個中 1 個などの）場合、可能性のある理由
は以下のとおりです。
• 該当のモートに RF の問題がある（モートが壊れているか、アンテナが取り付けられていないなど）。
• 該当のモートのセキュリティ資格情報に誤りがある。
• 該当のモートに電源が入っていない。
• モートの最大数に到達している。
• 該当のモートは残りのネットワークから遠く離れて配置されている。
16.5 1 つのモートによる離脱と再参加の繰り返し
モートはネットワークへの接続状態を無期限に維持する必要があります。1 つのモートが参加後ネットワークを離脱し、再び
参加する理由として、以下のことが考えられます。
• モートに電源の問題があり、そのためモートがリセットされる。
• 隣接モートへの RF 接続に余裕がない。
• 隣接モートへの RF 接続が非常に過渡的で不安定である。
• （筐体内や大型の障害物の背後のように）RF 接続が切断されてから再確立できる場所にモートがある。
SmartMesh IP アプリケーションノート
78/140
16.6 動作範囲内のデバイスの経路安定性が低い
これはおそらく干渉が原因なので、モートを互いに近づけて配置し、SNR を高くします。
16.7 中継器を設置する必要があるが、すでにモートが最大数に
達している
接続性をよくするために中継器が必要だった場合：モートを１つ取り外して中継器を配置するか、モートを再配置して経路
を短くします。
第 1 ホップの帯域幅を広げるために中継器が必要だった場合：報告率を低減するか、モートを外側から第 1 ホップのリング
の中に移動します。
16.8 データ待ち時間が予想より長い
データ待ち時間を個々のデバイスで短くするには、要求のサービス期間を短くしながら発行率は未変更のままにします。た
だし代償として（該当のモートとその先祖（上位）モートの）バッテリ寿命が短くなります。また、基本帯域幅を広げれば、ネッ
トワーク全体での待ち時間を改善できます。
16.9 ネットワークが最適に見えない経路を使用している
ネットワークは消費電力が最低限で済むように絶えず最適化しようとします。その一環として、定期的に新しい経路が試行さ
れます。経路安定性に加えて、効果を発揮し始めるその他の検討事項があります。
SmartMesh IP アプリケーションノート
79/140
17 アプリケーションノート：プロビジョニング係数の変更による
マネージャ・スループットの増加
17.1 はじめに
マネージャは、プロビジョニングによって経路安定性の短期間の変化を監視し、モートが発生するトラフィックの関数として
モートにリンクを割り当てます。デフォルトでは、 SmartMesh ネットワークのプロビジョニング係数は 3 倍です。モートを通
過すると予想されるパケットごとに 3 つのリンクを獲得します。これにより、デバイスは安定性が一時的に 33% まで低下して
も乗り切ることが可能であり、そのときデータの消失につながるキュー満杯の危険性はありません。ただし、マネージャのア
クセス・ポイントで使用可能なリンクの数は限られているので、プロビジョニングによってパケットのスループットには上限
が定められます。
マネージャのスループットの上限があるアプリケーションでは、ネットワークを小規模なサブネットワークに分割して総ス
ループットを高める方法を推奨します。この解決策では不十分な場合、顧客はプロビジョニング係数を変更して限度内でス
ループットを増やすことができます。Dust では、プロビジョニング係数を 1.5 倍より低い値には設定しないことを推奨します。
経路安定性が 70% 未満に低下することは、これまでに観測した顧客のネットワークでは珍しいことではないので、ネットワー
クが低ノイズ、低マルチパス環境で動作しているという確実な認識がない限り、プロビジョニング係数を低く設定するのは
危険です。一般に、経路安定性が 67% より高い場合は、観測された最低の経路安定性の逆数にプロビジョニング係数を設
定します。
SmartMesh マネージャは、データ・トラフィックの伝送以外の機能を対象にリンクを使用します。たとえば、十分な再試行
回数でキープアライブを送信して経路アラームを防止します。このため、一部のモートには、トラフィック単独で必要な数よ
り多くアクセス・ポイントへのリンクが存在することがあります。アクセス・ポイントがリンクの上限に達した場合、これらの
リンクは他のモートがリンクを追加しないようにして帯域幅を確保します。より大きいネットワークやより深いネットワークで
は、後述するように制限値に近づくことがさらに困難になります。
17.2 プロビジョニングの変更：IP
外付けの RAM がある IP マネージャは、 256 ∼ 284 スロット（平均 270）のランダム化されたスロットフレームに上りデータ
専用のリンクが 223 あります（外付け RAM を使用しない場合は 150 リンク）。各スロットは 7.25ms です。プロビジョニング
これは 36.1 パケット/ 秒に相当します。プロビジョニングを1.5 倍に設定すると、最大スループットは 72.2 パケッ
が 3 倍の場合、
ト / 秒になりますが、すべての経路で 70% より高い安定性の確保が必要です。
マネージャ CLI を使用してプロビジョニング係数を変更するには、以下のように入力します（ここでは 1.5 倍）。
> set config bwmult=150
> reset system
プロビジョニング係数をプログラム式に変更するには、setNetworkConfig<bwMult> というマネージャ API を使用します。
SmartMesh IP アプリケーションノート
80/140
17.3 プロビジョニングの変更：WirelessHART
WirelessHART マネージャには、1024 スロットのスロットフレームに 737 の上りデータ専用リンクがあり、各スロットは
10ms です。プロビジョニングが 3 倍の場合、
これは 24.0 パケット / 秒に相当します。プロビジョニングを 1.5 倍に設定すると、
48.0 パケット / 秒の最大スループットが得られます。
プロビジョニング係数を変更するには（ここでは 1.5 倍）、/opt/dust-manager/conf/config/dcc.ini にある dcc.
ini ファイルの link_oversubscribe パラメータを以下のように指定します。
# Oversubscribe coefficient for link (1.0 no oversubscribing)
# Range: 1-100
link_oversubscribe = 1.5
デフォルトでは、dcc.ini ファイルは存在しません。まだパラメータを変更していない場合は、dcc.ini ファイル
を作成してプロビジョニング係数を変更する必要があります。必ず上記に示すディレクトリにファイルを作成してく
ださい。
SmartMesh IP アプリケーションノート
81/140
18 アプリケーションノート：輻輳したネットワークのデバッグ
18.1 はじめに
SmartMesh ネットワークは、各モートがセンサから受け付けたすべてのパケットを送出するよう設計されています。あるパ
ケットがモートに受け付けられたがマネージャに到達しない場合、このパケットは消失したと分類され、ネットワークの信頼
性にとってマイナスとなります。マネージャが報告する信頼性統計情報は、受け付けたパケット数の合計に対する非消失パ
ケット数の割合です。
可用性と呼ばれる別の重要な測定基準があります。可用性とは、センサがモートにパケットを渡そうとしたとき実際に渡すこ
とができた回数の割合のことです。SmartMesh ネットワークは、通常、 100% の信頼性に加えて 100% の可用性を確保す
るよう十分なリンクが準備されますが、可用性はアプリケーション層の測定基準なので、可用性を直接測定しているわけで
はありません。モートがパケットを受け付けることができない唯一の場合は、モートのキューがパケットで満杯になっている
ときで、これは輻輳モートと呼んでいます。輻輳モートには、そのローカル・トラフィックと転送トラフィックをサポートする
十分な上りリンクがありません。ネットワークが可用性を失う危険にさらされているかどうかを判断するには、輻輳モートを
調べる必要があります。
18.2 サービスの順守
SmartMesh マネージャはサービス・モデルを使用してネットワーク内の帯域幅を割り当てます。このモデルでは、送信が必
要なデータ量の算出を各センサ・アプリケーションが担当し、マネージャからの十分な帯域幅の要求を関連のモートが担当
します。要約すると、アプリケーションの役割は以下の内容を実行することです。
1. 個々のデータ・フローについてパケット生成間隔を計算します。
2. これらすべてのデータ・フロー全体に対してサービスを要求します（これらは SmartMesh WirelessHART では個
別に要求できますが、SmartMesh IP では 1 サービスだけです）。
3. このサービス、またはより高速のサービスがマネージャによって受け付けられたという確認を待ってから発行します。
4. 確認が到着しない場合は、タイムアウト後にサービスを再度要求します。
SmartMesh WirelessHART と SmartMesh IP では、サービス・モデルに関する詳細が異なる場合が多数あります。詳細に
ついては、それぞれのガイド（SmartMesh WirelessHART Services および SmartMesh IP Services）を参照してください。
18.3 可用性の推定
モートが周期的なデータを生成していることと周期が分っている場合は、マネージャで 15 分おきに受信されるパケットの数
を推定できます。たとえば、すべてのモートが 1 秒に１回報告している場合、15 分ごとに 900 データ・パケットが予想されま
す。さらに、モートは 15 分ごとに 3 つの健全性レポート・パケットを送信し、マネージャの要求および経路アラームに対する
応答も送信する可能性があります。可用性は標準で 100% であるか、時間が経過すると大幅に低下するので、15 分間隔に
つき 903 パケット前後の数値がこの例では良好と考えられます。
間隔ごとの送信パケット数が少ないと、パケットがモートによってすべて受け付けられ、マネージャによって正常に受信され
たかどうかを確認するのがより困難になります。報告回数の少ないネットワークはリンク数が少ないので、通常は待ち時間
が長くなってパケットが次の 15 分間隔に押し込まれ、数パケットの増減が報告総数の大きな割合を占めることがあります。
SmartMesh IP アプリケーションノート
82/140
以下に示すモート統計情報の取得結果では、すべてのモートが 5 秒に 1 回報告しているので、1 回の間隔につき約 183 パケッ
トが予想されます。1 回の間隔中に到着したパケットの数を知らせる PkArr 列のモート 11 の数値は、疑わしい低さです。以
下に示す例では SmartMesh WirelessHART マネージャの統計情報を示していますが、SmartMesh IP ネットワークにも同
じ考え方が適用されます。
> show stat short 0
It is now .................. 06/06/12 16:30:17.
This interval started at ... 06/06/12 16:15:00.
--------------------------------NETWORK STATS---------------------------------PkArr
PkLost
1806
0
PkTx(Fail/ Mic/ Seq)
PkRx
Relia.
5395(2430/
3098
100%
0/
0)
Latency
Stability
3.61s
54.96%
---------------------------------MOTE STATS-----------------------------------Id PkArr PkLst PkGen PkTer PkFwd PkDrp PkDup Late. Jn Hop avQ mxQ me ne Chg
T
2
181
0
181
0
356
0
16 1.34
0
1
0
4
0
0
0 22
3
182
0
182
0
194
0
20 1.49
0 1.2
0
3
0
0
0 22
4
182
0
183
1
98
0
17 1.63
0
1
0
4
0
0
0 22
5
182
0
182
0
329
0
18 1.46
0 1.4
0
4
0
0
0 22
6
182
0
182
0
82
0
16
1.7
0 1.2
0
2
0
0
0 22
7
154
0
--
--
--
--
42 20.7
0 2.6
-
-
-
-
-
8
183
0
157
4
43
0
30 2.66
0 2.3
0
1
0
0
0 22
9
183
0
182
0
0
0
30 3.39
0
2
0
2
0
0
0 22
10
182
0
188
6
65
0
45 2.96
0 2.1
0
3
0
0
0 22
11
166
0
169
1
0
0
42 17.2
0
1
4
0
0
0 22
3
-
ここでの信頼性は 100% です。PkLst 列の項目数は 0 ですが、アプリケーションはモート 7 および 11 からより多くのパケット
数を予想していたので、これらのモートでは可用性が 100% より小さいです。一般に、センサが送信しようとしているパケッ
ト数は分らないので、代わりに輻輳の兆候に注意する必要があります。
18.4 輻輳の識別
可用性の推定値に加えて、予想より長い待ち時間や、モートのキューの数値を統計情報で調べることで、輻輳を識別できま
す。おおよその目安として、キューの長さの平均値（avQ）が 0 より大きいモートは、どこかの時点で輻輳を経験している危険
があります。キューの最大長（mxQ）が 4 以上のモートは、パケット生成間隔の間に深刻な輻輳に見舞われた可能性があり
ます。最後に、輻輳モートの待ち時間は、通常は対等のモートの待ち時間より長くなります。上記統計情報でのモート 11 は
これらの基準をすべて満たしており、直前の 15 分間は間違いなく輻輳状態でした。
SmartMesh IP アプリケーションノート
83/140
健全性レポートの欠落も輻輳を示している可能性があります。このシナリオでは、モートが健全性レポートを生成する時刻
にモートのキューが満杯であり、モートは動作を完了することができませんでした。モートの統計情報では、
これは上記のモー
ト 7 の行のような形で現れます。キューの占有率に関するレポートを直接取得したわけではありませんが、それでも対等な
モートよりPkArr の値が低く、待ち時間が長いことが分ります。モートは健全性レポートの生成に失敗すると、カウンタを増
やし続けて、次の健全性レポートには以前と同様に不足情報が要約されるように動作します。
モートは輻輳状態になると、その子モートがパケットをアンロードしようとするときに、子モートに NACK の送信を開始しま
す。これにより、輻輳モートの子モートでの実効上り帯域幅が狭まるので、プロビジョニングの余裕が十分でない場合は、子
モート自体が輻輳状態になる原因となる可能性があります。この進行はメッシュ全体にわたって繰り返されることがあります。
このため、問題のモートより3 ホップ深いモートは輻輳状態になる可能性があり、そのセンサがオフに戻っていると認識しま
す。この結果、マネージャがこのモートから受信するデータ・パケット数は予想より少なくなります。輻輳の発生源を見つけ
るため、各輻輳モートの上り経路を AP に向かってたどる必要があります。輻輳している最低ホップのモートが、その子孫モー
トの輻輳の推定発生源です。
18.5 帯域幅モデル
マネージャが各モートに与えようとするリンク数は、モートが安定性 100% のネットワークでローカル・トラフィックと転送ト
ラフィックを理論上伝送する必要があるリンク数の 3 倍です。これは安定性が 33% に低下するまでネットワークが動作でき
ることを意味していますが、安定性 33% とは、しばらくの間は 100% で、その後しばらくすると 0% になるということも多く、
それは安定した「2 回失敗して 1 回成功」のパターンと比べると、正常なマルチホップ・データ収集に適していません。どこか
に輻輳が存在する場合は、このモデルのどこかが壊れていて、輻輳の発生源については以下のいずれかが当てはまります。
• 経路アラームが原因で最近親を失った
• 経路安定性が 33% より低い
• 消費電力またはメモリの制約により、割り当て可能なリンクを使い果たした
• 子孫モートによる報告がそのサービス・レベル / 基本帯域幅レベルで可能な数を超えている
経路アラームはマネージャ通知にサブスクライブすることでモニタできます。また、経路アラームは通常、きわめて一時的な
輻輳を引き起こしますが、モートに十分な数の良好な隣接モートがある場合、この輻輳は解消します。モートに十分な数の
良好な隣接モートがない場合は、経路安定性が常に低い値となり、慢性的な輻輳が生じることがありますが、これは干渉が
原因である可能性があります。指針については、
「_inc_AN_IdentifyingandMitigatingInterference」のページを参照してく
ださい。
マネージャ CLI で show mote コマンドを発行して、輻輳モートがそのリンク限界にどの程度近づいているかを確認するこ
とができます。特に、以下の 2 行を調べてください。
Neighbours: 27 (max 32). Links: 34 (max 100)
Links per second: 4.882812 (limit: 11.648407)
ここで示されているリンクの数（34）は、最大値である 100 をはるかに下回っており、消費電力に起因する限界である 11.6 リ
ンク / 秒は、現在の 4.9 リンク / 秒を優に超えています。いずれかのモートがリンク限界に近づいている場合は、これらのモー
トのすぐ近くに中継器モートを追加してください。
最後に、マネージャは各センサがサービス・モデルを順守することを期待します。ネットワークの基本帯域幅で規定されてい
る速度より高速にセンサが報告する予定の場合、センサはより高速のサービスを要求します。それでも、センサがこれを適
切に実行する保証はないので、引き続き潜在的な根本原因とみなされます。
SmartMesh IP アプリケーションノート
84/140
モートがその要求サービス・レベルの限度を超えていないことを確認するため、show mote の結果をもう一度使用できます。
Bandwidth:
output
planned
global service
local service goal
guaranteed for services
0.3906 current
0.3614
delta
0.0250 current
0.0250 for child
0.3906
-0.0108
0.0250
0.3241 Free
0.0415
ここでは、ローカル・サービスの行を調べます。この最初の値 0.025 は、モートが要求したとマネージャが考えているパケッ
ト / 秒の値で、サービスと基本帯域幅の両方を含みます。現在の値も同じなので、マネージャが実際にこの帯域幅を割り当
てたことを示しています。差分の負の値が示しているのは、表面上はすべてのローカル・トラフィックおよび子孫モートのト
ラフィックをサポートするのに十分な帯域幅がこのモートにあるということです。0.025 パケット / 秒では、15 分の期間にモー
トが生成するデータ・パケットは、毎回最大でも36です。以前示したモートの統計情報（特にPkArr列の情報）を使用して、モー
トによる生成数がこの最大レベルより多いことはなく、割り当てを超えていないことが確認できます。
18.6 輻輳の緩和
SmartMesh ネットワークが数箇所で輻輳している場合は、ネットワーク全体の経路安定性が低すぎて正常に機能できてい
ない可能性があります。この場合の対応としては、モートの密度を高くすることが望ましいです。これらの追加モートは、それ
までに配置されているモートの間に広がり、潜在的な選択対象経路の数を増大できるので、その結果全体的な経路安定性
が向上します。新しいモートが追加データを報告していない場合、必要な全放出帯域幅がこの解決策によって広がることは
なく、むしろ既存のモートの平均消費電力が減少します。
モートの密度を高くすることができない場合は、輻輳モートのリンクの数を増やすことでも対応できます。輻輳が広い範囲に
わたっている場合、ネットワーク内のすべてのモートでのリンクの数を増やす方法が 2 つあります。それは、プロビジョニン
グを増加するか、基本帯域幅を減少することです。輻輳がネットワーク内の一か所に集中している場合は、このモートがより
高速のサービスを要求することで解決する可能性があります。リンクの数を増やすと、リンク数が増えたモートは、消費電力
が増えます。さらに、これらが増加すると、アクセス・ポイントに必要となる受信リンクが増えます。割り当てに使用できる余
分な帯域幅がアクセス・ポイントにない場合は、ネットワークを 2 つに分割して追加リンクのサポートが必要になる可能性が
あります。
SmartMesh IP アプリケーションノート
85/140
19 アプリケーションノート：干渉の影響の特定および軽減
19.1 はじめに
SmartMesh ネットワークは、干渉のない環境と比較した場合の性能低下を最小限に抑えつつ、消費電力が若干増えるだけ
で干渉に耐えられるよう設計されています。ただし、事例の数は少ないものの、性能に影響するほど強い干渉があるため、
以下の症状を示すことがあります。
• RSSI > -70dBm の場合でも多数の経路安定性が 60% に満たない
• 上りの待ち時間 >> 上りのフレーム長の 3 倍
• 平均キュー占有率 >= 1、または最大占有率 >= 3
• 信頼性 < 99.9%
干渉は、802.11g 無線ルータなどの帯域内干渉、または WiMax などの極端に大きな帯域外干渉の形を取ることがあります。
スペクトラム・アナライザ（Wi-Spy などの割安な WiFi 検出器）を使用することにより、混雑している周波数領域を特定する
ことができます。
• Bluetooth などの高速ホッピング干渉が、一様に引き上げられたノイズフロアとして現れる。
• 802.11 WiFi ルータが広範なピークとして現れる。
• 帯域外干渉はまったく現れていませんが、それでもネットワーク内のレシーバを飽和させる可能性がある。
指向性アンテナをスペクトラム・アナライザと組み合わせて使うことにより、干渉の発生源を正確に特定できることがありま
すが、
スペクトラム・アナライザをまったく使用しないで干渉物の存在を推定することが可能な場合もよくあります。ネットワー
ク統計情報を使用して干渉の存在を推測する方法も多く、さらに、干渉を回避する必要があるかどうかを判断することもで
きます。
SmartMesh IP アプリケーションノート
86/140
19.2 RSSI と経路安定性の確認
Dust は、ネットワークのスナップショット・ファイルを取り、それを RSSI および経路安定性を示す滝型曲線に変換するツー
ルを提供しています。
良い滝型曲線は以下のような形をしています。
上側のヒストグラムでは、-90 ∼ -80dBm の範囲で使用された経路の数と、同様に -60 ∼ -50dBm の範囲で使用される経
路の数を確認してください。右側のヒストグラムでは、経路の大部分が 80% 以上であり、50% より低い経路は少ないことを
確認してください。散布図では、-70dBm より良好なほとんどの経路は 60% 以上の安定性があるはずです。滝型曲線作図プ
ログラムはモート間の経路とモート -AP 間の経路に分けています。AP にはハードウェアまたは干渉に関してモートとは異な
るところが存在することがあるからです。
SmartMesh IP アプリケーションノート
87/140
良い滝型曲線と次の曲線を対比してみます。
ここに示す曲線は全体が右側にシフトしており、-70dBm より低い経路がほとんど見当たりません。デバイスが微弱信号の
受信に苦労しているので、このタイプの滝型曲線はレシーバの不具合または干渉を示しています。このネットワークが性能
に対する顧客の期待を満足する可能性はまだありますが、このような配置ではすべてのモートに十分な接続性を確保するよ
うに特別な配慮が必要です。
各顧客は、目標とする配置環境に似た「既知の良好な」環境で顧客固有のハードウェアを使用し、測定可能な干渉のない状
況でテスト・ネットワークを配置する必要があります。このテスト配置で生成された滝型曲線は、どんなフィールド内データ
とも比較できる最高条件として使用します。特に、アンテナの選択は受信感度に大きな影響を与えるので、すべての顧客に
同じ最高条件曲線を使用することはできません。
19.3 モートの待ち時間、キューの長さ、および信頼性の確認
その他の確認を行うには、ネットワークのスナップショット・ファイルを調べます。上記の悪い滝型曲線図を持つネットワーク
から取った短期間の統計情報の抜粋を以下に示します。
「NETWORK STATS」の下の行では、信頼性が 99.9% 未満を示し
ていることに注意してください。ここでの待ち時間（Latency）の値はフレーム長の 3 倍（30 秒）より大幅に大きいわけではあ
りませんが、
「MOTE STATS」の下を見ると、avQ および mxQ の列では、いくつかのモートのキューが最大数 3 を超えていて、
一部のモートの平均キューがゼロ以外の値になっています。データが欠落している行が存在していることも、ネットワークが
問題を抱えていることを示しています。該当のモートはキューが満杯で健全性レポートを生成できなかったからです。
SmartMesh IP アプリケーションノート
88/140
< show stat short 2
It is now .................. 04/23/12 15:49:45.
This interval started at ... 04/23/12 15:00:00.
--------------------------------NETWORK STATS---------------------------------PkArr PkLost PkTx(Fail/ Mic/ Seq) PkRx Relia. Latency Stability
1338
13
17k(6603/
0/
0)
13k 99.04%
11.9s
61.44%
---------------------------------MOTE STATS-----------------------------------Id PkArr PkLst PkGen PkTer PkFwd PkDrp PkDup Late. Jn Hop avQ mxQ me ne Chg T
10
12
0
10
0
0
35
0 3.25 0 2.6
0
1 0 09154 22
11
11
0
13
1
0
32
0
1.7 0 1.3
0
1 0 07825 25
12
17
0
16
2
0
29
2 4.92 0 1.5
0
2 0 08298 24
19
13
0
16
2
0
39
2 3.76 0 2.5
0
1 0 08429 23
20
13
0
13
0
0
29
1 6.65 0 1.6
0
1 0 08127 21
21
12
0
12
0
0
27
4 3.52 0 2.7
0
2 0 08602 21
22
4
0
----0 0.171 0
1
- - 23
11
0
11
2
76
3
2 2.73 0 2.2
0
2 0 0 21k 19
24
13
0
13
0
0
28
1 1.94 0 1.6
0
1 0 07873 21
25
10
0
14
5
95
1
2 0.753 0
1
0
4 0 0 43k 18
26
14
0
13
0
0
28
1
2.6 0 1.4
0
1 0 08060 22
27
18
0
14
1
0
26
1 5.01 0
3
0
1 0 08085 25
28
15
0
11
2
111
2
1 0.856 0 1.5
0
2 0 0 28k 19
29
4
0
----0 0.792 0
2
- - 46
22
0
15
0
0
32
2
4.4 0 3.2
0
1 0 07897 28
47
6
0
----1
1.16 0
2
- - 48
14
0
18
6
540
7
4 0.303 0
1
0
5 0 0 78k 18
56
12
0
11
3
90
0
7
2.81 0 4.3
0
3 0 0 486 19
57
4
0
5
3
145
0
2
2.75 0 4.5
1
4 0 0 803 19
64
9
0
13
6
447
7
2
1.54 0
3
2
8 0 01886 19
19.4 軽減
干渉を明確に特定したら、問題の是正に向けた手順がいくつかあります。
1. 干渉物を特定し、それを停止するか移動します。このためには、指向性アンテナを使用して発生源を突き止めるか、
他のデバイスがすぐ近くで送信している可能性とその内容を知ることが必要です。ネットワークの狭い領域に影響し
ている低電力の局所干渉の場合には、通常これが唯一の解決策です。非常に大電力の帯域外 WiMax による干渉
が見つかった例が 1 つありました。この場合は、害を及ぼしている産業用ネットワークに干渉しないように動作を変
更しました。
2. ブラックリストに登録します。干渉が一部の狭いスペクトラムに限られていることが分っている場合には、これをブ
ラックリストに登録することができます。完全にブロックされたチャネルで電力が浪費されていることが判っている
場合には、ブラックリストを使って 15 チャネルを 5 チャネルまで絞り込むことができます。
3. プロビジョニング係数を増やします。こうすると消費電力は増えますが、信頼性が向上し、待ち時間は影響を受けま
せん。
4. 親の数を増やします。これにより、経路安定性が低いことによる経路障害を軽減することができます。安定性が低く
なるほど、障害と見なされる程の連続的した偶発障害が発生する確率が増えます。下流の親が追加されると、下り
方向の受信回数が増えるので、消費電力はすべてのノードで増加します。上流の親を追加すると、キープアライブ・
パケットの送信量を増やす必要があるので、消費電力がわずかに増加します。また、マネージャによって選択され
た最短経路の他にネットワーク内に経路が増えるので、待ち時間がわずかに長くなります。
5. 「良好とされる」経路の最小 RSSI を大きくします。これにより、RSSI の低い経路のテストが省かれるため、干渉が
あるネットワークでの参加と最適化が加速されます。
6. 帯域外干渉を除去する狭帯域フィルタを追加します。これはモートのハードウェアに対する修正です。
SmartMesh IP アプリケーションノート
89/140
20 アプリケーションノート：正確なタイムスタンプの取得
20.1 時間
Dust ネットワーク内のすべてのデバイスは時間を共有しています。これにより、センサ・アプリケーションは、ネットワーク時
刻を使用してセンサ測定の正確なタイムスタンプを実現できます。理想条件下では精度を数十 µs 程度に合わせることがで
きます。これは全ての Dust 製品に共通した機能です。
1. センサ・プロセッサは測定を行い、モートの TIME ピンにストローブ信号を送出します。
2. モートはその現地時刻を UTC および ASN で返します。
3. センサ・プロセッサはタイムスタンプおよびデータをパケットに書き込みます。
4. モートはパケットをマネージャに転送して、ホスト・アプリケーションに送ります。
5. ホストは、必要であればデータ通知の内容についてネットワーク時刻と「絶対」時刻の差について後処理します。
測定のタイムスタンプの精度はシステム内での種々の不確実性によって決まりますが、その内容についてはこのアプリケー
ションノートで説明します。
20.2 参考文献
• RFC 5905 は、Network Time Protocol（NTP）のバージョン 4 を規定しています。
• IEEE1588-2008 は、Precision Time Protocol（PTP）のバージョン 2 を規定しています。
• IEEE C37.238 は、電力システムで IEEE1588 を使用するための規格です。この規格は、広範囲にわたって広がる設
備を同期化するためにイーサネットの使用やさまざまな設定について規定しています。
20.3 IP Eterna ベース・システム
ネットワーク時刻を使用する手順のフローチャートを図 1 に示します。SmartMesh IP マネージャは setTime API を備えて
いますが、ユーザーはこの API を使用して、ネットワークの形成前にマネージャに UTC 時刻を設定できます。ネットワークの
ASN カウンタは、この UTC 時刻を基準にします。ただし、そのときからマネージャは「絶対」時刻から徐々に離れていき、現
時点では時刻を継続的に修正する仕組み（たとえば、 SmartMesh WirelessHART マネージャで利用できるような NTP）が
存在しないので、マネージャの UTC に不確実性が生じる原因になります。マネージャの時刻ピンを使用することにより、ホ
スト・アプリケーションはこのずれを修正することができます。時刻は ASN と UTC の両方でモートに返されるので、正確な
タイムスタンプを得るためにマネージャに有効な UTC 時刻を設定する必要はありません。
SmartMesh IP アプリケーションノート
90/140
センサが測定を行う
はい
緩いタイミングで
OK ？
いいえ
センサ・プロセッサは TIMEn ピンに
ストローブ信号を送出し、
モートは ASN を
UTC で返す
センサ・プロセッサはアプリケーション・
タイムスタンプをデータに付加する
センサ・プロセッサはホスト・
アプリケーションにパケットを送出する
マネージャは受信パケットの通知を
生成する
緩いタイミングで
OK ？
ホストは通知タイムスタンプを使用する
ホストはマネージャの時刻ピンに
ストローブ信号を送出し、
モートは ASN と
UTC で返す
ホストはマネージャのずれを考慮して、
アプリケーション・タイムスタンプを修正する
図 1 - Eterna LTC5800/5901/5902 マネージャ・ネットワークでのタイムスタンプ処理
SmartMesh IP アプリケーションノート
91/140
20.4 緩いタイミング
緩い（数百ミリ秒）タイミングだけが必要な場合は、アプリケーションのタイムスタンプは必要ありません。ホスト・アプリケー
ションはデータ通知または ipData 通知の中のタイムスタンプを使用できます。このタイムスタンプにはキュー操作の不確実
性が存在し、それは数十ミリ秒になることがあります。このタイムスタンプにもやはりマネージャ UTC の不確実性が存在し
ますが、これについてはタイムスタンプされたデータに対する修正ができることを後で説明します。
20.5 正確なタイミング
1 ミリ秒未満のタイミング精度が必要な場合、センサ・プロセッサは測定を実施し、モートの TIME ピンにストローブ信号を
送ってネットワークのタイムスタンプを取得し、パケットに組み込むことができます。モートはその現地時刻を（UTC および
ASN で）返しますが、これには 2 つの不確実性があります。1 つはモートの現地時刻の不確実性で、これは経路安定性、モー
ト間の温度のばらつき、トポロジなどの関数です。もう 1 つはモートの TIME ピンの不確実性で、デバイスのデータシート特
性です。パケットには ASN または UTC のタイムスタンプを組み込むことができます。ASN を使用すると、 UTC 時刻が実際
には正確ではないことが明確になります。
アプリケーション・プロセッサは、データ通知を受信したらマネージャの TIME ピンを起動する必要があります。そうすること
アプリケーショ
により、現在の ASN 時刻または UTC 時刻をマネージャの TIME ピンの誤差の範囲内に入れます。これにより、
ンはパケット内のタイムスタンプに加えてマネージャからの現在のタイムスタンプを使用することで、マネージャの UTC 不
確実性を取り除き、パケットの絶対タイムスタンプがホストの時刻の精度に合うよう計算することができます。
20.6 最も高精度なタイミング
最高のタイミング精度を得るには、不確実性の原因をすべて考慮し、可能な場合は最小限に抑える必要があります。
• 通過時間（待ち時間）があると通過の不確実性が加わります。これはネットワーク・トポロジとネットワーク活動の関
数です。活動が非常に少ないネットワークでパケットが生成された場合、そのパケットがマネージャに到着するのに
30 秒かかることがあります。マネージャのずれが 50ppm である場合は、データが届くまでの時間のマネージャのず
れにより、 1.5ms の不確実性が計算値に加わります。アプリケーション・プロセッサがマネージャの時刻ピンに定期
的にストローブ信号を送出してマネージャのずれを測定する場合は、通過の不確実性を除去できます。その後、アプ
リケーション・プロセッサは現行の UTC オフセットを計算して、マネージャの UTC 不確実性の他に、通過時間に起
因する不確実性を除去します。ただし、標準的な条件下では、通過の不確実性は数 µs です。
• サンプルの取得とモートの TIME ピンへのストローブ信号出力の間のセンサ・プロセッサ内での遅延または不確実性
については、インテグレータの責任範囲です。
• 急な温度勾配は、モートの現地時刻の不確実性に影響することがあります。この誤差は、温度勾配のあるモートのす
べての子孫モートに伝播します。この影響によってシステムの要求を超える誤差が発生する可能性がある事例では、
アプリケーションがすべてのモートの温度を測定して、大幅な温度上昇が検出された場合にアラームを報告すること
ができます。その後、ホスト・アプリケーションは、これらのアラーム期間中のタイムスタンプがあるデータを無視す
るか、すべてのモートが一定の温度になっている時間帯に取得した測定値より大きな不確実性をアラーム期間中の
データに割り当てることを選択できます。安定した温度で動作するフラット・トポロジ・ネットワークは、モートの現地
時刻の不確実性が最低になります。
SmartMesh IP アプリケーションノート
92/140
20.7 IP 不確実性の定量化
以下に示すのは、IP ネットワークでの不確実性の値です。
• TIME ピンの不確実性 - Eterna ベースのマネージャまたはモートでは、ワーストケースで +/-1 µs です。
• モートの現地時刻の不確実性 - h ホップにあるモートの場合、標準的な不確実性は 0.6h1/2 µs になり、ワーストケース
C/ 分の温度勾配は、1 回の配信で 1.5µs•min/°
C
で 30h µs になると予想されます。さらに、規格限界値である最大 8°
増加します。
• マネージャの UTC 不確実性 - 水晶振動子の特性を評価済みの場合、稼働時間はワーストケースで +/-50µs/s、標準
で +/-2µs/s です。
• 通過の不確実性 - 水晶振動子の特性を評価済みの場合、パケットの通過時間による誤差はワーストケースで
+/-50µs/s、標準で +/-2µs/s です。
• キュー操作の不確実性 - パケットがモートによってアクノリッジを返されると仮定した場合、ワーストケースで 50ms
未満です。関係があるのは、ネットワーク層のタイムスタンプを使用する場合だけです。
20.8 WirelessHART（Linux SBC ベース）システム
Linux SBC ベース（PM2511/DN2511/LTC5903）のマネージャは、マネージャを絶対時刻基準に同期させ続けるための
NTP をサポートしています。マネージャは UTC（グローバル）時刻を取得するため、NTP サーバに接続されています。グロー
バル時刻に関するマネージャの精度は、マネージャの UTC 不確実性によって決まります。NTP サーバを専用接続回線に接
続すると、IP ネットワークが不確実性に与える影響を取り除くことができます。
ネットワーク時刻（ASN）はアクセス・ポイント（AP）とは独立して維持されます。マネージャは AP の時刻ピンにストローブ
信号を出して AP の時刻を測定し、得られた時刻をマネージャ独自の推定値と比較します。この測定値には AP の TIME ピン
の不確実性が含まれており、それはどちらの AP（DN2510 または Eterna）が使用されているかにより決まってきます。AP の
時刻が 100ms（max_utc_drift という ini パラメータで設定可能）を超えて異なっている場合、マネージャは新しい UTC 時刻
のマッピングを低信頼性のブロードキャストを介してすべてのモートに対して強要します。max_utc_drift の値を小さくする
と、下りのメッセージが増加します。たとえば、50ppm のずれがある LTC5800 ベースの AP の時刻をマネージャの UTC 時
刻から 100ms 以内にするには、約 30 分に 1 回の下りメッセージが必要です。これを 10ms に維持するには、3 分に 1 回のメッ
セージが必要です。
センサ・プロセッサがモートの UTC タイムスタンプを使用している場合は、UTC 不確実性に UTC マッピングの不確実性を
追加する必要があります。モートが数回の UTC 更新に失敗し、そのため AP とのずれが 200ms を超える可能性があります。
理論上は ASN タイムスタンプを使用すると UTC マッピングの不確実性を排除できますが、WirelessHART マネージャは正
確な ASN 時刻を取得する手段を備えていません。getTime マネージャ API は、マネージャが測定した最後の ASN/UTC マッ
ピングを返すので、最大で max_utc_drift ms の誤差が発生する可能性があります。
不確実性の発生源の多くは、現在の SmartMesh WirelessHART マネージャでは制御することも原因を特定することもでき
ないので、使用できるのは緩いタイミング（数百ミリ秒）だけです。
SmartMesh IP アプリケーションノート
93/140
20.9 WirelessHART 不確実性の定量化
以下に示すのは、WirelessHART ネットワークでの不確実性の値です。
• マネージャの UTC 不確実性 - これはマネージャ、NTP サーバ、および IP ネットワークの待ち時間の関数です。AP の
関数ではありません。この測定値は低トラフィックのイーサネット・ネットワークでは約 1ms になりますが、イーサネッ
ト・ネットワークが混雑状態になると 100ms 近くまで上昇することがあります。
• TIME ピンの不確実性 - これは DN2510 ベースの AP またはモートでは -60/+600µs になり、Eterna ベースのモート
では +/-1µs になります。
• UTC マッピングの不確実性 - モートが数回の UTC 更新に失敗し、そのため AP とのずれが最大 +/-300ms になる可
能性があります。
• モートの現地時刻の不確実性 - DN2510 ベースの AP を使用した場合、h ホップにあるモートでは、平均で 45h1/2µs
近辺になり、
ワーストケースで 150h になると予想されます。LTC5800 ベースの AP を使用した場合、平均で 1.2h1/2µs
になり、ワーストケースで 30h µs になると予想されます。さらに、規格限界値である最大 8°
C/ 分の温度勾配は、1 回
C 増加します。
の配信で 3µs•min/°
20.10 同期イベント
同期測定または同期イベントもすべての製品で可能ですが、手順が若干異なります。
• アプリケーションはマネージャの getTime API 呼び出しを使用して現在の ASN を取得します。
• ホスト・アプリケーションは、
（将来の）イベント時刻が書き込まれているアプリケーション層のパケットをブロードキャ
スト * します。メッセージは配信を確実に行うため、3 回送信されます。** すべてのモートは将来の ASN を使用してイ
ベントを同期化できます。すべてのモートが将来の ASN を受信し、イベントに備える時間を確保できるように、将来
の ASN として十分に大きな値を選択します。120 秒より大きな値が安全です。
• モートはパケットを受信し、アプリケーション層パケットが入っている通知をセンサ・プロセッサに送信します。
• 各センサ・プロセッサは、モートの時刻ピンを使用して現在時刻を確認します。
• 各センサ・プロセッサは、イベント、測定、作動の時刻がいつかを適宜確認します。センサ・プロセッサが非補償型の
32kHz 水晶振動子を時刻の基準（+/- 150 PPM）として動作させていると仮定すると、120 秒タイマでの絶対サンプル時
刻のデバイス間のばらつきが +/-15ms まで広がる可能性があります。このためには 24 ビットのタイマが必要であること
に注意してください。このレベルの同期では不十分な場合には、センサ・プロセッサはモートを定期的にポーリングして
現在の ASN を取得し、それに応じてタイマを調整できます。ASN の差分および時間の変換は次式のように行われます。
差分時間 = ASN の差分 * スロット長
ここで、SmartMesh WirelessHART のスロット長は 10ms であり、SmartMesh IP のスロット長は 7.25ms です。
• 各センサ・プロセッサは、イベントによって生成されたすべてのデータに対して上記のタイムスタンプ・ロジックをオ
プションで実行できます。
* 宛先（IP メッシュ層または WirelessHART ネットワーク層）アドレスは 0xFFFF です。
** コマンドを受け取るすべてのモートの待ち時間と可能性のトレードオフを考慮すると、低信頼性の下り伝送に対しては 3 回
の再試行が選択されます。再試行の回数が増えるとこの可能性は高くなりますが、待ち時間が長くなります（つまり、将来の
ASN はさらに先に設定する必要があります）。アプリケーション・レベルのアクノリッジがセンサ・プロセッサによって返さ
れる場合は、再試行の重複を避けることが可能です。この場合、センサ・プロセッサは同じ値の「将来の ASN」が記載され
た重複したコマンドは破棄する必要があります。
SmartMesh IP アプリケーションノート
94/140
21 アプリケーションノート：複数のマネージャを使用した
大規模ネットワークの構築
21.1 大規模な配置
1 つのマネージャがサポートできる数を超えた検出点を持つ実装形態があります。現在では、複数のマネージャを置いて全
ての範囲をカバーしています。これらのマネージャとそのモートの一部またはすべてが重複した無線到達範囲があることが
予想されます。可能な場合は、隣のマネージャを近接して配置するのではなく、数メートル離して配置する方が優れています。
これはマネージャのアクセス・ポイント間の無線干渉を避けるためです。全体的な無線セル空間の容量に近づきすぎなけれ
ば、複数の隣接マネージャが配置された実装は完璧に機能します。
各マネージャはマネージャ独自のネットワークを制御します。また、モートを種々のネットワークに分ける重要な方法が 2 つ
あります。一つ目は、各ネットワークにはネットワーク ID を与える方法です。この値はネットワークが送信する全ての通知の
中にあり、モートが参加した後にはパケットをフィルタするために使用します。二つ目は、マネージャは、ネットワークへの参
加を許すモートの MAC アドレスと参加鍵を指定するアクセス制御リスト（ACL）を保持できます。ネットワーク ID と ACL を
組み合わせて使用することにより、大規模な配置でのモートを小規模なネットワークに分割することができます。ネットワー
ク ID を制御した場合は、参加先のネットワークをモート側が決定する必要があります。ACL を制御した場合はマネージャが
決定できますが、この方法は、ACL に登録されていないモートはネットワークに参加しようとしてもできません。
SmartMesh WirelessHART マネージャは最大 250 モートまたは 500 モートをサポート可能であり、SmartMesh IP マネー
ジャは最大 32 モートまたは 100 モートをサポートできます。各 SmartMesh マネージャは 20 ∼ 25 パケット / 秒（プロビジョ
ニング係数を低くした場合は最大 40 パケット / 秒）の帯域幅をサポートしているので、モート数の増加ではなく帯域幅を広
げる目的でマネージャの追加が決定されることがあります。たとえば、100 モートが 1 秒に 1 回データを報告するネットワー
クは、5 つの SmartMesh マネージャで安全に実行できます。
21.2 RF の制限事項
SmartMesh WirelessHART の場合は、存在するチャネル数が 15 で 1 秒当たりのスロット数が 100 です。これは、1500 パケッ
ト / 秒の絶対最大数をさまざまなチャネル上であるいはさまざまな回数送信するには十分なセル空間です。複数のマネー
ジャが同じ無線空間を共有している場合、マネージャ同志はスケジュールも正確な時間も共有していないので、トラフィック
が重複した場合に衝突が発生します。マネージャを同じ場所に設置している場合は、セル空間の容量の約 25% を使用する
のが安全であることが経験的に分っているので、この場合は、全帯域幅が 375 パケット / 秒までマネージャを追加しても安全
です。一例として、4 つの SmartMesh WirelessHART マネージャを使用して 1800 モートが配置されており、各モートは 30
秒ごとに温度を報告するよう設定されているとします。この場合の全帯域幅の要件は 1800/30 = 60 パケット / 秒なので、こ
の配置は RF 制限値を十分に下回っています。
SmartMesh IP では、チャネル数は同じ 15 ですが、1 秒当たりのスロット数は 138 です。同じ計算を実行すると、共同設置
マネージャの安全な制限値は 517 パケット / 秒です。
重複ネットワークのトラフィックが増加するにつれて、ネットワーク間での衝突が経路安定性のわずかな減少として現れます。
SmartMesh マネージャは、１つの経路を完全に遮断するのではなく、すべての経路に均等に影響するように衝突を分散さ
せる軽減戦略を持っています。Dust ネットワークはデューティ・サイクルが低く低消費電力なので、他の Dust ネットワークか
らの干渉は、WiFi のような他の形態の干渉よりも被害が少なくて済みます。
SmartMesh IP アプリケーションノート
95/140
21.3 理想的な配置のガイドライン
理 想 的 な 事 例で は、 使 用 可 能 な マ ネ ージャの 間で モートが 均 等 に 分 けられます。たとえば、 48 の モートと 3 つ の
SmartMesh マネージャがある場合、各マネージャには 16 のモートが与えられます。これを実行するには、いくつかの段階
があります。
• 3 つのユニークなネットワーク ID を選び、各マネージャに 1 つずつ与える
• マネージャごとに 16 のモートを選び、該当するネットワーク ID でプログラムされる
• 各マネージャは 16 のモートの MAC アドレスおよび参加鍵が登録された ACL を持つ
• 設置の現地では、16 モートの各ネットワークが配置ガイドラインに従うようにモートが配置される
下の図では、ネットワーク ID で分けられた 3 つのネットワークを異なる色で表しています。モートの配置は、色分けされた各
ネットワークでの接続状態が十分になるように行われます。
モートは通知をネットワーク ID 別に選別するので、参加処理中のモートが参加要求を送信しようとする相手は、参加処理中
のモートとネットワーク ID が同じ親だけです。モートには正しいネットワーク ID が設定されているが、マネージャの ACL に
そのモートが登録されていない場合（このシナリオでの誤り）、モートは参加しようとしますが参加要求パケットはマネージャ
によって廃棄されます。この場合、モートはその再試行と再リセットを実行し尽すまでに数分かかります。
この方法は最も安全でネットワーク形成が促進されますが、最適な性能にするには設定時間を費やすことが必要です。各
モートには正しいネットワーク ID を設定する必要があり、各モートは現場の正しい区域に取り付ける必要があります。各マ
ネージャは正しいACLを持っている必要があります。いずれかのネットワークで代替デバイスまたは中継器が必要な場合は、
代替モートに正しいネットワーク ID を設定し、正しいマネージャに ACL 項目を与えてから新しいデバイスが参加できるよう
にする必要があります。さらに、モートが配置空間内のある場所から別の場所に移動する場合、モートは同じネットワーク ID
のエリアから離れてしまい、異なるネットワーク ID のエリアでは参加できなくなる場合があり得ます。
こうした課題を克服する機能を備える見込みです。
将来、SmartMesh WirelessHARTとSmartMesh IP の両製品ファミリは、
現在の製品ラインでは、理想的な配置ガイドラインが煩雑で従うことが困難な場合、WirelessHART および IP のファミリで
は別の方策を推奨します。
SmartMesh IP アプリケーションノート
96/140
21.4 大規模 IP ネットワーク - さまざまなネットワーク ID と共通の
参加鍵
セキュリティを最高に保つためには、 ACL と各モート固有の参加鍵を常に使用することを推奨します。ただし、現在の
SmartMesh IP マネージャはメモリが極端に制限されているので、格納できる ACL 項目は最大で 32 モートまたは 100 モー
ト（外付け RAM 使用時）に限られます。したがって、一つのマネージャの配置ではこの方法を推奨しますが、複数マネージャ
の配置では、各モートが（継続して）受信可能なマネージャが事前に分らない限り、この方法は不可能です。この場合には、
ACL を使用せず、共通の参加鍵を使用し、異なるネットワーク ID を使用してモートを複数のネットワークに分けることを推
奨します。悪意あるデバイスがネットワークに参加できないように、すべてのモートが共有しているが他者には知られること
がない専用の参加鍵の使用を引き続き推奨します。これは、配置内のどのモートもネットワークに参加できることを意味しま
す。ただし、モートが安全な共通の参加鍵を知っていることが前提です。モートがどのネットワークに参加するかは、モート
の持つネットワーク ID によって決まります。現在の SmartMesh 製品は、正しいネットワーク ID を選択する処理を簡略化した
「プロミスキャス・リスニング」と呼ばれる機能を備えています。
モートが起動した後、モートが参加を試行する前に、アプリケーションはモートをプロミスキャス・リッスン・モードに設定で
きます。このモードでは、モートはネットワーク ID に関係なく、すべての通知を受信します。モートは、受信する通知ごとに
送信元のネットワーク ID、信号強度、および送信元の深さ（ホップ数）を報告します。これにより、モートが参加を要望するネッ
トワークを自動制御で選択するための十分なデータがアプリケーションに与えられます。その後、アプリケーションはモート
のネットワーク ID を設定して、モートの通常の探索を開始します。この結果、モートはこの規定のネットワーク ID だけを参加
の対象にします。最初の起動時にモートが試行するべき望ましいネットワーク ID を使用して、アプリケーションをプログラミ
ングすることを推奨します。タイムアウト後にこのネットワーク ID からの通知が受信されない場合、アプリケーションはモー
トをプロミスキャス・リッスン・モードに設定して、代替ネットワークに参加するための情報を収集します。また、この処理で
は一定の可動性が許容されます。ネットワーク ID が異なる隣接モートを使用して移動およびリセットを行うモートは、この新
しいネットワーク ID を検出し、複数マネージャの配置内で別のネットワークに再参加できます。
ネットワーク ID 空間全体を通じてモートを均等に分けるため、各マネージャ・アプリケーションは、マネージャがモートを共
有している場合、通知をオフにすることができます。
SmartMesh IP マネージャの将来のバージョンでは、ACL 項目を増やして大規模な配置でのセキュリティを強化する予定です。
21.5 大規模 WirelessHART ネットワーク - さまざまな ID と共有
ACL
SmartMesh WirelessHART マネージャは、数千のモート MAC ID および参加鍵を ACL に保管できます。複数マネージャ
の配置を計画している場合、たとえば 1000 モートで 4 つのマネージャの場合は、各マネージャに最大 1000 モート分の ACL
および参加鍵、さらにマネージャ固有の独立したネットワーク ID が与えられます。この結果、モートは前のセクションで説明
したプロミスキャス・リッスン機能を使用して最適なネットワークに参加できます。
あるいは、複数のマネージャを配置する際に同じネットワーク ID と異なる ACL の組み合わせを使用してもかまいません。こ
の場合、各マネージャは、受け付けられるモートがどれかを知っている必要があります。この方法を使用するのが妥当なの
は、モートがあらかじめ決められたマネージャに参加することが望ましい場合だけです。たとえば、 300 のモートが 6 つの
SmartMesh WirelessHART マネージャの間で均等に分れている場合、各マネージャには異なる 50 モートの ACL が与えら
れ、最終的にどのモートがどのマネージャに制御されるかはこの ACL によって決きまることがあります。この方法だけを使
用するデメリットは、間違ったマネージャに参加しようとしているモートには、そのモートが拒否されていることが分らないと
SmartMesh IP アプリケーションノート
97/140
いうことです。このモートは、それが通知を受信した親を通じて参加要求パケットを送信します。また、このモートはその親
から適切なリンク層 ACK を受け取ります。参加側のモートは、マネージャからの応答を待っている間はネットワークとの同期
を維持しますが、参加側のモートが ACL に登録されていないので、マネージャは参加要求を廃棄します。モートがリセット
して再度参加を試みるまでには、長いタイムアウト時間がかかります。しかし、モートがいったん工場から出荷されると、モー
トに対してネットワーク ID を設定するのは簡単ではない場合があります。また、すべてのネットワークは同じネットワーク ID
を使用して稼働する必要があるので、均衡のとれたネットワークを実現するには ACL を分けることが唯一の方法です。
各ネットワークが範囲と接続性について配置のガイドラインに従うことを前提にすると、 ACL を分けるだけでは、最終的に
はすべてのモートが決められたネットワークに参加するので、少し時間がかかる場合があります。モートが元のネットワーク
の外側にある配置の新しい区域に移動する場合、新しい区域のマネージャが新しい ACL 項目でプログラムされない限り、
そのモートは再参加できません。少数のモートの可動性を有効にするため、配置内のすべてのマネージャは、これらの可動
モートを ACL に登録できます。その後、ネットワークから離れる可動デバイスは、新しい通知を受信後にリセットして新しい
ネットワークに再参加します。
SmartMesh WirelessHART モートの将来のバージョンは、大規模な配置内でさまざまなネットワーク ID を使用できるプロ
ミスキャス・リスニング機能を備える予定です。
21.6 複数マネージャの配置に関する危険
手法を決定するときに評価する必要があるポイントがいくつかあります。
すべてのモートおよびマネージャに単一のネットワーク ID を設定し、ACL をまったく分けないことも可能です。単一のネット
ワーク ID を使用した場合、モートは通知の受信対象となったネットワークがどれであっても参加しようとします。したがって、
最初に通知を開始したマネージャにモートが殺到して参加する可能性があるので、この場合は、モートがマネージャに均等
に割り当てられない危険性があります。さらに重要なのは、この人気のあるマネージャがモートの最大数または帯域幅の最
大値に到達して、他のマネージャ群の近くのすべてのモートを参加させるので、マネージャ群から離れているモートが孤立
する可能性があることです。この方法を採用する場合は、マネージャが容量の限界に達していることをアプリケーションが理
解して、適切にモートをリセットして、十分に使用されていないマネージャにそれらのモートが参加することを期待する必要
があります。
配置を工場にまかせる前に、個別のネットワーク ID および ACL を適切に使用して個々のネットワークを適切に区分し、ネッ
トワーク 1、ネットワーク 2 など別々の枠に入れることができます。ただし、モートを適切に設置するために配置時に注意が
必要です。モートを個別に配置すると、マネージャの近くのネットワーク 1 の枠からすべてのモートが選ばれる場合があり、
そのネットワークのマネージャの範囲を超えたネットワーク 2 のモートは行き場を失います。ネットワークの分散について何
らかの試みを行う場合でも、全体としての配置だけではなく、それぞれのネットワークについて個別に配置ガイドラインに従
うよう注意する必要があります。ボトルネックには特別に注意を払う必要があります。ネットワーク 1 のモートの周囲に多くの
モートが存在していても、それらがすべて他のネットワークのモートである可能性があります。この場合は、中継器を設置す
るために追跡調査の訪問が必要です。また、
これらの中継器は特定のネットワークIDで適切にプログラムする必要があります。
SmartMesh IP アプリケーションノート
98/140
ネットワークの区切りが不適当だと、上の図に示すようにボトルネックや孤立につながる恐れがあります。ここでは、緑のマ
ネージャがその近くにあるモートをすべて参加させており、黄色のマネージャと青いマネージャは、それぞれの対象モート
があまり近くにないので参加させることができません。
21.7 ネットワーク ID と参加鍵の無線による設定
アプリケーションは、マネージャから無線でネットワーク ID と参加鍵を設定できます。一部の顧客は工場でのテスト・ビルド
時に固定のネットワーク ID および参加鍵を使用し、その後、配置に備えてネットワークをパッケージ化する前に設定を固有
の値に再プログラムします。これが特に役立つのは、再プログラミングのために物理的に接続できない密封されたモート・
パッケージを持つ顧客です。新しい値はモート / マネージャのリセット後に有効になります。
SmartMesh IP アプリケーションノート
99/140
22 アプリケーションノート：SmartMesh Power and
Performance Estimator の使用
22.1 はじめに
本書では、 SmartMesh Power and Performance Estimator を使用して SmartMesh ネットワークがどのように動作する
かについて概略の結論を出すためのいくつかの方法について説明します。これらの結論の多くは必ずしも直観的ではありま
せんが、いったん理解すれば、ワイヤレスセンサ・ネットワークを SmartMesh 製品に基づいて計画する方法に関するシステ
ムレベルの決定を行うことができるようになります。以下の分析では SmartMesh IP プラットフォームを使用しますが、この
技術は SmartMesh WirelessHART ネットワークにも同様に当てはまり、同じスプレッドシートで行えます。
22.2 問題：バッテリ寿命はどれくらいか？
ワイヤレス・センサ・ネットワーク（WSN）の市場では、バッテリ寿命や電力消費が差別化の重要な要素です。SmartMesh
製品は、消費電力が最小の無線デバイスと最善のプロトコルを使用して無線デバイスのデューティ比を高くするので、バッ
テリ寿命のどのような比較でも優位に立つことができます。とは言っても、デバイスを取り付けた瞬間には、デバイスのバッ
テリ寿命がどれくらいの長さになるか分らないのが実情です。このデバイスは他のデバイスのデータのルーティングを担当
しないメッシュ内のリーフ・ノードになるのか？このデバイスは大量の負荷がかかったルータになるのか？ネットワーク内で
の再試行によってデバイスの動作頻度は高くなるか？これらの不確実性が累積した結果はどうなるのか？これはバッテリ寿
命を半減させるのか？ 5 分の 1 のなるのか？ 100 分の 1 になるのか？
22.3 Power and Performance Estimator
電力消費とバッテリ寿命に関連した不確実性の一部を取り除くために、弊社では SmartMesh Power and Performance
Estimator を開発しました。この Excel スプレッドシートを操作して、お好みのネットワーク内で動作するモートの消費電力
およびバッテリ寿命の推定値を求めることができます。SmartMesh Power and Performance Estimator は、消費電流と
バッテリ寿命を推定するための概算ツールですが、相対的な比較の感度分析を行うための優れたツールです。ここで導き出
された結論は、これらの相対的な比較に基づいています。すべての例では、デフォルト値である 3.6V 電源と室温の 25℃を
使用しています。
SmartMesh IP アプリケーションノート
100/140
22.4 Q1：報告率が電力に及ぼす影響は？
スプレッドシートによる演習：ネットワークを定義して、すべてのモートの電力が可能な最小の消費量になるポイントを見つ
けるまで、報告率を低くします。4 ホップごとに 5 モートで計 20 モートの IP ネットワークを構築します。データのペイロード・
サイズを 80 バイトで設定し、報告率を 1 パケット / 秒に設定してみます。その結果、1 ホップのモートは 441µA を消費するこ
とが判りました。公称容量が 2400mA-hr の Tadiran TL4903 のようなバッテリを使用すると、7 か月のバッテリ寿命に相当
します。子モートがない 4 ホップ目のモートのバッテリ寿命は約 3.1 年です。ここで、2 秒間隔、5 秒間隔、さらに長時間の間
隔で予測を繰り返します。結果は以下のとおりです。
データ報告率を 1 パケット / 秒から 1 パケット /2 秒に低下させた場合、消費電流はほぼ半分に削減され、バッテリの寿命は
実質的に 2 倍になりました。報告率が低い場合、これはあまり影響を与えません。センサがデータを報告する頻度が 1 分に
1 回でも 4 分に 1 回でも、消費電流はほとんど同じままです。1 秒から 30 秒までの範囲を拡大すると、次のようになります。
SmartMesh IP アプリケーションノート
101/140
すべてのデバイスの消費電流が 100µA 未満のマルチホップ・メッシュを構築するのは、非常に簡単です。100µA は、
TL4903 バッテリの場合には 2.5 年のバッテリ寿命に相当します。重要な結論は、高頻度の報告が必要な場合、バッテリ寿
命をきわめて長くするのは困難であるということです。バッテリの絶対最大寿命が必要な場合、データ報告頻度を 1 分に 1 回
より遅くするメリットはほとんどありません。結論 1：それ以上低くしても意味がない最小報告率が存在します。SmartMesh
ネットワークでは、ネットワークを介して時間同期を維持するために必要な一定の無線トラフィック量があります。センサが
まったくデータを送信しない場合、ネットワーク内のトラフィックはこの時間同期（「キープアライブ」）トラフィックによって決
まります。これにより、ネットワーク内での可能な最小消費電力の下限が設定されます。センサがデータを送信するときは、
この時間同期トラフィックを送信する必要はありません。
22.5 Q2：ルーティング・コストはどれくらいか？
スプレッドシートによる演習：上記と同じデータ設定を使用して、ルーティングのコストを示すことができます。この 4 ホップ・
メッシュでは、4 ホップ・モートがモートのデータだけを送信します。3 ホップ・モートは、モートのデータに加えて、メッシュ
内の子モートからのデータを送信します。1 ホップ・モートは、下流のすべてのトラフィックに加えて、それ自身のトラフィック
を転送する役割を果たします。データをさまざまな報告率で切ると、ルーティングのコストを示すことができます。
報告率が低い場合、ルーティング・データのコストは横ばいになります。4 ホップ・モートの消費電力は常に最小ですが、す
べてのルーティングを行うデバイスの消費電流が必ずしも数倍になるとは限りません。適度な報告率では、消費電流特性が
非常に平坦で適度に一様のバッテリ寿命を備えたネットワークを構築することが可能です。
結論 2：ルータにはある程度の負担がかかりますが、報告率がキープアライブ間隔に近づくにつれて思ったほどの大きさに
はならないことが判ります。
SmartMesh IP アプリケーションノート
102/140
22.6 Q3：リトライにかかるコストはどれくらいか？
スプレッドシートによる演習：スプレッドシートでの入力の 1 つは経路安定性です。これはパケット成功率、つまり「1 から再
試行率を引いた値」を意味します。無線のプロトコルを最適化してビット・エラーおよびパケット・エラーを減らすことが、消
費電力削減の鍵であると考える人もいます。これらのネットワークでは約 30% の再試行率は珍しくありませんが、これはバッ
テリの消耗速度が本来より30% 速いことを意味するのでしょうか？これを説明するために、20 デバイスで 4 ホップのネット
ワークの報告率を 16 秒間隔に維持して、経路安定性を変化させてみましょう。結果は以下のとおりです。
この適度な報告率では、パケット成功率が高いと消費電力が減少するのが事実です。パケット成功率が 40% であれば、消
費電流は 2.5 倍になり、バッテリの寿命は半分に満たなくなると思うかもしれませんが、実際はそうではありません。必要な
再試行回数が少ないほど強力な無線経路が存在する方が望ましいことは確かですが、リトライの実行がバッテリ寿命にとっ
て致命的であると考える必要はありません。SmartMesh マネージャは、経路安定性とホップ数の間のトレードオフを理解し、
それに応じて最適化します。経路安定性が高い親よりAP に近い親を選択した方が良い場合があります。こうするとネットワー
ク内での全再試行数は増加する可能性がありますが、各パケットが宛先に到達するために経由するホップ数は少なくて済み
ます。
40% より低いパケット成功率のネットワークが十分に機能するということはありません。非常に低いパケット成功率では、経
路が完全に失敗する境界にあることが分ります。この場合の問題は、メッシュからデバイスが完全に失われることです。
結論 3：リトライ率は重要ですが、思ったほどの影響は与えません。
SmartMesh IP アプリケーションノート
103/140
22.7 Q4：パケット集約で電力を節減できるか？
スプレッドシートによる演習：同じ 20 モート、4 ホップの深いネットワークで、1 回の報告間隔を 20 秒に選択し、ペイロード・
サイズを 5 バイト∼ 80 バイトの範囲で変化させます。結果は以下のとおりです。
より大きなデータ・ペイロードを送信すると消費電力が増加するのは確かですが、90 バイトのペイロード中のデータを 18
倍送信しても消費電流の増加は約 10% に過ぎません。これを別の見方でとらえるため、すべてのセンサが 1 分に 80 バイト
を送信する場合を考えます。あるセンサ・アプリケーションは、80 バイトのペイロードを 1 分に 1 回送信します。別のセンサ・
アプリケーションは、2 つの 40 バイト・ペイロードを 30 秒に 1 回送信します。3 番目のセンサ・アプリケーションは 20 バイト
のペイロードを 15 秒ごとに送信し、4 番目のセンサ・アプリケーションは 10 バイトのペイロードを 7.5 秒ごとに送信します。
5 番目のセンサ・アプリケーションは 5 バイトのペイロードを 3.75 秒ごとに送信します。6 番目のセンサ・アプリケーションは
2 バイトのペイロードを 1.5 秒ごとに送信します。結果は以下のとおりです。
SmartMesh IP アプリケーションノート
104/140
上記のすべてのアプリケーションは、完全に同じセンサ・スループットで送信しています。より大きなサイズのペイロードを
低い頻度で送信する方がはるかに効率的なデータ転送を行います。トレードオフはもちろん待ち時間です。新しい読み値が
あれば、古いデータは必要がないアプリケーションもありますが、データの履歴から重要な情報を得られるアプリケーション
もあります。空いているペイロード容量をアプリケーションが効率的に使用できる場合は、消費電力とバッテリ寿命に関して
4 倍もの利益を得ることができます。
結論 4：小さなペイロードの送信回数を増やすよりも、大きなペイロードを少ない回数で送信するほうが効率的です。また、
すべてのパケットには固定のオーバヘッドがあるので、大きなペイロードを送信しても、小さなペイロードの送信より大幅に
時間がかかることはありません。
22.8 Q5：ネットワークの深さが電力に及ぼす影響は？
スプレッドシートによる演習：この同じ 4 ホップ・メッシュを再検討しますが、今度は 1 ホップ・モートの数を変化させます。ホッ
プ 2 ∼ 4 は 12 モートのセンサ・クラスタとみなし、1 ホップ・モートは、センサからゲートウェイまでのギャップを埋めるため
に顧客が仕方なく購入している単なる中継器であるとみなします。すべてのセンサが 15 秒に 1 回 80 バイトのペイロードを
送信します。1 つの 1 ホップ・モートから始めて、1 ホップ・モートが 10 個になるまでモートを追加し続けます。ワーストケー
スの消費電力を 1 ホップ・モートの関数としてグラフ化します。結果は以下のとおりです。
多くのシステムでは、
「バッテリ寿命」の概念は、バッテリの消耗によって見えなくなるセンサが初めて出た瞬間を意味します。
そのときには、すべてのバッテリを交換します。1 ホップのリングはすべてのトラフィックを転送する必要があるので、最初に
駄目になるバッテリが 1 ホップのリングの中にあることはほぼ確実です。この期間を長くする最も簡単な方法は、 1 ホップ・
デバイスの数を増やすことです。この効果に加えて、多くの 1 ホップ・デバイスを備えておくと、失われたデバイスに対する
耐性が高くなります。ネットワークに 2 つの 1 ホップ・デバイスしか存在せず、1 つが取り除かれると、その最終ホップにはも
はや良質なメッシュが存在するとはいえません。信頼性が低下する可能性があります。
一般的に、トラフィックはマネージャに向かうすべてのホップ・レベルで増加します。各ホップ・レベルでは、そのホップ・
レベルのモートがそれら固有のトラフィックを転送するのに加えて、子孫モートからのトラフィックをすべて転送しています。
ゲートウェイに近い個々のホップ・レベルでは、消費電流の点からせいぜい出来ることは、そのホップ・レベルにあるすべて
のデバイスが均等に作業を分担することです。該当のホップ・レベルにあるデバイス数を増やすほど、分担作業量が小さく
なり、これらのデバイスのいずれか 1 つが離脱した場合の問題も小さくなります。
結論 5：できるだけ多くの 1 ホップ・モートを使用してください。任意のホップのリングに流れる電流は、そのホップのリング
にあるモートの数に反比例します。
SmartMesh IP アプリケーションノート
105/140
22.9 Q6：IP ネットワークでの通知を停止して電力を節減？
スプレッドシートによる演習：通知をするためには電力消費が必要であることに注意してください。IP ネットワークでは、デ
フォルトで通知はオンになっています。省電力化が望ましい場合は、アプリケーションが通知をオフにする必要があります。
ただし、注意が必要です。通知がオフになっている間、新しいモートは参加することができません。したがって、
アプリケーショ
ンによって通知をオフにする場合は、オンに戻すための仕組みが必要です。たとえば、ネットワークを形成する場合、通知を
オフにして、あるモートの電源を切ってから再度投入すると、通知をオンに戻さない限り、そのモートが再参加することはあ
りません。モートが離脱するたびにアプリケーションが自動的に通知をオンにすれば、問題はありません。また、アプリケー
ションが通知をオンにするユーザー・インタフェースを備えている場合、ユーザーは新規デバイスの追加も容易に行うことが
できます。アプリケーション開発者が注意深ければ、通知を実質的に常時オフにすることができます。これは、モートごとに
13.8µA の節約に相当します。30 秒間隔で更新する 4 ホップ、20 モートのネットワークを見直してみると、以下の電力曲線が
得られます。
31µA が 17.2µA に減少することにより、リーフ・ノードのバッテリ寿命は、Tadiran の単 3 電池（2160mA-hr）の場合で 14.5
年にすることが可能です。結論 6：不要な時に通知をオフにすることには価値があります。ただし、これには注意が必要です。
SmartMesh IP アプリケーションノート
106/140
23 アプリケーションノート：移動するモートに予想されること
23.1 1 モートの移動
現在の SmartMesh 製品では、その親の範囲を越えて移動するモートは、リセットして新しい親でネットワークに再参加する
必要があります。同様に、既存のネットワークの無線範囲内に到達する新しいモートがデータを送受信できるようになるに
は、その前にそのネットワークに参加する必要があります。これらの条件での正確な動作は、どの製品が使用されているか
によって異なります。
ネットワークの周囲を絶え間なく移動し、1 つの無線範囲を超えて移動するモートは好ましくありません。
23.2 SmartMesh WirelessHART
SmartMesh WirelessHART では、ネットワークがいったん構築段階から定常状態段階に移行すると、エネルギーを節約す
るためにモートでの通知が減少します。通知タイマは、モート上では 1.28 秒から 20 秒に長くなります。これは、定常状態時
にモートのアドバタイザの範囲内だけに現われるモートは、同期をとるのに構築段階時よりも約 16 倍長くかかることを意味
します。AP 通知の間隔は 0.16 秒から変わらないので、AP の範囲内に現われる新しいモートの参加動作は、2 つの状態の
いずれでも変わりません。アプリケーションは、新しいモートが追加されることを知っている場合、 API を使用して通知の頻
度を再度高くすることもできます。
移動するモートが既にネットワーク内にある場合、モートにリセットがかかるには、そのモートの二つの親への経路が失われ
ている必要があります。WirelessHART 標準での経路アラーム・タイマは 4 分です。また、こうした経路アラームを受け取る
ことが、モートが親経路を削除するきっかけになります。そのため、移動後のモートがリセットするまでには 4 分より少し長く
かかる可能性があります。いったんモートがリセットすると、マネージャはモートの以前の下りリンクによってモートに到達し
ようとします。いったんこの状態マシンがタイムアウトすると、それは最大 15 分に達することがあるので、離脱したモートを
探索するために残りのモートでは通知が自動的に加速されます。その一方で、モートがその新しい場所で通知を受信した場
合は、モートが離脱していることをマネージャが検出する前に、モートはネットワークに再参加できます。高速通知の期間中、
新しいモートの構築時または探索時に、Eterna モートは余分に 16 µA を消費し、DN2510 ベースのモートは余分に 30µA を
消費します。
参加までの予想時間の詳細については、
「SmartMesh WirelessHART User s Guide」の「Network Formation」セクショ
ンを参照してください。
23.3 SmartMesh IP
SmartMesh IP では、アプリケーションが API を介して通知の動作を明示的に停止しない限り、通知の周期同じに維持され
ます。SmartMesh IP の各フレームの長さは約 2 秒です。モートの通知頻度は 1 フレームにつき 1 回であり、 AP の通知頻度
は 1 フレームにつき 4 回です。通知を停止した場合、通知を行うモートはなくなります。つまり、新しいモートは参加できず、
モートはネットワークに再参加できません。エネルギーの節約が不可欠で、マネージャの介在なしで通知を制御するのに十
分なノウハウをアプリケーションが備えている場合に限り、通知を停止することを推奨します。通知を停止すると、Eterna モー
トでは 14µA 節約できます。
SmartMesh IP アプリケーションノート
107/140
移動するモートが既にネットワーク内にある場合、モートにリセットがかかるには、そのモートの二つの親への経路が失われ
ている必要があります。SmartMesh IP での経路アラーム・タイマは 1 分です。また、こうした経路アラームを受け取ること
が、モートが親経路を削除するきっかけになります。そのため、移動後のモートがリセットするまでには 1 分より少し長くか
かると予想されます。下りの照会を持つモートにマネージャが到達できないと、そのモートは離脱とマークされますが、通知
の自動変更は行われません。その間に、移動したモートは、新しい通知を受信した場合は必ず、自由に再参加できます。
参加までの予想時間の詳細については、
「SmartMesh IP ユーザー・ガイド」の「ネットワーク形成」セクションを参照してく
ださい。
23.4 SmartMesh WirelessHART と SmartMesh IP との違いの
まとめ
この単純な比較では、80% の経路安定性と 5% のジョイン・デューティ・サイクルを想定しています。
パラメータ
WH
IP
リセットまでの時間
4分
1分
通知頻度を高めるまでの時間
15 分
非該当
定常状態の平均同期時間（1 ホップ）
60 秒
188 秒 *
定常状態の平均同期時間（マルチホップ、3 つの隣接モート）
42 分
250 秒 *
* SmartMesh IP のアプリケーションによって通知が明示的にオフになった場合、モートは同期できず、ネットワークに参加
できません。
SmartMesh IP アプリケーションノート
108/140
24 アプリケーションノート：ネットワーク間でのモートの移行
24.1 モートの移行
多くのユーザーは、ネットワークに加えるモートの数をネットワークの存続期間にわたって徐々に増やします。あるネットワー
ク・サイズで、マネージャがモート数または帯域幅の限界に達する場合があるので、いくつかのモートを新しいネットワーク
に移動することが必要になる場合があります。本書では、顧客のアプリケーションがモートの機能を使用してこの処理を自動
的に管理する方法について説明します。これについては SmartMesh IP ネットワークのコンテキストで説明しますが、その
手順は SmartMesh WirelessHART ネットワークにも同様に当てはまります。
24.2 手順
ネットワークを石油採掘場に配置したとします。新しい坑井が掘削されるにつれて、モートが追加されていきます。次に示す
図では、ネットワーク A が容量の上限に近づいており、 2 番目のマネージャがネットワーク B を形成するために最新の採油
所の近くに配置されます。最初はネットワーク B にわずか数モート（灰色の菱形）しかないので、ネットワーク A から数モート
（白い菱形）を移動することが望まれます。ネットワーク A とネットワーク B のネットワーク ID は異なります。
ネットワーク A
ネットワーク B
図 1 - ネットワーク A からネットワーク B へのモートの移動
このためには、探索 API を使用します。これにより、モートは、近辺にあるどのネットワークからの通知の受信も待機して、受
信した通知の送信元ネットワークを報告するモードに入ります。
1. モートにはネットワーク ID が事前に設定されます。これを「優先」ID と呼びます。これはモートの使用を開始する場
合の通常の手順で、モートがその後移動すると予想されるかどうかは関係ありません。
2. センサ・アプリケーションは探索 API を使用して、受信した通知に関する情報の報告をモートに求めます。モート
ID、ネットワーク ID、および信号レベル（RSSI）が報告されます。これらの情報はセンサ・アプリケーションによって
保管されます。
SmartMesh IP アプリケーションノート
109/140
3. センサ・アプリケーションは探索のタイムアウトを設定します。具体的には、joinDutyCycle パラメータにより設定
されます。10% のデューティ・サイクルでは、タイムアウトは 2 ∼ 3 分です。与えられたデューティ・サイクルでの探
索が長いほど、近辺にあるすべてのネットワークを検出する確率は高くなりますが、この処理で消費されるエネル
ギーも高くなります。
4. タイムアウト時に、優先ネットワーク（モートの現在のネットワーク ID）が十分な RSSI（>-85dBm）で受信できてい
る場合、センサ・アプリケーションは join コマンドを出します。優先 ID が十分な RSSI で受信できない場合、センサ・
アプリケーションは十分な RSSI を持つ別の検出済みネットワークを選択し、networkId パラメータをそのネットワー
クに設定して、join コマンドを発行する必要があります。
5. モートが優先 ID に数回参加しようとしても成功しない場合は、モートに適切な資格（後述の「セキュリティ」を参照）
がない可能性があります。また、センサ・アプリケーションは探索処理を再開する一方で、モートが参加できないこ
のネットワークを「ブラックリストに登録」する必要があります。
一般に、この方法を使うと、モートは、モートが備える適切なセキュリティ資格に合う利用可能なすべてのネットワークに参
加できます。探索 API は、顧客のセンサ・アプリケーションにおける参加ロジックの通常処理として、あるいは顧客のアプリ
ケーション・メッセージに応じて行うことができます。上記のネットワーク A および B の場合には、ホスト側の顧客アプリケー
ションが白い菱形のモートの優先ネットワーク ID を B に変更した後、対象のモートをリセットします。その後、これらのモー
トは上記の手順に従ってネットワーク B に参加しようとしますが、実際にネットワーク B の範囲内に存在しない場合、ネット
ワーク A に安全に戻ることができます。
24.3 セキュリティ
モートは通知の受信に加えて、マネージャが使用するものと同じ参加鍵を持っている必要があります。望ましいやり方は、モー
トごとに固有の参加鍵を持たせて、その参加鍵をマネージャのアクセス制御リスト（ACL）に登録することです。ネットワーク
に参加できるのは、マネージャの ACL に登録されているモートだけです。ネットワーク A および B の場合には、ネットワーク
A から移動した白のモートをネットワーク B の ACL に追加してからリセットする必要があります。
SmartMesh IP ネットワークでは、マネージャができるのは ACL 項目を maxMotes 個（マネージャによって 32 または 100
に変化）格納することだけです。3 つの重複ネットワーク A、B、および C の例を調べます。理論上、このシステムは合計で
maxMotes の 3 倍の数のモートをサポートします。しかし、モートを 1 つ配置し、そのモートを 3 つのマネージャのうちいず
れか 1 つに参加させる場合、そのモートを 3 つすべての ACL に登録しておく必要があります。maxMotes+1 個のモートを追
加したい場合、すべての ACL が満杯なので追加できません。
1 つの解決策は、動作状態のモートが 1 つのネットワーク内で安定的に動作していて、後で別のネットワークに参加させる必
要はないという仮定の基、そのモートが属していないマネージャの ACL から該当のモートを削除する方法です。もう 1 つの
（秘密
オプションは、ACL を使用せずにすべてのネットワークにわたって共通の参加鍵を使用する方法です。この方法では、
の）共通鍵が攻撃者に知られてしまった場合に、攻撃者がモートを参加させることができるので、安全性が低下します。
SmartMesh IP アプリケーションノート
110/140
25 アプリケーションノート：境界内データ待ち時間に関する
ネットワークの構成
25.1 プロビジョニングの増加
デフォルトの設定では、SmartMesh ネットワークは低消費電力で高信頼性動作を行うように設計されています。安定性の平
均値が 70% を超え、4 ホップ以下の標準的なネットワークでは、デフォルトの設定で、パケットの約 90% が 1 回の報告間隔
内に配信されることが分っています。たとえば、モートがモートのセンサから 10 秒ごとに 1 パケットをそれぞれ配信している
ネットワークでは、これらのパケットの 90% では 10 秒以下の待ち時間になると想定されます。プロビジョニング係数と呼ば
れる設定を調整することにより、ネットワーク内で使用される電力を増やし、より高い割合のパケットを所定の目標待ち時間
より短時間で配信できます。
本書では、アプリケーションノート「プロビジョニング係数の変更によるマネージャ・スループットの増加」での説明内容と反
対のことを行います。
25.2 制限事項
このアプリケーションノートで説明する設定は、センサがほぼ同じ頻度で報告するネットワークに対して適用します。たとえ
ば、あるモートのセンサが 1 秒間隔で報告し、それ以外のすべてのモートが 30 秒間隔で報告するネットワークでは、ここで
の設定が必ずしも機能するとは限りません。そういったケースの場合は、上りバックボーンを使用してください。IP ネットワー
クの場合は、
アプリケーションノート
「通電バックボーンを使用した待ち時間の改善」を参照してください。WirelessHARTネッ
トワークの場合、この機能は将来のリリースで使用できるようになる予定です。
安定性の平均値が低い（70% 未満の）ネットワークでは、待ち時間が長くなります。これらの場合には、本書での推奨設定
値よりさらに高いプロビジョニング係数が必要です。最後に、本書での設定が当てはまるのは 4 ホップ以下のネットワークで
す。さらに深いネットワークの待ち時間はほぼ直線的に増加するので、たとえば 8 ホップのネットワークは、本書で説明した
プロビジョニング・レベルを 2 倍にすることにより、同じ待ち時間目標値を満たします。
25.3 プロビジョニング
すべての SmartMesh ネットワークでのデフォルトのプロビジョニングは 3 倍です。これは、すべてのモートには、予想され
るパケット伝送ごとに 3 つ以上の上りリンクがあることを意味します。このレベルのプロビジョニングにすると、低消費電力（リ
ンク数を減らして実現）および高い信頼性（リンク数を増やして実現）の正しいバランスをネットワーク全体に対して達成で
きることが経験的に分っています。したがって、あるモートがローカル生成パケットと転送パケットの両方を含むパケットを
1 秒に 1 回送信している場合、このモートには 1 秒当たり3 つの送信リンクが与えられます。
SmartMesh IP アプリケーションノート
111/140
25.4 プロビジョニングの変更
経験則として、 3 倍のプロビジョニングでは、パケットの 90% がマネージャに「時間どおりに」到達します。これは、 10 秒間
隔で報告するモートのパケットの 90% は、その待ち時間が 10 秒未満であり、7 秒間隔で報告するモートのパケットの 90% は、
その待ち時間が 7 秒未満であることを意味します。すべての顧客が時間どおりのパケット配信を望むとは限らないことに注意
してください。多くの場合、その目的は、合理的で厳しくない目標の期間内に、生成されたすべてのパケットをとにかく配信
することです。
時間どおりの配信率を 99% まで高めるには、プロビジョニングを 6 倍に変更します。
• SmartMesh WirelessHART：dcc.ini に TOP_LINK_OVRSUBSCR = 6.0 の 1 行を追加
• SmartMesh IP：マネージャ CLI で、set config bwmult 600 と入力
この変更を行うと、ネットワークの全スループット（単位：パケット / 秒）が半分になることに注意してください。デフォルトの
設定で 25 パケット / 秒をサポートできるネットワークは、 6 倍のプロビジョニングでは 12.5 パケット / 秒しかサポートできま
せん。
時間どおりの配信率を 99.9% まで高めるには、プロビジョニングを 9 倍に変更します。
• SmartMesh WirelessHART：dcc.ini に TOP_LINK_OVRSUBSCR = 9.0 の 1 行を追加
• SmartMesh IP：マネージャ CLI で、set config bwmult 900 と入力
デフォルトの設定で 25 パケット / 秒をサポートできるネットワークは、6 倍のプロビジョニングでは 8.3 パケット / 秒しかサポー
トできません。
25.5 電力の増加
プロビジョニングを追加してもネットワーク内での送信パケット数は多くなりません。同じパケット数を送信するためのリンク
の数が増えるだけです。追加の送信リンクは電力を消費しないので、プロビジョニングが変更された場合、リーフ・ノードの
電源要件が追加されることはありません。使用中のルータ・ノードは、いくつかの受信リンクを追加して追加された送信リン
クと組み合わせるので、これらのノードが最も影響を受けます。この場合もやはり、経験則として、使用中のルータの消費電
力は、プロビジョニングを 6 倍に増やすと 10 ∼ 15% 増加し、プロビジョニングを 9 倍に増やすと 20 ∼ 30% 増加します。
低トラフィックのネットワーク（例：報告間隔が 60 秒）の場合は、プロビジョニングを 9 倍に増やしても、ネットワーク内のリ
ンク数やモートの消費電力が実際には増加しない場合があります。こうした場合には、リンクの最小数が、時間どおりの配信
率 99.9% を保証するのに既に十分な値になっています。
SmartMesh IP アプリケーションノート
112/140
26 アプリケーションノート：ネットワークの共存
26.1 重複ネットワーク
すべての SmartMesh ネットワークは、2.4GHz の産業、科学、医療（ISM）無免許無線バンドで動作します。ここで言う無免
許とは、現地での電力制限に従えば、この帯域（バンド）で誰でも自由に動作させることができ、テレビや携帯電話の帯域で
は必要になる免許が不要という意味です。この帯域が選ばれたのは、この帯域が世界中で利用可能であり、IEEE 802.15.4
PHY 標準無線規格が存在することが理由です。したがって、多くの相互運用可能な無線機が市販されています。
しかし、誰もがこの帯域を使用できるので、他の製品で混雑しています。802.15.4 b/g/n Wi-Fi、Bluetooth、コードレス電
話機、ZigBee は、すべて同じ帯域で動作します。実際の配置では、時刻 T0 でチャネル X に存在する干渉、またはマルチパス・
フェージング環境が、時刻 T1 ではチャネル Y に存在しないという考えのもとに、SmartMesh ネットワークは、チャネル・ホッ
ピングにより潜在的な干渉を回避して送信する余裕をもって設計されています。すべてのチャネルにわたる平均的な性能に
頼ることにより、いずれか 1 つのチャネルがうまくいくことに頼るより結果は良好になります。他のプロトコルは 1 チャネル（ま
たは数組のチャネル）に留まるか、帯域全体を素早く飛び越える（Bluetooth）ので、近辺にある他の SmartMesh ネットワー
クが最も有害な干渉物になる可能性があります。非同期ネットワークが共通のスケジュールを共有する場合は衝突が続く可
能性があるからです。本書では、重複ネットワークによる干渉を克服するために実現された機能について説明します。
26.2 単一ネットワークでの衝突
SmartMesh マネージャは、同一ネットワーク内の伝送同志の衝突を防止するためにスケジュールを作成します。この規則
の例外は、三ケ所にある「共有」リンクです。共有リンクは、参加するモートが参加先の親と連絡をとるために使用します。
最悪の場合には、モートがネットワーク内で稼働する前に、この時間中の衝突によってモートはリセット状態になります。
SmartMesh IP では、通電バックボーンは共有リンクを使用して待ち時間を短縮します。これらのネットワークには、データ
要件をすべて満たすのに十分な専用（つまり、非共有の）帯域幅が引き続き存在するので、衝突による影響はごくわずかで
す。SmartMesh WirelessHART ネットワークでは、モートはリンクを共有してネットワーク検出パケットを送信します。マネー
ジャはこれらのパケットの衝突確率を低くするのに十分な長さをタイマに割り当てます。パケットが衝突した場合でも、検出
情報は後で安全に収集されます。
通常のネットワーク・トラフィックは専用のチャネル・オフセット上に予定されるので、上記の特定の衝突は、これらのトラ
フィックと衝突することはありません。また、単一ネットワーク内の同じチャネル上で同時に 2 つの伝送が実行されることもあ
りません。
26.3 周期的な衝突の回避
2 つのネットワークが同じ無線空間内にあり、両ネットワークとも以下の性質を持っているとします。
• 現在の絶対スロット番号（ASN）が同じ
• チャネル・リスト（例：デフォルトのチャネルのブラックリスト）が同じ
• すべてのスロットフレームの長さが同じ
• 同じタイムスロットのトランザクションのオフセットが同じ
SmartMesh IP アプリケーションノート
113/140
この場合、ネットワークは両方とも同じチャネル周波数で同時に送信するので、両方のメッセージが互いに干渉し、結果とし
てどちらも正常に転送されない可能性があります。該当するパケットは後で再試行される必要があります。ちょうど 1 スロット
フレーム後に同じシナリオが繰り返され、これが繰り返され続けます。重要なことは、ネットワークが両方とも同じ周期で動
作しているので、1 回発生した衝突は継続的に発生する可能性が高いということです。
ネットワークは、同じチャネル・ホッピング・パターンに従う場合、必ずしも ASN を一致させて互いに干渉させるまでもあり
ません。明示的に同期されないネットワークは、結局ドリフトします。また、いくつかの衝突が重複する期間があることが分
ります。これらの期間は、相対的なドリフトによってタイムスロットの長さが経過するまでに要する時間を表しますが、数分
から数時間続くことがあります。モートへの伝送が重複ネットワーク内での伝送パターンとすべて一致する場合、このモート
はその親と十分長い時間通信することができずに終わり、通信が途切れてリセットする可能性があります。伝送が時折成功
すれば、モートはネットワーク内にとどまります。モートが離脱するのは、すべてのデータ・パケットおよびキープアライブ・
パケットが常に失敗するときだけです。
2 つのネットワーク間で重複する量は非常に少量です。各ネットワークは単一のアクセス・ポイント（AP）ノードによってデー
タを収集します。また、各 AP が受信または送信できるのは、各タイムスロット内の 1 チャネル上に限られます。SmartMesh
ネットワークで利用可能な 15 チャネルと比較した場合、ネットワーク内で最も混雑した場所での実際の伝送が、最大でタイ
タイムスロットの全長がこの伝送で満たされることはないので、
ムスロット全体の 1/15 に収まることが期待されます。さらに、
全帯域幅に占める割合はさらに低くなります。このことは、周期的かつ継続的な衝突を回避できる場合には、モートが同じ
無線空間で安全に共存する余地が十分あることを示しています。衝突が発生するが、発生頻度が一定ではなく不規則である
場合、これは両方のネットワーク内の経路安定性の全体的な減少として現れ、重大な問題が発生することはありません。
SmartMesh ネットワークは、IP 製品群と WirelessHART 製品群とでは、周期的な衝突を別の方法で回避します。
26.3.1 SmartMesh WirelessHART
各 SmartMesh WirelessHART ネットワークには、固定長の同じスロットフレームがあります。上りスロットフレームは 1024
スロット、下りスロットフレームは 256 スロットであり、通知スロットフレームは 128 スロットです。これらのスロットフレーム
長は変更できないので、周期性を回避するために異なる仕組みが必要です。
上りの通信は、各モートに最低 4 つの送信リンクを与えることによってランダム化されます。これらのリンクのオフセットは完
全にランダムに選ばれ、選ばれたタイムスロットには上りリンクごとに若干のジッタがあります。したがって、ネットワーク A
からの 4 つのリンクのいずれかがネットワーク B と衝突する確率は、153 分の 1 未満、つまり1：3375。
下りの通信をランダム化するには、ブロードキャストとマルチキャストの両方のリンクを AP に与え、モートごとに 2 つの送信
元経路を使用します。下流のモートに達する最初の試みが失敗した場合は、異なるタイムスロットおよび比較的不規則なタ
イムスロット上の最初のホップ伝送により再試行されます。また、マルチホップ経路に沿った後続の各伝送に対しても同じこ
とが適用されます。
通知とネットワーク検出の伝送は、割り当てられたスロットごとにではなく、タイマを基準にして行われます。これは、これら
の伝送が完全な周期性では決して行われず、隣接するネットワーク内で持続的な問題が発生しないことを意味します。
SmartMesh IP アプリケーションノート
114/140
26.3.2 SmartMesh IP
SmartMesh IP ネットワーク・マネージャはメモリに制約があるので、各モートにいくつかのリンクを割り当てることができ
ません。この制限を乗り越えるため、短いスロットフレームに少ないリンク数を割り当てますが、こうすると衝突が継続的に
発生する確率が高くなります。ただし、IP ネットワークの基本のスロットフレーム長は 1 種類なので、これはランダム化する
のが簡単です。ネットワークの起動時に、マネージャは上流、下流、および通知のすべての動作で使用するスロットフレーム
長を 256 ∼ 284 タイムスロットの範囲でランダムに選択します。
IP ネットワークでは、上りリンクのデフォルトの最小数は 2 です。ネットワーク内にあまり多くのモートがなく、消費電力が大
（初期）設定でこのパラメータの値を大きくして、持続的な衝突に対する耐性を高めることが
きな問題ではない場合は、
「ini」
できます。
下りの通信をランダム化するには、ブロードキャストとマルチキャストの両方のリンクを AP に与え、モートの宛先ごとに 2 つ
の送信元経路を使用します。下流のモートに達する最初の試みが失敗した場合は、異なるタイムスロットおよび比較的不規
則なタイムスロット上の最初のホップ伝送により再試行されます。また、マルチホップ経路に沿った後続の各伝送に対して
も同じことが適用されます。
26.3.3 WirelessHART の混在環境
IP ソリューションとWirelessHART ソリューションは、それぞれ異なるタイムスロット長（7.25ms および 10ms）で動作します。
このことだけで、両者を同じ無線空間で動作させても安全であり、両者間に継続的な衝突が生じる恐れはありません。
26.4 クリア・チャネル評価
すべての SmartMesh 製品はオプションのクリア・チャネル評価（CCA）機能を備えています。この機能を有効化すると、ネッ
トワーク内のすべてのデバイスは伝送前の短期間に受信するようになり、別のデバイスの伝送を偶然受信した場合は、予定
していた伝送を中止します。これは隣接する非同期ネットワークの共存を目的としています。前述したように、ネットワーク内
では衝突を回避しているので、これは効果がありません。CCA の使用はデフォルトではオフです。IEEE 802.15.4 で定義さ
れているように、送信を中止するためのしきい値は低いので、正常に動作できるネットワークは、強度が中程度の広帯域干
渉によって完全に遮断される場合があります。隣接する別の 802.15.4 ネットワーク運用者から依頼があり、さらに彼らが共
存の問題を経験している場合にのみ、CCA の使用を検討することを推奨します。
26.5 実験結果
弊社のテスト研究所では、絶え間なく動作する約 900 のモートを備えた SmartMesh ネットワークが日常的に約 40 あります。
ピーク・トラフィックの時間帯に、弊社ビル内で利用可能な各チャネルで 20 パケット / 秒以上を取り込みました。この環境は
顧客の配置が直面するどんなところよりも難易度が高いと考えられますが、衝突が原因でモートがリセットされることはめっ
たにありません。
弊社では、弊社の小さな研究所で動作する 1000 のモートを 8x125 モートの WirelessHART ネットワークに分割して専用の
テストを実行しました。このネットワークでのピーク時の総トラフィックは 181 パケット / 秒で、ネットワークは 99.9% より高
い信頼性を維持していました。モートが同期を維持していたがデータを送信しなかった低トラフィック設定と比較すると、経
路安定性は 80% から 68% に低下しました。全体的に見て、ネットワークの待ち時間と消費電力は増加しましたが、深刻な
問題にはなりませんでした。
SmartMesh IP アプリケーションノート
115/140
27 アプリケーションノート：ジョイン・デューティ・サイクルの
選択方法
本書では、モートのジョイン・デューティ・サイクルをどのように決めたら良いのかについて段階的に説明します。この決定は、
通常、モートとやりとりするセンサ・アプリケーション側で行われます。
27.1 背景 - ジョイン・デューティ・サイクルとは？
モートの join API コマンドを送信すると、モートは参加できるネットワークを探索し始めます。探索とは、モートが 1 チャネ
ル上でしばらくの間受信し、次にしばらくの間スリープ状態になった後、別のチャネル上で受信を再開することを意味します。
全期間（受信時間 + スリープ時間）の長さは 3 ∼ 4 秒です（SmartMesh ファミリにより異なります）。ジョイン・デューティ・
サイクルは、 0 ∼ 255 の範囲内のいずれかの値に設定できる 1 バイトのフィールドで、この期間のどの部分を受信に費や
すかを設定できます。モートが受信する時間の割合が大きいほど、そのモートが通知を受信してネットワークに参加する速
度は速くなりますが、消費電流の平均値は大きくなります。たとえば、モートの探索デューティ・サイクルを 255 に設定する
と、モートは常に受信し、数秒ごとにチャネルを変更します。ジョイン・デューティ・サイクルを 26 に設定すると、モートは約
10%（26/255）の時間を受信に費やし、約 90% の時間をスリープ状態に費やします。こうすると消費電力は非常に少なくな
りますが、通知の受信速度も大幅に低下します。したがって、ジョイン・デューティ・サイクルの設定は、平均電力と探索に
費やす時間のトレードオフをもたらします。モートがネットワークに同期する期待時間は、ジョイン・デューティ・サイクルと
ネットワーク・トポロジ（通知を送信している隣接モートの数および送信率を介して表現）によって決まってきます。
/
* 経路安定性 * 受信モートのジョイン・デュー
同期時間 = デバイス当たりの通知送信率 * チャネル数 （通知送信デバイス数
ティ・サイクル）
SmartMesh スタータ・キット（DC9000 および DC9007）では、モートはマスタ・モードで動作します。モートはひとりでに
参加し、外部プロセッサからのコマンドは必要ありません。このモードは、通常はデモンストレーション用に使用されます。
対照的に、最も現実的なアプリケーションはモートをスレーブ・モードで動作させます。このモードでは、モートが参加する
ようモートに指示する必要があります。join コマンドとともに、探索に使用するデューティ・サイクルをモートに指示する必要
があります。本書では、いくつかのネットワーク・シナリオでの「十分に速い」ネットワーク形成時間と平均電力のトレードオ
フについて明確に説明します。SmartMesh WirelessHART では、リセットした場合や電源を入れ直した場合、モートはデ
フォルトに戻るので、デフォルト値以外の値が望ましい場合は、起動のたびに設定する必要があります。SmartMesh IP では、
ジョイン・デューティ・サイクルはリセットや電源の入れ直しがあっても維持されるので、設定する必要があるのは 1 回だけ
です。
27.2 使用すべきジョイン・デューティ・サイクルは？
ジョイン・デューティ・サイクルを設定する一般的な方法は 4 つあります。
1. 通電デバイスの場合：単純に 100% に設定します。この設定の利点は、参加までの時間が常に最短であることです。
隣接モートを検出できない場所にモートを置くと、そのデバイスは探索に約 5mA を消費しますが、通知を受信する
ことはありません。
SmartMesh IP アプリケーションノート
116/140
2. エナジー・ハーベスティングの場合：余裕のある電力レベルに設定します。エナジー・ハーベスティングが保証でき
る電流の大きさは限られています。その大きさに適合する探索デューティ・サイクルを設定します。たとえば、連続
して 200µA 供給できるエナジー・ハーベスティングをモートが備えており、モートが受信時に 5mA を消費する場合
は、探索デューティ・サイクルを 10（10/255 = 4%）以下に設定する必要があることが分っています。モートの参加
速度はデューティ・サイクルが高い場合より低下しますが、モートは探索の必要がある限り、予想電力量より低い値
にとどまります。
3. バッテリ寿命の目標値と一致するように設定します。デバイスに厳密なバッテリ寿命の目標値がある場合、このデ
バイスには規定の平均予想電流量が存在し、上記 2 の場合のようにジョイン・デューティ・サイクルを計算できます。
たとえば、2000mAhr のバッテリがあり、目標の寿命が 10,000 時間である場合は、200µA を流す余裕があります。
このように、デバイスはそれがネットワーク内にあるかどうかに関係なく、バッテリ寿命の目標値を満たします。こ
れは、
「孤立した」位置に残されることがよくあるが、ネットワークが存在するようになったら必ず参加することが必
要なデバイスに対する方法でもあります。
4. 速度と電力の点で「十分な」値を選ぶようにします。実際に試してみると、密集したネットワーク（ほとんどのモート
が 8 つ以上の隣接モートを検出可能なネットワーク）を完全に形成するための総所要時間は、ジョイン・デューティ・
サイクルとほとんど関係ないことが分ります。100 モートのネットワークを形成するのに探索デューティ・サイクル
が 100% のとき 30 分かかる場合、50% でもわずか 32 分、25% でも 35 分しかかからない可能性があります。探索
デューティ・サイクルを比較的低い値に設定することによって、速度はわずかに低下するものの、
「孤立した」デバイ
スの大量の消費電力を節減できます。設定値が低すぎて 10% をかなり下回る場合は、参加にかかる時間が大幅に
増える可能性があります。限界では、探索デューティ・サイクルを 0（0.2%）にすることで、参加速度はきわめて低く
なり、平均消費電流は 10µA 未満になります。デバイスがケーブル給電ではなく、エナジー・ハーベスティングでも
なく、孤立状態になる可能性も低い場合には、25% が優れたスタート・ラインです。設置担当者にとってネットワー
ク形成の速度が十分に速いことを確認し、担当者のフィードバックに基づいてこの値を調整することを検討してくだ
さい。
27.3 センサ・アプリケーションの状態マシン
SmartMesh IP モートはジョイン・デューティ・サイクルの設定を持続するので、通常この設定は製造時またはデバイスの最
初の運用開始時に行われます。
SmartMesh WirelessHART では、ジョイン・デューティ・サイクルが持続されないので、アプリケーションに対して以下の
規則の適用を検討してください。
規則 1：ソフトウェアが起動イベントを常に取得できる状況にしておく。
モートがリセットすると必ず、このイベントはモートによって送信されます。モートの電源が入れ直される場合、モートは起動
イベントを送信します。モートはネットワークから離脱すると、起動イベントを送信します。モートはリセット・コマンドを無
線で受信すると、起動イベントを送信します。最も単純な状態マシンは、起動イベントを受信するたびに、ジョイン・デュー
ティ・サイクルを設定します。
規則 2：ソフトウェアは、join コマンドを送信する前に、ジョイン・デューティ・サイクルを設定できるよう常に準備が必要です。
デフォルトのジョイン・デューティ・サイクルを望んでいることが判明した場合でも、そのデフォルト値は将来変更される可能
性があります。使用する値は常に書き留めておいてください（最善の実践例は、現在の値を読み取り、その値が目的の値と
異なる場合は新しい値に書き換えることです）。
SmartMesh IP アプリケーションノート
117/140
27.4 まとめ
繰り返すには、以下の手順に従います。
• ステップ 1：起動時の定型作業で、モートの API コマンドを使用してジョイン・デューティ・サイクルを設定します。
join コマンドを送信するときは常にこのコマンドを呼び出すようにしてください。
• ステップ 2：プレースホルダとして、値 64（25%）を使用します。
• ステップ 3：約 5mA を常に消費するのが気にならない場合は、代わりに 255（100%）を設定します。
• ステップ 4：デバイスの電力量が限られている場合は、その値を使用して、余裕のあるジョイン・デューティ・サイク
ルを計算します。
• ステップ 5：値を実験的にテストして、調整が必要かどうかを決めます。
SmartMesh IP アプリケーションノート
118/140
28 アプリケーションノート：SmartMesh のセキュリティ
28.1 はじめに
無線パケットは、理論的には誰でも盗聴できる空気中を通って送信されます。実際に、802.15.4 の周波数範囲（2.4GHz の
ISM バンド）内の全 16 チャネルを同時にモニタできる、いわゆるパケット・スニファがあるので、チャネル・ホッピングだけ
では外部のリスナからデータを保護するには不十分です。セキュリティ・プロトコルは、すべてのパケットの未加工ビットを
受信できる傍受者がどの情報も解読できないように設計されている必要があります。弊社の全製品は、標準製品の一環とし
て同じセキュリティ機能を備えています。弊社は、お客様が認識しているかどうかに関係なく、すべてのお客様が安全なネッ
トワークを必要としていると確信しており、すべてのお客様がセキュリティ機能を有効にするようお勧めしています。セキュリ
ティ機能の唯一のマイナス面は、各パケット伝送に少量のオーバヘッドが追加されることですが、これによって生じる消費電
力の増分はごくわずかです。Dust 製品に実装されているセキュリティ基準は産業界の最良実施例であり、 Dust の実装は徹
底していて、奇を衒ったものではありません。
28.2 目標
安全なワイヤレス・ネットワークには以下の特性が必須です。
• メッセージ整合性̶宛先で受信されたデータは、伝送中に改変されていた場合、受け付けられないようにする必要
があります。これは、悪意のあるルータが存在する場合でも、パケットが送信元から宛先まで多くのホップを通過する
場合でも維持される必要がある終端間特性です。これは認証とも呼ばれます。会話している両者が気づかないうちに
第三者と通信しているという中間者攻撃を防ぐために、送信者の身元を確認することを意図しているからです。
• アクセス制御̶モートは認証済みモートからのデータだけを受け付ける必要があります。これはエンド・ツー・エンド
の特性ですが、リンク層でも満たす必要があります。無許可のモートからのデータがサービス妨害（DoS）攻撃につ
ながることを認めないようにすることが必要です。
• 機密性̶暗号化されたデータを傍受する盗聴者は、平文の長さ以外の平文データに関して何も特定できないように
する必要があります（意味的なセキュリティ）。
• リプレイ攻撃からの保護̶敵対者が暗号化された正規のトラフィックを捕捉し、
（場合によっては別の場所にある）ネッ
トワークにトラフィックを再注入した場合、そのことを検出せずに宛先で受け付けないようにする必要があります。こ
れは終端間およびリンク層の特性です。
• DoS 抵抗̶ネットワークにパケットを注入して、ネットワークが正常に動作しないようになるまでネットワークを混雑
させることは、困難にする必要があります。
28.3 SmartMesh のセキュリティ機能
• メッセージ整合性̶メッセージの整合性は 2 つの 32 ビット・メッセージ整合性コード（MIC）を使用して実現します。
1 つはリンク層（つまり、各ホップ）にあり、もう 1 つはネットワーク層 / メッシュ層（つまり、メッシュ内の終端間）にあ
ります。リンク層 MIC により、各ホップの受信側モートは、パケットがマネージャ承認済みモートによって送信されて
いることを確認できます。終端間 MIC は、パケットを解読して認証するために宛先で使用されます。この MIC は、送
信者がパケットを送信後、パケットがどのホップでも変更されなかったことを保証します。これら 2 つの MIC は、どち
らも CCM* アルゴリズムによって計算されます（以下を参照）。
SmartMesh IP アプリケーションノート
119/140
• アクセス制御̶マネージャは、ネットワークへの参加を許可されたデバイスとデバイスの参加鍵の一覧により、アク
セス制御リストを維持します。デバイスは、正しい 128 ビットの参加鍵を提示することなく参加することはできません。
• 機密性̶機密性は、ペイロードの 128 ビットの AES 暗号に基づいた CCM* ストリーム暗号で保証されます。暗号鍵と
は、実行時に無作為に生成され安全に配信される共有の秘密セッション鍵です。ネットワーク外部の盗聴者がペイロー
ドを解読することはできません。ネットワーク内部のモートが他のモートのペイロードを解読することはできません。
• リプレイ攻撃からの保護̶ネットワークに参加するときに、各モートは持続的な参加カウンタを使用して最初のメッ
セージを暗号化します。リプレイ参加要求はマネージャによってすべて検出され、破棄されます。モートがネットワー
クに参加し、セッション鍵を取得すると、すべてのパケットは単調に増加する 32 ビットのノンス・カウンタを使用して
暗号化されます。宛先では、受信したノンス・カウンタの履歴をレシーバが追跡して、古いパケットや複製のパケット
を除去します。さらに、上記のリンク層 MIC はタイムスタンプ・ベースのノンスを使用して計算されます。リプレイは
検出されて破棄されます。
• DoS 抵抗̶リプレイ攻撃からの保護を実現するセキュリティ属性は、DoS 抵抗機能も備えています。
28.4 暗号化と認証
すべてのデータ・リンク層（DLL）メッセージは、 CCM* と AES-128 をハードウェア内で組み合わせて使用することによって
認証されます。これは、既定の鍵を使用した参加要求、および実行時ネットワーク鍵を使用したそれ以外のすべてのメッセー
ジを使用して実行されます。DLL ノンス・カウンタは、共用時刻（ASN）に基づいてリプレイを防止します。CCM* と AES-
128 を組み合わせて使用することで、ネットワーク層ヘッダを認証し、ペイロードを認証 / 暗号化します。参加メッセージでは、
上記のように適切な対称参加鍵を使用します。モートは、リセットを通じてそのノンス・カウンタを持続します。上記のような
実行時セッション鍵は、それ以外のすべての終端間セッション・トラフィックのために使用されます。各セッションは固有のノ
ンス・データを伝送することにより、リプレイ攻撃と中間者攻撃を軽減します。
メッセージ整合性およびリプレイ攻撃からの保護は、リンク層での時間ベースのメッセージ認証によって保証されます。ネッ
トワーク層でのセッション・ベースの認証および暗号化により、機密性、送信元の認証、およびリプレイ攻撃からの保護が保
証されます。
28.4.1 キーイング・モデル
SmartMeshネットワークでは、不揮発性（NV）フラッシュに安全に保管された128ビットの参加鍵が各モートにあります。モー
トは、この参加鍵および参加カウンタを使用して暗号化された参加要求を送信することにより、モート自体をネットワークに
対して認証します。ネットワーク・マネージャはこのメッセージを解読して、メッセージの送信元が、正しい鍵を保有している
モートであり、予想された参加カウンタを使用しているモートであることを確認します。認証が失敗した場合、参加要求は破
棄されます。
デバイス認証後、マネージャは以下のセッション鍵を配布します。
• マネージャ・ユニキャスト・セッション̶このセッションは、すべての鍵およびほとんどのネットワーク構成メッセージ
を安全に送信するために使用されます。モートは具体的なスケジュールに基づいて他のモートと通信します。そのス
ケジュールの作成およびメンテナンスに関連付けられているすべてのコマンドは、マネージャ・ユニキャスト・セッショ
ンに厳密に制限されます（つまり、マネージャだけがネットワーク資源をレイアウトすることができます）。
SmartMesh IP アプリケーションノート
120/140
• マネージャ・ブロードキャスト・セッション̶このセッションはすべてのモートに対して 1 つの鍵を使用します。また、こ
のセッションはすべてのモートを同時に宛先とするコマンドに使用されます。このセッションは無線通信プログラミン
グ（OTAP）に対して使用され、ネットワーク内での通知送信率を制御するために使用されます。OTAP イメージを動
作状態にすることができるのは、マネージャ・ユニキャスト・セッションを使用した場合だけであることに注意してく
ださい。
• ゲートウェイ・ユニキャスト・セッション̶このセッションはセンサ・ペイロードを暗号化して解読するために使用され
ます。マネージャとモートは、その暗号化機能および解読機能を実行します。
• ゲートウェイ・ブロードキャスト・セッション̶ゲートウェイが将来ペイロードをすべてのセンサ・プロセッサにブロー
ドキャストする必要がある場合、この鍵はそのペイロードを暗号化および解読のために使用されます。
上記のセキュリティ・セッションには、それぞれ鍵があります。したがって、N モートのネットワークには、N 個のマネージャ・
ユニキャスト・セッション鍵、N 個のゲートウェイ・セッション鍵、さらに 2 つのブロードキャスト・セッション鍵があります。
最後の鍵はネットワーク MIC 鍵です。この共有鍵は、データ・リンク層でパケットを認証するためにすべてのモートによって
使用されます。言い換えると、ルーティング・モートは、パケットの送信元が有効な隣接モートであることをこの鍵を使用して
確認し、暗号を解読するために必要な鍵は保有していません。
28.4.2 参加に関するマネージャのセキュリティ・ポリシー
マネージャには参加に関する 3 つのセキュリティ・ポリシーがあり、ネットワーク管理者が選択できます。
• 共通鍵の容認̶このセキュリティ・ポリシーでは、マネージャは、ネットワーク全体にわたる共有参加鍵を提示する
すべてのモートに対してネットワークへのアクセスを許可します。
• ACL と共通鍵̶このセキュリティ・ポリシーでは、マネージャは、グローバルに一意の 8 バイトの MAC アドレスがア
クセス制御リスト（ACL）に登録されているモートで、かつネットワーク全体にわたる共有参加鍵を提示するモートに
対してのみネットワークへのアクセスを許可します。無効の MAC アドレスまたは誤った参加鍵を提示する参加要求
は破棄されます。
• ACL と固有鍵̶このモードでは、ACL 上にある各モートに固有の参加鍵があります。デバイスがネットワークへのア
クセスを許可されるのは、正しい MAC アドレスおよび参加鍵を提示する場合だけです。それ以外のすべての要求は
破棄されます。これは推奨の動作モードであり、最も安全な動作モードです。
28.4.3 鍵管理
鍵の生成と配布はネットワーク・マネージャによって実行されます。鍵の生成は NIST 規格 SP800-90 に基づきます。CTR-
DRBG は熱ノイズと XOR 関数をサンプリングして、大きなランダム・シードを生成します。ネットワーク・マネージャには自
動的な鍵ローテーション・ポリシーはありませんが、ネットワーク・マネージャは鍵ローテーション API による指示に対応して、
すべての鍵の安全な生成およびローテーションを実行します。
SmartMesh IP アプリケーションノート
121/140
28.4.4 A CCM* に関する注意
CCM*（Counter mode with a CBC-MAC）とは、カウンタ・モードと CBC-MAC の組み合わせを意味します。これでは何
のことだか判らなかったでしょうか？ CBC（Chain Block Cipher）とは、連鎖ブロック暗号という意味です。AES はブロック
暗号で、16 バイトのデータ・ブロックを処理します。任意の長さの長いデータ（ストリーム）に役立てるには、ブロック連鎖と
呼ばれる技術を使用します。1 回の AES ブロック計算の出力を次のブロックへの入力として使用するので、すべてのブロック
のセキュリティは互いに「鎖でつながって」います。CCM* では、データが変更されなかったことを検証するために使用する
メッセージ確認コード（Message Authentication Code）も生成します。これはメッセージ整合性コード（MIC：Message
Integrity Code）とも呼ばれます。
「CCM* では」とは、認証動作、暗号化動作、あるいはその両方を実行できるという意味で
す。CCM は増分カウンタをノンスとして使用します。ノンスとは、暗号化 / 解読動作に対する入力として「1 回だけ使用され
る数」です。ノンスを秘密にしておく必要はありませんが、送信側と受信側が両方とも現在のノンスがいくつかを（鍵と合わ
せて）認識し、適切にパケットを解読する必要があります。また、この数の使用は 1 回だけにする必要があります。リンク層の
ノンスの場合、モートは ASN（ネットワーク内で経過したスロットのカウント）を使用します。ネットワーク層では、これは増
分メッセージ・カウンタです。
SmartMesh IP アプリケーションノート
122/140
29 アプリケーションノート：TestRadio コマンドの使用
29.1 testRadio コマンド
SmartMesh WirelessHART Mote ファームウェアは、 2 つのモート間の無線リンクの質をスタンド・アロンのテストで測定
これらのコマンドは無線の詳細な機能を実行し、
するAPIコマンド（testRadioTxExtおよびtestRadioRx）を内蔵しています。
またネットワークに参加していないモートでのみ使用できます。これらのコマンドにより、インテグレータはアプリケーション
のフロント・エンドを介して無線検査コマンドをプログラムで公開できるので、デバイス CLI の公開とは対照的です。
これらのコマンドは、通常は設計 / 製造したアンテナが期待どおりに動作することを確認する目的で使用します。このアプリ
ケーションノートでは、これらのコマンドを使用して 2 つのモート間のパケット配信比（PDR）テストを行なう方法を詳しく説
明します。このテストは、通常は上位の組立検査またはフィールド・デバッグ作業で用います。
testRadioTx コマンドおよび testRadioRx コマンドを使用してトランスミッタ・モートからレシーバ・モートへ 1000 パケット
を送信し、受信したパケット数の統計情報を収集します。
29.2 セットアップ
以下のものが必要です。
• ネットワークには接続されていない 2 つの SmartMesh WirelessHART モートまたは SmartMesh IP モート
• 使用可能な 2 つの USB ポートを備え、SmartMesh SDK がインストールされたコンピュータ
• 2 本の USB ケーブル
起動する前に、コンピュータに接続されている 2 つのモートの API ポートに対応するシリアル・ポート番号を書き留めてくだ
さい。
29.3 実験の実施
• APIExplorer アプリケーション（SmartMesh SDK の一部）の 2 つのインスタンスを起動します。
• アプリケーションを両方とも 2 つのモートの API ポートに接続します。
• トランスミッタ・モートに接続されている APIExplorer で、以下の操作を行います。
• testRadioTxExt コマンドを選択し、以下に示すフィールドにデータを取り込みます。
• testType：パケット - これにより、モートは IEEE802.15.4 準拠のパケットを送信するよう指示されます。
• chanMask：8000 - これは チャネル 15 つまり 2.480GHz でパケットを送信することを示しています
（0x8000 はビットマップ b1000000000000000 に対応します。つまり、ビット 15 だけが設定されます）。
• repeatCnt：1 - パケット・シーケンスを繰り返す回数。
• txPower：8 - モートは +8dBm の伝導電力でパケットを送信します。
• seqSize：1000 - 各シーケンスでのパケットの数
• sequenceDef：pkLen = 125、delay = 20000。パケット間の間隔は 20ms なので、1000 パケットを送
信するのに 20 秒かかります。モートはパケットの末尾に 2 バイトの CRC を追加するので、結果として最
大長の IEEE802.15.4 パケットになります。
• 「send」ボタンはまだクリックしないでください。
SmartMesh IP アプリケーションノート
123/140
• レシーバ・モートに接続されている APIExplorer で、以下の操作を行います。
• testRadioRx コマンドを選択し、以下に示すフィールドにデータを取り込みます。
• channel：2.480GHz。これはチャネル 15（トランスミッタが送信するチャネル）に対応します。
• time：30。これにより、モートは 30 秒間パケットを受信するよう指示されます。トランスミッタは 20 秒間
送信するので、これによって小容量のバッファが得られます。
• 以下のようにしてテストを開始します。
• レシーバ側の「send」ボタンをクリックします。モートは 30 秒間の受信を開始します。
• トランスミッタ側の「send」ボタンをクリックします。モートは、全 20 秒間にわたる 1000 パケットの送信を開始
します。
• 30 秒間待機し、以下の手順で結果を収集します。
• レシーバ・モートに接続されている APIExplorer で、getParameter コマンドと testRadioRxStats サブコマン
ドを入力します。
「send」を押します。
• 応答フィールドには以下のフィールドが含まれます。
• 「rxOk」は、正常に受信したパケットの数です。
• 「rxFail」は、受信したが CRC が失敗したパケットの数です。これは、パケットを受信したが送信中に破
壊されたことを示しています。
29.4 結果の解釈
干渉、マルチパス・フェージング、不適当なアンテナ接続、送信側と受信側との距離が離れすぎている場合など、いくつかの
物理的現象はパケットを正確に受信しない原因になる場合があります。これらの場合にはパケットを低い SN 比で受信する
ので、結局パケットが破壊（して、rxFail カウンタで表示）するか、まったく受信しなくなる可能性があります。
したがって、以下のことを確認する必要があります。
• 正しく受信されたパケットの数は？これは rxOk カウンタで確認します。
• 受信したが破壊しているパケットの数は？これは rxFail カウンタで確認します。
• 失われたパケットの数は？これは、送信したパケットの数と、rxOk カウンタと rxFail カウンタの数の合計との差です。
SmartMesh IP アプリケーションノート
124/140
30 アプリケーションノート：ピーク時の平均電流を
制限するための最良実施例
LTC5800 は低消費電力設計を目的としています。ただし、通常のモートは 50µA 未満の動作電流が標準的ですが、
（デバ
イスの起動時など）短い期間にはるかに大きい電流が流れる可能性があります。このことは、電流が制限された電源で動
作する設計における課題となります。LTC5800 は、デバイス自体を 360µA の平均電流に制限することを目標として設計
されています。この平均電流は、これらのピーク電流間隔時に 7 秒間にわたって平均化された値です。ただし、この電流
目標値を満たすには、ある特定のシステムレベルの考察を行う必要があります。この電流レベルは、従来の SmartMesh
WirelessHART 製品（DN2510）での低電流起動モードに対応しており、このモードは 4 ∼ 20mA の電流ループでのモート
の動作をサポートすることを目的としていました。
特に示していない場合、各項目はすべての SmartMesh ファミリに当てはまります。
• リセット - 起動時には約 800µA を消費し、800ms かかります。起動後にデバイスを繰り返しリセットすると、平均電
流が目標値より高くなることがあります。OEM プロセッサはデバイスを 2 秒より短い間隔では再起動しないというの
が弊社のガイドラインです。
• ジョイン・デューティ・サイクル - 平均電流がこの目標値を満たすように、ジョイン・デューティ・サイクルは 5% 以下
に設定します。
• UART 動作（SmartMesh WirelessHART）- UARTトラフィックは 9600bps では電流に多少影響があります。あ
る 1 つの API での処理を 115kbps で連続ループすると、平均電流が約 75µA 上昇するので回避する必要があります
が、これは通常の使用事例ではありません。デバイスの通常の使用では、ポーリングではなく通知が使用されます。
TIME ピンのポーリングは 2 秒より短い間隔で行わないようにしてください。
• 持続パラメータ - このシステムでは、ユーザーは setNVParameterAPI を使用してフラッシュ・ベースの不揮発性パ
ラメータを変更できます。ただし、書き込みが連続すると平均電流の目標値を超えることがあります。弊社のガイドラ
インは以下のとおりです。
• 起動通知の受信後、2 秒待ってから NV 書き込みを実行する
• NV パラメータの連続的な書き込みは、最短でも 2 秒間隔で行う必要がある
• NV 書き込みを起動通知後に行う場合は、参加要求を出す前に 2 秒待つ
• OTAP - OTAP では、
（着信する OTAP ファイルを保管するために）ファイル・システムを消去し、
（稼働中のファー
ムウェアを置き換えるために）メインのフラッシュ領域を消去する必要があります。現在のリリース（SmartMesh
WirelessHART 1.0.2、SmartMesh IP 1.2.0）では、この動作は不可分であり、電流の目標値を超えるので、電流が
制限されたデバイスでは、このバージョンのコードを使用した場合、 OTAP を行わないようにする必要があります。
OTAP による消去は、後続のリリースでは動作が周期化され、電流の目標値を満たします。OTAP は頻度の低い動作
であり、寿命に達するまでにアップグレードされないシステムが多数を占めます。
• 通電バックボーン（SmartMesh IP、SmartMesh WirelessHART のマネージャ 4.1 以上）- DN2510 の低電流
起動モードは、このネットワーク・モードでの電力の目標値を満たしません。LTC5800 モートは、 IP ネットワークと
WirelessHART ネットワークの両方のバックボーン上で非ルーティング・リーフとして動作できます。
• 極度の輻輳 - マネージャはモートのリンクを制限して、すべてのリンクが使用された場合でも電流の目標値を超えな
いようにします。実際に使用されるのはこれらのリンクの一部だけなので、現在のリリースでは、温度変動による無
線の再調整など、低頻度のハウスキーピング動作は考慮していません。非常にまれな事例では、デバイスがその無
線を再調整する必要がある場合、極度に輻輳したモートが目標値を超えることがあります。これによってリセットが発
生した場合でも、モートは起動時に再調整して正常に参加します。
• スクラッチ・パッドの使用（SmartMesh WirelessHART モート 1.1 以上）- バージョン 1.1.x 以降のモート・ソフトウェ
アでは、顧客の使用を目的としてスクラッチ・パッドを使用できます。ガイドラインは持続パラメータの場合と同じです。
平均電力の目標値を確実に満たすため、スクラッチ・パッドの書き込みは 2 秒以上の間隔を空ける必要があります。
SmartMesh IP アプリケーションノート
125/140
31 アプリケーションノート：パイロット・ネットワーク評価の方法
31.1 まとめ
パイロット・ネットワークの配置、テスト、分析を行い、最終的な配置先での典型的な環境で十分に機能するかどうかを確か
めたいという要求があります。モート / センサの場所、トポロジ、報告率などに関してパイロットの配置が実際の配置と一致
する割合が近づくほど、ユーザーは実際のネットワークがどのように機能するかの感触をつかみやすくなります。
SmartMesh SDK は、ユーザー固有の環境でネットワークを評価するシンプルなツールを提供します。ここでは、検査用の
特有な環境でユーザーがモートを配置するのに役立つ段階的なアプローチの概要を説明します。配置後、SDKに付属のユー
ティリティを使用して、ネットワーク内のさまざまなモートを構成し、所望の率でデータを報告するよう設定できるので、動作
を報告する実際のセンサを実際の配置でエミュレートできます。本書では、配置後のネットワークから一定期間にわたって
統計情報を収集して分析し、信頼性、データ・レート、帯域幅などの重要なパラメータに関してパイロット・ネットワークの
性能を評価する方法について説明します。
31.2 SmartMesh スタータ・キットと SDK
SmartMesh スタータ・キットには、標準で 1 つのマネージャと 5 つのモートが付属しています。必要に応じて追加のモート
を購入して、ネットワーク・サイズを大きくすることができます。ユーザーはリニアテクノロジーの FAE と事前にご相談いた
だいて、用途に応じた適切な製品ファミリ（SmartMesh IP または SmartMesh WirelessHART）を選ぶ必要があります。す
べての資料、ソフトウェア・ユーティリティ、およびツールは http://www.linear-tech.co.jp/starterkits でダウンロードでき
ます。
「SmartMesh IP Easy Start Guide」または「SmartMesh WirelessHART Easy Start Guide」は、スタータ・キット・ハー
ドウェアの設置と SDK ソフトウェアの基本機能のインストールについて説明しています。このアプリケーションノートでは、こ
れ以降、ユーザーの PC に適切な SDK が適切にインストールされており、ユーザーはマネージャで CLI（コマンド行インタ
フェース）を操作できることを前提とします。
設置やインストールの詳細については、
「SmartMesh IP Tools Guide」または「SmartMesh WirelessHART
Tools Guide」を参照してください。
31.3 評価方法
パイロット・ネットワークは、基本的に以下の 5 段階で評価します。
• ステップ 1 - SDK の PC へのインストール
• ステップ 2 - SDK のモートおよびマネージャのパイロット・ネットワークの配置
• ステップ 3 - 特定のデータ・レートに対応したモートの構成
• ステップ 4 - データと統計情報の収集
• ステップ 5 - データの分析
SmartMesh IP アプリケーションノート
126/140
31.4 ステップ 1：SDK の PC へのインストール
1. http://www.linear-tech.co.jp/starterkits から SDK をダウンロードします。目的の製品ファミリ（SmartMesh IP
または SmartMesh WirelessHART）に基づいて、該当する資料をダウンロードします。
2. 「Easy Start Guide」を確認し、SDK を PC にインストールします。
3. PC をマネージャに接続して CLI を実行できることを確認します。
4. SmartMesh IP の場合は、シリアル・マルチプレクサが設置されていて、正常に動作していることを確認します。詳
細なインストール手順については、
「SmartMesh IP Tools Guide」を参照してください。
31.5 ステップ 2：SDK のモートおよびマネージャのパイロット・
ネットワークの配置
• アプリケーションノート「配置の計画」を参照します。重要な配置ガイドラインは、各モートを他の 3 つの隣接モート /
モートの範囲内に置くことです。
• 物理的環境に基づいて範囲を決めます。50 メートルの範囲から始めて、結果に応じて後で調整してもかまいません。
ネットワークの解析では、設置する各モートの場所、または少なくとも隣接モートまでの距離を文書化できれば非
この距離デー
常に役立ちます。しばらくの間ネットワークを稼働したら、RSSIと対照してグラフを作成するためには、
タが非常に重要になります。
• 上記の 3 つの隣接モートのガイドラインと対象にする領域に基づいて、パイロット・ネットワークの配置に必要なモー
トの数を決めます。正常な配置のために必要な数のモートがあることを確認してください。
• マネージャを最初に配置します。PC を介してマネージャにアクセスできることを確認します。マネージャに電源を入
れ、CLI コマンドを実行できることを確認します。
• モートのバッテリが新しいことを確認します。モートは新しいバッテリを装着して出荷されていますが、 SDK のイン
ストール時やテスト時に消耗した可能性があります。この状況が起こる可能性があるのは、マネージャ / ネットワーク
が使用できない状態でモートが放置された場合です。この場合、モートは、容量を使い果たす可能性がある時間の
25% で、レシーバを使用してネットワークを探索し続けます。
• 特定のパラメータをモニタするために、センサを配置する可能性が高い場所にモートを配置することから始めます。
電源スイッチをオンにします。SmartMesh IP モートを有効化した場合は、Status_0 LED が点滅し始めます。
• モートの MAC アドレスと適切な配置先を必要に応じてマップまたは表に書き留めます。こうすると、ステップ 3 でデー
タレートに合わせてモートを構成するときに役立ちます。
モートを設置する前に、モートがマスタ・モードで構成されていることを確認してください。これはモートのデフォル
ト設定ですが、SDK のテスト中に構成を変更した可能性があります。
• 必要に応じて、計画のアプリケーションノートで概要を説明した方法に従って、中継器として動作する追加のモートを
設置してください。
• SmartMesh IP の場合、すべてのモートが配置されると 2 つのステータス LED が点灯し、各モートが現在マネージャ
に接続されていることを示します。
• 今度はマネージャに戻り、ネットワークが形成されていることを確認します。これはマネージャの CLI 接続を介して実
行できます。
• コマンド sm（「show motes」の省略形）を使用して、ネットワーク内のモートの一覧を表示します。
SmartMesh IP アプリケーションノート
127/140
いったん配置すると、ネットワークのサイズによりますが、ネットワークを形成するのに数分かかる場合があります。
モートが参加するように見えない場合は、モートを再起動してみてください。CLI コマンド trace motest on を
使用して、モートの状態変更をトレースすることもできます。これにより、モートが参加処理を段階的に進めるのに
応じて通知が書き込まれます。
下の図 1 には、マネージャに参加した 5 つのモートを、sm によって表示された状態で示します。モート ID 1 は AP（アクセス・
ポイント）モートです。ネットワーク内のすべてのモートがこの一覧に表示されることを確認してください。
図 1 - マネージャに接続されているモートを示す CLI コマンド sm
31.6 ステップ 3：特定のデータ・レートに対応したモートの構成
ネットワークは稼働状態になっているので、データを生成して送信するようモートを構成して、あたかもセンサからデータを
収集しているかのようにする必要があります。ネットワークを介して上り方向（モートからマネージャ）に送るデータの量、
レー
ト、およびサイズを指定します。SDK で利用可能な PkGen ユーティリティを使用してこれを遂行します。
パケット生成ユーティリティ PkGen では、ネットワーク内の各モートの構成をマネージャ自体から行うことが可能です。これ
は、ユーザーが個々のモートの場所に物理的に移動してモートのレートを設定する必要がないことを意味します。また、これ
らの構成を必要に応じて変更するには、変更が必要なモートの新しいフィールドに入力するだけで済みます。SmartMesh
ネットワークは異機種ネットワークとして動作できるので、各モートはモート固有のデータ・レートに合わせて構成できます。
データ・レートが低速 / 中速 / 高速のモートを組み合わせて、低速 / 中速 / 高速センサの現実世界のシナリオをエミュレートす
ることができます。
SmartMesh IP アプリケーションノート
128/140
PkGen ユーティリティを使用してモートを構成するには、以下の手順に従ってください。
このセクションでは、serialMux を動作状態にしておく必要があります。
• SmartMesh SDK の /win/ ディレクトリに移動し、/win/PkGen.exe で Windows 実行可能プログラムをダブル
クリックすることにより、PkGen を起動します。
• SmartMesh IP または SmartMesh WirelessHART を選択するよう指示されます。該当するファミリを選択して、
「load」をクリックします。
• IP デバイスに接続している場合は、指示されたときに serialMux を介して「connect」をクリックすれば済みます。こ
れが動作しない場合は、serialMux がステップ 1 で正しく設置されていることを確認してください。
• WirelessHart デ バ イス に 接 続して いる 場 合 は、 指 示 され たときに マ ネ ージャの IP アドレ ス を 入 力しま す。
WirelessHART マネージャのデフォルトの静的 IP アドレスは 198.162.99.101 です。このアドレスは任意のアドレス
に変更できます。詳細については、
「SmartMesh WirelessHART User s Guide」を参照してください。
• 接続すると、入力したフィールドが緑に変わり、ネットワーク内のモートの一覧がモート一覧のセクションに取り込ま
れます。ネットワーク内の各モートにはテーブルに一連のフィールドがあり、ここには各モートを構成するために必要
に応じて情報を入力します。
• mac 列は、ネットワークに接続されているモートの MAC アドレスを示しますが、これは構成の対象です。これを使用
して現場でのモートの位置を割り出し、その後、具体的な構成を決定する場合があります。
• 次の列（num. pkgen）は、PkGen の起動後任意の時点でそのモートからマネージャに送信されたパケットのカウン
タです。
• 次の列（pk./sec）は、モートがマネージャにパケットを送信しているときのパケット / 秒単位の平均レートを示す別
のカウンタです。ここに値が表示されるまでしばらく時間がかかる場合があります。
• 前の 2 列は「clear」ボタンを押すとリセットできます。おそらく新しい送信パラメータを設定するたびにこの操作を行
うことになるでしょう。
• 最後の列には 3 つのフィールドと「set」ボタンがあります。最初のフィールドは、モートが送信するパケット数の合計
用です。配置の期間とモートがデータを送信するレートに応じて、適切な数値をここに入力してください。少なくとも
1 つのパケットを送信する必要がありますが、最大値はありません。2 番目のフィールドはパケットの間隔で、単位は
ミリ秒です。
（たとえば、1000 = 1 パケット / 1000ms つまり1 パケット / 秒）。最後のフィールドは、毎回送信するパケッ
トのサイズです。
（最大 60 バイトで 20 バイトのヘッダあり）。
空白のセルに「-」を入力することはしないでください。空白のままにしておいてください。
• 最後の列の「set」ボタンをクリックして、モートによるパケットの送信を開始します。
（必要な場合は、
「clear pkgen」
ボタンを使用すればこれらのフィールドをリセットできます。）
「set」ボタンを押してから次に押すまで時間をおいてください。
「set」を 2 回急に押すと、セルが誤って緑に変わり、
セルが更新されたように表示されますが、パケットはネットワークに送信されません。
• ネットワーク内のモートごとに上記の 2 つの手順を繰り返します。
SmartMesh IP アプリケーションノート
129/140
マネージャがパケットの受信に利用できる全帯域幅には上限があります。この値はファミリに依存しますが、約 25
パケット / 秒です。この限度は超えないようにしてください。言い換えると、すべてのモートからマネージャに移動す
る 1 秒当たりのデータ・パケットの合計がこの限度を超えないようにする必要があります。個々のモートのデータ・
レートは、このようにネットワーク内のモートの総数とモートの個別データ・レートに依存します。たとえば、5 つの
モートを備えたネットワークでは、すべてのモート上で同時に 5 パケット / 秒を超えないようにする必要があります。
• スクリプトを閉じても、モートがパケットの送信を停止するという意味にはなりません。モートはすべてのパケットを
送信するまで送信し続けます。モートによるデータの送信を停止する場合は、モートをリセットしてください。
下記の図 2 は、PkGen スクリーン・ショットの例を示します。たとえば、最大サイズのパケットを 1 週間 1 パケット / 秒のレー
トで送信する場合は、
「num/rate/size」フィールドに次のように入力します。604800 1000 60
パラメータをモートごとに好みの値に設定すると、
「num. pkgen」カウンタが計数を開始するのを確認できます。
「pk./
sec」列には、最も近い 0.1 パケット/ 秒単位の値に丸められたレートが表示されます。レートが低すぎるか、送信されるパケッ
ト数が（平均を計算するには）不十分な場合は、0.0 というレートが表示されます。
図 2 - マネージャに接続されているモートを示す CLI コマンド sm
31.7 ステップ 4：統計情報の収集
ネットワークは上り方向にデータを送信しているので、次の段階は、現在の構成でのネットワークの性能を分析するために
使用できるネットワーク統計情報を収集することです。ネットワーク内の各モートは、ネットワーク、パケット成功率、隣接モー
トなどに関する情報が含まれているパケットを定期的に送信します。これらのパケットは健全性レポートと呼ばれ、標準で
15 分おきに送信されます。SmartMesh ネットワークには、データ・アクセスと同様に、ユーザーがすべてのネットワーク統
計情報にアクセスできる API が用意されています。
SmartMesh WirelessHART と SmartMesh IP のどちらを使用しているかに応じて、2 つのうちいずれかの方法で統計のス
ナップショットをとります。
SmartMesh IP アプリケーションノート
130/140
ステップ 4A：IP ネットワークでの統計情報の収集
SmartMesh IP マネージャは、ネットワーク信頼性、経路安定性、およびモート動作の最小限の統計情報一式を維持します。
ネットワーク健全性の全体像をつかむには、すべての健全性レポート通知を記録する必要があります。このトピックの詳細
については、
「アプリケーションノート：SmartMesh IP ネットワークの健全性のモニタ」で説明します。
ステップ 4B：WirelessHART ネットワーク・スナップショットによる統計情報の収集
SmartMesh WirelessHART マネージャは、すべてのマネージャ・ログを収集するユーティリティを内蔵しています。このユー
ティリティを呼び出すには、マネージャにログインし、Linux プロンプトでコマンドを使用します。
1. CLI に接続する方法である dust ログインを使用してマネージャにログインします。
2. nwConsole を使用する代わりに、次のコマンドを使用します。
/usr/bin/create-network-snapshot
これにより、現在のネットワーク統計情報のスナップショットを取って、それを /tmp/snapshot/snapshot.tar.gz に
保管できます。
1. このスナップショットにアクセスするには、WinSCP または別の FTP クライアントを使用してマネージャに接続しま
す。pkgen およびポート 22 との接続に使用したのと同じ IP アドレスに接続します。/tmp/snapshot に移動して、
snapshot.tar.gz を自分のマシンに転送します。
図 3 - マネージャからのネットワーク・スナップショットの転送
新しいスナップショットを取ると古いスナップショットは上書きされるので、必ずファイルをモートから転送してから
新しいスナップショットを取るようにしてください。
SmartMesh IP アプリケーションノート
131/140
31.8 ステップ 5：データの分析
SmartMesh IP でのスナップショット・ログの収集を効率化し、さらにスナップショット機能によって生成されたログを分析す
る実例ツールは、まだ開発中ですが、供給された場合には SmartMesh SDK の一部になります。
スナップショット・ログを検査する 1 つの目標は、経路 RSSI に関するデータを取得することです。これにより、このデータを
距離と比較して、より優れたネットワークを構築できます。より信号強度が高い経路を探すことにより、最適なモート間隔をう
まく判断することができます。
31.8.1 WirelessHart スナップショット・ログ
この ログ は、 マ ネ ージャから抽 出した .tar ファイル にあります。このファイル を 解 凍 すると、 求 めているデ ータは
nwconsoleOut.txt ファイルにあることが分ります。このログは、その名前のとおり、実際にはマネージャのコンソール
の内部照会の出力にすぎません。スナップショットの時点でのネットワークの状態に関する情報を集めるさまざまなコマン
ドを出します。show ver から始まる最初のコマンドを実行すると、おおむねマネージャのバージョン、状態、および設定に
関する基本的な情報が得られます。
sm –a を実行すると、ネットワーク内のモートの一覧が出力されます。
以下に示すのは、その出力の一部です。
< sm -a
Current time: 07/24/12 09:15:03 ASN: 32492664
Elapsed time: 3 days, 18:15:30
MAC MoteId Age Jn UpTime Fr Nbrs Links State
00-17-0D-00-00-1B-1B-CD ap 1 1 3-18:15:23 6 10 106 Oper
00-17-0D-00-00-38-0C-86 2 16 2 19:02:46 2 2 11 Oper
00-17-0D-00-00-38-0C-89 3 9 2 1-00:03:00 2 7 17 Oper
以下に示す get paths コマンドを実行すると、各モート対と、その経路上のリンクの数および方向、ならびに経路品質が
一覧表示されます。リンクが存在しない場合は unused（未使用）と表示され、経路品質はデフォルトの 75 になります。
< get paths
pathId: 65538
moteAMac: 00-17-0D-00-00-1B-1B-CD
moteBMac: 00-17-0D-00-00-38-0C-86
numLinks: 5
pathDirection: downstream
pathQuality: 90.07
pathId: 131077
moteAMac: 00-17-0D-00-00-38-0C-86
moteBMac: 00-17-0D-00-00-38-0C-96
numLinks: 0
pathDirection: unused
pathQuality: 75.00
この後は、便利だが該当する情報が少ないコマンドが続きますが、その一方で、必要な情報の大半を占める show mote
-a コマンドがあります。これらのコマンドは、各モートの隣接モートまでのすべての経路と、さらにこれらの経路のそれぞれ
の RSSI および経路品質を表示します。
SmartMesh IP アプリケーションノート
132/140
< show mote 1 -a
00-17-0D-00-00-1B-1B-CD 1 Oper SW: 3.0.2-0 HW: 37
Location is not supported
Number free TS: 757
Upstream hops: 0, latency: 0.000, TTL: 127
SourceRoute: Dist(Des): 0.0(10) Prim: 1 Sec:
Power Source: line
Advertisement Period: 20.000
Bandwidth:
Summary for AP: 2.5342
Neighbors: 10. Links: 106. Norm/bitmap 21/85 (max norm: 63)
Links per second: 19.824219 (unlimited)
Frame: 0. Neighbors: 10. Parents: 0. Links rx:87, tx:1.
Broadcast links
0. 1. 0: rtdb
0.993.10: rjb
<- #2 Links 3/3/3 RSSI: -52 Q: 0.90
<- #3 Links 4/4/4 RSSI: -29 Q: 0.94
<- #4 Links 8/8/8 RSSI: -50 Q: 0.83
<- #5 Links 5/5/5 RSSI: -51 Q: 0.86
<- #6 Links 3/3/3 RSSI: -48 Q: 0.90
<- #7 Links 33/33/33 RSSI: -41 Q: 0.86
<- #8 Links 16/16/16 RSSI: -43 Q: 0.90
<- #9 Links 6/6/6 RSSI: -45 Q: 0.87
<- #10 Links 4/4/4 RSSI: -41 Q: 0.90
<- #11 Links 3/3/3 RSSI: -41 Q: 0.95
この部分以降、ログには多くの統計表が取り込まれます。その内容は、モート、経路、およびネットワークの日々の統計の他に、
それらの寿命統計が含まれます。
SmartMesh IP アプリケーションノート
133/140
31.8.2 ログ・ファイルの解釈と分析
目標は、距離対 RSSI（経路安定性）を示す滝型曲線を生成することです。この曲線の屈曲部に着目すると、配置環境内でど
の範囲が適切かについて参考になるデータが得られます。この範囲は、元の配置で使用されたデフォルトの 50m の代わりに、
将来の配置に使用してもかまいません。
グラフの例を以下に示します。
これらのグラフは以下の方法によって生成できます。
• RSSI（経路品質）の値を経路ごとにログ・ファイルから抽出する
• 各モート対の間の距離を計算する
• 各 RSSI（経路品質）の値と、対応する距離とを対比させて作図する
SmartMesh IP アプリケーションノート
134/140
31.8.3 隣接モートの安定性分析
モートが備える良質な隣接モートの数（強い経路安定性）は、回復力のあるネットワークを形成するのに非常に重要です。こ
のデータをログ・ファイルから収集すると、ネットワーク・メッシュ内にある弱いリンクを見つけるのに役立つ場合がありま
す。3 つ以上の良質な隣接モートを持つモートはネットワークに正常に参加する確率が高いので、このフィードバックはネッ
トワークの配置担当者にとって特に役立ちます。良質な隣接モートの数が 3 未満の場合は、より多くの隣接モートを近くに配
置する必要性が高くなります。
その他のネットワーク健全性および性能を獲得する方法については、該当するファミリの「アプリケーションノート：ネットワー
ク性能とデバイス性能の評価方法」に説明されている場合があります。
SmartMesh IP アプリケーションノート
135/140
32 アプリケーションノート：パケット ID の概要と必要な理由
32.1 適用範囲
本書では、WirelessHARTとSmartMesh IPの両モート製品のモートAPIヘッダにあるフィールド・フラグでのパケットID（ビッ
ト 1）のユーティリティについて説明します。本書の最初のセクションでは、パケット ID について概説します。2 番目のセクショ
ンでは、モートとセンサ間のプロセッサ・インタフェースで 2 つのパケット ID がどのように使用されているか、それぞれがど
のように独立して切り替わり、追跡されるかについて説明します。3番目のセクションでは、パケットIDおよび関連する同期ビッ
トをコードでどのように使用するかについていくつかの有益なヒントを示します。
32.2 パケット ID とは？
たとえば、電動式のバケツ給水機があり、通信インタフェースがあって、このインタフェースを介して装置に以下の指示を出
すと考えてください。
1. 右へ移動しなさい
2. そこにバケツがあることを確認しなさい
3. バケツ 1 杯分の水を注ぎなさい
4. これを繰り返しなさい
これをバケツ給水機に指示するマイクロコントローラ・アプリケーションは作成可能であり、通常は正常に機能します。この
インタフェースを通信エラーに対してより堅牢にするために、呼び出し応答プロトコルを実装すると想定します。クライアント
（ここではマイクロコントローラ）からの各コマンドに対して、サーバ（ここではバケツ給水機）からの応答を生成します。ト
ランザクションは以下のように見えます。
1. マイクロコントローラ：右へ移動しなさい
2. バケツ給水機：右へ移動しました
3. マイクロコントローラ：そこにバケツがあることを確認しなさい
4. バケツ給水機：バケツがあります
5. マイクロコントローラ：バケツ 1 杯分の水を注ぎなさい
6. バケツ給水機：バケツ 1 杯分の水を注ぎました
7. これを繰り返しなさい
クライアントはそのメッセージが正常に伝達されたことを確認するので、より堅牢なインタフェースが得られました。ただし、
メッセージが届かない場合は、別の問題が予測されます。マイクロコントローラが「右へ移動しなさい」というコマンドを送
信し、応答を受信しなかった場合、これはバケツ給水機がコマンドを受け取っていないか、またはマイクロコントローラが応
答を受け取っていないことが原因の可能性があります。前者の場合は、クライアントがコマンドを繰り返す必要があるのに対
して、後者の場合はサーバの混乱を避けるため、次のコマンドに移る必要があります。必要なのは区別を可能にする識別子
です。コマンドと一緒にカウンタを送信することによってこれを実現できます。
1. クライアント：右へ移動しなさい（ID = 0）
2. サーバ：右へ移動しました（ID = 0）
3. クライアント：そこにバケツがあることを確認しなさい（ID = 1）- コマンドが届いていない
4. 応答を受信していないので、クライアントは最後のコマンドを繰り返します
5. クライアント：そこにバケツがあることを確認しなさい（ID = 1）
SmartMesh IP アプリケーションノート
136/140
6. サーバ：バケツがあります（ID = 1）
7. クライアント：バケツ 1 杯分の水を注ぎなさい（ID = 2）
8. サーバ：バケツ 1 杯分の水を注ぎました（ID = 2）- 応答が届いていない
9. 応答を受信していないので、クライアントは最後のコマンドを繰り返します
10. クライアント：バケツ 1 杯分の水を注ぎなさい（ID = 2）
11. サーバ：給水機はコマンド（ID = 2）に応答してバケツを既に水で満たしたので、コマンドを破棄して「バケツ 1 杯
分の水を注ぎました（ID = 2）」と応答したことを認識しました
コマンドに識別子があったので、コマンドの受信側は再試行と新しいコマンドとを区別できます。バケツ給水機はコマンド
で別の ID を受信しなかったので、再度バケツに水を注ぐ必要がないことを認識していました。現在のコマンドにアクノリッ
ジが返されるまでは次のコマンドに進まない信頼できるインタフェースでは、コマンドと後続のコマンドを区別することだけ
が必要なので、 1 ビット・カウンタを ID 用に使用することができます。コマンド 1 はコマンド 0 の後に発行され、コマンド 0
はコマンド 1 の後に発行されます。これが 1 ビットのパケット ID フィールドが機能する仕組みです。パケット ID ビットを 0 と 1
の間で切り替えることによって、受信側は再試行と新しいコマンドとを区別できます。ほとんどのモート・コマンドでは、バケ
ツに 2 杯分の水を注ぐことや、右に 1 歩ではなく2 歩動くような悪い結果になることはありませんが、これは依然としてインタ
フェースの信頼性に対する大きな改良点です。
32.3 2 つのパケット ID の存在
モートとセンサ・プロセッサを内蔵しているデバイスでは、2 つの独立した通信ストリームがあります。1 つはモートがサーバ
でセンサ・プロセッサがクライアントである場合で、もう 1 つはセンサ・プロセッサがサーバでモートがクライアントである
場合です。各ストリームにはそれ固有のパケット ID があります。センサ・プロセッサは、モートにコマンドを送信するたびに、
そのパケット ID を切り替える必要があります。モートはコマンドを受信するたびにそのパケット ID を検査し、前に受信した
パケット ID と比較します。パケット ID が格納値と異なる場合はコマンドが処理され、このパケット ID が格納されます。パケッ
ト ID が重複している場合、コマンドは処理されません。また、モートは、前のコマンドで送信したのと同じ応答（キャッシュ
に格納されている応答）で応答します。
モートはセンサ・プロセッサにコマンド（通知）をいつでも送信できるので、その通信には第2のパケットIDが存在します。モー
トはコマンドを送信するたびに、そのパケット ID を切り替えます。センサ・プロセッサはパケット ID を検査し、前に受信した
このパケット ID が格納されます。
パケット ID と比較する必要があります。パケット ID が格納値と異なる場合は通知が処理され、
パケット ID が重複している場合、通知は破棄され、マイクロコントローラはキャッシュに格納されている前の応答を送信します。
32.4 同期ビット
センサ・プロセッサ・アプリケーションは、リセットするか、何らかの理由がある場合、使用または想定するパケット ID がわ
からなくなります。同期ビットを使用すると、クライアントがパケット ID をリセットして既知の状態にすることができます。セ
ンサ・プロセッサは、モートに送信する最初のパケットに同期ビットを設定します。これにより、このパケットはパケット ID に
かかわらず新しいパケットであるとモートに伝達されます。センサ・プロセッサは、それ以降パケット ID を切り替える必要が
あります。センサ・プロセッサは、リセット後最初のパケットを受信すると、すべてのパケット ID を受け付けて、追加のパケッ
トに備えてパケットID を切り替えることを想定します。SmartMesh IP では、モートがリセットした場合、モートは常に同期ビッ
トを設定した状態で起動イベントを送信します。SmartMesh WirelessHART では同期ビットは設定されませんが、センサ・
プロセッサは各起動イベントを他と重複しないイベントとみなすことができるので、モートからのすべてのパケット ID を受け
付けて、追加のパケットに備えてパケット ID を切り替えることを想定できます。
SmartMesh IP アプリケーションノート
137/140
32.5 パケット ID の無視
センサ・プロセッサの実装を単純化してとにかく機能させるため、センサ・プロセッサは受信側のすべてのコマンドを新しい
ものとみなして処理することにより、実質的にパケット ID を無視できます。送信側では、センサ・プロセッサはすべてのメッ
セージについて同期ビットを設定し、モートがすべてのパケットを新しいコマンドとして処理するよう保証する必要がありま
す。こうすると、信頼できる呼び出し応答インタフェースの堅牢性がいくらか失われるので、試作品以外では推奨の動作では
ありません。
SmartMesh IP アプリケーションノート
138/140
商標
Eterna、Mote-on-Chip、および SmartMesh IP は Dust Networks, Inc の商標です。Dust Networks のロゴ、Dust、Dust
Networks、および SmartMesh は Dust Networks, Inc の登録商標です。LT、LTC、LTM、および L はリニアテクノロジー
社の登録商標です。第三者の会社名および製品名は、それぞれ所有者の商標であり、情報提供の目的でのみ使用されてい
ます。
著作権
本書は米国および国際著作権、その他の知的所有権法と工業所有権法により保護されています。本書はリニアテクノロジー
社とそのライセンサにより専有されており、限定的ライセンスに基づいて頒布されています。リニアテクノロジー社からの書
面による許可なく、本製品またはその一部を、いかなる形態または手段によっても、使用、複製、修正、逆アセンブル、逆コ
ンパイル、リバース・エンジニアリング、頒布、または再頒布を行うことはできません。
限定的権利：米国政府による使用、複製、または開示は、FAR 52.227-14(g) (2)(6/87) および FAR 52.227-19(6/87)、また
は DFAR 252.227-7015 (b)(6/95) および DFAR 227.7202-3(a)、ならびにすべての同等および後継の法令と規制による制
限の対象となります。
免責事項
本書は「現状有姿」で提供されており、商品性、特定の目的への適合性に関する暗黙の保証を含むがこれらに限定されない
保証を、明示か黙示かにかかわらず、一切いたしません。
本書には技術的に不正確な記述またはその他の誤りが含まれる場合があります。訂正と改善は、新しいバージョンの文書に
取り入れられる可能性があります。
リニアテクノロジー社は、製品やサービスの適用または使用により発生する責任を負いません。また、間接的あるいは偶発
的損害を含むがそれに限定されない、いかなる責任も負わないものとします。
リニアテクノロジー社の製品は、誤動作がユーザーの深刻な人身傷害につながると合理的に予想できる生命維持装置、デ
バイス、またはその他のシステムでの使用、またはその機能不全により生命維持装置またはシステムの故障あるいはその安
全性や有効性に影響すると合理的に予想できる生命維持装置またはシステムの重要な部品としての使用を目的として設計
されていません。このような用途での使用を目的としてこれらの製品を使用または販売しているリニアテクノロジー社の顧客
は、顧客自身の責任でそれを行い、このような意図しないまたは不正な使用に直接または間接的に起因するすべての主張、
費用、損害、支出、および妥当な額の弁護士費用、また、かかるクレームでリニアテクノロジー社に該当製品の設計または
製造に関わる過失があったと主張される場合でも、これを完全に補償し、リニアテクノロジー社とその職員、従業員、子会社、
関連会社、および販売代理店に何ら損害を与えないことに同意するものとします。
リニアテクノロジー社は、いつでも製品またはサービスに対する修正、変更、拡張、改良、その他の変更を行う権利を保有し、
製品またはサービスを予告なく中止する権利を有します。顧客は、発注の前に最新の関連情報を入手し、その情報が最新
で完全であることを確認する必要があります。すべての製品は、注文承諾時または販売時に提供される、販売に関する Dust
Network の契約条件に従い販売されます。
SmartMesh IP アプリケーションノート
139/140
リニアテクノロジー社は、リニアテクノロジー社の製品またはサービスが使用される組み合わせ、マシン、またはプロセスに
関連するリニアテクノロジー社の特許、著作権、マスクワーク権、またはその他のリニアテクノロジー社の知的所有権に従っ
て、明示か黙示かにかかわらず、ライセンスが付与されることを保証または主張するものではありません。第三者の製品ま
たはサービスに関してリニアテクノロジー社が公開した情報は、その製品またはサービスを使用するためのリニアテクノロ
ジーからのライセンス、あるいはその保証または推奨を意味するものではありません。このような情報を使用する場合、第
三者の特許または他の知的所有権に従って第三者からのライセンスが必要になるか、またはリニアテクノロジー社の特許ま
たは他の知的所有権に従ってリニアテクノロジー社からのライセンスが必要になります。
Dust Networks, Inc は、リニアテクノロジー社の完全所有子会社です。
© Linear Technology Corp. 2012-2013 All Rights Reserved.
SmartMesh IP アプリケーションノート
140/140