評価手法に関する研究

(1)

評価手法に関する研究

High Availability and Reliability Evaluation of IP Networks

2008 _年 2 _月

船越裕介

(2)

(3)

序論

1.1 IP ネットワークを取り巻く状況の変化

ベストエフォート系サービスから始まったIPネットワークは，既存系サービスを代替し，既に社会基盤の一部になりつつある．特に，近年では音声通話や専用線サービスのような専用の装置を必要としていた高信頼サービスへの適用が本格化しているが，様々な技術開発により要求条件を満たすことが可能になった．

これらのサービスに対応すべく，単なるルータ網からNGN^*1に代表される分散型アーキテクチャによるサービス統合網への移行が世界各国で進められており，そのための標準化作業も着実に実施されている．上記ネットワークの構想自体は以前からISC^*2 [1]や IETF^*3 [2]などの標準化団体で検討が進められていたが，NGNの本格化に合わせ，現在はITU-T^*4 [3, 4, 5] を中心に議論されている．

従来はサービスごとに異なるネットワークを構築していたが，IP統合網に重畳することで，サービス間のインターワークによる新しいサービスの創出と，機能別に装置が細分化されることで3rdベンダの参入が加速され，装置コストの低減が期待される．しかし，

装置の細分化はサービスを構成する装置数の増加を意味し，ネットワーク全体の信頼性を低下させる危険性を伴う．サービス統合網である以上，ネットワークとしてはより信頼性

*1Next Generation Network

*2International Softswitch Consortium

*3Internet Engineering Task Force

*4International Telecommunication Union-Telecommunication Sector

(8)

の高いサービスに合わせた構築が必要となるが，装置単体のコストが低下してもネットワーク全体のコストが上昇しては適正価格でのサービス提供が困難になることから，このようなIPネットワークには高信頼性の経済的な実現が要求されており，今後もこの傾向は続くと考えられる．

また，ユーザ層の変化やニーズの多様化などに対応するため，IPネットワークにおける設計・開発から導入・運用に至る展開サイクルは短縮化の方向にある．これは開発から導入までの期間短縮に加え，サービス提供開始後の運用段階においても，機能拡充のための設備更改やソフトウェアの更新が頻繁に行われることを意味する．したがって，展開サイクルの短縮化に対応しつつ信頼性を確保あるいは向上することがサービス提供者にとって重要となる．つまり構築前の信頼性設計や各種技術開発と同等以上に，サービス提供開始後の信頼性管理の重要性が増しており，このためにはIPネットワークの信頼性実態を短期間に把握する技術と，得られた結果を迅速に反映する管理法が求められている．

2006年に相次いで発生したNTT東西のひかり電話故障や，2007年5月のNTT東日

本Flet’s網の大規模停止は記憶に新しいが，管理も含めた通信ネットワークの信頼性につ

いて総務省情報通信審議会 [6]で検討が進められており，正に国を挙げての対策及び法令の整備が火急の要件である．

このように，通信ネットワークのIP化が進む一方でそれに伴う問題も顕在化しつつあり，信頼性対策は最重要課題となっている．

1.2 通信ネットワークにおける信頼性の考え方

ここで信頼性の考え方について整理する．信頼性という用語の定義は文献 [7] に詳述されているので割愛するが，特に国内において信頼性と言われる場合の意味は，

Reliability ^{狭義の信頼性} Quality 品質

Security ^安全性

の3つに大別される．本論文の研究対象はこの狭義の信頼性であるため，以後の文中において『信頼性』という場合はこれを指すものとする．更に狭義の信頼性は

(9)

Reliability ^{壊れにくさ}

Maintainability ^{修理しやすさ}

という2つの観点で考えることができる．Reliabilityを表す尺度としては，信頼度，故障率，不稼働率もしくは稼働率などがあり，Maintainability を表す尺度には保全度などがある．これらの尺度は，製造工程における品質管理，及び運用段階での実態値管理という 2つの利用形態がある．一般的な信頼性理論は，製造工程におけるハードウェアの品質管理を想定したものが大半を占め，詳細な研究及びその体系化は完成の域に達しているが，

ソフトウェアについては開発者の個人スキルに負う部分が多いために定量化が難しく，古くから研究の対象にはなっているものの，決定的な評価手法はまだ見つかっていない．IP ネットワークの進展はソフトウェア処理の増加と密接に関連するため，今後の進展が待たれる．

一方，通信分野の運用段階においては不稼働率もしくは稼働率が主流となっている．これらは『測定期間内に所与のサービスが提供できなかった，あるいはできた時間の割合』

と定義され，通信分野への適合性が高いためである．サービスによってはSLA^*5により，

不稼働率もしくは稼働率に応じて料金を返却するなどの補償形態を取るものも存在することからも，通信分野における重要性を伺い知ることができる．また，昨今では “Five-9”

という用語が通信分野で頻繁に聞かれるが，これは稼働率99.999%以上であるという，高信頼化を表すキーワードである．不稼働率と稼働率の間には

不稼働率+稼働率= 1 (1.1)

という関係があることから，どちらの尺度を用いても相互に変換可能であるが，通信サービス提供者としては故障などの理由により適切なサービスを提供できない状態を極力回避することが重要であるため，以後の説明では不稼働率を用いる．

1.3 ^{課題の設定}

1.3.1 ^{課題の抽出}

通信ネットワークの高信頼化は

*5Service Level Agreement

(10)

• ^{高信頼化技術開発}

→理論的にどれだけ信頼性が向上するか

• ^{運用管理技術開発}

→実際にどれだけ信頼性が向上したか

の2点を共に考えることで初めて達成されるものである．以下，それぞれの課題の抽出を行う．

高信頼化技術開発に関して，転送系は各レイヤで要素技術が揃いつつあり，サービス特性やコストを勘案した上で，それらを適宜組み合わせることになる [8]．一方，制御系はクラスタリング^*6やRAID^*7に代表されるように，複数装置を組み合わせて1つのシステムとする高信頼化方式が主流である．しかし，装置あるいはシステム故障をネットワークレベルで救済する高信頼化方式は十分に実現されているとは言えない．

