先日のLTEの各社プランまとめを書いたところ、LTEがらみのご質問をいただいています。あまりボリュームがなさそうなのでまとめて。

Q.

LTEはやたらと消費電力が多い（バッテリ持ちが悪い）みたいですが、なぜでしょうか。

A.
しょっぱなからLTEマイグレーションとは関係ないですが、端末がみんなLTE化してしまうと気になってくるのがやっぱりバッテリー。どうも、ドコモのLTEスマホはバッテリ持ちが悪いと評判（？）のようです。

これにはいくつか理由があると思います。まず一番単純な理由は、新しい技術だから。WCDMAが出始めた時も、連続待ち受け50時間なんていうスペックの端末があったくらいで、とにかく新しい技術はこなれていないがためにデバイスの消費電力が高めになってしまうことが多いですね。これは、ベースバンドチップの作りがちょっとずつ改善していって徐々に落ち着いていくことになると思います。

もう一つは、ネットワークパラメータがまだこなれていないこと。OFDMAのセルラーという全く新しい仕組みなので、どんなリソース配置にし、どんな間欠受信間隔にすればバッテリ消費を抑えられるのか、という点のノウハウがまだまだ足りないと思われます。たとえばリソースのスケジューリングだけをとっても、バルクで同じスループットを出すにしても、狭いリソースを連続割り当てした方が良いのか、大きなリソースを断続割り当てした方が良いのか、どっちの方が端末のベースバンドやRFの負担が少ないのか、というのはこれから探っていくことになるでしょう。まだまだしばらくはこういう状態が続くはずです。

まだ今のところはドコモ的にはパフォーマンス優先の設定にしてあるっぽいので、もう少しLTE加入者が増えて、パフォーマンスを突き詰めてもしょうがない、くらいに落ち着いたら、もうちょっと消費電力の少ないパラメータやアルゴリズムに変わってくるのではないでしょうか。スマホのように時々起きてちょこっと通信、みたいなやつがいることも考えて、条件によりスリープタイムアウトを超短くする、みたいなカスタマイズもできるようになるでしょうし。バッテリ持ちが悪いのは、発展途上だから、ってことで、一つ。

Q.

KDDIのLTEはグローバルが期待できないと書いてありましたが、KDDIからLTE iPhoneが出ることは期待できないのでしょうか。

A.
現状では難しいと思います。もちろん、iPhone自体はマルチテクノロジ対応となっていくので、これまでと同じくKDDIからはCDMA2000ベースでリリースされることは間違いないとは思いますが、LTEとなると、KDDIの持つ田舎バンドに対応する可能性は低いと思います。

一つ、参考になる情報があって、それは、先日出たLTE iPad。LTEに関しては、対応するバンドを大きく絞り込んでいます。それは、LTEの周辺不要発射があまりに大きいため、安く済ませるには特性の鋭いフィルタをかけざるを得なかったからと思われるのですが、AT&T向けが700帯+2100帯、Verizon向けが700帯のみ、という形。しかも700帯はAT&TバンドとVerizonバンドはほぼ隣り合っているのですが、明確に対応バンドを分けています（AT&T向けはVerizonバンドでは動かない）。これは、両バンドを同時にカバーできる高性能フィルタがコスト的に採用できず、特性の鋭いフィルタをシフトして使っていることを示唆しています。

それぞれが1億加入を持つ米国がこうですから、日本ローカルのKDDIバンドとなると、対応さえしないでしょう。ドコモと隣り合っていますが、上と同じ理由でドコモとKDDIの両対応は難しく、850対応フィルタをドコモ用シフト、KDDI用シフト、と使い分けた専用ハードウェア、ということになってしまいます。さすがにせいぜい3000万加入のキャリア向けに専用ハードを用意する、ということはありえなさそうな気がします。さらに言うと、日本の850帯は世界で最も性能規定が厳しいため、世界中の端末屋さんから嫌がられています。同一ハードのグローバル展開で低コスト、という戦略のAppleが、この超コスト高バンドに対応する可能性はかなり低いはずです。

ってことで、国内でLTE iPhoneをゲットするなら、今のところグローバルバンドをLTEに使っているドコモが第一候補、という感じになりそうな気がします。

ところで、この話をするとちょっと詳しい人は「Band26～」と思われるかもしれませんが、私の知る限り、あの新バンドに関しては、「あー、あの使い物にならないゴミバンドね」という反応しか聞いたことがありません（笑）。低周波数帯で幅35MHzで上下ギャップが10MHzしかないとか、何の冗談かと（笑）。

Q.

国際の2.5/2.6Gのうち日本では2.5Gを使っているみたいですが、2.6GHz帯の残りとかって日本では割り当てどうなるんでしょう。

