特許 5930561 ゲートウェイ装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】5930561

(24)【登録日】2016年5月13日

(45)【発行日】2016年6月8日

(54)【発明の名称】ゲートウェイ装置

(51)【国際特許分類】

   H04L 12/66 20060101AFI20160526BHJP

   H04L 12/46 20060101ALI20160526BHJP

   H04L 12/70 20130101ALI20160526BHJP

   G06F 21/31 20130101ALI20160526BHJP

【ＦＩ】

   H04L12/66 A

   H04L12/46 E

   H04L12/70 A

   G06F21/31

   H04L12/70 100Z

【請求項の数】6

【全頁数】15

(21)【出願番号】特願2015-79048(P2015-79048)

(22)【出願日】2015年4月8日

【審査請求日】2015年4月8日

(73)【特許権者】

【識別番号】399041158

【氏名又は名称】西日本電信電話株式会社

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100101247

【弁理士】

【氏名又は名称】高橋 俊一

(74)【代理人】

【識別番号】100095500

【弁理士】

【氏名又は名称】伊藤 正和

(74)【代理人】

【識別番号】100098327

【弁理士】

【氏名又は名称】高松 俊雄

(72)【発明者】

【氏名】後藤 孝臣

(72)【発明者】

【氏名】秋井 和貴

(72)【発明者】

【氏名】戸嶋 巌樹

(72)【発明者】

【氏名】大畑 博敬

【審査官】 速水 雄太

(56)【参考文献】

【文献】 特開２００１−３３３１１４（ＪＰ，Ａ）

【文献】 特開２００７−３１２２７７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／６６

Ｇ０６Ｆ ２１／３１

Ｈ０４Ｌ １２／４６

Ｈ０４Ｌ １２／７０

(57)【特許請求の範囲】

【請求項1】

接続要求元の装置であるゲートウェイ装置であって、
認証エラーが発生する接続要求をあらかじめ実施し、前記認証エラーが発生する接続要求に対する認証エラー受信までの応答時間に基づいて、前記認証エラーの発生を意図しない接続要求に対する認証エラーを送信した認証エラー送信元のサーバを推定する認証エラー要因推定部と、
前記認証エラー要因推定部による推定結果に応じて再接続要求を制御する接続要求制御部と
を備えることを特徴とするゲートウェイ装置。

【請求項2】

前記サーバは、網内のドメイン認証サーバ、又はインターネットサービスプロバイダのＩＳＰ認証サーバであることを特徴とする請求項１に記載のゲートウェイ装置。

【請求項3】

前記認証エラー要因推定部は、前記認証エラーが発生する接続要求に対する認証エラー受信までの応答時間を統計的に測定し、統計的に確からしい信頼区間に基づいて、前記認証エラーの発生を意図しない接続要求に対する認証エラーを送信した認証エラー送信元のサーバを推定することを特徴とする請求項２に記載のゲートウェイ装置。

【請求項4】

前記認証エラー要因推定部は、統計的に曖昧な区間が存在する場合において、その曖昧な区間に、前記認証エラーの発生を意図しない接続要求に対する認証エラー受信までの応答時間が属するときは、前記ドメイン認証サーバによるドメイン認証エラーであると推定することを特徴とする請求項３に記載のゲートウェイ装置。

【請求項5】

前記接続要求制御部は、前記ＩＳＰ認証サーバによるユーザ認証エラーであると推定された場合、再接続要求間隔を延長してリトライを実施することを特徴とする請求項２〜４のいずれか１項に記載のゲートウェイ装置。

【請求項6】

前記接続要求制御部は、前記ドメイン認証サーバによるドメイン認証エラーであると推定された場合、再接続要求を即時停止し、要求接続状態で待機することを特徴とする請求項２〜４のいずれか１項に記載のゲートウェイ装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ゲートウェイ装置に関し、特に、ゲートウェイ装置から網装置への再接続要求を制御する技術に関する。

【背景技術】

【0002】

現在、フレッツ網等の通信網への接続方式として、ＩＰｖ４／ＩＰｖ６＿ＰＰＰｏＥ方式及びＩＰｖ６ｏＥ方式が用いられている。ＰＰＰｏＥ（PPP over Ethernet）接続方式において利用者が複数の接続先を設定した場合や、ＩＳＰ（インターネットサービスプロバイダ）を変更した場合に、網装置への無効呼が発生するケースが多々発生している（Ethernetは登録商標）。

