石川先生の2.5GHz最強説についてツイートで軽く補足しようかと思っていたのですが、案外長くなりそうなので記事を一つ起こすことにしました。

さて、記事では「2.5GHzを先んじてゲットしたKDDI/SBMがそれを良く活用しており、2.5GHz帯の世界的エコシステムも整ってきたから最強のバンドなのかも」という感じの説が展開されています。これに関しては私は全く否定するところはないですし、以前私が「ドコモがなぜ品質が悪いのかのデータ見ちゃった」とつぶやいたのもこの件です。

ただ、私がそのデータを見たとき、もう一つ重要な背景が含まれてる、と感じたので、補足というか補強というか、そういう説明を改めてしておきたいと思うのです。単にいい感じの周波数ですよ、というだけではないのです。あくまでこれは私の仮説なので、これが正しいを言い張るつもりはありませんが。

さて、世の中、低い周波数と高い周波数というのがざっくりとあります。2.5GHzというのはちょうどその中間くらいではあるんですが、おおよそ、2GHz以下は低い周波数、それ以上は高い部類、くらいに考えておきます。で、高い周波数は飛びにくい、ちょっとした遮蔽でも止まっちゃう、という話はあまりに有名すぎる話なので理屈は省略しますが、とにかくそういう性質があるので、逆に、高い周波数はそもそも小さなセルになるように設計します。

こんな感じで、低い周波数で広いエリアを実現し、高い周波数をその上に重ねて通信容量を稼ぎます。基本的に携帯電話のエリア設計はこの応用で、東京都心部なんてのはすさまじい数の周波数が飛んでいますが、ど田舎のへき地ではいわゆるプラチナバンドしか飛んでない、なんてことになっているのが普通です。また、キャリアアグリゲーションなどの技術が向上したので、低い周波数を使いながら高い周波数をサブにくっつけて高速通信することもできるようになっていますので、割と柔軟に「ここは使う人多くて品質下がって来たあな、よし、周波数足したろ！」みたいな感じで品質向上施策を打つことができるようになっています。

また、これも原則論として「高い周波数は帯域幅も広いので容量もめっちゃ大きい」というのがあります。というのも含め、「容量が厳しくないところは低い周波数だけで効率よくカバーしつつ、使う人が多いところは大容量の高い周波数をガツンと置く」という戦略が成り立つわけです。

では、こんなエリアの中を端末が移動していくとどうなるか。

こんな感じで、低い周波数はべったりと塗ってあるけど高い周波数は飛び飛び、みたいになっている場合です。

こんな風に、「容量の大きい高い周波数が見えたらそっちに飛び乗って、見えなくなったら飛び降りる」という動きをするでしょうか。実際にはそういうことをする場合というのは結構レアです。

一つ目の切実な理由が、「飛び乗ったり飛び降りたりする」というのは「周波数間リセレクション」「周波数間ハンドオーバ」という動作になってしまうため、周波数サーチのために結構時間がかかるということに加え、ハンドオーバはまだしも、リセレクションの場合は「本来必要のなかった制御チャネルの通信が発生してしまう」という問題が出てきます。LTEといえど制御チャネルとデータチャネルは分かれていて、制御チャネルは容量を増加させるための各種技術がほとんど使えません。つまり、制御チャネルは容量が小さい。データチャネルを削って容量を増やすこともできますが、制御チャネルの容量を1ビット増やすためにデータチャネル容量を5ビット削る、みたいな無駄が生じます。ということで、エリアを設計するとき、特に「どの周波数帯で待ち受けするか」という設計では、こういった無駄を減らすためになるべく一続きの周波数に居続けるような設計をすることになります。

もう一つの理由は、そもそもキャリアアグリゲーションで高い周波数を後から足せるので、無理に高い周波数に飛び乗る必要はない、ということです。キャリアアグリゲーションという強力な武器があるのに周波数間リセレクションなんていう無駄なことをする必要はないよね、という話ですね。

ということで、ドコモのエリアはこのセオリー通りのエリアになっているようです。端的に言うと「高い周波数で待ち受けしない」というポリシー。で、この「待ち受け周波数」というのは、データ通信を始めようとした最初の瞬間に接続されるファーストステップの周波数であり、データ多いからキャリアアグリゲーションで周波数足すか、という判断がされるまでの間のつなぎで使われる周波数でもあります。

だんだん見えてきましたね。そうなんです。ドコモは、800MHz帯や1.7GHz帯という低めの周波数になるべく滞在するようになっているため、大概の人が最初の通信をその辺の周波数で始めてしまいます。当然、最初のちょっとの間だけとはいえ、ユーザ数が多ければバカになりません。通信のしはじめでやたらパケットが止まるのはおおよそコレ。

