JP2003209550A - 通信ネットワーク管理におけるオペレーションシステムおよびオーダー実行順序制御方法 - Google Patents

Abstract

(57)【要約】 【課題】本発明の課題は、第一の課題は、通信ネットワ
ークにおけるＲＡＮ区間のＶＰを柔軟かつ迅速に構築す
ることのできるオペレーションシステム提供することで
ある。 【解決手段】上記課題は、通信ネットワークの２つのノ
ード間の通信経路となるパスを設計する設計システムで
生成されたパス開通の指示を示すオーダーがネットワー
ク管理システムで受信された際に、そのネットワーク管
理システムが該オーダーの内容に従ってパスを開通させ
るようにしたオペレーションシステムにおいて、設計シ
ステムは、生成したオーダーを通信ネットワークの構築
形態に応じてネットワーク管理システムに送信する網構
築形態別オーダー送信手段を有し、ネットワーク管理シ
ステムは、上記通信ネットワークの構築形態に応じて送
信されたオーダーに対応した処理方法にてオーダーの実
行処理を行うオーダー実行手段を有するオペレーション
システムにて解決される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、通信ネットワー
ク、例えば移動通信ネットワーク管理におけるネットワ
ーク管理システムに係り、詳しくは、ＲＡＮ(Radio Acc
ess Network)区間のパスを構築する際に発行されるオー
ダーの実行順序の制御を行うオペレーションシステムに
関する。

【０００２】また、本発明はオペレーションシステムで
なされるオーダー実行順序制御方法に関する。

【０００３】

【従来の技術】従来、例えば、ある地域を対象に移動通
信サービス（例：ＰＤＣ（Personal Digital Cellula
r）方式の移動通信システムで提供されるサービス）の
提供を開始するような場合、通信事業者は、オペレーシ
ョンシステムを用いて、その地域の需要予測から必要と
なるネットワーク装置（以下、ＮＥ（Network Equipmen
t）という）の数や、通信容量を算出し、通信回線の収
容設計を行う。そして、その収容設計で得られた設計情
報をもとに通信回線を開通させるためのＯｒｄｅｒ（＝
オーダー）の実行処理を行う。このＯｒｄｅｒには、装
置ＩＤや、通信回線名、通信回線構成などＮＥや通信回
線設定に関する情報が含まれ、該当するＮＥはネットワ
ーク管理システム（以下、ＮＭＳ(Network Management
System)という）を介して上記Ｏｒｄｅｒに含まれる情
報を受取ることでボード間の接続設定や通信回線設定を
行うことができるようになっている。上記Ｏｒｄｅｒ
は、一般にオペレーションシステムの構成要素であるパ
ス設計システムで生成され、ＮＭＳにて実行される。ま
た、ＮＭＳは、受取ったＯｒｄｅｒをもとにＮＥの設定
や通信回線の設定を、ＮＥを管理するＮＥ管理システム
に行わせる。

【０００４】ＮＥ管理システムにて、ＮＥの設定や通信
回線の設定が完了すると、その設定された回線に対する
導通試験が行われ、異常がなけば張られた通信回線が開
通となる。通信事業者は、上記のような一連の処理を行
うことで、上記地域におけるサービスを開始することが
できるようになっている。

【０００５】

【発明が解決しようとする課題】上述したように、従来
のＰＤＣ方式で用いられるオペレーションシステムのＮ
ＭＳは、受取ったＯｒｄｅｒ順にＯｒｄｅｒ処理を実行
（シーケンシャル処理）するようになっている。そのた
め、１つのＯｒｄｅｒ処理を終えるまで次のＯｒｄｅｒ
処理を行うことができないため、Ｏｒｄｅｒ数に応じて
線形的に処理時間が増加してしまうという問題があっ
た。

【０００６】このような問題は、ＰＤＣ方式だけに限ら
ず、前述したオペレーションシステムを流用する限り第
三世代の通信方式であるＩＭＴ−２０００（internatio
nalmobile telecommunication 2000）でも言える。両者
の違いは、大局的に見て、Ｏｒｄｅｒに含まれる情報が
異なる。例えば、ＰＤＣ方式の場合、1回のデータ伝送
ごとに回線が接続、切断される方式、いわゆる回線交換
方式が主で用いられるため、通信をするノード間を、そ
の通信が占有する通信チャネルでつなぐための情報がＯ
ｒｄｅｒに含まれる。一方、ＩＭＴ−２０００の場合、
音声、文字、動画像等多様かつ総合的なコンテンツを扱
うため、個々の情報形態に応じて効率的な収容を行える
伝送、交換方式が不可欠であるとの観点から多元速度通
信や可変速度通信といった特徴を有するＡＴＭが用いら
れる。すなわち、通信をするノード間を論理的な接続関
係（仮想パス（以下、Virtual Path(ＶＰ)という）と仮
想チャネル(以下、Virtual Channel(ＶＣ)という)であ
る）で設定するための情報がＯｒｄｅｒに含まれる。従
って、ＩＭＴ−２０００におけるパス設計とは、ＶＰの
構築を指す。

