JP6358650B2 - 中継装置、中継方法及びプログラム - Google Patents

Description

本発明は中継装置、中継方法及びプログラムに関し、特に通信経路上の不具合を検出する中継装置、中継方法及びプログラムに関する。

近年、通信機能を有する情報家電、無線ＬＡＮ（Local Area Network）機能を有する携帯電話端末等が普及することに伴い、自宅内等において、情報家電及び携帯電話端末等を集約して接続するためにホームゲートウェイが用いられている。ホームゲートウェイは、光回線等を介してＩＳＰ（Internet Service Provider）ネットワークと接続している。ＩＳＰネットワークは、ホームゲートウェイとインターネットとの間の通信を中継する。

ホームゲートウェイ配下に接続される通信装置は、ホームゲートウェイを介してインターネットに接続する。この時、通信装置と、インターネット上のサーバ装置等との間の通信経路において不具合が発生した場合、通信装置は、インターネット上のサーバ装置へ接続することができなくなる。このような場合に、通信装置を操作しているユーザが、不具合を取り除くために、容易に不具合の発生を検出する方法が望まれている。

特許文献１には、ホームゲートウェイを通過したパケット数と、ホームゲートウェイに接続されているエンド端末において受信したパケット数とを用いて、不具合を検出する構成が開示されている。具体的には、不具合箇所検出装置が、ホームゲートウェイから、ホームゲートウェイを通過したパケット数に関する情報を取得し、さらに、エンド端末から、エンド端末において受信したパケット数に関する情報を取得する。不具合箇所検出装置は、取得した情報を比較して、パケット数が一致しているか否かに応じて、不具合があったか否かを検出する。不具合検出装置において、比較したパケット数が異なる場合、不具合が発生していると判定される。

特開２０１０−２２００４８号公報

しかし、特許文献１に開示されている不具合検出方法を用いる場合、ホームゲートウェイ及びエンド端末の両方が、不具合検出装置に対してカウントしたパケット数に関する情報を通知する必要がある。つまり、ホームゲートウェイ及びエンド端末の両方が、不具合検出装置に対してカウントしたパケット数に関する情報を通知する機能に対応する必要がある。ホームゲートウェイには複数のエンド端末が接続されていることが多く、エンド端末に新たな機能を盛り込む場合、複数のエンド端末のソフトウェア等をバージョンアップさせるための操作負担が生じるという問題がある。

本発明の目的は、上述した課題を解決するために、ネットワーク上に発生した不具合を検出する際に、ホームゲートウェイのみにおいて不具合を検出することができる中継装置、中継方法及びプログラムを提供することにある。

本発明の第１の態様にかかる中継装置は、ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号を、ＷＡＮ回線を介して接続されるサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定する判定部と、前記判定部において、前記応答信号が送信されてきていないと判定された場合に、自装置と前記サーバとの間に設けられた少なくとも１つの装置にアクセスし、アクセス結果に応じて、当該装置に不具合が生じているかどうかを判定する不具合要因検査処理部と、を備えるものである。

本発明の第２の態様にかかる中継方法は、ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号を、ＷＡＮ回線を介して接続されるサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定し、前記応答信号が送信されてきていないと判定された場合に、自装置と前記サーバとの間に設けられた少なくとも１つの装置にアクセスし、アクセス結果に応じて、当該装置に不具合が生じているかどうかを判定するものである。

本発明の第３の態様にかかるプログラムは、ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号、ＷＡＮ回線を介して接続されるサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定し、前記応答信号が送信されてきていないと判定された場合に、自装置と前記サーバとの間に設けられた少なくとも１つの装置にアクセスし、アクセス結果に応じて、当該装置に不具合が生じているかどうかを判定することをコンピュータに実行させるものである。

本発明により、ネットワーク上に発生した不具合を検出する際に、ホームゲートウェイのみにおいて不具合を検出することができる中継装置、中継方法及びプログラムを提供することができる。

実施の形態１にかかる通信システムの構成図である。 実施の形態２にかかる通信システムの構成図である。 実施の形態２にかかるホームゲートウェイの構成図である。 実施の形態２にかかるパケットフロー監視部における処理動作の流れを示す図である。 実施の形態２にかかるパケットフロー監視部における処理動作の流れを示す図である。 実施の形態２にかかる不具合要因検査処理部が実行する、不具合要因検査処理の流れを示す図である。 実施の形態２にかかる検査結果処理部における検査結果の通知先を選択する処理の流れを示す図である。 実施の形態３にかかるパケットフロー監視部における処理動作の流れを示す図である。 実施の形態４にかかるＨＴＴＰリクエスト代理応答処理の流れを示す図である。 実施の形態４にかかるＨＴＴＰリクエスト代理応答処理の流れを示す図である。

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１の通信システムは、中継装置１０、通信装置２０及びサーバ装置３０を有している。中継装置１０は、通信装置２０とサーバ装置３０との間の通信を中継する装置である。例えば、通信装置２０は、中継装置１０と無線ＬＡＮ通信方式に従って通信を行う。中継装置１０は、例えば、宅内において複数の通信装置と接続するホームゲートウェイ、ルータもしくはスイッチ装置等であってもよい。通信装置２０は、例えば、スマートフォン端末等を含む携帯電話端末、情報家電装置等であってもよい。

