(57)【要約】【課題】無線ネットワークの障害の原因を精度よく判定する。【解決手段】ＡＰ２０は、端末特定部２３と、障害判定部２２とを備える。端末特定部２３は、端末との間の通信状況に基づいて、フェージングの影響を受けている第１の端末を特定する。障害判定部２２は、端末特定部２３によって特定された第１の端末を除いた複数の端末について、該端末へパケットを送信してから該パケットに対する応答パケットを受信するまでの応答時間に基づいて、ＡＰ２０が干渉を受けているか否かを判定する。【選択図】図２
2017041806.tif 000002
【特許請求の範囲】
【請求項１】
無線通信装置と複数の端末装置とを有する無線通信システムに用いられる無線通信装置において、
複数の前記端末装置との間の通信状況に基づいて、フェージングの影響を受けている第１の端末装置を特定する特定部と、
前記特定部によって特定された前記第１の端末装置を除いた複数の前記端末装置について、該端末装置へパケットを送信してから該パケットに対する応答パケットを受信するまでの応答時間に基づいて、自装置が干渉を受けているか否かを判定する判定部と
を備えることを特徴とする無線通信装置。
【請求項２】
前記特定部は、
複数の前記端末装置がユーザデータを有するパケットの送受信を行っていない環境で、それぞれの前記端末装置へテストパケットを送信し、該端末装置から受信した応答パケットの受信電力の平均値が所定の閾値以下である端末装置を、前記第１の端末装置として特定することを特徴とする請求項１に記載の無線通信装置。
【請求項３】
前記特定部は、
複数の前記端末装置がユーザデータを有するパケットの送受信を行っていない環境で、それぞれの前記端末装置へテストパケットを送信し、該端末装置から受信した応答パケットの受信電力の平均値が所定の閾値以下である端末装置を特定し、特定した端末装置の中で、複数の前記端末装置がユーザデータを有するパケットの送受信を行う環境でパケットのロス率が所定値以上となった端末装置を、前記第１の端末装置として特定することを特徴とする請求項１に記載の無線通信装置。
【請求項４】
前記閾値は、
受信感度の電力よりも、所定のフェージングマージン分高い電力であることを特徴とする請求項２または３に記載の無線通信装置。
【請求項５】
前記特定部は、
複数の前記端末装置がユーザデータを有するパケットの送受信を行っていない環境で、前記応答時間のばらつきの度合いが遅延増加量の期待値よりも大きい端末装置を、前記第１の端末装置として特定することを特徴とする請求項１に記載の無線通信装置。
【請求項６】
前記特定部は、
許容されるパケット誤り率をＰＥＲ、再送回数をＮ、パケット長をＤpとした場合に、下記の算出式（１）に基づいて算出された遅延増加量の期待値Ｄintfを用いて、前記第１の端末装置を特定することを特徴とする請求項５に記載の無線通信装置。
Ｄintf＝［｛（１−ＰＥＲN）／（１−ＰＥＲ）｝−１］×Ｄp  ・・・（１）
【請求項７】
前記特定部は、
前記応答時間の標準偏差の所定数倍を、前記ばらつきの度合いとして用いることを特徴とする請求項５または６に記載の無線通信装置。
【請求項８】
無線通信装置と複数の端末装置とを有する無線通信システムにおいて、
前記無線通信装置は、
複数の前記端末装置との間の通信状況に基づいて、フェージングの影響を受けている第１の端末装置を特定する特定部と、
前記特定部によって特定された前記第１の端末装置を除いた複数の前記端末装置について、該端末装置へパケットを送信してから該パケットに対する応答パケットを受信するまでの応答時間に基づいて、自装置が干渉を受けているか否かを判定する判定部と
を有することを特徴とする無線通信システム。
【請求項９】
無線通信装置と複数の端末装置とを有する無線通信システムに用いられる無線通信装置における障害原因推定方法において、
前記無線通信装置が、
複数の前記端末装置との間の通信状況に基づいて、フェージングの影響を受けている第１の端末装置を特定し、
特定された前記第１の端末装置を除いた複数の前記端末装置について、該端末装置へパケットを送信してから該パケットに対する応答パケットを受信するまでの応答時間に基づいて、自装置が干渉を受けているか否かを判定する
処理を実行することを特徴とする障害原因推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信装置、無線通信システムおよび障害原因推定方法に関する。
【背景技術】
【０００２】
ＩＳＭ（Industry  Science  Medical）帯の電波を用いた無線ＬＡＮ（Local  Area  Network）等の無線ネットワークは、免許不要で手軽に使えるため利用シーンが増えている。しかし、ＩＳＭ帯の電波を用いる無線通信機器が無計画に配置されると、お互いに電波干渉を与え合い、通信環境が不安定となる。よって、通信ネットワークを安定して使うためには運用保守が重要となる。大規模ネットワークであれば専門の運用保守業者もしくは情報システム部門によってネットワークの監視、障害対策が行われる。また、個人宅や小規模なネットワークでは専用の運用保守部門はなく、ユーザ自ら障害に対応することになる。
【０００３】
しかし、電波は目に見えないため、無線ネットワークの障害の原因を特定することは容易ではない。また、障害が断続的に発生している場合には、障害の発生時点を見極めることも難しい。このように、無線ネットワークの障害は、原因の特定が難しいため、的確な対処を行うことが難しい。運用保守の専門家であっても、多くの場合、経験によって蓄積されたノウハウによる対症療法的な対処を行っており、そのため根本的な対策をとっていない場合は障害が再発する可能性もある。また、無線ネットワークが普及、増加していくにつれ、運用保守業者の数が不足する恐れもある。よって、ネットワーク安定性を向上し、かつ作業負荷を軽減する運用保守技術が求められている。
【０００４】
これに対し、例えば、無線ネットワーク内の端末に電波の測定機能を持たせ、端末が測定した情報をアクセスポイントに通知し、アクセスポイントが端末から収集した情報に基づいて障害原因を診断する技術が知られている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１１７９５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、無線ＬＡＮ等の無線ネットワークにおいて、アクセスポイントは、無線ネットワークの運用保守を行う管理者によって管理される。しかし、端末は、端末のユーザによって管理される場合が多く、無線ネットワーク内の全ての端末が、電波環境を測定してアクセスポイントに報告するような特定の機能を備えているとは限らない。そのような場合には、アクセスポイントは、無線ネットワークの障害の原因を判定することが困難となる。また、アクセスポイントや端末がフェージングを受けている場合には、アクセスポイントや端末に電波干渉等の障害が発生していなくても、電波干渉等が無線ネットワークの障害の原因として誤って判定される場合がある。
【０００７】
本願に開示の技術は、無線ネットワークの障害の原因を精度よく判定する。
【課題を解決するための手段】
【０００８】
１つの側面では、無線通信装置と複数の端末装置とを有する無線通信システムに用いられる無線通信装置は、特定部と、判定部とを備える。特定部は、複数の端末装置との間の通信状況に基づいて、フェージングの影響を受けている第１の端末装置を特定する。判定部は、特定部によって特定された第１の端末装置を除いた複数の端末装置について、該端末装置へパケットを送信してから該パケットに対する応答パケットを受信するまでの応答時間に基づいて、自装置が干渉を受けているか否かを判定する。
【発明の効果】
【０００９】
１実施形態によれば、無線ネットワークの障害の原因を精度よく判定することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、無線通信システムの一例を示す図である。
【図２】図２は、ＡＰの一例を示すブロック図である。
【図３】図３は、測定値テーブルの一例を示す図である。
【図４】図４は、応答時間の一例を説明する図である。
【図５】図５は、応答時間テーブルの一例を示す図である。
【図６】図６は、パケットロス率テーブルの一例を示す図である。
【図７】図７は、ＲＳＳＩテーブルの一例を示す図である。
【図８】図８は、ログテーブルの一例を示す図である。
【図９】図９は、端末リストテーブルの一例を示す図である。
【図１０】図１０は、応答時間の変動の一例を説明する図である。
【図１１】図１１は、ＲＳＳＩの変動の一例を説明する図である。
【図１２】図１２は、障害の一例を説明する図である。
【図１３】図１３は、シミュレーション結果の一例を示す図である。
【図１４】図１４は、基準値作成処理の一例を示すフローチャートである。
【図１５】図１５は、実施例１における除外端末特定処理の一例を示すフローチャートである。
【図１６】図１６は、測定処理の一例を示すフローチャートである。
【図１７】図１７は、実施例１における障害原因推定処理の一例を示すフローチャートである。
【図１８】図１８は、遮蔽・故障診断処理の一例を示すフローチャートである。
【図１９】図１９は、干渉診断処理の一例を示すフローチャートである。
【図２０】図２０は、実施例２における障害原因推定処理の一例を示すフローチャートである。
【図２１】図２１は、実施例３における除外端末特定処理の一例を示すフローチャートである。
【図２２】図２２は、ＡＰのハードウェアの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示する無線通信装置、無線通信システムおよび障害原因推定方法の実施例を、図面に基づいて詳細に説明する。なお、以下の実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１２】
［無線通信システム１０］
図１は、無線通信システム１０の一例を示す図である。本実施例における無線通信システム１０は、ＡＰ（Access  Point）２０および複数の端末１３−１〜１３−ｎを備える。ＡＰ２０は、ルータ等のネットワーク装置１２を介して、例えばＷＡＮ（Wide  Area  Network）１１等のコアネットワークに接続される。ＡＰ２０は、端末１３−１〜１３−ｎのそれぞれと無線ＬＡＮに基づく無線通信を行う。なお、以下では、複数の端末１３−１〜１３−ｎのそれぞれを区別することなく総称する場合に端末１３と記載する。ＡＰ２０は、無線通信装置の一例である。また、端末１３は、端末装置の一例である。
【００１３】
ＡＰ２０は、端末１３から受信したパケットをネットワーク装置１２へ送る。また、ＡＰ２０は、ネットワーク装置１２から受信したパケットを、無線通信により端末１３へ送信する。ネットワーク装置１２は、ＡＰ２０からパケットを受信した場合に、受信したパケットの宛先に基づいて、受信したパケットをＷＡＮ１１へ送信する。また、ネットワーク装置１２は、ＡＰ２０または端末１３宛のパケットをＷＡＮ１１から受信した場合に、受信したパケットをＡＰ２０へ送る。
【００１４】
［ＡＰ２０］
図２は、ＡＰ２０の一例を示すブロック図である。ＡＰ２０は、例えば図２に示すように、通信制御部２１、障害判定部２２、端末特定部２３、および保持部２４を有する。また、ＡＰ２０は、応答時間測定部２５、パケットロス率測定部２６、ＲＳＳＩ（Received  Signal  Strength  Indicator）測定部２７、送信部２８、受信部２９、およびアンテナ２００を有する。保持部２４は、測定値テーブル２４０、応答時間テーブル２４１、パケットロス率テーブル２４２、ＲＳＳＩテーブル２４３、ログテーブル２４４、および端末リストテーブル２４５を保持する。
【００１５】
図３は、測定値テーブル２４０の一例を示す図である。測定値テーブル２４０には、例えば図３に示すように、端末ＩＤ２４００毎に、個別テーブル２４０１が格納される。端末ＩＤ２４００は、それぞれの端末１３を識別する情報であり、例えば端末１３のＭＡＣ（Media  Access  Control）アドレスである。それぞれの個別テーブル２４０１には、応答時間２４０２、ＲＳＳＩ２４０３、およびパケットロス２４０４を含む複数のレコード２４０５が格納される。
【００１６】
応答時間２４０２は、ＡＰ２０から端末１３へパケットが送信されてから、該パケットに対する応答パケットをＡＰ２０が受信するまでの時間である。図４は、応答時間の一例を説明する図である。ＡＰ２０から端末１３へパケットが送信される場合、ＡＰ２０では、例えば通信制御部２１から送信部２８に、パケットの送信が指示される。送信部２８は、所定時間ｔ1の間、パケットの送信を待機した後に、アンテナ２００を介してパケットを送信する。所定時間ｔ1には、例えばＤＩＦＳ（Distributed  Inter  Frame  Space）期間およびバックオフ期間等が含まれる。ＡＰ２０から送信されたパケットは、端末１３において受信される。
【００１７】
端末１３は、パケットを受信してから所定時間ｔ2が経過した後に、受信したパケットに対する応答パケットであるＡｃｋ（Acknowledgement）パケットをＡＰ２０へ送信する。所定時間ｔ2は、例えばＳＩＦＳ（Short  Inter  Frame  Space）期間である。端末１３から送信されたＡｃｋパケットは、ＡＰ２０において受信される。端末１３から送信されたＡｃｋパケットは、ＡＰ２０からパケットが送信されてから所定時間ｔ3が経過した後に、ＡＰ２０において受信される。所定時間ｔ3は、ＡＰ２０と端末１３との間の無線通信路における往復の伝送時間と所定時間ｔ2とを合計した時間である。本実施例において、応答時間とは、例えば図４に示すように、通信制御部２１からパケットの送信が指示されてから、送信されたパケットに対するＡｃｋパケットを受信部２８が受信するまでの時間ｔ0である。
【００１８】
ＲＳＳＩ２４０３は、端末１３から送信されたパケットをＡＰ２０が受信した場合の受信電力である。パケットロス２４０４は、ＡＰ２０が、端末１３へ送信したパケットに対するＡｃｋパケットを受信しなかったことによりパケットロスと判定したか否かを示す情報である。ＡＰ２０が端末１３へ送信したパケットに対してＡｃｋパケットを受信した場合、パケットロス２４０４にはパケットロスが発生しなかったことを示す０が格納される。一方、ＡＰ２０が端末１３へ送信したパケットに対してＡｃｋパケットを受信しなかった場合、パケットロス２４０４にはパケットロスが発生したことを示す１が格納される。
【００１９】
ＡＰ２０が端末１３へパケットを送信する度に、該端末１３の端末ＩＤに対応する個別テーブル２４０１には、レコード２４０５が作成される。そして、ＡＰ２０が該端末１３からＡｃｋパケットを受信した場合、作成されたレコード２４０５内の応答時間２４０２およびＲＳＳＩ２４０３には測定値が登録され、パケットロス２４０４には０が登録される。一方、ＡＰ２０が該端末１３からＡｃｋパケットを受信しなかった場合、作成されたレコード２４０５内のパケットロス２４０４には１が登録され、応答時間２４０２にはパケットロスと判定されるまでの時間が登録され、ＲＳＳＩ２４０３は空欄となる。
【００２０】
図５は、応答時間テーブル２４１の一例を示す図である。応答時間テーブル２４１には、例えば図５に示すように、端末ＩＤ２４１０、平均応答時間２４１１、基準値２４１２、および応答時間マージン２４１３が対応付けて格納される。平均応答時間２４１１は、応答時間の平均値である。基準値２４１２は、平均応答時間２４１１の基準となる値である。応答時間マージン２４１３は、基準値２４１２に対して許容される平均応答時間の変動幅を示す値である。
【００２１】
図６は、パケットロス率テーブル２４２の一例を示す図である。パケットロス率テーブル２４２には、例えば図６に示すように、端末ＩＤ２４２０に対応付けてパケットロス率２４２１が格納される。パケットロス率２４２１は、ＡＰ２０から送信されたパケットのうち、該パケットに対するＡｃｋパケットがＡＰ２０において受信されなかったパケットの割合である。
【００２２】
図７は、ＲＳＳＩテーブル２４３の一例を示す図である。ＲＳＳＩテーブル２４３には、例えば図７に示すように、端末ＩＤ２４３０に対応付けて、平均ＲＳＳＩ２４３１が格納される。平均ＲＳＳＩ２４３１は、端末１３から送信されたパケットをＡＰ２０が受信した際にＡＰ２０において測定されたＲＳＳＩの平均値である。
【００２３】
図８は、ログテーブル２４４の一例を示す図である。ログテーブル２４４には、例えば図８に示すように、判定結果２４４０および時刻２４４１が対応付けて格納される。判定結果２４４０は、障害原因の判定結果を示す。時刻２４４１は、判定結果２４４０がログテーブル２４４に登録された時刻を示す。
【００２４】
図９は、端末リストテーブル２４５の一例を示す図である。端末リストテーブル２４５には、例えば図９に示すように、リスト名２４５０毎に端末リスト２４５１が格納される。リスト名２４５０は、それぞれの端末リスト２４５１を識別する情報である。それぞれの端末リスト２４５１には、端末ＩＤが登録される。
【００２５】
図２に戻って説明を続ける。送信部２８は、通信制御部２１からパケットの送信を指示された場合に、パケットの送信が指示された旨を、パケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５に通知する。そして、送信部２８は、所定時間待機した後に、指示されたパケットを、アンテナ２００を介して宛先の端末１３へユニキャストにより送信する。
【００２６】
また、送信部２８は、パケットを送信してから所定時間以内に、送信したパケットの宛先の端末１３から受信部２９がＡｃｋパケットを受信しなかった場合に、パケットを再送する。そして、再送回数が所定回数（例えば５回）に達した場合、送信部２８は、パケットロスを、パケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５およびパケットロス率測定部２６に通知する。
【００２７】
受信部２９は、アンテナ２００を介してパケットを受信した場合に、受信したパケットを通信制御部２１へ出力する。また、受信部２９は、アンテナ２００を介して受信したパケットがＡｃｋパケットである場合、Ａｃｋパケットを送信した端末１３の端末ＩＤを応答時間測定部２５、パケットロス率測定部２６、および送信部２８へ出力する。また、受信部２９は、端末１３からＡｃｋパケットを受信した場合に、パケットを受信した際に測定されたＲＳＳＩを、受信したパケットの送信元の端末１３の端末ＩＤと共にＲＳＳＩ測定部２７へ送る。
【００２８】
通信制御部２１は、ネットワーク装置１２からパケットを受信した場合に、受信したパケットを送信部２８へ送り、パケットの送信を送信部２８に指示する。また、通信制御部２１は、受信部２９からパケットを受信した場合に、受信したパケットをネットワーク装置１２へ送る。また、通信制御部２１は、各端末１３がユーザデータを有するパケットの送受信を行う時間帯において、所定のタイミング毎（例えば数秒毎）に、テストパケットを生成し、送信部２８に指示して、生成したテストパケットを各端末１３へ送信させる。また、通信制御部２１は、端末特定部２３からテストパケットの送信を指示された場合に、テストパケットを生成し、送信部２８に指示して、生成したテストパケットを各端末１３へ送信させる。
【００２９】
応答時間測定部２５は、端末１３の端末ＩＤと共に、パケットの送信が指示された旨が送信部２８から通知された場合に、端末ＩＤに対応する端末１３の応答時間の測定を開始する。そして、応答時間測定部２５は、保持部２４内の測定値テーブル２４０において、端末１３の端末ＩＤに対応付けられた個別テーブルを特定する。そして、応答時間測定部２５は、特定した個別テーブルに、新たにレコードを作成する。
【００３０】
そして、応答時間測定部２５は、受信部２９から、Ａｃｋパケットを送信した端末１３の端末ＩＤを受信した場合に、端末ＩＤに対応する端末１３の応答時間を算出する。そして、応答時間測定部２５は、算出した応答時間を、測定値テーブル２４０の個別テーブル内に新たに作成したレコードに登録する。なお、応答時間測定部２５は、送信部２８からパケットロスが通知された場合、パケットロスが通知された時点までの時間を応答時間として算出し、算出した応答時間を、測定値テーブル２４０の個別テーブル内のレコードに登録する。
【００３１】
また、応答時間測定部２５は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数の応答時間を抽出し、抽出した応答時間を平均して平均応答時間を算出する。そして、応答時間測定部２５は、端末１３毎に、応答時間テーブル２４１内の平均応答時間を、算出した平均応答時間で更新する。本実施例において、応答時間測定部２５は、端末１３毎に、新しく登録された順に例えば数十個程度の応答時間を平均して平均応答時間を算出する。
【００３２】
ここで、図４に示した応答時間ｔ0の中で、所定時間ｔ1に含まれるバックオフ時間は、数μ〜数十μ秒の範囲でランダムに選択される。そのため、応答時間ｔ0は、所定の変動幅を有する。また、所定時間ｔ3に含まれる、ＡＰ２０と端末１３との間の無線通信路における往復の伝送時間は、ＡＰ２０と端末１３との位置関係や、ＡＰ２０と端末１３との間の障害物の状況等に応じて、端末１３毎に異なる。
【００３３】
そのため、本実施例では、例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、送信部２８が各端末１３にテストパケットを複数回送信し、応答時間測定部２５が各端末１３の応答時間ｔ0を測定する。そして、応答時間測定部２５は、端末１３毎に、測定した応答時間ｔ0の平均値を応答時間の基準値として応答時間テーブル２４１の基準値２４１２に登録する。また、応答時間測定部２５は、端末１３毎に、測定した応答時間ｔ0のばらつきの度合いを算出し、応答時間テーブル２４１の応答時間マージン２４１３に登録する。応答時間マージン２４１３は、応答時間ｔ0の標準偏差σや標準偏差σの２倍等の値であってもよい。
【００３４】
パケットロス率測定部２６は、Ａｃｋパケットを送信した端末１３の端末ＩＤを受信部２９から通知された場合、測定値テーブル２４０を参照して、通知された端末ＩＤに対応する個別テーブルを特定する。そして、パケットロス率測定部２６は、特定した個別テーブルにおいて、新たに作成されたレコード内のパケットロスの欄に、パケットロスが発生しなかったことを示す０を登録する。
【００３５】
一方、端末１３の端末ＩＤと共に、パケットロスが送信部２８から通知された場合、パケットロス率測定部２６は、測定値テーブル２４０を参照して、通知された端末ＩＤに対応する個別テーブルを特定する。そして、パケットロス率測定部２６は、特定した個別テーブルにおいて、新たに作成されたレコード内のパケットロスの欄に、パケットロスが発生したことを示す１を登録する。
【００３６】
また、パケットロス率測定部２６は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数のパケットロスの値を抽出し、抽出した値を平均してパケットロス率を算出する。そして、パケットロス率測定部２６は、端末１３毎に、パケットロス率テーブル２４２内のパケットロス率を、算出したパケットロス率で更新する。本実施例において、パケットロス率測定部２６は、端末１３毎に、新しく登録された順に例えば数十個程度のパケットロスの値を平均してパケットロス率を算出する。
【００３７】
ＲＳＳＩ測定部２７は、受信部２９から端末１３の端末ＩＤと共にＲＳＳＩを受信した場合に、測定値テーブル２４０を参照し、受信した端末ＩＤに対応する個別テーブルを特定する。そして、ＲＳＳＩ測定部２７は、特定した個別テーブルにおいて、新たに作成されたレコード内のＲＳＳＩの欄に、受信部２９から受信したＲＳＳＩの値を登録する。
【００３８】
また、ＲＳＳＩ測定部２７は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数のＲＳＳＩを抽出し、抽出したＲＳＳＩを平均して平均ＲＳＳＩを算出する。そして、ＲＳＳＩ測定部２７は、端末１３毎に、ＲＳＳＩテーブル２４３内の平均ＲＳＳＩを、算出した平均ＲＳＳＩで更新する。本実施例において、ＲＳＳＩ測定部２７は、端末１３毎に、新しく登録された順に例えば数十個程度のＲＳＳＩを平均して平均ＲＳＳＩを算出する。なお、平均ＲＳＳＩは、Ａｃｋパケットの他、端末１３から送信された他のパケットを受信した際に測定されたＲＳＳＩを用いて算出されてもよい。
【００３９】
端末特定部２３は、例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、通信制御部２１にテストパケットの送信を指示する。そして、各端末１３に所定数のテストパケットが送信された後に、端末特定部２３は、端末１３毎に測定値テーブル２４０内の個別テーブルを参照して、フェージングの影響を受けている可能性が高い端末１３を特定する。
【００４０】
ここで、応答時間とフェージングの関係について説明する。図１０は、応答時間の変動の一例を説明する図である。図１０（ａ）は、端末１３が干渉電波を受けておらず、かつ、フェージングによる受信電力の変動が小さい場合の応答時間の変動の一例を示す。図１０（ｂ）は、端末１３が干渉電波を受けており、かつ、フェージングによる受信電力の変動が小さい場合の応答時間の変動の一例を示す。図１０（ｃ）は、端末１３が干渉電波を受けておらず、かつ、フェージングによる受信電力の変動が大きい場合の応答時間の変動の一例を示す。
【００４１】
端末１３が干渉電波を受けると、干渉電波を受けている間に受信した信号の品質が悪化し、ＡＰ２０から送信されたテストパケットの受信に失敗する場合がある。また、フェージングによる受信電力の変動が大きい場合も、端末１３において信号の受信電力が断続的に低下し、ＡＰ２０から送信されたテストパケットの受信に失敗する場合がある。ＡＰ２０から送信されたテストパケットの受信に失敗すると、端末１３は、ＡＰ２０へＡｃｋパケットを送信しない。そのため、ＡＰ２０は、テストパケットの再送を繰り返す。これにより、例えば図１０（ｂ）および（ｃ）に示す応答時間の平均値は、図１０（ａ）に示す応答時間の平均値に比べて長くなる。
【００４２】
また、端末１３が干渉電波を受けている場合も、例えば図１０（ｂ）に示すように応答時間が長くなり、フェージングによる受信電力の変動が大きい場合も、例えば図１０（ｃ）に示すように応答時間が長くなる。そのため、応答時間が長くなったことを検出しただけでは、その原因が干渉電波によるものか、フェージングによるものかを区別することは困難である。
【００４３】
図１１は、ＲＳＳＩの変動の一例を説明する図である。図１１（ａ）は、端末１３が干渉電波を受けておらず、かつ、フェージングによる受信電力の変動が小さい場合において、ＡＰ２０が測定したＡｃｋパケットのＲＳＳＩの変動の一例を示す。図１１（ｂ）は、端末１３が干渉電波を受けており、かつ、フェージングによる受信電力の変動が小さい場合において、ＡＰ２０が測定したＡｃｋパケットのＲＳＳＩの変動の一例を示す。図１１（ｃ）は、端末１３が干渉電波を受けておらず、かつ、フェージングによる受信電力の変動が大きい場合において、ＡＰ２０が測定したＡｃｋパケットのＲＳＳＩの変動の一例を示す。
【００４４】
フェージングによる受信電力の変動が大きい場合には、例えば図１１（ｃ）に示すように、ＡＰ２０が測定したＡｃｋパケットのＲＳＳＩの変動が大きくなると共に、ＲＳＳＩの平均値が低くなる。一方、フェージングによる受信電力の変動が小さい場合には、例えば図１１（ａ）および（ｂ）に示すように、端末１３が干渉電波を受けているか否かにかかわらず、ＡＰ２０が測定したＡｃｋパケットのＲＳＳＩの変動が小さく、ＲＳＳＩの平均値も比較的高い。
【００４５】
そのため、本実施例の端末特定部２３は、平均ＲＳＳＩが所定の閾値以下の端末１３をフェージングの影響を受けている可能性が高い端末１３として特定し、特定した端末１３の端末ＩＤを、端末リストテーブル２４５内のリスト１に登録する。リスト１に端末ＩＤが登録された端末１３は、第１の端末装置の一例である。リスト１に端末ＩＤが登録された端末１３は、障害原因の判定対象から除外される。これにより、ＡＰ２０は、フェージングの影響を受けている可能性が低い端末１３を対象として障害原因の判定を行うことができ、障害原因の判定を高い精度で行うことができる。
【００４６】
ここで、端末特定部２３は、フェージングの影響を受けている可能性が高い端末１３を特定するための閾値を、例えば以下の手順で算出する。まず、端末特定部２３は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照して、ＲＳＳＩの平均値を算出し、個別テーブル内のＲＳＳＩを平均値からの相対値に置き換える。そして、端末特定部２３は、各端末１３について相対値に置き換えられたＲＳＳＩの値を１つの集合として、相対値に置き換えられたＲＳＳＩの値の分布の標準偏差σRSSIを算出する。そして、端末特定部２３は、算出した標準偏差σRSSIの所定数倍をフェージングマージンＲmとして算出する。端末特定部２３は、標準偏差σRSSIの例えば３倍をフェージングマージンＲmとして算出してもよい。そして、端末特定部２３は、ＡＰ２０の最低受信感度ＲminにフェージングマージンＲmを加えた電力の値を、閾値として算出する。
【００４７】
障害判定部２２は、所定のタイミング毎（例えば１０分毎）に、保持部２４内の各テーブルを参照して、障害原因推定処理を実行する。障害判定部２２は、障害原因推定処理において、送信部２８が送信したパケットに対する応答に異常がある端末１３が、パケットの宛先の端末１３の中の一部の端末１３である場合に、当該一部の端末１３の障害と判定する。また、障害判定部２２は、障害原因推定処理において、送信部２８が送信したパケットに対する応答に異常がある端末１３が、パケットの宛先の全ての端末１３である場合に、ＡＰ２０の障害と判定する。
【００４８】
例えば、障害判定部２２は、障害原因推定処理において、パケットロス率テーブル２４２を参照し、パケットロス率Ｐが所定の閾値Ｐth1以上である端末１３を特定する。本実施例において、所定の閾値Ｐth1は、例えば１００％である。
【００４９】
パケットロス率Ｐが閾値Ｐth1以上の端末１３が、全ての端末１３である場合、障害判定部２２は、ＡＰ２０の故障または遮蔽を障害原因として判定する。全ての端末１３とは、例えばＡＰ２０に帰属している全ての端末１３である。また、ＡＰ２０の遮蔽とは、例えば、いずれの端末１３との間においても、ＡＰ２０からの電波が通信可能な強度で端末１３に届かず、端末１３からの電波が通信可能な強度でＡＰ２０に届かない状態を指す。
【００５０】
また、パケットロス率Ｐが閾値Ｐth1以上である端末１３が、一部の端末１３である場合、障害判定部２２は、パケットロス率Ｐが閾値Ｐth1以上である端末１３の故障または遮蔽を障害原因として判定する。そして、障害判定部２２は、判定結果を、判定を行った時刻と共に、保持部２４内のログテーブル２４４に登録する。
【００５１】
図１２は、障害の一例を説明する図である。例えば図１２に示すように、ＡＰ２０と端末１３−１との間に、遮蔽物３０が存在する場合、ＡＰ２０からの電波が通信可能な強度で端末１３−１に届かない。端末１３−１は、ＡＰ２０から送信されたパケットの受信に失敗するため、Ａｃｋパケットの送信を行わない。ＡＰ２０は、端末１３−１へ送信したパケットに対するＡｃｋパケットを受信しないため、端末１３−１に対してパケットの再送を繰り返す。そして、所定回数のパケットの再送を行っても端末１３−１からＡｃｋパケットを受信しない場合、ＡＰ２０は、端末１３−１についてパケットロスを検出する。これにより、端末１３−１のパケットロス率Ｐが閾値Ｐth1以上となる。
【００５２】
また、例えば図１２に示すように、端末１３−２が故障している場合、ＡＰ２０から送信されたパケットが、通信可能な電波強度で端末１３−２に届いたとしても、端末１３−２は、Ａｃｋパケットを返さない。そのため、ＡＰ２０は、端末１３−２に対してパケットの再送を繰り返し、パケットロスを検出する。これにより、端末１３−２のパケットロス率Ｐが閾値Ｐth1以上となる。
【００５３】
ここで、ＡＰ２０に帰属している端末１３の中に、パケットロス率Ｐが閾値Ｐth1未満となる端末１３−３が１つでも存在すれば、ＡＰ２０の故障または遮蔽ではないと判定することができる。また、ＡＰ２０の送信部２８が故障している場合、全ての端末１３に対してパケットが送信されない。また、ＡＰ２０が遮蔽物で遮蔽されている場合、送信されたパケットは、いずれの端末１３においても受信されない。また、ＡＰ２０の受信部２９が故障している場合には、ＡＰ２０の送信部２８がパケットを送信したとしても、いずれの端末１３から送信されたＡｃｋパケットの受信にも失敗する。そのため、ＡＰ２０が故障している、または、遮蔽されている場合には、全ての端末１３のパケットロス率Ｐが閾値Ｐth1以上となる。
【００５４】
ここで、全ての端末１３のパケットロス率Ｐが閾値Ｐth1以上になった場合、全ての端末１３が同時に故障したり遮蔽されることも考えられる。しかし、全ての端末１３が同時に故障したり遮蔽される確率は、１つのＡＰ２０が故障したり遮蔽される確率よりもずっと小さい。そのため、本実施例では、全ての端末１３のパケットロス率Ｐが閾値Ｐth1以上になった場合、障害判定部２２は、ＡＰ２０の故障または遮蔽を障害原因として判定する。
【００５５】
このように、ＡＰ２０から送信されたパケットに対する応答に異常があった端末１３が、全ての端末１３か否かを判定することにより、障害判定部２２は、端末１３の障害か、ＡＰ２０の障害かを切り分けることができる。これにより、ＡＰ２０は、端末１３に特別な測定機能が設けられていない場合であっても、端末１３の障害か、ＡＰ２０の障害かを切り分けることができる。
【００５６】
また、障害判定部２２は、障害原因推定処理において、ＡＰ２０の故障または遮蔽ではないと判定した場合、パケットロス率Ｐが閾値Ｐth1未満の端末１３の中から、端末リストテーブル２４５のリスト１内に端末ＩＤが登録されている端末１３を除外する。そして、障害判定部２２は、残った端末１３の端末ＩＤを、端末リストテーブル２４５のリスト４内に登録する。
【００５７】
そして、障害判定部２２は、応答時間テーブル２４１を参照し、リスト４内に端末ＩＤが登録されている端末１３の中で、平均応答時間が所定値よりも大きい端末１３を特定する。そして、障害判定部２２は、特定した端末１３が、リスト４内に端末ＩＤが登録されている端末１３の数の所定割合以上（例えば９０％以上）である場合に、ＡＰ２０が干渉を受けていることを障害原因として判定する。一方、特定した端末１３が、リスト４内に端末ＩＤが登録されている端末１３の数の所定割合未満である場合、障害判定部２２は、特定した端末１３が干渉を受けていることを障害原因として判定する。そして、障害判定部２２は、判定結果を、判定を行った時刻と共に、保持部２４内のログテーブル２４４に登録する。
【００５８】
このように、本実施例のＡＰ２０は、端末１３に特別な測定機能が設けられていない場合であっても、干渉電波の影響を受けている装置が、ＡＰ２０と端末１３のいずれであるのかを切り分ける等の障害原因の判定を行うことができる。また、いずれかの端末１３が干渉電波の影響を受けている場合、ＡＰ２０は、端末１３に特別な測定機能が設けられていない場合であっても、干渉電波の影響を受けている端末１３を特定することができる。これにより、干渉電波の影響を受けている端末１３やＡＰ２０の配置から、干渉源の位置を特定することも可能となる。また、本実施例の障害判定部２２は、フェージングの影響を受けている可能性が高い端末１３として、リスト１に端末ＩＤが登録された端末１３を、障害原因の判定対象から除外する。これにより、障害判定部２２は、フェージングの影響を受けている可能性が低い端末１３を対象として障害原因の判定を行うことができ、障害原因の判定精度を向上させることができる。
【００５９】
［シミュレーション結果］
図１３は、シミュレーション結果の一例を示す図である。図１３（ａ）は、フェージングの影響を考慮しない場合の判定結果の正解率を示す。図１３（ｂ）は、フェージングの影響を受けている可能性が高い端末１３を除外した場合の判定結果の正解率を示す。図１３において、横軸は干渉電波のトラフィック密度を示しており、縦軸は判定結果の正解率を示している。シミュレーションでは、ＡＰ２０のみが干渉電波を受けている状況を設定しているため、ＡＰ２０が干渉電波を受けていると判定された場合に、判定結果が正解となる。
【００６０】
図１３（ａ）および（ｂ）に示すように、フェージングの影響を受けている可能性が高い端末１３を除外することにより、判定結果の正解率が全体的に上昇している。従って、フェージングの影響を受けている可能性が低い端末１３を対象として障害原因の判定を行うことにより、障害原因の判定精度を向上させることができる。
【００６１】
［基準値作成処理］
図１４は、基準値作成処理の一例を示すフローチャートである。例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、ＡＰ２０は、本フローチャートに示す基準値作成処理を実行する。
【００６２】
まず、端末特定部２３は、通信制御部２１にテストパケットの送信を指示する。通信制御部２１は、ＡＰ２０に帰属中の端末１３の中で、未選択の端末１３を１つ選択する（Ｓ１００）。そして、通信制御部２１は、選択した端末１３宛のテストパケットを生成し、生成したテストパケットの送信を送信部２８に指示する。なお、選択した端末１３宛のパケットをネットワーク装置１２から受信した場合、通信制御部２１は、テストパケットに代えて、ネットワーク装置１２から受信したパケットの送信を送信部２８に指示してもよい。
【００６３】
送信部２８は、パケットの送信が指示された旨を、パケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５に通知する。そして、送信部２８は、通信制御部２１から指示された端末１３へ、テストパケットを送信する（Ｓ１０１）。そして、受信部２９は、テストパケットが送信されてから所定時間以内に、テストパケットに対するＡｃｋパケットを受信したか否かを判定する（Ｓ１０２）。
【００６４】
テストパケットが送信されてから所定時間以内にＡｃｋパケットを受信した場合（Ｓ１０２：Ｙｅｓ）、受信部２９は、Ａｃｋパケットを送信した端末１３の端末ＩＤを応答時間測定部２５、パケットロス率測定部２６、および送信部２８へ送る。また、受信部２９は、受信したＡｃｋパケットの送信元の端末１３の端末ＩＤと共に、パケットを受信した際に測定されたＲＳＳＩをＲＳＳＩ測定部２７へ送る。そして、ステップＳ１００で選択された端末１３に対応する測定値テーブル２４０内の個別テーブルに、各測定値が登録される（Ｓ１０５）。具体的には、応答時間測定部２５は、測定した応答時間を個別テーブルに登録する。また、パケットロス率測定部２６は、パケットロスが発生しなかったことを示す０を個別テーブルに登録する。また、ＲＳＳＩ測定部２７は、ＲＳＳＩの値を個別テーブルに登録する。そして、通信制御部２１は、ステップＳ１０６に示す処理を実行する。
【００６５】
テストパケットが送信されてから所定時間以内に、テストパケットに対するＡｃｋパケットを受信部２９が受信しなかった場合（Ｓ１０２：Ｎｏ）、送信部２８は、再送回数を１増やす（Ｓ１０３）。そして、送信部２８は、再送回数が所定回数以上か否かを判定する（Ｓ１０４）。再送回数が所定回数未満である場合（Ｓ１０４：Ｎｏ）、送信部２８は、ステップＳ１０１において、通信制御部２１から指示された端末１３へ、再びテストパケットを送信する。
【００６６】
一方、再送回数が所定回数以上である場合（Ｓ１０４：Ｙｅｓ）、送信部２８は、テストパケットのパケットロスを、テストパケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５に通知する。そして、ステップＳ１００で選択された端末１３に対応する測定値テーブル２４０内の個別テーブルに、各測定値が登録される（Ｓ１０５）。具体的には、応答時間測定部２５は、パケットロスが通知された時点までの時間を応答時間として個別テーブルに登録する。また、パケットロス率測定部２６は、パケットロスが発生したことを示す１を個別テーブルに登録する。
【００６７】
次に、通信制御部２１は、テストパケットを所定回数送信したか否かを判定する（Ｓ１０６）。本実施例において、通信制御部２１は、各端末１３に対してテストパケットを例えば数十回程度送信する。テストパケットを所定回数送信していない場合（Ｓ１０６：Ｎｏ）、通信制御部２１は、再びステップＳ１０１に示した処理を実行する。
【００６８】
一方、テストパケットを所定回数送信した場合（Ｓ１０６：Ｙｅｓ）、通信制御部２１は、ＡＰ２０に帰属中の全ての端末１３を選択したか否かを判定する（Ｓ１０７）。未選択の端末１３がある場合（Ｓ１０７：Ｎｏ）、通信制御部２１は、ステップＳ１００に示した処理を実行する。
【００６９】
一方、ＡＰ２０に帰属中の全ての端末１３が選択された場合（Ｓ１０７：Ｙｅｓ）、応答時間測定部２５は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照して、応答時間を平均することにより応答時間の基準値を算出する（Ｓ１０８）。また、応答時間測定部２５は、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照して、応答時間のばらつきの度合いを応答時間マージンとして算出する（Ｓ１０８）。そして、応答時間測定部２５は、端末１３毎に、算出した基準値および応答時間マージンを、端末ＩＤに対応付けて応答時間テーブル２４１に登録する。そして、端末特定部２３は、後述する除外端末特定処理を実行する（Ｓ１０９）。そして、ＡＰ２０は、本フローチャートに示した基準値作成処理を終了する。
【００７０】
［除外端末特定処理］
図１５は、実施例１における除外端末特定処理の一例を示すフローチャートである。
【００７１】
まず、端末特定部２３は、フェージングマージンＲmを算出する（Ｓ２００）。端末特定部２３は、例えば、端末１３毎に、測定値テーブル２４０内の個別テーブルを参照して、ＲＳＳＩの平均値を算出し、個別テーブル内のＲＳＳＩを平均値からの相対値に置き換える。そして、端末特定部２３は、各端末１３について相対値に置き換えられたＲＳＳＩの値を１つの集合として、相対値に置き換えられたＲＳＳＩの値の分布の標準偏差σRSSIを算出する。そして、端末特定部２３は、算出した標準偏差σRSSIの所定数倍をフェージングマージンＲmとして算出する。
【００７２】
次に、端末特定部２３は、変数ｉの値を０に初期化し、ＡＰ２０に帰属している端末１３の数を定数Ｎ0にセットする（Ｓ２０１）。そして、端末特定部２３は、端末リストテーブル２４５のリスト１内の端末ＩＤを全て削除する（Ｓ２０２）。そして、端末特定部２３は、変数ｉの値が定数Ｎ0未満か否かを判定する（Ｓ２０３）。変数ｉの値が定数Ｎ0以上である場合（Ｓ２０３：Ｎｏ）、ＡＰ２０は、本フローチャートに示す除外端末特定処理を終了する。
【００７３】
変数ｉの値が定数Ｎ0未満である場合（Ｓ２０３：Ｙｅｓ）、端末特定部２３は、保持部２４内のＲＳＳＩテーブル２４３を参照して、ｉ番目の端末１３の平均ＲＳＳＩであるＲ（ｉ）を取得する（Ｓ２０４）。そして、端末特定部２３は、取得した平均ＲＳＳＩであるＲ（ｉ）が、ＡＰ２０の最低受信感度ＲminにフェージングマージンＲmを加えた値以下であるか否かを判定する（Ｓ２０５）。Ｒ（ｉ）が最低受信感度ＲminにフェージングマージンＲmを加えた値より大きい場合（Ｓ２０５：Ｎｏ）、端末特定部２３は、ステップＳ２０７に示す処理を実行する。
【００７４】
Ｒ（ｉ）が最低受信感度ＲminにフェージングマージンＲmを加えた値以下である場合（Ｓ２０５：Ｙｅｓ）、端末特定部２３は、ｉ番目の端末１３の端末ＩＤを端末リストテーブル２４５のリスト１内に登録する（Ｓ２０６）。そして、端末特定部２３は、変数ｉの値を１増やし（Ｓ２０７）、再びステップＳ２０３に示した処理を実行する。図１５に示した除外端末特定処理が実行されることにより、リスト１内には、フェージングの影響を受けている可能性が高い端末１３の端末ＩＤが登録される。
【００７５】
［測定処理］
図１６は、測定処理の一例を示すフローチャートである。ＡＰ２０は、例えば所定のタイミング毎（例えば数秒毎）に、本フローチャートに示す測定処理を実行する。
【００７６】
まず、通信制御部２１は、ＡＰ２０に帰属中の端末１３の中で、未選択の端末１３を１つ選択する（Ｓ３００）。そして、通信制御部２１は、選択した端末１３宛のテストパケットを生成し、生成したテストパケットの送信を送信部２８に指示する。なお、選択した端末１３宛のパケットをネットワーク装置１２から受信した場合、通信制御部２１は、テストパケットに代えて、ネットワーク装置１２から受信したパケットの送信を送信部２８に指示してもよい。
【００７７】
送信部２８は、テストパケットの送信が指示された旨を、テストパケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５に通知する。そして、送信部２８は、通信制御部２１から指示された端末１３へ、テストパケットを送信する（Ｓ３０１）。
【００７８】
次に、受信部２９は、テストパケットが送信されてから所定時間以内に、テストパケットに対するＡｃｋパケットを受信したか否かを判定する（Ｓ３０２）。テストパケットが送信されてから所定時間以内にＡｃｋパケットを受信した場合（Ｓ３０２：Ｙｅｓ）、受信部２９は、Ａｃｋパケットを送信した端末１３の端末ＩＤを応答時間測定部２５、パケットロス率測定部２６、および送信部２８に通知する。また、受信部２９は、受信したＡｃｋパケットの送信元の端末１３の端末ＩＤと共に、パケットを受信した際に測定されたＲＳＳＩをＲＳＳＩ測定部２７に通知する。そして、ステップＳ３００で選択された端末１３に対応する測定値テーブル２４０内の個別テーブルに、各測定値が登録される（Ｓ３０５）。具体的には、応答時間測定部２５は、測定した応答時間を個別テーブルに登録する。また、パケットロス率測定部２６は、パケットロスが発生しなかったことを示す０を個別テーブルに登録する。また、ＲＳＳＩ測定部２７は、ＲＳＳＩの値を個別テーブルに登録する。そして、応答時間測定部２５は、ステップＳ３０６に示す処理を実行する。
【００７９】
テストパケットが送信されてから所定時間以内に、テストパケットに対するＡｃｋパケットを受信部２９が受信しなかった場合（Ｓ３０２：Ｎｏ）、送信部２８は、再送回数を１増やす（Ｓ３０３）。そして、送信部２８は、再送回数が所定回数以上か否かを判定する（Ｓ３０４）。再送回数が所定回数未満である場合（Ｓ３０４：Ｎｏ）、送信部２８は、ステップＳ３０１において、通信制御部２１から指示された端末１３へ、再びテストパケットを送信する。
【００８０】
一方、再送回数が所定回数以上である場合（Ｓ３０４：Ｙｅｓ）、送信部２８は、テストパケットのパケットロスを、テストパケットの宛先の端末１３の端末ＩＤと共に、応答時間測定部２５およびパケットロス率測定部２６に通知する。そして、ステップＳ３００で選択された端末１３に対応する測定値テーブル２４０内の個別テーブルに、各測定値が登録される（Ｓ３０５）。具体的には、応答時間測定部２５は、パケットロスが通知された時点までの時間を応答時間として個別テーブルに登録する。また、パケットロス率測定部２６は、パケットロスが発生したことを示す１を個別テーブルに登録する。
【００８１】
次に、応答時間測定部２５は、ステップＳ３００で選択された端末１３について、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数の応答時間を平均して平均応答時間を算出する。そして、応答時間測定部２５は、応答時間テーブル２４１において、ステップＳ３００で選択された端末１３の端末ＩＤに対応付けられている平均応答時間を、算出した平均応答時間で更新する（Ｓ３０６）。
【００８２】
次に、パケットロス率測定部２６は、ステップＳ３００で選択された端末１３について、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数のパケットロスの値を平均してパケットロス率を算出する。そして、パケットロス率測定部２６は、パケットロス率テーブル２４２において、ステップＳ３００で選択された端末１３の端末ＩＤに対応付けられているパケットロス率を、算出したパケットロス率で更新する（Ｓ３０７）。
【００８３】
次に、ＲＳＳＩ測定部２７は、ステップＳ３００で選択された端末１３について、測定値テーブル２４０内の個別テーブルを参照し、新しく登録された順に所定数のＲＳＳＩを平均して平均ＲＳＳＩを算出する。そして、ＲＳＳＩ測定部２７は、ＲＳＳＩテーブル２４３において、ステップＳ３００で選択された端末１３の端末ＩＤに対応付けられている平均ＲＳＳＩを、算出した平均ＲＳＳＩで更新する（Ｓ３０８）。
【００８４】
次に、通信制御部２１は、ＡＰ２０に帰属中の全ての端末１３を選択したか否かを判定する（Ｓ３０９）。未選択の端末１３がある場合（Ｓ３０９：Ｎｏ）、通信制御部２１は、再びステップＳ３００に示した処理を実行する。一方、全ての端末１３を選択した場合（Ｓ３０９：Ｙｅｓ）、ＡＰ２０は、本フローチャートに示した測定処理を終了する。
【００８５】
［障害原因推定処理］
図１７は、実施例１における障害原因推定処理の一例を示すフローチャートである。ＡＰ２０は、例えば各端末１３がユーザデータを有するパケットの送受信を行う時間帯において、例えば所定のタイミング毎（例えば１０分毎）に、本フローチャートに示す障害原因推定処理を実行する。
【００８６】
まず、ＡＰ２０は、後述する遮蔽・故障診断処理を実行する（Ｓ４００）。そして、ＡＰ２０は、ＡＰ２０の遮蔽または故障が判定されたか否かを判定する（Ｓ４０１）。ＡＰ２０の遮蔽または故障が判定された場合（Ｓ４０１：Ｙｅｓ）、ＡＰ２０の遮蔽または故障を障害原因とする判定結果を、判定を行った時刻と共に、保持部２４内のログテーブル２４４に登録する（Ｓ４０３）。そして、ＡＰ２０は、本フローチャートに示した障害原因推定処理を終了する。
【００８７】
一方、ＡＰ２０の遮蔽および故障が判定されていない場合（Ｓ４０１：Ｎｏ）、ＡＰ２０は、後述する干渉診断処理を実行する（Ｓ４０２）。そして、ＡＰ２０は、干渉診断処理によって判定された結果を障害原因として、判定を行った時刻と共に、保持部２４内のログテーブル２４４に登録する（Ｓ４０３）。そして、ＡＰ２０は、本フローチャートに示した障害原因推定処理を終了する。
【００８８】
［遮蔽・故障診断処理］
図１８は、遮蔽・故障診断処理の一例を示すフローチャートである。
【００８９】
まず、障害判定部２２は、変数ｉの値を０に初期化し、ＡＰ２０に帰属している端末１３の数を定数Ｎ0にセットする（Ｓ５００）。そして、障害判定部２２は、端末リストテーブル２４５のリスト２内の端末ＩＤを削除し、リスト３内の端末ＩＤを削除する（Ｓ５０１）。そして、障害判定部２２は、変数ｉの値が定数Ｎ0未満か否かを判定する（Ｓ５０２）。
【００９０】
変数ｉの値が定数Ｎ0未満である場合（Ｓ５０２：Ｙｅｓ）、障害判定部２２は、保持部２４内のパケットロス率テーブル２４２を参照し、ＡＰ２０に帰属している端末１３の中でｉ番目の端末１３のパケットロス率Ｐ（ｉ）を取得する（Ｓ５０３）。そして、障害判定部２２は、取得したパケットロス率Ｐ（ｉ）が、予め定められた閾値Ｐth1以上であるか否かを判定する（Ｓ５０４）。本実施例において、閾値Ｐth1は、例えば１００％である。
【００９１】
パケットロス率Ｐ（ｉ）が閾値Ｐth1以上である場合（Ｓ５０４：Ｙｅｓ）、障害判定部２２は、ｉ番目の端末１３の端末ＩＤを、故障または遮蔽が疑われる端末１３のリストであるリスト２に登録する（Ｓ５０５）。一方、パケットロス率Ｐ（ｉ）が閾値Ｐth1未満である場合（Ｓ５０４：Ｎｏ）、障害判定部２２は、ｉ番目の端末１３の端末ＩＤを、干渉の診断対象の候補となる端末１３のリストであるリスト３に登録する（Ｓ５０６）。そして、障害判定部２２は、変数ｉの値を１増やし（Ｓ５０７）、再びステップＳ５０２に示した処理を実行する。
【００９２】
変数ｉの値が定数Ｎ0以上である場合（Ｓ５０２：Ｎｏ）、障害判定部２２は、リスト２内に端末ＩＤが登録された端末１３の数を定数Ｎ2にセットする（Ｓ５０８）。そして、障害判定部２２は、定数Ｎ2の値が、ＡＰ２０に帰属している端末１３の数を示す定数Ｎ0の値と等しいか否かを判定する（Ｓ５０９）。定数Ｎ2の値と定数Ｎ0の値とが等しい場合（Ｓ５０９：Ｙｅｓ）、即ち、ＡＰ２０に帰属している全ての端末１３のパケットロス率Ｐ（ｉ）が閾値Ｐth1以上である場合、障害判定部２２は、ＡＰ２０の故障または遮蔽と判定する（Ｓ５１０）。これにより、図１７に示したステップＳ４０３において、ＡＰ２０の故障または遮蔽を障害原因とする判定結果が保持部２４内のログテーブル２４４に登録される。そして、障害判定部２２は、本フローチャートに示した遮蔽・故障診断処理を終了する。
【００９３】
一方、定数Ｎ2の値と定数Ｎ0の値とが異なる場合（Ｓ５０９：Ｎｏ）、障害判定部２２は、定数Ｎ2の値が１以上か否かを判定する（Ｓ５１１）。定数Ｎ2の値が０である場合（Ｓ５１１：Ｎｏ）、即ち、パケットロス率Ｐ（ｉ）が閾値Ｐth1以上の端末１３が１台も存在しない場合、障害判定部２２は、本フローチャートに示した遮蔽・故障診断処理を終了する。一方、定数Ｎ2が１以上である場合（Ｓ５１１：Ｙｅｓ）、即ち、一部の端末１３のパケットロス率Ｐ（ｉ）が閾値Ｐth1以上である場合、障害判定部２２は、リスト２内に端末ＩＤが登録された端末１３の故障または遮蔽と判定する（Ｓ５１２）。これにより、図１７に示したステップＳ４０３において、リスト２内に登録されている端末ＩＤと共に、端末１３の故障または遮蔽を障害原因とする判定結果が保持部２４内のログテーブル２４４に登録される。
【００９４】
［干渉診断処理］
図１９は、干渉診断処理の一例を示すフローチャートである。
【００９５】
まず、障害判定部２２は、端末リストテーブル２４５のリスト４内の端末ＩＤを削除し、端末リストテーブル２４５のリスト５内の端末ＩＤを削除する（Ｓ６００）。そして、障害判定部２２は、端末リストテーブル２４５のリスト３内に端末ＩＤが登録された端末１３の中から、端末リストテーブル２４５のリスト１内に端末ＩＤが登録された端末１３を除外する。そして、障害判定部２２は、残った端末１３の端末ＩＤをリスト４に登録する（Ｓ６０１）。そして、障害判定部２２は、変数ｉの値を０に初期化し、リスト４内に端末ＩＤが登録された端末１３の数を定数Ｎ4にセットする（Ｓ６０２）。
【００９６】
次に、障害判定部２２は、変数ｉの値が定数Ｎ4未満か否かを判定する（Ｓ６０３）。変数ｉの値が定数Ｎ4未満である場合（Ｓ６０３：Ｙｅｓ）、障害判定部２２は、応答時間テーブル２４１を参照し、リスト４内のｉ番目の端末１３の平均応答時間Ｄ（ｉ）、基準値Ｄr（ｉ）、および応答時間マージンＤm（ｉ）を取得する（Ｓ６０４）。そして、障害判定部２２は、平均応答時間Ｄ（ｉ）が、基準値Ｄr（ｉ）と応答時間マージンＤm（ｉ）とを合計した時間よりも長いか否かを判定する（Ｓ６０５）。
【００９７】
平均応答時間Ｄ（ｉ）が、基準値Ｄr（ｉ）と応答時間マージンＤm（ｉ）とを合計した時間以下である場合（Ｓ６０５：Ｎｏ）、障害判定部２２は、変数ｉの値を１増やし（Ｓ６０７）、再びステップＳ６０３に示した処理を実行する。一方、平均応答時間Ｄ（ｉ）が、基準値Ｄr（ｉ）と応答時間マージンＤm（ｉ）とを合計した時間よりも長い場合（Ｓ６０５：Ｙｅｓ）、障害判定部２２は、ｉ番目の端末１３の端末ＩＤをリスト５に登録する（Ｓ６０６）。リスト５は、干渉が疑われる端末１３のリストである。そして、障害判定部２２は、ステップＳ６０７に示した処理を実行する。
【００９８】
変数ｉの値が定数Ｎ4以上である場合（Ｓ６０３：Ｎｏ）、障害判定部２２は、リスト５内に端末ＩＤが登録された端末１３の数を定数Ｎ5にセットする（Ｓ６０８）。そして、障害判定部２２は、定数Ｎ5が０であるか否かを判定する（Ｓ６０９）。定数Ｎ5が０である場合（Ｓ６０９：Ｙｅｓ）、即ち、干渉が疑われる端末１３が存在しない場合、障害判定部２２は、前述の遮蔽・故障診断処理において、既に何らかの障害が判定されているか否かを判定する（Ｓ６１０）。
【００９９】
既に何らかの障害が判定されている場合（Ｓ６１０：Ｙｅｓ）、障害判定部２２は、本フローチャートに示した干渉診断処理を終了する。一方、障害が判定されていない場合（Ｓ６１０：Ｎｏ）、障害判定部２２は、異常なしと判定する（Ｓ６１１）。これにより、図１７に示したステップＳ４０３において、異常なしが判定結果として保持部２４内のログテーブル２４４に登録される。そして、ＡＰ２０は、本フローチャートに示した干渉診断処理を終了する。
【０１００】
一方、定数Ｎ5が０ではない場合（Ｓ６０９：Ｎｏ）、即ち、干渉が疑われる端末１３が存在する場合、障害判定部２２は、定数Ｎ5が、定数Ｎ4に所定の定数αを乗じた値以上か否かを判定する（Ｓ６１２）。所定の定数αは、１より小さい値であり、例えば０．９である。定数Ｎ5が、定数Ｎ4に所定の定数αを乗じた値以上である場合（Ｓ６１２：Ｙｅｓ）、障害判定部２２は、ＡＰ２０が干渉を受けていると判定する（Ｓ６１３）。これにより、図１７に示したステップＳ４０３において、ＡＰ２０が干渉を受けている旨を示す障害原因が判定結果として保持部２４内のログテーブル２４４に登録される。そして、ＡＰ２０は、本フローチャートに示した干渉診断処理を終了する。
【０１０１】
一方、定数Ｎ5が、定数Ｎ4に所定の定数αを乗じた値未満である場合（Ｓ６１２：Ｎｏ）、障害判定部２２は、リスト５に端末ＩＤが登録されている端末１３が干渉を受けていると判定する（Ｓ６１４）。これにより、図１７に示したステップＳ４０３において、リスト５に登録されている端末ＩＤと共に、端末１３が干渉を受けている旨を示す障害原因が判定結果として保持部２４内のログテーブル２４４に登録される。そして、ＡＰ２０は、本フローチャートに示した干渉診断処理を終了する。
【０１０２】
［実施例１の効果］
上述したように、本実施例のＡＰ２０は、端末特定部２３と、障害判定部２２とを備える。端末特定部２３は、端末１３との間の通信状況に基づいて、フェージングの影響を受けている端末１３を特定する。障害判定部２２は、端末特定部２３によって特定された端末１３を除く端末１３について、該端末１３へパケットを送信してから該パケットに対するＡｃｋパケットを受信するまでの応答時間に基づいて、ＡＰ２０が干渉を受けているか否かを判定する。本実施例のＡＰ２０によれば、端末１３に特別な測定機能が設けられていない場合であっても、干渉電波の影響を受けている装置がＡＰ２０と端末１３のいずれであるか等の障害原因の判定を行うことができる。また、本実施例のＡＰ２０は、フェージングの影響を受けている可能性が高い端末１３を、障害原因の判定対象から除外するため、フェージングの影響を受けている可能性が低い端末１３を対象として障害原因の判定を行うことができる。これにより、障害原因の判定精度を向上させることができる。
【０１０３】
また、本実施例のＡＰ２０は、例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、各端末１３へテストパケットを送信し、端末１３から受信したＡｃｋパケットのＲＳＳＩを測定する。そして、ＡＰ２０は、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下である端末１３をフェージングの影響を受けている端末１３として特定する。これにより、ＡＰ２０は、フェージングの影響を受けている可能性が高い端末１３を精度よく特定することができる。
【０１０４】
また、本実施例のＡＰ２０は、最低受信感度Ｒminよりも、フェージングマージンＲm分高い電力を閾値として、Ａｃｋパケットの平均ＲＳＳＩが閾値以下である端末１３をフェージングの影響を受けている端末１３として特定する。これにより、ＡＰ２０は、フェージングの影響を受けている可能性が高い端末１３を精度よく特定することができる。
【実施例２】
【０１０５】
実施例１におけるＡＰ２０は、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下である端末１３を、フェージングの影響を受けている端末１３として、障害原因の判定対象から除外した。これに対し、本実施例におけるＡＰ２０は、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下であっても、パケットロス率が所定値未満の端末１３を、障害原因の判定対象に加える点が異なる。
【０１０６】
ＡＰ２０から遠い位置にある端末１３からＡｃｋパケットが送信された場合、ＡＰ２０において測定されるＡｃｋパケットのＲＳＳＩは低い。しかし、ＡＰ２０から遠い位置にある端末１３であっても、フェージングの影響を受けていなければ、ＡＰ２０から送信されたパケットが端末１３において受信され、端末１３から送信されたＡｃｋパケットがＡＰ２０において受信される。そのため、フェージングの影響を受けていなければ、ＡＰ２０から遠い位置にある端末１３であっても、パケットロスと判定される頻度が低くなる。
【０１０７】
そこで、本実施例では、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下であり、かつ、パケットロス率が所定値以上の端末１３が、障害原因の判定対象から除外される。これにより、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下であっても、パケットロス率が所定値未満の端末１３は、障害原因の判定対象に加えられる。これにより、ＡＰ２０に帰属しているより多くの端末１３を対象として障害原因を判定することができるため、障害原因の判定精度をさらに向上させることができる。
【０１０８】
なお、本実施例において、ＡＰ２０が有する各機能ブロックは、以下に説明する点を除き、図２を用いて説明した実施例１のＡＰ２０が有する各機能ブロックと同様であるため、詳細な説明は省略する。また、本実施例の基準値作成処理および除外端末特定処理は、図１４および図１５を用いてそれぞれ説明した実施例１の基準値作成処理および除外端末特定処理と同様であるため、詳細な説明は省略する。また、本実施例の測定処理および遮断・故障診断処理は、図１６および図１８を用いてそれぞれ説明した実施例１の測定処理および遮断・故障診断処理と同様であるため、詳細な説明は省略する。また、本実施例の干渉診断処理は、図１９を用いて説明した実施例１の干渉診断処理と同様であるため、詳細な説明は省略する。
【０１０９】
［障害原因推定処理］
図２０は、実施例２における障害原因推定処理の一例を示すフローチャートである。なお、図２０に示したフローチャートにおいて、図１７に示した実施例１の障害原因推定処理と同様の処理については、同一の符号を付し、詳細な説明を省略する。
【０１１０】
まず、ＡＰ２０は、図１８を用いて説明した遮蔽・故障診断処理を実行する（Ｓ４００）。そして、ＡＰ２０は、ＡＰ２０の遮蔽または故障が検出されたか否かを判定する（Ｓ４０１）。ＡＰ２０の遮蔽または故障が検出された場合（Ｓ４０１：Ｙｅｓ）、ＡＰ２０の遮蔽または故障を障害原因とする判定結果を、判定を行った時刻と共に、保持部２４内のログテーブル２４４に登録する（Ｓ４０３）。そして、ＡＰ２０は、本フローチャートに示した障害原因推定処理を終了する。
【０１１１】
一方、ＡＰ２０の遮蔽および故障が検出されていない場合（Ｓ４０１：Ｎｏ）、端末特定部２３は、変数ｉの値を０に初期化し、リスト１内に端末ＩＤが登録された端末１３の数を定数Ｎ1にセットする（Ｓ４１０）。そして、端末特定部２３は、変数ｉの値が定数Ｎ1未満か否かを判定する（Ｓ４１１）。
【０１１２】
変数ｉの値が定数Ｎ1以上である場合（Ｓ４１１：Ｎｏ）、障害判定部２２は、図１９を用いて説明した干渉診断処理を実行する（Ｓ４０２）。一方、変数ｉの値が定数Ｎ1未満である場合（Ｓ４１１：Ｙｅｓ）、端末特定部２３は、保持部２４内のパケットロス率テーブル２４２を参照し、リスト１内のｉ番目の端末１３のパケットロス率Ｐ（ｉ）を取得する（Ｓ４１２）。そして、端末特定部２３は、取得したパケットロス率Ｐ（ｉ）が、予め定められた閾値Ｐth2未満であるか否かを判定する（Ｓ４１３）。本実施例において、閾値Ｐth2は、例えば１０％である。
【０１１３】
パケットロス率Ｐ（ｉ）が閾値Ｐth2未満である場合（Ｓ４１３：Ｙｅｓ）、端末特定部２３は、ｉ番目の端末１３の端末ＩＤを、リスト１から削除する（Ｓ４１４）。そして、端末特定部２３は、変数ｉの値を１増やし（Ｓ４１５）、再びステップＳ４１１に示した処理を実行する。一方、パケットロス率Ｐ（ｉ）が閾値Ｐth2以上である場合（Ｓ４１３：Ｎｏ）、端末特定部２３は、ステップＳ４１５に示した処理を実行する。
【０１１４】
［実施例２の効果］
上述したように、本実施例のＡＰ２０は、例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、端末１３へテストパケットを送信し、該端末１３から受信したＡｃｋパケットのＲＳＳＩを測定する。そして、ＡＰ２０は、測定したＲＳＳＩの平均値が所定の閾値以下である端末１３を特定する。そして、ＡＰ２０は、特定した端末１３の中で、各端末１３がユーザデータを有するパケットの送受信を行う時間帯におけるパケットのロス率が所定値以上である端末１３を、フェージングの影響を受けている端末１３として特定する。これにより、ＡＰ２０は、フェージングの影響を受けている可能性が高い端末１３を精度よく特定することができると共に、より多くの端末１３を対象として障害原因を判定することができる。そのため、障害原因の判定精度をさらに向上させることができる。
【実施例３】
【０１１５】
実施例１におけるＡＰ２０は、Ａｃｋパケットの平均ＲＳＳＩが所定の閾値以下である端末１３を、フェージングの影響を受けている端末１３として、障害原因の判定対象から除外した。これに対し、本実施例におけるＡＰ２０は、Ａｃｋパケットの応答時間のばらつきの度合いが、干渉により変動する応答時間のばらつきの期待値よりも大きい端末１３を、フェージングの影響を受けている端末１３として、障害原因の判定対象から除外する。これにより、フェージングなど干渉以外の要因により応答時間が変動している端末１３を、障害原因の判定対象から除外することができ、障害原因の判定精度を向上させることができる。
【０１１６】
なお、本実施例において、ＡＰ２０が有する各機能ブロックは、以下に説明する点を除き、図２を用いて説明した実施例１のＡＰ２０が有する各機能ブロックと同様であるため、詳細な説明は省略する。また、本実施例の基準値作成処理および測定処理は、図１４および図１６を用いてそれぞれ説明した実施例１の基準値作成処理および測定処理と同様であるため、詳細な説明は省略する。また、本実施例の障害原因推定処理および遮断・故障診断処理は、図１７および図１８を用いてそれぞれ説明した実施例１の障害原因推定処理および遮断・故障診断処理と同様であるため、詳細な説明は省略する。また、本実施例の干渉診断処理は、図１９を用いて説明した実施例１の干渉診断処理と同様であるため、詳細な説明は省略する。
【０１１７】
［除外端末特定処理］
図２１は、実施例３における除外端末特定処理の一例を示すフローチャートである。
【０１１８】
まず、端末特定部２３は、変数ｉの値を０に初期化し、ＡＰ２０に帰属している端末１３の数を定数Ｎ0にセットする（Ｓ７００）。そして、端末特定部２３は、端末リストテーブル２４５のリスト１内の端末ＩＤを全て削除する（Ｓ７０１）。そして、端末特定部２３は、変数ｉの値が定数Ｎ0未満か否かを判定する（Ｓ７０２）。変数ｉの値が定数Ｎ0以上である場合（Ｓ７０２：Ｎｏ）、ＡＰ２０は、本フローチャートに示す除外端末特定処理を終了する。
【０１１９】
変数ｉの値が定数Ｎ0未満である場合（Ｓ７０２：Ｙｅｓ）、端末特定部２３は、保持部２４内の測定値テーブル２４０を参照して、ｉ番目の端末１３の応答時間を取得する。そして、端末特定部２３は、取得した応答時間の分布から、応答時間の標準偏差Ｄrσ（ｉ）を算出する（Ｓ７０３）。そして、端末特定部２３は、下記の算出式（１）に基づいて、干渉による遅延増加量の期待値Ｄintfを算出する。
Ｄintf＝［｛（１−ＰＥＲN）／（１−ＰＥＲ）｝−１］×Ｄp      ・・・（１）
【０１２０】
上記の算出式（１）において、ＰＥＲは許容されるパケット誤り率、Ｎは再送回数、Ｄpはテストパケットのパケット長を示す。ＰＥＲは干渉トラフィック密度に相当する。例えば、ＰＥＲ＝３０％、Ｎ＝３、Ｄp＝２ミリ秒である場合、遅延増加量の期待値Ｄintfは、［｛（１−０．３3）／（１−０．３）｝−１］×２＝７８０μ秒となる。
【０１２１】
次に、端末特定部２３は、標準偏差Ｄrσ（ｉ）に所定の定数βを乗じた値が、遅延増加量の期待値Ｄintfの値よりも大きいか否かを判定する（Ｓ７０４）。本実施例において、所定の定数βは、例えば６である。標準偏差Ｄrσ（ｉ）に所定の定数βを乗じた値は、Ａｃｋパケットの応答時間のばらつきの度合いの一例である。また、遅延増加量の期待値Ｄintfは、干渉により変動する応答時間のばらつきの期待値の一例である。
【０１２２】
標準偏差Ｄrσ（ｉ）に定数βを乗じた値が、遅延増加量の期待値Ｄintfの値よりも大きい場合（Ｓ７０４：Ｙｅｓ）、端末特定部２３は、ｉ番目の端末１３の端末ＩＤを端末リストテーブル２４５のリスト１内に登録する（Ｓ７０５）。そして、端末特定部２３は、変数ｉの値を１増やし（Ｓ７０６）、再びステップＳ７０２に示した処理を実行する。一方、標準偏差Ｄrσ（ｉ）に定数βを乗じた値が、遅延増加量の期待値Ｄintfの値以下である場合（Ｓ７０４：Ｎｏ）、端末特定部２３は、ステップＳ７０６に示した処理を実行する。図２１に示した除外端末特定処理が実行されることにより、リスト１内には、フェージングの影響を受けている可能性が高い端末１３の端末ＩＤが登録される。
【０１２３】
［実施例３の効果］
上述したように、本実施例のＡＰ２０は、例えば深夜など各端末１３がユーザデータを有するパケットの送受信を行っていない時間帯において、各端末１３へテストパケットを送信し、Ａｃｋパケットを受信するまでの応答時間のばらつきの度合いを算出する。そして、ＡＰ２０は、算出したばらつきの度合いが、遅延増加量の期待値よりも大きい端末１３を、フェージングの影響を受けている端末１３として特定する。これにより、ＡＰ２０は、フェージングなど干渉以外の要因により応答時間が変動している端末１３を、障害原因の判定対象から除外することができる。そのため、障害原因の判定精度を向上させることができる。
【０１２４】
また、本実施例のＡＰ２０は、前述の算出式（１）に基づいて算出された遅延増加量の期待値Ｄintfを用いて、フェージングの影響を受けている端末１３を特定する。これにより、ＡＰ２０は、フェージングなど干渉以外の要因により応答時間が変動している端末１３を、障害原因の判定対象から除外することができる。
【０１２５】
また、本実施例のＡＰ２０は、端末１３へパケットを送信してから該パケットに対するＡｃｋパケットを受信するまでの応答時間の標準偏差Ｄrσに所定数βを乗じた値を、応答時間のばらつきの度合いとして用いる。これにより、ＡＰ２０は、フェージングなど干渉以外の要因により応答時間が変動している端末１３を、障害原因の判定対象から除外することができる。
【０１２６】
［ハードウェア］
なお、これまで説明した図に示された各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１２７】
さらに、ＡＰ２０が有する各種処理機能は、ＣＰＵ（Central  Processing  Unit）（又はＭＰＵ（Micro  Processing  Unit）、ＭＣＵ（Micro  Controller  Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、またはワイヤードロジックによるハードウェア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。
【０１２８】
ところで、上記実施例１から３において説明した各種の処理は、予め用意されたプログラムをＡＰ２０が実行することで実現できる。そこで、以下では、上記した実施例１から３と同様の機能を有するプログラムを実行するＡＰ２０の一例を説明する。図２２は、ＡＰ２０のハードウェアの一例を示す図である。
【０１２９】
例えば図２２に示すように、ＡＰ２０は、無線通信インターフェイス５０、有線通信インターフェイス５１、ＣＰＵ５２、ＲＡＭ（Random  Access  Memory）５３、およびＲＯＭ（Read  Only  Memory）５４を有する。無線通信インターフェイス５０、有線通信インターフェイス５１、ＣＰＵ５２、ＲＡＭ５３、およびＲＯＭ５４は、バス５５を介して互いに接続されている。
【０１３０】
ＲＯＭ５４には、基準値作成プログラム５４０、測定プログラム５４１、および障害原因推定プログラム５４２が予め記憶される。ＣＰＵ５２は、基準値作成プログラム５４０、測定プログラム５４１、および障害原因推定プログラム５４２をＲＯＭ５４から読み出してＲＡＭ５３に展開する。基準値作成プログラム５４０、測定プログラム５４１、および障害原因推定プログラム５４２は、図２に示した各々の構成要素と同様、適宜統合または分離されてもよい。
【０１３１】
ＣＰＵ５２は、ＲＯＭ５４から基準値作成プログラム５４０、測定プログラム５４１、および障害原因推定プログラム５４２をそれぞれ読み出す。そして、ＣＰＵ５２は、基準値作成プログラム５４０を基準値作成プロセス５３０として、測定プログラム５４１を測定プロセス５３１として、障害原因推定プログラム５４２を障害原因推定プロセス５３２として、ＲＡＭ５３にそれぞれ展開する。そして、ＣＰＵ５２は、上記した実施例１から３のそれぞれにおいて、ＲＡＭ５３上に展開された基準値作成プロセス５３０、測定プロセス５３１、および障害原因推定プロセス５３２を実行する。例えば、ＣＰＵ５２は、ＲＡＭ５３上に展開された各プロセスを実行することで、通信制御部２１、障害判定部２２、端末特定部２３、応答時間測定部２５、パケットロス率測定部２６、ＲＳＳＩ測定部２７、送信部２８、および受信部２９と同様の機能を発揮する。
【０１３２】
また、ＣＰＵ５２は、上記した実施例１および２において、ＲＡＭ５３上に展開された基準値作成プロセス５３０を実行することにより、例えば図１４および図１５に示した処理を実行する。また、ＣＰＵ５２は、上記した実施例３において、ＲＡＭ５３上に展開された基準値作成プロセス５３０を実行することにより、例えば図１４および図２１に示した処理を実行する。また、ＣＰＵ５２は、上記した実施例１から３において、ＲＡＭ５３上に展開された測定プロセス５３１を実行することにより、例えば図１６に示した処理を実行する。また、ＣＰＵ５２は、上記した実施例１および３において、ＲＡＭ５３上に展開された障害原因推定プロセス５３２を実行することにより、例えば図１７から図１９に示した処理を実行する。また、ＣＰＵ５２は、上記した実施例２において、ＲＡＭ５３上に展開された障害原因推定プロセス５３２を実行することにより、例えば図１８から図２０に示した処理を実行する。
【０１３３】
なお、ＣＰＵ５２によって仮想的に実現される各処理部は、全ての処理部がＣＰＵ５２によって常に実現されていなくてもよく、処理に用いられる処理部のみが仮想的に実現されればよい。また、基準値作成プログラム５４０、測定プログラム５４１、および障害原因推定プログラム５４２は、必ずしも最初から全てがＲＯＭ５４内に記憶させてなくてもよい。例えば、ＡＰ２０に挿入されるＩＣカードなどの可搬型記録媒体に各プログラムが記憶され、ＡＰ２０が可搬型記録媒体から各プログラムを取得して実行するようにしてもよい。また、各プログラムを記憶させた他のコンピュータまたはサーバ装置などから、無線通信回線、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介して、ＡＰ２０が各プログラムを取得して実行するようにしてもよい。
【０１３４】
［その他］
なお、開示の技術は、上記した各実施例に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記した各実施例では、ＡＰ２０に障害判定部２２および端末特定部２３が設けられるが、開示の技術はこれに限られない。例えば、ＡＰ２０が接続されたネットワーク上にコントローラを設け、該コントローラに障害判定部２２および端末特定部２３の機能が設けられてもよい。この場合、ＡＰ２０は、各端末１３へテストパケットを送信することにより、応答時間、パケットロス、およびＲＳＳＩを測定してコントローラに提供する。コントローラは、ＡＰ２０から提供された情報を元に、フェージングを受けている可能性の高い端末１３を特定する処理や障害原因を特定する処理を実行する。これにより、ＡＰ２０の処理負荷の増大を抑えることができる。
【０１３５】
また、上記した実施例３において、端末特定部２３は、応答時間のばらつきの度合いとして、応答時間の標準偏差Ｄrσに所定の定数β（例えば６）を乗じた値を算出したが、開示の技術はこれに限られない。例えば、端末特定部２３は、応答時間の値の分布において、母集団の所定割合が含まれる応答時間の範囲を、応答時間のばらつきの度合いとして算出してもよい。例えば、端末特定部２３は、応答時間の値の分布において母集団の９９％が含まれる応答時間の範囲を、応答時間のばらつきの度合いとして算出してもよい。
【０１３６】
また、上記した実施例３では、ＡＰ２０は、応答時間のばらつきの度合いが、遅延増加量の期待値よりも大きい端末１３を、フェージングの影響を受けている可能性が高い端末１３として特定するが、開示の技術はこれに限られない。例えば、実施例３においても、実施例２と同様に、応答時間のばらつきの度合いが遅延増加量の期待値よりも大きい端末１３であっても、パケットロス率が所定値未満の場合には、障害原因の判定対象に加えてもよい。これにより、ＡＰ２０に帰属しているより多くの端末１３を対象として障害原因を判定することができ、障害原因の判定精度をさらに向上させることができる。
【符号の説明】
【０１３７】
２０  ＡＰ
２１  通信制御部
２２  障害判定部
２３  端末特定部
２４  保持部
２４０  測定値テーブル
２４１  応答時間テーブル
２４２  パケットロス率テーブル
２４３  ＲＳＳＩテーブル
２４４  ログテーブル
２４５  端末リストテーブル
２５  応答時間測定部
２６  パケットロス率測定部
２７  ＲＳＳＩ測定部
２８  送信部
２９  受信部
２００  アンテナ
【図１】
2017041806.tif 000003
【図２】
2017041806.tif 000004
【図３】
2017041806.tif 000005
【図４】
2017041806.tif 000006
【図５】
2017041806.tif 000007
【図６】
2017041806.tif 000008
【図７】
2017041806.tif 000009
【図８】
2017041806.tif 000010
【図９】
2017041806.tif 000011
【図１０】
2017041806.tif 000012
【図１１】
2017041806.tif 000013
【図１２】
2017041806.tif 000014
【図１３】
2017041806.tif 000015
【図１４】
2017041806.tif 000016
【図１５】
2017041806.tif 000017
【図１６】
2017041806.tif 000018
【図１７】
2017041806.tif 000019
【図１８】
2017041806.tif 000020
【図１９】
2017041806.tif 000021
【図２０】
2017041806.tif 000022
【図２１】
2017041806.tif 000023
【図２２】
2017041806.tif 000024