JP5870842B2 - 収容設計プログラム、収容設計装置及び収容設計方法 - Google Patents

Description

本発明は、収容設計プログラム、収容設計装置及び収容設計方法に関する。

光ネットワークの設計では、光パス収容設計技術により、ＮＷ（Network）に収容する光パスの本数、使用帯域、光ファイバの経路等が設計される。そして、「局舎（ノード）」毎に、光パスの本数、使用帯域、光ファイバの経路等を設計した後、通信機器をどのように配備するかの収容設計が行なわれる。尚、光パスは、例えば、ＯＴＮ（Optical Transfer Network）収容設計の場合、ＨＯ−ＯＤＵ（Higher-Order Optical channel Data Unit）の光パスである。

図１３は、ハード容量が無制限のシェルフを備えたノードの一例を示す説明図である。ハード容量とは、例えばシェルフに収容するハードウェアの数量や筐体容積である。図１３に示すノード２００は、シェルフ２０１を有する。シェルフ２０１は、複数の光送受信器等のＮＷ側通信カード２０２と、複数の電気送受信器等のクライアント（ＣＬ）側通信カード２０３と、ＳＷＦ（Switch Fabric）２０４とを有する。ＮＷ側通信カード２０２は、１０Ｇｂｐｓ（Bits Per Second）や１００Ｇｂｐｓの信号帯域の光パスと接続する。尚、説明の便宜上、「Ｇｂｐｓ」は、単に「Ｇ」と称する。ＣＬ側通信カード２０３は、１．２５Ｇ、２．５Ｇや１０Ｇの信号帯域の電気パスと接続する。シェルフ２０１内のハード容量が無制限の場合、全てのＮＷ側通信カード２０２及びＣＬ側通信カード２０３を一台のシェルフ２０１に収容できる。従って、収容設計は必要ない。

しかしながら、現実には、シェルフ２０１のハード容量は有限であるため、シェルフ２０１の台数、シェルフ２０１の最大容積、シェルフ２０１間の通信容量等の全ての条件を考慮しながらの収容設計が必要である。従って、ノード２００においてハード容量が有限の複数のシェルフ２０１を備え、シェルフ２０１内にＮＷ側通信カード２０２及びＣＬ側通信カード２０３を収容するマルチシェルフ収容設計が重要となる。

また、シェルフ２０１は、ラック内に搭載されるため、ラックの占有床面積を考慮すると、ラックは１台が望ましい。しかし、現実には、シェルフ２０１が複数必要となるため、ラックのシェルフ最大収容数を考えると、ラックを複数要する。

すなわち、マルチシェルフ収容設計は、ＮＷ側通信カード２０２及びＣＬ側通信カード２０３をシェルフ２０１内にどのように収容するかという設計と言える。また、ＮＷ側通信カード２０２及びＣＬ側通信カード２０３は、直接シェルフ２０１に格納されるわけではなく、ＩＦＣ（Interface Card）内に収容される。そして、各ＩＦＣは、シェルフ２０１内に収容される。また、シェルフ相互間の通信は、ＮＷ内のＤｅｍａｎｄの光パス間の接続の変更（以下、「乗換」とする）、すなわちＮＷ側通信カード２０２間の乗換が生じる場合に発生する。従って、シェルフ相互間の通信には、シェルフ相互間通信用のＩＦＣを要する。

従って、マルチシェルフ収容設計では、ＮＷ側通信カード２０２やＣＬ側通信カード２０３をシェルフ２０１内に効率良く収容するための「箱詰め」問題を解くために用いられる「貪欲法」を採用することも考えられる。貪欲法は、サイズが大きな要素（ＩＦＣ）から、箱（シェルフ）に詰められるだけ詰め、詰められなくなった時点で新たな箱（シェルフ）を増やし、再び、新たな箱（シェルフ）に要素を詰め込む方法である。

特開平１１−８６４１号公報

しかしながら、貪欲法を使用してマルチシェルフ収容設計を実行することも考えられるが、各要素を詰め込む順番に結果が左右されてしまうため、シェルフの台数を最小限に抑制できる保証はない。

一つの側面では、シェルフの台数をより抑えることができる収容設計プログラム、収容設計装置及び収容設計方法を提供することを目的とする。

一つの案では、コンピュータに、第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報を収集させる。コンピュータに、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報とを収集させる。更に、コンピュータに、前記シェルフ相互間の通信に使用できる通信制限容量を収集させる。更に、コンピュータに、カード情報、個数情報、シェルフ情報、対応情報及び通信制限容量に基づき、設計対象の第１の通信カード及び第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成させる。更に、コンピュータに、前記整数計画モデルを実行させることで、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力させる。

開示の態様では、シェルフの台数をより抑えることができる。

図１は、本実施例の収容設計装置の一例を示す説明図である。 図２は、光ネットワークの一例を示す説明図である。 図３は、ノードの一例を示す説明図である。 図４は、シェルフ相互間通信の一例を示す説明図である。 図５Ａは、グループ定義の一例を示す説明図である。 図５Ｂは、シェルフ内の各ＩＦＣの収容イメージの一例を示す説明図である。 図６は、マルチシェルフ収容設計処理に関わるＣＰＵの処理動作の一例を示すフローチャートである。 図７Ａは、シェルフ相互間の接続形態の一例（直列接続）を示す説明図である。 図７Ｂは、シェルフ相互間の接続形態の一例（リング接続）を示す説明図である。 図８は、整数計画モデルの変数及び制約条件の一例を示す説明図である。 図９は、第１のテーブルの一例を示す説明図である。 図１０は、第２のテーブルの一例を示す説明図である。 図１１Ａは、比較例（貪欲法）の設計結果の一例を示す説明図である。 図１１Ｂは、比較例（貪欲法）の設計結果に基づくラック搭載の一例を示す説明図である。 図１２Ａは、本実施例の設計結果の一例を示す説明図である。 図１２Ｂは、本実施例の設計結果に基づくラック搭載の一例を示す説明図である。 図１３は、ハード容量が無制限のシェルフを備えたノードの一例を示す説明図である。

以下、図面に基づいて、本願の開示する収容設計プログラム、収容設計装置及び収容設計方法の実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。

図１は、本実施例の収容設計装置の一例を示す説明図である。図１に示す収容設計装置１は、設計対象のＮＷ側通信カード及びＣＬ側通信カードが格納された複数のＩＦＣを２以上のシェルフ内に効率良く収容できるマルチシェルフ収容設計を実現するものである。尚、収容設計装置１は、一例として、パーソナルコンピュータやワークステーション等で構成する。