【0003】

また、ＩＳＰを変更した場合は、接続要求元の端末となっているゲートウェイ装置（以降、ＨＧＷ）の設定を削除もしくはユーザによる接続要求を停止しない限り、再接続による無効呼を発生し続ける。このような接続要求増への対処策として、ＩＳＰや通信事業者をはじめとする、サーバを伴う装置によってネットワークサービスを提供する会社ではサーバを増設せざるを得ない状態となっている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７−００６２１８号公報

【特許文献2】特開２００７−２２６６２０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

現状では、ＨＧＷから送信される無効な接続要求に対するサーバ（網内の認証サーバ及びＩＳＰの認証サーバ）の応答は、どのようなケースにおいても全て「認証エラー」で送信されるため、ＨＧＷでは何が起きているのか判別することができない。

【0006】

本発明は、上述した従来の技術に鑑み、無効な接続要求の内容をいち早く捕捉することができるゲートウェイ装置を提供することを目的とする。

【課題を解決するための手段】

【0007】

上記目的を達成するため、第１の態様に係る発明は、接続要求元の装置であるゲートウェイ装置であって、認証エラーが発生する接続要求をあらかじめ実施し、前記認証エラーが発生する接続要求に対する認証エラー受信までの応答時間に基づいて、前記認証エラーの発生を意図しない接続要求に対する認証エラーを送信した認証エラー送信元のサーバを推定する認証エラー要因推定部と、前記認証エラー要因推定部による推定結果に応じて再接続要求を制御する接続要求制御部とを備えることを要旨とする。

【0008】

第２の態様に係る発明は、第１の態様に係る発明において、前記サーバが、網内のドメイン認証サーバ、又はインターネットサービスプロバイダのＩＳＰ認証サーバであることを要旨とする。

【0009】

第３の態様に係る発明は、第２の態様に係る発明において、前記認証エラー要因推定部が、前記認証エラーが発生する接続要求に対する認証エラー受信までの応答時間を統計的に測定し、統計的に確からしい信頼区間に基づいて、前記認証エラーの発生を意図しない接続要求に対する認証エラーを送信した認証エラー送信元のサーバを推定することを要旨とする。

【0010】

第４の態様に係る発明は、第３の態様に係る発明において、前記認証エラー要因推定部が、統計的に曖昧な区間が存在する場合において、その曖昧な区間に、前記認証エラーの発生を意図しない接続要求に対する認証エラー受信までの応答時間が属するときは、前記ドメイン認証サーバによるドメイン認証エラーであると推定することを要旨とする。

【0011】

第５の態様に係る発明は、第２〜第４の態様に係る発明において、前記接続要求制御部が、前記ＩＳＰ認証サーバによるユーザ認証エラーであると推定された場合、再接続要求間隔を延長してリトライを実施することを要旨とする。

【0012】

第６の態様に係る発明は、第２〜第４の態様に係る発明において、前記接続要求制御部が、前記ドメイン認証サーバによるドメイン認証エラーであると推定された場合、再接続要求を即時停止し、要求接続状態で待機することを要旨とする。

【発明の効果】

【0013】

本発明によれば、無効な接続要求の内容をいち早く捕捉することができるゲートウェイ装置を提供することが可能である。

【図面の簡単な説明】

【0014】

【図1】本発明に至る背景を説明するための図である。

【図2】認証エラーを説明するための図である。

【図3】本発明の実施の形態における認証エラー要因推定システムの構成図である。

【図4】本発明の実施の形態におけるＨＧＷの機能ブロック図である。

【図5】本発明の実施の形態におけるテスト結果書き込み用テーブルの構成図である。

【図6】本発明の実施の形態における判定用テーブルの構成図である。

【図7】本発明の実施の形態におけるＰＰＰｏＥ接続試行結果書き込み用テーブルの構成図である。

【図8】本発明の実施の形態におけるＨＧＷの動作を示すフローチャートである。

【図9】本発明の実施の形態におけるＨＧＷの動作を示すフローチャートである。

【図10】本発明の実施の形態における判定用データの概念図である。

【図11】本発明の実施の形態における認証エラー要因推定の概念図である。

【図12】本発明の実施の形態におけるＨＧＷのシーケンス図である。

【図13】本発明の実施の形態におけるＨＧＷのシーケンス図である。

