JP2005234851A - 通信システム及び管理装置及び情報収集装置及び通信方法 - Google Patents

Abstract

【課題】 ネットワーク管理装置のポーリング負荷・リソース消費を抑制するとともに、データ収集効率とデータ収集の信頼性を兼ね備えたシステムを実現する。
【解決手段】 各メータ２は、収集した収集情報（電力使用量データ等）を所定のタイミングで非確認型プロトコルであるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）−ＴＲＡＰにてネットワーク管理装置１に送信し、ネットワーク管理装置１では所定のタイミングに収集情報が受信できなかったメータ２に対してＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴにより再送要求を送信し、再送要求を受信したメータ２ではＳＮＭＰ−ＲＥＳＰＯＮＳＥにより収集情報を再送する。
【選択図】 図１

Description

この発明は、ネットワーク上に分散した複数の装置からデータを取得する技術に関する。

ＩＰネットワークを管理するプロトコルとしてＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）が標準となっている。ＳＮＭＰの管理モデルでは、マネージャ・エージェントモデルを採用している。すなわち、ネットワーク上に分散した個々のＩＰ機器の管理情報は内部ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を用いて収集し、その情報をマネージャからの要求によりエージェントが応答することにより、各ノードの情報をマネージャノードに集約し全体管理を行っている。
ＳＮＭＰはその名の通り、プロトコルの仕様が簡素であることから実装が比較的容易で現在では広く普及している。
例えば、ＳＮＭＰを利用したネットワーク管理の技術としては、特開平９−２８２２５２号公報に開示の技術、特開２００１−６７２９２号公報に開示の技術がある。

特開平９−２８２２５２号公報では、ポーリング間隔を短くした場合には管理トラヒックが増加するが、これを防止するために、ネットワーク負荷モニターを設置し、負荷が高くなった場合、プローブが管理装置に抑止信号を送信し管理トラヒックを調整する方式を開示している。

特開２００１−６７２９２号公報では、ネットワーク管理装置の負荷を回避するため、ＳＮＭＰ−ＴＲＡＰを受信した場合にＳＮＭＰ−ＧＥＴで確認するという方式を開示している。
特開平９−２８２２５２号公報 特開２００１−６７２９２号公報 ＳＮＭＰｖｅｒ１プロトコル仕様ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１１５７．ｔｘｔ ＳＮＭＰｖｅｒ２プロトコル仕様ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１９０５．ｔｘｔ ＳＮＭＰｖｅｒ３プロトコル仕様ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／（当該ページでＲＦＣ２５７０〜ＲＦＣ２５７５を検索） Ｍ・Ｔ・ローズ著 「シンプルブック−インターネット管理入門」プレンティスホール出版、第２版、１９９５年１２月１５日

前述の通り、ネットワーク管理におけるデータ収集では、ネットワーク管理装置側から欲しい値をＭＩＢ値としてＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴより指示・送信し、被管理装置ではＭＩＢ値に対応する値をＳＮＭＰ−ＲＥＳＰＯＮＳＥを用いて応答することにより収集する応答確認型プロトコルによっている。
しかし、ネットワーク管理装置からＳＮＭＰの応答確認型プロトコルによってデータ収集するのでは、ネットワーク管理装置のポーリング負荷・リソース消費の増大により、一定時間内に監視できる管理対象数に限界が出てしまう問題があった。
これを回避するためにネットワーク管理装置の負荷を減らすために、ＳＮＭＰ−ＴＲＡＰプロトコルを使う方法が考えられる。しかし、ＳＮＭＰ−ＴＲＡＰは応答確認型プロトコルではないため被管理ノードから管理装置に情報が到達したかどうかの保証がないという欠点がある。
本発明はＳＮＭＰプロトコルを使って一定時間内に収集できる管理対象ノード数を増大させるべく、非確認型プロトコル（ＳＮＭＰ−ＴＲＡＰ）を使用して端末側からデータをＳＮＭＰ−ＴＲＡＰを送信し、データが収集できたどうかを管理装置側のデータベースで管理しリカバリ処理を追加することにより、データ収集効率とデータ収集の信頼性を兼ね備えたシステムを構築することにある。