さらに、サーバ装置３０は、中継装置１０と光通信回線等を介して通信を行ってもよい。サーバ装置３０は、例えば、様々なＩＳＰネットワーク等を介して接続されるインターネット上に配置される装置であってもよい。

次に、中継装置１０の構成例について説明する。中継装置１０は、例えば、メモリに格納されているプログラムをＣＰＵが実行することによって動作するコンピュータ装置であってもよい。中継装置１０は、ＬＡＮ（Local Area Network）インタフェース部１１、ＷＡＮ（Wide Area Network）インタフェース部１２、判定部１３及び不具合要因検査処理部１４を有している。

ＬＡＮインタフェース部１１は、ＬＡＮ回線を介して通信装置２０と通信を行う。ＬＡＮ回線は、例えば無線ＬＡＮ通信方式が用いられてもよく、近距離無線通信方式が用いられてもよい。近距離無線通信方式は、例えば、Bluetooth（登録商標）もしくは赤外線通信等であってもよい。また、ＬＡＮ回線は、有線ケーブルを用いた有線ＬＡＮが用いられてもよい。本図においては、中継装置１０は、１台の通信装置２０と通信している様子を示しているが、複数台の通信装置２０と通信してもよい。

ＷＡＮインタフェース部１２は、ＷＡＮ回線を介してサーバ装置３０と通信を行う。ＷＡＮ回線は、例えば、光通信回線が用いられてもよく、もしくは、ＩＳＰ（Internet Service Provider）ネットワークと接続するための他の通信回線が用いられてもよい。ＷＡＮインタフェース部１２は、サーバ装置３０と通信する際に、複数の中継装置もしくはネットワークを介してサーバ装置３０と通信してもよい。

通信装置２０は、サーバ装置３０と通信する際に、中継装置１０を介してリクエスト信号をサーバ装置３０へ送信する。リクエスト信号は、リクエストメッセージと称されてもよい。サーバ装置３０は、リクエスト信号に対する応答信号を、中継装置１０を介して通信装置２０へ送信する。中継装置１０は、通信装置２０から送信されたリクエスト信号を受信すると、受信したリクエスト信号をサーバ装置３０へ送信する。さらに、中継装置１０は、サーバ装置３０から送信された応答信号を受信すると、受信した応答信号を通信装置２０へ送信する。

判定部１３は、通信装置２０から送信されたリクエスト信号を、サーバ装置３０へ転送した後に、サーバ装置３０からリクエスト信号に対する応答信号が送信されてきたか否かを判定する。例えば、判定部１３は、予め定められた期間の間、応答信号を監視し、応答信号が送信されてきたか否かを判定してもよい。判定部１３は、予め定められた期間の間に、応答信号が送信されてこなかった場合、応答信号が送信されてきていない、と判定してもよい。

不具合要因検査処理部１４は、判定部１３において、送信したリクエスト信号に対する応答信号が送信されてきていないと判定された場合に、不具合箇所を特定する処理を実行する。不具合箇所を特定する処理は、例えば、自装置と前記サーバとの間に設けられた少なくとも１つの装置にアクセスし、アクセス結果に応じて、当該装置に不具合が生じているかどうかを判定することである。不具合要因検査処理部１４は、例えば、中継装置１０に不具合が発生しているのか、もしくは、ＷＡＮ回線に不具合が発生しているのかを特定してもよい。

以上説明したように、図１にかかる中継装置１０は、サーバ装置３０へ転送したリクエスト信号に対する応答信号を受信したか否かに応じて、通信システムに不具合が発生しているか否かを判定することができる。さらに、中継装置１０は、不具合が発生していると判定すると、不具合箇所を特定する処理を実行することができる。

具体的には、中継装置１０は、通信装置２０とサーバ装置３０との間の通信ネットワーク上の装置等において発生した不具合を検出することができる。この時、中継装置１０は、通信装置２０とサーバ装置３０との間において通常送受信される応答信号の有無を用いて不具合を検出する。そのため、通信装置２０とサーバ装置３０との間の通信ネットワーク上の装置における不具合を検出するために、通信装置２０及びサーバ装置３０の両方へ機能を追加する必要はない。言い換えると、中継装置１０のみが、応答信号の有無を用いて不具合を検出する判定部１３を有することによって、通信装置２０とサーバ装置３０との間の通信ネットワーク上の装置における不具合を検出することができる。

（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ローカルネットワーク、ＩＳＰネットワーク及びインターネットを有している。ローカルネットワークは、例えば、自宅内における複数の通信装置を有する小規模なネットワークである。本図においては、ホームゲートウェイ４０が、通信装置２０と通信装置２２との間の通信、さらに、通信装置２０とＩＳＰネットワークとの間の通信、通信装置２２とＩＳＰネットワークとの間の通信を中継する装置であることを示している。

