LTEエリア状況図について、「バンドごとの整備状況も知りたい」と言う要望をたくさんいただき、スクリプト改修して一カ月ほどかけて再集計しました。別に一日で再集計くらいできるんですが、サーバ負荷とか気にしちゃうチキンです。

ということで、以下に自動出力図を。

全バンド合計

2.1GHz帯

ドコモ

KDDI

SBM

EM

プラチナバンド (700～900MHz帯)

ドコモ

KDDI

SBM

EM

以下その他

1.5GHz帯

ドコモ

KDDI

SBM

EM

1.7GHz帯

ドコモ

KDDI

SBM

EM

凡例
: iPhone5
: iPhone5S/5C
: Android
: Android(一部)

一応毎日更新ですが、免許情報が更新される月3回くらいしか情報は反映されないと思います。

一応このエントリから常時最新情報画像を参照していますので、参考にどうぞ。

[追記]バンド幅変更をするときの暫定的な状態だと思って無視してたんですが、共存不可能な2キャリア分の免許を1局にブチ込んだまま放置するという暴挙があまりに多くなってきていたので、計数方法修正。ちょっとDB負荷上がっちゃったけどたぶん大丈夫。
[追記]ダブルカウントしてね?(特にKDDIバンド別)というメールが20通を超えたので補足。えーと、マルチバンド基地局というものがありましてですね。そうでなくとも設備の一部を共用する基地局は免許を一つにまとめましょうという決まりがあってですね。なので「全ロケーション」に中のいくつかは一つのロケーションに複数バンドの基地局がおいてあるんです。慎重に「ロケーション数」という記述にしたのはそういう理由からです。
[追記]面グラフなら面積比例にした方がよくね？と言うご意見いただき、面積比例に直しました。
[追記]端末対応状況アイコン表示してみましたが、たぶん間違ってます。間違いご指摘いただければと思います。

TWEET

iPhone5でパケ詰まりが大流行らしいですが原因はなんでしょうか、と言うお便りをいただきまして、元祖パケ詰まり博士の無線にゃんが解説します。なんだよパケ詰まり博士って。

検索するといろんな情報があるようですが、現象としては、どうやらau限定で、LTEと3Gの境界で報告されている例が多いようです。いろんな説が出ていて、「800MHzを豪奢にLTEに使ったので3Gが細った説」「Qualcommチップのバグ説」「個体差説」等々。ちょっとだけ考えてみます。

と言っても、たいてい、パケ詰まりなんてのはネットワークが原因でおこるものです。元祖パケ詰まりと言えば、2000年初頭に話題をさらった使い放題PHSパケット(AIR-EDGE)のパケ詰まり。あのころは固定回線常時接続が引けない集合住宅などがまだ多く、常時接続需要が一斉にAIR-EDGEに流れ込んで、盛大なパケ詰まりを発生させていました。

原因はシンプルで、要するに集合住宅などで同じ場所で一斉に多くの端末がアクセスするために、無線チャネルがあふれていたり、あるいは地域ごとの接続サーバの許容量を超えていたり、と言うことが発生していただけです。

さてiPhoneのパケ詰まりの件で気になるのが、LTE-3Gの境界で、と言う症状ですね。LTE→3Gへの遷移が起こった時、と言うことになるかと思います。こういうことが起こるのは、要するにLTEのエリアの端っこ。たとえば、電車とかでみんな一斉に移動していると、みんなが同時にエリアの端っこを通過します。

と言うことは、結構な数の端末が一斉にLTEから3Gに遷移することになります。3Gに遷移すると、当然LTE→3Gハンドオーバが行われるわけですが、iPhoneの場合はoptimizedハンドオーバに対応していないので、この場合、いわゆる「ランダムアクセス」が行われます。[追記]WCDMAでもハンドオーバ時はランダムアクセスがあります。

