JP2005124057A - ネットワーク機器およびネットワーク状態通知方法 - Google Patents

Abstract

【課題】ネットワークの状態に起因して発生する複数の異常を、その異常ごとに確実に検知し、これをユーザーに通知して、適切な対応を迅速に取ることができるようにする。
【解決手段】衝突検出型のネットワークシステムを構成するネットワーク機器において、主に通信部３２の機能により、ネットワークの接続やネットワーク上に送出するようにされるパケットの量等のネットワークの状態に起因して発生する種々の異常の発生に関連する事象、例えば、キャリアの未検出、相手先機器からの応答の未検出、送信時のパケットの衝突、パケットの再送信、パケット送出の遅延などを検出し、制御部３７が適正に通信を行うことができないと判別した場合に、通信部３２を通じて検出した異常に関連する事象の検出の状態を表示部３４に表示して通知する。
【選択図】図３

Description

この発明は、例えば、イーサネット（登録商標）（Ethernet（登録商標））に代表される衝突検出型ネットワークに接続されるネットワーク機器およびネットワークの状態を通知するようにするための方法に関する。

ビル内や事業所の構内などの限られた所定の空間でパーソナルコンピュータや周辺機器などを接続し、ファイルやプリンタなどの資源を共有（共用）できるようにしたＬＡＮ（Local Area Network）システムが広く利用されるようになってきている。近年においては、家庭内に設置されるパーソナルコンピュータやＡＶ（Audio/Visual）機器等を接続することによりＬＡＮシステム（ホームネットワークシステム）を構築するようにすることも行なわれるようになってきている。

ＬＡＮシステムを構築するためには、規格化されたプロトコルやネットワークＯＳ（Operating System）を使用し、通常はＬＡＮアダプタやケーブル、あるいは、無線によって各機器間を接続するようにしている。また、ＬＡＮの接続形態（トポロジー）には、バス型、リング型、スター型などがあり、通信制御方式には、イーサネット（登録商標）に代表されるＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection：搬送波感知多重アクセス／衝突検出）方式やトークン・リングなどのトークン・パッシング（Token Passing）方式などがある。近年においては、障害に強いイーサネット（登録商標）方式、すなわち衝突検出型のＬＡＮが広く用いられている。

そして、ＬＡＮシステムにおいては、定期的に通信の相手先機器に対して所定のコマンドを生成して送出し、当該相手先機器から種々の設定値やエラーフラグの提供を受けるようにすることによって、障害の発生を検出し、その発生原因を解析することができるようにしているものもある。しかし、通信の相手先から定期的に種々の設定値やエラーフラグなどの情報の提供を受けるようにするのは、それらの情報の送受に時間がかかるために、障害の発生の迅速な検出ができない場合がある。

そこで、後に記す特許文献１には、ネットワーク診断プログラムｐｉｎｇで用いられるＩＣＭＰ（Internet Control Message Protocol）ｅｃｈｏパケットなどの非常に簡略化したコマンドを通信の相手先機器に送信し、その応答を受信する処理を頻繁に行うようにして、障害が発生した場合には、これを迅速に検出できるようにする技術が開示されている。

この特許文献１に記載の技術を用いることにより、通信の相手先機器との間に障害が発生したことを迅速に検出し、障害を速やかに回避することができるようにしている。

上記の特許文献１は、以下の通りである。
特開２００２−２８１５２８号公報

上述した特許文献１に開示された技術の場合、通信の相手先機器に障害が発生し、通信ができなくなった場合には、これを迅速かつ正確に検出することが可能である。しかしながら、これだけでは、不十分な場合があると考えられる。

例えば、イーサネット（登録商標）に代表される衝突検出型ネットワーク方式では、その原理上パケットの衝突やネットワーク上のパケットの輻輳によりＱｏＳ（Quality Of Service）を保証することが非常に困難である。すなわち、衝突検出型のＬＡＮの場合、パケットが衝突した場合には、衝突したパケットは正常な伝送ができないので、再送信するようにされる。

このため、衝突検出型のＬＡＮシステムの場合、パケットの衝突が頻繁に発生することにより、パケットの再送信が頻繁に行うようにされる可能性がある。そして、パケットの再送信が頻繁に行うようにされた場合には、ネットワークに係る負荷が大きくなり、パケット送出の遅延時間が急増し、機器は正常に動作しているにもかかわらず、データの送受が行われなくなるいわゆるメルトダウンを発生させてしまう場合があると考えられる。

この他にも、ケーブルが脱落することにより物理的な伝送路が失われたり、通信の相手先機器の電源がオフにされるなどして、当該相手先機機器を検知することができなくなったり、また、ＣＲＣ（Cyclic Redundancy Check）エラーが多発するなどのことも考えられる。このように、ネットワークに接続された機器自身の問題ではなく、主に、ネットワークの接続やネットワーク上に送出するようにされるパケットの量や送出タイミングなど、主にネットワークの状態（ネットワークのトラフィックの状態）に起因して生じる種々の異常が発生した場合には、パケット伝送のＱｏＳを満たすことができなくなる可能性が大きくなってしまう。

そして、衝突検出型のＬＡＮシステムの場合には、ネットワークに係る種々の異常に起因して、パケットを正常かつ迅速に送受することができない状態にあっても、これを異常とは検出せずに、パケットの再送信を行うことによって自己復旧しようと動作する。このため、パケットが正常かつ迅速に送受できない場合であっても、なぜ正常かつ迅速にパケットが送受できないのかをユーザーは知ることができない。

また、一般的に、ネットワークの状態に起因して生じる異常（いわゆるネットワーク障害）が瞬時的に発生したような場合には、異常状態から正常状態へ復帰後において、発生した障害の原因を追求することは困難である。また、ネットワークの状態に起因して生じる種々の異常のそれぞれを区別して検知することも難しい。

このため、イーサネット（登録商標）に代表される衝突検出型のネットワークに接続される機器のユーザー（利用者）は、ネットワークの接続やトラフィック量等のネットワークの状態に起因して発生するネットワークの異常の発生原因を知ることができず、機器の故障と勘違いするなどして、適切な対応を取ることができないという問題がある。このことは、近年、広く利用されるようになってきている衝突検出型のホームネットワークシステムにおいては重大な問題である。

すなわち、ホームネットワークシステムにおいては、これに接続されたサーバー装置とＡＶ機器間、あるいは、ＡＶ機器同士でオーディオデータやビデオデータを送受し、いわゆるストリーミング再生を行うようにする場合も多くなってきている。しかし、ネットワークの状態に起因してネットワークの異常が発生する場合があることから、ストリーミングデータを伝送するようなアプリケーションが動作している場合に、かならずしもストリーミングデータのリアルタイム性を保証することができず、音切れ等を起こす可能性がある。

しかも、衝突検出型のホームネットワークシステムのユーザーが、ＬＡＮについて正確な知識を持っていることは少なく、ネットワークの接続やネットワーク上のトラフィックの状態に起因してネットワークの異常が発生した場合に、その発生原因を適正に理解し、ネットワークに接続された機器の故障と混同することなく、発生した異常に対して適切な対応を迅速に取るようにすることは多くの場合において困難である。

以上のことにかんがみ、この発明は、ネットワークの状態に起因して発生する複数の異常を、その異常ごとに確実に検知し、これをユーザーに通知するようにして、機器の故障と混同することなく、適切な対応を迅速に取ることができるようにする装置、方法を提供することを目的とする。

上記課題を解決するため、請求項１に記載の発明のネットワーク機器は、
衝突検出型ネットワークに接続されるネットワーク機器であって、
前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象を検出するようにする検出手段と、
前記検出手段の検出結果に基づいて、前記ネットワークを通じて適正に通信を行うことができるか否かを判別する判別手段と、
前記判別手段により、前記ネットワークを通じて適正に通信を行うことができないと判別された場合に、前記検出手段によって、どのような異常についての発生に関連する事象が検出されたかを操作者が判別可能な態様で通知するようにする通知手段と
を備えることを特徴とする。

この請求項１に記載の発明のネットワーク機器によれば、イーサネット（登録商標）などのいわゆる衝突検出型のネットワークに接続されるネットワーク機器であって、検出手段により、ネットワークの接続やネットワーク上に送出するようにされるパケットの量等のネットワークのいわゆるトラフィックに起因して発生する種々の異常の発生に関連する事象、例えば、キャリアの未検出、相手先機器からの応答の未検出、送信時のパケットの衝突、パケットの再送信、パケット送出の遅延などが検出するようにされる。

そして、判別手段によって適正に通信を行うことができないと判別された場合に、検出手段によってどのような異常の発生に関連する事象が検出されたかをユーザー（操作者）が判別可能な態様で通知手段により通知するようにされる。すなわち、ユーザーに対して、どのような障害が発生しているのかを明示することができるようにされる。

