学術的に面白い記事があったので紹介する。
千葉大とNEC、無線LANを用いて通信される映像や音声の品質を向上させるダイナミック・パケット通信制御方式を開発
この方式はQoSを実現するにあたって802.11eに対応していない製品でも、QoSを実現しようという考えのもの。
通常802.11eは通常のデータトラフィックよりVoIPや映像のIFS（待ち時間）を短くすることによって優先度を与える。これにより、CSMA/CAを行った場合にVoIPのトラフィックが勝つ確率が大きくなるためにQoSが実現される。
今回の千葉大とNECの手法では、ブラウザなどのバックグラウンドデータのトラフィックのMACフレームをわざとAP側で損失したように見せかけ、ACKを返さないことで、送信端末側に指数バックオフを実行させ、バックグラウンドトラフィック側の優先度を下げようとするもの。これによってSTA側が11eに対応していなくてもAPのみの変更でQoSを実現することが可能だ。
問題は11eに比べてIFSの値がDIFSのため長くなってしまうため、わざとAP側でMACフレームを落としてしまうためにスループットが11eに比べて少しだけ落ちそうな点だが、QoSの優位性をつけたいだけであれば、まったく問題がない。
WRED(Weighted Random Early Detection)を連想させるような、この優先度のつけ方は思いつかなかった。非常に面白いし、既存の実装に影響を与えずにできる点が良い。アドホック系QoSでも絶賛検討すべき技術である。
特許を取っているかどうか気になる;p
ども、お久しぶりです。
>今回の千葉大とNECの手法では、ブラウザなどのバックグラウンドデータの
>トラフィックのMACフレームをわざとAP側で損失したように見せかけ、
>ACKを返さないことで、送信端末側に指数バックオフを実行させ、
>バックグラウンドトラフィック側の優先度を下げようとするもの。
受信側（中継側）がトラヒック過多のフリをして、その分無理やり空けた
帯域を使おうZE、ってことで理解は合ってますかね？
マイナスの発想すげえー
…でも過去に802.11のバックオフタイマをTCPのウインドウサイズと
同じように制御したら帯域が有効活用できました云々の論文があったような？？
発想は似てるけど…
他人に制御させる（集中）か自分で制御するか（分散）か
ならば個人的には後者が好きです。
バックグラウンドのトラヒックがいくら増えても構わないけど
優先すべきトラヒックが来たらどうするんだろう…
NGNウレナイヨーさん、
コメントありがとうございやす。
お久しぶりですね。
>受信側（中継側）がトラヒック過多のフリをして、
>その分無理やり空けた帯域を使おうZE
正しいです。
>802.11のバックオフタイマをTCPのウインドウサイズと
>同じように制御したら帯域が有効活用できました
よく分からないす＞＜
この研究の利点の良い点は”既存の（MAC）実装に一切の変更なくQoSを実現できること”だと個人的には理解しています。
MAC実装を変更できるのであればIFSを細かく設定できる802.11eの方が良いです。
しかしながら、アドホック端末も考慮した場合、IPより上位は変更できても、MAC以下は変更できない場合があるかもしれない、その場合にMAC以下実装を変更せずにQoSできたら嬉しい人がいるかもしれない、という発想にて「アドホックQoSで検討するべき」と書かさせて頂きました。
しばらく考えてみました。
アドホック端末＝全端末受信なので、結局MACでフレームを拒否する実装が必要になり、結局MAC実装をいじらないといけないので手間が変わらないような気もしてきました。上位層の制御だけでMACにフレームを落とさせることができるか？を考えてみても、MACのACKはハードウェア実装されており、変更は困難ですね。
となると、AP-STA間でSTA側に802.11eに対応しない端末が存在する場合にその子に遠慮してもらうという用途しかない予感です。
2年前程度から802.11eに対応するSTAは多い（というか、ほぼ全て？）ので、それ以前の端末が多い部署においてQoSを実現するにあたり、端末を変えることなく実現できるよ、という使い道がベストかと思われます。初期のVoIP端末は11e対応してないこともあるかも？なのでその場合向けですね。
> TCPのウインドウサイズ
ああ、受信ウィンドウサイズ=0でTCPを止めるということですかね