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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TWEET