特開 2024-154837 管理サーバ及びネットワーク状態管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024154837

(43)【公開日】2024-10-31

(54)【発明の名称】管理サーバ及びネットワーク状態管理方法

(51)【国際特許分類】

   H04L 41/06 20220101AFI20241024BHJP

   H04L 41/085 20220101ALI20241024BHJP

【ＦＩ】

H04L41/06

H04L41/085

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023068984

(22)【出願日】2023-04-20

(71)【出願人】

【識別番号】000005290

【氏名又は名称】古河電気工業株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】有馬 康弘

(57)【要約】

【課題】複数のノード装置を有するネットワークの状態取得にかかる通信量を低減することができる管理サーバ及びネットワーク状態管理方法を提供する。
【解決手段】ノード装置ＮＡ，ＮＢから状態変化のイベント通知ｍ１，ｍ２を受けた場合、イベント通知ｍ１，ｍ２に対してイベント通知ｍ１，ｍ２の受信時から予め設定した待機時間Ｔの計時を開始し、１つの待機時間Ｔの計時が終了した時点で待機時間Ｔを計時中の他のイベント通知があるか否かを判定し、待機時間Ｔを計時中の他のイベント通知ｍ２がある場合、待機時間Ｔの計時が終了したイベント通知ｍ１に対する処理を打ち切り、待機時間Ｔを計時中の他のイベント通知がない場合、各ノード装置Ｎに対する状態取得を実行する。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数のノード装置を有するネットワーク内における各ノード装置の動作状態及び各ノード装置間の接続状態を管理する管理サーバであって、
前記ノード装置から状態変化のイベント通知を受けた場合、前記イベント通知に対して前記イベント通知の受信時から予め設定した待機時間の計時を開始し、１つの前記待機時間の計時が終了した時点で前記待機時間を計時中の他のイベント通知があるか否かを判定し、前記待機時間を計時中の他のイベント通知がある場合、前記待機時間の計時が終了した前記イベント通知に対する処理を打ち切り、前記待機時間を計時中の他のイベント通知がない場合、各ノード装置に対する状態取得を実行することを特徴とする管理サーバ。

【請求項2】

前記待機時間は、前記ノード装置が状態変化を検出する状態変化検出時間よりも長いことを特徴とする請求項１に記載の管理サーバ。

【請求項3】

前記待機時間は、前記ノード装置の初期化時間に前記ノード装置が状態変化を検出する状態変化検出時間を加えた時間よりも長いことを特徴とする請求項１に記載の管理サーバ。

【請求項4】

前記待機時間は、各ノード装置から前記管理サーバに前記イベント通知が到達する通知所要時間のうちの最大である最大通知所要時間よりも長いことを特徴とする請求項１に記載の管理サーバ。

【請求項5】

前記待機時間は、前記ノード装置の初期化時間、前記ノード装置が状態変化を検出する状態変化検出時間、及び、各ノード装置から前記管理サーバに前記イベント通知が到達する通知所要時間のうちの最大である最大通知所要時間、のうちの１以上の時間を組み合わせ、組み合わせた時間の最大時間であることを特徴とする請求項１に記載の管理サーバ。

【請求項6】

前記ネットワークは、マルチホップ通信を行う光ネットワークであることを特徴とする請求項１～５のいずれか一つに記載の管理サーバ。

【請求項7】

複数のノード装置を有するネットワーク内における各ノード装置の動作状態及び各ノード装置間の接続状態を管理するネットワーク状態管理方法であって、
前記ノード装置から状態変化のイベント通知を受けた場合、前記イベント通知に対して前記イベント通知の受信時から予め設定した待機時間の計時を開始し、１つの前記待機時間の計時が終了した時点で前記待機時間を計時中の他のイベント通知があるか否かを判定し、前記待機時間を計時中の他のイベント通知がある場合、前記待機時間の計時が終了した前記イベント通知に対する処理を打ち切り、前記待機時間を計時中の他のイベント通知がない場合、各ノード装置に対する状態取得を実行することを特徴とするネットワーク状態管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のノード装置を有するネットワークの状態取得にかかる通信量を低減することができる管理サーバ及びネットワーク状態管理方法に関する。