【０００７】ところで、ＩＭＴ−２０００におけるＡＴ
Ｍネットワークは、交換機間の中継系ネットワークと、
移動端末と無線通信を行う無線基地局と、該無線基地局
を制御する無線制御装置間（以下、Radio Network Cont
roller(ＲＮＣ)という）のネットワーク（以下、Radio
Access Network (ＲＡＮ)という）とに分けられ、それ
ぞれの区間においてＶＰ構築のためのパス設計が設計者
にて行われる。特にＲＡＮ区間のＶＰ構築は、短期間で
の変動が予想される移動網の通信量やエリア拡大に等に
対応する必要がある。言い換えれば、ＲＡＮ区間のＶＰ
を柔軟かつ迅速に構築するには、ＶＰの設計から開通ま
での業務の効率化（フロースルー化）が不可欠となる。
しかしながら、パス設計システム〜ＮＭＳ間のフロース
ルー化を実現するにあたり次のような問題があった。 問題１：ＲＡＮ区間のＶＰ構築には、２つの開通形態が
ある。１つ目はサービス開始前にサービス提供地域全体
に対して行われる初期構築、２つ目はサービス開始後に
需要予測見直し等を踏まえ、計画的に追加構築する場合
である。パス設計システム〜ＮＭＳのフロースルー化
は、これら２つのパターンどちらにも対応している必要
がある。 問題２：ＲＡＮのＶＰを構成する装置は多種多様であ
る。例えば、無線基地局用ＡＴＭ多重化装置ＡＴＭ−Ｍ
ＵＸ（以下、Ｓ−ＭＵＸという）のように、インチャネ
ルＶＰ（監視制御用ＶＰ）を最初に設定しなければなら
ない場合もある。これらは装置に依存する問題であるた
め、その影響がパス設計システムへ及ぶことのないよう
ＮＭＳで隠蔽すべきである。従って、ネットワークを設
計する業務とネットワークを構成する装置へ設定を行う
業務とは、連携しつつも独立性の高いインタフェースを
規定する必要がある。

【０００８】問題３：パス設計システムは、過去の設計
データ及び実際のパス構築状況を元に、新たなパス設計
を行う。つまり、開通処理を管理している。ＮＭＳは、
その進捗状況をパス設計システムに通知する必要があ
る。このとき業務プロセス毎に通知機能を持たせると、
パス設計システムとＮＭＳ間の連携が複雑になるという
問題があった。

【０００９】本発明は、上記のような問題点に鑑みてな
されたもので、第一の課題は、通信ネットワーク（例：
移動通信ネットワーク）におけるＲＡＮ区間のＶＰを柔
軟かつ迅速に構築することのできるオペレーションシス
テム提供することである。また、第二の課題は、そのよ
うなオペレーションシステムで適用されるオーダー実行
順序制御方法を提供することである。

【００１０】

【課題を解決するための手段】上記第一の課題を解決す
るため、本発明は、請求項１に記載されるように、通信
ネットワークの２つのノード間の通信経路となるパスを
設計する設計システムで生成されたパス開通の指示を示
すオーダーがネットワーク管理システムで受信された際
に、そのネットワーク管理システムが該オーダーの内容
に従ってパスを開通させるようにしたオペレーションシ
ステムにおいて、設計システムは、生成したオーダーを
通信ネットワークの構築形態に応じてネットワーク管理
システムに送信する網構築形態別オーダー送信手段を有
し、ネットワーク管理システムは、上記通信ネットワー
クの構築形態に応じて送信されたオーダーに対応した処
理方法にてオーダーの実行処理を行うオーダー実行手段
を有するように構成することができる。

【００１１】このようなオペレーションシステムでは、
パス設計システムは、移動通信ネットワーク上の２つの
ノード間、例えば、無線基地局と無線制御装置（＝無線
回線制御装置）間のパス構築（ＶＰ構築）の構築形態に
応じてオーダーの送信形態を変える。例えば、計画的に
ＶＰ構築を行う（例：初期構築）場合、オーダーの実行
を通常通り行わせる送信形態で送信し、計画外の突発的
な需要に対応させる場合（例：追加構築）は、オーダー
の実行を即行わせる送信形態で送信する。このように、
本発明では、通常のオーダー送信形態の他にオーダーの
実行を即行わせる送信形態を用いるので、短期間で設
計、工事、パス開通を行うようなケースでも効率良くＶ
Ｐパスの構築が可能となる。

【００１２】上記オーダーの送信形態は、請求項２に記
載されるように、上記オペレーションシステムにおい
て、上記網構築形態別オーダー送信手段は、生成したオ
ーダーをネットワーク管理システムに自動的に送信する
オーダー自動送信手段と、上記オーダーを生成した際
に、その生成したオーダーを蓄積し、その蓄積したオー
ダーを所定タイミングで上記ネットワーク管理システム
に送信するオーダー手動送信手段とを有するように構成
される。

【００１３】このようなオペレーションシステムでは、
パスの初期構築時においては、パス設計システムで生成
されたオーダーが自動でＮＭＳに送出され、パスの追加
構築時においては、パス設計システムで生成されたオー
ダーが手動でＮＭＳに送出される。オーダーの手動送信
は、パスを設計する設計者が自由に複数選択して送信す
ることができるので、緊急度の高いパス構築を効率良く
行うことができる。

【００１４】オーダーの送信形態に応じてオーダー実行
処理を行うという観点から、本発明は、請求項３に記載
されるように、上記オペレーションシステムにおいて、
上記オーダー実行手段は、上記オーダー自動送信手段に
て送信されたオーダーの実行をバッチ処理にて行うバッ
チ処理手段と、上記オーダー手動送信手段にて送信され
たオーダーの実行をリアルタイム処理にて行うリアルタ
イム処理手段とを有するように構成される。

【００１５】このようなオペレーションシステムでは、
オーダーの送信形態に応じてバッチ処理あるいはリアル
タイム処理がＮＭＳで行われる。つまり、パス構築形態
に適したオーダーの実行処理が行われるので、いずれの
構築形態であっても構築形態に応じて効率良くパス構築
が行えるようになる。

