JPH08265367A

JPH08265367A - ネットワーク管理・情報収集方式

Info

Publication number: JPH08265367A
Application number: JP7061370A
Authority: JP
Inventors: 康一 ▲高▼瀬; Koichi Takase; Hideyuki Matsuda; 英幸松田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1995-03-20
Filing date: 1995-03-20
Publication date: 1996-10-11
Also published as: US5822535A

Abstract

(57)【要約】【目的】問合わせパケットと応答パケットが、周期に合
わせて集中してネットワークの中に流れ込んでしまうと
いう問題を解決するシステムを提供する。【構成】収容するノードをアクスセスするための回線網
と、回線網に収容された複数の被管理ノードと、回線網
に収容され、被管理ノードにアクセスして被管理ノード
の情報を収集する管理ノードを有し、管理ノードは、周
期的に情報を収集する際に、要求毎の許容応答時間とネ
ットワーク遅延値から、まとめて応答できる収集情報量
を計算し、計算した量の情報を蓄積して応答する様に該
被管理ノードに要求するアクセス手段を含み、被管理ノ
ードは、管理ノードの該アクセス手段に応じて周期的に
情報を収集蓄積し、蓄積情報を一度に該管理ノードに応
答する該被管理ノードのアクセス手段を有する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、回線網に収容された情
報処理機器や通信機器で構成されたネットワークの管理
を行う方式に関し、特に、管理ノードにより被管理ノー
ドから被管理ノードに繋がる装置の管理情報を収集する
ネットワーク管理・情報収集方式に関する。

【０００２】

【従来の技術】従来のＷＡＮ（広域ネットワーク）／Ｌ
ＡＮ（ローカルネットワーク）等のネットワークにおけ
る基本的な保守情報等の情報収集方式を図１８及び図１
９を用いて説明する。

【０００３】図１８において、２００は、ネットワーク
（回線網）であり管理ノード１００及び複数の被管理ノ
ード３００（図では、説明を簡略にするために一の被管
理ノードのみ示されている）が収容されている。また、
被管理ノード３００には、複数の監視対象装置３１０が
接続されている（図において、同様に一の監視対象装置
のみ示されている）。

【０００４】ここで、管理ノード１００から被管理ノー
ド３００に管理情報の問い合わせを指示するデータ（例
えば、Ｑ_Xインタフェースではｍ−ＧＥＴに相当し、以
下問い合わせパケットＩＰと呼ぶ）を送る。

【０００５】上記問い合わせパケットＩＰには、図１９
に示すように、管理の対象となる装置３１０の名前ａ
（以下管理対象名称と呼ぶ）、当該装置３１０の中で収
集対象となる情報の名前ｂ（以下属性名称と呼ぶ）、問
い合わせパケットＩＰ自身の識別子ｃ（以下インボーグ
ＩＤと呼ぶ）等を含む。

【０００６】上記問い合わせパケットＩＰを受信した被
管理ノード３００は、パケット内の装置名称ａ／属性名
称ｂに対応する情報（以下属性値と呼ぶ）を収集し、パ
ケット内のインボーグＩＤと収集した時間ｄ（以下現在
時刻と呼ぶ）を付与してデータを編集する。

【０００７】編集したデータを問い合わせパケットに対
する応答として回線網２００を介して管理ノード１００
に送る（以下、応答として送られるデータを応答パケッ
トＲＰと呼ぶ。）上記応答パケットＲＰを受信した管理ノード１００は、
インボーグＩＤによりどの問い合わせパケットに対応す
るのかを判別し、所定の位置（例えば補助記憶装置）に
属性値を格納する。以上のようにして情報収集が完了す
る。

【０００８】尚、管理の対象となる装置３１０として
は、通信制御装置の如き周辺装置から被管理ノード内の
ＣＰＵ、プリンタ装置等も含まれる。

【０００９】また、ＬＡＮをＷＡＮに接続する場合、情
報伝達の前処理／後処理としてプログラムが接続を認識
するための論理的なコネクション（以下このコネクショ
ンを呼と呼ぶ）の設定／開放が必要とされている。

【００１０】ここで、かかる情報伝達の前処理／後処理
を効率化する方式として提案されている従来技術として
以下のものがある。

【００１１】特開昭６２−２３４４４２号公報に記載さ
れる技術は、補助記憶装置に、ＷＡＮを介して接続され
る情報処理装置に関する情報を蓄積し、その情報に基づ
いてダイヤリングを行うものである。

【００１２】特開平５−１５３１２１号公報に記載され
る技術は、ポート（呼を設定する為の資源）数の多い被
管理ノードを経由して別の被管理ノードを管理し、その
接続構成を学習していくことにより、回線交換ＷＡＮ間
接続でも呼を確保して経済的に常時監視を行うものであ
る。

【００１３】また、ＯＳＩ（Open System Interconnect
ion:開放型システム間相互接続）のシステム管理におい
ては、管理の対象となる装置等がオブジェクト指向のモ
デルリング（模型化）手法に基づいて定義され、その管
理情報構造がＩＳＯ／ＩＥＣＤＰ１０１６５−１，２，
３において記述形式として標準化されている。

【００１４】この管理情報構造（管理情報ベース：ＭＩ
Ｂ）を構築する方式として、特開平４−８４２４９号公
報に記載され、情報パターンと各管理対象の宛先をテー
ブル化して通信相手を検索するものである。

【００１５】

【発明が解決しようとする課題】上記した各方式に基づ
いて管理情報の収集を行った場合、例えば管理ノードの
アプリケーション利用者から「一定時間例えば、１０秒
間隔で周期的に、適当な時間の間中、情報を取得して欲
しい」という要求が発生するものとすると、ネットワー
ク内の負荷状態に関係なく周期的に管理ノード１００か
ら問い合わせパケットＩＰとそれに対する応答パケット
ＲＰが被管理ノード３００から発生することになる。

【００１６】また、Ｑ_Xインタフェースでは、ｍ−Ｌｉ
ｎｋｅｄ−Ｒｅｐｌｙというプロトコルを用いて応答の
中間／最終を指定し、再度の問い合わせを省略するイン
タフェースが存在する。しかし、それでも収集回数分の
応答パケットＲＰが発生してしまう。

【００１７】更に、上記のアプリケーション利用者の要
求における問い合わせ先が複数となった場合（以下これ
を、ブロードキャストと呼ぶ）、問い合わせパケットＩ
Ｐとそれに対する応答パケットＲＰが、上記の周期に合
わせて集中してネットワークの中に流れ込んでしまうと
いう問題がある。

【００１８】かかる場合は、ネットワーク負荷が増大
し、これに伴い、他の通信が遅延する等の悪影響が生じ
る。

【００１９】本発明は、上記の従来の問題点を解消する
ネットワーク管理・情報収集方式を提供することを目的
とする。

【００２０】

【課題を解決するための手段及び作用】したがって、上
記目的を達成するために、本発明にしたがうネットワー
ク管理・情報収集方式は、管理ノード１００において、
適当な蓄積回数を指定して問い合わせパケットを送信
し、被管理ノード３００は、指定された時間間隔で上記
の蓄積回数分情報を収集した後、収集した情報を一つの
応答パケットにまとめて管理ノードに送信する。

【００２１】かかる方式により応答パケットの数を減ら
すことができ、集中してネットワークの中に流れ込んで
しまうという問題が解決できる。

【００２２】更に、本発明にしたがうネットワーク管理
・情報収集方式は、被管理ノードが、蓄積した情報を応
答パケットにまとめる時に、連続して同じ属性値のデー
タが並んでいる場合にはその２つ目以降の属性値は削除
して応答パケットを編集し、応答パケットを受け取った
管理ノードは属性値に付与されている現在時刻を参照し
て削除された情報を復元する。

【００２３】これにより、ネットワークに流れるデータ
量を縮小化できる。

【００２４】また、本発明にしたがうネットワーク管理
・情報収集方式は、被管理ノードが、事前に自分で使っ
ているネットワーク機器の負荷状態を監視して、応答パ
ケット送信時に負荷が高い場合には編集を延期し、負荷
が下がるまで蓄積を続け、下がった時点で編集し直して
管理ノードへの応答パケットの送信を行う様にする。

【００２５】これにより、ネットワークに流れるデータ
量を縮小化でき、更にネットワーク負荷の集中を回避す
ることが出来る。

【００２６】更にまた本発明にしたがうネットワーク管
理・情報収集方式は、前記課題で挙げたブロードキャス
トの問い合わせ要求に対して、管理ノードは、上記手段
における蓄積回数に問い合わせ先毎に違った値を設定す
る。

【００２７】これにより問い合わせパケットを送信する
ことにより、被管理ノードからの応答パケットが送られ
てくる時刻を適当に分散させることが出来る。

