1. ZDOコマンドによる管理ネットワーク更新要求
ZDO（Zigbee Device Object）はZigbeeデバイスの検出やネットワーク管理など、Zigbeeネットワークの管理および検出機能を提供します。前回は、ZDOコマンド（クラスタID：0x0031）であるManagement LQI（Link Quality Indicator）要求を実行し、返信されたフレームを解析してLQI等のパラメータを確認しました。今回は、ZDOコマンド（クラスタID：0x0038）である管理ネットワーク更新要求を実施します。
表1 ZDOコマンド（クラスタID）の種類
| ZDOコマンド（クラスタID） | 内容 |
| 0x0001 | IEEEアドレス要求 |
| 0x0002 | ノード記述子要求 |
| 0x0004 | シンプル記述子要求 |
| 0x0005 | アクティブエンドポイント要求 |
| 0x0031 | 管理LQI（Link Quality Indicator）要求 |
| 0x0032 | 管理ルーティング要求 |
| 0x0034 | 管理離脱要求 |
| 0x0036 | 管理参加許可要求 |
| 0x0038 | 管理ネットワーク更新要求 |
Zigbeeプロトコルにおいて ZDO（Zigbee Device Object）コマンドの一つとして「管理ネットワーク更新要求（Mgmt Network Update Request）」が定義されているのは、Zigbeeの分散型ネットワーク設計思想に基づくものと考えられます。
Digi International が提供する資料には、APIフレームを用いてZDOコマンドを送信する機能について、次のように記載されています。
「ZDO は通常、ホームオートメーションやスマートエネルギーなどのパブリックプロファイルで相互運用する Zigbee 製品を開発する場合、または他社の Zigbee デバイスと通信する場合に必要になります。また、ZDO を使用して、周波数アジリティ（エネルギー検出とチャネル変更 – Mgmt Network Update Request）、ルート（Mgmt Routing Request）とネイバー（Mgmt LQI Request）の検出、デバイスの接続管理（Mgmt Leave および Permit Join Request）等の管理機能を実行することもできます。」
Zigbeeの設計思想に基づく「周波数アジリティ（Frequency Agility）」の管理機能は、モジュール内部に実装されており、ZDOを通じて実行できることが分かります。但し、この機能が常に自動的に動作するわけではありません。
ZDOコマンド（クラスタID：0x0038）である管理ネットワーク更新要求（Management Network Update Request）を適切に発行することで、ユーザは手動、あるいは設定に基づく半自動的な制御によって、エネルギー検出（Energy Scan）やチャネル変更を実行できます。従って、XBee3における「周波数アジリティ」は、予め完全自動で動作する機能というよりも、ZDOコマンドを活用することで実現されるネットワーク管理機能と捉えるほうが、より正確な理解であるといえます。。
図1 ZDOコマンド（0x0038）による管理ネットワーク更新要求の概念図
Figure 1 Conceptual diagram of a management network update request using the ZDO command (0x0038)
2. ZDOコマンド（クラスタID：0x0031）実施例
XBee3のZigbeeファームウェアを使用し、コーディネータ1台とルータ2台から成るネットワーク構成において、その動作を確認します。
表2 XBee3のパラメータ設定
| パラメータ | コーディネータ | ルータ1＆ルータ2 |
| CE (Device Role) | Form Network [1] | Join Network [0] |
| AP (API Enable) | API Mode Without Escape [1] | API Mode Without Escape [1] |
| AO (API Output Mode) | 0x1 | 0x1 |
コーディネータXBee3のXCTUのConsoles working modeからFrames Generator Toolを起動し、コーディネータ自身に以下のAPIフレームを送信します。
Frame typeは0x11を選択します。コーディネータの64ビットアドレスは、0x0000000000000000を入力します。16ビットアドレスは0x0000です。
Source endpointとDestination endpointはどちらも0x00に設定します。
Cluster IDを0x0038に設定します。
Profile IDを0x0000に設定します
RF data (HEX)はHEXのタブから01 00 F8 FF 07 05 01 00 00を入力します。
図2 API Frames Generatorの入力画面
（完成した送信用フレーム）
Explicit Addressing Command Frame (API 1)
7E 00 1D 11 01 00 00 00 00 00 00 00 00 00 00 00 00 00 38 00 00 00 00 01 00 F8 FF 07 05 01 00 00 B0
Start delimiter: 7E
Length: 00 1D (29)
Frame type: 11 (Explicit Addressing Command Frame)
Frame ID: 01 (1)
64-bit dest. address: 00 00 00 00 00 00 00 00
16-bit dest. address: 00 00
Source endpoint: 00
Dest. endpoint: 00
Cluster ID: 00 38
Profile ID: 00 00
Broadcast radius: 00 (0)
Transmit options: 00
RF data (HEX): 01 00 F8 FF 07 05 01 00 00
RF data (ASCII):
APIフレームが完成したら、送信を行うと以下の図のように、PCからUART経由でコーディネータにAPIフレームを返信します。
図3 コーディネータからAPIフレーム送受信画面
（受信フレーム）
Explicit RX Indicator (API 1)
7E 00 2D 91 00 13 A2 00 42 1D 75 06 00 00 00 00 80 38 00 00 01 01 00 00 F8 FF 07 02 00 00 00 10 B3 B1 B3 B5 EC B3 B3 B5 B5 B5 C6 CC C6 DB C9 EF ED
Start delimiter: 7E
Length: 00 2D (45)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 00 13 A2 00 42 1D 75 06
16-bit source address: 00 00
Source endpoint: 00
Destination endpoint: 00
Cluster ID: 80 38
Profile ID: 00 00
Receive options: 01
RF data (HEX): 01 00 00 F8 FF 07 02 00 00 00 10 B3 B1 B3 B5 EC B3 B3 B5 B5 B5 C6 CC C6 DB C9 EF
RF data (ASCII):
（受信フレームの解析）
表3 ZDOコマンド（0x0038）に対して送信されたフレームの構造
| フレーム | 説明 |
| 7E | Start delimiter |
| 00 2D | Length 00 2D = 45 bytes |
| 91 | Frame Type Explicit RX Indicator |
| 00 13 A2 00 42 1D 75 06 | コーディネータ自身の64bit Source Address |
| 00 00 | 16bit Source 00 00はコーディネータ自身 |
| 00 | APS層 Source Endpoint |
| 00 | Destination Endpoint |
| 80 38 | Cluster ID 要求0x0038に対する応答 |
| 00 00 | Profile ID ZDO |
| 01 | Receive Options ACKあり |
| 01 00 00 F8 FF 07 02 00 00 00 10 B3 B1 B3 B5 EC B3 B3 B5 B5 B5 C6 CC C6 DB C9 EF | RF Data（ZDO応答ペイロード） |
| ED | Check Sum |
さらに、以下の表にRFデータの最初の11バイトの定義と意味を示します。
表4 RFデータのヘッダー部分の構造
| フィールド | バイトサイズ | RFデータ | 意味 |
| TSN | 1 | 01 | 要求と一致 |
| Status | 1 | 00 | スキャン成功 失敗は80 |
| Scanned Channels | 4 | 00 F8 FF 07 | Little Endianで表示されているため変換すると、0x07FFF800 = CH11〜CH26を意味している。 |
| Total Transmissions | 2 | 02 00 | 内部処理回数Little Endian表示なので0x0002 = 2回 |
| Transmission Failures | 2 | 00 00 | 失敗なし |
| Energy Values | N | 10 | 残り16バイト |
以下に、RFデータの残りの16バイトは、エネルギースキャンの実施結果を表示しています。
B3 B1 B3 B5 EC B3 B3 B5 B5 B5 C6 CC C6 DB C9 EF
対応するチャネルはCH11〜CH26 = 16チャネルであり、これを16バイトで表しています。
表5 RFデータの残りの16バイトのエネルギースキャン結果
| CH | 値(hex) | 10進数 |
| 11 | B3 | 179 |
| 12 | B1 | 177 |
| 13 | B3 | 179 |
| 14 | B5 | 181 |
| 15 | EC | 236 |
| 16 | B3 | 179 |
| 17 | B3 | 179 |
| 18 | B5 | 181 |
| 19 | B5 | 181 |
| 20 | B5 | 181 |
| 21 | C6 | 198 |
| 22 | CC | 204 |
| 23 | C6 | 198 |
| 24 | DB | 219 |
| 25 | C9 | 201 |
| 26 | EF | 239 |
エネルギー値は環境ノイズの大きさであり、値が大きいほど干渉が強いことを意味しています。 今回の結果を見ると、CH15 = 0xEC = 236及びCH26 = 0xEF = 239で、かなり高い値が得られていることが分かります。
3. まとめ
今回は、ZDOコマンド（クラスタID：0x0038）である管理ネットワーク更新要求を実行し、その結果を示しました。本検証では、PCからUART経由でコーディネータに対してAPIフレームを送信し、ZDOコマンドを実行しています。取得した応答APIフレームを詳細に解析することで、エネルギースキャンの成否を確認できるだけでなく、対象となる16チャネル（CH11～CH26）それぞれのエネルギーレベル（ノイズ強度）を定量的に評価できることを明らかにしました。