JP7348129B2 - 通信装置、情報通知方法及びコンピュータプログラム - Google Patents

Description

本発明は、通信装置、情報通知方法及びコンピュータプログラムに関する。

通信装置を備える通信システムには、例えば、ＰＯＮ（Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ）システムがある。ＰＯＮシステムは、顧客の宅内等に設置されるＯＮＵ（Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ：光加入者線終端装置）と、局舎に設置される通信装置であるＯＬＴ（Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ：光加入者線端局装置）と、両者を接続する光ファイバ網とを備える（非特許文献１参照）。
通信装置において、装置の準拠規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して依存性の低い機能を部品化し、当該機能のアプリケーションプログラミングインタフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）等の入出力インタフェース（ＩＦ：Ｉｎｔｅｒｆａｃｅ）の少なくとも一部を明確化し、汎用性・移植性・拡張性を高めることで、準拠規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかが異なる機器間での共用や独自機能の追加を容易とすることができる（非特許文献２参照）。

ＩＴＵ－Ｔ勧告Ｇ.９８９．１ ４０－Ｇｉｇａｂｉｔ－ｃａｐａｂｌｅ ｐａｓｓｉｖｅ ｏｐｔｉｃａｌ ｎｅｔｗｏｒｋｓ （ＮＧ－ＰＯＮ２）、２０１３ "ＦＡＳＡ"、［online］、ＮＴＴ、[平成２８年７月２８日検索]、インターネット＜http://www.ansl.ntt.co.jp/j/FASA/index.html＞

機能を部品化する場合、部品の配置場所は同一筺体内とは限らず、複数筺体に分散して配置されることがある。逆に、筺体内の部品が他装置を構成する部品として利用されることがある。しかしながら、ＯＮＵ、送信機、受信機、送受信器、ＣＴ（ｃｈａｎｎｅｌ ｔｅｒｍｉｎａｔｉｏｎ）、ＯＳＵ（Ｏｐｔｉｃａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）、ＯＬＴ等の通信装置を構成する部品や通信装置は、通信装置の保持する運用情報を、装置側で保持する場合、運用情報、特に波長、芯線、モード、周波数、キャリア、符号等へのＯＮＵ収容替等の部品の帰属替に伴い、収容替対象のＯＮＵ等の部品の帰属替に係る情報、例えばスリープ状態、運用系の状態、波長や芯線やコアや符号や周波数やキャリアの利用状態、自装置または対向する装置の状態、マルチキャストの加入離脱や配信の状態、帰属(収容)履歴や予め定められた又は算出した今後の帰属(収容)替順序のいずれかを継承させる手段が必要となる。

上記事情に鑑み、本発明は、通信装置を構成する部品又は通信装置の帰属替に伴い、通信装置を構成する部品又は通信装置に係る情報を継承させることができる技術の提供を目的としている。

本発明の一態様は、通信装置を構成する部品として、帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部を備え、前記保持部は、前記帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部とは異なる複数の保持部に対して保持する情報を通知しておき、前記第１の通信装置を構成する部品又は前記第１の通信装置の帰属替えのタイミングで、前記通知された保持部は、保持している情報の少なくとも一部を帰属替え先に対応する第２の通信装置の保持部に対して、ＯＡＭ部、主信号線又はオペレーションシステムのいずれかの前記通信装置と前記第２の通信装置との間を接続する外部の経路を介して通知する通信装置である。

本発明の一態様は、通信装置を構成する部品として、帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部を備える通信装置が行う通知方法であって、前記保持部が、前記帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部とは異なる複数の保持部に対して保持する情報を通知しておき、前記第１の通信装置を構成する部品又は前記第１の通信装置の帰属替えのタイミングで、前記通知された保持部は、保持している情報の少なくとも一部を帰属替え先に対応する第２の通信装置の保持部に対して、ＯＡＭ部、主信号線又はオペレーションシステムのいずれかの前記通信装置と前記第２の通信装置との間を接続する外部の経路を介して通知する情報通知方法である。

本発明の一態様は、コンピュータを、上記の通信装置に備わる各機能部として機能させるためのコンピュータプログラムである。

本発明により、通信装置を構成する部品又は通信装置の帰属替に伴い、通信装置を構成する部品又は通信装置に係る情報を継承させることが可能となる。

通信装置のアーキテクチャの第１例を示す図である。 通信装置のアーキテクチャの第２例を示す図である。 通信装置のアーキテクチャの第３例を示す図である。 通信装置のアーキテクチャの第４例を示す図である。 アーキテクチャの別例を示す図である。 通信装置及び外部サーバ１６の構成の例を示す図である。 ＯＬＴの構成を示す図である。 通信装置内の機能部間の信号／情報の流れを示す図である。 ＰＯＮ主信号処理機能部３００が有する機能構成の例を示す図である。 ＰＯＮアクセス制御機能部３２０が有する機能構成の例を示す図である。 Ｌ２主信号処理機能部３４０が有する機能構成の例を示す図である。 保守運用機能部３３０が有する機能構成の第１例を示す図である。 保守運用機能部３３０が有する機能の構成の第２例を示す図である。 保守運用機能部３３０が有する機能構成の第３例を示す図である。 ＰＯＮマルチキャスト機能部３５０が有する機能構成の例を示す図である。 省電力制御機能部３６０が有する機能構成の例を示す図である。 周波数・時刻同期機能部３７０が有する機能構成の例を示す図である。 プロテクション機能部３８０が有する機能構成の例を示す図である。

以下、本発明の一実施形態を、図面を参照しながら説明する。
（実施形態１）
通信装置は、例えば、ＰＯＮ等の光ファイバ網等の通信網を経由する光信号等の信号によって、他の通信装置との通信を実行する装置である。通信装置は、例えば、ＯＬＴである。通信装置は、例えば、ＯＳＵでもよい。通信装置は、例えば、光信号を切り替えるスイッチ部（ＳＷ）を備える又は備えないＯＬＴと、他のスイッチ部（ＳＷ）との組み合わせでもよい。通信装置は、例えば、ＯＬＴとＯＮＵとの組み合わせでもよい。通信装置は、複数の機器を備えてもよい。

ＯＮＵ、送信機、受信機、送受信器、ＣＴ、ＯＳＵ、ＯＬＴ等の通信装置を構成する部品や通信装置間のやり取りは、後述のミドルウェアを介すが、通信装置の独自の転送経路や手段を用いてもよいし、ＯＰＥＮＦＬＯＷや、ＮＥＴＣＯＮＦ／ＹＡＮＧや、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）等の規格化された手段を用いてもよい。また、内部配線、バックボード、ＯＡＭ部、主信号線、専用の配線、オペレーションシステム、コントローラ又は制御盤（Ｃｏｎｔ盤）等の経路のいずれでよい。やり取りはＯＡＭ部又は主信号にカプセル化してもよいし、いずれかの箇所で終端して、内部配線、バックボード、ＯＡＭ部、主信号線、専用の配線、オペレーションシステム、コントローラ又は制御盤等の経路を経由して入力してもよい。ＯＡＭ部や主信号線を用いる場合、ＯＡＭ部や主信号にカプセル化することが望ましい。主信号線を通す場合はＯＳＵ又は他箇所のスイッチ部にて振り分けることが望ましい。

次に、例として、ＴＷＤＭ（Ｔｉｍｅ ａｎｄ Ｗａｖｅｌｅｎｇｔｈ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘ）－ＰＯＮシステムのようなＩＴＵ－Ｔ勧告準拠のＰＯＮのＯＬＴを前提に、動作等を例示する。ここで、ＴＷＤＭ－ＰＯＮとしているが、ＰＯＮは、ＩＴＵ－Ｔ勧告準拠のＴＷＤＭ－ＰＯＮ以外のＰＯＮであってもよい。例えば、ＰＯＮは、ＧＥ（Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標））－ＰＯＮ、１０ＧＥ－ＰＯＮ等のＩＥＥＥ規格準拠のＰＯＮであってもよい。ＴＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｖｅｒｇｅｎｃｅ）レイヤやＰＭＤ（Ｐｈｙｓｉｃａｌ Ｍｅｄｉｕｍ Ｄｅｐｅｎｄｅｎｔ）レイヤは、標準規格において対応する層に読み替えれば同様である。

以下、帰属替えするＯＮＵ、送信機、受信機、送受信器、ＣＴ、ＯＳＵ、ＯＬＴ等の通信装置を構成する部品や通信装置としてＯＮＵを代表として説明するが、ＯＮＵ以外であっても同様である。
送信機又は受信機又は送受信器又はＣＴ又はＯＳＵ又はＯＬＴ（通信装置）に、収容替対象のＯＮＵに係る運用情報、例えばスリープ状態、運用系の状態、波長や芯線やコアや符号や周波数や（サブ）キャリアの利用状態、自装置または対向する装置の状態、マルチキャストの加入離脱や配信の状態、設定値、ＯＮＵのステート情報、ＥｑＤ、認証情報、フィルタ（Filter）設定情報、利用履歴（履歴情報）、課金情報、契約情報、マックアドレス等のラーニング情報であるマックテーブル（MAC Table）、帯域利用や帯域割当に関する不足カウンタ（Deficit Counter）、マルチキャストのＬｅａｖｅ／Ｊｏｉｎ等の応答で特に応答が未了のもの自体であってもよいし、帰属(収容)履歴や予め定められた又は算出した今後の帰属(収容)替順序であってもよく、それらの特定の状態のいずれかを保持する保持部を備える。保持部は以下のいずれかの処理を行う。

（１）ＯＮＵの収容替されうる、波長、芯線、モード、周波数、(サブ)キャリア、符号等の情報を保持する保持部の全てに運用情報を広告（通知）する。広告又は後述の通知は常時又は間欠的でよく、間欠の周期の上限は状態情報の誤差による。例えば、流量制御で１ＧＢが許容される誤差とすると、１ＧＢの流量が発生する時間間隔以下となる。逆に、間欠周期が長すぎて誤差が許容値を超過する場合は、流量自体を抑制して、誤差以下となるようにしてもよい。また保持部への書き込み情報は、運用情報そのものでもよいし、運用情報に統計処理を施した結果に基づく情報でもよい。書き込み情報は、一定期間の情報を、所定期間の総和、指数平均、移動平均、所定の間隔で履歴をリセットする形の平均、及びその他の統計処理を施した結果に基づく情報でもよい。書き込み情報は、書き込みに要する通信路の帯域や帯域時間積や書き込みに要する処理のコストに応じて変更されてもよい。運用情報の送受によって消費する通信帯域と、運用情報の転送に要する時間から広告又は通知に要する制約を満足することが望ましい。例えば、伝送時間としては、例えばＯＬＴ－ＯＮＵ間で応答が０．７５ミリ秒との規定のＰＬＯＡＭの応答であれば、０．７５ミリ秒等の当該処理に許容される時間から処理に要する時間を減じた時間以下のＯＳＵ－保持部の往復伝送時間である。伝送時間や伝送のためのフレーム化処理や保持部からの読出／書込み等の処理に要する時間の開始時間や処理時間に時間変動（ジッタ）がある場合は、最大のジッタの遅延を乗せた時間が処理に要する時間とすればよい。なお処理や応答に許容する時間は、標準化等で規定された値以上であっても相対する装置が許容する場合はその規定以上であってもよい。例えばＰＬＯＡＭであれば、ＯＮＵとＯＬＴで０．７５ミリ秒以上でも通信断としない等対応して動作するようにすれば、それ以上の値であってもよい。

（２）ＯＮＵの収容替されうる、波長、芯線、モード、周波数、(サブ)キャリア、符号の情報を保持する保持部のいずれか一つをホームと設定し、ホームで運用情報を保持し、少なくとも運用中の波長、芯線、モード、周波数、(サブ)キャリア、符号等の保持部に対して通知する。通知対象となる運用中の波長、芯線、モード、周波数、(サブ)キャリア、符号等に対応する保持部は収容替えに際し、少なくとも通知対象外に収容替えする場合は、収容替えに際して収容替え先の波長、芯線、モード、周波数、(サブ)キャリア、符号等に対応する保持部を通知先に含むように通知先を変更して通知する。

（３）収容替えに際して、運用情報を収容替え先の波長、芯線、モード、周波数、(サブ)キャリア、符号等に対応する保持部に通知する。収容元の保持部の当該収容替え対象の運用情報は、収容先の保持部に通知次第、或いは収容先の保持部からの運用情報格納の通知、或いは収容先の保持部からの運用情報の未格納の所定の期間又は所定の周期等の経過後もないことを確認して、削除することが望ましい。

（１）～（３）で、収容されていないＯＮＵ等の情報を保持する保持部に対応する送信機、受信機、送受信器、ＣＴ、ＯＳＵ、ＯＬＴ等は予め運用情報に応じたパス等の設定をしておくことが望ましく、設定より帯域の減少との問題がある場合は、設定しておきその設定による動作を休止しておくことが望ましい。

