特許 6403210 通信制御装置、通信制御プログラム及びＰＰＰセッションの復旧方法

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

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

(11)【特許番号】6403210

(24)【登録日】2018年9月21日

(45)【発行日】2018年10月10日

(54)【発明の名称】通信制御装置、通信制御プログラム及びＰＰＰセッションの復旧方法

(51)【国際特許分類】

   H04L 29/08 20060101AFI20181001BHJP

【ＦＩ】

   H04L13/00 307A

【請求項の数】9

【全頁数】14

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

(22)【出願日】2015年3月25日

(65)【公開番号】特開2016-184795(P2016-184795A)

(43)【公開日】2016年10月20日

【審査請求日】2017年11月8日

(73)【特許権者】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】松田 吉史

【審査官】 玉木 宏治

(56)【参考文献】

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

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

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

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

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

【文献】 米国特許出願公開第２０１４／０２９７８７８（ＵＳ，Ａ１）

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

Ｈ０４Ｌ ２９／０８

Ｈ０４Ｌ １２／００−９５５

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

【請求項1】

ＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、自装置に接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置であって、
前記ユーザ端末と前記サービスサーバとの間の通信状態を監視して、前記ユーザ端末から前記サービスサーバへの通信が不調となったことを検出してデータ通信不可信号を出力する通信監視部と、
予め設定された周期で前記ＰＰＰサーバにキープアライブメッセージを発行し、前記キープアライブメッセージに対する前記ＰＰＰサーバからの応答が得られないことに応じて前記ＰＰＰセッションの再確立処理を実施するＰＰＰキープアライブ処理部と、を有し、
前記ＰＰＰキープアライブ処理部は、前記データ通信不可信号を受信した場合、予め定められた前記周期よりも短い周期で前記キープアライブメッセージを送信する通信制御装置。

【請求項2】

前記ＰＰＰキープアライブ処理部は、前記データ通信不可信号を受信した場合、予め定められた前記周期に関わらず受信したデータ通信不可信号に応じて前記キープアライブメッセージを送信する請求項１に記載の通信制御装置。

【請求項3】

前記ＰＰＰキープアライブ処理部は、前記キープアライブメッセージに対する応答があった場合、前記周期を予め設定された長さに戻す請求項１又は２に記載の通信制御装置。

【請求項4】

前記ＰＰＰキープアライブ処理部は、前記キープアライブメッセージに対する前記ＰＰＰサーバからの応答が得られない場合に前記キープアライブメッセージを再送信するリトライ処理を行い、前記リトライ処理の連続数回がリトライ回数閾値以上となった場合に前記ＰＰＰセッションの再確立処理を実施すると共に、前記データ通信不可信号を受信した場合には前記リトライ回数閾値を小さな値にする請求項１乃至３のいずれか１項に記載の通信制御装置。

【請求項5】

前記ＰＰＰキープアライブ処理部は、前記キープアライブメッセージに対する応答があった場合、前記リトライ回数閾値を予め設定された値に戻す請求項４に記載の通信制御装置。

【請求項6】

前記キープアライブメッセージは、ＬＣＰ（Link Control Protocol）のエコー要求である請求項１乃至５のいずれか１項に記載の通信制御装置。

【請求項7】

前記通信監視部は、前記ユーザ端末から発行されるＴＣＰ（Transmission Control Protocol）に関するパケット及びＤＮＳ（Domain Name System）クエリーパケットの少なくとも１つを監視する請求項１乃至６のいずれか１項に記載の通信制御装置。

【請求項8】

第１の通信ポートの先に接続されるＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、第２の通信ポートに接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置において前記通信制御装置内の演算部にて実行される通信制御プログラムであって、
第１の通信ポートを介して予め設定された周期で前記ＰＰＰサーバにキープアライブメッセージを発行し、前記キープアライブメッセージに対する前記ＰＰＰサーバからの応答が得られないことに応じて前記ＰＰＰセッションの再確立処理を実施し、
前記第２の通信ポートと前記第１の通信ポートとの間で送受信される情報を参照することで前記ユーザ端末から前記サービスサーバとの間の通信状態を監視し、
前記ユーザ端末から前記サービスサーバへの通信が不調となったことを前記監視に基づき検出したことに応じて、予め定められた前記周期よりも短い周期で前記キープアライブメッセージを送信する通信制御プログラム。

【請求項9】

