JP5362026B2

JP5362026B2 - 通信障害要因推定方法、その推定方法を備えた通信装置およびプログラム

Info

Publication number: JP5362026B2
Application number: JP2011538109A
Authority: JP
Inventors: 翼湯村; 康之田中; 恒太郎伊瀬; 泰弘勝部
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2009-10-27
Filing date: 2009-10-27
Publication date: 2013-12-11
Anticipated expiration: 2029-10-27
Also published as: WO2011052001A1; JPWO2011052001A1

Description

本発明は、通信障害要因推定方法、およびその推定方法を備えた通信装置に関する。

ネットワークを介して接続される通信装置間で、通信の切断もしくは品質劣化などの障害が発生した場合、障害の要因を推定する技術が特許文献１に開示されている。その特許文献１の発明では、通信装置とネットワークの負荷を観測することにより、障害要因がネットワークと通信装置のいずれに存在するかを推定している。

特開P2007-189615号公報

特許文献１の推定方法では、論理的に接続されていない、パケットフィルタソフトによりパケットが廃棄されているなどの障害の要因を推定するものではないため、ユーザが障害に対して適切な対応をとることができなかった。

本発明の目的は、通信障害が発生した場合に、要因を詳細に推定することができる通信障害要因推定方法、およびその推定方法を備えた通信装置を提供することにある。

上記目的を達成するために、実施形態の通信障害要因推定方法は、中継装置を介して通信を行う第１通信装置と第２通信装置との間の通信障害要因を推定する方法であって、前記第２通信装置に対して応答パケットを要求するパケットを送信し、前記パケットを送信してから任意時間内に、前記第２通信装置からの前記応答パケットを受信するか否かを判定し、前記応答パケットが受信されない場合に、受信した特定のパケットを廃棄するフィルタ機構を前記第１通信装置が有しているか否かを調べる第１の調査を実行し、前記フィルタ機構を前記第１通信装置が有している場合に、前記フィルタ機構が通信障害要因であると判定することを特徴とする。

本発明によれば、通信障害が発生した場合に、障害の要因を詳細に推定することができる。そのため、通信障害の原因をいち早く検出することができる。

本発明の実施形態に係る通信システムを示す図。同実施形態に係る通信障害要因推定の手順を示すフローチャート。同実施形態に係るクライアント端末においてサーバ端末を指定する画面の例。同実施形態に係る接続性障害要因推定の手順を示すフローチャート。同実施形態に係るクライアント端末において通信品質を選択する画面の例。同実施形態に係る品質障害要因推定の手順を示すフローチャート。同実施形態に係る無線区間有無判定の手順を示すフローチャート。同実施形態に係るクライアント端末の構成を示す図。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。

図１は、本発明の実施形態に係る通信システムを示す図である。本実施形態の通信システムは、通信装置（以下、クライアント端末という）１００、通信装置（以下、サーバ端末という）２００、ネットワーク３００で構成される。クライアント端末１００と通信装置２００は、ネットワーク３００を介して接続される。ネットワーク３００はインターネットのような大規模な有線ネットワークでもよいし、ＬＡＮ（Local Area Network）のような小規模なネットワークでもよい。また、有線ネットワークでも、更には無線ネットワークでもよい。

本実施形態では、ネットワーク３００はＬＡＮ４００、ＨＧＷ（Home GateWay）５００、ＷＡＮ（Wide Area Network）６００を含む。クライアント端末１００はＬＡＮ４００に接続し、サーバ端末２００はＷＡＮ６００に接続している。ＬＡＮ４００とＷＡＮ６００とは、ＨＧＷ５００に接続されている。すなわち、ＨＧＷ５００はクライアント端末１００とサーバ端末２００間の通信を中継する中継端末の役割を果たしている。ＨＧＷ５００はＬＡＮ４００とＷＡＮ６００の両方に接続するため、２つのネットワークインタフェースを有する。

クライアント端末１００およびサーバ端末２００は、例えばＰＣとテレビ、又はＰＣと携帯電話、又はテレビと携帯電話などの組合せである。なお、以降の説明では、データの通信方式としてTCP/IP 関連プロトコルを想定するが、同等のことを実施できるならば他のプロトコルや通信方式でもよい。