A.
今のところ衛星通信に使っているようなのですが、2630～2655を使っているモバHOがサービスを終了したので、そのうち空くかもしれません。と言っても、同じ帯域・同じ衛星で韓国事業者がまだ使っているということもあって、まずは韓国での使用が終わらない限りは全く身動きができません。またそれが終わって空いたとしても、15MHzという半端な帯域なので、そのすぐ上の別の衛星通信帯域が空くまでは使いにくいかもしれませんが。

ここに関しては、WiMAXで使っている2595～2625に対して5MHzのガードバンドを挟んで隣接しているわけですから、ここを活用するとするなら、そこを全部きれいに均して、2595～2645までの50MHzの大きなバンドにして再活用する、という感じでしょうか。TDDの隣接を違う事業者同士でやるのはあまり現実的ではないので、UQにこの50MHzを全部任せるのが一番効率がよさそうです。たとえば、追加の20MHz分はTD-LTEじゃなきゃダメ、ってことにして、WiMAXの上下プロファイルとうまく合致するTD-LTEプロファイルで同期運用させ、ゆくゆくは全帯域をTD-LTE化させることを条件に、みたいな形が再利用の道筋としてはよさそうな気がします。

って感じで、また質問があったらこんな感じでやりますのでよろしく。

TWEET

いやぁ、夜中の緊急地震速報、驚きました。だいぶ時間もたってきて、ちょっとは落ち着いて警報音を聞けるようになってるんじゃないかと思ってたけど、やっぱり無理ですね。心臓が危なかった（苦笑）。

さて、解約したはずのEVOで緊急地震速報がという話を以前に書きましたが、えーと、鳴りましたね、解約、というか、機種変更して放り出してあった、EVO。単純な速報端末として使えますね。まぁそれ以外に鳴るやつらがいるので使い道はないんですけど。しかしまぁ、随分な実装です（笑）。

単純な速報端末と言えば、放送や有線接続を使うタイプはどうなのか、というと、まず放送に関しては、少なくとも携帯電話の緊急地震速報と同じく片方向なので、輻輳の心配もないし速報性も高い。あと有線に関しても、もちろん、上位のスイッチでの輻輳の可能性はありますが、最終的には一本の線の中を各ユーザ向け信号が流れることになるので輻輳もないし、常時接続なのでコネクション立ち上げのタイムラグもなし。ってことなので、使わなくなった携帯電話を速報端末とするよりは、やっぱり放送か有線の専用端末を置いてある方が品質は良いはずです。少なくとも、携帯電話は、報知情報の送信インターバルという問題と端末の間欠受信のインターバルという二つのタイムラグ要因があるわけで、常に受信機/回線を開きっぱなしの放送や有線には速報性ではかないません。と言ってもその二つにない「持ち歩ける」=「外出先でも」という特徴こそが携帯電話に求められているわけですけど。

ってことで、EVOは鳴りました、ってことで。同じauでもSIM機のSIM抜けとか、ドコモやソフトバンクのSIM抜け端末はどうだったんでしょう。純粋な無線上の仕組み的には鳴らすことはできるけど、あとはSIMなし状態の動作の実装次第。もし身近でそういう端末がなってたりしたらぜひご報告を。

TWEET

PHS制御周波数移行に関する質問をいくつかいただいたので、まとめて。

まず、「周波数移行できる端末とできない端末があるのはなぜ？」というご質問から。

その前に、PHSの制御周波数移行とはなんぞや、ということを簡単に。PHSでは、事業者ごとに「制御用周波数」というのが割り当てられています。すべての端末はこの周波数を見てネットワークの有無や着信の有無を知り、発信時はこの周波数にある制御チャネルで自分用の通話チャネルをもらう、というような役割を持っています。つまりPHSシステムのすべてのスタート地点。これがないとPHSはシステムとして成立しません。

これが「移行」、つまり、どこか別の場所に行ってしまう、ということはどういうことか。詳しいいきさつは省きますが、PHS周波数は3Gの周波数とあまりに近いため、お互いが干渉波になるという困った関係があります。日本の電波行政の原則は「先行者保護」なんですが、そうはいっても、PHSの周波数のほんの一部のために3G用の周波数が5MHzも無駄になってしまうことはあまりにもったいない、ということで、PHS周波数の縮退が提案されました。そもそもPHSというのは、端末が制御チャネル上で割り当てられた周波数にアホみたいに合わせるだけのシステムなので、3Gに近い方を割り当てることを基地局側がやめてしまえば、事実上その周波数帯は縮退したものとみなせる便利なシステムなんです。

ところが、その「縮退させたい周波数域」の中に、制御周波数があったんですね。非常に面倒なことに。なので、長い時限措置を経て、その制御周波数を別のところに動かしてしまおう、と。その間に端末もおおむね一巡してしまうだろう、と。そういうわけで、2012年5月24日の制御周波数移行が決定されました。