本実施の形態に係る通信システムは、
情報の収集を行うとともに、送信された情報が送信先に到達したか否かの確認が行われない非確認型通信プロトコルを用いて、収集した収集情報を送信する複数の情報収集装置と、
前記複数の情報収集装置を管理し、前記非確認型通信プロトコルを用いて、前記複数の情報収集装置から収集情報を受信する管理装置とを有する通信システムであって、
前記複数の情報収集装置のそれぞれは、
それぞれに対して予め定められた送信タイミングにおいて、前記非確認型通信プロトコルを用いて収集情報を前記管理装置に対して送信し、
前記管理装置は、
情報収集装置ごとに、それぞれの情報収集装置の送信タイミングにおいて収集情報を受信できたか否かを判断するとともに、送信タイミングにおいて収集情報を受信できていない情報収集装置に対して収集情報の再送を要求することを特徴とする。

本発明によれば、非確認型通信プロトコルを用いることにより、システム全体の管理対象数を増やすことができ、また、収集情報が所定のタイミングで受信できない場合は、再送要求を伴うリカバリ処理が行われるので、信頼性も確保することができる。

実施の形態１．
図１は実施の形態１に係る通信システムの全体を示す概要図である。本システムの具体的応用例としては、電力計の電力量検針をネットワークを使って自動化するシステムが典型例となる。以下、この（電力）検針自動化システムをモデルとして説明する。

図１において、メータ２は電力メータなどの計測機器である。これが、有線または無線の回線に接続されている。メータ２は、監視データ（例えば、月間電力量データ）をタイマー等により自発的にＳＮＭＰ−ＴＲＡＰで送信するための機構と、当該監視データ（例えば、月間電力量データ）をＳＮＭＰ−ＧＥＴで再送する機構を有するものとする。なお、監視データは以降、収集情報とも言う。また、メータ２は、情報収集装置の例である。なお、実施の形態においては、メータ２を情報収集装置の例として説明するが、情報を収集できるのであればメータ２に限らず、各種センサ等であってもよい。

ネットワーク４は、ＩＰｖ４またはＩＰｖ６によるネットワークである。メータ２はＩＰプロトコル（ＩＰｖ４／ＩＰｖ６プロトコル）とＵＤＰプロトコルとＳＮＭＰプロトコルを実装しているものとする。ＵＤＰプロトコルは場合によってはＴＣＰプロトコルであってもよい。

図１において、ネットワーク管理装置１は、メータ２と通信できる回線で接続され、ＩＰｖ４プロトコル及びＩＰｖ６プロトコルを実装しているものとする。
また、ＵＤＰプロトコル及びＳＮＭＰマネージャの機能を実装しているものとする。メータ側にＴＣＰプロトコルを使用するものがある場合は、ＵＤＰプロトコルと同時にＴＣＰプロトコルも実装する。
また、ネットワーク管理装置１は、リレーショナルデータベース３（以下「ＲＤＢ」と略する）により、取得したデータを管理できるように構成されているものとする。ＲＤＢ３の機能は必ずしも同一マシン上に構成されている必要はなく、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等十分高速なネットワークを介してネットワーク管理装置１がＲＤＢ３を利用できるように接続されていればよい。

ＲＤＢ３には電力を使用する顧客データ情報（顧客データテーブル、以下、顧客ＴＢＬとも記す）が管理されているものとする。顧客データ情報としては、顧客ＩＤ、顧客が使用している電力メータのＩＤ、顧客名、顧客連絡先、当該電力メータに付けられたＩＰアドレス等が管理されているものとする。監視データ（電力量データ）の管理もＲＤＢ３上のテーブル（データ取得結果テーブル、以下、データ収集結果ＴＢＬとも記す）を使って管理する。
また、ネットワーク管理装置１は、監視データをＳＮＭＰ−ＴＲＡＰで取得する期間を検知する機構と、当該期間内にＳＮＭＰ−ＴＲＡＰでデータを取得できなかったメータについてはＳＮＭＰ−ＧＥＴで同一データを受信してデータ取得する機構を有するものとする。