【００１６】適切なオーダー実行順にてオーダーを実行
できるという観点から、本発明は、請求項４に記載され
るように、上記オペレーションシステムにおいて、上記
ネットワーク管理システムは、上記設計システムがオー
ダー自動送信手段もしくはオーダー手動送信手段にて送
信した順不同かつ複数のオーダーを受信した際に、その
受信したオーダー内のパラメータが正常であるかどうか
を確認するパラメータ確認手段と、上記オーダーを実行
順序順に検索するオーダー検索手段とを有し、上記オー
ダー実行手段にて該オーダー検索手段の検索にて探しだ
したオーダー順に従ってオーダーを実行させるように構
成される。

【００１７】オーダーの実行順序は、本発明は、請求項
５に記載されるように、上記オペレーションシステムに
おいて、上記オーダー検索手段は、受信したオーダーを
格納するオーダー格納手段と、該オーダー格納手段にて
格納されたオーダーのなかから廃止を指示するオーダー
を検索した後に新設を指示するオーダーを検索し、その
検索した順で探しだしたオーダーを通信ネットワークを
管理するデータベースに登録する構成データベース登録
手段とを有するように構成される。

【００１８】また、本発明は、請求項６に記載されるよ
うに、上記オペレーションシステムにおいて、上記構成
データベース登録手段は、上記のようにしてオーダーを
格納する際に、オーダーに対するリソースの依存関係が
正常であるかどうかを判定する依存関係判定手段と、そ
の判定結果をオーダー格納手段に通知する進捗状態更新
通知手段とを有するように構成される。

【００１９】さらに、本発明は、請求項７に記載される
ように、上記オペレーションシステムにおいて、上記オ
ーダー格納手段は上記進捗状態更新通知手段にて通知さ
れた進捗状態更新に関する情報を契機に格納しているオ
ーダーをオーダー実行手段に送出するように構成され
る。

【００２０】このようなオペレーションシステムでは、
ＮＭＳはオーダー受信後、そのオーダーに対する依存関
係を調べ、該依存関係が正常であったオーダーのうち廃
止を指示するオーダーから実行し、次いで新設を指示す
るオーダーを実行する。上記依存関係のチェックは、例
えば、ある装置の廃止を指示するオーダーを受取った場
合、その装置に依存するボードやＶＰなどのパス設定が
すでに廃止になっているかどうかを調べることであっ
て、該装置と依存関係にあるＶＰがすでに設定されてい
れば該装置に対する廃止オーダーは実行されない。つま
り、該装置上で形成されている回線を利用しているユー
ザが存在しているにもかかわらずその装置を切断してし
まっては該ユーザに対するサービスが途断されることに
なる。従って、ＮＭＳでは上記のような依存関係をチェ
ックすることで信頼度の高いオーダー実行を実現でき
る。

【００２１】また、ＮＭＳはオーダーの実行を個別に行
うのでなく、競合しないオーダーを一括して実行するの
で、オーダーに対するパス設定等の時間を大幅に削減す
ることができる。

【００２２】オーダー進捗の共有と管理が可能になると
いう観点から、本発明は、請求項８に記載されるよう
に、上記オペレーションシステムにおいて、上記設計シ
ステムは、オーダーの進捗を管理するオーダー管理プロ
セス手段を有するように構成される。

【００２３】また、上記同様の観点から、本発明は、請
求項９に記載されるように、上記オペレーションシステ
ムにおいて、上記ネットワーク管理システムは、オーダ
ーの実行を管理するオーダー実行プロセス手段を有する
ように構成される。

【００２４】上記第二の課題を解決するため、本発明
は、請求項１０に記載されるように、通信ネットワーク
の２つのノード間の通信経路となるパスを設計する設計
システムで生成されたパス開通の指示となるオーダーが
ネットワーク管理システムで受信された際に、該ネット
ワーク管理システムが該オーダーを実行するオーダー実
行順序制御方法において、上記設計システムで生成され
たオーダーを受信した際に、その受信したオーダー内の
パラメータが正常であるかどうかを確認すると共にその
受信したオーダーを実行順序順に検索し、該検索にて探
しだしたオーダー順に従って管理対象となる装置に対し
てのパスを設定させるように構成することができる。

【００２５】

【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて説明する。

【００２６】図１は、本発明の実施の一形態に係る、通
信ネットワーク（以下、本例では、通信ネットワークの
一例として移動通信ネットワークを取り上げ説明する）
管理におけるオペレーションシステム１００および該オ
ペレーションシステム１００の管理対象となる管理対象
装置の一例を示す図である。

【００２７】本発明に係るオペレーションシステム１０
０は、管理対象装置となる無線基地局６００（以下、Ｂ
ＴＳ（Base Transceiver Station）という）と、無線制
御装置(以下、ＲＮＣ（Radio Network Controller）と
いう)２００の区間（以下、ＲＡＮ（Radio Access Netw
ork）という）のパス設計および該パス設計で生成され
たオーダーを実行して上記区間のパスを開通させる役割
を担う。本例において、上記オペレーションシステム１
００が管理する管理対象装置は、具体的には、ＲＮＣ２
００、ＲＮＣ側のＡＴＭ多重化装置（以下、ＡＴＭ−Ｍ
ＵＸという）３００、ＢＴＳ６００、ＢＴＳ側のＡＴＭ
−ＭＵＸ４００およびＡＴＭ−Ｓ−ＭＵＸ５００であ
る。本例ではこれらの装置をＮＥ（Network Equipmen
t：ネットワーク装置）と呼んで説明する。

