JP2009231861A - 無線通信システム並びに運用管理保守方法及び運用管理保守装置 - Google Patents

Abstract

【課題】複数の無線基地局についての効率的な運用管理保守処理を可能にする。
【解決手段】ＦＢＴＳ制御装置３０−Ｎ（ＯＡＭ制御部３６）では、配下に接続されているＦＢＴＳ４０−ｍを１台又は複数台を要素とするＦＢＴＳグループ＃１〜＃ｎ（ただし、ｎは２≦ｎ＜ｍを満足する整数である）にグループ化して管理する。このグループ＃ｋ（ｋ＝１〜ｎ）を単位として、ＦＢＴＳ４０−ｍの障害情報や輻輳情報などの集約、管理などを行なうことができる。これにより、ネットワークの通信負荷や上位のＲＮＣ２０での処理負荷を軽減することが可能となる。
【選択図】図３

Description

本件は、無線通信システム並びに運用管理保守方法及び運用管理保守装置に関する。本件は、例えば、フェムトセルとも呼ばれる小規模なセルを形成する無線基地局を設置する際に用いられる場合がある。

移動通信システムの屋内での無線カバー率は、それほど高くない。その理由にはいくつかあるが、例えば、屋内には無線電波が届きにくいことや、屋内用の無線基地局の設置、運用にコストがかかること等の理由による。

このような状況の中で、近年、「フェムトセル（Femto Cell）」と呼ばれる超小型のBase Transceiver Station（ＢＴＳ、無線基地局）が提案されている。このＢＴＳは、家庭やオフィス等の屋内での利用を想定したもので、例えば、wideband-code division multiple access（Ｗ−ＣＤＭＡ）方式に対応しており、半径数十ｍ程度の小規模なセル（フェムトセル）を形成して少ないユーザ数（４ユーザ程度）の同時通信を可能にする。また、価格も安価である。

このような超小型ＢＴＳ（以下、フェムトセルＢＴＳともいう）を、既存の無線基地局ではカバーしきれない高層ビルや地下施設等の屋内（不感帯）に配置することで、運用コストを上げずにカバー率を向上することが考えられている。

なお、移動体通信システムのカバー率を向上する手段の一つとして、既存の基地局装置と有線回線にて接続されたradio frequency（ＲＦ）装置を前記基地局装置に対して遠隔設置する技術も知られている。
特開２００４−４０８０２号公報 特表２００２−５２４９８９号公報 「3GSM続報 韓国SamsungやNECが「Femto Cell」を出展」、［online］、平成１９年２月２０日、［平成２０年２月２５日検索］、インターネット〈URL：http://techon.nikkeibp.co.jp/article/NEWS/20070220/127968/〉 "Manufacturing Agreement For Zone Gate Low-Cost Residential 3G Access Point"、［online］、平成１８年１１月１日、［平成２０年２月２５日検索］、インターネット〈URL：http://www.3g.co.uk/PR/Nov2006/3849.htm〉 NTT DoCoMoテクニカル・ジャーナルVol.15 No.1、［online］、平成１９年４月、［平成２０年２月２５日検索］、インターネット〈URL：http://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol15_1/vol15_1_08jp.pdf〉

フェムトセルＢＴＳは、各家庭やオフィスビルの各フロアなどの屋内に設置される場合があることを想定すると、その設置数は非常に多くなることが予想される。しかし、基地局を収容して制御する装置（ＲＮＣ：Radio Network Controller）が収容（制御）可能な基地局数にも限りがある（例えば、数百ＢＴＳ程度）。そのため、フェムトセルＢＴＳを多数（例えば、数千ＢＴＳ以上）収容するには、大規模で高価なＲＮＣ数を増やさざるを得なくなる場合がある。

本件の目的の一つは、複数の無線基地局についての効率的な運用管理保守処理を可能にすることにある。

なお、前記目的に限らず、後述する実施形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の一つとして位置付けることができる。

例えば、以下の手段を用いる。

（１）複数の無線基地局と、前記複数の無線基地局を複数のグループにグループ化して、前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する運用管理保守装置と、をそなえる、無線通信システムを用いることができる。

（２）複数の無線基地局を複数のグループにグループ化して管理し、前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する、運用管理保守方法を用いることができる。

（３）複数の無線基地局を複数のグループにグループ化して管理する管理部と、前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する処理部と、をそなえる、運用管理保守装置を用いることができる。

本件開示の技術によれば、複数の無線基地局についての効率的な運用管理保守処理が可能となる。

以下、図面を参照して実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本実施形態は、その趣旨を逸脱しない範囲で種々変形（各実施例を組み合わせる等）して実施することができる。

〔１〕システム構成
図１は、一実施形態に係る無線通信システムの一例としてのフェムトセルシステムの構成例を示す図である。この図１に示すシステムは、例えば、コアネットワーク（ＣＮ）１０と、このＣＮ１０に接続された少なくとも１台のradio network controller（ＲＮＣ、基地局制御装置）２０と、Ｎ台（Ｎは１以上の整数）の超小型ＢＴＳ制御装置（フェムトセルＢＴＳ制御装置）３０−１〜３０−Ｎ（＃１〜＃Ｎ）と、ｍ台（ｍは２以上の整数）の超小型ＢＴＳ（フェムトセルＢＴＳ）４０−１〜４０−ｍ（＃１〜＃ｍ）と、１又は複数台のユーザ端末の一例としての移動端末（無線端末）５０と、をそなえる。

また、ＲＮＣ２０は、保守用ネットワーク（ＮＷ）６０を介して上位装置の一例としてのオペレーティングシステム（ＯＰＳ）７０と通信可能に接続され、必要に応じてＯＰＳ７０との間でoperation, administration and maintenance（ＯＡＭ、運用管理保守）に関する通信を行なうことができる。なお、本例において、ＯＡＭ処理とは、運用、管理、保守のいずれか１又は２以上の組み合わせが含まれることを意味し、運用、管理、保守のすべてが必須であることを意味しない。また、これら３つ以外の処理が含まれることを排除するものでもない。

ＣＮ１０は、Ｗ−ＣＤＭＡ網等の無線アクセス網に配置されるＲＮＣ２０よりも上位のネットワーク装置の総称であり、加入者情報の管理、各ネットワーク装置の監視／管理、他ネットワーク網との接続等を行なうエンティティを具備する。

ＲＮＣ２０は、既存の基地局（ＢＴＳ）（Node Bとも呼ばれる）を１又は複数収容して制御することのできる装置であり、各既存ＢＴＳとの間で、制御プレーン（C-Plane）のデータ（つまり制御信号）や、ユーザプレーン（U-Plane）のデータ（つまりユーザ信号）等の信号を送受信する機能を具備する。

C-Planeデータには、例えば、移動端末５０宛の呼制御信号や、基地局制御に関する信号であるNode B application part（ＮＢＡＰ）信号が含まれる。また、フェムトセルＢＴＳ制御装置３０−ｉ（ｉ＝１〜Ｎ）とフェムトセルＢＴＳ４０−ｊ（ｊ＝１〜ｍ）との間の無線チャネルの観点からすると、C-Planeデータには、共通チャネルや、個別チャネル、報知チャネル、ページングチャネル等に関する信号が含まれる。一方、U-Planeデータには、共通チャネルや個別チャネルの信号が含まれる。

そして、本例のＲＮＣ２０は、既存ＢＴＳとともに、あるいは代替的に、Ｎ台のフェムトセルＢＴＳ制御装置３０−１〜３０−Ｎを収容することが可能な装置でもあり、これらのフェムトセルＢＴＳ制御装置３０−ｉとの間でも、既存ＢＴＳに対するのと同等の信号を送受信することが可能である。なお、ＲＮＣ２０とフェムトセルＢＴＳ制御装置３０−ｉとの間の接続インタフェース（ＩＦ）には、ＲＮＣ２０と既存ＢＴＳとの接続ＩＦと同じもの（例えば、Iubインタフェース）を適用することができる。

フェムトセルＢＴＳ制御装置（以下、ＦＢＴＳ制御装置と表記する）３０−ｉは、それぞれｍ台のフェムトセルＢＴＳ（以下、ＦＢＴＳと表記する）４０−１〜４０−ｍを収容することが可能な装置である。本例のＦＢＴＳ制御装置（運用管理保守装置）３０−ｉは、配下のＦＢＴＳ４０−ｊに対する、呼処理（発信、位置登録、ページング、報知、U-Plane信号処理等）や、ＯＡＭ処理（故障検出、輻輳制御、プログラム更新などの処理が含まれる）、セル設定などを実施することができる。

なお、ここでいう「セル設定」とは、ＦＢＴＳ４０−ｊが形成するセルのための無線リソースに関する設定を意味する。無線リソースには、Ｗ−ＣＤＭＡ方式を例にすれば、セル毎の、スクランブリングコード（ＳＣ）、チャネライゼーションコード（ＣＣ）、使用周波数（キャリア）等のいずれか１又は２以上の組み合わせが含まれる。なお、ＳＣは、セルの識別（セルサーチ）に用いられるコードであり、ＣＣはユーザ（移動端末５０）の識別に用いられるコードである。

このような、ＦＢＴＳ制御装置３０−ｉを導入することで、ＲＮＣ２０は、１台のＦＢＴＳ制御装置３０−ｉに対して、既存ＢＴＳに対するのと同等の制御信号（例えば、ＮＢＡＰ信号）を用いて既存ＢＴＳ１台分のセル設定を実施することで、ＦＢＴＳ制御装置３０−ｉに従属する個々のＦＢＴＳ４０−ｊに対して必要なセル設定を一括して実施することが可能となる。

換言すれば、ＲＮＣ２０からは複数のＦＢＴＳ４０−ｊを仮想的に１台のＢＴＳと見せる（認識させる）ことができる。例えば、各ＦＢＴＳ４０−ｊは、マルチバンドＢＴＳや高密度ＢＴＳといった、複数のセルやキャリア数を扱う１台のＢＴＳとしてＲＮＣ２０に認識させることが可能である。

例えば、３セル×３キャリア（周波数）で計９個のセルをもつＢＴＳとして認識させることが可能である。その場合、ＲＮＣ２０は、９セル分のセル設定情報（無線リソース）を前記ＮＢＡＰ信号によりＦＢＴＳ制御装置３０−ｉに割り当てる。つまり、ＦＢＴＳ制御装置３０−ｉに割り当て可能なセル設定情報の数は、ＲＮＣ２０で認識、管理する単位のセル設定情報数以下であると考えることができる。

ＦＢＴＳ４０−ｊは、それぞれ、無線エリアであるセルを形成し、当該セルに在圏する１又は複数の移動端末５０と無線リンクにて接続して無線通信を行なうことのできる基地局装置であり、例えば、家庭やオフィス等の屋内に設置される。このＦＢＴＳ４０−ｊは、通常の（既存の）ＢＴＳと比較して、主に以下の点で異なる。

（１）同時接続可能なユーザ（移動端末）数が既存ＢＴＳでは数百台であるのに対し１０台程度と少ない。
（２）セル数が既存ＢＴＳでは数セル〜数十セル程度であるのに対し１セル程度と少ない。
（３）電波カバー範囲（セル半径）が既存ＢＴＳでは数ｋｍ程度であるのに対し数十ｍ程度と狭い。

なお、ＦＢＴＳ４０−ｊは、既存ＢＴＳと機能面及び外部と送受信するメッセージに差は無いものとすることができる。

移動端末５０は、ユーザの使用する無線端末であり、いずれかのＦＢＴＳ４０−ｊと無線リンクにて接続して通信を行なう機能（例えば、呼処理の終端機能等）を具備する。

