スマートフォン 表示
メールフォームでよろづ質問受付中
スマートフォン速度統計への人柱ご協力をお願いします。

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

ネタは簡単で、国勢調査の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 TWEET

2012/11/21 10:00 · 事業考察, 技術動向 · (No comments)

2.5G(2.6G)帯の新割当に関して、WCP、UQはともかく突然ドコモも出てきていて、どういうことになりそうか解説が欲しいです、と言うお便りをいただきました。

前にもちょろっと書きましたが、2.5Gの上の方は衛星放送的サービスのモバHOで使ってて、そこが空いたので国際割当に従って無線ブロードバンド向けにさらに割り当てますよ、ってことになってて、どんな人が使いたいか募ってみたらさりげなくドコモが、っていうのが、今の状況。

どういう風に使いたいのか、ってのをおおざっぱに整理すると、ドコモ以外が、要するにTD-LTE。AXGPとかWiMAX2.1とか言ってますが、どちらも中身はTD-LTE。WiMAX2.0までが由緒正しきWiMAXで、その採用の可能性も(地域WiMAX事業者などでは)ありそうな要望内容ですが、まぁ普通に考えて今後デバイス調達がシュリンクしていくであろうレガシーWiMAXを新しく導入するのは筋が悪いですよね。どこに割り当てとなっても、結局はTD-LTEになるだろうと思っています。

さて問題がドコモ。ドコモがここまで徹底的にTD-LTEを嫌うとは思ってなかったんですが、上下非対称キャリアアグリゲーションの下りオンリー帯域として使う、と言っています。

キャリアアグリゲーションってのは、LTE Advancedで採用されている、複数の搬送波を束ねて高速通信を実現する方式。同じバンド内で束ねるのはもちろん、遠く離れたバンドをまたがって束ねることも可能で、さらに、上下ペアが前提のFDD-LTEであっても、上り搬送波は最低一つあればよく、束ねる他のバンドは下りだけでOK、と言うようなモードもあります。

つまりドコモが狙っているのは、たとえば、下り2GHz帯10MHz幅+下り2.5GHz帯20MHz+上り2GHz帯10MHz、みたいな組合せ。これで、下り通信速度を超ブーストできます(上りは従来通り)。この組み合わせだと、200Mbps超が可能です。

ただしこの割り当て方をした場合、ドコモに割り当てられた2.5GHz FDD-LTE下り専用帯域はまさにキャリアアグリゲーション専用帯域となり、単独で使うことはできません。アンテナロケーションや電波伝播の差分などにより2.5G以外か2.5Gかのどちらかしか届かないようなスペースってのは必ず生まれますが、そんなところでは、2.5G帯の電波は完全に無駄になります。

と言うことで、正直、ドコモへの割り当ては、単にドコモの「スペックブースト」の役割しかなく、有効利用と言う観点ではあまり有用ではないかなぁ、と言うのが私個人的な感想です。

じゃぁどこがいいかと言うと、まぁ順当なところを言えばUQなんですけどねぇ。今UQが持っているところからガードバンド10MHzを空けての割当と言うことに当初はなるわけですが、UQが旧WiMAXを巻き取ってTD-LTE化すれば、その間の10MHzも使えるようになるんですよ。もちろん、WCPが使ったとしても、UQとフレーム構成と同期を合わせれば使えるようにはなるんですが、競合事業者間でそこまで細かい部分を合わせこむのは現実的じゃないです。単純に周波数の有効利用を考えるなら、将来像まで考えればUQ一択。

あとは、グループ間のバランスもありますね。ソフトバンクグループはウィルコム・イーアクのグループ化で保有周波数で事実上トップ、加入者当たり周波数だととびぬけて多い。そう考えると、ドコモかKDDIグループに割り当てるのが順当、ってことになります。で、あとは加入者当たりって話になるとするとドコモ割当かなぁ、と言う結論にもなります。ドコモの要求はスペックブーストを指向しているとはいえ、束ねる方式でも書いた通り、束ねれば統計効果で容量増もできる、と見れば、容量観点でまるで無駄と言うわけでもないですし。