端末から基地局への「最初の一発目」の信号は、どうやっても基地局から制御することはできません。ですので、言ってみりゃあてずっぽうで短い信号を一発送り、基地局がそれを受けられたら即座に返答してちゃんとしたリソース制御が始まります。このあてずっぽう信号は、普通はみんなの通信開始契機がずれているのでぶつかることは稀ですが、「みんながほぼ同時に通信を開始しようとするような状況」が生じると盛大にぶつかり合って、なかなか一発目の信号が届かず、通信が開始できないということが起こります。

つまり、LTEのエリアの端っこをみんな同時に通過することで、3Gへのハンドオーバが一斉に起こって、その時の最初のランダムアクセスがぶつかり合ってなかなかチャネルの割り当てが行われない、と言うことが起こっているんだろうと思います。昔に書いた、地下鉄での混雑の後半に書いたような一斉アクセスが地上でも起きている、ってことです。で、たいていはチップの独自実装として一定回数ランダムアクセスが失敗するとしばらくお休みしちゃう、と言う動作をします（ネットワーク保護の観点で）。このチップの動作がおそらくパケ詰まりの原因。

要するにLTEのエリアの端っこ（と言うよりたぶん「穴」）があちこちにあることがそもそもの原因かと思われます。さっさと穴ふさげ、ってのが、事業者に対して求めることでしょうね。auでの問題が多くソフトバンクでの報告が少ないのは、この穴の多さじゃないでしょうか。なんだかだでauの方は2GHzLTE局数も少なく、人口の多いところでもまだ穴がたくさんあるんじゃないかと思われます。

また、上のような理由ならauのAndroidでも起きてもよさそうですが、そこもやっぱり、AndroidはLTE800MHzを掴めるので穴に落ちにくいということもあるでしょう。また、iPhoneは非対応でAndroidは対応といわれるOptimizedハンドオーバは、eCSFBと同じように先に個別チャネルを割り当てる方式（すなわち「ランダムアクセス」が必要ない）みたいなので、ランダムアクセスのぶつかり合いによる輻輳が起きにくいのかもしれません。

ちなみにその他のいくつかの説について簡単に。「800MHzをLTEに使いすぎて3Gが細った」説は間違いです。元々、auがLTEに使っている800MHz帯の15MHzのうち10MHzは、今年7月までドコモが使っていた帯域なので、auが3Gで使える残りの帯域5MHz自体は太りも細りもしていません。2GHzで5MHzをLTEに割り当てた分については、こちらも実は、今年6月のPHS制御チャネル移行で2G帯5MHzが新たに使えるようになっているので、実質プラマイゼロだったりします。なんだかだでauはLTE開始にあたって3G帯域を全く減らさずに対応できてたりします（と言うか逆に元々それだけ少ない割当で3Gを全部捌いていたのが異常な状態だったと言えるんでしょうけど）。

Qualcommチップバグ説は、何とも言えないですが、ないとは断言できないところ。やっぱりLTE-CDMA2000のチップはマイナー系なので、バグが残りやすい傾向は強いはずです。内部的には全く親和性のないステートマシンが好き勝手に動いている状況でしょうから、それぞれの内部的なタイミングが延々とずれて、片方が通知信号を出したときにはもう片方は耳を閉じてる、みたいな状態が続いて連携が途切れている、と言うようなことは起こりうるとは思います。先ほどの「しばらくお休み」の実装がLTEとの相互遷移を考慮していないプアな作りなのかもしれません。

端末の個体問題と言う可能性もないとは断言できません。端末を取り換えたら直った、と言う報告が、検索すると出てくるので。たとえば、アンテナ感度の個体差が大きい場合は起こらないとも限りません。ハンドオーバするかどうかを決めるのは、端末が受信した電波の強さなのですが、たとえばこれがある一定の中にばらついていて、ハンドオーバするには弱すぎる（または強すぎる）受信レベルでハンドオーバが起動することで悪影響がある、と言う可能性もあります。