【背景技術】

【0002】

複数のノード装置を有したネットワークでは、各ノード装置の動作状態や各ノード装置間の接続状態を管理する必要がある。この各ノード装置のネットワーク管理を定期的に行うネットワーク管理装置が提案されている（特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０００－２５９５２０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記の特許文献１では、各ノード装置に対して定期的に状態取得を行っているため、通信量が増大してしまう。一方、ノード装置から障害発生などの状態変化のイベント通知を受けるごとに、各ノード装置に対して状態取得を実行すると、連続して発生する状態変化のイベント通知に対してそれぞれに状態取得を実行することになり、ネットワーク管理のための通信量が増大する。

【0005】

本発明は、上記に鑑みてなされたものであって、複数のノード装置を有するネットワークの状態取得にかかる通信量を低減することができる管理サーバ及びネットワーク状態管理方法を提供することを目的とする。

【課題を解決するための手段】

【0006】

上述した課題を解決し、目的を達成するために、本発明にかかる管理サーバは、複数のノード装置を有するネットワーク内における各ノード装置の動作状態及び各ノード装置間の接続状態を管理する管理サーバであって、前記ノード装置から状態変化のイベント通知を受けた場合、前記イベント通知に対して前記イベント通知の受信時から予め設定した待機時間の計時を開始し、１つの前記待機時間の計時が終了した時点で前記待機時間を計時中の他のイベント通知があるか否かを判定し、前記待機時間を計時中の他のイベント通知がある場合、前記待機時間の計時が終了した前記イベント通知に対する処理を打ち切り、前記待機時間を計時中の他のイベント通知がない場合、各ノード装置に対する状態取得を実行することを特徴とする。

【0007】

また、本発明にかかる管理サーバは、上記の発明において、前記待機時間は、前記ノード装置が状態変化を検出する状態変化検出時間よりも長いことを特徴とする。

【0008】

また、本発明にかかる管理サーバは、上記の発明において、前記待機時間は、前記ノード装置の初期化時間に前記ノード装置が状態変化を検出する状態変化検出時間を加えた時間よりも長いことを特徴とする。

【0009】

また、本発明にかかる管理サーバは、上記の発明において、前記待機時間は、各ノード装置から前記管理サーバに前記イベント通知が到達する通知所要時間のうちの最大である最大通知所要時間よりも長いことを特徴とする。

【0010】

また、本発明にかかる管理サーバは、上記の発明において、前記待機時間は、前記ノード装置の初期化時間、前記ノード装置が状態変化を検出する状態変化検出時間、及び、各ノード装置から前記管理サーバに前記イベント通知が到達する通知所要時間のうちの最大である最大通知所要時間、のうちの１以上の時間を組み合わせ、組み合わせた時間の最大時間であることを特徴とする。

【0011】

また、本発明にかかる管理サーバは、上記の発明において、前記ネットワークは、マルチホップ通信を行う光ネットワークであることを特徴とする。

【0012】

また、本発明にかかるネットワーク状態管理方法は、複数のノード装置を有するネットワーク内における各ノード装置の動作状態及び各ノード装置間の接続状態を管理するネットワーク状態管理方法であって、前記ノード装置から状態変化のイベント通知を受けた場合、前記イベント通知に対して前記イベント通知の受信時から予め設定した待機時間の計時を開始し、１つの前記待機時間の計時が終了した時点で前記待機時間を計時中の他のイベント通知があるか否かを判定し、前記待機時間を計時中の他のイベント通知がある場合、前記待機時間の計時が終了した前記イベント通知に対する処理を打ち切り、前記待機時間を計時中の他のイベント通知がない場合、各ノード装置に対する状態取得を実行することを特徴とする。

【発明の効果】

【0013】

