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

ウィルコムの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

小ネタ。[ZTE ジャパン] ZTEがWireless City Planningに納入したAXGP基地局が2011年11月に商用予定と言うニュースに関してのコメントで、「ICICやCCIAは自律分散じゃないか」との指摘があるとの話、どう思いますか、と言うメールをいただきました。

さて、元々のPHSの自律分散機能とは、基地局が隣の基地局の電波を自分で受信し、それを邪魔しないように自分の居場所を見つける、と言うような機能と、端末に通話チャネルが割り当てられるときに、一定時間キャリアセンスを行ってチャネルが空いていることを確認する、と言う機能の二つを指しています。

一方、件のリリースに書いてある「ICIC」と「CCIA」と言うのは、標準技術的なものであると仮定すれば、隣同士のセル(基地局)が、お互いに自分が使っているリソース情報を交換して、リソースの使い方を変える、と言う技術です。つまり、基地局同士が接続され協調するという意味では「自律分散」ではなく、汎セル・リソース制御とでもいうべきものです。

具体的に何をするかと言うと、LTEで定義されているリソースブロック(RB)の単位で自分がどこを使っているかを隣接セルに通知し、隣接セルはそれに基づいて同じ周波数&スロットを占有するRBの電力を落として距離の近い端末に割り当てる、と言うようなことをします。こうすることで、お互いにセル端にいる端末に同じRBを高い電力で割り当てて干渉してしまうことを防ぐわけです。

CCIAについては標準の用語ではないようですが、標準でこれに該当しそうなのは、セルIDとRACHの割り当ての協調機能。セルIDは、それによってセルから常時送信しているリファレンス信号の位置が決まるため、セルIDをお互いに被らないようにすることで干渉を減らせますし、RACHは端末から基地局への最初のアクセス信号、これを送信可能なタイミングは基地局が決めるのですが、これもタイミングが被らないように協調することで端末の信号同士が混信してしまうのを防ぐことが出来ます。これを総称してCCIAとしているのだと思います。

つまり、LTEの協調機能は全然「自律」じゃないんですね。他律。あくまで他律。相手から教えてもらった情報を元に動作を変えるもの。そしてもっと重要なのは、そうやって隣同士を関連付けること自体には技術の入り込む余地がありません。「どのセルとどのセルが隣り合っているか」と言うのは、人手で決めるしかないんです。もちろん、「隣接セル情報の自動更新」と言う機能も標準で定められていますが、この場合の「隣接セル」とは「ハンドオーバ可能な隣接セル」のことであり、「セル端の干渉協調をするための隣接セル」とは全く別物になってしまうことが予想されます。と言うより、仮にハンドオーバ可能な全ての局と干渉協調関係を結ぶと、それが積み重なってあらゆるリソースが制限対象になってしまい、まともに動かなくなると思います。あくまで特別なパートナーシップを結んだ局同士での協調。

と言うことで、そういう設計が必要と言う意味でも「自律分散」とは程遠いんですね。PHSの自律分散は、実際に電波を受信してみて邪魔になっているかどうかで判断します。だから設計不要。その代わり、「受信してみる」と言う動作に非常に長い時間がかかるため、接続が遅い、移動に弱い、広帯域化しにくい、などなどのデメリットも出てくるわけです。

ちなみに、ICICなどは標準化されていますが、実際は標準化されていないのと同じ。一番重要な、「隣からこういう情報が来たらこう動く」と言うところが白紙です。つまり、そういったアルゴリズムは、キャリアやベンダが自分で決めなさい、と言うこと。となると、この機能を有効に働かせるためには、全ての基地局ソフトウェアをキャリアが開発するか、同じエリアは同じベンダの基地局で統一するかしないといけないということになります。非常に使いにくい技術なんですね。ってことで、一部の例外を除き大抵はエリアごとにベンダを統一し、こういった独自機能をうまく使う方法で進めているようです。

