モデムキター！！

どうやら期日どおりに工事はしてくれそうな雰囲気。

だけど、事前に携帯電話の方に打ち合わせの電話をもらえるはずなのに全く来ません。困ったなぁ。そろそろこっちからかけてみる必要があるかも。

いや、今から光を引くような人って、ネット環境があまり整っていないっていう前提もあるのかもしれないけど、電話ベースだけでなく、メールベースでの打ち合わせも活用してほしいですね、IT企業様には。

案外、そういうIT企業様のコールセンターとか開通センターの担当者レベルってITリテラシはすごく低かったりするんですけど（苦笑）。ちょっと専門用語を使うだけで話が通じなくなることが多くて、こっちが会話に気を使います。相手は天下のKDDI様だからこのくらいの用語は通じるだろうと思うと全然ダメ。基本、コールセンターの人って、知識はほぼないと思ったほうがよさそうと気がつきました。顧客にダイレクトに接するコールセンターにこそ、何にでも対応できるエースを置いておくべきだと思うんですけど、サービス事業者の常識ではそんなことはありえないんでしょうかね。一番お金をかけるべきところだと思うんだけど。

と言うことで、開通までもう少し。

TWEET

大変申し訳ありません、ケータイニュース.netが昨日夕方から深夜にかけて停止していました。

理由は転送量超過。

ついに速度計測でやっちゃったか、とあわてて調べてみたら。

ぜんっっっっぜん関係ないスクリプトのバグでした。

なんかいろいろ条件が重なるとでるっぽくて、2011年11月7日にピンポイントででる感じになってました。まだこういうバグありそう。

いろんなスクリプトを徐々に隔離して何かあってもスクリプトのディレクトリだけ停止されるようにしたいと思います。

ご迷惑をおかけしました。

TWEET

LTEの周波数利用効率が高いということが当たり前のように言われるのですが、なぜ高いのか、高いと言いきれるのか、と言う点がよくわからん、と言うご質問をいただきました。

早速ですが、まずは周波数利用効率について。周波数と言うのが有限の資源です、と言うのは改めて説明するまでもないのですが、有限であれば当然より効率よく使わなきゃ、と言うことになるわけで、そうした中で「周波数利用効率」と言う考え方が出てきています。

最も端的でシンプルな周波数利用効率は、単位を「bps/Hz」とする利用効率。基本的にはこれを前提に、最後にちょっとだけ他の拡張した指標も考えます。

bpsは言わずと知れた、通信速度の単位。Hzは周波数の単位ですが、この利用効率の話をする場合には、「搬送波の占有帯域幅」を指します。つまり、中心周波数が2GHzであっても60GHzでも、占有帯域幅が10MHzであればそれは全く同じ10MHzと扱います。

占有帯域幅と言うことについても定義が必要になりそうですが、これもいろいろと面倒な定義がいろんな場面で使われるので、単純化してしまうと、同じシステムを同じ場所に置くときにお互いに干渉しない中心周波数の離隔（間隔）と考えると分かり易くなります。ある中心周波数であるシステムの電波を発射しているところに、同じシステムの電波を追加で発射してシステムの容量を増やしたい、と思ったとき、では最初に発射している電波とどのくらい離さなければならないか、と言うのが、物理的な理屈と技術的な制約から最終的には技術標準と電波法規で定められることになるわけで、この最終的に決められた「離さなきゃならない幅」が実際には「占有帯域幅」（そのシステムがそこにあることで他の人が入れなくなる周波数の幅と言う意味で）と言ってもよかろう、と思います。

この考え方で行けば、WCDMAはきっちり5MHz、CDMA2000はきっちり1.25MHz、などなどとなるわけです。つまり、最終的にはそれぞれのシステムの電波1波で出せる最大速度を、この占有帯域幅で割り算すればよろしい。

WCDMAでは、HSDPAがどうとかDC-HSPAがどうとかありますが、今のところ、1波で出せる速度は21Mbpsくらいが限界のようです（今後MIMOで机上では倍速になる見込みがありますが、実際は動かない）。DC-HSPAだと42Mbpsでは、と思われるかもしれませんが、DC-HSPAは隣の基地局の電波も使う、つまり、2波使ってその速度。なので、1波と限定すれば21Mbpsが限界速度。