本発明によれば、逐次発生するネットワークの状態変化のイベント通知を一連のイベント通知とし、各イベント通知をまとめて各ノード装置に対する状態取得を実行するようにしているので、各ノード装置の状態取得にかかる通信量を減らすことができる。

【図面の簡単な説明】

【0014】

【図1】図１は、本発明の実施の形態である管理サーバを含むネットワークの概要構成を示す模式図である。

【図2】図２は、ノード装置の構成を示す機能ブロック図である。

【図3】図３は、ノード装置がリンクダウンした場合における管理サーバの状態取得処理を示すシーケンス図である。

【図4】図４は、管理サーバによる各ノード装置に対する状態取得処理手順を示す全体フローチャートである。

【図5】図５は、図４に示した状態取得処理の処理手順を示す詳細フローチャートである。

【図6】図６は、変形例１の管理サーバによる状態取得処理を示すシーケンス図である。

【図7】図７は、変形例２の管理サーバによる状態取得処理を示すシーケンス図である。

【図8】図８は、変形例３の管理サーバによる状態取得処理を示すシーケンス図である。

【発明を実施するための形態】

【0015】

以下、添付図面を参照して本発明を実施するための形態について説明する。

【0016】

＜装置構成＞
図１は、本発明の実施の形態である管理サーバ１を含むネットワーク２の概要構成を示す模式図である。ネットワーク２は、複数のノード装置Ｎを有し、各ノード装置Ｎの接続状態において各ノード装置Ｎ間で通信を行う。ネットワーク２は、例えば、メッシュ型の光ネットワークであり、マルチホップ通信を行う。ネットワーク２を構成する複数のノード装置Ｎを経由する通信経路を決定するルーティングプロトコルとしては、例えば、ＡＯＤＶ（Ad hoc On-Demand Distance Vector）ルーティングプロトコルを用いる。ＡＯＤＶルーティングプロトコルは、リアクティブ型ルーティングプロトコルであり、ノード装置Ｎのホップ数が小さい通信経路を決定する。

【0017】

一般的なＡＯＤＶルーティングプロトコルの概要は、まず、送信元ノード装置が経路要求パケット（ＲＲＥＱ：Route Request）を隣接ノード装置にブローキャストし、この経路要求パケットを受信したノード装置が、受信したノード装置以外の隣接ノード装置にブロードキャストすることを送信先ノード装置まで繰り返す。この際、経路要求パケットは、転送ごとに累積中継数（ホップ数）がインクリメントされる。そして、送信先ノード装置は、受信した複数の経路要求パケット内の中継数が最も少ない経路要求パケットが示す経路に対して経路回答パケット（ＲＲＥＰ：Route Reply）を送信元ノード装置にユニキャストする。各ノード装置は、経路要求パケットを受信した際、送信元、送信先、中継元、中継先を含む仮の経路テーブルを一時的に記憶しておき、所定時間内に経路回答パケットを受信した場合に仮の経路テーブルを経路テーブルとして記憶し、他の仮の経路テーブルを削除する。これにより、各ノード装置は、経路テーブルを用いて送信元ノード装置と送信先ノード装置との間の通信経路を決定する。

【0018】

図２は、ノード装置Ｎの構成を示す機能ブロック図である。図２に示すように、ノード装置Ｎは、パケット中継処理部１５に、記憶部１１，制御部１２、受信部１３－１～１３－ｎ、送信部１４－１～１４－ｎが接続される。パケット中継処理部１５は、制御部１２の制御に応じて、受信部１３―１～１３－ｎによって受信されたパケットを、そのヘッダに格納されている情報に応じて、対応する送信部１４－１～１４－ｎから送信する。制御部１２は、記憶部１１に記憶されている経路テーブルＲＴに応じて、パケット中継処理部１５を制御し、パケットを中継するとともに、最適経路を決定し、決定した経路テーブルＲＴを設定する。なお、受信部１３－１～１３－ｎと送信部１４－１～１４－ｎは、それぞれ対となって、他のノード装置Ｎとの間の通信経路にそれぞれ接続され、それぞれ他のノード装置Ｎとの間の送受信処理を行う。

