JP3984965B2 - 通信端末装置及び通信接続装置ならびにこれを用いた通信方法 - Google Patents

Description

本発明は、ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）接続により通信を行なう通信端末装置及び通信接続装置ならびにそれを用いた通信方法に関する。

ＲＦＣ１６６１（非特許文献１）で標準化されているＰＰＰは、ダイアルアップ接続やＩＳＤＮといったようにＷＡＮ回線で直接接続された装置間、移動体通信システムにおける移動無線端末とパケットデータサービング装置間のデータ通信用として使用されている。

ＰＰＰフレームは、ＣＲＣによるエラー訂正を行い、通信エラーの少ない通信を行えるようにしたものである。また、ＰＰＰではフレームのプロトコルフィールドを用いて、「フェーズ」と呼ばれる呼接続や呼切断に関するデータ（以下フェーズ情報と称す）の送受信を行っている。

ＰＰＰ接続／切断に関する基本的なフェーズには、リンク確定（ＬＣＰ：Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）フェーズ、ユーザ認証フェーズ、ネットワークプロトコル（ＮＣＰ：Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）フェーズ、リンク終了フェーズがある。ＬＣＰフェーズは、物理的な回線の接続が完了すると、ＬＣＰを用いデータリンクを確立するものである。

また、ユーザ認証フェーズは、相手のアクセス権限の可否等、ユーザ認証などを行うフェーズである。次に、ＮＣＰフェーズは、ＮＣＰを用いてネットワークの開放等を行うフェーズであり、リンク終了フェーズは、ＬＣＰを用いてＰＰＰリンクを終了させるフェーズである。

ＰＰＰは、ＬＣＰ、及びＮＣＰの二つのプロトコルから構成されて動作しており、ＬＣＰは主にリンク確立制御と認証制御を行い、物理的に回線接続されている上でリンクの確立制御、ユーザ認証制御を行うプロトコルである。ＮＣＰはレイヤ３プロトコル（ネットワ―ク層プロトコル）が使うアドレスの割当を実行するプロトコルである。例えば、ネットワーク層がＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の場合にはＩＰアドレスの割当てを行う機能を備えている。これらのＰＰＰパケットを転送する際には、ＲＦＣ１６６２で規定されているＨＤＬＣ（Ｈｉｇｈ―Ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）Ｌｉｋｅフレームや、ＲＦＣ２５１６で規定されているＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（登録商標）にカプセル化されて転送される。

従来のネットワーク接続においては、非特許文献１に示す通り、無線端末からネットワーク接続を行う際、無線端末からパケットサービングノードへ発呼、ＬＣＰによってリンク確立処理と認証処理とを行い、ＮＣＰによってネットワーク層で使用するアドレスの割当処理を行い、ネットワークへの接続を完了するという手順が行われている。

また、特許文献１には、後続のネゴシエーションで必要となる情報を予め、先行するネゴシエーションで伝送し、後続のネゴシエーション回数を減らし、通接続時間を短縮する技術が開示されている。

特開２０００−２３２４９７号公報 ＲＦＣ１６６１

上述した非特許文献１に示される従来のネットワーク接続方式では、回線接続を行う毎に図１１シーケンスに示すようにＬＣＰのリンク確立であるＬＣＰフェーズ５５０、認証フェーズ５６０、ＮＣＰにおけるアドレス割当処理等のＮＣＰフェーズ５７０が行われる。

しかしながら、ＬＣＰ、認証、ＮＣＰフェーズは、必ずシーケンシャルに行われるため、ＬＣＰフェーズ５５０が終了しなければ認証フェーズ５６０に移行できず、そして最後のＮＣＰフェーズ５７０を終えるまで、ＰＰＰ接続が完了しない為、接続にかなりの時間を要するという問題が生じる。

更に、移動体通信の場合には、短時間での頻繁な接続・切断が多く、ＰＰＰ接続完了までの時間が長い場合、使い勝手の良いものではない。また、接続先が変わり、ＰＰＰの再接続が必要なハンドオーバが生じた場合にも、ＰＰＰ接続時間が長いと接続不可時間が長くなってしまう問題がある。

また、特許文献１に示されるような、予めネゴシエーション情報を送信して接続時間短縮を行う技術は、頻繁に接続先が変わるような通信システムにおいては接続時間短縮の効果はあまり見込めない。

本発明の目的は、ＰＰＰ接続を行う際の接続時間を短縮できる通信端末装置及び通信接続装置を提供するものである。

上記目的を達成するため、本願発明は、ＰＰＰ接続の際のＬＣＰフェーズ、認証フェーズ、ＮＣＰフェーズを平行して実行することにより接続時間を短縮可能としたものである。

