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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tweet TWEET

[Tweet]

Written by


ケータイニュース.net
当サイトのニュースチェック用情報収集ポータルをコメント機能付きで開放中。

2 Comments to “制御信号とトラフィック – ドコモの障害に見るスマートフォンの影響”

  1. […] 制御信号とトラフィック — ドコモの障害に見るスマートフォンの影響 … […]

コメントをどうぞ

※ 次のタグが使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

CAPTCHA