まぁ、上記の理由に限らず、無線でTCPをやるときは、パケ詰まりは永遠について回るテーマですね。いくつかの運の悪いパケ遅延・パケロスの重なりが雪崩式にパケ詰まりに発展する、と言うのは、PHSパケット時代にいやという程体験させていただきました。TCPはそれほどパケ遅延・パケロスが高くない前提で作られているので、無線のように遅延・ロスが日常茶飯事と言う伝送路にはあまり向かない方式だと私は思います。TCPに対してHARQみたいなモードを提唱しているところもあるようですが、標準技術になるにはまだまだ時間がかかりそうです。と言うことで、パケ詰まりについてでした。

[追記]ソフトバンクでもiPhone4S以前からiPhone5に変えたら多発しているというご指摘をたくさんいただいたため、「au限定」ではなさそうです。どっちにしろこの考察が正しいなら、ランダムアクセスが同時多発するLTE→3GハンドオーバであればWCDMAであれCDMA2000であれ理屈上は同じように発生するものと思われます。昔のメディアの山の手線一周調査とかを見てもソフトバンクは3G時代からハンドオーバ時にブチ切れるのは当たり前だったみたいなので、声が上がりにくいのだけなのかも。

TWEET

ケータイニュース.netの方でやってるスマートフォンスピードテストですが、最近意外と協力者が多くてたくさんデータが集まっています。

と言っても、なんだか夜中の3時とか早朝とかに狙ったように測定して速度アップを目論む（笑）ような人もいたりしますが、そういうところを除いてもおおざっぱに傾向が出ていて面白いので、最近の傾向をメモっといてみます。

まず、ドコモ・KDDI・ソフトバンクの3社の速度を単純に比べると、KDDI＞ソフトバンク＞ドコモ、と言うのがおおざっぱな傾向。ただし、KDDI、ソフトバンクの二社は先ほど書いたような明らかな統計アップ狙いの怪しい計測が多いため（笑）、全体の平均速度そのものは直接重要な指標とは言えない気がします。

一方、時間帯別の速度についての統計も公開していますが、こちらを見ると面白い傾向が出てきます。

まずドコモですが、どんな時間であってもかなり安定した一定速度が出ています。ただし、その一定速度が他の二社を大きく下回っている。ここまで時間帯に影響されず安定した速度を出しているということは、何か結構特殊なことをやってるんじゃないかとさえ思えるほど。と言っても、時間を超えてトラフィックを平準化するような技術は存在しませんから、ドコモユーザの特性と言う面もあるのかもしれません。

KDDIは、ドコモとは真逆で、時間帯による速度差が非常に大きく出ています。速いときは他の二社を圧倒的に上回る速度だけど、遅いときはがっくり落ちる、みたいな。この業界にいるとよく見る、時間帯によるトラフィック量の推移グラフをきれいにひっくり返した形の速度分布になっていて面白いですね。

ソフトバンクがちょうどドコモとKDDIの中間くらいの傾向。時間帯による差もほどほどにあるけどKDDIほど顕著ではなく、上はそんなに速くもないけど下もそんなに遅くもならない、と言う感じ。なんか、ソフトバンクとKDDIが、事業者イメージ的に逆なのが面白いです。イメージ的に、ソフトバンクは品質差が激しいけどピークを攻めるけどKDDIはそこまで攻めきれず半端にドコモに追従して中間くらいの品質とスペックになっちゃう、みたいなイメージだったんですけど。

で、もう一つ公開していますが、iPhoneの時間帯別速度比較。ちょっと意外なんですが、こちらもKDDI＞ソフトバンクになってます。いろんなところで言われていますが、KDDIのiPhoneは2GHzLTEしか使えないのでエリアも狭く速度も遅い、とされていて、ってことは、LTEがつかめる率も低いはず、つまり平均速度も落ちるはず、ってことなんですが、2GHz一本に注力しているソフトバンクよりも速かったりするのはちょっと不思議。

ただ、実は別に基地局数統計で、2GHzLTE局数を帯域幅別に集計中(まだ半分くらい)だったりするんですが、2GHzLTEでもKDDIの10MHz幅局数の比率が結構高いっぽいんですよね。ソフトバンクはせいぜい1%くらいなんですがKDDIは1割以上はある感じ。もうちょっと集計が進んだら公開しますが、KDDIのiPhoneでも75Mbpsなエリアは結構広がりつつあるような感じです。この辺が、エリアが狭くても速度自体を底上げしているかもしれません。