具体的には、本願発明による通信端末装置は、ＰＰＰを用いてプロバイダネットワーク、通信接続装置経由で、公衆網に接続される通信端末装置であって、前記ＰＰＰ接続の為のプロトコル処理を行う複数のフェーズ処理部と、前記通信接続装置からのデータを受信するデータ受信部と、前記データ受信部が受信したデータよりフェーズ情報を判別し、適合したフェーズ処理部へ送信するパケット展開部と、前記複数のフェーズ処理部が処理したフェーズ情報を受信し、該複数のフェーズ情報を結合させるフェーズ情報結合部と、前記フェーズ情報結合部が生成したデータをプロバイダネットワークに適合するように変換するカプセル化部と、前記カプセル化部が変換したデータを前記通信接続装置に送信するデータ送信部とを備えたことを特徴とする。

また、本願発明による通信接続装置は、プロバイダネットワークを介し、ＰＰＰを用いて通信端末装置を公衆網に接続させる通信接続装置であって、前記ＰＰＰ接続の為のプロトコル処理を行う複数のフェーズ処理部と、前記通信端末装置からのデータを受信するデータ受信部と、前記データ受信部が受信したデータよりフェーズ情報を判別し、適合したフェーズ処理部へ送信するパケット展開部と、前記複数のフェーズ処理部が処理したフェーズ情報を受信し、該複数のフェーズ情報を結合させるフェーズ情報結合部と、前記フェーズ情報結合部が生成したデータをプロバイダネットワークに適合するように変換するカプセル化部と、前記カプセル化部が変換したデータを前記通信端末装置に送信するデータ送信部とを備えたことを特徴とする。

以上に説明したように、本願発明によれば、従来技術と比べてＰＰＰ接続時間を短縮することができる。

また、移動体通信システムにおいて、接続先が変わり、ＰＰＰの再接続が必要なハンドオーバが生じた場合にもＰＰＰ接続時間が短縮できることで通信不通時間を短くすることができる。

以下に本発明の実施の形態を説明する。

図１は、本発明のネットワーク接続方式を適用した移動体通信システムである。移動体通信システム１においては、無線端末１００−１、１００−２と、無線端末１００−１、１００−２と無線リンクを接続する基地局４００と、無線端末１００−１、１００−２とＰＰＰ接続するパケットデータサービングノード２００−１、２００−２と、通信接続装置（以下、パケットデータサービングノードと称する）２００−１、２００−２が認証時にアクセスする認証サーバ８００から構成される。

ＰＰＰ接続が完了すると、無線端末１００−１、１００−２は、プロバイダネットワーク４１０、パケットデータサービングノード２００−１又は２００−２を介して公衆網（例えば、インターネット）４２０と接続され、インターネット通信、コンテンツ閲覧を行えるようになる。

プロバイダネットワーク４１０とは、一般的なサービスプロバイダが管理するネットワークであり、パケットデータサービングノード２００もサービスプロバイダで管理している場合が多い。

無線端末１００−１、１００−２は、発呼を行うことでパケットデータサービングノード２００−１又は２００−２に対してＰＰＰ接続確立を開始、ＰＰＰ接続が完了した後のデータ送受信が可能となる。

図４は、無線端末１００−１、１００−２の機能構成図である。無線端末１００−１、１００−２は、基地局４００と無線回線の通信を行う無線処理部１０４、パケットデータサービングノード２００−１又は２００−２とＰＰＰ接続を行うＰＰＰ処理部１１０、ＰＰＰで転送されたＩＰパケットを処理するＩＰ処理部１０２、最後にアプリケーションを処理するアプリケーション処理部１０１で構成される。

ＰＰＰ処理部１１０は、無線処理部１０４から無線受信データを受信するデータ受信部１１１、受信したデータからカプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外すカプセル展開部１１２、カプセル展開後のデータをフェーズ毎に展開、各フェーズに転送するフェーズ展開部１１３、ＬＣＰ処理を行うＬＣＰフェーズ部１１４、認証処理を行う認証フェーズ部１１５、ＮＣＰ処理を行うＮＣＰフェーズ部１１６、各フェーズ部から受信した情報を結合するフェーズ結合部１１７、各フェーズ情報を結合したデータをプロバイダネットワーク４１０に適合したフレーム（ＨＤＬＣ−Ｌｉｋｅフレーミングなど）にカプセル化するカプセル化部１１８、カプセル化したデータを無線処理部１０４に送信するデータ送信部１１９から構成される。

また、フェーズ展開部１１３は、カプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外したデータが各フェーズ処理に属さないデータであった場合には、ＩＰ処理部１０２へ転送する機能も備え、フェーズ結合部１１７は、ＩＰ処理部１０２から受信したデータをカプセル化部１１８に転送する機能も備える。従って、ＰＰＰ接続完了後のインターネット通信等のデータは、各フェーズ部を介さず上述の経路でアプリケーション処理部１０１や無線処理部１０４へ転送されることとなる。