21Mbps / 5MHz、つまり、4.2 bps/Hzが、WCDMAの周波数利用効率と言うことになります。

では、LTEは、と言うと、最も広い帯域を占有する版で、150Mbps / 20MHzと言うのが今のところの最高速度（こっちもまだMIMO拡張で大幅にアップする予定ですが）。単純に割り算すると、7.5 bps/Hz。ざっくりと1.8倍も利用効率が良い、と言うことになります。

さてこれだけ利用効率が大幅にアップしているのはなぜか、と言うことなんですが、ぶっちゃけると、MIMOのおかげです。MIMOが無いとLTEでもたいした利用効率にはなりません。

じゃぁWCDMAでもMIMOを使えばいいじゃん、ってことになると、以前に書いたMIMOが効く仕組みの話になります。つまり根本的に、OFDMAはMIMOが効き易い変調方式なんですね。逆に、新世代方式ではMIMOを大幅に拡張するためにOFDMAを採用したと言っても過言ではありません。これに比べればボケボケのWCDMAなんてMIMOはまず全く効かないはずです（たとえ標準化されても）。

そしてもう一つ、OFDMAの特徴の一つは、「占有帯域幅を容易に拡大できる」と言う点があります。と言うと、鋭い方はすぐに突っ込みを入れるはずです。「結局は占有帯域幅で割り算するんだから拡大して最大速度を上げても意味が無い」と。

ここで注意しなければならないのは、上記の、21Mbpsとか150Mbpsとか書いた速度ってのが、純粋な物理レベルのビット速度だということ。実際のシステムでは、データに対して制御信号やヘッダがくっつき、そのくっついた結果の総ビットがビット速度を消費します。また、純粋なシステム制御信号だけがリソースの一部を占有しなければなりません。つまり、実際のユーザデータが流れる速度は、この机上の速度よりずっと遅くなるんです。

ところが、こういった制御信号などは、占有帯域幅が広がっても増えることはほとんどありません。たとえば、20MHzの周波数が用意されているところに、5MHzのWCDMAを4つ置くと、制御信号は4システム分のリソースを食いますが、20MHzのLTEを1つ置くのなら1システム分の制御信号リソースですみます。浮いた分は当然、ユーザに割り当てられる領域です。

つまり、単にビット速度に現れる以外でも、広帯域のシステムにすることで制御信号の比率を下げ、結果としてユーザの使えるデータのための利用効率を向上できるというわけです。

ということで、まぁぶっちゃけちゃえばMIMOさえ入れれば大幅に利用効率は上がるし、帯域を広げれば実効効率もあがるよ、ってことなんですね。

で、最後にもうひとつ。これをちょっとだけ拡張した考え方に、「bps/Hz/Cell」なんてのがあったりします。Cellってのは、発射した電波が届く範囲を一つの単位としたもの、単純化して言えば、一つの基地局当たりの、と言う意味です。もちろん、基地局を一個だけ置いて端末も最も電波良好な場所に一台だけ置いて考えたときは、この単位は上述のbps/Hzと完全に一致します。

一方、基地局からの電波は現実では距離により減衰するわけですが、その届く範囲に端末がランダムに散らばっている、と言う場合。そうすると、遠くの端末は電波品質がよくないため同じリソースを使っても速度が上がりにくくなります。これを全端末分足し合わせて、占有帯域幅で割る。すると、上述のbps/Hzよりもずっと小さな値になってしまいます。遠くの端末にちょっとだけ割り当てて、近くの端末には豪勢に奢る、と言うアルゴリズムが主流なのは、このタイプの利用効率を上げるためにあります。すぐ近くで電波の良好な端末にたっぷりリソースを割り振れば、それだけで理論上の利用効率にかなり近くなるからです。

