特許第6051871号(P6051871)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士通株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6051871
(24)【登録日】2016年12月9日
(45)【発行日】2016年12月27日
(54)【発明の名称】検出装置、検出システム、及び検出方法
(51)【国際特許分類】
   G08B 29/06 20060101AFI20161219BHJP
   H04L 12/26 20060101ALI20161219BHJP
   H04L 12/70 20130101ALI20161219BHJP
【FI】
   G08B29/06
   H04L12/26
   H04L12/70 100Z
【請求項の数】5
【全頁数】23
(21)【出願番号】特願2013-729(P2013-729)
(22)【出願日】2013年1月7日
(65)【公開番号】特開2014-132426(P2014-132426A)
(43)【公開日】2014年7月17日
【審査請求日】2015年6月4日
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成23年度、総務省、「情報通信ネットワークの耐災害性強化のための研究開発(大規模災害時における移動通信ネットワーク動的通信制御技術の研究開発)」研究開発委託契約に基づく開発項目「柔軟に割当可能な通信処理リソース制御技術に関する研究開発」委託研究、産業技術力強化法第19条の適用を受ける特許出願
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100089118
【弁理士】
【氏名又は名称】酒井 宏明
(72)【発明者】
【氏名】木村 昇一
【審査官】 吉村 伊佐雄
(56)【参考文献】
【文献】 特開2006−074310(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G08B23/00−31/00
H04B7/24−7/26
H04L12/00−12/26
12/50−12/955
H04M3/00
3/08−3/58
7/00−7/16
11/00−11/10
H04Q1/20−1/26
H04W4/00−99/00
(57)【特許請求の範囲】
【請求項1】
監視対象となる複数の装置の状態を示す装置状態情報を取得する取得部と、
前記取得部により取得された装置状態情報に基づき、前記複数の装置の中から、所定の要因で停止した装置を検知した際、該検知結果を用いて、各装置の使用の可否を判定することにより、前記複数の装置の中から、動作可能であるが通信に使用されない対象装置を検出する検出部とを有し、
前記検出部は、前記検知結果を用いて、前記各装置の再利用の可否または変更の可否を判定することにより、前記複数の装置の中から、前記対象装置を検出することを特徴とする検出装置。
【請求項2】
前記検出部は、前記取得部により取得された装置状態情報に基づき、前記複数の装置の中から、所定の要因で停止することが予想される装置を検知した際、該検知結果を用いて、各装置の使用準備の可否を判定することにより、前記複数の装置の中から、前記対象装置となることが予想される装置を検出することを特徴とする請求項1に記載の検出装置。
【請求項3】
前記対象装置は、全ての下位装置が停止した装置、または、上位装置が停止した装置であることを特徴とする請求項1に記載の検出装置。
【請求項4】
検出装置と、該検出装置と通信可能な管理装置とを有する検出システムであって、
前記検出装置は、
監視対象となる複数の装置の状態を示す装置状態情報を取得する取得部と、
前記取得部により取得された装置状態情報に基づき、前記複数の装置の中から、所定の要因で停止した装置を検知した際、該検知結果を用いて、各装置の使用の可否を判定することにより、前記複数の装置の中から、動作可能であるが通信に使用されない対象装置を検出し、該検出結果を前記管理装置に提供する検出部とを有し、
前記検出部は、前記検知結果を用いて、前記各装置の再利用の可否または変更の可否を判定することにより、前記複数の装置の中から、前記対象装置を検出し、
前記管理装置は、
前記検出装置から提供された前記検出結果を通知する通知部を有することを特徴とする検出システム。
【請求項5】
検出装置が、
監視対象となる複数の装置の状態を示す装置状態情報を取得し、
取得された装置状態情報に基づき、前記複数の装置の中から、所定の要因で停止した装置を検知した際、該検知結果を用いて、各装置の使用の可否を判定することにより、前記複数の装置の中から、動作可能であるが通信に使用されない対象装置を検出し、
前記検知結果を用いて、前記各装置の再利用の可否または変更の可否を判定することにより、前記複数の装置の中から、前記対象装置を検出する
ことを特徴とする検出方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、検出装置、検出システム、及び検出方法に関する。
【背景技術】
【0002】
近年、新しい無線通信方式として、LTE(Long Term Evolution)が普及しつつある。LTEを適用可能なネットワークの一種として、監視対象となる複数の装置が論理的な親子関係にあるツリー構造のネットワークが利用されている。この様なネットワークでは、例えば、災害等により、ある親装置配下の全ての子装置が動作不能な状態になると、たとえ親装置が動作可能な状態であっても、該親装置にはトラフィックが流れない状況となる。また、反対に、親装置が動作不能な状態になると、たとえ該親装置配下の子装置の中に動作可能な装置が残っている場合でも、該親装置の全ての子装置にトラフィックが流れない状況となる。その結果、ネットワーク内には、動作可能な状態にあるにも拘らず、トラフィックの流れない親装置や子装置が存在することとなる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2001−312783号公報
【特許文献2】特開2010−157881号公報
【特許文献3】特開平10−229395号公報
【特許文献4】特開2011−66522号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ネットワーク管理者は、ネットワーク管理システム(NMS:Network Management System)や装置管理システム(EMS:Element Management System)を活用することで、上述した様なトラフィックの流れない親装置や子装置を検出する。すなわち、ネットワーク管理者は、ネットワークのトポロジや各装置の状態(正常、故障等)を監視し、これらの情報を総合的に判断することで、動作可能であるにも拘らずトラフィックの流れない親装置や子装置を検出することができる。しかしながら、通常は、親装置または子装置の動作不能状態が長期に渡る(復旧までに時間を要する)か否かを正確に判断することは、困難である。このため、親装置が動作可能な場合に、該親装置を他のリソースとして再利用可能か、あるいは、子装置が動作可能な場合に、従前の親装置を他の親装置に変更可能かの判断をすることはできなかった。
【0005】
開示の技術は、上記に鑑みてなされたものであって、装置の停止要因に応じて、使用可能な装置を容易に特定することのできる検出装置、検出システム、及び検出方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
上述した課題を解決し、目的を達成するために、本願の開示する検出装置は、一つの態様において、取得部と検出部とを有する。前記取得部は、監視対象となる複数の装置の状態を示す装置状態情報を取得する。前記検出部は、前記取得部により取得された装置状態情報に基づき、前記複数の装置の中から、所定の要因で停止した装置を検知した際、該検知結果を用いて、各装置の使用の可否を判定することにより、前記複数の装置の中から、動作可能であるが通信に使用されない対象装置を検出する。
【発明の効果】
【0007】
本願の開示する検出装置の一つの態様によれば、装置の停止要因に応じて、使用可能な装置を容易に特定することができる。
【図面の簡単な説明】
【0008】
図1図1は、浮検出システムの全体構成を示す図である。
図2図2は、浮検出装置の機能構成を示すブロック図である。
図3A図3Aは、災害情報の構成例を示す図である。
図3B図3Bは、親子関係情報の構成例を示す図である。
図4A図4Aは、装置情報の構成例を示す図である。
図4B図4Bは、災害状態情報の構成例を示す図である。
図5図5は、浮検出装置のハードウェア構成を示すブロック図である。
図6図6は、災害情報設定処理を説明するためのフローチャートである。
図7図7は、装置状態収集処理を説明するためのフローチャートである。
図8図8は、親浮装置検出処理を説明するためのフローチャートである。
図9図9は、子浮装置検出処理を説明するためのフローチャートである。
図10A図10Aは、親装置を再利用可能な場合における装置情報格納部内のデータ格納例を示す図である。
図10B図10Bは、親装置を再利用可能な場合における災害情報格納部内のデータ格納例を示す図である。
図11A図11Aは、親装置を再利用可能な場合における親子関係格納部内のデータ格納例を示す図である。
図11B図11Bは、親装置を再利用可能な場合における災害状態格納部内のデータ格納例を示す図である。
図12A図12Aは、親装置の再利用を準備可能な場合における装置情報格納部内のデータ格納例を示す図である。
図12B図12Bは、親装置の再利用を準備可能な場合における災害情報格納部内のデータ格納例を示す図である。
図13A図13Aは、親装置の再利用を準備可能な場合における親子関係格納部内のデータ格納例を示す図である。
図13B図13Bは、親装置の再利用を準備可能な場合における災害状態格納部内のデータ格納例を示す図である。
図14A図14Aは、親装置を変更可能な場合における装置情報格納部内のデータ格納例を示す図である。
図14B図14Bは、親装置を変更可能な場合における災害情報格納部内のデータ格納例を示す図である。
図15A図15Aは、親装置を変更可能な場合における親子関係格納部内のデータ格納例を示す図である。
図15B図15Bは、親装置を変更可能な場合における災害状態格納部内のデータ格納例を示す図である。
図16A図16Aは、親装置の変更を準備可能な場合における装置情報格納部内のデータ格納例を示す図である。
図16B図16Bは、親装置の変更を準備可能な場合における災害情報格納部内のデータ格納例を示す図である。
図17A図17Aは、親装置の変更を準備可能な場合における親子関係格納部内のデータ格納例を示す図である。
図17B図17Bは、親装置の変更を準備可能な場合における災害状態格納部内のデータ格納例を示す図である。
【発明を実施するための形態】
【0009】
以下に、本願の開示する検出装置、検出システム、及び検出方法の実施例を、図面を参照しながら詳細に説明する。なお、以下の実施例により本願の開示する検出装置、検出システム、及び検出方法が限定されるものではない。
【0010】
本願の開示する一実施例に係る浮検出システム1の構成を説明する。図1は、浮検出システム1の全体構成を示す図である。図1に示す様に、浮検出システム1は、浮検出装置10とNMS(Network Management System)20と、S−GW(Serving-GateWay)30とMME(Mobility Management Entity)40とeNodeB50、60とを有する。浮検出システム1では、浮検出装置10とNMS20とが、保守用LAN(Local Area Network)等のネットワークNを介して、相互に各種信号やデータの送受信が可能な様に、S−GW30とMME40とeNodeB50、60とに有線接続されている。S−GW30とMME40とeNodeB50、60との各装置は、浮検出装置10による監視対象の装置であり、論理的な親子関係にあるツリー構造を有する。
【0011】
浮検出装置10は、浮装置を検出した際、上記各装置の故障要因に応じて、再利用や変更の可否を判定する。例えば、親子関係にある複数の装置の内、全ての子装置が故障した場合、その親装置は浮装置となるが、この場合、浮検出装置10は、該浮装置(親装置)の再利用若しくはその準備が可能であることを、保守管理者に通知する。一方、親子関係にある複数の装置の内、親装置が故障した場合、その子装置は浮装置となるが、この場合、浮検出装置10は、該浮装置(子装置)の他の親装置への接続変更(親装置の再設定)若しくはその準備が可能であることを、保守管理者に通知する。
【0012】
ここで、再利用とは、災害故障となった装置の接続先の装置を変更することで、他の装置への流用を図ることである。従って、例えば、親装置を再利用する場合、保守管理者は、従前の子装置との接続を終了し、新たな他の子装置への接続を開始する。また、変更とは、災害故障となった装置を他の装置に切り替えることで、他の装置への交換を図ることである。従って、例えば、親装置を変更する場合、保守管理者は、災害故障した親装置の子装置を、新たな他の親装置の配下に設定変更する。
【0013】
以下の説明において、親子関係とは、ネットワーク上の複数の装置間において、上位装置としての親装置を介して通信を確立する下位装置が存在する場合、上位装置(親装置)とその下位装置(子装置)との関係である。例えば、図1において、MME40とeNodeB50、60との関係は、MME40を親装置、eNodeB50、60を子装置とする親子関係である。これに対し、S−GW30とMME40との関係では、S−GW30は、MME40を子装置とする親装置である。また、浮装置とは、その装置自体の動作は可能であるが、トラフィックの流れない装置である。例えば、全ての子装置が故障となった親装置や、反対に、親装置が故障となった子装置等が、浮装置に該当する。
【0014】
なお、上記故障は、長期故障のみならず、短期故障を含む。長期故障は、復旧に時間の掛かる故障であり、例えば、津波や火災等の災害に起因する故障(以下、「災害故障」と記す。)である。短期故障は、一時的な故障であり、例えば、間欠故障の他、ネットワーク工事や、保守のための再起動等に起因する故障である。
【0015】
図2は、浮検出装置10の機能構成を示すブロック図である。図2に示す様に、浮検出装置10は、災害情報設定部11と災害情報格納部12と親子関係格納部13と装置状態収集部14と装置情報格納部15と浮検出部16と災害状態格納部17とを有する。これら各構成部分は、一方向又は双方向に、信号やデータの入出力が可能な様に接続されている。
【0016】
災害情報設定部11は、外部に設置された保守端末70から災害情報を入力すると、該災害情報を災害情報格納部12に格納させる。災害情報格納部12は、災害情報設定部11から入力された災害情報を格納する。
【0017】
図3Aは、災害情報の構成例を示す図である。図3Aに示す様に、災害情報は、災害発生時刻a1と災害発生エリアa2とを有する。災害発生時刻a1は、災害の発生した日時を示す情報である。災害発生エリアa2は、災害の発生したエリアを示す情報であり、例えば、MME40のカバーする地域として、“東京”、“大阪”等の文字列が設定される。
【0018】
親子関係格納部13は、装置間に定義された親子関係を示す情報を格納する。図3Bは、親子関係情報の構成例を示す図である。図3Bに示す様に、親子関係情報は、親装置の装置IDb1及び装置名b2と、子装置の装置IDb3及び装置名b4とを有する。装置IDb1、b3は、各装置を特定すると共に、親子関係の階層の深さを示すために付与された識別子である。例えば、階層の最上位に位置するS−GW30の装置IDが“1”である場合、その子装置であるMME40の装置IDは“1.1”となり、更にその子装置であるeNodeB50、60の装置IDはそれぞれ、“1.1.1”、“1.1.2”となる。装置名b2、b4は、対応する装置の名称を示す情報であり、例えば、“S−GW30”、“MME40”、“eNodeB50”、“eNodeB60”等の文字列が該当する。
【0019】
装置状態収集部14は、NMS20から収集された監視対象の装置状態情報に、上記装置IDを対応付けた後、該装置IDを基に、各装置状態情報を降順でソートすると共に、ソート後の装置状態情報を装置情報格納部15に格納させる。その後、装置状態収集部14は、降順ソート後の装置状態情報を、1レコードずつ浮検出部16に出力し、浮装置である親装置(以下、「親浮装置」と記す。)の検出を浮検出部16に実行させる。また、装置状態収集部14は、上記装置IDを基に、各装置状態情報を昇順でソートすると共に、ソート後の装置状態情報を装置情報格納部15に格納させる。その後、装置状態収集部14は、昇順ソート後の装置状態情報を、1レコードずつ浮検出部16に出力し、浮装置である子装置(以下、「子浮装置」と記す。)の検出を浮検出部16に実行させる。
【0020】
装置情報格納部15は、装置状態収集部14から入力された上記装置状態情報を「装置情報」として格納する。装置情報は、NMS20の管理する情報の内、監視対象のネットワークN上に配置された各装置の状態に関する情報である。図4Aは、装置情報の構成例を示す図である。図4Aに示す様に、装置情報においては、NMS20から収集された“装置名”、“エリア”、“更新時刻”、“装置状態”、“故障箇所”の各情報が、上述した親子関係格納部13内の装置IDb1、b3(図3B参照)と対応付けられている。
【0021】
装置情報は、図4Aに示す様に、装置IDc1と装置名c2とエリアc3と更新時刻c4と装置状態c5と故障箇所c6とを有する。装置IDc1は、上述した装置IDb1、b3と同様、各装置を特定すると共に、親子関係の階層の深さを示すために付与された識別子である。装置名c2は、上述した装置名b2、b4と同様、対応する装置の名称を示す情報である。エリアc3は、対応する装置の設置箇所の属するエリアを示す情報であり、例えば、“東京”、“大阪”等の文字列が設定される。更新時刻c4は、対応する装置状態c5が最後に変更された日時を示す情報である。装置状態c5は、対応する装置の現在の状態を示す情報であり、例えば、“正常”、“部分故障”、“故障”等の文字列が該当する。故障箇所c6は、対応する装置に故障が発生した場合に、その発生箇所を示す情報であり、例えば、“ファン”、“電源”、“メモリ”、“ディスク”、“CPU(Central Processing Unit)”、“NIC(Network Interface Card)”、“バッテリ”等である。
【0022】
浮検出部16は、装置状態収集部14から、ソート後の装置状態情報が入力されると、1レコード分の装置状態情報(装置情報)と、災害情報と、親子関係情報とに基づき、ネットワークN内の災害状態を特定する。また、浮検出部16は、特定された災害状態を示す情報(以下、「災害状態情報」と記す。)を、災害状態格納部17に出力し、格納させる。具体的には、浮検出部16は、降順ソート後の装置状態情報を用いて、後述する再利用状態及び親装置状態を各装置毎に判定することにより、親浮装置を検出する。次いで、浮検出部16は、上記装置状態情報を昇順にソートし直して、子浮装置を検出する。
【0023】
図4Bは、災害状態情報の構成例を示す図である。図4Bに示す様に、災害状態情報は、装置IDd1と装置名d2とエリアd3と更新時刻d4と災害状態d5と再利用状態d6と親装置状態d7とを有する。装置IDd1は、上述した装置IDb1、b3、c1と同様、各装置を特定すると共に、親子関係の階層の深さを示すために付与された識別子である。装置名d2は、上述した装置名b2、b4、c2と同様、対応する装置の名称を示す情報である。エリアd3は、上述したエリアc3と同様、対応する装置の設置箇所の属するエリアを示す情報である。更新時刻d4は、上述した更新時刻c4と同様、対応する災害状態d5が最後に変更された日時を示す情報である。
【0024】
災害状態d5は、対応する装置が災害に起因してとる状態を示す情報であり、例えば、“正常”、“部分故障”、“バッテリ駆動”、“故障”、“災害故障”等の文字列が該当する。また、再利用状態d6は、対応する装置の再利用の可否に関する情報として、例えば、“使用中”、“子故障”、“子故障予測”等の文字列が設定される。ここで、子故障とは、自装置は動作可能であるが、子装置が全て災害故障となっている親装置の状態を表す。更に、親装置状態d7は、対応する装置の親装置の状態を示す情報であり、例えば、“稼働中”、“親故障”、“親故障予測”等の文字列が該当する。ここで、親故障とは、少なくとも1つの動作可能な子装置を親装置が有し、かつ、該親装置が災害故障となっている子装置の状態を表す。例えば、装置名が“MME40”の場合、MME40を子装置とする親装置はS−GW30であるので、“MME40”の親装置状態d7には、“S−GW30”の状態が設定される。
【0025】
続いて、浮検出装置10のハードウェア構成を説明する。図5は、浮検出装置10のハードウェア構成を示すブロック図である。図5に示す様に、浮検出装置10においては、CPU(Central Processing Unit)10aと、SDRAM(Synchronous Dynamic Random Access Memory)等のメモリ10bと、NIC(Network Interface Card)10cと、HDD(Hard Disk Drive)10dとが、各種信号やデータの入出力が可能な様に接続されている。
【0026】
以下、浮検出装置10の機能的な構成部分と、ハードウェア構成部分との対応関係を説明する。災害情報設定部11と装置状態収集部14と浮検出部16とは、例えば、CPU10a及びメモリ10bにより実現される。また、災害情報格納部12と親子関係格納部13と装置情報格納部15と災害状態格納部17とは、例えば、メモリ10b及びHDD10dにより実現される。更に、浮検出装置10と、NMS20、保守端末70との間の通信は、NIC10cにより実現される。
【0027】
なお、保守端末70は、浮検出装置10から提供された災害状態情報を保守管理者に通知する通知部71を有する。通知部71は、例えば、LCD(Liquid Crystal Display)や有機EL(Electro Luminescence)ディスプレイ等の表示装置により実現されるが、これに加えて、スピーカ等を用いた音声や鳴動による通知を行ってもよい。
【0028】
次に、本実施例における浮検出システム1の動作を説明する。
【0029】
図6は、災害情報設定処理を説明するためのフローチャートである。S1では、浮検出装置10の災害情報設定部11は、保守管理者が保守端末70に入力した災害情報の受信を待機しており、該受信を検知すると、受信された災害情報を災害情報格納部12に出力する。S2では、災害情報格納部12は、災害情報設定部11からの指示に従い、災害情報設定部11から入力された災害情報を格納する。
【0030】
図7は、装置状態収集処理を説明するためのフローチャートである。装置状態収集部14は、NMS20の装置状態格納部21に更新可能に格納されている装置状態情報を収集する(S11)。収集のタイミングは、数分〜数時間(例えば、1時間程度)の間隔で定期的に収集してもよいし、保守管理者等の指示に応じて、任意のタイミングで収集するものとしてもよい。
【0031】
S12では、装置状態収集部14は、親子関係格納部13を参照して、装置状態情報に対する装置IDの対応付けを行う。次に、装置状態収集部14は、後述する親浮装置検出処理の事前処理として、上記装置IDを基に、上記装置状態情報を降順にソートする(S13)。S14では、装置状態収集部14は、ソート後の装置状態情報を、装置情報として、装置情報格納部15に格納させる。
【0032】
次に、装置状態収集部14は、S14で装置情報格納部15に格納された複数のレコード(例えば、4レコード)の内、最上位の1レコード分の装置情報を、浮検出部16への入力用レコードに設定する。そして、装置状態収集部14は、該レコードに属する装置情報に対し、後述する親浮装置検出処理を実行する(S15)。実行後、装置状態収集部14は、装置情報格納部15内に、次のレコードが存在するか否かの判定を行う(S16)。次のレコードが存在する場合(S16;Yes)には、装置状態収集部14は、該レコードに関し、上記S15の処理を再び実行する。以降、親浮装置検出処理は、装置情報格納部15内の全ての装置情報に対して実行され、該実行の完了(S16;No)に伴い、装置状態収集処理は、S17の処理に移行する。
【0033】
S17〜S20では、子浮装置の検出のため、上述したS13〜S16と同様の処理が実行される。具体的には、S17では、装置状態収集部14は、後述する子浮装置検出処理の事前処理として、上記装置IDを基に、上記装置状態情報を昇順にソートする(S17)。S18では、装置状態収集部14は、ソート後の装置状態情報を、装置情報として、装置情報格納部15に格納させる。次に、装置状態収集部14は、S18で装置情報格納部15に格納された複数のレコード(例えば、4レコード)の内、最上位の1レコードに属する装置情報に対し、後述する子浮装置検出処理を実行する(S19)。実行後、装置状態収集部14は、装置情報格納部15内における次レコードの存否を判定し(S20)、次レコードが存在する場合(S20;Yes)には、該レコードに関し、上記S19の処理を再び実行する。そして、装置情報格納部15内の全ての装置情報に対する子浮装置検出処理が完了した時点(S20;No)で、装置状態収集処理は終了する。
【0034】
図8は、親浮装置検出処理を説明するためのフローチャートである。まずS151では、浮検出部16は、災害情報格納部12を参照し、災害情報の有無を確認する。確認の結果、災害情報が有る場合(S151;Yes)には、浮検出部16は、災害が発生したものと判断し、災害情報格納部12内の災害情報と、装置情報格納部15内の装置情報とを比較する(S152)。
【0035】
上記比較の結果、上記災害情報と上記装置情報とが一致する場合(S153;Yes)、例えば、エリアc3と災害発生エリアa2とが一致し、かつ、更新時刻c4が災害発生時刻a1以降である場合、浮検出部16は、上記装置情報に含まれる装置状態c5を判定する(S154)。該判定の結果、装置状態c5が正常である場合(S154;正常)、浮検出部16は、災害状態格納部17における災害状態d5(図4B参照)に“正常”を設定する(S155)。
【0036】
一方、上記S154における判定の結果、装置状態c5が部分故障である場合(S154;部分故障)、浮検出部16は、災害状態格納部17における災害状態d5に“部分故障”を設定する(S156)。併せて、浮検出部16は、上記装置情報に含まれる故障箇所c6が電源の場合、災害状態格納部17における災害状態d5に“バッテリ駆動”を設定する(S157)。ここで、バッテリ駆動とは、災害に起因して装置の電源が故障した結果または停電となった結果、該装置が、充電式電池等の予備用電源により動作している状態である。
【0037】
更に、上記S154における判定の結果、装置状態c5が故障である場合(S154;故障)、浮検出部16は、災害状態格納部17における災害状態d5に“災害故障”を設定する(S158)。
【0038】
なお、上記S151における判定の結果、災害情報が無い場合(S151;No)、あるいは、上記S153における判定の結果、上記災害情報と上記装置情報とが一致しない場合(S153;No)には、S159以降の処理に移行する。S159では、浮検出部16は、災害状態格納部17内の再利用状態d6(図4B参照)を“使用中”に更新すると共に、親装置状態d7(図4B参照)を“稼働中”に更新する。更に、浮検出部16は、上記装置情報に含まれる装置状態c5を、災害状態格納部17内の災害状態d5に設定することで、各装置の現状を、保守管理者に通知される災害状態に反映させる(S160)。
【0039】
上記S155、S157、S158、S160の何れかの処理が終了すると、親浮装置検出処理は、S161の処理に移行する。S161では、浮検出部16は、検出対象の親浮装置の子装置全ての災害状態d5が“災害故障”に設定されているか否かの判定を行う。このとき、浮検出部16は、災害状態d5が“災害故障”以外の装置であっても、災害状態格納部17内の再利用状態d6が“子故障”に設定されている装置であれば、全ての子装置の災害状態d5が“災害故障”に設定されている装置と同様に、“災害故障”として扱う。
【0040】
上記S161における判定の結果、検出対象の親浮装置の子装置全ての災害状態d5が“災害故障”に設定されている場合(S161;Yes)、浮検出部16は、災害状態格納部17における再利用状態d6(図4B参照)に“子故障”を設定する(S162)。そして、一連の親浮装置検出処理を終了する。
【0041】
これに対し、上記S161における判定の結果、検出対象の親浮装置の子装置の内、少なくとも1つの子装置の災害状態d5が“災害故障”に設定されていない場合(S161;No)には、浮検出部16は、更に、S163の判定を行う。すなわち、浮検出部16は、検出対象の親浮装置の子装置全ての災害状態d5が、“災害故障”、“バッテリ駆動”の何れかに設定されているか否かを判定する(S163)。このとき、浮検出部16は、災害状態d5が“災害故障”以外の装置であっても、災害状態格納部17内の再利用状態d6が“子故障”に設定されている装置であれば、“災害故障”として扱う。また、浮検出部16は、災害状態d5が“バッテリ駆動”以外の装置であっても、災害状態格納部17内の再利用状態d6が“子故障予測”に設定されている装置であれば、全ての子装置の災害状態d5が、“災害故障”、“バッテリ駆動”の何れかに設定されている装置と同様に、“バッテリ駆動”として扱う。
【0042】
上記S163における判定の結果、検出対象の親浮装置の子装置全ての災害状態d5が、“災害故障”、“バッテリ駆動”の何れかに設定されている場合(163;Yes)、浮検出部16は、災害状態格納部17における再利用状態d6(図4B参照)に“子故障予測”を設定する(S164)。そして、一連の親浮装置検出処理を終了する。
【0043】
ここで、再利用状態d6の“子故障予測”とは、近い将来、全ての子装置が災害故障となることが予測される親装置の状態である。より具体的には、子故障予測とは、自装置(親装置)自体の動作は可能であるが、全ての子装置が災害故障またはバッテリ駆動の状態にあり、かつ、少なくとも1つの子装置がバッテリ駆動の状態にある場合の親装置の状態である。
【0044】
一方、S163の条件を満たさない場合、換言すれば、検出対象の親浮装置の子装置の内、少なくとも1つの子装置の災害状態d5が、“災害故障”、“バッテリ駆動”の何れにも設定されていない場合(S163;No)には、浮検出部16は、上記S164の処理を省略して、一連の親浮装置検出処理を終了する。
【0045】
図9は、子浮装置検出処理を説明するためのフローチャートである。まずS191では、浮検出部16は、災害情報格納部12を参照し、災害情報の有無を確認する。確認の結果、災害情報が有る場合(S191;Yes)には、浮検出部16は、災害が発生したものと判断し、災害情報格納部12内の災害情報と、装置情報格納部15内の装置情報とを比較する(S192)。
【0046】
上記比較の結果、上記災害情報と上記装置情報とが一致する場合(S193;Yes)、例えば、エリアc3と災害発生エリアa2とが一致し、かつ、更新時刻c4が災害発生時刻a1以降である場合、浮検出部16は、S194以降の処理を実行する。一方、上記S191における判定の結果、災害情報が無い場合(S191;No)、あるいは、上記S193における判定の結果、上記災害情報と上記装置情報とが不一致の場合(S193;No)には、浮検出部16は、S194以降の処理を省略し、子浮装置検出処理を終了する。
【0047】
S194では、浮検出部16は、検出対象の子浮装置の親装置の災害状態d5が“災害故障”に設定されているか否かの判定を行う。このとき、浮検出部16は、災害状態d5が“災害故障”以外の装置であっても、災害状態格納部17内の親装置状態d7が“親故障”に設定されている装置であれば、親装置の災害状態d5が“災害故障”に設定されている装置と同様に、“災害故障”として扱う。
【0048】
上記S194における判定の結果、検出対象の子浮装置の親装置の災害状態d5が“災害故障”に設定されている場合(S194;Yes)、浮検出部16は、災害状態格納部17における親装置状態d7(図4B参照)に“親故障”を設定する(S195)。そして、一連の子浮装置検出処理を終了する。
【0049】
これに対し、上記S194における判定の結果、検出対象の子浮装置の親装置の災害状態d5が“災害故障”に設定されていない場合(S194;No)には、浮検出部16は、更に、S196の判定を行う。すなわち、浮検出部16は、検出対象の子浮装置の親装置の災害状態d5が、“災害故障”、“バッテリ駆動”の何れかに設定されているか否かを判定する(S196)。このとき、浮検出部16は、災害状態d5が“災害故障”以外の装置であっても、災害状態格納部17内の親装置状態d7が“親故障”に設定されている装置であれば、“災害故障”として扱う。また、浮検出部16は、災害状態d5が“バッテリ駆動”以外の装置であっても、災害状態格納部17内の親装置状態d7が“親故障予測”に設定されている装置であれば、親装置の災害状態d5が“バッテリ駆動”に設定されている装置と同様に、“バッテリ駆動”として扱う。
【0050】
上記S196における判定の結果、検出対象の子浮装置の親装置の災害状態d5が、“災害故障”、“バッテリ駆動”の何れかに設定されている場合(196;Yes)、浮検出部16は、災害状態格納部17における親装置状態d7(図4B参照)に“親故障予測”を設定する(S197)。そして、一連の子浮装置検出処理を終了する。
【0051】
これに対し、S196の条件を満たさない場合、換言すれば、検出対象の子浮装置の親装置の災害状態d5が、“災害故障”、“バッテリ駆動”の何れにも設定されていない場合(S196;No)には、浮検出部16は、上記S197の処理を省略して、一連の子浮装置検出処理を終了する。
【0052】
ここで、再利用状態d6の“親故障予測”とは、近い将来、親装置が災害故障となることが予測される子装置の状態である。より具体的には、親故障予測とは、自装置(子装置)自体の動作は可能であるが、該装置の親装置がバッテリ駆動の状態にある場合の子装置の状態である。
【0053】
以下、図10A図17Bを参照しながら、上記動作説明の具体例として、各格納部にデータが設定される様子を、親装置の状態毎に分けて説明する。
【0054】
(親装置を再利用可能な場合)
まず、第1のケースとして、全ての子装置が災害故障した親装置(浮装置)を再利用可能な場合を想定する。この場合、災害状態格納部17の親装置の「再利用状態」には“子故障”が設定され(図8のS162参照)、親装置は、既に再利用可能な状態にある。
【0055】
図10Aは、親装置を再利用可能な場合における装置情報格納部15内のデータ格納例を示す図である。図10Aに示す様に、装置情報格納部15には、災害が発生したエリアと、格納データの更新時刻と、該時刻における装置状態とが、装置ID及び装置名毎に対応付けられ、降順に格納されている。例えば、最上段のレコードを参照すると、装置ID“1.1.2”を有するeNodeB60は、災害発生エリアである“岩手”に属し、災害発生時刻(図10B参照)以降の更新時刻の装置状態として、“故障”が設定されている。eNodeB50に関しても同様に、装置状態に“故障”が設定されている。従って、MME40は、全ての子装置(eNodeB50、60)が災害故障の状態にある親装置、すなわち親浮装置に該当する。
【0056】
図10Bは、親装置を再利用可能な場合における災害情報格納部12内のデータ格納例を示す図である。図10Bに示す様に、災害情報格納部12には、保守端末70から提供された「災害発生時刻」として“2012/09/20 13:00”が設定され、「災害発生エリア」として“岩手”が設定されている。
【0057】
図11Aは、親装置を再利用可能な場合における親子関係格納部13内のデータ格納例を示す図である。図11Aに示す様に、装置ID“1”を有するS−GW30には、親装置は存在しないが、装置ID“1.1”を有するMME40が、子装置として存在する。また、MME40は、eNodeB50、60をそれぞれ子装置として有する。従って、MME40は、S−GW30との関係では子装置であるが、各eNodeB50、60との関係では親装置となる。
【0058】
図11Bは、親装置を再利用可能な場合における災害状態格納部17内のデータ格納例を示す図である。例えば、各格納部内のデータが、図10A図10B図11Aに示した様に設定されている場合、親浮装置検出処理(図8参照)の実行により、災害状態格納部17内のデータは、図11Bに示す様な設定状態となる。すなわち、災害状態格納部17には、災害が発生した「エリア」と、格納データの「更新時刻」と、該時刻における「装置状態」とが、「装置ID」及び「装置名」毎に、更新可能に設定されている。更に、災害状態格納部17には、各装置が再利用可能か否かの判断指標となる「再利用状態」と、各装置の親装置の状態を表す「親装置状態」とが、装置ID及び装置名と対応付けられ、更新可能に設定されている。
【0059】
例えば、図11Bの2段目のレコードを参照すると、装置ID“1.1”を有するMME40に関し、自装置の「装置状態」は“正常”であるが、子装置の装置状態として“災害故障”が設定されている。このため、MME40の「再利用状態」には、“子故障”が設定されることとなる。また、MME40の親装置であるS−GW30の「装置状態」には“正常”が設定されているため、MME40の「親装置状態」には、“稼働中”が設定されることとなる。同様に、装置ID“1.1.2”を有するeNodeB60に関し、自装置の「装置状態」は“災害故障”であるが、浮装置となった親装置は、他の装置(例えば、eNodeB80、90)の親装置として再利用されている。このため、eNodeB60の「再利用状態」には、“使用中”が設定されることとなる。また、eNodeB60の親装置であるMME40の「装置状態」には“正常”が設定されているため、eNodeB60の「親装置状態」には、“稼働中”が設定されることとなる。なお、「親装置状態」の“−”は、該当する装置(例えば、S−GW30)に親装置が存在しないことを示す。
【0060】
上述した様に、災害状態格納部17に設定されたデータは、災害状態情報として、保守端末70宛に送信された後、表示装置に表示される。併せて、表示装置には、例えば、「岩手で災害が発生しました。この災害により、子装置(eNodeB50、60)が全て故障したので、親装置(S−GW30、MME40)の再利用が可能です。」等のメッセージが表示される。これにより、保守管理者は、災害の発生によりeNodeB50、60が故障した結果、S−GW30とMME40とを親装置として再利用可能であるとの判定が可能となる。また、保守管理者は、災害要因で故障となり復旧までに長期を要する子装置(例えば、eNodeB50、60)を、簡易かつ迅速に特定することができる。
【0061】
(親装置の再利用を準備可能な場合)
次に、第2のケースとして、全ての子装置が災害故障した親装置(浮装置)の再利用を準備可能な場合を想定する。この場合、災害状態格納部17の親装置の「再利用状態」には“子故障予測”が設定される(図8のS164参照)。親装置は、現時点では再利用可能な状態にないが、間もなく再利用可能な状態となる。ここで、再利用の準備とは、親装置の局データの準備であり、例えば、親装置(浮装置)であるMME40のIP(Internet Protocol)アドレスの再設定、あるいは、新たに子装置となったeNodeB側のトラフィック振り分け条件の再設定等である。
【0062】
図12A図13Bは、図10A図11Bと同様であることから、詳細な説明は省略する。図12Aは、親装置の再利用を準備可能な場合における装置情報格納部15内のデータ格納例を示す図である。図12Aに示す様に、装置情報格納部15には、災害発生エリアと更新時刻と装置状態と故障箇所とが、装置ID及び装置名と対応付けられ、降順に格納されている。例えば、2段目のレコードを参照すると、装置ID“1.1.1”を有するeNodeB50は、災害発生エリアである“岩手”に属し、災害発生時刻(図12B参照)以降の更新時刻の装置状態として、“部分故障”が設定されている。特に、装置状態が“部分故障”である場合には、該部分故障の発生箇所(例えば、“電源”)が設定される。従って、MME40は、全ての子装置(eNodeB50、60)が災害故障または災害起因のバッテリ駆動(将来的に災害故障となる状態)の状態にある親装置、すなわち親浮装置に該当する。
【0063】
図12Bは、親装置の再利用を準備可能な場合における災害情報格納部12内のデータ格納例を示す図である。図12Bに示す様に、災害情報格納部12には、保守端末70から提供された「災害発生時刻」として“2012/09/20 13:00”が設定され、「災害発生エリア」として“岩手”が設定されている。
【0064】
図13Aは、親装置の再利用を準備可能な場合における親子関係格納部13内のデータ格納例を示す図である。図13Aに示す様に、S−GW30とMME40とにはそれぞれ、子装置であるMME40とeNodeB50、60とが存在する。従って、MME40は、S−GW30との関係では子装置であるが、各eNodeB50、60との関係では親装置となる。
【0065】
図13Bは、親装置の再利用を準備可能な場合における災害状態格納部17内のデータ格納例を示す図である。例えば、各格納部内のデータが、図12A図12B図13Aに示した様に設定されている場合、親浮装置検出処理(図8参照)の実行により、災害状態格納部17内のデータは、図13Bに示す様な設定状態となる。
【0066】
例えば、図13Bの2段目のレコードを参照すると、装置ID“1.1”を有するMME40に関し、自装置の「装置状態」は“正常”であるが、子装置の装置状態として“(災害起因の)バッテリ駆動”と“災害故障”とが設定されている。このため、MME40の「再利用状態」には、“子故障予測”が設定されることとなる。また、MME40の親装置であるS−GW30の「装置状態」には“正常”が設定されているため、MME40の「親装置状態」には、“稼働中”が設定される。
【0067】
また、装置ID“1.1.1”を有するeNodeB50に関し、自装置の「装置状態」は“(災害起因の)バッテリ駆動”であるが、浮装置となった親装置は、他の装置(例えば、eNodeB80、90)の親装置として、将来的に再利用可能となる。このため、eNodeB50の「再利用状態」には、“使用中”が設定されることとなる。また、eNodeB50の親装置であるMME40の「装置状態」には“正常”が設定されているため、eNodeB50の「親装置状態」には、“稼働中”が設定されることとなる。なお、「親装置状態」の“−”は、該当する装置(例えば、S−GW30)に親装置が存在しないことを示す。
【0068】
上述した様に、災害状態格納部17に設定されたデータは、災害状態情報として、保守端末70宛に送信された後、表示装置に表示される。併せて、表示装置には、例えば、「岩手で災害が発生しました。この災害により、間もなく、全ての子装置(eNodeB50、60)が故障するので、親装置(S−GW30、MME40)を再利用する準備を始めて下さい。但し、再利用の開始は、全ての子装置の災害故障が確認された後にして下さい。」等のメッセージが表示される。これにより、保守管理者は、災害の発生によりeNodeB50、60が間もなく故障する結果、S−GW30とMME40とを親装置として再利用するための準備作業を開始可能であるとの判定が早期に可能となる。また、保守管理者は、災害要因で停止することが予想される子装置(例えば、eNodeB50、60)を、簡易かつ迅速に特定することができる。
【0069】
(親装置を変更可能な場合)
次に、第3のケースとして、災害故障した親装置を変更可能な場合を想定する。この場合、災害状態格納部17の子装置(浮装置)の「親装置状態」には“親故障”が設定され(図9のS195参照)、親装置は、既に変更可能な状態にある。
【0070】
図14Aは、親装置を変更可能な場合における装置情報格納部15内のデータ格納例を示す図である。図14Aに示す様に、装置情報格納部15には、災害が発生したエリアと、格納データの更新時刻と、該時刻における装置状態とが、装置ID及び装置名毎に対応付けられ、昇順に格納されている。例えば、2段目のレコードを参照すると、装置ID“1.1”を有するMME40は、災害発生エリアである“岩手”に属し、災害発生時刻(図14B参照)以降の更新時刻の装置状態として、“故障”が設定されている。従って、eNodeB50、60は、親装置(MME40)が災害故障の状態にある子装置、すなわち子浮装置に該当する。
【0071】
図14Bは、親装置を変更可能な場合における災害情報格納部12内のデータ格納例を示す図である。図14Bに示す様に、災害情報格納部12には、保守端末70から提供された「災害発生時刻」として“2012/09/20 13:00”が設定され、「災害発生エリア」として“岩手”が設定されている。
【0072】
図15Aは、親装置を変更可能な場合における親子関係格納部13内のデータ格納例を示す図である。図15Aに示す様に、装置ID“1”を有するS−GW30には、親装置は存在しないが、装置ID“1.1”を有するMME40が、子装置として存在する。また、MME40は、eNodeB50、60をそれぞれ子装置として有する。従って、MME40は、S−GW30との関係では子装置であるが、各eNodeB50、60との関係では親装置となる。
【0073】
図15Bは、親装置を変更可能な場合における災害状態格納部17内のデータ格納例を示す図である。例えば、各格納部内のデータが、図14A図14B図15Aに示した様に設定されている場合、子浮装置検出処理(図9参照)の実行により、災害状態格納部17内のデータは、図15Bに示す様な設定状態となる。すなわち、災害状態格納部17には、災害が発生した「エリア」と、格納データの「更新時刻」と、該時刻における「装置状態」とが、「装置ID」及び「装置名」毎に、更新可能に設定されている。更に、災害状態格納部17には、各装置が再利用可能か否かの判断指標となる「再利用状態」と、各装置の親装置の状態を表す「親装置状態」とが、装置ID及び装置名と対応付けられ、更新可能に設定されている。
【0074】
例えば、図15Bの最上段のレコードを参照すると、装置ID“1”を有するS−GW30に関し、自装置の「装置状態」は“正常”であるが、子装置(MME40)の装置状態として“災害故障”が設定されている。このため、S−GW30の「再利用状態」には、“子故障”が設定されることとなる。また、S−GW30には親装置が存在しないため、S−GW30の「親装置状態」には、“−”が設定されている。同様に、装置ID“1.1.1”を有するeNodeB50に関し、自装置の「装置状態」は“正常”であることから、浮装置となった子装置は、他の装置(例えば、MME100)の子装置として再利用されている。このため、eNodeB50の「再利用状態」には、“使用中”が設定されることとなる。また、eNodeB50の従前の親装置であるMME40の「装置状態」には“災害故障”が設定されているため、eNodeB50の「親装置状態」には、“親故障”が設定されることとなる。
【0075】
上述した様に、災害状態格納部17に設定されたデータは、災害状態情報として、保守端末70宛に送信された後、表示装置に表示される。併せて、表示装置には、例えば、「岩手で災害が発生しました。この災害により、親装置(MME40)が故障したので、子装置(eNodeB50、60)の親装置の変更、及び親装置(S−GW30)の再利用が可能です。」等のメッセージが表示される。これにより、保守管理者は、災害の発生によりMME40が故障した結果、MME40を変更可能であるとの判定が可能となる。また、保守管理者は、災害要因で故障となり復旧までに長期を要する親装置(例えば、MME40)を、簡易かつ迅速に特定することができる。
【0076】
(親装置の変更を準備可能な場合)
次に、第4のケースとして、災害に起因してバッテリ駆動となった親装置の変更を準備可能な場合を想定する。この場合、災害状態格納部17の子装置(浮装置)の「親装置状態」には“親故障予測”が設定される(図9のS197参照)。親装置は、現時点では変更可能な状態にないが、間もなく変更可能な状態となる。ここで、変更の準備とは、子装置の局データの準備であり、例えば、子装置(浮装置)であるeNodeB50、60のIPアドレスの再設定、あるいは、新たに親装置となったMME側のトラフィック振り分け条件の再設定等である。
【0077】
図16A図17Bは、図14A図15Bと同様であることから、詳細な説明は省略する。図16Aは、親装置の変更を準備可能な場合における装置情報格納部15内のデータ格納例を示す図である。図16Aに示す様に、装置情報格納部15には、災害発生エリアと更新時刻と装置状態と故障箇所とが、装置ID及び装置名と対応付けられ、昇順に格納されている。例えば、2段目のレコードを参照すると、装置ID“1.1”を有するMME40は、災害発生エリアである“岩手”に属し、災害発生時刻(図16B参照)以降の更新時刻の装置状態として、“部分故障”が設定されている。特に、装置状態が“部分故障”である場合には、該部分故障の発生箇所(例えば、“電源”)が併せて設定される。従って、各eNodeB50、60は、親装置(MME40)が災害起因のバッテリ駆動(将来的に災害故障となる状態)の状態にある子装置、すなわち子浮装置に該当する。
【0078】
図16Bは、親装置の変更を準備可能な場合における災害情報格納部12内のデータ格納例を示す図である。図16Bに示す様に、災害情報格納部12には、保守端末70から提供された「災害発生時刻」として“2012/09/20 13:00”が設定され、「災害発生エリア」として“岩手”が設定されている。
【0079】
図17Aは、親装置の変更を準備可能な場合における親子関係格納部13内のデータ格納例を示す図である。図17Aに示す様に、S−GW30とMME40とにはそれぞれ、子装置であるMME40とeNodeB50、60とが存在する。従って、MME40は、S−GW30との関係では子装置であるが、各eNodeB50、60との関係では親装置となる。
【0080】
図17Bは、親装置の変更を準備可能な場合における災害状態格納部17内のデータ格納例を示す図である。例えば、各格納部内のデータが、図16A図16B図17Aに示した様に設定されている場合、子浮装置検出処理(図9参照)の実行により、災害状態格納部17内のデータは、図17Bに示す様な設定状態となる。
【0081】
例えば、図17Bの最上段のレコードを参照すると、装置ID“1”を有するS−GW30に関し、自装置の「装置状態」は“正常”であるが、子装置(MME40)の装置状態として“(災害起因の)バッテリ駆動”が設定されている。このため、S−GW30の「再利用状態」には、“子故障予測”が設定されることとなる。また、S−GW30には親装置が存在しないため、S−GW30の「親装置状態」には、“−”が設定される。
【0082】
また、装置ID“1.1.1”を有するeNodeB50に関し、自装置の「装置状態」は“正常”であることから、他の装置(例えば、MME100)を親装置として、将来的に再利用可能となる。このため、eNodeB50の「再利用状態」には、“使用中”が設定されている。また、eNodeB50の親装置であるMME40の「装置状態」には“(災害起因の)バッテリ駆動”が設定されているため、eNodeB50の「親装置状態」には、“親故障予測”が設定されることとなる。
【0083】
上述した様に、災害状態格納部17に設定されたデータは、災害状態情報として、保守端末70宛に送信された後、表示装置に表示される。併せて、表示装置には、例えば、「岩手で災害が発生しました。この災害により、間もなく、親装置(MME40)が故障するので、子装置(eNodeB50、60)の親装置の変更の準備、及び親装置(S−GW30)の再利用の準備を始めて下さい。但し、変更及び再利用の開始は、親装置の災害故障が確認された後にして下さい。」等のメッセージが表示される。これにより、保守管理者は、災害の発生によりMME40が間もなく故障する結果、MME40の変更に向けた準備作業を実施可能であるとの判定が早期に可能となる。また、保守管理者は、災害要因で停止することが予想される親装置(例えば、MME40)を、簡易かつ迅速に特定することができる。
【0084】
以上説明した様に、本実施例に係る浮検出システム1は、浮検出装置10と、浮検出装置10と通信可能な保守端末70とを有する。浮検出装置10は、装置状態収集部14と浮検出部16とを有する。装置状態収集部14は、監視対象となる複数の装置(例えば、S−GW30、MME40、eNodeB50、60)の状態を示す装置状態情報を取得する。浮検出部16は、図11B図15Bの「装置状態」に示した様に、装置状態収集部14により取得された装置状態情報に基づき、上記複数の装置の中から、所定の要因(例えば、災害要因)で停止(例えば、故障、動作不能)した装置(例えば、eNodeB50、60)を検知する。また、浮検出部16は、図11B図15Bの「再利用状態」に示した様に、上記検知結果を用いて、各装置(例えば、S−GW30、MME40、eNodeB50、60)の使用(例えば、再利用、変更)の可否を判定する。これにより、浮検出部16は、上記複数の装置の中から、動作可能であるが通信に使用されない対象装置(浮装置)を検出する。そして、浮検出部16は、該検出結果を保守端末70に提供する。保守端末70は、浮検出装置10から提供された上記検出結果を通知する通知部71を有する。
【0085】
例えば、浮検出装置10は、災害故障等による長期停止であれば、浮装置を使用可能と判定するが、間欠故障等による短期停止であれば、浮装置を使用不可と判定する(使用可と判定しない)。なお、長期停止とは、復旧までに長時間(例えば、1時間以上)を要する停止であり、短期停止とは、短時間(例えば、1時間未満)での復旧が見込まれる一時的な停止である。
【0086】
本実施例に係る浮検出装置10によれば、保守管理者は、上記検出結果を参照することで、装置の停止要因に応じて、各装置の使用可否を容易に判断することができる。従って、浮検出システム1は、装置間におけるトラフィックの再送、ひいてはシステムの復旧を早期に行うことが可能となる。その結果、浮検出システム1の信頼性が向上する。
【0087】
また、浮検出装置10において、浮検出部16は、上記検知結果を用いて、上記各装置の再利用の可否または変更の可否を判定することにより、上記複数の装置の中から、上記対象装置(浮装置)を検出するものとしてもよい。これにより、保守管理者は、災害故障が発生した場合にも、システムを早期に復旧させることができる。
【0088】
更に、浮検出装置10において、浮検出部16は、図13B図17Bの「装置状態」に示した様に、装置状態収集部14により取得された装置状態情報に基づき、上記複数の装置の中から、所定の要因で停止することが予想される装置(例えば、eNodeB50、60)を検知する。また、浮検出部16は、図13B図17Bの「再利用状態」に示した様に、上記検知結果を用いて、各装置(例えば、S−GW30、MME40、eNodeB50、60)の使用準備(例えば、再利用準備、変更準備)の可否を判定する。これにより、浮検出部16は、上記複数の装置の中から、上記対象装置(浮装置)となることが予想される装置を検出するものとしてもよい。かかる態様によれば、保守管理者は、災害故障に先立ち、例えばバッテリ駆動となった時点で、システム復旧の事前準備をすることができる。従って、実際に災害故障が発生した場合に、簡易かつ迅速な災害対応が可能となる。
【0089】
また、浮検出装置10において、上記対象装置(浮装置)は、全ての下位装置(例えば、子装置としてのeNodeB50、60)が停止した装置(親装置としてのMME40)であってもよい。あるいは、上記対象装置は、上位装置(例えば、親装置としてのMME40)が停止した装置(例えば、子装置としてのeNodeB50、60)であってもよい。これにより、浮検出装置10は、親子関係を有する装置が災害等により故障した場合にも対応することができる。
【0090】
更に、浮検出部16は、浮装置の検出に際し、子故障、子故障予測、親故障、親故障予測の設定を災害状態格納部17に対して行う。これにより、浮検出装置10は、災害要因で復旧に時間の掛かる装置と、災害要因で停止が予想される装置とを区別して、処理することができる。換言すれば、浮検出装置10は、災害起因のバッテリ駆動からバッテリの電力が尽きて故障となり、送電等のライフラインの復旧を待つ間に再利用や変更が可能となる装置と、実際に災害故障した装置とを区別して、保守管理者に通知することができる。
【0091】
なお、上記実施例では、無線通信方式として、3GPPのLTEを想定して説明したが、浮検出システム1は、W−CDMA等、他の無線通信方式にも適用可能である。また、災害故障の監視対象となるゲートウェイ装置は、S−GWに限らず、P−GW(Packet data network-Gate Way)等の他の装置であってもよい。更に、監視対象となる装置間の接続形態(ネットワークトポロジー)は、ツリー型に限らず、上記実施例に係る浮検出システム1を、スター型、バス型、リング型等のネットワークに適用するものとしてもよい。
【0092】
また、浮検出システム1の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は、図示のものに限らず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することもできる。例えば、浮検出装置10の災害情報設定部11と装置状態収集部14、あるいは、各格納部をそれぞれ1つの構成要素として統合してもよい。反対に、浮検出装置10の浮検出部16に関し、親浮装置を検出する部分(親浮検索機能)と、子浮装置を検出する部分(子浮検索機能)とに分散してもよい。また、浮検出部16に関し、災害故障した装置を検知する部分と、各装置の使用可否を判定する部分と、複数の装置の中から浮装置を検出する部分とに分散してもよい。更に、各種情報の格納部としてのメモリ10bやHDD10dを、浮検出装置10の外部装置として、ネットワークやケーブル経由で接続する様にしてもよい。また、上記実施例では、災害状態の表示を保守端末70が行うものとしたが、浮検出装置10が表示装置を有し、浮検出装置10側で、浮装置を含む災害状態を表示するものとしてもよい。
【符号の説明】
【0093】
1 浮検出システム
10 浮検出装置
10a CPU(Central Processing Unit)
10b メモリ
10c NIC(Network Interface Card)
10d HDD(Hard Disk Drive)
11 災害情報設定部
12 災害情報格納部
13 親子関係格納部
14 装置状態収集部
15 装置情報格納部
16 浮検出部
17 災害状態格納部
20 NMS(Network Management System)
21 装置状態格納部
30 S−GW(Serving-GateWay)
40、100 MME(Mobility Management Entity)
50、60、80、90 eNodeB
70 保守端末
71 通知部
121、122、123、124 災害情報格納部内のデータ
131、132、133、134 親子関係格納部内のデータ
151、152、153、154 装置情報格納部内のデータ
171、172、173、174 災害状態格納部内のデータ
a1 災害発生時刻
a2 災害発生エリア
b1 親装置の装置ID
b2 親装置の装置名
b3 子装置の装置ID
b4 子装置の装置名
c1 装置ID
c2 装置名
c3 エリア
c4 更新時刻
c5 装置状態
c6 故障箇所
d1 装置ID
d2 装置名
d3 エリア
d4 更新時刻
d5 災害状態
d6 再利用状態
d7 親装置状態
N 保守用ネットワーク
図1
図2
図3A
図3B
図4A
図4B
図5
図6
図7
図8
図9
図10A
図10B
図11A
図11B
図12A
図12B
図13A
図13B
図14A
図14B
図15A
図15B
図16A
図16B
図17A
図17B