図５は、パケットデータサービングノード２００−１、２００−２の機能構成図である。パケットデータサービングノード２００−１、２００−２は、無線側とのインタフェースを持つ無線ＰＨＹ２０１、プロバイダネットワーク４１０と無線セッションを確立する無線処理部２０２、無線端末とＰＰＰ接続を行うＰＰＰ処理部２１０、ＰＰＰの認証フェーズ時に認証サーバ８００にアクセスする認証サーバＩＦ２０４、ＰＰＰによって転送されたＩＰパケットを処理するＩＰ処理部２０５、公衆網４２０へと転送するＩＰ側ＰＨＹ２０６から構成される。

ＰＰＰ処理部２１０は、無線処理部２０２からデータを受信するデータ受信部２１１、受信したデータからカプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外すカプセル展開部２１２、カプセル展開後のデータをフェーズ毎に展開、各フェーズに転送するフェーズ展開部２１３、ＬＣＰ処理を行うＬＣＰフェーズ部２１４、認証処理を行う認証フェーズ部２１５、ＮＣＰ処理を行うＮＣＰフェーズ部２１６、各フェーズ部から受信した情報を結合するフェーズ結合部２１７、各フェーズ情報を結合したデータをプロバイダネットワークに適合したフレームにカプセル化するカプセル化部２１８、無線処理部２０２に送信するデータ送信部２１９から構成される。また、フェーズ展開部２１３は、カプセル（例えばＨＤＬＣフレームフォーマットのヘッダ／フッタ）を外したデータが各フェーズ処理に属さないデータであった場合には、ＩＰ処理部２０５へ転送する機能も備え、フェーズ結合部２１７は、ＩＰ処理部２０５から受信したデータをカプセル化部２１８に転送する機能も備える。

次にＰＰＰ接続する際の結合ＰＰＰパケットについて説明する。図９は従来の通信システムで使われるデータフレーム構成を示した図であり、例としてＲＦＣ１６６２規定のＨＤＬＣ−Ｌｉｋｅフレームを示している。上記フレーム構成は、通信データであるＰＰＰパケット５１０が、ＨＤＬＣ−Ｌｉｋｅフレーミングのヘッダ部５００（ＦＬＡＧ部、アドレス部及び制御部とで構成）と、ＨＤＬＣ−Ｌｉｋｅフレームのフッタ部５２０（ＦＣＳ部、ＦＬＡＧ部とで構成）でカプセル化された（ヘッダ及びフッタで挟まれた）構成となっている。

次に図２は、本発明のデータフレーム構成を示した図であり、図９と同様に例としてＲＦＣ１６６２規定のＨＤＬＣ−Ｌｉｋｅフレームを示している。上記フレーム構成は、通信データであるＬＣＰパケット６０１、認証パケット６０２、ＩＰプロトコルのＮＣＰパケット６０３の３つのＰＰＰパケットを結合したものが、ＨＤＬＣ−Ｌｉｋｅフレーミングのヘッダ部６００と、ＨＤＬＣ−Ｌｉｋｅフレームのフッタ部６０４でカプセル化された構成となっている。

前記結合したＰＰＰパケットは、まず、ＰｒｏｔｏｃｏｌフィールドがＣ０２１のＬＣＰパケット６０１に認証パケット６０２が結合され、次にＮＣＰパケット６０３が結合されている。ここで、認証パケット６０２内のＰｒｏｔｏｃｏｌフィールドのＣ０２３がＰＡＰ（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）認証パケットであることを示している。認証には、ＰＡＰ認証とＣＨＡＰ（Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）認証があり、この認証種別の選択は、ＬＣＰパケットのオプションにて行う。従来技術では、ＬＣＰフェーズで認証種別を決定した後に認証フェーズへと移行するが、本発明ではＬＣＰフェーズと認証フェーズを同時に開始する為にＬＣＰパケット６０１のオプションで指定する認証種別と結合された認証パケット６０２の認証種別は同一にする。例えば、ＬＣＰパケット６０１のオプションでＰＡＰ認証を指定した場合は、結合する認証パケットは、ＰＡＰ認証パケットにする。

また、ＮＣＰパケット６０３内のＰｒｏｔｏｃｏｌフィールドの８０２１がＮＣＰのＩＰプロトコルであるＩＰＣＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であることを示している。

次に結合ＰＰＰパケットを用いたＰＰＰ接続シーケンスを図６にて説明する。以下では、無線端末１００−１とパケットデータサービングノード２００−１がＰＰＰ接続される場合を例に説明する。無線端末１００−１は、ユーザによる発呼要求があると始めに基地局４００と無線セッションを確立、更にはプロバイダネットワーク４１０とパケットデータサービングノード２００−１と無線セッション１５０を確立する。無線セッションの確立（１５０）が完了した後、無線端末１００−１とパケットデータサービングノード２００−１の間にＰＰＰ接続が開始される。無線端末１００−１は、ＬＣＰ、認証、ＩＰＣＰ Ｒｅｑｕｅｓｔを結合した結合ＰＰＰパケットをパケットデータサービングノード２００−１に対して送信する（６１０）。このパケットは、図２と同じ構成である。結合ＰＰＰパケットを受信したパケットデータサービングノード２００−１は、結合ＰＰＰパケットであることを判断すると、ＬＣＰ、認証、ＩＰＣＰパケットに展開して、各フェーズ処理部へと転送する。各フェーズ処理部では、独立した処理を行う。ＬＣＰ処理、認証処理、ＩＰアドレスの取得処理（６２０）が完了するとパケットデータサービングノード２００−１は、各フェーズの結果をＰＰＰパケットのＣｏｄｅフィールドに設定して無線端末へ送信する。

