AXGPスマホの連続待ち受け時間短すぎ、燃費が悪すぎじゃないですか、なんででしょうか、と言うご質問をいただきました。

え、ほんとかいな、と思って、とりあえず公表されているスペックでの連続待ち受け時間を調べてエクセルに貼り付けてみたんですが、これが思った以上の差が出ていてビックリ。

待ち受け時間の差=消費電力の差、と単純に考え、LTE(AXGP)待ち受けが3G待ち受けの何倍の消費電力になるのか、と言うのを並べて計算してみた結果。ドコモのXi端末だと、1.3倍～1.7倍程度に大体おさまっている感じ、auのLTE端末は、1.1倍～1.3倍くらいでちょっと成績が良いみたいですが、これは測定方法の差と言ってもいいくらいの大した差じゃありません。しかし、ソフトバンクAXGP端末だと、2.4倍～2.6倍。なんじゃこりゃ。

まず、そもそもの話として、LTEは消費電力が大きい、ここは良いですよね。これは、古くはPDCから3Gに方式が移った時も同じでしたが、要するに新しくて広い帯域を使って復調のための演算量の多い方式は、例外なく消費電力が増えます。これが、無線デバイス、演算デバイスの効率化によって徐々に旧方式と同等程度の消費電力に落ち着いていく、と言うのが、新方式が根付いていく流れです。逆にその辺まで行かないと「新方式なんて待ち受け時間短いだけで使えねーよ」ってことになってなかなか一般にまで受け入れられないものなんですが。

そう考えれば、まぁせいぜい3割～5割増程度で済んでいるLTEは結構頑張っている方だと思うんです。LTEは準備段階からガッツリデバイスメーカが関わっているし、（3Gでの経験から）仕様策定のかなり初期からバッテリ寿命に関する議論がものすごく盛んだったので、なかなかいい感じにできた、と言えるわけです。

では、ドコモ・KDDIのLTEとAXGPの燃費の差はいったい何か。FDDとTDDの差でしょうか。

実際には、単なる待ち受け状態に関しては、FDDとTDDの差はほとんどありません。LTEのフレームは、10個のサブフレームが集まってできていますが、この中のどこのサブフレームのどの辺の位置に待ち受け用のチャネル（ページングチャネル）があるのかが予め決まっています。一方、TDDでは、この10個のサブフレームのうちのいくつかを上り用にする、と言う形でTDDを実現しています。当然ながら、この上り用にするサブフレーム位置は、待ち受け用情報の無い場所が選択されます。要するに、待ち受けるだけなら、実はFDDかTDDかの違いは（ほぼ）出ないような作りになってるんですね。

となると考えられる原因としては、「1 TD-LTEデバイスがすごくこなれてない」「2 ひょっとして両面待ちしてない？」の二点になります。

1については話は簡単。TD-LTEはまだ世界でもマイナーな仕様です。変復調・シグナリングに関してはFDD-LTEとほぼ共通なので、その辺が消費電力増大に関係がある可能性は低いですが、アナログデバイスに関してはFDD-LTE用に比べれば出ている数は圧倒的に少ない。なので、まだまだ性能が詰め切れていない可能性は存分にあります。で、まだ燃費が悪いのかも、と言う説。

問題は2。TD-LTE=AXGPでの3Gとの連携についてはAXGPのサービスインのころから言及されていて、要するに、ドコモやKDDIがやっているようにLTEオンリー待ち受けで3Gでの音声発着信に対応する仕組みは備わっていますよと宣言されていたので、本来はこの疑いは「ナシ」です。しかし、緊急地震速報、災害情報が絡むと途端に話が面倒になります。AXGPは多分これらに対応していません（相互接続・配信システム的な意味で）。すると、これらの情報を取得するには、端末はAXGP待ち受けと同時に3Gも定期的に見る必要があります。これは3Gに在圏（位置登録）して3Gのページングチャネルを受信するのと同義です。前に連携の話とかでも書いたようにLTE-3G連携システムでの在圏情報は排他なので、実際問題として緊急地震速報受信ON/OFFでAXGP+3G待ち受けかAXGP待ち受けかを変える、なんていう動作は（標準仕様上も）現実的ではなく、この対応のために、常時両面待ちをしている可能性があります。