図２は、本実施形態における通信障害要因推定方法の手順を示すフローチャートである。ここでは、クライアント端末１００が、この通信障害要因推定方法を実行するものとする。しかし、クライアント端末１００ではなく、サーバ端末２００がこの通信障害要因推定方法を実行するものであってもよい。

クライアント端末１００が通信障害要因推定方法の実行を開始する条件は、例えば、クライアント端末１００においてユーザが特定の実行コマンドを入力することである。または、ユーザが特定のボタンやアイコンをクリックして実行を指示するものでもよい。または、クライアント端末１００が、定期的に自動的に実行するものでもよい。あるいは、クライアント端末１００からＴＣＰのような応答を要求するパケットを送信した場合に、任意時間内（予め決めておいた時間でもよく、適宜変更した時間でもよい）に応答を受信しない場合に実行するものでもよい。

図２において、まず、クライアント端末１００は、接続対象の通信装置（ここでは、サーバ端末２００）と接続されているかどうかを調べる（ステップＳ１）。具体的には、クライアント端末１００は、サーバ端末２００宛にパケットを送信する。なお、クライアント端末１００が接続を調べる対象とする端末（すなわち、サーバ装置２００）の指定は、図３に示すようにユーザがＵＲＬを入力してもよいし、あらかじめ定められた端末としてもよい。

クライアント端末１００が送信するパケットは、サーバ端末２００に応答信号を要求するパケットを用いる。例えば、ＴＣＰのコネクションを確立するためのパケットである。この場合、クライアント端末１００は、パケットのＴＣＰヘッダのＳＹＮフラグビットに「１」を設定して送信する。このパケットを受信したサーバ端末２００は、ＴＣＰのルールに従って、ＴＣＰヘッダのＳＹＮフラグビットとＡＣＫフラグビットに「１」を設定したパケットを、応答としてクライアント端末１００宛に返信する。または、上記パケットの代わりに、クライアント端末１００は ICMP ECHO REQUESTパケット(Ping)を送信してもよい。この場合は、サーバ端末２００から応答信号として ICMP ECHO REPLYパケットが返信される。

これらの方法において、クライアント端末１００は、サーバ端末２００から応答信号を受信すれば、サーバ端末２００と接続していると判定する（ステップＳ１の“Ｙｅｓ”）。一方、一定の時間が経過しても応答信号が受信できなければ、サーバ端末２００と接続されていないと判定する（ステップＳ１の“Ｎｏ”）。

サーバ端末２００と接続されていないと判定した場合（ステップＳ１の“Ｎｏ”）、クライアント端末１００は、接続障害要因推定を行う（ステップＳ２）。

図４は、接続障害要因推定の詳細な手順を示すフローチャートである。図４において、まず、クライアント端末１００は、ＨＧＷ５００がＷＡＮにおけるＩＰアドレスを取得しているかを確認する（ステップＳ２_１）。具体的には、クライアント端末１００は、Get External IP Addressアクションを記述した XML ファイルにSOAP Actionヘッダを付けて、HTTP POSTでＨＧＷ５００に送信する。ＨＧＷ５００からの応答信号として、クライアント端末１００がＸＭＬファイル（ＩＰアドレスが設定されている）を受信すれば、ＨＧＷ５００はＷＡＮ６００におけるＩＰアドレスを取得済みであると判定する。一方、ＨＧＷ５００からの応答信号として、クライアント端末１００が「SOAP ERROR」あるいは「HTTP ERROR」を受信すれば、ＨＧＷ５００はＷＡＮ６００におけるＩＰアドレスを有していないと判定する。

ＨＧＷ５００がＷＡＮ６００におけるＩＰアドレスを取得済みである場合には（ステップＳ２_１の“Ｙｅｓ”）、クライアント端末１００がパケットフィルタソフト（特定パケットを廃棄するフィルタ機構）を備えているかどうかを調べる（ステップＳ２_２）。例えば、クライアント端末１００は、いくつかの一般的なパケットフィルタソフトの名称が、インストール済みソフトウェアのリストに含まれているかを文字列照合により調べる。あるいは、パケットフィルタソフトを備えている場合には、パケットの宛先アドレス（ここではサーバ端末２００）や通信プロトコルが、通信を許可しないフィルタリストとして設定ファイルに登録されていないことを調べてもよい。

