JP2018064179A - 伝送装置，プログラムおよびネットワークシステム - Google Patents

Abstract

【課題】制御監視装置との間に通信異常が検出された場合であっても、ログ情報を制御監視装置に送信できる。【解決手段】第１のネットワーク５１における空き信号領域を探索する空き信号領域探索部と、第１のネットワーク５１を介して接続される複数の伝送装置１０のうち第１の伝送装置１０−１は、第２のネットワーク５２を介して接続される制御監視装置５０との通信に異常が検出された際に、複数の伝送装置１０のうち第２の伝送装置１０−２に、第１のネットワーク５１を介してログ情報を送信する第１送信部を備える。【選択図】図１

Description

本発明は、伝送装置，プログラムおよびネットワークシステムに関する。

図２７は光伝送ネットワーク（ＯＴＮ：Optical Transport Network）の接続構成を例示する図である。

光伝送ネットワークは、国際標準化機関ITU-Tで規定される通信規格（ITU-T勧告G.709）に準拠する通信ネットワークシステムである。

図２７に例示するネットワークシステム５００は、ネットワーク制御監視装置（ＯＰＳ：Operation System）５０１と複数の伝送装置５０２とを備える。

複数の伝送装置５０２は、ＯＴＮ５１０を介して相互に通信可能に接続される。ＯＴＮ５１０は、主信号を伝送する主信号ルートを構成する。以下、ＯＴＮ５１０を主信号ルート５１０という場合がある。

また、各伝送装置５０２は、制御監視ネットワーク５２０を介してそれぞれＯＰＳ５０１と接続されている。以下、制御監視ネットワーク５２０を通知ルート５２０という場合がある。

このような光伝送ネットワークにおいて、伝送装置５０２間を接続する主信号ルート５１０は冗長化されており、運用に必要な警報等の情報も、主信号ルート５１０を使って複数の伝送装置５０２で共有できるように構成されている。そのため、一部の伝送装置５０２とＯＰＳ５０１との間の制御監視ネットワーク５２０が断絶しても、サービスは継続できるようになっている。

特開２０１３−１０６１５３号公報 特開２０１２−０１５９６６号公報

しかしながら、上述の如く、一部の伝送装置５０２とＯＰＳ５０１との間の制御監視ネットワーク５２０が断絶してもサービスは継続できるために、ＯＰＳ５０１への通知ルート５２０は、主信号ルート５１０に比べて比較的安価に構成される。これにより、制御監視ネットワーク５２０は、断絶するリスクが高く、伝送装置５０２におけるインタフェースユニットとＯＰＳ５０１との間の経路において断絶が生じると、故障要因の解析等に用いる装置ログ等を遠隔から取得できず、保守作業者を派遣する必要がある。

１つの側面では、本発明は、制御監視装置との間に通信異常が検出された場合であっても、ログ情報を制御監視装置に送信できるようにすることを目的とする。

このため、この伝送装置は、第１のネットワークを介して接続される複数の伝送装置のうちのいずれか一つの伝送装置であって、前記第１のネットワークにおける空き信号領域を探索する空き信号領域探索部と、第２のネットワークを介して接続される制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうちの他の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する第１送信部を備える。

一実施形態によれば、制御監視装置との間に通信異常が検出された場合であっても、ログ情報を制御監視装置に送信できる。

実施形態の一例としての伝送システムの構成を模式的に示す図である。 ＴＣＭの構成を示す図である。 ＴＣＭを用いた接続性確認方法を例示する図である。 実施形態の一例としての伝送システムにおける伝送装置のハードウェア構成を示す図である。 実施形態の一例としての伝送システムにおける伝送装置の機能構成を示す図である。 実施形態の一例としての伝送システムにおける装置管理部により実現される機能を説明する図である。 実施形態の一例としての伝送システムにおけるＯＴＮの監視機能を説明するための図である。 実施形態の一例としての伝送システムにおける代行ノード探索部による代行通知可否問い合わせメッセージの送信方法説明するための図である。 実施形態の一例としての伝送システムにおける代行ノードからの代行可能通知メッセージの応答方法を説明するための図である。 実施形態の一例としての伝送システムにおける故障ノードから代行ノードへの装置ログの送信を例示する図である。 実施形態の一例としての伝送システムにおける代行ノードから故障ノードへの装置ログ送信への応答を例示する図である。 実施形態の一例としての伝送システムにおける故障ノードから代行ノードへの装置ログの転送方法を示すシーケンス図である。 実施形態の一例としての伝送システムにおける装置ログ送信ＴＣＭにおいて競合が発生した状態を例示する図である。 ＴＴＩフォーマットを示す図である。 実施形態の一例としての伝送システムにおけるメッセージフォーマットを例示する図である。 実施形態の一例としての伝送システムにおけるメッセージとメッセージＩＤとの対応関係を例示する図である。 実施形態の一例としての伝送システムにおける故障ノードにおける処理を説明するフローチャートである。 実施形態の一例としての伝送システムにおける代行ノードにおける処理を説明するフローチャートである。 実施形態の一例としての伝送システムにおいて故障ノードが隣接する代行ノードに装置ログを送信する処理の説明図である。 実施形態の一例としての伝送システムにおいて故障ノードが隣接する代行ノードに装置ログを送信する場合の故障ノードの処理を説明するシーケンス図である。 実施形態の一例としての伝送システムにおいて故障ノードが隣接する代行ノードに装置ログを送信する場合の代行ノードの処理を説明するシーケンス図である。 実施形態の一例としての伝送システムにおいて故障ノードに隣接するノードが代行ノードになれない場合の処理のイメージ図である。 実施形態の一例としての伝送システムにおける代行不可ノードの処理を示すシーケンス図である。 実施形態の一例としての伝送システムにおいて故障ノードから代行ノードへの装置ログの送信時に中断が発生する処理のイメージ図である。 実施形態の一例としての伝送システムにおいて装置ログの送信時に中断が発生する場合の故障ノードの処理を示すシーケンス図である。 実施形態の一例としての伝送システムにおいて装置ログの送信時に中断が発生する場合の代行ノードの処理を示すシーケンス図である。 光伝送ネットワークの接続構成を例示する図である。

以下、図面を参照して本伝送装置，プログラムおよびネットワークシステムに係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形（実施形態および各変形例を組み合わせる等）して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。

（Ａ）構成
図１は実施形態の一例としての伝送システム１の構成を模式的に示す図である。

図１に例示する伝送システム１は、ＯＴＮであって、ＯＰＳ５０と外部サーバ６０と、複数（図１に示す例では２つを図示）の伝送装置１０−１，１０−２とを備える。

なお、以下、伝送装置を示す符号としては、複数の伝送装置のうち１つを特定する必要があるときには符号１０−１，１０−２を用いるが、任意の伝送装置を指すときには符号１０を用いる。また、以下、伝送装置１０をノード１０という場合がある。

ＯＴＮ５１は、主信号を伝送する主信号ルートを構成するリング型のネットワークである。なお、以下、ＯＴＮ５１を主信号ルート５１という場合がある。

光伝送ネットワーク（ＯＴＮ)では、通信経路の信号品質監視方法として、ＴＴＩ（Trail Trace Identifier）を用いて互いの接続性確認を行なう。このような接続性確認を実現する機能として、セクションモニタリング（Section Monitoring；ＳＭ）、パスモニタリング（Path Monitoring；ＰＭ）およびタンデムコネクションモニタリング（Tandem Connection Monitoring；ＴＣＭ）の、信号領域を用いた３種の監視方法が知られている。

信号領域は、２つのノード間で接続性確認を行なうために用いられる領域である。本例では、信号領域は、任意に設定可能な２つのノード間で接続性確認を行なうために用いられる領域である。信号領域においては、例えば、接続確認に用いられる確認用値が格納され、受信側において、この確認用値を期待値と比較することで誤接続等の判断（接続性確認）が行なわれる。

これらのうち、ＴＣＭは、例えば、ネットワーク管理者がＯＰＳを介して任意のノード間の接続性確認を設定することに用いられる。なお、従来のＯＴＮにおいては、ＴＣＭの使用頻度は低い。

前述のように、ＴＣＭは、ネットワーク管理者が任意のノード間の接続性確認を行なうために使用される。接続性確認には６４バイトのＴＴＩ領域が使用される。

図２はＴＣＭの構成を示す図である。この図２に示すＴＣＭの構成は、ITU-T G.709に規定されたものである。