ここで、収容替は、ロードバランスや省電力目的であってもよいし、Ｔｙｐｅ Ｂ切替、党の切替であってもよい。切替契機は、連続又は間欠の広告又は通知の場合の所定期間の広告又は通知の欠如、切替通知、ＬＯＳ（Loss of Signal）、ＬＯＢｉ（Loss of burst for ONUi）、ＤｙｉｎｇＧａｓｐ、ＯＳＵ電源ＯＦＦ、ＯＳＵ抜去、芯線抜去等としてもよいし、保持部に対する新規の入力があるか否かで検出してもよいし、ＯＮＵからの帯域要求の総和と、ＯＳＵ又はＯＬＴ又はＳＷでの流量をそれぞれ保持部で保持し、保持したそれらの値が、流量制限等の妥当な処理なしに、所定値以上の差分が発生したことを持って、切替契機の異常として検出してもよい。例えば、強制切替、コールドスタンバイ（Cold Standby）であれば、外付の装置例えばスイッチ（ＳＷ）でフレームをバッファリングして、指示後５０ミリ秒以内に予備系ＯＳＵ（Cold Standby）の起動が開始し、下りトラフィックはフレームロスなく、上りトラフィックはＯＮＵ上りバッファ量までフレームロスなく、運用系の運用情報での通信がレンジング処理なしに切替する。例えば、ＯＳＵ切替（情報継承、障害、Cold Standby、予め切替に備えてＳＷでバッファリング）であれば、運用系ＯＳＵのパッケージ又はファイバを抜去し、設定した切替保護時間と誤差分の＋１設定単位以内に予備系ＯＳＵ（Cold Standby）の起動が開始するので、下りトラフィックでは設定した切替保護時間＋１設定単位分を上限とするフレームロスが発生する。また、上りトラフィックでは、ＯＮＵ上りバッファ量までフレームロスが発生すること無く、ＯＳＵが切替わる。例えば、ＯＳＵ切替（強制切替、ホットスタンバイ（Hot Standby））であれば、指示後５０ミリ秒以内に予備系ＯＳＵ（Cold Standby）の起動が開始し、下りトラフィックではフレームロスが発生することなく、上りトラフィックではＯＮＵ上りバッファ量までフレームロスが発生することなく、運用系の運用情報での通信がレンジング処理なしに切替わる。例えば、ＯＮＵ切替（強制切替、ホットスタンバイ）であれば、指示後５０ミリ秒以内に予備系ＯＮＵで（Cold Standby）の起動が開始し、下りトラフィックではフレームロスが発生することなく、上りトラフィックでは起動するまでの時間、例えば５０ミリ秒を上限とするフレームロスが発生して、運用系ＯＳＵの運用情報の通信が開始される。
なお、異常状態になった後の運用情報が正常である場合は遷移後の運用情報を用いてもよいが、異常な運用情報を用いると異常な状態となるおそれがある。異常となる前の運用状態を用いることでその危険を軽減できる。

（実施形態１－１）
実施形態１－１では、ＴＷＤＭ－ＰＯＮに用いられる通信システムを構成する通信装置の構成について説明する。以下、通信装置のアーキテクチャの例として、第１例から第６例までを説明する。通信システムを構成する通信装置のアーキテクチャは、下記で説明する第１例から第６例まで以外のアーキテクチャであってよい。例えば、アーキテクチャの第１例から第６例における通信装置のソフトウェア部は、ハードウェア部でもよい。

（アーキテクチャの第１例）
図１は、通信装置のアーキテクチャの第１例を示す図である。アーキテクチャの第１例では、通信装置は、準拠する標準や製造ベンダに依存する機器依存部１１０と、機器依存部１１０のハードウェアやソフトウェアの違いを隠蔽するミドルウェア１２０と、動作が機器に依存しない汎用の機器無依存アプリ１３０とを備える。したがって、機器依存部（ベンダ依存部）１１０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存する機能部である。言い換えれば、機器依存部１１０は、他の通信機器との互換性が小さく、新たに製造された通信機器（特に、準拠する標準や製造ベンダが異なる機器）にはそのまま用いることができない。機器依存部１１０は、ネットワーク機器に備わる１以上の機能を実行する。

また、機器無依存アプリ１３０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存しない機能部である。言い換えれば、機器無依存アプリ１３０は、他の通信機器との互換性が大きく、新たに製造された通信機器（特に、準拠する標準や製造ベンダが異なる機器）にそのまま用いることができる。機器無依存アプリ１３０に設けられるアプリの具体例として、ネットワーク機器における設定処理を行うアプリ、設定の変更処理を行うアプリ、アルゴリズム処理を行うアプリ等がある。
ミドルウェア１２０と機器無依存アプリ１３０とは、機器無依存ＡＰＩ２１を介して接続される。機器無依存ＡＰＩ２１は、機器に依存しない入出力ＩＦである。

機器依存部１１０は、例えばハードウェア部（ＰＨＹ）１１１、ハードウェア部（ＭＡＣ）１１２、ソフトウェア部１１３及びＯＡＭ（Ｏｐｅｒａｔｉｏｎ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）部１１４を備えて構成される。ハードウェア部（ＰＨＹ）１１１、ハードウェア部（ＭＡＣ）１１２、ソフトウェア部１１３及びＯＡＭ部１１４と、ミドルウェア１２０とは、機器依存ＡＰＩ２３を介して接続される。機器依存ＡＰＩ２３は、機器に依存する入出力ＩＦである。機器依存部１１０は、更にＮＥ（ＮＥ、Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ）管理・制御部１１５を備える。ＮＥ管理・制御部１１５とミドルウェア１２０とは、機器依存ＡＰＩ２５を介して接続される。

どのような機能を機器依存部１１０又は機器無依存アプリ１３０とするかは、ミドルウェア１２０や機器無依存アプリ１３０を実現するための処理に由来する制限、例えば、ソフトウェアの処理能力に由来する制限に加えて、機能の更新頻度や拡張機能の重要度等に応じて決められてもよい。これによって、通信装置は、機器無依存アプリ１３０による拡張機能部（独自機能部）の柔軟かつ迅速な追加を容易にし、通信サービスをタイムリーに提供することができる。

例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ（Ｄｙｎａｍｉｃ Ｂａｎｄｗｉｄｔｈ Ａｓｓｉｇｎｍｅｎｔ）等の更新頻度が高い機能又は通信サービス差異化に寄与する機能を優先して、機器依存部１１０又は機器無依存アプリ１３０とすることを決めてもよい。更に、共用化を図る機器の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して差異の隔たりが小さいものから、機器無依存アプリ１３０としてもよい。

準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに対しては最適でない場合でも、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの機能のいずれかを汎用化するために、機能を実行するための共通ＩＦが用いられてもよい。共通ＩＦの中には、機器依存部１１０の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダのいずれかにおいて使用されないＩＦやパラメータが含まれていてもよい。

図１及び後述する図２に示すミドルウェア１２０と、後述する図３及び後述する図４に示す機器依存部１１０のドライバと、後述する図２及び後述する図４に示す機器依存アプリ部（ベンダ依存アプリ部）との少なくともいずれかに、ＩＦやパラメータ等を機器依存部１１０に対応するように変換する変換機能部や、不足するＩＦやパラメータ等に対応して自動設定する機能部を更に備えてもよい。

図１に示す機器依存部１１０が備えるハードウェア部（ＰＨＹ）１１１は、物理層から光送受信関連の処理まで（ＰＨＹｓｉｃａｌ ｓｕｂｌａｙｅｒ処理）を実行する。ハードウェア部（ＭＡＣ）１１２は、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）処理を実行する。ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２は、準拠する標準規格や製造ベンダに依存する。ソフトウェア部１１３は、機器依存のドライバ、ファームウェア、アプリケーション等を実行する。

機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２は、これら以外に汎用サーバやレイヤ２スイッチ等を備えてもよい。機器依存部１１０は、ハードウェア部（ＭＡＣ）１１２を備えなくてもよい。機器依存部１１０は、ハードウェア部（ＰＨＹ）１１１の一部を備えなくてもよい。例えば、機器依存部１１０は、変復調信号処理、前方誤り訂正（ＦＥＣ、Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）、符復号処理、暗号化処理等の低位の信号処理を備えずに、光関連の機能のみを備えてもよい。機器依存部１１０は、データを符号化する部分であるＰＣＳ（Ｐｈｙｓｉｃａｌ Ｃｏｄｉｎｇ Ｓｕｂｌａｙｅｒ）を備えなくてもよい。機器依存部１１０は、データのシリアル化を行うＰＭＡ（Ｐｈｙｓｉｃａｌ Ｍｅｄｉｕｍ Ａｔｔａｃｈｍｅｎｔ）とＰＣＳとを備えなくてもよい。機器依存部１１０は、物理媒体に接続するＰＭＤを備えなくてもよい。機器依存部１１０は、ミドルウェア１２０がソフトウェア部を介さずに機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を直接に駆動、制御、操作又は管理する場合、ソフトウェア部を備えなくてもよい。

機器無依存アプリ１３０は、例えば、拡張機能部（図１では、拡張機能Ａ１３１－１、拡張機能Ｂ１３１－２及び拡張機能Ｃ１３１－３）１３１と、基本機能部１３２と、管理・制御エージェント部１３３とを備える。管理・制御エージェント部１３３は、ＥＭＳ（Ｅｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）１４０からデータを取得する。図ではＥＭＳ１４０及び外部の装置１５０がミドルウェア１２０を介して機器無依存アプリ１３０に接続しているが、ＥＭＳ１４０及び外部の装置１５０は必ずしもミドルウェア１２０を介して機器無依存アプリ１３０に接続している必要は無い。ＥＭＳ１４０及び外部の装置１５０は、必要に応じてミドルウェア１２０に適宜接続してもよいし、機器無依存アプリ１３０に直接接続してもよい。また「ミドルウェア１２０経由で接続」と表現しているが、この表現は機器無依存アプリ１３０からみた視点での表現である。実際には、ハードウェアでの接続の後にミドルウェア１２０を介して機能無依存アプリ同士が接続している。

以下、拡張機能部に共通する事項については、符号の一部を省略して、「拡張機能部」と表記する。ＥＭＳ１４０は、例えば、ＮＥのコントローラである。なお、機器無依存アプリ１３０は、拡張機能部と基本機能部１３２と管理・制御エージェント部１３３とのうちいずれかを含まなくてもよいし、管理・制御エージェント部１３３が基本機能部１３２に含まれていてもよいし、管理・制御エージェント部１３３が基本機能部１３２やミドルウェア１２０に含まれていてもよい。

機器無依存アプリ１３０は、拡張機能部、基本機能部１３２、及び管理・制御エージェント部１３３以外の構成を、更に含んでいてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリ１３０は、拡張機能部を備えなくてもよい。また、機器無依存アプリ１３０は、１個以上の拡張機能部を含んでもよい。

拡張機能部は、他の機能に不要な影響を与えずに独立して追加、削除、入替又は変更が可能であることが好ましい。例えば、拡張機能部は、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を実行する拡張機能部が必要になった場合、適宜に追加、削除、入替又は変更されてもよい。

基本機能部１３２は、拡張機能部の一部として機器無依存アプリ１３０に含まれてもよいし、ミドルウェア１２０よりも下位の機能部によって代替されてもよい。拡張機能部が基本機能部１３２を含む場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。ミドルウェア１２０よりも下位の機能部が基本機能部１３２を代替する場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。拡張機能部が基本機能部１３２を含み、ミドルウェア１２０よりも下位の機能部が基本機能部１３２を代替する場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。

管理・制御エージェント部１３３は、ＥＭＳ１４０からの通信を受けずに、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０と入出力しなくてよい。更に、管理・制御エージェント部１３３が管理設定機能を備えず、他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。

ＥＭＳ１４０と機器無依存アプリ１３０とは、情報を直接入出力してもよい。また、機器依存部１１０は、ＮＥ管理・制御部１１５と、ＮＥ管理・制御部１１５の下位の機能部の機器依存アプリ部（後述する図２及び後述する図４参照）によって代替されてもよい。

管理・制御エージェント部１３３は、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０との間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部１３３が備えず他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。ＥＭＳ１４０と機器無依存アプリ１３０とは、情報を直接入出力してもよい。