この場合の結合ＰＰＰパケットも図２と同じ構成である。ＩＰＣＰは、ＩＰアドレスを通知する為にＣｏｄｅフィールドにＮＡＣＫという設定したパケットを結合する。パケットデータサービングノード２００−１から各プロトコル処理結果をＰＰＰ結合パケットとして受信（６１３）した無線端末１００−１は、パケットデータサービングノード２００−１同様に各プロトコルパケットに展開して、各フェーズ処理部へと転送する。各フェーズ処理部では、独立して処理を行う。ＬＣＰ−ＡＣＫを受信したＬＣＰ処理部は、ＬＣＰ状態をＲＦＣ１６６１で規定さているＡＣＫ−ＳＥＮＤへと遷移させる。認証処理部は、認証−ＡＣＫパケットを受信した場合には、継続処理、認証−ＮＡＣＫパケットを受信した場合には、ＰＰＰ切断処理へと移行させる。

また、ＩＰＣＰ処理部は、ＮＡＣＫパケットを受信しているので、ＮＡＣＫ要因であるオプションを特定して、再度、ＩＰＣＰ―Ｒｅｑｕｅｓｔをパケットデータサービングノード２００−１へ送信する。オプションがＩＰアドレスの場合には、パケットデータサービングノード２００−１により付与されたＩＰアドレスをＩＰＣＰ−Ｒｅｑｕｅｓｔのオプションに含めて、パケットデータサービングノード２００−１へと送信する。この場合、ＬＣＰ、認証とも終了していれば、結合するものがなくＩＰＣＰ−Ｒｅｑｕｅｓｔパケットのみパケットデータサービングノード２００−１へ送信する（６１４）。再度、無線端末からＩＰＣＰ−Ｒｅｑｕｅｓｔ６１４を受信したパケットデータサービングノード２００−１は、オプションをチェックして、問題がなければ、ＩＰＣＰ−ＡＣＫ６１５を無線端末１００に送信する。パケットデータサービングノード２００―１からＩＰＣＰ−ＡＣＫパケットを受信（６１５）した無線端末１００−１は、ＩＰＣＰ状態をＡＣＫ−ＳＥＮＤへと遷移する。

一方、パケットデータサービングノード２００−１は、無線セッションが確立（１５０）するとＰＰＰ開始と判断して、ＬＣＰ、ＩＰＣＰ―Ｒｅｑｕｅｓｔパケットを結合した結合ＰＰＰパケットを無線端末１００−１に対して送信する（６１１）。通常パケットデータサービングノード２００１から無線端末１００−１に対して認証要求パケットは送信しない為、結合ＰＰＰパケットには、図３のようなＬＣＰとＩＰＣＰの２パケットを結合した結合ＰＰＰパケットとなる。

結合ＰＰＰパケットを受信（６１１）した無線端末１００−１は、ＬＣＰとＩＰＣＰパケットに展開して、個別に処理を始める。ＬＣＰ、ＩＰＣＰ共に処理が終了した後、各処理の結果を結合した結合ＰＰＰパケットとして、パケットデータサービングノード２００−１へと送信する（６１２）。ＬＣＰ、ＩＰＣＰの結果である結合ＰＰＰパケット６１２を受信したパケットデータサービングノード２００−１は、ＬＣＰ、ＩＰＣＰ共にＡＣＫである場合に各状態をＡＣＫ−ＳＥＮＤとする。

無線端末１００−１、パケットデータサービングノード２００−１からのＬＣＰ、ＩＰＣＰ−Ｒｅｑｕｅｓｔに対して、ＡＣＫが戻った場合には、無線端末、パケットデータサービングノード２００−１のＬＣＰ、ＩＰＣＰ状態をＡＣＫ−ＳＥＮＤからＯＰＥＮへと遷移させて、ＰＰＰ接続が完了する。

次に結合ＰＰＰパケットを受信した無線端末１００−１、およびパケットデータサービングノード２００−１のＰＰＰ処理部での処理フローを図７で説明する。始めにステップ７０１では、ＰＰＰパケットの受信を待ち、ＰＰＰパケットの受信があった場合には、ステップ７１７に進む、ステップ７１７では、プロバイダネットワークに適合するようにカプセル化されたフレームからカプセル化を外す処理を行う。カプセル展開後、ステップ７５０進む。ステップ７５０では、受信ＰＰＰパケットがＬＣＰ、認証、ＩＰＣＰのどのプロトコルに当たるかプロトコルフィールドを解読して、各フェーズ処理へ転送する。受信フレームが複数プロトコルの結合で構成されていた場合には、解読したプロトコル毎に対応するフェーズ処理へ転送する。解読した結果がＬＣＰであった場合にはステップ７０２、認証の場合はステップ７０５、ＩＰＣＰの場合には、ステップ７１０に転送する。