その後出てきた端末は、新しい制御周波数に何らかの形で対応できるように作られているため、こういった端末は何らかの措置を施せば、インフラ側の移行の意思に従って何の問題もなく周波数移行を終えることができます。

で、これで一つ目の疑問が片付きました。つまり、「できない端末」というのは、その「周波数移行の決定が行われる前に開発されていた端末」です。もちろん、仕様検討段階から含めれば開発期間は結構長いですから、同じ時期に出たものでも対応できない端末が入り混じったりするみたいですね。ただ、基本的には2001年ごろ以降に出てきた端末は基本的に対応しているはずです。

さてここでもう一つ、「周波数移行はどういう仕組みで行うのですか」という質問が出てきます。今まで通りの制御周波数を、端末は普通にサーチしてしまう仕組みですから、ある日、「移行しまーす」と言って古い制御周波数を止めてしまうと端末は途方に暮れてしまいます。

これは又聞きレベルなので信憑性に期待しないでほしいのですが、その辺の仕組みの一つとして、あらかじめ端末に作りこんである仕組みがあったりするようです。簡単にいうと、起動時には新制御周波数に一旦チューンしてサーチし、見つからなかったら旧周波数での動作になる、という感じ。また、一度新周波数での起動と位置登録に成功したら、旧周波数動作を止めてしまう、というような仕掛けを施して、毎回サーチに時間がかかるような状況を防ぐこともやっていたりするようです。

あと、ちょっと正しくはわからないのですが、後述する推測がらみでいうと、「制御周波数が移行しますよ」という小さな信号を旧周波数に埋め込むようなこともするのではないかと考えられます。これを受けた端末は、旧周波数に位置登録したままの状態であっても、一度新周波数をサーチしにいく、というような動作をするものと考えられます。

こんな感じの仕組みを、結構早い時期から端末に作りこんで移行に備えていたようです。

さて最後に、「3月1日に使えなくなる端末と5月1日に使えなくなる端末など時期ズレがあるのはなぜ」というご質問。先ほどの推測にたどり着いた答えもここにあります。

まず推測結果を書いておくと、3月1日は、「新周波数で発射開始する日」、5月1日は「旧周波数の送信を停止する日」です。

加えて、3月1日から、旧周波数の報知情報チャネル上で、何らかの「新周波数に移行せよ」という信号が送信され始めます。通常、端末は電源をONにした時にしか制御周波数のサーチをしないため、放っておくといつまでも旧周波数をつかんだままです。それを防ぐために、端末に「新しいのがあるぞ」と教えてあげます。

しかし、PHSの標準規格にはこんな信号は定義されていません。おそらくウィルコムの独自信号となります。となると、標準規格通りに作った端末は、この信号を受けると、「報知情報データが壊れている」と判断して動作しなくなるでしょう。これが「3月1日から動作しなくなる端末」。これは、ファームのアップデートをかけることで件の信号を最低限無視し、出来れば内容を解釈して新周波数に移行する、というような対策を行います。

これに比べれば5月1日動作停止の端末は簡単ですね。単に、ファーム書き換えをしないと新周波数に移行できない端末。上で書いたような自動移行の仕組みを備えず、「その時が来ればソフト的に無理やり書き替えちゃえばいいや」というポリシーで作っちゃった端末です。もちろん、そもそも新周波数に対応できない古い端末も5月1日に停止します。

こんな感じで整理をすると、3月～5月の間に「電源を入れ直せ」という端末の存在もすっきりします。報知情報に含まれる「移行せよ」の意味は理解できないけど無視はできる、加えて、電源ONサーチ時には新周波数をサーチする機能も持っている、そういう半端に古い端末は「電源入れ直し」が必要。「一度でも通話すべし」という端末も、通話をして制御周波数に戻るときに、ついでに新周波数もサーチするように作ってあるようなものでしょうね。

ということで、PHS周波数移行に関する疑問あれこれでした。

TWEET

総務省の災害用優先電話のページに、「着信は優先扱いはありません」という趣旨のことが書いてあるけど、これは携帯にも当てはまるの？というご質問をいただきました。

結論から言いますと、その通りです。携帯電話での優先電話の話に絞ると、もともと優先させる仕組みの一つとして、それ以外の電話を発信規制する、というのがベースの仕組みです。これは、端末の自発的な動作なので、それゆえにネットワークに一切負担をかけずに電話を規制し、規制されないものを優先させる、ということが可能になっています。

一方、着信は、ネットワークの呼び出し信号が端末に届いてそれに端末が反応する、というのが基本的な仕組みなのですが、仮にここで、端末が自発的に「被規制動作」をしてしまうと、どうなるでしょうか。「呼び出しがかかったけど、自分、規制中っすから無視っす」とかやるとどうなるか、ということです。