ホームゲートウェイ４０は、図１における中継装置１０に相当する。ホームゲートウェイ４０と通信装置２０との間の通信、さらに、ホームゲートウェイ４０と通信装置２２との間の通信には、例えば無線ＬＡＮ通信方式が用いられてもよい。ホームゲートウェイ４０は、ＩＳＰネットワークと通信を行う際に、光通信回線を介して通信を行ってもよい。本図においては、ホームゲートウェイ４０が、２台の通信装置と通信を行う例を示しているが、３台以上の通信装置と通信を行ってもよい。

ＩＳＰネットワークは、ローカルネットワーク内の通信装置と、インターネットとの間の通信を中継するネットワークである。言い換えると、ＩＳＰネットワークは、ローカルネットワーク内の通信装置に対して、インターネットへの接続サービスを提供するネットワークである。インターネットは、ＩＰ（インターネットプロトコル）を利用して相互に接続するネットワークの総称である。そのため、ＩＳＰネットワークは、インターネットの一部を構成するネットワークとして扱われてもよい。本図においては、ＩＳＰネットワークと、インターネットとは異なるネットワークとして説明する。

ＩＳＰネットワークは、回線終端装置５０、サポート端末６０、上位ルータ７０及びＤＮＳサーバ８０を有している。回線終端装置５０は、ホームゲートウェイ４０と接続する装置である。回線終端装置５０は、例えば、ホームゲートウェイ４０と光通信回線を介して接続してもよい。ＩＳＰネットワーク内においては、例えば、回線終端装置５０と上位ルータ７０とが接続しており、サポート端末６０は、回線終端装置５０と接続し、ＤＮＳサーバ８０は、上位ルータ７０と接続してもよい。また、ＩＳＰネットワーク内は、本図に示す接続構成以外の構成であってもよい。

サポート端末６０は、ＩＳＰネットワークを監視もしくは管理する端末である。ＩＳＰネットワーク内において、通信障害等の不具合が発生した場合、管理者等がサポート端末６０を用いて通信障害の復旧等を行ってもよい。

上位ルータ７０は、インターネットと通信するために用いられるルータ装置である。ＩＳＰネットワークは、ある特定の事業者によって定められた管理ポリシーに従って管理されるネットワークである。上位ルータ７０は、管理ポリシーの異なるネットワーク、具体的にはインターネットと接続する際に用いられるルータである。

ＤＮＳサーバ８０は、例えば、通信装置２０が通信先として指定したサーバ装置３０に関する名前解決を行う装置である。具体的には、ＤＮＳサーバ８０は、通信装置２０からサーバ装置３０のドメイン名を通知された場合、通信装置２０に対してサーバ装置３０のＩＰアドレスを通知する。

サーバ装置３０は、インターネット上に配置されている装置である。つまり、通信装置２０は、ローカルネットワーク、ＩＳＰネットワーク及びインターネットを介してサーバ装置３０と通信する。

続いて、図３を用いてホームゲートウェイ４０の構成例について説明する。ホームゲートウェイ４０は、ＬＡＮインタフェース部４１、ＷＡＮインタフェース部４２、パケットフロー監視部４３、不具合要因検査処理部４４及び検査結果処理部４５を有している。

ＬＡＮインタフェース部４１及びＷＡＮインタフェース部４２は、図１のＬＡＮインタフェース部１１及びＷＡＮインタフェース部１２と同様であるため、詳細な説明を省略する。

パケットフロー監視部４３は、図１の判定部１３に相当する。パケットフロー監視部４３は、ＬＡＮインタフェース部４１から出力されたリクエストメッセージをＷＡＮインタフェース部４２へ出力する。リクエストメッセージは、通信装置２０もしくは通信装置２２から送信されたメッセージであり、サーバ装置３０を宛先としている。リクエストメッセージは、ＬＡＮインタフェース部４１、パケットフロー監視部４３及びＷＡＮインタフェース部４２を介してサーバ装置３０へ送信される。

パケットフロー監視部４３は、リクエストメッセージをＷＡＮインタフェース部４２へ出力すると、リクエストメッセージに対する応答メッセージが、ＷＡＮインタフェース部４２から出力されるか否かを監視する。応答メッセージは、リクエストメッセージを受信したサーバ装置３０が、通信装置２０もしくは通信装置２２へ送信するメッセージである。

例えば、パケットフロー監視部４３は、リクエストメッセージを受け取った時もしくはリクエストメッセージをＷＡＮインタフェース部４２へ出力した時から監視タイマーを起動し、所定の時間経過後に、監視タイマーを停止してもよい。つまり、パケットフロー監視部４３は、監視タイマーがタイムアウトするまでに、応答メッセージを受け取ったか否かを判定してもよい。また、パケットフロー監視部４３は、監視タイマーが起動中に応答メッセージを受け取った場合、監視タイマーを停止してもよい。