図２は、メータ２の内部構成例を示す図である。
図２において、トリガ信号入力部２１は、ネットワーク管理装置１への送信（例えば、電力量データの送信）を行うためのトリガ信号を外部又は内部のタイマー等から入力する。
管理データ計測部２２は、継続的に所定の情報収集（例えば、電力使用量データの収集）を行っている。
ＳＮＭＰ送受信部２３は、ＳＮＭＰに基づいてネットワーク４を通じてネットワーク管理装置１とデータの送受信を行う。具体的には、収集情報（例えば、電力使用量データ）の送信の際には、非確認型通信プロトコルであるＳＮＭＰ−ＴＲＡＰオペレーションにより送信し、再送が必要な場合には、ネットワーク管理装置１からＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより送信された再送要求を受信し、再送要求を受信した後はＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションにより再送を行う。
ＳＮＭＰエージェント２４は、トリガ信号入力部２１がトリガ信号を入力した際に、管理データ計測部２２から収集情報を取得し、ネットワーク管理装置１への送信データとし、ＳＮＭＰ送受信部２３に渡す、また、再送要求があった場合には、当該再送要求に応答するための処理を行う。
また、メータ２は、ＳＮＭＰ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）２５、ＵＤＰ／ＴＣＰ処理部２６、ＩＰｖ４／ＩＰｖ６処理部２７も有する。
ここで、管理データ計測部２２は情報収集部の例であり、ＳＮＭＰ送受信部２３は収集情報送信部及び再送要求受信部の例である。

なお、メータ２は、図示していないが、例えばマイクロプロセッサ等のＣＰＵ、半導体メモリ等や磁気ディスク等の記録手段、及び通信手段を有する計算機により実現することができる。記録手段には、メータ２に含まれる各構成要素の機能を実現するプログラムが記録されており、ＣＰＵがこれらのプログラムを読み込むことによりメータ２の動作を制御し、各構成要素の機能を実現することができる。

図３は、ネットワーク管理装置１の内部構成例を示す図である。
図３において、トリガ信号入力部１１は、メータ２から収集情報（例えば、電力量データ）を受信するためのトリガ信号を外部又は内部のタイマー等から入力する。
ＳＮＭＰ送受信部１２は、所定の送信タイミングでメータ２から送信された収集情報を受信するとともに、所定の送信タイミングで収集情報を受信できなかったメータ２に対して再送要求を送信する。また、再送要求に対してメータ２から送信された収集情報（例えば、電力量データ）も受信する。具体的には、非確認型通信プロトコルであるＳＮＭＰ−ＴＲＡＰオペレーションにより送信された収集情報をメータ２から受信し、メータ２への再送要求はＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより行い、再送要求に対してＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションによりメータ２から送信された収集情報を受信する。
受信状況管理部１３は、所定の送信タイミングで各メータ２から送信された収集情報（例えば、電力量データ）を受信できたか否かを確認し、受信できていないメータ２があれば、そのメータ２に対する再送要求を生成し、再送要求の送信をＳＮＭＰ送受信部１２にリクエストする。
ＲＤＢインタフェース部１５（以下、ＲＤＢ Ｉ／Ｆ部とも記す）は、ＲＤＢ３とのデータ交換を行う。
また、ネットワーク管理装置１は、ＳＮＭＰ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）１４、ＵＤＰ／ＴＣＰ処理部１６、ＩＰｖ４／ＩＰｖ６処理部１７も有する。
ここで、ＳＮＭＰ送受信部１２は、収集情報受信部及び再送要求送信部の例である。

なお、ネットワーク管理装置１は、図示していないが、例えばマイクロプロセッサ等のＣＰＵ、半導体メモリ等や磁気ディスク等の記録手段、及び通信手段を有する計算機により実現することができる。記録手段には、ネットワーク管理装置１に含まれる各構成要素の機能を実現するプログラムが記録されており、ＣＰＵがこれらのプログラムを読み込むことによりネットワーク管理装置１の動作を制御し、各構成要素の機能を実現することができる。

次に、図４、図１１及び図１２を参照しながら動作について説明する。
電力検針自動化システムでは、決められた時間内に多数の電力量計から電力量データやその他の監視データを取得する必要がある。本実施の形態では、以下のようにデータを取得する。

図４に示すように、ネットワーク管理装置１は、タイマーイベントなどのトリガーにより検針前準備を開始する（Ｓ４０１）。すなわち、定められた時間帯（例えば月の初日の午前０時〜午前０時５分）に電力量データを取得することと定義されている場合、ネットワーク管理装置１は、トリガ信号入力部１１が内部又は外部のタイマーから取得開始時刻（この場合午前０時）にタイマーイベント（割り込み）を受けることにより検針前準備を開始する。