これにより、ユーザーは、適正に通信を行うことができない場合に、通知手段により通知される情報に基づいて、ネットワークに発生している異常がどのような異常であるのかを知ることができるようにされる。したがって、ユーザーが、ネットワークに接続された当該ネットワーク機器の故障などと間違うことなく、適切な対応を迅速に取ることができるようにされる。

また、請求項２に記載の発明のネットワーク装置は、請求項１に記載のネットワーク機器であって、
前記判別手段により、前記ネットワークを通じて適正に通信を行うことができないと判別された場合に、データの送出を停止するようにする停止制御手段と、
前記停止制御手段によりデータの送出が停止された後に、最小単位のパケットのテストデータを形成し、これを前記ネットワークに送出するテストデータ送出手段と、
前記テストデータ送出手段を通じて前記テストデータが正常に送出できたか否かを確認する確認手段と
を備え、
前記通知手段は、前記確認手段により前記テストデータが正常に送出することができなかったことが確認された場合に、通知を行うようにすることを特徴とする。

この請求項２に記載の発明のネットワーク機器によれば、判別手段により適正に通信を行うことができないと判別された場合には、停止制御手段によりデータのネットワークへの送出が停止するようにされ、最小パケットとされたテストデータが送出するようにされる。そして、確認手段により、最小パケットのテストデータさえ送出することができないことを確認した場合に、検出手段によってどのような異常の発生に関連する事象が検出されたかをユーザーが通知手段により判別可能な態様で通知するようにされる。

これにより、ネットワークの状態が最小パケットのテストデータさえ送信することができない異常が発生している状態にある場合に、通知手段により通知される情報に基づいて、どのような異常が発生しているのかを知ることができるようにされる。そして、ネットワークに接続された当該ネットワーク機器の故障などと間違うことなく、適切な対応を迅速に取ることができるようにされる。

また、請求項３に記載の発明のネットワーク機器は、請求項１または請求項２に記載のネットワーク機器であって、
前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象は、
伝送路の喪失、通信の相手先の喪失、送信遅延の発生、送出データの衝突の発生、再送信処理の発生、データエラーの発生の少なくとも１つ以上を含むことを特徴とする。

この請求項３に記載の発明のネットワーク機器によれば、ネットワークの異常の発生に関連する事象として、伝送路の喪失、通信の相手先の喪失、送信遅延の発生、送出データの衝突の発生、再送信処理の発生、データエラーの発生が検出するようにされる。

この場合、伝送路の喪失は、接続ケーブルの脱落の可能性があることが分かるし、通信の相手先の喪失は、当該相手先の障害の可能性があることが分かる。また、送信遅延の発生、送出データの衝突の発生、再送信処理の発生は、ネットワーク上に送出されるデータが多いなど、ネットワークのいわゆるトラフィックの状態に係る異常であることが分かる。

これにより、ネットワークに係るどのような異常が発生しているのかを操作者が正確に把握することが可能となり、迅速に適切な対応を取ることができるようにされる。

また、請求項４に記載の発明のネットワーク機器は、請求項１、請求項２または請求項３に記載のネットワーク機器であって、
前記通知手段は、適正に通信を行うことができない場合の、あるいは、前記テストデータが送出できない場合の対処方法をも通知するようにしたことを特徴とする。

この請求項４に記載の発明のネットワーク機器によれば、例えば、伝送路の喪失が検出された場合には、「ケーブルがきちんと接続されているか確認してくだい。」とか、送出データの衝突が多発していることが検出された場合には、「他の機器も通信を行っています。時間をずらして通信を行うようにしてください。」といった、発生しているネットワークに係る異常に対する対処方法が具体的に通知するようにされる。これにより、ユーザーは、対象方法に迷うことなく、迅速により的確な対応を取ることができるようにされる。

この発明によれば、ネットワークの接続やネットワーク上に送出するようにされるデータの量等に起因して発生するネットワークに係る異常の発生に関連する事象をリアルタイムに検出、計測することができ、例えば、リアルタイム性が要求されるストリーミングデータ転送などにおいて、要求性能が保証できるか否かを正確に判定することができる。

また、検出したり計測したりしたネットワークについての異常の発生に関連する事象についての情報を操作者に対して通知することにより、ネットワークについての障害の発生原因を容易に究明することができるようにされる。したがって、ネットワークに係る障害が発生した場合に、ネットワーク機器の故障と間違うことなく、適切な対応を迅速に取ることができる。

以下、図を参照しながら、この発明による装置、方法の一実施の形態について説明する。以下に説明する実施の形態においては、イーサネット（登録商標）に代表されるいわゆる衝突検出型のホームネットワークシステム（家庭内に形成されるＬＡＮ）に接続されるＡＶ機器に、この発明を適用した場合を例にして説明する。すなわち、ＡＶ機器は、パーソナルコンピュータなどの情報処理装置ではなく、オーディオデータやビデオデータの処理専用の一般家庭用電気機器である。

［システム構成について］
図１は、この実施の形態のホームネットワークシステムの構成例を説明するための図であり、イーサネット（登録商標）に代表される衝突検出型のＬＡＮの一般的な接続形態（トポロジー）の一例を示すものである。図１に示すように、この実施の形態のホームネットワークシステムは、同一ネットワーク上（ＬＡＮ６上）に、サーバー装置１、パーソナルコンピュータ２、ＡＶ機器３、ノート型パーソナルコンピュータ４、ＡＶ機器５が接続されているものである。

サーバー装置１は、例えば、大容量のハードディスク装置部を備え、ＬＡＮ６を通じて供給された、あるいは、外部機器から直接的に供給されるなどした楽曲のオーディオデータ、映画のＡＶデータ（同期が取られているオーディオデータとビデオデータ）、静止画像データ、プログラム、テキストデータなどの種々のコンテンツを蓄積し、ＬＡＮ６に接続されたネットワーク機器からの要求に応じて、蓄積しているコンテンツを、ＬＡＮ６を通じて提供することができるものである。

パーソナルコンピュータ２、ノート型パーソナルコンピュータ４は、一般に用いられているものであり、ハードディスク装置部やＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）の再生部、あるいは、ＣＤ−Ｒ（Compact Disc Recordable）、ＣＤ−ＲＷ（Compact Disc Rewritable）、書き換え可能なＤＶＤの記録再生部等の記録再生部を備え、テキストデータ処理、ビデオデータ処理、オーディオデータ処理、その他の種々のデータ処理を行うことが可能な情報処理装置である。

この実施の形態において、ＡＶ機器３、５は、オーディオデータやビデオデータ（静止画像、動画像の双方を含む）、あるいは、ＡＶデータを処理し、再生するようにするものである。ＡＶ機器３、５としては、ＬＡＮの接続端子を備えた種々の電子機器を想定することが可能である。例えば、ハードディスクレコーダやデジタルＶＴＲ（Video Tape Recorder）等の記録装置部を備えたＡＶデータなどの記録再生機、モニタ受像機などのＡＶデータの再生機、ＩＲＤ（Integrated Receiver Decoder）などと呼ばれるデジタル放送受信機やセットトップボックス（Set-top Box）などと呼ばれるケーブルテレビ網への接続装置などは、この実施の形態のＡＶ機器３、５としてＬＡＮ６に接続が可能である。

なお、この実施の形態においては説明を簡単にするため、ＡＶ機器３、５は、ＡＶデータの再生機、あるいは、市販のテレビ受像機などをＬＡＮ６に接続するための接続装置として用いられるものとして説明する。

そして、この実施の形態のホームネットワークシステムは、上述もしたように衝突検出型のＬＡＮシステムであるので、ＬＡＮ６に接続された各ネットワーク機器からのパケットの送信タイミングを全体的に制御する機構はなく、各ネットワーク機器のそれぞれが任意のタイミングでパケットを送信することができる。しかし、送信タイミングによっては、パケットがネットワーク上で衝突し、データエラーが発生してパケットが失われることがある。このため、ＬＡＮ６に接続された各ネットワーク機器は、パケットの衝突検出機構を備え、パケットの再送信機能がサポートされている。

［各ネットワーク機器の構成例］
［サーバー装置１等の構成例］
次に、この実施の形態のホームネットワークシステムを構成する各ネットワーク機器の構成例について説明する。まず、サーバー装置１、パーソナルコンピュータ２、ノート型パーソナルコンピュータ４の構成例について説明する。図２は、サーバー装置１、パーソナルコンピュータ２、ノート型パーソナルコンピュータ４の基本的な構成例を説明するためのブロック図である。

図２に示すように、サーバー装置１、パーソナルコンピュータ２、ノート型パーソナルコンピュータ４のそれぞれは、衝突検出型のＬＡＮに接続するための接続端１１と、通信部１２と、多数のデジタルコンテンツ（提供情報）などを蓄積することが可能なハードディスク１３と、制御部１５と、キーインターフェース（以下、キーＩ／Ｆと略称する。）１６１、キー操作部１６２と、表示インターフェース（以下、表示Ｉ／Ｆと略称する。）１６３と、表示部１６４とを備えたものである。