〔２〕ＦＢＴＳ制御装置及びＦＢＴＳ
次に、本例のＦＢＴＳ制御装置３０−ｉ及びＦＢＴＳ４０−ｊの構成例について、図２を参照して説明する。

（２．１）ＦＢＴＳ制御装置
図２に示すように、ＦＢＴＳ制御装置３０−ｉは、例示的に、ＲＮＣ間インタフェース（ＩＦ）３１と、データ管理部３４と、ノード間インタフェース（ＩＦ）３５と、ＯＡＭ制御部３６と、をそなえる。

ここで、ＲＮＣ間ＩＦ３１は、ＲＮＣ２０との間のＩＦであり、C-Planeデータ（つまり制御信号）、U-Planeデータ（つまりユーザデータ）等の信号をＲＮＣ２０との間で送受信する機能を具備する。

データ管理部３４は、局データや構成データ、セル設定データなどのデータ管理と制御とを行なう。なお、局データには、自局３０−ｉが、どのＲＮＣ２０と接続されているか、どのＦＢＴＳ４０−ｊと接続されているか、といった接続状態に関する情報や、接続されている装置番号などの情報が含まれる。また、構成データは、配下のＦＢＴＳ４０−ｊを管理、制御するのに用いられるデータであり、前記局データの情報要素を基に作成することができる。この構成データには、例えば、配下のＦＢＴＳ４０−ｊ毎のデータと、配下のＦＢＴＳ４０−ｊをグループ化したグループ別のデータとが含まれる。詳細については後述する。

付加的に、本例のデータ管理部３４は、配下のＦＢＴＳ４０−ｊのグループ化情報を基に、ＯＡＭ処理を行なう際にデータの集約や、配下のＦＢＴＳ４０−ｊへの制御同期などを管理したり、自局（ＦＢＴＳ制御装置）３０−ｉの情報（例えば、障害情報や輻輳情報、プログラムフィルや設定ファイル等のファイルバージョン等）を管理したりすることもできる。

ノード間ＩＦ３５は、ＦＢＴＳ４０−ｊとの間のＩＦであり、C-Planeデータ（ＮＢＡＰ信号を含む）、U-Planeデータ等の信号を送受信する機能を具備する。

ＯＡＭ制御部３６は、ノード間ＩＦ３５を介して接続されている配下のＦＢＴＳ４０−ｊに対するＯＡＭ処理を制御する。このＯＡＭ処理は、ＦＢＴＳ４０−ｊを複数のグループにグループ化した前記グループ単位で選択的に実施することができる。選択的とは、後述するＯＡＭ処理に関する所定の閾値判定により、ＯＡＭ処理の対象となるグループと非対象のグループとが生じ得ることを意味する。

ＯＡＭ処理には、例示的に、ＦＢＴＳ４０−ｊ及び／又はＦＢＴＳ制御装置３０−ｉについての障害監視（検知）、障害通知、輻輳監視（検知）、輻輳通知、輻輳制御、ＦＢＴＳ４０−ｊが保有するデータ（局データ、構成データ、プログラムファイルや設定ファイル等の各種データが含まれる）の更新その他の処理が含まれる。ＯＡＭ制御部３６は、これらのＯＡＭ処理に応じた機能（処理）部を必要に応じて選択的に具備することができる。

例示的に、図２に示すＯＡＭ制御部３６は、トラヒック処理部３６１と、輻輳検知処理部３６２と、障害監視処理部３６３と、ファイル操作処理部３６４と、をそなえる。なお、図２において、呼処理制御部などの呼処理に関連する機能ブロックの図示は省略している。

トラヒック処理部３６１は、ＯＡＭ処理の一つとして、上位のＲＮＣ２０との間及び／又は配下のＦＢＴＳ４０−ｊとの間の通信トラヒック（以下、単に「トラヒック」ともいう）の監視、管理、制御などを行なう。

輻輳検知処理部３６２は、ＯＡＭ処理の一つとして、前記通信トラヒックなどを基に、ＦＢＴＳ制御装置３０−ｉ及び／又は配下のＦＢＴＳ４０−ｊの輻輳状態の検知、管理、制御などを行なう。

障害監視処理部３６３は、ＯＡＭ処理の一つとして、ＦＢＴＳ制御装置３０−ｉ及び／又は配下のＦＢＴＳ４０−ｊの障害の状態監視や通知を行なう。

ファイル操作処理部３６４は、ＯＡＭ処理の一つとして、ＦＢＴＳ制御装置３０−ｉ及び／又は配下のＦＢＴＳ４０−ｊが保有する局データ、構成データ、プログラムファイル、設定ファイルなどの各種データの更新、転送などのデータ（ファイル）操作関連の処理を行なう。

上記の各処理部３６１〜３６４には、それぞれデータ（フォーマット）変換部３６０がそなえられ、このデータ変換部３６０によって、ＲＮＣ２０との間の通信、配下のＦＢＴＳ４０−ｊとの間の通信にそれぞれ適した信号フォーマットへの変換を行なうことができる。例えば、ＲＮＣ２０との間の通信に用いられる既存の信号フォーマットへの変換を行なうこととすれば、ＲＮＣ２０に大規模な改修を加えずにＦＢＴＳ制御装置３０−ｉをＲＮＣ２０に収容することができる。なお、データ変換部３６０は、前記各処理部３６１〜３６４に共通のものとしてもよい。

以上のＦＢＴＳ制御装置３０−ｉの機能の一部又は全部は、ＲＮＣ２０に具備することとしてもよい。

また、次世代移動体通信システムにおけるeNodeBのように、ＲＮＣ２０の機能の一部が基地局装置に組み込まれる場合、ＦＢＴＳ制御装置３０−ｉは、ＲＮＣ２０ではなくeNodeB、あるいは、アクセスゲートウェイ（aGW）等のeNodeBの上位装置に接続されることとしてもよい。その場合、ＦＢＴＳ制御装置３０−ｉは、当該eNodeBや上位装置から例えばＯＡＭ処理に関する情報や１台分のeNodeBに設定されるセル数分のセル設定情報の割り当てを受けて、配下のＦＢＴＳ４０−ｊについてのＯＡＭ処理やセル設定を実施することが可能である。

（２．２）ＦＢＴＳ
一方、図２に示すＦＢＴＳ４０−ｊは、例示的に、ノード（Node B）間インタフェース（ＩＦ）４１と、データ管理部４５と、ＯＡＭ制御部４６と、をそなえる。なお、図２において、呼処理制御部などの呼処理に関連する機能ブロックの図示は省略している。

ここで、ノード間ＩＦ４１は、ＦＢＴＳ制御装置３０−ｉとの間のＩＦであり、C-Planeデータ（ＮＢＡＰ信号を含む）、U-Planeデータ等の信号を送受信する機能を具備する。

データ管理部４５は、局データや構成データ、セル設定データなどのデータ管理と制御とを行なう。

ＯＡＭ制御部４６は、自局（ＦＢＴＳ４０−ｊ）のＯＡＭ処理を制御する。このＯＡＭ処理にも、例示的に、障害監視（検知）、障害通知、輻輳監視（検知）、輻輳通知、輻輳制御、ＦＢＴＳ４０−ｊが保有するデータ（局データ、構成データ、プログラムファイルや設定ファイル等の各種データが含まれる）の更新その他の処理が含まれる。このＯＡＭ処理は、必要に応じてノード間ＩＦ４１を介してＦＢＴＳ制御装置３０−ｉと連携して実施することができる。ＯＡＭ制御部４６も、これらのＯＡＭ処理に応じた機能（処理）部を必要に応じて選択的に具備することができる。

例示的に、図２に示すように、ＯＡＭ制御部３６は、トラヒック処理部４６１と、輻輳検知処理部４６２と、障害監視処理部４６３と、ファイル操作処理部４６４と、をそなえる。

ここで、トラヒック処理部４６１は、ＯＡＭ処理の一つとして、上位のＦＢＴＳ制御装置３０−ｉとの間及び／又は自局４０−ｊに接続している移動端末５０との間の通信トラヒックの監視、管理、制御などを行なう。

輻輳検知処理部４６２は、ＯＡＭ処理の一つとして、前記通信トラヒックなどを基に、輻輳状態の検知、管理、制御などを行なう。

障害監視処理部４６３は、ＯＡＭ処理の一つとして、障害発生の有無などの状態監視や、その監視結果のＯＰＳ７０に対する通知などを行なう。

ファイル操作処理部４６４は、ＯＡＭ処理の一つとして、自局４０−ｊのプログラムファイル、設定ファイルなどの各種ファイルの更新などのファイル操作関連の制御を行なう。

（２．３）ＦＢＴＳのグループ化情報及び構成データ
本実施形態では、ＦＢＴＳ４０−ｊに対して個別及び／又はグループ別のＯＡＭ処理を行なうために、ＦＢＴＳ４０−ｊについてのグループ化情報と構成データとを用いる。

（２．３．１）グループ化情報について
ＦＢＴＳ制御装置３０−ｉ（ＯＡＭ制御部３６）では、図３に例示するように、配下に接続されているＦＢＴＳ４０−ｊを１台又は複数台を要素とするＦＢＴＳグループ＃１〜＃ｎ（ただし、ｎは２≦ｎ＜ｍを満足する整数である）にグループ化して管理する。ＯＡＭ制御部３６は、このグループ＃ｋ（ｋ＝１〜ｎ）を単位として、ＦＢＴＳ４０−ｊの障害情報や輻輳情報などの集約、管理などを行なうことができる。これにより、ネットワークの通信負荷や上位のＲＮＣ２０での処理負荷を軽減することが可能となる。

なお、グループ化はＯＡＭ処理に都合の良いように任意に設定することができる。例えば、ＦＢＴＳ４０−ｊの設置場所（エリア）別にグループ化することもできる。グループ化の一例を、図４及び図５にそれぞれ示す。

図４は、ＦＢＴＳ４０−ｊが、ビル等の建物内に設置されている様子を示している。そして、この図４では、当該建物のフロア毎に２台ずつのＦＢＴＳ４０−ｊが設置され、フロア毎にＦＢＴＳ４０−ｊのグループ化がなされていることを例示している。即ち、例えば、１階のＦＢＴＳ４０−１及び４０−２がグループ＃１に属し、２階のＦＢＴＳ４０−３及び４０−４がグループ＃２に属し、３階のＦＢＴＳ４０−５及び４０−６がグループ＃３に属することを例示している。

一方、図５は、ある建物の１フロアに２台のＦＢＴＳ４０−１，４０−２が設置され、これら２台のＦＢＴＳ４０−１，４０−２が１つのグループ＃１として設定される様子を示している。

もちろん、１フロアにおいてＦＢＴＳ４０−ｊを複数グループにグループ化することも可能である。また、異なるフロアに設置された複数のＦＢＴＳ４０−ｊを１グループとすることもできる。

以上のようなグループ化は、例えば、ＦＢＴＳ制御装置３０−ｉではＯＡＭ制御部３６がアクセス可能なデータ管理部３４において、ＦＢＴＳ４０−ｊではＯＡＭ制御部４６がアクセス可能なデータ管理部４５において、図６や図７に例示するようなグループ化情報を保持、管理することで実現することが可能である。

すなわち、図６に例示するように、２台のＦＢＴＳ４０−１，４０−２がグループ＃１に属し、別の２台のＦＢＴＳ４０−３，４０−４がグループ＃２に属することとする場合、ＦＢＴＳ４０−１〜４０−４のそれぞれでは、データ管理部４５において、自局４０−ｊがいずれのグループ＃ｋに属するのかを識別する情報（グループ化情報）をデータ管理部４５において保持、管理する。このグループ化情報は、例えばＦＢＴＳ４０−ｊ毎の構成データに含めて管理することができる。なお、構成データには、ＦＢＴＳ４０−ｊの障害情報や輻輳情報などが含まれる。

