Last Update: 2026-09-30

IEEE 802.11 MAC の基礎¶

IEEE 802.11 MAC architecture¶

IEEE Std 802.11-2020 - Figure 10-1—Non-DMG non-CMMG non-S1G STA MAC architecture (p.1630) に、Wi-Fi 通信における MAC アーキテクチャの図が書かれてる。下の図は、 Figure 10-1 を元に作成した図。

また、MAC 副層では DCF・HCF・MCF が定義されており、QoS 機能をサポートする Wi-Fi 機器 では HCF の実装が必須であり、メッシュ Wi-Fi 機器では MCF の実装が必須であることも示されている。

HCFは、DCFの機能とQoSに特化した拡張機能やフレームサブタイプを組み合わせることで、QoSデータ転送に対して一貫したフレーム交換シーケンスを利用できるようにしている。 HCFは、 競合ベースの転送では競合ベースのチャンネルアクセス方式であるEDCAを使い、競合がない転送ではコントロールされたチャンネルアクセス方式であるHCCAを使う。 （HCCAを実装してるベンダーはないそう）

QoS 機能は Wi-Fi Multimedia (WMM) により実装されることがほとんどで、 WMM では Enhanced Distributed Channel Access（EDCA）のみを使う。

例えば、スマホとアクセスポイントの間で使うWi-Fi 通信(メッシュWi-FiとかWiGigとかWi-Fi HaLowとか除く)の MAC 副層では DCF と EDCA を使ってる。

ちなみに、Wi-Fi CERTIFIED n の認証を受けるには、WMM の認証にも通らないといけない。（= 最近のWi-Fiなら、DCF + EDCA(というかWMM)で動くのが普通のはず）

CSMA/CA¶

IEEE Std 802.11-2020 - 10.2.2 では、WiGig を除くすべての Wi-Fi 機器に DCF として Carrier Sense Multiple Access with Collision Avoidance（CSMA/CA）の実装が必須って書かれてる。

CSMA/CA の主要な構成要素は 4 つ。

• Physical Carrier Sense（Physical CS）
• Virtual Carrier Sense（Virtual CS）
• Interframe Space（IFS）
• Random Backoff

Physical CS, Virtual CS: 送信しようとするSTAは、他のSTAが送信中かどうかを知るために、Mediumを感知しなければならない。

IFS: 送信しようとするSTAは、送信の前に必要な時間分だけMediumがIDLEであることを検証しなければならない。もしMediumがBUSYだと判断したら、今この瞬間の送信が終わるまで遅延しなければならない。

Random Backoff: 遅延の後、もしくは送信成功後に再度送信を試行する前に、STAはbackoffカウンターを初期化しなければならない。さらにbackoffカウンターは、MediumがIDLEの間にaSlotTimeの間隔に1回だけ減らさなければならない。

Physical CS¶

Physical CS は、無線媒体の状態を PHY 層で判定するための仕組みで、フレームの送受信を行なって いないすべての Wi-Fi 機器によって常に実行される。Physical CS の目的は、フレームを送信する前に 無線媒体が BUSY かどうかを判定して、その結果を MAC 副層に渡すこと、及びフレームを 受信するために必要となる同期を行うこと。

めちゃくちゃ単純に言うと、他に電波を出してる機器があるかないかで BUSY / IDLE を判定して、 MAC 副層にその結果を渡すだけ。 Wi-Fi フレームを送信しようとしてるなら、 IDLE である（周りに同じ周波数で電波を出してる機器がない）ことが大前提。

Physical CS は常に行われてるけど、常に感知しようとしても、性能的には 4μs ごとでしか検知できないらしい。 Clear Channel Assessment（CCA）での signal detect と energy detect の判定に、それぐらいの時間が かかるので。

Virtual CS¶

Virtual CS では Network Allocation Vector（NAV）が使われる。Wi-Fi 機器の NAV にはタイマーと なる値がセットされて、その値が 0 になるまでは無線媒体が BUSY だと判定する。NAV にセット される値は、無線媒体が BUSY となる時間をフレームの送信者が計算した値で、MAC ヘッダーの Duration フィールドに示される。

NAVはすべてのMACで提供されなければならない。

NAVは、実際にデータをやり取りする前にSTAのRTS/CTS frameのDuration情報に基づいた将来のトラフィック予測を保持する。Duration情報はすべてのフレームのMACヘッダーからも参照できる。

Durationの値は、例えば SIFS + Ack frameにかかる時間(μs) となってる。

もし Wi-Fi フレームが自身宛てだったら、 Duration フィールドは無視して NAV にセットしない。

自分宛ならNAVをUpdateしてはいけない、自分宛以外でNAVが自分が持っている値より大きいなら、Updateしなければいけない。

Physical CS 又は Virtual CS のどちらか片方でも BUSY と判定した場合に無線媒体は BUSY として扱われ、共に IDLE だと判定した場合にのみ無線媒体は IDLE として扱われる。

IFS¶