制御部１５は、自装置内の各部を制御するものであり、ＣＰＵ（Central Processing Unit）１５１と、ＲＯＭ（Read Only Memory）１５２と、ＲＡＭ（Random Access Memory）１５３と、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）１５４とが、ＣＰＵバス１５５を通じて接続されて形成されたマイクロコンピュータである。

ここで、ＲＯＭ１５２は、ＣＰＵ１５１において実行するプログラムや処理に必要なデータなどが記録されたものであり、ＲＡＭ１５３は、主に各種の処理において作業領域として用いられるものである。ＥＥＰＲＯＭ１５４は、いわゆる不揮発性メモリーであり、種々のパラメータなどが記憶されるものである。

キー操作部１６２は、ユーザーからの操作入力を受け付けるものであり、カーソルを移動するための矢印キーや種々のファンクションキーなどが設けられたものである。このキー操作部１６２を通じて受け付けた操作入力に応じた電気信号は、キーＩ／Ｆ１６１を通じて制御部１５に供給するようにされる。これにより、サーバー装置１、パーソナルコンピュータ２、ノート型パーソナルコンピュータ４のそれぞれにおいては、ユーザーからの操作入力に応じた処理を行うことができるようにされる。

また、表示部１６４は、映像を表示させるものであり、制御部１５により制御される表示Ｉ／Ｆ１６３で処理されて形成された表示用映像信号の供給を受けて、種々の映像を自己の表示画面に表示することができるものである。表示部１６４には、例えば、御部１５において形成され、表示Ｉ／Ｆ１６３を通じて供給される各種の表示メッセージを表示することができるものである。

また、表示部１６４には、ハードディスク１３に蓄積されているメッセージデータ、テキストデータ、静止画データ、動画データに応じた表示用映像信号が表示Ｉ／Ｆ１６３を通じて供給され、ハードディスク１３に蓄積されている表示用のデータに応じた映像も表示することができるものである。

なお、サーバー装置１やパーソナルコンピュータ２の場合、キー操作部１６２や表示部１６４は、いわゆる外付けのキーボードや外付けのディスプレイ（ＣＲＴ（Cathode-Ray Tube）やＬＣＤ（Liquid Crystal Display））であり、ノート型パーソナルコンピュータ４の場合、キー操作部１６２や表示部１６４は、本体部に設けられたキーボードやＬＣＤである。

また、図２には図示しないが、例えば、外部機器接続端や外部Ｉ／Ｆ１６４を備えることにより、外部機器との間でデータの送受を直接的に行うようにしたり、また、ＣＤやＤＶＤの再生部、ＣＤ−Ｒ、ＣＤ−ＲＷ、記録可能なＤＶＤの記録再生部等を設けることにより、それらの記録媒体からデータを読み出して利用したり、記録可能な記録媒体に対してはデータを記録するなどのこともできるようにされる。

そして、上述もしたように、サーバー装置１、パーソナルコンピュータ２、ノート型パーソナルコンピュータ４のそれぞれは、接続端１１、通信部１２を通じてＬＡＮ６に接続され、ＬＡＮ６を通じて送信されてくる自機宛ての種々のデータを受信してこれをハードディスク１３に記録したり、また、相手先からのコンテンツ等の提供要求に応じて、ハードディスク１３から目的とするデータを読み出し、これを通信部１２、接続端１１を通じてＬＡＮ６に送出し、相手先の機器に送信したりすることなどができるようにされる。

［ＡＶ機器３、５の構成例］
次に、ＡＶ機器３、５について説明する。図３は、ＡＶ機器３、５の構成例を説明するためのブロック図である。図３に示すように、ＡＶ機器３、５は、ＬＡＮ６に接続するための接続端３１と、通信部３２と、映像信号処理部３３と、表示部３４と、音声信号処理部３５と、スピーカー３６と、制御部３７と、キーインターフェース（以下、キーＩ／Ｆと略称する。）３８１と、キー操作部３８２と、リモコン信号受光部３９１とを備えたものである。

制御部３７は、ＡＶ機器３、５の各部を制御するものであり、ＣＰＵ３７１と、ＲＯＭ３７２と、ＲＡＭ３７３と、ＥＥＰＲＯＭ３７４とが、ＣＰＵバス３７５を通じて接続されて形成されたマイクロコンピュータである。

ここで、ＲＯＭ３７２は、ＣＰＵ３７１において実行するプログラムや処理に必要なデータなどが記録されたものであり、ＲＡＭ３７３は、主に各種の処理において作業領域として用いられるものである。ＥＥＰＲＯＭ３７４は、いわゆる不揮発性メモリーであり、ＡＶ機器３、５の電源が落とされても保持しておくべき種々のデータが記録されるものである。

映像信号処理部３３は、所定のフォーマットのデジタル静止画データ、デジタル動画データの供給を受けて、これをデコードし、表示部３４に供給するアナログ映像信号を形成して、これを表示部３４に供給するものである。表示部３４は、例えば、ＬＣＤ、ＣＲＴ（Cathode-Ray Tube）、有機ＥＬ（Electronic Luminescence）、プラズマディスプレイなどであり、映像信号処理部３３からの映像信号の供給を受け、これに応じた画像を自己の表示画面に表示する。

また、音声信号処理部３５は、所定のフォーマットのデジタル音声信号の供給を受けて、これをデコードし、スピーカー３６に供給するアナログ音声信号を形成し、これをスピーカー３６に供給するものである。スピーカー３６は、音声信号処理部からの音声信号に応じた音声を放音する。

このように、ＡＶ機器３、５は、映像信号処理部３３と表示部３４とからなる画像再生系と、音声信号処理部３５とスピーカー３６とからなる音声再生系とを備えるものである。

そして、制御部３７には、図３に示したように、キーＩ／Ｆ３８１を通じてキー操作部３８２が接続されている。キー操作部３８２は、種々の操作キーを備えたものであり、ユーザーからの操作入力を受け付けて、操作入力に応じた電気信号を形成し、これをキーＩ／Ｆ３８１を通じて制御部３７に供給することができるものである。

また、リモコン信号受光部３９１は、リモートコマンダ（以下、リモコンという。）３９２からの例えば赤外線のリモコン信号を受光し、これを電気信号に変換して制御部３７に供給することとができるものである。リモコン３９１は、種々の操作キーを備え、ユーザーからの操作入力を受け付けて、これに応じたリモコン信号を形成して送出するものである。

キー操作部３８２、リモコン３９２は、いずれもカーソル移動のための矢印キーや決定キー、その他の操作キーを備えたものであり、コンテンツリストを要求したり、コンテンツリストから目的とするデジタルコンテンツを選択して目的とするコンテンツを要求したりするなどの種々の操作を受け付けることができるものである。

そして、ＡＶ機器３、５の制御部３７は、キー操作部３８２、あるいは、リモコン３９２を通じて受け付けたユーザーからのコンテンツリストの表示指示に応じて、コンテンツリストの提供要求を形成し、これを通信部３２、接続端３１を通じてパケットとしてＬＡＮ６に送出し、例えばサーバー装置１に送信する。

これに応じて、サーバー装置１から送信されてくるコンテンツリストが、接続端３１、通信部３２を通じて受信されて、制御部３７に供給され、ＲＡＭ３７３に一時記憶される。このＲＡＭ３７３に記憶されたコンテンツリストが、映像信号処理部３３を通じて表示部３４に供給され、表示部３４の表示画面にコンテンツリストが表示され、ユーザーは目的とするデジタルコンテンツの選択を行うことができるようにされる。

そして、目的とするデジタルコンテンツがコンテンツリスト上に見つかった時には、上述もしたように、その目的とするデジタルコンテンツの情報の表示欄（例えば、デジタルコンテンツのタイトルやアーチスト名の表示欄）にカーソルを位置付け、決定キーを操作することにより、そのデジタルコンテンツの識別ＩＤを含む提供要求が制御部３７において形成され、通信部３２、接続端３１を通じてパケットとしてＬＡＮ６に送出され、サーバー装置１に送信される。

これに応じて、サーバー装置１から目的とするデジタルコンテンツがパケットとして送信されてくるので、これが接続端３１、通信部３２を通じて受信され、この例の場合には、制御部３７を通じて画像パケットは、映像信号処理部３３に、音声パケットは、音声信号処理部３５に供給される。

そして、上述もしたように、映像信号処理部３３においては、これに供給された画像データからアナログ映像信号が形成されて、これが表示部３４に供給されることによりデジタルコンテンツの映像が表示部３４の表示画面に表示される。また、音声信号処理部３５においては、これに供給された音声データからアナログ音声信号が形成されて、これがスピーカー３６に供給されることにより、デジタルコンテンツの音声がスピーカー３６から放音される。このようにして、サーバー装置１からのデジタルコンテンツのＡＶ機器３、５におけるストリーミング再生が行うようにされる。