【図14】本発明の実施の形態におけるＨＧＷのシーケンス図である。

【図15】本発明の実施の形態におけるＨＧＷのシーケンス図である。

【図16】本発明の実施の形態におけるＨＧＷによる効果を示すグラフである。

【発明を実施するための形態】

【0015】

以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下の実施の形態は、この発明の技術的思想を具体化するためのゲートウェイ装置を例示するものであり、装置の構成やデータの構成等は以下の実施の形態に限定されるものではない。
（背景）
図１は、本発明に至る背景を説明するための図であり、（ａ）は、通信網内の装置（網装置）への接続要求推移を示すグラフ、（ｂ）は、接続要求内訳を示す表である。この図に示すように、ＨＧＷから網装置及びＩＳＰ認証サーバに対して接続要求が増加しているが、このような接続要求の約８割は無効な接続要求である。毎月定常的に接続要求量が増加しており、図中のＥ１に示すように、爆発的な増減があった場合は管理値Ｌ１を超える可能性がある。爆発的な増減がなくても、図中のＥ２に示すように、このままでは管理値Ｌ１を超える可能性がある。今後、収容限界値Ｌ２に到達する前に、網装置の増設など、想定を超える増設や維持管理に関するコストが発生する可能性がある。

【0016】

図２は、認証エラーを説明するための図である。この図に示すように、ＨＧＷ１０に対して認証エラーを送信するのはエッジルータ（サービスエッジ）２１である。エッジルータ２１は、ＨＧＷ１０からの認証方式により、「Ｃｈａｐ Ｆａｉｌｕｒｅ」及び「ＰＡＰ−Ａｕｔｈ−Ｎａｋ」のどちらかを認証エラーとして送信するようになっている。エッジルータ２１への認証エラーの送信元はドメイン認証サーバ３０とＩＳＰ認証サーバ４０の２種類あり、どのサーバから認証エラーが発信されたかは不明である。ＨＧＷ１０に対して送信される認証エラーについても、ドメイン認証エラーであるのかユーザ認証エラーであるのか判別することができない。
（システム構成）
図３は、本発明の実施の形態における認証エラー要因推定システムの構成図である。この図に示すように、ＨＧＷ１０は、エッジルータ２１を介してドメイン認証サーバ３０に接続され、エッジルータ２１・網終端装置２２を介してＩＳＰ認証サーバ４０に接続されている。

【0017】

ＩＳＰ認証サーバ４０は、インターネットサービスプロバイダの認証サーバである。ＩＳＰ認証サーバ４０は、無効な認証要求に対して「ユーザ認証エラー」を送信する。

【0018】

ドメイン認証サーバ３０は、フレッツ網等の通信網２０内の認証サーバであり、通信網２０で接続可能なＩＳＰ認証サーバ４０の有無を判別するために用いられる。ドメイン認証サーバ３０は、無効な認証要求に対して「ドメイン認証エラー」を送信する。

【0019】

このような認証エラー要因推定システムにおいて、「認証エラー要因推定機能」をＨＧＷ１０へ実装し、接続要求の必要性を判断し、認証エラー要因に応じた適切な動作とする。すなわち、ＨＧＷ１０から送信した接続要求に関する認証エラー受信までの時間を測定し、送信したサーバを推定し、統計処理により原因を明確化する。ＨＧＷ１０のみの機能追加（プログラムの追加インストール）で対処することができるため、網装置及びＩＳＰ認証サーバ４０は現行のまま利用可能である。
（ＨＧＷ）
図４は、本発明の実施の形態におけるＨＧＷ１０の機能ブロック図である。この図に示すように、ＨＧＷ１０は、ＩＰｖ４＿ＰＰＰｏＥ接続部１１と、ＩＰｖ６＿ＰＰＰｏＥ接続部１２と、接続要求制御部１３と、記憶部１４と、認証エラー要因推定部１５とを備える。

【0020】

認証エラー要因推定部１５は、あらかじめ設定した「認証エラー」が発生する接続要求を実施する。また、認証エラー受信までの所要時間を統計的に測定し、認証エラー送信元のサーバの推定を実施する。さらに、認証エラー送信元サーバ推定結果に応じた認証エラー要因を接続要求制御部１３へ通知する。

【0021】

接続要求制御部１３は、認証エラー要因推定部１５から通知された認証エラー送信元サーバ推定結果に基づいて適切な再接続仕様で動作する。