ネットワークとしては、呼び出したのに反応がない、というのは、単に電波が悪いだけかもしれない、と考え、再度呼び出しをかけたりなどいろんな救済を行おうとします。すると、当然ながらネットワークは余計な仕事をすることになるわけです。「ネットワークに負担をかけない」というおおもとの目的を達することができなくなります。なので、ネットワークとしては、「ここまで着信信号が来てるってことは発信側での規制をすり抜けた大切な通話に違いない」という前提で着信信号はすべて通すし、端末も「ネットワーク様がそうおっしゃるなら大切な通話に違いない」と規制を無視して応答する、ということになります。

しかしこれでは、着信通話だけでネットワークが大変なことになってしまいはしないでしょうか。心配ですね。そこで仮に、呼び出し先の電話番号が、優先電話か規制対象の電話か、というのをネットワークで判断できるものとしてみましょう。であれば、規制対象の電話であればそもそも呼び出すのをやめてしまえば、ネットワークの負担はなくなりますね。このようにすれば、着信でも優先制御ができることになります。これができないのであれば、今のシステムは非常に片手落ちですね。

では、もしこの仕組みが実現したとします。ある大災害の日、優先電話を持っている、たとえば災害救助隊が、ある倒壊した家屋の住人が中にいないかどうか電話をかけてみようとしました。ところが、その家の住民は当然ながら優先電話なんて持っていません。なので、救助隊のかけた電話は相手方ネットワーク上で「呼び出し先は規制対象だから呼び出さないよ」と判断されて、相手まで呼び出し信号が届かなくなってしまいます。そう、こんなことが起こってはならないので、今はわざと片手落ち状態にしてあるんです。

基本的に、「優先電話を持っている人とそのネットワークが電話をかけるかどうかの判断の権利を持っている」というのが今の優先電話システムの大前提。この前提を実現するために「発信側のネットワークが通してもよいと判断した発信は、着信側の判断で落としてはいけない」ということにつながります。もちろん、交換機が大輻輳を起こしているときはさすがにこの限りではありませんが、それでも、交換機は優先電話からの発信の可能性を考慮して最後のリソースを残しておくように設計されていることが多いようです。

また、細かい話になるのですが、電話は事業者をまたぐ通話が結構あります。その時、発信が優先だったかどうかというのを相手方に伝えることは、一般的にはできません。もしそういったインターフェースを普通の事業者間接続で開放するといろんな悪用の方法があるためです。緊急電話でさえ、緊急電話専用の交換台からしか緊急着信をさせることはできません。ですので、発信者が優先だったかどうか、ということで着信可否を判断するというのも、実際のネットワークでは実現不可能となっています。

そういうわけで、交換機の混雑で着信が受けられない、という事態でない限り、基本的には着信はすべて通すし、端末も、着信信号に関しては規制状況に関係なく通常通り応答するようになっています。こういう関係は結構昔に決められたので、たぶん今後、いろんな技術革新、たとえばIP交換網によるIP相互接続が基本になってさまざまな付加情報を発着信信号に乗せられるようになり、優先の扱いが容易になる、というようなことがあったとしても、おそらく変えることはないのではないでしょうか。そうやって発着信相互の事業者でいろんな情報をすり合わせするよりも、「発信側ネットワークがすべて判断する」としておく方がシンプルですし、結果的にはおそらく統計効果で細かい制御をした場合と大して変わらないことになりそうな気がします。

ということで優先電話と着信の話でした。

TWEET

先日のドコモの通信障害で一躍時のキーワードとなった「制御信号」なのですが、これに関して、具体的に何を指しているのか、そしてなぜスマホではそれが増えるのか、というご質問をいただきました。

発表されたレベルだと具体的にどの「信号」を指しているのかあまり明らかではないのですが、おそらくは一般的には「シグナリング」と呼ばれているものを日本語訳したところの「信号」ということであろうと仮定して話を進めます。

ドコモの発表では、「チャットやVoIPなど」と、あたかも特定のアプリケーションがこの「信号」を発生させるかのように書かれていますが、基本的には、アプリケーションそのものは（一部の例外を除き）信号を発生させることはありません。あくまでアプリケーションはIPネットワーク上で通常のIPトラフィックを発生させるのみです。

では、実際の障害の原因となった制御信号とは一体何で、どんな時に発生するのか。できるだけ平易に説明してみます。

携帯電話がネットワークに接続する際、「今から接続したいです」という「申請」をします。これに対して、ネットワークは「その前に、あなたは誰？」などという様に確認を開始します。こういったやり取りを何往復かして、接続するための情報（接続者の属性や契約状況、ネットワークの対応状況、などなど）が一揃いそろったところで、「では接続を許可します。○○というルートを使ってIP通信を行ってください」とネットワークが端末に接続許可をすることでようやく通信が開始できるようになります。