【００２８】更に、本発明にしたがうネットワーク管理
・情報収集方式は、適当な分散の中で同時に応答パケッ
トを送信する被管理ノードの組について、問い合わせパ
ケットを被管理ノード同士の間で送受信し、続いて応答
パケットも問い合わせパケットを伝達した被管理ノード
同士で送受信して、各自の蓄積した情報を順次付加し、
一番最後の被管理ノードからの応答パケットのみ、管理
ノードへ送信する。

【００２９】これにより、管理ノードに送られてくる応
答パケットの集中を回避することができる。

【００３０】

【実施例】以下図面にしたがい本発明の好適な実施例を
説明する。尚、図において同一または類似のものには同
一の参照番号及び記号を付して説明する。［実施例構成ブロック図の説明］図１は、本発明が適用
されるネットワーク構成の一例のブロック図である。一
つの管理ノード１００と、これに対応する複数（図では
４つが示される）の被管理ノード３０１〜３０４がネッ
トワーク２００に収容されている。更に、被管理ノード
３０１〜３０４の各々には、複数の管理対象装置３１０
〜３１７が繋がっている。

【００３１】管理ノード１００は、そのモジュール構成
例が図２に示すごとくである。各被管理ノード３００
（以下、図１の被管理ノード３０１〜３０４を代表して
必要により参照数字３００で表す）は、図３に示すモジ
ュール構成例を有するものである。

【００３２】図１に戻ると、被管理ノード３０１〜３０
４の内、被管理ノード３０３と被管理ノード３０４は、
条件によって呼４３４により論理的に接続されることを
示している。即ち、後述する群管理制御により、呼４３
４により論理的に接続されるように示されている。尚、
４つの被管理ノード３０１〜３０４の内、２つのみ接続
される状態は、本実施例ではありえないが、簡単化のた
め上記のような構成にして示している。

【００３３】図２と図３においては、管理ノード１００
も被管理ノード３００も、それぞれソフトウェア・シス
テム４００／４１０とタイマ１２０／３２０とメモリ１
３０／３３０と、それらを繋ぐ伝送路１７０／３７０か
ら構成される。

【００３４】この伝送路１７０／３７０によって、外付
けの補助記憶装置１４０／３４０と繋がり、特に被管理
ノード３００の場合は、対応する管理対象装置３１０〜
３１７に接続される通信路５００に繋がっていることを
示している。

【００３５】また管理ノード１００も被管理ノード３０
０も、ソフトウェア・システム４００／４１０の中で汎
用的な通信制御モジュール１５０／３５０を有してい
る。更に、本発明の特徴となる機能を有する管理システ
ム部分の各モジュール（１６１〜１６５／３６１〜３６
４）からの要求に従ってネットワーク２００に対して送
受信を行うことを示している。

【００３６】図２の例では、管理ノード１００はソフト
ウェア・システム４００の中にアプリケーション利用者
１１０を有しており、上記管理ノード１００に対して外
から要求が発せられることを示している。

【００３７】尚、実際のアプリケーション利用者１１０
はＷＳ端末やコンソール端末に接続され、上記管理ノー
ドをアクセスしながらメッセージの入出力を行うことが
容易に想定される。

【００３８】また図２では、管理ノード１００は、メモ
リ１３０の中から上記アプリケーション利用者１１０の
要求毎に作業域１３１を切り出してテーブル等に使用す
ること、更に補助記憶装置１４０には事前に設定された
定義ファイル１４１と被管理ノード一覧ファイル１４２
を有することを示している。

【００３９】定義ファイル１４１は、収集要求を予定す
る為に必要な情報が記述されており、被管理ノード一覧
ファイル１４２は管理対象となるノード／各ノードが持
つ管理対象装置／被管理ノードをグループ分け（以下群
制御と称し、詳細は後述する）の為に必要な情報が記述
されている。更に、各ファイルの詳細な情報も、同様に
後述する。

【００４０】図３では、被管理ノード３００は、上記ソ
フトウェア・システム４１０の上記管理システム部分の
中にある管理対象モジュール３６４により、伝送路３７
０を通して各管理対象装置を監視するとともに通信制御
モジュール３５０にアクセスすることを示している。

【００４１】従って、伝送路３７０に繋がるタイマ３２
０、メモリ３３０、補助記憶装置３４０も、管理ノード
１００における定義により管理対象装置として登録する
ことが可能である。

【００４２】また図３において、被管理ノード３００
は、ネットワーク２００を通して送られて来た管理ノー
ド１００からの問い合わせ要求ＩＰにより、補助記憶装
置３４０に蓄積情報フィアル３４１と既存ノードファイ
ル３４２が生成される。［プロトコル上の留意点］実施例では、問い合わせパケ
ットとして、動作実行要求（ｍ−Ａｃｔｉｏｎ）を使用
している。

【００４３】なお、プロトコルパラメータの指定により
ＣＣＩＴＴ勧告に基づくＱ_Xインタフェースの取得要求
（ｍ−Ｇｅｔ）でも実装可能である。特に、Ｑ_Xインタ
フェースの変わりにＵＮＩＸネットワークで実際的な標
準になっているＳＮＭＰプロトコルを使用した場合は、
動作実行要求プロトコルがサポートされない為、取得要
求（ｍ−Ｇｅｔ）を使用した実装が必要になる。

【００４４】但し、拡張性の面で動作実行要求（ｍ−Ａ
ｃｔｉｏｎ）による実装より劣ると想定できる。また応
答のパケットとして、一部事象報告（ｍ−ＥｖｅｎｔＲ
ｅｐｏｒｔ）を使用している。これはＱ_Xインタフェー
スとＳＮＭＰ両者で適応可能なプロトコルである。

【００４５】動作実行要求には「操作値」というパラメ
ータがあり、管理ノード１００と被管理ノード３００の
間で動作実行要求（ｍ−Ａｃｔｉｏｎ）が要求する動作
の内容を自由に取り決めて、操作値パラメータに値を割
り付けることができる。

【００４６】本実施例では、以下の動作内容を定義して
いる。

【００４７】操作値＝Ｘ：パラメータとして送る、既に
管理対象装置の生成を依頼してある被管理ノード３００
の一覧を記憶する。

【００４８】操作値＝Ｙ：指定の蓄積回数分、管理対象
装置の属性値を蓄積してまとめて応答する。

【００４９】操作値＝Ｚ：指定の蓄積回数分の管理対象
装置の属性値の蓄積を開始して応答する。

【００５０】操作値＝Ｗ：これ迄に蓄積してある属性値
を本動作実行要求に付加し、パラメータで指定してある
次の被管理ノードの指定に従って本動作実行要求を転送
する。その際、指定が在れば、指定の蓄積回数分の管理
対象の属性値の蓄積を再開する。［プロトコルの流れの説明］以下に、プロトコルの流れ
を、図を参照しながら項目に分けて説明する。また、理
解容易のために、プロトコルの流れに沿って処理ノード
が移る度に、行先頭に“＊”印を付与している。

【００５１】以下において、特にその都度断りを置かな
いが、管理ノード１００及び被管理ノード３００のソフ
トウェア・システム４００／４１０は、データ送信する
時には、データ編集モジュール１６２／３６２に対して
送信するパケットのフォーマット設定を依頼し、通信制
御モジュール１５０／３５０にデータ送信を依頼すると
いう手順を踏む。

【００５２】反対に、データを受信する時には、通信制
御モジュール１５０／３５０からの通知の受け取り、デ
ータ編集解析モジュール１６２／３６２に対して通知の
中の情報の、分解引き渡しを要求するという手順を踏
む。（１）管理開始時の情報分配処理のプロトコル：図４、
図５は、ネットワーク管理システム立上げの時点で、情
報取得要求を行う為に必要な情報を管理ノード１００か
ら被管理ノード３００に転送する処理プロトコルにおけ
る送受信フローを示したものである。尚、図４、図５は
一連のフローを図面の関係で分割して示してある。

【００５３】＊：管理ノード１００の中では、システム
立上要求をアプリケーション利用者１１０から受け取る
と、要求管理モジュール１６１は、補助記憶装置１４０
から被管理ノード一覧ファイル１４２を読み出す。

【００５４】その内容に沿って被管理ノード３０１〜３
０４対応に呼４０１から呼４０４を順次設定しながら、
各被管理ノード３０１から３０４に対して管理の対象と
なる装置を管理対象生成パケット（Ｑ_Xインタフェース
ではｍ−Ｃｒｅａｔｅ）によって通知する（ステップＳ
１）。

【００５５】例えば、図４において、管理ノード１００
と被管理ノード３０１との間に呼設定４０１が行われ、
同時に管理ノード１００から被管理ノード３０１への
（ｍ−Ｃｒｅａｔｅ）に対して、被管理ノード３０１か
ら応答が管理ノード１００に送られる。

【００５６】上記パケット通知後、既に同パケットを送
出済の被管理ノードのアドレスの一覧を、操作値＝Ｘの
問い合わせパケット６１１〜６１４により通知する。例
えば、被管理ノード３０３へ送られるパケット６１３
（図５参照）は、問い合わせパケット送出済管理ノード
３０１と３０２のアドレスを、送信した順と逆の順にリ
ストにして通知する（ステップＳ２）。

