1. フラグメンテーション機能の仕組み

　以下にZigbeeファームウェアにおけるフラグメンテーション機能の主要な項目について説明します。

・フラグメンテーションのサポート

　Zigbeeファームウェアでは、最大255バイトのデータを含む送信フレームを送信できます。ファームウェアはこの大きなパケットを自動的に複数のRF送信にフラグメント化します。受信デバイスは、シリアルポートにデータを出力する前に、フラグメントを再構成します。

・信頼性

　送信中にフラグメントが失われた場合、メッセージ全体が破棄され、送信者に拡張送信ステータスフレーム（0x8B）を介して失敗が通知されます。

・制限事項

　フラグメンテーションはユニキャスト送信でのみサポートされ、ブロードキャストではサポートされません。ブロードキャスト送信は、最大ペイロードサイズが92バイトに制限されます。

・フロー制御

　RTS（Request To Send）フロー制御とは、シリアル通信（RS-232C）において、受信側のデータ受信準備状況に合わせてデータ送信を管理するハードウェアフロー制御の一種です。受信デバイスでRTSフロー制御が有効になっている場合、フラグメント化されたメッセージではフロー制御が無視されます。その理由は、送信側のXBee3では、一度フラグメンテーションによる一連のパケット送信が開始されると、送信側デバイスは受信側のRTS信号の状態をチェックせずに、分割されたパケットを連続して送り続けようとするからです。この機能は、XBee3モジュール用のZigbeeファームウェアでのみ使用可能であり、802.15.4またはDigiMeshファームウェアではサポートされていません。

2. フラグメンテーション機能がZigbeeのみでサポートされている理由

　フラグメンテーションがZigbeeファームウェアでのみサポートされ、802.15.4やXBee3モジュール上のDigiMeshではサポートされない理由は次のとおりです。

　Zigbeeプロトコル仕様には、単一のZigbeeフレームの最大ペイロードサイズを超えるメッセージのフラグメンテーションと再構成が組み込まれています。これはZigbeeスタックの一部であり、ファームウェアによって自動的に処理されます。つまり、Zigbeeのフラグメンテーションはプロトコルスタックによって処理されます。

　一方、802.15.4とDigiMeshに関しては、DigiMeshのベースとなっているIEEE 802.15.4規格では、MAC層またはネットワーク層におけるフラグメンテーションと再構成のメカニズムは定義されていません。また、802.15.4フレームは、最大フレームサイズ（ヘッダーとフッターを含めて127バイト）内に完全に収まる必要があります。データがこのサイズを超える場合、データのフラグメンテーションと再構成はアプリケーション層（ソフトウェア）で行われます。

　DigiMeshは802.15.4をベースとしているため、この制限を継承しており、独自のフラグメンテーションプロトコルは追加されていません。したがって、より大きなデータを送信する必要がある場合は、アプリケーションコードでフラグメンテーションと再構成を実装する必要があります。

　従って、802.15.4とDigiMeshでは、フラグメンテーションは組み込まれていないため、MicroPython等のアプリケーションで処理する必要があります。802.15.4又はDigiMeshで大きなデータを送信する必要がある場合は、データを小さなチャンクに分割し、受信側で再構成する必要があります。

3. フラグメンテーション機能とZigbee設計思想の関係

　Digi XBee3 Zigbeeファームウェアのフラグメンテーション機能は、低消費電力・低データレートネットワークにおける信頼性、拡張性、相互運用性を重視したZigbeeの設計思想に密接に合致しています。Zigbeeの設計思想の主な特徴は以下のとおりです。：

・信頼性

　Zigbeeは、ノイズの多い環境でも堅牢な通信を実現するように設計されています。フラグメンテーションは、大容量のデータペイロードを小さなパケットに分割することで、確実に送信することを保証します。各パケットは個別に確認応答し、必要に応じて再送信できます。

・相互運用性

