JP2001086156A - 拡張ｐｐｐフレームを用いた通信システム - Google Patents

Abstract

(57)【要約】 【課題】２地点間でのマルチプロトコルの多重通信を可
能とするＰＰＰ（pointto Point Protocol)を使った、
通信端末と通信回線、アクセスサーバからなる通信シス
テムにおいて、毎回接続の都度、接続確立のために、繰
り返し行うオプションデータ確認の為のネゴシェーショ
ン時間を短縮し、インターネットサービスプロバイダへ
のアクセスがインターネット接続かトンネリング接続か
の判別を簡単に行い、リアルタイム通信等に対する優先
制御を迅速に行いたい。 【解決手段】 従来のＰＰＰのフレーム構成におい
て、固定値としているアドレスフィールドと制御フィー
ルドを活用し、オプションデータの組合せを識別する為
の識別コード値、ＩＳＰアクセス時のアクセスモードの
識別コード値や転送先アドレス値、優先順番と対応させ
た上位プロトコルやアプリケーションの識別コード値と
することによって解決を図る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、１対１の２点間通
信環境下において、近年、とくにインターネットサービ
スプロバイダ（以下ＩＳＰ）とのダイヤルアップ接続を
中心に、広く普及している標準通信処理プロトコルＰＰ
Ｐ（Point to Point Protocol)の機能を拡張した拡張Ｐ
ＰＰフレームを用いた通信システムに関し、とくに、通
信端末からアクセスサーバへのアクセスにおいて、高速
の接続処理、優先処理を実現する拡張ＰＰＰフレームを
用いた通信システムに関する。

【０００２】現在、ＰＰＰは、図１５のダイヤルアップ
接続によるＰＰＰを利用したアクセスサーバへの接続イ
メージに示す如く、パソコンと電話回線用のモデムによ
る通信端末やＩＳＤＮ接続用のダイヤルアップルータな
どに通信処理プロトコル・ソフトのひとつとして組み込
まれている。

【０００３】ＰＰＰ処理ソフトは、パソコンやアクセス
サーバの内部の他の通信処理ソフトや関連デバイスと連
携を取りながら、公衆通信回線を介した、インターネッ
トやイントラネットにおける通信端末とアクセスサーバ
との接続処理を行っており、現在、広く使われている。

【０００４】最も、一般的な使い方は、図１６のＰＰＰ
を使った複数端末とアクセスサーバとの接続に示す如
く、インターネットやイントラネットに、遠隔地のサテ
ライトオフィス、家庭や移動先から公衆通信網を使っ
て、複数のユーザが、一つのアクセスサーバに、パケッ
ト転送によりタイムシェリング的に、同時アクセスする
ケースである。

【０００５】ＰＰＰは、元々は、インターネット標準文
書のＲＦＣ１６６１で述べている如く、上位のネットワ
ーク層においてベンダの違いによる各種のマルチプロト
コルを同時に使いながら、２地点間を公衆回線や専用線
で結んで通信を行うことを目的に開発された。

【０００６】すなわち、ＰＰＰは、３層以上のマルチベ
ンダによるマルチプロトコルのパケットを複数同時に伝
送することが出来る。

【０００７】したがって、一本のＰＰＰ接続回線上で，
同時に、複数のアプリケーションが時間的にシェアした
り、図１５の（ｂ）のダイヤルアップルータ接続の場合
に示す如く、複数の端末からのパケットデータを時間的
にシェアしながら同時に転送することができる。

【０００８】インターネットで代表的なネットワークプ
ロトコルであるＴＣＰ／ＩＰでは、ＰＰＰ層の上にのり
ながら、上のＩＰ層でパケットの優先制御を行うことも
出来る。

【０００９】現在のインターネット利用のマルチメディ
ア化の急激な進展傾向から判断すると、今後はＰＰＰ接
続形態として、従来のメールやＷＥＢサーバアクセス利
用などに加えて、２点間通信において、音声や動画像通
信などのリアルタイム通信を同時に行う利用形態が増え
ると予測される。

【００１０】このような場合には、音声などのリアルタ
イムデータに対するＰＰＰパケットに対して優先的に回
線利用を行わせる優先制御機能を現在よりさらに迅速・
効果的にサポートできることが望ましい。

【００１１】また、現在、インターネットでは、ＩＰｖ
６などの新しいプロトコルが導入されつつあるが、これ
らの新しいプロトコルを使った音声や画像などのマルチ
キャストなどのリアルタイムのマルチメディア放送的な
使い方も今後普及が進むと予測されている。

【００１２】この様な使い方においては、従来のＩＰｖ
４や他のプロトコルと区別して、これらの新しいプロト
コルの優先度を上げて通したい等のマルチプロトコル間
での優先順位付けを行いたいニーズもある。

【００１３】また、サテライトオフィスやＳＯＨＯ等の
在宅勤務形態、モバイルコンピューティングの普及と共
に、通信料金削減を目的に、遠隔の出張先から最寄りの
ＩＳＰにアクセスして、ＩＳＰのネットワークを経由し
て、遠隔地の企業サーバにアクセスし、電子メールやＷ
ＥＢサーバを使ったりするケースも増えると予測され
る。

【００１４】このような場合に、通信料金を節約し、通
信確立時間の短縮を図る為に、交換接続確立後は、アク
セスの都度、毎回繰り返して行う上位の通信プロトコル
による通信処理をなるべく簡単に迅速に行えるように
し、ネゴシエーション時間を短縮し、交換接続後、すぐ
に通信利用ができるようにしたい。

【００１５】本発明は、このようなニーズに応える従来
のＰＰＰで現在未使用のデフォルトフィールドを活用し
た、音声等のリアルタイム通信データに対する迅速な優
先制御や、ダイヤルアップ接続時の迅速な接続処理を実
現する、拡張ＰＰＰフレームを用いた通信システムを提
供するものである。

【００１６】

【従来の技術】ＰＰＰは、現在、インターネット関連の
標準文書であるＲＦＣ(Request for Comment) の文書番
号１６６１、１６６２、１６６３の文書に、その内容が
規定されている。

【００１７】図１７のＯＳＩ参照モデルとＰＰＰの関
係、図１８のＰＰＰによるマルチプロトコルのカプセル
化の説明図に、ＰＰＰプロトコルが第２層のデータリン
ク層で使われ、ＰＰＰ層の上に、各種のマルチプロトコ
ルがカプセル化されて搭載されて通信が行われることを
示す。

【００１８】すなわち、ＰＰＰでは、第３層以上の上位
のプロトコルに依存しないで、データリンク層の共通の
通信プロトコルで確認接続を行う事によって、カプセル
化されたマルチプロトコルの転送処理を可能とすること
ができる。

【００１９】このマルチプロトコル転送処理を行う為
に、図１８に示す如く、データリンク層の中はさらに物
理層との連携処理を行うＬＣＰ（Link Control Protoco
l)と、上位のマルチプロトコルとのデータ授受を行うＮ
ＣＰ（Network Control Protocol) の２階層に分かれ
る。

【００２０】ＰＰＰは、元々は、主に１対Ｎの通信接続
環境下においてバイナリデータ転送を高速に信頼性良く
行うことを目的としたＨＤＬＣ（High-level Data Link
Control）プロトコルの技術をベースとする通信処理プ
ロトコルである。

【００２１】ＨＤＬＣプロトコルは、図１９のＨＤＬＣ
によるデータ通信の形態例に示す如く、ホストコンピュ
ータと端末装置間等の１対Ｎのデータ通信通信環境を中
心に広く使われていたデータリンク層レイヤ２のパケッ
ト通信方式の標準通信プロトコルである。

【００２２】ＰＰＰは、ＨＤＬＣをベースに、ベンダの
違いによるマルチプロトコルの差異を吸収して遠隔地間
で１対１通信を行うために開発された。

【００２３】このため、その基本的なフレーム構成は、
図２０のＰＰＰフレームフォーマットとＨＤＬＣフレー
ムフォーマットの比較に示す如く、ＨＤＬＣと共通の構
成を有している。

【００２４】ＰＰＰのフレーム構成を、インターネット
の技術委員会であるＩＥＴＦ（Internet Engineering T
ask Force)では、先の標準文書中でＨＤＬＣライクフレ
ーミングとも呼んでいる。

【００２５】ＰＰＰプロトコルは、１対１接続において
全２重通信形式の送受対等の平衡通信モードで使われる
ため、ＨＤＬＣプロトコルにおける複数の相手先アドレ
ス指定機能や通信モード指定機能は不要であり、これら
の機能は使われていない。

【００２６】すなわち、ＨＤＬＣフレームの持つ機能か
らＰＰＰでは不要なアドレス指定、通信モードの切替制
御や待ち合わせ制御、パケット番号の連続性チェック等
の制御機能を省いている。

【００２７】この結果、ＰＰＰのフレーム構成上では、
ＨＤＬＣで使っているアドレスフィールドと制御フィー
ルドに、図２０に示す如く、常に、デフォルトの固定値
が入れられている。

【００２８】デフォルト値としては、アドレス部フィー
ルドの８ビット部分として１１１１１１１１（１６進表
示でＦＦＨ）が、コントロール部の８ビット部分として
００００００１１（１６進表示で０３Ｈ）が使われてい
る。

【００２９】近年は、ＰＰＰプロトコルと連携したデー
タ通信を行う通信回線インタフェースＬＳＩがモデムや
ダイヤルアップルータなどに組み込まれている。

【００３０】これらの通信回線インタフェースＬＳＩ
と、ＷＥＢサーバアクセスや電子メール等の通信アクセ
ス用のアプリケーションソフトを走らせるパソコンとの
間での非同期・同期変換によるデータ受け渡し連携機能
を持ったＰＰＰ通信処理ソフトがパソコンやダイヤルア
ップルータなどに実装されるケースが一般的になってい
る。

【００３１】最も基本形となるパソコンとモデムからな
るＰＰＰ通信装置（通信端末）と、通信回線、アクセス
サーバからなるＰＰＰを用いた通信システムの例につい
て、従来のＰＰＰによる通信の仕組みを説明する。

【００３２】図２１のパソコンとモデムによるＰＰＰ通
信システムの原理構成図、図２２のＰＰＰ接続の通信プ
ロトコル処理のやりとりイメージ、図２３のダイヤルア
ップ接続動作中のＰＰＰ通信システム機能要素間の連携
動作説明図、図２４のＰＰＰの状態遷移フロー図に、最
も基本的な、通信端末とアクセスサーバ間の１対１接続
時に於けるＰＰＰ接続処理がどのような過程を追って行
われるかを示す。