【００５７】＊：被管理ノード３０１〜３０４では、要
求受付モジュール３６１が、管理対象生成パケット受信
時に、管理対象管理モジュール３６４に対して指定され
た管理対象装置への管理アクセス手段確立を要求する。
その結果を管理ノード１００に応答する。また問い合わ
せパケット６１１〜６１４の受信時に、補助記憶装置３
４０に既存ノードファイル３４２を作成し、その結果を
応答パケットで管理ノード１００に通知する（ステップ
Ｓ３）。

【００５８】＊：管理ノード１００は、かかる応答パケ
ットから被管理ノードでの作業の結果を取り出し、被管
理ノード一覧ファイル１４２に反映して一時呼４０１〜
４０４を解放切断する（ステップＳ４）。（２）管理対象追加時の情報分配処理のプロトコル：図
６は、例えば図４、図５のフローにしたがい図１に示す
ような構成において、呼設定４０１〜４０４を形成した
後に、新たに被管理ノード３０５を追加した場合の管理
ノード１００と被管理ノード３０５の間で行われるパケ
ットの送受信のフローを示すものである。

【００５９】＊：管理ノード１００の中で被管理ノード
３０５の追加をアプリケーション利用者１１０から受け
取ると、要求管理モジュール１６１は被管理ノード一覧
ファイル１４２に要求された被管理ノード３０５の情報
を追加する。そして（１）管理開始時の情報分配処理の
プロトコル：と同様に、被管理ノード３０５との間に呼
４０５を設定し、管理の対象となる装置を管理対象生成
パケットで通知する（ステップＳ１）。

【００６０】その後、操作値＝Ｘの問い合わせパケット
で既存の被管理ノード３０１〜３０４のアドレスを３０
４から降順にリストにして通知する（ステップＳ２）。

【００６１】＊：被管理ノード３０５は、（１）管理開
始時の情報分配処理のプロトコル：における被管理ノー
ド３０１〜３０４の処理と同様に、既存ノードファイル
３４２を生成して、管理アクセス手段の確立を行い、各
処理の結果を応答パケットで通知する（ステップＳ
３）。

【００６２】＊：管理ノード１００は、応答パケットか
ら被管理ノード３０５での作業の結果を取り出し、被管
理ノード一覧ファイル１４２に反映して呼４０５を開放
切断する（ステップＳ４）。（３）一つの被管理ノードに収集を依頼する時のプロト
コル：図７は、上記（１）管理開始時の情報分配処理の
プロトコル：で示したプロトコルのフローによって図１
のネットワーク構成が形成された後、アプリケーション
利用者１１０より被管理ノード３０１で管理している装
置の情報を収集するように依頼される時の管理ノード１
００と被管理ノード３０１との間で行われるデータ送受
信の様子を示すものである。

【００６３】＊：管理ノード１００の中で、要求管理モ
ジュール１６１はアプリケーション利用者１１０から情
報収集の要求を受け付けると、既に処理中になっている
収集要求のスケジュールを確認する。

【００６４】被管理ノード一覧情報ファイル１４２の情
報の一部を、メモリ１３０から切り出した領域１３１に
展開した後、スケジューリングモジュール１６３に被管
理ノード３０１のアクセスとなる契機の計算を依頼する
（ステップＳ５）。

【００６５】スケジューリングモジュール１６３は、定
義ファイル１４１を読み込み、その中の情報とアプリケ
ーション利用者１１０から与えられた収集回数／収集間
隔／応答許容時間をパラメータにして以下の値を計算す
る。

【００６６】ａ）問い合わせ数：被管理ノードに問い合
わせパケットを送信する回数ｂ）最終蓄積回数：最後の、問い合わせの応答で、被管
理ノードから一度に渡してもらう情報の収集回数ｃ）中間蓄積回数：最終以外の問い合わせの応答で、被
管理ノードから一度に渡してもらう情報の収集回数尚、これらの計算方法については、後に説明する。

【００６７】上記の値を算出後、メモリ領域１３１に展
開されたテーブルに出力値を書き込み、要求管理モジュ
ール１６１に制御を戻す。

【００６８】要求管理モジュール１６１は、返却された
上記ｃ）の情報とアプリケーション利用者１１０から渡
された収集間隔とを操作値＝Ｙの問い合わせパケット６
２１１に展開して、装置を管理している被管理ノード３
０１へ送信する（ステップＳ６）。

【００６９】＊：問い合わせパケット６２１１を受けた
被管理ノード３０１では、要求受付けモジュール３６１
が、補助記憶装置３４０に蓄積情報ファイル３４１を作
成し、管理対象管理モジュール３６４に、対応する管理
対象装置の属性値の収集を依頼する（ステップＳ７）。

【００７０】管理対象モジュール３６４から情報を受け
取ると要求受付モジュール３６１は、上記で作成した蓄
積情報ファイル３４１に現時刻と受け取った情報を書き
込む。ついで、時計管理モジュール３６３に上記の問い
合わせパケット６２１１に入っていた収集間隔で周期的
に通知する様に依頼する。

【００７１】これに応じて、時計管理モジュール３６３
がタイマ３２０を使用して周期的な通知を行い、要求受
付モジュール３６１は管理対象管理モジュール３６４
に、対応する管理対象装置の属性値の収集を、再度依頼
する。

【００７２】管理対象管理モジュール３６４から収集情
報を受け取ると、前回に収集した属性と比較して、違う
値の場合には、蓄積情報ファイル３４１に現時刻と受け
取った情報を追加して書き込みを行う。

【００７３】以上の処理を繰り返し、上記の蓄積回数分
〔元は上記ｃ）の値〕の管理対象管理モジュール３６４
に対する要求を終わる。そして、要求受付モジュール３
６１は、次に管理対象管理モジュール３６４に、通信制
御モジュール３５０の負荷状態の情報収集を依頼する。

【００７４】この負荷状態の値は、ＬＡＮの場合は衝突
頻度、ＷＡＮの場合はフロー制御パケットの返却時間が
反映される。負荷状態の値が、一定基準値（プログラム
内に静的に保持される値）より高い場合は、応答パケッ
トの送信を延期して、再度時計管理モジュール３６３か
らの情報収集のタイムアウト待ちを行う（ステップＳ
７）。

【００７５】負荷が無いと判断した場合は、応答パケッ
ト６２１１に、蓄積情報ファイル３４１０内の情報の全
てと現在の時刻を展開して、管理ノード１００へ送信
し、時計管理モジュール３６３に対しては、上記により
依頼していた周期的な通知を終了する様に依頼する（ス
テップＳ８）。

【００７６】＊：応答パケット６２１１を受け取った管
理ノード１００では、要求管理モジュール１６１がメモ
リ１３１を参照し、中間蓄積回数〔上記ｃ）〕の値を設
定した問い合わせパケット６２１２を折り返し、被管理
ノード３０１に送信する（ステップＳ９）。

【００７７】その際、要求管理モジュール１６１は、応
答パケット６２１１内の属性値の最初の時刻と最後に追
加された時刻とを参照して一括して送られた情報量を判
断する。問い合わせパケット６２１１で指定した上記先
頭蓄積回数より余分に情報が在る場合には、上記中間蓄
積回数から減算して上記問い合わせパケット６２１２に
設定して送信する。

【００７８】送信後、再度応答パケット６２１１内の属
性値の情報を参照して、被管理ノード３０１で省略され
た時刻の情報を復元する。即ち、当該時刻より前の時刻
で一番近い時刻を探し出して、同じ値とする。

【００７９】復元後、アプリケーション利用者からの収
集要求時の格納場所の指示に従って、補助記憶装置１４
０にログとして格納するか、アプリケーション利用者１
１０に返却する。尚、この時、被管理ノード周囲のネッ
トワーク負荷により余分に入っている情報も、同様に格
納／返却を行う。

【００８０】＊：問い合わせパケット６２１２を受けた
被管理ノード３０１の処理（ステップＳ１０）は、収集
回数が変わる以外は、上記問い合わせパケット６２１１
を受けた時の処理（ステップＳ７）と同じである。

【００８１】以上を上記問い合わせ数〔上記ａ）〕の値
の分だけ繰り返す。但し、最終問い合わせパケット６２
１ｎでは、管理ノード１００は当該パケットに最終蓄積
回数値〔上記ｂ）〕を設定する。またこの時、上記最終
蓄積回数〔上記ｂ）〕が０なら問い合わせパケット６２
１ｎは、送信せずに次の解放処理に行く〔図７では、問
い合わせパケット６２１ｎに対する応答パケット６２１
ｎが存在している（ステップＳ１１）〕。