課題1 特に制御系装置はVoIP^*8のSIPサーバ^*9に代表されるようにユーザ収容数の大規模化が進んでおり，故障の際の影響範囲が数十万ユーザに及ぶこともあることから，ネットワークレベルでの高信頼化技術の研究が必要である．

運用管理技術開発に関しては，前述の通り一般的な信頼性理論は主に製造工程を対象としており，通信ネットワークのように母数（装置数やユーザ数など）が常に変動するような運用段階での適用が非常に困難であることを指摘する．その上で，現在用いられている不稼働率定義式は次のような課題がある．

課題2 特定あるいは任意の1ユーザに対応する尺度でしかなく，故障とその影響の大きさ(影響規模)の関係が分からない

課題3 故障による社会的影響の大きさが考慮されていないため，規模，時間が同じ故障が2件発生したとして，それらがいつ発生したかによって報道の有無に違いが生じるが，この理由が説明できない

*6複数のサーバを相互接続し，全体で１台のシステムであるかのように見せる技術

*7Redundant Arrays of Inexpensive Disk：データを複数のハードディスクに分散し，性能と耐障害性の向上を図る技術．利用者からは1つのハードディスクと見える

*8Voice over IP：IPを用いて音声データを送受信する技術．NTTにおいてはひかり電話などのサービスが提供されている

*9Session Initiation Protocolを用いた通信制御を司るサーバ．固定電話網における共通線信号装置に相当する機能を持つ

(11)

課題4 各サービスネットワークに最適な信頼性設計値，あるいは運用目標値の設定への適用が困難であり，どこまで高信頼化すれば良いか，あるいは現状のネットワークの信頼性を測定した際に，その結果の良し悪しが判別できない

つまり，通信ネットワークの信頼性実態はどの程度か，あるいはどこがボトルネックでどのように改善すればよいのか，というマクロな問いに対して，現在の手法では明確に答えることができない．

次節においてこれら課題の背景を詳述する．

1.3.2 ^{課題の背景} (1) 高信頼化技術の動向とその問題点

まず課題1の高信頼化技術について述べる．IPネットワークの高信頼化には，装置レベルとネットワークレベルの 2つのアプローチによる高信頼化がある．装置レベルでは，

まず部品レベルの高信頼化を行うのが正論ではあるが，適正コストでの製品の提供という観点から過度な高信頼化は行えない．そこで，故障などによるサービス停止時間を短縮し，ユーザへの影響を極力少なくするという方向に進んでいる．更にサービス停止時間は

• ^{故障修理時間の短縮化}

• ^{保守時間の短縮化}

という2つの考え方があり，修理時間短縮に対しては故障検出の高速化，プロセッサ切替の高速化，更に隣接ノードへの影響の極小化という3つのアプローチが行われている．保守時間短縮は主にソフトウェア更新の短時間化を図っている．本来，保守時間には定期保守によるハードウェア交換も含まれるが，これは各サービス提供者の保守要員の練度に依存し，開発側の技術的問題ではないため，今回の分類には含まない．

転送系装置においてはネットワークレベルの高信頼化技術開発も進んでおり，各レイヤごとに様々な技術が存在する．これらは主にルータや伝送路（パス）の冗長構成および負荷分散を基本としている．図 1.1は主要な転送系装置のネットワークレベルの高信頼化技術について，レイヤと切替時間の関係を示したものである．図の縦軸がレイヤ，横軸が切替時間に対応し，上に行くほど高位レイヤ，右に行くほど切替が短時間な技術であることを示す．各技術はレイヤと切替時間が対応する位置にブロック状の矢印としてマッピングしているが，矢印の右端は最短の切替時間に位置し，左端はネットワークアーキテクチャ

(12)

Rerouting

　 Path Protection　　　　　　　　

Time for switchover

Over a minute Several seconds A second Milliseconds IP

MPLS

Ether

Optics Layer 0/1

Layer 3

　　　　　　　　　　　　 Load Balancing

　　　　　　　 Backup LSP Fast Reroute

　 Link Protection Segment Recovery

Divert to another optical path (same as Fast Reroute) Divert to another optical path

(with software process)

Rapid STP

Divert to another LSP Switchover to

the Backup path

　 UPSR/BLSR

Path multiplexing with wavelength GMPLS

SONET/SDH Link Aggregation

Link Aggregation

Bi-directional Forwarding Detection

　　　　Load balancing （ECMP,etc.） Configure the cost of all paths

Spanning Tree Protocol

Reroute the shortest path

Fast Hello protocol (Combined with others)

Bi-directional

transmission Fold at the outage node

ECMP: Equal Cost Multi Path UPSR: Unidirectional Path Switched Ring BLSR: Bidirectional Line Switched Ring

Influ ence to anot her serv ice Lower

Higher Bundle the

interfaces

Switchover

図1.1 ネットワークレベルの高信頼化技術

の複雑さが増す，あるいはネットワークが大規模化するといった条件に依存して決まる．

つまり矢印の長さが短いものはこのような条件に対する依存性は低いが，長いものは依存性が高いことを表す．一般的に，レイヤが上がるほどソフトウェア処理の比重が高まるため，サービス停止時間が長時間化する傾向にある．本図においては低位レイヤの技術ほど右側に，高位レイヤの技術になるにつれてより左側に矢印が位置することになる．

一方，サーバなどの制御系装置は，ネットワークレベルでの高信頼化技術開発，および商用ネットワークへの適用例は非常に少ない．その中でも唯一マルチホーミングと呼ばれる技術が一部のサーバで用いられてはいるが，汎用的な方法とは言えない．マルチホーミングとは，一般的には同時に複数の通信路を確保することを指すが，サーバに関してはネットワーク的な冗長化に対応し，以後の説明ではこの意味で用いる．サーバのマルチホーミングは，DNS^*10のように時刻によりデータの中身が変化しないサーバでは利用されているが，通信ネットワークの制御系装置は中身が変化する可能性のあるデータを扱うものが多く，それらの装置では用いられていない．例えばVoIPサービスを提供するSIP サーバへの適用を考えると，従量制課金を行うために複数SIPサーバ間でリアルタイム同期を行わねばらず，更にすべての端末も含めたネットワーク全体がサーバ故障時の切替