【００３３】また、図２５のＰＰＰフレームフォーマッ
トの基本構成、図２６のＬＣＰフレームの構成、図２７
のＬＣＰフレームにおける設定オプション機能、図２８
のＬＣＰフェーズの接続確立におけるオプションのネゴ
シエーションに、ＰＰＰのフレームと、ＬＣＰフレー
ム、オプションのネゴシエーションの様子を示す。

【００３４】図２１の構成において、近年は、モデムの
ＬＳＩ化、小型化の進展と共に、モデムもボード化やＰ
Ｃカード化が進んでいる。

【００３５】この結果、従来のＲＳ２３２Ｃインタフェ
ースを使った外部のモデムとのケーブルコネクタによる
接続に替わって、プリントボードによるＮＩＣモデムや
ＬＳＩによるＰＣカードモデムがデスクトップパソコン
のＰＣＩバスやノートパソコンの内部バスに直接挿入さ
れる一体型の構成が一般的になりつつある。

【００３６】図２１に示す如く、通信端末側のパソコン
とアクセスサーバの内部構成は、基本的には、同じ原理
構成をとっており、単位時間あたりのパケット処理数な
どの処理性能に差があるだけである。

【００３７】また、図２１の原理構成図にはパソコンか
らなる通信端末とアクセスサーバについて代表的な構成
要素を示しているが、ダイヤルアップルータも基本的な
ハードウェアの原理構成図は、共通しておりＣＰＵとメ
モリ、内部バス、外部入出力部の基本要素から構成され
ている。

【００３８】近年は、パソコンもサーバも、処理の高速
化を図るため、バスを階層化して、高速処理用のシステ
ムバスと外部インタフェース用の内部バスに分けたアー
キテクチャがＤＯＳ／Ｖパソコン等では標準となってい
る。

【００３９】アクセスサーバは、マルチプロセッサ構成
にして、処理能力をあげるケースやクラスタリング技術
により処理の分散化をはかるケースも見られる。

【００４０】ＰＰＰ処理ソフトは、これらの通信システ
ムにおいて、通信処理ソフトのひとつとして、ハードデ
ィスクの所定の領域にインストールされる。

【００４１】電子メールやＷＥＢサーバアクセス等の上
位のアプリケーションが起動され、ＰＰＰアクセスを要
求すると、その都度呼び出され、主メモリのプログラム
領域に格納され、モデムソフトや上位処理ソフトと連携
をとりながら必要な処理を行う。

【００４２】アクセスサーバ側では、ＰＰＰ処理ソフト
は、主メモリに常駐して必要な通信処理を常時行ってい
る。

【００４３】図２１（ｂ）のＰＰＰ通信処理中のパソコ
ンのメモリの構成例に、ＰＰＰ通信処理中のパソコンの
メモリの構成例を示す。

【００４４】ＰＰＰ処理プログラムは、通信処理中は、
その他のモデム処理プログラムや、ＴＣＰ／ＩＰ、ＷＥ
Ｂブラウザソフト等の下位及び上位のアプリケーション
ソフトと一緒にメモリに常駐して、連携しながら必要な
処理を行う。

【００４５】図２２のＰＰＰ接続の通信プロトコル処理
のやりとりイメージに、先の図１７のＯＳＩ参照モデル
とＰＰＰの関係、図１８のＰＰＰによるマルチプロトコ
ルのカプセル化の説明図に示したＰＰＰの各レイヤの通
信プロトコル処理が、時間順に、順を追って逐次処理さ
れる様子を示す。

【００４６】ダイヤルアップ接続で公衆通信網を使っ
て、アクセスサーバとパソコン等によるアクセス通信端
末との間の物理的な接続が行われ、その後、ＰＰＰプロ
トコルを使った、ＬＣＰフェーズ、ＮＣＰフェーズによ
って、リンクが確立され、ＰＰＰ通信フェーズで、ＰＰ
Ｐ上に必要な上位プロトコルを載せて転送を行い、最終
的に目的とするインターネット内のＷＥＢサーバやメー
ルサーバと通信端末との間で必要な通信情報のやり取り
が行われる。

【００４７】終了フェーズは、次のユーザに、端末ＩＰ
アドレス割当などのアクセスサーバへのアクセス資源割
当を解放し、再割当を行うためのアクセス終了、回線切
断の処理を示す。

【００４８】図２３のダイヤルアップ接続動作中のＰＰ
Ｐ通信システムの機能要素間の連携動作説明図は、図２
２の手順で処理を行う、通信端末の機能要素間の連携動
作をより具体的に説明する図である。

【００４９】図２３で、例えば、ＷＥＢブラウザ、メー
ラーソフトなどのインターネットアクセスソフトを使っ
て、インターネットに公衆通信網を使ってアクセスする
場合には、ブラウザやメーラーのユーザのマウスクリッ
クなどによる起動情報をそれぞれのインターネットアク
セスソフトが検知する。

【００５０】インターネットアクセスソフトは、事前に
設定された情報に応じて、アクセスサーバへの最寄りの
アクセスポイントへのダイヤルアップ接続の開始をＰＰ
Ｐ処理ソフトに指示する。

【００５１】ＰＰＰ処理ソフトはモデム接続処理ソフト
にダイヤルアップ接続を指示する。

【００５２】モデム接続処理ソフトは、事前に設定され
た、アクセスサーバへのアクセスポイントのダイヤル接
続番号と、事前に設定したアクセス速度の上限、受信デ
ータバッファの制御ルールなどの情報をモデムに伝え
る。

【００５３】モデムは、モデム接続処理ソフトからの交
換接続処理指示情報を基に、先ず、アクセスサーバへの
ダイヤリングによる交換接続を行う。

【００５４】交換接続直後には、アクセスサーバのモデ
ムとアクセスした側のモデムとの間で、事前に設定して
ある設定情報を基に、以降の通信条件の確認を行う。

【００５５】この確認調整終了後、モデム接続処理ソフ
トは、ＰＰＰ処理ソフトへ通信準備完了を通知する。

【００５６】モデムのダイヤルアップによる交換回線の
開通後、ＰＰＰ処理ソフトが、引き続いて、接続確立処
理を続ける。

【００５７】ＰＰＰ処理ソフトは、アプリケーションソ
フトの非同期処理を行っているパソコンと通信回線へデ
ータの同期転送処理を行うモデムとの間の非同期・同期
変換の速度整合処理も行う。

【００５８】モデム自体は、基本的には、ＰＰＰ処理ソ
フトの制御を受けながら、第１層の物理層における同期
データ転送の保証動作を行っている。

【００５９】現在、標準として使われているＭＮＰモデ
ムでは、波形自動等化などのモデム本来の基本機能に加
えて、モデム自体で、転送フレームの誤りチェック、再
送による誤り回復、符号圧縮、回線状況に応じた速度の
自動設定などの機能を物理層でサポートしている。

【００６０】ＰＰＰ処理ソフトは、モデムによる物理回
線確立の通知を受けた後、図２４のＰＰＰの状態遷移フ
ロー図で説明した如く、ＰＰＰ確立フェーズに於けるＬ
ＣＰフェーズで、通話品質の確認や、認証確認、相互
に、受信可能データ長の上限値などの通信要求条件、即
ち、オプションデータの交換による確認調整を行う。

【００６１】次いで、ＮＣＰフェーズで、通信プロトコ
ルの確認を行い、通信プロトコルの確認、通信セッショ
ンの確立を行う。

【００６２】ＮＣＰフェーズでは、ＩＰ接続の場合に
は、必要がある場合は、通信端末からの要求に応じて、
インターネーット又はイントラネットアクセスの為に、
アクセスサーバにプールしてあるＩＰアドレスの通信端
末への割当付与も行う。

【００６３】接続が確立され、通信が開始された定常通
信状態のＰＰＰ通信フェーズでは、このプロトコル上に
ＷＥＢブラウザ等のＷＥＢアクセスソフトの制御情報や
データ情報を載せたデータを、ＰＰＰのフレームのパケ
ット単位にカプセル化して送り、ＷＥＢサーバへのアク
セスが行われる。

【００６４】尚、上記の処理において、ＰＰＰ処理ソフ
トは、図２０のＰＰＰフレームフォーマットにおけるア
ドレスフィールド、制御フィールドの情報は全く使って
いない。

【００６５】図２２のＰＰＰ接続の通信プロトコル処理
のやりとりイメージ、図２３のダイヤルアップ接続動作
中のＰＰＰ通信システム機能要素間の連携動作説明図に
示したシーケンスが具体的にどのような手順で行われる
かをより詳細に示す為に、図２４のＰＰＰの状態遷移フ
ロー図を示す。

【００６６】図２４は、各フェーズにおいて、具体的に
どのような処理が行われているかを示している。

【００６７】図２４の各フェーズ順に、ＰＰＰ処理ソフ
トが上位アプリ・通信処理ソフト、下位通信ソフトと連
携を取りながら通信端末とアクセスサーバ間で、各フェ
ーズに応じたデータのやりとりが行われている。

【００６８】つぎに、図２５のＰＰＰフレームフォーマ
ットの基本構成、図２６のＬＣＰフレーム構成に、ＰＰ
Ｐ確立フェーズにおける具体的なフレームフォーマット
のデータを示す。

【００６９】図２５に示す如く、ＰＰＰプロトコルＮＯ
の１６ビットのコードで、ＬＣＰ制御、ＮＣＰ制御、ネ
ットワーク層プロトコル種別を識別しており、このコー
ドを図２２〜図２４で説明した如く時間フェーズ順に切
替ながら必要な処理を行う。

【００７０】情報フィールド部分は、各時間フェーズ順
に、ＰＰＰプロトコルＮＯの推移に応じて同時に内容が
変化する。

【００７１】図２６は、ＰＰＰプロトコルＮＯがＣ０２
１ＨのＬＣＰフェーズにおける情報部すなわちＬＣＰフ
レーム部の各フィールドの詳細構成を示す。

【００７２】ＬＣＰフレームの頭の８ビットコードで、
リンクの確立・設定やリンク終了の為の制御情報のやり
とりを行っており、ＬＣＰフェーズの中で、更に、細分
化したシーケンスの過程で、各制御コードが適宜選択さ
れてデータのやり取りが行われることを示す。

【００７３】図２７のＬＣＰフレームにおける設定オプ
ション機能、図２８のＬＣＰフェーズの接続確立におけ
る設定オプションのネゴシエーションにＬＣＰフェーズ
で、どのようにしてパラメータの調整が行われるかを示
す。

【００７４】図２７は、アクセスサーバと通信端末間と
で、どのようなタイプ（種類）のオプションデータのや
り取りを行うか現在インターネットのＩＥＴＦで標準と
して定義されているタイプと、そのタイプを表すコード
数、オプションデータの内容をそのデフォルト値ととも
に示す。

【００７５】図２８は、このように複数あるオプション
データの値の組合せを、アクセスサーバと、通信端末間
でどのような過程を踏んで調整されるか、その具体的な
事例を示す。

