第21話の光跡が、家庭模型のルーターまで巻き戻った。
ルーターは、届いたpacketのdestinationを見て出口を選ぶ。
けれど、入力lampはまだ暗い。
タブレットとルーターの間に、ケーブルがなかった。
代わりに、同じ部屋で三つの送信lampが点いている。
動画を再生したいタブレット。
番組表を更新したいテレビ。
写真を同期したいパソコン。
どれも、次のframeを抱えていた。
イト
三台なら、三本の見えない道を作ればいいんだ
ユイ
本当に、一台ずつ専用の道があるんでしょうか
ピコ
この実験では、三台とも同じWi-Fi channelを使っているよ
床に現れたのは、三本の橋ではなかった。
ルーター側のaccess pointまで伸びる、一本の青い帯だった。
この家庭模型では、access pointとrouterが同じ箱に入っている。まず無線のframeがaccess pointへ届いてから、routerのlookupが始まる。
奥の動画buffer gateに、残り九秒の輪が灯った。
九秒は、このラボだけの訓練時間だ。
タブレットのframeが届かなければ、gateは閉じる。
三本のつもりで送った
テレビが、青い帯へframeを送り始めた。
イトには、タブレット用の道が別に見えていた。
だから、迷わず送信leverを押した。
二つの光が重なった瞬間、帯の中央に黒い影が走った。
access pointの受信lampは点かない。
返事も戻らない。
イト
違う端末から送ったのに、どうして消えたの？
マコト
同じchannelを使うなら、空中では同じ場所を分け合うことになる
ピコ
いまの影は、同時送信を見えるようにしたラボ表示だよ。access pointはタブレットのframeを正しく読めなかった
イトが想像していた専用のbeamは、床から消えた。
Wi-Fiは、端末ごとに一本ずつ保証された私道ではない。
少なくとも、この三台は同じchannelという共有の場所を使っている。
現実のWi-Fiでも、同時送信や電波状況によってframeが届かず、再送が必要になることがある。ただし、何が衝突し、どう調整されるかは世代や機能、周囲の構成でも変わる。
動画buffer gateは、残り六秒になった。
どの順番を選ぶ？
操作台に、三枚のcardが開いた。
- 全端末が、送りたい瞬間にすぐ送る
- access pointに最も近い端末を、いつも先にする
- channelをsenseし、busyなら待つ。random backoffを使い、idleの間だけcounterを減らす
一番目なら速そうだ。
けれど、さっきの黒い影が残っている。
二番目なら順番は簡単だ。
けれど、近い端末が送り続けたら、ほかの端末はいつまで待つのだろう。
イトは、三番目のcardを持ち上げた。
イト
空いているか聞く。でも、空いた瞬間に全員が飛び出したら、また重なる
ユイ
だから、待つ長さも全員同じにはしない？
イト
うん。乱数でばらけさせる。ぼくが好きな数字を決めるんじゃなくて、端末側に選ばせる
ピコは答えを選ばなかった。
イトが一番目の「即送信」を閉じ、二番目の「永久優先」を伏せた。
そして三番目のcardを、タブレットの制御slotへ差し込んだ。
ラボの乱数器から、四つの小さなbeadが落ちた。
これも規格共通の固定値ではなく、今回の訓練表示だ。
空いた。でも、まだ送らない
テレビが送っている間、channel表示はbusyだった。
タブレットのbackoff counterには、beadが四つ残ったまま動かない。
テレビのframeが帯を抜ける。
channelがidleになり、定められた待ち条件を満たすと、beadが一つずつ落ち始めた。
四つ。
三つ。
そこで、パソコンが先に送信を始めた。
イトは送信leverへ指を伸ばし、止めた。
counterも、残り二つで止まる。
イト
いま空いたように見えた。でも、ぼくのcounterはzeroじゃない
ピコ
busyの間は減らさず、またidleになったら続きから数える。それがこの基本レーンの動きだよ
マコト
最初から数え直すのでも、busy中にこっそり減らすのでもないんだね
パソコンの光が抜けた。
青い帯が静まる。
二つ。
一つ。
zero。
その瞬間、イトは送信leverを押した。
タブレットのframeが、一本の青い帯を走る。
今度は黒い影が出ない。
access pointの受信lampが、はっきり点いた。
すぐあとを追うように、小さな返事の光がタブレットへ戻った。
ACK。
directed frameをこの無線区間で受け取ったことを知らせる、localな確認だ。
ルーターの入力lampが点き、第21話で見たFIB lookup台が動き始めた。
動画buffer gateは、輪を一つ残して開いている。
この訓練では、一つのframeをaccess pointまで届けられた。
待てば、絶対にぶつからない？
イトは、黒い影の消えた帯を見て笑った。
「これなら、もう衝突しないね」
しかし、ラボの端にある別の端末は、壁の陰に隠れていた。
タブレットからは、その送信がよく見えない。
ピコは、消えていないwarning lampを指した。
ピコ
senseとbackoffは、衝突を避けやすくする仕組み。衝突を絶対になくす魔法ではないよ
ユイ
互いの電波が見えにくい端末や、同じbackoffを選ぶ場合もありますね
イト
ACKが戻らなければ、失敗した可能性を見て再送へ進むんだ
random backoffにも待ち時間がある。
channelを確かめ、順番をずらし、ACKを返すぶんのairtimeも使う。
混んでいればcounterは何度も止まり、動画の待ち時間が伸びることもある。
それでも、「全員が空いた瞬間に同時に飛び出す」より、重なりを減らす道を選べる。
IEEE 802.11 Working Groupは、802.11をstationとaccess pointの間などで使うair interfaceの規格として扱い、そのMAC protocolをCSMA/CAと説明している。IEEEの802.11 MAC tutorialでも、基本的なDCFの流れとして、busy後のrandom backoff、idle中のcountdown、busy時のfreeze、directed frameへのACKが示されている。
この話で動かしたのは、その基本DCF / CSMA/CAをつかむための学習レーンだ。現在のWi-Fiにあるすべての優先制御、同時通信、周波数利用を、この一本だけで説明し切るものではない。
周波数帯を変えれば、私道になる？
ラボの隣室には、以前から二つの光路が置かれていた。
近くで太く見える道と、壁の向こうまで細く続く道。
2.4GHz、5GHz、対応機器では6GHzも選択肢になる。
周波数帯、channel幅、端末、壁、距離、周囲の利用状況、国や地域の利用条件によって、使える機能や結果は変わる。
だから「必ずこちらが速い」「どの家でもこちらが遠くまで届く」とは決めつけない。
そして、帯域を選んだだけで各端末に永久の私道が一本ずつ配られるわけでもない。同じchannelを使う端末は、その中でairtimeを分け合う。
この図は、住宅模型で違いを考えるための簡略表示だ。
実際の速さや届き方は、周波数帯の名前だけでは決まらない。
Wi-Fiが遅いときの置き場所、壁、ほかの端末、routerの先まで含めた切り分けは、関連ガイド「Wi-Fiの仕組み」で詳しく見られる。
ACKが点けなかったlamp
イトは、タブレットへ戻ったACKを指で受け止めた。
一つのframeは、access pointへ届いた。
ルーターも、そのpacketを次へ送る準備に入った。
それなのに、遠隔の動画service gateは暗いままだった。
イト
ACKが戻ったのに、動画serviceの到着lampは点かない
ピコ
そのACKが見ていたのは、いま渡ったlocalなWi-Fi hopだからね
ユイ
遠くの相手まで届いたことや、順番どおりそろったことは、別の層で確かめる必要があります
共有の青い帯では、テレビの光がまた走り始めた。
タブレットの新しいcounterは、busyの間、動かない。
その手前でlocal ACKが一度だけ瞬き、ルーターの向こうの到着lampはまだ暗い。
近い一歩を確認する光と、遠い相手への約束は、同じではなかった。
次回：届け方の約束は、誰が守る？
Wi-Fiのframeはaccess pointへ届いた。
routerはpacketの出口を選べる。
では、その先で一部が失われたら、誰が送り直すのだろう。
順番が入れ替わったら、誰が並べ直すのだろう。
速さを優先して、待たない届け方もあるのだろうか。
次回、ピコルート第23話。
TCP/IPという名前の中には、どこまで違う約束が入っている？