(57)【要約】【課題】  ＰＰＰ接続を行う際の接続時間を短縮できる通信接続装置及び通信端末を提供する。【解決手段】  ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、通信端末からのＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求パケットを受信する受信部と、前記受信部により受信した前記ＮＣＰ開始要求パケットの情報から、該パケット送信元の通信端末が実装するプロトコルを判断し、該プロトコル対応のＮＣＰ開始要求パケットを該パケットの送信元通信端末に送信するように制御する制御部とを備える。【選択図】  図４
2005269289.tif 000002
【特許請求の範囲】
【請求項１】
プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、
ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末からのＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求パケットを受信する受信部と、
前記受信部により受信した前記ＮＣＰ開始要求パケットの情報から、該パケット送信元の通信端末が実装するプロトコルを判断し、該プロトコル対応のＮＣＰ開始要求パケットを該パケットの送信元通信端末に送信するように制御する制御部と、
を備えたことを特徴とする通信接続装置。
【請求項２】
プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、
ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末に対して、複数のプロトコル各々に対応した複数のＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求パケットを送信する送信部と、
前記通信端末から、前記複数のプロトコルの何れかのプロトコルに対応したＮＣＰ開始要求パケットを受信する受信部と、
前記受信部により受信した前記ＮＣＰ開始要求パケットの情報から、該パケット送信元の通信端末が実装するプロトコルを判断し、該プロトコル対応の接続許可パケットを前記ＮＣＰ開始要求パケットの送信元通信端末に送信するように制御する制御部と、
を備えたことを特徴とする通信接続装置。
【請求項３】
プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、
ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末に対して、前記通信端末が実装しているプロトコル対応のＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求パケットを送信する送信部と、
前記通信端末から、前記プロトコルに対応したＮＣＰ開始要求パケットを受信する受信部と、
前記プロトコル対応の接続許可パケットを前記ＮＣＰ開始要求パケットの送信元通信端末に送信するように制御する制御部と、
を備えたことを特徴とする通信接続装置。
【請求項４】
ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて、プロバイダネットワーク、通信接続装置経由で公衆網に接続される通信端末であって、
ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、、前記通信接続装置からＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求パケットを受信する受信部と、
前記受信部により受信した前記ＮＣＰ開始要求パケットの情報からプロトコル種別を判断し、自装置が実装しているプロトコルと判断した場合、該プロトコル対応のＮＣＰ開始要求パケットを前記通信接続装置に送信するように制御する制御部と、
を備えたことを特徴とする通信端末。
【請求項５】
前記制御部は、前記ＮＣＰ開始要求パケットの情報から判断したプロトコル種別が、自装置が実装していないプロトコルと判断した場合、前記受信部で受信した前記ＮＣＰ開始要求パケットを廃棄することを特徴とする請求項４記載の通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＰＰＰ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）接続により通信を行う通信接続装置及び通信端末に関する。
【背景技術】
【０００２】
ＲＦＣ１６６１で標準化されているＰＰＰ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）は、ダイアルアップ接続やＩＳＤＮといったようにＷＡＮ回線で直接接続された装置間、移動体通信システムにおける移動無線端末とパケットデータサービングノード装置間のデータ通信用として使用されている。
【０００３】
ＰＰＰフレームは、ＣＲＣによるエラー訂正を行い、通信エラーの少ない通信を行えるようにしたものである。また、ＰＰＰではフレームのプロトコルフィールドを用いて、「フェーズ」と呼ばれる呼接続や呼切断に関するデータ（以下フェーズ情報と称す）の送受信を行っている。
【０００４】
ＰＰＰ接続／切断に関する基本的なフェーズには、リンク確定（ＬＣＰ：Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）フェーズ、ユーザ認証フェーズ、ネットワークプロトコル（ＮＣＰ：Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）フェーズ、リンク終了フェーズがある。ＬＣＰフェーズは、物理的な回線の接続が完了すると、ＬＣＰを用いデータリンクを確立するものである。  また、ユーザ認証フェーズは、相手のアクセス権限の可否等、ユーザ認証などを行うフェーズである。次に、ＮＣＰフェーズは、ＮＣＰを用いてネットワークの開放等を行うフェーズであり、リンク終了フェーズ は、ＬＣＰを用いてＰＰＰリンクを終了させるフェーズである。
【０００５】
ＰＰＰは、ＬＣＰ、及びＮＣＰの二つのプロトコルから構成されて動作しており、ＬＣＰは主にリンク確立制御と認証制御を行い、物理的に回線接続されている上でリンクの確立制御、ユーザ認証制御を行うプロトコルである。ＮＣＰはレイヤ３プロトコル（ネットワ―ク層プロトコル）が使うアドレスの割当を実行するプロトコルである。例えば、ネットワーク層がＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の場合にはＩＰアドレスの割当を行う機能を備えている。これらのＰＰＰパケットを転送する際には、ＲＦＣ１６６２で規定されているＨＤＬＣ−Ｌｉｋｅ（Ｈｉｇｈ  Ｌｅｖｅｌ  Ｄａｔａ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ−Ｌｉｋｅ）フレームや、ＲＦＣ２５１６で規定されているＰＰＰｏＥ（ＰＰＰ  ｏｖｅｒ  Ｅｔｈｅｒｎｅｔ）（登録商標）にカプセル化されて転送される。  更に、ＮＣＰはレイヤ３プロトコルで決められているＩＰアドレスの割当などを行う機能を備えているほか、レイヤ３プロトコルの種別が、１６進数で８０２１（ＩＰｖ４制御プロトコル）、１６進数で８０２９（Ａｐｐｌｅ Ｔａｌｋ制御プロトコル）、１６進数で８０５７（ＩＰｖ６制御プロトコル）といったように複数定義されている。例えば、ＩＰｖ４とは、ＲＦＣ７９１で規定されているネットワーク層（レイヤ３）のプロトコルであり、パケット（ＦＴＰやＴＣＰなどのデータ）を転送相手に届けるための経路選定の取り決めを行っている。この経路選定には、ＩＰアドレスといった３２ビットの数字によって決められており、最大約４２億台のアドレスを識別することができる。
【０００６】
しかし、近年のインターネットの急速な普及により、アドレス資源の枯渇が生じるとの危惧が高まり、１２８ビットでアドレスを表現するＲＦＣ２４６０で規定されたＩＰｖ６が開発され、今後のインターネット通信への適用が望まれている。
【０００７】
上記説明したようなＰＰＰパケットを送信するには、プロバイダネットワークに応じて、上記ＨＤＬＣ−ＬｉｋｅフレームやＲＦＣ２５１６で規定されているＰＰＰｏＥにカプセル化して転送しなければならない。
【０００８】
図２は、通信端末１００とパケットデータサービングノード(ＰＤＳＮ)６００間をＰＰＰでネットワークに接続している通信システムにおける従来の接続シーケンスである。ＰＤＳＮ６００がＩＰｖ４およびＩＰｖ６プロトコルを実装し、通信端末１００がＩＰｖ６プロトコルのみを実装している場合は、まず、通信端末１００とＰＤＳＮ６００がＬＣＰフェーズ７００を開始し、各々ＬＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット７０１、７０２を送信し、ＬＣＰ交渉が成立し、認証処理８００が終了した後、ＮＣＰ＃１フェーズ１２００、ＮＣＰ＃ｎフェーズ１２０７に移行する。ＰＤＳＮ６００は実装している全てのＮＣＰフェーズを開始するにあたり、ＩＰｖ４用のＩＰＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０１およびＩＰｖ６用のＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２を通信端末１００へ送信する。
【０００９】
一方、通信端末１００は、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３をＰＤＳＮ６００へ送信し、受信したＩＰＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０１に対して、ＬＣＰ  Ｐｒｏｔｏｃｏｌ  Ｒｅｊｅｃｔパケット１２０４を返信する。ＬＣＰ  Ｐｒｏｔｏｃｏｌ  Ｒｅｊｅｃｔパケット１２０４とは、通信端末１００が実装していないＩＰｖ４プロトコルを拒否するメッセージである。
【００１０】
ＰＤＳＮ６００は、通信端末１００からＩＰｖ４プロトコルを拒否するＬＣＰ  Ｐｒｏｔｏｃｏｌ  Ｒｅｊｅｃｔパケット１２０４を受けた場合、ＮＣＰ＃１フェーズ１２００終了と判断して、拒否されたプロトコルに対してのＮＣＰ交渉を終了させる。
【００１１】
次に、ＰＤＳＮ６００は通信端末１００から受信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３に対して、接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋパケット１２０５を送信する。このパケットを受信した時点で通信端末１００接続準備が完了となる。
【００１２】
最後に、ＰＤＳＮ６００が送信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２に対して、通信端末１００から接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋパケット１２０６を受信すると、ＰＤＳＮ６００の接続準備が完了となり、ＩＰｖ６ネットワーク通信を許容するＰＰＰ接続が完了する。
【００１３】
このように従来のＰＰＰ使用によるネットワーク接続では、非特許文献１に開示されているように接続したい端末がＰＤＳＮへ発呼を行い、ＬＣＰによる接続確立およびユーザ認証の交渉を行う。その後、ＮＣＰにおいてＰＤＳＮが実装している全てのプロトコル種別の交渉を行うという手順により、ＰＰＰ接続が行われている。
【００１４】
【非特許文献１】ＲＦＣ１６６１
【発明の開示】
【発明が解決しようとする課題】
【００１５】
上述した従来のＰＰＰを使用したネットワーク接続において、ＰＰＰ機能の１つであるＮＣＰは、複数のレイヤ３プロトコルが規定されており、各々にＮＣＰ交渉を行う。複数のレイヤ３プロトコルとは、例えばアプリケーションによってＩＰｖ４通信が必要なものと、ＩＰｖ６通信が必要なものとに分かれている場合、ＰＰＰ接続は、ＩＰｖ４用ＮＣＰ（ＩＰＣＰ）とＩＰｖ６用ＮＣＰ（ＩＰｖ６ＣＰ）と２つのＮＣＰのリンク確立を行う必要がある。
【００１６】
しかし、複数のレイヤ３プロトコルをサポートする通信システムにおいて、パケットデータサービングノードは、端末がどのレイヤ３プロトコルを実装しているか判別できない為、システムで許容する全てのレイヤ３プロトコルに対応するＮＣＰ交渉を行わなければならない。その交渉の結果、端末がサポートしているレイヤ３プロトコルのみＮＣＰ交渉が成功し、ＰＰＰ通信を行うことが可能となる。
【００１７】
しかしながら、この従来のＮＣＰ交渉では、図２のＮＣＰ＃１フェーズ１２００のようにパケットデータサービングノード６００は端末１００が実装していないレイヤ３プロトコルのＮＣＰ交渉も行うため、ＮＣＰフェーズでのシーケンス数が増加して、その結果、ＰＰＰ接続時間までも増加する問題が発生する。特に移動体通信システムの場合には、短時間での接続・切断が多いため、接続時間はできるだけ短いほうが好ましい。
【００１８】
また、接続先（パケットデータサービングノード）が変わり、ＰＰＰの再接続が必要なハンドオーバが生じた場合にもＰＰＰ接続時間が長い場合には、接続不可時間が長くなってしまう問題がある。
【００１９】
本発明の目的は、ＰＰＰ接続を行う際の接続時間を短縮できる通信接続装置及び通信端末を提供するものである。
【課題を解決するための手段】
【００２０】
上記目的を達成するため、本願請求項１に係る通信接続装置は、プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末からのＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求（Ｒｅｑｕｅｓｔ）パケットを受信する受信部と、前記受信部により受信した前記ＮＣＰ開始要求パケットの情報（ＮＣＰ プロトコル フィールド）から、該パケット送信元の通信端末が実装するプロトコル（例えば、ＩＰｖ６）を判断し、該プロトコル（ＩＰｖ６）対応のＮＣＰ開始要求パケットを該パケットの送信元通信端末に送信するように制御する制御部と、を備えたことを特徴とする。
【００２１】
上記構成により、ＰＰＰ接続時のＮＣＰフェーズにおいて、通信接続装置は、通信端末が実装しているプロトコル対応のＮＣＰ開始要求パケットのみを通信端末に送信すればよいので、通信接続装置が実装している全てのプロトコル種別の交渉を行う必要がなく、ＰＰＰ接続時間を短縮できる。
【００２２】
また本願請求項２に係る通信接続装置は、プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末に対して、複数のプロトコル各々（例えば、ＩＰｖ４、ＩＰｖ６）に対応した複数のＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求（Ｒｅｑｕｅｓｔ）パケットを送信する送信部と、前記通信端末から、前記複数のプロトコルの何れかのプロトコル（例えば、ＩＰｖ６）に対応したＮＣＰ開始要求パケットを受信する受信部と、前記受信部により受信した前記ＮＣＰ開始要求パケットの情報から、該パケット送信元の通信端末が実装するプロトコル（ＩＰｖ６）を判断し、該プロトコル（ＩＰｖ６）対応の接続許可（Ａｃｋ）パケットを前記ＮＣＰ開始要求パケットの送信元通信端末に送信するように制御する制御部と、を備えたことを特徴とする。
【００２３】
上記構成により、ＰＰＰ接続時のＮＣＰフェーズにおいて、通信接続装置は、複数のプロトコル対応のＮＣＰ開始要求パケットを通信端末に送信しても、通信端末が実装しているプロトコル対応のＮＣＰ開始要求パケットのみを受信するので、その後通信端末が実装していないプロトコル用のＮＣＰ処理は不要となり、ＰＰＰ接続時間を短縮できる。
【００２４】
さらに本願発請求項３に係る通信接続装置は、プロバイダネットワークを介し、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末を公衆網に接続させる通信接続装置であって、ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、前記通信端末に対して、前記通信端末が実装しているプロトコル（例えば、ＩＰｖ６）対応のＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求（Ｒｅｑｕｅｓｔ）パケットを送信する送信部と、前記通信端末から、前記プロトコル（ＩＰｖ６）に対応したＮＣＰ開始要求パケットを受信する受信部と、前記プロトコル（ＩＰｖ６）対応の接続許可（Ａｃｋ）パケットを前記ＮＣＰ開始要求パケットの送信元通信端末に送信するように制御する制御部と、を備えたことを特徴とする。
【００２５】
すなわち、本願請求項３に係る通信接続装置は、予め通信端末のプロトコル種別を記憶部に登録しておくことにより、ＰＰＰ接続を行う通信端末のプロトコル（ＩＰｖ６）がわかるので、これ以外のプロトコル用のＮＣＰ処理は不要となり、ＰＰＰ接続時間を短縮できる。
【００２６】
また本願請求項４に係る通信端末は、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて、プロバイダネットワーク、通信接続装置経由で公衆網に接続される通信端末であって、ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）処理と認証処理を完了した後、、前記通信接続装置からＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）開始要求（Ｒｅｑｕｅｓｔ）パケットを受信する受信部と、前記受信部により受信した前記ＮＣＰ開始要求パケットの情報（ＮＣＰ プロトコル フィールド）からプロトコル種別を判断し、自装置が実装しているプロトコル（例えば、ＩＰｖ６）と判断した場合、該プロトコル（ＩＰｖ６）対応のＮＣＰ開始要求パケットを前記通信接続装置に送信するように制御する制御部と、を備えたことを特徴とする。
【００２７】
そして、本願請求項５に係る通信端末に備える前記制御部は、前記ＮＣＰ開始要求パケットの情報から判断したプロトコル種別が、自装置が実装していないプロトコル（例えば、ＩＰｖ４）と判断した場合には、前記受信部で受信した前記ＮＣＰ開始要求パケットを廃棄することを特徴とする。
【００２８】
上記構成により、通信端末は、通信接続装置から複数のプロトコル対応のＮＣＰ開始要求パケットを受信しても、自装置が実装しているプロトコル用のＮＣＰ処理のみを行えばよいので、ＰＰＰ接続時間を短縮できる。
【発明の効果】
【００２９】
以上説明したように、本願発明によれば、通信端末と通信接続装置との間のＰＰＰ接続時間を短縮することができる。
【００３０】
また本願発明によれば、接続先が変わり、ＰＰＰの再接続が必要なハンドオーバが生じた場合にも、ＰＰＰ接続時間を短縮でき、これによって通信不通時間を短縮できる。
【００３１】
さらに本願発明によれば、ＰＰＰ接続のためのシーケンス数が減らすことができるので、システムにおける無線リソースの効率化を図ることが期待できる。
【発明を実施するための最良の形態】
【００３２】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【実施例１】
【００３３】
図１は、本発明を適用した通信通信システムの全体構成を示す図である。移動体通信システム１は、通信端末１００、１５０、１６０と、これら通信端末と無線リンクを接続する基地局４００と、通信端末とＰＰＰ接続される通信接続装置（本実施例では、パケットデータサービングノード）２００−１、２００−２から構成される。以下、通信接続装置（パケットデータサービングノード）をＰＤＳＮと称する。
【００３４】
通信端末は、ＩＰｖ４通信を用いて公衆ＩＰｖ４網に接続する端末１５０、ＩＰｖ６通信を用いて公衆ＩＰｖ６網に接続する端末１００、ＩＰｖ４/ＩＰｖ６両方の通信機能（デュアルスタック機能）を搭載した通信端末１６０があり、システム内に混在する。各端末は、ＰＰＰ接続が完了すると、プロバイダネットワーク、ＰＤＳＮ２００−１を介して公衆ＩＰｖ４網５０１や公衆ＩＰｖ６網５０２と接続し、インターネット通信、コンテンツ閲覧を行えるようになる。
【００３５】
通信端末１００、１５０、１６０は、図１２に示すように、プロセッサ１２１０と、プロセッサが実行するプログラムを記憶するメモリ（記憶部）１２１１と、基地局４００とのインタフェース（パケット送受信部）１２１２を備えている。
【００３６】
図３は、プロセッサ１２１０が実行するプログラムの機能を図示したもので、基地局４００から受信したパケットがＰＰＰパケットか否かの判断や基地局との無線回線の通信を行うパケット処理部１０４と、ＰＤＳＮ２００−１又は２００−２とＰＰＰ接続を行うＰＰＰ処理部１１０と、ＰＰＰで転送されたＩＰパケットを処理するＩＰ処理部１０２と、アプリケーションを処理するアプリケーション処理部１０１の各機能部から構成されている。
【００３７】
更にＰＰＰ処理部１１０は、パケット処理部１０４からのデータを受信するデータ受信部１１１、受信したデータからカプセル（例えば、ＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外すカプセル展開部１１２、カプセル展開後のＰＰＰデータのプロトコルを判断して、各フェーズに転送するプロトコル判断部１１３、ＬＣＰ処理を行うＬＣＰフェーズ部１１４、ＮＣＰ毎に処理するＮＣＰフェーズ部１１５、１１６（ＩＰｖ４、ＩＰｖ６通信と２つのＮＣＰが存在する場合には、２つのＮＣＰフェーズが存在）、起動するフェーズを決定するスケジュール部１２０、各フェーズ部から受信したデータをプロバイダネットワークに適合したフレーム（ＨＤＬＣ−Ｌｉｋｅフレーミングなど）にカプセル化するカプセル化部１１８、カプセル化したデータをパケット処理部１０４に送信するデータ送信部１１９の各機能部から構成されている。
【００３８】
また、プロトコル判断部１１３は、カプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外したデータが各フェーズ処理に属さないデータであった場合には、ＩＰ処理部１０２へ転送する機能も備え、カプセル化部１１８は、ＩＰ処理部１０２から受信したデータをカプセル化してデータ送信部１１９に転送する機能も備える。従って、ＰＰＰ接続完了後のインターネット通信等のデータは、各フェーズ部を介さず上述の経路でアプリケーション処理部１０１やパケット処理部１０４へ転送されることとなる。
【００３９】
次にＰＤＳＮ２００−１、２００−２は、図１３に示すように、プロセッサ１３１０と、プロセッサが実行するプログラムを記憶するメモリ（記憶部）１３１１と、ＩＰ網５０１、５０２とのインタフェース（パケット送受信部）１３１２と、プロバイダネットワーク５００とのインタフェース（パケット送受信部）１３１３とを備えている。
【００４０】
図４は、ＰＤＳＮ２００−１、２００−２の機能構成を示す図である。図４は、プロセッサ１３１０が実行するプログラムの機能を図示したもので、ＰＰＰパケットか否かの判断やプロバイダネットワーク５００とのセッションを確立するパケット処理部２０２と、通信端末１００とＰＰＰ接続を行うＰＰＰ処理部２１０と、ＰＰＰ処理部によって転送されたＩＰパケットを処理するＩＰ処理部２０５の各機能部から構成されている。
【００４１】
更にＰＰＰ処理部２１０は、パケット処理部２０２からのデータを受信するデータ受信部２１１と、受信したデータからカプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外すカプセル展開部２１２と、カプセル展開後のデータを各フェーズに転送するプロトコル判断部２１３と、プロトコル判断部２１３で判断したＮＣＰ情報を元に動作可能にするＮＣＰフェーズ部を決定する決定部２１９と、ＬＣＰ処理を行うＬＣＰフェーズ部２１４と、ＮＣＰ毎に処理するＮＣＰフェーズ部２１５、２１６と、各フェーズ部から受信したデータをプロバイダネットワークに適合したフレームにカプセル化するカプセル化部２１７とパケット処理部２０２にカプセル化されたフレームを送信するデータ送信部２１８の各機能部から構成される。
【００４２】
また、プロトコル判断部２１３は、カプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外したデータが各フェーズ処理に属さないデータであった場合には、ＩＰ処理部２０５へ転送する機能も備え、カプセル化部２１７は、ＩＰ処理部２０５から受信したデータをカプセル化してデータ送信部２１８に転送する機能も備える。
【００４３】
図８は、通信端末１００とＰＤＳＮ２００−１間で送受信されるＰＰＰフレームである。ＰＰＰフレームは、ＨＤＬＣ−Ｌｉｋｅフレーミングにカプセル化されており、ＦＬＡＧ、アドレス、制御フィールドからなるＨＤＬＣヘッダ８１１と、ＦＣＳ、ＦＬＡＧからなるＨＤＬＣフッタ８１２によってＰＰＰパケット８１３が挟まれた形で構成される。
【００４４】
また、ＰＰＰパケット８１３は、図９に示すようにＰｒｏｔｏｃｏｌ８１４、Ｃｏｄｅ８１５、ＩＤ８１６、Ｌｅｎｇｔｈ８１７、Ｏｐｔｉｏｎ  Ｄａｔａ８１８の各フィールドによって構成される。先頭のＰｒｏｔｏｃｏｌ８１４フィールドは、ＮＣＰのレイヤ３プロトコル種別を識別するフィールドであり、ＩＰｖ４は８０２１ｈ（ｈは１６進数を示す）、ＩＰｖ６は８０５７ｈ、Ａｐｐｌｅ  Ｔａｌｋは８０２９ｈとＲＦＣ１３４０で規定されている。又、ＬＣＰパケットかＮＣＰパケットかの識別もＰｒｏｔｏｃｏｌ８１４フィールドで行う。更に、ＲｅｑｕｅｓｔパケットかＡｃｋパケットかの識別は、Ｃｏｄｅ８１５フィールドで行う。
【００４５】
次に、通信端末とＰＤＳＮ間のＰＰＰ接続手順について説明する。以下、通信端末として１００、ＰＤＳＮとして２００−１を例に説明する。
【００４６】
図５は、通信端末１００とＰＤＳＮ２００−１間でのＰＰＰ接続シーケンスを示した図である。通信端末１００とＰＤＳＮ２００−１は、お互いにＬＣＰフェーズ７００よるリンク接続およびユーザ認証８００の交渉を行い、リンク確立およびユーザ認証成立後、ＮＣＰフェーズ１０００に移行する。
【００４７】
ＮＣＰフェーズ１０００が開始すると、ＰＤＳＮ２００−１は、通信端末１００からのＮＣＰパケットを待ち、通信端末１００よりなんらかのＮＣＰパケットを受信するまではＰＤＳＮ２００−１は受信待ち状態にはいる。
【００４８】
ＰＤＳＮ２００−１が受信待ち状態時に、通信端末１００からＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１００１を受信すると、その受信データは、パケット処理部２０２、データ受信部２１１を介してカプセル展開部２１２に転送される。カプセル展開部２１２では、プロバイダネットワークに適合したフレーム（ＨＤＬＣヘッダ、ＨＤＬＣフッタ）を外して、プロトコル判断部２１３へ転送する。プロトコル判断部２１３では、受信したデータがＩＰｖ６用ＮＣＰであることを判断すると、ＩＰｖ６処理を行うＮＣＰフェーズ（ＮＣＰ＃ｎ２１６と仮定）へとデータを転送して、受信データがＩＰｖ６用ＮＣＰであることを決定部２１９へ通知する。
【００４９】
決定部２１９では、通信先が実装するＮＣＰはＩＰｖ６と判断した後、ＩＰｖ６に対応するＮＣＰ＃ｎフェーズ部２１６に対して動作可能指示を与える。
【００５０】
ＮＣＰ＃ｎフェーズ部２１６では、決定部２１９より動作可能指示を受けると端末１００に対して、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１００２をカプセル化部２１７に対して送信する。カプセル化部２１７により受信データがカプセル化され、データ送信部２１８、パケット処理部２０２により必要な処理がなされた後通信端末１００に送信される。
【００５１】
また、ＮＣＰ＃ｎフェーズ部２１６により、プロトコル判断部２１３から転送されたデータ１００１が処理されると、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋ１００３がカプセル化部２１７、データ送信部２１８、パケット処理部２０２により必要な処理がなされ、通信端末１００に送信される。この後、通信端末１００からＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋパケット１００４を受信した後、ＩＰｖ６用のＮＣＰ交渉が成立し、ＩＰｖ６ネットワークのＰＰＰ接続が完了する。
【００５２】
次に、ＰＤＳＮ２００−１のＰＰＰ処理部２１０の動作を図６のフローチャートを用いて説明する。まず始めに、ステップ７５１では、決定部２１９のＬＣＰ開始指示によりＬＣＰリンク設定要求パケットを送信し、ステップ７５２に進む。ステップ７５２では、ＬＣＰフェーズ部２１４においてＬＣＰの接続確立やユーザ認証などの交渉を開始する。ステップ７５２でＬＣＰ交渉が成立し、ＬＣＰリンクが確立した場合は、ＬＣＰフェーズ部２１４から決定部２１９へＬＣＰ完了通知を行い、ステップ７５３に進む。ステップ７５３では、通信相手からのＮＣＰリンク設定要求パケットを待つ。この間、各ＮＣＰフェーズ部では、動作停止の状態となっており、リンク確立動作は開始できない。
【００５３】
通信相手からのパケットがプロトコル判断部２１３に転送されると、プロトコル判断部２１３では、受信パケットがＮＣＰパケットであるか判断する。ＮＣＰパケットと判断した場合、ステップ７５４に進む。ステップ７５４では、受信したＮＣＰパケットのＰｒｏｔｏｃｏｌ８１４フィールドから、どのプロトコル種別か識別して、ステップ７６０に進む。ステップ７６０は、決定部２１９で実行される処理であり、ステップ７５４で識別されたＮＣＰ種別と対応するＮＣＰフェーズ部に対して動作開始指示を行う。指示されたＮＣＰフェーズが＃１であれば、ステップ７５５に、ＮＣＰ＃ｎであればステップ７５７へと進む。例えば、ステップ７５７と進んだ場合、ステップ７５７は、ＮＣＰ＃ｎのリンク設定要求パケットを送信しＮＣＰフェーズを開始する。その後、ステップ７５８にて、ＮＣＰ＃ｎのリンク確立が完了した場合、ステップ７５９に進みＰＰＰ接続が完了する。
【００５４】
次に、端末１００のＰＰＰ処理部１１０の動作を図７のフローチャートを用いて説明する。始めに、ステップ７７１では、スケジュール部１２０のＬＣＰ開始指示によりＬＣＰリンク設定要求パケットを送信し、ステップ７７２に進む。ステップ７７２では、ＬＣＰフェーズ部１１４においてＬＣＰの接続確立やユーザ認証などの交渉を開始する。ステップ７７２でＬＣＰ交渉が成立し、ＬＣＰリンクが確立した場合は、ＬＣＰフェーズ部１１４からスケジュール部１２０へＬＣＰ完了通知を行い、ステップ７７３に進む。ステップ７７３は、スケジュール部で実行される処理であり、端末として使用するＮＣＰ種別は、予め設定されている場合やアプリケーション処理部１０１から指定される場合がある。このステップ７７３によって、各ＮＣＰフェーズ処理へと実行開始が指示される。ＮＣＰ＃１であれば、ステップ７７４に、ＮＣＰ＃ｎであれば、ステップ７７６に進む。例としてステップ７７４に進んだ場合には、ＮＣＰ＃１のリンク設定を開始して、ステップ７７５にて、ＮＣＰ＃１のリンク確立が完了した後、ステップ７７８に進みＰＰＰ接続が完了する。
【００５５】
このように、ＰＤＳＮから送信するＮＣＰパケットを、通信相手から受信したＮＣＰパケットのプロトコル種別と同一とすることで必要のないレイヤ３プロトコルの交渉を減らし、ＰＰＰ接続時間の短縮が可能となる。
【実施例２】
【００５６】
実施例１のＮＣＰフェーズにおいては、ＮＣＰフェーズの起動を通信端末１００からのＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１００１で行ったが、従来どおり、ＰＤＳＮ２００−１から、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケットを通信端末１００に送信することでも、同様の効果を達成することができる。
【００５７】
具体的には、図１０を用いて説明する。認証処理８００までは、図２の従来技術の動作シーケンスと同じなので省略する。
【００５８】
ＰＤＳＮ２００−１は実装している全てのＮＣＰフェーズを開始するにあたり、ＩＰｖ４用のＩＰＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０１およびＩＰｖ６用のＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２を通信端末１００へ送信する。
【００５９】
一方、通信端末１００は、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３をＰＤＳＮ６００へ送信し、受信したＩＰＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０１は、無視し廃棄する。
【００６０】
次に、ＰＤＳＮ６００は、通信端末１００から受信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３に対して、接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｕｇｒｅ  Ａｃｋパケット１２０５を送信する。このパケットを受信した時点で通信端末１００接続準備が完了となり、ＰＤＳＮ２００−１は、ＩＰｖ４用のＮＣＰフェーズを中止する。
【００６１】
最後に、ＰＤＳＮ６００が送信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２に対して、通信端末１００から接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋパケット１２０６を受信すると、ＰＤＳＮ６００の接続準備が完了となり、ＩＰｖ６ネットワーク通信を許容するＰＰＰ接続が完了する。
【００６２】
このように、通信回線のトラフックを少なくすることができるうえ、通信端末１００及びＰＤＳＮ２００−１での処理が減ることで、その他の処理時間の速度が上がり、ひいては接続時間の短縮につながる。
【実施例３】
【００６３】
図１１を用いて説明する。認証処理８００までは、図２の従来技術の動作シーケンスと同じ同じなので省略する。
【００６４】
ＰＤＳＮ２００−１は実装している全てのＮＣＰフェーズを開始するにあたり、図４に示す決定部２１９内のプロトコル指定部２１９１の指示のもと、予め指定されているプロトコルのＮＣＰフェーズ部へＮＣＰ Ｒｅｑｕｅｓｔパケットを送出するよう指示する。
【００６５】
その指示に従い、ＮＣＰ処理部（例えば指定されたプロトコルが、ＩＰｖ６の場合）が、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２を通信端末１００へ送信する。
【００６６】
一方、通信端末１００は、ＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３をＰＤＳＮ６００へ送信する。
【００６７】
次に、ＰＤＳＮ６００は、通信端末１００から受信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０３に対して、接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｕｇｒｅ  Ａｃｋパケット１２０５を送信する。このパケットを受信した時点で通信端末１００接続準備が完了とる。最後に、ＰＤＳＮ６００が送信したＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ｒｅｑｕｅｓｔパケット１２０２に対して、通信端末１００から接続可能を示すＩＰｖ６ＣＰ  Ｃｏｎｆｉｇｕｒｅ  Ａｃｋパケット１２０６を受信すると、ＰＤＳＮ６００の接続準備が完了となり、ＩＰｖ６ネットワーク通信を許容するＰＰＰ接続が完了する。
【００６８】
前記プロトコル指定部２１９１への指定する手段は、ＰＤＳＮ２００−１の管理者が、対向で通信を行う端末のプロトコル種別を把握し登録するものである。また、図４の決定部２１９内の統計処理部２１９２により、ＰＰＰ接続が完了した際にそのプロトコル種別を全てメモリに記憶して統計をとり、頻度の高いプロトコル種別を、プロトコル指定部２１９１へ指示してもよい。
【００６９】
このように、使用するプロトコル種別を直接指定したり又は、使用頻度の高いプロトコル種別を自動的に選択（予測）指定して、ＰＰＰ接続を開始することで、ＰＰＰ接続時間の短縮が行えるようになる。
【００７０】
もちろん、実施例１、実施例２及び実施例３に開示した技術を備えた通信端末及びＰＤＳＮを用い、その機能を選択して使用することでユーザのニーズにあった接続時間の短縮が行えることはいうまでもない。
【００７１】
また、上記実施例では、無線端末１００−１とパケットデータサービングノード２００−１がＰＰＰ接続される場合を説明したが、接続先が変わり（例えば、パケットデータサービングノード２００−１からパケットデータサービングノード２００−２）、ＰＰＰの再接続が必要なハンドオーバが生じた場合にも本発明を適用できる。
【００７２】
さらに、上記実施例では、通信端末として無線端末の場合を例に説明したが、有線端末であっても本発明を適用できる。この場合、通信接続装置は、一般にアクセスサーバと呼ばれ、上記同様の処理により、有線端末とアクセスサーバ間でＰＰＰ接続が可能となる。
【図面の簡単な説明】
【００７３】
【図１】本発明を適用した通信システム全体の構成を示す図である。
【図２】従来のＰＰＰ接続シーケンスを示した図である。
【図３】通信端末１００、１５０、１６０に備えるプロセッサ１２１０が実行するプログラムの機能を示す図である。
【図４】パケットデータサービングノード２００−１、２００−２が備えるプロセッサ１３１０が実行するプログラムの機能を示す図である。
【図５】本発明の第１の実施形態によるＰＰＰ接続シーケンス図である。
【図６】パケットデータサービングノードでのＰＰＰ処理を示すフローチャートである。
【図７】通信端末でのＰＰＰ処理を示すフローチャートである。
【図８】ＨＤＬＣ−Ｌｉｋｅフレーミングにカプセル化されたＰＰＰパケット構成を表した図である。
【図９】ＰＰＰパケット構成を表した図である。
【図１０】本発明の第２の実施形態によるＰＰＰ接続シーケンス図である。
【図１１】本発明の第３の実施形態によるＰＰＰ接続シーケンス図である。
【図１２】通信端末の構成を示すブロック図である。
【図１３】パケットデータサービングノードの構成を示すブロック図である。
【符号の説明】
【００７４】
１００、１５０、１６０・・・通信端末、２００−１、２００−２・・・通信接続装置、４００・・・基地局、５００・・・プロバイダネットワーク、５０１・・・公衆ＩＰｖ４網、５０２・・・公衆ＩＰｖ６網、１０１・・・アプリケーション処理部、１０２、２０５・・・ＩＰ処理部、１０４、２０２・・・パケット処理部、１１０、２１０・・・ＰＰＰ処理部、１１１、２１１・・・データ受信部、１１２、２１２・・・カプセル展開部、１１３、２１３・・・プロトコル判断部、１１４、２１４・・・ＬＣＰフェーズ部、１１５、２１５・・・ＮＣＰ＃１フェーズ部、１１６、２１６・・・ＮＣＰ＃ｎフェーズ部、１１８、２１７・・・カプセル化部、１１９、２１８・・・データ送信部、１２１０、１３１０・・・プロセッサ、１２１１、１３１１・・・メモリ、１２１２・・・基地局インタフェース、１３１２・・・ＩＰ網インタフェース、１３１３・・・プロバイダネットワークインタフェース
【図１】
2005269289.tif 000003
【図２】
2005269289.tif 000004
【図３】
2005269289.tif 000005
【図４】
2005269289.tif 000006
【図５】
2005269289.tif 000007
【図６】
2005269289.tif 000008
【図７】
2005269289.tif 000009
【図８】
2005269289.tif 000010
【図９】
2005269289.tif 000011
【図１０】
2005269289.tif 000012
【図１１】
2005269289.tif 000013
【図１２】
2005269289.tif 000014
【図１３】
2005269289.tif 000015