移動体通信のはてな

私は自動車で移動中に、UK、北米のニュースをストリーミングで聴いています。

最近、夕刻の時間帯に音声が途切れることが多くなりました。

通信速度が遅くなっているようです。

バックボーンのネットワークのトラフィックが上がって、帯域が狭くなっているのかもしれません。

エアインターフェイスは携帯電話会社のものを使っていますが、背後のネットワークは他の長距離通信会社と契約しています。

その会社が提供するネットワークの帯域が、法人契約のトランザクションでも動き出すのか、その時間帯で狭くなっているようです。

先日、大規模通信障害が発生しましたが、多くの人が一体何が起きていたのか不明だったのではないでしょうか。

私の移動体通信は複数のバックアップシステムを構成しているため、完全に不通になる可能性は低くなっています。

それでも障害で通信できなくなる危惧が全くないわけではありません。

先日の大規模障害を振り返ってみましょう。

移動体通信

　3000万加入者のモバイル通信システムで障害が発生。

　ほぼ全ての加入者に繋がらない、または繋がりにくい状態となり、復旧まで数日間を要しました。

　休日の保守作業中に、ルーターの設定ミスのため通信断となります。

　１０分後(数分〜数十分）通信断に気づき、ルータの設定を元の状態に戻します。

　ルータの設定は元の状態に戻り、その装置は稼働し始めたが、通話ができない状態が続きました。

　ルータの設定ミス。

　それだけでしょうか？

　ルータの設定誤りは、元の状態に戻すことで修正されました。設定誤りが元の稼働中の設定に戻れば繋がりそうです。

　しかし障害は３日以上継続しました。

　原因は別のところにあります。

　ルータの設定ミスは、障害発生の契機にすぎません。

　システム全体から見た障害復旧長時間化の要因は、データベースのI/Oボトルネック(注)です。

以下、詳細に見ていきましょう。

通信の仕組み

　移動体通信端末は、通信サービスを提供する会社の通信インフラシステムに、端末を接続することで通話ができる仕組みになっています。

　直接、端末が信号をやり取りするのは、通信会社が全国に網の目のように張り巡らせた基地局と呼ばれる装置の一つです。

　基地局の設置は開いたパラソルを隙間なく、地面に並べたような配置になります。

　端末は近くにあるいずれかの基地局と通信することで通信インフラ網に接続し、通話やネットワークアクセスが可能になります。

　どの基地局と接続するかは、移動体端末の位置に依存しており、その時点で最も通信感度の良い基地局と通信することになります。

　電源が入っている全ての端末が、いずれかの基地局の配下にあり、その位置情報は基地局の配下にある情報と関連付けて通信インフラに認識されています。

発信者が特定の電話番号に発呼すると、通信インフラはその電話番号で識別される端末がどの基地局の配下にあるか、内部テーブルと照合し、該当基地局に向けて通信路を作ることで通話が可能になります。

　

　移動体端末は基地局を跨いで移動するため、通信インフラは基地局間の境界で、基地局を切り替える処理を行います。

　これをハンズオーバーと言います。

　移動体端末は基地局をハンズオーバーしながら、インフラとの接続を維持しています。

　このように移動体端末の位置情報はリアルタイムで基地局と結び付けられて管理されています。

通話が繋がらない状態

　通話が繋がらない状態、「電源を切っておられます」とアナウンスされる状態は、端末に結び付けられた基地局の配下で、該当端末が応答しないという状態です。

　内部テーブルは、その基地局の配下に端末があるはずなので、通信インフラはその基地局に向けて通信路を開こうとしますが、端末が反応しません。

　通信インフラとユーザー間の終端のエアインターフェイスの部分で、基地局と端末が接続できないケースです。

　実際に電源を切っている場合、このケースに該当します。

　あるいは何らかの理由でテーブルの位置情報と実際の端末の位置が整合していないケースです。

　実際の端末は別の基地局の配下にあるにもかかわらず、通信インフラはそれとは異なる基地局の配下に端末があると認識しています。

　端末は、応答を要求する基地局の電波が届かない、全く別の基地局の配下にあります。そのため通信回線が開けないのです。

　「電源を切っておられるか、電波の届かない状態」は、通信インフラが認識している端末の位置情報が示す基地局の配下で、端末が応答しない状態です。

　通信インフラが保持する位置情報に結びついた基地局の配下に端末が存在しないため、その基地局に呼び出し信号を送っても端末は別の場所にいるため応答できないのです。

　大規模通信障害では、全国規模で各通信端末がこうした状況に置かれていたと考えられます。

移動体通信端末のハンズオーバー

　山手線の乗客は携帯電話の電源を切って乗車するでしょうか？

　おそらく乗客の全てが電源ONのまま移動します。

　１０分間乗車していると、全ての山手線で運行中の全車両の全乗客の位置情報が切り替わります。

　首都高を移動中の全てのドライバーと同乗者の位置情報が切り替わります。

　首都圏の電車、移動中の車両、繁華街の通行人の全ての位置情報が切り替わります。

　ルータの通信遮断を契機に全国規模かあるいは大規模な地域で、移動している加入者の位置情報が、通信インフラ内に記憶している位置情報と整合性が取れない状況が発生したと考えられます。

　インフラ内のデータが、移動した加入者端末の実際の位置と一致しなくなったのです。

　ルータの不通ラインが基幹ネットワークの帯域が広いラインだったと考えられます。

　ルータ復旧後、通信インフラは、位置情報不一致の状態を解消するためのデータの更新作業を行います。

　この間に移動した全ての加入者の位置情報のデータ更新手続きで、ネットワークの輻輳（注）が発生したのです。

位置情報データ

　加入者情報の管理にデータベース（以下　DB）を用います。

DBは人間が操作する速度で応答します。

　これは加入者の課金情報や課金手続きを処理する際、扱いやすい構造です。

　交換機にも位置情報のテーブルがあり、発呼端末から受けた相手先の識別情報を参照して、相手先端末とエアインターフェイスを通じてワイヤレス接続する基地局の情報を取得します。交換機は、その基地局向けに通信路を開くのです。

　つまり、その基地局向けに通信パケットを送信します。

　端末とその端末に結びついた基地局の識別データが、端末の位置情報とみなせます。

　この交換機内の位置情報と、インフラが管理する加入者情報と結びついた位置情報は整合性が取れていなければ通信できません。

　移動体端末は通話していない時でも、一定間隔でビーコンという識別情報を発信しています。

端末が電源を上げていれば、このビーコンを発するため、近くの基地局がそのビーコンを受信します。

　通信インフラは基地局が受信したビーコンにより、個別の端末がどの基地局の近くにあるか認識して位置情報のテーブルを更新するのです。

　

　通常の状態では、電源ONの端末の位置情報は常に更新され、交換機と加入者情報のDBの位置情報は整合性が取れています。

交換機とサーバーのDB間でも位置情報が確認されるため、両者のデータが不一致のまま稼働することはありません。

通信ボトルネック

　インフラシステム全体のネットワーク構成を見ると、いくつかの大型交換機の配下にコントローラーや基地局が接続され、位置情報は加入者情報と同じサーバーのDBで管理されています。各コンポーネントの中で遅い箇所が推測できます。

リアルタイム処理のワーストケース実行時間

　リアルタイムシステムでは、実行時間の最悪値を勘案してシステムを設計します。

　FA制御システムなどは、動作が制限された時間内に終了しなければ、システムとして成立しない用途もあります。

　自動車のブレーキを踏んで、要求時間内に作動し、制動距離が許容範囲内になければ、ABSはシステムとして成立しません。

　通信装置もリアルタイム応答性が求められ、そのように設計、製造されています。

　データが通信機器に入力され、内部で処理されて出力されるまでの時間をスループットタイムと言います。

　通信速度、何G b/sという表現がありますが、これは装置への入力部分や出力部分の速度を言います。

　これとは別の装置にデータが入って、装置からデータが出ていくまでの時間がスループットタイムです。

並列処理とパイプライン

　下図は処理方式の違いを示しています。

クロック    t0  t1  t2  t3
         +---+---+---+---+------+
入力      |   |   |   |   |
         +---+---+---+---+------+
デコード       |   |   |   |
             +---+---+---+------+
実行              |   |   |                         
                 +---+---+-----+
出力                  |   |
                     +---+-----+

クロック　t0  t1  t2  t3  t4
       +---+---+---+---+---+---+---+
       |   |   |   |   |   |   |   
       +---+---+---+---+---+---+---+
      入力　　　　実行
　　　　　　デコード　出力

上の処理方式ではI/Oと処理ユニットが並列に処理されて、１クロックで実行されます。

下の例はシーケンシャルな処理方式で、入力、デコード、実行、出力が順番に処理されます。

命令が２０個連続したした場合、上の例では 20+4＝24クロック後に出力結果が得られますが、したの例では20x4 = 80クロック後でなければ出力結果は得られません。

シーケンシャルな処理は、各ユニットが並列に処理されないため、遅くなります。

DBのアクセス速度

　DBのアクセスはインタープリタ経由のシーケンシャル処理です。

　シーケンシャルな処理とというのは、手続きを順序に従って進める処理です。従って、一つの命令を出すと、その命令の処理が終了するまで、次の命令を処理することができません。

　同期型の処理と言えます。

　一方で、非同期な処理手続きであれば、一つの命令の処理が終了する前であっても、次の命令を受け付けることができます。命令が連続して大量にある時は、非同期の処理方式の方が向いてます。

　DBへはSQLなどのインタープリタを経由して、ストレージにアクセスします。クエリと呼ばれる文をマシンに解る言葉の翻訳する手続きが入ります。

　直接、マシンに近い形の記憶形式、例えばcsv形式などはマシンから見て、どこにデータがあるかわかりやすいデータ形式です。

　そのため、csv形式の記録ファイルとDB形式で同じディスク上に記録されている同じ内容のデータを用いて、ひとつづつデータを読み込んで同じ処理を実行した場合、全体の処理速度に１０の２乗位の単位の差が発生します。これはDBがインタープリタを経由してアクセスする方式のためです。インタープリタにより人間に分かりやすい形式の命令をマシンの処理に翻訳する手間が発生します。

　SQLで人間に近い形式の命令でデータを取得する場合、命令をデコードして計算内容を実行させます。コマンド入力と同様にプログラムを実行して、データを取得することになります。従って処理はシーケンシャルとなり、一つの命令を出して応答が戻るまで次の命令を出すことができません。

　ひとつづつ順番に処理することになります。

+-----+-----+-----+
|命令１|命令２｜命令3|
+-----+-----+-----+

　DBが一つのクエリの処理に要する時間は、コマンドを打てば結果とともに表示されるため、応答速度が分かります。ハードウエアの処理系によりますが標準的なPCサーバーでは数ミリ秒です。業務用サーバーはPCサーバーより高速です。しかしこれはサーバーの高速化では対応できない処理の仕組みです。

　交換機の場合は、入力データが出力されるまで、次のデータが入力できないということはありません。入力は連続して処理され、出力も並列して実行されます。内部テーブルなどの一時的なストレージアクセスは、CPUからの決まったアドレスへのメモリアクセスなので、動作クロックの速度で処理されます。

　CPU-メモリ間のインターフェイスに依存しますが、ns(ナノ秒）のオーダーで処理されます。

　交換機は、１０分間の間に加入者が移動した位置情報の更新を捌けますが、DBはその規模のデータ処理をリアルタイムに裁くことができません。これがI/Oボトルネックです。