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

先日、VoLTEの音質の話を書いたところ、その直後?にSamsungとLGがVoLTE端末を作りました、と言うニュースがありました。で、これに関して、「どういう方式なのでしょうか、OTTでしょうか」というようなご質問がありましたので、タイムリーなうちに記事にしておきます。

ちなみに、「OTT」というのは「Over The Top」のことで、一般的には、キャリアが提供しているインターネット接続サービスよりも上のレイヤでいろいろやるような人やサービスのことです。たとえば、NTTcomの050plusなんてのは典型的なOTT IP電話サービスです。要するに、「The インターネット」の相互接続性を頼りにしたサービス一般ですね。

一方、そうではない、「非OTT」なのは、たとえばキャリアのインターネット接続サービスそのものだったり、普通の電話サービスだったりです。キャリアが独自に相互接続性を保証することでEnd-Endの通信が成り立つようなもの。インターネット接続サービスは、キャリアがIXか一次プロバイダかに直接接続することで接続性を保証しますし、電話は、キャリア内の交換網で電話同士を接続し、キャリア外に向けては、相手キャリアとの直接相互接続で接続性を保証します。もちろんキャリアがOTTを提供してもいいわけで、特にドコモなんぞは「土管化を避ける!」みたいな旗を掲げていろんなOTT的サービスに参入していますね。

さて、本来の意味でのVoLTEは、「非OTT」です。基本的な仕組みはVoIPなので、IPルートさえ通ればどこにでもつながる、と言うのが本来の形のように思えますが、VoLTEの基本は、VoLTE音声トラフィックは「The インターネット」には直接出ていくことはなく、キャリア内で交換され、他キャリアには相互接続点でのみ出ていく、と言うのが形になります。「The インターネット」は、原則論としてどこの誰のノードを経由するかを送信側が限定することはできません。だから、潜在的にありとあらゆる品質劣化を受ける可能性を持っています。VoLTEはキャリアグレードの電話サービスとして、そういう危険エリアにトラフィックをさらすことなく交換を完結させることになっています(そういう意味では、ソフトバンクの「The インターネット」経由のフェムトなんてのは、キャリアグレード品質を保証できないOTTに近いサービスと言えます)。

ってことで、「ちゃんと標準化されたVoLTE」なら、非OTTのはず。です。で、今回の発表を見ると、まずは韓国LGU+に供給し、ついで米国MetroPCSにも提供する、となっているので、これはおそらく各キャリア独自のOTTではなく同じ標準に従ったVoLTE、つまり非OTTのVoLTEではないかなぁ、と思います。あくまで私の推測ではありますが。

ちなみに、3GPPでのVoLTEの仕様自体は相当前に固まっていて、2010年時点で端末への実装のガイドライン的なものもいろいろとできていたりするので、今年のこのくらいの時期に本物のVoLTE端末が出てきても全然不思議ではないです。どっちかと言うとインフラの対応の方がずっと遅れることが予想されていたので、LGU+やMetroPCSのような割と小規模でチャレンジングなキャリアが先行してようやくインフラ導入にこぎつけた、というような感じではないでしょうか。

ということで、簡単ですが私なりの所感を書かせていただきました。

tweet TWEET

アイサットフォンと電波天文の干渉という問題について、結論として「電波望遠鏡の近くで使わないように」ということに落ち着いていますが、衛星って広く電波が降ってきているものなのに近くで使わないだけでOKなんですか、と言う質問をいただいていました。ちょっと回答が遅くなってしまいましたが、今日は簡単に。

アイサットフォンはインマルサットを使った電話サービスの一つ。なので、基本的に従来のインマルサットの周波数帯を使います。

で、もともとインマルサットは、地上局は固定や船舶がメイン、また、移動局でも指向性が高いアンテナを持ち、非常に限られた使用者しかいないようなものなので問題視されていませんでしたが、アイサットフォンのように指向性の低いアンテナで個人が自由に持ち歩けるようなタイプとなってしまうと、電波望遠鏡の近くでの干渉が問題になってきたのではないかと思われます。