第１の通信ポートの先に接続されるＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、第２の通信ポートに接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置のＰＰＰセッション復旧方法であって、
前記第２の通信ポートと前記第１の通信ポートとの間で送受信される情報を参照することで前記ユーザ端末から前記サービスサーバとの間の通信状態を監視し、
前記ユーザ端末から前記サービスサーバへの通信が不調となったことを前記監視に基づき検出したことに応じてデータ通信不可信号を生成し、
前記データ通信不可信号が生成された場合には、予め設定された長さよりも短い周期で前記ＰＰＰサーバにキープアライブメッセージを発行して前記ＰＰＰセッションが遮断していると判定したことに応じて再確立処理を実施するＰＰＰセッションの復旧方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は通信制御装置、通信制御プログラム及びＰＰＰセッションの復旧方法に関し、特にＰＰＰサーバと通信制御装置との間で確立されるＰＰＰ（Point to Point Protocol）セッションの遮断を復旧させる機能を有する通信制御装置、通信制御プログラム及びＰＰＰセッションの復旧方法に関する。

【背景技術】

【0002】

通信機能を有するユーザ端末から公衆ネットワークの先に設置されるサービスサーバ（例えば、Ｗｅｂサーバ、ＤＮＳサーバ等）との間で通信を行う場合、ＰＰＰセッション上でユーザ端末とサービスサーバとの間のパケットの送受信を行う。このＰＰＰセッションは、ユーザ端末が接続される通信制御装置と公衆ネットワークへの接続サービスを提供する事業者が設けるＰＰＰサーバとの間で確立されるものである。このように、ＰＰＰセッションに基づき通信を行う通信ステムでは、ＰＰＰセッションの維持のためにＬＣＰ（Link Control Protocol）エコー要求が用いられる。通信制御装置は、ＬＣＰエコー要求を周期的にＰＰＰサーバに送信することでＰＰＰセッションを維持する。このようなセッション維持のための処理をキープアライブ処理と称す。そこで、キープアライブ処理の技術が特許文献１、２に開示されている。

【0003】

特許文献１に記載のネットワーク接続装置は、監視制御装置から送信された制御信号であって、ＳＯＮＥＴ／ＳＤＨフレームのＳＤＣＣにマッピングされた制御信号に対する処理にＬＡＰＤプロトコルを使用するＬＡＰＤ制御部と、当該制御信号に対する処理にＰＰＰプロトコルを使用するＰＰＰ制御部と、を備える。Ｄ４−Ｄ１２判別部は、入力された制御信号の所定位置のビットの値に基づいて、当該制御信号のプロトコルの種別を判別し、判別結果に応じてＬＡＰＤ制御部またはＰＰＰ制御部に当該制御信号を出力する。当該ネットワーク接続装置をＳＯＮＥＴ／ＳＤＨ通信網を構成する全ての伝送装置に搭載する。また、特許文献１に記載のネットワーク接続装置は、制御信号のエラーの検出を行い、エラーが検出された場合には、ＬＡＰＤプロトコル処理手段および／またはＰＰＰプロトコル処理手段に再送要求の通知を行うエラー検出手段をさらに備え、ＬＡＰＤプロトコル処理手段および／またはＰＰＰプロトコル処理手段は、エラー検出手段からの通知を受け取った場合には、再送要求を行う。

【0004】

また、特許文献２に開示された方法では、サービシングノード（例えば、ホームエージェント、ローカルモビリティアンカーまたはパケットデータネットワークゲートウェイ）が、ユーザ端末に向けられたネットワークサーバからのキープアライブ要求を受信したときに、ユーザ端末にキープアライブ要求を転送すべきか否かを非アクティビティタイマーの値に基づき判断し、ユーザ端末に代わってサーバ要求に少なくとも部分的に基づいてネットワークサーバにサーバ応答を送信する。これにより、特許文献２では、ユーザ端末とサービシングノードとの間のキープアライブ要求の送受信を削減する。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００９−２４６５１９号公報

【特許文献2】特表２０１３−５３９６２３号公報

【発明の概要】

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

【0006】

ＰＰＰセッションが切断された場合、ＰＰＰセッションを再確立する必要がある。このとき、ＰＰＰセッションの再確立は、例えば、ＬＣＰエコー要求等のキープアライブ処理が複数回連続して失敗した場合に行われる。このとき、ＬＣＰエコー要求の発行間隔は、予め設定されているものであるため、キープアライブ処理が複数回失敗し、ＰＰＰセッションの再確立処理が行われるまでに多くの時間がかかる問題が発生する。特許文献１、２に記載の技術を用いても上記課題を解決することはできない。

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

【0007】

本発明にかかる通信制御装置の一態様は、ＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、自装置に接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置であって、前記ユーザ端末と前記サービスサーバとの間の通信状態を監視して、前記ユーザ端末から前記サービスサーバへの通信が不調となったことを検出してデータ通信不可信号を出力する通信監視部と、予め設定された周期で前記ＰＰＰサーバにキープアライブメッセージを発行し、前記キープアライブメッセージに対する前記ＰＰＰサーバからの応答が得られないことに応じて前記ＰＰＰセッションの再確立処理を実施するＰＰＰキープアライブ処理部と、を有し、前記ＰＰＰキープアライブ処理部は、前記データ通信不可信号を受信した場合、予め定められた前記周期よりも短い周期で前記キープアライブメッセージを送信する。