次に、ネットワーク管理装置１は検針前準備として、ＲＤＢ Ｉ／Ｆ部１５が顧客テーブル（図５）から検針対象となる顧客に対応するメータのメータＩＤを抽出する。図５において、“状態”が“利用”となっているものがデータ取得の対象となるので、対応するメータＩＤを抽出する。そして、抽出したメータＩＤを元に、対象となるメータ数分のデータエントリー（行）をデータ取得結果テーブル（図６）として作成（ＩＮＳＥＲＴ）する（Ｓ４０２）。この段階では電力使用量の欄は全て空の状態である（図６）。

図１１に示すように、各メータ２は定められた時刻（例えば月の初日の午前０時）が来ると、トリガ信号入力部２１が内部又は外部のタイマーからトリガ信号を受信し（Ｓ１１０１）、ＳＮＭＰエージェント２４及びＳＮＭＰ送受信部２３が、予め定義した企業拡張ＭＩＢとして定義されたＳＮＭＰ−ＴＲＡＰ−ＩＤを使って、収集情報（例えば、１ケ月の電力使用量データ）をメータのＩＰアドレスやメータのＩＤ等の情報とともにＳＮＭＰ−ＴＲＡＰオペレーションによりネットワーク管理装置１に送信する（図７）（Ｓ１１０２）。なお、ネットワーク管理装置１の宛先ＩＰアドレスはメータ設置・保守時に設定されているものとする。

収集情報（電力使用量データ）はＳＮＭＰ−ＴＲＡＰのＶＡＲ−ＢＩＮＤ部に埋め込まれて送信することとし（図７）、ネットワーク管理装置１側では、ＳＮＭＰ送受信部１２が各メータ２からの収集情報を受信するとともに、図４に示すように、受信したＳＮＭＰ−ＴＲＡＰのＶＡＲ−ＢＩＮＤの内容を解析して、対応するＲＤＢテーブルのフィールドへ書き込む（図８）（Ｓ４０３）。 例えば、ＶＡＲ−ＢＩＮＤ−ＩＤ １．３．６．１．２．４．１．４０９．４として送信された電力使用量の値が”１２３４”である場合、ＶＡＲ−ＢＩＮＤ−ＩＤ １．３．６．１．２．４．１．４０９．１として送信されたメータＩＤと同じ値をもつＲＤＢのデータ取得結果テーブルエントリの電力使用量欄を”１２３４”にアップデートする（図８）。

ところでＳＮＭＰ−ＴＲＡＰはエージェント（メータ）からマネージャ（ネットワーク管理装置）への片方向の通信のため、回線品質不良・回線輻輳等により、データが紛失することがある。このデータの紛失はメータ側では検出することはできないため、メータ側からデータパケットの紛失を検知して再送処理を行うことはできない。

そこでネットワーク管理装置１側では定義された受信期間の経過を待ち（Ｓ４０４）、受信状況管理部１３がデータ取得結果テーブル（図８）内で電力量が書き込まれていないフィールドを持つメータをデータロスが生じたメータであるとみなし抽出する。抽出したメータについて電力使用量に対応するデータをＳＮＭＰ−ＧＥＴオペレーションにより取得し、取得した値を対応するＲＤＢ３の当該フィールドに書き込むことでリカバリ処理を行う（Ｓ４０５）。具体的には、ＳＮＭＰ送受信部１２がＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより再送要求を送信し、ＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションにより送信された収集情報（電力使用量データ）を受信してリカバリ処理とする。一方、メータ２側では、図１２に示すように、受信待ち（Ｓ１２０１）期間の後、ＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴによる再送要求を受信した場合（Ｓ１２０２）には、収集情報をＳＮＭＰ−ＲＥＳＰＯＮＳＥにより再送（Ｓ１２０３）し、プロセス終了の指示があれば処理を終了する（Ｓ１２０４）。

また、ＳＮＭＰ−ＧＥＴによるリカバリ処理は複数回行うように設定することも可能である。例えば、最初のＳＮＭＰ−ＧＥＴがタイムアウトによりエラーとなった場合、指定された回数（例えば３回）リトライ処理を行う等である。