ＯＴＮにおいてはＴＣＭ１〜ＴＣＭ６の合計６つのＴＣＭが用意されており、セクション間で重複しない範囲でこれらのＴＣＭを使用することができる。フレームのＴＴＩ領域に設定された値はＴＣＭにおける終端するポイントでモニタされ、期待する値と異なれば、誤接続していると判断しTTI Mismatch 警報が発出される。ＴＣＭを終端する場合には、３ビットのＳＴＡＴ（Status）領域に、ＴＣＭが使用中であることを示す決められた値（001または 010）が設定される。

図３はＴＣＭを用いた接続性確認方法を例示する図である。この図３に示す例においては、ノードＡでＴＣＭ１を終端し、ＴＴＩに“NODEA”という文字列を挿入する。同じくノードＦでＴＣＭ１を終端し、ＴＴＩの受信期待値を“NODEA”に設定しておくことで正常にノードＡからの信号を受信していることを確認できる。ノードＥでは終端しているＴＣＭ３のＴＴＩの受信値は“NODEC”となるが、期待値を“NODEX”に設定しているため、TTI Mismatchを警報することで、接続性確認がＮＧであることをネットワーク管理者に知らせる。

ＯＰＳ５０は、本伝送システム１を管理する制御監視装置である。外部サーバ６０は、サーバ機能を有する情報処理装置である。

各伝送装置１０は、制御監視ネットワーク５２を介してそれぞれＯＰＳ５０と接続されている。以下、制御監視ネットワーク５２を通知ルート５２という場合がある。

各伝送装置１０は、ＯＰＳ５０を介して外部サーバ６０に装置ログのデータ（ログ情報）を送信する。以下、装置ログのデータを装置ログデータという場合がある。また、装置ログのデータを単に装置ログという場合もある。本伝送システム１においては、伝送装置１０における装置ログがこの外部サーバ６０の図示しない記憶装置に格納され、エラーの分析等に用いられる。

図４は実施形態の一例としての伝送システム１における伝送装置１０のハードウェア構成を示す図である。

伝送装置１０は、図４に示すように、ＣＰＵ１１，ＯＴＮ信号制御部１２，メモリ１３，終端制御スイッチ（ＳＷ）１４−１，１４−２，光モジュール１５−１，１５−２およびＬＡＮ（Local Area Network） ＰＨＹ（Physical layer）１６を備える。

ＬＡＮ ＰＨＹ１６は、イーサネット（登録商標）物理層に関する処理を行なうチップ（電子装置）であり、制御監視ネットワーク５２との通信制御を行なう。伝送装置１０とＯＰＳ５０との間においては、制御監視ネットワーク信号が制御監視ネットワーク５２を介して送受信される。

光モジュール１５−１，１５−２は、光信号と電気信号とを相互に変換する処理を行なう。光モジュール１５−１，１５−２は、ＯＴＮ５１を流れる光信号（ＯＴＮ信号）を電気信号に変換し、また、電気信号を光信号に変換する。

伝送装置１０は、ＯＴＮ５１の伝送路上に光信号を中継するように配設される。伝送装置１０におけるウェスト側においては、光モジュール１５−１を介してＯＴＮ５１と接続される。また、伝送装置１０におけるイースト側においては、光モジュール１５−２を介してＯＴＮ５１と接続される。

メモリ１３は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）を含む記憶装置である。メモリ１３のＲＯＭには、伝送制御に係るソフトウェアプログラム（ファームウェア）やこのプログラム用のデータ類が書き込まれている。メモリ１３上のソフトウェアプログラムは、ＣＰＵ１１に適宜読み込まれて実行される。また、メモリ１３のＲＡＭは、一次記憶メモリあるいはワーキングメモリとして利用される。メモリ１３のＲＡＭには、一時的な装置ログも格納される。

終端制御スイッチ１４−１，１４−２は、ＯＴＮ５１内のフレームを通過させるか取り込むかを切り換える。終端制御スイッチ１４−１，１４−２を終端させるよう切り換えることで、ＯＴＮ５１を流れるフレームを自伝送装置１０に取り込み、また、自伝送装置１０からＯＴＮ５１にフレームを流すことができる。

終端制御スイッチ１４−１，１４−２の切替制御は、後述するＣＰＵ１１によって行なわれる。

ＯＴＮ信号制御部１２は、ＯＴＮ５１を流れるフレームを取得し、また、ＯＴＮ５１にフレームを送出する。

ＣＰＵ１１は、種々の制御や演算を行なう処理装置（ハードウェアプロセッサ）であり、メモリ１３のＲＯＭ等に格納されたファームウェアを実行することにより、種々の機能を実現する。

ＣＰＵ１１は、ＯＴＮ信号制御部１２を介してＯＴＮ５１を流れるＯＴＮ信号の制御や監視を行なう。

また、ＣＰＵ１１は、ＬＡＮ ＰＨＹ１６を介して制御監視ネットワーク５２を流れる制御監視ネットワーク信号の送受信を行なう。

図５は実施形態の一例としての伝送システム１における伝送装置１０の機能構成を示す図である。

ＣＰＵ１１は、図５に示す、ユーザインタフェース部１３０，装置管理部１１０，ハードウェアアクセスドライバ部１２０および装置データベース管理部１４０としての機能を実現する。

なお、これらのユーザインタフェース部１３０，装置管理部１１０，ハードウェアアクセスドライバ部１２０および装置データベース管理部１４０としての機能を実現するためのプログラム（ファームウェア）は、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。また、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。

ユーザインタフェース部１３０，装置管理部１１０，ハードウェアアクセスドライバ部１２０および装置データベース管理部１４０としての機能を実現する際には、内部記憶装置（本実施形態ではメモリ１３のＲＡＭやＲＯＭ）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ１１）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。

ユーザインタフェース部１３０は、オペレータが操作入力を行なうためのユーザインタフェースを提供するものであり、例えば、図示しない表示装置にメニュー画面等を表示させる。

ハードウェアアクセスドライバ部１２０は、ＯＴＮ５１にアクセスする処理を行なう。このハードウェアアクセスドライバ部１２０は、例えば、ＳＴＡＴ監視プロセス１２１を実現する。ＳＴＡＴ監視プロセス１２１は、後述する第１ログ転送部２２が代行ノード１０へのログの転送処理中に、ログの転送に使用するＴＣＭのＳＴＡＴを監視し続ける。ＳＴＡＴ監視プロセス１２１は、割込みハンドラであり、監視対象のＴＣＭが他のノード１０によって使用された契機で、すなわち、ログ転送に使用中のＴＣＭ（装置ログ送信ＴＣＭ）が他の伝送装置１０によって使用されたことを検知すると、装置管理プロセス１１２に割り込み（ログ送信中断通知）を入力する。このように、ＳＴＡＴ監視プロセス１２１は、ＴＣＭ（信号領域）の使用状況を監視する監視部として機能する。

なお、監視対象のＴＣＭが他のノード１０によって使用されたことは、そのＴＣＭから使用割込みがＳＴＡＴ監視プロセス１２１に入力されることで通知される。

装置データベース管理部１４０は、伝送装置１０における種々の情報を記憶し、管理する。

装置管理部１１０は、自身が機能する伝送装置１０（以下、自伝送装置１０または自ノード１０という）に関する管理を行なう。

この装置管理部１１０は、装置ログ送受信プロセス１１１と装置管理プロセス１１２とを実行する。

装置ログ送受信プロセス１１１は、ノード１０間におけるメッセージの送受信を行なう。例えば、装置ログ送受信プロセス１１１は、自ノード１０が故障した場合に、故障した自ノード１０と代行ノード１０の間でメッセージのやりとりを行なう。なお、以下、故障が生じた伝送装置１０を故障ノード１０という場合がある。また、本実施形態における故障とは、例えばＬＡＮ ＰＨＹ１６等のインタフェース部分に異常が生じ、ＯＰＳ５０との通信が不可となった状態をいうものとする。

また、装置ログ送受信プロセス１１１は、自ノード１０が代行ノード１０として機能する場合に、故障ノード１０との間でメッセージのやりとりを行なう。

装置管理プロセス１１２は、伝送システム１における故障発生時の伝送装置１０の処理を管理する。

図６は実施形態の一例としての伝送システム１における装置管理部１１０により実現される機能を説明する図である。

装置管理部１１０は、図６に示すように、代行ノード探索部２１，第１ログ転送部２２，ログ転送中断制御部２３，第２ログ転送部２４，故障検出部２５，空きＴＣＭ探索部２６および代行可能判断部２７としての機能を実現する。

これらの機能のうち、代行ノード探索部２１，第１ログ転送部２２，ログ転送中断制御部２３および空きＴＣＭ探索部２６としての各機能は、故障検出部２５により、自ノード１０において故障が検出された伝送装置１０において実現される。なお、自ノード１０において故障が検出された伝送装置１０を故障ノード１０という場合がある。