【0008】

本発明にかかる通信制御プログラムの一態様は、第１の通信ポートの先に接続されるＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、第２の通信ポートに接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置において前記通信制御装置内の演算部にて実行される通信制御プログラムであって、第１の通信ポートを介して予め設定された周期で前記ＰＰＰサーバにキープアライブメッセージを発行し、前記キープアライブメッセージに対する前記ＰＰＰサーバからの応答が得られないことに応じて前記ＰＰＰセッションの再確立処理を実施し、前記第２の通信ポートと前記第１の通信ポートとの間で送受信される情報を参照することで前記ユーザ端末から前記サービスサーバとの間の通信状態を監視し、前記ユーザ端末から前記サービスサーバへの通信が不調となったことを前記監視に基づき検出したことに応じて、予め定められた前記周期よりも短い周期で前記キープアライブメッセージを送信する。

【0009】

本発明にかかるＰＰＰセッションの復旧方法は、第１の通信ポートの先に接続されるＰＰＰ（Point to Point Protocol）サーバとの間でＰＰＰセッションを確立し、第２の通信ポートに接続されるユーザ端末と前記ＰＰＰサーバの先に設けられるサービスサーバとの間の通信を前記ＰＰＰセッションにより行う通信制御装置のＰＰＰセッション復旧方法であって、前記第２の通信ポートと前記第１の通信ポートとの間で送受信される情報を参照することで前記ユーザ端末から前記サービスサーバとの間の通信状態を監視し、前記ユーザ端末から前記サービスサーバへの通信が不調となったことを前記監視に基づき検出したことに応じてデータ通信不可信号を生成し、前記データ通信不可信号が生成された場合には、予め設定された長さよりも短い周期で前記ＰＰＰサーバにキープアライブメッセージを発行して前記ＰＰＰセッションが遮断していると判定したことに応じて再確立処理を実施する。

【発明の効果】

【0010】

本発明にかかる通信制御装置、通信制御プログラム及びＰＰＰセッションの復旧方法によれば、ＰＰＰセッションの復旧に要する時間を短縮することができる。

【図面の簡単な説明】

【0011】

【図1】実施の形態１にかかる通信システムのブロック図である。

【図2】実施の形態１にかかる通信制御装置のブロック図である。

【図3】実施の形態１にかかるデータ通信監視部の動作を説明するフローチャートである。

【図4】実施の形態１にかかるＰＰＰキープアライブ処理部の動作を説明するフローチャートである。

【図5】実施の形態１にかかる通信システムの動作を説明するシーケンス図である。

【図6】比較例にかかるＰＰＰキープアライブ処理部の動作を説明するフローチャートである。

【図7】比較例にかかるＰＰＰキープアライブ処理を有する通信システムの動作を説明するシーケンス図である。

【図8】実施の形態２にかかるデータ通信監視部の動作を説明するフローチャートである。

【図9】実施の形態３にかかるデータ通信監視部の動作を説明するフローチャートである。

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

【0012】

実施の形態１
以下、図面を参照して本発明の実施の形態について説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。

【0013】

まず、実施の形態１にかかる通信制御装置が用いられる通信システム１のブロック図を図１に示す。そして、図１を参照して通信システム１における通信制御装置の役割について説明する。図１に示すように、実施の形態１にかかる通信システム１は、ユーザ端末１０、ルータ装置１１、ＰＰＰサーバ１２、公衆ネットワーク１３、Ｗｅｂサーバ１４を有する。ルータ装置１１は、実施の形態１にかかる通信制御装置の一例である。通信制御装置は、例えば、ユーザ端末１０に組み込まれていても良い。

【0014】

実施の形態１にかかる通信システム１では、ユーザ端末１０とルータ装置１１とがＬＡＮ（Local Area Network）により通信を行う。ルータ装置１１は、ＰＰＰサーバ１２とＰＰＰセッションにより通信を行う。ＰＰＰサーバ１２は、認証処理に基づき接続を許可するルータ装置１１を制限する。また、ＰＰＰサーバ１２は、ＰＰＰ（Point to Point Protocol）に基づき、ルータ装置１１との間でＰＰＰセッションを確立する。そして、実施の形態１にかかる通信システム１では、ユーザ端末１０がルータ装置１１とＰＰＰサーバ１２との間で確立されているＰＰＰセッションを用いて、公衆ネットワーク１３の先に設置されているＷｅｂサーバ１４との通信を行う。なお、Ｗｅｂサーバ１４は、サービスサーバの一例であり、サービスサーバとしてはＤＮＳ（Domain Name System）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、動画配信サーバ等が考えられる。

