はじめに
本ドキュメントでは、携帯電話サービスを提供するためのモバイルパケットコアネットワークにおける代表的な障害事例の一つである輻輳について説明したいと思います。
コントロールプレーンとデータプレーン
モバイルネットワークにおける輻輳を理解するためには、コントロールプレーンとデータプレーンの違いを理解する必要があります。コントロールプレーンとは、ネットワークに接続するために必要な認証、位置情報の登録、IP アドレスや QoS 情報を含むユーザセッションの作成、データ使用量のレポート、など挙げればきりがありませんが、要は携帯端末がモバイルネットワークに接続してデータ通信をするために必要なシグナリングメッセージのやり取りのことを意味します。参考までに、携帯端末がモバイルネットワークに接続するまでの一般的なコールフローは以下のようなものです。
| 名称 | 説明 |
| eNB | evolved Node B |
| MME | Mobility Management Entity |
| HSS | Home Location Register |
| SGW | Serving Gateway |
| PGW | Packet data network Gateway |
| PCRF | Policy and Charging Rules Function |
多くのシグナリングメッセージが異なるノード間でやり取りされていることが分かります。一方データプレーンとは携帯端末でブラウジングしたり音声通話をすることで発生するユーザトラフィックのことで、前述のコントロールプレーンの処理が完了してはじめてデータプレーンのトラフィックが疎通できる状態になります。一般的にモバイルネットワークの輻輳とはコントロールプレーンにおけるシグナリングメッセージの輻輳のことを指します。ユーザトラフィックは単純に次の宛先に転送するだけで良いのに対し、シグナリングメッセージは各ノードでメッセージの中身を処理してレスポンスを返すという動作がになるためより多くのコンピュートリソースを必要とします。モバイルサービスは固定のインターネットサービスに比べてセキュリティの高さであったりきめ細かいサービス内容の提供、位置情報の処理が必要といった観点からコントロールプレーンの処理は必須であり、このような背景から輻輳の問題は切っても切り離せないものであると言えます。
輻輳が発生するメカニズム
モバイルネットワークにおける輻輳とはコントロールプレーンのシグナリングメッセージの輻輳のことであると説明しましたが、一般的にモバイルネットワークは十分なキャパシティや冗長構成で設計されており、通常運用では輻輳による障害は発生しません。輻輳が発生する主な条件とは、ノードやネットワークにおける何らかの問題によって多くのユーザセッションが同時に失われた場合です。その場合、携帯端末はモバイルネットワークに再接続を試みますが、シグナリングメッセージが一時的にバーストする状態になります。最終的に障害に至るかどうかは失われたユーザセッション数やモバイルネットワークのキャパシティに依存しますが、仮にどこかのノードがシグナリングメッセージを処理しきれない状態になりエラー応答になったりタイムアウトが発生した場合、携帯端末やモバイルネットワークの他のノードはリトライあるいは再接続を試みるので、さらに状況が悪化することになり障害が悪化・長期化するということになります。
ここで簡単な実験をしてみます。Cisco VIRL (Virtual Internet Routing Lab) 上に非常に簡単なモバイルパケットコアネットワークを作成してみました。UE/HSS/PCRF はシュミレータを使用していますが、MME/SGW/PGW (CUPS CP/UP) は実際に多くの商用環境で使用されている Cisco StarOS ベースの仮想マシンです。
まず、何も制約がない状態で、1000 ユーザを 50 call/sec で接続します。以下は MME と SGW 間の S11 インターフェースで取得したキャプチャを元にして作成した Create Session Request メッセージのグラフです。問題が無い場合は、約 20 秒で全てのセッションが接続完了しています。
次に PGW と PCRF の間の Gx インターフェースのメッセージレートを 30 に制限してみます。同じテストを実施した結果が以下のグラフです。20 秒では接続が完了せず、継続して Create Session Request が送信されています。また、最初は 50 call/sec であったレートが 100 近くまで増大しています。これは接続が失敗した結果発生するリトライによるものであり、より輻輳が悪化していることが分かります。
輻輳によって障害発生に至るかどうか、あるいはどの程度の障害になるかは複雑なモバイルネットワークにおいて様々な要素に依存しているので一概には言えません。例えばどの程度のユーザセッションが失われたか、携帯端末の再接続時の挙動（端末によって異なることがある）、リトライに関する各種タイマー（EMM の T3402 タイマーや MME/SGW/PGW の GTPC メッセージのタイマー、Gx のタイマーなど ）、ユーザがネットワークに接続できない時にどのような行動を取るか、など考慮すべき部分は多種多様です。
輻輳による障害を防ぐ対策
そもそもユーザセッションの切断が大量に発生するような障害を防げれば良いのですが、原因も様々であり完全に防ぐことは非常に難しいと言えます。
例）
- MME/SGW/PGW などのノードダウン
- SGi 側ネットワークの問題（端末やユーザの挙動により特定の疎通生が失われると再接続する可能性がある）
- オペレーションの自動化ソフトウエアなどの誤作動
それでも対策として考えられることは当然ありますので、以下にいくつか例を挙げて説明します。
Failure Domain を小さくする
モバイルネットワークに限らず障害を完全にゼロにすることは難しいと言えます。ただし、障害が発生した場合の影響範囲をより小さく限定することにより再接続するユーザ数を減らせるので、例えば各種ノードをより分散させるといったアプローチは有効だと考えられます。
製品の冗長化機能によってセッションを失わないようにする
製品に依存する機能になりますが、例えば Cisco の StarOS では ICSR(Interchassis Session Recovery) というセッション情報をシステム間で冗長する仕組みがあるので、これを活用してノード障害発生時にもセッションを失わずにサービスを継続することができます。
一時的に PCRF をバイパスする
すでに説明したとおりモバイルネットワークでは多くのノード間でメッセージがやり取りされています。基本的にほとんどのものは必須ですが、PCRF との間でやり取りされる情報はサブスクライバーのポリシー情報（QoS など）、最悪スキップして PGW で持っているローカルの情報を使ってサービスを継続できる可能性があります（そのかわり最新の最新のサービス内容が反映されない、あるいは VoLTE 音声呼が使用できないといったマイナス面もあります）。Cisco StarOS では Failure Handling Template という機能で輻輳発生時に PCRF をバイパスするといった設定が実現可能です。
Network Overload Protection
モバイルパケットコアにおける輻輳を防ぐために、新規アタッチをレートリミットするという手法もあります。レートリミットが発動されると接続できるユーザ数に制限はかかりますが、輻輳が発生して状況が悪化するよりも最終的には障害の収束時間が短くなることが期待できます。Cisco の MME では Network Overload Protection という機能で新規アタッチレートを制限することが可能です。
先程の VIRL によるシュミレーション環境を使って、実際に Network Overload Protection 機能を実験してみます。テストの条件は以下の通りです。輻輳が発生するようにあえて PCRF が処理できる TPS に制限を設けています。
- 新規アタッチレート： 100
- サブスクライバー数： 1000
- PCRF が処理できる TPS(Transaction per sec): 50
まずは Network Overload Protection を設定していない状態での試験結果です。S11 インターフェースでのパケットキャプチャを元に Create Session Request のレートをグラフにしています。本来であれば 10 秒程度で 1000 セッションが接続完了するはずですが、PCRF 側のボトルネックにより接続できないユーザがリトライを繰り返し、新規アタッチレートは想定を超えて 180 程度まで達し、収束するまで 120 秒以上かかってしまっています。本試験は小さなシュミレーション環境で実施しているため最終的には収束することができていますが、実際の環境では輻輳により例えばどこかのノードでデータベースのエラーなど取り返しのつかない問題が発生し、自動的には収束できずさらに障害を拡大させてしまうといったシナリオも考えられます。
MME のカウンターを見ると、Attach Failure が 9580 カウントされており、再接続が繰り返される分アタッチリクエストが 10580 と多くカウントされています。
Associations by Combined Attach using IMSI:
Attempted: 10580 Success: 0
Success EPS Only: 1000 Failure: 9580
PCRF との接続が失敗した場合 Create Session Response の Reject Cause は No Resource Available になりますので、MME の ESM メッセージでの Insufficient Resource が多くカウントアップしています。
ESM Failure: 9533
Rejected By PGW/SGW: 2095 Authentication Failed: 0
Svc Opt Not Support: 0 Svc Opt Not Subscribed: 0
Unknown APN: 0 Opr Determined Barring: 0
Insufficient Resource: 7438 Activation Rejected: 0
Svc Opt Tmp OutOfOrder: 0 Protocol Errors: 0
APN Restrict Incomt: 0 APN not sup PLMN-RAT: 0
Network Failure: 0
次は MME で以下の Network Overload Protection の設定を投入して同じ実験をしてみます。新規アタッチレートが 50 を超えた場合はドロップするというものです。
network-overload-protection mme-new-connections-per-second 50 action attach drop tau drop fwd-reloc drop
以下が試験結果です。先程とは違い、新規アタッチレートは 50 以下に制限され、収束時間も約 30 秒程度と大幅に短縮されています。
MME のカウンターではエラーはカウントされず、新規アタッチ数も 1000 で不要なリトライは防ぐことができています。
Associations by Combined Attach using IMSI:
Attempted: 1000 Success: 0
Success EPS Only: 1000 Failure: 0
ESM Failure: 0
Rejected By PGW/SGW: 0 Authentication Failed: 0
Svc Opt Not Support: 0 Svc Opt Not Subscribed: 0
Unknown APN: 0 Opr Determined Barring: 0
Insufficient Resource: 0 Activation Rejected: 0
Svc Opt Tmp OutOfOrder: 0 Protocol Errors: 0
APN Restrict Incomt: 0 APN not sup PLMN-RAT: 0
Network Failure: 0
本来であれば 10 秒で完了すると考えれば収束時間は 30 秒と増えていますが、過度な輻輳を防ぎつつできるだけ短い時間で障害を収束させるためには効果的であると考えられます。
結論
簡単なシュミレーションを使ってモバイルパケットコアネットワークにおける輻輳の発生メカニズムやその対策について見てきました。輻輳の原因は様々であり完全に防ぐことは難しいこと、かつ様々なコンポーネントが複雑に関わりあってその後の影響の大きさを左右することが理解できたと思います。対策としてネットワークデザイン面での考慮、あるいは輻輳からネットワークを守るための様々な機能が存在していますが、場合によっては逆効果にもなり得るので、注意深く実際のネットワークの状況を把握して適切な対策を選ぶということが大切だと思います。
