(57)【要約】【課題】装置ごとに固有の設定が必要であっても保守や運用を容易にすること。【解決手段】加入者線端局装置は、管理システムと接続され、ソフトウェアによって実装された機能部により動作する加入者線端局装置は、前記機能部の設定についての前記管理システムからの設定要求に基づき、当該設定要求を前記機能部の設定に反映させる共通基盤部を有する。【選択図】図４
2019004295.tif 000002
【特許請求の範囲】
【請求項１】
管理システムと接続され、ソフトウェアによって実装された機能部により動作する加入者線端局装置であって、
前記機能部の設定についての前記管理システムからの設定要求に基づき、当該設定要求を前記機能部の設定に反映させる共通基盤部
を有する加入者線端局装置。
【請求項２】
前記共通基盤部は、機能部が追加された場合、当該追加された機能部の設定についての前記管理システムからの設定要求に基づき、当該設定要求を当該追加された機能部の設定に反映させる
請求項１に記載の加入者線端局装置。
【請求項３】
前記機能部の設定に使用される命令セット群と前記機能部とが対応付けられた設定情報テーブルを記憶する記憶部と、
前記設定情報テーブルに基づいて、前記管理システムからの命令を、当該命令のあて先である機能部に該当する形式の命令に変換したうえで、当該命令のあて先の機能部へ転送する機能設定部と、
を有する請求項１または請求項２に記載の加入者線端局装置。
【請求項４】
前記設定情報テーブルは、それぞれの前記機能部で動作する仮想マシンのバージョンを示す情報、それぞれの前記機能部で動作する通信プロトコルのバージョンを示す情報、およびそれぞれの前記機能部に対応する管理システムのバージョンを示す情報のうち少なくとも１つを含む
請求項３に記載の加入者線端局装置。
【請求項５】
ソフトウェアによって実装された機能部の設定についての管理システムからの設定要求に基づき、当該設定要求を前記機能部の設定に反映させる設定反映ステップ
を有する設定反映方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、加入者線端局装置、および設定反映方法に関する。
【背景技術】
【０００２】
ネットワークの分野おいて、ＳＤＮ（Software Defined Network）やＮＦＶ（Network Function Virtualization）といった仮想化技術の導入が進められている。
ＳＤＮは、ネットワークにおける転送機能と制御機能とを、それぞれデータプレーンとコントロールプレーンとに分離する。そして、ＳＤＮは、制御機能をソフトウェア化したうえでコントロールプレーン上のクラウドなどに配置し、データプレーン上の通信機器を制御する。これにより、ＳＤＮによれば、柔軟な構成変更が可能になるため、ネットワーク運用の効率化が期待される。
また、ＮＦＶは、通信装置内の主信号処理を含むネットワーク機能をソフトウェア化して、当該ネットワーク機能を、汎用装置上（例えば、ＰＣ（Personal Computer）サーバ上、ホワイトボックススイッチ上など）、または、クラウド上で動作させる技術である。これにより、ＮＦＶによれば、ネットワーク機能の追加、削除、および更改の自由度が向上するとともに、汎用装置やクラウドを用いることによって、ＣＡＰＥＸ（Capital Expenditure；資本的支出）の削減も期待される。
そして、上記のＳＤＮやＮＦＶのコンセプトを踏まえて、アクセス装置における仮想化技術の適用についての検討がなされている（例えば、非特許文献１、および非特許文献２）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】”アクセスシステムへの仮想化技術の適用”，ビジネスコミュニケーション，Ｖｏｌ．５２，Ｎｏ．９，ｐｐ２−５，２０１５年
【非特許文献２】”ＮＴＴが描くアクセス網の将来像”，テレコミュニケーション，Ｎｏ．３８１，ｐｐ５６−５７，２０１６年４月
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一般的に、現状のアクセス装置は、システムやベンダごとの専用装置であるため、アクセス装置ごとに固有の設定が必要になる。また、通信キャリアは、サービスの持続性や安定性を踏まえ、複数ベンダのアクセス装置を設置する場合があるが、当該複数ベンダのアクセス装置を用いてサービスを提供する場合、アクセス装置ごとに保守や運用の方法が異なり作業が煩雑になるという課題がある。
【０００５】
本発明は、上記事情に鑑み、装置ごとに固有の設定が必要であっても保守や運用を容易にすることができる加入者線端局装置、および設定反映方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一態様は、管理システムと接続され、ソフトウェアによって実装された機能部により動作する加入者線端局装置であって、前記機能部の設定についての前記管理システムからの設定要求に基づき、当該設定要求を前記機能部の設定に反映させる共通基盤部を有する加入者線端局装置である。
【０００７】
本発明の一態様は、上記の加入者線端局装置であって、前記共通基盤部は、機能部が追加された場合、当該追加された機能部の設定についての前記管理システムからの設定要求に基づき、当該設定要求を当該追加された機能部の設定に反映させる。
【０００８】
本発明の一態様は、上記の加入者線端局装置であって、前記機能部の設定に使用される命令セット群と前記機能部とが対応付けられた設定情報テーブルを記憶する記憶部と、前記設定情報テーブルに基づいて、前記管理システムからの命令を、当該命令のあて先である機能部に該当する形式の命令に変換したうえで、当該命令のあて先の機能部へ転送する機能設定部と、を有する。
【０００９】
本発明の一態様は、上記の加入者線端局装置であって、前記設定情報テーブルは、それぞれの前記機能部で動作する仮想マシンのバージョンを示す情報、それぞれの前記機能部で動作する通信プロトコルのバージョンを示す情報、およびそれぞれの前記機能部に対応する管理システムのバージョンを示す情報のうち少なくとも１つを含む。
【００１０】
本発明の一態様は、ソフトウェアによって実装された機能部の設定についての管理システムからの設定要求に基づき、当該設定要求を前記機能部の設定に反映させる設定反映ステップを有する設定反映方法である。
【発明の効果】
【００１１】
本発明によれば、装置ごとに固有の設定が必要であっても保守や運用を容易にすることができる。
【図面の簡単な説明】
【００１２】
【図１】従来のアクセス装置および管理システムの構成を示す概略図である。
【図２】従来のモデル化したデータで処理を行うアクセス装置および管理システムの構成を示す概略図である。
【図３】本発明の第１の実施形態に係る汎用装置および管理システムの構成を示す概略図である。
【図４】本発明の第１の実施形態に係る汎用装置および管理システムの機能構成を示す図である。
【図５】本発明の第１の実施形態に係る汎用装置の動作を示すフローチャートである。
【図６】本発明の第１の実施形態に係る汎用装置に機能部を追加する場合について説明するための図である。
【図７】本発明の第２の実施形態に係る汎用装置および管理システムの機能構成を示す図である。
【発明を実施するための形態】
【００１３】
まず、従来のアクセス装置について説明する。
一般的に、従来のアクセス装置は、専用ハードウェア（例えば、専用チップ）による、システムやベンダごとの専用装置であるため、当該アクセス装置の設定における入力コマンド（例えば、Ｃｏｎｆｉｇコマンド）の体系などが、システムやベンダによってそれぞれ異なる。具体的には、アクセス装置が専用装置であることにより、ＣＬＩ（Command Line Interface）やＳＮＭＰ（Simple Network Manager Protocol）のＭＩＢ（Management Information Base；管理情報ベース）が異なる。そのため、システムやベンダの異なるアクセス装置ごとに、当該アクセス装置の設定、監視、および制御などを行うための管理システム（例えば、ＥＭＳ（Element Management System；エレメント管理システム））をそれぞれ用意する必要がある。
【００１４】
図１は、従来のアクセス装置および管理システムの構成の一例を示す概略図である。図示するように、ベンダＡ社のアクセス装置５０ａ−１、ベンダＢ社のアクセス装置５０ａ−２、およびベンダＣ社のアクセス装置５０ａ−３があり、この３つのアクセス装置はベンダごとの専用装置である。そのため、アクセス装置５０ａ−１、アクセス装置５０ａ−２、およびアクセス装置５０ａ−３は、それぞれ異なるＭＩＢ（ＭＩＢ（Ａ社）、ＭＩＢ（Ｂ社）、およびＭＩＢ（Ｃ社））を記憶している。そのため、アクセス装置５０ａ−１、アクセス装置５０ａ−２、およびアクセス装置５０ａ−３は、それぞれ異なる管理システム（管理システム６０ａ−１、管理システム６０ａ−２、および管理システム６０ａ−３）によって管理される。
【００１５】
通信キャリアは、同一システム（例えば、ＧＥ−ＰＯＮ（Gigabit Ethernet-Passive Optical Network））であっても、サービスの持続性や安定性を踏まえ、アクセス装置のＥｏＳ（End of Sales）、ＥｏＬ（End of Life）、および不具合などのリスクに備えて、複数ベンダのアクセス装置を設置する場合がある。このように、通信キャリアが、当該複数ベンダのアクセス装置を用いてサービスを提供する場合には、アクセス装置ごとに保守や運用の方法が異なり作業が煩雑になる。
【００１６】
上記の従来技術に対し、ＸＭＬ（Extensible Markup Language）を用いる管理システムがある。ＸＭＬは、手順および処理対象をモデル化したデータである。
【００１７】
図２は、従来のモデル化したデータで処理を行うアクセス装置および管理システムの構成を示す概略図である。図示するように、ベンダＡ社のアクセス装置５０ｂ−１、ベンダＢ社のアクセス装置５０ｂ−２、およびベンダＣ社のアクセス装置５０ｂ−３があり、この３つのアクセス装置はベンダごとの専用装置である。そして、アクセス装置５０ｂ−１、アクセス装置５０ｂ−２、およびアクセス装置５０ｂ−３は、いずれも、モデル化したデータであるＸＭＬを用いて処理を行う。
【００１８】
しかしながら、アクセス装置に搭載されるＯＳ（Operating System；基本ソフト）によってＸＭＬ構造に違いがあるため、上述した従来技術と同様に、システムやベンダが異なるアクセス装置ごとに管理システム側が対応する必要がある。そのため、図２に図示するように、アクセス装置５０ｂ−１、アクセス装置５０ｂ−２、およびアクセス装置５０ｂ−３は、それぞれ異なる管理システム（管理システム６０ｂ−１、管理システム６０ｂ−２、および管理システム６０ｂ−３）によって管理される。
【００１９】
＜第１の実施形態＞
以下、本発明の第１の実施形態について説明する。
［汎用装置および管理システムの全体構成］
以下、汎用装置および管理システムの全体構成について、図面を参照しながら説明する。
【００２０】
図３は、本発明の第１の実施形態に係る汎用装置１０ａおよび管理システム２０ａの全体構成の一例を示す概略図である。図示するように、２台の汎用装置（汎用装置１０ａ−１および汎用装置１０ａ−２）と管理システム２０ａとが接続される。なお、以下、汎用装置１０ａ−１と汎用装置１０ａ−２とを特に区別して説明する必要がない場合には、単に汎用装置１０ａという。なお、図３においては、汎用装置１０ａは２台であるものとしたが、これに限定されるものではなく、汎用装置１０ａの台数は任意の台数である。
【００２１】
汎用装置１０ａは、例えば、ＰＣサーバを含んで構成される。汎用装置１０ａは、例えば、Ｌｉｎｕｘ（登録商標）などのＯＳ上で、アクセス装置の機能をソフトウェア化して実装した仮想的なＯＬＴ（Optical Line Terminal;加入者線端局装置）を構成する。
【００２２】
なお、ＯＬＴは、光通信網を経由する光信号によって他の通信装置（例えば、ＯＮＵ（Optical Network Unit；加入者線終端装置））との通信を実現する装置である。ＯＬＴが接続される光通信網は、例えばＰＯＮ（Passive Optical Network）などの受動光通信網である。ＯＬＴは、例えば光通信網に接続された局舎に設置される。なお、ＯＮＵは、通信網を経由する光信号によって他の通信装置との通信を実現する装置である。ＯＮＵが接続される通信網は、例えばＰＯＮなどの光ファイバ網である。ＯＮＵは、例えば通信サービスの提供を受けるユーザの宅内に設置される。
【００２３】
図３に図示するように、汎用装置１０ａは、仮想マシンであるＸＸ−ＰＯＮと、同じく仮想マシンであるＹＹ−ＰＯＮと、を構成する。ここで、ＸＸやＹＹとは、ＰＯＮの種類（例えば、ＧＥ−ＰＯＮ、Ｇ−ＰＯＮなど）を表したものであり、ＸＸ−ＰＯＮとＹＹ−ＰＯＮは異なる種類のＰＯＮである。
【００２４】
管理システム２０ａは、ＯＳおよびミドルウェア上で、汎用装置１０ａを管理する管理アプリケーションを動作させる。管理システム２０ａの管理アプリケーションは、例えば、ＮＥＴＣＯＮＦなどの通信プロトコルによって汎用装置１０ａと通信接続し、汎用装置１０ａの仮想マシンの設定、制御、および監視などを行う。管理アプリケーションは、仮想マシンに対し、ＸＭＬなどのデータ形式で生成された指示データを送信することにより指示を行う。
【００２５】
汎用装置１０ａの各仮想マシンのＣｏｎｔ部（制御部）は、それぞれ上記の指示データを取得し、当該指示データに基づいて主信号処理部を動作させる。
【００２６】
図３に示すように、本実施形態では、アクセス装置の機能がソフトウェア部品化され、汎用装置１０ａ上で仮想マシンとして構成されるため、同一システム（例えば、ＸＸ−ＰＯＮ）であれば、同一機能のソフトウェア部品を複数用意する必要がない。例えば、汎用装置１０ａ−１のＸＸ−ＰＯＮと汎用装置１０ａ−２のＸＸ−ＰＯＮとは、同一の管理アプリケーションで管理可能である。新たに管理対象のシステム（例えば、ＹＹ−ＰＯＮ）が追加された場合には管理アプリケーションに機能追加をする必要はあるが、汎用装置１０ａ−１のＹＹ−ＰＯＮと汎用装置１０ａ−２のＹＹ−ＰＯＮとは同一の管理アプリケーションで管理可能であるため、汎用装置１０ａごとに管理アプリケーションに機能追加をする必要がない。
【００２７】
このように、本実施形態では、アクセス装置の機能がソフトウェア部品化され、汎用装置１０ａ上で仮想マシンとして構成されることにより、汎用装置１０ａ上に構成された仮想マシンに対するＣｏｎｆｉｇ設定などにおけるベンダごとの差異はなくなる。そのため、本実施形態では、汎用装置１０ａごとに管理システム２０ａを用意する必要がない。これにより、本実施形態によれば、１台の管理システム２０ａによって、複数台の汎用装置１０aを管理することができる。
【００２８】
［汎用装置および管理システムの機能構成］
以下、汎用装置１０ａおよび管理システム２０ａの機能構成について図面を参照しながら説明する。
図４は、本発明の第１の実施形態に係る汎用装置１０ａおよび管理システム２０ａの機能構成を示す図である。図示するように、汎用装置１０ａに対して管理システム２０ａが接続される。なお、説明を簡略化するため、汎用装置１０ａは１台であるものとしたが、例えば、図３に示したように、１台の管理システム２０ａに対して複数台の汎用装置１０ａが接続されていても構わない。
【００２９】
図示するように、汎用装置１０ａは、ＯＳ１００ａと、共通基盤部１０１ａと、２つの機能部（機能部Ａ１０２ａ−１、機能部Ｂ１０２ａ−２）とを含んで構成される。なお、以下、機能部Ａ１０２ａ−１と機能部Ｂ１０２ａ−２とを特に区別して説明する必要がない場合には、単に機能部１０２ａという。
【００３０】
汎用装置１０ａは、ＯＳ１００ａ上でソフトウェア化して実装された機能部１０２ａにより動作する仮想的なＯＬＴ（以下、「仮想化ＯＬＴ」と称する）を構成する装置である。
共通基盤部１０１ａは、機能部１０２ａの設定についての管理システム２０ａからの設定要求に基づき、当該設定要求を当該機能部１０２ａの設定に反映させる。また、共通基盤部１０１ａは、後述する設定情報テーブルを記憶する記憶部１０１１を備える。
【００３１】
管理システム２０ａから汎用装置１０ａへの指示は、汎用装置１０ａ内に共通基盤部１０１ａを設けて、指示のフォーマット（指示フォーマット）を共通化することで、異なる機能部（例えば、機能部Ａ１０２ａ−１と機能部Ｂ１０２ａ−２）に対しても、共通の指示フォーマットにより行うことができる。
【００３２】
例えば、指示フォーマットの一例としては、図４に図示する指示フォーマットｆ１のように、各機能部１０２ａに対して設定をしたいのか、各機能部１０２ａから情報を取得したいのか、などの指示の種類を示すコマンド分類と、各機能部１０２ａへのそれぞれのコマンド自体をまとめてカプセル化したコマンド（群）とが繋げられた指示フォーマットであるものとし、当該指示フォーマットに基づく指示データが、管理システム２０ａから共通基盤部１０１ａに対して送信される。そして、各機能部１０２ａに対するコマンドの体系（コマンドのサイズ、並び順など）をあらかじめ規定しておくことにより、各機能部１０２ａへのカプセル化されたコマンドを、共通基盤部１０１ａにおいて正しくデカプセル化できる。
【００３３】
さらに、汎用装置１０ａは、コマンド分類と、コマンドと、当該コマンドに該当する機能部１０２ａとが対応付けられ一覧化された情報（設定情報テーブル）を、共通基盤部１０１ａ内の記憶部１０１１にあらかじめ保持している。なお、設定情報テーブルは、共通基盤部１０１ａ外の記憶装置に記憶されている構成であってもよい。
これにより、デカプセル化されたコマンドがどの機能部１０２ａに該当するコマンドなのかを、共通基盤部１０１ａは、上記の設定情報テーブルを参照することによって特定することができる。そして、共通基盤部１０１ａは、デカプセル化された複数のコマンドが、どの機能部１０２ａに対するコマンドなのかをそれぞれ特定した後、特定した複数のコマンドを該当する機能部１０２ａにそれぞれ振り分けて通知することにより、それぞれの機能部１０２ａに対して設定を反映させる。
【００３４】
なお、汎用装置上にアクセス装置の機能をソフトウェア化して実装した仮想化ＯＬＴにおいて、従来技術では、当該機能の設定を管理システム側から設定する必要があった。例えば、汎用装置１０ａの機能部Ａはベンダである甲が作成し、機能部Ｂはベンダである乙が作成した場合、各々のベンダが自由に作成すると、当該機能に対して設定するためのＣｏｎｆｉｇコマンド（設定コマンド）の体系などが異なったものになる。そのため、設定の指示を行う管理システム側の仕様についても、機能部ごとに差異が生ずることになる。一方、本実施形態に係る汎用装置１０ａは、当該汎用装置１０ａの機能部品をベンダ依存とならないように共通化したことを特徴とする。
【００３５】
以上により、本実施形態によれば、複数の機能部１０２ａがそれぞれ異なるベンダによって作成されたとしても、管理システム２０ａから汎用装置１０ａへ送信される指示フォーマットを統一すること、および、コマンドと機能部１０２ａとが対応付けられた設定情報テーブルをあらかじめ汎用装置１０ａの共通基盤部１０１ａの記憶部１０１１が保持しておくことによって、ベンダの差異に起因する管理システム２０ａ側への影響、すなわち、管理システム２０ａに対する改造などが不要となる。
【００３６】
以下、さらに具体的に説明する。図４に図示するように、管理システム２０ａから共通基盤部１０１ａへ送信される指示の指示フォーマットｆ１は、先頭に、コマンド分類を示す情報が配置される。コマンド分類は、例えば、機能部１０２ａに対する「設定」の指示であれば「Ｓｅｔ」が、機能部１０２ａからの情報の「取得」の指示であれば「Ｇｅｔ」が配置される。そして、コマンド分類を示す情報の後には、複数のコマンドがカプセル化されたコマンド（群）が配置される。例えば、機能部Ａ１０２ａ−１に対するコマンド、機能部Ｂ１０２ａ−２に対するコマンド、などが順に並べて配置されたデータがカプセル化されたコマンド（群）が、コマンド分類を示す情報の後に配置される。
【００３７】
管理システム２０ａからの指示を受け取った共通基盤部１０１ａは、カプセル化されたコマンドをデカプセル化し、デカプセル化された後の各コマンドがどの機能部１０２ａに対するコマンドなのかをそれぞれ特定する。当該特定は、図４に図示する設定情報テーブルｔ１に基づいて行われる。図示するように、設定情報テーブルｔ１は、「コマンド分類」と、「コマンド」と、「該当機能部」と、の３つの項目の列からなる２次元の表形式のデータである。
【００３８】
例えば、管理システム２０ａからの指示を受け取った指示のコマンド分類が「Ｓｅｔ」であり、デカプセル化したコマンドの中の１つが「ＸＸＸ」であった場合には、共通基盤部１０１ａは設定情報テーブルｔ１を参照し、当該コマンド分類（「Ｓｅｔ」）および当該コマンド（「ＸＸＸ」）に対応する「該当機能部」の値（すなわち、「機能部Ａ」）を取得する。これにより、共通基盤部１０１ａは、当該コマンドが、機能部Ａ１０２ａ−１に対するコマンドであることを特定することができる。同様に、例えば、管理システム２０ａからの指示を受け取った指示のコマンド分類が「Ｓｅｔ」であり、デカプセル化したコマンドの１つが「ＹＹＹ」であった場合には、共通基盤部１０１ａは、当該コマンドが、機能部Ｂ１０２ａ−２に対するコマンドであることを特定することができる。
【００３９】
共通基盤部１０１ａは、上記において特定した機能部１０２ａに対して、コマンド分類およびコマンドをそれぞれ振り分けて出力する。この際、例えば、「Ｓｅｔ＿ＸＸＸ」のように、コマンド分類とコマンドとがアンダーバーによって結びつけられたデータとして、各機能部１０２ａへ出力される。
【００４０】
上述したように、本実施形態においては、管理システム２０ａから各機能部１０２ａに対して行われる指示は、共通基盤部１０１ａを介して行われる。そして、本実施形態においては、機能部１０２ａが追加されるたびに管理システム２０ａに対して改造が要求されることを防ぐため、各機能部１０２ａへのコマンドは隠蔽（カプセル化）された形で、管理システム２０ａから共通基盤部１０１ａへ送信される。
【００４１】
そして、共通基盤部１０１ａと管理システム２０ａとの間でルール（指示フォーマット）をあらかじめ規定しておくことにより、管理システム２０ａ側では、データ構造を解釈したり、コマンドを認識したりする必要がなく、機能部１０２ａを開発したベンダの差異による管理システム２０ａ側への影響がない。したがって、管理システム２０ａに対する改造などが不要となる。
【００４２】
［汎用装置の動作］
以下、汎用装置１０ａの動作について、図面を参照しながら説明する。
図５は、本発明の第１の実施形態に係る汎用装置１０ａの動作を示すフローチャートである。本フローチャートは、管理システム２０ａから汎用装置１０ａへ、あらかじめ規定された指示フォーマットに基づく指示データが送信された際に開始する。
【００４３】
（ステップＳ００１）汎用装置１０ａの共通基盤部１０１ａは、管理システム２０ａから送信された指示データを取得する。その後、ステップＳ００２へ進む。
（ステップＳ００２）汎用装置１０ａの共通基盤部１０１ａは、ステップＳ００１において取得した指示データに含まれるコマンド分類を認識する。その後、ステップＳ００３へ進む。
【００４４】
（ステップＳ００３）汎用装置１０ａの共通基盤部１０１ａがステップＳ００１において取得した指示データに含まれるコマンド（群）はカプセル化されている。共通基盤部１０１ａは、カプセル化されたコマンド（群）をデカプセル化する。そして、共通基盤部１０１ａは、デカプセル化された１または複数のコマンドを認識する。その後、ステップＳ００４へ進む。
（ステップＳ００４）汎用装置１０ａの共通基盤部１０１ａは、コマンド分類と、コマンドと、該当機能部と、が対応付けられた設定情報テーブルｔ１を参照し、ステップＳ００２において認識したコマンド分類と、ステップＳ００３において認識したそれぞれのコマンドと、に該当する機能部１０２ａをそれぞれ特定する。その後、ステップＳ００５へ進む。
【００４５】
（ステップＳ００５）汎用装置１０ａの共通基盤部１０１ａは、ステップＳ００２において認識したコマンド分類と、ステップＳ００３において認識したそれぞれのコマンドとを、ステップＳ００４において特定した、該当する機能部１０２ａへそれぞれ振り分けて出力する。その後、ステップＳ００６へ進む。
（ステップＳ００６）汎用装置１０ａの各機能部１０２ａは、ステップＳ００５において共通基盤部１０１ａから出力されたコマンド分類およびコマンドをそれぞれ取得する。その後、ステップＳ００７へ進む。
【００４６】
（ステップＳ００７）汎用装置１０ａの各機能部１０２ａは、ステップＳ００６において取得したコマンド分類およびコマンドに基づく処理をそれぞれ実行する。
以上で本フローチャートの処理が終了する。
【００４７】
［汎用装置における機能部の追加例］
以下、汎用装置１０ａに新たな機能部１０２ａを追加する場合について、図面を参照しながら説明する。
図６は、本発明の第１の実施形態に係る汎用装置１０ａに機能部１０２ａ−３を追加する場合について説明するための図である。図示するように、汎用装置１０ａに対して管理システム２０ａが接続される。
【００４８】
図示するように、図６に示す汎用装置１０ａおよび管理システム２０ａの構成は、図４において説明した構成に対して、汎用装置１０ａに機能部Ｃ１０２ａ−３が追加されたものである。
【００４９】
ベンダである丙が開発した機能部Ｃ１０２ａ−３が汎用装置１０ａに追加され、追加された機能部Ｃ１０２ａ−３に対する指示を行う場合、管理システム２０ａは、図６に図示するように、機能部Ｃ１０２ａ−３に対するコマンドを含めてカプセル化したうえで、指示フォーマットｆ１に基づく指示データを生成し、当該指示データを共通基盤部１０１ａへ送信する。
これにより、管理システム２０ａに対して改造などを行うことなく、新たに機能部Ｃ１０２ａ−３を追加することが可能になる。
【００５０】
また、図６に図示するように、共通基盤部１０１ａが、コマンド分類と、コマンドと、（該当機能部である）機能部Ｃ１０２ａ−３と、を対応付けた情報を、設定情報テーブルｔ１にあらかじめ登録しておくことによって、指示データに含まれるコマンドの中に機能部Ｃ１０２ａ−３に対するコマンドが含まれている場合であっても、共通基盤部１０１ａは、設定情報テーブルｔ１を参照することにより、当該コマンドが機能部Ｃ１０２ａ−３に対するコマンドであることを特定することができる。これにより、共通基盤部１０１ａは、機能部Ｃ１０２ａ−３に対しても、コマンド分類およびコマンドを振り分けて出力することができる。
【００５１】
以上、説明したように、本発明によれば、アクセス装置の機能がソフトウェア部品化され汎用装置１０ａに搭載されるため、ベンダロックインが解消される。なお、例えば、これと同様に、オペレーション向けの管理システム２０ａもソフトウェア部品化されるならば、従来オペレーションシステムが備えていた、ベンダ差異を吸収する機能が不要となるため、管理システム２０ａの開発費の削減を図ることもできる。このように、専用装置を汎用装置化し、機能をソフトウェア部品化することにより、ベンダに依存する機能を極小化、あるいは排除することができる。
【００５２】
具体的には、アクセス装置の機能をソフトウェア部品化し、汎用装置１０ａ上に構築することによって、同一システム（例えばＸＸ−ＰＯＮ）であれば同一機能のソフトウェア部品を複数用意する必要がなくなるため、複数のアクセス装置を同一の管理システム２０ａによって管理することが可能になる。Ｃｏｎｆｉｇ設定などの、ベンダごとの差異がなくなることから、アクセス装置ごとに管理システム２０ａを用意する必要がなくなり、コストダウンを図ることができる。
【００５３】
以上、説明したように、第１の実施形態によれば、装置ごとに固有の設定が必要であっても保守や運用を容易にすることができる。
【００５４】
＜第２の実施形態＞
以下、本発明の第２の実施形態について説明する。
なお、汎用装置および管理システムの全体構成については、図３を参照しながら説明した第１の実施形態と同様であるため、説明を省略する。
【００５５】
［汎用装置および管理システムの機能構成］
以下、汎用装置および管理システムの機能構成について図面を参照しながら説明する。
図７は、本発明の第２の実施形態に係る汎用装置１０ｂおよび管理システム２０ｂの機能構成を示す図である。なお、第１の実施形態と共通する構成については説明を省略する。
汎用装置１０ｂ上に構成される複数の機能部１０２ｂにおいて、当該機能部１０２ｂの設定のために用いることができる通信プロトコルが、あらかじめ特定の通信プロトコルに限定されている場合がある。例えば、図７に図示するように、機能部Ｂ１０２ｂ−２は、ＮＥＴＣＯＮＦの通信プロトコルによってのみ設定を行うことができる機能部である。
【００５６】
第２の実施形態においては、図７に図示するように、共通基盤部１０１ｂの記憶部１０１１は、コマンド分類と、コマンドと、該当機能部と、通信プロトコル（ＯＰＥＮＦＬＯＷ、ＮＥＴＣＯＮＦなど）とが対応付けられた設定情報テーブルｔ２をあらかじめ保持している。
【００５７】
なお、共通基盤部１０１ｂは、通信プロトコルだけでなく、各機能部１０２ｂに対して行われる指示において使用される各種情報の情報群（命令セット群）を、コマンド分類と、コマンドと、該当機能部と、に対応付けて、あらかじめ設定情報テーブルｔ２に保持しておくようにしてもよい。
【００５８】
共通基盤部１０１ｂは、機能部１０２ｂに対する管理システム２０ｂから送信された指示に基づくコマンドおよびコマンド分類に対応する、該当機能部および通信プロトコルを、共通基盤部１０１ｂの記憶部１０１１に記憶された設定情報テーブルｔ２を参照して特定する。
また、第２の実施形態においては、共通基盤部１０１ｂは機能設定部１０１２を備える。共通基盤部１０１ｂの機能設定部１０１２は、当該コマンドを、上記特定した通信プロトコルに適合するコマンドに変換する処理を行った後、該当する宛先である機能部１０２ｂへ出力（転送）する。
【００５９】
これにより、第２の実施形態によれば、機能部１０２ｂのベンダが異なっていたとしても、管理システム２０ｂに対して改造などを行うことなく、管理システム２０ｂから汎用装置１０ｂへ、コマンドを送信することができる。
このように、従来では、例えば、Ａ社のＯＬＴとＢ社のＯＬＴとでは、管理システムからＯＬＴへの命令の方法が異なっていたところを、本実施形態によれば、仮想化ＯＬＴ側で、当該命令の方法の差異を吸収することができる。これにより、本実施形態によれば、管理システム２０ｂは一つにすることができるため、保守や運用を容易にし、装置の設置コストも軽減させることができる。
【００６０】
以上、説明したように、第２の実施形態によれば、装置ごとに固有の設定が必要であっても保守や運用を容易にすることができる。
【００６１】
なお、上述した、第１の実施形態および第２の実施形態において、設定情報テーブル（ｔ１、ｔ２）には、機能部（１０２ａ、１０２ｂ）ごとに管理システム（２０ａ、１０ｂ）のバージョンがあらかじめ登録されているようにしてもよい。ここで登録されるバージョンは、機能部ごとに求められる管理システムのバージョンである。そして、管理システム（２０ａ、２０ｂ）のバージョンごとに、指示フォーマットが異なるような場合には、汎用装置（１０ａ、１０ｂ）において当該指示フォーマットを変換して、各機能部（１０２ａ、１０２ｂ）の設定を行うようにしてもよい。
なお、その他、ＯＰＥＮＦＬＯＷなどの通信プロトコルのバージョンなどを、設定情報テーブルｔ１（または設定情報テーブルｔ２）に登録しておくようにしてもよい。
【００６２】
なお、各機能部１０２ａ（または各機能部１０２ｂ）が、特定のバージョンの仮想マシンでしか動作しないような場合であっても、当該仮想マシンのバージョンを設定情報テーブルｔ１（または設定情報テーブルｔ２）にあらかじめ登録しておき、共通基盤部１０１ａ（または共通基盤部１０１ｂ）により、各仮想マシンに適合した命令へと変換したうえで、設定を行うようにしてもよい。
また、共通基盤部１０１ａ（または共通基盤部１０１ｂ）は、各機能部１０２ａ（または各機能部１０２ｂ）がどの仮想ＯＳで動いているのかを管理して、管理システム２０ａ（または管理システム２０ｂ）から取得した指示データを、設定情報テーブルｔ１（または設定情報テーブルｔ２）に基づいて、最適なフレームに変換したうえで出力するようにしてもよい。
【００６３】
なお、上述した共通基盤部１０１ａおよび共通基盤部１０１ｂは、ソフトウェアアーキテクチャにより、エージェントに渡すことによって実現するようにしてもよい。同一ＯＬＴ内、あるいは異なる汎用装置上で実装されているならば、本発明に基づく処理は可能となる。従来、機能間の差異をベンダごとに吸収する必要があったが、これにより、汎用装置上で差異を吸収することが可能となる。
【００６４】
なお、他の実施態様としては、ある特定のＯＮＵのＶＬＡＮ  ＩＤ（Virtual LAN Identifier）を「１」に設定したい（すなわち、デフォルトＶＬＡＮに設定したい）場合において、従来はベンダが異なるＯＬＴに対してはそれぞれ個別に設定を行う必要があったが、本発明に係る仮想化ＯＬＴによれば、共通の命令によって設定を反映させることができるため、設定作業が効率化される。
【００６５】
なお、上述した実施形態においては、機能部１０２ａ（または機能部１０２ｂ）を含む汎用装置１０ａ（または汎用装置１０ｂ）に共通基盤部１０１ａ（または共通基盤部１０１ｂ）が備えられる構成であるものとしたが、これに限られるものではなく、例えば、共通基盤部１０１ａ（または共通基盤部１０１ｂ）の機能の範囲のみを専用装置化して実装するようにしてもよい。
【００６６】
なお、共通な指示であっても、共通基盤部１０１ａ（または共通基盤部１０１ｂ）において各機能部１０２ａ（または各機能部１０２ｂ）に適合した命令に変換することとする。管理システム２０ａ（または管理システム２０ｂ）からは、通信プロトコルは同じで各機能部１０２ａ（または各機能部１０２ｂ）に対する指示のみ伝達するものとする。
【００６７】
なお、命令セットは同じでも、パラメータが異なるため、管理システム２０ａ（または管理システム２０ｂ）では、個々に設定が必要となる場合ある。この場合の実装としては、仮想化ＯＬＴ向けの信号をスニッフィングして変換する方法もある。
【００６８】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【００６９】
１０ａ・１０ｂ・・・汎用装置、
２０ａ・２０ｂ・・・管理システム、
５０ａ・５０ｂ・・・アクセス装置、
６０ａ・６０ｂ・・・管理システム、
１００ａ・１００ｂ・・・ＯＳ、
１０１ａ・１０１ｂ・・・共通基盤部、
１０２ａ・１０２ｂ・・・機能部
１０１１・・・記憶部
１０１２・・・機能設定部
【図１】
2019004295.tif 000003
【図２】
2019004295.tif 000004
【図３】
2019004295.tif 000005
【図４】
2019004295.tif 000006
【図５】
2019004295.tif 000007
【図６】
2019004295.tif 000008
【図７】
2019004295.tif 000009