上記はすべて妄想なので、本当の答えはわかりません。私としてはハズしていると思っています。思ってはいるんですが、3G待ち受け電力を1とし、LTEオンリー待ち受けの電力が（ドコモ・KDDIの例から）1.5程度と考えると、足すと2.5。ソフトバンクのAXGP待ち受けの電力とぴたりと符合しちゃうから、ちょっと気持ち悪いんですよね。と言うことで中の人の情報待ちです（えぇ～）。

と言うことで、なぜAXGPが燃費が悪いのかについて答えのない一言でした。

TWEET

SIMフリー版のiPhone5が買えるようになったんですが、どうやら、「2GHzの3Gだけ」と言うよくわからん縛りがあったりするようです。これに関して、「850MHz(Band5)帯でドコモの800帯はカバーできてるけどなんで？」と言うご質問と、「LTEも2GHzが対応してるのになんで？」と言うご質問をいただいています。憶測交じりで解説。

800MHz帯は世界中で大人気の帯域なので、あらゆる国でいろんな使い方がされています。日本も例外とならず、米国とほぼ同じような使い方をしています。で、米国で使われている「Band5」と言うのがあるのですが、これが実は、ドコモが使っている「Band19」をすっぽりとカバーしているため、Band5対応の端末はドコモ帯域に完全に対応しています。

しかしここから非常にややこしい話なのですが、実は、帯域のMHzの数字が同じでも、実はそのまま使えるというものではありません。こればかりは本当に理不尽でわかりにくい仕組みなのですが、端末が動作できるかどうかは、MHzの数字ではなく、バンド番号(上でいう5とか19)で決まっています。

なぜこんなことになっているのかと言うと、実は、バンド番号ごとに別々の端末テスト規定があるからです。たとえば、同じく850MHz近辺の送受信ができる端末を作ったとしても、最終的には「Band5用テスト」だけをパスしたものは、Band5でしか動作せず、Band19では動作してはいけないという決まりがあるのです。

なので、この端末の場合は、最終試験で、Band5のテストとBand19のテストを両方パスして各国の公的機関に認定をもらわなければなりません。たとえば、単に二つ分のテストをパスさせるための準備やらお布施やらがもったいないというだけの理由で、Band5だけのテストで済ませちゃえ、と言う理由でのBand19非対応もあり得てしまうんです。

実際にはもう少しめいどい話がBand5とBand19にはあって、実はこの二つのバンド、テスト規定のパス基準が違います。Band19の方が思いっきり厳しい規定になっています(日本の電波法規定がものすごく厳しいからなんですが；そもそも似たような帯域なのに日本向けのバンド番号が独立しているものが多いのもこの理由)。しかもBand19なんて世界でドコモしか使っていません。なので、Band19をパスさせるってのは、どうせドコモで使われることがないんならできればサボりたいネタの一つなんですね。もちろん、知っている人は知っていると思いますが、Band5とBand19の両対応端末を作る場合の特例的な緩和措置があるので、規定そのものの厳しい基準を通さなきゃならないってほどでもないんですが、それでもめんどいものはめんどい、ってことです。iPhoneみたいに莫大な数が売れちゃう端末ともなると、それをサボれば1台3円のコストダウンだったとしても大変な利益寄与ですから、やっぱりそっちに向いちゃうんじゃないかと思います。

とかなんとかいう、非常に細かい話もあって、同じ800帯なのにサポートできてないなんて話もあるんですが、まぁこれもあと1年もすればデバイス価格がぐーんと下がってあっさりとサポートするようになると思います。今ははっきり言ってLTE対応デバイスは売り手市場で高止まりしてるんですよね。この辺が落ち着けば、たぶん。

さてもう一つ、バンド的には対応しているはずの2GHz帯で、なぜかドコモのLTEが使えない話なんですが、普通に考えれば、ドコモがiPhoneからの接続を弾いている、と言うことになるかと思います。めんどくさいですから。たとえば、単にXi端末でない端末IDからの接続はLTEからデタッチさせちゃうなんてのは簡単。ただ、iOSの新しい版だとつながるなんていうウワサもあるみたいですが、iOSのアップデートだけで治るのであれば、ドコモは弾いたりしてないけどiPhone側が対応してなかっただけ、と言うことも考えられます。