【0022】

ＩＰｖ４＿ＰＰＰｏＥ接続部１１は、ＩＰｖ４アドレスを用いたＰＰＰｏＥ方式で通信網２０に接続する。ＩＰｖ６＿ＰＰＰｏＥ接続部１２は、ＩＰｖ６アドレスを用いたＰＰＰｏＥ方式で通信網２０に接続する。以降、ＩＰｖ４＿ＰＰＰｏＥ接続部１１とＩＰｖ６＿ＰＰＰｏＥ接続部１２とを特に区別することなく「ＰＰＰｏＥクライアント部」と呼ぶ場合がある。

【0023】

記憶部１４は、認証結果ＤＢ１４Ａを記憶している。認証結果ＤＢ１４Ａには、後述するテスト結果書き込み用テーブルＴ１、判定用テーブルＴ２、及びＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３が含まれる。

【0024】

本発明の実施の形態によれば、無効な接続要求の内容をいち早く捕捉することができる。これにより、無効な接続要求を自律的に制御することができるゲートウェイ装置を提供することが可能である。また、お客様からの接続障害の問い合わせに対する原因の明確化にかかる時間を短縮する効果がある。
（データベース構成）
図５は、本発明の実施の形態におけるテスト結果書き込み用テーブルＴ１の構成図である。この図に示すように、テスト結果書き込み用テーブルＴ１は、「Ｎｏ」「ドメイン」「応答時間」「Ｒｅｓｐｏｎｓｅ」「備考」等の情報を蓄積する。「備考」には、判定結果である「ｃａｓｅ−１」「ｃａｓｅ−２」等の情報を蓄積するようにしている。

【0025】

テスト結果書き込み用テーブルＴ１の初期化契機は、例えば、ＨＧＷ再起動時であり、更新契機は、例えば、認証エラー要因推定フェーズからの結果通知時である。テスト結果書き込み用テーブルＴ１には、最大１００件のテスト結果を蓄積することができ、１００件以降、古いものから上書きするようになっている。

【0026】

図６は、本発明の実施の形態における判定用テーブルＴ２の構成図である。この図に示すように、判定用テーブルＴ２は、「レコードＮｏ」「要因」「応答時間Ｍｉｎ」「応答時間Ｍａｘ」等の情報を蓄積する。判定用テーブルＴ２の初期化契機は、例えば、ＨＧＷ再起動時であり、更新契機は、例えば、判定用データ蓄積フェーズ完了後である。

【0027】

図７は、本発明の実施の形態におけるＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の構成図である。この図に示すように、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３は、「Ｎｏ」「ＰＰＰ−ＩＦ」「ＵＳＥＲ−ＩＤ」「ＰＡＳＳ」「応答時間」「試行結果」「判定結果」等の情報を蓄積する。ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の初期化契機は、例えば、ＨＧＷ再起動時であり、更新契機は、例えば、認証エラー要因推定フェーズにおけるＰＰＰｏＥ接続試行実施時、及び認証エラー要因推定フェーズにおける認証エラー要因推定完了時である。
（認証エラー要因推定）
図８は、本発明の実施の形態におけるＨＧＷ１０の動作を示すフローチャートである。以下、図８を用いて、認証エラー要因を推定する動作について説明する。

【0028】

まず、所定の起動契機で認証エラー要因推定動作を開始する。この起動契機は、例えば、ＨＧＷ起動時／再起動時、ＷＡＮポートリンクアップ検知時、ＷｅｂＵＩによるＩＰｖ４ＰＰＰｏＥ接続ボタン／ＩＰｖ６ＰＰＰｏＥ接続ボタン押下時、及び外部ＩＦ（ルータライブラリ）からの接続要求受信時である。

【0029】

次いで、ＩＰｖ４／ＩＰｖ６の両方でＰＰＰｏＥ接続試行を実施し（ステップＳ１）、そのＰＰＰｏＥ接続試行結果をＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３に書き込む（ステップＳ２）。

【0030】

次いで、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３より「試行結果」＝“Ｆａｉｌｕｒｅ"を抽出する（ステップＳ３）。これにより、ＰＰＰｏＥ接続失敗ＩＦが検出されなかった場合（接続ＯＫ＿ＩＦ）は終了する。一方、ＰＰＰｏＥ接続失敗ＩＦが検出された場合（接続ＮＧ＿ＩＦ）は、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の過去レコードから「ＰＰＰ−ＩＦ」「ＵＳＥＲ−ＩＤ」「ＰＡＳＳ」を検索し、その判定結果情報を確認する（ステップＳ４）。