まぁこの辺は総務省のお役人と各社の話し合いになるのでどうなるかはわかりませんね。700Mのときのように、せっかくの広い帯域を細切れにするような無駄をやるのが日本の電波行政ですから、どういう結論になっても驚きません。

そんなわけで、2.5G新割当についての駄文でした。

tweet TWEET

2012/11/21 10:00 · 事業考察, 技術動向 · (No comments)
2012/10/18 10:00 · 事業考察, 技術動向 · 3 comments

ドコモが100Mbps超のLTEを始めますよ、と言うアナウンスがあったことについて、「これっていったい何モノ?」と言うご質問をいただきました。もうわかってる人は死ぬほどわかってる話だとは思いますが、ふつーの生活をしているといきなり3倍ですと言われてもにわかに信じられないのも仕方がないわけで、今日はこれを平易に解説してみたいと思います。

ドコモが現在、大半のエリアでサービスしているのが、37.5Mbpsと表記される速度でのサービス。で、一部エリアで75Mbpsでますよーと言っていますが、まぁたいていの人はこのエリアに当たることはほとんどないと思います。おおざっぱに言って、37.5Mbpsがドコモのサービスのベースです。

さてここでXi=LTEの仕組み。LTEは、もちろん携帯と同じく電波を使ったサービスです。で、ざっくりと言うと、電波を使ったサービスでは、「電波を使う量」で、その最大通信速度がほぼ決まってきます。※良くわかっている人向け: それ以外のアンテナ数やチャネル構成が等しいとして。

で、電波を使う量の単位が、「Hz(ヘルツ)」。これをどのくらい使うかで通信速度が変わってきます。ちょっと余談になりますが、昔は、1Hz=1bpsくらいが相場でした。なので、100万Hz(1MHz)を使うと1Mbpsの通信速度と言うのが相場。だったのですが、最近はこれがものすごく改善して、1Hzで数bps出るような仕組みが作られています。LTEも大体この仲間。

で、ドコモでは、今、LTEで「5MHz」を使ったエリアを多くの場所で展開しています。この5MHzで出せる最大速度が、37.5Mbps。ここまで書けばほぼ答えですね。

LTEは、使う電波の量を柔軟に変えられるということも大きな特徴の一つ。最小で1.3MHzから、最大で20MHz (さらにもっと多くも将来は可能)を使って、しかもそれが同じキャリアで混在して使うことができます。なので、ドコモも、多くは5MHzを使っていますが、一部のエリアで、10MHzを使ったサービスをしていて、このエリアが75Mbpsエリアと言うわけです。となれば、15MHzを使えば、これが自然に112.5Mbpsになることは想像通り。

さて、こうなると、「じゃぁなんで全部のエリアで15MHzとか20MHzとかを最初から使わないのか」と言う質問が出てくると思います。これに関しては、電波についてもう一つ踏み込んで考えなければなりません。

電波は、国が許可してキャリアに割り当てます。ですので、無尽蔵に使えるわけではありません。新しい方式であるLTEですが、各キャリアは、古い方式でもらっていた電波を再利用してLTEを開始しています。

ところが、古い方式(3G)とLTEは、同じ場所で同じ電波を使ってはいけません(LTE同士でも基本的には同じ電波を使ってはいけません)。たとえば、ドコモは、バンド1と言う場所に、20MHzのカタマリを持っていて、これを5MHz毎に細切れにして使っています。3Gは、1エリアで5MHz単位で使う方式だからです。

仮に、20MHzの中の5MHzの小カタマリに、1、2、3、4と名前を付けます。3Gでは、小カタマリが一個あれば全国をカバーできます。なので、たとえば、全国で小カタマリ1を使うとします。ところが、小カタマリ一個でたくさんのユーザを捌こうとするとものすごく混雑してしまうことがあります(人口の多い場所などで)。このため、混雑したところから、小カタマリ2を使う様になります。で、さらに混雑すると小カタマリ3、それでもだめなら4まで使う、と言う様に。

