JP3967548B2 - リンク構成方法および装置 - Google Patents

リンク構成方法および装置 Download PDF

Info

Publication number
JP3967548B2
JP3967548B2 JP2000528055A JP2000528055A JP3967548B2 JP 3967548 B2 JP3967548 B2 JP 3967548B2 JP 2000528055 A JP2000528055 A JP 2000528055A JP 2000528055 A JP2000528055 A JP 2000528055A JP 3967548 B2 JP3967548 B2 JP 3967548B2
Authority
JP
Japan
Prior art keywords
protocol
packet
link
ppp
packets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2000528055A
Other languages
English (en)
Other versions
JP2002501331A (ja
Inventor
ルドウィグ、レイネル
ゲルデス、マルティン
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン(パブル) filed Critical テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Publication of JP2002501331A publication Critical patent/JP2002501331A/ja
Application granted granted Critical
Publication of JP3967548B2 publication Critical patent/JP3967548B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Radio Relay Systems (AREA)

Description

【0001】
(技術的背景)
本発明はリンク、好ましくはパケット交換により動作する通信網にアクセスする、リンクを構成するのに使用される通信装置および方法に関する。このような通信網の例はインターネットである。
【0002】
インターネットはコンピュータのネットワークであり、通信はパケットと呼ばれる単位により行われる。それは伝送される情報がこのようなパケットを介して配信されることを意味し、これらのパケットはネットワークを介して個別に独立して送ることができる。この通信は、ここではいわゆるインターネットプロトコルIPである、プロトコルにより支配される。プロトコルはフォーマットおよび一般的な通信手順を決定する1組のルールであり、ネットワークの各メンバーは他のメンバーと通信できるためにはプロトコルに従わなければならない。
【0003】
インターネットへアクセスするためのさまざまな可能性がある。最も基本的なのは専用回線、すなわちネットワークの一部であるもう1つのコンピュータに常時接続されている回線、を経由することである。したがって、専用回線を経由してネットワークへアクセスするコンピュータはネットワークのメンバーとなる、すなわちネットワークはそれによって拡張される。回線に沿った通信はIPに従って行われる。しかしながら、専用回線は費用がかかり、このような構成はインターネットへの永久アクセスおよび/もしくは大量データの迅速な伝送を必要とするユーザにしか意味をなさない。
【0004】
専用回線に替わるものは擬似専用接続でありそれはインターネットとの接続が必要である場合しか確立されないが、確立されれば専用回線のように作用する。このような接続の典型的な例は単一ユーザから、大学コンピュータや商業インターネットアクセスサーバ等の、インターネット内のサーバへのモデムリンクである。ユーザは必要な時にインターネットとの接続を確立するだけであり、専用回線に伴う高いコストはかからないが接続は専用回線のように作用するため、確立された接続によりユーザはインターネットの完全なメンバーとされる。
【0005】
2つのポイント(一方ではインターネットに一時的にアクセスしたいコンピュータ、他方では典型的に複数の他のインターネットメンバーに接続されるインターネット内のサーバ)間のこのような擬似専用接続にはそれ自体のプロトコルが必要である。2つの既知のプロトコルはSLIP(シリアルラインインターネットプロトコル)およびPPP(ポイントツーポイントプロトコル)である。近年、PPPがこのような擬似専用接続に対する支配的なプロトコルとなってきている。
【0006】
PPPはNetworking Group RfC(Request for Comments)1661,編集者ダブリュー.シンプトン,1994年7月に定義されている。PPPは3つの主要要素からなり、それはマルチプロトコルデータグラムのカプセル化方法(データグラムはネットワークレイヤ(IP等)における伝送単位)、データリンク接続を確立、構成およびテストするリンク制御プロトコル(LCP)、およびさまざまなネットワークレイヤプロトコルを確立かつ構成するためのネットワーク制御プロトコル(NCP)のファミリーである。ポイントツーポイントプロトコルは2つのいわゆるピア間、すなわちプロトコルに従うリンクの2つの端部間でパケットを移送するように設計されている。これらのリンクは全二重同時双方向動作を提供する。
【0007】
PPPにより確立されたリンクの両端間の通信はデータグラム、すなわちIP等のネットワークレイヤにおける伝送単位、が1つ以上のフレーム内へカプセル化されてデータリンクレイヤへ通されるように遂行される。データリンクレイヤ上の伝送単位フレームであり、それはいくつかのデータユニットと共にヘッダーおよび/もしくはトレーラ(trailer)を含むことができる。通常、パケットはフレームへマップされる。
【0008】
カプセル化フォーマットオプション(encapsulation format option)を取り決め、パケットサイズの変化する限界を処理し、構成エラーを検出し、リンクを終端するためにLCPが使用される。他のオプショナルなファシリティはリンク上のそのピアのアイデンティティの認証、およびリンクが適切に機能している時および故障している時の決定である。
【0009】
図2にRfC1661に従ったPPPカプセル化(フォーマット)を示す。参照番号1はプロトコルフィールド、2は情報フィールド、3はパディングフィールド(padding field)を示す。これらのフィールドは左から右の順で伝送される。
【0010】
プロトコルフィールド1は1もしくは2オクテット(オクテットは8−ビットからなるバイトに対する別の表現)であり、その値はパケットの情報フィールド2内にカプセル化されたデータグラムを識別する。“0***”から“3***”の範囲内のプロトコルフィールド値は特定のパケットに対するネットワークレイヤプロトコルを識別し、“8***”から“b***”の範囲内の値は、存在する場合の、関連するNCPに属するパケットを識別する。“4***”から“7***”の範囲内のプロトコルフィールド値は関連するNCPが無い低ボリュームトラフィックを有するプロトコルに対して使用される。“c***”から“f***”の範囲内のプロトコルフィールド値はパケットをLCP等のリンクレイヤ制御プロトコルとして識別する。
【0011】
RfC1661は前記値に対して下記を予約している。
【表1】
Figure 0003967548
【0012】
情報フィールドは0以上のオクテットである。情報フィールドはプロトコルフィールド内に指定されたプロトコルに対するデータグラムを含んでいる。情報フィールドの最大長は最大受信単位(MRU)と呼ばれ、それはパディングを含めて1500オクテット(バイト)にデフォルトする。交渉により、許可するPPPインプリメンテーションはMRUに対する他の値を使用することができる。
【0013】
最後に、情報フィールドにMRUまでの任意数のオクテットをパディング(パッド(pad)として付加)することができる。このパディング(padding)はパディングフィールド内に含まれパディングオクテットと実際の情報とを識別するのは各プロトコルの責任である。
【0014】
RfC1661に従って、ポイントツーポイントリンクを介した通信を確立するために、PPPリンクの各端部は最初にデータリンクを構成しテストするためのLCPパケットを送らなければならない。それは絶対的必要条件である。リンクが確立された後で、ピアを認証することができ、すなわちそれはオプションである。次に、PPPは1つ以上のネットワークレイヤプロトコルを選択し構成するためのNCPパケットを送らなければならず、それも絶対的必要条件である。選択した各ネットワークレイヤプロトコルが構成されていると、各ネットワークレイヤプロトコルからのデータグラムをリンクを介して送ることができる。明確なLCPパケットがリンクダウンを閉じるか、あるいはある外部イベントが生じる(例えば、非動作タイマーが切れる)までリンクは通信のために構成されたままとされる。
【0015】
リンクを介した構成要求パケットの受信に応答してピアが送り出す基本的返答に次の3つがあることは留意すべきである。すなわち、例えば受信パケット内に提示した設定が受理されることを示すACKパケット(受信応答)を送り出す、例えば提示した設定が受理されないことを示すNACKパケット(非受信応答)を送り出す、あるいは例えば誤ったシンタクスを有するため拒否パケットを送出して受信パケットを受理できないことを示す、ことである。またピアは拒否パケットを送り出すことなくそれを廃棄することによりパケットの受信に反応することもできる。したがって、それは“サイレント(silent)”廃棄と呼ばれる。
【0016】
前記したように、構成パケットの交換を介した接続を確立するためにリンク制御プロトコル(LCP)が使用される。この交換は完全であり、構成ACK(受信応答)パケットが送り出され受信されておればLCP開放状態に入る。このいわゆるリンク確立フェーズ中は、LCPしか処理されずいかなる非LCPパケットも必ず処理されずに廃棄される。
【0017】
リンク確立フェーズの後に、認証フェーズが続くことがある、すなわちオプショナルである。しかしながら、ピアがある特定の認証プロトコルで認証することをインプリメンテーションが所望する場合には、リンク確立フェーズ中にその認証プロトコルの使用を必ず要求しなければならない。リンク確立フェーズに続くことがあるもう1つのフェーズはリンク品質決定フェーズであり、そこではリンク品質決定パケットが交換される。認証およびリンク品質決定は同時に行われることがある。認証フェーズの後で、NCPパケットを交換する後続フェーズに入るのは認証が成功する場合だけであり、そうでなければリンク終端が行われる。このフェーズ中に、LCPパケット、認証プロトコルパケットおよびリンク品質決定パケットだけが処理され、このフェーズ中に受信される他の全てのパケットは必ず処理されずに廃棄される。
【0018】
前記したフェーズがうまく完了すると、各ネットワークレイヤは必ず適切なネットワーク制御プロトコル(NCP)により別々に構成しなければならない。このようなNCPの例はIPCP(インターネットプロトコル制御プロトコル)である。NCPが開放状態に達した後で、PPPは対応するネットワークレイヤプロトコルパケットを運ぶ。対応するNCPが開放状態ではない時に受信されるサポートしたネットワークレイヤプロトコルパケットはどれも必ず処理せずに廃棄しなければならない。
【0019】
最後に、リンク終端フェーズはLCPを使用して終端パケットの交換によりリンクを閉じることを含んでいる。このフェーズ中に受信される非LCPパケットは必ず処理せずに廃棄しなければならない。
【0020】
(本発明がかかわる問題)
近年、通信手段および情報ツールとしてのインターネットの重要性が高まっているだけでなく、セルラー電話網等のワイヤレス通信網の提供も普遍的となってきている。その結果、ワイヤレスすなわちセルラー加入者に対してインターネットへのリンクを確立するための装置および方法に対する要求が生じている。
【0021】
セルラーネットワークを介してインターネットがアクセスされる場合には、予め確立された回路交換リンクの構成にポイントツーポイントプロトコル(PPP)が最も広く使用される。それを図3について説明する。
【0022】
図3の底部はモバイルノード10内の端末装置TEがインターネットと通信するためにネットワークノードと通信する構造を示す。端末装置TEは例えばラップトップコンピュータである。TEはMS/TAFに接続されており、それは移動局/端末アダプテーション機能を意味する。移動局は例えば移動電話機であり、端末アダプテーション機能は例えば移動電話機およびラップトップコンピュータを接続するPCMCIAにより実現される。移動局MSは移動体通信交換局MSCとの通信リンクを確立する。移動体通信交換局はインターワーキング機能IWFを介してアクセスユニットAUに接続されている。アクセスユニットAUは回路交換接続を終端させネットワークレイヤPDUをインターネットに対してルーティングする。
【0023】
図3の上部に示すように、モバイルノード10内の端末装置(TE)およびダイレクトアクセスユニット(AU)はそれらの間に予め確立されたトラフィックチャネルがPPPに従って構成され、次にネットワークレイヤプロトコルデータユニット(PDU)、例えばIPパケット、がチャネルを介して伝送されるように制御される。二重矢符号40はTEおよびAU間の構成されたリンクを表わし、前記リンクはPPPに従って構成されIPパケットを伝送する。802の数字はLANに対するフレーミング標準を表わす。
【0024】
前記したPPPが必要とするさまざまな通信フェーズを図4に略示する。基本通信リンクが確立されている、すなわちリンクはアップである、ことをTEおよびAU内の2つのピアが知らされる(例えば、メッセージを受信する)時に通信が開始する。図3の例では、モバイルユニット、例えばセルラー電話機、は端末装置、例えばラップトップコンピュータ、への確認された回路交換接続を示す。前記した例では、この基本リンクは移動局MSおよび移動体通信交換局MSCが属するセルラーシステムにより提供される回路交換リンクである。判り易くするために、図4には端末装置(TE)により送られる要求およびアクセスユニット(AU)により送られる受信応答しか図示されていないが、アップである基本リンクに応答して、事実両方のピアがこれらの要求をほとんど同時に伝送開始すると理解すべきものである。また、図4はPPPに従って構成および通信する絶対的理想ケースを示している、すなわち最少量の情報交換しか示していない、点も重要である。
【0025】
第1のフェーズすなわちリンク確立フェーズにおいて、LCP要求パケットおよびLCP要求受信応答パケットが交換される。前記したように、このフェーズは強制的でありPPPリンクを確立する目的に役立つ。図示する第2のフェーズは認証フェーズであり、それはPAP/CHAP要求パケットおよびPAP/CHAP要求受信応答パケットを交換する(PAP=パスワード認証プロトコル、CHAP=チャレンジ−ハンドシェークプロトコル)。このフェーズはオプショナルであるが、セキュリティを高めるため通常利用される。第3のフェーズはNCPフェーズ、ここではIPCPフェーズ(IPCP=インターネットプロトコル制御プロトコル)である、すなわち開かれるネットワーク制御プロトコルはインターネット制御プロトコルである。このフェーズはIPCP要求パケットとIPCP要求受信応答パッケージの交換を含む。このフェーズは強制的である。このIPCPフェーズの後でのみ、IPパケットが交換できしたがってモバイルノード10内の端末装置が完全にインターネットに接続されるように、PPPおよびIPに従ったリンクが確立される。
【0026】
1セットのパケットを交換するための持続時間はラウンドトリップ時間(RTT)と呼ばれる、図4参照。すなわち、ラウンドトリップ時間は要求パケットの送り出しと対応する受信応答パケットの受信との間で経過する時間である。
【0027】
図4に示すように、TEにより開始されるPAPが必要とする2方向ハンドシェークとは反対に、CHAPはAUにより開始される3方向ハンドシェーク(図4には図示せず)を必要とすることに留意すべきである。しかしながら、AUは第1のCHAPパケットをそれが送り出す最後のLCP要求受信応答パケットに相次いで返送することができるため、それによってフェーズの持続時間が増すことはない。
【0028】
RfC1661にレイアウトされたPPPに対する必要条件に従って、前記した各フェーズは次のフェーズを開始できないうちに完了しなければならない。したがって、IPパケットを送り出すことができる前の絶対最少構成時間は認証が選択されるか否かに応じて2もしくは3RTTとなる。実際上、リンクを確立するための持続時間は7RTT以上となることがある。それはLCPもしくはIPCPにおける交渉によるものである。PPPピアが異なるリンク設定を望む場合には、NACK(受信応答されていない)および新しい要求は交換しなければならないため、LCPおよびNCPにより処理されるオプションの交渉は数RTTとなることがある。リンク品質決定プロトコルパケットがさらに交換される場合には、確立時間はさらに長くなる。セルラーネットワーク内のトラフィックチャネルのRTTは850msにも達することがある。GSMでは、セルラー標準の例として、HSCSD(高速回路交換データ)において行われるようにどれだけ多くのトラフィックチャネルが単一接続のために一緒に束ねられるかとは無関係に、RTTは600msよりも少なくなることはなく通常は750ms程度である。
【0029】
ユーザがインターネットを介してデータを送り出すもしくは受信するまでの待機時間とみなすこの長いリンク確立時間の問題はユーザにとって煩わしいものである。この問題はRfC1661にレイアウトされたPPPに従って動作するシステムに限定されるものではなく、後に続く接続フェーズを開始できないうちに特定の接続フェーズを完了させることに関する前記した厳しい必要条件を有する任意のシステムにおいて遭遇することに注目すべきである。
WO96/21984にはパケット無線システムおよび対応する端末装置が開示されている。この従来技術の文献ではGSMにおける一般的なパケット無線サービスGPRSが検討され、特に特殊な無線リンクプロトコルのリンク内にPPPパケットをカプセル化する時に、冗長情報がこのように伝送されるために帯域幅が無駄に使われてしまう問題が指摘されている。その結果、この文献はPPPデータフレームから不要なフィールドの一部を除去することにより制御データを低減することを示唆している。すなわち、PPPデータフレームの無線リンクプロトコル内に既に含まれている部分がPPPフレームから除去される。しかしながら、この文献はPPPリンクのセットアップには関連していない。
WO96/00468には不完全メッシュネットワーク(IMN)上でPPPプロトコルを使用する方法が説明されている。特に、この文献は不完全メッシュ通信網を介したポイントツーポイントデータ通信リンクのエミュレーションに関連している。典型的にIMNは正しい順序の伝送を保証できないため、この従来技術の文献はIMNを横切ってPPPパケットを転送する問題について検討している。この文献に記載された展開はいわゆるライトウェイトトランスポートプロトコル、すなわち順序正しい送出しを保証しないプロトコル、をIMN上で使用することからなっている。その利点は従来のシステムで使用されるIMNにおける付加再送信により性能が不必要に劣化するようにPPP等の高レイヤプロトコルが以前に再送信を行う事実にある。しかしながら、この文献はリンクの確立には関連していない。
【0030】
(発明の目的)
したがって、本発明の目的はパケット交換網(例えば、インターネット)とのリンクを確立するように設計される装置を制御するための改良された方法を提供することである。
【0031】
本発明のもう1つの目的は対応する装置を提供することである。
【0032】
(発明の開示)
これらの目的は以下の通信制御方法により達成される。通信装置は、通信リンクによりもう1つの通信装置に接続されて前記通信リンクがパケット交換用に構成される。前記2つの通信装置の一方は他方側で第1のプロトコル(例えば、IP)に従うパケット交換網に接続される。前記通信装置制御方法は少なくとも前記第1のプロトコルをカプセル化しかつ前記リンクを確立し構成するための第3のプロトコル(例えば、LCP)を含む第2の予め決められたプロトコル(例えば、PPP)に従ってパケットを交換することにより前記リンクを介した通信が行われるように前記装置を制御することが可能であり、
前記第2のプロトコルによる要件は、
−前記リンクを介して送られるパケットが、前記第3のプロトコルに対し少なくとも1つの特定値が予約され他の所定値は前記第2のプロトコルにより使用されないようにして、予め決められたプロトコルに対し予め決められた値が予約されるプロトコルフィールドと、前記プロトコルフィールド内に含まれる値により示されるプロトコルに関連するデータを含む情報フィールドとを含むことと、
−リンクを構成するプロセスが、プロトコルフィールド内の前記第3のプロトコルを示すパケットしか処理されず他の全てのパケットは廃棄されるようにパケットが交換される少なくとも1つのフェーズを含むことであり、
前記通信装置制御方法はさらに、
前記第2のプロトコルに従う前記リンクを介してそのプロトコルフィールド内の前記第3のプロトコルを示す第1のタイプのパケットを送り出すステップと、
引き続き前記第2のプロトコルにより許可はされるが使用されない値をそのプロトコルフィールド内に有する第2のタイプの少なくとも1つのパケットを送り出し、前記第2のパケットは前記第2のプロトコルに従って動作する通信装置により拒否はされないが処理せずに廃棄されるようにするステップと、
前記第1のタイプのパケットの受信を待機し受信されればそれを格納し、前記第2のタイプのパケットの引き続く受信を所定時間待機するステップと、
第2のタイプのパケットが受信されなければ前記第1のタイプの前記格納されたパケットを処理して引き続き前記第2のプロトコルに従って動作するステップと、
このようなパケットが受信されれば前記第2のタイプのパケットを処理するステップとを含んでいる。
【0033】
本発明に従って、リンクに接続された2つのピアが前記方法に従って動作する場合、必要な全ての情報(例えば、LCP,IPCP等)を並列に、すなわち両方向に同時に、送ることにより第2のプロトコル(例えば、PPP)により利用されるリンク構成のシーケンシャルステップを回避することができる。それによりリンク構成の速度が著しく増加する。一方、本発明に従って一方のピアしか動作せず他方のピアは前記第2のプロトコルに従う場合には、本発明によるピアは前記第2のプロトコルに従う動作モードへ自動的に戻る。したがって、コンパチビリティが保持される。
【0034】
その結果、第2のプロトコル(例えば、標準PPP)に従って動作する他のシステムとのコンパチビリティ問題を生じることなく本発明を既存のシステム内に統合することができる。一方、ポイントツーポイントリンクを形成する両方のピアが本発明に従う場合には、パケット交換によるデータ通信を第2のプロトコル(例えば、標準PPP)に従うよりも遥かに速く確立することができる。
【0035】
したがって、本発明はセルラー通信システムのインターネットのようなパケット交換網へのポイントツーポイントリンクの構成を処理する部分へ応用すれば特に有利である。しかしながら、本発明はそこに限定されるものではなく他の全てのハイレイテンシ通信リンク、例えば衛星リンク、および/もしくは他のいわゆる“チャッティ(chatty)”プロトコル、すなわちリンクを構成する時に極端な数のパケットを交換する必要があるプロトコル、RfC1661に従った標準PPPはその一例にすぎない、の修正にも有利に応用することができる。
【0036】
(詳細な説明)
現在本発明の最善の実施態様と考えられる本発明の好ましい実施例に従って、セルラー通信網のインターネット等のパケット交換網とのポイントツーポイントリンクを確立する責任のある部分へ発明概念が応用される。それらは図3に示す端末装置(TE)および直接アクセスユニット(AU)である。したがって、図3の下部のハードウェアの前記説明は繰り返さない。
【0037】
この好ましい実施例では、本発明は予め確立された回路交換リンクをRfC1661に明記されたPPPとは異なるが前記標準PPPとのコンパチビリティは保持される修正に従って構成するのに使用される。したがって、既知のポイントツーポイントプロトコルに関する前記開示は本発明の開示に完全に組み込まれる。
【0038】
以下の説明において、標準PPPピア(peer)という用語はRfC1661に定義されたPPPにしか従わないピアのことであり、CSD−PPPピアは本発明の概念に従って動作する、すなわち本発明のパケット交換モードに従う、が標準PPPに従って動作することもできるピアのことである。CSDという用語は回路交換されたデータを意味し、したがって本実施例が回路交換リンクを構成するのに使用されるという事実に関係する。
【0039】
また、マスクしたPPPパケットという用語はRfC1661に定義されたシンタクス(syntax)およびセマンテクス(semantics)を有するが“不正”プロトコルフィールドをもつパケット(LCP,PAP,CHAP,IPCPもしくはIPパケット等)を指示するのに使用される。“不正”をもつパケットは意味しない。“不正”はマスクしたPPPパケットのプロトコルフィールド内でプロトコルを示すのに使用される値が必ずしも予約はされないが、一方では有効プロトコルフィールドがどのように定義されるかに関してRfC1661に従うように一意的に選択されるべきことを意味する。例として、0x8001から0x801fの16進範囲からの値は受理できる候補である(表1参照)。これらの必要条件は標準PPPピアがこれらの“不正”パケットを廃棄しなければならずそれらを拒否してはならないという事実から生じる。標準PPPピアが例えばリンク確立フェーズであれば、それはLCPパケットを処理するだけでPAPやCHAP等の他のパケットは廃棄する。
【0040】
その結果、標準PPPピアがマスクしたPPPパケットを受信すると、そのパケットはサイレント廃棄される。
【0041】
一方、CSD−PPPピアはマスクしたPPPパケットを識別できるように制御される。マスクしたパケットはあるプロトコル(例えば、LCP)がPPPパケットのプロトコルフィールド内に含めることができる値、すなわち標準PPPに受理される値、に割り当てられるがそれにより使用はされない(例えば、前記した0x8001から0x801fの16進範囲)パケットである。マスクしたパケットの情報フィールド内に含まれる情報は標準パケットに対するものと同じルールに従う。例として、ピアがMRUを所与の値にリセットするLCPパケットを送り出す場合には、標準パケットおよび対応するマスクしたパケットは同一情報フィールドを有するが、異なるプロトコルフィールドを有し、標準パケットはPPPにより規定される値を含みマスクしたパケットはPPPパケット内のプロトコルフィールドに対しては許可されるがPPPにより使用はされない、すなわちPPPにより特定プロトコルに対して保存されない前記した値(表1参照)の1つを含んでいる。
【0042】
CSD−PPPピアは次にマスクしたパケットを処理してリンクを確立しマスクしたパケット内の情報に従ってデータを伝送する。本発明に従ったシステムおよび方法は標準PPPにより要求されるフェーズの厳密な分離(図4参照)を必要としないように設計される。両方のピアは予め定義された1組のLCPおよびIPCPオプション、例えば下記の表2に明記されたセット、を採用してまずLCP、認証およびIPCPフェーズおよびIPパケットの交換を同時に開始する。“同時に”という意味は構成されるリンクが“アップ”である(確立された)というメッセージに応答して、両方のCSD−PPPピアがほとんど同時にパケットを送り始めるが、標準PPPとは対照的に次のフェーズが始まらないうちに各フェーズをうまく完了させなければならない図4に示す手順には従わないことを意味する。むしろコンパチビリティを保証するために、最初に前記した標準LCPパケットを送り出し次に1つ以上のマスクしたパケットを送り出す。両方のピア共リンクアップメッセージに応答して送出開始するため、マスクしたパケットのこの送り出しは双方向でありほとんど同時である。これらのマスクしたパケットはリンクを構成するための所望もしくは所要パケット、例えば図4の例で逐次送られるパケット、の一部もしくは全部を含んでいる。すなわち、図4に示すシーケンシャル処理は並列に遂行することができる。その結果、特にハイレーテンシリンクに対して、構成速度は途方もなく増加する。例として、2つのCSD−PPPピアがいかなる設定も交渉する必要がなく全ての構成が相互に受理できる場合には、本発明のシステムにおいて構成時間は0.5RTTへ低減される。構成フェーズを並列とするこの基本的アスペクトについては図5から図7に関して後述する。
【表2】
Figure 0003967548
【0043】
リンクを確立するプロセスはCSD−PPPピアにより最初にLCPパケット(標準PPPに従った正規のリンク確立プロセスに完全に従うパケット)が相次いで送られ、その後マスクしたパケット好ましくは1組のマスクしたパケットが相次いで送られるように行われる。受信ピアが標準PPPピアであれば、それは第1のLCPパケットを受理して処理しマスクしたパケットをサイレント廃棄する。このようにして、コンパチビリティが保持される。
【0044】
受信ピアがCSD−PPPであれば、標準LCPパケットをサイレント廃棄して替わりにマスクしたパケットを処理するように制御される。それは最初に標準LCPパケットを一時的に格納し次にマスクしたパケットが続くかどうかを調べるために待機して行われる。マスクしたパケットが続く場合には、格納された標準LCPパケットはサイレント廃棄されてマスクしたパケットが処理される。しかしながら、マスクしたパケットが続かない場合には、標準LCPパケットが処理され標準PPPに従って標準PPPリンクを完全に確立する。それは図4に示すフェーズのシーケンシャルな完了が追従することを意味する。したがって、CSD−PPPピアが標準PPPピアと通信する場合には、自動的に標準PPPへ戻って標準PPPピアのように作用するように制御される。
【0045】
同じ動作がCSD−PPPピアでも実施され、前記したように、それは標準LCPパケットおよびそれに続く1組のマスクしたパケットを送り出すが、標準LCPパケットだけを受信して他のピアからのマスクしたパケットは受信しない。したがって、このCSD−PPPピアは他のピアが標準PPPピアであることを学習し、自動的に標準PPPモードへ戻るように制御される。
【0046】
要約すれば、前記実施例はパケットリンクを確立するためにCSD−PPPピアが最初に標準[PPP]LCPパケットを送り出しそれに相次いでマスクしたパケットの初期セットを送り出すように働き、前記マスクしたパケットが含んでいるのはLCP情報だけではない。これらのマスクしたパケットは好ましくは標準PPPシステムにおいてシーケンシャルフェーズで送られる構成情報の全てもしくは少なくとも一部を含んでいる(図4参照)。本発明のシステムでは、図4に示すシーケンシャルフェーズにおいて標準パケット内で送られる情報は前記最初の標準LCPパケットの後のマスクしたパケットの初期セット内で送られる。このようにして、本発明のシステムおよび方法により並列構成プロセスが与えられる。
【0047】
受信CSD−PPPピアは標準LCPパケットをサイレント廃棄してマスクしたパケットの初期セットを処理しマスクしたパケット内の情報に従ってリンクを確立して使用する。一方、受信ピアが標準PPPピアであれば、それは標準LCPパケットを処理してマスクしたパケットの初期セットをサイレント廃棄し、標準PPPリンクを確立する、すなわちシーケンスおよびタイプが標準PPPに完全に従う応答パケットを戻すだけである。CSD−PPPピアが標準LCPパケットしか受信しない(すなわちマスクしたパケットが続かない)すなわちそのマスクしたパケットに対するいかなるマスクした応答パケットも受信しない場合には、自動的に標準PPPモードへ戻って標準PPPピアのように機能する。
【0048】
処理すなわち廃棄のアクションは本発明のこの実施例のシステムおよび方法によりマスクしたパケットが標準PPPにより拒否されないようにPPPパケットの標準プロトコルフィールドに対して許された値を使用して達成され、前記値は一方では標準PPPにより使用するために保存はされず、それらは標準PPPにより処理されずにサイレント廃棄されるだけである。一般的に、それはマスクしたパケットがPPPにより拒否されずにサイレント廃棄されるように定義されることにより本発明の実施例が標準PPPとコンパチブルとなるように設計されることを意味する。
【0049】
本発明の基本的方法を図1のフロー図により説明する。最初のステップS1において、装置は通信リンクが確立されるまで待機する。例えば、図3に示す端末装置は回路交換リンクが確立されていることを示す移動局MSからのリンクアップメッセージを受信する。次に、ステップS2において、標準PPPに従う標準LCPパケットが送り出され、バックツーバック(back to back)で少なくとも1つのマスクしたパケット、好ましくは1組のマスクしたパケットが送り出される。ステップS3において、装置はリンクの他端から標準LCPパケットが受信されるまで待機する。この標準LCPパケットが受信されると、それはステップS4において格納される。ステップS5において、装置はリンクの他端がマスクしたパケットを送っているかどうかを調べる。送ったのであれば、方法はステップS6へ分岐し、そこでマスクしたパケットは処理されてマスクしたパケットおよび恐らくはそれに続くマスクしたパケット内の情報に従って通信が行われる。一方、ステップS5における判断が否定的であれば、方法はステップS7へ分岐し、そこで装置は標準PPPモードへ戻り、標準PPPに完全に従うリンクを確立するために標準PPPに従うパケットだけを処理する。
【0050】
ステップS7に従う処理は標準PPPに完全に従うことに留意すべきである。ステップS6に従う処理はCSD−PPPピアがリンクの構成後にマスクしたパケット、例えばマスクしたIPパケット、を送って処理し続けるか、あるいはマスクしたパケットが構成にしか使用されずリンク構成後にCSD−PPPピアは標準ネットワークレベルパケット、例えばPPPに従う標準IPパケット、の送り出しに戻るようなものとすることができる。
【0051】
この実施例に従って、マスクしたパケットの初期セットは、第1の構成フェーズにおいてLCPパケットしか許可しない標準PPPとは対照的に、LCP,PAP,CHAP,IPCP,IPその他の任意タイプの情報を含むことができる。本発明の本実施例のシステムおよび方法は、標準PPPについて前記したシーケンシャルプロセスとは対照的に、並列構成プロセスの可能性を提供する。その結果、前記実施例に従ったシステムは僅か0.5RTT後に迅速にリンクを確立してIPパケット送り始めることができ、それは標準PPPに比べて著しい速度増加である。
【0052】
どのタイプのパケット(PAP,CHAP,等)がマスクしたパケットとして送られるかは個別の必要条件およびインプリメンテーションによって決まる。例えば、1つのインプリメンテーションはPAPパスワードが常に与えられる必要があるという必要条件を含み、もう1つのインプリメンテーションはPAPパスワードが特定の条件下にあればよくさらにもう1つのインプリメンテーションはPAPに対する規定がなにもない。インタラクトする2つのCSD−PPPピアの例が下記に示され、前記した実施例に基づく本発明のさらなる実施例を構成する。
【0053】
もう1つの実施例として、CSD−PPPピアは前記したマスクしたパケットの初期セットの一部として適切なマスクしたLCPもしくはIPCPパケットを送ることにより予め定められたLCPもしくはIPCP設定を変えることができる。設定のこのような変更の例はMRUを296および1500間の値へ調節することである。このような変更がなされる場合、受信CSD−PPPピアはそれを受理したりしなかったりすることができる。したがって、受信CSD−PPPピアはマスクしたACK(受信応答)もしくはNACK(非受信応答)により応答する。
【0054】
さらにもう1つの例として、CSD−PPPピアはPAPおよびCHAPの両方をサポートすることができるが、AU内のCSD−PPPピア(図3参照)は使用される認証プロトコルを指示する。認証が必要であれば、認証フェーズ中にCSD−PPPピアにより受信されるIPパケットはバッファしなければならず(すなわち、一時的に格納される)かつ認証フェーズが成功しないうちに受信IPピア(すなわち、TE内のCSD−PPPピアがAU内のCSD−PPPピアを介して接続されると思われるインターネット内のピア)へ転送してはならない。
【0055】
前記したCSD−PPPピア動作の例外のケース、例えばIPアドレスが既に割り当てられておりかつ/もしくはIPパケットが既に受信されているのに認証に失敗した場合においては、リンクを終端させなければならずAUにより割り当てられるIPアドレスを割当て解除して受信IPパケットを廃棄しなければならない。
【0056】
以下に、図4の標準PPPが必要とする手順と比べられる図5から図7の線図に関していくつかの例について説明する。図4のケースと同様に、図5から図7ではTE内のピア(図3参照)がAU内のピアと通信するものと仮定され、図5から図7はCSD−PPPピアを示し図4は標準PPPピアを示すにすぎない。また、実際の通信は常に反対方向でも行われる、すなわち通信は常に双方向であるため、図4と同様に、図5から図7に示す通信は説明の目的で簡単化されている。図4に関して前記したように、それは図5から図7にはAUからTEへの最初の送信が示されているが、TEはほぼ同時にそのパケット、すなわち最初のLCPパケット、を送り始め次に相次いでマスクしたパケットの第1セットを送ることを意味する。すなわち、リンクがアップであるという信号に応答して2つのサイドが共に送り始め、リンクがアップであることを一般的に両サイドがほぼ同時に確認する。
【0057】
また、簡単化しかつ大要をよく掴むために、前記した予め定められた設定を変更するためのオプションでマスクしたLCPおよびIPCPパケットおよび対応する前記したACKおよびNACKは図5から図7には含まれていない。
【0058】
さらに、それ自体をCSD−PPPピアとして識別するためにCSD−PPPピアにより標準LCPパケットの後で相次いで送られる初期マスクしたLCPパケット(好ましくは、予め定められた設定を変更する必要がない場合でも送られ、その場合前記パターンは空である)も示されていない。
【0059】
最後に、初期マスクしたLCPパケットよりも先に送られる標準LCPパケットも示されていない。したがって、図5から図7に示されたパケットは全てマスクしたパケットである。
【0060】
図5はAUがCHAP(チャレンジハンドシェーク認証プロトコル)を必要とする実施例を示す。したがって、リンクアップメッセージに応答して、AUは最初に標準LCPパケットを送り相次いでマスクしたLCPパケット(前記したように、図示せず)を送り次にAUはCHAP−チャレンジ(challenge)を送る。さらに、AUはCHAPパケットに相次いでIPCPパケットも送り、これら2つのパケットは先行するマスクしたLCPパケット(図示せず)と共に1組のマスクしたパケットを形成し、それによりシステムは構成、認証およびネットワーク制御を同時に実施することができる。このセットに応答して、TEはユーザIDおよび/もしくはCHAPパケットおよび第1のIPパケットに対応するパスワードを送る。したがって、認証およびネットワークレイヤパケット交換は同時に実施され、ネットワークレイヤ(IP)パケットの交換は0.5RTT後に既に始まるようにされる。それは図4に示す標準PPPに関して著しい増加である。図4は標準PPPに対する最少(すなわち、理想的)構成しか示していないことを再度留意すべきである。
【0061】
図6はAUがPAP(パスワード認証プロトコル)を必要とする実施例を示す。PAPが必要とされていることを示すパケットはPAPが予め定められた設定ではないため予め定められた設定のこの変更を示す適切なマスクしたLCPパケットであることを注記しなければならない点を除けば、手順は図5に示すものに非常に類似している。すなわち、図5に示す実施例と同様に、リンクアップメッセージに応答して、AUは最初に標準LCPパケット(図示せず)を送り出し次にPAPを要求する前記マスクしたLCPパケットを送り出し、その後IPCPパケットが送り出される。それに応答して、TEは第1のIPパケットだけでなく、PAPユーザIDおよび/もしくはパスワードを送る。図5のケースと同様に、ネットワークレイヤパケット交換は0.5RTT後に開始することができる。
【0062】
最後に、図7に認証が必要とされずすなわち要求されずかつTEが第1のマスクしたIPパケットを送ることにより応答する初期標準LCPパケットおよびマスクしたLCPパケット(前記したように、図示せず)の後でAUがマスクしたIPCPパケットを送る実施例を示す。ここでも、ネットワークレイヤパケット交換は0.5RTT後に開始することができる。
【0063】
前記した実施例によりセルラー網を介したインターネットアクセスに対する全体接続時間が低減される。認証が必要とされるか否かにかかわらず、ポイントツーポイント構成は0.5RTTに低減される。えられる利点は標準PPPにおいて認証があるもしくはない場合にそれぞれ最少の1.5もしくは2.5RTTとなることである(図5から図7と比べた図4参照)。GSMセルラー網ではそれは例えば認証がない場合のおよそ1000msおよび認証がある場合の1600msに対応する。大概の場合、利得はそれよりも遥かに高くおよそ2秒から4秒であり4秒から8秒となることもある。
【0064】
図5、図6および図7に関して説明した前記実施例では、最初のIPパケット(より一般的には最初のネットワークパケット)はTEが前記したIPCPパケット内のAUからソースIPアドレスを受信した後でしか送られない。しかしながら、本発明のもう1つの実施例に従って、TEはリンクがアップとなる後に送られるマスクしたパケットの最初のセットにより最初のIPパケットおよび恐らくはさらなるIPパケットを送ることもできる。これらのIPパケットは適切なフィールド内にソースIPアドレスを持たない。この場合、AUは消失アドレスをこれらのIPパケット内へ挿入する。TEがAUからIPアドレスを受信した後で、前記した実施例と同様に、TE自体が後続するIPパケット内へアドレスを書き込むことができる。
【0065】
したがって、前記した実施例では下層リンクがアップとなる直後に所望のデータ通信(すなわち、IPパケットの送り出し)を開始することができる。
【0066】
図5、図6および図7にそれぞれ対応する図8、図9および図10に関してそれを幾分詳細に説明する。3つの図面の全てにおいて、インプリメンテーション(TE)を送っているIPパケットおよびインプリメンテーション(AU)を受信しているIPはリンクがアップであることを同時に確認ししたがって同時にパケットを送り始めるものと仮定する。ここでも、標準LCPパケットおよび最初のマスクしたLCPパケットは図示されていない。
【0067】
図5のそれに対応する状況を示す図8のケースでは、TEはリンクがアップであることを確認した直後に送られるパケット列内で最初のIPパケット(および恐らくはそれ以上のパケット)を送る。このIPパケットは適切なフィールド内にIPアドレスを持たないが、この実施例のインプリメンテーションはそれでもパケットが送られるようにされている。ここでも判り易くするためにTEにより送られる初期標準LCPパケットおよびマスクしたLCPパケットは図示されていない。図8に示す状況では、CHAPは必要とされるものとする。したがって、この実施例のインプリメンテーションはCHAP認証が受信されるまでAUは1つ以上のIPパケットをバッファするようにされる。CHAPチャレンジが正しく返答されている、すなわちTEがそれ自体を正しく識別している、ことがAUにより確認されている場合には、AUは消失IPアドレスを挿入して対応するIPパケットを送る。AUからIPアドレスを受信した後でTEにより送られる他方のIPパケットは適切なフィールド内にIPアドレスを有し、それらはAUによりいつものように処理することができる。
【0068】
同様な状況が図9に示されており、それは図6に対応する。ここではAUはPAPが必要とされるパケットを送り、それにIPアドレスが続き、同時にTEがIPアドレスを欠く最初のIPパケットを送る。AUは正しいパスワードが受信されるまでIPパケットをバッファし、次にIPアドレスを挿入してIPパケットを送る。IPアドレス受信後にTEにより送られるIPパケットはその中に含まれたアドレスを有する。
【0069】
図9に関して説明した実施例は次のように修正することもできる。TEにおけるインプリメンテーションは、必要条件メッセージを受信せずに、マスクしたパケットの最初の列内でPAPパスワードを送るようにTEを設定できるようなものとすることができる。リンクがアップである直後にマスクしたパケットの最初の列でユーザIDもしくはパスワードを送るように、すなわちPAPが必要とされるというメッセージを受信せずに自動的に、TEが設定される場合には、AUはただちにパスワードを受信し最初のIPパケットをバッファする必要がない。次にAUは即座にパスワードをチェックすることができる。それが正しければ、消失ソースIPアドレスを受信IPパケットへ挿入することができこれらのパケットを遅延なく送ることができる。このような能力は一般的に常に同じパートナーとの接続を確立する、例えば常に同じインターネットサービスプロバイダに接続するユーザに対する、装置におけるインプリメンテーションに対して特に有利である。
【0070】
当然、この能力はPAPパスワードに限定はされず考えられる任意のパスワードもしくは識別方式において実現することができる。それはIPパケットに対する遅延をさらに低減する利点を有する。
【0071】
図7に対応する図10では、AUはIPパケットをバッファする必要がないため状況はさらに単純となる。より正確にいえば、AUはIPアドレスを送り、TEはIPアドレスを欠く最初のIPパケットを送る。このIPパケットは単にAUにより受信され、それはIPアドレスを挿入し次にパケットを送る。ここでも、前のケースと同様に、AUからIPアドレスを受信した後でTEにより送られるパケットは適切なIPアドレスを含んでいる。
【0072】
一般的に、それはインプリメンテーションがネットワークパケット(すなわち、IPパケット)の送り手として作用することを意味し、これらのパケットがネットワークアドレスを含まなくても、リンクがアップであるという確認に続くマスクしたパケットの最初の列で最初のネットワークパケットを送ることができる。状況に応じて、受け手として作用するインプリメンテーションはネットワークアドレスを挿入し、恐らくは所与の状況に応じて予め決められた条件が満たされるまでバッファすることによりこれらのネットワークパケットを適切に処理する。
【0073】
本発明はそれをよく理解しかつ発明者が現在本発明の最善の実施態様と考えることを当業者に詳細に説明するために提示した前記例に限定されるものではない。
【0074】
例えば、本発明はRfC1661のポイントツーポイントプロトコルの修正に限定はされず、独立項に概説された性質を有するいかなるプロトコルにも当然応用することができる。すなわち、本発明は例えば極端な量のパケット交換を必要とする任意の“チャッティ”プロトコルに有利に応用することができる。その結果、マスクしたパケット(LCP,CHAP,PAP等)に関して前記した特定のプロトコルは、選択した応用に適切な、他のプロトコルで置換もしくは補足することができる。
【0075】
また、本発明は図3に示す回路交換リンクの特定例の構成に限定されるものでもない。それはいかなるタイプの回路交換リンクにも応用することができる。さらに、本発明は回路交換リンクに限定されるものでもない。それはいかなるタイプのリンクにも応用することができる。セルラー網における回路交換リンク等のハイレイテンシリンクに関して利点は特に顕著であるが、本発明を典型的にはやはりハイレイテンシを有する、例えば衛星リンク、に応用する場合にも同様に顕著な利点がえられる。
【0076】
したがって、本発明を詳細な例に関して説明してきたが、本発明はそれに限定されるものではないことが分る。当業者ならば、特定の必要条件および制約に応じて、さまざまな修正および変更が可能である。したがって、本発明の範囲は添付した特許請求の範囲およびそれに相当するものにより明示される。
【0077】
特許請求の範囲の参照符合は理解しやすくするためのものであり、特許請求の範囲を限定するものではない。
【図面の簡単な説明】
【図1】 本発明の基本的方法を説明するフロー図である。
【図2】 RfC1661に従ったポイントツーポイントプロトコルに対するカプセル化を示す図である。
【図3】 セルラー通信システムのモバイルノードとネットワークノード間に接続を確立して前記モバイルノードからインターネットへの接続を確立することを示す略図である。
【図4】 標準ポイントツーポイントプロトコルに従ってリンクが確立される時の図3のモバイルノード内の端末装置と図3のネットワークノード内の直接アクセスユニットとの間のパケット交換のシーケンスを示す図であり、TEにより開始される一連のパケットだけが図示されており考えられる最高速リンク構成を示している。
【図5】 本発明の実施例に従ってリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。
【図6】 本発明のもう1つの実施例に従ってリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。
【図7】 本発明のさらにもう1つの実施例に従ってリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。
【図8】 ネットワークノードからIPアドレスが受信される前にモバイルノードから最初のIPパケットが送られる点を除けば、図5の実施例に対応するリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。
【図9】 ネットワークノードからIPアドレスが受信される前にモバイルノードから最初のIPパケットが送られる点を除けば、図6の実施例に対応するリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。
【図10】 ネットワークノードからIPアドレスが受信される前にモバイルノードから最初のIPパケットが送られる点を除けば、図7の実施例に対応するリンクを確立する時にモバイルノードとネットワークノード間で交換されるパケットのシーケンスを示す図である。

Claims (21)

  1. 通信リンクによりもう1つの通信装置に接続される通信装置を制御して前記通信リンクをパケット交換用に構成する方法であって、前記2つの通信装置の一方は他方側で第1のプロトコル(IP)に従うパケット交換網に接続され、前記方法は前記リンクを介した前記通信装置間の通信が少なくとも前記第1のプロトコル(IP)をカプセル化しかつ前記リンクを確立し構成する第3のプロトコル(LCP)を含む第2の予め決められたプロトコル(PPP)に従ってパケットを交換して行われるように前記装置を制御することが可能であり、前記第2のプロトコル(PPP)は、
    −前記リンクを介して送られるパケットが、前記第3のプロトコル(LCP)に対し少なくとも1つの特定値が予約され、他の予め決められた値は前記第2のプロトコル(PPP)により予約されないようにして、予め決められたプロトコルに対する予め決められた値が予約されるプロトコルフィールド(1)と、前記プロトコルフィールド(1)内に含まれる値により示されるプロトコルに関連するデータを含む情報フィールド(2)とを含むこと、および
    −リンクを構成するプロセスが、プロトコルフィールド内の前記第3のプロトコル(LCP)を示すパケットだけ処理されて他の全てのパケットは廃棄されるようにパケットが交換される少なくとも1つのフェーズを含むこと、
    とを必要とし、
    前記方法はさらに、
    前記第2のプロトコル(PPP)に準じておりそのプロトコルフィールド内の前記第3のプロトコル(LCP)を示す第1のタイプのパケットを前記リンクを介して送り出すステップと、
    続いて前記第2のプロトコル(PPP)により許可はされるが前記第2のプロトコル(PPP)により予約はされない値をそのプロトコルフィールド内に有する少なくとも1つの第2のタイプのパケットを送り出し、前記第2のパケットは前記第2のプロトコル(PPP)に従って動作する通信装置により拒否はされないがそれにより処理されることなく廃棄されるようにするステップと、
    前記第1のタイプのパケットの受信を待機し受信したパケットを格納し、引き続き前記第2のタイプのパケットを受信するまで予め決められた時間待機するステップと、
    第2のタイプのパケットが受信されない場合には、前記第1のタイプの前記格納されたパケットを処理し引き続き前記第2のプロトコル(PPP)に従って動作するステップと、
    このようなパケットが受信される場合には、前記第2のタイプの前記パケットを処理するステップと、
    を含む、方法。
  2. 請求項1記載の方法であって、前記第2のタイプの前記少なくとも1つのパケットは前記第1のタイプの前記パケットに対しバックツーバックで送られる、方法。
  3. 請求項1あるいは請求項2記載の方法であって、第2のタイプの複数のパケットが第1のタイプの前記パケットの後で送られ、前記複数の内に含まれる前記パケットはバックツーバックで送られる、方法。
  4. 請求項1から請求項3のいずれか1項記載の方法であって、前記通信リンクはシリアルリンクである、方法。
  5. 請求項4記載の方法であって、前記通信リンクは回路交換リンクもしくは衛星リンクである、方法。
  6. 請求項1から請求項4のいずれか1項記載の方法であって、前記第1のプロトコル(IP)はインターネットプロトコルであり、前記第2のプロトコル(PPP)は標準ポイントツーポイントプロトコルであり、前記第3のプロトコル(LCP)はリンク構成プロトコルである、方法。
  7. 請求項6記載の方法であって、前記標準ポイントツーポイントプロトコルはRcF1661に従う、方法。
  8. 請求項6あるいは請求項7記載の方法であって、前記第1のタイプのパケットは前記標準ポイントツーポイントプロトコルに従うリンク構成プロトコルパケットであり、前記少なくとも1つの引き続く第2のタイプのパケットは前記標準ポイントツーポイントプロトコルに従うパケットに対して許可はされるが前記標準ポイントツーポイントプロトコルにより使用するために予約されることはない範囲内の値をそのプロトコルフィールド内に有するリンク構成プロトコルパケットである、方法。
  9. 請求項8記載の方法であって、前記第2のタイプのリンク構成プロトコルパケットにはパスワード認証プロトコルパケット、リンク品質報告パケット、チャレンジハンドシェーク認証プロトコルパケット、インターネットプロトコル構成プロトコルパケットおよびインターネットプロトコルパケットの少なくとも1つが続き、前記第2のタイプのリンク構成プロトコルパケットに続く1つ以上の前記各パケットも第2のタイプである、方法。
  10. 請求項3記載の方法であって、
    −前記通信装置がネットワークレイヤプロトコルパケットの送り手(TE)として作用する場合には、少なくとも1つのネットワークレイヤプロトコルパケットが前記複数の第2のタイプのパケット内で送られ、前記少なくとも1つのネットワークレイヤプロトコルパケットは適切なネットワークプロトコルソースアドレスを欠き、
    −前記通信装置がネットワーク行き先へ送るネットワークレイヤプロトコルパケットの受け手(AU)として作用する場合には、前記通信装置は適切なネットワークプロトコルアドレスを欠くこれらのネットワークレイヤプロトコルパケットへネットワークプロトコルソースアドレスを挿入する、方法。
  11. 請求項10記載の方法であって、前記通信装置がネットワークレイヤプロトコルパケットの受け手(AU)として作用する場合には、前記通信装置は予め決められた条件が満たされるまで適切なネットワークプロトコルソースアドレスを欠くこれらのネットワークレイヤプロトコルパケットをバッファする、方法。
  12. 請求項10あるいは請求項11記載の方法であって、前記ネットワークレイヤプロトコルパケットはインターネットプロトコルパケットであり前記ネットワークプロトコルアドレスはインターネットプロトコルアドレスである、方法。
  13. 通信リンクによりもう1つの通信装置に接続されるように制御される通信装置であって、前記装置は前記通信リンクをパケット交換のために構成するように制御することが可能であり、前記2つの通信装置の一方は他方側で第1のプロトコル(IP)に従うパケット交換網に接続され、前記装置は前記リンクを介した通信が少なくとも前記第1のプロトコル(IP)をカプセル化しかつ前記リンクを確立し構成する第3のプロトコル(LCP)を含む第2の予め決められたプロトコル(PPP)に従ってパケットを交換して行われるように制御することが可能であり、前記第2のプロトコル(PPP)は、
    −前記リンクを介して送られるパケットが、前記第3のプロトコル(LCP)に対し少なくとも1つの特定値が予約され、他の予め決められた値は前記第2のプロトコル(PPP)により予約されないようにして、予め決められたプロトコルに対する予め決められた値が予約されるプロトコルフィールド(1)と、前記プロトコルフィールド(1)内に含まれる値により示されるプロトコルに関連するデータを含む情報フィールド(2)とを含むこと、および
    −リンクを構成するプロセスが、プロトコルフィールド内の前記第3のプロトコル(LCP)を示すパケットだけ処理されて他の全てのパケットは廃棄されるようにパケットが交換される少なくとも1つのフェーズを含むこと、
    とを必要とし、
    前記装置はさらに、
    前記第2のプロトコル(PPP)に準じており、そのプロトコルフィールド内の前記第3のプロトコル(LCP)を示す第1のタイプのパケットを前記リンクを介して送り出す手段と、
    続いて前記第2のプロトコル(PPP)により許可はされるが前記第2のプロトコル(PPP)により予約はされない値をそのプロトコルフィールド内に有する少なくとも1つの第2のタイプのパケットを送り出し、前記第2のパケットは前記第2のプロトコル(PPP)に従って動作する通信装置により拒否はされないがそれにより処理されることなく廃棄されるようにする手段と、
    前記第1のタイプのパケットを受信した後で格納し、引き続き前記第2のタイプのパケットを受信するために予め決められた時間待機する手段と、
    第2のタイプのパケットが受信されない場合には前記第1のタイプの前記格納されたパケットを処理し、引き続き前記第2のプロトコル(PPP)に従って動作するように装置を制御する手段と、
    このようなパケットが受信される場合には、前記第2のタイプのパケットを処理する手段と、
    を含む、装置。
  14. 請求項13記載の装置であって、前記第2のタイプの前記少なくとも1つのパケットは前記第1のタイプの前記パケットに対しバックツーバックで送られる、装置。
  15. 請求項13もしくは請求項14記載の装置であって、第2のタイプの複数のパケットが第1のタイプの前記パケットの後で送られ、前記複数の内に含まれる前記パケットは相次いで送られる、装置。
  16. 請求項13から請求項15のいずれか1項記載の装置であって、前記通信リンクはシリアルリンクである、装置。
  17. 請求項16記載の装置であって、前記通信リンクは回路交換リンクもしくは衛星リンクである、装置。
  18. 請求項13から請求項16のいずれか1項記載の装置であって、前記第1のプロトコル(IP)はインターネットプロトコルであり、前記第2のプロトコル(PPP)は標準ポイントツーポイントプロトコルであり、前記第3のプロトコル(LCP)はリンク構成プロトコルである、装置。
  19. 請求項18記載の装置であって、前記標準ポイントツーポイントプロトコルはRcF1661に従う、装置。
  20. 請求項18あるいは請求項19記載の装置であって、前記第1のタイプのパケットは前記標準ポイントツーポイントプロトコルに従うリンク構成プロトコルパケットであり、前記少なくとも1つの引き続く第2のタイプのパケットは前記標準ポイントツーポイントプロトコルに従うパケットに対して許可はされるが前記標準ポイントツーポイントプロトコルにより使用するために予約されることはない範囲内の値をそのプロトコルフィールド内に有するリンク構成プロトコルパケットである、装置。
  21. 請求項20記載の装置であって、前記第2のタイプのリンク構成プロトコルパケットにはパスワード認証プロトコルパケット、リンク品質報告パケット、チャレンジハンドシェーク認証プロトコルパケット、インターネットプロトコル構成プロトコルパケットおよびインターネットプロトコルパケットの少なくとも1つが続き、前記第2のタイプのリンク構成プロトコルパケットに続く前記1つ以上の各パケットも第2のタイプである、装置。
JP2000528055A 1998-01-12 1999-01-11 リンク構成方法および装置 Expired - Lifetime JP3967548B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19800772.8 1998-01-12
DE19800772A DE19800772C2 (de) 1998-01-12 1998-01-12 Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
PCT/EP1999/000111 WO1999035798A1 (en) 1998-01-12 1999-01-11 Method and device for configuring a link

Publications (2)

Publication Number Publication Date
JP2002501331A JP2002501331A (ja) 2002-01-15
JP3967548B2 true JP3967548B2 (ja) 2007-08-29

Family

ID=7854351

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000528055A Expired - Lifetime JP3967548B2 (ja) 1998-01-12 1999-01-11 リンク構成方法および装置

Country Status (10)

Country Link
US (1) US6487218B1 (ja)
EP (1) EP1046266B1 (ja)
JP (1) JP3967548B2 (ja)
CN (1) CN1222145C (ja)
AU (1) AU753693B2 (ja)
CA (1) CA2317446C (ja)
DE (1) DE19800772C2 (ja)
ES (1) ES2226336T3 (ja)
IL (1) IL137035A (ja)
WO (1) WO1999035798A1 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1056258A1 (en) 1999-05-27 2000-11-29 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Data unit sending means and control method in wireless networks
US6654914B1 (en) * 1999-05-28 2003-11-25 Teradyne, Inc. Network fault isolation
US6957346B1 (en) 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations
US6934276B1 (en) * 1999-09-08 2005-08-23 Qualcomm Inc Methods for efficient early protocol detection
SG119208A1 (en) * 1999-09-21 2006-02-28 Ntt Docomo Inc Data conversion apparatus signal data conversion method dce gateway and communication apparatus
US6918041B1 (en) * 2000-02-23 2005-07-12 Microsoft Corporation System and method of network communication with client-forced authentication
US7228363B1 (en) 2000-04-05 2007-06-05 Rockwell Automation Technologies, Inc. Pointbus architecture and automatic sequential addressing
US7080150B1 (en) * 2000-04-10 2006-07-18 Rockwell Automation Technologies, Inc. Pointbus architecture and automatic sequential addressing protocol
JP2001309053A (ja) * 2000-04-26 2001-11-02 Nec Corp Ipアドレス割り当てシステム及びその処理方法
JP2001339431A (ja) * 2000-05-26 2001-12-07 Fujitsu Ltd 通信方式、中継装置、エンドシステム及び通信方法
AU2001290172A1 (en) * 2000-10-18 2002-04-29 Noriaki Hashimoto Method and system for preventing unauthorized access to a network
US7363371B2 (en) * 2000-12-28 2008-04-22 Nortel Networks Limited Traffic flow management in a communications network
BR0209538A (pt) * 2001-05-08 2004-05-04 Nortel Networks Ltd Identificação de recursos não utilizados em uma rede de dados de pacote
US7403498B2 (en) * 2001-05-31 2008-07-22 Qualcomm Incorporated Method and apparatus for selective examination of PPP packets for renegotiation of a PPP link on a Um interface
US7295522B2 (en) * 2001-06-29 2007-11-13 Microsoft Corporation System and method for continuously provisioning a mobile device
JP3697711B2 (ja) * 2001-07-04 2005-09-21 日本電気株式会社 Ppp終端装置、ネットワーク装置及びlcpエコー要求応答方法
JP4225743B2 (ja) * 2002-07-04 2009-02-18 株式会社東芝 無線端末及び通信制御方法
ATE381195T1 (de) * 2002-08-01 2007-12-15 Research In Motion Ltd Mobilstation zur aufrechterhaltung einer immer eingeschalteten drahtlosen internetprotokoll- kommunikation und verfahren dazu
US20050021770A1 (en) * 2003-06-13 2005-01-27 Guy Helm Method for transferring PPP inactivity time in a CDMA2000 network
US7543142B2 (en) * 2003-12-19 2009-06-02 Intel Corporation Method and apparatus for performing an authentication after cipher operation in a network processor
KR100617672B1 (ko) * 2003-12-26 2006-08-28 삼성전자주식회사 이동통신 단말기와 기지국 간에 점대 점 프로토콜 연결설정 방법
JP3984965B2 (ja) * 2004-02-25 2007-10-03 株式会社日立コミュニケーションテクノロジー 通信端末装置及び通信接続装置ならびにこれを用いた通信方法
US8676986B2 (en) * 2004-03-10 2014-03-18 Cisco Technology, Inc. Reduced data session establishment time in CDMA-2000 networks
JP3959402B2 (ja) * 2004-03-19 2007-08-15 株式会社日立コミュニケーションテクノロジー 通信接続装置及び通信端末ならびにこれを用いた通信方法
US9032065B2 (en) 2004-07-30 2015-05-12 Qualcomm Incorporated Fast link establishment for network access
US8233416B2 (en) * 2004-09-28 2012-07-31 Qualcomm Incorporated Handoff supports for networks having different link establishment protocols
CN1909472B (zh) * 2005-08-05 2010-05-05 华为技术有限公司 一种基于主、备pos接口的状态检测方法
HUE045919T2 (hu) 2007-03-19 2020-01-28 Optis Wireless Technology Llc Rádiós hordozó specifikus CQI jelentés
EP2106115B1 (de) * 2008-03-28 2011-02-23 Cinterion Wireless Modules GmbH Verfahren zum Betreiben eines Kommunikationsgerätes und Kommunikationsgerät hierfür
CN101741656B (zh) * 2008-11-12 2012-01-11 上海摩波彼克半导体有限公司 实现移动通信无线Modem终端点对点协议数据传输优化的方法
EP2257025A1 (en) * 2009-05-27 2010-12-01 ST-Ericsson SA System and method for establishing reliable communication in a connection-less environment
US9306803B2 (en) * 2009-10-30 2016-04-05 Hewlett Packard Enterprise Development Lp Methods and devices for implementing configuration synchronization
US8661118B2 (en) 2010-03-08 2014-02-25 Microsoft Corporation Detection of end-to-end transport quality
US8811281B2 (en) 2011-04-01 2014-08-19 Cisco Technology, Inc. Soft retention for call admission control in communication networks

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996000468A1 (en) * 1994-06-24 1996-01-04 Metricom, Inc. Method for using point-to-point protocol over an imperfect mesh network
US5550816A (en) * 1994-12-29 1996-08-27 Storage Technology Corporation Method and apparatus for virtual switching
FI98027C (fi) * 1995-01-10 1997-03-25 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten
US5918019A (en) * 1996-07-29 1999-06-29 Cisco Technology, Inc. Virtual dial-up protocol for network communication
JPH10154995A (ja) * 1996-11-20 1998-06-09 Fujitsu Ltd ゲートウェイ装置及びパケット中継方法
US6041054A (en) * 1997-09-24 2000-03-21 Telefonaktiebolaget Lm Ericsson Efficient transport of internet protocol packets using asynchronous transfer mode adaptation layer two

Also Published As

Publication number Publication date
CA2317446C (en) 2005-06-28
CN1222145C (zh) 2005-10-05
CA2317446A1 (en) 1999-07-15
US6487218B1 (en) 2002-11-26
AU2516899A (en) 1999-07-26
EP1046266B1 (en) 2004-10-06
AU753693B2 (en) 2002-10-24
IL137035A0 (en) 2001-06-14
WO1999035798A1 (en) 1999-07-15
CN1292966A (zh) 2001-04-25
ES2226336T3 (es) 2005-03-16
EP1046266A1 (en) 2000-10-25
JP2002501331A (ja) 2002-01-15
IL137035A (en) 2004-08-31
DE19800772A1 (de) 1999-07-15
DE19800772C2 (de) 2000-04-06

Similar Documents

Publication Publication Date Title
JP3967548B2 (ja) リンク構成方法および装置
JP4164365B2 (ja) デュアル・プロキシ装置を設けることによる無線インタフェースを介するtcp性能の改良技術
US6542490B1 (en) Data link control proctocol for 3G wireless system
US7957369B2 (en) Methods and apparatus for data communications through packet networks
KR101192523B1 (ko) 서로 다른 링크 확립 프로토콜을 가진 네트워크들에 대한 핸드오프 지원
JP3430509B2 (ja) データ通信システム及び方法
RU2351082C2 (ru) Быстрое установление соединения для доступа к сети
JP2005064594A (ja) フレーム送受信システム、フレーム送信装置、フレーム受信装置、及びフレーム送受信方法
EP1155551B1 (en) Simultaneous setup of ppp on a um and rm interface
MXPA02009502A (es) Metodo y aparato para aplicarse a una estacion movil para identificar eventos especificos.
US7761508B2 (en) Access device-based fragmentation and interleaving support for tunneled communication sessions
US7680122B2 (en) Communication method for data communication based on point-to-point protocol
KR20070103362A (ko) 서로 다른 링크 확립 프로토콜을 가진 네트워크들에 대한핸드오프 지원
US7746852B2 (en) Packet data serving node and communication method using the same
Cisco Session and Tunnel Scalability
EP1505759A2 (en) Method and device for transmitting/receiving data using acknowledged transport layer protocols
Cisco Session and Tunnel Scalability
JP4567051B2 (ja) ワイヤレス・ネットワークにおけるセッション確立時間の削減方法
KR20070078922A (ko) 이동통신 시스템에서 피피피 재접속시 데이터 전송 방법
Harvey et al. PPP Network Control Protocol for LAN Extension Status of Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Chapman et al. PPP Network Control Protocol for LAN Extension

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050811

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20050811

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050812

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20050811

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070508

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070531

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100608

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110608

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120608

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120608

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130608

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term