あとは、実際に測定すると表示されるんですが（ちょっとデータベース負荷高いので常時表示はしてませんが）、そのキャリア・その時間の詳細グラフを見ると、たとえばKDDI AndroidだとLTE対応と非対応で大きく二つの山ができていたりするのが見えたりします。まだ非対応が圧倒的に多いのですが、速度計測結果に関してはLTE対応端末の普及率と言うのも大きな要因になりそうです。買い替え需要が旺盛なiPhoneの場合はLTE対応率が高くなるので、iPhoneを持つKDDI・ソフトバンクの結果がドコモよりも高い、ということも考えられます。ドコモも、LTE対応率の低い昨年秋冬くらいの端末が買い替えられていくと、徐々に追いついていくんじゃないかなぁ、と言う感じ。

と言うことで、最近の速度測定結果の傾向についてでした。

TWEET

とある大きなイベントでの話、と言うことで、お便りをいただきました。その人はなんでもソフトバンクの「優先携帯電話」を持ってそこに行ったそうですが、無線が輻輳して全く使えなかったそうです。同じくドコモ、auも優先電話を持っていて、そちらは問題なくつながったのに、と。優先電話をわざわざ持って行ったのにつながらないのは納得がいかない、どういう理由があるんでしょうか、と言うご質問。

いやぁ、私もソフトバンクを貶すのは大好きなのでこういうネタには食いついちゃいますが、なんというか、こればっかりは運ですよね。この場合はたまたまソフトバンクでした、ってことで。とはいえ、そもそもどうしてそんなことになるんや！と言うご立腹には何らかのお答えを用意しましょうということで本日のネタ。

まず、無線における優先電話ってのがなんなのかっていう話を軽くおさらいしておくと、前にも似たようなことを書きましたが、基本的には「優先的につないであげる電話」ではなく、「他の電話に接続禁止の信号を送っているときも優先電話は無視できる」と言う仕組み。なので、「他の電話が接続禁止」と言うのが前提条件になります。

これでどうして「優先」になるのか。話は簡単で、他の電話は接続禁止信号を受けているので接続しません。接続しないということは、その分無線容量や回線容量に空きができます。なので、接続禁止信号を無視できる優先電話はその空きを使って通信できます、と言う仕組みになっているわけです。

そもそも無線だと、最初に「今から発信しますよ」と言う信号が出るのですが、その信号自体が無線容量を食いつぶします。なので、たとえば固定電話のように交換機で優先電話からの発信を優先的に受け入れる処理と言うことをするだけでは不足で、他の電話がその「今から発信しますよ」信号を送らなく（送りにくく）してあげる、と言うことで差をつけるしかないわけです（もちろん携帯電話でも交換機で優先非優先処理は行っていますが）。

こう考えると、「優先電話」でも接続できなくなってしまうケースがあることに気が付きます。

一つ目。混雑しているのに接続禁止（規制）がかからなかった場合。これは完全にオペレーションのミスですが、普通の電話に対して規制がかかっていなければ、優先電話と普通の電話の差は（ほぼ）ありません。普通の電話の使用で無線が非常に混雑してしまえば、優先電話と言えども、無線信号を送ることさえできずに立ち往生します。冒頭の質問者のケースでは、きっとこれが起こっていたものと思われます。

二つ目。規制はかかっていたものの、やっぱり無線が混雑してしまった場合。規制がかかったとしても、規制がかかる前からつながっていた回線は切れるまで規制対象とならないため、無線の使用は続きます。また、規制がかかった後も、たとえば、同じような優先端末が大量に通信を始めれば、同じように無線は混雑するでしょう。なかなか起こらないとは思いますが、こういったケースでも優先電話がつながらない、と言うことが起こります。

