「Thread」における6LowPANの活用（後編）：IoT時代の無線規格を知る【Thread編】（5）（2/3 ページ）

ホームネットワーク向け無線規格として注目を集める「Thread」を解説する本連載。今回は、Threadにおける6LoWPANアダプテーション層が持つ機能について解説していく。

[水谷章成（Silicon Labs），EDN Japan]

6LowPANコンテキスト

　Threadネットワークでは、IPv6アドレスが全てのノードにおける通信の基本となり、IPv6ヘッダーがほとんどの無線通信上のパケットに含まれる。

　あるノードに割り当てられるIPv6アドレスは、リンクローカルやメッシュローカル、グローバルアドレスのように、いくつかのタイプを割り当てることができる。

　6LowPAN層により、無線で通信されるIPv6ヘッダーのサイズは、メッシュローカルやグローバルプレフィックスのように、ネットワークでは既知の情報を活用するなどで圧縮されている。Threadネットワークで使用されるメッシュローカルとグローバルプレフィックスはリーダーにより管理され、プレフィックスとコンテキストは1対1でマッピングするように割り当てられることで、ネットワークコンテキストも管理される。

メッシュローカルプレフィックス

　FD00:0DB8::/64

グローバルプレフィックス

　2001::/64＝>コンテキスト Id 1

　2003::/64＝>コンテキスト Id 2

　コンテキストは、長さと関連付けされたコンテキストIDを持つが、Threadネットワーク全体で必ず同調していなくてはならない。コンテキスト圧縮を用いる際の最初のステップは、リーダーがThreadネットワーク内の全てのノードへ、Threadネットワークデータを伝播（でんぱ）する手段を用いて配布することから始まる。

　このプロセスについての情報は、ホワイトペーパー「Boarder Routers」で別途紹介されている。いったん伝播が完了すると、デバイスは圧縮されたIPv6ヘッダーでパケット送信を開始し、IPHC圧縮ヘッダーのCIDフィールドを「1」にセットする。この信号は、コンテキスト拡張識別子が存在することを指し示し、IPHC DAMフィールドのすぐ後に続けられる。コンテキスト拡張識別子は、表2での説明と図4に示した構造を持つ。

表2：コンテキスト拡張識別子の構造

フィールド	定義
SCI	発信元コンテキスト識別子。IPv6の発信元アドレスに関連したプレフィックスの識別子。
DCI	宛先コンテキスト識別子。IPv6の宛先アドレスに関連したプレフィックスの識別子。

図4：コンテキスト拡張識別子 （クリックで拡大）

UDPヘッダー圧縮

　Threadにおける、UDPヘッダー圧縮はNHC（ネクストヘッダー圧縮：RFC4944）が用いられ、IPv6ヘッダーに続くネクストヘッダー圧縮は、NHCヘッダーを使って定義される。典型的な圧縮ヘッダーの構成例を図5に示す。

図5：圧縮ヘッダー （クリックで拡大）

　UDP圧縮向けのNHCヘッダーを図6と表3で紹介する。

図6：UDPヘッダーエンコーディング

表3：UDPヘッダーエンコーディングのフィールド定義

1111 0	UDPヘッダー圧縮向けのNHC ID
C	チェックサム。1ビットでUDPチェックサムがインラインで実行されたか、省略されたかを示す。
P	ポート。2ビットでUDPポートの圧縮スキームを示す。

6LowPAN IPv6パケット断片化

　これまで述べてきたように、IEEE802.15.4 MAC層が用意するペイロード長は最悪の場合、88バイトになる。IPv6でサポートする必要があるMTUが、1280バイトであることを考慮すると、断片化と再構築のメカニズムが必要である。

　また、実用的なアプリケーションの観点からも、802.15.4の単一パケットで送ることのできる残されたペイロードサイズは非常に小さい。例えば、UDPをトランスポート層に使った場合、実効的なアプリケーション層のペイロードは以下のようになる。

　MACペイロード（88バイト）−IPv6ヘッダー（40バイト）− UDPヘッダー（8バイト）＝40バイト

　RFC6282に記述されているヘッダー圧縮技術を使うことでアプリケーション層ペイロードに使えるバイト数を増やせる。それでも、図7に示すように80バイトだけである。

図7：IPv6ヘッダー圧縮で、マルチホップ中継した場合のアプリケーションペイロード （クリックで拡大）