【0015】

実施の形態１にかかる通信システム１では、ルータ装置１１とＰＰＰサーバ１２との間でＰＰＰセッションが確立される。このとき、ルータ装置１１は、ＰＰＰセッションの維持を目的としたキープアライブ機能を有する。そこで、図２に実施の形態１にかかるルータ装置１１のブロック図を示し、図２を参照してルータ装置１１について詳細に説明する。

【0016】

図２に示すように、実施の形態１にかかるルータ装置１１は、第１の通信ポート（例えば、ＷＡＮインタフェース２０）、データ通信監視部２１、ＰＰＰキープアライブ処理部２２、第２の通信ポート（例えば、ＬＡＮインタフェース２３）を有する。なお、ルータ装置１１は、ＷＡＮインタフェース２０、データ通信監視部２１、ＰＰＰキープアライブ処理部２２、ＬＡＮインタフェース２３以外の処理部も有しているが、本発明にかかるルータ装置１１の動作とは直接関連しないため、ここでは説明を省略する。

【0017】

ルータ装置１１は、ＷＡＮインタフェース２０をＰＰＰサーバ１２との通信に利用し、ＬＡＮインタフェース２３をユーザ端末１０との通信に用いる。ＷＡＮインタフェース２０は、例えば、ＰＰＰサーバ１２とルータ装置１１との間の物理的な信号の送受信及び送受信するパケットの形式変換等を行う。ＬＡＮインタフェース２３は、例えばルータ装置１１とユーザ端末１０との間の物理的な信号の送受信及び送受信するパケットの形式変換等を行う。

【0018】

また、ルータ装置１１は、ＷＡＮインタフェース２０とデータ通信監視部２１との間に、ルータ装置１１と公衆ネットワーク１３との間で送受信されるデータの制御及びルータ装置１１とＰＰＰサーバ１２の間の通信制御を行う通信処理部を有する。この通信処理部の一部がデータ通信監視部２１及びＰＰＰキープアライブ処理部２２である。

【0019】

データ通信監視部２１及びＰＰＰキープアライブ処理部２２は、個別の処理部として実装することができる。また、別の形態では、データ通信監視部２１及びＰＰＰキープアライブ処理部２２を含む通信処理部は、例えば通信制御プログラムを実行する演算部により実現できる。

【0020】

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

【0021】

データ通信監視部２１は、ユーザ端末１０とＷｅｂサーバ１４との間の通信状態を監視して、ユーザ端末１０からＷｅｂサーバ１４への通信が不調となったことを検出してデータ通信不可信号を出力する。実施の形態１にかかる通信システム１では、データ通信監視部２１は、ユーザ端末１０からＷｅｂサーバ１４に送信されるＴＣＰ（Transmission Control Protocol）に基づく通信で用いられるＴＣＰ ＳＹＮパケットを監視する。ＴＣＰ ＳＹＮパケットは、ＴＣＰパケットのうちＳＹＮフラグがセットされているパケットであって、Ｗｅｂサーバ１４に送信したパケットに対して応答を要求するものである。データ通信監視部２１は、ＴＣＰ ＳＹＮパケットの送信を検出すると、当該ＴＣＰ ＳＹＮパケットに対する応答を確認し、一定時間の間に応答が確認できなければデータ通信不可信号をＰＰＰキープアライブ処理部２２に出力する。

【0022】

ＰＰＰキープアライブ処理部２２は、予め設定された周期でＰＰＰサーバ１２にキープアライブメッセージを発行し、キープアライブメッセージに対するＰＰＰサーバ１２からの応答が得られないことに応じてＰＰＰセッションの再確立処理を実施する。ここで、本実施の形態では、キープアライブメッセージとしてＬＣＰ（Link Control Protocol）エコー要求を用いる。ＬＣＰエコー要求は、ＰＰＰサーバ１２に対して応答を要求するものである。

【0023】

また、ＰＰＰキープアライブ処理部２２は、データ通信監視部２１からデータ通信不可信号を受信した場合、予め定められた周期よりも短い周期でキープアライブメッセージを送信する。特に、実施の形態１にかかるＰＰＰキープアライブ処理部２２は、データ通信不可信号を受信した際に、ＬＣＰエコー要求の再送を行うリトライ処理を実施していなかった場合には、予め定められた周期に関わらず受信したデータ通信不可信号に応じてキープアライブメッセージを送信する。また、ＰＰＰキープアライブ処理部２２は、キープアライブメッセージに対する応答がＰＰＰサーバ１２からあった場合、キープアライブメッセージの送信周期を予め設定された長さに戻す。

【0024】