【0031】

ステップＳ４において、判定結果が「ｃａｓｅ−１」又は「ｃａｓｅ−２」である場合は終了する。一方、判定結果が「ｃａｓｅ−３」「ｅｒｒ」又は「判定結果なし」である場合、判定用テーブルＴ２を確認する（ステップＳ５）。

【0032】

ステップＳ５において、判定用テーブルＴ２に判定用データがない場合は、後述する「判定用データ蓄積」に移行する（ステップＳ６）。一方、判定用テーブルＴ２に判定用データがある場合は、認証エラー要因を判定する（ステップＳ７）。

【0033】

具体的には、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の「応答時間」と判定用テーブルＴ２の「要因」の応答時間（Ｍｉｎ〜Ｍａｘ）の範囲検索を実施する。そして、応答時間が範囲に属するかに応じて、Ｃａｓｅ−１、Ｃａｓｅ−２、Ｃａｓｅ−３（範囲外）、Ｅｒｒ（判定不可）を判定する。

【0034】

例えば、ＩＳＰ認証サーバ４０におけるＩＤ／パスワード間違いのようなケースでは、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の「判定結果」に「ｃａｓｅ−１」が書き込まれ（ステップＳ８）、その旨が認証エラー要因推定部１５から接続要求制御部１３に通知される（ステップＳ９）。この場合、接続要求制御部１３は、例えば、再接続要求間隔を延長してリトライ実施するようになっている。

【0035】

また、ドメイン認証サーバ３０におけるドメイン入力誤りのようなケースでは、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の「判定結果」に「ｃａｓｅ−２」が書き込まれ（ステップＳ１０）、その旨が認証エラー要因推定部１５から接続要求制御部１３に通知される（ステップＳ１１）。この場合、接続要求制御部１３は、例えば、再接続要求を即時停止し、要求接続状態で待機するようになっている。

【0036】

また、その他のケースでは、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の「判定結果」に「ｃａｓｅ−３」が書き込まれ（ステップＳ１２）、その旨が認証エラー要因推定部１５から接続要求制御部１３に通知される（ステップＳ１３）。さらに、判定不可のケースでは、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３の「判定結果」に「ｅｒｒ」が書き込まれ（ステップＳ１４）、その旨が認証エラー要因推定部１５から接続要求制御部１３に通知される（ステップＳ１３）。これらの場合、接続要求制御部１３は、例えば、再接続要求を即時停止し、要求接続状態で待機するようになっている。また、ランダムタイマにより一定時間（１〜３時間）が経過した後、ステップＳ３に戻る。
（判定用データ蓄積）
図９は、本発明の実施の形態におけるＨＧＷ１０の動作を示すフローチャートである。以下、図９を用いて、判定用データを蓄積する動作を説明する。

【0037】

まず、所定の起動契機で判定用データ蓄積動作を開始する。この起動契機は、例えば、ＨＧＷ起動時／再起動のみとし、必要以上にテストデータが送信されないようにしている。

【0038】

ＨＧＷ１０が起動時又は再起動されると、ドメイン認証サーバ３０向けのテストデータを送信し（ステップＳ２１）、そのテスト結果をテスト結果書き込み用テーブルＴ１に書き込む（ステップＳ２２）。また、ＩＳＰ認証サーバ４０向けのテストデータを送信し（ステップＳ２３）、そのテスト結果をテスト結果書き込み用テーブルＴ１に書き込む（ステップＳ２４）。テストデータは特に限定されるものではないが、例えば、事前登録した５件程度のサンプルデータを送信するようになっている。

【0039】

次いで、テスト結果書き込み用テーブルＴ１の内容に基づいて判定用データを作成し、判定用テーブルＴ２を更新する（ステップＳ２５）。そして、判定用テーブルＴ２の範囲をチェックし（ステップＳ２６）、範囲重複がある場合は、ランダムタイマにより一定時間（３０分〜１時間）が経過した後、ステップＳ２１に戻る。一方、範囲重複がない場合は、ランダムタイマにより一定時間（１週間）が経過した後、ステップＳ２１に戻る。
（判定用データ作成）
上述したように、ドメイン認証サーバ３０向けのテストを実施するとともに、ＩＳＰ認証サーバ４０向けのテストを実施する。テスト結果が得られると、統計学の「信頼区間による判定」を用いて判定用データを作成する。信頼区間は次式で定義する。