また、この実施の形態のＡＶ機器３、５の映像信号処理部３３、音声信号処理部３５は、複数の異なるフォーマットに対応することができるものである。例えば、音声信号の場合には、ＬＰＣＭ、ＡＴＲＡＣ、ＭＰ３等に対応可能であり、映像信号についても、ＭＰＥＧ１、ＭＰＥＧ２等に対応可能である。

なお、図３に示したＡＶ機器３、５は、映像信号処理部３３と表示部３４とからなる画像処理系と、音声信号処理部３５とスピーカー３６とからなる音声処理系とを備えるものとして説明した。しかし、表示部３４は、ＡＶ機器３、５とは別個に設けられたモニタ受像機などであってもよく、また、スピーカー３６もまたＡＶ機器３、５とは別個に設けられたものであってももちろんよい。

また、上述のＡＶ機器３、５の映像信号処理部３３と音声信号処理部３５とは例えば制御部３７において実行されるソフトウエアによって実現することも可能である。

［ホームネットワークシステムの基本動作について］
次に、図２、図３を用いて説明した構成のネットワーク機器が、図１に示したようにＬＡＮ６に接続されて形成されたこの実施の形態のホームネットワークシステムにおいて、正常にパケットが送受できる場合と、パケットの衝突が発生するために、再送信が行われる場合とについて、図４、図５を参照しながら説明する。ここでは、サーバー装置１、パーソナルコンピュータ２、ＡＶ機器３とがパケットを送出する場合を例にして説明する。

図４は、パケットが正常に送信できる場合のタイミング例を説明するための図である。図４に示すように、時点ｔ０を基準として、サーバー装置１は、時間ｔ１経過後にパケット１を、時間ｔ１’経過後にパケット１’をそれぞれ送出するようにし、パーソナルコンピュータ２は、時間ｔ２経過後にパケット２を、時間ｔ２’経過後にパケット２’をそれぞれ送出するようにし、また、ＡＶ機器３は、時間ｔ３経過後にパケット３を、時間ｔ３’経過後にパケット３’をそれぞれ送出するようにした場合を示している。

この場合には、パケット送信開始タイミング＋送信時間が重ならないため、各ネットワーク機器から送出されるパケットはエラーなく正常に目的とする相手先機器に送信されて送信を完了することができる。すなわち、図４に示した例の場合には、サーバー装置１、パーソナルコンピュータ２、ＡＶ機器３から送出されるパケットの送出タイミングが重なり合うことがなく、しかも、送出されたパケットの送信時間も重なり合うこともないので、パケットを正常に送信することができるのである。

図５は、パケット衝突が発生する場合のタイミング例を説明するための図である。この図５に示す例の場合には、時点ｔ０を基準として、時間ｔ１経過後において、サーバー装置１、パーソナルコンピュータ２、ＡＶ機器３が同時にパケットを送信しようとした場合、それぞれのネットワーク機器のネットワークインターフェース（通信部）が持つ衝突検出機能により、パケット衝突が検出される。

パケットの衝突を検出すると、各ネットワーク機器のネットワークインターフェースでは、パケットの送出タイミングを規定時間時間分遅延させるようにし、衝突したパケットの再送信を行うようにする。この場合、パケットの規定の遅延時間は、例えば乱数を用いるようにして得られるランダムな値である。このように、遅延時間をランダムな値にするのは、再送信のタイミングが固定値であれば、パケットの衝突が繰り返されることになるためであり、換言すれば、各ネットワーク機器における再送信のタイミングを分散させ、再衝突することを防ぐためである。

そして、図５に示した例の場合、サーバー装置１は、時点ｔ０から時間ｔ２経過後において、パケットの再送信を行い、パーソナルコンピュータ２は、時点ｔ０から時間ｔ３経過後において、パケットの再送信を行い、ＡＶ機器３は、時点ｔ０から時間ｔ４経過後においてパケットの再送信を行うようにしている。

この場合、サーバー装置１の再送信時においては、他のネットワーク機器とパケットの送信タイミングが衝突することも、また、他のネットワーク機器とのパケットの送信時間が重なり合うこともないので、サーバー装置１はパケット１を再送信により正常に送信することができる。

一方、パーソナルコンピュータ２がパケットの送信を開始したタイミング（時点ｔ０から時間ｔ３経過後の時点）からパケット送信が続いている間に、ＡＶ機器３が時点ｔ０から時間ｔ４経過後の時点からパケット送信を行ってしまった場合には、再び衝突が発生することとなる。

両者のネットワークインターフェースは、再度パケット衝突を検出し、再び パケット衝突の検出時点を基準時点とし、時間ｔ５経過後のタイミング、および、時間ｔ６経過後のタイミングでパケットの再々送信を行う。この場合にもパケット衝突が再々度発生すると、パケットが正常に送信できるまで再送信が繰り返されることになる。

そして、パケットの衝突が発生した場合、衝突したパケットはデータエラーとなり、破棄される。従って、パケット衝突回数に反比例して、ネットワーク帯域の利用効率は低下する。また、同一ネットワーク上に接続されている機器が多数であり、かつ、パケット送信頻度が高い場合、パケット衝突による再送信処理が、送出すべきパケットを雪だるま式に増加させ、一定値を超えると、パケット衝突が絶え間なく発生してしまうような状態になり、ネットワークがメルトダウンすることが発生し得ることになる。

すなわち、ＣＳＭＡ／ＣＤ型等のいわゆる衝突検出型のＬＡＮシステムは、パケットの衝突が発生しても、自動的に再送信を行う機能を備えているので、障害に強いシステムであると言える。しかし、ネットワークにかかる負荷が一定量を超えるといわゆるメルトダウン状態となりパケットの送受が行えなくなるという点において、大きな負荷はかけられないシステムであるといえる。換言すれば、ネットワークに接続されたネットワーク機器自体の故障が発生したわけではないのに、データの送受が行えなくなる状態があり、その状態がユーザーにとっては分かりにくい状態になっている。

このように、衝突検出型のＬＡＮシステムにおいては、ＬＡＮに接続されるネットワーク機器に原因があるのではなく、ネットワークの接続やデータの衝突や再送信と言ったネットワークの状態（ネットワークのトラフィックの状態）に起因して正常な通信ができなくなる場合がある。また、ネットワークの状態に起因して正常な通信ができなくなる場合には、種々の要因があり、なぜ正常な通信を行うことができなくなったのかをユーザーに通知することができなければ、ユーザーはネットワーク機器の故障と勘違いするなどして、適切な対応を迅速に取ることができない。

特に、ホームネットワークシステムを構成するＡＶ機器３、５においては、パーソナルコンピュータのような情報処理能力を備えていないので、ネットワークに起因して正常な通信ができない状態が発生することにより、音切れ等が発生してしまった場合には、ユーザーはＡＶ機器の故障と勘違いしてしまう場合が多くなる。

そこで、この実施の形態のＡＶ機器３、５においては、自機が接続される衝突検出型のホームネットワークにおいて発生し得る異常の発生に関連する事象を検出してカウントし、その情報を保持するようにし、当該ホームネットワークシステムにおいて、適正に通信を行うことができなくなった場合に、先に検出した異常の発生に関する事象についての情報をユーザーに通知することにより、当該ホームネットワークにおいてどのような異常が発生しているのかを明確に把握することができるようにしている。

［ネットワークに係る異常の検出と通知について］
図６は、この実施の形態のホームネットワークシステムを構成するＡＶ機器３、５において、ネットワークの状態に起因して発生するユーザーに通知すべき異常と、その異常の検出方法とを説明するための図である。図６に示すように、この実施の形態のホームネットワークシステムのＡＶ機器３、５においては、（１）〜（７）に示す７つの異常を、ネットワークの状態に起因して発生するユーザーに通知すべき異常として検出するようにしている。

（１）、（２）は、ネットワークの接続に問題が生じた場合である。すなわち、（１）の「物理的伝送路が失われた。」という異常は、ＡＶ機器３、５において、ＬＡＮ６への接続ケーブルが脱落するなど、物理的な接続状態が切断された場合に発生する。この（１）の異常の検出は、ネットワーク上を流れるキャリアを検出するようにし、ＬＡＮ６を通じて何らの電気信号も検出できない場合に、「物理的伝送路が失われた。」と判別することができる。

また、（２）の「接続相手がいなくなった。」という異常は、通信の相手先となっているネットワーク機器の電源が落とされたり、相手先となっているネットワーク機器のＬＡＮ６への接続ケーブルが脱落したりするなどした場合に発生する。この（２）の異常の検出は、例えば、一般にｐｉｎｇと呼ばれているプログラムを用いて相手先のネットワーク機器に対して応答を要求するなど、目的とする相手先のネットワーク機器からの応答の有無を調べることにより検出することができる。

