JP2008092598A - 通信ネットワークを管理する方法および通信システム - Google Patents

Abstract

【課題】通信ネットワークにおいて、たとえばメーカ固有の下位のオペレーションおよびメンテナンスセンタ（ＯＭＣ）が占有されていない時点などに、メーカに依存しない管理する側の上位のネットワークマネージメントセンタ（ＮＭＣ）からの自動的なテスト機能を実現する。
【解決手段】アラームメッセージの交換にあたりメーカに依存する少なくとも１つの情報を伝達し、ネットワークマネージメントセンタにおいてメーカ固有のハードウェアテストを自動的に生成する。その際、ＯＭＣ−ＮＭＣインタフェースの情報モデルは、メーカ固有のオブジェクトクラスを知る必要がない。ネットワークマネージメントセンタＮＭＣにおいて自動的に生成されるテストを、たとえば特定のハードウェアボードにおけるエラー発生後にトリガしてもよいし、予防措置としてたとえばあるネットワークユニットのハードウェア全体のためにトリガしてもよい。
【選択図】図２

Description

本発明は、通信ネットワークの管理方法たとえば上位のネットワークマネージメントセンタにおいてテストを生成する方法および該方法を実施するための通信システムに関する。

無線通信システムにおいて情報（たとえば音声、画像情報または他のデータ）は、電磁波を用い送信側無線局と受信側無線局（基地局または移動局）との間の無線インタフェースを介して伝送される。この場合、電磁波の放射は、個々のシステムのために設定された周波数帯域内にある搬送波周波数によって行われる。ＧＳＭ（Global System for Mobile Communication）の場合には搬送波周波数は９００ＭＨｚ、１８００ＭＨｚもしくは１９００ＭＨｚの領域にある。たとえばＵＭＴＳ（Universal Mobile Telecommunication System）あるいは第３世代の他のシステムなどのような無線インタフェースを介したＣＤＭＡまたはＴＤ／ＣＤＭＡ伝送方式による将来の移動無線については、約２００００ＭＨｚの周波数帯域の周波数が設定されている。

ＴＭＮ方式（TMN: Telecommunications Management Network）とも称される一般的なマネージメントネットワークの方式によって、通信システムたとえば移動通信システムを管理するための複数のマネージメントレベルが定義されており、この場合、各レベルは２重の機能をもっている。このマネージメントシステムにおいて各レベルは最も下のレベル以外は、自身の１つ下に位置するレベルのためのマネージャ機能を備えている。管理される側のシステムでは各レベルは最も上のレベル以外は、自身の１つ上に位置するレベルのためのエージェント機能を備えている。

オブジェクト指向の環境では、それぞれ特定の機能を備えたネットワーク資源を成す多数のオブジェクトが存在する。典型的には移動無線ネットワークにおいてマネージャとエージェントとの間で成り立つようなオブジェクト指向の環境の場合にはそれに応じて各エージェントの機能が、１つのオブジェクトクラスにおける管理される側のオブジェクト（ないしはオブジェクトインスタンスＭＯＩ）として利用可能な１つの特定のオブジェクトによって提供される。

このオブジェクトは、機能のほかにたとえばパラメータや周囲条件が定義されるモデリング作業の結果として生じるものであり、これはマネージャにも相応のインタフェースにおいて実行するエージェントにも既知である。この場合、インタフェースはたとえば移動無線ネットワークにおいては、オペレーションおよびメンテナンスセンタ（図１のＯＭＣ）と基地局システム（ＢＳＳ）との間のいわゆるＯインタフェースとすることができる。

管理される側の特定のクラスＡのオブジェクトインスタンス（managed object class とも称する）は、同じクラスまたは別のクラスのオブジェクトインスタンスを有することができる。各オブジェクトインスタンス（クラスではない）の間におけるこのような関係は、モデリングにおいては包含関係 "containment relationship" とも呼ばれる。