【0019】

ノード装置Ｎの１つに、管理サーバ１が接続される。各ノード装置Ｎは、ノード装置Ｎの動作状態及びノード装置Ｎ間の接続状態が変化した場合、状態変化のイベント通知を管理サーバ１に通知する。例えば、図１に示すように、ノード装置ＮＡとノード装置ＮＢとの間がリンクダウンした場合、ノード装置ＮＡ，ＮＢはそれぞれリンクが確立しているノード装置Ｎを介して管理サーバ１に状態変化のイベント通知を送る。このイベント通知を受けた管理サーバ１は、各ノード装置Ｎに対する状態取得を実行する。

【0020】

ここで、本実施の形態の管理サーバ１は、ノード装置Ｎから状態変化のイベント通知を受けた場合、イベント通知に対してイベント通知の受信時から予め設定した待機時間の計時を開始し、１つの待機時間の計時が終了した時点で待機時間を計時中の他のイベント通知があるか否かを判定し、待機時間を計時中の他のイベント通知がある場合、待機時間の計時が終了したイベント通知に対する処理を打ち切り、待機時間を計時中の他のイベント通知がない場合、各ノード装置に対する状態取得を実行する。

【0021】

図３は、ノード装置ＮＡ，ＮＢがリンクダウンした場合における管理サーバ１の状態取得処理を示すシーケンス図である。図３に示すように、ノード装置ＮＡ，ＮＢがリンクダウンした場合、ノード装置ＮＡは、状態変化（リンクダウン）のイベント通知ｍ１を管理サーバ１に送信する。また、ノード装置ＮＢは、状態変化（リンクダウン）のイベント通知ｍ２を管理サーバ１に送信する。

【0022】

イベント通知ｍ１，ｍ２を受けた管理サーバ１は、各イベント通知ｍ１，ｍ２に対してイベント通知ｍ１，ｍ２の受信時から予め設定した待機時間Ｔの計時をそれぞれ開始する。そして、管理サーバ１は、イベント通知ｍ１に対する待機時間Ｔの計時が終了した時点で待機時間Ｔを計時中の他のイベント通知があるか否かを判定する。この場合、他のイベント通知としてイベント通知ｍ２が待機時間Ｔを計時中であるため、イベント通知ｍ１に対する処理を打ち切る。そして、管理サーバ１は、その後、イベント通知ｍ２に対する待機時間Ｔの計時が終了した時点で待機時間Ｔを計時中の他のイベント通知がないため、この時点で、各ノード装置Ｎに対して状態取得のメッセージｍｍを送信して各ノード装置Ｎの状態を取得する。

【0023】

本実施の形態では、各イベント通知ｍ１，ｍ２の受信ごとに各ノード装置Ｎに対する状態取得の処理を実行せず、イベント通知ｍ１，ｍ２を一連のイベント通知とし、各イベント通知ｍ１，ｍ２をまとめて各ノード装置Ｎに対する状態取得を実行するようにしているので、各ノード装置Ｎの状態取得にかかる通信量を減らすことができる。

【0024】

＜状態取得処理＞
図４は、管理サーバ１による各ノード装置Ｎに対する状態取得処理手順を示す全体フローチャートである。図４に示すように、管理サーバ１は、まず、ノード装置Ｎから状態変化のイベント通知があったか否かを判定する（ステップＳ１０１）。イベント通知がない場合（ステップＳ１０１：Ｎｏ）、ステップＳ１０１の判定処理を繰り返す。一方、イベント通知があった場合（ステップＳ１０１：Ｙｅｓ）、状態取得処理を実行し（ステップＳ１０２）、ステップＳ１０１に戻って上記の処理を繰り返す。なお、ステップＳ１０２の状態処理取得は、サブルーチンではなく、その都度、状態取得処理のスレッドを起動するものであり、状態取得処理後、ステップＳ１０２に戻らずに処理を終了し、１以上のスレッドが並列した起動状態を許容するものである。