機器無依存アプリ１３０と機器依存部１１０との入出力の例は以下である。
例えば、ＤＢＡアプリ部及びプロテクションアプリ部は、ＴＣレイヤのエンベデッドＯＡＭエンジン（Ｅｍｂｅｄｄｅｄ ＯＡＭ Ｅｎｇｉｎｅ）と、相互に情報を入出力する。ＤＷＢＡ（Ｄｙｎａｍｉｃ Ｗａｖｅｌｅｎｇｔｈ ａｎｄ Ｂａｎｄｗｉｄｔｈ Ａｓｓｉｇｎｍｅｎｔ）アプリ及びＯＮＵ登録認証アプリ部は、ＴＣレイヤのＰＬＯＡＭエンジンと、相互に情報を入出力する。省電力アプリ部は、ＯＭＣＩ及びＬ２主信号処理機能部（Ｌ２機能部）と相互に情報を入出力する。ＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒ）プロキシアプリ部は、Ｌ２機能部と相互に情報を入出力する。低速監視アプリ（ＯＭＣＩ）は、ＯＭＣＩと相互に情報を入出力する。ＯＭＣＩ及びＬ２機能部は、ＸＧＥＭフレーマ（ＸＧＰＯＮ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｍｅｔｈｏｄ Ｆｒａｍｅｒ）及び暗号化を動作させる。ここで、ＤＷＢＡとＤＢＡは、別々、一体又は組み合わせでもよい。例えば、管理・制御エージェント部１３３は、保守運用機能のアプリ部であり、ＮＥ管理・制御部１１５のためのＮＥコントローラ等であるＥＭＳ１４０と、相互に情報を入出力する。

機器無依存アプリ１３０は、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＴＵ－Ｔ Ｇ．９８９シリーズに準拠するＴＷＤＭ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８７シリーズに準拠するＸＧ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８４シリーズに準拠するＧ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８３シリーズに準拠するＢ（Ｂｒｏａｄｂａｎｄ）ＰＯＮとのいずれにもよらずに動作するアプリである。機器無依存アプリ１３０は、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＥＥＥ８０２．３ａｖやＩＥＥＥ１９０４．１等に準拠する１０ＧＥ－ＰＯＮとＩＥＥＥ８０２．３ａｈに準拠するＧＥ－ＰＯＮ等の差異の少なくともいずれかに依らずに動作するアプリである。

拡張機能部のアプリとして、機器無依存ＡＰＩ２１を介して、一部のベンダ、方式、種別、世代に備える機能を駆動するためのアプリや、一部のベンダ、方式、種別、世代の装置のみに備える機能を駆動するアプリを含んでいてもよい。
管理・制御エージェント部１３３は、ＥＭＳ１４０及びミドルウェア１２０と入出力する。ミドルウェア１２０は、ＮＥ管理・制御部１１５との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＮＥ管理情報及び制御情報をＥＭＳ１４０と直接送受信してもよいし、管理・制御エージェント部１３３を介して、ＮＥ管理情報及び制御情報を送受信してもよい。

ミドルウェア１２０は、機器無依存アプリ１３０と機器無依存ＡＰＩ２１を介して情報を入出力する。ミドルウェア１２０は、機器依存ＡＰＩ２３を介して、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部又はハードウェア部と情報を入出力する。ミドルウェア１２０は、入力した情報を、そのまま又は所定の形式で出力する。例えば、ミドルウェア１２０は、出力先が機器無依存アプリ１３０の各部であれば、機器無依存ＡＰＩ２１の各部の入力形式に情報を変換する。出力先が機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部又はハードウェア部であれば、ミドルウェア１２０は、それぞれに入力する形式の機器依存ＡＰＩ２３の形式に変換してから、又は終端して所定の処理を施してから情報を出力先に送信する。

ミドルウェア１２０は、入力の際に、それぞれの入力先に不要な入力情報は削除し、不足の情報があれば、他の機器無依存ＡＰＩ２１や機器依存ＡＰＩ２３を介して収集して補足することが望ましい。また、ミドルウェア１２０への入力の際に、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。

図１では、ミドルウェア１２０や機器依存部１１０は単一で例示したが、それぞれ複数から構成されていてもよい。機器依存部１１０のハードウェアに複数のプロセッサが含まれる場合、ミドルウェア１２０はプロセッサやハードウェアをまたいでプロセッサ間通信等を用いて入出力してもよい。機器無依存アプリ１３０間や機器無依存アプリ１３０をＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）のような実行プログラムとして、単一のプロセッサ上のユーザ空間上に配置してもよいし、複数のプロセッサ上のユーザ空間上に配置してもよい。

また、機器無依存アプリ１３０は、ＡＰＩ等の入出力ＩＦを確保した上でカーネル空間に配置してもよいし、独立にファームウェア等に入替可能なＩＦを有するミドルウェア１２０とともに配置してもよいし、ファームウェア等に組み込んでコンパイルし直してもよい。機器無依存アプリ１３０毎にユーザ空間やカーネル空間を任意の組み合わせとしてもよい。

同一の機能に対応する機器無依存アプリ１３０を、ユーザ空間とカーネル空間の両方で実装可能としてもよい。この場合、例えば、切り替えていずれかを選択してもよいし、両方協働して処理してもよいし、一方のみで実処理を行うとしてもよい。機器依存部１１０のソフトウェアも同様である。

望ましくは、主信号処理やＤＢＡ処理や低レイヤの信号処理のように高速処理が必要であるほど、拡張性・入替の即時性とトレードオフはあるが、オーバーヘッドが少なく高速な処理が期待されるカーネル空間やファームウェアに組み込むことが望ましい。機器依存アプリ部（後述する図２及び後述する図４参照）を配置するプロセッサもプロセッサ間通信によるバスや速度等の制限、通信路の占有等による他のプログラムへの影響の観点から、実処理を行うプロセッサ又はその近傍のプロセッサのユーザ空間やカーネル空間やファームウェア上に配置することが望ましい。ただし、実処理を行うプロセッサ又はその近傍のプロセッサの能力を軽減するためにはプロセッサ間通信によるコミュニケーションコストは増大するが、遠隔のプロセッサで処理するとしてもよい。

機器無依存ＡＰＩ２１は、追加する拡張機能部を想定してミドルウェア１２０に予め備えられることが望ましいが、機器依存ＡＰＩ２３や他の機器無依存アプリ１３０の改変を抑制する形で、必要に応じて追加又は削除されてもよい。

なお、本例では、ソフト化領域を、基本機能部１３２、管理・制御エージェント部１３３、拡張機能部、ミドルウェア１２０としたが、ソフト化領域は、サービスアダプテーション（暗号化、フラグメント処理、ＧＥＭフレーム化／ＸＧＥＭフレーム化、ＰＨＹアダプテーションのＦＥＣ、スクランブル、同期ブロック生成／抽出、ＧＴＣ（ＧＰＯＮ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｖｅｒｇｅｎｃｅｓ）フレーム化、ＰＨＹフレーム化、ＳＰ変換、符号化方式も対象としてもよい。アーキテクチャのソフト化機能の実装例とハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２に対応する機能配備の例を説明する。機能配備は、例えば、ネットワーク機器又は外部のサーバにソフト化機能を備える。これは他の例でも同様である。

（アーキテクチャの第２例）
図２は、通信装置のアーキテクチャの第２例を示す図である。図２では、通信装置は、図１に示す通信装置のミドルウェア１２０の配下に機器依存アプリ部１６０を更に備えた構成である。アーキテクチャの第２例は、機器依存アプリ部１６０を備えること以外は、アーキテクチャの第１例と同様である。

図２では、通信装置は、準拠する機器依存部１１０の標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等を実行するソフトウェア部と、機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２やソフトウェア部の少なくとも一部を駆動する機器依存アプリ部１６０と、機器依存部１１０のハードウェア部、ハードウェア部、ソフトウェア部及び機器依存アプリ部１６０の違いを隠蔽するミドルウェア１２０と、機器に依存しない汎用の機器無依存アプリ１３０とを備える。

ミドルウェア１２０と機器依存アプリ部１６０とは、機器依存ＡＰＩ２３で接続される。機器依存アプリ部１６０と、機器依存部１１０のＯＡＭ部１１４、ソフトウェア部、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２とは、機器依存ＡＰＩ２４で接続される。機器依存アプリ部１６０と管理・制御エージェント部１３３とは、ＡＰＩで接続される。

機器無依存アプリ１３０は、例えば、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３と、基本機能部１３２と、拡張機能部とを備える。機器無依存アプリ１３０は、アーキテクチャの第１例と同様に、管理・制御エージェント部１３３と基本機能部１３２と拡張機能部とのうちいずれかを備えなくてもよい。機器無依存アプリ１３０は、管理・制御エージェント部１３３と基本機能部１３２と拡張機能部と以外の機能部を、更に備えてもよい。また、拡張機能部は、アーキテクチャの第１例と同様に、他の機能に影響を与えずに追加、削除、入替又は変更が可能であることが好ましい。

基本機能部１３２は、各拡張機能部の一部として含まれていてもよいし、ミドルウェア１２０の下位で代替されてもよい。拡張機能部が基本機能部１３２を含む場合や、ミドルウェア１２０の下位が基本機能部１３２を代替する場合や、それらの組み合わせである場合、機器無依存アプリ１３０は基本機能部１３２を含まなくてもよい。
また、基本機能部１３２の一部もミドルウェア１２０の下位の機器依存アプリ部１６０で代替してもよい。管理・制御エージェント部１３３は、予め定められた設定に従って自動設定する場合、ＥＭＳ１４０との間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部１３３が備えず、他の機器無依存アプリ１３０や基本機能部１３２や機器依存部１１０が管理設定機能を備える場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。
ＥＭＳ１４０と機器無依存アプリ１３０とは、直接入出力してもよい。ミドルウェア１２０の下位が基本機能部１３２の全てを代替する場合、機器無依存アプリ１３０は、基本機能部１３２を備えなくてもよい。

図２に示す通信装置において、機器依存アプリ部１６０は、ミドルウェア１２０を介して情報を入出力してもよいし、管理・制御エージェント部１３３から情報を直接入出力してもよいし、両者のうちのいずれかとの間で情報を入出力してもよいし、ＥＭＳ１４０と直接入出力してもよい。また、機器依存アプリ部１６０が、ＥＭＳ１４０からの通信を受けずに、予め定められた設定に従って自動設定されており、ミドルウェア１２０を介してＥＭＳ１４０から管理及び制御情報を取得可能である場合、機器無依存アプリ１３０は、管理・制御エージェント部１３３を備えなくてもよい。

機器無依存アプリ１３０は、ミドルウェア１２０を介して少なくとも機器依存部１１０のハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２との間又はソフトウェア部との間で、情報を入出力する。機器無依存アプリ１３０は、必要に応じてミドルウェア１２０を介して、相互に入出力する。特に、機器無依存アプリ１３０は、ＥＭＳ１４０との間で入出力された情報に応じて制御又は管理を実行する場合、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３との間で、情報を入出力する。
ＮＥ管理・制御部１１５は、ミドルウェア１２０を介して管理・制御エージェント部１３３との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＥＭＳ１４０との間で、ＮＥ管理情報及び制御情報を直接入出力してもよい。

機器依存アプリ部１６０は、管理・制御エージェント部１３３との間で、ＮＥ管理情報及び制御情報を入出力している。機器依存アプリ部１６０は、管理・制御エージェント部１３３を介さずに、ＥＭＳ１４０との間で、情報を直接入出力してもよい。管理・制御エージェント部１３３は、ＥＭＳ１４０、ミドルウェア１２０及び機器依存アプリ部１６０との間で、情報を入出力する。ミドルウェア１２０は、ＮＥ管理・制御部１１５との間で、ＮＥ管理情報及び制御情報を入出力する。
ＮＥ管理・制御部１１５は、ミドルウェア１２０を介さずに、ＥＭＳ１４０との間で、ＮＥ管理情報及び制御情報を直接入出力してもよい。ミドルウェア１２０は、機器無依存アプリ１３０との間で、機器無依存ＡＰＩ２１を介して情報を入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２との間で、機器依存ＡＰＩ２３を介して情報を入出力する。

ミドルウェア１２０は、図１に示すミドルウェア１２０と同様に、そのまま又は所定の形式で入力する。機器無依存ＡＰＩ２１は、後から追加する拡張機能部を想定して、予めミドルウェア１２０に備えることが望ましいが、必要に応じて、機器依存ＡＰＩ２３や他の機器無依存アプリ１３０の改変を抑制する形で追加又は削除してもよい。

（アーキテクチャの第３例）
図３は、通信装置のアーキテクチャの第３例を示す図である。図３では、図１に示すアーキテクチャの第１例で説明したミドルウェア１２０の代わりに、基本機能部１３２が、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、拡張機能部との入出力を行う。その他の機器無依存アプリ１３０は、アーキテクチャの第１例と同様である。

アーキテクチャの第１例と比べて、第３例は、機器依存ＡＰＩを備えるミドルウェア１２０を、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかが異なる機器毎に作成する必要がない。これによって、アーキテクチャの第３例の通信装置は、機器間世代間でより多くの機能を汎用化して移植し易く、接続性の検証も容易で、機器の機能が堅牢となる効果がある。

アーキテクチャの第３例による通信装置は、機器依存部１１０と、機器無依存アプリ１３０とを備える。機器依存部１１０は、準拠する標準規格又は機器製造ベンダ等に依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等のソフトウェア部とを備える。ドライバ等は、機器依存部１１０の違いを隠蔽する。