さらには、もっとたくさんの基地局があり、それぞれにたくさんの端末がランダムに散らばっている場合。これも同じように電波状況が悪い端末の分を加算すると理論上の利用効率より低下します。しかし、基地局からの電波が十分に良好なうちにしっかりと止まるようにアンテナを建て（たとえばすごく高い鉄塔から絞ったビームでしっかりと吹き降ろす）、届かないところは隣の基地局からやはり同じようにしっかりと止まる電波でカバーする、と言うことを繰り返していくと、「電波の悪いところにいる端末」がほとんどいなくなり、格段に利用効率を上げることができます。常々「電波は飛ばす技術より飛ばさない技術が重要」と言っているのはまさにこの点です。高トラフィック時代では、いかに電波を劣化させずにしっかりと止めるか、と言う技術が非常に重要なのです。

で、実はLTEは、こういった「飛ばさない」と言う点でもCDMAには出来ない工夫を入れ込む余地があり、この意味での周波数利用効率（bps/Hz/Cell）を上げやすい方式でもあったりします。

ということで、LTEなど新世代の通信方式がなぜ周波数利用効率が高いといわれるのか、についてでした。

TWEET

WiFiオフロードはもはや各社喫緊の課題であり、もちろんWiFiスポットそのものの干渉をどうするかと言う問題はあるものの、それとは別に、どうWiFiを使われ易くするか、と言う問題が大きく立ちはだかっているように聞きます。

前にも似たようなテーマで書いたかもしれませんが、これはもう、どうしてもオフロードしたいという動機のある事業者側がいろんな仕掛けを作りこんでいかなければなりません。そんな中で、技術的に出来るかもしれないネタを漫然とぶちまけて今日の話はおしまいにします（無責任）。

WiFiオフロードをすることに対しての最大の難関は、「ユーザ」です。何しろ、ユーザがWiFiをOFFにしちゃう。これが最大の敵であるわけで、言ってみれば、ユーザを洗脳してコントロールしてしまえば全て解決します。しかし、ここではそういった野暮ったい解決策を封印した上で、何か出来ないかを考えて見ます。

まず、ユーザがWiFiをOFFにする最大の理由は、バッテリ消費です。WiFiは、リンク状態では基本的にかなりの頻度で無線回路を開いて非同期で飛んでくる無線パケットを監視しなければなりません。また、リンクしていない状態でも、APを見つけたらなるべく早く接続するために、やはり結構な頻度で無線回線を開いて監視をしています。

前にも書きましたが、無線回路は、受信のためだけに電源を入れるだけでもかなりの電力を消費します。WiFiをONにするとバッテリの減りが極端に早くなるのは、もはやどうしようもないことです。

これをどうにかする方法。まず、無線LANに繋がっていない場所でONにしたままでも消費電力が大きくならない方法、これについては、サーチ頻度を下げる、くらいしか解決策はありません。むしろ、無線LANが見えない場所でならサーチ頻度さえ下げればそこそこ効果のある省電力が可能です。

しかしもう一歩踏み込みます。いくらそのような策を講じても、ユーザが「WiFiがONだと電力食うよね」と感じていることは覆せず、ONにしてもらえないわけです。であれば、「WiFi APがありそうな場所では勝手にONになる」「なさそうな場所では勝手にOFFになる」みたいなことが出来れば、ユーザがONだOFFだを意識しなくてもよくなります。むしろこれが出来れば「ユーザによる強制WiFi OFFをソフト的に封じる」くらいのことさえ考えられるわけです。

そういうことはどうすれば出来るでしょうか。ある場所にWiFiがあるかどうかを知る、これには、たとえばGPSで位置を確認し、その位置と、端末がローカルに持っている「WiFiスポットデータベース」とを照合し、近づいていたら勝手にWiFiをONにする、なんていうソリューションが考えられます。これは実に簡単。

ただしこの方法でも、結局は「GPSで確認」と言う電力消費があります。GPSも、WiFiに劣らず電力を食います。それはもちろん「受信のために無線機をONにするから」です。このGPS方式は一つの解決策ではありますが、ではさらにそのGPSさえ封印してみましょう。