加えて、5G対応端末であればすぐに5G周波数を足してあげようという動作もしようとします。この5Gがまた曲者なんです。もうお分かりかと思いますが、5G周波数は高い周波数で、上の図のように飛び石エリアになってるんですね。しかし、低い周波数のセルは「このセルは対応する5Gのセルがあるよ」という情報しか持ってないので、端末に5Gが実際に見えるかどうかサーチさせて5Gを足す動作を判断します。サーチする、飛び石の端っこが見える、見えるから足したろ、5G足したんだからデータは全部そっちに流したろ、足してみたら結構品質悪くて全然データ流れんやん、というのがパケ止まりの正体。何しろ飛び石がダメなんです。

その理屈だったら、KDDIもSBMも同じでしょ？　という話になるんですよね。ここで、件の2.5GHzが登場します。実際の2.5GHzはですねえ、だいたい、こんな感じになってます。

みっちり。

で、ここからが2.5GHz独特の特徴なんですが、えーと、2.5GHz帯は、携帯電話ではありません。WiMAXとかXGPとか言ってたアレ、すなわち、「BWA(ブロードバンドワイヤレスアクセス)」という携帯電話とは別のシステムなんです（法的には）。そして、建前上、BWAはそれ単体でサービスを提供できなければなりません。また、BWAは「時速○○kmの移動でもちゃんと使えるよ」という宣言を最初にしています（細かい数字忘れちゃった）。そういう約束で周波数をもらってるんですね。つまり、BWAはBWAだけできちんと高速移動を担保できる連続したエリアを作らなければならなかったという事情があったんです。当然、BWAバンドでの待ち受けも必須要件です。このためにUQとかWCPとかはめちゃくちゃ汗かいてるはずなんです。

さらにここに5G事情の後押しが入ります。5GはBWAとはまた別の話じゃん、と思われるわけですが、一方、5Gのエリア構築を進めるときに、5Gのためだけに電波塔を建てるか？　という話です。いや、電波塔とは言っても都市部ではビルの屋上の間借りとかではあるんですが、そういう場所を新しく準備するには、大都市中心部のビル屋上は枯渇しすぎ。ということで、KDDIとSBMがとった手段は、BWAの基地局が置いてあるところを使っちゃおう、というアイデア。で、「高めの周波数は飛ばないのであえてセルを小さめに設計する」というのがここで活きます。あえて小さく設計したセルは、BWAより高めの5G周波数にもマッチするんです。つまり、5Gでもみっちりカバーができるんです。だから、飛び石の端っこをつかんでパケ止まり、ということが起こりにくい。5Gの大容量を効率よく使える。2.5GHz自体の容量は大した問題ではなく、その場所に5Gの超大容量周波数をみっちり展開できた、これがKDDI、SBMの品質が良い理由なんです。

そして最後の決め手は、端的に言えば各社のポリシーの問題。「連続的にみっちり確保できないのであればできるだけ低い周波数だけで待ち受けさせよう」というドコモに対し、KDDI、SBMは「高いところもみっちり確保できる前提で高い周波数で待ち受けさせよう」になってるんじゃないかと思うわけです。なので、高い周波数や5Gを足すという動作を省けるし、低い周波数がファーストステップ通信でつぶされるということを防げている、というあたりが体感品質の差になってる気がするなあ、というところまで、当初データを見たときに感じたわけです。

ということで、私の説は、「2.5G TD-LTEが最強なのではなく、それを展開するときに余計な汗水を流したことが5Gエリア構築で活きてる」なのです。

という感じで補足をさせていただきました。

TWEET

無線にゃん、ここ数年大規模通信障害を起こし、まことにもうしわけ

という話ではなくて。昨日のauとか、去年くらいのドコモとか、大規模通信障害というやつが起こっていますね。しかも、起こったらとことん大規模。

実際、この辺は避けようがないというのが実態だと思うんです。そもそも論ですが、携帯電話ネットワークというのは、どういう風に作られているのか、というと、超たくさんの基地局をたくさんの制御局に収容してそれらをほどほどの数の交換局に集約して、みたいな感じに作られているものですよね。LTE以降、この辺はIPアクセスによるフラットなネットワークを志向、なんていうことも言われていますが、実際に物理的にネットワークを作ろうとすると、どうしてもどこかに「呼処理」が集中するポイントが生じてしまいます。

呼処理というのは、簡単に言えば、ある携帯電話が正当なものであることを確認しその通信要求が正当なものであることを確認し適当なポリシーのもとに通信リソースを割り当てる、一連の処理のことです。ある一人の加入者が全国どこでも使えるようにする、という要求を満たす場合、すべてのネットワークノードは必ずつながっていなくてはなりません。さらに、その加入者の通信オプションや課金を正しく扱うためには、その加入者の情報がすべてのノードで整合性ある形でアクセスできなければなりません。今回のauの障害でもキーワードで出てきた、加入者情報の不一致云々、の話です。