ここで、なぜ「近くだけ」問題になるのか、と言うと、周波数配置がポイント。インマルサットの周波数は、地上→衛星の周波数バンドと衛星→地上の周波数バンドのうち、地上→衛星のバンドが電波天文学用バンドに非常に近いんです。逆に、衛星→地上は非常に広い範囲に強い電波をばらまくことになってしまうので、電波天文学用バンドから離れた方のバンドを使う様にした、と言うのが真相だったかもしれません(情報不明瞭)。

となると、地上→衛星バンドが電波天文学に干渉することになります。つまり、地上移動局が発する電波。もちろん地上移動局だって不要発射を十分に抑えるようにフィルターを持っていますが、それでも(電波天文学的には)結構大きなレベルの不要発射を出してしまいます。

電波望遠鏡は言ってみれば巨大なパラボラアンテナなんですが(なので古い衛星通信用アンテナを流用したりもする)、いくらパラボラと言っても、周辺からの漏れ込みをゼロにするということはできません。パラボラ面の横から受信素子に直接入っていくような電波もあるでしょうし、ななめ方向にも割と強いゲインを持つサイドローブを持っていたりもします。そういうところにアイサットフォン端末がいて、これが衛星に向かって電波を発射すると、電波望遠鏡にも影響を与えてしまうことになります。具体的には、背景ノイズレベルが上がってしまい、観測解像度が下がってしまうわけです。

ってことで、アイサットフォンは電波望遠鏡の近くで使っちゃだめですよ、ってことになります。日本で大きな電波天文台と言うと、まず何を置いても野辺山ですね。あと、確か山口と茨城に割と大きいやつ、岩手水沢+小笠原父島+鹿児島薩摩川内+石垣島のVLBIあたりが大きな観測所です。ってことで、この近くに行くときは、出来ればアイサットフォンは電源OFFでよろしく。

tweet TWEET

ウィルコムのALL ITX化が済んだという情報。なんだか公式発表されないのが腑に落ちないのですが(NTTへの配慮とか?)、転送時の発信元電話番号が通知されるようになったことを確認できました。これで結構便利になります。

今、メインの回線はウィルコム定額プランGに誰とでも定額をつけてあるので、転送先をドコモのメイン回線にしても転送通話料はかかりません(のはず)。誰定でも通話料かかるようです。しょっく。まぁ、そこまで電話がかかってくることはないので誰定は外してしまった方が安くなるとは思うのですが、気分的な問題で。

で、少なくとも転送番号表示が可能になったということは、ALL ITXが完了したということのはず。というのは、ITX化局と非ITX局が混在すると、番号通知の際にインターフェースの不整合が起こってしまうので、そういう状況が起こりえない、ということが確定するまではサービスできないからです。

さて、ALL ITXが達成すると、ほかにも(潜在的に)できることがいろいろと出てきます。まず、ぶっちゃけMNPには相当近づきます。というか、070もMNPに参加しましょうという総務省のお達しはたぶんウィルコムからの申し入れで、それを実現する大前提は、1局の漏れもなくITX化することです(1局でも非ITX局があるとその局配下の通話は誤った通話先につながってしまう)。これができるようになることがおそらく直近の効果。

あとは私の妄想レベルの話になりますが、ライトメールとSMSの相互互換が可能になる可能性が出てきます。後は細かい点だと、現在はできない「発信中(呼び出し中)」のハンドオーバができるようになり、今までよりも移動中の発着呼に強くなるかもしれません。これができないのは、もう本当に単純にNTT交換機の機能制限のせいだと聞いたことがあるので。それと、PHSのPS-IDをたくさん持たせた端末でたくさんのセッションを同時に張る、なんてこともできるようになるかも(無線機は一台で)。要するに、音声とパケットの同時接続とか。