【００７６】ＰＰＰは、双方向転送を保証するプロトコ
ルであり、オプションデータは、例えば、転送速度な
ど、上り下りで一致するとは限らない為、ネゴシエーシ
ョンによるオプションデータの確認調整は、通常、双方
向に対して行われる。

【００７７】オプションデータは、同時に複数のオプシ
ョン値のセットを送って調整する事が出来る。

【００７８】図２８（ｂ）オプションネゴシエーション
時の例の（１）は、送られて来たオプションデータの組
に対して、全て受け入れ可能な場合、（２）は、一部オ
プションの変更が必要な場合、（３）は、一部オプショ
ンの認識が不能だった場合、の事例をそれぞれ示す。

【００７９】尚、図１５（ｂ）のダイヤルアップルータ
接続の場合では、ＰＰＰ処理ソフトは、ダイヤルアップ
ルータ側に実装され、ＬＡＮによって、複数のパソコン
とダイヤルアップルータとの間が接続されている。

【００８０】ダイヤルアップルータは、パソコンからＬ
ＡＮ経由で、ＮＩＣ（ネットワークインタフェースカー
ド）からＷＥＢサーバアクセスや電子メール等のアプリ
ケーションソフトからのデータを受け取る。

【００８１】ダイヤルアップルータの内部に実装された
３、４層以上の上位層のネットワークプロトコル処理ソ
フト、ＰＰＰ処理ソフトは、上位・下位の関連通信ソフ
ト、回線がＩＳＤＮの例ではＴＡ:Terminal Adapter と
ＤＳＵ:Digital Service Unit)からなる回線インタフェ
ース装置と連携を取りながらＰＰＰ接続処理を行う。

【００８２】従って、ダイヤルアップサーバへＬＡＮ経
由で、複数の通信端末による接続要求を受けて、接続処
理を行う点が異なるだけで、ＰＰＰを使った通信処理の
基本的な仕組みは、図１５のダイヤルアップ接続による
ＰＰＰを利用したアクセスサーバへの接続イメージ図の
（ａ）のモデム接続の場合と同じである。

【００８３】

【発明が解決しようとする課題】既に説明した如く、従
来技術のＰＰＰによる通信プロトコルを使っても、その
本来の目的であるマルチプロトコル転送処理に加え、Ｐ
ＰＰの上に開設したＩＰプロトコルの上に、さらに複数
のアプリケーションセッションを同時に開設したり、Ｉ
Ｐパケットレベルで優先制御を行うことは可能である。

【００８４】しかし、従来のＰＰＰによる通信プロトコ
ルのままでは次の３つの問題点があった。 １．ＩＳＰにおけるアクセスモード判別機能の不備 図２９のトンネリングプロトコルによるＰＰＰ転送と企
業アクセスサーバとの接続に示す如く、現在、中小企業
等のネットワーク利用者が、遠隔地における在宅勤務や
サテライトオフィス勤務時に、公衆回線を介して、ま
た、遠隔地を移動中に携帯電話等を経由して、本社のメ
ールサーバやＷｅｂサーバにアクセスする利用法が急激
に増えつつある。

【００８５】この時に、通信料金を極力安くする為に、
手近なＩＳＰのアクセスポイントを経由して、本社のサ
ーバに、マルチプロトコルを転送してアクセスするネッ
トワーク利用法が考えられる。

【００８６】この場合、ＰＰＰをさらに、ＩＰを使って
カプセル化することによって、インターネットを使って
ＰＰＰパケットを転送することが可能となる。

【００８７】しかし、インターネットは、多数のプロバ
イダが参加して構築されており、多数のユーザが共有し
てネットワーク利用を行っている。

【００８８】したがって、悪意の盗聴などによって、重
要データが外部に漏れる恐れもありＩＳＰのインターネ
ットを利用して、本社のサーバにアクセスする場合に
は、セキュリティを確保する必要がある。

【００８９】トンネリングプロトコルは、ＩＰフレーム
上に、ＰＰＰフレームをカプセル化・暗号化してＩＳＰ
のネットワークを利用して、２点間を伝送する技術であ
り、最近、インターネットの技術標準化委員会のＩＥＴ
Ｆでは、Ｌ２ＴＰ（Layer 2Tunneling Protocol) 方式
の標準化が完了し、標準番号ＲＦＣ２６６１の勧告書の
発行がなされた。

【００９０】多数のＩＳＰによるインターネットを通し
て、２点間をＩＰとは別のプロトコルであるＰＰＰプロ
トコルをトンネルの様にして通すことができる為にトン
ネリングプロトコルと呼ばれている。

【００９１】図２９において、ＩＰの上に、ＰＰＰプロ
トコルをのせて、遠隔地の企業のアクセスサーバにアク
セスした後は、ＰＰＰプロトコルが機能して、認証処理
やアクセスユーザに対するＩＰアドレスの臨時割当処理
などが行われ、最終的には、企業内のメールサーバやＷ
ＥＢサーバにアクセスして、必要な業務処理を行うこと
が出来る。

【００９２】他方、ＩＳＰのアクセスポイントへアクセ
スした利用者は、本社へのサーバにアクセスする以外
に、情報収集の為のＩＳＰのＷＥＢサーバアクセスや顧
客とのメールのやりとり等を目的にした一般的なインタ
ーネットユーザともなり得る。

【００９３】上記の２種類のアクセス利用の仕方を識別
するためには、 （１）ＩＳＰは、特定の企業にトンネリングプロトコル
で接続する場合には、その企業毎に専用の電話番号を用
意して利用者にその番号にかけさせ、通常のインターネ
ットアクセスの場合には、近くの公開アクセスポイント
にアクセスするようにする。 （２）ＰＰＰでアクセスするユーザＩＤ毎に、通常のイ
ンターネットアクセスか、トンネリングプロトコルによ
る企業のアクセスサーバへの接続かの識別処理を行う。 の２案が考えられる。

【００９４】しかし、（１）の方法は、ＩＳＰの運用コ
ストを増大させることになり、（２）の方法も、簡易な
実現方法は提案されていなかった。

【００９５】そこで、本発明の第一の課題は、ＩＳＰの
アクセスポイントにアクセスしたユーザが、遠隔地から
トンネリングプロトコルを使って本社のアクセスサーバ
へアクセスする場合と、一般的なインターネットアクセ
ス利用を行う場合との区別を簡単な手段で実現すること
である。

【００９６】次に、従来のＰＰＰプロトコル利用におけ
る２番目の問題点について述べる。 ２．ＰＰＰアクセスの都度毎回発生する接続確立待ち時
間の発生 ＰＰＰによる通信システムでは、ベンダの違いによるマ
ルチプロトコルをＰＰＰ上にカプセル化して転送処理す
ることによって、マルチプロトコルの多重化されたパケ
ットの同時転送、上位層における優先制御などを実現し
ている。

【００９７】他方、図２２〜図２４のＰＰＰの処理手順
の説明に示した如く、従来のＰＰＰを使った通信システ
ムではＰＰＰによる接続確立の為のネゴシエーションを
毎回行ってからアクセスサーバとアクセスを行う。

【００９８】この為、接続の都度、同じ通信端末と同じ
アクセスサーバ同士でも、毎回、図２７のＬＣＰフレー
ムにおける設定オプション機能、図２８のＬＣＰフェー
ズの接続確立における設定オプションのネゴシエーショ
ンに示した如く、定型的なネゴシエーション調整を行
う。

【００９９】現在のＰＰＰでは、このネゴシエーション
調整によって、同じ通信端末とアクセスサーバとの間で
も、アクセスの都度、毎回、同じ、オプションデータの
組合せや使うプロトコルの確認を繰り返している。

【０１００】この為、アクセスサーバとの接続が確立さ
れ、アプリケーションが起動するまでに、毎回、接続確
立待ちの無駄時間が発生していた。

【０１０１】他方、ＰＰＰは、モバイルコンピューティ
ング等において、移動中の端末からＩＳＰや企業のアク
セスポイントにアクセスする場合にも使われる。

【０１０２】これらの場合、ＰＰＰ接続を行う場合に、
図２２のＰＰＰ接続の通信プロトコル処理のやりとりイ
メージで説明した如く、交換接続後の物理回線が開通後
に、ＬＣＰ−＞認証−＞ＮＣＰのＰＰＰ接続確立の手順
を踏む必要がある。

【０１０３】この接続確認の時間は、ダイヤルアップ接
続環境下では、通常、十数秒以上かかることが多い。

【０１０４】モバイル環境下での通信料金は、通常の有
線接続と比べ、単位時間あたりの通話料金が近距離通話
の場合には数倍以上のオーダーで高めに設定されてい
る。

【０１０５】この結果、交換接続後の通信開始までのＰ
ＰＰ接続処理の時間が長い場合、実際には有効な通信デ
ータ通信に使っていない無駄な接続確立時間に対して、
毎回使用料金を払うことになり接続回数が多い場合には
通話料金問題となっている。

【０１０６】また、サテライトオフィスやＳＯＨＯ等の
自宅からアクセスする場合でも、接続確立時間は、極力
短いことがヒューマンインタフェース上望ましい。

【０１０７】そこで、本発明の第２の課題は、上記問題
点を解決する交換接続後のＰＰＰ確立の処理時間の短縮
を図る新たな手段を提供することである。

【０１０８】次に、従来のＰＰＰプロトコルにおける第
３番目の問題点について述べる。 ３．多重通信時におけるリアルタイム通信等に対する優
先制御の迅速化の困難性 マルチメディアやマルチプロトコルの同時利用による多
重通信を行う場合に、従来のＰＰＰプロトコルの場合に
は、ＩＰプロトコルヘッダの優先制御フィールドを見
て、アクセスサーバに対するＩＰパケットの待ち行列の
優先制御を行っている。

【０１０９】従って、ＰＰＰプロトコルをベースに通信
を行っているＰＰＰ接続の場合には必ずＰＰＰプロトコ
ル処理の後にＩＰプロトコル処理を行う手順を踏む必要
があり、なるべく迅速な処理が要求されるリアルタイム
性の必要な電話や動画像パケット伝送等の場合、処理の
迅速化が図れず問題となる。

【０１１０】そこで、本発明の第３の課題は、上記第３
の問題を解決するマルチメディアやマルチプロトコルの
多重通信時におけるアクセスサーバの待ち行列の優先処
理の高速化を実現する手段を提供することである。

【０１１１】次に、本発明の課題を解決するための手段
について説明する。

【０１１２】

【課題を解決するための手段】上記の課題を解決する為
に、本発明では、従来の ＰＰＰ（Point to PointProt
ocol)を用いた通信システムにおけるＰＰＰフレーム
で、固定値としているアドレスフィールドと制御フィー
ルドの値を可変コード値とする拡張ＰＰＰフレームを用
いる。