一方、ＦＢＴＳ制御装置３０−ｉでは、配下のＦＢＴＳ４０−１〜４０−４毎の構成データを集約してデータ管理部３４にて前記グループ化情報を基にグループ＃ｋ別に保持、管理することができる。その際、構成データの検索を効率的に行なえるようにするために、グループ＃ｋ毎の代表データ（例えば、先頭の構成データ）を示すグループインデックス情報を生成することができる。図６には、例示的に、グループ＃１に属するＦＢＴＳ４０−１の装置番号＝１、グループ＃２に属するＦＢＴＳ４０−３の装置番号＝３がそれぞれグループインデックス情報（グループの先頭装置番号）として示されている。

ＯＡＭ制御部３６は、このようなグループインデックス情報を基にして、データ管理部３４において、所望の構成データを効率的に検索、特定することができる。なお、このグループインデックス情報は、例えば、ＦＢＴＳ制御装置３０−ｉの電源投入時や局データの更新時などの所定のタイミングで作成することができる。

一方、図７は、３台のＦＢＴＳ４０−１，４０−２，４０−３がグループ＃１に属し、１台のＦＢＴＳ４０−４がグループ＃２に属する場合におけるデータ管理の一例を示している。この場合は、例示的に、グループ＃１に属するＦＢＴＳ４０−１の装置番号＝１、グループ＃２に属するＦＢＴＳ４０−４の装置番号＝４がそれぞれグループインデックス情報（グループ＃ｋの先頭装置番号）として示されることになる。

（２．３．２）構成データについて
構成データの一例としては、装置別の構成データとグループ別の構成データの２種類のデータがある。装置別構成データは、ＦＢＴＳ４０−ｊ毎のデータであり、グループ別構成データは、前記グループ＃ｋ毎（複数のＦＢＴＳ４０−ｊ単位）のデータである。次表１に、装置別構成データの一例を示し、次表２に、グループ別構成データの一例を示す。

この表１に例示するように、装置別構成データは、ＦＢＴＳ４０−１〜４０−ｍの装置番号（＃１〜＃ｍ）毎に、グループ番号、ＩＰアドレス、装置状態、輻輳状態（例えば、輻輳発生でＯＮ、輻輳なし又は輻輳復旧でＯＦＦ）、プログラムファイルや設定ファイル等の各種ファイルの識別子、前記ファイルのバージョン等に関する情報を情報要素として有する。

また、表２に例示するように、グループ別構成データは、グループ番号（＃１〜＃ｎ）毎に、故障率、前記故障率に関する閾値（故障閾値）、トラヒック量、輻輳発生閾値、輻輳復旧閾値、ＦＢＴＳ４０−ｊの設置エリア等に関する情報を情報要素として有する。

なお、上記各構成データの情報要素の詳細については、後述する動作説明においても適宜説明する。

〔３〕動作説明
以下、上述したシステムの動作（ＯＡＭ処理）例を説明する。本例のＯＡＭ処理には、一例として、（１）故障検出及び故障通知／制御、（２）輻輳検知及び輻輳通知／制御、（３）ファイル更新が含まれる。以下では、これらの処理を項別に説明する。ただし、本システム（ＦＢＴＳ制御装置３０−ｉ及びＦＢＴＳ４０−ｊ）において、これら３種類のＯＡＭ処理のすべてが可能である必要はない。いずれか１又は２以上の組み合わせで実施可能であればよい。

（３．１）故障（障害）処理
ＦＢＴＳ４０−ｊは、ＯＡＭ制御部４６（障害監視処理部４６３）にて自局４０−ｊの障害情報を検出すると、上位のＦＢＴＳ制御装置３０−ｉに対して障害情報を送信する。ＦＢＴＳ制御装置３０−ｉは、保守用ネットワーク６０経由で障害情報をＯＰＳ７０に通知する。

ただし、ＦＢＴＳ制御装置３０−ｉは、グループ＃ｋ毎の故障率と故障閾値との比較（閾値判定）により、ＯＰＳ７０に対する障害情報の通知の要否を判断し、通知が必要と判断した場合に、ＯＰＳ７０宛に障害情報を送信する。また、ＦＢＴＳ制御装置３０−ｉは、ＯＰＳ７０から故障状況の問い合わせを受信した場合、データ管理部３４にて前記構成データとして保持、管理している故障情報をＯＰＳ７０宛に送信する。

（３．１．１）ＦＢＴＳの故障（障害）をＯＰＳに通知するケース
まず、いずれかのＦＢＴＳ４０−ｊの故障（障害）発生をＯＰＳ７０へ通知する場合の動作例について、図８〜図１０を用いて説明する。

一例として、ＦＢＴＳ制御装置３０−１（＃１）の配下のＦＢＴＳ４０−２（＃２）に故障が発生した場合を想定する。また、ＦＢＴＳ＃２の故障発生前の状態として、ＦＢＴＳ制御装置＃１の配下のグループ＃１には、故障中のＦＢＴＳ＃１と、正常状態のＦＢＴＳ＃２及び＃３が属しており、故障閾値は、２／３と仮定する。

図９に例示するように、ＦＢＴＳ＃２の障害監視処理部４６３にて障害が検出されると（処理１００１）、ＦＢＴＳ＃２の障害監視処理部４６３は、検出した障害内容（障害情報）を例えば障害通知メッセージに含めてノード間ＩＦ４１経由で上位のＦＢＴＳ制御装置＃１へ通知（送信）する（処理１００２及び処理１００３）。

ＦＢＴＳ制御装置＃１は、前記障害通知メッセージをノード間ＩＦ３５で受信すると（図９の処理１００３及び図１０の処理１０２１）、当該メッセージをデータ管理３４に転送し（図９の処理１００４）、データ管理部３４は、受信したメッセージ内容（障害情報）を前記装置別構成データに反映する（図９の処理１００５及び図１０の処理１０２２）。その一例を次表３に示す。

次いで、データ管理部３４は、前記装置構成データに反映した故障情報を基にグループ別構成データの故障率を更新し、更新後のグループ別構成データにおける故障率と故障閾値とを比較する（図１０の処理１０２３）。

故障閾値は、例えば、ＦＢＴＳ４０−ｊがホームユーザ向けに各家庭に設置されている場合、１台の故障でもその家庭には通信断等の大きな影響があるため、低めに設定することができる。

これに対し、ＦＢＴＳ４０−ｊが例えば繁華街やオフィス街、公共施設などの不特定ユーザによる利用が想定されるような場所に設置されている場合、１台が故障しても他のＦＢＴＳ４０−ｊが代替となり得るから、故障閾値は高めに設定することができる。

このように、故障閾値は、ＦＢＴＳ４０−ｊの設置エリア別に設定することが可能である。なお、前記表２における「設置エリア」に関する情報がこのことを意味している。「設置エリア」は、ＦＢＴＳ４０−ｊのグループ＃ｋと１対１に対応付けることもできるし、グループ＃ｋとは独立に対応付けることもできる。

さて、本例において、故障閾値は２／３に設定されており、ＦＢＴＳ＃２が故障する前のグループ＃１の故障率は１／３である。データ管理部３４は、装置別構成データを基に、故障発生したＦＢＴＳ＃２がグループ＃１に属していることを識別するから、次表４に例示するように、グループ別構成データの故障率を１／３から２／３へ更新する。その結果、故障率が故障閾値以上となるから、障害通知要と判断して（図１０の処理１０２３のＹＥＳルート）、その旨を障害監視処理部３６３に通知する（図９の処理１００６）。

前記通知を受けた障害監視処理部３６３は、ＯＰＳ７０宛の障害情報を含む障害通知メッセージを生成して、ＲＮＣ間ＩＦ３１経由でＯＰＳ７０へ送信する（図９の処理１００７〜処理１０１０、及び、図１０の処理１０２４及び処理１０２５）。この通知（メッセージ）は、ＲＮＣ２０との間の通信に用いる既存の信号フォーマットを用いて送信することができる。その一例を図８に示す。

この図８では、既存の信号フォーマットとして、ヘッダフィールドと、ＢＴＳ番号フィールドと、故障情報フィールドと、その他のデータフィールドと、を有することを例示している。ヘッダフィールドには、メッセージ種別（障害情報の通知メッセージであること等）を設定することができ、ＢＴＳ番号フィールドには、通知元（既存ＢＴＳ）の装置番号を設定することができる。また、故障情報フィールドには、既存ＢＴＳの故障情報を所定の内部ユニット（カードとも呼ばれる）単位で設定することができる。

このような信号フォーマットにおいて、例えば、ＢＴＳ番号フィールドに、ＦＢＴＳ制御装置３０−ｉの装置番号を設定し、故障情報フィールドに、ＦＢＴＳ４０−ｊの装置番号やそのＦＢＴＳ４０−ｊの属するグループ番号を設定することで、ＲＮＣ２０に対して、どのＦＢＴＳ制御装置３０−ｉ配下の、どのグループ＃ｋに属するどのＦＢＴＳ４０−ｊに故障が発生したかを既存の信号フォーマットを利用して通知することが可能となる。このような信号フォーマットの通知メッセージを生成するのが、例えば前記データ変換部３６０である。ただし、ＲＮＣ２０との間の通信において、信号フォーマットの変更が許容できるなら、障害情報の通知は、既存の信号フォーマットとは異なる信号フォーマットを利用して行なうことも可能である。

なお、前記の閾値判定処理１０２３（図１０）において、故障率が故障閾値未満であった場合、データ管理部３４は、ＦＢＴＳ＃２から受信した障害通知メッセージは無視して、他の障害通知メッセージの受信待機状態となる（処理１０２３のＮＯルート）。

つまり、故障率が故障閾値未満のグループ＃ｋについては、一部のＦＢＴＳ４０−ｊに故障が発生していても、グループ＃ｋとしては故障未発生と判断する。これにより、ＦＢＴＳ４０−ｊについての障害情報のＯＰＳ７０への通知量を削減することが可能となる。したがって、ＦＢＴＳ制御装置３０−ｉ、ＲＮＣ２０、ＯＰＳ７０の処理負荷を低減することが可能である。

また、前記閾値比較処理１０２３は、グループ別構成データの更新を契機に実施することとしているが、一例である。グループ別構成データの更新とは独立して周期的に実施することも可能である。

（３．１．２）ＯＰＳ７０から故障状況の問い合わせを受信したケース
次に、ＯＰＳ７０から故障状況の問い合わせをＦＢＴＳ制御装置３０−ｉが受信した場合の動作例について、図１１〜図１３を用いて説明する。

ＦＢＴＳ制御装置３０−ｉにおいて、ＯＰＳ７０の発行した故障状況の問い合わせメッセージがＲＮＣ２０経由でＲＮＣ間ＩＦ３１にて受信されると（図１２の処理１０１１及び図１３の処理１０３１）、当該問い合わせメッセージは障害監視処理部３６３に転送される（図１２の処理１０１２）。

なお、問い合わせメッセージの信号フォーマットの一例を図１１に示す。この信号フォーマットは、ヘッダフィールドと、ＢＴＳ種別フィールドと、その他のデータフィールドと、を有する。ヘッダフィールドには、その信号の送信元及び宛先を示す情報（ＩＰアドレス等）や、その信号（メッセージ）の種別（故障状況の問い合わせメッセージであること等）を設定することができる。