実際にこれらのやり取り（制御メッセージ）は、通信そのものとは全く別の特別なやり方でやり取りされています。それを捌くサーバも全く別のものです（仮にハードウェアとしては一つでも、処理システムとしては独立している）。こういった、接続のための調整用の制御信号のやり取りをするシステムを、「呼処理（こしょり）系システム」などと呼びます。

つまり、「制御信号」と呼ばれているものは、この呼処理系の信号のことです。一方、実際のトラフィックは全部ひとまとめに「ユーザデータ」とか「トラフィック系」とか呼ばれます。これは、無線ネットワークとしては単にカプセル化されたビット列を右から左に流しているだけのシステムです。

呼処理系とユーザデータの一番大きな違いは、まさにその部分です。ユーザデータは一過性の、ただ目の前を通り過ぎるビット列であって、その中身を一切関知する必要がありません。だから、サーバのリソースも、そのビット列が通る瞬間だけ浪費され、通り過ぎれば瞬時に解放されます。

一方、呼処理系は、相手との会話が今どんな状況か、相手のIDはなんだったか、処理しているメッセージの内容はどんなだったか、というのを、全部のやり取りが終わるまで覚えておかなければなりません。人間の知覚では一瞬に近いやり取りですが、莫大な数の相手をするサーバから見れば、この「覚えておかなければならない時間」というのは非常に長い時間です。それぞれの相手向けのセッションの一つ一つが「ステートマシン」（自分の状態を覚え変化させる仮想機械）を持ち、リアルタイムに処理を行っているわけですから、サーバのリソースの消費特性はユーザトラフィックを捌くのとは全く別物になります。

たとえば、ユーザトラフィックであれば、大量のパケットが大量に到着した場合、それを格納できるサイズのメモリを用意して待ち行列に放り込んでおけば、あとは一つの処理プログラムが逐次処理をして待ち行列を消化してくれます。しかし、呼処理であればそうはいきません。大量に来た呼処理メッセージの一つ一つをそのオーナーのステートマシンに渡さなければならないし、それぞれのステートマシンが複雑な制御処理を行う必要があります。偶然、何万分の一でしか起こらないようなタイミングのバッティングというものが、莫大な数のステートマシンが同時に動くことで起こる可能性が高まります。もちろん、振り分け処理部が輻輳を起こしてメッセージをステートマシンに渡すのが遅れてしまうと、期待した時間内にメッセージの返答が来ないように見えてしまうため、さらに再送を繰り返すなどで大量のメッセージを生み出してしまうことも起こります。

つまり、ステートマシンそのものが大量にあることで、それ自身が呼処理メッセージ（制御信号）をさらに多く生み出し混雑を加速させることが起こりうるわけです。これが、単なるユーザトラフィックの輻輳よりも制御信号の輻輳が恐ろしいところです。

さて、こういうものが制御信号です、としたうえでドコモの発表に立ち戻ると、「VoIPやチャットが」と言うのは明らかにおかしいことがわかりますね。VoIPやチャットのアプリが使うのはあくまでIP上のデータ、つまりビットが右から左に流れるだけのユーザトラフィックです。アプリそのものが原因であるということは絶対にありえません。

そうではなくて、そういったアプリが定期的に起動して、新着メッセージの有無を確認しようとIPパケットを送信する、その時に、OSは「お、IPパケットが出るからちょっとネットワークにつなぎましょうか」という感じで、毎回ネットワーク接続を起動するんです。当然、接続するための下準備である呼処理が開始されます。つまり、「IPパケットを何度も定期的にやり取りするタイプのアプリ全般が輻輳の元の原因」であって、間違っても「VoIPだから悪い」というわけではないんです。ちょっとドコモにしては軽率な誤りです。

スマートフォンというのは特にこの辺が面倒で、何らかのIPパケットのやり取りが発生しそうになると、自動的にネットワーク接続を開始（復帰）させようとします。スマートフォンではたいていはIP Always Onなので、IP接続の再起動ということはしないのですが、パケット通信では通信トラフィックがない場合は「休止状態」となっていて、これを「アクティブ状態」に復帰させる必要があります。ゼロスタート程ではないにしろ、この復帰手順でもそこそこの量の制御信号が必要とされます。これを、わずか数パケットを送るために定期的に起動されていては確かに制御信号の量は大変なものになります。

また、一部のアプリでは特に面倒な「例外」があって、というのが、ネットワークからのパケット着信がありうる、ということです。これにはいくつかのタイプがあるのですが、細かい違いを割愛すると、ネットワークから何らかのデータを端末に送りつけるときには、端末が休止状態や完全な切断状態でも強引にパケット接続をさせることができる機能。端末の定期送受信とは同期せずに好き勝手にパケットを送りつけてくるアプリがあると、これも制御信号を逼迫させます。VoIPやチャットなどは特にこのタイプの通信を多発させやすいため、ドコモがあえてやり玉に挙げたのかもしれません。