以上、LTEの局間協調機能に関する小ネタ。でした。

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

小ネタ。「iPhoneのモデムチップがMDM6610で、auのHIGH SPEED対応のARROWS ZがMDM6600で、後継チップ使っているはずのiPhoneがHIGH SPEED対応していないのは納得いかない」(意訳)とのことです。

すみません、正直、チップ屋のラインナップポリシーは分からないんですが、Qualcommに関しては、数字が大きければ単純に機能が多いというものでもなかった気がします。最初にデモンストレーション的な意味で全部いりスペシャルチップ出して、機能削ってコストを安くした版を後から出す、ってこともあった気がする。

ので、ひょっとすると、6610はHIGH SPEED (Rev.B)対応を削った版かもしんないですね。Rev.Bって結構でかいバージョンアップだから回路規模もかなり大きくて、それ削るだけで全然コストが違う、なんてことは十分にあるかも。受信帯域幅が3倍なのでアナログ回路にも大きな影響がありそうだし。あるいは、6600に対してRev.Bを削って空いたダイ容量(?)にUMTSを入れた、とかかも。

よくわかんないですが、6610が単純に6600の機能アップ版と言うものでもなさそうなので、UMTS対応&機能限定版か、あるいは、アナログ回路部分のコスト削減のために機能をOFFにしてあるか、って感じかなぁ、と。

ついでに小ネタその2。「iPhone4Sのau版で○が出て速度が遅くなるのは一体何?回避方法はないの?」と言うご質問。

なんなんでしょうね、あれ(笑)。いや、多分1xに落ちてるんだろうって言う話は処々で出ていて、まぁ多分その通りなんでしょうけど、「1x」って表示しないで「○」ってところが、微妙な笑いを誘います。

で、1xってのは回線交換ベースのシステムで、と言ってももちろんパケット通信(的な)システムも持っていて、その最大速度が一応144kbpsなので、速度がかなり制限されてしまう、と言うのはその通り。

なんですが、噂になっているほどの高確率で出るようなものじゃないと思うんですけど。ってのが、私も、iPhone4Sと全く同じ無線構成、つまり2GHzと新800MHzしか対応していないEVOを常用していて、1xになっていることってほとんど無いんです。

1x表示を見るのは、地下鉄でトンネル内の圏外状態におちて、その後次の駅が見えてきたときに数秒間だけ1x表示が出ます。その後、すぐに3G表示に変わって、普通の3G通信が出来るんですよね。それ以外の場所で1x表示を見たことが無い。

ただ、この地下鉄のとき、1x表示になった瞬間にブラウザのリンクをクリックしたりすると、もちろん1xで通信が始まるんですが、この通信が終わって落ち着く(つまり休止状態=ドーマントになる)まで、1x表示を引っ張る傾向があります。1xからEVDOへのアクティブ状態での遷移ってのはあまりうまく出来ないのかも(出来ることもたまにあるので)。一応違う搬送波なので、周波数間ハンドオーバになり、つまり、別周波数メジャメントって言うめんどくさい動作が必要になるので、確かに1xがアクティブに通信中は遷移しにくいのかも知れません。

でもなぜiPhoneでは噂になるほどこれがおきているのか。不思議です。多分、ですが、一応、完全なTDMAのEVDOと違って、1xは拡散方式なので拡散利得があり、その分わずかながらEVDOよりエリアが広いことが考えられます。そこにきて、iPhone4Sでもおそらくデスグリップ問題は存在します、筐体がアンテナである以上は確実に。今回はダイバシティ受信でデスグリップ問題の顕在化を回避するようになっていますが、パイロット信号(待ち受け信号)を受信するときはダイバシティは働かないはずなので、このデスグリップで受信感度が劣化し、結果としてわずかに優位な1xを掴んじゃうケースが増えているのかも。←大嘘書いてるかもしれないのでご注意。

と言うことで小ネタ二連発でした。

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