さてドコモは、現在、このバンド1でLTEを開始しています。一方、このバンド1は、ドコモ3Gのメインバンドでもあるため、多くの場所で、小カタマリの1~3まで使っちゃってます。ってことは、LTEでエリアを作るために使えるのは、ほぼ小カタマリ4だけと言う状態です。

なので、ドコモはほとんどのエリアで小カタマリ一個分すなわち5MHzのサービスを行っているわけです。で、3Gで使っている小カタマリが2個で済んでいる地域(つまり人口が少ない場所など空いているエリア)では、LTEで小カタマリ2個を消費して10MHz=75Mbpsのサービスを行っています。

今回15MHz=112.5Mbpsのサービスを行うということは、LTEで小カタマリを3個使うということです。こうなると、ちょっとした人口の地域でも難しくなります。要するに、3Gで小カタマリ一個だけで通信を全部捌ける地域でしか、LTEに小カタマリ三つを使えないからです。

とはいえ、やっぱり競争上の理由で最大スペックは飾らないといけない、ってことで、とにかくできそうなところだけなんとかかんとか3Gの使用を1小カタマリに縮小統一して(LTEで3小カタマリ使うには、その周囲の電波が届きそうな結構広い範囲で3Gを1小カタマリにしておかないと電波がぶつかります)、LTEに3小カタマリを振り分けていったという感じですね。なので、112.5Mbpsサービスのエリアは本当にピンポイントになってしまっているわけです。

と言うのが、ドコモがいきなり3倍になった理由と、それでもなぜかほとんどのエリアで使えない理由。今後、3GのユーザがLTEにどんどん機種変していって3Gの「小カタマリ消費」が減っていけば、徐々に75Mbps、112.5Mbpsのエリアが広がっていくでしょうが、それにはもうちょっと時間がかかるでしょうね。でわ。

tweet TWEET
2012/10/18 10:00 · 事業考察, 技術動向 · 3 comments
2012/10/17 10:00 · 事業考察, 品質動向 · 4 comments

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

下記がその図です。

LTEエリア

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

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

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

tweet TWEET
2012/10/17 10:00 · 事業考察, 品質動向 · 4 comments
2012/8/27 10:00 · 事業考察 · 10 comments

[追記]最新図はこちら↓
各社LTEエリア展開状況(常時更新)

さて、前に書いた各社LTE展開プランに関して、まただいぶ状況が変わってきているので、改めてアップデートしておきたいと思います。

まずドコモ。相変わらず2GHzがメインで、なおかつ、ほとんどのエリアが5MHz幅(37.5Mbps)エリアとなっていて、状況は変わらず、エリアが徐々に広がっているだけのようです。ごく一部の地域で2GHzの15MHzを始めていたりするようで、今後は、これを徐々に増やしていくでしょうが、3Gのメインバンドともいえる2Gを都市部では削れないでしょうから、これ以上2GHzを使った拡大は難しいでしょう。一方、800MHzや1.5GHzの基地局も実験的に展開を始めているようですので、もう少ししたらこれらのエリアが急に広がり始めるかもしれません。

次にKDDI。こちらは着々と800MHzと1.5GHzを増やしていて、800MHzのロケーションの数だけでドコモに匹敵するほどになっているようです。まだサービスイン前なのに。もちろん、全くロケーション数が同じなら2GHzより800MHzの方がエリアは広く取れますから、サービスインと同時にドコモを大きく上回るエリアを実現する可能性が高く、さらに、ほぼすべての局が10MHz幅(75Mbps)となっているなど、速さ・広さともに他社を圧倒することが確定。加えて、難しいんじゃないかと思っていた2GHzも相当な勢いで建てているらしく、グローバル端末の受け入れに関しても万全です。なんだこの最強LTEキャリア。

