(57)【要約】【課題】ある装置の筺体内の構成要素を他の装置の構成要素として活用する手段を提供すること。【解決手段】装置を構成し、装置外部と情報を授受する部品と、装置内部に備えられ、部品に対して装置外部から又は部品から装置外部に対して独立した装置又は自装置内部の部品として装置外部と情報のやり取りを可能にする経路と、を備える通信装置。【選択図】図１
2018022963.tif 000002
【特許請求の範囲】
【請求項１】
装置を構成し、装置外部と情報を授受する部品と、
装置内部に備えられ、前記部品に対して装置外部から又は前記部品から装置外部に対して独立した装置又は自装置内部の部品として装置外部と情報のやり取りを可能にする経路と、
を備える通信装置。
【請求項２】
装置外部から又は装置外部に対して前記情報を授受する部品に対する情報を透過又は装置外部から又は装置外部に対してそれ以外の部品に対する情報を遮断する代行部をさらに備える、請求項１に記載の通信装置。
【請求項３】
装置外部と情報を授受する部品を装置外で特定できる識別子又は経路又はそれらの組み合わせ等の装置外や当該装置を含む網内で一意の識別情報を付与する付与部をさらに備える、請求項１に記載の通信装置。
【請求項４】
装置外部と情報を授受する部品を特定できる識別子又は経路又はそれらの組み合わせの等の装置外や当該装置を含む網内で一意の識別情報を付与し、当該部品の識別情報を変換し、装置外や当該装置を含む網内では一意の識別情報となるように前記部品の識別情報を変換する変換部をさらに備える、請求項２に記載の通信装置。
【請求項５】
部品化した機能を備える通信装置の設計方法であって、
装置を構成し、装置外部と情報を授受する部品と、装置内部に備えられ、前記部品に対して装置外部から又は前記部品から装置外部に対して独立した装置又は自装置内部の部品として装置外部と情報のやり取りを可能にする経路と、を用いて前記通信装置を設計する設計方法。
【請求項６】
コンピュータを、請求項１から４のいずれか一項に記載の通信装置に備わる各機能部として機能させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、設計方法及び通信プログラムに関する。
【背景技術】
【０００２】
通信装置を備える通信システムには、例えば、ＰＯＮ（Ｐａｓｓｉｖｅ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ）システムがある。ＰＯＮシステムは、顧客の宅内等に設置されるＯＮＵ（Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ  Ｕｎｉｔ：光加入者線終端装置）と、局舎に設置される通信装置であるＯＬＴ（Ｏｐｔｉｃａｌ  Ｌｉｎｅ  Ｔｅｒｍｉｎａｌ：光加入者線端局装置）と、両者を接続する光ファイバ網とを備える（非特許文献１参照）。
通信装置において、装置の準拠規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して依存性の低い機能を部品化し、当該機能のアプリケーションプログラミングインタフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）等の入出力インタフェース（ＩＦ：Ｉｎｔｅｒｆａｃｅ）の少なくとも一部を明確化し、汎用性・移植性・拡張性を高めることで、準拠規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかが異なる機器間での共用や独自機能の追加を容易とすることができる（非特許文献２参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ＩＴＵ−Ｔ勧告Ｇ.９８９．１  ４０−Ｇｉｇａｂｉｔ−ｃａｐａｂｌｅ ｐａｓｓｉｖｅ ｏｐｔｉｃａｌ ｎｅｔｗｏｒｋｓ （ＮＧ−ＰＯＮ２）、２０１３
【非特許文献２】“ＦＡＳＡ”、［online］、ＮＴＴ、[平成２８年７月２８日検索]、インターネット＜http://www.ansl.ntt.co.jp/j/FASA/index.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００４】
機能を部品化する場合、部品の配置場所は同一筺体内とは限らず、複数筺体に分散して配置されることがある。逆に、筺体内の部品が他装置を構成する部品として利用されることがある。しかしながら、ある装置の筺体内の構成要素を他の装置の構成要素として活用することができないという問題があった。
【０００５】
上記事情に鑑み、本発明は、ある装置の筺体内の構成要素を他の装置の構成要素として活用する手段を提供することができる技術の提供を目的としている。
【課題を解決するための手段】
【０００６】
本発明の一態様は、装置を構成し、装置外部と情報を授受する部品と、装置内部に備えられ、前記部品に対して装置外部から又は前記部品から装置外部に対して独立した装置又は自装置内部の部品として装置外部と情報のやり取りを可能にする経路と、を備える通信装置である。
【０００７】
本発明の一態様は、上記の通信装置であって、装置外部から又は装置外部に対して前記情報を授受する部品に対する情報を透過又は装置外部から又は装置外部に対してそれ以外の部品に対する情報を遮断する代行部をさらに備える。
【０００８】
本発明の一態様は、上記の通信装置であって、装置外部と情報を授受する部品を装置外で特定できる識別子又は経路又はそれらの組み合わせの等の装置外や当該装置を含む網内で一意の識別情報を付与する付与部をさらに備える。
【０００９】
本発明の一態様は、上記の通信装置であって、装置外部と情報を授受する部品を特定できる識別子又は経路又はそれらの組み合わせの等の装置外や当該装置を含む網内で一意の識別情報を付与し、当該部品の識別情報を変換し、装置外や当該装置を含む網内では一意の識別情報となるように前記部品の識別情報を変換する変換部をさらに備える。
【００１０】
本発明の一態様は、部品化した機能を備える通信装置の設計方法であって、装置を構成し、装置外部と情報を授受する部品と、装置内部に備えられ、前記部品に対して装置外部から又は前記部品から装置外部に対して独立した装置又は自装置内部の部品として装置外部と情報のやり取りを可能にする経路と、を用いて前記通信装置を設計する設計方法である。
【００１１】
本発明の一態様は、コンピュータを、本発明に係る通信装置に備わる各機能部として機能させるためのプログラムである。
【発明の効果】
【００１２】
本発明により、ある装置の筺体内の構成要素を他の装置の構成要素として活用する手段を提供することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】通信装置の基本構成図である。
【図２】通信装置の例を示す図である。
【図３】通信装置のアーキテクチャの第１例を示す図である。
【図４】通信装置のアーキテクチャの第２例を示す図である。
【図５】通信装置のアーキテクチャの第３例を示す図である。
【図６】通信装置のアーキテクチャの第４例を示す図である。
【図７】アーキテクチャの別例を示す図である。
【図８】通信装置及び外部サーバ１６の構成の例を示す図である。
【図９】ＯＬＴの構成を示す図である。
【図１０】通信装置内の機能部間の信号／情報の流れを示す図である。
【図１１】ＰＯＮ主信号処理機能部３００が有する機能構成の例を示す図である。
【図１２】ＰＯＮアクセス制御機能部３２０が有する機能構成の例を示す図である。
【図１３】Ｌ２主信号処理機能部３４０が有する機能構成の例を示す図である。
【図１４】保守運用機能部３３０が有する機能構成の第１例を示す図である。
【図１５】保守運用機能部３３０が有する機能の構成の第２例を示す図である。
【図１６】保守運用機能部３３０が有する機能構成の第３例を示す図である。
【図１７】ＰＯＮマルチキャスト機能部３５０が有する機能構成の例を示す図である。
【図１８】省電力制御機能部３６０が有する機能構成の例を示す図である。
【図１９】周波数・時刻同期機能部３７０が有する機能構成の例を示す図である。
【図２０】プロテクション機能部３８０が有する機能構成の例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の一実施形態を、図面を参照しながら説明する。
（実施形態１）
通信装置は、例えば、ＰＯＮ等の光ファイバ網等の通信網を経由する光信号等の信号によって、他の通信装置との通信を実行する装置である。通信装置は、例えば、ＯＬＴである。通信装置は、例えば、ＯＳＵ（Ｏｐｔｉｃａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｕｎｉｔ）でもよい。通信装置は、例えば、光信号を切り替えるスイッチ部（ＳＷ）を備える又は備えないＯＬＴと、他のスイッチ部（ＳＷ）との組み合わせでもよい。通信装置は、例えば、ＯＬＴとＯＮＵとの組み合わせでもよい。通信装置は、複数の機器を備えてもよい。
【００１５】
部品間のやり取りは、後述のミドルウェアを介すが、通信装置の独自の転送経路や手段を用いてもよいし、ＯＰＥＮＦＬＯＷや、ＮＥＴＣＯＮＦ／ＹＡＮＧや、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）等の規格化された手段を用いてもよい。また、内部配線、バックボード、ＯＡＭ部、主信号線、専用の配線、オペレーションシステム、コントローラ又は制御盤（Ｃｏｎｔ盤）等の経路のいずれでよい。やり取りを直接終端して入力する場合、ＯＡＭ部又は主信号にカプセル化してもよい。やり取りをいずれかの箇所で終端して、内部配線、バックボード、ＯＡＭ部、主信号線、専用の配線、オペレーションシステム、コントローラ又は制御盤等の経路を経由して入力してもよい。ＯＡＭ部や主信号線を用いる場合、ＯＡＭ部や主信号にカプセル化することが望ましい。主信号線を通す場合はＯＳＵ又は他箇所のスイッチ部にて振り分けることが望ましい。
【００１６】
次に、例として、ＴＷＤＭ（Ｔｉｍｅ  ａｎｄ  Ｗａｖｅｌｅｎｇｔｈ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘ）−ＰＯＮシステムのようなＩＴＵ−Ｔ勧告準拠のＰＯＮのＯＬＴを前提に、動作等を例示する。ここで、ＴＷＤＭ−ＰＯＮとしているが、ＰＯＮは、ＩＴＵ−Ｔ勧告準拠のＴＷＤＭ−ＰＯＮ以外のＰＯＮであってもよい。例えば、ＰＯＮは、ＧＥ（Ｇｉｇａｂｉｔ  Ｅｔｈｅｒｎｅｔ（登録商標））−ＰＯＮ、１０ＧＥ−ＰＯＮ等のＩＥＥＥ規格準拠のＰＯＮであってもよい。ＴＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｖｅｒｇｅｎｃｅ）レイヤやＰＭＤ（Ｐｈｙｓｉｃａｌ  Ｍｅｄｉｕｍ  Ｄｅｐｅｎｄｅｎｔ）レイヤは、標準規格において対応する層に読み替えれば同様である。
【００１７】
通信装置は、ハードウェア又はソフトウェア又はそれらの組み合わせの部品又は部品化した機能を備える。例えば、サービス毎あるいは通信事業者毎に異なる機能等を、汎用化した入出力インタフェース（例えば、ＦＡＳＡアプリケーションＡＰＩ）を用いて実現されるソフトウェア部品であるアプリケーション（例えばＦＡＳＡアプリケーション）と、該アプリケーションに汎用化した該入出力インタフェースを提供すると共に標準化されている等の理由で、サービスや要求に応じた変更が不要な機能を提供するアクセスネットワーク装置の基盤的構成要素（例えば、ＦＡＳＡ基盤）とから構成されていてもよい。以下、具体的に説明する。
【００１８】
(手段１−１、外部との接続)
図１に示すように、通信装置は、装置を構成する部品に対して装置外部から又は装置を構成する部品から装置外部に対して、独立した装置又は自装置内部の部品として当該部品と情報(制御情報、性能情報、警報情報、主信号等)を授受するための経路を備える。
ここで、独立した装置又は自装置内部の部品としてとは、装置外部から当該部品を指定して制御情報、性能情報、主信号等を授受することを意味する。
例えば、情報が制御情報の場合は、部品が装置外部から制御されるか又は装置外部を制御する又はそれらの組み合わせである。経路は手段１−１の上の図に示すように、該当する部品の複数に対して共通で用いる経路であってもよいし、手段１−１の下の図に示すように特定の部品が単独で用いる経路であってもよいし、それらの組み合わせであってもよい。また、制御信号や性能情報や警報情報や主信号等のやり取りする種類毎に複数の代行部や経路があってもよい。図１では、二重線が情報の経路を意味し、矢印が情報のやり取りを意味する。経路を共有する場合は経路数が少なくなる効果があり、単独で用いる場合は経路により部品を識別できる効果や、共有する部品間の授受の競合による遅延や帯域不足が軽減される効果がある。以上は後述する構成でも同様である。
【００１９】
また、独立した装置又は自装置内部の部品として情報を授受しない部品に経路が接続されてもよい。その場合、経路又は部品又はそれらの間の部分がそれらの部品に関連する情報の授受を遮断することが望ましい。例えば、通信装置は、装置を構成する部品で、装置外部に制御される／装置外部を制御する部品に、装置外と制御情報をやり取りする経路を装置内部に備え、当該部品に対する／当該部品からの制御情報をやり取りする手段を部品に備える。具体的には、手段１−１では、通信装置は、例えば装置の制御に用いる信号線、例えば共通信号線の信号の情報をそのまま或いは少なくとも装置を構成する部品で、装置外部に制御される／装置外部を制御する部品の情報を含む情報を装置内外に通信する経路を備える。なお、図１では、該当する部品以外の装置以外の情報を授受する経路を記載しているが、なくてもよい。以上は後述する構成でも同様である。
【００２０】
(手段１−２、外部との接続)
手段１−１の変形であり、通信装置は代行部を備え、装置外部から又は装置外部に対して情報を授受する部品に対する情報は代行部を介する。代行部は、装置外部から又は装置外部に対して情報を授受する部品に対する情報を透過する、又は、装置外部から又は装置外部に対してそれ以外の部品に対する情報を遮断することが望ましい。また、代行部は、情報の授受確認であるＡＣＫ等を当該部品の代わりに代行して授受してもよい。この場合、当該部品の処理が簡易化する。また、代行部は、装置内外で信号伝送の形式、例えばフレームフォーマットやトレーラーの有無やＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）の有無や暗号化の有無等を装置内では装置内の形式に、装置外では装置外の形式としてもよい。
例えば、通信装置は、装置を構成する部品又は機能部品で、装置外部に制御される／装置外部を制御する部品に、装置外と制御情報のやり取りを代行する手段を備え、当該代行する手段が当該部品に対する／当該部品からの制御情報を受け渡す。具体的には、手段１−２では、通信装置は、例えば装置の制御に用いる信号線、例えば共通信号線の信号の情報で少なくとも代行される部品の情報を装置内外に代行部を介して通信する経路を備える。
また図では代行部は部品で共有する形で示しているが、一つ又は複数の部品毎に別の代行部であってもよいし、制御信号や性能情報や警報情報や主信号等のやり取りする種類毎に複数の代行部や経路があってもよい。
【００２１】
(手段２−１、外部との制御／非制御対象の識別)
手段１−１の変形であり、装置外と情報を授受する部品を特定できる識別子や経路（図１の手段１−１の構成の下側相当）やその組み合わせ等の装置外や当該装置を含む網内で一意の識別情報を手段１−１に追加した。
例えば、通信装置は、装置を構成する部品で、装置外部に制御される／装置外部を制御する部品に、識別子又は経路又はそれらの組み合わせ等の装置外や当該装置を含む網内で一意の識別情報を付与し、当該識別情報により当該部品を一意に制御する。あるいは制御情報のやり取りを代行する手段を備え、当該代行する手段が当該部品に制御情報を受け渡す。なお、識別情報の付与は、装置自体でも、ＮＥコントローラ等の装置外で行ってもよい。
具体的には、手段２−１では、通信装置は、筺体に係る架番号やＭＡＣアドレス等に筺体内の部品を示す子番号等を追加又は付加又は乗ずる等の演算を行って装置外で用いる一意のグローバル番号等として装置外や当該装置を含む網内で一意の識別情報として用いる。部品毎の経路を用いる場合は、筺体に係る架番号やＭＡＣアドレス等に経路に関する値を追加又は付加又は乗ずる等の演算を行って装置外で用いるグローバル番号等の識別情報として用いる。
【００２２】
識別情報は、実効的に一意であればよい。例えば、対象とする部品を装置外や当該装置を含む網内から一意に識別できればよいため、複数の部品が単一の識別情報に対応して、対象とする部品以外が情報を授受しない設定とすれば実効的に一意となる。このような設定は、同一系統の機能を備える部品同士で互いに排他的に利用する部品であれば、装置外部の設定を変えることなく別部品に入れ替えて利用することが可能である。経路で識別する場合は、複数の部品が単一の識別情報であるとは、同一経路に複数の部品が共有している状態に対応する。以上は後述する構成でも同様である。
【００２３】
このような通信装置は例えば図２のＯＳＵである。ＯＳＵ内の波長毎（λ１、λ２、λ３、λ４）のＣＴ（Ｃｈａｎｎｅｌ  Ｔｅｒｍｉｎａｔｉｏｎ）は独立した部品として異なるＳＷに接続している。言い換えると実ＯＳＵ内のＣＴがそれぞれ別の仮想的なＯＳＵの部品として信号を導通し、仮想的なＯＳＵとＳＷが接続している。このような構成では、ＣＴがＯＳＵ外から一意に制御できないと、ＰＯＮ毎の制御が困難であるが、本願では一意に制御できるため制御が容易である。
なお、図では、該当する部品以外の装置以外の情報を授受する経路を記載しているが、なくてもよい。
【００２４】
(手段２−２、外部との制御／非制御対象の識別)
手段１−２の変形であり、装置外部と情報を授受する部品を特定できる識別子や経路（図１の手段１−２の構成の下側相当）やその組み合わせ等の装置外で一意の識別情報を手段１−２に追加した。識別情報は識別情報を付与する付与部により付与してもよいし、付与部の付与する識別情報は、当該部品を含む装置外で一意であれば、付与部自体、付与部以外の装置の内部、コントローラ等の外部の装置のいずれの定める値であってもよい。
代行部は、手段１−２の処理とは別に又は加えて、情報を授受する部品が外部と授受する情報の該情報の宛先／送信元の部品の識別情報を、装置外部で他の装置及び他の装置を構成し、独立した装置又は自装置内部の部品として外部の装置と通信する部品が、少なくとも該部品を収容する装置の外部で、識別子の変換や経路の選択又はその組み合わせで、装置外や当該装置を含む網内で一意の識別情報とした。
【００２５】
通信装置は、装置を構成する部品に対して装置外部から又は装置を構成する部品から装置外部に対して、独立した装置又は自装置内部の部品として当該部品と情報(制御情報、性能情報、主信号等)を授受するための経路を備える。例えば、情報が制御情報の場合は、通信装置は、装置を構成する部品で、装置外部に制御される／装置外部を制御する部品に、装置外で識別子又は経路又はその組み合わせ等の装置外や当該装置を含む網内で一意の識別情報を付与し、装置内外で当該部品の識別子を変換し、装置内部では少なくとも装置内部では一意の識別子を付与し、装置外や当該装置を含む網内で一意の識別情報となるように当該部品の識別子を装置内外で変換する手段を備える。
【００２６】
具体的には、手段２−２では、通信装置は、例えば、筺体に係る架番号やＭＡＣアドレス等に筺体内の部品を示す子番号等を追加又は付加又は乗ずる等の演算を行って装置内外で用いるグローバル番号等の装置外や当該装置を含む網内で一意の識別情報又は筺体に係る架番号やＭＡＣアドレス等に経路に関する値を追加又は付加又は乗ずる等の演算を行って装置外で用いるグローバル番号等の装置外や当該装置を含む網内で一意の識別情報を筺体内の部品の子番号に、いずれかの箇所、例えば筺体内部あるいはＮｅＯｐＳ等のコントローラやそれら以外のネットワークの手段にて付替する。
手段２−２では、通信装置は、例えば、筺体に係る架番号やＭＡＣアドレス等に筺体内の子番号等からなるグローバル番号に対して、筺体外の予め定めたあるいはすべての装置からの制御等の情報のやり取りであることを識別して、当該部品自体が応答する識別情報を変更する。
【００２７】
（実施形態１−１）
実施形態１−１では、ＴＷＤＭ−ＰＯＮに用いられる通信システムを構成する通信装置の構成について説明する。以下、通信装置のアーキテクチャの例として、第１例から第６例までを説明する。通信システムを構成する通信装置のアーキテクチャは、下記で説明する第１例から第６例まで以外のアーキテクチャであってよい。例えば、アーキテクチャの第１例から第６例における通信装置のソフトウェア部は、ハードウェア部でもよい。
【００２８】
（アーキテクチャの第１例）
図３は、通信装置のアーキテクチャの第１例を示す図である。アーキテクチャの第１例では、通信装置は、準拠する標準や製造ベンダに依存する機器依存部１１０と、機器依存部１１０のハードウェアやソフトウェアの違いを隠蔽するミドルウェア１２０と、動作が機器に依存しない汎用の機器無依存アプリ１３０とを備える。したがって、機器依存部（ベンダ依存部）１１０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存する機能部である。言い換えれば、機器依存部１１０は、他の通信機器との互換性が小さく、新たに製造された通信機器（特に、準拠する標準や製造ベンダが異なる機器）にはそのまま用いることができない。機器依存部１１０は、ネットワーク機器に備わる１以上の機能を実行する。
【００２９】
また、機器無依存アプリ１３０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存しない機能部である。言い換えれば、機器無依存アプリ１３０は、他の通信機器との互換性が大きく、新たに製造された通信機器（特に、準拠する標準や製造ベンダが異なる機器）にそのまま用いることができる。機器無依存アプリ１３０に設けられるアプリの具体例として、ネットワーク機器における設定処理を行うアプリ、設定の変更処理を行うアプリ、アルゴリズム処理を行うアプリ等がある。
ミドルウェア１２０と機器無依存アプリ１３０とは、機器無依存ＡＰＩ２１を介して接続される。機器無依存ＡＰＩ２１は、機器に依存しない入出力ＩＦである。
【００３０】
機器依存部１１０は、例えばハードウェア部（ＰＨＹ）１１１、ハードウェア部（ＭＡＣ）１１２、ソフトウェア部１１３及びＯＡＭ（Ｏｐｅｒａｔｉｏｎ  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  ａｎｄ  Ｍａｉｎｔｅｎａｎｃｅ）部１１４を備えて構成される。ハードウェア部（ＰＨＹ）１１１、ハードウェア部（ＭＡＣ）１１２、ソフトウェア部１１３及びＯＡＭ部１１４と、ミドルウェア１２０とは、機器依存ＡＰＩ２３を介して接続される。機器依存ＡＰＩ２３は、機器に依存する入出力ＩＦである。機器依存部１１０は、更にＮＥ（ＮＥ、Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ）管理・制御部１１５を備える。ＮＥ管理・制御部１１５とミドルウェア１２０とは、機器依存ＡＰＩ２５を介して接続される。
【００３１】
どのような機能を機器依存部１１０又は機器無依存アプリ１３０とするかは、ミドルウェア１２０や機器無依存アプリ１３０を実現するための処理に由来する制限、例えば、ソフトウェアの処理能力に由来する制限に加えて、機能の更新頻度や拡張機能の重要度等に応じて決められてもよい。これによって、通信装置は、機器無依存アプリ１３０による拡張機能部（独自機能部）の柔軟かつ迅速な追加を容易にし、通信サービスをタイムリーに提供することができる。
【００３２】
例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ（Ｄｙｎａｍｉｃ  Ｂａｎｄｗｉｄｔｈ  Ａｓｓｉｇｎｍｅｎｔ）等の更新頻度が高い機能又は通信サービス差異化に寄与する機能を優先して、機器依存部１１０又は機器無依存アプリ１３０とすることを決めてもよい。更に、共用化を図る機器の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して差異の隔たりが小さいものから、機器無依存アプリ１３０としてもよい。
【００３３】
準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに対しては最適でない場合でも、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの機能のいずれかを汎用化するために、機能を実行するための共通ＩＦが用いられてもよい。共通ＩＦの中には、機器依存部１１０の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダのいずれかにおいて使用されないＩＦやパラメータが含まれていてもよい。
【００３４】
図３及び後述する図４に示すミドルウェア１２０と、後述する図５及び後述する図６に示す機器依存部１１０のドライバと、後述する図４及び後述する図６に示す機器依存アプリ部（ベンダ依存アプリ部）との少なくともいずれかに、ＩＦやパラメータ等を機器依存部１１０に対応するように変換する変換機能部や、不足するＩＦやパラメータ等に対応して自動設定する機能部を更に備えてもよい。
【００３５】
図３に示す機器依存部１１０が備えるハードウェア部（ＰＨＹ）１１１は、物理層から光送受信関連の処理まで（ＰＨＹｓｉｃａｌ  ｓｕｂｌａｙｅｒ処理）を実行する。ハードウェア部（ＭＡＣ）１１２は、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）処理を実行する。ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２は、準拠する標準規格や製造ベンダに依存する。ソフトウェア部１１３は、機器依存のドライバ、ファームウェア、アプリケーション等を実行する。
【００３６】
機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２は、これら以外に汎用サーバやレイヤ２スイッチ等を備えてもよい。機器依存部１１０は、ハードウェア部（ＭＡＣ）１１２を備えなくてもよい。機器依存部１１０は、ハードウェア部（ＰＨＹ）１１１の一部を備えなくてもよい。例えば、機器依存部１１０は、変復調信号処理、前方誤り訂正（ＦＥＣ、Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）、符復号処理、暗号化処理等の低位の信号処理を備えずに、光関連の機能のみを備えてもよい。機器依存部１１０は、データを符号化する部分であるＰＣＳ（Ｐｈｙｓｉｃａｌ  Ｃｏｄｉｎｇ  Ｓｕｂｌａｙｅｒ）を備えなくてもよい。機器依存部１１０は、データのシリアル化を行うＰＭＡ（Ｐｈｙｓｉｃａｌ  Ｍｅｄｉｕｍ  Ａｔｔａｃｈｍｅｎｔ）とＰＣＳとを備えなくてもよい。機器依存部１１０は、物理媒体に接続するＰＭＤを備えなくてもよい。機器依存部１１０は、ミドルウェア１２０がソフトウェア部を介さずに機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を直接に駆動、制御、操作又は管理する場合、ソフトウェア部を備えなくてもよい。
【００３７】
機器無依存アプリ１３０は、例えば、拡張機能部（図３では、拡張機能Ａ１３１−１、拡張機能Ｂ１３１−２及び拡張機能Ｃ１３１−３）１３１と、基本機能部１３２と、管理・制御エージェント部１３３とを備える。管理・制御エージェント部１３３は、ＥＭＳ（Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）１４０からデータを取得する。図ではＥＭＳ１４０及び外部の装置１５０がミドルウェア１２０を介して機器無依存アプリ１３０に接続しているが、ＥＭＳ１４０及び外部の装置１５０は必ずしもミドルウェア１２０を介して機器無依存アプリ１３０に接続している必要はない。ＥＭＳ１４０及び外部の装置１５０は、必要に応じてミドルウェア１２０に適宜接続してもよいし、機器無依存アプリ１３０に直接接続してもよい。また「ミドルウェア１２０経由で接続」と表現しているが、この表現は機器無依存アプリ１３０からみた視点での表現である。実際には、ハードウェアでの接続の後にミドルウェア１２０を介して機能無依存アプリ同士が接続している。
【００３８】
以下、拡張機能部に共通する事項については、符号の一部を省略して、「拡張機能部」と表記する。ＥＭＳ１４０は、例えば、ＮＥのコントローラである。なお、機器無依存アプリ１３０は、拡張機能部と基本機能部１３２と管理・制御エージェント部１３３とのうちいずれかを含まなくてもよいし、管理・制御エージェント部１３３が基本機能部１３２に含まれていてもよいし、管理・制御エージェント部１３３が基本機能部１３２やミドルウェア１２０に含まれていてもよい。
【００３９】
機器無依存アプリ１３０は、拡張機能部、基本機能部１３２、及び管理・制御エージェント部１３３以外の構成を、更に含んでいてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリ１３０は、拡張機能部を備えなくてもよい。また、機器無依存アプリ１３０は、１個以上の拡張機能部を含んでもよい。
【００４０】
拡張機能部は、他の機能に不要な影響を与えずに独立して追加、削除、入替又は変更が可能であることが好ましい。例えば、拡張機能部は、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を実行する拡張機能部が必要になった場合、適宜に追加、削除、入替又は変更されてもよい。
【００４１】
基本機能部１３２は、拡張機能部の一部として機器無依存アプリ１３０に含まれてもよいし、ミドルウェア１２０よりも下位の機能部によって代替されてもよい。拡張機能部が基本機能部１３２を含む場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。ミドルウェア１２０よりも下位の機能部が基本機能部１３２を代替する場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。拡張機能部が基本機能部１３２を含み、ミドルウェア１２０よりも下位の機能部が基本機能部１３２を代替する場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。
【００４２】
管理・制御エージェント部１３３は、ＥＭＳ１４０からの通信を受けずに、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０と入出力しなくてよい。更に、管理・制御エージェント部１３３が管理設定機能を備えず、他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。
【００４３】
ＥＭＳ１４０と機器無依存アプリ１３０とは、情報を直接入出力してもよい。また、機器依存部１１０は、ＮＥ管理・制御部１１５と、ＮＥ管理・制御部１１５の下位の機能部の機器依存アプリ部（後述する図４及び後述する図６参照）によって代替されてもよい。
【００４４】
管理・制御エージェント部１３３は、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０との間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部１３３が備えず他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。ＥＭＳ１４０と機器無依存アプリ１３０とは、情報を直接入出力してもよい。
【００４５】
機器無依存アプリ１３０と機器依存部１１０との入出力の例は以下である。
例えば、ＤＢＡアプリ部及びプロテクションアプリ部は、ＴＣレイヤのエンベデッドＯＡＭエンジン（Ｅｍｂｅｄｄｅｄ  ＯＡＭ  Ｅｎｇｉｎｅ）と、相互に情報を入出力する。ＤＷＢＡ（Ｄｙｎａｍｉｃ  Ｗａｖｅｌｅｎｇｔｈ  ａｎｄ  Ｂａｎｄｗｉｄｔｈ  Ａｓｓｉｇｎｍｅｎｔ）アプリ及びＯＮＵ登録認証アプリ部は、ＴＣレイヤのＰＬＯＡＭエンジンと、相互に情報を入出力する。省電力アプリ部は、ＯＭＣＩ及びＬ２主信号処理機能部（Ｌ２機能部）と相互に情報を入出力する。ＭＬＤ（Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒ）プロキシアプリ部は、Ｌ２機能部と相互に情報を入出力する。低速監視アプリ（ＯＭＣＩ）は、ＯＭＣＩと相互に情報を入出力する。ＯＭＣＩ及びＬ２機能部は、ＸＧＥＭフレーマ（ＸＧＰＯＮ  Ｅｎｃａｐｓｕｌａｔｉｏｎ  Ｍｅｔｈｏｄ  Ｆｒａｍｅｒ）及び暗号化を動作させる。ここで、ＤＷＢＡとＤＢＡは、別々、一体又は組み合わせでもよい。例えば、管理・制御エージェント部１３３は、保守運用機能のアプリ部であり、ＮＥ管理・制御部１１５のためのＮＥコントローラ等であるＥＭＳ１４０と、相互に情報を入出力する。
【００４６】
機器無依存アプリ１３０は、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＴＵ−Ｔ  Ｇ．９８９シリーズに準拠するＴＷＤＭ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８７シリーズに準拠するＸＧ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８４シリーズに準拠するＧ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８３シリーズに準拠するＢ（Ｂｒｏａｄｂａｎｄ）ＰＯＮとのいずれにもよらずに動作するアプリである。機器無依存アプリ１３０は、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＥＥＥ８０２．３ａｖやＩＥＥＥ１９０４．１等に準拠する１０ＧＥ−ＰＯＮとＩＥＥＥ８０２．３ａｈに準拠するＧＥ−ＰＯＮ等の差異の少なくともいずれかによらずに動作するアプリである。
【００４７】
拡張機能部のアプリとして、機器無依存ＡＰＩ２１を介して、一部のベンダ、方式、種別、世代に備える機能を駆動するためのアプリや、一部のベンダ、方式、種別、世代の装置のみに備える機能を駆動するアプリを含んでいてもよい。
管理・制御エージェント部１３３は、ＥＭＳ１４０及びミドルウェア１２０と入出力する。ミドルウェア１２０は、ＮＥ管理・制御部１１５との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＮＥ管理情報及び制御情報をＥＭＳ１４０と直接送受信してもよいし、管理・制御エージェント部１３３を介して、ＮＥ管理情報及び制御情報を送受信してもよい。
【００４８】
ミドルウェア１２０は、機器無依存アプリ１３０と機器無依存ＡＰＩ２１を介して情報を入出力する。ミドルウェア１２０は、機器依存ＡＰＩ２３を介して、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部又はハードウェア部と情報を入出力する。ミドルウェア１２０は、入力した情報を、そのまま又は所定の形式で出力する。例えば、ミドルウェア１２０は、出力先が機器無依存アプリ１３０の各部であれば、機器無依存ＡＰＩ２１の各部の入力形式に情報を変換する。出力先が機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部又はハードウェア部であれば、ミドルウェア１２０は、それぞれに入力する形式の機器依存ＡＰＩ２３の形式に変換してから、又は終端して所定の処理を施してから情報を出力先に送信する。
【００４９】
ミドルウェア１２０は、入力の際に、それぞれの入力先に不要な入力情報は削除し、不足の情報があれば、他の機器無依存ＡＰＩ２１や機器依存ＡＰＩ２３を介して収集して補足することが望ましい。また、ミドルウェア１２０への入力の際に、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。
【００５０】
図３では、ミドルウェア１２０や機器依存部１１０は単一で例示したが、それぞれ複数から構成されていてもよい。機器依存部１１０のハードウェアに複数のプロセッサが含まれる場合、ミドルウェア１２０はプロセッサやハードウェアをまたいでプロセッサ間通信等を用いて入出力してもよい。機器無依存アプリ１３０間や機器無依存アプリ１３０をＤＬＬ（Ｄｙｎａｍｉｃ  Ｌｉｎｋ  Ｌｉｂｒａｒｙ）のような実行プログラムとして、単一のプロセッサ上のユーザ空間上に配置してもよいし、複数のプロセッサ上のユーザ空間上に配置してもよい。
【００５１】
また、機器無依存アプリ１３０は、ＡＰＩ等の入出力ＩＦを確保した上でカーネル空間に配置してもよいし、独立にファームウェア等に入替可能なＩＦを有するミドルウェア１２０とともに配置してもよいし、ファームウェア等に組み込んでコンパイルし直してもよい。機器無依存アプリ１３０毎にユーザ空間やカーネル空間を任意の組み合わせとしてもよい。
【００５２】
同一の機能に対応する機器無依存アプリ１３０を、ユーザ空間とカーネル空間の両方で実装可能としてもよい。この場合、例えば、切り替えていずれかを選択してもよいし、両方協働して処理してもよいし、一方のみで実処理を行うとしてもよい。機器依存部１１０のソフトウェアも同様である。
【００５３】
望ましくは、主信号処理やＤＢＡ処理や低レイヤの信号処理のように高速処理が必要であるほど、拡張性・入替の即時性とトレードオフはあるが、オーバーヘッドが少なく高速な処理が期待されるカーネル空間やファームウェアに組み込むことが望ましい。機器依存アプリ部（後述する図４及び後述する図６参照）を配置するプロセッサもプロセッサ間通信によるバスや速度等の制限、通信路の占有等による他のプログラムへの影響の観点から、実処理を行うプロセッサ又はその近傍のプロセッサのユーザ空間やカーネル空間やファームウェア上に配置することが望ましい。ただし、実処理を行うプロセッサ又はその近傍のプロセッサの能力を軽減するためにはプロセッサ間通信によるコミュニケーションコストは増大するが、遠隔のプロセッサで処理するとしてもよい。
【００５４】
機器無依存ＡＰＩ２１は、追加する拡張機能部を想定してミドルウェア１２０に予め備えられることが望ましいが、機器依存ＡＰＩ２３や他の機器無依存アプリ１３０の改変を抑制する形で、必要に応じて追加又は削除されてもよい。
【００５５】
なお、本例では、ソフト化領域を、基本機能部１３２、管理・制御エージェント部１３３、拡張機能部、ミドルウェア１２０としたが、ソフト化領域は、サービスアダプテーション（暗号化、フラグメント処理、ＧＥＭフレーム化／ＸＧＥＭフレーム化、ＰＨＹアダプテーションのＦＥＣ、スクランブル、同期ブロック生成／抽出、ＧＴＣ（ＧＰＯＮ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｖｅｒｇｅｎｃｅｓ）フレーム化、ＰＨＹフレーム化、ＳＰ変換、符号化方式も対象としてもよい。アーキテクチャのソフト化機能の実装例とハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２に対応する機能配備の例を説明する。機能配備は、例えば、ネットワーク機器又は外部のサーバにソフト化機能を備える。これは他の例でも同様である。
【００５６】
（アーキテクチャの第２例）
図４は、通信装置のアーキテクチャの第２例を示す図である。図４では、通信装置は、図３に示す通信装置のミドルウェア１２０の配下に機器依存アプリ部１６０を更に備えた構成である。アーキテクチャの第２例は、機器依存アプリ部１６０を備えること以外は、アーキテクチャの第１例と同様である。
【００５７】
図４では、通信装置は、準拠する機器依存部１１０の標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等を実行するソフトウェア部と、機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２やソフトウェア部の少なくとも一部を駆動する機器依存アプリ部１６０と、機器依存部１１０のハードウェア部、ハードウェア部、ソフトウェア部及び機器依存アプリ部１６０の違いを隠蔽するミドルウェア１２０と、機器に依存しない汎用の機器無依存アプリ１３０とを備える。
【００５８】
ミドルウェア１２０と機器依存アプリ部１６０とは、機器依存ＡＰＩ２３で接続される。機器依存アプリ部１６０と、機器依存部１１０のＯＡＭ部１１４、ソフトウェア部、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２とは、機器依存ＡＰＩ２４で接続される。機器依存アプリ部１６０と管理・制御エージェント部１３３とは、ＡＰＩで接続される。
【００５９】
機器無依存アプリ１３０は、例えば、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３と、基本機能部１３２と、拡張機能部とを備える。機器無依存アプリ１３０は、アーキテクチャの第１例と同様に、管理・制御エージェント部１３３と基本機能部１３２と拡張機能部とのうちいずれかを備えなくてもよい。機器無依存アプリ１３０は、管理・制御エージェント部１３３と基本機能部１３２と拡張機能部と以外の機能部を、更に備えてもよい。また、拡張機能部は、アーキテクチャの第１例と同様に、他の機能に影響を与えずに追加、削除、入替又は変更が可能であることが好ましい。
【００６０】
基本機能部１３２は、各拡張機能部の一部として含まれていてもよいし、ミドルウェア１２０の下位で代替されてもよい。拡張機能部が基本機能部１３２を含む場合や、ミドルウェア１２０の下位が基本機能部１３２を代替する場合や、それらの組み合わせである場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。
また、基本機能部１３２の一部もミドルウェア１２０の下位の機器依存アプリ部１６０で代替してもよい。管理・制御エージェント部１３３は、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０との間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部１３３が備えず、他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。
ＥＭＳ１４０と機器無依存アプリ１３０とは、直接入出力してもよい。ミドルウェア１２０の下位が基本機能部１３２の全てを代替する場合、機器無依存アプリ１３０は、基本機能部１３２を備えなくてもよい。
【００６１】
図４に示す通信装置において、機器依存アプリ部１６０は、ミドルウェア１２０を介して情報を入出力してもよいし、管理・制御エージェント部１３３から情報を直接入出力してもよいし、両者のうちのいずれかとの間で情報を入出力してもよいし、ＥＭＳ１４０と直接入出力してもよい。また、機器依存アプリ部１６０が、ＥＭＳ１４０からの通信を受けずに、予め定められた設定に従って自動設定されており、ミドルウェア１２０を介してＥＭＳ１４０から管理及び制御情報を取得可能である場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。
【００６２】
機器無依存アプリ１３０は、ミドルウェア１２０を介して少なくとも機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２との間又はソフトウェア部との間で、情報を入出力する。機器無依存アプリ１３０は、必要に応じてミドルウェア１２０を介して、相互に入出力する。特に、機器無依存アプリ１３０は、ＥＭＳ１４０との間で入出力された情報に応じて制御又は管理を実行する場合、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３との間で、情報を入出力する。
ＮＥ管理・制御部１１５は、ミドルウェア１２０を介して管理・制御エージェント部１３３との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＥＭＳ１４０との間で、ＮＥ管理情報及び制御情報を直接入出力してもよい。
【００６３】
機器依存アプリ部１６０は、管理・制御エージェント部１３３との間で、ＮＥ管理情報及び制御情報を入出力している。機器依存アプリ部１６０は、管理・制御エージェント部１３３を介さずに、ＥＭＳ１４０との間で、情報を直接入出力してもよい。管理・制御エージェント部１３３は、ＥＭＳ１４０、ミドルウェア１２０及び機器依存アプリ部１６０との間で、情報を入出力する。ミドルウェア１２０は、ＮＥ管理・制御部１１５との間で、ＮＥ管理情報及び制御情報を入出力する。
ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＥＭＳ１４０との間で、ＮＥ管理情報及び制御情報を直接入出力してもよい。ミドルウェア１２０は、機器無依存アプリ１３０との間で、機器無依存ＡＰＩ２１を介して情報を入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２との間で、機器依存ＡＰＩ２３を介して情報を入出力する。
【００６４】
ミドルウェア１２０は、図３に示すミドルウェア１２０と同様に、そのまま又は所定の形式で入力する。機器無依存ＡＰＩ２１は、後から追加する拡張機能部を想定して、予めミドルウェア１２０に備えることが望ましいが、必要に応じて、機器依存ＡＰＩ２３や他の機器無依存アプリ１３０の改変を抑制する形で追加又は削除してもよい。
【００６５】
（アーキテクチャの第３例）
図５は、通信装置のアーキテクチャの第３例を示す図である。図５では、図３に示すアーキテクチャの第１例で説明したミドルウェア１２０の代わりに、基本機能部１３２が、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、拡張機能部との入出力を行う。その他の機器無依存アプリ１３０は、アーキテクチャの第１例と同様である。
【００６６】
アーキテクチャの第１例と比べて、第３例は、機器依存ＡＰＩを備えるミドルウェア１２０を、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかが異なる機器毎に作成する必要がない。これによって、アーキテクチャの第３例の通信装置は、機器間世代間でより多くの機能を汎用化して移植し易く、接続性の検証も容易で、機器の機能が堅牢となる効果がある。
【００６７】
アーキテクチャの第３例による通信装置は、機器依存部１１０と、機器無依存アプリ１３０とを備える。機器依存部１１０は、準拠する標準規格又は機器製造ベンダ等に依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等のソフトウェア部とを備える。ドライバ等は、機器依存部１１０の違いを隠蔽する。
【００６８】
機器無依存アプリ１３０は、拡張機能部と、基本機能部１３２とを備える。基本機能部１３２は、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との違いを隠蔽するドライバを介して、機器無依存ＡＰＩ２７（移植用ＩＦ）により機器依存部１１０と接続する。機器無依存アプリ１３０は、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との違いを隠蔽するドライバを介して、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との間で、データを入出力する。
【００６９】
基本機能部１３２と拡張機能部とは、機器無依存ＡＰＩ２２（拡張用ＩＦ）を介して接続される。基本機能部１３２と機器依存部１１０とは、機器無依存ＡＰＩ２７を介して接続される。機器無依存アプリ１３０の内の基本機能部１３２が、ミドルウェア１２０の代わりに、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２や拡張機能部との間で、情報の入出力を行う。
機器無依存アプリ１３０は、必要に応じて基本機能部１３２を介して、相互に入出力する。機器無依存アプリ１３０の拡張機能部は、基本機能部１３２及び機器無依存ＡＰＩ２７を介して、情報を入出力する。基本機能部１３２は、機器無依存アプリ１３０と機器無依存ＡＰＩ２７を介して情報を入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器無依存ＡＰＩ２７とを介して情報を入出力する。
【００７０】
基本機能部１３２は、図３に示すミドルウェア１２０と同様に、そのまま又は所定の形式で運用情報を入力する。例えば、他の機器無依存アプリ１３０であれば、基本機能部１３２は、入力する形式の機器無依存ＡＰＩの形式にそれぞれに変換し、機器依存のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部であれば、入力する形式の機器無依存ＡＰＩの形式にそれぞれに変換してから、又は終端して所定の処理を施してから運用情報を入力する。入力の際に、基本機能部１３２は、それぞれの入力先に不要な入力情報を削除し、不足の情報があれば、他の機器無依存ＡＰＩや機器無依存ＡＰＩを介して収集して補足することが望ましい。しかし、基本機能部１３２は、入力先への入力を、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。
【００７１】
機器無依存アプリ１３０は、例えば、拡張機能部と、基本機能部１３２とを備える。機器無依存アプリ１３０は、拡張機能部と基本機能部１３２とのうち、いずれかを備えなくてもよい。機器無依存アプリ１３０は、拡張機能部と基本機能部１３２と以外の機能部を、更に備えてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリ１３０は、拡張機能部を備えなくてよい。
【００７２】
拡張機能部は、他の機能に影響を与えることなく独立に追加又は削除可能であることが好ましい。例えば、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を拡張機能部とする場合、拡張機能部が必要になった場合に、適宜追加し、不要となった場合に適宜削除し、変更に応じて入替又は変更してもよい。
機器無依存ＡＰＩ２２は、後から追加する拡張機能部を想定して、基本機能部１３２に予め備えることが望ましいが、必要に応じて、機器無依存ＡＰＩ２２、機器無依存ＡＰＩ２７、他の機器無依存アプリ１３０の改変を抑制する形で、追加又は削除してもよい。
【００７３】
（アーキテクチャの第４例）
図６は、通信装置のアーキテクチャの第４例を示す図である。アーキテクチャの第４例とアーキテクチャの第３例との違いは、通信装置が、基本機能部１３２の配下に、機器依存アプリ部１６０を備える点である。このように、アーキテクチャの第４例の通信装置は、機器依存アプリ部１６０を備えることで、基本機能部１３２の構成を簡易化できる効果がある。
【００７４】
図６に示す通信装置は、機器依存部１１０と、機器無依存アプリ１３０とを備える。機器依存部１１０は、準拠する標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等のソフトウェア部と、機器依存部１１０の少なくとも一部分を駆動する機器依存アプリ部１６０とを有する。機器無依存アプリ１３０は、移植用ＩＦとハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェアとの違いを隠蔽するドライバを介して又は移植用ＩＦと機器依存アプリ部１６０とを介して、機器に依存しない処理を実行する汎用の機器無依存アプリ１３０である。機器無依存アプリ１３０内の基本機能部１３２と、機器依存部１１０内の機器依存アプリ部１６０とは、機器無依存ＡＰＩ２７を介して接続される。機器依存アプリ部１６０と機器依存部１１０は、機器依存ＡＰＩ２４を介して接続される。
機器無依存アプリ１３０内の基本機能部１３２は、ミドルウェア１２０の代わりに、基本機能部１３２がハード、拡張機能部との入出力を行う。基本機能部１３２の中に、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３相当を含んでいてもよいし、拡張機能部として管理・制御エージェント部１３３を備えてもよい。
【００７５】
基本機能部１３２は、機器無依存アプリ１３０と機器無依存ＡＰＩ２２（拡張用ＩＦ）を介して入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器無依存ＡＰＩ２７（移植用ＩＦ）と機器依存部１１０の差異を隠蔽する機器依存部１１０のドライバ又は機器依存アプリ部１６０と機器依存ＡＰＩ２４を介して入出力する。
基本機能部１３２は、図３に示すミドルウェア１２０と同様に、そのまま又は所定の形式で入力する。アーキテクチャの第３例と同様に、基本機能部１３２の中に、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３相当を含んでいてもよいし、拡張機能部として管理・制御エージェント部１３３を備えてもよい。
【００７６】
機器無依存アプリ１３０は、例えば、拡張機能部と、基本機能部１３２とを備える。機器無依存アプリ１３０は、アーキテクチャの第３例と同様に、拡張機能部と基本機能部１３２とのいずれかを備えなくてもよい。機器無依存アプリ１３０は、アーキテクチャの第３例と同様に、拡張機能部と基本機能部１３２と以外の機能部を、更に備えてもよい。
拡張機能部は、アーキテクチャの第３例と同様に、互いに独立に他の機能に影響を与えずに、追加、削除、入替又は変更が可能であることが好ましい。基本機能部１３２の一部は、機器依存アプリ部１６０で代替してもよい。機器依存アプリ部１６０は、情報を基本機能部１３２から直接入出力しているが、そのまま又は所定の変換の後に、基本機能部１３２を介さずにＥＭＳ１４０との間で情報を入出力してもよい。
【００７７】
機器無依存ＡＰＩ２２は、図３に示すアーキテクチャの第１例と同様に、後から追加する拡張機能部を想定して、基本機能部１３２に予め備えることが望ましいが、機器無依存ＡＰＩ２２、機器無依存ＡＰＩ２７、他の機器無依存アプリ１３０、機器依存アプリ部１６０又は機器依存ＡＰＩ２４の改変を抑制する形で、必要に応じて追加又は削除してもよい。
【００７８】
（アーキテクチャの第５例）
図７の右上図は、アーキテクチャの第５例を示す図である。図７の右下図はアーキテクチャの第１〜第４例に相当する。本例では、通信装置は、既存／市中品ハードウェアと外付ハードウェアからなる。例えば既存／市中品ハードウェアは機器に依存する非汎用の機器依存部であり、外付ハードウェア上にハードウェアやソフトウェアの違いを隠蔽するミドルウェアと、動作が機器に依存しない汎用の機器無依存アプリとを備える。したがって、同図のミドルウェア以下の機器依存部（ベンダ依存部）は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存する機能部である。また、機器無依存アプリ１３０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存しない機能部である。
【００７９】
ミドルウェアと機器無依存アプリとは、機器に依存しない入出力ＩＦである機器無依存ＡＰＩを介して接続される。機器依存部の例えば、ソフトウェア部、ＯＡＭ、ハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）と、外付ハードウェア上のミドルウェアとは、機器に依存する入出力ＩＦである機器依存ＡＰＩ及び既存／市中品ハードウェアと外付ハードウェア間の機器間接続を介して接続される。
【００８０】
本アーキテクチャでは機器無依存アプリによる拡張機能部（独自機能部）の柔軟及び迅速な追加を容易にし、通信サービスをタイムリーに提供することができる。ここで、機器依存部は、図７に示す保守運用、アクセス制御、物理層処理、光モジュルであってもよく、機器自体の構成による。
【００８１】
例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ等の更新頻度が高い機能又は通信サービス差異化に寄与する機能を優先して、機器依存部又は機器無依存アプリとすることを決めてもよい。更に、共用化を図る機器の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して差異の隔たりが小さいものから、機器無依存アプリとしてもよい。
【００８２】
準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに対しては最適でない場合でも、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの機能のいずれかを汎用化するために、機能を実行するための共通ＩＦが用いられてもよい。共通ＩＦの中には、機器依存部の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダのいずれかにおいて使用されないＩＦやパラメータが含まれていてもよい。
【００８３】
ミドルウェアと、機器依存部のドライバと、機器依存アプリ部（ベンダ依存アプリ部）との少なくともいずれかに、ＩＦやパラメータ等を機器依存部に対応するように変換する変換機能部や、不足するＩＦやパラメータ等に対応して自動設定する機能部を更に備えてもよい。
機器依存部は、ハードウェア部と、ソフトウェア部とを備える。ソフトウェア部は、機器依存のドライバ、ファームウェア、アプリケーション等を実行する。
機器依存部は、物理媒体に接続するＰＭＤ、ＭＡＣ、データのシリアル化を行うＰＭＡ、データを符号化する部分であるＰＣＳ又はＰＨＹの一部を備えなくてもよい。例えば、変復調信号処理、前方誤り訂正（ＦＥＣ）、符復号処理、暗号化処理等の低位の信号処理を備えずに光関連の機能のみを備えてもよい。
【００８４】
機器無依存アプリは、例えば、ＥＭＳからデータを取得する管理・制御エージェント部と、拡張機能部と、基本機能部とである。以下、拡張機能部に共通する事項については、符号の一部を省略して、「拡張機能部」と表記する。ＥＭＳは、例えば、ネットワーク・エレメントを制御するコントローラである。なお、機器無依存アプリは、管理・制御エージェント部と拡張機能部と基本機能部とのうちいずれかを含まなくてもよい。
【００８５】
機器無依存アプリは、管理・制御エージェント部、拡張機能部及び基本機能部以外の構成を、更に含んでいてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリは、拡張機能部を備えなくてもよい。また、機器無依存アプリは、１個以上の拡張機能部を含んでもよい。
拡張機能部は、他の機能に不要な影響を与えずに独立して追加、削除、入替又は変更が可能であることが好ましい。例えば、拡張機能部は、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を実行する拡張機能部が必要になった場合、適宜に追加、削除、入替又は変更されてもよい。
【００８６】
基本機能部は、拡張機能部の一部として機器無依存アプリに含まれてもよいし、ミドルウェアよりも下位の機能部によって代替されてもよい。拡張機能部が基本機能部を含む場合、機器無依存アプリは基本機能部を含まなくてもよい。ミドルウェアよりも下位の機能部が基本機能部を代替する場合、機器無依存アプリは基本機能部を含まなくてもよい。拡張機能部が基本機能部を含み、ミドルウェアよりも下位の機能部が基本機能部を代替する場合、機器無依存アプリは基本機能部を含まなくてもよい。
【００８７】
管理・制御エージェント部は、ＥＭＳからの通信を受けずに、予め定められた設定に従って自動設定する場合、ＥＭＳと入出力しなくてよい。更に、管理・制御エージェント部が管理設定機能を備えず、他の機器無依存アプリや基本機能部や機器依存部が管理設定機能を備える場合、機器無依存アプリは、管理・制御エージェント部を備えなくてもよい。
【００８８】
ＥＭＳと機器無依存アプリとは、情報を直接入出力してもよい。また、機器依存部は、ＮＥ管理・制御部と、ＮＥ管理・制御部のＩＦとを備えなくともよい。
基本機能部は、拡張機能部の一部として機器無依存アプリに含まれてもよいし、ミドルウェアの下位の機能部によって代替されてもよい。拡張機能部が基本機能部を含む場合や、ミドルウェアの下位の機能部が基本機能部を代替する場合や、それらの組み合わせである場合、機器無依存アプリは基本機能部を含まなくてもよい。また、基本機能部の一部は、ミドルウェアの下位の機能部の機器依存アプリ部によって代替されてもよい。
【００８９】
管理・制御エージェント部は、予め定められた設定に従って自動設定する場合、ＥＭＳとの間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部が備えず他の機器無依存アプリや基本機能部や機器依存部が管理設定機能を備える場合、機器無依存アプリは、管理・制御エージェント部を備えなくてもよい。ＥＭＳと機器無依存アプリとは、情報を直接入出力してもよい。
【００９０】
機器無依存アプリと機器依存部との入出力の例は以下である。例えば、ＤＢＡアプリ部及びプロテクションアプリ部は、ＴＣレイヤのエンベデッドＯＡＭエンジンと、相互に情報を入出力する。ＤＷＢＡアプリ及びＯＮＵ登録認証アプリ部は、ＴＣレイヤのＰＬＯＡＭエンジンと、相互に情報を入出力する。省電力アプリ部は、ＯＭＣＩ及びＬ２主信号処理機能部（Ｌ２機能部）と相互に情報を入出力する。ＭＬＤプロキシアプリ部は、Ｌ２機能部と相互に情報を入出力する。低速監視アプリ（ＯＭＣＩ）は、ＯＭＣＩと相互に情報を入出力する。ＯＭＣＩ及びＬ２機能部は、ＸＧＥＭフレーマ及び暗号化を動作させる。ここで、ＤＷＢＡとＤＢＡは、別体、一体又は組み合わせでもよい。例えば、管理・制御エージェント部は、保守運用機能のアプリ部であり、ＮＥ管理・制御部のためのＮＥコントローラ等であるＥＭＳと、相互に情報を入出力する。
【００９１】
機器無依存アプリは、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＴＵ−Ｔ  Ｇ．９８９シリーズに準拠するＴＷＤＭ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８７シリーズに準拠するＸＧ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８４シリーズに準拠するＧ−ＰＯＮと、ＩＴＵ−Ｔ  Ｇ．９８３シリーズに準拠するＢＰＯＮとのいずれにもよらずに動作するアプリである。機器無依存アプリは、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＥＥＥ８０２．３ａｖやＩＥＥＥ１９０４．１等に準拠する１０ＧＥ−ＰＯＮとＩＥＥＥ８０２．３ａｈに準拠するＧＥ−ＰＯＮ等の差異の少なくともいずれかに依らずに動作するアプリである。
【００９２】
拡張機能部のアプリとして、機器無依存ＡＰＩを介して、一部のベンダ、方式、種別、世代に備える機能を駆動するためのアプリや、一部のベンダ、方式、種別、世代の装置のみに備える機能を駆動するアプリを含んでいてもよい。
管理・制御エージェント部は、ＥＭＳ及びミドルウェアと入出力する。ミドルウェアは、ＮＥ管理・制御部との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部は、ミドルウェアを介さずに、ＮＥ管理情報及び制御情報をＥＭＳと直接送受信してもよいし、管理・制御エージェント部を介して、ＮＥ管理情報及び制御情報を送受信してもよい。
【００９３】
ミドルウェアは、機器無依存アプリと機器無依存ＡＰＩを介して情報を入出力する。ミドルウェアは、機器依存ＡＰＩを介して、機器依存部のＯＡＭ部、ドライバ、ファームウェア、ハードウェア部又はハードウェア部と情報を入出力する。ミドルウェアは、入力した情報を、そのまま又は所定の形式で出力する。例えば、ミドルウェアは、出力先が機器無依存アプリの各部であれば、機器無依存ＡＰＩの各部の入力形式に情報を変換する。出力先が機器依存部のＯＡＭ部、ドライバ、ファームウェア、ハードウェア部又はハードウェア部であれば、ミドルウェアは、それぞれに入力する形式の機器依存ＡＰＩの形式に変換してから、又は終端して所定の処理を施してから情報を出力先に送信する。
【００９４】
ミドルウェアは、入力の際に、それぞれの入力先に不要な入力情報は削除し、不足の情報があれば、他の機器無依存ＡＰＩや機器依存ＡＰＩを介して収集して補足することが望ましい。また、ミドルウェアへの入力の際に、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。
ミドルウェアや機器依存部は単一で例示したが、それぞれ複数から構成されていてもよい。機器依存部のハードウェアに複数のプロセッサが含まれる場合、ミドルウェアはプロセッサやハードウェアをまたいでプロセッサ間通信等を用いて入出力してもよい。機器無依存アプリ間や機器無依存アプリをＤＬＬのような実行プログラムとして、単一のプロセッサ上のユーザ空間上に配置してもよいし、複数のプロセッサ上のユーザ空間上に配置してもよい。
【００９５】
また、機器無依存アプリは、ＡＰＩ等の入出力ＩＦを確保した上でカーネル空間に配置してもよいし、独立にファームウェア等に入替可能なＩＦを有するミドルウェアとともに配置してもよいし、ファームウェア等に組み込んでコンパイルし直してもよい。機器無依存アプリ毎にユーザ空間やカーネル空間を任意の組み合わせとしてもよい。
同一の機能に対応する機器無依存アプリを、ユーザ空間とカーネル空間の両方で実装可能としてもよい。この場合、例えば、切り替えていずれかを選択してもよいし、両方協働して処理してもよいし、一方のみで実処理を行うとしてもよい。機器依存部のソフトウェアも同様である。
【００９６】
望ましくは、主信号処理やＤＢＡ処理や低レイヤの信号処理のように高速処理が必要であるほど、拡張性・入替の即時性とトレードオフはあるが、オーバーヘッドが少なく高速な処理が期待されるカーネル空間やファームウェアに組み込むことが望ましい。機器依存アプリ部を配置するプロセッサもプロセッサ間通信によるバスや速度等の制限、通信路の占有等による他のプログラムへの影響の観点から、実処理を行うプロセッサ又はその近傍のプロセッサのユーザ空間やカーネル空間やファームウェア上に配置することが望ましい。ただし、実処理を行うプロセッサ又はその近傍のプロセッサの能力を軽減するためにはプロセッサ間通信によるコミュニケーションコストは増大するが、遠隔のプロセッサで処理するとしてもよい。
【００９７】
機器無依存ＡＰＩは、追加する拡張機能部を想定してミドルウェアに予め備えられることが望ましいが、機器依存ＡＰＩや他の機器無依存アプリの改変を抑制する形で、必要に応じて追加又は削除されてもよい。
【００９８】
（アーキテクチャの第６例）
アーキテクチャの第６例は、機器依存部として準拠する標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）と、ハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）を駆動するドライバ・ファームウェア等のソフトウェア部と、機器依存部の少なくとも一部分を駆動する機器依存アプリ部とを備える。
【００９９】
機器依存アプリ部及び機器依存部は、機器依存ＡＰＩを介して接続される。機器依存アプリ部の中に、ＥＭＳからの通信を受ける管理・制御エージェント部相当を含んでいてもよい。機器依存ＡＰＩは、機器依存アプリ部及び機器依存ＡＰＩの改変を抑制する形で、必要に応じて追加又は削除されてもよい。
【０１００】
なお、通信装置のアーキテクチャの第１例〜第６例に示す通信装置の構成は、ＴＷＤＭ−ＰＯＮのようなＩＴＵ−Ｔ勧告準拠のＰＯＮのＯＬＴを前提に記載しているが、ＯＮＵであってもよく、ＴＷＤＭ−ＰＯＮ以外のＩＴＵ−Ｔ勧告準拠のＰＯＮのＯＬＴ又はＯＮＵのいずれかであってもよいし、ＧＥ−ＰＯＮ、１０ＧＥ−ＰＯＮ等のＩＥＥＥ規格準拠のＰＯＮであってもよく、ＴＣレイヤ又はＰＭＤレイヤは対応する層に読み替えれば同様である。
【０１０１】
以下、ＴＷＤＭ−ＰＯＮが、ＰＯＮマルチキャスト機能と、省電力制御機能と、周波数・時刻同期機能と、プロテクション機能と、保守運用機能と、Ｌ２主信号処理機能と、ＰＯＮアクセス制御機能と、ＰＯＮ主信号処理機能とを主に有する場合を例に説明する。以下、ＰＯＮマルチキャスト機能と、省電力制御機能と、周波数・時刻同期機能と、プロテクション機能と、保守運用機能と、Ｌ２主信号処理機能と、ＰＯＮアクセス制御機能と、ＰＯＮ主信号処理機能とを、「主要８機能」という。
【０１０２】
図８は、通信装置及び外部サーバ１６の構成の例を示す図である。通信システムは、通信装置と、外部サーバ１６とを備える。通信装置は、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、プロキシ部１５との少なくとも一部を備える。なお、通信装置は、外部サーバ１６を備え得る。
図８では、異なる波長（λＡ〜λＮ）の光信号を送受信（通信）する送受信部１１が同一のスイッチ部１２に接続されている構成を示すが、実施形態１−１はこれに限定されない。例えば、異なる波長（λＡ〜λＮ）の光信号を送受信する送受信部１１が同一のスイッチ部１２に接続されている構成に加えて、同一の波長の光信号を送受信する送受信部１１が同一のスイッチ部１２に接続されていてもよいし、異なる波長（λＡ〜λＮ）の光信号を送受信する送受信部１１の内で少なくとも一部の波長の送受信部１１が複数同一のスイッチ部１２に接続されていてもよいし、送受信部１１の内の一部又は全てが送信のみ又は受信のみ行う送受信部１１であってもよい。
【０１０３】
ＯＬＴなどの通信装置は、送受信部１１から制御部１４を備えていてもよいし、これらに加えて外部サーバ１６を更に、備えてもよい。また、ＯＳＵは、送受信部１１でもよいし、これに加えてスイッチ部１２（ＳＷ）又はスイッチ部１３（ＳＷ）を備えてもよい。
通信システム構成（１−１）の通信システムは、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、プロキシ部１５と、外部サーバ１６とを備える（図８）。
【０１０４】
通信装置がＯＬＴである場合、ＯＬＴは、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、外部サーバ１６とから構成してもよい。ＯＳＵは、送受信部１１（ＴＲｘ）とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１３（ＳＷ）とから構成してもよい。
異なる波長（λＡ〜λＮ）の光信号を送受信する送受信部１１（ＴＲｘ）がスイッチ部１２に接続されている。送受信部１１（ＴＲｘ）は、自律制御を行い、又は、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。送受信部１１（ＴＲｘ）は、ＯＤＮ（Ｏｐｔｉｃａｌ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｎｅｔｗｏｒｋ）若しくはスイッチ部１２（ＳＷ）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ（Ｖｉｒｔｕａｌ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、又は、タグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一つ又はその組み合わせの処理を行う。
【０１０５】
なお、上りトラフィックに関しても集約されるとは限らない。スイッチ部１２（ＳＷ）は通信システム構成（１−１）の構成では波長毎の振分が主であるが、集約、分配、複製、折返、透過、ＶＩＤ（Ｖｉｒｔｕａｌ  ＬＡＮ  Ｉｄｅｎｔｉｆｉｅｒ）や優先廃棄を表すタグ等のタグ付加又はタグ付替を行ってもよい。後述する通信システム構成（１−２）の構成では、上りトラフィックは集約が主であるが、分配、振分、複製、折返、透過、タグ付加又はタグ付替を行ってもよい。下りトラフィックも集約、分配、振分、複製、折返、透過、タグ付加又はタグ付替のいずれかを行ってもよく、少なくとも一部の組み合わせを行ってもよい。そのいずれとするかはサービスポリシーに応じて決定する。これは以降の通信システム構成でも同様である。
【０１０６】
スイッチ部１２（ＳＷ）は、スイッチ部１３（ＳＷ）に接続される。スイッチ部１２（ＳＷ）は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。スイッチ部１２（ＳＷ）は、送受信部１１（ＴＲｘ）若しくはスイッチ部１３（ＳＷ）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、又は、タグの変更無で、集約、分配、振分、複製、折返、透過若しくはタグ付加又はタグ付替の少なくとも一部又はその組み合わせの処理を行う。これは以降の通信システム構成でも同様である。
【０１０７】
なお、スイッチ部１２（ＳＷ）は、制御されるとは限らない。送受信部１１からプロキシ部１５の少なくとも一つが制御される場合と、制御されずに送受信部１１からプロキシ部１５の少なくとも一つに制御情報が転送される場合とがある。転送元としては例えばプロキシ部１５又は外部サーバ１６がある。また、送受信部１１からプロキシ部１５が自律で動く場合もある。これは以降の通信システム構成でも同様である。
【０１０８】
スイッチ部１３（ＳＷ）は、プロキシ部１５に直接、又は集線ＳＷ等を介して接続される。この集線ＳＷは、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約、分配、振分、複製、折返若しくは透過の少なくとも一部を行う。スイッチ部１３（ＳＷ）は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。スイッチ部１３（ＳＷ）は、スイッチ部１２（ＳＷ）若しくはプロキシ部１５のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、若しくは、タグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一部又はその組み合わせの処理を行う。
【０１０９】
制御部１４は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５又は外部サーバ１６又は外部のオペレーションシステム（不図示）、コントローラ（不図示）若しくは外部の装置（不図示）と接続される。制御部１４は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を制御し、又は送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して、指示を転送する。
【０１１０】
図８に示すプロキシ部１５は、ＯＬＴから若しくはＯＬＴへのデータ経路上に設置してもよい。ただし、間に他の装置（例えば、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約／分配する集線ＳＷ等）が介在する場合があるので、直接接続されるとは限らない。制御の流れとしては、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、外部サーバ１６のいずれに、プロキシ部１５があってもよい。
【０１１１】
プロキシ部１５は、上位側の装置（不図示）に直接、又は集線ＳＷ等を介して接続される。この集線ＳＷは、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約、分配、振分、複製、折返若しくは透過の少なくとも一部を行う。プロキシ部１５は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。プロキシ部１５は、スイッチ部１３（ＳＷ）若しくは上位側の装置（不図示）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、若しくはタグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一部又はその組み合わせの処理を行う。
【０１１２】
外部サーバ１６は、送受信部１１（ＴＲｘ）又はスイッチ部１２（ＳＷ）又はスイッチ部１３（ＳＷ）又は制御部１４又はプロキシ部１５又は外部のオペレーションシステム（不図示）又はコントローラ（不図示）若しくは外部の装置（不図示）と接続される。外部サーバ１６は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）若しくは制御部１４若しくはプロキシ部１５等の他の構成要素を制御し、又は送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）若しくは制御部１４若しくはプロキシ部１５等の他の構成要素を介して指示を転送する。
【０１１３】
送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素のトラフィックの一部又はその全てそれ自体又はその複写を受けて、受けたトラフィックの一部、その全て自体、受けたトラフィックの一部、全てを書き換えたトラフィック又は受けたトラフィックに対する応答を、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素、外部のオペレーションシステム（不図示）、コントローラ（不図示）又は外部の装置（不図示）に送信してもよい。
【０１１４】
なお、要素は適宜含まなくてもよいし、含まない要素とのやりとりは例えば、スキップしてその先の要素とやりとりする。同士をハブ遺体相手同士で通信してもよい。
通信システム構成（１−２）の通信システムでは、通信システム構成（１−１）の構成に対して更に、異なる波長の代わりに同一の波長の光信号を送受信する送受信部１１（ＴＲｘ）（λＡ〜λＡ）、送受信部１１（ＴＲｘ）（λＢ〜λＢ）、…、送受信部１１（ＴＲｘ）（λＮ〜λＮ）が、スイッチ部１２にそれぞれ接続されている。更に、異なる波長の送受信部１１の内の少なくとも一部の波長の送受信部１１がスイッチ部１２に複数接続されていてもよい。他は同様である。
【０１１５】
図９に係る光アクセスシステムでは、ＩＴＵ−Ｔ  Ｇ．９８９シリーズに準拠する。図９において、コントローラと外部装置はＯＬＴに含まれないが、ＦＡＳＡアプリケーションＡＰＩとの通信を例示するために記載する。論理モデルは、ＦＡＳＡアプリケーションと、ＦＡＳＡアプリケーションにＦＡＳＡアプリケーションＡＰＩを提供するＦＡＳＡ基盤とから構成される。ＦＡＳＡ基盤はＦＡＳＡアプリケーション用ミドルウェアを含む。ＦＡＳＡアプリケーションＡＰＩ用ミドルウェアは、ＦＡＳＡ基盤を構成するハードウェアやソフトウェアのベンダや方式の違いを吸収する。ＦＡＳＡアプリケーションＡＰＩ用ミドルウェア上にベンダや方式に依存しないＦＡＳＡアプリケーションＡＰＩセットを規定し、ＦＡＳＡアプリケーションの入替により、サービス毎あるいは通信事業者毎に必要な機能を実現する。ＦＡＳＡアプリケーション間の通信やコントローラ等による設定管理はＦＡＳＡアプリケーションＡＰＩ用ミドルウェアを介して行う。なお、ＦＡＳＡアプリケーションＡＰＩ用ミドルウェアを介さないこともありうる。ＦＡＳＡアプリケーションＡＰＩセットは、ＦＡＳＡアプリケーションで利用する共通のＡＰＩ群であり、ＦＡＳＡアプリケーション毎に必要なＡＰＩをＡＰＩセットから選択して利用する。
【０１１６】
以下に示す接続関係は例であり、間に介在する接続は介在しない接続であってもよいし、複数の接続関係の一部のみ接続していてもよく、それ以外の接続であってもよい。これは他の説明も同様である。これは他の説明も同様である。ＮＥコントローラとして機能するＥＭＳは、ＮＥ−ＯｐＳ等のＯＬＴの設定管理システムであり、ミドルウェアを介して、ＩＦ変換アプリを介して設定管理アプリケーション(例えば、低速監視アプリ（ＥＭＳ−ＩＦ）及び設定・管理アプリ)が配置されている。ＩＦ変換アプリは、ＮＥコントローラ等のＥＭＳからＯＬＴ等のNetwork Entityに対する制御ＩＦであるＳＢＩ（South Band Interface）のコマンドを変換するＳＢＩアプリに相当する。ここでＩＦ変換アプリがＩＦ変換するとしているが低速監視アプリ（ＥＭＳ−ＩＦ）及び設定・管理アプリにて、ＩＦ変換を行う又はＩＦ変換を行う必要のないＡＰＩを備えれば、ＩＦ変換アプリは備えなくともよい。Ｌ２（レイヤ２）機能と接続された低速監視アプリ（ＥＭＳ−ＩＦ）と設定・管理アプリはミドルウェアを介して、ＥＭＳやＮＥ管理等を行うＮＥ制御・管理と接続されている。低速監視アプリ（ＯＭＣＩ）、ＭＬＤプロキシアプリ（マルチキャストアプリ）及び省電力アプリは、ミドルウェアを介してそれぞれＬ２機能と接続されている。
【０１１７】
プロテクションアプリは、ミドルウェアを介してPLOAM EngineとEmbedded OAM Engineと接続されている。省電力アプリは、ミドルウェアを介してＯＭＣＩとPLOAM Engineと接続されている。ＯＮＵ登録認証アプリ及びＤＷＢＡアプリはミドルウェアを介してPLOAM Engineと接続され、ＤＢＡアプリはミドルウェアを介してEmbedded OAM Engineと接続されている。省電力アプリは、ミドルウェアを介してプロテクションアプリとＯＮＵ登録認証アプリとＤＷＢＡアプリとＤＢＡアプリ間でそれぞれ動作させてもよい。外部の装置からの入力はミドルウェアを介してＤＢＡアプリに接続している。なおこれらの接続は、例であり、外部の装置からの入力をＤＢＡアプリ以外の他のアプリ例えばプロテクションアプリやＤＷＢＡアプリに接続してもよい。また外部の装置からの入力をミドルウェア経由でＩＦ変換アプリを介してＩＦ変換したり、ミドルウェア経由で設定・管理アプリを介してＤＢＡアプリ等に接続したりしてもよい。
【０１１８】
図１０は、通信装置内の機能部間の信号／情報の流れを示す図である。同図に示す通信装置は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）と、Ｌ２主信号処理機能部３４０と、ＰＯＮマルチキャスト機能部３５０と、省電力制御機能部３６０と、周波数・時刻同期機能部３７０と、プロテクション機能部３８０とを備える。
【０１１９】
ＰＯＮ主信号処理機能部３００は、ＰＯＮ主信号処理機能を有する。ＰＯＮ主信号処理機能は、ＯＮＵとの間で送受信を行う主信号を処理する機能群であり、ＰＯＮフレームの生成分離や前方誤り訂正（ＦＥＣ：Forward Error Correction）等を含む。ＰＯＮアクセス制御機能部３２０は、ＰＯＮアクセス制御機能を有する。ＰＯＮアクセス制御機能は、前述の主信号送受信を行うための制御機能群であり、動的帯域割当やＯＮＵの登録認証等を含む。
【０１２０】
保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）は、保守運用機能を有する。保守運用機能は、アクセス装置によってサービスを円滑に保守運用するための機能群であり、ＯＮＵやＯＬＴ（ＯＳＵ及びスイッチ）の装置設定を実施する機能や、ソフトウェアの更新、装置やサービスの管理、各種機能が正常に動作しているかを監視する機能、異常発生時に能動的に警報を発出する機能、異常発生時の範囲や原因を調査するための試験機能等を含む。また、保守運用機能は、多数のアクセス装置を管理する保守運用システムと接続され、リモートからも円滑な保守運用を実現する。
【０１２１】
Ｌ２主信号処理機能部３４０は、Ｌ２主信号処理機能を有する。Ｌ２主信号処理機能は、ＰＯＮ側ポートとＳＮＩ側ポートとの間で主信号を転送し、処理する機能群であり、ＭＡＣアドレス学習やＶＬＡＮ制御、優先制御やトラフィックモニタ等の機能を含む。ＰＯＮマルチキャスト機能部３５０は、ＰＯＮマルチキャスト機能を有する。ＰＯＮマルチキャスト機能は、ＳＮＩ側から受信したマルチキャストストリームを適切なユーザに転送する機能群であり、マルチキャストストリームの識別や振分し、ＯＮＵのフィルタ設定を実施する機能を含む。
【０１２２】
省電力制御機能部３６０は、省電力制御機能を有する。省電力制御機能は、ＯＮＵやＯＬＴの電力消費を削減するための機能群であり、標準化で規定されている省電力化機能に加え、トラフィックモニタとの連携によってサービスへの影響を最小限に抑えながら、最大限の効果を得るための機能を含む。周波数・時刻同期機能部３７０は、周波数・時刻同期機能を有する。周波数/時刻同期機能は、ＯＮＵ配下の装置に正確な周波数同期や時刻同期を提供するための機能群であり、自身のリアルタイムクロックを上位装置に従属同期させる機能や、ＰＯＮフレームを用いてＯＮＵに時刻情報を通知する機能を含む。
【０１２３】
プロテクション機能部３８０は、プロテクション機能を有する。プロテクション機能は、スイッチ間やＯＳＵ間等、複数のハードウェアで冗長をとった構成において、障害検知時に現用系から予備系への切替や引継を実施してサービスを継続するための機能群であり、切替トリガの検出や切替処理の実施といった機能を含む。また、プロテクション機能は障害検知時や手動での切替時に、サービスを全面停止せず縮退運転で動作させ続けるための機能を提供する。ＰＭＤ部３１０は、主要８機能以外の機能を有する。
【０１２４】
ＰＯＮ主信号処理機能部３００は、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）と、Ｌ２主信号処理機能部３４０とに接続されていてもよい。ＰＯＮマルチキャスト機能部３５０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。省電力制御機能部３６０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。周波数・時刻同期機能部３７０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。プロテクション機能部３８０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。
【０１２５】
図１１は、ＰＯＮ主信号処理機能部３００が有する機能構成の例を示す図である。ＰＯＮ主信号処理機能部３００は、上り信号の処理順（下り信号の処理は逆方向）に、ＰＨＹアダプテーションと、フレーム化と、サービスアダプテーションとを、ＰＯＮ主信号処理機能を構成する処理として備えていてもよい。これらの処理は、基本処理から構成されてもよい。基本処理は、同期ブロック生成／抽出と、スクランブル／デスクランブルと、ＦＥＣデコード／エンコードと、フレーム生成／分離と、ＧＥＭ（Ｇ−ＰＯＮ  Ｅｎｃａｐｓｕｌａｔｉｏｎ  Ｍｅｔｈｏｄ）カプセル化と、フラグメント処理と、暗号化とである。
【０１２６】
ＰＨＹアダプテーションは、同期ブロック抽出と、デスクランブルと、ＦＥＣデコーディングとを、上り信号の処理順に備えていてもよい。ＰＨＹアダプテーションは、ＦＥＣエンコーディングと、スクランブルと、同期ブロック生成とを、下り信号処理の順番で備えていてもよい。
ＰＯＮ主信号処理機能部３００は、ＰＨＹアダプテーション、フレーム化又はサービスアダプテーションの処理を備えずに、同等の処理を基本処理の組み合わせで実現してもよい。ＰＨＹアダプテーション、フレーム化又はサービスアダプテーションの処理は、順番が入れ替わっていてもよい。ＰＨＹアダプテーションは、例えば、ＦＥＣ処理をＰＨＹアダプテーション以外に備えてもよい。
【０１２７】
ＰＯＮ主信号処理機能部３００の主要機能では、１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長毎に処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が複数波長を処理するなら、複数波長分が求められる。
【０１２８】
図１２は、ＰＯＮアクセス制御機能部３２０が有する機能構成の例を示す図である。ＰＯＮアクセス制御機能部３２０が有するＰＯＮアクセス制御機能を構成する処理として、ＯＮＵ登録又は認証、ＤＢＡ、及び、λ設定切替（ＤＷＡ）を有する。これらの処理は、基本処理から構成されてもよい。例えば、ＯＮＵ登録又は認証は、初期処理を構成するレンジング、認証削除、登録、起動停止、ＤＢＡは帯域要求受信、トラフィック測定、履歴保持、割当計算、割当処理、設定切替計算、設定切替処理、設定切替状況把握の全て又はそのいくつか、λ設定切替は、帯域要求受信、トラフィック測定、履歴保持、割当計算、割当処理、設定切替計算、設定切替処理、設定切替状況把握の全て又はそのいくつかから構成されてもよい。ＯＮＵ登録又は認証、ＤＢＡ、λ設定切替（ＤＷＡ）は備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１２９】
ＰＯＮアクセス制御機能部３２０の主要機能では、ＯＮＵ高速起動、ＤＢＡ周期内でのＢＷＭａｐ、無瞬断λ設定切替等が必要に応じて求められる。機能分担の例として、登録又は認証としては、タイムクリティカルなレンジング処理を機器依存部、その後の認証や鍵交換をアプリとしてもよい。ＤＢＡ・λ設定切替では、単純な繰り返し処理を機器依存部、理想状態への反映をアプリとしてもよい。
図１３は、Ｌ２主信号処理機能部３４０が有する機能構成の例を示す図である。Ｌ２主信号処理機能部３４０が有するＬ２主信号処理機能を構成する処理として、ＭＡＣ学習、ＶＬＡＮ制御、パス制御、帯域制御、優先制御、遅延制御、Ｃｏｐｙを有する。これらの処理は基本処理であるアドレス管理、Ｃｌａｓｓｉｆｉｅｒ（クラシファイア、分類部）、Ｍｏｄｉｆｉｅｒ（モディファイア、変更部）、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ（ポリサー／シェイパ）、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ（クロス・コネクト）、Ｑｕｅｕｅ（キュー）、Ｓｃｈｅｄｕｌｅｒ（スケジューラ）、Ｃｏｐｙ（コピー）、トラフィックモニタから構成されてもよい。ＭＡＣ学習、ＶＬＡＮ制御、パス制御、帯域制御、優先制御、遅延制御、Ｃｏｐｙは備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１３０】
Ｌ２主信号処理機能部３４０の主要機能では、１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長ごとに処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が、複数波長を処理するなら複数波長分が求められる。
【０１３１】
図１４は、保守運用機能部３３０が有する機能構成の第１例を示す図である。保守運用機能部３３０が有する保守運用機能を構成する処理として、ＯＮＵ、ＯＳＵ、ＯＬＴ又はＳＷの装置設定（手動、一括、自動、オペレーション契機）、設定バックアップ、ＦＷ更新、装置制御（リセット）、冗長構成対応を有する。これらの処理は、基本処理であるＣＬＩ−ＩＦ、装置管理ＩＦ、オペレーションＩＦ、汎用Ｃｏｎｆｉｇ（コンフィグ）−ＩＦ（ＮＥＴＣＯＮＦ、ＳＮＭＰなど）、テーブル管理から構成されてもよい。装置設定、設定バックアップ、ＦＷ更新、装置制御、冗長構成対応は備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１３２】
保守運用機能部３３０の主要機能では、指示を受けてからＡＣＫ送信まで１００ミリ秒以内、指示を受けてから反映完了通知送信まで２００ミリ秒以内（ただし、データ転送を含む設定バックアップとＦＷ更新は規模（サイズ・ユーザ数）に応じて規定。）等の規定に従うことが求められる。機能分担の例としては、ハードのＣｏｎｆｉｇを除きアプリとし、ソフトや設定データはＯＮＵやＯＬＴで持たずに図８の外部サーバ１６上のアプリとすることもできる。コマンドの統一とシーケンスの定義をすることで実現することもできる。
【０１３３】
図１５は、保守運用機能部３３０が有する機能の構成の第２例を示す図である。保守運用機能部３３０が有する機能を構成する処理として、装置の状態監視（ＣＰＵ／メモリ／電源／切替）、トラフィック監視、警報監視（ＯＮＵ異常、ＯＬＴ異常）、試験（ループバック）を有する。これらの処理は基本処理である警報通知、ログ記録、Ｌ３パケット生成／処理、テーブル管理から構成されてもよい。装置の状態監視、トラフィック監視、警報監視、試験は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１３４】
保守運用機能部３３０の主要機能では、レイテンシが１００ミリ秒以内等の規定に従うことが求められる。機能分担の例として、通知／表示のＩＦのみアプリとし、モニタが必要な項目（ＣＰＵ負荷、メモリ利用量、電源状態、消費電力、イーサネット（登録商標）のリンク状態など）は機器依存部であり、機器依存部からの通知読み出し、通知のネットワーク（ＮＷ）送信、ファイルへの書き込みなどのＩＦをきるアプリによる処理とすることもできる。
【０１３５】
図１６は、保守運用機能部３３０が有する機能構成の第３例を示す図である。保守運用機能部３３０が有する保守運用機能を構成する処理として、高速を要する監視・制御の入出力（スリープ指示／返答、λ設定切替指示／返答など）を有する。本処理の手段として、物理層ＯＡＭ（ＰＬＯＡＭ：Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  ＯＡＭ）メッセージ、及び、ヘッダ内のビット表示（Ｅｍｂｅｄｄｅｄ  ＯＡＭ）を利用する。これらの処理は基本処理であるＰＬＯＡＭ処理、Ｅｍｂｅｄｄｅｄ  ＯＡＭ処理、省電力制御機能部３６０との通信、プロテクション機能部３８０との通信、ＰＯＮアクセス制御機能部３２０との通信から構成されてもよい。高速を要する監視・制御の入出力は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。保守運用機能部３３０の主要機能では、ＰＬＯＡＭ処理を７５０マイクロ秒以内とする等の規定に従うことが求められる。
【０１３６】
図１７は、ＰＯＮマルチキャスト機能部３５０が有する機能構成の例を示す図である。ＰＯＮマルチキャスト機能部３５０が有するＰＯＮマルチキャスト機能を構成する処理として、マルチキャストストリームの識別又は振り分け、ＭＬＤプロキシ／スヌーピング、ＯＮＵフィルタ設定、波長間設定移行を有する。これらの処理は基本処理であるＬ２識別・振り分け、Ｌ３パケット処理（ＩＰｖ６  Ｐａｒｓｅを備えるのが望ましい）、Ｌ３パケット生成、テーブル管理、ＯＭＣＩ機能との通信から構成されてもよい。マルチキャストストリームの識別又は振り分け、ＭＬＤプロキシ／スヌーピング、ＯＮＵフィルタ設定、波長間設定移行は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１３７】
ＰＯＮマルチキャスト機能部３５０の主要機能では、識別／振り分けを１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長毎に処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が、複数波長を処理するなら複数波長分が求められる。更に、ＰＯＮマルチキャスト機能部３５０の主要機能では、パケット処理としてザッピング性能（Ｚａｐｐｉｎｇ性能）（ＪＯＩＮレイテンシ）が、平均１．５秒以内等の規定に従うことが求められる。
機能分担の例としては、マルチキャスト（ＭＣ）ストリームの識別・振分は高速な処理能力を持つＣＰＵ等であればソフト処理可だが、ハード＋ｃｏｎｆｉｇが望ましい。その他、上りに対するアプリ系やＯＮＵ設定は頻度や遅延制約が緩いためアプリによる処理とするである。
【０１３８】
図１８は、省電力制御機能部３６０が有する機能構成の例を示す図である。省電力制御機能部３６０が有する機能を構成する処理として、スリープ用プロキシ／トラフィックモニタ、ＯＮＵ波長設定、波長間設定移行を有する。これらの処理は基本処理であるＬ３パケット処理（ＩＰｖ６  Ｐａｒｓｅを備えるのが望ましい）、Ｌ３パケット生成、テーブル管理、ＯＳＵ省電力ステートダイアグラム（ＳＤ：Ｓｔａｔｅ  Ｄｉａｇｒａｍ）、ＯＭＣＩ機能との通信から構成されてもよい。スリープ用プロキシ／トラフィックモニタ、ＯＮＵ波長設定、波長間設定移行は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
本主要機能では、送受信立ち上がり時間（受信器／送信器）を１０ミリ秒／５ミリ秒、立ち上がり時間（ＬＣ／ＯＳＵ／ＯＬＴ）を１００ミリ秒／１秒／１０秒等の規定に従うことが求められる。
【０１３９】
機能分担の例として、パワーセーブ（ＰＳ：Ｐｏｗｅｒ  Ｓａｖｅ）アプリや、信号によってはプロキシ処理もアプリによる処理とすることもできる。省電力制御状態遷移管理（ドライバ部）は速度が求められるがアプリによる処理とすることもできる。トラフィックモニタはコンフィグ（ｃｏｎｆｉｇ）のみアプリによる処理とすることもできる。
【０１４０】
図１９は、周波数・時刻同期機能部３７０が有する機能構成の例を示す図である。ＯＬＴは、ＳｙｎｃＥ（Ｓｙｎｃｈｒｏｎｏｕｓ  Ｅｔｈｅｒｎｅｔ（登録商標））（周波数同期用）及びＩＥＥＥ  １５８８ｖ２（時刻同期）により、自身のリアルタイムクロック（ＲＴＣ）を上位装置に従属同期させる。更に、ＯＭＣＩを利用して、ＰＯＮのスーパーフレームカウンタ（ＳＦＣ）と絶対時刻（ＴｏＤ：Ｔｉｍｅ  ｏｆ  Ｄａｙ）情報の対応をＯＮＵに通知する。これらの処理は基本処理であるリアルタイムクロックの保持等から構成されてもよい。同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１４１】
本主要機能では、周波数同期精度＋／−５０ｐｐｂ（ＬＴＥ  ＦＤＤ、同ＴＤＤ）、時刻同期精度＋／−１〜１．５マイクロ秒（ＬＴＥ  ＴＤＤ、スモールセル）、＋／−１マイクロ秒（Ｇ．９８７．３）等の規定に従うことが求められる。機能分担の例としては、リアルタイムクロック自体は機器依存部であり、上位装置への時刻合わせ計算はアプリによる処理とすることもできる（精度により機器依存部とすることもできる）。
【０１４２】
図２０は、プロテクション機能部３８０が有するプロテクション機能を構成する処理として、冗長切替（ＣＴ、ＳＷ、ＮＮＩ、ＣＯＮＴ、ＰＯＮ（Ｔｙｐｅ  Ａ、Ｂ、Ｃ））を備える。これらの処理は基本処理である冗長パス設定、 切替トリガ検出、切替通知送受信、切替処理等から構成されてもよい。同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
【０１４３】
本主要機能では、強制切替は５０ミリ秒以下等の規定に従うことが求められる。機能分担の例としては、故障検出等のハードの切替トリガ検出と切替処理を除きアプリによる処理とすることもできる。冗長パスを予め設定せずに、切替トリガ検出時にＥＭＳ側へ（から）指示する場合は機器依存、等である。
【０１４４】
なお、主要８機能は必要に応じて備えればよく、例えばＰＯＮ主信号処理機能、ＰＯＮアクセス制御機能、Ｌ２主信号処理機能、保守運用機能のみを備えてもよいし、それ以外の機能を備えてもよい。また、各機能のソフト化可否の評価は、２０１８年に想定されるＯＬＴの処理能力かつ、ソフトスイッチの適用は想定していない前提での一例である。想定する処理能力やソフトスイッチの適用を想定して適宜変更してもよい。ソフト化可の機能であっても、ソフト化しなくてもよい。各機能の内部の構成は同様の機能を実現できれば他の構成であってもよい。
【０１４５】
主要８機能に含まれるアルゴリズムを主なソフト化領域とする。ソフト化領域とした機能を機器無依存ＡＰＩ２１上の機器無依存アプリ１３０とする。例えば、差異化サービスに資するＯＮＵ登録又は認証機能、ＤＷＢＡ機能、設定・管理・監視制御機能及び省電力制御機能におけるアルゴリズムは機器無依存アプリ１３０における拡張機能部として扱われる。ＭＬＤプロキシアプリはマルチキャスト機能を含む。
拡張機能部は、アプリの内、機能の更新頻度や独自仕様等の実現等の重要度に応じて拡張機能部とする。更新頻度が低いか独自仕様等の実現の要求の低いものは基本機能部１３２や機器無依存アプリ１３０以外のミドルウェアや機器依存ソフトウェアやハードウェア部及びハードウェア部とすることが好ましい。特に、ソフトウェアの処理能力からくる制限がある機能は、ハードウェア部及びハードウェア部のままとすることが好ましい。例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ等の更改頻度が高いかサービス差異化に寄与する機能や、オペレータの業務フローに密接にかかわり合いオペレータ毎の独自仕様が要求される管理制御機能から拡張機能部とする。
【０１４６】
情報処理部は、これらのソフト化機能に限らず、それ以外のソフト化機能を備えていてもよい。ハードウェア部及びハードウェア部は、送受信部、ＯＳＵ、スイッチ、制御部、情報処理部に限らない。例えば、情報処理部は、送受信部、ＯＳＵ、スイッチ、制御部に含まれていてもよい。また図８に示すように、スイッチのＮＮＩ（Ｎｅｔｗｏｒｋ−Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ）側に、スイッチに入出力する信号を処理するプロキシ部又は外部サーバを備えていてもよい。外部サーバは、複数の装置を備えるデータセンタ等のいわゆるクラウドと呼ばれる情報処理機能であってもよい。
【０１４７】
各機能は、処理能力や処理遅延の要求に応じて適宜配置してもよい。また、ＯＳＵにスイッチ部１２又はスイッチ部１３を備えていてもよいし、スイッチとは別途スイッチ（スイッチ部１３を備える場合のスイッチ部１２）を備えていてもよい。スイッチの機能はスイッチ部１２とスイッチ部１３で重複せずにスイッチの処理能力等に従って適宜分担することが望ましいが、重複してもよい。
【０１４８】
ソフト化機能を配備する箇所は、情報処理部に限らず、複数の演算処理可能な箇所に配置してもよい。例えば、ソフト化機能を配備する箇所は、送受信部、ＯＳＵのスイッチ、ＯＳＵのスイッチ以外、ＯＬＴの制御部、ＯＬＴのスイッチ、ＯＬＴの情報処理部、ＯＬＴのスイッチと制御部と情報処理部以外、スイッチのＮＮＩ側にスイッチに入出力する信号を処理するプロキシ部また外部サーバ等の処理装置のいずれかであってもよい。
【０１４９】
また、ソフト化機能の配置は、ソフト化機能毎であってもよいし、単一のソフト化機能を分割したソフト化機能の一部であってもよい。例えば、送受信部に関するものを送受信部以外の他の箇所、例えば、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。ＰＯＮ終端に関するものをＰＯＮ終端処理配備箇所以外の他の箇所、例えば、ＯＳＵの送受信部、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。
【０１５０】
ＯＮＵのスイッチに関するものをＯＮＵのスイッチ以外の他の箇所、例えば、送受信部、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。ＯＬＴのスイッチに関するものをＯＬＴのスイッチ以外の他の箇所、例えば、送受信部、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。
また、ソフト化機能を配備する箇所は拡張機能部の配備の状況や、演算可能な箇所の演算能力や演算負荷や消費電力等に応じて、適宜変更してもよい。
【０１５１】
ＯＬＴの主信号処理に係る主要な機能と機能間の関係を説明する。ＯＬＴ機能をスイッチに移行する。ＰＨＹアダプテーション機能、フレーム化機能、サービスアダプテーション機能などのＰＯＮ区間処理を行うＰＯＮ主信号処理機能を、送受信部に配備する。ＯＮＵ登録又は認証機能、ＤＢＡ制御機能、ＤＷＡ機能などのＰＯＮアクセス制御機能を情報処理部に配備する。フレーム化で利用されるＶＬＡＮ制御、シェーパの前段の優先制御、マックス又はデマックス（ＭｕＸ／Ｄｍｕｘ）及びキュー（Ｑｕｅｕｅ）、並びにフレーム化の前段のシェーパなどのＬ２主信号処理機能をスイッチに配備する。
シェーパの前段のコピー機能、コピーで利用されるＭＬＤプロキシなどのマルチキャスト機能をスイッチに配備する。このように、ＰＯＮに配備されていたＰＯＮ主信号処理機能及びＰＯＮアクセス制御機能をスイッチに配備することで、ＰＯＮ基本機能部１３２を縮小する。特に、Ｌ２主信号処理は重複を避け、スイッチに配備することが好ましい。
【０１５２】
なお、スイッチの機能として、Ｃｌａｓｓｉｆｉｅｒ（クラシファイア）、Ｍｏｄｉｆｉｅｒ（モディファイア）、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ（ポリサー／シェーパ）、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ（クロス・コネクト）、Ｑｕｅｕｅ（キュー）、Ｓｃｈｅｄｕｌｅｒ（スケジューラ）の順に備える前提で例示したが適宜変更してもよい。例えば、上り方向であり、帯域割当単位の中で処理を行わなければ、ＯＮＵからの入力をバースト送信のためのプリアンブルやバーストオーバーヘッドを外し、フレームをデカプセル化したり、ＬＬＩＤを外したりして、ＰＯＮを終端のみし、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒの全ての機能をスイッチで実施してもよいし、スイッチでＭｏｄｉｆｉｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒのみ実施してもよい。
更に、ＰＯＮ終端後のパス等を記載するＶＩＤ等をＯＮＵで付与すれば、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒすればよい。上位ネットワークが単一パスと見做せれば、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒでよい。また、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔでフレームが衝突しないようにＤＢＡすれば、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、とすることができる。更に、上り方向であり、帯域割当単位の中で処理を行わなければ、ＯＮＵからの入力をバースト送信のためのプリアンブルやバーストオーバーヘッドを外し、フレームをデカプセル化したり、ＬＬＩＤを外したりして、ＰＯＮを終端のみし、ＰＯＮ終端後のパス等を記載するＶＩＤ等をＯＮＵで付与すれば、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔのみとすることもできる。
【０１５３】
また、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒで、Ｃｌａｓｓｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｍｏｄｉｆｉｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒとしてもよいし、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒの前段にＱｕｅｕｅを置いて、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｑｕｅｕｅ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｓｃｈｅｄｕｌｅｒとしたり、Ｃｌａｓｓｉｆｉｅｒ、Ｑｕｅｕｅ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｍｏｄｉｆｉｅｒ、Ｃｒｏｓｓ  Ｃｏｎｎｅｃｔ、Ｓｃｈｅｄｕｌｅｒとしたりしてもよい。ＰＯＮのバースト伝送や、マルチキャスト等の優先トラフィックを多重することによって生ずるバースト性による不要のＰｏｌｉｃｉｎｇ（ポリシング）／Ｓｈａｐｉｎｇ（シェイピング）や、受信側での平準化したトラフィックの受信を考慮するとＰｏｌｉｃｅｒ／Ｓｈａｐｅｒの前段にＱｕｅｕｅを置いて平準化した後にＰｏｌｉｃｉｎｇ／Ｓｈａｐｉｎｇによる処理を実行することが望ましい。
【０１５４】
（実施形態１−２）
実施形態１−１ではＴＷＤＭ−ＰＯＮに用いられる構成を例示したが、ＴＤＭ−ＰＯＮに適用してもよい。ＴＤＭ−ＰＯＮでは、λ設定切替（ＤＷＡ）のようなＯＮＵの間ＯＮＵ−ＯＬＴのＰＯＮ区間の波長リソースを波長分割多重する機能を備えていなくてもよいことを除けば実施形態１−１と同様である。
【０１５５】
（実施形態１−３）
実施形態１−１ではＴＷＤＭ−ＰＯＮに用いられる構成を例示したが、ＷＤＭ−ＰＯＮに適用してもよい。ＷＤＭ−ＰＯＮでは、ＤＢＡのようなＯＮＵの間ＯＮＵ−ＯＬＴのＰＯＮ区間の帯域リソースを時分割多重する機能を備えていなくてもよいことを除けば、実施形態１−３は実施形態１−１と同様である。
【０１５６】
（実施形態１−４）
本実施形態は、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘ）−ＰＯＮ、ＣＤＭ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘ）−ＰＯＮ、ＳＣＭ（Ｓｕｂｃａｒｒｉｅｒ  Ｍｕｌｔｉｐｌｅｘ）−ＰＯＮ、芯線分割多重を含めた組み合わせである。
【０１５７】
実施形態１−１ではＴＷＤＭ−ＰＯＮに用いられる構成を例示したが、波長と時間以外のリソースを共用するＰＯＮに適用してもよい。例えば、１波長の電気の周波数リソースを分割多重するＯＦＤＭ−ＰＯＮ、１波長の電気の周波数リソースを分割多重するＳＣＭ−ＰＯＮ、符号で分割多重するＣＤＭ−ＰＯＮに適用してもよいし、芯線分割多重を併用してもよいし、マルチコアファイバ等を用いた空間分割多重を併用してもよいし、波長分割多重を用いなくてもよい。ＴＷＤＭ−ＰＯＮの波長リソースを波長分割多重する機能を、それぞれの多重するリソースに分割多重するに要する機能に対応する機能に読み替えれば同様である。
【０１５８】
（実施形態２）
実施形態２では、ＴＷＤＭ−ＰＯＮに用いられる構成が、ＧＥＭカプセル化を行う。この場合、ＧＥＭフレームを生成するアダプタをスイッチに備え、スイッチとそれ以外の部分の間でＧＥＭフレームを導通するようにする。ＧＥＭカプセル化までスイッチに移管することで、それ以外の部分のプロトコルスタックからＬ２機能部を除外し、スイッチとそれ以外の部分で、Ｌ２機能部の重畳を回避することができる。
【０１５９】
なお、ＴＷＤＭ−ＰＯＮを例に挙げたが、実施形態１−２〜実施形態１−４のように、ＰＯＮ区間での識別するためのフレームを同様に扱えばそれ以外のＰＯＮであっても同様の効果が得られる。例えば、ＩＥＥＥの規格のＧＥ−ＰＯＮ、１０ＧＥ−ＰＯＮ等であれば、ＧＥＭフレームの代わりに、ＬＬＩＤを付与してＬＬＩＤの付与されたフレームをスイッチとそれ以外の部分の間を導通するようにすればよい。
【０１６０】
（実施形態３）
実施形態３では、ＴＷＤＭ−ＰＯＮに用いられる制御情報が、スイッチを経由する。この場合、ブリッジ機能関連をスイッチに移管する代わりに、制御情報を保持するＰＬＯＡＭ、Ｅｍｂｅｄｄｅｄ  ＯＡＭ、ＯＭＣＩのいずれかを必要に応じてフレーム化してスイッチ経由で処理する。制御情報をスイッチ経由で入出力することで、スイッチ以外の処理が軽くなる効果がある。なお、実施形態３の移管に加えて、実施形態１及び実施形態２のブリッジ機能のスイッチへの移管を行ってもよい。
なお、ＴＷＤＭ−ＰＯＮを例に挙げたが、制御情報を同様に扱いスイッチ経由で処理すれば、実施形態１−２〜実施形態１−４のように、それ以外のＰＯＮであっても同様の効果が得られる。
【０１６１】
上述した実施形態における通信装置の少なくとも一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。更に「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、更に前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
【０１６２】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではない。上記の実施形態は例示に過ぎず、本発明は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができ、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０１６３】
１１…送受信部，  １２、１３…スイッチ部，  １４…制御部，  １５…プロキシ部，  １６…外部サーバ，  ２１、２２、２７…機器無依存ＡＰＩ，  ２３、２４、２５…機器依存ＡＰＩ
【図１】
2018022963.tif 000003
【図２】
2018022963.tif 000004
【図３】
2018022963.tif 000005
【図４】
2018022963.tif 000006
【図５】
2018022963.tif 000007
【図６】
2018022963.tif 000008
【図７】
2018022963.tif 000009
【図８】
2018022963.tif 000010
【図９】
2018022963.tif 000011
【図１０】
2018022963.tif 000012
【図１１】
2018022963.tif 000013
【図１２】
2018022963.tif 000014
【図１３】
2018022963.tif 000015
【図１４】
2018022963.tif 000016
【図１５】
2018022963.tif 000017
【図１６】
2018022963.tif 000018
【図１７】
2018022963.tif 000019
【図１８】
2018022963.tif 000020
【図１９】
2018022963.tif 000021
【図２０】
2018022963.tif 000022