【０１１３】即ち、この可変コード値を、それぞれの目
的に応じた意味を持った識別コード値として用い、通信
端末が通信回線を通してアクセスサーバにアクセスする
場合の識別手段とする。

【０１１４】第一の使い方として、通信端末からＩＳＰ
の前記アクセスサーバへのアクセスにおいて、前記識別
コード値のフィールドの一部は、前記アクセスサーバへ
のアクセスがインターネットへのアクセスなのか、企業
のアクセスサーバへのトンネリングプロトコルによるア
クセスなのかを識別するコード値を持たせる。

【０１１５】該フィールドと異なるフィールドには、該
企業のアクセスサーバへのアクセスアドレス値の短縮コ
ード値を持たせる。

【０１１６】該ＩＳＰの前記アクセスサーバは、該アク
セスアドレス値の短縮コード及び通信端末の回線発信番
号とから、対応データライブラリによって、企業のアク
セスサーバへのＩＰアドレスを知り、トンネリングプロ
トコルによる企業のアクセスサーバへのアクセス処理を
行わせる。

【０１１７】これによって、簡単に、ＩＳＰのアクセス
サーバへのアクセスのアクセスモードの判別と、企業の
アクセスサーバのアドレスへの転送を簡単に実現するこ
とが出来、第一の課題が解決出来る。

【０１１８】第二の使い方としては、識別コード値を、
通常は、ＰＰＰのネゴシエーションフェーズによって獲
得している上位プロトコルのオプションパラメータの組
合せ値に対応した識別コード値とする使い方がある。

【０１１９】これによって、毎回、通信端末からアクセ
スサーバにアクセスする都度、行っているＬＣＰネゴシ
エーションの時間を大幅に短縮し、回線確立時間の短縮
化をはかることが出来る。

【０１２０】また、上位プロトコルのオプションパラメ
ータの組合せ値と前記識別コード値との対応ライブラリ
の作成方法としては、事前に定めた対応ルールの値を使
う方法と、通信端末からアクセスサーバへのアクセス時
にＰＰＰの通信処理プロトコルによるＬＣＰネゴシエー
ションによって行う方法が考えられる。

【０１２１】後者の場合は、最初のネゴシエーションで
は通常のアクセス確立時間を必要とするが、それ以降の
アクセスにおいては、該対応ライブラリによる前記識別
コード値を用いることによって、通信端末とアクセスサ
ーバ間の通信接続確立処理におけるネゴシエーション時
間を大幅に短縮することが可能となる。

【０１２２】これによって、第二の課題の解決を図るこ
とが可能となる。

【０１２３】さらに、第三の使い方として、アドレスフ
ィールド、制御フィールドの上位プロトコルのパラメー
タと１対１に対応付けられた識別コード値として、上位
プロトコルの転送待ち行列における優先順位を付与する
ことが考えられる。

【０１２４】これによって、わざわざ上位プロトコルま
で戻って優先制御を行うのでなく、データリンク層で識
別コードの値を見て簡単・迅速に優先制御を行うことが
可能となり、第三の課題の解決を図ることが可能とな
る。

【０１２５】以下、実施例を参照しながら詳細な説明を
行う。

【０１２６】

【発明の実施の形態】図１の本発明の拡張ＰＰＰフレー
ム構成の原理説明図、図２の拡張ＰＰＰフレームの識別
コードによるＩＳＰ接続時のアクセスモード判定、図３
の拡張ＰＰＰフレームの識別コードによる通信開始時間
短縮の原理説明図、図４のマルチプロトコル間の優先度
指定識別コードによる待ち行列の制御イメージに、本発
明の拡張ＰＰＰフレームによる通信システムの基本原理
を示す。

【０１２７】図１の本発明の拡張ＰＰＰフレーム構成の
原理説明図に示す如く、本発明では、従来のＰＰＰでは
デフォルト値のまま使われていなかったアドレスフィー
ルドと制御フィールドの組合せフィールド（以下、識別
フィールドと呼ぶ）を、本発明の目的に応じた形で識別
コード用のフィールドとし、積極的に活用するものであ
る。

【０１２８】識別フィールドの使い方としては、アドレ
スフィールドのみを使う場合、制御フィールドのみを使
う場合、両方のフィールドを同時に使う場合が考えられ
る。

【０１２９】この使い分けは、実際に、この識別フィー
ルドをどの様な目的で、どの程度の規模で使うかによっ
てきまる。

【０１３０】この識別フィールドを活用して、識別コー
ド値の差に、使用目的に応じた特定の意味を持たせるこ
とによって、 １）ＩＳＰのアクセスサーバにアクセスした場合のアク
セスモード即ちトンネリングモードで企業のアクセスサ
ーバへのアクセスを要求するのか、インターネットへの
アクセスを要求するのかの識別の簡単化 ２）毎回ネゴシエーションによって確認しているオプシ
ョンパラメータ値の組合せに対応する短縮コードを識別
コード値として知り、ネゴシエーションを短縮すること
によって、接続確立時間の短縮化 ３）上位のプロトコルの優先度に対応する値を識別コー
ドとして持たせる事によって、データリンク層での迅速
な優先制御を実現することが出来る。

【０１３１】尚、これ以降、この新たに定義した識別フ
ィールドに可変値を持たせることを特徴とするＰＰＰフ
レームを拡張ＰＰＰフレーム、この拡張ＰＰＰフレーム
を基に行う通信処理プロトコルを拡張ＰＰＰと呼ぶ。

【０１３２】この識別コードとオプションデータの組合
せとの対応付けを行う具体的な方法としては、（ａ）限
定されたユーザの範囲内で事前に特定のルールを決めて
使う使い方と（ｂ）不特定ユーザを対象とし、最初にア
クセスサーバにアクセスする場合に、従来のＰＰＰ接続
と同様に１度だけネゴシエーションを行い、アクセスサ
ーバ、通信端末とアクセスサーバのそれぞれの必要なオ
プションデータの組合せを知り次回以降は、この求めら
れたオプションデータの組合せに対応する短縮コード
を、識別フィールドで伝達することにより、２回目以降
のアクセスの高速化を図る方法がある。

【０１３３】このようにして決めた識別コードを下記の
如く用いる事によって、次の如く各課題の解決が図れ
る。 （１）ＩＳＰアクセスサーバへのアクセスモードの簡単
な識別実現 転送するＰＰＰパケットが、ＩＳＰのアクセスサーバを
経由してインターネットアクセスを行うのか、トンネリ
ングプロトコルを使って企業のアクセスサーバヘアクセ
スするのかを拡張ＰＰＰフレームにおける識別コードの
特定のビット位置の値によって指定し、アクセスサーバ
における簡単な拡張ＰＰＰフレームを有するパケットの
識別処理を実現する。

【０１３４】図２の拡張ＰＰＰフレームの識別コードに
よるＩＳＰ接続時のアクセスモード判定に示す如く、サ
テライトオフィス等から、ユーザがＩＳＰのアクセスサ
ーバにＰＰＰ通信プロトコルを使ってアクセスした場
合、ユーザがインターネットを使いたいのか、トンネリ
ングプロトコルを使って、企業のアクセスサーバにアク
セスしたいのかを、拡張ＰＰＰフレームにおけるアドレ
スフィールドと制御フィールドの識別コードを見て即座
に判断できる。

【０１３５】図２の例では、例えば、アドレスフィール
ドの値が０９Ｈの場合は、インターネット利用の場合と
し、０１Ｈの場合は、トンネリングプロトコルによっ
て、企業のサーバに接続するケースとする。

【０１３６】尚、トンネリング先の企業のアクセスサー
バへのＩＰアドレスは、発信者番号通知機能を使って、
発信者の通信端末の回線番号を知り、対応ライブラリか
ら知った、企業のアクセスサーバのＩＰアドレスへ転送
するものとする。

【０１３７】また、識別コード値に、アクセスサーバの
アドレス値をいれるようにすれば、複数の企業のアクセ
スサーバへのアクセスが可能となる。

【０１３８】この場合も、発信者番号通知機能と組み合
わせることによって、多数のユーザグループがそれぞれ
の複数のアクセスサーバへアクセスすることが可能とな
る。

【０１３９】この判別処理後は、それぞれのケースに応
じた上位層に対する通常のＰＰＰ対応処理が行われる。
これによって課題１が解決できる。尚、詳細説明は実施
例を参照しながら行う。 （２）ＰＰＰ処理確立時間の短縮 ネゴシエーションによって決めているオプションデータ
値の組合せに対応する値にマッピングさせた特定の識別
コード値によって指定することによってネゴシエーショ
ン時間を短縮する。

【０１４０】図３の拡張ＰＰＰフレームの識別コードに
よる通信開始時間の短縮の原理説明図に示す如く、通常
はレイヤ２のデータリンク層におけるＰＰＰ層の処理に
おいて、ＬＣＰ、ＮＣＰ、レイヤ３、と順次、毎回のネ
ゴシエーションによって確認する上位通信プロトコルの
オプションデータの値のセットを、拡張ＰＰＰフレーム
におけるアドレスフィールド、制御フィールドの識別コ
ードの値と１対１に対応付けておく。

【０１４１】また、通信端末からの認証データの送信に
関しては、通常は図２４の状態遷移フロー図で説明した
如く、ＬＣＰフェーズの最後に行われるが、拡張ＰＰＰ
フレームにおけるＬＣＰフレームのオプション部のオプ
ションデータとして識別コードと同時に送るようにす
る。

【０１４２】アクセスサーバは、通信端末から送られて
来た識別フィールドの値を見て、拡張ＰＰＰフレームに
よるアクセスである事、その時の識別コードの値からオ
プションデータの組合せ値を対応ライブラリによって知
る。

【０１４３】また、アクセスサーバは、同時にＬＣＰフ
レームのオプション部のオプションデータとして送られ
て来たユーザ識別ＩＤとパスワードを確認し、認証を行
う。

【０１４４】認証結果、アクセスサーバは、拡張ＰＰＰ
フレームを使い、通信端末に対して、既に、ＬＣＰネゴ
シエーションで確認されているアクセスサーバから通信
端末へのオプションデータの組合せ値に対応する識別コ
ードを識別フィールドに入れて送る。

【０１４５】同時に、アクセスサーバは、アクセスした
通信端末に対して、プールしてあるＩＰアドレスの中か
ら空きのＩＰアドレスを割当ＩＰアドレスとして、拡張
ＰＰＰフレームにおけるＬＣＰフレームのオプション部
のオプションデータ部を使って通知する。

【０１４６】このようにすることによって、通常のＰＰ
ＰによるＬＣＰより上の上位のプロトコルによる毎回の
定常的なネゴシエーション結果を待つことなく、識別子
の値から即座に、上位のプロトコルのパラメータの値を
確認することが出来る。