クライアント端末１００がパケットフィルタソフトを備えている場合には（ステップＳ２_２の“Ｙｅｓ”）、パケットフィルタソフトが障害要因があると推定する（ステップＳ２_４）。つまり、パケットフィルタソフトがパケットを廃棄しているために、クライアント端末１００とサーバ端末２００とが接続されないと判定する。

クライアント端末１００がパケットフィルタソフトを備えていない場合には（ステップＳ２_２の“Ｎｏ”）、サーバ端末２００とＨＧＷ５００との間（ここではＷＡＮ６００）に障害要因があると推定する（ステップＳ２_５）。

一方、ステップＳ２＿１で、ＨＧＷ５００がＷＡＮ６００におけるＩＰアドレスを取得していない場合には（ステップＳ２_１の“Ｎｏ”）、クライアント端末１００は、ＨＧＷ５００とサーバ端末２００間（ここではＷＡＮ６００）でリンクアップしているか否かを調べる（ステップＳ２_３）。すなわち、クライアント端末１００は、Get Link Layer Max Bit Ratesアクションを記述したXMLファイルにSOAP Actionヘッダを付けて、HTTP POSTでＨＧＷ５００に送信する。ＨＧＷ５００からの応答信号として、クライアント端末１００がＸＭＬファイル（ＷＡＮの上りリンクと下りリンクの最大リンク速度が記載されている）を受信すれば、ＨＧＷ５００は正常にＷＡＮ６００にリンクアップしていると判定する。一方、ＨＧＷ５００からの応答信号として、クライアント端末１００が「SOAP ERROR」あるいは「HTTP ERROR」を受信すれば、ＨＧＷ５００はＷＡＮ６００にリンクアップしていないと判定する。

ＨＧＡ５００がＷＡＮ６００にリンクアップしている場合には（ステップＳ２_３の“Ｙｅｓ”）、ＨＧＷ５００の設定に障害要因があると推定する（ステップＳ２_６）。つまり、ＨＧＷ５００の設定に問題があるため、ＨＧＷ５００がＷＡＮにおけるＩＰアドレスを取得できず、クライアント端末１００とサーバ端末２００間の接続が確立されないと判定できる。

一方、ＨＧＡ５００がＷＡＮ６００にリンクアップしていない場合には（ステップＳ２_３の“Ｎｏ”）、ＨＧＷ５００におけるＷＡＮ６００とのユーザインタフェースに障害要因があると推定する（ステップＳ２_７）。例えば、ケーブルが物理的に抜けているためにサーバ端末２００と接続されないと判定する。

以上のステップＳ２_１〜ステップＳ２_７により、クライアント端末１００は、サーバ端末２００との間の接続障害の要因を推定する。その後、クライアント端末１００は、推定した障害要因を表示部等に出力する。例えば、図８の表示部１５０に「パケットフィルタソフトの設定を確認してください」や「HGWのケーブルが抜けていないか確認してください」といった、障害要因に応じたメッセージを表示する。

図２に戻り、ステップＳ１でサーバ端末２００と接続していると判定した場合（ステップＳ１の“Ｙｅｓ”）、クライアント端末１００は、サーバ端末２００との間の通信品質を調べる（ステップＳ３）。通信品質とは、例えば動画のストリーミング配信における映像の乱れ具合などである。通信品質を調べる方法として、例えば、クライアント端末１００がサーバ端末２００から動画データをストリーミング受信してクライアント端末１００の表示部１５０に表示する。そして、表示される映像が乱れているか否かをユーザに選択入力させる。または、ユーザが動画の視聴状況などから通信品質が十分であるか否かを、図５に示すようにユーザに選択させてもよい。この場合、あらかじめ通信品質を認識していることを前提とする。あるいは、ping等を用いてパケットロス率を測定し、あらかじめ定めた閾値よりもパケットロス率が高い場合に、通信品質が低いと判定してもよい（ステップＳ３の“Ｎｏ”）。