*10Domain Name Server

(13)

に対応しなければならないことから，単にサーバへの機能追加だけで解決することができない．なお，固定電話網の加入者交換機においてもマルチホーミングは実現されていないが，加入者交換機単体の高信頼化機能は十分に具備されており，固定電話網では収容規模を極力小さくし，その分加入者交換機を大量に配備するという方法を採っている．

分散型ネットワークアーキテクチャは以前からMSF^*11 でも議論されていたが，本アーキテクチャでは機能の細分化による大規模集約が進むため，制御系装置の収容ユーザ数は加入者交換機と比較して大幅に増加することが考えられる．したがって，課金データや通話記録のように，時刻によって中身が変化し得るデータを扱う制御系装置においても，マルチホーミングの実現に向けた基礎検討を行わなければならないが，NGNも含めてこのような研究事例はない．

1.3.3 ^{課題の背景} (2) 運用管理技術の問題点

課題2〜4は密接に関連しているため，本節でまとめる．

1.3.3.1 不稼働率と故障影響規模の関係

まず課題2について述べる．

1.2 節でも述べたように，通信ネットワークの信頼性を測る尺度として不稼働率が用いられている．しかし現在利用されている不稼働率定義式は，特定，あるいは任意の1ユーザが体感するものでしかなく，不稼働率と影響規模の関係が判らない．ここで，任意の 1 ユーザとはネットワークに属する平均的な1ユーザという意味で用いる．一人一人のユーザからみた場合には現在の定義式でも十分であるが，一般的に通信ネットワークは影響規模の大きい故障ほど起りにくくするという思想に基づいて構築されるため，サービス提供者としては不稼働率を考える際には同時に影響規模も考慮しなければならない．

不稼働率と影響規模の関係に着目した先行研究には文献[9]があり，影響規模に応じた通信ネットワークの信頼性設計法について示している．しかしこれは設計段階での議論であり，実際の故障データから不稼働率実態値を同様の方法で求める場合には，計算量がネットワークに属する総ユーザ数に比例する．また，特定種別の装置に収容されるユーザ

*11Multi-service Switching Forum

(14)

数は配備される地域ごとに異なるが，その平均を求めなければならないことから，分析精度が低下する危険性がある．更に市販品によって構成される IPネットワークでは，装置の信頼性カタログ値と実態値が乖離する場合があり，設計段階で想定したネットワークの信頼性が実態として満足できるとは限らないため，常にネットワークの実力を把握しておかねばならない．

しかし不稼働率と影響規模の実態を把握する方法はこれまで提案されておらず，従来の不稼働率算出式でのみ信頼性を測定するに留まっていることから，本問題に対応する信頼性測定方法の確立が急務である．

1.3.3.2 ^{社会的影響の定量化}

次に課題3について述べる．

通信も含む社会基盤系サービスは，故障による社会的影響が大きく，場合によっては報道の対象となることがある．したがって社会的影響をできるだけ小さくするような通信ネットワークの構築と運用を行わねばならない．

しかし社会的影響は明確な尺度がなく，その定量化に対する重要性は認識されてはいるものの，これまで十分に検討されてきたとは言いがたい．故障影響規模の大きい故障ほど起りにくくする考え方は前節で言及したが，これは能條の提案した社会的迷惑量 [10]L(x)

（x：影響規模）という抽象的概念に基づいている．文献 [10]では思考実験から

L(x)∝x^1.5 (1.2)

という結果を導出し，装置の収容ユーザ数がk倍になれば，不稼働率は従来比で1/√ k倍とすべきであるという関係を示している．ただし L(x)は実際の故障データに裏付けられるものではなく，かつ時刻変動性もないという暗黙の仮定を置いている．通信サービスの性質上，ユーザが望むときにはいつでも通信可能であるべきという観点で，この考え方は正しいが，実際は昼間と深夜で全く同じ保守体制を取ることはなく，現実と一致していないことになる．

一方，社会的影響の定量化に向けた案は文献 [11]にも述べられており，比較検討の結果，社会的影響に時刻変動性はないとする上記の仮定を正当化している．しかしこれは実データによる評価に基づいた結論ではないことから，社会的影響の定量評価とその統計的な分析を実施しなければならない．

(15)

1.3.3.3 設計・運用目標値の設定最後に課題4について述べる．

通常の通信ネットワークにおける信頼性設計では，文献 [9, 10]に示す方法で不稼働率目標値を設定し，装置ごとの故障率カタログ値がこれを下回るように構築しているが，冒頭に述べたように展開サイクルの早いIP網では，以下の理由から従来方法を信頼性管理に適用することは困難である．

• 不稼働率目標値は規定した時点での尺度であり，これを絶対視することなく適切さを随時見直す必要があるが，IP網ではその頻度が高まることになる．これにより，

通信ネットワーク構築の上流工程である設計フローが頻繁に変更されるため，対応する稼動が膨大になる

• IP系装置は信頼性予測値と実態値が乖離することがあり，設計段階で適切でも実態値が妥当であるとは限らない．したがって実態値管理とその結果をフィードバックするスキームの確立が必要であるが，設計段階と同様の方法を用いて実態値を求めると，計算量が総ユーザ数に依存して増加し，かつ十分な精度が確保できない危険性がある．

これらに加え，次のような問題もある．

• 信頼性設計の根幹を成してきた社会的迷惑量L(x)は実データによる検証が行われてないため，課題3において定量評価を行うが，もしL(x)が従来と異なる結果になった場合には，L(x)を利用する不稼働率目標値の考え方自体の再評価も行う必要がある