【０１４７】この様に、拡張ＰＰＰフレームを用いるこ
とによりＬＣＰ、ＮＣＰのシーケンスの大幅な短縮化が
可能となり、ただちに、ＰＰＰによる上位プロトコルの
カプセル化機能を使って実際の通信を開始することが出
来る。

【０１４８】尚、識別コードの値と、上位のプロトコル
のパラメータ値の組合せの対応は、限定されたユーザの
中で、限定されたユーザの中でだけ使う場合は、予め、
対応ルールを決めておいた共通の対応ライブラリを使
う。

【０１４９】又、不特定多数のユーザを対象とする場合
には、アクセスサーバに対する最初のアクセスの時に、
ネゴシエーションによって確認したオプションデータの
組合せに対応する識別コードとの対応関係を使って、２
回目以降は、ネゴシエーションの過程を省略して、ただ
ちに通信を開始することができる。

【０１５０】この際、アクセスするユーザも多数となる
為、アクセスユーザの違いにより、識別コードの意味が
異なるように決めた場合は、対応ライブラリの解釈を行
う際に、発信者番号通知機能を使って、発信番号と識別
コードのセットに対して、オプションデータの組を定め
る事によって、識別コードのビット数の制約から来る収
容ユーザ数の制限を解決することが可能となる。

【０１５１】上記の如く、毎回のアクセスにおいては、
ＰＰＰのリンク確立の為のネゴシエーション時間を大幅
に短縮でき、これによって課題２を解決することが出来
る。 （３）優先制御の迅速化 ＰＰＰパケットが優先制御を必要とするパケットかそう
でないのかを特定位置のコード値によって指定すると同
時に優先制御時は、優先度も同時に指定する。これによ
って上位プロトコルでの処理を省き高速化を実現する。

【０１５２】図４のマルチプロトコル間の優先度指定識
別コードによる待ち行列の制御イメージの図に示す如
く、アドレスフィールド、制御フィールドに、ＰＰＰ転
送パケットの転送待ち行列における優先度指定データを
書き込んで置く。

【０１５３】これによって、音声や画像などのリアルタ
イム性の必要なデータを伝送する場合には、ＰＰＰパケ
ットの転送待ち行列における優先度を上げ、良好な通信
品質を保つことができる。

【０１５４】また、上述の優先度判別処理は、わざわざ
上位プロトコルにまでさかのぼって、優先順位を識別し
て、判断する必要がない為に、処理時間の短縮化が図れ
る。

【０１５５】これによって、同一の端末を使って複数の
サービスを同時に一本のＰＰＰ回線を共用する場合や複
数の端末が複数のサービスを使って一本のＰＰＰ回線を
共有して使う場合の、利用サービスに応じた伝送パケッ
トの転送の優先制御の迅速な処理が可能となり、課題３
の解決が図れる。

【０１５６】以上の様に、現在のＰＰＰフレームでは、
使われていない識別フィールドを活用し、上位のプロト
コルと関連のある識別コード値を伝送する事によって、
高速のアクセス処理を実現するものである。

【０１５７】尚、装置構成は、従来のパソコンやダイヤ
ルアップルータ、アクセスサーバのＣＰＵとメモリと内
部バスを基本とする内部構成とモデムやＮＩＣ、ＴＡ、
ＤＳＵを基本とする入出力インタフェースのハードウェ
ア構成はそのまま使え、ソフトウェアモジュールの内の
ＰＰＰ処理部分を置き換えることによって、本発明の拡
張ＰＰＰフレームを用いた通信システムを実現できる。

【０１５８】次に、具体的な実施例を参照しながら、本
発明のさらに詳細な説明を行う。

【０１５９】図５の拡張ＰＰＰフレームのアドレス・制
御フィールドの識別コード設計例に、本発明の識別コー
ド設計例を示す。

【０１６０】図６の拡張ＰＰＰによる実施例１の優先制
御の仕組み、図７の拡張ＰＰＰによる実施例１の優先制
御の送信処理フロー図、図８の拡張ＰＰＰによる実施例
１の優先制御の受信処理フロー図に、本発明による優先
制御処理の実施例１を示す。

【０１６１】図９の拡張ＰＰＰによる実施例２のトンネ
リング接続を含む多重通信利用イメージ、図１０の拡張
ＰＰＰによる実施例２における多重通信処理の仕組み、
図１１の拡張ＰＰＰによる実施例２における多重通信処
理の送信処理フロー図、図１２の拡張ＰＰＰによる実施
例２における多重通信処理の受信処理フロー図によっ
て、トンネリング接続を含む実施例２をしめす。

【０１６２】図１３のＬＣＰネゴシエーションによる拡
張ＰＰＰにおける識別コードの決定、図１４の拡張ＰＰ
ＰにおけるＬＣＰフレーム構成に、ネゴシエーションに
よる識別コードの決定法による実施例３を示す。

【０１６３】以下、順を追って説明を行う。

【０１６４】図５の例に示す如く、識別コードの値の決
め方は、自由度があり実際の適用の態様に応じて、各種
の決め方が考えられる。

【０１６５】図５は、優先制御と、トンネリングアクセ
スモードの識別、ＬＣＰネゴシエーションの短縮を実現
する複合コードの例である。

【０１６６】また、図５は、の不特定多数の複合利用を
意図とする場合のコード設計例を示しており、不特定多
数の利用者が使う場合は、標準的・共通的な識別コード
を決めて、共通のルールに従って、各種の利用形態を同
時に組み合わせて、情報のやりとりと制御を行う場合が
ある。

【０１６７】逆に、特定企業ユーザの特定目的利用の場
合は、その拡張ＰＰＰを特定の企業の中だけで、利用目
的も限定して、カスタマイズした特定の識別コードをき
めて使う場合もある。この場合のアクセスサーバは、限
定された企業のアクセスサーバとなる。

【０１６８】図５の識別コードでは、不特定多数の利用
者が、優先制御やトンネリング接続、ＬＣＰネゴシエー
ションの短縮などを行うことを想定したコード設計例と
なっている。

【０１６９】即ち、図５の識別コードでは、元のアドレ
スフィールドの最初の１ビット目の値を０と設定する事
によって、拡張ＰＰＰフレームである事を示す。

【０１７０】２ビット目は、プロバイダへの直接アクセ
ス（値０）かトンネリングアクセス（値１）かを示す。
企業のアクセスサーバへの直接アクセスの場合は０の値
をとる。

【０１７１】直接アクセスの場合は、拡張ＰＰＰでカプ
セル化された上位プロトコルのパケットは、インターネ
ットへルータを経由して転送され、トンネリングアクセ
スの場合は、トンネリング用にＩＰヘッダを付けカプセ
ル化し、インターネットを通して、企業のアクセスサー
バへ転送される。

【０１７２】３ビット目は、ネゴシエーションによりオ
プションデータを求める場合のネゴシエーションが初回
かどうかを示すビットである。

【０１７３】何らかの理由で、環境条件が変わり、再
度、ネゴシエーションによって、オプションパラメータ
の組合せに対する識別コードを求める場合は、最初のネ
ゴシエーションモードでネゴシエーションを行う必要が
ある。

【０１７４】４ビット目は、優先制御の有無を示す。１
が優先制御、０が優先制御を行わない場合である。

【０１７５】５〜８ビット目は、ＬＣＰネゴシエーショ
ンに於けるオプション値の代表値のセットに対応する識
別コード値である。

【０１７６】この例では、１６個の代表的な値をセット
して置くことが出来る。

【０１７７】制御フィールドの１〜２ビットは、優先度
を示す。４ビット目が１で、優先制御を行う場合に、４
段階の優先度設定が可能となる。数値が小さい方を優先
度が高いものとする。

【０１７８】上位のプロトコルにおける優先順位とこの
ビットとは、１対１に対応付けられるものとする。具体
的には、アプリケーションを起動した場合に、優先制御
ありの場合には、ＰＰＰパケットを組み立てた場合にア
プリケーションの優先順位に対応した識別コードの値を
設定を行うものとする。

【０１７９】優先制御なしの場合には、このフィールド
は意味を持たない為、無視される。

【０１８０】制御フィールドの３〜８ビットは、トンネ
リング転送時の転送先の短縮アドレス値を示す。

【０１８１】短縮アドレスだけでは、ユーザ数が限定さ
れた閉じた利用範囲であれば問題ないが、不特定多数の
ユーザが同じサービスを利用する場合に、収容可能なユ
ーザ数の制限の為、対応する転送先のアクセスサーバの
ＩＰアドレスを知ることはできない。

【０１８２】その場合は、交換網側で提供している発信
者番号表示機能との組合せによって、特定ユーザにカス
タマイズした転送先アドレスデータベースを準備する。

【０１８３】即ち、発信者の発信番号を知ることによっ
て、利用者に対応した転送先のアクセスサーバのＩＰア
ドレスと短縮アドレス値との対応付けを行ったデータベ
ースを参照することが出来、簡単に、短縮アドレスを、
正しい転送先アクセスサーバのＩＰアドレスに変換する
ことが出来る。

【０１８４】以下、（１）優先制御、（２）多重制御、
（３）ネゴシエーションによる識別コードとオプション
データの組合せ対応の決定例を参照しながら、個々の事
例を基により具体的に本発明の詳細説明を行う。 （１）優先制御による実施例１ 本実施例１は、識別フィールドを優先制御の目的にだけ
使う場合を例示した場合である。また、ＩＰｖ６による
マルチキャスト利用などの音声やビデオ等のリアルタイ
ム転送利用ユーザと、従来のＩＰｖ４、ＩＰＸなどを利
用するユーザのマルチプロトコル混在環境を想定してい
る。

【０１８５】尚、本実施例１の拡張ＰＰＰフレームを用
いた通信システムにおいて、通信端末側は、ダイヤルア
ップルータに対して、複数のパソコンがＬＡＮ経由で接
続される場合を想定している。

【０１８６】図６の拡張ＰＰＰによる実施例１の優先制
御の仕組み、図７の拡張ＰＰＰによる実施例１の優先制
御の送信処理フロー図、図８の拡張ＰＰＰによる実施例
１の優先制御の受信処理フロー図に、本発明による優先
制御処理の実施例を示す。

【０１８７】以下、図７、図８を参照しながら図６の詳
細説明を行う。

【０１８８】図６で、送信側の通信装置１で、ネットワ
ークインタフェース部はＬＡＮ経由でパソコンからデー
タを受信し、上位プロトコル処理部でＰＰＰより上の層
のプロトコル処理を行い、ＰＰＰ処理部で、ＰＰＰカプ
セル化処理を行い、優先番号付与処理部で優先制御テー
ブルを参照し、データの優先度に応じた優先番号をＰＰ
Ｐの所定の識別フィールドの位置に優先番号を付与し、
送受データ格納部に受信順に一旦格納を行い、回線イン
タフェース部を通じて、通信回線にデータの送出を行
う。