ステップＳ３で、通信品質が低いと判定した場合（ステップＳ３の“Ｎｏ”）、クライアント端末１００は、品質障害要因推定を行う（ステップＳ４）。

図６は、品質障害要因推定の詳細な手順を示すフローチャートを示す。図６において、まず、クライアント端末１００とサーバ端末２００との間に無線区間が存在するか否かの判定（無線区間有無判定）する（ステップＳ４_１）。

図７は、無線区間有無判定の詳細な手順を示すフローチャートである。図７では、クライアント端末１００からの要求に従って、ＨＧＷ５００が無線区間有無判定を実行するものとする。

図７において、まず、クライアント端末１００からＨＧＷ５００へ、無線区間有無判定の開始を指示するパケットを送信する。ＨＧＷ５００はこのパケットを受信し、無線区間有無の判定を開始する（ステップＳ１００１）。

次に、ＨＧＷ５００は、クライアント端末１００宛に、ICMP ECHO REQUESTパケット（ping）をユニキャスト送信する（ステップＳ１００２）。ユニキャストのpingで使用するパラメータ（データサイズやパケット間隔、パケット送信回数など）は、事前に設定されているものとする。クライアント端末１００はICMP ECHO REQUESTパケットを受信すると、ICMP ECHO REPLYパケットをＨＧＷ５００に返信する。ＨＧＷ５００は、クライアント端末１００からのICMP ECHO REPLYパケットの受信数と、自装置が送信したICMP ECHO REQUESTパケットの送信数を用いて、パケットロス率を計算する（ステップＳ１００２）。計算したパケットロス率は、ＨＧＷ５００の内部メモリ等に記憶される。

次に、ＨＧＷ５００は、ICMP ECHO REQUESTパケット（ping）をブロードキャスト送信する（ステップＳ１００３）。ブロードキャストのpingで使用するパラメータ（データサイズやパケット間隔、パケット送信回数など）は、ステップＳ１００２におけるユニキャスト送信時と同じ値を使用する。また、ブロードキャスト送信ではICMP ECHO REQUESTパケットの宛先ＩＰアドレスとして、例えば「２５５.２５５.２５５.２５５」などのブロードキャストアドレスを設定する。そして、ステップＳ１００２と同様に、ＨＧＷ５００は、クライアント端末１００からのICMP ECHO REPLYパケットの受信数と、自装置が送信したICMP ECHO REQUESTパケットの送信数を用いて、パケットロス率を計算する。計算したパケットロス率は、ＨＧＷ５００の内部メモリ等に記憶される。

次に、ＨＧＷ５００は、ユニキャスト送信時とブロードキャスト送信時のパケットロス率をそれぞれメモリから取得し、両者の差を計算する。そして、計算したパケットロス率の差を、既定の閾値と比較する（ステップＳ１００４）。

パケットロス率の差が閾値よりも小さい場合（ステップＳ１００４の“Ｎｏ”）、ＨＧＷ５００はクライアント端末１００との間に無線区間が存在しないと判定する（ステップＳ１００５）。

一方、パケットロス率の差が閾値よりも大きい場合（ステップＳ１００４の“Ｙｅｓ”）、ＨＧＷ５００はクライアント端末１００との間に無線区間が存在すると判定する（ステップＳ１００６）。

上記の無線区間有無判定の終了後、ＨＧＷ５００は、判定結果をクライアント端末１００に通知する。

図６に戻り、ステップＳ４＿２で無線区間が存在すると判定された場合（ステップＳ４_２の“Ｙｅｓ”）、クライアント端末１００は、無線区間が通信障害要因であると判定する（ステップＳ４_３）。すなわち、無線区間は有線区間よりも伝播環境等によりパケットロスが発生しやすいので、通信品質が劣化している状況である。