ＳＮＭＰ−ＧＥＴによるリカバリ処理終了後も、電力使用量データ部が書き込まれていないメータについては、メータ機器の故障又は通信回線障害の可能性が高いので、エラー事象用ログに書き込む。

ＳＮＭＰ− ＴＲＡＰのＴＲＡＰ番号はＲＤＢ３のＴＡＢＬＥ−ＩＤに対応させ、ＶＡＲ−ＢＩＮＤ−ＩＤはテーブルのフィールドに対応させことになるが、この対応をネットワーク管理装置１の設定ファイル（図９）によることにより、汎用的なデータ収集手法とすることが可能である。

なお、本システムにおいては各メータ、ネットワーク管理装置が内部時計を利用する場合には、内部時計が正確であることが必要となる。これについては、ＮＴＰプロトコルにより公開されているＳｔｒａｔｕｍ１〜２程度のクラスのＮＴＰサーバと同期させたり、電波時計の回路を内蔵させる、標準時を取得するなどの方法等により時刻を正確に合わせることが可能である。このようにして、ネットワーク管理装置とメータの時刻誤差を一定範囲に抑えることができる。

また、ネットワーク管理装置側では、ＳＮＭＰ−ＴＲＡＰが集中することが考えられるが、取りこぼさないように十分大きなＳＮＭＰ−ＴＲＡＰ受信用のキューを用意し、到着したＳＮＭＰ−ＴＲＡＰをバッファリングし順次処理することにより対処できる。

このように、本実施の形態によれば、ネットワーク管理装置１とメータ２（エージェント）が連携して動作することより、データ取得のためのネットワーク管理装置のポーリング負荷を減らすことができるのでシステム全体の管理対象数を増やすことができる利点がある。

また、ＴＲＡＰに監視データを含めて送信するので、パケットが届いた場合、再度不要なＳＮＭＰ−ＧＥＴパケットを出す必要がなく、全体として通信量を減少させることができ、ネットワーク負荷が減るので管理対象にできる端末数を増やすことができる利点がある。

同時に、ＴＲＡＰパケットが届かない場合でもネットワーク管理装置からＲＤＢを使ってＳＮＭＰ−ＧＥＴプロトコルを使ったリカバリ処理を行うので、信頼性は単純ポーリング方式と同様に確保することができる効果がある。

実施の形態２．
本実施の形態は、実施の形態１のシステムにおいて、メータ２からネットワーク管理装置１へのＳＮＭＰ−ＴＲＡＰの送信が集中し、輻輳やパケットロスが生じないように、負荷を分散する仕組みを備えたメータ２（エージェント）に関する。

すなわち、各メータでのデータ送信時間を０時から０時５分と設定してあった場合、この時間内でそれぞれのメータからのＳＮＭＰ−ＴＲＡＰの送信が分散するように、各メータはこの時間内のいずれかの時刻をランダムに定めるため、乱数を使って時刻を決め、この時刻にＳＮＭＰ−ＴＲＡＰを送信するように改良する。
実施の形態１のシステムでは、時刻を指定していたので、ある時刻に負荷が集中してしまうため、パケットロスが生じる確率が高くなる。この結果、ＳＮＭＰ−ＧＥＴによるリカバリ処理の回数が多くなり管理装置の負荷が増える。

本実施の形態によれば、この負荷集中を改善できる効果がある。

実施の形態３．
本実施の形態は、メータ側から監視データを送信するためのトリガーとしてタイマーイベント以外の手段を使うところが、実施の形態１及び２と異なる。
近年のＩＰネットワーク（特にＩＰｖ６ネットワーク）では、ネットワークを階層的に構成することが多い。このような場合に、各階層のある枝の下全体をスコープとするマルチキャストパケットを定義し、ネットワーク管理装置から取得したいスコープ部分（例えば、図１０の１００の部分）にマルチキャストパケットを送信し当該部分のメータ群に対してＳＮＭＰ−ＴＲＡＰ送信のトリガーを与え、監視データを送信させることもできる。

また、実施の形態２と同様に、同じスコープ内の複数のメータ間で、ＳＮＭＰ−ＴＲＡＰの送信が分散するようにＳＮＭＰ−ＴＲＡＰの送信時刻を各メータでランダムに定めるようにすることも可能である。