収容設計装置１は、入力装置１１と、出力装置１２と、ドライブ装置１３と、補助記憶装置１４と、主記憶装置１５と、ＣＰＵ（Central Processing Unit）１６と、データベース１７とを有する。これらの各要素はシステムバス１８で相互に接続される。入力装置１１は、ユーザが操作するキーボード及びマウス等を含み、各種データの入力を受け付ける。出力装置１２は、マルチシェルフ収容設計のプログラムを操作するために要する各種ウィンドウや設計結果等のデータ等を表示するディスプレイを含む。出力装置１２は、実行プログラムの動作に基づいて、各種ウィンドウや設計結果等のデータ等をディスプレイに表示する。実行プログラムは、例えば、光若しくは磁気により情報を記録するディスク媒体やフラッシュメモリ等の記録媒体１９に記録され、提供される。プログラムを記緑した記録媒体１９はドライブ装置１３に装着される。ドライブ装置１３は、記録媒体１９に格納された実行プログラムを読み出し、読み出された実行プログラムを主記憶装置１５に展開する。また、ＣＰＵ１６は、収容設計装置１全体を制御する。ＣＰＵ１６は、主記憶装置１５に展開された実行プログラムに基づき、各種演算処理を実行する。

図２は、光ネットワークの一例を示す説明図である。図２に示す光ネットワーク２は、光パス３上を伝送する光信号を光波長単位で分岐又は挿入する複数のＯＡＤＭ（Optical Add-Drop Multiplexer:光分岐挿入装置）のノード４を有する。各ノード４は、後述するシェルフ５を搭載したラック内に搭載して構成される。本実施例では、マルチシェルフ収容設計において、２以上のシェルフ５内に設計対象の複数のＩＦＣ６等を効率良く収容することで、ノード４内のシェルフ５の台数を最小限に抑える。

図３は、ノード４の一例を示す説明図である。ノード４内の各シェルフ５は、例えば、１０Ｇ／１００Ｇの信号帯域の光パス３上の光信号と、１．２５Ｇ／２．５Ｇ／１０Ｇの信号帯域の電気パス上の電気信号とに相互に変換する通信カードを搭載する。また、シェルフ５は、例えば、第１のシェルフ５Ａと、第２のシェルフ５Ｂと、第３のシェルフ５Ｃ等とを有する。シェルフ５は、複数のＩＦＣ６と、ＳＷＦ７とを有する。例えば、格納カードの一例とした各ＩＦＣ６は、例えば、第１の通信カードの一例としてのＮＷ側通信カード２１や、第２の通信カードの一例としてのＣＬ側通信カード２２を格納している。また、シェルフ５相互間の通信は、例えば、第１のシェルフ５Ａと第２のシェルフ５Ｂとの間の通信である。そして、シェルフ５相互間の通信は、シェルフ相互間通信用のＩＦＣ６Ａを使用して通信接続するものである。また、各ＣＬ側通信カード２２は、予め定められた指定のＮＷ側通信カード２１と接続する。そして、ＣＬ側通信カード２２及びＮＷ側通信カード２１は、同一シェルフ５内に収容される。従って、収容設計装置１では、ＣＬ側通信カード２２と、このＣＬ側通信カード２２が通信するＮＷ側通信カード２１とを対応付けた対応情報をグループ単位に管理する。

図４は、シェルフ５相互間通信の一例を示す説明図である。図４に示す第１のシェルフ５Ａ内のＮＷ側通信カード２１のＩＦＣ６は、ＮＷ内の第１の光パス３Ａを通じてＤｅｍａｎｄを受信し、ＳＷＦ７を通じてシェルフ相互間通信用のＩＦＣ６Ａに伝送する。更に、第１のシェルフ５Ａ内のシェルフ相互間通信用のＩＦＣ６Ａは、受信したＤｅｍａｎｄを、ＳＷＦ７を通じて第２のシェルフ５Ｂに伝送する。第２のシェルフ５Ｂ内のシェルフ相互間通信用のＩＦＣ６Ａは、第１のシェルフ５ＡからＮＷ内のＤｅｍａｎｄを受信し、ＳＷＦ７を通じてＮＷ側通信カード２１のＩＦＣ６に伝送する。そして、第２のシェルフ５Ｂ内のＮＷ側通信カード２１のＩＦＣ６は、第１のシェルフ５ＡからのＤｅｍａｎｄをＮＷ内の第２の光パス３Ｂに伝送する。つまり、ＮＷ内の第１の光パス３Ａで受信したＤｅｍａｎｄを第２の光パス３Ｂに伝送する光パス３相互間で乗換が生じた場合に、シェルフ５相互間の通信が発生する。

図５Ａは、グループ定義の一例を示す説明図である。図５Ａに示すＣＬ側通信カード２２は、通信接続に際し、指定のＮＷ側通信カード２１が予め設定されているため、組み合わせに応じてグループ化される。例えば、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａ及び１０ＧのＣＬ側通信カード２２Ｂは、通信接続に際し、指定の１００ＧのＮＷ側通信カード２１Ａと接続する。従って、ＣＬ側通信カード２２Ａ、ＣＬ側通信カード２２Ｂ及びＮＷ側通信カード２１Ａは、同一のグループＧ１である。また、例えば、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａは、通信接続に際し、指定の１０ＧのＮＷ側通信カード２１Ｂと接続する。従って、ＣＬ側通信カード２２Ａ及びＮＷ側通信カード２１Ｂは、同一のグループＧ７である。

図５Ｂは、シェルフ５内の各ＩＦＣ６の収容イメージの一例を示す説明図である。図５Ｂに示すシェルフ５は、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａが格納されるＩＦＣ６Ｂと、１０ＧのＣＬ側通信カード２２Ｂが格納されるＩＦＣ６Ｃとを有する。更に、シェルフ５は、１０ＧのＮＷ側通信カード２１Ｂが格納されるＩＦＣ６Ｄと、１００ＧのＮＷ側通信カード２１Ａが格納されるＩＦＣ６Ｅと、シェルフ相互間通信用のＩＦＣ６Ａとを収容する。