ここで、図４を用いて、ホームゲートウェイ４０のパケットフロー監視部４３における処理動作の流れについて説明する。はじめに、ホームゲートウェイ４０は、通信装置２０からリクエストメッセージを受信する（Ｓ１１）。次に、パケットフロー監視部４３は、監視タイマーをスタートする（Ｓ１２）。監視タイマーは、予め定められた時間の間起動している。次に、ホームゲートウェイ４０は、ＩＳＰネットワークへリクエストメッセージを転送する（Ｓ１３）。ここで、パケットフロー監視部４３は、リクエストメッセージをＩＳＰネットワークへ転送してから監視タイマーをスタートさせてもよい。つまり、ステップＳ１２及びＳ１３の処理の順番が入れ替わってもよい。

次に、監視タイマーは、予め定められた時間を経過するとタイムアウトし、停止する（Ｓ１４）。本図においては、ホームゲートウェイ４０が、監視タイマーの起動中に、応答メッセージを受け取らなかった例について説明している。次に、図５を用いて、ホームゲートウェイ４０が、監視タイマーの起動中に、応答メッセージを受け取った場合の例について説明する。

図５のステップＳ２１〜Ｓ２３は、図４のステップＳ１１〜Ｓ１３と同様であるため詳細な説明を省略する。ホームゲートウェイ４０は、ステップＳ２３においてリクエストメッセージをＩＳＰネットワークへ送信した後に、ＩＳＰネットワークを介してサーバ装置３０から応答メッセージを受信する（Ｓ２４）。

次に、パケットフロー監視部４３は、ステップＳ２２において起動した監視タイマーを停止する（Ｓ２５）。次に、ホームゲートウェイ４０は、受信した応答メッセージを通信装置２０へ送信する（Ｓ２６）。

図４のように、パケットフロー監視部４３が、リクエストメッセージに対する応答メッセージを受け取らなかった場合、通信装置２０とサーバ装置３０との間の通信システムにおいて不具合が発生した可能性がある。また、図５のように、パケットフロー監視部４３が、リクエストメッセージに対する応答メッセージを受け取った場合、通信装置２０とサーバ装置３０との間の通信システムは正常であると判定される。

図３に戻り、パケットフロー監視部４３は、監視タイマーが起動中に応答メッセージを受け取らなかった場合、不具合要因検査処理部４４へ、不具合が発生している可能性があることを通知するメッセージ（以下、不具合通知メッセージと称する）を出力する。不具合要因検査処理部４４は、不具合通知メッセージを受け取ると、不具合要因検査処理を実行する。ここで、図６を用いて、不具合要因検査処理部４４が実行する、不具合要因検査処理の流れについて説明する。

はじめに、不具合要因検査処理部４４は、上位ルータ７０と通信することができるか否かを判定する（Ｓ３１）。例えば、不具合要因検査処理部４４は、ＷＡＮインタフェース部４２を介して、上位ルータ７０へリクエストパケットを送信する。不具合要因検査処理部４４は、リクエストパケットに対する応答パケットを受信することによって、上位ルータ７０と通信することができると判定する。リクエストパケットは、例えば、ｐｉｎｇによるＩＣＭＰパケットであってもよいが、上位ルータ７０との間において、予め定められているポート番号を使用して、ＴＣＰもしくはＵＤＰによる通信を行ってもよい。

不具合要因検査処理部４４は、ステップＳ３１において、上位ルータ７０と通信することができると判定した場合、ＤＮＳサーバ８０と通信することができるか否かを判定する（Ｓ３２）。ＤＮＳサーバ８０と通信することができるか否かに関する判定方法は、上位ルータ７０と通信することができるか否かに関する判定方法と同様である。

不具合要因検査処理部４４は、ＤＮＳサーバ８０と通信することができると判定した場合、通信装置２０が通信先として指定したサーバ（以下、目的サーバと称する）と、通信することができるか否かを判定する（Ｓ３３）。ここでは、目的サーバは、サーバ装置３０とする。目的サーバと通信することができるか否かに関する判定方法は、上位ルータ７０と通信することができるか否かに関する判定方法と同様である。

不具合要因検査処理部４４は、目的サーバ、つまり、サーバ装置３０と通信することができると判定した場合、通信装置２０とサーバ装置３０との間には、不具合は発生していないと判定する（Ｓ３４）。

ステップＳ３１において、不具合要因検査処理部４４は、上位ルータ７０と通信することができないと判定した場合、ホームゲートウェイ４０の設定が正しいか否かを判定する（Ｓ３８）。不具合要因検査処理部４４は、例えば、ＷＡＮインタフェース部４２のリンクが正常に立ち上がっているか、ＷＡＮインタフェース部４２を介したＰＰＰ接続において認証エラーが発生していないか等を確認することによって、ホームゲートウェイ４０の設定が正しいか否かを判定する。

不具合要因検査処理部４４は、ＷＡＮインタフェース部４２のリンクが正常に立ち上がっていない、もしくは、ＰＰＰ接続において認証エラーが発生している等によって、ホームゲートウェイ４０の設定が正しくないと判定した場合、ホームゲートウェイ４０に不具合が発生していると判定する（Ｓ４０）。