古い携帯電話では、パケット接続の起動・切断は比較的明示的に行われるもので、大体、「接続してから切断するまでに発生するユーザトラフィック」というのがモデル化されていました。これを「コールモデル」と言うのですが、ネットワークの装置を設計するときは必ずコールモデルを立て、呼処理に回すリソースとトラフィック処理に回すリソースをうまくバランスさせたりするわけです。

ところが、スマートフォンは、こういった固定的なコールモデルが全く通用しない。突然のヒットアプリの出現でコールモデルがリアルタイムでゴロリと変わる。古い携帯電話では、キャリア自身が機能追加しない限り変わらなかったトラフィックの発生の仕方が、スマートフォンではキャリアのあずかり知らぬところでひっくり返される可能性が出てきたんですね。これが、ドコモの見誤りの最大の原因。ひいては、ドコモがいろんな装置を独自開発していたことがかえって仇なした例とも言えるでしょう。グローバルベンダは海外の多数の例に基づき、いろんな状況に対応できる柔軟なシステムを作りますが（その分マージンが大きく無駄ともいえるんですが）、ドコモの独自開発では、おそらくドコモ自身のコールモデルに基づき可能な限り効率的なものを目指そうとしていたのでしょう。それが、いつの間にか変わっていたスマートフォンのコールモデルに対応できなくなっていた、と考えられます。

特定のアプリが悪いのではなく、そもそもスマートフォンに対しては、ネットワークの作り方に関する考え方を変えなければならない、ということなんですね。コールモデルは常に変動するものという前提で作らないと、今回のような手痛い障害を起こしうる、と。ドコモは、今まさにスマートフォン移行でこの苦しみを味わっているところです。

ということで、制御信号とな何か、と、ドコモの障害とはなんだったのか、についてのお話でした。

TWEET

ドコモL-09Cの無線LANルータ機能がおかしいという事件（？）が起きていて、これに関して何か思いつくことがないでしょうか、というご質問をいただきました。

リンク先のページのさらにリンク先にいろんな検証結果が出ているので、まずはそちらをご覧いただくとして、結論から言うと、不可解すぎて訳が分かりません。もうここまで来ると実装上のバグとしか言いようがないような気がします。

前にもちょこっとWi-Fiのことは書きましたが、Wi-Fiってかなり実装が自由なんですね。特に、マイクロ秒レベルでの送信タイミングの実装なんてのはもう完全にフリー。好き勝手に動いてよし。ただし、送信する前に他の奴がいないかちょっとだけ確認してね、という仕組み。

で、無線LANルータとして動く、つまりAPとして動くときは、単に通常の通信パケットだけでなく、ビーコンパケットを定期的に送信します。これが出ているか出ていないか、というのが要するにSSIDが見えるかどうか、ということにほぼ相当します。

このビーコンパケットも、原則として一般のパケットと同じように、送る直前に周辺を調べます。ちょっと調べて別の電波が飛んでたら少しだけ送信を後ろ倒しします。その後ろ倒しした先でもまた別の電波が飛んでいたら、また後ろ倒し。ってことを繰り返しているといつまでも送れません。つまり、周辺がすごく混雑していると、このビーコンパケットさえ送れなくなる、ということが起き得ます。

実際には、送る直前のひと調べ、ってのは、その送ろうとする無線LANチャネルの受信電力の測定、ということになります。どんな電波が飛んでいるかを調べるのではなく、単純に「電力」。なので、複数のAP関連の雑音がものすごく低いレベルで飛んでいても、その「合算値」が判定基準になります。なので、いくら個々が弱くてもあまりに大量のAPがある場合、「送ろうと思ったら雑音多いからちょっとタンマ」を繰り返す、という動作をすることは十分にあり得ます。

ただ、一般的にはそれで完全につぶれるようなところはそもそも無線LANチャネルは「空いていない」と判定すべきところなんですよね。ひょっとすると件のL-09Cは、そういうところも「弱いけど空いてるよね」と勝手に判断してそこに自分を置く、みたいな動作をするのかもしれません。

一方、「完全に干渉がなくなる」か「強くて支配的なAPが見える」ようになると、件のL-09Cは電波発射を再開するようですが、これは、支配的なAPが見えれば、「あ、そこは避けよう」と判断して空いている別のところに逃げる、ので送信できるようになるのかもしれないと考えられます。

ただ、実際には、干渉でビーコン送信が阻止されるような状況はまず起こりません。正直に言うと、弱いAPの電力の合算でたまたま送信不可な状況が出来上がっている、っていう説は私自身信じていません。