仮に加入者情報サーバを二重化していたとしても、その二台のサーバの間に「データの不整合」が生じてはならないので、二台の間では常に整合性のためのやり取りが行われます。また、今回の障害の原因と言われているVoLTE交換機（IMS）も同じように「ある加入者の唯一性」を保証しなければ正常な処理はできません。そうした唯一性の保証が必要なサーバ類をたくさん置いて障害が起きても一部にしか影響が出ないようにする、というのは当然どこのキャリアもやっているわけですが、では、それらのサーバ間を直接メッシュ接続できるか？　というと、そんなことはもちろん無理です。メッシュ接続というのは、例えば2台と3台のサーバ群同士をつなげる場合、6本の線を直結させる、というやり方。今や加入者情報サーバだのIMSだのは何十台という規模で、メッシュ接続するとなると数百本の接続が必要になります。もちろん、論理的にこれができることは当然ですが、じゃあ物理的にできるか、というと、一つの筐体に何百本のケーブルをつないでそれぞれが独立した回線で全国につながる、なんていうことは無理です。回りくどく書きましたが、物理的にはどこかで集約するための巨大なルータ的なものに入ることになります。このルータにはもちろんその他いろんな通信が論理的には別々の回線のようにふるまいながら収容されています。

さて、もしこのルータが壊れたら。当然、このルータも冗長化されていますから、即座にスタンバイ系に切り替わるわけで、一見、あらゆる呼処理が集中していても問題がないように思われます。ただ、この冗長化した二台のルータは、つながっています。比喩でもなんでもなく、冗長、というのは、その二台を束ねる何らかのコントローラの上で成立するものです。このコントローラ機能は、古くは独立した装置だったりしましたが、最近では二台のルータ間やルータの下位ノードとの間で成立している冗長化プロトコルのステートマシンという論理的な存在が担っています。なんにしろ、その二台の状態を把握して障害時に正しく切り替え処理を行う頭脳の役割が存在し、それを介して必ず冗長した二台のルータはつながっている、ということです。

そしてこの頭脳そのものは、冗長化できません。だから、もしこの頭脳に何らかの変調が起きると、冗長機能が働かなくなります。もちろん、その状態でもルータ自身が正しく動いていれば問題ありませんが、この頭脳が変調を起こすような設定の誤りやバグというのは、えてして、片方のルータが落ちたときに顕在化するものです。つまり、あらゆる呼処理が集中しているルータ自身、どんなに完璧な冗長を組んだとしても全台破綻、ということがありうるわけです。これは隕石が落ちてくるほどの低い確率ですが、でも実際に隕石は落ちてくる。だから、そうした事態に備えた訓練を各キャリアは欠かさないわけです。

こうした呼処理が集中する場所で通信断が起きると、先ほどの「唯一性」と「整合性」を重視するサーバたちは一斉にうごめき始めます。データの不整合が発生した可能性がある以上、何とかして最新の情報を得なければならないからです。また、そういった状態になると、端末側も通信の接続や再開ができないために、何かあったのかもしれない、ということで、通信の手続きを最初からやり直そうとします。こうしたことが雪だるま式に膨らんでいくことで設備の処理能力が枯渇し、なおかつ「唯一性」に自信が持てなくなった各種ノードは通信手続きをやめてしまうわけで、大規模な障害に至るということです。

こうした大規模な障害を回復させるには、まず、入ってくる量を減らすところから始めます。つまり、基地局で「規制」をかけます。これで、端末が何度もアクセスすることを防ぎます。次に、「唯一性」と「整合性」を回復させなければなりませんが、これも、冗長を組んだたくさんの装置を一台ずつ同期させていくという地道な作業になるはずです。なおかつ、その同期させようとするデータが大きすぎるとこれまた設備負荷になり、安全弁が働いて途中で止まり、芋づる式にデータすべてが再び不整合、なんていう面白いことが起こったりします。面白くないですねすみません。そんなことを考えると、一度集約部分で混乱が起きるとその終息にどのくらい時間がかかるかというのは全く誰にも読めない、と思われるわけです。

実際、最近は小規模な障害は比較的減っていますが、ごくまれにこういうどでかいのが起こる感じですよね。それは、障害を防ぐ仕組みがどんどん進んでいるから、ということの裏返しでもあります。標準化でも障害耐性というのは大きなテーマで、障害を防ぐ、障害が起きた時も小規模で済ます、起きた障害が速やかに収束する、そうした仕組みを標準の中にどんどん作り込んでいるので、実は日常的に小さな障害は起こってるんだけど利用者にばれるほどにまで大きくならない、みたいなところはあります。で、最後に残ったのが、こういう物理的にドカンとくるやつ。こういうのもしっかりと機能と収容加入者数をばらして分散化していけばいいわけですが、いかんせん、「唯一性」の問題があり、どこかにどうしても集中する場所が生じることになります。仮にそういうのを物理的にばらして置いたとしても、その物理的に離したサーバの間を加入者が移動するような場合には情報を交換する必要があるわけで、やっぱりそこでは最低二台の間での集中は起こります。ついでに言えば、昨今の官製値下げの影響で、各社ともぎりぎりまで設備を集約して効率化しようと頑張っています。三社ともアホみたいに利益を出しているように見えますがそれぞれがそれぞれに帳簿上の利益を減らせない大人の都合があってしわ寄せは設備投資に向かうわけです。