図７では、ステップ７０２、７０３、７０４がＬＣＰフェーズ、ステップ７０５、７０６、７０７、７０８、７０９が認証フェーズ、ステップ７１０、７１１、７１２、７１３、７１４がＮＣＰフェーズに対応しており、ＰＰＰ処理部のＬＣＰフェーズ部、認証フェーズ部、ＮＣＰフェーズ部で処理される。

ステップ７０２は、ＬＣＰ処理であり、ＬＣＰのオプションを解読して、ステップ７０３に転送する。ステップ７０３では、ＬＣＰオプションが許容できるか判断する。全てのオプションで許容できる場合には、ステップ７０４に進みＡＣＫ処理を行う。

ステップ７０５は、認証処理であり、認証を識別する。例えばＣＨＡＰやＰＡＰ等を識別する。識別が完了したらステップ７０６に進み認証処理を行う。認証処理は、同一装置内の認証データベースとの照合や、認証サーバ８００への問い合わせを行う。

認証結果が成功であった場合には、ステップ７０８に進みＡＣＫ/Ｓｕｃｃｅｓｓ処理、認証結果が失敗であった場合には、ステップ７０９に進みＮＡＣＫ/Ｆｉｌｕｒｅ処理を行う。次にステップ７１０は、ＩＰＣＰ処理である。先ず、オプションを解読・展開して、ステップ７１１に進む。

ＩＰＣＰのオプションは、ＩＰアドレスやＤＮＳアドレスの確認があり、オプションにアドレスが格納されている。格納されているアドレスがシステムで許容する適切な場合には、ステップ７１３に進みＡＣＫ処理を実施する。また、アドレスが適切でない場合には、アドレス取得を行いＮＡＣＫ処理７１４にて適切なアドレスを通信相手に通知する。ＬＣＰ、認証、ＩＰＣＰと全ての処理を終えるとステップ７１５に進みフェーズ情報結合処理を行う。このステップ７１５は、各フェーズでの結果を結合したフレームを生成して、ステップ７１６に転送する。ステップ７１５からフレームを受け取ったステップ７１６は、プロバイダネットワークに適合したフレームにカプセル化して無線処理部へと転送する。

次にステップ７５０のＰＰＰフェーズ展開処理フローについて図８にて説明する。始めにステップ７５１でプロトコルを識別する。ＰＰＰパケットの先頭にあるプロトコルフィールドには、ＬＣＰや認証を識別する値が入っている。次に識別したプロトコルのＣｏｄｅ識別７５２である。Ｃｏｄｅフィールドを識別することで、受信したパケットがＲｅｑｕｅｓｔなのかＡＣＫ、もしくはＮＡＣＫかを識別することができる。Ｃｏｄｅを識別した後は、ステップ７５３に進みパケット中のＬｅｎｇｔｈ値に従ったデータを抽出して、ステップ７５４の各プロトコル処理部へと転送する。次にステップ７５５に進み他のプロトコルパケットが存在しているか、否かを判断して存在している場合には、ステップ７５１に戻り処理を繰り返す。他のプロトコルパケットが存在していない場合には、終了となる。

上述した結合ＰＰＰパケットを使ってＬＣＰ、認証、ＩＰＣＰを同時に処理開始することで従来のＰＰＰ接続と比較してＰＰＰ接続時間を短縮することができる。さらに、ＰＰＰ再接続が生じるパケットデータサービングノード間ハンドオフの場合において、接続時間の短縮によって通信不通時間の短縮ができる。

また、本実施の例では、ＰＰＰのカプセルにＲＦＣ１６６２のＨＤＬＣ−Ｌｉｋｅフレーミングを使用したが、本発明はカプセス方式に依存しないためＲＦＣ２５１６のＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔにも適用できる。

次に、実施の形態２について説明する。本発明を適用するシステムは、図１と同じであり、例えば、無線端末１００−１とパケットデータサービングノード２００−１間は、ＰＰＰ接続される。実施の形態１では、ＬＣＰ、認証、ＮＣＰフェーズが同時に開始することを特徴の一つとしている。ＬＣＰ交渉には、認証種別の決定がある。

例えば、ＰＡＰにするかＣＨＡＰにするか等の決定である。システムによって事前に決定する場合には、実施の形態１でよいが、複数ある場合には、ＬＣＰ交渉が決定した後に認証フェーズを実施した方が都合が良い。実施の形態２では、ＬＣＰ交渉が完了した後、認証とＮＣＰフェーズを同時に開始することを特徴とする。実施の形態２を適用したＰＰＰ接続シーケンスを図１２で説明する。