したがって、ＲＮＣ間ＩＦ３１は、前記ヘッダフィールドの設定情報を参照することで、受信した信号（メッセージ）がＯＰＳ７０からの障害状況の問い合わせメッセージであることを識別して、当該メッセージを障害監視処理部３６３に転送することができる。

また、前記ＢＴＳ種別フィールドには、故障状況の問い合わせ対象が、ＦＢＴＳ制御装置３０−ｉであるのか、それともＦＢＴＳ４０−ｊであるのかを示す情報を設定することができる。

したがって、障害監視処理部３６３は、前記問い合わせメッセージをＲＮＣ間ＩＦ３１から受信した場合に、ＢＴＳ種別フィールドの設定情報を参照することで、ＯＰＳ７０が自局（ＦＢＴＳ制御装置）３０−ｉについての故障状況に関する情報（障害情報）を要求しているのか、それとも配下のＦＢＴＳ４０−ｊについての故障情報を要求しているのかを判断（識別）することができる（図１３の処理１０３２及び処理１０３３）。

その識別の結果、「ＢＴＳ種別」が「ＦＢＴＳ」であれば、障害監視処理部３６３は、ＦＢＴＳ４０−ｊに関する現在の故障状況（障害情報）を、「ＢＴＳ種別」が「ＦＢＴＳ制御装置」であれば、自局（ＦＢＴＳ制御装置３０−ｉ）に関する現在の故障状況を、それぞれデータ管理部３４に問い合わせる（図１２の処理１０１３及び処理１０１４）。

データ管理部３４は、その問い合わせに応じた（つまりはＢＴＳ種別に応じた）障害情報を、前記装置別構成データ及び／又はグループ別構成データ、あるいは、自局３０−ｉの障害情報から取得して、障害監視処理部３６３に通知する（図１２の処理１０１５及び処理１０１６、並びに、図１３の処理１０３４及び処理１０３５）。

そして、障害監視処理部３６３は、通知された障害情報を含む信号の一例として、前記問い合わせメッセージに対する応答メッセージを生成して、この応答メッセージをＲＮＣ間ＩＦ３１経由でＯＰＳ７０宛に送信する（図１２の処理１０１７〜処理１０１９、図１３の処理１０３６及び処理１０３７）。なお、この応答メッセージについても、図８に例示した信号フォーマットを用いることができる。

（３．２）輻輳処理
次に、ＦＢＴＳ制御装置３０−ｉがＦＢＴＳ４０−ｊの輻輳状態をグループ＃ｋ別に監視（検知）、制御する処理一例について、図１４〜図１７を用いて説明する。

ＦＢＴＳ４０−ｊの輻輳状態をＦＢＴＳ制御装置３０−ｉが認識する方法として、例えば、次の２つが考えられる。すなわち、第１の方法は、配下のＦＢＴＳ４０−ｊが検知した輻輳状態に関する情報の通知を当該ＦＢＴＳ４０−ｊから受ける方法である。第２の方法は、ＦＢＴＳ制御装置３０−ｉが、例えば、配下のＦＢＴＳ４０−ｊとの間の通信トラヒックを監視することで、自律的に検知する方法である。以下、これら２つの方法に基づく動作例を項目別に説明する。

（３．２．１）第１の方法（ＦＢＴＳにて輻輳状態を検出）
一例として、ＦＢＴＳ４０−１（＃１）のトラヒック量の増加に伴って、当該ＦＢＴＳ＃１の属するグループ＃１のトラヒック量がそのグループ＃１についての輻輳発生閾値を超えた場合について説明する。

図１４に例示するように、ＦＢＴＳ４０−ｊは、トラヒック処理部４６１により、呼処理を監視するなどして、トラヒックデータ（単位時間当たりの発着信数）を収集する（処理１２０１）。その監視、収集タイミングは、例えば、定期的（周期的）なタイミングとすることができる。

輻輳検知処理部４６２は、トラヒック処理部４６１にて収集された前記トラヒックデータと、グループ＃ｋ別の所定の閾値（輻輳発生閾値）とを比較して、輻輳状態を確認する（処理１２０２〜処理１２０４）。

ここで、輻輳発生閾値は、既述の故障閾値と同様に、ＦＢＴＳ４０−ｊのグループ＃ｋ別に設定することが可能である。例えば、前記グループ分けを設置エリア別に行ない、ＦＢＴＳ４０−ｊがホームユーザ向けに各家庭に設置されているような場合、一部のＦＢＴＳ４０−ｊが輻輳状態となったからといってそのＦＢＴＳ４０−ｊの属するグループ＃ｋ全体が輻輳状態となる確率は低いと考えられる。そこで、輻輳発生閾値は、高めに設定することができる。

これに対して、ＦＢＴＳ４０−ｊが例えば繁華街やオフィス街、公共施設などの不特定ユーザによる利用が想定されるような場所に設置されており、そのエリアでお祭りなどのイベントが開催されて不特定多数のユーザが密集しているような場合には、同じエリア（グループ＃ｋ）に属する一部のＦＢＴＳ４０−ｊが輻輳状態となれば、他のＦＢＴＳ４０−ｊも輻輳状態となる確率が高いと考えられる。そこで、輻輳発生閾値は、低めに設定することができる。

輻輳検知処理部４６２は、このような閾値比較の結果、トラヒック量が輻輳発生閾値以上であり、輻輳発生と判断した場合、ノード間ＩＦ４１経由でＦＢＴＳ制御装置３０−ｉに輻輳発生の旨を通知する（処理１２０５〜処理１２０７）。この通知は、例えば既存ＢＴＳとＲＮＣ２０との間の通信に用いられる既存の信号フォーマットを用いて行なうことができる。

当該通知は、ＦＢＴＳ制御装置３０−ｉのノード間ＩＦ３５で受信され、輻輳検知処理部３６２に転送される（図１４の処理１２０８、図１５の処理１２２１）。輻輳検知処理部３６２は、通知された輻輳状態（輻輳発生）をデータ管理部３４の装置別構成データに反映する（図１４の処理１２０９、処理１２１０、図１５の処理１２２２）。その一例を次表５に示す。

この表５では、例示的に、グループ＃１に属するＦＢＴＳ＃１のトラヒック量が１０から１５に更新され、輻輳状態がＯＦＦからＯＮに更新された様子を示している。

また、データ管理部３４は、この更新に伴ってグループ別構成データの内容も更新する。その一例を次表６に示す。

この表６では、例示的に、グループ＃１のトラヒック量が、前記ＦＢＴＳ＃１のトラヒック量の増加（１０→１５）に伴って、２０から２５に更新された様子を示している。

次いで、データ管理部３４は、前記構成データを更新した輻輳状態のグループ番号を輻輳検知処理部３６２に通知し（図１４の処理１２１１及び処理１２１２）、輻輳検知処理部３６２は、データ管理部３４から通知されたグループ番号を基に、グループ別構成データを参照して、ＯＰＳ７０への輻輳状態通知の要否を判断する。

すなわち、輻輳検知処理部３６２は、グループ＃ｋ毎に、トラヒック量と輻輳発生閾値とを比較して、トラヒック量が輻輳発生閾値（本例では例えば２５）以上となっているグループ＃ｋの有無をチェックする（図１４の処理１２１３、図１５の処理１２２３）。

その結果、トラヒック量が輻輳発生閾値以上のグループ＃ｋ（本例では、グループ＃１）が存在すれば、輻輳検知処理部３６２は、そのグループ＃ｋに属する各ＦＢＴＳ４０−ｊに対して、発着信の制限を行なうように通知する（図１４の処理１２１４〜処理１２１６、図１５の処理１２２３のＹＥＳルートから処理１２２４）。

この通知を受けたＦＢＴＳ４０−ｊ（輻輳検知処理部４６２）は、配下の無線端末５０との間の通信に関して発着信規制を行なうように呼処理を制御する（図１４の処理１２１７）。

また、ＦＢＴＳ制御装置３０−ｉの輻輳検知処理部３６２は、付加的、あるいは、代替的に、ＯＰＳ７０に対して、輻輳が発生したと判断したグループ＃ｋの輻輳状態を通知する（図１４の処理１２１８及び処理１２１９、図１５の処理１２２４〜処理１２２６）。その際、輻輳検知処理部３６２は、グループ番号＃ｋに対応するエリア情報を併せて通知することができる。

エリア情報は、例えば、既存ＢＴＳに通知可能な単位として、キャリア／セクタ単位に対応付けた単位とすることができる。このエリア情報については、例えばデータ管理部３４において、局データに含めて管理することができ、装置起動／再開時や局データ更新時に、局データから構成データに反映させることができる。

なお、前記の閾値比較処理１２２３（図１５）において、トラヒック量が輻輳発生閾値未満であった場合、輻輳検知処理部３６２は、他の輻輳状態通知の受信待機状態となる（処理１２２３のＮＯルート）。

つまり、輻輳検知処理部３６２は、グループ＃ｋ別のトラヒック量が輻輳発生閾値以上でない限り、そのグループ＃ｋとしては輻輳状態にない（輻輳未発生）と判断して、当該グループ＃ｋについての発着信規制やＯＰＳ７０への輻輳状態の通知は行なわない。これにより、ＦＢＴＳ４０−ｊに対する発着信規制の制御負荷や、個々のＦＢＴＳ４０−ｊの輻輳状態のＯＰＳ７０への通知量を削減することが可能となる。したがって、ＦＢＴＳ制御装置３０−ｉ、ＲＮＣ２０、ＯＰＳ７０の処理負荷を低減することが可能である。

また、ＦＢＴＳ４０−ｊの輻輳状態が復旧した場合は、その旨がＦＢＴＳ制御装置３０−ｉに通知され、輻輳発生の場合と同様に、装置別構成データ、グループ別構成データが更新され、グループ＃ｋ別の輻輳復旧閾値との比較により、グループ＃ｋ毎に輻輳状態の復旧が判断される。輻輳状態が復旧したグループ＃ｋについては、その旨を当該グループ＃ｋに属するＦＢＴＳ４０−ｊと、ＯＰＳ７０と、に通知することができる。また、そのグループ＃ｋについての前記発着信規制を解除することもできる。

（３．２．２）第２の方法（ＦＢＴＳ制御装置にて輻輳状態を検出）
次に、第２の方法の一例として、ＦＢＴＳ制御装置３０−ｉが、配下のＦＢＴＳ４０−１（＃１）から通知されたトラヒック量によってグループ＃１に輻輳が発生したと判断した場合について、図１６及び図１７を用いて説明する。

図１６に例示するように、ＦＢＴＳ４０−１は、トラヒック処理部４６１にて、トラヒックデータを収集し、収集したトラヒックデータをノード間ＩＦ４１経由でＦＢＴＳ制御装置３０−ｉに通知する（処理１３０１〜処理１３０３）。トラヒックデータの収集、通知タイミングは、周期的なタイミングとすることができる。

前記通知は、ＦＢＴＳ制御装置３０−ｉのノード間ＩＦ３５にて受信され、トラヒック処理部３６１に転送される（処理１３０４、図１７の処理１３３１）。トラヒック処理部３６１は、通知されたトラヒックデータをデータ管理部３４の装置別構成データに反映する（図１６の処理１３０５、図１７の処理１３３２）。その一例を次表７に示す。

この表７では、例示的に、グループ＃１に属するＦＢＴＳ＃２のトラヒック量が１０から１５に更新された様子を示している。

また、データ管理部３４は、この更新に伴い、グループ別構成データも更新する。その一例を次表８に示す。

この表８では、例示的に、グループ＃１のトラヒック量が、前記ＦＢＴＳ＃２のトラヒック量の増加（１０→１５）に伴って、２０から２５に更新された様子を示している。