この場合、各メータに対してネットワーク管理装置から問い合わせる必要が無くなるので、ネットワーク管理装置のポーリング負荷及びネットワークの負荷を減らすことができる。従って、本実施の形態によれば、監視対象数を増やすことができるメリットがある。

実施の形態４．
実施の形態１〜３では、ＳＮＭＰ−ＴＲＡＰフォーマットさえ合致するパケットを送信すれば、ＲＤＢ３内の監視データを書き換えることができる。すなわち、不正パケットに対する対策が十分でないともいえる。本実施の形態はこれを解決するためのものである。

すなわち、監視データ（電力使用量）といっしょに送信される、「送信元ＩＰアドレス」をキーにＲＤＢに登録された当該ＩＰアドレスに対応する「メータＩＤ」を調べ、これとＳＮＭＰ−ＴＲＡＰのＶＡＲ−ＢＩＮＤとして同時に送信された「メータＩＤ」と一致するかどうかを検査し、一致した場合に監視データ部分の書き換えを行い、それ以外の場合は不正パケットであるとして書き換えを行わない、という不正パケット検出機構を付け加えるものである。

これにより、ＲＤＢ３への不正アクセスを検出することができ、データの改ざん等を防止することができる。

ここで、以上の実施の形態に示したシステムの特徴を以下にて示す。

以上の実施の形態に示したシステムは、ＳＮＭＰを用いたネットワーク管理において以下のデータ収集の手段を備えたことを特徴とする。
（ａ）被管理ノードの装置ＩＤ、ＩＰアドレス等の構成情報をリレーショナル・データベース（以下「ＲＤＢ」と略）に保持し、被管理ノードに関する情報を管理する機能を持つネットワーク管理装置、
（ｂ）定められた時間帯に、事前に定義した企業拡張ＭＩＢによりＳＮＭＰ−ＴＲＡＰで監視情報を送信し、また当該監視情報をＳＮＭＰ−ＧＥＴにより取得することを可能にする被管理ノード、
（ｃ）被管理ノードから定められた時間帯内に、ＳＮＭＰ−ＴＲＡＰにより当該監視情報を受信した場合、ＲＤＢのデータ取得結果テーブルに保存し、ＳＮＭＰーＴＲＡＰを受信しない場合に、当該ＳＮＭＰ−ＴＲＡＰで送信されたであろう情報をＳＮＭＰ−ＧＥＴで取得し、復旧処理を行う機能を持つネットワーク管理装置。

また、上記被管理ノードを電力量メータ計とし、監視情報を電力使用量とし、ＳＮＭＰプロトコルを使って、電力使用量を自動収集することを特徴とする。

また、各被管理ノードから、定められた時間帯内にタイマーイベントをトリガーとしてＳＮＭＰ−ＴＲＡＰにより監視情報を送信する場合において、送信パケットが同一時刻に集中しパケットが輻輳・廃棄されることを回避するため、被管理ノードが、ＳＮＭＰ−ＴＲＡＰパケットの送信を当該時間帯内でランダムに定めた時刻に送信することにより管理パケットの輻輳等を回避する機能をもつことを特徴とする。

また、被管理ノードにおいて、タイマーイベントをトリガーとしてＳＮＭＰ−ＴＲＡＰを送信するのではなく、ネットワーク管理装置からの送信指示マルチキャストパケットをトリガーとしてＳＮＭＰ−ＴＲＡＰを送信することを特徴とする。

また、被管理ノードにおいて、トリガーとなるマルチキャストパケットを受信した直後にＳＮＭＰ−ＴＲＡＰを送信するのではなく、乱数により定めた時間待った後に、ＳＮＭＰ−ＴＲＡＰを送信する機能を持つことを特徴とする。

また、ＳＮＭＰ−ＴＲＡＰの送信元ＩＰアドレスを元にＲＤＢの顧客テーブルを検索した結果、メータＩＤがＳＮＭＰ−ＴＲＡＰ内のメータＩＤ一致する場合にのみＲＤＢの管理データエントリを書き換えるようにすることを特徴とする。