ＩＦＣ６Ｂは、最大４０個の１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを格納できる。尚、ＩＦＣ６Ｂの使用スロット数は２個である。ＩＦＣ６Ｃは、最大１０個の１０ＧのＣＬ側通信カード２２Ｂを格納できる。尚、ＩＦＣ６Ｃの使用スロット数は２個である。ＩＦＣ６Ｄは、最大５個の１０ＧのＮＷ側通信カード２１Ｂを格納できる。尚、ＩＦＣ６Ｄの使用スロット数は２個である。ＩＦＣ６Ｅは、最大１個の１００ＧのＮＷ側通信カード２１Ａを格納できる。尚、ＩＦＣ６Ｅの使用スロット数は４個である。シェルフ相互間通信用のＩＦＣ６Ａの使用スロット数は２個である。また、シェルフ５は、最大２４スロット分のＩＦＣ６を収容できる。

マルチシェルフ収容設計は、シェルフ数Ｎ、シェルフ数Ｎ及び通信カードｎの組み合わせＮ^ｎ、シェルフ５内で収容可能な最大スロット数、ＩＦＣ６の使用スロット数及びグループ間の通信確保の制約条件を満たしてシェルフ数を最小限に抑えることが求められる。

先ず、収容設計装置１は、設計対象のＮＷ側通信カード２１及びＣＬ側通信カード２２を含む全ＩＦＣ６が１台のシェルフ５内に収容できるか否かを確認した後、１台のシェルフ５で収容しきれない場合にマルチシェルフ収容設計処理を実行する。図６は、マルチシェルフ収容設計処理に関わるＣＰＵ１６の処理動作の一例を示すフローチャートである。図６に示すマルチシェルフ収容設計処理では、設計対象のＮＷ側通信カード２１及びＣＬ側通信カード２２を含む全ＩＦＣ６を最小限のシェルフ５内に効率良く収容できる設計結果を出力する処理である。

ＣＰＵ１６は、初期シェルフ数を設定する（ステップＳ１１）。尚、初期シェルフ数とは、全ＩＦＣ６を１台のシェルフ５で収容しきれない場合に本処理を起動する。従って、初期シェルフ数は、例えば、“２”である。ＣＰＵ１６は、シェルフ５相互間の接続形態に応じてシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数を決定する（ステップＳ１２）。

更に、ＣＰＵ１６は、シェルフ相互間通信用のＩＦＣ６Ａのスロット数を決定した後、現在の設定条件に対応したマルチシェルフ収容設計問題の整数計画モデルを生成する（ステップＳ１３）。ＣＰＵ１６は、生成された整数計画モデルを実行することで問題を解く（ステップＳ１４）。

ＣＰＵ１６は、問題に対する設計可能解があるか否かを判定する（ステップＳ１５）。ＣＰＵ１６は、設計可能解がある場合（ステップＳ１５肯定）、設計結果を出力装置１２に出力し（ステップＳ１６）、図６に示す処理動作を終了する。また、ＣＰＵ１６は、問題に対する設計可能解がない場合（ステップＳ１５否定）、変更できるシェルフ５相互間の接続形態があるか否かを判定する（ステップＳ１７）。尚、シェルフ５の接続形態とは、例えば、後述する図７Ａ及び図７Ｂに示す「直列接続」や「リング接続」等である。

ＣＰＵ１６は、変更できるシェルフ５相互間の接続形態がある場合（ステップＳ１７肯定）、変更できる接続形態を設定する（ステップＳ１８）。そして、ＣＰＵ１６は、設定された接続形態に応じてシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数を決定すべく、ステップＳ１２に移行する。その結果、シェルフ５相互間の接続形態を反映して新たな整数計画モデルを生成する。

ＣＰＵ１６は、変更できるシェルフ５相互間の接続形態がない場合（ステップＳ１７否定）、設定シェルフの台数を増加し（ステップＳ１９）、シェルフ相互間通信用のＩＦＣ６Ａの使用スロット数を決定すべく、ステップＳ１２に移行する。その結果、シェルフ数を増やして新たな整数計画モデルを生成する。

図６に示すマルチシェルフ収容設計処理のＣＰＵ１６は、現在の設定条件に応じた整数計画モデルを生成し、生成された整数計画モデルを実行する。ＣＰＵ１６は、整数計画モデルで設計可能解がある場合、その設計可能解に対応した設計結果を出力する。

また、ＣＰＵ１６は、整数計画モデルの設計可能解がなく、変更できるシェルフ５相互間の接続形態がある場合、変更できる接続形態を設定し、新たに整数計画モデルを生成する。その結果、新たな整数計画モデルが生成できる。

また、ＣＰＵ１６は、整数計画モデルの設計可能解がなく、しかも、変更できるシェルフ５相互間の接続形態がない場合、シェルフ数を増やして、新たに整数計画モデルを生成する。その結果、新たな整数計画モデルが生成できる。

尚、ステップＳ１１の初期シェルフ数の設定は、通常、「２」を設定するが、例えば、増やす場合には１台を基本とする。しかし、シェルフ５を搭載するラックの床占有面積の削減が重要の場合には柔軟に設定可能である。例えば、最大３台までのシェルフが搭載可能なラックの場合、シェルフ台数の増加よりもラック台数の増加のインパクトが大きいため、この場合、初期シェルフ数を「３」に設定する。そして、３台のシェルフで収容が失敗した場合には次に更に３シェルフ増やして「６」としても良い。

図７Ａは、シェルフ５相互間の接続形態の一例（直列接続）を示す説明図、図７Ｂは、シェルフ５相互間の接続形態の一例（リング接続）を示す説明図である。シェルフ５相互間の接続形態は、様々な形態を考えられるが、接続帯域や接続トポロジ等で様々な接続形態を考え得るため、説明の便宜上、「直列接続」及び「リング接続」を例示するが、例示の接続形態に限定されるものではない。図７Ａに示す「直列接続」は、複数のシェルフ５を直列に接続する形態である。この場合、両側の終端のシェルフ５Ａ及び５Ｃのシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数は２スロット、中間のシェルフ５Ｂのシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数は４スロットである。従って、両側の終端のシェルフ５Ａ及び５Ｃは、中間のシェルフ５Ｂに比較し、シェルフ相互間通信用のＩＦＣ６Ａの使用スロット数を削減できる。図７Ｂに示す「リング接続」は、複数のシェルフ５Ａ，５Ｂ，５Ｃをリング状に接続する形態である。全シェルフ５Ａ，５Ｂ，５Ｃのシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数は、４スロットであるため均等となる。

次にマルチシェルフ収容設計問題の整数計画モデルについて説明する。整数計画モデルの目的関数は、２以上のシェルフ５内のＮＷ側通信カード２１やＣＬ側通信カード２２を収容するＩＦＣ６のスロット数の合計を最小にする。その結果、ノード４内のシェルフ数を最小に抑えられる。