機器無依存アプリ１３０は、拡張機能部と、基本機能部１３２とを備える。基本機能部１３２は、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との違いを隠蔽するドライバを介して、機器無依存ＡＰＩ２７（移植用ＩＦ）により機器依存部１１０と接続する。機器無依存アプリ１３０は、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との違いを隠蔽するドライバを介して、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェア部との間で、データを入出力する。

基本機能部１３２と拡張機能部とは、機器無依存ＡＰＩ２２（拡張用ＩＦ）を介して接続される。基本機能部１３２と機器依存部１１０とは、機器無依存ＡＰＩ２７を介して接続される。機器無依存アプリ１３０の内の基本機能部１３２が、ミドルウェア１２０の代わりに、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２や拡張機能部との間で、情報の入出力を行う。
機器無依存アプリ１３０は、必要に応じて基本機能部１３２を介して、相互に入出力する。機器無依存アプリ１３０の拡張機能部は、基本機能部１３２及び機器無依存ＡＰＩ２７を介して、情報を入出力する。基本機能部１３２は、機器無依存アプリ１３０と機器無依存ＡＰＩ２７を介して情報を入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器無依存ＡＰＩ２７とを介して情報を入出力する。

基本機能部１３２は、図１に示すミドルウェア１２０と同様に、そのまま又は所定の形式で運用情報を入力する。例えば、他の機器無依存アプリ１３０であれば、基本機能部１３２は、入力する形式の機器無依存ＡＰＩの形式にそれぞれに変換し、機器依存のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部であれば、入力する形式の機器無依存ＡＰＩの形式にそれぞれに変換してから、又は終端して所定の処理を施してから運用情報を入力する。入力の際に、基本機能部１３２は、それぞれの入力先に不要な入力情報を削除し、不足の情報があれば、他の機器無依存ＡＰＩや機器無依存ＡＰＩを介して収集して補足することが望ましい。しかし、基本機能部１３２は、入力先への入力を、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。

機器無依存アプリ１３０は、例えば、拡張機能部と、基本機能部１３２とを備える。機器無依存アプリ１３０は、拡張機能部と基本機能部１３２とのうち、いずれかを備えなくてもよい。機器無依存アプリ１３０は、拡張機能部と基本機能部１３２と以外の機能部を、更に備えてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリ１３０は、拡張機能部を備えなくてよい。

拡張機能部は、他の機能に影響を与えることなく独立に追加又は削除可能であることが好ましい。例えば、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を拡張機能部とする場合、拡張機能部が必要になった場合に、適宜追加し、不要となった場合に適宜削除し、変更に応じて入替又は変更してもよい。
機器無依存ＡＰＩ２２は、後から追加する拡張機能部を想定して、基本機能部１３２に予め備えることが望ましいが、必要に応じて、機器無依存ＡＰＩ２２、機器無依存ＡＰＩ２７、他の機器無依存アプリ１３０の改変を抑制する形で、追加又は削除してもよい。

（アーキテクチャの第４例）
図４は、通信装置のアーキテクチャの第４例を示す図である。アーキテクチャの第４例とアーキテクチャの第３例との違いは、通信装置が、基本機能部１３２の配下に、機器依存アプリ部１６０を備える点である。このように、アーキテクチャの第４例の通信装置は、機器依存アプリ部１６０を備えることで、基本機能部１３２の構成を簡易化できる効果がある。

図４に示す通信装置は、機器依存部１１０と、機器無依存アプリ１３０とを備える。機器依存部１１０は、準拠する標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２を駆動するドライバ、ファームウェア等のソフトウェア部と、機器依存部１１０の少なくとも一部分を駆動する機器依存アプリ部１６０とを有する。機器無依存アプリ１３０は、移植用ＩＦとハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器依存のソフトウェアとの違いを隠蔽するドライバを介して又は移植用ＩＦと機器依存アプリ部１６０とを介して、機器に依存しない処理を実行する汎用の機器無依存アプリ１３０である。機器無依存アプリ１３０内の基本機能部１３２と、機器依存部１１０内の機器依存アプリ部１６０とは、機器無依存ＡＰＩ２７を介して接続される。機器依存アプリ部１６０と機器依存部１１０は、機器依存ＡＰＩ２４を介して接続される。
機器無依存アプリ１３０内の基本機能部１３２は、ミドルウェア１２０の代わりに、基本機能部１３２がハード、拡張機能部との入出力を行う。基本機能部１３２の中に、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３相当を含んでいてもよいし、拡張機能部として管理・制御エージェント部１３３を備えてもよい。

基本機能部１３２は、機器無依存アプリ１３０と機器無依存ＡＰＩ２２（拡張用ＩＦ）を介して入出力し、機器依存部１１０のＯＡＭ部１１４、ドライバ、ファームウェア、ハードウェア部（ＰＨＹ）１１１及びハードウェア部（ＭＡＣ）１１２と機器無依存ＡＰＩ２７（移植用ＩＦ）と機器依存部１１０の差異を隠蔽する機器依存部１１０のドライバ又は機器依存アプリ部１６０と機器依存ＡＰＩ２４を介して入出力する。
基本機能部１３２は、図１に示すミドルウェア１２０と同様に、そのまま又は所定の形式で入力する。アーキテクチャの第３例と同様に、基本機能部１３２の中に、ＥＭＳ１４０からの通信を受ける管理・制御エージェント部１３３相当を含んでいてもよいし、拡張機能部として管理・制御エージェント部１３３を備えてもよい。

機器無依存アプリ１３０は、例えば、拡張機能部と、基本機能部１３２とを備える。機器無依存アプリ１３０は、アーキテクチャの第３例と同様に、拡張機能部と基本機能部１３２とのいずれかを備えなくてもよい。機器無依存アプリ１３０は、アーキテクチャの第３例と同様に、拡張機能部と基本機能部１３２と以外の機能部を、更に備えてもよい。
拡張機能部は、アーキテクチャの第３例と同様に、互いに独立に他の機能に影響を与えずに、追加、削除、入替又は変更が可能であることが好ましい。基本機能部１３２の一部は、機器依存アプリ部１６０で代替してもよい。機器依存アプリ部１６０は、情報を基本機能部１３２から直接入出力しているが、そのまま又は所定の変換の後に、基本機能部１３２を介さずにＥＭＳ１４０との間で情報を入出力してもよい。

機器無依存ＡＰＩ２２は、図１に示すアーキテクチャの第１例と同様に、後から追加する拡張機能部を想定して、基本機能部１３２に予め備えることが望ましいが、機器無依存ＡＰＩ２２、機器無依存ＡＰＩ２７、他の機器無依存アプリ１３０、機器依存アプリ部１６０又は機器依存ＡＰＩ２４の改変を抑制する形で、必要に応じて追加又は削除してもよい。

（アーキテクチャの第５例）
図５の右上図は、アーキテクチャの第５例を示す図である。図５の右下図はアーキテクチャの第１～第４例に相当する。本例では、通信装置は、既存／市中品ハードウェアと外付ハードウェアからなる。例えば既存／市中品ハードウェアは機器に依存する非汎用の機器依存部であり、外付ハードウェア上にハードウェアやソフトウェアの違いを隠蔽するミドルウェアと、動作が機器に依存しない汎用の機器無依存アプリとを備える。したがって、同図のミドルウェア以下の機器依存部（ベンダ依存部）は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存する機能部である。また、機器無依存アプリ１３０は、通信装置の機器が準拠する標準規格や機器の製造ベンダに依存しない機能部である。

ミドルウェアと機器無依存アプリとは、機器に依存しない入出力ＩＦである機器無依存ＡＰＩを介して接続される。機器依存部の例えば、ソフトウェア部、ＯＡＭ、ハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）と、外付ハードウェア上のミドルウェアとは、機器に依存する入出力ＩＦである機器依存ＡＰＩ及び既存／市中品ハードウェアと外付ハードウェア間の機器間接続を介して接続される。

本アーキテクチャでは機器無依存アプリによる拡張機能部（独自機能部）の柔軟及び迅速な追加を容易にし、通信サービスをタイムリーに提供することができる。ここで、機器依存部は、図５に示す保守運用、アクセス制御、物理層処理、光モジュルであってもよく、機器自体の構成による。

例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ等の更新頻度が高い機能又は通信サービス差異化に寄与する機能を優先して、機器依存部又は機器無依存アプリとすることを決めてもよい。更に、共用化を図る機器の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに関して差異の隔たりが小さいものから、機器無依存アプリとしてもよい。

準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの少なくともいずれかに対しては最適でない場合でも、準拠する標準規格、世代、方式、システム、機器種別、製造ベンダの機能のいずれかを汎用化するために、機能を実行するための共通ＩＦが用いられてもよい。共通ＩＦの中には、機器依存部の準拠する標準規格、世代、方式、システム、機器種別、製造ベンダのいずれかにおいて使用されないＩＦやパラメータが含まれていてもよい。

ミドルウェアと、機器依存部のドライバと、機器依存アプリ部（ベンダ依存アプリ部）との少なくともいずれかに、ＩＦやパラメータ等を機器依存部に対応するように変換する変換機能部や、不足するＩＦやパラメータ等に対応して自動設定する機能部を更に備えてもよい。
機器依存部は、ハードウェア部と、ソフトウェア部とを備える。ソフトウェア部は、機器依存のドライバ、ファームウェア、アプリケーション等を実行する。
機器依存部は、物理媒体に接続するＰＭＤ、ＭＡＣ、データのシリアル化を行うＰＭＡ、データを符号化する部分であるＰＣＳ又はＰＨＹの一部を備えなくてもよい。例えば、変復調信号処理、前方誤り訂正（ＦＥＣ）、符復号処理、暗号化処理等の低位の信号処理を備えずに光関連の機能のみを備えてもよい。

機器無依存アプリは、例えば、ＥＭＳからデータを取得する管理・制御エージェント部と、拡張機能部と、基本機能部とである。以下、拡張機能部に共通する事項については、符号の一部を省略して、「拡張機能部」と表記する。ＥＭＳは、例えば、ネットワーク・エレメントを制御するコントローラである。なお、機器無依存アプリは、管理・制御エージェント部と拡張機能部と基本機能部とのうちいずれかを含まなくてもよい。

機器無依存アプリは、管理・制御エージェント部、拡張機能部及び基本機能部以外の構成を、更に含んでいてもよい。例えば、拡張機能部が不要である場合、機器無依存アプリは、拡張機能部を備えなくてもよい。また、機器無依存アプリは、１個以上の拡張機能部を含んでもよい。
拡張機能部は、他の機能に不要な影響を与えずに独立して追加、削除、入替又は変更が可能であることが好ましい。例えば、拡張機能部は、サービス上の要求に合わせて、例えばマルチキャストサービス、省電力対応を実行する拡張機能部が必要になった場合、適宜に追加、削除、入替又は変更されてもよい。

基本機能部は、拡張機能部の一部として機器無依存アプリに含まれてもよいし、ミドルウェアよりも下位の機能部によって代替されてもよい。拡張機能部が基本機能部を含む場合、機器無依存アプリは基本機能部を含まなくてもよい。ミドルウェアよりも下位の機能部が基本機能部を代替する場合、機器無依存アプリは基本機能部を含まなくてもよい。拡張機能部が基本機能部を含み、ミドルウェアよりも下位の機能部が基本機能部を代替する場合、機器無依存アプリは基本機能部を含まなくてもよい。

管理・制御エージェント部は、ＥＭＳからの通信を受けずに、予め定められた設定に従って自動設定する場合、ＥＭＳと入出力しなくてよい。更に、管理・制御エージェント部が管理設定機能を備えず、他の機器無依存アプリや基本機能部や機器依存部が管理設定機能を備える場合、機器無依存アプリは、管理・制御エージェント部を備えなくてもよい。

ＥＭＳと機器無依存アプリとは、情報を直接入出力してもよい。また、機器依存部は、ＮＥ管理・制御部と、ＮＥ管理・制御部のＩＦとを備えなくともよい。
基本機能部は、拡張機能部の一部として機器無依存アプリに含まれてもよいし、ミドルウェアの下位の機能部によって代替されてもよい。拡張機能部が基本機能部を含む場合や、ミドルウェアの下位の機能部が基本機能部を代替する場合や、それらの組み合わせである場合、機器無依存アプリは基本機能部を含まなくてもよい。また、基本機能部の一部は、ミドルウェアの下位の機能部の機器依存アプリ部によって代替されてもよい。

管理・制御エージェント部は、予め定められた設定に従って自動設定する場合、ＥＭＳとの間で情報を入出力しなくてよい。更に、管理設定機能を管理・制御エージェント部が備えず他の機器無依存アプリや基本機能部や機器依存部が管理設定機能を備える場合、機器無依存アプリは、管理・制御エージェント部を備えなくてもよい。ＥＭＳと機器無依存アプリとは、情報を直接入出力してもよい。