無線セッションの確立（１５０）後、無線端末１００−１とパケットデータサービングノード２００−１間のＰＰＰ接続が開始する。ＬＣＰフェーズ９００は、従来の交渉と同じである。ＬＣＰ交渉の完了後、無線端末１００−１は、パケットデータサービングノード２００−１に対して認証、ＩＰＣＰ−Ｒｅｑｕｅｓｔを結合した結合ＰＰＰパケット９１０を送信する。この際に結合する認証パケットは、ＬＣＰフェーズ９００で決定した認証種別にする。

パケットデータサービングノード２００−１は、無線端末１００−１からのＰＰＰ結合パケットを受信（９１０）後、図７の処理フローにより認証とＩＰＣＰパケットとに展開して、各々の処理を開始する。パケットデータサービングノード２００−１は、認証処理・ＩＰＣＰ処理（９１１）が完了した後に処理結果を結合ＰＰＰパケットとして無線端末１００に送信する（９１２）。この際にパケットデータサービングノード２００−１から無線端末へとＩＰＣＰ−Ｒｅｑｕｅｓｔを結合しても良い。

結合ＰＰＰパケットを受信（９１２）した無線端末１００−１は、結合ＰＰＰパケットを各々のＰＰＰパケットに展開した後、独立に処理する。認証処理は、Ｓｕｃｃｅｓｓパケットであるので認証完了、ＩＰＣＰ処理は、ＩＰＣＰ−ＮＡＣＫのオプションに格納されているＩＰアドレスの設定を行う。また、ＩＰＣＰ−Ｒｅｑｕｅｓｔパケットも結合されているのでＩＰＣＰ処理を行う。

無線端末１００−１は、各処理終了後、パケットデータサービングノード２００−１に送信すべきパケットがある場合には、そのパケットを結合してパケットデータサービングノード２００−１へと送信する。この図では、パケットデータサービングノード２００−１から付与されたＩＰアドレスをオプションに含めたＩＰＣＰ−Ｒｅｑｕｅｓｔパケットとパケットデータサービングノード２００−１からのＩＰＣＰ−Ｒｅｑｕｅｓｔに対する応答であるＩＰＣＰ−ＡＣＫを結合して送信する（９１３）。このパケットを受信したパケットデータサービングノード２００−１は、各ＰＰＰパケットを処理して、ＩＰＣＰ―Ｒｅｑｕｅｓｔに対する応答であるＩＰＣＰ−ＡＣＫを無線端末１００−１に送信する（９１４）ことでＩＰＣＰ交渉完了となる。

上述した結合ＰＰＰパケットを使って認証、ＩＰＣＰを同時に処理開始することで従来のＰＰＰ接続と比較してＰＰＰ接続時間を短縮することができる。

次に、実施の形態３について説明する。本発明を適用するシステムは、図１と同じである。無線端末１００−１およびパケットデータサービングノード２００−１から送出されるパケットは、新たに定義するパケットを用いる。前記の通り、ＰＰＰパケットは、図１０に示す先頭のプロトコル５１１によって各フェーズを識別することができる。このプロトコル５１１には、ＲＦＣ標準に定義されていない未使用の番号があり、未使用番号に接続短縮用パケットを示す番号を定義し、この１つの接続短縮用パケットにＬＣＰ、認証、ＩＰＣＰフェーズの情報を含ませることで、接続交渉する際のシーケンス数を減らすことができる。

図１３は、本実施例で使用する接続短縮用ＰＰＰパケットをＨＤＬＣ−Ｌｉｋｅフレーミングにカプセル化した図である。この図では、ＰＰＰパケット８０２のプロトコル８０４は、Ｆ０２１（Ｆ０００〜ＦＦＦＦはＲＦＣ標準では未使用）として使用している。

この接続短縮用パケットを処理する無線端末１００−１とパケットデータサービングノード２００−１の構成は、図４、図５と実施例１、２と同様である。無線端末１００−１の処理は、無線処理部１０４を介して受信したデータは、ＰＰＰ処理部１１０に転送され、データ受信部１１１、カプセル展開部１１２を介してフェーズ展開部１１３へと転送される。フェーズ展開部１１３では、ＰＰＰパケットのプロトコルを識別して、識別した結果、システムで定義した接続短縮用パケットと判断すると、このパケットに含まれるＬＣＰ、認証、ＮＣＰ情報を抽出して、抽出したデータをＬＣＰフェーズ部１１４、認証フェーズ部１１５、ＮＣＰフェーズ部１１６へと転送する。各フェーズ処理の完了後、各フェーズの結果情報を各フェーズからフェーズ結合部１１７へと転送する。フェーズ結合部１１７では、各フェーズから受信した結果情報を接続短縮用パケットに挿入して、カプセル化１１８、データ送信部１１９、無線処理部１０４を介して、パケットデータサービングノードへと送信する。