不具合要因検査処理部４４は、ステップＳ３８においてホームゲートウェイ４０の設定が正しいと判定した場合、もしくは、ステップＳ３２において、ＤＮＳサーバと通信することができないと判定した場合、ＩＳＰネットワークに不具合が発生していると判定する（Ｓ３９）。

不具合要因検査処理部４４は、ステップＳ３３において目的サーバと通信することができないと判定した場合、目的サーバとは異なる他のサーバと通信することができるか否かを判定する。他のサーバと通信することができるか否かに関する判定方法は、上位ルータ７０と通信することができるか否かに関する判定方法と同様である。目的サーバとは異なる他のサーバとは、インターネット上のサーバであり、例えば、時刻同期を行うＮＴＰサーバ等であってもよい。

不具合要因検査処理部４４は、他のサーバと通信することができないと判定した場合、インターネット上において、何らかの不具合が発生していると判定する（Ｓ３７）。不具合要因検査処理部４４は、他のサーバと通信することができると判定した場合、目的サーバであるサーバ装置３０において不具合が発生していると判定する（Ｓ３６）。

図３に戻り、不具合要因検査処理部４４は、不具合要因検査処理の結果を検査結果処理部４５へ出力する。検査結果処理部４５は、不具合要因検査処理の結果を受け取ると、検査結果の通知先を選択する処理を行う。

図７を用いて、検査結果処理部４５における検査結果の通知先を選択する処理の流れについて説明する。はじめに、検査結果処理部４５は、受け取った検査結果において、ホームゲートウェイ４０に不具合があるか否かを判定する（Ｓ５１）。検査結果処理部４５は、ホームゲートウェイ４０に不具合があると判定した場合、ホームゲートウェイ４０の管理者が保持する端末（以下、管理者端末と称する）へ、ホームゲートウェイ４０に不具合があることを示すメッセージを送信する（Ｓ５２）。ホームゲートウェイ４０の管理者が保持する端末は、例えば、通信装置２０もしくは通信装置２２であってもよく、予め登録されている他の通信装置であってもよい。

例えば、ホームゲートウェイ４０は、Ｗｅｂサーバ機能を有し、Ｗｅｂブラウザを介してクライアント端末からアクセスされた際に、ホームゲートウェイ４０における正しい設定内容及び上位ルータ７０への接続方法等をクライアント端末に表示させてもよい。この場合、ステップＳ５２において、ホームゲートウェイ４０に不具合があることを通知された管理者は、管理者端末のＷｅｂブラウザを介して、ホームゲートウェイ４０にアクセスしてもよい。さらに、ホームゲートウェイ４０は、Ｗｅｂブラウザに表示される、ホームゲートウェイ４０における正しい設定内容に従って、ホームゲートウェイ４０の設定を変更する。

検査結果処理部４５は、管理者端末によって、ホームゲートウェイ４０の設定内容が修正された場合に、図６の不具合要因検査処理を再度実施してもよい。

検査結果処理部４５は、ステップＳ５１において、ホームゲートウェイ４０以外に不具合があると判定した場合、ＩＳＰネットワークを管理するサポート端末６０へ、不具合を通知するメッセージを送信する（Ｓ５３）。検査結果処理部４５は、サポート端末６０へ、例えば、Ｅメールを用いて不具合を通知するメッセージを送信してもよく、その他の手段によってメッセージを送信してもよい。また、本図においては、ホームゲートウェイ４０以外に発生した不具合をすべてＩＳＰネットワークを管理するサポート端末６０へ送信する例について説明しているが、インターネットの不具合に対応するサポート端末、サーバ装置３０の不具合に対応するサポート端末等がある場合には、不具合要因に応じてぞれぞれのサポート端末へメッセージを送信してもよい。

以上説明したように、本発明の実施の形態２にかかるホームゲートウェイ４０を介して通信されるリクエストメッセージ及び応答メッセージを用いることによって、通信装置２０とサーバ装置３０との間に発生した不具合を検出することができる。ホームゲートウェイ４０において不具合を検出する際に、通信装置２０及びサーバ装置３０は、不具合を検出するために新たな機能を追加する必要はなく、ホームゲートウェイ４０のみに、パケットフローを監視する機能を追加することによって、通信装置２０とサーバ装置３０との間の不具合を検出することができる。

（実施の形態３）
続いて、図８を用いて本発明の実施の形態３にかかるホームゲートウェイ４０のパケットフロー監視部４３における処理動作の流れについて説明する。本図においては、通信装置２０が、調査目的等を理由として、応答メッセージを想定しないリクエストメッセージを送信する場合について説明する。この場合、通信装置２０は、同じリクエストメッセージを複数回送信する。具体的には、応答メッセージを想定しないリクエストメッセージは、ポートスキャンによるＴＣＰ８０パケットであってもよい。