また、あるクラスのオブジェクトインスタンスが他のクラスのオブジェクトに対し上位の（SUPERIOR）オブジェクトとして定義されているまたは定義可能であることを指定するオブジェクトクラス間の関係は、ネームバインディング "NAME BINDING" とも呼ばれる。ネームバインディング関係に基づきハイアラーキが組織されているオブジェクトの階層的なアロケーションは、一般にネーミングツリー "naming tree " と呼ばれる。

その際、通信ネットワークたとえば移動無線ネットワークにおいて、ネットワークの監視ならびに制御は一般に２つのマネージャサイドから行われる。すなわち一方では中央でオペレーションおよびメンテナンスセンタＯＭＣ（OMC: Operation and Maintanance Centre）から行われ、これはエレメントマネージャに対応し、他方では現地で局所的なメンテナンスデータステーションＬＭＴ（LMT: Local Maintenance Terminal）から行われ、これは様々なネットワークユニットに接続することができる。この種のネットワークユニットは移動無線ネットワークであればたとえば基地局サブシステムＢＳＣ、ハードウェアをモデリングもしくは考慮する基地局送受信局ＢＴＳＥ（ＢＴＳＥ：Base Transceiver Station Equipment）、あるいはトランスコーダおよびアダプタユニットＴＲＡＵである。

サービス提供側によって管理される通信ネットワーク全体は運用上、図１にも示されているように複数のネットワーク領域に分割される。ネットワーク全体には様々なメーカのハードウェアが含まれているにもかかわらず、これらのネットワーク領域各々の内部では、ネットワークエレメントも既述のマネージメントシステムも通常は同じメーカから納入される。それというのもオペレーションおよびメンテナンスセンタＯＭＣおよびローカルのメンテナンスデータステーションにおけるマネージメントによってメーカ固有のハードウェア特性すべてを考慮しなければならないからである。これにはたとえば個々のコンポーネントの機能テストなども属する。

夜や休日、週末の間、移動無線ネットワークは一方では、一般に "Network Management Centre" (NMC) と呼ばれる上位のネットワークマネージメントセンタによって監視される。なぜならば地域的なオペレーションおよびメンテナンスセンタＯＭＣはそのような時間は空いているからである。他方、ネットワークマネージメントセンタＮＭＣと地域的なオペレーションおよびメンテナンスセンタＯＭＣとの間のインタフェースをメーカには依存しないようにしておく必要があり、その目的はメーカ固有のネットワーク領域の機能的なインテグレーションを１つの統一的なネットワークマネージメントセンタＮＭＣのもとで実現できるようにするためである。

ＯＭＣ−ＮＭＣインタフェースのメーカ非依存性は、オブジェクト指向のマネージメント環境においていわゆるファンクショナルオブジェクトクラスたとえばマネージメントオブジェクトクラス（functional-related MOC）の排他的な利用により行うことができる。この場合、ファンクショナルオブジェクトによって、機能的なメーカに依存しない視点から通信ネットワークのネットワークリソースがモデリングされる。これに対しオペレーションおよびメンテナンスセンタＯＭＣとネットワークエレメントとの間のメーカ固有のインタフェースは、メーカごとに異なっているいわゆるハードウェア関連マネージメントオブジェクトクラス（equipment-related MOC）も把握している。ここでネットワークエレメントはたとえば基地局ＢＳＳであって、これはネットワーク領域においてＯＭＣによって管理される。

たとえば特定のハードウェアコンポーネントの故障など予期せぬ出来事に対し迅速に応答できるようにする目的で、ネットワークマネージメントセンタＮＭＣのオペレータは対応するテストをスタートさせることができなければならない。しかしネットワークマネージメントセンタのオペレータはオペレーションおよびメンテナンスセンタＯＭＣとは異なり、特定メーカのハードウェアに関するシステム固有の情報をもっていない。このためメーカ固有のテストを実行できない。