また、図６において、（３）〜（７）のそれぞれは、ネットワークへのパケットの送出タイミングや送出量等のいわゆるトラフィック状態に起因して生じるものである。すなわち、（３）の「トラフィックが多すぎ、パケットを送信することができない。」という異常は、オーディオデータやＡＶデータなどの大量のパケットが断続的に送出されているような場合であって、パケットを送出しようとしても、ネットワークに空きが存在しないためになかなかパケットを送出することができない場合に発生する。

この（３）の異常の検出は、パケット送信遅延回数をカウントアップ（累積）するようにし、単位時間当たりの送信遅延回数に基づいて行うことが可能である。また、パケットの送信回数や受信回数をカウントアップするようにし、これらを考慮するようにしてもよい。すなわち、単位時間当たりのパケットの送信回数や受信回数に対する送信遅延回数の割合に基づいて検出することも可能である。

また、（４）の「パケットの衝突が多発している。」という異常は、パケットの送出タイミングが一致してしまっている他のネットワーク機器が存在している場合に発生する。この（４）の異常の検出は、パケットの衝突回数をカウントアップし、単位時間当たりの衝突回数に基づいて行うことが可能である。

また、（５）の「再送信が多すぎ、ネットワークのメルトダウンを起こしている。」という異常は、ネットワーク上に空きが検出できなかったり、パケットの衝突が発生したり、その他の種々の原因によりパケットが正常に相手方に届かなかった場合に発生する。この（５）の異常の検出は、パケットの再送信回数をカウントアップし、単位時間当たりのパケットの再送信回数に基づいて行うことが可能である。

また、（６）の「ＣＲＣエラーが多発している。」という異常は、パケットの衝突が発生したり、ノイズがネットワークに混入したり、その他の種々の原因によりパケットが正常に受信できなかった場合に発生する。この（６）の異常の検出は、ＣＲＣエラー（受信エラー）の発生回数をカウントアップし、単位時間当たりのＣＲＣエラーの発生回数に基づいて行うことが可能である。

また、（７）の「瞬時的にネットワーク負荷が高くなったため、一時的にネットワークが異常となった。」という異常は、ネットワークに接続された機器において、送信するパケットが多くなり、伝送路が空いていなかったり、パケットの衝突が多発したりするなどして、パケットの再送信が多発し、パケットの送信遅延が頻繁に発生した場合に生じる。この（７）の異常の検出は、パケット送信遅延回数、パケット衝突回数、パケット再送信回数、パケット受信数、パケット送信数、受信エラー回数などを考慮することによって、行うことが可能である。なお、この場合の各検出回数は、単位時間当たりのものである。

また、図６に示した（３）〜（６）の異常は、ネットワーク上のトラフィック量が多くなってきた場合には、異なる異常が重複して発生する場合もある。しかし、上述もしたように、（３）〜（６）の異常は、それぞれが独立に発生する場合も考えられるので、この実施の形態のホームネットワークシステムを構成するＡＶ機器３、５においては、そのそれぞれを独立して正確に検出することができるようにしている。

このように、この実施の形態のホームネットワークシステムを構成するＡＶ機器３、５は、図６に示したネットワークの状態に起因して発生し、その発生をユーザーに通知すべき（１）〜（７）の異常のそれぞれの発生を検出するために、そのそれぞれの異常の発生に関連する事象を検出し、必要な場合には検出回数を累積していくようにしている。

そして、所定の時間毎（単位時間毎）に、前回検出した異常の発生に関連する事象の検出回数に対する今回検出した異常の発生に関連する事象の各検出回数の増加量が、予め決められた値以上になった場合に、ネットワークに異常が発生していると判別して、ネットワークの状態をユーザーが認識可能なように通知するようにしている。

［異常の発生に関連する事象の検出について］
次に、図６を用いて説明した（１）〜（７）の異常を検出するための処理と、検出した異常を通知する場合の処理を、図７〜図１１のフローチャートを参照しながら説明する。

まず、（１）物理的伝送路が失われた場合を検出するための処理を図７のフローチャートを用いて説明する。この実施の形態においては、ＬＡＮ６上の信号（キャリア）の有無によって、物理的な伝送路が失われたが否かを検出するようにしている。すなわち、常にキャリアが検出できないときには、ＬＡＮ６への接続ケーブルが脱落するなど、物理的に伝送路が失われたに他ならないためである。

このため、この実施の形態のＡＶ機器３、５においては、電源が投入されると、通信部３２と、制御部３７とが協働し、所定のタイミング毎に図７に示す処理を実行する。すなわち、通信部３２が持つ機能により、例えば一定時間連続して、あるいは、一定時間内に複数回、ＬＡＮ６上の信号の有無を検出するようにし（ステップＳ１０１）、まったく信号が検出できなかった場合に、物理的伝送路が失われたと判断して、キャリア検出エラー（伝送路エラー）が発生したことを通知するようにする（ステップＳ１０２）。

このキャリア検出エラーの通知は、制御部３７において、ＲＯＭやＥＥＰＲＯＭに保持されているメッセージデータが用いられてエラーメッセージが形成され、これが映像信号処理部３３に供給されてエラーメッセージの表示用信号が形成され、これが表示部３４に供給されてエラーメッセージが表示部３４の表示画面に表示されることになる。もちろん、アラーム音（警告音）を音声信号処理部３５、スピーカー３６を通じて放音するようにすることも可能である。

次に、（２）接続相手がいなくなった場合を検出するための処理を図８のフローチャートを参照しながら説明する。この実施の形態においては、目的とする相手先からの応答の有無によって、通信の相手先がいなくなったか否かを検出するようにしている。そして、この実施の形態のＡＶ機器３、５においては、図７に示したキャリア検出の場合と同様に、電源が投入されると、通信部３２と、制御部３７とが協働し、所定のタイミング毎に図８に示す処理を実行する。

すなわち、この実施の形態のＡＶ機器３、５においては、例えば、ｐｉｎｇと呼ばれる返信要求を送出するプログラムなどを用い、目的とする通信の相手先に対して応答を返信するように要求し、応答が返信されてきたか否かを判断することにより、通信の相手先がいなくなったか否かを判断するようにしている（ステップＳ２０１）。ステップＳ２０１の判断処理において、応答が返信されてきたと判断したときには、ステップＳ２０１の処理を繰り返す。

また、ステップＳ２０１の判断処理において、応答が返信されてこないと判断したときには、通信の相手先のネットワーク機器の電源が落とされたり、通信の相手先のネットワーク機器のＬＡＮ６への接続ケーブルが脱落したりするなどして、通信の相手先がいなくなったと判断して、相手先の接続エラーが発生したことを通知するようにする（ステップＳ２０２）。

この相手先の接続エラーの通知は、上述したキャリア検出エラーの通知の場合と同様に、制御部３７において、ＲＯＭやＥＥＰＲＯＭに保持されているメッセージデータが用いられてエラーメッセージが形成され、これが映像信号処理部３３に供給されてエラーメッセージの表示用信号が形成され、これが表示部３４に供給されてエラーメッセージが表示部３４の表示画面に表示されることになる。もちろん、アラーム音（警告音）を音声信号処理部３５、スピーカー３６を通じて放音するようにすることも可能である。

次に、図６に示した（３）〜（７）の異常の検出であるが、これらは上述した（１）、（２）のネットワークの接続異常の場合と異なり、パケットの送信処理時および受信処理時において、図６に示した（３）〜（７）の異常の発生に関連する事象の発生回数をカウントアップするようにしている。この場合の送信処理、受信処理は、制御部３７の制御に応じて、通信部３２において行うようにされている。

まず、パケットの送信処理について、図９を参照しながら説明する。この実施の形態のホームネットワークシステムに接続されるＡＶ機器３、５において、パケットを送信する場合、制御部３７の制御により通信部３２が動作して、図９のパケット送信処理を行うようにする。

通信部３２は、以下に説明するように、パケット送信時用の種々のカウンタを備えており、パケット送信時には、最初に送信カウンタＳのカウント値に１を加算する（ステップＳ３０１）。次に、通信部３２は、自己のキャリア検知機能を用い、ＬＡＮ６上にパケットが伝送されているか否かを判断する（ステップＳ３０２）。

ステップＳ３０２の判断処理において、伝送されているパケットが存在しないと判断したときには、通信部３２はパケットを送信するようにし（ステップＳ３０３）、自己の衝突検知機能を用いて、送信中にパケットの衝突を検出したか否かを判断する（ステップＳ３０４）。

ステップＳ３０４の判断処理において、パケットの衝突を検知しなかったと判断したときには、通信部３２は、送信中にパケットのエラー（送信エラー）を検出したが否かを判断する（ステップＳ３０５）。ステップＳ３０５の判断処理において、送信エラーを検出しなかったと判断したときには、通信部３２は、パケットの送信を正常に終了したと判断し、図９に示す処理を終了して（パケットに対する監視処理は終了して）、次のパケットの送信、または、自機へのパケットの受信の待ち状態となる。