トラヒック処理部３６１は、前記更新があったことを輻輳検知処理部３６２に通知し（図１６の処理１３０６）、輻輳検知処理部３６２は、データ管理部３４のグループ別構成データから前記更新されたグループ番号及びトラヒック量と、輻輳発生閾値と、を取得する（図１６の処理１３０６〜処理１３１０）。

そして、輻輳検知処理部３６２は、取得したグループ＃ｋ（本例ではｋ＝１）のトラヒック量と、輻輳発生閾値とを比較して、トラヒック量が輻輳発生閾値（本例では例えば２５）以上か否かをチェックする（図１６の処理１３１１、図１７の処理１３３３）。その結果、グループ＃１のトラヒック量が輻輳発生閾値以上であれば、輻輳検知処理部３６２は、グループ＃１に輻輳が発生したと判断し、そのグループ＃１に属する各ＦＢＴＳ４０−ｊ（本例では、例えばＦＢＴＳ＃１及び＃２）に対して、発着信規制を行なうように通知する（図１６の処理１３１２〜処理１３１４、処理１３１６〜処理１３１９、図１７の処理１３３３のＹＥＳルートから処理１３３４）。

この通知を受けたグループ＃１に属する各ＦＢＴＳ＃１及び＃２（輻輳検知処理部４６２）は、配下の無線端末５０との間の通信に関して発着信規制を行なうように呼処理を制御する（図１６の処理１３１５及び処理１３２０）。

また、ＦＢＴＳ制御装置３０−ｉの輻輳検知処理部３６２は、付加的、あるいは、代替的に、ＯＰＳ７０に対して、輻輳が発生したと判断したグループ＃１の輻輳状態を通知する（図１６の処理１３２１及び処理１３２２、図１７の処理１３３５及び処理１３３６）。その際、輻輳検知処理部３６２は、グループ＃１に対応するエリア情報を併せて通知することができる。

さらに、輻輳検知処理部３６２は、装置別構成データのグループ＃１に属するＦＢＴＳ＃１及び＃２の輻輳状態をそれぞれＯＮに更新する。その一例を次表９に示す。

なお、前記の閾値判定処理１３３３において、グループ＃ｋ別のトラヒック量が輻輳発生閾値未満であった場合、輻輳検知処理部３６２は、そのグループ＃ｋについては輻輳未発生と判断して、他のトラヒックデータの受信待機状態となる（処理１３３３のＮＯルート）。

つまり、トラヒック量が輻輳発生閾値未満のグループ＃ｋについては、一部のＦＢＴＳ４０−ｊが輻輳状態となっていても、グループ＃ｋとしては輻輳未発生と判断する。これにより、個々のＦＢＴＳ４０−ｊについての輻輳状態のＯＰＳ７０への通知量を削減することが可能となる。したがって、ＦＢＴＳ制御装置３０−ｉ、ＲＮＣ２０、ＯＰＳ７０の処理負荷を低減することが可能である。

（３．３）ファイル操作
次に、ＦＢＴＳ制御装置３０−ｉやＦＢＴＳ４０−ｊが保有する、局データや構成データ、プログラムファイル、設定ファイルなどの各種データやファイルに対するファイル操作を行なう処理について説明する。

ＦＢＴＳ４０−ｊやＦＢＴＳ制御装置３０−ｉで使用する局データや構成データ、プログラムファイル、設定ファイルなど（以下、単に「ファイル」と総称する）は、例えばＯＰＳ７０やＣＮ１０内のファイルサーバなどにマスタファイルが保持されている。

これらのファイルに変更があった場合に、ＯＰＳ７０やＣＮ１０側からのオペレーションにより更新のあった各ファイルをダウンロードして更新したり、ＣＮ１０側からのオペレーションがなくても各ファイルのダウンロードと更新とを自律的に行なったりする機能がファイル操作機能である。各ファイルの更新にあたっては、ＦＢＴＳ４０−ｊ同士やＦＢＴＳ４０−ｊとＦＢＴＳ制御装置３０−ｉとで同期をとることが望ましい。

そこで、本例では、一例として、ＦＢＴＳ制御装置３０−ｉについてはファイル操作処理部３６４、ＦＢＴＳ４０−ｊについてはファイル操作処理部４６４にて、それぞれ上記のようなファイル操作を可能とする。なお、以下の説明では、一例として、マスタファイルはＣＮ１０に存在するファイルサーバに保持されていると仮定する。

（３．３．１）ＣＮ１０側からのオペレーションによるファイル更新
まず、ＣＮ１０側からのオペレーションによるファイル更新の一例について、図１８〜図２１を用いて説明する。ファイル更新対象は、ＦＢＴＳ制御装置３０−ｉの場合と、その配下のＦＢＴＳ４０−ｊの場合と、が含まれ、それぞれ項目別に説明する。

（３．３．１．１）ＦＢＴＳ制御装置３０−ｉのファイル更新処理
ＦＢＴＳ制御装置３０−ｉは、ＣＮ１０側からのオペレーションによりファイルダウンロードを行なう。ファイルは、ＲＮＣ間ＩＦ３１を経由してファイル操作処理部３６４にて受信され、データ管理部３４に転送される（図１８の処理１４０１〜処理１４０３、図２０の処理１４６１）。データ管理部３４は、前記転送されたファイルを格納し、格納が完了したらファイル操作処理部３６４にその旨を通知する（図１８の処理１４０４及び処理１４０５）。

ファイル操作処理部３６４は、前記格納完了通知をデータ管理部３４から受けると、ダウンロード完了の旨をＣＮ１０（ファイルサーバ）へ通知する（図１８の処理１４０６〜処理１４０８）。

その後、ＣＮ１０（ファイルサーバ）からファイル更新指示がＲＮＣ間ＩＦ３１経由でファイル操作処理部３６４にて受信されると（図１８の処理１４０９及び処理１４１０）、ファイル操作処理部３６４は、前記ダウンロードしたファイルが、ＦＢＴＳ制御装置３０−ｉ向けのファイルであるか、ＦＢＴＳ４０−ｊ向けのファイルであるかを判別する（図１８の処理１４１１、図２０の処理１４６２）。この判別は、例えば図２１に示すような、ファイルヘッダに示される情報（ファイル名＋ファイル識別子）を基にして行なうことができる。

例えば、ファイルヘッダに示される情報が「xxxxxyyy.XYZ」である場合、ファイル名“xxxxxyyy”のうち、“xxxxx”の部分で上位装置の番号を表し、“yyy”の部分でＦＢＴＳ制御装置３０−ｉまたはＦＢＴＳ４０−ｊの装置番号を表すこととすることができる。したがって、この例では、ファイル操作処理部３６４は、“yyy”の部分を参照することで、前記判別を行なうことができる。

なお、ファイル名に続く“.XYZ”は、ファイル識別子であり、例えば、Xで装置種別、Yで装置型番、Zでメーカ種別を表すものとすることができる。一例として、X＝Bなら既存ＢＴＳ、X＝CならＦＢＴＳ制御装置３０−ｉの局データ、X＝DならＦＢＴＳ４０−ｊの局データ、X＝EならＦＢＴＳ制御装置３０−ｉのプログラム、X＝FならＦＢＴＳ４０−ｊのプログラム、をそれぞれ表すものとすることができる。また、Y＝１なら最新型の装置、Y＝2なら旧型の装置などを表すものとすることができる。さらに、Z＝Fならメーカ種別が富士通（FUJITSU）であることを表すことができる。

さて、上記の判別の結果、例えば、ダウンロードしたファイルがＦＢＴＳ制御装置３０−ｉ向けのファイルであった場合、ファイル操作処理部３６４は、データ管理部３４に対してファイル更新の実行を通知する（図１８の処理１４１２及び処理１４１３）。この通知を受けたデータ管理部３４は、ファイルの更新を実行し（図２０の処理１４６３）、完了したらファイル操作処理部３６４に対して完了の旨を通知する（図１８の処理１４１４及び処理１４１５）。

なお、前記ファイル更新を実行した段階では、更新前のファイルも保持されており、後述するファイル切替の実行により、使用すべきファイルが更新前のものから更新後のもの変更される。したがって、更新後のファイルに不具合等が存在する場合には、適宜、使用すべきファイルを更新前のファイルに戻すこともできる。ただし、前記ファイル更新を実行することにより更新前のファイルを上書きすることを排除するものではない。これらの点は、以降の説明においても同様である。

ファイル更新の完了通知を受けたファイル操作処理部３６４は、ファイル切替を実行し、完了したら更新結果通知用のデータ（メッセージ）を生成して、ＣＮ１０（ファイルサーバ）宛に送信することで、ファイル更新の完了を通知する（図１８の処理１４１６〜処理１４１８、図２０の処理１４６７及び処理１４６８）。

（３．３．１．２）ＦＢＴＳのファイル更新処理
一方、前記のファイルダウンロード後の判別処理１４６２（図２０）において、ダウンロードしたファイルがＦＢＴＳ４０−ｊ向けのファイルであった場合、ファイル操作処理部３６４は、前記ファイルヘッダの情報を基に、更新対象の装置メーカ種別、装置型番などを判別し、該当のＦＢＴＳ４０−ｊ宛にダウンロードしたファイルを転送する（図１９の処理１４３２〜処理１４３４、図２０の処理１４６４）。

前記転送されたファイルは、ＦＢＴＳ４０−ｊのノード間ＩＦ４１にて受信され、ファイル操作処理部４６４に転送される（図１９の処理１４３４及び処理１４３５）。ファイル操作処理部４６４は、受信したファイルの前記ファイルヘッダの情報を基に、受信ファイルが自局（ＦＢＴＳ４０−ｊ）用のファイルであることを判別する（図１９の処理１４３６）。

そして、ファイル操作処理部４６４は、データ管理部４５に対して、自局４０−ｊ用のファイル更新を通知（指示）し（図１９の処理１４３７及び処理１４３８）、この通知を受けたデータ管理部３４は、ＦＢＴＳ制御装置３０−ｉから受信した前記ファイルによりファイル更新を実行し、完了したらその旨をファイル操作処理部４６４へ通知する（図１９の処理１４３９及び１４４０、図２０の処理１４６５）。

ファイル操作処理部４６４は、前記ファイル更新の完了通知を受けると、ファイル更新完了の旨をＦＢＴＳ制御装置３０−ｉに通知する（図１９の処理１４４１〜処理１４４３、図２０の処理１４６６）。

ＦＢＴＳ制御装置３０−ｉは、ＦＢＴＳ４０−ｊから前記ファイル更新の完了通知をファイル操作処理部３６４にて受けると（図１９の処理１４４４）、ファイル切替の同期をとるために、該当のＦＢＴＳ４０−ｊのファイル更新が全て完了したかを判断し、全て完了していれば、配下の各ＦＢＴＳ４０−ｊに対してファイル切替を指示する（図１９の処理１４４５〜処理１４４７）。

ＦＢＴＳ４０−ｊは、前記ファイル切替の指示をノード間ＩＦ４１経由でファイル操作処理部４６４にて受信すると（図１９の処理１４４８）、ファイル操作処理部４６４によって、ファイル切替を実施し、完了したらＦＢＴＳ制御装置３０−ｉに通知する（図１９の処理１４４９〜処理１４５１）。

ＦＢＴＳ制御装置３０−ｉは、前記ファイル切替の完了通知をＦＢＴＳ４０−ｊからノード間ＩＦ３５経由でファイル操作処理部３６４にて受信すると（図１９の処理１４５２）、ファイル操作処理部３６４にて、該当のＦＢＴＳ４０−ｊのファイル切替が全て完了したかを判断し、全て完了していればＣＮ１０（ファイルサーバ）にファイル更新の完了を通知する（図１９の処理１４５３〜処理１４５５、図２０の処理１４６７及び処理１４６８）。