IFS は Wi-Fi フレームと Wi-Fi フレームとの間の時間間隔のこと。 Wi-Fi 機器は Physical CS と Virtual CS を使って、 Wi-Fi フレーム送信前に IFS の時間だけ無線媒体が IDLE であることを確かめなきゃいけない。IEEE Std 802.11-2020 では 10 種類の IFS が定義されている。

各IFSの計算式

• SIFS = aSIFSTime
• RIFS = 2μs
• PIFS = SIFS + slot time
• DIFS = SIFS + 2 x slot time
• EIFS = SIFS + AckTXTime + DIFS
• AIFS = AIFSN(AC) x slot time + SIFS

IEEE 802.11ac (WI-Fi 5)を前提にすると、

• Short Interframe Space（SIFS）: 16μs - Ack フレームや BlockAck フレームを送信する前
• DCF Interframe Space（DIFS）: 34μs - Data フレームを送信する前

など、規格により各 IFS の値が定められている。 SIFS の値は PHY ごとに定められていて、5 GHz バンドなら 16μs 。 DIFS は SIFS + スロットタイム × 2 なので、5 GHz バンドなら 16 + 9 × 2 = 34μs になる。

具体的なSIFSとslot timeの数値は各PHYで決まってる。VHTだとどうなのか見てみる; Table 21-28には書かれていないので、Table 19-25(HT PHY)の値と同じ。

(IEEE Std 802.11-2020 - Table 19-25—HT PHY characteristics, p.2951 ※一部省略あり)

上に示したパケットキャプチャの画像にある Duration フィールドの値: 48μs は、SIFS と Ack フレームの 送信にかかる時間の合計を QoS Data フレームの送信者が計算した値。

下の画像は EAPOL の 4-way handshake をキャプチャしたもので、Data フレームと、それに対する Ack フレームが交互に並んでる。

Data フレームと Ack フレームの時間差は 22μs・25μs・28μs・29μs とばらついていて、SIFS の 16μs ぴったりにはならない。キャプチャのタイムスタンプの精度とか電波状況の影響を受けるから。 ただ、どれも DIFS の 34μs より短い。もし Ack フレームが DIFS + Random Backoff を待ってから 送信されてるなら、フレームとフレームの間隔が 34μs より短くなることはない。 つまり、Ack フレームが SIFS の後に送信されてることは、このキャプチャからも分かる。

Random Backoff¶

Random Backoff はランダムに決まる待機時間。Contention Window（CW）の範囲（0〜CW）からランダムに選ばれた整数値と各 PHY 層で定められたスロットタイム を掛けた値。

Data フレームか Management フレームを送信する前に実行されるので、 Control フレーム(Ack フレームとか)は対象外。IFS と同じで Physical CS と Virtual CS を使って、Random Backoff の間、無線媒体が IDLE であることを確かめなきゃいけない。IFS が終了した後に Random Backoff を実行することで、同じ種類のフレームを送信しようとする複数の Wi-Fi 機器が同時にフレームを送信する可能性が下がるので、フレームの衝突(Collision)が発生する確率も下がる。

IEEE 802.11ac なら、スロットタイムは 9μs で、フレーム送信が初回であれば CW は 15（CWmin）。 CW はフレームの再送ごとに増加していくけど、1023（CWmax）が最大値。 どれも上に載せた Table 19-25 の値。(IEEE Std 802.11-2020 - Table 19-25, p.2951)

CWの値は、フレームの送信が成功したり、再送回数の上限まで再送したら初期化される。

backoff procedureを実行してるSTAは、backoff slotの間CSをしてMediumがBUSYかどうか判断する。 もしその間IDLEだったなら、backoff counterを減らす。

backoff counterが0になったら送信を始めなければいけない。

backoff procedureによって複数のSTAがrandom backoffする → 最小のbackoff countを使うSTAが競合に勝つ。 （隠れ端末問題があるので必ずそうとも限らないけど）

backoff counterの値は保持できて、再度IDLEになったら続きから値を減らせる。

Ackが必要なフレームを送信した後は、Ackの手順に従わないといけない。 MACフレーム(MPDU)の送信失敗ごとに、Data/ManagementフレームでかつRTSThreshold以下の長さのフレームならSRCを増加しないといけない。 再送フレームなら、Retryサブフィールドを"1"にセットしないといけない。 フレームの再送は、dot11ShortRetryLimit か dot11MaxTransmitMSDULifetime まで続く。

再送されたフレームでは、MAC ヘッダーの Frame Control フィールドにある Retry サブフィールドが "1" になっている。再送してもフレームに割り当てられた Sequence number は変わらないので、 元のフレームと同じ値（この画像だと 1）が入る。

dot11ShortRetryLimit のデフォルト値は 7 。ちなみに、 dot11LongRetryLimit のデフォルト値は 4; Long か Short の違いは dot11RTSThreshold を超えるかどうかで決まるみたい。

dot11ShortRetryLimit OBJECT-TYPE
    SYNTAX Unsigned32 (1..65535)
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
        "This is a control variable.
        It is written by an external management entity.
        Changes take effect as soon as practical in the implementation.
        This attribute indicates the maximum number of transmission attempts of a
       frame that are made before a failure condition is indicated." 
    DEFVAL { 7 }
    ::= { dot11OperationEntry 3 }

