検索
連載

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

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

Share
Tweet
LINE
Hatena

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ヘッダー圧縮で、マルチホップ中継した場合のアプリケーションペイロード (クリックで拡大)

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る