一方、パケットデータサービングノード２００−１は、無線側ＰＨＹ２０１で受信したデータを無線処理部２０２、データ受信部２１１、カプセル展開部２１２を介して、フェーズ展開部２１３へと転送する。フェーズ展開部２１３では、ＰＰＰパケットのプロトコルを識別して、識別した結果、システムで定義した接続短縮用パケットと判断すると、このパケットに含まれるＬＣＰ、認証、ＮＣＰ情報を抽出して、抽出したデータをＬＣＰフェーズ部２１４、認証フェーズ部２１５、ＮＣＰフェーズ部２１６へと転送する。各フェーズ処理の完了後、各フェーズの結果情報を各フェーズからフェーズ結合部２１７へと転送する。フェーズ結合部２１７では、受信した結果情報を接続短縮用パケットに挿入して、カプセル化２１８、データ送信部２１９、無線処理部２０２、無線側ＰＨＹ２０１を介して、無線端末１００−１へと送信する。

次にＰＰＰ接続シーケンスを図１４を用いて説明する。無線端末１００−１は、無線セッション８１０を確立後、接続短縮用ＰＰＰパケット８１１をパケットデータサービングノード２００−１へ送信する。このデータ８１１を受信したパケットデータサービングノード２００−１は、カプセル展開した後にＰＰＰパケットを抽出して、プロトコルを識別する。識別の結果、システムで定義した接続短縮用ＰＰＰパケットと判断した場合には、ＬＣＰ、認証、ＩＰＣＰ情報を抽出して、各フェーズ処理を行う。ＬＣＰ、認証、ＮＣＰ処理が完了するとその結果を接続短縮用パケット８１２に挿入して無線端末１００−１へと送信してＰＰＰ接続完了となる。

上述したＰＰＰパケットのプロトコルに接続短縮用パケットを定義する番号を割り当て、そのパケット内容にＬＣＰ、認証、ＮＣＰの情報を含めて、１つのＰＰＰパケットで３フェーズの情報を端末―パケットデータサービングノード間でやり取りすることで接続時間を短縮することができる。

また、上記実施例では、無線端末１００−１とパケットデータサービングノード２００−１がＰＰＰ接続される場合を説明したが、接続先が変わり（例えば、パケットデータサービングノード２００−１からパケットデータサービングノード２００−２）、ＰＰＰの再接続が必要なハンドオーバが生じた場合にも本発明を適用できる。

さらに、上記実施例では、端末として無線端末の場合を例に説明したが、有線端末であっても本発明を適用できる。この場合、パケットデータサービングノードは、一般にアクセスサーバと呼ばれ、上記同様の処理により、有線端末とアクセスサーバ間でＰＰＰ接続が可能となる。

本発明を適用した移動体通信システムの構成を表した図である。 本発明を適用したＬＣＰ、認証、ＩＰＣＰパケットを結合した結合ＰＰＰパケット図である。 本発明を適用したＬＣＰ、ＩＰＣＰパケットを結合した結合ＰＰＰパケット図である。 本発明を適用した無線端末の機能構成図である。 本発明を適用したパケットデータサービングノードの機能構成図である。 本発明を適用した実施の形態１のＰＰＰ接続シーケンス図である。 本発明を適用した結合ＰＰＰパケットの受信処理フローを表した図である。 本発明を適用した結合ＰＰＰパケットを各ＰＰＰパケットに展開する処理フローを表す図である。 従来のＨＤＬＣ−Ｌｉｋｅフレーミングにカプセル化されたＰＰＰパケット構成を表した図である。 ＰＰＰパケット構成を表した図である。 従来のＰＰＰ接続シーケンスを表す図である。 本発明を適用した実施の形態２のＰＰＰ接続シーケンス図である。 本発明を適用した実施の形態３のＨＤＬＣ−Ｌｉｋｅフレームにカプセル化されたＰＰＰパケットを表す図である。 本発明を適用した実施の形態３のＰＰＰ接続シーケンス図である。

符号の説明

１００・・・無線端末、２００・・・通信接続装置、４００・・・基地局、４１０・・・プロバイダネットワーク、４２０・・・公衆網、８００・・・認証サーバ、１０１・・・アプリケーション処理部、１０２、２０５・・・ＩＰ処理部、２０１・・・無線側ＰＨＹ、１０４、２０２・・・無線処理部、１１０、２１０・・・ＰＰＰ処理部、２０６・・・ＩＰ側ＰＨＹ、１１１、２１１・・・データ受信部、１１２、２１２・・・カプセル展開部、１１３、２１３・・・フェーズ展開部、１１４、２１４・・・ＬＣＰフェーズ部、１１５、２１５・・・認証フェーズ部、１１６、２１６・・・ＮＣＰフェーズ部、１１７、２１７・・・フェーズ結合部、１１８、２１８・・・カプセル化部、１１９、２１９・・・データ送信部

Claims (6)

1. ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信網に接続される通信端末装置であって、
   前記ＰＰＰ接続の為の制御処理を複数並列に行なう複数のフェーズ処理部と、
   通信相手からのデータを前記通信網から受信するデータ受信部と、
   前記データ受信部が受信したデータよりフェーズ情報を判別し、前記複数のフェーズ処理部のうちの適合したフェーズ処理部へ該フェーズ情報を送信するとともに前記フェーズ処理に属さないデータである場合には、前記ＰＰＰで転送されたＩＰパケットを処理するＩＰパケット処理部に転送するフェーズ展開部と、
   前記複数のフェーズ処理部が処理したフェーズ情報を受信し、該複数のフェーズ情報のうち、認証種別決定のためのフェーズ情報と、認証のためのフェーズ情報の認証種別が同一となるように、かつ該制御フェーズ情報のＰＰＰプロトコルフィールドの情報を変更せずに該複数のフェーズ情報を結合させるフェーズ情報結合部と、
   前記フェーズ情報結合部が生成したデータを前記通信網に適合するように変換するカプセル化部と、
   前記カプセル化部が変換したデータを前記通信相手に前記通信網を介して送信するデータ送信部と、
   を備えたことを特徴とする通信端末装置。
2. ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末装置を通信網に接続させる通信接続装置であって、
   前記ＰＰＰに係る複数の制御フェーズ情報を、認証種別決定のためのフェーズ情報と、認証のためのフェーズ情報の認証種別が同一となるように、かつ該制御フェーズ情報のＰＰＰプロトコルフィールドの情報を変更せずに結合させるフェーズ情報結合部と、
   前記フェーズ情報結合部が生成したデータを前記通信網に適合するように変換するカプセル化部と、
   前記カプセル化部が変換したデータを前記通信端末装置に送信するデータ送信部と、
   を備えたことを特徴とする通信端末装置。
3. ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信端末装置を通信網に接続させる通信接続装置であって、
   前記ＰＰＰ接続の為の制御処理を複数並列に行なう複数のフェーズ処理部と、
   前記通信端末装置からのデータを受信するデータ受信部と、
   前記データ受信部が受信したデータよりフェーズ情報を判別し、前記複数のフェーズ処理部のうちの適合したフェーズ処理部へ該フェーズ情報を送信するとともに前記フェーズ処理に属さないデータである場合には、前記ＰＰＰで転送されたＩＰパケットを処理するＩＰパケット処理部に転送するフェーズ展開部と、
   前記複数のフェーズ処理部が処理したフェーズ情報を受信し、該複数のフェーズ情報のうち認証種別決定のためのフェーズ情報と、認証のためのフェーズ情報の認証種別が同一となるように、かつ該制御フェーズ情報のＰＰＰプロトコルフィールドの情報を変更せずに該複数のフェーズ情報を結合させるフェーズ情報結合部と、
   前記フェーズ情報結合部が生成したデータを前記通信網に適合するように変換するカプセル化部と、
   前記カプセル化部が変換したデータを前記通信網を介して前記通信端末装置に送信するデータ送信部と、
   を備えたことを特徴とする通信接続装置。
4. ＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）を用いて通信網に接続された通信端末装置と通信接続装置との間を通信する方法であって、
   送信側装置が前記ＰＰＰ接続の為の制御処理を複数並列に行い、複数の制御フェーズに関する情報を生成し、該複数の情報を、該複数の情報のうち、認証種別決定のためのフェーズ情報と、認証のためのフェーズ情報の認証種別が同一となるように、かつ該それぞれの情報のＰＰＰプロトコルフィールドの情報を変更せずに結合し、該結合したデータを第１のデータとして前記通信網を介して受信側装置に送信すると、
   前記受信側装置は、受信した前記複数の情報を結合した第１のデータからそれぞれの情報を判別し、該情報に対応した制御処理を複数並列に行い、該複数の制御結果に関する情報を、該複数の情報のうち、認証種別決定のためのフェーズ情報と、認証のためのフェーズ情報の認証種別が同一となるように、かつ該それぞれの制御結果に関する情報のＰＰＰプロトコルフィールドの情報を変更せずに結合して第２のデータとして前記通信網を介して前記送信側装置に送信することを特徴とする通信端末装置と通信接続装置の通信方法。
5. 上記フェーズ処理部は、ＬＣＰフェーズ処理部と、認証フェーズ処理部と、ＮＣＰフェーズ処理部とから構成され、
   上記フェーズ情報結合部は、ＬＣＰ情報、認証情報、ＮＣＰ情報を組み合わせて結合させることを特徴とする請求項１に記載の通信端末装置。
6. 上記フェーズ処理部は、ＬＣＰフェーズ処理部と、認証フェーズ処理部と、ＮＣＰフェーズ処理部とから構成され、
   上記フェーズ情報結合部は、ＬＣＰ情報、認証情報、ＮＣＰ情報を組み合わせて結合させることを特徴とする請求項３に記載の通信接続装置。

Images