また、代行可能判断部２７，ログ転送中断制御部２３および第２ログ転送部２４としての各機能は、後述の如く、故障ノード１０の装置ログのデータを故障ノード１０の代わりにＯＰＳ５０に送信する代行ノード１０において実現されることが望ましい。

第１ログ転送部２２，ログ転送中断制御部２３，第２ログ転送部２４としての各機能は、装置ログ送受信プロセス１１１によって実現される。また、代行ノード探索部２１，故障検出部２５，空きＴＣＭ探索部２６および代行可能判断部２７としての各機能は、装置管理プロセス１１２によって実現される。

故障検出部２５は、自ノード１０における故障の発生を検出する。具体的には、故障検出部２５は、ＯＰＳ５０との間での通信障害の発生を検出する。例えば、故障検出部２５は、ＬＡＮ ＰＨＹ１６の故障や、制御監視ネットワーク５２との接続ケーブルやインタフェース部分における故障を検出する。なお、故障検出部２５による故障の検出は、既知の種々の手法で実現することができ、その詳細な説明は省略する。

空きＴＣＭ探索部（空き信号領域探索部）２６は、ＯＴＮ５１において空いているＴＣＭ、すなわち、データ送信に使用されていないＴＣＭ領域（空き信号領域）を探索する。

図７は実施形態の一例としての伝送システム１におけるＯＴＮ５１の監視機能を説明するための図である。

この図７に示すように、伝送装置１０は、モニタ部２０１−１，２０１−２およびＴＴＩインサート部２０２−１，２０２−２を備える。

モニタ部２０１−１は、ＯＴＮ５１における伝送装置１０のウェスト側に流れるフレームを監視する。具体的には、モニタ部２０１−１は、ＯＴＮ５１におけるウェスト側のＴＣＭ１〜６に割り当てられた期間に流れるフレームを監視し、これらのフレームのＴＴＩ領域（６４バイト）およびＳＴＡＴ領域（３ビット）をそれぞれ監視する。

これに対して、モニタ部２０１−２は、ＯＴＮ５１における伝送装置１０のイースト側に流れるフレームを監視する。具体的には、モニタ部２０１−２は、ＯＴＮ５１におけるイースト側のＴＣＭ１〜６を流れるフレームを監視し、これらのフレームのＴＴＩ領域（６４バイト）およびＳＴＡＴ領域（３ビット）をそれぞれ監視する。

なお、以下、モニタ部を示す符号としては、複数のモニタ部のうち１つを特定する必要があるときには符号２０１−１，２０１−２を用いるが、任意のモニタ部を指すときには符号２０１を用いる。

ＴＴＩインサート部２０２−１，２０２−２は、ＯＴＮ５１に流れるフレームにＴＴＩを挿入する。具体的には、ＴＴＩインサート部２０２−１は、ＯＴＮ５１におけるウェスト側のＴＣＭ１〜６を流れるフレームのＴＴＩ領域に自ノード１０を識別するための文字列を入力することで、挿入したフレームが流れるＴＣＭを終端する。同様に、ＴＴＩインサート部２０２−２は、ＯＴＮ５１におけるイースト側のＴＣＭ１〜６を流れるフレームのＴＴＩ領域に自ノード１０を識別するための文字列を入力することで、挿入したフレームが流れるＴＣＭを終端する。

なお、以下、ＴＴＩインサート部を示す符号としては、複数のＴＴＩインサート部のうち１つを特定する必要があるときには符号２０２−１，２０２−２を用いるが、任意のＴＴＩインサート部を指すときには符号２０２を用いる。また、以下、ＴＣＭ１〜６を流れるフレームのＴＴＩ領域に自ノード１０を識別するための文字列を入力することを、ＴＴＩを挿入するという場合がある。

空きＴＣＭ探索部２６は、ＯＴＮ５１におけるウェスト側のＴＣＭ１〜６およびイースト側のＴＣＭ１〜６から、空いているＴＣＭ領域を見つける。ＴＣＭ領域が空いているか否かは、判断対象のＴＣＭが以下の条件（１）〜（３）の全てを満たすか否かで判断する。すなわち、空きＴＣＭ探索部２６は、判断対象のＴＣＭが、以下の条件（１）〜（３）の全てを満たす場合に、当該ＴＣＭが空き状態であると判断する。

条件（１）：判断対象のＴＣＭが、ＯＰＳ５０により自ノード１０にて終端設定されていないこと。つまりＴＴＩが挿入がされていないこと。

条件（２）：他ノード１０により該当ＴＣＭが使用されていないこと。すなわち、モニタ部２０１で検出したＳＴＡＴ領域が“001”または“010”ではないこと。

条件（３）：判断対象のＴＣＭが、後述する第１ログ転送部２２によるログ転送で既に使用されていないこと。なお、この条件（３）を満たすことにより、ログ転送に用いるＴＣＭは重複することがないため、ログ転送同士が競合することはない。

以下、使用されていない空き状態のＴＣＭを空きＴＣＭという場合がある。

空きＴＣＭ探索部２６は、空きＴＣＭを見つけると、ＴＴＩインサート部２０２によりＴＴＩの挿入を行なわせることで、この空きＴＣＭの終端設定を行なう。

代行可能判断部２７は、自ノード１０が代行ノード１０となれるかの判断（代行可能判断機能）を行なう。

ここで、代行ノード１０とは、故障ノード１０の装置ログを、故障ノード１０の代わりにＯＰＳ５０に対して送信する伝送装置１０である。例えば、自ノード１０がＯＰＳ５０と正常に接続されている場合に、代行可能判断部２７は、自ノード１０が代行ノード１０となれると判断する。なお、代行ノード１０となれるか否かの判断基準は、これに限定されるものではなく、適宜変更して実施することができる。例えば、自ノード１０における負荷（プロセッサ負荷やトラフィック負荷）等を鑑みてもよい。すなわち、自ノード１０における負荷の状況を表す値が基準値以上である場合等には、自ノード１０がＯＰＳ５０と正常に接続されている場合であっても、代行ノード１０となれないと判断してもよく、適宜変更して実施することができる。

［代行ノード探索部］
例えば、各伝送装置１０には、予め、ネットワーク管理者により、自ノード１０の装置ログをＯＰＳ５０を介して外部サーバ６０に送信するルート（通知ルート）が設定されている。ところが、自ノード１０に故障が生じた場合には、自ノード１０から外部サーバ６０に装置ログを送信することができない。

そこで、故障ノード１０において、代行ノード探索部２１は、故障した自身の代わりに自ノード１０の装置ログを外部サーバ６０に送信してくれる代行ノード１０を探索する。

代行ノード探索部２１は、空きＴＣＭ探索部２６によって探索された空きＴＣＭを用いて他ノード１０に対して、代行通知可否問い合わせメッセージを送信することで、代行ノード１０を探索する。

代行ノード探索部２１は、ＴＴＩインサート部２０２に、代行通知可否問い合わせメッセージを空きＴＣＭのフレームのＴＴＩ領域に挿入させる。

以下、代行通知可否問い合わせメッセージをＴＴＩ領域に設定したフレームをＴＣＭに送信することを、単に、代行通知可否問い合わせメッセージを送信するという。

なお、この代行通知可否問い合わせメッセージのフォーマットについては、図１５および図１６を用いて後述する。

図８は実施形態の一例としての伝送システム１における代行ノード探索部２１による代行通知可否問い合わせメッセージの送信方法を説明するための図であり、図９は代行ノード１０からの代行可能通知メッセージの応答方法を説明するための図である。

図８に示す例においては、ノードＢが故障ノード１０であり、ＯＰＳ５０との通信経路が断となった状態を示すものであって、イースト側に代行通知可否問い合わせメッセージを送信する例を示す。

空きＴＣＭ探索部２６は、ＴＣＭ１〜６の使用状況をモニタしＴＣＭ２のイースト側が未使用であることを検出する。代行ノード探索部２１は、空き状態であるＴＣＭ２のイースト側に、代行通知可否問い合わせメッセージを通知する。

自ノード１０が代行可能であると判断した伝送装置１０は、故障ノード１０からの代行通知可否問い合わせメッセージに対し、該当ＴＣＭ２の終端設定を行なう。すなわち、ＴＴＩインサート部２０２により、ＴＣＭ２のフレームのＴＴＩ領域に、代行可能であることを示す代行可能通知メッセージを挿入する。

図９に示す例においては、ノードＢからの代行通知可否問い合わせメッセージに対して、ノードＣが代行可能であることを示す代行可能通知メッセージを通知することで応答する例を示している。