ってことは、L-09Cは何か全く別の基準で「あ、何とか送信はできるけど、このチャネルなんかあまり良くないからちょっと送信休んで別の無線チャネル調べてみよう」みたいな動きを繰り返しているのかもしれません。無線機ってのは一度に一つのチャネルにしかチューニングできませんから、他のチャネルを調べている間は送信停止です。その送信停止状態と、戻ってきてちょっと送信してみて、っていう状態を行ったり来たりしているのかもしれません。

たとえば、一つのビーコンパケットを送信するのに、連続して何回か失敗（測定結果が悪くて送信後ろ倒しをしちゃった）を繰り返した場合、このチャネルはもうダメだ、と判定するような独自基準が入っていて、しかもその「連続何回」ってのがかなり厳しい基準（せいぜい2回か3回）だったりした場合、その辺に転がっているシチュエーションでも十分に再現できる可能性があります。「空いていると判断する基準が甘い」「パケット送信直前審査がちょっと厳しめ（受信電力値に多少マージンを持たせている）」「独自のダメ判定基準が厳しい」という条件がそろうと、こういう動作になる、かもしれない、という感じです。もちろん、チャネル自動選択のアルゴリズムなんて100社あれば100通りですから、もっと複雑な事情の絡み合いがあるとは思いますが。

ただ、気になる実験もあって、L-09Cを空き缶に閉じ込めたら完全に送信停止しちゃったっていう結果。他のAPも完全に見えなくなってるくさいのに、送信停止しているのは、全く解せません。

ってことで、Wi-Fiの仕組み、無線の特性、って観点からこの謎の現象は説明できそうもありません。やっぱり、L-09Cのバグかなぁ、としか。ってことで解決になってなくてごめんなさいですが、思いつくのはこんなところかなぁ、の一言でした。

TWEET

先日の「LTE仮想化によるスピードアップ」から奇しくも同日発表のWCPのクラウド基地局の話につながった、LTE仮想化ノードによるエリア構築スピードアップの話、twitterにて「拡充スピードだけが本当に大切だろうか、本当に大切なのは品質ではないか」とのご指摘がありました。

全くその通りなんです。実は、あの仮想化のお話、逆説的に「最近の雨後の筍的LTEってのはそういった汎用で品質の担保できない怪しげなものでもある」ということを含ませる意図もなきにしもあらず、で。

確かに、専用設計のハードと専用設計に近いOSの組み合わせってのは、コスト的に非常に高額になるし小回りもきかないものになりがちです。しかし、ハードもOSも、そしてその上で動くノードソフトウェアも自社設計であるということは、かなり品質を自在に設計できるということでもあるんです。

もちろん、従来通り超高品質なものを維持してもいいし、あえて品質を落としてネットワーク側のマージンを稼いでも良い、そういうことができるのは、やはり専用設計品だと思うんですね。

一方の仮想化していく方は、とにかく安くて速いんだけど、詰め込めば詰め込むだけ品質担保レベルが必然的に下がっていきます。おそらく究極的には、やっぱりハード1台に1ノード、という構成だけが品質を担保できる構成で、それ以上を詰め込むことは、同一ハード上・同一メモリ上でお互いが情報雑音となって確率的に品質が担保できない状態になるんではないかと思うんです。

これは、何もLTEノードに限った話ではなくて、昨今のエンタープライズシステムの仮想化の話とかに対しても個人的には同じことを思っていて、一つのソフトウェアエンティティやデータベースエンティティを仮想化かつ分散化していく過程で、他のエンティティと同じメモリを共有することによりお互いが情報雑音になることが、どうしても気持ち悪いなぁ、と思ってるんです。個人的には嫌いな考え方。

昔のリアルタイムOSならメモリ管理はほぼ100%できるのが普通でしたが、最近のノンリアルタイムOSではどうしても確率的にメモリ競合が起きてしまうもの、と思っていて、実際、今までいろんな機器・ソフトウェアの開発や検証を見てきた（傍観してきた；笑）中で、必ずメモリ競合によるごく低い確率での動作不具合は起きていて、しかもそれは根本的に解決不能で、だけどその確率がものすごく低いことがそれを製品として成り立たせている、そういうものをたくさん見てきました。

一つのハードを複数のソフトウェアで共有することはそのメモリ競合を必ず起こる状態にすることだし、仮想化エンティティを増やすということはその起こる確率を倍々ゲームで増やすということです。だから、「何十もの基地局を仮想化して一台に収めた」というのは、品質という観点では必ずしもほめられたものではない、と私は思います。