実施の形態１〜４に係る通信システムのシステム構成例を示す図。 実施の形態１に係るメータの構成例を示す図。 実施の形態１に係るネットワーク管理装置の構成例を示す図。 実施の形態１に係るネットワーク管理装置の処理例を示すフローチャート図。 実施の形態１に係る顧客テーブルの例を示す図。 実施の形態１に係るデータ取得結果テーブル（受信処理前）の例を示す図。 実施の形態１に係るＳＮＭＰ−ＴＲＡＰの例を示す図。 実施の形態１に係るデータ取得結果テーブル（更新状態）の例を示す図。 実施の形態１に係る定義ファイル例を示す図。 実施の形態３に係るマルチキャストパケットの送信対象スコープの例を示す図。 実施の形態１に係るメータの処理例を示すフローチャート図。 実施の形態１に係るメータの処理例を示すフローチャート図。

符号の説明

１ ネットワーク管理装置、２ メータ、３ リレーショナルデータベース、４ ネットワーク、５ ルータ、１１ トリガ信号入力部、１２ ＳＮＭＰ送受信部、１３ 受信状況管理部、１４ ＳＮＭＰ ＡＰＩ、１５ ＲＤＢインタフェース部、１６ ＵＤＰ／ＴＣＰ処理部、１７ ＩＰｖ４／ＩＰｖ６処理部、２１ トリガ信号入力部、２２ 管理データ計測部、２３ ＳＮＭＰ送受信部、２４ ＳＮＭＰエージェント、２５ ＳＮＭＰ ＡＰＩ、２６ ＵＤＰ／ＴＣＰ処理部、２７ ＩＰｖ４／ＩＰｖ６処理部。

Claims (16)

1. 情報の収集を行うとともに、送信された情報が送信先に到達したか否かの確認が行われない非確認型通信プロトコルを用いて、収集した収集情報を送信する複数の情報収集装置と、
   前記複数の情報収集装置を管理し、前記非確認型通信プロトコルを用いて、前記複数の情報収集装置から収集情報を受信する管理装置とを有する通信システムであって、
   前記複数の情報収集装置のそれぞれは、
   それぞれに対して予め定められた送信タイミングにおいて、前記非確認型通信プロトコルを用いて収集情報を前記管理装置に対して送信し、
   前記管理装置は、
   情報収集装置ごとに、それぞれの情報収集装置の送信タイミングにおいて収集情報を受信できたか否かを判断するとともに、送信タイミングにおいて収集情報を受信できていない情報収集装置に対して収集情報の再送を要求することを特徴とする通信システム。
2. 前記複数の情報収集装置は、
   非確認型通信プロトコルとして、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）−ＴＲＡＰオペレーションにより収集情報を前記管理装置に対して送信し、
   前記管理装置は、
   送信タイミングにおいて収集情報を受信できていない情報収集装置に対して、ＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより収集情報の再送を要求することを特徴とする請求項１に記載の通信システム。
3. 前記複数の情報収集装置のそれぞれは、
   前記管理装置から、ＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより収集情報の再送が要求された場合に、収集情報をＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションにより前記管理装置に対して送信することを特徴とする請求項２に記載の通信システム。
4. 前記管理装置は、
   情報収集装置から収集情報を受信した際に、受信した収集情報をリレーショナルデータベースに記録することにより、それぞれの情報収集装置の送信タイミングにおいて収集情報を受信できたか否かを判断することを特徴とする請求項１に記載の通信システム。
5. 前記複数の情報収集装置のそれぞれは、
   メータ値情報を収集し、収集情報としてメータ値情報を前記管理装置に対して送信することを特徴とする請求項１に記載の通信システム。
6. 前記複数の情報収集装置のそれぞれは、
   それぞれ異なる送信タイミングで収集情報を前記管理装置に対して送信することを特徴とする請求項１に記載の通信システム。
7. 前記管理装置は、
   前記複数の情報収集装置からの収集情報の送信に先立ち、収集情報の送信を指示する収集情報送信指示を前記複数の情報収集装置に対して送信し、
   前記複数の情報収集装置のそれぞれは、
   前記管理装置から送信された収集情報送信指示を受信した場合に、収集情報を前記管理装置に対して送信することを特徴とする請求項１に記載の通信システム。
8. 前記複数の情報収集装置のそれぞれは、
   前記管理装置から送信された収集情報送信指示を受信した場合に、それぞれ異なる送信タイミングで収集情報を前記管理装置に対して送信することを特徴とする請求項７に記載の通信システム。
