Wi-Fiメッシュで通信コストを最小化する仕組み、「IEEE 802.11s」の採用技術

「IEEE 802.11s」の無線メトリック値

　前回までのルーティングプロトコルに続いて、IEEE 802.11sの仕様について解説していこう。

　Wi-Fi Meshにおいて、実際に通信を行うための経路を計算する場合には、そのための無線のメトリック値が必要になる。このメトリックは、要するに「通信のコスト」を算出するもので、これに基づいて経路が“通信のコストを最小化する”ように決められる。

　以下の図はRM-AODVの場合の算出方法だが、要するに経路ごとに通信コストを算出し、これをベースにメトリック値を設定。その結果として経路を決めることになる。この通信コストの算出であるが、最終的にIEEE 802.11sで採用されたのは、以下の方式だ。

　　 Ca = [ O + Bt / r ] / ( 1 - ef )

　　Ca：メトリック値
　　O ：チャネルアクセスオーバーヘッド。この値はPHY自身が保有するため、PHYベンダーには適切な値を返すことが求められる
　　Bt：8192（テストフレームのbitサイズ）
　　r ：データレート（Mbit/sec）
　　ef：フレームエラーレート（Btのサイズのフレームを送信した際のエラーレート）

　数式の各項目は以上のようになっている。要するに、あらかじめ送受信の速度とエラーレートを計測し、これを基にメトリック値が決まるかたちだ。

RA-OLSRでは、MPPがすべての経路のコストをまとめて取得することで、最適なツリーをあらかじめ構築する。出典は「NTT Docomoテクニカルジャーナル VOL.14 No.2」の"IEEE802.11s無線LANメッシュネットワーク技術"

　速度やエラーレートは、環境とか相手のスペックなどでダイナミックに変わる可能性があるから、RA-OLSRとは逆に、毎回通信にあたって経路を定めるRM-AODVが手ごろということになる。

また、距離が長いほど、実効速度が落ちてエラーレートが上がりやすく（rが減り、efが増える）なっていき、その分メトリック値は増大しやすくなることから、なるべく短い経路でつなぐ方向になりやすい、というわけだ。

ルーティング時のフレームフォーマット

　それから、ルーティングを行う際のフレームフォーマットについても簡単に説明しておこう。IEEE 802.11sでは、以下の図のように、基本的に6 Addressの拡張が施される。通常のMACアドレスだと、Linkの両端とEnd-to-Endの2組4つのAddressがあれば足りるわけだが、Meshの経路はMulti-Hopになるため、Meshの両端のAddressを格納することで、ルーティングできるようにするわけだ。

ちなみに基本的なMACフレームは4つまでしかAddressを格納できないため、Address 5/6はMesh拡張フレームに格納される。以降はすべて2006年11月に開催されたIEEE 802 Plenary Sessionにおける「IEEE 802.11s Tutorial」のスライド（PDF）

　以下の左が、間にMPP/MP/MAPを挟んでエンドポイント（クライアント）同士で通信する例、右がMP同士の通信の例となる。ただ、これはあくまでもMeshのルーティング中だけ6 Addressに拡張されるという意味で、エンドポイントから見ると、通常のMACフレームと扱えることになる。

RM-AODVを利用する例。Meshの中ではSourceがMAP1、DestinationがMPPとなり、Meshを抜ける時点でこれが消えるかたちとなる

こちらはRA-OLSRの例。Rootを経由した時点でMeshから抜け、その先は経路表がすでにできていて探索の必要がないため、Root→MP3の時点で4 Addressになる

MAC層での拡張"Mesh Medium Access Coordination"の詳細

　MAC層には、前回も書いた"Mesh Medium Access Coordination"と呼ばれる拡張が施されている。具体的には「MDA（Mesh Deterministic Access：予約ベースの判断メカニズム）」、「CCF（Common Channel Framework：マルチチャネルオペレーション）」、「Intra-mesh Congestion Control（混雑状態の監視とレートコントロール）」、「Power Management」などだ。

　まずMDAについて。“Deterministic”というと分かりにくいが、要するに特定のデバイスに割り当てるTimeslotを用意する、という仕組みだ。

CANとかFlexRayなどでは一般的だし、広義にはUSBのIsochronousもこうした方式であり、その意味では別に珍しくはない