ソフトバンクは、予想通りと言うか、自身によるFDDの展開も始めました。これはおそらくグローバル端末(と言うかLTE対応iPhone)の受け入れが主目的。ただし、ロケーション数では大きく後れを取っているうえ、10MHz幅率はドコモより下。要するに、エリアの広さでも速度の速さでも二社に大きく後れを取っている状況。これをカバーするのがWCPによるTD-LTEですが、こちらはPHSロケーションの再利用であるため、局数が多くともカバーできる範囲はかなり狭くなりがちです。あと、こちらに関しては全く同じ局に10MHz免許(FDDの5MHz幅相当)と20MHz免許(FDDの10MHz幅相当)の両方が付けられていたりして、実際にどっちの幅でサービスをしているのかわからない感じ。たぶんほとんどは20MHz幅だとは思うのですが、ちょっと不明瞭な感じですね、免許情報からは。

イーモバイルは、まぁ、うーん、頑張ってるけど、ちょっと、なぁ、って感じ。ロケーション数はソフトバンクをさらに大きく下回り、10MHz幅率もドコモ程ではないけどかなり低い。安さ以外でイーモバイルを選ぶ理由はなさそうです、残念ながら。

最後に、現時点で情報取得済み情報で図式化してみたものを。まだ完全ではないですが、おおよそ9割ほどは正確な情報のはずです。

まぁなんつーか、KDDI(au)の鬼っぷりがよくわかる図です。今後、この中の「赤い丸」がどのくらい大きくなっていくか、ってのが、各社LTEサービスの「本当のスペック」を知るうえで重要になると思うわけで、時々、この図、更新したいですね。案外作るのめんどい図なんですけど。

tweet TWEET
2012/8/27 10:00 · 事業考察 · 10 comments
2012/8/21 10:00 · 事業考察, 品質動向 · (No comments)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tweet TWEET
2012/8/21 10:00 · 事業考察, 品質動向 · (No comments)
2012/6/27 10:00 · 事業考察, 技術動向 · 1 comment

クラウドというのがいまいち気に入らないんですよ。まぁ全面的に否定するわけじゃないんですけど、個人的には気に入らない思想で作られたクラウドってのが結構あるような気がするんです。

クラウドって、何らかの情報資源をネットワークの向こうに置いておいて、適宜利用する、っていうコンセプトですよね。もちろん、必要なときに時々アクセスするだけです、っていうのなら、たいした問題じゃないんですよ。ローカルで使うツールの一部がクラウドによって強化される、っての、つまりハイブリッド型は悪くないんです。

困るのは、なんというか、ツールそのものがクラウドってタイプ。ピュアクラウド。たとえば、スマホのアプリを立ち上げると、いきなりネットワークにアクセスして必要な情報をゲットしたりするタイプ。もちろん、その時点でネットワーク接続に失敗すると「アプリの起動に失敗しました」ってなるやつ。単純にストリーミング動画サービスも、ネットワークにアクセスできないと何もできないですよね。これもある意味でピュアクラウド的サービスだと思います。

さらには、そもそもアプリの実体はローカルには無くて、ローカルにあるアプリっぽいものは、単なるブラウザエリアだったり画像表示器だったりするタイプもこれ。インターフェースそのものをクラウド側で生成していてローカルには一切インターフェースが無いようなの。シンクライアント的な感じ。

別にこういうサービスやアプリがあることを否定するつもりはないんですけど、ちょっと気に入らないのは、ケータイキャリアたちが、こういうタイプのサービスをこぞって始めていることです。ドコモなんてひどいもんで、「ネットワークの土管化を避けるために、ネットワーククラウドを本質的な付加価値にしていく」とか言い出している始末。

まずそもそも、どうしてクラウド的サービスが個人的に気に入らないのか、ってことなんですが、答えは簡単です。ネットワークがないと使えない。今、日本で一番広いエリアで使えるであろうネットワーク手段は、携帯・PHSによるインターネット接続です。ところが、これらでさえ、圏外という場所は多分に残っています。

そして、インフラオタク的に言わせていただければ、根本的にすべてのエリアを完全にカバーするインフラというのは作れない、と思っている部分もあるんです。たとえば、イリジウムみたいに全地球をカバーできるシステムもありますが、あれだって、地下では絶対に使えません。地下どころかビルの谷間でさえ使えないこともあるくらい。単に距離的・面積的な問題で置けないことよりも、そういった些細な理由での「カバー不可」というのが、通信インフラでは根本的に残らざるを得ない、というのが私の持論です。