こういうことが起こらないようにするにはどうすればいいのか？　という話については、まあぶっちゃけ、完全に物理的に隔離された冗長ネットワークがあればいいんじゃね？　ってことになります。簡単に言えば、別キャリアです。もちろん別キャリアにしてローミングで救済する仕組みにしても、そこに「ローミング接続」があったら無意味です。なので、ローミング情報も何らかの形で隔離して持っていく必要があります。13桁のパスワードをかけたUSBとかで。というのは冗談にしても、実際、一つのキャリアの全域である加入者の唯一性を保証するという条件でネットワークを物理的に分断することはできないので、最悪他キャリアにローミングできる仕組みを全キャリアでしっかりと話し合った方がいいよね、と私は思うのです。もちろん、大障害の時にローミングアクセスが集中してローミング先も落ちた、なんていう本末転倒なことは必ず起こるので、ローミングでの利用については相当に絞った形にするしかないでしょうが。で、そのローミング利用料をお互いに払うようにすれば、ある意味、障害のリスクをカネで解決してるわけですから、お互いいろいろと楽になるよね。

ということで、無線にゃん、今後一切このような長期間の障害を起こすことのないようしっかりと見直しを・・・いや、別にしなくていっか。ではまた来週か来月か来年か♪

TWEET

えー、auネットワークでiOS12にアップデートするとSMSが使えなくなるという話があるそうですが、どんなメカニズムでしょうか、というご質問をいただいているのですが。

知らん、アップルに聞け。

まあ一言で言うとこういうことになるんですけど。いや、単純にバグです。iOSのバグ。まあ、auのネットワークはCDMA2000と相互接続（？）している都合もあっていろいろと癖があるのは確かなんですが、それでも3GPP標準どおりに作ってあるのは確かです。なので、アップルの単純なポカ。です。

そもそもの話、しますね。アップル、iOS、バグ多いです。そんなこと無い、と主張する人も多いでしょうが、あくまで私の主観として、iOSは結構酷いOSです。

ユーザインターフェース部分に関しては、かなり洗練されています。なので、ユーザとして使う分にはほとんど不便を感じないと思います。

問題は、通信。プロトコルの実装。本当にバグ多いです。バグと言うか、分かっててやってる感じがする変な実装が多いようです。アップルが世界中で「俺様商売」をしているのはご存知のとおり、なので、あえて変な実装をしてiOSとしての変な機能を実現したとしても、世界中のほとんどのインフラベンダーは泣く泣く変な実装にあわせてアップデートします。もちろんそのお金を出すのは通信事業者。通信事業者にお金を払っているのは一般のスマホユーザ。アップルのおかしなバグまがいの実装のために結構な金額がどぶに捨てられています。Androidユーザはもっと怒っていい（笑）。

Androidもプロトコルがらみのバグは少なくないですが、メーカ独自実装の部分に集中しています。3GPPにきっちり規定された部分に関してはかなりバグ少ないです。めちゃくちゃ品質高いです。「出来上がった標準を活用する」という立場と「俺様が標準だ」という立場の違いですかね。Androidはオープンなリソースを共有しようという精神からできたOSなので、通信プロトコルの実装に関してもあくまでオープン、素直に標準（オープンリソース）どおりに作られています。そこにあえて変なメーカカスタマイズを入れた部分が大体バグを出します（笑）。

あと数年はアップルもこういう商売ができるとは思いますが、その先は見てるでしょうかね。アップルのシェアがある程度下がったどこかの段階で「こんなマイナーで変な実装、もうケアしてやるのやめようぜ」と世界中のインフラベンダが声を揃えたとたんに破綻するんじゃないかな、なんて思います。

まあ、そういいつつも、そうなったらそうなったでiPhoneを切り捨てられないいくつかの国（特に日本）では独自ネットワーク化が進みインフラコストが上がってスマホ料金が諸外国に比べてどーんとあがる、ってことになるんでしょうけど。総務省の方にはこういう視点で見てほしいですけどね。無理か。

TWEET

ということで、新iPhoneの対応バンドなどの情報がそろったので、今時点での私のiPhone用インフラ評価をまとめてみます。こうやって並べてもやっぱり一長一短と言う感じですねぇ。ちょっと先のことを考えればドコモが一番よさそうな気がする、くらい。