とはいえ、黎明期にあってはとにかく品質よりもユーザに見えるエリア面積です。要するに営業上の見せ方の問題として、やっぱり「展開速度」は経営上もっとも強力な武器なんです。ということで、さて今後ドコモ・KDDIが、高品質なノードでどのように「整備速度で向かってくる敵」を迎え撃つのか、というあたりが興味深いわけですね。そんなわけで「ドコモさんKDDIさん、メインプランとは別に新興事業者対策の抜け道プランを用意しといた方がいいですよ」という意味のコメントなのでした。でわ。

TWEET

先週末、久々にドコモショップに行ったんです。もちろん目的は、ARROWS Xをさわりに。いや、発売しましたっていうステータスでさすがにホットモックも商用バージョンになってるだろう、と思って。

あ、余談ですが、本当の狙いはARROWS Zですよ。au版の。なんで、と思うかもしれませんが、えー、auって、ホットモック全然配備しないんですよね。少なくともうちの近所の量販と単売りショップ、どちらも今まで最新機種のホットモックを全然置いてこなかったので。っていうか、量販の方なんて、auのホットモック0台ですよ。ドコモ・ソフトバンクが一揃い置いてある中で。au凋落の原因は、そういう顧客に一番近い販売現場にカネを惜しむっていう渋ちんなところだと思うんですよね（ちなみに私の中ではiPhoneで一時復活しているけどたぶん半年もたたないうちに再び凋落ペースに落ちるのは間違いないと予想しています）。

閑話休題。で、ARROWS Xをさわりに行ったんですよ。なんかホットモックの周りには全然人だかりとかもなくて、だけど受付は80分待ちとか大盛況だったんですが、とりあえずホットモックは触り放題だったので、触ってみたんですが。

なんじゃこれ。いや、カクカクだという前評判も聞いてたし、それがドコモ製ホームアプリのせいだっていう情報も知った上での評価ですが、なんですか、これ、売っていいレベルじゃない。なにこのガクガクっぷりは。生まれたての子犬かよ、ってくらいカクカクプルプルしてるよ、ホーム画面が。

そしてその隣にあったAQUOS PHONE、えーと型番は忘れちゃったけど、戯れにそっちも触ってみたら。

なにこのレスポンスの悪さ。タッチして引っ張っても、あからさまに遅れて画面が動き始める。はぁ？って感じ。

ぶっちゃけ、日本メーカ製、総じてひどい。こりゃ、iPhoneユーザに「Androidは操作性が悪い」って馬鹿にされるのもわかりますわ。

普段、EVO使ってて、で、iPhoneユーザが「指に吸い付くようなこの操作感はiPhoneだけ！」とか言ってて、でも実際にお店でiPhone触ってもEVOと全然違いがわからない、だから、ああいった操作感に関するiPhone > Androidなコメントって焦ったApple信者のネガキャンに過ぎないんだろうなぁ、って思ってたんですが、少なくとも富士通とシャープの最新スマホを触って、意味が分かりました。あぁ、こりゃ馬鹿にされるわ、って。

スペック的には一世代遅れているEVOにも全然及ばない操作感には、本当にあきれるしかないです。なんつーか、前にも似たようなことを書きましたけど、日本のメーカのソフトウェア技術力の落ちっぷりは目を覆いたくなるものがあります。

メーカにとってのソフトウェア技術力って、結局は、きっちり要件を定義する、ってところに尽きると思うんですが、どうも、ファンクションの定義には熱心でもパフォーマンスの定義の仕方がわからない（間違ってる）、というところが感じられるんですよね。だから、ファンクションてんこ盛りでパフォーマンス最悪、っていうソフトばかりが量産される。某ウィルコムの某ZERO3のプリインストールのホームアプリもあまりのひどさに投げ捨てたくなったくらい。

ちょっとずつちょっとずつ余計な機能を積み上げて全体としてのパフォーマンスを耐えがたいレベルにまで落とす、っていう日本メーカのお家芸。で、トータルパフォーマンスを上げたくても、機能ごとに開発が縦割りで全体チューニングができない。結局「この機能はこのくらいの負荷なのは当然ですよ、すでにこの機能はめいいっぱいパフォーマンスチューニングできてますし。っていうかこの程度の負荷なんて平気なくらいのハードでしょう？」と機能毎の担当に押し切られておわるんですよ。これはもう、ノートPCを見ても同じですよね。日本メーカ製はくだらないソフト（常駐含む）が大量に入っていてお互いにメモリやディスクを奪い合ってハードは良いのに耐え難いほどに性能が落ちている、っていう感じ。。

いや本当に、国産スマホを（EVOを持った後で）真面目に触ったのって実は初めてだったので（こんなサイト運営してるくせに）、そのあまりの程度の低さにびっくりした、というお話なんです。

いやー、ソフト的な改善がある程度見えるまで、手を出すのはやめておこうかなぁ。さすがにあの操作感では、ストレスたまりまくること必至。

TWEET