機器無依存アプリと機器依存部との入出力の例は以下である。例えば、ＤＢＡアプリ部及びプロテクションアプリ部は、ＴＣレイヤのエンベデッドＯＡＭエンジンと、相互に情報を入出力する。ＤＷＢＡアプリ及びＯＮＵ登録認証アプリ部は、ＴＣレイヤのＰＬＯＡＭエンジンと、相互に情報を入出力する。省電力アプリ部は、ＯＭＣＩ及びＬ２主信号処理機能部（Ｌ２機能部）と相互に情報を入出力する。ＭＬＤプロキシアプリ部は、Ｌ２機能部と相互に情報を入出力する。低速監視アプリ（ＯＭＣＩ）は、ＯＭＣＩと相互に情報を入出力する。ＯＭＣＩ及びＬ２機能部は、ＸＧＥＭフレーマ及び暗号化を動作させる。ここで、ＤＷＢＡとＤＢＡは、別体、一体又は組み合わせでもよい。例えば、管理・制御エージェント部は、保守運用機能のアプリ部であり、ＮＥ管理・制御部のためのＮＥコントローラ等であるＥＭＳと、相互に情報を入出力する。

機器無依存アプリは、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＴＵ－Ｔ Ｇ．９８９シリーズに準拠するＴＷＤＭ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８７シリーズに準拠するＸＧ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８４シリーズに準拠するＧ－ＰＯＮと、ＩＴＵ－Ｔ Ｇ．９８３シリーズに準拠するＢＰＯＮとのいずれにもよらずに動作するアプリである。機器無依存アプリは、機器のベンダ、方式、機器種別、機器の世代、例えば、ＩＥＥＥ８０２．３ａｖやＩＥＥＥ１９０４．１等に準拠する１０ＧＥ－ＰＯＮとＩＥＥＥ８０２．３ａｈに準拠するＧＥ－ＰＯＮ等の差異の少なくともいずれかに依らずに動作するアプリである。

拡張機能部のアプリとして、機器無依存ＡＰＩを介して、一部のベンダ、方式、種別、世代に備える機能を駆動するためのアプリや、一部のベンダ、方式、種別、世代の装置のみに備える機能を駆動するアプリを含んでいてもよい。
管理・制御エージェント部は、ＥＭＳ及びミドルウェアと入出力する。ミドルウェアは、ＮＥ管理・制御部との間で、ＮＥ管理情報及び制御情報を入出力する。ＮＥ管理・制御部は、ミドルウェアを介さずに、ＮＥ管理情報及び制御情報をＥＭＳと直接送受信してもよいし、管理・制御エージェント部を介して、ＮＥ管理情報及び制御情報を送受信してもよい。

ミドルウェアは、機器無依存アプリと機器無依存ＡＰＩを介して情報を入出力する。ミドルウェアは、機器依存ＡＰＩを介して、機器依存部のＯＡＭ部、ドライバ、ファームウェア、ハードウェア部又はハードウェア部と情報を入出力する。ミドルウェアは、入力した情報を、そのまま又は所定の形式で出力する。例えば、ミドルウェアは、出力先が機器無依存アプリの各部であれば、機器無依存ＡＰＩの各部の入力形式に情報を変換する。出力先が機器依存部のＯＡＭ部、ドライバ、ファームウェア、ハードウェア部又はハードウェア部であれば、ミドルウェアは、それぞれに入力する形式の機器依存ＡＰＩの形式に変換してから、又は終端して所定の処理を施してから情報を出力先に送信する。

ミドルウェアは、入力の際に、それぞれの入力先に不要な入力情報は削除し、不足の情報があれば、他の機器無依存ＡＰＩや機器依存ＡＰＩを介して収集して補足することが望ましい。また、ミドルウェアへの入力の際に、ブロードキャスト又はマルチキャストして、関連するアプリ等に同報することとしてもよい。
ミドルウェアや機器依存部は単一で例示したが、それぞれ複数から構成されていてもよい。機器依存部のハードウェアに複数のプロセッサが含まれる場合、ミドルウェアはプロセッサやハードウェアをまたいでプロセッサ間通信等を用いて入出力してもよい。機器無依存アプリ間や機器無依存アプリをＤＬＬのような実行プログラムとして、単一のプロセッサ上のユーザ空間上に配置してもよいし、複数のプロセッサ上のユーザ空間上に配置してもよい。

また、機器無依存アプリは、ＡＰＩ等の入出力ＩＦを確保した上でカーネル空間に配置してもよいし、独立にファームウェア等に入替可能なＩＦを有するミドルウェアとともに配置してもよいし、ファームウェア等に組み込んでコンパイルし直してもよい。機器無依存アプリ毎にユーザ空間やカーネル空間を任意の組み合わせとしてもよい。
同一の機能に対応する機器無依存アプリを、ユーザ空間とカーネル空間の両方で実装可能としてもよい。この場合、例えば、切り替えていずれかを選択してもよいし、両方協働して処理してもよいし、一方のみで実処理を行うとしてもよい。機器依存部のソフトウェアも同様である。

望ましくは、主信号処理やＤＢＡ処理や低レイヤの信号処理のように高速処理が必要であるほど、拡張性・入替の即時性とトレードオフはあるが、オーバーヘッドが少なく高速な処理が期待されるカーネル空間やファームウェアに組み込むことが望ましい。機器依存アプリ部を配置するプロセッサもプロセッサ間通信によるバスや速度等の制限、通信路の占有等による他のプログラムへの影響の観点から、実処理を行うプロセッサ又はその近傍のプロセッサのユーザ空間やカーネル空間やファームウェア上に配置することが望ましい。ただし、実処理を行うプロセッサ又はその近傍のプロセッサの能力を軽減するためにはプロセッサ間通信によるコミュニケーションコストは増大するが、遠隔のプロセッサで処理するとしてもよい。

機器無依存ＡＰＩは、追加する拡張機能部を想定してミドルウェアに予め備えられることが望ましいが、機器依存ＡＰＩや他の機器無依存アプリの改変を抑制する形で、必要に応じて追加又は削除されてもよい。

（アーキテクチャの第６例）
アーキテクチャの第６例は、機器依存部として準拠する標準規格又は機器製造ベンダに依存するハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）と、ハードウェア部（ＰＨＹ）及びハードウェア部（ＭＡＣ）を駆動するドライバ・ファームウェア等のソフトウェア部と、機器依存部の少なくとも一部分を駆動する機器依存アプリ部とを備える。

機器依存アプリ部及び機器依存部は、機器依存ＡＰＩを介して接続される。機器依存アプリ部の中に、ＥＭＳからの通信を受ける管理・制御エージェント部相当を含んでいてもよい。機器依存ＡＰＩは、機器依存アプリ部及び機器依存ＡＰＩの改変を抑制する形で、必要に応じて追加又は削除されてもよい。

なお、通信装置のアーキテクチャの第１例～第６例に示す通信装置の構成は、ＴＷＤＭ－ＰＯＮのようなＩＴＵ－Ｔ勧告準拠のＰＯＮのＯＬＴを前提に記載しているが、ＯＮＵであってもよく、ＴＷＤＭ－ＰＯＮ以外のＩＴＵ－Ｔ勧告準拠のＰＯＮのＯＬＴ又はＯＮＵのいずれかであってもよいし、ＧＥ－ＰＯＮ、１０ＧＥ－ＰＯＮ等のＩＥＥＥ規格準拠のＰＯＮであってもよく、ＴＣレイヤ又はＰＭＤレイヤは対応する層に読み替えれば同様である。

以下、ＴＷＤＭ－ＰＯＮが、ＰＯＮマルチキャスト機能と、省電力制御機能と、周波数・時刻同期機能と、プロテクション機能と、保守運用機能と、Ｌ２主信号処理機能と、ＰＯＮアクセス制御機能と、ＰＯＮ主信号処理機能とを主に有する場合を例に説明する。以下、ＰＯＮマルチキャスト機能と、省電力制御機能と、周波数・時刻同期機能と、プロテクション機能と、保守運用機能と、Ｌ２主信号処理機能と、ＰＯＮアクセス制御機能と、ＰＯＮ主信号処理機能とを、「主要８機能」という。

図６は、通信装置及び外部サーバ１６の構成の例を示す図である。通信システムは、通信装置と、外部サーバ１６とを備える。通信装置は、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、プロキシ部１５との少なくとも一部を備える。なお、通信装置は、外部サーバ１６を備え得る。
図６では、異なる波長（λＡ～λＮ）の光信号を送受信（通信）する送受信部１１が同一のスイッチ部１２に接続されている構成を示すが、実施形態１－１はこれに限定されない。例えば、異なる波長（λＡ～λＮ）の光信号を送受信する送受信部１１が同一のスイッチ部１２に接続されている構成に加えて、同一の波長の光信号を送受信する送受信部１１が同一のスイッチ部１２に接続されていてもよいし、異なる波長（λＡ～λＮ）の光信号を送受信する送受信部１１の内で少なくとも一部の波長の送受信部１１が複数同一のスイッチ部１２に接続されていてもよいし、送受信部１１の内の一部又は全てが送信のみ又は受信のみ行う送受信部１１であってもよい。

ＯＬＴなどの通信装置は、送受信部１１から制御部１４を備えていてもよいし、これらに加えて外部サーバ１６を更に、備えてもよい。また、ＯＳＵは、送受信部１１でもよいし、これに加えてスイッチ部１２（ＳＷ）又はスイッチ部１３（ＳＷ）を備えてもよい。
通信システム構成（１－１）の通信システムは、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、プロキシ部１５と、外部サーバ１６とを備える（図６）。

通信装置がＯＬＴである場合、ＯＬＴは、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）と、スイッチ部１３（ＳＷ）と、制御部１４と、外部サーバ１６とから構成してもよい。ＯＳＵは、送受信部１１（ＴＲｘ）とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１２（ＳＷ）とから構成してもよいし、送受信部１１（ＴＲｘ）と、スイッチ部１３（ＳＷ）とから構成してもよい。
異なる波長（λＡ～λＮ）の光信号を送受信する送受信部１１（ＴＲｘ）がスイッチ部１２に接続されている。送受信部１１（ＴＲｘ）は、自律制御を行い、又は、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。送受信部１１（ＴＲｘ）は、ＯＤＮ（Ｏｐｔｉｃａｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）若しくはスイッチ部１２（ＳＷ）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、又は、タグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一つ又はその組み合わせの処理を行う。

なお、上りトラフィックに関しても集約されるとは限らない。スイッチ部１２（ＳＷ）は通信システム構成（１－１）の構成では波長毎の振分が主であるが、集約、分配、複製、折返、透過、ＶＩＤ（Ｖｉｒｔｕａｌ ＬＡＮ Ｉｄｅｎｔｉｆｉｅｒ）や優先廃棄を表すタグ等のタグ付加又はタグ付替を行ってもよい。後述する通信システム構成（１－２）の構成では、上りトラフィックは集約が主であるが、分配、振分、複製、折返、透過、タグ付加又はタグ付替を行ってもよい。下りトラフィックも集約、分配、振分、複製、折返、透過、タグ付加又はタグ付替のいずれかを行ってもよく、少なくとも一部の組み合わせを行ってもよい。そのいずれとするかはサービスポリシーに応じて決定する。これは以降の通信システム構成でも同様である。

スイッチ部１２（ＳＷ）は、スイッチ部１３（ＳＷ）に接続される。スイッチ部１２（ＳＷ）は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。スイッチ部１２（ＳＷ）は、送受信部１１（ＴＲｘ）若しくはスイッチ部１３（ＳＷ）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、又は、タグの変更無で、集約、分配、振分、複製、折返、透過若しくはタグ付加又はタグ付替の少なくとも一部又はその組み合わせの処理を行う。これは以降の通信システム構成でも同様である。

なお、スイッチ部１２（ＳＷ）は、制御されるとは限らない。送受信部１１からプロキシ部１５の少なくとも一つが制御される場合と、制御されずに送受信部１１からプロキシ部１５の少なくとも一つに制御情報が転送される場合とがある。転送元としては例えばプロキシ部１５又は外部サーバ１６がある。また、送受信部１１からプロキシ部１５が自律で動く場合もある。これは以降の通信システム構成でも同様である。

スイッチ部１３（ＳＷ）は、プロキシ部１５に直接、又は集線ＳＷ等を介して接続される。この集線ＳＷは、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約、分配、振分、複製、折返若しくは透過の少なくとも一部を行う。スイッチ部１３（ＳＷ）は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。スイッチ部１３（ＳＷ）は、スイッチ部１２（ＳＷ）若しくはプロキシ部１５のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、若しくは、タグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一部又はその組み合わせの処理を行う。

制御部１４は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５又は外部サーバ１６又は外部のオペレーションシステム（不図示）、コントローラ（不図示）若しくは外部の装置（不図示）と接続される。制御部１４は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を制御し、又は送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素を介して、指示を転送する。