【０１８９】受信側の通信装置２では、回線インタフェ
ース部でデータの受信を行い、送受データ格納部に、一
旦データを格納し、優先制御部で優先番号順に、送受デ
ータ格納部からデータを取り出しＰＰＰ処理部に渡し、
ＰＰＰ処理部で上位のデータを取り出し、上位プロトコ
ル処理部で上位プロトコル処理を行い、送信部を通じて
外部にデータを渡す。

【０１９０】即ち、受信側で、識別コードの優先番号順
に、送受データ格納部に時間順に到着したデータの待ち
行列から、データの取り出しを行うことによって、デー
タリンク層で簡単に、優先制御を行うことが出来る。

【０１９１】受信側の通信装置２すなわちアクセスサー
バには、他のルートで来た複数のパケットも同時に、送
受データ格納部に受信され、待ち行列として並ぶ。

【０１９２】この場合、常に、識別コードを見て、瞬時
に、優先順位の高い順、時間順にデータの取り出しが行
われる為に、多数のユーザからのアクセスに対して高速
の優先制御処理を行うことが可能となる。

【０１９３】図６の説明図において、通信装置１では、
ネットワークインタフェース部にアプリケーションを起
動した通信端末Ａからデータが送られて来ると上位プロ
トコル処理部でＰＰＰより上のネットワーク層やアプリ
ケーション層に対応したプロトコル処理が行われる。

【０１９４】ここでは、ＰＰＰ処理部にデータを渡すと
同時に、送信部に対して、回線の確立を要求する。

【０１９５】回線インタフェース部は、ダイヤルアップ
による交換回線接続に続き、ＰＰＰ処理部と連携しなが
ら、通常のＬＣＰネゴシエーションによって、回線を確
立し、次に、回線上に流すネットワーク層プロトコルに
対応したＮＣＰのネゴシエーションを行う。

【０１９６】優先制御テーブルには、データの種別と優
先番号との対応データが格納されている。

【０１９７】ここでは、ネットワーク層のプロトコル種
別毎に、ＩＰｖ６：０、ＩＰｖ４：１、ＩＰＸ：２と対
応付けられている。

【０１９８】数値が低い方が優先度は高くなるように設
定されている。

【０１９９】ＰＰＰ処理部でカプセル化されたデータ
は、優先制御部によって、優先制御テーブルの対応付け
に従った優先番号を付けられる。ここではアドレスフィ
ールドを利用して優先番号をつける場合の事例を示す。

【０２００】ＩＰＸ、ＩＰｖ６、ＩＰｖ４の順に、デー
タが来た場合は、それぞれ、優先番号２、０、１が付与
される。優先番号が付与されたデータは、送受データ格
納部に格納される。送受データ格納部に格納されたデー
タは、格納順に回線インタフェース部を通して通信回線
に送信される。

【０２０１】受信側の通信装置２では、回線インタフェ
ース部でデータを受信すると、送受データ格納部に一旦
データの格納を行う。

【０２０２】優先制御部は、先ず、優先番号の値が最も
小さな優先度が最も高いデータをＰＰＰ処理部に渡す。
次のデータは、残りのデータの中で優先順位の最も高い
データである。

【０２０３】ＰＰＰ処理部は、カプセルを外し、上位プ
ロトコル処理部にデータを渡す。上位プロトコル処理部
で処理を行ったデータは、ネットワークインタフェース
部を通じて外部のインターネット、イントラネットなど
に渡される。

【０２０４】尚、優先番号の割当ルールとしては、この
ほかに、既述の如く音声やメールなどのアプリケーショ
ンレベルで行う案、トランスポートのプロトコルに対し
て割当てる案などが考えられる。

【０２０５】また、上位の複数の層のプロトコル毎に優
先番号を付与しておき、アドレスフィールドにある層の
プロトコルの優先度、制御フィールドに、別の層のプロ
トコルの優先度を割り当てることも出来る。

【０２０６】どのような割当ルールを採用するかは、実
際の適用上のニーズ、適用効果を考慮してきめる。

【０２０７】以上説明した如く、本実施例によれば、Ｐ
ＰＰと同じレイヤ２で優先制御を行うことが出来、リア
ルタイム放送のマルチキャスト利用、音声などのリアル
タイムニーズの強いデータと通常のメールデータなどが
混在する場合でも、迅速な待ち行列処理による優先制御
が可能となり、今後のマルチメディア混在下の通信環境
下でその適用効果は大きい。 （２）トンネリング接続を含む実施例２ 図９の拡張ＰＰＰによる実施例２のトンネリング接続を
含む多重通信利用イメージ、図１０の拡張ＰＰＰによる
実施例２における多重通信処理の仕組み、図１１の拡張
ＰＰＰによる実施例２における多重通信処理の送信処理
フロー図、図１２の拡張ＰＰＰによる実施例２における
多重通信処理の受信処理フロー図によって、トンネリン
グ接続を含む実施例２について説明を行う。

【０２０８】図９で通信端末Ａ、Ｂは、ＩＳＰのアクセ
スサーバ、インターネットを経由して、トンネリングプ
ロトコルを使ってデータ転送を行い、企業Ａのファイア
ウォール内の部門サーバに、メール利用、ＷＥＢ利用ア
クセスする場合を示す。

【０２０９】また、同時に通信端末Ｃは、ＩＳＰのアク
セスサーバ経由で、企業Ｂにトンネリングプロトコルを
使ってｔｅｌｎｅｔでアクセスしている。

【０２１０】図１０の送信側において、通信装置１のネ
ットワークインタフェース部で、外部からデータを受信
し、上位プロトコル処理部で、上位プロトコル処理を行
い、ＰＰＰ処理部でカプセル化を行う。

【０２１１】その後、ＰＰＰ識別コード付与処理部で異
なる端末やアプリケーションからのデータを識別する為
に識別コードをデータに付加し、送信データ格納部にデ
ータを一旦格納し、回線インタフェース部を通して回線
にデータを送出する。

【０２１２】図１０の受信側では、回線インタフェース
部で回線からのデータを受信し、送受データ格納部に一
旦格納した後で、ＰＰＰ処理部は異なる識別コードを持
つデータは、異なる端末装置からのデータであると判定
して、ネットワークインタフェース部にデータを渡す。

【０２１３】即ち、ＰＰＰ識別コードはこの場合、送信
側で、端末装置が複数あって、その内のどの端末装置か
ら送られて来たのかを判別する目的で使われる。

【０２１４】従来技術でも、ネットワーク層でＩＰプロ
トコルを使う場合は、ＩＰ割当アドレス値によっても、
端末の識別は可能である。

【０２１５】しかし、このように、データリンク層で、
拡張ＰＰＰフレームの識別コードを使って端末の識別を
行うことによって、データリンク層で、通信端末の高速
識別が行える。

【０２１６】この結果、通信端末毎のアクセスサーバへ
のアクセス接続モードの分布データ、パケット通信量等
のネットワーク統計データが直接収集出来、通信端末毎
の料金管理、ネットワーク資源配分の検討などが簡単に
行える効果が得られる。

【０２１７】以下、図１１、図１２を参照しながら図
９、図１０の詳細な説明を行う。

【０２１８】図１０の通信装置１で、通信端末Ａから受
信したＬＡＮ経由で企業Ａのメールサーバアクセスを要
求するメールデータが受信される。

【０２１９】上位プロトコル処理部は、ＰＰＰ処理部に
データを渡すと同時に、送信部に対して、回線の確立を
要求する。

【０２２０】回線インタフェース部は、ダイヤルアップ
による交換回線接続に引き続き、ＰＰＰ処理部と連携を
とりながら、ＬＣＰネゴシエーションによって回線を確
立し、次いで、回線上に流すネットワーク層のプロトコ
ルに対応したＮＣＰのネゴシエーションを行う。

【０２２１】ＰＰＰ処理部でカプセル化されたデータ
は、識別コード付与処理部で、１本目のＰＰＰであるこ
とを表す数値が識別コード部に書き込まれる。

【０２２２】即ち、この場合は、識別コードは、送信側
における端末の番号、即ち、開設したチャネル番号に対
応する。

【０２２３】この場合、最初のチャネルである事を示す
為に、アドレスフィールドに０を書き込む。この様にし
てＰＰＰ識別コードを付加されたデータは、送信データ
格納部に書き込まれる。

【０２２４】同時に、トンネリングモードによるアクセ
スを要求することをしめす為に、この場合は、制御フィ
ールドに０１Ｈを書き込む。

【０２２５】回線インタフェース部は、送受データ格納
部に書き込まれた順番でデータを読出し通信回線に送出
する。

【０２２６】次に、通信装置１のネットワークインタフ
ェース部に、通信端末ＢからのＷＥＢサーバへのアクセ
スの為のＨＴＴＰデータが受信される。上位プロトコル
処理部で上位プロトコルの処理が行われる。ＰＰＰ処理
部にデータを渡すと同時に、回線インタフェース部に，
通信回線の確立を要求する。

【０２２７】既に、回線は確立されているので、ＰＰＰ
識別コードを別の値にすることを識別コード付与処理部
に指示する。同時に、企業Ａのアクセスサーバへのトン
ネリングアクセスであることを示すために制御フィール
ドに０１Ｈを書き込む。

【０２２８】上位プロトコル処理部は、このデータが最
初の１つ目のＰＰＰでカプセル化しているプロトコルと
は異なるプロトコルの場合は、送信部に対して、そのプ
ロトコルに対応したＮＣＰのネゴシエーションを行うこ
とを指示するが、この場合は、同じＩＰｖ４である為、
指示を行わない。

【０２２９】ＰＰＰ処理部でカプセル化されたデータ
は、識別コード付与処理部によってＰＰＰ識別コードを
示すアドレスフィールドに、２本目のチャネルのＰＰＰ
を表す数値１が書き込まれる。

【０２３０】さらに、通信装置１において、ネットワー
クインタフェース部に通信端末Ｃからのｔｅｌｎｅｔデ
ータが受信される。上位プロトコル処理部で、上位プロ
トコルの処理が行われる。

【０２３１】上位プロトコル処理部は、ＰＰＰ処理部に
データを引き渡すと同時に、送信部に対して回線の確立
を要求する。回線は、既に確立しているので、ＰＰＰ識
別コードを別の値にすることを識別コード対応処理部に
指示する。また、同時に、企業Ｂへのトンネリングアク
セスであることをしめす為に、拡張ＰＰＰフレームにお
ける制御フィールドに識別コードとして０１Ｈを書き込
む。