（３．３．２）自律的なファイル更新
次に、ＦＢＴＳ制御装置３０−ｉ、ＦＢＴＳ４０−ｊが自律的にファイル更新する動作例について、図２２〜図２５を用いて説明する。自律的なファイル更新においても、ファイル更新対象は、ＦＢＴＳ制御装置３０−ｉの場合と、その配下のＦＢＴＳ４０−ｊの場合と、があるから、それぞれ項目別に説明する。

（３．３．２．１）ＦＢＴＳ制御装置３０−ｉのファイル更新処理
図２２に例示するように、ＦＢＴＳ制御装置３０−ｉのファイル操作処理部３６４は、あるタイミングでファイルバージョンの確認要求（問い合わせ）をＣＮ１０（ファイルサーバ）へ送信し（処理１５０１及び処理１５０２、図２５の処理１５６１）、その問い合わせに対する応答（ファイルバージョン通知）を受信する（図２２の処理１５０３及び処理１５０４）。

図２３に、ファイルバージョン通知（メッセージ）のフォーマット例を示す。この図２３に示すメッセージは、ＩＰパケットである場合を例示しており、ＩＰヘッダフィールドと、繰り返し数フィールドと、データ部と、を有する。データ部には、ファイル識別子（.CEF等）とファイルバージョン（V01L02等）との組み合わせを、繰り返し設定することができる。繰り返し設定した数が前記「繰り返し数」フィールドに設定される。ＩＰヘッダフィールドには、当該メッセージの宛先ＩＰアドレス及び送信元ＩＰアドレス等が設定される。

ファイル操作処理部３６４は、受信したファイルバージョン通知の内容をデータ管理部３４に通知する（図２２の処理１５０５及び処理１５０６）。この通知を受けたファイル管理部３４は、現在管理している各ファイルのバージョンと、通知されたファイルバージョン通知の内容と、を比較して、差分の有無をチェックし（図２５の処理１５６２）、その結果をファイル操作処理部３６４に通知する（図２２の処理１５０７及び処理１５０８）。
次表１０に、ＦＢＴＳ制御装置３０−ｉのデータ管理部３４で管理しているバージョン情報の一例を示す。なお、ファイル識別子の意味は、先に例示したとおりである。

ファイル操作処理部３６４は、差分が１つも無ければ処理を終了し（図２５の処理１５６２のＮＯルートから処理１５６３）、差分が有れば、ファイルダウンロード要求をＣＮ１０（ファイルサーバ）に送信して（図２２の処理１５０９及び処理１５１０）、ＣＮ１０からファイルダウンロードを行なう（図２２の処理１５１１及び処理１５１２、図２５の処理１５６２のＹＥＳルートから処理１５６４）。なお、ダウンロードするファイルは、差分のみでもよいし、差分を含むファイルの全部又は一部でもよい。

そして、ファイル操作処理部３６４は、ダウンロードしたファイルをデータ管理部３４へ転送し（図２２の処理１５１３）、データ管理部３４は、転送されたファイルを格納し、格納が完了したら、ファイル操作処理部３６４にその旨を通知する（図２２の処理１５１４及び処理１５１５）。

ファイル操作処理部３６４は、前記ファイル格納の完了通知を受けると、ダウンロード完了をＣＮ１０（ファイルサーバ）へ通知する（図２２の処理１５１６〜処理１５１８）。

その後、ＣＮ１０（ファイルサーバ）からファイル更新指示があると（図２２の処理１５１９及び処理１５２０）、ファイル操作処理部３６４は、前記ダウンロードしたファイルが、ＦＢＴＳ制御装置３０−ｉ向けのファイルか、配下のＦＢＴＳ４０−ｊ向けのファイルかを、ダウンロードしたファイルのファイルヘッダの情報を基に判別する（図２２の処理１５２１、図２５の処理１５６５）。

その結果、ダウンロードしたファイルが、ＦＢＴＳ制御装置３０−ｉ向けのファイルであれば、ファイル操作処理部３６４は、データ管理部３４に対してファイル更新の実行を通知（指示）する（図２２の処理１５２２及び処理１５２３）。

データ管理部３４は、前記ファイル更新指示を受けると、ダウンロードした前記ファイルにより前記差分が無くなるようにファイルの更新を実行し（図２５の処理１５６６）、完了したらファイル操作処理部３６４へその旨を通知する（図２２の処理１５２４及び処理１５２５）。

ファイル操作処理部３６４は、前記ファイル更新の完了通知を受けると、ファイル切替を実施し、完了したら更新結果通知用のデータ（メッセージ）を生成して、ＣＮ１０（ファイルサーバ）宛に送信することで、ファイル更新の完了を通知する（図２２の処理１５２６〜処理１５２８、図２５の処理１５７０及び処理１５７１）。

（３．３．２．２）ＦＢＴＳ４０−ｊのファイル更新処理
一方、前記の判別処理１５６５（図２５）において、ダウンロードしたファイルがＦＢＴＳ４０−ｊ向けのファイルであった場合、ファイル操作処理部３６４は、更新対象の装置メーカ種別、装置型番などを、ダウンロードしたファイルのファイルヘッダの情報を基に判別し（図２４の処理１５３１）、該当のＦＢＴＳ４０−ｊ宛にダウンロードしたファイルを転送する（図２４の処理１５３２〜処理１５３４、図２５の処理１５６７）。

ＦＢＴＳ４０−ｊでは、前記転送されたファイルがノード間ＩＦ４１経由でファイル操作処理部４６４にて受信される（図２４の処理１５３４及び処理１５３５）。ファイル操作処理部４６４は、受信したファイルのファイルヘッダの情報を基に、当該受信ファイルが自局（ＦＢＴＳ）４０−ｊ用のファイルであることを判別する（図２４の処理１５３６）。

そして、ファイル操作処理部４６４は、データ管理部４５に対して自局４０−ｊのファイル更新を通知する（図２４の処理１５３７及び処理１５３８）。この通知を受けたデータ管理部４５は、ＦＢＴＳ制御装置３０−ｉから受信した前記ファイルによりファイル更新を実行し（図２５の処理１５６８）、完了したらその旨をファイル操作処理部４６４へ通知する（図２４の処理１５３９及び処理１５４０）。

ファイル更新の完了通知を受けたファイル操作処理部４６４は、ファイル更新完了の旨をＦＢＴＳ制御装置３０−ｉへ通知する（図２４の処理１５４１〜処理１５４３、図２５の処理１５６９）。

ＦＢＴＳ制御装置３０−ｉは、前記ファイル更新の完了通知をノード間ＩＦ３５経由でファイル操作処理部３６４にて受信すると（図２４の処理１５４４）、ファイル切替の同期をとるために、ファイル操作処理部３６４において、該当のＦＢＴＳ４０−ｊのファイル更新が全て完了したかを判断する。全て完了していれば、ファイル操作処理部３６４は、各ＦＢＴＳ４０−ｊに対してファイル切替の指示を行なう（図２４の処理１５４５〜処理１５４７）。

ＦＢＴＳ４０−ｊは、前記ファイル切替の指示をノード間ＩＦ４１経由でファイル操作処理部４６４にて受信すると（図２４の処理１５４８）、ファイル操作処理部４６４によってファイル切替を実施し、完了したらその旨をＦＢＴＳ制御装置３０−ｉに通知する（図２４の処理１５４９〜処理１５５１）。

ＦＢＴＳ制御装置３０−ｉは、前記ファイル切替の完了通知をノード間ＩＦ３５経由でファイル操作処理部３６４にて受信すると（図２４の処理１５５２）、ファイル操作処理部３６４において、該当のＦＢＴＳ４０−ｊのファイル切替が全て完了したかを判断する。全て完了していれば、ファイル操作処理部３６４は、更新結果通知用のデータ（メッセージ）を生成して、ＣＮ１０（ファイルサーバ）宛に送信することで、ファイル更新の完了を通知する（図２４の処理１５５３〜処理１５５５、図２５の処理１５７０及び処理１５７１）。

（３．３．３）ＦＢＴＳのグループ単位のファイル更新
次に、既述のグループ＃ｋ単位で、ＦＢＴＳ４０−ｊのファイル更新を行なう場合の動作例について、図２６〜図２８を用いて説明する。

図２６に例示するように、ＦＢＴＳ制御装置３０−ｉは、例えば、ＣＮ１０（ファイルサーバ）側からのオペレーションによりファイルダウンロードを行なう。ファイルは、ＲＮＣ間ＩＦ３１を経由してファイル操作処理部３６４にて受信され、データ管理部３４に転送される（図２６の処理１６０１〜処理１６０３、図２７の処理１６４１）。データ管理部３４は、前記転送されたファイルを格納し、格納が完了したらファイル操作処理部３６４にその旨を通知する（図２６の処理１６０４及び処理１６０５）。

ファイル操作処理部３６４は、前記格納完了通知をデータ管理部３４から受けると、ダウンロード完了の旨をＣＮ１０（ファイルサーバ）へ通知する（図２６の処理１６０６〜処理１６０８）。

その後、ＣＮ１０（ファイルサーバ）からファイル更新指示がＲＮＣ間ＩＦ３１経由でファイル操作処理部３６４にて受信されると（図２６の処理１６０９及び処理１６１０）、ファイル操作処理部３６４は、前記ダウンロードしたファイルが、ＦＢＴＳ４０−ｊ向けで、かつ、グループ指定されたファイルであるかを、ファイルヘッダの情報及び前記ファイル更新指示の内容を基に判別する（図２６の処理１６１１、図２７の処理１６４２）。

前記ファイル更新指示（メッセージ）には、既存のファイル更新指示に用いられるメッセージフォーマットを用いることができる。そのフォーマット例を図２８に示す。この図２８に例示するフォーマットは、ヘッダフィールドと、ＢＴＳ番号フィールドと、ファイル名フィールドと、を有する。ＢＴＳ番号フィールドには、既存ＢＴＳの装置番号に代えて、ＢＴＳ種別を表す情報に相当する、ＦＢＴＳ制御装置３０−ｉの装置番号を設定することができる。また、ファイル名フィールドには、ファイル名に代えて、ＦＢＴＳ４０−ｊのグループ番号を設定することができる。

したがって、ファイル操作処理部３６４は、例えば、ＢＴＳ番号フィールドに、ＦＢＴＳ制御装置３０−ｉの装置番号が設定されており、かつ、ファイル名フィールドに、ＦＢＴＳ４０−ｊのグループ番号が設定されていなければ、受信したメッセージが、ＦＢＴＳ制御装置３０−ｉに対するファイル更新指示であると判断することができる。

その場合、ファイル操作処理部３６４は、例えば図１８に例示した処理１４１２〜処理１４１８と同様にして、データ管理部３４で保持するファイルをダウンロードしたファイルによって更新して、更新完了をＣＮ１０（ファイルサーバ）へ通知する（図２７の処理１６４２のＮＯルートから処理１６４３，処理１６４７及び処理１６４８）。

一方、例えば、ＢＴＳ番号フィールドに、ＦＢＴＳ制御装置３０−ｉの装置番号が設定されておらず、かつ、ファイル名フィールドに、ＦＢＴＳ４０−ｊのグループ番号が設定されていれば、ファイル操作処理部３６４は、受信したメッセージが、指定されたグループ＃ｋに属する各ＦＢＴＳ４０−ｊに対するファイル更新指示であると判断する。