dot11LongRetryLimit OBJECT-TYPE
    SYNTAX Unsigned32 (1..255)
    MAX-ACCESS read-write
    STATUS deprecated
    DESCRIPTION
        "Deprecated as the related feature has been removed from IEEE Std 802.11.
        This is a control variable.
        It is written by an external management entity.
        Changes take effect as soon as practical in the implementation.
        This attribute indicates the maximum number of transmission attempts of a
        frame, in a PSDU of length that is greater than dot11RTSThreshold, that is
        made before a failure condition is indicated." 
    DEFVAL { 4 }
    ::= { dot11OperationEntry 4 }

EDCA, WMM¶

EDCA¶

Wi-Fi 通信に QoS 機能を導入するために、IEEE Std 802.11e-2005 において EDCA が定義された。 IEEE Std 802.11-2020 - 10.23.2 では、4 つの独立した Enhanced Distributed Channel Access Functions（EDCAFs）を DCF に追加したものが EDCA であるって書かれてる。なので、基本は DCF で QoS の部分を 追加したのが EDCA 。

優先順位で4つに分けるっていう部分がDCFとの大きな違い。

EDCA では、上位層から受け取った MAC Service Data Unit（MSDU）が User Priority（UP）の値をもとに 4 つの Access Category（AC）にマッピングされ、各 AC に対応したそれぞれの EDCAF が無線媒体の競合に使われる。

UP の値は、QoS Data フレームの QoS Control フィールドにある TID として示される。

この QoS Data フレームは TID が 0 なので、AC_BE にマッピングされる。 Wireshark は TID に対応する UP も表示してくれる。

EDCA では Transmit Opportunity（TXOP）も導入されていて、CSMA/CA のように Wi-Fi フレーム 1 つの送信権を 与えられるのではなくて、無線媒体を占有できる一定時間が付与される場合がある。 TXOP の間は、SIFS を挟みつつ複数のフレームを連続して送信できる。

各ACごとで、EDCAFがTXOPを勝ち取るために競合する。

WMM¶

Wi-Fi Multimedia (WMM) は、IEEE Std 802.11e-2005 で定義された機能の一部に基づいた、Wi-Fi 通信における QoS 機能の実装規格。 HCF として EDCA のみを使う。
→ 802.11eでは、実装されることがないいろんな技術・機能が規定されているけど、Wi-FiにQoS自体は実装するべきで、そのために802.11eのいいとこだけを取ってWMMが規格化された。

WMM Parameters¶

AC ごとにデフォルト WMM パラメーターとして CWmin・CWmax・TXOP Limit・Arbitration Inter Frame Spacing Number（AIFSN）の値を定めてて、 AC_VO・AC_VI・AC_BE・AC_BK の順でフレーム送信が優先されるにとなってる。下の表は、 WMM Specification p.24 で示されてるデフォルト WMM パラメーター。

aCW_min と aCW_max の値は、VHT PHY 仕様を見ても載ってなくて、HT PHY と同じ値。 (IEEE Std 802.11-2020 - Table 19-25—HT PHY characteristics, p.2951 ※一部省略あり)

表の値はあくまでデフォルト値で、アクセスポイントによっては変更できることもある。 実際に使用する WMM パラメーターは、Wi-Fi 接続時のネゴシエーションにより決定されて、 WMM アソシエーションが確立することによって、互いに QoS Data フレームを送信できるようになる。

アクセスポイントは、Beacon フレームの WMM Parameter Element で実際に使う WMM パラメーターを 通知してる。

ECWmin・ECWmax は指数で示されていて、CW = 2^ECW - 1 の関係。ECWmin/max が 4/10 なら CWmin/max は 15/1023 で、Wireshark が括弧の中に換算後の値も出してくれてる。

CWmin = 2^(ECWmin) – 1
CWmax = 2^(ECWmax) – 1

TXOP Limit の単位は 32μs なので、AC_VI の TXOP 94 は 94 × 32μs = 3.008ms、 AC_VO の TXOP 47 は 47 × 32μs = 1.504ms 。

このアクセスポイントは、上の表のデフォルト値（TXOP Limit は 802.11a/g の列）どおりの値を使ってた。

AC parameter set count は、WMM parameter が変わるたびに 1 ずつ足される。

STA は Beacon の WMM Parameter Element で通知される WMM Parameters をモニターして、変化に応じて 自分の値をアップデートしないといけない。association 前の段階では、これらの値を Table 13 の デフォルト値にセットしないといけない。

その後は、Probe Response フレーム・Association Response フレーム・アソシエーションしてる AP の Beacon フレームから受け取った WMM Parameters でアップデートしないといけない。 無線媒体にアクセスするときに現時点の WMM Parameters を使うことは、STA の義務。

AP は、advertise してる値とは違う値を使うことができる。AP が使う推奨のデフォルト値は Table 15 に あって、AP の場合は AIFSN が 1 以上でないといけない。