図６に示すプロキシ部１５は、ＯＬＴから若しくはＯＬＴへのデータ経路上に設置してもよい。ただし、間に他の装置（例えば、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約／分配する集線ＳＷ等）が介在する場合があるので、直接接続されるとは限らない。制御の流れとしては、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、外部サーバ１６のいずれに、プロキシ部１５があってもよい。

プロキシ部１５は、上位側の装置（不図示）に直接、又は集線ＳＷ等を介して接続される。この集線ＳＷは、複数のＯＬＴから若しくはＯＬＴへのトラフィックに集約、分配、振分、複製、折返若しくは透過の少なくとも一部を行う。プロキシ部１５は、自律制御を行い、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４若しくは外部サーバ１６等の他の構成要素から制御され、又は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４若しくは外部サーバ１６等の他の構成要素を介して転送された指示で制御される。プロキシ部１５は、スイッチ部１３（ＳＷ）若しくは上位側の装置（不図示）のトラフィックの一部又はその全てに、所定の手順に従って、ＶＬＡＮ、優先、廃棄優先若しくは宛先等の少なくとも一部又はその組み合わせのタグの追加、削除、付替をして、若しくはタグの変更無で、集約、分配、振分、複製、折返若しくは透過の少なくとも一部又はその組み合わせの処理を行う。

外部サーバ１６は、送受信部１１（ＴＲｘ）又はスイッチ部１２（ＳＷ）又はスイッチ部１３（ＳＷ）又は制御部１４又はプロキシ部１５又は外部のオペレーションシステム（不図示）又はコントローラ（不図示）若しくは外部の装置（不図示）と接続される。外部サーバ１６は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）若しくは制御部１４若しくはプロキシ部１５等の他の構成要素を制御し、又は送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）若しくは制御部１４若しくはプロキシ部１５等の他の構成要素を介して指示を転送する。

送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、制御部１４、プロキシ部１５若しくは外部サーバ１６は、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素のトラフィックの一部又はその全てそれ自体又はその複写を受けて、受けたトラフィックの一部、その全て自体、受けたトラフィックの一部、全てを書き換えたトラフィック又は受けたトラフィックに対する応答を、送受信部１１（ＴＲｘ）、スイッチ部１２（ＳＷ）、スイッチ部１３（ＳＷ）、プロキシ部１５若しくは外部サーバ１６等の他の構成要素、外部のオペレーションシステム（不図示）、コントローラ（不図示）又は外部の装置（不図示）に送信してもよい。

なお、要素は適宜含まなくてもよいし、含まない要素とのやりとりは例えば、スキップしてその先の要素とやりとりする。同士をハブ遺体相手同士で通信してもよい。
通信システム構成（１－２）の通信システムでは、通信システム構成（１－１）の構成に対して更に、異なる波長の代わりに同一の波長の光信号を送受信する送受信部１１（ＴＲｘ）（λＡ～λＡ）、送受信部１１（ＴＲｘ）（λＢ～λＢ）、…、送受信部１１（ＴＲｘ）（λＮ～λＮ）が、スイッチ部１２にそれぞれ接続されている。更に、異なる波長の送受信部１１の内の少なくとも一部の波長の送受信部１１がスイッチ部１２に複数接続されていてもよい。他は同様である。

図７に係る光アクセスシステムでは、ＩＴＵ－Ｔ Ｇ．９８９シリーズに準拠する。図７において、コントローラと外部装置はＯＬＴに含まれないが、ＦＡＳＡアプリケーションＡＰＩとの通信を例示するために記載する。論理モデルは、ＦＡＳＡアプリケーションと、ＦＡＳＡアプリケーションにＦＡＳＡアプリケーションＡＰＩを提供するＦＡＳＡ基盤とから構成される。ＦＡＳＡ基盤はＦＡＳＡアプリケーション用ミドルウェアを含む。ＦＡＳＡアプリケーションＡＰＩ用ミドルウェアは、ＦＡＳＡ基盤を構成するハードウェアやソフトウェアのベンダや方式の違いを吸収する。ＦＡＳＡアプリケーションＡＰＩ用ミドルウェア上にベンダや方式に依存しないＦＡＳＡアプリケーションＡＰＩセットを規定し、ＦＡＳＡアプリケーションの入替により、サービス毎あるいは通信事業者毎に必要な機能を実現する。ＦＡＳＡアプリケーション間の通信やコントローラ等による設定管理はＦＡＳＡアプリケーションＡＰＩ用ミドルウェアを介して行う。なお、ＦＡＳＡアプリケーションＡＰＩ用ミドルウェアを介さないこともありうる。ＦＡＳＡアプリケーションＡＰＩセットは、ＦＡＳＡアプリケーションで利用する共通のＡＰＩ群であり、ＦＡＳＡアプリケーション毎に必要なＡＰＩをＡＰＩセットから選択して利用する。

以下に示す接続関係は例であり、間に介在する接続は介在しない接続であってもよいし、複数の接続関係の一部のみ接続していてもよく、それ以外の接続であってもよい。これは他の説明も同様である。これは他の説明も同様である。ＮＥコントローラとして機能するＥＭＳは、ＮＥ－ＯｐＳ等のＯＬＴの設定管理システムであり、ミドルウェアを介して、ＩＦ変換アプリを介して設定管理アプリケーション(例えば、低速監視アプリ（ＥＭＳ－ＩＦ）及び設定・管理アプリ)が配置されている。ＩＦ変換アプリは、ＮＥコントローラ等のＥＭＳからＯＬＴ等のNetwork Entityに対する制御ＩＦであるＳＢＩ（South Band Interface）のコマンドを変換するＳＢＩアプリに相当する。ここでＩＦ変換アプリがＩＦ変換するとしているが低速監視アプリ（ＥＭＳ－ＩＦ）及び設定・管理アプリにて、ＩＦ変換を行う又はＩＦ変換を行う必要のないＡＰＩを備えれば、ＩＦ変換アプリは備えなくともよい。Ｌ２（レイヤ２）機能と接続された低速監視アプリ（ＥＭＳ－ＩＦ）と設定・管理アプリはミドルウェアを介して、ＥＭＳやＮＥ管理等を行うＮＥ制御・管理と接続されている。低速監視アプリ（ＯＭＣＩ）、ＭＬＤプロキシアプリ（マルチキャストアプリ）及び省電力アプリは、ミドルウェアを介してそれぞれＬ２機能と接続されている。

プロテクションアプリは、ミドルウェアを介してPLOAM EngineとEmbedded OAM Engineと接続されている。省電力アプリは、ミドルウェアを介してＯＭＣＩとPLOAM Engineと接続されている。ＯＮＵ登録認証アプリ及びＤＷＢＡアプリはミドルウェアを介してPLOAM Engineと接続され、ＤＢＡアプリはミドルウェアを介してEmbedded OAM Engineと接続されている。省電力アプリは、ミドルウェアを介してプロテクションアプリとＯＮＵ登録認証アプリとＤＷＢＡアプリとＤＢＡアプリ間でそれぞれ動作させてもよい。外部の装置からの入力はミドルウェアを介してＤＢＡアプリに接続している。なおこれらの接続は、例であり、外部の装置からの入力をＤＢＡアプリ以外の他のアプリ例えばプロテクションアプリやＤＷＢＡアプリに接続してもよい。また外部の装置からの入力をミドルウェア経由でＩＦ変換アプリを介してＩＦ変換したり、ミドルウェア経由で設定・管理アプリを介してＤＢＡアプリ等に接続したりしてもよい。

図８は、通信装置内の機能部間の信号／情報の流れを示す図である。同図に示す通信装置は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）と、Ｌ２主信号処理機能部３４０と、ＰＯＮマルチキャスト機能部３５０と、省電力制御機能部３６０と、周波数・時刻同期機能部３７０と、プロテクション機能部３８０とを備える。

ＰＯＮ主信号処理機能部３００は、ＰＯＮ主信号処理機能を有する。ＰＯＮ主信号処理機能は、ＯＮＵとの間で送受信を行う主信号を処理する機能群であり、ＰＯＮフレームの生成分離や前方誤り訂正（ＦＥＣ：Forward Error Correction）等を含む。ＰＯＮアクセス制御機能部３２０は、ＰＯＮアクセス制御機能を有する。ＰＯＮアクセス制御機能は、前述の主信号送受信を行うための制御機能群であり、動的帯域割当やＯＮＵの登録認証等を含む。

保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）は、保守運用機能を有する。保守運用機能は、アクセス装置によってサービスを円滑に保守運用するための機能群であり、ＯＮＵやＯＬＴ（ＯＳＵ及びスイッチ）の装置設定を実施する機能や、ソフトウェアの更新、装置やサービスの管理、各種機能が正常に動作しているかを監視する機能、異常発生時に能動的に警報を発出する機能、異常発生時の範囲や原因を調査するための試験機能等を含む。また、保守運用機能は、多数のアクセス装置を管理する保守運用システムと接続され、リモートからも円滑な保守運用を実現する。

Ｌ２主信号処理機能部３４０は、Ｌ２主信号処理機能を有する。Ｌ２主信号処理機能は、ＰＯＮ側ポートとＳＮＩ側ポートとの間で主信号を転送し、処理する機能群であり、ＭＡＣアドレス学習やＶＬＡＮ制御、優先制御やトラフィックモニタ等の機能を含む。ＰＯＮマルチキャスト機能部３５０は、ＰＯＮマルチキャスト機能を有する。ＰＯＮマルチキャスト機能は、ＳＮＩ側から受信したマルチキャストストリームを適切なユーザに転送する機能群であり、マルチキャストストリームの識別や振分し、ＯＮＵのフィルタ設定を実施する機能を含む。

省電力制御機能部３６０は、省電力制御機能を有する。省電力制御機能は、ＯＮＵやＯＬＴの電力消費を削減するための機能群であり、標準化で規定されている省電力化機能に加え、トラフィックモニタとの連携によってサービスへの影響を最小限に抑えながら、最大限の効果を得るための機能を含む。周波数・時刻同期機能部３７０は、周波数・時刻同期機能を有する。周波数/時刻同期機能は、ＯＮＵ配下の装置に正確な周波数同期や時刻同期を提供するための機能群であり、自身のリアルタイムクロックを上位装置に従属同期させる機能や、ＰＯＮフレームを用いてＯＮＵに時刻情報を通知する機能を含む。

プロテクション機能部３８０は、プロテクション機能を有する。プロテクション機能は、スイッチ間やＯＳＵ間等、複数のハードウェアで冗長をとった構成において、障害検知時に現用系から予備系への切替や引継を実施してサービスを継続するための機能群であり、切替トリガの検出や切替処理の実施といった機能を含む。また、プロテクション機能は障害検知時や手動での切替時に、サービスを全面停止せず縮退運転で動作させ続けるための機能を提供する。ＰＭＤ部３１０は、主要８機能以外の機能を有する。

ＰＯＮ主信号処理機能部３００は、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０（ＰＬＯＡＭ処理、ＯＭＣＩ処理）と、Ｌ２主信号処理機能部３４０とに接続されていてもよい。ＰＯＮマルチキャスト機能部３５０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。省電力制御機能部３６０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。周波数・時刻同期機能部３７０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。プロテクション機能部３８０は、ＰＯＮ主信号処理機能部３００と、ＰＭＤ部３１０と、ＰＯＮアクセス制御機能部３２０と、保守運用機能部３３０と、Ｌ２主信号処理機能部３４０とからなる群に接続していてもよい。

図９は、ＰＯＮ主信号処理機能部３００が有する機能構成の例を示す図である。ＰＯＮ主信号処理機能部３００は、上り信号の処理順（下り信号の処理は逆方向）に、ＰＨＹアダプテーションと、フレーム化と、サービスアダプテーションとを、ＰＯＮ主信号処理機能を構成する処理として備えていてもよい。これらの処理は、基本処理から構成されてもよい。基本処理は、同期ブロック生成／抽出と、スクランブル／デスクランブルと、ＦＥＣデコード／エンコードと、フレーム生成／分離と、ＧＥＭ（Ｇ－ＰＯＮ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｍｅｔｈｏｄ）カプセル化と、フラグメント処理と、暗号化とである。

ＰＨＹアダプテーションは、同期ブロック抽出と、デスクランブルと、ＦＥＣデコーディングとを、上り信号の処理順に備えていてもよい。ＰＨＹアダプテーションは、ＦＥＣエンコーディングと、スクランブルと、同期ブロック生成とを、下り信号処理の順番で備えていてもよい。
ＰＯＮ主信号処理機能部３００は、ＰＨＹアダプテーション、フレーム化又はサービスアダプテーションの処理を備えずに、同等の処理を基本処理の組み合わせで実現してもよい。ＰＨＹアダプテーション、フレーム化又はサービスアダプテーションの処理は、順番が入れ替わっていてもよい。ＰＨＹアダプテーションは、例えば、ＦＥＣ処理をＰＨＹアダプテーション以外に備えてもよい。

ＰＯＮ主信号処理機能部３００の主要機能では、１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長ごとに処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が複数波長を処理するなら、複数波長分が求められる。