一方、ＯＰＳ５０と接続していない等、ＯＰＳ５０と通信できない伝送装置１０は、ＴＣＭ２を流れる代行通知可否問い合わせメッセージを終端せずにスルーする。また、必然的に、本発明が適用されていないノードも代行通知可否問い合わせメッセージをスルーすることになる。なお、代行可能通知メッセージのフォーマットについては、図１５および図１６を用いて後述する。

以下、代行可能通知メッセージをＴＴＩ領域に設定したフレームをＴＣＭに送信することを、単に、代行可能通知メッセージを送信するという。

代行ノード探索部２１は、空きＴＣＭのフレームに代行通知可否問い合わせメッセージを挿入後、一定時間経過しても、いずれの伝送装置１０からも代行可能通知メッセージを受信しない場合には、空きＴＣＭの終端設定を解除する。すなわち、代行ノード探索部２１は、ＴＴＩインサート部２０２に、代行通知可否問い合わせメッセージの挿入を解除させる。そして、代行ノード探索部２１は、空きＴＣＭ探索部２６による空きＴＣＭの探索と、代行通知可否問い合わせメッセージの通知を再度実行（リトライ）する。

なお、代行ノード探索部２１による空きＴＣＭの探索および代行通知可否問い合わせメッセージの送信のリトライ処理は、例えば、最大で１２｛＝６（ＴＣＭ１〜６）×２（ウェスト側およびイースト側）｝回行なわれる。

代行ノード探索部２１によるリトライを１２回実施しても、いずれのノード１０からも代行可能通知メッセージを受信しない場合は、代行ノード１０からの外部サーバ６０への装置ログの代理転送は行なわずに処理を終了する。

［第１ログ転送部］
故障ノード１０において、第１ログ転送部２２は、代行ノード探索部２１によって決定された代行ノード１０に対して、装置ログを送信（転送）する（代行ノード１０への装置ログ転送処理）。

故障ノード１０は、代行可能通知メッセージを受けた契機で、自ノード１０のメモリ１３に格納されている装置ログの代行ノード１０への転送を開始する。

装置ログの送信は、故障ノード１０が、空きＴＣＭに装置ログデータ送信メッセージを挿入することで行なう。第１ログ転送部２２は、この装置ログデータ送信メッセージに装置ログデータを乗せる。
図１０は実施形態の一例としての伝送システム１における故障ノード１０から代行ノード１０への装置ログの送信を例示する図である。

この図１０に示す例においては、故障ノード１０であるノードＢが、代行ノード１０であるノードＣにＴＣＭ２を用いて装置ログを送信している。

代行ノード１０は、故障ノード１０から装置ログデータ送信メッセージを受信後、このメッセージ内に格納されている装置ログのデータをメモリ１３に保持し、そのＴＣＭに装置ログデータ送信応答メッセージを挿入する。

第１ログ転送部２２は、この、装置ログデータ送信メッセージと装置ログデータ送信応答メッセージとの挿入および転送を、装置ログのサイズ分繰り返す。

また、第１ログ転送部２２は、装置ログデータ送信メッセージにはチェックサム値を付与する。

代行ノード１０においては、受信した装置ログデータのチェックサム値の確認を行なう。チェックサム値異常の場合は、代行ノード１０は、装置ログデータ送信応答メッセージの代わりに、装置ログ再送要求メッセージを挿入して、故障ノード１０に応答する。なお、これらの、メッセージのフォーマットについては、図１５および図１６を用いて後述する。

故障ノード１０において第１ログ転送部２２は、代行ノード１０に対する装置ログの送信が完了すると、ＴＴＩインサート部２０２に、装置ログデータ送信完了メッセージをＴＴＩに挿入させる。

代行ノード１０は、装置ログデータ送信完了メッセージを受信した契機で、装置ログのファイル化を行なう。また、代行ノード１０は、ＴＴＩインサート部２０２に、装置ログデータ送信完了応答メッセージをＴＴＩに挿入させる。この装置ログデータ送信完了応答メッセージを契機にして、故障ノード１０および代行ノード１０は、いずれも装置ログの送信に用いたＴＣＭの終端設定を解除する。

図１１は実施形態の一例としての伝送システム１における代行ノード１０から故障ノード１０への装置ログ送信への応答を例示する図である。

この図１１に示す例においては、代行ノード１０であるノードＣが、故障ノード１０であるノードＢにＴＣＭ２を用いて装置ログ送信への応答を行なっている。

図１２は実施形態の一例としての伝送システム１における故障ノード１０から代行ノード１０への装置ログの転送方法を示すシーケンス図である。

なお、メッセージのやり取りには、タイムアウトを設けることが望ましい。タイムアウト時は、ＴＣＭの終端設定を解除し、ログの転送処理を中止する。

図１２に示ように、代行ノード探索部２１から、各ノード１０に対して、代行通知可否問い合わせメッセージが送信される（符号Ｓ１参照）。
代行ノード１０においては、代行可能判断部２７が代行可能であると判定した場合に、故障ノード１０に対して、代行可能通知メッセージを応答する（符号Ｓ２参照）。

以下、故障ノード１０の第１ログ転送部２２が、代行ノード１０に対して、装置ログの送信を行ない（符号Ｓ３，Ｓ５参照）、代行ノード１０が、装置ログデータ送信応答を行なう（符号Ｓ４，Ｓ６参照）。これらの装置ログの送信および装置ログデータ送信応答は、装置ログの送信が完了するまで繰り返し行なわれる。以下、故障ノード１０から代行ノード１０への装置ログデータの送信に用いられるＴＣＭを装置ログ送信ＴＣＭという場合がある。

装置ログの送信が完了すると、第１ログ転送部２２は代行ノード１０に装置ログデータ送信完了を通知し（符号Ｓ７参照）、これに対して、代行ノード１０は、装置ログデータ送信完了応答を送信する（符号Ｓ８参照）。

そして、代行ノード１０の第２ログ転送部２４が、故障ノード１０から受信した装置ログデータを、外部サーバ６０に対して送信して（符号Ｓ９参照）、処理を終了する。

［ログ転送中断制御部］
故障ノード１０および代行ノード１０において、ログ転送中断制御部２３は、故障ノード１０から代行ノード１０へのログ転送処理中に、ＯＰＳ５０により、ログ転送で使用しているＴＣＭ（信号領域）の使用設定が行なわれた場合に、直ちに装置ログデータの送信を中断する（ログ転送処理中断）。

例えば、ログ転送中断制御部２３は、装置ログ送受信プロセス１１１（第１ログ転送部２２）に対して、ログ送信中断通知を送信する。

代行ノード１０への装置ログの転送処理中に、ＯＰＳ５０により装置ログ送信ＴＣＭが使用設定された場合に、装置ログを送信しているノード１０間でＴＣＭを終端しているので、ＯＰＳ５０が設定したＴＴＩが送信値と期待値とで不一致となり、ＴＴＩミスマッチが発生してしまう。

そのため、ＯＰＳ５０により装置ログ送信ＴＣＭが使用設定された場合は、ログ転送を迅速に停止しなければならない。故障ノード１０および代行ノード１０に対して、ＯＰＳ５０による装置ログ送信ＴＣＭの終端設定が行なわれた場合は、ログ転送中断制御部２３は、その設定契機でログ転送を中止する。

ログ転送中断制御部２３は、例えば、ログ転送のメッセージの挿入を停止し、代わりにＯＰＳ５０に設定された文字列を挿入する。

さて、故障ノード１０と代行ノード１０との外側のノード１０に対し、ＯＰＳ５０により、ＴＣＭの終端設定が行なわれた場合は、装置ログの転送のために終端設定している、故障ノード１０と代行ノード１０には、直接のトリガがない。

そのため、故障ノード１０および代行ノード１０は、装置ログ送信ＴＣＭがＯＰＳ５０により使用されたかどうかを判断するために、ログ転送中は、装置ログ送信ＴＣＭのＳＴＡＴ領域を監視し続ける。

図１３は実施形態の一例としての伝送システム１における装置ログ送信ＴＣＭにおいて競合が発生した状態を例示する図である。

この図１３に示す例においては、ＴＣＭ２を用いてノードＢからノードＤに対して装置ログを転送している状態を示す。すなわち、ＴＣＭ２が装置ログ送信ＴＣＭである（図１３中の符号（１）参照）。

このような状態において、符号（２）に示すように、これらのノードＢとノードＤとを跨いだ、ノードＡとノードＥの間でＴＣＭ２が使用設定されたものとする。

ノードＡとノードＥとが、それぞれＳＴＡＴ領域を使用設定（001または010）に書き換える。ノードＢおよびノードＤにおいては、ＳＴＡＴが使用設定に変更された契機で、ログ転送中断制御部２３が、ＴＣＭ２の終端設定を解除してログ転送処理を中断する。