なので、AP 自身は Table 15 の値を使って、STA に通知するのは Table 13 の値、というのが推奨。

(Wi-Fi Multimedia™ Technical Specification Version 1.2.0 - Table 15 Default EDCA Parameters for the AP)

Table 13 と比べると、AC_BE の CW_max が広がってて、AC_VI と AC_VO の AIFSN が 2 から 1 に なってる。AP の方が待ち時間が短くて、フレームを送信しやすい値。

AP が自分を優先するのは、無線媒体を流れるフレームは AP からクライアント宛てのものが一番多いから。

QoS の情報がない Data フレームは Best Effort として扱われる。Management フレームには QoS Control フィールドがないけど、AC_VO のパラメーターで送信するべきとされてる。

WMM Association¶

Frame Format¶

WMM だけに対応してる AP や STA は、Association・Beacon・Probe Response フレームの Capability Information フィールドにある QoS ビットをセットしない。かわりに、WMM Information Element が この規格で新しく定義されていて、それらのフレームで運ばれる。

Aruba の AP も Buffalo の無線 LAN ルーターも QoS ビットは 0 （デフォルト; 変更できるかは不明）。

実際のフレーム

Beacon フレームと Probe Response フレームの WMM Parameter Element フィールドの中で、 QoS でどんなパラメーターを使うか伝えてる。

実際のフレーム

(Wi-Fi Multimedia™ Technical Specification Version 1.2.0 - Table 5 WMM Parameter Element Field Values)

Association Request フレームの WMM Information Element フィールドで、STA 自身が WMM を サポートしていることを伝える。

(Wi-Fi Multimedia™ Technical Specification Version 1.2.0 - Table 3 WMM Information Element Field Values)

QoS Info field の中身は、WMM AP から送信されるときと WMM STA から送信されるときで違う。

(Wi-Fi Multimedia™ Technical Specification Version 1.2.0 - Figure 6 QoS Info field when sent from WMM AP)

(Wi-Fi Multimedia™ Technical Specification Version 1.2.0 - Figure 7 QoS Info field when sent from WMM STA)

実際のフレーム

Negotiation¶

• Beacon フレーム: WMM が使える AP は WMM Information Element フィールド or WMM Parameter Element フィールドを追加しないといけない

  Wi-Fi Multimedia™ Technical Specification Version 1.2.0, p.16

  Every beacon frame transmitted by a WMM-enabled AP shall contain, in addition to those elements specified in [1], either a WMM Information Element or a WMM Parameter Element.

  ※ [1]: ISO/IEC 8802-11:1999(E) ANSI/IEEE Std 802.11, 1999 Reaffirmed 2003 edition

• Probe Request フレーム: 変更なし

  Wi-Fi Multimedia™ Technical Specification Version 1.2.0, p.16

  Probe request frames transmitted by a WMM-enabled STA are unchanged from [1].

• Probe Response フレーム: WMM が使える AP は WMM Parameter Element フィールドを追加しないといけない

  Wi-Fi Multimedia™ Technical Specification Version 1.2.0, p.16

  A probe response frame transmitted by a WMM-enabled AP shall contain a WMM Parameter Element.

• Association Request フレーム: WMM を使う STA は WMM Information Element フィールドを追加しないといけない

  Wi-Fi Multimedia™ Technical Specification Version 1.2.0, p.17

  A WMM association request frame contains a WMM Information Element in addition to the information elements specified in [1].

• Association Response フレーム: Association Request フレームに WMM Information Element フィールドがあったなら WMM Parameter Element フィールドを追加しないといけない。逆に Association Request フレームに WMM Information Element フィールドがなかったなら WMM Parameter Element フィールドを追加してはいけない

  Wi-Fi Multimedia™ Technical Specification Version 1.2.0, p.17

  An association response frame shall contain a WMM Parameter Element in addition to the information specified elements in [1] if the corresponding association request contained a WMM Information element and shall not contain a WMM Parameter Element if the corresponding association request did NOT contain a WMM Information element.

  原文のミスと修正

  原文（2.2.7 Association Response Frame）には 2 箇所ミスがある。 [1] の位置が Error! Reference source not found. になってるのと、 association request が ssociation request になってるところ。 前者は他の節が全部 [1] なのでそう推測して、後者は誤字として直した。 the information specified elements の語順は原文のまま

WMM をサポートする AP は、WMM Information Element or WMM Parameter Element を Beacon に 含めないといけない。Probe Response には、WMM Parameter Element を含めないといけない。

Association Request に WMM Information Element が含められていたら、AP が Association Response を 返すときに WMM Parameter Element を含めてなければいけない、かつ WMM association として 扱わなければいけない。

WMM association をした STA 宛てに Data フレームを送信するときは、AP は (WMM) QoS Data フレームを 使わないといけない。WMM association じゃないなら、QoS Data フレームを使ってはいけない。

WMM に対応してる STA は、Association Request を送信する前に、Beacon とか Probe Response に よって、AP が WMM に対応しているかを特定しないといけない。最も新しい Probe Response や Beacon によって特定しないといけない。