【００８２】以上の処理の繰り返し終了後、管理ノード
１００では、要求管理モジュール１６１が呼４０１を解
放して処理を終了する（ステップＳ１２）。（４）複数の被管理ノードに収集を依頼する時のプロト
コル（要求受付時）：図８、図９は、（１）管理開始時
の情報分配処理のプロトコル：で説明したフローによっ
て図１のネットワーク構成が形成された後に、アプリケ
ーション利用者１１０により各被管理ノード３０１〜３
０４で管理している対象装置の情報を収集するよう依頼
された時の、管理ノード１００と各被管理ノードとの間
で行われるデータ送受信の様子を示したものである。
尚、図面の大きさの関係で、フローを図８と図９に分割
して示している。

【００８３】＊：管理ノード１００の中で、要求管理モ
ジュール１６１はアプリケーション利用者１１０から情
報収集の要求を受け付けると、上記（３）一つの被管理
ノードに収集を依頼する時のプロトコル：の場合と全く
同様にして、既に処理中になっている収集要求のスケジ
ュールの確認、被管理ノード一覧情報ファイル１４２の
情報の一部のメモリ領域１３１への展開、スケジューリ
ングモジュール１６３に被管理ノードへのアクセス契機
計算の依頼を行う（ステップＳ１３）。

【００８４】スケジューリングモジュール１６３は、先
ず定義ファイル１４１の中の情報とアプリケーション利
用者１１０から与えられた収集回数／収集間隔／応答許
容時間を基にして、以下の値を計算する。

【００８５】ｄ）時間をずらしながら情報を収集できる
被管理ノードの数図８、図９では、ｄ）の数が３となっており、アプリケ
ーション利用者１１０から指定された被管理ノードの数
４より小さい為、群管理制御が必要と判断し、群制御モ
ジュール１６４を呼び出す。

【００８６】群制御モジュール１６４は、メモリ領域１
３１に展開された被管理ノード一覧情報１４２の複写フ
ァイルを参照して、アプリケーション利用者１１０から
指定された被管理ノードの中からまとめられる（以下、
複数ノードをまとめることを『群化』と呼ぶ）組合せを
探し出す。

【００８７】探し出した被管理ノードの組合せ（以下、
『群』と呼ぶ）について、上記の被管理ノード一覧情報
１４２で各被管理ノードがエントリされている個別部に
フラグを立てるとともに群の番号を付与する。

【００８８】尚、以上のフラグ制御と群番号の付与処理
については後に更に説明する。図８、図９の例では、被
管理ノード３０１／３０２は単独、被管理ノード３０３
／３０４は群番号３で群化されている。

【００８９】群制御モジュール１６４から制御が戻ると
スケジューリングモジュール１６３は、上記（３）一つ
の被管理ノードに収集を依頼する時のプロトコル：と同
様に再度、上記の定義ファイル１４１の情報と、上記の
収集回収／収集間隔／応答許容時間とを利用して、次は
割り振られた被管理モジュールの群毎に以下の値を計算
し（単独の被管理ノードにも各々にこれらの値を計算）
する（ステップＳ１３）。

【００９０】ｅ）問い合わせ数：被管理ノードに問い合
わせパケットを送信する回数ｆ）先頭蓄積回数：最初の問い合わせの応答で、被管理
ノードに一度に渡してもらう情報の収集回数ｇ）最終蓄積回数：最後の問い合わせの応答で、被管理
ノードに一度に渡してもらう情報の収集回数ｈ）中間蓄積回数：ｆ）ｇ）以外の問い合わせの応答
で、被管理ノードに一度に渡してもらう情報の収集回数ｉ）初回収集間隔：周期をズラす為に利用者指定の収集
間隔より小さい間隔を空ける必要がある場合に、指定群
毎の通知のタイムラグは、ｆ）、ｇ）及びｉ）の値を群
毎にズラすことによって生成する。

【００９１】更に上記（３）一つの被管理ノードに収集
を依頼する時のプロトコル：と同様に、メモリ領域１３
１に展開されたテーブルに、算出した各情報を書き込ん
で、要求管理モジュール１６１に制御を戻す。

【００９２】尚、ｄ）〜ｉ）の値の計算方法と要求スケ
ジュールテーブルの処理については、後に説明する。

【００９３】要求管理モジュール１６１は、群化された
被管理ノードの存在を上記のフラグで確認して、単独の
被管理ノード３０１／３０２には、上記各々の先頭蓄積
回数〔上記ｆ）〕／初回収集間隔〔上記ｉ）〕と、後は
同様にアプリケーション利用者から渡された上記収集間
隔とを展開し、操作値＝Ｙの問い合わせパケット６２１
１／６２２１を送信する（ステップＳ１４）。

【００９４】群化された３０３／３０４には、やはり上
記の群３用の先頭蓄積回数〔上記ｆ）〕／初回収集間隔
〔上記ｉ）〕と、アプリケーション利用者指定の上記と
同じ収集間隔を展開して、今度は操作値＝Ｚの問い合わ
せパケット６２３１／６２４１を送信する（ステップＳ
１５）。

【００９５】要求管理モジュール１６１は、操作値＝Ｚ
の問い合わせパケットを送信した場合、全部の送信終了
後、時計管理モジュール１６５に対し、各々の問い合わ
せパケットに展開した上記の初回収集間隔〔上記ｉ）〕
の中から最小値の間隔で通知するように依頼する。

【００９６】＊：問い合わせパケット６２１１〜６２４
１を受け取った各被管理ノード３０１〜３０４では、各
々の要求受付モジュール３６１が、各々パケットにより
指定された収集間隔で属性値を収集するように対応する
各々の管理対象管理モジュール３６４に順次依頼する。

【００９７】処理の流れは、上記（３）一つの被管理ノ
ードに収集を依頼する時のプロトコル：とほぼ同様であ
り、上記の初回収集間隔〔上記ｉ）〕で０以外の値が指
定されていた場合のみ、当該指定値に合わせて、最初の
収集間隔を変える処理を行う。

【００９８】操作値＝Ｚの問い合わせパケット６２３１
／６２４１を受け取った被管理ノード３０３／３０４で
は、それぞれの要求受付モジュール３６１が、最初の管
理対象管理モジュール３６４への情報収集の依頼が終了
した時、上記の情報収集の開始処理の追加により、再
度、管理対象管理モジュール３６４に対し、各々の通信
制御モジュール３５０の現時点の負荷状態参照を依頼す
る。

【００９９】そして応答パケット６２３１／６２４１
を、以下の情報を『処理状況』として付与した上で、管
理ノード１００に送信する（ステップＳ１６、Ｓ１
８）。

【０１００】・管理対象装置への参照が問題無く行われ
たか。・通信制御モジュールが負荷状態になっていないか。

【０１０１】＊：応答パケット６２３１／６２４１を受
信した管理ノード１００では、要求管理モジュール１６
１が当該パケットの中の処理状況を群制御モジュール１
６４に通知する。

【０１０２】群制御モジュール１６４は、メモリ領域１
３１に展開されているノード一覧情報１４２を複写した
テーブルの、対象の被管理ノードがエントリされている
個別部に、上記の処理状況を設定する。

【０１０３】制御が戻ると要求管理モジュール１６１
は、操作値＝Ｚの問い合わせを行った被管理ノードに対
しては、応答のパケット６２３１／６２４１を受信した
時点で呼の解放を行う（ステップＳ１７、Ｓ１９）。

【０１０４】以上の如くアプリケーション利用者からの
要求の延長で起こる処理が終了し、管理ノード／被管理
ノードの時計管理モジュール１６５／３６３が通知をす
る度に、次の（５）の処理を行う。（５）複数の被管理ノードに収集を依頼する時のプロト
コル（タイマからの通知による起動時）：図１０、図１
１は、図１の様に構成されたネットワークで、上記
（４）複数の被管理ノードに収集を依頼する時のプロト
コル（要求受付時）：のフローにしたがって管理ノード
１００から被管理ノード３０１〜３０４に情報収集の開
始が通知された後に、管理ノード／被管理ノード内にあ
る時計管理モジュール１６５／３６３が通知を発生させ
る時を契機にして起動される処理の様子を示すものであ
る。

【０１０５】＊：被管理ノード３０１〜３０４では、上
記（３）一つの被管理ノードに収集を依頼する時のプロ
トコル：で示したとおりに、各々の時計管理モジュール
３６３からの通知時に、各々の要求受付モジュール３６
１が対応する管理対象管理モジュール３６４への依頼を
通して対象装置の属性値と現時刻の収集と蓄積を行う。

【０１０６】また上記（４）複数の被管理ノードに収集
を依頼する時のプロトコル（要求受付時）：で操作値＝
Ｙの問い合わせパケットを受け取った被管理ノード３０
１／３０２、即ち、群化されずに、単独で応答を返す被
管理ノードでは、これも上記（３）一つの被管理ノード
に収集を依頼する時のプロトコル：と同じく、要求受付
モジュール３６１が、蓄積回数と汎用通信制御モジュー
ル３５０の負荷状態を監視して、応答パケット６２１１
／６２２１を送信する（ステップＳ２２）。