これにより、ＯＰＳ５０は、ノードＡとノードＥとの間でＴＣＭ２の運用が可能となる。この際、過渡的にTTI Mismatchが発生するおそれがあるが、通常時（第１ログ転送部２２による装置ログの転送中でないとき）であっても、ノードＡにＴＴＩ送信値を設定するタイミングと、ノードＥにＴＴＩ期待値を設定するタイミングとは同期しないため、過渡的なTTI Mismatchは問題とはならない。また、最終的にはTTI Mismatch警報は消える。

［第２ログ転送部］
代行ノード１０において、第２ログ転送部２４は、故障ノード１０（第１ログ転送部２２）からの装置ログ転送処理が終わった契機で、ＯＰＳ５０を介して外部サーバ６０に、故障ノード１０の装置ログを転送する（外部サーバ６０への装置ログ転送）。

例えば、第２ログ転送部２４は、故障ノード１０から受信した装置ログをファイル化し、外部サーバ６０にＦＴＰ（File Transfer Protocol）等で転送する。

[メッセージフォーマットについて]
本伝送システム１においては、ITU-T G.709で示すＴＴＩのOperator Specific領域を用いてノード１０間のメッセージの授受を行なう。

図１４はＴＴＩフォーマットを示す図であり、ITU-T G.709で規定されたものである。

ITU-T G.709の規定に従って、ＳＡＰＩに送信元アドレスを、また、ＤＡＰＩに送信先アドレスをそれぞれ設定することで、フレームを受信したノード１０が、どのノード１０から送られてきたメッセージかを判断できる。

なお、代行ノード探索部２１が送信する代行通知可否問い合わせメッセージについては、どの伝送装置１０が代行ノード１０となるかが未確定な状態で送信されるものであるので、ＤＡＰＩはＡＬＬ０（すなわち、ブロードキャスト）で送信する。

図１５は実施形態の一例としての伝送システム１におけるメッセージフォーマットを例示する図である。

この図１５に示すメッセージフォーマットにおいては、MagicNumber，MessageID，Sequence Number，LOG DataおよびChecksumを備える。

MagicNumberには、本伝送システム１における故障ノード１０の装置ログ転送処理にかかるメッセージであることを示す固有の値が設定される。この値が、固有の値でない場合には通常のＴＴＩ値として扱われる。MagicNumberは、例えば２バイトのデータサイズを有する。

MessageIDは、本伝送システム１における故障ノード１０の装置ログ転送処理にかかるメッセージを特定する識別情報（ＩＤ）が設定される。MessageID は、例えば、２バイトのデータサイズを有する。

図１６は実施形態の一例としての伝送システム１におけるメッセージとメッセージＩＤとの対応関係を例示する図である。

例えば、故障ノード１０の代行ノード探索部２１が、メッセージＩＤ“0x0001”を設定することにより、代行通知可否問い合わせメッセージが生成される。代行ノード１０となりうる伝送装置１０がメッセージＩＤ“0x0002”を設定することにより、代行可能通知メッセージが生成される。

Sequence Numberは、複数回送信することにより装置ログデータが送信される場合において、その送信の進捗状態を表す。すなわち、Sequence Numberは、そのデータが、何番目のログデータの送信なのか、何番目のログデータの送信が成功または失敗したのか等を示す。

Message IDが、装置ログデータ送信、装置ログデータ送信応答、装置ログデータ再送要求以外は、Sequence Numberは、Don't careとなる。Sequence Number は、例えば２バイトのデータサイズを有する。

LOG Dataには、装置ログのデータが設定される。LOG Data は２２バイトのデータサイズを有し、１度に２２バイトまでログの送信ができる。２２バイト以上の装置ログデータを送信する場合は、複数回に分けて送信することになる。なお、Message IDが、装置ログデータ送信（0x0003）以外は、LOG Dataには、Don't careが設定される。

Checksumは、メッセージ全体のチェックサム値を示す。受信側でチェックサム値が異常の場合は、次の処理に遷移しない。エラーし続ける場合は、タイムアウトとなり、ログの転送処理は中止される。なお、Checksum は、例えば２バイトのデータサイズを有する。

（Ｂ）動作
上述の如く構成された実施形態の一例としての伝送システム１における故障ノード１０における処理を、図１７に示すフローチャート（ステップＡ１〜Ａ１０）に従って説明する。

ノード１０において故障検出部２５が自ノード１０における故障の発生を検知すると、空きＴＣＭ探索部２６が空きＴＣＭを探索し、代行ノード探索部２１が、この空きＴＣＭに代行通知可否問い合わせメッセージをブロードキャストで送信する（ステップＡ１）。

他のいずれかのノード１０から、代行可能通知メッセージが送信されたか、すなわち、代行ノード１０が発見されたかを確認する（ステップＡ２）。確認の結果、代行可能通知メッセージが送信されない場合には（ステップＡ２のＮＯルート参照）、ステップＡ９に移行する。

ステップＡ９において、リトライ数をインクリメントし、ステップＡ１０において、リトライ数が所定の閾値以上であるかを確認する。リトライ数が所定の閾値未満である、すなわち、リトライオーバーでない場合には（ステップＡ１０のＮＯルート参照）、ステップＡ１に戻る。

リトライ数が所定の閾値以上である、すなわち、リトライオーバーである場合には（ステップＡ１０のＹＥＳルート参照）、処理を終了する。

また、ステップＡ２における確認の結果、他のノード１０から代行可能通知メッセージが送信された場合には（ステップＡ２のＹＥＳルート参照）、終端制御スイッチ１４を切り替えて、空きＴＣＭの終端設定を行なう（ステップＡ３）。これにより、空きＴＣＭであったＴＣＭが装置ログ送信ＴＣＭとなる。

ステップＡ４では、送信する装置ログのサイズ（ログサイズ）に到達するまで、単位サイズ（例えば、２２バイト）に分割した装置ログ（分割装置ログ）の全てに対して、ステップＡ７までの処理を繰り返し実施するループ処理を開始する。

ステップＡ５では、分割装置ログを送信し、ステップＡ６では、ログ転送中断制御部２３による転送中断が行なわれるかを確認する。

転送中断が行なわれない場合には（ステップＡ６のＮＯルート参照）、その後、処理がステップＡ７に進む。

ステップＡ７では、ステップＡ４に対応するループ端処理が実施される。ここで、送信した分割装置ログのデータサイズの合計値が装置ログのデータサイズに到達すると、すなわち、全ての分割装置ログの送信が完了すると、処理がステップＡ８に進む。

また、ステップＡ６における確認の結果、ログ転送中断制御部２３による装置ログの転送中断が行なわれる場合も（ステップＡ６のＹＥＳルート参照）、ステップＡ８に移行する。

ステップＡ８においては、終端制御スイッチ１４を切り替えて、装置ログ送信ＴＣＭの終端設定を解除し、処理を終了する。

次に、実施形態の一例としての伝送システム１における代行ノード１０における処理を、図１８に示すフローチャート（ステップＢ１〜Ｂ７）に従って説明する。

故障ノード１０から代行通知可否問い合わせメッセージを受信したノード１０において、代行可能判断部２７が、自ノード１０が代行ノード１０になれるかの判断を行なう（ステップＢ１）。

代行可能判断部２７が自ノード１０が代行ノード１０になれないと判断した場合には（ステップＢ１のＮＯルート参照）、処理を終了する。

代行可能判断部２７が自ノード１０が代行ノード１０になれると判断した場合には（ステップＢ１のＹＥＳルート参照）、ステップＢ２に移行する。

ステップＢ２において、終端制御スイッチ１４を切り替えて、代行通知可否問い合わせメッセージが送信されたＴＣＭの終端設定を行なう。これにより、当該ＴＣＭが装置ログ送信ＴＣＭとなる。

ステップＢ３において、代行可能判断部２７は、代行通知可否問い合わせメッセージの送信元のノード１０（故障ノード１０）に対して、装置ログ送信ＴＣＭを介して、代行可能通知メッセージを送信する。

ステップＢ４において、代行ノード１０は、故障ノード１０から送信される装置ログを受信する。

ステップＢ５において、ログ転送中断制御部２３による転送中断が行なわれるかを確認する。

転送中断が行なわれない場合には（ステップＢ５のＮＯルート参照）、処理がステップＢ６に進む。ステップＢ６においては、装置ログを構成する全てのデータ（分割装置ログ）を受信したかを確認する。

装置ログを構成する全てのデータ（分割装置ログ）を受信していない場合には（ステップＢ６のＮＯルート参照）、ステップＢ４に戻る。

装置ログを構成する全てのデータ（分割装置ログ）を受信した場合には（ステップＢ６のＹＥＳルート参照）、ステップＢ７に移行する。また、ステップＢ５における確認の結果、転送中断が行なわれる場合も（ステップＢ５のＹＥＳルート参照）、処理がステップＢ７に移行する。