【0040】

Σ（Xi-μ）²/χ_H²、Σ（Xi-μ）²/χ_L²
Ｘｉはサンプル値である。μは母平均である。χは、自由度ｎに対する確率αに対して、α／２のχ²分布点の値である（上限χ_H，下限χ_L）。このような信頼区間をあらかじめサーバ毎に算出しておく。

【0041】

なお、判定用データを作成する手法は限定されるものではない。すなわち、統計的に確からしい区間を推定する方法や２つの集合を区別する方法などを適宜選択することができる。

【0042】

図１０は、本発明の実施の形態における判定用データの概念図である。図１０（ａ）は、サンプル数が最小（５回）の場合を示し、図１０（ｂ）は、サンプル数が最大（５０回）の場合を示している。この図に示すように、テスト回数を増大させると、応答時間の信頼区間が狭くなり、範囲推定の精度を向上させることができる。
（認証エラー要因推定）
図１１は、本発明の実施の形態における認証エラー要因推定の概念図であり、（ａ）は判定用データ、（ｂ）は判定結果を示している。この図に示すように、判定用データとＰＰＰｏＥ接続試行結果を用いて認証エラー要因を判定する。すなわち、ドメイン認証サーバ３０のエラーについての信頼区間に応答時間が属する場合は、ドメイン認証サーバエラーと判定し、エラー区分を「ｃａｓｅ−２」とする。また、ＩＳＰ認証サーバ４０のエラーについての信頼区分に応答時間が属する場合は、ＩＳＰ認証サーバエラーと判定し、エラー区分を「ｃａｓｅ−１」とする。また、ドメイン認証サーバエラーの下限を下回る場合、及びＩＳＰ認証サーバエラーの上限を超える場合は、その他と判定し、エラー区分を「ｃａｓｅ−３」とする。

【0043】

なお、ドメイン認証サーバエラーの上限とＩＳＰ認証サーバエラーの下限との間の曖昧な区間をどちらに判定するかは、運用やサーバの性質を考慮した上で適宜決定する。例えば、図１１（ｂ）中に点線で示すように、このような曖昧な区間は、網装置側の負荷を優先的に低減する観点から、ドメイン認証サーバエラーであると判定するようにしてもよい。
（シーケンス：認証エラー要因推定フェーズ）
次に、図１２〜図１４を用いて、本発明の実施の形態におけるＨＧＷ１０のシーケンス（認証エラー要因推定フェーズ）について説明する。

【0044】

まず、接続要求制御部１３は、ＰＰＰｏＥクライアント部を介してサーバに接続要求を送信するとともに（図１２、ステップＳ３１→Ｓ３２）、認証内容通知とタイマ開始通知を認証エラー要因推定部１５に送信する（図１２、ステップＳ３３）。

【0045】

認証エラー要因推定部１５は、タイマを開始し、認証内容通知を記憶部１４に送信する（図１２、ステップＳ３４→Ｓ３５）。記憶部１４は、認証内容通知により通知された内容をＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３に書き込む（図１２、ステップＳ３６）。

【0046】

次いで、接続要求制御部１３は、ＰＰＰｏＥクライアント部を介してエッジルータ２１から認証結果通知を受信すると（図１２、ステップＳ３７→Ｓ３８）、タイマ完了通知を認証エラー要因推定部１５に送信する（図１２、ステップＳ３９）。

【0047】

認証エラー要因推定部１５は、タイマを終了し、タイマ結果通知を記憶部１４に送信する（図１２、ステップＳ４０→Ｓ４１）。記憶部１４は、タイマ結果通知により通知された内容をＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３に書き込む（図１２、ステップＳ４２）。

【0048】

以下、図１３を用いて、認証エラー要因推定フェーズのパターン１を説明する。

【0049】

まず、認証エラー要因推定部１５は、接続ＮＧ＿ＩＦを抽出する（ステップＳ５１）。具体的には、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を検索し、接続要求が失敗したものを検索する。

【0050】

次いで、認証エラー要因推定部１５は、検索結果がある場合、過去判定結果を抽出する（ステップＳ５２→Ｓ５３）。具体的には、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を検索し、過去に同じものがあったかどうか検索する。