【0025】

また、図５は、図４に示した状態取得処理の処理手順を示す詳細フローチャートである。図５に示すように、管理サーバ１は、まず受信したイベント通知の受信時から待機時間Ｔの計時を開始する（ステップＳ２０１）。その後、管理サーバ１は、待機時間Ｔの計時が終了したか否かを判定する（ステップＳ２０２）。待機時間Ｔの計時が終了しない場合（ステップＳ２０２：Ｎｏ）、本判定処理を繰り返す。

【0026】

一方、待機時間Ｔの計時が終了した場合（ステップＳ２０２：Ｙｅｓ）、さらに、他の待機中の状態取得処理があるか否かを判定する（ステップＳ２０３）。他の待機中の状態取得処理がある場合（ステップＳ２０３：Ｙｅｓ）、本処理を終了する。これに対し、他の待機中の状態取得処理がない場合（ステップＳ２０３：Ｎｏ）、このイベント通知に対する状態取得の実行を行って（ステップＳ２０４）、本処理を終了する。すなわち、イベント通知に対する状態取得のために、各ノード装置Ｎに対して状態取得のメッセージを送信して各ノード装置Ｎの状態を取得し、本処理を終了する。

【0027】

＜変形例１＞
図６は、変形例１の管理サーバ１による状態取得処理を示すシーケンス図である。変形例１では、待機時間Ｔを、ノード装置が状態変化を検出する状態変化検出時間Ｔｄよりも長い時間（待機時間ＴＡ）としている。

【0028】

図６に示すように、ノード装置ＮＡ，ＮＢは状態変化（リンクダウン）が発生した場合、ノード装置ＮＡ，ＮＢはそれぞれイベント通知ｍ１０，ｍ１１を管理サーバ１に通知する。

【0029】

ここで、管理サーバ１は、各イベント通知ｍ１０，ｍ１１の受信時に、各イベント通知ｍ１０，ｍ１１の受信時から待機時間ＴＡを計時する。待機時間ＴＡは、状態変化検出時間Ｔｄよりも長いため、各イベント通知ｍ１０，ｍ１１は、待機時間ＴＡの期間内に発生する。図６では、イベント通知ｍ１０が先に管理サーバ１に通知されるため、イベント通知ｍ１０の待機時間ＴＡの終了時点では、イベント通知ｍ１１の待機時間ＴＡは計時中であり、イベント通知ｍ１０の処理は打ち切られる。

【0030】

その後、イベント通知ｍ１１の待機時間ＴＡの終了時点で、待機時間ＴＡを計時中の他のイベント通知がない場合、イベント通知ｍ１１の待機時間ＴＡの終了時点において、各ノード装置Ｎに対する状態取得が実行されるが、図６では、イベント通知ｍ１１の待機時間ＴＡ中に、ノード装置ＮＡ，ＮＢの状態変化（リンクアップ）が発生し、状態変化検出時間Ｔｄ後に、ノード装置ＮＡ，ＮＢからそれぞれイベント通知ｍ１２，ｍ１３が管理サーバ１に通知され、各イベント通知ｍ１２，ｍ１３に対する待機時間ＴＡがそれぞれ計時されている。このため、イベント通知ｍ１１の待機時間ＴＡの終了時点で、イベント通知ｍ１２，ｍ１３に対する待機時間ＴＡが計時中であり、イベント通知ｍ１１の処理は打ち切られる。

【0031】

同様にして、イベント通知ｍ１２の待機時間ＴＡの終了時点で、イベント通知ｍ１３の待機時間ＴＡが計時中であり、イベント通知ｍ１２の処理は打ち切られる。そして、イベント通知ｍ１３の待機時間ＴＡの終了時点で、待機時間ＴＡを計時中の他のイベント通知がないため、イベント通知ｍ１３の待機時間ＴＡの終了時点において、管理サーバ１は、各ノード装置Ｎに対してメッセージｍｍを送信して、各ノード装置Ｎの状態を取得する。

