ワイヤレスネットワーク from ブラウザネットワーキング
2部 ワイヤレスネットワークのパフォーマンス
5章 ワイヤレスネットワーク入門
使用できる周波数帯域幅は国によって割り当て計画が異なる
アメリカはFCCによるISMバンドと呼ばれる商用・私的利用可能な帯域が使われる 周波数帯域による性質
周波数帯域とチャネル(=通話路)容量は直接比例するため高周波ほど転送速度が速い
低周波はより遠くへ伝わりカバレッジが上がる、高周波は狭いために多数の設備が必要となる
ラジオなどは低周波が向くが、双方向通信はカバレッジが狭い方がかえって干渉せず都合が良い
S/N比の体験はパーティに例えられる
同じチャネル(可聴音域)で多数の人物が会話する状況ではノイズによる干渉が激しい
より大きい声でしか通信が通らない
遠近問題
近付かなければ会話できない
セルブリージング
スループットもレイテンシもクライアント側に一切の保証がない
IEEE 802.11gで54Mbpsを出したとしても同じチャネルをHD動画ストリーミングなどで占有されると帯域幅は半分以下になってしまう CSMA/CAを使って衝突回避
送信中の衝突が検知できないためチャネルが空いている場合のみメッセージ全体を1度に送信する
受信者から明示的な受信確認が届いたら成功それまで待機
待機時間は再送信回数に応じ指数的に増大させる
セル(1つのワイヤレスネットワークの被覆)内のクライアントが増えるとレイテンシに著しく影響する
2.4GHz帯のWiFiチャネルは(国によって異なるが)3~5程度が使える
avashe.iconワイヤレスホップのレイテンシを実測する際、複数回サンプルした結果から中央値、95パーセンタイル、99パーセンタイルを示しているのは外れ値のバイアスを抽象化する良い指標だと感じた
WiFiはWiFiの層で独自のエラー訂正及び再送アルゴリズムを実装し上の層から隠蔽しているため、Ethernetより特別TCPパケットロスが多いということはない
WiFiの帯域幅は敏感に変動しうるため、過去の値から予測してはならない
アダプティブビットレートストリーミングのようなストリームを持続的に監視する手法が有効
youtubeでは予め5-10秒毎に動画を分割しておき、分割毎に複数の画質にエンコードしておく
最初の分割は低ビットレートを渡す
分割毎の下り帯域幅を監視し、それに応じて次の分割の画質を切り替えていく
avashe.iconビットレート版スロースタート
netflixでは画面サイズや帯域幅ごとに120のバージョンにエンコードしている
7章 モバイルネットワーク
前半は歴史の話なので大幅に割愛
3G、4Gというのは技術ではなく要求されるパフォーマンスの国際標準 ITU(International Telecommunication Union)が設定し、その後複数の標準化団体がそれぞれ技術仕様を作る マーケティングの影響力が強い領域なので政治的な融通が通ってITUがガバガバになったりする
avashe.icon実際の4Gは曖昧なものであり実際の技術を理解せよ
1つの無線技術標準が策定されてからメインストリームとして普及するまでには10年ほど掛かる
LTEとHSPA+の成長予測より
モバイルWebでは顧客回線の技術的スパンを意識しよう
世代が混在した環境では規格を超えたネットワーク感での引き渡しが発生しうる
想定される技術のボトルネックを検討せよ
更に各技術標準は継続的な成長を続けるため、同じLTEでも時期によってスペックが異なる
これを判別するのがUE(User Equipment)カテゴリと呼ばれるバージョン番号
MIMOの数が異なったりする
現代の携帯端末は2~4の無線インターフェースを装備しているとされる
携帯端末の無線ネットワークのレイテンシを最適化する場合は電源管理の仕様を理解せよ
WiFiではアクセスポイント側が一定間隔でDTIM(Delivery Traffic Indication Message)をブロードキャストする 「これに続いて特定のクライアント向けのデータを送信する」というビーコン
特定のアクセスポイントに接続したクライアントはこれを監視し自分向け以外はWiFiを休眠させる
バッテリーは持続するがレイテンシは大きくなる
WiFi MultiMediaはこれにNoAckやAPSDを加える
強力だがAPIなどの制御を受け付けないためRRCの制限を理解せよ
電源効率の観点から比較すると
大容量のデータを転送する割合が大きく信号強度が強ければWiFi
アイドル状態が多い場合3G/4G
電源管理とネットワークパフォーマンス
電波の維持は携帯端末において2番目に電力消費が激しい
1番目は画面
MIMOが多重化される傾向にあるのでより激化していく見込み
スループットと消費電力はトレードオフ
MIMOや強い信号強度が高スループットに欠かせないため
電波の出力を下げると基地局への通信が切れやすくなる
接続再確立で数十~数百msのレイテンシが生ずる
移動体通信事業者ネットワークアーキテクチャ
ここではLTEで解説を行う
大域的にはRAN - CN - WAN
RAN(Radio Access Network)
端末と無線通信する基地局
要所は基地局から基地局へのハンドオーバー
LTEでは100ms以内に行われる必要がある
音声やデータのトラフィックが妨害されてはならない
データリンクからは隠蔽されなければならない
2つの状況で実行される
セルがオーバーロードしている場合
他のセルの強い信号が検出された場合
端末が移動している状況
更にRAN-CN間を動的にルーティングする必要がある
都会ではハンドオーバーが頻繁に起きうる
実際にはRAN-CN間にトラッキングエリアという間接レイヤがあり管理していることもある
CN(基幹ネットワーク)
二段のゲートウェイにそれぞれ参照すべき補助コンポーネントが付属している
RAN - (S-GW, MME) - (P-GW, PCRF) - WAN
S-GW(Serving Gateway)はデバイスが該当するRAN(トラッキングエリア)にルーティングするゲートウェイ
MME(Mobility Management Entity)はネットワーク上の全てのユーザの状態を管理するDB
S-GWはこれを参照しながら複数のRANとやりとりする
P-GW(Packet Gateway)はCN全体のゲートウェイ
パケットフィルタリングやQoS、DoS対策の実行
PCRF(Policy and Charging Rules Function)はP-GWのQoSルール管理と評価を行う
特にVoLTEなどのマルチメディア転送時に重要になる
モバイルネットワークのパケットフロー
実運用上の4Gネットワークのe2eレイテンシは接続状態から開始すれば30-100msに収まる
新規リクエストを送る際に起きる一連のレイテンシ
制御プレーンレイテンシ
RRCネゴシエーション、状態遷移時に発生する
アイドルからアクティブまで100ms未満
ドーマントからアクティブまで50ms未満
ユーザプレーンレイテンシ
端末 - RAN間の固定レイテンシが5ms未満
基幹ネットワークレイテンシ
RAN - P-GWのパケット転送レイテンシ
事業者によるが30-100ms
インターネットルーティングレイテンシ
通信事業者のP-GWから宛先アドレス間に発生するレイテンシ
完全に予測できずとも、これら値を把握するとかなりレイテンシが予測しやすくなる
制御プレーンレイテンシは技術仕様から読み解ける
CNのルーティングにかかるレイテンシは通信事業者の技術的FAQで数値の回答が得られる場合がある
AT&Tのような大手携帯電話会社が予測を述べることもある
ドーマント状態からアウトバウンド、アイドル状態からのインバウンドなフローについて予測しておくと吉
次世代はワイヤレスネットワークのトポロジによって変革される(という予想)
4Gの変調技術がワイヤレスチャネルの理論的限界に達しつつあるため
階層型ヘテロジニアスネットワークが考えられている
ワイヤレスノードの増大と都市圏におけるセルの高密度化が問題
数十〜数百km2を覆うようなマクロセルを減らし多数のマイクロセルに置き換える
信号同士の輻輳や距離や障害物による信号減衰を減らし電力消費と帯域を向上させる
セルの上に他のセルを置いて階層化でき、更にネットワーク容量とカバレッジを向上させる
avashe.iconさらっとしか触れられてないのでHetNet自体を調べる必要があるが、周波数帯が異なるネットワークを重ねてシームレスに統合する感じだろうか?
現在事業者による小さなセルは駅や会議場、スタジアムのような不定期な人口過密地帯において用いられている
で結局現実の4G LTEのパフォーマンスはどうなの?
モバイルネットワーク最適化
まず現代の通信規格のRRCステートマシンの性質に従うこと
3G/4G時点では時間局所的に振る舞うべし
プッシュ配信はクライアントのポーリングよりマシだが高頻度になるとそれよりも高コストである
この辺のスケジュールにはプッシュ配信関連のサービスや機能が利用できる
Google Cloud Messaging (GCM)など
WebサービスならServer-Sent EventsやWebSocket
不要なアプリケーションによるキープアライブを排除すべき
ただし多くの移動体通信事業者は5-30分のNAT接続タイムアウトを設定しているため、例外的に5分程度のキープアライブが必要になりうる
table:比較的楽観的なHTTPリクエストレイテンシ
制御プレーン 200-2,500 50-100
DNSルックアップ 200 100
TCPハンドシェイク 200 100
TLSハンドシェイク 200-400 100-200
HTTPリクエスト 200 100
合計レイテンシ 200-3500 100-600
UIフィードバックは即座に返し、ネットワークリクエストはバックグラウンドで管理する
変化するネットワークに対応する
ネットワーク状態を推測せず状態データをキャッシュしない
一時的エラーは頻繁に発生するため再送戦略を利用する
リクエストリトライにバックオフアルゴリズムを利用する
HTML5 AppCacheやLocalStorageの利用