整数計画モデルの変数は、第１〜第４の変数を有する。第１の変数は、光パス３をシェルフ５内で使用するか否かを示すブール型の識別子である。第２の変数は、各シェルフ５内で使用できる各種のＩＦＣ６の個数（自然数）である。第３の変数は、光パス３の組み合わせがシェルフ５で分かれて収容されているか否かを示すブール型の識別子である。第４の変数は、シェルフ５相互間の接続形態が「リング接続」の場合に南回りの接続又は北回りの接続を示すブール型の識別子である。ここで、例えば、「南回り」は時計回りであり、「北回り」は反時計回りである。

整数計画モデルの制約条件は、第１〜第４の制約条件を有する。第１の制約条件は、各光パス３に対応するＮＷ側通信カード２１が必ずどれか１個のシェルフ５に収容する制約条件である。第２の制約条件は、各シェルフ５内でＩＦＣ６が格納できる、シェルフ情報の一例として、最大スロット数を示す制約条件である。第３の制約条件は、カード情報の一例として、各種ＩＦＣ６の通信カードの最大格納個数を示す制約条件である。第４の制約条件は、通信制限容量の一例として、各種シェルフ５相互間の最大通信容量を示す制約条件である。第４の制約条件は、対応関係の一例として、例えば、乗換が生じる２本の光パス３に対応するＮＷ側通信カード２１が、夫々どのシェルフ５に搭載されるかを管理するための制約条件である。尚、整数計画モデルは、具体的に数式として表現することが可能である。図８は、整数計画モデルの変数及び制約条件の一例を示す説明図である。

図８に示す「ｈ」は、ＮＷ側の光パス３を示す。「Ｈ１００」は、帯域１００Ｇの光パスｈの集合を示す。「Ｈ１０」は、帯域１０Ｇの光パスｈの集合を示す。「ｓ」は、ＳＷＦ７を有するシェルフ５を示す。「ＯＰ（ｈ，ｓ）」は、光パスｈをシェルフ５内で使用するか否かを示す識別子である。尚、使用の場合は「１」、使用しない場合は「０」である。

「ＮＷ＿１０Ｇ＿ＩＦＣ（ｓ）」は、シェルフ５内で１０ＧのＮＷ側通信カード２１Ｂを格納したＩＦＣ６Ｄの個数を示す。「ＣＬ＿１０Ｇ＿ＩＦＣ（ｓ）」は、シェルフ５内で１０ＧのＣＬ側通信カード２２Ｂを格納したＩＦＣ６Ｃの個数を示す。「ＣＬ＿１＿２．５Ｇ＿ＩＦＣ（ｓ）」は、シェルフ５内で１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを格納したＩＦＣ６Ｂの個数を示す。

「ｔｒａｎｓｆｅｒＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」は、例えば、光パスｈ１及び光パスｈ２がシェルフｓ１及びシェルフｓ２で分離して収容されているか否かを示す識別子である。尚、ｓ１及びｓ２に分離して収容されている場合は「０」、ｓ１及びｓ２で分離して収容されていない場合は「１」である。

「ＮｏｒｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」は、光パスｈ１及び光パスｈ２がシェルフｓ１及びシェルフｓ２で分離して収容されている場合に、どちらの回転方向からシェルフ相互間通信を行うかを示す識別子である。尚、「リング接続」において、光パスｈ１がシェルフｓ１内に収容、光パスｈ２がシェルフｓ２内に収容され、シェルフｓ２からシェルフｓ１への通信経路はｓ２→ｓ１の北回りと判定する。北回りの場合は「０」、北回りでない場合（南回り）は「１」である。「ＳｏｕｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」は、光パスｈ１及び光パスｈ２がシェルフｓ１及びシェルフｓ２で分離して収容されている場合に、どちらの回転方向からシェルフ相互間通信を行うかを示す識別子である。尚、「リング接続」において、光パスｈ１がシェルフｓ１内に収容、光パスｈ２がシェルフｓ２内に収容され、シェルフｓ１からシェルフｓ２への通信経路はｓ１→ｓ２の南回りと判定する。南回りの場合は「０」、南回りでない場合（北回り）は「１」である。

「Ｓｌｏｔ＿１００Ｇ＿ＮＷ＿ＩＦＣ」は、１００ＧのＮＷ側通信カード２１Ａを格納するＩＦＣ６Ｅのスロット数を示す。尚、今回は、例えば、「４」である。「Ｓｌｏｔ＿１０Ｇ＿ＮＷ＿ＩＦＣ」は、１０ＧのＮＷ側通信カード２１ＢのＩＦＣ６Ｄのスロット数を示す。尚、今回は、例えば、「２」である。「Ｓｌｏｔ＿１０Ｇ＿ＣＬ＿ＩＦＣ」は、１０ＧのＣＬ側通信カード２２ＢのＩＦＣ６Ｃのスロット数を示す。尚、今回は、例えば、「２」である。「Ｓｌｏｔ＿１＿２．５Ｇ＿ＣＬ＿ＩＦＣ」は、１０Ｇ以外（今回は１Ｇや２．５Ｇ）のＣＬ側通信カード２２ＡのＩＦＣ６Ｂのスロット数を示す。尚、今回は、例えば、「２」である。

「ＳｈｅｌｆＳｌｏｔＣａｐ」は、１台のシェルフ５当たりで使用できる最大スロット数を示す。尚、今回は、例えば、「２４」である。「ＲｓｖｄＳｌｏｔＦｏｒＩＣ（ｓ）」は、１台のシェルフ５当たりでシェルフ相互間通信用に使用するＩＦＣのスロット数を示す。「ＯＰ＿ＢＷ（ｈ）」は、光パスｈの帯域を示す。尚、今回は、１０Ｇの場合は「８」、１００Ｇの場合「８０」である。

「１＿２．５ＧＡｄｄＤｎｄＮｕｍ（ｈ）」は、光パスｈ１００又は光パスｈ１０に属する現在ノードからＡｄｄされる１Ｇ及び２．５ＧのＤｅｍａｎｄ本数の合計を示す。「１０ＧＡｄｄＤｎｄＮｕｍ（ｈ）」は、光パスｈ１００又は光パスｈ１０に属する現在ノード４からＡｄｄされる１０ＧのＤｅｍａｎｄ本数の合計を示す。