また、ＰＰＰキープアライブ処理部２２は、ＰＰＰセッションの再確立処理を行うための判断として、ＰＰＰサーバ１２から応答の得られないキープアライブメッセージの送信処理の連続回数がリトライ回数閾値に達したか否かに基づき行う。また、ＰＰＰキープアライブ処理部２２は、データ通信不可信号を受信した場合、当該リトライ回数閾値を小さな値に変更する。なお、ＰＰＰキープアライブ処理部２２は、キープアライブメッセージに対する応答がＰＰＰサーバ１２からあった場合、リトライ回数閾値を予め設定された値に戻す。

【0025】

続いて、実施の形態１にかかるルータ装置１１の動作について詳細に説明する。実施の形態１にかかるルータ装置１１では、データ通信監視部２１とＰＰＰキープアライブ処理部２２とがそれぞれ並列して動作するため、以下の説明では、データ通信監視部２１の動作とＰＰＰキープアライブ処理部２２の動作をそれぞれ個別に説明する。

【0026】

まず、図３に実施の形態１にかかるデータ通信監視部２１の動作を説明するフローチャートを示す。図３に示すように、データ通信監視部２１は、ＰＰＰセッションが開始されたことに応じて処理を開始する。そして、ＰＰＰセッションが開始されると、データ通信監視部２１は、データ通信を監視しながらユーザ端末１０から送信されるＴＣＰ ＳＹＮパケットを待つ（ステップＳ１）。そして、データ通信監視部２１は、ＴＣＰ ＳＹＮパケットの送信を検出すると（ステップＳ２）、ＴＣＰ ＹＳＮパケットの送信履歴をデータ通信監視部２１内の記憶部に保存する（ステップＳ３）。その後、データ通信監視部２１は、Ｗｅｂサーバ１４からＴＣＰ ＳＹＮに対応する応答の有無を確認する（ステップＳ４）。このステップＳ４において、ＴＣＰ ＳＹＮパケットに対する応答が確認された場合、データ通信監視部２１は、次のＴＣＰ ＳＹＮパケットを検知するために、ＴＣＰに基づく通信を監視する（ステップＳ１）。一方、ステップＳ４において、ＴＣＰ ＳＹＮパケットに対する応答が確認出来なかった場合、データ通信監視部２１は、ＰＰＰキープアライブ処理部にデータ通信不可信号を出力する（ステップＳ５）。データ通信不可信号を出力した後、データ通信監視部２１は、次のＴＣＰ ＳＹＮパケットを検知するために、ＴＣＰに基づく通信を監視する（ステップＳ１）。

【0027】

続いて、図４に実施の形態１にかかるＰＰＰキープアライブ処理部２２の動作を説明するフローチャートを示す。図４に示すように、ＰＰＰキープアライブ処理部２２は、ＰＰＰセッションが開始されたことに応じて処理を開始する。ＰＰＰキープアライブ処理部２２は、処理を開始すると、ステップＳ１０〜Ｓ２０のキープアライブ処理とステップＳ２１〜Ｓ２４の条件変更処理とを並列的に実施する。なお、キープアライブ処理と条件変更処理とは、それぞれに含まれる各処理を時分割で実施しても良い。

【0028】

まず、ステップＳ１０〜Ｓ２０のキープアライブ処理について説明する。ステップＳ１０では、ＬＣＰエコー要求を送信する間隔が経過するまで待機し（ステップＳ１０）、送信間隔が経過した後にＰＰＰサーバ１２にＬＣＰエコー要求を送信する（ステップＳ１１）。そして、送信したＬＣＰエコー要求に対応する応答がＰＰＰサーバ１２から得られた場合、次のＬＣＰエコー要求の送信間隔が経過するまで待機する（ステップＳ１２、Ｓ１０）。ここで、図４では、送信したＬＣＰエコー要求に対応する応答がＰＰＰサーバ１２から得られなかった場合、にＬＣＰエコー要求のリトライ送信間隔及びリトライ回数閾値を規定値に戻す処理（ステップＳ１９、Ｓ２０）があるが、ステップＳ２２、Ｓ２３による条件変更が行われなければステップＳ１９、Ｓ２０の処理は行われない。

【0029】