【０２３２】上位プロトコル処理部は、このデータが１
本目のＰＰＰでカプセル化しているプロトコルと異なる
プロトコルである場合は、送信部に対して、そのプロト
コルに対応したＮＣＰのネゴシエーションを行う事を指
示するが、この場合も同じＩＰｖ４であるので指示を行
わない。

【０２３３】ＰＰＰ処理部で、カプセル化されたデータ
は、３本目の異なるチャネルである事を識別する為に、
ＰＰＰ識別コード付与処理部によって識別コードのアド
レスフィールドに２の値を書き込む。

【０２３４】他方、図１０の受信側の通信装置２におい
て、回線インタフェース部を通して回線からのデータは
受信されると、送受データ格納部に一時的に格納され
る。

【０２３５】ＰＰＰ対応処理部は、受信データ格納部か
らのデータについて、異なるＰＰＰ識別コードが割り振
られたデータは、異なるチャネルからのデータであると
判断し、ＰＰＰ処理部にデータを渡す。

【０２３６】ＰＰＰ処理部でカプセル化を外されたデー
タは上位プロトコル処理部に渡され、上位プロトコル処
理部で処理を行った後、ネットワークインタフェース部
を通じてインターネットに送信される。

【０２３７】本実施例で、企業Ａのアクセスサーバへの
トンネルをはる場合は、ＰＰＰ識別コードの値を、例え
ば、制御フィールドの値として、企業のアクセスへ対応
した０１Ｈの特定の値に設定している。

【０２３８】この特定のコード値によって、トンネリン
グアクセスであること、特定のユーザからのアクセスが
あることを発信者番号通知によって知り、特定の企業の
アクセスサーバへトンネリング処理を行う。

【０２３９】これは、上位プロトコル処理部におけるＩ
Ｐカプセル化によって行われる。

【０２４０】上記の例では、同じ発信者番号のユーザか
らのアクセス先が企業Ａ、企業Ｂと複数ある場合であ
る。

【０２４１】このように、特定の発信者番号回線の複数
のユーザからのトンネリング先の企業のアクセスサーバ
が複数存在する場合は、制御フィールドの上位の７ビッ
トと発信者番号を組み合わせることによって、特定のユ
ーザに対して、複数のアクセスサーバへのトンネリング
アクセスを実現することが出来る。

【０２４２】即ち、例えば、上位の７ビットをアクセス
サーバのアドレス識別に使い、下位の１ビットでトンネ
リングの有無の識別を行うようにする。

【０２４３】発信者番号と上位７ビットのアクセスサー
バ番号の組合せに対してアクセスサーバのＩＰアドレス
を対応させたライブラリを作成して置くことによって簡
単に特定ユーザグループに対する複数の特定アクセスサ
ーバへのアクセスを実現出来る。

【０２４４】この場合、プロバイダのアクセスサーバで
は認証チェックを行わないようにし、トンネリングで企
業アクセスサーバにアクセスした後で、認証チェックを
行うようにする事によってより高速でのアクセスを実現
できる。

【０２４５】以上の図９〜図１２に示す実施例２によっ
て、アクセスサーバへのアクセスモードの簡単な識別に
よるインターネットへの直接接続とトンネリングプロト
コルを使った企業のアクセスサーバへの転送制御が簡単
に行え、同時に、複数の通信端末毎のアクセスデータの
収集管理を容易に行うことが出来る。 （３）ネゴシエーションによる識別コードの決定の実施
例３ 図１３のＬＣＰネゴシエーションによる拡張ＰＰＰにお
ける識別コードの決定、図１４の拡張ＰＰＰにおけるＬ
ＣＰフレーム構成を参照しながら、ネゴシエーションに
よる識別コードの決定法について説明を行う。

【０２４６】実施例１、２において、アドレスフィール
ド、制御フィールドをどのように用いるかは事前に送受
装置間で決めてあることを前提に説明を進めて来たが、
ＰＰＰのネゴシエーションを利用して、システム立ち上
げ時の最初の接続の時に決定する方法について述べる。

【０２４７】このようにして一旦オプションパラメータ
の組合せ値を確認し、識別コードによる短縮コードと、
オプションパラメータの組合せとの対応関係をしめすデ
ータをライブラリ化し、送信装置、受信装置側で持って
いれば、次回以降のアクセス時には、オプションデータ
の確認を毎回行わないで済む。

【０２４８】これは、実際の環境下では、オプション値
の調整の対象となる通信端末とアクセスサーバ間の最大
通信可能データ長などのデータ通信条件を主とするオプ
ションデータの組合せは、通常は、限定されており、数
も少ない為、ライブラリの規模もそれ程、大きくはなら
ない性質を利用している。

【０２４９】これによってシステム立ち上げ時には、ネ
ゴシエーションによるオプションデータの確認調整が必
要となるが、その後の定常状態での運用では、調整確認
済のオプションデータと１対１に対応させた拡張ＰＰＰ
の識別フィールドの識別コードの値を使って、毎回行う
ネゴシエーションを省いて、ただちに接続を確立するこ
とが出来るようになる。

【０２５０】これは、サテライトオフィスや在宅勤務な
どの場合、アクセスするユーザもアクセスするアクセス
サーバも、通常、決まっており、従ってオプションデー
タの値も通常は、通信相手同士の間で、一定の組合せ値
に固定されており、毎回、ＰＰＰ確立の為の同じネゴシ
エーションを行う必要性が本来はないことを利用してい
る。

【０２５１】モバイルユーザの場合も自分の使用する同
じ端末を使うことにすれば、端末の発信者番号表示機能
を使って、ユーザの特定が可能であり、同様にして、最
初のアクセス時に確認したオプションデータの組合せ
を、識別コードによる短縮コードで通知することが出
来、２回目以降のＰＰＰ接続確立におけるＬＣＰ、ＮＣ
Ｐのネゴシエーションの過程を短縮し、高速アクセスを
行うことが出来る。

【０２５２】これは、異なる設定環境のユーザ同士での
最初に相互接続する場合や、最初に接続される未知の端
末との間でパラメータ値の調整を行う為にも有効であ
る。

【０２５３】次に、複数の制御パラメータを具体的にネ
ゴシェーョンによって決める手順について説明する。

【０２５４】尚、この手順は、上述の如く、システムを
立ち上げる場合に、最初に１回行うだけで良く、２回目
以降の通常の運用状態では、オプションデータ即ち通信
制御パラメータの組合せと１対１に対応付けを行った拡
張ＰＰＰフレームにおける識別フィールドを活用して高
速の接続を行うことが出来る。システムの変更などオプ
ションデータの変更時には、再度、確認調整を行う。

【０２５５】ダイヤルアップ接続時に、通信端末がネゴ
シエーションを要求するのか、定常状態で、短縮識別コ
ードによりオプションデータの設定を行うのかの区別
は、図５の拡張ＰＰＰフレームのアドレス・制御フィー
ルドの識別コード設計例にも示した如く、拡張ＰＰＰの
識別コードの特定ビットを使って、指示することが出来
る。

【０２５６】図１３のＬＣＰネゴシエーションによる拡
張ＰＰＰにおける識別コードの決定は、このように制御
パラメータの組合せを決定する為に、ＬＣＰネゴシエー
ションを行う様子を示す。

【０２５７】図１３で、送信装置、受信装置共に装置自
身の使用可能なオプションを含めた設定要求（Configur
e Request)を相手装置に対して送信し、それを受信した
相手装置は、図２８のＬＣＰフェーズの接続確立におけ
る設定オプションのネゴシエーションの（ｂ）のオプシ
ョンネゴシエーション時の例で説明した如く、それらの
オプションの全てが使用可能な場合には、設定確認(Con
figure Ack) 、一部使用可能な場合には設定否定(Confi
gure Nak) を返信する。

【０２５８】この際、図１４の拡張ＰＰＰにおけるＬＣ
Ｐフレーム構成は、この最初のアクセス時に、拡張ＰＰ
Ｐにおけるフレーム構成の内、拡張ＰＰＰフレームが、
ＬＣＰフレームであることを意味するＰＰＰプロトコル
ＮＯ（２１Ｈ）部分と引き続くＬＣＰフレーム部分を抜
き出したものである。

【０２５９】このＬＣＰフレーム構成は、インターネッ
トの技術標準化委員会のＩＥＴＦで定められており、コ
ードには、設定要求（Configure Request)では０１Ｈ、
設定可確認(Configure Ack) では０２Ｈ、設定否認(Con
figure Nak) では０３Ｈが、また、設定拒否（Configur
e Reject) では０４Ｈの値が入れられる。

【０２６０】図１４における識別子は、転送パケットの
要求と応答の区別を行い、正しく、手順通りに要求と応
答が行われるようにする為のもので要求と応答に対応す
る定まった値が入れられる。

【０２６１】ＬＣＰパケット長は、ＬＣＰフレームのデ
ータ長を、オプション部の、タイプは、オプションデー
タの意味を指示している。

【０２６２】タイプは、図２７のＬＣＰフレームにおけ
る設定オプション機能で説明した如く、現在、１１種類
のオプションデータの意味が定義されている。

【０２６３】新たなタイプを定義して広く一般的に使う
為には、ＩＥＴＦへの登録が必要となる。

【０２６４】拡張ＰＰＰ用を、企業内や企業グループ内
の限定された範囲で使う場合には、８ビットのコードの
数の範囲で、任意に、新たなオプションデータの意味に
対応させて設定出来る。

【０２６５】新たなオプションデータをインターネット
で広く使う場合には、タイプのＩＥＴＦへの登録と承認
が必要となる。

【０２６６】オプションデータ長は、オプション部のデ
ータ長を表す。

【０２６７】フィールドは、本発明の拡張ＰＰＰにおけ
る識別フィールド、すなわち、アドレスフィールドと制
御フィールドをどの様に使うかを決めるデータを入れ
る。

【０２６８】たとえば、アドレスフィールドのみを使う
場合には、このオプションデータ調整の時のオプション
データの値として０、制御フィールドのみ使う場合に
は、１、アドレスフィールドと制御フィールドの両方を
１つのフィールドとしてまとめて使う場合には、２、ア
ドレスフィールドと制御フィールドを同時に別々のフィ
ールドとして使用する場合には、３とする。

【０２６９】フィールド長は、フィールド部の示すデー
タの長さを示す。

【０２７０】データは、優先制御の場合は、プロトコル
番号、優先番号のセットを必要な数だけ設定する。ＰＰ
Ｐ多重の場合は、データ部に入れるデータは実行動作環
境のデータや、トンネリング等の動作が必要な場合に
は、対応する識別コード値を設定する。