そのほかにもいろんなケースがあるでしょうが、こんな感じで、その時・場所によっては、やっぱりどうしてもつながらないケースと言うのは出てきます。それが起こらないように調整するのがオペレーションの腕の見せ所ですが、こればっかりは天気予報と同レベルの不確実さのある現象を先読みする、と言うスキルが必要なわけで、まぁ時には失敗はするよね、と言うことなんですよね。ってことで、「運が悪かったですね」と言う結論になるわけで。

一方で、たぶんどこのキャリアも持っていると思うんですが、あるエリアで突発的にトラフィックが増えたりした場合に自動で規制がかかるような仕組みがあったりするんですが、この自動規制がどういうトラフィックの変動のときに発動するのか、と言うアルゴリズムに関しては、キャリア独自の技術力と言う面もあるとは思います。ただ、やっぱりイベント会場とかだと、事前に予測して何時ごろにどのくらいの規制をかけよう、と言う様に計画するはずなので、イベント情報の取りこぼしがあったり予測を間違えたりなんていう単純なミスでどこのキャリアも同じようなことをやらかす可能性はありそうです。

と言うことで、なぜ優先電話なのにつながらないなんていうことが起こるのか、と言うお話でした。

TWEET

いや、自分でやっといてなんですが、例の局数まとめの数字見てるとKDDIのLTEエリアがすごいことになってそうな局数で、ちょっと期待してて、でようやくエリアマップが公開されたっぽいので見てみました、っていう話なんですが。

私が、エリアを確認するときに主にリファレンスとして使っているのが、私の実家。もちろん身元バレはいやなので公開しませんが、2000年代前半はドコモmovaとウィルコムPHSしか入っていない場所で、FOMA?au?何それ?みたいな場所だったので、各キャリアがどのくらい本気でカバーしに行ってるかが良くわかる場所なんですよね。

もちろん、その後、FOMAもプラスエリアで入るようになって(でも居間の床に置くと圏外になるけど→レピータ入れてもらいました)、それからしばらくしてauも入るようになって(こちらはとりあえず床においても大丈夫)、ウィルコムが入らなくなって(オイ)、ソフトバンクは未だにエリア端が2km先をうろうろしてて、っていう状況で、まぁこのイメージが私の中の各社のエリアの実力そのものなんですが、そこを基準にしてLTEを見てみますと、っていう話になるわけで。

ドコモLTEは、実家の最寄の役所(市役所支所=5km先)さえもカバーしてなくて、完全にアウト。一番近いエリア端が7km先です。これはひどい。ソフトバンクは、4G(AXGP)の方が実家から1kmくらいのところに端っこ、4G LTEが2km先のところに端っこがある感じでいずれも支所はちゃんとカバーしてます。なんだかだでソフトバンクはとりあえず持ってるロケーションのところまでは頑張って攻めてるってことですね。ウィルコムPHSロケーションにもちゃんとAXGPが建ってるみたい(でも実家まで届いてないけど)。ドコモ弱。

問題のKDDI。マップ見たら、3Gと全く同じでした(拡大してみると申し訳程度に端っこが30メートル縮んで見える、くらい)。拡大予定とかじゃなくて現況エリア内。本当の端っこは実家から数km山奥に入ったところにあるので、たぶん居間の床においても大丈夫。800MHz使ってるからとはいえ、これはちょっとすごいことになってるみたいです。さらに免許情報見ると、800MHzのLTE基地局はほぼ全部10MHz幅(75Mbps対応)だからうちの実家も75Mbpsエリアってことなんですけど（まぁその「ほぼ」から外すのが我が実家クオリティなんですが）。とにかくKDDIの本気っぷりが怖いです。ソフトバンクがこれ以上広がる可能性は薄いし(3Gさえ来てないし)、ドコモもなんだか全然やる気ないみたいだし、どうやらLTEはKDDIを選ぶしかないですわこれ。

ってことで、私の中のLTEエリアの実力は、KDDI＞ソフトバンク＞＞＞＞＞＞＞＞＞＞＞ドコモです。ドコモ、なんか不真面目すぎじゃない？ちびちびと850MHz帯のLTE局建てたりしてるみたいだけど、これはなんというか・・・丸2年近く先んじていてこれってのは、もはや怠慢以外の何を疑えばいいのかわからんです。