　Zigbeeネットワークには、異なるメーカーのデバイスが使用されることがよくあります。フラグメンテーションと再構成のプロセスはZigbeeで標準化されているため、デバイス間の最大ペイロードサイズが異なっていても、より大きなメッセージを交換できます。

・リソース効率

　Zigbeeは、メモリと処理能力が限られているデバイスを対象としています。フラグメンテーションにより、これらのデバイスはフラグメントを順次処理するため、大きなバッファサイズを必要とせずに大容量のメッセージを処理できます。

・スケーラビリティ

　フラグメンテーションの実装により、Zigbeeネットワークは通信品質を損なうことなく、多様なデータサイズへの柔軟な適応を実現しました。

　信頼性の確保、相互運用性の維持、そして限られたリソースの最適化というZigbeeのコアバリューを支えるこの機能は、堅牢性が求められるIoTや産業用ソリューションにおいて不可欠な要素です。

4. 各ファームウェアの比較

　XCTUのConfigurationにおいて、NP（Maximum Number of Transmission Bytes）パラメータを確認することができます。このパラメータはRead Onlyのパラメータであり、ユーザが自由に設定することはできません。NPは1回のユニキャスト送信で送信できるペイロードサイズの最大バイト数を意味します。以下に、ZigbeeファームウェアのNPが表示されているXCTUの画面を示します。

5. Zigbeeにおけるフラグメンテーション処理

　XBee3の Zigbeeファームウェアは、単一Zigbeeフレームの最大ペイロードサイズが通常72～84バイトですが、セキュリティ設定とメッセージタイプによって異なります。Zigbeeファームウェアでは、最大ペイロードサイズを超えるユニキャストメッセージの断片化と再構成を自動的に処理します。

　APIモード又はMicroPython経由でユニキャストメッセージを送信する場合、最大255バイトのペイロードを送信できます。メッセージが単一フレームの最大RFペイロードサイズを超える場合、XBee3の Zigbeeファームウェアはメッセージを複数のフレームに断片化し、受信側で再構成してから、完全なメッセージをシリアルポートに送信します。断片が1つでも失われると、メッセージ全体が破棄され、送信側は送信失敗を示します。

　断片化はユニキャスト送信でのみサポートされます。ブロードキャスト送信は断片化されていないメッセージとして送信され、APSセキュリティは使用できません。

　単一のユニキャストパケットの最大ペイロードサイズは、暗号化とセキュリティ設定の影響を受けます。

6.　運用上の最適設定のヒント

　XBee3 モジュールにおけるZigbeeフラグメンテーション機能を利用する場合の、XBee3の最適設定方法を以下に示します。

(1)API モードの推奨

　信頼性の高い通信、特に大きなペイロードやフラグメンテーションに対処する場合は、API モード（AP=1 または AP=2）の使用が推奨されます。API モードでは、送信ステータスフレームを介して各送信のステータスを監視することが可能です。また、NP（最大 RF ペイロードバイト）パラメータに基づいて、モジュールがフラグメンテーションと再構成を自動的に処理することを保証されます。さらに、透過モードと比較して、アドレス指定、再試行、エラー処理をより適切に制御可能です。

(2)タイムアウト設定の調整

　フラグメンテーションを必要とする大きなデータを送信する場合、処理に時間がかかります。タイムアウトパラメータ（パケット化タイムアウトの RO やアプリケーションレベルのタイムアウトなど）を調整すると、早期のタイムアウトが発生することなく、メッセージ全体が正しく送受信されるようになります。これは、アプリケーションが大きなペイロードを送信した後に応答または確認応答を期待している場合に特に重要です。

まとめ

　XBee3のZigbeeファームウェアでのみサポートされているフラグメンテーション機能について詳しく解説しました。この機能は、最大単一パケットのRFペイロードサイズを超えるデータフレームを、自動的に小さなフラグメントに分割して送信する機能です。この機能の仕組みや、Zigbeeの設計思想との関係等について解説しました。