【0051】

次いで、認証エラー要因推定部１５は、検索結果がない場合、情報検索する（ステップＳ５４→Ｓ５５）。具体的には、記憶部１４の判定用テーブルＴ２及びＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を突き合わせることにより認証エラー要因を推定する（ステップＳ５６）。また、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３へ認証エラー要因推定結果を書き込む（ステップＳ５７）。

【0052】

次いで、認証エラー要因推定部１５は、検索結果がある場合、判定結果通知を接続要求制御部１３に送信する（ステップＳ５８→Ｓ５９）。これにより、接続要求制御部１３は、判定結果通知の内容に応じた動作通知をＰＰＰｏＥクライアント部に送信する（ステップＳ６０）。

【0053】

以下、図１４を用いて、認証エラー要因推定フェーズのパターン２を説明する。パターン２は、接続ＮＧ＿ＩＦの抽出において「接続ＯＫ＿ＩＦ」検出時の動作パターンである。

【0054】

まず、認証エラー要因推定部１５は、接続ＮＧ＿ＩＦを抽出する（ステップＳ７１）。具体的には、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を検索し、接続要求が失敗したものを検索する。

【0055】

次いで、認証エラー要因推定部１５は、検索結果がない場合（すなわち、接続ＯＫ＿ＩＦを検出した場合）、判定結果通知を接続要求制御部１３に送信する（ステップＳ７２→Ｓ７３）。これにより、接続要求制御部１３は、判定結果通知の内容に応じた動作通知をＰＰＰｏＥクライアント部に送信する（ステップＳ７４）。

【0056】

以下、図１４を用いて、認証エラー要因推定フェーズのパターン３を説明する。パターン３は、過去判定結果の抽出において「過去判定結果あり」時の動作パターンである。

【0057】

まず、認証エラー要因推定部１５は、接続ＮＧ＿ＩＦを抽出する（ステップＳ８１）。具体的には、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を検索し、接続要求が失敗したものを検索する。

【0058】

次いで、認証エラー要因推定部１５は、検索結果がある場合、過去判定結果を抽出する（ステップＳ８２→Ｓ８３）。具体的には、記憶部１４のＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３を検索し、過去に同じものがあったかどうか検索する。

【0059】

次いで、認証エラー要因推定部１５は、検索結果がある場合、ＰＰＰｏＥ接続試行結果書き込み用テーブルＴ３へ認証エラー要因推定結果書き込み（ステップＳ８４→Ｓ８５）、判定結果通知を接続要求制御部１３に送信する（ステップＳ８６）。これにより、接続要求制御部１３は、判定結果通知の内容に応じた動作通知をＰＰＰｏＥクライアント部に送信する（ステップＳ８７）。
（シーケンス：判定用データ蓄積フェーズ）
図１５は、本発明の実施の形態におけるＨＧＷ１０のシーケンス図である。以下、図１５を用いて、判定用データ蓄積フェーズについて説明する。

【0060】

まず、認証エラー要因推定部１５は、テスト認証要求を接続要求制御部１３に送信するとともに（ステップＳ９１）、テスト内容通知を記憶部１４に送信する（ステップＳ９２）。接続要求制御部１３は、ＰＰＰｏＥクライアント部を介してサーバにテスト認証要求を送信するとともに（ステップＳ９３→Ｓ９４）、タイマ開始通知を認証エラー要因推定部１５に送信する（ステップＳ９７）。その後、接続要求制御部１３は、ＰＰＰｏＥクライアント部を介してエッジルータ２１から認証結果通知を受信すると（ステップＳ９５→Ｓ９６）、タイマ完了通知を認証エラー要因推定部１５に送信する（ステップＳ９９）。認証エラー要因推定部１５は、タイマを終了し、タイマ結果通知を記憶部１４に送信する（ステップＳ１００→Ｓ１０１）。

【0061】

以上の動作を事前登録済みサンプルデータ数だけ繰り返し実施する（ステップＳ１０２）。

【0062】

最後に、記憶部１４は、タイマ結果通知により通知された内容に基づいて判定用テーブルＴ２を更新する（ステップＳ１０３）。
（効果）
図１６は、本発明の実施の形態におけるＨＧＷ１０による効果を示すグラフである。この図に示すように、ＨＧＷ１０からの接続要求の抑制により、網装置の利用期間が延長される。また、設定誤りの判別が可能となるため、ユーザサポートの効率化が可能である。