また、ITXからの光ファイバの足を直接貸し出すサービスも考えられます。というか、すでに自治体向けにそれに近いサービスをしていますが、すべてのPHS収容局舎がITX化しているということは、おそらく日本でも有数の広さのIP網を持っているということです。下手するとNTT東西のフレッツよりも広いところさえあるかも、くらいの話。NTT東西が変な品質規定のために光もADSLも足を出せないような田舎にも、光か銅線の足を出してIP系サービスを提供できるかもしれません。まぁユーザには直接恩恵はありませんが。

ってことで、ウィルコムのALL ITX化についての簡単なコメントでした。

tweet TWEET

ちょっと前に、とある近郊の小さな駅に用事があっていくことがあったんです。その駅の出口からすぐ目の前には、小さな個人商店がたくさん並んだ商店街っぽい感じの道があるんです。大体、すべてのお店が、間口3m~5m程度の。

そこで見た驚くべき光景とは。

隣り合ったお店ことごとくに、ソフトバンクのWi-Fiステッカーが貼ってあるんですよ。駅に一番近い定食屋みたいなところから、その商店の並びの果てまで、全部のお店に「Wi-Fi使えます(犬)」のステッカーが貼ってあるんです。

さすがに全部のお店をチェックするわけにもいきませんが、原則として、あのステッカーって、Wi-Fi APを設置してあるお店に張るものですよね。なので、駅前から全部のお店に、まさにローラー作戦でWi-Fi APを設置して回ってるんです。だからこそ、「24万AP!圧倒的!」なんていう数を稼げるわけですけど。

さすがに背筋が凍りましたよ。無線のお仕事をしている身としては。

2000年代前半、企業へのWi-Fi導入が盛んだったころ、ネットワーク系の専門誌は一時期どこも「これからは構内Wi-Fiで低コストLANを」という論調一色だったんですが、その1~2年後から一斉に「企業を悩ます構内Wi-Fi」という話題があふれたんです。

その理由は言わずもがな、無線LANの干渉問題。少し前に、無線LAN、というかWi-Fi(802.11系)の干渉についての解説を書かせていただきましたが、Wi-Fiは基本的に自律的にタイミングをずらすことで電波が潰れることを防ぐ方式です。ただし、電波がつぶれない代わりに、他のAPや端末が出した電波をよけるために、それを避けるのに必要な時間以上を自発的に止めるということが必要になるため、他のAPや端末が増えれば増えるほど加速的に効率が悪くなる方式です。

このため、一つのフロアに複数台を設置したり、またその配下に多くの端末を収容したり、あるいは、近隣に多くの他社APがあるような場所では、無線LANの通信効率が非常識なほど落ちてしまい、たとえば、Wi-FiとVoIPを活用した構内電話システムを作ってはみたけれどほどなくまともに通話できなくなってしまった、などという問題を起こしています。このため企業では、AP同士の配置を綿密に設計し、さらに隠れ端末問題の排除のためにWi-Fiの電波を遮断するパーティションを設けるなど四苦八苦していたんです。

さて、ここで最初の話に戻ります。ソフトバンクのAPが、要するに、3m~5mというすごいせまい間隔で大量に設置されている、という話になるんです。隠れ端末云々なんて言うまでもなく、これだけの密度となると、ビーコン信号だけで大変なものです。しかもほとんどが木造に近い商店なので、遮蔽効果は低く、50m、100mほど電波が飛んでしまう可能性が高くなります。

さらに、どこかのAPの下に端末が一台入るだけで、その干渉影響範囲は最大で倍にまで増えます。端末も同じチャネルで電波を出すからです。しかもその電波がビーコンや他のパケット送信に影響を与え、それらがどこかで輻輳的な状態になると、しばらくの間、周辺は再送パケットや遅延ビーコンであふれかえることになります。もし一台のスマートフォンがWi-FiをONにしたままその商店街を通り抜けると、周辺の2.4Gはすさまじい汚染を受けることになります。