ステップＳ６１〜Ｓ６３は、図４のステップＳ１１〜Ｓ１３と同様であるため、詳細な説明を省略する。通信装置２０は、ステップＳ６１においてリクエストメッセージを送信した後に、再送リクエストメッセージを送信する（Ｓ６４）。次に、ホームゲートウェイ４０は、通信装置２０から送信された再送リクエストメッセージをＩＳＰネットワークへ送信する。この時、ホームゲートウェイ４０は、再送リクエストメッセージが送信されてきた回数を管理するリトライカウンタを有し、リトライカウンタの値を増加させる（Ｓ６６）。例えば、ステップＳ６６においては、ホームゲートウェイ４０は、リトライカウンタの値を１に設定する。

通信装置２０は、ステップＳ６７及びＳ７０においても、ステップＳ６４と同様に再送リクエストメッセージを送信し、ホームゲートウェイ４０も、ステップＳ６５と同様に、ステップＳ６８及びＳ７１において、再送リクエストメッセージをＩＳＰネットワークへ送信する。また、ホームゲートウェイ４０は、ステップＳ６８において、再送リクエストメッセージを送信した後に、リトライカウンタの値を２に更新する（Ｓ６９）。さらに、ホームゲートウェイ４０は、ステップＳ７１において、再送リクエストメッセージを送信した後に、リトライカウンタの値を３に更新する（Ｓ７２）。

次に、ホームゲートウェイ４０における監視タイマーは、予め定められた時間を経過するとタイムアウトし、停止する（Ｓ７３）。次に、ホームゲートウェイ４０は、リトライカウンタの値が、予め定められている値を超えているか否かを判定する（Ｓ７４）。ホームゲートウェイ４０は、リトライカウンタの値が閾値を超えている場合、図６において説明した不具合要因検査処理を実行する。ホームゲートウェイ４０は、リトライカウンタの値が閾値を超えていない場合、不具合要因検査処理を行わない。

例えば、リトライカウンタの閾値が２と設定されている場合、ステップＳ７２において、リトライカウンタの値は３となっているため、ホームゲートウェイ４０は、不具合要因検査処理を実行する。リトライカウンタにおける閾値は、変更可能とする。

以上説明したように、図８におけるホームゲートウェイ４０のパケットフロー監視部４３における処理動作を行うことによって、応答メッセージが送信されてくる予定のない、すべてのリクエストメッセージ対して、不具合要因検査処理を行う必要がなくなり、不要な検査処理の実行を減少させることができる。

（実施の形態４）
続いて、図９を用いて、本発明の実施の形態４にかかるＨＴＴＰリクエスト代理応答処理の流れについて説明する。図７にて説明した例においては、ホームゲートウェイ４０の不具合を通知された管理者は、管理者端末を介してホームゲートウェイ４０にアクセスする。本図においては、管理者端末が、ホームゲートウェイ４０にアクセスせずに、インターネット上のサーバ等へアクセスする場合における動作を説明する。図７の説明においては、管理者端末がＷｅｂブラウザを介してホームゲートウェイ４０にアクセスすることによって、管理者端末においてホームゲートウェイ４０の正しい設定内容等を表示することができる。しかし、管理者端末が、ホームゲートウェイ４０へアクセスせずに、インターネット上のサーバ等へアクセスする場合、ホームゲートウェイ４０のＷｅｂサーバへアクセスすることはない。つまり、管理者端末が、ホームゲートウェイ４０を宛先として設定せず、インターネット上のサーバを宛先に設定する場合、管理者端末が、Ｗｅｂブラウザに、ホームゲートウェイ４０の正しい設定内容を表示することができない。本図においては、管理者端末が、ホームゲートウェイ４０へアクセスしない場合においても、ホームゲートウェイ４０が、管理者端末に対して、ホームゲートウェイ４０の正しい設定内容等を表示させる手順について説明する。

はじめに、通信装置２０は、インターネット上のサーバへアクセスするために、ＤＮＳサーバ８０を用いた名前解決を行う。そのため、通信装置２０は、DNS queryメッセージをホームゲートウェイ４０へ送信する（Ｓ８１）。例えば、通信装置２０は、example.co.jpとのドメイン名の名前解決を要求する。

次に、ホームゲートウェイ４０は、通信装置２０から送信されたDNS queryメッセージをＤＮＳサーバ８０へ転送する（Ｓ８２）。次に、ＤＮＳサーバ８０は、DNS replyメッセージをホームゲートウェイ４０へ送信する（Ｓ８３）。例えば、ＤＮＳサーバ８０は、DNS replyメッセージにおいて、example.co.jpに対応するＩＰアドレスとして、50.0.0.5を設定する。次に、ホームゲートウェイ４０は、代理ＨＴＴＰ応答を設定する（Ｓ８４）。代理ＨＴＴＰ応答は、50.0.0.5を宛先とするパケットを送信してきた通信装置２０に対して、ホームゲートウェイ４０のＷｅｂサーバ情報を表示させることである。ホームゲートウェイ４０は、代理ＨＴＴＰ応答を設定する代理応答部をさらに設けていてもよい。