その場合、ファイル操作処理部３６４は、更新対象の装置メーカ種別、装置型番などを前記ファイルヘッダの情報を基に判別し、指定されたグループ＃ｋに属するＦＢＴＳ４０−ｊ宛にダウンロードした前記ファイルを転送する（図２６の処理１６１２〜処理１６１４、図２７の処理１６４２のＹＥＳルートから処理１６４４）。

前記転送されたファイルは、ＦＢＴＳ４０−ｊのノード間ＩＦ４１にて受信され、ファイル操作処理部４６４に転送される（図２６の処理１６１４及び処理１６１５）。ファイル操作処理部４６４は、受信したファイルの前記ファイルヘッダの情報を基に、受信ファイルが自局（ＦＢＴＳ４０−ｊ）用のファイルであることを判別する（図２６の処理１６１６）。

そして、ファイル操作処理部４６４は、データ管理部４５に対して、自局４０−ｊ用のファイル更新を通知（指示）し（図２６の処理１６１７及び処理１６１８）、この通知を受けたデータ管理部３４は、ＦＢＴＳ制御装置３０−ｉから受信した前記ファイルによりファイル更新を実行し、完了したらその旨をファイル操作処理部４６４へ通知する（図２６の処理１６１９及び１６２０、図２７の処理１６４５）。

ファイル操作処理部４６４は、前記ファイル更新の完了通知を受けると、ファイル更新完了の旨をＦＢＴＳ制御装置３０−ｉに通知する（図２６の処理１６２１〜処理１６２３、図２７の処理１６４６）。

ＦＢＴＳ制御装置３０−ｉは、ＦＢＴＳ４０−ｊから前記ファイル更新の完了通知をファイル操作処理部３６４にて受けると（図２６の処理１６２４）、ファイル切替の同期をとるために、指定グループ＃ｋに属するＦＢＴＳ４０−ｊのファイル更新が全て完了したかを判断し、全て完了していれば、当該グループ＃ｋに属する各ＦＢＴＳ４０−ｊに対してファイル切替を指示する（図２６の処理１６２５〜処理１６２７）。

ＦＢＴＳ４０−ｊは、前記ファイル切替の指示をノード間ＩＦ４１経由でファイル操作処理部４６４にて受信すると（図２６の処理１６２８）、ファイル操作処理部４６４によって、ファイル切替を実施し、完了したらＦＢＴＳ制御装置３０−ｉに通知する（図２６の処理１６２９〜処理１６３１、図２７の処理１６４６）。

ＦＢＴＳ制御装置３０−ｉは、前記ファイル切替の完了通知をＦＢＴＳ４０−ｊからノード間ＩＦ３５経由でファイル操作処理部３６４にて受信すると（図２６の処理１６３２）、ファイル操作処理部３６４にて、該当のＦＢＴＳ４０−ｊのファイル切替が全て完了したかを判断し、全て完了していればＣＮ１０（ファイルサーバ）にファイル更新の完了を通知する（図２６の処理１６３３〜処理１６３５、図２７の処理１６４７及び処理１６４８）。

なお、以上のようなグループ指定によるファイル更新は、例えば、工事エリアでの試験運用のため、ファイル更新を実施する場合、該当工事エリアをグループとすることにより、該当エリア（あるグループ）の全ＦＢＴＳ４０−ｊに対して一括して実施することなどが想定できる。

また、上述した例は、ＣＮ１０（ファイルサーバ）からのオペレーションによるグループ単位のファイル更新の一例であるが、項目（３．３．２．２）で説明したような、自律的なグループ単位のファイル更新を実施することも可能である。

（３．３．４）グループ単位でのバージョン情報通知
次に、ＦＢＴＳ制御装置３０−ｉが、配下のＦＢＴＳ４０−ｊが保持するファイルのファイルバージョンをグループ＃ｋ別に管理し、ＯＰＳ７０へ通知する動作例について、図２９及び図３０を用いて説明する。

図２９に例示するように、ＦＢＴＳ制御装置３０−ｉでは、ファイル操作処理部３６４によって、配下のＦＢＴＳ４０−ｊが保持しているファイルのファイルバージョンを収集する（処理１７０１）。この収集は、例えば、既述のファイル更新処理毎に行なっておくことができる。

ファイル操作処理部３６４は、収集したファイルバージョンをデータ管理部３４に通知する（処理１７０２）。この通知を受けたデータ管理部３４は、通知されたファイルバージョンを装置別構成データの要素情報として保持（更新）する（処理１７０３）。この保持も、例えば、既述のファイル更新処理毎に行なっておくことができる。その一例を、次表１１に示す。

この表１１では、例示的に、ファイル識別子（ハード版数）が「.CEF」、「.DEF」、「.EEF」である各ファイルの最新ファイルバージョンが「V02L00」であるとして、ＦＢＴＳ＃２，＃４，＃５は、いずれも最新のファイルバージョン（V02L00）のファイルを保持しており、ＦＢＴＳ＃１，＃３は、最新でないファイルバージョン（V01L00）のファイルを保持していることを表している。

データ管理部３４は、このような装置別構成データを基に、グループ＃ｋ毎のファイルバージョンの更新率を求め、グループ別構成データを更新する（処理１７０４）。上記の表１１の例であれば、グループ＃１に属する３台のＦＢＴＳ＃１，＃２，＃３のうち、ファイルバージョンが最新（V02L00）のものは１台であるから、更新率は１／３となる。同様に、グループ＃２に属する２台のＦＢＴＳ＃４，＃５については、いずれもファイルバージョンが最新であるから、更新率は２／２となる。

そして、例えば次表１２に示すように、グループ別構成データを更新する。

ここで、更新率閾値は、グループ＃ｋ別に設定することができ、ファイルバージョンの更新状況の要否をグループ別に判断することができる。すなわち、前記更新率が当該閾値以下のグループ＃ｋについて、ファイル更新が必要であり、また、ＯＰＳ７０にファイル更新状況を通知する必要があると判断することができる。換言すれば、グループ＃ｋについての前記更新率が前記更新率閾値以下でない限り、そのグループ＃ｋについてのファイル更新や更新状況のＯＰＳ７０への通知は不要と判断することができる。

ファイル操作処理部３６４は、所定の監視タイミング（周期的なタイミングなど）が到来すると、前記グループ別構成データを参照して（図２９の処理１７０５）、各グループ＃ｋの更新率と更新率閾値とを比較して、更新率閾値以下となっているグループ＃ｋが存在するか否かをチェックする（図３０の処理１７１１及び処理１７１２）。

その結果、更新率が更新率閾値以下となっているグループ＃ｋが存在すれば（図３０の処理１７１２でＹＥＳであれば）、ファイル操作処理部３６４は、そのグループ＃ｋに属するＦＢＴＳ４０−ｊにおけるファイルのファイルバージョンを最新のものに更新させる。その後、ファイル操作処理部３６４は、更新状況報告用のデータ（メッセージ）を生成してＯＰＳ７０宛に送信することで、ファイル更新状況をＯＰＳ７０に通知する（図２９の処理１７０６〜処理１７０８、図３０の処理１７１３及び処理１７１４）。

なお、更新率が更新率閾値以下となっているグループ＃ｋが存在しない場合（図３０の処理１７１２でＮＯの場合）は、ファイル操作処理部３６４は、次の監視タイミングが到来するまで処理を待機する。

以上のような処理によって、例えば、既述の自律的なファイル更新処理で更新が漏れている場合に、ＯＰＳ７０（オペレータ）にファイル更新を行なうように促すことが可能となる。その際、個々のＦＢＴＳ４０−ｊのファイル更新状況を定期的に報告すると、信号量が増加するため、グループ単位で報告することもできる。

〔４〕一実施形態の効果
上述した実施形態によれば、次のような効果ないし利点が選択的あるいは追加的に（組み合わせとして）得られる。

（１）ＦＢＴＳ４０−ｊ（障害監視処理部４６３）で自律的に自装置の障害（故障）を検出することができる。また、該当故障情報をＦＢＴＳ制御装置３０−ｉへ通知することができる。

（２）ＦＢＴＳ４０−ｊ（トラヒック処理部３６１）で自装置のトラヒック状態を監視して自律的に自装置の輻輳状態を検知することできる。また、輻輳状態の発生を検知した場合に、自律的に発着信規制を実施することができる。さらに、輻輳状態をＦＢＴＳ制御装置３０−ｉへ通知することができる。

（３）ＦＢＴＳ制御装置３０−ｉのファイル操作処理部３６４およびＦＢＴＳ４０−ｊのファイル操作処理部４６４によって、ＦＢＴＳ４０−ｊの各種ファイルをＣＮ１０やＯＰＳ７０側から遠隔的に更新することができる。

（４）ＦＢＴＳ制御装置３０−ｉ（障害監視処理部３６３）でＦＢＴＳ４０−ｊから受信した故障情報を上位のＯＰＳ７０へ通知することができる。

（５）ＦＢＴＳ制御装置３０−ｉ（障害監視処理部３６３）で自装置の故障を自律的に検出することができる。また、該当故障情報を上位のＯＰＳ７０へ通知することができる。

（６）ＦＢＴＳ制御装置３０−ｉ（輻輳検知処理部３６２）でＦＢＴＳ４０−ｊの輻輳状態を監視し、その監視結果を上位のＯＰＳ７０へ通知することができる。

（７）ＦＢＴＳ制御装置３０−ｉ（障害監視処理部３６３）でＦＢＴＳ４０−ｊの輻輳状態を監視して、その監視結果を上位のＯＰＳ７０へ通知することができる。また、輻輳状態となったＦＢＴＳ４０−ｊに対して発着信規制を実施することができる。

（８）ＦＢＴＳ制御装置３０−ｉ（輻輳検知処理部３６２）で自装置の故障情報、トラヒック状態を基に輻輳状態を自律的に判別し、配下のＦＢＴＳ４０−ｊに対して発着信規制を実施することができる。また、ＦＢＴＳ制御装置３０−ｉの輻輳状態をＯＰＳ７０へ通知することができる。

（９）ＦＢＴＳ制御装置３０−ｉのファイル操作処理部３６４によって、ＦＢＴＳ制御装置３０−ｉの各種ファイルをＣＮ１０やＯＰＳ７０側から遠隔的に更新することができる。

（１０）上述したＦＢＴＳ制御装置３０−ｉの導入により、ＲＮＣ２０に収容可能な既存ＢＴＳ数に限りがある（例えば１００台程度）としても、ＲＮＣ２０を含む上位のシステムに大規模な改修を加えることなく、数千台単位などの多数のＦＢＴＳ４０−ｊをＲＮＣ２０に収容することができる。したがって、無線カバー率を低コストで容易に拡大することができる。

（１１）上述したＦＢＴＳ制御装置３０−ｉの導入により、ＦＢＴＳ制御装置３０−ｉ及び／又はＦＢＴＳ４０−ｊの障害監視を、ＲＮＣ２０を含む上位のシステムに大規模な改修を加えることなく、容易に行なうことができる。また、ＦＢＴＳ４０−ｊの障害情報の全てを上位装置（ＯＰＳ７０）に通知してしまい監視漏れが生じる確率も下げることができる。したがって、ＦＢＴＳ４０−ｊの全数の監視画面などを制御する必要もない。

（１２）上述したＦＢＴＳ制御装置３０−ｉの導入により、ＦＢＴＳ制御装置３０−ｉ及び／又はＦＢＴＳ４０−ｊの輻輳（トラヒック量）の監視、制御を、ＲＮＣ２０を含む上位のシステムに大規模な改修を加えることなく、容易に行なうことができる。