とりあえず遊び＆緊急回線用のスマホは次もKDDIで安泰ですかな。っていうか実家のブロードバンド回線もLTEにしちゃえ(今は何度も断られたところをゴネて無理やり引っ張ったADSLで1Mbps未満)。なんだかだでフィーチャーフォンがドコモ以外選びようがないのでメインはドコモを使うしかないんですが、それにしても、各キャリアのエリアに対する真剣さが昔とまるっきり逆転しちゃってる感じがするんですよねぇ。ってことで各キャリアLTEエリアの私的実力見極め個人的メモでした。

TWEET

先日のLTE展開プランのアップデートの図が思いのほか好評だったのですが、毎回作るのがめんどくさいのでスクリプトで自動で作るようにしました。

下記がその図です。

一応毎日更新ですが、免許情報が更新される月3回くらいしか情報は反映されないと思います。

一応このエントリから常時最新情報画像を参照していますので、参考にどうぞ。

[追記]面グラフなら面積比例にした方がよくね？と言うご意見いただき、面積比例に直しました。

TWEET

ドコモの障害が増えていますね。なぜ障害が増えているか、という点については、障害が表面化する仕組みを考えてみればいいと思います。要するに、前に書いた通信事業における障害に対する考え方について辺りをおさらいしてみるといい感じかもしれません。

まず、「表面化する障害」とは何か、と言うことを考えています。障害が起こったとき、仮にどんな小さな障害でも出た瞬間に公表しなければならない、なんてことにはなっていません。と言うか、もしそんなことをしてしまうと、キャリアの障害情報ページはあっという間にぎっしりと埋まってしまいます。どんなに品質の良い機器を使っても、何しろ全国区の通信キャリアの使う機器数は膨大ですから、仮に障害率(ダウン率)1ppmだったとしても、毎日何十個という機器故障情報が障害リストを埋めてしまうことになります。

そんなわけで、実際には、加入者への影響度で公表有無を決めているようです。と言っても、各社の詳しい内規まではわかりませんが、一つの重要な基準として、「総務省への報告義務のある事故」の基準値があります。これが、「3万 以上 かつ 継続時間 2時間 以上」となっています。大体、各社ともおおむねこの基準かこの基準よりちょっと厳しいくらいの基準で、障害の公表有無を決めているようです。

ポイントは、「影響人数」と「継続時間」というところ。特に、「継続時間」については重要で、たとえば、機器故障でスタンバイ系に切り替わるときに1秒だけ影響があった、こういう場合は、障害とは言えませんね。つまり、どんなにドでかい障害であろうと、短期間で終息すればそれは障害発生と言えない、とさえ言えます。

これが、要するに対策至上主義の原典。起こってもいい。起こってから復旧までを極限まで短くせよ。

さて一方、ドコモやKDDIが採用しているのは、予防絶対主義。起こしてはならない、という考え方です。ただ、ここで短絡的に「予防絶対主義だから何かが起こってしまうと長期化してしまう」と結論してしまうのは、ちょっと違うと感じる方も多いでしょう。すなわち、「予防絶対主義と対策至上主義は両立しうるのではないか」と言う命題です。

出来うる限り完璧に予防する。同時に、何かが起きた時にも素早く復旧する技術を磨く。これは両立しそうに思えます。

結論から言うと、これは両立しないんですね。

なぜかと言うと、それは予防絶対主義の「障害時の初動対応」にあります。予防絶対主義の原典には「一度起こした障害を繰り返してはならない」というありがたい言葉が記されています。なので、万一の障害が起こった場合、その障害を繰り返さないための対応がまず最優先されるのです。すなわち、「調査のための現状保存」。