他に端末に残っているのは、と言うと、そう、3Gなどの携帯電話回線ですね。そして都合の言いことに、携帯電話回線の方は、待ち受けのためにどっちにしろ数秒に一回のペースで無線機をONにして呼び出し情報を確認するということを必ず行っています。さらには、基地局のカバーエリアをまたいで移動した場合はさらにたくさんの情報受信を自動で行います。

つまり、「移動したら自動で確認する」が、携帯電話システムに自ずから備わっているわけです。これを使わない手はありません。

要するにこうです。WiFiスポットのある付近の基地局から送信している、端末への常時通知情報（報知情報）に、何らかの形で「近くに対応したWiFiスポットがあるぞ」と言う情報を乗せておきます。端末は通常時はWiFiはOFFです。端末が移動して捕捉している基地局が変わった場合、端末は自動でその基地局が送信している報知情報をチェックします。そこにもし「WiFiあり」と言う情報があれば、即座にWiFiをONにするわけです。

もちろん携帯電話の基地局のカバーエリアのほうがWiFiよりもはるかに広いので、実際には見えない位置からWiFiがONになってしまうきらいはあります。しかし、少なくとも「こういう仕組みです」と説明して、ユーザに自動WiFiを受け入れてもらえる可能性は高いでしょう。あるいは、基地局から「あるぞ」信号を受けたらその段階でさらにGPS測位を行って確度を上げる、と言う二段階アプローチもあるでしょう。

さて、相当な無茶を書いていることは自覚しているんですが、しかし、実は、WCDMAにも、CDMA2000にも、実は既に標準の中に「他の無線システムが近くにあるよ」と通知する方式が定義されています。実際、デュアルシステム対応端末などが、WCDMAとLTEの間、CDMA2000とLTEの間、などなどを行き来するためにこの情報が使われています。この仕組み、それぞれシステムごとに対応状況は違うのですが、大雑把に「WCDMA、CDMA2000、GPRS、GSM、LTE、WiMAX」あたりが対応されています。

はい、その通り。WiFi、入ってないんです。当然、WiFiのための情報コンテナを改めて標準で定義しなければなりません。しかし、既に自分とは全く関係ない他のシステムが近くにあるよ、と教える仕組みが備えられているわけですから、これを単にWiFiに拡張すればいいんです。あるいは、既存のコンテナで絶対に使わないであろうものを無理やりWiFiに読み替える、なんていうことも不可能ではないでしょう（端末は特注になりますが）。

と言うことで、こういう解決策もあるよ、と言いつつ、案外端末自前測位＋自前データベースによるON/OFFが一番手っ取り早かったりするかも、なんて思ってたりするわけですが、今日は（技術的に）どうやったらWiFiが使われ易くなるかを考えてみました。でわ。

TWEET

またちょっと更新しました。

http://speed.ktainews.net/

といっても計測ロジック自体は変わっていません。

計測結果の表示に変更が入っています。

まず、ソフトバンクAndroid、メールで情報いただきました。openmobileだけじゃないんですね。pcsitebrowserもスマホが使っているとのことで、調べてみたら確かにありました。しかもたくさん（笑）。ってことで追加しました。サンプル増えました。めでたし。

あと、統計結果、最頻値っぽい値を出していますが、サンプル数による信頼区間の補正を入れました。簡単に言うと、サンプルが少ないと結果がブレ易くなる効果を最頻値に対して補正しています。

ただし。

基本的に、表示に対して「品質低下方向」に補正しています。本当は、結果が上下どちらにブレているのかは分からないはずなので、素直に中央値を表示して誤差（標準偏差）表記を広げるべきなんですが、実際は標準偏差がでかすぎて既に役立たずレベルなので、「最悪でもこれ以上は平均的に望めますよ」と言う指標を目指してそういう意味での安全側に倒すことにしました。具体的には、速度は上方向にブレていると仮定して下方向に、応答速度は下方向にブレていると仮定して上方向に補正。こういう前提での数字ですよ、とあらかじめここで断っておきますのでよろぴこ。

TWEET