ステップＳ３０２の判断処理において、ＬＡＮ６上に伝送中のパケットが存在すると判断した時には、パケット送信遅延カウンタＳＤのカウント値に１を加算する（ステップＳ３０６）。同様に、ステップＳ３０２の判断処理において、パケットの送信中にパケットの衝突を検出したと判断したときには、パケット送信衝突カウンタＳＣのカウント値に１を加算する（ステップＳ３０７）。また、ステップＳ３０５の判断処理において、送信エラーを検出したと判断したときには、パケット送信エラーカウントＳＥのカウント値に１を加算する。

ステップＳ３０６、ステップＳ３０７、ステップＳ３０８の各カウンタの値のカウントアップ処理の後、通信部３２は、再送信カウンタＡＳのカウント値に１を加算し（ステップＳ３０９）、乱数時間待ちを行って（ステップＳ３１０）、この後にステップＳ３０２からの処理を繰り返すようにする。

このように、パケットの送信時において通信部３２は、パケット送信数、パケット送信遅延回数、パケット衝突回数、送信エラー数、再送信回数のそれぞれを累積するようにしている。これらの累積される各値は、パケットの送信時のネットワークの状態を判断するための有用な情報であり、ネットワークのトラフィックに起因して生じる種々の障害に関連する事象の発生回数を累積するようにしているものである。

次に、パケットの受信処理について、図１０を参照しながら説明する。この実施の形態のホームネットワークシステムに接続されるＡＶ機器３、５において、パケットの受信は、制御部３７の制御により通信部３２が動作して、図１０のパケット受信処理を行うようにする。

通信部３２は、以下に説明するように、パケット受信時用のいくつかのカウンタを備えており、パケット受信時には、最初に受信カウンタＲのカウント値に１を加算する（ステップＳ４０１）。次に、通信部３２は、自機宛てのパケットが送信されてくるのを待って、自機宛てのパケットが送信されて来たときにはこれを受信し（ステップＳ４０２）、受信中にエラーを検出したか否かを判断する（ステップＳ４０３）。

ステップＳ４０３の判断処理において、受信エラーを検出しなかったと判断したときには、通信部３２はステップＳ４０１からの処理を繰り返し、自機宛てのパケットの受信処理を繰り返すようにする。ステップＳ４０３の判断処理において、受信エラーを検出したと判断したときには、受信エラーカウンタＲＥのカウント値に１を加算し（ステップＳ４０４）、この後に、ステップＳ４０１からの処理を繰り返すようにする。

このように、パケット受信の状態検出は常時監視され、パケット受信中にエラーを検出した場合は、受信エラーカウンタＲＥのカウント値に１を加算し、再び受信待機処理に戻るようにしている。なお、このパケット受信時のエラーには、受信パケットのＣＲＣエラー等のデータエラーの他、パケットの衝突検出も含まれる。これらの累積される各値は、パケットの受信時のネットワークの状態を判断するための有用な情報であり、ネットワークのトラフィックに起因して生じる障害に関連する事象の発生回数を累積するようにしているものである。

次に、ネットワークの状態監視処理について、図１１のフローチャートを参照しながら説明する。この実施の形態のホームネットワークシステムに接続されるＡＶ機器３、５においては、電源が投入された後、図９に示した送信処理はパケットの送信時において実行するようにされ、図１０に示した受信処理は常時実行するようにされ、それらの処理において累積されたネットワークの異常に関連する種々の事象の発生回数に基づいて、ネットワークの状態を監視するようにし、ネットワークに異常が発生した場合にはこれを迅速に検知して、ユーザーに通知することができるようにしている。

すなわち、この実施の形態のＡＶ機器３、４においては、電源が投入された後においては、図１１に示す処理も実行される。この図１１に示す処理は、通信部３２と制御部３７とが協働して行うようにされる。まず、制御部３７は、通信部３２の各カウンタの値の提供を受け、これをＲＡＭ３７３あるいはＥＥＰＲＯＭ３７４に保存するようにする（ステップＳ５０１）。

このステップＳ５０１の処理おいて、カウント値が保存されるカウンタは、図１１に示したように、遅延カウンタＳＤのパケット送信遅延回数と、衝突カウンタＳＣのパケット衝突回数と、送信エラーカウンタＳＥの送信エラー回数と、再送信カウンタＡＳの再送信回数と、受信エラーカウンタＲＥの受信エラー回数とが保存するようにされる。

そして、制御部３７は、ステップＳ５０１で保存した各カウント値を表示するための情報、あるいは、当該カウント値に応じたグラフなどを表示するための情報を形成し、これを映像信号処理部３３を通じて表示部３４に供給して、各カウント値に応じた情報を表示部３４の表示画面に一定時間表示する（ステップＳ５０２）。

ステップＳ５０２の処理の後、制御部３７は、ステップＳ５０１で保存するようにした各カウント値を保持したまま、ステップＳ５０１の処理と同様に、通信部３２から各カウント値の最新情報を取得し、この今回の各カウント値と、ステップＳ５０１において保持するようにした前回の各カウント値との差分を算出する（ステップＳ５０３）。

そして、制御部３７は、ステップＳ５０３で算出した各カウント値の差分が、予め決められた規定値を超えたか否かを判断する（ステップＳ５０４）。このステップ５０４の判断処理は、一定時間内に発生した各事象（異常に関連する事象）の回数が規定のスレッショルドを越えた場合、制御部３７は、ネットワークに異常が発生していると判断し、通常のパケット送信処理を一時停止する（ステップＳ５０５）。

その後、例えばイーサネット（登録商標）で規定している最小パケット（５６バイト）の送信を行い（ステップＳ５０６）、正常に送信可能かを判断する（ステップＳ５０７）。その結果、送信が正常に可能であれば、停止中の通常パケットの送信を再開する（ステップＳ５０９）。送信に失敗した場合は、ネットワークの異常を示す表示を行う（ステップＳ５０８）。

ここで、最小パケットでの送信テストを行うのは、混雑しているネットワークの場合の送信可能性はパケットの長さに反比例すると考えられるため、最小パケットの送信さえ失敗する場合は、それ以上の長さのパケットは必ず失敗するネットワークダウンの状態であると判断できるためである。

このように、この実施の形態のホームネットワークシステムに接続されるこの実施の形態のＡＶ機器３、５は、従来、異常であると検出することができなかったネットワークの種々の異常のそれぞれを検出し、これらをユーザーに対して正確に通知することができるようにしている。

［ネットワークに係る異常の通知の具体例］
ここで、この実施の形態のＡＶ機器３、５において行われるネットワークに係る異常についての情報の通知態様について説明する。図１２〜図１４は、ネットワークに係る異常についての情報の通知態様の具体例を説明するための図である。図１２は、図９、図１０を用いて説明したパケットの送信処理時、あるいは、パケットの受信処理時にカウントアップされるネットワークの異常に関連する事象の発生回数に基づいて、各事象の発生の変化を折れ線グラフで示すようにした場合の例を説明するための図である。

図１２の例の場合には、グラフの下側に示したように、（ａ）単位時間当たりのパケット送信数、（ｂ）単位時間当たりのパケット受信数、（ｃ）単位時間当たりのパケット送信遅延回数、（ｄ）単位時間当たりのパケット衝突回数、（ｅ）単位時間当たりの送信エラー回数、（ｆ）単位時間当たりの受信エラー回数、（ｇ）ネットワーク帯域利用率、（ｈ）伝送路状態の８つの情報を一度に表示し、効率よく確認することができるようにしている。

この図１２の例の場合、横軸は時間であるが、縦軸の単位は、（ａ）〜（ｇ）についてはパーセンテージ（百分率）であり、（ｈ）については、オン「１」かオフ「０」かのいずれかとなる。

そして、図１２の伝送路状態を示すグラフは、ＡＶ機器３あるいはＡＶ機器５において、伝送路状態のグラフが示すように、電源投入の２単位時間後（例えば２分後）からにネットワーク（ＬＡＮ６）への接続が開始され、例えば、サーバー装置１からオーディオコンテンツ（オーディオデータ）の供給を受けてストリーミング再生が行うようにされ、電源投入から１２単位時間後にネットワークへの接続を終了した場合を示している。

この場合、パケット送信数のグラフ、および、パケット受信数のグラフからわかるように、パケットの単位時間当たりの送信数、受信数は徐々に増加するように推移している。また、受信エラー回数のグラフが示すように、受信したパケットに例えばＣＲＣエラーが発生しているなどの受信エラーはほぼ発生していないことが分かり、受信エラー回数のグラフが示すように、単位時間当たりの受信エラーは低位に推移していることがわかる。