ドコモ	エリアについては、都市部のLTEカバーは強力。ただし郊外では全くKDDIに追いついていませんし、穴だらけでバッテリへのダメージも大。800での整備も加速するという話なので、今後は徐々に良くなりそうです。ドコモの特長は屋内。四社共同整備の公共トンネル(地下鉄など)では差が出ませんが、一般の民間施設をきめ細かにカバーするところはドコモが一番強いので、高品質で使える屋内施設はかなり多くなっていくはずです。 iPhoneは1.5Gを外したのですが、対応している800、1.7、2Gを持っているため、今後容量についても徐々に強化されることが見込まれます。最強を目指すと自称していますが、名実ともに最強インフラになる可能性が一番高いキャリアです。
KDDI	広さだけで言えばエリアは圧倒的。800をベースにエリアを作っているので、エリアの連続性や屋内への浸透も抜群。ただし、飛びすぎるためにS/N比がかなり劣化傾向で、都市部では通信速度・品質が下がる傾向が今後強くなっていくと思われます。これを補完するバンドの候補がすでにiPhone5で汚れている2Gしかないため、むしろ今がピークかも。ただそれを差し置いても、エリア面積で他社を圧倒する状況は当面続きそう。 容量に関しては、800と2Gと言う選択しかないため、他の二社に比べるとかなり不利。セルの分割が難しい800でそれをしなければならないなど巨額のエリア投資が必要なので、今後容量に不安が出てきます。あとペアになるシステムがLTEと親和性の低いCDMA2000なので、不整合による不都合が起こりやすいかも。
ソフトバンク	2Gと1.7Gは元々競合別キャリアとして整備してきたものなのでほとんど重複エリア、900帯のLTEを打ち始めればほどほどには広がると思われますが、それでも900帯の3Gエリアは他社800帯の広さに全くかなわないので、エリアの広さ自体での逆転は当分あり得ないです。エリア内では穴など無く連続エリアを確保できていて行儀のいいエリア構成。屋内カバーは相変わらず弱し。 900、1.7、2Gと言う三帯域を使えるという意味でドコモと同等のポテンシャルを持ちますが、900LTEの都市部整備はまだまだ先になりそう。ただし、都市部ではウィルコム譲りのストリートセルのコンセプトで高品質のマイクロセルを構築していて、容量にはかなりプラス。

[追記] 一応、各キャリアのLTEエリアの目安はっときます。

TWEET

最近実人口カバー率がどうとか言う話が増えて、昔ながらの人口カバー率について人口カバーと面積カバーの関係と言うのを作ったのがあまり役立たずになっちゃってる感じなので、実人口カバー率について、同じような分析をしてみました。

ネタは簡単で、国勢調査の500mメッシュデータを並べて、データにしただけです。しただけですと言いつつ、データ量が超多いのでめんどくさかったのですが。

で、このデータを作って気が付いたというか思い出したのですが、日本って、総面積の3割くらいしか人が住んでないんですね。ってことで、総面積に対する比率だとよくわからなくなるので、「人が住んでる面積に対する比率」を「実面積カバー率」と定義して、データを作成。

まずグラフ。

旧人口カバーと傾向はほぼ同じ。

次に、人口カバー率に対しての順引き・逆引き一覧表。

実人口カバー率1%刻み→実面積カバー率

実人口カバー率	実面積カバー率	面積カバー率
1%	0.04%	(0.01%)
2%	0.08%	(0.03%)
3%	0.13%	(0.04%)
4%	0.18%	(0.06%)
5%	0.23%	(0.07%)
6%	0.28%	(0.09%)
7%	0.34%	(0.11%)
8%	0.40%	(0.13%)
9%	0.46%	(0.15%)
10%	0.53%	(0.17%)
11%	0.59%	(0.19%)
12%	0.66%	(0.21%)
13%	0.73%	(0.23%)
14%	0.81%	(0.26%)
15%	0.88%	(0.28%)
16%	0.96%	(0.31%)
17%	1.04%	(0.33%)
18%	1.13%	(0.36%)
19%	1.21%	(0.39%)
20%	1.30%	(0.42%)
21%	1.39%	(0.44%)
22%	1.48%	(0.47%)
23%	1.58%	(0.50%)
24%	1.68%	(0.54%)
25%	1.78%	(0.57%)
26%	1.88%	(0.60%)
27%	1.99%	(0.63%)
28%	2.10%	(0.67%)
29%	2.21%	(0.71%)
30%	2.33%	(0.74%)
31%	2.45%	(0.78%)
32%	2.57%	(0.82%)
33%	2.69%	(0.86%)
34%	2.82%	(0.90%)
35%	2.96%	(0.94%)
36%	3.09%	(0.99%)
37%	3.23%	(1.03%)
38%	3.38%	(1.08%)
39%	3.52%	(1.12%)
40%	3.68%	(1.17%)
41%	3.83%	(1.22%)
42%	3.99%	(1.27%)
43%	4.15%	(1.33%)
44%	4.32%	(1.38%)
45%	4.50%	(1.43%)
46%	4.67%	(1.49%)
47%	4.86%	(1.55%)
48%	5.04%	(1.61%)
49%	5.23%	(1.67%)
50%	5.43%	(1.73%)
51%	5.64%	(1.80%)
52%	5.85%	(1.86%)
53%	6.06%	(1.93%)
54%	6.28%	(2.00%)
55%	6.51%	(2.08%)
56%	6.75%	(2.15%)
57%	6.99%	(2.23%)
58%	7.24%	(2.31%)
59%	7.50%	(2.39%)
60%	7.77%	(2.48%)
61%	8.05%	(2.57%)
62%	8.34%	(2.66%)
63%	8.64%	(2.76%)
64%	8.95%	(2.86%)
65%	9.28%	(2.96%)
66%	9.62%	(3.07%)
67%	9.97%	(3.18%)
68%	10.34%	(3.30%)
69%	10.72%	(3.42%)
70%	11.13%	(3.55%)
71%	11.56%	(3.69%)
72%	12.00%	(3.83%)
73%	12.48%	(3.98%)
74%	12.98%	(4.14%)
75%	13.51%	(4.31%)
76%	14.07%	(4.49%)
77%	14.67%	(4.68%)
78%	15.30%	(4.88%)
79%	15.99%	(5.10%)
80%	16.71%	(5.33%)
81%	17.50%	(5.58%)
82%	18.34%	(5.85%)
83%	19.25%	(6.14%)
84%	20.23%	(6.45%)
85%	21.30%	(6.79%)
86%	22.46%	(7.16%)
87%	23.72%	(7.57%)
88%	25.11%	(8.01%)
89%	26.65%	(8.50%)
90%	28.35%	(9.04%)
91%	30.25%	(9.65%)
92%	32.40%	(10.33%)
93%	34.84%	(11.11%)
94%	37.65%	(12.01%)
95%	40.96%	(13.07%)
96%	44.96%	(14.34%)
97%	49.97%	(15.94%)
98%	56.67%	(18.08%)
99%	67.03%	(21.38%)
100%	100.00%	(31.90%)