（１３）上述したＦＢＴＳ制御装置３０−ｉの導入により、ＦＢＴＳ制御装置３０−ｉ及び／又はＦＢＴＳ４０−ｊのファイル操作（更新等）を、ＲＮＣ２０を含む上位のシステムに大規模な改修を加えることなく、容易に行なうことができる。したがって、ＦＢＴＳ４０−ｊが数千台単位で多数存在したとしても、それぞれのプログラムファイル、設定ファイルなどの管理、更新（バージョンアップ等）を低コストで容易に実施することができる。

項目〔１〕〜〔４〕により上述した実施形態に加えて、さらに以下の付記を開示する。

〔５〕付記
（付記１）
複数の無線基地局と、
前記複数の無線基地局を複数のグループにグループ化して、前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する運用管理保守装置と、
をそなえたことを特徴とする、無線通信システム。

（付記２）
複数の無線基地局を複数のグループにグループ化して管理し、
前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する、
ことを特徴とする、運用管理保守方法。

（付記３）
複数の無線基地局を複数のグループにグループ化して管理する管理部と、
前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する処理部と、
をそなえたことを特徴とする、運用管理保守装置。

（付記４）
前記管理部は、
前記無線基地局の障害発生数に関する閾値を前記グループ別に保持し、
前記処理部は、
前記無線基地局の障害の有無を監視し、いずれかの前記グループにおける障害発生数が前記閾値以上である場合に、当該グループに障害が発生したと判断する、ことを特徴とする、付記３記載の運用管理保守装置。

（付記５）
前記処理部は、
前記障害発生数が前記閾値未満である場合には、当該無線基地局グループに障害は発生していないと判断する、ことを特徴とする、付記４記載の運用管理保守装置。

（付記６）
前記処理部は、
前記グループに障害が発生した判断した場合に、前記運用管理保守装置の上位装置へ障害情報を通知する、ことを特徴とする、付記４又は５に記載の運用管理保守装置。

（付記７）
前記処理部は、
前記障害の有無の監視を、前記各無線基地局から障害情報の通知を受けてを行なう、ことを特徴とする、付記４〜６のいずれか１項に記載の運用管理保守装置。

（付記８）
前記処理部は、
前記運用管理保守装置の障害の有無の監視も行ない、その監視結果を前記運用管理保守装置の上位装置へ通知する、ことを特徴とする、付記４〜７のいずれか１項に記載の運用管理保守装置。

（付記９）
前記管理部は、
前記無線基地局の輻輳状態に関する閾値を前記グループ別に保持し、
前記処理部は、
前記無線基地局の輻輳状態を監視し、いずれかの前記グループにおける輻輳状態が前記閾値以上である場合に、当該グループに輻輳が発生したと判断する、ことを特徴とする、付記３記載の運用管理保守装置。

（付記１０）
前記処理部は、
前記輻輳状態が前記閾値未満である場合には、当該グループに輻輳は発生していないと判断する、ことを特徴とする、付記９記載の運用管理保守装置。

（付記１１）
前記処理部は、
前記グループに輻輳が発生したと判断した場合に、その旨を前記運用管理保守装置の上位装置へ通知する、ことを特徴とする、付記９記載の運用管理保守装置。

（付記１２）
前記処理部は、
前記輻輳状態の監視を、前記各無線基地局で検知された輻輳状態の通知を受けて行なう、ことを特徴とする、付記９〜１１のいずれか１項に記載の運用管理保守装置。

（付記１３）
前記処理部は、
前記輻輳状態の監視を、前記各無線基地局で測定された通信トラヒック量の通知を受けて行なう、ことを特徴とする、付記９〜１１のいずれか１項に記載の運用管理保守装置。

（付記１４）
前記処理部は、前記運用管理保守装置の輻輳状態も監視し、その監視結果を前記運用管理保守装置の上位装置へ通知する、ことを特徴とする、付記９〜１３のいずれか１項に記載の運用管理保守装置。

（付記１５）
前記処理部は、
前記輻輳が発生したと判断したグループに属する各無線基地局に対して発着信規制を行なう、ことを特徴とする、付記９〜１４のいずれか１項に記載の運用管理保守装置。

（付記１６）
前記管理部は、
前記無線基地局が保持するファイルの更新率に関する閾値を前記グループ別に保持し、
前記処理部は、
前記無線基地局が保持するファイルの更新率を監視し、いずれかの前記グループにおける前記更新率が前記閾値を超えている場合に、当該グループに属する各無線基地局の前記ファイルの更新を行なう、ことを特徴とする、付記３記載の運用管理保守装置。

（付記１７）
前記処理部は、
前記更新状況が前記閾値以下である場合には、前記ファイルの更新が不要であると判断する、ことを特徴とする、付記１６記載の運用管理保守装置。

（付記１８）
前記処理部は、
前記更新率が前記閾値を超えているグループにおける前記更新率に関する情報を前記運用管理保守装置の上位装置へ通知する、ことを特徴とする、付記１６又は１７に記載の運用管理保守装置。

（付記１９）
前記無線基地局は、それぞれ、フェムトセル基地局である、ことを特徴とする、付記３〜１８のいずれか１項に記載の運用管理保守装置。

（付記２０）
前記グループは、前記無線基地局の設置場所に応じて設定される、ことを特徴とする、付記３〜１９のいずれか１項に記載の運用管理保守装置。

一実施形態に係る無線通信システムの一例としてのフェムトセルシステムの構成例を示す図である。 図１に示すシステムの詳細構成例を示すブロック図である。 図１に示すシステムにおけるＦＢＴＳのグループ化イメージを説明する図である。 図１に示すシステムにおけるＦＢＴＳのグループ化イメージを説明する図である。 図１に示すシステムにおけるＦＢＴＳのグループ化イメージを説明する図である。 図１に示すＦＢＴＳ制御装置で管理するグループ化情報の一例を説明する図である。 図１に示すＦＢＴＳ制御装置で管理するグループ化情報の一例を説明する図である。 図１に示すＦＢＴＳ制御装置からＲＮＣへの障害通知メッセージのフォーマット例を示す図である。 図１に示すシステムにおける障害検知及び障害通知処理の一例を説明するシーケンス図である。 図１に示すシステムにおける障害通知処理の一例を説明するフローチャートである。 図１に示すＯＰＳからＦＢＴＳ制御装置に対する障害状況の問い合わせメッセージのフォーマット例を示す図である。 図１に示すシステムにおける障害情報収集処理の一例を説明するシーケンス図である。 図１に示すシステムにおける障害情報収集処理の一例を説明するフローチャートである。 図１に示すシステムにおける輻輳検知処理の一例を説明するシーケンス図である。 図１に示すシステムにおける輻輳検知処理の一例を説明するフローチャートである。 図１に示すシステムにおける輻輳検知処理の一例を説明するシーケンス図である。 図１に示すシステムにおける輻輳検知処理の一例を説明するフローチャートである。 図１に示すＦＢＴＳ制御装置に対するファイル更新処理の一例を説明するシーケンス図である。 図１に示すＦＢＴＳに対するファイル更新処理の一例を説明するシーケンス図である。 図１に示すシステムにおけるファイル更新処理の一例を説明するフローチャートである。 図１に示すＦＢＴＳ制御装置がダウンロードしたファイルのフォーマット例を示す図である。 図１に示すＦＢＴＳ制御装置に対するファイル更新処理の一例を説明するシーケンス図である。 図１に示すシステムでファイルバージョン通知に用いられる信号フォーマット例を示す図である。 図１に示すＦＢＴＳに対するファイル更新処理の一例を説明するシーケンス図である。 図１に示すシステムにおけるファイル更新処理の一例を説明するフローチャートである。 図１に示すＦＢＴＳに対するグループ単位のファイル更新処理の一例を説明するシーケンス図である。 図１に示すＦＢＴＳに対するグループ単位のファイル更新処理の一例を説明するフローチャートである。 図１に示すＦＢＴＳ制御装置に対するファイル更新指示のフォーマット例を示す図である。 図１に示すシステムにおいてＦＢＴＳのファイルバージョン情報をグループ単位に通知する処理の一例を説明するシーケンス図である。 図１に示すシステムにおいてＦＢＴＳのファイルバージョン情報をグループ単位に通知する処理の一例を説明するフローチャートである。

符号の説明

１０ コアネットワーク（ＣＮ）
２０ ＲＮＣ
３０−１〜３０−Ｎ 超小型ＢＴＳ制御装置（フェムトセルＢＴＳ制御装置；運用管理保守装置）
３１ ＲＮＣ間インタフェース（ＩＦ）
３４ データ管理部
３５ ノード間インタフェース（ＩＦ）
３６ ＯＡＭ制御部
３６０ データ変換部
３６１ トラヒック処理部
３６２ 輻輳検知処理部
３６３ 障害監視処理部
３６４ ファイル操作処理部
４０−１〜４０−ｍ 超小型ＢＴＳ（フェムトセルＢＴＳ）
４１ ノード間インタフェース（ＩＦ）
４５ データ管理部
４６ ＯＡＭ制御部
４６１ トラヒック処理部
４６２ 輻輳検知処理部
４６３ 障害監視処理部
４６４ ファイル操作処理部
５０ 移動端末（無線端末）
６０ 保守用ネットワーク
７０ オペレーションシステム（ＯＰＳ）

Claims (10)

1. 複数の無線基地局と、
   前記複数の無線基地局を複数のグループにグループ化して、前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する運用管理保守装置と、
   をそなえたことを特徴とする、無線通信システム。
2. 複数の無線基地局を複数のグループにグループ化して管理し、
   前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する、
   ことを特徴とする、運用管理保守方法。
3. 複数の無線基地局を複数のグループにグループ化して管理する管理部と、
   前記複数の無線基地局の運用管理保守に関する処理を、前記グループ単位で選択的に実施する処理部と、
   をそなえたことを特徴とする、運用管理保守装置。
4. 前記管理部は、
   前記無線基地局の障害発生数に関する閾値を前記グループ別に保持し、
   前記処理部は、
   前記無線基地局の障害の有無を監視し、いずれかの前記グループにおける障害発生数が前記閾値以上である場合に、当該グループに障害が発生したと判断する、ことを特徴とする、請求項３記載の運用管理保守装置。
5. 前記処理部は、
   前記障害発生数が前記閾値未満である場合には、当該無線基地局グループに障害は発生していないと判断する、ことを特徴とする、請求項４記載の運用管理保守装置。
6. 前記処理部は、
   前記グループに障害が発生した判断した場合に、前記運用管理保守装置の上位装置へ障害情報を通知する、ことを特徴とする、請求項４又は５に記載の運用管理保守装置。
7. 前記管理部は、
   前記無線基地局の輻輳状態に関する閾値を前記グループ別に保持し、
   前記処理部は、
   前記無線基地局の輻輳状態を監視し、いずれかの前記グループにおける輻輳状態が前記閾値以上である場合に、当該グループに輻輳が発生したと判断する、ことを特徴とする、請求項３記載の運用管理保守装置。
8. 前記処理部は、
   前記輻輳状態が前記閾値未満である場合には、当該グループに輻輳は発生していないと判断する、ことを特徴とする、請求項７記載の運用管理保守装置。
9. 前記管理部は、
   前記無線基地局が保持するファイルの更新率に関する閾値を前記グループ別に保持し、
   前記処理部は、
   前記無線基地局が保持するファイルの更新率を監視し、いずれかの前記グループにおける前記更新率が前記閾値を超えている場合に、当該グループに属する各無線基地局の前記ファイルの更新を行なう、ことを特徴とする、請求項３記載の運用管理保守装置。
10. 前記処理部は、
    前記更新状況が前記閾値以下である場合には、前記ファイルの更新が不要であると判断する、ことを特徴とする、請求項９記載の運用管理保守装置。

Images