次に、ホームゲートウェイ４０は、通信装置２０へDNS replyメッセージを転送する（Ｓ８５）。次に、通信装置２０は、宛先アドレスに50.0.0.5を設定して、TCP SYNメッセージを送信する（Ｓ８６）。次に、ホームゲートウェイ４０は、50.0.0.5宛てのパケットに対して、インターネット上のサーバの代わりに、TCP SYN, ACKメッセージを送信する（Ｓ８７）。次に、通信装置２０は、宛先アドレスに50.0.0.5を設定して、TCP ACKメッセージを送信する（Ｓ８８）。

次に、通信装置２０は、宛先アドレスに50.0.0.5を設定して、HTTP GETメッセージを送信する（Ｓ８９）。次に、ホームゲートウェイ４０は、インターネット上のサーバの代わりに、HTTP 200 OKメッセージを送信する（Ｓ９０）。ホームゲートウェイ４０は、HTTP 200 OKメッセージにおいて、ホームゲートウェイ４０の正しい設定内容等を通知する。通信装置２０は、HTTP 200 OKメッセージを受信すると、Ｗｅｂブラウザ上に、ホームゲートウェイ４０の正しい設定内容等を表示することができる。

ホームゲートウェイ４０は、ステップＳ９０においてHTTP 200 OKメッセージを送信した後に、代理ＨＴＴＰ応答設定を解除する（Ｓ９１）。これ以降は、通信装置２０から、50.0.0.5を宛先とするパケットが送信されてきた場合、送信されたパケットをＩＳＰネットワークへ送信する。

続いて、図１０を用いて、本発明の実施の形態４にかかるＨＴＴＰリクエスト代理応答処理の流れについて図９とは異なる例について説明する。図１０を用いて、ＤＮＳサーバ８０を用いた名前解決が行えない場合の処理の流れについて説明する。

はじめに、通信装置２０は、インターネット上のサーバへアクセスするために、ＤＮＳサーバ８０を用いた名前解決を行う。そのため、通信装置２０は、DNS queryメッセージをホームゲートウェイ４０へ送信する（Ｓ１０１）。例えば、通信装置２０は、example.co.jpとのドメイン名の名前解決を要求する。ここで、ホームゲートウェイ４０は、ＤＮＳサーバ８０と通信を行うことができず、DNS queryメッセージをＤＮＳサーバ８０へ送信することができないとする。この場合、ホームゲートウェイ４０は、ＤＮＳサーバ処理を実行する（Ｓ１０２）。例えば、ホームゲートウェイ４０は、ＤＮＳサーバ処理として、自装置のＩＰアドレスである192.168.0.1を設定したDNS replyメッセージを生成する。次に、ホームゲートウェイ４０は、自装置のＩＰアドレスである192.168.0.1を設定したDNS replyメッセージを通信装置２０へ送信する（Ｓ１０３）。ステップＳ１０４〜Ｓ１０９は、図９のステップＳ８６〜Ｓ９１における宛先アドレスに、ホームゲートウェイ４０のアドレスである192.168.0.1を設定し、図９のステップＳ８６〜Ｓ９１と同様の処理を実行する。

以上説明したように、図９及び図１０を用いることによって、ホームゲートウェイ４０が、通信装置２０へホームゲートウェイ４０における不具合を通知した後に、通信装置２０が、ホームゲートウェイ４０へアクセスしない場合においても、ホームゲートウェイ４０がＨＴＴＰ代理応答もしくはＤＮＳサーバ処理を実行する。これによって、ホームゲートウェイ４０は、通信装置２０へホームゲートウェイ４０における正しい設定内容等の情報を通知することができる。

上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、図４〜図１０において説明した処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。）

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

１０ 中継装置
１１ ＬＡＮインタフェース部
１２ ＷＡＮインタフェース部
１３ 判定部
１４ 不具合要因検査処理部
２０ 通信装置
２２ 通信装置
３０ サーバ装置
４０ ホームゲートウェイ
４１ ＬＡＮインタフェース部
４２ ＷＡＮインタフェース部
４３ パケットフロー監視部
４４ 不具合要因検査処理部
４５ 検査結果処理部
５０ 回線終端装置
６０ サポート端末
７０ 上位ルータ
８０ ＤＮＳサーバ

Claims (4)