【００２８】上記オペレーションシステム１００は、パ
ス設計システム１０と、ＮＭＳ（Network Management S
ystem:ネットワーク管理システム）２０と、ＮＥ管理シ
ステム３０とで構成される。パス設計システム１０とＮ
ＭＳ２０はＬＡＮで接続されデータのやり取りが行える
ようになっている。ＮＭＳ２０とＮＥ管理システム３０
は、本例では、１つの装置の中に並存している形態を例
にとり説明を行うが、本発明はこのような形態に限ら
ず、ＮＭＳ２０とＮＥ管理システム３０が個々の装置で
構成されているような形態であってもよい。ＮＥ管理シ
ステム３０には、パス設定やＮＥ設定を仲介するＮＥメ
ディエーション３１〜３２が備えられ、ＮＥ管理システ
ムとＮＥメディエーション間は例えば、ＬＡＮを用いて
データの送受が行われる。

【００２９】パス設計システム１０では、トラヒックデ
ータ等の需要予測に基づいて算出されるパス容量等から
ＶＰ（Virtual Path）の収容設計が行われ、該ＶＰの収
容設計情報をもとに『Ｏｒｄｅｒ（＝オーダー）』生成
する。そして、その生成したＯｒｄｅｒ（＝送信Ｏｒｄ
ｅｒ）をＮＭＳ２０に送出する役割を担う。パス設計シ
ステム１０から送出されるＯｒｄｅｒの送出形態は、Ｖ
ＰやＮＥの構築形態、例えば、初期構築や追加構築など
の構築形態によって変わり（詳細説明は、後述する説明
（１）を参照）、さらに上記Ｏｒｄｅｒには、装置ＩＤ
やパス名、パス構成などネットワーク装置（ＮＥ）やパ
スの設定情報が含まれる。

【００３０】ＮＭＳ２０は、パス設計システム１０から
Ｏｒｄｅｒを受け取り、そのＯｒｄｅｒの内容に従って
パスやＮＥの設定、生成、削除などが行われるよう設定
要求（＝ＮＥ設定要求）をＮＥ管理システム３０に送
る。このＮＥ設定要求は、ＮＥメディエーション３１〜
３２を介してＡＴＭ−ＭＵＸ３００(実線矢印)およびＢ
ＴＳ側のＡＴＭ−ＭＵＸ４００を経由してＡＴＭ−Ｓ−
ＭＵＸ（点線矢印）５００に送られ、それぞれのＮＥに
おいて該ＮＥ設定要求に含まれる情報の内容に従ったパ
スの設定やＮＥの設定が行われる。

【００３１】このように各ＮＥの設定、パスの設定はパ
ス設計システム１０から送出されるＯｒｄｅｒに基づい
て行われる。

【００３２】図２は、送信Ｏｒｄｅｒのイメージを示す
図である。同図に示すように、送信Ｏｒｄｅｒには、Ｎ
Ｅに対するＯｒｄｅｒ（例：ＡＴＭ−ＭＵＸ３００、４
００、ＡＴＭ−Ｓ−ＭＵＸ５００の送信架や同装置内の
ＩＦ Ｂｏａｒｄに対するＯｒｄｅｒ）やパスに対する
Ｏｒｄｅｒ（例：ＶＰやＶＣ（ＶＣ４/３２）に対する
Ｏｒｄｅｒ）等がある。

【００３３】また、ＮＭＳ２０では、受信したＯｒｄｅ
ｒを予め定められた実行順序にて実行する。このＮＭＳ
でなされるＯｒｄｅｒの実行順序の説明は後述する（後
述する説明（２）を参照）。

【００３４】また、ＮＭＳ２０ではＯｒｄｅｒが実行さ
れると、Ｏｒｄｅｒ処理の進捗通知をパス設計システム
に行う。本発明では、この進捗通知を、業務プロセスご
とに行うのでなく、Ｏｒｄｅｒ管理系とＯｒｄｅｒ実行
系のプロセスに分けて配置し、互いのプロセス間通信の
みでＯｒｄｅｒの進捗管理を実現する（詳細説明は、後
述する説明（３）を参照）。

【００３５】尚、ＮＥにおけるＲＮＣ側のＡＴＭ−ＭＵ
Ｘ３００とＢＴＳ側のＡＴＭ−ＭＵＸ４００の通信はマ
イクロ波帯のエントランス回線を利用する形態であって
も、ＳＤＨ（synchronous digital hierarchy）伝送装
置を利用する形態であってもよく、いずれの形態でも本
発明を限定するものでない。

【００３６】図３は、本発明のネットワーク管理システ
ムの一構成であるパス設計システム１０の機能ブロック
の構成例を示すものである。

【００３７】図３において、このパス設計システム１０
は、クライアント/サーバー・システムであって、クラ
イアント側は、オペレーティング・システム（Ｗｉｎｄ
ｏｗｓ（登録商標）（ＮＴ））１１、業務用アプリケー
ション（Visual Basic、Excel等）１２、オラクルが提
供するデータベース・サーバーとアクセスするためのイ
ンタフェース(Oracle Net8)１３などが備えられる。一
方、サーバー側は、オペレーティング・システム（ＵＮ
ＩＸ（登録商標）のSolaris）１４、オラクルが提供す
るデータベース(Oracle 8(RDBMS))１５、クライアント
側とアクセスするためのインタフェース(Oracle Net8)
１６、業務用アプリケーション１７、ＢＴＳ６００やＲ
ＮＣ２００の無線ネットワーク装置（ＲＡＮ：Radio Ac
cess Network）の無線諸元に係る情報を得るための通信
用ＡＰＩ（Application Program Interface）１８が備
えられる。また、上記通信用ＡＰＩには、ＬＡＮでＮＭ
Ｓ２０との通信を行うプロトコルなどが備えられる。