【０２７１】例えば、ある特定のアプリケーションから
のデータには、識別コード９０Ｈを割当て、ＬＣＰのデ
ータフィールドには、９０Ｈ、133.161.192.254 と設定
して、受信装置は、９０Ｈを受信すると、133.161.192.
254 のＩＰアドレスを持つ企業のアクセスサーバへトン
ネリングパスを張る為の接続データライブラリを作成し
ておき、次回からのアクセスでは、識別フィールドの識
別コードの値を認識しただけで、瞬時に転送処理を行う
ようにする。

【０２７２】また、別の例として、（１）受信可能なフ
レームの最大長ＭＲＵ（Muximum Receiving Unit) とし
て1500バイト、（２）認証は発信者番号確認によって行
いＰＰＰでは行わない、（３）ＰＰＰの上位はＩＰに限
定してＤＨＣＰ（Dynamic Host Configuration Protoco
l)によってアクセスサーバから割当を受ける、などのオ
プションデータの組合せのパターンを識別コード値０１
Ｈとする。

【０２７３】受信側は、識別コード０１Ｈが設定された
ＬＣＰのConfigure Request を受信した時点で、通常の
手順を取らずに、即座に、ＬＣＰのConfigure Ack 、続
けてＮＣＰのConfigure Ack を送信する。

【０２７４】これによって、毎回、最初から全てのネゴ
シエーションを行った場合に比べて、ネゴシエーション
時間を１／２〜１／３に短縮することが出来る。

【０２７５】尚、本発明の拡張ＰＰＰによる通信システ
ムを、従来からのＰＰＰを利用した通信端末と混在する
環境で使う必要性がある場合が考えられる。

【０２７６】実際の導入にあたっては、この様な導入の
形態が最も自然な形となる。

【０２７７】この様な場合には、アクセスサーバ側に実
装された拡張ＰＰＰによる通信プロトコル処理ソフト
は、拡張ＰＰＰを実装した通信端末からのアクセスと、
従来のＰＰＰを実装した通信端末からのアクセスの双方
に対して、対応する能力を有する必要がある。

【０２７８】この様な場合には、アクセスサーバには、
最初にＰＰＰフレームを受信した時点で、既存のＰＰＰ
に対応するデフォルト値即ちアドレスフィールドにＦＦ
Ｈ、制御フィールドに、０３Ｈが設定されている場合
は、通常のＰＰＰ処理を行う。

【０２７９】又、拡張ＰＰＰに対応する上記以外の識別
コードの値が設定されていた場合には拡張ＰＰＰモード
での処理を行う。

【０２８０】拡張ＰＰＰモードであることが判明し、そ
のシステムがネゴシエーションによって最初のアクセス
時にオプションデータの識別コード対応ライブラリを作
成するように、定められている場合には、最初のネゴシ
エーションによって、オプションデータの組合わせに対
する識別コードの値を決めるライブラリを作成し、２回
目以降はネゴシエーションを省略してアクセス処理を行
う。

【０２８１】そのシステムが、予め決めておいた識別コ
ードとオプションデータの組合せの対応ライブラリに従
ってアクセスを行うように決めてある場合には、初回の
アクセスから、拡張ＰＰＰの識別コードを利用した、ネ
ゴシエーションを短縮したアクセス処理を行う。

【０２８２】また、拡張ＰＰＰの通信プロトコル処理ソ
フトを、従来のパソコンやダイヤルアップルータにイン
ストールする場合には、とくに、アクセスサーバ側にお
いてメモリサイズに対する配慮が必要となる。

【０２８３】企業等の限定したユーザの範囲で、限定し
た目的で使う場合は、識別フィールドの識別コード値と
オプションデータの組合せ対応の数も、識別フィールド
の利用ルールの範囲も少ないからとくに問題ない。

【０２８４】しかし、ＩＳＰのアクセスサーバ等では、
不特定多数のユーザに対する識別フィールドの識別値と
オプションデータの組合せの対応ライブラリを作る必要
がある。

【０２８５】この場合、ユーザ数が大きな場合は、ライ
ブラリの規模も大きくなる為、ユーザの規模に応じて、
性能保証面から必要な場合は、主メモリ規模の増設を行
う。

【０２８６】オプションデータとして標準値を使うユー
ザが多く、ユーザの違いによるオプションデータの違い
がそれ程大きなものにならなければ、上記の問題はとく
に起こらないため上記の配慮は不要となる。

【０２８７】いずれの場合でも、拡張ＰＰＰのソフトモ
ジュール自体は変更せずに、必要に応じてメモリやプロ
セッサの増設によって対応することが出来る。

【０２８８】

【発明の効果】本発明の拡張ＰＰＰフレームを用いた通
信システムによって、アクセスサーバへのアクセスの都
度、繰り返すＰＰＰのネゴシエーションによる接続確立
の為の時間を短縮し、トンネリングアクセス利用におい
ては、アクセスサーバへのアクセスモードの瞬時判別を
可能とし、音声等のリアルタイムデータを含む多重パケ
ット伝送時における迅速な優先制御が実現されその利用
上の適用効果は大きい。

【図面の簡単な説明】

【図１】 本発明の拡張ＰＰＰフレーム構成の原理説明
図である。

【図２】 拡張ＰＰＰフレームの識別コードによるＩＳ
Ｐ接続時のアクセスモード判定である。

【図３】 拡張ＰＰＰフレームの識別コードによる通信
開始時間短縮の説明図である。

【図４】 マルチプロトコル間の優先度指定識別コード
による待ち行列の制御イメージである。

【図５】 拡張ＰＰＰフレームのアドレス・制御フィー
ルドの識別コード設計例である。

【図６】 拡張ＰＰＰによる実施例１の優先制御の仕組
みである。

【図７】 拡張ＰＰＰによる実施例１の優先制御の送信
処理フロー図である。

【図８】 拡張ＰＰＰによる実施例１の優先制御の受信
処理フロー図である。

【図９】 拡張ＰＰＰによる実施例２のトンネリング
接続を含む多重通信利用イメージである。

【図１０】 拡張ＰＰＰによる実施例２における多重通
信処理の仕組みである。

【図１１】 拡張ＰＰＰによる実施例２における多重通
信処理の送信処理フロー図である。

【図１２】 拡張ＰＰＰによる実施例２における多重通
信処理の受信処理フロー図である。

【図１３】 ＬＣＰネゴシエーションによる拡張ＰＰＰ
における識別コードの決定である。

【図１４】 拡張ＰＰＰにおけるＬＣＰフレーム構成で
ある。

【図１５】 ダイヤルアップ接続によるＰＰＰを利用し
たアクセスサーバへの接続イメージ図である。

【図１６】 ＰＰＰを使った複数端末とアクセスサーバ
の接続である。

【図１７】 ＯＳＩ参照モデルとＰＰＰの関係である。

【図１８】 ＰＰＰによるマルチプロトコルのカプセル
化の説明図である。

【図１９】 ＨＤＬＣによるデータ通信の形態例であ
る。

【図２０】 ＰＰＰフレームフォーマットとＨＤＬＣフ
レームフォーマットの比較である。

【図２１】 パソコンとモデムによるＰＰＰ通信システ
ムの原理構成図である。

【図２２】 ＰＰＰ接続の通信プロトコル処理のやりと
りイメージである。

【図２３】 ダイヤルアップ接続動作中のＰＰＰ通信シ
ステム機能要素間の連携動作説明図である。

【図２４】 ＰＰＰの状態遷移フロー図である。

【図２５】 ＰＰＰフレームフォーマットの基本構成で
ある。

【図２６】 ＬＣＰフレームの構成である。

【図２７】 ＬＣＰフレームにおける設定オプション機
能である。

【図２８】 ＬＣＰフェーズの接続確立における設定オ
プションのネゴシエーションである。

【図２９】 トンネリングプロトコルによるＰＰＰ転送
と企業アクセスサーバとの接続である。

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B089 HA10 HB03 HB10 JB01 KA05 KB06 KB10 KC05 5K030 GA01 HA08 HC01 HC13 HD06 LE05 5K033 AA02 CB08 CB17 CC01 DA05 5K101 KK20 LL01 LL03 MM05 RR05 TT06

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ＰＰＰ（Point to Point Protocol)を用
   いた通信システムにおいて、 ＰＰＰフレームにおけるアドレスフィールドと制御フィ
   ールドの値を可変コード値とする拡張ＰＰＰフレームを
   用いることを特徴とする、 通信端末、通信回線、アクセスサーバからなる、 拡張ＰＰＰフレームを用いた通信システム。
2. 【請求項２】 請求項１に記載の拡張ＰＰＰフレームを
   用いた通信システムにおいて、 前記可変コード値として、上位プロトコルのオプション
   パラメータの組合せ値に対応した識別コード値とする事
   を特徴とする、 拡張ＰＰＰフレームを用いた通信システム。
3. 【請求項３】 請求項１に記載の拡張ＰＰＰフレームを
   用いた通信システムにおいて、 上位プロトコルのオプションパラメータの組合せ値と前
   記識別コード値との対応ライブラリの作成を、 通信端末からアクセスサーバへのアクセス時にＰＰＰの
   通信処理プロトコルによるＬＣＰネゴシエーションによ
   って行い、 以降のアクセスにおいては、該対応ライブラリによる前
   記識別コード値を、アドレスフィールド、制御フィール
   ドの可変コード値として用い、 通信端末とアクセスサーバ間の通信接続確立処理は、該
   識別コード値と対応ライブラリを基に行うことを特徴と
   する拡張ＰＰＰフレームを用いた通信システム。
4. 【請求項４】 請求項１に記載の拡張ＰＰＰフレームを
   用いた通信システムにおいて、 通信端末からインターネットサービスプロバイダ（以下
   ＩＳＰ）の前記アクセスサーバへのアクセスにおいて、 前記識別コード値のフィールドの一部は、前記アクセス
   サーバへのアクセスがインターネットへのアクセスなの
   か、企業のアクセスサーバへのトンネリングプロトコル
   によるアクセスなのかを識別するコード値を有し、 該フィールドと異なるフィールドには、該企業のアクセ
   スサーバへのアクセスアドレス値の短縮コード値を有
   し、 該ＩＳＰの前記アクセスサーバは、該アクセスアドレス
   値の短縮コード及び通信端末の回線発信番号とから、対
   応データライブラリによって、企業のアクセスサーバへ
   のＩＰアドレスを知り、 トンネリングプロトコルによる企業のアクセスサーバへ
   のアクセス処理を行うことを特徴とする拡張ＰＰＰフレ
   ームを用いた通信システム。
5. 【請求項５】 請求項１に記載の拡張ＰＰＰフレームを
   用いた通信システムにおいて、 アドレスフィールド、制御フィールドの上位プロトコル
   のパラメータと１対１に対応付けられた識別コード値と
   して、 上位プロトコルの転送待ち行列における優先順位を付与
   することを特徴とする拡張ＰＰＰフレームを用いた通信
   システム。