一方、ステップＳ１２で、送信したＬＣＰエコー要求に対応する応答がＰＰＰサーバ１２から得られた場合、ステップＳ１３〜Ｓ１８のリトライ処理を行う。まず、ステップＳ１３では、リトライ処理が連続した回数を示すリトライカウント値をゼロにリセットする。次いで、ＰＰＰキープアライブ処理部２２は、ＬＣＰエコー要求の送信をリトライする間隔が経過するまで待機し（ステップＳ１４）、リトライ送信間隔が経過した後にＰＰＰサーバ１２にＬＣＰエコー要求を送信する（ステップＳ１５）。そして、送信したＬＣＰエコー要求に対応する応答がＰＰＰサーバ１２から得られた場合、次のＬＣＰエコー要求の送信間隔が経過するまで待機する（ステップＳ１６、Ｓ１０）。一方、ステップＳ１６で、送信したＬＣＰエコー要求に対応する応答がＰＰＰサーバ１２から得られなかった場合、ＰＰＰキープアライブ処理部２２は、リトライカウント値を１つ増加させる（ステップＳ１７）。次いで、ＰＰＰキープアライブ処理部２２は、リトライカウント値が予め設定したリトライ回数閾値以上であるか否かを判断する（ステップＳ１８）。このステップＳ１８でリトライカウント値がリトライ回数閾値よりも小さい場合、ＰＰＰキープアライブ処理部２２は、次のＬＣＰエコー要求のリトライ送信間隔が経過するまで待機する（ステップＳ１８、Ｓ１４）。一方、ステップＳ１８においてリトライカウント値がリトライ回数閾値以上であると判断した場合ＰＰＰキープアライブ処理部２２は、ＰＰＰセッションの切断と再確立処理を行う。

【0030】

次いで、ステップＳ２１〜Ｓ２４の条件変更処理について説明する。ステップＳ２１では、データ通信監視部２１が出力したデータ通信不可信号の受信を待機する。そして、データ通信不可信号を受信したことに応じて、ＰＰＰキープアライブ処理部２２は、リトライ送信間隔の短縮（ステップＳ２２）と、リトライ回数閾値の削減（ステップＳ２３）とを実施する。そして、ＰＰＰキープアライブ処理部２２は、現在の処理状態がステップＳ１３以降のＬＣＰエコー要求送信のリトライ処理状態であるか否かを確認する（ステップＳ２４）。ステップＳ２４においてリトライ処理状態であると判断された場合、次のデータ通信不可信号の受信を待機する。一方、ステップＳ２４においてリトライ処理状態ではないと判断された場合、ＰＰＰキープアライブ処理部２２は、エコー送信間隔の経過を待つことなくＬＣＰエコー要求をＰＰＰサーバ１２に送信する。ステップＳ２４の判断に基づきＬＣＰエコー要求を送信したＰＰＰキープアライブ処理部２２は、ステップＳ１４以降の処理を実施する。なお、このステップＳ２２〜Ｓ２４の処理は、割込処理により実施するものとする。

【0031】

続いて、実施の形態１にかかる通信システム１の動作について説明する。そこで、図５に実施の形態１にかかる通信システム１の動作を説明するシーケンス図を示す。なお、図５で示したシーケンス図は、ＬＣＰエコー送信間隔を６０秒、リトライ送信間隔を１０秒、リトライ回数閾値を１０回、データ通信不可信号を受信後のリトライ送信間隔を５秒、データ通信不可信号を受信後のリトライ回数閾値を５回、としたものである。

【0032】

図５に示すように、実施の形態１にかかる通信システム１では、まず、ルータ装置１１とＰＰＰサーバ１２との間でＰＰＰセッションが開始される。その後、ユーザ端末１０とＷｅｂサーバ１４との間で通信が行われる。そして、ユーザ端末１０とＷｅｂサーバ１４との間の通信が正常に行われている間は、ＴＣＰ ＳＹＮパケットに対する応答がユーザ端末１０に届くためルータ装置１１のデータ通信監視部２１は、データ通信不可信号を出力しない。その後ＰＰＰサーバ１２においてＰＰＰセッションの切断が発生すると、ユーザ端末１０からＷｅｂサーバ１４へのアクセスが失敗し、ＴＣＰ ＳＹＮパケットに対する応答が途絶える。これにより、ルータ装置１１のデータ通信監視部２１がデータ通信不可信号を出力する。

【0033】

そして、ＰＰＰキープアライブ処理部２２は、当該データ通信不可信号に応じて、リトライ送信間隔の短縮とリトライ回数閾値の削減とを実施する。また、ＰＰＰキープアライブ処理部２２は、データ通信不可信号を受信したため、エコー送信間隔に関わらず即座にＬＣＰエコー要求をルータ装置１１に送信する。ここで、ＰＰＰセッションが切断されている場合、このＬＣＰエコー要求は失敗する。そのため、ＰＰＰキープアライブ処理部２２は、ＬＣＰエコー要求のリトライ処理が行われる。このとき、ＰＰＰキープアライブ処理部２２では、リトライ送信間隔の短縮及びリトライ回数閾値の削減が行われているため、セッション再確立までの時間が短縮される。

【0034】

このように、ルータ装置１１では、図３、図４で説明した処理を実施することで、ＰＰＰセッションが不調となったときの復旧時間を短縮することができる。以下では、実施の形態１にかかるＰＰＰセッション復旧方法に対する比較例を挙げ、当該比較例との比較により、このＰＰＰセッションの復旧時間の短縮の効果をより詳細に説明する。