AP が WMM に対応してると特定できたなら、STA は Association Request に WMM Information Element を 含めないといけない。かつ Association Response に WMM Parameter Element が含まれてたら WMM association として扱わないといけない。

Frame Aggregation¶

IEEE Std 802.11n-2009 でフレームアグリゲーション機能として、Aggregate MAC Service Data Unit （A-MSDU）と Aggregate MAC Protocol Data Unit（A-MPDU）が導入された。 どっちも TXOP を使うのが前提で、Wi-Fi 5（IEEE 802.11ac）以降の規格でもサポートされてる。

ちなみに、IEEE Std 802.11-2020 - 10.23.2.9 では、TXOP Limit が 0 でも A-MSDU か A-MPDU が 1 つなら送信できるって書かれてる。

A-MSDU¶

A-MSDU ( Aggregate MAC Service Data Unit )は、複数の MSDU を結合して 1 つの MAC Protocol Data Unit（MPDU）に含めることでフレーム送信のオーバーヘッドを減らす。 1つのMACヘッダーとFCSに対して複数のFrame bodyが入ってるイメージで。 1回のMACフレーム送信で多くのデータを送信できるから、オーバーヘッドを削減できるのがメリット。 弱点は、再送になったときに全部を再送しないといけないこと。

MSDU を結合するには、すべての MSDU が下の 3 つを満たしてないといけない。

• 同一の AC
• 同一の RA
• 同一の Transmitter Address（TA）

A-MSDU では複数の MSDU に対して 1 つの MAC ヘッダーと FCS が追加されるので、 FCS エラーが発生したら A-MSDU 全体を再送しなきゃいけない。 ACK として必要になるのは通常の Ack フレーム。

Format¶

IEEE Std 802.11-2020 では、A-MSDU の Format が下図のように定義されてる。 Padding は、A-MSDU サブフレームが "4 の倍数" bytes になるように調整するためのもの。

Frame body に A-MSDU subframes が入る。

A-MSDU は、A-MSDU サブフレームが連続したもの。A-MSDU サブフレームは、 A-MSDU サブフレームヘッダー + MSDU + パディングで構成される。

Basic A-MSDU サブフレームでは、(最後を除く) それぞれの A-MSDU サブフレームは 4 バイトの倍数に なるようにパディングが追加される。最後の A-MSDU サブフレームにはパディングは追加されない。

A-MSDU サブフレームヘッダーには、DA・SA・Length（MSDU の長さ）の 3 つのフィールドがある。

A-MSDU は、DA と SA の値が同じ RA と TA の値に対応する MSDU だけを含む。 ほぼ、DA = RA かつ SA = TA のときだけ、と考えてもいいかも。

A-MSDU の構造は、1 つの MPDU (= MAC フレーム) の Frame body の中に含められる。 もし暗号化されてたら、MPDU は 1 つのユニットとして暗号化される。

下の画像は、ns-3 のシミュレーション（BE_MaxAmsduSize = 7935）で取得した QoS Data フレームの A-MSDU 部分。UDP ペイロード 1472 bytes の MSDU が 5 つ結合されてる。

A-MSDU サブフレームごとに DA・SA・A-MSDU Length の 3 つのフィールドがある。 このフレームの RA は 00:00:00:00:00:01 で TA は 00:00:00:00:00:0a なので、 5 つとも DA = RA かつ SA = TA になってる。

Max Length¶

VHT だと、最大 A-MSDU サイズは直接的には決められてなくて、MPDU サイズによって間接的に制限される。 (IEEE Std 802.11-2020 - p.786)

MPDU サイズは Table 9-271 で決められてる。(IEEE Std 802.11-2020 - p.1277)

VHT Capability Information フィールド

ノーマル Ack ポリシーの QoS Data フレームの中に A-MSDU が含められてた場合、 VHT STA は A-MSDU を Single MPDU として受信できなきゃいけない。

Block Ack の合意のもとだと、QoS Data フレームの中の A-MSDU の扱いは、それぞれの合意によって決まる。 受信者が A-MSDU を使えるってことを示してなかったら、STA は A-MSDU を送信してはいけない。

受信者が送信してきた HT Capabilities element の中の Max A-MSDU Length を超えた長さの A-MSDU を 送信してはいけない。

VHT Capabilities element で Max MPDU Length を 7991 か 11454 にセットしてる VHT STA は、 HT Capabilities element では Max A-MSDU Length を 7935 にセットしないといけない。

HT Capabilities Info フィールド

受信側 STA の Max MPDU サイズによって、VHT PPDU 内の A-MSDU の長さは制限される。

VHT STA は、受信側 STA から送信された Extended Capabilities element にある Max Number Of MSDUs の 値を超えた数の MSDU を含む A-MSDU を送信してはいけない。

A-MPDU¶

A-MPDU (Aggregate MAC Protocol Data Unit) は、複数の MPDU を結合して 1 つの PPDU に含めることでフレーム送信のオーバーヘッドを減らす。

MPDU を結合するには、すべての MPDU が下の 2 つを満たしてないといけない。

• 同一の AC
• 同一の RA