1. ＬＡＮ回線を介して通信装置と通信を行うＬＡＮインタフェース部と、
   ＷＡＮ回線を介してインターネット上に配置されているサーバ装置及び前記インターネットへの接続を中継するＩＳＰネットワーク上に配置されているＤＮＳサーバと通信を行うＷＡＮインタフェース部と、
   前記ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号を、前記ＷＡＮ回線を介して接続されるサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定する判定部と、
   前記判定部において、前記応答信号が送信されてきていないと判定された場合に、前記ＤＮＳサーバとの間に配置されている上位ルータと通信できず、前記ＷＡＮインタフェース部における設定内容が誤っている場合、自装置に不具合が発生していると判定し、前記ＤＮＳサーバと通信できず、前記自装置に不具合が発生していない場合、前記ＩＳＰネットワークに不具合が発生していると判定し、前記ＤＮＳサーバと通信可能であり、前記サーバ装置と通信できない場合、前記インターネットに不具合が発生していると判定する不具合要因検査処理部と、
   前記不具合要因検査処理部において、前記自装置に不具合が発生していると判定された場合、前記自装置を管理するユーザが保持する通信装置へ判定結果を送信し、前記ＩＳＰネットワークに不具合が発生していると判定された場合、前記ＩＳＰネットワークに接続されているサポート端末へ判定結果を送信する判定結果通知部と、
   前記判定結果通知部によって前記自装置を管理するユーザが保持する通信装置へ判定結果が送信された後に、前記通信装置から、ＤＮＳ ｑｕｅｒｙメッセージを受信し、前記ＤＮＳサーバへ前記ＤＮＳ ｑｕｅｒｙメッセージを送信することができない場合、前記ＤＮＳサーバに代理して、前記通信装置から受信した前記ＤＮＳ ｑｕｅｒｙメッセージに対して自装置のＩＰアドレスを設定したＤＮＳ ｒｅｐｌｙメッセージを前記通信装置へ送信する代理応答部と、を備える中継装置。
2. 前記不具合要因検査処理部は、
   前記判定部において、前記リクエスト信号の再送信号の数が、予め定められた閾値を超えたと判定された場合に、不具合箇所を特定する、請求項１に記載の中継装置。
3. ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号を、ＷＡＮ回線を介して接続されるインターネット上に配置されているサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定し、
   前記応答信号が送信されてきていないと判定された場合に、ＩＳＰネットワーク上に配置されているＤＮＳサーバとの間に配置されている上位ルータと通信できず、前記サーバ装置及び前記ＤＮＳサーバと通信を行うＷＡＮインタフェース部における設定内容が誤っている場合、自装置に不具合が発生していると判定し、前記ＤＮＳサーバと通信できず、前記自装置に不具合が発生していない場合、前記ＩＳＰネットワークに不具合が発生していると判定し、前記ＤＮＳサーバと通信可能であり、前記サーバ装置と通信できない場合、前記インターネットに不具合が発生していると判定し、
   前記自装置に不具合が発生していると判定された場合、前記自装置を管理するユーザが保持する通信装置へ判定結果を送信し、前記ＩＳＰネットワークに不具合が発生していると判定された場合、前記ＩＳＰネットワークに接続されているサポート端末へ判定結果を送信し、
   前記自装置を管理するユーザが保持する通信装置へ判定結果が送信された後に、前記通信装置から、ＤＮＳ ｑｕｅｒｙメッセージを受信し、前記ＤＮＳサーバへ前記ＤＮＳ ｑｕｅｒｙメッセージを送信することができない場合、前記ＤＮＳサーバに代理して、前記通信装置から受信した前記ＤＮＳ ｑｕｅｒｙメッセージに対して自装置のＩＰアドレスを設定したＤＮＳ ｒｅｐｌｙメッセージを前記通信装置へ送信する、中継方法。
4. ＬＡＮ回線を介して接続される通信装置から送信されたリクエスト情報を含むリクエスト信号を、ＷＡＮ回線を介して接続されるインターネット上に配置されているサーバ装置へ送信した後に、前記サーバ装置から前記リクエスト信号に対する応答信号が送信されてきたか否かを判定し、
   前記応答信号が送信されてきていないと判定された場合に、ＩＳＰネットワーク上に配置されているＤＮＳサーバとの間に配置されている上位ルータと通信できず、前記サーバ装置及び前記ＤＮＳサーバと通信を行うＷＡＮインタフェース部における設定内容が誤っている場合、自装置に不具合が発生していると判定し、前記ＤＮＳサーバと通信できず、前記自装置に不具合が発生していない場合、前記ＩＳＰネットワークに不具合が発生していると判定し、前記ＤＮＳサーバと通信可能であり、前記サーバ装置と通信できない場合、前記インターネットに不具合が発生していると判定し、
   前記自装置に不具合が発生していると判定された場合、前記自装置を管理するユーザが保持する通信装置へ判定結果を送信し、前記ＩＳＰネットワークに不具合が発生していると判定された場合、前記ＩＳＰネットワークに接続されているサポート端末へ判定結果を送信し、
   前記自装置を管理するユーザが保持する通信装置へ判定結果が送信された後に、前記通信装置から、ＤＮＳ ｑｕｅｒｙメッセージを受信し、前記ＤＮＳサーバへ前記ＤＮＳ ｑｕｅｒｙメッセージを送信することができない場合、前記ＤＮＳサーバに代理して、前記通信装置から受信した前記ＤＮＳ ｑｕｅｒｙメッセージに対して自装置のＩＰアドレスを設定したＤＮＳ ｒｅｐｌｙメッセージを前記通信装置へ送信することをコンピュータに実行させるプログラム。

Images