【0032】

本変形例１では、待機時間ＴＡを状態変化検出時間Ｔｄよりも長くしているので、通信ケーブルの曲がりなどによる通信が不安定となって接続されているノード装置間がリンクダウンした場合であっても、接続されていたノード装置ＮＡ，ＮＢのイベント通知を一連のイベント通知としてまとめて一回のノード装置Ｎに対する状態取得を実行している。これにより、ノード装置Ｎに対する状態取得の通信量を減少させることができる。

【0033】

＜変形例２＞
図７は、変形例２の管理サーバ１による状態取得処理を示すシーケンス図である。変形例２では、待機時間Ｔを、ノード装置Ｎの停止後におけるノード装置Ｎの初期化（起動）時間Ｔｓと状態変化検出時間Ｔｄとの合計時間よりも長い時間（待機時間ＴＢ）としている。

【0034】

図７に示すように、ノード装置ＮＢが停止した場合、ノード装置ＮＢに接続されていたノード装置ＮＡは、状態変化（リンクダウン）のイベント通知ｍ２０を、ノード装置ＮＡが状態変化を検出する状態変化検出時間Ｔｄ後に管理サーバ１に通知する。

【0035】

その後、ノード装置ＮＢは起動され、初期化時間Ｔｓ後に、ノード装置ＮＢは初期化が完了する。このノード装置ＮＢの初期化により、ノード装置ＮＡとノード装置ＮＢとがリンクアップし、ノード装置ＮＡは、リンクアップから状態変化検出時間Ｔｄ後に、状態変化（リンクアップ）のイベント通知ｍ２１を管理サーバ１に通知する。同様にして、ノード装置ＮＢは、ノード装置ＮＡとの間の接続確立により、リンクアップから状態変化検出時間Ｔｄ後に、状態変化（リンクアップ）のイベント通りｍ２２を管理サーバ１に通知する。

【0036】

ここで、管理サーバ１は、各イベント通知ｍ２０，ｍ２１，ｍ２２の受信時に、各イベント通知ｍ２０，ｍ２１，ｍ２２の受信時から待機時間ＴＢを計時する。待機時間ＴＢは、ノード装置Ｎの初期化時間Ｔｓに状態変化検出時間Ｔｄを加えた時間よりも長い時間としている。このため、イベント通知ｍ２０の待機時間ＴＢの計時終了の時点で、イベント通知ｍ２１，ｍ２２２の待機時間ＴＢが計時中であるため、イベント通知ｍ２０に対する処理は打ち切られる。そして、イベント通知ｍ２１の待機時間ＴＢの計時終了の時点でも、イベント通知ｍ２２の待機時間ＴＢが計時中であるため、イベント通知ｍ２１に対する処理は打ち切られる。その後、イベント通知ｍ２２の待機時間ＴＢの計時終了の時点で、待機時間ＴＢを計時中のイベント通知がないため、イベント通知ｍ２２の待機時間ＴＢの終了の時点で、管理サーバ１は、各ノード装置Ｎに対してメッセージｍｍを送信して、各ノード装置Ｎの状態を取得する。

【0037】

本変形例２では、待機時間ＴＢをノード装置Ｎの初期化時間Ｔｓに状態変化検出時間Ｔｄを加えた時間よりも長くしているので、ノード装置Ｎの停止に対するイベント通知からノード装置Ｎの起動（再起動）によるリンクアップに対するイベント通知までの間に発生するイベント通知をまとめられ、１つの状態取得処理を行うようにしている。具体的には、イベント通知ｍ２０，ｍ２１，ｍ２２を一連のイベント通知としてまとめて一回のノード装置Ｎに対する状態取得を実行している。これにより、ノード装置Ｎに対する状態取得の通信量を減少させることができる。

【0038】

