ちょっと古いネタですが、auの障害の時に音声もつながらなくなったのはどうしてでしょうか、という質問をいただいています。というのも、CDMA2000はデータと音声が独立したシステムなので仮にデータが輻輳しても音声には影響は出ないのではないか、ということからです。

普通に考えれば確かにその通りなのですが、そもそもLTEと旧システムが連携しているということを考えるとちょっと問題が複雑になってきます。

LTEが障害で全く使えない、完全にゼロ、という状態であれば、すべての端末は3Gに落ちてしまい、あとは3Gの輻輳だけが問題になってきます。CDMA2000であればシステムが独立しているので影響は出にくいかもしれません。もちろん、データ(EVDO)側が完全に輻輳でつながらないと、音声系(1x)のデータ回線に切り替わるということも起きるので(iPhoneの○印が出るアレ)、これが原因で輻輳ということは考えられますが、それでもデータ用チャネルよりは音声用チャネルを優先制御するくらいのことはやっているはずなので、この状況での影響は出にくいでしょう。

しかし、先ほどの記事の音声連携の仕組みを見るとわかるのですが、音声着信の信号(ページング)はLTE上で送信され、LTE上でそれに応答するのが連携システムの基本です。もしLTEが障害で信号がほとんど通らない状況だとすると、このページングが端末まで届かないため、音声着信ができないということになります。また、発信でも最初のネゴ(どの周波数が利用可能か、など)はLTE網を経由して他網と通信します。このため、LTE障害で信号が通らないとこれもアウトです。

上記の「ページング」や「ネゴのための信号」、実はどちらもLTEにおける特定装置を経由します。すなわち「MME」なんですね。ってことは、MMEが落ちるとどちらもダメになってしまうんです。先日のau障害はまさしくMMEの障害だったため、音声通話ができないというユーザが出てくる可能性が確かにあったわけです。当初、障害箇所はMMEっぽいという発表、それでも音声に影響ありませんと書いてあったのを見て私は「そんなわけないんだけどなぁ」と思ったくらいです。

もちろん、完全に全端末を3Gに落とせればこのタイプの通話不良は回避できるんですが、そもそもそういったこと(たとえば端末を強制Detachさせること)を制御できるMMEが死んじゃってるので、MMEが落ちたことに気づかずに在圏したままの端末はほどほど残ってしまうことになります(通信をしようとしてMMEからの応答がなくて3Gに落ちる、というような契機がないと普通はMMEが落ちていることに端末は気づかない)。いっそ全基地局の電波を止めるくらいのことをすればよかったんでしょうがそこまでやる大胆さをKDDIは持ち合わせず、半端にLTEに残ってしまった端末が音声不可になっていたものを思われます。実は私の端末もしばらくの間、LTEの電波つかんでました。

ということで、LTE障害なのに音声影響はなぜの話でした。あ、上の推測は全部憶測ですよ、念のため。

地下鉄のトンネル内で駅に着く前に電車が止まると、車両によっては圏外になったりすることを見たことがあります、地下鉄の駅間カバーとかってどんな感じで作っているんでしょうか、と言う質問をいただきました。

まず、前にも似たようなことを書いた気がしますが、地下鉄の携帯カバーについての基本。地下鉄など需要はすごくあるけどスペースが全然ない、と言うような場所をカバーするために、JMCIAと言う組織があります。これは、トンネルや地下街などの携帯電話カバーを、事業者みんなで協力して整備しましょう、っていう組織。

と言うのも、たとえば地下鉄の場合、鉄道会社としては他人の装置をおかせたくなんてない、っていう事情があり、置く装置をできるだけ少なくしたいという事情があります。そこで、みんなで共用できるものは共用しましょう、ということで、JMCIAが出てきます。

具体的にどんな感じで置いているのか、と言うところについてですが、代表的なものを説明してみます。これ以外にもあるかもですが、私はあまり聞いたことがないです。

1つ目。トンネルの入り口に、奥に吹き込むように基地局(またはレピータ)アンテナを設置。あんまり主流ではなさそうですが、あるというウワサを聞いたことがあります。これは簡単なことで、入り口から奥に向かって電波を吹き込むことでトンネルの奥までカバーするようなもの。なので、一番奥、あるいは(反対側も同じ処置をしていない場合は)反対側の出口近くは電波が届かないことが往々にして起こります。