ＨＧＷ５００とクライアント端末１００との間に無線区間が存在すると判定された場合、以後の通信では無線区間の存在を考慮した送信制御を行うことができる。例えば、TCP (Transmission Control Protocol)のように輻輳制御を有する通信方式では、無線区間特有のパケットロスを考慮した輻輳制御アルゴリズムを使用する。また、例えば音声や映像などのマルチメディアデータの転送では、無線区間特有のパケットロスに対する耐性が高いエンコード方式を採用する。

一方、ＨＧＷ５００とクライアント端末１００の間に無線区間が存在しないと判定された場合は（ステップＳ４＿２の“Ｎｏ”）、一般的には無線回線よりも通信品質が高いとされる有線回線によりＨＧＷ５００とクライアント端末１００が接続されていると想定し、より通信効率の高い方式でデータ送受信を行う（ステップＳ４＿４）。例えば、TCPのようなフロー制御を行う通信方式では、ウィンドウの増減をより積極的に行うことで通信効率を向上させることができる。また、音声や映像などのマルチメディアデータの転送ではビットレートの高いエンコード方式を採用することができる。以上の処理で、推定処理を終了する。

次に、本実施形態におけるクライアント端末１００の構成を説明する。図８に、クライアント端末１００を示す。クライアント端末１００は、推定部１１０、送信部１２０、受信部１３０、探索部１４０を有する。

推定部１１０は、上述の通信障害要因推定方法を実行する。通信障害要因推定方法に従って、前述した各種パケットの送信を送信部１２０に指示する。パケット送信後、送信したパケットに対する応答パケットを任意時間内に受信したか否かの情報を受信部１３０から受け取る。さらに応答パケットを受信した場合には、当該応答パケットの内容を、受信部１３０から受け取る。

また、推定部１１０は、通信障害要因推定方法に従って、パケットフィルタソフトがインストールされているかの調査を、探索部１４０に指示する。その後、調査結果として、パケットフィルタソフトの有無を、探索部１４０から受け取る。

推定部１１０は、受信部１３０から通知される応答パケットの有無と応答パケットの内容、および探索部１４０から通知されるパケットフィルタソフトの有無に基づいて、前述した通信障害要因推定方法の手順に従って通信障害要因を推定する。

送信部１２０は、推定部１１０からの指示に従って、パケットを送信する。

受信部１３０は、他の通信装置（ここでは、サーバ端末２００やHGW５００）が送信するパケットを受信する。さらに、受信部１３０は、パケット受信の有無や、受信したパケットの内容を推定部１１０に通知する。

探索部１４０は、推定部１１０からの指示に従って、自端末にパケットフィルタソフトがインストールされているか否かを調査する。そして探索部１４０は、調査結果として、パケットフィルタソフトの有無を、推定部１１０に通知する。

探索部１４０は、推定部１１０に含まれていてもよい。また、クライアント端末１００は、推定部１１０において推定した通信障害要因を出力して、ユーザに通知するための表示部１５０をさらに備えていてもよい。

本実施形態の通信障害要因推定方法によれば、通信障害が発生した場合に、通信障害要因を具体的に推定することができる。また、推定した通信障害要因をユーザに通知することで、ユーザが障害に対して適切な対応をとることができる。

尚、本実施形態ではネットワークプロトコルとしてIPv4を仮定して説明したが、ネットワークプロトコルはIPv6でもよい。さらには、以上で説明した内容と同等手順、効果が得られればTCP/IP以外の通信プロトコルを用いてもよい。

また、本実施形態の通信障害要因推定方法は、クライアント端末１００とサーバ端末２００が同じLANに接続されているシステムにおいて、実施してもよい。この場合、通信障害要因推定方法におけるWAN６００に関する手順（ステップS２_１：HGW５００がWAN６００におけるIPアドレスを取得しているかどうかの確認及びステップS２_３：HGW５００がWLAN６００にリンクアップしているかどうかの確認）は行わない。

尚、本発明は上記実施形態をそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

１００・・・クライアント端末
２００・・・サーバ端末
３００・・・ネットワーク
４００・・・LAN
５００・・・HGW
６００・・・WAN
１１０・・・推定部
１２０・・・送信部
１３０・・・受信部
１４０・・・探索部
１５０・・・表示部