本発明の課題は、通信ネットワークの管理方法を改善することにあり、たとえば通信ネットワークにおいてメーカに依存しない上位のネットワークマネージメントセンタからの自動的なテスト機能を実現することにある。

この課題は、請求項１の特徴を備えた方法ならびに請求項１３の特徴を備えた無線通信システムによって解決される。従属請求項には有利な実施形態が示されている。

メーカに依存しないファンクショナルマネージメントオブジェクトクラスの処理と、メーカ固有のハードウェア関連マネージメントオブジェクトクラスの処理との間のコンフリクトは、マネージメントセンタにおいてメーカ固有のハードウェアテストを自動的に生成させることによって解決される。これは有利には、目的に合わせてつまりハードウェアエラーの結果としてアラームを受けた後にも行われるし、包括的にもつまり周期的な予防措置としても行われる。

このようにネットワークマネージメントセンタＮＭＣの側から、メーカ固有のハードウェアテストを自動的に生成することができ、このことはＯＭＣ−ＮＭＣインタフェースの情報モデルがメーカ固有のオブジェクトクラスを把握していないにもかかわらず可能である。

また、ネットワークマネージメントセンタＮＭＣにおいて自動的に発せられるテストをもっぱら特定の目的のために、つまり特定のハードウェアボードのエラーの発生後にトリガすることもできるし、たとえばあるネットワークユニットのハードウェア全体に対して予防措置としてトリガすることもできる。

次に、図面を参照しながら実施例について詳しく説明する。

図２および図３には、ネットワークマネージメントセンタＮＭＣの側からネットワークユニットに対しハードウェア固有のテストを行うための方法の流れが例示されている。

ネットワークマネージメントＮＭＣと地域的なオペレーションおよびメンテナンスセンタＯＭＣとの間のインタフェースを制御するために、様々なマネージメントオブジェクトクラスＭＯＣが設けられている。それらのインタフェースをメーカに依存しないようにする必要があるため、この種のマネージメントインタフェースの情報モデルはファンクショナルマネージメントオブジェクトクラスＭＯＣだけしかもっていない。

この情報モデルにメーカ固有のハードウェアをインテグレーションする目的で、有利にはすべてのハードウェアコンポーネントつまりいわゆるボードすべてが、汎用の全設備マネージメントオブジェクトクラスＭＯＣ（equipment summary MOC）としてネットワークユニットのレベル上で定義される。

たとえば移動無線ネットワークの無線部分は基地局制御装置ＢＳＣ、基地局送受信局ＢＴＳＥおよびトランスコーダおよびレートアダプタユニットＴＲＡＵというネットワークユニットから成り、この部分のために以下の全設備マネージメントオブジェクトクラスＭＯＣが定義される：
bscEquipment
btsEquipment
trauEquipment
マネージメントオブジェクトクラス bscEquipment は基地局制御装置の設備フィーチャに係わるものであり、btsEquipment は基地局送受信局の設備フィーチャであり、trauEquipment はトランスコーダおよびレートアダプタユニットの設備フィーチャである。

特定のハードウェアコンポーネントにおいてハードウェアエラーが発生すると、たとえば図２であればＴｙｐ ＴＰＵ（ＴＰＵ：Transceiver Power Unit）のボード１においてハードウェアエラーが発生すると（ここではこれは単にハードウェアボードの例としてＢＴＳＥユニット８のフレームないしラックＮｏ．２で示されている）、そのネットワークユニットは以下のパラメータをもつ警告もしくはアラームメッセージを発生する：
−オブジェクトクラスＭＯＣ： ＴＰＵ（メーカ固有のＯＭＣ−ＢＳＳインタフェースにおけるハードウェア関連ＭＯＣ）および
−オブジェクトインスタンスＭＯＩ： ．．．−８−２−１（相対的に区別可能な名前、いわゆる Relaive Distinguisched Name これはネームツリーに従う）。

