提案⽅式の実装⽅法に関する検討

⼀般的に802.11nにおけるA-MPDUの送受信処理は，データ送信側とデータ受信側の 無線LANチップとデバイスドライバによって実現される．それぞれの⾏う処理は図4.4 のようになる．無線LANチップでは，物理層の電波の送受信や即時の応答が求められる

ようなハードウェアに依存した処理が⾏われる．⼀⽅，デバイスドライバではデータの送 り込みなどのハードウェアの制御やMPDUの選定や再送判断などの時間の余裕のある処 理がソフトウェアによって⾏われる．

• 送信データレートの決定

• アグリゲーションするMPDUの 選定

• 通知されたBlock AckのBitmap から再送MPDUの選択

• MPDUのリトライアウトの判断

• A-MPDUの作成・送出

• タイムアウト再送とその上位へ の通知

• Block AckフレームのBitmapの 上位への通知

• MPDUの順序管理

• MPDUのリトライアウトの判断

• 受信したMPDUの上位への通 知（誤ったフレームのエラー通 知を含む）

• Block Ackフレームの送出

データ送信側 データ受信側

デバ イス ドラ イバ

無 線 ＬＡ Ｎチ ップ

図 4.4: A-MPDUの送受信処理の分担

具体的には以下のように⾏う．データ送信側では，デバイスドライバにおいて，上位 層からのデータ送信要求をリングバッファに格納し，その中からアグリゲーションを⾏

うMPDUを選択する．その中には，Block AckフレームのBitmapから判断された再送フ レーム分のMPDUも含まれる．また，MPDUごとに再送回数を記録しており，⼀定回数の 再送が⾏われた場合にリトライアウトを判断する．また，この送信成否を次回の送信デー タレートの決定に⽤いている．これに対して，無線LANチップでは，実際にA-MPDU を作成して送出する処理，送信したがACKが返ってこない際のA-MPDU全体のタイム アウト再送の処理，受信したBlock AckフレームのBitmapのデバイスドライバへの通知 などの処理を⾏う．

⼀⽅，データ受信側では，無線LANチップにおいて，受信したMPDUのデバイスド ライバへの通知，Block Ackフレームの送信などを⾏う．なお，MPDUの通知機能では，

CRCエラーとなったMPDUに関する情報も知らされる．それに対して，受信側のデバイ スドライバでは，MPDUの順序管理やリトライアウトの判断を⾏う．受信側でのリトラ

イアウトは，送信側のBlock Ack Requestによって判断される．さらにデバイスドライバ では，受信したMPDUの送信データレート，受信信号強度などの情報も取得しており利

⽤可能である．

このように，デバイスドライバと無線LANチップによって，処理の分担が⾏われてい る．無線LANチップ側の処理の変更は困難であるが，デバイスドライバ側の処理はソフ トウェアで構成されているため，現実的に変更が可能である．このため，本論⽂では提 案⽅式を端末およびアクセスポイントのデバイスドライバに実装するという⽅針を採⽤

する．

4.5 ^まとめ

本章では，まずBufferbloat問題への既存アプローチの無線LANへの適応性の検討を

⾏った．そして，無線LANに特化した⽅式提案のための基本検討を⾏い，無線データレー トが低いほど遅延性能が悪化することを⽰した．また3章の実験結果から無線データレー トに関わらずキュー⻑が伸びていることから，パケットロスによるスループット低下の懸 念があることを⽰した．これらの検討から802.11n無線LANのデータレートに着⽬して，

TCP通信におけるBufferbloat問題に対してスループット性能の低下を引き起こすことな く遅延性能の悪化を抑制する⽅法を提案した．本提案⽅式の実現⽅法は端末側とアクセ スポイント側の2つのアプローチがある．さらに，提案⽅式の実装⽅法に関する検討を⾏

い，デバイスドライバにて現実的に実現可能であることを述べた．

第 5 章 端末側によるデータレートに応じ