と言うことで、ドコモ網でのiPhone利用に関するお話でした。

TWEET

こんな質問をいただきました。「新BSチャンネルのIF周波数とソフトバンクULTRASPEEDが干渉して問題を起こしているようですが、ほかのCSチャンネルのIF周波数でも、たとえば2GHz帯に丸かぶりのところがあって干渉問題を起こしてもおかしくない気がしますが、そんな話は聞きません。なぜでしょうか」

はい、最初に答えを書きますと、私もわかりません（笑）。なので、ここからは推測とすごく古いもんやりとした記憶だけで憶測を書きまくります。たぶん間違っていますので、信じないでください。

今回問題となっている新BSチャンネルが1.5GHz帯に干渉する話、まずはなぜこんなことが起こっているのかを簡単にご説明。

衛星放送は、12GHzとかなんとかいうものすごく高い周波数を使っています。一般のTV放送が500MHzとかその程度ですから、24倍も高い周波数です。まず普通に考えて、一般の個人が購入できるような無線機器では、こんなに広い周波数幅を扱えるようなものはほとんどないし、非常に高価なものになってしまいます。

ってことで、衛星放送では、アンテナに入った直後に、周波数変換をします。12GHzの周波数帯を、一気に1GHzくらいにまで落とします。おおよそ10GHzくらい、ざっくりと引き算しちゃうわけです。実は周波数の世界では周波数をざくっと引き算しちゃうという処理は案外簡単にできちゃうもので、衛星放送の受信アンテナはこの機能を備えていて、ケーブルに出てくるときにはすでに1GHzのオーダーの電波に変わっています。

となると、一般のTV放送と比べてもせいぜい2～3倍の周波数ですから、従来のケーブルなどが再利用できるようになります。ほとんどの場合、宅内配線にはほとんど手を入れずに衛星放送を受信できるようになりますし、古い配線を使っている場合でも比較的安価なケーブルを追加で引けば簡単に受信できるようになる、というのが、この周波数変換の恩恵となります。で、この変換後の周波数を「IF周波数」と言っているわけです。

さて、今回問題が起こったのは、新しく追加されたBSの周波数です。衛星の周波数を追加する、ということなんですが、先ほども書いた通り、アンテナ自体は単に「周波数の引き算をしているだけ」なので、空から新しい周波数が飛んで来ればそれも単に一緒に引き算してケーブルに出力することになります。で、この引き算した結果の周波数が、たまたまソフトバンクがULTRASPEEDをやっている1.5GHz帯にぴったり重なったわけです。

普通は、家庭用の受信系統であっても、そう簡単に外には漏れないように作るわけですが、やっぱりいろいろと手抜きをする余地もあるわけで、そういうところから、この1.5GHzのケーブル内電波が、空中に飛び出してしまう事案が出てきてしまった、ということですね。

さてここまでが確認された問題。一方、結構前から、CS放送として放送されている電波があります。これも、同じようにパラボラアンテナで周波数シフトされるわけですが、その中の一部は、確実に2GHz帯、つまり、3G携帯で使っている周波数帯に重なっているものがあります。もちろんその周辺、たとえば、1.9GHz帯のPHSにかぶっているものもあります。

とすると、こういった周波数がなぜ今まで問題を起こさなかったのか、が疑問に思えるのも当然です。私も、あれ、確かに言われてみれば、という感じです。ということで以下憶測。

まず、歴史的に、1.9GHzや2GHzが使われ始めるのが早かった、ということがあります。110度CSが本格放送を始めるより早くから、この周波数帯がPHSや携帯電話に使われることがわかっていました。このため、110度CSに対応したブースターは最初から与干渉を考慮した設計になっていたことが想像できます。

一方、BSの方は、アナログ放送のころから同じ周波数帯で、非常に歴史が古く、逆に1.5GHz帯が携帯電話に使われる見込みとなったのはごく最近のことです。となると、古いBS対応ブースターは与干渉に関して非常にルーズな作りになっていたことが想像できます。