ステップＢ７においては、終端制御スイッチ１４を切り替えて、装置ログ送信ＴＣＭの終端設定を解除し、処理を終了する。

次に、上述の如く構成された実施形態の一例としての伝送システム１における処理を、３つのケースに応じて説明する。

［ケース１］
先ず、ケース１として、実施形態の一例としての伝送システム１における、故障ノード１０が隣接する代行ノード１０に装置ログを送信する処理を、図１９を参照しながら、図２０および図２１に示すシーケンス図に従って説明する。

なお、図１９は故障ノード１０が隣接する代行ノード１０に装置ログを送信する処理のイメージ図である。この図１９に示す例においてはノードＢが故障ノード１０であり、このノードＢに隣接して配置されたノードＣが代行ノード１０となり、ＴＣＭ１を装置ログ送信ＴＣＭとして装置ログの転送を行なう例を示す。

また、図２０は故障ノード１０における処理を示し、図２１は代行ノード１０における処理を示す。

故障ノード１０（図１９に示す例ではノードＢ）の隣接ノード１０（図１９に示す例ではノードＣ）が、ＯＰＳ５０と正常に接続されている場合には、この隣接ノード１０であるノードＣが代行ノード１０として、装置ログの転送を代行する。

故障ノード１０においては、図２０に示すように、故障が生じると、装置管理プロセス１１２（故障検出部２５）がこの故障の発生を検出する（図２０の符号Ｓ１０１参照）。装置管理プロセス１１２（空きＴＣＭ探索部２６）が空きＴＣＭを探索する（図２０の符号Ｓ１０２参照）。この探索の結果、空きＴＣＭ探索部２６は、ＴＣＭ１が空きＴＣＭであると判断する。

装置管理プロセス１１２（第１ログ転送部２２）が、装置ログ送受信プロセス１１１に対して、ＴＣＭ１を用いて装置ログの送信を開始する旨の通知を行なう（図２０の符号Ｓ１０３参照）。

また、装置ログ送受信プロセス１１１（第１ログ転送部２２）が、ＳＴＡＴ監視プロセス１２１に対して、ＴＣＭ１を用いて装置ログの送信を開始する旨の通知を行なう（図２０の符号Ｓ１０４参照）。これにより、ＳＴＡＴ監視プロセス１２１が装置ログの転送に使用する装置ログ送信ＴＣＭのＳＴＡＴの監視を開始する。

装置ログ送受信プロセス１１１（第１ログ転送部２２）が、代行ノード１０に対して、装置ログの転送を行なう（図２０の符号Ｓ１０５参照）。なお、この代行ノード１０に対する装置ログ転送の詳細な処理は、図１２を参照のこと。

装置ログの転送が完了すると、装置ログ送受信プロセス１１１（第１ログ転送部２２）は、ＴＣＭ１での装置ログデータ送信完了を装置管理プロセス１１２に通知（ＴＣＭ１ログ送信完了通知）する（図２０の符号Ｓ１０７参照）。

装置管理プロセス１１２（第１ログ転送部２２）は、ＳＴＡＴ監視プロセス１２１に対して、ＴＣＭ１での装置ログの送信完了を通知（ＴＣＭ１ログ送信完了通知）する（図２０の符号Ｓ１０８参照）。

一方、代行ノード１０においては、図２１に示すように、装置ログ送受信プロセス１１１は、代行通知可否問い合わせメッセージを受信する（図２１の符号Ｓ２０１参照）。この代行通知可否問い合わせメッセージは、故障ノード１０の装置ログ送受信プロセス１１１（代行ノード探索部２１）から、各ノード１０に対して送信される（図１２の符号Ｓ１参照）。

装置ログ送受信プロセス１１１は、装置管理プロセス１１２（代行可能判断部２７）に対して、代行通知可否問い合わせメッセージを転送する（図２１の符号Ｓ２０２）。代行可能判断部２７は、自ノード１０が代行ノード１０となれるかの判断（代行可能判断機能）を行なう（図２１の符号Ｓ２０３）。

代行可能判断部２７が自ノード１０が代行ノード１０となれると判断すると、装置管理プロセス１１２は装置ログ送受信プロセス１１１に対して、ＴＣＭ１による装置ログの受信開始の通知（ＴＣＭ１ログ受信開始通知）を行なう（図２１の符号Ｓ２０４）。

また、装置管理プロセス１１２は、ＳＴＡＴ監視プロセス１２１に対しても、ＴＣＭ１による装置ログの受信開始の通知（ＴＣＭ１ログ受信開始通知）を行なう（図２１の符号Ｓ２０５）。

装置ログ送受信プロセス１１１は、故障ノード１０に対して、代行可能通知メッセージを送信する（図２１の符号Ｓ２０６）。

装置ログ送受信プロセス１１１は、故障ノード１０から、装置ログの受信を行なう（図２０の符号Ｓ２０７参照）。なお、この故障ノード１０からの装置ログ転送の詳細な処理は、図１２を参照のこと。

装置ログの受信が完了すると、装置ログ送受信プロセス１１１は、ＴＣＭ１での装置ログデータ受信完了を装置管理プロセス１１２に通知（ＴＣＭ１ログ受信完了通知）する（図２１の符号Ｓ２０８参照）。

装置管理プロセス１１２は、ＳＴＡＴ監視プロセス１２１に対して、ＴＣＭ１での装置ログの受信完了を通知（ＴＣＭ１ログ受信完了通知）する（図２１の符号Ｓ２０９参照）。

［ケース２］
ケース２として、実施形態の一例としての伝送システム１における、故障ノード１０が隣接するノード１０が代行ノード１０になれない場合の処理を、図２２を参照しながら、図２３に示すシーケンス図に従って説明する。

図２２は故障ノード１０に隣接するノード１０が代行ノード１０になれない場合の処理のイメージ図である。また、図２３は代行不可なノード１０における処理を示すシーケンス図である。

なお、本例においては、故障ノード１０における処理は、図２０に示したシーケンス図と同様であるので、その説明は省略する。

図２２に示す例においてはノードＢが故障ノード１０であり、このノードＢに隣接して配置されたノードＣ（隣接ノード）が、ＯＰＳ５０への通知代行不可であるケースを示す。以下、代行ノード１０となれないノード１０を代行不可ノード１０という場合がある。

ノード１０は、自ノード１０がＯＰＳ５０と接続していない場合や、自ノード１０も故障している場合は、代行ノード１０になれない。代行不可ノード１０は、故障ノード１０からの代行通知可否問い合わせメッセージをスルーする。

なお、ＯＴＮ５１上において、その先に代行可能なノード１０があれば、そのノード１０（図２２に示す例ではノードＤ）が代行可能通知メッセージを応答し、このノードＤに対して、故障ノード１０（図２２に示す例ではノードＢ）から装置ログの転送が行なわれる。

なお、故障ノード１０から、代行通知可否問い合わせメッセージを送信しても、代行できるノード１０が存在せず、いずれのノード１０からも応答がないことも考えられる。そのため、代行通知可否問い合わせメッセージにはタイムアウトを設けることが望ましい。タイムアウト後は、空きＴＣＭ探索部２６による空きＴＣＭの探索から再開することが望ましい。

代行ノード１０においては、図２３に示すように、装置ログ送受信プロセス１１１は、代行通知可否問い合わせメッセージを受信する（図２３の符号Ｓ３０１参照）。この代行通知可否問い合わせメッセージは、故障ノード１０の装置ログ送受信プロセス１１１（代行ノード探索部２１）から、各ノード１０に対して送信される（図１２の符号Ｓ１参照）。

装置ログ送受信プロセス１１１は、装置管理プロセス１１２（代行可能判断部２７）に対して、代行通知可否問い合わせメッセージを転送する（図２３の符号Ｓ３０２参照）。代行可能判断部２７は、自ノード１０が代行ノード１０となれるかの判断（代行可能判断機能）を行なう（図２３の符号Ｓ３０３参照）。

代行可能判断部２７が自ノード１０が代行ノード１０になれないと判断すると、装置管理プロセス１１２は装置ログ送受信プロセス１１１に対して、代行不可能である旨の通知（代行不可能通知）を行なう（図２３の符号Ｓ３０４参照）。

自ノード１０が故障ノード１０の代行を行なうことができないと判断したノード１０においては、終端制御スイッチ１４の切り替えを行なわない。これによりＯＴＮ５１のＴＣＭ１に割り当てられた期間に流れるフレームは、代行不可能と判断されたノード１０を通過する。