【００３８】図４は、本発明のネットワーク管理システ
ムの一構成であるＮＭＳ２０の機能ブロックの構成例を
示すものである。

【００３９】図４において、このＮＭＳ２０は信頼性向
上のため二重化(０系、１系)がとられる。０系、１系と
も同構成であるので、以下、０系を例にとり説明する。

【００４０】本ＮＭＳ２０の０系は、オペレーティング
・システム（ＵＮＩＸのSolaris）２１、オラクルが提
供するデータベース(Oracle 8(RDBMS))２２、通信ＡＰ
Ｉ２３、業務用アプリケーション２４、冗長構成共通Ａ
ＰＩ２５とで構成される。通信ＡＰＩは、パス設計シス
テム１０やＮＭＳ２０用のＧＵＩ(graphical user inte
rface)ならびにＮＥ管理システム３０と接続するための
通信インタフェース機能を備える。

【００４１】上記データベースには、パス設計システム
から受信したＯｒｄｅｒを格納するデータベース（以
下、オーダーＤＢという）と、移動通信ネットワークの
すべての構成に係るデータを格納するデータベース（以
下、構成ＤＢという）とが備えられる。図５は、本発明
のネットワーク管理システムの一構成であるＮＥ管理シ
ステム３０の機能ブロックの構成例を示すものである。

【００４２】図５において、このＮＥ管理システム３０
は前述したＮＭＳ２０と同様に信頼性向上の見地から二
重化(０系、１系)がとられる。０系、１系とも同構成で
あるので、以下、０系を例にとり説明する。

【００４３】本ＮＥ管理システム３０の０系は、オペレ
ーティング・システム（ＵＮＩＸのSolaris）５１、オ
ラクルが提供するデータベース(Oracle 8(RDBMS))５
２、通信ＡＰＩ５３、業務用アプリケーション５４、冗
長構成共通ＡＰＩ５５とで構成される。通信ＡＰＩ５３
には、ＧＵＩを持つ総合保守端末、ＮＭＳ２０およびＮ
Ｅメディエーション３１〜３２と通信をするための通信
インタフェース機能が備えられる。

【００４４】次に、ＶＰやＮＥの構築形態に応じてＯｒ
ｄｅｒの送出形態を変える実施例について詳述する。

【００４５】（説明１）ＲＡＮのパス構築には、計画的
に行う場合（初期構築）と、計画外の突発的な需要に対
応する場合（追加構築）の２つがある。本発明では、前
者に対応したＯｒｄｅｒを「通常Ｏｒｄｅｒ」、後者に
対応したＯｒｄｅｒを「緊急Ｏｒｄｅｒ」とし、ＶＰや
ＮＥの構築形態によって両者のＯｒｄｅｒを使い分け
る。

【００４６】以下、それぞれのＯｒｄｅｒについて説明
する。

【００４７】図６は、通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒ
の流れを示す図である。

【００４８】同図に示すように、通常Ｏｒｄｅｒは、パ
ス設計システム１０において作成された網の設計情報を
基に、自動的に該パス設計システム１０内で生成され、
その後ＮＭＳ２０に自動送信される。ＮＭＳ２０はその
Ｏｒｄｅｒを受信した後、受信したＯｒｄｅｒに対して
パラメータチェック等の事前処理を行う。その後の日次
バッチ処理において、実行日となるＯｒｄｅｒの検索を
行い、対象Ｏｒｄｅｒがあれば実行する。

【００４９】一方、緊急Ｏｒｄｅｒは、パス設計システ
ム１０でのＯｒｄｅｒ作成までは前述した通常Ｏｒｄｅ
ｒと同じであるが、Ｏｒｄｅｒ自動生成後、パス設計シ
ステム１０に蓄積される。これは、ＮＥの物理的な工事
が完了次第、設計者が自由に複数選択してＮＭＳ２０へ
手動送信できるようにするためである。ＮＭＳ２０へ送
信するＯｒｄｅｒは、設計者がＯｒｄｅｒを任意に選択
して個別に送信したり、あるパスに関連するＯｒｄｅｒ
（物理および論理に関連するＯｒｄｅｒ）をまとめて送
信したりすることができる。ＮＭＳ２０はＯｒｄｅｒ受
信後、受信したＯｒｄｅｒのパラメータチェック等の事
前処理後、即時に各実行処理を行う。この実行処理は、
ＮＥ情報設定から工事設定解除まで連続して実行され
る。

【００５０】上述したように本実施例によれば、通常Ｏ
ｒｄｅｒと緊急Ｏｒｄｅｒの２種類のＯｒｄｅｒを用意
し、サービス開始前にサービス提供地域全体に対して行
われる初期構築に対しては通常Ｏｒｄｅｒを、当初の計
画外のＶＰを構築する必要が生じた場合は手動でＯｒｄ
ｅｒ送信可能な緊急Ｏｒｄｅｒを用いる。例えば、特定
地域のＶＰを短期間で構築しなければならない場合に
は、緊急Ｏｒｄｅｒを用いれば遅滞なく速やかなパス開
通が可能である。従って、通常Ｏｒｄｅｒと緊急Ｏｒｄ
ｅｒとを使い分けることでパスの開通形態によらずパス
設計システム〜ＮＭＳ間フロースルー化（自動化）が実
現できる。

【００５１】次に、ＮＭＳ２０で実行されるＯｒｄｅｒ
の実行順序について説明する。

【００５２】（説明２）まず、ＮＭＳ２０で実行される
Ｏｒｄｅｒの種類と実行順序について図７を参照しなが
ら説明する。