展開サイクルの短縮化に対応するには，従来と発想を逆転し，まず社会的影響を考慮した信頼性実態値分析を行い，その結果から測定期間内における最適な信頼性管理目標値を解析的に導出する方法を考えねばならない．また，このように社会的影響を定量化した上で動的に管理目標値を与える方法も，過去検討された例がない．設計ないし運用目標関数を定めるという観点では文献 [12]が多少の類似性を有するが，文献 [10]と同様に時刻変動性を仮定していないことと，目標関数が米国の固定電話サービスに特化しているため，

(16)

他サービスへの拡張性が乏しい．

1.4 ^{本論文の構成}

以上の課題およびその背景から，本論文を以下のように構成する．

まず第2章では課題1の制御系装置に対するマルチホーミングの適用可能性について論じる．特にNGNでも重要となるVoIPサービスを想定し，既存固定電話網とのインターワークを考慮した制御系装置 MGC^*12のマルチホーミングの実現方式を検討する．その際にはマルチホーミングによる信頼性向上効果を定量評価するとともに，その具体的な実現シーケンスを明らかにする [13, 14, 15, 16, 17]．通常の高信頼化技術提案では，その効果を理論値で定量評価するに留まる場合が多いが，本章では実現に向けた課題を詳細化し，それぞれに対する解決策も含めた具体的なシーケンスの検討も実施する．特にVoIP サービスの場合は既存電話網の巻き取りも含めたインターワークが必須であり，既に技術が確立され，かつ安定した運用実績を持つ既存電話網への影響を最小限に抑えることが求められる．なお，本章では検討当時の背景から装置間の連携にMGCP^*13を仮定しているが，提案した方式はプロトコルに依存しないことから，SIPを用いるNGN においても適用可能であることを付記する．

以降の章では課題2〜4について順に論じるが，これらはすべて保守部門の現場で利用されることを想定し，可能な限り簡易に分析が行えることを付帯条件とする．

第3章では，はじめに故障とサービス停止との関係をモデル化し，本モデルから一般的な不稼働率式を導出する．次にこの考え方に影響規模の概念を取り入れ，不稼働率と故障影響規模の関係を簡易に推定する方法 [18, 19, 20, 21] （以下，規模別不稼働率実態推定式と表す）を提案する．また，

• 従来の信頼性設計方法と比較した計算量比較

• 提案方法の推定精度の検証

• 実用化に向けた詳細課題の考察

*12Media Gateway Controller: NGNにおけるSIPサーバに相当する

*13Media Gateway Control Protocol

(17)

も行い，提案方法の効果を示す．特に推定精度に関しては，MTBF^*14の区間推定を応用し，その推定幅を縮める方法についても合わせて検討する．

第4章では故障による影響規模とその際のユーザからの申告件数に対して通信トラヒックの日内変動を利用した重み付き影響規模x_w と重み付き申告件数y_w という新しい尺度を導入し，故障による社会的影響の定量化を行う．これにより，まず提案方法の有効性を検証するため，報道有無の判別を行う．次に，y_w が社会的迷惑量L(x)の具体例であると考え，統計解析を通じて両者の等質性について論じる [22, 23, 24]．なお，重み付き影響規模と重み付き申告件数はこれまでにない尺度であることから，その妥当性についても考察する．

第5章では，大きく3つの観点から検討を進める．はじめに第3章で提案した規模別不稼働率実態推定式に第4章で論じた社会的影響を表す重みを組み込み，故障による社会的影響を考慮した規模別不稼働率実態推定式（以下，重み付き規模別不稼働率実態推定式と表す）を提案する．次に，社会的迷惑量を実データ分析結果から再評価し，最初に求めた重み付き規模別不稼働率実態推定式に対して最適な信頼性管理目標値を解析的に求め，

比較を通じて測定期間における信頼性バランスの良し悪しを見極める方法 [25, 26]を提案する．重み付き規模別不稼働率実態推定式と信頼性管理目標値は密接に関連しているため，対にして考えるべきものである．最後にこれらの結果から，管理目標値に対して実態値をどのように近づけるか，つまり信頼性管理をどのように行うべきかについて論じる．

これにより，現実に即した信頼性実態把握を行うと同時に，適切な管理目標を導出することで，運用中のネットワークの継続的な信頼性管理，あるいは次期ネットワークの構築に対する指針が実際の故障データから直接的に得られる．

第3章から第5章では，いずれも実際の故障データを用いた解析例を示すことで，提案方法の有効性検証を行う．

*14Mean Time Between Failure：平均故障間隔

(18)

(19)

第 2 ^章

制御系装置の高信頼化方式

2.1 ^まえがき

MSFやISC などの標準化組織にて仕様化が推進された次世代分散型ネットワークは，

現在ではNGNとして発展し，ITU-Tを主要な検討の場に移している．NGNは，QoS 制御可能な広帯域転送技術によるサービス・転送機能を分離したIPネットワークであり，

アクセス制御・モビリティ・ユビキタス性を有する．特にサービスと転送機能の分離により，それぞれの機能の独立な発展を保障している．つまり音声やデータ，動画などあるゆる種類の情報を，IPパケットという統一のメディアに変換し，共通のバックボーンに流すことにより，個別のネットワーク構築に比べ大群化効果による効率的な運用を実現しつつ，サービス毎の独自な開発が可能となる．例えば，既存の音声サービスなどの膨大なソフトウェアは継承しつつ，音声—IPパケット変換処理部を最新化する，あるいは異種サービスの融合処理を容易に構築することなどが期待できる．

NGNも含めた次世代分散型ネットワークは，全サービスに共用されるIPパケット型通信機能を提供するコアノード^*1，各サービスの伝送物理媒体をパケット型のベアラに変換するメディアゲートウェイ^*2，及びMGを制御してサービスや呼処理を実行するメディアゲートウェイコントローラ^*3の各要素から構成される．従来の固定電話交換機ではこれらの機能が一体となっていたが，各機能ごとに装置そのものを分離させることで，上記の

*1Core Node：CN