1.5で問題が起きて2Gで問題が起きない本質は、たぶんこの辺かなぁ、という気がします。

問題を起こす場合、とにかくまずはブースターによってIF周波数がブーストされなきゃならないわけで、BSだけを前提としたブースターは基本的にはCSの高い周波数帯はカットしている（あるいは適当にブーストはかかるけど増幅率は弱い）と思われ、こういった古くてたくさんばらまかれたブースターが2G帯を汚す確率は比較的低いわけです。一方、そんな古くてたくさんあるブースターは例外なく1.5GHz帯にかぶるBS-IFはフルパワーでブーストしてくれるので、それこそちりも積もればの要領で結構な汚染をばらまいている可能性があります。

先ほども書いた通り、そもそも110度CSは開始が遅かったこともありますし、それより早くにやっていたその他のCSも経度が違ったりマニアックなチャンネルだったりで普及度は決して高くなく、CS-IFに対応したブースターはかなり限られたところにしか置かれていないでしょう。一般的なTVが当たり前のようにCSチューナを内蔵するようになった最近になれば、すでに2GHzが携帯に使われることを知っているわけで、与干渉に慎重な「お行儀のいい」ブースターとなっているはず。「数が少ない」「与干渉源となることが予めわかっていた」という二つの理由から、CS-IFによる2GHzへの影響はかなり少なく済んだのではないかと考えます。

以上私の憶測以上妄想未満の考えですが、えー、なんというか、ちゃんと真相を知っている人がいたら教えてください（笑）。いや、古い記憶をたどると、CS-IFによってPHSだか2GHz携帯だかが影響を受けちゃってちょっと困ったなぁっていう話を聞いたことがあったような気がして、それもなんだかすごくレアな古いCSブースターだからしょうがないよね、みたいな話があった気がして、こんな憶測になってるんですけど、この辺が完全に記憶違いかもしれないので。

以上、BS-IFとCS-IFによる携帯への影響についてでした。

TWEET

今日は質問いっこだけの短いエントリ。

Xi対応端末はXiとFOMAの両方の電波を受信するので待ち受け時間が短いという話を聞いたけど本当でしょうか、というご質問。

前にもLTEの質問に答えるの回である程度なぜバッテリの持ちが悪いのか、という話は書きましたが、一方で、この「両待ち受け説」には全く触れていませんでしたね。というかそんな説があったのか。

この辺については、LTE他システム連携の話で本当に一言だけで触れていたのですが、他システムと連携するLTEは、LTEシングル待ち受けが原則です。デュアル待ち受けをすることもできないわけではありませんが、よほどの理由がない限りやりません。それは、まさに「バッテリライフが極端に短くなるから」という理由です。

他システムと連携する（というか音声肩代わりさせる）タイプのLTEでは、LTE側に音声着信信号が飛んできます。その着信信号を受けた端末が、即座に音声対応システムを立ち上げて音声通話を開始する、そのために、音声セッション情報を音声システム（ドコモでいえばFOMA）とLTE（Xi）の間で共有するために、連携システムが作られています。この辺の話は、LTE音声着信率の話でも詳しく書いてあります。

ということで、「両待ち受け説」は基本的に間違い。LTEとWCDMAで着信連携をする、という前提でネットワークを作っているところは両待ち受けはしないはずです。ただ、たとえばとりあえず適当なEPCとLTE局を買ってきて適当にばらまいて本当に仮のLTEサービスを突貫で始めちゃうみたいなことをやる事業者だと、WCDMA側の連携システム対応が間に合わずにしばらくは両待ち受け、なんていう状態もなくはないですが、いまどきのUMTSコアはたいていはいつでも対応できるのでソフト買ってね状態だと思うしもちろんEPCも適当なの買ってきてもたいていは連携対応してるとは思うしインターフェースも標準化されてるからベンダが違ってもつながっちゃうと思うし。

そんなわけで、Xiでバッテリ消費が大きい話の補足でした。

TWEET

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

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

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

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

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