そして、パケット送信遅延回数のグラフ、パケット衝突回数のグラフが示すように、単位時間当たりのパケット送信遅延回数と単位時間当たりのパケット衝突回数とは、電源投入後の３単位時間経過後から４単位時間経過時点までの間に増加し、その減少して低位に推移している。

また、ネットワーク帯域利用率のグラフが示すように、接続開始当初においては、ネットワークの利用率は５０％と高く、その後１０％台に低下するが、電源投入後から５単位時間経過後においては８０％台と高くなり、その後急激に減少して、低位安定となっている。なお、ネットワーク帯域利用率は、例えば、単位時間当たりのパケットの受信数などに基づいて求めることができるものである。

この図１２に示したグラフからは、接続開始直後においては、他のネットワーク機器もネットワーク（ＬＡＮ６）を通じて通信を行っている状態にあり、ネットワークの利用率が高いために、自機においてもパケットの衝突、パケットの送信遅延が頻繁に発生したが、その後、他のネットワーク機器の通信が終了するなどして、ネットワークの利用率が低下するにしたがって、パケットの衝突、パケットの送信遅延もほぼ発生しない状態に安定したことが分かる。このように、ネットワークのいわゆるトラフィックに起因して発生する異常を、その異常に関連する事象の検出数に応じて、ユーザーに通知することができるようにされる。

このように、過去のネットワーク状態を含め、ネットワークの状態が一定時間表示されるので、不具合の原因を知ることができるようにされ、ユーザーは、通信が正常にできない場合において、ネットワーク機器の故障などと間違うことなく、適切な対応を迅速に取ることができるようにされる。

なお、図１２においては、単位時間当たりの再送信回数のグラフについては示さなかった。再送信は、図９を用いて説明したように、パケットを送信しようとしたときに、ネットワーク上に送信中のパケットが存在するために送信できなかった場合や、パケットの衝突が発生した場合、その他の送信エラーが発生したために、パケットが正常に送信できなかった場合には、いずれの場合においてもパケットの再送信が行われることになる。

このため、パケット送信遅延回数、パケット衝突回数、送信エラー数についての情報を示せば、それらの情報に基づいて、パケットの再送信回数の状態を把握することが可能になる。しかし、パケットの再送信回数も図９に示したようにカウントアップしているので、これおもユーザーに通知することにより、直接的にパケットの再送信の状態をユーザーが認識することができるようにされる。

次に、ネットワークの状態に起因して発生する個々の異常を個別的に通知する場合の例を説明する。以下に説明する例の場合には、発生した異常毎に対処方法をもユーザーに通知するようにした場合の例である。この実施の形態のＡＶ機器３、５においては、図６を用いて上述したように、（１）〜（７）の７つのネットワークの異常について個別的に通知することができるようにしている。図１３、図１４は、ネットワークの異常毎の通知メッセージの一例を示す図である。

ＬＡＮ６上の信号（キャリア）を検出することができず、（１）物理的伝送路が失われたと判断したときには、図７に示した処理のステップＳ１０２において、ＡＶ機器３、５の制御部３７は、ＲＯＭ３７２などに予め用意されている表示用メッセージを用いて、図１３（Ａ）に示すように、ＬＡＮ６へのケーブルの脱落の可能性を通知すると共に、ＬＡＮ６への接続ケーブルの確認を要求するメッセージを表示部３４の表示画面に表示するようにする。

なお、以下に説明する各メッセージの表示も、制御部３７のＲＯＭ３７２などに予め用意されている表示用メッセージが用いられて、これが映像信号処理部３３を通じて表示部３４に供給され、種々のメッセージが表示部３４の表示画面に表示されることになる。

また、相手先からの応答を受信することができないために、（２）相手先がいなくなったと判断したときには、図８に示した処理のステップＳ２０２において、ＡＶ機器３、５の制御部３７は、図１３（Ｂ）に示すように、通信の相手先が見つからないことを通知すると共に、相手先機器の電源やＬＡＮ６への接続ケーブルの確認を要求するメッセージを表示部３４の表示画面に表示するようにする。

また、パケット送信遅延回数やパケットの受信数、送信数が規定値よりも多く、（３）トラフィックが多すぎ、パケットを送信することができないと判断したときには、図１３（Ｃ）に示すように、通信量が多いことを通知すると共に、ＬＡＮ６に接続された他のネットワーク機器の使用を中止したり、時間をずらしてオーディオデータのストリーミング再生処理等の目的とする処理を行うようにしたりすることを促すメッセージを表示ブ４の表示画面に表示するようにする。

また、パケット衝突回数が規定値より多く、（４）パケットの衝突が多発していると判断したときには、図１３（Ｄ）に示すように、パケットの送出タイミングが他のネットワーク機器と重なっていることを通知すると共に、時間をずらして目的とする処理を行うようにすることを促すメッセージを表示部３４の表示画面に表示するようにする。

また、パケットの再送信回数が規定値より多く、（５）再送信が多すぎ、ネットワークのメルトダウンを起こしていると判断したときには、図１４（Ａ）に示すように、パケットの再送信が多すぎ、ネットワークが適正に通信を行うことができない状態にあることを通知すると共に、ＬＡＮ６に接続されたネットワーク機器の内、不要な機器の使用を中止したり、時間をずらして目的とする処理を行うようにしたりすることを促すメッセージを表示部３４の表示画面に表示するようにする。

また、受信したパケットのＣＲＣエラー回数が規定値より多く、（６）ＣＲＣエラーが多発していると判断したときには、図１４（Ｂ）に示すように、受信エラーが多く発生していることを通知すると共に、ＬＡＮ６に空きができるまで、処理を待つことを促すメッセージを表示部３４の表示画面に表示するようにする。

また、カウントアップするようにした各事象の単位時間当たりの発生回数、すなわち、パケット送信数、パケット受信数、パケット送信遅延回数、パケット衝突回数、送信エラー回数、受信エラー回数などの単位時間当たりの増加量が瞬時的に規定値よりも多くなり、（７）瞬時的にネットワークの負荷が大きくなったために、一時的にネットワークが異常になったと判断した場合には、これを通知すると共に、同じ処理を再度行うように促すメッセージを表示部３４の表示画面に表示するようにする。

なお、上述のメッセージの表示において、（３）から（７）の場合のメッセージ表示、すなわち、図１３（Ｃ）、（Ｄ）、図１４（Ａ）、（Ｂ）、（Ｃ）の表示は、図１１に示した処理のステップＳ５０８において、制御部３７が各カウンタの値に基づき、どのような異常が発生しているかを判断して、その異常に応じたメッセージの表示を行うようにしている。

このように、ネットワークの接続やいわゆるトラフィックに起因して発生するネットワーク上の種々の異常を個別に検出し、どのような異常が発生しているのかをユーザーに明確に通知する。そして、上述した例の場合には、発生した異常に応じて、どのような対応を取ればよいかをユーザーに対して具体的に通知することができるようにされる。したがって、ユーザーは、ネットワークに異常が発生した場合にこれを正確に知ることができ、ネットワーク機器の故障などと間違うことなく、適切な対応を迅速に取ることができるようにされる。

換言すれば、従来のＡＶ機器では、上述したようなネットワーク上の状態を知ることができず、ユーザーにとっては単に「ネットワークがおかしい」ということしか分からずに、その原因を知ることができなかった。しかし、この実施の形態のＡＶ機器３、５においては、図７〜図１２を用いて説明したネットワークの状態監視手法を用いることによって、ネットワークの状態を監視し、ユーザーにネットワーク状態を視覚や聴覚に作用する形式で直接的に通知することができ、これに応じて迅速かつ適正な対応をユーザーが取ることができるようにされる。

また、この実施の形態においては、上述の説明からも分かるように、主に通信部３２が検出手段としての機能を実現し、制御部３７が、判別手段、停止制御手段としての機能を実現し、映像信号処理部３３、表示部３４が、表示手段としての機能を実現し、制御部３７と通信部３２とが協働して、テストデータ送出手段、確認手段としての機能を実現するようにしている。

なお、図１１に示した処理のステップＳ５０２の処理においては、図１２に示したネットワークの状態を示す折れ線グラフを表示するようにしてもよいし、図１１の処理のステップＳ５０８において、図１２に示したネットワークの状態を示す折れ線グラフを表示するようにしてもよい。もちろん、図１１に示した処理のステップＳ５０２の処理においては、各カウンタの値をそのまま表示したり、各カウンタの値の単位時間当たりの増加分の値を表示するようにしたりしてもよい。

また、上述の実施の形態においては、図１１に示したように、単位時間当たりの各カウンタの値の少なくとも１つ以上が、予め決められた規定値以上になった場合であって、かつ、最小単位のパケットが送信でできなかった場合に、ネットワークに係る異常が発生したことを通知するものとして説明したが、これに限るものではない。