「Ｌｉｍｉｔ＿１０Ｇ＿ＮＷ＿ＩＦＣ」は、１０ＧのＮＷ側通信カード２１ＢのＩＦＣ６Ｄに格納できる１０ＧのＮＷ側通信カード２１Ｂの最大格納個数を示す。尚、今回は、例えば「５」である。「Ｌｉｍｉｔ＿１＿２．５Ｇ＿ＣＬ＿ＩＦＣ」は、１０Ｇ以外（今回は１．２５Ｇ及び２．５Ｇ）のＣＬ側通信カード２２ＡのＩＦＣ６Ｂに格納できる１０Ｇ以外（今回は１Ｇ及び２．５Ｇ）のＣＬ側通信カード２１Ｂの最大格納個数を示す。尚、今回は、例えば「４０」である。「Ｌｉｍｉｔ＿１０Ｇ＿ＣＬ＿ＩＦＣ」は、１０ＧのＣＬ側通信カード２２ＢのＩＦＣ６Ｃに格納できる１０ＧのＮＷ側通信カード２１Ｂの最大格納個数を示す。尚、今回は、例えば「１０」である。

「ｔｒａｎｓｆｅｒＢＷ（ｈ１，ｈ２）」は、光パスｈ１及び光パスｈ２の相互間で乗換が発生するＤｅｍａｎｄ容量を示す。「ＣｏｎｎｅｃｔＢＷＬｉｍｉｔ（ｓ１，ｓ２）」は、シェルフｓ１及びシェルフｓ２の相互間で確保される通信容量限界値を示す。「ＮＲＣｏｎｔａｉｎＳｐａｎ（ｓｓ１，ｓｓ２，ｓ１，ｓ２）」は、シェルフｓ１からシェルフｓ２に北回りでＤｅｍａｎｄを伝送する際にシェルフｓｓ１とシェルフｓｓ２との間を通過するかの識別子である。「ＳＲＣｏｎｔａｉｎＳｐａｎ（ｓｓ１，ｓｓ２，ｓ１，ｓ２）」は、シェルフｓ１からシェルフｓ２に南回りでＤｅｍａｎｄを伝送する際にシェルフｓｓ１とシェルフｓｓ２との間を通過するかの識別子である。

整数計画モデルの目的関数は、シェルフ台数の削減に直結するパラメータとなす「使用ＩＦＣのスロット数の合計」を最小とするように設定する。目的関数は、（数１）の通り、表現できる。

また、整数計画モデルの第１の変数は、光パス３をシェルフ５内で使用するか否かを示す識別子である。第１の変数は、「ＯＰ（ｈ，ｓ）」で表現する。また、第２の変数は、各シェルフ５内で使用できる各種類のＩＦＣ６の個数（自然数）を示す。第２の変数は、例えば、「ＮＷ＿１０Ｇ＿ＩＦＣ（ｓ）」、「ＣＬ＿１０Ｇ＿ＩＦＣ（ｓ）」や「ＣＬ＿１＿２．５Ｇ＿ＩＦＣ（ｓ）」で表現する。尚、１００ＧのＮＷ側通信カード２１Ａは、今回想定の装置では直接シェルフ５に収容されることで、そのスロット数は「Ｓｌｏｔ＿１００Ｇ＿ＮＷ＿ＩＦＣ」で、その個数は「ＯＰ（ｈ，ｓ）」で規定する。

第３の変数は、光パス３の組み合わせがシェルフ５で分かれて収容されているか否かを示すブール型の識別子である。第３の変数は、例えば、「ｔｒａｎｓｆｅｒＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」で表現する。第４の変数は、シェルフ５相互間の接続形態が「リング接続」の場合に南回りの接続又は北回りの接続を示すブール型の識別子である。第４の変数は、例えば、「ＮｏｒｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」や「ＳｏｕｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」で表現する。尚、第４の変数は、シェルフ５相互間の接続形態が「リング接続」を対象とするが、「直列接続」の場合、経路が一つしか存在しない。従って、例えば、「ＮｏｒｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」を常に「１」とし、「ＳｏｕｔｈＲｏｕｎｄＦｌａｇ（ｓ１，ｓ２，ｈ１，ｈ２）」を実質使用しないものとする。

また、整数計画モデルの第１の制約条件は、各光パス３に対応するＮＷ側通信カード２１が必ずどれか１台のシェルフ５に収容する制約条件である。従って、第１の制約条件は、（数２）の通り、表現できる。

また、整数計画モデルの第２の制約条件は、各シェルフ５内に収容するＩＦＣ６の使用スロット数の合計がシェルフ５内で収容できる最大スロット数を超えないように制約する条件である。シェルフ５全体の最大スロット数からシェルフ相互間通信用のＩＦＣ６Ａの使用スロット数を差し引いたスロット数内で収容するＩＦＣ６を設定する。１台のシェルフ５当りで使用できるスロット数は、「ＳｈｅｌｆＳｌｏｔＣａｐ（今回は２４）−ＲｓｖｄＳｌｏｔＦｏｒＩＣ（ｓ）」で表現できる。従って、第２の制約条件は、（数３）の通り、表現できる。

また、整数計画モデルの第３の制約条件は、各種ＩＦＣ６内の通信カードの最大格納個数を示す制約条件である。例えば、１０ＧのＮＷ側通信カード２１ＢをＩＦＣ６Ｄに格納する制約条件は、（数４）の通り、表現できる。

また、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２ＡをＩＦＣ６Ｂに格納する制約条件は、（数５）の通り、表現できる。

また、１０ＧのＣＬ側通信カード２２ＢをＩＦＣ６Ｃに格納する制約条件は、（数６）の通り、表現できる。

また、整数計画モデルの第４の制約条件は、各種シェルフ５相互間の最大通信容量を示す制約条件である。第４の制約条件として、例えば、ＮＷ内の各シェルフ相互間の乗換容量（通信容量）が準備した容量を超えない条件である。この制約条件は、（数７）の通り、表現できる。

また、第４の制約条件として、例えば、乗換が生じる２本の光パス３に対応するＮＷ側通信カード２１が、夫々どのシェルフ５に搭載されるかを管理するための制約条件である。尚、２本の光パス３に対応するＮＷ側通信カード２１が別のシェルフ５に格納されている場合に、この状態が変数に適切に反映されるように設定する。この制約条件は、（数８）及び（数９）の通り、表現できる。

また、第４の制約条件として、例えば、「リング接続」の場合にシェルフ５相互間の通信が北回り又は南回りを確認する制約条件がある。この制約条件は、（数１０）の通り、表現できる。