実面積カバー率1%刻み→実人口カバー率

実面積カバー率	実人口カバー率	面積カバー率
1%	16.45%	(0.32%)
2%	27.09%	(0.64%)
3%	35.32%	(0.96%)
4%	42.06%	(1.28%)
5%	47.78%	(1.59%)
6%	52.72%	(1.91%)
7%	57.03%	(2.23%)
8%	60.81%	(2.55%)
9%	64.15%	(2.87%)
10%	67.09%	(3.19%)
11%	69.69%	(3.51%)
12%	71.99%	(3.83%)
13%	74.04%	(4.15%)
14%	75.88%	(4.47%)
15%	77.53%	(4.78%)
16%	79.02%	(5.10%)
17%	80.37%	(5.42%)
18%	81.60%	(5.74%)
19%	82.73%	(6.06%)
20%	83.77%	(6.38%)
21%	84.73%	(6.70%)
22%	85.62%	(7.02%)
23%	86.44%	(7.34%)
24%	87.21%	(7.66%)
25%	87.92%	(7.97%)
26%	88.59%	(8.29%)
27%	89.22%	(8.61%)
28%	89.80%	(8.93%)
29%	90.35%	(9.25%)
30%	90.87%	(9.57%)
31%	91.36%	(9.89%)
32%	91.82%	(10.21%)
33%	92.26%	(10.53%)
34%	92.67%	(10.85%)
35%	93.06%	(11.16%)
36%	93.43%	(11.48%)
37%	93.78%	(11.80%)
38%	94.11%	(12.12%)
39%	94.43%	(12.44%)
40%	94.73%	(12.76%)
41%	95.01%	(13.08%)
42%	95.28%	(13.40%)
43%	95.54%	(13.72%)
44%	95.78%	(14.04%)
45%	96.01%	(14.35%)
46%	96.23%	(14.67%)
47%	96.44%	(14.99%)
48%	96.64%	(15.31%)
49%	96.82%	(15.63%)
50%	97.01%	(15.95%)
51%	97.18%	(16.27%)
52%	97.34%	(16.59%)
53%	97.49%	(16.91%)
54%	97.64%	(17.23%)
55%	97.78%	(17.54%)
56%	97.91%	(17.86%)
57%	98.04%	(18.18%)
58%	98.16%	(18.50%)
59%	98.27%	(18.82%)
60%	98.38%	(19.14%)
61%	98.49%	(19.46%)
62%	98.58%	(19.78%)
63%	98.68%	(20.10%)
64%	98.76%	(20.42%)
65%	98.85%	(20.73%)
66%	98.92%	(21.05%)
67%	99.00%	(21.37%)
68%	99.07%	(21.69%)
69%	99.13%	(22.01%)
70%	99.20%	(22.33%)
71%	99.26%	(22.65%)
72%	99.31%	(22.97%)
73%	99.37%	(23.29%)
74%	99.42%	(23.61%)
75%	99.46%	(23.92%)
76%	99.51%	(24.24%)
77%	99.55%	(24.56%)
78%	99.59%	(24.88%)
79%	99.63%	(25.20%)
80%	99.66%	(25.52%)
81%	99.69%	(25.84%)
82%	99.72%	(26.16%)
83%	99.75%	(26.48%)
84%	99.78%	(26.79%)
85%	99.80%	(27.11%)
86%	99.83%	(27.43%)
87%	99.85%	(27.75%)
88%	99.87%	(28.07%)
89%	99.89%	(28.39%)
90%	99.90%	(28.71%)
91%	99.92%	(29.03%)
92%	99.93%	(29.35%)
93%	99.95%	(29.67%)
94%	99.96%	(29.98%)
95%	99.97%	(30.30%)
96%	99.98%	(30.62%)
97%	99.98%	(30.94%)
98%	99.99%	(31.26%)
99%	100.00%	(31.58%)
100%	100.00%	(31.90%)