障害が起こりました。まずどのノードの障害かを突き止めます。次にそのノードの保守ベンダに連絡を入れ、調査のためのログ取りの準備をします。場合によっては現地に行く必要さえあるかもしれません。この間にたとえば「復旧のためにリセットしていいか」とベンダに聞いて、ベンダがダメーと返答したりなど無駄な時間を過ごします。ベンダがようやくログ取りをはじめ、必要なログがすべて取得出来たらようやく、リセットや電源入れ直しなどの対応を始めます。この間、おそらく1時間以上。下手すりゃ数時間です。[追記]実際の切り分けなんてやってないしログ取りなんて一瞬だろ、と言うご指摘をいただきましたが、一番時間がかかるのが、ログ取りを開始できるまでの手続きと手順です。実際に商用で運用されている装置に対してベンダがアクセスするためには膨大な儀式が必要なのです。入局作業ともなればなおさら。それが、この「無駄時間」の大半だったりします。

要するに、予防絶対主義を貫く限りは、障害に対する初動対応が「次の障害を起こさないための対策」で数時間遅れてしまう。となると、上の公表基準、報告基準であるところの「障害継続時間」が長時間化してしまうわけですね。

で、数年前まではこれでよかったんです。なぜなら、システムは比較的シンプルで、「手におえる」レベルだったから。数年に一度の大障害を糧に信頼性をグングン向上させられるシステムだったから。しかし、前にも書いた通り、新しい時代になり、いろんなシステムが複雑に絡み合い、もはや全体の把握は人間の手におえるレベルを超え始めています。システム自体が生き物のように毎日姿を変える、と言うと言い過ぎかもしれませんが、IPベースでアダプタビリティ・スケーラビリティが向上しているがために、ブラックボックス化した動作の機微がシステム全体にバタフライ効果的インパクトを与えうるものになってきています。大昔にやってたサイトで「フルIP化はシステム挙動をカオティックにするから嫌いだ」なんてことを書いた覚えがありますが、まさにそういったことが起こりつつあるというわけです。

なので、いくら予防を徹底しても、毎日のように新しい障害要因が生まれてくるわけです。もちろんその新しい障害要因のほとんどは日の目を見ずに潰されるわけですが、それをすり抜けたものが障害として花開くわけで、その新しい障害には対策できずに大障害として長時間継続を許してしまうのが、予防絶対主義、と言うことなのかなぁ、と思うわけです。

と言うことで、まぁとある筋から、なぜドコモやKDDIの障害は長時間化しやすいのか、なんていう与太話を聞いてこんな記事を書いてみたりしました。それでわ。

TWEET

行ってみました。行ったのは昨日なのでぜんぜん速報じゃないですけど。ドコモとauしか試せてないですが、どちらもすごく快適です。

駅から出るとき、ドコモ端末では一度アンテナ表示がゼロになるような挙動がありました。セルとしては駅構内セルとはまったく分割してあるようですね。

auのARROWS ZでYoutubeを見ながら突入してみましたが、まったく途切れなく、むしろトンネルを出る前キャッシュが満杯になってしまうくらい。

トンネル内であんまりに快適だったので、速度計測してみました。

ドコモはアプリ計測、auはflash計測サイト利用。平日通勤ラッシュ時間で、乗車状況はつり革にありつけない人が各車両2割くらい、という乗車率。

駒込→西ヶ原
ドコモ: 1.90Mbps
au: 2.84Mbps

西ヶ原→王子
ドコモ: 2.00Mbps
au: 3.62Mbps

王子→王子神谷
ドコモ: 1.43Mbps
au: 2.95Mbps

王子神谷→志茂
ドコモ: 2.34Mbps
au: 4.89Mbps

志茂→赤羽岩淵
ドコモ: 2.50Mbps
au: 3.16Mbps

なんだか、下手に屋外で使うよりよほど快適。巨大な反射物が高速移動しているという最悪の伝播条件でこのパフォーマンスはすばらしい。このトンネル内で使えることにみんな気づき始めたらまた変わってくるでしょうが、とりあえず、トンネル内だからと我慢させられるような問題は今のところは起こってなさそうで何よりです。

以上レポでした。

TWEET