9. 前記管理装置は、
   情報収集装置ごとに、情報収集装置の識別子と情報収集装置の通信アドレスとを対応させて表示するリレーショナルデータベースを管理しており、
   前記複数の情報収集装置のそれぞれは、
   収集情報の送信の際に、収集情報にそれぞれの情報収集装置の識別子を付加して送信し、
   前記管理装置は、
   収集情報を受信した際に、収集情報の送信元の通信アドレスに基づきリレーショナルデータベースを検索し、送信元の通信アドレスに対応する情報収集装置の識別子が受信した収集情報に付加された識別子と一致する場合に、受信した収集情報をリレーショナルデータベースに記録することを特徴とする請求項１に記載の通信システム。
10. 情報の収集を行うとともに、収集した収集情報をそれぞれに対して予め定められた送信タイミングにて送信する複数の情報収集装置を、管理する管理装置であって、
    送信された情報が送信先に到達したか否かの確認が行われない非確認型通信プロトコルを用いて、前記複数の情報収集装置から収集情報を受信する収集情報受信部と、
    情報収集装置ごとに、それぞれの情報収集装置の送信タイミングにおいて収集情報を受信できたか否かを判断するとともに、送信タイミングにおいて収集情報を受信できていない情報収集装置に対して収集情報の再送を要求する再送要求を生成する受信状況管理部と、
    前記受信状況管理部により生成された再送要求を、収集情報を受信できていない情報収集装置に対して送信する再送要求送信部とを有することを特徴とする管理装置。
11. 前記収集情報受信部は、
    非確認型通信プロトコルとして、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）−ＴＲＡＰオペレーションを用いて前記複数の情報収集装置から収集情報を受信し、
    前記再送要求送信部は、
    収集情報を受信できていない情報収集装置に対して、ＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより再送要求を送信することを特徴とする請求項１０に記載の管理装置。
12. 前記収集情報受信部は、
    前記再送要求送信部から再送要求が送信された情報収集装置からＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションにより再送された収集情報を受信することを特徴とする請求項１１に記載の管理装置。
13. 情報の収集を行うとともに、送信された情報が送信先に到達したか否かの確認が行われない非確認型通信プロトコルを用いて、収集した収集情報を所定の管理装置に対して送信する情報収集装置であって、
    情報の収集を行う情報収集部と、
    前記情報収集部が収集した収集情報を前記非確認型通信プロトコルにより前記管理装置に対して送信する収集情報送信部と、
    前記収集情報送信部から送信された収集情報が前記管理装置に到達しなかった場合に、前記管理装置より収集情報の再送を要求する再送要求を受信する再送要求受信部とを有することを特徴とする情報収集装置。
14. 前記収集情報送信部は、
    非確認型通信プロトコルとして、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）−ＴＲＡＰオペレーションを用いて前記管理装置に対して収集情報を送信し、
    前記再送要求受信部は、
    前記収集情報送信部から送信された収集情報が前記管理装置に到達しなかった場合に、ＳＮＭＰ−ＧＥＴ−ＲＥＱＵＥＳＴオペレーションにより前記管理装置から送信された再送要求を受信することを特徴とする請求項１３に記載の情報収集装置。
15. 前記収集情報送信部は、
    前記再送要求受信部により再送要求が受信された場合に、収集情報をＳＮＭＰ−ＲＥＳＰＯＮＳＥオペレーションにより前記管理装置に対して再送することを特徴とする請求項１４に記載の情報収集装置。
16. 情報の収集を行うとともに、送信された情報が送信先に到達したか否かの確認が行われない非確認型通信プロトコルを用いて、収集した収集情報を送信する複数の情報収集装置と、
    前記複数の情報収集装置を管理し、前記非確認型通信プロトコルを用いて、前記複数の情報収集装置から収集情報を受信する管理装置とを用いる通信方法であって、
    前記複数の情報収集装置のそれぞれは、
    それぞれに対して予め定められた送信タイミングにおいて、前記非確認型通信プロトコルを用いて収集情報を前記管理装置に対して送信し、
    前記管理装置は、
    情報収集装置ごとに、それぞれの情報収集装置の送信タイミングにおいて収集情報を受信できたか否かを判断するとともに、送信タイミングにおいて収集情報を受信できていない情報収集装置に対して収集情報の再送を要求することを特徴とする通信方法。

Images