間違いなく、ローラー作戦を行った営業担当は無線の知識はゼロです。無線の技術的な知識がないだけでなく、ほんの数年前に一般に手に入るレベルの情報誌にも乗っていたような無線LANによる干渉の問題提起さえ目を通していないようなずぶの素人です。こういう人たちが、単に上から「とにかく数を稼げ」と命令されて片っ端からAPを置いている状況です。その結果が「圧倒的な24万AP」です。

そりゃね、ソフトバンクが、適していないかもしれないロケーションにアホみたいに携帯基地局を立てて「基地局数No.1」とか言ってその実、実際の品質はもちろん干渉で落ちている、なんていう状況なら、ソフトバンクユーザは宣伝のために品質落とされてかわいそうだな、っていう、対岸の火事で済んでいたんですけど、残念ながら、今のAP乱造だけは、そうじゃありません。みんなの共有帯域で運用されるWi-Fiを無計画にばらまいて莫大な干渉を日々増やし続けているんです。

無計画のバカ、というだけならかわいいものですが、残念ながら、今ソフトバンクがやっていることは、2.4Gに対するテロリズムです。宣伝のためのAP数稼ぎと引き換えに他人を巻き込んだ環境汚染を進めているんです。

私の家の近所にも、お互い結構距離の近い個人商店などに無計画にAPが設置されているところがあったりして、その魔の手が私の家の至近にまで迫らないか、冷や汗ものです。ただでさえ、私の家は近所の2.4G利用者が多くてかなりパフォーマンスが落ちているのに、ここでソフトバンクのAPばらまきまで加わっては、さすがにお手上げです。

もうこれは切実な問題として、ソフトバンク様にお願いしたいんです。どうか、無用なAPばらまきをやめてください。無駄に密度の高いAPを間引きしてください。AP同士は最低でも100m以上離すように、技術を持ったベンダを使ってきちんと設計してください。設置店舗から路上に漏れて隠れ端末問題を起こさないよう、店舗の電波遮蔽の対策をきちんと講じてください。ソフトバンク様が自分の責任帯域で勝手にやっている分は看過できましたが、みんなの帯域を使うWi-Fiでは、どうか、それを環境問題として考えてください。伏してお願い申し上げます。

補足記事

tweet 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 TWEET

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tweet TWEET

さて、雨後の筍・・・とかいうと失礼なのかもしれませんが、携帯電話事業者が今年相次いでLTEを開始すると発表。しかも、ずいぶん前から用意していたドコモ・KDDIはともかく、LTE開始を発表して間もないソフトバンク・イーモバイルがすごい速さでLTEをサービスインすることについて、なぜそんなことになっているかの考察。

いや、これはもう古い携帯電話システムをある程度知っている人なら、そんなに「ちょっとやってみる」みたいに始められるようなものじゃないはずだ携帯電話システムというのは、と思うはずなんですよね。とにかく携帯電話システムは鈍重で融通が利かないものが多いんです。

たとえば、LTE未満の携帯電話システム、WCDMAやCDMA2000では、まず、携帯電話基地局と基地局制御装置が別の位置においてあることが一般的。別の位置になくても、その間には、各方式に独自のインターフェースが一つ切ってあります。それぞれのインタフェースがこれまた独自の性能要求を持っていたりします(たとえばきっちり1ミリ秒グリッドで動作しなきゃならないとか)。ということは、その独自インタフェースに対応したハードウェアとミドルウェアとOSが必要になります。つまり、ほぼ0からハードもOSもソフトも設計・開発しなきゃならない。これが、制御装置とかだけじゃなくゲートウェイとか認証装置とかもろもろに同じように面倒な事情が乗っかっています。

しかも、インフラベンダごとにその作り方は独自なので、あるベンダから買うものをほかのハードで流用できないわけで、ほとんどの場合、インフラベンダの言い値でハードを買わされる羽目になります。何しろ、インフラベンダが「売ってあげない」と言ったらお手上げなわけで、事業者は良いカモです。