というのは、結局は通信インフラってのは、維持コストと収益のバランス。維持コストが無限に使えるならありとあらゆる場所を完璧にカバーできるでしょうが、収益、採算性によるキャップがかかってしまうというのが、営利企業であることの限界。狭くて人口密度の高い島国ならあるいは、と思わないでもないですが、それにしても、シンガポールならまだしも山地の多いこの国での完全カバーは厳しいでしょう。

というか、最近特に気になっているのは、東京の地下。地下鉄。駅間カバーは徐々に進んでいるとはいえ、それでもまだ一部分にすぎないし、そもそも、最近は混雑でつながらない、実質圏外。実質圏外どころか、実際に圏外表示出ますからね、ドコモの場合。ホームで電車待ち中にブラウザでリンクたどってると突然圏外表示になって、15分ほど帰ってこない。ホームで圏外表示になったらいつも電源入れ直ししてます。なんですかあれ。何が起こってるのかは大体想像はつくけど、なんですか、あれ。改善する気ゼロですか。

という様に、東京の地下には広大な「圏外エリア」が広がっています。これは一例で、土管=インフラというのは、完璧無欠ということはありえない、と私は考えるわけです。だから、少なくとも端末単位で動くようなサービスは、ネットワークが無くても動くような工夫をすべきということなんですよ。キャリア諸氏が傲慢にも「我々の土管は完璧だ」と、土管ありきのサービスをやることはとりあえず気に入らないし、それ以外のサービスプロバイダに関しては、土管なんぞあって当然、圏外の奴は死ねみたいな考え方が気に入らん。

いや本当、クラウド的に、全部の処理をサーバ側でやっちゃう、っていう概念は確かにいろんな便利な面があることは重々承知してるんですけど、個人が端末単位で使うサービスだったら、ローカルでもある程度動く仕組みを備えてほしいんです。もちろんそういう努力をしたアプリケーションも結構ありますけど、最近は本当に多いんですよ。地下鉄でアプリ立ち上げたら「ネットワークが見つかりません。アプリを終了します」。アプリの価値が赤の他人が作っているネットワークインフラに完全に依存してしまうことを、ちょっとくらい恥ずかしいとか思わないのか、と。いっそ、アプリがネットワークを利用する分の通信料をアプリ提供者に課金するっていう仕組みがあればいいのに。あれっ、これいいアイデアだ。マルウェアとかも激減するよね。よし特(以下5kB程中略)

ってことで、クラウドサービスっていうのが、ネットワークとは切っても切れないサービスで一方ネットワークというのは完璧ってことはありえないものっていう前提でサービスを設計するなら、せめてスマホ向けサービスとかはクラウドとローカルのハイブリッドで考えてほしいよなぁ、と思うお話でした。誰とは言わないけどネットワーククラウドが主力!とか言ってるキャリア殿にはしっかり考えていただきたいところです。でわ。

tweet TWEET
2012/6/27 10:00 · 事業考察, 技術動向 · 1 comment
2012/5/31 10:00 · 事業考察, 技術動向 · 4 comments

だいぶ前に、地下鉄駅構内でドコモの携帯電話がほとんど使い物にならない、という話を書きましたが、最近は、auの方も結構ダメダメになってきました。スマホなのでパケットにつながってるのかつながってないのか辺りが少し不明瞭なのですが、通信状態を表す矢印を見ていると、上り方向は点滅するけど下り方向が全く点灯しない、という感じ。これはあくまで上位プロトコルから見た状態なので、おそらく、無線がちゃんとつながってなくて、上位から見ればデータを送ったつもりなんだけど、たぶん下位プロトコルのところで完全に滞留している(無線がつながってないので)、という感じだと思われます。