図１０は、ＰＯＮアクセス制御機能部３２０が有する機能構成の例を示す図である。ＰＯＮアクセス制御機能部３２０が有するＰＯＮアクセス制御機能を構成する処理として、ＯＮＵ登録又は認証、ＤＢＡ、及び、λ設定切替（ＤＷＡ）を有する。これらの処理は、基本処理から構成されてもよい。例えば、ＯＮＵ登録又は認証は、初期処理を構成するレンジング、認証削除、登録、起動停止、ＤＢＡは帯域要求受信、トラフィック測定、履歴保持、割当計算、割当処理、設定切替計算、設定切替処理、設定切替状況把握の全て又はそのいくつか、λ設定切替は、帯域要求受信、トラフィック測定、履歴保持、割当計算、割当処理、設定切替計算、設定切替処理、設定切替状況把握の全て又はそのいくつかから構成されてもよい。ＯＮＵ登録又は認証、ＤＢＡ、λ設定切替（ＤＷＡ）は備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

ＰＯＮアクセス制御機能部３２０の主要機能では、ＯＮＵ高速起動、ＤＢＡ周期内でのＢＷＭａｐ、無瞬断λ設定切替等が必要に応じて求められる。機能分担の例として、登録又は認証としては、タイムクリティカルなレンジング処理を機器依存部、その後の認証や鍵交換をアプリとしてもよい。ＤＢＡ・λ設定切替では、単純な繰り返し処理を機器依存部、理想状態への反映をアプリとしてもよい。
図１１は、Ｌ２主信号処理機能部３４０が有する機能構成の例を示す図である。Ｌ２主信号処理機能部３４０が有するＬ２主信号処理機能を構成する処理として、ＭＡＣ学習、ＶＬＡＮ制御、パス制御、帯域制御、優先制御、遅延制御、Ｃｏｐｙを有する。これらの処理は基本処理であるアドレス管理、Ｃｌａｓｓｉｆｉｅｒ（クラシファイア、分類部）、Ｍｏｄｉｆｉｅｒ（モディファイア、変更部）、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ（ポリサー／シェイパ）、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ（クロス・コネクト）、Ｑｕｅｕｅ（キュー）、Ｓｃｈｅｄｕｌｅｒ（スケジューラ）、Ｃｏｐｙ（コピー）、トラフィックモニタから構成されてもよい。ＭＡＣ学習、ＶＬＡＮ制御、パス制御、帯域制御、優先制御、遅延制御、Ｃｏｐｙは備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

Ｌ２主信号処理機能部３４０の主要機能では、１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長ごとに処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が、複数波長を処理するなら複数波長分が求められる。

図１２は、保守運用機能部３３０が有する機能構成の第１例を示す図である。保守運用機能部３３０が有する保守運用機能を構成する処理として、ＯＮＵ、ＯＳＵ、ＯＬＴ又はＳＷの装置設定（手動、一括、自動、オペレーション契機）、設定バックアップ、ＦＷ更新、装置制御（リセット）、冗長構成対応を有する。これらの処理は、基本処理であるＣＬＩ－ＩＦ、装置管理ＩＦ、オペレーションＩＦ、汎用Ｃｏｎｆｉｇ（コンフィグ）－ＩＦ（ＮＥＴＣＯＮＦ、ＳＮＭＰなど）、テーブル管理から構成されてもよい。装置設定、設定バックアップ、ＦＷ更新、装置制御、冗長構成対応は備えずに同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

保守運用機能部３３０の主要機能では、指示を受けてからＡＣＫ送信まで１００ミリ秒以内、指示を受けてから反映完了通知送信まで２００ミリ秒以内（ただし、データ転送を含む設定バックアップとＦＷ更新は規模（サイズ・ユーザ数）に応じて規定。）等の規定に従うことが求められる。機能分担の例としては、ハードのＣｏｎｆｉｇを除きアプリとし、ソフトや設定データはＯＮＵやＯＬＴで持たずに図６の外部サーバ１６上のアプリとすることもできる。コマンドの統一とシーケンスの定義をすることで実現することもできる。

図１３は、保守運用機能部３３０が有する機能の構成の第２例を示す図である。保守運用機能部３３０が有する機能を構成する処理として、装置の状態監視（ＣＰＵ／メモリ／電源／切替）、トラフィック監視、警報監視（ＯＮＵ異常、ＯＬＴ異常）、試験（ループバック）を有する。これらの処理は基本処理である警報通知、ログ記録、Ｌ３パケット生成／処理、テーブル管理から構成されてもよい。装置の状態監視、トラフィック監視、警報監視、試験は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

保守運用機能部３３０の主要機能では、レイテンシが１００ミリ秒以内等の規定に従うことが求められる。機能分担の例として、通知／表示のＩＦのみアプリとし、モニタが必要な項目（ＣＰＵ負荷、メモリ利用量、電源状態、消費電力、イーサネット（登録商標）のリンク状態など）は機器依存部であり、機器依存部からの通知読み出し、通知のネットワーク（ＮＷ）送信、ファイルへの書き込みなどのＩＦをきるアプリによる処理とすることもできる。

図１４は、保守運用機能部３３０が有する機能構成の第３例を示す図である。保守運用機能部３３０が有する保守運用機能を構成する処理として、高速を要する監視・制御の入出力（スリープ指示／返答、λ設定切替指示／返答など）を有する。本処理の手段として、物理層ＯＡＭ（ＰＬＯＡＭ：Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ ＯＡＭ）メッセージ、及び、ヘッダ内のビット表示（Ｅｍｂｅｄｄｅｄ ＯＡＭ）を利用する。これらの処理は基本処理であるＰＬＯＡＭ処理、Ｅｍｂｅｄｄｅｄ ＯＡＭ処理、省電力制御機能部３６０との通信、プロテクション機能部３８０との通信、ＰＯＮアクセス制御機能部３２０との通信から構成されてもよい。高速を要する監視・制御の入出力は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。保守運用機能部３３０の主要機能では、ＰＬＯＡＭ処理を７５０マイクロ秒以内とする等の規定に従うことが求められる。

図１５は、ＰＯＮマルチキャスト機能部３５０が有する機能構成の例を示す図である。ＰＯＮマルチキャスト機能部３５０が有するＰＯＮマルチキャスト機能を構成する処理として、マルチキャストストリームの識別又は振り分け、ＭＬＤプロキシ／スヌーピング、ＯＮＵフィルタ設定、波長間設定移行を有する。これらの処理は基本処理であるＬ２識別・振り分け、Ｌ３パケット処理（ＩＰｖ６ Ｐａｒｓｅを備えるのが望ましい）、Ｌ３パケット生成、テーブル管理、ＯＭＣＩ機能との通信から構成されてもよい。マルチキャストストリームの識別又は振り分け、ＭＬＤプロキシ／スヌーピング、ＯＮＵフィルタ設定、波長間設定移行は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

ＰＯＮマルチキャスト機能部３５０の主要機能では、識別／振り分けを１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λの処理をそれぞれ波長毎に処理する場合、それぞれ１０Ｇｂｉｔ／ｓ／λと２．５Ｇｂｉｔ／ｓ／λ以上のストリーム処理が、複数波長を処理するなら複数波長分が求められる。さらに、ＰＯＮマルチキャスト機能部３５０の主要機能では、パケット処理としてザッピング性能（Ｚａｐｐｉｎｇ性能）（ＪＯＩＮレイテンシ）が、平均１．５秒以内等の規定に従うことが求められる。
機能分担の例としては、マルチキャスト（ＭＣ）ストリームの識別・振分は高速な処理能力を持つＣＰＵ等であればソフト処理可だが、ハード＋ｃｏｎｆｉｇが望ましい。その他、上りに対するアプリ系やＯＮＵ設定は頻度や遅延制約が緩いためアプリによる処理とするである。

図１６は、省電力制御機能部３６０が有する機能構成の例を示す図である。省電力制御機能部３６０が有する機能を構成する処理として、スリープ用プロキシ／トラフィックモニタ、ＯＮＵ波長設定、波長間設定移行を有する。これらの処理は基本処理であるＬ３パケット処理（ＩＰｖ６ Ｐａｒｓｅを備えるのが望ましい）、Ｌ３パケット生成、テーブル管理、ＯＳＵ省電力ステートダイアグラム（ＳＤ：Ｓｔａｔｅ Ｄｉａｇｒａｍ）、ＯＭＣＩ機能との通信から構成されてもよい。スリープ用プロキシ／トラフィックモニタ、ＯＮＵ波長設定、波長間設定移行は同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。
本主要機能では、送受信立ち上がり時間（受信器／送信器）を１０ミリ秒／５ミリ秒、立ち上がり時間（ＬＣ／ＯＳＵ／ＯＬＴ）を１００ミリ秒／１秒／１０秒等の規定に従うことが求められる。

機能分担の例として、パワーセーブ（ＰＳ：Ｐｏｗｅｒ Ｓａｖｅ）アプリや、信号によってはプロキシ処理もアプリによる処理とすることもできる。省電力制御状態遷移管理（ドライバ部）は速度が求められるがアプリによる処理とすることもできる。トラフィックモニタはコンフィグ（ｃｏｎｆｉｇ）のみアプリによる処理とすることもできる。

図１７は、周波数・時刻同期機能部３７０が有する機能構成の例を示す図である。ＯＬＴは、ＳｙｎｃＥ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｅｔｈｅｒｎｅｔ（登録商標））（周波数同期用）及びＩＥＥＥ １５８８ｖ２（時刻同期）により、自身のリアルタイムクロック（ＲＴＣ）を上位装置に従属同期させる。更に、ＯＭＣＩを利用して、ＰＯＮのスーパーフレームカウンタ（ＳＦＣ）と絶対時刻（ＴｏＤ：Ｔｉｍｅ ｏｆ Ｄａｙ）情報の対応をＯＮＵに通知する。これらの処理は基本処理であるリアルタイムクロックの保持等から構成されてもよい。同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

本主要機能では、周波数同期精度＋／－５０ｐｐｂ（ＬＴＥ ＦＤＤ、同ＴＤＤ）、時刻同期精度＋／－１～１．５マイクロ秒（ＬＴＥ ＴＤＤ、スモールセル）、＋／－１マイクロ秒（Ｇ．９８７．３）等の規定に従うことが求められる。機能分担の例としては、リアルタイムクロック自体は機器依存部であり、上位装置への時刻合わせ計算はアプリによる処理とすることもできる（精度により機器依存部とすることもできる）。

図１８は、プロテクション機能部３８０が有するプロテクション機能を構成する処理として、冗長切替（ＣＴ、ＳＷ、ＮＮＩ、ＣＯＮＴ、ＰＯＮ（Ｔｙｐｅ Ａ、Ｂ、Ｃ））を備える。これらの処理は基本処理である冗長パス設定、 切替トリガ検出、切替通知送受信、切替処理等から構成されてもよい。同等の処理を基本処理の組み合わせで実現してもよい。また、順番が入れ替わっていてもよい。

本主要機能では、強制切替は５０ミリ秒以下等の規定に従うことが求められる。機能分担の例としては、故障検出等のハードの切替トリガ検出と切替処理を除きアプリによる処理とすることもできる。冗長パスを予め設定せずに、切替トリガ検出時にＥＭＳ側へ（から）指示する場合は機器依存、等である。

なお、主要８機能は必要に応じて備えればよく、例えばＰＯＮ主信号処理機能、ＰＯＮアクセス制御機能、Ｌ２主信号処理機能、保守運用機能のみを備えてもよいし、それ以外の機能を備えてもよい。また、各機能のソフト化可否の評価は、２０１８年に想定されるＯＬＴの処理能力かつ、ソフトスイッチの適用は想定していない前提での一例である。想定する処理能力やソフトスイッチの適用を想定して適宜変更してもよい。ソフト化可の機能であっても、ソフト化しなくてもよい。各機能の内部の構成は同様の機能を実現できれば他の構成であってもよい。

主要８機能に含まれるアルゴリズムを主なソフト化領域とする。ソフト化領域とした機能を機器無依存ＡＰＩ２１上の機器無依存アプリ１３０とする。例えば、差異化サービスに資するＯＮＵ登録又は認証機能、ＤＷＢＡ機能、設定・管理・監視制御機能及び省電力制御機能におけるアルゴリズムは機器無依存アプリ１３０における拡張機能部として扱われる。ＭＬＤプロキシアプリはマルチキャスト機能を含む。
拡張機能部は、アプリの内、機能の更新頻度や独自仕様等の実現等の重要度に応じて拡張機能部とする。更新頻度が低いか独自仕様等の実現の要求の低いものは基本機能部１３２や機器無依存アプリ１３０以外のミドルウェアや機器依存ソフトウェアやハードウェア部及びハードウェア部とすることが好ましい。特に、ソフトウェアの処理能力からくる制限がある機能は、ハードウェア部及びハードウェア部のままとすることが好ましい。例えば、主信号の優先処理や回線の利用効率を向上するＤＢＡ等の更改頻度が高いかサービス差異化に寄与する機能や、オペレータの業務フローに密接にかかわり合いオペレータ毎の独自仕様が要求される管理制御機能から拡張機能部とする。