【００５３】同図に示すように、Ｏｒｄｅｒの工程種別
には「廃止」と「新設」の２つがあり、Ｏｒｄｅｒの種
類には、ＡＴＭ関連のＯｒｄｅｒとして、「ＶＰ」、
「ＶＣ４/３２パス」、「ＩＦボード」、「グルー
プ」、「ユニット」、「装置架」ある。これらのＯｒｄ
ｅｒのうち、「ＶＰ」と「ＶＣ４/３２パス」は論理系
リソース、他は物理系リソースである。論理系のリソー
スは、物理系リソースに依存していて、廃止の場合であ
れば、論理系リソース→物理系リソースの順、新設の場
合であれば、物理系リソース→論理系リソースに順でＯ
ｒｄｅｒが実行される。尚、同一リソースに対する廃止
は、新設が正常終了しない限り、設計できない。つま
り、あるＶＰを廃止するには、必ず該ＶＰが新設されて
いなければならない。

【００５４】このようにＮＭＳ２０は、上記のような実
行順序に従ってＯｒｄｅｒを実行する。

【００５５】次に、上記実行順序に基づいてＮＭＳ２０
で実行されるＯｒｄｅｒ処理の流れについて図８を参照
しながら説明する。

【００５６】図８において、パス設計システム１０は、
ＮＭ２０Ｓに対して順不同で任意の種類のＯｒｄｅｒを
複数送信（手動送信、自動送信いずれであってもよい）
する。ＮＭＳ２０は、受信したＯｒｄｅｒをオーダーＤ
Ｂに格納する（）。オーダーＤＢは格納したＯｒｄｅ
ｒを図７で示したＯｒｄｅｒ実行順序の順番に検索す
る。具体的には、「ＶＰの廃止があるかないか」→「Ｖ
Ｃ４/３２の廃止があるかないか」のような順（廃止Ｏ
ｒｄｅｒであれば論理系リソースから物理系リソースの
順に、新設Ｏｒｄｅｒであれば物理系リソースから論理
系リソースの順）に検索し、該当するものがあればそれ
を構成ＤＢに登録（）する。構成ＤＢでは、新設のオ
ーダーに対してはレコードを新たに挿入（）し、廃止
のオーダーに対しては廃止フラグを立てる（）。その
際、構成ＤＢはそのＯｒｄｅｒの依存関係をチェック
（）してから登録を行う。構成ＤＢにてなされる依存
関係チェックとは、次のようなチェックである。あるリ
ソースを新規に生成するためには、依存するリソースが
既に存在するか、またはそのリソースの新規オーダーが
あることが必要である。例えば、あるＶＰを新設する場
合、それを構成するＶＣ４/３２が存在しているかどう
かがチェックされる。また、装置架を廃止するためには
その装置架に対応付けられたＩＦボード〜ＶＰまでが既
に廃止されているかどうかがチェックされる。

【００５７】尚、上記構成ＤＢには既存のネットワーク
に関する全てのデータが格納される。構成ＤＢではオー
ダーが正常に登録される度にデータベースを更新し、そ
の結果を進捗更新としてオーダーＤＢに通知（）す
る。このようにして進捗更新通知がオーダーＤＢになさ
れると、オーダーＤＢは、格納しているオーダーに対す
るＮＥ設定のための設定要求をＮＥ管理システムに送
る。尚、ＮＥ設定要求に対するＮＥ設定が失敗したとき
は、オーダーＤＢはロールバック、つまり、先に挿入し
た新設Ｏｒｄｅｒや廃止Ｏｒｄｅｒを構成ＤＢから探し
出して、挿入したレコードについてはもとに戻したり、
廃止フラグを立てたレコードについては廃止を取り消し
たりする（）。

【００５８】上述したように、本実施例によれば、構成
ＤＢにて依存関係がチェックされたオーダーに対応する
ＮＥ設定要求がオーダーＤＢより一括してＮＥ管理シス
テムに送られてＮＥ設定やパス設定が行われる。すなわ
ち、従来のようにＯｒｄｅｒ個別に処理を行うのでな
く、競合しないＯｒｄｅｒを並列で処理するようにする
ので、パス開通が多いような初期構築や計画されたパス
構築においてはＯｒｄｅｒ数に応じた処理時間の線形増
加を防ぐことができ、パス開通を効率的に行うことがで
きる。ところで、ＮＭＳ２０は、各Ｏｒｄｅｒの各実行
処理フェーズの結果を、進捗通知を用いてパス設計シス
テム１０に通知するが、本発明では、業務プロセスごと
に進捗通知を行うのでなく、プロセスをＯｒｄｅｒ管理
系とＯｒｄｅｒ実行系に分けて配置し、プロセス間通信
を行って進捗を管理する。以下、具体例について説明す
る。 （説明３）図９は、プロセスの配置法を図示したもので
ある。同図に示すように、プロセスをＯｒｄｅｒ管理系
と、Ｏｒｄｅｒ実行系とに分けることで、パス設計シス
テムのＯｒｄｅｒ管理プロセス（）と、ＮＭＳのＯｒ
ｄｅｒ実行ワークフロープロセス（）のやり取りのみ
でＯｒｄｅｒ進捗の共有と管理が可能となる。従って、
本実施例によれば、ＮＭＳ２０内での進捗管理の複雑化
を防止することができる。ＮＭＳ２０ではＯｒｄｅｒ受
信後、Ｏｒｄｅｒ実行系プロセスを１つずつ起動する。
実行中にエラーとなった場合、パス設計システム１０へ
通知される。図１０にＯｒｄｅｒ進捗管理プロセス及び
Ｏｒｄｅｒ実行ワークフロープロセス各々で管理するＯ
ｒｄｅｒの状態を示す。同図に示すように、パス設計シ
ステム１０の進捗管理（）では、Ｏｒｄｅｒ作成中
（Ａ）、Ｏｒｄｅｒ実行中（Ｂ）、サービス中（Ｃ）と
いう大まかな状態を管理しているのに対し、ＮＭＳ２０
の実行ワークフロー（）では、Ｏｒｄｅｒ実行中にお
けるより詳細な状態を管理している。