このような通知はメーカ固有のアラームメッセージ（alarm report）として、ネットワークユニットである基地局制御装置ＢＳＣを介して地域的なオペレーションおよびメンテナンスセンタＯＭＣへ転送される。

オペレーションおよびメンテナンスセンタＯＭＣがふさがっていない時間に上位のネットワークマネージメントセンタＮＭＣにおけるネットワーク監視を行えるようにする目的で、メーカ固有の各オペレーションおよびメンテナンスセンタＯＭＣはいわゆる調停機能（mediation function）をもっている。この調停機能によって、ネットワークマネージメントセンタＮＭＣにとって重要であり通信ネットワークから到来するすべてのイベントメッセージ（event report）が、それぞれ対応するファンクショナルマネージメントオブジェクトクラスに変換され、これはＯＭＣ−ＭＭＣインタフェースの情報モデルに従い行われる。この処理はいわゆるマッピング手順とも呼ばれ、図２に描かれている。

換言すれば、ハードウェアエラー発生後のアラームメッセージすなわちハードウェア関連のメーカ固有のアラームが、調停機能によってファンクショナル全設備マネージメントオブジェクトに変換され、ついでこれはメーカに依存しないアラーム通知の形態でネットワークマネージメントセンタＮＭＣへ転送される。もとものハードウェア関連アラームメッセージは ITU-T X. 733 ("Systems Management: Alarm Reporting Function") に従い、たとえば以下のパラメータをもつ標準化されたファンクショナルアラームメッセージにマッピングされる：
−オブジェクトクラス： btsEquipment （これはネットワークユニットＢＴＳＥにおけるハードウェアの機能をモデリングする）
−オブジェクトインスタンス： ．．．-8。

オブジェクトインスタンスに関してＯＭＣ−ＮＭＣインタフェースには、実際のネットワークユニットＢＴＳＥと汎用のファンクショナルなオブジェクトクラスのインスタンス btsEquipment が存在する。

図２に描かれている実施例の場合、オペレーションおよびメンテナンスセンタＯＭＣへ伝送されるものであり "MOC = TPU" および "MOI = 1" をもつ元のアラームメッセージが、"MOC = btsEquipment", "MOI = 8" および付加情報（標準化パラメータ "Additional information"）＝ [rack 2, TPU 1] " にマッピングされる。

元のエラーのあるハードウェアを一義的に識別するメーカ固有の情報は、このように調停機能によって付加情報というフィールドに定義される。ネットワークマネージメントセンタＮＭＣに送信されるアラームメッセージの付加情報は、この実施例では ITU-T X. 710 "Open Systems Interconnection - Common Nanagement Information Service Definition" によれば以下のように定義されている：
−ラック番号： ２ なぜならばＢＴＳＥハードウェアはここでは複数のラックに収納されているからである。
−ボードタイプ： ＴＰＵ
−ボード番号： １。

調停されたアラームメッセージの受信後、ネットワークマネージメントセンタＮＭＣのＮＭＣソフトウェアはオブジェクトクラス（"equipment-summary" btsEquipment）に基づき、これがメーカ固有のハードウェアエラーであることを識別する。

エラーをさらに詳しく調べるために、つまり過渡的なエラーなのか永続的なエラーなのか、ボードを交換すべきなのか、などといったことを判定する目的で、ネットワークマネージメントＮＭＣは着目しているボード（ＴＰＵ）に固有のテストをスタートさせる必要がある。そのためＮＭＣソフトウェアはフィールド「付加情報」を評価し、調停されたアラームメッセージのオブジェクトクラスおよびオブジェクトインスタンスとともに、エラーの発生しているボードのアドレスを一義的に特定してシミュレートすることができる。