【0063】

具体的には、図中のＥ３に示すように、接続要求が抑制されている。また、図中のＥ４に示すように、今後の接続要求もほぼ横ばいになる。そのため、既存設備の利用期間が延長され、サーバ増強の必要性が低下する効果がある。また、設定誤りの箇所が自動検出されるため、ユーザ利便性の向上、問合せ対応稼動の軽減等の効果もある。

【0064】

以上説明したように、本発明の実施の形態におけるＨＧＷ１０は、接続要求元の装置であるゲートウェイ装置であって、認証エラーが発生する接続要求をあらかじめ実施し、その接続要求に対する認証エラー受信までの応答時間に基づいて認証エラー送信元のサーバを推定する認証エラー要因推定部１５と、認証エラー要因推定部１５による推定結果に応じて再接続要求を制御する接続要求制御部１３とを備える。これにより、無効な接続要求の内容をいち早く捕捉し、無効な接続要求を自律的に制御することができる。例えば、ユーザへＩＳＰアカウント間違いを知らせることで、無効アカウントによるサーバへの負荷を軽減することが可能である。

【0065】

例えば、サーバは、網内のドメイン認証サーバ３０、又はインターネットサービスプロバイダのＩＳＰ認証サーバ４０である。

【0066】

また、認証エラー要因推定部１５は、認証エラー受信までの応答時間を統計的に測定し、統計的に確からしい信頼区間に基づいて認証エラー送信元のサーバを推定してもよい。これにより、認証エラー受信までの応答時間に基づいて精度よくサーバを推定することが可能である。

【0067】

また、認証エラー要因推定部１５は、統計的に曖昧な区間が存在する場合において、その曖昧な区間に応答時間が属するときは、ドメイン認証サーバ３０によるドメイン認証エラーであると推定してもよい。これにより、網装置側の負荷を優先的に低減されるため、更に網装置の増設を抑制する効果がある。

【0068】

また、接続要求制御部１３は、ＩＳＰ認証サーバ４０によるユーザ認証エラーであると推定された場合、再接続要求間隔を延長してリトライを実施してもよい。これにより、無効な再接続要求の発生頻度を低下させることが可能である。

【0069】

また、接続要求制御部１３は、ドメイン認証サーバ３０によるドメイン認証エラーであると推定された場合、再接続要求を即時停止し、要求接続状態で待機してもよい。これにより、無効な再接続要求の発生を防止することが可能である。

【0070】

なお、ＨＧＷ１０が認証サーバに情報を送る場合について説明したが、本発明はこれに限定されるものではない。すなわち、認証サーバでなくともサーバに何らかの情報を送り、承認もしくは拒否の返事をもらうあらゆるパターンについて、本発明を適用することが可能である。

【0071】

また、本発明は、ＨＧＷ１０として実現することができるだけでなく、ＨＧＷ１０が備える特徴的な処理部を各ステップとする再接続要求制御方法として実現したり、それらの各ステップをコンピュータに実行させる再接続要求制御プログラムとして実現したりすることも可能である。このようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。

【符号の説明】

【0072】

１０…ＨＧＷ（ゲートウェイ装置）
１１…ＩＰｖ４＿ＰＰＰｏＥ接続部
１２…ＩＰｖ６＿ＰＰＰｏＥ接続部
１３…接続要求制御部
１４…記憶部
１４Ａ…認証結果ＤＢ
１５…認証エラー要因推定部
２０…通信網
２１…エッジルータ
３０…ドメイン認証サーバ
４０…ＩＳＰ認証サーバ
Ｔ１…テスト結果書き込み用テーブル
Ｔ２…判定用テーブル
Ｔ３…ＰＰＰｏＥ接続試行結果書き込み用テーブル

【要約】      （修正有）

【課題】無効な接続要求の内容をいち早く捕捉して、無効な接続要求を自律的に制御することができるゲートウェイ装置を提供する。
【解決手段】ゲートウェイ装置１０は、認証エラーが発生する接続要求をあらかじめ実施して接続要求に対する認証エラー受信までの応答時間に基づいて認証エラー送信元のサーバを推定する認証エラー要因推定部１５と、認証エラー要因推定部１５による推定結果に応じて再接続要求を制御する接続要求制御部１３とを備える。
【選択図】図４

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】