［ケース３］
次に、ケース３として、実施形態の一例としての伝送システム１における、故障ノード１０から代行ノード１０への装置ログの送信中に、装置ログの送信を中断する場合の処理を、図２４を参照しながら、図２５および図２６に示すシーケンス図に従って説明する。

なお、図２４は故障ノード１０から代行ノード１０への装置ログの送信時に中断が発生する処理のイメージ図である。この図２４に示す例においてはノードＢが故障ノード１０であり、このノードＢに隣接して配置されたノードＣが代行ノード１０となり、ＴＣＭ１を装置ログ送信ＴＣＭとして装置ログの転送を行なう例を示す。

本例においては、ＴＣＭ１でログ転送中に、ログ転送ノード間（図２４に示す例ではノードＢとノードＣ）を跨ぐノード間（図２４に示す例ではノードＡとノードＥ）でＯＰＳ５０によりＴＣＭ１が使用設定されたケースについて説明する。

ＴＣＭ１を使った装置ログ転送の前に、ＴＣＭの使用／未使用を監視するＳＴＡＴ監視プロセス１２１に、どのＴＣＭを使用してログを転送するかを事前に通知しておく。

ＳＴＡＴ監視プロセス１２１は、装置ログ送信ＴＣＭが使用設定されたことを認識すると、ログの転送を中断させるために、装置管理プロセス１１２（第１ログ転送部２２）にログ転送中断を通知する。

代行ノード１０は、受信中の装置ログのデータを破棄し、故障ノード１０は空きＴＣＭ探索部２６が空きＴＣＭの再検索を行なう。ＴＣＭに空きがあれば、この空きがあったＴＣＭを空きＴＣＭとして用いてログの転送をやり直すのである。

故障ノード１０においては、図２５に示すように、故障が生じると、装置管理プロセス１１２（故障検出部２５）がこの故障の発生を検出する（図２５の符号Ｓ４０１参照）。装置管理プロセス１１２（空きＴＣＭ探索部２６）が空きＴＣＭを探索する（図２５の符号Ｓ４０２参照）。この探索の結果、空きＴＣＭ探索部２６は、ＴＣＭ１が空きＴＣＭであると判断する。

装置管理プロセス１１２（第１ログ転送部２２）が、装置ログ送受信プロセス１１１に対して、ＴＣＭ１を用いて装置ログの送信を開始する旨の通知を行なう（図２５の符号Ｓ４０３参照）。

また、装置管理プロセス１１２が、ＳＴＡＴ監視プロセス１２１に対して、ＴＣＭ１を用いて装置ログの送信を開始する旨の通知を行なう（図２５の符号Ｓ４０４参照）。これにより、ＳＴＡＴ監視プロセス１２１が装置ログの転送に使用する装置ログ送信ＴＣＭのＳＴＡＴの監視を開始する。

装置ログ送受信プロセス１１１（第１ログ転送部２２）が、代行ノード１０に対して、装置ログの転送を行なう（図２５の符号Ｓ４０５参照）。なお、この代行ノード１０に対する装置ログ転送の詳細な処理は、図１２を参照のこと。

ＳＴＡＴ監視プロセス１２１に、ＴＣＭ１を用いたログ送信中に、ＴＣＭ１が他のノード１０間通信に使用されることを示す割込み（ＴＣＭ１使用割込み）が、入力される（図２５の符号Ｓ４０６参照）。

ＳＴＡＴ監視プロセス１２１（ログ転送中断制御部２３）は、装置管理プロセス１１２に対して、送信中断通知を送信する（図２５の符号Ｓ４０７参照）。これにより、故障ノード１０から代行ノード１０への装置ログの送信が中断される。装置管理プロセス１１２（第１ログ転送部２２）は、装置ログ送受信プロセス１１１に対して、ＴＣＭ１を用いた装置ログの送信を中断する旨の通知を行なう（図２５の符号Ｓ４０８参照）。

そして、故障ノード１０において、装置管理プロセス１１２（空きＴＣＭ探索部２６）が空きＴＣＭを探索する（図２５の符号Ｓ４０９参照）。この探索の結果、空きＴＣＭ探索部２６は、空きＴＣＭとして例えば、ＴＣＭ２を選択する。

装置ログ送受信プロセス１１１が、装置管理プロセス１１２（第１ログ転送部２２）に対して、ＴＣＭ２を用いて装置ログの送信を開始する旨の通知を行なう（図２５の符号Ｓ４１０参照）。

また、装置管理プロセス１１２が、ＳＴＡＴ監視プロセス１２１に対して、ＴＣＭ２を用いて装置ログの送信を開始する旨の通知を行なう（図２５の符号Ｓ４１１参照）。これにより、中断された故障ノード１０からの装置ログの送信が再開される。

一方、代行ノード１０においては、図２６に示すように、装置ログ送受信プロセス１１１は、代行通知可否問い合わせメッセージを受信する（図２６の符号Ｓ５０１参照）。この代行通知可否問い合わせメッセージは、故障ノード１０の装置ログ送受信プロセス１１１（代行ノード探索部２１）から、各ノード１０に対して送信される（図１２の符号Ｓ１参照）。

装置ログ送受信プロセス１１１は、装置管理プロセス１１２（代行可能判断部２７）に対して、代行通知可否問い合わせメッセージを転送する（図２６の符号Ｓ５０２参照）。代行可能判断部２７は、自ノード１０が代行ノード１０となれるかの判断（代行可能判断機能）を行なう（図２６の符号Ｓ５０３参照）。

代行可能判断部２７が自ノード１０が代行ノード１０となれると判断すると、装置管理プロセス１１２は装置ログ送受信プロセス１１１に対して、ＴＣＭ１による装置ログの受信開始の通知（ＴＣＭ１ログ受信開始通知）を行なう（図２６の符号Ｓ５０４参照）。

また、装置管理プロセス１１２は、ＳＴＡＴ監視プロセス１２１に対しても、ＴＣＭ１による装置ログの受信開始を通知（ＴＣＭ１ログ受信開始通知）を行なう（図２６の符号Ｓ５０５参照）。

装置ログ送受信プロセス１１１は、故障ノード１０に対して、代行可能通知を送信する（図２６の符号Ｓ５０６参照）。

装置ログ送受信プロセス１１１は、故障ノード１０から、装置ログの受信を行なう（図２６の符号Ｓ５０７参照）。なお、この故障ノード１０からの装置ログ転送の詳細な処理は、図１２を参照のこと。

ＳＴＡＴ監視プロセス１２１に、ＴＣＭ１を用いたログ送信中に、ＴＣＭ１が他のノード１０間通信に使用されることを示す割込み（ＴＣＭ１使用割込み）が、入力される（図２６の符号Ｓ５０８参照）。

ＳＴＡＴ監視プロセス１２１（ログ転送中断制御部２３）は、装置管理プロセス１１２に対して、装置ログの受信を中断する通知（受信中断通知）を入力する（図２６の符号Ｓ５０９参照）。

装置管理プロセス１１２は、装置ログ送受信プロセス１１１に対して、ＴＣＭ１を用いた装置ログの受信を中断する通知（ＴＣＭ１受信中断通知）を入力する（図２６の符号Ｓ５１０参照）。これにより、代行ノード１０における装置ログの受信が中断される。

装置ログ送受信プロセス１１１は、受信した装置ログを破棄し（図２６の符号Ｓ５１１参照）、処理を終了する。

（Ｃ）効果
このように、実施形態の一例としての伝送システム１によれば、ＯＰＳ５０との通信障害が生じた故障ノード１０の第１ログ転送部２２が、代行ノード１０に対して自ノード１０（故障ノード１０）の装置ログを送信する。そして、この装置ログを受信した代行ノード１０の第２ログ転送部２４が、外部サーバ６０に、故障ノード１０の装置ログを、制御監視ネットワーク５２を介して送信する。

これにより、故障ノード１０においてＯＰＳ５０との通信障害が生じた場合に、この故障ノード１０の装置ログを代行ノード１０を介して外部サーバ６０に送信することができる。外部サーバ６０においては、故障ノード１０の装置ログを解析等することで、障害を迅速に復旧させることができ、システムの信頼性を向上させることができる。また、保守効率を向上させることができる。

そして、代行ノード探索部２１は、空きＴＣＭ探索部２６によって探索された空きＴＣＭを用いて他ノード１０に対して、代行通知可否問い合わせメッセージを送信することで、代行ノード１０を探索する。

これにより、一般的にシステム運用フェーズでは使用頻度が低いＴＣＭを有効に活用することができる。

ＯＰＳ５０との通信障害が生じた故障ノード１０において、空きＴＣＭ探索部２６がＯＴＮ５１における使用されていない空きＴＣＭを探索し、この空きＴＣＭを用いて各種メッセージの授受や装置ログの送受信を行なう。これにより、ＯＰＳ５０等に悪影響を与えることなく、ノード１０間での装置ログの送受信を行なうことができる。