2つ目。トンネルの中の随所に、アンテナを設置。実際には、基地局から出たアンテナ線を共用の装置でたくさんに分割し、分割した信号線の先にさらに増幅装置+アンテナを設置するようなやり方。これを、トンネル内に一定間隔で置いておきます。すると、その個別の装置からのカバーエリアは狭くてもそれが細かく置いてあるので結果としてトンネル内をしっかりをカバーできます。難点は、一つの基地局の信号をたくさんに無理やり分割するのでノイズがすごく上がり、電波は良くても品質が下がりやすくなる、ということ。

3つ目。今はもうほとんどこの方式じゃないかと思うんですが、漏えい同軸ケーブル方式。トンネル内に長ーい同軸ケーブルを這わせるんですが、そのケーブルに、じんわりと電力が空中に漏れるように隙間を作ってあります。その隙間から漏れた電力が、そのものズバリ、携帯電話の電波と言うわけです。分割・増幅なんてことをしないのでノイズも上がらないし、その割にはしっかり遠くまでカバーできます。普通にアンテナを置くと円形に出ていく電波を一旦無理やり同軸ケーブルに閉じ込めて、ところどころに抜け穴を作ってあげるというイメージですね。すごく細長いエリアを作っているようなものです。実はやっていることの本質は1つ目の「片側から吹き込んであげる」と全く同じことだったりします。なので短所も質的には同じ。ただ、手前を漏れにくく奥を漏れやすく、みたいな使い方で割と奥まで一定して届かせるといったやり方が常套手段となっているので、奥の方が届きにくいという短所はカバーされています。

と言うことで、地下鉄も漏えい同軸で作ってると思うんですが、それでも駅に近づくと圏外になる、と言う辺りがなぜと言うのは不思議です。が、そもそも漏えい同軸と言うのは、ケーブルから離れるとあっという間に電波が弱ります。あんまり飛ばないんですね。特に軸方向。

と言うことで、漏えい同軸ケーブルの「始まり点」と「終わり点」がどこにあるか、と言う辺りで、ケーブルの始まり点がホームの電波が届くよりも奥にせざるを得なかったような駅間では、ホーム前で停車したりすると、電波が届かないエリアができている可能性はあります。こればっかりは、トンネルの構造などによるのでどうしようもない場所ってのは出てきます。トンネル内の電源用の溝とかを活用してるんだと思いますが、この出入り口をホームぎりぎりに置かなきゃならない理由なんてそもそも無いですからね。できる範囲でやるとなると、どこかに穴はできるでしょうね。

JMCIAの事業計画を見ると、駅構内のセル分割なんてのもあるようで、もしホーム内のセルを分割すれば、ホームからトンネルにしみこむ範囲ももう少し広がることになると思うので、こういった穴も徐々に埋まっていく可能性はあると思います。まぁなんにしろ、JMCIA頑張れー、と言うことで。何もしていないくせに後から来てtwitterで自慢して自分の手柄にするようなどっかのインチキ社長なんぞに負けるなー。

もう私から見ると雲の上のレイヤーの話になっちゃうのですが、VoLTE、LTE上の音声サービスについて、解説を希望する声が絶えないので、取り上げてみます。嘘書いてても知らないよ！！

VoLTE=Voice Over LTEの略で、LTE無線・システム上で音声サービスをするための仕組み、あるいはサービスそのもののことです。

従来、3Gまでのシステムであれば、音声交換専用のシステムと、音声伝送専用の無線チャネルが定義されていて、音声サービス=これらのシステム・チャネルを使ったサービス、と言う様にされていました。3Gまでは、基本的に、こういった音声サービスをベースに開発が始まり、データは付随物に近い扱いだったわけです。

しかし、LTEは最初からデータ向けシステムとして開発が始まり、もちろんご存知の通りデータ通信サービスから開始されました。少なくとも国内ではLTEはまだデータ専用システムで、ほとんどの諸外国でも同じ状況です。

従来3Gが、音声・データそれぞれで伝送システムやチャネルを異にしていたように、新しいシステムでも音声データ分離が行われるのであれば話は簡単なのですが、LTEはフルIPフラットネットワークを一番の売りにしています。ここに、音声専用の伝送系統が追加されるなんていうのはいくらなんでも筋が悪い。と言うことで、LTE上の音声は、最初からVoIPを流用したシステムとなることが決まっていました。むしろ、「IPのパイプさえ通っちゃえばあとはVoIPでもなんでも使えば音声だろうがビデオだろうがいくらでも通せるんだから気にしなくていいよね」的な発想でIP接続専用サービスとしてLTEが作られていった、と言うのが真相です。