もちろん、インターフェースがすべてぶつ切りなので、その階層ごとにそれぞれ独立した一つのネットワークを維持管理しなければなりません。しかもそれらすべてがこれまた異なる性能・品質を求めるようなものを、です。

こうなると当然値段も保守費も大幅に上がってしまうため、一つのシステムを持ったらもう一つ別のものを持つというのは、よほど体力がない限り難しい。業界3位とはいえ決算書ベースではKDDIをすでに凌駕した2位であるソフトバンクでさえ、複数システムの維持はあまりに重い課題で、ちょっと前まではLTEに手を出しあぐねていたというところがあります。

にもかかわらず、言ってみれば零細事業者であるイーモバイルでさえあっという間にLTEを始めますみたいな話になっているのはどういうことか、ということなんですが、要するに、上で書いた問題点がすっきり片付きつつあるんですよね、最近。

LTEインフラのもっとも大きな特徴の一つが、「IPフルフラットネットワーク」です。つまり、一つの大きなIP網の中に、加入者管理サーバも移動管理サーバも接続ゲートウェイもそしてすべての基地局さえもが対等に参加するというシステム。IPであるが故の「遅延揺らぎ」「パケロス」などを許容できる設計。これは究極的には「IP」というたった一つのインターフェースにすべての装置が相乗りできるということを意味します。

当然、従来はいろんな独自インターフェースを事業者が自分で定義しなきゃならなかった「運用・監視系ネットワーク」も同じIP網に乗せることができます(VPNくらいは切るでしょうけど)。要するに、「とりあえず全国カバーできるIP網いっこ」を用意して、あとは必要に応じて装置を買ってきてぶら下げればとりあえずはLTEが動いちゃう。

また、LTEになってから、インターフェースのベースがすべてIPであるため、汎用のサーバ装置、汎用のOSがそのまま使えるようになる傾向が強いようです。なので、ハードとしては一般的なハードを一括で買い、その上に乗せるソフトウェアだけでLTEの各ノードを実現する、そういうやり方が通用するようになっているようです。極論すれば、基地局でさえ半分はこの方法で作れなくもありません(もう半分は無線出力を担う部分=RRH)。

こうなるとソフトウェア技術の強い会社が基地局の無線部分以外について汎用サーバに乗せられるような「LTEノードアプリ」としてガシガシと作って提供できるようになります。自然競争も激しくなり、かなり安く「ノード」を入手できるようになります。そのため、零細(失礼)のイーモバイルでさえ、とりあえず現在のWCDMAネットワークのコアあたりに使っているIP網上にVPN一つ切ってLTE各ノードを何も考えずにぶら下げるだけでLTEがサービス開始できちゃったりするわけです。

また、一番面倒な無線部(RRH)に関しても、最近のものはマルチテクノロジ対応が一般的です。つまり、同じRRHでWCDMAもLTEも出力できる、というものです。意識せずにマルチテクノロジ対応のRRHをすでに展開済みであれば、その根元にLTE基地局(の半分を実現するソフトウェア入りサーバ=BBU)を追加で置くだけで何となくLTEっぽいものができちゃう。これが、LTEのすごいところなんですね。

ソフトバンク(というかWCP)のLTEもほぼこの発想で、PHS用IP網に汎用LTEノードをガシガシぶら下げただけだと思われます。加えて、アンテナはPHS共用(もともとXGP対応のため1.9G/2.5Gデュアル化済み)。だから、あとは併設できる小さな基地局装置を買ってきてばらまけば完了です。

という感じで、LTEは、ネットワーク事業者に非常に優しいシステムになっているわけで、そのあたりが、最近すごい速度で新事業者がサービスインできている理由かなぁ、と思います。いや、究極的には、LTEの全ノードを一台のサーバの中にソフトウェアだけで仮想的に実現する、なんてこともできるようになるかもしれず、そうなったらいよいよ事業者の負担は軽くなります。既存事業者がレガシーネットワークとの連携をする限りこれは絵に描いた餅ですが、今後、周波数さえある程度手当できれば、こういった究極的な集中管理ネットワークによる超閉域LTE事業者、なんてものも出てくるようになるかもしれません。