A-MPDU では MPDU ごとに MAC ヘッダーと FCS が追加されるので、オーバーヘッドの削減効果は A-MSDU より小さい。そのかわり、FCS エラーが発生しても該当の MPDU だけが再送される。 ACK として必要になるのは BlockAck フレーム。

下の画像は、ns-3 のシミュレーション（BE_MaxAmpduSize = 1048575）で取得したパケットキャプチャ。 16 個の MPDU が 1 つの A-MPDU として送信されて、それに対する BlockAck フレームが 1 つだけ 返ってきてる。

A-MPDU は受信側で分解されてから Wireshark に渡されるので、A-MPDU 全体が 1 つのフレームとして 表示されることはなくて、MPDU ごとに独立したフレームとして表示される。 MPDU Delimiter や EOF Padding もキャプチャには残らない。 同じ A-MPDU に属していたことは、Radiotap ヘッダーの A-MPDU status でわかる。

A-MPDU reference number が同じ値（この画像だと 96）の MPDU が、1 つの A-MPDU として送信された MPDU 。最後の MPDU だけ "This is the last subframe of this A-MPDU" が True になってて、 上の画像の 565〜579 番目のフレームは False 、580 番目のフレームだけが True になってる。

ちなみに、A-MPDU の送信が終わってから BlockAck フレームが送信されるまでの時間差は 2.049649 − 2.049633 = 16μs で、SIFS ちょうどの値になってる。

Format¶

下図は、IEEE Std 802.11-2020 の Figure 9-971〜974 で定義されてるフォーマットを合体させたもの。

A-MPDU subframe フィールド内にある Padding サブフィールドは、A-MPDU subframe を "4 の倍数" バイトにするためにある。

MPDU Delimiter サブフィールドは、A-MPDU 内で MPDU がどこに位置するかを示すためにある。復元できるように。

EOF Padding Subframes サブフィールドは、MPDU が空っぽで MPDU Delimiter 内の EOF フィールドが "1" の A-MPDU subframe と同じ。

EOF Padding フィールドが存在する目的は、PHY 層に渡すときに PSDU_LENGTH に適合させるためっぽい。

Max Length¶

VHT PPDU の A-MPDU の最大値は 1,048,575 bytes、HT PPDU の A-MPDU の最大値は 65,535 bytes。

VHT Capability Information フィールドでは、指数の値で示される。(IEEE Std 802.11-2020 - p.1279)

VHT Capability Information フィールド

STA は A-MPDU の最大値を HT / VHT Capabilities element で示す。

VHT STA が A-MPDU の最大値として 0〜3 の値を設定したいときは、VHT Capabilities element でも HT Capabilities element でも同じ値にしなきゃいけない。3 より大きい値を設定したいときは、 VHT Capabilities element ではその値にして、HT Capabilities element では 3 にしなきゃいけない。

STA は、HT Capabilities element と VHT Capabilities element の Maximum A-MPDU Length Exponent フィールドを使って、自分宛てに送信してもいい A-MPDU pre-EOF padding の最大長を アソシエーションのときに確定させる。

VHT STA は、VHT Capabilities element で設定した最大値の A-MPDU を受信できなきゃいけない。

STA は、受信者の HT / VHT Capabilities element で設定された最大値を超える A-MPDU を送信してはいけない。

Block Ack¶

複数のフレームにまとめてAckを送信できるのが Block Ack 。TXOP の間に送信された複数のフレームや A-MPDU に対する ACK は、BlockAck フレームとしてまとめて送信できる。

通常の ACK だとフレームごとに SIFS と Ack フレームの送信が必要となるけど、 Block Ack では複数のフレームに対して SIFS と BlockAck フレーム 1 つの送信となる。 なので、EDCA では TXOP によるフレーム送信の効率化だけではなく、Block Ack による ACK の効率化も実現されている。

BlockAck フレームの送信前に使われる IFS も、通常の Ack フレームと同じで SIFS 。

Block Ack Agreement¶

frame burst とか A-MPDU で複数の QoS Data フレームを送信して Block Ack を要求する前に、Management フレームの 1 種の Action フレーム（ADDBA Request フレームと ADDBA Response フレーム）で Block Ack に必要なパラメーターを交換することによって、Block Ack Agreement が行われる。 Block Ack メカニズムが初期化された後なら、QoS Data フレームのブロック （BlockAck フレームで返事してっていう複数のフレーム）を送信してもいい。

Block Ack に関する Action フレームは、Wireshark で wlan.fixed.category_code == 3 の ディスプレイフィルターをかけると抽出できる。

Dialog Token が同じ値のものが、1 組の ADDBA Request フレームと ADDBA Response フレーム。 Block Ack Agreement は方向ごとに結ばれるので、STA から Request を送る場合と AP から Request を 送る場合の両方がある。上の画像だと、Dialog Token が 1 のものだけ AP 側から Request を送ってる。 Buffer Size を変更するために、もう一度 Block Ack Agreement をすることもある。

ADDBA Request¶

