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

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

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

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

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

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

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

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

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

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

TWEET

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TWEET

このまえKDDIが発表した移動・固定コンバージョン戦略について、改めてちょっと書いてみたいと思います。いや個人的には自宅がauひかりだし、借り物じゃない移動と固定（アクセス線）を持っている唯一の事業者という意味で、本当のFMCに一番近い事業者だと思っているので、ちょっと興味はあるんです。

発表されたことをおさらいすると、まず一番上に「スマートパスポート構想」というのがあり、移動、準移動、固定などなどが共通のIDで共通のコンテンツやサービスを利用できる、というところを目指しているような感じ。で、その構想を実現するための個々のサービスとして、割引サービス「スマートバリュー」、コンテンツパック「スマートパス」、共通ID「au ID」という三本柱がある、という感じ。

一言で言ってしまうとたったこれだけのことなんですが、ここから発展してどんなことが起きることを想定しているのか、ということを考えてみます。

まず、アクセスサービス事業者として最終的に目指している（っぽい）ところは、「1契約だけで家庭の固定ネットワーク（インターネット＋電話）と家族全員分の携帯電話（スマートフォン）とそれらが対応したすべてのアクセスサービスを利用できるようにする」という感じかと思います。

正直、FTTHや提携CATVを引っ張ったからと言ってスマホをいきなり1500円近くも割り引いちゃうのはでかすぎる。これは逆に、「スマホが割り引かれる」から一歩進めて、「1家族契約に○○円のオプション料金でスマホが持てるよ」というところに向かおうとしているのかな、という感じ。

もちろんその「1家族契約」には、FTTHまたはCATV接続権と公衆Wi-Fi接続権が基本的についてきている。そこにスマホ（=3G/4G接続権）をオプションで足す、という考え方になるのかな、と。いや、まだそこまで踏み込んだ説明はない気がしますが、固定・移動を統合していく、かつ、家族を1単位と考える、という発表内容から考えれば、将来はこの方向に行くのだろうな、と思います。

以前に某所で「今FMCと言っている事業者は単なる料金割引でしかFMCを実現できていない、つまらない」と発言したことがありますが、上のような考え方なのであれば、別契約をそれぞれ割り引くという考え方から単一契約のオプション化という形で、契約上の変化は感じられる気がします。まぁそこはあくまで契約書/請求書の上だけの話で、請求書だけで実現してきた従来のFMCからさほど変わるところではないのですが。

しかし、これに加えて出てきている話が、マルチデバイス、つまり同じコンテンツを異なる機器、異なるネットワーク経由で利用できるようにする、という構想。たとえばスマホで買った動画がFTTH経由でも見られるとか、親が買ったアプリを子供が別のスマホから使う、そういうことを想定しているようです。

こうなると、「契約が一つにまとまる」効果が出てくるような気がします。つまり、基本的にコンテンツやサービスのオプション契約は基本契約（家族契約）にひも付き、あとはそのライセンシングの問題として処理できるわけです。たとえばあるサービスは家族につき1契約で全員が利用できるし、あるコンテンツは○台分ライセンスが含まれててそれを超えたら使うスマホの台数分のライセンスが必要ですよ、というような形で、家族単位ですっきり整理できる。従来のように「個別契約＆割引」でこのようなことを実現しようとすると、家族割引相手の誰かがこのコンテンツを買っていてなおかつそれ以外でそのコンテンツを無料利用している契約が○個以下なら自分はそのコンテンツの代金を割り引いてもらえます、なんていう超めんどくさい形態になってしまいます。しかもそれがコンテンツ・サービスごとに。

また、私が昔言ったような「機能的なネットワークの統合」というところはまだあまり感じられないのですが、それを間接的に実現できるのが「au ID」という考え方だと思うわけで、これは、ネットワークが認証するIDを使って、デバイスのアプリ経由で連携を持たせる、というある意味逆転の発想。ネットワークノード同士がID連携するのではなく、ネットワークノードは真面目に端末の相手だけして、端末がそれぞれのネットワークノード上の自分のIDを一つの統一IDで統合する、というアイデアだと思います（違ってたらゴメン）。

このアイデアが成立するのなら、実は、こういった考え方は何もKDDIだけに実現できるものでもないんですよね。ぶっちゃけ、資本関係さえなくてもいい。何しろノード同士が会話する必要はなく、その上位のID管理アプリケーションサーバさえ統一したものが置いておけるなら何でもいいんです。いや、今回の話の中で、全く資本関係のないケイ・オプティコムやその他CATVが入っているのが不思議だったんですが、このように考えれば、それら提携先は単に土管に徹し、その上を「勝手にau IDが飛び交っている」という状態であっても統合サービスとして成立しうるわけです。

たとえば、今、OCNが独自のスマホ向けIP電話サービスを始めていますが、これはOCN管理のIDがどのスマホでも利用できる、という形。考え方は同じですよね。OCNがハブとなって統一IDと利用アプリを準備し、それをドコモやNTT東西に配ることで同じような統合サービスを行うことは不可能ではないはずです。あるは、OCNがVNO、MVNOとなって統合してもいい。東西とドコモが「うちは単なる土管です」と言い張れば、NTT法もバイパスできるかも（※先日ドコモMVNOの日本通信がそういうコンセプトを発表しちゃいましたね）。あるいはソフトバンクが、FTTHのアクセスに使っているNTT東西と組み、こういったサービスを行っていくことも可能でしょう。もちろん、接続料やアプリライセンス料などの「売り上げの取り分」でもめることは容易に想像でき（笑）、そういった「社間のもめごとが起こらない」という点が1社体制であるKDDIがこういったサービスで一歩先を行ける最大の根拠となるのかなぁ、と個人的には考察します。M&Aで会社コレクションしていただけじゃなかったのね、と。

ということで、KDDIの統合サービスについての考察でした。

TWEET