【０１０７】＊：応答パケット６２１１／６２２１（操
作値＝Ｙの問い合わせに対する応答）を受け取った管理
ノード１００では、これも上記（３）一つの被管理ノー
ドに収集を依頼する時のプロトコル：で示したとおり
に、追加分の属性値をチェックしながら、次の問い合わ
せパケット６２１２／６２２２をそれぞれ応答を送って
きた被管理ノードに送信する（ステップＳ２２）。

【０１０８】以上までは、操作値＝Ｚの問い合わせパケ
ットを受けた被管理ノードが応答パケット送信の為の処
理をスキップする以外は、上記（３）一つの被管理ノー
ドに収集を依頼する時のプロトコル：の処理と全く同様
である。

【０１０９】＊：管理ノード１００では、時計管理モジ
ュール１６５からの周期的な通知により、要求管理モジ
ュールがメモリ領域１３１に展開されてある被管理ノー
ド一覧情報テーブル１４２の、操作値＝Ｚの問い合わせ
パケットを送信した被管理ノード（群化された被管理ノ
ード）の個別部の蓄積回数を監視する。

【０１１０】指定回数分、被管理ノード側で蓄積された
と判断すると、要求管理モジュール１６１は、上記の被
管理ノード一覧情報テーブルの中から該当する群番号を
持ち通信制御モジュールの処理状況が正常である被管理
ノードをピックアップし、ビットマップ化して宛先情報
を編集するとともに、ピックアップした中から一番最近
に管理対象の生成依頼（上記（１）〜（２）の処理）を
行った被管理ノード３０４を特定する。

【０１１１】上記処理にて特定した被管理ノード３０４
に対して呼４０４の再設定を行った後、上記処理にて編
集したビットマップの宛先情報から被管理ノード３０４
に対応するビットをクリアして、操作値＝Ｗの問い合わ
せパケット６２４２に編集し直した宛先情報と該当する
群の中間蓄積回数〔上記（４）で計算したｈ）の値〕を
乗せて、設定済の呼４０４を使って被管理ノード３０４
に送信する（ステップＳ２３）。

【０１１２】尚、宛先情報のビットマップ化の処理内容
については後述する。

【０１１３】問い合わせ６２４２送信後、要求管理モジ
ュール１６１は応答を待たずに呼４０４を解放する（ス
テップＳ２４）。

【０１１４】また、同じ該当する群番号を持ち、通信制
御モジュールの負荷状態が異常となっている被管理ノー
ドに対しては、上記の処理と別に、宛先情報を０クリア
してある操作値＝Ｗの問い合わせパケット６２Ｘ２を送
信する。

【０１１５】＊：問い合わせパケット６２４２を受け取
った被管理ノード３０４では、要求受付モジュール３６
１が、管理対象管理モジュール３６４に、現時点での汎
用通信制御モジュール３５０の負荷状態の参照を依頼
し、その結果から当該通信制御モジュールの負荷状態を
判定する。

【０１１６】負荷状態が正常の場合、受信した問い合わ
せパケット６２４２内の宛先情報のビットマップを参照
し、既存ノードファイル３４２と比較して問い合わせパ
ケットが未だ送られていない被管理ノードをピックアッ
プする。ピックアップした中で一番最初にエントリされ
ている被管理ノードを選択するとにより、次にアクセス
する被管理ノード３０３を特定し、呼４３４の設定を行
う（ステップＳ２５）。

【０１１７】その後、問い合わせパケット６２４２の宛
先情報で被管理ノード３０３に対応するビットをクリア
し、蓄積情報ファイル３４１の中にある情報を問い合わ
せパケット６２４２のデータに追加記述することによ
り、操作値＝Ｗのままの問い合わせパケット６２３２を
生成する（ステップＳ２６）。

【０１１８】これを被管理ノード３０３に送信し、管理
ノード１００と同様に応答を待たずに呼４３４を解放す
る（ステップＳ２７）。尚、ビットマップ読み取りの処
理内容は後述する。

【０１１９】負荷状態が異常の場合は、上記（３）一つ
の被管理ノードに収集を依頼する時のプロトコル：の被
管理ノード３０１の処理と同様に次の属性値収集契機迄
待って、再度通信制御モジュール３５０の負荷状態を参
照することにより、正常を確認してから上記の問い合わ
せパケット６２３２の送信を行う。

【０１２０】＊：問い合わせパケット６２３２を受け取
った被管理ノード３０３でも、要求受付モジュール３６
１が、上記の被管理ノード３０４の処理と同様に、通信
制御モジュール３５３の負荷状態の判定と、次にアクセ
スする被管理ノードの特定処理を行う。

【０１２１】この場合、問い合わせパケット６２３２内
の宛先情報ビットマップは既に全て０クリアされている
ので要求受付モジュールは次に問い合わせパケットを送
信する被管理ノード無しと判断し、管理ノード１００対
して呼４０３を設定する（ステップＳ２８）。

【０１２２】設定後、問い合わせパケット６２３２に付
与されてきた被管理ノードの蓄積情報を取り出し、補助
記憶装置３４０の中にある蓄積情報ファイル３４１のデ
ータを追加し、ｍ−ＥｖｅｎｔＲｅｐｏｒｔプロトコル
に全ての情報を乗せることによって応答パケット６３３
２を管理ノード１００へ送信する（ステップＳ２９）。

【０１２３】＊：応答パケット６３３２を受け取った管
理ノード１００では、要求管理モジュール１６１が、上
記（３）一つの被管理ノードに収集を依頼する時のプロ
トコル：の時と同様に、省略された時刻の情報を復元し
た後、アプリケーション利用者からの収集要求の格納場
所の指示に従って、補助記憶装置にログとして格納する
か、アプリケーション利用者への返却を行う。

【０１２４】更に要求管理モジュール１６１では、各被
管理ノード３０３／３０４における収集の先頭と最終の
時刻を割り出して、群制御モジュール１６４に引き渡
す。

【０１２５】群制御モジュールで１６４では、各被管理
ノードが余分に属性値を取得しているか否かにより、通
信制御モジュールの負荷が発生してるか否かを判断す
る。

【０１２６】負荷が発生している場合は、余分に属性値
情報を取得している最初の被管理ノード（操作値＝Ｗの
問い合わせパケットを受け付けた順で最初の被管理ノー
ド）を特定し、メモリ領域１３１に展開してある被管理
ノード一覧テーブル１４２の、特定した被管理ノードが
エントリされている個別部の処理状況を『負荷発生』と
する。

【０１２７】逆に、既に負荷が発生して、上述の処理で
問い合わせパケット６２Ｘ２を個別に送られた被管理ノ
ード３０Ｘから、問い合わせパケット６２Ｘ２で指定の
回数分過不足無く属性値が渡されてくる場合が在る。

【０１２８】この場合には、当該被管理ノード３０Ｘは
負荷が解除されたとして、メモリ領域１３１に展開して
ある被管理ノード一覧テーブルの、当該被管理ノード３
０Ｘに対応する個別部の処理状況を『正常』とする。

【０１２９】以上のデイジ・チェイン処理を問い合わせ
数〔上記（４）複数の被管理ノードに収集を依頼する時
のプロトコル（要求受付時）：で計算したｅ）の値〕の
分だけ繰り返す。

【０１３０】この時、最後から２番目の操作値＝Ｗの問
い合わせパケットには、蓄積する回数に、当該群番号に
対応する最終蓄積回数〔上記（４）複数の被管理ノード
に収集を依頼する時のプロトコル（要求受付時）：で計
算したｇ）の値〕を設定し、最後の操作値＝Ｗの問い合
わせパケット６２４ｎには、蓄積する回数に０を設定す
る。

【０１３１】また最終蓄積回数〔ｇ）の値〕が０の時
は、最後のパケット送信は省略する。

【０１３２】蓄積する回数が０の操作値＝Ｗの問い合わ
せパケットを受け取った各被管理ノードは、時計管理モ
ジュールへの通知のスケジュールの停止を依頼し、蓄積
情報ファイル３４１の削除を行う。

【０１３３】蓄積する回数が０の、操作値＝Ｗの問い合
わせパケット６２４ｎに対する応答パケット（ｍ−Ｅｖ
ｅｎｔＲｅｐｏｒｔ６３３ｎ）を受け取った管理ノー
ド１００は、メモリ領域１３１の解放を行い、情報の格
納／通知をして、要求に対する処理を終了する（ステッ
プＳ３０）。（６）蓄積回数の計算とスケジューリング方式：上記
（３）一つの被管理ノードに収集を依頼する時のプロト
コル：や（４）複数の被管理ノードに収集を依頼する時
のプロトコル（要求受付時）：で管理ノード１００で
は、アプリケーション利用者１１０や定義ファイル１４
１から与えられた情報を元に、被管理ノード３０１〜３
０４で属性値を蓄積してもらう回数等の計算をしてい
た。