【００５９】また、統合保守端末のプロセスは、実行ワ
ークフローをＧＵＩ上から直接操作でき、緊急Ｏｒｄｅ
ｒの進捗状況の参照、取消、ＮＧのＯｒｄｅｒの再実行
が可能である。このときの実行結果は、Ｏｒｄｅｒ実行
ワークフローを通じてパス設計システムのＯｒｄｅｒ管
理プロセスへ通知される。

【００６０】従って、本実施例によれば、プロセスの配
置と、Ｏｒｄｅｒ進捗管理形態を適用することで、パス
設計システムとＮＭＳの独立性を確保することができ
る。

【００６１】上記例において、パス設計システム１０の
通信ＡＰＩ１８の通信機能が網構築形態別オーダー送信
手段、オーダー自動送信手段、オーダー手動送信手段に
対応し、業務アプリケーション１２、１７のプロセス管
理機能がオーダー管理プロセス手段に対応する。

【００６２】また、ＮＭＳ２０の業務アプリケーション
２４、２５の情報処理機能がオーダー実行手段、バッチ
処理手段、オーダー手動送信手段に、同業務アプリケー
ション２４、２５のプロセス管理機能がオーダー実行プ
ロセス手段対応する。データベース(Oracle 8(RDBMS))
２２、２７と業務アプリケーション２４、２５の連携処
理機能がパラメータ確認手段、オーダー検索手段、依存
関係判定手段に対応し、データベース(Oracle 8(RDBM
S))２２、２７のデータ登録機能がオーダー格納手段、
構成データベース登録手段に対応する。さらに、通信Ａ
ＰＩ２３の通信機能が進捗状態更新通知手段に対応す
る。

【００６３】

【発明の効果】以上、説明したように、請求項１乃至９
記載の本願発明によれば、バッチ処理によるスケジュー
ルに沿った開通が可能な通常Ｏｒｄｅｒと、設計後、即
座に開通可能な緊急Ｏｒｄｅｒとを用意するので、それ
ぞれのパスの構築形態で効率良くパス構築を行うことが
できる。

【００６４】また、ＮＭＳでは実行するＯｒｄｅｒの順
序を廃止Ｏｒｄｅｒ→新設Ｏｒｄｅｒの順で実行される
よう順序制御を行うので、サービスを提供している回線
の誤切断を防ぐことができると共に、Ｏｒｄｅｒの一括
処理が行えるためパス構築に要する時間を極力抑えるこ
とができる。

【００６５】さらに、パス設計システムのＯｒｄｅｒ進
捗プロセスとＮＭＳのＯｒｄｅｒ実行ワークプロセスで
Ｏｒｄｅｒ進捗管理を行うことでＯｒｄｅｒ進捗の共有
と管理が可能となるため、パス設計システムとＮＭＳ間
の連携が複雑になるという問題を解決することができ
る。

【００６６】また、請求項１０乃至１３記載の本願発明
によれば、上記のようなネットワーク管理システムで適
用することのできるオーダー実行順序制御方法を提供す
ることができる。

【図面の簡単な説明】

【図１】本発明の実施の一形態に係る移動通信ネットワ
ーク管理におけるオペレーションシステムの構成例およ
び該オペレーションシステムの管理対象となる管理対象
装置の一例を示す図である。

【図２】送信Ｏｒｄｅｒのイメージを示す図である。

【図３】パス設計システムの構成例を示す図である。

【図４】ＮＭＳの構成例を示す図である。

【図５】ＮＥ管理システムの構成例を示す図である。

【図６】通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒの流れを示す
図である。

【図７】Ｏｒｄｅｒの種類と実行順序を示す図である。

【図８】ＮＭＳで実行されるＯｒｄｅｒ処理の流れを示
す図である。

【図９】プロセスの配置法を示す図である。

【図１０】Ｏｒｄｅｒ進捗管理プロセス及びＯｒｄｅｒ
実行ワークフロープロセス各々で管理するＯｒｄｅｒの
状態を示す図である。

【符号の説明】