＜変形例３＞
図８は、変形例３の管理サーバ１による状態取得処理を示すシーケンス図である。変形例３では、待機時間Ｔとして、各ノード装置Ｎから管理サーバ１にイベント通知が到達する通知所要時間のうちの最大である最大通知所要時間Ｔｘよりも長い時間（待機時間ＴＣ）としている。なお、最大通知所要時間Ｔｘは、例えば、隣接ノード装置間の転送所要時間に、マルチホップによるネットワーク２内の最大転送回数を乗算した値である。

【0039】

図８に示すように、ノード装置ＮＡ，ＮＢは状態変化（リンクダウン）が発生し、それぞれイベント通知ｍ３１，ｍ３２を管理サーバ１に通知する。また、ノード装置ＮＣは、イベント通知ｍ３１，ｍ３２の後、単独の他の状態変化が発生し、イベント通知ｍ３３を管理サーバ１に通知する。

【0040】

ここで、管理サーバ１は、各イベント通知ｍ３１，ｍ３２，ｍ３３の受信時に、各イベント通知ｍ３１，ｍ３２，ｍ３３の受信時から待機時間ＴＣを計時する。各イベント通知ｍ３１～ｍ３３は、同時に状態変化が生じても、ネットワーク２内のホップ数などによって管理サーバ１の受信時点が異なる。待機時間ＴＣは、この各イベント通知ｍ３１～ｍ３３の通知時間差を吸収できるようにしており、短時間に発生した多くのイベント通知に対してそれぞれ個別に状態取得を実行せずに、一回の状態取得のみを実行するようにしている。

【0041】

具体的に、イベント通知ｍ３１の待機時間ＴＣの終了時点で、イベント通知ｍ３２，Ｍ３３の待機時間ＴＣは計時中であるため、イベント通知ｍ３１に対する処理は打ち切られる。その後、イベント通知３２の待機時間ＴＣの終了時点で、イベント通知ｍ３２の待機時間ＴＣは計時中であるため、イベント通知ｍ３２に対する処理は打ち切られる。さらに、その後、イベント通知３３の待機時間ＴＣの終了時点で、他のイベント通知はないため、この時点で状態取得が実行される。

【0042】

本変形例３では、待機時間ＴＣを最大通知所要時間Ｔｘよりも長くしているので、少なくとも、ほぼ同時に発生した状態変化に伴う複数のイベント通知に対する状態取得の実行を一回のみで行うことができる。これにより、ノード装置Ｎに対する状態取得の通信量を減少させることができる。

【0043】

なお、待機時間Ｔは、ノード装置の初期化時間Ｔｓ、状態変化検出時間Ｔｄ、及び、最大通知所要時間Ｔｘ、のうちの１以上の時間を組み合わせ、組み合わせた時間の最大時間としてもよい。

【0044】

また、上記の実施の形態及び変形例では、マルチホップ通信を行う光ネットワークを例にあげて説明したが、これに限らず、ネットワーク２は複数のノード装置Ｎによって接続されるものであればよく、また、光以外の有線ネットワークや無線ネットワークにも適用でき、一部に光以外の有線ネットワークや無線ネットワークを含むものであってもよい。

【0045】

以上、本発明者らによってなされた発明を適用した実施の形態及び変形例について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例、及び運用技術等は全て本発明の範疇に含まれる。

【符号の説明】

【0046】

１ 管理サーバ
２ ネットワーク
１１ 記憶部
１２ 制御部
１３－１～１３－ｎ 受信部
１４－１～１４－ｎ 送信部
１５ パケット中継処理部
ｍ１，ｍ２，ｍ１０，ｍ１１，ｍ１２，ｍ２０，ｍ２１，ｍ３１，ｍ３２，ｍ３３ イベント通知
ｍｍ メッセージ
Ｎ，ＮＡ，ＮＢ，ＮＣ ノード装置
ＲＴ 経路テーブル
Ｔ，ＴＡ，ＴＢ，ＴＣ 待機時間
Ｔｄ 状態変化検出時間
Ｔｓ 初期化時間
Ｔｘ 最大通知所要時間

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】