Claims

中継装置を介して通信を行う第１通信装置と第２通信装置との間の通信障害要因を推定する方法であって、
前記第２通信装置に対して応答パケットを要求するパケットを送信し、
前記パケットを送信してから任意時間内に、前記第２通信装置からの前記応答パケットを受信するか否かを判定し、
前記応答パケットが受信されない場合に、受信した特定のパケットを廃棄するフィルタ機構を前記第１通信装置が有しているか否かを調べる第１の調査を実行し、
前記フィルタ機構を前記第１通信装置が有している場合に、前記フィルタ機構が通信障害要因であると判定することを特徴とする通信障害要因推定方法。
前記中継装置が論理的に前記第２通信装置と接続されているか否かを調べる第２の調査を実行することを特徴とする請求項１記載の通信障害要因推定方法。
前記第２の調査は、前記中継装置がネットワークアドレスを取得しているか否かを調べ、前記ネットワークアドレスを取得していない場合に、前記中継装置が論理的に前記第２通信装置と接続されていないと判定することを特徴とする請求項２に記載の通信障害要因推定方法。
前記中継装置が物理的に前記第２通信装置と接続されているか否かを調べる第３の調査を実行することを特徴とする請求項１又は２記載の通信障害要因推定方法。
前記第３の調査は、前記中継装置と前記第２の通信装置との間のリンクアップ状況を調べ、前記リンクアップ状況がエラーを示す場合に、前記中継装置が物理的に前記第２通信装置と接続されていないと判定することを特徴とする請求項４に記載の通信障害要因推定方法。
前記応答パケットが受信された場合に、前記中継装置と前記第１通信装置との間に無線区間が存在するか否かを調査する第４の調査を実行することを特徴とする請求項１に記載の通信障害要因推定方法。
前記第４の調査は、前記中継装置と第１通信装置との間のユニキャスト通信における第１のパケットロス率と、前記中継装置と第１通信装置との間のブロードキャスト通信における第２のパケットロス率と、を測定し、前記第１のパケットロス率と前記第２のパケットロス率とを比較し、前記第２のパケットロス率の方が高い場合に、前記無線区間が存在すると判定することを特徴とする請求項６に記載の通信障害要因推定方法。
前記第４の調査は、前記無線区間が存在する場合に、前記無線区間が通信障害要因であると判定し、パケットの送信方法を変更することを特徴とする請求項７に記載の通信障害要因推定方法。
前記第１の調査に基づき判定した通信障害要因を表示することを特徴とする請求項１に記載の通信障害要因推定方法。
中継装置を介して他の通信装置と通信を行う通信装置であって、
前記他の通信装置との間の前記通信に障害が発生した場合に、障害要因を推定する推定部と、
前記推定部の指示に従ってパケットを前記他の通信装置に送信する送信部と、
前記他の通信装置からの応答パケットを受信する受信部と、
特定のパケットを廃棄するフィルタ機構の有無を、前記推定部の指示に従って探索する探索部とを備え、
前記推定部は、
前記受信部が前記他の通信装置から任意時間内に前記応答パケットを受信するか否かを判定し、前記応答パケットが受信されない場合に、受信した特定のパケットを廃棄するフィルタ機構を自通信装置が有しているか否かを前記探索部に調べさせる第１の調査を実行し、前記フィルタ機構を有している場合に、前記フィルタ機構が通信障害要因であると判定することを特徴とする通信装置。
中継装置を介して通信を行う第１通信装置と第２通信装置との間の通信障害要因を推定するプログラムであって、
前記第２通信装置に対して応答パケットを要求するパケットを送信し、
前記パケットを送信してから任意時間内に、前記第２通信装置からの前記応答パケットを受信するか否かを判定し、
前記応答パケットが受信されない場合に、受信した特定のパケットを廃棄するフィルタ機構を前記第１通信装置が有しているか否かを調べる第１の調査を実行し、
前記フィルタ機構を前記第１通信装置が有している場合に、前記フィルタ機構が通信障害要因であると判定することを特徴とするプログラム。