何かに使ってやってください。

TWEET

ちょっと古いネタですが、auの障害の時に音声もつながらなくなったのはどうしてでしょうか、という質問をいただいています。というのも、CDMA2000はデータと音声が独立したシステムなので仮にデータが輻輳しても音声には影響は出ないのではないか、ということからです。

普通に考えれば確かにその通りなのですが、そもそもLTEと旧システムが連携しているということを考えるとちょっと問題が複雑になってきます。

LTEが障害で全く使えない、完全にゼロ、という状態であれば、すべての端末は3Gに落ちてしまい、あとは3Gの輻輳だけが問題になってきます。CDMA2000であればシステムが独立しているので影響は出にくいかもしれません。もちろん、データ(EVDO)側が完全に輻輳でつながらないと、音声系(1x)のデータ回線に切り替わるということも起きるので(iPhoneの○印が出るアレ)、これが原因で輻輳ということは考えられますが、それでもデータ用チャネルよりは音声用チャネルを優先制御するくらいのことはやっているはずなので、この状況での影響は出にくいでしょう。

しかし、先ほどの記事の音声連携の仕組みを見るとわかるのですが、音声着信の信号(ページング)はLTE上で送信され、LTE上でそれに応答するのが連携システムの基本です。もしLTEが障害で信号がほとんど通らない状況だとすると、このページングが端末まで届かないため、音声着信ができないということになります。また、発信でも最初のネゴ(どの周波数が利用可能か、など)はLTE網を経由して他網と通信します。このため、LTE障害で信号が通らないとこれもアウトです。

上記の「ページング」や「ネゴのための信号」、実はどちらもLTEにおける特定装置を経由します。すなわち「MME」なんですね。ってことは、MMEが落ちるとどちらもダメになってしまうんです。先日のau障害はまさしくMMEの障害だったため、音声通話ができないというユーザが出てくる可能性が確かにあったわけです。当初、障害箇所はMMEっぽいという発表、それでも音声に影響ありませんと書いてあったのを見て私は「そんなわけないんだけどなぁ」と思ったくらいです。

もちろん、完全に全端末を3Gに落とせればこのタイプの通話不良は回避できるんですが、そもそもそういったこと(たとえば端末を強制Detachさせること)を制御できるMMEが死んじゃってるので、MMEが落ちたことに気づかずに在圏したままの端末はほどほど残ってしまうことになります(通信をしようとしてMMEからの応答がなくて3Gに落ちる、というような契機がないと普通はMMEが落ちていることに端末は気づかない)。いっそ全基地局の電波を止めるくらいのことをすればよかったんでしょうがそこまでやる大胆さをKDDIは持ち合わせず、半端にLTEに残ってしまった端末が音声不可になっていたものを思われます。実は私の端末もしばらくの間、LTEの電波つかんでました。

ということで、LTE障害なのに音声影響はなぜの話でした。あ、上の推測は全部憶測ですよ、念のため。

TWEET

またまたauがやらかしたみたいで、いろいろ解説希望のメールをもらっているわけですが。

今回の故障個所は「基地局制御装置」みたいに発表されていますが、具体的にどこと言うのはよくわかりません。が、LTEのシステムの中でそれに相当しそうなのは、たぶんMMEかなぁ、と言う気がします。もちろん、基地局の監視制御用のシステムとかの独自装置の可能性もあります。

で、確か前回もMMEが障害って言ってたなぁと考えた時にふと思った件があって。こちらの基地局数で見ると、2013/05/30現在の総基地局数(バンドごと(細かいことを言うとキャリアごとだけど現在は実質1バンド1キャリアしか入らないので)に別のノードなので「制御装置」から見えるノードの数という観点で数えた時)は、ドコモが27716局、auが46575局、SBMが23249局と、auはほぼダブルスコアで他よりも局数が多いんですよ。しかも、建設開始からの期間も短くて。

つまり、MMEであれ独自装置であれ「基地局制御装置」の故障というのは、この基地局数の急増とそれが多すぎることに起因するんじゃないか、と思うんです。

3Gだと、何年もかけて徐々に増やしていった基地局数を、auはこの1年で一気に5万近くにまで増やしているわけです。正直、正気の沙汰とは思えないペース。

普通この手のシステムって、ノード数や加入者数の増加に合わせて、容量比で使用率が○%を超えたら装置を増設しましょう、みたいな形で管理しているはずなんですね。それが全然追いついていない疑惑が出てきます。

auの基地局の急増の理由は簡単で、ほとんどの3G基地局にアドオンでLTE局を追加できる仕組みになっていたから。もちろんドコモでもSBMでもそういうタイプの局はありますが、au程徹底して既設局にLTEをゴリゴリと追加していってはいないはずです。CDMA2000を一秒でも早く収束させたいがために全エリアを強引にLTE化していこうという意思が感じられる、と言うのは前にも書いた通り。