【０１３４】以下に、その処理内容をまとめて説明す
る。

【０１３５】定義情報ファイル１４１には以下の情報
が、２の累乗の形式で格納されている。以下２のｎ乗を
２↑ｎと記述する。

【０１３６】ａａ）希望通知間隔：管理ノードで２つ通
知を受け取る間に設定しておきたい時間間隔＝２↑α秒
（α＜０）ｂｂ）遅延許容値：指定した応答時間の何倍まで待つか
＝２↑β（β＞０）ｃｃ）要求受付数：同時にスケジュールできる要求の数
＝２↑γ（γ＞０）要求管理モジュール１６１はこれに対して、『現在管理
している要求の数』であるΔを静的に保持する。

【０１３７】要求内容を受け取った時点で、上記のΔ
（現在管理している要求数）を１だけ加算する。加算し
た値が上記の２↑γ以下であることを確認する。これに
より、上記（３）一つの被管理ノードに収集を依頼する
時のプロトコル及び（４）複数の被管理ノードに収集を
依頼する時のプロトコル（要求受付時）における『既に
処理中になっている収集要求〜』のチェックを行う。

【０１３８】尚、要求管理モジュール１６１は、問い合
わせの繰り返しを行って収集要求に対する処理が全て終
了すると、上記のΔ（現在管理している要求数）から１
を減算する。

【０１３９】アプリケーション利用者１１０からの収集
要求の指定には、以下のパラメータが入っている。

【０１４０】ｄｄ）収集間隔：属性値情報を何秒置きに
収集するかが、２の累乗の形式で入っている＝２↑Ａ秒
（１以上１０２４≒１５分以下）ｅｅ）収集回数：属性値情報を収集する全体の回数＝Ｎｆｆ）許容応答時間：定期的な応答が待てる時間＝Ｔ先ずアプリケーション利用者１１０の指定する許容応答
時間Ｔの値以下の２の累乗の数の中で最大の値２↑ｔを
算出する。そして、情報を蓄積しながら通知する時間間
隔を、２↑［ｔ−β］とし、２↑Ａ（収集間隔）以上で
あることを確認する。

【０１４１】一つの要求で、２↑［α＋γ］秒毎に通知
を受け取れるものとして、『時間をずらしながら情報収
集可能な被管理ノード数』を、２↑［（ｔ−β）−（α
＋γ）］で計算して上記（４）複数の被管理ノードに収
集を依頼する時のプロトコル（要求受付時）における上
記ｄ）の値とし、要求管理モジュール１６１は、この値
とアプリケーション利用者１１０指定の被管理ノードの
数を比較して群制御が必要か否かを判断する。

【０１４２】上記（３）一つの被管理ノードに収集を依
頼する時のプロトコル：における上記ｃ）、（４）複数
の被管理ノードに収集を依頼する時のプロトコル（要求
受付時）：における上記ｈ）の中間蓄積回数を、２↑
［ｔ−β］／２↑Ａ＝２↑［Ｔ−β−Ａ］で計算した
後、各群（以下、単独で操作値＝Ｙの問い合わせパケッ
トを受ける被管理ノードも個別の群として扱う）におけ
る、基本周期２↑［ｔ−β］からのズレを以下の様に計
算する。

【０１４３】『ｉ番目の群のズレは（ｉ−１）を２進数
表示して、２↑ｐを示す桁（ｐ≧０）が１ならば、２
［−ｐ−１］×２↑［ｔ−β］を足して混んでゆく』例
えば、１１番目の群のズレは、１１−１＝１０を２進数
表示すると“１０１０”で、２↑１の桁と２↑３の桁が
１なので、（２↑［−２］×２↑［ｔ−β］＋２↑［−
４］×２↑［ｔ−β］＝（１／４＋１／１６）×２↑
［ｔ−β］＝５／１６×２↑［ｔ−β］という値にな
る。

【０１４４】このズレの値を更に分解して、２↑Ａ×ｊ＋２↑［α＋γ］×ｋ（ｊ、ｋは非負整数、
２↑［α＋γ］×ｋ≦２↑Ａ）とした時に、ｉ）２↑［α＋γ］×ｋを初回収集間隔、即ち上記
（４）におけるｈ）の値 ii）ｊを先頭蓄積回数とする値、即ち上記（４）に
おけるｆ）の値 iii）（Ｎ−ｊ）／２↑［Ｔ−β−Ａ］＋２（割った商
に２を足す）を問い合わせ数、即ち上記（３）における
ａ）、（４）におけるｅ）の値 iv）（Ｎ−ｊ）％２↑［Ｔ−β−Ａ］（割った余り）を
最終蓄積回数、即ち（３）におけるｂ）、（４）におけ
るｇ）の値として計算する。

【０１４５】要求管理モジュール１６１は操作値＝Ｙ、
Ｗの問い合わせパケットを送りだす毎に、上記（３）に
おけるａ）、（４）におけるｅ）の問い合わせ数を減算
してゆくことにより、問い合わせパケットの繰り返しを
管理する。

【０１４６】この処理において、上記（３）における
ａ）、（４）におけるｅ）の問い合わせ数は先頭蓄積回
数の収集と最終蓄積回数の収集の為の問い合わせパケッ
トを無条件に勘定しているので、（４）のｆ）の先頭蓄
積回数や（３）のａ）／（４）のｇ）の最終蓄積回数が
０で、相当する問い合わせパケットの送信処理がスキッ
プされた場合も、上記問い合わせ数は１減算する。（７）被管理ノード一覧ファイル／被管理ノード一覧情
報とビットマップ：管理ノード１００の補助記憶装置１
４０に格納される被管理ノード一覧ファイル１４２は、
図１２の表ａと図１３の表ｂが結合したファイルであ
る。

【０１４７】表ａ、表ｂとも左上から縦の列毎にレコー
ドを形成している。図１２の表ａの部分は、被管理ノー
ドの各々が、１レコード単位に登録されている。各レコ
ードに登録されている内容は、被管理ノード名（ａ）、
被管理ノードのアドレス（ｂ）、呼設定の際に使用する
コンテキスト情報であって被管理ノード毎に設定される
情報群（ｃ）、所属するドメイン番号（群初期設定番号
として１以上の値を登録）（ｄ）であり、更に、相応の
空き領域（ｅ）を持つ。

【０１４８】尚、上記コンテキスト情報（ｃ）には、使
用する機能単位や、被管理ノードのＡＰ名称等がある。
またドメインの設定（ｄ）は、ネットワークの構成に着
目して、被管理ノード一覧ファイル１４２の作成者が行
う。

【０１４９】図１３の表ｂの部分には、被管理ノードで
管理の対象となる全ての装置（ｆ）に対して、各々１レ
コード毎に所属する被管理ノード等（ｇ）及び各装置生
成のためのコンテキスト（ｈ）の情報が登録される。こ
れらの情報により、送信される各管理対象の生成要求パ
ケットが生成される。

【０１５０】管理開始時には、要求管理モジュール１６
１は、図１２の表ａの登録レコードの先頭から順に呼４
０１〜４０４を設定しし、その後図１３の表ｂから各々
の被管理ノードに所属する管理対象装置を選択して、管
理対象装置の生成要求（ｍ−Ｃｒｅａｔｅ）と、操作値
＝Ｘの問い合わせパケットの送信を行う（図４、図５参
照）。

【０１５１】また上記（２）管理対象追加時の情報分配
処理のプロトコル：の様に被管理ノードが追加された時
は、以下の手順で被管理ノード一覧ファイル１４２を更
新する。

【０１５２】第一に、図１２において、右側部の点線枠
で囲った被管理ノード名３０５のレコードを生成する。
ついで、表ａの最終レコードの後（図１３の表ｂの前）
に挿入する。

【０１５３】第二に、追加された管理の対象となる装置
毎に個別レコードを生成して、図１３の表ｂの最後に追
加する。

【０１５４】図１４は、被管理ノード側で操作値＝Ｘの
問い合わせパケットを受信した際、被管理ノード側で生
成する既存ノードファイル３４２の形式を示している。
操作値＝Ｘの問い合わせパケットの中に入っている他の
既存被管理ノード数を数え、当該数分の、ノードアドレ
スを保持できる個別部Ｂと、被管理ノード数を格納する
共通部Ａを持つ。

【０１５５】上記の共通部Ａに数えた被管理ノード数を
設定し、操作値＝Ｘの問い合わせパケットに入っていた
順に、既存被管理アドレスを、上記の個別部Ｂに設定す
る。従って、図１２の表ａのレコードとは逆の順番にな
る。

【０１５６】尚、具体例として、図１４の例では被管理
ノード３０４が図４、図５の事象フロー図で生成する既
存ノードファイル３４２の様子を示している。

【０１５７】アプリケーション利用者１１０から情報収
集の要求を受付けた時、要求管理モジュール１６１は、
被管理ノード一覧ファイル１４２の表ａ（図１２）の部
分だけをメモリ領域１３１に展開する。

