(57)【特許請求の範囲】
【請求項１】
通信ネットワークの２つのノード間の通信経路となるパスを設計する設計システムで生成されたパス開通の指示を示すオーダーがネットワーク管理システムで受信された際に、そのネットワーク管理システムが該オーダーの内容に従ってパスを開通させるようにしたオペレーションシステムにおいて、
設計システムは、通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて、該オーダーをネットワーク管理システムに送信する網構築形態別オーダー送信手段を有し、
ネットワーク管理システムは、上記通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて送信されたオーダーに対応した処理方法にてオーダーの実行処理を行うオーダー実行手段を有するオペレーションシステム。
【請求項２】
請求項１記載のオペレーションシステムにおいて、
上記網構築形態別オーダー送信手段は、生成したオーダーをネットワーク管理システムに自動的に送信するオーダー自動送信手段と、
上記オーダーを生成した際に、その生成したオーダーを蓄積し、その蓄積したオーダーを所定タイミングで上記ネットワーク管理システムに送信するオーダー手動送信手段とを有するネットワーク管理システム。
【請求項３】
請求項１記載のオペレーションシステムにおいて、
上記オーダー実行手段は、上記オーダー自動送信手段にて送信されたオーダーの実行をバッチ処理にて行うバッチ処理手段と、
上記オーダー手動送信手段にて送信されたオーダーの実行をリアルタイム処理にて行うリアルタイム処理手段とを有するオペレーションシステム。
【請求項４】
請求項２又は３記載のオペレーションシステムにおいて、
上記ネットワーク管理システムは、上記設計システムがオーダー自動送信手段もしくはオーダー手動送信手段にて送信した順不同かつ複数のオーダーを受信した際に、
その受信したオーダー内のパラメータが正常であるかどうかを確認するパラメータ確認手段と、
上記オーダーを実行順序順に検索するオーダー検索手段とを有し、
上記オーダー実行手段にて該オーダー検索手段の検索にて探しだしたオーダー順に従ってオーダーを実行させるオペレーションシステム。
【請求項５】
請求項４記載のオペレーションシステムにおいて、
上記オーダー検索手段は、受信したオーダーを格納するオーダー格納手段と、該オーダー格納手段にて格納されたオーダーのなかから廃止を指示するオーダーを検索した後に新設を指示するオーダーを検索し、その検索した順で探しだしたオーダーを通信ネットワークを管理するデータベースに登録する構成データベース登録手段とを有するオペレーションシステム。
【請求項６】
請求項５記載のオペレーションシステムにおいて、
上記構成データベース登録手段は、上記のようにしてオーダーを格納する際に、オーダーに対するリソースの依存関係が正常であるかどうかを判定する依存関係判定手段と、
その判定結果をオーダー格納手段に通知する進捗状態更新通知手段とを有するオペレーションシステム。
【請求項７】
請求項６記載のオペレーションシステムにおいて、
上記オーダー格納手段は上記進捗状態更新通知手段にて通知された進捗状態更新に関する情報を契機に格納しているオーダーをオーダー実行手段に送出するオペレーションシステム。
【請求項８】
請求項１記載のオペレーションシステムにおいて、
上記設計システムは、オーダーの進捗を管理するオーダー管理プロセス手段を有するオペレーションシステム。
【請求項９】
請求項１記載のオペレーションシステムにおいて、
上記ネットワーク管理システムは、オーダーの実行を管理するオーダー実行プロセス手段を有するオペレーションシステム。
【請求項１０】
通信ネットワークの２つのノード間の通信経路となるパスを設計する設計システムで生成されたパス開通の指示となるオーダーがネットワーク管理システムで受信された際に、該ネットワーク管理システムが該オーダーを実行するオーダー実行順序制御方法において、
設計システムは、通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて、該オーダーをネットワーク管理システムに送信し、
ネットワーク管理システムは、上記通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて送信されたオーダーを受信した際に、その受信したオーダー内のパラメータが正常であるかどうかを確認すると共にその受信したオーダーを実行順序順に検索し、該検索にて探しだしたオーダー順に従って管理対象となる装置に対してのパスを設定させるオーダー実行順序制御方法。
【請求項１１】
請求項１０記載のオーダー実行順序制御方法において、
受信したオーダーを所定のデータベースに格納し、その格納したオーダーのなかから廃止を指示するオーダーを検索した後に新設を指示するオーダーを検索し、その検索した順で探しだしたオーダーを通信ネットワークを管理するデータベースに登録するオーダー実行順序制御方法。
【請求項１２】
請求項１１記載のオーダー実行順序制御方法において、
上記通信ネットワークを管理するデータベースにオーダーを格納する際に、格納をしようとするオーダーのリソースの依存関係が正常であるかどうかを判定し、その判定結果を上記所定のデータベースに通知するオーダー実行順序制御方法。
【請求項１３】
請求項１２ 記載のオーダー実行順序制御方法において、
上記判定結果にて通知された進捗状態更新に関する情報を契機に上記所定のデータベースに格納しているオーダーを管理対象となる装置のパス設定を行う装置に送出するオーダー実行順序制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信ネットワーク、例えば移動通信ネットワーク管理におけるネットワーク管理システムに係り、詳しくは、ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）区間のパスを構築する際に発行されるオーダーの実行順序の制御を行うオペレーションシステムに関する。
【０００２】
また、本発明はオペレーションシステムでなされるオーダー実行順序制御方法に関する。
【０００３】
【従来の技術】
従来、例えば、ある地域を対象に移動通信サービス（例：ＰＤＣ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ｃｅｌｌｕｌａｒ）方式の移動通信システムで提供されるサービス）の提供を開始するような場合、通信事業者は、オペレーションシステムを用いて、その地域の需要予測から必要となるネットワーク装置（以下、ＮＥ（Ｎｅｔｗｏｒｋ  Ｅｑｕｉｐｍｅｎｔ）という）の数や、通信容量を算出し、通信回線の収容設計を行う。そして、その収容設計で得られた設計情報をもとに通信回線を開通させるためのＯｒｄｅｒ（＝オーダー）の実行処理を行う。このＯｒｄｅｒには、装置ＩＤや、通信回線名、通信回線構成などＮＥや通信回線設定に関する情報が含まれ、該当するＮＥはネットワーク管理システム（以下、ＮＭＳ（Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）という）を介して上記Ｏｒｄｅｒに含まれる情報を受取ることでボード間の接続設定や通信回線設定を行うことができるようになっている。上記Ｏｒｄｅｒは、一般にオペレーションシステムの構成要素であるパス設計システムで生成され、ＮＭＳにて実行される。また、ＮＭＳは、受取ったＯｒｄｅｒをもとにＮＥの設定や通信回線の設定を、ＮＥを管理するＮＥ管理システムに行わせる。
【０００４】
ＮＥ管理システムにて、ＮＥの設定や通信回線の設定が完了すると、その設定された回線に対する導通試験が行われ、異常がなけば張られた通信回線が開通となる。通信事業者は、上記のような一連の処理を行うことで、上記地域におけるサービスを開始することができるようになっている。
【０００５】
【発明が解決しようとする課題】
上述したように、従来のＰＤＣ方式で用いられるオペレーションシステムのＮＭＳは、受取ったＯｒｄｅｒ順にＯｒｄｅｒ処理を実行（シーケンシャル処理）するようになっている。そのため、１つのＯｒｄｅｒ処理を終えるまで次のＯｒｄｅｒ処理を行うことができないため、Ｏｒｄｅｒ数に応じて線形的に処理時間が増加してしまうという問題があった。
【０００６】
このような問題は、ＰＤＣ方式だけに限らず、前述したオペレーションシステムを流用する限り第三世代の通信方式であるＩＭＴ−２０００（ｉｎｔｅｒｎａｔｉｏｎａｌ  ｍｏｂｉｌｅ  ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ２０００）でも言える。両者の違いは、大局的に見て、Ｏｒｄｅｒに含まれる情報が異なる。例えば、ＰＤＣ方式の場合、１回のデータ伝送ごとに回線が接続、切断される方式、いわゆる回線交換方式が主で用いられるため、通信をするノード間を、その通信が占有する通信チャネルでつなぐための情報がＯｒｄｅｒに含まれる。一方、ＩＭＴ−２０００の場合、音声、文字、動画像等多様かつ総合的なコンテンツを扱うため、個々の情報形態に応じて効率的な収容を行える伝送、交換方式が不可欠であるとの観点から多元速度通信や可変速度通信といった特徴を有するＡＴＭが用いられる。すなわち、通信をするノード間を論理的な接続関係（仮想パス（以下、Ｖｉｒｔｕａｌ  Ｐａｔｈ（ＶＰ）という）と仮想チャネル（以下、Ｖｉｒｔｕａｌ  Ｃｈａｎｎｅｌ（ＶＣ）という）である）で設定するための情報がＯｒｄｅｒに含まれる。従って、ＩＭＴ−２０００におけるパス設計とは、ＶＰの構築を指す。
【０００７】
ところで、ＩＭＴ−２０００におけるＡＴＭネットワークは、交換機間の中継系ネットワークと、移動端末と無線通信を行う無線基地局と、該無線基地局を制御する無線制御装置間（以下、Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ（ＲＮＣ）という）のネットワーク（以下、Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  （ＲＡＮ）という）とに分けられ、それぞれの区間においてＶＰ構築のためのパス設計が設計者にて行われる。特にＲＡＮ区間のＶＰ構築は、短期間での変動が予想される移動網の通信量やエリア拡大に等に対応する必要がある。言い換えれば、ＲＡＮ区間のＶＰを柔軟かつ迅速に構築するには、ＶＰの設計から開通までの業務の効率化（フロースルー化）が不可欠となる。しかしながら、パス設計システム〜ＮＭＳ間のフロースルー化を実現するにあたり次のような問題があった。
問題１：ＲＡＮ区間のＶＰ構築には、２つの開通形態がある。１つ目はサービス開始前にサービス提供地域全体に対して行われる初期構築、２つ目はサービス開始後に需要予測見直し等を踏まえ、計画的に追加構築する場合である。パス設計システム〜ＮＭＳのフロースルー化は、これら２つのパターンどちらにも対応している必要がある。
問題２：ＲＡＮのＶＰを構成する装置は多種多様である。例えば、無線基地局用ＡＴＭ多重化装置ＡＴＭ−ＭＵＸ（以下、Ｓ−ＭＵＸという）のように、インチャネルＶＰ（監視制御用ＶＰ）を最初に設定しなければならない場合もある。これらは装置に依存する問題であるため、その影響がパス設計システムへ及ぶことのないようＮＭＳで隠蔽すべきである。従って、ネットワークを設計する業務とネットワークを構成する装置へ設定を行う業務とは、連携しつつも独立性の高いインタフェースを規定する必要がある。
【０００８】
問題３：パス設計システムは、過去の設計データ及び実際のパス構築状況を元に、新たなパス設計を行う。つまり、開通処理を管理している。ＮＭＳは、その進捗状況をパス設計システムに通知する必要がある。このとき業務プロセス毎に通知機能を持たせると、パス設計システムとＮＭＳ間の連携が複雑になるという問題があった。
【０００９】
本発明は、上記のような問題点に鑑みてなされたもので、第一の課題は、通信ネットワーク（例：移動通信ネットワーク）におけるＲＡＮ区間のＶＰを柔軟かつ迅速に構築することのできるオペレーションシステム提供することである。
また、第二の課題は、そのようなオペレーションシステムで適用されるオーダー実行順序制御方法を提供することである。
【００１０】
【課題を解決するための手段】
上記第一の課題を解決するため、本発明は、請求項１に記載されるように、通信ネットワークの２つのノード間の通信経路となるパスを設計する設計システムで生成されたパス開通の指示を示すオーダーがネットワーク管理システムで受信された際に、そのネットワーク管理システムが該オーダーの内容に従ってパスを開通させるようにしたオペレーションシステムにおいて、設計システムは、通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて、該オーダーをネットワーク管理システムに送信する網構築形態別オーダー送信手段を有し、ネットワーク管理システムは、上記通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて送信されたオーダーに対応した処理方法にてオーダーの実行処理を行うオーダー実行手段を有するように構成することができる。
【００１１】
このようなオペレーションシステムでは、パス設計システムは、移動通信ネットワーク上の２つのノード間、例えば、無線基地局と無線制御装置（＝無線回線制御装置）間のパス構築（ＶＰ構築）の構築形態に応じてオーダーの送信形態を変える。例えば、計画的にＶＰ構築を行う（例：初期構築）場合、オーダーの実行を通常通り行わせる送信形態で送信し、計画外の突発的な需要に対応させる場合（例：追加構築）は、オーダーの実行を即行わせる送信形態で送信する。このように、本発明では、通常のオーダー送信形態の他にオーダーの実行を即行わせる送信形態を用いるので、短期間で設計、工事、パス開通を行うようなケースでも効率良くＶＰパスの構築が可能となる。
【００１２】
上記オーダーの送信形態は、請求項２に記載されるように、上記オペレーションシステムにおいて、上記網構築形態別オーダー送信手段は、生成したオーダーをネットワーク管理システムに自動的に送信するオーダー自動送信手段と、上記オーダーを生成した際に、その生成したオーダーを蓄積し、その蓄積したオーダーを所定タイミングで上記ネットワーク管理システムに送信するオーダー手動送信手段とを有するように構成される。
【００１３】
このようなオペレーションシステムでは、パスの初期構築時においては、パス設計システムで生成されたオーダーが自動でＮＭＳに送出され、パスの追加構築時においては、パス設計システムで生成されたオーダーが手動でＮＭＳに送出される。オーダーの手動送信は、パスを設計する設計者が自由に複数選択して送信することができるので、緊急度の高いパス構築を効率良く行うことができる。
【００１４】
オーダーの送信形態に応じてオーダー実行処理を行うという観点から、本発明は、請求項３に記載されるように、上記オペレーションシステムにおいて、上記オーダー実行手段は、上記オーダー自動送信手段にて送信されたオーダーの実行をバッチ処理にて行うバッチ処理手段と、上記オーダー手動送信手段にて送信されたオーダーの実行をリアルタイム処理にて行うリアルタイム処理手段とを有するように構成される。
【００１５】
このようなオペレーションシステムでは、オーダーの送信形態に応じてバッチ処理あるいはリアルタイム処理がＮＭＳで行われる。つまり、パス構築形態に適したオーダーの実行処理が行われるので、いずれの構築形態であっても構築形態に応じて効率良くパス構築が行えるようになる。
【００１６】
適切なオーダー実行順にてオーダーを実行できるという観点から、本発明は、請求項４に記載されるように、上記オペレーションシステムにおいて、上記ネットワーク管理システムは、上記設計システムがオーダー自動送信手段もしくはオーダー手動送信手段にて送信した順不同かつ複数のオーダーを受信した際に、その受信したオーダー内のパラメータが正常であるかどうかを確認するパラメータ確認手段と、上記オーダーを実行順序順に検索するオーダー検索手段とを有し、上記オーダー実行手段にて該オーダー検索手段の検索にて探しだしたオーダー順に従ってオーダーを実行させるように構成される。
【００１７】
オーダーの実行順序は、本発明は、請求項５に記載されるように、上記オペレーションシステムにおいて、上記オーダー検索手段は、受信したオーダーを格納するオーダー格納手段と、該オーダー格納手段にて格納されたオーダーのなかから廃止を指示するオーダーを検索した後に新設を指示するオーダーを検索し、その検索した順で探しだしたオーダーを通信ネットワークを管理するデータベースに登録する構成データベース登録手段とを有するように構成される。
【００１８】
また、本発明は、請求項６に記載されるように、上記オペレーションシステムにおいて、上記構成データベース登録手段は、上記のようにしてオーダーを格納する際に、オーダーに対するリソースの依存関係が正常であるかどうかを判定する依存関係判定手段と、その判定結果をオーダー格納手段に通知する進捗状態更新通知手段とを有するように構成される。
【００１９】
さらに、本発明は、請求項７に記載されるように、上記オペレーションシステムにおいて、上記オーダー格納手段は上記進捗状態更新通知手段にて通知された進捗状態更新に関する情報を契機に格納しているオーダーをオーダー実行手段に送出するように構成される。
【００２０】
このようなオペレーションシステムでは、ＮＭＳはオーダー受信後、そのオーダーに対する依存関係を調べ、該依存関係が正常であったオーダーのうち廃止を指示するオーダーから実行し、次いで新設を指示するオーダーを実行する。上記依存関係のチェックは、例えば、ある装置の廃止を指示するオーダーを受取った場合、その装置に依存するボードやＶＰなどのパス設定がすでに廃止になっているかどうかを調べることであって、該装置と依存関係にあるＶＰがすでに設定されていれば該装置に対する廃止オーダーは実行されない。つまり、該装置上で形成されている回線を利用しているユーザが存在しているにもかかわらずその装置を切断してしまっては該ユーザに対するサービスが途断されることになる。従って、ＮＭＳでは上記のような依存関係をチェックすることで信頼度の高いオーダー実行を実現できる。
【００２１】
また、ＮＭＳはオーダーの実行を個別に行うのでなく、競合しないオーダーを一括して実行するので、オーダーに対するパス設定等の時間を大幅に削減することができる。
【００２２】
オーダー進捗の共有と管理が可能になるという観点から、本発明は、請求項８に記載されるように、上記オペレーションシステムにおいて、上記設計システムは、オーダーの進捗を管理するオーダー管理プロセス手段を有するように構成される。
【００２３】
また、上記同様の観点から、本発明は、請求項９に記載されるように、上記オペレーションシステムにおいて、上記ネットワーク管理システムは、オーダーの実行を管理するオーダー実行プロセス手段を有するように構成される。
【００２４】
上記第二の課題を解決するため、本発明は、請求項１０に記載されるように、通信ネットワークの２つのノード間の通信経路となるパスを設計する設計システムで生成されたパス開通の指示となるオーダーがネットワーク管理システムで受信された際に、該ネットワーク管理システムが該オーダーを実行するオーダー実行順序制御方法において、設計システムは、通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて、該オーダーをネットワーク管理システムに送信し、ネットワーク管理システムは、上記通信ネットワークの構築形態に応じて前記オーダーの送信形態を変えて送信されたオーダーを受信した際に、その受信したオーダー内のパラメータが正常であるかどうかを確認すると共にその受信したオーダーを実行順序順に検索し、該検索にて探しだしたオーダー順に従って管理対象となる装置に対してのパスを設定させるように構成することができる。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２６】
図１は、本発明の実施の一形態に係る、通信ネットワーク（以下、本例では、通信ネットワークの一例として移動通信ネットワークを取り上げ説明する）管理におけるオペレーションシステム１００および該オペレーションシステム１００の管理対象となる管理対象装置の一例を示す図である。
【００２７】
本発明に係るオペレーションシステム１００は、管理対象装置となる無線基地局６００（以下、ＢＴＳ（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ）という）と、無線制御装置（以下、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）という）２００の区間（以下、ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）という）のパス設計および該パス設計で生成されたオーダーを実行して上記区間のパスを開通させる役割を担う。本例において、上記オペレーションシステム１００が管理する管理対象装置は、具体的には、ＲＮＣ２００、ＲＮＣ側のＡＴＭ多重化装置（以下、ＡＴＭ−ＭＵＸという）３００、ＢＴＳ６００、ＢＴＳ側のＡＴＭ−ＭＵＸ４００およびＡＴＭ−Ｓ−ＭＵＸ５００である。本例ではこれらの装置をＮＥ（Ｎｅｔｗｏｒｋ  Ｅｑｕｉｐｍｅｎｔ：ネットワーク装置）と呼んで説明する。
【００２８】
上記オペレーションシステム１００は、パス設計システム１０と、ＮＭＳ（Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ：ネットワーク管理システム）２０と、ＮＥ管理システム３０とで構成される。パス設計システム１０とＮＭＳ２０はＬＡＮで接続されデータのやり取りが行えるようになっている。ＮＭＳ２０とＮＥ管理システム３０は、本例では、１つの装置の中に並存している形態を例にとり説明を行うが、本発明はこのような形態に限らず、ＮＭＳ２０とＮＥ管理システム３０が個々の装置で構成されているような形態であってもよい。ＮＥ管理システム３０には、パス設定やＮＥ設定を仲介するＮＥメディエーション３１〜３２が備えられ、ＮＥ管理システムとＮＥメディエーション間は例えば、ＬＡＮを用いてデータの送受が行われる。
【００２９】
パス設計システム１０では、トラヒックデータ等の需要予測に基づいて算出されるパス容量等からＶＰ（Ｖｉｒｔｕａｌ  Ｐａｔｈ）の収容設計が行われ、該ＶＰの収容設計情報をもとに『Ｏｒｄｅｒ（＝オーダー）』生成する。そして、その生成したＯｒｄｅｒ（＝送信Ｏｒｄｅｒ）をＮＭＳ２０に送出する役割を担う。パス設計システム１０から送出されるＯｒｄｅｒの送出形態は、ＶＰやＮＥの構築形態、例えば、初期構築や追加構築などの構築形態によって変わり（詳細説明は、後述する説明（１）を参照）、さらに上記Ｏｒｄｅｒには、装置ＩＤやパス名、パス構成などネットワーク装置（ＮＥ）やパスの設定情報が含まれる。
【００３０】
ＮＭＳ２０は、パス設計システム１０からＯｒｄｅｒを受け取り、そのＯｒｄｅｒの内容に従ってパスやＮＥの設定、生成、削除などが行われるよう設定要求（＝ＮＥ設定要求）をＮＥ管理システム３０に送る。このＮＥ設定要求は、ＮＥメディエーション３１〜３２を介してＡＴＭ−ＭＵＸ３００（実線矢印）およびＢＴＳ側のＡＴＭ−ＭＵＸ４００を経由してＡＴＭ−Ｓ−ＭＵＸ（点線矢印）５００に送られ、それぞれのＮＥにおいて該ＮＥ設定要求に含まれる情報の内容に従ったパスの設定やＮＥの設定が行われる。
【００３１】
このように各ＮＥの設定、パスの設定はパス設計システム１０から送出されるＯｒｄｅｒに基づいて行われる。
【００３２】
図２は、送信Ｏｒｄｅｒのイメージを示す図である。同図に示すように、送信Ｏｒｄｅｒには、ＮＥに対するＯｒｄｅｒ（例：ＡＴＭ−ＭＵＸ３００、４００、ＡＴＭ−Ｓ−ＭＵＸ５００の送信架や同装置内のＩＦ  Ｂｏａｒｄに対するＯｒｄｅｒ）やパスに対するＯｒｄｅｒ（例：ＶＰやＶＣ（ＶＣ４／３２）に対するＯｒｄｅｒ）等がある。
【００３３】
また、ＮＭＳ２０では、受信したＯｒｄｅｒを予め定められた実行順序にて実行する。このＮＭＳでなされるＯｒｄｅｒの実行順序の説明は後述する（後述する説明（２）を参照）。
【００３４】
また、ＮＭＳ２０ではＯｒｄｅｒが実行されると、Ｏｒｄｅｒ処理の進捗通知をパス設計システムに行う。本発明では、この進捗通知を、業務プロセスごとに行うのでなく、Ｏｒｄｅｒ管理系とＯｒｄｅｒ実行系のプロセスに分けて配置し、互いのプロセス間通信のみでＯｒｄｅｒの進捗管理を実現する（詳細説明は、後述する説明（３）を参照）。
【００３５】
尚、ＮＥにおけるＲＮＣ側のＡＴＭ−ＭＵＸ３００とＢＴＳ側のＡＴＭ−ＭＵＸ４００の通信はマイクロ波帯のエントランス回線を利用する形態であっても、ＳＤＨ（ｓｙｎｃｈｒｏｎｏｕｓ  ｄｉｇｉｔａｌ  ｈｉｅｒａｒｃｈｙ）伝送装置を利用する形態であってもよく、いずれの形態でも本発明を限定するものでない。
【００３６】
図３は、本発明のネットワーク管理システムの一構成であるパス設計システム１０の機能ブロックの構成例を示すものである。
【００３７】
図３において、このパス設計システム１０は、クライアント／サーバー・システムであって、クライアント側は、オペレーティング・システム（Ｗｉｎｄｏｗｓ（ＮＴ））１１、業務用アプリケーション（Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｅｘｃｅｌ等）１２、オラクルが提供するデータベース・サーバーとアクセスするためのインタフェース（Ｏｒａｃｌｅ  Ｎｅｔ８）１３などが備えられる。一方、サーバー側は、オペレーティング・システム（ＵＮＩＸのＳｏｌａｒｉｓ）１４、オラクルが提供するデータベース（Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））１５、クライアント側とアクセスするためのインタフェース（Ｏｒａｃｌｅ  Ｎｅｔ８）１６、業務用アプリケーション１７、ＢＴＳ６００やＲＮＣ２００の無線ネットワーク装置（ＲＡＮ：Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）の無線諸元に係る情報を得るための通信用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）１８が備えられる。また、上記通信用ＡＰＩには、ＬＡＮでＮＭＳ２０との通信を行うプロトコルなどが備えられる。
【００３８】
図４は、本発明のネットワーク管理システムの一構成であるＮＭＳ２０の機能ブロックの構成例を示すものである。
【００３９】
図４において、このＮＭＳ２０は信頼性向上のため二重化（０系、１系）がとられる。０系、１系とも同構成であるので、以下、０系を例にとり説明する。
【００４０】
本ＮＭＳ２０の０系は、オペレーティング・システム（ＵＮＩＸのＳｏｌａｒｉｓ）２１、オラクルが提供するデータベース（Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））２２、通信ＡＰＩ２３、
業務用アプリケーション２４、冗長構成共通ＡＰＩ２５とで構成される。通信ＡＰＩは、パス設計システム１０やＮＭＳ２０用のＧＵＩ（ｇｒａｐｈｉｃａｌ  ｕｓｅｒ  ｉｎｔｅｒｆａｃｅ）ならびにＮＥ管理システム３０と接続するための通信インタフェース機能を備える。
【００４１】
上記データベースには、パス設計システムから受信したＯｒｄｅｒを格納するデータベース（以下、オーダーＤＢという）と、移動通信ネットワークのすべての構成に係るデータを格納するデータベース（以下、構成ＤＢという）とが備えられる。
図５は、本発明のネットワーク管理システムの一構成であるＮＥ管理システム３０の機能ブロックの構成例を示すものである。
【００４２】
図５において、このＮＥ管理システム３０は前述したＮＭＳ２０と同様に信頼性向上の見地から二重化（０系、１系）がとられる。０系、１系とも同構成であるので、以下、０系を例にとり説明する。
【００４３】
本ＮＥ管理システム３０の０系は、オペレーティング・システム（ＵＮＩＸのＳｏｌａｒｉｓ）５１、オラクルが提供するデータベース（Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））５２、通信ＡＰＩ５３、業務用アプリケーション５４、冗長構成共通ＡＰＩ５５とで構成される。通信ＡＰＩ５３には、ＧＵＩを持つ総合保守端末、ＮＭＳ２０およびＮＥメディエーション３１〜３２と通信をするための通信インタフェース機能が備えられる。
【００４４】
次に、ＶＰやＮＥの構築形態に応じてＯｒｄｅｒの送出形態を変える実施例について詳述する。
【００４５】
（説明１）
ＲＡＮのパス構築には、計画的に行う場合（初期構築）と、計画外の突発的な需要に対応する場合（追加構築）の２つがある。本発明では、前者に対応したＯｒｄｅｒを「通常Ｏｒｄｅｒ」、後者に対応したＯｒｄｅｒを「緊急Ｏｒｄｅｒ」とし、ＶＰやＮＥの構築形態によって両者のＯｒｄｅｒを使い分ける。
【００４６】
以下、それぞれのＯｒｄｅｒについて説明する。
【００４７】
図６は、通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒの流れを示す図である。
【００４８】
同図に示すように、通常Ｏｒｄｅｒは、パス設計システム１０において作成された網の設計情報を基に、自動的に該パス設計システム１０内で生成され、その後ＮＭＳ２０に自動送信される。ＮＭＳ２０はそのＯｒｄｅｒを受信した後、受信したＯｒｄｅｒに対してパラメータチェック等の事前処理を行う。その後の日次バッチ処理において、実行日となるＯｒｄｅｒの検索を行い、対象Ｏｒｄｅｒがあれば実行する。
【００４９】
一方、緊急Ｏｒｄｅｒは、パス設計システム１０でのＯｒｄｅｒ作成までは前述した通常Ｏｒｄｅｒと同じであるが、Ｏｒｄｅｒ自動生成後、パス設計システム１０に蓄積される。これは、ＮＥの物理的な工事が完了次第、設計者が自由に複数選択してＮＭＳ２０へ手動送信できるようにするためである。ＮＭＳ２０へ送信するＯｒｄｅｒは、設計者がＯｒｄｅｒを任意に選択して個別に送信したり、あるパスに関連するＯｒｄｅｒ（物理および論理に関連するＯｒｄｅｒ）をまとめて送信したりすることができる。ＮＭＳ２０はＯｒｄｅｒ受信後、受信したＯｒｄｅｒのパラメータチェック等の事前処理後、即時に各実行処理を行う。この実行処理は、ＮＥ情報設定から工事設定解除まで連続して実行される。
【００５０】
上述したように本実施例によれば、通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒの２種類のＯｒｄｅｒを用意し、サービス開始前にサービス提供地域全体に対して行われる初期構築に対しては通常Ｏｒｄｅｒを、当初の計画外のＶＰを構築する必要が生じた場合は手動でＯｒｄｅｒ送信可能な緊急Ｏｒｄｅｒを用いる。例えば、特定地域のＶＰを短期間で構築しなければならない場合には、緊急Ｏｒｄｅｒを用いれば遅滞なく速やかなパス開通が可能である。従って、通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒとを使い分けることでパスの開通形態によらずパス設計システム〜ＮＭＳ間フロースルー化（自動化）が実現できる。
【００５１】
次に、ＮＭＳ２０で実行されるＯｒｄｅｒの実行順序について説明する。
【００５２】
（説明２）
まず、ＮＭＳ２０で実行されるＯｒｄｅｒの種類と実行順序について図７を参照しながら説明する。
【００５３】
同図に示すように、Ｏｒｄｅｒの工程種別には「廃止」と「新設」の２つがあり、Ｏｒｄｅｒの種類には、ＡＴＭ関連のＯｒｄｅｒとして、「ＶＰ」、「ＶＣ４／３２パス」、「ＩＦボード」、「グループ」、「ユニット」、「装置架」ある。これらのＯｒｄｅｒのうち、「ＶＰ」と「ＶＣ４／３２パス」は論理系リソース、他は物理系リソースである。論理系のリソースは、物理系リソースに依存していて、廃止の場合であれば、論理系リソース→物理系リソースの順、新設の場合であれば、物理系リソース→論理系リソースに順でＯｒｄｅｒが実行される。尚、同一リソースに対する廃止は、新設が正常終了しない限り、設計できない。つまり、あるＶＰを廃止するには、必ず該ＶＰが新設されていなければならない。
【００５４】
このようにＮＭＳ２０は、上記のような実行順序に従ってＯｒｄｅｒを実行する。
【００５５】
次に、上記実行順序に基づいてＮＭＳ２０で実行されるＯｒｄｅｒ処理の流れについて図８を参照しながら説明する。
【００５６】
図８において、パス設計システム１０は、ＮＭ２０Ｓに対して順不同で任意の種類のＯｒｄｅｒを複数送信（手動送信、自動送信いずれであってもよい）する。ＮＭＳ２０は、受信したＯｒｄｅｒをオーダーＤＢに格納する（▲１▼）。オーダーＤＢは格納したＯｒｄｅｒを図７で示したＯｒｄｅｒ実行順序の順番に検索する。具体的には、「ＶＰの廃止があるかないか」→「ＶＣ４／３２の廃止があるかないか」のような順（廃止Ｏｒｄｅｒであれば論理系リソースから物理系リソースの順に、新設Ｏｒｄｅｒであれば物理系リソースから論理系リソースの順）に検索し、該当するものがあればそれを構成ＤＢに登録（▲２▼）する。構成ＤＢでは、新設のオーダーに対してはレコードを新たに挿入（▲５▼）し、廃止のオーダーに対しては廃止フラグを立てる（▲４▼）。その際、構成ＤＢはそのＯｒｄｅｒの依存関係をチェック（▲３▼）してから登録を行う。構成ＤＢにてなされる依存関係チェックとは、次のようなチェックである。あるリソースを新規に生成するためには、依存するリソースが既に存在するか、またはそのリソースの新規オーダーがあることが必要である。例えば、あるＶＰを新設する場合、それを構成するＶＣ４／３２が存在しているかどうかがチェックされる。また、装置架を廃止するためにはその装置架に対応付けられたＩＦボード〜ＶＰまでが既に廃止されているかどうかがチェックされる。
【００５７】
尚、上記構成ＤＢには既存のネットワークに関する全てのデータが格納される。構成ＤＢではオーダーが正常に登録される度にデータベースを更新し、その結果を進捗更新としてオーダーＤＢに通知（▲６▼）する。このようにして進捗更新通知がオーダーＤＢになされると、オーダーＤＢは、格納しているオーダーに対するＮＥ設定のための設定要求をＮＥ管理システムに送る。尚、ＮＥ設定要求に対するＮＥ設定が失敗したときは、オーダーＤＢはロールバック、つまり、先に挿入した新設Ｏｒｄｅｒや廃止Ｏｒｄｅｒを構成ＤＢから探し出して、挿入したレコードについてはもとに戻したり、廃止フラグを立てたレコードについては廃止を取り消したりする（▲７▼）。
【００５８】
上述したように、本実施例によれば、構成ＤＢにて依存関係がチェックされたオーダーに対応するＮＥ設定要求がオーダーＤＢより一括してＮＥ管理システムに送られてＮＥ設定やパス設定が行われる。すなわち、従来のようにＯｒｄｅｒ個別に処理を行うのでなく、競合しないＯｒｄｅｒを並列で処理するようにするので、パス開通が多いような初期構築や計画されたパス構築においてはＯｒｄｅｒ数に応じた処理時間の線形増加を防ぐことができ、パス開通を効率的に行うことができる。
ところで、ＮＭＳ２０は、各Ｏｒｄｅｒの各実行処理フェーズの結果を、進捗通知を用いてパス設計システム１０に通知するが、本発明では、業務プロセスごとに進捗通知を行うのでなく、プロセスをＯｒｄｅｒ管理系とＯｒｄｅｒ実行系に分けて配置し、プロセス間通信を行って進捗を管理する。以下、具体例について説明する。
（説明３）
図９は、プロセスの配置法を図示したものである。
同図に示すように、プロセスをＯｒｄｅｒ管理系と、Ｏｒｄｅｒ実行系とに分けることで、パス設計システムのＯｒｄｅｒ管理プロセス（▲１▼）と、ＮＭＳのＯｒｄｅｒ実行ワークフロープロセス（▲２▼）のやり取りのみでＯｒｄｅｒ進捗の共有と管理が可能となる。
従って、本実施例によれば、ＮＭＳ２０内での進捗管理の複雑化を防止することができる。
ＮＭＳ２０ではＯｒｄｅｒ受信後、Ｏｒｄｅｒ実行系プロセスを１つずつ起動する。実行中にエラーとなった場合、パス設計システム１０へ通知される。
図１０にＯｒｄｅｒ進捗管理プロセス及びＯｒｄｅｒ実行ワークフロープロセス各々で管理するＯｒｄｅｒの状態を示す。
同図に示すように、パス設計システム１０の進捗管理（▲１▼）では、Ｏｒｄｅｒ作成中（Ａ）、Ｏｒｄｅｒ実行中（Ｂ）、サービス中（Ｃ）という大まかな状態を管理しているのに対し、ＮＭＳ２０の実行ワークフロー（▲２▼）では、Ｏｒｄｅｒ実行中におけるより詳細な状態を管理している。
【００５９】
また、統合保守端末のプロセスは、実行ワークフローをＧＵＩ上から直接操作でき、緊急Ｏｒｄｅｒの進捗状況の参照、取消、ＮＧのＯｒｄｅｒの再実行が可能である。このときの実行結果は、Ｏｒｄｅｒ実行ワークフローを通じてパス設計システムのＯｒｄｅｒ管理プロセスへ通知される。
【００６０】
従って、本実施例によれば、プロセスの配置と、Ｏｒｄｅｒ進捗管理形態を適用することで、パス設計システムとＮＭＳの独立性を確保することができる。
【００６１】
上記例において、パス設計システム１０の通信ＡＰＩ１８の通信機能が網構築形態別オーダー送信手段、オーダー自動送信手段、オーダー手動送信手段に対応し、業務アプリケーション１２、１７のプロセス管理機能がオーダー管理プロセス手段に対応する。
【００６２】
また、ＮＭＳ２０の業務アプリケーション２４、２５の情報処理機能がオーダー実行手段、バッチ処理手段、オーダー手動送信手段に、同業務アプリケーション２４、２５のプロセス管理機能がオーダー実行プロセス手段対応する。データベース（Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））２２、２７と業務アプリケーション２４、２５の連携処理機能がパラメータ確認手段、オーダー検索手段、依存関係判定手段に対応し、データベース（Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））２２、２７のデータ登録機能がオーダー格納手段、構成データベース登録手段に対応する。さらに、通信ＡＰＩ２３の通信機能が進捗状態更新通知手段に対応する。
【００６３】
【発明の効果】
以上、説明したように、請求項１乃至９記載の本願発明によれば、バッチ処理によるスケジュールに沿った開通が可能な通常Ｏｒｄｅｒと、設計後、即座に開通可能な緊急Ｏｒｄｅｒとを用意するので、それぞれのパスの構築形態で効率良くパス構築を行うことができる。
【００６４】
また、ＮＭＳでは実行するＯｒｄｅｒの順序を廃止Ｏｒｄｅｒ→新設Ｏｒｄｅｒの順で実行されるよう順序制御を行うので、サービスを提供している回線の誤切断を防ぐことができると共に、Ｏｒｄｅｒの一括処理が行えるためパス構築に要する時間を極力抑えることができる。
【００６５】
さらに、パス設計システムのＯｒｄｅｒ進捗プロセスとＮＭＳのＯｒｄｅｒ実行ワークプロセスでＯｒｄｅｒ進捗管理を行うことでＯｒｄｅｒ進捗の共有と管理が可能となるため、パス設計システムとＮＭＳ間の連携が複雑になるという問題を解決することができる。
【００６６】
また、請求項１０乃至１３記載の本願発明によれば、上記のようなネットワーク管理システムで適用することのできるオーダー実行順序制御方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の一形態に係る移動通信ネットワーク管理におけるオペレーションシステムの構成例および該オペレーションシステムの管理対象となる管理対象装置の一例を示す図である。
【図２】送信Ｏｒｄｅｒのイメージを示す図である。
【図３】パス設計システムの構成例を示す図である。
【図４】ＮＭＳの構成例を示す図である。
【図５】ＮＥ管理システムの構成例を示す図である。
【図６】通常Ｏｒｄｅｒと緊急Ｏｒｄｅｒの流れを示す図である。
【図７】Ｏｒｄｅｒの種類と実行順序を示す図である。
【図８】ＮＭＳで実行されるＯｒｄｅｒ処理の流れを示す図である。
【図９】プロセスの配置法を示す図である。
【図１０】Ｏｒｄｅｒ進捗管理プロセス及びＯｒｄｅｒ実行ワークフロープロセス各々で管理するＯｒｄｅｒの状態を示す図である。
【符号の説明】
１０  パス設計システム
１１  オペレーティング・システム（Ｗｉｎｄｏｗｓ（ＮＴ））
１２、１７、２４、２９、５４、５９  業務用アプリケーション（Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｅｘｃｅｌ等）
１３、１６  データベース・サーバーアクセスインタフェース
１４、２１、２６、５１、５６  オペレーティング・システム（ＵＮＩＸのＳｏｌａｒｉｓ）
１５、２２、２７、５２、５７  Ｏｒａｃｌｅ  ８（ＲＤＢＭＳ））
１８、２３、３０、５３、６０  通信用ＡＰＩ
２０  ＮＭＳ
２５、２８、５５、５８  冗長構成共通ＡＰＩ
３０  ＮＥ管理システム
３１、３２  ＮＥメディエーション
１００  オペレーションシステム
２００  ＲＮＣ
３００、４００  ＡＴＭ−ＭＵＸ
５００  ＡＴＭ−Ｓ−ＭＵＸ
６００  ＢＴＳ
【図１】
0003581133.tif 000002
【図２】
0003581133.tif 000003
【図３】
0003581133.tif 000004
【図４】
0003581133.tif 000005
【図５】
0003581133.tif 000006
【図６】
0003581133.tif 000007
【図７】
0003581133.tif 000008
【図８】
0003581133.tif 000009
【図９】
0003581133.tif 000010
【図１０】
0003581133.tif 000011