*2Media Gateway：MG

*3Media Gateway Controller：MGC

(20)

ような効果を見込んでいる．なお，本研究はMSFの分散型アーキテクチャの検討の中で行ったものであり，MGCは現在のNGNではSIPサーバに対応している．ただし要素としては同じであることから，このまま標記する．また，以後の検討内容はプロトコル依存性がないため，NGNに対する差分もないことを付記する．

しかし，本アーキテクチャは従来単一のシステムで構成されていたサービス・呼処理，

メディア処理（通話路制御），中継処理が分離され，障害処理，再開処理，ネットワーク構成要素が別装置になることで部品数が増加する．またそれら要素間の連携において，これまで装置内で実装されていた部分がネットワークを介するため，従来の一体型アーキテクチャに比べて信頼性が低下する可能性がある．

ルータをベースとした転送系装置（CN・MG）の高信頼化技術は各レイヤごとに様々なものがあり，ネットワークレベルでの救済機能も実用化されている．一方制御系装置

（MGC）はサーバをベースとして開発が行われており，第一章で述べたようにクラスタリング，RAIDなど複数装置を１つのシステムとする高信頼化機能は存在するものの，実用レベルでのネットワーク的な高信頼化機能は限られた分野にしか適用されていない．最終的な実用化判断はコストとの兼ね合いになるが，MGCは収容ユーザ数が数十万以上になることも想定されるため，実現方式検討は必須である．

本章では，次世代アーキテクチャ導入に伴うネットワークの信頼性に着目し，音声系サービスにおける加入者区間のマルチホーミングという，実際のネットワークにおいて適用例のない方式を詳細に検討し，その実現性を論じる．またその信頼性向上効果を従来システムとの対比から定量評価する．

2.2 ^{信頼性評価モデル}

本節では，信頼性評価，すなわち不稼働率算出に必要な各種装置及びネットワークモデルの前提条件について述べる．

2.2.1 ^{評価対象サービス}

本章において想定するサービスは，各通信サービス提供者で準備が進められている VoIPとする．ここでは既存電話サービスとのインターワークを考慮し，片側区間は既存

(21)

電話の長距離中継を行うケースを想定する．このため，目標とする信頼性は既存電話と同等並と仮定する．なお既存電話サービスへの影響を最小限に留めることを重視し，IP網内に閉じる呼は評価の対象外とする．

更に既存電話サービスにおけるフリーダイヤルなどの高度サービスについてはSCP^*4の使用を前提とするが，IP端末の種別，あるいは使用する呼制御プロトコルにより，既存電話における高度サービスのすべてが VoIPにおいても受けられるとは限らない．そこで，

本章では固定電話サービスの基本的な通話を評価対象とする．

2.2.2 ^{ノードの評価モデル}

便宜上，MGC，MG，CNの3装置をノードと分類する．これら装置の評価モデルについて図 2.1〜2.3 に示す．前述の通り，既存電話サービスと同等の信頼性を確保することを目標としており，2.3 節において既存の一体型装置との比較を行うため，従来の交換システムと同様に内部2重化構成を取ると仮定する．各ノードを制御するソフトウェアの信頼性を予測することは非常に困難であり，かつ実際の故障では原因の切り分けができない場合が多いことから，問題の簡単化のためハードウェアの不稼働率を評価する．

Processor Signaling

IF Signal

Processing Clock

Cross Connect

Hub

図2.1 MGCの装置モデル

*4Service Control Point

(22)

PSTN-IF CoreNW-IF Switch

&

Processor

… …

図2.2 MGの装置モデル

MG-IF CoreNW-IF

Switch

&

Processor

… …

図2.3 CNの装置モデル

MGC は複数MG を制御するため，マルチプロセッサ構成を前提とするが，呼処理単位は各プロセッサに閉じており，プロセッサ部の故障は他プロセッサ部の呼処理へ影響しないと仮定する．更に既存電話網との接続にはIPアドレスと電話番号を変換するゲートキーパー^*5機能が必要だが，本機能はMGCに具備されると仮定する．

次に各ノードの不稼働率算出について述べる．基本的にノードを構成する部品レベルの不稼働率を算出し，故障パターンの組合せを考慮した上で不稼働率を積み上げ，システム不稼働率を求める．不稼働率算出に必要なデータとその計算方法を表 2.1〜2.4に示す．

MGとCNは，各部品が2重化され，かつ系交絡しているため，MGCのように故障の組

*5Gate Keeper：GK

(23)

合せパターンを考慮する必要はない．このとき，各ノードのシステム不稼働率（これらをそれぞれ U_MGC，U_MG，U_CN とおく）は式 (2.1)で表される．

表2.1 MGCの装置不稼働率

ﬁt数故障率故障時間不稼働率 Processor(Proc.) a1 a1(※1) b1 S1(※2)

Cross Connect(XC) a2 a2 b2 S2

Clock a3 a3 b3 S3

Signal Processing a4 a4 b4 S4

Signal IF a₅ a5 b5 S5

（※1）ai= 10⁻⁹a_i

（※2）Si =aibi

表2.2 MGCのシステム不稼働率

不稼働率冗長数組合せ数不稼働率 Proc. S1 r1 p1 U1(※1)

XC S2 r2 p2 U2

Clock S3 r3 p3 U3

Sig. Proc. S4 r4 p4 U4

Sig. IF S5 r5 p5 U5

XC+Proc. − − p6 U6(※2)

XC+Clock − − p7 U7

XC+Sig.IF − − p8 U8

XC+Sig.Proc. − − p9 U9

Clock+Sig.Proc. − − p10 U10

（※1）Ui=S_i^rⁱpi (1≤i≤5)

（※2）Ui=SjSkpi (6≤i≤10,1≤j, k≤5) Sj,Sk は関連装置不稼働率．

(24)

表2.3 MGのシステム不稼働率

ﬁt数故障率故障時間冗長数不稼働率 SW＆Proc. a1 a1 b1 r1 U1(※) PSTN IF a2 a2 b2 r2 U2