ADDBA Request フレームのうち、Block Ack に関係するのは Order 1〜6 のフィールド。 (IEEE Std 802.11-2020 - Table 9-360—ADDBA Request frame Action field format)

実際のフレーム

• Category: Block Ackなら"3"

  IEEE Std 802.11-2020, p.880

  The Category field is set to one of the nonreserved values shown in the Code column of Table9-51.

  (IEEE Std 802.11-2020 - Table 9-51—Category values ※一部省略あり)

  Code	Meaning	See subclause	Robust	Group addressed privacy
  0	Spectrum Management	9.6.2	Yes	No
  1	QoS	9.6.3	Yes	No
  2	Reserved
  3	Block Ack	9.6.4	Yes	No

• Block Ack Action: ADDBA Requestなら"0"

  (IEEE Std 802.11-2020 - Table 9-359—Block Ack Action field values)

  Block Ack Action field values	Meaning
  0	ADDBA Request
  1	ADDBA Response

• Dialog Token: 同じActionに対するRequest/ResponseのDialog Tokenは同じ値を使う

  IEEE Std 802.11-2020, p.881

  • The Dialog Token field is used for matching action responses with action requests when there are multiple concurrent action requests.

  • The length of the Dialog Token field is 1 octet.

• Block Ack Parameter Set

  (IEEE Std 802.11-2020 - Figure 9-96—Block Ack Parameter Set field format)

  サブフィールド	ビット	長さ (bits)
  A-MSDU Supported	B0	1
  Block Ack Policy	B1	1
  TID	B2〜B5	4
  Buffer Size	B6〜B15	10

  • A-MSDU Supported: この Block Ack Agreement のもとで A-MSDU 入りの QoS Data フレームを送ってもいいかどうか。

    IEEE Std 802.11-2020, p.881

    The A-MSDU Supported subfield is set to 1 by a STA to indicate that it supports an A-MSDU carried in a QoS Data frame sent under this block ack agreement. It is set to 0 otherwise.

  • Block Ack Policy: ほぼ確実に"1"

    IEEE Std 802.11-2020, p.881

    The Block Ack Policy subfield is set to 1 for immediate or HT-immediate block ack

    immediate block ack の他には、delayed block ack っていうのがあるらしいけど、"Deprecated"に なってる; Block Ack Policy は"1"以外あり得ないのでは。

    IEEE Std 802.11-2020, p.3568

    dot11DelayedBlockAckOptionImplemented OBJECT-TYPE
        SYNTAX TruthValue
        MAX-ACCESS read-only
        STATUS Deprecated
        DESCRIPTION
            "Deprecated as the related feature has been removed from IEEE Std 802.11.
            This is a capability variable.
            Its value is determined by device capabilities.
            This attribute, when true, indicates that the station implementation is
            capable of supporting delayed block ack. The capability is disabled,
            otherwise."
        ::= { dot11StationConfigEntry 32 }
    

  • TID

    IEEE Std 802.11-2020, p.881

    The TID subfield contains the TC or TS for which the BlockAck frame is being requested.

  • Buffer Size: Wiresharkの表示も合わせてみると、BlockAck フレームを返すまでに、2304bytes x BufferSizeの分だけフレームを保持できるってことみたい

    IEEE Std 802.11-2020, p.881

    The Buffer Size subfield indicates the number of buffers available for this particular TID.

    IEEE Std 802.11-2020, p.882

    When the A-MSDU Supported field is equal to 1 as indicated by the STA, each buffer is capable of holding a number of octets equal to the maximum size of an A-MSDU that is supported by the STA.

    ADDBA Requestの時に"0"で送ると、Responseで値を決めてくれって相手に言ってるみたいな。

    IEEE Std 802.11-2020, p.882

    In an ADDBA Request frame, the Buffer Size subfield provides guidance for the frame receiver to decide its reordering buffer size. If the Buffer Size subfield is equal to 0, it implies that the originator of the block ack has no information to specify its value.

• Block Ack Timeout Value: このBlock Ack Agreementのタイムアウトを設定、"0"ならタイムアウトを無効にする

  IEEE Std 802.11-2020, p.882

  • The Block Ack Timeout Value field is used in the ADDBA Request and Response frames to indicate the timeout value for a block ack agreement.

  • The field is set to 0 to disable the timeout.

• Block Ack Starting Sequence Control: Fragment Numberサブフィールドは"0"(固定)、Starting Sequence NumberサブフィールドでBlockAck フレームを返して欲しいMSDUの番号を伝える

  IEEE Std 802.11-2020, p.800

  The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0.

ADDBA Response¶

ADDBA Response フレームのうち、Block Ack に関係するのは Order 1〜6 のフィールド。 (IEEE Std 802.11-2020 - Table 9-361—ADDBA Response frame Action field format)

実際のフレーム

ADDBA Request フレームと比べると、Block Ack Starting Sequence Control が無くなって、 Status Code が増える。

• Category: Block Ackなら"3"

  • 上記と同じ

• Block Ack Action: ADDBA Responseなら"1"

  • 上記と同じ

• Dialog Token: 同じActionに対するRequest/ResponseのDialog Tokenは同じ値を使う

  • 上記と同じ