【０１５８】図１５は、被管理ノード一覧ファイル１４
２をメモリ１３１に展開してテーブル化し、上記（６）
蓄積回数の計算とスケジューリング方式：における蓄積
回数の計算を行い、群番号とともに当該テーブル上に設
定した時の状態を示す。

【０１５９】図１２により説明した被管理ノード一覧フ
ァイル１４２の各レコードが当該テーブルの個別部
（Ｉ）になっている。群番号（ｄ）は、ファイル１４２
の各レコードの群初期設定（ドメイン番号）を上書きし
ている。

【０１６０】（II）は、ファイル上の空き領域（図１２
（ｅ））であり、ここに計算された値が登録される。こ
の領域（II）において、ｎ、ｔ、ａ、ｒはアプリケーシ
ョン利用者１１０からの指定値から（６）蓄積回数の計
算とスケジューリング方式：の処理の過程で導き出され
た値である。

【０１６１】群制御モジュール１６４における上記
（４）複数の被管理ノードに収集を依頼する時のプロト
コル（要求受付時）：での、図１５のテーブルにおける
群番号の計算は、以下の手順で行う。

【０１６２】ｉ）上記（４）のｄ）の数と、被管理ノー
ドの数を比べて、いくつの被管理ノード間接続が必要か
を計算する。

【０１６３】ii）ドメイン番号の若い順に、当該ドメイ
ン番号と同じ群初期設定値を持ち、且つ利用者から収集
要求を受けている被管理ノードを探す。

【０１６４】その際、同じドメイン番号に該当する被管
理ノードを複数探し出すことにより、被管理ノード間接
続が可能な被管理ノードの組合せを、上記で計算した必
要数になるまで探してゆく。

【０１６５】iii）見つけ出した被管理ノードの組合せ
に入る被管理ノードの群初期設定値（ドメイン番号）の
みを有効とし、他の被管理ノードの群初期設定値を、群
番号としてあり得ない値に書き換える。

【０１６６】実施例として、群番号の値として、利用者
から収集要求の指定を受けない被管理ノードには−１
を、利用者から収集の指定は受けている被管理ノードに
は０を設定している。

【０１６７】iv）探し出した被管理ノードの組合せで上
記（６）蓄積回数の計算とスケジューリング方式：で計
算する各値が揃う様に、（６）の『基本周期からのズ
レ』を計算する際のエントリ番号“ｉ”を、探し出され
た被管理ノードの順に振っておく。上記エントリ番号
は、探しだされた順に振られるために、個別部エントリ
の順番とは異なる。

【０１６８】次に、管理ノード１００の、要求管理モジ
ュール１６１での、操作値＝Ｗの問い合わせパケットを
送信する時に付与するビットマップの作成は、以下の手
順で行う。

【０１６９】xi) 適当な大きさを持った宛先情報域を用
意し、その最左オクテットの最左ビットを制御対象ビッ
トとしておく。

【０１７０】xii)ある群番号に対する、操作値＝Ｗの問
い合わせ契機に、該当する群番号を持つ被管理ノード
で、各応答の値により設定した処理状況が『正常』とな
っているものを、上記のテーブルの最終個別から順に探
してゆく。

【０１７１】xiii）この時、各個別部毎に、当該個別部
が該当する被管理ノードのものであれば１を、該当しな
い被管理ノードのものであれば０を宛先領域の制御対象
ビットに設定し、制御対象ビットを右へズラしてゆく。

【０１７２】ｘiv) 先頭個別部まで上記のビット設定処
理が終了した時点で、処理中の宛先情報域オクテットの
処理中ビットより右の各ビットを０パティングする。

【０１７３】上記xi) 〜ｘiv) の手順は、図１５の例で
は図１６に示されるようになる。群番号３の問い合わせ
を契機に、被管理ノード３０３／３０４に対応するビッ
トを１とする（図１６：ステップＳａ）。そして、長さ
を１オクテットに合わせる為に、４ビットの０パティン
グを行う（ステップＳｂ）。

【０１７４】宛先情報の作成が終了すると要求管理モジ
ュール１６１は、最初に問い合わせパケットを送信する
宛先を、上記で作成した宛先情報から探す。宛先情報の
最左オクテットの最左ビットから順に、始めて“１”と
なるビットを探し出し、上記図１５のテーブルの対応す
る個別部の被管理ノードを宛先とする（ステップＳ
ｃ）。

【０１７５】決定した宛先に対応するビットのクリア
は、該当するビットが溢れるまで宛先情報の左シフトを
行い、最右オクテットの最右ビット側に空いた領域に０
を埋めることにより実現する（ステップＳｄ）。

【０１７６】問い合わせを受け取った被管理ノードの要
求受付モジュール３６１では、次の送信先を、受け取っ
た宛先情報と、図１４の様な形式を持つ既存ノードファ
イル３４２から探す。

【０１７７】即ち、宛先情報の最左オクテットの最左ビ
ットから順に、初めて“１”となるビットの順番を取り
出し、既存ノードファイル３４２の当該順番目の個別部
にあるアドレスに向けて、呼の設定と問い合わせパケッ
トの送信を行う。

【０１７８】宛先情報における、見つけ出した『初めて
“１”となるビット』のクリア手順は、上記の要求管理
モジュール１６１と同じ左シフトにより行う。

【０１７９】受け取った宛先情報のビットが全て０の場
合は、次送信の被管理ノードが無いとして、管理ノード
１００へ応答を送る。

【０１８０】ここで、先に説明した図８乃至図１１の事
象フローは、図１２で示したテーブルの例から設定され
る問い合わせパケットの送信の様子を示するものであ
る。

【０１８１】本来図１５の表ａ中の問い合わせ数の値が
ｎの場合、操作値＝Ｚの問い合わせと操作値＝Ｗの問い
合わせを合わせて、ｎ＋１回の問い合わせパケットが送
信されるが、（６）蓄積回数の計算とスケジューリング
方式：で記述したとおり上記の問い合わせ数は、値が０
のためにスキップしてしまう先頭蓄積回数指定の問い合
わせも勘定に入れている。このため、同図のフローの説
明では、最後のパケットが「ｎ番目の問い合わせパケッ
ト」になっている。

【０１８２】更に、図１７は、上記した本発明にしたが
い、管理ノード１００から被管理ノード３００に向け送
られる要求パケットと被管理ノード３００から管理ノー
ド１００に向けて送られる応答パケットの形式の一例を
示す図である。

【０１８３】図１７において、Ａは管理ノード１００か
ら被管理ノード３００に向け送られる要求パケット構
造、Ｂは被管理ノード３００から管理ノード１００に向
けて送られる応答パケットの構造である。プロトコルヘ
ッダ１７１と各パラメータの後ろに管理対象名称１７
２、操作値１７３、動作引数１７４の順にデータが入っ
ている。これらは、ＣＭＩＳＥプロトコルで規定される
ものである。

【０１８４】更に図において、（＊１）０_x６（１６進
で６という意味：以下同様）は管理対象名称を記述する
のに適したタイプを示す。（＊２）０_x２は整数型を示
す。（＊３）０_x３０は数値の構造体を構成しているこ
とを示す。（＊４）０_x３はビット列型を示す。また
（＊５）αに対し、属性値構造が応答パケットＢのよう
にすることは、通信両者間で合意される。

【０１８５】

【発明の効果】以上実施例にしたがい説明したように、
本発明は、基本的構成として管理ノード１００におい
て、適当な蓄積回数を指定して問い合わせパケットを送
信し、被管理ノード３００は、指定された時間間隔で上
記の蓄積回数分情報を収集した後、収集した情報を一つ
の応答パケットにまとめて管理ノードに送信するように
している。

【０１８６】したがって、かかる構成によりネットワー
ク上を流れるパケット数の削減、ネットワーク上を流れ
るデータ量の削減更に、ネットワーク上の負荷の分散を
図るネットワーク管理・情報収集方式が提供可能であ
る。

【０１８７】また、上記実施例は、本発明の説明のため
のものであり、本発明はかかる実施例に限定されるもの
ではない。本発明の範囲は、特許請求の範囲の記載に基
づき定められ、特許請求の範囲に記載のものと均等の範
囲にあるものでは、本発明の保護の範囲に含まれるもの
である。

【図面の簡単な説明】

【図１】本発明が適用されるネットワーク構成の一例を
示す図である。

【図２】図１における管理ノード１００の構成例ブロッ
ク図である。

【図３】図１における被管理ノード３００の構成例ブロ
ック図である。

【図４】ネットワーク管理システム立上時のプロトコル
の送受信フロー（その１）である。

【図５】ネットワーク管理システム立上時のプロトコル
の送受信フロー（その２）である。

【図６】図４及び図５に対し、被管理ノードが追加され
た時のプロトコルの送受信フローである。

【図７】一つの管理ノードの管理する装置の情報収集時
の管理ノードと被管理ノードとの間で行われるデータ送
受信のフローである。