ということで、LTE整備が楽になってきてるっぽいよ、という考察でした。

tweet TWEET
2011/12/27 10:00 · ニュース解説 · 1 comment

iOS 5.0.1で気になるバッテリ駆動時間は伸びたか?という記事に関して、「緊急地震速報を切るだけでバッテリ持続が大幅に伸びたと書いてあるが、緊急地震速報の本来の仕組み上は影響がないはずでは」というご質問をいただきました。

えーと、しょっぱなから種明かししますが、記事で扱っているのは、ソフトバンク版のiPhoneですね。ソフトバンクのネットワークはダイナミックな緊急地震速報に対応していないみたいです。つまり、無線チャネル的には、緊急地震速報を常時送信している状態。単に、地震がないときは空っぽにしてあるだけで、無線チャネルは開きっぱなし。なので、それに対応する端末も、緊急地震速報用のチャネルを常時受信しています(常時といってももちろん一定間隔の間欠受信ですけど)。

というような話はこちらの記事の追記で軽く触れているのですが、緊急地震速報を実現する仕組みであるCBSシステムというのは元々は全員で同じ情報を一斉受信するための仕組みで、受信設定してある端末は、このチャネルがある状態では常時見ていること、というのが本来の動作なんですね。

ただこれではあまりにバッテリ持ちが悪い。一方、このチャネルが設定されているかどうかというのは別の報知情報という同じく一斉送信情報の中に含まれていて、だったらこの報知情報の中のCBSのON/OFFをダイナミックに変えてやればいいじゃない、というのがドコモのアプローチ。報知情報がダイナミックに変わるときは自動的にページング(呼び出し)が出ることになっているので、通常の待ち受け状態の端末でもその変化を知ることができ、ゆえにバッテリ持ちに一切影響なく緊急地震速報を実現できるということになります。さらに、ドコモでは最近は新しいETWSを採用していて、これは上記報知情報に直接地震速報を載せるタイプのため、CBS用のチャネルを見に行く必要さえなく速報性が大幅に高まっています。

一方、auのCDMA2000では、BCSMSというSMSの強化版のような方式を採用しています。もともと、CDMA2000のページングチャネルというのは、なんだかいろんな下り向け情報を載せられるようにできていて、実は通常SMSもページングチャネルで送れるようになっているみたいです(いろいろ調べてみた結果)。まぁそれは余談としても、BCSMSもSMSと同じようにページングでトリガをかけるので、やはり通常の待ち受け状態と全く同じ状態で緊急地震速報を待ち受けることができ、バッテリへの影響は皆無です。

そんなわけで、標準仕様をうまく組み合わせてバッテリ影響を回避したドコモや、標準上バッテリ影響が皆無のCDMA2000を使うauに比べ、ソフトバンクは「標準の流用としての緊急地震速報」を本当に標準のままで使っているために、機能をONにしておくだけで何倍もの無線電力を使っていることになります。

消費電力の話でも書いた通り、無線機の消費電力というのはおそらく密度でいえば携帯電話機の中では断トツ、それが、頑張って頑張って受信タイミングを超短くして低消費電力化したのがページングチャネルの間欠受信というシステムなんですが、CBSの常時受信なんてのはそんな努力を根底からぶっ壊すようなシステムなわけで、そりゃこれをON/OFFするだけで消費電力はあほみたいに違ってきます。

ということで件の記事での低消費電力化、緊急地震速報をOFFにする、という対策はソフトバンク版だけに有効な対策なのでご注意。au版は緊急地震速報をOFFにしてもバッテリ持ちは変わりませんのでOFFにしないようにしてください(au版ってそもそもOFFにできないのかな?)。

tweet TWEET
2011/12/27 10:00 · ニュース解説 · 1 comment