【0035】

以下で説明する比較例にかかるＰＰＰセッションの復旧方法は、データ通信監視部の処理を行わずに、ＰＰＰキープアライブ処理部のみでＰＰＰセッションの復旧を行うものである。つまり、比較例にかかるＰＰＰセッションの復旧方法は、ＬＣＰエコー要求の送信間隔を通常時とリトライ処理時との間で切り替えずに、ＬＣＰエコー要求のリトライ処理の失敗に基づきＰＰＰセッションの復旧を行う。

【0036】

そこで、比較例にかかるＰＰＰキープアライブ処理部の動作を説明するフローチャートを図６に示す。図６に示すように、比較例にかかるＰＰＰキープアライブ処理部では、ＬＣＰエコー要求を送信間隔が経過する毎にＰＰＰサーバ１２に送信する（ステップＳ１００、Ｓ１０１）。そして、ＬＣＰエコー要求に対するＰＰＰサーバ１２からの応答があれば、リトライ処理を行うことなく周期的にＬＣＰエコー要求を送信する処理を継続する（ステップＳ１００、Ｓ１０１、Ｓ１０２）。

【0037】

一方、ＬＣＰエコー要求に対するＰＰＰサーバ１２からの応答がない場合、比較例にかかるＰＰＰキープアライブ処理部においてもＬＣＰエコー要求をＰＰＰサーバ１２に周期的に送信し、連続してＰＰＰサーバ１２からの応答がなければ、ＰＰＰセッションの切断及び再確立処理を行う（ステップＳ１０３〜Ｓ１０８）。ここで、図６に示すように、比較例にかかるＰＰＰキープアライブ処理部では、リトライ処理時のリトライ送信間隔は、通常時のＬＣＰエコー要求送信間隔から変更を行う処理は含まれない。

【0038】

上記比較例にかかるＰＰＰキープアライブ処理部を含むを有する通信システムの動作を説明するシーケンス図を図７に示す。図７に示す例は、図５に示した実施の形態１にかかる通信システム１の動作と同じ条件で比較例にかかるＰＰＰキープアライブ処理部を動作させた場合のものである。なお、図７に示す例では、サーバアクセスの失敗がＬＣＰエコー要求を出力した時点より２０秒後にサーバアクセスの失敗が判明した場合のものである。

【0039】

図７に示すように、比較例にかかる通信システムでは、ＬＣＰエコー要求の送信間隔は、通常とリトライ時で同じである。そのため、比較例にかかる通信システムでは、ＬＣＰエコー要求のリトライ送信処理に移行するまでの時間及びリトライ送信処理からセッション再確立を行うまでの時間がいずれも図５に示した実施の形態１にかかる通信システム１よりも多くかかっていることが分かる。

【0040】

上記説明より、実施の形態１にかかる通信システム１は、データ通信監視部２１を有することでユーザ端末１０とＷｅｂサーバ１４との間の通信の不具合を検出することができる。そして、データ通信監視部２１が検出したデータ通信の不具合を検出したことに応じて、ＰＰＰキープアライブ処理部２２がＬＣＰエコー要求のリトライ送信間隔の短縮とリトライ回数閾値の削減との少なくとも一方を実施する。これにより、実施の形態１にかかる通信システム１では、ＰＰＰセッションの切断を復旧するために要する時間を短縮することができる。

【0041】

また、実施の形態１にかかる通信システム１では、ＰＰＰキープアライブ処理部２２がデータ通信監視部２１からデータ通信不可信号を受信したことに応じて、エコー要求送信周期に関わらず、即座にＬＣＰエコー要求を出力する。これによっても、実施の形態１にかかる通信システム１では、ＰＰＰセッションの切断を復旧するために要する時間を短縮することができる。

【0042】

また、実施の形態１にかかる通信システム１では、ＰＰＰセッションがユーザ端末１０とＷｅｂサーバ１４との間の通信に利用されている期間のＰＰＰセッションの不調をデータ通信監視部２１において検出し、当該検出結果に応じてＬＣＰエコー要求の出力を行うことができる。これにより、実施の形態１にかかる通信システム１では、ＰＰＰセッションが確立していても、データ通信には利用されていない期間のルータ装置１１とＰＰＰサーバ１２との間のキープアライブ処理の頻度を下げても通信品質を維持できる。つまり、実施の形態１にかかる通信システム１では、キープアライブ処理に要するパケット通信の通信量を低減して、他の通信に用いられる通信帯域を拡大することができる。

【0043】

また、実施の形態１にかかる通信システム１では、データ通信監視部２１においてデータ通信に不具合が発生したと判断された場合にはリトライ回数閾値を減少させる。これにより、実施の形態１にかかる通信システム１では、ＰＰＰサーバ１２がＬＣＰエコー要求に応答するための処理を削減することができる。