CoreNW IF a3 a3 b3 r3 U3

(※)Ui= (aibi)^rⁱ

表2.4 CNのシステム不稼働率

ﬁt数故障率故障時間冗長数不稼働率 SW＆Proc. a1 a1 b1 r1 U1(※)

MG IF a2 a2 b2 r2 U2

CoreNW IF a3 a3 b3 r3 U3

(※)Ui= (aibi)^rⁱ

U_MGC =

1≤i≤10

U_i （表 2.2参照）

U_MG =

1≤i≤3

U_i （表 2.3参照） (2.1)

U_CN =

1≤i≤3

U_i （表 2.4参照）

2.2.3 分散型ネットワークの評価モデル

本節では次世代分散型ネットワークの配備モデル及びシステム要件について示す．

2.2.1 節のサービス要求条件から，図 2.4に示されるネットワークを想定する．MGC間の

通信媒体に関して制限はないが，既存資産の有効活用及び固定電話網とのインターワークを考慮し，共通線信号網^*6の使用を前提とする．

MG–MGC間の呼処理信号網は主情報網（MG，CN網）に重畳せず，別網での構築を

想定しているが，重畳する場合には以下の課題が発生することによる．

*6Signaling System No.7：SS7．信号中継局（Signaling Transfer Point：STP）と信号終端局（Signaling End Point：SEP）により構成される

(25)

• 主情報伝送路の故障により，話中呼の切断処理が行えない場合がある．

• MG–MGC間で経由するCN，MG（エッジノード）の段数により不稼働率の値が

変動する．

• 主情報と重畳するためには，MG–MGC間通信用に優先制御を行わねばならず，信頼性評価モデルが複雑化する．

• 信号網と主情報網の重畳については，サービス性も含めた広範な検討を要する．

Telephony Switch

MG PSTN/

ISDN

SS7 MGC

MG (Edge)

MG

MGC

STP#1 STP

#2 STP#3

CN ^CN

Core-NW

図2.4 次世代分散型ネットワークモデル

分散型アーキテクチャの場合，MGC，MG，CNのうちどれか１装置でも故障すると，

MG配下に収容されている加入者は通話不能となる．つまり従来の一体型アーキテクチャでは1ノードの故障に相当する範囲が，分散型アーキテクチャではネットワーク全体に及ぶことから，MGC，MG，CNに関するネットワークレベルの不稼働率を求める必要がある. 不稼働率の算出範囲は故障によりユーザに影響するすべての範囲（図 2.4の太線で囲んだ部分）とし，保守運用関連装置^*7は評価の対象外とする．このとき，ネットワークレベルの不稼働率 U_NW は，MGC，MG，CN のシステム不稼働率をそれぞれ U_MGC， U_MG，U_CN，MG–MGC間信号路不稼働率をU_f₁，MG–CN間伝送路不稼働率をU_f₂ と

*7Operation System：OpS

(26)

すると次式で表される．

U_NW =U_MGC +U_MG+U_CN +U_f₁ +U_f₂ (2.2)

伝送路不稼働率の算出方法は表2.1〜2.4と同様である．しかし伝送路の故障率はその距離に比例するため，単位距離当りの故障率を a，平均故障時間を b，伝送路長を l，冗長数を r とすると，不稼働率は次式で表される．

U_f = (abl)^r (2.3)

2.3 ^{マルチホーミング}

分散型アーキテクチャは，部品・装置数の増加から，一体型ノードと比較して明らかに不稼働率が上昇する．また MGC の加入者収容規模は数十万以上と想定されるため，

MGCが内部冗長構成を取ったとしても故障時の影響が甚大になることが考えられる．そこで本節ではネットワークレベルの信頼性向上対策として，加入者区間におけるMGCのマルチホーミングを提案し，信頼性向上効果を示す．

2.3.1 ^{方式の概略}

分散型アーキテクチャの効果を生かすため，MGCは複数MGを束ねる構成を取る．この場合，MGCの収容規模が従来の交換システムを大幅に上回ることになり，地震，火災などの激甚災害時にユーザに及ぼす影響が大きい．例えば，MGC設置局舎に火災が発生した場合，そのMGC に帰属している全MG配下のユーザは，ユーザ自身が収容されているMGが正常動作しているにも関わらず，MGCが復旧するまで通信不可になる．

マルチホーミングとは，隣接MGCが代替手段として該当 MGを収容し，通常であれば通信不可となる場合にもサービスを提供可能とする方式である．従来の固定電話網では，中継区間は多ルート化により本方式は既に実現されているが，加入者区間においては以下の理由から実現されていない．

• 電話交換機が一体型アーキテクチャのため，呼処理機能部分のみのネットワーク冗長化が図れず，宅内の電話端末から2台の加入者交換機に対して回線を引く必要がある

(27)

Core-NW

Telephony Switch

MG PSTN/

ISDN

SS7

#2（GK)MGC

#1（GK)MGC

MG (Edge)

MG

MGC

STP#1 STP

#2 STP#3

図2.5 マルチホーミング

• マルチホーミングに対応する複数の交換機間において従量制課金を行うためのデータをリアルタイム同期しなければならない

• すべての端末も含めたネットワーク全体が，故障時の切り替えに対応しなければならないことから，加入者系交換機への機能追加だけで解決きない

なお加入者交換機単体の高信頼化機能は十分に具備されており，固定電話網では収容規模を極力小さくし，加入者交換機を大量に配備するという方法を採っている．

分散型アーキテクチャでは呼処理機能部分，すなわちMGCのみの増設が可能なため，

一体型アーキテクチャと比べ本方式の実現可能性は高く，コスト面からも必要な機能のみの増設で済むことから，有効性が期待できる．本方式を図 2.5に示す．ここではMGが帰属する MGCを2台としているが，理論的には 3台以上の構成も可能である．ただし 3 台以上になる場合には排他制御処理が複雑化するため，以後の説明では問題の単純化のため2台として検討を行う．