図３に描かれているように、ネットワークマネージメントセンタＮＭＣは ITU-T X. 745 (Systems Management: Test Management Function) に従い標準化されたマネージメントアクション "M-ACTION" を発生させ、そこではテストすべきハードウェアがいわゆる "nonSpecificForm" によって定義されている。この場合、パラメータはフィールド "toBeTestedMORTs" つまりテストすべきボードである。この実施例によれば第１のバイトは、テストすべきボードもしくはテストすべき回路基板が収容されているフレーム番号もしくはラック番号である。第２のバイトによりボードタイプが定義され、つまりこの実施例ではＴＰＵであり、さらに第３のバイトによって回路基板番号もしくはボード番号ここでは１が定義される。

マネージメントアクションＭ−ＡＣＴＩＯＮは、ネットワークマネージメントセンタＮＭＣからインタフェースを介してオペレーションおよびメンテナンスセンタＯＭＣへ送られ、その際、受信側は常に全設備タイプ（"equipment-summary" object）のマネージメントオブジェクトである。これはこの事例では btsEquipment インスタンス８である。

オペレーションおよびメンテナンスセンタＯＭＣにおいて、調停機能はこのマネージメント要求（M-ACTION Request）をＯＭＣ−ＢＳＳインタフェースのメーカ固有の情報モデルに従ったテスト要求に変換する。実際の基地局送受信装置ＢＴＳＥと全設備インスタンス btsEquipment とパラメータ値 "toBeTestedMORTs" との１：１の対応づけに基づき、調停機能は実際の通信ネットワークにおいてテストすべきボードのアドレスを一義的に規定することができる。その際、テスト要求には、着目しているボードについてまえもって規定されているメーカ固有のテストの識別子も含まれている。

ネットワークユニットここではＢＴＳＥ８に送り戻されたテスト結果は、オペレーションおよびメンテナンスセンタＯＭＣの調停機能により、やはりＯＭＣ−ＭＭＣインタフェースの情報モデルに従い変換され、標準化されたパラメータ "テスト呼び出しＩＤ" もしくは "testInvocationId" を用いることで、ネットワークマネージメントセンタＮＭＣの先行のＮＭＣテスト要求と一義的に相関づけられる。その際、ＯＭＣは標準化されたＮＭＣテストコマンドに従い "レスポンス Response" を送信し、テスト過程が一義的に識別されるようにする目的でこれにはパラメータ値 "testInvocationId" が含まれている。同じ値はオペレーションおよびメンテナンスセンタＯＭＣによりテスト終了後、ネットワークマネージメントセンタＮＭＣに対する testResultNotification に挿入される。

マッピングもしくは調停されたテスト結果は、いわゆるエラーフォームないしは "Trouble tickets" の自動作成のためにもＮＭＣソフトウェアによって用いることができ、これによって対応する修復措置を現場で導入することができる。

ＯＭＣ−ＮＭＣインタフェースの定義によって付加的および／または択一的に、ネットワークマネージメントセンタＮＭＣにおいて周期的予防的なハードウェアテストを自動的に生成することもできる。ITU-T X. 745 に従い標準化されたテスト要求において、ネットワークマネージメントセンタＮＭＣはテストすべきボードに対する特別な値を "toBeTestedMORTs" という属性で利用することができる。調停機能はこのコマンドをたとえば、テスト要求の受信側によりモデリングされるネットワークユニット全体に対するテスト要求として解釈することができる。この実施例の場合、これは btsEquipment インスタンス８である。したがって調停機能は、各ハードウェア基板に固有の複数の個々のテストコマンドを生成し、それらのコマンドはネットワークユニットＢＴＳＥ ８へ相前後して送られる。

各テスト後に個々のテスト結果は調停機能によって収集され、「マッピングされ」、ITU-T X. 745 に従い標準化されたテスト結果メッセージつまりいわゆる "testResultNofication" として上位のネットワークマネージメントセンタＮＭＣへ伝送される。

複数のネットワーク領域に分割された一般的な通信ネットワークを示す図 図１のような通信ネットワークにおけるアラーム伝送手順の流れを示す図 上述の通信ネットワークにおけるメーカ固有のテストの流れを概略的に示す図