さて、この話を以前にも書いた時、ほかの地上のターミナル駅でも結構ひどいよ、というお話もいただいたり、あるいは、「地下だからしょうがないじゃん」的なコメントもいただいたりしたのですが、よく御存じの方から見れば「地下だからしょうがない」というのは至極当然かと思われますが、今日はそのあたりの話を少し。

私が特に地下鉄駅を取り上げたことには、やっぱり意図があるというか、だからこそ地下鉄駅を、というのがあります。それは、地下という閉鎖性が問題です。

今現在、地下で携帯電話が使えるのは結構当たり前になっていますが、特に地下鉄駅などの公共の地下で携帯電話が使えるようになるのにはいろんな紆余曲折があったりなかったりするわけです。とにかく何を置いても問題になるのが、「基地局をどこに置くのか」です。

確かに普段、地下鉄の駅構内で天井を眺めたりしても、そこかしこに入り口があってあちこちに無駄なスペースもあって、携帯電話の基地局なんてどこに置いたっていいじゃん、と思うこともわからないでもないのですが、一方、地下鉄事業者にも地下鉄事業者なりの言い分があります。すなわち「あれは無駄なスペースなんかじゃない」と。

地下掘るのだってタダじゃないし、出来るだけ効率よく必要な装置・機材を収容できるように作るのは当然の話で、そういう前提であるにも関わらず何か無駄っぽいスペースがあるってことは、それは、たとえば保守・作業用のマージンとして必要欠くべからざるものであったり、あるいは、地下鉄事業者自身が将来的に装置設置のために確保してあるものだったりするわけです。それを赤の他人にホイホイと貸すかというと、それも無理のある話でしょう。

もちろん、スペースに十分な空きがあったとしても赤の他人の装置を置くこと、置くために工事をすること自体、地下鉄事業者にとってはリスクでしかありません。スペースの消費はもとより、そこに重さもわからない装置を置くようなリスクも取れないし、そのための電源や回線を引き回すためにダクトなりなんなりの経路を使わせることは、自社サービスのための配線に対するリスクでもあります。さらには携帯電話基地局は事業法電波法に守られた装置、法的に触ってはいけないケーブルがそこにあることで、自社用のケーブルの工事に制限ができてしまう可能性もあるわけです。そもそも鉄道用の保守スペースとかに他の知らない作業者を立ち入らせる、って時点でかなりハードルが高いわけで、まず第一声は「ヤダ」でしょう。私ならそう言います(笑)。

そんなわけで、携帯電話事業者と地下鉄事業者は話し合いに話し合いを重ね、こうやってスペースを節約してこうやって必要スペースを確保するし、こういう仕組みにすることで作業員の出入りや回線の取り回し作業を最小化するので何とか置かせてください、という様にして、基地局設置を実現しているわけですね。

で、地下鉄事業者などとの交渉の内容はまぁ想像するしかないのですが、一番よく知られているところで言うと、「各社のアンテナを出来るだけ共用化してスペースを節約すること」なんてのがあったりします。基地局本体もかさばりますが、アンテナもかさばる物。それを各社が好き好きにつけたんじゃぁたまらないから、多バンド対応のアンテナを共用で使う様にしなさい、なんていう形になっていることが多いようです。

一番技術的に厳しいアンテナ共用さえさせるほどですから、それ以外にもおそらく細かい点でいろんな縛りがあることは想像に難くありません。回線数を増やすために基地局を増設するとか、無線キャリア数を増やすとか、そういったことに対してはかなり厳しく制限が入っているはずですし、もちろん、バックホールの物理線をいろいろいじくることも難しいはず。となると、たとえば、アクセスが増えて大変になってきたのでバックホールを太くしよう、なんてことは簡単にはできないわけです。

おそらく、全くやっちゃダメ、という程の制限ではないでしょうが、たとえば、配線してある天井裏に潜るには○ヶ月以上前に申請して審査を受けなきゃならないとか、鉄道事業者の工事や調整が優先なのでそういった作業が一切ない時期まで待たなきゃならないとか、新しい機器や線などはどんなものが入るのかの仕様を開示して審査を受けなきゃならないとか、二社以上の事業者の工事が一度にできるよう事業者同士で話をつけてこい(単独工事は不可)とか、たぶんそんな感じではないかと思います。私が鉄道屋さんなら、たぶんこの程度のことは吹っかけると思います。だって触られたくないもん(笑)。