　Wi-Fiでは、原則として早い者勝ちで通信が行われるわけだが、Meshの場合は結果的に、Meshに属するすべてのデバイスが一定期間ごとに確実に通信を行うわけで、あるデバイス（STA/MP/MPA/MPP）が優先的に通信時間を独占すると、そもそもMeshが機能しない。またMesh内のデバイス同士で通信時間の奪い合いになりコリジョンが多発すると、実効通信性能が落ちることになる。

　そこで各デバイスに対して、占有できる時間を均等に割り当てることで、コリジョンを抑えつつ通信時間を確保し、Mesh全体でのスループットを向上する仕組みがMDAと言える。

　CCFは、複数のチャネルを使って効率的に通信を行う仕組みだ。Common ChannelではRTX/CTXのやり取りに加え、空いていればデータの転送も可能だが、以下の左で図示されている混雑時には、ほかのチャネルでデータとACKの転送を行うことが可能となる。

送受信の制御（RTX/CTX）はf0を、1つ目のデータ転送はf1を、2つ目のデータはf2を、というように、同時に複数チャネルを利用することで、効果的に通信を行う仕組み

ここでの設計目標は、基本的にRTX/CTXを利用したシンプルなものにとどめ、またIEEE 802.11eで実装された方式である「EDCA（Enhanced Distributed Channel Access）」を再利用することを念頭に置いたもの、と説明されている

　Intra-mesh Congestion Controlは、言わば原始的なQoSである。例えば以下の左図のような構図のMeshがあったとして、3⇔5、4⇔5、5⇔6の間は帯域が小さいことが分かっている。こうなると、1→6とか2→7、7→3といったFlowは、帯域の小さいところがボトルネックになりやすい。そこで、それぞれのノードは常に帯域の利用率を監視し、渋滞が発生したらそれを近傍に通知することで、各ノード自身が帯域を絞り込むという仕組みである。

あえて1⇔5の帯域を太いと仮定したのは、これも細いとNode 5自体がボトルネックとなるのが明白なため、排除すべきという議論になりかねないからだろうか

渋滞が発生したら優先順位の高いパケットのみを流す、といったところまでは踏み込んでおらず、全体のスループットを絞るというかたちでの制御とされる

　Power Managementについては、「ATIM（Announcement Traffic Indication Message）」ベースのものだ。要するに、定期的にBeaconを発信し、そこから一定期間（ATIM window）待機して、ここで何も通信がなければ次のBeaconのタイミングまで休止するという仕組みだ。

　Beaconの間隔であるDTIM Intervalが短すぎると省電力の効果が薄れるし、長すぎるとスループットに影響が出かねない。このあたりはATIM windowの期間をうまく調整することで、性能に大きな影響を与えずに待機中の消費電力を減らせるとされている。

もともとは、「BSS/IBSS（Basic Service Set/Independent Basic Service Set）」と呼ばれるWi-Fiの基本的な仕組みを再利用し、そこにATIMという概念を追加したようなかたちで実装される

　ほかにも、すべてのノードで時間の同期を取る“Synchronization”なども盛り込まれているが、主なIEEE 802.11sの特徴はおおむねこんなところだ。

　ZigBeeやThreadなどのMesh Networkをご存知の方はお分かりかと思うが、実は基本的な構成はほとんど同じである。もちろん既存のIEEE 802.11との互換性を維持するために、特にフレーム構造などは無駄に冗長な感はあり、ZigBeeとかと比べると無駄にフィールドが多い気はするが、これは致し方ないところだ。

　説明は省くが、新規に出現したノードをMeshに組み込む“Discovery”などの手順も、ZigBeeなどに非常に良く似ている。もっとも、そもそもMesh Networkを構築するとなると、そう多くの手段があるわけではないし、ZigBeeといってもPHY/MAC層はIEEE 802.15.4として標準化されている規格だから、これを流用することには何の問題もないわけで、必然的に似てくるのも無理もない。

　逆に言えば、そもそも問題になりそうなポイントはほとんどないはずなのに、スポンサー投票に5回を要した理由がさっぱり分からないのだ。ただ、すでにP802.11sTGのウェブページからは、意外なことに議事録その他のリンクがすべてなくなっており、何が起きていたのかは正直分からない。とにかく2012年末に標準化は終わったわけだ。