次に、マルチシェルフ収容設計に関わる収容設計装置１の動作について説明する。先ず、収容設計装置１内のＣＰＵ１６は、光ネットワーク２内の設計対象となるノード４の設計前提情報をデータベース１７から収集する。設計前提情報は、設計対象のノード４内でＡｄｄ／ＤｒｏｐされるＤｅｍａｎｄ対応のＣＬ側通信カード２２の情報と、設計対象のノード４から光ネットワーク２で送出される光信号を取り扱うＮＷ側通信カード２１の情報とを有する。更に、設計前提情報は、各ＤｅｍａｎｄをＣＬ側通信カード２２からＮＷ側通信カード２１に伝送する経路情報と、光パス３間で乗り換えるＤｅｍａｎｄの情報とを有する。

ＣＰＵ１６は、設計前提情報内のＣＬ側通信カード２２の情報、ＮＷ側通信カード２１の情報及び経路情報に基づき、光パス３に対応したＤｅｍａｎｄ本数の第１のテーブル３０を生成し、第１のテーブル３０をデータベース１７に格納する。図９は、第１のテーブル３０の一例を示す説明図である。第１のテーブル３０は、光パス番号３１と、信号帯域３２と、ＣＬ側通信カード２２の種別３３と、Ｉｎｔｅｒ光パス３４とを対応付ける。光パス番号３１は、光パス３を識別する番号である。信号帯域３２は、光パス３で使用する信号帯域である。尚、収容設計装置１は、設計対象のノード４において、光パス番号３１が、図９に示すように、例えば、１〜１５であり、１５本の光パス３を使用する。しかも、収容設計装置１は、１５個のＮＷ側通信カード２１を認識する。更に、収容設計装置１は、信号帯域３１が１０Ｇ及び１００Ｇであり、１０Ｇの光パス３を８本及び１００Ｇの光パス３を７本と認識する。

ＣＬ側通信カード２２の種別３３は、１．２５Ｇ、２．５Ｇ及び１０Ｇの３種類のＣＬ側通信カード２２毎に光パス３でＡｄｄ／ＤｒｏｐされるＤｅｍａｎｄの本数を示す。収容設計装置１は、光パス番号３１が“１”の場合、１．２５ＧのＤｅｍａｎｄが１本、２．５ＧのＤｅｍａｎｄが１本、１０ＧのＤｅｍａｎｄが０本と認識する。

Ｉｎｔｅｒ光パス３４は、現在の光パス３から他の光パス３に乗り換えるＤｅｍａｎｄの本数を示す。尚、光パス３の乗換は、信号の帯域のみが重要であるため、帯域は１．２５Ｇの本数で換算した値となる。

収容設計装置１は、設計前提情報に基づき、光パス３に対応した乗換Ｄｅｍａｎｄ本数（通信容量）の第２のテーブル４０を生成する。図１０は、第２のテーブル４０の一例を示す説明図である。図１０に示す第２のテーブル４０は、光パス番号のマトリクスで示し、乗換が生じる箇所に数値が記載されている。尚、数値は、１．２５Ｇの本数で換算したＤｅｍａｎｄの本数である。例えば、光パス番号「１」は、光パス番号「４」に数値「２」が記載されているが、光パス番号「１」の光パス３から光パス番号「４」の光パス３へ１．２５Ｇ換算で２本のＤｅｍａｎｄの乗換が生じたことを示す。また、例えば、光パス番号「２」は、光パス番号「５」に「−」が記載されているが、光パス番号「２」の光パス３から光パス番号「５」の光パス３へ乗換のＤｅｍａｎｄがないことを示す。

そして、収容設計装置１のＣＰＵ１６は、第１のテーブル３０及び第２のテーブル４０を参照し、初期シェルフ数を「２」に設定する。そして、ＣＰＵ１６は、シェルフ５相互間の接続形態を「直列接続」と仮定して整数計画モデルを生成する。

ＣＰＵ１６は、生成された整数計画モデルを実行する。図１１Ａは、比較例（貪欲法）の設計結果の一例を示す説明図、図１１Ｂは、比較例（貪欲法）の設計結果に基づくラック搭載の一例を示す説明図である。

例えば、設計対象のＣＬ側通信カード２１は、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを１４７個、１０ＧのＣＬ側通信カード２２Ｂを１８個とする。設計対象のＮＷ側通信カード２１は、１００ＧのＮＷ側通信カード２１Ａを７個、１０ＧのＮＷ側通信カード２１Ｂを８個とする。更に、シェルフ５の最大スロット数は、２４スロットとする。

設計対象に対して貪欲法を使用した場合、シェルフ５が３台必要な設計結果を得た。尚、「４０ＰｏｒｔＭＲＭＳ」は、例えば、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａが格納されるＩＦＣ６Ｂである。「１０ＧＵ１０Ｇ」は、例えば、１０ＧのＣＬ側通信カード２２Ｂが格納されるＩＦＣ６Ｃ、１０ＧのＮＷ側通信カード２１Ｂが格納されるＩＦＣ６Ｄやシェルフ相互間通信用のＩＦＣ６Ａである。「１００ＧＮＢＯ」は、１００ＧのＮＷ側通信カード２１Ａが格納されるＩＦＣ６Ｅである。

第１のシェルフ５Ａは、２個の４０ＰｏｒｔＭＲＭＳと、４個の１０ＧＵ１０Ｇと、３個の１００ＧＮＢＯとを収容する。各４０ＰｏｒｔＭＲＭＳの使用スロット数は２スロット、各１０ＧＵ１０Ｇの使用スロット数は２スロット、各１００ＧＮＢＯの使用スロット数は４スロットである。

２個の４０ＰｏｒｔＭＲＭＳは、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを６５個格納し、２個の１０ＧＵ１０Ｇは、１０ＧのＣＬ側通信カード２２Ｂを１１個格納する。また、１個の１０ＧＵ１０Ｇは、第２のシェルフ５Ｂとのシェルフ相互間通信に使用し、通信容量１００Ｇ分の内、１．２５Ｇ＊５４＝６７．５Ｇ分をシェルフ相互間通信に使用する。更に、３個の１００ＧＮＢＯは、３個（例えば、光パス「３」、「６」及び「８」）の１００ＧのＮＷ側通信カード２１Ａを格納する。１個の１０ＧＵ１０Ｇは、５個（例えば、光パス「１」、「２」、「４」、「５」及び「７」）の１０ＧのＮＷ側通信カード２１Ｂを格納する。第１のシェルフ５Ａは、合計２４スロットを割当てる。