情報処理部は、これらのソフト化機能に限らず、それ以外のソフト化機能を備えていてもよい。ハードウェア部及びハードウェア部は、送受信部、ＯＳＵ、スイッチ、制御部、情報処理部に限らない。例えば、情報処理部は、送受信部、ＯＳＵ、スイッチ、制御部に含まれていてもよい。また図６に示すように、スイッチのＮＮＩ（Ｎｅｔｗｏｒｋ－Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）側に、スイッチに入出力する信号を処理するプロキシ部又は外部サーバを備えていてもよい。外部サーバは、複数の装置を備えるデータセンタ等のいわゆるクラウドと呼ばれる情報処理機能であってもよい。

各機能は、処理能力や処理遅延の要求に応じて適宜配置してもよい。また、ＯＳＵにスイッチ部１２又はスイッチ部１３を備えていてもよいし、スイッチとは別途スイッチ（スイッチ部１３を備える場合のスイッチ部１２）を備えていてもよい。スイッチの機能はスイッチ部１２とスイッチ部１３で重複せずにスイッチの処理能力等に従って適宜分担することが望ましいが、重複してもよい。

ソフト化機能を配備する箇所は、情報処理部に限らず、複数の演算処理可能な箇所に配置してもよい。例えば、ソフト化機能を配備する箇所は、送受信部、ＯＳＵのスイッチ、ＯＳＵのスイッチ以外、ＯＬＴの制御部、ＯＬＴのスイッチ、ＯＬＴの情報処理部、ＯＬＴのスイッチと制御部と情報処理部以外、スイッチのＮＮＩ側にスイッチに入出力する信号を処理するプロキシ部また外部サーバ等の処理装置のいずれかであってもよい。

また、ソフト化機能の配置は、ソフト化機能毎であってもよいし、単一のソフト化機能を分割したソフト化機能の一部であってもよい。例えば、送受信部に関するものを送受信部以外の他の箇所、例えば、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。ＰＯＮ終端に関するものをＰＯＮ終端処理配備箇所以外の他の箇所、例えば、ＯＳＵの送受信部、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。

ＯＮＵのスイッチに関するものをＯＮＵのスイッチ以外の他の箇所、例えば、送受信部、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴのスイッチ、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。ＯＬＴのスイッチに関するものをＯＬＴのスイッチ以外の他の箇所、例えば、送受信部、ＯＳＵのスイッチ、ＯＳＵの送受信部以外且つスイッチ以外、ＯＬＴの制御部、ＯＬＴの情報処理部、ＯＬＴのそれ以外、ＯＬＴの外部で主信号の経路上にあるプロキシ部、外部サーバ等のどこか又は複数の配備場所の組み合わせに配備してもよい。
また、ソフト化機能を配備する箇所は拡張機能部の配備の状況や、演算可能な箇所の演算能力や演算負荷や消費電力等に応じて、適宜変更してもよい。

ＯＬＴの主信号処理に係る主要な機能と機能間の関係を説明する。ＯＬＴ機能をスイッチに移行する。ＰＨＹアダプテーション機能、フレーム化機能、サービスアダプテーション機能などのＰＯＮ区間処理を行うＰＯＮ主信号処理機能を、送受信部に配備する。ＯＮＵ登録又は認証機能、ＤＢＡ制御機能、ＤＷＡ機能などのＰＯＮアクセス制御機能を情報処理部に配備する。フレーム化で利用されるＶＬＡＮ制御、シェーパの前段の優先制御、マックス又はデマックス（ＭｕＸ／Ｄｍｕｘ）及びキュー（Ｑｕｅｕｅ）、並びにフレーム化の前段のシェーパなどのＬ２主信号処理機能をスイッチに配備する。
シェーパの前段のコピー機能、コピーで利用されるＭＬＤプロキシなどのマルチキャスト機能をスイッチに配備する。このように、ＰＯＮに配備されていたＰＯＮ主信号処理機能及びＰＯＮアクセス制御機能をスイッチに配備することで、ＰＯＮ基本機能部１３２を縮小する。特に、Ｌ２主信号処理は重複を避け、スイッチに配備することが好ましい。

なお、スイッチの機能として、Ｃｌａｓｓｉｆｉｅｒ（クラシファイア）、Ｍｏｄｉｆｉｅｒ（モディファイア）、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ（ポリサー／シェーパ）、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ（クロス・コネクト）、Ｑｕｅｕｅ（キュー）、Ｓｃｈｅｄｕｌｅｒ（スケジューラ）の順に備える前提で例示したが適宜変更してもよい。例えば、上り方向であり、帯域割当単位の中で処理を行わなければ、ＯＮＵからの入力をバースト送信のためのプリアンブルやバーストオーバーヘッドを外し、フレームをデカプセル化したり、ＬＬＩＤを外したりして、ＰＯＮを終端のみし、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒの全ての機能をスイッチで実施してもよいし、スイッチでＭｏｄｉｆｉｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒのみ実施してもよい。
更に、ＰＯＮ終端後のパス等を記載するＶＩＤ等をＯＮＵで付与すれば、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒすればよい。上位ネットワークが単一パスと見做せれば、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒでよい。また、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔでフレームが衝突しないようにＤＢＡすれば、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、とすることができる。更に、上り方向であり、帯域割当単位の中で処理を行わなければ、ＯＮＵからの入力をバースト送信のためのプリアンブルやバーストオーバーヘッドを外し、フレームをデカプセル化したり、ＬＬＩＤを外したりして、ＰＯＮを終端のみし、ＰＯＮ終端後のパス等を記載するＶＩＤ等をＯＮＵで付与すれば、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔのみとすることもできる。

また、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒで、Ｃｌａｓｓｉｆｉｅｒ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｍｏｄｉｆｉｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｑｕｅｕｅ、Ｓｃｈｅｄｕｌｅｒとしてもよいし、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒの前段にＱｕｅｕｅを置いて、Ｃｌａｓｓｉｆｉｅｒ、Ｍｏｄｉｆｉｅｒ、Ｑｕｅｕｅ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｓｃｈｅｄｕｌｅｒとしたり、Ｃｌａｓｓｉｆｉｅｒ、Ｑｕｅｕｅ、Ｐｏｌｉｃｅｒ／Ｓｈａｐｅｒ、Ｍｏｄｉｆｉｅｒ、Ｃｒｏｓｓ Ｃｏｎｎｅｃｔ、Ｓｃｈｅｄｕｌｅｒとしたりしてもよい。ＰＯＮのバースト伝送や、マルチキャスト等の優先トラフィックを多重することによって生ずるバースト性による不要のＰｏｌｉｃｉｎｇ（ポリシング）／Ｓｈａｐｉｎｇ（シェイピング）や、受信側での平準化したトラフィックの受信を考慮するとＰｏｌｉｃｅｒ／Ｓｈａｐｅｒの前段にＱｕｅｕｅを置いて平準化した後にＰｏｌｉｃｉｎｇ／Ｓｈａｐｉｎｇによる処理を実行することが望ましい。

（実施形態１－２）
実施形態１－１ではＴＷＤＭ－ＰＯＮに用いられる構成を例示したが、ＴＤＭ－ＰＯＮに適用してもよい。ＴＤＭ－ＰＯＮでは、λ設定切替（ＤＷＡ）のようなＯＮＵの間ＯＮＵ－ＯＬＴのＰＯＮ区間の波長リソースを波長分割多重する機能を備えていなくてもよいことを除けば実施形態１－１と同様である。

（実施形態１－３）
実施形態１－１ではＴＷＤＭ－ＰＯＮに用いられる構成を例示したが、ＷＤＭ－ＰＯＮに適用してもよい。ＷＤＭ－ＰＯＮでは、ＤＢＡのようなＯＮＵの間ＯＮＵ－ＯＬＴのＰＯＮ区間の帯域リソースを時分割多重する機能を備えていなくてもよいことを除けば、実施形態１－３は実施形態１－１と同様である。

（実施形態１－４）
本実施形態は、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘ）－ＰＯＮ、ＣＤＭ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘ）－ＰＯＮ、ＳＣＭ（Ｓｕｂｃａｒｒｉｅｒ Ｍｕｌｔｉｐｌｅｘ）－ＰＯＮ、芯線分割多重を含めた組み合わせである。

実施形態１－１ではＴＷＤＭ－ＰＯＮに用いられる構成を例示したが、波長と時間以外のリソースを共用するＰＯＮに適用してもよい。例えば、１波長の電気の周波数リソースを分割多重するＯＦＤＭ－ＰＯＮ、１波長の電気の周波数リソースを分割多重するＳＣＭ－ＰＯＮ、符号で分割多重するＣＤＭ－ＰＯＮに適用してもよいし、芯線分割多重を併用してもよいし、マルチコアファイバ等を用いた空間分割多重を併用してもよいし、波長分割多重を用いなくてもよい。ＴＷＤＭ－ＰＯＮの波長リソースを波長分割多重する機能を、それぞれの多重するリソースに分割多重するに要する機能に対応する機能に読み替えれば同様である。

（実施形態２）
実施形態２では、ＴＷＤＭ－ＰＯＮに用いられる構成が、ＧＥＭカプセル化を行う。この場合、ＧＥＭフレームを生成するアダプタをスイッチに備え、スイッチとそれ以外の部分の間でＧＥＭフレームを導通するようにする。ＧＥＭカプセル化までスイッチに移管することで、それ以外の部分のプロトコルスタックからＬ２機能部を除外し、スイッチとそれ以外の部分で、Ｌ２機能部の重畳を回避することができる。

なお、ＴＷＤＭ－ＰＯＮを例に挙げたが、実施形態１－２～実施形態１－４のように、ＰＯＮ区間での識別するためのフレームを同様に扱えばそれ以外のＰＯＮであっても同様の効果が得られる。例えば、ＩＥＥＥの規格のＧＥ－ＰＯＮ、１０ＧＥ－ＰＯＮ等であれば、ＧＥＭフレームの代わりに、ＬＬＩＤを付与してＬＬＩＤの付与されたフレームをスイッチとそれ以外の部分の間を導通するようすればよい。

（実施形態３）
実施形態３では、ＴＷＤＭ－ＰＯＮに用いられる制御情報が、スイッチを経由する。この場合、ブリッジ機能関連をスイッチに移管する代わりに、制御情報を保持するＰＬＯＡＭ、Ｅｍｂｅｄｄｅｄ ＯＡＭ、ＯＭＣＩのいずれかを必要に応じてフレーム化してスイッチ経由で処理する。制御情報をスイッチ経由で入出力することで、スイッチ以外の処理が軽くなる効果がある。なお、実施形態３の移管に加えて、実施形態１及び実施形態２のブリッジ機能のスイッチへの移管を行ってもよい。
なお、ＴＷＤＭ－ＰＯＮを例に挙げたが、制御情報を同様に扱いスイッチ経由で処理すれば、実施形態１－２～実施形態１－４のように、それ以外のＰＯＮであっても同様の効果が得られる。

上述した実施形態における通信装置の少なくとも一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。更に「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、更に前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではない。上記の実施形態は例示に過ぎず、本発明は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができ、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１１…送受信部， １２、１３…スイッチ部， １４…制御部， １５…プロキシ部， １６…外部サーバ， ２１、２２、２７…機器無依存ＡＰＩ， ２３、２４、２５…機器依存ＡＰＩ

Claims (3)

1. 通信装置を構成する部品として、帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部を備え、
   前記保持部は、前記帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部とは異なる複数の保持部に対して保持する情報を通知しておき、前記第１の通信装置を構成する部品又は前記第１の通信装置の帰属替えのタイミングで、前記通知された保持部は、保持している情報の少なくとも一部を帰属替え先に対応する第２の通信装置の保持部に対して、ＯＡＭ部、主信号線又はオペレーションシステムのいずれかの前記通信装置と前記第２の通信装置との間を接続する外部の経路を介して通知する通信装置。
2. 通信装置を構成する部品として、帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部を備える通信装置が行う通知方法であって、
   前記保持部が、前記帰属替え対象となる第１の通信装置を構成する部品又は前記第１の通信装置の特定の状態に関する情報の少なくとも一部の情報を保持する保持部とは異なる複数の保持部に対して保持する情報を通知しておき、前記第１の通信装置を構成する部品又は前記第１の通信装置の帰属替えのタイミングで、前記通知された保持部は、保持している情報の少なくとも一部を帰属替え先に対応する第２の通信装置の保持部に対して、ＯＡＭ部、主信号線又はオペレーションシステムのいずれかの前記通信装置と前記第２の通信装置との間を接続する外部の経路を介して通知する情報通知方法。
3. コンピュータを、請求項１記載の通信装置に備わる各機能部として機能させるためのコンピュータプログラム。

Images