【0044】

実施の形態２
実施の形態２では、データ通信監視部２１が通信の不具合を検出するために監視する対象の別の例について説明する。実施の形態２では、データ通信監視部２１がＰＰＰセッション上に設けられるＴＣＰセッションにおけるＷｅｂサーバ１４からの応答の有無に基づきデータ通信の可能性を判断する。

【0045】

そこで、実施の形態２にかかるデータ通信監視部２１の動作を説明するフローチャートを図８に示す。図８に示すように、実施の形態２においても、データ通信監視部２１は、ＰＰＰセッションが開始されたことに応じて処理を開始する。そして、ＰＰＰセッションが開始されると、データ通信監視部２１は、ＴＣＰ通信を監視した状態で待機する（ステップＳ３１）。そして、データ通信監視部２１は、ＴＣＰコネクションの確立を検知すると（ステップＳ３２）、ＴＣＰコネクションの確立履歴をデータ通信監視部２１内の記憶部に保存する（ステップＳ３３）。その後、データ通信監視部２１は、Ｗｅｂサーバ１４からユーザ端末１０への応答が一定時間内にあれば、次のＴＣＰコネクションの確立を検知するために、ＴＣＰに基づく通信を監視する（ステップＳ３４、Ｓ３１）。一方、ステップＳ３４において、ＴＣＰコネクションにおいてユーザ端末１０に対する応答が一定時間内に確認出来なかった場合、データ通信監視部２１は、ＰＰＰキープアライブ処理部にデータ通信不可信号を出力する（ステップＳ５）。データ通信不可信号を出力した後、データ通信監視部２１は、次のＴＣＰコネクションの確立を検知するために、ＴＣＰに基づく通信を監視する（ステップＳ３１）。

【0046】

上記説明より、実施の形態２では、ＴＣＰコネクションにおけるＷｅｂサーバ１４からユーザ端末１０への応答の有無に基づきデータ通信の可否を判定する。つまり、ユーザ端末１０とＷｅｂサーバ１４との間のデータ通信の可否は、実施の形態１のＴＣＰ ＳＹＮパケットのみならず、Ｗｅｂサーバ１４からの応答を求めるものであれば様々な情報を利用できる。

【0047】

実施の形態３
実施の形態３では、データ通信監視部２１が通信の不具合を検出するために監視する対象の別の例について説明する。実施の形態３では、データ通信監視部２１がＰＰＰセッション上でＤＮＳサーバに送信されるＤＮＳクエリーに対する応答の有無に基づきデータ通信の可能性を判断する。

【0048】

そこで、実施の形態３にかかるデータ通信監視部２１の動作を説明するフローチャートを図９に示す。図９に示すように、実施の形態３においても、データ通信監視部２１は、ＰＰＰセッションが開始されたことに応じて処理を開始する。そして、ＰＰＰセッションが開始されると、データ通信監視部２１は、ＤＮＳ通信を監視した状態で待機する（ステップＳ４１）。そして、データ通信監視部２１は、ＤＮＳクエリーの送信を検知すると（ステップＳ４２）、ＤＮＳクエリーンの送信履歴をデータ通信監視部２１内の記憶部に保存する（ステップＳ４３）。その後、データ通信監視部２１は、Ｗｅｂサーバ１４からユーザ端末１０にＤＮＳクエリーに対する応答が一定時間内にあれば、次のＤＮＳクエリーの送信を検知するために、ＤＮＳに基づく通信を監視する（ステップＳ４４、Ｓ４１）。一方、ステップＳ４４において、ＤＮＳクエリーに対する応答が一定時間内に確認出来なかった場合、データ通信監視部２１は、ＰＰＰキープアライブ処理部にデータ通信不可信号を出力する（ステップＳ５）。データ通信不可信号を出力した後、データ通信監視部２１は、次のＤＮＳクエリーの送信を検知するために、ＤＮＳに基づく通信を監視する（ステップＳ４１）。

【0049】

上記説明より、実施の形態３では、ＤＮＳクエリーに対する応答がＷｅｂサーバ１４からユーザ端末１０にあったか否かに基づきデータ通信の可否を判定する。つまり、ユーザ端末１０とＷｅｂサーバ１４との間のデータ通信の可否は、実施の形態１、２のＴＣＰに関するもののみならず、Ｗｅｂサーバ１４からの応答を求めるものであれば様々な情報を利用できる。

【0050】

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

【符号の説明】

【0051】

１ 通信システム
１０ ユーザ端末
１１ ルータ装置
１２ ＰＰＰサーバ
１３ 公衆ネットワーク
１４ Ｗｅｂサーバ
２０ ＷＡＮインタフェース
２１ データ通信監視部
２２ ＰＰＰキープアライブ処理部
２３ ＬＡＮインタフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】