【図８】複数の管理ノードの管理する装置の情報収集時
の管理ノードと被管理ノードとの間で行われるデータ送
受信のフロー（その１）である。

【図９】複数の管理ノードの管理する装置の情報収集時
の管理ノードと被管理ノードとの間で行われるデータ送
受信のフロー（その２）である。

【図１０】時計管理モジュールが通知を発生させる時を
契機にして起動させる処理フロー（その１）である。

【図１１】時計管理モジュールが通知を発生させる時を
契機にして起動させる処理フロー（その２）である。

【図１２】被管理ノードの一覧ファイル（その１）であ
る。

【図１３】被管理ノードの一覧ファイル（その２）であ
る。

【図１４】被管理ノード側で生成する既存ノードファイ
ル形式を示す図である。

【図１５】被管理ノードファイルのテーブル化の説明図
である。

【図１６】ビットマップ作成手順を説明する図である。

【図１７】本発明にしたがう問い合わせパケットと応答
パケットのデータ形式の説明図である。

【図１８】従来例のネットワーク管理システムを説明す
る図である。

【図１９】図１８の従来例における問い合わせパケット
と応答パケット形式の説明図である。

【符号の説明】

１００管理ノード２００回線網（ネットワーク）３００〜３０４被管理ノード３１０〜３１７管理対象装置４０１〜４０４呼５０１〜５０４通信路１１０アプリケーション利用者１２０／３２０タイマ１３０／３３０メモリ１４０／３４０補助記憶装置１４１定義ファイル１４２被管理ノード一覧１５０／３５０通信制御モジュール１６１要求管理モジュール１６２／３６２データ編集／解析モジュール１６３スケジューリングモジュール１６４群制御モジュール１６５／３６３時計管理モジュール１７０／３７０伝送路４００／４１０ソフトウエア・システム３４１蓄積情報ファイル３４２既存ノードファイル３６１要求受付モジュール３６４管理対象管理モジュール

Claims

【特許請求の範囲】

【請求項１】収容するノードをアクスセスするための回
線網と、該回線網に収容された複数の被管理ノードと、該回線網に収容され、該被管理ノードにアクセスして該
被管理ノードの情報を収集する管理ノードを有し、該管理ノードは、周期的に情報を収集する際に、要求毎
の許容応答時間とネットワーク遅延値から、まとめて応
答できる収集情報量を計算し、計算した量の情報を蓄積
して応答する様に該被管理ノードに要求するアクセス手
段を含み、該被管理ノードは、該管理ノードの該アクセス手段に応
じて周期的に情報を収集蓄積し、蓄積情報を一度に該管
理ノードに応答する該被管理ノードのアクセス手段を有
することを特徴とするネットワーク管理・情報収集方
式。
【請求項２】請求項１において、前記管理ノードからの要求に応答する前記被管理ノード
のアクセス手段は、該管理ノードからの情報収集要求に
対する応答を送る際に、自ノード内のネットワーク制御
モジュールの情報から負荷状態を割り出し、高負荷の場
合は一定時間経過後に、その時刻の情報を追加して応答
し、更に、前記管理ノードは、該被管理ノードからの応答に
基づき、該被管理ノードの負荷状態を判別し、追加され
た情報をログとして扱う情報解析手段を有することを特
徴とするネットワーク管理・情報収集方式。
【請求項３】請求項１において、前記被管理ノードは、収集した情報を以前に収集済の情
報と比較して差が在る場合のみ時間と共に蓄積し、同じ
場合には蓄積を省略して前記一度に応答する蓄積情報と
する情報格納手段を有し、前記管理ノードは、該被管理ノードからの応答に対し
て、各情報に付いている時刻によって省略された情報の
存在を確認し、直前の情報と同じ値で復元する情報解析
手段を有することを特徴とするネットワーク管理・情報
収集方式。
【請求項４】請求項１において、前記管理ノードは、前記複数の被管理ノードの情報を集
める際に、指定された被管理ノードのエントリの順番を
２進数化し“１”になっている桁に対応する分数の和を
取ることにより、該被管理ノードに要求する最初の応答
で蓄積する数と、最初の要求間のインターバルを変える
ことにより、応答が返る周期をズラし、応答が集中しな
い様にするスケジューリング手段を有することを特徴と
するネットワーク管理・情報収集方式。
【請求項５】収容するノードをアクスセスするための回
線網と、該回線網に収容された複数の被管理ノードと、該回線網に収容され、該被管理ノードにアクセスして被
管理ノードの情報を収集する管理ノードと、該管理ノードは、該被管理ノードに該被管理ノードに接
続された管理の対象となる装置を通知した際に、既に通
知を行った他の被管理ノードの一覧を、通知した順と逆
順にして、管理するように依頼する初期登録要求手段
と、該複数の被管理ノードの情報を集める際に、該被管理ノ
ードを管理するテーブルから、収集を要求する被管理ノ
ードを示すビットマップ化された宛先情報の作成と、最
初に要求を行う被管理ノードの選択を行い、選択した被
管理ノードに作成した宛先情報（ビットマップ）を付け
て収集要求の問い合わせを行うアクセス手段を有し、該被管理ノードは、該管理ノードの該初期登録要求手段
からの初期登録要求に対して、要求された順に該被管理
ノードの一覧を格納する初期登録手段と、問い合わせを受け取った際に、付いてる宛先情報（ビッ
トマップ）と初期登録による該他の被管理ノードの一覧
を比較して、問い合わせの連鎖を生成するアクセス手段
を有することを特徴とするネットワーク管理・情報収集
方式。
【請求項６】請求項５において、前記被管理ノードのアクセス手段は、他の被管理ノード
に、自ノード情報と、ビットマップをシフトして編集し
た宛先情報を付けて、問い合わせの転送を行うことによ
り前記問い合わせの連鎖の生成を行うことを特徴とする
ネットワーク管理・情報収集方式。
【請求項７】請求項５において、前記被管理ノードのアクセス手段は、応答として前記管
理ノードにレポート通知を行い、前記問い合わせの連鎖
の生成を行うことを特徴とするネットワーク管理・情報
収集方式。
【請求項８】請求項５において、更に、前記被管理ノードは、収集開始要求の問い合わせパケッ
トに対して、現在の自ノード内の、管理対象装置の参照
状態と通信制御モジュールの負荷状態を、応答するネッ
トワークアクセス手段を有し、前記管理ノードは、該ネットワークアクセス手段により
応答に入っている各状態を、初期値として記憶するとと
もに、問い合わせの連鎖から戻ってきた応答を受け取っ
た際に、各被管理ノード毎の時刻を参照し、遅延が発生
している被管理ノードを監視し、該遅延が発生している被管理ノードは負荷が発生してい
るとして、宛先情報のビットマップから、該当の被管理
ノードを外し、当該被管理ノードには連鎖を生成する問
い合わせとは別の収集要求の問い合わせを送信し、該別の収集要求の問い合わせが遅延無く応答された時に
は、連鎖を生成する問い合わせの宛先情報（ビットマッ
プ）に再度当該被管理ノードを登録する被管理ノード管
理手段を有することを特徴とするネットワーク管理・情
報収集方式。
【請求項９】請求項１または４において、前記管理ノードは、前記該被管理ノードに該被管理ノー
ドに接続された管理の対象となる装置を通知した際に、
既に通知を行った他の被管理ノードの一覧を、通知した
順と逆順にして、管理するように依頼する初期登録要求
手段と、該複数の被管理ノードの情報を集める際に、該被管理ノ
ードを管理するテーブルから、収集を要求する被管理ノ
ードを示すビットマップ化された宛先情報の作成と、最
初に要求を行う被管理ノードの選択を行い、選択した被
管理ノードに作成した宛先情報（ビットマップ）を付け
て収集要求の問い合わせを行うアクセス手段と、該被管理ノードは、該管理ノードの該初期登録要求手段
からの初期登録要求に対して、要求された順に該被管理
ノードの一覧を格納する初期登録手段と、問い合わせを受け取った際に、付いてる宛先情報（ビッ
トマップ）と初期登録による該他の被管理ノードの一覧
を比較して、問い合わせの連鎖を生成するアクセス手段
を有し、一つの要求で受けられる応答の数と収集の対象となる被
管理ノードの数を比較して、該被管理ノードのアクセス
手段による問い合わせの連鎖の各繋ぎ目が幾つ必要かを
判断し、該被管理ノードを管理するテーブル上の各被管
理ノードの所属するドメイン番号から被管理ノード間接
続を行う被管理ノードの組合せを選択し、選択されなか
った被管理ノードとは操作値の異なる問い合わせによ
り、要求内容を振り分け、この時、被管理ノード間接続
を行う被管理ノードに対する問い合わせパケットの送信
契機を、適当な時間周期タイムアウト通知によって取得
するスケジュール補助手段を有することを特徴とするネ
ットワーク管理・情報収集方式。