例えば、単位時間当たりの各カウンタの値の少なくとも１つ以上が、予め決められた規定値以上になった場合に即座にネットワークに係る異常が発生したことを通知するようにしてもよい。また、ＡＶ機器３、４のキー操作部３８２やリモコン３９２を通じて、ユーザーからのネットワークの状態表示の指示があった場合に、図１２に示したような態様で、ネットワークの状態を通知するようにしてもよい。このようにすれば、データの送受が遅いと感じた場合などの適宜のタイミングで、ユーザーはネットワークの状態を正確に把握することが可能となる。

また、図１３、図１４に示したメッセージの具体例は一例であって、これ以外の種々のメッセージを用いることが可能であることは言うまでもない。また、図１３、図１４に示した種々のメッセージは、映像信号処理部３３を通じて表示部３４の表示画面に表示するものとして説明したが、これに限るものではない。ＡＶ機器３、５にＬＣＤなどの表示素子が設けられている場合には、これに上述したようなネットワーク上の異常を通知するメッセージを表示するようにしてももちろんよい。

また、上述した実施の形態においては、ネットワーク上の異常を表示メッセージにより通知するようにしたが、これに限るものではない。例えば、警告用ＬＥＤ（Light Emitting Diode）を設け、ＬＥＤの点灯、消灯、点滅により、ネットワーク上に発生した種々の異常を個別的に通知するようにしてもよいし、表示部３４の表示画面に表示する色やＬＥＤの色などに応じて、ネットワーク上に発生した種々の異常を個別的に通知するようにしてもよい。

また、異なる放音パターンの複数種類の警告音を用いることにより、ネットワーク上に発生した種々の異常を個別的に通知したり、図１３、図１４に示した表示用メッセージを音声メッセージとして音声信号処理部３５、スピーカー３６を通じて放音するようにしたりしてもよい。

また、ボーグラフや円グラフなどのビジュアル的に異なる表現形式を用いて、図１２に示した折れ線グラフの場合と同様の情報内容を、ネットワークの状態を示すものとして表示するようにしてももちろんよい。

また、検出するネットワークの異常の発生に関連する事象も、上述した実施の形態に示しものだけに限るものではない。例えば、相手先機器からの応答のレスポンスなど、ネットワークにかかる種々の事象の有無や発生回数、検出した事象の継続時間やその事象の発生によって行われた処理の実行値や検出値などを検知して通知するようにしてもよい。

なお、上述の実施の形態においては、例えば、ハードディスクレコーダ、デジタルＶＴＲ、デジタルテレビ受像機、オーディオ機器等の衝突検出型のＬＡＮ６への接続機能を有するＡＶ機器３、５にこの発明を適用するものとして説明したが、これに限るものではない。イーサネット（登録商標）に代表される衝突検出型のＬＡＮへの接続機能を備えた種々のネットワーク機器にこの発明を適用することができる。

また、ＬＡＮの方式は、イーサネット（登録商標）などのＣＳＭＡ／ＣＤ型のものに限らず、衝突検出型の種々の方式、すなわち、パケットの送出時のキャリア検出は行わないが、衝突の検出は行うようにする種々の方式を用いるＬＡＮシステムに接続可能な種々のネットワーク機器にこの発明を適用することができる。

この発明の一実施の形態が適用されたＡＶ機器が接続されるホームネットワークシステムを説明するための図である。 図１に示したサーバー装置１、パーソナルコンピュータ２、４の構成例を説明するためのブロック図である。 図１に示したＡＶ機器３、５の構成例を説明するための図である。 衝突検出型のネットワークにおいて、パケットが正常に送信できる場合のタイミング例を説明するための図である。 衝突検出型のネットワークにおいて、パケット衝突が発生する場合のタイミング例を説明するための図である。 ネットワークの状態に起因して発生するユーザーに通知すべき異常と、その異常の検出方法とを説明するための図である。 物理的伝送路が失われた場合を検出するための処理を説明するためのフローチャートである。 接続相手がいなくなった場合を検出するための処理を説明するためのフローチャートである。 パケットの送信処理を説明するためのフローチャートである。 パケットの受信処理を説明するためのフローチャートである。 ネットワークの状態監視処理を説明するためのフローチャートである。 パケットの送信処理時、あるいは、パケットの受信処理時にカウントアップされるネットワークの異常に関連する事象の発生回数に基づいて、各事象の発生の変化を折れ線グラフで示すようにした場合の例を説明するための図である。 ネットワークの異常毎の通知メッセージの一例を示す図である。 ネットワークの異常毎の通知メッセージの一例を示す図である。

符号の説明

１…サーバー装置、２…パーソナルコンピュータ、３、５…ＡＶ機器、４…ノート型パーソナルコンピュータ、３１…接続端、３２…通信部、３３…映像信号処理部、３４…表示部、３５…音声信号処理部、３６…スピーカー、３７…制御部、３８１…キーインターフェース（キーＩ／Ｆ）、３８２…キー操作部、３９１…リモコン信号受光部、３７１…ＣＰＵ３７１、３７２…ＲＯＭ３７２、３７３…ＲＡＭ、３７４…ＥＥＰＲＯＭ、３７５…ＣＰＵバス

Claims (8)

1. 衝突検出型ネットワークに接続されるネットワーク機器であって、
   前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象を検出するようにする検出手段と、
   前記検出手段の検出結果に基づいて、前記ネットワークを通じて適正に通信を行うことができるか否かを判別する判別手段と、
   前記判別手段により、前記ネットワークを通じて適正に通信を行うことができないと判別された場合に、前記検出手段によって、どのような異常についての発生に関連する事象が検出されたかを操作者が判別可能な態様で通知するようにする通知手段と
   を備えることを特徴とするネットワーク機器。
2. 請求項１に記載のネットワーク機器であって、
   前記判別手段により、前記ネットワークを通じて適正に通信を行うことができないと判別された場合に、データの送出を停止するようにする停止制御手段と、
   前記停止制御手段によりデータの送出が停止された後に、最小単位のパケットのテストデータを形成し、これを前記ネットワークに送出するテストデータ送出手段と、
   前記テストデータ送出手段を通じて前記テストデータが正常に送出できたか否かを確認する確認手段と
   を備え、
   前記通知手段は、前記確認手段により前記テストデータが正常に送出することができなかったことが確認された場合に、通知を行うようにすることを特徴とするネットワーク機器。
3. 請求項１または請求項２に記載のネットワーク機器であって、
   前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象は、
   伝送路の喪失、通信の相手先の喪失、送信遅延の発生、送出データの衝突の発生、再送信処理の発生、データエラーの発生の少なくとも１つ以上を含むことを特徴とするネットワーク機器。
4. 請求項１、請求項２または請求項３に記載のネットワーク機器であって、
   前記通知手段は、適正に通信を行うことができない場合の、あるいは、前記テストデータが送出できない場合の対処方法をも通知するようにしたことを特徴とするネットワーク機器。
5. 衝突検出型ネットワークに接続されるネットワーク機器において、前記ネットワークの状態を検出して通知するようにする方法であって、
   前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象を検出するようにする検出ステップと、
   前記検出ステップにおいての検出結果に基づいて、前記ネットワークを通じて適正に通信を行うことができるか否かを判別する判別ステップと、
   前記判別ステップにおいて、前記ネットワークを通じて適正に通信を行うことができないと判別した場合に、前記検出ステップにおいて、どのような異常に係る発生に関連する事象を検出したかを操作者が判別可能な態様で通知する通知ステップと
   を有することを特徴とするネットワーク状態通知方法。
6. 請求項５に記載のネットワーク状態通知方法であって、
   前記判別ステップにおいて、前記ネットワークを通じて適正に通信を行うことができないと判別した場合に、データの送出を停止するようにする停止制御ステップと、
   前記停止制御ステップにおいて、データの送出を停止した後に、最小単位のパケットのテストデータを形成し、これを前記ネットワークに送出するテストデータ送出ステップと、
   前記テストデータ送出ステップにおいて前記テストデータを正常に送出することができたか否かを確認する確認ステップと
   を有し、
   前記通知ステップにおいては、前記確認ステップにおいて前記テストデータが正常に送出することができなかったことを確認した場合に、通知を行うようにすることを特徴とするネットワーク状態通知方法。
7. 請求項５または請求項６に記載のネットワーク状態通知方法であって、
   前記ネットワークに係る複数種類の異常のそれぞれの発生に関連する事象は、
   伝送路の喪失、通信の相手先の喪失、送信遅延の発生、送出データの衝突の発生、再送信処理の発生、データエラーの発生の少なくとも１つ以上を含むことを特徴とするネットワーク状態通知方法。
8. 請求項５、請求項６または請求項７に記載のネットワーク状態通知方法であって、
   前記通知ステップにおいては、適正に通信を行うことができない場合の、あるいは、前記テストデータが送出できない場合の対処方法をも通知するようにしたことを特徴とするネットワーク状態通知方法。

Images