更に、第２のシェルフ５Ｂは、１個の４０ＰｏｒｔＭＲＭＳと、３個の１０ＧＵ１０Ｇと、３個の１００ＧＮＢＯとを有する。１個の４０ＰｏｒｔＭＲＭＳは、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを３８個格納し、１個の１０ＧＵ１０Ｇは１０ＧのＣＬ側通信カード２２Ｂを４個格納する。１個の１０ＧＵ１０Ｇは、第１のシェルフ５Ａとのシェルフ相互間通信に使用する。更に、１個の１０ＧＵ１０Ｇは、第３のシェルフ５Ｃとのシェルフ相互間通信に使用し、通信容量１００Ｇ分の内、１．２５Ｇ＊２９＝３６．２５Ｇ分をシェルフ相互間通信に使用する。更に、３個の１００ＧＮＢＯは、３個（例えば、光パス「１１」、「１２」及び「１３」）の１００ＧのＮＷ側通信カード２１Ａを格納する。第２のシェルフ５Ｂは、合計２０スロットを割当てる。

更に、第３のシェルフ５Ｃは、２個の４０ＰｏｒｔＭＲＭＳと、３個の１０ＧＵ１０Ｇと、１個の１００ＧＮＢＯとを有する。２個の４０ＰｏｒｔＭＲＭＳは、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを４４個格納し、１個の１０ＧＵ１０Ｇは、１０ＧのＣＬ側通信カード２２Ｂを３個格納する。１個の１０ＧＵ１０Ｇは、第２のシェルフ５Ｂとのシェルフ相互間通信に使用する。更に、１個の１００ＧＮＢＯは、１個（例えば、光パス１５）の１００ＧのＮＷ側通信カード２１Ａを格納する。更に、１個の１０ＧＵ１０Ｇは、３個（例えば、光パス「９」、「１０」及び「１４」）の１０ＧのＮＷ側通信カード２１Ｂを格納する。第３のシェルフ５Ｃは、合計１４スロットを割当てる。

従って、貪欲法を採用した場合、シェルフ５が３台必要なため、２シェルフ搭載用のラックで２台必要となる。その結果、２台分のラック床占有面積のスペースを確保する必要がある。

尚、貪欲法では、ＩＦＣ６の使用スロット数等の制約条件を考慮できるものの、シェルフ台数を最小にできる保証はない。従って、実際の設計では、従来の貪欲法等では実現不可能な「制約条件を満たした設計」と「よりコストを抑えた設計」の両立を求められる。

そこで、本実施例の収容設計装置１を使用した場合には、下記の通り、マルチシェルフ収容設計の設計結果が得られた。図１２Ａは、本実施例の設計結果の一例を示す説明図、図１２Ｂは、本実施例の設計結果に基づくラック搭載の一例を示す説明図である。尚、設計対象は、図１１Ａと同一である。その結果、設計対象をシェルフ５の２台で収容できる。

第１のシェルフ５Ａは、３個の４０ＰｏｒｔＭＲＭＳと、３個の１０ＧＵ１０Ｇと、３個の１００ＧＮＢＯとを収容する。３個の４０ＰｏｒｔＭＲＭＳは、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを１０７個格納し、１個の１０ＧＵ１０Ｇは、１０ＧＣＬ側通信カード２２Ｂを９個格納する。１個の１０ＧＵ１０Ｇは、第２のシェルフ５Ｂとのシェルフ相互間通信に使用し、通信容量１００Ｇ分の内、１．２５Ｇ＊７８＝９７．５Ｇ分をシェルフ相互間通信に使用する。更に、３個の１００ＧＮＢＯは、３個（例えば、光パス「１５」、「８」及び「６」）の１００ＧのＮＷ側通信カード２１Ａを格納する。１個の１０ＧＵ１０Ｇは、５個（例えば、光パス「２」、「９」、「１４」、「５」及び「４」）の１０ＧのＮＷ側通信カード２１Ｂを格納する。第１のシェルフ５Ａは、合計２４スロットを割当てる。

更に、第２のシェルフ５Ｂは、１個の４０ＰｏｒｔＭＲＭＳと、３個の１０ＧＵ１０Ｇと、４個の１００ＧＮＢＯとを有する。１個の４０ＰｏｒｔＭＲＭＳは、１．２５Ｇ／２．５ＧのＣＬ側通信カード２２Ａを４０個格納し、１個の１０ＧＵ１０Ｇは、１０ＧのＣＬ側通信カード２２Ｂを９個格納する。１個の１０ＧＵ１０Ｇは、第１のシェルフ５Ａとのシェルフ相互間通信に使用する。更に、４個の１００ＧＮＢＯは、４個（例えば、光パス「１２」、「１１」、「３」及び「１３」）の１００ＧのＮＷ側通信カード２１Ａを格納する。１個の１０ＧＵ１０Ｇは、３個（例えば、光パス「７」、「１０」及び「１」）の１０ＧのＮＷ側通信カード２１Ｂを格納する。第２のシェルフ５Ｂは、合計２４スロットを割当てる。

尚、この設計では、第１のシェルフ５Ａと第２のシェルフ５Ｂとの間の接続形態は、「直列接続」の状態で、制約条件を全て満たした収容設計が実現されていることを示している。そして、この設計では、１００Ｇ分用意されたシェルフ相互間の通信容量の内、９７．５Ｇを使用することで、２シェルフ設計が実現されていることを示している。

従って、本実施例を採用した場合、２台のシェルフ５内に設計対象のＣＬ側通信カード２２及びＮＷ側通信カード２１を収容できるため、２シェルフ搭載用のラックが１台で済む。その結果、シェルフ数は、貪欲法に比較して３３％削減し、ラック数は、貪欲法に比較して５０％削減できる。その結果、ラックを占有する床面積を貪欲法に比較して５０％削減することで設備コストを大幅に軽減できる。

実施例のＣＰＵ１６は、設計対象のＮＷ側通信カード２１及びＣＬ側通信カード２２が格納された複数種のＩＦＣ６を２以上のシェルフ５内に収容する際に、設計対象のＮＷ側通信カード２１及びＣＬ側通信カード２２の個数を示す個数情報を収集する。更に、ＣＰＵ１６は、各ＩＦＣ６の使用スロット数を示すカード情報を収集する。更に、ＣＰＵ１６は、シェルフ５内でＩＦＣ６が収容可能な最大スロット数を示すシェルフ情報と、異なるＮＷ側通信カード２１相互間のシェルフ５相互間で通信する際の対応関係を示す第１の対応情報とを収集する。更に、ＣＰＵ１６は、シェルフ５相互間の通信に使用できる通信制限容量を収集する。ＣＰＵ１６は、カード情報、個数情報、シェルフ情報、第１の対応情報及び通信制限容量に基づき、設計対象のＮＷ側通信カード２１及びＣＬ側通信カード２２が格納されたＩＦＣ６を最小限のシェルフ５内に割当てる整数計画モデルを生成する。ＣＰＵ１６は、整数計画モデルを実行することで、ＩＦＣ６を最小限のシェルフ５内に割当てる収容設計の設計解がある場合に、当該設計解を出力装置１２に出力する。その結果、収容設計装置１は、シェルフ５の台数を２台以上の最小限に抑えたマルチシェルフ収容設計を提供できる。