代行通知可否問い合わせメッセージを受信した他のノード１０において、代行可能判断部２７が自ノード１０が代行ノード１０となれると判断した場合に、当該ノード１０が代行ノード１０となり、空きＴＣＭを用いて、故障ノード１０に対して代行可能通知メッセージを送信する。これにより、各ノード１０の監視や、代行ノード１０の任命、故障ノード１０の装置ログの採取および外部サーバ６０への転送等を一元的に制御する制御装置等を備えることなく、伝送システム１に備えられた各伝送装置１０間で、自律的に故障ノード１０の装置ログを外部サーバ６０へ送信させることができる。

（Ｄ）その他
そして、本発明は上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。

例えば、上述した実施形態においては、ＴＣＭを用いて各種メッセージや装置ログの送受信を行なっているが、これに限定されるものではない。例えば、ＴＣＭに代えて、ＳＭやＰＭを用いてもよく、種々変形して実施することができる。

また、上述した開示により本実施形態を当業者によって実施・製造することが可能である。

（Ｅ）付記

（付記１）
第１のネットワークを介して接続される複数の伝送装置と、前記複数の伝送装置のそれぞれと第２のネットワークを介して接続される制御監視装置とを備えるネットワークシステムにおいて、
前記複数の伝送装置のうち第１の伝送装置が、前記第１のネットワークにおける空き信号領域を探索する空き信号領域探索部と、前記制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうち第２の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する第１送信部とを備え、
前記第２の伝送装置が、送信された前記ログ情報を前記第２のネットワークを介して前記制御監視装置に送信する第２送信部を備える
ことを特徴とする、ネットワークシステム。

（付記２）
前記第１の伝送装置は、前記複数の伝送装置の中から、当該第１の伝送装置の代わりに前記ログ情報を前記制御監視装置に送信する代行伝送装置を探索する代行伝送装置探索部を備える
ことを特徴とする、付記１記載のネットワークシステム。

（付記３）
前記代行伝送装置探索部は、前記第１のネットワークを介して前記複数の伝送装置のうち当該第１の伝送装置以外の他の伝送装置に対して、代行通知可否問い合わせメッセージを送信する
ことを特徴とする、付記２記載のネットワークシステム。

（付記４）
前記信号領域の使用状況を監視する監視部と、
前記監視部により前記信号領域の使用が検出された場合に、前記第１送信部によるログ情報の送信を中断させる中断処理部と
を備えることを特徴とする、付記１〜３のいずれか１項に記載のネットワークシステム。

（付記５）
第１のネットワークを介して接続される複数の伝送装置のうちのいずれか一つの伝送装置であって、
前記第１のネットワークにおける空き信号領域を探索する空き信号領域探索部と、
第２のネットワークを介して接続される制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうちの他の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する第１送信部とを備える
ことを特徴とする、伝送装置。

（付記６）
前記複数の伝送装置の中から、当該伝送装置の代わりに前記ログ情報を前記制御監視装置に送信する代行伝送装置を探索する代行伝送装置探索部を備える
ことを特徴とする、付記５記載の伝送装置。

（付記７）
前記代行伝送装置探索部は、前記第１のネットワークを介して前記他の伝送装置に対して、代行通知可否問い合わせメッセージを送信する
ことを特徴とする、付記６記載の伝送装置。

（付記８）
前記信号領域の使用状況を監視する監視部と、
前記監視部により前記信号領域の使用が検出された場合に、前記第１送信部によるログ情報の送信を中断させる中断処理部と
を備えることを特徴とする、付記５〜７のいずれか１項に記載の伝送装置。

（付記９）
第１のネットワークを介して接続される複数の伝送装置のうちのいずれか一つの伝送装置のプロセッサに、
前記第１のネットワークにおける空き信号領域を探索する処理と、
第２のネットワークを介して接続される制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうちの他の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する処理と
を実行させるプログラム。

（付記１０）
前記複数の伝送装置の中から、当該伝送装置の代わりに前記ログ情報を前記制御監視装置に送信する代行伝送装置を探索する処理
を前記プロセッサに実行させる、付記９記載のプログラム。

（付記１１）
前記第１のネットワークを介して前記他の伝送装置に対して、代行通知可否問い合わせメッセージを送信する処理
を、前記プロセッサに実行させる、付記１０記載のプログラム。

（付記１２）
前記信号領域の使用状況を監視し、
前記信号領域の使用が検出された場合に、前記ログ情報の送信を中断させる
処理を、前記プロセッサに実行させる、付記９〜１１のいずれか１項に記載のプログラム。

（付記１３）
第１のネットワークを介して他の伝送装置と接続されるとともに、第２のネットワークを介して制御監視装置と接続される伝送装置であって、
前記他の伝送装置において前記制御監視装置との通信に異常が検出された際に、前記他の伝送装置から前記第１のネットワークにおける前記空き信号領域を介して送信されるログ情報を、前記第２のネットワークを介して前記制御監視装置に送信する
ことを特徴とする、伝送装置。

（付記１４）
第１のネットワークを介して他の伝送装置と接続されるとともに、第２のネットワークを介して制御監視装置と接続される伝送装置のプロセッサに、
前記他の伝送装置において前記制御監視装置との通信に異常が検出された際に、前記他の伝送装置から前記第１のネットワークにおける前記空き信号領域を介して送信されるログ情報を、前記第２のネットワークを介して前記制御監視装置に送信する
処理を実行させるプログラム。

１ 伝送システム
１０ 伝送装置
１１ ＣＰＵ
１２ ＯＴＮ信号制御部
１３ メモリ
１４−１，１４−２，１４ 終端制御スイッチ
１５ 光モジュール
１６ ＬＡＮ ＰＨＹ
５０ ＯＰＳ
５１ ＯＴＮ
５２ 制御監視ネットワーク
１１０ 装置管理部
１１１ 装置ログ送受信プロセス
１１２ 装置管理プロセス
２１ 代行ノード探索部
２２ 第１ログ転送部
２３ ログ転送中断制御部
２４ 第２ログ転送部
２５ 故障検出部
２６ 空きＴＣＭ探索部
２７ 代行可能判断部
１２０ ハードウェアアクセスドライバ部
１２１ ＳＴＡＴ監視プロセス
１３０ ユーザインタフェース部
１４０ 装置データベース管理部
２０１−１，２０１−２，２０１ モニタ部
２０２−１，２０２−２，２０２ ＴＴＩインサート部

Claims (6)

1. 第１のネットワークを介して接続される複数の伝送装置のうちのいずれか一つの伝送装置であって、
   前記第１のネットワークにおける空き信号領域を探索する空き信号領域探索部と、
   第２のネットワークを介して接続される制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうちの他の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する第１送信部とを備える
   ことを特徴とする、伝送装置。
2. 前記複数の伝送装置の中から、当該伝送装置の代わりに前記ログ情報を前記制御監視装置に送信する代行伝送装置を探索する代行伝送装置探索部を備える
   ことを特徴とする、請求項１記載の伝送装置。
3. 前記代行伝送装置探索部は、前記第１のネットワークを介して前記他の伝送装置に対して、代行通知可否問い合わせメッセージを送信する
   ことを特徴とする、請求項２記載の伝送装置。
4. 前記信号領域の使用状況を監視する監視部と、
   前記監視部により前記信号領域の使用が検出された場合に、前記第１送信部によるログ情報の送信を中断させる中断処理部と
   を備えることを特徴とする、請求項１〜３のいずれか１項に記載の伝送装置。
5. 第１のネットワークを介して接続される複数の伝送装置のうちのいずれか一つの伝送装置のプロセッサに、
   前記第１のネットワークにおける空き信号領域を探索する処理と、
   第２のネットワークを介して接続される制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうちの他の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する処理と
   を実行させるプログラム。
6. 第１のネットワークを介して接続される複数の伝送装置と、前記複数の伝送装置のそれぞれと第２のネットワークを介して接続される制御監視装置とを備えるネットワークシステムにおいて、
   前記複数の伝送装置のうち第１の伝送装置が、前記第１のネットワークにおける空き信号領域を探索する空き信号領域探索部と、前記制御監視装置との通信に異常が検出された際に、前記複数の伝送装置のうち第２の伝送装置に、前記第１のネットワークにおける前記空き信号領域を介してログ情報を送信する第１送信部とを備え、
   前記第２の伝送装置が、送信された前記ログ情報を前記第２のネットワークを介して前記制御監視装置に送信する第２送信部を備える
   ことを特徴とする、ネットワークシステム。

Images