マルチホーミングの処理は以下の手順になる．

1. MGC#1配下のMGはMGC#2にも回線を結ぶ．ただし通常は MGC#1が管理

を行い，MGはMGC#2からの命令を受け付けない．

2. MGC#1が何らかの理由より故障した場合，MGC#2はMGC#1配下の加入者

(28)

0 0.1 0.2 0.3 0.4

MGC

MG CN

MGC

MG CN MGC

MG CN

MGC

Normal All in one Multihoming

30000 50000 70000 90000

0.05 0.03 0.01

0.12 0.09 0.03

0.23 0.19

0.06

0.37 0.31

0.10

MG CN MGC

MG

Un CN

avail abilit y (mi n/ye ar)

Impr ovem ent b y mult ihomi ng

Fiber

Failure rate par package(Fit)

図2.6 不稼働率の比較

データをアクティベートする．

3. MGC#1配下のMGは，帰属先をMGC#2に変更し，MGC#1，#2以外の隣接

ノードは本来MGC#1向けの呼をMGC#2に振替える．

図 2.6で2.2.2，2.2.3 節で設定した条件で，単純な分散型アーキテクチャ，従来の一体

型アーキテクチャ，マルチホーミングの不稼働率を算出した．装置の部品レベルの故障率は製品によって不稼働率が異なるため，固定電話交換機の部品故障率の上限と下限の平均を考慮し，3万，5万，7万，9万Fitと変動させた．平均故障時間は駆け付け1時間，修理1時間の合計2時間と見積もった．

MG–MGC 接続についてはMGC が複数県に１台平均で配備されると仮定し，MG–

MGC 間の平均距離は 300Kmとした．CN はデータ通信系サービスとも共用するため，

MG と別局舎に配備することを想定し，その平均距離は50Kmで評価した．なおMGと CNは都道府県に1台程度配備され，MG–CN，MG–MGC間は共に伝送路2重化を仮定している．故障率は実測値の平均に重みを加え，危険側の値とし100Fitとする．伝送路

（光ファイバ）の故障率は装置故障率と比較して大きく変動する可能性はほとんどないため，この値で固定する．平均故障時間については，伝送路故障では故障箇所の特定がノー

(29)

ドの部品故障と比較して困難なため，故障切り分け1時間，駆け付け1時間，修理3時間の合計5時間と見積もっている．

一体型アーキテクチャの不稼働率は，機能的に MGCにMG，CN のスイッチ部と各 IFが装備されたものと同等であることから，これら機能の不稼働率を合算して算出した．

単純な分散型アーキテクチャの不稼働率は式 (2.2) により求めているが，マルチホーミングの不稼働率はMGCの2重化により以下のように故障パターンが異なり，そのときの不稼働率はMGC，MG–MGC間伝送路故障率をそれぞれ F_MGC，F_f₁，平均故障時間を hとすると次式で表される．

• MGが故障（式 (2.2)と同様）⇒ U_MG

• CNが故障（式 (2.2)と同様）⇒ U_CN

• MG–CN間伝送路が故障（式 (2.2)と同様 ⇒ U_f₂

• MGC#1，#2が共に故障 ⇒ U_MGC²

• MG–MGC間伝送路が共に故障 ⇒ U_f²

1

• MGC#1と，MGC#2側の伝送路が共に故障 ⇒ U_MGCU_f₁

• MGC#1側の伝送路とMGC#2が共に故障 ⇒ U_MGCU_f₁

U =U_MG+U_CN+U_f₂ +

(F_MGC +F_f₁)h2

=U_MG+U_CN+U_f₂ +U_MGC² +U_f²

1 + 2U_MGCU_f₁ (2.4)

MGCは構成部品数増加により不稼働率がMG，MGCと比べて高いが，本方式はMGC 分の不稼働率が現用系，予備系 MGC，伝送路などの不稼働率の和の 2乗（式 (2.4)の {(F_MGC+F_f₁)h}² ）になるため，何も対策を施さない場合と比較して，ほとんど無視可能になっていることが判る．

これに対し図 2.7は故障時間を2倍，すなわちノード故障4時間，伝送路故障10時間とした場合の評価結果である．故障時間が延びることで不稼働率が大幅に上昇しているが，各パターンの比率は図 2.6とほぼ同様の傾向を示している．

ただし実際の不稼働率には，図2.6，2.7の結果に加え，次節で述べる課題を解決した上で，故障発生から発見までの時間と，MGC切り替えの時間を加えて評価する必要がある．

(30)

0.10 0.20.3 0.40.5 0.60.7 0.80.91 1.11.2 1.31.4 1.51.6 1.7

MGC

MG CN

MGC

MG CN MGC

MG CN

MGC

Normal All in one Multihoming

30000 50000 70000 90000

0.25 0.140.09

0.54 0.38 0.17

0.96 0.74

0.29

1.53 1.23

0.46

MG CN MGC

MG

Un CN

avail abilit y (mi n/ye ar)

Impr ovem ent b y mult ihomi ng

Fiber(MG-CN) Fiber(MG-MGC)

Failure rate par package(Fit)

図2.7 不稼働率の比較（その２）

2.3.2 課題の抽出と対策案の検討

マルチホーミングの実現には次の課題がある．

• MGCリソースの確保

• 短時間で故障を発見するトリガ

• ^{隣接装置への影響}

• VoIPユーザへの影響

• ^{加入者データの引継ぎ}

• 呼状態の引継ぎ

以下，これら課題の対策について述べる．なお，MGCのシステムダウンの原因を地震，

火災などによるものとし，既存電話網における故障検出や通常故障の場合の再開処理，

ユーザ呼の整合処理などは分散型アーキテクチャにおいても行われるものとする．更に故障時の課金についても既存電話サービスと同等の処理を行うものとする．マルチホーミングによるMGC変更の際に話中の呼については救済の検討対象とし，発呼，あるいは切断

(31)

処理中の呼については，故障検出が追随できないため本検討の対象外とする．