ということで、地下鉄駅構内などでは、装置を追加しにくい、回線を増設しにくい、という事情があり、トラフィックの急増にはどうしても追いつかないということになります。地上の駅よりも地下鉄の駅が、より混雑の影響を受けやすいのは、これが一番強く効いていると考えられます。要するに、一昔前の前提のネットワークがいつまでも残ってしまう、ということ。

そしてもう一つ、これを加速させる地下の事情は、「逃げ道がないこと」です。地上だと、たとえば3Gではトラフィックが増えてくるとそれはノイズの増大として観測され、そうなるともっとノイズの少ないところへ行けないものか、という仕組みが働きます。いわゆるハンドオーバです。特に移動しなくても、トラフィックが集中して品質の落ちたセルからは端末ができるだけ逃げ出そうとするわけです。たとえ届く電波が弱くても、そのノイズが十分に低ければ利用できるわけで、本来その場所をカバーする目的ではなかった隣のセルなどにハンドオーバして品質を保とうとするんです。WCDMAではもともと品質ベースでハンドオーバをかける契機があるのでこれが有効に働いていますし、CDMA2000(EVDO)はスロット分割なのでこの仕組みが働きにくいのですが、先日のEVDO Advanced導入で能動的にこの契機をかける仕組みが入ったようで、いずれも、「やばくなったら隣のセルに逃げる」ということができるようになっています。

ところが、地下になると、その頼みの「隣のセル」が見えないんですね。基本的に最小限のアンテナしか設置しないということと、構造が複雑でしかも遮蔽力が強力なコンクリ+地盤に阻まれているため、ごく一部のエリアをのぞいて複数のセルがオーバーラップしていることはないと考えられます。であるため、ある一定のエリアはほとんど一つのセルが単独でさばいているようなもの。特に駅のホームとかとなると、設置位置も限られているためセル一つかせいぜい二つ、これで、乗車+列車待ちの千人単位の携帯電話利用者が殺到すれば、あっという間にパンクです。

で、これに加えて地下鉄特有の問題として位置登録輻輳も電車の入線のたびに起こります。地上駅であれば、駅の間のページングエリア境界でみんな一斉に位置登録を行うということは起こるわけですが、と言ってもアナログ現象である電波ですから、エリアが連続的であればある程度アナログ的にばらつきますが、地下は「一度完全圏外になる」「次に突然復帰する」というデジタル的なギャップがあるため、位置登録集中の効果は地上より非常に大きくなります。で、この位置登録輻輳のために一般のデータ接続への割り当てが先送りになったりして(一般的には位置登録などシステム上必須の接続はデータ接続などより優先処理されます)、溜まったデータがそのあとの時間帯にシフトしてトラフィックを底上げするわけで、トラフィックの増大による逼迫がより出やすくなっている、ということになります。

ということで、混雑が激しくなればまず地下鉄に来るはず、ってことで、地下鉄での品質には特に注目していたわけです。で、予想を超えて、地下鉄駅だと、ターミナルどころか乗り換え駅でもない近郊のヘボい駅でさえ症状が出るほどに混雑してきたことにびっくり、という感じなんですよね。

今、各社共同で地下鉄の駅間トンネルのカバーを進めていますが、これは上述の問題のうち、位置登録輻輳による逼迫を多少緩和してくれるのではないかと期待されます。というか、すでに都心で始まっている駅間カバー路線で、以前はかなりひどかった状態が同じ曜日・時間でもかなり緩和されているのを体感しています。位置登録や接続再開のアクセスが駅間でばらついてくれるだけでこれだけよくなるんだー、ってくらいです。

ってことで、地下ってのは何かと特殊な事情が絡みやすいので、トラフィック対策は大変なんですよ、というお話でした。ちょっと違うか。

tweet TWEET
2012/5/31 10:00 · 事業考察, 技術動向 · 4 comments