実施例のＣＰＵ１６は、整数計画モデルを生成する前に使用可能なシェルフ数を設定し、整数計画モデルの実行による設計解がない場合に、シェルフ相互間の接続形態を変更する。更に、ＣＰＵ１６は、変更されたシェルフ相互間の接続形態に応じて、カード情報、個数情報、シェルフ情報、対応情報及び通信制限容量を収集する。更に、ＣＰＵ１６は、カード情報、個数情報、シェルフ情報、対応情報及び通信制限容量に基づき、整数計画モデルを再び生成する。その結果、シェルフ相互間の接続形態の変更を反映した新たな整数計画モデルを再び生成できる。

実施例のＣＰＵ１６は、整数計画モデルの実行による設計解がなく、変更できるシェルフ相互間の接続形態がない場合に、シェルフ数を増加して設定する。ＣＰＵ１６は、シェルフ数を増加して設定した後、カード情報、個数情報、シェルフ情報、対応情報及び通信制限容量を収集する。更に、ＣＰＵ１６は、カード情報、個数情報、シェルフ情報、対応情報及び通信制限容量に基づき、整数計画モデルを再び生成する。その結果、シェルフ数変更を反映した新たな整数計画モデルを再び生成できる。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。

以上、本実施例を含む実施の形態に関し、更に以下の付記を開示する。

（付記１）コンピュータに、
第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
各処理を実行させることを特徴とする収容設計プログラム。

（付記２）前記整数計画モデルを生成する前に使用可能なシェルフ数を設定し、前記整数計画モデルの実行による設計解がない場合に、前記シェルフ相互間の接続形態を変更し、
変更された前記シェルフ相互間の接続形態に応じて、前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量を収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記整数計画モデルを再び生成する
各処理を前記コンピュータに実行させることを特徴とする付記１に記載の収容設計プログラム。

（付記３）前記整数計画モデルの実行による設計解がなく、変更できる前記シェルフ相互間の接続形態がない場合に、前記シェルフ数を増加して設定し、
前記シェルフ数を増加して設定した後、前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量を収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記整数計画モデルを再び生成する
各処理を前記コンピュータに実行させることを特徴とする付記２に記載の収容設計プログラム。

（付記４）前記シェルフ相互間の接続形態は、
前記シェルフ相互間を直列接続又はリング接続したことを特徴とする付記２又は３に記載の収容設計プログラム。

（付記５）前記シェルフ相互間の接続形態は、
前記シェルフ相互間を直列接続したことを特徴とする付記２又は３に記載の収容設計プログラム。

（付記６）前記シェルフ相互間の接続形態は、
前記シェルフ相互間をリング接続したことを特徴とする付記２又は３に記載の収容設計プログラム。

（付記７）ＣＰＵを備えた収容設計装置であって、
前記ＣＰＵは、
第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
各処理を実行することを特徴とする収容設計装置。

（付記８）収容設計装置の収容設計方法であって、
前記収容設計装置は、
第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
各処理を実行することを特徴とする収容設計方法。

（付記９）プロセッサとメモリとを備えた情報処理装置であって、
前記プロセッサは、
第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
各処理を実行することを特徴とする情報処理装置。

１ 収容設計装置
５ シェルフ
６ ＩＦＣ
１１ 入力装置
１２ 出力装置
１６ ＣＰＵ
１７ データベース
２１ ＮＷ側通信カード
２２ ＣＬ側通信カード

Claims (6)

1. コンピュータに、
   第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
   前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
   前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
   各処理を実行させることを特徴とする収容設計プログラム。
2. 前記整数計画モデルを生成する前に使用可能なシェルフ数を設定し、前記整数計画モデルの実行による設計解がない場合に、前記シェルフ相互間の接続形態を変更し、
   変更された前記シェルフ相互間の接続形態に応じて、前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量を収集し、
   前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記整数計画モデルを再び生成する
   各処理を前記コンピュータに実行させることを特徴とする請求項１に記載の収容設計プログラム。
3. 前記整数計画モデルの実行による設計解がなく、変更できる前記シェルフ相互間の接続形態がない場合に、前記シェルフ数を増加して設定し、
   前記シェルフ数を増加して設定した後、前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量を収集し、
   前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記整数計画モデルを再び生成する
   各処理を前記コンピュータに実行させることを特徴とする請求項２に記載の収容設計プログラム。
4. 前記シェルフ相互間の接続形態は、
   前記シェルフ相互間を直列接続又はリング接続したことを特徴とする請求項２又は３に記載の収容設計プログラム。
5. ＣＰＵを備えた収容設計装置であって、
   前記ＣＰＵは、
   第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
   前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
   前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
   各処理を実行することを特徴とする収容設計装置。
6. 収容設計装置の収容設計方法であって、
   前記収容設計装置は、
   第１の通信カード及び第２の通信カードが格納された複数種の格納カードを２以上のシェルフ内に収容する際に、前記第１の通信カード及び前記第２の通信カードの個数を示す個数情報と、前記格納カードの使用スロット数を示すカード情報と、前記シェルフ内で前記格納カードが収容可能な最大スロット数を示すシェルフ情報と、異なる第１の通信カード相互間のシェルフ相互間で通信する際の対応関係を示す対応情報と、前記シェルフ相互間の通信に使用できる通信制限容量とを収集し、
   前記カード情報、前記個数情報、前記シェルフ情報、前記対応情報及び前記通信制限容量に基づき、前記設計対象の前記第１の通信カード及び前記第２の通信カードが格納された前記格納カードを２以上の最小限のシェルフ内に割当てる整数計画モデルを生成し、
   前記整数計画モデルを実行し、前記格納カードを最小限のシェルフ内に割当てる収容設計の設計解がある場合に、当該設計解を出力する
   各処理を実行することを特徴とする収容設計方法。

Images