符号の説明

ＮＭＣ ネットワークマネージメントセンタ
ＯＭＣ オペレーションおよびメンテナンスセンタ
ＢＳＳ 基地局システム
ＢＳＣ 基地局サブシステム
ＢＴＳＥ 基地局送受信装置

Claims (15)

1. 少なくとも１つの上位のファンクショナルなたとえばメーカに依存しない装置（ＮＭＣ）と、
   該装置により監視されるおよび／または制御される少なくとも１つの下位の装置（ＯＭＣ）が設けられており、
   前記の装置の間でファンクショナルでないたとえばメーカに依存する通信ネットワークにおける少なくとも１つの装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）の状態に関するメッセージが交換される形式の、
   通信ネットワークの管理方法において、
   メッセージの交換にあたり少なくとも１つのファンクショナルでないメーカに依存する情報を伝達することを特徴とする、
   通信ネットワークの管理方法。
2. メーカに依存する情報をもつメッセージを周期的におよび／または要求に応じておよび／またはメーカに依存しない少なくとも１つの装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）におけるエラー発生後に伝達する、請求項１記載の方法。
3. 前記メッセージをメーカに依存しない上位の装置（ＮＭＣ）へ伝達する、請求項１または２記載の方法。
4. メーカに依存する少なくとも１つの特定の装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）の状態に関するメーカに依存する情報を前記メッセージによって伝達する、請求項１から３のいずれか１項記載の方法。
5. 下位の装置（ＯＭＣ）においてメーカに依存する情報を、メーカに依存しない上位の装置（ＮＭＣ）へのメーカに依存しないメッセージのために、メーカに依存する付加情報へ変換する、請求項１から４のいずれか１項記載の方法。
6. メッセージたとえばテスト要求メッセージをメーカに依存する情報を用いて、メーカに依存しない上位の装置（ＮＭＣ）からメーカに依存する装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）のうちの１つまたは複数の所定の装置へ伝達する、請求項１または２記載の方法。
7. メッセージの伝達により、メーカに依存する少なくとも１つの装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）の状態をチェックまたは問い合わせ、たとえばメーカ固有のテストを開始する、請求項１または２または６記載の方法。
8. 下位の装置（ＯＭＣ）においてメーカに依存しないメッセージにおけるメーカに依存する付加情報を、メーカに依存する装置（ＯＭＣ，ＢＳＣ，ＢＴＳＥ，ＴＲＡＵ）のためにメーカに依存する情報へ変換する、請求項１から７のいずれか１項記載の方法。
9. 前記情報を付加情報としてたとえば標準化されたメッセージによって伝達する、請求項１から８のいずれか１項記載の方法。
10. メーカに依存しない少なくとも１つの上位の装置（ＮＭＣ）と、少なくとも１つの下位の装置（ＯＭＣ）との間のインタフェースを介して、該インタフェース（ＯＭＣ−ＮＭＣ）の情報モデルに従いメッセージを伝達し、該情報モデルはメーカに依存する情報に対して設計されていない、請求項１から９のいずれか１項記載の方法。
11. 前記情報モデルをオブジェクト指向で構築し、該情報モデルはメーカに依存するオブジェクトクラスを知らない、請求項１０記載の方法。
12. メーカに依存する情報を付加情報として通常のたとえば標準化されたメッセージ内で伝達する、請求項１から１１のいずれか１項記載の方法。
13. 請求項１から１２のいずれか１項記載の通信システムたとえば無線通信システム。
14. メーカに依存しない上位の装置（ＮＭＣ）にネットワークマネージメントセンタが設けられている、請求項１３記載の通信システム。
15. 少なくとも１つの上位の装置は、たとえば複数のネットワーク領域のうち１つのネットワーク領域のオペレーションおよびメンテナンスセンタ（ＯＭＣ）である、請求項１３または１４記載の通信システム。

Images