その強引な局数の急増に対して、「制御装置」の増設が間に合わなかった、と見ます。もちろん局数増設計画と制御装置増設計画はリンクしているでしょうが、LTE開始からまだわずか半年、おそらくその計画はLTEのノウハウが貯まる前に設計した古い基準なので、いざ始めてみると全然追いつきませんでした、と言うのが今の状況なんじゃないかと思うわけです。

前回は発表は「MMEバグ」となっていましたが、ソフトなんてバグがあるのは当たり前、バグで1台2台つぶれてもいいような冗長構成をとっておくべきで、幸い、LTEはフルフラットNWなので冗長とロードバランスがやりやすいようなシステムなわけで、そういうことはやりやすいようになってるんですよね。それでも障害ってことは、MMEの台数が局数に全然追いついていない、ってことだと思うんです。バグを出すのが悪いんじゃなくて、バグが出ても誰にも気づかせないってことが重要なんですよね、前にも似たようなことを書きましたが。LTEは単に台数を増やせばこういうところをカバーできる便利なシステムで障害は顕在化しにくいシステムのはずなんですが、それでもこれだけやらかすってことは、絶対的な処理量不足とか、その辺の疑いが強いです。

そんな感じなので、昨日今日みたいなのは、もうしばらく繰り返すんじゃないかなんて思っています。んー、データ回線をauのみに依存する生活は危ないですね。昨日今日は3Gで使ってましたが、3Gの遅いこと遅いこと。ドコモ系も一つ確保しておきますかね。

そうそう、「3Gもつながらない」という質問もありましたが、私もしばらくそんな状態でした。障害そのものというよりも、LTEな端末がみんな3Gに落ちちゃったことが原因でしょうね。LTEのために3Gのキャリア数も減らしているでしょうから従来よりも簡単にひっ迫するようになっているはずです。でわ。

TWEET

ちょっと面白い調査結果を見せてもらって。一応ほんとは出しちゃダメ的な情報だったので細かい結果やソースは伏せますが、面白いなぁ、と言う結果だったので、雰囲気だけ。

ドコモ、au、ソフトバンクの各社のユーザをランダムに抽出したアンケート調査みたいなもので、「エリアが広いキャリアはどこだと思いますか？」と言うような質問をした結果だと思ってください。その時に、各社のユーザがそれぞれどんな回答をしたのか、と言うのが面白くて。

ドコモユーザでは、ほとんどのユーザが「ドコモ」と回答。auと答えた人は少数、ソフトバンクと答えた人はほぼゼロ、と言う感じ。

auユーザでは、やはりほとんどが「au」と回答し、残りが「ドコモ」と答えています。こちらもソフトバンクと答えた人は極々少数。

ところが、ソフトバンクユーザだけは、半分が「ドコモ」と答え、4割が「au」と回答、「ソフトバンク」と答えた人は1割しかいないんですね。

これって、まぁ実際にソフトバンクのエリアが狭いことは仕方がないとしても、ソフトバンクユーザってそれをちゃんと理解しててソフトバンクを使ってる人が多いってことなんですね。逆にドコモ・auユーザはよく訓練されている(笑)というか。

実際、私の感覚としてもドコモ≧au＞＞ソフトバンク、って感じなので、調査結果がおかしいとは思わないんですが、「エリアが狭いっていう自覚があるのにそれでもソフトバンクを使う」ってことは、エリア以外の満足度が、実はソフトバンクってすごく高いんじゃないかな、とも思うわけです。逆に、もしドコモやauで、エリアっていう化けの皮がはがれでもしたら、一気に瓦解する可能性もある、ってことで。

エリアって実際に目に見えるものじゃなくて正直「言ったもん勝ち」の世界なんですよね。日本の津々浦々までエリアを実地確認出来るような人なんて普通はいなくて、あくまでWEB上のエリアマップをうのみにするしかないし、エリアマップなんていくらでも嘘を描けます。

実地確認したとしても実はそこにはいろんな欺瞞が隠れる要素があります。端末上に「エリア内」を示すアンテナマークを表示するかどうか、って、比較的簡単なパラメータ調整でいくらでもいじくれるんです。実際には全く通信できないような超弱電界でも、端末に対して「まだ留まれ」と指示することができるんですよ。実際には順番は逆で、端末が最初に受信したネットワークパラメータの中に「電波をあきらめて圏外になる閾値はこのくらいですよ」って書いてあるんです。その閾値を下回らない限り、圏外表示にはならない。もちろん、超弱電界環境だと、実際の通信は失敗しまくるのですが(失敗した結果圏外表示になることもありますが)、表示が圏外になってもならなくてもどうせ使えないなら、嘘でもアンテナマーク立てておけばエリアがあるかのように見せかけられるわけです。そんな非常識なことをやっている事業者は(今のところは)ないみたいですが。

閑話休題。そんなわけで、実際のエリアは及ばないとはいえ、それがわかってても使いたいと思う魅力がソフトバンクにはあるのかもしれないなぁ、と言う面白い調査結果でしたっていう話でした。実際どの辺がポイントなのかなぁ。料金も端末もほぼ横並びなのになぁ。あれですか、お父さんですか。あの犬アホっぽくていいよね。

TWEET