• Status Code: successなら"0"

  IEEE Std 802.11-2020, p.874

  • The Status Code field is used in a response Management frame to indicate the success or failure of a requested operation.

  • If an operation is successful, then the status code is set to SUCCESS (0).

• Block Ack Parameter Set

  IEEE Std 802.11-2020, p.882

  In an ADDBA Response frame, when the Status Code field is equal to SUCCESS, the Buffer Size subfield is set to at least 1.

• Block Ack Timeout Value

  • 上記と同じ

BlockAck frame¶

Block Ack Agreement が確立した後は、複数の QoS Data フレームに対する ACK が BlockAck フレームで 返される。BlockAck フレームは Control フレームの 1 種。

(IEEE Std 802.11-2020 - Figure 9-41—BlockAck frame format)

RA は BlockAck フレームを要求した recipient STA のアドレスで、TA は BlockAck フレームを送信する STA のアドレス。

実際のフレーム

• BA Control: Compressed BlockAck フレームの TID_INFO サブフィールドには、この BlockAck フレームを送信する対象の TID が入る

  (IEEE Std 802.11-2020 - Figure 9-42—BA Control field format)

  サブフィールド	Reserved	Multi-TID	Compressed Bitmap	GCR Mode	Reserved	TID_INFO
  ビット	B0	B1	B2	B3〜B4	B5〜B11	B12〜B15
  長さ (bits)	1	1	1	2	7	4

  IEEE Std 802.11-2020, p.803

  The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for which this BlockAck frame is sent.

  Wireshark は B1〜B4 をまとめて BA Type として表示する。上の画像の BA Type: Compressed BlockAck (0x2) は、Multi-TID が 0 で Compressed Bitmap が 1 、GCR Mode が 0 の状態にあたる。TID_INFO は TID for which a Basic BlockAck frame is requested という名前で表示される

• BA Information: Compressed BlockAck フレームでは、Block Ack Starting Sequence Control サブフィールドと Block Ack Bitmap サブフィールドで構成される

  (IEEE Std 802.11-2020 - Figure 9-43—BA Information field format (Compressed BlockAck))

  サブフィールド	Block Ack Starting Sequence Control	Block Ack Bitmap
  Octets	2	8

  IEEE Std 802.11-2020, p.804

  The BA Information field of the Compressed BlockAck frame comprises the Block Ack Starting Sequence Control subfield and the Block Ack Bitmap subfield, as shown in Figure 9-43. The Block Ack Starting Sequence Control subfield is shown in Figure 9-37. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. This subfield is defined in 10.25.6.5. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0.

• Block Ack Bitmap: ビットが 1 なら、対応する MSDU か A-MSDU を受信できたということ。最大 64 個分の受信状況を示せて、先頭のビットが Starting Sequence Number に対応する

  IEEE Std 802.11-2020, p.804

  The Block Ack Bitmap subfield of the BA Information field of the Compressed BlockAck frame is used to indicate the received status of up to 64 entries, where each entry represents an MSDU or an A-MSDU. Each bit that is equal to 1 in the compressed Block Ack Bitmap field acknowledges the reception of a single MSDU or A-MSDU in the order of sequence number, with the first bit of the Block Ack Bitmap field corresponding to the MSDU or A-MSDU with the sequence number that matches the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield.

上の画像だと、SSC の Starting Sequence Number が 2614 で、Block Ack Bitmap が fd 01 00 00 00 00 00 00 。先頭のオクテット 0xfd は 1111 1101 なので、bit 1 だけが 0 になってる。 bit 0 が Sequence Number 2614 に対応するので、2615 だけ受信できなかったことになる。 2 オクテット目の 0x01 は bit 8 で、Sequence Number 2622 に対応する。 Wireshark も Not acknowledged frame: 2615 と [Last acknowledged frame: 2622] を出してくれる。

なのでこの BlockAck フレーム 1 つで、2614 から 2622 までの 9 個の MPDU の受信状況を返してる。 再送が必要なのは 2615 だけで、他の 8 個は再送しなくていい。 A-MPDU は、FCS エラーが発生した MPDU を Starting Sequence Number と Block Ack Bitmap で特定してる。

References¶

1. IEEE 802.11 Working Group (2020), IEEE Standard for Information Technology — Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks — Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
2. Wi-Fi Alliance, “Wi-Fi Multimedia Technical Specification Version 1.2.0”
3. David D. Coleman & David A. Westcott (2021), CWNA: Certified Wireless Network Administrator Study Guide Exam CWNA-108, 6^th ed, John Wiley & Sons
4. David Westcott, et al. (2011), CWAP: Certified Wireless Analysis Professional Official Study Guide: Exam PW0-270, Wiley
5. Tom Carpenter, et al. (2021), Certified Wireless Analysis Professional (CWAP) Official Study Guide (CWAP-404), CertiTrek
6. Wi-Fi Alliance (2009), “Wi-Fi CERTIFIED n: Longer-Range, Faster-Throughput, Multimedia-Grade Wi-Fi Networks”