ただしそうはいっても、素のLTEデータ回線上で、極ふつーのVoIPクライアントを使っても、電話サービスとして求められる品質の担保と言うところからほど遠いのは想像に難くありません。確かにアプリレベルでVoIPで通話ができるようなサービスはたくさんあり、ほどほどの品質を確保できているものもありますが、結局そういったアプリは無線の不安定さ、ネットワークの輻輳、そういったものに対しては完全に無力です。できることは、巨大なジッタバッファを用意することくらい。これは当然音声の盛大な遅延となって現れるため、単にバッファを大きくすればいいというわけでもなく、どこかで折り合いをつける必要があります。

ところが、VoLTEは、事業者クラスの電話サービスとしての品質が確保されるようにしなければなりません。特に日本では緊急呼を扱うという要請上その品質はかなり高度に保つ必要があります。単にIPパイプがあるから何でもやり放題だぞー、と言うわけにはいかないんですね。

めんどくさいので答えを書いちゃうと、LTEでは、普通のベストエフォートのIP接続の仕組みとは別に、帯域確保型(Guaranteed Bit Rate)のチャネルを用意する仕組みがあります。優先制御は割と細かく決められているんですが、その中でざっくりと、帯域確保かそうでないか、と言うのが決められていて、サービスごとに使い分けて良いようになっています。細かく言うと、たとえば音声は多少パケットがロスってもいいから帯域確保かつ低遅延で、みたいな感じになっていて、リアルタイム性を重視しつつ無駄なフレーム再送なども起こらないようになっています。

なので、VoLTEを使う時には、ある端末に対してきっちりと○○bpsを割り当てる、と言うようなことができるようになっているんですね。もちろん、無線の割り当ての上でどういう戦略で一定帯域を確保するか、と言うのはまさに技術的な工夫のしどころの一つで、この仕組みの出来如何でエンドトゥエンドの音声品質が全然違うということも起こると思います。

さて、そうはいってもVoLTEも中身はIP電話です。SkypeやLINEと違い、IPベースで通話を始めてもきちんと上に書いたような帯域の確保が行われるのはなぜか、と言う点も気になります。

ポイントは、こういった制御のためにきめ細かに定義された上位システムです。以下にざっくりと動きを書きますと。

まず、端末がLTEに接続するときに、VoLTE用のセッション管理サーバ(CSCFなど)(SIPサーバみたいなもの)の情報をLTE網(正確にはデータ接続ゲートウェイ)からもらうことができる仕組みがあり、これを通知してもらったらその内容に従ってセッション管理サーバに位置登録します。この専用のセッション管理サーバが後述のポリシー管理サーバ(PCRF)と連携して帯域保障無線チャネルを起動できるVoIPサーバのイメージです。この連携があることが、一般のVoIPとVoLTEの大きな違いとなります。

実際の通話のときは、端末がセッション管理サーバに向けて「今から音声通話したいです」と要求し、セッション管理サーバがポリシー管理サーバに対して「こいつに音声通話をさせてやりたいんですが」と問い合わせします。ポリシー管理サーバはここで、その加入者に音声サービスを提供できるかと言うポリシー的な判断をし、LTEネットワークに対して、その端末のための帯域保障チャネルを割り当てするようにお願いを投げます。これで、IP上で音声通話をすると決めただけなのになぜ帯域保障チャネルが張られるのか、と言う点がわかってきます。音声専用の伝送系があるわけではないのですが、上位システムとしてはやはりLTE音声のためのシステムが定義されている、と言うことで、「IPパイプがあるからVoIPサーバ立ててみた」と言うレベルとは厳然たる隔たりがあるわけです。

と言うことで、こういった連携で帯域保障チャネルを確保して、そこにVoIPデータを流すように端末とネットワークで調整を行い、音声が通る、っていうのがVoLTEの大まかな仕組みです。伝送系はIPで共有するので低コストながらも標準的なQoS制御と何よりも無線チャネルの専用割り当てを使うことで高品質を維持できる、というわけです。以上、VoLTEってのがどんなのかっていうお話でした。

こちらのLTE基地局数グラフで、グラフ作成がうまくできない不具合がありましたので修正しました。

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

言い訳をすると、なんか先月にありえない無線搬送波共存パターンを削らなきゃならなかったときに、削るための判定ルーチンが月をまたぐと動かないとかいう超めんどくさいバグを作りこんでました。我ながらすごい。

なおっていますので今後ともよろしくです。