１０ パス設計システム １１ オペレーティング・システム（Windows（Ｎ
Ｔ）） １２、１７、２４、２９、５４、５９ 業務用アプリケ
ーション（Visual Basic、Excel等） １３、１６ データベース・サーバーアクセスインタフ
ェース １４、２１、２６、５１、５６ オペレーティング・シ
ステム（ＵＮＩＸのSolaris） １５、２２、２７、５２、５７ Oracle 8(RDBMS)) １８、２３、３０、５３、６０ 通信用ＡＰＩ ２０ ＮＭＳ ２５、２８、５５、５８ 冗長構成共通ＡＰＩ ３０ ＮＥ管理システム ３１、３２ ＮＥメディエーション １００ オペレーションシステム ２００ ＲＮＣ ３００、４００ ＡＴＭ−ＭＵＸ ５００ ＡＴＭ−Ｓ−ＭＵＸ ６００ ＢＴＳ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 榮 浩三 東京都千代田区永田町二丁目11番１号 株 式会社エヌ・ティ・ティ・ドコモ内 (72)発明者 原 和彦 東京都千代田区永田町二丁目11番１号 株 式会社エヌ・ティ・ティ・ドコモ内 Ｆターム(参考） 5K030 GA14 HB06 JA10 KA01 MD07 5K051 AA09 AA10 CC07 DD13 DD15 EE01 FF01

Claims (13)

【特許請求の範囲】
1. 【請求項１】通信ネットワークの２つのノード間の通信
   経路となるパスを設計する設計システムで生成されたパ
   ス開通の指示を示すオーダーがネットワーク管理システ
   ムで受信された際に、そのネットワーク管理システムが
   該オーダーの内容に従ってパスを開通させるようにした
   オペレーションシステムにおいて、 設計システムは、生成したオーダーを通信ネットワーク
   の構築形態に応じてネットワーク管理システムに送信す
   る網構築形態別オーダー送信手段を有し、 ネットワーク管理システムは、上記通信ネットワークの
   構築形態に応じて送信されたオーダーに対応した処理方
   法にてオーダーの実行処理を行うオーダー実行手段を有
   するオペレーションシステム。
2. 【請求項２】請求項１記載のオペレーションシステムに
   おいて、 上記網構築形態別オーダー送信手段は、生成したオーダ
   ーをネットワーク管理システムに自動的に送信するオー
   ダー自動送信手段と、 上記オーダーを生成した際に、その生成したオーダーを
   蓄積し、その蓄積したオーダーを所定タイミングで上記
   ネットワーク管理システムに送信するオーダー手動送信
   手段とを有するネットワーク管理システム。
3. 【請求項３】請求項１記載のオペレーションシステムに
   おいて、 上記オーダー実行手段は、上記オーダー自動送信手段に
   て送信されたオーダーの実行をバッチ処理にて行うバッ
   チ処理手段と、 上記オーダー手動送信手段にて送信されたオーダーの実
   行をリアルタイム処理にて行うリアルタイム処理手段と
   を有するオペレーションシステム。
4. 【請求項４】請求項２又は３記載のオペレーションシス
   テムにおいて、 上記ネットワーク管理システムは、上記設計システムが
   オーダー自動送信手段もしくはオーダー手動送信手段に
   て送信した順不同かつ複数のオーダーを受信した際に、
   その受信したオーダー内のパラメータが正常であるかど
   うかを確認するパラメータ確認手段と、 上記オーダーを実行順序順に検索するオーダー検索手段
   とを有し、 上記オーダー実行手段にて該オーダー検索手段の検索に
   て探しだしたオーダー順に従ってオーダーを実行させる
   オペレーションシステム。
5. 【請求項５】請求項４記載のオペレーションシステムに
   おいて、 上記オーダー検索手段は、受信したオーダーを格納する
   オーダー格納手段と、 該オーダー格納手段にて格納されたオーダーのなかから
   廃止を指示するオーダーを検索した後に新設を指示する
   オーダーを検索し、その検索した順で探しだしたオーダ
   ーを通信ネットワークを管理するデータベースに登録す
   る構成データベース登録手段とを有するオペレーション
   システム。
6. 【請求項６】請求項５記載のオペレーションシステムに
   おいて、 上記構成データベース登録手段は、上記のようにしてオ
   ーダーを格納する際に、オーダーに対するリソースの依
   存関係が正常であるかどうかを判定する依存関係判定手
   段と、 その判定結果をオーダー格納手段に通知する進捗状態更
   新通知手段とを有するオペレーションシステム。
7. 【請求項７】請求項６記載のオペレーションシステムに
   おいて、 上記オーダー格納手段は上記進捗状態更新通知手段にて
   通知された進捗状態更新に関する情報を契機に格納して
   いるオーダーをオーダー実行手段に送出するオペレーシ
   ョンシステム。
8. 【請求項８】請求項１記載のオペレーションシステムに
   おいて、 上記設計システムは、オーダーの進捗を管理するオーダ
   ー管理プロセス手段を有するオペレーションシステム。
9. 【請求項９】請求項１記載のオペレーションシステムに
   おいて、 上記ネットワーク管理システムは、オーダーの実行を管
   理するオーダー実行プロセス手段を有するオペレーショ
   ンシステム。
10. 【請求項１０】通信ネットワークの２つのノード間の通
    信経路となるパスを設計する設計システムで生成された
    パス開通の指示となるオーダーがネットワーク管理シス
    テムで受信された際に、該ネットワーク管理システムが
    該オーダーを実行するオーダー実行順序制御方法におい
    て、 上記設計システムで生成されたオーダーを受信した際
    に、その受信したオーダー内のパラメータが正常である
    かどうかを確認すると共にその受信したオーダーを実行
    順序順に検索し、 該検索にて探しだしたオーダー順に従って管理対象とな
    る装置に対してのパスを設定させるオーダー実行順序制
    御方法。
11. 【請求項１１】請求項１０記載のオーダー実行順序制御
    方法において、 受信したオーダーを所定のデータベースに格納し、 その格納したオーダーのなかから廃止を指示するオーダ
    ーを検索した後に新設を指示するオーダーを検索し、そ
    の検索した順で探しだしたオーダーを通信ネットワーク
    を管理するデータベースに登録するオーダー実行順序制
    御方法。
12. 【請求項１２】請求項１１記載のオーダー実行順序制御
    方法において、 上記通信ネットワークを管理するデータベースにオーダ
    ーを格納する際に、格納をしようとするオーダーのリソ
    ースの依存関係が正常であるかどうかを判定し、 その判定結果を上記所定のデータベースに通知するオー
    ダー実行順序制御方法。
13. 【請求項１３】請求項１２記載のオーダー実行順序制御
    方法において、 上記判定結果にて通知された進捗状態更新に関する情報
    を契機に上記所定のデータベースに格納しているオーダ
    ーを管理対象となる装置のパス設定を行う装置に送出す
    るオーダー実行順序制御方法。