加えて，以下に述べる各方式案の評価基準は既存電話サービスと同等並であることとするが，各方式案の実際の効果は今後の開発に依存することと，VoIPのサービス要求基準そのものが今後変動し得るため，厳密な定量評価は行わず定性評価に留める．

2.3.2.1 MGCリソースの確保

図 2.5 のように，MGは通常MGC#1に帰属しているものとする．マルチホーミングによって，MGC#1配下の全MGがMGC#2に帰属する場合，MGC#2の最大処理能

力は，MGC#2の元々の担当エリア+MGC#1の担当エリア分必要になる．これは担当

エリアの大きさが同じ場合，MGC#2は通常その処理能力の半分程度しか利用できない．

ここで取るべき対策は以下の2つである．

1. マルチホーミングによって救済する MG 分を見込み，MGCに対する収容制限を行う

2. 全ユーザを救済対象とはしない

収容制限を行う場合，MGC#1 の全 MG を MGC#2 に帰属させる必要はなく，周辺 MGCで分割して帰属させることも考えられる．しかし，分割させるためにはネットワークトポロジーが複雑化し，MGの増設などに合わせたネットワーク設計が困難になる．

全ユーザを救済対象としない場合には，VoIPサービスの中でQoSなどのグレードによる差別化を行い，そのサービス提供条件によって救済対象を選別する．この場合，サービスグレードによってマルチホーミングの有無を判別する仕組みを別途用意する必要がある．なお，全MGが2つのMGC に対して回線を物理的に確保しておくという条件は両者共通である．

サービスの公平性では 1. が，MGC リソースの有効活用という観点では 2. が有効である．

2.3.2.2 短時間で故障を発見するトリガ

電話サービスでは高信頼性及び高リアルタイム性が要求されるため，MGCの故障検出の短縮化が課題となる．通常の装置故障ではノードが自律再開処理を行うため問題はない

(32)

が，激甚災害，特に地震の場合はMGC周辺の伝送路も故障する可能性が高く，MGC故障という状態を判別すること自体が困難であり，MGCに自律切り替え機能を具備させることができない．このようなレベルの障害には OpS側から遠隔で，あるいは現地で手動対処することが考えられるため，MGCに起きた障害レベルを判別する機能が必要になる．

伝送路や信号路故障の場合，OpSにアラームが出るという前提の上で，故障判別を行うための対策として以下の案が考えられる．

1. MGCの故障検出機能をMGに具備する

2. MGCの故障検出機能をOpSに具備する

3. 共通線信号網側で故障を検出する

4. MGC間で正常性を定期的に相互診断する

1. は図2.5 におけるMGC#1の故障を配下のMGが知り得ないため，MG側にMGC

の故障検出機能を具備させる案である．具体的には一定期間毎に MGCに対する正常性確認を行うことになるが，高頻度の確認はMG に対する処理ネックを引き起こす可能性がある．

2. は 1. と同様の機能をOpS側に具備する案である．MGへの機能追加の必要がないが，OpSが全MGCに対して正常性確認を行うため，OpSの処理ネックは1. より大きくなる可能性がある．

3. はSS7において他MGCなどからのIAM信号^*8に対し，MGC#1 を集約している

STP#1が自動的に送出するTFP信号^*9を利用する案である．本案は従来からのSS7の

機能を用いるため，MG，MGC，OpSに対する機能具備が不要になるという利点がある．

しかし本方式には，MGC#1に対して他MGCから発呼しない限り故障を検出できないという問題がある．また本案で発見できるのはMGC の信号装置故障のみであり，TFP 送出の原因がMGCシステム全体の故障であるとは限らない．

4. はMGC#1とMGC#2をSS7と独立した専用回線で結び，相互に正常性を監視す

る案である．MGCに対し本機能の作り込みが必要なことに加え，高頻度の正常性確認は MGCに対する処理ネックの原因になる可能性がある．しかし，連携するMGC間で常に

*8Initial Adderess Meeage：アドレス信号

*9Transfer-prohibited Signal：転送禁止信号

(33)

状態監視することで，原因の早期発見に繋がる可能性が高いと考えられる．

開発・導入コストの観点を考慮すると，大量配備によるコスト効果が得られやすい1.が有効と考えられるが，コストを考慮しない場合，確実な案は 4. になる．

2.3.2.3 ^{隣接装置への影響}

マルチホーミングでは，該当MGC間の切り替えだけでなく，隣接装置への影響も大きい．中でも

• ゲートキーパーの書き換え

• 隣接局のポイントコードの書き換え

が課題となる．ここでポイントコードとは，電話番号からエリアを特定するためのコードであり，市外局番などがこれに相当する．IPアドレスと電話番号の対応テーブルを保持するGKは，マルチホーミングによるMGC 切り替え時にこの対応関係を変更しなければならない．切り替え毎に該当する全データを書き換える場合，変更中のサービス停止時間が問題となる可能性があるため，予めMGC#2 に切り替えた場合のテーブルを追加しておき，必要に応じ該当データを読み出すなどの対策が必要になる．

ポイントコードの書き換えは，本来MGC#1で処理すべき呼をMGC#2に引き込むために必要な処理である．そこで以下の3案が考えられる．

1. STP側でMGC#1向けのポイントコードを変更する

2. 隣接MGC側でMGC#1向けのポイントコードを変更する

3. 通常の呼処理において，MGCとは別のサーバに毎回問い合わせる

1. はSTPでMGC#1，#2のポイントコードを対にして管理し，MGC#1故障時に代替

ポイントコードを用いる案である．本案ではMGC#2以外のSEPがMGC#1の故障を知る必要がない．その反面，既に稼働しているSTPに対する機能追加が必要である．また，安定稼働が絶対条件であるSS7網への機能追加による影響が未知数であることが大きなネックとなる．

2. は元々MGC#1にリンクを持っているSEP，すなわちMGC#2以外のMGC側で

ポイントコードを管理する案である．この場合，関連するMGC はMGC#1 の代替ポ

評価手法に関する研究